WO2006029247A2

WO2006029247A2 - Digital tv and home networking framework

Info

Publication number: WO2006029247A2
Application number: PCT/US2005/031946
Authority: WO
Inventors: Rajesh B. Khandelwal; Luyang Li; Dmitry A. Tkachenko; Nickolay V. Kornet
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2004-09-07
Filing date: 2005-09-07
Publication date: 2006-03-16
Also published as: WO2006029247A3; WO2006029247B1

Abstract

A home networking framework (14) is provided for interfacing an application residing on a digital TV receiver (16) with a home network environment. The home networking framework (14) includes: a digital TV middleware (22) that enables the application to access a digital transport stream received at the digital TV receiver (16); and a home network manager (40) that registers network devices (18A-N) and services support by the network devices (18 A-N) in a registry, thereby enabling discovery of the registered devices and services by the application. The home networking framework (14) further includes a service interface (42) which implements the functionality necessary to expose the application to the registered services and a networking translator (44) which provides the functionality necessary for communicating with particular types of network technologies. In an exemplary implementation, the service interface and network translator (44) are plug-ins modules that may be dynamically downloaded from the broadcast stream.

Description

DIGITAL TV AND HOME NETWORKING FRAMEWORK

CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims the benefit of U.S. Provisional

Application No. 60/607,571 filed on September 7, 2004. The disclosure of the above application is incorporated herein by reference.

FIELD OF THE INVENTION [0002] The present invention relates to a method and system for communicating with and managing a network of devices.

BACKGROUND OF THE INVENTION

[0003] Interactive digital television (iDTV) platforms are on the verge of fostering a new generation of television programming content. Examples of prominent standard iDTV specifications are MHP (Multimedia Home Platform),

OCAP (OpenCable Application Platform), and ACAP (Advanced Common

Application Platform). Such platforms allow interactive content, generally in the form of Java programs, to be downloaded to an iDTV receiver via a DTV (terrestrial, cable or satellite) broadcast. Interactive content includes electronic programming guides, program-related applications, games, etc.

[0004] At the same time, home networking technologies that allow devices to automatically interoperate with one another are beginning to become mainstream. Examples of such home networking technologies are OSGi (Open Services Gateway Initiative), UPnP (Universal Plug And Play), Home Plug, etc.

[0005] Despite the obvious benefits to consumers, work in these two areas has largely remained separate. Bridging the gap between iDTV platforms and home networking domains would allow iDTV applications access to home networks and their various devices.

SUMMARY OF THE INVENTION [0006] A home networking framework is provided for interfacing an application residing on a digital TV receiver with a home network environment. The home networking framework includes: a digital TV middleware that enables the application to access a digital transport stream received at the digital TV receiver; and a home network manager that registers network devices and services supported by the network devices in a registry, thereby enabling discovery of the registered devices and services by the application. The home networking framework further includes a service interface which implements the functionality necessary to expose the registered services to the application and a networking translator which provides the functionality necessary for communicating with particular types of network technologies.

[0007] In other aspects of the present invention, the service interface and network translator are implemented via plug-ins modules that may be dynamically downloaded from the broadcast stream. [0008] 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

[0009] Figure 1 is an illustration of a home network communicating with a home networking framework of an interactive digital television set top box; [0010] Figure 2 is an illustration of a home networking framework according to the present invention;

[0011] Figure 3 is an illustration of a network manager of the home networking framework;

[0012] Figure 4 is a block diagram illustrating a home networking services layer of the home networking framework; [0013] Figure 5 is a block diagram illustrating a networking translator layer of the home networking framework; [0014] Figure 6 is a table illustrating categories of services provided by devices on the home network;

[0015] Figure 7 is a block diagram illustrating interfacing between an application and a device of the home network via the home networking framework during discovery and registration;

[0016] Figure 8 is a block diagram illustrating interfacing between an application and a device of the home network via the home networking framework when a service is requested by an application; and

[0017] Figure 9 is a block diagram illustrating a home networking environment having multiple interconnected local gateways in accordance with another aspect of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0018] Figure 1 depicts an exemplary home networking environment. The home networking environment is primarily comprised of a plurality of network devices 18A-N interconnected by a home network 12. The network devices communicate with one another according to one or more communication protocols or home networking technologies. Such protocols and home networking technologies may include, but are not limited to, Universal Plug and Play (UPnP), Open Service Gateway initiative (OSGi), Home Plug, USB, IEEE 1394, Wi-Fi, and Bluetooth. Although particular standardized protocols and networking technologies are being discussed, the implementation of the home networking framework is independent of any standardized protocol or networking technology. [0019] At least one of the network devices is further defined as an interactive digital television (iDTV) set top box (STB) 16 which is adapted to receive a broadcast transport stream. Functionality of set top box 16 may also be implemented in television set containing a video display and all necessary blocks and electronic circuits for receiving broadcast TV programs. This device will be referred to herein as a digital TV receiver.

[0020] In an alternative embodiment (not shown), set top box 16 communicates directly with another iDTV set top box 16 or receiver (not shown). For example, a first STB 16 provides services to the home network 12, a second STB 16 can communicate with the first STB 16 to use the content and services of the first STB 16. A first STB 16 may also control services of other set top boxes 16. [0021] The set top box 16 includes a number of abstract software layers. The top layer is the iDTV applications layer 20. The layer includes a number of iDTV applications (also referred to as Xlets in the context of Java programming) that are downloaded to the STB 16. Applications are typically small programs that perform simple functions of the interactive television such as electronic programming guides (EPGs), interactive games, enhanced content, managing a broadcast media pipeline, or managing a broadcast data signal.

[0022] The next layer includes a digital TV middleware 22 and a home networking framework 14. The digital TV middleware 22 provides an environment for running iDTV applications. The digital TV middleware 22 allows interactive content to be downloaded to the STB 16 from a DTV (terrestrial, cable, or satellite) broadcast stream 24. Exemplary middlewares include but are not limited to Multimedia Home Platform (MHP), OpenCable Application Platform (OCAP), and Advanced Common Application Platform (ACAP). The home networking framework 14 is an interface that enables applications 20 on the STB 16 to access and communicate with the network devices 18A-N in the home network 12. The home networking framework 14 will be discussed in more detail below.

[0023] The layer below the digital TV middleware 22 and the home networking framework 14 is a programming platform layer 26. This layer includes libraries and programming functionalities that support the underlying programming languages used to implement the iDTV applications 20, the digital TV middleware 22, and the home networking framework 14. In an exemplary embodiment, the programming platform is a Java Virtual Machine. While the following description is provided with reference to a Java implementation, it is readily understood that one or more other programming languages can be used to implement the programs of the various layers. [0024] An operating system layer 28 manages and controls the operations of the STB 16. A receiver layer 30 includes communication software drivers for receiving and sending data.

[0025] Figure 2 depicts the home networking framework 14 according to the principles of the present invention. The home networking framework (HNF) 14 facilitates the communication between applications 20 on the STB 16 and network devices 18A-N of the home network. The home networking framework 14 communicates with network devices 18A-N by interacting with functionalities also referred to as services of a device. [0026] The home networking framework 14 is comprised of at least three abstract software layers: a network manager 40, a home networking services layer 42, and networking translator layer 44. Each layer includes one or more software programs responsible for a different function of the communication. Each layer passes information up and down to the next subsequent layer as data is communicated between the application 20 and a network device 18A-N. Each of these layers will be further described below.

[0027] Figure 3 illustrates an exemplary embodiment of the network manager 40. For illustration purposes, the network manager will be discussed in the context of Java programming. In the Java context, the network manager includes a plurality of classes and application program interfaces (APIs) that provide for the interaction between applications 20 and the network devices 18A- N of the home network 12. The classes and interfaces allow the network manager 40 to discover devices, register devices and services, and manage events on the home network 12. The entities of the network manager 40 can be implemented as any programming construct suitable for the particular programming language used to implement the home networking framework.

[0028] In this exemplary embodiment, the network manager class 46 is a singleton class that discovers and registers all devices and services within a home network 12. The network manager is the entry point for applications 20 to communicate with all device interfaces and service interfaces. Discovery of devices and services in the home network is implemented in cooperative operation with the network translator described below. The network manager class 46 registers devices 48 and their corresponding services 50 provided by the device 48. Registration involves compiling a device list 52 and a service list 54. The network manager allows the lists to be filtered by a property filter 56 according to key-value pairs 58 (such as "network_technology"="UPnP" or "serial_number"="087956135"). Each service 50 is capable of performing at least one function of the device 48. Any function can be defined as a single action 60, where the parameters 62A-N define how the action 60 is to be performed for a particular device 48. These parameters may include both input (that are set before action performing) and output (that contain results of action performing) parameters. Each action 60 can have zero or more parameters 62A-N (e.g., actions "play" or "stop" may have no parameters).

[0029] The network manager class 46 also manages service events, either status events 64 or state events 66 that occur on the network. The network manager allows an application to monitor a service's internal state (the state event 66) by subscribing as a listener to the service via a service event listener interface 68. The home network also allows an application to monitor a service's status (the status event 64) on the network by subscribing as a listener to the changed services via a service change listener interface 70. The service's status can be available, busy, or lost. Further description of the most relevant classes and application program interfaces of this exemplary embodiment is found in the appendix below.

[0030] The home networking services layer implements the functionality necessary to expose the services provided by the network devices to an iDTV application. More specifically, the home networking services layer provides an application program interface for the iDTV applications in the form of a set of actions, where each action may be performed with certain arguments that describe parameters of the action. In operation, the iDTV application is aware of the actions and parameters that are needed for a particular service, but is not aware of the communication protocol or type of network technology that is used to connect to the network device which supports the requested service. Thus, the iDTV application provides arguments for a given action to the service layer which in turn translates the arguments into commands that may be accepted by the network interface layer.

[0031] In an exemplary embodiment, the service layer may be implemented using a series of service plug-in modules as shown in Figure 4. A service plug-in module is operable to instantiate multiple service objects which correspond to the services exposed by the network devices. For example, a home network having three different USB printers would have three service objects produced by the same service plug-in. In contrast, a different service plug-in module would instantiate a service object for a USB MP3 player. [0032] Service plug-ins 72A-N can be preinstalled on the set-top box

16. However, a service plug-in is preferably downloaded from the broadcast stream 24 as will be further described below. Alternatively, a service plug-in may be downloaded from the home network 12, from another external network (like Internet) connected to the home network or from flash card, CD disk or other removable storage device connected to the home network 12.

[0033] The networking translator layer 44 implements the functionality necessary to communicate with the services of a device in accordance with the home networking technologies. Thus, the networking translator layer 44 provides network-level interfaces required to communicate with devices and services of a particular home network.

[0034] In an exemplary embodiment, the network interface layer may be implemented using a series of network plug-in modules 74A-74N as shown in Figure 5. Each network plug-in may correspond to a protocol or home networking technology, including but not limited to, UPnP, OSGi, HAVi, etc. Network plug-ins 74A-N map the interfaces of the network manager 40 and service plug-ins 72A-N to interfaces capable of communicating with a particular device 18A. It is reasonable to assume that network plug-ins corresponding to high-level network technologies (i.e., UPnP or OSGi) that are agnostic of a physical communications layer may be downloadable; whereas, support for network technologies dependent on specific physical layers (i.e., IEEE 1394) are preferably preinstalled on the DTV receiver. It is envisioned that network plug- ins may be downloaded from other sources and in a similar manner as service plug-ins.

[0035] In general, service plug-ins 72A-72N may be unique for every model of device for every manufacturer (e.g. different models of printers may need different service plug-ins). In order to substantially decrease the number of possible downloadable service plug-ins 72A-72N, it is further proposed in the invention to introduce service categories, where every service plug-in would correspond to a service category. For example, all models of conditioner devices should provide the same basic functionality so that a conditioner control service plug-in would provide the same interface for interaction with an iDTV application 20. This unification will restrict to some extent the basic functionality of devices exposed to iDTV applications, but it may be a reasonable solution because it is hardly reasonable and possible to put separate plug-ins for each model of home devices into the broadcast stream 24. Nevertheless, it may be still possible to download service plug-ins 72A-72N corresponding to specific models of devices (with model-specific functionality) from the Internet or from local storage device.

[0036] Even if every service plug-in corresponds to some unified service category, it is still necessary to have different service plug-ins for interactions with different network technologies i.e., a storage device connected via IEEE-1394 network plug-in and a storage device connected via USB network plug-in will need different service plug-ins. These two service plug-ins will provide the same service interface for iDTV application, but they will have different interfaces with network plug-ins 74A-74N depending on specific features of the network technology.

[0037] A unification of interfaces between network plug-ins 74A-74N and service plug-ins 72A-72N is also contemplated. That is, it may be possible to have the same interface for all network plug-ins 74A-74N. For example, it may contain methods for performing basic network-related actions (e.g. sending control commands, receiving discovery notifications, etc.); whereas, transfer of service specific actions and parameters may be implemented, for example, in the format of binary data that will be further processed by each network plug-in. The advantage of such approach is that each service category will need only one service plug-in for interaction with any network plug-in. The drawback of this approach is that it is difficult to make unification of network plug-in interfaces for different technology (e.g. X-10 technology for control of home automation devices is strongly different from IEEE-1394 technology that is used for audio and video transfer). The detailed consideration of this approach is beyond the scope of the current invention.

[0038] Service plug-ins 72A-N can be grouped into service categories as shown in Figure 6. Each category declares a set of actions 60 and their input/output parameters 62A-N that are provided by the associated service object 50. When an iDTV application 20 needs to find a device 18A that offers a specific service (e.g., hardcopy printing), the network manager class 46 queries the service list 54 and device list 52 for a list of appropriate devices and then uses the published device and service information (service category, manufacturer, location in the home or connection via certain home network technology, etc.) to select a service plug-in 72A. If this service plug-in is not installed yet, it is downloaded and installed.

[0039] In Figure 6, cells of the table may contain Uniform Resource Identifiers (URIs) for downloading of corresponding service plug-ins from broadcast stream 24, home network 12, etc. This table may be implemented using, for example, XML and may be downloaded to STB 16, for example, via broadcast stream 24. When necessary, the table may be updated.

[0040] Figure 7 is a block diagram illustrating an exemplary sequence of events that may occur between layers of the HNF 14 when the HNF 14 discovers and registers devices on a home network 12. First, an iDTV application 20 requests a list of devices within a given category at 100, the network manager 40 communicates the request to the networking translator at 110. Each network plug-in 74A.B of the networking translator multicasts a discovery message searching for interesting devices, services, or both at 120. All devices 18A.B listen to the standard multicast address for these messages. If any of the devices 18A,B embedded devices or services match the search criteria in the discovery message, the device 18A.B responds to the message at 130. The networking plug-ins 74A₁B receive the response and transfer the response along with pertinent device information to the network manager 40 at 140. The network manager 40 combines the subsequent search results into service lists and device lists, and then returns those results to the requesting application at 150.

[0041] Alternatively, a network plug-in 74A may learn of a device of interest from a new device 18A advertising itself on the network (not shown). The network plug-in 74A receives the advertising message and relays the message along with other pertinent device information to the network manager 40. The network manager 40 informs all applications 20 that subscribe to receive status events about the new devices and services. After discovery, the network plug-in 74A gathers basic information about the new device such as serial number, manufacturer, model number, etc. The network plug-in 74A passes this information to the network manager 40 where it is stored in a registry.

[0042] Similarly, when a device 18A is removed from the network, the device 18A may multicast a number of discovery messages revoking it's earlier announcements (not shown), effectively declaring that it's embedded devices and services will not be available. The network plug-in 74A receives these messages and relays them to the network manager 40. The network manager 40 informs all applications 20 that subscribe to receive status events about the removed device. The device 18A and its services are then removed from the registry. Other mechanisms for monitoring of device disconnecting are also possible. [0043] Figure 8 is a block diagram illustrating an exemplary interaction between an application 20 and services on a UPnP device 18A. First, an application 20 communicates to the network manager 40 its desire to perform an action at 200. The network manager 40 in turn calls service actions and sets parameters, if necessary, of service plug-ins 72A at 210. The service plug-in 72A translates actions and parameters to device specific commands and passes to UPnP network plug-in at 220. In the case of UPnP, the service plug-in prepares UPnP control messages for a specific service and relays them to the UPnP network plug-in. The UPnP network plug-in 74A operates a control point and thus sends the control messages to the applicable network device in accordance with the UPnP communication protocol at 230. The device 18A receives the command and performs accordingly. [0044] A state of the service performed on the device may be routinely multicasted at 240. Network-plug-ins 74A monitor the state message and relay the information to the network manager 40 at 250. The network manager 40 updates all applications 20 subscribed to the service event of the change in state at 260. [0045] In another aspect of the present invention, a method is provided for determining the location of a network device in a home networking environment. Referring to Figure 9, multiple local gateways are used to construct the home networking environment. More specifically, each local gateway resides in a different room of the home and is assigned a location identifier for the room. The local gateways are in turn interconnected a backbone home network implemented using Ethernet, IEEE802.11 or other suitable technologies.

[0046] When a network device connects to the home network, it will be associated with one of the local network gateways. The network device in turn receives an identifier for its assigned local network gateway which implicitly indicates the location of the network device in the home. For a wired network connection, the identity of the local gateway may be readily ascertained. For a wireless connection, the local gateways may be configured to detect the signal power level received from wireless network devices and assign a given wireless device to the local gateway recording the highest signal level from the given wireless device. It is readily understood that other types of assignment mechanisms are contemplated.

[0047] When a network device is detached from one local gateway and attached to another, a tracking mechanism tracks the change of the device location within the home network based on the gateway identifier and the unique identifier assigned to each physical device. In this way, the proximate location of a network device may be determined based on its association with a local gateway.

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

APPENDIX

Device

Declaration public interface Device

Description

The Device interface represents a Homenetwork device that supports homenetwork HNServices. A Device is a hierarchical structure with root device being the physical appliance, such as an OCAP_Terminal or an OCAPJHOST. The valid device types for an OCAP root device are OCAPJHOST and OCAP_Terminal. A root device may contain a number of sub-devices. Each sub- device may support one or more HNService(s) whereas each HNService only represents one sub-device. A HNService is some functional unit in the device and examples of HNServices are ContentList, ContentManager, etc. A device may also have certain capabilities and properties associated with it. An application can retrieve these capabilities and properties by using property filters.

Fields

CAP_REMOTE_STORAGE_SUPPORTED public static final java.lang.String CAP_REMOTE_STORAGE_SUPPORTED

A constant indicating remote storage capability.

CAP_STREAMING_SUPPORTED public static final java.lang.String CAP_STREAMING_SUPPORTED

A constant indicating streaming capability of the device.

CAP_TUNER_SUPPORTED public static final java.lang.String CAP_TUNER_SUPPORTED

A constant indicating if the device has a tuner.

PROP_FRIENDLY_NAME public static final java.lang.String PROP_FRIENDLY_NAME

A constant for a friendly name of the device.

PROPJ.OCATION public static final java.lang.String PROPJ-OCATION

A constant indicates device property: location of the device.

PROP_MANUFACTURER public static final java.lang.String PROP_MANUFACTURER A constant indicating the manufacturer of this device.

PROP_MANUFACTURER_URL public static final java.lang.String PROP_MANUFACTURER_URL

A constant providing URL to the manufacturer's web site.

PROP_MIDDLEWARE_PROFILE public static final java.lang.String PROP_MIDDLEWARE_PROFILE

A constant indicates device property: middleware profile.

PROP_MIDDLEWARE_VERSION public static final java.lang.String PROP_MIDDLEWARE_VERSION

A constant indicates device property: middleware version.

PROP_MODEL_DESCRIPTION public static final java.lang.String PROP_MODEL_DESCRIPTION

A constant providing description of the device.

PROP_MODEL_NAME public static final java.lang.String PROP_MODEL_NAME

A constant indicates device property: model name.

PROP_MODEL_NUMBER public static final java.lang.String PROP_MODEL_NUMBER

A constant indicates device property: model number.

PROP_MODEL_URL public static final java.lang.String PROP_MODEL_URL

A constant indicates device property: model URL.

PROP_PRESENTATION_URL public static final java.lang.String PROP_PRESENTATION_URL

A constant indicates device property: presentation URL.

PROP_SERIAL_NUMBER public static final java.lang.String PROP_SERIAL_NUMBER

A constant indicates device property: serial number. PROPJJDN public static final Java. lang. String PROP-UDN

A constant indicates device property: unique device name.

PROP-UPC public static final Java. lang. String PROPJJPC

A constant indicates device property: universal product code.

