Ocap software architecture

Despite the variety of techniques described above, the prior art does not disclose apparatus or methods to efficiently implement application software such as that useful for ITV applications that can be adapted to work on any network-specific communication protocol.

This deficiency is particularly acute with respect to the HFC networks where different proprietary protocols exist for OOB communication with the head-end, and for certain Conditional Access functions. Accordingly, there is a need for an architecture and methods that enable registration of APIs, and provide mechanisms for applications to identify and use the appropriate APIs in any communications network regardless of its particular protocol s. Such methods and apparatus would ideally simplify application development by eliminating the need to generate code to take into account all possible network protocols, thereby reducing host device CPU and memory requirements.

Such methods and apparatus would also ideally provide software applications access to on-demand and encrypted services without having to know the details of the network specific protocol. The present invention addresses the foregoing needs by providing an improved methods and apparatus for operating network software. In a first aspect of the invention, a method of operating client equipment having at least one application associated therewith within a content-based network is disclosed.

The method generally comprises: providing a manager module adapted to manage a plurality of network-specific interfaces; registering at least one programming interface specific to said content-based network using said module; running said at least one application; and based at least in part on said registration, accessing said at least one programming interface with said application.

In one exemplary embodiment, the network comprises a cable network and the client equipment a set-top box or similar device adapted for residential use. The manager module is installed on the client equipment whether via download, installation at manufacture, or otherwise , and used to interface with the applications also running on the client equipment.

In a second aspect of the invention, a method of providing access to network-specific programming interfaces e. In one exemplary embodiment, the CPE comprises a Java-based software environment and a plurality of applications which are precluded from accessing each other's class files or instantiated objects.

The method comprises: providing an API manager within said CPE environment; providing a registry associated with said manager, said registry adapted to register a plurality of network-specific APIs; running at least one of said plurality of applications on said CPE, at least one of said APIs being required by said at least one application; and accessing said registry to obtain said at least one API.

In a third aspect of the invention, an improved storage device for use in a network is disclosed. The storage device generally comprises a medium adapted to store a plurality of data bits thereon, said data bits comprising a computer program, said computer program comprising an interface manager program, said interface manager adapted to run on a digital processor and further to: register one or more network-specific APIs within an associated registry; and interface with one or more applications requesting access to said APIs.

In one exemplary embodiment, the storage device comprises RAM or a mass storage device e. In a fourth aspect of the invention, improved CPE adapted for operation within a first cable network is disclosed. In one embodiment, the CPE comprises: an application which is substantially generic across a plurality of different networks; a manager module resident within a protocol stack of said CPE, said manager module being adapted to register APIs adapted for use within said first network; wherein said application can query said protocol stack for one or more of said APIs in order to communicate with another entity associated with said first network.

In another embodiment, the CPE comprises: a processor; a storage device operatively coupled to said processor; a monitor application running on said processor and adapted to control at least one function within said apparatus; an API manager adapted to manage one or more APIs; and at least one software application adapted to run on said processor; wherein said apparatus is configured to: i download at least one API from said first network; and ii selectively provide access to said API by said at least one software application using at least said manager.

In a fifth aspect of the invention, a method of operating a cable network having a plurality of client devices operatively coupled thereto is disclosed, the method generally comprising: providing an on-demand or conditional access capability within said network; providing an API manager on each of said plurality of devices; providing at least one on-demand or conditional access-related application for use on each of said devices; providing at least one network-specific API to each of said devices; and accessing said on-demand or conditional access capability from at least one of said client devices using said at least one application and said at least one API, said API manager controlling access to said API by said application.

In a sixth aspect of the invention, improved CPE for use in a network is disclosed. In one embodiment, the CPE comprises an OCAP-compliant device which is adapted to implement an API registration functionality, specifically comprising: receiving at least one application; receiving a plurality of files associated with the at least one application; and registering the API based at least in part on information contained within the plurality of files.

The files comprise class and data files that describe the classes associated with the API. The CPE is adapted to generate one or more classloaders upon signaling of the application with a descriptor in order to provide access to the shared classes of the registered API.

The descriptor contains the name of the registered API s that the application is requesting access to. In a seventh aspect of the invention, a software architecture adapted for use in a cable network is disclosed, the architecture generally comprising: at least one software application having substantially all network-specific programming interfaces and protocols abstracted therefrom; at least one network-specific programming interface; and at least one manager entity, said manager entity being adapted to run within the same software environment as said at least one interface and application, said manager entity registering said at least one interface and providing access thereto by said application.

