KR102194021B1 - Peer-to-peer content delivery network, method, and manager - Google Patents

Abstract

A peer-to-peer (P2P) content delivery network delivers select data files to end users. The content delivery network provides a client, a P2P gateway server, and a resource name server (RNS) within a computer-populated network. RNS caches data resource locations within a computer-populated network and resolves resource requests using optimal data resource locations within the computer-populated network. The gateway server requests and receives optimal data resource locations via RNS; Request and receive data files from the computer-populated network via optimal data resource locations; Processes received data files for data file transfer to the client. Thus, the network enables an origin-agnostic data transmission method for optimally transmitting select data files to end users. The data-routing control or management utility controls/manages the content delivery network and related methods to provide industry rights management, compliance monitoring, and/or compliance reporting of data file transfers.

Description

Peer-to-peer content delivery network, method, and manager {PEER-TO-PEER CONTENT DELIVERY NETWORK, METHOD, AND MANAGER}

The present invention generally relates to a content delivery network, and a related method for providing a media compliance engine. The media compliance engine according to the present invention operates as local gateway servers that use peer-to-peer networks and multiple data origins (cloud) to optimize the transmission of media and simplify the reporting process. The media compliance engine according to the present invention matches requests from streaming providers with an optimized data source and network. By doing so, the media compliance engine can minimize bandwidth consumption, licensing, and reporting costs.

The present invention provides a peer-to-peer content delivery network (CDN) that can be added to any existing standard content delivery network, or server configuration, without any changes to the back end systems. A peer-to-peer CDN according to the present invention is formed when an end user installs a local peer-to-peer gateway server on a client machine. The gateway server receives request(s) from the media consuming client over an encrypted or decrypted connection (eg, HTTP, HTTPS, secure socket, and/or socket).

The local gateway server operates as a peer on a peer-to-peer network and also has an encrypted cache that stores data for transmission to other peers or for local transmission to data consuming clients. In addition, the local gateway server can pull resources from an associated remote data source (eg, server or other CDN). The consuming client will only have to forward a single request to the gateway server, and the gateway server manages resources and network connections independently of the client. This type of setup allows for media transfer to standalone desktop applications, as well as mobile applications, browsers and media players with the capabilities of standard web browsers (e.g. HTTP, HTTPS, and/or sockets). Makes it possible.

The present invention provides a P2P gateway server for receiving communication from a client on a local machine. The communication or request can be formatted as a standard HTTP request directed to the local gateway server, which is registered under the local domain name. Consider that the request(s) may be formatted differently when a new transport protocol that refers to a reserved port in which the gateway server exists is formed. In this case, the request will be formatted slightly differently (ie, without the HTTP prefix).

The present invention provides a Resource Name Server (RNS), which RNS caches the resource URL and resource location (i.e., IP address) and also has a machine address to resolve resource requests. A general process or method for mismatched media types is as follows.

1. The client sends a request for resources to the gateway server;

2. The gateway server then sends the request to the RNS to resolve the resource request with the resource address;

3. If the resource request matches the optimal (least cost) resource locations, the resource location data is sent back to the gateway server;

4. The gateway then sends the request for resource data to the appropriate machines or server clusters;

5. The machines or service clusters then respond by providing the requested data to the gateway server located on the local machine;

6. The gateway process organizes and verifies the data and then transfers the resources to the client on the local machine;

The reader will note that in a conventional client-server relationship, the client requests data from the server, and the server sends the data according to the client request. In a conventional unmanaged peer-to-peer network, each peer can act as both a server (ie, a sender of data) and a client (ie, a recipient of data). In an unmanaged environment, requests for data are passed from peer to peer until the file is located.

A managed peer-to-peer network has a centralized server that indexes resources. Peers in these networks can make the location of resources easier and faster by reporting and registering their availability. In hybrid systems, peer-to-peer networks provide low-cost peer transport, but to provide consistency and speed of heavy-duty centralized data sources, and to expedite resource transfers as in managed peer-to-peer networks. , Used with a centralized data source/indexing server. In this situation, the data origin server and peers merge to transmit data.

According to the invention, the client is a standalone client, and data requests are sent and consumed by the standalone client (browser, desktop or mobile application). Unlike the networks described above, requests for data are not originated by peers, but are originated by standalone clients as in a conventional client-server relationship.

The gateway server receives the request and then resolves the request for the resource by the resource name server (i.e., the resource indexing server). The RNS responds with a resource origin (ie, an IP address), which can be a resource origin or peer. Assuming the network is irrelevant to the origin of the data, peer data is not managed by a central data server, but rather indexed on the RNS as requests are forwarded and cached at the gateway server.

Thus, in such a network, since the data source is away from the resource indexing server, any data request by a standalone client can be made to be input from a data origin or peer-to-peer (P2P) network, which means that the request is sent from a standalone client This is because data in the P2P network is cached when transmitted.

Other features of the invention will become more apparent from the following brief description of examples of the invention.
1 is a diagram showing a fragmented configuration of a data file including a row of sub-stream packets and a column of verification packets.
2 is a first diagram showing a system overview according to the present invention, showing a gateway server located in the middle of a cloud of server clusters and a resource name server.
3 is a second diagram showing a system overview according to the present invention, showing a gateway server located in the middle of a cloud of server clusters and a resource name server.
4 is a diagram showing an overview of a domain name server system.
5 is a diagram showing an overview of a resource name server system.
6 is a diagram showing an overview of non-plug-in security measurement.
7 is a diagram illustrating a conventional client-server relationship in which a client requests data and a server transmits data.
Figure 8 is a diagram illustrating a peer-to-peer unmanaged network overview in which each peer can act as both a server and a client, and requests for data are passed from peer to peer until a file is located.
9 is a diagram illustrating a peer-to-peer managed network overview in which a centralized server indexes resources and peers report and register their availability.
Figure 10 is a peer-to-peer centralized hybrid in which a peer-to-peer network is used with a centralized data source/indexing server to provide low-cost peer transport, but to provide consistency and speed of centralized data sources. It is a diagram showing the outline of the network.
11 is a diagram illustrating an overview of a peer-to-peer gateway server network.
12 is a diagram showing how secure connections are structured from a local server and browser perspective.
13 is a diagram showing how a local gateway server is verified through a plug-in.
14 is a diagram illustrating a resource indexing configuration with an initial request but no file matching.
15 is a diagram showing a resource indexing configuration with a subsequent request and no file matching.
16 is a diagram showing a progressive cloud indexing configuration with an initial request.
17 is a diagram showing a configuration of local resource indexing.
18 is a diagram illustrating a first indexed resource request processing configuration.
19 is a diagram illustrating a second indexed resource request processing configuration.
20 is a diagram illustrating a third indexed resource request processing configuration.
21 is a diagram illustrating a fourth indexed resource request processing configuration.
22 is a diagram showing a cloud transmission configuration of sub-licensing.
23 is a diagram showing a peer-to-peer transmission configuration of sub-licensing.
24 is a first diagram illustrating a streaming provider requesting a song to be played on a mobile device according to the present invention.
25 is a second diagram showing a streaming provider requesting a song to be played on a mobile device according to the present invention.
26 is a diagram illustrating an overview of a gateway server improved system according to the present invention.
27 is a diagram showing a configuration of a pre-recorded media queue according to the present invention.
28 is a diagram showing a stream division configuration according to the present invention.
FIG. 29 is a diagram showing a structure of an MP3 file according to the present invention showing frame headers and audio frames of an audio stream.
30 is a diagram showing the state of technology methods for streaming radio over the Internet.
31 is a diagram illustrating a system overview for advertisement integration without audio mixing according to the present invention.
32 is a diagram showing the configuration of an advertisement indicator according to the present invention.
33 is a diagram illustrating a method related to routing HTTP requests from browsers and/or other media-consuming clients.

