GB2371387A

GB2371387A - Asset delivery system

Info

Publication number: GB2371387A
Application number: GB0125927A
Authority: GB
Inventors: Gavin Henry Ross; Andrew Peter Grace
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2000-10-27
Filing date: 2001-10-29
Publication date: 2002-07-24
Also published as: GB0125927D0; GB0026339D0

Abstract

A delivery system for the delivery of audio-visual material (eg videos) or other digitally coded items via a a telecommunications network TN to remote user terminals CT has an asset server AS with access to a source ASD of such items, and has a conditional access system CAS. The conditional access system has access to a store ACD containing records defining permitted access to said items. When the asset server receives a request (R3) from a user terminal for an item, it sends to the conditional access system an enquiry message (R6) identifying the item requested and the origin of the request The conditional access system, upon receipt of the enquiry message, compares the message with the stored records to ascertain whether the enquiry message represents a request for access defined by a record as being permitted, and, if it does, to return a message of authorisation to the asset server. The asset server receives the message of authorisation (R10) and thereupon transmits the item to the user terminal. Each record in the conditional access system defiles a contact which may, for example, limit the customer to viewing an unlimited number of items for a specified period, to view an item once in a specified period, to watch a specified number of videos during a specified period. The contract can be limited to videos of a specific category or classification.

Description

ASSET DELIVERY SYSTEM This invention is concerned with the delivery of digitally coded items to a remote user terminal, via a telecommunications network.

According to one aspect of the present invention there is provided a delivery system for the delivery of digitally coded items to remote user terminals, comprising: (a) an asset server which has access to a source of said items; and (b) a conditional access system which has access to a store containing records defining permitted access to said items; wherein (c) the asset server and the conditional access system each have one or more interfaces whereby they can communicate with each other and the asset server can communicate via a telecommunications network with the remote user terminals ; and wherein (d) the asset server is arranged, in response to receipt of a request from a user terminal for an item, to send to the conditional access system an enquiry message identifying the item requested and the origin of the request and arranged, in response to receipt of a message of authorisation from the conditional access system, to transmit the item to the user terminal ; and (e) the conditional access system is arranged, in response to receipt of such an enquiry message from the asset server, to compare the message with the stored records to ascertain whether the enquiry message represents a request for access defined by a record as being permitted, and, if it does, to return a message of authorisation to the asset server.

In another aspect, the invention provides a delivery system for the delivery of digitally coded items to remote user terminals, comprising : (a) at least one distribution server ; (b) an asset server which has access to a source of said items ; and (c) a conditional access system which has access to an access store for containing records defining permitted access to said items ; wherein

(d) the distribution server, the asset server and the conditional access system each have one or more interfaces whereby they can communicate with each other and the distribution server and asset server can communicate via a telecommunications network with the remote user terminals ; and wherein (e) the distribution server is arranged in response to signals from a user terminal to create a record defining permitted access to said items and to cause the record to be stored in the access store; (f) the asset server is arranged, in response to receipt of a request from a user terminal for an item, to send to the conditional access system an enquiry message identifying the item requested and the origin of the request and arranged, in response to receipt of a message of authorisation from the conditional access system, to transmit the item to the user terminal ; and (g) the conditional access system is arranged, in response to receipt of such an enquiry message from the asset server, to compare the message with the stored records to ascertain whether the enquiry message represents a request for access defined by a record as being permitted, and, if it does, to return a message of authorisation to the asset server.

Other aspects of the invention are set out in the claims.

Some embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings.

The system now to be described has as its aim the delivery of "assets" to paying customers via the internet or other digital telecommunications system.

"Asset"is used here as a generic term for any kind of material which can be encoded in digital form and transmitted from one place to another. In this particular example, it is assumed that the assets are videograms, or, colloquially, videos, stored as a digital file in compressed format using one of the currently popular video compression systems such as that defined in the MPEG standards. However the system could be used for conveying material of other formats such as still images, of pictures or books, audio files, text files, computer programs and so forth.