TYPE_BINARY_LIGHT public static final java.lang.String TYPE_BINARY_LIGHT

A constant indicates device type: Binary Light (on/off).

TYPEJDIMMABLE JJGHT public static final java.lang.String TYPE J)IMMABLE_LIGHT

A constant indicates device type: Dimmable Light (light intensity control).

TYPE_HVAC_SYSTEM public static final java.lang.String TYPE JHVAC_SYSTEM

A constant indicates device type: Heater-Vent-Air Conditioning System.

TYPE_HVAC_ZONE_THERMOSTAT public static final java.lang.String TYPE_HVAC_ZONE_THERMOSTAT

A constant indicates device type: Heater-Vent-Air Conditioning Thermostat.

TYPEJNTERNET J3ATEWAY_DEVICE public static final Java. lang. String TYPEJNTERNETJ3ATEWAY JDEVICE

A constant indicates device type: Internet gateway device.

TYPE_LAN J)EVICE public static final java.lang.String TYP E-LANJD EVI C E

A constant indicates device type: LAN device.

TYPE_MEDIA_RENDERER public static final java.lang.String TYPE-MEDI A-RENDERER

A constant indicates device type: Media Renderer.

TYPE MEDIA SERVER public static final java.lang.String TYPE_MEDIA_SERVER A constant indicates device type: Media Server. TYPE_OCAP_HOST public static final java.lang.String TYPE_OCAP_HOST

A constant indicates device type: OCAP Host. TYPE_OCAP_TERMINAL public static final java.lang.String TYPE_OCAP_TERMINAL

A constant indicates device type: OCAP terminal. TYPE_PRINTER public static final java.lang.String TYPE_PRINTER

A constant indicates device type: Printer. TYPE_REMOTE_UI_CLIENT_DEVICE public static final java.lang.String TYPE_REMOTE_UI_CLIENT_DEVICE

A constant indicates device type: Remote Ul Client Device, Allows for basic operations on a Remote Ul client including: user interface connection management, optionally user interface availability management and optionally basic user interaction.

TYPE_REMOTE_UI_SERVER_DEVICE public static final java.lang.String TYPE_REMOTE_UI_SERVER_DEVICE

A constant indicates device type: Remote Ul Server Device.

See Also: TYPE_REMOTE_UI_CLIENT_DEVICE TYPE_SCANNER public static final java.lang.String TYPE_SCANNER

A constant indicates device type: Scanner. TYPE_WAN_CONNECTION_DEVICE public static final java.lang.String TYPE_WAN_CONNECTION_DEVICE A constant indicates device type: WAN connection device.

TYPE_WAN_DEVICE public static final java.lang.String TYPE_WAN_DEVICE

A constant indicates device type: WAN device. TYPE_WLAN_ACCESS_POINT_DEVICE public static final Java. lang. String

TYPE_WLAN_ACCESS_POINT_DEVICE A constant indicates device type: WAN access point device.

Methods getCapabilJtiesO public Java. util. Enumeration getCapabilities()

Returns capabilities of this device in Enumeration. Capabilities are defined in Device. Returns: An enumeration of String objects representing capabilities of this device. getKeys() public Java. util. Enumeration getKeys()

Returns all property keys supported by this device in Enumeration.

Returns: An enumeration of String objects representing all property keys supported by this device getName() public Java. lang. String getName()

Returns the name of this device. It is the responsibility of the implementation to assure that the device name is unique within a home network. The naming rule is proprietary. For example, "LivingRoom:OCAP_HOST1".

Returns: name of this device getHNService(String) public org.ocap.hn.HNService getHNService(java. lang. String serviceld)

Returns the HNService by service id. Service id is unique within a device.

Parameters: serviceld - unique id of a HNService

Returns: HNService by id, if specified HNService is not supported by this device, then null is returned. getHNServiceListO public org.ocap.hn.HNServiceList getHNServiceListO Returns the list of HNServices supported by this device.

Returns: HNServiceList supported by this device getProperty(String) public Java. lang. String getProperty(java.lang. String key)

Returns property of this device specified by a key. Minimum supported keys are defined in Device, like PROP_MANUFACTURER,

PROP_MODEL_NUMBER, etc.

Parameters: key - key of the property

Returns: property value specified by the key getSubDevices() public org.ocap.hn.DeviceList getSubDevices()

Returns a list of sub devices hosted by this device.

Returns: list of sub-devices. getType() public int getType()

Returns the type of this device, for example, MediaRenderer, MediaServer, etc. All OCAP-HN device types are defined in Device.

Returns: type of this device

Deviceϋst

Declaration public interface DeviceList

Description A group of devices. The application may retrieve such a list from NetManager getDeviceUst. The application may refine the list by applying a PropertyFilter. contains(Device) public boolean contains(org.ocap.hn. Device device)

Indicates whether a device is included in the list

Parameters: device - device to be checked

Returns: true if device is included in the list; otherwise false getElement(int) public org.ocap.hn. Device getDevice(int index)

Returns device by index Parameters: index - index of the device

Returns: device matching index; if index is less than 0 or greater than device list size, null is returned. getElements() public Java. util. Enumeration getDevices()

Returns all devices in this DeviceList in Enumeration. Returns: An enumeration of Device elements. filterElement(PropertyFilter) public DeviceList filterDevice(PropertyFilter filter) A new device list is generated based on new filter