Referring now to the drawings in more detail, the present invention provides a content delivery network and a related method for Cloud Agnostic Peer-to-Peer Data Streaming. As noted above, the present invention includes a peer-to-peer (P2P) gateway server as shown and referred to as 3. The P2P gateway server 3 receives communications (as in 200) from the client 2 on the local machine 101.

These requests can be formatted as standard HTTP requests directed to the local gateway server 3 which are those registered under the local domain name. While routing HTTP requests from web browsers and other devices may involve the use of locally registered domain names and protocols are viable methods, the following method provides HTTP requests from browsers and other media consuming clients. Preferred when routing them.

The consuming client 2 is given a Fully Formatted domain name for the peer-to-peer remote server 4 or the resource name server 4. For simplicity, the reader will consider the domain name www.rns_server.com. To request media 401 via a peer-to-peer content delivery network (CDN) as in 144, the client 2 serves as a URL with the RNS public domain name, and a GET variable with the location of the requested media. Includes a part of the form www.rns_server.com?media=www.somemediasource.com/media.mp4&protocol=http.

Upon receiving the request, the RNS 4 queries 404 two separate databases. The first query uses the public IP address of the requesting devices to identify if any network peers 3 are present in the local network 101 of the requesting devices. The second query identifies peers 3 using the requested media available for streaming (as in 200, 207, 208, 209, and 210) within a peer-to-peer (P2P) CDN 144 To do this, it searches the resource database.

Based on the results of queries 404, the following may occur. First, if there is no registered peer on the local network, the request will be directed back to the remote source 104 of media, as at 403, and the P2P network 144 will not be used. If there is a registered peer 3 in the local network 101, the request is directed back to the local network peer 3 with the resource location and availability data that was retrieved in the second query 404 as in 402. The local network peer 3 then handles the media stream (as in 200, 207, 208, 209, and 210).

Accordingly, the reader will understand that the RNS cited at 4 is central to the practice of the present invention. The RNS 4 caches the resource URL and resource location (IP address), and uses the machine address (IP address) to resolve resource requests. The general process for mismatched media types would be as follows. The client 2 sends a request for resources to the gateway server 3 (as in 200).

The gateway server 3 then routes the request (as in 201) to a separate RNS 4 to resolve the incoming resource ID/URL request (as in 203) using the resource address (as in 204). By sending, the resource or IP address is then communicated back to the gateway server 3 (as in 205), as shown more specifically in FIG. 5. That is, if the resource request 203 matches the optimal (e.g., (a) the most cost effective or (b) the highest sound quality of the source) resource location 204 as in 202, the resource location data or IP The address(s) 204 is returned to the gateway server 3 as in 205.

The gateway server 3 then sends the request(s) for resource data (as in 206, 207, and 208) to the appropriate machines 102 and/or 103 or server clusters as in 104. Machines 102/103 or server clusters 104 then respond by providing the requested data (as in 209) to a gateway server 3 located on machine 101. The gateway server 3 on the machine 101 processes (i.e., organizes and verifies) the data as provided at 209, and then transfers 210 the resources to the client 2.

Certain client-server-peer relationships are basically shown in Figures 7, 8, 9 and 10. A conventional client-server relationship is shown in Fig. 7; The unmanaged peer-to-peer network is shown in Figure 8; The managed peer-to-peer network is shown in FIG. 9; The centralized/hybrid peer-to-peer network is shown in FIG. 10.

In a conventional client-server relationship, the client 105 requests 211 data from the server 106, and the server 106 transmits data 212 in a periodic manner as shown in FIG. 7. Typically, each peer (or client/server combination) 107 in an unmanaged peer-to-peer network can act as both a client 105 receiving data and a server 106 transmitting data. In an unmanaged environment as generally shown in FIG. 8, a request 211 for data is passed from peer 107 to peer 107 until the file is located.

A managed peer-to-peer network as generally shown in FIG. 9 has a centralized resource-indexing server 108 that functions to index resources. The indexed resources are sent to peers 107, whereby requests 214 follow. The availability of the indexed resource is then reported and registered by peers 107. This type of configuration makes positioning of resources easier and faster.

In the hybrid system generally shown in FIG. 10, a peer-to-peer network is used with a centralized data source/indexing server 109. Both indexed resources and data are transferred 215 from server 109 to peers 107, followed by requests 216 for resources and data by peer(s) 107 . This type of configuration provides the consistency and speed of a low-cost peer transmission, but a centralized data source, to expedite resource transmission as in a managed peer-to-peer network. In this situation, the mixing of data begins with the server 109 and peers 107 transmit the data.

In the origin-agnostic peer-to-peer content delivery network (CDN) 144 generally shown in Figures 2 and 3, the client 2 is a standalone client. That is, a data request is initiated and consumed by the standalone client 2 (ie, a browser, desktop or mobile application). Unlike in other networks, the request for data is not initiated using peer 107, but is initiated using a standalone client 2 as in the conventional client-server relationship generally shown in FIG. 7.

The gateway server 3 receives a request from the client 2, and then resolves the request for a resource using a resource name server or a resource indexing server 4. The RNS 4 responds using resource locations (eg, IP address), and the resource locations may be resource origins or peers. If the network is said to be data origin-independent, peer data is indexed on the RNS 4 as requests are forwarded and cached in the gateway server 3, rather than being managed by a central data server.

In such a network, the data source is remote from the resource indexing server or RNS 4. This is because data in the peer-to-peer network is cached when the request is sent from the standalone client 2, so that any data request by the standalone client 2 is input from the data origin or peer-to-peer network. Let's do it.

The present invention is not limited to using HTTP or Web sockets, and standard file transfer protocols (FTP, WebDAV, SMB, AFP, etc.) may be used. In this case, the client will be a standalone FTP (or any standard file transfer protocol client). If an FTP directory (or WebDAV, SMB, AFP, etc.) is mounted as a network drive in the operating system, the operating system will act as a client. In this situation, the gateway server will act as a file server.

In particular, there are several security problems in this configuration. The proposed solution or configuration in accordance with the present invention is potentially vulnerable to "man in the middle attacks" and/or unauthorized client access. These problems can be addressed by providing some means of client and/or server authentication. The client and/or server authentication means basically functions to verify the client and/or server authenticity.

The client and/or server authentication means may be exemplified by a number of different mechanisms, which are described in more detail later. For example, the authentication means is media plug-in authentication (client authentication), and a browser extension that verifies the local server to ensure that it is not a corrupt server (this is a unique ID, session token, or key pairing). May require some kind of).

In addition, the client-side script along with the plug-in may be used to authenticate both the client and server by embedding some form of verification identification in the plug-in, after which some form of verification identification is verified using AJAX. Is delivered to the client-side script. The use of a client-side script in conjunction with a browser plug-in is preferable as it provides verification of both the client and server in one process. This method is described below.

Referring to Figures 12 and 13, the reader will consider client verification through browser plug-ins and client-side scripts. The process of creating a secure connection begins with the installation of the local server. When installed, the server generates a self-signed certificate and adds the self-signed certificate to the root certificate tree. This allows the server to create a secure connection from the browser.

To add another layer of security, the local server 110 loads multiple instances of the media processing browser plug-in 24 (eg, Flash, Silverlight, etc.). The local server 110 can easily load as many as 1,000 multiple instances of the media processing browser plug-in 24. Each instance has its own encryption key, as in 27, embedded within the instance. Instead of loading multiple instances, the encryption key 27 can be injected into the plug-in component file if custom code insertion is enabled by plug-in libraries.

