WO2006122024A2

WO2006122024A2 - Open architecture for internet protocol television

Info

Publication number: WO2006122024A2
Application number: PCT/US2006/017716
Authority: WO
Inventors: Eddie Drake; Satish Annapureddy; Hans Wald; Tom Cezeaux; Weihong Xie; Shyan-Ming Perng; Sagar Gordhan
Original assignee: Nokia Siemens Networks Gmbh & Co. Kg
Priority date: 2005-05-10
Filing date: 2006-05-09
Publication date: 2006-11-16
Also published as: WO2006122024A3

Abstract

An embodiment of the present invention adopts a modular client and server architecture to accommodate the needs of large broadband service providers (BSP). It will evolve the current monolithic software platform to a modular architecture based on the Open Services Gateway (OSGI) model, which supports a standards-based application service framework. This service framework allows the development, secure distribution, event collection and life cycle management IPTV applications to the client without requiring a software build. Customization of applications would be inherent in the design. BSPs would be provided a mechanism to manage and entitle applications, which are deployed on their networks.

Description

Open Architecture for Internet Protocol Television

BACKGROUND OF THE INVENTION

The present invention relates to internet protocol television, and more particularly, to an improved architecture for internet protocol television.

As large operators enter the IPTV market place, the requirements on software of the type provided by Myrio Inc.'s (Myrio) are subsequently changing. Among other requirements, BSPs are requiring the following:

1. An open standard architecture that evolves to meet new requirements and adopts new technologies or standards.

2. The ability to customize the look, feel, function and navigation of existing and new applications to create a seamless, branded environment for their customers.

3. Leverage emerging ITV standards and subsequent applications delivered on those standards in the cable and satellite industries including Open Cable Access Platform (OCAP), Multimedia Home Platform (MHP), and Open Service Gateway (OSGI) among others.

4. Support a secure framework, which provides an application management environment where applications from different vendors can co-exist, be loaded and unloaded dynamically.

5. Provide an entitlement framework that allows them to control which applications and content are deployed and consumed on their network. 6. Expand service coverage to devices other than TV set-top boxes. Provide interconnection and interoperability with other service devices within the digital home (PCs, Home automation and security systems, WAN Gateways, etc.). Support emerging home networking standards.

An embodiment of the present invention adopts a modular client and server architecture to accommodate the needs of large operators. It will evolve the current monolithic software platform to a modular architecture based on the Open Services Gateway (OSGI) model, which supports a standards-based application service framework.

This service framework will allow the development, secure distribution, event collection and life cycle management IPTV applications to the client without requiring a software build. Customization of applications would be inherent in the design. BSPs would be provided a mechanism to manage and entitle applications, which are deployed on their networks.

In 2001 , Myrio was the first company to standardize on the Sun Microsystems Java platform for use in IPTV middleware. At that time, however, support for video-related applications within the Java framework was immature. Versions 2 and 3 of Myrio's software were based on the proprietary implementation of Myrio's IPTV application framework.

With all of the advantages to using a technology like Java, there are still some obstacles to overcome to provide the type of functionality that BSPs require. Over the past several years, application service frameworks have been developed on top of the Virtual Machine in order to provide a horizontal platform base for others to easily add additional functionality and services.

These frameworks are deployed in a number of environments including cable and satellite set-top boxes, mobile phones, automobile and telematics systems, embedded appliances and residential gateways. The nature and use of the devices require a portable, continuous computing environment, which provides a modular framework for distribution and execution of applications, sometimes from various parties. This type of framework is ideal for the IPTV space, which has very similar application execution and management requirement. Three such frameworks that have been successfully deployed are MHP, OCAP, and OSGI.

Each of the framework types listed above may ultimately need to be addressed within Myrio's middleware implementation as we anticipate applications being written for each that BSPs will wish to deploy. OSGI however, has been selected by Myrio as the base framework. It is one of the most widely adopted java-based application servers across many types of networked devices including:

^■ Digital mobile phones

^■ Automotive

^■ Telematics

^■ Embedded appliances

^■ Residential gateways

^■ Industrial computers - Desktop PCs

■ High-end servers, including mainframes

Therefore, OSGI cuts across many of the devices that will ultimately peer with the set-top box within the digital home. Interoperability between devices, peering and shared services will become a reality as the set-top box in the home is able to interface at a common layer with other devices in the home.

