ОДНОРАНГОВАЯ СЕТЬ ДОСТАВКИ КОНТЕНТА, СПОСОБ И УПРАВЛЯЮЩЕЕ УСТРОЙСТВО Российский патент 2017 года по МПК H04L12/28 H04L29/08 

УРОВЕНЬ ТЕХНИКИ

ОБЛАСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение в целом относится к сети доставки контента и соответствующему способу и предлагает механизм медиасовместимости. Упомянутый механизм медиасовместимости в соответствии с настоящим изобретением работает посредством локальных шлюзовых серверов, которые используют одноранговые сети (пиринговые сети) и несколько источников данных (облаков) для оптимизации доставки медиа и упорядочения процесса отчетности. Упомянутый механизм медиасовместимости в соответствии с настоящим изобретением согласует запросы от поставщиков потоков данных с оптимизированным источником данных и сетью. Тем самым упомянутый механизм медиасовместимости может минимизировать потребление ширины полосы пропускания, затраты на лицензирование и отчетность.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение предлагает одноранговую сеть доставки контента (далее, сеть CDN), которая может быть добавлена к любой существующей стандартной сети доставки контента или конфигурации сервера без каких-либо изменений серверных систем. Одноранговая сеть CDN в соответствии с настоящим изобретением создается, когда конечный пользователь инсталлирует локальный шлюзовой сервер для одноранговых узлов на клиентский компьютер. Шлюзовой сервер принимает запрос (запросы) от потребляющего медиаклиента с помощью зашифрованных или незашифрованных соединений (например, НТТР, HTTPS, Secure Socket, и/или Socket).

Локальный шлюзовой сервер действует как одноранговый узел в одноранговой сети и имеет зашифрованную кэш-память для хранения данных для доставки на другие одноранговые узлы или для локальной доставки для потребляющего данные клиента. Локальный шлюзовой сервер может также извлекать ресурсы из связанного с ним удаленного источника данных (например, сервер или другая сеть CDN). Потребляющему данные клиенту нужно только передать один запрос на шлюзовой сервер, и шлюзовой сервер управляет ресурсами и сетевым соединением независимо от клиента. Этот тип инсталляции позволяет доставку медиа не только для автономных приложений рабочего стола, но также для браузеров и медиаплееров, и мобильных приложений, которые имеют стандартные возможности веб-браузеров (например, HTTP, HTTPS, и/или Socket).

Настоящее изобретение предлагает шлюзовой сервер одноранговых узлов (peer-to-peer,P2P), который принимает сообщение от клиента на локальный компьютер. Сообщение или запрос могут форматироваться как стандартный HTTP запрос, направленный на локальный шлюзовой сервер, который будет зарегистрирован под именем локального домена. Предполагается, что упомянутый запрос (запросы) могут форматироваться различно, если новый протокол передачи создается, который ссылается на зарезервированный порт, где размещается шлюзовой сервер. В этом случае, запрос будет форматироваться немного иным путем (т.е. без HTTP префикса).

Изобретение предлагает сервер имен ресурсов (далее, сервер RNS), при этом сервер RNS кэширует URL ресурса (универсальный адрес ресурса) и местоположения ресурсов (т.е. IP адреса) и разрешает запросы ресурсов с адресов компьютеров (машинных адресов). Общий процесс или методология для несогласованного типа медиа будут следующими.

1. Клиент направляет запрос ресурсов на шлюзовой сервер;

2. Шлюзовой сервер затем направляет запрос на сервер RNS для разрешения запроса ресурсов с адресом ресурсов;

3. Как только запрос ресурса согласован с оптимальными (наименее дорогостоящими) местоположениями ресурсов, данные местоположения ресурсов возвращаются на шлюзовой сервер;

4. Шлюз затем направляет запрос данных ресурсов соответствующим компьютерам или серверным кластерам;

5. Затем эти компьютеры и серверные кластеры отвечают, посредством передачи запрошенных данных, шлюзовому серверу, размещаемому на этом локальном компьютере.

6. Шлюзовой процесс на этом локальном компьютере подготавливает и проверяет достоверность данных и затем доставляет ресурсы клиенту.

Читатель заметит, что в традиционных отношениях клиент-сервер клиент запрашивает данные от сервера и сервер доставляет данные в соответствии с запросом клиента. В традиционной неуправляемой одноранговой сети каждый эдноранговый узел может действовать как сервер (т.е. доставляющим данные) и как клиент (т.е. принимающим данные). В неуправляемой среде запрос данных предается от однорангового узла к одноранговому узлу пока файл не будет найден.

Управляемая одноранговая сеть имеет центральный сервер, который индексирует ресурсы. Одноранговые узлы в такой сети сообщают и регистрируют свою доступность, таким образом, делая легче и быстрее поиск ресурса. В гибридной системе одноранговая сеть используется наряду с централизованным источником данных / сервером индексирования, чтобы обеспечить низкие затраты доставки одноранговому узлу, но и корректность и скорость передачи централизованного источника данных, и для того, чтобы ускорить доставку ресурсов, как в управляемой одноранговой сети. В этой ситуации совместно используется сервер источника данных и одноранговые узлы для доставки данных.

В соответствии с настоящим изобретением, клиент является автономным клиентом, и запрос данных создается и потребляется автономным клиентом (браузер, рабочий стол или мобильное приложение). Здесь в отличие от сетей, упомянутых выше, запрос данных создается не с помощью однорангового узла, но с помощью автономного клиента, как в традиционных отношениях клиент-сервер.

Шлюзовой сервер принимает запрос и затем разрешает запрос для ресурса с помощью сервера имен ресурсов (сервер RNS) (т.е. сервера индексирования ресурсов). Сервер RNS готовит ответ с местоположениями ресурсов (IP адрес), которые могут быть источниками ресурсов или одноранговыми узлами ресурсов. Учитывая то, что упомянутая сеть является инвариантной для источника данных, данные одноранговых узлов не управляются центральным сервером данных, а индексируются на сервере RNS и как запросы передаются и кэшируются на шлюзовом сервере.

Соответственно, в такой сети источник данных находится отдельно от сервера индексирования ресурсов, таким образом, позволяя автономному клиенту заполнить любой запрос от источника данных или одноранговой сети Р2Р, поскольку данные в пределах сети Р2Р кэшируются, когда запрос передается от автономного клиента.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Другие функциональные возможности нашего изобретения станут более ясными из рассмотрения следующих кратких описаний иллюстраций предмета изобретения:

На Фиг. 1 представлен схематический рисунок фрагментированного расположения для файла данных, включая строки пакетов суб-потока и столбцы пакетов проверки достоверности.

На Фиг. 2 представлен первый схематический рисунок общего представления системы в соответствии с настоящим изобретением, изображающий шлюзовой сервер, расположенный между облаком серверных кластеров и сервером имен ресурсов.

На Фиг. 3 представлен второй схематический рисунок общего представления системы в соответствии с настоящим изобретением, изображающий шлюзовой сервер, расположенный между облаком серверных кластеров и сервером имен ресурсов.

На Фиг. 4 представлен схематический рисунок общего представления системы сервера имен доменов.

На Фиг. 5 представлен схематический рисунок общего представления системы сервера имен ресурсов.

На Фиг. 6 представлен схематический рисунок общего представления не встраиваемого средства безопасности.

На Фиг. 7 представлен схематический рисунок традиционных взаимосвязей клиент-сервер, когда клиент запрашивает данные и сервер доставляет данные.

На Фиг. 8 представлен схематический рисунок общего представления неуправляемой одноранговой сети, где каждый одноранговый узел может действовать как сервер и как клиент, где запросы данных передаются от однорангового узла к одноранговому узлу, пока не будет найден файл.

На Фиг. 9 представлен схематический рисунок общего представления управляемой одноранговой сети, в которой централизованный сервер индексирует ресурсы и в которой одноранговые узлы сообщают и регистрируют их доступность.

На Фиг. 10 представлен схематический рисунок общего представления централизованной гибридной одноранговой сети, в которой одноранговая сеть используется наряду с централизованным источником данных / сервером индексирования, чтобы обеспечить низкие затраты доставки для однорангового узла, но и корректность и скорость централизованного источника данных.

На Фиг. 11 представлен схематический рисунок общего представления шлюзового сервера одноранговой сети.

На Фиг. 12 представлен схематический рисунок того, как безопасные соединения структурированы через локальный сервер и браузер.

На Фиг. 13 представлен схематический рисунок того, как через подключение проверяется подлинность шлюзового сервера.

На Фиг. 14 представлен схематический рисунок индексации ресурсов с первоначальным запросом и без сопоставления файлов.

На Фиг. 15 представлен схематический рисунок варианта индексации ресурсов с последующим запросом и без сопоставления файлов.

На Фиг. 16 представлен схематический рисунок варианта развивающейся облачной индексации с первоначальным запросом.

На Фиг. 17 представлен схематический рисунок варианта локальной индексации ресурсов.

На Фиг. 18 представлен схематический рисунок первого варианта процесса обработки запроса индексированных ресурсов.

На Фиг. 19 представлен схематический рисунок второго варианта процесса обработки запроса индексированных ресурсов.

На Фиг. 20 представлен схематический рисунок третьего варианта процесса обработки запроса индексированных ресурсов.

На Фиг. 21 представлен схематический рисунок четвертого варианта процесса обработки запроса индексированных ресурсов.

На Фиг. 22 представлен схематический рисунок варианта облачной доставки, сублицензирования.

На Фиг. 23 представлен схематический рисунок варианта сублицензирования доставки для одноранговых узлов.

На Фиг. 24 представлен первый схематический рисунок поставщика потоковой передачи при запросе воспроизведения песни на мобильном устройстве в соответствии с настоящим изобретением.

На Фиг. 25 представлен второй схематический рисунок поставщика потоковой передачи при запросе воспроизведения песни на мобильном устройстве в соответствии с настоящим изобретением.

На Фиг. 26 представлен схематический рисунок общего вида расширенной шлюзовой серверной системы в соответствии с настоящим изобретением.

На Фиг. 27 представлен схематический рисунок структуры очереди предварительно записаного медиа в соответствии с настоящим изобретением.

На Фиг. 28 представлен схематический рисунок механизма деления потока в соответствии с настоящим изобретением.

На Фиг. 29 представлен схематический рисунок МР3 файловой структуры в соответствии с настоящим изобретением, изображающий заголовки кадров и аудиокадры аудиопотока.

На Фиг. 30 представлен схематический рисунок способов современного уровня техники для потокового радио через сеть Интернет.

На Фиг. 31 представлен схематический рисунок общего вида системы для интеграции рекламы без микширования звука в соответствии с настоящим изобретением.

На Фиг. 32 представлен схематический рисунок с представлением варианта рекламного маркера в соответствии с настоящим изобретением.

На Фиг. 33 представлен схематический рисунок методологии, связанной с маршрутизацией HTTP запросов от браузеров и/или других потребляющих медиаклиентов.

ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНОГО ВАРИАНТА

ОСУЩЕСТВЛЕНИЯ СПОСОБА / МЕТОДОЛОГИИ

