WO2006017218A2

WO2006017218A2 - Tuner service and dtv receiver as a upnp device

Info

Publication number: WO2006017218A2
Application number: PCT/US2005/024521
Authority: WO
Inventors: Rajesh B. Khandelwal; Arlis Boyd Dodson; Luyang Li
Original assignee: Matsushita Electric Industrial Co. Ltd.
Priority date: 2004-07-13
Filing date: 2005-07-13
Publication date: 2006-02-16
Also published as: WO2006017330A3; WO2006017330A2; WO2006017218A3

Abstract

A network architecture includes a home network, a broadcast network, a DTV receiver connected to the home network and the broadcast network, and a DTV-related service implemented on the home network and operable to expose functionalities of the DTV receiver to the network. In other aspects, a tuner service exposes characteristics and capabilities of tuners to other devices on a network, and controls operation of the tuners in accordance with control commands received from control points. In yet other aspects, a resource manager service is adapted to manage allocation of resources on the DTV device and keep track of resource allocation status. In still other aspects, a time and stream event service maintains a common time for the network and delivers triggers to the network from a cache of triggers received from a broadcast carousel.

Description

TUNERSERVICEAND DTVRECEIVERASAUPnP DEVICE

CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims the benefit of U.S. Provisional Application No. 60/587,576, filed on July 13, 2004. This application also claims the benefit of U.S. Provisional Application No. 60/607,571 , filed on September 7, 2004. The disclosures of the above applications are incorporated herein by reference in their entirety for any purpose.

FIELD OF THE INVENTION

[0002] The present invention generally relates to a DTV receiver as a UPnP device, where the basic functionalities of the DTV receiver are exposed as UPnP services, such as a tuner service, a resource manager service, and/or time and stream event service, etc.

BACKGROUND OF THE INVENTION

[0003] Today's DTV receiver cannot function as a UPnP device that exposes its functions relating to DTV services. DTV services are composed of audio media and video media synchronized with one another and with a software application that is bundled with the audio and video media. The application bundled with the media is termed a service bound application. Service bound applications are signaled via an Application Information Table (AlT) in the in- band Transport Stream (TS). In contrast, an unbound application is not bound to any audio or video media. These unbound applications are signaled via extended AIT (XAIT) in one of the following ways: a complete XAIT is delivered via a CableCARD extended data channel; and an XAIT fragment is passed as a parameter to a DTV Application Program Interface (API method).

[0004] Currently there are two sources of unbound applications, a cable operator and a manufacturer. Cable operator signals unbound applications via a XAIT. A receiver can persist these unbound applications in its persistent storage. A manufacturer of the DTV receiver can also provide resident unbound applications. These applications get registered in the applications database at the boot time of the device. Accordingly, the applications database is updated at boot-time for locally-stored services. However, there is currently no mechanism to share these locally stored services with other devices on the home network. Moreover, past and current Open CableTM Application Platform (OCAP) specifications do not permit an unbound application to be signaled and delivered by any technique other then the ones described above.

SUMMARY OF THE INVENTION [0005] In accordance with the present invention, the architecture includes a broadcast network, such as Cable, Terrestrial, or Satellite, a home network, a DTV receiver connected to both the broadcast network and the home network, and a set of DTV-related UPnP services implemented on the DTV receiver to expose its functionalities to other devices on the home network. In other aspects, a tuner service exposes characteristics and capabilities of tuner(s) in the DTV receiver, and controls operation of the tuners in accordance with control commands received from control points. In yet other aspects, a resource manager service is adapted to manage allocation of resources on the DTV receiver and keep track of resource allocation status. In still other aspects, a time and stream event service maintains a common time for the network and delivers triggers to the network from a cache of triggers received from a broadcast carousel.

[0006] 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.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein:

[0008] Figure 1 is a block diagram illustrating a DTV receiver as a UPnP device in accordance with the present invention; [0009] Figure 2 is a block diagram illustrating an OCAP home networking device in accordance with the present invention;

[0010] Figure 3 is a network diagram illustrating a DTV receiver integrated with other UPnP devices and control points in accordance with the present invention;

[0011] Figure 4 is a network diagram illustrating a legacy receiver implemented as a UPnP device in accordance with the present invention;

[0012] Figure 5 is a block diagram illustrating DTV actions and events performed and generated by a DTV device in accordance with the present invention;

[0013] Figure 6 is a network diagram for a method of signaling OCAP services stored on removable storage media in accordance with the present invention;

[0014] Figure 7 is a network diagram illustrating SI data translation in accordance with the present invention;

[0015] Figure 8 is a block diagram illustrating mapping of XAIT to secondary storage services and applications in accordance with the present invention;

[0016] Figure 9 is a block diagram illustrating the prior art XAIT update mechanism;

[0017] Figure 10 is a block diagram illustrating XAIT update in accordance with the present invention;

[0018] Figure 11 is a block diagram illustrating common-media XAIT update event/XAIT delivery in accordance with the present invention; [0019] Figure 12 is a block diagram illustrating dual-media update event/XAIT delivery in accordance with the present invention;

[0020] Figure 13 is a block diagram illustrating an EPG user interface with merged broadcast/secondary SI in accordance with the present invention;

[0021] Figure 14 is a block diagram illustrating recording of broadcast service applications in accordance with the present invention; [0022] Figure 15 is a block diagram illustrating a DTV-HNF distributed resource manager working in tandem with an OCAP resource manager to keep track of resource allocation status in accordance with the present invention;

[0023] Figure 16 is a block diagram illustrating a local reservation process in accordance with the present invention;

[0024] Figure 17 is a block diagram illustrating a remote reservation process in accordance with the present invention;

[0025] Figure 18 is a network diagram illustrating triggers from a broadcast carousel being cached in a datastore for later dispatch by the receiver via broadcast on a home network to appliances in accordance with the present invention;

[0026] Figure 19 is a block diagram illustrating a DTV receiver including a trigger service that operates according to a time service in accordance with the present invention; [0027] Figure 20 is a block diagram illustrating a content listing service interfacing with an OCAP SI manager and an OCAP recording manger in accordance with the present invention; and

[0028] Figure 21 is a block diagram of the content listing service architecture, including the content listing service employing uniform locators mapped to multiple content sources in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0029] 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.

[0030] Some embodiments of the present invention are or include a DTV receiver implemented as a UPnP device to allow organized selection and delivery of available media content streams to devices connected to the network on which the DTV receiver resides. Referring to Figure 1 , the DTV receiver 100 as a UPnP device can include several services. For example, the receiver 100 can include an EPG content listing service 102, a content display service 104, and a tuner service 106. It can also include a time and stream event service 108, a resource manager service 110, a content recording or duplication service 112, a Diagnostic service 114, and a DRM service 116. Additionally, it can include a playback control service 118 including an AVT service 120, and a content delivery service 122 including a CM service 124. [0031] Turning now to Figure 2, an OCAP home networking device

200, such as the DTV receiver, can have a network manager 202 providing registration, discovery, and eventing mechanisms for services described above. These services can include a tuner service 204 as described above, a content delivery service 206, a content display service 208, a playback control service 210, a content rec./dup. service 212, a content management service 214, a DRM service 216, a diagnostic service 218, a resource manager 220, and other services. Technology glue 222, such as UPnP, OSGi, etc.), serves to support the underlying functionality.

[0032] Turning now to Figure 3, the DTV receiver 300 can be integrated with other UPnP devices 302A-302C and control points 304 by functioning as both a service and a control point. Services reside on the DTV receiver. The receiver 300 automatically announces its presence, description, allows control, and generates events. It also exports its functionalities by way of various services, such as the tuner service, hard disk service, and EPG service. It further controls other UPnP services, and allows dynamic plug-in and plug-out.

[0033] Turning now to Figure 4, a legacy receiver 400 can also be implemented as a UPnP device according to some embodiments of the present invention. The legacy receiver can be operably connected to a PC via an appropriate interface such as Ethernet or USB interface of the legacy DTV receiver. Service can be deployed and therefore reside on the PC as proxy services. Again, the legacy receiver is adapted by configuration with the proxy services to automatically announce its presence, description, allow control, and generate events. Embodiments of the invention can export services from the legacy system for smooth integration, control other UPnP devices, and allow dynamic plug-in and plug-out.

[0034] Turning now to Figure 5, shows actions, events and state variables. These are generalized and are applicable to all the services mentioned above. Each service mentioned above implements actions and generates events based on its functionality in accordance with UPnP architecture. Each service 502A and 502B on a device 500 also maintains state variables 504A and 504B. An action 506 can be performed on a service, potentially modifying one or more of its state variables. Action examples include: tune an RF receiver; render an MPEG-2 video elementary stream; launch a VOD session, get service information tables, reserve a resource such as a tuner, etc.. An event listener 508 is notified of events 510 for which the listener has registered, with events being generated by services, for example, in response to change in their state variables. Event examples include: RF tuning complete; MPEG-2 video elementary stream playout status change; VOD session status change; new DTV service announcement; DTV service status change; new DTV device announcement; DVT device status change; and DTV resources busy or free. The examples of actions, events, and state variables mentioned above are merely exemplary in nature and each service mentioned above can implement more or different actions, events, and state variables based on its functionality.

[0035] In some aspects, the present invention is directed toward signaling and sharing (launching) DTV applications/services to other DTV devices [and PCs] in a home network. Signaling implies notifying the receiver that a DTV service is available on a particular channel (or transport stream). Launching implies the mechanism by which the application/video/audio/data is transmitted to the receiver so that the receiver can launch or execute the service. As mentioned above, a DTV service is a combination of audio/video/application/data that can be presented as a whole to the user. [0036] In-band - (broadcast - one way) - carries signaling, application, AA/, data (bound services) from the head-end to the receiver. This signaling is performed via the AIT. The AIT carries enough information so the receiver knows where to find the application/AA/ in the transport stream and how to launch it. [0037] Out-of-band (OOB) - (used for two-way communication with the head-end) - is used for signaling unbound services. As mentioned above, unbound applications are applications that are not related to any broadcast service (e.g., EPG or game application). Unbound applications are signaled via an XAIT delivered via OOB channel to the receiver. The signaling of the unbound application is performed via OOB channel, but the actual delivery could be performed either via OOB or in-band. [0038] Today, unbound applications originate either from the head-end or installed by the manufacturer at the time of manufacturer. Some embodiments of the present invention prepare for the possibility that applications or DTV services can also become available from other means such as DVD, SD memory card, home network, and other data storage sources. Currently there exists no mechanism to signal the existence or availability of such services to other devices in the home network.

[0039] According to some embodiments, the present invention includes a tuner service that exposes functionalities of a real tuner to other DTV devices [and PCs] on a home network. For example, close captions, vertical blanking interval (VBI) contents, emergency alert messages, channel maps, and/or system information tables can be exposed. The virtual tuner thus accomplished can use a real tuner as a source of media, the Internet or similar communications system as a source of media, or storage on the home network as a source of media. Thus, the virtual tuner exposes SI (metadata) about broadcast, stored, or other dynamically discovered content.

[0040] Dynamically discovered content is dynamically discovered when a datastore containing media is operably connected to the home network. For example, when a SD card with a DTV service is inserted in an SD interface of the DTV receiver, the virtual tuner service registers that service and makes it available to other devices in the network. As another example, content on a DVD disk can be dynamically discovered when the disk is inserted in a DVD drive connected to the home network.

[0041] In some embodiments, the virtual tuner can be logically identical to a real tuner (i.e. supports all the functions supported by a real tuner). It can enable a receiver with both a real tuner and a home networking interface to act as a head-end in the home by exposing tuner functionalities in the home network. Accordingly the virtual tuner service accomplishes notification of AITVXAIT, CAS, Emergency Alert, and other bound and unbound applications from storage. Additionally, the service accomplishes SI translation; for example, EPG data can be translated into a known XML format requested by a client. Further, the service discovery protocol to which the tuner service adheres can vary, and can include UPnP, OSGi, and other specified protocols.

[0042] The device I/F appearance can vary, and can be determined in part by a stylesheet on the DTV device or control point in question. However, some controls that can be provided include controls for switching channels on a real tuner or in recorded content. Thus, the user of the DTV as a control point can interface with the virtual tuner in order to select between real channels, and in order to switch between channels of recorded content. The implementation may also attach a time-shift buffer to enable live-TV transmission to other devices in the home network

[0043] In some embodiments, the virtual tuner service can maintain copy protection for content by observing copy protection data associated with the content and obeying it. For example, content on a disk may be labeled read only, and thus the service can prevent the user from selecting to record the content. Similarly, the service can observe copy protection data associated with a bound service arriving by broadcast and obey that data. As an example, the data can specify that the service can be recorded to one place on the network in an encrypted fashion, with the decryption key being hidden elsewhere on the network by the service. In this case, the user may be allowed to view the content on the home network a given number of times, but not to record or transfer the content. [0044] A virtual tuner provided by the tuner service can have various properties. For example, it can record the last time it was tuned. Also, it can attach a time shift buffer. Further, it can store user profiles. Additionally, it can achieve a required metadata format. Still further, it can accomplish encryption and decryption, and engage in or enable encryption/decryption key exchange. Finally, it can accomplish tuner reservation and notification of tuner availability.

[0045] The tuner service can employ various actions. For example, the service can have actions for tuning a real tuner. It can also have actions for acquiring and/or assigning a channel number. It can additionally have actions for acquiring or assigning a frequency. It can further have actions for reserving and releasing tuners. It can still further have actions for attaching time shift buffers. Yet further, it can have actions for getting channel maps. The tuner service may also implement and expose functionalities of a point-of-deployment module. Finally, it can have trick-play actions, including play, stop, forward and rewind.

[0046] The tuner service can have various state variables and events. For example, the service can have the following state variables: current set frequency; current set channel number; and reservation status. Additionally, the service can have the following events: tuner reserved; tuner released; AIT/XAIT; EAS; MMI/CAS; triggers such as stream events; system time table; start of advertisement; and end of advertisement.

[0047] Turning now to Figure 6, a network diagram for a method of signaling OCAP or DTV services stored on removable storage media is shown. It should be noted that the ideas presented in this invention can be implemented with or without DTV middleware running on these devices. The home network can include a cable network 600 connected to an OCAP server 602, which is also connected to OCAP clients 604A-604D. "Live" OCAP services are received from the cable network. An OCAP monitor application may bridge or control the sharing between the OCAP network with a UPnP AV network. The UPnP AV network can include a UPnP optical drive 606, a UPnP DVD drive 608, and a UPnP CD drive 610, each connected to the OCAP server 602 by Ethernet 612. These are UPnP OCAP services removable storage devices. Each of the OCAP clients 604A-604D can be configured with inexpensive, fixed-frequency RF tuners, as well as other network interfaces, such as 802.11 , 1394, and USB. OCAP server 602 can be configured with multiple RF tuners. SD cards and DVD drives can also be integrated with the OCAP server 602 and/or clients 604A- 604D. [0048] Turning now to Figure 7, SI data translation can occur according to an XML format requested by a client. DTV terminal 700 connects a home RF network having an OCAP DTV terminal 702A and MHP DTV terminal 702B to a home Ethernet network having an MPEG-2 player 704A, laptop computer 704B running a home networking application, and another DTV terminal 704C. The DTV terminal 700 also connects these networks with cable network 706 and XML SI database 708. Broadcast SI data are received from cable network 706, converted to XML, and merged with home network SI data on database 708. XML document type description (DTD) specifies format of merged broadcast/home network SI data. DTV terminal can thus deliver the contents of database 708 to the home RF network and Ethernet network. The home network devices provide home network SI data and, in turn, accept merged XML SI data. XML SI data are converted to an appropriate format before transmission to DTV terminals that cannot ingest XML SI data, such as OCAP or DVB-MHP. Similarly, XML SI data are converted to an appropriate format before transmission to home network devices that cannot ingest XML SI data, such as MPEG-2 tables. [0049] Merged SI can include location-resolution information; for example: IP address; TCP/IP or UDP port number; IEEE1394 identifier; and hardware interfaces. Such information is needed when multiple sources provide a common service (e.g., a given media file). This information can be co-located on the DTV terminal or anywhere on the home network [0050] Turning now to Figures 8-14, signaling the secondary storage

OCAP service is described in greater detail. The signaling occurs in a manner that ensures the service is handled by the OCAP terminal in the same fashion as a broadcast OCAP service.

[0051] As mentioned above, the signaling mechanisms in OCAP include the (DVB-MHP) Application Information Table (AIT) and the Extended AIT (XAIT). It is currently expected that the XAIT will be used to announce the presence of unbound applications delivered in the lnband broadcast stream or resident in the OCAP terminal, although it is possible that unbound applications could be delivered to the terminal via Out-of-Band (OOB). [0052] Some embodiments of the present invention broaden usage of the XAIT to include announcing the presence of OCAP services and OCAP applications (service-bound or unbound) resident in secondary storage. In particular, the XAIT can be used (though AITs could be used as well) to signal service-bound applications associated with secondary storage AA/ media assets.

[0053] As also mentioned above, the current OCAP specification provides two mechanisms for delivering XAIT updates: the OOB stream and an API available to privileged OCAP applications (so-called "Monitor Applications").

Some embodiments of the present invention employ a third, broad, mechanism for delivering XAIT updates: the OCAP implementation monitors every OCAP terminal interface (other than lnband and OOB) for XAIT Update Events. The format of these events can be determined in part by the nature of the interface (e.g., PCMCIA, IEEE1394, IP, 801.11x). Each XAIT Update Event can identify the media on which the XAIT is to be received and whether the XAIT must be "pulled" into the OCAP terminal or will be "pushed" at the OCAP terminal by an outside agent. Although the XAIT Update Event and the XAIT itself may arrive by the same medium, this is not necessarily the case. Where practical, an open specification like the Session Description Protocol (SDP) and/or the Session Initial Protocol (SIP) may be used to "signal" the secondary storage XAIT.

[0054] Interestingly, the current OCAP specification implies the XAIT is distinguished from the AIT by the delivery mechanism alone: a table arriving via lnband is assumed to be an AIT; a table arriving via OOB is assumed to be an XAIT. The two MPEG-2 table IDs are identical. Therefore, the following rule can be added to the OCAP specification: "an *AIT arriving by any mechanism other than lnband is assumed to be an XAIT".

[0055] Some changes or additions can be made to the OCAP specification that supports signaling according to the present invention. Some of these changes can be viewed as new rules. For example, one rule can be that any AIT or XAIT arriving by any mechanism other than lnband is assumed to be XAIT. Also, another rule can be that XAIT can be used to announce the presence of DTV services and applications (service-bound or unbound) resident in secondary storage. Additionally, a third rule can be that the XAIT format is extended to identify the origin of the XAIT. Another change or addition that can be made to the OCAP specification is definition of a new XAIT source that is consistent with the existing DTV model. [0056] Generation of XAIT-update events can occur in various ways and in response to varying stimuli. For example, one implementation of the present invention can continuously monitor all interfaces. When a connection on an interface is detected and presence of a DTV service is detected, an XAIT- update event can be generated. Another implementation can choose to scan the attached storage for XAITs without needing an XAIT-update event.

[0057] Each XAIT Update Event can identify the media on which the XAIT is to be received and whether the XAIT must be "pulled" into the DTV terminal or will be "pushed" at the DTV terminal by an outside agent. Although the XAIT Update Event and the XAIT itself may arrive by the same medium, this is not necessarily the case. Figure 8, showing mapping of XAIT to secondary storage services and applications, illustrates some possible cases. For example, in DVD-RAM 300A, XAIT service description 802 can be mapped to unbound application 804, which can be executed as an abstract service. Conversely, a transport stream 806 stored in DVD-RAM 800B can contain, in addition to an application on an object carousel and audio/video/digital assets, an AIT executed as a bound service. In another example, SD card 808A can contain XAIT service description 810 mapped to unbound application 812, which is executed as an abstract service. In a further example, hard disk 814 can contain XAIT service description 816 mapped to an unbound application 818 executed as an abstract service, and TS AIT service description 820 mapped to a bound application 822 executed within a bound service. If appropriate, the XAIT need not be co-located with the service media. Thus, in a final example, multiple XAIT service descriptions 824 on SD card 808B can be mapped to unbound applications 826A-826D on remote hard disk 828, which can be executed as bound services

[0058] Varying service discovery protocols can be employed in accordance with varying embodiments. For example, an open specification like the Session Description Protocol (SDP) and/or the Session Initiation Protocol (SIP) may be used to "signal" the secondary storage XAIT. Also, AITs arriving at the edge of a DTV Home Network lnband can be mapped to XAIT format by the framework on-the-fly. Further, XAITs that encapsulate AIT data can be disseminated to the DTV Home Network. Additionally, XAIT-update events can trigger a service registration in UPnP or OSGi. Still further, broadcast of XAIT update events to networked clients can occur via SIP/SDP or the OSGi or UPnP frameworks. Finally, embodiments can have the ability to broadcast DTV services to other clients that are in NGNA Guaranteed Service Domain or Authorized Service Domain.

[0059] In some embodiments, a monitor application can drive update of the SI database, reflecting stored DTV services. For example, the monitor application can modify XAIT schema to identify sharable services. Also, sharing of services can be under MSO control. Further, a monitor application can act as a registrar of applications stored on secondary storage.

[0060] Turning now to Figures 9 and 10, Figure 9 illustrates the prior art XAIT update mechanism, while Figure 10 illustrates update according to some embodiments of the present invention. In Figure 9, the OCAP terminal 900 and its resident monitor application 902 can register XAIT update via API. The native layer 904 containing the service descriptions is updated via OOB.

[0061] In contrast to the prior art, the XAIT update mechanism depicted in Figure 10 allows the service descriptions in the native layer to additionally be updated from a communications system 1000, SD memory card 1002, DVD-RAM 1004, or other source. Communication of XAIT updates from system 1000 can occur over PCM/CIA 1006A, IEEE 1394 1006B, IP network 1006C, wireless 1006D, USB 1006E, and/or other communication mechanisms. Accordingly, OCAP host 1008 can place OCAP services on secondary storage 1010, such as SD card, hard drive, DVD-RAM, and other storage mechanisms. [0062] Turning now to Figure 11 , common-media XAIT update event/XAIT delivery is illustrated by example. Consider a virtual private domain with two OCAP terminals 1100A and 1100B, one of which is configured as a media server. Terminal 1100A can push the XAIT to terminal 1100B. Alternatively or additionally, terminal 1100A can pull the XAIT after receiving a separate XAIT update event (such as a UPnP event). Terminal 1100A could alternatively broadcast secondary storage service throughout the virtual private domain. As an aside, terminal 1100B can simultaneously record a separate broadcast service to local storage disk 1102. Thus, XAIT can be transmitted from terminal 1100A to terminal 1100B following an XAIT update event, and the broadcast stream can be enabled and transmitted from terminal 1100A to terminal 1100B following selection of the broadcast service 604 on terminal 110OA by terminal 1100B.

[0063] Turning now to Figure 12, dual-media update event/XAIT delivery is illustrated by example. It should be noted that an XAIT update event can originate at one device while the XAIT and the service stream originate at another device. Two scenarios are explored in Figure 12 to illustrate this point. In the first scenario, an XAIT update event is communicated from OCAP terminal 1200A to OCAP terminal 1200B. Terminal 1200B then pulls the XAIT update from hard disk 1202, and subsequently selects a service on the hard disk 1202. Streaming then occurs from hard disk 1202 to terminal 1200B. In the second scenario, terminal 1200A first pulls an XAIT update from hard disk 1202. Terminal 1200A then modifies the update and pushes it to OCAP terminal 1200C. Terminal 1200C then selects the service from terminal 1200A, unaware that the content is stored on hard disk 1202. In response, terminal 1200A pulls the selected stream from hard disk 1202, modifies tables in the stream as needed, and transmits the modified stream to terminal 1200C. [0064] Turning now to Figure 13, an EPG user interface 1300 with and merged broadcast/secondary SI is illustrated. The user interface 1300 can provide guide video 1302 with controls for selecting service categories, including broadcast service control 1304, abstract service control 1306, and secondary storage service control 1308. Selecting a service category results in access and display information about of services of the category. The categorical services information can be displayed in services list display area 1310 for final selection by the user. XAIT of broadcasts, monitor applications, and secondary storage are accessed in the EPG 1312 having the interface 1300 through services database 1314. It should be noted that secondary storage services can be mapped to broadcast services or abstract services and accessed and executed as such in some embodiments of the present invention. [0065] Turning now to Figure 14, recording of broadcast service applications according to some embodiments of the present invention is explored with an example. Applications 1400 arriving inband at a OCAP terminal 1402 are delivered to a media rendering device 1404, such as a TV, and also recorded to DVD-RAM 1406. The Applications persisting with XAIT, certificates, hard files, and media assets on DVD-RAM 1406 are thereafter accessible by any other OCAP terminal 908 for delivery to another media rendering device 1410.

[0066] Some embodiments of the present invention are or include a discoverable soft-tuner/interface service capable of launching remote DTV services. Entries in the SI database marked appropriately to indicate if the application is sharable/stored/local or remote. Applications are selected and launched from the EPG as if the application is local. The service allows launching of live applications from a remote client. In some embodiments, the application is downloaded from the remote client and executed locally. For example, an application can be cached locally and then launched. Alternatively, an application can be launched locally from remote storage. In additional or alternative embodiments, an application is launched on a remote client, with only the screen displayed locally as if the application is running on the local machine.

[0067] In some embodiments, the soft tuner service exposes VOD, I PPV, and comparable sessions in the same fashion as for standard broadcast and stored DTV services. The service can also allow launching and control of these sessions from EPG (via soft-tuner), potentially spanning multiple DTV terminals. In some embodiments, a session can be initiated at a given DTV terminal and then transferred to a second DTV terminal (perhaps in a different room).

[0068] The soft-tuner service can be implemented as a discoverable UPnP or OSGi service. Alternatively or additionally, it can be implemented as a DTV service with a UPnP or OSGi proxy. Either approach allows clients to select and tune to local or remote services in a seamless fashion. As detailed above, the architecture can bridge a UPnP AV network and a DTV home network. [0069] Some embodiments of the soft-tuner service define new OCAP monitor application functionality to control bridging of UPnP AV network and DTV home network. In this regard, the MA can play the role of a UPnP control point. The MA can be configured to translate services information from UPnP to OCAP. In some embodiments, the MA uses OCAP API to transparently update SI database, mimicking receipt of XAIT updates.

[0070] In some embodiments, the soft tuner service can define new DTV URL forms, with a superset that includes JavaTV, DVB MHP, and OCAP locators. It can introduce the notion of session to DTV locators (VOD, IPPV, etc.). Possible forms include: dtv://stored[.st g_id] [.sourcejd]; dtv://live[.source_id] == dtv://source_id; dtv://session[.sessoin_id] [.sourcejd].

[0071] In some embodiments of the soft-tuner interface, DTV services (live, stored) can be exposed as UPnP or OSGi services. Alternatively or additionally, the service can define a new UPnP device template, such as: DTV Services Removable Storage Device; and/or UPnP DTV Tuner Device.

[0072] The resource manager service of the DTV receiver provides a resource manager that manages local resources such as tuners, bandwidth (in terms of input and output streams per interface and cumulative), graphics device, background device, video device, decoder/JMF, and storage and others. It also allows reservations from a remote device. In some embodiments, the service can accomplish priority-based and/or user-profile based allocation. For example, requests originating from the device itself may have the highest priority, while requests originating from a device in a bedroom of a home in which the home network is implemented may have a next-highest priority. Accordingly, requests originating from a device in a basement of the home may have the lowest priority. Such parameters may be set during network administration and may be considered during resource contention resolution. In another example, different users registered to the network can have different priorities and can identify themselves by password. The priorities can be stored and accessed on the network in user profiles.

[0073] Being a discoverable service, the resource manager service provides notifications when resources are idle versus busy by broadcast or based on subscription. In addition to managing local resources, it provides a resource allocation snapshot either distributed and/or available to all interested clients. It further maps OCAP/DTV resource allocation requests to UPnP/OSGi events and vice-versa. It is envisioned that resources can be allocated for a fixed time, with the resource requestor renewing the resource before the expiration time.

[0074] Turning now to Figure 15, DTV-HNF distributed resource manager 1500 works in tandem with OCAP resource manager 1502 to keep track of resource allocation status. Remote allocations allocate resources through distributed RM 1500, which in turn allocates resources with OCAP/DTV resource manager 1502. Examples of local and remote reservations are detailed with reference to Figure 16 and Figure 17, respectively.

[0075] Turning now to Figure 16, a local reservation process begins with DTV/OCAP application 1600 requesting a resource from OCAP resource manager 1502. Next, OCAP resource manager 1502 signals the application1600 that the resource has been successfully reserved. Then, OCAP resource manager 1502 notifies distributed resource manager 1500 that the resource is busy. Finally, distributed resource manager 1500 notifies devices on the home network 1602 that the resource is busy. [0076] Turning now to Figure 17, a remote reservation process begins with a device on the home network 1602 requesting a resource from distributed resource manager 1500. Next, distributed resource manager 1500 requests the resource from OCAP resource manager 1502. Then, OCAP resource manager 1600 signals distributed resource manager 1500 that the resource has been successfully reserved. Then, distributed resource manager signals the requesting device on the home network 1602 that the resource has been successfully reserved. Thereafter, DTV/OCAP application 1600 requests the same resource from OCAP resource manager 1502. In response, OCAP resource manager 1502 signals DTV/OCAP application 1600 that the resource is busy. Resource contention is handled by OCAP rules (e.g., monitor application).

[0077] The broadcast time and stream event service of the DTV receiver accomplishes distribution and synchronization of broadcast triggers with devices in the home network. Triggers are mechanisms to synchronize DTV applications with program content. Analog triggers are carried in VBI, while digital triggers can be carried as DSMCC stream event or as a playlist in an alternate channel. Three kinds of triggers are absolute time triggers, relative time triggers, and do it now triggers. Triggers are meant for consumption at the DTV receiver.

[0078] In some embodiments, the invention provides a mechanism to synchronize a real-time clock between the DTV receiver and other home appliances. For example, the invention can be or include a discoverable, self- describing service, which makes time (time of the day) information available to any requesting entity on the home network. The service description can be provided using XML. The service can be discoverable by using different service discovery protocols (e.g., SSDP). Time information can be extracted from STT and provided as events/actions over a variety of home networking frameworks (e.g., OSGi, UPnP, DENI, and others). Some embodiments can provide a mechanism to extend availability of DSMCC triggers on the home network with time synchronization.

[0079] According to the broadcast time service, the DTV receiver extracts time information from MPEG2 PSl. For example, it converts the time information into XML or other, appropriate formats. It also manages subscription and notification of time of day to network appliances for time synchronization. Home network devices can update themselves with broadcast time extracted from STT by invoking the following actions, wherein GetTime() returns STT time: GetTime(TimeFormatParameter) returns STT converted into other various formats (for instance, GMT). The service can also pose the "BroadcastTime/SystemTime" evented state variable. Accordingly, all entities that subscribe to this service receive time change events. This can be a moderated state variable in order to decrease the frequency of eventing, for example, if once per second eventing is too frequent. [0080] In some embodiments, a trigger relay service can be provided.

For example, triggers can be extracted as stream events from a broadcast carousel. Triggers can also be converted to XML or other, appropriate formats. Time information can further be synchronized with a broadcast time service. Still further, subscription and notification to home appliances can be managed.

Finally, triggers can be cached for later access, and/or converted to UPnP or

OSGi event format. [0081] Turning now to Figure 18, triggers from broadcast carousel

1800 are cached in datastore 1802 for later dispatch by the receiver 1804 via broadcast on the home network 1806 to appliances 1808A-1808C. This procedure enables synchronization of a home appliance with content on DTV, and distributed applications related to the content. [0082] Turning now to Figure 19, in an operation example, DTV receiver 1900 includes a trigger service 1902 that operates according to a time service 1904 and receives events from broadcast carousel 1904. Home appliance 1908 registers for or subscribes to time and trigger information.

Thereafter, receiver 1900 sends time information and trigger notifications to home appliance 1908. Trigger notifications can include time information and be in XML format.

[0083] The content listing service (or EPG service) of the DTV receiver has some similarities to the UPnP CDS, but has extended capabilities. For example, it can import VOD/PPV sessions and exports events. It can also make metadata available from multiple tuners, such as cable and terrestrial tuners. It can further make bandwidth requirements available, along with copy protection rules. Finally, it can provide metadata translations.

[0084] Turning now to Figure 20, the content listing service 2000 can interface with an OCAP SI manager 2002 and an OCAP recording manger 2004, which in turn interface with the OCAP application 2006. Content listing service

2000 can exchange subscriptions, notifications, and events with home network

2008.

[0085] In some embodiments, content listing and launching can be a discoverable home network service. For example, it can be a consolidated Java TV service or content listing from sources such as: SI manager for broadcast services; recording manager for stored services via DVR; VOD/PPV sessions; contents stored in removable and/or fixed storage via SD card, hard disk, DVD/CD, and others; and Internet content. Metadata can be provided in association with each entry.

[0086] Metadata information can include various components. For example, it can include metadata in XML format that has been translated form SI data, VOD metadata, TV-AnyTime metadata, and others. Metadata can also contain one or more uniform locators for launching the service in question. Metadata can further specify format, such as SD, HD, audio/video, mp3, and others. Metadata can still further provide an estimate of bandwidth requirements. Metadata can even further specify that a service is XAIT or AIT. Yet still further, metadata can specify that the service in question is remote launchable. Finally, metadata can describe copy protection rules for a content service.

[0087] The content listing and launching service can monitor removable storage (SD, DVD, CD, etc.) media for content. In this regard, the service can generate notifications.

[0088] Turning now to Figure 21 , the content listing service architecture can include the content listing service 2100 employing uniform locators 2102 mapped to multiple content sources. Sources can include broadcast content 2104 from SI manager, including tuners 2106, cable, ATSC, etc.. Sources can also include stored content 2108, and stored services 2110 from recording manager (DVR), each of which can be stored on hard disk 2112 or on removable storage, such as SD card 2114. Sources can also include VOD/PPV sessions 2116, the Internet 2118, and multi-player games 2120.

[0089] 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. For example, while a home network is typically envisioned as being deployed in a single family dwelling, it should be readily understood that a home network can be deployed across multiple locations as a virtual private domain, and/or can be deployed in various types of locations, including offices, public places, and vehicles. Such variations are not to be regarded as a departure from the spirit and scope of the invention.

Claims

CLAIMS What is claimed is:

1. A network architecture, comprising: a broadcast network; a home network; a DTV receiver connected to said broadcast network and said home network; and one or more DTV-related services implemented on said DTV receiver, wherein said DTV-related services are operable to expose functionalities of the DTV receiver to the home network.

2. The architecture of claim 1 , wherein said DTV-related service is a tuner service operable to expose signaling from a real tuner to other devices on the home network.

3. The architecture of claim 1 , wherein said DTV-related service is a resource manager service operable to manage and keep track of allocation of resources of said DTV receiver.

4. The architecture of claim 1 , wherein said DTV-related service is a time and stream event service operable to maintain a common time for the network and deliver triggers to the network from a cache of triggers received from a broadcast carousel via said DTV receiver, said delivery occurring according to the common time.

5. The architecture of claim 1 , further comprising a content listing service employing uniform locators mapped to multiple content sources, including at least two sources selected from the group consisting of: (a) broadcast content from a service information manager;

(b) stored content from a recording manager;

(c) stored services from a recording manager

(d) VOD/PPV sessions; (e) the Internet; or

(f) multi-player games.

6. The architecture of claim 1 , wherein said DTV-related service is implemented on said DTV receiver.

7. The architecture of claim 1 , wherein said DTV-related service is implemented as a proxy service on a device connected to the network, wherein the device is not said DTV receiver.

8. A tuner service, comprising: a plurality of tuner objects stored in memory, said tuner objects having characteristics indicating states and capabilities of at least one of: (a) a real tuner having a capability to tune to and receive at least one of broadcast or narrowcast DTV services; or (b) a soft tuner mimicking a real tuner for one or more DTV services stored in secondary storage media connected to the network, said soft tuner having a capability to deliver the DTV services from the secondary storage; a tuning module controlling at least one of said real tuner or said soft tuner according to control commands received over the network from control points connected to the network; and a service discovery module exposing: (a) the characteristics and capabilities of the tuner objects to the network; and (b) capabilities and related control commands of the tuning module to the network.

9. The service of claim 8, further comprising an SI data translation module translating SI data according to a format requested by a client, merging broadcast SI data in a common database with home network SI data, and delivering contents of the common database to the home network.

10. The service of claim 8, wherein said service exposes signaling from a real tuner to other devices on the network, including at least one of the following types of signaling:

(a) EAS;

(b) CA;

(c) MMI; (d) Service Information tables; or

(e) Channel Map.

11. The service of claim 8, further comprising an XAIT mapping module mapping XAIT to at least one of secondary storage services or applications.

12. The service of claim 8, further comprising an XAIT updating module receiving XAIT updates from secondary storage and updating XAIT stored in a native network layer accordingly.

13. The service of claim 8, further comprising a recording module recording broadcast service applications by attaching a time shift buffer according to received control commands.

14. The service of claim 8, wherein said service resides in a DTV receiver.

15. A resource manager service, comprising: a distributed resource manager in communication with a network; a local resource manager in communication with an application running on a DTV device, wherein said distributed resource manager and said local resource manager work in tandem to allocate at least one of local resources or distributed resources, and to keep track of resource allocation status relating to said resources.

16. The service of claim 15, wherein remote allocations allocate resources through said distributed resource manager, which in turn allocates resources with said local resource manager.

17. The service of claim 16, wherein said distributed resource manager and said local resource manager are configured to manage a local reservation process in which the application requesting a resource from said local resource manager, said local resource manager signals the application that the resource has been successfully reserved, said local resource manager notifies said distributed resource manager that the resource is busy, and said distributed resource manager notifies the home network that the resource is busy.

18. The service of claim 16, wherein said distributed resource manager and said local resource manager are configured to manage a remote reservation process in which the home network requests a resource from said distributed resource manager, said distributed resource manager requests the resource from said local resource manager, said resource manager signals said distributed resource manager that the resource has been successfully reserved, and said distributed resource manager signals the home network that the resource has been successfully reserved.

19. The service of claim 18, wherein following reservation of the resource, the application requests the resource from said local resource manager, said local resource manager responds by signaling the application that the resource is busy.

20. The service of claim 15, wherein said service resides in a DTV receiver.

21. The service of claim 15, wherein said service at least one of resolves resource contention or performs resource allocation based on differing priorities accorded to different sources of requests for resources.

22. The service of claim 21 , wherein the sources are differentiated as different DTV devices on the home network.

23. The service of claim 21 , wherein the sources are differentiated as different users identifying themselves by password, said users having differing priorities recorded in respective user profiles on the home network.

24. The service of claim 15, wherein said service records data of resource usage, including at least one of: time of resource usage; duration of resource usage; device using a resource; or user using a resource, said service exposing the data as state variables, and using the data to identify resources in the network having a least probability of a contention.

25. A time and stream event service, comprising: a datastore caching triggers received from a broadcast carousel; a time service maintaining a common time for a network; a trigger relay service operating according to the time service to deliver triggers from said datastore to devices on the network.

26. The service of claim 25, wherein said time service is a discoverable, self-describing service that makes time information available to a requesting entity on the network.

27. The service of claim 25, wherein said time service extracts time of the day information from in-band PSI tables and makes this time information available to other appliances in the home network for setting up their clock automatically.

28. The service of claim 25, further comprising a mechanism to extend availability of triggers on the network with time synchronization.

29. The service of claim 28, wherein said trigger relay service extracts triggers as stream events from the broadcast carousel, and converts the triggers to appropriate formats for delivery to devices on the network.

30. The service of claim 25, wherein said time and stream event service resides on a DTV receiver.