In an eighth aspect of the invention, a method of conducting business over a network having at least one server adapted to interface directly or indirectly with a plurality of client devices is disclosed. In one embodiment, said method comprises: providing the ability to utilize selectively or conditionally accessible services over said network to a plurality of said users; distributing to at least some of said users a manager module adapted to interface with a plurality of applications, at least one of said applications relating to said services; providing at least one network-specific API adapted for use in providing said services; and providing said services to said client devices using at least said manager module, said at least one network-specific API, and said at least one application.

In a ninth aspect of the invention, a method of operating first and second networks so as to be able to use a common application in both is disclosed. A common version of the application is developed which has abstracted out any of the aforementioned APIs or protocols, thereby rendering it generic and useable in either network. The above and other features and advantages of the present invention are hereinafter described in the following detailed description of illustrative embodiments to be read in conjunction with the accompanying drawings and figures, wherein:.

Reference is now made to the drawings wherein like numerals refer to like parts throughout. Such content may be, for example, stored or temporarily cached on a server, or streamed directly from a source, and may be in response to a user-initiated event, service profile or configuration, head-end event, or otherwise.

For example, middleware may run on top of an operating system and platform hardware, and below applications. Such networks or portions thereof may utilize any one or more different topologies e. Accordingly, it is anticipated that MSO networks may have client devices from multiple vendors, and these client devices will have widely varying hardware capabilities.

Multiple regional head-ends may be in the same or different cities. The host device functionality may be integrated into a digital television DTV set. For example, a network agent may comprise a computer program running in server belonging to a network operator, which is in communication with one or more processes on a CPE or other device. The term includes a set of industry standards, which were introduced to help accomplish this goal via three key objectives to define the next-generation digital consumer device, encourage supplier competition, and create a retail hardware platform.

As such, the Opencable project has two key components: a hardware specification and a software specification. The hardware specification allows a receiver that can be sold at retail to provide interoperability. The software specification of the OpenCable project, called the OpenCable Applications Platform OCAP , solves the problem of proprietary operating system software by creating a common platform upon which interactive services may be deployed.

For example, ITV middleware makes use of application programming interfaces APIs to define how various applications running on a set-top or host device can be efficiently designed and operated within the set-top OS environment.

An API may be, for example, a standardized or commonly agreed-upon set of programming interfaces that can be used by applications to gain access to and execute various functionality within a particular computer system type.

This enables, inter alia, interoperable application creation for specific computer system types. The Open Cable Applications Platform OCAP is a software programming interface standard that provides a common middleware environment for applications to execute on different types of consumer devices that may be connected to different cable systems.

In one salient aspect, the present invention provides apparatus and methods to extend or complement an existing or standard programming interface set for items where the implementation is network-specific.

The invention may be useful, for example, with respect to Video On-Demand VOD programming interfaces, on-demand session startup interfaces, and conditional access CA interfaces, as well as in other applications. The functional blocks at the top of the stack of FIG. Native Applications are typically written for, e.

Examples of such Native Applications may include management of front panel functionality, remote control interaction, games, and the like. The details of a particular cable network that are relevant for the software to interoperate are also represented in the exemplary stack of FIG. The present invention is perhaps best understood in the context of the OCAP software specification architecture, although it will be appreciated the invention is by no means limited to this particular context.

The modules in the exemplary configuration have been arranged in three groups. This includes for example the Executive Module , and may also include other modules such as the Closed Captioning Module The Executive Module performs the task of discovering, loading, authenticating and launching the Monitor Application that is provided by network operator to all host devices wanting to attach to the network.

A second set of application modules is shown in the bottom row of FIG. These applications share the collective property that they operate by performing registration through the Monitor Application.

Examples of this type of module include a Watch-TV application which allows channel changes to view television program, a CableCard Resources Module that allows access to certain CableCard resources, and an Emergency Alert Module that is responsible for processing and displaying any emergency messages present in the incoming signals. The third set of modules in the illustration of FIG. Alternatively, a third-party application developer can incorporate the applications with in television programs or out-of-band signals received by the CPE.

The OCAP specification defines steps taken when launching an application, including application authentication, application registration and application persistence. As will be described in greater detail subsequently herein, one exemplary embodiment of the programming interface registration method of the present invention is advantageously designed to use these same steps, therefore minimizing impact on the existing OCAP code base.

