Bundespatentgericht, Urteil vom 02.02.2022, Az. 5 Ni 31/20 (EP)

Die Beklagte ist eingetragene Inhaberin des auch mit Wirkung für das Hoheitsgebiet der [X.] am 29. April 2008 angemeldete [X.] Patents 2 393 259 (Streitpatent = Anlage K2), das die Prioritäten vom 28. Juni 2007 aus [X.] 937552 P, vom 19. Oktober 2007 aus [X.] 999619 P und vom 8. Februar 2008 aus [X.] 28400 in Anspruch nimmt. Der Hinweis auf Erteilung des Streitpatents ist am 17. August 2016 veröffentlicht.

Das in [X.] gefasste Streitpatent ist in [X.] und wird beim [X.] unter dem Aktenzeichen 60 2008 045 808.3 geführt. Es trägt die Bezeichnung

„Telecommunication and multimedia management method and apparatus“

(auf [X.] laut Streitpatentschrift:

„Telekommunikations- und Multimediaverwaltungsverfahren und -vorrichtung“)

und umfasst in der erteilten Fassung zwölf Patentansprüche, die die Klägerin mit der am 13. August 2020 eingereichten Nichtigkeitsklage im Umfang der Patentansprüche 1, 5, 7, 8, 10, 11 und 12 teilweise angegriffen hat.

Der erteilte unabhängige Patentanspruch 1 lautet gemäß Streitpatentschrift:

Die Patentansprüche 5, 7, 8, 10, 11 und 12 sind unmittelbar oder mittelbar rückbezogen auf Patentanspruch 1; wegen ihres Wortlauts wird auf die Akte verwiesen.

Die Klägerin ist der Ansicht, das Streitpatent sei unzulässig erweitert und wegen des [X.] der mangelnden Patentfähigkeit, mangelnder Neuheit und insbesondere mangelnder erfinderischer Tätigkeit, für nichtig zu erklären.

Den Einwand der fehlenden Patentfähigkeit stützt sie auf die [X.] (Nummerierung und Kurzzeichen nach Klägerin):

Die Klägerin beantragt,

das [X.] Patent 2 393 259 mit Wirkung für das Hoheitsgebiet der [X.] im Umfang der Patentansprüche 1, 5, 7, 8, 10, 11 und 12 für nichtig zu erklären.

Die Beklagte beantragt,

die Klage abzuweisen,

hilfsweise, die Klage abzuweisen,

soweit sie sich auch gegen eine der Fassungen des Streitpatents nach den [X.] 0‘, 0a‘, 1a, 1a‘, 1c, 1c‘, 2a, 2a‘, 2c, 2c‘, 3a, 3a‘, 3c, 3c‘, 4a, 4a‘, 5, 5‘, 6, 6‘, 6a, 6a‘, 7, 7‘, 7a oder 7a‘ richtet,

wobei die Anträge in der genannten Reihenfolge geprüft werden sollen und alle Anträge als geschlossene Anspruchsätze gestellt sind.

Wegen des Wortlauts der Patentansprüche nach den [X.] wird auf die Akte verwiesen.

Die Beklagte tritt der Argumentation der Klägerin entgegen und hält das Streitpatent in der erteilten Fassung nicht für unzulässig erweitert und seinen Gegenstand für schutzfähig, jedenfalls in einer der mit den [X.] verteidigten Fassung.

Der Senat hat den Parteien einen qualifizierten Hinweis vom 14. Oktober 2021 zugeleitet und hierin Fristen zur Stellungnahme auf den Hinweis und auf etwaiges Vorbringen der jeweiligen Gegenpartei gesetzt.

Wegen der weiteren Einzelheiten des Sach- und Streitstands wird auf die zwischen den Parteien gewechselten Schriftsätze nebst Anlagen, auf das Protokoll der mündlichen Verhandlung vom 2. Februar 2022 sowie den weiteren Akteninhalt Bezug genommen.

Die zulässige Klage ist nicht begründet. Der Gegenstand des Patents geht nicht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus und auch der geltend gemachte [X.] der mangelnden Patentfähigkeit gem. Art. II § 6 Abs. 1 Nr. 1 [X.] [X.] Art. 138 Abs. 1 lit. a), 52, 54, 56 EPÜ liegt nicht vor.

[X.] Zum Gegenstand des [X.]s

1. Der Gegenstand des [X.]s betrifft ein Telekommunikations- und Multimedia-Verwaltungsverfahrenund -gerät, die es Benutzern ermöglichen, die Nachrichten von Konversationen entweder in einem Live-Modus („live mode“) oder einem zeitversetzten Modus („time-shifted mode“) zu überprüfen („to review“), während einer Konversation zwischen den beiden Modi hin und her zu wechseln, an mehreren Konversationen gleichzeitig teilzunehmen und die Nachrichten von Konversationen zur späteren Überprüfung oder Verarbeitung zu archivieren (vgl. [X.], Abs. [0001]).

Das [X.] geht in seiner Beschreibungseinleitung zunächst davon aus, dass es bei [X.]rachkommunikationssystemen, wie bspw. bei Telefonie, notwendig sei, einen Anruf entgegenzunehmen, um überhaupt erst eine Konversation betreiben zu können (vgl. [X.], Absatz [0002], „[X.], synchronous conversation“). Im Unterschied dazu seien "Voice mail"-Systeme bekannt, die es erlauben, eine Nachricht zu hinterlassen, wenn der Empfänger den Anruf nicht entgegennimmt (vgl. [X.], Absatz [0003], „one-way asynchronous voice message“). Allerdings werde die Nachricht bei "Voice mail"-Systemen üblicherweise nach dem Abhören gelöscht und bei "normalen" Telefonaten gar nicht erst gespeichert (vgl. [X.], Abs. [0004] bis [0006]). Bei bekannten Textkommunikationssystemen, wie bspw. [X.] oder E-Mail finde teilweise zwar eine Archivierung von Text-, jedoch nicht von [X.]rachnachrichten statt (vgl. [X.], Abs. [0007]). Bei sogenannten taktischen Kommunikationssystemen, die im Bereich von [X.], Feuerwehr, Polizei, Rettungsteams, etc. Verwendung finden, wäre stets eine funktionierende Radio-Verbindung nötig und verpasste Nachrichten seien unwiderruflich verloren. Darüber hinaus gäbe es weder auf der Sende- noch auf der Empfangsseite geeignete Werkzeuge zum Verwalten, Priorisieren und Archivieren von Nachrichten bzw. ganzen Konversationen (vgl. [X.], Abs. [0010] bis [0013]).

Als eine mögliche Lösungsmöglichkeit bei fehlender Priorisierung von Nachrichten werde bisher insbesondere die Nutzung von mehreren parallelen Kanälen angewendet, was allerdings eine effiziente [X.] erschwere, da die relevanten Kanäle den Teammitgliedern bekannt sein müssten und zwischen den Kanälen umgeschaltet werden müsste (vgl. [X.], Abs. [0012]).

Die paketbasierten Netzwerke basierten im Allgemeinen entweder auf dem [X.]- oder dem [X.]. [X.] offeriere eine schnelle Datenübertragung auf Kosten einer Datensicherung, so dass insbesondere die Vollständigkeit einer Datenübertragung nicht gewährleistet werden könne, wohingegen [X.] eine fehlerfreie Übertragung garantiere, allerdings auf Kosten der Latenz. Die [X.] verwende daher [X.], da es auf eine schnelle und verzögerungsfreie Kommunikation ankomme (vgl. [X.], Abs. [0014]).

Derzeit gebe es jedoch keine bekannten Protokolle, welche die Vorzüge der sicheren Datenübertragung mittels [X.] und der Schnelligkeit von [X.] in sich vereinigten und Medien mit zumindest ausreichender Qualität („[X.]) übertragen könnten. Darüber hinaus fehle ein Protokoll, welches die zu übertragende Informationsmenge bestimmen würde in Abhängigkeit der Verfügbarkeit von Teilnehmern und ggf. deren [X.], den vorherrschenden [X.] sowie der verfügbaren Bandbreite. Die bekannten Telefon-, Voicemail- und taktische [X.]rachkommunikationssysteme gemäß dem Stand der Technik würden somit unnötig Bandbreite verschwenden und die Gesamtperformance des Netzwerks degradieren (vgl. [X.], Abs. [0014]).

2. Da aus den oben genannten Gründen Telefon-, Voicemail- und taktische [X.]rachkommunikationssysteme unzureichend seien, liegt dem [X.] die Aufgabe zugrunde, ein verbessertes [X.]rach- und [X.] und Verwaltungssystem und -verfahren sowie Verbesserungen bei der Bereitstellung von [X.]rache und anderen Medien über paketbasierte Netze bereitzustellen (vgl. [X.], Abs. [0018]).

Diese Aufgabe soll mit einem Verfahren zur Kommunikation nach Anspruch 1 gelöst werden, wobei der Anspruch sich wie folgt gliedern lässt:

3. Als zuständigen Fachmann sieht der [X.] einen Fachmann auf dem Gebiet der Informations- und Nachrichtentechnik, wie zum Beispiel Computernetzwerke und verteilte Systeme. Er verfügt über einschlägige Kenntnisse auf dem Gebiet der Nachrichtenübermittlung und der multimedialen Kommunikation, insbesondere der gängigen Datenübertragungs- und Nachrichtenverfahren zwischen elektronischen Geräten sowie den gängigen [X.]eicherarchitekturen in diesem Bereich. Typischerweise besitzt er einen Bachelor-Abschluss im Fachgebiet Informatik, Elektrotechnik, Nachrichtentechnik oder einen gleichwertigen Abschluss.

4. Dieser Fachmann versteht die Lehre des [X.]s und die Merkmale des Anspruchs 1 wie folgt:

Der Anspruch betrifft ein Verfahren zum Übertragen von Nachrichten von einer ersten [X.] („communication device“; in der [X.] Übersetzung des Patentanspruchs 1 auch als „Kommunikationsvorrichtung“ bezeichnet) über ein Übertragungsnetz („communication network“) (vgl. Merkmal [X.]). Unter einer Übertragungsvorrichtung versteht das [X.] ein physikalisches Gerät, auf dem eine Klientapplikation abläuft. Bei der Klientapplikation handelt es sich um eine Nutzerapplikation des Kommunikationsystems, welche ein Nutzerinterface, ein persistentes [X.]eichermedium und die „[X.]“-Funktionalität beinhaltet (vgl. [X.], Abs. [0034]). Darüber hinaus sieht das [X.] ggf. einen oder mehrere optionale Server vor, die jeweils einen Computerknotenpunkt im Netzwerk darstellen. Server sind verantwortlich für das Routing von Nachrichten, die zwischen verschiedenen Benutzern der o.g. Klientapplikationen über das Netzwerk hin und her gesendet werden, sowie für die dauerhafte [X.]eicherung und Archivierung von Mediennutzlasten. Server bieten Routing, Transcodierung, Sicherheit, Verschlüsselung und Authentifizierung sowie die Optimierung der Datenübertragung über das Netzwerk (vgl. [X.], Abs. [0034], „Server“).

Gemäß [X.] des Verfahrens werden Medien („media“) im Zuge ihrer Erzeugung auf der [X.] fortschreitend nach und nach kodiert („progressively encoded“), die erzeugten und kodierten Medien im Zuge ihrer Erzeugung fortschreitend und dauerhaft gespeichert und fortschreitend über das Netzwerk gesendet („progressively and persistently storing on the first communication device and progressively transmitting media“). Als Beispiel für Medien nennt das [X.] Audio, Video, Text, etc. (vgl. [X.], Abs. [0035]).

Unter Kodieren („encoding“) versteht das [X.] das Übersetzen von erfassten Audio- oder [X.] mit der [X.] in digitale Daten, die von einem Klienten verarbeitet werden können (vgl. [X.], Absatz [0036], „Encoding“). Die Umwandlung von [X.]rache oder Video in digitale Daten (Payload eines „Vox“-Pakets) im Source-Client erfolgt gemäß [X.] in Abhängigkeit von der verfügbaren Übertragungsbandbreite mit angepasster Qualität (vgl. [X.], Abs. [0031], [0068], [0076], dort: „good enough“). Als physikalische [X.]eichermedien nennt das [X.], [X.], Festplatten oder optische Medien bzw. eine Kombination davon (vgl. [X.], Abs. [0072], [X.], [X.] 3 bis 13, „Many possible implementations exist for the physical storage implementation of [X.] 30, including, but not limited to: [X.], [X.], hard drives, [X.], or some combination thereof . [X.] is also "infinite" in size, meaning the amount of data that can be stored in [X.] 30 is not inherently limited. [X.] limit is in comparison to existing jitter buffer technology that discards data as soon as it is rendered. In one specific embodiment, [X.] 30 may be implemented using a small and relatively fast [X.] cache [X.] coupled with a hard drive for persistent storage .“; Unterstreichung hinzugefügt). Gemäß [X.] werden die Daten/Nachrichten in dem jeweiligen [X.] („[X.]“) der [X.]en von Teilnehmern/Benutzer bzw. der Server mit einer Alterssteuerung bspw. bis zu 30 Tagen gespeichert und werden danach verworfen (vgl. [X.], Abs. [0072]), so dass „conversations“ für Sekunden, Minuten, Stunden bzw. mehrere Tage unterbrochen und immer wieder aufgerufen werden können (vgl. [X.], Abs. [0028], Punkt (iv)). Aus fachmännischer Sicht gehen dauerhaft gespeicherte Daten – bspw. beim Abschalten einer [X.] - nicht verloren und werden ohne Zustimmung des Nutzers nicht überschrieben. Unter dem dauerhaften [X.]eichern („persistently storing“) versteht der Fachmann daher ein [X.]eichern in einem nicht-volatilen [X.]eichermedium. Darunter fallen beispielsweise Festplatten bzw. Flash-[X.]eicher, die im Gegensatz zu [X.]-Bausteinen ihren [X.]eicherinhalt beim Abschalten des Geräts oder bei einem Stromausfall nicht verlieren. Soweit das [X.] von einer unendlichen („infinite“) Größe des [X.]eichers spricht, so ist diese natürlich nicht unendlich, sondern nur so groß, dass eine ausreichend große Menge an Daten aus verschiedenen Kommunikationen gespeichert werden kann, und ist somit auf beispielsweise die Festplattengröße begrenzt. Aus Sicht des Fachmanns wird bereits dann mit dem Kodieren, [X.]eichern und Senden der Medien begonnen, sobald sie verfügbar werden, d.h. während z.B. ein Video oder eine [X.]rachnachricht noch aufgenommen wird. Nicht unter den Wortlaut des Anspruchs fallen daher vollständige Medien, also etwa fertig aufgenommene [X.], die anschließend versendet bzw. erst nach deren vollständigem Empfang angezeigt werden.

Nach Merkmal [X.].2 ist neben der Sendefunktion ([X.]) auch eine Empfangsfunktion für die Übertragungsvorrichtung vorgesehen. Dabei soll das Empfangen von Medien einer eingehenden Nachricht fortschreitend stattfinden, während die Medien in einer Echtzeitwiedergabebetriebsart empfangen werden. Auch die empfangenen Medien sollen dabei fortschreitend persistent gespeichert und gerendert, d.h. auf der jeweiligen Kommunikationsvorrichtung in Echtzeit wiedergegeben werden (vgl. [X.], Abs. [0077] – [0078], „render“). Die Umwandlung der empfangenen Daten im Empfänger („destination“, „target client“) zur Darstellung an den Benutzer/Teilnehmer umfasst gemäß [X.] mehrere, verschiedene Optionen, eine [X.]- und Prioritäts-Steuerung, ggf. eine Interpolation bei ausgefallenen Paketen und ein Mixen mehrerer simultaner Streams (vgl. [X.], Abs. [0036], [0114], [0212]).

Nach Merkmal [X.].3.1 soll es sich bei den eingehenden und ausgehenden Nachrichten um asynchrone Nachrichten handeln.

Gemäß Absatz [0051] des [X.]s können Medien, die empfangen werden, sofort während des Empfangs („immediate) oder zeitversetzt („time-shifted“) wiedergegeben werden („Media that is sent or received by the Device 13 running the application 12 is available for immediate Review while being received. [X.] in a time-shifted mode, Conversation management, and archival purposes.”). Und gemäß Absatz [0053] des [X.]s sind im Wesentlichen alle Konversationen asynchron („[X.]/Message management services 20f, all Conversations are essentially asynchronous. “; Unterstreichung hinzugefügt). Und weiter heißt es dort, dass, falls ein Nutzer aus irgendeinem Grund seine Teilnahme verzögert, die Konversation in Richtung einer asynchronen Nachricht abdriftet (vgl. [X.], Abs. [0053], [X.]. 20, [X.] 3 ff, „[X.], [X.], [X.] an asynchronous voice (or other Media) [X.].“).

Bei asynchronen Nachrichten („asynchrone messages“) gemäß Merkmal [X.].3.1 handelt es sich aus fachmännischer Sicht daher um Nachrichten, bei denen das Timing verändert werden kann, d.h. die Nachrichten von eingehenden / empfangenen Medien können gegenüber Nachrichten von ausgehenden/gesendeten Medien zeitversetzt („time shifted“) wiedergegeben werden, müssen dies aber nicht. So auch Absatz [0053] des [X.]s, wonach zwischen einem nahezu synchronen und einem zeitversetzten Modus unterschieden wird („[…] the Conversation again may flow between near synchronous (i.e. live or real-time) and asynchronous (i.e., time-shifted or voice messaging) modes.“).

Gemäß Merkmal [X.] werden bei dem beanspruchten Verfahren die Nachrichten über das Übertragungsnetzwerk zwischen zwei Übertragungsvorrichtungen ausgetauscht, d.h. von einer ersten zu einer zweiten Übertragungsvorrichtung gesendet („transmitted over the communication network from the first communication device to the second communication device“) und über das Übertragungsnetzwerk an der ersten Übertragungsvorrichtung von der zweiten Übertragungsvorrichtung empfangen („and received over the communication network at the first communication device from the second communication device“).

Dieser bi-direktionale Austausch umfassend sowohl ein Senden als auch ein Empfangen von Nachrichten an einer [X.] findet statt, ohne zunächst eine Verbindung zwischen den beiden beteiligten [X.]en herzustellen („[…] without first establishing a connection over the communication network between the first and the second communication device“, Unterstreichung hinzugefügt).

Hinsichtlich des Begriffs „Verbindung“ („connection“) ist zu beachten, dass sich das Multimedia-Management-Verfahren gemäß [X.] auf der reinen [X.] befindet (vgl. [X.], Abs. [0034], „Client: A Client is the user application in the communication system, which includes a user interface, persistent data storage, and "[X.]" functionality.“) und auf die zugrundeliegenden Netzwerke nur aufgesetzt ist, gleichzeitig jedoch im [X.] ebenfalls typische, den unteren [X.] zugeordnete Begriffe wie bspw. gute/schlechte Radio-Bedingungen und Netzwerk-Verbindung verwendet werden (vgl. [X.], Abs. [0029], „[X.], [X.], allowing the real time participation of the conversation.“ und Abs. [0041], [0067], „underlying network 18“ sowie Abs. [0090], „underlying technology of the network 18“).

Wie auch in der mündlichen Verhandlung erörtert, weiß der Fachmann, dass für den Nachrichtenaustausch zwischen zwei Geräten ([X.]en) über ein Netzwerk das [X.]/[X.] für Netzwerkprotokolle gilt. Für das Beispiel des [X.] lässt sich dies auch dem [X.] aus den [X.]uren 4a bis 4c [X.] [0090] bis [0098] für den Austausch der Nachrichten zwischen zwei [X.]en entnehmen. Demnach handelt es sich bei einem [X.] um ein strukturiertes Nachrichtenformat, das zur Kapselung innerhalb eines Transportpakets oder von Transportpaketen der zugrundeliegenden Technologie des Netzwerks ausgelegt ist (vgl. [X.], Abs. [0090], „[X.] format designed for encapsulation inside a transport packet or transport packets of the underlying technology of the network 18.“). Bei dem zugrundeliegenden Netzwerkprotokoll kann es sich beispielsweise um ein [X.], IP oder [X.] handeln (vgl. [X.], Abs. [0092] in Verbindung mit [X.]ur 4b und 4c).