Как показано на чертежах и в более подробном описании, настоящее изобретение предлагает сеть доставки контента и соответствующую технологию для облачной независимой потоковой передачи данных между одноранговыми узлами. Как рассматривалось выше, изобретение содержит шлюзовой сервер для связи между одноранговыми узлами (Р2Р), который обозначен как 3. Упомянутый Р2Р шлюзовой сервер 3 принимает передачи данных (показано как 200) от клиента 2 на локальном компьютере 101.

Эти запросы могут форматироваться как стандартные HTTP запросы, направляемые на локальный шлюзовой сервер 3, который будет зарегистрирован под именем локального домена. При этом имеются различные способы запросов маршрутизации HTTP от веб-браузеров и других устройств, которые могут включать в себя использование локально зарегистрированных доменных имен и протоколов, следующий способ является предпочтительным при маршрутизации HTTP запросов от браузеров и других потребляющих медиаклиентов.

Потребляющему данные клиенту 2 дается полностью форматированное доменное имя для удаленных одноранговых серверов 4 или серверов 4 имен ресурса. Ради простоты, читатель рассмотрит доменное имя www.rns_server.com. Для того чтобы запросить медиа 401 (см. фиг. 33) через сеть доставки контента (сеть CDN) одноранговых узлов, обозначенную как 144, клиент 2 содержит в себе унифицированный указатель ресурса (URL) с RNS открытым доменным именем, и переменную GET с местоположением запрошенного медиа, что-то вида.

www.rns_server.com?media=www.somemediasource.com/media.mp4&protocol=http.

Когда сервер RNS 4 принимает запрос, он делает запросы 404 двух различных баз данных. Первый запрос использует открытый адрес протокола сети Интернет (IP) запрашивающих устройств, чтобы идентифицировать, существуют ли какие-нибудь сетевые одноранговые узлы 3 в пределах локальной сети 101 запрашивающих устройств. Второй запрос выполняет поиск базы данных ресурсов, чтобы идентифицировать одноранговые узлы 3 с запрашиваемым медиа, доступным для потоковой передачи (показано как 200, 207, 208, 209, и 210) в пределах одноранговой сети CDN 144 (peer-to-peer, Р2Р).

На основе запросов 404 может произойти следующее. Во-первых, если отсутствует зарегистрированный одноранговый узел на локальной сети, то запрос перенаправляется, показано как 403 (фиг. 30), на удаленный источник 104 медиа, и Р2Р сеть 144 не будет использоваться. Если имеется зарегистрированный одноранговый узел 3 в пределах локальной сети 101, то запрос перенаправляется, показано как 402 (фиг. 30), на одноранговый узел 3 локальной сети наряду с данными о местоположении ресурса и данными о доступности, которые были извлечены во втором запросе 404. Одноранговый узел 3 локальной сети затем обрабатывает медиапоток (показано как 200, 207, 208, 209, и 210).

Таким образом, читатель поймет, что сервер имен ресурсов (сервер RNS), который указан как 4, занимает центральное место для осуществления на практике настоящего изобретения. Сервер RNS 4 кэширует указатели URL ресурсов и местоположения ресурсов (IP адреса), и разрешает запросы ресурсов с адресами компьютеров (IP адреса). Обычный процесс для несогласованного типа медиа будет выглядеть следующим образом. Клиент 2 передает запрос ресурсов (показано как 200) на шлюзовой сервер 3.

Шлюзовой сервер 3 затем передает запрос (показано как 201) на обособленный сервер RNS 4 для принятия решения (показано как 202) запроса (показано как 203) идентификатора ID входящего ресурса / URL с адресом ресурса (показано как 204), упомянутый ресурс или IP адрес затем передается обратно (показано как 205) на шлюзовой сервер 3, как более подробно изображено на Фиг. 5. Другими словами, как только запрос 203 ресурса согласован, показано как 202, с оптимальными (например, (а) с наиболее эффективной стоимостью или (b) наиболее высоким качеством звука источника) местоположениями ресурсов 204, данные местоположения ресурсов или IP адрес (адреса) 204 возвращаются 205 на шлюзовой сервер 3.

Шлюзовой сервер 3 затем передает (показано как 206, 207, и 208) запрос (запросы) данных ресурсов для соответствующих компьютеров (102 и/или 103) или серверных кластеров показано как 104. Упомянутые компьютеры 102 / 103 или серверные кластеры 104 затем отвечают посредством передачи (показано как 209) данных, которые запрашиваются, на шлюзовой сервер 3, размещаемый на компьютере 101. Шлюзовой сервер 3 на компьютере 101 обрабатывает (т.е. подготавливает и проверяет подлинность) данные, которые были переданы на 209, и затем доставляет 210 ресурсы для клиента 2.

Конкретные отношения клиент-сервер-одноранговый узел в основном схематически изображены на фигурах 7, 8, 9, и 10. Традиционные отношения клиент-сервер изображены на Фиг. 7; неуправляемые одноранговые сети изображены на Фиг. 8; управляемые одноранговые сети изображены на Фиг. 9; и централизованные / гибридные одноранговые сети изображены на Фиг. 10.

В традиционных отношениях клиент-сервер клиент 105 запрашивает 211 данные от сервера 106 и сервер 106 доставляет 212 данные циклическим способом, как изображено на Фиг. 7. В традиционной неуправляемой одноранговой сети каждый одноранговый узел (или сочетание клиент/сервер) 107 может действовать как сервер 106 для доставки данных и как клиент 105 для приема данных. В неуправляемой среде, как в целом изображено на Фиг. 8, запрос 211 данных передается от однорангового узла 107 к одноранговому узлу 107 пока не будет найден файл.

Управляемая одноранговая сеть, как в целом изображено на Фиг. 9, имеет централизованный сервер 108 индексирования ресурсов, который функционирует для индексирования ресурсов. Индексированные ресурсы доставляются 213 одноранговым узлам 107 с использованием последующих запросов 214. Доступность индексированных ресурсов затем сообщается и регистрируется посредством одноранговых узлов 107. Этот тип устройства делает быстрее и легче нахождение ресурса.

В гибридной системе, в целом изображенной на Фиг. 10, одноранговая сеть используется наряду с централизованным источником данных / сервером индексирования 109. Как индексированные ресурсы, так и данные доставляются 215 на узлы 107 от сервера 109 после запрашивания 216 ресурсов и данных узлом (узлами) 107. Этот тип устройства обеспечивает низкие затраты доставки одноранговыми узлами, но и корректность и скорость централизованного источника данных, и ускорение доставки ресурсов, как в управляемой одноранговой сети. В этой ситуации происходит смешивание данных от сервера 109 и одноранговых узлов 107, доставляющих данные.

В одноранговой сети 144 доставки контента (сеть CDN), в целом изображенной на Фиг. 2 и Фиг. 3, клиент 2 является автономным клиентом. Другими словами, запрос данных подготавливается и потребляется автономным клиентом 2 (т.е. браузер, рабочий стол или мобильное приложение). В отличие от других сетей, запрос данных происходит не с помощью узла 107, но с помощью автономного клиента 2, как в традиционных отношениях клиент-сервер, как в целом изображено на Фиг. 7.

Шлюзовой сервер 3 принимает запрос от клиента 2 и затем принимает решение запроса ресурса вместе с сервером имен ресурсов или RNS, или сервером 4 индексирования ресурсов. Сервер RNS 4 дает ответ с местоположениями ресурсов (например, IP адрес), упомянутые местоположения ресурсов могут быть первичными источниками ресурсов или одноранговыми узлами. Предполагается, что сеть является не зависящей от источника данных, данные одноранговых узлов не управляются посредством центрального сервера данных, а индексируются на сервере RNS 4 как запросы, которые передаются и кэшируются на шлюзовом сервере 3.

В такой сети источник данных находится отдельно от сервера индексирования ресурсов RNS 4. Это позволяет заполнить любой запрос данных автономным клиентом 2 от источника данных или от одноранговой сети, поскольку данные в пределах одноранговой сети кэшируются, когда запрос передается от автономного клиента 2.

Настоящее изобретение не ограничивается использованием HTTP или WebSockets, но может также использовать стандартные протоколы передачи файлов (FTP, WebDAV, SMB, AFP и т.д.). В этом случае клиент будет автономным FTP (или любым клиентом стандартного протокола передачи данных). Если директория FTP (или WebDAV, SMB, AFP и т.д.) монтируется как сетевой накопитель в пределах операционной системы, то упомянутая операционная система будет действовать как клиент. В этой ситуации шлюзовой сервер будет работать как файловый сервер.

В частности, имеются некоторые проблемы безопасности в таком устройстве. Предлагаемое решение или устройство в соответствии с настоящим изобретением потенциально является уязвимым для ситуаций "атака через посредника" и/или несанкционированный клиентский доступ. Эти проблемы могут быть урегулированы посредством предоставления конкретному клиенту и/или серверу средств аутентификации. Клиентские и/или серверные средства аутентификации в основном функционируют для проверки клиента и/или подлинности сервера.

Клиентские и/или серверные средства аутентификации могут быть иллюстрированы посредством нескольких различных механизмов, как описано более подробно здесь далее. Например, упомянутые средства аутентификации могут предоставляться посредством способа встроенной аутентификации медиа (клиентская аутентификация) и расширений браузера, которые проверяют достоверность локального сервера, чтобы убедиться, что это не вредоносный сервер (это потребует каких-то уникальных идентификаторов ID, маркеров сеансов или использования криптографической пары).

Скрипты на стороне клиента наряду с встроенными модулями программного обеспечения могут также использоваться для аутентификации как клиента, так и сервера, путем внедрения той или иной формы проверки идентификации в пределах дополнительного модуля программного обеспечения, что затем передается для скриптов стороны клиента, которые проверяют достоверность проверки идентификации с использованием AJAX. Использование скриптов на стороне клиента в тандеме с дополнительным программным модулем браузера является предпочтительным, поскольку это обеспечивает проверку как клиента, так и сервера в одном процессе. Этот способ рассматривается ниже.

Со ссылкой на фигуры 12 и 13, читатель будет рассматривать проверку клиента через встроенный программный модуль браузера и скрипты на стороне клиента. Процесс создания безопасного соединения начинается с инсталляции локального сервера. После инсталляции, сервер создает подписанный им самим сертификат и добавляет этот подписанный им самим сертификат к корню дерева сертификата. Это позволяет серверу создать безопасное соединение от браузера.

Для добавления другого уровня безопасности локальный сервер 110 загружает множество вхождений 24 дополнительного программного модуля браузера обработки медиа (например, flash, sliver light и т.д.). Локальный сервер 110 может легко загружать более чем 1000 множественных вхождений 24 дополнительного программного модуля браузера обработки медиа. В каждое вхождение встраивается индивидуальный ключ шифрования, показано как 27. Вместо загрузки множественных вхождений, ключ 27 шифрования может вводиться в компонентный файл встроенного программного модуля, если библиотеки дополнительного программного модуля позволяют вводить пользовательский код.

