Low latency active noise cancellation system with client intercommunication

Abstract

A system and method for providing load balanced secure media content and data delivery (10) in a distributed computing environment is disclosed. Media content is segmented and encrypted into a set of individual encrypted segments on a centralized control center (15). Each individual encrypted segment has the same fixed size. The complete set of individual encrypted segments is staged to a plurality of intermediate control nodes (17, 19). Individual encrypted segments are mirrored from the staged complete set to a plurality of intermediate servers (21a-b, 23a-b). Requests are received from clients (11) for the media content at the centralized control center. Each individual encrypted segment in the set is received from one of an intermediate control node and an intermediate server optimally sited from the requesting client. The individual encrypted segments are reassembled into the media content for media playback.

Claims

1. A system for providing load balanced, secure media content delivery in a distributed computing environment, the system comprising: a centralized control center that segments and encrypts media content into a set of individual encrypted segments, each segment being either variable or fixed in size, each segment being a portion of or an entirety of the media content size, the centralized control center including an encryption module stored in memory and executable by a processor to encrypt individual segments with encryption keys; a plurality of intermediate servers that mirror the individual encrypted segments from a staged set of individual encrypted segments; and at least one client computer that: sends requests for the media content to the centralized control center, receives the individual encrypted segments in the set from an intermediate server of the plurality of intermediate servers in communication with the requesting client computer, and reassembles the individual encrypted segments into the media content for media playback, and includes: a broadcasting module stored in memory and executable by a processor to broadcast a pulse prior to receiving individually encrypted segments, and a request processing module stored in memory and executable by the processor to select the intermediate server based on responses to the pulse for subsequent receipt of the individual encrypted segments in the set.

2. The system according to claim 1, further comprising: the plurality of intermediate servers queuing requests from a plurality of client computers; and the centralized control center multicasting the individual encrypted segments to the at least one client computer.

3. The system according to claim 1, in which a codec is executed at each requesting client computer to decode the individual encrypted segments.

4. The system according to claim 1, in which media content delivery is balanced in an intermediate server of the plurality of intermediate servers via the centralized control center.

5. The system according to claim 1, in which media playback is enabled at each requesting client computer prior to receipt of the individual encrypted segments.

6. The system according to claim 1, in which flexible media playback is provided at each requesting client computer comprising functions selected from a group comprising pause, rewind, fast-forward, skip forward, skip backward, chapter stops, and a shuttle bar.

7. The system according to claim 1, in which a pulse is broadcasted from each client computer prior to receiving the individual encrypted segments, and in which the intermediate server is selected based on responses to the pulse.

8. The system according to claim 1, in which the individual encrypted segments from the staged set are mirrored to a plurality of client computers, and the individual encrypted segments are received from one of an intermediate server of the plurality of intermediate servers and a client computer in communication with the requesting client computer.

9. The system according to claim 1, in which individual encrypted segments comprising an initial portion of the media content are staged to a plurality of client computers, and individual encrypted segments comprising a remaining portion of the media content are sent to a plurality of client computers upon request.

10. A method for providing load balanced secure media content delivery in a distributed computing environment, comprising: segmenting and encrypting media content into a set of individual encrypted segments at a centralized control center; mirroring the individual encrypted segments from a staged complete set of the individual encrypted segments to a plurality of intermediate servers; receiving requests from client computers for the media content at the centralized control center; receiving each individual encrypted segment in the set from an intermediate server of the plurality of intermediate servers in communication with the requesting client computer; reassembling the individual encrypted segments into the media content for media playback; queuing requests from a plurality of client computers on at least one intermediate server; and multicasting the individual encrypted segments to the requesting client computers.

11. The method according to claim 10, wherein the encrypting into the individual encrypted segments uses encryption keys.

12. The method according to claim 10, further comprising: executing a codec at each requesting client computer to decode the individual encrypted segments.

13. The method according to claim 10, further comprising: balancing media content delivery in an intermediate server via the centralized control center.

