GB2516319A

GB2516319A - A host device method and system

Info

Publication number: GB2516319A
Application number: GB1312989.5A
Authority: GB
Inventors: David Richard Hill-Jowett
Original assignee: Sony Europe Ltd; Sony Corp
Current assignee: Sony Europe BV United Kingdom Branch; Sony Corp
Priority date: 2013-07-19
Filing date: 2013-07-19
Publication date: 2015-01-21
Also published as: GB201312989D0

Abstract

A method of controlling a host device (e.g. television or set-top box, STB) comprises: receiving a broadcast application (e.g. providing additional services such as the red button) from a provider; running the received broadcast application and first middleware (e.g. conforming to an application programme interface (API) such as MHEG or HbbTV) on the host device; receiving a module (e.g. removable conditional access module, CICAM) application stored in a location, the module application requiring second (different) middleware to be run on the host device; and generating an identifier of the location of the stored module application, wherein the identifier indicates the second middleware and, in response to the identifier, running the second middleware. Running of first middleware may be stopped before running the second middleware. The module application may be retrieved from the identified location (e.g. Internet) and passed to the broadcast application for running on the host. Different identifier formats (e.g. module://root/file or module://AppDomainIdentifier/root/file) are used respectively in the cases where first and second middleware are the same or different.

Description

A Host Device, System and Method

BACKGROUND

Field of the Disclosure

The present invention relates to a host device, system and method.

Description of the Related Art

The "background" description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in the background section, as well as aspects of the description which may not otherwise qualiI' as prior art at the time of filing, are neither expressly or impliedly admitted as prior art against the present invention.

As background, the Digital Video Broadcast Common Interfaee+ (CE-) specification allows a broadcast application to launch an application from a conditional access module on a host. In this sense, a host is a device where modules (including the conditional access module) can be connected, such as a television or set-top box or the like. When a broadcast application, such as providing additional services, is run the host must inform the broadcast application of any module applications that can be run on the host. An example of a broadcast application is an additional service such as the "red button" feature in the UK where a menu of other content related to the broadcast content is displayed when a user presses a red button on the controller of the host. This is part of the technical requirements for CI± specification v.1.4 (see at the time of filing hftp://w.dvb.org/groups modules/technical rnodule/tmcinlus/index.xml) In this instance, when a user presses the red button, the host passes to the broadcast application 1) a name suitable for presentation to the user, 2) an icon suitable for presentation to the user and 3) launching infonnation for the application. in examples, the launching information may be a Unique Resource identifier (URT) or the like that identifies the location of the module application within the CICAM.

This is briefly described in flow chart 1000 of Figure 6. The flow chart starts at step 1010. The host waits at step 1020 for the start of a broadcast application. For example, the host may wait ibr a user to press the red button. After the broadcast application starts, the host informs the broadcast application of module applications (step 1030). The broadcast application retrieves the module application from the IJR1 (step 1040). The broadcast application then runs on the host and die flowchart ends (step 1050).

In this scenario, the inventors of the present application have identified a previously unforeseen issue.

In the example above, there is an assumption that the host is running middleware conforming to one particular application programme interface (API) such as MHEGTM or HbbTV ® or the like, and the broadcast application wishes to access a module application within the Conditional Access Module that requires the same middleware to be run on the host. The inventors have considered the previously unforeseen scenario that the host and module application may run different middleware.

It is an aim of embodiments of the disclosure to address this issue.

SUMMARY

There is provided a host device comprising receiving circuifty for receiving a broadcast application from a provider; control circuitry for running i) the received broadcast application, and ii) first middleware on the host device, and a connector for receiving a niodule application stored in a location, S wherein the module application requires second middleware to be run on the host device, wherein the control circuitry is configured to generate an identifier that identifies the location of the stored module application, wherein the identifier indicates the second middleware, and in response to the identifier, the control circuitry is configured to run the second middleware.

The foregoing paraaphs have been provided by way of general introduction, and are not intended to limit the scope of the following claims. The described embodiments, together with flrther advantages, will be best understood by reference to the following detailed description taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF TIlE DRAWINGS

A more complete appreciation of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein: Figure 1 is a schematic diagram of a host device with a CAM and a smart card; Figure 2 is a schematic diagram of a conditional access (CA) system incorporating the host device of Figure 1; Figure 3 is a schematic diagram illustrating the operation of the system of Figure 2; Figure 4 is an EPG broadcast application; Figure 5 is a flow chart describing embodiments of the disclosure;

Figure 6 is a prior art flow chart; and

Figure 7 is an ancillary flowchart

DESCRIPTION OF TILE EMBODIMENTS

Referring now to the drawings. wherein like reference numerals designate identical or corresponding parts throughout the several views.

