Результат интеллектуальной деятельности: СИСТЕМА И СПОСОБ ДЛЯ ПОДДЕРЖКИ РАЗЛИЧНЫХ СХЕМ ЗАХВАТА И ДОСТАВКИ В СЕТИ РАСПРЕДЕЛЕНИЯ КОНТЕНТА

Область техники, к которой относится изобретение

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

Уровень техники

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

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

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

Что необходимо, так это системы и способы улучшения доставки потокового видеоконтента.

Раскрытие изобретения

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

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

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

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

Краткое описание чертежей

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

на фиг.1 показан вариант осуществления системы распределения контента;

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

на фиг.3 показан вариант реализации формата видео;

на фиг.4 показан вариант реализации формата аудио;

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

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

на фиг.7 показан вариант реализации формата видеофрагмента;

на фиг.8 показан вариант реализации формата аудиофрагмента;

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

на фиг.10 показан вариант реализации формата файла-контейнера;

на фиг.11 показан пример сборки файла в соответствии с вариантом осуществления.

Подробное описание иллюстративных вариантов осуществления

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

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

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

В варианте осуществления система и способ, предназначенные для того, чтобы поддерживать различные схемы захвата и доставки в сети распределения контента, имеют три стадии: стадия поступления мультимедийных данных, стадия кэширования, на которой мультимедийные данные поступают от сервера источника на пограничный сервер для кэширования, и стадия выхода мультимедийных данных. На стадии поступления мультимедийных данных исходный поток "живого" видео или файл кодируется, перекодируется или повторно кодируется в один формат кодирования видео, например H.264/AVC, а аудиопоток или файл кодируется, перекодируется или повторно кодируется в один формат кодирования аудио, например ААС. Для того чтобы охватить различия доступной ширины полосы пропускания, возможностей терминала и предпочтений пользователя, на стадии поступления мультимедийных данных для их адаптации подготавливается множество альтернативных мультимедийных данных, например видеоконтент с различным битрейтом, разрешением, частотой кадров и на разных языках. Более того, для того, чтобы на пограничных серверах осуществлять эффективное кэширование и перекодирование по запросу, аудио- и видеопотоки синхронно фрагментируют. На второй стадии для доставки мультимедийных данных от сервера источника пограничным серверам используется режим push или pull. В любом режиме мультимедийный контент передается порциями, при этом каждая порция состоит из одного или более фрагментов. В варианте осуществления мультимедийные данные сохраняются на пограничных серверах в виде фрагментов или порций, состоящих из фрагментов. На стадии выхода мультимедийных данных поддерживаются различные схемы доставки такие, как загрузка файла, поэтапная загрузка, потоковая передача по протоколу HTTP, потоковая передача RTP/RTSP.

На фиг.1 показана система распределения контента в соответствии с вариантом осуществления изобретения. Логически у системы есть стадия 102 поступления мультимедийных данных, стадия 104 кэширования мультимедийных данных и стадия 106 выхода мультимедийных данных. Физически система имеет сервер 108 источника и пограничный сервер ПО. В варианте осуществления сервер 108 источника и пограничный сервер 110 расположены в различных частях сети. Как альтернатива, сервера 108 и 110 могут быть совмещены. В варианте осуществления один или более серверов 108 источников могут поддерживать связь с одним или более пограничных серверов 110.

В варианте осуществления сервер 108 источника получает исходные мультимедийные данные, например, в форме мультимедийного файла и/или "живого" контента и осуществляет предварительную обработку мультимедийных данных для того, чтобы получить предварительно обработанные мультимедийные данные и данные описания. Предварительно обработанные мультимедийные данные сохраняются в запоминающем устройстве 114, которое может быть также жестким диском или другим устройством хранения, в форме мультимедийных данных и описания. В варианте осуществления предварительная обработка мультимедийных данных функционально осуществляется процессором 116. Сервер 108 источника передает предварительно обработанные мультимедийные данные и описание пограничному серверу ПО через сетевое подключение 118. Сетевое подключение 118 может быть прямым подключением или любым известным сетевым подключением, включая, но не ограничиваясь, проводное или беспроводное соединение, Ethernet, интернет IP-подключение или другой тип широкополосного подключения.