When the browser creates a secure connection as in 26, the server 110 creates a unique session for the initiated connection, and then pairs that session with the media plug-in instance 24 and the embedded encryption key 27 or Alternatively, the encryption key 27 is generated and injected into the plug-in component file. After that, the plug-in component file 25 is loaded into the browser 111. The plug-in file 25 encrypts all requests coming from the browser 111 through a client-side script, and also sends them to the server 110 through an encrypted connection 26. Further, the unique encryption key 27 may be a unique token used to sign requests to verify the requests.

In order to retrieve the encryption key or token 27, the plug-in file 25 provided by the local server 110 is decompiled, and then a new "cracked" plug-in instance is used to interact with the server 110. You will have to re-establish the connection. However, since the server 110 selects a different encryption key 27 for each session, the old encryption key 27 expires as soon as a new secure socket connection 26 is established. This makes the encryption key 27 retrieved through decompilation useless.

One of the major problems with using a local server for content delivery is that scenario malicious software is capable of "man-in-the-middle attack" that can block user data by pretending to be a valid gateway. To prevent this type of attack, the system uses a method of requesting the local server 110 to verify the authenticity of the valid gateway by presenting the valid server authentication identification 31 via the browser plug-in component 25. The process is described in more detail later.

Each local gateway server 110 registers itself with a remote host 112 (as in 19) by generating a verification identification 31 that is linked to the local machine's public Internet protocol. This verification identification 31 and its associated public internet protocol are stored in a database 29 on the remote host 112. When the web page 30 is loaded using the local gateway server 110, the browser 111 transmits a request to the local server 110 (as in 217). Server 110 responds by presenting its verification identification 31.

The browser 111 then sends a request with a verification identification 31 to the remote host 112 (as in 218). If the verification identification 31 matches the Internet Protocol address and verification identification stored in the remote database 29, the remote server 112 sends a response along the path 218 that verifies the local gateway server 110. After verification, the browser 111 proceeds to load the media plug-in 24 (as in 26) from the local server 110. The media plug-in 24 then creates a secure connection 219 to the local gateway server 110 that transmits data (eg, music-based data).

Referring to Figure 6, the reader will consider a non-plug-in security measure. A method that does not require the use of a media plug-in according to the present invention comprises the step of the client 2 sending a request for a registered session identification 113 from the gateway server 3 to prove its authenticity. Include. The session identification 114 is pre-registered (as in 221) by the gateway server and becomes invalid after a single authentication.

This requires that the gateway server 3 registers multiple sessions 114 in advance, and that each session identification 113 is valid only for a single verification. The gateway server 3 presents the session identification 113 to the client 2 (as in 222). Thereafter, the client 2 verifies the received session identification 115 (as in 223) using the verification server 116. The verification server 116 matches the session identification 115 sent by the client 2 (as in 224 and 225) with the registered session identification 114. If a match is found, the verification server 116 verifies the validity of the gateway server 3 to the client 2 (as in 224).

Other alternative methods exist to ensure valid access, including integrating the operating system with the local domain name reserved for the gateway server, so that other applications can create a transfer protocol for data transmission through these systems Human body can not Both of these are possible solutions. However, custom protocol solutions require different request formatting, as illustrated later:

rstp://domain.com/resource_directory/resource_name?var=123