Referring now to Figure 1, a host device 10 is shown here as a television set but could be, for example, a set lop box (noting that the expression "set top" does not imply, to the skilled person, any requirement for a particular physical position of the device in use). The host device 10 receives an access-controlled television signal 15 via a broadcast data path. This could he, for example, a satellite television signal received by a satellite dish (not shown), a terrestrial television signal, a cable television signal or the like, although other types of television signal will be discussed below. The host device 10 has a PCMCIA slot 20 which includes electrical cotmections and a physical space for a plug-in module, both according to the PCMCIA standard. Of course, the host device 10 may receive the access-controlled television signal via other methods such as over Internet Protocol packets (IF), or the like A Ci -P conditional access module, referred to as a CICAM 30, is a PCMCIA module which can be plugged into the PCMCIA slot 20. When the CICAM 30 is fully plugged into the slot 20, electrical connections are made between connectors on the CICAIVI 30 and cooperating connectors within the slot 20. Note that although the embodiments are described with respect to a CI + CAM, other types of removable CAM are applicable to the present techniques. Further, it is noted that other form-factors are envisaged ucli as Universal Serial Bus or the like.

Thc CICAM itself may be a cardless module or may have a slot 40 into which a so-called smart card 50 may be inserted. The stuart card is removable and carries information defining a current user of the content receiver in a tamper-proof, secure and non-volatile form. When the smart card is fully inserted in the slot 40, a data connection is formed between the smart card 50 and the CICAM 30, either by using cooperating electrical connectors on the smart card 50 and within the slot 40, or by using a known contactiess connection technique in which data is transferred wirelessly over a very short range.

Figure 2 schematically illustrates the host device 10 in the context of a conditional access system.

A so-called head end 60 represents the source of the access-controlled television signal 15. The head end may represent, for example, an uplink station of a satellite broadcaster or a signal distribution centre of a * terrestrial or cable broadcaster. The CA system scrambles content at the head end using a CA system encryption. The Ii cad end can also introduce other CA-related information into the encrypted data stream * 30 which enables the CICAM to descramble the content and to manage the subscriber's (user's) access and entitlements.

The head end 60 sends the television signal 15 to the host 10 which in turn passes the signal to the CICAM 30 for decryption of the access control encryption. Located within the television signal 15 is one or more broadcast applications. Broadcast application is a tenn of art and provides additional services from the broadcaster. This may include a pay-TV purchasing application or additional content related to the content currently being displayed. The CICAM 30 then re-encrypts the signal using a local encryption and sends the re-encrypted signal back to the host 10 via the PCMCIA connection. The host decrypts the signal received from the CICAM 30 for display on a display screen or for supply to another device 70 such as a hard disc based video recorder.

Figure 3 is a schematic diagram illustrating the operation of thc system of Figure 2. The detailed operation of the system of Figure 3 is described in the CJ Plus Specification 1.3.1(2011-10), available (at the time of filing) at http://www.ci-plus.com/data!ci-plus_specification_vl.3.1.pdf This document is incorporated by reference into the present description. The present description of Figure 3 simply provides an overview of that detailed operation, for the purposes of placing the subsequent description into the appropriate technical context.

As before, Figure 3 shows the head end 60 (which receives a content signal from a content provider 90), the host device 10, the CICAM 30 and the smart card 50. The signal 15 is shown passing from the head end 60 to the host device 10. The secure interface 80 between the host device 0 and the CICAM 30 is referred to as the common interface.

Conditional Access Known CA systems provide techniques by which a user can be denied or allowed access to a digital television stream. Access is provided only to those subscribers or users with valid payment accounts. In practical terms, a user is provided with a smart card 50 identifying that user in (ideally) a tamper-free way, and the system is set up so that only users with valid smart cards are able to obtain access t.o the access-controlled content.

Access control is provided by the use of scrambling and encryption. The content signal is scrambled with an 8-byte control word, witich is changed frequently (up to several times per minute) to avoid the CA system being compromised by outside knowledge of the control word. The control words are transmitted to the receiver's CICAM, for deserambling of the scrambled content, in an encrypted form as an entitlement control message (ECM). The CICAM decrypts the control word to allow descrambling of the access-controlled content only when it is authorised to do so by receipt of an entitlement management message (EMM). EMMs are specific to each user or group of users; the CICAM confirms the rights which an EMM provides by comparing the user identification provided in the EMM with user information provided in the smart card 50. The EIVIMs can be sent less frequently than the ECMs, with intervals between successive EMMs in current commercial systems varying betsveen 12 minutes and six weeks.

ECMs and EMMs themselves are well known message types in MPEG television distribution systems. The format of their payloads can be specific to the CA system in use, with the differences between formats often being semantic rather than having technical significance.

HeadEnd The head end 60 comprises a CA encryptor 61, a key generator 62, an entitlement control unit 63 and a multiplexer and modulator 64.

The content provider 90 supplies content (such as television signals) to the head end 60. The head end 60 applies conditional access (CA) scrambling and encryption to the content. Although CA is noted here, the skilled person will appreciate any digital rights management (DRM) is also applicable.

