BR112016012893B1 - Método de entrega de dados de origem agnóstica, sistema de governo de roteamento de dados e rede de entrega de conteúdo - Google Patents

Abstract

MÉTODO DE ENTREGA DE DADOS DE ORIGEM AGNÓSTICA, SISTEMA DE GOVERNO DE ROTEAMENTO DE DADOS E REDE DE ENTREGA DE CONTEÚDO. Uma rede de entrega de conteúdo peer-to-peer (P2P) entrega arquivos de dados selecionados para um usuário final. A rede de entrega de conteúdo provê um cliente, um servidor gateway P2P e um Resource Name Server (RNS) dentro de uma rede habitada por computador. As localizações de recurso de dados de cache RNS dentro da rede habitada por computador e resolve solicitações de recursos, com localizações de recurso de dados ideais dentro da rede habitada por computador. O servidor gateway solicita e recebe localizações de recursos de dados ideais através do RNS; solicita e recebe arquivos de dados a partir de rede habitada por computador através das localizações de recursos de dados ideal; e processar arquivos de dados recebidos para entrega de arquivos de dados para o cliente. A rede permite, portanto, um método de entrega de dados de origem agnóstica para entregar otimamente arquivos de dados selecionados a um usuário final. Uma utilidade de administração ou de governo de roteamento de dados administra/governa a rede de entrega de conteúdo e metodologia associada para prover (...).

Description

FUNDAMENTOS DO CAMPO DE INVENÇÃO DA INVENÇÃO

[0001] A presente invenção se refere, geralmente, a rede de entrega de conteúdo e metodologia associada que provê um mecanismo de conformidade de mídia. O mecanismo de conformidade de mídia, de acordo com a presente invenção, opera por meio de servidores de gateway local, os quais utilizam redes peer-to-peer e múltiplas origens de dados (nuvens) para otimizar a entrega de mídia e agilizar o processo de geração de relatórios. O mecanismo de conformidade de mídia, de acordo com a presente invenção, corresponde a requisitos de provedores de transmissão com uma fonte de dados otimizados e rede. Ao fazer isso, o mecanismo de conformidade de mídia pode minimizar o consumo de largura de banda, licenciamento e custos de emissão de relatórios.

RESUMO DA INVENÇÃO

[0002] A presente invenção provê uma Rede de Entrega de Conteúdo peer-to-peer (CDN) que pode ser adicionada a qualquer rede de entrega de conteúdo padrão existente, ou configuração do servidor, sem quaisquer alterações de sistemas de back-end. O CDN peer-to-peer, de acordo com a presente invenção, é criado quando o utilizador final instala um servidor de gateway peer-to-peer local na máquina do cliente. O servidor gateway recebe requisito(s) do cliente que consome mídia através de conexões criptografados ou não criptografadas (por exemplo, HTTP, HTTPS, Secure Socket, ou socket).

[0003] O servidor gateway local atua como um peer na rede peer-to- peer e tem um cache criptografado para armazenar dados para entrega a outros peers ou para entrega local para um cliente que consome dados. O servidor de gateway local também pode tirar recursos de uma fonte de dados remota relacionada (por exemplo, um servidor ou outro CDN). O cliente que consome precisaria, apenas, passar um único requisito para o servidor gateway e o servidor gateway gerenciaria os recursos e a conexão de rede, independentemente do cliente. Este tipo de configuração permite a entrega de mídia não apenas para aplicativos desktop stand-alone, mas também para os navegadores e reprodutores de mídia e aplicativos móveis que têm capacidades de navegadores da web padrão (por exemplo, HTTP, HTTPS, e/ou socket).

[0004] A presente invenção provê um servidor gateway peer-to-peer (P2P) que recebe comunicação de um cliente em uma máquina local. A comunicação ou o requisito pode ser formatado como um requisito HTTP padrão direcionado no servidor gateway local, o qual será registrado com um nome de domínio local. Está previsto que o(s) requisito(s) podem ser formatado(s) diferentemente, se um novo protocolo de transferência é criado que faz referência a uma porta reservada onde residiria o servidor gateway. Neste caso, o requisito seria formatado ligeiramente diferente (ou seja, sem o prefixo HTTP).

[0005] A invenção provê um Servidor de Nome de Recurso (RNS), cuja URL do recurso de cache RNS e locais de recurso (ou seja, endereços IP) e resolve requisitos de recursos com endereços de máquina. O processo geral ou metodologia para um tipo de mídia não-combinado seria da seguinte maneira. 1. Cliente envia um requisito de recursos para o servidor gateway; 2. O servidor gateway então envia o requisito para o RNS para resolver o requisito de recurso com um endereço de recurso; 3. Uma vez que o requisito de recurso é combinado com as localizações de recurso ideais (menos caras), os dados de localização do recurso são retornados para o servidor gateway; 4. O gateway, em seguida, envia o requisito para dados de recurso para as máquinas apropriadas ou clusters de servidores; 5. As máquinas ou clusters de serviço então respondem, servindo os dados que são solicitados para o servidor gateway localizado na máquina local. 6. O processo de gateway organiza e valida os dados e em seguida, envia os recursos para o cliente na máquina local.

[0006] O leitor vai notar que em uma relação cliente-servidor tradicional, um cliente requisita dados de um servidor e o servidor entrega dados de acordo com requisito do cliente. Numa rede peer-to-peer não gerenciada tradicional, cada peer pode atuar como um servidor (ou seja, um entregador de dados) e como um cliente (ou seja, um receptor de dados). Em um ambiente não gerenciado um requisito de dados é passado de um peer-to-peer até um arquivo estar localizado.

[0007] A rede peer-to-peer gerenciada tem um servidor centralizado que classificam recursos. Os peers em tal rede relatam e registram a sua disponibilidade, tornando assim mais fácil e mais rápido a localização de um recurso. Em um sistema híbrido uma rede peer-to-peer é utilizada juntamente com um servidor de fonte/indexação de dados centralizados para prover os baixos custos de entrega de peer, mas a consistência e a velocidade de uma fonte de dados centralizada e a fim de agilizar a entrega de recursos como a rede peer-to-peer gerenciada. Nesta situação, uma mistura de peers e servidor de origem de dados, entrega os dados.

[0008] De acordo com a presente invenção, o cliente é um cliente stand-alone, e o requisito de dados se origina e é consumido por um cliente stand-alone (navegador, aplicativo de desktop ou móvel). Ao contrário a redes prefaciadas acima, o requisito de dados não se origina com o mesmo peer, mas com um cliente stand-alone como em um relacionamento de servidor cliente tradicional.

[0009] O servidor gateway recebe o requisito e, em seguida, resolve o requisito para um recurso com um Servidor de Nome de Recurso (ou seja, servidor de indexação de recurso). O RNS responde com localizações de recurso (endereço IP), os quais podem ser origem de recurso ou peers. Dado que a rede é de origem de dados agnóstica, dados de peer não gerenciados por um servidor de dados central, mas ao invés disso indexados no RNS como requisito são passados e armazenados em cache no servidor gateway.

[0010] Nesse sentido, em tal rede, a fonte de dados é separada do servidor de indexação de recursos, permitindo, assim, que qualquer requisito de dados por um cliente stand-alone seja preenchido a partir da origem de dados ou uma rede peer-to-peer (P2P), uma vez que os dados dentro da rede P2P são armazenados em cache quando o requisito é enviado a partir do cliente stand-alone.

BREVE DESCRIÇÃO DAS FIGURAS

[0011] Outras características de nossa invenção se tornarão mais evidentes a partir de uma consideração das seguintes descrições breves de ilustrações da invenção em questão:

[0012] A figura n° 1 é uma representação esquemática de um arranjo fragmentado para um arquivo de dados, incluindo linhas de pacotes de sub- transmissão e colunas de pacotes de validação.

[0013] A figura n° 2 é uma primeira representação diagramática de uma visão geral do sistema de acordo com a presente invenção, mostrando um servidor gateway posicionado intermediário a uma nuvem de clusters de servidor e um servidor de nome de recurso.

[0014] A figura n° 3 é uma segunda representação diagramática de uma visão geral do sistema de acordo com a presente invenção, mostrando um servidor gateway posicionado intermediário a uma nuvem de clusters de servidor e um servidor de nome de recurso.

[0015] A figura n° 4 é uma representação diagramática de uma visão de sistema de servidor de nome de domínio.

[0016] A Figura n° 5 é uma representação diagramática de uma visão de sistema de servidor de nome de recurso.

[0017] A figura n° 6 é uma representação diagramática de uma visão de medida de segurança não plug-in.

[0018] A figura n° 7 é uma representação diagramática de uma relação cliente-servidor tradicional pela qual um cliente requisita dados e o servidor de entrega dados.

[0019] A figura n° 8 é uma representação diagramática de uma visão de rede não gerenciada peer-to-peer, segundo a qual cada peer pode atuar como um cliente e como um servidor onde requisitos de dados são passados de peer para peer, até que um arquivo seja localizado.

[0020] A figura n° 9 é uma representação diagramática de uma visão de rede gerenciada peer-to-peer, na qual um servidor centralizado indexa recursos e na qual os peers relatam e registram sua disponibilidade.

[0021] A figura n° 10 é uma representação diagramática de uma visão de rede peer-to-peer centralizada híbrida com a qual uma rede peer- to-peer é usada juntamente com um servidor de fonte/indexação de dados centralizado para prover os baixos custos de entrega de peer, mas a consistência e a velocidade de uma fonte de dados centralizada.

[0022] A figura n° 11 é uma representação diagramática de uma visão de rede de servidor gateway peer-to-peer.

[0023] A figura n° 12 é uma representação diagramática do quão conexões seguras são vista estruturada de um servidor local e navegador.

[0024] A figura n° 13 é uma representação esquemática de como um servidor gateway local é validado através de um plug-in.

[0025] Figura n ° 14 é uma representação esquemática de um arranjo de recurso de indexação de acordo com um requisito inicial e nenhum arquivo de correspondência.

[0026] A figura n° 15 é uma representação esquemática de um arranjo de recurso de indexação de acordo com requisito subsequente e nenhum arquivo de correspondência.

[0027] A figura n ° 16 é uma representação esquemática de um arranjo de indexação de nuvem progressiva com um requisito inicial.

[0028] Figura n° 17 é uma representação esquemática de um arranjo de indexação de recurso local.

[0029] A figura n ° 18 é uma representação esquemática de um primeiro arranjo de processamento de requisito de recurso de indexado.

[0030] A figura n° 19 é uma representação esquemática de um segundo arranjo de processamento de requisito de recurso indexado.

[0031] A figura n ° 20 é uma representação esquemática de um terceiro arranjo de processamento de requisito de recurso de indexado.

