GB2496145A

GB2496145A - Delivering Protected Video Data

Info

Publication number: GB2496145A
Application number: GB1118881.0A
Authority: GB
Inventors: Peter Vassilev Sedeffow
Original assignee: Saffron Digital Ltd
Current assignee: Ott Film 1 Ltd
Priority date: 2011-11-01
Filing date: 2011-11-01
Publication date: 2013-05-08
Anticipated expiration: 2031-11-01
Also published as: GB201118881D0; GB2496145B

Abstract

Protected video data (203) derived from reference video data is delivered to a requesting client (104). After retrieving a reference video tile (201) containing the reference video data, a file system node (e.g. a named pipe) is established configured to receive, store and output a stream of data, and also adapted to allow read and write operations to take place upon it concurrently. The reference video data is provided to a digital rights management encoder (105) that encodes the reference video data and writes it to the file system node as a stream of protected video data. The stream of protected video data outputted by the file system node is then read and delivered to the requesting client whilst the encoding process is in progress. The requesting client may be provided with an indication of the expected volume of the protected video data.

Description

Delivering Protected Video Data

CROSS REFERENCE TO RELATED APPLICATIONS

This application represents the first appflcation for a patent directed towards the invention and the subject-matter.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to delivering protected video data derived from reference video data to a requesting client, and in particular the deliven) of the protected video data whilst it is being encoded.

2. Description of the Related Art

Digital rights management (DRM) encoding systems are known.

Current DRM systems allow content providers to assign various business-related rules to their media, such as territories in which the media may be consumed and date ranges between which the media may be played.

A particularly useful implementation of DRM encoding is in the delivery of video files to users. Traditional methods involve the sourcing of an unprotected reference video file -that is, a video file not having DRM associated with it -from a content store, the encoding of the reference video file such that it is protected by a DRM system, and the delivery of the protected video data to the user.

However, a probLem is encountered in the encoding stage of the delivery process. Many ORM systems require that the complete reference video file must be fully encoded before delivery of the protected video data to the user can commence. Depending upon the hardware available and the length of the video file, this encoding process can take a substantial period of time. Thus, a user must wait for the encoding process to be completed before they can even begin downloading the file, leading to an unsatisfactory experience. Hitherto, this technical problem persists due to the inherent s difficulties of achieving a technical solution that provides a disruptive technical advance in terms of the system operating in an improved manner as a mailer of practical reality.

BRIEF SUMMARY OF THE INVENTION

According to an aspect of the present invention, there is provided a io method of delivering protected video data derived from reference video data to a requesting client, said method including steps of retrieving a reference video file containing said reference video data, establishing a file system node configured to receive, store and output a stream of data, and adapted to allow read and write operations to take place upon it concurrently, providing said reference video data to a digitat rights management encoder configured to encode said reference video data and write it to said file system node as a stream of protected video data, and reading and delivering to said requesting client the stream of protected video data outputted by said file system node whilst the encoding process is in progress.

According to another aspect of the present invention, there is provided an apparatus for delivering protected video data derived from reference video data to a requesting client comprising a processing device, memory, a storage device and a network interface, wherein said processor is configured to retrieve from said storage device a reference video file containing said reference video data, provide said requesting client with an indication of the expected voLume of said protected video data, establish a file system node on said storage device configured to receive, store and output a stream of data, and adapted to allow read and write operations to take place upon it concurrently, provide said reference video data to a digital rights management encoder configured to encode said reference video data and write it to said file S system node as a stream of protected video data, and read and deliver to said requesting client via said network interface the stream of protected video data outputted by said file system node whilst the encoding process is in progress.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows an environment in which the present invention may be implemented; Figure 2 shows an overview of the process of delivering protected video data 203; Figure 3 shows the structure of protected video data 203; Figure 4 shows components within ORM server 105; Figure 5 is a protocol diagram showing the exchange of requests and data to initiate delivery of protected video data 203; Figure 6 is a diagram showing the interaction of the hardware, the operating system and the applications of ORM server 105; Figures 7A and 76 show the process of writing data to different The systems on DRM server 105; Figure 8 shows steps carried out by DRM server 105 during the encoding process; Figure 9 shows steps carried out to provide client 104 with an indication of the expected volume of protected video data: Figure 10 shows steps carried out to ensure that the resulting volume of protected video data matches the expected volume; and Figure 11 is a protocol diagram showing the exchange of requests and data to initiate playback of protected video data 203.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Figure 1 An environment in which the present invention may be implemented is illustrated in Figure 1.

A large number of video files are stored by a content provider 101 in a content store 102 Content store 102 can be located in the same physical location as content provider 101, although this is not necessary, as communication can be established between different sites via connections to the Internet 103, or, alternatively, a wide area network or some other type of network.

Content provider 101 provides an interface for customers such as a client 104 that allows them to browse and select video files for purchase.

Typically, content provider 101 requires that a subscription is established or a payment per fife provided before access is allowed to the video files stored in content store 102.

Thus, in order to control the use of its video files, content provider 101 implements digital rights management (DRM) upon files that it distributes between itself and clients such as client 104. The application of DRM to the video files stored in content store 102 is performed by a ORM server 105. In addition to content provider 101 and content store 102, client 104 and DRM server 105 are connected to and communicate via the Internet 103, or, alternatively, a wide area network or some other type of network.

When a client such as client 103 requests access to or purchases a video file from content provider 101, content store 102 is instructed to provide ORM server 105 with the source material for application of DRM. The requested video file is then encoded to produce protected video data. In many current systems, this encoding process must be fully completed before the protected video data can be delivered to the requesting client. Given that video file sizes can easily extend into many gigabytes, the encoding process can result in a significant delay before the delivery of the protected video data to the requesting client can commence.

Figure 2 An overview of the process of delivering protected video data is illustiated in Figure 2.

Upon receiving instructions from content provider 101, content store 102 provides DRM server 105 with access to a reference video file 201 containing reference video data. Additionally, DRM server 105 is provided with DRM data 202 describing the ORM rights that should be applied in the encoding process. ORM server 105 encodes the reference video file to produce protected video data 203, which is delivered via the Internet 103 to requesting client 104.

Figure 3 The structure of protected video data 203 is shown in Figure 3.

At a first level is a header 301, comprising a content ID 302, a user rights URL 303 and DRM data 202. Content ID 302 is a number that identifies protected video data 203 as being unique. Thus, no two sets of protected video data produced by DRM server 105 are the same. User rights URL 303 identifies a unique resource location where a video playback application running on client 104 may obtain a ticence confirming that they may play protected video data 203. DRM data 202 describes the various geographical locations in which protected video data 203 may be played, in addition to time limits on playback and other rights defined by content provider 101.

At a second level is video data 304 that is derived from reference video data in reference video file 201. Compression may or may not be applied to video data 304 during the encoding process. The process of applying compression when needed will be described further with reference to Figure 10.

Figure 4 An illustration of components within DRM server 105 is shown in Figure 4.

In order for DRM server 105 to encode the reference video data as protected video data 203, it comprises a processing device such as central processing unit (CPU) 401. In this instance, central processing unit 401 is a single lntek! Xeon® processor. It is possible that in other configurations several such processors will be present to provide a high degree of parallelism in the execution of the encoding process.

Memory is provided by 8 gigabytes of DDRS random access memory (RAM) 402, which allows storage of frequently-used instructions and data structures by DRM server 105. A portion of RAM 402 is reserved as shared memory, which allows high speed inter-process communication between applications running on DRM server 105.

Permanent storage is provided by a storage device such as hard disk drive 403, which in this instance has a capacity of 1 terabyte. Hard disk drive 403 stores operating system and application data. In alternative embodiments, a number of hard disk drives could be provided and configured as a RAID array to improve data access times.

A network interface 404 allows DRM server 105 to connect to a network such as the Internet 105. Additionally, DRM server 105 comprises a number of human interfaces 405 that allow an administrator to interact with and configure It.

ORM server 105 also comprises an optical drive, such as a CD-ROM drive 406, into which an optical disk, such as a CD-ROM 407 can be inserted.

CD-ROM 407 comprises computer-readable instructions that are installed on io hard disk drive 403, loaded into RAM 402 and executed by CPU 401.

Alternatively, the instructions may be downloaded from a network via a network interface 404.

It is to be appreciated that the above system is merely an example of a configuration of system that can fulfil the role of DRM server 105. Any other system having a processing device, memory, a storage device and a network interface could equally be used.

Figure 5 A protocol diagram showing the exchange of requests and data to initiate delivery of protected video data 203 is shown in Figure 5.

In the protocol diagram, vertical lines represent client 104, DRM server 105, content provider 101 and content store 102.

At 501, client 104 issues a request to content provider 101 for the purchase of the right to view a video file. In order for this request to be made, it may be necessary for the user of client 104 to go through a login procedure.

The request from client 104 contains data identifying characteristics of the client, such as whether it is a personal computer or a cellular telephone, and

B

the file format in to which reference video file 201 should be encoded, such as Windows Media Video or QuickTime®, for example.

Upon receipt of this request, content provider 101 approves access to the selected video file, and at 502 issues a request to content store 102 for the licence for the selected video file.

The grant of a licence to content provider 101 by content store 102 is on the condition that the characteristics of client 104 meets certain predetermined attributes in respect of the selected video file. These include the client device type, the clients geographical location and the users age and 50 on. Thus, assuming these conditions have been met, a licence is produced at 503 and sent to content provider 101 at 504.

Upon receipt of the licence, content provider 101 proceeds to issue a unique resource locator (URL) to client 104 at 505. The URL defines the location of the particular file stored by content store 102. In this example, the URL defines the location of reference video file 201. Accordingly, client 104 issues a request at 506 to content store 102 for reference video file 201.

As described previously with reference to Figure 1, content provider does not allow unrestricted access to video files. Therefore, it does not simply allow the direct delivery of reference video file 201 to client 104.

In order to produce protected video data 203, content store 102 issues a request at 507 to DRM server 105 that instructs it to encode reference video file 201. Request 507 includes DRM data 304 that is used during the encoding process to protect reference video file 201, thus producing protected video data 203.

Upon receiving this instruction, DRM server 105 derives an expectation of the volume of protected video data 203 that will be produced in the encoding process. This procedure will be described further with reference to Figure 10.

In this example, ORM server 105 caches a copy of the reference video file on its local storage (hard disk drive 403). As part of an initial setup routine, the reference video file would be transferred via Internet 103 from content store 102. However, it is possible that in alternative embodiments with a high-bandwidth network connection, DRM server 105 could access the reference video file directly from content store 102, with content store 102 being established as a network storage device.

The protected video data 203 is then produced at 508 and written to io hard disk drive 403 at 509. When the writing to disk of protected video data 203 begins, it is transferred as a data stream back to content store 102 at 510.

This proxy transfer means that, at this stage, no data flows between ORM server 105 and client 104. This masking of the presence of DRM server 105 in the delivery process has been shown to improve the security of the delivery system.

The procedure by which the production, writing to disk, reading from disk and transfer takes place will be described further with reference to Figures to 7.

Content store 102 then initiates a hypertext transfer protocol (HTTP) transfer of the protected video data to client 104 at 511. As part of the initiation of the HTTP transfer at 511, the indication of the expected votume of protected video data 203 is provided to client 104 such that progress of the delivery process may be reported to a user, Upon completion of the HTTP transfer, client 104 proceeds to begin playback of the delivered protected video data 203 at 512. The process of initiating playback will be described further with reference to Figure 11.

Figure 6 Many current ORM standards effectively require that the encoding of a reference video file be finished before read access of the file is allowed.

Traditional implementations create a file system node in the form of a file on the storage device of the ORM server as a container for the protected video data, with the output of the encoding process being written directly into the file.

In these implementations the file system node used is sh-nply a normal file.

Whilst the write operation is taking place on the file, it is locked, and therefore no other process running on the DRM server can write to, or indeed read from, io the file.

As previously discussed, this presents problems in terms of the user experience after requesting the file. With high speed Internet technology now commonplace, the notion of instant response to requests is widespread. The lock placed on the file receiving the encoded video data results in a long delay is between the user requesting the file, the encoding taking place and being completed, and the actual delivery taking place.

The present invention overcomes this technical problem by establishing a type of file system node on a storage device that is configured to receive, store and output a stream of data, and adapted to allow read and write operations to take pLace upon it concurrently.

In order to discuss the use of the file system nodes described above, it is necessary to first describe the interaction of the hardware, the operating system and the applications of DRM server 105. In the following explanation, the operating system described is a Microsoft® Windows NTTM based operating system. It is to be appreciated, however, that the particular type of file-system node described above can be exploited on operating systems such as GNU/Linux®, NetBSD® and Mac® OS x.

Figure 6 is an abstraction layer diagram showing at a first level the hardware components 610 described previously with reference to Figure 4. At a second level are the services that run within the operating system of ORM server 105 in kernel mode 620, and at a third level are the various subsystems and applications that run within the operating system of DRM server 105 in user mode 630.

The first layer of kernel mode 620 contains device drivers 621, which layer includes drivers for file systems, processors, memory, network interfaces, optical disk drives, human interfaces and so on.

Above device drivers 621 sits a hardware abstraction layer 622 and a microkernel 623. Hardware abstraction layer 622 hides differences in hardware from microkernel 623 and thus allows a highly portable kernel to be implemented on a large number of disparate platforms such as x86, Itanium and PowerPC. Microkernel 623 manages computing resources such as scheduling of processes, thread prioritisation and memory management.

Further, microkernel 623 administers inter-process communication between applications by allocating shared memory address space in RAM 402.

Additionally, microkernel 623 allows interaction between higher-level services and physical inputs such as human interfaces 405 and network interface 404. Microkernel 623 refers to device drivers 621 in order to understand how the various devices under its control should be instructed.

Alongside hardware abstraction layer 622 and microkernel 623 is an input output manager 624 which allows applications to interact with storage devices. This is achieved by translating read and write instructions from programs into instructions that are understood by device drivers 621. Input output manager 624 includes a memory manager 625 that controls the paging of memory to and from RAM 402 to virtual memory on hard disk drive 403, and also protects memory systems from errors. A cache manager 626 co-operates with memory manager 625 to provide a common cache for data input/output by applications.

Input output manager 624 further includes a volume manager 628, which manages the segregation of hard disk drive 403 into defined volumes. In this example, volumes are portions of hard disk drive 403 comprising data that has been written according to a particular file system standard.

Input output manager 624 also includes file system drivers 627 that define the procedures and methods for reading and writing data to disk.

Examples of file system drivers present in many operating systems include FAT (File Allocation Table), FAT32 (File Aflocation Table 32-bit) and NTFS (New Technology File System) for writing to hard disk drive 403, say, and CDFS (Compact Disk File System) for reading data from CD-ROM 407.

File system drivers 627 provide instructions for creating and reading data structures on various disks according to each file system's storage methods. The data structures written to and read from disks are referred to by file system nodes that describe the location and type of data they contain.

Different types of file system node may be created, and will be described further with reference to Figure 7.

Thus, in an example, hard disk drive 403 could comprise a first, smalL volume (a master boot record) that describes the layout of the disk in terms of its platters and sectors, and a second, large volume formatted with the NTFS file system that input output manager 624 uses an NTFS file system driver to read from and write to.

The third layer of kernel mode 620 comprises system services 629, which includes services that deal with security, process management and object management. Various other services may exist in system services 629 at any point in time, depending upon resources presented to the operating system on the particular computer. Such services could include printer managers, display services and graphics support and so on.

User mode 630 comprises a subsystem 631 which creates an environment in which applications can run. Thus, subsystem 631 provides applications 632 with window management support, user mode security services and network support Applications 632 run in user mode 630, and must therefore pass information through kernel mode 620 in order to access the functionality of hardware components 610.

Thus, in order to write data to disk, an application instructs input output manager 624 to create a file system node on a volume on hard disk drive 403 managed by volume manager 627. Input output manager 624 then proceeds to use the corresponding file system driver for the volume to provide instructions to the device driver for hard disk drive 403 to physically write the data to hard disk drive 403.

When an application wishes to read data from a disk, it provides input output manager 624 with the details of the file system node corresponding to the data it wishes to read. Input output manager 624 proceeds to provide volume manager 628 with the details of the file system node, which then allows the data structures previously written to disk to be located and supplied to the operating system by a disk such as hard disk drive 403.

Figures TA and 78 The interaction between a first application 701, a second application 702, input output manager 624 and hard disk drive 403 in order to create and read various types of file system node is shown in Figures 7A and 7B.

As described previously with reference to Figure 6, traditional encoding of reference video files creates a file system node that becomes locked once write operations begin.

In the example shown in Figure 7A, first application 701 issues a request to input output manager 624 to create a file system node 710 on an NTFS volume 711 using an NTFS file system driver 712. Storage device driver 703 in turn receives a request to instruct hard disk drive 403 to physically write data to disk. The NTFS file system is not multithreaded, and as a result, WTFS file system driver 712 cannot support the concurrent writing to and reading from a file system node created on an NTFS volume. Thus, once write operations begin (indicated by the solid arrows), the file system ncde becomes locked. Therefore, whilst first application 701 is writing data to file 710, second application 702 cannot read it, as indicated by the dashed arrows.

This is the source of the technical problem encountered wherein once the encoding of a reference video file begins, the encoding process must be completed before it can be read by another application for delivery via the Internet 103 to client 104.

In the exampie shown in Figure 7B, the functionality of a different flue system driver and corresponding volume is used. In this case, application 701 issues a request to input output manager 625 to create an alternative type of file system node that is configured to receive, store and output a stream of data, and adapted to allow read and write operations to take place upon it concurrently. In this embodiment, the file system node is a named pipe, but in alternative embodiments any other file system node that allows read and write operations to take place upon it concurrently could be used.

Upon receiving a request from first application 701 to create a named pipe, input output manager 625 creates a file system node 720 on a named pipe volume 721 using a named pipe file system (NPFS) driver 722.

Accordingly, the location of file system node 720 within named pipe volume 721 is published system-wide. File system node 720 is then available for both reading and writing by applications 701 and 702 as indicated by the solid arrows.

Figure8 Steps carried out by DRM server 105 during the encoding process are shown in Figure 8.

Upon receiving a request from content store 102 to produce protected video data 203, DRM server 105 proceeds to locate and obtain reference video file 201 and DRM data 202. In this embodiment, reference video file 201 is cached locally on hard disk drive 403 to improve performance, but in other examples DRM server 105 could access the original reference video file 201 stored by content store 102. In this case, a file system node could be established in named pipe volume 721 that reference video file 201 is streamed into using an HTTP transfer between content store 102 and DRM server 105.

At the next step, ORM server 105 analyses reference video file 201 and provides client 103 with an indication 801 of the expected volume of protected video data. The indicated volume takes into account the addition of DRM data to the reference video data, and allows client 104 to present to a user the progress of the delivery even though the encoding process may not be complete. This process will be described further with reference to Figure 9.

A named pipe 802 is then established in named pipe volume 721, and its location published system-wide.

At the next step, reference video file 201 and ORM data 202 are dispatched to an encoder 803 which encodes reference video file 201 in the context of DRM data 202, and begins writing its output stream of protected video data 203 to named pipe 802. Various parameters can be changed during the encoding process carried out such that the resulting volume of protected video data matches the indicated volume.

S When the writing of the stream of protected video data 203 to named pipe 802 begins, an (-hIP file server 804 begins reading named pipe 802, arid proceeds to deliver the stream of protected video data 203 via the Internet 103 to content store 102 by proxy transfer.

FIgure 9 rn Steps carried out by content store 102 to provide a client such as client 103 with an indication of the expected volume of protected video data are shown in Figure 9.

At step 901, the reference video is read and its file size ascertained, At step 902, a constant representing the volume of data of content ID 302 is added, and at step 903 a constant representing the volume of data of user rights URL 303 is added. At step 904, a constant representing the volume of DRM data 202 is added, and at step 905 padding of 2 kilobytes is added. The resulting figure is established as the volume of protected video data at step 906 for providing to client 104.

Figure 10 Steps carried out by DRM server 105 to ensure that the resulting volume of protected video data matches the expected volume are shown in Figure 10.

At step 1001, the total amount of protected video data already encoded by DRM encoder 813 is found, and at step 1002 the progress of the encoding process is found. At step 1003, a question is asked as to whether the encoding process is complete based upon the values found at steps 1001 and 1002. If this question is answered in the negative, then control proceeds to step 1004 where a question is asked as to whether, given the progress of the encoding process, the projected volume of protected video data is above the expected volume. If this question is answered in the affirmative, then at step 1005 a compression flag is set and DRM encoder 813 is instructed to apply compression in the encoding process at step 1006. Control then returns to step 1001.

If the question asked at step 1004 is answered in the negative, then at step 1007 a question is asked as to whether the total volume of data is below the expected volume. If this question is answered in the negative, then DRM server 105 concludes that the projected volume matches the expected volume and control returns to step 1001.

If the question asked at step 1007 is answered in the affirmative, then at step 1008 a question is asked as to whether the compression flag has previously been set. If this question is answered in the affirmative, then at step 1009 the compression is removed and control returns to step 1001.

If the question asked at step 1008 is answered in the negative, then at step 1010 DRM encoder 813 is instructed to continue encoding and control returns to step 1001 accordingly.

If the question asked at step 1003 is answered in the affirmative, to the effect that the encoding process is complete, then contro' proceeds to step 1011 where a question is asked as to whether the total volume of data encoded was below the expected volume. If this question is answered in the affirmative, then redundant data, possibly representing blank video frames, is produced and appended to protected video data 203 at step 1012. After this, and also if the question asked at step 1011 was answered in the negative, then the connection between HTTP file server 714 and content store 12 is closed at step 1013.

Figure 11 s A protocol diagram showing the exchange of requests and data to initiate playback of protected video data 203 is shown in Figure 11.

As previously described with reference to Figure 5, playback of io protected video data 203 may only commence after the HTTP transfer from content store 102 to client 104 is completed.

Thus, when the delivery of protected video data 203 is complete, a user input is received at 1101 instructing client 104 to begin playback. At 1102, a question is asked by the client as to whether a key is available. This question will be answered in the negative, and at 1103, client 104 issues a request to DRM server 105 for a licence to play protected video file 203, using the unique resource locator contained in user rights URL 303.

At 1104, DRM server 105 proceeds to issue a request to content store 102 for the particular user rights associated with client 104, and at 1105 the rights are returned. At 1106, DRM server 105 stores the user rights, arid proceeds to return the licence to client 104 at 1107. Upon receipt of the licence, playback of protected video data 203 by client 104 begins.

Claims

<claim-text>Claims What we claim is: 1. A method of delivering protected video data derived from reference video data to a requesting client, said method including steps of: retrieving a reference video file containing said reference video data; establishing a file system node configured to receive, store and output a stream of data, and adapted to allow read and write operations to take place upon it concurrently; providing said reference video data to a digital rights management encoder configured to encode said reference video data and write it to said file system node as a stream of protected video data; and reading and delivering to said requesting client the stream of protected video data outputted by said file system node whilst the encoding process is in progress.</claim-text> <claim-text>2. The method of claim 1, wherein said file system node is a named pipe.</claim-text> <claim-text>3. The method of claim 1 or claim 2, wherein said reference video file is a locally cached copy of a video file stored on a networked storage device.</claim-text> <claim-text>4. The method of any one of claims 1 to 3, wherein said delivering step delivers the stream of protected video data using hypertext transfer protocol.</claim-text> <claim-text>5. The method of any one of claims I to 4, further comprising the steps of: receiving a request from said requesting client to view said protected video data; identifying the characteristics of said requesting client; authorising the request from said requesting client; and providing said requesting client with a unique resource locator identifying the Location of said video file.</claim-text> <claim-text>6. The method of any one of claims 1 to 5, wherein said encoding operation produces protected video data that is unique to an individual requesting client.</claim-text> <claim-text>7. The method of any one of claims I to 6, further comprising the step of providing said requesting client with an indication of the expected volume of said protected video data, wherein said indication is calculated by: identifying the total volume of said reference video data; adding a constant representing the volume of the data that describes the digital rights management components associated with said protected video data; and adding a constant representing the volume of a desired margin of error.</claim-text> <claim-text>8. The method of any one of claims 1 to 7, wherein said step of delivering said protected video data includes the step of monitoring the volume of protected video data being produced during the encoding operation to ensure that the volume of protected video data is consistent with the expected volume.</claim-text> <claim-text>9. The method of claim 8, wherein the volume of protected video data is reduced during the encoding operation in response to said monitoring step indicating that the volume of said protected video data produced will be greater than the expected volume.</claim-text> <claim-text>10. The method of claim 9, wherein the volume of protected video data is reduced by performing a compression procedure during the encoding operation.</claim-text> <claim-text>11. The method of claim 8, wherein redundant data is delivered to said requesting client at the end of said protected video data when the volume of said protected video data is less than the expected total size of said protected video data.</claim-text> <claim-text>12. The method of claim 11, wherein said redundant data represents blank frames of video.</claim-text> <claim-text>13. An apparatus for delivering protected video data derived from reference video data to a requesting client comprising a processing device, memory, a storage device and a network interface, wherein said processor is configured to: retrieve from said storage device a reference video file containing said reference video data: provide said requesting client with an indication of the expected volume of said protected video data; establish a file system node on said storage device configured to receive, store and output a stream of data, and adapted to allow read and write operations to take place upon it concurrently; provide said reference video data to a digital rights management encoder configured to encode said reference video data and write it to said file system node as a stream of protected video data; and read and deliver to said requesting client via said network interface the stream of protected video data outputted by said file system node whilst the encoding process is in progress.</claim-text> <claim-text>14. The apparatus of claim 13, wherein said file system node is a io named pipe.</claim-text> <claim-text>15. The apparatus of claims 13 or 14, wherein said reference video file is a locally cached copy of a video file stored on a networked storage device.</claim-text> <claim-text>16. The apparatus of any one of claims 1 to 3, wherein said delivering processor is further configured to deliver the stream of protected video data using hypertext transfer protocol.</claim-text> <claim-text>17. The apparatus of any one of claims 13 to 15, wherein said processor is further configured to: receive a request from said requesting client via said network interface to view said protected video data: authorise the request from said requesting client; identify the characteristics of said requesting client; and provide said requesting client with a unique resource locator identifying the location of said video file via said network interface.</claim-text> <claim-text>18. The apparatus of any one of claims 13 to 17, wherein said encoding operation performed by said processor produces protected video data that is unique to an individual requesting cUent.</claim-text> <claim-text>19. The apparatus of any one of claims Ito 6, wherein said processor is further configured to provide said requesting client with an indication of the expected volume of said protected video data, wherein said processor is configured to calculate said indication by performing steps of: identifying the total volume of said reference video data; adding a constant representing the volume of the data that describes the digital rights management components associated with said protected video data; and adding a constant representing the volume of a desired margin of error.</claim-text> <claim-text>20. The apparatus of any one of claims 1 to 7, wherein said processor is further configured to, when delivering said protected video data, monitor the volume of protected video data being produced during the encoding operation to ensure that the volume of protected video data is consistent with the expected volume.</claim-text> <claim-text>21. The apparatus of claim 8, wherein said processor is further configured to reduce the volume of protected video data during the encoding operation in response to said monitoring step indicating that the volume of said protected video data produced will be greater than the expected volume.</claim-text> <claim-text>22. The apparatus of claim 9, wherein said processor is further configured to reduce the volume of protected video data by performing a compression procedure during the encoding operation.</claim-text> <claim-text>23. The apparatus of claim 8, wherein said processor is further S configured to deliver redundant data to said requesting client at the end of said protected video data when the volume of said protected video data is less than the expected total size of said protected video data.</claim-text> <claim-text>24. Instructions executable by a computer or a network of computers that, when executed by a computer or a network of computers, cause a computer or a network of computers to perform a method as set out in any one of claims ito 12.</claim-text> <claim-text>25. A computer system programmed to execute the instructions of claim 24.</claim-text> <claim-text>26. A computer network including the computer system of claim 25.</claim-text> <claim-text>27. A method of delivering protected video data derived from reference video data to a requesting client substantially as herein described with reference to the accompanying drawings.</claim-text> <claim-text>28. Apparatus for delivering protected video data derived from reference video data to a requesting client substantially as herein described with reference to the accompanying drawings Amendments to the claims have been filed as follows: Claims What we claim is: 1. A method of delivering protected video data derived from reference video data to a requesting client, said method including steps of: retrieving a reference video file containing said reference video data; establishing a file system node configured to receive, store and output a stream of data, and adapted to allow read and write operations to take place upon a concurrently; providing said reference video data to a digital rights management encoder configured to encode said reference video data and write it to said file system node as a stream of protected video data; and reading and delivering to said requesting client the stream of protected video data outputted by said file system node whilst the digital rights management encoding process is in progress.S
2. The method of claim 1, wherein said file system node is a named * S5.** * S pipe. * S. * * S S...
3. The method of claim 1 or claim 2, wherein said reference video file is a locally cached copy of a video fire stored on a networked storage device. *S.
4. The method of any one of claims 1 to 3, wherein said delivering step delivers the stream of protected video data using hypertext transfer protocol.
5. The method of any one of claims 1 to 4, further comprising the steps of: receiving a request from said requesting client to view said protected video data; identifying the characteristics of said requesting client; authorising the request from said requesting client; and providing said requesting client with a unique resource locator identifying the location of said video file.
6. The method of any one of claims 1 to 5, wherein said encoding operation produces protected video data that is unique to an individual requesting client.
7. The method of any one of claims 1 to 6, further comprising the step of providing said requesting client with an indication of the expected volume of said protected video data, wherein said indication is calculated by: identifying the total volume of said reference video data; * adding a constant representing the volume of the data that describes ****.* the digital rights management components associated with said protected *s:s video data; and adding a constant representing the volume of a desired margin of error. * 4* * . * *s8. The method of any one of claims 1 to 7, wherein said step of delivering said protected video data includes the step of monitoring the volume of protected video data being produced during the encoding operation to 26 ensure that the volume of protected video data is consistent with the expected volume.9. The method of claim 8, wherein the volume of protected video data is reduced during the encoding operation in response to said monitoring step indicating that the volume of said protected video data produced will be greater than the expected volume.10. The method of claim 9, wherein the volume of protected video data is reduced by performing a compression procedure during the encoding operation.11. The method of claim B, wherein redundant data is delivered to said requesting client at the end of said protected video data when the volume of said protected video data is less than the expected total size of said protected video data.12. The method of claim 11, wherein said redundant data represents blank frames of video. - * 13. An apparatus for delivering protected video data derived from reference video data to a requesting client, said apparatus comprising a processing device, memory, a storage device and a network interface, and *:> wherein said processor is configured to: retrieve from said storage device a reference video file containing said reference video data; provide said requesting client with an indication of the expected volume of said protected video data; establish a file system node on said storage device configured to receive, store and output a stream of data, and adapted to allow read and write operations to take place upon it concurrently; provide said reference video data to a digital rights management encoder configured to encode said reference video data and write it to said file system node as a stream of protected video data; and read and deliver to said requesting client via said network interface the stream of protected video data outputted by said file system node whilst the encoding process is in progress.14. The apparatus of claim 13, wherein said file system node is a named pipe.15. The apparatus of claim 13 or 14, wherein said reference video file is a locally cached copy of a video file stored on a networked storage device.16. The apparatus of any one of claims 13 to 15, wherein said delivering processor is further configured to dellver the stream of protected video data using hypertext transfer protocol. * .17. The apparatus of any one of claims 13 to 16, wherein said processor is further configured to: *:c:* receive a request from said requesting client via said network interface + to view said protected video data; authorise the request from said requesting client; identify the characteristics of said requesting client; and provide said requesting client with a unique resource locator identifying the location of said video file via said network interface.18. The apparatus of any one of claims 13 to 17. wherein said encoding operation performed by said processor produces protected video data that is unique to an individual requesting client.19. The apparatus of any one of claims 13 to 18, wherein said processor is further configured to provide said requesting client with an indication of the expected volume of said protected video data, wherein said processor is configured to calculate said indication by performing steps of: identifying the total volume of said reference video data; adding a constant representing the volume of the data that describes the digital rights management components associated with said protected video data; and adding a constant representing the volume of a desired margin of error.20. The apparatus of any one of claims 13 to 19, wherein said processor is further configured to, when delivering said protected video data, * monitor the volume of protedted video data being produced during the * encoding operation to ensure that the volume of protected video data is consistent with the expected volume.21. The apparatus of claim 20, wherein said processor is further configured to reduce the volume of protected video data during the encoding operation in response to said monitoring step indicating that the volume of said protected video data produced will be greater than the expected volume.22. The apparatus of claim 21, wherein said processor is further configured to reduce the volume of protected video data by performing a compression procedure during the encoding operation.23. The apparatus of claim 20, wherein said processor is further configured to deliver redundant data to said requesting client at the end of said protected video data when the volume of said protected video data is less than the expected total size of said protected video data.24. Instructions executable by a computer or a network of computers that, when executed by the computer or the network of computers, cause the computer or the network of computers to perform a method as set out in any one of claims Ito 12.25. A computer system programmed to execute the instructions of claim 24.26. A computer network including the computer system of claim 25.* .. *..* 27. A computer readable medium encoded with computer-readable instructions executable by a computer that, when executed by the computer, cause the computer to perform a method as set out in any one of claims 1 to * ** * * ** 28. A method of delivering protected video data derived from reference video data to a requesting client substantially as herein described with reference to the accompanying drawings.29. Apparatus for delivering protected video data derived from reference video data to a requesting client substantially as herein described with reference to the accompanying drawings. * . * . . *
S.S..... * S * .* * S "S. * SS * . I * .. *..S</claim-text>