Когда браузер создает безопасное соединение, показано как 26, сервер 110 создает индивидуальный сеанс для инициированного соединения и затем объединяет сеанс с медиавхождением 24 дополнительного программного модуля и его встроенным ключом 27 шифрования или создает ключ 27 шифрования и вводит его в компонентный файл встроенного программного модуля. Упомянутый компонентный файл 25 дополнительного программного модуля затем загружается в браузер 111. Упомянутый файл 25 дополнительного программного модуля шифрует все запросы, которые поступают от браузера 111 через сценарий на стороне клиента, и передает их на сервер 110 через зашифрованное соединение 26. Индивидуальный ключ 27 шифрования может также быть индивидуальным маркером, используемым для подписи запросов для проверки их достоверности.

Для того чтобы извлечь ключ шифрования или маркер 27, нужно декомпилировать файл 25 дополнительного программного модуля, вручаемый локальным сервером 110, и затем повторно установить соединение с сервером 110, используя новый "взломанный" экземпляр дополнительного программного модуля. Однако, поскольку сервер 110 выбирает иной ключ 27 шифрования в каждом сеансе в момент, когда новое безопасное сокет соединение 26 устанавливается, действие предыдущего ключа 27 шифрования заканчивается. Это делает ключ шифрования 27, извлекаемый посредством декомпилирования, непригодным.

Одной из основных проблем использования локального сервера для доставки контента является возможность "атаки через посредника", в этом сценарии вредоносное программное обеспечение может выступать в качестве действительного шлюза и, возможно, перехватывать пользовательские данные. Для того чтобы предотвратить эту форму атаки, настоящая система использует способы, которые требуют от локального сервера 110 проверить подлинность действительного шлюза посредством представления идентификации 31 аутентификации действительного сервера через компоненту 25 дополнительного программного модуля браузера. Этот процесс описан более подробно далее.

Каждый локальный шлюзовой сервер 110 регистрирует (показано как 19) себя с использованием удаленного хоста 112 посредством создания идентификации 31 проверки (идентификации проверки правильности регистрации), которая подключена к протоколу сети Интернет общего пользования локального компьютера. Эта идентификация 31 проверки и ее связанный протокол сети Интернет общего пользования хранятся в базе данных 29 на удаленном хосте 112. Когда загружается веб-страница 30, которую будет использовать локальный шлюзовой сервер 110, браузер 111 передает запрос (показано как 217) на локальный сервер 110. Сервер 110 отвечает посредством представления своей идентификации 31 проверки.

Браузер 111 затем передает запрос (показано как 218), используя идентификацию 31 проверки, на удаленный хост 112. Если идентификация 31 проверки соответствует упомянутому адресу протокола сети Интернет и идентификации проверки, хранящейся в удаленной базе данных 29, удаленный сервер 112 передает ответ по пути 218, подтверждая локальный шлюзовой сервер 110. После проверки, браузер 111 затем переходит к загрузке (показано как 26) медиа дополнительного программного модуля 24 из локального сервера 110. Медиа дополнительный программный модуль 24 затем создает безопасное соединение 219 для локального шлюзового сервера 110, через которое он будет доставлять данные (например, данные на основе музыки).

Со ссылкой на Фиг. 6, читатель рассмотрит меры безопасности без дополнительного программного модуля. Способ, который не требует использования медиа дополнительного программного модуля в соответствии с настоящим изобретением, подразумевает наличие клиента 2, передающего запрос (показано как 220) идентификации 113 для регистрируемого сеанса от шлюзового сервера 3 для проверки достоверности его подлинности. Идентификация 114 сеанса предварительно регистрируется (показано как 221) шлюзовым сервером и является недействительной после единственной аутентификации.

Это требует от шлюзового сервера 3 регистрации нескольких сеансов 114 заблаговременно, и каждая идентификация 113 сеанса является действительной только для одного подтверждения. Шлюзовой сервер 3 представляет (показано как 222) идентификацию 113 сеанса клиенту 2. Клиент 2 затем проверяет подлинность (показано как 223) принятой идентификации 115 сеанса с помощью сервера 116 проверки. Упомянутый сервер 116 проверки сопоставляет (показано как 224 и 225) идентификацию 115 сеанса, передаваемую клиентом 2, с идентификациями 114 регистрированных сеансов. Если соответствие найдено, тогда сервер 116 проверки подтверждает (показано как 224) для клиента 2 достоверность шлюзового сервера 3.

Существуют другие альтернативные способы, чтобы гарантировать правомерное соединение, включая интеграцию операционной системы, которая будет иметь локальное доменное имя, зарезервированное для шлюзового сервера, так что другие приложения не могут выступать как легитимный шлюзовой сервер, или через создание протокола передачи для передачи данных через такую систему. Оба из этих решений являются возможными решениями. Решение с пользовательским протоколом, однако, требует другого форматирования запроса, как иллюстрируется ниже:

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