Damit das zugrundeliegende Netzwerk das [X.] an den richtigen Ort liefert, muss gemäß [X.] die Adresse eines Zielclients bekannt sein. Bei [X.] ist dabei die Adresse normalerweise eine [X.]-Adresse, bei der es sich um eine 32-Bit-Zahl handelt, die einen Host innerhalb des Netzwerks eindeutig identifiziert (vgl. [X.], Abs. [0104], „[X.]. [X.], [X.] an [X.] Address, which is a 32-bit number that uniquely identifies a host within the network.“). Der Fachmann weiß, dass die entsprechende Ziel- (und auch die [X.] gemäß [X.] Protokoll in der [X.] (network layer, layer 3) des [X.] verankert ist, vgl. [X.], die „Protocol Options“ in [X.]ur 4c für IP (IPA, [X.]):

Um gemäß dem anspruchsgemäßen Verfahren Nachrichten mit einem Medien-Inhalt zwischen zwei [X.]en über das Netzwerk gemäß Merkmal [X.] auszutauschen, wobei eine Nachricht von der ersten [X.] an die zweite gesendet bzw. an der ersten [X.] von der zweiten empfangen wird, ist es daher erforderlich, dass die entsprechenden [X.] auf den [X.]en bekannt sind und dass die Nachrichtenübertragung im Sinn einer „Ende-zu-Ende“ Übertragung zwischen den beiden [X.]en als jeweiligen „Endpunkten“ bzw. [X.] über das Netzwerk durchgeführt wird.

Der Meinung der Klägerin, wonach es bei dem anspruchsgemäßen Verfahren lediglich ganz allgemein um eine Nachrichtenübertragung von einer ersten/zweiten [X.] zu einer zweiten/ersten [X.], völlig unabhängig von einer Betrachtung der Kommunikationsabläufe bzw. der Protokolle im Netzwerk bspw. unter Zugrundelegung der Schichten des [X.]/[X.], geht, da dies im [X.] nicht festgelegt sei, und die Auslegung daher zu eng sei, schließt sich der [X.] nicht an.

Denn Merkmal [X.] betrifft ebenfalls das Vorliegen eines Verbindungsaufbaus („[…] without first establishing a connection […]“). Während [X.] noch eine Verbindung der ersten [X.] mit dem Netzwerk erfordert, wird hiermit jegliche physikalische und logische Verbindung auf den niedrigen Schichten sowie das Verwenden [X.], wie bspw. [X.] auf der Transportschicht gemäß Layer 4 des [X.], zwischen der ersten und der zweiten [X.] ausgeschlossen. Hinsichtlich eines [X.]-Transports wird übrigens im [X.] [0014] explizit ausgeführt, dass [X.] zwar sicher sei, jedoch zur Verwendung bei „live“ Telefonaten aufgrund der Latenz unpraktisch wäre, so dass gemäß [X.] auf der Transportschicht (Layer 4) – wie bei [X.] – daher das [X.] und verzögerungsärmere [X.]-Protokoll verwendet würde (vgl. [X.], Abs. [0014], [0092]).

Der Fachmann weiß, dass bei einer [X.]-Applikation jedoch (im Gegensatz zum [X.]) stets eine Verbindung aufgebaut wird (vgl. auch [X.], Abs. [0002]), wobei beim Aufbau eines Telefongesprächs das SIP-Protokoll (session initiation protocol) zum Einsatz kommt. Im OSI-Kommunikationsmodell verwaltet die Sitzungsschicht (session layer, Layer 5) den Auf- und Abbau von (logischen) Verbindungen zwischen kommunizierenden [X.]. Eine Verbindung bzw. Sitzung/Session wird aufrechterhalten, während sich die beiden Endpunkte in der Konversation miteinander unterhalten.

Da gemäß [X.] die gesamte „[X.]“- und [X.]eicher-Funktionalität in der Nutzerapplikation des Kommunikationssystems enthalten und auf die zugrundeliegenden Netzwerke nur aufgesetzt ist, ist das Verfahren nach Patentanspruch 1 offensichtlich komplett auf der Anwendungsschicht (Layer 7 des [X.]) realisiert.

Der Fachmann erkennt daher, dass es sich bei der anspruchsgemäßen Verbindung nach Merkmal [X.] insbesondere um eine Verbindung auf Layer 5 des [X.], d.h. der Sitzungsschicht bzw. dem [X.], handelt, auf der gemäß Wortlaut des Patentanspruchs 1 zunächst keine Verbindung zwischen den beiden beteiligten Kommunikationsvorrichtungen hergestellt wird.

Aus Sicht des Fachmanns scheiden somit sowohl eine direkte Verbindung zwischen den beiden Übertragungsvorrichtungen als auch eine indirekte Verbindung, die über einen oder mehrere zwischengeschaltete Server zwischen den beiden Übertragungsvorrichtungen „geroutet“ wird, aus, falls irgendeine Verbindung bereits vor Beginn der Nachrichtenübertragung hergestellt wird.

Nach Auffassung des [X.]s ist Merkmal [X.] beispielsweise auch dann nicht automatisch erfüllt, wenn Medien in einem ersten Übertragungsvorgang von der ersten [X.] zu einem Server und in einem zweiten Übertragungsvorgang von dem Server (ggf. umadressiert) zur zweiten [X.] übertragen werden und in diesem Fall aufgrund des dazwischengeschalteten Servers gerade keine (direkte) Verbindung zwischen der ersten und zweiten [X.] bestehen würde.

Denn solche Teilstreckenverfahren („store and forward“) für die (Ende-zu-Ende) Datenübertragung zwischen zwei [X.]en/[X.], welche vorzugsweise in Netzwerken eingesetzt werden, welche keine dauerhafte Konnektivität der [X.]en zu selbigem voraussetzen, zählen zu den Routing-Verfahren und betreffen somit die unterhalb des [X.]s liegende [X.] ([X.]), was jedoch das Vorliegen eines [X.] (Layer 4) bzw. einer (logischen) Verbindung auf dem darüber liegenden [X.] (Layer 5) nicht unmittelbar ausschließt und was jeweils im Einzelfall zu überprüfen ist.

Darüber hinaus fallen auch [X.] nicht unter den [X.], bei denen eine Verbindung zwischen den [X.]/Klienten für die (Ende-zu-Ende) Datenübertragung über einen Server hergestellt wird, falls dort zuvor beispielsweise eine gemeinsame Session aufgebaut wird, was beispielsweise bei [X.] ([X.]) mit vorab aufgebauter [X.]-Session der Fall ist.

Schließlich betrifft [X.] auch keine [X.], bei denen – beispielsweise wie bei einem E-Mail Dienst mit „push“ / “pop“ oder einem [X.] ([X.]) mit [X.] / [X.] GET – ein Endgerät Daten auf dem Server platziert und ein anderes Endgerät diese Daten in einem separaten Schritt vom Server per Download abholt, da hier zwei unabhängige Datenübertragungen Endgerät-Server und Server-Endgerät und eben keine anspruchsgemäße Kommunikation zwischen zwei [X.]en / [X.] über das Netzwerk stattfindet.

Zusammenfassend darf somit gemäß Merkmal [X.] bei einer (Ende zu Ende) Kommunikation zwischen zwei [X.]en/[X.] vorab auf keinem der die Datenübertragung über das zugrundeliegende Netzwerk betreffende Layer unterhalb der Anwendungsschicht (Layer 7) eine Verbindung zwischen der ersten und zweiten [X.] aufgebaut werden.

Unter den [X.] fällt aber auch, dass nicht nur zeitlich begrenzt zu Beginn des Nachrichtenaustauschs („first“) keine Verbindung hergestellt wird, sondern auch dauerhaft überhaupt keine Verbindung besteht, zumal in den Ausführungsbeispielen des [X.]s niemals eine anspruchsgemäße Verbindung aufgebaut wird.

I[X.] Zu den Nichtigkeitsgründen

Weder der [X.] der unzulässigen Erweiterung gegenüber den ursprünglichen eingereichten Unterlagen noch der [X.] der mangelnden Patentfähigkeit liegen vor.

1. Zum [X.] der unzulässigen Erweiterung

Der Gegenstand des [X.]s geht nicht über den Inhalt der Patentanmeldung in ihrer bei der für die Einreichung der Anmeldung zuständigen Behörde ursprünglich eingereichten Fassung hinaus (Art. II § 6 Abs. 1 Nr. 3 [X.] [X.] Art. 138 Abs. 1 lit. c) EPÜ).

Die Merkmale des Verfahrens gemäß dem erteilten Anspruch 1 sind wie folgt in der ursprünglich eingereichten Fassung (EP 2 393 259 [X.] = [X.]a) offenbart:

Die Merkmale [X.], [X.] und [X.].2 gehen aus dem ursprünglichen Anspruch 1 in Verbindung mit den abhängigen Ansprüchen 2 bis 4 und 6 hervor und sind somit ursprungsoffenbart.

Zwar sind die Merkmale [X.].3.1 und [X.] in der ursprünglich eingereichten Fassung nicht wörtlich offenbart, jedoch entnimmt der Fachmann die beiden Merkmale der Ursprungsoffenbarung an folgenden Stellen unmittelbar.

Die „asynchronous messages“ gemäß [X.].3.1 finden sich in der [X.] in Absatz [0095] (dort: „… all Conversations are essentially asynchronous … [X.] an asynchronous voice (or other Media) [X.] … Conversations can be optionally tagged as asynchronous Messages only … the Conversation again may flow between near synchronous (i.e. live or real-time) and asynchronous (i.e., time-shifted or voice messaging) modes“) sowie im ursprünglichen Anspruch 10.

Das Merkmal „that are transmitted … without first establishing a connection“ gemäß [X.] entnimmt der Fachmann dem Absatz [0040] Punkt iv. (dort: „… participate in conversations without waiting for a connection to be established [X.] conversations, and review previously received time- shifted messages of conversations even when there is no network available, [X.], or other participants are unavailable;“; Unterstreichung hinzugefügt).

Auch der Auffassung der Klägerin, dass eine unzulässige Zwischenverallgemeinerung vorliege, teilt der [X.] nicht.

Soweit die Klägerin der Ansicht ist, der beanspruchte Vorgang, Daten zwischen zwei [X.]en zu übermitteln, ohne zunächst eine Verbindung zueinander aufgebaut zu haben, könne technisch nur dann umgesetzt werden, wenn im Netzwerk ein Server vorgesehen sei, um von der ersten [X.] versendete [X.]e zwischen zu speichern, um diese dann später an die zweite [X.] weiterzuleiten, und bei dem „Weglassen“ eines derartigen, erforderlichen Servers mit seiner [X.] handle es sich daher um eine unzulässige Zwischenverallgemeinerung, überzeugt dies nicht.

Entscheidend ist hierbei, dass der Anspruch in seiner erteilten Fassung voraussetzt, dass das Übertragungsnetz (das üblicherweise auch Server beinhaltet) zwischen die beiden beteiligten Kommunikationsvorrichtungen geschaltet ist und die („[X.]“) Übertragung der Nachrichten zwischen diesen sicherstellt. Der erteilte Anspruch mag die Details der konkreten Implementierung des Übertragungsnetzes offenlassen, aber es kann vor diesem Hintergrund nicht die Rede davon sein, dass in der erteilten Anspruchsfassung ein zwingendes Merkmal fehlt, denn für die Datenübermittlung über das Netzwerk gilt das [X.]. Zuständig für die Datenübermittlung vom Sender zum Empfänger ist dabei die [X.] ([X.]). Da ggf. nicht immer eine direkte Kommunikation zwischen Absender und Ziel möglich ist, müssen Pakete von Knoten, die auf dem Weg liegen, weitergeleitet werden. Wie der Fachmann weiß, gelangen weitervermittelte Pakete dabei nicht in die höheren Schichten, sondern werden mit einem neuen Zwischenziel versehen und an den nächsten Knoten gesendet (geroutet) (vgl. [X.]a, Abs. [0045], „Servers“). Ein Zwischenspeichern ist dabei für den Fachmann – auch ohne eine anspruchsgemäße Verbindung (auf Layer 5 des [X.]) zwischen den [X.]en – nicht zwingend erforderlich.

Darüber hinaus zeigt die [X.]a [X.]ur 7 [X.] [0144] bis [0146] ein Ausführungsbeispiel mit einer Kommunikation zwischen zwei Klienten [X.] und [X.] in unterschiedlichen Netzen A und B über die [X.] 16A, [X.], wobei in den [X.]n ausschließlich ein Routing und keine Zwischenspeicherung offenbart wird.

2. Zum [X.] der mangelnden Patentfähigkeit

Dem Gegenstand von Patentanspruch 1 des [X.]s in der erteilten Fassung steht der [X.] der fehlenden Patentfähigkeit nach Art. II § 6 Abs. 1 Nr. 1 [X.] [X.] Art. 138 Abs. 1 lit. a) EPÜ nicht entgegen. Denn das hiermit unter Schutz gestellte Verfahren gilt gegenüber dem im [X.] Stand der Technik – insbesondere auch gemäß den Druckschriften [X.], [X.], [X.] und [X.] sowie der [X.] – als neu und auf einer erfinderischen Tätigkeit beruhend.

2.1 Zur Neuheit

[X.] erweist sich gegenüber dem nachgewiesenen Stand der Technik als neu im Sinne des Art. 54 EPÜ.

2.1.1 [X.] ist neu gegenüber dem Stand der Technik nach der Druckschrift [X.] - [X.] 2006/0003740 [X.] („[X.]“). Insbesondere die Merkmale [X.], [X.].2 und [X.] nach [X.] gehen aus [X.]/[X.] nicht unmittelbar und eindeutig hervor.