[0032] A figura n ° 21 é uma representação esquemática de um quarto arranjo de processamento de requisito de recurso de indexado.

[0033] A figura n° 22 é uma representação esquemática de um arranjo de entrega de nuvem, sub-licenciamento.

[0034] Figura n. ° 23 é uma representação esquemática de um arranjo de entrega de sublicenças, peer-to-peer.

[0035] A figura n° 24 é uma primeira representação diagramática de um provedor de transmissão, requisitando que uma canção seja reproduzida em um dispositivo móvel de acordo com a presente invenção.

[0036] A figura n° 25 é uma segunda representação diagramática de um provedor de transmissão, requisitando que uma canção seja reproduzida em um dispositivo móvel de acordo com a presente invenção.

[0037] A figura n° 26 é uma representação esquemática de uma vista de sistema gateway potencializado de servidor gateway de acordo com a presente invenção.

[0038] A figura n° 27 é uma representação esquemática de um arranjo de fila de mídias pré-gravadas de acordo com a presente invenção.

[0039] A figura n° 28 é uma representação esquemática de um arranjo de divisão de transmissão de acordo com a presente invenção.

[0040] A figura n° 29 é uma representação diagramática de uma estrutura de arquivos MP3 de acordo com a presente invenção mostrando cabeçalhos de quadro e quadros de áudio de uma transmissão de áudio.

[0041] A figura n° 30 é uma representação diagramática de métodos do estado da técnica para a transmissão de rádio através da Internet.

[0042] A figura n° 31 é uma representação diagramática de uma visão geral do sistema para integração de propaganda sem mixagem de áudio de acordo com a presente invenção.

[0043] A figura n° 32 é uma representação esquemática de um arranjo produtor de propaganda de acordo com a presente invenção.

[0044] A figura n° 33 é uma representação esquemática da metodologia relativa ao encaminhamento de requisitos HTTP a partir de navegadores e/ou outros clientes de consumo de mídia.

DESCRIÇÃO DETALHADA DA MODALIDADE / METODOLOGIA PREFERENCIAL

[0045] Com referência aos desenhos, agora com mais especificidade, a presente invenção provê uma rede de entrega de conteúdo e metodologia associada para transmissão de dados Agnósticos em Peer-to-Peer em nuvem. Como discutido acima, a invenção compreende um servidor gateway peer-to-peer (P2P) como retratado e referenciado em 3. O servidor gateway P2P 3 recebe comunicações (como em 200) do cliente 2 na máquina local 101.

[0046] Esses requisitos podem ser formatado como um requisito HTTP padrão direcionado no servidor gateway local 3, o qual será registrado com um nome de domínio local. Enquanto roteamento de requisitos HTTP a partir de navegadores da web e outros dispositivos pode incluir o uso de nomes de domínio registrados localmente e protocolos são métodos viáveis, o seguinte método é preferencial quando roteamento de requisitos HTTP a partir de navegadores e outros clientes que consumem mídias.

[0047] O cliente consumindo 2 é dado um nome de domínio totalmente formatado para os servidores remotos peer-to-peer 4 ou servidores de nome de recurso 4. Por razões de simplificação, o leitor irá considerar o nome de domínio www.rns_server.com. Para requisitar mídia 401 através da rede de entrega de conteúdo peer-to-peer (CDN) como em 144, o cliente 2 contém um localizador de recurso uniforme (URL) com o nome de domínio público RNS e um GET variável com a localização da mídia requisitada, algo da forma www.rns_server.com?media=www.somemediasource.com/media.mp4&prot ocol=http o formulário.

[0048] Quando o RNS 4 recebe o requisito, ele consulta 404 duas bases de dados distintas. A primeira consulta usa o endereço de protocolo de Internet (IP) público de dispositivos de requerimento para identificar se quaisquer peers de rede 3 que existem dentro da rede local de dispositivos de requerimento solicitante dispositivos 101. A segunda consulta procura o banco de dados do recurso para identificar peers 3 com a mídia requisitada disponível para transmissão (em 200, 207, 208, 209 e 210) dentro do peer- to-peer (P2P) 144 CDN.

[0049] Com base no resultado de consultas 404, as seguintes coisas poderiam acontecer. Em primeiro lugar, se não houver nenhum ponto registrado na rede local, o requisito é redirecionado em 403 para a fonte remota da mídia 104, e a rede P2P 144 não será utilizada. Se houver um peer registrado 3 dentro da rede local 101, o requisito é redirecionado como em 402 para o peer de rede local 3 junto com a localização de recurso e os de disponibilidade os quais foram recuperados na segunda consulta 404. O peer de rede local 3 controla, então, a transmissão de mídia (como em 200, 207, 208, 209 e 210).

[0050] O leitor, portanto, irá apreciar que o servidor de nome de recurso (RNS) como referido em 4, é central para a prática da presente invenção. O URL do recurso de cache de RNS 4 e locais de recurso (ou seja, endereços IP) e resolve requisitos de recursos com endereços de máquina (endereço de IP). O processo geral para um tipo de mídia não- combinado seria da seguinte maneira. O cliente 2 envia um requisito para recursos (como em 200) para o servidor gateway 3.

[0051] O servidor gateway 3, em seguida, envia o requisito (como em 201) ao RNS 4 compartimentados para resolver (como em 202) o requisito de ID/URL de recurso de entrada (como em 203) com um endereço de recurso (como em 204), cujos recursos ou o endereço IP é então comunicado (como em 205) para o servidor gateway 3 como mais particularmente retratado na figura n ° 5. Em outras palavras, uma vez que o requisito de recurso 203 é correspondido como 202 com (por exemplo, (a) preço mais eficiente ou (b) maior qualidade da fonte de som) localizações de recurso ideais 204, os dados de localização de recursos ou endereço(s) de IP 204 são retornados como em 205 para o servidor gateway de 3.

[0052] O servidor gateway 3, em seguida, envia (como em 206, 207 e 208) requisito(s) para dados de recursos para as máquinas apropriadas (102 ou 103) ou clusters de servidor em 104. As máquinas 102/103 ou clusters de servidor 104 então respondem, servindo (como em 209) os dados que são solicitados para o servidor gateway 3 localizado na máquina local 101. O servidor gateway 3 em máquina 101 processa (ou seja, organiza e valida) os dados como servido em 209 e em seguida, entrega 210 os recursos para o cliente 2.

[0053] Certas relações cliente-servidor-peer basicamente são representadas esquematicamente nas figuras n. ° s 7, 8, 9 e 10. Uma relação de cliente-servidor tradicional é representada na figura n ° 7; uma rede peer-to-peer não gerenciada é retratada na figura n ° 8; uma rede peer-to-peer gerenciada é retratada na figura n ° 9; e uma rede peer-to-peer centralizada/híbrida é representada na figura n ° 10.

[0054] Em uma relação cliente-servidor tradicional, um cliente 105 requisita 211 os dados de um servidor, 106 e o servidor 106 entrega 212 os dados de forma cíclica como representado na figura n ° 7. Em uma rede peer-to-peer tradicional, não gerenciada, cada peer (ou combinação de cliente/servidor) 107 pode atuar como um servidor 106 para a entrega de dados e um cliente 105 para receber dados. Em um ambiente não gerenciado, como geralmente retratado na figura n ° 8, um requisito 211 para dados é passado do mesmo peer 107 a peer 107 até que um arquivo seja localizado.

[0055] Uma rede peer-to-peer gerenciada, como geralmente retratada na figura n ° 9 tem um servidor centralizado, servidor de recurso de indexação 108 que funciona para recursos de index. Os recursos indexados são entregues 213 aos peers 107 seguindo requisitos 214 desse modo. A disponibilidade de recursos indexados é então relatada e registrada por peers 107. Este tipo de arranjo torna mais fácil e mais rápido localizar um recurso.

[0056] No sistema híbrido, geralmente representado na figura n ° 10, uma rede peer-to-peer é utilizada juntamente com um servidor de fonte/indexação de dados centralizado 109. Recursos indexados e dados são entregues 215 para os peers 107 a partir do servidor 109 seguintes requisitos 216 de recursos e dados pelo(s) peer(s) 107. Este tipo de arranjo provê os baixos custos de entrega de peer, mas a consistência e a velocidade de uma fonte de dados centralizada e a fim de agilizar a entrega de recursos como na rede peer-to-peer gerenciada. Nesta situação, uma mistura de dados de origem de servido 109 e peers 107 entrega os dados.

[0057] Na rede de entrega de conteúdo (CDN) peer-to-peer de origem agnóstica 144 geralmente representada nas figuras n° 2 e 3, o cliente 2 é um cliente stand-alone. Em outras palavras, o requisito de dados se origina e é consumido por um cliente stand-alone 2 (ou seja, navegador, aplicativo de desktop ou móvel). Ao contrário das outras redes, o requisito de dados não se origina com um peer 107, mas com um cliente stand-alone 2 como em um relacionamento de servidor cliente tradicional como geralmente retratado na figura n° 7.

[0058] O servidor gateway 3 recebe o requisito a partir do cliente 2 e, em seguida, resolve o requisito para um recurso com um Servidor de Nome de Recurso ou RNS ou servidor de indexação de recurso 4. O RNS 4 responde com localizações de recurso (por exemplo, endereço de IP), cujas localizações podem ser origem de recurso ou peers. Dado que a rede é de origem de dados agnóstica, dados de peer não gerenciados por um servidor de dados central, mas ao invés disso indexados no RNS 4 como requisito são passados e armazenados em cache no servidor gateway 3.

[0059] Em tal rede, a fonte de dados é separada do servidor de indexação de recurso ou RNS 4. Isso permite que qualquer requisito de dados por um cliente stand-alone 2 seja preenchido a partir da origem de dados ou uma rede peer-to-peer (P2P), uma vez que os dados dentro da rede peer-to-peer são armazenados em cache quando o requisito é enviado a partir do cliente stand-alone 2.

[0060] A presente invenção não é limitada a usar HTTP ou Web Sockets, mas também pode usar protocolos de transferência de arquivo padrão (FTP, WebDAV, SMB, AFP etc ). Neste caso, o cliente seria um FTP standalone (ou qualquer cliente de protocolo de transferência de arquivo padrão). Se o diretório FTP (ou WebDAV, SMB, AFP etc ) é montado como uma unidade de rede dentro de um sistema operacional, o sistema operacional agiria como o cliente. Nesta situação o servidor gateway iria funcionar como um servidor de arquivos.

[0061] Nomeadamente, existem algumas preocupações de segurança em tal arranjo. A solução ou arranjo proposto de acordo com a presente invenção é potencialmente vulnerável ao "homem no meio ataques" e/ou acesso de cliente não-autorizado. Estas preocupações podem ser abordadas, provendo certos meios de autenticação de cliente ou servidor. A autenticação de cliente e/ou servidor significa basicamente função para verificar a autenticidade do cliente e/ou servidor.