Parameters: filter - new filter to generate the device list Returns: new device list generated on new filter indexOf (Device) public int indexθf(org.ocap.hn. Device device) Returns the index of a device in this list

Parameters: device - device to be checked Returns: index of the device in this list; if no such device, -1 is returned. size() public int size() Returns the size of the device list

Returns: size of the device list NetManaqer

Declaration public abstract class NetManager Java. lang. Object

I +-org.ocap.hn. NetManager

Description The NetManager is a singleton class that registers all the Devices and HNServices within a home network. It maintains an implementation dependent database of devices and HNServices. The NetManager may be used to retrieve list of HNService and Device in the network. The application can filter the list by specifying a name or by applying filtering rules. For example, "modelNumber = h6315, location = LivingRoom". Application can monitor availability of HNServices by registering as a listener to NetManager instance.

Constructors NetManagerQ public NetManagerO

Methods addHNServiceChangeListenerfHNServiceEventListener) public abstract void addHNServiceChangeListener (org.ocap.hn.HNServiceEventListenerlistener)

Adds a HNService change listener to NetManager. Listener will receive a HNServiceEvent when a new HNService is registered or an old

HNService is removed from home network. If listener is already registered, no action is performed.

Parameters: listener - Listener which listens to HNService change events on home network

See Also: removeHNServiceChangeListene^HNServiceEventListener) getDevice(String) public abstract org.ocap.hn. Device getDevice(java. lang. String name)

Returns device by name. This name is unique device name. For example, "BallRoom:DVD_PLAYER1 ".

Parameters: name - Device name Returns: Device matching the specified name getDeviceList(PropertyFilter) public abstract org.ocap.hn.DeviceList getDevicel_ist( org.ocap.hn.PropertyFilter filter)

Returns devices that match all properties set by a given filter. Parameters: filter - Filter to select out devices from all connected devices

Returns: List of devices satisfying filter getlnstanceO public static org.ocap.hn.NetManager getlnstance()

Returns the singleton NetManager. This is the entry point for home network.

Returns: Singleton instance of NetManager getHNService(String) public abstract org.ocap.hn.HNService getHNService(java.lang. String name)

Returns HNService by name. This name is composed of unique device name and service ID. For example,

"LivingRoom:OCAP_HOST1 :Contentl_isting1 ", where LivingRoom:OCAP_HOST1 is the device name and ContentListingi is a unique servicelD within this device.

Parameters: name - HNService name

Returns: HNService with the specified name

HNService Declaration public interface HNService

All Known Subinterfaces: ContentManagementService, ContentServer, RemoteMediaRendererService, RemoteMediaStorage, RemoteRecordingManager, RemoteTimeShiftManager

Description HNService is an abstraction of functionality that is provided by a Device. It is a group of related actions. A HNService is always associated with a homenetwork Device. Application may monitor a HNService's status by subscribing as a listener to this HNService.

Fields

CONTENT_LIST public static final Java. lang. String CONTENTJJST A constant indicating content listing HNService.

CONTENT_MANAGER public static final java.lang.String CONTENTJΛANAGER A constant indicating content manager HNService.

CONTENT_RENDERER public static final java.lang.String CONTENT_RENDERER A constant indicating content renderer HNService. CONTENT_SERVER public static final java.lang.String CONTENT_SERVER A constant indicating content server HNService.

PROP_CONTROL_URL public static final java.lang.String PROP_CONTROL_URL

A constant providing URL for HNService control.

PROP_DESCRIPTION_URL public static final java.lang.String PROP_DESCRIPTION_URL A constant providing URL for HNService description.

PROP_EventSub_URL public static final java.lang.String PROP_EventSub_URL A constant providing URL for HNService event.

PROP_HNSERVICE_ID public static final java.lang.String PROP_HNSERVICE_ID A constant indicating HNServicelD.. Methods getDevice() public org.ocap.hn. Device getDevice() Returns the device that provides this HNService.

Returns: device that offers this HNService getKeys() public Java. util. Enumeration getKeys()

Returns the property keys supported by this HNService.

Returns: An enumeration of String object representing property keys for this HNService getHNServiceld() public Java. lang. String getHNServiceld()

Returns the id of this HNService, which is unique within the device. An example could be, ContentListingi . Returns: id of this HNService getHNServiceType() public Java. lang. String getHNServiceType() Returns the type of this HNService. The allowed types are defined as constant field in HNService, for example, CONTENT_MANAGER, CONTENTJJST.

Returns: type of this HNService getProperty(String) public Java. lang. String getProperty(java. lang. String key)

Returns the property value for specified key.

Parameters: key - specified property key

Returns: property value for specified key subscribe(HNServiceEventListener) public void subscribe(org.ocap.hn.HNServiceEventl_istener listener)

Subscribes to the event of this HNService. When HNService status change (version change, internal states change), HNService listeners will be notified. If listener has already been registered, then no action is performed.

Parameters: Listener - The listener to be notified when HNService event happens unsubscribe(HNServiceEventListener) public void unsubscribe(org.ocap.hn.HNServiceEventl_istener listener) Unsubscribe to the event of this HNService. If listener is not registered yet, then no action is performed. Parameters: listener - The listener to be removed from the HNService event listener pool