Die Entgegenhaltung [X.]/[X.] betrifft ein Push-To-Talk ([X.]) System für Mobiltelefone (vgl. [X.], Absatz [0002]). Bei einer [X.]-Kommunikation treffen Nachrichten unmittelbar und unangekündigt ein. Entsprechend kann es vorkommen, dass einzelne Nachrichten überhört bzw. versäumt werden (vgl. [X.], Absatz [0005], „An end user of the mobile station may be busy or caught “off-guard” and not listening to the initial communication. Thus, the end user may not hear at least the initial [X.] voice communication“).

Es wird deshalb von [X.]/[X.] vorgeschlagen, eine Aufnahme- und Wiedergabefunktion für [X.]-Geräte vorzusehen, um gesendete und empfangene [X.]rachnachrichten lokal auf einem mobilen Endgerät ([X.]) zu speichern ([X.], Absatz [0007]). Dadurch wird es beispielsweise einem Nutzer eines Empfangsgeräts ermöglicht, versäumte Nachrichten zu einem späteren [X.]punkt abzuspielen ([X.], Absatz [0008]). Es können somit Nachrichten mit [X.]versatz ausgetauscht werden.

Im Hinblick auf den geltenden Verfahrensanspruch 1 geht aus der [X.]/[X.] hervor:

[X.] Medienübertragungsverfahren für ein Übertragen mit einer ersten Übertragungsvorrichtung über ein Übertragungsnetz

[X.]/[X.] beschreibt ein Mobiltelefon, das mit einer Sende-/Empfangseinrichtung ausgestattet ist, die in der Lage ist, [X.]-[X.]rachnachrichten über ein drahtloses Übertragungsnetzwerk zu senden, vgl. [X.], Abs. [0007], „In one illustrative example, a mobile Station includes a wireless transceiver which operates with a wireless communication network; a processor; [X.] coupled to the processor; and a user interface which includes a Push-To-Talk ([X.]) switch for transmitting a [X.] voice communication through the wireless transceiver […] “, Unterstreichung hinzugefügt.

[X.] fortschreitendes Kodieren, fortschreitendes und persistentes [X.]eichern auf der ersten Übertragungsvorrichtung und fortschreitendes Senden von Medien einer ausgehenden Nachricht, welche von der ersten Übertragungsvorrichtung erzeugt werden, über das Übertragungsnetz, während die Medien erzeugt werden;

Gemäß [X.]/[X.] werden, sobald ein [X.]-Schalter von einem Nutzer des Mobiltelefons gedrückt wird, von einem Mikrofon des Mobiltelefons empfangene [X.]rachsignale über das Drahtlosnetzwerk gesendet, vgl. [X.], Abs. [0060], „[X.] also include a [X.] voice communication Switch 450. […] When [X.] switch 450 is depressed by an end user , the mobile station initiates a [X.] voice communication through the wireless network. After [X.] switch 450 depression, [X.] .“, Unterstreichung hinzugefügt. Damit offenbart [X.]/[X.] ein fortschreitendes Senden von an einer Übertragungsvorrichtung ("mobile station") erzeugten Medien einer ausgehenden Nachricht ("voice signals"), während die Medien erzeugt werden.

Gemäß Abs. [0034] von [X.]/[X.] werden die zu sendenden Signale auch fortlaufend kodiert, „In a similar manner, [X.], including modulation and encoding , for example, by DSP220. These [X.] signals are input to transmitter 214 for [X.] ([X.]) conversion, [X.], filtering, [X.] via antenna 218.“, Unterstreichung hinzugefügt.

[X.]/[X.] beschreibt auch, dass die vom Mobiltelefon verschickten [X.]-Nachrichten gleichzeitig mit deren Übertragung sukzessive in einem [X.]eicher des Mobiltelefons gespeichert werden, vgl. [X.], Abs. [0053], „Memory 412 is used to store compressed voice data of received [X.] voice communications, as will be described further herein.“; vgl. Abs. [0074], „The mobile station may also save its own [X.] voice communications in its [X.] in a similar manner, in sequence along with the [X.] voice communications received through its receiver. This option provides a more complete history of [X.] voice communications stored in [X.]. In [X.], [X.]. 6 correspond to detecting [X.] button depressions and [X.] button releases, [X.], at the user interface of the mobile station. Upon [X.] button depression, the processor causes the voice data of the [X.] voice transmission to be stored in the [X.] simultaneously with its transmission .“, Unterstreichung hinzugefügt; [X.]. auch [X.], Ansprüche 1- 5.