( and not http://vertigo/domain.com/resource_directory/resource_name?var=123)

Another way to secure the system is to limit the content transmitted through the system to media (music, images, videos, etc.), and to limit file distribution for content not related to the structure and code of a website or application. Is to do. This method is more difficult to load malicious code because only media files are allowed. This is done for security considerations. In other words, HTML, JavaScript, CSS, and PHP files cannot be delivered through the gateway server. Another limitation is to have a client (browser) restricting the use of these gateways or protocols if the website (structure, code and media) is loaded over https and is confidential.

Referring to Figure 1, the reader will consider certain data validity and security aspects in accordance with the present invention. One of the problems with the data-originated CDN 144 is the validity of the data. For example, if one of the peers has corrupted data, or if someone creates a malicious peer that registers files unrelated to the original data as peer-cached versions of the original file, the reliability and usefulness of the system will be compromised. I can.

This is why data fragmentation and verification methods should be included for a reliable and useful system. Accordingly, in order to keep a single peer from corrupting or intentionally replacing data in an improper manner, it is desirable to fragment the data transmission across multiple peers through some data transmission fragmentation means. The data transmission fragmentation means according to the present invention can be exemplified by a number of mechanisms. For example, data transmission fragmentation can be achieved by dividing data 199 into packets or sub-streams as in rows 117, 118, 119, 120. Fragmentation can be optimized to meet the requirements of the system.

Fragmentation can be done by simply limiting each peer's transmission to, for example, at most 1/3 or 1/4 of a given media file. This is managed using a resource name server or RNS 4 as described in more detail later below. With data transfer fragmentation, each data file has a verification package for a specific sector of data as in columns 121, 122, 123, 124. This is done because all peers providing the data must first cache the media before providing the data again. Thus, as an example, if a peer sends a data substream 117, it will also send a verification package for sector 121 of the file along with that data. This verification package is a checksum generated by a predetermined algorithm.

Thus, if the peer-transmit sub-stream 118 was to transmit corrupt or malicious data, the receiving peer may perform a verification checksum from the peer-transmit sub-stream 117 to verify the content delivered by the peer-transmit sub-stream 118. You will be able to detect this by using. If the content cannot be verified, the peer will send the data request to the original or data origin source. The present invention will enable such peer-to-peer data verification, further taking into account setting a minimum daily threshold of requests. Otherwise, the verification server will provide checksums, and these checksums will be formed in the first request forwarded to the gateway server for the resource.

Referring to Figures 4 and 5, the reader will compare and consider certain differences between a domain name server (DNS) and a resource name server (RNS). The main difference between DNS 130 and RNS 4 is how requests for resources are handled. Within DNS 130, a request for a resource (such as in 226) is an SOA 126 or domain name 129 with a specific resource 127 in a directory 128 of a Start of Authority (SOA) 126. Is solved (as in 227). The client 2 receives the IP address of the SOA from DNS (as in 228), and then makes a request (as in 229) for the resource 127 from the SOA 126.

Within the resource name server or RNS 4, the RNS 4 resolves a request (as in 201) for a resource (as in 202) for multiple machines with unique resources stored or cached. . Thus, the IP address of the SOA with the resource can be returned (as in 205) as a valid resource location, and the IP address for peer cached resources can also be returned. That is, within the DNS system, the URL is more similar to the address of a particular resource, and within the RNS 4, the URL 240 is treated as a unique identification linking the unique resource to multiple locations.

Some means for resource indexing without using file matching are shown in FIGS. 14 and 15, and some means for resource indexing using file matching are shown in FIGS. 16 and 17. One of the main issues that arise when dealing with compliance is how to verify what is being regenerated. Metadata is often corrupted or modified by the user. Therefore, in order to stream local media more effectively, it is necessary to provide a method for verifying with a very high degree of certainty that media files or songs on a local drive correspond to those stored in the cloud.

This is done by using a metadata-independent file matching system or means, and also by indexing all local files and matching them with cloud files. There are two sources of files that must be matched against the library in accordance with the present invention, including (1) those originating from other streaming providers or coming from external clouds, and (2) those on the local machine.

Referring to Fig. 16, the process 247 of progressive indexing begins with a request coming from a third party client application. This may be a standalone desktop application as in 131 or a website played through a browser as in 132. The application 131 or browser 132 passes a properly formatted and valid URL (such as 241 and 242) to the local gateway server 133. Local gateway server 133 retrieves the requested resource for streaming (such as in 243 and 244) from the associated cloud 245, 246 (or associated peer-to-peer network, or any possible network-based resource). For this, use the URL (as in 241 and 242). If the resource has been downloaded for streaming, such as at 243 and 244, the local server 133 begins the process of indexing as at 247 (with subroutines 248-252). Local resource indexing 253 is shown generally in FIG. 17 (with subroutines 254-258).

Indexed resource request processing 259 is shown generally in FIG. 18. After the resource has been indexed, the following process occurs when subsequent requests are made from third party clients. Assuming that the media streaming service provider (as in 132) publishes the request 242 to the local server 133 using a standard URL, the request 242 arrives and the local server 133 has previously The local file system database 135 and indexing server 134 are queried to determine if they have been indexed. (The URL is used to determine if it exists on the indexing server 134 or on the local file system 137.) In this case, the local server 133 has the resource indexed and on the peer-to-peer network 138. Decide that it is available. The media is then retrieved from the peer-to-peer network 138 and provided to a media streaming service provider (such as at 132) for playback.

In other cases, the media streaming service provider (such as in 131) makes a similar request using the URL. At this time, the server 133 determines by querying a local database indicating that the resource is indexed and associated with the local file 137. The server 133 then provides this file to, for example, a third-party cloud-based music streamer (eg, Spotify) (such as in 131). Systems or applications accessing the local gateway server 133 are likely to deliver all the resources required during the session at the start of the session. Thereafter, server 133 will derive the associated fields from resource indexing server 134. All of this indexed data is stored locally for quick access and routing.

The gateway server according to the present invention provides predetermined means for both smart routing and royalty reporting for data (eg, music) transmission. Assuming that music can be transmitted from multiple sources, the local gateway servers according to the present invention deliver both the reciprocal music request and the non-interactive music request made by the client application, and also the bandwidth cost and loyalty agreement. Route the actual transmission from the best (eg (a) most cost effective, or (b) highest sound quality of the source) location on both sides. Such a system results in a unique compliance engine or compliance device that allows usage reports and loyalty agreements to be generated from and across various types of service platforms, while meeting the requirements and criteria of all rights holders. .

Examples of transmission sources include: (1) cloud-based streamer; (2) a third-party cloud-based storage provider that makes purchases of data available to device owners; (3) Vertigo's cloud-based virtual locker (protected under 512(c) of the Copyright Act); (4) Vertigo-licensed music driven by user/sub-service matched data; (5) locally owned and stored music files available on the listener's device or other owned entitled device connected via Wi-Fi; (6) transfer from the linked PC to the mobile device; (7) Includes, but is not limited to, peer-to-peer owned files routed on replacement of a file prior to being streamed from (1), (3) and (4) listed above and available for transmission.

Some examples of music routing and route-result reporting are as follows. Referring to FIG. 19, a listener is listening to a non-interactive Internet radio channel via an associated streaming client (e.g., a website or a standalone desktop application) (such as in 140), and an Internet radio service provider is on the listener's device. When ready to stream the file 139 that is already stored and available in (as in 230), the gateway server 141 according to the present invention sends the indexed local file 139 to the Internet radio service provider's incoming request The reader will consider matching (as in 231) and streaming the file 139 (as in 232) instead of playing from the cloud of the Internet radio service provider as in 142.

In particular, all resources, whether local or remote, are indexed to enable quick matching. After streaming 232, the use of the local file is reported to the compliance server 143 as at 233. Labels may require Internet radio service providers to pay a small fee when streaming 232 local files 139 because there is no way to ensure that files are not pirated. As a result of efficient resource allocation according to the server 141, the Internet radio service provider 140 will not have to pay for the bandwidth or for the entire licensing, and this cost reduction can then be transferred to the Internet radio service provider. .

FIG. 20 shows a file that a listener is listening to on a non-interactive Internet radio service provider channel and is not available on the listener's device but is available on the peer 141 in the peer-to-peer network 144 according to the present invention. It attempts to illustrate a scenario when the service provider client 140 is ready to stream (as in 230). Although there is no loyalty reduction for the Internet radio service provider, the peer-to-peer network 144 according to the present invention saves the bandwidth and replaces the file 139 with the Internet radio service provider as shown in 233. Send to the service provider. Thereafter, the server 141 may report at 233 what song has been played to the compliance server 143 if necessary.

Fig. 21 attempts to show a scenario when a listener creates a 10-song playlist in a media streaming service provider account as at 145 for a special event. The listener is the restaurant owner or manager, and the event is a public event in a commercial setting. The media streaming service provider account 145 does not allow a commercial environment, and while three songs can in fact be downloaded to a local device via the listener's cloud storage locker, the purchased media license agreement is also in a commercial environment. Do not allow transmission.

The commercial licensing provider device 146 is installed on the premise that it has the legal right to broadcast all 10 songs, but only 5 of the requested playlists of 10 songs available on the provider's locally installed device 146 Exists. The system according to the present invention synchronizes playlists made in the media player 145 of the media streaming provider, matches the files available in the Vertigo cloud and the missing files (as in 231), The songs are transmitted to the licensing provider's device 146 (234). These transmissions may come from Vertigo's peer-to-peer network 144 depending on the bandwidth cost. All transmissions and streaming can be reported 233 by server 141 to compliance server 143 to track the number of times the song has been played (if necessary).

In the scenario shown in FIG. 24, streaming provider 147 requests song 151 to be played on mobile device 148. The request is sent from the mobile device application 149 on the mobile device 148 and sent to the remote server 150 according to the present invention. When the mobile device 148 requesting the song 237 is linked as in 235 to the personal computer 152 having the locally stored file, the request for the song is sent to the data origin server 147 (i.e., the streaming provider's server). Rather than routing to ), the request is sent to personal computer 152 and streamed from personal computer 152 to mobile device 148 as at 236. In this situation, no additional streaming rights are required and no bandwidth cost is incurred. If the request 237 is transmitted to the remote server 150 according to the present invention and the file does not exist in the linked personal computer 152 or in the cloud, the request 237 is transmitted as in 238 to the data origin 147 And then the data origin 147 can stream 239 the file to the device 148.

In the scenario shown in FIG. 25, the streaming provider 147 requests that the song be played on the mobile device 148. The request is sent from the mobile application 149 on the mobile device 148 and sent to the remote server 150 according to the present invention. When the mobile device 148 is requesting the uploaded song as in 240 from the personal computer 152 linked as in 235 to the cloud service 153, the remote server 150 sends the request 237 to the cloud locker. Or routing 236 to service 153. In this case, no licensing is required, but bandwidth charges will apply. If the request 237 is sent to the remote server 150 according to the present invention and the file does not exist in the linked personal computer 152 or in the linked cloud 153, the request is made at 238 to the data origin 147 and And then the file can be streamed to device 148 as at 239.

The server 150 according to the present invention, and its smart music routing engine, as described in the previous examples, in terms of bandwidth and loyalty costs, including but not limited to resources such as Examples 1-6 above. In addition to selecting songs from the least cost transmission points, it evaluates the compliance aspects of these transmissions and also reports this activity for royalties.

Referring to Figures 22 and 23, the reader will consider some sub-licensing configurations in accordance with the present invention. The use of a local gateway server for automated sub-licensing of streamed content relies on agreements between the copyright holder and the content bearer (ie, streaming service provider). A situation is described below in which a streaming provider may have an agreement requiring sharing a portion of the revenue obtained from streaming licensed media. In particular, there may be a requirement that a streaming provider can operate as a wholesaler under such a license.

The first case scenario is shown in FIG. 22. In this case, the streaming service provider 155, in response to a request for the provider 155 to set predetermined parameters that enable the local server 150 to stream 241 at an optimal price, the local gateway server ( 150). This indicates that the server 150 can stream from a sub-licensed account as at 156. In the figure, there are three sub-licensed accounts referred to as 157, 158, and 159.

If the request comes from a client application 155, the local server 150 determines at 242 whether the sub-licensing account (selected from accounts 157-159) has the optimal licensing cost for a given request 241. Decide like this. The song is then streamed 234 from the cloud of sub-licensors (eg, from account 157). The streaming provider then receives an invoice as at 244 on behalf of the sub-licensor 157. Billing includes licensing fees and streaming fees based on sub-licensors' licensing agreements. Thereafter, the sub-licensor pays 245 royalties to the author 160, and maintains the money needed to cover the cost of the streaming and the profits obtained from the transaction.

In the second case as shown in Fig. 23, the main difference lies in how the cost of streaming is covered. Since the data is streamed 246 from the peer-to-peer network 161 according to the present invention, the fees associated with using the peer-to-peer network 161 are the service provider 162 that owns the network 161 Is paid 247, after which the cost of the licensing is passed 244 to the sub-licensor 157, which pays 245 royalties to the copyright holder 160 and holds the profits obtained from the transaction.

Since the local server 150 tracks and reports the stream, that is, who streams from where (which sub-licensor), the above sub-licensing cases are possible, and as a result, it is possible to properly route royalties payments. The system's uniqueness does not allow such tracking, but it has access to peer-to-peer networks and can still report such usage. While the second case scenario presented above is only possible with the local gateway server 150, the first scenario may occur in the form of a standard server for server requests, or some form of rewrite or redirect.

Certain licensing benefits/benefits by using local server content are self-evident according to the present invention. In this regard, if the song exists on a local server controlled or owned by the end user of the service, the local media usage is in the state of playback. This will already be a title or album in the user's personal media library account or in any part of the local computer. Such content could be placed there as a purchase, download, or gift. It is not the responsibility of the owners or service providers of the system/method to verify the legitimate sourcing of local files on the end user's computer.

The streaming provider will not perform, distribute, or duplicate locally controlled sound recording or music creation. Thus, no rights are used, and no additional license fees are required for calculation or reporting. The key is to be able to quickly and accurately identify these tracks so that they do not interfere with the end user's experience.

The use of media from the server according to the present invention occurs when a song licensed at a more desirable fee from the owner of the system/method can be used in place of a song from a streaming provider. This is made possible by licenses created directly using the content controller. These new direct agreements provide a more transparent loyalty structure and a process for reporting directly to the artist.

In addition, Direct Licensing considers both interactive and non-interactive use that form more than a "one-stop" relationship for online use. In addition, the consensus will provide a unique loyalty payment calculated by the savings gained from transmission efficiency. There is currently no agreement to convey some of the savings made by shared files back to the industry.

The advantage of using these files for streaming providers stems from the reduced loyalty rate over mutual and non-interactive use. All performance and listening times calculated from the use of these titles will be achieved with standard "full-rate" loyalty calculations, and will also be based on more favorable rates.

The use of controlled peer-to-peer media occurs when the file is placed in the secure cache of the controlled user server, and can also replace the scheduled file for playback per streaming provider's data supply. There is no cost savings from the royalties fee, but there are transfer savings that are beneficial for artists under direct license under the present system and method. Thus, the more titles that can originate from this secure cache, the greater the advantage for both the streaming provider and the music industry.

Below is a breakout of a sample month programming from a virtual streaming provider. The breakdown is not only the savings associated with the use of multiple sources of content, but also how the unique compliance calculation process is important to the overall savings process.

The compliance engine and reporting tool has the ability to retrieve the following information:

1) Usage reports based on specific specifications required by all Performing Rights Organizations. These specifications include the following items.

a. Provides unique reports per platform (stream provider)

b. Provides the ability to securely enter revenue information per streaming provider based on platform type

c. Usage reports per unique user session to generate average listening time totals, Per play totals, and per listening session totals.

d. Ability to aggregate all usage and revenue information into separate usage reports for each SP and PRO

2) Usage specifications for sound exchange reporting and payment