Building on the success of their Vehicle Experts Group, the OSGI alliance recently launched the Mobile Experts Group to focus on standardization of middleware applications onto mobile handsets. Focussing on a Java 2 execution environment and the new profile Connected Device Configuration (CDC), companies like IBM and Nokia have launched OSGI- based product such as the Nokia 9500 communicator. The Siemens SmartHome solution uses OSGI as a base application framework to tie together home automation, home security, entertainment and home comfort systems. BMW representatives recently discussed how implementing OSGI on their in-car Assist Services systems have allowed greater integration between their cars and BMW Online. Companies like Siemens, Mitsubishi, Samsung and Sun are all providing certified OSGI solutions today for various markets.

OSGI is ideally suited as a cross over, base-service framework for IPTV. As devices move closer to convergence, we see OSGI as the standard through which those devices will interact. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram illustrating the previous IPTV architecture.

Figure 2 is a block diagram illustrating the new IPTV architecture.

Figure 3 is a functional diagram illustrating one possible structure of a video on demand application.

Figure 4 is a functional diagram illustrating scripting registry function acting as a set of JavaScript statements that perform a task.

Figure 5 is a diagram illustrating a simple layout which incorporates the HTMS/JavaScript skin, and plugins which show through the skin.

Figure 6 is a flow diagram illustrating the process involving entitlement of applications deployed on a BSPs network, secure transmission of those applications to the client, and event and transaction collection.

DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE INVENTION

Glossary of Terms and Abbreviations

It is assumed that the reader has a technical understanding of Myrio's current 3.x architecture, and in describing the embodiments of this invention, references will be made to Myrio's architecture.

There are 4 primary areas of functional change in the architecture of the embodiment of the present invention:

1. Myrio Interactive™ will be adapted to the new service framework. The current monolithic application will be broken down into logical packages of functionality, which will execute within the service framework. These packages of functionality will be referred to as "bundles." Bundles may be applications (application bundles) or they may provide infrastructure functionality (infrastructure modules). Functionality already provided as a standard part of the service framework will be leveraged. The MyrioiDK porting layer will be modified to accommodate the new service framework, however the impact to MyrioiDK licensees should be minimized at the native layer where possible to ensure rapid porting. The fundamental data format and data handlers on the client will be altered to support a more robust mechanism for data storage. An embedded database management system (DBMS) will be established to provide a better data management infrastructure on the client that can be utilized not just by Myrio's applications, but by third party applications. It is anticipated that this client database will be able to more adequately handle larger amount of data as more services are added, but also provide higher performance access to the data.

2. The Multicast Messaging and Data Distribution Framework (MMDDF) will be leveraged as a secure distribution mechanism to deliver applications and software updates created by Myrio, the BSP or third parties. The format of the files transmitted by the MMDDF may be altered in order to take better advantage of the new data storage capabilities of the client.

3. A layered security model will be adopted including the use of digital signatures for authentication of bundles; secure download mechanisms will ensure authenticated distribution of data; and an entitlement and policy framework will be developed within TotalManage allowing the BSP to control the execution of all applications entering the network.

4. Event and Transaction collection APIs will be provided allowing the BSP to unify billing and event data from all applications.

In addition to these areas of modification to our current product, an application development kit will be created and provided in order to facilitate application creation within the new framework. The kit will be based on off-the- shelf software production tools and standards. An application customization component will be supplied which will allow BSPs the ability to customize the look and feel of Myrio-supplied applications as well as define the look of their own applications.

Because there are many different standards being employed for application development and distribution within a video network, there are four types of applications that a BSP may encounter when deploying video. Each of these applications must be managed and entitled.

• Application bundles created by Myrio using the OSGI standard. These include new infrastructure as well as application-level functionality

• Application bundles created by the BSP using the OSGI standard and/or supplied Myrio toolkit components

• Application bundles created by third parties (using the OSGI standard and/or supplied Myrio toolkit components) which are deployed by the BSP

• Service-bound or other applications, which are delivered out of band to the BSPs distribution network (e.g. MHP or OCAP applications embedded within an Mpeg-2 transport stream). These applications typically employ MHP, OCAP or a proprietary framework

Each of these applications must co-exist and be managed within the client execution environment. Because service-bound applications require native layer support, and therefore would require changes or additions to the current native layer definition within the MyrioiDK support for service bound applications will be provided in subsequent releases.

Referring to Figure 1 , Myrio Interactive is currently executed as a single Java package or archive (.jar) in the legacy 3.x architecture. All applications and infrastructure functionality are contained within this single .jar file. A .jar file is a collection of resources (Java class files, applets, graphics, sound files, etc) bundled together forming a Java application. There are two .jar files which makeup Myrio Interactive - one provided by Myrio, the other provided by a third party supplier, Espial:

The Espial Escape™ Web browser, licensed separately by the MyrioiDK licensee, is integrated with Myrio's client application and executes side by side. These two apps form the basis for the services deployed in the 3.x architecture. While the functionality is rich in scope, there are inherent disadvantages to such an approach:

1. Customization is cumbersome. Layout files describing the look and feel are part of the code for the functionality of the feature. While the layout files are easy to modify using a Myrio-supplied customization tool, it is a proprietary approach to customization, which doesn't easily apply itself to an application creation environment. A radically different approach will be undertaken in order to provide dynamic customization of Myrio's applications as well as third party applications.

2. Additional application required must be built into either Myrio's or Espial's .jar files. Beyond this, resource contention becomes a problem - there is no mechanism to manage additional applications and ensure that lower level resources are properly managed.

3. Remote updates of components require a restart of the Java client in order to execute which causes an interruption in service.

4. Source control and build management must be centralized through a common source control system. This makes distributed development difficult and build integration becomes a large process in order to procedurally ensure interoperability of all components.

The new architecture addresses the above issues. In order to adapt Myrio Interactive into the new framework, the application must be subdivided into individual components. As discussed previously, major component areas include application and infrastructure. These components will then be subdivided into individual functional bundles. Each bundle will provide a set of services, which will be published as application programming interfaces (APIs) to a service registry. The registry will describe the service functionality available to any other application bundle deployed into the service framework.

A high level diagram of the client stack diagram is shown in Figure 2.

In order to modularize Myrio's software, there must be an underlying framework that manages the interaction of the various components. Myrio has chosen the Open Services Gateway (OSGI) revision 3 (revision 4 when available) application management framework to be the base framework for IPTV client middleware. The Java Virtual machine API support will also need to be expanded. The JVM for the new architecture will be based on the Java 2 profile, CDC/PBP 1.1. PBP 1.1 is based on, and includes, CDC 1.1 and FP 1.1. The profile for the JVM is based on J2SE 1.4. That is, all the API's present in CDC, FP, and PBP that are in common with J2SE will be the same as the definitions found in J2SE v.1.4.

In the stack diagram above, all components in lighter gray (porting layer up) may be supplied by Myrio as part of a complete package in order to ensure maximum interoperability and support for vertical applications. However, individual components (such as the Java Virtual Machine) may be sourced separately. Part of the new architecture deliverable will be the updated requirements specification for the Java Virtual Machine and OSGI layers.

Myrio will also undertake an analysis of current and emerging Java standards that may be applicable to the new software architecture and where possible, replace Myrio proprietary implementations with these standards. Some relevant standards are listed here. More detail can be found in the Myrio Module Analysis Document [3]. ^■ Java packages contained in CDC/PBP 1.0/1.1

^■ Advanced graphics such as AGUI (JSR Proposal 209) [6]

^■ MHP-based standards

o JavaTV

o Java Media Framework (JMF)

o DAVIC

o DVB

o HAVI

The framework itself supports dynamic loading and unloading of bundles and management of resources required by each bundle. This is a critical requirement in supporting third party applications. It also enables decentralized development of individual bundles. No longer would it be required to build a single .jar file containing all of the functionality. This is a distinct advantage over other applications written in C, C++, or other proprietary languages.

When bundles are deployed into the client environment, the framework takes over and manages the lifecycle of the application. In this way, applications can be created as permanent applications or ones that expire based on some external parameter. For example, an application can be developed and deployed to execute only during a particular event that is being broadcast is viewed, and then remove itself once the event is over.

Once a bundle is installed, it deploys an "activator" component, which provides initialization and devitalization functionality. Once activated, the bundle receives a context object that gives it access to the service framework and the service registry according to the policies and entitlements provided by the BSP.

Each functional bundle can then be acted upon in the following manner:

1. Install - This process installs a bundle into the framework. An installation does not affect other running applications.

2. Start/Stop - Starting a bundle makes certain resources available while stopping a bundle will clean the resources up. Only a single instance of the Java virtual machine is required where all applications execute.

3. Update - Updates of bundles occur once it has been stopped and resources cleaned up. The bundle is then unloaded and replaced with a newer version. It is then restarted. It is not required that the Java virtual machine restart in order for an update to take place.

4. Uninstall. - This occurs at the end of the bundles lifecycle. The code is removed from the system and resources freed up.

Installed bundles are then able to publish functionality to the service registry for other bundles to use. See Sharing Resources below.

An additional advantage of the service framework is the ability of bundles to contribute services into the environment for other applications to use. In a closed environment, every application must carry with it its own resources, even if those resources are present in other areas of the software environment. Even many of the Java application service models employed today are closed in this fashion including J2EE, MIDP and JMX. The OSGI service framework employed in the new architecture will allow bundles to publish, find, and bind services inside the JVM using the service registry. From the OSGI Alliance Web site:

The service registry provides a cooperation model for

bundles that takes the dynamics into account. Bundles

can cooperate via traditional class sharing but class

sharing is not very compatible with dynamically installing

and uninstalling code. The service registry provides a

comprehensive model to share objects between bundles.

A number of events are defined to handle the coming and

going of services. Services are just Java objects that can

represent anything. Many services are server like objects,

like an HTTP server, other services represent an object in

the real world, for example a Bluetooth phone that is

nearby.

(h ttp ://www. osgi. org/osgi_ technology/index, asp Psection

=2)

More detail on the OSGI service registry can be found in the paper Listeners Considered Harmful: The "Whiteboard" Pattern Technical Whitepaper. Rev 2 17 Aug. 2004 OSGI Alliance (www.osgi.org).Th\s model vastly simplifies the ability to create new applications that use pre-existing functionality as well as saving space on the STB because common elements will only need to exist in on place. In order to fully facilitate the sharing of functionality-effectively class sharing-the service framework will need to manage how a class or a group of classes (package) are loaded. Classes are the executable part of the bundle. As explained, every bundle can export and import packages within the service framework. Thus, the service framework will provide a method to elect which classes will be used by all bundles that need access to those classes.

Using class version control, the framework ensures the latest class libraries are used by each bundle that has imported them, unloading the unused classes. The OSGI version 3 framework has a more mature implementation of version control. Additional detail can be found in the paper About the OSGI Service Platform Technical White Paper. Rev 3. 12 July 2004 OSGI Alliance (www.osgi.org).

There are three types of bundles comprising the services provided by Myrio Interactive:

1. Application Bundles

2. Infrastructure Bundles (referred to as Modules.)

3. Standard Service Bundles

Application bundles are the specific vertical applications developed by the Myrio Application Development Team. In the new architecture, the user experience with respect to each application bundle will look and feel much the same way that it does in 3.0. However, the infrastructure will be radically different allowing the ability to change the look and feel of the features if desired. As mentioned, in the first release of the new architecture, all of the application functionality will have feature parity with Myrio's latest release 3.7 Pyrenees.

Each application bundle will represent individual features such as:

1. Digital Television with Guide and Pay-per view service

2. Main Menu Provides a central location for applications to link to within the Ul for access.

3. Media Menu and link to walled garden and Web content

4. Music This is the current DMX/MusicChoice linear broadcast music feed

5. OnDemand Content This application bundle may be subdivided as needed, but includes VOD, SVOD, FOD, and other content service which utilizes Myrio's content meta-data management system.

6. Online Help

7. Phone CallerlD and other Class service applications.

8. Promotion

9. PVR Client and network-based PVR control and meta data management

These bundles utilize APIs provided by both Myrio infrastructure Modules, as well as Service Framework Bundles.

Formerly known as the Myrio Client Application Platform (MCAP), Myrio Infrastructure bundles provide the core functionality for applications (hence infrastructure Bundles are referred to as Modules). The following list describes a subset of available bundles.

1. Audit Viewer Record (AVR) Module - Transmits collected event data to a well-known port on the application server.

2. Client Environment Module - Provides a layer of abstraction for the application bundles so that they can read and write platform/OS-level settings and configuration information without needing to know the specifics of how the information is stored or managed on the specific platform. The kinds of information to which it would provide access would include network configuration, hardware/software version, video decoding configuration (e.g. modulator, aspect ratio, and PAL/NTSC), and persistent settings. The Client Environment Bundle would also provide access to the keystore for authentication purposes (virtual smart card).

3. Conditional Access (CA) Module - Myrio provides support for many different content-encryption schemes from different vendors such as Verimatrix, Widevine, etc. The CA bundle abstracts the media player from the details of the particular content encryption/DRM scheme used for a given piece of content by managing the content decryption process. It routes the encrypted content to the appropriate decryption module based on the encryption scheme used. It also allows for installing and upgrading new content encryption schemes and removing any scheme currently installed without a reboot. 4. Datastore Module - Provides general purpose data warehouse for storage of meta data or other persistent data

5. Debug / Test Automation Module - Enabling this module allows a developer to connect test automation systems or a field technician to troubleshoot field problems by capturing stack traces and other state information.

6. Download Module - Manages requests from applications to download specific data. Provides an abstraction between the requesting bundle and the actual transport utilized.

7. EAS Module - Receives events from the Session Announcement Manager and provides alert notification to other application bundles via API