Der [X.]eicher kann auch so groß sein, dass mehrere [X.]-[X.]rachverbindungen gespeichert werden können (vgl. [X.], Abs. [0056], „Preferably, a plurality of [X.] voice communications are consecutively saved in [X.] 412 which have corresponding pairs of start and end markers for identification and retrieval.“, Unterstreichung hinzugefügt.

Da die Daten bei [X.]/[X.] jedoch in einem Ringspeicher abgelegt und somit automatisch zyklisch überschrieben werden (vgl. [X.], Abs. [0055], „circular buffer [X.]“), handelt es sich hierbei nicht um ein „persistentes“ [X.]eichern im Sinne des [X.]s.

[X.].2 fortschreitendes Empfangen, fortschreitendes und persistentes [X.]eichern auf der ersten Übertragungsvorrichtung und [X.] von Medien einer eingehenden Nachricht, welche über das Übertragungsnetz an der ersten Übertragungsvorrichtung empfangen wird, während die Medien fortschreitend in einer Echtzeitwiedergabebetriebsart empfangen werden,

[X.]/[X.] beschreibt neben der Übertragungsfunktion auch eine Empfangsfunktion. Für den Fall, dass eine Aufnahmefunktion für das empfangende Mobiltelefon freigeschaltet ist, erfolgt ein gleichzeitiges Verarbeiten und [X.]eichern der eingehenden [X.]-[X.]rachkommunikation, vgl. [X.], Abs. [0071], „[X.], the voice data for the [X.] voice communication is received through the wireless transceiver ([X.]. 6). [X.] so that audible voice signals are heard through the speaker of the mobile station. In particular, RF signals carrying the voice data may be processed through receiver 212, channel decoder and demodulator 408, voice decompressor 406, [X.], and audio circuit 402 of FIG. 4. Advantageously, the voice data of the [X.] voice communication is also simultaneously saved in [X.] ([X.]. 6). Preferably, the circular buffer [X.] 412 of [X.]. 4-5 is utilized for the recording of the [X.] voice data as previously described.“.

Da die Daten bei [X.]/[X.] jedoch in einem Ringspeicher abgelegt und somit automatisch zyklisch überschrieben werden (vgl. [X.], Abs. [0055], „circular buffer [X.]“), handelt es sich hierbei nicht um ein „persistentes“ [X.]eichern im Sinne des [X.]s.

[X.].3.1 wobei die ausgehende Nachricht und die eingehende Nachricht asynchrone Nachrichten sind

Die bei [X.]/[X.] empfangenen Nachrichten können zeitversetzt zu versendeten Nachrichten abgespielt werden (vgl. [X.], Abs. [0054]), es handelt sich daher um asynchrone Nachrichten im Sinne des [X.]s.

[X.] welche über das Übertragungsnetz von der ersten Übertragungsvorrichtung zu der zweiten Übertragungsvorrichtung gesendet werden und über das Übertragungsnetz an der ersten Übertragungsvorrichtung von der zweiten Übertragungsvorrichtung empfangen werden, ohne zuerst eine Verbindung über das Übertragungsnetz zwischen der ersten Übertragungsvorrichtung und der zweiten Übertragungsvorrichtung einzurichten .

Gemäß [X.]/[X.] muss bei [X.] für den Nachrichtenaustausch zwischen den [X.] eine Session zwischen den beiden [X.] aufgebaut werden (vgl. [X.], Abs. [0030], „[X.], referred to as session “participants”, [X.] in a half-[X.] much like conventional walkie-talkies or two-way radios.“ oder Abs. [0044], „[X.] connection between end users of a UE 302, referred to as session "participants”, [X.] in a half [X.]. [X.] [X.] ([X.]) technology […] “).

Aus [X.]/[X.] geht somit nicht unmittelbar und eindeutig hervor, dass die gesendeten und empfangenen Nachrichten auf der ersten [X.] dauerhaft im Sinne des [X.]s gespeichert werden (Merkmale [X.] und [X.].2). Auch das Merkmal [X.], geht aus [X.]/[X.] nicht unmittelbar und eindeutig hervor, denn gemäß [X.]/[X.] muss bei einem Nachrichtenaustausch zwischen den [X.] immer zuerst eine Verbindung (Session) über das Übertragungsnetz zwischen den beiden [X.]en eingerichtet werden.

2.1.2 [X.] ist auch neu gegenüber dem Stand der Technik nach der Druckschrift [X.] - [X.] 2006/0085515 [X.] („[X.]“). Insbesondere, dass – entsprechend der Lehre des [X.]s - ein Übertragen oder Empfangen von Nachrichten auf dem ersten Endgerät beginnen kann, ohne dass zunächst eine Verbindung zwischen den Übertragungsvorrichtungen hergestellt wird, kann der [X.]/[X.] nach Überzeugung des [X.]s weder unmittelbar noch implizit entnommen werden.

[X.]/[X.] betrifft allgemein eine [X.] Anwendung, die Audio/Video Sessions in Echtzeit zwischen Kommunikationspartnern auf zwei Computern ermöglicht. Insbesondere beschreibt [X.] einen [X.] Client mit einer grafischen Benutzeroberfläche ([X.]), die eine Vielzahl von erweiterten Nutzeroptionen und -features für [X.]/[X.] bereitstellt (vgl. [X.], Abs. [0052] bis [0053]). Ausdrücklich beschrieben werden auch die vom [X.] zentral in den Blick genommenen Möglichkeiten des Nutzers, auf die Nachrichten zu einem späteren [X.]punkt zugreifen und diese verwalten zu können (vgl. [X.], Abs. [0064] ff.).

[X.]/[X.] beschreibt weiterhin, dass diese Nutzeroptionen eine Vielzahl von sogenannten "personal video recorder" (PVR-)Funktionen ermöglichen (vgl. [X.], [X.]. 10). Dabei entsprechen die unterhalb der [X.] (1001) der beiden Kommunikationspartner der Echtzeit-[X.]ession angezeigten Symbole bzw. der Schieberegler (1010-1014) den PVR (Personal Video [X.]. Dadurch ist es einem Teilnehmer, beispielsweise durch Zurückspulen (1012) möglich, von einer Echtzeit-[X.]ession in einen bereits in der Vergangenheit liegenden Teil der [X.]ession zu wechseln und diesen Teil anschließend zeitversetzt zur Echtzeit-[X.]ession anzusehen. Diese (lokalen) Videorekorderfunktionen ermöglichen somit ein Hin- und Herwechseln zwischen einer Echtzeit-[X.]ession und einer zeitversetzten Wiedergabe der [X.]ession (vgl. [X.], Abs. [0055] bis [0056]).

Im Hinblick auf den geltenden [X.] geht aus der [X.]/[X.] hervor:

[X.] Medienübertragungsverfahren für ein Übertragen mit einer ersten Übertragungsvorrichtung über ein Übertragungsnetz

[X.]/[X.] beschreibt einen auf einem Computer befindlichen [X.] Client, über den [X.]/[X.]essions mit einem weiteren Computer durchgeführt werden können (vgl. [X.], Abs. [0052]).

[X.] fortschreitendes Kodieren, fortschreitendes und persistentes [X.]eichern auf der ersten Übertragungsvorrichtung und fortschreitendes Senden von Medien einer ausgehenden Nachricht, welche von der ersten Übertragungsvorrichtung erzeugt werden, über das Übertragungsnetz, während die Medien erzeugt werden;

[X.]/[X.] beschreibt, dass die beiden Computer, mit denen die [X.]/[X.] durchgeführt wird, mit einer Videokamera und einem Mikrofon ausgestattet sind (vgl. [X.], Abs. [0052]). Das fortschreitende Kodieren wird dabei in Abs. [0054] beschrieben, „Various well known video compression codecs may be employed on the system to encode/ decode video. These include, but are not limited to the MPEG-2 (or “Motion Picture Experts Group-2”), [X.], [X.], and Audio Video Interleaved [X.]”) to name a few.“.

Gemäß [X.]/[X.] werden während einer Audio/[X.] die Audio- bzw. [X.] automatisch gepuffert (vgl. [X.], Abs. [0056]). Die [X.]eicherung erfolgt entweder in einem [X.] oder auf einer Festplatte (vgl. [X.], Abs. [0055]). Darüber hinaus offenbart [X.]/[X.] in Absatz [0060], dass die entsprechend erfassten Videodaten auch über den [X.]raum der Live-Übertragung hinaus und dauerhaft auf der lokalen Festplatte (und damit auf einem nichtflüchtigen [X.]eichermedium) gespeichert und später an [X.] übertragen werden können, womit ein fortschreitendes und persistentes [X.]eichern auf der ersten Übertragungsvorrichtung unmittelbar aus [X.]/[X.] hervorgeht.

Wie in Absatz [0053] in [X.]/[X.] beschrieben, enthält das Videofenster des [X.] die Möglichkeit, den Live-[X.]trom des lokalen Nutzers sowie den des "buddys", sprich einem weiteren (entfernten) [X.], darzustellen. Somit werden die Medien (wie es bei einer Echtzeit-[X.]ession zwischen zwei Nutzern zwingend der Fall ist) während des Erzeugens - und damit fortschreitend - in Form eines ausgehenden [X.] über das Netzwerk gesendet.

[X.].2 fortschreitendes Empfangen, fortschreitendes und persistentes [X.]eichern auf der ersten Übertragungsvorrichtung und [X.] von Medien einer eingehenden Nachricht, welche über das Übertragungsnetz an der ersten Übertragungsvorrichtung empfangen wird, während die Medien fortschreitend in einer Echtzeitwiedergabebetriebsart empfangen werden,

[X.]/[X.] beschreibt das Durchführen einer Echtzeit-[X.]ession auf einem Computer mit entsprechendem [X.]. Explizit beschreibt [X.]/[X.] in Absatz [0053], dass dabei auch Videodaten von einem entfernten Teilnehmer ("buddy") in dem Videofenster der [X.]-[X.] dargestellt werden.

Somit offenbart [X.]/[X.] den Prozess des Empfangens und [X.] des (von anderen Teilnehmergeräten kommenden) Video- und Audiostroms während einer Echtzeit-[X.]ession. Da die Vorgänge des Empfangens und [X.] von Videodaten während einer Echtzeit-[X.]ession zwischen zwei Nutzern stattfinden, folgt zwingend, dass die empfangenen Medien fortschreitend in einer Echtzeitwiedergabebetriebsart gerendert werden.

[X.]/[X.] offenbart in den Absätzen [0055] und [0056] auch, dass die [X.]essiondaten, die schrittweise empfangen und gerendert werden, lokal gespeichert werden können mit dem Zweck, die bereits gespeicherten Daten erneut wiedergeben zu können. Zudem offenbart [X.]/[X.] auch, dass die unter Verwendung der [X.] erfassten Videodaten auch zum späteren Übertragen an andere [X.] auf der lokalen Festplatte gespeichert werden können (vgl. [X.], Abs. [0060]).

[X.].3.1 wobei die ausgehende Nachricht und die eingehende Nachricht asynchrone Nachrichten sind

Auch bei [X.]/[X.] können die eingehenden Nachrichten zeitversetzt zu ausgehenden Nachrichten wiedergegeben werden (vgl. [X.], Abs. [0055], [0056]). Es handelt sich mithin um asynchrone Nachrichten im Sinne des [X.]s.

[X.] welche über das Übertragungsnetz von der ersten Übertragungsvorrichtung zu der zweiten Übertragungsvorrichtung gesendet werden und über das Übertragungsnetz an der ersten Übertragungsvorrichtung von der zweiten Übertragungsvorrichtung empfangen werden, ohne zuerst eine Verbindung über das Übertragungsnetz zwischen der ersten Übertragungsvorrichtung und der zweiten Übertragungsvorrichtung einzurichten .

Gemäß [X.]/[X.] kann eine Kommunikation zwischen den [X.] nur stattfinden, wenn sich beide Endgeräte zuvor am System angemeldet haben und eine Verbindung zwischen den [X.] hergestellt wurde (vgl. [X.], Abs. [0012], „[X.], [X.].” The user may then click on a name of any contact in the buddy list who is online, opening an [X.] in which the user may enter an instant message.“ und Abs. [0013], „[X.], all subsequent communication may occur directly between the two clients,[…]“; vgl. auch [X.], [X.]. 1).

In den Absätzen [0011] und [0012] der [X.]/[X.] ist der für den Austausch von Nachrichten erforderliche Verbindungsaufbau näher beschrieben. Danach senden die Endgeräte Verbindungsinformationen (z.B. die IP-Adresse) an den [X.]-Dienst, der diese Informationen mit der Kontaktliste des Benutzers abgleicht und dann die Verbindungsdaten der Endgeräte der Kontakte des Benutzers zurück an dessen Endgerät schickt. Über diese Verbindungsinformationen können dann die in [X.], [X.]ur 1 gezeigten direkten Verbindungen zwischen den [X.] hergestellt werden, über die diese dann Nachrichten austauschen.

Zwar kann es gemäß [X.]/[X.] sein, dass eine direkte Kommunikation zwischen den beiden [X.] nicht möglich ist, z.B. wegen einer Firewall, und die Kommunikation über den „messaging service 100“ laufen muss (vgl. [X.], Abs. [0013], 2. Satz). Nach Auffassung des [X.]s besagt dies jedoch lediglich, dass in manchen Fällen die Daten einer Session nicht unmittelbar zwischen den Teilnehmern ausgetauscht werden können, sondern über einen Server geleitet werden müssen, wenn etwa eine Firewall zwischen den Teilnehmern liegt. Dies setzt aber dennoch voraus, dass zuerst eine Session zwischen den [X.] über das Übertragungsnetzwerk eingerichtet und somit eine Verbindung zwischen den [X.] aufgebaut wird, auch wenn diese über das Übertragungsnetzwerk bzw. einen Server vermittelt wird. Damit kann mit der Übertragung der Nachrichten immer erst begonnen werden, wenn eine Verbindung über das Übertragungsnetz zwischen der ersten [X.] und der zweiten [X.] eingerichtet ist.

2.1.3 [X.] ist auch neu gegenüber dem Stand der Technik nach der Druckschrift [X.] - WO 2006/121550 [X.] („[X.]“); insbesondere geht aus [X.]/[X.] das Merkmal [X.] nach [X.] nicht hervor.

Die Druckschrift [X.]/[X.] betrifft ein Verfahren zum Archivieren von Daten, die während einer Session innerhalb eines Drahtlosübertragungsnetzwerks anfallen ([X.], Titel, Abs. [0002]). Unter einer Session versteht [X.]/[X.] einen Verbund zwischen zwei oder mehr Benutzern und/oder Entitäten, der es den Benutzern und/oder Entitäten ermöglicht, Daten auszutauschen (vgl. [X.], Abs. [0027], „[X.], a session is an association between two or more users and/or entities that enables the users and/or entities to exchange data.“Unterstreichung und Fettschrift hinzugefügt).

Als Applikationen, über die die Nutzer Daten austauschen können, nennt [X.] /[X.] beispielsweise „[X.] ([X.]), Push-to-Talk ([X.]), Push-to-talk [X.] ([X.]), and so on.“ (vgl. Abs. [0024]) und Abs. [0026], „[X.] 110 may communicate via a communication network with application server 160 for any application (e.g., [X.]) [X.].“).

Bei den während einer Session ausgetauschten Daten kann es sich um Video-, [X.]rach- oder auch andere Medienarten handeln (vgl. [X.], Abs. [0020]).

Gemäß [X.]/[X.] soll erreicht werden, dass der Nutzer eines Terminals/Endgeräts (z.B. ein Mobiltelefon ([X.], Absatz [0020])) während oder auch nach Beendigung der Session auf die während der Session angefallenen Daten (vollständig bzw. teilweise) zurückgreifen kann (vgl. [X.], Absätze [0005] und [0006]).

In [X.]/[X.] ist stets der Aufbau einer Session zwischen der ersten der zweiten [X.] erforderlich, um Daten austauschen zu können (vgl. [X.], Abs. [0027], „[X.] in a session. [X.], a session is an [X.] data.“).

Somit geht aus [X.]/[X.] das Merkmal [X.] nicht hervor.

2.1.4 [X.] ist zur Überzeugung des [X.]s auch neu gegenüber dem Stand der Technik nach der Druckschrift [X.] - [X.] 2004/0119814 [X.] („[X.]“), denn aus [X.]/[X.] gehen die Merkmale [X.].3.1 und [X.] nach [X.] nicht hervor.

Die Druckschrift [X.]/[X.] beschreibt ein Kommunikationsverfahren, bei dem eine Videokonferenz zwischen mehreren tragbaren Geräten ermöglicht wird (vgl. [X.], Abs. [0008]).

[X.]/[X.] möchte sich unter anderem zu Videokonferenzanwendungen abgrenzen, die auf Telefonsystemen mit geringer Bandbreite basieren (vgl. [X.], Abs. [0004] und [0006]). Daher schlägt [X.]/[X.] ein System bestehend aus Servern vor, die innerhalb eines Hochgeschwindigkeitskommunikationsnetzwerks den Datenaustausch zwischen den (Client-)Geräten steuern (vgl. [X.]/[X.], Abs. [0005] und [0009]).

Dass die Medien in [X.]/[X.] von eingehenden Nachrichten gegenüber Medien von ausgehenden Nachrichten zeitversetzt („time shifted“) wiedergegeben werden können, kann der [X.]/[X.] nicht entnommen werden (nicht Merkmal [X.].3.1).

Zudem beschreibt [X.]/[X.], dass vor der Kommunikation zunächst ein Call Request gesendet wird, der von der empfangenden Kommunikationsvorrichtung angenommen werden muss. Erst wenn dieser Call Request akzeptiert wurde, kann die Videokonferenz beginnen (vgl. [X.], Abs. [0112]).

Dies bedeutet aus fachmännischer Sicht, dass eine Kommunikation zwischen den beiden [X.] erst dann erfolgen kann, wenn eine Verbindung zwischen diesen besteht. Dies wird auch in [X.]ur 4 der [X.]/[X.] illustriert (dort: „Start/Abort Session“) (nicht Merkmal [X.]).

Soweit die Klägerin meint, dass der [X.]erver ein sogenanntes "multicast" durchführe und [X.]/[X.] somit offenbare, dass der [X.]trom nicht direkt von einer ersten [X.] an eine zweite [X.] gesendet wird, sondern in einem ersten Übertragungsvorgang von der ersten [X.] zu einem Server und in einem zweiten Übertragungsvorgang von dem Server zur zweiten [X.] und es entsprechend vor Beginn der Übertragung keiner Verbindung zwischen der ersten und der zweiten [X.] bedürfe, kann sich der [X.] nicht anschließen, denn es muss immer zuerst eine Verbindung zwischen den [X.], z.B. auch über einen Server, hergestellt werden.

2.1.5 Dass der Gegenstand des erteilten Patentanspruchs 1 aus einer der weiteren im Verfahren befindlichen Druckschriften neuheitsschädlich vorweggenommen sei, hat weder die Klägerin behauptet noch ist dies für den [X.] ersichtlich.

2.2 Zur erfinderischen Tätigkeit

Das Verfahren des Anspruchs 1 nach [X.] beruht auch auf einer erfinderischen Tätigkeit im Sinne des Art. 56 EPÜ, da es sich für den Fachmann nicht in naheliegender Weise aus dem entgegengehaltenen Stand der Technik ergibt.

Ausgehend vom Stand der Technik nach einer der Druckschriften [X.], [X.] oder [X.] gelangt der Fachmann nicht in naheliegender Weise zum Verfahren des erteilten Anspruchs 1.

2.2.1 [X.] Tätigkeit ausgehend von der Druckschrift [X.] - [X.] 2002/0073205 [X.] („[X.]“)

Die Druckschrift [X.]/[X.] betrifft allgemein Übertragungsdienste (vgl. [X.], Titel: "communication service"). Insbesondere schlägt [X.]/[X.] eine [X.] im Rahmen von [X.] ([X.]) vor (vgl. [X.], Abs. [0001]).

Gemäß [X.]/[X.] ermöglicht die vorbekannte Implementierung von [X.] das Senden von Multimedianachrichten zwischen mehreren Nutzern von Mobilgeräten. Dabei wird eine Nachricht (wie im [X.]-Standard 3GPP 23.140 vorgeschlagen) nach Erzeugung zunächst an einen Server ("[X.] Centre") gesendet. Von dort kann die Nachricht auf ein Empfangsendgerät heruntergeladen werden. Sobald die Nachricht vollständig ("as a whole") heruntergeladen und auf dem Endgerät gespeichert ist, kann diese wiedergegeben werden. (vgl. [X.], Abs. [0008]). Das bekannte [X.]-Verfahren hat gemäß der [X.] den Nachteil, dass das empfangende Endgerät die Multimedianachricht speichern muss, bevor sie dem Benutzer präsentiert werden kann. Daher legt die Größe des [X.]eichers des empfangenden Endgeräts eine Obergrenze für die Größe von [X.] fest, die heruntergeladen werden können (vgl. [X.], Abs. [0010]).

Abgesehen von [X.] seien „Streaming“-Technologien bekannt, die eine „streaming session“ zwischen Sender und Empfänger voraussetzten, aber noch nicht für den Empfang über [X.] angepasst seien, bzw. [X.] unterstützten diese nicht und seien inkompatibel mit [X.] (vgl. [X.], Abs. [0011] bis [0013]).

Vor diesem Hintergrund schlägt [X.]/[X.] die Ergänzung des [X.]-Standards um eine Streaming-Erweiterung vor. Diese beinhaltet drei Phasen, Phase 1, „Media upload“, Phase 2, „[X.] notification“ und Phase 3, „Media download“ (vgl. [X.], Abs. [0096] in Verbindung mit [X.]. 2):

In Phase 1 wird [X.] von einem Sendeendgerät ("sending mobile terminal") an einen Medienserver ("Media (streaming) server") übertragen. Dazu richtet der Sender 21 eine [X.] mit dem „media (streaming) server“ ein, der den [X.] in einem vordefinierten [X.]eicherbereich speichert (vgl. [X.], Abs. [0103]). In der zweiten Phase („phase 2“) werden ein oder mehrere Empfänger („receiving terminals“) darüber benachrichtigt, dass [X.] zur Lieferung verfügbar ist. Vorzugsweise erfolgt die Benachrichtigung („notification“) über eine „notification message“, die vom Sender über einen [X.]-Server mittels „store-and-forward“ (vgl. [X.], Abs. [0098]) an den/die Empfänger gesendet wird (vgl. [X.], Abs. [0096], „the [X.] server stores the notification message and then tries to forward it to the receiver.“). Die Benachrichtigung enthält keine Mediendaten sondern Informationen, die erforderlich sind, um nachgelagert eine weitere Streaming-Sitzung zwischen dem Empfänger 24 und dem [X.] einzurichten, wie beispielsweise die Netzwerkadresse des Medienservers, das/die zum Codieren des [X.]s verwendete(n) Codierungsverfahren und die Angabe des/der für das Herunterladen von Medien zu verwendenden [X.](e) (vgl. [X.], Abs. [0104]).

In der dritten Phase („phase 3“), der [X.], baut das Empfangsgerät 24 eine [X.] mit dem [X.] basierend auf den in der [X.] empfangenen Informationen auf und das Empfangsgerät 24 beginnt, die Medien herunterzuladen und abzuspielen (vgl. [X.], Abs. [0105], „[X.], [X.] establishes a streaming session with the media server 22, [X.] in the notification message and [X.] starts to download and play the media .“; und Abs. [0118], „In [X.], [X.], extracting information relating to the location of media content to be streamed and information necessary to form streaming sessions to retrieve the media content .“; Unterstreichungen jeweils hinzugefügt).

Gemäß der Druckschrift [X.] werden die Medien der einzelnen Nachrichten für diesen Fall nicht lokal auf den [X.] gespeichert, sondern ausschließlich auf dem Medienserver.

Im Hinblick auf den geltenden Patentanspruch 1 geht aus [X.]/[X.] hervor:

[X.] Medienübertragungsverfahren für ein Übertragen mit einer ersten Übertragungsvorrichtung über ein Übertragungsnetz

[X.]/[X.] beschreibt ein Übertragungsverfahren, bei dem ein [X.] von einem Sendeendgerät an einen im mobilen Übertragungsnetzwerk befindlichen Medienserver übertragen wird (vgl. [X.], Abs. [0096] und [0106]), [X.]. 2)