14. The method according to claim 10, further comprising: enabling media playback at each requesting client computer prior to receipt of the individual encrypted segments.

15. The method according to claim 10, further comprising: providing flexible media playback at each requesting client computer comprising functions selected from a group comprising pause, rewind, fast-forward, skip forward, skip backward, chapter stops, and a shuttle bar.

16. The method according to claim 10, further comprising: broadcasting a pulse from each requesting client computer prior to receiving the individual encrypted segments; and selecting the intermediate server based on responses to the pulse.

17. The method according to claim 10, further comprising: mirroring the individual encrypted segments from the staged complete set to a plurality of client computers; and receiving the individual encrypted segments in the set from an intermediate server of the plurality of intermediate servers and a client computer in communication with the requesting client computer.

18. The method according to claim 10, further comprising: staging the individual encrypted segments comprising an initial portion of the media content to a plurality of client computers; and sending the individual encrypted segments comprising a remaining portion of the media content to the plurality of client computers upon request.

19. A system for providing load balanced, secure media content delivery in a distributed computing environment, the system comprising: a centralized control center that segments and encrypts media content into a set of individual encrypted segments, each segment being either variable or fixed in size, each segment being a portion of or an entirety of the media content size, the centralized control center including an encryption module stored in memory and executable by a processor to encrypt individual segments to encryption keys; and at least one client computer that: sends requests for the media content to the centralized control center, receives the individual encrypted segments in the set, and reassembles the individual encrypted segments into the media content for media playback, executes a codec to decode the individual encrypted segments, and includes a broadcasting module stored in memory and executable by a processor to broadcast a pulse prior to receiving the individually encrypted segments.

20. A non-transitory computer-readable storage medium having embodied thereon a program, the program executable by a processing unit to perform a method for providing load balanced secure media content delivery in a distributed computing environment, the method comprising: segmenting and encrypting media content into a set of individual encrypted segments at a centralized control center, each segment being either variable or fixed in size; mirroring the individual encrypted segments from a staged complete set of the individual encrypted segments to a plurality of intermediate servers; receiving requests from one or more client computers for the media content at the centralized control center; receiving each individual encrypted segment in the set from an intermediate server of the plurality of intermediate servers in communication with the one or more requesting client computer; reassembling the individual encrypted segments into the media content for media playback; and executing a codec at each requesting client computer to decode the individual encrypted segments.

21. The non-transitory computer-readable storage medium according to claim 20, further comprising: queuing requests from a plurality of client computers on at least one of one such intermediate server; and multicasting the individual encrypted segments to the one or more client computers.

22. The non-transitory computer-readable storage medium according to claim 20, wherein the encrypting individual encrypted segments uses encryption keys.

Description

DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is a block diagram showing a system for providing load balanced secure media content delivery in a distributed computing environment.

(2) FIG. 2 is a process flow diagram showing load balanced secure media content delivery via the system of FIG. 1.

(3) FIG. 3 is a process flow diagram showing load balanced secure media content delivery with peer-to-peer intercommunication in accordance with a further embodiment.

(4) FIG. 4 is a process flow diagram showing load balanced secure media content delivery with pre-casted media content staging in accordance with a further embodiment.

(5) FIG. 5 is a block diagram showing the software modules of the Neuro Center of FIG. 1.

(6) FIG. 6 is a block diagram showing the software modules of a Neuro Node of FIG. 1.

(7) FIG. 7 is a block diagram showing the software modules of an Edge Server of FIG. 1.

(8) FIG. 8 is a block diagram showing the software modules of a Smart Client of FIG. 1.

(9) FIG. 9 is a data structure diagram showing a play ticket used by the system of FIG. 1.

(10) FIG. 10 is a data structure diagram showing a validation certificate used by the system of FIG. 1.

(11) FIG. 11 is a data structure diagram showing a packet header used by the system of FIG. 1.

(12) FIG. 12 is a flow diagram showing a method for providing load balanced secure media content delivery in a distributed computing environment.

(13) FIG. 13 is a flow diagram showing a routine for performing the operations of the Neuro Center for use in the method of FIG. 12.