8. Key Event Input Module - Receives events from the Java Virtual Machine from input devices such as remote controls or keyboards. Provides mapping function between the native key events and application specific events.

9. Media Player Module - Abstracts control from the Media Player provided by the STB vendor or integrator. Handles both Unicast, Multicast and Broadcast (satellite, terrestrial, etc) media player control.

10. Monitor Bundle Module - Primary permissions, policy and entitlement module. BSP-controlled bundle which executes with all privileges. Manages the loading and unloading of other bundles within the service framework. Receives entitlement and policy information from TotalManage and enforces execution of applications accordingly.

11. Mpeg Section Data Handler - Receives information from the Mpeg2 section parser such as closed caption, digital music TTA, service bound and unbound application identifiers, etc. and makes the information available through APIs.

12. Multicast Data Carousel Client (MDCC) Module - Available in a subsequent release, provides inbound APIs that handle requests for data multicast from the download manager.

13. Object Carousel Module - Reads hierarchical file structures from DSM- CC object carousels embedded in MPEG-2 TS.

14. PIN Module -Stores personal identification numbers. Participates in the authentication of STBs.

15. Real Time Streaming Protocol (RTSP) Module - Provides RTSP communication with various VOD servers; changes RTSP dialects according to VOD server types present; provides failover functionality between VOD server types.

16. Session Announcement Module - Joins a well known multicast group and collects session announcement transmissions from TotalManage. Publishes messages via APIs

17. Subscriber Data Module - Interfaces to the TotalManage subscriber information database, stores information about the subscriber and publishes this information through APIs 18. Transaction Module - Collects transaction events from application modules through APIs which will be transmitted to TotalManage for consolidated billing.

19. User Interface Toolkit Module(s) and rendering engine - Contains widget sets, font controls, color palette, and access to drawing surfaces to change the look and feel of existing Myrio applications. Can be used to author the look and feel of new applications.

Standard service bundles are provided as part of the service framework and are stock or slightly modified to enhance functionality for an IPTV environment. For the purposes of this section, the standard OSGI standard services are examined. Descriptions of the specific functionality for each of the following may be found in the paper About the OSGI Service Platform Technical White Paper. Rev 3. 12 July 2004 OSGI Alliance (www.osgi.org).

1. Framework Services

a. Permission Administration -Resources in the environment (other than services provided by other applications) that the application can access at run-time can be restricted by using permissions which are enforced by Java Security Manager which is part of Java2 Security model [2].

b. Java Package Administration Service - Packages contain classes and resources, which are shared with other bundles on the system. The package administration function manages the sharing of these resources. c. Start Level Service - Determines the order of start level of bundles.

d. URL Handlers - Provides a dynamic update mechanism to the standard Java 2 URL handler class.

2. System Services

a. Log Service

b. Configuration Administration

c. Device Access

d. User Administration

e. IO Connector

f. Preferences Service

3. Protocol Services

a. HTTP

b. Universal Plug and Play (UPnP)

Application bundles and infrastructure bundles work together to form a complete application. For example, a functional diagram for the video on demand application may resemble Figure 3.

Each of the infrastructure modules contributes a piece of core functionality. The VOD application pulls functionality from each core component to realize the finished application. At a high level, the functional flow is as follows: 1. STB is authenticated against TotalManage using PKC and is provided access to the application repository.

2. The VOD application is downloaded via one of various transport methods and initializes based on the policy set by the BSP and the service entitlement of that subscriber as contained within the Subscriber Module. If the subscriber is not subscribed to the service, the application does not load and resources are not consumed. No restart of the Java Virtual Machine is required to initialize and run the new application.

3. Upon initialization, the application loads metadata from the Data store module (which in turn has downloaded this data through the download module) and links itself into the Main Menu application bundle and Key Event Module.

4. Ul look and feel (widgets, colors, fonts, etc.) will be pulled from the Ul Module. Since the application was authored in an IDE which contained the Ul classes, the application can make full use of the exported functionality.

5. The Key Event Module will signal when a key event comes through to bring the VOD application into focus. The subscriber module provides information about parental control state, packages, and subscription which affect how the data is displayed to the subscriber. AVR are events are passed to the AVR module as the subscriber views content.

6. When a subscriber identifies the VOD item for purchase, the subscriber will enter their PIN (if required). The PIN module can be utilized to validate the PIN and the requesting STB to TotalManage. The Transaction module is employed to record the transaction.

7. The Datastore module provides the URI of the asset (as well as failover pathways in the event of a problem). The RTSP module is then used to setup the connection with the server along with the Media Player that will ultimately control the native-layer handler for the inbound media. Relevant section data will be made available to the application (closed captions, etc) through the Section Parser Module.