[X.] fortschreitendes Kodieren, fortschreitendes und persistentes [X.]eichern auf der ersten Übertragungsvorrichtung und fortschreitendes Senden von Medien einer ausgehenden Nachricht, welche von der ersten Übertragungsvorrichtung erzeugt werden, über das Übertragungsnetz, während die Medien erzeugt werden;

In Phase 1 baut der Sender 21 eine „streaming session“ zum Medienserver auf und der [X.] wird von dem Sendeendgerät ("sending terminal") an den Server ("media streaming server") übertragen und dort gespeichert (vgl. [X.], Abs. [0103]). Entsprechend werden die Medien bei [X.]/[X.] fortschreitend gesendet.

[X.]/[X.] beschreibt weiterhin, dass es sich bei den gestreamten Medien um Audio- bzw. Videodaten handeln kann, die von einer Videokamera und einem Mikrofon erzeugt werden (vgl. [X.], Abs. [0102]). Diese unmittelbar nach Erzeugung gestreamten [X.]e werden fortschreitend kodiert (vgl. [X.], Abs. [0104]).

Ein persistentes [X.]eichern auf dem Kommunikationsgerät geht nicht aus [X.]/[X.] hervor.

[X.].2 fortschreitendes Empfangen, fortschreitendes und persistentes [X.]eichern auf der ersten Übertragungsvorrichtung und [X.] von Medien einer eingehenden Nachricht, welche über das Übertragungsnetz an der ersten Übertragungsvorrichtung empfangen wird, während die Medien fortschreitend in einer Echtzeitwiedergabebetriebsart empfangen werden,

Die Endgeräte 21 und 24 sind gemäß der [X.] ähnliche Geräte, die je nach ihrer Rolle als Sender oder Empfänger auftreten, d.h. jedes Gerät kann sowohl empfangen als auch senden (vgl. [X.], Abs. [0102], „Typically, the sender 21 and [X.] are similar devices, one of them being the sender 21 and another of the being [X.] just because of their roles as sending and receiving parties (sender and recipient).“).

In Phase 3 baut der Empfänger eine „streaming session“ mit dem [X.] auf und beginnt, die Medien herunterzuladen und abzuspielen (vgl. [X.], Abs. [0105]).

Somit offenbart [X.]/[X.] ein fortschreitendes Empfangen ("streaming session") und [X.] ("play the media") von Medien einer eingehenden Nachricht ("media") auf der ersten [X.], die über das Übertragungsnetz an dem empfangenden Endgerät ("receiver") empfangen wird.

Ein [X.]eichern dieser empfangenen Medien ist in [X.]/[X.] nicht vorgesehen.

[X.].3.1 wobei die ausgehende Nachricht und die eingehende Nachricht asynchrone Nachrichten sind

Das Abrufen der Medien vom Medienserver zum Empfänger in Phase 3 kann entweder automatisch nach dem Empfang der Benachrichtigung aus Phase 2 oder später durch den Nutzer gestartet werden (vgl. [X.], Abs. [0098]). Nachrichten von eingehenden/empfangenen Medien können somit gegenüber Nachrichten von ausgehenden/gesendeten Medien zeitversetzt („time shifted“) wiedergegeben werden. Es handelt sich mithin um asynchrone Nachrichten im Sinne des [X.]s.

[X.] welche über das Übertragungsnetz von der ersten Übertragungsvorrichtung zu der zweiten Übertragungsvorrichtung gesendet werden und über das Übertragungsnetz an der ersten Übertragungsvorrichtung von der zweiten Übertragungsvorrichtung empfangen werden, ohne zuerst eine Verbindung über das Übertragungsnetz zwischen der ersten Übertragungsvorrichtung und der zweiten Übertragungsvorrichtung einzurichten.

Gemäß [X.]/[X.] werden die Nachrichten mit [X.] in Phase 1 vom [X.] (der ersten [X.]) nach Aufbau einer „Streaming Session“, d.h. aus fachmännischer Sicht dem Aufbau einer Verbindung auf der Sitzungsschicht des [X.], zum [X.] gesendet und dort gespeichert. Bei dem Medienserver handelt es sich jedoch nicht um eine zweite [X.] im Sinne des [X.]s, sondern um einen Server mit [X.]eicherfunktionalität im Übertragungsnetzwerk.

Gemäß [X.]/[X.] wird in Phase 3 unter Nutzung der in der Benachrichtigung aus Phase 2 enthaltenen Informationen (z.B. Netzwerkadresse des Medienservers) vom Empfangsgerät (der ersten [X.]) eine „Streaming Session“ mit dem [X.] aufgebaut und daraufhin die Medien innerhalb dieser Sitzung vom Medienserver heruntergeladen und abgespielt, d.h. die Nachrichten werden in einem Empfangsgerät vom Medienserver empfangen und nicht von einer zweiten [X.] im Sinne des [X.]s (vgl. [X.], Abs. [0105], „[X.], [X.] establishes a streaming session with the media server 22, [X.] in the notification message and [X.] starts to download and play the media .“; und Abs. [0118], „In [X.], [X.], extracting information relating to the location of media content to be streamed and information necessary to form streaming sessions to retrieve the media content .“; Unterstreichungen jeweils hinzugefügt).

In der [X.]/[X.] fehlt somit jegliche anspruchsgemäße Ende-zu-Ende Übertragung von Nachrichten mit [X.]en von einer ersten/zweiten zu einer zweiten/ersten [X.].