[0062] Os meios de autenticação de cliente e/ou servidor podem ser exemplificados por um número de diferentes mecanismos, conforme descrito mais detalhadamente adiante. Por exemplo, ditos meios de autenticação podem ser providos por meio de autenticação de plug-in de mídia (autenticação de cliente) e extensões de navegador que validam o servidor local para garantir que não é um servidor corrompido (isto exigiria algum tipo de original ID, tokens de sessão ou emparelhamento por chave).

[0063] Certificados do lado do cliente juntamente com plug-ins, também podem ser usados para autenticar o cliente e o servidor modalizando algum tipo de verificação de identificação dentro do plug-in, o qual é então passado para os certificados do lado do cliente os quais validam a identificação de verificação usando AJAX. O uso de certificados do lado do cliente em tandem com um plug-in de navegador é preferencial à medida que provê verificação de cliente e servidor em um processo. Este método é discutido abaixo.

[0064] Números de referência de figura 12 e 13, o leitor considerará verificação do cliente através do plug-in de navegador e certificados do lado do cliente. O processo de criação de uma conexão segura começa com a instalação do servidor local. Quando instalado, o servidor cria um certificado auto-assinado e adiciona o certificado auto-assinado para a árvore de certificado root. Isto permite que o servidor criar uma conexão segura a partir de um navegador.

[0065] Para adicionar outra camada de segurança no servidor local 110 carrega várias instâncias de um plug-in de navegador de processamento de mídia 24 (por exemplo, flash, sliver light, etc...). O servidor local 110 pode facilmente carregar até 1.000 instâncias múltiplas de um plug-in de navegador de processamento de mídia 24. Cada instância modalizou no seu interior uma chave de criptografia exclusiva como em 27. Em vez de carregar várias instâncias, a chave de criptografia 27 pode ser injetada o arquivo de componente de plug-in se as bibliotecas de plug-in permitem a injeção de código personalizado.

[0066] Quando um navegador cria uma conexão segura, como em 26, o servidor 110 cria uma sessão exclusiva para a conexão iniciada e em seguida emparelha a sessão com uma instância de plug-in de mídia 24 e sua chave de criptografia modalizada 27, ou cria uma chave de criptografia 27 e injeta no arquivo do componente de plug-in. O arquivo do componente de plug-in 25 é então carregado no navegador 111. O arquivo de plug-in 25 criptografa todos os requisitos que provêm do navegador 111 através do certificado do lado do cliente e envia para o servidor 110 através da conexão criptografada 26. A chave de criptografia exclusiva 27 também pode ser um único token usado para assinar os requisitos para validá-los.

[0067] Para recuperar a chave de criptografia ou token 27 seria preciso descompilar o arquivo de plug-in 25 servido pelo servidor local 110 e então reestabelecer uma conexão com o servidor 110 usando uma nova instância de plug-in "rachada". No entanto, uma vez que o servidor 110 seleciona uma chave de criptografia diferente 27 com todas as sessões, no momento em que a nova conexão de socket segura 26 é estabelecida a chave de criptografia anterior 27 expira. Isto torna inútil a chave de criptografia 27 obtida através de descompilação.

[0068] Uma das preocupações sobre o uso de um servidor local para entregar o conteúdo principal é a possibilidade de um "homem no ataque médio" cujo cenário de software malicioso poderia posar como um gateway válido e possivelmente interceptar dados de usuário. Para evitar esta forma de ataque, o atual sistema emprega métodos que exigem que o servidor local 110 verifique a autenticidade de um gateway válido apresentando um servidor válido de identificação de autenticação 31 através do componente de plug-in de navegador 25. O processo é descrito mais detalhadamente adiante.

[0069] Todos os servidores de gateway local 110 registram (como em 19) eles mesmos com o host remoto 112, criando uma identificação de verificação 31 que está vinculada ao protocolo de internet pública da máquina local. Esta identificação de verificação 31 e seu protocolo de internet público relacionado são armazenados em um banco de dados 29 no host remoto 112. Quando uma página da web 30 é carregada que estará usando o servidor gateway local 110, o navegador 111 envia um requisito (como em 217) para o servidor local 110. O servidor 110 responde ao apresentar sua identificação de verificação 31.

[0070] O navegador 111 então envia um requisito (como em 218) com a identificação de verificação 31 para o host remoto 112. Se a identificação de verificação 31 coincide com o endereço de protocolo de internet e a identificação de verificação armazenada no banco de dados remoto, 29, o servidor remoto 112 envia uma resposta ao longo do caminho 218 validando o servidor gateway local 110. Após a verificação, o navegador 111 então começa a carregar (em 26) o plug-in de mídia 24 do servidor local 110. A o plug-in de mídia 24, em seguida, cria uma conexão segura 219 para o servidor gateway local 110 pelo qual ele vai entregar dados (por exemplo, os dados baseados em música).

[0071] Fazendo referência a figura n ° 6, o leitor irá considerar uma medida de segurança não plug-in. Um método que não requer o uso de uma mídia de plug-in de acordo com a presente invenção envolve ter o cliente 2 envia um requisito (como em 220) para identificação de sessão registrada 113 do servidor gateway 3 para validar sua autenticidade. Uma identificação de sessão 114 pré-registrada (como no 221) pelo servidor gateway e é inválida após uma autenticação única.

[0072] Isso requer que o servidor de gateway 3 registre várias sessões 114 antes do tempo e cada identificação de sessão 113 é válida apenas para uma única validação. O servidor gateway 3 apresenta (como em 222) a identificação de sessão 113 ao cliente 2. Em seguida, cliente 2 valida (como em 223) a identificação de sessão recebida 115 com o servidor de verificação 116. O servidor de verificação 116 combina (como em 224 e 225) a identificação de sessão 115 enviada pelo cliente 2 com identificações de sessão registradas 114. Se uma correspondência for encontrada, então o servidor de verificação 116 confirma (como em 224) para o cliente 2 a validade do servidor gateway 3.

[0073] Há outros métodos alternativos para garantir uma conexão válida, incluindo uma integração de sistema operacional que teria um nome de domínio local reservado para o servidor gateway, para que outros aplicativos não pudessem posar como um servidor gateway legítimo ou através da criação de um protocolo de transferência para a transmissão de dados através de um sistema desse tipo. Ambas são soluções possíveis. A solução de protocolo personalizado, no entanto, exige requisito diferente de formatação, como exemplificado a seguir: rstp://domain.com/resource_directory/resource_name?var=123 (e não http://vertigo/domain.com/resource_directory/resource_name?var=123)

[0074] Outra maneira de proteger o sistema é limitar o conteúdo entregado através daquele sistema para mídia (música, imagens, vídeo, etc) e restringir a distribuição de arquivos de conteúdo que não está relacionada com a estrutura e o código de um site ou aplicativo. Desta forma é mais difícil de importar código malicioso, já que somente os arquivos de mídia são permitidos. Isso é feito com segurança em mente. Em outras palavras, arquivos HTML, Javascript, CSS, PHP etc... Não pode ser entregue através do servidor gateway. Outra restrição é fazer com que o cliente (navegador) restrinja o uso de tal gateway ou protocolo, se o site (estrutura, código e meios de comunicação) é carregado através de https e é sensível.

[0075] Fazendo referência à figura n° 1, o leitor irá considerar certa validade dos dados e aspectos de segurança de acordo com a presente invenção. Uma das preocupações em um CDN agnóstico de origem de dados 144 é a validade dos dados. Se, por exemplo, um dos peers corrompeu dados, ou se alguém fosse criar um peer malicioso que registra a arquivos que não estão relacionados aos dados originais, como uma versão em cache de peer de um arquivo original, a confiabilidade e a utilidade do sistema podem ser comprometidas.

[0076] É por isso que métodos de fragmentação e validação de dados devem ser incluídos para que o sistema seja confiável e útil. Assim, a fim de manter um único peer possivelmente corrompendo ou propositalmente, substituindo dados de forma inadequada, é preferencial fragmentar a entrega dos dados através de múltiplos peers através de certos meios de fragmentação de entrega de dados. Os meios de fragmentação de entrega de dados, de acordo com a presente invenção, podem ser exemplificados por uma série de mecanismos. Fragmentação de entrega de dados, por exemplo, pode ser conseguida ao quebrar os dados 199 em pacotes ou sub transmissões em linhas, 117, 118, 119 e 120. A fragmentação pode ser otimizada para atender as necessidades do sistema.

[0077] A fragmentação pode ser feita simplesmente limitando cada entrega do peer para um máximo de um terceiro exemplar ou um quarto de um determinado arquivo de mídia. Isto é gerenciado usando o servidor de nome de recurso ou RNS 4, como discutido em mais detalhes posteriormente abaixo.

[0078] Juntamente com a fragmentação da entrega de dados, cada arquivo de dados tem com ele um pacote de validação para um setor específico dos dados em colunas, 121, 122, 123 e 124. Isso é feito porque cada peer que serve dados deve primeiro armazenar em cache a mídia antes de servi-la novamente.

[0079] Nesse sentido, por exemplo, se o peer entrega de transmissão de sub-dados 117, também entregaria junto com esses dados um pacote de validação para setor 121 do arquivo. Este pacote de validação é uma soma de verificação criada por um algoritmo predeterminado.

[0080] Portanto, se o peer que envia sub-transmissão 118 deveria entregar dados que foram corrompidos ou maliciosos, o peer que recebe seria capaz de detectar isto usando a soma de verificação de validação peer enviando sub-transmissão 117 para validar o conteúdo entregado pelo peer que envia sub-transmissão 118. Se o conteúdo não pode ser validado, o peer iria enviar o requisito de dados para a fonte original ou dados de origem. A presente invenção contempla adicionalmente a definição um limite mínimo diário de requisitos, o que permitiria tal validação de dados peer-to-peer. Caso contrário, um servidor de validação serviria as somas de verificação, e estas somas de verificação seriam criadas no primeiro requisito passado para um servidor gateway para um recurso.

[0081] Com referência às figuras n° 4 e 5, o leitor considerará comparativamente certas diferenças entre um servidor de nome de domínio (DNS) e um servidor de nome de recurso (RNS). A principal diferença entre um DNS 130 e um RNS 4 é em como um requisito para um recurso é manipulado. Dentro de DNS 130 uma solicitação para um recurso (como em 226) é resolvido (como em 227) para um nome de domínio 129 ou um Start of Authority (SOA) 126 o qual tem o recurso especificado 127 dentro de um diretório 128 do SOA 126. O cliente 2 recebe (como em 228) o endereço de IP do SOA do DNS e então faz um requisito (como em 229) para o recurso de 127 do SOA 126.

