The present invention comprises a content delivery system for delivering content to clients. The content delivery system comprises at least one mobile object adapted to be executed on the content delivery system and on other content delivery systems or multimedia devices adapted for mobile objects. Each mobile object comprises a media file and is further adapted to determine the capabilities of the other content delivery systems or multimedia devices and to monitor data related to the clients' access of the media file. The content delivery system also comprises a transcoder unit for transcoding the media file to another media file prior sending it to the other content delivery system or multimedia device. The invention solves problems that can arise when sending large media files to content delivery systems or multimedia devices having limited capabilities.
|
9. A method for placing content in a multimedia device comprising the steps of:
executing in a content delivery system a first mobile object comprising execution logic, a policy data base and a first media file accessible by a client in the multimedia device and where the execution logic comprises client access data related to the client's access of the first media file;
receiving a request from the client to access the first media file;
when certain conditions stored in the policy data base are met by the client access data, sending a copy of and created by the first mobile object excluding the first media file to the multimedia device;
determining capabilities in the multimedia device for receiving the first media file;
creating a reference to the copied first mobile object in the first mobile object;
transcoding the first media file into a second media file if the multimedia device is not capable of receiving the first media file; and
sending the second media file to the copied first mobile object in the multimedia device.
5. A method for placing content in a content delivery network comprising the steps of:
executing in a first content delivery system a first mobile object comprising execution logic, a policy data base and a first media file accessible by at least one client and where the execution logic comprises client access data related to the clients' access of the first media file;
monitoring the client access data;
when certain conditions stored in the policy data base are met by the client access data, sending a copy of and created by the first mobile object excluding the first media file to a second content delivery system;
determining capabilities of the second content delivery system for receiving the first media file;
creating a reference to the copied first mobile object in the first mobile object;
transcoding the first media file into a second media file if the second content delivery system is not capable of receiving the first media file; and
sending the second media file to the copied first mobile object in the second content delivery system.
3. A content delivery system for delivering content to at least one client, said content delivery system comprising:
a processor,
a memory area, and
at least one mobile object adapted to be stored in the memory area and to be executed in the content delivery system and in at least one multimedia device adapted to execute mobile objects and comprising the client and where the mobile object comprises the following parts:
a first media file accessible by the client;
a policy data base;
execution logic comprising program code and a data area and where the data area comprises client access data related to the client's access of the first media file and where the execution logic is adapted to receive a request for the first media file from the client, to determine capabilities of the multimedia device, to copy the mobile object excluding the first media file to the multimedia device when certain conditions stored in the policy data base are met by the client access data and create a reference to the copied mobile object in the mobile object; and
where the content delivery system further comprises a transcoder unit adapted to transcode the first media file into a second media file prior to the sending of the second media file to the copied mobile object in the multimedia device.
1. A first content delivery system for delivering content to at least one client, said first content delivery system comprising:
a processor;
a memory area, and
at least one mobile object adapted to be stored in the memory area and to be executed in the first content delivery system and in at least one second content delivery system and where the mobile object comprises the following parts:
a first media file accessible by clients;
a policy data base; and
execution logic comprising program code and a data area where the data area comprises client access data related to the clients' access of the first media file and where the execution logic is adapted to determine capabilities of the second content delivery system and to monitor the client access data, to interrogate the policy data base, to copy the mobile object excluding the first media file to the second content delivery system when certain conditions stored in the policy data base are met by the client access data and create a reference to the copied mobile object in the mobile object; and
wherein the first content delivery system further comprises a transcoder unit, adapted to transcode the first media file into a second media file prior to sending the second media file to the copied mobile object in the second content delivery system.
2. The content delivery system as in
4. The content delivery system as in
6. The method as in
7. The method as in
10. The method as in
11. The method as in
|
The present invention relates to a method and a system for content delivery.
A content delivery network or content distribution network (CDN) is a system of computers (such as content servers) networked together across the Internet and that delivers content (especially media content) to clients. Content delivery networks are difficult to control and manage as requests for content come from different locations sometimes following certain viewing patterns. In order to optimize performance, locations of the content servers and media content close to the client may be chosen. Many parameters have to be taken into account to optimize the media delivery in content delivery networks, for example:
The number of parameters and unpredictability when it comes to user behavior makes this problem very complex if one wants to control a global CDN using a central management system.
Existing solutions try to solve this problem in a centralized approach. Taking all the parameters into account the different solutions try to best place content in the network. However, the dynamicity of such an environment makes the algorithms highly complex and global decisions take a long time to be made and effectuated.
Another technical area relevant to the current invention is mobile objects (also called mobile agents). Mobile objects are programs (software) and associated data that can migrate from host to host in a network at times and to places of their own choosing. In the new host they can then continue to run, possibly interacting with the local execution environment. Mobile objects have for example been discussed in the paper ‘Mobile Agents and the Future of the Internet’ by Kotz et al published in ‘ACM Operating Systems Review, August 1999 pp 7-13. An example of using mobile agents is disclosed in U.S. Pat. No. 7,254,608. This patent discloses a system and a method for using mobile agents for managing distribution of content in peer-to-peer networks. In the patent the mobile agent may visit the peer nodes on an itinerary to search for and collect information on distributor content stored on the visited peer.
The present invention relates to the problem of how to avoid the disadvantages mentioned above of managing a content delivery network.
The problem is in the current invention solved by placing the content itself (such as media files) in the mobile objects (agents). The invention comprises a content delivery system for delivering content to clients where the content itself (such as media files) is placed within the mobile objects (agents). This content delivery system comprises at least one mobile object adapted to be executed on the content delivery system but also adapted to be executed on other content delivery systems or multimedia devices adapted to execute mobile objects. What characterizes these mobile objects is that they comprise:
The execution logic is adapted to determine the capabilities of the other content delivery systems or multimedia devices.
The execution logic is also adapted to alternatively
The content delivery system does also include a transcoder unit adapted to transcode the media file prior sending it to other content delivery systems or multimedia devices having limited capabilities.
The invention does also include a method for placing content in the content delivery system or multimedia device.
In the method, the mobile object (comprising the policy data base and the media file accessible by the client as described above) executes in one content delivery system. The mobile object either:
After sending the copy excluding the media file, the mobile object also determines the capabilities of the other content delivery system or multimedia device. If the capabilities in the other content delivery system or multimedia device are restricted, the media file is transcoded before it is sent to the copy of the mobile object in the content delivery system or multimedia device.
The invention further includes a method and a multimedia device for receiving and executing mobile objects comprising media files.
The current invention makes the content (e.g., a media file) autonomous. By autonomous is here meant that the mobile object is intelligent enough to monitor data related to the client's access of the media file (e.g., number of times the media file has been downloaded, local link utilization measurements, link costs, etc) and to determine capabilities of other content delivery systems or multimedia devices and to take appropriate decisions. Instead of utilizing a central server (or a couple of servers) to gather global information and take global decisions the invention comprises a mobile object that takes local decisions based on local information. This will highly simplify the way content is placed and controlled through content delivery networks.
The objective with the current invention is therefore to overcome at least one of the disadvantages mentioned above.
The invention has several advantages:
Content such as media files can be placed in content delivery systems and multimedia devices having limited capabilities.
Efficient utilization of radio link (e.g., GPRS) and network resources (e.g., more powerful network-based execution environments).
Avoid utilizing scarce resources on the device with limited resources.
Allow mobile objects residing in portable devices to be utilized by the content delivery system.
Enhanced end-user experience (faster transcoding time, faster download time).
Robustness; the system is more robust since it features strong fault isolation characteristics. The mobile objects are independent pieces of software relying on the local environment and not on centralized systems. It is harder to launch a denial of service attack towards such a distributed system.
No central point of failure; equal distribution of control and management functionalities brings a nice load distribution and no central point of failure.
Simplicity; the complexity of traditional global optimization algorithms is eliminated by allowing local decisions based on local knowledge to be taken.
Lower maintenance/management costs; simplicity leads to lower cost of maintenance of the entire system.
The invention will now be described in more detail and with preferred embodiments and referring to accompanying drawings.
In known prior art, the content servers 111, 112, 113 and 114 are managed by a central operation and management center, OMC 190. As discussed above, this solution has a number of drawbacks.
The mobile object 212 further comprises execution logic 214. The execution logic comprises program code 215 and a data area 216 that is used to execute the mobile object 212. The execution logic 214 is also handling requests in action 231 from the clients 230, 240 that want to access the media file 213. The programming language for the program code 215 could preferably be Java which has been the most used programming language to implement mobile objects as it is platform independent. The data area 216 comprises also data related to the client's 230, 240 access of the media file 213 as for example:
In addition to monitor data in the data area 216 in the mobile object 212, the execution logic 214 is also adapted to monitor in action 241 data related the execution environment 211 as for example:
The mobile object 212 further comprises a policy data base 217. This data base 217 is adapted to comprise any kind of application specific policies that can trigger actions by the mobile object 212 as for example:
Furthermore, utilizing the inventive concept a skilled person can create different policies and corresponding behaviors that are more suitable and tailored to the management of a particular content delivery network.
Using the data 216 related to the access of the media file 213 and the execution environment 211 and interrogating the policy data base 217, the execution logic 214 can for example determine that a majority of the clients 240 accessing the media file 213 are located close to another server, Content Server 2 220.
Fulfilling certain conditions stored in the policy data base 217 the execution logic 214 may trigger a process to move, in action 250, the mobile object 212 from Content Server 1 210 to Content Server 2 220 which has its own execution environment 221.
In this process the mobile object 212 may stop serving requests from the clients 230, 240. Active connections with clients 230, 240 are paused. The clients 230, 240 are informed about the pause by the mobile object 212 using suitable signaling protocols (e.g., a modified TCP). This signaling is normally demanding some support from the execution environment 211 and underlying operating system. The execution environments 211 and 221, on the other hand, do not know where the mobile object 212 came from or where it is going next.
In the process of moving, the mobile object 212 moves from the original Content Server 1 210 to Content Server 2 220 without leaving any traces in Content Server 1 210.
Fulfilling other conditions stored in the policy data base 217 the execution logic 214 may trigger a process to copy the mobile object 212 from Content Server 1 210 to a new mobile object 222 in Content Server 2 220. In this case, the mobile object 212 in Content Server 1 210 continues to execute in parallel with the copy 222.
The copy 222 of mobile object 212 could either be adapted to keep its execution states when starting to execute in Content server 2 220 or it could be adapted to reset the execution states prior the execution.
In order for clients not previously connected to find the new location of the mobile object 222, a name resolution process is started using for example DNS (Domain Name Service) redirection.
A situation that also can occur is that very few (or no) clients at all have accessed the media file 213 for a certain period of time. This can be an indication that the media file 213 has become less popular or that the clients 240 are located close to another Content Server 2 220 already hosting a copy of the media file 213. In this situation, the execution logic 214 can take a decision to simply let the mobile object 212 in Content Server 1 210 ‘die’ and delete itself.
The flow charts in
In step 303, a check is made if the media file 213 can be deleted. If a certain period of time has lapsed without any client 230, 240 accessing the media file 213 or that the media file 213 has been accessed very seldom, the mobile object 212 can make the decision to halt the execution and delete itself in step 304. The conditions for this are stored in the policy data base 217. If, on the contrary, the media file 213 is very popular but mainly accessed by clients 240 located closer to the other content server 220, the mobile object 212 makes the decision in step 305 to move the mobile object 212 to the other server 220. But before sending the mobile object to the other content server 220 in step 307, the mobile object 212 halts in step 306 the access to the media file 213 and pauses the active connections between clients 230, 240 and the mobile object 212.
If the decision in step 305 is to not move the media file 213, the flow chart continues (digit ‘2’ encircled) in
If the media file 213 is popular in both regions where clients 230 (close to Content Server 1 210) and clients 240 (close to Content Server 2 220) are located, the mobile object 212 can make the decision in step 308 (now turning to
Yet another aspect of the invention is that the content delivery system 220 can be seen as a content delivery end-point (source of content) that is created dynamically when the mobile object 212 is moved or copied into the execution environment 221. As an example, a server that is originally not a content server but having an execution environment 221 adapted for mobile objects in general can become a Content Server 2 220 when the mobile object 212 according to the invention is copied or moved into the execution environment 221 in the server 220.
The current invention is in the embodiments described above applied to a mobile object 212 that is moved and/or copied from one content server 210 to another content server 220. The inventive concept does also allow for the mobile object 212 to migrate between other content delivery systems or to other systems or devices adapted to execute mobile objects 212.
One example of this is a peer-to-peer P2P network.
Another example are portable devices such as PDAs, smart phones, game consoles and so on. The portable devices can themselves be content delivery systems and part of the content delivery network 100, but can also be a portable device only adapted to receive and execute mobile objects. In principle, the portable devices can in addition comprise a client that itself can request content from the content delivery network 100.
The first content delivery system 510 comprises an execution environment 511, at least one mobile object 512 adapted to run in the execution environment 511. The mobile object 512 in turn comprises execution logic 514, a policy data base 517 and a media file 513. The execution logic 514 is also adapted to monitor in action 5143 data related to the execution environment 511. The first content delivery system 510 further comprises a transcoder 519 adapted to transcode the media files 513.
The term transcode does here include various types of transformation of the media file 513. If for example the media file 513 is a video file, transcoding can mean digitally compressing, changing sample rate, converting between different coding formats etc.
The second content delivery system 520 comprises an execution environment 521 adapted for mobile objects. It further comprises an execution interface 540 to the execution logic 521 that is adapted so that mobile objects 522 can access information about the capabilities of the second content delivery system 520. In addition, the second content delivery system 520 optionally comprises a client C 528.
The client X 660 is a traditional client that can access the media file 513 but is neither part of the content delivery network 100 nor having capabilities of executing mobile objects.
When sending the mobile object 512 from the first content delivery system 510 to the second content delivery system 520 or the multimedia device 620, a number of considerations have to be made with regard to the capabilities of this system 520 and this device 620. The capabilities can be limited by the system/device 520,620 itself such as screen resolution, processing power, memory, supporting decoding types, battery life-time etc. Other capabilities can be network related such as link capacity and link costs (especially for wireless devices). If for example the media file 513 is a high definition video file, this video file may be unsuitable for being presented on a small wireless smart phone screen. Alternatively, the link capacity between the first content delivery system 510 and the system/device 520,620 can be limited (such as low bandwidth) which makes the distribution too slow. To overcome this, the invention includes the feature to transcode in action 707 the media file 513 to a format more suitable for the system/device 520,620 prior sending it in action 708 to the system/device 520,620.
The method to place content in a content delivery system 520 having limited capabilities is illustrated more in detail in by the flow chart in
When the child mobile object 522 is received by the content delivery system 520, it starts to collect information about the capabilities in the system 520. This can be done by simple system calls within the system 520 and can also include network probing. The probing can be performed as measurements between the child mobile object 522 and the parent mobile object 512 in the content delivery system 510 to detect current link conditions such as bandwidth etc.
When the information of the capabilities has been collected by the child mobile object 522 in the content delivery system 520, it returns this information in step 705 in a message to the parent mobile object 512 in the content delivery system 510.
The parent mobile object 512 determines in step 706 if transcoding is necessary. If not, the media file 513 is sent unchanged in step 708 to the child mobile object 522. This can for example be the case when the content delivery system 520 itself can perform the transcoding. If transcoding is needed in step 706, the media file 513 is transcoded in step 707 by the transcoder 519 and sent in step 708 to the child mobile object 522. The execution of the parent mobile object 512 is continued as before in step 701.
In addition to transcode the media file 513 in step 707, optionally a reference between the parent mobile object 512 and the child mobile object 522 is created and stored in the parent mobile object 512. The use of this reference will be discussed more in detail further below.
The method to place content in the multimedia device 620 is illustrated more in detail by the flow chart in
The knowledge that the client M 628 is residing in a portable device 620 can be determined, for example, by analyzing the HTTP request and identifying the specific portable device's browser. The ability to execute mobile objects can for example be determined by receiving an explicit indication in the request 630.
When the information of the capabilities of the portable device 620 has been collected by the child mobile object 622, it returns this information in step 805 in a message to the parent mobile object 512.
The parent mobile object 512 determines in step 806 if transcoding is necessary. If not, the media file 513 is sent unchanged in step 808 to the child mobile object 622. This can for example be the case when the portable device 620 itself can perform the transcoding. If transcoding is needed in step 806, the media file 513 is transcoded in step 807 by the transcoder 519 to a transcoded media file 523 and sent in step 808 to the child mobile object 622 in the portable device 620. The execution of the parent mobile object 512 is continued as before in step 801.
As a further option, a user of the portable device 620 can specify some parameters related to the capabilities of the device 620 to be used for playback of the content. These parameters can be accessed by the child mobile object 622. The parameters can for example comprise an override parameter that says that irrespectively of the capabilities of the portable device 620, the media file 513 should be delivered unchanged. This option could be used when the user desires to receive the full media file 513 but intends to transfer it locally to another device having a more suitable display such as a desktop computer or a HDTV set. By returning the overridden parameter in step 805, the parent mobile object 512 considers this in step 806 and sends in step 808 the media file 513 unchanged to the child mobile object 622.
The method to receive content in the portable device 620 seen from the portable device's 620 point of view is illustrated by the flow chart in
When receiving the child mobile object 622, the portable device 620 starts in step 1003 to collect information about the capabilities in the device 620. This can be done by simple system calls within the device 620 and can also include probing. The probing can be performed as measurements between the child mobile object 622 and the parent mobile object 512 in the content delivery system 510 to detect current link conditions such as bandwidth, packet loss etc. When the information of the capabilities has been collected by the child mobile object 622, it returns this information in step 1004 in a message to the parent mobile object 512. After that the parent mobile object 512 has determined that the original media file 513 needs to be transcoded, it transcodes the media file 513 to a new transcoded media file 623 and sends that to the child mobile object 622 in the portable device 620. After that the child mobile object 622 has received the transcoded media file 623 in step 1005, it stores it in step 1006.
If the child mobile object 622 includes a transcoded media file 623 different from the original media file 513, the child mobile object 622 is no longer the same as the original parent mobile object 512.
An alternative for the parent mobile object 910 to transcode the media file 914 before sending it to the third mobile object 940 is to refer to an already existing transcoded media file 924,934 in an already existing child mobile object 920,930. This is done by storing references 921,931 to the child objects 920,930 in the parent mobile object 910.
In the case with the third child mobile object 940, the parent mobile object 910 can for example decide to send in action 941 the reference 931 to the child mobile object 930 instead of sending a transcoded media file. The procedure to do this is similar to the procedure illustrated by the flow chart in
The parent mobile object 910 is adapted to keep the references 921, 931 alive only if certain conditions are met. If the parent mobile object 910 judges that the available bandwidth or the processing power for the systems or devices carrying the child objects 920,930 is too restricted, it may erase the references 921,931. The parent mobile object 910 can also erase the references 921,931 when no request relating to the existing transcoded media files 924,934 has been received for a certain period of time.
The invention does also include a multimedia device 620 for playing media files 523 received from the content delivery system 510. This device is illustrated in
The multimedia device 620 comprises a client 628. Triggered by a user event in step 1000 (see flow chart in
Certain requested media files 513 may not be suitable to be played on the multimedia device 620 due to limited screen resolution, processing power, memory, supporting decoding types, battery life-time etc. In order to overcome this, the execution environment 621 in the multimedia device 620 is provided with an execution interface (640) accessible by the mobile object (622). Through this execution interface (640) the mobile object (622) can access information about the capabilities of the multimedia device 620. This information is sent to the mobile object 512 in the content delivery system 510. This mobile object 512 will then, if necessary, initiate a transcoding of the media file 513 to a transcoded media file 623. The transcoded media file 623 (or the original media file 513) is then sent to and received by the multimedia device 620.
As an option, the multimedia device 620 also comprises an internal transcoder unit 629 that can transcode the original media file 513 to a transcoded media file 623.
Patent | Priority | Assignee | Title |
10417394, | Aug 14 2009 | Ericsson AB | Method and system for unified mobile content protection |
9858396, | Aug 14 2009 | Ericsson AB | Method and system for unified mobile content protection |
Patent | Priority | Assignee | Title |
6055562, | May 01 1997 | International Business Machines Corporation | Dynamic mobile agents |
6658000, | Jun 01 2000 | Google Technology Holdings LLC | Selective routing |
6701316, | Apr 07 2000 | NEC Corporation | Method and apparatus for intelligent network bandwidth and system resource utilization for web content fetch and refresh |
6810417, | Feb 20 2001 | LEE, KIN MAN | Content delivery network system and method for network configuring |
6886029, | Mar 13 2001 | Intelsat Corporation | End to end simulation of a content delivery system |
6888477, | Dec 22 2000 | Sony Corporation | Distributed on-demand media transcoding system and method |
6892218, | Sep 28 1998 | ARRAY NETWORKS, INC | Extending network services using mobile agents |
6970902, | May 24 2001 | Cisco Technology, Inc. | Method and apparatus for providing a distributed service in a network |
7024466, | Apr 07 2000 | BLOCKBUSTER L L C | Network configured for delivery of content for download to a recipient |
7155531, | Jun 12 2001 | Network Appliance | Storage methods and apparatus for streaming media data |
7254608, | Oct 31 2002 | Oracle America, Inc | Managing distribution of content using mobile agents in peer-topeer networks |
7415537, | Apr 07 2000 | Nuance Communications, Inc | Conversational portal for providing conversational browsing and multimedia broadcast on demand |
7499990, | Nov 17 1999 | International Business Machines Corporation | Apparatus and method for managing mobile agents |
7689510, | Sep 07 2000 | Rovi Technologies Corporation | Methods and system for use in network management of content |
7761609, | Jan 20 2005 | Oracle America, Inc | Socket level packet scheduling for connectionless protocols |
8150897, | Feb 27 2002 | Science Park Corporation | Computer file system driver control method, program thereof, and program recording medium |
8260881, | Sep 06 2006 | Amazon Technologies, Inc | Remote download of content |
8266357, | Mar 31 2006 | Malikie Innovations Limited | System and method for provisioning a remote resource for an electronic device |
8423496, | Dec 22 2006 | CALLAHAN CELLULAR L L C | Dynamic determination of needed agent rules |
8510596, | Feb 09 2006 | VIRSEC SYSTEMS, INC | System and methods for run time detection and correction of memory corruption |
20010025346, | |||
20020120721, | |||
20030037097, | |||
20030135566, | |||
20030154399, | |||
20040010590, | |||
20040088348, | |||
20050060561, | |||
20050210120, | |||
20050235148, | |||
20050273858, | |||
20060015580, | |||
20060018264, | |||
20060161635, | |||
20060236367, | |||
20060248139, | |||
20070033340, | |||
20070094675, | |||
20070168294, | |||
20070204115, | |||
20070217436, | |||
20070226365, | |||
20070237133, | |||
20070266383, | |||
20070282951, | |||
20080059631, | |||
20080216145, | |||
20090055547, | |||
20120036361, | |||
20120072529, | |||
WO2009136828, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Dec 18 2008 | Telefonaktiebolaget L M Ericsson (publ) | (assignment on the face of the patent) | / | |||
Dec 19 2008 | KARLSSON, PER | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 026607 | /0175 | |
Dec 19 2008 | SOUZA, VICTOR | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 026607 | /0175 |
Date | Maintenance Fee Events |
Aug 23 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Oct 16 2023 | REM: Maintenance Fee Reminder Mailed. |
Apr 01 2024 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Feb 23 2019 | 4 years fee payment window open |
Aug 23 2019 | 6 months grace period start (w surcharge) |
Feb 23 2020 | patent expiry (for year 4) |
Feb 23 2022 | 2 years to revive unintentionally abandoned end. (for year 4) |
Feb 23 2023 | 8 years fee payment window open |
Aug 23 2023 | 6 months grace period start (w surcharge) |
Feb 23 2024 | patent expiry (for year 8) |
Feb 23 2026 | 2 years to revive unintentionally abandoned end. (for year 8) |
Feb 23 2027 | 12 years fee payment window open |
Aug 23 2027 | 6 months grace period start (w surcharge) |
Feb 23 2028 | patent expiry (for year 12) |
Feb 23 2030 | 2 years to revive unintentionally abandoned end. (for year 12) |