The OCAP specification does not require that the Monitor Application be deployed; however there are significant commercial and operational reasons why it should be. In addition, it is likely that a large proportion of unbound applications will require digital signature to activate permissions. A key aspect of OCAP-based host device functionality is the retail availability of these devices. A consumer or other user should be able to obtain such a host device in the retail market or via another channel, and be able to use it successfully to receive cable television programs or services, without having to attend to cable network-specific details, and without having to get assistance from MSO technical support.

In other words, the installation and operation as it relates to network-specific aspects should be completely transparent. The manufacturer of the host device will typically provide all software for the host device needed to perform basic operations. Cable operators are expected to provide a software application Monitor Software on their networks that can be used to provide network-specific look and feel to a host device that is connected the cable network. As previously described, software authoring entities developing modules without prior knowledge of which cable network the host device will be deployed in and hence which network-specific protocols and other requirements that it must be compatible with must ensure that the module s will work uniformly for all cable network protocols.

Additionally, the software developer simply may not have access to all necessary details of each particular cable network. A better solution is to offer a common interface between the network-specific protocols and the applications needing to utilize the protocols.

This can be achieved for example by a software module or other entity that registers the relevant programming interfaces and in effect advertises them to each application wanting to use these interfaces. One salient benefit of a common API is that it can be shared by multiple applications across networks. A related subtle yet significant benefit is also provided; i. This benefit is magnified where the host device may potentially be introduced into a large number of heterogeneous networks; even a modest code savings for a large number of applications can be quite significant when considered in the aggregate.

Furthermore, such API designs can be made public, or even standardized. For APIs based on communications protocols, the API can be made protocol agnostic if desired, and ported to multiple systems, thereby allowing manufacturers the freedom to determine implementation-specific details.

Reusable modules can also be created for registered API use, and integrated into various applications. Such software modules are described in greater detail subsequently herein. The present invention also addresses the fact that while the CableCard or similar interface is used to abstract a conditional access CA system, there may be additional network protocols that require an abstracted API in order to provide true interoperability.

One exemplary embodiment of the API handler comprises a separate software module that is downloaded or otherwise distributed to the CPE and that will register the implementation of a specific programming interface e. Applications will then have the ability to query the OCAP stack to determine if a specific API implementation is available, and then use that interface if it is available.

For example, a purchase transaction library could be registered that allows any unbound applications that provide consumer purchase interaction to use the same API to complete purchase transactions with a head-end or other network agent. This not only increases flexibility, but also reduces the overhead associated with the multitude of different applications which may be run on any given CPE within a given network.

In another embodiment, a registered API including associated class and data files is delivered with a privileged application. The privileged application registers the API using a modified version thereof. Classes that need to access the registered API must be signaled with an appropriate descriptor e. The descriptor contains the name s of the API. An application can also query what registered APIs are available, but access to those APIs is granted only when the application is first started.

Exemplary embodiments of the methods and apparatus of the invention are now described in detail with reference to FIGS. Myriad other variations are possible.

It will also be appreciated that while described generally in the context of a residential or home ITV application domain, the present invention may be readily adapted to other types of environments e. Myriad different distribution or delivery paradigms will be readily apparent to those of ordinary skill given the present disclosure.

The various components of the network include i one or more data and application origination points ; ii one or more application distribution servers ; iii one or more VOD servers , and iv consumer premises equipment CPE A simple architecture comprising one of each of the aforementioned components , , , is shown in FIG.

For example, the head-end architecture of FIG. The application origination point comprises any medium that allows an application such as a VOD based application as well as the downloadable handler module described subsequently herein, to be transferred to a distribution server This can include for example an application vendor website, CD-ROM, external network interface, mass storage device e.

Such transference may be automatic, initiated upon the occurrence of one or more specified events such as the receipt of a request packet or ACK , performed manually, or accomplished in any number of other modes readily recognized by those of ordinary skill. The application distribution server comprises a computer system where such applications can enter the network system. Distribution servers are well known in the networking arts, and accordingly not described further herein. The VOD server a computer system where on-demand content can be received from one or more data sources and enter the network system.

These servers may generate the content locally, or alternatively act as a gateway or intermediary from a distant source. The DNCS responds with negative or positive response to the request, and the VOD server implements the appropriate resource allocation logic, such as that described in co-pending and co-owned U.

It will be recognized that other topologies of the bearer network may also be used consistent with the present invention, such as for the multi-server architecture described in co-pending and co-owned U. Patent Application Publication No.

Such CPEs comprise processors and associated computer memory adapted to store and run the downloaded or resident application, as well as receive the streamed in-band content. In the present context, at least a portion of the API handler module is downloaded to the CPE , wherein the latter installs and utilizes the downloaded module s.