[0082] Dentro de um servidor de nome de recurso ou RNS 4, o RNS 4 resolve (como em 202) o requisito (como em 201) para um recurso para várias máquinas que possuem o exclusivo recurso guardados ou armazenados em cache. Por conseguinte, o endereço de IP do SOA com o recurso pode ser retornado (como em 205) como uma localização de recurso válido, mas também o endereço de IP para os recursos armazenados em cache de peer. Em outras palavras, dentro de um sistema DNS, um URL é mais parecido com o endereço de um recurso específico, dentro de RNS 4, a URL 240 é tratada como uma identificação única ligando um recurso único para várias localizações.

[0083] Certos meios para o recurso de indexação sem correspondência de arquivo estão representados nas figuras n° 14 e 15; e certos meios para indexação de recurso com correspondência de arquivo são descritos nas figuras n° 16 e 17. Uma das principais questões que surgem ao lidar com conformidade é como verificar o que está sendo emitido. Metadados são freqüentemente corrompidos ou modificados pelo usuário. Portanto, para transmitir mídia local mais efetivamente, uma pessoa precisa prover uma maneira para verificar com um muito elevado grau de certeza que uma canção ou arquivo de mídia na unidade local corresponde àqueles armazenados na nuvem.

[0084] Isso é feito usando um arquivo de metadados-independente de sistema ou por meio de correspondência, e indexação de todos os arquivos locais e combiná-los com arquivos em nuvem. Existem duas fontes de arquivos que devem ser comparados com a biblioteca de acordo com a presente invenção, incluindo (1) aqueles originários de outros provedores de transmissão ou vindo de nuvens externas e (2) aqueles que estão na máquina local.

[0085] Fazendo referência à figura n° 16, o processo de indexação progressiva 247 começa com um requisito que vem de um aplicativo de cliente de terceiros. Isso pode ser um aplicativo de desktop stand-alone como em 131 ou um site emitido através de um navegador como em 132. O aplicativo 131 ou navegador 132 passa como em um URL válido e corretamente formatado (como 241 e 242) para o servidor gateway local (133). O servidor gateway local 133 usa a URL (como em 241 e 242) para recuperar o recurso solicitado para transmissão (em 243 e 244) a partir das nuvens relacionadas 245 e 246 (rede peer-to-peer relacionadas ou qualquer recurso baseado em rede possível). Uma vez que o recurso foi sido baixado para transmissão como em 243 e 244, o servidor local 133 começa o processo de indexação em 247 (com sub-rotinas 248-252). Indexação de recurso local 253, geralmente, é representada na figura n° 17 (com sub-rotinas 254-258).

[0086] Processamento de requisito de recurso indexado 259 é geralmente retratado na figura n° 18. Depois que um recurso foi indexado, o seguinte processo ocorre quando requisitos subsequentes são feitos a partir de clientes de terceiros. Supondo que um provedor de serviços de transmissão de mídia (como em 132) coloca em um requisito 242 para o servidor local 133 usando o seus URLs padrão, o requisito 242 entra e o servidor local 133 consulta o banco de dados do sistema de arquivos local 135 e o servidor de indexação 134 para determinar se o recurso foi indexado anteriormente. (O URL é usado para determinar se ele existe no servidor de indexação 134 ou no sistema de arquivos locais 137). Neste caso, o servidor local 133 determina que o recurso foi indexado e está disponível na rede peer-to-peer 138. A mídia é então obtida a partir da rede peer-to-peer 138 e serviu para o provedor de serviço de transmissão de mídia (como em 132) para reprodução.

[0087] Em outro caso, um provedor de serviço de transmissão de mídia (em 131) faz um requisito semelhante, usando um URL. Desta vez o servidor 133 determina, ao consultar o banco de dados local, que indica que o recurso é indexado e associado com um arquivo local, 137. O servidor 133 então serve esse arquivo, por exemplo, para um transmissor de música baseado em nuvem de terceiros (por exemplo, Spotify) (em 131). É provável que sistemas ou aplicativos que acessem o servidor gateway local (133) vão passar todos os recursos que serão necessários durante uma sessão quando inicia uma sessão. O servidor 133 então puxará os campos associados a partir do servidor de indexação de recursos (134). Desta forma, todos dados indexados são armazenados localmente para acesso rápido e roteamento.

[0088] O servidor gateway, de acordo com a presente invenção, provê certos meios para roteamento inteligente e relatórios de realeza para transmissão de dados (por exemplo, música). Dado que a música pode ser transmitida de várias fontes, os servidores gateway locais, de acordo com a presente invenção, entregam os dois pedidos de música interativa e não- interativa feitos por um aplicativo de cliente e rota da transmissão real da localização ideal (por exemplo, (a) preço mais eficiente ou (b) maior qualidade da fonte de som) dos custos de largura de banda e as obrigações da realeza. Esse sistema resulta em um único mecanismo de conformidade ou Aparelho de conformidade permitindo que relatórios de uso e as obrigações de realeza sejam geradas a partir de e em vários tipos de plataformas de serviços, atendendo todas as normas e requisitos de titular de direitos.

[0089] Exemplos de fontes de transmissão incluem mas não estão limitadas a: (1) Um transmissor baseado em nuvem; (2) um provedor de armazenamento baseado em nuvem de terceiros que tornam compras de dados disponíveis para o proprietário do dispositivo; (3) o armário virtual baseada em nuvem vertigo (blindado sob 512(c) do Copyright Act); (4) música vertigem-licenciado, conduzida por usuário/sub-serviço dados correspondentes; (5) arquivos de música localmente possuídos e armazenados disponíveis no dispositivo do ouvinte ou outra propriedade e qualificação de dispositivo conectado através de Wi-Fi; (6) transmissão para um dispositivo móvel de um PC ligado; (7)arquivos peer-to-peer disponíveis para a transmissão de propriedade e roteados na substituição de um arquivo antes de ele ser transmitido a partir de n° 1, n. ° 3 e n ° 4 listados acima.

[0090] Alguns exemplos de roteamento de música e emissão de relatórios de resultado de rota são os seguintes.

[0091] Fazendo referência a figura n° 19, o leitor irá considerar que quando um ouvinte está ouvindo um canal de rádio de internet não interativo através de um cliente de transmissão relacionado (como em 140) (por exemplo, um web site ou aplicativo de desktop stand alone) e o provedor de serviço de rádio de internet está se preparando transmitir (em 230) um arquivo 139 já armazenado e disponível no dispositivo do ouvinte , o servidor gateway 141 de acordo com a presente invenção corresponde (como em 231) o arquivo local indexado 139 com requisito de entrada do provedor do serviço de rádio da Internet e transmite (como em 232) o arquivo 139 em vez da emissão da nuvem do provedor de serviço de rádio da Internet como em 142.

[0092] Nomeadamente, todos os recursos, se o local e remoto, são indexados, que permitem rápida correspondência. Depois de transmissão 232, o uso do arquivo local é relatado em 233 para o servidor de conformidade 143. É possível que os rótulos poderiam exigir que o provedor de serviço de rádio de Internet pague uma pequena taxa quando transmissão 232 de arquivos locais 139 uma vez que não há uma maneira de garantir que eles não são pirateados. Como resultado da alocação de recursos eficiente, de acordo com o servidor 141, o provedor de serviço de rádio de Internet 140 não teria que pagar a largura de banda ou pagar de licenciamento completo e estas economias de custo podem então ser repassadas para o provedor de serviço de rádio de Internet.

[0093] Figura n ° 20 tenta descrever um cenário quando um ouvinte está ouvindo um canal de provedor de serviço de rádio de Internet não interativo e o cliente de provedor de serviços de rádio de Internet 140 está se preparando para transmitir (em 230) um arquivo não disponível no dispositivo do ouvinte, mas está disponível em um peer 141 dentro de uma rede peer-to-peer 144 de acordo com a presente invenção. Não há nenhuma economia de royalties para o provedor de serviço de rádio de Internet, mas a rede peer-to-peer 144 de acordo com a presente invenção transmite, como em 233 o arquivo 139, em substituição do arquivo do provedor de serviço de rádio de Internet em uma economia de largura de banda para provedor de serviço de Internet. O servidor 141 então pode relatar em 233 qual música foi tocada em um servidor de conformidade 143 se necessário.

[0094] A figura n° 21 tenta retratar o cenário, quando um ouvinte cria uma lista de dez músicas na sua conta do provedor de serviço de transmissão de mídia como em 145 para um evento especial. O ouvinte pode ser um dono de restaurante ou gerente e o evento é um evento público em um ambiente comercial. A conta de provedor de serviço de transmissão de mídia 145 não permite para um ambiente comercial e enquanto três das canções na verdade estão disponíveis para download para o dispositivo local através do armário de armazenamento de nuvem do ouvinte, o contrato de licença de mídia comprado também não permite a transmissão em um ambiente comercial.

[0095] Um dispositivo de provedor de licenciamento comercial 146 é instalado no local com os direitos legais para transmitir todas as 10 músicas, mas há apenas cinco da lista de reprodução solicitada de dez canções disponíveis no dispositivo instalado localmente do provedor 146. O sistema, de acordo com a presente invenção, sincroniza a playlist feita no reprodutor de mídia do provedor de transmissão de mídia 145 e correspondências (como em 231) os arquivos que faltam para arquivos disponíveis na nuvem Vertigo e transmite 234 as músicas para o dispositivo do provedor de licenciamento comercial 146 por acordo de licenciamento do provedor. Esta transferência pode vir da rede peer-to-peer do Vertigo 144 dependendo dos custos de largura de banda. Toda transmissão e emissão pode ser relatada 233 pelo servidor 141 (se necessário) para um servidor de conformidade 143 para controlar o número de vezes que uma música foi tocada.

[0096] O cenário retratado na figura n° 24, um provedor de transmissão 147 requisita que uma canção 151 seja reproduzida em um dispositivo móvel 148. O requisito é enviado a partir de um aplicativo de dispositivo móvel 149 no dispositivo móvel 148 e enviado para o servidor remoto 150 de acordo com a presente invenção. Se o dispositivo móvel 148 que requisita 237, a música que está ligada como em 235 a um computador pessoal 152 que tem o arquivo armazenado localmente, em vez de roteamento, o requisito para a canção para o servidor de origem de dados 147 (ou seja, o servidor do provedor de transmissão), o requisito é enviado para o computador pessoal 152 e transmitido em 236 a partir do computador pessoal 152 para o dispositivo móvel 148. Em tal situação, nenhum direito de transmissão adicional seria necessário e nenhum custo de largura de banda incorreria. Se o requisito 237 é enviado para o servidor remoto 150 de acordo com a presente invenção, e o arquivo não existe no computador pessoal vinculado 152 ou nuvem, o requisito 237 é enviado como em 238 para a origem de dados 147 cuja origem de dados 147 pode então transmitir 239 o arquivo para o dispositivo 148.

