`
`(19) World Intellectual Property Organization
`International Bureau
`
`
`
`11111111111111111101111IIII10111111111111111111111111111111111111110111111
`
`(43) International Publication Date
`22 November 2001 (22.11.2001)
`
`PCT
`
`(10) International Publication Number
`WO 01/89195 A2
`
`(51) International Patent Classification':
`
`HO4N
`
`(21) International Application Number: PCT/US01/15661
`
`240 Ackerman Avenue, Ridgewood, NJ 07450 (US). MU-
`RAT, Altay; 104-13 89th Avenue, Richmond Hill, NY
`11418 (US).
`
`(22) International Filing Date:
`
`15 May 2001 (15.05.2001)
`
`(25) Filing Language:
`
`(26) Publication Language:
`
`English
`
`English
`
`(30) Priority Data:
`60/204,386
`
`15 May 2000 (15.05.2000) US
`
`(71) Applicant: SORCERON, INC [US/US]; 459 West 15th
`Street, Suite 6 East, New York, NY 10011 (US).
`
`(74) Agent: OSTROW, Seth, H.; Brown Raysman Millstein
`Felder & Steiner, LLP, 900 Third Avenue, New York, NY
`10022-4728 (US).
`
`(81) Designated States (national): AE, AG, AL, AM, AT, AU,
`AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU,
`CZ, DE, DK, DM, DZ, EE, ES, FL GB, GD, GE, GH, GM,
`fIR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK,
`LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX,
`MZ, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL,
`TJ, TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW.
`
`(72) Inventors: MCTERNAN, Brennan; 135 North Martine
`Avenue, Fanwood, NJ 07023 (US). NEMITOFF, Adam;
`
`(84) Designated States (regional): ARIPO patent (GH, GM,
`KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian
`patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European
`
`[Continued on next page]
`
`(57) Abstract: A system and method
`for the secure delivery of rich media
`resources across a computer network
`having a plurality of servers connectable
`to one or more clients. Client devices are
`configured to request and receive rich
`media resources form a show server and
`decryption keys from a security server.
`The show server receives a request for
`rich media resources from a client device
`and delivers them to the requesting
`client, preferably in an encrypted from.
`The security server responds to the
`request for decryption keys and transmits
`keys
`that are operative
`to decrypt
`the rich media resources received by
`the client device. Upon receipt of
`the decryption keys,
`the rich media
`resources are decrypted and played back
`on the client device using media player
`software. During the playback of the
`received rich media resources, heartbeat
`packets are generated indicating that
`the client is playing back the received
`rich media resources. Heartbeat packets
`are aggregated and analyzed across
`all clients connected to the network
`for receipt and playback of rich media
`resources,
`thereby
`establishing
`a
`mechanism that allows precise show
`viewership measurements to be made.
`
`(54) Title: SYSTEM AND METHOD FOR SECURE DELIVERY OF RICH MEDIA
`
`(-- 116
`
`114
`
`- 112
`
`Accounts
`Receivable
`
`Data
`Base
`
`CS
`
`Security Server
`
`Encryption
`Module
`
`110
`
`Key
`Manager
`
`-
`
`ma
`
`110b
`
`107a--
`
`104
`
`1076 —
`
`Multicast
`Router
`
`107
`
`103a
`
`103b
`
`Show
`Integrator
`
`Media Player
`
`Show Server
`Guide
`
`Web Server
`
`103c
`
`108 --
`
`Multicast-in Multicast-
`n unicast-
`unicast-out
`TCP-out
`Proxy
`Proxy
`
`Table of I_
`Contents
`
`Show Server
`
`106a
`
`106 -
`
`108a
`
`108b
`
`Connection Manager
`
`Resource Registry
`Client
`
`Producer
`
`102
`
`102a
`
`100 —
`
`WO 01/89195 A2
`
`IPR2020-00677
`Vudu Ex. 1007, Page 1
`
`
`
`WO 01/89195 A2
`
`IIIIIIIHII11IIIIIIIIII111IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII1111111IIIIIi1111
`
`patent (AT, BE, CH, CY, DE, DK, ES, H, FR, GB, GR, IE, For two-letter codes and other abbreviations, refer to the "Guid-
`ance Notes on Codes and Abbreviations" appearing at the begin-
`IT, LU, MC, NL, PT, SE, TR), OAPI patent (BF, BJ, CF,
`ning of each regular issue of the PCT Gazette.
`CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG).
`
`Published:
`
` without international search report and to be republished
`upon receipt of that report
`
`IPR2020-00677
`Vudu Ex. 1007, Page 2
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`SYSTEM AND METHOD FOR SECURE DELIVERY OF RICH MEDIA
`
`Applicant(s) hereby claims the benefit of provisional patent application serial no.
`
`60/204,386, titled "AUTOMATIC IPSEC TUNNEL ADMINISTRATION," filed May 15, 2000,
`
`5
`
`attorney docket no. 38903-014. The application is incorporated by reference herein in its
`
`entirety.
`
`COPYRIGHT NOTICE
`
`A portion of the disclosure of this patent document contains material which is
`
`subject to copyright protection. The copyright owner has no objection to the facsimile
`
`10
`
`reproduction by anyone of the patent document or the patent disclosure, as it appears in the
`
`Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights
`
`whatsoever.
`
`RELATED APPLICATIONS
`
`This application is related to the following commonly owned patent applications,
`
`15
`
`each of which applications are hereby incorporated by reference herein in their entirety:
`
`•
`
`application serial no. 09/767,672, titled "METHOD AND SYSTEM FOR
`
`DISTRIBUTING VIDEO USING A VIRTUAL SET," attorney docket no. 4700/2;
`
`•
`
`application serial no. 09/767,268, titled "SYSTEM AND METHOD FOR
`
`ACCOUNTING FOR VARIATIONS IN CLIENT CAPABILITIES IN THE
`
`20
`
`DISTRIBUTION OF A MEDIA PRESENTATION," attorney docket no. 4700/4;
`
`•
`
`application serial no. 09/767,603, titled "SYSTEM AND METHOD FOR USING
`
`BENCHMARKING TO ACCOUNT FOR VARIATIONS IN CLIENT
`
`1
`
`IPR2020-00677
`Vudu Ex. 1007, Page 3
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`CAPABILITIES IN THE DISTRIBUTION OF A MEDIA PRESENTATION,"
`
`attorney docket no. 4700/5;
`
`•
`
`application serial no. 09/767,602, titled "SYSTEM AND METHOD FOR
`
`MANAGING CONNECTIONS TO SERVERS DELIVERING MULTIMEDIA
`
`5
`
`CONTENT," attorney docket no. 4700/6;
`
`•
`
`application serial no. 09/767,604, titled "SYSTEM AND METHOD FOR
`
`RECEIVING PACKET DATA MULTICAST IN SEQUENTIAL LOOPING
`
`FASHION," attorney docket no. 4700/7; and
`
`•
`
`application serial no. 09/767,607, titled "SYSETM AND METHOD FOR
`
`10
`
`DISTRIBUTING CAPTURED MOTION DATA OVER A NETWORK," attorney
`
`docket no. 4700/8.
`
`BACKGROUND OF THE INVENTION
`
`The invention disclosed herein relates generally to techniques for distributing
`
`interactive multimedia content across computer networks. More particularly, the present
`
`15
`
`invention relates to a system and method for seamlessly and securely distributing rich media
`
`among a plurality of clients, thereby allowing creators of rich media to retain control over
`
`distribution and playback of their content.
`
`Over the past decade, processing power available to both producers and
`
`consumers of multimedia content has increased exponentially. Approximately a decade ago, the
`
`20
`
`transient and persistent memory available to personal computers was measured in kilobytes (8
`
`bits = 1 byte, 1024 bytes = 1 kilobyte) and processing speed was typically in the range of 2 to 16
`
`megahertz. Due to the high cost of personal computers, many institutions opted to utilize
`
`2
`
`IPR2020-00677
`Vudu Ex. 1007, Page 4
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`"dumb" terminals, which lack all but the most rudimentary processing power, connected to large
`
`and prohibitively expensive mainframe computers that "simultaneously" distributed the use of
`
`their processing cycles with multiple clients.
`
`Today, transient and persistent memory is typically measured in megabytes and
`
`5
`
`gigabytes, respectively (1,048,576 bytes =1 megabyte, 1,073,741,824 bytes =1 gigabyte).
`
`Processor speeds have similarly increased, modem processors based on the x86 instruction set
`
`are available at speeds up to 1.5 gigahertz (approximately 1000 megahertz = 1 gigahertz).
`
`Indeed, processing and storage capacity have increased to the point where personal computers,
`
`configured with minimal hardware and software modifications, fulfill roles such as data
`
`10 warehousing, serving, and transformation, tasks that in the past were typically reserved for
`
`mainframe computers. Perhaps most importantly, as the power of personal computers has
`
`increased, the average cost of ownership has fallen dramatically, providing significant computing
`
`power to average consumers.
`
`The past decade has also seen the widespread proliferation of computer networks.
`
`15 With the development of the Internet in the late 1960's followed by a series of inventions in the
`
`fields of networking hardware and software, the foundation was set for the rise of networked and
`
`distributed computing. Once personal computing power advanced to the point where relatively
`
`high speed data communication became available from the desktop, a domino effect was set in
`
`motion whereby consumers demanded increased network services, which in turn spurred the
`
`20
`
`need for more powerful personal computing devices. This also stimulated the industry for
`
`Internet Service providers or ISPs, which provide network services to consumers.
`
`Computer networks transfer data according to a variety of protocols, such as UDP
`
`(User Datagram Protocol) and TCP (Transport Control Protocol). According to the UDP
`
`3
`
`IPR2020-00677
`Vudu Ex. 1007, Page 5
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`protocol, the sending computer collects data into an array of memory referred to as a packet. IP
`
`address and port information is added to the head of the packet. The address is a numeric
`
`identifier that uniquely identifies a computer that is the intended recipient of the packet. A port
`
`is a numeric identifier that uniquely identifies a communications connection on the recipient
`
`5
`
`device.
`
`Once the data packet is addressed, it is transmitted from the sending device across
`
`a network via a hardware network adapter, where intermediary computers (e.g., routers) relay the
`
`packet to the appropriate port on the device with the appropriate unique IP address. When data is
`
`transmitted according to the UDP protocol, however, no attempt is made to inform the sender
`
`10
`
`that the data has successfully arrived at the destination device. Moreover, there is neither
`
`feedback from the recipient regarding the quality of the transmission nor any guarantee that
`
`subsequent data sent out sequentially by the transmitting device is received in the same sequence
`
`by the recipient.
`
`According to the Transmission Control Protocol, or TCP, data is sent using UDP
`
`15
`
`packets, but there is an underlying "handshake" between sender and recipient that ensures a
`
`suitable communications connection is available. Furthermore, additional data is added to each
`
`packet identifying its order in an overall transmission. After each packet is received, the
`
`receiving device transmits acknowledgment of the receipt to the sending device. This allows the
`
`sender to verify that each byte of data sent has been received, in the order it was sent, to the
`
`20
`
`receiving device. Both the UDP and TCP protocols have their uses. For most purposes, the use
`
`of one protocol over the other is determined by the temporal nature of the data. Data can be
`
`viewed as being divided into two types, transient or persistent, based on the amount of time that
`
`the data is useful.
`
`4
`
`IPR2020-00677
`Vudu Ex. 1007, Page 6
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`Transient data is data that is useful for relatively short periods of time. For
`
`example, a television transmits a video signal consisting of 30 frames of imagery each second.
`
`Thus, each frame is useful for 1130th of a second. For most applications, the loss of one frame
`
`would not diminish the utility of the overall stream of images. Persistent data, by contrast, is
`
`5
`
`useful for much longer periods of time and must typically be transmitted completely and without
`
`errors. For example, a downloaded record of a bank transaction is a permanent change in the
`
`status of the account and is necessary to compute the overall account balance. Losing a bank
`
`transaction or receiving a record of a transaction containing errors would have harmful side
`
`effects, such as inaccurately calculating the total balance of the account.
`
`10
`
`UDP is useful for the transmission of transient data, where the sender does not
`
`need to be delayed verifying the receipt of each packet of data. In the above example, a
`
`television broadcaster would incur an enormous amount of overhead if it were required to verify
`
`that each frame of video transmitted has been successfully received by each of the millions of
`
`televisions tuned into the signal. Indeed, it is inconsequential to the individual television viewer
`
`15
`
`that one or even a handful of frames have been dropped out of an entire transmission. TCP,
`
`conversely, is useful for the transmission of persistent data where the failure to receive every
`
`packet transmitted is of great consequence.
`
`One of the reasons that the Internet is a successful medium for transmitting data is
`
`because the storage of information regarding identity and location of devices connected to it is
`
`20
`
`decentralized. Knowledge regarding where a device resides on a particular part of the network is
`
`distributed over a plurality of sources across the world. A connection between two remotely
`
`located devices can traverse a variety of paths such that if one path becomes unavailable, another
`
`route is utilized.
`
`5
`
`IPR2020-00677
`Vudu Ex. 1007, Page 7
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`Each network on the Internet is uniquely identified with a numeric address. Each
`
`device within a network, in turn, is identified by an IP address that is comprised of a subnet
`
`address coupled with a unique device ID. According to version four of this standard ("IPv4") an
`
`IP address is a '32-bit number that is represented by four "dot" separated values in the range from
`
`5
`
`0 through 255, e.g., 123.32.65.72. Each device is further configured with a subnet mask. The
`
`mask determines which bits of a device's IP address represent the subnet and which represent the
`
`device's ID. For example, a device with an IP address of 123.32.65.72 and a subnet mask of
`
`255.255.255.0 has a subnet address of 123.32.65 and an ID of 72.
`
`Each packet of data sent by a device, whether it is formatted according to the UDP
`
`10
`
`or TCP protocols, has a header data field. The header is an array of bytes at the beginning of a
`
`packet that describe the data's destination, its origin, its size, etc. When a sender and recipient
`
`are both located within the same subnet, the recipient device's network hardware examines
`
`network traffic for packets tagged with its address. When a packet addressed to the recipient is
`
`identified, the network hardware passes the received data off to the operating system's network
`
`15
`
`services software for processing.
`
`When a sender and recipient are located in different subnets, data is relayed from
`
`the originating subnet to the destination subnet primarily through the use of routers. While other
`
`physical transport methodologies are available, e.g., circuit switched transmission systems such
`
`as ATM (Asynchronous Transfer Mode), the majority of computer networks utilize packet
`
`20
`
`switched hardware such as routers. A router is a device that interconnects two networks and
`
`contains multiple network hardware connections. Each network connection is associated with,
`
`and provides a connection to, a distinct subnet.
`
`6
`
`IPR2020-00677
`Vudu Ex. 1007, Page 8
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`Two tasks are performed when a packet, destined for a subnet that is different
`
`from the subnet it is currently in, reaches a router within the current subnet. First, the router
`
`examines the subnets that it is connected to via its network hardware. If the router is connected
`
`to the packet's destination subnet, it forwards the packet to the router in the appropriate subnet.
`
`5
`
`If the router is not directly connected to the packet's destination subnet, it queries other routers
`
`available on its existing connections to determine if any of them are directly connected to the
`
`destination subnet. When a router directly connected to the destination subnet is discovered, the
`
`packet is forwarded to it. Where a router connected to the destination subnet is not found,
`
`however, the router propagates the packet to a top level router that is strategically placed to allow
`
`10
`
`access, either directly or through other top level routers, to the entire Internet. A registration
`
`authority under government oversight currently maintains these top-level routers.
`
`The transmission method described above is referred to as the unicast method of
`
`transmission, whereby a sender establishes a unique connection with each recipient. By utilizing
`
`a unicast model, the specific address of the receiving machine is placed in the packet header.
`
`15 Routers detect this address and forward the packet so that it ultimately reaches its intended
`
`recipient. This method, however, is not the most efficient means for distributing information
`
`simultaneously to multiple recipients. The transmission method that best facilitates broadcasting
`
`to many recipients simultaneously is multicasting.
`
`Multicasting relies on the use of specialized routers referred to as multicast
`
`20
`
`routers. These routers look only for data packets addressed to devices in the range of 224.0.0.0
`
`through 239.255.255.255. This address range is specifically set aside for the purpose of
`
`facilitating multicast transmissions. Recipients wishing to receive multicast packets watch for a
`
`specific IP address and port within the multicast address space.
`
`7
`
`IPR2020-00677
`Vudu Ex. 1007, Page 9
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`Under the multicast model, the sender transmits packets to a single address, as
`
`opposed to the unicast model where the data is transmitted individually to each subscribing
`
`recipient. The multicast routers handle replication and distribution of packets to each subscribing
`
`client. The multicast model, like the broadcast model, can be conceptually viewed as a "one-to-
`
`5 many" connection and, therefore, must use the UDP protocol. UDP must be utilized because the
`
`TCP protocol requires a dialog between the sender and receiver that is not present in a multicast
`
`environment.
`
`As previously described, Internet Service Providers or ISPs, provide connections
`
`between local networks and the Internet. A router is used to connect the customer's local
`
`10
`
`network to the ISP and forwards data packets not addressed to devices within the local network
`
`to the ISP for relay across the Internet to the packet's intended recipient. There are no
`
`regulations, however, regarding the types of routers supported by ISPs and many of them do not
`
`incur the cost of providing and maintaining multicast routers. Because of this limitation, not all
`
`systems can subscribe to multicast addresses.
`
`15
`
`Many ISPs restrict the transmission of UDP packets across their networks. Since
`
`these packets do not require a persistent link between sender and receiver, they are referred to as
`
`anonymous packets. Security issues involved with this anonymity is the reason for restrictions
`
`on the transmission of these packets, which has the twofold effect of restricting the use of UDP
`
`packets and preventing users from subscribing to multicast services.
`
`20
`
`There is thus a need for a system and method that allows users to receive the
`
`secure delivery of rich media resources irrespective of the means of communication while
`
`ensuring that resource producers a compensated for the use of their property. Strategies are
`
`8
`
`IPR2020-00677
`Vudu Ex. 1007, Page 10
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`required to identify individual users and the amount of resources they utilize to more equitably
`
`account and compensate for system usage.
`
`BRIEF SUMMARY OF THE INVENTION
`
`It is an object of the present invention to solve the problems described above
`
`5
`
`relating to existing content delivery systems.
`
`It is another object of the present invention to provide a secure mechanism for the
`
`delivery, of rich media content that ensures content owners are compensated for content usage.
`
`It is another object of the present invention to provide a secure mechanism for the
`
`delivery of rich media resources that ensures content availability.
`
`10
`
`It is another object of the present invention to more effectively track the use of
`
`content by consumers.
`
`The above and other objects are achieved by a computer-implemented method for
`
`receiving a securely distributed show comprising a plurality of rich media resources over a
`
`computerized network operative to connect a plurality of clients and servers. The method
`
`15
`
`involves retrieving the rich media resources in an encrypted format. Each of the encrypted
`
`resources is tagged with a unique resource identifier. The decryption keys corresponding to the
`
`unique resource ids of the encrypted rich media resources are identified and retrieved from a
`
`Security Server along with a unique session identifier. The rich media resources are decrypted
`
`with the retrieved decryption keys and played to the end user as a show by presenting the
`
`20
`
`retrieved and decrypted rich media resources.
`
`Heartbeat data packets may be generated at regular intervals while the end user is
`
`playing the show. These heartbeat data packets are used to calculate the total time that a user is
`
`watching a show, which is useful in generating billing statistics. The heartbeat data packets are
`
`9
`
`IPR2020-00677
`Vudu Ex. 1007, Page 11
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`tagged with the session identifier and transmitted to a Security Server for aggregation and
`
`indexing by session id. The aggregated heartbeat data is transmitted by a plurality of security
`
`servers to a Central Server to generate payment information. The method may also comprise
`
`downloading a media player to facilitate playback of the retrieved show, the media player being
`
`5
`
`identified by a unique player identifier. The user performing the download operation can provide
`
`demographic data, which is associated with the unique identifier of the player being downloaded
`
`and aggregated across a plurality of users.
`
`The above and other objects are also achieved by a computer-implemented
`
`method for providing the secure distribution of a show comprising a plurality of rich media
`
`10
`
`resources over a computerized network operative to connect a plurality of clients and server. The
`
`method involves receiving each rich media resource comprising the show at a Security Server,
`
`each of the resources identified by a unique resource identifier. A plurality of
`
`encryption/decryption keys are generated, one for each rich media resource, which is used to
`
`encrypt the resources. A plurality of records is also generated to associate each encrypted rich
`
`15 media resource with the appropriate decryption key. The decryption keys and records are sent to
`
`a central server to distribution to other Security Server located throughout the network. A check
`
`may also be performed at the Security Server to determine if the received resource was
`
`previously encrypted. If the check determines that a resource was previously encrypted, it is not
`
`subsequently encrypt multiple times. Instead, the previously encrypted resource is utilized.
`
`20
`
`The above and other objects are achieved by a computer-implemented system for
`
`providing for the secure distribution of a show comprising a plurality of rich media resources
`
`over a computerized network operative to connect a plurality of clients and servers. A Security
`
`Server is used to the unique resource id of rich media resources, and handle key requests from
`
`10
`
`IPR2020-00677
`Vudu Ex. 1007, Page 12
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`clients. The Security Server's encryption system generates encryption/decryption keys, one pair
`
`for each resource. A separate encryption key is used to encrypt each resource. A Key Manager
`
`creates a record for each resource encrypted to associate each decryption key with the encrypted
`
`rich media resource that it is capable of decoding. A Show Server is provided to supply rich
`
`5 media resources to the Security Server for encryption, to manage the encrypted rich media
`
`resources, and to respond to client requests for rich media resources.
`
`The system may also comprise a web server configured to serve media player
`
`software to a requesting client and further configured to collect and aggregate demographic data
`
`regarding clients. The web server may further comprise show server guides containing addresses
`
`10
`
`of Show Servers thereby allowing clients to locate resources located thereon. A Central Server is
`
`provided to collect the aggregated demographic data from a plurality of web server. The system
`
`may comprise a media player operative to retrieve a show comprising a plurality of rich media
`
`resources from the Show Server and issue requests to the Security Server for decryption keys
`
`corresponding to the unique ids of the rich media resources comprising the show. The media
`
`15
`
`player comprises functionality that allows it to generate heartbeat data packets for broadcast
`
`across the network. These heartbeat data packets are aggregated at the Security Server across a
`
`plurality of media players. A Central Server collects heartbeat data form Security Servers
`
`attached to the network to create usage statistics regarding all media players in use.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`20
`
`The invention is illustrated in the figures of the accompanying drawings, which
`
`are meant to be exemplary and not limiting, in which like references are intended to refer to like
`
`or corresponding parts, and in which:
`
`11
`
`IPR2020-00677
`Vudu Ex. 1007, Page 13
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`Fig. 1 is a block diagram presenting a configuration of hardware components
`
`according to one embodiment of the present invention;
`
`Fig. 2 is a flow diagram presenting the process of generating and uploading rich
`
`media to a server for receipt and playback by client devices according to one embodiment of the
`
`5
`
`present invention;
`
`Fig. 3 is a flow diagram presenting the process downloading rich media for
`
`playback on a client device according to one embodiment of the present invention; and
`
`Fig. 4 is a flow diagram presenting the process of playing received rich media on
`
`a client device according to one embodiment of the present invention.
`
`10
`
`DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
`
`Preferred embodiments of the present invention are now described with reference
`
`to the drawings in the figures. With reference to Fig. 1, one configuration of a system in
`
`accordance with the present invention includes various hardware components, including client
`
`devices 108, media producers 102, web servers 104, show servers 106, security servers 110,
`
`15
`
`central servers 112, and routers 107a-107c. Users access rich media through the use of client
`
`devices 108. Client devices 108 may be any general purpose computing devices with the
`
`capacity to access a data network 100 including, but not limited to, personal computers, wireless
`
`computing devices, and personal digital assistants. The data network 100 may be any type of
`
`computerized network capable of carrying data, such as the Internet, Intranets, LANs, WANs,
`
`20
`
`etc. Moreover, the data network may be comprised of a plurality of disparate networks and
`
`network types.
`
`Producers 102 create rich media presentations by assembling show resources
`
`using the Show Integrator 103a. The Show Integrator is a stand-alone GUI application that is
`
`12
`
`IPR2020-00677
`Vudu Ex. 1007, Page 14
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`retrieved from the Web Server 104, using HTTP, FTP, or any other suitable data transfer
`
`protocol. The producer 102 selects rich media elements that comprise the show and arrange
`
`them graphically within a scene, which are sequenced over time (interaction data). The Show
`
`Integrator GUI 103a gives the producer 102 flexibility in viewing the scene, allowing it to be
`
`5
`
`viewed along an animation timeline, as a two dimensional representation of one possible client
`
`configuration, or as multiple client configurations simultaneously. These functions are described
`
`further in commonly owned patent application serial no. PCT/US01/02224, titled "SYSTEM
`
`AND METHOD FOR DELIVERING RICH MEDIA CONTENT OVER A NETWORK," which
`
`has been incorporated by reference herein.
`
`10
`
`A Producer 102 uses the Show Integrator 103a to assemble one or more scenes
`
`into a show. The show is then packaged as an ".srf' or " Sorceron Release File" file 102a. This
`
`file 102a is a collection of all the resources and data regarding the interaction of these resources
`
`needed by the client 108 to recreate a show. Alternatively, producer 102 may forgo packaging
`
`the resources as a single file and instead use the Show Integrator to create individual resources
`
`15
`
`and data regarding the interaction of these resources. The terms "show", ".srf' and "resources"
`
`will be used interchangeably throughout.
`
`Each resource used in the presentation of a show is tagged with a unique
`
`identifier. Likewise, a show comprising a plurality of resources and interaction data is assigned a
`
`single identifier. The identifier may take any form that allows a client 108 to uniquely identify a
`
`20
`
`desired resource from all other resources being distributed using the present invention. For
`
`example, one method is to use Globally Unique Identifiers ("GUIDs") through third-party
`
`software well known in the art, or another method is to use the address of the producer creating
`
`the resource may be appended to a randomly generated alphanumeric identifier. In this manner,
`
`13
`
`IPR2020-00677
`Vudu Ex. 1007, Page 15
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`no two resources will be tagged with an identical identifier, allowing retrieval of any resource.
`
`The show or resource data is transmitted by the producer 102 to a Show Server 106 for
`
`distribution to requesting clients 108. A table of contents 106a is also provided by the producer
`
`103 to allow clients 108 to identify resources needed to recreate a show that already reside on the
`
`5
`
`client device 108, thereby eliminating the need for duplicative downloads.
`
`The Show Server 106 is configured to manage resources and .srf files 102a
`
`received from Producers 102 and transmit these data to requesting Clients 108. In order to
`
`encrypt a show, the Show Server 106 initiates a communication channel with a Security Server
`
`110. Upon establishing communication with a Security Server 110, the Show Server 106
`
`10
`
`uploads resources or .srf files for encryption. The Security Server 110 employs a public/private
`
`key encryption architecture to encrypt show resources. Public/private key encryption involves
`
`the use of a mathematical algorithm to generate public/private key pairs. Data encrypted by a
`
`private key can only be decrypted with its corresponding public key. As a corollary, the public
`
`key can only be used to successfully decrypt data that has been encrypted by its corresponding
`
`15
`
`private key.
`
`Depending on whether an .srf file or multiple resources are uploaded, the Security
`
`Server 110 uses one or more private keys to encrypt the received data using its encryption
`
`module 110a. The encryption module 110a may be implemented in hardware, software, or a
`
`combination of the two. The encryption module 110a generates one or more public/private key
`
`20
`
`pairs for the received data and proceeds with encryption using the generated private key or keys.
`
`Upon encryption of each resource, a key manager 110b generates a record in its key management
`
`table associating or correlating the newly created public key with the resource identifier for the
`
`resource encrypted with the public key's private key. The key/identifier record is used by the
`
`14
`
`IPR2020-00677
`Vudu Ex. 1007, Page 16
`
`
`
`WO 01/89195
`
`PCT/US01/15661
`
`key manager 110b to allow the retrieval of the public key associated with a specific resource or
`
`show requested by a Client 108. The Security Server 110 returns the encrypted file to the Show
`
`Server 106 initiating the encryption transaction.
`
`The Security Server 110 forwards the key or keys, along with the key/identifier
`
`5
`
`record or records, to the Central Server 112. The Central Server 112 forwards the received keys
`
`and key/identifier records to other Security Servers 110 located throughout the network to
`
`minimize the time necessary to retrieve keys for the de