Пограничный сервер ПО получает предварительно обработанные мультимедийные данные от сервера 108 источника и сохраняет данные в кэше 122, используя функцию 120 кэширования. Если нужно, функция 126 потоковой передачи создает потоковые данные, используя функцию 128 перекодирования, которая перекодирует предварительно обработанные мультимедийные данные в целевой формат медиа-клиента. В варианте осуществления функция потоковой передачи и функция перекодирования по запросу осуществляются процессором 124.

В варианте осуществления для увеличения эффективности управления системой и адаптации на стадии 104 кэширования мультимедийных данных используется унифицированный формат мультимедийных данных. Унифицированный формат мультимедийных данных содержит унифицированный видеоформат, унифицированный аудиоформат и унифицированный формат файла-контейнера. Например, в одном варианте осуществления в качестве унифицированных форматов мультимедийных данных используются видеоформат Н.264 и аудиоформат ААС (перспективное звуковое кодирование). В альтернативных вариантах осуществления могут использоваться другие форматы, такие как видеоформат MPEG-2 и аудиоформат ААС. На стадии 102 поступления мультимедийных данных видеопоток кодируется, повторно кодируется или перекодируется в унифицированный видеоформат, например формат Н.264, аудиопоток кодируется, повторно кодируется или перекодируется в унифицированный аудиоформат, например формат ААС, а формат файла-контейнера перекодируется, а унифицированный формат файла-контейнера. В одном варианте осуществления унифицированный формат файла-контейнера соответствует базовому формату ISO мультимедийных файлов. В альтернативных вариантах осуществления могут использоваться другие форматы файлов.

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

На фиг.2 показан вариант осуществления процесса 200 предварительной обработки мультимедийных данных на стадии поступления мультимедийных данных варианта осуществления. Блок 202 разделения контента получает мультимедийные файлы или "живой" контент и разделяет контент на видеоконтент и аудиоконтент. Видеоконтент сначала сегментируется (шаг 204), а затем при необходимости перекодируется (шаг 206), в то время как аудиоданные сначала при необходимости перекодируются (шаг 208), а затем сегментируются (шаг 210). Сегментированные и возможно перекодированные видео- и аудиоданные обрабатываются блоком 212 управления контейнерами и сохраняются в запоминающем устройстве 216, которое может быть жестким диском или другим устройством хранения. Блок 214 выработки описания мультимедийных данных вырабатывает описание аудио- и видеосегментов, которое также сохраняется в запоминающем устройстве 216. В альтернативных вариантах осуществления порядок сегментирования и перекодирования может отличаться от того, что показано на фиг.2.

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

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

В варианте осуществления аудиофрагменты выравниваются согласно видеофрагментам следующим образом. Допустим, что Dv_i - это длительность видеофрагмента i, Da_i(n) - это длительность аудиофрагмента i, содержащего n сэмплов, Da_i(n+1) – это длительность аудиофрагмента i, содержащего n - 1 сэмпл, a Da_(n+1) - это длительность аудиофрагмента i, содержащего n+1 сэмпл. Тогда число аудиосэмплов, содержащихся в аудиофрагменте i равно n, для которого выполнены оба следующих условия:

В одном варианте осуществления для поддержания эффективного управления файлами и хранения на сервере источника все фрагменты, принадлежащие одному варианту контента, сохраняются в одном треке файла согласно спецификации базового формата ISO мультимедийных файлов. На фиг.3 показан вариант реализации видеоформата 300 для каждого уровня качества видеопотока. Видеоформат 300 имеет заголовок 302 типа файла, мультимедийные метаданные 304, один или более видеофрагментов 310 и блок 320 произвольного доступа к фрагментам видеоклипа. Блок 304 мультимедийных метаданных имеет заголовок 306 видеоклипа и заголовок 308 видеотрека, каждый фрагмент 310 имеет заголовок 312 фрагмента и мультимедийные данные 314, которые содержат фактические видеоданные. Блок 320 произвольного доступа к фрагментам видеоклипа имеет блок 322 произвольного доступа к трекам фрагмента и блок 324 смещения произвольного доступа к фрагментам видеоклипа.