Referring now to FIG. As shown in FIG. It will be appreciated that while a bar or bus LAN topology is illustrated, any number of other arrangements as previously referenced e. Furthermore, the head-end configuration depicted in FIG. The architecture of FIG. In the present context, the distribution servers are coupled to the LAN , which provides access to the MEM and network via one or more file servers As previously described, information is carried across multiple channels.

Thus, the head-end must be adapted to acquire the information for the carried channels from various sources. Content e. The OCAP specification provides for networking protocols both downstream and upstream. Many other permutations of the foregoing system components and communication methods may also be used consistent with the present invention, as will be recognized by those of ordinary skill in the field. As described above, one embodiment of the present invention provides inter alia a software module adapted to perform authentication and registration of various APIs within a middleware protocol stack, such that the appropriate programming interface is made available to an application or other entity seeking access to it, and having permission to use it.

This approach also contemplates the complete life cycle of such a programming interface; i. However, loading of a registered API can be highly implementation specific. The typical trade-off in such cases is between speed and memory; loading all registered APIs regardless of whether another application is using the API will require more run-time memory, but might result in faster software response when applications that use these APIs are launched.

Static classes and attributes are, in the illustrated embodiment, made local to each application logical VM. A registered API implementer can use various communication mechanisms such as inter-Xlet communications IXC to share objects and primitives. This approach can substantially simplify IXC object and application upgrades.

The exemplary module is implemented as a class for the org. This class contains the methods; register and unregister. The XAIT in this case does not represent unbound applications, but instead represents a collection of classes that make up the API being registered.

This approach advantageously allows for the authentication of a registered API in the same fashion as that of an application. Descriptor usage for a registered API is somewhat different than for an application, and is described further herein. In the illustrated embodiment, the RIIM is responsible for authenticating and loading classes that are registered as a registered API by a privileged application. The classes are loaded such that any application launched after the registered API is registered will have access to it.

Any static objects or attributes in a registered API are local to the logical VM they were created in. Classes in a registered API may make calls to any implementation API to which it has access to and for which it has permission. A registered API may also be signed in the same fashion as an application if desired.

A registered API may also contain a permission request file. The OCAP Permission Request File comprises an extensible markup language XML file, although it will be apparent that other files types and formats may be used consistent with the invention, the foregoing form and compatibility adaptations being merely illustrative of the broader principles.

In the illustrated embodiment of the module , the org. The register method takes a java. InputStream parameter, and the InputStream parameter is passed to the org. However, a registered API is in the illustrated embodiment signaled in similar fashion to an Xlet, with the exception of certain attributes described below. While use of an Xlet-like signaling paradigm provides certain advantages, it will be appreciated that other signaling methods may be substituted therefor.

The exemplary XAIT for a registered API contains the following descriptors: i a routing descriptor, ii a pre-fetch descriptor, and iii a DII descriptor, although it will be appreciated that other descriptor architectures including additional descriptors may be used if desired.

For storage purposes, a registered API has the same specification as an application that was registered by a privileged application, although other approaches may be substituted. When the host device detects that it has been moved to a network other than the network where the registered APIs were first registered, these registered APIs associated with the previous network may be removed from persistent storage in order to make room for new APIs associated with the new network.

Additionally, various schemes for removal may be used, including for example i complete and unconditional removal of the registered APIs from the previous network; ii conditional removal according to one or more criteria e. In any interactive TV receiver, there are a number of core functions that must get carried out as part of the general housekeeping within the receiver.

These include things like resource management; parsing application signalling and launching or killing applications; and managing security functions by updating certificates and checking permissions. While these functions may not be glamorous how many times have you impressed someone by telling them you wrote an application manager?

A monitor application is an unbound application which has special privileges in the receiver, and which is provided by the network operator. Typically, only one monitor application is available on the at a time. An OCAP receiver can contain several special applications which carry out various functions within the system. The most common of these will probably be the application that handles messages from the Emergency Alert System. This is a system that is required in US digital cable systems for transmitting information to viewers during national or regional emergencies such as natural disasters.

This may either display messages as an overlay on the screen, or it may force tuning to a specific service in order to display the messages. Given that every receiver must support this service, this functionality may be included in the monitor application.

By default, handling of Emergency Alert System messages is carried out by a module in the Execution Engine that can be replaced by other applications. See the discussion of the OCAP software architecture for more details of this. While MHP acknowledges native applications, they are handled completely separately from downloaded applications.