[0097] O cenário retratado na figura n° 25, um provedor de transmissão 147 requisita que uma canção seja reproduzida em um dispositivo móvel 148. O requisito é enviado a partir do aplicativo de dispositivo móvel 149 no dispositivo móvel 148 e enviado para o servidor remoto 150 de acordo com a presente invenção. Se o dispositivo móvel 148 está requerendo uma canção que foi carregada como em 240 para um serviço de nuvem 153 de um computador pessoal 152 ao qual o dispositivo móvel 148 está vinculado como em 235, o servidor remoto 150 roteia 236 o requisito 237 para o armário em nuvem ou serviço 153. Neste caso licenciamento não é necessário, mas taxas de largura de banda seriam aplicadas. Se o requisito 237 é enviado para o servidor remoto 150 de acordo com a presente invenção, e o arquivo não existe no computador pessoal vinculado 152 ou nuvem ligada 153, o requisito 237 é enviado como em 238 para a origem de dados, doravante o arquivo pode ser transmitido como em 239 para o dispositivo 148.

[0098] O servidor 150, de acordo com a presente invenção, e seu mecanismo de roteamento de música inteligente como descrito dentro os exemplos precedentes não só seleciona a música a partir do ponto de transmissão menos caro no que se refere a custos de largura de banda e royalties, incluindo, mas não limitado a recursos como exemplo n ° 1 - 6 acima, mas tem também avaliados os aspectos de conformidade de tal transmissão e relatórios de tal atividade para fins de royalty.

[0099] Com referência às figuras n ° s 22 e 23, o leitor irá considerar certos arranjos de sublicenças de acordo com a presente invenção. O uso do servidor gateway local para sub-licenciamento automatizado de conteúdo de transmissão é dependente dos termos de acordos entre titulares dos direitos e distribuidores de conteúdo (ou seja, provedores de serviço de transmissão). Descrita abaixo, é uma situação que é possível, dado que o provedor de transmissão tem um acordo que requer que eles compartilham uma parte das renovações derivadas de mídia licenciadas de transmissão. Pode haver um requerimento que tal licença especificamente permite que o provedor de transmissão atue como um atacadista.

[00100] Um primeiro cenário é representado na figura n. ° 22. Neste caso, um provedor de serviços de transmissão 155 passa um requisito para o servidor gateway local 150 junto com o requisito que o provedor 155 deve definir certos parâmetros, permitindo que o servidor local 150 transmita 241 a um preço ideal. Isto indica que o servidor 150 pode transmitir de uma conta sublicenciadas como em 156. No diagrama existem três contas sublicenciadas referenciadas em 157, 158 e 159.

[00101] Quando o requisito vem em a partir do aplicativo de cliente 155, o servidor local 150 determina como em 242 qual conta de sublicença (conforme selecionado a partir de contas 157-159) tem o custo de licenciamento ideal para o determinado requisito 241 de 242. A canção é então transmitida 243 a partir da nuvem sublicenciadores (por exemplo, da conta 157). O provedor de transmissão é então faturado em 244 em nome de sublicenciante 157. O faturamento que inclui os custos de licenciamento e custos de transmissão baseados no acordo de licenciamento de sublicenciadores. O sublicenciante então paga 245 o titular de direitos 160 royalties e mantém verbas necessárias para cobrir o custo de transmissão e lucro derivado da transação.

[00102] Em um segundo caso conforme representado na figura n ° 23, a principal diferença é vista como o custo de transmissão é coberto. Uma vez que os dados são transmitidos 246 a partir de uma rede peer-to- peer 161 de acordo com a presente invenção, a taxa associada ao uso da rede peer-to-peer 161 é paga 247 ao provedor de serviço 162 possuindo a rede 161 e então os custos de licenciamento são repassados 244 para o sublicenciante 157 que então paga 245 os royalties para o titular de direitos 160 e retém o lucro derivado da transação.

[00103] Os casos de sub-licenciamento acima são possíveis porque o servidor local 150 rastreia e relata transmissões, ou seja, quem transmite de onde (qual sub licenciante) e como resultado pode corretamente rotear os pagamentos de royalties. A singularidade do sistema é não que permite tal rastreamento, mas que é possível acessar uma rede peer-to-peer e ainda relatar tal uso. O segundo cenário apresentado acima só é possível com um servidor gateway local 150, enquanto o primeiro cenário pode acontecer com um requisito de servidor para servidor padrão, ou alguma forma de reescrita ou redirecionamento.

[00104] Certos benefícios/vantagens de licenciamento ao usar o conteúdo do servidor local são evidentes, de acordo com a presente invenção. A este respeito, uma utilização de mídia de comunicação local entra em jogo quando uma canção existe em um servidor local controlado ou de propriedade do usuário final do serviço. Isso seria um título ou álbum já na conta da biblioteca de mídia pessoal do usuário ou qualquer parte de seu computador local. Este conteúdo pode ser colocado lá por compra, download ou presente. Não é a responsabilidade do provedor de serviços ou dos proprietários do presente sistema/metodologia confirmar a origem legal dos arquivos locais no computador de um usuário final.

[00105] O provedor de transmissão não estará fazendo uma duplicação, distribuição ou desempenho de uma gravação de som controlada localmente ou obra musical. Portanto, direitos não são usados e nenhuma taxa de licença adicional é necessária para o cálculo ou relatório. A chave é capaz de rapidamente e com precisão identificar essas faixas a fim de não interromper a experiência do usuário final.

[00106] O uso dos meios de comunicação de um servidor de acordo com a presente invenção acontece quando uma canção que foi licenciada em uma taxa mais favorável do atual sistema/metodologia do proprietário pode ser usada no lugar de uma canção do provedor de transmissão. Isto é feito possível por licenças que são feitas diretamente com os controladores de conteúdo. Estes novos acordos diretos oferecem uma estrutura de royalty mais transparente, e processo de geração de relatórios diretamente para o artista.

[00107] As licenças diretas também levam em conta usos interativos e não-interativos cirando mais de uma relação de "uma pausa" para uso online. O acordo também irá oferecer um pagamento de royalties exclusivo que é calculado através da economia adquirida com eficiência de entrega. Atualmente não existem acordos que passam uma porção das economias criadas ao compartilhar arquivos para a indústria.

[00108] As vantagens de usar esses arquivos para os provedores de transmissão vêm da taxa de royalties reduzida através do uso interativo e não interativo. Todas as performances e horas de escuta calculadas a partir do uso desses títulos vão ser esculpidas dos cálculos padrão de royalty de "taxa total" e serão baseadas na taxa mais favorável.

[00109] O uso da mídia peer-to-peer controlada acontece quando um arquivo está localizado dentro do cache seguro do servidor do usuário controlado e pode substituir um arquivo programado para reproduzir pela alimentação de dados de provedores de transmissão. Enquanto não há nenhuma economia de custos das taxas de royalty, há uma economia de entrega que vai beneficiar internamente os artistas que estão sob as licenças diretas de acordo com o atual sistema e metodologia. Portanto, os títulos, mais que isto, podem vir deste cache seguro quanto mais benefício para os provedores de transmissão e a indústria da música.

[00110] Abaixo está uma quebra de um mês de amostra de programação a partir de um provedor de transmissão fictício. A quebra é destinada a mostrar não só a economia com o uso do conteúdo de múltiplas fontes, mas também o quão crítico o processo de cálculo de conformidade único é o processo de economia global.

[00111] O mecanismo de conformidade e ferramenta de relatórios têm a capacidade de puxar as seguintes informações: 1) Relatórios de uso baseados nas especificações originais exigidas por todas as organizações de direitos realizantes. Estas especificações incluem os seguintes itens. a. Prover relatórios exclusivos por plataforma (provedor de transmissão) b. Prover a capacidade para obter informações de receitas para serem firmemente inseridos com base no tipo de plataforma e provedor por Transmissão c. Relatórios de uso por sessão de usuário exclusiva para criar Horas de Listagens Médias totais, e por sessões de audição totais d. Capacidade de agregar todas as informações de uso e relatórios de uso separado por SP por PRO 2) Especificações de uso para pagamentos e relatório de troca de som a. Prover relatórios exclusivos por plataforma (provedor de transmissão) b. Prover a capacidade para obter informações de receitas para serem firmemente inseridos com base no tipo de plataforma e provedor por Transmissão c. Relatórios de uso por sessão de usuário exclusiva para criar Horas de Listagens Médias totais, e por sessões de audição totais d. Capacidade de agregar todas as informações de uso e relatórios de uso separado por SP 3) Especificação de uso geral para Gravadoras e editores - Usado para usos interativos. 4) Módulo de direitos "Painel de Conformidade" - capacidade de mudança de lote ou direitos de mudança individualmente (por ativos de mídia), taxa de royalties, status de apuramento e usos concedidos pelo controlador de conteúdo para vários tipos de acordo: a. Contrato de licença de Gravadora b. Contrato de Licença Residencial c. Contrato de Licença Comercial d. Contrato de Licença de Plataforma múltipla e. Contrato de Direitos conjuntos f. Contrato de Partilha de Royalty (administração de publicação) g. Renúncia/grátis 5) Capacidade de prover conta individual e agregada de todos os relatórios requisitos acima através de todas plataformas e serviços separados para a cada um dos seguintes "tipos de fonte de conteúdo" a. 100% de conteúdo de Provedor de Transmissão (SP) b. Conteúdo de servidor local c. Conteúdo P2P controlado d. Conteúdo licenciado Vertigo 6) Mecanismo de cálculo de royalties - o sistema tem a capacidade de calcular royalties devidos ao combinar os dados de uso por intervalo de datas, conteúdo, tipo de fonte e provedor de transmissão com base nas taxas inseridas no painel de conformidade. O cálculo a seguir será usado para o conteúdo do servidor local encontrar saídas. X / X + Y x (por reprodução ou taxa de hora de transmissão) = royalty total. X = conteúdo do servidor Local e Y = conteúdo de provedor por transmissão

[00112] A capacidade de calcular com precisão e gerar relatório para todas as sociedades de direitos, loja, fonte e calcular usos de conteúdo controlada de proprietários e incorporar a economia de custo de entrega para o royalty global total faz deste um tipo de serviço de cumprimento.

[00113] Esta parte do documento revela como o servidor gateway local poderia ser usado para fazer a transmissão de internet de estações de rádio tradicionais mais eficientes e aumentar a qualidade do áudio transmitido. A invenção ou esta parte da divulgação é focada em transmissões de rádio que principalmente reproduzem música em vez de talk-shows, transmissões de esporte etc... Economias significativas podem ser derivadas e a qualidade do áudio pode ser melhorada significativamente, devido ao fato de que música baseada em emissões de radiodifusão são uma mistura de áudio ao vivo e áudio pré-gravado.