(14) FIG. 14 is a flow diagram showing a routine for performing the operations of a Neuro Node for use in the method of FIG. 12.

(15) FIG. 15 is a flow diagram showing a routine for performing the operations of an Edge Server for use in the method of FIG. 12.

(16) FIG. 16 is a flow diagram showing a routine for performing the operations of a Smart Client for use in the method of FIG. 12.

DETAILED DESCRIPTION

(17) FIG. 1 is a block diagram showing a system 10 for providing load balanced secure media content delivery in a distributed computing environment. Media content is delivered as individual encrypted segments to a Smart Client 11 or, alternatively, to a set-top box (STV) 13 for airing on a television set (TV) 14. The Smart Client 11 provides media viewing playback capabilities to personal computers, wireless devices, public display kiosks, and the like. The Smart Client 11 includes a local storage 12 in which the segments are transitorily stored. Henceforth, for clarity of discussion, media content delivery will be described with reference to the Smart Client 11 only, although one skilled in the art would recognize that a similar form of delivery would apply to a set-top box 13 or similar media access device. The Smart Client 11 is further described below with reference to FIG. 8.

(18) The Smart Client 11 initiates the media content delivery process by sending a request to a Neuro Center 15. The Neuro Center 15 centrally manages all requests for media content and is accessible via an internetwork 26, including the Internet, or similar broadband wide area network. The Smart Client 11 interfaces to the internetwork 26 through an Internet Service Provider 25 (ISP) or via direct connection (not shown). The Neuro Center 15 maintains a master database 16 in which individual users are profiled and e-commerce and e-business management data are maintained. Upon validating each client request, the Neuro Center 15 requests the Smart Client 11 to check the network and commence media content delivery. The Neuro Center 15 is further described below with reference to FIG. 5.

(19) The actual media content is stored as individual encrypted segments on Neuro Nodes 17 and 19 and Edge Servers 21a-b and 23a-b. Neuro Node 17 and Edge Servers 21a-b are locally interfaced via an intranetwork 27 and are interfaced to the Neuro Center 15 via a gateway (GW) 28 interfacing to the internetwork 26. Neuro Node 19 and Edge Server 23a-b directly interface to the Neuro Center 15 via the internetwork 26. Other configurations and network topologies are feasible, as would be recognized by one skilled in the art.

(20) The Neuro Nodes 17 and 19 maintain segment storages 18 and 20, respectively, in which complete sets of individual encrypted segments comprising a complete (or portion of a) media selection are stored. The Edge Servers 21a-b and 23a-b also maintain segment storages 22a-b and 24a-b, respectively, in which mirrored segments are maintained. The Neuro Nodes 17 and 19 selectively copy or “mirror” segments to the Edge Servers 21a-b and 23a-b to optimally balance the distribution of individual encrypted segments throughout the network. Neuro Nodes 17 and 19 are further described below with reference to FIG. 6 and Edge Servers 21a-b and 23a-b are further described below with reference to FIG. 7.

(21) The individual computer systems, including Neuro Center 15, Neuro Nodes 17 and 19, Edge Servers 21a-b, and 23a-b, and Smart Client 11, are general purpose, programmed digital computing devices consisting of a central processing unit (CPU), random access memory (RAM), non-volatile secondary storage, such as a hard drive or CD ROM drive, network interfaces, and peripheral devices, including user interfacing means, such as a keyboard and display. Program code, including software programs and data, are loaded into the RAM for execution and processing by the CPU and results are generated for display, output, transmittal, or storage.

(22) FIG. 2 is a process flow diagram showing load balanced secure media content delivery 40 via the system of FIG. 1. The key to achieving dynamic load balancing is through the continuous determination of network throughput and load characteristics using client-generated “pulses” A pulse is generated prior to requesting each individual encrypted segment to identify an optimally sited Neuro Node or Edge Server from which to request the segment. Media content delivery begins with a Smart Client 41 sending a request 45 to a Neuro Center 42 (step {circle around (1)}). In response, the Neuro Center 42 validates the client request 45 and sends a response 46 requesting the Smart Client to “pulse” the network status prior to commencing delivery (step {circle around (2)}).

