EP1243136A1 - Method and apparatus for authorization of software applications and features in digital communication terminals via a central billing system - Google Patents

Abstract

A method and apparatus are provided for allowing billing systems (105) to authorize and specify services, using service handles, for applications, features of applications, terminal features associated with applications or features of applications, in digital communication terminals (150) (e.g., television set-top boxes). In particular, the present invention relates to the authorization by a billing system (105) of software applications and features of communication terminals (150) which are operating in a Multiple Applications Management (MAM) (165) environment. Applications may include virtual applications which can be identified, downloaded (110), and enabled under the control of the MAM (165).

Description

METHOD AND APPARATUS FOR AUTHORIZATION OF SOFTWARE

APPLICATIONS AND FEATURES IN DIGITAL COMMUNICATION

TERMINALS VIA A CENTRAL BILLING SYSTEM

This application claims the benefit of U.S. provisional patent application no. 60/161,230 filed on October 22, 1999.

BACKGROUND OF THE INVENTION

The present invention relates to cable and satellite television systems and the like, and more particularly to a method and apparatus for allowing billing systems to authorize software applications and features in digital communication terminals (e.g., television set-top boxes) . The present invention further relates to the authorization by a billing system of software applications and features of communication terminals which are operating in a Multiple Applications Management (MAM) environment. Applications may comprise virtual applications that can be identified, downloaded, and enabled under the control of the MAM.

In accordance with the invention, a software application, an application feature, or a feature of a terminal associated with an application can be viewed as a "service" from the perspective of a billing system. The mechanisms, messages and data structures which allow these services to be defined and authorized in digital terminals are described herein. Traditionally there has been only one software application, viz., an Electronic Program Guide (EPG) , available in a digital television network. There existed no explicit control mechanisms to treat this traditional application as a service that can be authorized and/or billed by the billing system. For example, Figure 1 shows the modules in a prior art digital terminal prior to the implementation of Multiple Applications Management.

