WO2013054305A1 - Remote user interface - Google Patents
Remote user interface Download PDFInfo
- Publication number
- WO2013054305A1 WO2013054305A1 PCT/IB2012/055553 IB2012055553W WO2013054305A1 WO 2013054305 A1 WO2013054305 A1 WO 2013054305A1 IB 2012055553 W IB2012055553 W IB 2012055553W WO 2013054305 A1 WO2013054305 A1 WO 2013054305A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- identified
- rui
- user interface
- features
- services
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
-
- 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/25808—Management of client 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/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/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
- H04N21/26291—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for providing content or additional data updates, e.g. updating software modules, stored at the client
-
- 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/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
- H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
-
- 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/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
- H04N21/4431—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB characterized by the use of Application Program Interface [API] libraries
-
- 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/47—End-user applications
- H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
-
- 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/47—End-user applications
- H04N21/482—End-user interface for program selection
-
- 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/8166—Monomedia components thereof involving executable data, e.g. software
- H04N21/8173—End-user applications, e.g. Web browser, game
Definitions
- the present invention relates to apparatus and methods related to remote user interfaces.
- CE Consumer Electronic
- STB Set-Top Boxes
- a RUI is one solution to the problem of offering a unified and consistent user experience across multiple client devices.
- the RUI paradigm includes the following concepts:
- the UI may be delivered either partially or fully constructed from a server/Gateway (GW), to a plurality of client devices;
- GW server/Gateway
- the server/GW may be located at (or just outside) the subscriber's premises, at a remote headend and/or distributed on both sides; • the client devices accessing the UI may have a plurality of display technologies; and
- the RVU Alliance also developed and made available technical specifications for the distribution of digital audio/video home networked entertainment content augmented with pixel accurate remote user interface graphics based on the RVU protocol.
- the RVU protocol is an application layer protocol that combines the preexisting Digital Living Network Alliance (DLNA) standards and a new Remote User Interface (RUI) protocol, which works in a similar way to the Remote Desktop Protocol (RDP).
- DLNA Digital Living Network Alliance
- RUI Remote User Interface
- the RVU RUI protocol is intended to allow an RVU-enabled client, such as a TV, to receive a pixel-accurate display of the user interface available on an RVU server.
- Embodiments include: gathering available content information related to a plurality of content items from a plurality of content sources via a data network, the plurality of content sources including a public content source and a personal content source; processing the content information, using a processor, to provide digital representations of the plurality of content items, the digital representations including a digital representation of a public content item from the public content source and a digital representation of a personal content item from the personal content source; and displaying available content information related to the selected content item in response to receiving a selection of the content item, the available content information including at least one user-selectable command option for obtaining an additional level of detailed information related to the selected content item.
- a method including: providing at a first device a plurality of API implementations enabling a plurality of features such that, each of the plurality of features is enabled by at least one of the plurality of API implementations, the plurality of features enabling a plurality of services such that, each of the plurality of features at least partially enables at least one of the plurality of services; receiving a request for transmitting a user interface to a second device, the user interface enabling a user of the second device to access and make use of one or more services from the plurality of services, wherein the request further includes a set of parameters characterizing the second device; identifying the second device using the set of parameters; identifying API implementations from the plurality of API implementations to provide to the identified second device, wherein one or more features from the plurality of features is enabled by the identified API implementations, and wherein the one or more features enable the one or more services to be accessed and used at the identified second device; and transmitting the identified API implementations along
- the method further includes: storing layouts, contents and metadata related to a plurality of services to be made available to a plurality of client devices at the first device; identifying layouts, contents and metadata relevant to the user interface, the layouts, contents and metadata being in a format suitable for display and use at the identified second device; and transmitting the identified layouts, contents and metadata relevant to the user interface to the identified second device.
- the receiving includes receiving a request for transmitting a subset of a user interface.
- the user interface is an electronic program guide, the electronic program guide including a plurality of visual elements for display.
- the receiving includes receiving a request for transmitting a subset of a user interface and the subset corresponds to a particular visual element of the electronic program guide.
- the visual element is a single page of the electronic program guide being displayed in full screen.
- the visual element is a widget of the electronic program guide not being displayed in full screen.
- the receiving includes receiving a request from a user of the second device. Still further, in accordance with an embodiment of the present invention, the receiving a request from a second device includes receiving a request for transmitting a user interface every time the second device is powered on.
- the method further includes: receiving a further request for transmitting an updated user interface to the identified second device; and transmitting the updated user interface to the identified second device.
- the receiving a further request includes receiving the further request from the identified second device upon reception by the identified second device of a notification transmitted by the first device, the notification signaling an update of the user interface.
- the notification is transmitted by a television operator headend.
- the notification signals an availability of a new service relevant to the second device.
- the method further includes: identifying API implementations from the plurality of API implementations to provide to the identified second device, wherein one or more features is enabled by the identified API implementations, and wherein the one or more features enable the new service to be accessed and used at the identified second device; and transmitting the identified API implementations along with the updated EPG from the first device to the identified second device.
- the notification signals an availability of a new layout for the user interface.
- the method further incldues: identifying the new layout relevant to the updated user interface, the new layout being in a format suitable for display at the identified second device; and transmitting the identified layout relevant to the updated user interface to the identified second device.
- the notification signals an availability of new contents for the user interface.
- the method further includes: identifying the new contents relevant to the updated user interface, the new contents being in a format suitable for display and use at the identified second device; and transmitting the identified new contents relevant to the updated user interface to the identified second device.
- the receiving a further request includes receiving a further request from a second device upon reception by the second device of a notification transmitted by one service from the one or more services available at the identified second device.
- the receiving a further request includes receiving a further request from a second device upon reception by the second device of a user input requesting the electronic program guide to switch from one visual element to another visual element.
- the set of parameters characterizing the second device includes one or more of: an identifier of the second device; information on data supported by the second device; types of input devices associated to the second device; and types of connections supported by the second device.
- the second device is a client device.
- the first device is a server.
- the first device is another client device.
- a server including: a storage module operable to store a plurality of API implementations enabling a plurality of features such that, each of the plurality of features is enabled by at least one of the plurality of API implementations, the plurality of features enabling a plurality of services such that, each of the plurality of features at least partially enables at least one of the plurality of services; a front end module operable to receive a request for transmitting a user interface to a second device, the user interface enabling a user of the second device to access and make use of one or more services from the plurality of services, wherein the request further includes a set of parameters characterizing the second device; a control manager operable to identify the second device using the set of parameters; a processor module to identify API implementations from the plurality of API implementations to provide to the identified second device, wherein the one or more features from the plurality of features is enabled by the identified API implementations, and wherein the one or more features enable the one or more services
- a server including: means for storing a plurality of API implementations enabling a plurality of features such that, each of the plurality of features is enabled by at least one of the plurality of API implementations, the plurality of features enabling a plurality of services such that, each of the plurality of features at least partially enables at least one of the plurality of services, means for receiving a request for transmitting a user interface to a second device, the user interface enabling a user of the second device to access and make use of one or more services from the plurality of services, wherein the request further includes a set of parameters characterizing the second device; means for identifying the second device using the set of parameters; means for identifying API implementations from the plurality of API implementations to provide to the identified second device, wherein the one or more features from the plurality of features is enabled by the identified API implementations, and wherein the one or more features enable the one or more services to be accessed and used at the identified second device; and means for transmit
- Figures la, lb and lc are simplified block diagram illustrations of interaction sequences between a RUI server and a RUI client device according to embodiments of the present invention
- FIG. 2 is a simplified block diagram illustration of an example infrastructure comprising RUI servers and RUI client devices according to an embodiment of the present invention
- FIG. 3 is a simplified block diagram illustration of a RUI server according to an embodiment of the present invention.
- FIG. 4 is a simplified block diagram illustration of features which may be made available to RUI client devices according to an embodiment of the present invention
- FIG. 5 is a simplified block diagram illustration of a RUI client device according to an embodiment of the present invention.
- FIG. 6 is a simplified block diagram illustration of a RUI EPG and Applications system according to another embodiment of the present invention.
- FIG. 7 is a simplified diagram illustration showing a sequence of operations in a RUI EPG and Applications system according to an embodiment of the present invention.
- Figure 8 is a simplified diagram illustration of a sequence of operations to switch from one widget to another in accordance with an embodiment of the present invention.
- the present invention in embodiments thereof, comprises method and apparatus related to an improved RUI that enables, yet simplifies, the delivery of an EPG and/or UI applications, metadata and content in a large ecosystem of client devices across different communication networks.
- the present invention in embodiments thereof, comprises:
- a RUI enabled Application Programming Interfaces (APIs) system which allows an optimal QoS and user experience to be delivered from a RUI server to a RUI client device; and • a RUI EPG (and/or UI applications) system describing an improved navigation model that may be used with any RUI client device. Communication processes between a RUI server and RUI client devices are also described later in greater detail.
- APIs Application Programming Interfaces
- Figs la-lc are simplified block diagram illustrations of interaction sequences between a RUI server and a RUI client device according to embodiments of the present invention.
- Figs la-lc give a high level overview of communications between a RUI server 100 and a RUI client device 110 in a RUI enabled API system.
- Fig. la is an illustration of a typical interaction sequence between a RUI server 100 and a RUI client device 110 according to an embodiment of the present invention.
- Fig. la describes how a RUI client device 110 retrieves for example, but without limiting the generality of the invention, a RUI EPG (or any RUI application) from a RUI server 100.
- the RUI EPG may be used with any appropriate client device/terminal 110 operable to receive Audio-Video (AV) content (e.g. a STB operable to receive digital TV such as satellite TV, cable TV, and terrestrial or Internet Protocol TV (IPTV); a computer; a tablet computer; a Portable Media Player (PMP); a handheld device; etc.) and which allows a user to view, navigate, select and discover any type of content.
- AV Audio-Video
- STB operable to receive digital TV such as satellite TV, cable TV, and terrestrial or Internet Protocol TV (IPTV)
- IPTV Internet Protocol TV
- PMP Portable Media Player
- the RUI client device 110 boots up and is then ready to establish a communication with a RUI server 100.
- a communication is established between the RUI client device 110 and the RUI server 100. Then, the RUI client device 110 requests a RUI EPG (or a UI application) to be displayed. This request may be made by a user of the RUI client device 110 at any time or automatically generated by the RUI client device 110 either every time the RUI client device 110 is powered on or at regular time intervals.
- a RUI EPG or a UI application
- the RUI server 100 identifies the client device 100 and transmits the relevant RUI EPG.
- the RUI EPG typically enables a user to access and make use of one or more services.
- the RUI EPG may comprise for example, but without limiting the generality of the invention, UI layouts and data related to an EPG and/or any other UI applications, contents and associated metadata and at least one client-side interface.
- a client-side interface is typically an API (Application Programming Interface) implementation that enables a service to be made available at the RUI EPG.
- API Application Programming Interface
- Fig. lb describes a RUI EPG loading operation from a first device 100 (hereinafter referred as the RUI server 100) to a second device (hereinafter referred as the RUI client device 110).
- the RUI client device 110 may request an EPG to be displayed.
- the EPG typically enables a user to access and make use of one or more services. Thereafter, a communication is established between the RUI client device 110 and a RUI server 100.
- the RUI client device 110 requests and receives from the RUI server 100 the client-side APIs. Then at step 2, the RUI server 100 requests and receives the UI layouts and data related to the RUI EPG. Finally, at step 3, the RUI client device 110 receives the contents and associated metadata relevant to the RUI EPG from the RUI server 100 and the RUI EPG is ready to be displayed and used by a user at the RUI client device 110.
- FIG. lc is an illustration of a typical interaction sequence between a RUI server 100 and a RUI client device 110 according to a further embodiment of the present invention.
- Fig. lc describes a sequence occurring when a notification is emitted by a
- the RUI client device 110 receives a notification from the RUI server 100.
- this notification may be a notification corresponding to an update of the RUI EPG.
- the RUI client device 110 processes the notification and requests in response to receiving the updated RUI EPG from the RUI server 100.
- the RUI client device 110 dynamically updates the RUI EPG.
- the entire updated version of the RUI EPG may be delivered or that a subset of the RUI EPG corresponding to the update may be delivered to the to the RUI client device 110.
- Fig. 2 is a simplified block diagram illustration of an exemplary infrastructure comprising RUI servers and RUI client devices according to an embodiment of the present invention.
- the RUI enabled API system according to embodiments of the present invention also provides support for a multi-server and multi-client device infrastructure as shown in the exemplary RUI enabled API system infrastructure of Fig. 2. It will be apparent to someone skilled in the art that the current implementation also supports a single-server and single-client device approach as described in the RUI enabled API system of Fig. la-lc.
- the infrastructure of Fig. 2 shows a plurality of RUI servers 200a- 200i that may be connected to a plurality of client devices 210a-210j.
- a user of one particular client device of the plurality of the client devices 210a-210j may request and receive for example, but without limiting the generality of the invention, an EPG or any UI application from one RUI server of the plurality of RUI servers 200a-200i.
- the RUI EPG may then be retrieved and loaded on the user's client device for display and use.
- the RUI servers 200a-200i may also be interconnected together. Therefore, in an embodiment of the present invention, a particular RUI server may act as a master RUI server (200a for example but without limiting the generality of the present invention).
- the infrastructure is similar to a node or a tree structure wherein the infrastructure may include a master RUI server 200a and slave RUI servers 200b -200i acting as clients of the master RUI server 200a.
- a particular RUI server may provide one or more services (e.g. live TV channels/programs, VOD, push-VOD or near-VOD catalog, recorded programs, user generated contents, etc.) for display and use at the client devices 210a-210j.
- the RUI enabled API system allows superposition of a plurality of services retrieved from several different RUI servers 200a-200i for transmission to client devices 210a-210j over a communications network. Technologies such as Common Request Broker Architecture (CORBA), Universal Plug and Play (UPnP), etc. are typically used to support cumulative servicing over a communications network.
- CORBA Common Request Broker Architecture
- UFP Universal Plug and Play
- the RUI client devices 210a-210j of the RUI enabled API system may be connected to any other suitable RUI servers 200a-200i and RUI client devices 210a-210j.
- the RUI servers 200a-200i and the RUI client devices 210a-210j may be registered and identified so that the RUI enabled API system knows which communications network(s) and/or service(s) a particular RUI client device and/or a particular RUI server are authorized to access.
- the communication and identification protocols used between a master RUI server 200a and the slave RUI servers 200b-200i are the same as the ones used between RUI servers 200a-200i and RUI client devices 210a-210j.
- a RUI server 200a-200i is also able to provide a plurality of
- UI applications such as for example, but without limiting the generality of the invention, an EPG, a game application, a widget application, a television application or any UI interactive application, etc. to RUI client devices 210a-210j.
- the plurality of UI applications may be written in several different programming languages - e.g. HyperText Markup Language (HTML) with Javascript, Flash with Actionscript, etc. - as long as these languages are supported by the presentation engines located in the RUI client devices 210a-210j.
- HTML HyperText Markup Language
- Javascript Javascript
- Flash with Actionscript etc.
- the communication protocol used for communication between the RUI servers 200a-200i and the RUI client devices 210a-210j typically provides APIs and data models that support both pull (in response to a RUI client device request) and push (update/notification from a RUI server) modes.
- pull and push APIs are socket-based such as for example, but not limited to, sockets and/or HTTP/HTTPS GET/PUT, with the use of a listener component located on the RUI client device side.
- This communication protocol is also scalable so that a RUI client device from the RUI client devices 210a-210j may request at its convenience a subset of the overall information available as part of the services.
- the subset may be for example, but not limited to, the next five channels or the ten first on-demand movies, etc. and this subset may be requested by a particular RUI client device at any time.
- Requesting and transmitting only a subset of information to RUI client devices 210a-210j enables the RUI enabled API system to accommodate the requests of a wider range of RUI client devices 210a-210j, each RUI client device 210a-210j having its own characteristics in terms of memory capacity, storage capacity or network connectivity (e.g. WiFi, ethernet, 3G or 4G, etc.).
- the communication protocol also allows customizing replies to RUI client devices 210a-210j according to the capabilities and connectivity means of the RUI client devices 210a-210j.
- the communication protocol allows receiving the different TV channels or TV programs and downloading EPG and/or UI applications as well as RUI client-side APIs. To do so, the requests sent from a RUI client device (210a for example) to a RUI server (200a for example) may include information related to the RUI client device (210a).
- a set of parameters that specifically characterizes the characteristics and the capabilities of the RUI client device (210a) may be sent to the RUI server (200a) along with the request thereby allowing at least identification of the RUI client device (210a).
- This set of parameters typically defines a type of the client device (210a) and may include for example, but not limited to: an identifier of the RUI client device (210a); type, size and format of data supported by the RUI client device (210a); type of input device(s) associated with the RUI client device (210a); type of connectors supported by the RUI client device (210a); etc.
- FIG. 3 is a simplified block diagram illustration of a RUI server in a RUI enabled API system according to an embodiment of the present invention.
- a RUI server 300a is typically located on the server side and includes different modules such as, but not limited to, an ingest module 302, a front end module 304, a processing module 303 and a control manager module 301. It will be apparent to those skilled in the art that it is possible to physically organize these modules in any appropriate manner. Similarly, the RUI server 300a may also be provided as a standalone component or may be integrated into a more complex application.
- the ingest module 302 typically retrieves UI layouts and data for an EPG and/or UI applications, metadata (e.g. additional information and/or description related to a TV program part of a channel line-up), assets (e.g. a channel logo), etc., all of them potentially being of different formats and coming from a plurality of databases 340.
- Fig. 3 shows remote databases 340 that are communicating with the ingest module 302. Those skilled in the art will appreciate that these databases may include local databases i.e. integrated within the RUI server 300a. Then, the ingest module 302 formats the metadata and the assets into a format of preference as defined by the RUI enabled API system.
- the RUI enabled API system of embodiments of the present invention are not limited to a single or a particular format but on the contrary may support a wide range of implementation formats such as, but not limited to, REpresentational State Transfer (REST), extensible Markup Language (XML), or JavaScript Object Notation (JSON), etc.
- the processing module 303 may be used to convert the assets in lieu of the ingest module 302.
- a storage component 350 for later access.
- Fig. 3 shows an external storage component 350 but it will be apparent to someone skilled in the art that this storage component 350 may be integral with the RUI server 300a. In both cases, the storage component 350 may be a high capacity storage device, such as a hard disk or a high capacity memory. Alternatively, the storage component 350 may also be implemented as a file-system based physical device that may be cached into a memory.
- the RUI server 300a also includes a front end module 304, which is the communication interface with the RUI client devices 310a and 310b.
- a front end module 304 is the communication interface with the RUI client devices 310a and 310b.
- the front end module 304 typically receives requests from the RUI client devices 310a and 310b and passes the requests to the processing module 303.
- the front end module 304 is also operative to send replies to the RUI client devices 310a and 310b. To do so, the front end module 304 is therefore able to retrieve UI layouts and data, for EPG or UI applications, as well as formatted assets and metadata from the storage component 350. In another embodiment of the present invention, the front end module 304 is also able to push information (e.g. notification of an update, remote commands, etc.) to RUI client devices 310a and 310b.
- information e.g. notification of an update, remote commands, etc.
- the RUI enabled API system may use a wide range of technologies for enabling connection and communication as well as for ensuring interoperability with the RUI client devices 310a and 310b.
- the front end module 304 may use for example, but without limiting the generality of the present invention, sockets for connections such as Web sockets and HyperText Transfer Protocol (HTTP)/HTTP Secure (HTTPS), and/or may contain adapters for ensuring the interoperability with some RUI client devices 310a and 310b that may have specific characteristics e.g. DLNA, Hybrid broadcast broadband TV (HbbTV), etc.
- the processing module 303 typically receives the RUI client devices requests from the front end module 304.
- the processing module 303 processes the requests and generates customized replies.
- This processing module 303 typically performs some adaptions depending on the RUI client device 310a/310b type (e.g. DLNA client) at the time when the replies are generated.
- the processing module 303 may for example, but without limiting the generality of the invention, convert a picture into a particular format or resolution, so that the picture will be suitable for display at the RUI client device 310a/310b which sent the request.
- the processor module 303 may also identify API implementations that are associated to one or more services requested by the RUI client device 310a/310b. These identified API implementations ensure that the one or more services will be available for use on the RUI client device 310a/310b.
- components external to the processing module 303 - e.g. an external transcoder or a DLNA software component - may be used to perform these adaptions.
- the RUI server 300a also includes a control manager module 301 that controls the correct functioning and monitors the overall state of the RUI server 300a.
- the RUI server 300a also manages identification of the RUI client devices 310a and 310b - including identification of their characteristics - thereby ensuring that the RUI client devices 310a and 310b are connected to the relevant operator backend server 320.
- the control manager module 301 may further interact and exchange data with:
- This operator backend 320 is typically the operator headend that: manages registration and identification of the different devices within the communications network including the RUI client devices 310a and 310b; controls broadcast and/or broadband operations including delivery of AV contents; etc.
- the operator is therefore able to use this communication link to publish and/or notify the RUI server 300a of any modification or update such as for example, but without limiting the generality of the invention, an update of the UI layout or an availability of a new VOD assets;
- This communication link may be present in a case where the RUI server 300a is integrated in a platform like a Consumer Premises Equipment (CPE) e.g. a set-top box (STB) or a gateway (GW).
- CPE Consumer Premises Equipment
- the RUI server 300a may also be servicing RUI client devices 310a and 310b in a home network.
- the communication link may be used to retrieve different types of information such as, but not limited to, Quadrature Amplitude Modulation (QAM)/broadcast channels received directly on the CPE, home network contents (e.g. DLNA based contents), etc.; and
- RUI server 300b located upstream or downstream i.e. a master or a slave RUI server.
- This communication link may be used as a proxy for an upstream server in a complex communications network infrastructure to improve its reliability, bandwidth and response time to RUI client devices 310a and 310b.
- this communication link may also be used in a situation where the RUI server 300a is integrated into different service platforms e.g. headend or GW.
- Fig. 4 is a simplified block diagram illustration of features which may be made available to RUI client devices.
- these services are typically abstracted so that they can be exposed in a generic manner. Therefore, the services may be available to and accessed seamlessly from different RUI client devices and across different communications networks. Similarly, characteristics of RUI client devices and communications networks are also typically abstracted. Therefore, these abstractions help the services to be run on a large ecosystem of RUI client devices through heterogeneous communications networks.
- Fig. 4 e.g. network 400, device 401, content and metadata 402, hybrid services 403, applications 404, users 405, developer 406 and protection 407 and stored in an abstracted form in the storage component 350 on the RUI server side.
- Fig. 4 e.g. network 400, device 401, content and metadata 402, hybrid services 403, applications 404, users 405, developer 406 and protection 407
- Each clustered feature comprises one or more API implementations enabling the feature.
- a plurality of API implementations enabling a plurality of features is stored on the RUI server side.
- Each feature is enabled by at least one API implementation of the plurality of API implementations.
- a service may be enabled by a plurality of features.
- a RUI client device requests a particular service to be available for display and use, then the RUI client device typically identifies a plurality of features for enabling the service.
- a service such as a VOD catalog may be requested to be available at the RUI client device, therefore requiring the RUI client device to identify relevant features related to the VOD catalog (e.g. user inputs supported by the RUI client device to interact with the VOD catalog, video player used by the RUI client, etc.).
- the RUI client device typically identifies one relevant API implementation for each feature that may be related to the service. To do so, the RUI client device sends a request to the RUI server and the relevant API implementations are retrieved from the relevant clusters for the features, thereby enabling the RUI client device to use the service in an optimal manner.
- the clustered features that enable different services to be made available for access and use at the RUI client device comprise:
- Network features using the Network cluster 400 this cluster 400 provides information relevant to the communications network on which a RUI client device is connected e.g. operator communications network, home network or any other user defined network.
- Network information is typically retrieved by Internet Protocol (IP) connectivity including the Media Access Control (MAC) address of an IP router.
- IP Internet Protocol
- MAC Media Access Control
- This cluster 400 also provides information relevant to further RUI client devices that may be connected on the same communications network. This information is typically retrieved by sending a request upstream to an IP router. Those skilled in the art will appreciate that a RUI client device and an IP router may be, in certain situations, the same device.
- this cluster 400 provides means (i.e. API implementations) for communicating to several RUI client devices so that different RUI client devices are able to communicate with each other. This communication is typically initiated and managed by the RUI server to which the RUI client devices are connected. In another embodiment of the present invention, one or more RUI client devices are able to initiate direct communication but still under the supervision of the RUI server. Furthermore, this cluster 400 provides means (i.e. API implementations) for controlling RUI client devices through a remote management system using protocols such as Technical Report 069 (TR-069) of the Broadband Forum, Technical Report 135 (TR-135) of the Broadband Forum or Simple Network Management Protocol (SNMP). Other native protocols may also be used independently or in combination.
- TR-069 Technical Report 069
- TR-135 Technical Report 135
- SNMP Simple Network Management Protocol
- this cluster 400 also provides geolocation information relevant to a RUI client device.
- the HTML5 geolocation feature may be used and/or a static location may be installed on the RUI client device.
- the latter is well suited to situations where a RUI client device is not mobile (e.g. a STB). In such a case, the operator is able to load in advance this static location information using the subscriber's information;
- this cluster 401 detects and provides information relevant to the type and capabilities of a RUI client device. This information is typically retrieved from a user agent or a MAC address of a RUI client device. Other native protocols (e.g. SNMP) may also be used independently or in combination.
- This cluster 401 also provides means (i.e. API implementations) for enabling communication between different presentations engines located on a same platform.
- a local socket is typically used for enabling this bidirectional communication.
- this cluster 401 provides information relevant to input device(s) that may be used by a RUI client device.
- APIs on the RUI client device side typically provide information relevant to generic events/gestures that may be used and understood by an application.
- this cluster 401 provides connectivity information. Applications may not rely on a specific connection to be normally executed.
- This cluster 401 also provides means (i.e. API implementations) for resizing and rescaling a visual element (that may be part, for example, of an EPG or a UI application) on a RUI client device screen.
- this cluster may also provide means (i.e. API implementations) for interpreting metadata relevant to three dimensional (3D) displays.
- this cluster 401 further provides means (i.e. API implementations) for managing a RUI client device storage and/or cache.
- a RUI client device storage and/or cache Different types of storage devices such as HTML5 web storage, a memory, a Structured Query Language (SQL) server or cookies may be used independently or in combination;
- SQL Structured Query Language
- these clusters 402-403 provides contents and/or services characteristics such as, but not limited to: source types (e.g. DLNA, QAM, OTT, social networks, home automation, etc.), local optimizations (i.e. the optimal format to be used on a particular platform), etc.;
- source types e.g. DLNA, QAM, OTT, social networks, home automation, etc.
- local optimizations i.e. the optimal format to be used on a particular platform
- this cluster provides means (i.e. API implementations) for managing the lifecycle of an application.
- the lifecycle includes starting, running and closing an application on a RUI client device under the control of a RUI server.
- the communication protocol used between a RUI server and a RUI client device typically includes a messaging protocol based on events generated for installing, controlling and updating the application. Additionally or alternatively, these events may be used for managing and updating a main application such as an EPG.
- the events may also include events for saving an execution context and a state of an application over a communications network and/or locally on a RUI client device, thereby allowing the application to be resumed later at the saved state using the saved execution context.
- This cluster 405 provides means (i.e. API implementations) for managing a plurality of users.
- the communication protocol used between RUI client devices and RUI servers typically includes means (i.e. API implementations) for identifying a user by use of a login and/or a password.
- the communication protocol is also able to retrieve and save users profiles and preferences, therefore providing a same customized/personal environment whichever RUI client devices are used by a particular user. For example, customized contents and/or customized UI layouts may be displayed seamlessly on all the RUI client devices relevant to a particular user.
- This cluster 406 enables developers to submit new applications to operators and/or subscribers.
- the communication protocol used between RUI client devices and RUI servers typically includes means (i.e. API implementations) for developing, testing and publishing an application. Any developer may therefore develop his own application in a language compliant and executable by a presentation engine.
- the communication protocol may further includes means (i.e. API implementations) for searching, selecting, buying, installing (and uninstalling) and accessing an application published by a developer. Furthermore, the communication protocol may further include means (i.e. API implementations) for logging and tracing errors as well as means (i.e. API implementations) for debugging an application. Additionally, it may include means (i.e. API implementations) for setting a RUI server into simulation mode. The latter is achieved by storing static data on a RUI server without connecting it to an operator backend, or to databases, etc. Content protection features using the Protection cluster 407: this cluster 407 provides means (i.e.
- This cluster 407 further provides means (i.e. API implementations) for accessing secured contents and/or applications. Registration, identification, access rights and certifications are typically managed by the operator backend and communicated to the RUI client devices.
- RUI client devices include means (i.e. API implementations) for receiving the information as well as secure contents and/or applications so that a decrypting operation may be locally performed on the RUI client device.
- Fig. 5 is a simplified diagram illustration of a RUI client device according to an embodiment of the present invention.
- the RUI enabled API system typically includes at least one RUI client device 510 on the client device side.
- the RUI client device 510 comprises different functional modules such as, but not limited to, a display module 580, an input module 590, at least one presentation engine 560, an execution engine module 561, an AV player module 562, a storage module 563, an operating system module 570 and a protection module 571.
- additional modules may be embedded in the RUI client device 510 (e.g. additional modules for a personal computer or a tablet computer) and that these modules may be organized in any appropriate manner.
- the display module 580 typically displays the output of the presentation engine 560. It will be appreciated by those skilled in the art that although shown in Fig. 5 as being integrated into the RUI client device 510 which may be the case for laptop or tablet computers and handheld devices, the display module 580 may also be disposed outside and connected to the RUI client device 510 e.g. a TV connected to the RUI client device 510 with High Definition Memory Interface (HDMI) or Video Graphics Array (VGA) connectors for example. Additionally or alternatively, the RUI client device 510 may also have multiple display modules 580 e.g. more than one display module 580 such as a Nintendo DSTM or may have 3D capabilities.
- HDMI High Definition Memory Interface
- VGA Video Graphics Array
- the input module 590 typically enables a user to control and interact with an application currently being executed such as an EPG or any other UI application.
- the input module 590 typically receives input controls data from one or more input devices such as, but not limited to: a mouse, a keyboard, a touchpad, a tactile screen, a remote control, a 3D camera, etc.
- an input device module may be an input proxy module 590 so that the RUI client device 510 is able to receive inputs commands/events from an external input device e.g. events generated by a tablet computer to control a connected television.
- the presentation engine module 560 typically comprises at least one presentation engine.
- a presentation engine is typically in charge of rendering graphical elements (e.g. control buttons, menus, etc. of a UI) on the display module 580.
- Many different presentation engines exist (e.g. HTML5 browser, Flash, Java, native or Unity 3D engines) and may therefore be used to handle declarative TV applications.
- the execution module 561 is typically embedded within the presentation engine module 560 e.g. Javascript for HTML5 or Actionscript for Flash.
- the execution engine module 561 is a processor that typically executes interactive TV applications for rendering them on the display module 580.
- the AV player module 562 typically receives and decodes AV streams for display on the display module 580.
- the AV player 562 is also able to communicate with the content protection module 571 thereby allowing decryption of encrypted AV streams under the control of the content protection module 571.
- the AV player 562 may also be provided as a separate module.
- the AV player 562 is further able to support a plurality of AV streams thereby enabling a picture in picture functionality.
- the storage module 563 typically stores data downloaded from the RUI server such as UI layouts and data 564, assets 564, metadata 565 and user information 566.
- This module 563 may be any type of storage device such as, but not limited to, a memory, a cache, a database, etc. Although shown as being integrated in the presentation engine module 560, the storage module 563 may also be provided as a separate module.
- the operating system module 570 typically manages hardware resources such as the available memory.
- the operating system module 570 may be any available operating system e.g. Linux, Windows or iOS and may be seen as a specific application like a middleware.
- the content protection module 571 typically handles access rights thereby ensuring that the subscribers have access to secure and encrypted contents and/or services.
- This module 571 may be implemented as a hardware component included in the operating system module 570 or as a software component.
- FIG. 6 is a simplified block diagram illustration of an RUI EPG and Applications system according to an embodiment of the present invention.
- a RUI EPG or a UI application typically enables a user to access and make use of one or more services.
- the RUI EPG or a UI may of the RUI EPG and Applications system comprise one single page or more pages that can be accessed and navigated by a user.
- the different pages of the RUI EPG or UI application may comprise one or more visual element that can be displayed as screens and/or widgets. Therefore, a user may navigate through the RUI EPG or UI application and requests for example, but not limited to, to switch from one visual element to another visual element.
- Widget a widget is a visual element of a graphical user interface that is typically not displayed in full screen mode and therefore partially covers/overlays another display element such as, for example, a video or an EPG.
- a widget typically displays information and provides a specific way for a user to interact with the operating system and application.
- Screen is a visual element of a graphical user interface that is typically displayed in full screen mode.
- a screen may also display information and provide a specific way for a user to interact with the operating system and application.
- the RUI EPG and Applications system 642 may be transmitted along with the RUI from a RUI server to be run on a RUI client device. In another embodiment of the present invention, the RUI EPG and Applications system 642 may be already integrated within a RUI client device.
- the RUI EPG and Applications system 642 defines an improved navigation model that proposes several interfaces separating the EPG and/or applications layouts and data from the actual navigation.
- the RUI EPG and Applications system 642 separates how to navigate from one widget/screen of the EPG/application to another widget/screen from the actual layouts and data. This separation allows parallelized development of each widget or screen for later integration into the overall navigation model. It also allows management of the lifecycle of an EPG and/or applications, even on a per-screen basis, and aims to reduce development time and integration costs, while optimizing the use of the RUI enabled API system 680. Integration is simplified by enabling early development of the navigation model, prior to delivering each widget or screen.
- a widget/screen may be integrated in lieu of a default widget/screen that was used to validate the navigation model.
- the navigation model defined by the RUI EPG and Applications system is dynamic thereby allowing insertion or removal of new visual elements (widgets and/or screens), even at run time.
- the RUI EPG and Applications system 642 includes a context interface 650, a navigation model interface 660 and a screen/widget interface 670 as shown in Fig. 6.
- the navigation model interface 660 is typically able to receive events and/or notifications from the RUI enabled API system 680. Events are typically initiated by a user input. Notifications are typically initiated from a RUI server and/or a RUI client device e.g. system error message, new email or message, message from an external or internal application, etc.
- the navigation model interface 660 defines a navigation model i.e. a decision to show or hide a specific widget or screen according to a received event/notification. For example, but without limiting the generality of the invention, the navigation model interface 660 may decide to open a TV program grid in response to a user pressing a button on a remote control.
- the navigation model interface 660 is further able to graphically layer different widgets and/or screens. This may be achieved for example, but without limiting the generality of the invention, by using the "z-index" feature of the Cascading Style Sheets (CSS) standard for HTML5.
- CSS Cascading Style Sheets
- the navigation model interface 660 also controls the lifecycle of each widget/screen e.g. processes the received event that requests the opening or the closing of a particular widget/screen. This improves resource management (computer processing unit and memory) on a per widget/screen-basis.
- the RUI EPG and Applications system 642 also includes a widget/screen interface 670 operable to receive events and notifications from the RUI enabled API system 680.
- Events are typically the same as the ones described hereinabove in the present specification in relation to the navigation model interface 660. Events are typically initiated by a user input. Notifications are typically initiated from a RUI server and/or a RUI client device e.g. system error message, new email or message, message from an external or internal application, etc.
- the widget/screen interface 670 defines the navigation model for a particular widget/screen.
- the widget/screen interface 670 may be able to manage the display of and navigation through a VOD library (displayed in a widget or in a screen) comprising a plurality of VOD assets.
- the widget/screen model interface 670 may include for example, but without limiting the generality of the invention, means (i.e. API implementations) for:
- the visual element properties include for example, but not limited to, size, aspect ratio and 3D capabilities;
- the input properties typically include the type of events and/or notifications that a particular visual element is able to receive and process.
- a widget/screen may notify capture or dismiss of an event and/or notification to the navigation model interface 660.
- a widget/screen is also able to send a state machine event to another widget/screen;
- the widget/screen model interface 670 typically enables creating, initializing, starting, pausing, resuming, closing, deleting and bringing the visual element on and off the display.
- the RUI EPG and Applications system 642 further comprises a context interface 650.
- a context is information that is shared by the navigation model interface 660 and the widget/screen interface 670 during execution on the RUI client device.
- the context interface 650 typically stores execution information such as, but not limited to, user information (e.g. profiles or preferences), content currently being viewed (e.g. current channel and type of content such as VOD, live, record, catch-up, etc.), content currently being browsed and widgets/screens currently being used and/or displayed. This information is stored in a format compliant to the RUI format.
- the context interface 650 may also include means (i.e.
- the context interface 650 may provide means (i.e. API implementations) for copying and saving the context before the transfer operation and means (i.e. API implementations) for executing the context on the receiving RUI client device upon completion of the transfer operation.
- Fig. 7 is a simplified diagram illustration showing a sequence of operations in the RUI EPG and Application system according to an embodiment of the present invention.
- a connection is established between the navigation model interface 660 of the RUI EPG and Application system 642 and the RUI enabled API system 680.
- the navigation model interface 660 is therefore "listening for” any event and/or notification that will be received by the RUI enabled API system 680.
- an EPG event or an EPG notification is received at the RUI enabled API system 680.
- This EPG event or notification may be received from a RUI server (e.g. notification from a TV operator of an availability of a new VOD asset) or from a user operating the RUI EPG either using a remote control device or the RUI client device itself.
- the EPG event may be relevant to a screen or a widget currently being displayed.
- the EPG event or notification is forwarded to the navigation model interface 660 and a determination is made by the navigation model interface 660 to determine whether the event or notification apply to a particular widget/screen or not. Then, the navigation model interface 660:
- the widget/screen is also operable to send a state machine event to the navigation model interface 660 which might also be the case after processing an event/notification at the widget/screen interface 670.
- Fig. 8 is a simplified diagram illustration of a sequence of operations to switch from one widget to another in accordance with an embodiment of the present invention.
- the navigation model interface 660 processes an event and performs a related action (up/down/left/right/). This related action may be, for example, but not limited to, to close the widget currently being displayed and open another one.
- context information is stored at the context interface (not shown) and typically corresponds to the instruction related to the next navigational step i.e. to display the next widget in this case. Storing such context information is typically useful in situations where an animation or a transition - e.g. zoom in, zoom out, fade, etc. - is to be played before the actual display of the widget.
- the next widget is informed that it will be displayed.
- a related action may also be performed such as updating or merely retrieving layouts, contents or data that are to be displayed.
- the instruction to stop displaying the current widget is sent to and processed at step 805.
- the current widget is closed and the next navigational step is requested from the navigation model interface 660.
- the context information is retrieved and the next widget is displayed at step 807 when the closing animation of the current widget and/or the opening animation of the next widget are finished.
- a further instruction may be sent at step 808 to the current widget thereby removing data related to the current widget no longer useful from the memory.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- Human Computer Interaction (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Graphics (AREA)
- Library & Information Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
Abstract
A method for delivering a remote user interface is described. The method includes: providing at a first device a plurality of API implementations enabling a plurality of features such that, each of the plurality of features is enabled by at least one of the plurality of API implementations, the plurality of features enabling a plurality of services such that, each of the plurality of features at least partially enables at least one of the plurality of services; receiving a request for transmitting a user interface to a second device, the user interface enabling a user of the second device to access and make use of one or more services from the plurality of services, wherein the request further includes a set of parameters characterizing the second device; identifying the second device using the set of parameters; identifying API implementations from the plurality of API implementations to provide to the identified second device, wherein one or more features from the plurality of features is enabled by the identified API implementations, and wherein the one or more features enable the one or more services to be accessed and used at the identified second device; and transmitting the identified API implementations along with the user interface from the first device to the identified second device. Related systems, apparatus and methods are also described.
Description
REMOTE USER INTERFACE
FIELD OF THE INVENTION The present invention relates to apparatus and methods related to remote user interfaces.
BACKGROUND OF THE INVENTION In recent years, and particularly with the advent of powerful yet portable
Consumer Electronic (CE) devices, pay-television (pay- TV) operators are facing a growing challenge to meet their subscribers' demand for a premium content viewing experience on a multitude of client devices, no longer limited to Set-Top Boxes (STBs). These client devices may be, for example, computers, mobile phones, tablet computers or any handheld devices.
Additionally, growing competition means that pay- TV operators are providing ever more advanced services typically requiring end-to-end service orchestration and a greater involvement of the headend - whether it is for transcoding, business logic, or third party service enablement using the pay-TV operator's infrastructure.
It is desirable for a subscriber to be exposed to a coherent and consistent service, which maintains a consistent user experience between the different client devices that may be used to access the services. Since the UI is the visual mechanism by which a subscriber discovers and accesses a service or associated content, the concept of the remote user interface (RUI) was developed.
A RUI is one solution to the problem of offering a unified and consistent user experience across multiple client devices. The RUI paradigm includes the following concepts:
• the UI may be delivered either partially or fully constructed from a server/Gateway (GW), to a plurality of client devices;
• the server/GW may be located at (or just outside) the subscriber's premises, at a remote headend and/or distributed on both sides;
• the client devices accessing the UI may have a plurality of display technologies; and
• the UI may have to work across a wide range of client devices.
Current known Remote User Interface (RUI) technologies are described in a paper called "Remote UI protocols for home environment" presented at a Seminar I'l l 0.5190 on Internetworking held at the Telecommunications Software and Multimedia Laboratory of Helsinki University of Technology in Spring 2007 by Juha Leppilahti. Binary User Interface (UI) protocols aim at transferring the native UI with the native look and feel whereas markup protocols transfer the description of the UI and hence allow unified look and feel that best suits the displaying device. Known protocols that may be used in RUIs are Widex and Universal Plug and Play (UPnP). UPnP is an interoperability enabler that supports multiple remoting protocols. Widex has extensible Markup Language (XML) Document Object Model (DOM) based UI support and hence a generic and flexible architecture for UI rendering.
The RVU Alliance also developed and made available technical specifications for the distribution of digital audio/video home networked entertainment content augmented with pixel accurate remote user interface graphics based on the RVU protocol. The RVU protocol is an application layer protocol that combines the preexisting Digital Living Network Alliance (DLNA) standards and a new Remote User Interface (RUI) protocol, which works in a similar way to the Remote Desktop Protocol (RDP). The RVU RUI protocol is intended to allow an RVU-enabled client, such as a TV, to receive a pixel-accurate display of the user interface available on an RVU server.
US Published Patent Application 2011/0283232 of Jordan et al. also describes a computer-implemented system and method providing a user interface for content browsing and selection in a content system. Embodiments include: gathering available content information related to a plurality of content items from a plurality of content sources via a data network, the plurality of content sources including a public content source and a personal content source; processing the content information, using a processor, to provide digital representations of the plurality of content items, the digital representations including a digital representation of a public content item from the public content source and a digital representation of a personal content item from the personal content source; and displaying available content information related to the selected
content item in response to receiving a selection of the content item, the available content information including at least one user-selectable command option for obtaining an additional level of detailed information related to the selected content item.
SUMMARY OF THE INVENTION
An issue with unmanaged (inter-)communications networks is the complexity of ensuring a consistent Quality of Service (QoS). This is due to the bandwidth variability at each stage of the delivery chain, and also to the coexistence of a wide range of services competing for priority across those same communications networks. In a case of pure video delivery, development of technologies such as Adaptive BitRate (ABR) encoding may be helpful ensuring a consistent QoS remains important for the RUI to provide the best user experience while optimizing the bandwidth availability.
Furthermore, the continuing development of cheaper, yet higher performance hardware for both vertical and horizontal platforms means that a richer and more dynamic user experience may be executed on a large selection of client devices with different presentation engines. In trying to reach these client devices, deployment of native applications quickly developed. These applications also highlighted the value of better use of richer aggregated metadata bringing enhanced user experience. The companies operating in the CE devices space, along with TV operators, are facing issues with native applications in terms of cost of multiple development strains as well as ongoing support/upgrades. Pay- TV operators are also facing the same issues (with TV applications such as Electronic Program Guides (EPGs) for instance) since they have been targeting seamless service integration and these applications are usually not designed to work on different screen resolutions or with different remote controls.
There is thus provided in accordance with an embodiment of the present invention a method including: providing at a first device a plurality of API implementations enabling a plurality of features such that, each of the plurality of features is enabled by at least one of the plurality of API implementations, the plurality of features enabling a plurality of services such that, each of the plurality of features at least partially enables at least one of the plurality of services; receiving a request for transmitting a user interface to a second device, the user interface enabling a user of the second device to
access and make use of one or more services from the plurality of services, wherein the request further includes a set of parameters characterizing the second device; identifying the second device using the set of parameters; identifying API implementations from the plurality of API implementations to provide to the identified second device, wherein one or more features from the plurality of features is enabled by the identified API implementations, and wherein the one or more features enable the one or more services to be accessed and used at the identified second device; and transmitting the identified API implementations along with the user interface from the first device to the identified second device.
Further, in accordance with an embodiment of the present invention, the method further includes: storing layouts, contents and metadata related to a plurality of services to be made available to a plurality of client devices at the first device; identifying layouts, contents and metadata relevant to the user interface, the layouts, contents and metadata being in a format suitable for display and use at the identified second device; and transmitting the identified layouts, contents and metadata relevant to the user interface to the identified second device.
Still further, in accordance with an embodiment of the present invention, the receiving includes receiving a request for transmitting a subset of a user interface.
Additionally, in accordance with an embodiment of the present invention, the user interface is an electronic program guide, the electronic program guide including a plurality of visual elements for display.
Further, in accordance with an embodiment of the present invention, the receiving includes receiving a request for transmitting a subset of a user interface and the subset corresponds to a particular visual element of the electronic program guide.
Still further, in accordance with an embodiment of the present invention, the visual element is a single page of the electronic program guide being displayed in full screen.
Additionally, in accordance with an embodiment of the present invention, the visual element is a widget of the electronic program guide not being displayed in full screen.
Further, in accordance with an embodiment of the present invention, the receiving includes receiving a request from a user of the second device.
Still further, in accordance with an embodiment of the present invention, the receiving a request from a second device includes receiving a request for transmitting a user interface every time the second device is powered on.
Additionally, in accordance with an embodiment of the present invention, the method further includes: receiving a further request for transmitting an updated user interface to the identified second device; and transmitting the updated user interface to the identified second device.
Further, in accordance with an embodiment of the present invention, the receiving a further request includes receiving the further request from the identified second device upon reception by the identified second device of a notification transmitted by the first device, the notification signaling an update of the user interface.
Still further, in accordance with an embodiment of the present invention, the notification is transmitted by a television operator headend.
Additionally, in accordance with an embodiment of the present invention, the notification signals an availability of a new service relevant to the second device.
Further, in accordance with an embodiment of the present invention, the method further includes: identifying API implementations from the plurality of API implementations to provide to the identified second device, wherein one or more features is enabled by the identified API implementations, and wherein the one or more features enable the new service to be accessed and used at the identified second device; and transmitting the identified API implementations along with the updated EPG from the first device to the identified second device.
Still further, in accordance with an embodiment of the present invention, the notification signals an availability of a new layout for the user interface.
Additionally, in accordance with an embodiment of the present invention, the method further incldues: identifying the new layout relevant to the updated user interface, the new layout being in a format suitable for display at the identified second device; and transmitting the identified layout relevant to the updated user interface to the identified second device.
Further, in accordance with an embodiment of the present invention, the notification signals an availability of new contents for the user interface.
Still further, in accordance with an embodiment of the present invention, the method further includes: identifying the new contents relevant to the updated user interface, the new contents being in a format suitable for display and use at the identified second device; and transmitting the identified new contents relevant to the updated user interface to the identified second device.
Additionally, in accordance with an embodiment of the present invention, the receiving a further request includes receiving a further request from a second device upon reception by the second device of a notification transmitted by one service from the one or more services available at the identified second device.
Further, in accordance with an embodiment of the present invention, the receiving a further request includes receiving a further request from a second device upon reception by the second device of a user input requesting the electronic program guide to switch from one visual element to another visual element.
Still further, in accordance with an embodiment of the present invention, the set of parameters characterizing the second device includes one or more of: an identifier of the second device; information on data supported by the second device; types of input devices associated to the second device; and types of connections supported by the second device.
Additionally, in accordance with an embodiment of the present invention, the second device is a client device.
Further, in accordance with an embodiment of the present invention, the first device is a server.
Still further, in accordance with an embodiment of the present invention, the first device is another client device.
There is also provided with a further embodiment of the present invention, a server including: a storage module operable to store a plurality of API implementations enabling a plurality of features such that, each of the plurality of features is enabled by at least one of the plurality of API implementations, the plurality of features enabling a plurality of services such that, each of the plurality of features at least partially enables at least one of the plurality of services; a front end module operable to receive a request for transmitting a user interface to a second device, the user interface enabling a user of the second device to access and make use of one or more services from the plurality of
services, wherein the request further includes a set of parameters characterizing the second device; a control manager operable to identify the second device using the set of parameters; a processor module to identify API implementations from the plurality of API implementations to provide to the identified second device, wherein the one or more features from the plurality of features is enabled by the identified API implementations, and wherein the one or more features enable the one or more services to be accessed and used at the identified second device; and wherein, the front end module is further operable to transmit the identified API implementations along with the user interface from the first device to the identified second device.
There is also provided with a further embodiment of the present invention, a server including: means for storing a plurality of API implementations enabling a plurality of features such that, each of the plurality of features is enabled by at least one of the plurality of API implementations, the plurality of features enabling a plurality of services such that, each of the plurality of features at least partially enables at least one of the plurality of services, means for receiving a request for transmitting a user interface to a second device, the user interface enabling a user of the second device to access and make use of one or more services from the plurality of services, wherein the request further includes a set of parameters characterizing the second device; means for identifying the second device using the set of parameters; means for identifying API implementations from the plurality of API implementations to provide to the identified second device, wherein the one or more features from the plurality of features is enabled by the identified API implementations, and wherein the one or more features enable the one or more services to be accessed and used at the identified second device; and means for transmitting the identified API implementations along with the user interface from the first device to the identified second device.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:
Figures la, lb and lc are simplified block diagram illustrations of interaction sequences between a RUI server and a RUI client device according to embodiments of the present invention;
Figure 2 is a simplified block diagram illustration of an example infrastructure comprising RUI servers and RUI client devices according to an embodiment of the present invention;
Figure 3 is a simplified block diagram illustration of a RUI server according to an embodiment of the present invention;
Figure 4 is a simplified block diagram illustration of features which may be made available to RUI client devices according to an embodiment of the present invention;
Figure 5 is a simplified block diagram illustration of a RUI client device according to an embodiment of the present invention;
Figure 6 is a simplified block diagram illustration of a RUI EPG and Applications system according to another embodiment of the present invention;
Figure 7 is a simplified diagram illustration showing a sequence of operations in a RUI EPG and Applications system according to an embodiment of the present invention; and
Figure 8 is a simplified diagram illustration of a sequence of operations to switch from one widget to another in accordance with an embodiment of the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS The present invention, in embodiments thereof, comprises method and apparatus related to an improved RUI that enables, yet simplifies, the delivery of an EPG and/or UI applications, metadata and content in a large ecosystem of client devices across different communication networks. The present invention, in embodiments thereof, comprises:
· a RUI enabled Application Programming Interfaces (APIs) system which allows an optimal QoS and user experience to be delivered from a RUI server to a RUI client device; and
• a RUI EPG (and/or UI applications) system describing an improved navigation model that may be used with any RUI client device. Communication processes between a RUI server and RUI client devices are also described later in greater detail.
Figs la-lc are simplified block diagram illustrations of interaction sequences between a RUI server and a RUI client device according to embodiments of the present invention. Figs la-lc give a high level overview of communications between a RUI server 100 and a RUI client device 110 in a RUI enabled API system.
Reference is now made to Fig. la which is an illustration of a typical interaction sequence between a RUI server 100 and a RUI client device 110 according to an embodiment of the present invention.
Fig. la describes how a RUI client device 110 retrieves for example, but without limiting the generality of the invention, a RUI EPG (or any RUI application) from a RUI server 100. The RUI EPG may be used with any appropriate client device/terminal 110 operable to receive Audio-Video (AV) content (e.g. a STB operable to receive digital TV such as satellite TV, cable TV, and terrestrial or Internet Protocol TV (IPTV); a computer; a tablet computer; a Portable Media Player (PMP); a handheld device; etc.) and which allows a user to view, navigate, select and discover any type of content. At step 1, the RUI client device 110 boots up and is then ready to establish a communication with a RUI server 100.
At step 2, a communication is established between the RUI client device 110 and the RUI server 100. Then, the RUI client device 110 requests a RUI EPG (or a UI application) to be displayed. This request may be made by a user of the RUI client device 110 at any time or automatically generated by the RUI client device 110 either every time the RUI client device 110 is powered on or at regular time intervals.
At step 3, the RUI server 100 identifies the client device 100 and transmits the relevant RUI EPG. The RUI EPG typically enables a user to access and make use of one or more services. The RUI EPG may comprise for example, but without limiting the generality of the invention, UI layouts and data related to an EPG and/or any other UI applications, contents and associated metadata and at least one client-side interface. A client-side interface is typically an API (Application Programming Interface) implementation that enables a service to be made available at the RUI EPG.
Reference is now made to Fig. lb which is an illustration of a typical interaction sequence between a RUI server 100 and a RUI client device 110 according to an embodiment of the present invention.
Fig. lb describes a RUI EPG loading operation from a first device 100 (hereinafter referred as the RUI server 100) to a second device (hereinafter referred as the RUI client device 110). As described hereinabove in relation to Fig. la, the RUI client device 110 may request an EPG to be displayed. The EPG typically enables a user to access and make use of one or more services. Thereafter, a communication is established between the RUI client device 110 and a RUI server 100.
At step 1 of Fig. lb, upon identification of the RUI client device 110 by the
RUI server 100, the RUI client device 110 requests and receives from the RUI server 100 the client-side APIs. Then at step 2, the RUI server 100 requests and receives the UI layouts and data related to the RUI EPG. Finally, at step 3, the RUI client device 110 receives the contents and associated metadata relevant to the RUI EPG from the RUI server 100 and the RUI EPG is ready to be displayed and used by a user at the RUI client device 110.
Reference is now made to Fig. lc which is an illustration of a typical interaction sequence between a RUI server 100 and a RUI client device 110 according to a further embodiment of the present invention.
Fig. lc describes a sequence occurring when a notification is emitted by a
RUI server 100 and received by a RUI client device 110. At step 1 of Fig. lc, the RUI client device 110, which has previously loaded a RUI EPG, receives a notification from the RUI server 100. Typically, this notification may be a notification corresponding to an update of the RUI EPG. Then, at step 2, the RUI client device 110 processes the notification and requests in response to receiving the updated RUI EPG from the RUI server 100. Finally, at step 3, the RUI client device 110 dynamically updates the RUI EPG. Those skilled in the art will appreciate that the entire updated version of the RUI EPG may be delivered or that a subset of the RUI EPG corresponding to the update may be delivered to the to the RUI client device 110.
Reference is now made to Fig. 2 which is a simplified block diagram illustration of an exemplary infrastructure comprising RUI servers and RUI client devices according to an embodiment of the present invention.
The RUI enabled API system according to embodiments of the present invention also provides support for a multi-server and multi-client device infrastructure as shown in the exemplary RUI enabled API system infrastructure of Fig. 2. It will be apparent to someone skilled in the art that the current implementation also supports a single-server and single-client device approach as described in the RUI enabled API system of Fig. la-lc. The infrastructure of Fig. 2 shows a plurality of RUI servers 200a- 200i that may be connected to a plurality of client devices 210a-210j. Therefore, a user of one particular client device of the plurality of the client devices 210a-210j may request and receive for example, but without limiting the generality of the invention, an EPG or any UI application from one RUI server of the plurality of RUI servers 200a-200i. The RUI EPG may then be retrieved and loaded on the user's client device for display and use.
The RUI servers 200a-200i may also be interconnected together. Therefore, in an embodiment of the present invention, a particular RUI server may act as a master RUI server (200a for example but without limiting the generality of the present invention). In such a case, the infrastructure is similar to a node or a tree structure wherein the infrastructure may include a master RUI server 200a and slave RUI servers 200b -200i acting as clients of the master RUI server 200a.
A particular RUI server may provide one or more services (e.g. live TV channels/programs, VOD, push-VOD or near-VOD catalog, recorded programs, user generated contents, etc.) for display and use at the client devices 210a-210j. The RUI enabled API system allows superposition of a plurality of services retrieved from several different RUI servers 200a-200i for transmission to client devices 210a-210j over a communications network. Technologies such as Common Request Broker Architecture (CORBA), Universal Plug and Play (UPnP), etc. are typically used to support cumulative servicing over a communications network.
In another embodiment of the present invention, the RUI client devices 210a-210j of the RUI enabled API system may be connected to any other suitable RUI servers 200a-200i and RUI client devices 210a-210j.
The RUI servers 200a-200i and the RUI client devices 210a-210j may be registered and identified so that the RUI enabled API system knows which communications network(s) and/or service(s) a particular RUI client device and/or a particular RUI server are authorized to access.
In a further embodiment of the present invention, the communication and identification protocols used between a master RUI server 200a and the slave RUI servers 200b-200i are the same as the ones used between RUI servers 200a-200i and RUI client devices 210a-210j.
Furthermore, a RUI server 200a-200i is also able to provide a plurality of
UI applications such as for example, but without limiting the generality of the invention, an EPG, a game application, a widget application, a television application or any UI interactive application, etc. to RUI client devices 210a-210j. The plurality of UI applications may be written in several different programming languages - e.g. HyperText Markup Language (HTML) with Javascript, Flash with Actionscript, etc. - as long as these languages are supported by the presentation engines located in the RUI client devices 210a-210j.
The communication protocol used for communication between the RUI servers 200a-200i and the RUI client devices 210a-210j typically provides APIs and data models that support both pull (in response to a RUI client device request) and push (update/notification from a RUI server) modes. In a further embodiment of the present invention, pull and push APIs are socket-based such as for example, but not limited to, sockets and/or HTTP/HTTPS GET/PUT, with the use of a listener component located on the RUI client device side. This communication protocol is also scalable so that a RUI client device from the RUI client devices 210a-210j may request at its convenience a subset of the overall information available as part of the services. The subset may be for example, but not limited to, the next five channels or the ten first on-demand movies, etc. and this subset may be requested by a particular RUI client device at any time. Requesting and transmitting only a subset of information to RUI client devices 210a-210j enables the RUI enabled API system to accommodate the requests of a wider range of RUI client devices 210a-210j, each RUI client device 210a-210j having its own characteristics in terms of memory capacity, storage capacity or network connectivity (e.g. WiFi, ethernet, 3G or 4G, etc.).
On the RUI server side, the communication protocol also allows customizing replies to RUI client devices 210a-210j according to the capabilities and connectivity means of the RUI client devices 210a-210j. On the RUI client device side, the communication protocol allows receiving the different TV channels or TV programs
and downloading EPG and/or UI applications as well as RUI client-side APIs. To do so, the requests sent from a RUI client device (210a for example) to a RUI server (200a for example) may include information related to the RUI client device (210a). In order to generate a customized reply to the RUI client device (210a), a set of parameters that specifically characterizes the characteristics and the capabilities of the RUI client device (210a) may be sent to the RUI server (200a) along with the request thereby allowing at least identification of the RUI client device (210a). This set of parameters typically defines a type of the client device (210a) and may include for example, but not limited to: an identifier of the RUI client device (210a); type, size and format of data supported by the RUI client device (210a); type of input device(s) associated with the RUI client device (210a); type of connectors supported by the RUI client device (210a); etc.
Reference is now made to Fig. 3 which is a simplified block diagram illustration of a RUI server in a RUI enabled API system according to an embodiment of the present invention.
A RUI server 300a is typically located on the server side and includes different modules such as, but not limited to, an ingest module 302, a front end module 304, a processing module 303 and a control manager module 301. It will be apparent to those skilled in the art that it is possible to physically organize these modules in any appropriate manner. Similarly, the RUI server 300a may also be provided as a standalone component or may be integrated into a more complex application.
The ingest module 302 typically retrieves UI layouts and data for an EPG and/or UI applications, metadata (e.g. additional information and/or description related to a TV program part of a channel line-up), assets (e.g. a channel logo), etc., all of them potentially being of different formats and coming from a plurality of databases 340. Fig. 3 shows remote databases 340 that are communicating with the ingest module 302. Those skilled in the art will appreciate that these databases may include local databases i.e. integrated within the RUI server 300a. Then, the ingest module 302 formats the metadata and the assets into a format of preference as defined by the RUI enabled API system. It will be apparent to those skilled in the art that the RUI enabled API system of embodiments of the present invention are not limited to a single or a particular format but on the contrary may support a wide range of implementation formats such as, but not limited to, REpresentational State Transfer (REST), extensible Markup Language (XML),
or JavaScript Object Notation (JSON), etc. In another embodiment of the present invention, the processing module 303 may be used to convert the assets in lieu of the ingest module 302.
Once retrieved and formatted, the UI layouts and data, metadata and assets are stored in a storage component 350 for later access. Fig. 3 shows an external storage component 350 but it will be apparent to someone skilled in the art that this storage component 350 may be integral with the RUI server 300a. In both cases, the storage component 350 may be a high capacity storage device, such as a hard disk or a high capacity memory. Alternatively, the storage component 350 may also be implemented as a file-system based physical device that may be cached into a memory.
The RUI server 300a also includes a front end module 304, which is the communication interface with the RUI client devices 310a and 310b. For simplicity of description and depiction, but without limiting the generality of the present invention, only two client devices 310a and 310b have been represented in Fig. 3. The front end module 304 typically receives requests from the RUI client devices 310a and 310b and passes the requests to the processing module 303.
Once the requests are processed by the processing module 303, the front end module 304 is also operative to send replies to the RUI client devices 310a and 310b. To do so, the front end module 304 is therefore able to retrieve UI layouts and data, for EPG or UI applications, as well as formatted assets and metadata from the storage component 350. In another embodiment of the present invention, the front end module 304 is also able to push information (e.g. notification of an update, remote commands, etc.) to RUI client devices 310a and 310b.
Again, the RUI enabled API system, according to embodiments of the present invention, may use a wide range of technologies for enabling connection and communication as well as for ensuring interoperability with the RUI client devices 310a and 310b. The front end module 304 may use for example, but without limiting the generality of the present invention, sockets for connections such as Web sockets and HyperText Transfer Protocol (HTTP)/HTTP Secure (HTTPS), and/or may contain adapters for ensuring the interoperability with some RUI client devices 310a and 310b that may have specific characteristics e.g. DLNA, Hybrid broadcast broadband TV (HbbTV), etc.
The processing module 303 typically receives the RUI client devices requests from the front end module 304. Then, the processing module 303 processes the requests and generates customized replies. This processing module 303 typically performs some adaptions depending on the RUI client device 310a/310b type (e.g. DLNA client) at the time when the replies are generated. The processing module 303 may for example, but without limiting the generality of the invention, convert a picture into a particular format or resolution, so that the picture will be suitable for display at the RUI client device 310a/310b which sent the request. The processor module 303 may also identify API implementations that are associated to one or more services requested by the RUI client device 310a/310b. These identified API implementations ensure that the one or more services will be available for use on the RUI client device 310a/310b. In another embodiment of the present invention, components external to the processing module 303 - e.g. an external transcoder or a DLNA software component - may be used to perform these adaptions.
The RUI server 300a also includes a control manager module 301 that controls the correct functioning and monitors the overall state of the RUI server 300a. The RUI server 300a also manages identification of the RUI client devices 310a and 310b - including identification of their characteristics - thereby ensuring that the RUI client devices 310a and 310b are connected to the relevant operator backend server 320. The control manager module 301 may further interact and exchange data with:
• an operator backend 320. This operator backend 320 is typically the operator headend that: manages registration and identification of the different devices within the communications network including the RUI client devices 310a and 310b; controls broadcast and/or broadband operations including delivery of AV contents; etc. The operator is therefore able to use this communication link to publish and/or notify the RUI server 300a of any modification or update such as for example, but without limiting the generality of the invention, an update of the UI layout or an availability of a new VOD assets;
• a middleware 330. This communication link may be present in a case where the RUI server 300a is integrated in a platform like a Consumer Premises Equipment (CPE) e.g. a set-top box (STB) or a gateway (GW). The RUI
server 300a may also be servicing RUI client devices 310a and 310b in a home network. In such a case, the communication link may be used to retrieve different types of information such as, but not limited to, Quadrature Amplitude Modulation (QAM)/broadcast channels received directly on the CPE, home network contents (e.g. DLNA based contents), etc.; and
• another RUI server 300b located upstream or downstream i.e. a master or a slave RUI server. This communication link may be used as a proxy for an upstream server in a complex communications network infrastructure to improve its reliability, bandwidth and response time to RUI client devices 310a and 310b. Furthermore, this communication link may also be used in a situation where the RUI server 300a is integrated into different service platforms e.g. headend or GW.
Reference is now made to Fig. 4 which is a simplified block diagram illustration of features which may be made available to RUI client devices.
To offer a number of services in a unified manner to a plurality of RUI client devices, these services are typically abstracted so that they can be exposed in a generic manner. Therefore, the services may be available to and accessed seamlessly from different RUI client devices and across different communications networks. Similarly, characteristics of RUI client devices and communications networks are also typically abstracted. Therefore, these abstractions help the services to be run on a large ecosystem of RUI client devices through heterogeneous communications networks.
In an embodiment of the present invention, several features enabling a plurality of services to be made available to a plurality of RUI client devices through the RUI enabled API system, are clustered into different categories as shown in Fig. 4 (e.g. network 400, device 401, content and metadata 402, hybrid services 403, applications 404, users 405, developer 406 and protection 407) and stored in an abstracted form in the storage component 350 on the RUI server side. It will be apparent to those skilled in the art that these clusters may be organized in any appropriate manner. Each clustered feature comprises one or more API implementations enabling the feature. In another embodiment of the present invention, a plurality of API implementations enabling a plurality of features is stored on the RUI server side. Each feature is enabled by at least one API
implementation of the plurality of API implementations. Furthermore, a service may be enabled by a plurality of features. When a RUI client device requests a particular service to be available for display and use, then the RUI client device typically identifies a plurality of features for enabling the service. For example, but without limiting the generality of the invention, a service such as a VOD catalog may be requested to be available at the RUI client device, therefore requiring the RUI client device to identify relevant features related to the VOD catalog (e.g. user inputs supported by the RUI client device to interact with the VOD catalog, video player used by the RUI client, etc.). Then, the RUI client device typically identifies one relevant API implementation for each feature that may be related to the service. To do so, the RUI client device sends a request to the RUI server and the relevant API implementations are retrieved from the relevant clusters for the features, thereby enabling the RUI client device to use the service in an optimal manner. The clustered features that enable different services to be made available for access and use at the RUI client device comprise:
• Network features using the Network cluster 400: this cluster 400 provides information relevant to the communications network on which a RUI client device is connected e.g. operator communications network, home network or any other user defined network. Network information is typically retrieved by Internet Protocol (IP) connectivity including the Media Access Control (MAC) address of an IP router.
This cluster 400 also provides information relevant to further RUI client devices that may be connected on the same communications network. This information is typically retrieved by sending a request upstream to an IP router. Those skilled in the art will appreciate that a RUI client device and an IP router may be, in certain situations, the same device.
Additionally, this cluster 400 provides means (i.e. API implementations) for communicating to several RUI client devices so that different RUI client devices are able to communicate with each other. This communication is typically initiated and managed by the RUI server to which the RUI client devices are connected. In another embodiment of the present invention, one or more RUI client devices are able to initiate direct communication but still under the supervision of the RUI server.
Furthermore, this cluster 400 provides means (i.e. API implementations) for controlling RUI client devices through a remote management system using protocols such as Technical Report 069 (TR-069) of the Broadband Forum, Technical Report 135 (TR-135) of the Broadband Forum or Simple Network Management Protocol (SNMP). Other native protocols may also be used independently or in combination.
Finally, this cluster 400 also provides geolocation information relevant to a RUI client device. The HTML5 geolocation feature may be used and/or a static location may be installed on the RUI client device. The latter is well suited to situations where a RUI client device is not mobile (e.g. a STB). In such a case, the operator is able to load in advance this static location information using the subscriber's information;
Abstracted device features using the Device cluster 401: this cluster 401 detects and provides information relevant to the type and capabilities of a RUI client device. This information is typically retrieved from a user agent or a MAC address of a RUI client device. Other native protocols (e.g. SNMP) may also be used independently or in combination.
This cluster 401 also provides means (i.e. API implementations) for enabling communication between different presentations engines located on a same platform. A local socket is typically used for enabling this bidirectional communication.
Additionally, this cluster 401 provides information relevant to input device(s) that may be used by a RUI client device. APIs on the RUI client device side typically provide information relevant to generic events/gestures that may be used and understood by an application.
Furthermore, this cluster 401 provides connectivity information. Applications may not rely on a specific connection to be normally executed. This cluster 401 also provides means (i.e. API implementations) for resizing and rescaling a visual element (that may be part, for example, of an EPG or a UI application) on a RUI client device screen. In an embodiment of the present invention, this cluster may also provide means (i.e. API
implementations) for interpreting metadata relevant to three dimensional (3D) displays.
Finally, this cluster 401 further provides means (i.e. API implementations) for managing a RUI client device storage and/or cache. Different types of storage devices such as HTML5 web storage, a memory, a Structured Query Language (SQL) server or cookies may be used independently or in combination;
Abstracted sources and/or contents using the Hydrid Content/Metadata cluster 402 and Services using the Hybrid Services cluster 403: these clusters 402-403 provides contents and/or services characteristics such as, but not limited to: source types (e.g. DLNA, QAM, OTT, social networks, home automation, etc.), local optimizations (i.e. the optimal format to be used on a particular platform), etc.;
Application and store features using the Application & Store cluster 404: this cluster provides means (i.e. API implementations) for managing the lifecycle of an application. The lifecycle includes starting, running and closing an application on a RUI client device under the control of a RUI server. The communication protocol used between a RUI server and a RUI client device typically includes a messaging protocol based on events generated for installing, controlling and updating the application. Additionally or alternatively, these events may be used for managing and updating a main application such as an EPG. The events may also include events for saving an execution context and a state of an application over a communications network and/or locally on a RUI client device, thereby allowing the application to be resumed later at the saved state using the saved execution context. These events are typically related to operator's applications but may further include public events and methods that may be used by a third party entity to develop an application. Finally, the events may further include private events enabling several applications to communicate with each other (e.g. by posting messages and/or notifications);
User related features using the User cluster 405: this cluster 405 provides means (i.e. API implementations) for managing a plurality of users. The communication protocol used between RUI client devices and RUI servers typically includes means (i.e. API implementations) for identifying a user by use of a login and/or a password. The communication protocol is also able to retrieve and save users profiles and preferences, therefore providing a same customized/personal environment whichever RUI client devices are used by a particular user. For example, customized contents and/or customized UI layouts may be displayed seamlessly on all the RUI client devices relevant to a particular user.
Developer features using the Developer cluster 406: this cluster 406 enables developers to submit new applications to operators and/or subscribers. The communication protocol used between RUI client devices and RUI servers typically includes means (i.e. API implementations) for developing, testing and publishing an application. Any developer may therefore develop his own application in a language compliant and executable by a presentation engine.
The communication protocol may further includes means (i.e. API implementations) for searching, selecting, buying, installing (and uninstalling) and accessing an application published by a developer. Furthermore, the communication protocol may further include means (i.e. API implementations) for logging and tracing errors as well as means (i.e. API implementations) for debugging an application. Additionally, it may include means (i.e. API implementations) for setting a RUI server into simulation mode. The latter is achieved by storing static data on a RUI server without connecting it to an operator backend, or to databases, etc. Content protection features using the Protection cluster 407: this cluster 407 provides means (i.e. API implementations) for registering and identifying RUI client devices owned by a user over a communications network, thereby allowing a secure access to contents and services. This cluster 407 further provides means (i.e. API implementations) for accessing secured contents and/or applications. Registration, identification, access rights and
certifications are typically managed by the operator backend and communicated to the RUI client devices. These RUI client devices include means (i.e. API implementations) for receiving the information as well as secure contents and/or applications so that a decrypting operation may be locally performed on the RUI client device.
Reference is now made to Fig. 5 which is a simplified diagram illustration of a RUI client device according to an embodiment of the present invention.
The RUI enabled API system typically includes at least one RUI client device 510 on the client device side. The RUI client device 510 comprises different functional modules such as, but not limited to, a display module 580, an input module 590, at least one presentation engine 560, an execution engine module 561, an AV player module 562, a storage module 563, an operating system module 570 and a protection module 571. Those skilled in the art will appreciate that additional modules may be embedded in the RUI client device 510 (e.g. additional modules for a personal computer or a tablet computer) and that these modules may be organized in any appropriate manner.
The display module 580 typically displays the output of the presentation engine 560. It will be appreciated by those skilled in the art that although shown in Fig. 5 as being integrated into the RUI client device 510 which may be the case for laptop or tablet computers and handheld devices, the display module 580 may also be disposed outside and connected to the RUI client device 510 e.g. a TV connected to the RUI client device 510 with High Definition Memory Interface (HDMI) or Video Graphics Array (VGA) connectors for example. Additionally or alternatively, the RUI client device 510 may also have multiple display modules 580 e.g. more than one display module 580 such as a Nintendo DS™ or may have 3D capabilities.
The input module 590 typically enables a user to control and interact with an application currently being executed such as an EPG or any other UI application. The input module 590 typically receives input controls data from one or more input devices such as, but not limited to: a mouse, a keyboard, a touchpad, a tactile screen, a remote control, a 3D camera, etc. In another embodiment of the present invention, an input device module may be an input proxy module 590 so that the RUI client device 510 is able to receive inputs commands/events from an external input device e.g. events generated by a tablet computer to control a connected television.
The presentation engine module 560 typically comprises at least one presentation engine. A presentation engine is typically in charge of rendering graphical elements (e.g. control buttons, menus, etc. of a UI) on the display module 580. Many different presentation engines exist (e.g. HTML5 browser, Flash, Java, native or Unity 3D engines) and may therefore be used to handle declarative TV applications.
The execution module 561 is typically embedded within the presentation engine module 560 e.g. Javascript for HTML5 or Actionscript for Flash. The execution engine module 561 is a processor that typically executes interactive TV applications for rendering them on the display module 580.
The AV player module 562 typically receives and decodes AV streams for display on the display module 580. The AV player 562 is also able to communicate with the content protection module 571 thereby allowing decryption of encrypted AV streams under the control of the content protection module 571. Although shown as being integrated in the presentation engine module 560, the AV player 562 may also be provided as a separate module. The AV player 562 is further able to support a plurality of AV streams thereby enabling a picture in picture functionality.
The storage module 563 typically stores data downloaded from the RUI server such as UI layouts and data 564, assets 564, metadata 565 and user information 566. This module 563 may be any type of storage device such as, but not limited to, a memory, a cache, a database, etc. Although shown as being integrated in the presentation engine module 560, the storage module 563 may also be provided as a separate module.
The operating system module 570 typically manages hardware resources such as the available memory. The operating system module 570 may be any available operating system e.g. Linux, Windows or iOS and may be seen as a specific application like a middleware.
Finally, the content protection module 571 typically handles access rights thereby ensuring that the subscribers have access to secure and encrypted contents and/or services. This module 571 may be implemented as a hardware component included in the operating system module 570 or as a software component.
Reference is now made to Fig. 6 which is a simplified block diagram illustration of an RUI EPG and Applications system according to an embodiment of the present invention. A RUI EPG or a UI application typically enables a user to access and
make use of one or more services. The RUI EPG or a UI may of the RUI EPG and Applications system comprise one single page or more pages that can be accessed and navigated by a user. Furthermore, the different pages of the RUI EPG or UI application may comprise one or more visual element that can be displayed as screens and/or widgets. Therefore, a user may navigate through the RUI EPG or UI application and requests for example, but not limited to, to switch from one visual element to another visual element.
By way of introduction, the following definitions will aid understanding of the embodiments of the present invention.
Widget: a widget is a visual element of a graphical user interface that is typically not displayed in full screen mode and therefore partially covers/overlays another display element such as, for example, a video or an EPG. A widget typically displays information and provides a specific way for a user to interact with the operating system and application.
Screen: a screen is a visual element of a graphical user interface that is typically displayed in full screen mode. A screen may also display information and provide a specific way for a user to interact with the operating system and application.
The RUI EPG and Applications system 642 may be transmitted along with the RUI from a RUI server to be run on a RUI client device. In another embodiment of the present invention, the RUI EPG and Applications system 642 may be already integrated within a RUI client device.
The RUI EPG and Applications system 642 defines an improved navigation model that proposes several interfaces separating the EPG and/or applications layouts and data from the actual navigation. In other words, the RUI EPG and Applications system 642 separates how to navigate from one widget/screen of the EPG/application to another widget/screen from the actual layouts and data. This separation allows parallelized development of each widget or screen for later integration into the overall navigation model. It also allows management of the lifecycle of an EPG and/or applications, even on a per-screen basis, and aims to reduce development time and integration costs, while optimizing the use of the RUI enabled API system 680. Integration is simplified by enabling early development of the navigation model, prior to delivering each widget or screen. Once mature enough, a widget/screen may be integrated in lieu of a default widget/screen that was used to validate the navigation model. Furthermore, the navigation
model defined by the RUI EPG and Applications system is dynamic thereby allowing insertion or removal of new visual elements (widgets and/or screens), even at run time.
The RUI EPG and Applications system 642 includes a context interface 650, a navigation model interface 660 and a screen/widget interface 670 as shown in Fig. 6.
The navigation model interface 660 is typically able to receive events and/or notifications from the RUI enabled API system 680. Events are typically initiated by a user input. Notifications are typically initiated from a RUI server and/or a RUI client device e.g. system error message, new email or message, message from an external or internal application, etc.
The navigation model interface 660 defines a navigation model i.e. a decision to show or hide a specific widget or screen according to a received event/notification. For example, but without limiting the generality of the invention, the navigation model interface 660 may decide to open a TV program grid in response to a user pressing a button on a remote control.
The navigation model interface 660 is further able to graphically layer different widgets and/or screens. This may be achieved for example, but without limiting the generality of the invention, by using the "z-index" feature of the Cascading Style Sheets (CSS) standard for HTML5.
Furthermore, the navigation model interface 660 also controls the lifecycle of each widget/screen e.g. processes the received event that requests the opening or the closing of a particular widget/screen. This improves resource management (computer processing unit and memory) on a per widget/screen-basis.
The RUI EPG and Applications system 642 also includes a widget/screen interface 670 operable to receive events and notifications from the RUI enabled API system 680. Events are typically the same as the ones described hereinabove in the present specification in relation to the navigation model interface 660. Events are typically initiated by a user input. Notifications are typically initiated from a RUI server and/or a RUI client device e.g. system error message, new email or message, message from an external or internal application, etc.
The widget/screen interface 670 defines the navigation model for a particular widget/screen. For example, but without limiting the generality of the present
invention, the widget/screen interface 670 may be able to manage the display of and navigation through a VOD library (displayed in a widget or in a screen) comprising a plurality of VOD assets.
The widget/screen model interface 670 may include for example, but without limiting the generality of the invention, means (i.e. API implementations) for:
• retrieving visual properties of a visual element. The visual element properties include for example, but not limited to, size, aspect ratio and 3D capabilities;
• retrieving input properties supported by a visual element. The input properties typically include the type of events and/or notifications that a particular visual element is able to receive and process. Upon reception of an event and/or a notification, a widget/screen may notify capture or dismiss of an event and/or notification to the navigation model interface 660. In another embodiment of the present invention, a widget/screen is also able to send a state machine event to another widget/screen; and
• controlling the lifecycle of a visual element. The widget/screen model interface 670 typically enables creating, initializing, starting, pausing, resuming, closing, deleting and bringing the visual element on and off the display.
The RUI EPG and Applications system 642 further comprises a context interface 650. A context is information that is shared by the navigation model interface 660 and the widget/screen interface 670 during execution on the RUI client device. The context interface 650 typically stores execution information such as, but not limited to, user information (e.g. profiles or preferences), content currently being viewed (e.g. current channel and type of content such as VOD, live, record, catch-up, etc.), content currently being browsed and widgets/screens currently being used and/or displayed. This information is stored in a format compliant to the RUI format. The context interface 650 may also include means (i.e. API implementations) for transferring a context from a RUI client device to another RUI client device as long as both RUI client devices are running the same RUI, which may be the case in situations where for example, but not limited to, a RUI client device acts as a RUI server for another RUI client device, or when a same RUI has been transmitted to a plurality of RUI client devices, etc. To do so, the context
interface 650 may provide means (i.e. API implementations) for copying and saving the context before the transfer operation and means (i.e. API implementations) for executing the context on the receiving RUI client device upon completion of the transfer operation.
Reference is now made to Fig. 7, which is a simplified diagram illustration showing a sequence of operations in the RUI EPG and Application system according to an embodiment of the present invention.
At step 701, a connection is established between the navigation model interface 660 of the RUI EPG and Application system 642 and the RUI enabled API system 680. The navigation model interface 660 is therefore "listening for" any event and/or notification that will be received by the RUI enabled API system 680.
At step 702, an EPG event or an EPG notification is received at the RUI enabled API system 680. This EPG event or notification may be received from a RUI server (e.g. notification from a TV operator of an availability of a new VOD asset) or from a user operating the RUI EPG either using a remote control device or the RUI client device itself. In this situation, the EPG event may be relevant to a screen or a widget currently being displayed.
In any case, the EPG event or notification is forwarded to the navigation model interface 660 and a determination is made by the navigation model interface 660 to determine whether the event or notification apply to a particular widget/screen or not. Then, the navigation model interface 660:
• may process the event or notification at step 704 if the widget/screen does not capture (i.e. dismisses) it and performs a related action if a machine state applies; or
• does not process the event or the notification if the widget/screen captures the EPG event or notification (step 705). Then, the widget/screen interface
670 (not shown) performs a related action at step 706.
The widget/screen is also operable to send a state machine event to the navigation model interface 660 which might also be the case after processing an event/notification at the widget/screen interface 670.
Reference is now made to Fig. 8, which is a simplified diagram illustration of a sequence of operations to switch from one widget to another in accordance with an embodiment of the present invention.
At step 801, the navigation model interface 660 processes an event and performs a related action (up/down/left/right/...). This related action may be, for example, but not limited to, to close the widget currently being displayed and open another one. Then, at step 802, context information is stored at the context interface (not shown) and typically corresponds to the instruction related to the next navigational step i.e. to display the next widget in this case. Storing such context information is typically useful in situations where an animation or a transition - e.g. zoom in, zoom out, fade, etc. - is to be played before the actual display of the widget.
At step 803, the next widget is informed that it will be displayed. A related action may also be performed such as updating or merely retrieving layouts, contents or data that are to be displayed. Also, at step 804, the instruction to stop displaying the current widget is sent to and processed at step 805. The current widget is closed and the next navigational step is requested from the navigation model interface 660. The context information is retrieved and the next widget is displayed at step 807 when the closing animation of the current widget and/or the opening animation of the next widget are finished. Finally, a further instruction may be sent at step 808 to the current widget thereby removing data related to the current widget no longer useful from the memory.
Although the above embodiments have been described as being carried out on the client and/or the server side, someone skilled in the art will appreciate that various features of the present invention may be implemented in intermediate network components.
It is appreciated that various features of the present invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.
It will be appreciated by people skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the invention is defined only by the claims which follow.
Claims
1. A method comprising:
providing at a first device a plurality of API implementations enabling a plurality of features such that, each of said plurality of features is enabled by at least one of said plurality of API implementations, said plurality of features enabling a plurality of services such that each of said plurality of features at least partially enables at least one of said plurality of services;
receiving a request for transmitting a user interface to a second device, said user interface enabling a user of said second device to access and make use of one or more services from said plurality of services, wherein said request further comprises a set of parameters characterizing said second device;
identifying said second device using said set of parameters;
identifying API implementations from said plurality of API implementations to provide to said identified second device, wherein one or more features from said plurality of features is enabled by said identified API implementations, and wherein said one or more features enable said one or more services to be accessed and used at said identified second device; and
transmitting said identified API implementations along with said user interface from said first device to said identified second device.
2. The method of claim 1, said method further comprising:
storing layouts, contents and metadata related to a plurality of services to be made available to a plurality of client devices at said first device;
identifying layouts, contents and metadata relevant to said user interface, said layouts, contents and metadata being in a format suitable for display and use at said identified second device; and
transmitting said identified layouts, contents and metadata relevant to said user interface to said identified second device.
3. The method of any preceding claim, wherein said receiving comprises receiving a request for transmitting a subset of a user interface.
4. The method of any preceding claim wherein said user interface is an electronic program guide, said electronic program guide comprising a plurality of visual elements for display.
5. The method of claim 4, wherein said receiving comprises receiving a request for transmitting a subset of a user interface and said subset corresponds to a particular visual element of said electronic program guide.
6. The method of claim 5, wherein said visual element is a single page of said electronic program guide being displayed in full screen.
7. The method of claim 5, wherein said visual element is a widget of said electronic program guide not being displayed in full screen.
8. The method of any preceding claim, wherein said receiving comprises receiving a request from a user of said second device.
9. The method of any preceding claim, wherein said receiving a request from a second device comprises receiving a request for transmitting a user interface every time said second device is powered on.
10. The method of any preceding claim, said method further comprising:
receiving a further request for transmitting an updated user interface to said identified second device; and
transmitting said updated user interface to said identified second device.
11. The method of claim 10, wherein said receiving a further request comprises receiving said further request from said identified second device upon reception by said identified second device of a notification transmitted by said first device, said notification signaling an update of said user interface.
12. The method of claim 11, wherein said notification is transmitted by a television operator headend.
13. The method of claims 11-12, wherein said notification signals an availability of a new service relevant to said second device.
14. The method of claim 13, said method further comprising:
identifying API implementations from said plurality of API implementations to provide to said identified second device, wherein one or more features is enabled by said identified API implementations, and wherein said one or more features enable said new service to be accessed and used at said identified second device; and
transmitting said identified API implementations along with said updated EPG from said first device to said identified second device.
15. The method of claims 11-12, wherein said notification signals an availability of a new layout for said user interface.
16. The method of claim 15, said method further comprising:
identifying said new layout relevant to said updated user interface, said new layout being in a format suitable for display at said identified second device; and
transmitting said identified layout relevant to said updated user interface to said identified second device.
17. The method of claims 11-12, wherein said notification signals an availability of new contents for said user interface.
18. The method of claim 17, said method further comprising:
identifying said new contents relevant to said updated user interface, said new contents being in a format suitable for display and use at said identified second device; and
transmitting said identified new contents relevant to said updated user interface to said identified second device.
19. The method of claim 11, wherein said receiving a further request comprises receiving a further request from a second device upon reception by said second device of a notification transmitted by one service from said one or more services available at said identified second device.
20. The method of claim 10, wherein said receiving a further request comprises receiving a further request from a second device upon reception by said second device of a user input requesting said electronic program guide to switch from one visual element to another visual element.
21. The method of any preceding claim, wherein said set of parameters characterizing said second device comprises one or more of:
an identifier of said second device;
information on data supported by said second device;
types of input devices associated to said second device; and
types of connections supported by said second device.
22. The method of any preceding claim, wherein said second device is a client device.
23. The method of claim 21, wherein said first device is a server.
24. The method of any claim 21, wherein said first device is another client device.
25. A server comprising:
a storage module operable to store a plurality of API implementations enabling a plurality of features such that, each of said plurality of features is enabled by at least one of said plurality of API implementations, said plurality of features enabling a plurality of services such that, each of said plurality of features at least partially enables at least one service of said plurality of services; a front end module operable to receive a request for transmitting a user interface to a second device, said user interface enabling a user of said second device to access and make use of one or more services from said plurality of services, wherein said request further comprises a set of parameters characterizing said second device;
a control manager operable to identify said second device using said set of parameters;
a processor module to identify API implementations from said plurality of API implementations to provide to said identified second device, wherein one or more features from said plurality of features is enabled by said identified API implementations, and wherein said one or more features enable said one or more services to be accessed and used at said identified second device; and
wherein, said front end module is further operable to transmit said identified API implementations along with said user interface from said first device to said identified second device.
26. A server comprising:
means for storing a plurality of API implementations enabling a plurality of features such that, each of said plurality of features is enabled by at least one of said plurality of API implementations, said plurality of features enabling a plurality of services such that, each of said plurality of features at least partially enables at least one service of said plurality of services;
means for receiving a request for transmitting a user interface to a second device, said user interface enabling a user of said second device to access and make use of one or more services from said plurality of services, wherein said request further comprises a set of parameters characterizing said second device;
means for identifying said second device using said set of parameters;
means for identifying API implementations from said plurality of API implementations to provide to said identified second device, wherein said one or more features from said plurality of features is enabled by said identified API implementations, and wherein said one or more features enable said one or more services to be accessed and used at said identified second device; and means for transmitting said identified API implementations along with said user interface from said first device to said identified second device.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP12788644.8A EP2759146A1 (en) | 2011-10-12 | 2012-10-12 | Remote user interface |
US14/350,657 US20140298361A1 (en) | 2011-10-12 | 2012-10-12 | Remote User Interface |
CN201280061112.7A CN103999475A (en) | 2011-10-12 | 2012-10-12 | Remote user interface |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201161627508P | 2011-10-12 | 2011-10-12 | |
US61/627,508 | 2011-10-12 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2013054305A1 true WO2013054305A1 (en) | 2013-04-18 |
Family
ID=47216376
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2012/055553 WO2013054305A1 (en) | 2011-10-12 | 2012-10-12 | Remote user interface |
Country Status (4)
Country | Link |
---|---|
US (1) | US20140298361A1 (en) |
EP (1) | EP2759146A1 (en) |
CN (1) | CN103999475A (en) |
WO (1) | WO2013054305A1 (en) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2014055517A2 (en) | 2012-10-03 | 2014-04-10 | Sony Corporation | Home network controller with remote user interface wrapper of discovered multimedia content |
EP2822289A1 (en) * | 2013-07-05 | 2015-01-07 | Samsung Electronics Co., Ltd | Rui system, rui server, rui terminal apparatus, and method of providing rui service |
CN104869431A (en) * | 2015-05-18 | 2015-08-26 | 无锡天脉聚源传媒科技有限公司 | Video processing method and apparatus |
EP3148208A4 (en) * | 2014-05-22 | 2017-07-05 | ZTE Corporation | Video access method and system, set top box, proxy server and media server |
WO2020132641A1 (en) * | 2018-12-21 | 2020-06-25 | Home Box Office, Inc. | Collection of timepoints and mapping preloaded graphs |
US11269768B2 (en) | 2018-12-21 | 2022-03-08 | Home Box Office, Inc. | Garbage collection of preloaded time-based graph data |
US11474974B2 (en) | 2018-12-21 | 2022-10-18 | Home Box Office, Inc. | Coordinator for preloading time-based content selection graphs |
US11474943B2 (en) | 2018-12-21 | 2022-10-18 | Home Box Office, Inc. | Preloaded content selection graph for rapid retrieval |
US11475092B2 (en) | 2018-12-21 | 2022-10-18 | Home Box Office, Inc. | Preloaded content selection graph validation |
US11829294B2 (en) | 2018-12-21 | 2023-11-28 | Home Box Office, Inc. | Preloaded content selection graph generation |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10521250B2 (en) * | 2012-09-12 | 2019-12-31 | The Directv Group, Inc. | Method and system for communicating between a host device and user device through an intermediate device using a composite video signal |
CN104837067A (en) * | 2015-03-26 | 2015-08-12 | 腾讯科技(北京)有限公司 | Interface display method and interface display device |
US9591350B2 (en) * | 2015-04-10 | 2017-03-07 | Sony Corporation | Sharing web application program guide content items over home networks |
US10642455B2 (en) * | 2015-12-28 | 2020-05-05 | Ssh Communications Security Oyj | User interfaces in a computer system |
KR102522424B1 (en) * | 2016-08-19 | 2023-04-17 | 삼성전자주식회사 | Method and apparatus for displaying in electronic device |
US10958963B2 (en) * | 2016-11-22 | 2021-03-23 | Caavo Inc | Automatic screen navigation for media device configuration and control |
US10089219B1 (en) * | 2017-01-20 | 2018-10-02 | Intuit Inc. | Mock server for testing |
US11429400B2 (en) | 2017-10-20 | 2022-08-30 | Red Hat, Inc. | User interface metadata from an application program interface |
CN112218125B (en) * | 2019-07-12 | 2022-11-15 | 北京邦天信息技术有限公司 | Playing terminal and playing method |
CN118152680A (en) * | 2020-10-27 | 2024-06-07 | 支付宝(杭州)信息技术有限公司 | Applet sub-service identification method, device, equipment and storage medium |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060020950A1 (en) * | 2004-06-30 | 2006-01-26 | Patrick Ladd | Apparatus and methods for implementation of network software interfaces |
WO2008082064A1 (en) * | 2007-01-04 | 2008-07-10 | Samsung Electronics Co., Ltd. | Method and apparatus for content service |
US20100262961A1 (en) * | 2007-10-30 | 2010-10-14 | Lg Electronics Inc. | Method and system for downloading software |
US20110283232A1 (en) | 2010-05-14 | 2011-11-17 | Rovi Technologies Corporation | User interface for public and personal content browsing and selection in a content system |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8087047B2 (en) * | 2007-04-20 | 2011-12-27 | United Video Properties, Inc. | Systems and methods for providing remote access to interactive media guidance applications |
JP2011504258A (en) * | 2007-10-30 | 2011-02-03 | エルジー エレクトロニクス インコーポレイティド | Software download method and system |
US8005950B1 (en) * | 2008-12-09 | 2011-08-23 | Google Inc. | Application server scalability through runtime restrictions enforcement in a distributed application execution system |
-
2012
- 2012-10-12 WO PCT/IB2012/055553 patent/WO2013054305A1/en active Application Filing
- 2012-10-12 US US14/350,657 patent/US20140298361A1/en not_active Abandoned
- 2012-10-12 EP EP12788644.8A patent/EP2759146A1/en not_active Withdrawn
- 2012-10-12 CN CN201280061112.7A patent/CN103999475A/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060020950A1 (en) * | 2004-06-30 | 2006-01-26 | Patrick Ladd | Apparatus and methods for implementation of network software interfaces |
WO2008082064A1 (en) * | 2007-01-04 | 2008-07-10 | Samsung Electronics Co., Ltd. | Method and apparatus for content service |
US20100262961A1 (en) * | 2007-10-30 | 2010-10-14 | Lg Electronics Inc. | Method and system for downloading software |
US20110283232A1 (en) | 2010-05-14 | 2011-11-17 | Rovi Technologies Corporation | User interface for public and personal content browsing and selection in a content system |
Non-Patent Citations (2)
Title |
---|
BART CALDER ET AL: "Java TV API Technical Overview", INTERNET CITATION, 14 November 2000 (2000-11-14), XP002255146, Retrieved from the Internet <URL:http://www.oracle.com/technetwork/java/javame/jtv-1-0-spec-overview-150049.pdf> [retrieved on 20030919] * |
JUHA LEPPILAHTI: "Remote UI protocols for home environment", TKK T-110.5190 SEMINAR ON INTERNETWORKING, 3 May 2007 (2007-05-03), Helsinki, XP055049595, Retrieved from the Internet <URL:http://www.tml.tkk.fi/Publications/C/23/papers/Leppilahti_final.pdf> [retrieved on 20130115] * |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2014055517A2 (en) | 2012-10-03 | 2014-04-10 | Sony Corporation | Home network controller with remote user interface wrapper of discovered multimedia content |
EP2891035A4 (en) * | 2012-10-03 | 2016-04-20 | Sony Corp | Home network controller with remote user interface wrapper of discovered multimedia content |
EP2822289A1 (en) * | 2013-07-05 | 2015-01-07 | Samsung Electronics Co., Ltd | Rui system, rui server, rui terminal apparatus, and method of providing rui service |
EP3148208A4 (en) * | 2014-05-22 | 2017-07-05 | ZTE Corporation | Video access method and system, set top box, proxy server and media server |
CN104869431A (en) * | 2015-05-18 | 2015-08-26 | 无锡天脉聚源传媒科技有限公司 | Video processing method and apparatus |
US11204924B2 (en) | 2018-12-21 | 2021-12-21 | Home Box Office, Inc. | Collection of timepoints and mapping preloaded graphs |
WO2020132641A1 (en) * | 2018-12-21 | 2020-06-25 | Home Box Office, Inc. | Collection of timepoints and mapping preloaded graphs |
US11269768B2 (en) | 2018-12-21 | 2022-03-08 | Home Box Office, Inc. | Garbage collection of preloaded time-based graph data |
US11474974B2 (en) | 2018-12-21 | 2022-10-18 | Home Box Office, Inc. | Coordinator for preloading time-based content selection graphs |
US11474943B2 (en) | 2018-12-21 | 2022-10-18 | Home Box Office, Inc. | Preloaded content selection graph for rapid retrieval |
US11475092B2 (en) | 2018-12-21 | 2022-10-18 | Home Box Office, Inc. | Preloaded content selection graph validation |
US11720488B2 (en) | 2018-12-21 | 2023-08-08 | Home Box Office, Inc. | Garbage collection of preloaded time-based graph data |
US11748355B2 (en) | 2018-12-21 | 2023-09-05 | Home Box Office, Inc. | Collection of timepoints and mapping preloaded graphs |
US11829294B2 (en) | 2018-12-21 | 2023-11-28 | Home Box Office, Inc. | Preloaded content selection graph generation |
US11907165B2 (en) | 2018-12-21 | 2024-02-20 | Home Box Office, Inc. | Coordinator for preloading time-based content selection graphs |
Also Published As
Publication number | Publication date |
---|---|
US20140298361A1 (en) | 2014-10-02 |
CN103999475A (en) | 2014-08-20 |
EP2759146A1 (en) | 2014-07-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20140298361A1 (en) | Remote User Interface | |
US12034993B2 (en) | Method and apparatus for executing application in wireless communication system | |
US10225370B2 (en) | Systems and methods for compiling and organizing multiple episodes of media content series | |
US7664813B2 (en) | Dynamic data presentation | |
US9883251B2 (en) | Method and apparatus for managing connection between broadcast receiving device and another device connected by network | |
US8418207B2 (en) | Dynamic video source selection for providing the best quality programming | |
EP2447833A1 (en) | Display apparatus and method for controlling the display apparatus | |
US9021365B2 (en) | Apparatus and method for distributing media content | |
US20060085824A1 (en) | Method and appartus for management of video on demand client device | |
US20140082682A1 (en) | Smart set-top box and operating method for providing smart service and digital television service using default media player included in single operating system | |
WO2021174663A1 (en) | Watching history display method and display device | |
US10554745B2 (en) | Method and apparatus for managing connection between broadcasting reception device and another device which are connected through network | |
JP2014529382A (en) | Smart set-top box providing smart service and digital TV service on a single operating system and driving method thereof | |
US20110066679A1 (en) | Method and system for distributing content | |
JP5669277B2 (en) | Method and apparatus for providing supplemental information | |
US10063923B2 (en) | Digital device and control method thereof | |
Zorrilla et al. | A Web-based distributed architecture for multi-device adaptation in media applications | |
US9800901B2 (en) | Apparatus, systems and methods for remote storage of media content events | |
KR20140123523A (en) | System for synchronizing content transmitted to a digital tv receiver with multiple portable devices with or without internet access | |
CN112004125A (en) | Media resource playing method and display equipment | |
KR101909257B1 (en) | Server and method for executing virtual application requested from device, and the device | |
WO2014154868A1 (en) | Operation of a content receiver | |
US12045631B2 (en) | Page loading method and display apparatus | |
US20240137596A1 (en) | Methods for multimedia data delivery and apparatuses for implementing the same | |
WO2012169833A2 (en) | Method for providing semantic application |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 12788644 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 14350657 Country of ref document: US |
|
REEP | Request for entry into the european phase |
Ref document number: 2012788644 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2012788644 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |