WO2011045816A1

WO2011045816A1 - Method and apparatus for content delivery over internet

Info

Publication number: WO2011045816A1
Application number: PCT/IN2010/000682
Authority: WO
Inventors: Vishal Borker
Original assignee: Vishal Borker
Priority date: 2009-10-15
Filing date: 2010-10-18
Publication date: 2011-04-21

Abstract

This invention relates to client-server systems, and more particularly to media transfer between server and client systems. A method and system for delivery of media content from a remote module to client systems by efficient management of available bandwidth and ensuring that the security of the delivered content is not compromised. A Media ON Demand (MOD) module splits media content into a minor component and a major component and creates corresponding metadata information. The minor component is directly sent from the MOD module to the client, along with the licensing information and metadata information over a secure connection. The major component may be transmitted directly between individual clients requesting the same media content over a peer to peer network or physical means. License is given to the client so that only the authorized client can use the transmitted media.

Description

METHOD AND APPARATUS FOR CONTENT DELIVERY OVER INTERNET

FIELD OF INVENTION

[001] This invention relates to client-server systems, and more particularly to 5media transfer between server and client systems.

BACKGROUND OF INVENTION

[002] Media On Demand (MOD) systems transfer Digital Rights Management (DRM) enabled media content from a MOD module to a remote MOD client which lOmay be running on a Computer or set-top box device, interfaced with the MOD module over a internet or private Local Area Connection (LAN) connectivity, permitting the users of the MOD client to consume locally, the DRM protected media received from the MOD module. Media content can be downloaded to any device capable of storing and consuming the Digital Rights Management (DRM) enabled

15content, at any time. When a client requests for a media from the MOD module, the media will usually be DRM'd so that it can be consumed only by the client requesting for it, for a specific number of times and/or for a specific time period, on expiry of which the media may be invalidated for consumption on the MOD Client. Such Media content is then transferred to the MOD client system, usually over a secure/encrypted

20connection. Once this media is available locally, the client can then call on a range of services as permitted by the DRM mechanism while accessing/consuming/playing the media.

[003] It must be noted that Common Client Server MOD Architectures suffer from issues of scalability, drop in performance, exponential bandwidth needs and high 25infrastructure cost as the number of MOD clients interfacing with the MOD module Increase. Also due to the limited bandwidth availability on the MOD module side, a limited number of users may be served at one time by the server resulting in concerns regarding cost effectiveness, performance and scalability of such MOD architectures in large scale MOD deployments.

5 [004] In present MOD architectures, if multiple users request for the same media from the MOD module, the MOD module fetches the media, DRM enables this media for each client and then serves the DRM'd media to the user. This results in huge processing and bandwidth requirements at the MOD module end.

[005] DRM encoding of the media is essential since the MOD module needs a lOreasonable level of security against media piracy before supplying the media to a remote client, but quality encryption is costly and raises the price of the electronic and software components needed by MOD modules and MOD clients. There is also a difficulty in controlling the duplication of the transmitted DRM enabled media.

15

SUMMARY

[006] The principal object of this invention is to identify a MOD Client Server architecture that will enable delivery of media content from a MOD module to a MOD client system such that the content delivered is DRM enabled, protected and 20also utilizes the least bandwidth required for transferring the Media content between the MOD module and client, whilst ensuring that the complexity of the media delivery system, infrastructure costs and bandwidth costs are maintained at the most minimal levels. [007] Another object of the invention is to outline methods of consumption of the Media on the MOD Client, inline with the mechanism of delivery of DRM'd media content.

[008] These and other aspects of the embodiments herein will be better 5appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein lOwithout departing from the spirit thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF FIGURES

[009] This invention is illustrated in the accompanying drawings, through out 15which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0010] FIG. 1 illustrates a block diagram of client systems connected to a MOD module, according to embodiments as disclosed herein;

20 [0011] FIG. 2 illustrates a block diagram of a MOD module, according to embodiments as disclosed herein;

[0012] FIG. 3 illustrates a block diagram of a client system, according to embodiments as disclosed herein;

[0013] FIGs. 4a and 4b are flowcharts depicting a method for transferring 25media content from a MOD module to a client, according to an embodiment herein; [0014] FIG 5 is a flowchart depicting the process of media playback, according to embodiments disclosed herein; and

[0015] FIGs. 6a and 6b are flowcharts depicting a method for transferring video from a Video on Demand (VOD) module to a client, according to anembodiment herein.

DETAILED DESCRIPTION OF INVENTION

[0016] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the 5following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not lObe construed as limiting the scope of the embodiments herein.

[0017] The embodiments herein enable delivery of media content from a MOD module to MOD client systems, such that the delivered content is efficiently protected by DRM methods whilst reducing the bandwidth for delivering the media content to the client, hereby reducing the complexity of the media delivery system and

15reducing the costs related to infrastructure and bandwidth. Also, the speed of delivery of media content to MOD clients is increased, and the costs incurred in delivering content to the MOD clients reduced by having the clients transfer parts of the media content directly between each other, reducing MOD module involvement. If there are multiple clients trying to download the same media content, then the speed of

20download by individual clients increases as the number of clients downloading that media content or have already downloaded that media content increases. Referring now to the drawings, and more particularly to FIGs. 1 through 6, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments. [0018] FIG. 1 illustrates a block diagram of client systems connected to a MOD module. A MOD module 101 streams content to a client 102 system, allowing a user of the client 102 system to view in real time or to download the media content to a device capable of storing the media content, for viewing at a later point in time. For 5example, a music file may be downloaded from the MOD module 101 to a computer. The MOD module 101 splits media content into a major component and a minor component. For example, if the media content is an MP3 file, then the minor component may be the MP3 header and periodic chunks of audio data bytes from the MP3 file stream, amounting to a minor fraction of the MP3 file size, and the major lOcomponent may be the remainder of the MP3 file. The minor and the major components are stored in the MOD module 101. If any client 102 system wants media content stored in the MOD module 101, the client sends a request to the MOD module 101 along with the account information of the client over a secure and encrypted connection set up by the client 102. The account information may comprise of the

15user name of the client, password of the client, payment information and so on. On receiving the request, the MOD module 101 verifies the account information received from the client, and then sends to the client, over the encrypted and secure connection, the minor component of requested media content, DRM/licensing information generated as per clients request and information pertaining to usage of major and

20minor components for the re-construction of media during playback/usage. Also sent to the client over this secure encrypted connection is information detailing the means and location(s) for downloading the major component of the file, using separate and unencrypted means of data transfer, which may utilize technologies such as Peer to Peer data transfer protocol. [0019] The licensing DRM information, information on the means and locations to be used for obtaining the major components and information on how to merge the major and minor components and information on how to access the major component may also be present in different order to reconstruct the original media file 5before consumption (playback, usage) on the MOD client is delivered from the MOD module to the MOD Client and is referred to as Metadata. This Metadata may be delivered in a single Metadata file or separately using multiple Metadata files. This metadata may also be delivered in a metadata stream. The minor and major components of the requested media content are sent to the client 102 separately. The lOmajor component may be received by the client directly from the MOD module 101, from both the MOD module 101 and other clients, over a peer to peer file transfer enabled network architecture, only from other clients over a peer to peer transfer

• enabled network architecture or through physical means. The major component may be transferred to the client 102 using a peer to peer communication link. The client

15102 may also receive the major component using a physical transmission means, like a CD-ROM, DVD, USB drives, hard drives and so on. The client, on receiving the minor component, licensing and metadata information, information on how to merge the major and minor components and atleast a part of the major component may begin to access/consume the requested media. Multiple client 102 systems may be

20connected to the MOD module 101 through a suitable means like the World Wide Web.

[0020] FIG. 2 illustrates a block diagram of a MOD module. The MOD module 101 splits media content into a minor component and a major component. For example, a MPEG standard audio video file may be split into audio data, I, P, and B 25frames. A file containing the I frames may be stored as the minor component and a file containing the P and B frames and the audio data may be stored as the major component. Some portion of the P and/or B frames and/or the audio data may also be present in the minor component. The minor and the major components are stored as different files in a memory 202 in the MOD module 101. If any client 102 system 5wants media content stored in the MOD module 101, the client sends a request to the MOD module 101 along with the account information of the client. On receiving the request, the MOD module 101 verifies the account information of the client 102. On verifying the account information, a license management module 201 generates a license specific to the requesting user. The generated license may be added to the lOheader of the metadata. The generated license comprises of information like the client account information, the number of times the client 102 may play the media, the time period during which the client 102 may be allowed to play the media and so on. This generated license may also be delivered to the client in a file distinct from the metadata. A content security module 203 may be used to add further DRM restrictions