In Figure 1, a standard MPEG (Moving Picture Experts' Group) message 10 is received at the terminal 20. An MPEG packet processor 30 and a user processor 40 process the packet 10. A security processor 50 is provided in communication with the MPEG packet processor 30 for determining a user's authorization rights. The user processor 40 is in communication with a message preamble handler 60, which enables the terminal 20 to download the authorized application via downloader 70. The downloaded application is then stored in object download memory 80. The enabled application 90 (e.g., an EPG) can now be displayed. No explicit control mechanisms are provided in this prior art terminal 20 for treating this traditional software application (EPG) as a service (analogous, e.g., to a television service such as HBO , Cinemax , Pay-Per- View, or the like) that can be authorized and/or billed by a billing system.

Various software applications can be written for digital terminals. Newer versions of digital terminal firmware support Multiple Applications Management (MAM) . A MAM environment allows multiple virtual applications to be downloaded to and/or enabled in a digital terminal. These software applications enhance the user experience and increase the revenue for service providers and for equipment manufacturers. Examples of such applications include email, video-on- demand, web browsing, electronic programming guide, advertising, audio-on-demand, telephony services, stock prices, weather data, travel services and information, games, gambling, banking, shopping, voting, and the like.

MAM is proprietary technology owned by General Instrument Corporation of Horsham, Pennsylvania, USA, the assignee of the present invention. MAM is described in co-pending, commonly assigned U.S. Patent Application No. PCT/US 99/24745 filed October 22, 1999. Multiple Application Management is implemented by using some new, as well as some existing messages that are modified and/or interpreted differently. The MAM functionality within digital terminals receives and processes these messages .

Under MAM, the number of applications available to a digital terminal is expected to grow considerably, beyond the single traditional EPG application. It would be advantageous to provide a simple means for an application or an application feature to be treated as a service which can be authorized for a digital terminal by a billing system provided, e.g., at a cable television system headend (e.g., headend controller) . In particular, it would be advantageous to allow various applications, virtual applications, or their features to be viewed as services from the perspective of a billing system, and to allow the billing system to authorize digital terminals for these services, via the controller in a digital network.

It would be further advantageous to allow such a system to be backward compatible with digital terminals that are not running MAM capable firmware (platform code) . It would also be advantageous to allow a controller in a digital network to configure and authorize these services at the behest of a "billing system." Such a billing system may communicate with the controller via specific commands. The present invention provides the aforementioned and other advantages .

SUMMARY OF THE INVENTION

In a preferred embodiment of the invention, a system is provided in which a billing system controls access to services in a digital communication terminal. A controller is provided which is in communication with the terminal for defining one or more services available at the terminal. A billing system is provided which is in communication with the controller. The billing system provides authorization or de-authorization commands to the terminal via the controller for the defined service (s) . A download server is provided which is in communication with at least one of the controller and the terminal for enabling the downloading of authorized service (s) to the terminal.

The services may comprise at least one of an application, a feature of an application, or a terminal feature associated with at least one application. Alternatively, the services may comprise at least one of a virtual application, a feature of a virtual application, or a terminal feature associated with at least one virtual application. The services provided may include, by way of example, at least one of email, video-on-demand, web browsing, electronic programming guide, advertising, audio-on-demand, telephony services, stock prices, weather data, travel services and information, games, gambling, banking, shopping, voting, and the like. The commands sent by the billing system to the controller may comprise service handles used by said billing system to specify a service. The billing system may control multiple terminals in a digital network. The terminals in the digital network may be adapted to be operated in a MAM environment.

In an alternate embodiment, the service may comprise a feature of an application. The billing system in such an embodiment may provide feature identification and authorization requirements for the features to terminals in a digital network via the controller. The controller may create a Feature Authorization Table (FAT) which is sent by the controller in a digital message to the terminal. The FAT may be sent on a cyclic basis to the terminal. The FAT may comprise: a FAT_ID field which specifies an identifier for the FAT contained in the digital message; a sequence_number field which serves as a version number for the FAT; a number_of_fa_records field which specifies how many FAT records are present in the FAT; and a sequence of fa_records each of which identify a feature of an application and authorization requirements for the said feature.

Each fa_record may comprise: one or more feature_ID fields, each of v/hich specifies an identifier for a specific terminal feature associated with a feature of an application; and one or more feature_tier fields, each of which specifies the authorization requirements for the specific terminal feature . The service may be a virtual application feature. Where the service is a virtual application feature, the controller may create a Virtual Application Table (VAT) containing va_records, each of which identifies a virtual application. The controller may create fa_records in the va_records, where each fa_record identifies a feature of a virtual application and authorization requirements for the virtual application. The controller sends the VAT in a digital message to the terminal . The VAT may be sent on a cyclic basis to the terminal.

Each fa_record in the va_records may comprise one or more feature_ID fields, each of which specifies an identifier for a specific feature of a virtual application, and one or more feature_tier fields, each of which specifies the authorization requirements for the specific feature.

In an alternate embodiment, the service may be an application feature and the controller may send terminal configuration messages to modify the features of the terminal . The terminal features enable or disable the terminal's capability to run certain features of authorized applications.

The billing system may be capable of activating a previously deactivated terminal, initializing the previously deactivated terminal, and authorizing services at the previously deactivated terminal.

In addition, the billing system may be capable of determining the authorization state for an application, determining the authorization state for a feature of said application, and enabling or disabling the feature of an application based on the authorization state of the feature.

The billing system may provide updated authorization or de-authorization commands to the terminal via the controller. The terminal may re-check the authorization states of the application and the application features when updated authorization requirements or new authorization rights are received from the controller. The billing system can then enable or disable a feature of an application based on the updated authorization state of the feature.

The terminal may maintain terminal information in non-volatile memory. Terminal information may include at least one of internal tables, authorization states of applications, authorization states of features of applications, and the like. By maintaining such terminal information in non-volatile memory, such terminal information may be preserved through resets of the terminal . One application (e.g., an EPG) may be designated as a system wide default application authorized to run on all terminals in a digital network.

The billing system may bill for services provided on the terminal depending on the authorization state of the terminal.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a prior art digital terminal system which is not MAM enabled;

Figure 2 shows a block diagram of an implementation of the present invention;

Figure 3 shows a block diagram of an implementation of a communication terminal in accordance with the present invention;

Figure 4 shows a block diagram of a an alternate implementation of a communication terminal in accordance with the present invention;

Figure 5 shows an example of significant fields in a fa_record; and

Figure 6 shows a block diagram of an alternate implementation of a communication terminal in accordance with the present invention. DETAILED DESCRIPTION OF THE INVENTION

In accordance with the invention, a method and apparatus are provided for allowing billing systems to authorize and specify services (e.g., software objects and features) in digital communication terminals

(e.g., television set-top boxes). In particular, the present invention relates to the authorization by a billing system of software applications and features of communication terminals which are operating in a Multiple Applications Management (MAM) environment. An application, an application feature, or a feature of a terminal associated with an application can be viewed as a "service" from the perspective of a billing system. The mechanisms, messages and data structures which allow these services to be defined and authorized in digital terminals are described herein. The invention provides for authorization of at least the following via a billing system interface:

A. Data objects or data services, such as software applications, associated application features, and operating systems and features thereof .

B. Specific features of digital terminals, to enable access to certain application features (e.g., built-in e-mail, video-on-demand, or web browsing capabilities associated with an application such as an electronic program guide) .

Applications may comprise virtual applications which can be identified, downloaded, and enabled under the control of the MAM. In a MAM environment, digital terminals can be authorized for acquiring and enabling multiple applications. In accordance with the present invention, a billing system can view these applications and/or specific features of these applications as services. Such services can then be authorized in the same manner as conventional services like premium television channels, special pay-per-view events, video-on-demand services, and the like.

Figure 2 illustrates an overview of a digital network for providing authorization of software applications and features in digital communications terminals via a central billing system in accordance with the present invention. A billing system 105, which may be located at (or otherwise be in communication with) the headend 115 of a network (such as a cable or satellite television network) , manages the billing and authorization of applications for each specific terminal 150 in a network.

Users of the network can make arrangements to receive authorizations for the applications using conventional techniques, e.g., by phoning an operator and authorizing a credit card payment, or by use of an upstream communication path on the network, if available. For example, a user may request an authorization for an e-mail application, assuming the terminal 150 has the capability to access a network such as the Internet. Moreover, the user may have the option of requesting a basic or an enhanced e-mail capability for different fees.

Thus, an application or a virtual application can be viewed as a "service" from the perspective of the billing system 105.

Moreover, the network operator has the capability to authorize specific terminals 150 to receive an application without a user request, e.g., as a promotion, or as part of a package deal when other programming services are ordered, or some other goal is reached, such as the user purchasing a certain dollar value of pay-per-view or video-on-demand programs .

The billing system 105 can be implemented with a computer and known record-keeping and billing procedures . In a preferred embodiment, a system is provided in which the billing system 105 controls access to services in a digital communications terminal 150. The billing system 105 communicates with a controller 120. The controller 120 defines one or more services available at a terminal 150 which services are authorized by the billing system 105. The billing system 105 provides authorization or de-authorization commands to the terminal 150 via the controller 120 for the defined service (s) . The controller 120 translates the commands from the billing system 105 into data structures and forwards these messages to the terminal 150. These messages provide authorization rights to the terminals 150 for virtual applications and/or their features. A download server 110 is provided which is in communication with at least one of the controller 120 and the terminal 150 for enabling the downloading of authorized service (s) to the terminal 150. The download server 110 transmits the application data via an interface 130, and physical network and intermediate equipment 140 to a terminal 150. Note that the example terminal 150 is assumed to be part of a large terminal population. The application data may be broadcast to all terminals, but preferably can only be recovered by the terminals based on control data from the controller 120.

Alternatively, or in addition, control data can be provided to the terminal 150 by other means, such as locally using a smart card, or at the time of installation or manufacture of the terminal. However, the provision of control data via a controller 120 that is under the direct control of a headend 115 is believed to provide the greatest flexibility since updated control data can be transmitted immediately to the terminal 150. Moreover, known decoder addressing and conditional access techniques can be used to deliver specific control data to specific terminals or groups of terminals. For example, the control data can be encrypted under a key that has been assigned to the specific terminal 150.

The controller 120 thus configures and authorizes the terminals 150 under the control of the billing system 105.

The application and control data can be encapsulated in transport packets, for example, such as MPEG-2 packets, using known techniques. The application and control data can be carried in-band, with the programming services, or out-of-band, apart from the programming services. Also, the application data can be sent via any reliable transport mechanism, for example via TCP/IP.

The physical network and intermediate equipment 140 may include cable and/or optical fiber, as well as required switches, amplifiers and other conventional components .

The billing system 105 can use Wirelink Protocol (or comparable) commands such as the "Add New Settop", "Change Settop Service", and/or "Initialize Digital Settop" to authorize or de-authorize these services on digital terminals 150. The billing system 105 sends these Wirelink commands to the controller 120 in the digital network. Wirelink is a protocol developed by General Instrument Corporation of Horsham, Pennsylvania, USA, the assignee of the present invention and is described in General Instrument Corporation's Digi tal Wirelink Protocol Reference Guide Version 3 . 0 (1999). It should be appreciated that the Wirelink protocol is only an example of a protocol that can be used to provide commands. As will be appreciated by those skilled in the art, other communication protocols or physical interfaces now known or that will be developed in the future can be substituted for the specific Wirelink implementation discussed herein. Based on the information in the Wirelink commands from the billing system 105, the controller 120 creates certain messages containing information about the applications, features of applications, or features of the terminal 150. The messages are sent on a cyclic basis to terminals 150 in the digital network. These messages provide authorization requirements for the services representing applications or features of applications. For example, the billing system 105 can send a "Change Settop

Features" command to the controller 120 to authorize or de-authorize the terminal features associated with applications or features of applications.

The services may comprise at least one of an application, a feature of an application, or a terminal feature associated with at least one application. Alternatively, the services may comprise at least one of a virtual application, a feature of a virtual application, or a terminal feature associated with at least one virtual application. The services provided may include, by way of example, at least one of email, video-on-demand, web browsing, electronic programming guide, advertising, audio-on-demand, telephony services, stock prices, weather data, travel services and information, games, gambling, banking, shopping, voting, and the like.

The commands sent by the billing system 105 to the controller 120 may comprise service handles used by said billing system 105 to specify a service. Using service handles is considered advantageous since few software modifications need to be made within the system. The billing system 105 may control multiple terminals 150 in a digital network. The terminals 150 in the digital network may be adapted to be operated in a MAM environment.

In an alternate embodiment, the service may comprise a feature of an application. The billing system 105 in such an embodiment may provide feature identification and authorization requirements for the features to terminals 150 in a digital network via the controller 120. The controller 120 may create a Feature Authorization Table (FAT) which is sent by the controller in a digital message to the terminal . The FAT may be sent on a cyclic basis to the terminal 150. Section 1.1.3.1 below describes the structure of a FAT.

Figure 3 illustrates the modules in a digital terminal 150 using a FAT. The terminal 150 receives MPEG messages (packets), such as example packet 200, from the controller 120 of Figure 2. Use of MPEG packets is discussed herein only as an example. Any digital transport protocol may be used. An MPEG packet processor 155 processes the packet 200 to recover control and authorization data (commands) from the controller 120 of Figure 2. The control and authorization data is provided to the security processor 160 and to a multiple applications manager (MAM) 165. The MAM 165 and other terminal functions can be implemented using any known software, firmware and/or hardware techniques. Control and authorization data can be stored at a memory associated with the terminal 150. The MPEG packet processor 155 can recover the application data and forward it to a downloader 170. The downloader 170 has an associated memory, download object memory 175, for storing the downloaded application data, including the applications themselves, such as code objects. "Downloading" refers to recovering and storing. For example, the downloader 170 may receive a "Tune Download Channel Message" contained in the MPEG packet 200 that commands it to download particular applications, and/or particular versions of the same application from a specific channel. The channel may be identified by a packet identifier in a known manner. A user processor 180 is provided for running software .

The controller 120 may send the FAT 181 in a digital message (e.g., in a virtual object message contained within MPEG message 200) to the terminal 150. The Feature Authorization Function 190 obtains the application feature's authorization requirements from the FAT. The Feature Authorization Function 190 also obtains the authorization rights for the application feature from the controller 120. The

Feature Authorization Function then checks with the security processor 160 and obtains the authorization state for the feature of the application. A Virtual Application Table (VAT) 185 may also be provided in the terminal, which VAT may contain va_records, each of which identifies an application existing on the terminal 150.

When a virtual application is enabled on a terminal, the enabled application 195 queries the Feature Authorization Function for the authorization states of the application's features. Depending on the authorization state of a feature, the application will enable or disable the feature.

The FAT 181 may comprise: a FAT_ID field which specifies an identifier for the FAT 181 contained in the digital message 200; a sequence_number field which serves as a version number for the FAT 181; a number_of_fa_records field which specifies how many FAT records are present in the FAT 181; and a sequence of fa_records each of which identify a feature of an application and authorization requirements for the feature. Table 3 provides details of these fields.

There may be multiple FATs existing in a digital network. The Virtual Application Config message specifies the home_FAT_ID. Table 1 provides a detailed description of the significant fields of a Virtual Application Config message used in this embodiment. The home_FAT_ID specifies the current default FAT to be used by a terminal . Each fa_record may comprise: one or more feature_ID fields, each of which specifies an identifier for a specific terminal feature associated with a feature of an application (which can be provided by any enabled application in the terminal) ; and one or more feature_tier fields, each of which specifies the authorization requirements for the specific terminal feature. Table 8 describes the fa_records in a FAT .

The service may be a virtual application feature. Where the service is a virtual application feature, the controller 120 of Figure 2 may create a Virtual Application Table (VAT) . As shown in Figure 4, the controller 120 of Figure 2 sends the VAT 185 in a digital message 200 to the terminal 150. The VAT may be sent on a cyclic basis to the terminal 150. Like- numbered elements correspond to one another in the Figures and the specific functions of each element will be repeated only as necessary in order to describe a particular embodiment. The VAT 185 may contain va_records, each of which identifies a virtual application. Section 1.1.3.4 describes the structure of a va_record of a VAT. The controller 120 (of Figure 2) may create fa_records in the va_records, where each fa_record identifies a feature of a virtual application and authorization requirements for the virtual application. The Feature Authorization Function 190 obtains the application feature's authorization requirements from the fa_record contained in a va_record. The application may then be enabled or disabled as discussed in connection with Figure 3 above. A features_included field is defined in the virtual_application_control_word of the va_record in the VAT. If the fea tures_included field is set, then a feature_count field and a sequence of fa_records are present and contained in the va_record. Each fa_record identifies a feature of the application and specifies the authorization requirements for that feature. The eature_couπt field specifies how many fa_records are present in the va_record for the application. Table 6 describes in detail the fields of a va_record of a VAT containing fa_records .

Figure 5 illustrates the significant fields in the structure of fa_records . Each fa_record 200a-200e in the va_records (or in the FAT) may comprise one or more feature_ID fields 210, each of which specifies an identifier for a specific feature of a virtual application, and one or more feature_tier fields 220, each of which specifies the authorization requirements for the specific feature. These fa_records are described in Table 9.

In an alternate embodiment, the service may be an application feature and the controller 120 may send terminal configuration messages to modify the features of the terminal 150. These features can be provided by any virtual application that is enabled in the terminal 150. Figure 6 illustrates the modules in a digital terminal 150 using the terminal's configuration features 184. The terminal features enable or disable the terminal's capability to run certain features of authorized applications.

For example, when adding a new terminal to the network, the billing system uses the Wirelink command 660, viz., "Add New Settop". The command provides a list of Service_Handle fields. Each Service_Handle contains a service number field plus other fields. A service can be authorized or de-authorized using sub- fields in the Service_Handle field. The Num_Changed_Services field specifies the number of Service_Handle fields included in the 660 command.

A "Change Settop Service" is the Wirelink command 662. The billing system uses this command to change the services in a terminal that has already been added in a digital network. This command also contains a Num_Changed_Services field and a sequence of

Service_Handle fields. A service can be authorized or de-authorized using sub- fields in the Service_Handle field. A sub-field of the Num_Changed_Services field can indicates that all services in the terminal are to be de-authorized.

Alternatively, the "Change Settop Features" can be used to authorize a particular feature in the terminal (e.g., the terminal should be authorized for e-mail, web-browsing, VOD, etc.). The "Change Settop Features" i.e., the Wirelink command 680, is used by the billing system to modify the default settings that are applied when adding a terminal using the "Add New Settop" command. A sub-field of the Bi t_Mask_l field specifies, if set, that the APPLICATION_FEATURES field in the message is valid. The APPLICATION_FEATURES field has sub-fields which specify the terminal features which are to be enabled (if the sub-field is set) or disabled (if the sub-field is clear) . Each sub-field set or cleared would authorize or deauthorize, respectively, particular features within a terminal .

The billing system 105 may be capable of activating a previously deactivated terminal 150, initializing the previously deactivated terminal 150, and authorizing services at the previously deactivated terminal 150. For example, the billing system may use the Wirelink command 664, viz., "Initialize Digital Settop" to activate a previously de-activated terminal. This command is used to initialize a terminal and change its service authorizations. This command also has a Nuw_Changed_Services field and a sequence of Service_Handle fields, as described for the Wirelink Commands 660 and 662 above.

In addition, the billing system 105 may be capable of determining the authorization state for an application, determining the authorization state for a feature of said application, and enabling or disabling the feature of an application based on the authorization state of the feature. The billing system 105 may provide updated authorization or de-authorization commands to the terminal 150 via the controller 120. The terminal 150 may re-check the authorization states of the application and the application features when updated authorization requirements or new authorization rights are received from the controller 120. The billing system 105 can then enable or disable a feature of an application based on the updated authorization state of the feature. Whenever the Feature Authorization Function 190 receives new or modified authorization requirements for the applications' features or the terminal features associated with application features, the Feature Authorization Function 190 re- checks the authorization states of all the features with the Security processor. The Feature Authorization Function 190 also re-checks the authorization states when authorization commands are received by the terminal .

After the authorization states of application features are updated, the Feature Authorization Function 190 sends a message to the application that may be already enabled, indicating which features are currently authorized or that the application needs to query the Feature Authorization Function 190 to check which features are currently authorized.

The terminal 150 may maintain terminal information in non-volatile memory (e.g., in the MAM). Terminal information may include at least one of internal tables, authorization states of applications, authorization states of features of applications, and the like. By maintaining such terminal information in non-volatile memory, such terminal information may be preserved through resets of the terminal .

One application (e.g., an EPG) may be designated as a system wide default application authorized to run on all terminals 150 in a digital network. An Electronic Program Guide (EPG) has traditionally been the one and only application which older non-MAM capable digital terminals acquired and enabled. The invention provides for backward compatibility with older terminals which may be present in the digital network and which are not capable of running in a MAM environment .

Since previously reserved or unused fields are used to specify the definitions of new messages, or for modifying the functionality of already existent messages, older terminals cannot acquire or understand them. Thus, although the functioning of older terminals is not adversely affected, these terminals cannot take advantage of the newer MAM features .

At the same time, the present invention can be advantageously implemented in a manner which ensures that newer terminals running in a MAM environment can acquire, enable and run the traditional EPG application. To this effect, the present invention allows for one application in a MAM environment to be regarded as a system wide default application. The traditional EPG can then be designated as the system wide default application. Newer terminals running in a MAM environment perceive the system wide default application as a virtual application. However, billing system services for traditional EPG applications will always be authorized for digital terminals under MAM. Therefore, the traditional EPG application can run as before in a MAM environment.

The billing system 105 may bill for services provided on the terminal 150 depending on the authorization state of the terminal 150.

The following is a detailed description of the messages and data structures which may be used in a preferred embodiment to implement the present invention:

1.1.1 The Newly Created DCII Message Preamble Decoder Conditional

A new enumeration configured_for_MAM has been defined and added as a part of the DigiCipher^® II (DCII) message preamble decoder condition, using a previously reserved entry. DCII is a digital television standard proprietary to General Instrument Corporation of Horsham, Pennsylvania, USA, the assignee of the present invention. It should be appreciated that the invention can be implemented using other standards and hardware, and the following details are only provided as an example implementation .

The newly created decoder condition may be prefixed to certain messages, such as the Virtual Object message and the Tune Download Channel message, sent by the controller 120 to the terminals 150.

(These messages are described below in Sections 1.1.3 and 1.1.4, respectively).

Consequently, a terminal 150 which has not been configured_for_MAM will not acquire a Virtual Application Table and become MAM enabled, nor tune to a download channel for acquiring a virtual application.

The selective use of this decoder conditional also allows older terminals (e.g., the terminal 20 of Figure 1) that are not upgraded with MAM capable firmware platform code, to continue to operate without any detrimental side effects caused by the innovations involved with Multiple Applications Management.

1.1.2 The Newly Created Virtual Application Config Message.

A new sub-command has been added to the Digital Cable Terminal (DCT) Configuration message, by using a previously reserved value, and represents the Virtual Application Config message.

A Virtual Application Config message is used to configure or de-configure a terminal 150 for Multiple Application Management and to provide MAM configuration settings to the terminal 150. Information derived from the Virtual Application Config message is kept by the terminal 150 in nonvolatile memory, in order to preserve it through (warm) resets of the terminal . The significant fields in the Virtual Application Config message can have two different forms depending on the embodiment of the invention. They are described in the following sub-sections.

1. 1 .2. 1 Significant Fields of Virtual Application Config Message in Figure 3 Embodiments .

The significant fields in the Virtual Application Config message used in the embodiments of the invention described in connection with Figure 3 are described in Table 1 below. A home_FAT_ID field is included as a significant field in the message. The home_FAT_ID field identifies the current default Feature Authorization Table 181 in the terminal 150.

Table 1: Significant Fields in a Virtual Application Config Message in the Figure 3 Embodiments .

1 . 1. 2. 2 Significant Fields of Virtual Application Config Message in the Figure 4 and Figure 6 Embodiments .

The significant fields in the Virtual Application Config message used in the embodiments described in connection with Figure 4 and Figure 6 are described in Table 2 below. Note that a home_FAT_ID field is not a significant field in these embodiments, and is not used.

Table 2: Significant Fields in a Virtual Application Config Message in the Figure 4 and Figure 6 Embodiments .

1.1.3 The Newly Created Virtual Object Message.

A new DCII message type has been created by using a previously reserved value, and represents the Virtual Object message. A Virtual Object message is used to deliver a Virtual Application Table 185 to a terminal 150. This message is carried in the network stream and may be sent broadcast-addressed, multicast- addressed or singlecast-addressed to the terminal 150, using segmentation overlay. The controller 120 (e.g., a DAC) prefixes the virtual object message with a configured_for_MAM decoder condition in the message preamble. Therefore, only terminals which are configured_for_MAM will process this message. This ensures that terminals which are not running a MAM capable firmware (platform code) will fail the decoder condition test, and will not acquire a Virtual Application Table.

A terminal 150 is considered to be in a MAM enabled state if it is configured_for_MAM and has completely acquired its home_VAT (described in Section 1.1.2 above) .

Information derived from the Virtual Object message, including the Virtual Application Table (VAT) 185 and the Feature Authorization Table (FAT) 181, is kept by the terminal 150 in non-volatile memory, in order to preserve it through (warm) resets of the terminal 150. As described in the following sub-sections, the Figure 3 embodiments of the invention use separate FATs 181 (which contain fa_records ) and VATs 185 (whose va_records do not contain fa_records ) . The Figure 4 embodiments use VATs 185 (whose va_records contain fa_records ) . It does not use FATs. The Figure 6 embodiment uses VATs 185 whose va_records do not contain fa_records . The Figure 6 embodiment does not use FATs either; instead, it uses terminal configuration features 184 to determine which application features are authorized.

1. 1. 3. 1 Significant Fields of Virtual Object Message containing a FAT, used in the Figure 3 Embodiments .

The significant fields in the Virtual Object message containing a FAT, applicable to the Figure 3 embodiments of the invention, are described in Table 3. Table 3: Significant Fields in a Virtual Object Message containing a FAT used in the Figure 3 Embodiments .

1. 1. 3. 2 Significant Fields of Virtual Object Message containing a VAT, applicable to all Embodiments . The significant fields in the Virtual Object message containing a VAT 185 are described in Table 4 The VAT 185 is used in all embodiments of the invention. In the Figure 4 embodiment, the va_records also contain fa records , as described later.

Table 4: Significant Fields in a Virtual Object Message containing a VAT, applicable to all Embodiments .

1 . 1. 3. 3 Significant Fields of a va_record of a VAT, applicable to the Figure 4 and Figure 6 Embodiments .

The following Table 5 describes the significant fields in each record of a Virtual Application Table (VAT) 185 used in the Figure 4 and Figure 6 embodiments of the invention. The va_record does not contain information about features associated with the application.

Table 5: Significant Fields in a "va_record" in a Virtual Object message used in the Figure 4 and Figure 6 Embodiments .

1 . 1.3. 4 Significant Fields of a va_record of a VAT, applicable to the Figure 3 Embodiments .

The following Table 6 describes the significant fields in a va_record of a Virtual Application Table (VAT) 185 used in the Figure 3 embodiments of the invention. The va_record contains information about features associated with the application. That information does not need to be delivered to the terminal 150 by a separate Feature Authorization Table.

If the virtual_application_control_word has the fea ures_included field set, then the feature_count field in the va_record is present and provides a count of the number of fa_records included in the va_record. The fa_records provide the identifier of a feature of the application and the authorization requirements for that feature to be enabled on the terminal 150. The fa_records included within a va_record of the VAT are described in Table 9.

Table 6: Significant Fields in a "va_record", which includes "fa_records" , used in the Figure 3 Embodiments .

1. 1.3. 5 Significant Fields of a virtual _application_control_word in a va_record of a

VAT.

The following Table 7 describes the significant fields in the virtual_applica tion_control_word in the va record for a virtual application in the Virtual Application Table (VAT) 185. This is common to all embodiments .

Table 7: Significant fields in a

"virtual_application_control_word" of a "va_record" in the VAT.

1 . 1 . 3. 6 Significant Fields of a fa_record of a FAT, applicable to the Figure 4 Embodiments . The following Table 8 describes the significant fields in the fa_record for the features of virtual applications in the Feature Authorization Table (FAT) 181. Table 8: Significant fields of a fa record in the FAT.

1. 1. 3. 7 Significant Fields of a fa_record included in a va_record applicable to the Figure 4 Embodiments .

In the Figure 4 embodiments of the invention, one or more fa_records are included in the va_record of the VAT 185. The feature_count field of the va_record specifies how many fa_records are present for the application.

The following Table 9 describes the significant fields in the fa record for the features of virtual applications included within a va_record of a Virtual Application Table (VAT) 185.

Table 9: Significant fields of a "fa_record" included within a "va record" in the VAT.

1.1.4 The Modified Definition of the Tune Download Channel Message.

This message, which is a sub-command of the DCT Download Control message, has been modified.

The definition of the tune_download_function_field has been enhanced. A previously reserved value has been re-defined to specify whether the message applies to a

"virtual_application" or to a fixed or standard application.

The Tune Download Channel message for all virtual applications (except for a system wide default application) must contain the configured_for_MAM decoder condition in the message preamble.

Therefore, only terminals which are configured_for_MAM will process this message. This ensures that terminals which are not running a MAM capable firmware platform code will fail the decoder condition test and will not acquire a virtual application. If a virtual application is specified in the Tune Download Channel message, the virtual application is identified by the obj_application_ID field in the message. This virtual application then correlates to the one identified by the obj ect_applica tion_ID field in one of the records of the Virtual Application Table (the home_VAT) maintained by the Multiple Application Manager.

Moreover, the obj_application_ID, tune_obj ect_name and tune_ojb'ect_version in the Tune Download Channel message should correlate with the application_ID, object_name and object_ version in the DCT Download message for the virtual application.

The Tune Download Channel message for the system wide default virtual application is an exception. The configured_for_MAM decoder condition is not used for this default application. Consequently, all terminals will always be able to acquire the system wide default application. 1.1.5 The Modified Functionality of the Download Control Message.

This message, which is also a sub-command of the DCT Download Control message, has modified functionality as an implication of the invention.

Since the Multiple Application Manager 165 has the information (via the Virtual Application Table) about which applications must be enabled, disabled, purged, etc., the Downloader 170 can no longer directly act on the receipt of the Download Control sub-command message.

Therefore, if MAM is enabled on a terminal, the "disable", "delete" and "purge" functions specified in a DCT Download Control sub-command message, for virtual applications, are ignored by the Downloader 170 module in the terminal 150.

In addition, if MAM is enabled, the "enable" function specified in a DCT Download Control sub- command message for a virtual application causes the

Downloader 170 to interrogate the Multiple Application Manager module 165 to see if the application should indeed be enabled. The MAM 165 responds back with information whether to enable or disable the virtual application.

1.1.6 The Modified Functionality of the Virtual Channel Config Message.

This message, which is a sub-command of the DCT Config message, has modified functionality as an implication of the invention.

If MAM is enabled, the digital terminal 150 will disregard the turnon_VC_defined, turnon_VC, turnoff_VC_de fined and turnoff_VC fields specified by this message if the default virtual application has a defined VCT_source_ID . In this case, the terminal 150 will tune to the channel associated with the VCT_source_J given for the default virtual application. It should be appreciated that the above described implementation of the invention using the DCII standard is provided herein as an example, and other standards which are known or to be developed may be used to implement the invention. It should now be appreciated that the present invention provides a scheme for allowing billing systems to authorize software applications and application features in digital terminals. The invention provides a system architecture for allowing specific billing system services to be associated with client software applications or their features. Billing systems can authorize or de-authorize terminals for these services, via a controller in a digital network. Customers can also be billed for using these services.

Thus, the invention provides a means for supporting feature rich multiple applications on digital terminals. Moreover, authorizable and/or billable services can be created in accordance with the invention which correspond to applications and their features in digital terminals. The invention also provides a scheme for efficiently authorizing and de-authorizing applications and features in digital terminals. Television system operators and the like are provided with the ability to bill for applications and/or features in digital terminals. For example, the capability is provided to authorize, de-authorize and/or bill for items such as operating systems, web pages, and other downloadable code or data objects.

Although the invention has been described in connection with various illustrated embodiments, numerous modifications and adaptations may be made thereto without departing from the spirit and scope of the invention as set forth in the claims

Claims

What is claimed is:

1. A method for allowing a billing system to control access to services in a digital communication terminal, comprising the steps of: defining one or more services available at a terminal as controllable by said billing system; providing authorization or de-authorization commands from the billing system to the terminal for the defined service (s) via a controller; and downloading the authorized service (s) to the terminal .

2. A method in accordance with claim 1, wherein the services comprise at least one of an application, a feature of an application, or a terminal feature associated with at least one application.

3. A method in accordance with claim 1, wherein the services comprise at least one of virtual application, a feature of a virtual application, or a terminal feature associated with at least one virtual application.

4. A method in accordance with claim 1, wherein the services comprise at least one of email, video-on- demand, web browsing, electronic programming guide, advertising, audio-on-demand, telephony services, stock prices, weather data, travel services and information, games, gambling, banking, shopping, and voting.

5. A method in accordance with claim 1, wherein the commands comprise service handles used by said billing system to specify a service.

6. A method in accordance with claim 1, wherein the billing system controls multiple terminals in a digital network.

7. A method in accordance with claim 6, wherein the terminals are adapted to be operated in a Multiple Applications Management (MAM) environment.

8. A method in accordance with claim 1, wherein: the service comprises a feature of an application; and the billing system provides feature identification and authorization requirements for the features to terminals in a digital network via the controller.

9. A method in accordance with claim 1, wherein the service is an application feature, further comprising the steps of : creating a Feature Authorization Table (FAT) ; and sending the FAT in a digital message to the terminal .

10. A method in accordance with claim 9, wherein the FAT is sent on a cyclic basis.

11. A method in accordance with claim 9, wherein the FAT comprises; a FAT_ID field which specifies an identifier for the FAT contained in the digital message; a sequence_number field which serves as a version number for the FAT; a number_of_fa_records field which specifies how many FAT records are present in the FAT; and a sequence of fa_records each of which identify a feature of an application and authorization requirements for the said feature.

12. A method in accordance with claim 11, wherein each fa_record comprises : one or more feature_ID fields, each of which specifies an identifier for a specific terminal feature associated with a feature of an application; and one or more feature_tier fields, each of which specifies the authorization requirements for the specific terminal feature.

13. A method in accordance with claim 1, wherein the service is a virtual application feature, further comprising the steps of : creating a Virtual Application Table (VAT) containing va_records, each of which identifies a virtual application; creating fa_records in the va_records, where each fa_record identifies a feature of a virtual application and authorization requirements for the virtual application; and sending the VAT in a digital message to the terminal .

14. A method in accordance with claim 13, wherein the VAT is sent on a cyclic basis.

15. A method in accordance with claim 13, wherein each fa_record comprises : one or more feature_ID fields, each of which specifies an identifier for a specific feature of a virtual application; and one or more feature_tier fields, each of which specifies the authorization requirements for the specific feature.

16. A method in accordance with claim 1, wherein the service is an application feature, further comprising the step of : sending terminal configuration messages to modify the features of the terminal, which terminal features enable or disable the terminal's capability to run certain features of authorized applications.

17. A method in accordance with claim 1, further comprising the step of: activating a previously deactivated terminal; initializing said previously deactivated terminal ; and authorizing services at said previously deactivated terminal .

18. A method in accordance with claim 1, further comprising the steps of: determining the authorization state for an application; determining the authorization state for a feature of said application; and enabling or disabling the feature of an application based on the authorization state of the feature .

19. A method in accordance with claim 18, further comprising the steps of: providing updated authorization or de- authorization commands to the terminal; re-checking the authorization states of the application and the application features at the terminal when updated authorization requirements are received; and enabling or disabling a feature of an application based on the updated authorization state of the feature.

20. A method in accordance with claim 18, further comprising the step of : maintaining terminal information in non-volatile memory, such terminal information including at least one of internal tables, authorization states of applications, and authorization states of features of applications, such that said terminal information is preserved through resets of the terminal .

21. A method in accordance with claim 1, wherein one application is designated as a system wide default application authorized to run on all terminals in a digital network.

22. A method in accordance with claim 1, further comprising the step of: billing for services provided on the terminal depending on the authorization state of the terminal.

23. A system for allowing a billing system to control access to services in a digital communication terminal, comprising: a terminal ; a controller in communication with said terminal for defining one or more services available at the terminal ; a billing system in communication with said controller, said billing system providing authorization or de-authorization commands to the terminal via the controller for the defined service (s); and a download server in communication with at least one of the controller and the terminal for enabling the downloading of authorized service (s) to the terminal .

24. A system in accordance with claim 23, wherein the services comprise at least one of an application, a feature of an application, or a terminal feature associated with at least one application.

25. A system in accordance with claim 23, wherein the services comprise at least one of virtual application, a feature of a virtual application, or a terminal feature associated with at least one virtual application.

26. A system in accordance with claim 23, wherein the services comprise at least one of email, video-on- demand, web browsing, electronic programming guide, advertising, audio-on-demand, telephony services, stock prices, weather data, travel services and information, games, gambling, banking, shopping, and voting .

27. A system in accordance with claim 23, wherein the commands comprise service handles used by said billing system to specify a service.

28. A system in accordance with claim 23, wherein the billing system controls multiple terminals in a digital network.

29. A system in accordance with claim 28, wherein the terminals are adapted to be operated in a Multiple Applications Management (MAM) environment.

30. A system in accordance with claim 23, wherein: the service comprises a feature of an application; and the billing system provides feature identification and authorization requirements for the features to terminals in a digital network via the controller.

31. A system in accordance with claim 23, wherein: the service is an application feature; the controller creates a Feature Authorization Table ( FAT ) ; and the controller sends the FAT in a digital message to the terminal .

32. A system in accordance with claim 31, wherein the FAT is sent on a cyclic basis.

33. A system in accordance with claim 31, wherein the FAT comprises; a FAT_ID field which specifies an identifier for the FAT contained in the digital message; a sequence_number field which serves as a version number for the FAT; a number_of_fa_records field which specifies how many FAT records are present in the FAT; and a sequence of fa_records each of which identify a feature of an application and authorization requirements for the said feature.

34. A system in accordance with claim 33, wherein each fa_record comprises : one or more feature_ID fields, each of which specifies an identifier for a specific terminal feature associated with a feature of an application; and one or more feature_tier fields, each of which specifies the authorization requirements for the specific terminal feature.

35. A system in accordance with claim 23, wherein: the service is a virtual application feature; the controller creates a Virtual Application Table (VAT) containing va_records, each of which identifies a virtual application; the controller creates fa_records in the va_records, where each fa_record identifies a feature of a virtual application and authorization requirements for the virtual application; and the controller sends the VAT in a digital message to the terminal .

36. A system in accordance with claim 35, wherein the VAT is sent on a cyclic basis.

37. A system in accordance with claim 35, wherein each fa_record comprises : one or more feature_ID fields, each of which specifies an identifier for a specific feature of a virtual application; and one or more feature tier fields, each of which specifies the authorization requirements for the specific feature.

38. A system in accordance with claim 23, wherein: the service is an application feature; the controller sends terminal configuration messages to modify the features of the terminal, which terminal features enable or disable the terminal's capability to run certain features of authorized applications .

39. A system in accordance with claim 23, wherein the billing system in capable of: activating a previously deactivated terminal; initializing said previously deactivated terminal ; and authorizing services at said previously deactivated terminal .

40. A system in accordance with claim 23, wherein the billing system is capable of: determining the authorization state for an application; determining the authorization state for a feature of said application; and enabling or disabling the feature of an application based on the authorization state of the feature .

41. A system in accordance with claim 40, wherein: the billing system provides updated authorization or de-authorization commands to the terminal via the controller; the billing system re-checks the authorization states of the application and the application features at the terminal when updated authorization requirements are received; and the billing system enables or disables a feature of an application based on the updated authorization state of the feature.

42. A system in accordance with claim 40, wherein: the terminal maintains information in nonvolatile memory, such information including at least one of internal tables, authorization states of applications, and authorization states of features of applications, such that said terminal information is preserved through resets of the terminal .

43. A system in accordance with claim 23, wherein one application is designated as a system wide default application authorized to run on all terminals in a digital network.

44. A system in accordance with claim 23, wherein: the billing system bills for services provided on the terminal depending on the authorization state of the terminal .