The architecture of the system is shown in Figure 1. Shown are four servers in the form of general purpose computers running appropriate software: a distributor

server DS, an asset server AS, a content management system CMS and a conditional access system CAS. Also shown are a plurality of customer terminals CT in the form of conventional personal computers. The servers and customer terminals all include telecommunications interfaces for communication via a telecommunications network TN. For simplicity, all are shown interconnected by a single network which could be the internet or other TCP/IP network (though other types of digital network could be employed). This is today the most convenient choice, especially for communications by the customer terminals CT (which, in this version, communicate only with the distributor server DS and with the asset server AS). Intercommunication between the servers could take place over the same network, or using a different one.

The broad idea of the scheme is that the asset server has access to an asset database ASD containing the videos. One or more organisations referred to as distributors are authorised to sell the videos to customers, and provide a user interface to the customers in the form of HTML pages stored on the distributor server DS. This server is conventional-i. e. it is an ordinary"web server". Thus in practice there will in all probability be several distributor servers DS, used by different distributors.

The conditional access server CAS (with an access database ACD) and the content management system (with a content database CD) are provided to assist in the management of the ordering and delivery of the videos which the customer choose to view, as will be described in more detail presently. Only one of each of these is needed, though there could be more than one, if desired. Moreover, although shown separately, at separate sites, two or more of them could be co-sited and connected directly rather than via a telecommunications network. Similarly the databases referred to can be located alongside, or in, the relevant server, or located remotely.

Each of the servers mentioned, and the customer terminals, has a conventional computer architecture, as shown in Figure 2, comprising a central processor 1, memory 2, a disk store 3, a telecommunications interface 4 and (at least for the customer terminals) user interfaces: keyboard 5, mouse 6 and video display unit 7. Suitable computer programs are provided in the disk stores 3 and can be loaded into the memories 2 and executed by the respective processor 1. Where, in this description, reference is made to steps being performed by one of the servers

or by a customer terminal, this is to be understood to mean that the steps are performed by the relevant processor under control of one of the programs, embodying instructions for performance of those steps. The customer terminal can employ a conventional internet browser such an Microsoft Internet Explorer, or Netscape Navigator.

The way the system works, considered from a customer's point of view, is that the customer accesses the distributor's web pages and selects from options offered by the distributor as to which videos he wants to watch, and when; having made this selection he makes a payment to the distributor, for example by sending his credit card details, so that he then has a contract with the distributor. Details of the contract are sent by the distributor to the conditional access system.

Subsequently, when the customer wishes to view the video, he clicks on a link on one of the distributor's pages on the server DS which results in a request for the video in question to the asset being sent to the asset server AS, which uses the conditional access system CAS and, in turn, the content management system CMS to ascertain whether the request is in accordance with the terms of the contract, and if so, delivers the video to the customer. The customer's usage is also recorded by the system.

A number of different types of contract are envisaged as set out in the list below, though these are not the only possibilities : Single asset: the customer is allowed to watch, once, during a specified period a particular selected video (for example, he can watch the film"Jungle Book" once any time during the coming week) ; Multiple asset: the customer is allowed to watch a specified number of videos during a specified period, and can, at the time of viewing select any video from those the distributor is offering; All assets: the customer is allowed to watch one video during a specified period, and can, at the time of viewing select any video from those the distributor is offering; Duration access: the customer is allowed during a specified period to watch an unlimited number of videos an unlimited number of times, subject to a limit on the total viewing time; All the above can be qualified by additional criteria:

Category access : e. g. the customer is allowed during a specified period to watch any video within a specified category (for example he can watch any science fiction video during the next month); Classification: e. g. the customer is allowed during a specified period to watch any video having a specified category (for example he can watch any ctassification"U" [the British marking indicating that a film is suitable for viewers of all ages video during the next month); Credit access: the customer is allowed to watch an unlimited number of videos from those the distributor is offering, but each time he does so a charge will be made to his credit card account.

It will be seen that there are two distinct processes involved-purchase, and delivery. These will now be described in detail with reference to Figure 3 which is the same as Figure 1 except that, instead of showing the telecommunications network, we have shown, by separate arrows, the individual transmissions that occur between the servers and/or terminals. The asset database merely contains the videos. The content database contains one record for each video (only one record is actually shown); each record contains several fields of information about the respective video. The access database contains one record for each customer contract (only one record is actually shown); each record contains several fields of information about the respective contract. The content database and access database contain the following fields: Content database Asset Id Asset URL Supplier d Name] Description Classification Category Category Category

Access start Access end Access database Contract Id [Customer Id & Password] Distributor Id Contract Start Contract End Contract Type Duration Usage Classification Category Status Asset Id Asset Id Asset Id The steps involved in the purchase process are marked P1, P2, etc. in Figure 3 ; for enhanced security, the customer may be required to enter password a one or more stages of the process, though the corresponding steps will not be specifically described: P1 : Assuming that the customer using his terminal CT is already logged on to the internet and viewing one of the distributor's pages from the distributor server DS, the customer selects the type of contract he requires and specifies the details such as dates, category and so forth, as well as credit card details, this being achieved in conventional manner by following hyperlinks through a series of menus and/or filling in boxes on the distributor's pages. As a result, the distributor server assembles a contract record, containing the following fields. Fields marked * are required-some of the other fields will be left blank if they are not relevant to the particular type of contract: *distributor id-a code identifying the distributor

*contract type contract start-the start date of the period for which the contract is effective contract end-the end date of the period for which the contract is effective duration category classification asset id-a code or codes identifying one of more videos usage-a number indicating the number of times viewing is allowed It might also be useful to include a username and password; these could be used to help identify a contract by support staff, and verify the caller (to the support staff) as the owner of the contract.

P2: The distributor server transmits this information to the conditional access system CAS.

P3, P4 : If the contract is for specific assets, the conditional access system CAS first checks with the content management system CMS whether the distributor has been authorised to distribute the asset. If the contract is more general, such as a contract that allows the customer to view all the distributor's allowed assets, this check is deferred until the customer wishes to access a specific asset.

P5: The conditional access system CAS adds to the received information a contract number and stores it as a record in the access database ACD.

P6: The contract number is passed back to the distributor server.

P7: The distributor server transmits the contract number to the customer terminal CT along with a message informing the customer that he can now go ahead and view the asset (s) in question.

This completes the purchase process.

The steps involved in the delivery process are marked R1, R2, etc. in Figure 3; again, password protection may be added if desired.

R1 : When the customer wishes to view the asset (or one of the assets) for which he has contracted, he requests one of the pages obtained from the distributor's server; this page containing a menu of assets and hyperlinks each with the Universal Resource Locator (URL) of a respective asset. This menu could be a list of all assets or (assuming that the customer supplies the contract number to the distributor server) it could be a bespoke menu listing (with the aid of an additional step of

interrogating the access database ACD) only those assets covered by the contract.

Once this page has been downloaded (R2a) to the customer terminal... R3: The customer makes his selection by clicking on one of the links ; that is, he uses his mouse to select one of the hyperlinks which causes his browser to transmit a request for the page having that URL. The URL will have a first part identifying the asset server and a second part identifying the asset. (in fact of course the browser will automatically translate the first part of the URL into the IP address of the asset server before transmitting the request).

R4: The request having arrived at the asset server AS, the asset server requests the customer to enter the contract number.

R5: The customer sends the contract number to the asset server.

(If desired, the contract number (if it has already been given to the distributor server) could instead be forwarded from the distributor server via the customer terminal to the asset server; in which case steps R4 and R5 would be omitted). The contract id could also form part of the URL: e. g.: mms ://123. 456. 789. 1Qj/nglebook. asf ? contract id= 1234 R6: The asset server sends to the conditional access system CAS a message, containing the contract number and asset identifier, so that it can verify whether the viewing of that asset at that time is authorised by the contract. In principle, the second part of the URL and the asset identifier can be one and the same thing; if, however it is more convenient for them to be different, then the asset server or conditional access system would need to access the content database to translate the URL into the corresponding asset identifier: for this reason, both are shown in Figure 3 as being recorded in the content database.

