DE60212339T2 - Ein digitales fernsehen anwendungsprotokoll zum interaktiven fernsehen - Google Patents

Ein digitales fernsehen anwendungsprotokoll zum interaktiven fernsehen Download PDF

Info

Publication number
DE60212339T2
DE60212339T2 DE60212339T DE60212339T DE60212339T2 DE 60212339 T2 DE60212339 T2 DE 60212339T2 DE 60212339 T DE60212339 T DE 60212339T DE 60212339 T DE60212339 T DE 60212339T DE 60212339 T2 DE60212339 T2 DE 60212339T2
Authority
DE
Germany
Prior art keywords
datp
message
stb
service platform
sgw
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60212339T
Other languages
English (en)
Other versions
DE60212339D1 (de
Inventor
Rachad Sunnyvale ALAO
Alain Delpuch
Vincent Palo Alto DUREAU
Jose Henrard
Matthew Huntington
Waiman Union City LAM
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OpenTV Inc
Original Assignee
OpenTV Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=46150067&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE60212339(T2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by OpenTV Inc filed Critical OpenTV Inc
Application granted granted Critical
Publication of DE60212339D1 publication Critical patent/DE60212339D1/de
Publication of DE60212339T2 publication Critical patent/DE60212339T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • H04L51/066—Format adaptation, e.g. format conversion or compression
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2542—Management at additional data server, e.g. shopping server, rights management server for selling goods, e.g. TV shopping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25875—Management of end-user data involving end-user authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25891—Management of end-user data being end-user preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2668—Creating a channel for a dedicated end-user group, e.g. insertion of targeted commercials based on end-user profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64707—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless for transferring content from a first network to a second network, e.g. between IP and wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/812—Monomedia components thereof involving advertisement data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8545—Content authoring for generating interactive applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols

Description

  • Ein Teil der Offenbarung dieses Patentdokuments enthält Material (Code-Listen und Meldungslisten), für die ein Urheberrechtsschutz beansprucht wird. Der Urheberrechtseigentümer hat keine Einwände gegen eine Telefaxreproduktion des Patentdokuments oder der Patentoffenbarung, wie sie in der Akte oder den Aufzeichnungen des US Patent and Trademark Office erscheint, durch eine Person, behält sich aber ansonsten alle Rechte vor. Copyright 2001 OpenTV Inc.
  • Hintergrund der Erfindung
  • Bereich der Erfindung
  • Die vorliegende Erfindung betrifft den Bereich Kommunikationen in der interaktiven Fernsehumgebung und betrifft insbesondere ein Verfahren und eine Vorrichtung zum Bereitstellen eines generischen Meta-Sprachen- und Digitalfernseh-Anwendungsprotokolls für interaktives Fernsehen.
  • Zusammenfassung der verwandten Technik
  • Interaktive Fernsehsysteme können zum Bereitstellen einer breiten Vielfalt an Diensten für Zuschauer verwendet werden. Interaktive Fernsehsysteme können typische Videoprogrammströme, interaktive Fernsehanwendungen, Text und Graphikbilder, Webseiten und andere Informationstypen liefern. Interaktive Fernsehsysteme können auch Zuschaueraktionen oder -antworten registrieren und können für Zwecke wie Marketing, Unterhaltung und Ausbildung verwendet werden. Benutzer oder Zuschauer können mit den Systemen durch Bestellen von angepriesenen Produkten oder Diensten, Antreten in Wettbewerben in einer Spieleshow, Anfordern spezieller Informationen über bestimmte Programme oder Navigieren durch Informationsseiten interagieren.
  • Typischerweise erzeugt ein Rundfunkdiensteanbieter (Broadcast Service Provider) oder Netzwerkbetreiber ein interaktives Fernsehsignal für die Übertragung zum Fernseher eines Zuschauers. Das interaktive Fernsehsignal kann einen interaktiven Teil beinhalten, der Applikationscode oder Steuerinformationen umfasst, sowie einen Audio/Video-Teil, der ein Fernsehprogramm oder andere Informationsanzeigen umfasst. Der Broadcast Service Provider kombiniert den Audio/Video-(A/V)- und den interaktiven Teil zu einem einzelnen Signal für die Übertragung zu einem mit dem Fernseher des Benutzers verbundenen Empfänger. Das Signal wird im Allgemeinen vor dem Senden komprimiert und durch typische Broadcast-Kanäle wie Kabelfernseh-(CATV)-Leitungen oder direkte Satellitenübertragungssysteme übertragen.
  • Die interaktive Funktionalität des Fernsehers wird typischerweise durch eine am Fernseher angeschlossene Set-Top-Box (STB) gesteuert. Die STB empfängt ein vom Broadcast Service Provider gesendetes Rundfunksignal, trennt den interaktiven Teil des Signals vom A/V-Teil des Signals ab und dekomprimiert die jeweiligen Teile des Signals. Die STB verwendet die interaktiven Informationen z.B. zum Ausführen einer Applikation, während die A/V-Informationen zum Fernseher gesendet werden. Die STB kann die A/V-Informationen mit interaktiven, von der interaktiven Applikation erzeugten Graphik- oder Audiosignalen vor dem Senden der Informationen zum Fernseher kombinieren. Die interaktiven Graphik- und Audiosignale können dem Zuschauer zusätzliche Informationen bieten oder den Zuschauer zu einer Eingabe auffordern. Die STB kann dem Broadcast Service Provider über eine Modemverbindung oder ein Kabel Benutzereingaben oder andere Informationen zuführen.
  • Im Einklang mit ihrem Summierungscharakter bieten interaktive Fernsehsysteme Inhalt in verschiedenen Inhaltsformen und Kommunikationsprotokollen, die von der/dem STB/Client verstanden und angezeigt werden müssen, die/der die Informationen vom Broadcast Service Provider/Netzwerkbetreiber empfängt. Der Client ist typischerweise eine STB mit einem Prozessor, der begrenzte Verarbeitungsleistung besitzt. Die Umsetzung der verschiedenen Inhalte und Protokolle liegt jenseits der begrenzten Verarbeitungskapazität des typischen STB-Prozessors. Somit besteht Bedarf an einem einfachen Kommunikationsprotokoll, das vom Client/STB-Prozessor leicht verstanden und in den verschiedenen von Diensteanbietern verwendeten Protokollen übermittelt werden kann.
  • Zusammenfassung der Erfindung
  • Gemäß einem ersten Aspekt der Erfindung wird ein Verfahren zum Bereitstellen von Kommunikationen in einem interaktiven Fernsehsystem bereitgestellt, das Folgendes umfasst: Empfangen einer ersten, an einen Applikationsserver gerichteten Meldung an einer Service-Plattform, wobei die erste Meldung von einem Client-Gerät empfangen wird und eine Benutzerkennung beinhaltet; gekennzeichnet durch: Mappen der empfangenen Benutzerkennung in eine Session-Kennung; und Übertragen einer zweiten Meldung zum Applikationsserver, die der ersten Meldung entspricht, wobei die zweite Meldung die Session-Kennung enthält und die Benutzerkennung nicht enthält.
  • Gemäß einem zweiten Aspekt der Erfindung wird eine Vorrichtung zum Erleichtern der Kommunikation in einem interaktiven Fernsehsystem bereitgestellt, wobei die genannte Vorrichtung Folgendes umfasst: ein Mittel, das für die Kommunikation mit einem Client-Gerät über eine erste Kommunikationsverbindung konfiguriert ist; ein Mittel, das für die Kommunikation mit einem Applikationsserver durch eine zweite Kommunikationsverbindung konfiguriert ist; und eine Service-Plattform, die zum Empfangen einer ersten Meldung konfiguriert ist, die eine Benutzerkennung vom Client-Gerät beinhaltet, dadurch gekennzeichnet, dass die genannte Service-Plattform konfiguriert ist zum: Mappen der empfangenen Benutzerkennung in eine Session-Kennung; und Übertragen einer zweiten Meldung zum Applikationsserver, wobei die genannte zweite Meldung der ersten Meldung entspricht, wobei die zweite Meldung die Session-Kennung enthält und die Benutzerkennung nicht enthält.
  • Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein rechnerlesbares Medium bereitgestellt, das Befehle enthält, die, wenn sie auf einem verteilten Computersystem ausgeführt werden, ein verteiltes Computersystem zu Folgendem veranlassen: Übertragen einer an einen Applikationsserver gerichteten ersten Meldung von einem Client-Gerät, wobei die genannte erste Meldung eine Benutzerkennung beinhaltet; dadurch gekennzeichnet, dass die Befehle, wenn sie ausgeführt werden, das verteilte Computersystem zu Folgendem veranlassen: Empfangen der ersten Meldung an einer Service-Plattform, wobei die genannte Service-Plattform: die empfangene Benutzerkennung in eine Session-Kennung mappt, und eine zweite Meldung überträgt, die der ersten Meldung entspricht, wobei die zweite Meldung die Session-Kennung enthält und die Benutzerkennung nicht enthält, Empfangen der zweiten Meldung an einem Applikationsserver.
  • Die vorliegende Erfindung addressiert die erörterten Bedürfnisse der interaktiven Fernsehumgebung. Die vorliegende Erfindung erfüllt das seit langem empfundene Bedürfnis, ein einfaches Inhalt- und Kommunikationsprotokoll bereitzustellen, das von einem STB-Prozessor leicht gehandhabt werden kann und komplexe Kommunikationen mit einer SP und Diensteanbietern ermöglicht. Die nachfolgende Erörterung verwendet zwar das Beispiel eines/einer Client/STB, aber die vorliegende Erfindung erstreckt sich auf alle Client-Geräte wie Digital Assistants, Zellulartelefone, Taschen-PCs oder jeden anderen Typ von elektronischem Gerät, das ein elektronisches Signal empfangen kann. Die vorliegende Erfindung befindet sich in einer Service-Plattform (SP) oder einem Server. Die SP ermöglicht es einem Netzwerkbetreiber, der Fernsehsignale zu seinen Subscriber-Clients sendet, Geschäfts-, Transport- und Kommunikationsfunktionen zu erzeugen und bereitzustellen, die eine Kommunikation zwischen Diensteanbietern und dem Client- oder STB-Zuschauer ermöglichen.
  • Die interaktive Fernsehumgebung muss Probleme handhaben und lösen, die für interaktives Fernsehen einzigartig sind, wie z.B. den intermittierenden Rückkehrpfad vom Client zur SP. Das heißt, das Client-Gerät ist nicht immer mit der Kommunikationslink verbunden, z.B. wenn die STB abgeschaltet ist. Somit gibt es nicht immer einen aktiven Rückkehrpfad vom Client. Die vorliegende Erfindung bietet eine Speicher- und Weiterleitungsfunktion, um dieses intermittierende Rückkehrpfadproblem abzumildern.
  • Bandbreiten- und Bearbeitungsbegrenzungen und Kommunikationskomplexitäten sind in der interaktiven Fernsehumgebung ebenfalls problematisch. Einerseits bietet der Netzwerkbetreiber typischerweise einen Broadcast-Kanal mit einer relativ großen Datenübertragungskapazität (typischerweise ein Satellit mit Antenne) zum Senden von Daten und Programmierungssignalen zum Client. Andererseits hat der Client-Rückkehrpfad eine relativ niedrige Datenübertragungskapazität (typischerweise ein Satellit mit Antenne) zum Senden von Daten und Programmierungssignalen zum Client. Andererseits hat der Client-Rückkehrpfad eine relativ niedrige Datenübertragungskapazität, gewöhnlich im STB-Szenario; der Rückkehrpfad ist eine Telefonleitung. Selbst wenn der Rückkehrpfad typischerweise eine größere Bandbreite hat, besitzen die STBs/Clients typischerweise ein langsames Modem zum Senden von Daten über den Rückkehrpfad. Diese und andere Belange werden von der vorliegenden Erfindung adressiert.
  • Kurzbeschreibung der Zeichnungen
  • Weitere Aufgaben und Vorteile der Erfindung gehen aus dem Studium der nachfolgenden ausführlichen Beschreibung und nach Bezugnahme auf die Begleitzeichnungen hervor. Dabei zeigt:
  • 1 ein allgemeines Architekturschema für eine bevorzugte Ausgestaltung einer Service-Plattform, in der sich die vorliegende Erfindung befindet;
  • 2 eine Architektur für die Service-Plattform, in der sich die vorliegende Erfindung befindet;
  • 3 ein Beispiel für ein bevorzugtes Application-Backend-Framework der vorliegenden Erfindung;
  • 4 ein Beispiel für eine bevorzugte DATP STB Stack Architekur der vorliegenden Erfindung;
  • 5 das SGW (Service Gateway) DATP (Digital TV Application Transport Protocol) der vorliegenden Erfindung als Teil des DAP (Digital TV Application Protocol), das zum Standardisieren von Rückkanalkommunikationen zwischen Applikationsservern und dem SGW verwendet wird;
  • 6 DAML und DATP als Teil von DAP;
  • 7 ein Beispiel für eine bevorzugte Architektur für das SGW der vorliegenden Erfindung;
  • 8 das Rückweisungsgleitfenster der vorliegenden Erfindung;
  • 9 eine Beispiel für eine DATP-Session zwischen einer STB und einem Applikationsserver;
  • 10–13 Statusmaschinen für DATP;
  • 14 eine Architektur für Inhaltsumsetzung, H20; und
  • 15–19 Meldungsszenarios zwischen Client/STB, SGW, H2O und Applikationsdiensteanbietern.
  • Die Erfindung kann zwar Gegenstand verschiedener Modifikationen und alternativer Formen sein, aber spezielle Ausgestaltungen davon werden beispielhaft in den Zeichnungen dargestellt und hierin ausführlich beschrieben. Es ist jedoch zu verstehen, dass die Zeichnungen und deren ausführliche Beschreibung die Erfindung nicht auf die besondere offenbarte Form begrenzen sollen, sondern die Erfindung soll im Gegenteil alle Modifikationen, Äquivalente und Alternativen abdecken, die im Rahmen der vorliegenden Erfindung wie in den beiliegenden Ansprüchen definiert liegen.
  • Ausführliche Beschreibung einer bevorzugten Ausgestaltung
  • Überblick
  • Die vorliegende Erfindung, ein Digital Television Application Protocol (DAP/DATP), befindet sich in einer Service-Plattform (SP) und interagiert mit dem Inhaltstranscoder H2O und einem Service Gateway (SGW). In einer typischen interaktiven Fernsehumgebung gibt es eine Vielzahl von Clients, typischerweise STBs, die mit einer Vielzahl von Applikationsservern kommunizieren müssen, die Inhalt über eine Vielzahl von Netzwerken mittels verschiedener Kommunikationsprotokolle bereitstellen. Die STB hat typischerweise eine begrenzte Verarbeitungsleistung, so dass es nicht wünschenswert ist, eine Vielzahl von Kommunikationsprotokoll-Handlern im STB-Prozessor oder STB-Stack zu platzieren. Somit besteht Bedarf an einer gemeinsamen Kommunikationsschnittstelle, die alle STBs und Applikationsserver adressieren kann. Das DATP-Protokoll der vorliegenden Erfindung bietet eine generische portable Kommunikations-API (Application Programmer Interface), die eine leichte Prozessorauslastung erfordert, die für eine typische STB mit begrenzter Verarbeitungsleistung gut geeignet ist. DATP erfordert relativ wenige Verarbeitungszyklen im Vergleich zu typischen Internet-Kommunikationsprotokollen. DATP reduziert das Overhead. des Kommunikationsprotokoll-Handlers an der STB und macht den Kommunikationsprotokoll-Handler für alle STBs gemein. Das bevorzugte DATP-Protokoll ist für alle STBs portabel, da es in O-Code, einem STB-unabhängigen Byte-Code geschrieben ist, der an das Betriebssystem der STB anschließt.
  • In der vorliegenden Erfindung dient ein SGW als DATP-Server. SGW ermöglicht es SP-Clients an STBs, sich über das DATP-Protokoll mit Applikationsservern zu verbinden. Ein HTML-in-Nativcode-Proxy H2O ist vorgesehen und kann in diesem Zusammenhang als SP-Applikationsserver angesehen werden. H2O führt spezielle. Inhaltsumsetzung wie HTML-in-SP-O-Codes durch. O-Codes sind der STB-unabhängige Bytecode der virtuellen Maschine, die auf der SP läuft. In einer bevorzugten Ausgestaltung existiert eine O-Code-Implementation des DATP-Protokoll-Stack im Client, typischerweise einer STB. Der Client kommuniziert über das DATP-Protokoll mit einem DATP-Server, SGW. Der H2O-Proxy existiert auf der anderen Seite des SGW und führt Inhaltsumsetzung wie HTML in O-Code durch. Eine O-Code-Implementation eines DATP-Stack in dem/der Client/STB gibt Kommunikationsanforderungen aus und kommuniziert mit dem SGW über das DATP-Protokoll. Vom H2O umgesetzter Inhalt wird durch das SGW zum Client geleitet, wo Inhalt angezeigt wird.
  • Das SGW ist ein DATP-Server, der Ausführungsthreads für die Handhabung jeder einzelnen STB und zur Verarbeitung jedes verwandten Inhalts erzeugt. Der SGW-Server-Stack kommuniziert mit dem/der Client/STB über das DATP-Protokoll. Das SGW wendet auch das geeignete Protokoll an, das nötig ist, damit die STB zwischen der STB und unterschiedlichen Applikationsservern hin und her kommunizieren kann. Interaktive Fernsehapplikationen verwenden gewöhnlich gut bekannte Internet-gestützte Protokolle (HTML usw.) für die Hin- und Herkommunikationen zwischen Client/STB und Applikationsservern. Die vorliegende Erfindung stellt ein generisches und gut geeignetes asymmetrisches Kommunikationsprotokoll zwischen Client/STB und Applikationsservern über das SGW bereit. Die vorliegende Erfindung bewältigt die an Client/STB zur Verfügung stehende minimale Verarbeitungs- und Speicherleistung.
  • Die vorliegende Erfindung stellt eine asymmetrische Datenkompressionslösung bereit. Die Bandbreite des bidirektionalen Pfades von Client/STB zu Netzwerkbetreiber ist relativ gering, gewöhnlich eine gewöhnliche Telefonleitung oder ein Rückkehrkanal in einem Kabel und gewöhnlich mit einem langsamen Modem verbunden. So wird zum Erhöhen der über das langsame Modem zur Verfügung stehenden Bandbreite der vom Server zu Client/STB heruntergeladene Inhalt komprimiert. An dem/der Client/STB erfolgt jedoch vorzugsweise keine Datenkompression. Zurückkommende Client/STB-Datenmengen sind relativ gering und brauchen nicht vom STB-Prozessor komprimiert zu werden, der gewöhnlich keine Verarbeitungsleistung für Datenkompression besitzt. In einer alternativen Ausgestaltung gibt es jedoch Fälle, bei denen Datenkompression von dem/der Client/STB gewünscht wird, und in diesem Fall erfolgt eine Datenkompression am SGW. Datenkompression ist in Bezug auf Client/STB dahingehend asymmetrisch, dass Daten, die stromabwärts zu dem/der Client/STB gehen, komprimiert werden, und Daten, die aufwärts von der STB gehen, nicht komprimiert werden. Somit ist die Architektur der vorliegenden Erfindung asymmetrisch, im Gegensatz zu typischen Internet-gestützten Protokollen, bei denen angenommen wird, dass beide kommunizierenden Entitäten symmetrisch gespeist werden.
  • SGW und Client/STB kommunizieren mit Applikationsservern unter Verwendung von Session-Kennungen für Clients anstatt mit Benutzerkennungen, so dass die Client-Benutzer anonym bleiben. Die vorliegende Erfindung bietet auch Multicasting zu Clients. Eine Multicast-Meldung kann zu mehreren Clients über eine Broadcast-Link gesendet werden, wenn die STB über eine Broadcast-Bandbreite und einen Tuner verfügt und wenn Broadcast-Meldungen verfügbar sind und von einem bestimmten Filter-Setup in der STB erfasst werden. In diesem Fall fordert das DATP an, dass die STB eine Meldung von einem speziellen Eintrag auf dem Broadcast erhält. Wenn kein Tuner zum Empfangen des Broadcast in der STB zur Verfügung steht, dann werden auch Meldungsfragmente auf jeder individuellen Punkt-zu-Punkt-Verbindung zu den STBs ohne Tuner gesendet. Wenn sich die STBs auf einem LAN befinden, dann werden Meldungen zu einer gut bekannten Adresse auf dem LAN zu den STBs gesendet.
  • Die vorliegende Erfindung stellt auch ein(e) neuartige(s) Struktur und Verfahren zur Handhabung von Cookies von Internet-Applikationen bereit und bietet ein „leichtes" (light) HTTP-Protokoll, LHTTP, das HTTP-Anforderungen in DATP-Meldungen verkapselt. LHTTP ist eine vereinfachte Version von HTTP, die auf DATP läuft. Das neue LHTTP läuft auf DATP und implementiert keinen Teil der TCP/IP-Spezifikation.
  • SGW stellt eine Link oder eine Socket-Verbindung mit einer STB her. Zum Implementieren des User Datagram Protocol (UDP) wird UDP jedoch nicht direkt ausgeführt. Für eine STB, die UDP ausgeben kann, verkapselt die vorliegende Erfindung DATP auf UDP. Das in DATP verkapselte UDP wird zum SGW gesendet. Im Falle von UDP werden ein Socket im SGW und ein Socket in der STB effektiv in einer simulierten Verbindung auf UDP aneinander gebunden. Durch diese simulierte Verbindung werden DATP-Pakete von der STB zum SGW-Server und vom SGW-Server zur STB gesendet.
  • Viele STB-Modeme bieten keine Datenkompression, besitzen nur minimale Verarbeitungskapazität und können sich die Verarbeitungskosten zur Ausführung von Datenkompression in der STB nicht leisten. Daher erfolgt in einer bevorzugten Ausgestaltung eine asymmetrische Datenkompression an der STB. Die STB empfängt komprimierte Daten und dekomprimiert sie, aber die STB führt keine Datenkompression aus. Datendekompression ist jedoch weniger rechenintensiv als Datenkompression, und daher führt die STB vorzugsweise Dekompression aus. Die STB führt keine Datenkompression aus. Komprimierte Daten werden zum DATP-Stack an der STB gesendet, aber unkomprimierte Daten werden von der STB zum SGW gesendet. Das SGW führt Datenkompression an den unkomprimierten Daten aus, die von der STB gesendet werden, und SGW leitet die komprimierten Daten zu Applikationsservern zurück. Somit erhöht die bevorzugte asymmetrische DATP/SGW-Kompression die Bandbreite des Rückkehrpfades von der STB durch das SGW zu den Applikationsservern.
  • Die vorliegende Erfindung bietet asymmetrisches Routing durch das SGW. Bei asymmetrischem Routing wird ein Teil der Bandbreite dem SGW zugeordnet, um Daten zum Broadcast-Strom Für Broadcast zu senden. SGW hat die Fähigkeit zu entscheiden, ob es Daten zu einer oder mehreren STBs über den Broadcast-Strom oder eine Punkt-zu-Punkt-(PTP)-Verbindung zwischen den SGW und der/den STB(s) sendet. SGW routet Daten über Broadcast oder PTP auf der Basis der Datenmenge, der Geschwindigkeit der Punkt-zu-Punkt-Verbindung zu der/den STB(s) und den aktuellen Kommunikationslink-Belastungsbedingungen. So kann das SGW entscheiden, einen Datensatz nicht über die Punkt-zu-Punkt-Verbindung zu senden, weil der Datensatz zu groß ist, und ihn stattdessen über den Broadcast-Strom zu senden. Daten können vom SGW komprimiert werden, bevor sie zum Empfängerstrom oder zur Punkt-zu-Punkt-Verbindung gesendet werden, um die Bandbreite der Link zwischen dem SGW und der Link oder dem Strom zu erhöhen und Speicherbegrenzungen in der STB zu berücksichtigen.
  • Das DATP ist rechnerisch leichtgewichtig, weil es so ausgelegt ist, dass alle STB-Stack-Operationen nur minimale Verarbeitungsleistung benötigen. So wird beispielsweise im DATP-Verschlüsselungsansatz, wenn Rivest, Shamir und Alderman (RSA) Public-Key-Verschlüsselung angewendet wird, der Key, der vom Server kommt, so gewählt, dass sein Exponent klein (3 oder größer) ist, so dass die Potenzierungsphase nur minimale Zeit und Verarbeitungsleistung beansprucht. So wird der schwere Rechenaufwand für den SGW-Server reserviert und der STB- oder Client-Prozessor braucht nur minimale Verarbeitungskapazität. Ebenso braucht die LHTTP-Schicht auf DATP in der STB keine schweren Parsing- oder sonstigen intensiven Verarbeitungsoperationen auszuführen. Stattdessen werden die HTTP-Daten in DATP-Meldungen durch LHTTP verkapselt, und die rechenintensiven HTTP-Funktionen, wie z.B. die Konvertierung in das HTTP-Protokoll, werden vom SGW gehandhabt.
  • DATP führt mehr als nur Transaktionen aus. DATP ist vielmehr ein meldungsgestütztes Protokoll als ein transaktionsorientiertes Protokoll. Wenn also ein Benutzer eine Meldung von einer STB zu einem Applikationsserver sendet, dann braucht der Applikationsserver nicht zu antworten. Das heißt, es gibt keine Eins-zu-eins-Korrespondenz zwischen STB und Diensteanbieter-Meldungen. Alle DATP-Meldungen, mit Ausnahme der Klasse der unzuverlässigen DATP-Meldungen, werden durch eine DATP-Schicht zuverlässig verarbeitet. Alle DATP-Meldungen haben eindeutige Kennungen, die als die Basis für eine Transaktion verwendet werden können.
  • In einer Transaktion über DATP, z.B. einer HTTP-Anforderung, sendet die STB eine DATP-Meldung zum SGW und fordert eine Webseite an. Das SGW konvertiert LHTTP in HTTP und sendet sie zum Internet über H2O. Wenn die die Webseite enthaltende Antwort vom Internet über H2O zu SGW züruckkehrt, das den Inhalt konvertiert, sendet SGW eine LHTTP DATP-Meldung zur STB, die den Inhalt der angeforderten Webseite zur STB zurückführt. Ein weiteres Beispiel für eine Transaktion ist eine von einer STB gesendete Fetchmail-Anforderung. Die Fetchmail-Anforderung ist in einer DATP-Meldung verkapselt. DAML wird auf der DATP-Meldung verwendet. DAML ist eine domänenspezifische Instanz von XML.
  • So sendet die STB eine DATP-Meldung zu Fetchmail, die eine DAML (XML) Anforderung enthält. Fetchmail liest die DATP-Meldung und extrahiert den Inhalt aus der Meldung, leitet den Inhalt zum Applikationsserver, der die Transaktion verarbeitet und gibt eine Meldung zu Fetchmail zurück. Fetchmail sendet dann eine angeforderten Inhalt enthaltende DATP-Meldung zur STB.
  • DATP ist aufgrund seines Mapping auf das OSI-(Open Systems Interconnection)-Modellflexibel. Das OSI-Modell umfasst sieben Schichten für Kommunikationen von Computer zu Computer. Jede der sieben Schichten baut auf der Schicht darunter auf. Die sieben OSI-Schichten lauten, von unten nach oben, wie folgt: Bitübertragung (Physical), Sicherung (Datalink), Vermittlung (Network), Transport (Transport), Sitzung (Session), Darstellung (Presentation) und Anwendung (Application). DATP ist flexibel, da es vier der sieben Schichten des OSI-Modells überspannt. DATP überspannt die Schichten Sicherung, Vermittlung, Transport und Sitzung des OSI-Modells. Das OSI-Modell geht von einer symmetrischen Verarbeitungskapazität an jedem Computer-Server und Host aus, der über das OSI-Modell kommuniziert. Das heißt, das OSI-Modell bietet ein symmetrisches Kommunikationsmodell. Dieses symmetrische Modell ist für die schwache Verarbeitungskapazität der STB nicht geeignet. DATP bietet ein asymmetrisches Kommunikationsprotokoll auf der Basis des Paradigmas „dicker" (große Bandbreite und Verarbeitungsleistung) Server/dünner (kleine Bandbreite und Verarbeitungsleistung) Client, das so ausgelegt ist, dass es besonders gut für die interaktive Fernsehumgebung geeignet ist.
  • DATP reduziert das pro Byte übertragene Overhead erheblich auf ein Minimum. Das DATP-Protokoll wird in einem binären Format implementiert, dessen eigenes DATP-Paket so formatiert ist, dass das Paket-Overhead grob zwanzig Byte beträgt, was die Hälfte von dem ist, was im TCP/IP-Format-Framing benötigt wird. DATP bietet eine Zuverlässigkeitsschicht. DATP sieht auch vor, dass „unzuverlässige DATP-Pakete" Meldungen zu STBs senden, die nicht bestätigt werden und die durch die Zuverlässigkeitsschicht nicht zuverlässig gemacht werden. Unzuverlässige DATP-Pakete sind für Multicasting nützlich.
  • SGW bietet auch eine Speicher- und Weiterleitungsfunktion zum Handhaben von von mehreren Benutzern kommenden Auftragsspitzen und reagiert schnell auf die Benutzerauftragsanforderung. SGW sendet eine „Auftragsbestätigung" zum Benutzer schnell als Reaktion auf dessen Auftrag und speichert den Auftrag für eine spätere Übertragung zum Applikationsserver, der die Auftragstransaktion tatsächlich verarbeitet. Indem der Auftrag später gesendet wird, kann eine größere Zahl von Aufträgen über die Zeit verteilt werden, und es brauchen nicht alle gleichzeitig zum Applikationsserver gesendet zu werden. Somit wird die Bandbreite effizient ausgelastet. DATP bietet auch ein Rückweisungsgleitfenster auf der Basis von Sequenznummern gegenüber Zeit. DATP/SGW werden nachfolgend ausführlich erörtert.
  • Die Service-Plattform
  • 1 zeigt die SP, in der sich die vorliegende Erfindung befindet. Die SP 50 umfasst eine Gruppe von Applikationen, die grob in drei Kategorien unterteilt sind, Inhaltskonvertierung 204, Transaktionssteuerung/Geschäftsfunktionen 106 und Transportkonvertierung 108. Die SP ermöglicht es Diensten 200, mit einem Client 212 zu interagieren. Die Dienste 200 kommunizieren durch eine Kommunikationslink 102 mit der SP 50. Die SP 50 wiederum kommuniziert mit einem Client 212. Der Client 212 kann eine STB, ein Digital Assistant, ein Zellulartelefon oder ein beliebiges anderes Telekommunikationsgerät sein, das mit der SP durch die Kommunikationslink 210 kommunizieren kann. Die Dienste Inhaltskonvertierung 204 und Transportkonvertierung 108 bieten die Transport- und Kommunikationsfunktion, die Geschäftsfunktionsdienste bieten die Geschäftssteuerfunktionen.
  • 2 illustriert ein Beispiel für eine bevorzugte Implementation der Service-Plattform 50. Die Dienste 200 bieten Shopping, Chatten und andere entweder über das Internet oder über einen anderen Netzwerk- oder Kommunikationskanal, auf den der Netzwerkbetreiber zugreifen kann. Mit der SP greift der Netzwerkbetreiber auf diese Dienste zu. Geschäftsfunktionen 206, einschließlich Service-Manager 238, interagieren mit dem Karussell-Manager 254 zum Abrufen von Inhalt von einem Dienst 200. Das Karussell umfasst einen sich wiederholenden Strom von Audio/Video/Interaktiv-Daten, die von der SP 50 zu Clients gebroadcastet wurden. Karussell-Manager 254, Transaktionsmanager 242 und Service-Manager 238 steuern das Einfügen und Löschen von Inhalt vom Broadcast-Karussell. Service-Inhalt wird abgerufen und vom H2O 248 in ein für die SP geeignetes Format konvertiert. H2O 248 ist eine mögliche Implementation der Inhaltskonvertierung 204. H2O konvertiert HTML-Inhalt in von der/dem SP/Client lesbaren Inhalt. Der konvertierte Inhalt wird zu einem Datenkarussell formatiert und von Open Streamer 256 zum Broadcasten zum Client 212 multiplexiert. Der Client 212 interagiert mit den Diensten und kommuniziert bei Bedarf mit der SP und den Diensten 200. PTP-Kommunikation erfolgt durch SGW 246. SGW 246 führt eine Transportkonvertierung zum Konvertieren des STB DATP Protokolls in eine Form aus, die Platform-Business-Agenten 226 und H2O 248 erwarten und verstehen. Der Lastausgleicher 236 interagiert mit Geschäftsfunktionen 206, dem Karussell-Manger 254 und dem SGW 246 zum Ermitteln der optimalen Last zwischen der Broadcast-Link 241 und der PTP-Kommunikationslink 210. Geschäftsfunktionen 206 interagieren mit den Plattform-Business-Agenten 226 zum Steuern von Zugriff und Informationsaustausch zwischen den Diensten 200 und dem Client 212.
  • SP verbirgt die wertvolle Subscriber-Profildatenbank des Operators, indem sie verlangt, dass einem Dienst Zuschauerinformationen ausschließlich vom Netzwerkbetreiber und unter dessen Kontrolle gegeben werden. Um die Identität des Subscribers zu schützen, wird eine abstrahierte Benutzerkennung (d.h. Session-Kennung) während der Session zum Dienst übertragen, dass der Dienst Transaktionsdetails zur SP überträgt. Die Benutzerkennung ist session-spezifisch. Es kann mehr als eine Benutzerkennung mit einem Client assoziiert sein, wie z.B. dann, wenn verschiedene Familienmitglieder dieselbe STB benutzen. Jedem Familienmitglied und der Haushalt-STB können individuell eine Zuschauerkennung, eine Kategorie zugewiesen werden, die im Hinblick auf Transaktionen für Einkäufe/Kinofilmanforderungen/Fernsehgewohnheiten usw. verfolgt und vom SP-Zuschauer-Manager profiliert werden. Der Dienst kennt die Client- oder STB-Kennung nur durch eine Session-Kennung. Nur der Netzwerkbetreiber kann, über das SGW, eine Session-Kennung in Zuschauerinformationsdetails auflösen (Name, Adresse, Versandinformationen usw.), die zum Ausfüllen eines Auftrags benötigt werden. Eine Ausnahme kann für eine Kreditkartennummer oder andere Information gemacht werden, wenn der Operator keine Kreditkartensammlungen oder andere Transaktionen durchführen möchte.
  • Die vorliegende Erfindung ermöglicht es Netzwerkbetreibern, den Zugriff auf die Zuschauerinformationsdatenbank zu kontrollieren und nur denjenigen Diensteanbietern zu gestatten, die eine Vereinbarung mit dem Netzwerkbetreiber für den Zugriff auf privilegierte Informationen haben (z.B. Kreditkartennummern, Eigenname des Zuschauers, Heimadresse, Telefonnummer, Sozialversicherungsnummer usw.). Der Zuschauer-Manager 252 ermöglicht den Zugriff auf Personen- und Profilinformationen, die auf den Client-Geräten gespeichert sind, und ermöglicht es den Client-Geräten oder der SP, vom Benutzer bevorzugten Inhalt und Kaufgewohnheiten auf der Basis der im Zuschauerprofil gespeicherten Fernsehinformationen zu wählen. Clients oder die SP wählen vom Benutzer bevorzugten Inhalt auf der Basis von Zuschauerprofilierung über Geschäftsfilter, die im Client-Gerät vom Client, dem SGW oder einer anderen SP-Komponente aktiviert werden.
  • Der Zuschauer-Manager 252 bietet Haushalt/Subscriber/STB-(oder andere Client-Geräte)-Identifikationen und Berechtigung zur Unterstützung der SGW- und Kindersicherungsfunktionen. Der Zuschauer-Manager 252 unterstützt mehrere Zuschaueridentifikationen und Registrierungsberechtigungen an einer einzelnen STB durch Kosenamen und/oder persönliche Identifikationsnummern (PIN) plus der Zuschauerkennung, die von Client-Geräte-Kennnummer(n), Transaktionshistorie, Zuschauerprofilen, Kosenamen und persönlichen Identifikationsnummern abgeleitet wurde. Der Zuschauer-Manager 252 führt eine Haushalts- und individuelle Zuschauerprofilierung durch Logging, Erzeugung und Zusammenführung in Verbindung mit beobachteten kumulativen Fernseh- und Kaufgewohnheiten durch. Der Zuschauer-Manager unterstützt verteilte Datenerfassung und Speicherung zwischen der SP und der STB und unterstützt bidirektionale Synchronisation.
  • Der Zuschauer-Manager 252 ermöglicht einen verteilten Profilgebrauch zwischen allen SP-Applikationen und bietet Synchronisation mit einem externen SMS/CRM. Der Zuschauer-Manager 252 ermöglicht mehrere Zuschauerregistrierungen für ein(e) einzelne(s) STB oder Client-Gerät unter Verwendung abstrakter Zuschauerkennungen, die Pseudonyme oder Kosenamen, volle Namen und PIN-Speicherung in der STB oder einem anderen Client-Gerät umfassen. Business-Agenten 226 vollziehen die Einhaltung der Transaktionsgeschäftsregeln für eine Interaktion zwischen Diensteanbietern und Zuschauern. Auf der Basis von Geschäftsregeln, die von den Netzwerkbetreibern definiert werden und auf Vereinbarungen mit den Diensteanbietern basieren, steuern die Business-Agenten 226 Transaktionen und den Zugriff von Diensteanbietern auf Benutzerinformationen. Business-Agenten 226 ergänzen, addieren, ersetzen und löschen Zuschauerinformationen während einer Transaktion auf der Basis der Diensteanbietervereinbarungen und abstrakten Session-Kennung.
  • Business-Agenten 226 erzeugen Sessions zwischen Client-Subscribern und Diensteanbietern. Business-Agenten 226 steuern den Zugriff auf Zuschauerinformationsdetails und manipulieren Zuschauerinformationen durch Einschließen, Ersetzen und Herausnehmen von Zuschauerinformationen, die Diensteanbietern vorgelegt werden. Die Business-Agenten 226 geben Vorgabewerte und steuern den Zugriff auf Benutzerinformationen. Die Business-Agenten 226 führen auch Transaktionslogging, Meldungslogging und Last-/Transaktionsüberwachung durch.
  • Der Reklamemanager 244 bietet eine Schnittstelle mit den Broadcast- und PTP-Links, die eine kostenlose Reklameinteraktion zwischen den beiden Zuführungskanälen ermöglicht. So kann beispielsweise eine Broadcast-(Push-) Reklame eine PTP-Verbindung zum Reklamedienst über die SP auslösen, so dass der Benutzer das Produkt kaufen oder mehr Informationen über das Produkt einholen kann. Eine Broadcast-Reklame kann auch in den PTP-Inhalt gesetzt werden, um einen Benutzer über die Verfügbarkeit von Broadcast-Diensten (z.B. ein Infomercial) zu informieren.
  • In einigen Fällen werden mehrere Produkte oder Reklamesegmente zum Client gepusht oder gebroadcastet, ohne dass der Client die Informationen angefordert hat. Geschäftsfilter in Verbindung mit dem Client, die sich vorzugsweise in einer STB befinden, werden zum Wählen der besten Reklame für den Zuschauer auf der Basis von Benutzerprofilen verwendet. Zum Beispiel, während einer Kochsendung kann die SP eine Gruppe von Kochreklamen zum Broadcasten zu Zuschauern planen. Diese Gruppe von Werbesendungen kann Kochreklamen über italienische, französische, indische und deutsche Küche umfassen. Der Geschäftsfilter, der mit der STB oder dem Client assoziiert sein oder sich darin befinden kann, wählt, welchen Typ von kulinarischer Reklame er dem Client vorlegt. Ein Zuschauer möchte möglicherweise eine französische Kockreklame sehen, während ein anderer Zuschauer möglicherweise die indische Kochreklame sehen möchte, je nach dem STB-Filter, der vom Client oder der SP auf der Basis der Benutzerpräferenzen und Client-Profile eingestellt ist.
  • Die SP ermöglicht eine Wiederverwendung von Web Commerce Infrastruktur. Die SP ersetzt die ,gewöhnlichen' HTML-Schablonen durch ein SP-freundliches Format. Die Business-Agenten empfangen die Auftragsanforderungen von der STB oder dem Client über das SGW. Das SGW setzt Meldungen in Warteschlangen (um Spitzen zu bewältigen), einige Aufträge werden von den Business-Agenten mit einer Verzögerung empfangen (dieser Ansatz würde vorzugsweise für Aufträge benutzt, die keine Form von Bestätigung benötigen). Die Business-Agenten fügen Aufträgen Zuschauerinformationen hinzu. Menge und Typ der in einem Auftrag/einer Meldung enthaltenen Zuschauerinformationen werden durch Geschäftsregeln im Einklang mit Dienste/Einzelhandelsvereinbarungen bestimmt.
  • Als Kommunikationen zwischen Diensten und Zuschauern/Clients werden die Informationen entweder zu separaten Karussells mit einem einzelnen Karussell pro Transportstrom gesendet oder zu den existierenden Applikationskarussels zusammengeführt. Aufträge können dann bei Bedarf durch eine „Kreditkarten-Clearance"-Funktion bearbeitet werden, die von der SP bereitgestellt wird. Wenn Bestätigungen von den Einzelhändlern zurückgesendet werden, werden die Aufträge in Echtzeit zum Benutzer zurückgesendet, per Email zum Benutzer oder auf Abruf durch eine Form von Kundenbetreuungsapplikation zur Verfügung gestellt.
  • Die SP bietet auch Offline-Zuschaueridentifikation (OVI), so dass ein Zuschauer ohne eine hergestellte Online-Zuschauerverbindung identifiziert oder authentifiziert werden kann. Dadurch wird gewährleistet, dass die Verbindungsverzögerung (z.B. 10–40 Sekunden) an die geeignetste Stelle im Kaufvorgang gesetzt werden kann. Dies ermöglicht auch eine Zuschaueridentifikation zusammen mit der Speicher- und Weiterleitungsfunktion. OVI ermöglicht Kommunikationen und die Erledigung von Aufträgen/Operationen mit einem Client-Gerät, das intermittierend ein- und ausgeschaltet ist.
  • Es ist eine Offline-Auftragsformularfunktion vorgesehen, die es der SP ermöglicht, T-Commerce-Dienste für einen Zuschauer bereitzustellen, um Artikel auf ein Auftragsformular (Einkaufswagen) zu setzen, ohne online zu sein. Die Speicher- und Weiterleitungsfunktion ist zur Erzielung einer größeren Skalierbarkeit wichtig. Speicherung und Weiterleitung können entweder Weiterleitung zu ruhigeren Zeiten oder einfach Verteilen der Last über eine bestimmte Zeitperiode nach dem Einleiten einer Transaktion erfolgen. Die volle Speicher- und Weiterleitungslösung wird integriert mit [Lakune], so dass Antworten von jedem Kanal zu jeder Zeit weitergeleitet werden können. Speicherung und Weiterleitung können für erweiterte E-Commerce, T-Commerce Transaktionen verwendet werden. Die Offline-Zuschauerauthentifizierung ermöglicht eine Offline-Zahlungsauswahl. Die Offline-Zahlungsauswahl wird von der SP bereitgestellt, um den Kaufprozess zu verbessern und die Nutzung der Speicher- und Weiterleitungsfunktion mit T-Commerce/E-Commerce zu ermöglichen.
  • Die SP verwendet, wo anwendbar, einen standardmäßigen Webtransport, d.h. sie verwendet HTTP für Echtzeitanforderungen und wo anwendbar SMTP für asynchrone Kommunikationen (d.h. Merchant-Reporting, Speichern und Weiterleiten). Selbst wenn man online geht, bietet die SP die Möglichkeit, sich für kurze Zeit zum Zugreifen auf Daten (z.B. Email) zuzuschalten und die Daten dann lokal zu benutzen. Die SP bietet Session-gestützte Kennungen anstatt der typischen Web-Cookies zum Schützen der Operator-Zuschauerdatenbank. Anstatt Web-Cookies bietet die SP eine Session-gestützte Kennung, mit der der Dienst nicht den Benutzer, sondern nur die Session identifizieren kann. Der Dienst muss die Zuschauerinformationen vom SGW anfordern (und dies wird vom Netzwerkbetreiber berechnet).
  • Die SP informiert den Zuschauer bei Bedarf, wenn ein Zuschalten stattgefunden hat, und kann auch bei Bedarf die Zustimmung des Zuschauers zum Aufrechterhalten der Verbindung einholen. Die SP zeigt auch einen „Connection ON" (Verbindung ein) Status am Zuschauerbildschirm an. Die SP verwendet die Broadcast-Bandbreite für PTP-Kommunikationen, wenn dies effizienter ist. Es ist ein Lastausgleicher vorgesehen, der bestimmt, welche Informationen über die Broadcast- und welche über die PTP-Verbindung gehen. Lastausgleichsentscheidungen basieren auf der Dringlichkeit der Daten, der Zuführungslatenz der Broadcast- gegenüber PTP-Übertragungslinks, der Vergleichslast auf den Broadcast- und PTP-Pfaden und der Zahl der die Daten empfangenden Zuschauer. Im Allgemeinen werden Daten, die zu einer großen Zahl von Zuschauern gehen, gebroadcastet, und geringe Datenmengen, die sofort gesendet werden müssen, werden über die PTP-Link gesendet. STBs ohne Breitbandtuner empfangen ausgesendete PTP-Meldungen zusammen mit Breitband.
  • SP bietet Filter für STBs und/oder Clients, die Informationen im Breitbandpfad auf der Basis von Zuschauerprofilierung selektiv empfangen, so dass nur ausgewählte Zuschauer, in deren STB ein bestimmter Filter eingerichtet ist, Inhalt (Werbung, Informationen oder A/V-Programmierung usw.) im Broadcast-Strom erfassen. Diese Filter verbessern die adaptiven und selektiven Zuführungsaspekte der SP. Der Karussell-Manager bietet ein Datenkarussell für Open Streamer. Der Karussell-Manager verwaltet ein Karussell von Daten in Echtzeit. Der Karussell-Manager komplementiert Open Streamer. Der Karussell-Manager bietet eine Server-Komponente und eine STB-Client-OCOD-Bibliothek. Der Karussell-Server empfängt Anforderungen von Applikationen, um Inhalt zum Karussell hinzufügen, davon wegzunehmen oder auf andere Weise zu ändern. Wenn der Karussell-Manager eine Anforderung empfängt, behandelt er sie als eine einzelne Transaktion und holt alle notwendigen Daten ein (gewöhnlich durch HTTP). Der Karussell-Manager erzeugt bei Bedarf eine neue Karussellindex- oder Karussellverzeichnisdatei. Der Karussell-Manager veröffentlicht das aktualisierte Karussellverzeichnis zu Open Streamer und steuert dadurch die Broadcast-Prioritäten und -Tracks von Open Streamer.
  • Open Streamer ist ein Software/Hardware-Produkt, das es Netzwerkbetreibern ermöglicht, SP-Anwendungen und Daten in ihrem Netzwerk-Broadcast zu broadcasten. Open Streamer lässt es zu, dass SP-Daten und -Applikationen gleichzeitig mit den A/V- Programmen des Netzwerkbetreibers gesendet werden. Open Streamer ermöglicht die Aktualisierung eines Datenstroms in Echtzeit passend zum A/V-Inhalt. So kann beispielsweise ein Netzwerkbetreiber eine interaktive Sportapplikation zusammen mit der Live-Sendung einer Sportveranstaltung broadcasten. Open Streamer umfasst zwei Komponenten, eine gemeinsame Server-DLL und einen Broadcast-Streamer. Ein Applikationsserver (z.B. ein Wetterapplikationsserver) oder der Carousel Builder in der SP ruft die gemeinsame Server-DLL auf, um die Karusselldaten zum Broadcast-Streamer zu senden. Der Broadcast-Streamer führt die Multiplexierung (gemäß Code/Daten-Verhältnis- und Bitratenanforderungen) der Applikationen und A/V-Daten durch und sendet die multiplexierten Daten zum Ausstrahlen zum Broadcast-Gerät.
  • Überblick über den DAP/DATP-Protokollansatz
  • Die vorliegende Erfindung ermöglicht Kommunikationen zwischen STBs und Diensteanbietern in Verbindung mit einer SP. Das DATP-Protokoll ist ein meldungsgestütztes Protokoll, bei dem eine Entität eine Meldung zu einer anderen Entität mit einer Liefergarantie sendet. Jedes Mal, wenn die STB eine Meldung zum SGW sendet, erhält die STB eine Bestätigungsmeldung, sobald die Meldung ihr Endziel erreicht hat (SGW oder ein Applikationsserver). Wenn ein Applikationsserver die Meldung verarbeitet hat, kann eine Antwortmeldung zur STB gesendet werden, vorausgesetzt, die STB-Session mit SGW ist noch offen. Der DATP-Meldungssendephase geht eine DATP-Login-Phase voraus und es folgt ihr eine DATP-Logout-Phase, die zum Herstellen einer DATP-Session nötig sind. DATP ist ein Sessionorientiertes Protokoll. 9 illustriert ein einfaches Beispiel für eine DATP-Session.
  • DATP unterstützt mehrere Sessions auf derselben STB-Transportschicht-Verbindung. STB-Clients können mitten in einer offenen Session mit SGW-Login Pakete zum Starten einer neuen Session auf derselben STB-Transportlink senden, die für die erste Session benutzt wird. Beide DATP-Session-Management-Module im STB-Client und im SGW multiplexieren die verschiedenen Session-Meldungen über dieselbe Link.
  • Überblick über den DATP-Paketinhalt
  • Das DATP-Protokollpaket umfasst einen Header fester Größe, Nutzdaten veränderlicher Größe (DAML-Meldungen) und einen Trailer. Der Header umfasst die folgenden Elemente: Protokollversionsnummer; Pakettyp (Login/Logout Handshake, Ping, Daten, Bestätigung usw.); tatsächliche Transport-Info (Rohdaten, TCP/IP, UDP usw.); Meldungssequenznummer (DATP-Meldungsnummer, von STB oder SG erzeugt); Dienstekennung (ID des Dienstes zum Empfangen der Daten). Die Dienste-ID ist eine 8-Bit-Kennung, die im DATP-Protokoll definiert ist. Die Session-ID (Session ID wird vom SGW beim Handshake gegeben); Verschlüsselungsflags für verschlüsselte Sessions; und Nutzdatengröße.
  • Die Nutzdaten können die folgenden je nach Pakettyp enthalten: Login/Logout-Info für Handshake-Pakete; Quittungsinfo für Bestätigungspaket; Nutzdaten für Datenpaket. Der Trailer enthält wenigstens die 32 Bits CRC-Prüfsumme des DATP-Pakets. Die DATP-Protokollbyte-Reihenfolge ist BIG ENDIAN.
  • Paketfelderspezifikation
  • Das Protocol Version Feld ist die Version des DATP-Protokolls, das von der sendenden Entität benutzt wird. Dies ist das erste Byte eines DATP-Pakets. Das DATP-Paketformat kann je nach der DATP-Protokollversionsnummer variieren. Wenn neue Versionen des DATP-Protokolls vorgegeben werden, dann wird diese Versionsnummer erhöht, um die Änderungen zu reflektieren. DATP-Kommunikationen zwischen zwei Entitäten benutzen die höchste an beiden Entitäten verfügbare DATP-Version. Die Versionsnegoziierung ist Teil des Login-Prozesses.
  • Das Packet Type Info Feld ist das zweite Byte eines DATP-Pakets. Es zeigt an, welcher Typ von DATP-Paket gerade gesendet wird. Das STB Transport Info Feld ist das dritte Byte eines DATP-Pakets. Es gibt Informationen über den auf der STB-Seite benutzten Transport. Es ist in 3 Subfelder unterteilt: STB_transport_info[7..4]: Die vier MSB-Bits des Feldes repräsentieren den nativen STB-Transportprotokolltyp. STB_transport_info [3]: Dieses Bit gibt an, ob der zu Grunde liegende Transport zuverlässig ist. Man beachte, dass dieses Bit selbst dann auf den richtigen Wert gesetzt wird, wenn der Wert des nativen Transportprotokolltyps eine gute Anzeige der Protokollzuverlässigkeit geben kann. STB_transport_info [2..1]: Dieses Bit zeigt die Geschwindigkeitsklasse des nativen STB-Transports an.
  • Die Service-ID ist das vierte Byte in einem DATP-Paket und zeigt die ID des Ziel- (STB-zu-SGW-Pakete) oder Sende- (SGW-zu-STB-Pakete) Hosts eines DATP-Pakets an. Die Session-ID ist das zweite Quadlet (Doppelwort) eines DATP-Pakets. Sie gibt die Session-ID des DATP-Pakets an. Session-ID-Werte werden vom SGW während des Login-Prozesses erzeugt. Bei Login-Paketen ist das Session-ID-Feld auf 0 gesetzt.
  • In DATP ist eine Sequenznummer das erste Wort des dritten Quadlets eines DATP-Pakets. Es zeigt die DATP-Meldungssequenznummer an. Diese Nummer identifiziert eine DATP-„Transaktion" von einem zu seiner entsprechenden Bestätigung gesendeten Paket. Meldungssequenznummern werden durch die sendende Entität erzeugt und sind nur über die auf einem Zweig einer DATP-Verbindung gesendeten Meldungen eindeutig. Das bedeutet, dass eine vom STB-Client zum SGW gesendete DATP-Meldung und eine vom SGW zum STB-Client gesendete Meldung dieselbe Sequenznummer haben können, aber weiterhin zwei separaten „Transaktionen" entsprechen.
  • In DATP ist die Datengröße das zweite Doppelwort des dritten Quadlets eines DATP-Pakets. Es gibt die Größe der Nutzdaten des Pakets in Bytes an. Diese Größe ist konstruktionsbedingt auf 64 KB begrenzt, um verschiedene gemeinsame Faktoren bei Low-End-STBs wie langsame Modemlinks, äußerst verrauschte Kommunikationskanäle, begrenzte RAM-Speicherressourcen usw. zu berücksichtigen. In DATP bilden Verschlüsselungsflags das erste Byte des vierten Quadlets eines DATP-Pakets. Die DATP-Nutzdaten beginnen am ersten Byte nach den 16 Bytes des Headers fester Größe bis zur Größe der Nutzdaten wie im Headerdatengrößenfeld angegeben. In DATP ist CRC das erste Quadlet nach den Nutzdaten. Es enthält den Wert der 32-Bit-CRC-Prüfsumme des gesamten DATP-Pakets (einschließlich Header).
  • Das Login-Paket wird von der/dem STB/Client zum Einleiten einer DATP-Session mit dem SGW gesendet. Es repräsentiert die erste Phase der Login-Prozessnegoziation, wobei sich die STB dem SGW selbst vorstellt. Das SGW beantwortet eine Login-Anforderung im Erfolgsfall mit einem Bestätigungspaket. Es entscheidet dann über die negoziierbaren Attribute der DATP-Verbindung und weist der neu erzeugten Session eine Session-ID zu.
  • Das SGW beantwortet die Login-Anforderung im Misserfolgsfall mit einem negativen Bestätigungspaket. Dieses Paket wird von der STB zum Schließen einer DATP-Session mit dem SGW gesendet. Das SGW beantwortet eine Logout-Anforderung im Erfolgsfall mit einem Logout-Bestätigungspaket.
  • Das SGW beantwortet eine Logout-Anforderung im Misserfolgsfall mit einem negativen Logout-Bestätigungspaket. Misserfolgsfälle sind u.a. Fehler wie unbekannte Session-ID, schlechte CRC usw. Ein Datenpaket kann von jeder Entität einer DATP-Verbindung gesendet werden. Eine STB-Client-Applikation kann DATP-Datenpakete zu Applikationsservern senden und Applikationsserver können einer STB antworten und eine Übertragung eines Datenpakets vom SGW zur Client-STB bewirken. Eine Entität, die ein Datenpaket empfangen hat, antwortet bei erfolgreichem Anfang mit einem Datenbestätigungspaket. Eine Entität, die ein Datenpaket empfangen hat, antwortet bei erfolglosem Empfang mit einem negativen Datenbestätigungspaket. Wenn kein Paket von einer Fern-DATP-Entität für eine konfigurierbare Zeitperiode empfangen wurde, dann könnte die andere Fernentität die DATP-Link dadurch testen, dass sie ein DATP-Ping-Paket sendet und auf eine Antwort wartet. Eine Fernentität, die ein Ping-Paket empfangen hat, muss ein Ping-Quittungspaket zu ihrem Fern-Peer senden, wenn das Ping-Paket erfolgreich empfangen wurde. Eine Fernentität, die ein Ping-Paket empfangen hat, muss im Falle eines erfolglosen Empfangs eines Ping-Pakets ein negatives Ping-Quittungspaket zu ihrem Fern-Peer senden. Misserfolgsfälle sind u.a. Fehler wie unbekannte Session-ID, schlechte CRC-Prüfsumme usw.
  • 3 zeigt eine Zusammenfassung der Architektur für DATP/SGW. Eine große Zahl von SP- und STB-Client-Applikationen haben gemeinsame Bedürfnisse, die eher transportspezifisch als applikationsspezifisch sind und die in der DATP-Architektur adressiert werden. DATP führt Verschlüsselung, Datenkompression, HTTP-Routing und viele andere nachfolgend erörterte Funktionen aus. Die Architektur für das DATP-Application-Backend-Framework ist in 3 illustriert. DATP stellt Lightweight HTTP (LHTTP) auf O-Code-Applikationsebene, Speicher- und Weiterleitungsfunktionen, STB-Identifikation (mit dem OpenTV Central Registry [OCR]) und viele andere Funktionen bereit. Diese Funktionen werden im Rahmen des oder zusätzlich zu dem DATP-Protokoll(s) bereitgestellt.
  • Wie in 3 gezeigt, bietet der SGW-Server 1018 eine robuste Kommunikationslink zwischen der STB 1008 und einer Reihe verschiedener Applikationsserver 1026, 1028, 1030 und 1032, einschließlich dem Fetchmail-Server 1026. SGW 1018 routet Anforderungen zwischen der STB und Applikationsdiensten hin und her. SGW empfängt DATP-Pakete von dem/der Client/STB 1018, kontaktiert den richtigen Applikationsserver und sendet/empfängt Daten zum/vom Applikationsserver über die TCP/ID-Verbindung. SGW ermöglicht es einem Fremdserver oder SP-spezifischen Servern wie dem Fetchmail-Server 1026, Meldungen zur STB zu senden.
  • Wie in 4 gezeigt, hat die STB-/Client-Stack-Architektur mehrere Module sowie eine zusätzliche Schicht, den Meldungs-Manager 1104, zwischen der Applikation und dem nativen STB/Client-Transport. APIs sind für STB-Applikationen wie eine LHTTP API 1106 und eine Speicher- und Weiterleitungs-API 1108 vorgesehen. Der Server verwendet eine asynchrone Version der PAL-Schicht, implementiert Thread-Pools und Prozessisolationstechniken.
  • In einer bevorzugten Ausgestaltung ermöglicht DATP größere Meldungen und garantiert dabei die Lieferzuverlässigkeit und adressiert komplexe Speicherbelange aufgrund von eingeschränkten eingebetteten Umgebungen in der STB. Um die DATP-Meldungsgröße zu erhöhen, werden große Meldungen in kleinere Sektionen unterteilt, gesendet, umgeordnet und in einer rekonstruierten DATP-Meldung geliefert. Auf einer unzuverlässigen Link mit einer binären Fehlerrate (BER) von 10–64 beträgt die Wahrscheinlichkeit für einen Fehler in einer 64 KB-Meldung grob 7% (1 von 14 Meldungen). Wenn man weiß, dass die Übertragung von 64 KB über ein 2400 Bits Modem etwas länger als fünf Minuten dauert, dann vermeidet es DATP, dieselbe Meldung weitere fünf Minuten neu zu senden, nur weil eines seiner Bits verfälscht ist. Um eine Neuübertragung zu vermeiden, lauten die folgenden Implementationsrichtlinien für DATP vorzugsweise wie folgt.
  • In einer bevorzugten Ausgestaltung werden große Meldungen, d.h. Meldungen über 64 KB, in kleinere DATP-Pakete fragmentiert. Es können auch kleinere Fragmentgrenzwerte als 64 KB verwendet werden. Jedes DATP-Fragment wird separat quittiert. Wie in 8 gezeigt, verfolgt DATP Meldungssequenznummern und die Zeit, zu der die Sequenznummer zuletzt benutzt wurde. DATP-Meldungen mit einer „kürzlich" benutzten Sequenznummer werden als „bereits empfangen" abgelehnt. Um diese Richtlinie zu implementieren, führen DATP-Hosts ein Gleitfenster von kürzlich benutzten Sequenznummern mit einem Zeitstempel auf jeder Sequenznummer. Ältere Sequenznummern werden aus dem Fenster des Fernhosts entfernt, wenn sie älter als (host_max_retry+1)*host_timeout sind. In einer bevorzugten Ausgestaltung ist der Zeitabschaltwert programmierbar und kann auf jeden beliebigen Wert gesetzt werden.
  • Das Rückweisungsfenster verfolgt die Sequenznummern von Paketen, die in einem bestimmten Zeitrahmen empfangen wurden, beginnend mit der aktuellen Zeit. Wenn die DATP-Kernschicht ein Paket empfängt, dann wird ihre Sequenznummer im Rückweisungsfenster nachgeschlagen. Wenn die Sequenznummer in dem Fenster gefunden wird, dann wird sie verworfen, d.h. das Paket oder Fragment in Verbindung mit dieser Sequenznummer wird ignoriert. Wenn die Sequenznummer des Pakets nicht in dem Fenster gefunden wird, dann wird die neue Sequenznummer dem Fenster hinzugefügt. Das Fenster oder „Rückweisungsfenster" wird periodisch gereinigt, um Paketnummern zu beseitigen, die hinter einem bestimmten Datum liegen, je nach der auf der Kommunikationslink verwendeten Zeit. Der Paketrückweisungsfenster-Algorithmus schützt effizient vor einem mehrmaligen Empfang identischer Pakete, was bei zuverlässigen meldungsorientierten Transportprotokollen auf der Basis von Neusendung/Zeitabschaltung häufig auftreten kann.
  • DATP-Meldungen werden auf der Basis von Fernhost-Speicherbedingungen gesendet. Jedes quittierte Paket einer DATP-Meldung enthält ein Speicher-verfügbar-Feld, das den aktuellen Speicherzustand der empfangenden Entität anzeigt. Wenn DATP zum Senden einer Meldung zu einem Peer verwendet wird, dann prüft ein Fernobjekt zunächst, ob die DATP-Meldung kleiner ist als die in der empfangenden Entität verfügbare Speicherkapazität. Wenn an der empfangenden Entität die verfügbare Speicherkapazität zum Empfangen der Meldung ausreicht, dann werden die Fragmente der DATP-Meldung zum empfangenden Host gesendet. Nach dem Empfang der Meldung bestätigt der empfangende Host den Empfang der Meldung. Ansonsten sendet der sendende Host Steuerpakete zum empfangenden Host, um die Speicherverfügbarkeit des Fern- oder Empfangshost abzufragen. Bei Bedarf kann auch eine Teillieferung auf der Basis der verfügbaren Speicherkapazität implementiert werden, bei der nur ein. Teil einer Meldung gespeichert wird. In diesem Fall werden die Teilmeldungen bis zum Abschluss gecacht. Die Steuerpakete werden gesendet, bis ausreichend Speicherkapazität in der Fernentität verfügbar ist oder bis die Höchstzahl der Meldungsneusendeversuche überschritten ist. Wenn die Höchstzahl der Neuversuche überschritten ist und am empfangenden Host immer noch nicht genügend Speicherkapazität verfügbar ist, um die Meldung vollständig zu senden, dann verläuft die Meldungsübertragung erfolglos (es sei denn, dass eine Teillieferung der Meldung möglich ist).
  • Das DATP-Protokoll ist ein meldungsgestütztes Protokoll, bei dem eine Entität eine Meldung mit einer Liefergarantie zur anderen Entität sendet. Jedes Mal, wenn die STB eine Meldung zum Service-Gateway sendet, dann empfängt sie eine Bestätigungsmeldung, wenn die Meldung ihr Endziel erreicht hat (das Service Gateway selbst oder ein Applikationsserver). Wenn ein Applikationsserver die Meldung verarbeitet hat, kann eine Antwortmeldung zur STB gesendet werden, vorausgesetzt, die STB-Session mit dem Service Gateway ist noch offen. Der DATP-Meldungsübertragungsphase geht eine DATP-Login-Phase voraus und es folgt ihr eine DATP-Logout-Phase, die zum Herstellen einer DATP-Session nötig wird. Es ist wichtig zu bemerken, dass durch DATP gesendete Meldungen zu DATP-Paketen von höchstens MTU (Medium Transmission Unit) Bytes fragmentiert werden, die unabhängig gesendet und bestätigt werden. So können DATP-Meldungen so groß sein, wie dies DATP-Entitäten physisch verkraften können. 9 zeigt ein einfaches Beispiel für eine DATP-Session.
  • DATP unterstützt mehrere Sessions auf derselben STB-Transportschicht-Verbindung. STB-Clients können mitten in einer offenen Session mit den Service-Gateway-Login Pakete zum Starten einer neuen Session auf derselben exakten STB-Transportlink senden, die für die erste Session verwendet wurde. Beide DATP-Session-Management-Module im STB-Client und im Service Gateway sind für das Multiplexieren der verschiedenen Session-Meldungen auf derselben Link verantwortlich.
  • Zum Unterstützen der Übertragung großer Meldungen mit DATP greift das DATP auf einen Paketfragmentierungs/-rekonstruktionsansatz zurück. Große Meldungen werden in kleinere DATP-Pakete von höchstens MTU-Größe fragmentiert. Jeder Host hat eine MTU-Größe und jede DATP-Entität kann eine andere haben. Jedes Fragment (DATP-Paket) einer DATP-Meldung wird separat bestätigt.
  • Eine DATP-Meldung mit „kürzlich" benutzter Sequenznummer wird abgelehnt, um „Mehrfachempfang identischer Fragmente" von Wettlaufbedingungen zu vermeiden. Um diese Richtlinie zu implementieren, führen DATP-Hosts ein Gleitfenster mit kürzlich benutzten (Sequenznummer, Fragment-ID) Einträgen mit einem Zeitstempel auf jedem Eintrag in dem Fenster. Alte (Sequenznummer, Fragment-ID) Einträge werden aus dem Fenster eines DATP-Hosts beseitigt, wenn sie älter als (host_max_retry+1)*host_timeout sind.
  • Eine DATP-Fragmentgrößenvorgabe (d.h. MTU-Größe) ist auf 4 KB begrenzt, um begrenzte STB-Umgebungen zu berücksichtigen, wo Speicherfragmentierung von Belang ist. Die Fragmentgröße kann im Ermessen der Applikation auf maximal 64 KB erhöht werden.
  • DATP unterstützt bis zu 65536 Fragmente pro DATP-Meldung. Dies ergibt eine maximale theoretische Meldungsgröße von 4 GB. Das erste Fragment einer DATP-Meldung gibt einen Marker, der anzeigt, dass das Fragment ein erstes Fragment einer neuen Meldung ist, und sein Fragmentidentifikations-(ID) Feld wird auf die Zahl der Fragmente gesetzt, aus denen sich diese DATP-Meldung zusammensetzt.
  • Unvollständige DATP-Meldungen sollten nach (host_max_retry+1)*host_timeout aus Fernentitäten gelöscht werden.
  • DATP bietet Verschlüsselung, um es Applikationen zu ermöglichen, vertrauliche Daten zurück zu ihren jeweiligen Applikationsservern zu senden. Die Bereitstellung von Verschlüsselung auf der Transportebene adressiert das Problem des Bereitstellens von Verschlüsselung in der verarbeitungskapazitätsarmen STB- oder Client-Umgebung. Somit wird Verschlüsselung mit einem sorgfältig ausgelegten Verschlüsselungsansatz und einer bevorzugten DATP-sicheren API adressiert. Sicherheit/Verschlüsselung wird auf einer Session-Ebene bereitgestellt. Applikationen öffnen eine sichere Session über eine DATP-sichere API. DATP-Verschlüsselungsparameter werden beim Session-Login negoziiert. Eine sichere Session-Negoziation wird in wenigstens zwei Phasen bereitgestellt: während einer standardmäßigen DATP-Login-Phase und während einer Key-Negoziationsphase.
  • Es folgt eine kurze Beschreibung der Hauptschritte der Key-Negoziationsphase. Der DATP-Server sendet seinen Public-Key server_epk zu einem Client oder einer STB. DATP verwendet vorzugsweise Rivest, Shamir & Adleman (Public-Key-Verschlüsselungstechnologie) RSA (es können auch andere verwendet werden). DATP verwendet den RSA-Exponent server_epk = (e, n) so, dass e=3 oder größer ist, während ein robustes Sicherheitsniveau gewahrt bleibt (Sicherheit hängt nur von n ab). Da die STB zum Verschlüsseln einer Meldung mit RSA (me) mod n berechnen muss, bedeutet ein kleines „e", dass die Potenzierungsphase klein ist, was die Berechnung der verschlüsselten Meldung beschleunigt. Die STB oder der Client initialisiert ihren seinen Zufallsgenerator mit der Systemzeit plus einer eventuellen Zufallsquelle, die der O- Code-Schicht zur Verfügung steht (Beispiel: aktueller Video-Frame usw.). Die/der STB/Client holt einen STB/Client-Secret-Key (stb_sk). Die STB verschlüsselt den Secret-Key stb_sk mit server_epk mittels RSA. Die STB sendet den verschlüsselten Secret-Key stb_sk zum DATP-Server. Der DATP-Server entschlüsselt den verschlüsselten stb_sk mit seinem Private-Key server_dpk.
  • Der DATP-Server (z.B. SGW) initialisiert seinen Zufallsgenerator und nimmt einen Server-Secret-Key server_sk. Der DATP-Server (z.B. SGW) verschlüsselt server_sk mit stb_sk mit einem Secret-Key-Verschlüsselungsansatz. Der DATP-Server sendet den verschlüsselten server_sk zum DATP-Server. Die STB entschlüsselt den verschlüsselten server_sk mit ihrem Secret-Key stb_sk. Nach erfolgreichem Austausch der Keys können verschlüsselte Geheimdaten zwischen den beiden Entitäten über DATP mittels der Secret-Keys der jeweils anderen Entität ausgetauscht werden. In einer bevorzugten Ausgestaltung kommt ein DATP-Server-Authentifizierungsschritt zum Protokoll hinzu, um den Key-Austauschansatz zu erweitern und ihn gegen „Mittelmann"-Attacken robust zu machen. So sieht das DATP-Protokoll die Signierung von DATP-Stacks und die Verwaltung von Authentifizierungszertifikaten vor.
  • Um die Kommunikationszeit mit SGW minimal zu halten, wird der Public-Key des Servers vorzugsweise so in dem Stack eingebettet, dass die Verschlüsselung des STB-Private-Key offline erfolgen kann. Dies wirft eine neue Key-Management-Problematik auf, da der DATP-Server den Server-Public-Key kennen muss, der von der STB oder dem Client verwendet wird. Über eine sichere Session gesendete Meldungen werden vorzugsweise auf der Fragmentebene verschlüsselt. Dies bedeutet, dass jedes einzelne Fragment einer DATP-Meldung unabhängig verschlüsselt wird.
  • Einer DATP-sicheren API wird die Fähigkeit verliehen, unverschlüsselte Meldungen über eine sichere DATP-Session zu senden, so dass die SP-Applikationen die Option haben, CPU-Zyklen einzusparen, indem sie über eine sichere Session gesendete unvertrauliche Daten nicht verschlüsseln. Dies ist für Clients oder STBs mit begrenzter Verarbeitungsleistung, wie z.B. Motorola DCT 2000, nützlich.
  • Nach dem Herstellen einer sicheren Session zwischen einem DATP-Server und einem/r DATP-Client oder -STB werden von dem/der Client/STB zu einem Applikationsserver gesendete Meldungen zunächst im DATP-Server (z.B. SGW) entschlüsselt und dann über eine SSL-(Secure Socket Layer)-Verbindung zu Applikationsservern weitergeleitet. Die Verschlüsselungsschicht basiert auf einer kryptografischen Bibliothek, die O-Code- und Applikationsserver-Entwicklern zur Verfügung steht. Diese Bibliothek kann von Applikationen zum Verwalten von Verschlüsselung auf Applikationsebene verwendet werden. Diese Fähigkeit könnte beim Verwalten von End-zu-End-Verschlüsselung für Sicherheit in kritischen Applikationen wie solchen im Bankwesen nützlich sein.
  • Datenkompression auf langsamen Links wie z.B. den auf den meisten STBs und Clients (2400 bis 33.600 bps) es ist wünschenswert, um zum Erhöhen des Gesamtdurchsatzes der Leitung komprimierte Daten zu senden [sic]. In einigen Fällen steht Modemdatenkompression auf OSI-Link-Ebene zur Verfügung. Protokolle auf höheren Ebenen können durch Komprimieren ihrer Nutzdaten nicht merklich profitieren. Eine große Zahl von Client/STB-Modems bieten keine Kompression auf der Link-Ebene, daher wird Kompression durch Protokolle auf höherer Ebene bereitgestellt. Die vorliegende Erfindung bietet Datenkompression auf DATP-Server-Ebene.
  • Die Herausforderung besteht darin, dass STBs oder Client-Prozessoren nicht die nötige Kapazität haben, um effiziente Mustersuchläufe (oder andere CPU-intensive Operationen) auszuführen, die die meisten Kompressionsalgorithmen benötigen. Dekompression ist jedoch eine relativ leichte Aufgabe und es werden für die Clients/STBs auf O-Code-Ebene Dekompressions-APIs vorgesehen. Auf der Basis dieser Überlegungen ist der DATP-Support für Kompressions asymmetrisch, d.h. es wird vorzugsweise nur die Downlink vom DATP-Server zur STB oder zum Client mit standardmäßigen SP-Kompressionstools komprimiert.
  • Komprimierte DATP-Pakete haben einen „Daten komprimiert" Flag im Paket-Header, der angibt, dass die Nutzdaten komprimiert sind. Paket-Header werden nicht komprimiert. Kompression und Dekompression erfolgen mit standardmäßigen SP-Kompressions- und -Dekompressionstools und APIs. Die DATP-Paketgröße gibt die Größe der komprimierten Nutzdaten an. Die dekomprimierte Größe der Nutzdaten wird im Kompressions-Header der Nutzdaten angegeben. Die Kompression von DATP-Meldungen erfolgt auf der Fragmentebene. Jedes einzelne DATP-Paket einer DATP-Meldung wird unabhängig komprimiert. Dies wird deshalb bevorzugt, weil DATP-Meldungsfragmente beim Empfang nicht unbedingt zusammenhängend gespeichert werden, daher wird bevorzugt, dass DATP jedes Fragment separat dekomprimiert. Eine unabhängige Dekompression ist deshalb möglich, weil jedes DATP-Fragment unabhängig komprimiert wird. Der DATP STB Stack und die DATP-Applikationsserver-API können Datenkompression auf der Downlink sperren oder freigeben. Diese Funktion verleiht Applikationsservern wenigstens zwei wichtige Fähigkeiten, die Fähigkeit zum Übertragen großer Datenmengen zu Clients oder STBs unter Verwendung des schnellen Broadcast-Kanals und die Fähigkeit, Multicast-Daten zu mehreren Clients oder STBs durch den Broadcast-Kanal zu senden, wodurch SP-Gesamtbandbreite eingespart wird.
  • Der DATP-Server stellt ein Open Streamer Applikationsservermodul bereit, das eine konfigurierbare Anzahl von Broadcast-Strömen verwaltet. Diese Ströme werden zum Senden größer Datenblöcke sowie von Multicast-Daten zu Clients und/oder STBs verwendet. Multicasting wird als ein Merkmal bereitgestellt, das als Routing über Broadcast wichtig ist, da dadurch Applikationsserver Daten zu einer Gruppe von STBs senden können, ohne jede STB individuell zu adressieren. Multicast-Unterstützung in DATP bietet unzuverlässige DATP-Pakete. Die SP führt die Multicast-Gruppenliste von Session-Kennungen und handhabt Fälle, bei denen ein(e) STB oder Client ohne verfügbaren Broadcast-Tuner zu einer Multicast-Gruppe gehört.
  • Der DATP Name Service (DNS) bietet Mapping zwischen Applikationsservernamen und Dienstekennungen. Gut bekannte Dienste haben zwar reservierte Dienstekennungen, aber eine große Zahl von benutzerdefinierten Dienstekennungen steht zur Verfügung und kann von verschiedenen Applikationen verwendet werden. Um eine Festcodierung von Dienstekennungen in STB- oder O-Code-Applikationen zu vermeiden, haben Applikationen die Fähigkeit, sich nach einer Namensauflösungsstufe mit Namen auf Dienste zu beziehen. Auf diese Weise ist die Applikation weniger abhängig von der SGW-Konfigurationsdatei.
  • Es folgt eine Beschreibung davon, wie DATP-Clients DNS-Fähigkeiten verliehen werden. DNS wird vom Standpunkt des DATP-Protokolls aus einfach als ein anderer Dienst angesehen. Eine spezielle Dienstekennung wird für den DNS-Dienst reserviert. Der DNS-Dienst wird im SGW gehostet oder kann an anderer Stelle in der SP oder in einer STB oder in einem anderen Client gehostet werden. Der DATP-Client bietet eine einfache API zum Auflösen von Namen von Applikationsservern. Vorzugsweise gibt der Hauptruf (datp_get_asid_by_name (as_name)) synchron eine Anforderungsnummer zurück. Eine asynchrone Avisierung gibt im Erfolgsfall den Status der Namensauflösung einschließlich der Applikationsserverkennung zurück. Konkurrierende Namensauflösungen sind ohne signifikante Leistungsbeeinträchtigungen möglich. Benutzer können Namensserver-Avisierungen auf der Basis einer an jede Anforderung angehängte Anforderungskennung versenden. Der Namensparameter der Applikationsserver wird der aktuellen DNS-Konfigurationsdatei hinzugefügt. Es darf für unterschiedliche Dienstekennungen nicht derselbe Name verwendet werden. Zum Erzielen von Redundanz oder zum Erfüllen von Skalierbarkeitsanforderungen wird die Registrierung mehrerer Maschinen pro Dienstekennung unterstützt.
  • In der bevorzugten Implementation wird DNS als eine Instanz eines noch zu definierenden Verzeichnisdienstes angesehen. Das DNS-Anforderungspaketformat umfasst die folgenden Felder: Query Type (gibt den Abfragetyp an (z.B. 0 für DNS-Abfrage)), Query Tag (vom Benutzer gegebenes Etikett, das mit Verzeichnisdienst-Antworten zu vergleichen ist), Query Data (Daten, die zum Ausführen der Abfrageoperation verwendet werden (typischerweise der Name des Dienstes für DNS)). Das DNS-Antwortpaketformat umfasst die folgenden Felder: Answer Type (gibt den Antworttyp an (0 für DNS ist OK)), Answer Tag (dasselbe wie das Abfrageetikett, das die Antwort erzeugt hat) und Answer Data (Antwortdaten auf die Abfrage (typischerweise die ID des Dienstes für DNS)).
  • In einer alternativen Ausgestaltung von DATP wird angenommen, dass sich alle DATP-Clients hinter einem Modemeinschub befinden und der Modemeinschub-Anschlussserver für jeden angeschlossenen Client eine dedizierte TCP/IP-Verbindung mit dem SGW öffnet und alles weiterleitet, was er von einer bestimmten STB zu dieser TCP-Verbindung empfängt. Mit der möglichen Verwendung in Kabelkästen älterer Generationen ohne TCP/IP-Support, aber mit User Datagram Protocol (UDP) bietet der DATP-Server (z.B. SGW) die Fähigkeit, auf einen UDP-Port zu horchen. UDP wird wie folgt unterstützt. Auf dem Server wird eine neue datp_socket_listener Klasse zum Handhaben von UDP-Verbindungen erzeugt. Eine Abstraktionsschicht des Socket-Typs wird zum Aufnehmen von UDP-Sockets (PAL_udp_socket) erzeugt.
  • UDP-Verbindungen werden wie folgt verarbeitet. UDP_listener liest das neue Anschlussanforderungs-Datagram und erzeugt einen neuen AL_udp_socket. UDP_listener antwortet auf die Verbindung und sendet das Datagram mittels des neu erzeugten PAL_udp_socket. UDP_listener erzeugt einen neuen Session-Manager-Thread und leitet den neu erzeugten PAL_udp_socket als Attribut. Der neue Session-Manager antwortet dem DATP-Client direkt mittels pal_udp_socket_send mit dem bereitgestellten PAL_udp_socket. Man beachte, dass die Fernadresse des Datagram nicht vorgegeben zu werden braucht. Sie wird bereits vom UDP_listener beim Beantworten der Verbindungsanforderung eingestellt.
  • Auf der Client-Seite wird ein UDP stb_transport Modul erzeugt, das die bereits vorgegebene stb_transport API auf jeder UDP API implementiert, die in der/dem angepeilten STB oder Client verfügbar ist. Dieses UDP stb_transport sendet vorzugsweise ein Verbindungsanforderungs-Datagram zum SGW UDP Listener Port und wartet, bis es eine Antwort vom SGW erhält, bevor es den DATP-Kern avisiert, dass die STB-Transport-Link steht. Nachfolgende Datagrams werden über den Port gesendet, der in der Verbindungsanforderungsantwort vom SGW vorgegeben ist.
  • HTTP-Routing ist vorgesehen, um eine Schnittstelle für das SGW mit standardmäßigen Applikationsservern bereitzustellen, die Webserver als ihr Front-End verwenden. In diesem Fall verwendet DATP vorzugsweise nicht die standardmäßige DATP-Applikationsserver-API, die Applikationsserver-Entwicklern zur Verfügung steht, sondern schließt stattdessen durch Weiterleiten von DATP-Meldungen zu ihrem Webserver-Front-End mit dem HTTP POST (HTTPP) Mechanismus direkt an diese Applikationsserver an. Bei diesem Ansatz verwenden Client- und/oder STB-Anwendungen die DATP API, ohne zu wissen, dass sie mit einem HTTP-Server sprechen.
  • Um HTTPP zu unterstützen, ist ein DATP-Applikationsservertyp vorgesehen. Alle Server dieses Typs erhalten einen zusätzlichen Eintrag in der Namensserver-Konfigurationsdatei, um ihre Post-URL-Adresse vorzugeben. Das Applikationsserver-Kommunikationsmodul bietet die Fähigkeit, DATP-Meldungen zu HTTP-Servern je nach dem angepeilten Servertyp zu posten. Dieses Modul wird vorzugsweise in einen Applikationsserver-(AS)-Kommunikationsmanager und zwei AS-Datensender unterteilt. Ein AS-Datensender sendet Daten zu den mit DATP AS API kompatiblen Applikationsservern, ein anderer sendet Daten zu HTTP-gestützten Applikationsservern. Vom HTTP-Server empfangene HTTP-Cookies werden im SGW gespeichert und nach Bedarf neu zum HTTP-Server gesendet. Auf einer sicheren DATP-Session empfangene DATP-Meldungen werden mit HTTPS zu HTTP-Servern weitergeleitet. DATP-Login und -Logout sind vorzugsweise nicht anonym, um es zu ermöglichen, dass das SGW den Zugang zu SP-interaktiven Diensten steuert und es Applikationsservern ermöglicht, auf die Identität eines angeschlossenen Client zuzugreifen.
  • Es folgt eine weitere Beschreibung der STB- oder Client-Identifikation als Teil von DATP. DATP-Stacks enthalten eine von STB oder Client abhängige eindeutige Hardware-Kennung (HID). Im Falle einer STB wird diese Hardware-Kennung von der STB/Netzwerk-abhängigen STB-Transportschicht abgerufen. Das HID-Format ist eine Zeichenfolge veränderlicher Länge. Die HIDs für ein bestimmtes Netzwerk werden in einer HID-Liste gespeichert. Der Netzwerkbetreiber aktualisert die HID-Liste über SP von seiner Kundendatenbank über APIs. In dem Fall, in dem eine direkte Verbindung mit der Netzwerkbetreiber-Subscriber-Datenbank nicht möglich ist, importiert die SP die Subscriber-Informationen (einschließlich der HID) von einer zweidimensionalen Datei.
  • Zum Herstellen von DATP-Sessions beinhalten STB- oder Client-DATP-Stacks ihre HID innerhalb des DATP-Login-Pakets. Das SGW prüft die Gültigkeit der HID unter Verwendung eines zentralen Repository. Wenn das zentrale Repository die HID bestätigt, dann wird Zugang zum STB-Stack gewährt. Die HID ermöglicht es dem SGW, die Identität einer/s STB oder Client zu ermitteln. Ähnlich wie bei HTTP-Cookies, authentifiziert eine HID eine(n) Fern-STB- oder -Client nicht „streng". So erfolgt eine formelle Authentifizierung von Fernbenutzern vorzugsweise durch Anwendungen, die eine robustere Authentifizierung ihrer Fern-Peers benötigen.
  • DATP bietet LHTTP von HTTP-Funktionen zu O-Code-Applikationsentwicklern, die es ihnen ermöglichen, mit Fern-HTTP-Servern zu interagieren. LHTTP wird bereitgestellt, um die Entwicklung von webähnlichen HTTP-gestützten Applikationen zu ermöglichen. LHTTP erfüllt die derzeitige H2O-Strategie, indem es eine OS-unabhängige vereinfachte HTTP-Schnittstelle für Rückkanalkommunikationen zwischen Client, Netzwerkbetreiber und Diensten bietet. Die LHTTP-Schnittstelle basiert auf dem DATP-Stack und verkapselt HTTP-Anforderungen zu DATP-Meldungen. Eine spezielle DATP-Dienstekennung wird der LHTTP-Schicht und den auf dieser Dienstekennung empfangenen DATP-Meldungen zugewiesen, die mittels eines speziellen LHTTP-Datensendemoduls im SGW zum Ziel-HTTP-Server geleitet werden.
  • Es wird vorzugsweise ein begrenzter Satz von HTTP-Befehlen unterstützt, der GET- und POST-Befehle umfasst. Zusätzliche HTTP-Befehle können zum LHTTP addiert werden. LHTTP-Anforderungen werden am SGW in echte HTTP-Anforderungen transformiert. HTTP-Anforderungen erfolgen vom SGW im Namen von LHTTP-Clients. Cookies werden zu LHTTP-Clients weitergeleitet. SGW cacht die Cookies und führt eine Cookie-in-Session-ID-Umsetzungstabelle. DNS beantwortet HID-Auflösungsanforderungen von HTTP-Servern mittels dieser Umsetzungstabelle. HTTP-Server verwenden vorzugsweise die HID zum Extrahieren von Benutzerinformationen vom Zentralregisterserver. LHTTP bietet auch eine sichere API, LHTTPS. Diese API basiert auf der DATP-Verschlüsselungsschicht. LHTTPS-Anforderungen werden am SGW automatisch in HTTPS-Anforderungen umgesetzt.
  • SMTP-(Simple Mail Transfer Protocol)-Routing oder einfache Weiterleitung von Meldungen per Email werden einer Schnittstelle zwischen dem SGW und Applikationsservern bereitgestellt. Diese Schnittstelle kann für Nicht-Echtzeit-Transaktionen verwendet werden, bei denen eine Applikation DATP-Meldungen zu SMTP-gestützten Applikationsservern sendet, und diese Meldungen per Email zu den angepeilten Applikationsservern weitergeleitet werden.
  • Um SMTP-Routing zu unterstützen, wird ein DATP-Applikationsservertyp für SMTP-Applikationsserver erzeugt. Server dieses Typs haben zusätzliche Einträge in der Namensserver-Konfigurationsdatei zum Vorgeben ihrer Email-Adresse sowie des Email-Betreffs von weitergeleiteten Meldungen. Das Applikationsserver- Kommunikationsmodul postet DATP-Meldungen zu SMTP-gestützten Applikationsservern je nach dem angepeilten Servertyp. Ein SMTP-Applikationsserver-Datensendemodul ist vorgesehen, um diesen Transaktionstyp zu unterstützen. Zu SMTP-Applikationsservern gesendete DATP-Meldungen werden an mehrteilige MIME-(Multipurpose Internet Mail Extensions)-codierte Emails angehängt. Der erste Teil der Meldung enthält die Hardware-Kennungen der Sender sowie die DATP-Meldungs-ID der weitergeleiteten Meldungen. Der zweite Teil der Meldung enthält MIME-codierte DATP-Meldungen.
  • Zu einem SMTP-Applikationsserver gesendete DATP-Meldungen werden bestätigt, wenn sie von einem Session-Manager decodiert wurden und zum Senden zum angepeilten Applikationsserver per Email bereit sind. Nachfolgende SMTP-bezogene Fehler könnten auftreten, wenn das SGW versucht, die DATP-Meldung per Email zum angepeilten Applikationsserver zu liefern. Mit der DATP-Verschlüsselungsschicht gesendete Meldungen würden unverschlüsselt zum End-Host weitergeleitet. Auch PGP-Verschlüsselung wird unterstützt, um DATP-Meldungen sicher über SMTP zu leiten.
  • Der DATP-Speicher- und Weiterleitungsdienst bietet Funktionen für Applikationen zum Senden von Nicht-Echtzeitmeldungen zu einem bestimmten Applikationsserver. Eine Speicher- und Weiterleitungsbibliothek ist auf DATP vorgesehen. Die Applikation verwendet das Speicher- und Weiterleitungsmodul zum Senden von Meldungen mit unterschiedlichen Zeitbeschränkungen je nach. ihren Bedürfnissen. Zeitbeschränkungen variieren von „so bald wie möglich", „eine bestimmte Zeit", „ein(e) bestimmte(s) Auftreten, Event oder Meldung" bis „sobald wir angeschlossen sind" einschließlich „nach einer zufälligen Zeitperiode".
  • Das Speicher- und Weiterleitungsmodul speichert ungelieferte DATP-Meldungen im Dateisystem zusammen mit einigen speziellen Attributen (Zeitstempel, Zeitbeschränkungen, angepeilte AS-Kennung usw.). Der Dateisystemspeicherpfad ist wenigstens zur Kompilationszeit für ein bestimmtes Netzwerk konfigurierbar. Meldungen, die nicht weitergeleitet werden, während eine bestimmte DATP-Speicher- und Weiterleitungs-enabelte Applikation läuft, werden erst dann weitergeleitet, wenn eine andere Speicher- und Weiterleitungs-enabelte Applikation startet. Das Speicher- und Weiterleitungsmodul verändert den Inhalt der weitergeleitetetn DATP-Meldung nicht. Die Meldung wird ohne Veränderung zum angepeilten Applikationsserver weitergeleitet.
  • 4 zeigt die DATP-Architektur des Client-Stack, der mehrere Module umfasst. Die Module unter der Linie 1121 sind im Client-Nativcode geschrieben, Module über der Linie 1121 sind in O-Code geschrieben. Das Lightweight-HTTP-Modul 1106 bietet Lightweight-HTTP-Fähigkeiten für O-Code-Applikationen. Es wird auf der DATP API implementiert. Das Speicher- und Weiterleitungsmodul 1108 bietet Speicher- und Weiterleitungsfähigkeiten für O-Code-Applikationen. Es wird auf der DATP API implementiert. Das DNS-Modul 1110 nutzt das DATP-Meldungsmanager-Modul 1104 zum Leisten von DATP-Namensauflösungsdiensten. Das DATP-Meldungsmanager-Modul 1104 ist das Front-End von DATP. Alle DATP-meldungsbezogenen API-Rufe gehen durch das DATP-Meldungsmanager-Modul. Dieses Modul unterteilt Meldungen in DATP-Pakete und rekonstruiert DATP-Pakete zu Meldungen. Das DATP-Transportkernmodul 1102 verwaltet DATP-Sessions, sendet und empfängt DATP-Pakete und verwaltet DATP-Modulempfang von Broadcast. Das DATP-sichere Transporterweiterungsmodul 1120 handhabt sichere DATP-Sessions. Die DATP-Paketbibliothek 1134 bietet die Funktionen zum Lesen (Parsen) und Schreiben (Komponieren) von DATP-Paketen zum DATP STB Transportmodul 1132 auf der Basis der DATP-Paketformatspezifikation. Nach dem Lesen eines vollständigen DATP-Pakets avisiert dieses Modul den DATP-Transportkern mit dem geparsten DATP-Paket.
  • Die DATP-Broadcast-Bibliothek 1126 horcht auf gewählte SP-Ströme auf der Basis der Spezifikationen des DATP-Transportkerns 1102 und wartet auf Module, die für eine(n) bestimmte(n) STB oder Client bestimmt sind, und avisiert den DATP-Transportkern 1102 mit den geparsten DATP-Modulen. Das DATP STB Transportmodul 1132 bietet eine Paketschnittstelle auf Link-Ebene auf der nativen Transport- oder Daten-Link, die auf dem DATP-Host verfügbar ist. Der Event-Loop-Stub 1116 bietet eine Stub-Version der in der DATP-Portabilitätsschicht vorgegebenen Meldungs-API. Dieser Stub basiert auf dem Event-Loop der gemeinsamen Bibliothek. Die Rolle der Portabilitätsschicht 1114 besteht darin, den DATP-Stack von applikationsabhängigen Belangen wie Meldungsversandmechanismus, Verschlüsselungs-APIs usw. zu abstrahieren. Der kryptografische Bibliothek-Stub 1118 ist eine Stub-Version der in der DATP-Portabilitätsschicht vorgegebenen kryptografischen API. Dieser Stub basiert auf dem gemeinsamen Bibliotheksverschlüsselungspaket. Der Modul-Lib-Stub 1124 ist eine Stub-Version der in der DATP-Portabilitätsschicht vorgegebenen Multitrack-Modul-Download-API. Dieser Stub basiert auf dem Multitrack-Modul-Download-Paket der gemeinsamen Bibliothek.
  • 6 zeigt DATP als Bestandteil des Digital TV Application Protocol (DAP). DAP/DATP ist in 6 dargestellt. DAP wird zum Standardisieren von Rückkanalkommunikationen zwischen SP-Applikationen und SGW verwendet. DATP und SGW bieten einen generischen virtuellen Transportmechanismus zu SP-Applikationen, da nicht alle SP-enabelten STBs eine TCP/IP-Stack-Erweiterung bieten. Außerdem können einige der STBs ihren eigenen proprietären Stack haben oder überhaupt keinen Kommunikationsstack bereitstellen.
  • DAP ist eine einfache leichtgewichtige Applikationsprotokollsuite. Der Hauptzweck von DAP besteht darin, eine einfache und wirksame Weise zu bieten, um existierende Applikationsprotokolle wie POP3, SMTP, IMAP (Internet Message Access Protocol) und andere an Low-End-STBs anzupassen. STBs haben häufig kapazitätsarme Verarbeitungsressourcen und/oder proprietäre Kommunikationsprotokolle. DAP ist zum Abstrahieren von Kommunikationskomplexität von den Applikationsanbietern ausgelegt, so dass wiederum existierende Netzwerkinfrastruktur an heutige Applikationsstandards angepasst wird.
  • Gemäß 6 ist DAP in zwei Teile unterteilt: DAML 1610 – Digital-TV-Applikations-Metasprache, und DATP 1620 – Digital-TV-Applikationstransport-Protokoll. DAML 1610 ist eine Metasprache, die viele SP-Applikationen überspannt. Jede SP-Applikation hat ihre eigene DAML-Domäne. Die Client-Applikation antwortet auf in einer DAML-Domäne verkapselte Meldungen und fordert sie an. Diese Anforderungsmeldungen werden von Applikationsservern in das geeignete Protokoll für existierende Applikationen wie SMTP oder IMAP umgesetzt.
  • DATP 1620 ist ein leichtes, einfaches Transportprotokoll für bandbreitenarme Applikationen, wenn TCP/IP oder andere bekannte Protokolle nicht zur Verfügung stehen. DATP ist für eine Verbindung mit existierenden Kommunikationsprotokollen in derzeitigen STBs ausgelegt. DAP umfasst Folgendes: DATP, DAML-Mail (XML-Domäne für Mail); DAML-Regi (XML-Domäne für Kontoregistrierung); und DAML-Acct (XML-Domäne für den Zugriff auf SP VMS/AMS-System).
  • Typische STBs basieren auf einer Thin-Client-Architektur, d.h. sie besitzen minimale Verarbeitungskapazität. Die von heutigen STBs bereitgestellten Dienste sind häufig „unintelligente" Low-End-Applikationen. Heutige ressourcenintensive Applikationen wie Email, Chat und Internet-Browser benötigen leistungsstärkere Verarbeitungsgeräte. Heutige STBs können diese Art von Verarbeitungsleistung nicht bieten, daher die Notwendigkeit für ein leichtes Low-End-Applikationsprotokoll. DAP ist einfach genug, um die Client/Server-Netzwerkkomplexität vom Applikationsentwickler zu verbergen oder zu abstrahieren.
  • DAP ist modular, flexibel und an zukünftige Software-Architekturen anpassbar. Hierbei könnte es sich entweder um ein auf der Common Object Request Broker Architecture (Object Management Group) (CORBA) basierendes Modell oder um ein Common Object Module (COM)/Distributed Component Object Module (DCOM) Modell handeln. DAP ist flexibel genug, um existierende Fremd-Legacy-Systeme aufzunehmen und zu integrieren. DAP bietet eine Schnittstelle zu verschiedenen offenen und proprietären Protokollen. Diese Protokolle gibt es für Dienstesysteme, bei denen der PC der Haupt-Client ist, z.B. IMAP oder POP3 Dienste. DAP beeinflusst die SP-Middleware-Technologie. DAP-Serverware setzt das DAP-Protokoll in existierende applikationsspezifische Protokolle um.
  • DAP und sein Bestandteil DAML 1610 sind leichtgewichtig ausgelegt und in der Lage, bandbreitenempfindliche Low-End-STBs zu unterstützen. DAML-Etiketten sind vorzugsweise nicht größer als 4 Zeichen und nach Möglichkeit auf 2 oder 3 Zeichen begrenzt. DAML beinhaltet binäres XML zum Erleichtern von DAML-Etiketten. DAP wird als Kommunikationsprotokoll zwischen Applikationen verwendet, die auf der STB und Service-Subsystemen laufen. DATP 1620 steuert Kommunikations-Handshaking, Routing und transportspezifische Authentifizierung, während DAML die applikationsspezifischen Anforderungen verwaltet. DAML-Anforderungen und -Antworten werden zwischen einem STB-Client und einem Diensteanbieter über ein existierendes Kommunikationsprotokoll wie z.B. TCP, UDP, DATP oder ein proprietäres Kommunikationsprotokoll übermittelt.
  • Das DAP-Protokoll und sein Bestandteil DAML können eine sessionorientierte oder „sessionlose" Protokoll-Suite sein. DAML-Domänen sind applikationsabhängig. Neue Domänen des DAP-Protokolls können für neue Applikationstypen verwendet werden. Das Hinzukommen neuer DAP-Domänen hat nur wenig Einfluss auf existierende DAP-Domänen. So bietet DAP eine eindeutige und simple SP für Netzwerkbetreiber zum Hinzufügen zusätzlicher Dienste, ohne existierende Dienste zu beeinträchtigen. Jede DAML-Domäne kann entweder auf einem einfachen, vom Menschen lesbaren Etikett oder einem kryptisch abgekürzten Etikett zum Erhöhen der Protokollleistung durch Verringern der Paketgröße basieren, wenn Leistung ein kritischer Faktor ist.
  • Nachfolgend wird die Rolle von DAML in der DAP-Architektur umrissen. DAML ist ein Kommunikationsprotokoll auf Applikationsebene, das zum Vorgeben von Kommunikationsverhalten und Kommunikationsdaten für interaktive Fernsehdienste benutzt wird. Das Kommunikationsprotokoll auf Diensteebene liegt über dem Transportebenenprotokoll. Es definiert, wie der applikationsspezifische Inhalt zwischen Client/Server-Kommunikationen verkapselt wird.
  • DAML ist eine Sammlung von domänenspezifischen Protokollen, die ein modulares Design der SP ermöglicht. So ist beispielsweise DAML-Mail ein Bestandteil von DAP. DAML-Mail ist ein Maildomänen-spezifisches Protokoll. Neue domänenspezifische Protokolle können als Bestandteil von DAP einfach durch Erzeugen neuer DTDs hinzugefügt werden. DAP gibt das Kommunikationsverhalten durch das Senden und Empfangen von DAP-Meldungen vor. Die applikationsspezifischen Daten werden in einem XML-Format verkapselt. Die Syntax jeder XML-Applikationsdomäne gibt die Aktionen vor, die die Applikationsserver ausführen sollen. So können äußerst leichte und einfache Protokolle entworfen werden, die heutige STBs für eine Verbindung mit existierender Infrastruktur wie SMTP-Diensten und IMAP-Diensten nutzen können.
  • DATP ist ein Protokoll auf Transport/Dienste-Ebene, das eine Kommunikationsplattform zwischen SGW und mehreren STBs oder Clients bietet. DAML ist in einem DATP-Paket verkapselt. Protokolle auf Diensteebene liegen im Allgemeinen über Transportprotokollen, aber DATP ist dahingehend einzigartig, dass es in einem typischen Netzwerkmodell entweder auf Service-Ebene, Datenlink-Ebene oder Transportebene sitzen kann. Dies macht DATP sehr flexibel. DATP hat Verbindung mit den zu Grunde liegenden Transportprotokollen wie TCP, UDP, X.25, Raw Sockets oder anderen Protokollen.
  • SGW bietet Routing- und SGW-Technologie für Low-End-STBs, die mit einer Netzwerk-Backend-Infrastruktur verbunden werden sollen. SGW bietet Protokollunterstützung auf Transportebene zwischen STB/Clients und SGW, z.B. ein Sequential-Stream-Protokoll über Raw-Sockets. DAML beeinflusst dieses Merkmal.
  • DAML-Mail ist ein Protokollteil von DAP. DAML-Mail ist ein Maildomänen-spezifisches Protokoll. Dieses Protokoll dient zum Verbinden von STBs mit IMAP-, POP3- und SMTP-Diensten. DAML-Regi ist ein DAP-Servicedomänen-Protokoll, das eine generische Methode für die Registrierung von Konten für mehrere Dienste vorgibt. DAML-Regi ist ein einfaches Protokoll zwischen einer STB und dem Registrierungsserver. Dies ermöglicht komplexe Interaktionen zwischen einer STB und einer Reihe verschiedener Applikationssysteme, mit nur einem einzelnen Integrationspunkt, dem Registrierungsserver.
  • DAML-Acct ist ein DAP-Servicedomänen-Protokoll, das mit der SP VMS/AMS Datenbank kommuniziert. DAML-Acct ermöglicht es der/dem STB/Client, benutzerspezifische Daten vom VMS/AMS-System abzufragen und zurückzusenden. Alle DAML-Domänen werden mit XML-Dokumenttyp-Definition-(DTD)-Syntax definiert. DTDs beschreiben die Meldungssyntax, aber nicht die Logik für den Austausch von Anforderungen und Antworten. XML ist zum Definieren der Auszeichnung eines Textblocks nützlich. Spezifische DAML-Anforderungen und -Antworten sind aufeinander bezogene Interaktionen. Die Regeln für ihre Interaktion werden in der STB und Applikationsserver-Komponenten modularisiert.
  • Der Messaging-Manager bietet verschiedene Typen von Meldungskommunikationen zwischen den Benutzern und mit Außenstehenden (solchen, die keine Netzwerkdienste-Subscriber sind). Er ermöglicht es beispielsweise Benutzern, Emails zu senden und zu empfangen, mit anderen Nicht-Subscribern zu chatten und Sofortmeldungen von Nicht-Subscribern zu empfangen. Der Email-Teil des Messaging-Managers enthält eine Fetchmail-Komponente, die mit einem Internet-gestützten Email-Server wie IMAP-, POP3- und anderen Webmail-Meldungen für den geeigneten Mail-Hosting-Server verbunden ist.
  • Fetchmail verwaltet das gesamte SP-Server-seitige Mail-Management. Fetchmail setzt DAP-Meldungen in IMAP-, POP3- oder Webmail-Meldungen für den geeigneten Mail-Hosting-Server um. SGW leitet DAP-Mail-Meldungen zwecks Verarbeitung zu „Fetchmail". Fetchmail reagiert mit der richtigen Antwort auf die Anforderung. Fetchmail schließt an IMAP-Server an. Eine Email-Applikation wird von der SP bereitgestellt. Alle SP-Applikationen können Email über den vom SGW geleisteten Email-Dienst ,senden'.
  • Der Chat-SP-Dienst schließt an einen Chat-Server an oder beinhaltet alternativ einen Chat-Server. Auf einen Chat-Dienst kann durch eine dedizierte Chat-Applikation zugegriffen werden, aber auch von jeder SP-Applikation, die eine Link mit der SP-Chat-Client-DLL hat. Durch Bereitstellen einer Schnittstelle zwischen einem Chat und einem Programmlisting kann ein Chatroom dynamisch mit einer Broadcast-Show erzeugt werden. Applikationen und andere Dienste können den SP-„Alert"-Dienst zum Auslösen von STB-residenten Miniapplikationen verwenden. Alert nutzt die SP OMM Erweiterung und Funktionalität von Open Streamer. Der Email-Dienst verwendet Alert-Trigger zum Informieren des Zuschauers über eine eingehende Meldung.
  • 10 beschreibt die DATP-Verbindungszustandsmaschine. Diese Zustandsmaschine beschreibt das Verhalten einer DATP-Session-Verbindungszustandsmaschine von der STB-Client-Seite her. Eine Session muss im angeschlossenen Zustand sein, bevor sie ein Datenpaket zum SGW sendet, und muss nach einer Logout-Anforderung vom Client abgetrennt werden. 11 beschreibt den Meldungssendezustand. Diese Zustandsmaschine beschreibt, wie eine DATP-Entität ein DATP-Datenpaket zu einer anderen DATP-Entität sendet. 12 beschreibt die Meldungsempfangszustandsmaschine. Diese Zustandsmaschine beschreibt, wie eine DATP-Entität ein DATP-Datenpaket von einer anderen DATP-Entität empfängt. 13 beschreibt die „Keep-Alive"-Zustandsmaschine. Diese Zustandsmaschine beschreibt, wie eine DATP-Entität Ping-Pakete benutzen soll, um zu gewährleisten, dass eine DATP-Link mit der anderen Entität bestehen bleibt. Wenn es sich herausstellt, dass die Link nicht mehr steht, dann wird ein Logout eingeleitet.
  • SGW
  • Nun mit Bezug auf 5, SGW beinhaltet mehrere Module zum Unterstützen von DATP-Merkmalen. Die SGW-Architektur ist eine Multiprozess-gestützte Architektur, die Thread-Pools bereitstellt. Der gesamte Server läuft auf einer asynchronen Version einer Plattform-Abstraktionsschicht (PAL). Die PAL implementiert einen Meldungswarteschlangenprozess. PAL kommuniziert mittels Meldungspassiertechniken. Wie 5 zeigt, verwendet SGW drei Typen von Prozessen.
  • Wie in 5 gezeigt, kommunizieren Applikationsserver oder Dienste mit mehreren Clients/STBs durch das SGW über ein domänenspezifisches DAP-Protokoll. In bestimmten Fällen können Clients/STBs sich direkt an die Applikationsdienste anschalten. Wenn beispielsweise das Transportprotokoll zwischen der STB und dem Netzwerk TCP/IP ist, dann ist die STB TCP/IP-enabelt und es besteht keine Notwendigkeit, vom SGW bereitgestellte komplexe gemeinsame Dienste auszuführen, eine schnellere Netzwerkleistung kann über eine Direktkommunikation von Client/STB mit einem Dienst über TCP/IP verbessert werden.
  • Gemäß 7 ist der SGW-Hauptprozess des DATP-Servers der oben beschriebene Haupt-DATP-Serverprozess. SGW hostet mehrere wichtige Module. Das TCP-Socket-Listener-Modul 1204 ist ein einfacher TCP-Socket-Listener-Thread, der auf Verbindungen auf dem DATP TCP Listen-Port wartet, sie akzeptiert und die Erzeugung neuer Session-Manager zum Handhaben neuer Verbindungen anfordert. Der UDP-Socket-Listener 1202 wartet auf einem gut bekannten Port auf UDP-Verbindungen. Nach dem Eingang einer Verbindungsanforderung erzeugt der UDP-Socket-Listener 1202 einen neuen Socket und sendet eine Verbindungsanforderungsquittung zum Fern-Host. Der UDP-Socket-Listener 1202 fordert dann die Erzeugung eines neuen Session-Managers zum Handhaben der Verbindung an.
  • Das Session-Manager-Monitor-Modul 1206 ist Teil des Hauptthread. Die Hauptrolle dieser Komponente besteht darin, die Population von Session-Manager-(SM)-Prozessoren 1214 (Erzeugen und Löschen von SM-Prozessoren auf Lastbasis) zu überwachen und Session-Manager-Erzeugungsanforderungen zu dem am wenigsten beschäftigten SM-Prozessor 1215 weiterzuleiten. Jeder SM-Prozessor (0-n) 1215 umfasst ein DATP-Applikationsserver-Kommunikationsmodul (ASCM) 1217 und einen separaten Applikationsserver-Datensender (ASDS) für DATP, HTTPP, LHTTP und SMTP.
  • Der DNS-Namensserver-Thread 1212 führt eine Abgleichtabelle zwischen Applikationsserver-Kennungen und deren Attributen (Hostname, Port, Typ usw.) sowie eine Abgleichtabelle zwischen Session-Kennungen und Session-Manager-Meldungswarteschlangenkennungen. Das Namensservermodul DNS beantwortet Namensauflösungsanforderungen, die auf seine Meldungswarteschlange gepostet wurden. Der Applikationsserver-Socket-Listener-Thread 1208 ist dafür verantwortlich, auf von Applikationsservern kommende Meldungspostieranforderungen zu warten. Der Namensserver 1212 leitet dann die Postieranforderungen zu den angepeilten Session-Managern auf der Basis der Post-Anforderung-Session-Kennung weiter.
  • Der Session-Managerprozessor-Prozess 1214, 1216 hostet einen Pool von Session-Manager-Threads 1215. Neue Session-Manager-Threads werden auf der Basis von Anforderungen vom Session-Manager-Monitor 1206 zum Session-Manager-Prozessorthread erzeugt. Der Session-Manager-Prozessor-Thread 1214, 1216 kommt Anforderungen von den Session-Manager-Prozessoren 1214, 1216 nach und erzeugt oder löscht Session-Manager auf der Basis von Anforderungen vom SM-Monitor und avisiert den Session-Manager-Prozessor über das Ergebnis seiner Anforderungen. Session- Manager-Threads 1215 verwalten DATP-Sessions und leiten DATP-Meldungen von STBs oder Clients zu Applikationsservern und umgekehrt weiter. Es gibt pro STB oder Client einen Thread. Diese Threads nutzen mehrere wichtige Module zur Handhabung von DATP-Sessions (Paketbibliothek; Applikationsserver-Kommunikationsmodul; DATP-Applikationsserver-Datensender; HTTPP-Applikationsserver-Datensender; LHTTP-Applikationsserver-Datensender und SMTP-Applikationsserver-Datensender).
  • Der Broadcast-Manager-Prozess 1210 ist die Hauptkomponente von DATP-Routing über Broadcast. Dieser Prozess ist ein Open Streamer Applikationsserver, der DATP-Server-Karussells verwaltet. Der Broadcast-Manager-Prozess aktualisiert diese Karussells dynamisch in Abhängigkeit von Anforderungen, die er von anderen Komponenten des DATP-Servers erhält.
  • SP und SGW werden vorzugsweise auf dem Datenverarbeitungssystem Sun Solaris 7 mit Memory, Monitor, GUI, Maus, Tastatur und Prozessor unterstützt, das in der Technik gut bekannt und von Sun Microsystems erhältlich ist. SGW läuft als UNIX Daemon, wird mit einer Konfigurationsdatei konfiguriert und von der Befehlszeile aus gestartet. Nach dem Herstellen einer Verbindung zwischen SGW und STB/Client über ein Netzwerk handhabt TCP/IP alle Kommunikationen zwischen den anderen Diensten. Neben der Handhabung unterschiedlicher Transportprotokolle routet das SGW auch Meldungen zu verschiedenen Service-Untersystemen je nach der Konfiguration von SGW.
  • SGW führt seine Funktionen an der Eintrittsstelle zu den Applikationsservern aus. So können Merkmale leicht konfiguriert und/oder hinzugefügt werden, da Netzwerk- und Messaging-Funktionen auf SGW isoliert sind. Dies befreit die Service-Subsysteme, so dass sie auf Kernapplikationsfunktionen arbeiten können, und überlässt Netzwerkkonnektivitätsprobleme dem SGW. Dies bietet auch größere Skalierbarkeit durch Isolieren spezieller Funktionen zu separaten Hosts; Email-Meldungslieferung und -empfang (mit dem Fetchmail-Server) von Netzwerk-Routing und Sicherheit mit SGW.
  • SGW ist so bemessen, dass es hunderte von gleichzeitigen Verbindungen auf einem einzigen Server unterstützt. SGW kann so konfiguriert werden, dass es mehr Verbindungen handhaben kann, je nach der Verarbeitungsleistung des das SGW hostenden Prozessors. Diese Grenze basiert auf der Anzahl der Modeme (typischerweise mehrere hundert) pro POP (Point of Presence) für bedeutende ISPs. Im Falle einer WAN-Architektur, bei der sich das SGW an einer zentralen Stelle befindet, ist ein auf Hardware-Netzwerkadressumsetzung (NAT) basierendes Lastausgleichsgerät für den parallelen Anschluss mehrerer SGWs zum Verteilen der Last vorgesehen.
  • Inhaltsumsetzung – H2O
  • Es folgt ein Überblick über die H2O Proxy Umgebung mittels einer Logikübersicht über H2O-Architektur und Transaktionsbeispiele. URI-Anforderungen können entweder von unterschiedlichen H2O-Komponenten kommen – z.B.: STB/SGW und Karussell. Der Fokus der folgenden Kontextüberblick ist, dass STB/SGW die Anforderungen ausgibt – aber der allgemeine Informationsfluss bleibt gleich.
  • Ein Zuschauer beschließt, mit seiner TV-Webseite zu interagieren und gibt somit eine Anforderung von der STB an das H2O-System aus und wartet auf eine Antwort. STB-Anforderungen werden mit Lightweight-HTTP-Anforderungen (LHTTP) zum SGW gesendet, in DATP-Meldungen als Transportprotokoll verkapselt. Das angeforderte Objekt wird durch den-/dasselbe(n) Kanal und Protokoll zurückgegeben. Das SGW konvertiert das LHTTP-Protokoll in Standard-HTTP über TCP/IP und gibt die Anforderung an einen Web-Cache aus.
  • Der Compiled Object Cache (COC) verwendet seinen internen Speicher zum Bedienen jeder Anforderung, die er bedienen kann (nach einer heuristischen Berücksichtigung der Lebenszeit von Objekten). Seine Rolle besteht darin, alle statischen Objekte zu bedienen (standardmäßige URL-Adressen ohne Abfragen, keine gepostete Form), ohne den H2O Proxy abzufragen, wodurch seine Verarbeitungslast reduziert wird. In dieser Architektur speichert der COC nur kompilierte Objekte (H2O-Module). Die COC-Maschine ist E/A-gesteuert.
  • Gemäß 14 bietet der H2O-Proxy 248 eine skalierbare Umgebung, auf der die verschiedenen H2O-Compiler (oder Filter) laufen können. Er verarbeitet HTTP-Anforderungen und Antworten „on the fly" (nebenbei) und somit ist die H2O Proxy Maschine prozessgesteuert. Der H2O HTML Compiler 1420 ist für die HTML-in-SP-Ressourcen-Kompilation verantwortlich. Zum Berechnen des zu rendernden TV Layout 1422 gibt diese Komponente HTTP-Anforderungen alleine auf der Basis der Größe der eingebetteten Bilder aus. Dieser Compiler ordnet das webgestützte Bild so um, dass es zum Client-Anzeigegerät, z.B. ein Fernseher, passt.
  • Der MPEG-Compiler 1426 ist für die Konvertierung vom regelmäßigen Webbilderformat in SP H2O MPEG-Ressourcen verantwortlich. Das Quellformat beinhaltet JPEG und GIF und kann PNG beinhalten. Durch Leiten von Argumenten durch die URL-Adresse kann der Konvertierungsprozess angesteuert werden. Der PIXMAP-Compiler ist für die Konvertierung von regelmäßigen Webbildern in SP H2O Ressourcen verantwortlich. Das Quellformat umfasst GIF und kann PNG beinhalten.
  • Der Request Patcher 1424 ist verantwortlich für das Erledigen oder Modifizieren der Anforderungen oder der Antworten zum Integrieren von Daten, die von einem anderen System kommen (z.B. Kreditkartennummer usw.). Er kommuniziert mit einem externen Prozess oder einer externen Datenbank zum Einholen von Kundeninformationen. Die SP-Komponente bietet ein zentrales Repository für Benutzerinformationen. Der Request Patcher kommuniziert mit dieser Komponente, um die Daten einzuholen, die zum Patchen der Anforderungen/Antworten notwendig sind.
  • Der Not Compiled Object Cache 1430 verwendet seinen internen Speicher zum Bedienen jeder Anforderung, die er bedienen kann (gemäß einer heuristischen Berücksichtigung der Lebensdauer von Objekten). Die gecachten Objekte umfassen statisches HTML, GIF-Bilder, JPEG-Bilder und alle standardmäßigen Webformat-Dateien. Seine Rolle ist es, alle statischen Objekte zu bedienen (standardmäßige URL-Adressen ohne Abfragen, keine gepostete Form), ohne das Internet abzufragen, wodurch Latenzzeiten zum Holen eines Objekts reduziert werden und dem System eine Art Fehlertoleranz verliehen wird. Die Kunden-Website enthält die Website zur Veröffentlichung durch das H2O-System.
  • 15 illustriert eine Anforderung für eine bereits gecachte statische Seite. Der STB-Benutzer gibt eine Anforderung zum Laden einer HTML-Seite 1520 aus. Diese Anforderung wird mit LHTTP über DATP zum SGW 248 gesendet. Das SGW konvertiert die Anforderung in HTTP über TCP/IP und leitet sie zum Compiled Object Cache 1410 weiter (1522). Der Compiled Object Cache 1410 hat die angeforderte (zu einem Modul kompilierte) HTML-Seite in seinem internen Festplattenspeicher gespeichert; wenn die Lebenszeit des Objektes nicht abgelaufen ist und der Compiled-Objekt-Cache kommt der Anforderung mit der kompilierten HTML-Seite nach [sic]. Er sendet die HTTP-Antwort 1424 zum SGW mit HTTP über TCP/IP. Das SGW setzt das Protokoll von HTTP über TCP/IP in LHTTP über DATP um. Die STB lädt die angeforderte Seite 1526 (kompiliert) in ihren Speicher und sendet sie zwecks Interpretation zur H2O-Browser-Maschine. Die H2O-Browser-Maschine fordert beim SGW an (1528), die zum Rendern des Bildschirms auf dem Fernseher notwendigen Bilder zu holen, mit Konvertierungsoptionen (mpeg oder pixmap, Breite, Höhe usw.) auf URL. Das SGW sendet die HTTP-Anforderung 1530 zum Compiled Object Cache. Das angeforderte (zu einem Modul kompilierte) Bild ist im internen Festplattenspeicher des Compiled Object Cache gespeichert; die Lebenszeit der Objekte ist nicht abgelaufen und der Compiled Object Cache kommt der Anforderung mit dem kompilierten Bild nach (1532 und 1534). Bei diesem Szenario wurde dem H2O Proxy die Anforderung erspart und er kann somit andere Anforderungen verarbeiten.
  • Wie in 16 gezeigt, gibt der Benutzer der STB 212 eine Anforderung 1610 zum Laden einer HTML-Seite (home.asp) aus, Host- und Benutzer-Info des Anforderungs-Headers enthalten [STB Modell+STB Seriennummer] und [Zugangskarten-ID] des Benutzers. Diese Anforderung 1610 wird mit LHTTP über DATP zum SGW gesendet. Das SGW konvertiert die Anforderung in HTTP über TCP/IP und leitet sie zum Compiled Object Cache weiter (1612). Das angeforderte Objekt ist im Speicher des Web-Cache nicht verfügbar. Der Web-Cache leitet dann die Anforderung 1614 zum H2O Proxy weiter. Der H2O Proxy fordert die SP auf (1616), den Namen des Benutzers (für den amazon.com Dienst) zurückzugeben (1620). Der H2O Proxy patcht die Anforderung mit dem Namen des Benutzers und gibt diese Anforderung an den „Not Compiled Object Cache" aus (1622). Der „Not Compiled Object Cache" hat die angeforderte HTML-Seite nicht in seinem Speicher und gibt dann die Anforderung 1624 an den angepeilten Webserver aus, hier amazon.com. Der angepeilte Webserver berechnet die HTML-Seite auf der Basis der Benutzerinformationen und gibt sie zum „Not Compiled Object Cache" zurück (1626). Der „Not Compiled Object Cache" gibt die HTML-Seite 1628 zum H2O Proxy zurück.
  • Der H2O Proxy sendet die HTTP-Anforderung 1630 zum „Not Compiled Object Cache", um die Bilder 1632, 1634, 1636 zu holen, die für seine Layout-Berechnungen notwendig sind (gif, jpeg usw.). Der H2O Proxy kompiliert die HTML-Seite, berechnet das Layout, patcht die URL-Adressen der eingebetteten Bilder und sendet die resultierende OpenTV-Ressource 1646 (mit SP-Ressource Mime-Typ) zum „Compiled Object Cache" zurück. Der Compiled Object Cache speichert das Objekt in seinem internen Speicher und sendet die kompilierte HTML-Seite 1648 zum SGW zurück. Das SGW konvertiert die Antwort in LHTTP über DATP und sendet sie zur STB 1650 zurück. Die STB lädt das angeforderte Objekt in ihren Speicher und sendet sie zur Interpretation zur H2O-Browser-Maschine.
  • Die H2O-Browser-Maschine gibt Anforderungen 1652 an das SGW aus, um die zum Rendern notwendigen Bilder zu holen (durch die gepatchten URL-Adressen: hier beinhaltet die URL-Adresse logo.gif eine Direktive für das Pixmap-Ressourcenformat): pix/logo.gif. Das SGW konvertiert die Anforderung 1652 in HTTP über TCP/IP und leitet sie zum Compiled Object Cache weiter. Der „Compiled Object Cache" hat das angeforderte GIF-Bild bereits im richtigen Ressourcenformat – weil ein Benutzer dieses Bild bereits zu einem früheren Zeitpunkt angefordert hat – und das Bild wird direkt zum SGW zurückgegeben (1654). Das SGW konvertiert die Antwort in LHTTP über DATP und sendet sie zur STB zurück (1656). Die H2O-Browser-Maschine gibt Anforderungen an das SGW aus (1658), um die zum Rendern notwendigen Bilder zu holen: mpg/banner.jpg. Der „Compiled Object Cache" hat das angeforderte Bild nicht in seinem Speicher und gibt daher die Anforderung 1660 an den H2O Proxy aus. Der H2O Proxy sendet die HTTP-Anforderung 1662 zum „Not Compiled Object Cache", um das /banner.jpg Bild zu holen.
  • Der „Not Compiled Objekt Cache" hat das Bild in seinem Cache und gibt es sofort zum H2O Proxy zurück (1664). Der H2O Proxy konvertiert das Bild mit den Parametern in der URL-Adresse (MPG-Format, Breite, Höhe usw.) und gibt das Ergebnis an den Compiled Object Cache 1668 zurück. Der Compiled Object Cache speichert das Objekt in seinem internen Speicher und sendet das konvertierte MPEG-Bild zum SGW zurück (1668). Das SGW konvertiert die Antwort in LHTTP über DATP und sendet sie zur STB zurück (1670). Die STB rendert die HTML-Seite auf dem Bildschirm.
  • Die H2O Proxy Komponente bietet anderen H2O-Komponenten oder -Compilern eine robuste und skalierbare Architektur sowie eine Schnittstelle für die „Compiler"-Konfiguration. Weitere mögliche Dienste sind: die Fähigkeit zum Protokollieren von Fehlern; die Fähigkeit zum Alarmieren eines Administrators über definierte Events und die Fähigkeit zur Fehlersuche in den „Compilern". Von der bereitgestellten H2O Proxy Umgebung und APIs „patchen" die Compier HTTP-Anforderungen und -Antworten „on the fly" und greifen schließlich dazu auf eine externe Datenbank, Datei oder einen Prozess zu. Die Compiler patchen HTTP-Anforderungen durch Entfernen der speziellen HTTP-Header (STB-Kennung, Zugriffskartenkennung usw.); durch Addieren eines speziellen HTTP-Headers (Benutzername, Kreditkartennummer usw.); durch Addieren von HTML-Formular-Feldern zu eingehenden Postieranforderungen (Visakartennummer usw.); und durch Ausführen von Stringsubstitution ($UID$ → Benutzerkennung) konvertieren die Compiler Webobjektformate und Mime-Typen „on the fly" in HTTP-Antworten und geben HTTP-Anforderungen alleine aus und holen dafür ein Antwortobjekt ein.
  • Wie in 17 gezeigt, wird der H2O Proxy in einer bevorzugten Ausgestaltung durch die Entwicklung einer Erweiterung von Einschlusssoftware (Web Proxy, Firewall, Webserver oder sonstige usw.) implementiert. Diese Host-Software bietet H2O-Threading und Planung der H2O-Tasks sowie einige der benötigten Funktionen zum Implementieren von H2O „Compilern" und Patching-Komponenten.
  • Unter Verwendung der von der Proxy Host Software bereitgestellten API wird ein API-Satz (die H2O Proxy API) zum Implementieren der von den H2O-Compilern benötigten Funktionen bereitgestellt, die von den H2O Proxy Host Software Services fehlen, und bieten ein höheres Abstraktionsniveau für die von der H2O Proxy Host Software zur Verfügung gestellten Dienste. Die Komponente Request Patcher 1424 liest eingehende HTTP-Anforderungen für HTML-Seiten und vervollständigt sie mit Informationen von einem anderen Prozess oder einer anderen Datei oder Datenbank. Der HTML2RES Compiler 1420 kompiliert zurückgegebene HTML-Seiten in SP-Ressourcen-Dateien und ändert den Mime-Type des HTTP-Antwort-Headers passend zum neuen Format: Mime-Type: text/otvres.
  • Der GIF2PIX Compiler 1422 konvertiert ein zurückgegebenes GIF-Bild in eine SP-Ressourcen-Datei und ändert den Mime-Type des HTTP-Antwort-Headers passend zum neuen Format: Mime-Type: image/otvpix. Der 2MPEG Compiler 1426 konvertiert ein zurückgegebenes GIF- oder JPEG-Bild in eine SP-Ressourcen-Datei und ändert den Mime-Type des HTTP-Antwort-Headers passend zum neuen Format: Mime-Type: image/otvmpg. 18 zeigt ein Folgeschema für eine dynamische Anforderung einer HTML-Seite. Die Object Caches werden in dem Folgeschema nicht angezeigt, weil sie „passive" Komponenten in dieser Interaktion sind. Die Benutzer-STB 212 gibt eine Anforderung 1810 um eine Seite (home.asp) durch eine HTTP-Anforderung aus. Der Request Patcher 1424 greift auf eine externe process/file/database/url 1812, 1814 zu, um den Benutzernamen zu holen, patcht die Anforderung und sendet sie zum HTML2RES Compiler (1816). Der HTML2RES Compiler sendet die Anforderung 1818 zur angepeilten Website (amazon.com). Die Website berechnet die Anforderung und sendet die resultierende HTML-Seite zum HTML2RES Compiler zurück (1820). Der HTML2RES Compiler parst die Datei zum Holen der URL-Adresse der Bild-Links und gibt die Anforderungen zur Website aus (1822), um die Bilddateien (logo.gif, banner.jpg) zu holen (1824). Der HTML2RES Compiler berechnet das TV-Layout für die Seite, kompiliert sie zu einer SP-Ressourcen-Datei und sendet sie zur STB zurück (1830). Die STB rendert die HTML-Seite auf dem Fernseher.
  • 19 zeigt ein Folgeschema einer Anforderung für eine Bilddatei. Eine in die Benutzer-STB geladene HTML-Seite braucht ein Bild zum Rendern auf einem Bildschirm. Sie gibt eine HTTP-Anforderung 1910 für das Bild (in der URL-Adresse eingebettete Konvertierungsoptionen) an den 2MPG Compiler aus. Der 2MPG Compiler fordert das Bild 1912 von der Ziel-Site an (amazon.com). Die Ziel-Site gibt die Bilddatei banner.jpg 1914 an den 2MPG Compiler zurück. Der 2MPG Compiler konvertiert die Datei banner.jpg mit den auf der URL-Adresse angegebenen Optionen und gibt das Ergebnis, mit einem image/otvmpg-Mime-Type, zur STB zurück (1916). Die STB rendert das Bild auf dem Bildschirm.
  • Die verschiedenen identifizierten H2O-Compiler erben vom Klassen-H2O-Compiler und bieten eine Implementation für die verschiedenen reinen virtuellen Eintrittsstellen der Klasse. Compilern werden Speicherfunktionen gegeben, um die Anforderungen/Antworten-Puffer zuzuordnen und zu befreien. Die Größe des zugeordneten Puffers wird einer FreeBuffer-Funktion gegeben, so dass der Puffer mit unterschiedlichen Ansätzen befreit werden kann (für eine bestimmte Größe könnte der Puffer als temporäre Datei implementiert werden, die in Memory gemappt ist, während sie für geringere Größen vorzugsweise wie in Memory-Puffer implementiert wird).
  • Der Puffer wird zu einer Ausführungsfunktion geleitet, die die volle HTTP-Anforderung/Antwort enthält, der Compiler parst die Anforderungsheader, Mime-Typen und führt die geeigneten Aktionen durch. Dieser Puffer ist vorzugsweise ein Nur-Lese-Puffer. Der Puffer kann auch beschreibbar sein, um eine Erweiterung durch den Compiler oder andere Funktionen danach zu ermöglichen. Der von den Ausführungsfunktionen zurückgegebene Puffer enthält eine gültige HTTP-Anforderung/Antwort, der Memory wird vom H2O Proxy mit der richtigen FreeBuffer-Funktion befreit und muss von der bereitgestellten AllocBuffer-Funktion zugeordnet werden. Das Debug-Member wird für Compiler-Implementierer bereitgestellt, damit sie eine Debug-Trace aus der H2O Proxy Umgebung holen können.
  • Die Parameterfunktionen dienen zum Einholen der Namen der Parameter, zum Einholen der aktuellen Werte (String) der Parameter, zum Einstellen eines neuen Wertes für einen Parameter und zum Validieren eines Parametersatzes. Die URL-Funktionen werden vom HTML-Compiler zum Abrufen von Bildern verwendet. Diese Funktionen stehen den anderen Compilern zur Verfügung, um den Komponenten nach Bedarf zusätzliche Dienste zu bieten.
  • So erzeugt beispielsweise ein Netzwerk mit 1 Million STBs mit durchschnittlich 20.000 angeschlossenen Benutzern 2000 Anforderungen pro Sekunde für HTML-Seiten zum SGW und „Compiled Object Cache" (es sei denn, dass ein Teil der angeforderten Seiten von Breitband kommt). Angenommen, diese Seiten sollen statisch sein und sollen sofort vom „Compiled Object Cache" bedient werden, muss der H2O Proxy 200 Anforderungen pro Sekunden bedienen. Angenommen, dass eine typische HTML-Seite 10 Bilder einbettet, wobei 8 von 10 JPEG H2O Proxy 10 abgehende Anforderungen für jede eingehende Anforderung ausgeben, bedient der „Not Compiled Object Object Cache" 2000 Anforderungen pro Sekunde.
  • Die MPG-Konvertierung erfolgt vorzugsweise nach Möglichkeit im Voraus. Ein Web-Crawler kann die HTML-Seiten und Bilder nachts anfordern, so dass sie im Voraus konvertiert werden, was diese Sache verbessert. Die Compiler interagieren somit mit H2O. H2O 248 ist die bevorzugte Client/Server-Lösung, die im der SP vorgesehen ist und es Internet-Inhaltsentwicklern ermöglicht, interaktiven Fernsehinhalt, Applikationen und Dienste für die auf der SP laufenden Netwerkbetreiber zu erzeugen. Somit wird über H2O der größere Pool von Internet-Talent und -Inhalt dem riesigen wachsenden Weltmarkt für interaktiven Fernsehanwendungen zur Verfügung gestellt. Der H2O-Server konvertiert Internet-Inhalt (HTML-Seiten, ECMA-Skripte und HTML-Seitenformatierung) zu SP-Assets. Der H2O-Client, H2OC, rendert die Assets und interagiert mit den Clients. In dem Szenario mit T-Commerce/E-Commerce ermöglicht es H2O E/T-Commerce-Verkaufsstellen, existierende Web-Tools zum Schaffen von Einkaufsdiensten zu nutzen und über standardmäßige Webprotokolle mit der bevorzugten SP (Operator) Verbindung aufzunehmen. Somit ist die vorliegende Erfindung bedienerfreundlich, weil sie APIs durch bekannte Methodiken bereitstellt.
  • H2O dient als Proxy für das SGW und die Broadcasting-Tools zum Konvertieren von Webinhalt in SP-Inhalt. Somit können Website-Entwickler ihre derzeitigen HTTP-Server und Applikationsserver benutzen, um interaktiven Fernsehinhalt kostenarm zu erzeugen. In einer bevorzugten Ausgestaltung konvertiert H2O HTML, JavaScript und Internet-Graphik, es können aber auch andere bekannte oder entwickelte Internet- oder sonstige Inhalte oder Protokolle zur Proxy-Funktionalität von H2O hinzugefügt werden. H2O ermöglicht es der SP, Webseiten auf STBs anzuzeigen, die nicht vollständig Browser-fähig sind, und Original-Benutzerschnittstellen zu erzeugen. H2O ermöglicht eine SP-Verbindung mit einer beliebigen Commerce-Maschine, die nur HTML benutzt. H2O ist für das Konvertieren aller jetzigen oder zukünftigen Breitband- und Webinhalte wie HTML-Seiten, JPG-Bilder, Wav-Audio-Dateien usw. in SP-Ressourcen verantwortlich.
  • Die Server-Seite von H20, H2OS, ist ein HTTP-Proxy. Für andere Zwecke kann sie als dynamische Link-Bibliothek (DLL) oder als Batch-Tool verpackt werden. Die Client-Seite von H2O, H2OC, ist eine STB O-Code-Applikation. H2OC baut auf anderen SP-Client-Komponenten wie der SGW-Bibliothek oder der Carousel Load Bibliothek auf. H2O lässt es zu, dass URLs zum Adressieren von Dokumenten und Diensten verwendet werden. H2O ermöglicht auch Tracking in den Broadcast- und Online-Umgebungen. H2OS bietet HTTP-Proxy-Funktionen. SP-Applikationen fordern ein Dokument durch H2O an, worauf H2O das Dokument abruft, parst, kompiliert und das Dokument zum Anforderer zurücksendet. Diese H2O-Funktionalität ermöglicht die Verwendung derselben Maschine für unterschiedliche Zwecke, online und Broadcast, erleichtet die Skalierbarkeit und ermöglicht eine flexible Nutzung von H2O. Das Parsing hängt vom Typ des Dokuments ab, Parsing kann HTML-Parsing, ein GIF-Bild oder JPEG-Bilder usw. sein. Um es erweiterungsfähig zu machen, kann H2O „einsteckbar" (Plug-In) sein und kann neue Fremdfilter verwenden.
  • H2O ermöglicht Skript-Erstellungen mit unterschiedlichen Sprachen. Vorzugsweise standardisieren alle SP-Serverkomponenten um Überwachung, besonders um die Fähigkeit zum Fernverwalten der unterschiedlichen Prozesse. SNMP dient zum Handhaben von Grundfunktionen („Process OK" und Traps bei bedeutenden Problemen). Ein Befehlszeilen-Interpreter ist am Socket zum Prüfen des Status vorgesehen. Das Einstellen von Parametern ermöglicht Fernmanagement und bietet eine Schnittstelle mit dem Web durch Web-Skripts. In einer bevorzugten Ausgestaltung sind standardisierte Warnungen und Fehlerprotokolle vorgesehen.
  • HTML/JS ermöglicht keine gemeinsame Nutzung von Informationen von einer Seite zur anderen für das Web, wenn der Server den Kontext verwaltet. Im Broadcast-Modus reicht diese Anordnung nicht aus. Die vorliegende Erfindung stellt einen Broadcast-Modus bereit, bei dem vorzugsweise ein globales permanentes Objekt vorgesehen ist, das beim Starten einer neuen Seite nicht gelöscht wird. Das permanente Objekt führt Kontext zwischen Seiten. Andere von der SP bereitgestellte Basisobjekte werden ebenfalls beim Übergang (z.B. Stationssteuerung, OSD) permanent gemacht. Gadgets werden durch eine Schnittstellendefinitionssprache definiert, um die Erzeugung neuer Gadgets, die Modifikation von Gadgets und die Hinzufügung von Methoden zu ermöglichen, ohne den Compiler zu modifizieren.
  • Das H2O-Karussellmerkmal bietet Echtzeit-Aktualisierung von Katalogen, das Bewahren der Einheitlichkeit von Katalogen bei Updates und das Bereitstellen sicherer Transaktionsmodelle. Das H2O-Karussell ermöglicht die Aktualisierung einer einzelnen Seite oder eines ganzen Satzes von Seiten in einer einzelnen Transaktion. Karussellmanagement ermöglicht das Management eines Karussellindex oder -verzeichnisses. Der Index enthält Informationen zum Zugreifen auf und Abrufen von Daten vom Karussell. Das heißt für eine bestimmte Seite, das Karussellmanagement enthält eine Liste aller notwendigen Module, so dass H2OC alle notwendigen Module gleichzeitig zum Beschleunigen des Prozesses anfordert.
  • Das Karussell bietet Datenkompression, Metadaten auf Seiten (z.B. seitenrelative Priorität, wie oft die Seite gesendet wird) und Seitenverfolgung (Elementarstrom). Der Karussell-Client ist eine STB OCOD Bibliothek, die das Laden von Ressourcen handhabt. Der Karussell-Client verwaltet die Dynamik von Ressourcen, d.h. neue Ressourcen, gelöschte Ressourcen und geänderte Ressourcen. Das dynamische Ressourcenmanagement ermöglicht es dem Client (H2OC) dieser Bibliothek, dynamischen Inhalt zu präsentieren. Der Karussell-Client verwaltet Speicherzuordnung, Pre-Fetching und Caching von Ressourcen und die Dekompression von Modulen. Der Karussell-Client verwaltet Subindex/Verzeichnisse und verwaltet einen ,Satz' von Ressourcen anstatt eines ,Baums' von Ressourcen, was die gemeinsame Nutzung von Assets erleichtert. Teilmengen eines einzelnen Baums von Ressourcen können getrennten Prozessen zugewiesen werden, so dass Ressourcen gemeinsam genutzt werden können.
  • H2O überwacht Leistung und Bandbreite von TV-Triggern, z.B. gemeinsam genutzte Ressourcen in gemeinsam genutzten Modulen. H2O optimiert die Bandbreitenauslastung. H2O bietet Multitracks, Multiprioritäten und Management von Datenangebotsvolumen. H2O bietet Laufzeit-Prefetching und Caching auf Modulebene. H2O unterstützt komprimierte Module. H2O unterstützt Pfeil- und Direkttastennavigation (z.B. Stelle oder Farbe), handhabt internationale (chinesische) Metadaten auf Seiten (z.B. seitenrelative Priorität, wie oft sie gesendet wird) und Seitenverfolgung (Elementarstrom). Globale GUI wird gemeinsam genutzt, d.h. es ist eine direkte Tastenverbindung vorgesehen, so dass jede Informationsseite auch von jeder anderen Seite genutzt werden kann.
  • H2O verwaltet Seiten und Unterseiten zum Handhaben von Fällen, bei denen Seiten zu groß sind, um ohne zu rollen auf einen Bildschirm zu passen. H2O ermöglicht die Verwendung von HTML zum Präsentieren von Inhalt, online, Punkt zu Punkt und Broadcast. H2O ermöglicht das Komponieren einer Seite mit einem Gemisch aus Broadcast- und Online-Komponenten. So kann eine Seite beispielsweise von einem Online-Server kommen, während sein Hintergrund Broadcast ist. H2O ermöglicht das Zusammenführen von Inhalt in der STB. So kann beispielsweise eine Bankapplikation die letzten 20 Kreditkartentransaktionen eines Zuschauers von ihrem Server senden, während die HTML-Seite gebroadcastet wird. Vorzugsweise fordert eine Java-Skript-Funktion (HTTP ähnlich) vom Server XML unter Verwendung des Ergebnisses an und eine DOM-Funktion patcht das Ergebnis in eine Tabelle.
  • Vorzugsweise wird Sicherheit für eine gesicherte Authentifizierung des Zuschauers vorgesehen, was am SGW anstatt bei H2O erfolgt. H2O kann jedoch alternativ auch Authentifizierungsfunktionalität enthalten. H2O sendet auch verschlüsselte Daten zu (z.B. Senden einer Kreditkartennummer) und von einer STB zu einem Online-Server. Für einige Dienste ist es geeignet, durch einen Sicherheitsproxy in der Nähe der HTML-in-SP-Konvertierung zu gehen. SP kann HTTPS vom Proxy zum Diensteanbieter und eine SSL-ähnliche OCOD-Bibliothek von der STB zum Proxy nutzen. In anderen Fällen (z.B. Banken) wird Sicherheit von Ende zu Ende bereitgestellt, und in diesem Fall führt H2O gewöhnlich keine Umsetzung durch. Dieses Szenario ist vorzugsweise für Daten reserviert, die die STB ohne Umsetzung durch H2O verarbeiten kann. Verschlüsselung kann alternativ bei SGW oder STB durchgeführt werden.
  • Die vorliegende Erfindung wurde für interaktives Fernsehen in einer bevorzugten Ausgestaltung beschrieben, aber die vorliegende Erfindung kann auch in einem verteilten Computersystem ausgestaltet werden, das einen Server und ein Clientgerät beinhaltet. In einer anderen Ausgestaltung wird die vorliegende Erfindung als ein Satz von Befehlen auf einem rechnerlesbaren Medium implementiert, das ROM, RAM, CD ROM, Flash oder ein anderes rechnerlesbares Medium umfasst, jetzt bekannt oder unbekannt, das bei Ausführung auf einem verteilten Computersystem bewirkt, dass ein verteiltes Computersystem das erfindungsgemäße Verfahren ausführt.
  • Es wurde zwar eine bevorzugte Ausgestaltung der Erfindung in der obigen Erfindung dargestellt, aber dies geschah nur beispielhaft und soll den Umfang der Erfindung nicht begrenzen, der durch die folgenden Ansprüche definiert wird.

Claims (20)

  1. Verfahren zum Bereitstellen von Kommunikation in einem interaktiven Fernsehsystem, das Folgendes umfasst: Empfangen einer ersten, an einen Applikationsserver (200) gerichteten Meldung an einer Service-Plattform (50), wobei die erste Meldung von einem Client-Gerät (212) empfangen wird und eine Benutzerkennung beinhaltet; gekennzeichnet durch: Mappen der empfangenen Benutzerkennung in eine Session-Kennung; und Übertragen einer zweiten Meldung zum Applikationsserver, die der ersten Meldung entspricht; wobei die zweite Meldung die Session-Kennung enthält und die Benutzerkennung nicht enthält.
  2. Verfahren nach Anspruch 1, das ferner das Auflösen einer Session-Kennung in eine Benutzerkennung umfasst, wobei nur die Service-Plattform die Session-Kennungen in entsprechende Benutzerkennungen auflöst.
  3. Verfahren nach Anspruch 2, wobei die Service-Plattform ferner eine Subscriber-Profildatenbank umfasst, die zum Speichern von Benutzerinformationen konfiguriert ist, wobei das Verfahren ferner die folgenden Schritte umfasst: Empfangen einer Meldung in der Service-Plattform, die eine Anforderung um Zugang zur Datenbank anzeigt; und Gewähren oder Verweigern des angeforderten Zugangs auf der Basis von in der Service-Plattform aufgestellten Regeln; wobei die genannten Regeln bestimmte Zugangsrechte für eine Anwendung vorgeben, die die Meldung verfasst hat.
  4. Verfahren nach Anspruch 3, wobei die genannten Regeln Geschäftsvereinbarungen zwischen einem Operator der Service-Plattform und einem Operator des Applikationsservers entsprechen.
  5. Verfahren nach Anspruch 3, das ferner das Umwandeln eines Client-Gerätetransportprotokolls in eine Form umfasst, die mit einem Applikationsserver-Transportprotokoll kompatibel ist.
  6. Verfahren nach Anspruch 5, das ferner Folgendes umfasst: Konvertieren von Inhalt, der vom Applikationsserver erhalten wurde, in ein Format, das mit dem Client-Gerät kompatibel ist; und Konvertieren von Inhalt, der vom Client-Gerät empfangen wurde, in ein Format, das mit dem Applikationsserver kompatibel ist.
  7. Vorrichtung zum Erleichtern der Kommunikation in einem interaktiven Fernsehsystem, wobei die genannte Vorrichtung Folgendes umfasst: ein Mittel, das für die Kommunikation mit einem Client-Gerät 212 über eine erste Kommunikationsverbindung konfiguriert ist; ein Mittel, das für die Kommunikation mit einem Applikationsserver (200) durch eine zweite Kommunikationsverbindung konfiguriert ist; und eine Service-Plattform (50), die zum Empfangen einer ersten Meldung konfiguriert ist, die eine Benutzerkennung vom Client-Gerät beinhaltet, dadurch gekennzeichnet, dass die genannte Service-Plattform konfiguriert ist zum: Mappen der empfangenen Benutzerkennung in eine Session-Kennung; und Übertragen einer zweiten Meldung zum Applikationsserver, wobei die zweite Meldung der ersten Meldung entspricht; wobei die zweite Meldung die Session-Kennung enthält und die Benutzerkennung nicht enthält.
  8. Vorrichtung nach Anspruch 7, wobei nur die Service-Plattform zum Auflösen einer Session-Kennung in eine Benutzerkennung konfiguriert ist.
  9. Vorrichtung nach Anspruch 8, wobei die Service-Plattform ferner eine Subscriber-Profildatenbank umfasst, die zum Speichern von Benutzerinformationen konfiguriert ist.
  10. Vorrichtung nach Anspruch 9, wobei die Service-Plattform ferner einen Transaktionssteuermechanismus (106, 266) beinhaltet, der konfiguriert ist zum: Empfangen einer Meldung, die eine Anforderung um Zugang zur Datenbank anzeigt; und Gewähren oder Verweigern des angeforderten Zugangs auf der Basis von in der Service-Plattform aufgestellten Regeln; wobei die genannten Regeln bestimmte Zugangsrechte für eine Anwendung vorgeben, die die Meldung verfasst hat.
  11. Vorrichtung nach Anspruch 10, wobei die genannten Regeln Geschäftsvereinbarungen zwischen einem Operator der Service-Plattform und einem Operator des Applikationsservers entsprechen.
  12. Vorrichtung nach Anspruch 10, wobei die genannte Service-Plattform ferner einen Transportkonvertierungsmechanismus (108, 246) umfasst, der zum Konvertieren eines Transportprotokolls des Client-Geräts in eine Form konfiguriert ist, die mit einem Transportprotokoll des Applikationsservers kompatibel ist.
  13. Vorrichtung nach Anspruch 12, wobei die genannte Service-Plattform ferner einen Inhaltssteuermechanismus (204, 248) umfasst, der konfiguriert ist zum: Konvertieren von Inhalt, der vom Applikationsserver erhalten wurde, in ein Format, das mit dem Client-Gerät kompatibel ist; Konvertieren von Inhalt, der vom Client-Gerät empfangen wurde, in ein Format, das mit dem Applikationsserver kompatibel ist.
  14. Vorrichtung nach Anspruch 7, wobei die Service-Plattform für die Kommunikation mit dem Client-Gerät über einen Rundsendekanal und einen Punkt-zu-Punkt-Kanal konfiguriert ist.
  15. Rechnerlesbares Medium, das Befehle enthält, die, wenn sie auf einem verteilten Computersystem ausgeführt werden, ein verteiltes Computersystem zu Folgendem veranlassen: Übertragen einer an einen Applikationsserver (200) gerichteten ersten Meldung von einem Client-Gerät (212), wobei die genannte Meldung eine Benutzerkennung beinhaltet; dadurch gekennzeichnet, dass die Befehle, wenn sie ausgeführt werden, das verteilte Computersystem zu Folgendem veranlassen: Empfangen der ersten Meldung an einer Service-Plattform (50), wobei die genannte Service-Plattform: die empfangene Benutzerkennung in eine Session-Kennung mappt; und eine zweite Meldung überträgt, die der ersten Meldung entspricht; wobei die zweite Meldung die Session-Kennung enthält und die Benutzerkennung nicht enthält; Empfangen der zweiten Meldung an einem Applikationsserver (200).
  16. Rechnerlesbares Medium nach Anspruch 15, wobei die genannten Befehle, wenn sie ausgeführt werden, ferner so konfiguriert sind, dass sie bewirken, dass die Service-Plattform eine Session-Kennung in eine Benutzerkennung auflöst, wobei nur die Service-Plattform zum Auflösen von Session-Kennungen in entsprechende Benutzerkennungen konfiguriert ist.
  17. Rechnerlesbares Medium nach Anspruch 16, wobei die Service-Plattform ferner eine Subscriber-Profildatenbank umfasst, die zum Speichern von Benutzerinformationen konfiguriert ist, und wobei die genannten Befehle, wenn sie ausgeführt werden, ferner so konfiguriert sind, dass sie die Service-Plattform zu Folgendem veranlassen: Empfangen einer Meldung, die eine Anforderung um Zugang zur Datenbank anzeigt; und Gewähren oder Verweigern des angeforderten Zugangs auf der Basis von in der Service-Plattform aufgestellten Regeln; wobei die genannten Regeln besondere Zugangsrechte für eine Anwendung vorgeben, die die Meldung verfasst hat.
  18. Rechnerlesbares Medium nach Anspruch 17, wobei die genannten Regeln Geschäftsvereinbarungen zwischen einem Operator der Service-Plattform und einem Operator des Applikationsservers entsprechen.
  19. Rechnerlesbares Medium nach Anspruch 17, wobei die genannten Befehle, wenn sie ausgeführt werden, ferner so konfiguriert sind, dass sie bewirken, dass die Service-Plattform ein Client-Gerät-Transportprotokoll in eine Form konvertiert, die mit einem Applikationsserver-Transportprotokoll kompatibel ist.
  20. Rechnerlesbares Medium nach Anspruch 19, wobei die genannten Befehle, wenn sie ausgeführt werden, ferner so konfiguriert sind, dass sie bewirken, dass die Service-Plattform Folgendes tut: Konvertieren des vom Applikationsserver empfangenen Inhalts in ein Format, das mit dem Client-Gerät kompatibel ist; Konvertieren des vom Client-Gerät empfangenen Inhalts in ein Format, das mit dem Applikationsserver kompatibel ist.
DE60212339T 2001-02-02 2002-02-01 Ein digitales fernsehen anwendungsprotokoll zum interaktiven fernsehen Expired - Lifetime DE60212339T2 (de)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US26621001P 2001-02-02 2001-02-02
US26598601P 2001-02-02 2001-02-02
US266210P 2001-02-02
US265986P 2001-02-02
US26787601P 2001-02-09 2001-02-09
US267876P 2001-02-09
US26926101P 2001-02-15 2001-02-15
US269261P 2001-02-15
US27954301P 2001-03-28 2001-03-28
US279543P 2001-03-28
US858379 2001-05-16
US09/858,379 US7017175B2 (en) 2001-02-02 2001-05-16 Digital television application protocol for interactive television
PCT/US2002/002829 WO2002063851A2 (en) 2001-02-02 2002-02-01 A digital television application protocol for interactive television

Publications (2)

Publication Number Publication Date
DE60212339D1 DE60212339D1 (de) 2006-07-27
DE60212339T2 true DE60212339T2 (de) 2007-05-16

Family

ID=46150067

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60212339T Expired - Lifetime DE60212339T2 (de) 2001-02-02 2002-02-01 Ein digitales fernsehen anwendungsprotokoll zum interaktiven fernsehen

Country Status (9)

Country Link
US (3) US7017175B2 (de)
EP (1) EP1364511B1 (de)
JP (1) JP4363847B2 (de)
AT (1) ATE330408T1 (de)
AU (1) AU2002240200B8 (de)
CA (1) CA2437373A1 (de)
DE (1) DE60212339T2 (de)
ES (1) ES2266456T3 (de)
WO (1) WO2002063851A2 (de)

Families Citing this family (166)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100424481B1 (ko) * 2000-06-24 2004-03-22 엘지전자 주식회사 디지털 방송 부가서비스 정보의 기록 재생장치 및 방법과그에 따른 기록매체
US7320134B1 (en) * 2000-11-07 2008-01-15 Digeo, Inc. System and method for cable operator control over enhanced programming
JP4900998B2 (ja) * 2000-11-30 2012-03-21 ソニー株式会社 情報処理装置および方法、並びに記録媒体
US7017175B2 (en) * 2001-02-02 2006-03-21 Opentv, Inc. Digital television application protocol for interactive television
US7305697B2 (en) 2001-02-02 2007-12-04 Opentv, Inc. Service gateway for interactive television
US7383347B2 (en) * 2001-07-18 2008-06-03 International Business Machines Corporation Method and apparatus for providing extensible scalable transcoding of multimedia content
US6980820B2 (en) * 2001-08-20 2005-12-27 Qualcomm Inc. Method and system for signaling in broadcast communication system
US6731936B2 (en) * 2001-08-20 2004-05-04 Qualcomm Incorporated Method and system for a handoff in a broadcast communication system
JP3961796B2 (ja) * 2001-08-27 2007-08-22 ソニー株式会社 情報提供システム、情報処理装置および方法、情報提供装置および方法、記録媒体、並びにプログラム
US7249193B1 (en) * 2001-08-28 2007-07-24 Emc Corporation SRDF assist
US8042132B2 (en) 2002-03-15 2011-10-18 Tvworks, Llc System and method for construction, delivery and display of iTV content
US8413205B2 (en) 2001-09-19 2013-04-02 Tvworks, Llc System and method for construction, delivery and display of iTV content
US11388451B2 (en) 2001-11-27 2022-07-12 Comcast Cable Communications Management, Llc Method and system for enabling data-rich interactive television using broadcast database
WO2003026275A2 (en) 2001-09-19 2003-03-27 Meta Tv, Inc. Interactive user interface for television applications
US20050091376A1 (en) * 2001-10-12 2005-04-28 Helfman Nadav B. Apparatus and method for optimized and secured reflection of network services to remote locations
US7426534B2 (en) 2001-12-19 2008-09-16 International Business Machines Corporation Method and system for caching message fragments using an expansion attribute in a fragment link tag
US7509393B2 (en) * 2001-12-19 2009-03-24 International Business Machines Corporation Method and system for caching role-specific fragments
US20030188021A1 (en) * 2001-12-19 2003-10-02 International Business Machines Corporation Method and system for processing multiple fragment requests in a single message
US7730154B2 (en) * 2001-12-19 2010-06-01 International Business Machines Corporation Method and system for fragment linking and fragment caching
GB2383488A (en) * 2001-12-20 2003-06-25 Sony Uk Ltd Method and apparatus for creating data carousels
GB2385687A (en) * 2002-02-26 2003-08-27 Hewlett Packard Co Apparatus and method for generating a process definition
US8707354B1 (en) 2002-06-12 2014-04-22 Tvworks, Llc Graphically rich, modular, promotional tile interface for interactive television
US7703116B1 (en) 2003-07-11 2010-04-20 Tvworks, Llc System and method for construction, delivery and display of iTV applications that blend programming information of on-demand and broadcast service offerings
US7558873B1 (en) 2002-05-08 2009-07-07 Nvidia Corporation Method for compressed large send
US20030212739A1 (en) * 2002-05-09 2003-11-13 Antoine Boucher Store and forward architecture
US20030212735A1 (en) * 2002-05-13 2003-11-13 Nvidia Corporation Method and apparatus for providing an integrated network of processors
US20030217369A1 (en) * 2002-05-17 2003-11-20 Heredia Edwin Arturo Flexible application information formulation
CN103810411B (zh) * 2002-05-29 2018-01-12 索尼株式会社 信息处理系统
GB2390459A (en) * 2002-05-31 2004-01-07 Gointeracttv Ltd Interactive digital television
US7209915B1 (en) 2002-06-28 2007-04-24 Microsoft Corporation Method, system and apparatus for routing a query to one or more providers
SE0202133D0 (sv) * 2002-07-08 2002-07-08 Astrazeneca Ab Novel compounds
US7437548B1 (en) * 2002-07-11 2008-10-14 Nvidia Corporation Network level protocol negotiation and operation
US8352983B1 (en) 2002-07-11 2013-01-08 Tvworks, Llc Programming contextual interactive user interface for television
US9124447B2 (en) * 2002-07-26 2015-09-01 International Business Machines Corporation Interactive client computer communication
US7720910B2 (en) * 2002-07-26 2010-05-18 International Business Machines Corporation Interactive filtering electronic messages received from a publication/subscription service
US11070890B2 (en) 2002-08-06 2021-07-20 Comcast Cable Communications Management, Llc User customization of user interfaces for interactive television
US7266582B2 (en) * 2002-08-09 2007-09-04 Sun Microsystems, Inc. Method and system for automating generation of web services from existing service components
US20080313282A1 (en) 2002-09-10 2008-12-18 Warila Bruce W User interface, operating system and architecture
US8220018B2 (en) 2002-09-19 2012-07-10 Tvworks, Llc System and method for preferred placement programming of iTV content
KR100920654B1 (ko) * 2002-12-09 2009-10-09 엘지전자 주식회사 대화형 광디스크 장치에서의 재생 제어방법
US7397797B2 (en) * 2002-12-13 2008-07-08 Nvidia Corporation Method and apparatus for performing network processing functions
US7395048B2 (en) * 2002-12-26 2008-07-01 Motorola, Inc. Unsolicited wireless content delivery and billing apparatus and method
US10664138B2 (en) 2003-03-14 2020-05-26 Comcast Cable Communications, Llc Providing supplemental content for a second screen experience
US8578411B1 (en) 2003-03-14 2013-11-05 Tvworks, Llc System and method for controlling iTV application behaviors through the use of application profile filters
US11381875B2 (en) 2003-03-14 2022-07-05 Comcast Cable Communications Management, Llc Causing display of user-selectable content types
US7558841B2 (en) * 2003-05-14 2009-07-07 Microsoft Corporation Method, system, and computer-readable medium for communicating results to a data query in a computer network
US7620070B1 (en) 2003-06-24 2009-11-17 Nvidia Corporation Packet processing with re-insertion into network interface circuitry
US7359380B1 (en) 2003-06-24 2008-04-15 Nvidia Corporation Network protocol processing for routing and bridging
US7359983B1 (en) 2003-06-24 2008-04-15 Nvidia Corporation Fragment processing utilizing cross-linked tables
US7913294B1 (en) 2003-06-24 2011-03-22 Nvidia Corporation Network protocol processing for filtering packets
US7746781B1 (en) * 2003-06-30 2010-06-29 Nortel Networks Limited Method and apparatus for preserving data in a system implementing Diffserv and IPsec protocol
KR100501332B1 (ko) * 2003-07-04 2005-07-18 삼성전자주식회사 메시지 기반 프로토콜을 이용한 티브이 포탈 서비스 제공시스템 및 그 방법
US9615061B2 (en) * 2003-07-11 2017-04-04 Tvworks, Llc System and method for creating and presenting composite video-on-demand content
US8416952B1 (en) 2003-07-11 2013-04-09 Tvworks, Llc Channel family surf control
US7664946B2 (en) * 2003-07-28 2010-02-16 Qcom Tv Partners System and method of guaranteed anonymity of cable television viewership behavior
WO2005015824A1 (en) * 2003-08-07 2005-02-17 Samsung Electronics Co., Ltd. Audio/video device, apparatus and method for controlling audio/video device
US7912485B2 (en) * 2003-09-11 2011-03-22 Qualcomm Incorporated Method and system for signaling in broadcast communication system
US8819734B2 (en) 2003-09-16 2014-08-26 Tvworks, Llc Contextual navigational control for digital television
US8484671B1 (en) 2003-10-07 2013-07-09 The Directv Group, Inc. Receiver interface with multiple access cards
JP4475235B2 (ja) * 2004-01-28 2010-06-09 日本電気株式会社 コンテンツの符号化、配信及び受信方法と装置とシステムならびにプログラム
EP1723766A1 (de) * 2004-03-02 2006-11-22 Novo Nordisk A/S Übertragungsdatenpaket-konstruktion für bessere kopfauthentifikation
US7827573B2 (en) * 2004-04-05 2010-11-02 Comcast Cable Holdings, Llc Method and system for provisioning a set-top box
US20060031256A1 (en) * 2004-05-20 2006-02-09 Bea Systems, Inc. Template language for mobile client
US7650432B2 (en) 2004-05-20 2010-01-19 Bea Systems, Inc. Occasionally-connected application server
US20060136555A1 (en) * 2004-05-21 2006-06-22 Bea Systems, Inc. Secure service oriented architecture
US7774485B2 (en) * 2004-05-21 2010-08-10 Bea Systems, Inc. Dynamic service composition and orchestration
US20050278374A1 (en) * 2004-05-21 2005-12-15 Bea Systems, Inc. Dynamic program modification
US7310684B2 (en) * 2004-05-21 2007-12-18 Bea Systems, Inc. Message processing in a service oriented architecture
US20050273521A1 (en) * 2004-05-21 2005-12-08 Bea Systems, Inc. Dynamically configurable service oriented architecture
US20050273847A1 (en) * 2004-05-21 2005-12-08 Bea Systems, Inc. Programmable message processing stage for a service oriented architecture
US20050264581A1 (en) * 2004-05-21 2005-12-01 Bea Systems, Inc. Dynamic program modification
US20050273502A1 (en) * 2004-05-21 2005-12-08 Patrick Paul B Service oriented architecture with message processing stages
US8615601B2 (en) * 2004-05-21 2013-12-24 Oracle International Corporation Liquid computing
US20060031481A1 (en) * 2004-05-21 2006-02-09 Bea Systems, Inc. Service oriented architecture with monitoring
US20060069791A1 (en) * 2004-05-21 2006-03-30 Bea Systems, Inc. Service oriented architecture with interchangeable transport protocols
US7653008B2 (en) 2004-05-21 2010-01-26 Bea Systems, Inc. Dynamically configurable service oriented architecture
US20060031432A1 (en) * 2004-05-21 2006-02-09 Bea Systens, Inc. Service oriented architecture with message processing pipelines
US20060031433A1 (en) * 2004-05-21 2006-02-09 Bea Systems, Inc. Batch updating for a service oriented architecture
US20050270970A1 (en) * 2004-05-21 2005-12-08 Bea Systems, Inc. Failsafe service oriented architecture
US20060007918A1 (en) * 2004-05-21 2006-01-12 Bea Systems, Inc. Scaleable service oriented architecture
US20060005063A1 (en) * 2004-05-21 2006-01-05 Bea Systems, Inc. Error handling for a service oriented architecture
US20060080419A1 (en) * 2004-05-21 2006-04-13 Bea Systems, Inc. Reliable updating for a service oriented architecture
US7720432B1 (en) * 2004-06-16 2010-05-18 Colby Steven M Content customization in asymmetric communication systems
US8346157B1 (en) 2004-06-16 2013-01-01 Colby Steven M Content customization in asymmertic communication systems
US8201191B2 (en) * 2004-06-30 2012-06-12 Time Warner Cable Inc. Apparatus and methods for implementation of network software interfaces
US9641902B2 (en) 2007-06-26 2017-05-02 Broadband Itv, Inc. Dynamic adjustment of electronic program guide displays based on viewer preferences for minimizing navigation in VOD program selection
US7631336B2 (en) 2004-07-30 2009-12-08 Broadband Itv, Inc. Method for converting, navigating and displaying video content uploaded from the internet to a digital TV video-on-demand platform
US11259059B2 (en) 2004-07-30 2022-02-22 Broadband Itv, Inc. System for addressing on-demand TV program content on TV services platform of a digital TV services provider
US7590997B2 (en) 2004-07-30 2009-09-15 Broadband Itv, Inc. System and method for managing, converting and displaying video content on a video-on-demand platform, including ads used for drill-down navigation and consumer-generated classified ads
US9584868B2 (en) 2004-07-30 2017-02-28 Broadband Itv, Inc. Dynamic adjustment of electronic program guide displays based on viewer preferences for minimizing navigation in VOD program selection
US8570880B2 (en) 2004-08-05 2013-10-29 Qualcomm Incorporated Method and apparatus for receiving broadcast in a wireless multiple-access communications system
WO2006031812A2 (en) * 2004-09-13 2006-03-23 Comcast Cable Holdings, Llc Method and system of managing subscriber access to services associated with service provider
WO2006062161A1 (ja) * 2004-12-09 2006-06-15 Matsushita Electric Industrial Co., Ltd. コンテンツ視聴システム
US20060133611A1 (en) * 2004-12-21 2006-06-22 Biggs Robert J Method of use data compression technology
US8201205B2 (en) 2005-03-16 2012-06-12 Tvworks, Llc Upstream bandwidth management methods and apparatus
US7818667B2 (en) 2005-05-03 2010-10-19 Tv Works Llc Verification of semantic constraints in multimedia data and in its announcement, signaling and interchange
US7961739B2 (en) * 2005-07-21 2011-06-14 Genband Us Llc Systems and methods for voice over multiprotocol label switching
EP1750253B1 (de) * 2005-08-04 2012-03-21 Nuance Communications, Inc. Sprachdialogsystem
US7992085B2 (en) * 2005-09-26 2011-08-02 Microsoft Corporation Lightweight reference user interface
US7788590B2 (en) * 2005-09-26 2010-08-31 Microsoft Corporation Lightweight reference user interface
US20070091919A1 (en) * 2005-10-24 2007-04-26 Sandoval Francis R Method and system of supporting enhanced television signaling
SE529620C2 (sv) 2006-02-24 2007-10-09 Abb Ab Styrning av verkliga objekt i sammankopplade datoriserade styrsystem
US8788706B2 (en) * 2006-02-27 2014-07-22 Vudu, Inc. Method and system for managing data transmission between devices behind network address translators (NATs)
WO2007128957A1 (en) * 2006-04-10 2007-11-15 Tektronix International Sales Gmbh Method and apparatus for processing digitally encoded data in stream to retrieve data portion located externally
WO2007123302A1 (en) 2006-04-25 2007-11-01 Lg Electronics Inc. Digital broadcasting system and method of processing data
US9277295B2 (en) 2006-06-16 2016-03-01 Cisco Technology, Inc. Securing media content using interchangeable encryption key
US9137480B2 (en) 2006-06-30 2015-09-15 Cisco Technology, Inc. Secure escrow and recovery of media device content keys
US8571061B2 (en) * 2006-07-07 2013-10-29 Avaya Communications Israel Ltd. Inter-network translation
US8645973B2 (en) * 2006-09-22 2014-02-04 Oracle International Corporation Mobile applications
KR100823282B1 (ko) * 2006-09-29 2008-04-21 삼성전자주식회사 데이터 방송 애플리케이션을 수신, 저장 및 실행하기 위한방법 및 장치
US20080094500A1 (en) * 2006-10-20 2008-04-24 Hewlett-Packard Development Company Lp Frame filter
US20080098433A1 (en) * 2006-10-23 2008-04-24 Hardacker Robert L User managed internet links from TV
US20080101409A1 (en) * 2006-10-26 2008-05-01 Hewlett-Packard Development Company Lp Packetization
US7949006B2 (en) * 2006-11-09 2011-05-24 Motorola Mobility, Inc. System and method for media burst control of discrete content for push-to-cellular communication
TWI320893B (en) * 2006-11-22 2010-02-21 Quanta Comp Inc Management interface between embedded system of blade server and computer system medium thereof
KR101576943B1 (ko) 2006-12-01 2015-12-15 에이치에스엔아이 엘엘씨 향상된 대화형 텔레비전 프로세싱 방법 및 시스템
US8274401B2 (en) * 2006-12-22 2012-09-25 Acterna Llc Secure data transfer in a communication system including portable meters
US9276664B2 (en) 2007-04-30 2016-03-01 Dish Network Corporation Mobile interactive satellite services
US8457682B2 (en) 2008-03-04 2013-06-04 Dbsd Satellite Services G.P. Method and system for integrated satellite assistance services
US8996394B2 (en) * 2007-05-18 2015-03-31 Oracle International Corporation System and method for enabling decision activities in a process management and design environment
US20080301320A1 (en) * 2007-05-31 2008-12-04 Morris Robert P Method And System For Managing Communication Protocol Data Based On MIME Types
US11570521B2 (en) 2007-06-26 2023-01-31 Broadband Itv, Inc. Dynamic adjustment of electronic program guide displays based on viewer preferences for minimizing navigation in VOD program selection
US8185916B2 (en) * 2007-06-28 2012-05-22 Oracle International Corporation System and method for integrating a business process management system with an enterprise service bus
US8108680B2 (en) * 2007-07-23 2012-01-31 Murray Mark R Preventing unauthorized poaching of set top box assets
US8385545B2 (en) * 2007-07-27 2013-02-26 Howard G. Pinder Secure content key distribution using multiple distinct methods
US20100138875A1 (en) * 2007-11-30 2010-06-03 Johnson Gerard C Method and system for improved interactive television processing
US10721533B2 (en) 2007-11-30 2020-07-21 Hsni, Llc Method and system for displaying and updating electronic information on a display device
WO2009108703A1 (en) * 2008-02-25 2009-09-03 Locamoda, Inc. Associating a user's activity in relation to a physical location with a virtual community
US8626230B2 (en) 2008-03-04 2014-01-07 Dish Network Corporation Method and system for using routine driving information in mobile interactive satellite services
US9043726B2 (en) * 2008-07-03 2015-05-26 Ebay Inc. Position editing tool of collage multi-media
US8893015B2 (en) 2008-07-03 2014-11-18 Ebay Inc. Multi-directional and variable speed navigation of collage multi-media
US10282391B2 (en) 2008-07-03 2019-05-07 Ebay Inc. Position editing tool of collage multi-media
US9639505B2 (en) * 2008-07-03 2017-05-02 Ebay, Inc. System and methods for multimedia “hot spot” enablement
US8086526B2 (en) 2008-07-23 2011-12-27 Ebay Inc. Hybrid account
US8762969B2 (en) * 2008-08-07 2014-06-24 Microsoft Corporation Immutable parsing
US20100042535A1 (en) * 2008-08-15 2010-02-18 Ebay Inc. Currency display
BRPI0803717A2 (pt) * 2008-09-03 2010-06-15 Tqtvd Software Ltda sistema de execução de aplicativos para televisão digital, aparato de execução de aplicativos para televisão digital e método para implementar tal sistema
KR101727049B1 (ko) * 2008-11-18 2017-04-14 엘지전자 주식회사 비실시간 서비스 처리 방법 및 방송 수신기
US11832024B2 (en) 2008-11-20 2023-11-28 Comcast Cable Communications, Llc Method and apparatus for delivering video and video-related content at sub-asset level
EP2211335A1 (de) 2009-01-21 2010-07-28 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Vorrichtung, Verfahren und Computerprogramm zum Erhalt eines Parameters, der eine Variation einer Signaleigenschaft eines Signals beschreibt
US9014832B2 (en) 2009-02-02 2015-04-21 Eloy Technology, Llc Augmenting media content in a media sharing group
US8307390B2 (en) * 2009-02-26 2012-11-06 Comcast Cable Communications, Llc Re-addressable alternate content
US8775529B2 (en) * 2009-05-08 2014-07-08 Raytheon Company Bridging communications between communication services using different protocols
TWI379398B (en) * 2009-05-20 2012-12-11 Ind Tech Res Inst Electrostatic discharge clamp circuit
US8325725B2 (en) * 2009-07-20 2012-12-04 Telefonaktiebolaget L M Ericsson (Publ) Efficient host management protocol on multicast capable router
US8379641B2 (en) * 2009-07-20 2013-02-19 Telefonaktiebolaget L M Ericsson (Publ) Light host management protocol on multicast capable router
JP5576697B2 (ja) * 2010-04-14 2014-08-20 オリンパス株式会社 サービス利用端末、サービス提供端末、サービス利用端末の制御方法、サービス提供端末の制御方法およびサービス提供システム
KR101892100B1 (ko) * 2010-05-19 2018-08-27 아카마이 테크놀로지스, 인크. 에지 서버 ｈｔｔｐ ｐｏｓｔ 메시지 프로세싱
US20120036048A1 (en) 2010-08-06 2012-02-09 Diy Media, Inc. System and method for distributing multimedia content
US9179188B2 (en) * 2010-08-30 2015-11-03 Sony Corporation Transmission apparatus and method, reception apparatus and method, and transmission and reception system
US20120059696A1 (en) * 2010-09-08 2012-03-08 United Video Properties, Inc. Systems and methods for providing advertisements to user devices using an advertisement gateway
US9112623B2 (en) 2011-06-06 2015-08-18 Comcast Cable Communications, Llc Asynchronous interaction at specific points in content
US11323337B2 (en) 2011-09-27 2022-05-03 Comcast Cable Communications, Llc Resource measurement and management
US8904462B2 (en) 2012-01-24 2014-12-02 Motorola Mobility Llc System and method for communication resource information
US11115722B2 (en) 2012-11-08 2021-09-07 Comcast Cable Communications, Llc Crowdsourcing supplemental content
US9553927B2 (en) 2013-03-13 2017-01-24 Comcast Cable Communications, Llc Synchronizing multiple transmissions of content
US9106557B2 (en) 2013-03-13 2015-08-11 Comcast Cable Communications, Llc Scheduled transmission of data
US10880609B2 (en) 2013-03-14 2020-12-29 Comcast Cable Communications, Llc Content event messaging
FR3021481B1 (fr) * 2014-05-23 2016-05-27 Oneaccess Procede de distribution pour une liaison a liens multiples et heterogenes
US11783382B2 (en) 2014-10-22 2023-10-10 Comcast Cable Communications, Llc Systems and methods for curating content metadata
FR3031644A1 (fr) * 2015-01-13 2016-07-15 Orange Procede de traitement d'un flux multimedia, dispositif et programme d'ordinateur correspondants.
US11818203B2 (en) 2015-02-05 2023-11-14 Comcast Cable Communications, Llc Methods for determining second screen content based on data events at primary content output device
US10958649B2 (en) 2018-03-21 2021-03-23 Akamai Technologies, Inc. Systems and methods for internet-wide monitoring and protection of user credentials
US11310271B2 (en) 2019-02-20 2022-04-19 Arris Enterprises Llc Using secure web sockets to extend reach of conditional access systems
CN112838966A (zh) * 2021-04-22 2021-05-25 北京拓课网络科技有限公司 一种udp链路监控方法、系统及电子设备
US20220413946A1 (en) * 2021-06-24 2022-12-29 Infosec Global Inc. Cryptographic agility application program interface engine

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5432937A (en) 1993-08-20 1995-07-11 Next Computer, Inc. Method and apparatus for architecture independent executable files
US5446726A (en) * 1993-10-20 1995-08-29 Lsi Logic Corporation Error detection and correction apparatus for an asynchronous transfer mode (ATM) network device
US5668810A (en) 1995-04-26 1997-09-16 Scientific-Atlanta, Inc. Data transmission protocol method and apparatus
US5848352A (en) * 1995-04-26 1998-12-08 Wink Communications, Inc. Compact graphical interactive information system
EP0760563A1 (de) 1995-08-29 1997-03-05 ALCATEL BELL Naamloze Vennootschap Mehrfachrahmenstruktur und Kommunikationsprotokoll für ein Übertragungsnetz
US5886732A (en) * 1995-11-22 1999-03-23 Samsung Information Systems America Set-top electronics and network interface unit arrangement
US5727159A (en) * 1996-04-10 1998-03-10 Kikinis; Dan System in which a Proxy-Server translates information received from the Internet into a form/format readily usable by low power portable computers
US6311197B2 (en) 1996-06-03 2001-10-30 Webtv Networks, Inc. Method for downloading a web page to a client for efficient display on a television screen
US5918013A (en) 1996-06-03 1999-06-29 Webtv Networks, Inc. Method of transcoding documents in a network environment using a proxy server
US5987518A (en) 1996-10-28 1999-11-16 General Instrument Corporation Method and apparatus for communicating internet protocol data over a broadband MPEG channel
US6226642B1 (en) 1997-09-11 2001-05-01 International Business Machines Corporation Content modification of internet web pages for a television class display
US5928331A (en) 1997-10-30 1999-07-27 Matsushita Electric Industrial Co., Ltd. Distributed internet protocol-based real-time multimedia streaming architecture
US6201538B1 (en) 1998-01-05 2001-03-13 Amiga Development Llc Controlling the layout of graphics in a television environment
US6263437B1 (en) * 1998-02-19 2001-07-17 Openware Systems Inc Method and apparatus for conducting crypto-ignition processes between thin client devices and server devices over data networks
US6188401B1 (en) 1998-03-25 2001-02-13 Microsoft Corporation Script-based user interface implementation defining components using a text markup language
US6141793A (en) 1998-04-01 2000-10-31 Hewlett-Packard Company Apparatus and method for increasing the performance of interpreted programs running on a server
US6659860B1 (en) 1998-05-12 2003-12-09 Sony Computer Entertainment Inc. Game device, game machine operation device and game system which employ a half-duplex serial communication system and game device two-way communication method
US6397259B1 (en) * 1998-05-29 2002-05-28 Palm, Inc. Method, system and apparatus for packet minimized communications
US6405367B1 (en) 1998-06-05 2002-06-11 Hewlett-Packard Company Apparatus and method for increasing the performance of Java programs running on a server
US6567981B1 (en) * 1998-08-03 2003-05-20 Elysium Broadband Inc. Audio/video signal redistribution system
US6558431B1 (en) 1998-09-11 2003-05-06 Macromedia, Inc. Storing valid and invalid markup language in strict and relaxed tables respectively
JP2002528971A (ja) 1998-10-19 2002-09-03 ジェネラル・インスツルメント・コーポレイション 構成可能な機能をもつテレビジョン・セットトップ・ボックス
US6192082B1 (en) 1998-11-13 2001-02-20 Compaq Computer Corporation Digital television data format conversion with automatic parity detection
SE524391C2 (sv) 1998-12-28 2004-08-03 Spyglass Inc Metod och system för innehållskonvertering av elektroniska dokument för trådlösa klienter.
US6535896B2 (en) 1999-01-29 2003-03-18 International Business Machines Corporation Systems, methods and computer program products for tailoring web page content in hypertext markup language format for display within pervasive computing devices using extensible markup language tools
US6564261B1 (en) 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks
AU5914900A (en) 1999-07-01 2001-01-22 Netmorf, Inc. Cross-media information server
CA2380165A1 (en) 1999-07-20 2001-01-25 United Video Properties, Inc. Interactive television systems with data collection
US6526581B1 (en) * 1999-08-03 2003-02-25 Ucentric Holdings, Llc Multi-service in-home network with an open interface
US7035270B2 (en) * 1999-12-30 2006-04-25 General Instrument Corporation Home networking gateway
US7159235B2 (en) * 2000-01-28 2007-01-02 Sedna Patent Services, Llc Method and apparatus for content distribution via non-homogeneous access networks
US6593944B1 (en) 2000-05-18 2003-07-15 Palm, Inc. Displaying a web page on an electronic display device having a limited display area
EP1170675A1 (de) 2000-07-06 2002-01-09 Gavoa Ltd Darstellung kundenspezifisches Dateninhalts
US20020056109A1 (en) * 2000-07-25 2002-05-09 Tomsen Mai-Lan Method and system to provide a personalized shopping channel VIA an interactive video casting system
US9094226B2 (en) * 2000-08-30 2015-07-28 Broadcom Corporation Home network system and method
US20020062396A1 (en) 2000-10-31 2002-05-23 Mishou Co., Ltd. Server devices for displaying web pages
US7017175B2 (en) * 2001-02-02 2006-03-21 Opentv, Inc. Digital television application protocol for interactive television
US20030093799A1 (en) * 2001-11-14 2003-05-15 Kauffman Marc W. Streamed content Delivery
US6748080B2 (en) * 2002-05-24 2004-06-08 Scientific-Atlanta, Inc. Apparatus for entitling remote client devices

Also Published As

Publication number Publication date
CA2437373A1 (en) 2002-08-15
EP1364511B1 (de) 2006-06-14
AU2002240200B2 (en) 2006-06-15
JP4363847B2 (ja) 2009-11-11
US7882533B2 (en) 2011-02-01
DE60212339D1 (de) 2006-07-27
US7017175B2 (en) 2006-03-21
US20020108122A1 (en) 2002-08-08
ES2266456T3 (es) 2007-03-01
WO2002063851A3 (en) 2003-09-18
US7490346B2 (en) 2009-02-10
AU2002240200B8 (en) 2006-08-31
ATE330408T1 (de) 2006-07-15
JP2004527028A (ja) 2004-09-02
US20020169885A1 (en) 2002-11-14
US20090150966A1 (en) 2009-06-11
EP1364511A2 (de) 2003-11-26
WO2002063851A2 (en) 2002-08-15

Similar Documents

Publication Publication Date Title
DE60212339T2 (de) Ein digitales fernsehen anwendungsprotokoll zum interaktiven fernsehen
US10826748B2 (en) Service gateway for interactive television
AU2002240200A1 (en) A digital television application protocol for interactive television
AU2002237989A1 (en) A service gateway for interactive television
US7127720B2 (en) Storing state in a dynamic content routing network
US20150249854A1 (en) Method and system for recording streams
US20070033293A1 (en) Techniques for delivering personalized content with a real-time routing network
US9178924B1 (en) IPv6 to web architecture
US11503098B2 (en) Embedding MQTT messages in media streams
US20160127803A1 (en) Systems and Methods for Providing an Advertisement Calling Proxy Server
MacLarty et al. Policy-based content delivery: an active network approach
CN113286202A (zh) 一种基于http协议的机顶盒网络节目定制化方法
FR2910213A1 (fr) Procede de diffusion de donnees au sein d'un terminal de reception et terminal implementant le procede.

Legal Events

Date Code Title Description
8364 No opposition during term of opposition