(a нehttp://vertigo/domain.com/resource_directory/resource_name?var=123)

Другим способом защиты системы является - ограничить контент, доставляемый через эту систему, для медиа (музыка, изображения, видео и т.д.), и ограничить распределение файлов для контента, который не связан со структурой и кодом веб-сайта или приложения. Этот способ является более трудным для импортирования вредоносного кода, поскольку только медиафайлы разрешены. Это делается с учетом требований безопасности. Другими словами, HTML, Javascript, CSS, PHP файлы и т.д. не могут быть доставлены через шлюзовой сервер. Другим ограничением является то, что клиент (браузер) должен иметь ограничение на использование такого шлюза или протокола, если веб-сайт (структура, код и медиа) загружается через http и является чувствительным.

Со ссылкой на Фиг. 1, читатель будет рассматривать аспекты достоверности конкретных данных и аспекты безопасности в соответствии с настоящим изобретением. Одна из проблем в сети CDN 144, не зависящей от источника данных, заключается в достоверности данных. Если, например, один из одноранговых узлов имеет вредоносные данные, или если кто-нибудь создал вредоносный одноранговый узел, который регистрирует файлы, которые не связаны с исходными данными, как кэшированную одноранговым узлом версию исходного файла, надежность и полезность системы могут быть под угрозой.

Именно поэтому способы проверки и фрагментации данных должны включаться для того, чтобы система была надежной и полезной. Таким образом, для того чтобы сохранить отдельный одноранговый узел от возможного повреждения или целенаправленного замещения данных ненадлежащим образом является предпочтительным фрагментировать доставку данных через несколько одноранговых узлов посредством конкретных средств фрагментации доставки данных. Средства фрагментации доставки данных в соответствии с настоящим изобретением могут быть иллюстрированы посредством нескольких механизмов. Фрагментация доставки данных, например, может достигаться посредством разбиения данных 199 на пакеты или суб-потоки показано как строки 117, 118, 119, и 120. Фрагментация может быть оптимизирована для соответствия требованиям системы.

Фрагментация может быть сделана посредством простого ограничения доставки каждым одноранговым узлом максимально примерно до трети или четверти конкретного медиафайла. Это управляется с использованием сервера имен ресурсов или сервера RNS 4, как рассматривается более подробно ниже. Наряду с фрагментацией доставки данных, каждый файл данных имеет пакет для проверки для конкретного сектора данных, показано как столбцы 121, 122, 123 и 124. Это делается, поскольку каждый одноранговый узел, который подает данные, должен сначала кэшировать медиа перед их подачей снова. Соответственно, в качестве примера, если одноранговый узел доставляет суб-поток 117 данных, то он будет также доставлять наряду с этими данными пакет для проверки для сектора 121 файла. Этот пакет для проверки является контрольной суммой, созданной посредством заранее определенного алгоритма.

Следовательно, если одноранговый узел, передающий суб-поток 118, желает доставить данные, которые были повреждены или являются злонамеренными, принимающий узел будет способен обнаружить это посредством использования контрольной суммы для проверки от узла, передающего суб-поток 117, для проверки достоверности контента, доставляемого одноранговым узлом, передающим суб-поток 118. Если для контента не может быть проверена достоверность, то упомянутый одноранговый узел передает запрос данных для источника оригинала или источника исходных данных. Настоящее изобретение также предусматривает установление минимального ежедневного порога запросов, что позволит такое подтверждение данных одноранговых узлов. В ином случае, сервер проверки будет подавать контрольные суммы, и эти контрольные суммы будут созданы при первом запросе, переданном на шлюзовой сервер ресурса.

Со ссылкой на фигуры 4 и 5, читатель сравнительно рассмотрит конкретные отличия между сервером доменных имен (сервер DNS) и сервером имен ресурсов (сервер RNS). Главным отличием между сервером DNS 130 и сервером RNS 4 является то, как обрабатывается запрос ресурса. В сервере DNS 130 запрос ресурса (показано как 226) разрешается (показано как 227) для доменного имени 129 или начала полномочий (SOA) 126, которые имеют определенный ресурс 127 в директории 128 SOA 126. Клиент 2 принимает (показано как 228) IP адрес SOA от DNS и затем осуществляет запрос (показано как 229) ресурса 127 из SOA 126.

В сервере имен ресурсов или RNS 4, RNS 4 разрешает (показано как 202) запрос (показано как 201) ресурса для нескольких компьютеров, которые имеют отдельный ресурс, хранящийся или кэшированный. Соответственно, IP адрес SOA с упомянутым ресурсом может быть возвращен (показано как 205) как достоверное местоположение ресурса, но также как IP адрес для кэшируемых узлом ресурсов. Другими словами, в системе DNS указатель URL больше напоминает адрес конкретного ресурса, в сервере RNS 4, указатель URL 240 рассматривается как индивидуальный идентификатор, соответствующий отдельному ресурсу, для нескольких местоположений.

Конкретные средства для индексации ресурсов без сопоставления файлов изображены на фигурах 14 и 15; и конкретные средства для индексации ресурсов с сопоставлением файлов изображены на фигурах 16 и 17. Одним из основных вопросов, который возникает, когда имеем дело с совместимостью, является вопрос, как проверить, что в настоящее время воспроизводится. Метаданные часто повреждены или изменены пользователем. Следовательно, чтобы более эффективно передавать поток локального медиа, необходимо предложить способ проверки с очень высокой степенью уверенности, что медиафайл или музыкальная композиция на локальном накопителе соответствуют тем, которые хранятся в облаке.

Это осуществляется посредством использования средства или системы сопоставления файлов, независимых от метаданных, и индексации всех локальных файлов и сопоставления их с облачными файлами. Имеются два источника файлов, которые должны быть сопоставлены с библиотекой в соответствии с настоящим изобретением, включая (1) те, которые происходят от других поставщиков потоковых данных или поступают от внешних облаков, и (2) те, которые размещаются на локальном компьютере.

Как показано на Фиг. 16, процесс прогрессивной индексации 247 начинается с запроса, который поступает из клиентского приложения 3-й стороны. Это может быть автономное приложение рабочего стола, показано как 131, или веб-сайт, воспроизводящийся через браузер, показано как 132. Упомянутое приложение 131 или браузер 132 передает параллельно соответственно отформатированный и проверенный URL (показано как 241 и 242) на локальный шлюзовой сервер (133). Локальный шлюзовой сервер 133 использует унифицированный указатель ресурса (URL) (показано как 241 и 242) для извлечения запрошенного ресурса для потоковой передачи (показано как 243 и 244) из соответствующих облаков 245 и 246 (или соответствующей одноранговой сети, или ресурса на основе любой возможной сети). Как только ресурс был загружен для потоковой передачи, показано как 243 и 244, локальный сервер 133 начинает упомянутый процесс индексации, показано как 247 (с подпрограммами 248-252). Локальная ресурсная индексация 253 в целом изображена на Фиг. 17 (с подпрограммами 254-258).

Обработка 259 запроса индексированного ресурса в целом изображена на Фиг. 18. После того как ресурс был индексирован, следующий процесс происходит тогда, когда последующие запрашивания осуществляются от клиентов 3-й стороны. Предполагая, что поставщик услуги потоковой передачи медиа (показано как 132) подает запрос 242 на локальный сервер 133 с использованием его стандартных указателей URL, запрос 242 поступает и локальный сервер 133 запрашивает базу 135 данных локальной файловой системы и сервер индексирования 134 для определения того, был ли ресурс ранее индексирован. (Указатель URL используется для определения того, существует ли он на сервере индексирования 134 или в локальной файловой системе 137.) В этом случае, локальный сервер 133 определяет, что ресурс был индексирован и доступен на одноранговой сети 138. Медиа затем извлекается из одноранговой сети 138 и подается для поставщика услуги потоковой передачи медиа (показано как 132) для воспроизведения.

В другом случае, поставщик услуги потоковой передачи медиа (показано как 131) делает подобный запрос с использованием URL. Здесь сервер 133 определяет с использованием запрашивания локальной базы данных, что указывает на то, что ресурс индексируется и ассоциируется с локальным файлом 137. Сервер 133 затем подает этот файл, например, на стример музыки третьей стороны на основе облаков (например, Spotify) (показано как 131). Вполне вероятно, что системы или приложения, которые получают доступ к локальному шлюзовому серверу (133), передадут все ресурсы, которые будут необходимы во время сеанса, когда начинается сеанс. Сервер 133 будет затем вытаскивать соответствующие поля из сервера индексирования ресурсов (134). В этом способе все индексированные данные хранятся локально для быстрого доступа и маршрутизации.

Шлюзовой сервер в соответствии с настоящим изобретением обеспечивает конкретные средства как для интеллектуальной маршрутизации, так и для передачи лицензионного платежа, при передаче данных (например, музыки). Предполагая, что музыка может передаваться от нескольких источников, локальные шлюзовые серверы в соответствии с настоящим изобретением доставляют как интерактивные, так и неинтерактивные запросы музыки, осуществляемые посредством приложения клиента, и осуществляют маршрутизацию действительной передачи из оптимального (например, (а) с наиболее эффективной стоимостью или (b) с наиболее высоким качеством звука источника) местоположения как по затратам ширины полосы пропускания, так и по лицензионным платежам. Такая система приводит к уникальному механизму совместимости или приспособлению совместимости, позволяющему использование сообщений и лицензионные платежи, чтобы быть сгенерированными из и через несколько типов сервисных платформ, соответствуя всем стандартам и требованиям обладателей прав.

Примеры источников передачи включают в себя, но не ограничиваются: (1) стример на основе облака; (2) поставщик из хранилища на основе облака третьей стороны, который делает покупки данных доступными для владельца устройства; (3) виртуальный ящик на основе облака Vertigo (защищенный с помощью 512(c) закона об авторском праве); (4) Vertigo-лицензированная музыка, управляемая пользовательскими / суб-сервисными согласованными данными; (5) находящиеся в локальной собственности и хранящиеся музыкальные файлы, доступные на устройстве слушателя или другом находящемся в собственности и квалифицируемом устройстве, подключенном через Wi-Fi; (6) передача на мобильное устройство от подключенного PC; (7) находящиеся в собственности файлы одноранговых узлов, доступные для передачи и для которых осуществляется маршрутизация в замещении файла перед его потоковой передачей от No. 1, No. 3 и No. 4, перечисленных здесь выше.

Несколько примеров маршрутизации музыки и осуществления отчетности результатов маршрутизации заключаются в следующем. Со ссылкой на Фиг. 19, читатель будет рассматривать, когда слушатель прослушивает неинтерактивный Интернет радиоканал через соответствующего потокового клиента (показано как 140) (например веб-сайт или автономное приложение рабочего стола) и поставщик услуги Интернет радио готов начать потоковую передачу (показано как 230) файла 139 уже хранящегося и доступного на устройство слушателя. Шлюзовой сервер 141 в соответствии с настоящим изобретением сопоставляет (показано как 231) индексированный локальный файл 139 с поступающим запросом для поставщика услуги Интернет радио и передает поток (показано как 232) упомянутого файла 139 вместо воспроизведения из облака поставщика услуги Интернет радио, показано как 142.

В частности, все ресурсы, будь то локальные или удаленные ресурсы, индексируются, что позволяет быстрое сопоставление. После потоковой передачи 232 об использовании локального файла сообщается, показано как 233, на сервер 143 соблюдения (прав). Вполне возможно, что лейблы потребуют, чтобы поставщик услуги Интернет радио заплатил небольшую плату при потоковой передаче 232 локальных файлов 139, так как не существует никакого способа гарантировать, что они не являются пиратскими. В результате эффективного назначения ресурсов в соответствии с сервером 141, поставщику услуги Интернет радио 140 не придется платить за ширину полосы пропускания или платить за полное лицензирование, и эта экономия средств может затем передаваться поставщику услуги Интернет радио.

На Фиг. 20 предприняты усилия изобразить сценарий, когда слушатель прослушивает неинтерактивный канал поставщика услуги Интернет радио и клиент 140 поставщика услуги Интернет радио готов начать потоковую передачу (показано как 230) файла недоступного на устройстве слушателя, но доступного на узле 141 в пределах одноранговой сети 144 в соответствии с настоящим изобретением. Не существует экономии для лицензионного платежа для поставщика услуги Интернет радио, но одноранговая сеть 144 в соответствии с настоящим изобретением передает, показано как 233, упомянутый файл 139 в замещение файла поставщика услуги Интернет радио при экономии ширины полосы пропускания для поставщика услуги Интернет радио. Сервер 141 может затем сообщать на 233, какая музыкальная композиция была воспроизведена, серверу 143 соблюдения, если требуется.

На Фиг. 21 предприняты усилия изобразить сценарий, когда слушатель создает список для воспроизведения из десяти музыкальных композиций в их аккаунте, показано как 145, поставщика услуги потоковой передачи медиа для отдельного события. Упомянутый слушатель случился быть владельцем ресторана или менеджером, и упомянутое событие является общественным мероприятием на коммерческих условиях. Аккаунт 145 поставщика услуги потоковой передачи медиа не позволяет использования на коммерческих условиях, хотя три из музыкальных композиций в действительности доступны для загрузки на локальный носитель данных через ящик хранения облака слушателя, при этом лицензионное соглашение купленного медиа также не позволяет передачу на коммерческих условиях.

Устройство 146 поставщика с коммерческой лицензией устанавливается в помещениях с легальными правами для широковещательной передачи всех 10 музыкальных композиций, но только пять из запрошенного списка для воспроизведения из десяти музыкальных композиций доступно на локально установленном устройстве 146 поставщика. Система в соответствии с настоящим изобретением синхронизирует список для воспроизведения, сделанный в медиаплеере 145 поставщика потоковой передачи медиа и сопоставляет (показано как 231) пропущенные файлы с файлами, доступными в Vertigo облаке, и передает 234 упомянутые музыкальные композиции на устройство 146 поставщика с коммерческим лицензированием согласно лицензионному соглашению поставщика. Эта передача может поступать от Vertigo одноранговой сети 144 в зависимости от стоимости ширины полосы пропускания. Вся передача и потоковая передача могут сообщаться 233 посредством сервера 141 (если требуется) серверу 143 соблюдения для отслеживания числа раз, когда музыкальная композиция была воспроизведена.

В сценарии, изображенном на Фиг. 24, поставщик 147 потоковой передачи запрашивает, чтобы музыкальная композиция 151 воспроизводилась на мобильном устройстве 148. Запрос передается от приложения 149 мобильного устройства на мобильное устройство 148, и направляется на удаленный сервер 150 в соответствии с настоящим изобретением. Если упомянутое мобильное устройство 148, запрашивающее 237 музыкальную композицию, соединяется, показано как 235, с персональным компьютером 152, который имеет упомянутый файл, хранящийся локально, вместо маршрутизации запроса музыкальной композиции серверу 147 исходных данных (т.е. сервер поставщика потоковой передачи), запрос передается на персональный компьютер 152, и передается поток, показано как 236, от персонального компьютера 152 на мобильное устройство 148. В такой ситуации не потребуется дополнительных прав на потоковую передачу и не потребуется затрат на оплату ширины полосы пропускания. Если запрос 237 передается на удаленный сервер 150 в соответствии с настоящим изобретением и упомянутый файл не существует либо на подключенном персональном компьютере 152, либо облаке, то запрос 237 передается, показано как 238, источнику 147 данных, упомянутый источник 147 данных может затем передавать поток 239 упомянутого файла устройству 148.

В сценарии, изображенном на Фиг. 25, поставщик потоковой передачи 147 запрашивает воспроизведение музыкальной композиции на мобильном устройстве 148. Запрос передается от мобильного приложения 149 на мобильном устройстве 148 и передается на удаленный сервер 150 в соответствии с настоящим изобретением. Если упомянутое мобильное устройство 148 запрашивает музыкальную композицию, которая была загружена, показано как 240, в облачной службе 153 из персонального компьютера 152, с которым упомянутое мобильное устройство 148 соединено, показано как 235, удаленный сервер 150 осуществляет маршрутизацию 236 запроса 237 на ящик облака или службу 153. В этом случае не требуется лицензирования, но будет взиматься плата за ширину полосы пропускания. Если запрос 237 передается на удаленный сервер 150 в соответствии с настоящим изобретением и упомянутый файл не существует либо на подключенном персональном компьютере 152, либо на подключенном облаке 153, то запрос передается, показано как 238, на источник 147 данных, после чего упомянутый файл может передаваться потоком, показано как 239, на устройство 148.

Сервер 150 в соответствии с настоящим изобретением и его механизм интеллектуальной маршрутизации музыки, как описано в упомянутых выше примерах, не только выбирает упомянутую музыкальную композицию с точки зрения минимальных затрат на передачу в отношении ширины полосы пропускания и затрат на лицензионные платежи, включая, но не ограничиваясь такими ресурсами, как в примерах выше с номерами 1-6, но также оценены аспекты соблюдения (прав) в такой передаче и отчеты о такой деятельности для целей лицензионных платежей.

Со ссылкой на фигуры Фиг. 22 и Фиг. 23, читатель будет рассматривать конкретные механизмы суб-лицензирования в соответствии с настоящим изобретением. Использование локального шлюзового сервера для автоматизированного суб-лицензирования потокового контента зависит от условий соглашений между правообладателями и поставщиками контента (т.е. поставщиками услуги потоковой передачи). Ниже описывается ситуация с учетом возможности того, что поставщик потоковой передачи данных имеет соглашение, в котором требуется, чтобы они совместно использовали часть доходов, полученных от потокового лицензированного медиа. Также может быть требование, чтобы такая лицензия специально позволяла поставщику потоковой передачи данных действовать как оптовому торговцу.

Сценарий первого случая изображен на Фиг. 22. В этом случае поставщик 155 услуги потоковой передачи данных передает запрос на локальный шлюзовой сервер 150 наряду с запросом того, что упомянутый поставщик 155 должен устанавливать конкретные параметры, позволяющие локальному серверу 150 осуществлять потоковую передачу 241 с оптимальной стоимостью. Это будет указывать, что сервер 150 может передавать поток из сублицензированного аккаунта, показано как 156. На схеме представлены три сублицензированных аккаунта со ссылками на 157, 158, и 159.

Когда запрос поступает от приложения 155 клиента, локальный сервер 150 определяет, показано как 242, какой аккаунт суб-лицензирования (выбираемый из аккаунтов 157-159) имеет оптимальную стоимость лицензирования для данного запроса 241. Упомянутая музыкальная композиция затем передается потоком 243 из суб-лицензированного облака (например, от аккаунта 157). Поставщик потоковой передачи данных затем предъявляет счет, показано как 244, от имени сублицензиара 157. Счет будет включать затраты на лицензирование и затраты на потоковую передачу данных на основе лицензионного соглашения сублицензиаров. Упомянутый сублицензиар затем платит 245 правообладателю 160 лицензионные платежи и сохраняет деньги, необходимые для покрытия расходов потоковой передачи и получаемую прибыль от транзакции.

Во втором случае, как изображено на Фиг. 23, основное отличие видится в том, как покрывается стоимость потоковой передачи. Поскольку данные передаются потоком 246 из одноранговой сети 161 в соответствии с настоящим изобретением, плата, связанная с использованием одноранговой сети 161, платится 247 поставщику 162 услуги, владеющему сетью 161, и затем стоимость лицензирования передается на основании 244 сублицензиару 157, который затем платит 245 лицензионные платежи правообладателю 160 и сохраняет прибыль, полученную от транзакции.

Случаи суб-лицензирования, рассмотренные выше, возможны, поскольку локальный сервер 150 отслеживает и отчитывается о потоках, а именно, кто осуществляет потоковую передачу, откуда (тот, кто является сублицензиаром) и в результате может надлежащим образом осуществлять маршрутизацию лицензионных платежей. Уникальность такой системы заключается не в том, чтобы позволять такое отслеживание, но в том, что возможно получать доступ к одноранговой сети и еще сообщать о таком использовании. Сценарий второго случая, представленный выше, является возможным только с использованием шлюзового сервера 150, в то время как первый сценарий может происходить со стандартным запросом от сервера к серверу или при некоторой форме перезаписи и перенаправления.

Конкретная польза / преимущества лицензирования посредством использования контента локального сервера являются очевидными в соответствии с настоящим изобретением. В этом отношении, локальное медиа использование поступает для воспроизведения, когда музыкальная композиция существует на локальном сервере, который контролируется или принадлежит конечному пользователю услуги. Это будет заголовок или альбом уже в аккаунте персональной медиабиблиотеки пользователя или в любой части их локального компьютера. Этот контент мог быть размещен там посредством покупки, загрузки или подарка. Это не является ответственностью поставщика услуги или владельцев настоящей системы / методологии подтверждать легальность источников локальных файлов на компьютере конечного пользователя.

Поставщик потоковой передачи данных не будет делать дублирование, распределение или представление локально управляемой записи звука или музыкальной обработки. Следовательно, никакие права не используются, и никакой дополнительной платы лицензии не требуется для расчета или отчетности. Ключом является возможность быстро и точно определить эти фонограммы, чтобы не прерывать опыт работы конечного пользователя.

Использование медиа из сервера в соответствии с настоящим изобретением происходит, когда музыкальная композиция, которая была лицензирована при более благоприятной ставке от владельца, настоящей системы / методологии может использоваться вместо музыкальной композиции от поставщика потоковой передачи данных. Это стало возможным с помощью лицензий, которые сделаны непосредственно с контроллерами контента. Эти новые прямые соглашения предлагают более прозрачную структуру лицензионного платежа и процесс отчетности непосредственно для исполнителя.

Прямые лицензии также учитывают как интерактивные, так и неинтерактивные использования, создавая более чем "одну остановку» взаимоотношения для использования в режиме онлайн. Упомянутое соглашение также будет предлагать отдельный лицензионный платеж, который вычисляется за счет экономии, полученной в результате повышения эффективности доставки. В настоящее время нет соглашений, которые передают часть сбережений, созданных посредством совместно используемых файлов обратно для индустрии.

Преимущество использования этих файлов для поставщиков потоковой передачи данных происходит от уменьшенной ставки лицензионного платежа через интерактивное и неинтерактивное использование. Все представления и часы прослушивания, вычисляемые от использования этих прав собственности, будут вырезаны из стандартных расчетов по "полному тарифу" лицензионных платежей и будут на основе более выгодной ставки.

Использование управляемого одноранговыми узлами медиа происходит, когда файл размещается в безопасном кэше, управляемом сервером пользователя, и может замещать файл, запланированный для воспроизведения, на канале данных поставщиков потоковой передачи данных. Хотя нет никакой экономии затрат от дополнительной платы по лицензионным платежам, имеется экономия на доставке, что будет изолировать выплаты исполнителей, которые находятся под прямыми лицензиями, в соответствии с настоящей системой и методологией. Следовательно, чем больше прав собственности, которые могут поступать из этого безопасного кэша, тем больше преимуществ как для поставщиков потоковой передачи данных, так и для музыкальной индустрии.

Ниже приведена врезка образца ежемесячного программирования от воображаемого поставщика потоковой передачи данных. Врезка подразумевает показать не только экономию, связанную с использованием контента из многих источников, но также то, насколько критичен отдельный процесс вычисления соблюдения для всего процесса экономии.

Механизм соблюдения и средство для отчета со способностью вытянуть следующую информацию:

1) Отчеты об использовании на основе отдельных спецификаций, требуемых всеми организациями, наблюдающими за исполнением авторских прав. Эти спецификации включают в себя следующие пункты.