(23) The requested media content is delivered in individual encrypted segments received from Neuro Nodes 43 and Edge Servers 44. Prior to receiving each segment, Smart Client 41 broadcasts a “pulse” 47 over the network to determine the load and operational status of the various Neuro Nodes 43 and Edge Servers 44 (step {circle around (3)}). The Smart Client 41 receives “pulse” responses and segments 48 back from the Neuro Nodes 43 and Edge Servers 44 (step {circle around (4)}). The Neuro Center 42 manages encryption and security in the background to media content delivery.

(24) The “pulse” responses indicate the network load and relative status of each network component while each segment contains a portion of the actual requested media content. The Smart Client 41 reassembles the individual encrypted segments and begins media playback upon receiving a sufficient number of segments. The Smart Client 41 decrypts and decompresses each segment and provides a full-featured, full-motion playback. Note the segments need not be received in serial order and can be (and in practice, often are) requested from different Neuro Nodes 43 and Edge Servers 44, depending on network load and component status.

(25) FIG. 3 is a process flow diagram showing load balanced secure media content delivery with peer-to-peer intercommunication 60 in accordance with a further embodiment. The Smart Client 61 takes advantage of media content already made available on peer Smart Client 65 through peer-to-peer segment sharing. This approach improves file delivery capabilities and provides a highly scalable network with a rich intermediate content server population.

(26) As before, a Smart Client 61 sends a request 66 to a Neuro Center 62 to initiate media content delivery (step {circle around (1)}). The Neuro Center 62 validates the request and sends a response 67 requesting the Smart Client 61 to “pulse” the network (step {circle around (2)}). The Smart Client 61 broadcasts a “pulse” 68 over the network to the Neuro Nodes 63, Edge Server 64 and other Smart Clients 65 (step {circle around (3)}). These components send back responses and segments 69 (step {circle around (4)}) as above.

(27) FIG. 4 is a process flow diagram showing load balanced secure media content delivery with pre-casted media content staging 80 in accordance with a further embodiment. Ordinarily, a Neuro Center 81 is only initially involved in media content delivery during the validation of individual user requests. However, to substantially minimize the delay attendant to media content delivery during peak demand times, the Neuro Center 81 can pre-cast 84 (step {circle around (1)}) media content to each Smart Client 82 during off-peak times. The initial segments of popular media content are thereby staged at individual Smart Clients 82 for immediate playback by a user without incurring a delay due to network load and demand. Once playback begins, the remaining segments are sent to each Smart Client 82 in a continuous multicast 85 from the Neuro Center 81 (step {circle around (2)}).

(28) FIG. 5 is a block diagram showing the software modules 100 of the Neuro Center 101 of FIG. 1. The Neuro Center 101 functions as a centralized control center and is primarily responsible for preparing raw media content 112 for distribution as individual encrypted segments 115 and for validating individual user requests. The Neuro Center 101 includes: encoding module 102, segmentation module 103, encryption module 104, profiling and e-commerce module 105, request processing module 106, ticket validation module 107, pre-casting module 108, and multicasting and broadcasting module 109.

(29) The encoding module 102 receives raw media content 112 from a variety of diverse sources, including the Internet, satellite and cable feeds, wireless devices, and next-generation media sources. The raw media content 112 is converted into a standardized form of encoded content 114. In turn, the segmentation module 103 segments the encoded content 114 into sets of individual segments 115 which are then encrypted by the encryption module 104, preferably using a different unique key for each individual segment. The complete sets of individual encrypted segments 115 are then broadcast by the multicasting and broadcasting module 109 to the Neuro Nodes (shown in FIG. 1) for mirroring to Edge Servers and, in a further embodiment, Smart Clients.