a. Provides unique reports per platform (stream provider)

b. Provides the ability to securely enter revenue information per streaming provider based on platform type

c. Usage reports per unique user session to generate average listening time total, total per play, and total per listening session

d. Ability to aggregate all usage and revenue information into separate usage reports for each SP

3) Record Labels and General Usage Specification for Publishers-Used for interactive use

4) Authorization module "Compliance Dashboard"-

Ability to change permissions, loyalty rates, clearance status and usages approved by the content controller for various types of consensus in bulk or individually (per media asset):

a. Record label license agreement

b. Residential License Agreement

c. Advertisement license agreement

d. Multi-platform license agreement

e. Bundled authorization agreement

f. Loyalty sharing agreement (publishing management)

g. Waiver/gratis

5) Ability to provide individual and aggregated accounts with all of the reporting requirements above across all separate platforms and services for each of the following "content source types"

a. 100% streaming provider (SP) content

b. Local server content

c. Controlled P2P content

d. Vertigo Licensed Content

6) Loyalty Calculation Engine-The system has the ability to calculate owned royalties by combining usage data for each data range, content source type, and streaming provider based on rates entered in the compliance dashboard. The following calculations will be used for carve outs of local server content. X/X+Y×(per play or streaming time rate) = total loyalty. X=local server content and Y=streaming provider content

The ability to accurately calculate and report on groups, stores, and sources of all rights, calculate the use of controlled and proprietary content, and consolidate transmission cost savings with total royalties makes this a type of compliance service.

This part of this specification discloses how the local gateway server could be used to make the Internet stream of conventional radio stations more efficient and also to improve the quality of the streamed audio. The present invention, more precisely, this part of the specification is not focused on talk shows, sports broadcasts, and the like, but on radio broadcasts that mainly play music. Due to the fact that music based on radio broadcasts is a mix of live audio and pre-recorded audio, significant savings can be obtained, and the quality of the audio can also be significantly improved.

Pre-recorded audio is separated from the live audio or studio mix, and locally via a peer-to-peer network or via local file systems (metadata file matching systems will be used to ensure that the appropriate song is playing). Significant savings and improvements in audio quality can be achieved if they can be transmitted to a computer. The pre-recorded audio and studio mix can then be mixed on the local computer to ensure consistent broadcast content and quality. This specification will explain how this can be achieved.

Existing methods of streaming radio over the Internet are generally shown in FIG. 30. Current methods of transmitting radio streams over the Internet typically use the use of a media playback device (e.g., a personal computer in general) as in 163 playing pre-recorded audio (music tracks, advertisements, etc.). And outputs 248 audio to the sound board 164. This audio is then mixed with the disc jockey's utterances and/or commentary, and other live audio 165 that is input 249 to the soundboard 164 both in the studio or recording system 170.

The soundboard mix is then output as at 250 to computer 166 as a single stream of audio. The computer 166 then compresses the audio stream and outputs the audio stream to a compressed audio file 167 (which is usually an MP3 file). As the file is live streamed and new data is constantly appending to the end of the file, this MP3 file does not have a set duration. This MP3 file is typically located on a content delivery network 168 and a computer 166 that compresses and trans-codes an audio stream that attaches 251 the file with new data upon compression. do. The content delivery network 168 then distributes 252 this file to the clients 169. Also, this is a simple system overview and is likely to be similar to most configurations on the market.

An improved system of a gateway server according to the invention is shown generally in Figs. 26-29. The improved system starts with computer 163 and radio studio 170 outputting 248 pre-recorded audio to soundboard 164. The computer 163 according to the present invention will have certain event maker related means that are enabled upon installation or application, as exemplified by the patented software.

1. Disc jockey cueing songs for broadcast; The software creates a song queue 171 that is distributed to clients 172, and the clients 172 stream the broadcast. The cue 171 contains songs that the disc jockey plans to play while on air. The local server 184 preloads 253 these songs so that when the disc jockey decides to play the song the song will be made available to the client 172 for playback. These songs may be transmitted via a remote content delivery network client 173, a peer-to-peer network client 174, or matched and streamed from a local file system 175.