a. Предоставление отдельных отчетов платформе (поставщик потоковой передачи данных).

b. Предоставление возможности для безопасного ввода информации о доходах в зависимости от типа платформы и в расчете на одного поставщика потоковой передачи данных.

c. Отчеты об использовании в расчете на один отдельный сеанс пользователя для создания итога о средних часах прослушивания, итогов в расчете на одно воспроизведение и итогов в расчете на один сеанс прослушивания.

d. Возможность агрегировать всю информацию об использовании и всю информацию о доходах в отдельные отчеты об использовании в расчете на одного поставщика услуг (SP) и PRO.

2) Спецификации об использовании для отчетности об обмене звуковыми записями и платежах.

a. Предоставление отдельных отчетов в расчете на одну платформу (поставщик потоковой передачи данных).

b. Предоставление возможности для безопасного ввода информации доходах в зависимости от типа платформы и в расчете на одного поставщика потоковой передачи данных.

c. Отчеты об использовании в расчете на один отдельный сеанс пользователя для создания итогов о среднем часе прослушивания, итогов в расчете на одно воспроизведение и итогов в расчете на один сеанс прослушивания.

d. Возможность агрегировать всю информацию об использовании и всю информацию о доходах в отдельные отчеты об использовании в расчете на одного SP.

3) Спецификация об общем использовании для звукозаписывающих компаний и издателей - используемая для интерактивных использований.

4) Модуль прав "Информационная панель соблюдения" - Возможность формировать права для группового изменения или права для индивидуального изменения (в расчете на один медиаактив), ставку лицензионного платежа, статус получения прав и использования, предоставляемый контроллером контента для различных типов соглашений:

a. Лицензионное соглашение лейбла звукозаписи.

b. Связанное с местом жительства лицензионное соглашение.

c. Коммерческое лицензионное соглашение.

d. Лицензионное соглашение для нескольких платформ.

e. Соглашение для связанных прав.

f. Соглашение о совместном лицензионном платеже (Администрирование для публикации).

g. Отказ от права / безвозмездно.

5) Способность предоставить индивидуальный и агрегированный аккаунт для всех требований отчетности, указанной выше, через все отдельные платформы и службы для каждого из следующих "типов источника контента".

a. 100% контент для поставщика потоковой передачи данных (SP).

b. Контент для локального сервера.

c. Управляемый Р2Р контент.

d. Vertigo Лицензионный контент.

6) Механизм вычисления лицензионного платежа - система имеет способность вычислять причитающиеся лицензионные платежи, посредством объединения данных об использовании в расчете на один срок данных, в расчете на один тип источника контента и в расчете на одного поставщика потоковой передачи данных на основе ставок, введенных в информационную панель соблюдения прав. Следующее вычисление будет использовано для выделения контента локального сервера. X/X+Yx (на воспроизведение или почасовую ставку потоковой передачи данных) = итоговый лицензионный платеж. X = контент локального сервера и Y = контент поставщика потоковой передачи.

Способность точно вычислять и давать отчеты для всех объединений обладателей прав, хранилищ, источников и вычислять контролируемые и надлежащие использования контента, и включать экономию средств доставки в итоговый общий лицензионный платеж, делают это одним из видов службы соблюдения прав.

Эта часть документа описывает, как локальный шлюзовой сервер может использоваться для более эффективного осуществления Интернет потоков традиционных радиостанций и повышения качества, передаваемого аудиопотока. Изобретение или скорее эта часть описания фокусируется на широковещательных радиопередачах, которые в первую очередь воспроизводят музыку, в отличие от ток-шоу, спортивных широковещательных передач т.д. Значительная экономия может обеспечиваться и качество аудио может быть существенно улучшено из-за того факта, что музыка на основе широковещательной радиопередачи является смесью живого аудио и предварительно записанного аудио.

Значительная экономия и повышение качества аудио может достигаться, если упомянутое предварительно записанное аудио может быть отделено от живого аудио или студийного микса и доставляться на локальный компьютер через одноранговую сеть или через локальные файловые системы (система сопоставления файлов метаданных будет использоваться, чтобы обеспечивать воспроизведение надлежащей музыкальной композиции). Предварительно записанное аудио и студийный микс могут затем смешиваться на локальном компьютере, чтобы обеспечить соответствующий контент широковещания и качество. В этом описании будет пояснено, как это может быть достигнуто.

Существующие способы для потокового радио через Интернет в целом изображены на Фиг. 30. Современные способы для доставки радиопотоков через Интернет как правило включают в себя использование устройства воспроизведения медиа, показано как 163 (например, обычный персональный компьютер), который воспроизводит предварительно записанное аудио (музыкальная фонограмма, объявление и т.д.) и выводит 248 упомянутое аудио на звуковую плату 164. Это аудио затем микшируется с примечаниями диск-жокея и/или комментариями и другим живым аудио 165, все это поступает 249 на звуковую плату 164 в студии или записывающей системе 170.