(30) Individual users request media content delivery by sending a play ticket 110, as further described below with reference to FIG. 9. The play ticket 110 identifies the user and requested media content. The request processing module 106 processes each request and the ticket validation module 107 validates the play ticket 110. The ticket validation module 107 accesses a ticket database 118 to validate the play ticket 110 and generate a validation certificate 111 which is sent back to the requesting client. The profiling and e-commerce module 105 accesses user profiles 116 and e-commerce data 117 to provide demographics tracking and order management. As well, advertising and product targeting can be delivered via the profiling and e-commerce module 105.

(31) The pre-casting module 108 is used in a further embodiment to stage the initial segments of popular media content to the individual Smart Clients during off-peak times. Finally, the multicasting and broadcasting module 109 sends sets of segments 115, as well as individual encrypted segments 115, to a select subset of network components (multicasting) or to all network components (broadcasting). The Neuro Center 101 monitors network status 113 in the background.

(32) FIG. 6 is a block diagram showing the software modules 120 of a Neuro Node 121 of FIG. 1. Each Neuro Node 121 functions as an intermediate control node within the network. The Neuro Center (shown in FIG. 1) sends complete sets of individual encrypted segments, collectively constituting a complete work, to each Neuro Node 121 for staging and mirroring. Each Neuro Node 121 includes: mirroring module 122, request processing module 123, multicasting and broadcasting module 124, and codec module 125.

(33) The mirroring module 122 selectively stages individual encrypted segments 128 to Edge Servers and, in a further embodiment, Smart Clients. The segments are distributed throughout the network to maximize load balancing and fault tolerance. The request processing module 123 receives incoming requests from individual Smart Client. The requests are staged in a request queue 126. The multicasting and broadcasting module 124 sends a requested segment 128 if the Neuro Node 121 is optimally sited relative to the requesting Smart Client. Alternatively, a plurality of individual client requests for the same segment 128 can be stored in the request queue 126 and fulfilled en masse by the multicasting and broadcasting module 124. The advantage of staging multiple client requests is network throughput efficiency. The request processing module 123 authenticates each user through a user authentication table 129. The Neuro Node 121 monitors the network status 127 in the background. The codec 125 compresses individual encrypted segments 128 prior to delivery to a Smart Client.

(34) FIG. 7 is a block diagram showing the software modules 140 of an Edge Server 141 of FIG. 1. Each Edge Server 141 functions as an intermediate server within the network. The Neuro Nodes (shown in FIG. 1) mirror select individual encrypted segments to each Edge Server 141 for staging. Each Edge Server 141 includes: request processing module 143, segment receipt module 142, multicasting and broadcasting module 144, and codec module 145. The segment receipt module 142 receives individual encrypted mirrored segments 148 selectively staged by the Neuro Nodes.

(35) The request processing module 143 receives incoming requests from individual Smart Clients. The requests are staged in a request queue 146. The Edge Server 141 sends a mirrored requested segment 148 if the Edge Server 141 is optimally sited relative to the requesting Smart Client. Alternatively, a plurality of individual client requests for the same mirrored segment 148 can be stored in the request queue 146 and fulfilled en masse by the multicasting and broadcasting module 144. The advantage of staging multiple client requests is network throughput efficiency. The request processing module 143 authenticates each user through a user authentication table 149. The Edge Server 141 monitors the network status 147 in the background.

(36) FIG. 8 is a block diagram showing the software modules 160 of a Smart Client 161 of FIG. 1. Each Smart Client 161 initiates, facilitates and delivers media content to a requesting user. The Smart Client 161 includes: user interface module 162, request processing module 163, segment receipt module 164, multicasting and broadcasting module 165, codec module 166, and playback module 167.