R7: To perform this verification, the conditional access system retrieves from the access database ACD the record held in the access database for the relevant contract, and verifies that the current date lies between the limits specified by the Contract Start and Contract End dates, and (if appropriate for the particular Contract Type) whether the asset is listed in the Asset Id field (s) and whether the Duration or Usage fields are non-zero. It also checks whether access is precluded by the Status field. (If desired, this field could, during such an access, be temporarily marked "unavailable", to avoid a customer obtaining delivery under that contract to two or more customer terminals simultaneously.

R8, R9 : If the contract is of the more general variety, the conditional access system CAS contacts the content management system CMS to check that the distributor has been authorised to distribute the asset. If the contract type so requires, the conditional access system CAS also checks whether the asset requested falls within any limitations (category or classification) specified in the contract record. For this purpose it accesses (R9a, R9c) the content management system CMS which consults (R9b) the content database CD for the necessary information which the conditional access system CAS then compares with the Category or Classification field of the contract record.

R10 : If all these checks are satisfactory, the content management system CMS sends a message back to the asset server informing is that the customer is authorised to receive that asset.

R11 : The asset server retrieves the asset from the asset database DB, and...

R12 :... transmits it to the customer terminal.

R13 : During transmission, the customer terminal can send signals back to control the process, as is conventional. Also, the asset server records delivery parameters, such as start and stop times.

R14: The delivery parameters are sent to the content management system CMS along with the contract number and the asset identity.

R15 : As well as saving the delivery parameters in the access database ACB, so as to be available for download by the distributor, the content management system also updates the contract details in the access database. Thus, if, for example the contract is of Multiple type, the Usage field is decremented, whilst for a Duration Access contract, the Duration field should be decremented by the duration of viewing. Or if a contract permits an asset to be viewed only once the relevant Asset Id field should be deleted (or its Status field can be marked as used up). If any of these actions results in a record indicating that no further deliveries are permitted, the status field can again be marked as used up, or the whole record may if desired be automatically deleted.

The distributors can access the content management system CMS to enter details for download of records belonging to their customers.

The above description assumes that the customer identifies his contract by giving the contract number. Alternatively, the customer could identify himself to the distributor

store and access server by means of a user identifier (or possibly just to the distributor store if the latter is arranged to forward the user identifier-or contract number-on to the asset server directly). Although this might be a more"user friendly"approach, it would require additional complexity in that the distributor server and/or asset server would need: (a) to identify the relevant contract or contracts; (b) accommodate the possibility of the customer having more than one contract (especially if the contracts overlap where for example with two duration type contracts the question may arise as to which of two duration fields is to be decremented) ; and (c) if bespoke menus are used in step R1, to construct a bespoke menu which lists assets covered by more than one contract.

One possible solution to this is to provide that the distributor server (at step R1) and/or asset server (at step R4) should (a) consult the database records in the access database ACD (each of which would then additionally contain a customer identifier field) to identify the contract or contracts standing in the name of that customer; and (b) identify cases of overlap and if present to offer to the customer by means of a menu the opportunity to select under which contract the asset is to be viewed.

Alternatively, the user could be required to use a different password for each contract Although various different arrangements can be envisaged for setting up the assets, and the distributors, some possibilities will now be discussed. A supplier terminal 10 (Figure 3) is connected via a communications link or network to the content management system CMS. When an asset is to be added, the asset itself is sent to the CMS (path S1), along with the necessary metadata. These are sent (S2, S3) to the asset database and the content database respectively. A message (not shown) may also be sent to distributors advising that the newly added asset is available. When the supplier wishes to authorise a distributor to distribute an asset, the supplier terminal 10 sends a message S4 to the content management system CMS with details of the distributor and of the assets in question, where they are stored in local storage 3, and be later used for checking whether the distributor is

authorised (as discussed above in connection with messages P3, P4). A list of the assets is also sent to the distributor, who can then update his pages stored in the server DS.

As well as being suitable for the delivery of items already in existence, the system is however also suitable for delivery of bespoke items, that is to say, items which are not pre-existing, but are created or constructed in response to a particular request from the customer. One example of this would be the provision of a computer program service whereby, rather than the program being sent to the customer for execution on his own computer, the program is run at a point remote from the customer terminal. Thus the asset server AS, having retrieved the program from the asset database ASD in the manner described above, would then execute the program itself (or have it executed by a separate computer provided for the purpose), with or without exchanges of messages with the user for data input and selection of options. The asset or item delivered would then be the results generated by the program rather than the program itself.

Claims

CLAIMS 1. A delivery system for the delivery of digitally coded items to remote user terminals (CT), comprising: (a) an asset server (AS) which has access to a source (ASD) of said items; and (b) a conditional access system (CAS) which has access to a store (ACD) containing records defining permitted access to said items; wherein (c) the asset server and the conditional access system each have one or more interfaces (4) whereby they can communicate with each other and the asset server can communicate via a telecommunications network (TN) with the remote user terminals ; and wherein (d) the asset server is arranged, in response to receipt of a request (R3) from a user terminal for an item, to send to the conditional access system an enquiry message (R6) identifying the item requested and the origin of the request and arranged, in response to receipt of a message of authorisation (R10) from the conditional access system, to transmit the item to the user terminal ; and (e) the conditional access system is arranged, in response to receipt of such an enquiry message from the asset server, to compare the message with the stored records to ascertain whether the enquiry message represents a request for access defined by a record as being permitted, and, if it does, to return a message of authorisation to the asset server.
2. A delivery system for the delivery of digitally coded items to remote user terminals (CT), comprising: (a) at least one distribution server (DS) ; (b) an asset server (AS) which has access to a source (ASD) of said items; and

(c) a conditional access system (CAS) which has access to an access store (ASD) for containing records defining permitted access to said items; wherein (d) the distribution server, the asset server and the conditional access system each have one or more interfaces (4) whereby they can communicate with each other and the distribution server and asset server can communicate via a telecommunications network (TN) with the remote user terminals ; and wherein (e) the distribution server is arranged in response to signals from a user terminal to create a record defining permitted access to said items and to cause the record to be stored in the access store; (f) the asset server is arranged, in response to receipt of a request (R3) from a user terminal for an item, to send to the conditional access system an enquiry message (R6) identifying the item requested and the origin of the request and arranged, in response to receipt of a message of authorisation (R10) from the conditional access system, to transmit the item to the user terminal ; and (g) the conditional access system is arranged, in response to receipt of such an enquiry message from the asset server, to compare the message with the stored records to ascertain whether the enquiry message represents a request for access defined by a record as being permitted, and, if it does, to return a message of authorisation to the asset server.
3. A system according to claim 2 in which the distribution server is arranged upon the creation of said record defining permitted access to send to the conditional access system a message containing said record and the conditional access system is operable upon receipt thereof to store the record in the access store.
4. A system according to claim 2 or 3 in which the distribution server is operable to present to the user terminal particular of said items and, in response to a request from the user terminal for delivery of an item, to send to the user terminal

address information for use by the customer terminal in formulating the request that the user terminal is to send to the asset server.
5. A system according to claim 4 in which the address information includes a network address of the access server.
6. A system according to claim 4 or 5 in which the address information includes an address of the item within the access store.
7. A system according to claim 4,5 or 6 in which the address information includes information identifying one or more of the stored records.
8. A system according to any one of the preceding claims including means operable, in the event that a record defining permitted access defined in terms of classes into which items may be assigned, to retrieve, from stored information (CD) about the items, information as to the class (es) to which the requested item belongs and to forward said retrieved information to the conditional access system.
9. A delivery system for the delivery of stored digitally coded items to remote user terminals, substantially as herein described with reference to the accompanying drawings.