HNServiceList

Declaration public interface HNServiceList

Description A list comprising of homenetwork HNServices. The application may retrieve such a list from NetManager. getHNServices. The application may refine the list by applying a PropertyFilter.

Methods contains(Object) public boolean contains(org.ocap.hn. HNService element)

Indicates whether a service is included in this HNServiceList.

Parameters: element - the element to check whether it is in the list

Returns: true if the element is in the list; otherwise false. filterElement(PropertyFilter) public org.ocap.hn. HNServiceList filterElement( org.ocap.hn. PropertyFilter filter)

Applies a new PropertyFilter to this element list and returns a new list.

Parameters: filter - new filter

Returns: new element list generated by new filter

See Also: PropertyFilter getElement(int) public org.ocap.hn. HNService getElement(int index)

Returns the element indexed by a number. Parameters: index - specified index of the element

Returns: element indexed by the number getElementsQ public java. util. Enumeration getElements()

Returns all services in this HNServiceList in Enumeration. Returns: An enumeration of HNService elements indexθf(θbject) public int indexθf(org.ocap.hn. HNService element) Returns the index of an element in this element list.

Parameters: element - to be checked Returns: index of an element in this list. If there is no such element in this list, returns -1. size() public int size()

Returns the size of this list.

Returns: size of the element list

HNServiceChanqeEvent

Declaration public class HNServiceChangeEvent extends java. util. EventObject java. lang. Object

+--java. util. EventObject

I +-org.ocap.hn. HNServiceChangeEvent

All Implemented Interfaces: java.io.Serializable

Description

Entity for HNServiceChange event. Application can register to HomeNetwork to monitoring HNService change information.

Fields SERVICE_AVAILABLE public static final int SERVICE_AV AILABLE SERVICE_BUSY public static final int SERVICE_BUSY

SERVICEJ.OST public static final int SERVICEJ.OST

Constructors

HNServiceChangeEvent(int, Object) public HNServiceChangeEvent(int type, Java. lang. Object source)

Methods getSourceO public Java. lang. Object getSource()

Returns service which just changed

Overrides: getSource in class EventObject Returns: service which just changed getType() public int getType() Returns service change type

Returns: service change type

HNServiceChangeListener

Declaration public interface HNServiceChangeListener

Description HNServiceChange callback interface. When a HNService is added/removed/changed, system will call serviceChanged() method to notify listeners.

Methods notify(HNServiceChangeEvent) public void notify(org.ocap.hn.HNServiceChangeEvent event) Callback function for service change event. Callee will be notified when service change happens

Parameters: event - service change event

HNServiceEvent

Declaration public class HNServiceEvent extends Java. util.EventObject

Java. lang. Object +-java. util.EventObject

I +-org.ocap.hn. HNServiceEvent

All Implemented Interfaces: java.io.Serializable

Description

Entity for HNService Event. There are two types of HNService events: one that is generated by the NetManager when a HNService is added or removed from the home network. Application may register as a listener to NetManager to receive such events. The other HNServiceEvent is generated by the HNService itself when its internal state changes. Application should register as a listener with a particular HNService for such events. In both scenarios, the HNService that was the source of the event is returned. Fields

SERVICE_ADDED public static final int SERVICE_ADDED A constant indicating new service is registered to home network.

SERVICE_BUSY public static final int SERVICE_BUSY A constant indicating a service is busy and cannot respond to request now.

SERVICE_REMOVED public static final int SERVICE_REMOVED

A constant indicating a service is removed from home network. SERVICEJJPDATED public static final int SERVICE_UPDATED

A constant indicating a service is updated from home network.

STATE_CHANGE public static final int STATE_CHANGE

A constant indicating a service's internal status changed.

Constructors

HNServiceEvent(int, Object) public HNServiceEvent(int type, Java. lang. Object source)

Constructs a HNServiceEvent by specifying type and source.

Parameters: type - HNService change type, allowed type are defined in HNServiceEvent source - HNService where the change happens.

Methods getSourceO public Java. lang. Object getSource()

Returns service event source, which is always a HNService. Overrides: getSource in class EventObject

Returns: service event source

getType() public int getType()

Returns service event type, as defined in HNServiceEvent.

Returns: service event type

HNServiceEventListener

Declaration public interface HNServiceEventListener

Description HNServiceEvent callback interface. When a HNService is registered or removed from NetManager, or if the internal status of a HNService changes, then system will notify all registered listeners. Methods notify(HNServiceEvent) public void notify(org.ocap.hn. HNServiceEvent event) Callback function for HNService event. Callee will be notified when

HNService event happens

Parameters: event - HNService event

PropertvFilter

Declaration public class PropertyFilter

Java. lang. Object

+--org.ocap.hn. PropertyFilter

Description

The filter for (key.value) pair filtering mechanism. If a device or a HNService has same value on all of the specified keys, it is regarded as a match. Constructors

PropertyFilter(Properties) public PropertyFilter(java.util. Properties prop) Constructs a PropertyFilter object.

Parameters: prop - Initial properties for this Property filter

Methods accept(Object) public boolean accept(java. lang. Object element)

Checks whether an element is accepted by this filter, the element must be either HNService or Device. If a HNService/Device's properties share the same value as all properties from this filter, it is accepted and true is returned; otherwise, false is returned. Parameters: element - element to be checked against