15and protection measures to the files before delivery to client. The DRM restrictions and protection measures may be set by the MOD module 101, according to the media license requested by the client 102. The MOD module 101 sends to the requesting client 102 through the secure connection using a delivery module 205, which may encrypt the data before delivering to the MOD Client 102, the minor component of

20requested media content, licensing information, information on how to merge the major and minor components and information on how to access the major component. The secure connection may have been set up between the client 102 and MOD module 101 before making the request. The major component may then be received by the client directly from the MOD module 101, from both the MOD module 101

25and other clients, only from other clients or through physical means. The major component may be transferred to the client 102 using a peer to peer network. For example, the minor and the major components may be sent directly from the MOD module 101 to the client 102 who makes the first request for a specific media from the MOD module 101 while. For all the subsequent clients 102 which make a request for 5the same specific media, only the minor component, which has been DRM'd separately for each client, will be sent from the MOD module 101 to the client 102 who makes the next request for a specific media. The client and the major component may be downloaded by the client 102 who makes the next request for a specific media may download the major component from both the MOD module 101 and the client lOwho makes the first request for the specific media. All the other clients 102 who have already requested for and downloaded the major component. The download of major component from other clients 102 will be done using peer to peer communication network protocols. As an example, BitTorrent may be used to download the major component. A processor 204 controls the functioning of the MOD module 101. The

15processor 204 controls the splitting of content, storage, delivery and the functioning of all the modules in the MOD module 101.

[0021] FIG. 3 illustrates a block diagram of a client system. If a client 102 system wants media content stored in the MOD module 101, the client sends a request to the MOD module 101 along with the account information for the client 102. A

20secured connection may be set up between the MOD module 101 and client 102. On verifying the request, the MOD module 101 serves the requested media content to the requesting client 102 in two parts; a minor component and a major component. The MOD module 101 also sends to the requesting client 102 the licensing information, information on how to merge the major and minor components and information on

25how and where to download the major component. The licensing information, information on how to merge the major and minor components and information on how and where to download the major component may be present in a single metadata. The above information may also be present in separate files. The major component may be received by the client 102 directly from the MOD module 101, 5from both the MOD module 101 and other clients, from other clients or through physical means. The major component may be transferred to the client 102 using a peer to peer network. The client 102 may also receive the major component using a physical transmission means, like a CD-ROM, DVD, USB drives, hard drives and so on. The client 102 on receiving the files, stores the files in the memory 302. The lOmemory 302 has been partitioned into an encrypted memory and a non-encrypted memory. The minor component along with the metadata is stored in the encrypted memory and the major component is stored in the non-encrypted memory. Only the content playback module 305 can access and decrypt the encrypted memory for playback. The major component stored in the non-encrypted memory can be freely

15transmitted by the client 102 to other clients 102 over a network, by physical means or over a peer to peer architecture. Only the particular client 102 that is given the license would be able to use the transmitted media content with the help of the license. A license management 301 module manages the various licenses given to various media content received by the client 102. A content security 303 module manages the

20restrictions that have been placed on the received media content by the MOD module 101 and processes the usage of the media according to the restrictions placed by the MOD module 101. A processor 304 controls the functioning of the client 102 system. The processor 304 controls the storage, use and license management of the received media content and the functioning of all the modules in the client 102 system. The

25content playback module 305, on receiving the request from the client for playback, accesses the metadata from the encrypted memory and checks the license information if the client is authorized to play the media. The client may not be permitted to play the media if the client has exceeded the number of times the client is permitted to play the media or if the time duration the client is permitted to play the media has expired, 5as defined in the license information. If the client is permitted to access the media, the content playback module 305 further checks from where to access the major component and checks if atleast a portion of the major component is present with the client 102. If atleast a portion of the major component is not present with the client 102, the content playback module 305 instructs the processor 304 to start fetching the lOmajor component. Once atleast a portion of the major component has been fetched, the content playback module 305 fetches the minor component from the encrypted memory and merges the minor component and the major component, as per directions in the metadata to reconstruct the original media file, which can be then processed for playback. The merging of the minor component and the major component is done in

15real time, ensuring that no complete copy of the merged file exists on the client 102 at any point in time.

[0022] FIGs. 4a and 4b are flowcharts depicting a method for transferring media content from a MOD module to a client. The MOD module 101 receives (401) different kinds of media content. The MOD module 101 splits (402) media content

20into a minor component and a major component before storing the media. A metadata is created (403), where the metadata comprises of licensing information, information on how to merge the major and minor components and information on how and where to download the major component to the requesting client 102. If any client 102 system wants any media content available from the MOD module 101, the client

25102 establishes (404) a secure connection between the MOD module 101 and the client 102 and sends (405) a request for that media to the MOD module 101. The request send by the client 102 may also comprise of the client account details. On receiving the request, the MOD module 101 verifies (406) the client credentials. If the MOD module was not able to verify the client credentials, the MOD module 101 5informs (407) the client of the failure in the verification. The client 102 is then offered (408) the option of trying again. If the client 102 wants to try again, then the process goes to step (405). If the MOD module was able to verify the client credentials, the MOD module 101 generates (409) a license based on the client media download request. The generated license comprises of information like the client account lOinformation, the number of times the client 102 may play the media, the time period for which the client 102 may play the media and so on. Only the particular client 102 is given the license, using which only the particular client 102 would be able to use the transmitted media content with the help of the license. The MOD module 101 modifies (410) the header of the metadata according to the generated license

15information. The MOD module 101 transmits (411) the minor component along with the metadata to the client 102 over the secure connection. The client 102 stores (412) the metadata and the minor component in the encrypted memory. The client 102 then fetches (413) the major component. The major component may be fetched by the client 102 directly from the MOD module 101, from both the MOD module 101 and

20other clients, from other clients or through physical means. The major component may be transferred to the client 102 using a peer to peer network. The client 102 may also receive the major component using a physical transmission means, like a CD- ROM, DVD, USB drives, hard drives and so on. The client 102 on receiving the major component, stores (414) the major component in the non-encrypted memory.

25The various actions in method 400 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIGs. 4a and 4b may be omitted.

[0023] FIG 5 is a flowchart depicting the process of media playback, according to embodiments disclosed herein. On receiving a request for playing a media, the client 102 reads (501) the metadata from the encrypted memory. Using information from the metadata, the client 102 identifies (502) the major component and minor component for this media. The client 102 checks (503) if atleast a portion of the major component is present in the client 102. If atleast a portion of the major component is present in the client 102, the client 102 fetches (504) the major component. The major component may be fetched by the client 102 directly from the MOD module 101, from both the MOD module 101 and other clients, from other clients or through physical means. The major component may be transferred to the client 102 using a peer to peer network. The client 102 may also fetch the major component using a physical transmission means, like a CD-ROM, DVD, USB drives, hard drives and so on. If atleast a portion of the major component is present in the client 102, the client 102 checks (505) the license information. The license information may be present within the metadata or may be present in a separate file. The client checks (506) if the client 102 has permission to play the media. If the client 102 is not permitted to play the media, then the client 102 informs (507) the user. The client may not be permitted to play the media if the client has exceeded the number of times the client is permitted to play the media or if the time duration the client is permitted access to the media has expired. If the client 102 has permission to play the media, then the client 102 reads (508) the minor component from the encrypted memory and merges (509) the contents from the major component and minor component, to form the actual Media file in real time, using the merging information contained in the metadata. The client 102 playbacks (510) the media simultaneously, while the merging of the contents from the major component and minor component happens at run time. The client 102 may also update (511) the license information on completion of playback. The various actions in method 500 5 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 5 may be omitted.

[0024] FIG'S. 6a and 6b are flowcharts depicting a method for transferring video from a VOD module to a client. On a Video on Demand (VOD) module receiving (601) a new video, the VOD module splits (602) the video into frames lOwhich may be classified as I frames, P frames, B frames and audio (A) frames. The entire set of I frames is stored (603) as an I file (minor component) and the P, B and A frames are stored (604) as a PBA file (major component). Some portion of the P and/or B frames and/or the A frames may also be present in the I file. The size of the I file may turn out to be about 3%-20% of the video. A metadata is also created (605), 15where the metadata comprises of licensing information, information on how a client 102 can merge the major and minor components to generate playable media at run time and information on how and where to download the major component. If any client 102 system wants any media content stored in the VOD module, the client 102 establishes (606) a secure connection with the VOD module. The client then sends 20(607) a request to the VOD module for the video. The request send by the client 102 may also comprise of the client account details. On receiving the request, the VOD module verifies (608) the client information. If the VOD module was not able to verify the client information, the VOD module informs (609) the client of the failure in the verification. The client 102 is then offered (610) the option of trying again. If 25the client 102 wants to try again, then the process goes to step (607). If the VOD module was able to verify the client information, the VOD module generates (611) a license based on the client information. The generated license comprises of information like the client account information, the number of times the client 102 may play the media, the time duration for which the client 102 may play the media 5and so on. Only the particular client 102 is given the license and only the particular client 102 would be able to use the transmitted license information, metadata and I file to generate at run time, playable media content using the freely available PBA file. The VOD module modifies (612) the header of the metadata according to the license information generated specific to the user request. The MOD module 101 lOtransmits (613) the I file along with the metadata to the client 102 over the secure connection. The client 102 stores (614) the metadata and the I file in the encrypted memory. The client 102 fetches (615) the PBA file independently. The PBA file may be fetched by the client 102 directly from the VOD module, from both the VOD module and other clients, from other clients or through physical means. The PBA file

15may be fetched to the client 102 using a peer to peer network. The client 102 may also receive the PBA file using a physical transmission means, like a CD-ROM, DVD, USB drives, hard drives and so on. The client 102 on receiving the PBA file stores (616) the PBA file in the non-encrypted memory. Though the embodiments disclosed above disclose a method of sharing video content, it will be obvious to a person of

20ordinary skill in the art to apply the embodiments as disclosed to live television content. The various actions in method 600 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG'S. 6a and 6b may be omitted.

[0025] At the MOD module 101, since the MOD module, directly serves only

25a minor component of the Media file, the number of clients 102 able to be handled is much higher. Thereby reducing costs associated with the MOD module 101 hardware and bandwidth needs. At the MOD module 101 side the processing power required to handle media management, media license management, and media delivery is reduced which in turn reduces the costs associated a running a media on demand service. The 5bandwidth required at the MOD module 101 side to allow media to be downloaded by multiple clients 102 is also reduced. The content delivery process to individual clients is simplified.

[0026] Efficient content download mechanism at the client 102 further reduces the load on the MOD module 101. License management ensures the media content is lOavailable to the user for use only for the specified time period or the specified number of usages as specified by the MOD module 101. Content security, copy protection and content encryption of the minor component and metadata ensures that the media content licensed to a specific client 102 can be used only by that particular client 102.

[0027] By distributing the major component over a P2P protocol such as

15BitTorrent, embodiments herein implement a radical approach to internet decentralization. Every client is also a server of the major component; the major component files are broken up into fragments that can be served from multiple locations, transparently harnessing the network of users to provide both bandwidth and major component data to other users. The more popular the major component file,

20in fact, the faster it can be served, as there are more users providing bandwidth and fragments of the complete major component file.

[0028] According to embodiments disclosed herein, the service automatically gets better the more people use it. In embodiments disclosed herein, there's an implicit "architecture of participation", a built-in ethic of cooperation, in which the MOD service acts primarily as an intelligent broker, connecting the clients to each other and harnessing the power of the clients themselves.

[0029] The embodiments disclosed herein can be implemented through at least one software program nmning on at least one hardware device and performing 5network management functions to control the network elements. The network elements shown in Figs. 1, 2 and 3 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

[0030] The embodiment disclosed herein describes a method and system to deliver media content from a server to client systems by efficient management of lOavailable bandwidth and ensuring that the security of the delivered content is not compromised. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a