На фиг.4 показан вариант реализации аудиопотока 400, который аналогичен формату 300 видеопотока. Аудиоформат 400 имеет заголовок 402 типа файла, мультимедийные метаданные 404, один или более аудиофрагментов 410 и блок 420 произвольного доступа к фрагментам видеоклипа. Блок 404 мультимедийных метаданных имеет заголовок 406 видеоклипа и заголовок 408 видеотрека, каждый фрагмент 410 имеет заголовок 412 фрагмента и мультимедийные данные 414, которые содержат фактические аудиоданные. Блок 420 произвольного доступа к фрагментам видеоклипа имеет блок 422 произвольного доступа к трекам фрагмента и блок 424 смещения произвольного доступа к фрагментам видеоклипа.

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

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

На фиг.6 показан вариант осуществления схемы 600 хранения предварительно обработанных мультимедийных данных на стадии поступления мультимедийных данных. Один или более видеофайлов 604 и 606 и один или более аудиофайлов 608 и 610 сохранены так, что описываются одним файлом 602 описания мультимедийных данных. В варианте осуществления каждый видеофайл 604 и 606 может представлять различные уровни качества, а каждый аудиофайл 608 и 610 может представлять особый целевой аудиокодек, язык канала и/или битрейт.Один или более заранее вычисленных файлов-контейнеров или файлов 612 и 614 манифеста для каждой схемы распределения дополнительно сохраняются так, что описываются файлом 602 описания мультимедийных данных.

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

На фиг.7 показан вариант реализации формата 700 порции видео, имеющей фрагмент 702 видеоклипа и мультимедийные данные 704. В варианте осуществления каждая порция видео содержит один видеофрагмент. Как альтернатива, может использоваться более одного фрагмента. В одном варианте осуществления фрагмент 702 видеоклипа форматируется согласно спецификации базового формата ISO мультимедийных файлов и содержит информацию о типе, размере и местоположении каждого сэмпла в мультимедийных данных 704. В варианте осуществления каждый видеофрагмент именуется следующим образом: "v_xx_yyyyy.frv", где "хх" представляет собой двузначный ID видеотрека, а "ууууу" - пятизначный номер последовательности фрагмента. Например, "v_01_00001.frv" - это первый видеофрагмент видеотрека №1. В альтернативных вариантах осуществления могут использоваться другие форматы и схемы именования.

На фиг.8 показан вариант осуществления формата 800 порции аудио, имеющей фрагмент 802 видеоклипа и мультимедийные данные 804, аналогичного формату 700 порции видео. В варианте осуществления каждая порция видео содержит один аудиофрагмент. В одном варианте осуществления фрагмент 802 видеоклипа форматируется согласно спецификации базового формата ISO мультимедийных файлов и содержит информацию о типе, размере и местоположении каждого сэмпла в мультимедийных данных 804. В варианте осуществления каждый видеофрагмент именуется следующим образом: "v_xx_yyyyy.fra", где "хх" представляет собой двузначный ID аудиотрека, а "УУУУУ"^_ пятизначный номер последовательности фрагмента. Например, "v_01_00001.fra" - это первый видеофрагмент аудиотрека №1. В альтернативных вариантах осуществления могут использоваться другие форматы и схемы именования.