Damit unterscheidet sich die Lehre der [X.]/[X.] grundsätzlich von der Lehre des [X.]s, denn gemäß [X.] werden bei einem dort ggf. im Übertragungsweg vorgesehenen Server die von der ersten [X.] gesendeten Nachrichten zwar auch im Server zwischengespeichert, diese dann aber vom Server direkt und ohne einen separaten Download-Schritt an die zweiten [X.]en geroutet bzw. weitergeleitet (vgl. [X.], Abs. [0087], „[X.] 12. [X.], they are stored in [X.] 85 and transmitted to the next Server 16 (i.e., the net "hop") of the network layer 14 along the path to the intended recipient(s), or to the recipient(s) directly depending on the system configuration.“, vgl. Abs. [0109], „The [X.] Reader 26 on the Client 12 ₁ reads the payloads out of [X.] 30, creates Vox packets, and transmits the packets to the receiving Client 12 ₂ ([X.]) over the network 18. Each Server 16 along the path between the sending Client 12 ₁ and the receiving Client 12 ₂ stores the transmitted payloads in [X.] 85 and transmits the Vox packets to the next hop (box 133)“.

Eine Verbindung auf irgendeinem Layer unterhalb der Applikationsschicht ist gemäß [X.] dazu nicht erforderlich.

Zwar umfasst die [X.]/[X.] in der Phase 2 eine Ende-zu-Ende Übertragung der Benachrichtigung („notification“) mittels „store and forward“ durch den [X.] Server, die Benachrichtigung übermittelt jedoch keinerlei [X.]e. Darüber hinaus betrifft das „store and forward“ der Benachrichtigung als Routing-Verfahren den [X.]. Es kann daher völlig dahingestellt bleiben, ob die Benachrichtigung Ende-zu-Ende übertragen wird, zumal die [X.]/[X.] hinsichtlich des dafür verwendeten [X.]s (Layer 4) sowie einer potentiellen Verbindung auf dem [X.] (Layer 5) schweigt.

Somit geht in Bezug auf den geltenden Patentanspruch 1 aus [X.]/[X.]

a) das Merkmal [X.] nicht unmittelbar und eindeutig hervor, und

b) die gesendeten und empfangenen Nachrichten werden nicht dauerhaft im Sinne des [X.]s in der ersten [X.] gespeichert, so dass auch die Merkmale [X.] und [X.].2 fehlen.

Zu a) Der [X.]/[X.] entnimmt der Fachmann aus Sicht des [X.]s keinerlei Anregung, die gestreamten Medien vom ersten Kommunikationsteilnehmer bzw. von der ersten Übertragungsvorrichtung statt an den Medienserver an den zweiten Kommunikationsteilnehmer bzw. an die zweite Übertragungsvorrichtung zu senden. Soweit die Klägerin der Ansicht ist, dass die vom [X.] verwendete Auslegung zu eng sei, wird auf die obigen Ausführungen zum Verständnis des Fachmanns unter [X.] 4 zu Merkmal [X.] verwiesen.

Zu b) Die Ansicht der Klägerin, aufgrund der auf Gigabytegröße gestiegenen lokalen [X.]eicherkapazität mobiler Endgeräte, die zum Prioritätszeitpunkt der [X.]/[X.] noch nicht verfügbar gewesen sei, würde sich die in [X.]/[X.] angesprochene Problematik fehlender [X.]eicherkapazität zum Prioritätszeitpunkt des [X.]s nicht mehr stellen und der Fachmann hätte daher auch für das in [X.]/[X.] beschriebene Streaming von Medien ein persistentes [X.]eichern auf den beiden Endgeräten vorgesehen, vermag der [X.] nicht zu teilen.

Denn in der [X.]/[X.] sind bereits Endgeräte mit [X.]eichern in Gigabytegröße in Form von Laptops offenbart, wobei auch schon für diese nach [X.]/[X.] keine lokale persistente [X.]eicherung der ein- und ausgehenden Medien vorgesehen ist (vgl. [X.], Abs. [0126]). Aus [X.]/[X.] erhält der Fachmann keinen Hinweis oder Anregung dahingehend, dass es bei diesen Laptops aufgrund der höheren [X.]eicherkapazität vorteilhaft sein könnte, die Medien der ein- und ausgehenden Nachrichten persistent zu speichern. Im Gegenteil, [X.]/[X.] beschäftigt sich sogar ausdrücklich mit E-Mail-Kommunikation mit großen Mediendateien unter Verwendung von [X.] und mobilen [X.] und stellt auch dort das lokale [X.]eichern dieser großen Mediendateien als nachteilig dar (vgl. [X.], Abs. [0007]).

Zudem konnte die Klägerin auch nicht überzeugend darlegen, dass die zum Prioritätszeitpunkt gängigen Mobiltelefone über mehrere Gigabyte große [X.]eicher verfügten. Das von der Klägerin zum Fachwissen aufgeführte Mobiltelefon [X.] in der ersten Version verfügt zwar über einen größeren internen [X.]eicher (Memory internal 4/8/16 GB) als der in der [X.]/[X.] genannte [X.] (2 MB user data storage), bei dem [X.] handelt es sich aber nicht um ein zum [X.] des [X.]s gängiges Mobiltelefon, sondern um eine neue Kategorie von Mobiltelefonen, welche erst kurz vor dem [X.] auf den Markt gekommen sind (vgl. [X.], [X.], „Released 2007, June“).

Der Fachmann hatte daher ausgehend von [X.]/[X.] weder eine Veranlassung, ein persistentes [X.]eichern von eingehenden/ausgehenden Nachrichten (Mediendateien) auf der [X.] vorzusehen, noch eine Veranlassung, Nachrichten (Mediendateien) über das Übertragungsnetz von der ersten [X.] zu der zweiten [X.] zu senden bzw. zu empfangen, ohne zuvor eine Verbindung im Sinne des [X.]s einzurichten. Somit würde der Fachmann ausgehend von [X.]/[X.] nicht in naheliegender Weise zu dem Verfahren nach Patentanspruch 1 gelangen.

Bei dieser Sachlage kommt es auch nicht mehr darauf an, ob für die [X.] „store-and-forward“ Übermittlung der Benachrichtigung („notification“) mittels „notification message“ vom Sender über einen [X.]-Server an den/die Empfänger in Phase 2 der Lehre der [X.]/[X.] ggf. eine Verbindung im Sinne des [X.]s auf den darüber liegenden [X.] (Layer 4) oder [X.] (Layer 5) erforderlich ist.

2.2.2 [X.] Tätigkeit ausgehend von [X.] - [X.] 2006/0003740 [X.] („[X.]“) in Verbindung mit [X.] bzw. [X.]0

Wie bei der Prüfung der Frage der Neuheit ausgeführt, geht aus [X.]/[X.] nicht unmittelbar und eindeutig hervor, dass

a) die gesendeten und empfangenen Nachrichten auf der ersten [X.] im Sinne des [X.]s persistent (dauerhaft) gespeichert werden (Merkmale [X.] und [X.].2), und

b) Nachrichten über das Übertragungsnetz von der ersten [X.] zu der zweiten [X.] gesendet werden und über das Übertragungsnetz an der ersten Übertragungsvorrichtung von der zweiten Übertragungsvorrichtung empfangen werden, ohne zuerst eine Verbindung über das Übertragungsnetz zwischen der ersten Übertragungsvorrichtung und der zweiten Übertragungsvorrichtung einzurichten (Merkmal [X.]).

zu a) Gemäß der [X.]/[X.] werden nicht nur eine Vielzahl von eingehenden Nachrichten, sondern auch eine Vielzahl von ausgehenden Nachrichten – und somit ein umfassender Nachrichten-Verlauf - in einem [X.]eicher 412 abgelegt (vgl. [X.]/[X.], Abs. [0056] und [0074]), wobei somit also eine [X.]eicherung diverser Nachrichten und Konversationen bereits vorgesehen ist. Dies wird insbesondere auch durch das in [X.]/[X.] beschriebene „scroll wheel 812“ bekräftigt, mit welchem der Nutzer durch die Vielzahl von aufgezeichneten Nachrichten navigieren kann (vgl. [X.]/[X.], Abs. [0063] ff.). Bei den in [X.]/[X.] vorgesehenen [X.]eichern kann es sich sowohl um volatile (vgl. Abs. [0022] für das Betriebssystem) oder nicht-volatile (vgl. Abs. [0025] und S. 4, Abs. [0035]) [X.]eicher handeln.Ob der [X.] auf einem volatilen oder nicht-volatilen [X.]eicher abgelegt ist, lässt [X.]/[X.] offen; in den entsprechenden Textstellen wird lediglich von einem [X.]eicher (vgl. Abs. [0055], „[X.] 412“) gesprochen.

Zwar wird in dem Ausführungsbeispiel der [X.]ur 5 in Verbindung mit Absatz [0055] ein Ring-[X.]eicher („circular buffer [X.]“) für das [X.]eichern des [X.]s beschrieben, bei dem Nachrichten nach einer bestimmten [X.] überschrieben werden, allerdings ist [X.]/[X.] darauf jedoch nicht beschränkt. Anspruch 1 der [X.]/[X.] spricht ganz allgemein von einem [X.]eicher (vgl. [X.], Anspruch 1, „[…] causing the voice data of the [X.] voice communication to be recorded in [X.] of the mobile station based on receiving the [X.] key message“; vgl. Abs. [0070], „Preferably, [X.] 412 of [X.]. 4-5 is utilized.“). Erst mit [X.] wird dieser [X.]eicher auf einen Ringspeicher beschränkt.

Der Fachmann hat deshalb Anlass, sich Gedanken über die Art und Weise der [X.]eicherung zu machen. Er würde sie zudem in jedem Fall derart ausgestalten, dass der Nutzer stets – also auch nach einem Aus- und Einschalten der Kommunikationsvorrichtung – auf die vollständige Konversation zugreifen kann und deshalb vorzugsweise einen nicht-volatilen [X.]eicher verwenden, in dem der komplette [X.] persistent im Sinne des [X.]s (dauerhaft) gespeichert wird. Einer erfinderischen Tätigkeit bedarf es zu diesem Merkmal nicht.

zu b) Die Ansicht der Klägerin, dass das Merkmal [X.] durch den Verweis in [X.]/[X.] auf den PoC-Standard (vgl. [X.], Abs. [0050]) durch die Druckschriften [X.] bzw. [X.]0 nahegelegt sei, vermag der [X.] nicht zu teilen.

Der PoC-Standard gemäß [X.] besagt für den Fall, dass der Empfänger registriert ist und die automatische Antwortfunktion verwendet ("Automatic Answer Mode"), dass das Sendegerät (in Folge eines [X.]) eine Antwort ("[X.]") vom [X.] erhält. Diese "[X.]" Antwort bedeutet, dass das Empfangsgerät (noch) nicht Teil der [X.] ist. Der PoC-Standard sieht dann vor, dass das Sendegerät nach Erhalt der besagten Antwort bereits proaktiv Medien an den [X.] losschicken kann. Diese werden am [X.] gepuffert, bis eine Verbindung bzw. Session zum eingeladenen Empfangsgerät steht, vgl. [X.], [X.] und 6 in Verbindung mit [X.]ur 13:

Anders formuliert ermöglicht diese PoC-Funktionalität ("Automatic Answer Mode") ein Senden von Medien von einem ersten Kommunikationsgerät zum [X.], wobei dieser die Medien zwischenspeichert und erst dann an das zweite Kommunikationsgerät weiterleitet, sobald dieses in der [X.] verbunden ist. Es kann also bereits gesendet werden, ohne zunächst auf eine vollständig eingerichtete Verbindung im Sinne des [X.]s zu warten, um so etwaige Verzögerungszeiten beim Aufbau der [X.] zumindest teilweise zu kompensieren.

Ein Empfangen von Medien am ersten Kommunikationsgerät vom zweiten Kommunikationsgerät, ohne dass zuvor eine Verbindung aufgebaut wird, ist der [X.] jedoch nicht zu entnehmen. Da der [X.] unidirektional ist, wird das erste Kommunikationsgerät Medien erst nach Übernahme der [X.]rechfunktion durch den Kommunikationspartner empfangen, wobei zu diesem [X.]punkt die [X.] dann bereits steht.

Etwas anderes hat die Klägerin auch nicht vorgetragen und soweit sie die Ansicht vertritt, das Merkmal [X.] sei durch die in Anlage [X.]0 beschriebene „Video sharing“ (vgl. [X.]0, [X.]) und die dort beschriebene [X.] (vgl. [X.]0, [X.]) nahegelegt, überzeugt dies nicht.

Auch die [X.]0 erfordert für das in Kapitel 5.1 beschriebene „Video sharing“ eine [X.] zu einem Empfänger, was bereits aus dem ersten Absatz des Abschnitts 5.1.1. hervorgeht (vgl. [X.]0, [X.], 1. Absatz). Dass der Ablauf gemäß [X.]0 an dieser Stelle ein anderer sein sollte als in [X.] beschrieben, ist der [X.]0 nicht zu entnehmen. Damit ist das Merkmal [X.] gemäß Patentanspruchs für das Senden von Medien auch durch die [X.]0 nahegelegt. Allerdings ist auch hier für den Empfang der Medien am ersten Kommunikationsgerät wiederum eine Verbindung zwischen den Kommunikationsgeräten erforderlich.

Etwas anderes ergibt sich auch nicht aus der in Kapitel 5.2 der [X.]0 beschriebenen „[X.]“ (vgl. [X.]0, [X.]). Diese stellt lediglich eine Möglichkeit für die Aufnahme von [X.]rachnachrichten in Form einer Art „Online-Anrufbeantworter“ dar, mit der sich das Sendegerät in einer Session verbinden muss, damit es eine Nachricht absenden darf (vgl. [X.]0, [X.], „[X.] Session between PoC User A and a PoC Box.“). Bei der [X.] handelt es sich aus fachmännischer Sicht um einen Server im System und nicht um das zweite Kommunikationsgerät im Sinne des [X.]s. Das erste Kommunikationsgerät sendet die Nachricht somit nicht an das zweite Kommunikationsgerät sondern an einen Server als Kommunikationspartner, wozu vorab eine Verbindung (eine „PoC-session“) erforderlich ist. Ist das zweite Kommunikationsgerät (PoC user B) wieder erreichbar, so baut der Server („PoC Service Infrastructure“) ebenfalls eine Verbindung (also eine weitere „PoC-session“) mit dem zweiten Kommunikationsgerät ([X.]) auf und sendet die aufgezeichnete [X.]rachnachricht (vgl. [X.]0, [X.] oben). Das zweite Kommunikationsgerät empfängt die Nachricht somit nicht vom ersten Kommunikationsgerät sondern vom Server.

Des Weiteren offenbart die Entgegenhaltung [X.]0 nicht, dass die von der [X.] abgerufenen Nachrichten progressiv in einem Echtzeitwiedergabemodus gemäß Merkmal [X.].2 abgespielt werden. Die Druckschrift verhält sich hierzu nicht. Es ist aus fachmännischer Sicht davon auszugehen, dass [X.] die aufgezeichneten Nachrichten zunächst vollständig herunterlädt und erst dann abspielt, da die aufgezeichnete Nachricht vollständig auf der [X.] abgelegt ist.

Da somit weder [X.] noch [X.]0 das Merkmal [X.] zeigen, ist durch eine Zusammenschau der [X.]/[X.] mit diesen Druckschriften das erteilte Verfahren gemäß Patentanspruch 1 nicht nahegelegt.

2.2.3 [X.] Tätigkeit ausgehend von der Druckschrift [X.] - [X.] 2006/0085515 [X.] („[X.]“)

Wie bereits zuvor bei der Prüfung der Frage der Neuheit ausgeführt, geht aus der [X.]/[X.] das Merkmal [X.] nicht unmittelbar und eindeutig hervor. Der Fachmann erhält aus der [X.] auch keine Anregung hierfür.

a) Soweit die Klägerin der Auffassung ist, [X.]/[X.] lege im Zusammenhang mit der [X.] bei [X.] in [X.] ([X.]) Systemen das Merkmal [X.] nahe und für den Fachmann sei es zum Prioritätszeitpunkt bereits Teil des allgemeinen Fachwissens – insbesondere in Anbetracht des [X.]s [X.] - gewesen, dass [X.]-Systeme (zusätzlich zu Live-Chats) auch das Übertragen von „[X.]“ ermöglichen würden, überzeugt nicht. Dass die [X.] dabei zeige, dass die dem Fachmann bekannten [X.]-Systeme A[X.], [X.], [X.] und [X.] Messenger zum Prioritätszeitpunkt allesamt das Übertragen von „[X.]“ ermöglichten, sieht der [X.] nicht.

Die [X.]/[X.] offenbart keine [X.] und erwähnt gerade die Übertragung von [X.]rache und Video ausschließlich im Zusammenhang mit dem Bestehen einer Online-Verbindung zwischen den Teilnehmern.

Aus fachmännischer Sicht handelt es sich bei den aus dem [X.] [X.] bekannten „[X.]“ bei [X.]-Systemen ausschließlich um [X.], die zunächst vollständig verfasst und erst nach einem Sendebefehl verschickt werden. Auf der Empfängerseite werden diese erst dann dargestellt, sobald diese vollständig erhalten wurden. Keinem der in [X.] genannten [X.] ist ein Hinweis darauf zu entnehmen, dass eine solche Funktion in Verbindung mit progressiv übertragenen bzw. empfangenen Nachrichten unterstützt würde. Zudem lässt sich weder der [X.]/[X.] noch den als [X.] [X.] vorgelegten [X.] ein Anhaltspunkt bzw. eine Anregung dafür entnehmen, dass eine Kombination dieser beiden Modi vorteilhaft wäre. Soweit die Klägerin der Ansicht ist, die progressive Übertragungsweise würde einen schnelleren Kommunikationsablauf gewährleisten, ist schon nicht ersichtlich, wieso das bei solchen [X.] mit [X.] überhaupt eine Rolle spielen sollte. Gerade bei [X.] gibt es überhaupt keinen Grund, die Übertragung zu beschleunigen, weil der Empfänger ja ohnehin nicht erreichbar ist. „Streaming“ ist in dieser Konstellation und erst recht bei [X.] unnötig und damit fernliegend.

Soweit die Klägerin außerdem auf [X.]/[X.] verweist, betrifft diese Entgegenhaltung gerade keinen [X.] Dienst, sondern den im Mobilfunk aus der [X.] weiterentwickelten [X.] ([X.]), also einen komplett anderen Kommunikationsdienst, der im Übrigen ohne die Lehre der [X.]/[X.] auch keine progressive Übertragung vorsieht.

b) Auch die weiteren Ausführungen der Klägerin, [X.]/[X.] lege im Zusammenhang mit der Freundesliste („Buddy list“) für die [X.] nahe, bereits dann Datenpakete loszuschicken, wenn auf [X.] noch keine Verbindung besteht, da dem Sendegerät durch die „[X.]“ der Status einzelner Nutzer bereits bekannt sei, der Fachmann ausgehend von [X.]/[X.] daher darauf verzichten würde, vor dem Versenden der Nachricht mittels eines Verbindungsaufbaus zu überprüfen, ob der Empfänger auch tatsächlich verfügbar ist und der Fachmann daher Anlass habe, eine Implementierung vorzusehen, bei der bereits mit Drücken des „Sende“-Knopfes ohne erneute Überprüfung der Verfügbarkeit Daten losgeschickt werden können, überzeugen nicht.

Denn es geht bei dem Erfordernis des Verbindungsaufbaus bei der [X.]/[X.] nicht darum, nochmals mittels eines Verbindungsaufbaus zu überprüfen, ob der Empfänger tatsächlich verfügbar ist, wenn er in der „[X.]“ als verfügbar angezeigt wird. Die Session und damit die Verbindung im Sinne des Merkmals [X.] wird durch den Austausch der Anmelde- und Verbindungsinformationen über den [X.]-Dienst zwischen den Kommunikationsgeräten eingerichtet, der gemäß der [X.]/[X.] zwingende Voraussetzung für das Versenden von Nachrichten ist und erst recht für den Aufbau einer [X.]. Dies ist aber nicht möglich, wenn einer der beteiligten Nutzer offline ist, auch wenn er in der „[X.]“ als verfügbar angezeigt wird. Mit einer Übertragung von Nachrichten kann mithin auch nicht begonnen werden.

2.2.4 Dass der Gegenstand des erteilten Patentanspruchs 1 gegenüber einer der weiteren im Verfahren befindlichen Druckschriften auf keiner erfinderischen Tätigkeit beruhen würde, ist für den [X.] nicht ersichtlich. Vielmehr liegen diese [X.] noch weiter ab vom Stand der Technik hinsichtlich des Gegenstands nach Patentanspruch 1.

Die Druckschriften K9, [X.] und [X.] wurden seitens der Klägerin zum Nachweis der Merkmale des erteilten, auf Patentanspruch 1 rückbezogenen Patentanspruch 8 in das Verfahren eingeführt, die [X.] betrifft den Nachweis von [X.] Dateigrößen zum Prioritätszeitraum, und die [X.]1 bis [X.]3 betreffen den Nachweis des Fachwissens hinsichtlich des [X.] gemäß [X.] und [X.]0.

Da sich somit der Gegenstand des Patentanspruchs 1 in seiner erteilten Fassung nach Hauptantrag für den Fachmann nicht in naheliegender Weise aus dem im Verfahren befindlichen Stand der Technik ergibt, gilt er auch als auf einer erfinderischen Tätigkeit beruhend und ist patentfähig.

3. Hinsichtlich der ebenfalls angegriffenen Unteransprüche 5, 7, 8, 10 sowie der nebengeordneten Ansprüche 11 und 12, zu denen die Klägerin lediglich schriftsätzlich pauschal auf ihren Vortrag zum erteilten Patentanspruch 1 verweist und keine darüberhinausgehenden Einwendungen erhoben hat, gelten auch - soweit sie vorteilhafte Ausgestaltungen des [X.] betreffen - die vorstehenden, den Anspruch 1 betreffenden Überlegungen entsprechend. Die Unteransprüche und die Nebenansprüche sind bereits durch ihren Rückbezug auf den patentfähigen Anspruch 1 rechtsbeständig. Gegenteiliges hat die Klägerin auch nicht geltend gemacht.

Nebenentscheidungen

Die Kostenentscheidung beruht auf § 84 Abs. 2 [X.] [X.] § 91 Abs. 1 ZPO.

Die Entscheidung über die vorläufige Vollstreckbarkeit beruht auf § 99 Abs. 1 [X.] [X.] § 709 ZPO.