(37) The user interface module 162 provides controls to select media content for delivery. The request processing module 163 forms a request for media content that is sent to the Neuro Center (shown in FIG. 1) to initiate content delivery. The segment receipt module 164 receives individual downloaded segments 168 from the Neuro Nodes, Edge Servers, and, in a further embodiment, Smart Clients. A “pulse” is sent over the network via the multicasting and broadcasting module 165 to determine the current status of the network. The segment receipt module 164 also receives pre-cast segments 169 sent by the Neuro Center during off-peak times. Similarly, the segment receipt module 164 stages mirrored segments 170 received from Neuro Nodes when providing peer-to-peer intercommunications, in accordance with a further embodiment. The codec module 166 decompresses the individual downloaded segments 168 and pre-cast segments 169. The codec module 166 performs decryption of each individual segment including the decryption by a unique key through use of the play ticket 110 and validation certificate 111 (both shown in FIG. 5). Finally, the playback module 167 provides full-feature playback functionality, including play, pause, stop, rewind, fast forward, full screen, chapter stops, shuttle bar, and similar features.

(38) Each module in the Neuro Center 101, Neuro Node 121, Edge Server 141, and Smart Client 161 is a computer program, procedure or module written as source code in a conventional programming language, such as the C++ programming language, and is presented for execution by the CPU as object or byte code, as is known in the art. The various implementations of the source code and object and byte codes can be held on a computer-readable storage medium or embodied on a transmission medium in a carrier wave. The system operates in accordance with a sequence of process steps, as further described below with reference to FIG. 12.

(39) FIG. 9 is a data structure diagram showing a play ticket 180 used by the system 10 of FIG. 1. Each play ticket 180 is used to transact the purchase or rental of delivered media content. Briefly, a play ticket 180 is issued on an individual customer basis and contains information about the movie ordered. Only a portion of the movie key for each movie is stored on a play ticket 180 to disable decryption and safeguard against theft and unauthorized access. The movie key also prevents reuse of the play ticket 180.

(40) When a customer orders media content from a Neuro Center (shown in FIG. 1), a play ticket 180 is generated and includes the following:

(41) (1) Certificate serial number (181) for the ticket;

(42) (2) Customer number (182);

(43) (3) Creation date and time (183);

(44) (4) Expiration date and time (184);

(45) (5) Movie title number (185);

(46) (6) Number of plays (186)

(47) (7) Reserved (187)

(48) (8) Movie key (Part 1) (188); and

(49) (9) Certificate signature (189).

(50) The Certificate signature 189 is a digital signature prepared using symmetric public key encryption. The certificate signature 189 ensures the ticket cannot be altered without validation. As well, the movie key part 1188 includes only a portion of the entire movie key, which is split into two pieces between the play ticket 180 and a validation certificate 200 (shown below in FIG. 10).

(51) In the described embodiment, each play ticket 180 has a 96-byte structure containing all information necessary to validate the play ticket. The certificate serial number 181 is used as a record lookup key into the ticket database 118 (shown in FIG. 5). The customer number 182 and movie title number 185 are also stored in the ticket database 118 and validated when the play ticket is used.

(52) Before the play ticket 180 is presented for validation by the Neuro Center, the Smart Client checks the certificate signature 189 for validity. The certificate signature 189 includes a checksum of the certificate consisting of the first 64 bytes which are cryptographically signed using the Digital Signature Standard (DSS). If the play ticket 180 has been altered, the certificate signature 189 will not match and the signature validation will fail.

(53) The number of plays field 186 can contain either a special numeric value indicating the ticket is good for unlimited plays, that is, the user has purchased the media content, or a numeric value indicating the number of plays remaining in a rental of the media content. Unlimited play tickets 180 do not have an expiration date and time 184.

(54) Generally, all other play tickets 180 are good for only one play. If the number of plays in the play ticket 180 is greater than one, the play ticket 180 must be replaced. When validated, a replacement play ticket 180 is also returned with the number of plays field 186 reduced and a new certificate serial number 181 issued.

(55) FIG. 10 is a data structure diagram showing a validation certificate 200 used by the system 10 of FIG. 1. Each validation certificate 200 includes essentially the same information as a play ticket 180 as follows:

(56) (1) Certificate serial number (201) for the validation certificate;

(57) (2) Customer number (202);

(58) (3) Creation date and time (203);

(59) (4) Expiration date and time (204);

(60) (5) Movie title number (205);