[00114] Economia significativa e aumento da qualidade de áudio pode ser alcançada se o áudio pré-gravado pode ser separado da mistura de áudio ao vivo ou gravado em estúdio e entregues ao computador local através de uma rede peer-to-peer ou através de sistemas de arquivos locais (um sistema de correspondência de arquivo de metadados iria ser usado para garantir que a boa música seja tocada). O áudio pré-gravado e a mix de estúdio poderiam então ser misturados no computador local para garantir a qualidade e conteúdo de difusão consistente. A divulgação irá explicar como isso pode ser alcançado.

[00115] Métodos existentes para transmissão de rádio através da Internet são geralmente retratados na figura n° 30. Métodos atuais para a entrega de transmissões de rádio via Internet normalmente envolvem o uso de um dispositivo de reprodução de mídia em 163 (por exemplo, normalmente um computador pessoal) o qual reproduz áudio pré-gravado (faixas de música, anúncios, etc..) e emite 248 o áudio para uma mesa de som 164. Este áudio é então mixado com as observações do disc jockey e/ou comentário e outros áudios ao vivo 165 que é entrada 249 na mesa de som 164 todos em um estúdio ou sistema de gravação 170.

[00116] A mixagem de mesa de som é então emitida como em 250 para um computador 166 como uma única emissão de áudio. O computador 166 então comprime a transmissão de áudio e emite a emissão de áudio para um arquivo de áudio compactado 167 (este é geralmente um arquivo MP3). Este arquivo MP3 não tem uma duração definida, à medida que o arquivo é transmitido ao vivo e novos dados estão sendo acrescentados ao final do arquivo constantemente. Esse arquivo MP3 está normalmente localizado em uma rede de entrega de conteúdo 168 e o computador 166 que comprime e transcodifica o anexo de transmissão de áudio 251 esse arquivo com novos dados à medida que ele o comprime. A rede de distribuição de conteúdo, 168, em seguida, distribui 252 este arquivo para clientes 169. Novamente, esta é uma visão geral do sistema simples e é provável semelhante à maioria das configurações no mercado.

[00117] O sistema aprimorado de servidor gateway, de acordo com a presente invenção, é geralmente retratado nas figuras n° 26 - 29. O sistema avançado começa em um estúdio de rádio 170 e um computador 163 que emite 248 áudio pré-gravado para uma mesa de som 164. O computador 163, de acordo com a presente invenção, teria certos meios de associação do marcador de evento, como exemplificado pelo software de proprietário, o qual, quando instalado ou aplicado permite... 1. Um disc jockey enfileirar canções para um programa de rádio; o software cria uma fila de canções 171 que é então distribuída aos clientes 172, cujos clientes 172 transmitem a transmissão. A fila 171 contém canções, as quais o disc jockey planeja tocar durante a transmissão. O servidor local 184 carrega previamente 253 estas canções para que quando o disc jockey decida tocar uma música, a música estará disponível no cliente 172 para a reprodução. Essas músicas podem ser entregues através de um cliente de rede de entrega de conteúdo remoto 173, um cliente de rede peer-to-peer 174 ou correspondidas e transmitidas a partir de um sistema de arquivos local 175. 2. O software também comprime como em 256 o áudio emite 176 de volta da caixa acústica, 164. O software também insere marcadores de evento nos cabeçalhos de quadro 177 da transmissão de áudio, 179. Cada transmissão/arquivo de áudio MP3 179 consiste em quadros de áudio 178, cujos quadros áudio 178 cada um tem um cabeçalho 177. À medida que áudio novo é adicionado, novos quadros 178 são acrescentados ao arquivo. Esses cabeçalhos 177 são do comprimento de 32 bits. Dentro de cada cabeçalho 177 há um bit reservada para uso em aplicação privada. Este bit seria definido como "1" no início de um evento e definido como "0" durante a transmissão regular. Esses dados seriam incorporados em ambas as transmissões 176 e/ou 256 vindo da mesa de som 164. Cada cabeçalho 177 também contém bits que são informativos somente e não afetam a reprodução de áudio (por exemplo, "direitos autor", "original"). Cada cabeçalho 177 tem pelo menos 3 bits (incluindo o bit privado) o qual não afetaria a reprodução de áudio. Esses bits podem ser usados para criar um ID de evento. O ID seria criado usando esses bits (um bit indicador de evento a seguir) para criar uma combinação de "0" e "1" para permitir ID ' s exclusivo o suficiente para acomodar eventos o suficiente para preencher 10 segundos de reprodução. Assim, se o cabeçalho do quadro com o mesmo bit indicador original é usado junto com cabeçalho do quadro diretamente a seguir é utilizada no total de pelo menos 5 bits poderia ser usado para criar pelo menos 32 ou 25marcadores exclusivos. Isto deve ser mais do que marcadores exclusivos o suficiente para cobrir eventos o suficiente para um possível atraso de 10 segundos. Se mais marcadores são necessários, outro cabeçalho pode ser adicionado para aumentar o total de 256 a partir de 32. Uma vez que cada evento terá um marcador exclusivo dentro de um período de tempo de 10 segundo, estes marcadores podem ser usados para sincronizar dois transmissões separados (aquele que contém apenas o áudio ao vivo e o outro que seria o mix total) a entrega e a transição para uma transmissão totalmente remotamente mixada e uma transmissão mixada localmente (que seria uma transmissão de áudio ao vivo transmitido do estúdio e áudio pré-gravado mixado na transmissão nos marcadores de evento pelo servidor local). Os marcadores de evento também teriam link para instruções para imitar o mix de áudio do estúdio.

[00118] O aplicativo também cria uma fila de eventos. Esta seria uma fila de eventos a qual seria combinada para marcadores de evento com base na identificação de bit único, seguindo o marcador (como explicado acima). Esses eventos seriam registrados no computador 163 o qual comprime o áudio, para que cada evento seja registrado no quadro exato 178 no qual eles ocorrem, garante que o calendário dos eventos é incorporado na transmissão de áudio ao vivo 256 no lugar exato que ocorre na mixagem original de estúdio 176. Esses eventos irão conter informações sobre: a. Qual áudio pré-gravado áudio precisa ser reproduzido no marcador do evento. b. Em qual quadro de reprodução começa para o áudio pré-gravado. c. Em que volume deve começar a reprodução. d. E se o volume estava sendo abaixado em uma equação que melhor se adapta a direção e a inclinação do aumento/diminuição do volume. Isto será usado para imitar o aumento/diminuição do estúdio. Esta informação poderia possivelmente ser gravada por um fader periférico 180 que permite que o disc jockey controle 257 o áudio, pois é saída para a placa de som 164 e relata as alterações no volume de volta ao computador 163. e. O final do evento (isto é normalmente necessário para marcar quando aumento/diminuição para). f. E muito mais... Este é apenas um exemplo do tipo mais provável de eventos. 4. O aplicativo também atualizaria 258 no arquivo de transmissão de áudio ao vivo 181 e arquivo de mix total 182 no servidor remoto ou rede de entrega de conteúdo 150.

[00119] Uma vez que as duas transmissões 181 / 182 são registradas e codificados pelo aplicativo dentro do estúdio 170 no computador 163, ambos os arquivos 181 / 182 são 258 carregado a uma rede de entrega de conteúdo ou um servidor remoto 185 para entrega 259 aos clientes 172. Aplicações do lado do cliente 183 (por exemplo, navegadores, etc ). Envia requisitos para a transmissão de rádio usando um URL corretamente formatado. A URL é estruturada como um subdomínio do nome de domínio primário, por exemplo um URL deste formato possivelmente poderia ser usado para fazer referência a uma transmissão radiostation.vertigomusic.com/[show id]. Se não tiver sido instalado o servidor de gateway de vertigem 184, essa URL seria referir o cliente para a transmissão de estúdio totalmente misto 182 e iria reproduzir o arquivo da mesma maneira como uma tradicional transmissão de rádio do Internet (veja acima e figura n ° 30).

[00120] Se um servidor de gateway de vertigem 184 tiver sido instalado, o servidor 184 registra esse nome de subdomínio para si mesmo e, em seguida, manipula que tudo que solicitar para o nome de subdomínio 183 no aplicativo cliente local. Neste caso quando é feita uma solicitação para a transmissão por um aplicativo cliente 183, a solicitação é servida 260 por servidor do gateway 184. O servidor de gateway 184 começa por servir a transmissão totalmente misto 182 partir da rede de distribuição de conteúdo remoto 185. Uma vez que a transmissão começa as solicitações de 184 de servidor de gateway a fila de áudio pré-gravado 171 e começa a cache 253 o áudio pré-gravado de entrega de conteúdo remoto 174, peer- to-peer redes 173, ou locais fontes 175. O servidor de gateway 184 também carrega 261 a fila de eventos de um banco de dados remoto 186, que é constantemente atualizado pelo computador estúdio 163. O gateway 184 consistentemente iria receber atualizações de events261 enquanto a transmissão 181 é ao vivo.

[00121] Para a transição do mix completo estúdio 182 na transmissão ao vivo de áudio única 181, o servidor de gateway 184 carrega ambos as transmissões, 181 e 182 e só serve o mix total

[00122] 182. A fim de garantir que o servidor de gateway de 184 e o mistura aplicativo 187 têm tempo suficiente para completar todas as tarefas, o servidor 184 inicia a transmissão de 10 a 20 segundos de recepção de dados em tempo real, criando uma defasagem personalizada que pode ser usada para criar tempo para que o sistema execute a mistura e a transição. O servidor de gateway 184 aguarda um evento pouco em estúdio completo mistura 182 quadro cabeçalhos de 177 a transição para a transmissão de áudio, 181.

[00123] O servidor de gateway 184 alinha as duas transmissões 182 / 181 no evento um pouco. Isso é feito combinando o código de bit a bit de evento a seguir. Se o bit código corresponde para ambos os eventos, os eventos são considerados combinados, uma vez que apenas os últimos 1015 segundos de uma transmissão são pesquisados. Códigos de 32 bit único fornecem suficiente unicidade para garantir que os eventos correspondentes na verdade são idênticos. Uma vez que o evento bits forem correspondidas, as transições de 184 de servidor de gateway do estúdio completo misturam 182 para a mistura de áudio ao vivo 181 no quadro 178 em que o bit de evento ocorre. Usar este método fornece uma transição suave de transmissão de transmissão com precisão de quadro a quadro.

[00124] Uma vez que o servidor de gateway 184 foi transferida para o áudio ao vivo apenas 181, começa a seguir as instruções de mistura que são armazenadas no banco de dados de eventos 186 quando aparece um pouco do evento. Desde que somente os últimos 10-15 segundos da transmissão ao vivo são rastreados para evento bits, o código de bit é usado para localizar os dados de evento do banco de dados 186 que coincide com o evento pouco código.