Returns: true if the element is accepted by the PropertyFilter addProperty(String, String) public void addProperty(java.lang. String key, Java. lang. String value)

Adds a (key.value) pair to the filter. If the key is already in the list, no action is taken.

Parameters: key - new key which will be used for filtering value - value for the new key contains(String) public boolean contains(java. lang. String key)

Checks whether a key is in the list.

Parameters: key - key to be checked against

Returns: true if key is in the list; otherwise false removeKey(String) public void removeKey(java. lang. String key)

Remove a key from the filter, if the key is not in the property list, no action is taken.

Parameters: key - key to be removed from list removeKeys(String[]) public void removeKeys(java.lang.StringO keys)

Remove keys from the filter, if a key is not in the property list, it is disregarded; while others are processed as normal. Parameters: keys - keys to be removed from the list

Claims

CLAIMS What is claimed is:

1. A home networking framework for interfacing an application residing on a digital TV receiver with a home network environment having a plurality of network devices communicating in accordance with a network communication protocol, comprising: a digital TV middleware residing on the digital TV receiver that enables the application to access a digital transport stream received at the digital TV receiver; a home network manager residing on the digital TV receiver and operable to register the network devices in a registry, thereby enabling discovery of the registered devices by the application, where each network device may expose services residing thereon; the home network manager is further operable to register the services exposed by each of the network devices in the registry and enable discovery of the registered services by the application; a service interface having an application program interface for the application to the registered services; and a networking translator in data communication with the service interface and providing functionality for communicating with the registered services in accordance with the network communication protocol.

2. The home networking framework of Claim 1 wherein the networking translator is a plug-in software module downloaded onto the digital

TV receiver from the digital broadcast transport stream.

3. The home networking framework of Claim 1 wherein the networking translator is a plug-in software module downloaded to the digital TV receiver from one of the home network or a network outside of the home network.

4. The home networking framework of Claim 1 wherein registration of services exposed by a given network device is performed concurrently with the registration of the given network device.

5. The home networking framework of Claim 1 wherein the home network manager provides an application program interface for retrieving a list of registered network devices from the registry.

6. The home networking framework of Claim 1 wherein the home network manager provides an application program interface for retrieving a list of registered services from the registry.

7. The home networking framework of Claim 1 wherein the networking translator is configured to receive advertising messages from the network devices and communicate with the home network manager regarding the advertising messages, such that the home network manager registers the network devices based on the advertising messages.

8. The home networking framework of Claim 1 wherein the home network manager provides an application program interface that enables applications to monitor changes to the services registered by the home network manager.

9. The home networking framework of Claim 8 wherein home network manager is operable to monitor changes to the registered services and to send an event notification message to applications when a change in a registered service occurs.

10. The home networking framework of Claim 9 wherein the home network manager is operable to send an event notification message when a service is added or removed from the home network and when there is a change to an internal state of a registered service.

11. The home networking framework of Claim 1 wherein the service layer further comprises a service plug-in module operable to instantiate a service object for each registered service, wherein a given service object exposes a set of actions associated with a given registered service.

12. The home networking framework of Claim 11 wherein a given service object is adapted to receive parameters for the set of actions from the application and operable to pass the parameters to the networking translator.

13. The home networking framework of Claim 12 wherein the networking translator is adapted to receive the parameters from the given service object, the networking translator is operable to translate the parameters into network specific commands and communicate the translated parameters via the home network to the registered service of the network device.

14. The home networking framework of Claim 1 wherein the digital TV middleware is further defined as one of OpenCable Application Platform (OCAP), Multimedia Home Platform (MHP) or Advanced Common Application Platform (ACAP).

15. The home networking framework of Claim 1 is further implemented in a Java application environment.

16. A home network manager for interfacing an application residing on or downloaded to a digital TV receiver with a home network having a plurality of network devices communicating in accordance with a network communication protocol, comprising: a registry for storing information about the network devices and services supported by the network devices; a manager class that enables registration of the network devices in the registry and registration of the services supported by each registered network device; and a device list application interface that enables the application to discover the network devices registered in the registry.

17. The home network manager of Claim 16 further comprises a service list application interface that enables the application to discover the services provided by network devices registered in the registry.

18. The home network manager of Claim 17 further comprises a service change listener application interface that enables the application to monitor changes as to which services are registered with the home networking framework.

19. The home network manager of Claim 17 further comprises a service state listener application interface that enables the application to monitor changes to an internal state of a service registered with the home networking framework.

20. The home network manager of Claim 16 is further downloaded to the digital TV receiver via a broadcast transport stream received at the digital TV receiver.

21. A home networking framework for interfacing an application residing on a digital TV receiver with a home network environment having a plurality of network devices communicating in accordance with a network communication protocol, comprising: a digital TV middleware residing on the digital TV receiver that enables the application to access a broadcast transport stream received at the digital TV receiver; a home network manager that registers network devices and services support by the network devices in a registry, thereby enabling discovery of the registered devices and services by the application,

34 /Ss .i

^■vχi n% <-^■ wherein the home network manager is downloaded on the digital TV receiver via the broadcast transport stream; and a networking protocol translator adapted to receive a request for one of the registered services from the application and operable to formulate the request in accordance with the network communication protocol.