(61) (6) Reserved (206);

(62) (7) Movie key (Part 2) (207); and

(63) (8) Certificate signature (208).

(64) Like the play ticket 180, the Neuro Node validates each validation certificate 200 using the certificate signature 208. If the certificate signature 208 does not match, the validation certificate 200 is invalid. The validation certificate 200 includes the other remaining portion of the movie key Part 2 207.

(65) In the described embodiment, each movie key is split into two parts by using a second 128-bit random number generated using the same operations as used to generated the movie key Part 1. The second 128-bit random number is used as a split filter using an exclusive OR operation against the full movie key. The value used to split the key becomes the validation key.

(66) Play tickets are computed according to the following operation:
K.sub.2=K.sub.M⊕K.sub.1

(67) where:

(68) K.sub.M is the Movie Key

(69) K.sub.1 is the Validation Key (Split Value)

(70) K.sub.2 is the Play Ticket Key

(71) The validation key is stored in the ticket database 118, along with the other information necessary to validate the play ticket 180. The play ticket key becomes part of the play ticket 180.

(72) During the later validation phase, after the play ticket information has been validated against the ticket database 118, a validation certificate 200 is generated and sent to the user. This certificate includes the validation key. The full movie key is recovered by using an exclusive OR of the two values to reverse the split process and recover the original key.

(73) FIG. 11 is a data structure diagram showing a packet header 220 used by the system 10 of FIG. 1. A packet header 220 is prepended to each segment to enable a Smart Client (shown in FIG. 1) to reassemble the media content and enable playback. In the described embodiment, the individual data packets are sent in accordance with the Tranz-Cast Delivery Protocol (TCDP), a data exchange network based on the Reliable Multicast Framework (RMF).

(74) The fixed header of each TCDP data packet contains the following fields:

(75) (1) Sources (221): port number from which the packet was sent;

(76) (2) Destination (222): port number to which the packet was directed;

(77) (3) Packet Length (223): contains a count of octets in the packet, including the header and data;

(78) (4) Checksum (224): corresponds to the Internet protocol checksum;

(79) (5) Type (225): identifies the type of packet;

(80) (6) Data Owner (226): contains a unique identifier for the originator of the data. Together with the sequence number, the contents of this field uniquely define a packet when multiple senders share a common multicast address;

(81) (7) Sequence Number (227): increments by one for each new packet sent and may be used by the receiver to detect packet loss and to restore packet sequence;

(82) (8) Header Extensions (228): indicates the presence of a header extension field; and

(83) (9) Data (229): Variable payload data is appended to the end of the header 220 and may be of any length, including zero, as specified by the type field. Other types and combinations of fields are possible, as would be recognized by one skilled in the art.

(84) FIG. 12 is a flow diagram showing a method for providing load balanced secure media content delivery 240 in a distributed computing environment. Each of the individual components, the Neuro Center, Neuro Nodes, Edge Servers, and Smart Clients, operate independently following initialization and start-up (blocks 241-244, respectively). With the exception of the Neuro Center, the various components can initiate and terminate their respective processing asynchronously without significantly affecting the continued operation of the remaining components. Following initialization and start-up, the method completes.

(85) FIG. 13 is a flow diagram showing a routine for performing the operations of the Neuro Center 250 for use in the method of FIG. 12. The purpose of this routine is to initially, and as necessary, stage complete segment sets to Neuro Nodes for mirroring and validate individual user requests.

(86) Thus, complete sets of segments 115 (shown in FIG. 5) are sent to Neuro Nodes (block 251). Thereafter, user requests are processed in an iterative processing loop (block 252-263) as follows. During each iteration (block 252), a user request is received (block 253) from a Smart Client and the corresponding user profile 116 is looked up (block 254). The play ticket 180 (shown in FIG. 9) is looked up in the ticket database 118 (block 255) and, if valid (block 256), a validation certificate 200 (shown in FIG. 10) is generated (block 258). If more plays are left on the play ticket 180 (block 259), a replacement play ticket 180 is generated (block 260). The validation certificate 200 and a replacement play ticket 180 are sent to the user (block 261) and the e-commerce data 117 is updated (block 262).

