Patent Application
20060155850
The present invention generally relates to electronic programming guides, and relates in particular to a networked mobile EPG service.
Among home entertainment services, EPG (Electronic Programming Guide) is perhaps the most appealing applications for television, and its services continue to grow in the emergence of new digital TV market. Traditionally, for both analog and digital interactive TV, EPG applications are running on the set-top box and its services are provided by the MSO (e.g., cable provider) for a fee. Additional features associated with EPG application on a STB are content filtering and program recommendation, among others.
As the convergence of mobile and home devices evolves in the new digital networking era, there is a need for mobile devices to receive the similar services as offered on a home networked device. Consequently, EPG on mobile draws much attention. Naturally, this service is offered by the cell phone providers or Internet portal provider (WAP), both for a fee. Such services require frequent update of EPG content.
Available EPG services for STB and mobile both require customer to pay a subscription fee. Further, they use proprietary technologies. As a result, users must pay for provision of both services if they want the EPG to be provided in their homes and also on their mobile devices. Accordingly, there is a need for realizing an EPG service on a home network that is exportable to mobile devices.
In accordance with the present invention, a networked mobile EPG system includes an EPG application running on a user device to query and retrieve EPG contents from a home network. A home network gateway uses SIP messaging to allow communication of commands and data on the user device to and from a home networked device through bridging between SIP and a non-SIP protocol of the home network. An EPG service on the home network sends EPG metadata when a query is made from the user device.
Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.
The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein:
a and 4b are views of EPG user interface components for browsing at various levels of detail in accordance with the present invention;
The following description of the preferred embodiments is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.
The mobile EPG system according to the present invention has a system architecture based on SIP (Session Initiation Protocol) and a home network protocol (e.g., OSGi (Open Service Gateway Initiative)) to realize an EPG service on a home network and export such service to a remote mobile device via SIP. The use of SIP simplifies the communication protocol (in comparison to, for example, http) for a mobile device to receive data, and the use of an OSGi gateway or equivalent allows multiple vendors to develop EPG service applications for the home.
The mobile EPG system according to the present invention can have applications and features that operate according to one or more of the following assumptions: (1) an EPG database is downloaded to home network device (e.g. home server) in some way, for example, through STB broadcast, Internet etc.; (2) an EPG service is running on a home server to analyze EPG contents in the EPG database and provide filtering and recommendation services; and (3) the EPG service can be accessed and configured from a mobile device in a remote location.
In accordance with some embodiments of the system architecture, the system can be comprised of mainly two parts: mobile device and home network. The architecture of the system can be based on SIP-OSGi bridging. Referring to
The mobile applications can realize one or more of the scenarios described previously. The application can communicate with the home entertainment network and be able to download information from entertainment devices, utilize related services (e.g. EPG service), and control these devices. The SIP stack enables the mobile device with SIP. Depending on SIP implementation, a JVM may or may not be required.
SIP was originally designed as the protocol for multimedia session creation and termination with its intended use in Voice over IP. To use SIP in home networking applications, a middleware is needed to convert SIP signaling protocols to home networking specific functions. In some embodiments, the middleware can be an internal library that receives messages from mobile applications in relation to home entertainment, and convert them to SIP commands. It can also receive SIP messages and events and send relevant messages to applications.
The purpose of building SIP middleware is two fold. One is to simplify SIP signaling protocols for applications and this middleware is to be able to re-use for future applications. The second purpose is to make the mobile application independent of SIP, therefore providing flexibility to use other than SIP protocols in the future, if needed. For example, if the mobile device is equipped with an OSGi framework for mobile environments in the future, SIP middleware needs to be replaced, but mobile applications do not need to be rewritten.
SIP Server 134 is an intermediary device that is located within the SIP-enabled network 136 and assists user agents in session establishment and other functions. It is a general term for SIP Proxy, redirect server, or registrar server.
OSGi Gateway 114 provides a basic framework for networked devices 124-132 to be able to communicate and control each other. OSGi supports a variety of networks such as UPnP, Jini, Http etc.
The SIP-OSGi bridging 116 is an adaptor to allow devices and services (applications) on the OSGi gateway to possess SIP capability that allows them to be able to communicate with other SIP devices in a remote location via SIP server/proxy. EPG-SIP bridging 118 can interface an EPG service bundle 120 and other bundles 122 with SIP-OSGI bridging. SIP-OSGi bridging can be constructed in two ways.
A first way in which SIP-OSGI bridging can be constructed is referred to herein as SIP Stack Bundle on OSGi. Turning now to
A second way in which SIP-OSGI bridging can be constructed is referred to herein as SIP Service for OSGi. As illustrated in
The SIP-OSGi bridging allows sharing and control of these devices from outside the home via SIP service. Services can also be installed and executed on the framework. For example, EPG service can be installed on the OSGi framework and utilized by devices or other bundle services on the network.
EPG service provides information to requested devices about TV programming. It can also be configured to only provide EPG in selected categories, or adaptively filter, prioritize and recommend EPG based upon user's preference. The source of EPG can be diverse: local media, Internet, or digital TV broadcast (via STB). The policy of EPG recommendation can be implemented differently without changing the EPG Service bundle API.
The SIP Bridging for EPG service is provided within the gateway SIP middleware to allow other SIP devices to access such service through SIP-OSGi bridging. It converts EPG requests/events to SIP methods and events, which is necessary for SIP devices to access the functions of EPG service bundle.
SIP Device bridging provides capabilities for EPG service to be able to control other OSGi or non-OSGi devices. For example, a SIP-UPnP bridging may convert SIP commands/messages/events to those of UPnP and therefore allows EPG service to control an UPnP device on OSGi framework.
The mobile EPG application remotely accesses and controls home network devices. In some embodiments, an EPG service is installed on the home network to provide EPG services. The service can function as follows: (1) the mobile device registers with home network and request selected EPG information; (2) the user is able to browse EPG information in different levels of detail as shown in
As previously stated, SIP middleware is needed in order to convert SIP signaling protocols to home network flavor functions, and vice versa. Particularly, for home networking applications, several basic functions are needed: (1) register a mobile device with home network; (2) list the devices, services and events available on the home network; (3) subscribe to events on the home network, such as system events (e.g., new devices are added to the home network) and special events that are provided by devices or services on the network (e.g., reminder of a TV show); (4) send control commands to a device on the home network, such as “record” on a PVR; (5) request and receive data from home network devices or services (e.g., EPG data from home media server or EPG service, shopping list data from networked refrigerator, etc.); (6) start and terminate audio/video streaming session with an A/V device on the home network, such as connect to a SIP phone at home, or view video stream that is being captured from a security camera.
The SIP protocol provides capability of device/service discovery, control, registration and events through methods like REGISTER, MESSAGE, and SUBSCRIBE.
Both data and media stream need to be “carried” via SIP service. The challenge is that SIP can only carry a small message body, not suitable for a large chunk of data or streams of video. Therefore, the transport of data can be implemented in the following ways: (1) short messages such as request and control commands can be carried in SIP MESSAGE body as plain text, and these messages can be transparent to proxies and need to be interpreted at the SIP end point; (2) additional information such as a chunk of data can be added and carried in a separate message body attachment as a payload, and it can be either text based or MIME type; (3) RTP can be used for media transport, with the multimedia streaming session being negotiated by applications in SDP (session description protocol), which is a simple text based protocol that is supported by SIP and completely transparent to SIP.
Home EPG application service bundles are collections of application specific services that are packaged into OSGi bundles to be executed within the OSGi framework from any requested devices/services. The EPG service provides EPG contents to requested device. The EPG contents include different levels of detail (e.g., program title, synopsis, detailed program information, photo, preview video clip, etc.) for optimizing on the application device display.
Referring to
Again, a SIP bridging is needed in order for EPG service to be accessed by mobile device via SIP service. The SIP bridging for EPG service can function as follows: (1) register with OSGi SIP Service and act itself as an EPG SIP UA; (2) pass SIP commands to/from EPG service bundle; and (3) pass data to/from EPG service bundle through SIP messages or MIME type payloads.
Mobile applications run on the mobile device and directly interact with end users via GUI. The applications take user's input from applications and translate to mobile-home middleware “protocols”. Applications also receive the results from middleware and display to the user via GUI. The following describes an example of translation between GUI functions and mobile-home middleware modules.
Turning now to
EPG data can be filtered depending on personal preferences. These preferences can be defined manually by the application (“Config” button) or collected automatically on the device by monitoring user's interaction with EPG data. These preferences can be locally stored on the Profile Manager 722 and be utilized by Control module when it packs an EPG request into a SIP message body.
Turning now to
REGISTER sip:sipserver.myhome.com SIP/2.0
Via SIP/2.0/UDP 4.3.2.1:5060
To: Matthew Ma <sip:mma@mymobile.com>
From: Matthew Ma <sip:mma@mymobile.com>
Contact: <sip:mma@4.3.2.1>; class=personal
. . .
Upon receipt from SIP server:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 4.3.2.1:5060
To: Matthew Ma <sip:mma@mymobile.com>
From: Matthew Ma <sip:mma@mymobile.com>
Contact: <sip:mma@4.3.2.1>; class=personal; expires=3600
Notice that the 200 OK response to a REGISTER echoes the contact URL that have been successfully registered.
In another additional or alternative embodiment, mobile-home SIP middleware sends an instant messaging message to the Home EPG SIP UA 804 via SIP server 802 requesting EPG as at 810 and 812. Consider the following example message:
MESSAGE im:epg@myhome.com SIP/2.0
Via: SIP/2.0 UDP 4.3.2.1
To: Home EPG <im:epg@myhome.com>
From: Matthew Ma <im:mma@mymobile.com>
Cseq: 1 MESSAGE
<EPG REQUEST XML BODY>
In still another additional or alternative embodiment, Home EPG SIP UA 804 delivers requested EPG through SIP message body as at 814. A sample messages looks like:
MESSAGE im:mma@mymobile.com SIP/2.0
Via: SIP/2.0/UDP 198.162.1.100:5060
To: Matthew Ma <im:mma@mymobile.com>
From: Home EPG <im:epg@myhome.com>
Cseq: 1 MESSAGE
<EPG data XML body>
In yet another additional or alternative embodiment, Mobile-Home SIP middleware 800 acts upon EPG and decides to record a show of interest. A “record” command is sent as at 816 via IM message like:
MESSAGE im:epg@myhome.com SIP/2.0
Via: SIP/2.0/UDP 4.3.2.1:5060
To: Home EPG <im:epg@myhome.com>
From: Matthew Ma <im:mma@mymobile.com>
Contact: <sip:mma@4.3.2.1>
Cseq: 1 MESSAGE
<Device control record XML body>
Some example Java Objects for Mobile Home SIP Middleware in
Turning now to
The control module 908 of EPG handles all EPG requests and returning of requested EPG data. In most cases, transmitting the entire EPG contents for all TV stations may not be feasible due to limited capabilities (storage, memory, network latency etc) such as a mobile device. Therefore, a filtering and recommendation engine 912 is needed to send selected EPG data. A user can include keywords/qualifiers in their EPG request to specify what kind of contents to request.
Optionally, a user profile 910 can be used to filter or recommend the most appropriate EPG data according to the user's behavior. A user who requests EPG data can also send an updated user profile to override an existing profile, or update only certain fields from an existing user profile. Upon receiving and browsing EPG data, a user can select certain programs to watch or record, and this data can be sent to EPG bundle to heuristically filter and recommend for future request. This feedback process is also called accumulative learning.
EPG SIP bridging middleware 904 acts as an activator of EPG bundle for SIP. This SIP bridging itself can be an OSGi bundle. Upon start, SIP bridging registers to the SIP service (proxy) on OSGi gateway and become a SIP UA. By way of SIP service registration, it is automatically registered to the OSGi framework, which allows it to gain access to other OSGi bundles including EPG Bundle. Since it becomes a SIP UA, it is accessible by other SIP UAs including mobile device on the SIP network. Subsequent SIP communication between mobile device and EPG SIP bridging middleware can be used to send/receive data and commands from mobile device to EPG service. SIP commands from a mobile device are translated so appropriate EPG bundle control functions can be called. Similarly, any status/data from EPG bundle control module are packed into appropriate SIP messages and send to the mobile device
EPG and Device SIP bridging middleware 904 also provides functions for user to control home entertainment devices 918 through SIP protocol. These entertainment devices are on the home network and supported by OSGi framework such as UPnP, Jini. For devices 916 that are not supported by OSGi framework such as 1394, a 1394 control bundle is needed in order to control such a device from OSGi.
Some example Java Objects for EPG Service and SIP Bridging are illustrated below in pseudocode.
The description of the invention is merely exemplary in nature and, thus, variations that do not depart from the gist of the invention are intended to be within the scope of the invention. Such variations are not to be regarded as a departure from the spirit and scope of the invention.
This application is a continuation-in-part of U.S. patent application Ser. No. 10/894,469 filed on Jul. 19, 2004, which claims the benefit of U.S. Provisional Application No. 60/524,599, filed on Nov. 25, 2003. The disclosures of the above applications are incorporated herein by reference in their entirety for any purpose.
| Number | Date | Country | |
|---|---|---|---|
| 60524599 | Nov 2003 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10894469 | Jul 2004 | US |
| Child | 11285622 | Nov 2005 | US |