8. If the content is encrypted, the CA module is utilized to receive events from the underlying native CA libraries.

The above illustrates the intent of how the various modules will work together to provide complete application functionality.

On of the keys to this type of framework is resource and lifecycle management. BSPs will be able to set policies for applications which execute on their network. These policies will be enforced by the monitor bundle running on the client. This bundle receives its policies dynamically from TotalManage as new applications are deployed on the network. When the lifecycle of an application expires, it is uninstalled from the system and resource dependencies are freed up for others to use.

A layered approach to security is critical in a domain where applications can come from anywhere in the network. Not only must a BSP be able to secure the application execution environment from unwanted applications, but applications themselves must be protected from one another. The new architecture will address both of these security concerns among others.

In order to establish trust, both the device that receives applications as well as the applications themselves must be trusted. The system to establish trust on an STB is outside of the scope of this white paper (see the paper JSR 177 Security and Trust Services API for J2ME, http://icp.org/en/jsr/detail?id=209), but Myrio will work to establish and support a standard means to authenticate set-top boxes. One such method entails the STBs being initialized with a set of public keys in a trusted environment (for example, at the factory). A hierarchical set of keys provides the flexibility of allowing different parties to execute commands at different privileges on the STB. Typically the STB vendor and the CA vendor will work together to establish the identity of a trusted host.

Only applications from trusted sources will be allowed to execute on the STB. One way of building an infrastructure of trust is to use Public Key Cryptography (PKC). Applications are digitally signed by the operator or by a third party that the operator trusts. The monitor bundle on the STB will verify digital signatures preventing applications from deploying that are not signed by a trusted source.

The Java 2 Security Model will be implemented to enforce execution permissions of application bundles and infrastructure modules (http://java.sun.com/features/1998/11/jdk.security.html). Each bundle deployed into the service framework will be associated with a permission class. When initialized, the permission checker creates an instance of the permission class and checks with the Monitor Bundle Module. The Monitor Bundle Module receives policy information, which grants the required permissions (or not) to the requesting bundle.

Third parties wanting to author applications that integrate with Myrio services in the context of the service framework will be provided with the Myrio Collaborate™ toolkit. The exact makeup of the toolkit will be determined during the development phase, and the various components required to simulate the target environment. At a high level, the toolkit includes:

1. Myrio services - Java interfaces for published Myrio services within the service framework, including both design-time and runtime implementations (where appropriate) and associated documentation.

2. Service customization tools - Some services may incorporate functionality for which an accompanying tool is needed to support customization of that service. For example, a visual screen layout tool will be an integral part of the toolkit in order to support customization of the Myriol Ul service. See below for more details.

3. Service framework emulation environment -- This will allow developers to test their services in conjunction with the Myrio service implementations in the simulated service framework environment without requiring the setup and complete infrastructure required by the full runtime environment.

4. IDE integration -- IDE plugins may be developed to integrate the use of both the service framework emulation environment and the service customization tools more tightly within a particular IDE. Note that use of a particular IDE will not be required; the goal is to improve efficiency for popular IDEs without limiting potential developers just to those.

The new architecture will provide the ability to customize the look and feel of client applications. The following requirements must be met in order to provide complete application customization functionality:

1. Ability to change the look and feel of existing applications provided by Myrio.

2. Ability to create the look and feel of new applications based on a set of Myrio-provided elements (widgets, colors, fonts, etc) using an off-the- shelf integrated development environment (IDE).

3. Ability to create the look and feel of new applications based on pure a pure Java implementation based on AWT.

4. Ability to manipulate graphical elements at the Java layer.

5. Ability to manipulate graphical elements using markup (XML, HTML, etc.).

6. Ability to distribute and dynamically update new UIs to set-top clients at runtime.

It is important to note here, that BSPs that take on the task of creating their own applications and modifications to the stock user interfaces provided, will need to supply their own source control and version management systems.

The customization toolkit will seek to provide multiple methods to customize and create the graphical interface for applications. Methods will be provided at both the code level and markup level using a Declarative User Interface Framework structure (DUIF). Code-level methods will provide a standard set of Myrio IDE GUI plugins. The DUIF will be provided as an OSGI service bundle that will expose several external interfaces:

1. Plugins registry function acting as special purpose application extensions that simplify the creation of useful widgets (e.g. sliders, grid objects, buttons, etc.).

2. Referring to Figure 4, scripting registry function acting as a set of JavaScript statements that perform a task.

Skins are designed using basic HTML tags and JavaScript functions supplemented with the DUIF plugins and scripting services for implementing the user interface. The Figure 5 shows a simple layout which incorporates the HTML / JavaScript skin, and then plugins which "show through" the skin and provide hooks to the OSGI services. Traditional Web plugins could also be embedded to enhance the look and functionality of the skin as supported by the layout and rendering engine.

In this manner, third parties will be able to customize applications at the Java code level using a standard IDE as well as at a markup level using off-the- shelf HTML editors. This has the added benefit of providing support for popular Web plugins such as Macromedia Flash Player to use as skin elements.

The Myrio Interactive Development Kit (MyrioiDK) defines a porting

layer for the client application to interface to platform dependent functionality by specifying a set of APIs (as shown below). These APIs are typically implemented by STB vendor or other integrator participating in the IDK program.

The functionality of this layer will be extended to support the service framework. Much of the functionality already implemented by iDK partners will be leveraged. Among other functions, this layer will continue to interface with:

1. Mpeg Players and Decoders

2. Section Filters and Parsers

3. Graphics display and frame buffer drawing

4. OS and File system specific functions

5. Input events

6. Networking

7. Conditional Access Libraries

The service framework concept discussed on the client is potentially well suited to the server-side. Just as BSPs desire a modular framework approach to the client, a similar approach is also desirable in the back office. However, because of the scope of change required for the new client architecture, no attempt to change the architecture of TotalManage will be undertaken for this release. It will be the intention to address this design change during the the new architecture lifecycle however.

The key functionality developed for TotalManage will revolve around entitlement of applications deployed on a BSPs network, secure transmission of those applications to the client and event and transaction collection.

In Figure 6, Myrio and third parties create applications that are registered with TotalManage by the BSP. The design for the registration process will be forthcoming. Once registered, an application may be distributed to clients using one or multiple distribution methods. The most efficient means of IPTV application distribution is the same one that is employed today for global data distribution, which is IP Mutlicast.

The monitor bundle on the client receives entitlement information from TotalManage and manages the collection and execution of the application on the client. Once the application is initialized, client APIs collect event and transaction data and manage the transmission of that data back to TotalManage. Existing APIs on the server allow the transaction data to be exported to existing external billing systems and for AVR data to be processed for analysis.

There are several methods by which applications may be distributed on a BSPs network. A BSP is only limited by the transport bandwidth and type of protocols supported when considering which methods to employ as described above. Using Myrio's Mutlicast Messaging and Data Distribution Framework, for example, protocol-capable networks will be able to continually transmit a single instance of the application to all eligible clients on the network. Unicast methods may also be used as well, for example, web servers that transmit applications using HTTP, as requests come in from clients. BSPs may opt to run both methods using unicast as a failover mechanism if multicast temporarily goes down. In one embodiment of the new architecture, only broadband IP- based transports may be used. There will not be support for distribution of "bound"¹ applications within a cable, terrestrial, or satellite transmission (e.g. embedded within an Mpeg2 transport mux), which is required to support OCAP or MHP applications. However if the cable, terrestrial or satellite transport supports broadband IP transmission, it may be possible to utilize those transports for application and data distribution (e.g. embed MMDDF transport directly over broadband IP transport within the broadcast pipe).

Thus, for BSPs employing a network that is IP multicast capable, both multicast and unicast methods will be provided for application distribution. For networks that are not multicast-capable, a unicast-only method will be employed. In all cases, applications will only be delivered to a client as requested either by joining the proper multicast data transmission group, or by making a request to a web server. A client will only ever make requests for applications to which it has been granted entitlement by TotalManage. For more detail, please see "Server-side Application Security, Entitlement and Policies."

Secure transport methods that utilize encryption and secure sockets may be provided for an additional layer of security.

As explained previously, a layered approach to security will be adopted

¹ Bound applications are those bound to, or associated with, the currently tuned broadcast channel. When the viewer tunes away, the bound application is terminated ensuring secure packaging, distribution and execution of applications. Starting with the application authoring environment, applications will be digitally signed by the author and will be signed by the BSP when the application is deployed on the network. In this manner, the client will be able to trust the source of the applications.

TotalManage will include a policy engine which will allow BSP to set global policies for applications. For example, a policy can also be set identifying specific signatures that are authorized. TotalManage will continue to utilize the package subscription model at the application layer to authorize client services. The main difference now will be that bundles will not exist on the client for services that are not subscribed to saving resources.

Thus only applications to which the client is entitled will be downloaded to the set-top box. In the event that an application arrives that does not have an explicit entitlement it will be managed per a default policy enforced by the BSP-managed monitor bundle. It will be discarded or the monitor bundle may query TotalManage to attempt to obtain the policy.

Thus, authorized applications are those that have been digitally signed by the Author and the Operator; explicitly distributed to the client service framework via one of several transport methods; entitled on a per client, per device basis; requested and downloaded by the client; and have a policy in place which allows them to execute and be accessed by the subscriber.

An external API will be provided so that policies can be set an in external system to TotalManage. Much of the existing Myrio Release 3.0 infrastructure for event and transaction collection will be leveraged for the new architecture. While client components will accommodate the new service framework, server-side changes especially in the area of outbound APIs will be minimized. The fundamental extension created will allow for the collection of events and transactions which occur in applications created by the BSP or third parties Transactions

The Transaction Module on the client will provide a set of APIs for other bundles to utilize. When transactions are passed to the Transaction Module, it will communicate with TotalManage to record the transaction, and if required by the requesting bundle, confirm and authorize the bundle to complete the transaction.

The Audit Viewer Record (AVR) Module on the client will provide a set of APIs for the other bundles to utilize. Events passed into AVR will be collected, periodically transmitted back to TotalManage on a well known port, and recorded into a server log. This change in the client will be transparent to both the logging and parsing/analysis tool currently available in Release 3.x.

There are several service frameworks that satisfy part or all of the requirements of the new architecture which are based on Java technology. Microsoft™ also provides a proprietary service framework called .Net, but is only available from Microsoft. It is critical that Myrio draw from a technology pool that is open and non-proprietary.

MHP is based on the JavaTV API and is primarily a European standard for deployment of service-bound applications in the Satellite and Cable industries. The standard is television-based service device specific. This standard employs a carousel-based file system, embedded in the Mpeg transport multiplex, and is designed for one-way video transmission systems.

OCAP is also based on the JavaTV API and is primarily a North American standard for deployment of both service-bound and unbound applications to the Satellite and Cable industries. This standard employs a carousel-based file system, embedded in the Mpeg transport multiplex, but also supports two -way and out of band application delivery. This standard is designed for one-way or two-way video transmission systems.

OSGI is based on the Java 2 standard and was developed to connect home gateway devices to home automation systems, but has since expanded into Telematics (BMW), smart phones (Nokia, Motorola), smart home applications (Siemens) and consumer electronics (Philips iPronto™). MHP and OCAP are fundamentally designed around a vertical application domain, namely broadcast TV; they are application management/execution frameworks and provide little consideration for modularity and inter-dependency between a layered and peered application environment, i.e. library vs. application interactions. OSGi is domain independent and handles primarily modularity and dependency between modules and also provides domain independent services

In comparing and contrasting the various frameworks and the support provided against the Release 4.0 requirements, the following table depicts:

• Strength = Framework has strong support for desired functionality Possible = Framework has ability to support desired functionality

Weakness = Framework would require significant work to support desired functionality

Not possible = Framework cannot support the desired functionality.

Both platforms provide many of the aspects necessary for the new architecture. OCAP/MHP excels at providing application-level modularity, applicability to adjacent markets, and access to a wider range of third party software vendors. OSGi, contains the application-level modularity advantages of OCAP, but provides a better framework for adding services outside the traditional TV market (ex. UPnP).

OSGI appears to be the appropriate base service framework to support the infrastructure requirements of Myrio's software and ultimately the BSPs deploying it. However, it is important that the other video-centric standards are supported. This means that a combined-stack approach will need to be researched and understood. Because both MHP and OCAP applications need to be supported, either stack may need to be present depending on the market. Since OSGI stack's run-time footprint is very small (110K-1 M, depending on the stack), this is a viable strategy and one that will be explored as part the development phase of the implementation.

The new architecture of the embodiment of the present invention will be a radical change from current architecture providing the type of application authoring and execution environment required by BSPs deploying enhanced services using Internet Protocol. Moreover, the new architecture will seek to fully leverage the emerging application standards in the Cable and Satellite space as well as embrace technologies that unify devices within the digital home. This approach will foster an ever-growing community of open application development, which will benefit a BSP greatly over other sole-sourced, proprietary solutions.

Claims

What claimed is:

1. A computer-implemented system for handling internet protocol television data comprising a modular architecture based on Open Services Gateway model.

2. The system as recited in Claim 1 having a client stack, said client stack having a structure as shown in Figure 2.

3. The system as recited in Claim 1 having a VOD application, said VOD application having a structure as shown in Figure 3.

4. The system as recited in Claim 1 employing a process for establishing entitlement of applications deployed on a BSP network, said process having a flow as shown in Figure 6.