Patent Grant
8918908
The present invention relates generally to digital rights management (DRM) systems and more specifically to authentication of user devices when purchasing and requesting access to DRM protected multimedia content.
When a customer visits a movie theater, the process typically involves purchasing a “ticket” at the ticket booth and having the ticket “torn” when the customer enters the theater. A ticket serves as a physical proof of purchase for the right to view a particular movie. A ticket can change possession from the purchaser to another customer and can be used by either person. When a ticket is claimed by entering the theater and being torn, the ticket is thought to be redeemed by the customer presenting the ticket and henceforth the viewing rights granted by the ticket are owned by that customer.
In a digital multimedia playback system, viewing rights are generally governed by possession of physical media that contains digital content. When the content is not tied to physical media, such as when digital content is streamed over a network, a digital rights management (DRM) system is often used to restrict access to the content. Such systems typically involve user accounts and associating purchased content with a user account. A user device may be registered to a user account and then have access to the content purchased under that user account.
Systems and methods for accessing digital content using electronic tickets and ticket tokens in accordance with embodiments of the invention are disclosed. In one embodiment, a user device includes a processor, a network interface, and memory configured to store an electronic ticket, and a ticket token, and the processor is configured by an application to send a request for digital content, receive a ticket token from a merchant server, wherein the ticket token is generated by a DRM server and associated with an electronic ticket that enables playback of the requested digital content, send the ticket token to a DRM server, receive an electronic ticket that enables playback of requested digital content, request the digital content associated with the electronic ticket, and play back the requested digital content using the electronic ticket.
In a further embodiment, the electronic ticket includes a torn status.
In another embodiment, the electronic ticket is an XML file.
In a still further embodiment, the electronic ticket identifies the purchased digital content.
In still another embodiment, the electronic ticket includes a characteristic of the purchased content selected from the group of information identifying the content that was purchased, a license indicating how the content can be played back, a purchase price, a merchant transaction identifier, the identification of a customer who purchased the ticket, and the identification of a customer owning the ticket.
In a yet further embodiment, the electronic ticket is associated with cryptographic data that can be used to access the digital content to which the electronic ticket refers.
In yet another embodiment, the ticket token references the electronic ticket, a customer, and the requested digital content.
In a further embodiment again, the processor is further configured to receive access information for the digital content.
In another embodiment again, the access information includes at least one piece of information selected from the group of a top level index of the digital content, an identifier for the digital content, and cryptographic data that can be used to access the digital content.
In a further additional embodiment, the electronic ticket is embedded in the header of a multimedia file.
Another additional embodiment includes sending a request for digital content from a user device to a merchant server, receiving a ticket token from the merchant server using the user device, where the ticket token is generated by a DRM server and associated with an electronic ticket that enables playback of the requested digital content, sending the ticket token to a DRM server using the user device, receiving the electronic ticket from the DRM server using the user device, downloading the digital content associated with the electronic ticket from a content server using the user device, and playing back the requested digital content.
In a still yet further embodiment, the electronic ticket includes a torn status.
In still yet another embodiment, the electronic ticket is an XML file.
In a still further embodiment again, the electronic ticket identifies the purchased digital content.
In still another embodiment again, the electronic ticket includes a characteristic of the purchased content selected from the group of information identifying the content that was purchased, a license indicating how the content can be played back, a purchase price, a merchant transaction identifier, the identification of a customer who purchased the ticket, and the identification of a customer owning the ticket.
In a still further additional embodiment, the electronic ticket is associated with cryptographic data that can be used to access the digital content to which the electronic ticket refers.
In still another additional embodiment, the ticket token references the electronic ticket, a customer, and the requested digital content.
A yet further embodiment again includes receiving access information for the digital content.
In yet another embodiment again, the access information includes at least one piece of information selected from the group of a top level index of the digital content, an identifier for the digital content, and cryptographic data that can be used to access the content.
In a yet further additional embodiment, the electronic ticket is embedded in the header of a multimedia file.
Turning now to the drawings, systems and methods for accessing digital content using electronic tickets and ticket tokens are illustrated. In many embodiments, a user device can communicate with merchant servers, digital rights management (DRM) servers, and content servers to request access to and play back digital content. A user device may be configured with a web browser, web application, or other application that provides a user interface to a customer. The interface typically displays the digital content available from a merchant and is populated with data from the merchant server.
In many embodiments, a user device can purchase the right to access digital content from a merchant server. However, the user device obtains the cryptographic information used to access the purchased content directly from a DRM server. In several embodiments, a merchant server requests that the DRM server issue the right to access a piece of digital content to one of its customers. In response to the request, the DRM server generates an electronic ticket. The DRM server can also generate a ticket token associated with the electronic ticket at that time and/or when a user device requests playback of the content via the merchant website. The electronic ticket is evidence of the right of a user device registered with the DRM server to playback DRM protected content. The ticket token is a temporary credential that can be used to obtain the electronic ticket from the DRM server by a playback device that is registered with the DRM server and/or to obtain cryptographic information enabling playback of the content from the DRM server. In many instances the DRM server cannot authenticate the user device that is purchasing the content from the merchant server. The DRM server can provide the ticket token to the merchant server, which passes the ticket token to the user device used to purchase the content. Provided the user device or another user device onto which the token is loaded is registered with the DRM server, the user device can provide the ticket token to the DRM server and obtain the electronic ticket and any cryptographic information needed to access the purchased content. At which point, the user device can request the DRM protected content from the content server and commence playback using the cryptographic information. The use of electronic tickets, and ticket tokens to authenticate the right of a user device to playback digital content in accordance with embodiments of the invention is discussed further below.
System Architecture
A system including user devices that can communicate with merchant servers, DRM servers and content servers to access digital content in accordance with an embodiment of the invention is illustrated in
An electronic ticket issued by the DRM server in response to the purchase of content that serves as a representation of the purchase can be used to facilitate access of the purchased content in a coordinated fashion among the user device 12, merchant server 14, DRM server 16, and content server 18. In many embodiments, however, the merchant server 14 is unable to authenticate the user device 12 that purchased the content to the DRM server 16. Accordingly, the DRM server 16 issues a ticket token to the merchant server 14 that acts as a temporary credential. In several embodiments, the ticket token is a single use credential that can be utilized by a user device that authenticates itself to the DRM server to obtain the electronic ticket and/or cryptographic information enabling playback of the content. In a number of embodiments, the ticket token is generated when the user device requests playback of the content and expires within a predetermined period of time. In other embodiments, the ticket token, is generated when the user device purchases the content.
The merchant server 14 can provide the ticket token to the user device 12 that purchased the content. Provided the user device 12 is registered with the DRM server 16, the user device 12 can authenticate itself to the DRM server and exchange the ticket token for the electronic ticket that evidences the user device's right to access the purchased content. Where the user device 12 that purchased the content is not authorized to participate within the DRM system administered by the DRM server 16, the ticket token can be transferred to a device that is capable of participating within the DRM system. In embodiments where the DRM server registers user devices with user accounts, DRM system can provide an electronic ticket to a registered user device and can associate the electronic ticket with the user account to which the device is registered. In this way, other user devices registered to the user account can request access to the purchased content following the initial exchange of the ticket token for the electronic ticket. In instances where the user device has previously requested playback of the content, the user device can be in possession of the electronic ticket. When the user device again requests playback of the content via the merchant website (for example by streaming), the merchant can provide the electronic ticket to the DRM server to obtain a ticket token. The user device can then use the ticket token to access the content in the manner outlined above and the DRM server can authenticate that the electronic ticket provided by the merchant server is associated with the user device attempting to play back the content prior to providing cryptographic information enabling play back of the content to the user device.
Although a specific architecture is shown in
Electronic Tickets
An electronic ticket represents the purchased right to access a piece of digital content. Electronic tickets can also be used to represent the right to playback any DRM protected content including free content that is not capable of being freely distributed and content played back under a subscription agreement. Accordingly, references to purchased content can be considered to encompass more than just requests to access DRM protected content that involve a direct payment and can extend to any request for access to content. An electronic ticket can be a string, binary data, or other electronic representation of information that includes at least a unique identifier for the content with which the electronic ticket is associated.
Electronic tickets typically remain valid for the life of the purchase. When the purchase is a rental of the content, the ticket may be expired after the rental period. A ticket can initially be in a conceptually “untorn” state before it is used to access content. It is not yet associated with any particular user account and/or user device, and can be transferred from the purchaser to any other user, for instance as a gift. The electronic ticket may be “torn” and associated with a user account and/or user device that then holds the exclusive rights granted by that ticket. Whether a DRM system associates an electronic ticket with a user account or a user device can depend on whether the DRM system grants access rights on a device or user basis. Thereafter, that user account and/or user device is considered the owner or holder of the ticket. An electronic ticket may be torn, for example, when it is used for the first time to access content or in response to a user device exchanging a ticket token for an electronic ticket (see discussion below). An electronic ticket's torn or untorn status can be indicated by a variety of methods including (but not limited to) a field within the ticket or an associated field in a database where the ticket is stored.
An electronic ticket may be expressed in a variety of formats that can store the associated information. One suitable format is Extensible Markup Language (XML) defined in the XML 1.0 Specification by the World Wide Web Consortium (W3C) of Cambridge, Mass. and related specifications. XML specifies a textual data format for documents to be both human-readable and machine-readable.
In many embodiments of the invention, an electronic ticket may contain, reference, or be associated with some characteristics of the purchase it represents. Characteristics can include (but are limited to) the content that was purchased, the license describing how the content can be played (high definition or standard definition, rental or purchase, download or streaming, etc.), the purchase price, the merchant transaction identifier (ID), the customer who purchased the ticket, the customer owning the ticket if the ticket is torn. Cryptographic information that can be used to decode or decrypt the digital content may also be associated with a ticket. The characteristics or cryptographic information may be stored as part of the electronic ticket or the ticket may have a pointer or identifier to where the information may be found.
Ticket Token
A ticket token can be generated and associated with an electronic ticket as a temporary credential, which can be exchanged for an electronic ticket by a user device that is registered with a DRM system. In many embodiments, a merchant server requests a ticket token from a DRM server when a user request playback of content. In several embodiments, the merchant server requests a ticket token from the server when the user purchases content. The request may contain information such as (but not limited to) a content identifier, a merchant identifier, an account link identifier, a license identifier, a stream identifier, a transaction identifier, currency, and/or price. The ticket token that is returned may reference the electronic ticket, customer, and current content request. The first time the user device requests playback, the user device can exchange the ticket token for an electronic ticket. After the user device has obtained the electronic ticket, a further playback request can identify the electronic ticket and a DRM server can issue a ticket token that is used to authenticate that the user device attempting to playback the content is registered to the user account with which the electronic tickets is associated.
In several embodiments, the merchant server provides the ticket token to a user device only after the user device or a user account enabled on the user device is authenticated by the merchant server. The DRM server can issue the ticket token without authenticating the user device. The authentication occurs when the ticket token is used to request playback of the content and/or exchanged for the electronic ticket by a user device. In many embodiments, the DRM server may determine when a session is complete and expire the token, or expire the token after a certain amount of time has passed. Moreover, a token can typically only be used once. Methods for granting access to DRM protected content using electronic tickets and associated ticket tokens in accordance with embodiments of the invention are discussed further below.
Obtaining a Ticket and Ticket Token to Facilitate Playback
Typically a customer will buy or otherwise request access to digital content on a merchant's web site or through some other type of interface that shows the merchant's digital content offerings. The customer may use a personal computer with a web browser application, a user device with an on-screen interface, or other interactive user device to view the merchant's offerings. The customer typically has an account with the merchant and logs in using the account, or first creates a new account if there is no existing account. The purchased content can be viewed in the future (i.e., the associated electronic ticket is untorn) or immediately played back. In several embodiments, the content is streamed and/or viewed while it is being downloaded.
In many embodiments, the process of purchasing and playing back content involves a merchant obtaining a ticket token from a DRM server. A user device that obtains the ticket token can exchange it with the DRM server for an electronic ticket evidencing the user device's right to play back the purchased content and cryptographic information necessary to play back the purchased content. A process 100 for granting user devices with access to digital content purchased via a merchant using an electronic ticket and an associated electronic token in accordance with an embodiment of the invention is shown in
A DRM server authenticates (102) a merchant server. Authentication may involve establishing a certain level of identification and trust between the merchant server and the DRM server and/or the DRM system to which the DRM server belongs.
A user device sends (104) a request for digital content to a merchant server.
The merchant server sends (106) a request for a ticket token to a DRM server. If it is a new purchase, an electronic ticket may not yet exist and the merchant server may also request that a new electronic ticket be created to represent the purchase. In several embodiments of the invention, the request may also include information to be associated with the purchase. The information may include (but is not limited to) a content identifier, merchant link identifier, account link identifier, license identifier, stream identifier, transaction identifier, currency, and/or price.
The DRM server generates (108) a ticket token and associates the token with the electronic ticket that represents the purchase. If it is a new purchase, the DRM server creates a new electronic ticket. If playback is requested of content that was previously purchased and played back by a user device registered to a user's account with the DRM server, the ticket token is associated with the existing electronic ticket. In various embodiments of the invention, the digital content may be transferring via a streaming protocol for immediate viewing or downloaded at a later time to be viewed in a disconnected playback mode (i.e., not in immediate communication with a server). If streamed immediately, the electronic ticket may be “torn” immediately. If the content is to be downloaded at a later time, the electronic ticket may be “untorn” and retain the ability to be transferred to another customer before being “torn” and associated with that customer's account. The electronic ticket may be stored on a user device, deleted from the device when playback is requested, and embedded in a container file with the content for disconnected playback as will be discussed further below.
The DRM server sends (110) the ticket token to the merchant server. If the merchant server does not yet have the electronic ticket (e.g., for a new purchase), the DRM server can also send the electronic ticket. In many embodiments, the merchant server stores the electronic ticket for future reference.
The merchant server sends (112) the ticket token to the user device.
The user device sends (114) the ticket token to the DRM server. In the communication with the DRM server, the user device may also send information about the customer and/or the device that identifies or describes the customer and/or device. For example, the user device may be authenticated with the DRM server. Authentication may include the device identifying itself as registered to a specific user account. The user account may be the same the account the consumer or user device holds with the merchant server, or (more typically) a separate account that the consumer or user device holds with the DRM system to which the DRM server belongs.
In many embodiments of the invention, the device may send information that identifies the brand and model of the device, or the graphics and audio capabilities of the device (e.g., high definition, multi-channel audio, MPEG4 decoding). The information can be used to help authenticate the device to the DRM system and determine the appropriate format of the content to provide to the device. Systems and processes for collecting information about a user device and representing the information using a device match data token include those disclosed in U.S. patent application Ser. No. 13/339,315 entitled “Binding of Cryptographic Content Using Unique Device Characteristics with Server Heuristics,” the disclosure of which is hereby incorporated by reference in its entirety.
The DRM server validates (116) the ticket token, e.g., by checking that the token has not yet been used and is not expired. The DRM server uses the ticket token to determine the electronic ticket to which it refers and customer information for the customer who sent the request.
The DRM server may associate (118) the electronic ticket with the customer's user account and register the user device to the user account if they are not already so registered, using the customer information associated with the ticket token and device match data it may have received from the user device.
In many embodiments of the invention, the DRM server may also verify the play request according to certain rules using the ticket token and/or a device match data token. For example, the DRM server may enforce concurrency and device rules on the playback of content. A concurrency rule may stipulate that only one device on the user account can play back any content at a time, or that a specific piece of content may only be played on one device at a time. Device rules may include limiting high definition content to user devices such as set-top boxes connected to television displays. A device match data token identifies the type of device so the DRM server can look up the device type to determine the appropriate format of content.
In many embodiments of the invention, the electronic ticket and/or the ticket token contain information to identify the license under which the content can be played. The DRM server can use the ticket information to retrieve the license information and generate or retrieve access information that the user device can use to access or decrypt the requested content. Access information can include (but is not limited to) a top level index file of the digital content, an identifier or location pointer for the digital content, and/or cryptographic data that can be used to access and/or decrypt the content. In several embodiments of the invention, a top level index file describes the location and content of container files containing streams of media that can be utilized by the playback device to stream and playback content. In adaptive bitrate streaming systems, the top level index file typically references the alternative streams that the playback device can switch between. Systems and methods for automatically generating top level index files for use in adaptive bitrate stream include those disclosed in U.S. patent application Ser. No. 13/341,789 entitled “Systems and Methods for Automatically Generating Top Level. Index Files,” filed on Dec. 30, 2011, the disclosure of which is hereby incorporated by reference in its entirety.
The DRM server sends (120) the electronic ticket to the user device. In several embodiments, the electronic ticket embedded in another file. The ticket may be embedded in a file that also contains the content that was requested, e.g., in the header of a multimedia container file. In many embodiments, the DRM server also sends the access information that is used to access or play back the content that was requested. The DRM server invalidates the token by expiring (122) it.
Using the received electronic ticket and access information, the user device can play back the requested content via download or streaming. In many embodiments of the invention, the content is hosted on a content server that is accessible to the user device over a network. The user device may request the content from the content server. The content may be downloaded and played (124) during download or after downloading is complete, or streamed and played while being transferred to the user device. The user device may send a signal such as a “heartbeat” to the DRM server to let the server know that it is currently playing back content and/or the position in the file that is being played back. The DRM server can use this information for functions such as providing a resume feature so that the customer can stop playback and restart at the same position on the same or a different user device.
Although a specific process is illustrated in
Processes similar to the process illustrated in
A generalized process 150 for using a DRM server to provide a user device with access to digital content purchased via a merchant using an electronic ticket and an associated electronic token in accordance with an embodiment of the invention is shown in
User Devices
In many embodiments of the invention, an electronic ticket is stored on a playback device to enable the user device to access content through a DRM system using the electronic ticket. A user device configured to access purchased content using electronic tickets in accordance with an embodiment of the invention is shown in
DRM Servers
In many embodiments of the invention, electronic tickets and ticket tokens may be stored on a merchant server or a DRM server (e.g., in a database) for reference, to track purchases, and to provide user devices with access to content. A merchant or DRM server may look up an electronic ticket using fields such as (but not limited to) a customer email address, merchant identifier, content identifier, or merchant transaction identifier. A DRM server configured to issue electronic tickets and ticket tokens and to provide cryptographic information enabling playback of DRM protected content in accordance with an embodiment of the invention is shown in
Although the description above contains many specificities, these should not be construed as limiting the scope of the invention but as merely providing illustrations of some of the presently preferred embodiments of the invention. Various other embodiments are possible within its scope. Accordingly, the scope of the invention should be determined not by the embodiments illustrated, but by the appended claims and their equivalents.
The current application claims priority to U.S. Provisional. Application No. 61/583,807, filed Jan. 6, 2012, the disclosure of which is incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5361332 | Yoshida et al. | Nov 1994 | A |
| 5404436 | Hamilton | Apr 1995 | A |
| 5715403 | Stefik | Feb 1998 | A |
| 6031622 | Ristow et al. | Feb 2000 | A |
| 6141754 | Choy | Oct 2000 | A |
| 6195388 | Choi et al. | Feb 2001 | B1 |
| 6658056 | Duruöz et al. | Dec 2003 | B1 |
| 6807306 | Girgensohn et al. | Oct 2004 | B1 |
| 6859496 | Boroczky et al. | Feb 2005 | B1 |
| 6956901 | Boroczky et al. | Oct 2005 | B2 |
| 7242772 | Tehranchi | Jul 2007 | B1 |
| 7421411 | Kontio et al. | Sep 2008 | B2 |
| 7478325 | Foehr | Jan 2009 | B2 |
| 8023562 | Zheludkov et al. | Sep 2011 | B2 |
| 8046453 | Olaiya | Oct 2011 | B2 |
| 8054880 | Yu et al. | Nov 2011 | B2 |
| 8225061 | Greenebaum | Jul 2012 | B2 |
| 8233768 | Soroushian et al. | Jul 2012 | B2 |
| 8249168 | Graves | Aug 2012 | B2 |
| 8270473 | Chen et al. | Sep 2012 | B2 |
| 8270819 | Vannier | Sep 2012 | B2 |
| 8289338 | Priyadarshi et al. | Oct 2012 | B2 |
| 8311115 | Gu et al. | Nov 2012 | B2 |
| 8321556 | Chatterjee et al. | Nov 2012 | B1 |
| 8386621 | Park | Feb 2013 | B2 |
| 8412841 | Swaminathan et al. | Apr 2013 | B1 |
| 8456380 | Pagan | Jun 2013 | B2 |
| 8472792 | Butt | Jun 2013 | B2 |
| 20030002578 | Tsukagoshi et al. | Jan 2003 | A1 |
| 20030065777 | Mattila et al. | Apr 2003 | A1 |
| 20030152370 | Otomo et al. | Aug 2003 | A1 |
| 20030231863 | Eerenberg et al. | Dec 2003 | A1 |
| 20030231867 | Gates et al. | Dec 2003 | A1 |
| 20030236836 | Borthwick | Dec 2003 | A1 |
| 20030236907 | Stewart et al. | Dec 2003 | A1 |
| 20040039916 | Aldis et al. | Feb 2004 | A1 |
| 20040136698 | Mock | Jul 2004 | A1 |
| 20050038826 | Bae et al. | Feb 2005 | A1 |
| 20050114896 | Hug | May 2005 | A1 |
| 20050149450 | Stefik et al. | Jul 2005 | A1 |
| 20050193070 | Brown et al. | Sep 2005 | A1 |
| 20050193322 | Lamkin et al. | Sep 2005 | A1 |
| 20050204289 | Mohammed et al. | Sep 2005 | A1 |
| 20050207442 | Zoest et al. | Sep 2005 | A1 |
| 20050207578 | Matsuyama et al. | Sep 2005 | A1 |
| 20050273695 | Schnurr | Dec 2005 | A1 |
| 20050275656 | Corbin et al. | Dec 2005 | A1 |
| 20060078301 | Ikeda et al. | Apr 2006 | A1 |
| 20060129909 | Butt et al. | Jun 2006 | A1 |
| 20060173887 | Breitfeld et al. | Aug 2006 | A1 |
| 20060245727 | Nakano et al. | Nov 2006 | A1 |
| 20060259588 | Lerman et al. | Nov 2006 | A1 |
| 20060263056 | Lin et al. | Nov 2006 | A1 |
| 20070031110 | Rijckaert | Feb 2007 | A1 |
| 20070047901 | Ando et al. | Mar 2007 | A1 |
| 20070083617 | Chakrabarti et al. | Apr 2007 | A1 |
| 20070086528 | Mauchly et al. | Apr 2007 | A1 |
| 20070100757 | Rhoads | May 2007 | A1 |
| 20070136817 | Nguyen | Jun 2007 | A1 |
| 20070140647 | Kusunoki et al. | Jun 2007 | A1 |
| 20070154165 | Hemmeryckx-Deleersnijder et al. | Jul 2007 | A1 |
| 20070168541 | Gupta et al. | Jul 2007 | A1 |
| 20070180125 | Knowles et al. | Aug 2007 | A1 |
| 20070185982 | Nakanowatari et al. | Aug 2007 | A1 |
| 20070239839 | Buday et al. | Oct 2007 | A1 |
| 20070292107 | Yahata et al. | Dec 2007 | A1 |
| 20080066181 | Haveson et al. | Mar 2008 | A1 |
| 20080126248 | Lee et al. | May 2008 | A1 |
| 20080137736 | Richardson et al. | Jun 2008 | A1 |
| 20080192818 | DiPietro et al. | Aug 2008 | A1 |
| 20080256105 | Nogawa et al. | Oct 2008 | A1 |
| 20080263354 | Beuque | Oct 2008 | A1 |
| 20080279535 | Haque et al. | Nov 2008 | A1 |
| 20080310496 | Fang | Dec 2008 | A1 |
| 20090031220 | Tranchant et al. | Jan 2009 | A1 |
| 20090060452 | Chaudhri | Mar 2009 | A1 |
| 20090066839 | Jung et al. | Mar 2009 | A1 |
| 20090132599 | Soroushian et al. | May 2009 | A1 |
| 20090132721 | Soroushian et al. | May 2009 | A1 |
| 20090132824 | Terada et al. | May 2009 | A1 |
| 20090150557 | Wormley et al. | Jun 2009 | A1 |
| 20090169181 | Priyadarshi et al. | Jul 2009 | A1 |
| 20090201988 | Gazier et al. | Aug 2009 | A1 |
| 20090226148 | Nesvadba et al. | Sep 2009 | A1 |
| 20090228395 | Wegner et al. | Sep 2009 | A1 |
| 20090293116 | DeMello | Nov 2009 | A1 |
| 20090303241 | Priyadarshi et al. | Dec 2009 | A1 |
| 20090307258 | Priyadarshi et al. | Dec 2009 | A1 |
| 20090307267 | Chen et al. | Dec 2009 | A1 |
| 20090313544 | Wood et al. | Dec 2009 | A1 |
| 20090313564 | Rottler et al. | Dec 2009 | A1 |
| 20090328124 | Khouzam et al. | Dec 2009 | A1 |
| 20100040351 | Toma et al. | Feb 2010 | A1 |
| 20100083322 | Rouse | Apr 2010 | A1 |
| 20100095121 | Shetty et al. | Apr 2010 | A1 |
| 20100111192 | Graves | May 2010 | A1 |
| 20100138903 | Medvinsky | Jun 2010 | A1 |
| 20100158109 | Dahlby et al. | Jun 2010 | A1 |
| 20100189183 | Gu et al. | Jul 2010 | A1 |
| 20100228795 | Hahn | Sep 2010 | A1 |
| 20100235472 | Sood et al. | Sep 2010 | A1 |
| 20110047209 | Lindholm et al. | Feb 2011 | A1 |
| 20110078440 | Feng et al. | Mar 2011 | A1 |
| 20110080940 | Bocharov | Apr 2011 | A1 |
| 20110082924 | Gopalakrishnan | Apr 2011 | A1 |
| 20110126191 | Hughes et al. | May 2011 | A1 |
| 20110142415 | Rhyu | Jun 2011 | A1 |
| 20110150100 | Abadir | Jun 2011 | A1 |
| 20110153785 | Minborg et al. | Jun 2011 | A1 |
| 20110225417 | Maharajh et al. | Sep 2011 | A1 |
| 20110239078 | Luby et al. | Sep 2011 | A1 |
| 20110246659 | Bouazizi | Oct 2011 | A1 |
| 20110268178 | Park | Nov 2011 | A1 |
| 20110302319 | Ha et al. | Dec 2011 | A1 |
| 20110305273 | He et al. | Dec 2011 | A1 |
| 20110314176 | Frojdh et al. | Dec 2011 | A1 |
| 20120023251 | Pyle et al. | Jan 2012 | A1 |
| 20120093214 | Urbach | Apr 2012 | A1 |
| 20120170642 | Braness et al. | Jul 2012 | A1 |
| 20120170643 | Soroushian et al. | Jul 2012 | A1 |
| 20120170906 | Soroushian et al. | Jul 2012 | A1 |
| 20120170915 | Braness et al. | Jul 2012 | A1 |
| 20120173751 | Braness et al. | Jul 2012 | A1 |
| 20120265562 | Daouk et al. | Oct 2012 | A1 |
| 20120278496 | Hsu | Nov 2012 | A1 |
| 20120307883 | Graves | Dec 2012 | A1 |
| 20130044821 | Braness et al. | Feb 2013 | A1 |
| 20130046902 | Villegas Nuñez et al. | Feb 2013 | A1 |
| 20130054958 | Braness et al. | Feb 2013 | A1 |
| 20130061045 | Kiefer et al. | Mar 2013 | A1 |
| 20130166906 | Swaminathan et al. | Jun 2013 | A1 |
| 20130179199 | Ziskind et al. | Jul 2013 | A1 |
| 20130226635 | Fisher | Aug 2013 | A1 |
| 20140101722 | Moore | Apr 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| 813167 | Dec 1997 | EP |
| 2004102571 | Nov 2004 | WO |
| 2009065137 | May 2009 | WO |
| 2010060106 | May 2010 | WO |
| 2010122447 | Oct 2010 | WO |
| 2012094171 | Jul 2012 | WO |
| 2012094181 | Jul 2012 | WO |
| 2012094189 | Jul 2012 | WO |
| 2013103986 | Jul 2013 | WO |
| Entry |
|---|
| International Search Report and Written Opinion for PCT/US2013/020572, International Filing Date Jan. 7, 2013, Search Completed Mar. 19, 2013, Mailed Apr. 29, 2013, 10 pgs. |
| “Widevine Content Protection.” Ooyala Support Center for Developers. Ooyala, Inc., 2013 (Retrieved on Jun. 3, 2013). http://support.ooyala.com/developers/documentation/concepts/player—v3—widevine—integration.html. |
| “IBM Closes Cryptolopes Unit,” Dec. 17, 2007, CNET News, Retrieved from http://news.cnet.com/IBM-closes-Cryptolopes-unit/2100-1001—3206465.html, 3 pgs. |
| Michael, Nelson, “IBM's Cryptolopes,” Complex Objects in Digital Libraries Course, Spring 2001, Retrieved from http://www.cs.odu.edu/˜mln/teaching/unc/inls210/?method=display&pkg—name=cryptolopes.pkg&element—name=cryptolopes.ppt, 12 pgs. |
| “IBM Spearheading Intellectual Property Protection Technology for Information on the Internet; Cryptolope Containers Have Arrived”, May 1, 1996, Business Wire, Retrieved from http://www.thefreelibrary.com/IBM+Spearheading+Intellectual+Property+Protection+Technology+for...-a018239381, 1pg. |
| International Search Report and Written Opinion for International Application No. PCT/US2011/067243, International Filing Date Dec. 23, 2011, Search Completed Apr. 24, 2012, Mailed May 8, 2012, 8 pages. |
| International Search Report and Written Opinion for International Application PCT/US2011/067167, International Filing Date Dec. 23, 2011, Report Completed Jun. 19, 2012, Mailed Jul. 2, 2012, 11 pages. |
| International Search Report and Written Opinion for International Application PCT/US2011/066927, International Filing Date Dec. 22, 2011, Report Completed Apr. 3, 2012, Mailed Apr. 20, 2012, 14 pages. |
| “Adaptive Streaming Comparison”, Jan. 28, 2010, 5 pages. |
| “Best Practices for Multi-Device Transcoding”, Kaltura Open Source Video, 13 pages. |
| European Search Report for Application 11855237.1, Report Completed Jun. 12, 2014, Mailed Jun. 25, 2014, 9 pgs. |
| “Informationweek: Front End: Daily Dose, Internet on Wheels”, Jul. 20, 1999, 3 pages. |
| “Netflix turns on subtitles for PC, Mac streaming”, 3 pages. |
| “Supported Media Formats”, Supported Media Formats, Android Developers, Nov. 27, 2013, 3 pages. |
| “Thread: SSME (Smooth Streaming Medial Element) config.xml review (Smooth Streaming Client configuration file)”, 3 pages. |
| “Transcoding Best Practices”, From movideo, Nov. 27, 2013, 5 pages. |
| “Using HTTP Live Streaming”, iOS Developer Library, Retrieved from: http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html#//apple—ref/doc/uid/TP40008332-CH102-SW1, 10 pgs. |
| Akhshabi et al., “An Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP”, MMSys'11, Feb. 24-25, 2011, 12 pages. |
| Anonymous, “Method for the encoding of a compressed video sequence derived from the same video sequence compressed at a different bit rate without loss of data”, ip.com, ip.com No. IPCOM000008165D, May 22, 2012, pp. 1-9. |
| Author Unknown, “Tunneling QuickTime RTSP and RTP over HTTP”, Published by Apple Computer, Inc.: 1999 (month unknown), 6 pages. |
| Deutscher, “IIS Transform Manager Beta—Using the MP4 to Smooth Task”, Retrieved from: https://web.archive.org/web/20130328111303/http://blog.johndeutscher.com/category/smooth-streaming, Blog post of Apr. 17, 2010, 14 pages. |
| Gannes, “The Lowdown on Apple's HTTP Adaptive Bitrate Streaming”, GigaOM, Jun. 10, 2009, 12 pages. |
| Ghosh, “Enhancing Silverlight Video Experiences with Contextual Data”, Retrieved from: http://msdn.microsoft.com/en-us/magazine/ee336025.aspx, 15 pages. |
| Inlet Technologies, “Adaptive Delivery to iDevices”, 2 pages. |
| Inlet Technologies, “Adaptive delivery to iPhone 3.0”, 2 pages. |
| Inlet Technologies, “HTTP versus RTMP”, 3 pages. |
| Inlet Technologies, “The World's First Live Smooth Streaming Event: The French Open”, 2 pages. |
| Kim, Kyuheon, “MPEG-2 ES/PES/TS/PSI”, Kyung-Hee University, Oct. 4, 2010, 66 pages. |
| Kurzke et al., “Get Your Content Onto Google TV”, Google, Retrieved from: http://commondatastorage.googleapis.com/io2012/presentations/live%20to%20website/1300.pdf, 58 pgs. |
| Lang, “Expression Encoder, Best Practices for live smooth streaming broadcasting”, Microsoft Corporation, 20 pages. |
| Levkov, “Mobile Encoding Guidelines for Android Powered Devices”, Adobe Systems Inc., Addendum B, source and date unknown, 42 pages. |
| MSDN, “Adaptive streaming, Expression Studio 2.0”, 2 pages. |
| Nelson, “Smooth Streaming Deployment Guide”, Microsoft Expression Encoder, Aug. 2010, 66 pages. |
| Noé, Alexander, “Matroska File Format (under construction !)”, Internet Citation, Jun. 24, 2007, pp. 1-51, XP002617671, Retrieved from the Internet: URL:http://web.archive.org/web/20070821155146/www.matroska.org/technical/specs/matroska.pdf, Retrieved on Jan. 19, 2011. |
| Ozer, “The 2012 Encoding and Transcoding Buyers' Guide”, Streamingmedia.com, Retrieved from: http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-2012-Encoding-and-Transcoding-Buyers-Guide-84210.aspx, 2012, 8 pages. |
| Pantos, “HTTP Live Streaming, draft-pantos-http-live-streaming-10”, IETF Tools, Oct. 15, 2012, Retrieved from: http://tools.ietf.org/html/draft-pantos-http-live-streaming-10, 37 pages. |
| Pantos, “HTTP Live Streaming: draft-pantos-http-live-streaming-06”, Published by the Internet Engineering Task Force (IETF), Mar. 31, 2011, 24 pages. |
| RGB Networks, “Comparing Adaptive HTTP Streaming Technologies”, Nov. 2011, Retrieved from: http://btreport.net/wp-content/uploads/2012/02/RGB-Adaptive-HTTP-Streaming-Comparison-1211-01.pdf, 20 pages. |
| Schulzrinne, H. et al., “Real Time Streaming Protocol 2.0 (RTSP): draft-ietfmmusic-rfc2326bis-27”, MMUSIC Working Group of the Internet Engineering Task Force (IETF), Mar. 9, 2011, 296 pages. |
| Siglin, “Unifying Global Video Strategies, MP4 File Fragmentation for Broadcast, Mobile and Web Delivery”, Nov. 16, 2011, 16 pages. |
| Wu, Feng et al., “Next Generation Mobile Multimedia Communications: Media Codec and Media Transport Perspectives”, In China Communications, Oct. 2006, pp. 30-44. |
| Zambelli, Alex, “IIS Smooth Streaming Technical Overview”, Microsoft Corporation, Mar. 2009. |
| Number | Date | Country | |
|---|---|---|---|
| 20130179992 A1 | Jul 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61583807 | Jan 2012 | US |