15server or mobile device or any suitable programmable device. The method is implemented in a preferred embodiment through or together with a software program written in e.g. Very high speed integrated circuit Hardware Description Language (VHDL) another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The

20hardware device can be any kind of portable device that can be programmed. The device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs.

[0031] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying 5current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the major concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description lOand not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

Claims

1. A method for media transfer in a network, said method comprising steps of

A user requesting for a media file from a media on demand module;

Said media on demand module generating a license;

5 Said media on demand module modifying header of a metadata according to said license;

Said media on demand module sending said license, said metadata and a first portion of said media file to a client used by said user; and

Said client obtaining a second portion of said media file from at least one other lOsource.

2. The method, as claimed in claim 1, said method further comprises the step of said media on demand module splitting said media file into said first portion, said second portion and said metadata.

3. The method, as claimed in claim 1, wherein said metadata is one of

15 Metadata file; or

Metadata stream.

4. The method, as claimed in claim 1, wherein said metadata comprises of

Licensing information,

Digital Rights Management (DRM) information;

20 Location of said second portion; and

Procedure for merging said first portion and said second portion.

5. The method, as claimed in claim 1, said method further comprises of said user requesting for said media file from said media on demand module over a secure connection means.

6. The method, as claimed in claim 1, wherein said user sends user account information to said media on demand module along with said request.

7. The method, as claimed in claim 1, said method further comprises of said media on demand module checking if said user is authorized before generating said license.

58. The method, as claimed in claim 1, said method further comprises of said media on demand module sending said license, said metadata and a first portion of said media file to said client using a secure connection means.

9. The method, as claimed in claim 1, said method further comprises of said client obtaining said second portion of said media file based on information present in said lOmetadata.

10. The method, as claimed in claim 1, said method further comprises of said client obtaining said second portion of said media file using at least one of

peer to peer data transfer protocol;

File Transfer Protocol;

15 Hypertext Transfer Protocol; or

Physical media transfer means.

11. The method, as claimed in claim 10, wherein said peer to peer data transfer protocol is BitTorrent protocol.

12. The method, as claimed in claim 10, wherein said method further comprises of 20said client obtaining said second portion of said media file using peer to peer data transfer protocol from at least one of

Said media on demand module; or

At least one other client.

13. The method, as claimed in claim 1, wherein said method further comprises steps 25of Said client checking said license to check if said user is authorized to access said media file, on receiving a request from said user to access said media file;

Said client combining said first portion and said second portion if said user is authorized to access said media file; and

5 Said client making said media file available to said client.

14. The method, as claimed in claim 13, wherein said client updates said license on making said media file available to said client.

15. The method, as claimed in claim 13, wherein said client combines said first portion and said second portion such that the completely reconstructed media file is lOnot present in said client at any point in time.

16. A system comprising at least one means configured for

Enabling a user to request for a media file from a media on demand module; Enabling said media on demand module to generate a license;

Enabling said media on demand module to modify header of a metadata according 15to said license;

Enabling said media on demand module to send said license, said metadata and a first portion of said media file to a client used by said user; and

Enabling said client to obtain a second portion of said media file from at least one other source.

2017. The system, as claimed in claim 16, said system further comprises at least one means configured for enabling said media on demand module to split said media file into said first portion, said second portion and said metadata.

18. The system, as claimed in claim 16, said system further comprises at least one means configured for creating said metadata, wherein said metadata is one of 25 Metadata file; or Metadata stream.

19. The system, as claimed in claim 16, said system further comprises at least one means configured for creating said metadata, wherein said metadata comprises of

Licensing information,

5 Digital Rights Management (DRM) information;

Location of said second portion; and

Procedure for merging said first portion and said second portion.

20. The system, as claimed in claim 16, said system further comprises at least one means configured for enabling said user to request for said media file from said media lOon demand module over a secure connection means.

21. The system, as claimed in claim 16, said system further comprises at least one means configured for enabling said user to send user account information to said media on demand module along with said request.

22. The system, as claimed in claim 16, said system further comprises at least one 15means configured for enabling said media on demand module to check if said user is authorized before generating said license.

23. The system, as claimed in claim 16, said system further comprises at least one means configured for enabling said media on demand module to send said license, said metadata and a first portion of said media file to said client using a secure