Микс звуковой платы затем выводится, показано как 250, на компьютер 166 как один поток аудио. Упомянутый компьютер 166 затем сжимает аудиопоток и выводит аудиопоток в сжатый аудиофайл 167 (это обычно МР3 файл). Этот МР3 файл не имеет установленной длительности и как файл передается потоком вживую и новые данные присоединяются к концу файла постоянно. Этот МР3 файл обычно размещается в сети 168 доставки контента и упомянутый компьютер 166, который сжимает и транс-кодирует аудиопоток, присоединяет 251 к этому файлу новые данные по мере того как он их сжимает. Упомянутая сеть 168 доставки контента затем распределяет 252 этот файл клиентам 169. Опять же это простое общее представление системы и скорее всего похоже на большинство конфигураций на рынке.

Улучшенная система шлюзового сервера в соответствии с настоящим изобретением в целом изображена на фигурах 26-29. Улучшенная система начинается в радиостудии 170 и компьютере 163, который выводит 248 предварительно записанное аудио на звуковую плату 164. Упомянутый компьютер 163 в соответствии с настоящим изобретением будет иметь определенные средства ассоциации маркера событий как иллюстрируется с специализированным программным обеспечением, которое, когда инсталлировано или применяется, позволяет…

1. Диск-жокей запрашивает музыкальные композиции для широковещания; программное обеспечение создает очередь 171 музыкальных композиций, которые затем распределяются для клиентов 172, упомянутые клиенты 172 осуществляют потоковое широковещание. Очередь 171 содержит музыкальные композиции, которые диск-жокей планирует воспроизвести во время широковещания. Локальный сервер 184 предварительно загружает 253 эти музыкальные композиции так, что когда диск-жокей решает воспроизвести музыкальную композицию, упомянутая музыкальная композиция будет доступна на стороне клиента 172 для воспроизведения. Эти музыкальные композиции могут доставляться через удаленные сети клиента 173 для доставки контента, одноранговые сети клиента 174 или сопоставимые и передаваемые потоком из локальной файловой системы 175.

2. Программное обеспечение также сжимает, показано как 256, аудиовыход 176, возвращающийся из звуковой платы 164. Программное обеспечение также встраивает маркеры событий в заголовки 177 кадров аудиопотока 179. Каждый МР3 аудиопоток/файл 179 состоит из аудиокадров 178, кадры 178 каждый имеет заголовок 177. По мере того как новое аудио добавляется, новые кадры 178 присоединяются к файлу. Эти заголовки 177 имеют длительность 32 бит. В пределах каждого заголовка 177 имеется бит, зарезервированный для частного прикладного использования. Этот бит будет установлен на "1" в начале события и установлен на "0" во время регулярной потоковой передачи. Эти данные будут встроены в оба потока 176 и/или 256, поступающие от звуковой платы 164. Каждый заголовок 177 также содержит биты, которые являются только информационными и не влияют на аудиовоспроизведение (например, "авторские права", "оригинал"). Каждый заголовок 177 имеет, по меньшей мере, 3 бита (включая частный бит), которые не будут влиять на аудиовоспроизведение. Эти биты могут использоваться для создания идентификатора ID события. Этот идентификатор ID будет создан, используя эти биты (следующие за битом индикатора события), чтобы создать сочетание из "0" и "1", чтобы позволить обеспечить достаточное количество отдельных идентификаторов ID для размещения достаточного количества событий для заполнения 10 секунд воспроизведения. Таким образом, если упомянутый заголовок кадра с исходным битом индикатора события используется наряду с заголовком кадра, следующим непосредственно после, то, в общем, по меньшей мере, 5 бит может использоваться для создания, по меньшей мере, 32 или 25 отдельных маркеров. Это должно обеспечивать более чем достаточно отдельных маркеров для охвата достаточного числа событий для возможных 10 секунд задержки. Если требуется больше маркеров, то другой заголовок может быть добавлен для увеличения общего количества маркеров от 32 до 256. Поскольку каждое событие будет иметь отдельный маркер в пределах 10 секунд временного кадра, эти маркеры могут использоваться для синхронизации двух отдельных потоков (один из которых содержит только живое аудио, а другой из них будет полным миксом) для передачи и перехода на полностью дистанционно микшированный поток и локально микшированный поток (который будет потоком живого аудио передаваемого потоком из студии и предварительно записанного микшированного аудио, микшированного в упомянутый поток при маркерах событий посредством локального сервера). Маркеры событий также будут связаны с инструкциями микширования, чтобы имитировать аудиомикс из студии.

3. Упомянутое приложение также создает очередь событий. Это будет очередь событий, которые будут сопоставлены с маркерами событий на основе отдельного битового идентификатора ID после маркера (как пояснено выше). Эти события будут записаны на компьютере 163, который сжимает аудио, так что каждое событие регистрируется в точном кадре 178, в котором они происходят, обеспечивая то, что синхронизация событий встраивается в живой аудиопоток 256 в точном месте, в котором они произошли в исходном студийном миксе 176. Эти события будут содержать следующую информацию.

a. Какое предварительно записанное аудио должно быть воспроизведено на маркере события.

b. На каком кадре начинается воспроизведение предварительно записанного аудио.

c. При какой громкости должно начинаться воспроизведение.

d. При этом, если эта громкость была заглушена, уравнение, которое наилучшим образом подбирает направление и наклон плавного изменения возрастания/снижения громкости. Это будет использовано для имитирования студийного возрастания/снижения громкости. Эта информация возможно может быть записана периферийным микшером 180, который позволяет диск-жокею управлять 257 аудио по мере того, как оно выводится на звуковую плату 164 и сообщать изменения в громкости обратно на упомянутый компьютер 163.

e. Завершение события (это, как правило, требуется, чтобы отметить, когда исчезновение/возникновение громкости прекращается).

f. И более того. Это всего лишь пример наиболее вероятного типа события.

4. Упомянутое приложение будет также обновлять 258 файл 181 живого аудиопотока и файл 182 полного микса на удаленном сервере или сети 150 доставки контента.

Как только два потока 181/182 записаны и кодированы посредством упомянутого приложения в студии 170 на компьютере 163, оба файла 181/182 загружаются 258 на сети доставки контента или удаленный сервер 185 для доставки 259 для клиентов 172. Приложения 183 на стороне клиента (например, браузеры и т.д.) передают запросы радиопотока с использованием надлежащим образом отформатированного указателя URL. Указатель URL структурируется как суб-домен первичного доменного имени, например, указатель URL этого формата возможно использовать для ссылки на поток радиостанции radiostation.vertigomusic.com/[showid]. Если vertigo шлюзовой сервер 184 не был установлен, то этот указатель URL будет отправлять клиента на полностью микшированный студийный поток 182 и будет воспроизводить упомянутый файл тем же способом, как и традиционный Интернет радиопоток (смотрите выше и Фиг. 30).

Если vertigo шлюзовой сервер 184 был установлен, то сервер 184 регистрирует это суб-доменное имя для себя и затем обрабатывает весь запрос для суб-доменного имени от локального приложения клиента 183. В этом случае, когда запрос для потоковой передачи сделан посредством приложения клиента 183, запрос подается 260 посредством шлюзового сервера 184. Шлюзовой сервер 184 начинает работу посредством подачи полностью микшированного потока 182 из удаленной сети 185 доставки контента. Как только потоковая передача начинается, шлюзовой сервер 184 запрашивает предварительно записанную аудиоочередь 171 и начинает кэширование 253 предварительно записанного аудио от одноранговых узлов 174 удаленной сети (сетей) 173 доставки контента или из локальных источников 175. Шлюзовой сервер 184 также загружает 261 очередь событий из удаленной базы данных 186, которая постоянно обновляется посредством студийного компьютера 163. Шлюз 184 будет постоянно принимать обновления событий 261, пока поддерживается живой поток 181.

Для перехода от полного студийного микса 182 на поток 181 только живого аудио, шлюзовой сервер 184 загружает оба потока 181 и 182 и подает только полный микс 182. Для обеспечения того, чтобы шлюзовой сервер 184 и микширующее приложение 187 имели достаточное количество времени для завершения всех задач, сервер 184 запускает поток 10-20 секунд от приема данных в реальном времени, создавая специальную задержку, которая будет использоваться, чтобы создать время для выполнения системой микширования и перехода. Шлюзовой сервер 184 ожидает бит события в заголовках 177 кадров полного студийного микса 182 для перехода на живой аудиопоток 181.

Шлюзовой сервер 184 выравнивает упомянутые два потока 182/181 на бит события. Это осуществляется посредством сопоставления битового кода, следующего за битом события. Если упомянутый битовый код сопоставляет оба события, то упомянутые события считаются соответствующими, поскольку только последние 10-15 секунд потока ищутся. 32 отдельных битовых кода обеспечивают достаточную индивидуальнсть, чтобы гарантировать, что соответствующие события действительно являются идентичными. Как только биты события сопоставлены, шлюзовой сервер 184 переходит от полного студийного микса 182 к живому аудиомиксу 181 на кадре 178, в котором бит события имеет место. Использование этого способа обеспечивает легко сочетаемый переход от потока, чтобы осуществлять потоковую передачу с межкадровой точностью.

Как только шлюзовой сервер 184 осуществил переход на поток 181 только живого аудио, он начинает следовать инструкциям микширования, которые хранятся в базе 186 данных событий, когда бит события появляется. Поскольку только последние 10-15 секунд живого потока отслеживаются для бита события, упомянутый битовый код используется для нахождения данных события в базе 186 данных, которая сопоставляет битовый код события.

Таким образом, предполагая, что первое событие было для воспроизведения первой музыкальной композиции в очереди 171 предварительно записанного аудио, упомянутое приложение уже проведет кэширование по меньшей мере 10-20% аудио. В этом случае, шлюзовой сервер 184 передает живой аудиопоток 181 и данные 188 предварительно записанного аудио на внутреннее микширующее приложение 187 (это может быть приложение командной строки подобно SoX или пользовательское встроенное приложение).

Шлюзовой сервер 184 также передает 261 данные микширования для упомянутого приложения, которое микширует живой аудиопоток 181 и упомянутое предварительно записанное аудио, чтобы имитировать полный студийный микс 182. Это осуществляется посредством использования данных, которые записываются в студии 170 и ассоциируются с событием для имитирования заглушения громкости звука и выбора определенного времени для диск-жокея. Упомянутое приложение 187 затем выводит новый локально микшированный файл 189, который затем подается запрашивающему клиенту 183. Это может быть сделано плавно, поскольку сервер может создавать существенную задержку между живой передачей данных и подаваемыми данными для приложения клиента. Пока эта задержка создается в самом начале подаваемого радио, этот временной кадр задержки может использоваться для микширования и подготовки аудио.

В тех случаях, где радиостанция или радиопостановка будут интегрировать только рекламные объявления и не будут микшировать живой поток с предварительно записанным аудио (например, музыка), упомянутая система предусматривает определенные средства интеграции рекламы, которые будут работать как описано ниже и как в целом изображено на фигурах 31 и 32.

