CA2388155A1 - Method and apparatus for authorization of software applications and features in digital communication terminals via a central billing system - Google Patents
Method and apparatus for authorization of software applications and features in digital communication terminals via a central billing system Download PDFInfo
- Publication number
- CA2388155A1 CA2388155A1 CA002388155A CA2388155A CA2388155A1 CA 2388155 A1 CA2388155 A1 CA 2388155A1 CA 002388155 A CA002388155 A CA 002388155A CA 2388155 A CA2388155 A CA 2388155A CA 2388155 A1 CA2388155 A1 CA 2388155A1
- Authority
- CA
- Canada
- Prior art keywords
- terminal
- feature
- application
- authorization
- accordance
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
- H04N21/8166—Monomedia components thereof involving executable data, e.g. software
- H04N21/8173—End-user applications, e.g. Web browser, game
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
- H04N21/2362—Generation or processing of Service Information [SI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/254—Management at additional data server, e.g. shopping server, rights management server
- H04N21/2543—Billing, e.g. for subscription services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
- H04N21/8166—Monomedia components thereof involving executable data, e.g. software
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/162—Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
- H04N7/165—Centralised control of user terminal ; Registering at central
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
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 S
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 services) 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 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 f eature .
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 5 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.
10 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 5 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 10 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.
15 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 services) 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 Digital 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 5 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 10 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 15 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 20 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 features 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 feature-count 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 5 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 10 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 15 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 20 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 25 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 Bit Mask 1 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 Num 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 5 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 10 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 15 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, 20 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 non-volatile memory, in order to preserve it through (warm) resets of the terminal.
32.
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.
Name of Field Description config-for multiThis field, if set to "yes" configures apps a terminal for Multiple Application Management.
The terminal is then considered to be in a configured for MAM
state.
The terminal will then be able to receive other messages that have the configured for MAM decoder condition in the DCII message preamble.
If this field is cleared to "no", the terminal will no longer be configured for MAM, nor enabled for MAM.
home VAT_ID This field identifies a Virtual Application Table (VAT) which must be used by the terminal as the terminal's default VAT (home VAT).
(The Virtual Application Table is described in Section 1.1.3).
default application_IDThis field identifies an application that will be the default virtual application for the terminal.
(This ID correlates to the object application ID
of a virtual application in the home VAT).
volatile memory This specifies the number of bytes config of volatile memory that the terminal allocates and make available for the download of virtual applications other than the default virtual application.
home FAT_ID This field identifies a Feature Authorization Table (FAT) which must be used by the terminal as the terminal'a default FAT (home FAT).
(The Feature Authorization Table is described in Section 1.1.3).
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.
Name of Field Description config_for multi Thia field, if set to "yes" configures apps a terminal for Multiple Application Management.
The terminal is then considered to be in a configured for MAM state.
The terminal will then be able to receive other messages that have the configured for MAM
decoder condition in the DCII message preamble.
If this field is cleared to "no", the terminal will no longer be configured for MAM, nor enabled for MAM.
home VAT_ID This field identifies a Virtual Application Table (VAT) which must be used by the terminal as the terminal's default VAT (home VAT).
(The Virtual Application table is described in Section 1.1.3).
default application_IDThis field identifies an application that will be the default virtual application for the terminal.
(This ID correlates to the object application_ID of a virtual application in the home VAT).
volatile memory-configThis specifies the number of bytes of volatile memory that the terminal allocates and make available for the download of virtual applications other than the default virtual application.
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.
Name of Field Description Table subtype This field can be used to specify that this Virtual Object message contains a Feature Authorization Table (FAT).
FAT_ID This field specifies an identifier for the FAT
contained in this message.
The ID may be the same as the home FAT ID from the Virtual Application Config message described in Section 1.1.2).
Sequence number This field serves as a version number for the FAT.
If the sequence number for the FAT included in this message is different from the sequence number associated with the FAT with the same FAT ID already present in the terminal, then it implies that the FAT has changed.
Number of_fa This field specifies how many records FAT records are present in the Feature Authorization Table (FAT) included in this message.
fa record This is a list of FAT records constituting the Feature Authorization Table (FAT).
Each record identifies a feature of a virtual application. The records are described in more detail in Table 8 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.
Name of Field Description Table subtype This field can be used to specify that this Virtual Object message contains a Virtual Application Table (VAT).
VAT_ID This field specifies an identifier for the VAT
contained in this message.
The ID may be the same as the home VAT ID from the Virtual Application Config message described in Section 1.1.2).
Sequence number This field serves as a version number for the VAT.
If the sequence number for the VAT included in this message is different from the sequence number associated with the VAT with the same VAT ID already present in the terminal, then it implies that the VAT has changed.
Number of va This field specifies how many VAT
records records are present in the Virtual Application Table (VAT) included in this message.
va record This is an array of VAT records constituting the Virtual Application Table (VAT).
Each record identifies a virtual application.
The significant fields of a va record are described in Table 5.
One of the records may identify the virtual application whose default application_ID
was given in the Virtual Application Config message (described in Section 1.1.2).
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.
Name of Field Description Virtual application This field specifies which other control word optional fields are present in the rest of the va record.
The significant sub-fields of this field are described in a separate table.
Object application-ID This field contains a numeric identifier for the virtual application.
The identifier must be unique between all va records within a VAT.
VCT-source-ID This is a list of identifiers of programming "sources" which are associated with the virtual application.
The terminal may use these values to obtain a virtual channel to be tuned to before enabling the virtual application.
VCT application-ID This is a list of identifiers of "services"
associated with the virtual application.
The values and usage are the same as described for VCT source ID above.
Object version This is a list of version numbers for each of the versions, which can exist, of a virtual application.
The terminal will enable the highest version, which can be authorized.
Virtual application_tierThis is a list of authorization tiers for the virtual application, one per version. (All versions of an application may have the same or different tiers).
This specifies the authorization requirements for the versions of the virtual application.
Virtual name This is a multi-lingual text string of printable ASCII characters.
The name can be used for on-screen displays at the terminal.
1.1..s. ~ signiticant 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 features-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 Fanbodiments .
Name of Field Description Virtual applicationThis field specifies which other cont optional rol word fields are present in the rest of the va record.
The significant sub-fields of this field are described in a separate table.
Object application_IDThis field contains a numeric identifier for the virtual application.
The identifier must be unique between all va records within a VAT.
VCT-source_ID This is a list of identifiers of programming ~~sources~~ which are associated with the virtual application.
The terminal may use these values to obtain a virtual channel to be tuned to before enabling the virtual application.
VCT application_IDThis is a list of identifiers of ~~services~~
associated with the virtual application.
The values and usage are the same as described for VCT source ID above.
Object version This is a list of version numbers for each of the versions, which can exist, of a virtual application.
The terminal will enable the highest version, which can be authorized.
Virtual application_tierThis is a list of authorization tiers for the virtual application, one per version.
(All versions of an application may have the same or different tiers).
This specifies the authorization requirements for the versions of the virtual application.
Virtual name This is a multi-lingual text string of printable ASCII characters.
The name can be used for on-screen displays at the terminal.
Feature count If the virtual application_control_word has the features_included field set, then the feature count field is present and provides a count of the number of features of the application that are defined in this record.
fa record This is a list of records providing information about the identifiers of features of virtual applications, and the authorization requirements for those features.
These fa records are described in detail in Table 9.
1.1.3.5 Significant Fields of a virtual application control word in a va record of a VAT .
5 The following Table 7 describes the significant fields in the virtual-application-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.
Name Field Description of Versioncount Specifies the number of object_versiona existing for this virtual application.
VCT ce_ID count Specifies the number of VCT source-ID
sour fields present in the record.
VCT ID count Specifies the number of VCT application_ID
app-fields present in the record.
Downloadchannel~resentSpecifies whether a download_channel is present or not in the record.
Virtualname~resent Specifies whether a virtual name for the application is present or not in the record.
Features-included Specifies whether the va record contains information about application features.
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.
Name of Field Description Feature_ID Specifies an identifier for a specific terminal feature associated with a feature of virtual applications.
Feature tier Specifies the authorization requirements for the specific terminal feature associated with a feature of virtual applications.
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.
Name of Field Description Feature ID Specifiesidentifier for a specific an feature virtual application.
of a Feature tier Specifiesauthorization requirements the for the specificfeature of the virtual application.
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 object-application-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 object name and tune-object-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 5 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, 10 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 15 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-20 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 defined 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 ID 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.
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 S
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 services) 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 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 f eature .
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 5 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.
10 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 5 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 10 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.
15 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 services) 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 Digital 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 5 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 10 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 15 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 20 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 features 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 feature-count 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 5 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 10 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 15 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 20 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 25 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 Bit Mask 1 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 Num 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 5 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 10 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 15 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, 20 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 non-volatile memory, in order to preserve it through (warm) resets of the terminal.
32.
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.
Name of Field Description config-for multiThis field, if set to "yes" configures apps a terminal for Multiple Application Management.
The terminal is then considered to be in a configured for MAM
state.
The terminal will then be able to receive other messages that have the configured for MAM decoder condition in the DCII message preamble.
If this field is cleared to "no", the terminal will no longer be configured for MAM, nor enabled for MAM.
home VAT_ID This field identifies a Virtual Application Table (VAT) which must be used by the terminal as the terminal's default VAT (home VAT).
(The Virtual Application Table is described in Section 1.1.3).
default application_IDThis field identifies an application that will be the default virtual application for the terminal.
(This ID correlates to the object application ID
of a virtual application in the home VAT).
volatile memory This specifies the number of bytes config of volatile memory that the terminal allocates and make available for the download of virtual applications other than the default virtual application.
home FAT_ID This field identifies a Feature Authorization Table (FAT) which must be used by the terminal as the terminal'a default FAT (home FAT).
(The Feature Authorization Table is described in Section 1.1.3).
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.
Name of Field Description config_for multi Thia field, if set to "yes" configures apps a terminal for Multiple Application Management.
The terminal is then considered to be in a configured for MAM state.
The terminal will then be able to receive other messages that have the configured for MAM
decoder condition in the DCII message preamble.
If this field is cleared to "no", the terminal will no longer be configured for MAM, nor enabled for MAM.
home VAT_ID This field identifies a Virtual Application Table (VAT) which must be used by the terminal as the terminal's default VAT (home VAT).
(The Virtual Application table is described in Section 1.1.3).
default application_IDThis field identifies an application that will be the default virtual application for the terminal.
(This ID correlates to the object application_ID of a virtual application in the home VAT).
volatile memory-configThis specifies the number of bytes of volatile memory that the terminal allocates and make available for the download of virtual applications other than the default virtual application.
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.
Name of Field Description Table subtype This field can be used to specify that this Virtual Object message contains a Feature Authorization Table (FAT).
FAT_ID This field specifies an identifier for the FAT
contained in this message.
The ID may be the same as the home FAT ID from the Virtual Application Config message described in Section 1.1.2).
Sequence number This field serves as a version number for the FAT.
If the sequence number for the FAT included in this message is different from the sequence number associated with the FAT with the same FAT ID already present in the terminal, then it implies that the FAT has changed.
Number of_fa This field specifies how many records FAT records are present in the Feature Authorization Table (FAT) included in this message.
fa record This is a list of FAT records constituting the Feature Authorization Table (FAT).
Each record identifies a feature of a virtual application. The records are described in more detail in Table 8 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.
Name of Field Description Table subtype This field can be used to specify that this Virtual Object message contains a Virtual Application Table (VAT).
VAT_ID This field specifies an identifier for the VAT
contained in this message.
The ID may be the same as the home VAT ID from the Virtual Application Config message described in Section 1.1.2).
Sequence number This field serves as a version number for the VAT.
If the sequence number for the VAT included in this message is different from the sequence number associated with the VAT with the same VAT ID already present in the terminal, then it implies that the VAT has changed.
Number of va This field specifies how many VAT
records records are present in the Virtual Application Table (VAT) included in this message.
va record This is an array of VAT records constituting the Virtual Application Table (VAT).
Each record identifies a virtual application.
The significant fields of a va record are described in Table 5.
One of the records may identify the virtual application whose default application_ID
was given in the Virtual Application Config message (described in Section 1.1.2).
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.
Name of Field Description Virtual application This field specifies which other control word optional fields are present in the rest of the va record.
The significant sub-fields of this field are described in a separate table.
Object application-ID This field contains a numeric identifier for the virtual application.
The identifier must be unique between all va records within a VAT.
VCT-source-ID This is a list of identifiers of programming "sources" which are associated with the virtual application.
The terminal may use these values to obtain a virtual channel to be tuned to before enabling the virtual application.
VCT application-ID This is a list of identifiers of "services"
associated with the virtual application.
The values and usage are the same as described for VCT source ID above.
Object version This is a list of version numbers for each of the versions, which can exist, of a virtual application.
The terminal will enable the highest version, which can be authorized.
Virtual application_tierThis is a list of authorization tiers for the virtual application, one per version. (All versions of an application may have the same or different tiers).
This specifies the authorization requirements for the versions of the virtual application.
Virtual name This is a multi-lingual text string of printable ASCII characters.
The name can be used for on-screen displays at the terminal.
1.1..s. ~ signiticant 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 features-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 Fanbodiments .
Name of Field Description Virtual applicationThis field specifies which other cont optional rol word fields are present in the rest of the va record.
The significant sub-fields of this field are described in a separate table.
Object application_IDThis field contains a numeric identifier for the virtual application.
The identifier must be unique between all va records within a VAT.
VCT-source_ID This is a list of identifiers of programming ~~sources~~ which are associated with the virtual application.
The terminal may use these values to obtain a virtual channel to be tuned to before enabling the virtual application.
VCT application_IDThis is a list of identifiers of ~~services~~
associated with the virtual application.
The values and usage are the same as described for VCT source ID above.
Object version This is a list of version numbers for each of the versions, which can exist, of a virtual application.
The terminal will enable the highest version, which can be authorized.
Virtual application_tierThis is a list of authorization tiers for the virtual application, one per version.
(All versions of an application may have the same or different tiers).
This specifies the authorization requirements for the versions of the virtual application.
Virtual name This is a multi-lingual text string of printable ASCII characters.
The name can be used for on-screen displays at the terminal.
Feature count If the virtual application_control_word has the features_included field set, then the feature count field is present and provides a count of the number of features of the application that are defined in this record.
fa record This is a list of records providing information about the identifiers of features of virtual applications, and the authorization requirements for those features.
These fa records are described in detail in Table 9.
1.1.3.5 Significant Fields of a virtual application control word in a va record of a VAT .
5 The following Table 7 describes the significant fields in the virtual-application-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.
Name Field Description of Versioncount Specifies the number of object_versiona existing for this virtual application.
VCT ce_ID count Specifies the number of VCT source-ID
sour fields present in the record.
VCT ID count Specifies the number of VCT application_ID
app-fields present in the record.
Downloadchannel~resentSpecifies whether a download_channel is present or not in the record.
Virtualname~resent Specifies whether a virtual name for the application is present or not in the record.
Features-included Specifies whether the va record contains information about application features.
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.
Name of Field Description Feature_ID Specifies an identifier for a specific terminal feature associated with a feature of virtual applications.
Feature tier Specifies the authorization requirements for the specific terminal feature associated with a feature of virtual applications.
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.
Name of Field Description Feature ID Specifiesidentifier for a specific an feature virtual application.
of a Feature tier Specifiesauthorization requirements the for the specificfeature of the virtual application.
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 object-application-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 object name and tune-object-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 5 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, 10 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 15 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-20 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 defined 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 ID 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 (44)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 non-volatile 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.
the terminal maintains information in non-volatile 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.
the billing system bills for services provided on the terminal depending on the authorization state of the terminal.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US16123099P | 1999-10-22 | 1999-10-22 | |
| US60/161,230 | 1999-10-22 | ||
| PCT/US2000/028853 WO2001031924A1 (en) | 1999-10-22 | 2000-10-19 | Method and apparatus for authorization of software applications and features in digital communication terminals via a central billing system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2388155A1 true CA2388155A1 (en) | 2001-05-03 |
Family
ID=22580379
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002388155A Abandoned CA2388155A1 (en) | 1999-10-22 | 2000-10-19 | Method and apparatus for authorization of software applications and features in digital communication terminals via a central billing system |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP1243136A1 (en) |
| AU (1) | AU1214501A (en) |
| CA (1) | CA2388155A1 (en) |
| TW (1) | TW503359B (en) |
| WO (1) | WO2001031924A1 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7376625B2 (en) * | 2001-11-15 | 2008-05-20 | Nokia Corporation | System and method for activating individualized software modules in a digital broadcast environment |
| US7305484B2 (en) | 2001-12-07 | 2007-12-04 | Matsushita Electric Industrial Co., Ltd. | Media contents distribution system and method |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5003591A (en) * | 1989-05-25 | 1991-03-26 | General Instrument Corporation | Functionally modifiable cable television converter system |
| US5715515A (en) * | 1992-12-02 | 1998-02-03 | Scientific-Atlanta, Inc. | Method and apparatus for downloading on-screen graphics and captions to a television terminal |
| JPH06224997A (en) * | 1993-01-26 | 1994-08-12 | Rohm Co Ltd | Telephone set |
| US5608446A (en) * | 1994-03-31 | 1997-03-04 | Lucent Technologies Inc. | Apparatus and method for combining high bandwidth and low bandwidth data transfer |
| ES2243624T3 (en) * | 1997-03-21 | 2005-12-01 | Thomson Licensing | TRANSMISSION AND RECEPTION OF TELEVISION PROGRAMS AND OTHER DATA. |
-
2000
- 2000-10-19 CA CA002388155A patent/CA2388155A1/en not_active Abandoned
- 2000-10-19 EP EP00973655A patent/EP1243136A1/en not_active Withdrawn
- 2000-10-19 WO PCT/US2000/028853 patent/WO2001031924A1/en not_active Ceased
- 2000-10-19 AU AU12145/01A patent/AU1214501A/en not_active Abandoned
- 2000-10-20 TW TW89122093A patent/TW503359B/en not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| TW503359B (en) | 2002-09-21 |
| WO2001031924A1 (en) | 2001-05-03 |
| EP1243136A1 (en) | 2002-09-25 |
| AU1214501A (en) | 2001-05-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10743066B2 (en) | Methods and apparatus for selecting digital access technology for programming and data delivery | |
| US8165302B2 (en) | Key table and authorization table management | |
| RU2321965C2 (en) | Mpeg-table structure | |
| US7916755B2 (en) | Methods and apparatus for selecting digital coding/decoding technology for programming and data delivery | |
| US8050406B2 (en) | Key table and authorization table management | |
| CA2341248C (en) | Application data table for a multiservice digital transmission system | |
| KR20010041652A (en) | Multimedia terminal adapted for multiple users | |
| KR20060066173A (en) | Broadcast and reception systems, and receivers | |
| CN1605206A (en) | Method and system for conditional access | |
| CN1720736A (en) | System and method for reducing fraud in a digital cable network | |
| US20090151003A1 (en) | Receiver capable of managing conditional access software objects, download-based conditional access system including the receiver, and method for managing the conditional access software | |
| CA2387408C (en) | Method and apparatus for managing multiple applications in large scale networks | |
| WO2001031442A2 (en) | Management of volatile and non-volatile memory resources in digital communications terminals | |
| US6832323B1 (en) | Object and feature authorization for digital communication terminals | |
| JP2002503063A (en) | Configuration method and apparatus | |
| CA2388155A1 (en) | Method and apparatus for authorization of software applications and features in digital communication terminals via a central billing system | |
| CA2388210C (en) | Object and feature authorization for digital communication terminals | |
| EP1222818B1 (en) | Tuning of multiple application enabled digital communication terminals to access services | |
| KR20030051798A (en) | Controlling data-on-demand client access | |
| KR100947315B1 (en) | Method and system for supporting roaming based on downloadable conditional access system | |
| KR20000076400A (en) | Broadcast and Reception System, and Conditional Access System therefor | |
| HK1034840B (en) | Application data table for a multiservice digital transmission system | |
| MXPA00007588A (en) | Configuring method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued | ||
| FZDE | Discontinued |
Effective date: 20090728 |