20connection means.

24. The system, as claimed in claim 16, said system further comprises at least one means configured for enabling said client to obtain said second portion of said media

' file based on information present in said metadata.

25. The system, as claimed in claim 16, said system further comprises at least one means configured for enabling said client to obtain said second portion of said media file using at least one of

peer to peer data transfer protocol;

5 File Transfer Protocol;

Hypertext Transfer Protocol; or

Physical media transfer means.

26. The system, as claimed in claim 25, said system further comprises at least one means configured for enabling said client to obtain said second portion of said media lOfile using peer to peer data transfer protocol from at least one of

Said media on demand module; or

At least one other client.

27. The system, as claimed in claim 16, said system further comprises at least one means configured for

15 Enabling said client to check said license to check if said user is authorized to access said media file, on receiving a request from said user to access said media file;

Enabling said client to combine said first portion and said second portion if said user is authorized to access said media file; and

Enabling said client to make said media file available to said client.

2028. The system, as claimed in claim 27, said system further comprises at least one means configured for enabling said client to update said license on making said media file available to said client.

29. The system, as claimed in claim 27, said system further comprises at least one means configured for enabling said client to combine said first portion and said second portion such that the completely reconstructed media file is not present in said client at any point in time.

30. A module comprising of at least one means configured for

generating a license, on receiving a request for a media file from a user;

5 modifying header of a metadata according to said license; and

sending said license, said metadata and a first portion of said media file to a client used by said user.

31. The module, as claimed in claim 30, said module further comprises of at least one means configured for splitting said media file into said first portion, a second portion lOand said metadata.

32. The module, as claimed in claim 30, said module further comprises of at least one means configured for creating said metadata comprising of

Licensing information,

Digital Rights Management (DRM) information;

15 Location of said second portion; and

Procedure for merging said first portion and said second portion.

33. The module, as claimed in claim 30, said module further comprises of at least one means configured for accepting said request from said user over a secure connection means.

2034. The module, as claimed in claim 30, said module further comprises at least one means configured for checking if said user is authorized before generating said license.

35. The module, as claimed in claim 30, said module further comprises at least one means configured for sending said license, said metadata and a first portion of said 25media file to said client using a secure connection means.

36. The module, as claimed in claim 30, said module further comprises at least one means configured for providing said second portion using a peer to peer data transfer protocol.

37. The module, as claimed in claim 36, said module further comprises at least one 5means configured for providing said second portion using a peer to peer data transfer protocol, wherein said peer to peer data transfer protocol is BitTorrent protocol.

38. A client module comprising at least one means configured for

Receiving a license, a metadata and a first portion of a media file to a client used by a user from a media on demand module, on said user sending a request for said lOmedia file; and

Obtaining a second portion of said media file from at least one other source.

39. The client module, as claimed in claim 38, said client module further comprises at least one means configured for requesting for said media file from said media on demand module over a secure connection means.

1540. The client module, as claimed in claim 38, said client module further comprises at least one means configured for sending user account information to said media on demand module along with said request.

41. The client module, as claimed in claim 38, said client module further comprises at least one means configured for obtaining said second portion of said media file based

20on information present in said metadata.

42. The client module, as claimed in claim 38, said client module further comprises at least one means configured for obtaining said second portion of said media file using at least one of

peer to peer data transfer protocol;

25 File Transfer Protocol; Hypertext Transfer Protocol; or

Physical media transfer means.

43. The client module, as claimed in claim 42, said client module further comprises at least one means configured for obtaining said second portion of said media file using

5peer to peer data transfer protocol from at least one of

Said media on demand module; or

At least one other client

44. The client module, as claimed in claim 38, said client module further comprises at least one means configured for

10 checking said license to check if said user is authorized to access said media file, on receiving a request from said user to access said media file;

combining said first portion and said second portion if said user is authorized to access said media file; and

making said media file available to said client.

1545. The client module, as claimed in claim 44, said client module further comprises at least one means configured for updating said license on making said media file available to said client.

46. The client module, as claimed in claim 44, said client module further comprises at least one means configured for combining said first portion and said second portion 20such that the completely reconstructed media file is not present in said client at any point in time.

25