Радиопостановка может быть записана на компьютере 190 с использованием программного обеспечения 191, которое будет кодировать аудио и отмечать, когда реклама или другой предварительно записанный файл должен быть воспроизведен. Рекламные маркеры размещаются по истечении заранее определенного времени аудиотишины. Для достижения этого, кодирующее приложение191 создает задержку 300 на несколько секунд больше, чем заранее определенная указывающая на рекламу аудиотишина 301. Таким образом, если радиоперсонал записывает и требуется вставить рекламный перерыв, радиоперсонал просто заглушает или делает тише громкость микрофона на 5 секунд, показано как 301 (например). После 5 секунд тишины (показано как 301) (в качестве примера) кодирующее приложение отмечает аудиопоток не в конце 302 интервала 5 секунд тишины, а в ее начале 303. При этом способе конечный слушатель не услышит тишину, но услышит рекламу.

Как только заранее определенный временной кадр тишины прошел, упомянутое приложение 191 подсказывает радиоперсоналу указать длительность рекламы, которая должна воспроизводиться, и рекламные объявления интегрируются в соответствии с выбранным временным кадром. Этот аудиопоток затем кодируется и отмечается приложением 191 и загружается на сервер или сеть 192 доставки контента по выбору радиоперсонала.

Когда слушатель из своего устройства 193 запрашивает через приложения клиента 194 (например, браузер или мобильное приложение) радиопоток, запрос передается 270 на шлюзовой сервер 195. Шлюзовой сервер 195 передает 271 запрос аудиопотока на облако/сервер 192, который отвечает и доставляет 272 это аудио на шлюзовой сервер 195.

Шлюзовой сервер 195 затем доставляет 273 аудиопоток клиенту 194. Шлюзовой сервер 195 создает небольшой буфер (2-5 секунд данных), так что, когда рекламный маркер идентифицируется в аудиопотоке, шлюзовой сервер 195 может выбирать 274 соответствующее рекламное объявление из рекламного сервера 196 и интегрирует его в указанное время. В мобильном приложении, упомянутому приложению придется интегрировать рекламные объявления без шлюзового сервера 194. Упомянутому мобильному приложению придется интегрировать рекламные объявления в исходный код приложения. Так что оно будет иметь код, который обнаружит рекламный маркер, и затем интегрирует рекламное объявление в начале рекламного маркера.

В то время как представленное выше описание содержит много особенностей, эти особенности не должны толковаться как ограничения на область действия упомянутого изобретения, а скорее, как иллюстрация упомянутого изобретения. Например, предполагается, что настоящее изобретение в основном предоставляет одноранговые сети доставки контента (peer-to-peer,P2P) для доставки (например, потоковой передачи) выбранных файлов данных конечному пользователю.

Так называемые Р2Р сети доставки контента (сети CDN) или Р2Р CDN в соответствии с настоящим изобретением предпочтительно содержат клиента, показано как 2, Р2Р шлюзовой сервер, показано как 3, сервер имен ресурсов (RNS), показано как 4, и заполненную компьютерами сеть, эта заполненная компьютерами сеть может содержать локальные серверы, подключенные к узлам серверы, облачные ящики, облачное хранилище, облачное медиа и/или инфраструктуру (инфраструктуры) предоставления коммерческого обслуживания (музыка) потоковой передачи.

Клиент связывается с Р2Р шлюзовым сервером, и Р2Р шлюзовой сервер связывается с сервером RNS и заполненной компьютерами сетью. Сервер RNS в основном функционирует для кэширования местоположений ресурсов данных в заполненной компьютерами сети и разрешает запросы ресурсов с оптимальными (например, (а) с источником с наиболее эффективной стоимостью или (b) с источником с наиболее высоким качеством звука) местоположениями ресурсов данных в заполненной компьютерами сети.

Р2Р шлюзовой сервер запрашивает и принимает оптимальные местоположения ресурсов данных через сервер RNS; запрашивает и принимает файлы данных от заполненной компьютерами сети с использованием способа оптимальных местоположений ресурсов данных, обрабатывает принятые файлы данных и доставляет файлы данных клиенту и конечному пользователю.

Сеть доставки контента или сеть CDN в соответствии с настоящим изобретением включает в себя несколько опциональных, но предпочтительных дополнительных для базовой системы компонентов, включая конкретные клиентские и/или серверные средства аутентификации для верификации клиента и/или верификации сервера, как здесь рассматривается немного подробнее выше. Дополнительно, в целях повышения доставки невредоносных потоков данных, настоящее изобретение предполагает конкретные средства фрагментации доставки данных, как здесь также рассматривалось выше.

Местоположения ресурсов могут предпочтительно индексироваться через конкретные средства индексации ресурсов, совместно работающие в соединении с сервером RNS для дальнейшего улучшения эффективности сети или способа. В частности, средства индексации ресурсов могут предпочтительно содержать конкретные средства сопоставления файлов для быстрого и эффективного сопоставления файлов данных независимо от метаданных файлов данных. Средства сопоставления файлов в соответствии с настоящим изобретением более полно указаны в акцептованной патентной заявке США №13/065,254, по которой в настоящее время выдан патент США №8,589,171, чьи описания заявляют приоритет, и эти описания были включены как отсылки в заявке.

Средства сопоставления файлов в соответствии с настоящим изобретением могут таким образом предпочтительно содержать конкретные средства извлечения файлов, конкретные средства получения суммарной статистики, конкретные средства генерирования пользовательского маркера, конкретные средства ассоциирования пользовательского маркера и конкретные средства доступа пользовательского маркера.

Упомянутые средства извлечения данных извлекают данные о форме сигнала из первого файла данных. Извлеченные данные о форме сигнала содержат значения длины сегмента, эти значения извлекаются по отношению к базовому уровню извлечения данных и содержат значения длины сегмента от нижнего до базового уровня и от пикового до базового уровня. Средства получения сводных статистических данных получают сводные статистические данные из извлеченных данных формы сигнала, при этом сводные статистические данные получают из значений длины сегмента, и они содержат статистику длины сегмента от нижнего до базового уровня и от пикового до базового уровня.

Упомянутые средства генерирования пользовательского маркера генерируют пользовательский маркер на основе полученных сводных статистических данных, и средства ассоциирования пользовательского маркера ассоциируют этот пользовательский маркер с первым файлом данных, таким образом конструируя отмеченный пользователем файл данных. Средства доступа к пользовательскому маркеру обеспечивают доступ к пользовательскому маркеру, когда осуществляется сравнение второго файла данных с отмеченным маркером файлом данных для визуализации положительного сопоставления файлов данных.

Упомянутые Р2Р сети доставки контента могут дополнительно содержать конкретные средства ассоциирования маркера события для ассоциирования маркеров событий в заголовках кадров файлов данных для улучшения передачи файла данных, как здесь рассматривается более подробно выше. В этом последнем рассмотрении читателю напоминается, что настоящее изобретение в дополнение предполагает конкретные средства интегрирования рекламных объявлений, эти средства могут в дальнейшем использоваться для интегрирования рекламного контента в файлы данных через указанные средства ассоциирования маркера события.

Предполагая независящий от источника данных характер настоящего изобретения, дополнительно предлагается система управления данными маршрутизации. Система управления данными маршрутизации в соответствии с настоящим изобретением предпочтительно содержит, в сочетании, механизм или приспособление для сопоставления данных маршрутизации и описанные сети доставки контента. Соответственно, упомянутое приспособление для сопоставления данных маршрутизации находится в соединении с упомянутыми сетями доставки контента, сети доставки контента содержат множество источников данных, упомянутые источники содержат или хранят файлы данных.

Упомянутые сети доставки контента доставляют выбранные файлы данных конечному пользователю из оптимального местоположения источника данных, при этом оптимальное местоположение источника данных выбирается из группы, состоящей из источников данных. Таким образом, механизм или приспособление для сопоставления, в соответствии с настоящим изобретением, обеспечивают (а) управление правами индустрии (b) мониторинг соблюдения прав и/или (с) передачи файлов данных отчетности о соблюдении прав.

По существу, настоящее изобретение может быть заявлено, чтобы предоставить функциональные возможности для (1) доставки потока для косвенного запроса из локального сервера (например, цифровое радио, которое иллюстрируется посредством PANDORA® radio); доставки потока для косвенного запроса из подключенного к узлу сервера; доставки потока для косвенного запроса из второго источника по прямому запросу (например, iTunesMatch или Spotify или облачный ящик подобно DropBox или любое медиа в облаке); доставки потока для косвенного запроса из подключенного к узлу сервера на основе права потоковой передачи или воспроизведения второго источника по прямому запросу; доставки потока по прямому запросу из второго источника прямого запроса на основе (а) эффективности затрат или (b) качества звука источника; и (6) доставки потока по прямому запросу от подключенного к узлу источника на основе права потоковой передачи или воспроизведения второго источника по прямому запросу. Предполагая не зависящие от источника данных или не зависящие от облака аспекты настоящей системы, упомянутая система в дополнение обеспечивает (а) управление правами индустрии (b) мониторинг соблюдения прав и/или (с) отчетность о соблюдении, где доставка контента осуществляется из вторичного источника, иного, чем исходный запрошенный службой источник, включая примеры 1-6, упомянутые выше.

Упомянутые выше спецификации в дополнения полагают конкретную методологию доставки данных, не зависящую от источника, для оптимальной (например, с эффективными затратами) доставки выбранных данных конечному пользователю в среде, заполненной компьютерами. Упомянутый способ доставки данных, не зависящий от источника, в соответствии с настоящим изобретением может быть указан предпочтительно содержащим следующие этапы: соединение клиента, шлюзового сервера (Р2Р) одноранговых узлов и сервера имен ресурсов (RNS) с заполненной компьютерами сетью; и кэширование данных о местоположениях ресурсов в заполненной компьютерами сети через сервер RNS.

Оптимальные данные о местоположении ресурсов могут запрашиваться посредством Р2Р шлюзового сервера через клиента из кэшированных сервером RNS данных о местоположении ресурсов, упомянутые запросы ресурсов разрешаются с помощью оптимальных местоположений ресурсов через сервер RNS. Оптимальные местоположения ресурсов принимаются посредством Р2Р шлюзового сервера через сервер RNS, после чего файлы данных из заполненной компьютерами сети запрашиваются с использованием способа или становятся возможными для доступа с использованием принятых оптимальных местоположений ресурсов. Запрашиваемые файлы данных затем передаются (т.е. отправляются и принимаются) и обрабатываются для доставки файлов данных клиенту.

Изобретение относится к сети доставки контента одноранговых узлов (Р2Р), доставляющих выбранные файлы данных конечному пользователю. Технический результат – обеспечение возможности доставки независящих от источника данных для оптимальной доставки выбранных файлов данных конечному пользователю. Для этого, в частности, шлюзовой сервер выполнен с возможностью запрашивания и приема оптимального местоположения ресурсов данных через сервер имен ресурсов RNS, запрашивания и приема файлов данных из заполненной компьютерами сети через оптимальные местоположения ресурсов данных и обработки принятых файлов данных для доставки файлов данных клиенту, упомянутые средства интеллектуальной маршрутизации выполнены с возможностью реагировать на интерактивные и неинтерактивные запросы, осуществляемые клиентом, с использованием потребляемой маршрутизации, легально защищенных данных из выбранных оптимальных местоположений ресурсов данных, при этом упомянутый выбор оптимальных местоположений ресурсов данных осуществляется из группы, содержащей, по меньшей мере, две разные легальные точки доступа, упомянутый выбор основывается на определяемых пользователем параметрах. 4 н. и 22 з.п. ф-лы, 33 ил.