На фиг.9 показан вариант осуществления внутренней схемы 900 хранения мультимедийных данных для пограничного сервера на стадии кэширования. В варианте осуществления контент сохраняется в одном или более файлах-контейнерах 904, 906 и 908, каждый из которых указывается в XML-описании 902 мультимедийных данных и соответствует варианту контента. В варианте осуществления XML-описание 902 мультимедийных данных форматируется согласно SMIL-шаблону, показанному на фиг.5. С каждым файлом-контейнером 904, 906 и 908 связан один или более файл видеофрагмента и/или один или более файл аудиофрагмента. В одном варианте осуществления файлы 910, 912, 914, 916, 918и 920 фрагментов в файле-контейнере 1 (904) представляют собой аудио и видео первого варианта контента. Фрагменты 922, 924 и 926 в файле-контейнере 2 (906) и фрагменты 928, 930, 932, 934, 936 и 938 в файле-контейнере j (908) представляют собой другие варианты контента. В варианте осуществления варианты контента создаются на сервере источника. Варианты контента могут вырабатываться в соответствии с числом таких параметров сервера источника, как качество поступившего контента, и в соответствии с такими переменными клиента, как ширина полосы пропускания сети, возможности ЦП (центрального процессора), разрешение экрана и/или конфигурация конечного пользователя. В варианте осуществления имеется j файлов-контейнеров и m фрагментов. В варианте осуществления каждый видеофрагмент обозначен согласно шаблону n_m, где n - это общее число вариантов уровней качества видео, а каждый аудиофрагмент обозначен согласно шаблону k_m, где k - это общее число вариантов аудиотрека.

В варианте осуществления для отдельных технологий потоковой передачи определены файлы манифеста. Например, на фиг.9 имеется XML-файл 940 манифеста клиента Silverlight, который представляет собой файл манифеста, форматированный для плавной потоковой передачи Microsoft Silverlight. В альтернативных вариантах осуществления могут использоваться другие файлы манифеста для других технологий потоковой передачи таких, как Adobe Flash.

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

Например, вариант осуществления, показанный на фиг.9, поддерживает плавную потоковую передачу Microsoft Silverlight. Здесь, плавная потоковая передача Microsoft Silverlight использует один файл манифеста с фрагментированными аудио и видео, доставляемыми клиентскому устройству воспроизведения фрагмент за фрагментом, а для запроса специфических аудио- и видеофрагментов использует уровень качества и время начала. В варианте осуществления уровень качества отображается на ID аудио- и видеотрека, а время начала отображается на номер фрагмента в последовательности. При наличии ID аудио/видеотрека и номера фрагмента в последовательности соответствующий файл фрагмента a_xx_yyyyy.fra или v_xx_yyyyy.frv передается клиенту Silverlight для воспроизведения напрямую из кэша. В варианте осуществления фрагменты подсказки, показанные на фиг.9, содержат информацию, которая может использоваться для содействия при формировании пакетов транспортного потока MPEG-2 из аудио- и видеофрагментов.

На фиг.10 показан вариант осуществления файла-контейнера 1000. Файл-контейнер 1000 имеет заголовок 1002 типа файла и метаданные 1004 мультимедийных данных. Метаданные 1004 мультимедийных данных имеют заголовок 1006 видеоклипа, заголовок 1008 аудиотрека и заголовок 1010 видеотрека.

В варианте осуществления загрузка файла и поэтапная загрузка по протоколу HTTP, которая использует полный перемежающийся файл, осуществляются следующим образом. С использованием видеофрагмента 700, показанного на фиг.7, аудиофрагмента 800, показанного на фиг.8, и файла-контейнера 1000, показанного на фиг.10, как изображено на фиг.11, собирается один полный МР4-файл для загрузки и поэтапной загрузки по протоколу HTTP. Здесь, на стадии выхода путем компоновки заголовка файла и метаданных из файла-контейнера и фактических видео- и аудиоданных из фрагментов 1104 и 1106 вырабатывается МР4-файл 1102.

В варианте осуществления используется унифицированный внутренний кодек и формат контейнера. На стадии поступления мультимедийных данных исходный поток "живого" видео или файл кодируется, перекодируется или повторно кодируется в один формат кодирования видео, например H.264/AVC, а любой аудиопоток или файл кодируется, перекодируется или повторно кодируется в один формат кодирования аудио, например ААС. На стадии выхода мультимедийных данных разделение на порции видео и аудио на пограничном сервере позволяет поддерживать различные схемы доставки, включая загрузку файла, поэтапную загрузку, потоковую передачу HTTP и потоковую передачу RTP/RTSP.

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

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

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

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