More specifically, the CA enciyptor 61 scrambles the content using a. CA key as a control word. The CA S key is generated by the CA key generator 62. The scranihled content generated by the CA encryptor is supplied to the multiplexer and modulator 64.

The CA key is also provided to the entitlement control unit 63, which generates RCMs based on the CA keys and EMMs based on subscriber data defining which subscribers are entitled to descramble which content streams. The ECMs and EMMs are supplied to the multiplexer and modulator 64. One or more scrambled content streams from the CA eneryptor 61, one or more unscrambled (open access or "free to air") content streams and the entitlement conirol messages are multiplexed together to form a transport stream such as an MPEG2 transport stream. Known formats are used to carry the content data, the ECMs and the EMMs. The ECMs, BMMs and data defining the type of scrambling used on each elementary stream (corresponding to individual scrambled content streams) are provided in a known format in a conditional access table (CAT) which has a predetermined proam identifier (P1 D) of OxOOl, so that. the CAT can he recognised at the CICAM.

The multiplexed transport stream is then modulated by the multiplexer and modulator 64 for transmission as a cable, satellite or terrestrial broadcast signal 15.

Host Device The host device 10 comprises a tuner ii, a demodulator and demultiplexer 12, a demultiplexer ("demux") 13 and a CC (content control) decryptor 14. Note that the host device may have other additional functions, such as network (IPTV) television reception.

Depending on the type of broadcast signal 15, the tuner acts to transform the received signal back to baseband, so that the demodulator and demultiplexer 12 can select and demultiplex a single elementuy content stream and associated CAT data from the received signal. The content stream and ECM / 13MM.

data are passed via the common interface 80 to the CICAM 30.

in the case of access-controlled content data, at this stage the content data is still scrambled as it is passed via the common interface 80 to the CICAM 30. This part of the transmission over the common interface 80 is therefore secure by virtue of the CA encryption.

Assuming the ECM and EMM allow it, the CICAM 30 descrambles the content data and re-encrypts it using a content control (CC) encryption. The way in which this is done will be described below. The CC encrypted data is returned to the host device 10 where it is demultiplexed by the demux 13 and decrypted by the CC decryptor 14, so that it can be displayed or passed to another device 70 as clear content.

CICAM

The C1CAM 30 comprises a CA decryptor 31, a CA key generator 32, a CC encryptor 33 and a CC key generator 34. The CICAM 30 also comprises a memory 35. Within the memory 35 are stored files which may be retrieved by the broadcast application received from thc head cnd 60. These flies consist of the module application. The location of each file within the memory 35 is provided by a S Unique Resource Identifier (U RI). The detailed association of the file with the URI will he explained later.

The CA deciyptor 31 and the CA key generator 32 may be considered as an access control unit for decoding access-controlled broadcast content or other data. The CC key generator 34 and the CC encryptor 33 of the CICAM 30, and the demtiltiplexer 13 and the CC decryptor 14 of the host device 10 cooperate to provide an encrypted communication link (the common interface 80) for decoded access-controlled encoded broadcast content, between the CICAM and the host device.

The CA deciyptor 31 uses keys generated from received ECMs and EMMs by the CA key generator 32, using checks of the user's identity from the smart card 50, to descramble the received access-controlled content. This part of the operation of the CIAM uses known CA techniques to retrieve and apply the CA keys.

Clear content data is passed from the CA dectyptor 31 to the CC encryptor 33. However, as this data transfer is entirely internal to the CICAM, it can be rendered secure and tamper proof by known techniques such as by providing the CA decryptor 31, the CC encryptor 33 and the clear content interface within a single integrated circuit device.

The CC encryptor 33 encrypts the descrambled content using a CC key supplied by the CC key generator 34. This key is established by a secure interchange between the CICAM 30 and the host device 10, and is specific to that CTCAM-host device pair. The CC-encrypted content is passed over the common interface 80 to the host device 10. Therefore, this part of the common interface is also secure, as the content data is CC-encrypted as it passes to the host device.

Key Exchange The CICAM 30 and the host device 10 both contain logic, firmware or software providing algorithms for Diffie-Hellman (DII) secure key exchange, hashing and encryption using the known algorithms SIIA-256, DES and AES, respective certificates issued by a certifying authority such as Ci Plus LLP, and private keys with the corresponding public keys.

When the CICAM 30 is fir st associated with the host device 10, the CICAM 30 initiates an authentication process with the host device 10. In this process, each device verifies the other's certificate, and the DTT key exchange process takes place so as to securely share keys between the two devices. In particular, the CICAM first requests that the host device provides its certificate data. The CICAM verifies the signature on the host device's certificate. The same process is then carried out by the host requesting and verifying the CICAM' s certificate. The CICAM and the host then each demonstrate that they possess the private key corresponding to the public key in the certificate by signing a DII public key and sending it to the other device for validation. [he CICAM then obtains and verifies an authentication key AXII from the host. The CICAM and host start to compute and exchange key data for the encryption and authentication of data sent over the common interface 80. In this way, the key, key pair or other key information established by the CICAM and the host for communication over the common intciface 80 is S specific to that CICAM-host pair.