[00125] Assim, assumindo que o primeiro evento foi para a reprodução da primeira canção dentro da fila de áudio pré-gravado 171, o aplicativo será já tem armazenado em cache pelo menos 10-20% do áudio. Neste caso, o servidor de gateway 184 passa a transmissão de áudio ao vivo 181 e os dados de áudio pré-gravado 188 para um aplicativo de misturando interno 187 (isso pode ser um aplicativo de linha de comando como SoX ou um aplicativo personalizado construído).

[00126] O servidor de gateway 184 também envia 261 os misturando dados para o aplicativo que mixagens ao vivo áudio 181 e o áudio pré-gravados para imitar o estúdio completo misturam 182. Isso é feito usando os dados que são gravados no estúdio 170 e associados com um evento para imitar o desvanecimento do disk jóquei e timing. As saídas em seguida 187 aplicativo que localmente misturado um novo arquivo 189, que em seguida é servido ao cliente solicitante 183. Isso pode tudo ser feito perfeitamente porque o servidor pode criar uma defasagem significativa entre a transmissão de dados ao vivo e servindo de dados para o aplicativo cliente. Enquanto esta defasagem é crie desde o início de servir o áudio que desse prazo de atraso pode ser usado para misturar e preparar o áudio.

[00127] Em casos onde uma estação de rádio ou mostrar somente irá ser integrar anúncios e não vai ser misturar uma transmissão ao vivo com áudio pré-gravado (por exemplo, música), o sistema contempla certos meios de integração de propaganda, que funcionarão conforme descrito abaixo e como geralmente representado nas figuras n. ° s 31 e 32.

[00128] Um programa de rádio pode ser gravado em um computador 190 através do software 191 que codificar o áudio e marcar quando um anúncio ou outro arquivo pré-gravado precisa ser jogado. Marcadores de anúncio são colocados após um tempo predeterminado de áudio silêncio. Para conseguir isso, o aplicativo de codificação 191 cria uma defasagem 300 alguns segundos a mais, então o anúncio predeterminado indicando silêncio áudio 301. Assim, se uma personalidade de rádio é gravação e necessidades para inserir uma quebra de propaganda, a personalidade de rádio simplesmente silencia ou silencia o microfone durante 5 segundos como em 301 (por exemplo). Depois de 5 segundos de silêncio (como em 301) (por exemplo) o aplicativo de codificação marca a transmissão de áudio não no final 302 dos 5 segundos de silêncio, mas no início 303. Desta forma, o ouvinte de fim não ouve o silêncio, mas um anúncio.

[00129] Uma vez o prazo pré-determinado de silêncio passou as instruções de aplicação 191 a personalidade de rádio para indicar quanto tempo anúncios deve ser jogada, e propagandas estão integradas de acordo com o período de tempo selecionado. Esta transmissão de áudio é então codificada e marcada pelo aplicativo 191 e enviado para o servidor ou conteúdo entrega rede 192 de escolher a personalidade rádio.

[00130] Quando o ouvinte de seu dispositivo 193 solicita por meio de um aplicativo de cliente 194 (por exemplo, um navegador ou aplicativo móvel) para a transmissão de rádio, a solicitação é enviada 270 com um servidor de gateway de 195. O servidor gateway 195 a 271 envia a solicitação para a transmissão de áudio para o servidor de nuvem/192, que responde e entrega 272 o áudio para o servidor de gateway de 195.

[00131] O servidor de gateway 195 então entrega 273 a transmissão de áudio para o cliente 194. O servidor de gateway 195 cria um buffer pequeno (2-5 segundos de dados), para que quando um marcador de propaganda é identificado dentro da transmissão de áudio, o servidor de gateway 195 pode buscar 274 um anúncio apropriado do servidor anúncio 196 e integrá-lo no horário especificado. Em um aplicativo móvel, o aplicativo precisa integrar os anúncios sem um servidor de gateway 194. O aplicativo móvel precisaria tê-lo integrado no código-fonte do aplicativo. Então ele teria código que detectar um marcador de propaganda e então integrar um anúncio no início do marcador de propaganda.

[00132] Enquanto a descrição acima contém muita especificidade, essa especificidade não deve ser interpretada como limitações sobre o escopo da invenção, mas sim como uma exemplificação da invenção. Por exemplo, isso está previsto que a presente invenção fornece essencialmente uma rede de distribuição de conteúdo-to-peer (P2P) para a entrega de arquivos de dados selecione (por exemplo, transmissão) para um usuário final.

[00133] A também chamado Rede de Entrega de Conteúdo P2P (CDN) ou CDN P2P, de acordo com a presente invenção compreende de preferência um cliente como em 2, um servidor de gateway de P2P como no 3, um servidor de nome de recurso (RNS) como a 4 e uma rede de computador-preenchido, qual rede de computador preenchida pode incluir servidores locais, servidores conectados por pares, nuvens cacifos, armazenamento em nuvem, nuvem de mídia e/ou comercial (música), serviço de transmissão fornece infraestrutura(s).

[00134] O cliente está em comunicação com o servidor de gateway de P2P, e o servidor de gateway de P2P está em comunicação com o RNS e a rede de computador-preenchida. O RNS funciona basicamente para cache locais de recursos de dados dentro da rede de computador-preenchida e resolver as solicitações de recurso ideal (por exemplo, (a) a maioria preço eficiente ou (b) maior qualidade da fonte de som) locais de recursos de dados dentro da rede preenchida por computador.

[00135] O servidor gateway P2P solicita e recebe localizações de recursos de dados ideais através do RNS; solicita e recebe arquivos de dados a partir de rede habitada por computador através das localizações de recursos de dados ideal; e processa arquivos de dados recebidos para entrega de arquivos de dados para o cliente e o usuário final

[00136] A rede de entrega de conteúdo ou CDN de acordo com a presente invenção incorpora uma série de opcionais, mas de preferência adicionam-na é o sistema básico de componentes, incluindo certos meios de autenticação de cliente ou servidor para verificar a autenticidade do cliente e/ou servidor, conforme discutido em um maior detalhe aqui. Além disso, em um esforço para melhorar a sua prestação de transmissões de dados não-corruptos, a presente invenção contempla certos dados entrega fragmentação significa também como discutida acima.

[00137] Locais de recurso poderão ser indexados de preferência através de certos recursos meios cooperáveis em conexão com o RNS para realçar ainda mais a eficiência de rede ou método de indexação. Nomeadamente, o recurso a meios de indexação de preferência pode incluir determinados ficheiros correspondentes meios para rapidamente e eficazmente correspondência arquivos de dados independentemente do metadados de arquivos de dados. Os meios de arquivo correspondentes de acordo com a presente invenção mais plenamente são especificados em permitidos E.U. patente aplicação n. ° 13/065,254, agora emitido E.U. patente n ° 8.589.171, para que estas especificações reivindicam um benefício, e quais as especificações foram incorporadas por referência aos mesmos.

[00138] O arquivo correspondência meios de acordo com a presente invenção assim de preferência pode incluir certos meios de extração de dados, certos meios de derivação estatística Resumo, certos meios de geração de marcador personalizado, certos meios de associação de marcador personalizado e certos meios de acesso de marcador personalizado.

[00139] Os meios de extração de dados extraem dados de forma de onda de um primeiro arquivo de dados. Os dados extraídos de forma de onda compreendem valores de segmento de comprimento, quais valores são extraídos em relação a uma base de extração de dados e incluem valores de segmento de comprimento de cocho-de-linha de base e pico-a- linha de base. A derivação de estatística Resumo significa derivar estatísticas de resumo dos dados extraídos de forma de onda, quais estatísticas de resumidas são derivados os valores do segmento de comprimento e compõem estatísticas do segmento de comprimento de cocho-de-linha de base e pico-a-linha de base.

[00140] A geração de marcador personalizado significa gerar um marcador personalizado com base em estatísticas de resumo a derivada, e a associação de marcador do cliente significa associar o marcador personalizado com o primeiro arquivo de dados, assim, construir um arquivo de dados personalizados marcado. Os meios de acesso de marcador personalizado acessam, o marcador personalizado quando comparando um segundo arquivo de dados para o arquivo de dados personalizados marcado para renderizar uma correspondência de arquivo de mídia positiva.

[00141] A rede de entrega de conteúdo P2P mais pode incluir certo meio de associação de marcador do evento para associar marcadores de evento nos cabeçalhos do quadro dos arquivos de dados para melhorar a transmissão de arquivo de dados, como discutido em mais detalhes aqui. Neste último aspecto, o leitor recordará que a presente invenção mais contempla certos meios de integração do anúncio, o que significa que pode ser ainda mais empregada para integrar o conteúdo de propaganda em arquivos de dados através dos meios de associação do marcador de evento especificado.

[00142] Dado o carácter de origem independente de dados da presente invenção, um sistema de governança de roteamento de dados ainda é contemplado. De preferência, o sistema de governança do roteamento de dados de acordo com a presente invenção compreende, em combinação, um aparelho de conformidade de roteamento de dados ou do motor e da rede de distribuição de conteúdo descrito.

[00143] Nesse sentido, o aparelho de conformidade de roteamento de dados está em comunicação com a rede de distribuição de conteúdo, qual rede de entrega de conteúdo compreende uma pluralidade de fontes de dados, que as fontes compreendem ou armazenam arquivos de dados.

[00144] A rede de entrega de conteúdo fornece dados selecione arquivos para um usuário final de um local de fonte de dados ideal, qual ideais fonte de dados local é selecionado do grupo constituído por fontes de dados. O aparelho de conformidade ou o mecanismo de acordo com a presente invenção fornece assim indústria (a) direitos de gestão (b) conformidade monitoramento e/ou relatórios de conformidade (c) arquivo das transmissões de dados.

[00145] Essencialmente, a presente invenção pode ser dito para fornecer funcionalidade para (1) entregar um transmissão de solicitação indireta de um servidor local (por exemplo, rádio digital como exemplificado pela rádio PANDORA®); entregar um transmissão de solicitação indireta de um servidor de conexão ponto a ponto; entregar um transmissão de solicitação indireta de uma segunda fonte de solicitação direta (por exemplo, iTunes Match ou Spotify ou nuvem armário como DropBox ou qualquer mídia na nuvem); entregar um transmissão de solicitação indireta de um servidor de conexão ponto a ponto com base no direito de uma fonte pedido segundo direto de reproduzir ou transmissão; entregar um transmissão de solicitação direta de uma segunda fonte de solicitação direta com base na qualidade de eficiência ou (b) o som (a) o preço da fonte; e (6) entregar um transmissão de solicitação direta de uma fonte de conexão ponto a ponto com base no direito de uma segunda fonte solicitação direta de reproduzir ou transmissão. Tendo em conta os dados origem agnóstica ou nuvem agnóstica aspectos do presente sistema, mais o sistema fornece monitoramento gestão de (b) conformidade (a) indústria direitos e/ou relatórios de conformidade (c) onde a entrega de conteúdo é proveniente de uma fonte secundária que não seja o serviço solicitado fonte original incluindo exemplos acima de 1-6.