2. The software also compresses the audio output 176 returning from the soundboard 164 as at 256. In addition, the software inserts event indicators in the frame headers 177 of the audio stream 179. Each MP3 audio stream/file 179 consists of audio frames 178, and each of the audio frames 178 has a header 177. As new audio is added, new frames 178 are attached to the file. These headers 177 are 32 bits long. Within each header 177, there are bits reserved for dedicated application use. This bit will be set to "1" at the start of the event and "0" during periodic streaming. This data will be inserted into both streams 176 and/or 256 coming from soundboard 164. In addition, each header 177 only provides information and contains bits (eg, "copyright", "original") that do not affect the audio reproduction. Each header 177 has at least 3 bits (including dedicated bits) that do not affect audio reproduction. These bits can be used to generate the event ID. The ID will be generated by using these bits to form a combination of "0" and "1" to enable an ID that is unique enough to accommodate enough events to fill a 10 second replay. Thus, if a frame header with the original even indicator bits is used with the frame header, what is done immediately, which is used as a sum of at least 5 bits, can be used to generate at least 32 or 2 ⁵ unique markers. This should be more than enough unique markers to cover enough events for a possible 10 second delay. If more markers are needed, another header can be added to increase the total from 32 to 256. Since each event has a unique marker within a 10 second frame, these markers are fully remotely mixed streams and locally mixed streams (live audio streamed from the studio, and mixed from event markers to stream by the local server). It can be used to synchronize two separate streams (one containing only live audio and the other will be a full mix) to handoff and transition to a pre-recorded stream of audio). Event markers will also be linked to the mixing instruction to mimic the audio mix from the studio.

3. The application also creates an event queue. This would be a queue of events matching event markers based on the unique bit ID following the marker (as described above). These events will be recorded on the computer 163 compressing the audio so that the events occur and the timing of the events is inserted into the live audio stream 256 at the exact location where the events occur in the original studio mix 176. Each event is registered at the correct frame 178 to ensure that it is. These events will contain information on:

a. What pre-recorded audio needs to be played in the event marker

b. At which frame playback starts for pre-recorded audio

c. At what volume playback should start

d. If the volume was gradually fading in, the equation best matches the slope and direction of the volume fade in/out. This will be used to mimic the studio fade in/out. This information is output to the soundboard 164 as a peripheral fader 180 that allows the disc jockey to control the audio 257 and report changes in the volume back to the computer 163. Can be recorded by

e. End of event (this is normally required to record when fade in/out stops)

f. Beyond that, this is just an example of the most similar types of events.

4. The application also updates 258 live audio stream files 181 and full mix files 182 on a remote server or content delivery network 150.

When two streams 181/182 are recorded and encoded by an application in studio 170 at computer 163, both files 181/182 are for transmission 259 to clients 172. It is uploaded 258 to a content delivery network or remote server 185. Client-side application 183 (eg, browser, etc.) sends requests for radio streams by using a properly formatted URL. The URL can be structured as a subdomain of the main domain name, for example a URL in this format can be used to refer to the radio station stream radiostation.vertigomusic.com/[show id]. If the Vertigo gateway server 184 is not installed, this URL will cause the client to refer to the fully mixed studio stream 182 and will play the file in the same manner as the conventional Internet radio stream (see above and Fig. 30). .

Once the Vertigo gateway server 184 is installed, the server 184 registers its sub-domain name with itself and then processes all requests for the sub-domain name from the local client application 183. In this case, if a request for the stream is made by the client application 183, the request is provided by the gateway server 184 (260). The gateway server 184 starts by providing a fully mixed stream 182 from the remote content delivery network 185. When the stream starts, the gateway server 184 requests a pre-recorded audio queue 171 and from peer-to-peer 174, remote content delivery network(s) 173, or local sources 175. Begin caching 253 pre-recorded audio. The gateway server 184 also loads 261 an event queue from a remote database 186 that is constantly updated by the studio computer 163. The gateway 184 will continuously receive updates of the events 261 while the stream 181 is in progress.

For the transition from the full studio mix 182 to the live audio only stream 181, the gateway server 184 loads both streams 181 and 182 and only provides a full mix 182. To ensure that the gateway server 184 and mixing application 187 have enough time to complete all tasks, the server 184 starts a stream 10-20 seconds from receiving live data, mixing and transitioning. It creates a custom lag that is used to generate time for the running system. The gateway server 184 waits for an event bit in the frame headers 177 of the full studio mix 182 to transition to the live audio stream 181.

The gateway server 184 sorts the two streams 181/182 into event bits. This is done by matching the bit code after the event bit. If the bit code matches both events, the events are considered to match because only the last 10-15 seconds of the stream are searched. The 32 unique bit codes provide enough uniqueness to ensure that the matched events are virtually identical. Once the event bits are matched, the gateway server 184 transitions from the full studio mix 182 to the live audio mix 181 in the frame 178 in which the event bit occurs. Using this method provides a smooth transition from stream to stream with frame-to-frame accuracy.

Once the gateway server 184 has transitioned to the live audio-only stream 181, it starts following mixing instructions stored in the database 186 of events when an event bit appears. Because only the last 10-15 seconds of the live stream are tracked for event bits, the bit code is used to place the event data in the database 186 matching the event bit code.

Thus, assuming that the first event was for the playback of the first song in the prerecorded audio cue 171, the application would have already cached at least 10-20% of the audio. In this case, the gateway server 184 delivers the live audio stream 181 and the pre-recorded audio data 188 to the internal mixing application 187 (which may be an SoX similar to a command line application or a custom built application). .

In addition, the gateway server 184 transmits 261 the mixing data to an application that mixes the live audio stream 181 and pre-recorded audio to imitate the full studio mix 182. This is recorded in the studio 170 and is done by using data associated with the event to mimic the fading and timing of the disc jockey. The application 187 then outputs a locally mixed new file 189 that is provided to the requesting client 183. This can all be done smoothly, as the server can create significant delays between sending live data and providing data to the client application. As long as this delay is created at the beginning of the audio presentation, this delay interval can be used to mix and prepare the audio.

If the radio station or show only incorporates advertisements and does not mix the live stream with pre-recorded audio (e.g. music), the system will also be shown generally in FIGS. 31 and 32 as described below. Consider some advertising consolidation means that works as follows.

The radio show can be recorded on the computer 190 via software 191 that encodes the audio and indicates when an advertisement or other pre-recorded file should be played. The advertisement indicators are placed after a predetermined time of audio silence. To achieve this, the encoding application 191 creates a delay 300 that is several seconds longer than a predetermined advertisement indicating audio silence 301. So, if a radio celebrity is recording and needs to insert a commercial break, the radio celebrity simply mutes or silences the microphone for 5 seconds, as in 301 (for example). After 5 seconds of silence (as in 301 as an example), the encoding application marks the audio stream at the start 303, not at the end 302 of the 5 seconds silence. Thereby, the final listener hears the advertisement, not silence.

If a predetermined period of silence has passed, the application 191 allows the radio celebrity to indicate how long the advertisement should be played, and the advertisements are consolidated according to the selected period. This audio stream is then encoded and displayed by the application 191 and uploaded to a server or content delivery network 192 of which the radio celebrity chooses.

When a listener from the device 193 requests a radio stream through the client application 194 (eg, a browser or mobile application), the request is sent 270 to the gateway server 195. The gateway server 195 transmits (271) a request for an audio stream to the cloud/server 192 that transmits 272 audio to the gateway server 195 in response.

Thereafter, the gateway server 195 delivers (293) the audio stream to the client 194. When an advertisement indicator is identified within the audio stream, the gateway server 195 is a small buffer (2-) so that the gateway server 195 can fetch 274 the appropriate advertisement from the advertisement server 196 and integrate it at a specific time. 5 seconds of data). In a mobile application, the application would have to integrate advertisements without gateway server 194. The mobile application will have to be integrated into the application's source code. Thus, the mobile application will have code that detects the advertisement indicator and then incorporates the advertisement at the beginning of the advertisement indicator.