After authentication, the CICAM also starts to compute the CC key. The CICAM can also instruct the host device to compute the CC key. The CC key is then used as described above to encrypt content data passed from the CICAM 30 to the host dcvicc 10, according to the AES algorithm.

Therefore, it will be understood that the keys used for the secure common interface 80 are specific to a particular CICAM-host pair.

During operation of the host device, a broadcast application may be started. This broadcast operation may be started by a user, for example, by running a certain function of the host device. In this particular example, the user may wish to view a pay-TV channel from the Electronic Program Guide menu.

When selecting the Electronic Program Guide (EPU) menu, the host device 10 runs a broadcast application. Thc host lO informs the broadcast application of any module applications, for example, any module applications stored within the CICAM. In this sense, the CICAM is one example of a module. A module is a device, not working by itself, that is designed to run specialised tasks in association with the host, such as an electronic program guide application module, or to provide resources required by an application running on the host but not provided directly by the host.

In particular, as supported in the C1+ standard the host 10 may pass to the broadcast application the launch information for each of the module applications located within the CICAM. This launch information includes the root of the file and the file name of the file. In other words, the launch information for the module application within the CICAM is "root/file".

As the broadcast application knows the launch information and the module upon which the module application is stored (the CTc.AM 30), the broadcast application generates a Unique Resource Identifier identifying the location of the computer code to form the layout of the EPO. This URI is passed to the host device 10 who fetches the computer code from the identified location. Specifically, the broadcast application gen crates the URT CL//root/file Where Cl indicates to the host device that the computer code is located in the CICAM 30, the root/file is the file location within the memory 35 within the CICAM 30 where the file is stored.

As would be appreciated, although this code is specified as being located on the CICAM, and so the URI indicates this, the invention is no way limited by this and the code may be]ocated instead within the host 10 itself or within any module. Indeed, it may be located on the Internet.