[00146] As especificações acima serão ainda mais são acreditadas para apoiar determinada metodologia de entrega de dados de origem independente para otimamente (por exemplo, custos reduzidos) entregando selecionar dados de um usuário final em um ambiente de computador-preenchida. O método de entrega de dados de origem independente de acordo com a presente invenção pode ser dito de preferência compreende as etapas de: comunicação de um cliente, um servidor de gateway-to-peer (P2P) e um servidor de nome de recurso (RNS) com uma rede de computador-preenchida; e locais de recursos de dados dentro da rede de computador-preenchida através de RNS de cache.

[00147] Locais de recursos de dados ideal podem ser solicitadas pelo servidor de gateway de P2P através do cliente de RNS-em cache locais de recursos de dados, quais solicitações de recursos são resolvidas com locais de recurso ideal através de RNS. Os locais de recurso ideal são recebidos pelo servidor do gateway de P2P através dos dados de seus RNS arquivos da rede computador povoadas são solicitados de ou como habilitado pelos locais receberam recurso ideal. Os arquivos de dados solicitados são então transmitidos (ou seja, enviadas e recebidas) e processamento para entrega de arquivos de dados para o cliente.

Claims (15)

1. Método de entrega de dados de origem agnóstica, para a entrega de forma otimizada de arquivos de dados, selecionados para um usuário final em um ambiente habitado por computador, caracterizado pelo fato de que compreende as etapas de: associar marcadores de evento nos cabeçalhos de quadro de arquivos de dados selecionados através de meios de associação de marcador de evento e de um primeiro computador; comunicar um cliente, um servidor gateway peer-to-peer (P2P) e um Resource Name Server (RNS) com uma rede habitada por computador; realizar cache de localizações de recurso de dados dentro da rede de habitada por computador através do RNS; solicitar localizações de recurso de dados ideal por servidor gateway P2P a partir de localizações de recursos de dados em cache RNS; resolver solicitações de recursos com localizações de recurso ideal através do RNS; receber localizações de recurso ideal no servidor gateway P2P através do RNS; solicitar arquivos de dados selecionados a partir da rede habitada por computador através das localizações de recurso ideal recebidas, os meios de associação de marcador de evento para melhorar a transmissão de arquivos de dados; transmitir arquivos de dados selecionados solicitados; e processar arquivos de dados selecionados transmitidos para entrega de arquivo de dados selecionados ao cliente.

2. Método de entrega de dados de origem agnóstica, de acordo com reivindicação 1, caracterizado pelo fato de que compreende a(s) etapa(s) de prover (a) administração de direitos industriais (b) monitorar conformidade e/ou (c) relatar conformidade de transmissão de arquivo de dados.

3. Método de entrega de dados de origem agnóstica, de acordo com qualquer uma das reivindicações 1 ou 2, caracterizado pelo fato de que compreende a etapa de integrar conteúdo de propaganda em arquivos de dados através de meios de associação de marcador de evento.

4. Sistema de governo de roteamento de dados, caracterizado pelo fato de que compreende, em combinação, um aparelho de conformidade de roteamento de dados e uma rede de entrega de conteúdo, o aparelho de conformidade de roteamento de dados em comunicação com a rede de entrega de conteúdo, a rede de entrega de conteúdo compreendendo uma pluralidade de fontes de dados, as fontes de dados compreendendo arquivos de dados, a rede de entrega de conteúdo para entregar arquivos de dados selecionados a um usuário final a partir de uma localização de fonte de dados ideal, a localização de fonte de dados ideal sendo selecionada a partir do grupo consistindo em fontes de dados, o aparelho em conformidade provendo (a) administração de direitos industriais (b) monitoramento de conformidade e/ou (c) relatório de conformidade de transmissões de arquivos de dados.

5. Rede de entrega de conteúdo para entregar arquivos de dados selecionados a um usuário, caracterizada pelo fato de que compreende: meios de associação de marcador de evento, um cliente, um servidor de gateway P2P e um Resource Name Server (RNS - Servidor de Nome de Recurso) em comunicação com uma rede habitada por computador, o RNS para (1) localizações de recurso de dados de cache dentro da rede habitada por computador e (2) resolver solicitações de recursos com localizações de recurso de dados ideais dentro da rede habitada por computador, o servidor gateway para (1) solicitar e receber localizações de recursos de dados ideais através do RNS, (2) solicitar e receber arquivos de dados a partir da rede habitada por computador através das localizações de recursos de dados ideais, e (3) processar arquivos de dados recebidos para entrega de arquivos de dados para o cliente, os meios de associação de marcador de evento para associar marcadores de evento nos cabeçalhos de quadro dos arquivos de dados, os meios de associação de marcador de evento para melhorar a transmissão de arquivos de dados.

6. Rede de entrega de conteúdo, caracterizada pelo fato de que compreende um cliente (172/193), um servidor gateway peer-to-peer (150/184/195), um servidor de nome de fonte e uma rede habitada por computador, o cliente (172/193), o servidor gateway peer-to-peer (150/184/195), o servidor de nome de fonte e a rede habitada por computador cooperando mutuamente a fim de prover funcionalidade para: a. entregar uma transmissão de solicitação indireta de um servidor local; b. entregar uma transmissão de solicitação indireta de um servidor de conexão ponto a ponto; c. entregar uma transmissão de solicitação indireta de uma segunda fonte de solicitação direta; d. entregar uma transmissão de solicitação direta de uma segunda fonte de pedido direto; e e. entregar um transmissão de solicitação direta de uma fonte de conexão ponto a ponto.

7. Rede de entrega de conteúdo, de acordo com a reivindicação 6, caracterizada pelo fato de que a funcionalidade para: a. entregar a transmissão de solicitação indireta a partir de um servidor conectado ponto a ponto se baseia em um segundo direito da fonte de solicitação direta em tocar ou fazer a transmissão; b. entregar a transmissão de solicitação direta a partir da segunda fonte de solicitação direta se baseia na eficiência de preço ou qualidade de som da fonte; e c. entregar a transmissão de solicitação direta a partir da fonte conectada ponto a ponto se baseia no segundo direito da fonte de solicitação em tocar ou fazer a transmissão.

8. Rede de entrega de conteúdo, de acordo com qualquer uma das reivindicações 6 ou 7, caracterizada pelo fato de que compreende um aparelho de conformidade, o aparelho de conformidade provendo administração de direitos industriais, monitoramento de conformidade e/ou relatório de conformidade onde entrega de conteúdo tem como fonte uma fonte secundária diferente do serviço de fonte original solicitado, de acordo com a funcionalidade de processos de entrega de (a) a (e).

9. Rede de entrega de conteúdo, caracterizada pelo fato de que compreende um computador (163/190), o computador (163/190) sendo operável para implementar software de proprietário, o software de proprietário permitindo que um usuário enfileire áudio em uma fileira de áudio (171) para uma difusão e distribuição ou para difundir a fileira de áudio (171) para o cliente (172/193), o cliente (172/193) sendo operável para transmitir a difusão, uma canção selecionada podendo ser entregue ao cliente (172/193) através de um processo de entrega selecionado, selecionado a partir de processos de entrega de (a) a (e), incluindo cooperação com um servidor remoto, um cliente de rede de entrega de conteúdo remoto (173), um cliente de rede ponto a ponto (174) ou combinado e transmitido a partir de um sistema de arquivo local (175).

10. Rede de entrega de conteúdo, de acordo com a reivindicação 9, caracterizada pelo fato de que o software de associação de marcador é operável para marcadores de evento embarcados em cabeçalhos de quadro (177) de uma transmissão de áudio (179), os marcadores de evento para permitir sincronização de duas transmissões separadas (181/182), uma primeira transmissão (181) das duas transmissões separadas (181/182) contendo apenas áudio ao vivo e uma segunda transmissão (182) das duas transmissões separadas (181/182) contendo áudio misturado.

11. Rede de entrega de conteúdo, de acordo com a reivindicação 10, caracterizada pelo fato de que os marcadores de evento permitem transição para uma transmissão totalmente mixada remotamente e para uma transmissão mixada no local, a transmissão mixada no local compreendendo áudio ao vivo transmitido a partir de um computador (163/190) e áudio pré-gravado mixado ao áudio ao vivo nos marcadores de evento via aplicação de mixagem (187).

12. Rede de entrega de conteúdo, de acordo com a reivindicação 11, caracterizada pelo fato de que o software de proprietário é operável para criar uma fileira de eventos, os eventos sendo combinados aos marcadores de evento e gravados no computador (163/190), cada evento sendo registrado a um momento exato no qual eles ocorrem, garantido, com isso, marcação de tempo de evento adequada dentro de uma transmissão com base em quadro de áudio comprimido (256).

13. Rede de entrega de conteúdo, de acordo com a reivindicação 12, caracterizada pelo fato de que compreende um servidor remoto (185), as duas transmissões separadas podendo ser submetidas a upload (258) para o servidor remoto (185) a partir do computador (163/190) para entrega (259) ao cliente (172/193).

14. Rede de entrega de conteúdo, de acordo com a reivindicação 13, caracterizada pelo fato de que a aplicação da parte de cliente (183/194) é operável para fazer um pedido de transmissão por difusão, o pedido de transmissão por difusão sendo servido (260) pelo servidor (150/184/195), o servidor (150/184/195) iniciando serviço ao servir a segunda transmissão (182) a partir do servidor remoto (185), o servidor (150/184/195) pedindo, então, o enfileiramento (171).

15. Rede de entrega de conteúdo, de acordo com a reivindicação 14, caracterizada pelo fato de que o servidor (150/184/195) é operável para transição da primeira transmissão (181) para a segundo transmissão (182), o servidor (150/184/195) carregando as duas transmissões separadas (181/182) e servindo a segunda transmissão (182), o servidor (150/184/195) esperando por um evento selecionado em um cabeçalho de quadro selecionado (177) da segunda transmissão (182) para transição para a primeira transmissão (181), o servidor (150/184/195) alinhando as duas transmissões separadas (181/182) no evento de seleção, o servidor (150/184/195) fazendo a transição da segunda transmissão (182) para a primeira transmissão (181) em um quadro selecionado (178) associado ao evento selecionado, garantindo, assim, uma transição sem junções a partir da segunda transmissão (182) para a primeira transmissão (181) com precisão quadro a quadro.

Images