• Es ist bereits Apfeltalk-Tradition und wir möchten sie auch in diesem Jahr fortsetzen: Unser Apfeltalk-Weihnachtslogo-Wettbewerb hat begonnen! Gestaltet für uns das Weihnachtsbanner, das im Monat Dezember bis zum Weihnachtsfest unsere Webseite schmücken soll. Lasst Eurer Kreativität freien Lauf! Hier geht es zum Wettbewerb --> Klick
  • November - das bedeutet oftmals Herbstblues, grauer Himmel, Tristesse und Wetter, bei dem man gern im Warmen bleibt. Aber nur oftmals! Wir fordern Euch gern auf, gegen den Herbstblues anzukämpfen und hoffen, dabei hilft Euch unser aktuelles Monatsthema. Neugierig geworden? --> Zum Mitmachen bitte hier klicken

Patentverletzung: Apple soll 2,8 Milliarden Dollar zahlen

Bezahlt Apple aus der Portokasse. Gehört zum tagtäglichen Geschäft dazu.
 
Mein Gott, nicht ein Post hier hat bisher etwas mit dem Artikel zu tun.
Habe ich mir auch gedacht. Kommt aber öfters im Magazin vor.

Nun denn, für mich nimmt diese Verklagerei aufgrund von Patentverletzungen zuweilen groteske Züge an.

Klar eine Kopie eines Markenproduktes zu einem Bruchteil des Peises aus China ist eine.

Es kommen aber auch andere Fälle vor.
 
Die beschäftigen 20 Leute mit einer Routine, die abfragt, welche Übertragungsart der Empfänger unterstützt? Lächerlich und meiner Meinung nach nicht patentierbar.
 
Wer soll denn sonst die Kosten tragen?
Der Hersteller, der Importeur oder doch der Kunde der dadurch das er solche Produkte kauft dieses Geschäft erst ermöglicht?

Mein Gott, nicht ein Post hier hat bisher etwas mit dem Artikel zu tun. ;)

Na sicher nicht der Endkunde wenn er auf dem amazon.de Marketplace bestellt.

Man muss nicht alles mit sich machen lassen.
 
"Das Unternehmen betont kein Patenttroll zu sein." Herrlich. :D
 
@theSNAD Aber leider ist das so. Und ich hoffe, das wird bald geändert. Denn was mal zum Schutz von Ideen gedacht war, ist schon lange Zeit in Behinderung von Entwicklung übergegangen. Das mit den 20 Ingenieuren ist auch absurd. So schwierig ist es wohl nicht, auf einen funktionierenden Prozess für dieses Problem zu kommen. Man kann sich aber so nun gut zusammenreimen, warum Apple zB die iCloud-Funktionalität nicht "einfach" so komfortabel, wie bei Dropbox gestaltet. Einfach, weil sie einen anderen Weg finden müssen, der nicht gegen Patente verstößt...oder eben teuer lizensieren.
 
Man kann sich aber so nun gut zusammenreimen, warum Apple zB die iCloud-Funktionalität nicht "einfach" so komfortabel, wie bei Dropbox gestaltet. Einfach, weil sie einen anderen Weg finden müssen, der nicht gegen Patente verstößt...oder eben teuer lizensieren.

Man kann aus der Historie der Cloud- und Onlinediensten von Apple aber auch einfach schließen, dass sie das einfach nicht auf die Kette kriegen, anstatt sich weitere Theorien zurechtzulegen, warum Apple das "eigentlich" doch ganz toll könnte, wenn sie denn nur dürften... Schließlich haben das Microsoft, Google und Amazon auch hinbekommen.

Die beschäftigen 20 Leute mit einer Routine, die abfragt, welche Übertragungsart der Empfänger unterstützt? Lächerlich und meiner Meinung nach nicht patentierbar.

Wenn man keine Ahnung hat, einfach mal nichts schreiben. Für einen Wechsel vom paketbasierten iMessage-Protokoll auf das verbindungsorientierte MAP für SMS müssen u.a. die i.d.R. fragmentierten iMessages zusammengesetzt werden, nach Abfrage des SMS-C des Empfängers auf 140 oder 160 Zeichen umgebrochen werden und die Prozesse zum verzögerten (re-)senden des MAP bedient werden. Natürlich muß der dahinterstehende Dienst das ganze über SS7 tunneln und daher ggf. einen Dualstack implementieren.
 
  • Like
Reaktionen: walnussbaer
Für einen Wechsel vom paketbasierten iMessage-Protokoll auf das verbindungsorientierte MAP für SMS müssen u.a. die i.d.R. fragmentierten iMessages zusammengesetzt werden, nach Abfrage des SMS-C des Empfängers auf 140 oder 160 Zeichen umgebrochen werden und die Prozesse zum verzögerten (re-)senden des MAP bedient werden. Natürlich muß der dahinterstehende Dienst das ganze über SS7 tunneln und daher ggf. einen Dualstack implementieren.
Ja, jetzt wo du's sagst...[emoji4]
 
  • Like
Reaktionen: Arcane
Für einen Wechsel vom paketbasierten iMessage-Protokoll auf das verbindungsorientierte MAP für SMS müssen u.a. die i.d.R. fragmentierten iMessages zusammengesetzt werden

Zumindest bei mir entscheidet iOS vorab, ob SMS oder iMessage möglich ist und geht auf die ensprechende Nachrichtenfunktion. Da muss nichts konvertiert werden?
 
Natürlich muß der dahinterstehende Dienst das ganze über SS7 tunneln und daher ggf. einen Dualstack implementieren.
Ich wäre eigentlich davon ausgegangen, dass da dann das iPhone mit dem Netz kommuniziert und die Nachricht als SMS überträgt. Das der iMessage-Dienst direkt mit dem Netzbetreiber kommuniziert wundert mich. Sollten die iMessages nicht nur verschlüsselt auf den Apple-Servern liegen? Oder versteh ich da grad was falsch.
 
Zumindest bei mir entscheidet iOS vorab, ob SMS oder iMessage möglich ist und geht auf die ensprechende Nachrichtenfunktion. Da muss nichts konvertiert werden?

Es geht um die Technik, die das ermöglicht. Zumindest bei mir versucht iOS auch durchaus eine iMessage zu senden und macht dann einen Fallback auf GSM/SMS, wenn das nicht klappt (z.B. weil der Gegenüber gerade im Ausland roamt und keine Datenverbindung hat).

Das der iMessage-Dienst direkt mit dem Netzbetreiber kommuniziert wundert mich.

Das tut nicht der Dienst, sondern die Nachrichten-App (bzw. das Framework dahinter).

Oder versteh ich da grad was falsch.

Tust du.