In order to run the computer code of the module application, the host device 10 will be requested to run particular middleware which complies with an Application Program Interface (API) in the field of televisions such as EIbbTV (10 or MHEG. In this case, we will assume that the host device 10 will run 1-IbbTV middleware when the EPG menu is desired. Prior to the EPG menu being displayed, the host device 10 is also running the HbbTV middleware.

As the host device 10 is running ilbbTV middleware and the EPG menu requires HbbTV middleware, the EPG layout file (module application) is retrieved from the IJRI and run by the broadcast application. Thc EPG menu is displayed and populated with data from the television signal 15. The data retrieved from the television signai populates area 420 in Figure 4 which describes the programs broadcast at any particular time.

The layout of the EPG is provided by the EPG layout file retrieved from the URI. So, the channel names 415, the icons describing other functions available within the host device such as icons 410A, 41 OB and 41 OC are provided by the EPU layout file retrieved from the Uffi. Also, the area 405 is defined by the file, Area 405 is the area hi which the images in the television signal are displayed.

The on-demand icon 425, the pay-tv icon 430 and the search icon 435 are provided by the retrieved EPG layout ific.

If the user presses button associated with the pay-TV service 430 on the remote commander (not shown), a second broadcast application is run.

As the pay-TV service is a subscription service, the pay-TV module application may be also located within the CICAM 30. l'herefore, when the pay-TV service application is requested, the module applications within the CICAM 30 arc provided to the second broadcast application by the host device 10.

Tn some instances, the pay-TV service application (module application) required by the broadcast application may be designed to run on HbbTV middleware, This is conveyed to the broadcast application because the module application will provide to the host device 10 the middleware environmeuit upon which it operates. The broadcast application confirms that the middleware enviromnent is the same as that currently running on the host device 10. The broadcast application then generates the URI as being CI://rootlfile as explained above. This is because the middleware required by the module application is the same as that currently running on the host dcviec 10.

however, in some instances, the pay-TV service application (or any module application) required by the broadcast application may be designed to run on MHEG niiddleware. In other words, the module application may run on middleware different to that currently running on the host device 10. In this instance, the broadcast application needs to inform the host device 10 lo create a new niiddlcware environment to run the broadcast application. This is communicated to the host device 10 by the broadcast application generating a URI of the fonn Cl:J!AppDomainldentifier/root'fil e Where CI indicates to the host device that the computer code is located in the CICAM 30, the AppDomainldentifier indicates to the host device both that a new middleware environment needs to be created and also which middleware environment to create and root/file is the file location within the memory 35 within the CICAM 30 where the file is stored.

So, in the specific example above, the AppDotnainldentifler will be MHEG. The AppDomainldentifier does not identifr a different file location within the CICAM 30, but rather is used to indicate to the host device 1 0 to run a new middleware, and also identifies which middleware to run.

in the case that the middleware of the module application is the same as that running, the AppDomainidentifler is not present in the (JR I. After the host device 10 starts the MPEG middleware, the host device 10 retrieves the pay-TV service application from file location Ci://rootlflle and passes the pay-TV service application to the broadcast application. The broadcast application can then run the pay-TV service application on the host device 10.

In the event of a new middleware being required, the host device 10 may need to stop running the current middleware. Alternatively, an additional middlcware may be run.

A flowchart 500 explaining the operation of embodiments of the disclosure is shown in FigureS.

The flowchart starts in step 502. The broadcast application is then launched in step 505. This may be started in response to a user request. After the broadcast application is launched the host device 10 provides a list of applications located in particular modules to the broadcast application. In embodiments. this maybe applications within the CICAM 30. This is step 510.

]n order for the broadcast appiicatioi to launch, the host device 10 must launch the module application (step 515)-For this to occur, appropriate rniddleware must be running on the host device 10.

The module application is passed to the host device 10. With the module application is passed details of the middleware required to also run the module application. This module application and the details of the middleware are passed to the broadcast application (step 520). The broadcast application then determines whether the middleware running on the host device 10 is the same as the middleware required to launch the module application (step 525).

In the event that the iniddleware is the same, (i.e. the "yes" path is followed), the broadcast application generates the TJRI identifying the location of the module application. In this case, as the module application is located on the CICAM 30, and the middleware is the same, the tilt! generated by the broadcast application is of the form CI://root/file as explained above. This generated URI is sent to the host device 10. This is step 530. As the UIU is of the form CI://rootlflle, the host device 10 knows to keep the same middleware running on the host device lO. This is step 540.

In the event that the middleware is not the same (i.e. the "no" path is followed), the broadcast application generates the TiRE identi1iing the location of the module application, lit this case, as the module application is located on the CICAM 30, and the middleware is not the same, the URI generated by the broadcast application is of the form (21:/I AppDomainldentifier Irootlfile as explained above. This generated URI is sent to the host device 10. This is step 535. As the TJRI is of the form CI:/I AppDomainldentifier Irootlfilc, the host device 10 knows to run the middleware identified in the AppDomainldentifler part of the file structure. This may require the currently running middleware to stop running. This is step 545.

In either of the two cases above, after the appropriate is running on the host device 10, the host device 10 retrieves the module application from the memory 35 of the CICAM 30. Specifically, the host device 10 retrieves the module application from the URI Cl://root/file within the memory 35. This is step 550.

The process then ends (step 555).

Although the foregoing is described with reference to the broadcast application running the module application, the disclosure is not so limited. For example, the module application may run the broadcast apphcation and/or the host device may run either or both of the module application or the broadcast application.

Although the foregoing is described with reference to the CICAM 30 having the module application loaded thereon, the disclosure is not so limited. For example, the module application may be located on the Internet. In this more general case, the format of the identifier will be of the form module://root/file and module://Domainldentifier/rootlfile, where niodule identifies the module (which may be connected to the host device over a network) in which the module application is stored.

Although the foregoing has been described with reference to CJCAM Obviously, numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may he practiced otherwise than as specifically described herein.

In so far as embodiments of the invention have been described as being implemented. at least in part, by software-controlled data processing apparatus, it will be appreciated that a non-transitory machine-readable medium canying such software, such as an optical disk, a magnetic disk, semiconductor memory or the like, is also considered to represent an embodiment of the present invention.

Ancillary Information in the Description

One aspect of the proposal is to use the Auxiliary file system resource for the broadcast application to gain knowledge of the available CICAM applications and to launch the CICAM application Other aspects are: Alternatively, a broadcast application could start and in turn launch the module application. For example, app-toapp communication can facilitate such a behavior.

If a broadcast application is running, then a Module application can never be started by a Module request, but this does not prevent the broadcast application launching the module application.

Further other aspects are: The Host shall provide the information below about an available Module application to a Broadcast application and the information below about available Broadcast applications to a Module application.

Name suitable for presentation to the end-user Icon, if available, suitable for presentation to the end-user launching information for the application 1 CICAM file retrieval 1.1 General CICAM file retrieval is realised via a new Cl Plus resource, namely the auxiliary file system resource. It provides a generic mechanism for a CICAM to offer files or applications to the Host. The method used by a Host or running application to access this resource depends on the corresponding Host application environment and is out of scope of the present document.

This new resource inherits most of its messages and underlying semantics from the Application MMI resource v2, which is defined in clause 14.5 of the CI Plus V1.3 specification.

The Host provides an auxiliary file system resource with resource identifier 0x0091004 1. This resource allows: * the retrieval of files from the CICAM by the Host, for example to be used by applications running in the Host orfor the running application on the Host to launch an application from the CICAM.

* the ability for the Host to gain details of available CICAM applications, for example to inform the running application of available applications on the CICAM.

The file system is read-only and offers the possibility to request particular known files and receive them if they are present, otherwise an error is returned.

A CICAM offers its file system to the Host using the FileS ystemoffer() APDU. The Host requests a file using the Filekequest() APDU. Files are sent by the CICAM to the Host using the Fi/eAcknowledge() APDU.

The CICAM shall provide only one file system per auxiliary file system resource session. If the CICAM has multiple file system offerings, it shall request one session to this resource for each file system it offers.

The Host shall support a minimum of three sessions to this resource.

If the CICAM needs to stop access to its file system for any reason, for example due to a file system update, it shall close the session to the auxiliary file system resource.

An example call flow for file retrieval is depicted in Figure 7.

1.2 File system offer APDU This APDU specifies the file system that is provided by the CICAM. Its syntax is shown in table 1.

The Host shall reply to the CICAM using the FilesystemAck message APDU.

Table 1: FileSystemOfferAPDu Syntax No. of bits Mnemonic FilesystemOffer() C FilesystemOtfer_tag 24 Uimsbf

length_field()

DoniainldentifierLength 8 Uinisbf for (i = 0; 1 <DomainldentifierLength; i ++) { Domainldentifier 8 Uinisbf J. FileSystemOffer_tag: This 24 bit field with value 0x9F9400 identifies this message.

length_field: Length of APDU payload!n ASN.1 BER format as defined in EN 50221, clause 8.3.1.

DomainldentifierLength: This 8 bit field specifies the number of bytes of Domainldentifier following.

Domainldentifier: The bytes provide information needed by the Host to identify the file system provided by the CICAM. The Domalaldentifier can be the AppDomainldentif!er as used by the Application MMI resource. The Domainidentifier field has no specific format. The meaning of these bytes is defined by the middleware and is out of scope for this specification. Some examples of possible

contents of the Domainldentfier field are:

* A URL that can be used to idefflify the file system, and which is owned by the organisation managing the file system, for example: "www. operator comlcifilesystein". APJs may use this value as a precursor of URLs or file paths to access the files offered by the CICAM through this resource.

* A TJ1JID, as described hi RFC4122, for example: "urll:uuid:f8 ld4fae-7dec-l ldO-a765-OOaOc9leóbth".

* A DYB-registered identifier.

1.3 File System Ack AFDU This APDU is sent by the Host to confirm if the requested application domain is not supported or not by the Host.

Table 2: FileSysternAck APDU Syntax No. of bits Mnemonic PileSystemAck() { FilesystemAck tag 24 uimsbf Iength_fleld() AckCode 8 bslbf FilesystemAck_tag: This 24 bit field with value 0x9F9401 identifies this message.

length_field: Length of APDU payload in ASN.1 BER format as defined in EN 50221, clause 8.3.1.

AckCode: This 8 bit field communicates the response to the FileSystemOffer.

Table 3: AckCode values AckCode Meaning OxOO Reserved forfuture use.

0x01 OK The application environment is supported by the _________________ Host. __________ 0x02 Wrong API The application environment is not support by _______________________________ the Host ____________________ Ox 03 to Ox [F Reserved for future use.

If the Host responds with AckCode equal to wrong API", the CICAM shall close this session of the resource, freeing up resource for other file systems it may offer.

1.4 File request APDU This APDU is copied from the Application MMI v2 resource and is fully described in clause 14.5.1. of Cl Plus V1.3.

It allows the Host to support file caching and to discover reqtypes supported by the CICAM (file, data, hash, ...).

1.5 File acknowledge APDU This APDU is copied from the Application MMI v2 resource and is fully described in clause 14.5.2 of CI Plus V1.3.

1.6 AppAbortRequestAPDU This APDU is copied from the Application M MI resource and is fully described in clause 14.4.4 of Cl Plus V1.3 and clause 6.5.6 ofTS 101 699. This APDU is only used when the Application is coming from the CICAM.

1.7 AppAbortAckAPDU This ARDU is copied from the Application MMI resource and is fully described in clause 6.5.7 of TS101699. This APDU is only used when the Application is coming from the CICAM.

1.8 File Application Offer Request APDU This APDLJ request the CICAM to send information of the Applications that are available for the file system that is provided by the CICAM. Its syntax is shown in table 4.

Table 4: FileAppofferReq APDU Syntax No. of bits Mnemonic FileAppOfferReq() { FileAppOfferReq_Tag 24 uinisbf Iength_fleld() FileAppOfferReq_Tag: This 24 bit field with value 0x9F9406 identifies this message.

1.9 File Application Offer Reply APDU This APDU is sent in response to the FileAppOfferReq() APDU, it specifies the Applications that are available for the file system that is provided by the CICAM.

The method used by a I-lost to communicate this information to the running application depends on the application environment and is out of scope of the present document.

Its syntax is shown in table 5.

Table 5: FileAppOfferReq APDU Syntax No. of bits Mnemonic FileAppOfferReply() { FileAppOffcrRcply_Tag 24 uimsbf

length_fieldO

number_applications 8 uimsbf for (i = 0; i < n; i -i-+) { AppNameLength 8 uimsbf lnitialObjectLength 8 Reserved 7 Icon flag for (I = 0;i < AppNameLength; I 8 uimsbf AppNarne } 16 uimsbf for (i = 0; i < InitialObjectLength; i ++) { InitialObject 8 uimsbf if (Icon_flag == 1){ lconLocationLength 8 uimsbf for (i = 0; I < IconLocationLength; i++) { IconLocation 8 uimsbf FileAppOfferReply_Tag: This 24 bit field with value 0x9F9407 identifies this message.

number_applications: the number of applications that are available for the file system. If this value is set to OxO, then the CICAM does not have any applications for this file systems but may still have files which a running application may tempt to use.

AppNameLength: This 8 bit field specifies the length of the string of bytes that specifies the Application Name AppName: These bytes specify the name of the Application which shall be suitable for presentation to the end-user lnitialObjectLength: This 8 bit field specifies the length of the string of bytes that specifies the initial object.

InitialObject: These bytes specify the initial object in an application domain specific way. The encoding of the file source within the InitialObject is a subject for application domain specification.

icon_flag: This 1 bit field indicates if there is an image available to present as an icon to the user in. The icon image is provided to the running application for presentation.lconLocationLength: This 8 bit field specifies the length of the string of bytes that specifies the icon location.

IconLocation: These bytes specify the location of the Icon in an application domain specific way.

1.10 Changing Application environments The running application on the Host may request the Host to launch a CICAM application, from time to time the environment may not be the same. In this case the running application needs to inform the Host to start up a new middleware environment, which may require the current middleware environment to be terminated. For the running application to change environment, it shall insert the Domainldentifier (which in this instance is the AppDomainldentifier) into the URI of the requested application.

If the running application environment is the same then the application shall not insert this Domainldentifier (AppDomainldentifier).

For Example:

o Cl://root/file Same Application Environment * CI://AppDomainldentifier/root/file Different Application Environment

1.11 Auxiliary file system resource summary

Table 6 below provides a summary of the attributes of the auxiliary file system resource.

Table 6: Auxiliary tile system resource summary

___________ Resource ______ ______ Application Object Direction Name Resource Class Type Vers. APDU Tag Tag value Host CAM _____________ Identifier _______ _______ _______ _____________________ ____________ ________________ Auxiliary file 0091 00 145 I I FileSystemOffer 9F 9400 4 system 41 FileSystemAck 9F 94 01 9 FileReguest 9F 94 02 9 _____ FileAcknowledge 9F 94 03 ________ AppAbortReguest 9F 94 04 (-9 AppAbortAck 9F 9405 44 FileAppofterReg 9F 94 xx 9 __________ ______ ______ FileAppOfferReply 9F 94 xx ____________ 1.12 Auxiliary file system and Application MMI resource coordination The Auxiliary File System and Application MMI Resources both provide access to the CICAM file system.

s when both resources are open the Host shall use the resource according to the following rules: * Broadcast applications shall use the Auxiliary File System resource.

* CICAM applications shall use the Application MMI resource.

NOTE: A CICAM application is any application launched by the CICAM by issuing the RequestStart to the Application MMI resource, or any application subsequently launched by a CICAM application.

Clauses Features and aspects of the above disclosure can be written as in the following numbered para'aphs.

1 A host device comprising receiving circuitry for receiving a broadcast application from a provider; control circuitry for running I) the received broadcast application, and ii) first middleware on the host device, and a connector for receiving a module application stored in a location, wherein the module application requires second middleware to be run on the host device, wherein the control circuitry is configured to generate an identifier that identifies the location of the stored module application, wherein the identifier indicates the second middlcware, and in response to the identifier, the control circuitry is configured to run the second middleware.

2. A host device according to clause 1, wherein the control circuitiy is configured to stop running the first middleware before running the second middlewarc.

3. A host device according to clause I or 2, wherein the control circuitry is configured to reftieve the module application from the identified location and is further configured to pass the retrieved module application to the broadcast application for running on the host device.

4. A host device according to clause 1, 2 or 3, wherein the connector is configured to he connected to a removable conditional access module.

5. A host device according to clause 1, 2 or 3, wherein the connector is configured to be connected to the internet for retrieval of the module application therefrom.

6. A host device according to any one of clause 1 to 5, wherein in the event that the first middleware and the second middleware is the same, the identifier is of the form module:J!rootifile where module identifies the module in which the module application is stored; root identifies the root of the module upon which the module application is stored; and file identifies the file name of the module application.

7. A host device according to anyone of clause ito 6, wherein in the event that the first middleware and the second middleware is different, the identifier is of the form module:!! AppDomainldentifier!rootlfile where module identifies the module in which the module application is stored; AppDomainldentifier identifies the second middleware; root identifies the root of the module upon which the module application is stored; and lile identifies the file name of the module application.

8. A system comprising a host device according to any preceding clause and an access control module coupled to the host device via the connector, wherein the access control module comprises a memory in which the module application is stored.

9. A method of controlling a host device, the method comprising receiving a broadcast application from a provider; running i) the received broadcast application, and ii) fir st middleware on the host dcvicc, and receiving a module application stored in a location, wherein the module application rcquires second middlcwarc to be run on thc host device, and generating an identifier that identifies the location of the stored module application, wherein the identifier indicates the second middleware, and in response to the identifier, running the second middleware.

10. A method according to clause 9. comprising stopping running the first iniddleware before running the second middleware.

11. A method according to clause 9 or 10, comprising retrieving the module application from the identified location and passing the retrieved module application to the broadcast application for running on the host device.

12. A method according to clause 9, 10 or 11, comprising connecting the host to a removable conditional access module.

13. A method according to clause 9, 10 or ii, comprising connecting the host to the internet for retrieval of the module application therefrom.

14. A method according to clause 9 to 13, wherein in the event that the first middleware and the second middlewarc is the same, the identifier is of the fonn moduleil/root/file where module identifies the module in which the module application is stored; root identifies the root of thc module upon which the module application is stored; and file identifies the file name of the module application.

15. A method according to clause 9 to 13, wherein in the event that the first middleware and the second middleware is different, the identifier is of the form module:!! AppDomainTdentifier /root!file where module identifies the module in which the module application is stored; AppDomainldentifier identifies the second middlcware; root identifies the root of the module upon which the module application is stored; and f ile identifies the file name of the module application.

16. A computer program containing computer readable instructions which, when loaded onto a computer, eonfigurc the computer to perform a method according to clause 9 to 15.

17. A storage medium configured to store the computer progarn of clause 16 therein or thereon.

Claims

CLAEVLS1. A host device comprising receiving circuitry for receiving a broadcast application from a provider; control circuitry for running i) the received broadcast application, and ii) first middleware on the host device, and a connector for receiving a module application stored in a location, wherein the S module application rcquires sceond middleware to be run on the host device, wherein the control circuitry is configured to generate an identifier that identities the location of the stored module application, wherein the identifier indicates the second middleware, and in response to the identifier, the control circuitry is configured to run the second middleware.
2. A host device according to claim 1, wherein the control circuitry is configured to stop running the first middleware before running the second niiddleware.
3. A host device according to claim I, wherein the control circuitry is configured to retrieve the module application from the identified location and is further configured to pass the retrieved module application to the broadcast application for running on the host device.
4. A host device according to claim I, wherein the connector is configured to be connected to a removable conditional access module.
5. A host device according to claim 1, wherein the connector is configured to be connected to the internet for retheval of the module application therefrom.
6. A host device according to claim 1, wherein in the event that the first middleware and the second middleware is the same, the identifier is of the fonn module://root/file where module identifies the module in which the module application is stored; root identifies the root of the module upon which the module application is stored; and file identifies the file name of the module application.
7. A host device according to claim i, wherein in the event that the first middlcware and the second middleware is different, the identifier is of the form module]! AppDomainldentifier!rootlfile where module identifies the module in which the module application is stored; AppDomainldentifier identifies the second middleware; root identifies the root of the module upon which the module application is stored; and file identifies the file name of the module application.
8. A system comprising a host device according to claim 1 and an access control module coupled to the host device via the connector, wherein the access control module comprises a memory in which the module application is stored.
9. A method of controlling a host device, the method comprising receiving a broadcast application from a provider; running I) the received broadcast application, and ii) first middleware on the host device, and receiving a module application stored in a location, wherein the module application requires second middleware to be run on the host device, and generating an identifier that identifies the location of the stored module application, wherein the identifier indicates the second middleware, and in response to the identifier, running the second middleware,
10. A method according to claim 9, comprising stopping running the first middleware before running the second middlewarc.
11. A method according to claim 9, comprising retrieving the module application from the identified location and passing the relrieved module application to the broadcast application for running on the host device.
12. A method according to claim 9, comprising connecting the hostto a removable conditional access module.
13. A method according to claim 9, comprising connecting the host to the internet for retrieval of the module application therefrom.
14. A method according to claim 9, wherein in the event that the first middleware and the second middleware is the same, the identifier is of the form module:1/root/file where module identifies the module in which the niodule application is stored; root identifies the root of the module upon which the module application is stored; and file identifies the file name of the module application.
15. A method according to claim 9, wherein in the event that the first middleware and the second middleware is different, the identifier is of the form module:1/ AppDomainldentifier /rootlfile where module identifies the module in which the module application is stored; AppDomainldcntifier identifies the second middleware; root identifies the root of the module upon which the module application is stored; and file identifies the file name of the module application.
16. A computer program containing computer readable instructions which, when loaded onto a computer, configure the computer to perform a method according to claim 9.
17. A storage medium coiifigured to store the computer program of claim 16 therein or thereon.S18. A host device, system, method or computer program as substantially hercinbefore described with reference to the accompanying drawings.