Although the above description includes many features, these features should be regarded as illustrative of the invention, not as limitations on the scope of the invention. For example, it is contemplated that the present invention necessarily provides a peer-to-peer (P2P) content delivery network for delivering (eg, streaming) selection data files to end users.

The so-called P2P content delivery network (CDN) or P2P CDN according to the present invention includes a client as in 2, a P2P gateway server as in 3, a resource name server (RNS) as in 4, and a computer-populated network (a computer-populated network), wherein the computer-populated network is a local server, a peer-connected server, a cloud locker, a cloud storage, a cloud media, and/or an advertisement (music) streaming service providing infrastructure(s). ) Can be included.

The client communicates with the P2P gateway server, and the P2P gateway server communicates with the RNS and computer-populated network. RNS basically caches data resource locations within a computer-populated network, and provides optimal (e.g., (a) most cost effective or (b) highest sound quality of the source) within the computer-populated network. ) Basically works to resolve resource requests with data resource locations.

The P2P gateway server requests and receives optimal data resource locations via RNS; Request and receive data files from the computer-populated network using optimal data resource locations, and process the received data files for data file transfer to clients and end users.

The content delivery network or CDN according to the present invention is optional but preferably add-on, including predetermined client and/or server authentication means for verifying the authenticity of the client and/or server, as described in more detail above. -on) integrates multiple components of the base system. Further, in an effort to improve the transmission of intact data streams, the present invention contemplates some means of data transmission fragmentation as also described above.

The resource locations can be preferably indexed via some resource indexing means cooperating in connection with the RNS to further improve the network or method efficiency. In particular, the resource indexing means may preferably include a predetermined file matching means for quickly and effectively matching data files independently of the data file metadata. The file matching means according to the present invention is more fully specified in the licensed U.S. Patent Application No. 13/065,254, currently issued U.S. Patent No. 8,589,171, in which these specifications are claimed to be beneficial. Included for reference.

Accordingly, the file matching means according to the present invention preferably comprises a predetermined data extracting means, a predetermined summary statistics derivation means, a predetermined custom indicator generating means, a predetermined custom indicator association means, and a predetermined custom indicator access means. Can include.

The data extracting means extracts waveform data from the first data file. The extracted waveform data includes length segment values, these values are extracted in relation to the data extraction baseline and include trough-to-baseline and peak-to-baseline length segment values. . The summary statistics derivation means derives summary statistics from the extracted waveform data, wherein the summary statistics are derived from length segment values and include trough-to-baseline and peak-to-baseline length segment statistics.

The custom indicator generating means generates a custom indicator based on the derived summary statistics, and the custom indicator association means associates the custom indicator with the first data file, thereby constructing a custom displayed data file. The custom indicator access means accesses the custom indicator when comparing the second data file with the displayed data file in order to make a positive data file match.

The P2P content delivery network may further include predetermined event indicator association means for associating the event indicator in the frame header of the data file to improve the data file transmission described in more detail above. In this last point, the reader will be reminded that the present invention further considers certain advertising integration means, which means are further adopted to integrate advertising content into data files via specified event indicator association means. Can be.

In view of the characteristics irrelevant to the data origin of the present invention, a data routing control system is additionally considered. The data routing control system according to the present invention preferably includes a data routing compliance device or engine in combination with the described content delivery network. Thus, the data routing compliance device communicates with a content delivery network, the content delivery network comprising a plurality of data sources including or storing data files.

The content delivery network transfers selected data files from the optimal data source location to the end user, with the optimal data source location selected from the group consisting of data sources. Accordingly, a compliance device or engine according to the present invention provides (a) industrial rights management (b) compliance monitoring and/or (c) compliance reporting of data file transfers.

Fundamentally, the present invention is to (1) deliver an indirect request stream from a local server (eg, a digital radio exemplified by PANDORA® radio); Deliver an indirect request stream from a peer-connected server; Deliver an indirect request stream from a second direct request source (eg, a cloud locker such as iTunes Match or Spotify or DropBox or any media in the cloud); Deliver the indirect request stream from the peer-connected server based on the rights to the playback or stream of the second direct request source; deliver an indirect request stream from a second direct request source based on (a) cost effectiveness or (b) sound quality of the source; (6) It can be said that it provides a function of delivering a request stream directly from a peer-connected source based on the playback of the second direct request source or the right to the stream. Given the data origin-independent or cloud-independent aspects of the present invention, the system can be used to: (a) manage industrial rights (b) monitor compliance and/or (c) source the original requested source including Examples 1-6 above. In addition to the service, the delivery of content provides compliance reporting provided by secondary sources.

The preceding specification is further believed to support certain fiducial-independent data transfer methods for optimally (eg, cost-effectively) delivery of selection data to end users in a computer-populated environment. The fiducial-independent data transmission method according to the present invention comprises: communicating a client, a peer-to-peer (P2P) gateway server, and a resource name server (RNS) with a computer-populated network; It can preferably be said to include caching data resource locations in the computer-populated network via RNS.

Optimal data resource locations may be requested by the P2P gateway server via the client from RNS cached data resource locations, and resource requests are resolved to the optimal resource locations via RNS. Optimal resource locations are received by the P2P gateway server via the RNS, after which data files from the computer-populated network are either requested or received using the received optimal resource locations. Requested as made possible by The requested data files are then transmitted (ie, transmitted/received) and processed for data file transfer to the client.

Claims (33)