(87) If the play ticket 180 is not valid (block 256), an invalid play ticket message is sent to the user (block 257) and the e-commerce data is updated (block 262). Processing continues with each subsequent user request (block 263), after which the routine returns.

(88) FIG. 14 is a flow diagram showing a routine for performing the operations of a Neuro Node 270 for use in the method of FIG. 12. The purpose of this routine is to mirror individual encrypted segments to the Neuro Nodes and to deliver requested segments to Smart Clients.

(89) Thus, initially and as required thereafter, individual encrypted segments 128 (shown in FIG. 6) are mirrored to Neuro Nodes and, in a further embodiment, to Smart Clients, for providing load balancing and optimal retrieval of media content over the network (block 271). User requests are then processed in an iterative processing loop (blocks 272-276) as follows. During each iteration (block 272), a user request is received (block 273) from a Smart Client. The requested segment 128 is retrieved (block 274) from the segment storage and sent to the requesting user (block 275). Iterative processing continues (block 276) until the Neuro Node terminates, after which the routine returns.

(90) FIG. 15 is a flow diagram showing a routine for performing the operations of an Edge Server 280 for use in the method of FIG. 12. The purpose of this routine is to receive individual encrypted mirrored segments and to deliver requested segments to Smart Clients.

(91) Thus, initially and as required thereafter, individual encrypted segments are received from Neuro Nodes and staged (block 281) as mirrored segments 148 (shown in FIG. 7). User requests are then processed in an iterative processing loop (blocks 282-286) as follows. During each iteration (block 282), a user request is received (block 283) from a Smart Client. The requested segment 128 is retrieved (block 284) from the segment storage and sent to the requesting user (block 285). Iterative processing continues (block 286) until the Edge Server terminates, after which the routine returns.

(92) FIG. 16 is a flow diagram showing a routine for performing the operations of a Smart Client 290 for use in the method of FIG. 12. The purpose of this routine is to request delivery of and playback media content selected by a user. In a further embodiment, the Smart Client provides peer-to-peer intercommunications by serving individual encrypted mirrored segments to other Smart Clients.

(93) Thus, in a further embodiment, individual encrypted mirrored segments 170 (shown in FIG. 8) are staged (block 291) for retrieval by peer Smart Clients. Thereafter, media content requests are processed in an iterative processing loop (blocks 292-306) as follows. During each iteration (block 292), media content is ordered (block 293) through the user interface 162. A play ticket 180 (shown in FIG. 9) is received from the Neuro Center (block 294) and validated by the Smart Client (block 295) by authenticating the certificate signature 189. If the play ticket 180 is not valid (block 296), the media content is re-ordered (block 297) from the Neuro Center.

(94) The status of the network is determined prior to requesting each individual segment (blocks 298-300) as follows. First, a “pulse” is sent from the Smart Client (block 298) to the Neuro Nodes, Edge Servers and, in a further embodiment, peer Smart Clients. A pulse report is received back from each of the components (block 299) and an optimal route is determined (block 300) for each of the individual encrypted segments.

(95) Each individual encrypted segment is requested (block 301) and received (block 302), preferably from an optimally sited network component. If segments sufficient for playback have been received (block 303), playback begins (block 304). Receipt of segments continues (block 305) until media content delivery is complete. Processing media content requests continues (block 306) until the Smart Client terminates.

(96) In a further embodiment, the Smart Client sends individual encrypted mirrored segments 170 to peer Smart Clients upon request (blocks 307-109) as follows. A user request for an individual encrypted segment is received (block 307). The requested mirrored segment 170 is retrieved (block 308) and sent to the requesting user (block 309). The delivery of mirrored segments 170 from a peer Smart Client enables fuller network resource utilization and improved load balancing characteristics for the network.

(97) While the invention has been particularly shown and described as referenced to the embodiments thereof, those skilled in the art will understand that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the invention.