1. Интеллектуальная система маршрутизации для работы в пределах одноранговой сети доставки контента, при этом одноранговая сеть доставки контента для доставки выбирает файлы данных для пользователя, упомянутая интеллектуальная система маршрутизации, содержащая:

клиента, выполненного с возможностью совместной работы со средствами интеллектуальной маршрутизации, шлюзовой сервер и сервер имен ресурсов (далее, сервер RNS) совместно в соединении с заполненной компьютерами сетью, упомянутый сервер RNS выполнен с возможностью (1) кэширования местоположения ресурсов данных в пределах заполненной компьютерами сети и (2) разрешения запросов ресурсов с использованием оптимального местоположения ресурсов данных в пределах заполненной компьютерами сети, шлюзовой сервер выполнен с возможностью (1) запрашивания и приема оптимального местоположения ресурсов данных через упомянутый сервер RNS, (2) запрашивания и приема файлов данных из заполненной компьютерами сети через оптимальные местоположения ресурсов данных и (3) обработки принятых файлов данных для доставки файлов данных клиенту, упомянутые средства интеллектуальной маршрутизации выполнены с возможностью реагировать на интерактивные и неинтерактивные запросы, осуществляемые клиентом, с использованием потребляемой маршрутизации, легально защищенных данных из выбранных оптимальных местоположений ресурсов данных, при этом упомянутый выбор оптимальных местоположений ресурсов данных осуществляется из группы, содержащей, по меньшей мере, две разные легальные точки доступа, упомянутый выбор основывается на определяемых пользователем параметрах.

2. Интеллектуальная система маршрутизации по п. 1, дополнительно содержащая средства аутентификации клиента, при этом упомянутые средства аутентификации клиента выполнены с возможностью верификации аутентичности клиента.

3. Интеллектуальная система маршрутизации по п. 1, дополнительно содержащая средства аутентификации сервера, при этом упомянутые средства аутентификации сервера выполнены с возможностью верификации аутентичности сервера.

4. Интеллектуальная система маршрутизации по п. 1, дополнительно содержащая средства фрагментации доставки данных, при этом упомянутые средства фрагментации доставки данных выполнены с возможностью улучшения осуществления доставки невредоносных потоков данных.

5. Интеллектуальная система маршрутизации по п. 1, дополнительно содержащая средства индексации ресурсов, упомянутые средства индексации ресурсов выполнены с возможностью индексации местоположения ресурсов и таким образом для повышения эффективности сети упомянутой интеллектуальной системы маршрутизации.

6. Интеллектуальная система маршрутизации по п. 5, в которой упомянутые средства индексации ресурсов содержат средства сопоставления файлов, упомянутые средства сопоставления файлов выполнены с возможностью сопоставления файлов данных независимо от метаданных файлов данных, упомянутые средства сопоставления файлов выполнены таким образом для повышения эффективности сети упомянутой интеллектуальной системы маршрутизации.

7. Интеллектуальная система маршрутизации по п. 1, дополнительно содержащая, (а) средства управления промышленными правами, (b) средства мониторинга соблюдения и/или (с) средства отчетности о соблюдении, при этом упомянутые средства выполнены с возможностью управления, мониторинга и/или отчетности передачи файлов данных, подвергнувшихся интеллектуальной маршрутизации, легально защищенных данных из выбираемых оптимальных местоположений источников информации.

8. Интеллектуальная система маршрутизации по п. 1, дополнительно содержащая средства ассоциирования маркера события, упомянутые средства ассоциирования маркера события выполнены с возможностью ассоциирования маркеров событий в заголовках кадров файлов данных для улучшения эффективности передачи файлов данных.

9. Интеллектуальная система маршрутизации по п. 8, дополнительно содержащая средства интеграции рекламных объявлений, упомянутые средства интеграции рекламных объявлений выполнены с возможностью интеграции рекламного контента в файлы данных с использованием упомянутых средств ассоциирования маркера события.

10. Не зависящий от источника способ доставки данных в среде, заполненной компьютерами, для доставки легально защищенного выбранного файла данных конечному пользователю из оптимальных местоположений ресурсов на основе определяемых пользователем параметров, упомянутый независящий от источника способ доставки данных содержит следующие этапы:

соединение клиента, шлюзового сервера одноранговых узлов и сервера имен ресурсов (сервер RNS) с заполненной компьютерами сетью;

кэширование местоположения ресурсов данных в пределах заполненной компьютерами сети с использованием упомянутого сервера RNS;

запрашивание, по меньшей мере, двух местоположений ресурсов данных посредством шлюзового сервера одноранговых узлов из кэшируемых сервером RNS местоположений ресурсов данных;

разрешение запросов ресурсов из упомянутого шлюзового сервера одноранговых узлов с использованием, по меньшей мере, двух местоположений ресурсов через упомянутый сервер RNS, при этом, по меньшей мере, эти два местоположения ресурсов каждое определяет легальную точку доступа;

прием, по меньшей мере, этих двух местоположений ресурсов на шлюзовой сервер одноранговых узлов через упомянутый сервер RNS;

запрашивание того, какое из, по меньшей мере, этих двух местоположений ресурсов оптимально соответствует определяемым пользователем параметрам для передачи данных, при этом запрос, таким образом, определяет оптимальные местоположения ресурсов;

запрашивание легально защищенного выбранного файла данных из оптимальных местоположений ресурсов из заполненной компьютерами сети;

передача легально защищенного выбранного файла данных из оптимальных местоположений ресурсов; и

обработка переданного легально защищенного выбранного файла данных для доставки клиенту.

11. Не зависящий от источника способ доставки данных по п. 10, дополнительно содержащий этап верификации аутентичности клиента с использованием средства аутентификации клиента.

12. Не зависящий от источника способ доставки данных по п. 10, дополнительно содержащий этап верификации аутентичности сервера с использованием средств аутентификации сервера.

13. Не зависящий от источника способ доставки данных по п. 10, дополнительно содержащий этап фрагментации файлов данных в течение доставки файлов данных с использованием средства фрагментации доставки данных для улучшения осуществления доставки невредоносных потоков данных.

14. Не зависящий от источника способ доставки данных по п. 10, дополнительно содержащий этап индексации местоположений ресурсов с использованием средства индексации ресурсов для улучшения эффективности способа.

15. Не зависящий от источника способ доставки данных по п. 14, дополнительно содержащий этап сопоставления файлов данных независимо от метаданных файлов данных с использованием средства сопоставления файлов для улучшения эффективности способа.

16. Не зависящий от источника способ доставки данных по п. 10, дополнительно содержащий этап (этапы) предоставления (а) управления индустриальными правами (b) мониторинга соблюдения и/или (с) отчетности о соблюдении передачи файлов, подвергнувшихся интеллектуальной маршрутизации легально защищенных данных из, по меньшей мере, двух местоположений ресурсов данных.

17. Не зависящий от источника способ доставки данных по п. 10, дополнительно содержащий этап ассоциирования маркеров событий в заголовках кадров файлов данных с использованием средства ассоциирования маркера события для улучшения эффективности передачи файлов данных.

18. Не зависящий от источника способ доставки данных по п. 17, дополнительно содержащий этап интеграции рекламного контента в файлы данных с использованием средства ассоциирования маркера события.

19. Не зависящий от источника способ доставки данных по п. 15, в котором этап сопоставления файлов данных содержит следующие этапы:

извлечение данных о форме сигнала из первого файла данных с использованием средства извлечения данных, связанных, при этом извлеченные данные о форме сигнала содержат значения длины сегмента, при этом значения длины сегмента извлекаются относительно базового уровня извлечения данных и содержат значения длины сегмента от наименьшего до базового уровня и от пикового до базового уровня; получение сводных статистических данных из извлеченных данных о форме сигнала, при этом сводные статистические данные получают из значений длины сегмента, при этом сводные статистические данные содержат статистику длины сегмента от наименьшего до базового значения уровня и от пикового до базового уровня;

генерирование пользовательского маркера на основе полученных сводных статистических данных; ассоциирование пользовательского маркера с первым файлом данных, таким образом конструируя пользовательский отмеченный маркером файл данных; и

получение доступа к пользовательскому маркеру при сравнении второго файла данных с пользовательским отмеченным маркером файлом данных для трансляции выгодного контакта для позитивного медиафайла.

20. Система управления маршрутизацией данных для управления маршрутизацией данных в пределах сети доставки контента, упомянутая система управления маршрутизацией данных, содержащая

устройство для сопоставления данных маршрутизации, упомянутое устройство для сопоставления данных маршрутизации соединено с интеллектуальной системой маршрутизации, работоспособной в пределах сети доставки контента, упомянутая сеть доставки контента содержит множество источников данных, упомянутые источники данных содержат файлы данных, упомянутая сеть доставки контента выбирает файлы данных для конечного пользователя из оптимального местоположения источника данных, упомянутое оптимальное местоположение источника данных выбирается из группы, состоящей из источников данных, и оптимально выбирается на основе заранее определенных параметров, упомянутые источники данных определяют, по меньшей мере, две разных легальных точки доступа, упомянутое устройство для сопоставления предоставляет (а) управление правами индустрии (b) мониторинг соблюдения прав и/или (с) отчет о соблюдении прав при передачах файлов данных, подвергнувшихся интеллектуальной маршрутизации, легально защищенных данных, из оптимальных местоположений источников данных.

21. Система синхронизации интеллектуальной маршрутизации для предоставления потребителю широковещания с оптимальным источником, упомянутая система синхронизации интеллектуальной маршрутизации, содержащая средства интеллектуальной маршрутизации для выбора маршрутизации потребляемого легально защищенного контента для упомянутого потребителя из оптимальной легальной точки доступа, определяемой из, по меньшей мере, двух легальных точек доступа на основе заранее определенных параметров, определенных потребителем.

22. Система синхронизации интеллектуальной маршрутизации по п. 21, в которой широковещание с оптимальным источником характеризуется доставкой прямого источника из выбираемого легально защищенного контента для упомянутого потребителя как подсказано отобранным инициирующим источником.

23. Система синхронизации интеллектуальной маршрутизации по п. 22, в которой отобранный инициирующий источник выбирается из группы, состоящей из непрямого источника и прямого источника.

24. Система синхронизации интеллектуальной маршрутизации по п. 23, в которой заранее определенные параметры выбираются из группы параметров, содержащей параметры эффективности затрат и параметры качества данных.

25. Система синхронизации интеллектуальной маршрутизации по п. 23, в которой прямой источник является подключенным узлом, отобранный легально защищенный контент непосредственно получен на основе легального права прямого источника, чтобы выбрать упомянутый отобранный легально защищенный контент.

26. Система синхронизации интеллектуальной маршрутизации по п. 21, дополнительно содержащая (а) средства управления правами индустрии, (b) средства мониторинга соблюдения прав и/или (с) средства отчетности о соблюдении прав, упомянутые средства для управления, мониторинга и/или передачи отчетности выбранного легально защищенного контента.