A routing and synchronization system operable with one or more data sources to selectively transfer synchronized data files to users in real time, comprising:
A resource name server (RNS), a gateway server, and a client capable of cooperating with synchronization and routing means, which communicates with a computer-populated network,
The RNS (1) caches the data resource location in the computer-populated network, (2) resolves the resource request using the optimal data resource location in the computer-populated network,
The gateway server (1) requests and receives an optimal data resource location through the RNS, (2) requests and receives a data file from the computer-populated network through the optimal data resource location, ( 3) process the received data file for data file transmission to the client,
The synchronization and routing means synchronize and route synchronized, consumable, legally-protected data from a optimal data resource location to the client for consumption. By doing so, it is operable to respond to reciprocal requests and non-reciprocal requests,
The optimal data resource location is selected from a routing instruction fulfillment source prompted by a routing instruction received from a routing instruction generating source,
The routing instruction fulfillment source and the routing instruction generation source are each affiliated with a legitimate access point,
The synchronized, consumable and legally protected data is sourced from a data library to the consumer.
Routing and synchronization system.
The method of claim 1,
The routing instruction fulfillment source is associated with at least two fulfillment-based legitimate access points.
Routing and synchronization system.
The method of claim 1,
The synchronized, consumable and legally protected data is supplied to consumers from the data library controlled by ID-hash mapping
Routing and synchronization system.
The method of claim 1,
Data transmission fragmentation means operable through the RNS for (a) fragmenting the data, (b) transmitting the fragmented data, and (c) enhancing the transmission of a non-corrupt data stream. Containing
Routing and synchronization system.
The method of claim 1,
A resource indexing means operable through the RNS for indexing the resource location and thus improving network efficiency of the routing and synchronization system
Routing and synchronization system.
The method of claim 5,
The resource indexing means further operates to improve network efficiency of the routing and synchronization system by matching data files separately from data file metadata.
Routing and synchronization system.
The method of claim 1,
Routed, synchronized, consumable, legally-protected data content (routed, synchronized, consumable, legally-protected data content). Including compliance devices that manage, monitor and/or report data file transfers of legally protected data.
Routing and synchronization system.
The method of claim 1,
And event indicator association means for improving data file transmission by associating event markers in the frame header of the data file.
Routing and synchronization system.
The method of claim 8,
The event indicator association means is operable to incorporate advertising content into a data file.
Routing and synchronization system.
An origin-agnostic data transfer method for transferring a legally protected data file to an end user from an optimal resource location selected from one or more data sources in a computer-populated environment, comprising:
Communicating with a client, a gateway server, and a resource name server (RNS) within a computer-populated network,
Caching data migration sources in the computer-populated network via the RNS;
Requesting a data fulfillment source listing from RNS-cached data fulfillment sources through a routing instruction generation source, by the Singgi gateway server;
Querying which of the data fulfillment sources best meets user-defined data transfer requirements-an optimal transition source is defined by the query; and
Requesting a data file that is legally protected from the optimal transit source over the computer-populated network, the data file that is legally protected is supplied to the client from a data file library; and
Transferring the legally protected data file from the optimal source of fulfillment;
Processing the transmitted legitimately protected data file for transmission to the client.
Origin-independent data transmission method.
The method of claim 10,
Including the step of verifying the authenticity of the client (authenticity)
Origin-independent data transmission method.
The method of claim 10,
Including the step of verifying the server authenticity
Origin-independent data transmission method.
The method of claim 10,
Fragmenting the data file during data file transfer to improve the transfer of the intact data stream.
Origin-independent data transmission method.
The method of claim 10,
Including the step of indexing the resource location to improve the method efficiency
Origin-independent data transmission method.
The method of claim 14,
Matching the data file separately from the data file metadata to improve method efficiency.
Origin-independent data transmission method.
The method of claim 15,
The step of matching the data files,
Extracting waveform data from a first data file-the extracted waveform data includes a length segment value, and the length segment value is extracted in relation to a data extraction baseline and trough-to-baseline -to-baseline) contains length segment values and peak-to-baseline length segment values-and,
Deriving summary statistics from the extracted waveform data-the summary statistics are derived from the length segment values, and the summary statistics are trough-to-baseline length segment statistics and peak-to-baseline length Includes segment statistics-Wow,
Generating a custom marker based on the derived summary statistics, and
Building a custom marked data file by associating the custom indicator with the first data file; and
Accessing the custom indicator when comparing a second data file to the custom marked data file to render a positive media file match.
Origin-independent data transmission method.
The method of claim 10,
Providing (a) industry rights management, (b) compliance monitoring, and/or (c) compliance reporting for data file transfers of routed and lawfully protected data from at least two data resource locations, Said (a) industrial rights management, (b) compliance monitoring, and/or (c) compliance reporting is for the owner or representative of the owner of the lawfully protected data file.
Origin-independent data transmission method.
The method of claim 10,
Associating an event indicator in the frame header of the data file to improve data file transfer.
Origin-independent data transmission method.
The method of claim 18,
Incorporating the advertising content into the data file.
Origin-independent data transmission method.
As a data-routing governance system that controls and reports data routing within the content delivery network,
Including a data routing compliance device in communication with the routing and synchronization system,
The routing and synchronization system (a) is operable with (b) one or more data sources within the content delivery network,
The content delivery network includes a plurality of routing instruction fulfillment sources each including a data file,
The content delivery network transfers the data file from the optimal data transition source induced by the routing instruction generation source to the end user,
The optimal data transition source is selected from a group comprising the plurality of routing instruction transition sources,
The routing instruction fulfillment source and the routing instruction generation source each define a legitimate access point,
Each legitimate access point is associated with a data file library,
The data file is supplied from a data file library to the end user,
The compliance device may provide (a) industrial rights management, (b) compliance monitoring, for data file transfer of routed and legally protected data from an optimal data source location to the owner or representative of the owner of the data file, and /Or (c) providing compliance reporting
Data routing control system.
A routing and synchronization system operable with one or more data sources within a network-based media content playback environment to provide a selectively sourced media content broadcast to a consumer,
Synchronizing and routing means for synchronizing and routing media content consumable and legally protected to the consumer from a routing instruction fulfillment source induced by a routing and playback instruction generated through a routing instruction generation source,
The routing instruction fulfillment source is associated with at least one legitimate access point,
The synchronization and routing means (a) generate the routing and playback instructions through the routing instruction generation source to control playback of the consumable and legally protected media content through a primary channel for content delivery, (b) establish a secondary channel for instruction delivery to the consumer through an operable network infrastructure, and (c) supply the consumable and legally protected media content to the consumer from the at least one legitimate access point. Operable to deliver the routing and playback instructions to the consumer via a secondary channel for delivery of instructions to
Routing and synchronization system.
The method of claim 21,
The selectively supplied media content broadcast is a direct source transmission of the consumable and legally protected media content to the consumer from a consumer-accessible content library derived by the routing instruction generation source. Characterized by
Routing and synchronization system.
The method of claim 22,
The routing instruction generation source is an initialization source, and the initialization source is selected from the group consisting of an incoming indirect source and a consumer-associated direct source.
Routing and synchronization system.
The method of claim 23,
The consumable and legally protected media content is supplied to the consumer controlled by a predefined parameter,
The predefined parameter is selected from a parameter group comprising a price efficiency parameter and a data quality parameter,
The price efficiency parameter controls media playback from a cost effective content library, and the data quality parameter controls media playback from a high quality content library.
Routing and synchronization system.
The method of claim 23,
The consumer-associated direct source is peer-connected and the consumable and legally protected media content is provided to the consumer based on the legal right of the consumer-associated direct source to supply the consumable and legally protected media content Integrated
Routing and synchronization system.
The method of claim 21,
(a) industrial rights management, (b) compliance monitoring and/or (c) compliance devices that provide compliance reporting,
The compliance device manages, monitors and/or reports the transmission of the consumable and legally protected media content to the owner or agent of the owner of the consumable and legally protected media content.
Routing and synchronization system.
The method of claim 21,
File matching means operable to identify the content derived by the routing instruction generation source, and to determine the routing instruction fulfillment source by querying the existence of a matching file from the at least one legitimate access point.
Routing and synchronization system.
The method of claim 21,
The synchronization and routing means are operable to associate an event reference with the routing and playback instructions,
The event reference and the routing and playback instructions together provide the consumable and legally protected media content to the consumer from a content library.
Routing and synchronization system.
The method of claim 28,
During the encoding process, the event reference and the routing and playback instructions are accepted into a custom media format.
Routing and synchronization system.
The method of claim 21,
The routing and playback instructions are associated with a file location, and the file location is selected from a location group consisting of a file start location or a file end location.
Routing and synchronization system.
The method of claim 21,
The routing and playback instruction is timed metadata
Routing and synchronization system.
The method of claim 21,
The routing and playback instructions are subject to multiple playback events, and the multiple playback events include (a) play, (b) pause, (c) stop, (d) load, (e) search, (f) comment. , (i) comment start, (ii) comment end, (g) audio mix, (h) playback speed, (j) playback direction, and (k) content identification.
Routing and synchronization system.
As a non-transitory computer-implementable media content-sharing system,
The non-transitory computer-implementable media content sharing system includes selectively supplied media content to a consumer having access to a first of the at least two computers within a network-based media content playback environment including at least two computers Operable to provide broadcast,
The non-transitory computer-implementable media content sharing system includes and provides computer-implementable instructions, wherein the instructions,
(a) open a secondary channel for delivery of instructions to consumers through an operable network,
(b) create routing and playback instructions that control the playback of consumable and legally protected media content through the primary channel for content delivery,
(c) delivering the routing and playback instructions to the consumer through a secondary channel for delivery of instructions to supply consumable and legally protected media content to the consumer from at least one legitimate access point.
Non-transitory computer-implementable media content sharing system.

Images