The differences in an OCAP receiver — especially the presence of a monitor application — mean that interoperable applications must be able to manipulate and control native applications. Since there is no navigator software than can know about built-in applications, they can only be started via the monitor application. This means that native applications must have an OCAP-compatible interface, so that they can be controlled from the monitor application.

It also means that any changes in their state such as terminating must be reflected back to the monitor application. This can be handled by having a simple OCAP application that acts a a Java wrapper for the underlying native application. In order for a receiver to know about any applications that can be run, it somehow needs to be told that they are there.

This provides a way for receivers to find out about applications that are bound to the current service and which can be started. As we have seen, an OCAP receiver can also run applications which are stored in the local storage of the receiver or which are not bound to any service stored applications and unbound applications, respectively. This is an XML file that can be delivered to the receiver in a number of ways, either over the broadcast channel or over the return channel, and which describes applications that are not bound to a given service.

The XAIT contains information about unbound applications, system applications and the monitor application. Like MHP, the OCAP middleware in the receiver contains a component called the application manager that is responsible for monitoring the current services and starting or stopping applications.

Unlike an MHP receiver, however, this application manager does not have complete control over what happens to applications in the system. The application manager in an OCAP receiver manages a database of all available applications — including native applications, stored applications and those which are not bound to any service.

When the receiver notices that application signalling has changed or in some cases, when applications have been registered — see the application signalling tutorial for details of how and when this happens , any new applications are loaded into the application database and any applications not present in the current signalling are removed.

Applications are given a control code as part of the signalling. This tells the receiver what action should be taken for that application. The three most common and useful control codes that we are likely to encounter are:.

The application manager uses these control codes to decide what to do with an application. If an application is signalled as auto-start, or if the user chooses to start an application, the application manager will query the monitor application if one is registered to see whether that application is allowed to run.

If the monitor application allows the application to be run, then the application manager starts it and manages its state as it runs. In the case that application signalling tells the receiver to kill an application, the application manager is the one to do that. In this case, the monitor application has no influence — it can not stop a particular application even itself from being killed.

The monitor application does have one final way to influence the application manager, however. It can choose to register new unbound applications with the application database. Once registered, these applications can be started and controlled just like any other application. The monitor application can also unregister applications that it has registered, removing them from the application database as if their signalling had been removed which, in effect, it is.

Once an application is entered into the application database, it will go through a number of states. These are shown in the state diagram below:. At this point all of the necessary classes to start the application have been loaded, and the main class of the application has been created and initialised, but the application is not actually running yet. An application in this state is running normally and is interacting with the user and may be using scarce resources.

All of the class files and content associated with the application are removed from memory, any scarce resources are reclaimed and the application is back where it started from.

Partly, it allows the network operator to enforce common behaviour across receivers. In an MHP system, two different receivers on the same network may behave differently when resolving a resource conflict between two applications. This allows the network operator to make the user experience as close to identical as possible, no matter who built the receiver. If all boxes on a network are running the same monitor application, you know that the behaviour will be identical in those areas that the monitor application has responsibility.

There is another part to this, of course. Controlling the monitor application also gives the network operator more control over the receivers, and takes some of the control away from the receiver manufacturer. From the point of view of the network operators, this makes some sense in that it allows them to give their brand more exposure to the customer and provide another way to help them sell premium services. Resource arbitration. In MHP, two receivers on the same network may resolve a resource conflict in different ways.

Two OCAP receivers that share a network will resolve the conflict in the same way, but a receiver on one network may resolve the conflict in a different way to the same receiver on another network. This has advantages and disadvantages, but it does mean that the user sees more consistent behaviour from receivers on the same network.

Application registration. This allows other applications to control unbound applications should they wish to do so and should the monitor application allow them. Application validation. Before any application can be started, it must be validated by the monitor application. This enables the network operator to keep tight control over what applications get started and when. We will talk about the process of validating applications later in this tutorial.

Error handling. This provides a general mechanism for handling certain types of general errors, such as out of memory errors, where the network operator can decide to implement a standard way of handling them.

Why is this useful? Software upgrades. The monitor application has the ability to store applications in the flash memory of the set top boxes, and to upgrade these stored applications. Typically this will get used by the network operator to make sure that any unbound applications provided by the network operator are up-to-date and will load quickly.

Since the monitor application is itself an unbound application, it can upgrade itself in the same way. User input event handling.

Before any other application has access to user input events, they will pass through the monitor application. During this process, the monitor application can choose to modify them or even block them completely.

This allows applications to receive a common set of user input events for all keys on the remote control, even those not standardized by OCAP. The monitor application can choose how keys are mapped across remote control units, and even whether certain keys have any effect at all.