СПОСОБ И УСТРОЙСТВО, ПРЕДНАЗНАЧЕННЫЕ ДЛЯ ЗАГРУЗОК ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В СЕТИ Российский патент 2013 года по МПК H04L9/32 

Перекрестная ссылка на родственные заявки

Эта заявка испрашивает приоритет согласно 35 U.S.C 119 предварительной заявки 60/925,810, зарегистрированной в США 23 апреля 2007 г.

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

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

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

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

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

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

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

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

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

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

Сущность изобретения

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

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

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

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

фиг. 1 - блок-схема, иллюстрирующая иллюстративную систему, использующую варианты осуществления настоящего раскрытия,

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

фиг. 3 - блок-схема, иллюстрирующая иллюстративный вариант осуществления одного из устройств шлюзов фиг. 1,

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

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

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

фиг. 7 - схема иллюстративных структур данных, использующих варианты осуществления настоящего раскрытия.

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

Описание предпочтительных вариантов осуществления

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

Теперь, ссылаясь на чертежи и, более конкретно, на фиг. 1, изображена иллюстративная система 100, использующая варианты осуществления настоящего раскрытия. Как указано на фиг. 1, иллюстративная система 100 включает в себя устройства 10 шлюзов, главный распределительный щит 20 (MDF) и промежуточные распределительные щиты (IDF) 30. Иллюстративная система 100 также включает в себя один или более источников сигнала и клиентские устройства, не изображены. В соответствии с иллюстративным вариантом осуществления фиг. 1 представляет типичную систему, которая может быть использована в MDU, использующем Ethernet или другой тип сети, такой как коаксиально-кабельная технология, технология цифровой абонентской линии (DSL), технология передачи данных по электросети, беспроводная технология или тому подобные.

На фиг. 1 каждое устройство 10 шлюза оперативно соединено и взаимодействует с источником сигнала (т.е. поставщиком услуг), таким как головной узел сети спутниковой, наземной, кабельной, Internet и/или другого типа широковещательной системы. В соответствии с иллюстративным вариантом осуществления каждое устройство 10 шлюза принимает множество сигналов, включающих в себя аудио, видео и/или содержание данных, из источника (источников) сигнала, преобразует формат сигнала принятых сигналов, а затем посылает соответственные потоки данных в формате, таком как формат протокола Internet (IP), через сеть посредством MDF 20 и IDF 30 в клиентские устройства (например, телеприставки, телевизоры и т.д.) на основании запросов, сделанных пользователями в соответственных устройствах мест проживания. Как известно в данной области техники, MDF 20 и IDF 30 работают в качестве устройств коммутации и маршрутизации. Число устройств 10 шлюзов, MDF 20 и IDF 30, включенных в данную установку MDU, может изменяться на основании выбора конструкции. Например, каждый IDF 30 может обслуживать клиентские устройства, присутствующие на данном этаже, и/или другую определенную часть MDU. Несмотря на то, что система 100 изображена и описана в настоящей заявке как являющаяся сетью Ethernet, использующей специфичный сетевой формат, специалисты в данной области техники поймут, что принципы настоящих вариантов осуществления также могут быть применены к другим типам сетей, таким как сети, использующие коаксиально-кабельную технологию, технологию цифровой абонентской линии (DSL), технологию передачи данных по электросети и/или беспроводную технологию, и некоторое число возможных сетевых форматов. В соответствии с иллюстративными вариантами осуществления настоящего раскрытия, которые будут описаны далее, каждое устройство 10 шлюза действует с возможностью предоставления возможности загрузки файлов, связанных с работой устройства 10 шлюза и клиентских устройств, с минимальным вмешательством оператора.

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

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

Ссылаясь на фиг. 2, изображена блок-схема, иллюстрирующая соответственную часть одного из устройств 10 шлюзов фиг. 1. Устройство 10 шлюза фиг. 2 включает в себя блок 12 ввода/вывода (I/O), процессор 14 и память 16. Для ясности описания определенные традиционные элементы, связанные с устройством 10 шлюза, такие как определенные управляющие сигналы, сигналы питания, и/или другие элементы, могут быть не изображены на фиг. 2.

Блок 12 I/O действует с возможностью выполнения функций I/O устройства 10 шлюза, включая в себя прием сигналов из источников сигналов, прием сигналов из клиентских устройств и передачу сигналов в клиентские устройства. В соответствии с иллюстративным вариантом осуществления блок 12 I/O действует с возможностью приема сигналов, таких как аудио, видео и/или сигналы данных, в аналоговом и/или цифровом формате из одного или более источников сигналов, таких как спутниковые, наземные, кабельные или Internet. Блок 12 I/O также действует с возможностью вывода сигналов в один или более источников сигналов. Блок 12 I/O также действует с возможностью передачи сигналов в клиентские устройства и приема сигналов из клиентских устройств через MDF 20.

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

Процессор 14 также действует с возможностью выполнения кода программного обеспечения, который дает возможность загрузки файлов, связанных с работой устройства 10 шлюза и клиентских устройств, с минимальным вмешательством оператора. Дополнительные детали относительно этого аспекта процессора 14 и связанных с ним функций будут предоставлены в настоящей заявке позже. Процессор 14 также действует с возможностью выполнения и/или включения других функций устройства 10 шлюза, включая обработку вводов пользователя, сделанных через пользовательское устройство ввода, не изображенное, считывание данных из памяти 16 и запись данных в память 16 и другие операции, как известно специалистам в данной области техники, но не ограниченных ими. В предпочтительном варианте осуществления процессор 14 включает в себя устройство микропроцессора, которое может принимать информацию из блока 12 I/O, включающую в себя первый файл, первый элемент аутентификации и второй элемент аутентификации. Процессор 14 определяет, является ли второй элемент аутентификации достоверным для устройства шлюза, и предоставляет первый элемент аутентификации и второй файл, связанный с первым файлом, для хранения, передачи и последующего использования с помощью одного или более клиентских устройств, если второй элемент аутентификации является достоверным для устройства шлюза. Связь между первым файлом и вторым файлом может включать в себя первый файл, содержащий метаданные, идентифицирующие второй файл, и второй файл, содержащийся в первом файле, но не ограничена ими.

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

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

Теперь, ссылаясь на фиг. 3, изображена блок-схема иллюстративного спутникового устройство 300 шлюза. Спутниковое устройство 300 шлюза подобно устройству 10 шлюза, как описано на фиг. 1. Как проиллюстрировано, спутниковое устройство 300 шлюза включает в себя источник 340 питания, два препроцессора 341а и 341b и постпроцессор 352. Источник 340 питания может быть одним из некоторого числа источников питания переменного тока или постоянного тока промышленного стандарта, конфигурируемым таким образом, чтобы дать возможность препроцессорам 341а, b и постпроцессору 352 выполнять функции, описанные ниже.

Спутниковое устройство 300 шлюза также может включать в себя два препроцессора 341а, b. В одном варианте осуществления каждый из препроцессоров 341а, b может быть сконфигурирован с возможностью приема двух сигналов, предоставленных из разделителей 1:2, не изображенных. Например, препроцессор 341а может принимать два сигнала из одного разделителя 1:2, а препроцессор 341b может принимать два сигнала из второго разделителя 1:2.

Затем препроцессоры 341а, b могут дополнительно разделять сигналы с использованием разделителей 342а, 342b, 342с и 342d 1:4. Если разделены, сигналы могут проходить в четыре группы 344а, 344b, 344с и 344d устройств двойной линии связи согласующего устройства. Каждая из двойных линий связи согласующего устройства в группах 344а-344d устройств, может быть сконфигурирована с возможностью согласования двух услуг в сигналах, принятых с помощью этой отдельной двойной линии связи согласующего устройства, чтобы создать один или более транспортных потоков. Каждая из двойных линий связи 344а, 344b, 344с и 344d согласующего устройства передает транспортные потоки в один из формирователей 348а, 348b, 348с и 348d низковольтной дифференциальной сигнализации (“LVDS”). Формирователи 348а-348d LVDS могут быть сконфигурированы с возможностью усиления транспортных сигналов для передачи в постпроцессор 352. В альтернативных вариантах осуществления другие виды дифференциальных формирователей и/или усилителей могут быть использованы вместо формирователей 348а-348d LVDS. Другие варианты осуществления могут использовать преобразование в последовательную форму всех транспортных сигналов вместе для маршрутизации в постпроцессор 352.

Как проиллюстрировано, препроцессоры 341а, b также могут включать в себя микропроцессоры 346а и 346b. В одном варианте осуществления микропроцессоры 346а, b управляют и/или передают команды в группы 344а-344d устройств двойных линий связи согласующих устройств и разделители 342а-342d 1:4. Микропроцессоры 346а, b могут содержать, например, микропроцессоры ST10, созданные ST Microelectronics. В других вариантах осуществления может быть использован другой процессор или управление может быть получено из процессоров в постпроцессоре 352. Микропроцессоры 346а, b могут быть соединены с модулями 350а и 350b приемника и передатчика LVDS. Модули 350а, b приемника/передатчика LVDS облегчают передачи транспортных сигналов между группами 344а-344d устройств двойных линий связи согласующих устройств и компонентами в постпроцессоре 352, как будет описано дополнительно ниже.

Обращаясь затем к постпроцессору 352, постпроцессор 352 включает в себя приемники 352а, 352b, 352с и 352d LVDS, которые сконфигурированы с возможностью приема сигналов транспортного потока, переданных с помощью формирователей 348а-348d LVDS. Постпроцессор 352 также включает в себя модули 356а и 356b приемника/передатчика LVDS, которые сконфигурированы с возможностью взаимодействия с модулями 350а, b приемника/передатчика LVDS.

Как проиллюстрировано, приемники 354а-354d LVDS и приемник/передатчики 356а, b LVDS сконфигурированы с возможностью взаимодействия с контроллерами или транспортными процессорами 358а и 358b. В одном варианте осуществления транспортные процессоры 358а, b сконфигурированы с возможностью приема транспортных потоков, созданных с помощью двойных линий связи согласующих устройств в препроцессорах 341а, b. Транспортные процессоры 358а, b также могут быть сконфигурированы с возможностью повторного оформления в виде пакетов транспортных потоков в пакеты протокола Internet (IP), которые могут быть переданы многоадресным способом через локальную сеть, описанную ранее. Например, транспортные процессоры 358а, b могут повторно оформлять в виде пакетов пакеты широковещательного протокола в пакеты протокола IP, а затем передавать многоадресным способом эти пакеты IP по адресу IP в одно или более клиентских устройств.

Транспортные процессоры 358а, b также могут быть соединены с шиной 362, такой как 32-битовая шина межсоединения периферийных компонентов (“PCI”) 66 MHz. Через шину 362 транспортные процессоры 358а, b могут взаимодействовать с другим контроллером или сетевым процессором 370, интерфейсом 384 Ethernet и/или с разъемом 366 расширения. Сетевой процессор 370 может быть сконфигурирован с возможностью приема запросов услуг из локальной сети и управления транспортными процессорами 358а, b, чтобы передавать многоадресным способом запрошенные услуги. Сетевой процессор 370 также может управлять загрузками программного обеспечения, используемого клиентскими устройствами. В одном варианте осуществления сетевой процессор является IXP425, созданным Intel, и выполняет код программного обеспечения, предназначенный для приема информации, такой как данные, из препроцессоров 341а, b. Загрузки данных также могут происходить с использованием интерфейса 368 или модема Ethernet. Данные могут включать в себя метаданные, один или более выполняемых файлов, первый элемент аутентификации и второй элемент аутентификации. Сетевой процессор 370 определяет, является ли второй элемент аутентификации достоверным для устройства шлюза, и предоставляет первый элемент аутентификации и второй файл, связанный с первым файлом, для хранения, передачи и последующего использования с помощью одного или более клиентских устройств, если второй элемент аутентификации является достоверным для устройства шлюза. Связь между первым файлом и вторым файлом может включать в себя первый файл, содержащий метаданные, идентифицирующие второй файл, и второй файл, содержащийся в первом файле, но не ограничена ими. Несмотря на то, что не проиллюстрировано, сетевой процессор 370 также может быть сконфигурирован с возможностью передачи данных статуса в лицевую панель спутникового устройства 300 шлюза или поддержки устранения неисправностей или мониторинга спутникового устройства 300 шлюза через порты устранения неисправностей.

Как проиллюстрировано, транспортные процессоры 358а, b соединены с интерфейсом 368 Ethernet через шину 362. В одном варианте осуществления интерфейс 368 Ethernet является гигабитным интерфейсом Ethernet, который обеспечивает либо интерфейс в виде медного кабеля, либо волоконно-оптический интерфейс в локальную сеть. В других вариантах осуществления могут быть использованы другие интерфейсы, такие как интерфейсы, используемые в приложениях цифровой домашней сети. Кроме того, шина 362 также может быть соединена с разъемом расширения, таким как разъем расширения межсоединения периферийных компонентов (PCI), чтобы дать возможность модернизации или расширения спутникового устройства 300 шлюза.

Транспортные процессоры 358а, b также могут быть соединены с главной шиной 364. В одном варианте осуществления главная шина 364 является 16-битовой шиной данных, которая соединяет транспортные процессоры 358а, b с модемом 372, который может быть сконфигурирован с возможностью взаимодействия через коммутируемую телефонную сеть общего пользования (PSTN) 28. В альтернативных вариантах осуществления модем 372 также может быть соединен с шиной 362.

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

Важно заметить, что транспортные процессоры 358а, b, сетевой процессор 370 и микропроцессоры 346а, b могут быть включены в один большой контроллер или устройство обработки, которое может выполнять любые или все из функций управления, необходимые для работы спутникового устройства 300 шлюза. Некоторые или все из функций управления также могут быть распределены в другие блоки и не влияют на первоначальную операцию в спутниковом устройстве 300 шлюза.

Ссылаясь на фиг. 4 на фиг. 6, изображена блок-схема последовательности этапов, иллюстрирующая иллюстративный способ настоящего раскрытия. Для целей примера и объяснения способ фиг. 4 на фиг. 6 будет описан со ссылкой на систему 100 фиг. 1 и элементы устройства 10 шлюза фиг. 2. Следует заметить, что способ фиг. 4 на фиг. 6 также может быть описан со ссылкой на устройство 300 шлюза фиг. 3. Также для целей примера и объяснения этапы фиг. 4 на фиг. 6 будут в первую очередь описаны со ссылкой только на одно устройство 10 шлюза. Однако на практике предполагают, что каждое устройство 10 шлюза в данной установке MDU может автономно и независимо выполнять некоторые или все из этапов фиг. 4 на фиг. 6. Этапы фиг. 4 на фиг. 6 являются только иллюстративными и никоим образом не предназначены для того, чтобы ограничивать настоящее раскрытие.

На этапе 410 запускают таймер автоматического обновления. В соответствии с иллюстративным вариантом осуществления каждое устройство 10 шлюза поддерживает таймер автоматического обновления для целей определения того, когда начать процесс модернизации файла. Как указано на фиг. 4, истечение таймера автоматического обновления вызывает повторный запуск таймера на этапе 420. Из этапа 420 последовательность операций процесса продвигается на этап 430, где начинается процесс модернизации файла.

На этапе 430 файл данных загружают в устройство 10 шлюза из источника сигнала, такого как предварительно определенный сервер файла (например, sftp.mfh3.com и т.д.). Загруженный файл данных может быть принят с помощью входа устройства 10 шлюза, такого как I/O 12. Принятый файл данных содержит метаданные, включающие в себя описания файлов, доступных для загрузки из того же самого или другого дистанционного сервера файла. В соответствии с иллюстративным вариантом осуществления используемым форматом файла данных является расширяемый язык разметки (XML), несмотря на то, что также могли бы быть использованы другие типы форматов файла. XML обеспечивает основу для создания документов и систем документов. XML работает на двух основных уровнях: первом, он обеспечивает базовый синтаксис для разметки документов, и втором, он обеспечивает синтаксис для объявления структур документов. Самое важное, XML обеспечивает базовый синтаксис, который может быть использован для того, чтобы совместно использовать информацию между разными видами компьютеров, разными приложениями и разными организациями без необходимости проходить через много уровней преобразования. В соответствии с этим иллюстративным вариантом осуществления каждый элемент в файле данных, загруженном на этапе 430, может содержать один или более типов информации XML. Примеры типов информации XML включают в себя имя файла, версию файла, размер файла, тип файла, информацию файла и информацию аутентификации, такую как флаг подписи. Другие атрибуты файла, отличные от атрибутов, перечисленных выше, также являются возможными.

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

Из этапа 430 и “A” последовательность операций процесса продвигается на этап 440, где устройство 10 шлюза выполняет синтаксический анализ загруженного файла данных. В соответствии с иллюстративным вариантом осуществления процессор 14 выполняет синтаксический анализ и исследует описания содержаний файла данных на этапе 440. Как указано выше, файл данных содержит описания файлов, доступных для загрузки. Такие файлы, например, могут включать в себя выполняемые файлы для устройства 10 шлюза, файлы конфигурирования для устройства 10 шлюза, файлы ключей для устройства 10 шлюза, выполняемые файлы для одного или более клиентских устройств и/или другие типы файлов. Выполняемые файлы также могут быть упомянуты в настоящем описании как “образы”. Специфичная информация XML, которая может быть использована в этом варианте осуществления, является следующей:

Типы информации файла указывают с помощью тэгов XML следующим образом:

<имя тэга> информация </имя тэга>

Полной структурой для одного файла является:

<образ шлюза=”AAAA”>

<ID изготовителя=”##”>

<ID модели=“####”>

<версия>##.##.##</версия>

<размер>#######</размер>

<подписан>#</подписан>

<тип файла>#</тип файла>

<информация><информация>

<имя файла>AAA##_####_##.##.##.zip</имя файла>

</модель>

</изготовитель>

</MFH3>

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

<образ шлюза=”клиент”>

<!-Томпсон-->

<ID изготовителя=”7d”>

<!-D11i-->

<ID модели=“000e”>

<версия>01.02.03</версия>

<размер>1234567</размер>

<подписан>Y</подписан>

<тип файла>zip</тип файла>

<информация><информация>

<имя файла>mid7d_000e.010203.zip</имя файла>

</модель>

</изготовитель>

</шлюз>

Структура XML концептуально может быть рассмотрена как структура каталога с атрибутами как часть имени каталога. Иначе говоря, информация для вышеупомянутого файла концептуально находится в каталоге “шлюз: клиент/изготовитель:7d/модель:000е”.

Файл для данной модели второго клиентского устройства указывают с помощью добавления следующей информации перед тэгом </изготовитель>:

<!-клиент01-->

<ID модели=“000f”>

<версия>01.02.03</версия>

<размер>1234567</размер>

<подписан>N</подписан>

<тип файла>bin</тип файла>

<информация><информация>

<имя файла>mid7d_000f.010203.bin</имя файла>

</модель>

Файл XML может создавать каталог один раз. Иначе говоря, все элементы клиентских устройств могут быть между тэгом <образ шлюза=”клиент”> и тэгом </шлюз>. Все образы клиентских устройств от Томпсона могут быть между тэгом <ID изготовителя=”7d”> и тэгом </изготовитель>.

Синтаксис вышеупомянутой секции “замена” является следующим:

<замена>

<ID CAM=”0011579046168”>использоватьBeta</САМ>

<ID CAM=”0011579046168”> использовать предыдущее</САМ>

<ID сайта=“Alpha”>использоватьAlpha</сайт>

<ID рынка>”93”использоватьIndy</рынок>

</замена>

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

Из этапа 440 последовательность операций процесса продвигается на этап 510 фиг. 5, как указано с помощью “В”. На этапе 510 устройство 10 шлюза делает определение относительно того, что совпадает ли идентификация рынка для устройства 10 шлюза (если файл шлюза) или применяемого клиентского устройства (если файл клиентского устройства) с соответствующим элементом в секции замены файла данных. В соответствии с иллюстративным вариантом осуществления процессор 14 выполняет этап 510 с помощью сравнения соответствующего элемента в секции замены файла данных с данными идентификации рынка для устройства 10 шлюза или применяемого клиентского устройства, хранимого в памяти 16.

Если определение на этапе 510 является отрицательным, последовательность операций процесса продвигается на этап 520, где устройство 10 шлюза делает определение относительно того, что совпадает ли идентификация сайта для устройства 10 шлюза (если файл шлюза) или применяемого клиентского устройства (если файл клиентского устройства) с соответствующим элементом в секции замены файла данных. В соответствии с иллюстративным вариантом осуществления процессор 14 выполняет этап 410 с помощью сравнения соответствующего элемента в секции замены файла данных с данными идентификации сайта для устройства 10 шлюза или применяемого клиентского устройства, хранимого в памяти 16.

Если определение на этапе 520 является отрицательным, последовательность операций процесса продвигается на этап 530, где устройство 10 шлюза делает определение относительно того, совпадает ли идентификации модуля условного доступа (САМ) для устройства 10 шлюза (если файл шлюза) или применяемого клиентского устройства (если файл клиентского устройства) с соответствующим элементом в секции замены файла данных. В соответствии с иллюстративным вариантом осуществления процессор 14 выполняет этап 410 с помощью сравнения соответствующего элемента в секции замены файла данных с данными идентификации САМ для устройства 10 шлюза или применяемого клиентского устройства, хранимого в памяти 16.

Если определение на любом этапе 510, 520 или 530 является положительным, последовательность операций процесса продвигается на этап 540, где определяют с помощью процессора 14, что устройство 10 шлюза будет использовать информацию файла замены, чтобы идентифицировать имя версии, чтобы загрузить или выполнить синтаксический анализ из первоначального файла данных. То есть, имя версии файла, чтобы загрузить или выполнить синтаксический анализ, получают из секции замены файла данных. В примере, приведенном выше, если определение на этапе 510 является положительным (т.е. идентификация рынка совпадает), именем версии файла для загрузки является “использоватьIndy”. Подобным образом, если определение на этапе 520 является положительным (т.е. идентификация сайта совпадает), именем версии файла для загрузки является “использоватьAlpha”. Также если определение на этапе 530 является положительным (т.е. идентификация САМ совпадает) и идентификация САМ устройства 10 шлюза или применяемого клиентского устройства является “001579046168”, тогда именем версии файла для загрузки является “использоватьBeta”. В противоположность, если определения на каждом из этапов 510, 520 и 530 являются отрицательными, последовательность операций процесса продвигается на этап 550, где определяют с помощью процессора 14, что устройство 10 шлюза будет использовать информацию файла по умолчанию, чтобы идентифицировать имя версии файла для загрузки. Информацию файла по умолчанию задают также в файле данных, но она не изображена специально выше. Подобные этапы предпринимают, если выполняют синтаксический анализ идентифицированного выполняемого файла из первоначального файла данных.

Из этапа 540 или этапа 550 последовательность операций процесса продвигается на этап 610 фиг. 6, как указано с помощью “С”. На этапе 610 делают определение относительно того, совпадает ли информация файла (т.е. информация замены на этапе 540 или информация по умолчанию на этапе 550) с идентификацией изготовителя и идентификацией модели для устройства 10 шлюза или конкретного клиентского устройства. В соответствии с иллюстративным вариантом осуществления процессор 14 выполняет этап 610 с помощью сравнения элементов идентификации изготовителя и идентификации модели файла данных с данными идентификации изготовителя и идентификации модели для устройства 10 шлюза или конкретного клиентского устройства, хранимыми в памяти 16.

Если определение на этапе 610 является положительным, последовательность операций процесса продвигается на этап 620, где делают определение относительного того, сохранило ли уже устройство 10 шлюза версию файла, заданного с помощью замены или информации по умолчанию. В соответствии с иллюстративным вариантом осуществления процессор 14 выполняет этап 620 с помощью сравнения версии файла, заданного с помощью замены или информации по умолчанию, с версией файла, хранимой в текущей момент в памяти 16.

Если определение на этапе 610 является отрицательным или определение на этапе 620 является положительным, последовательность операций процесса продвигается на этап 630, где делают определение относительно того, выполнило ли устройство 10 шлюза синтаксический анализ файла данных. В соответствии с иллюстративным вариантом осуществления процессор 14 выполняет этап 630 с помощью определения, выполнен ли синтаксический анализ всего файла данных. Если определение на этапе 630 является положительным, последовательность операций процесса продвигается на этап 640, где способ заканчивается. В качестве альтернативы, если определение на этапе 630 является отрицательным, последовательность операций процесса образует цикл обратно на этап 440 фиг. 4, как указано с помощью “А”, и вышеупомянутые этапы повторяют до тех пор, пока не будет выполнен синтаксический анализ всего файла данных для всех типов файлов, представляющих интерес, а именно файлов для устройства 10 шлюза, а также для любых связанных клиентских устройств.

Теперь, ссылаясь опять на этап 620, если определение на нем является отрицательным, последовательность операций процесса продвигается на этап 650, где новую версию файла загружают в устройство 10 шлюза, и проверяют элемент аутентификации (т.е. подпись), связанный с устройством 10 шлюза, который присоединяют к новой версии файла, под управлением процессора 14. Вновь загруженный файл может быть принят способом, подобным способу, описанному для этапа 430. В качестве альтернативы, на этапе 650 синтаксический анализ новой версии файла может быть выполнен из первоначального файла данных, если версия файла включена в качестве части первоначального файла данных, и проверяют элемент аутентификации. На этапе 660 процессор 14 определяет, является ли достоверным элемент аутентификации (т.е. подпись), связанный с устройством 10 шлюза. В соответствии с иллюстративным вариантом осуществления процессор 14 выполняет этап 660 с помощью дешифрования элемента аутентификации (т.е. подписи) с использованием открытого ключа устройства 10 шлюза, хранимого в памяти 16, чтобы таким образом восстановить значение хэш-функции файла. Затем процессор 14 вычисляет свое собственное значение хэш-функции относительно файла (не включающего часть подписи). Процессор 14 не вычисляет свое собственное значение хэш-функции относительно части подписи, поскольку эта часть уже дешифрована, чтобы определить первое значение хэш-функции. Затем процессор 14 сравнивает два значения хэш-функций. Если два значения хэш-функций соответствуют, подпись считают достоверной. В противоположность, если два значения хэш-функций не соответствуют, подпись считают недостоверной. Важно заметить, что процесс аутентификации в настоящей заявке может быть выполнен независимо от элемента аутентификации и без изменения любого элемента аутентификации (т.е. подписи), который может быть включен в файл для использования с помощью клиентского устройства. Таким образом, защита и целостность элемента аутентификации клиентского устройства является неизменяемой, не воздействованной или не идентифицируемой с помощью операций устройства 10 шлюза.

В соответствии с иллюстративным вариантом осуществления загруженные файлы для устройства 10 шлюза включают в себя только один элемент аутентификации, в то время как загруженные файлы для клиентских устройств включают в себя два разных элемента аутентификации. На фиг. 7 иллюстративная структура 70 данных для загруженного файла для устройства 10 шлюза включает в себя подпись 72 шлюза, присоединенную к файлу 74 шлюза. Кроме того, иллюстративная структура 80 данных для загруженного файла для клиентского устройства включает в себя подпись 72 клиентского устройства, присоединенную к файлу 84 клиентского устройства, и дополнительно включает в себя подпись 72 шлюза, присоединенную к нему изготовителем устройства 10 шлюза или поставщиком услуг. Как описано выше, структуры данных, изображенные на фиг. 7, представляет структуры данных, используемые при загрузке файла шлюза и прилагаемой подписи шлюза. Принятый файл шлюза может содержать идентификацию для одного или более файлов клиентских устройств, которые на одном и том же этапе или на отдельных этапах загружают вместе с прилагаемыми подписями клиентских устройств и подписями шлюзов. Использование отдельного файла шлюза для идентификации файлов клиентских устройств может быть важным, например, когда множество производителей клиентских устройств предоставляют файлы клиентских устройств и подписи клиентских устройств.

В структуре 80 данных подпись 82 клиентского устройства и файл 84 клиентского устройства не изменяют, а обрабатывают как непрозрачный файл данных без каких-либо допущений, сделанных относительно его формата или содержания. Добавление подписи 72 шлюза к подписи 82 клиентского устройства и файлу 84 клиентского устройства представляет подпись-поверх, выполненную с помощью изготовителя устройства 10 шлюза или поставщика услуг. Эту подпись-поверх генерируют с использованием ключа подписи, выбранного для исключительного использования конкретным производителем устройства шлюза, и/или номера модели устройства шлюза. В соответствии с иллюстративным вариантом осуществления все файлы клиентских устройств, независимо от изготовителя или номера модели, снабжают подписью-поверх с использованием одного и того же ключа подписи шлюза. Когда устройство 10 шлюза принимает новый или обновленный файл клиентского устройства, оно проверяет его подпись-поверх с использованием ключа подписи шлюза (открытого ключа, если использована открытая/секретная криптографическая система) и/или программы проверки подписи шлюза. В соответствии с иллюстративным вариантом осуществления процессор 14 только определяет, является ли достоверной самая внешняя подпись, на этапе 660 на фиг. 6. То есть, процессор 14 только проверяет достоверность подписи 72 шлюза на этапе 660.

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

Возвращаясь к фиг. 6, если определение на этапе 660 является положительным, последовательность операций процесса продвигается на этап 670, где вновь загруженную версию файла сохраняют в энергонезависимой части памяти 16 под управлением процессора 14. Хранение вновь загруженной версии файла в энергонезависимой части памяти 16 предотвращает потенциальные проблемы защиты сети и устройства, например, вследствие неожиданного операционного прерывания, такого как выхода из строя питания. В соответствии с иллюстративным вариантом осуществления при хранении версии файла для клиентского устройства на этапе 670 устройство 10 шлюза отбрасывает байты подписи-поверх (т.е. подписи 72 шлюза), оставляя неповрежденной первоначальную подпись 82 клиентского устройства и файл 84 клиентского устройства. Устройство 10 шлюза хранит этот первоначально подписанный файл клиентского устройства в энергонезависимой части памяти 16 и может позже передать или загрузить его в одно или более клиентских устройств, например, после приема запроса перезагрузки/загрузки файла из клиентского устройства. Из этапа 670 последовательность операций процесса продвигается на этап 630, как описано ранее выше.

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

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

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

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

Изобретение относится к передаче данных, а именно, к способам предоставления данных в устройство шлюза в сети. Техническим результатом является повышение безопасности. Технический результат достигается тем, что заявленный способ предоставления данных в устройство шлюза в сети содержит этапы, на которых: принимают первый файл, первый элемент аутентификации и второй элемент аутентификации, причем упомянутый первый элемент аутентификации является уникальным для клиентского устройства, связанного с устройством шлюза (430, 650), определяют, является ли второй элемент аутентификации достоверным для упомянутого устройства шлюза (660), и сохраняют упомянутый первый элемент аутентификации и второй файл для упомянутого клиентского устройства, если упомянутый второй элемент аутентификации является достоверным для упомянутого устройства шлюза (670). 3 н. и 17 з.п. ф-лы, 7 ил.

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

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

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

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

5. Способ по п.1, в котором упомянутый первый элемент аутентификации и упомянутый второй элемент аутентификации присоединяют к упомянутому второму файлу.

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

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

8. Способ по п.1, в котором этап определения дополнительно включает в себя этапы, на которых:
определяют, включает ли в себя упомянутый первый файл по меньшей мере один элемент идентификации, совпадающий с по меньшей мере одним соответствующим элементом идентификации, связанным с упомянутым клиентским устройством (510, 520, 530), и идентифицируют упомянутый второй файл с использованием информации в упомянутом первом файле на основе упомянутого определения.

9. Способ по п.8, дополнительно содержащий этап, на котором принимают (650) упомянутый второй файл на основании упомянутой идентификации.

10. Устройство (10) шлюза, содержащее:
средство (12) для приема данных, включающих в себя первый файл, первый элемент (82) аутентификации и второй элемент (72) аутентификации, причем упомянутый первый файл связан со вторым файлом (84), причем упомянутый первый элемент (82) аутентификации является уникальным для клиентского устройства, связанного с упомянутым устройством (10) шлюза,
средство (14) для определения того, является ли упомянутый второй элемент аутентификации достоверным для упомянутого устройства (10) шлюза, и
средство (16) для предоставления (12) упомянутого первого элемента (82) аутентификации и упомянутого второго файла (84) в упомянутое клиентское устройство, если упомянутый второй элемент (72) аутентификации является достоверным для упомянутого устройства (10) шлюза.

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

12. Устройство (10) шлюза по п.10, в котором упомянутый первый элемент (82) аутентификации и упомянутый второй элемент (72) аутентификации присоединяются к упомянутому второму файлу (84).

13. Устройство (10) шлюза по п.10, в котором упомянутый второй элемент (72) аутентификации присоединяется к упомянутому второму файлу (84) и упомянутому первому элементу (82) аутентификации по меньшей мере одним из поставщика услуг и изготовителя упомянутого устройства (10) шлюза.

14. Устройство (10) шлюза по п.10, в котором упомянутое средство для определения, дополнительно включает в себя:
средство для определения того, включает ли в себя упомянутый первый файл по меньшей мере один элемент идентификации, совпадающий с по меньшей мере одним соответствующим элементом идентификации, связанным с упомянутым клиентским устройством (510, 520, 530), и
средство для идентификации упомянутого второго файла с использованием информации в упомянутом первом файле на основе упомянутого определения.

15. Устройство (10) шлюза, содержащее:
приемник (12), который принимает данные, причем упомянутые данные включают в себя первый элемент (82) аутентификации и второй элемент (72) аутентификации, причем упомянутый первый элемент (82) аутентификации является уникальным для клиентского устройства, связанного с упомянутым устройством (10) шлюза,
процессор (14), соединенный с упомянутым приемником (12), который определяет, является ли второй элемент аутентификации достоверным для упомянутого устройства (10) шлюза, и
память (16), соединенную с упомянутым процессором (14), которая сохраняет упомянутый первый элемент (82) аутентификации и часть упомянутых принятых данных для упомянутого клиентского устройства, если упомянутый второй элемент (72) аутентификации является достоверным для упомянутого устройства (10) шлюза.

16. Устройство (10) шлюза по п.15, дополнительно содержащее передатчик (12), соединенный с упомянутым процессором (14), который передает упомянутый первый элемент (82) аутентификации и упомянутую вторую часть упомянутых принятых данных (84) из упомянутого устройства (10) шлюза в упомянутое клиентское устройство.

17. Устройство (10) шлюза по п.15, в котором упомянутые данные дополнительно включают в себя первый файл, содержащий файл метаданных, и второй файл (84), который является исполняемым файлом.

18. Устройство (10) шлюза по п.17, в котором упомянутый первый элемент (82) аутентификации и упомянутый второй элемент (72) аутентификации присоединяются к упомянутому второму файлу (84).

19. Устройство (10) шлюза по п.18, в котором упомянутый второй элемент (72) аутентификации присоединяется к упомянутому второму файлу (84) и упомянутому первому элементу (82) аутентификации по меньшей мере одним из поставщика услуг и изготовителя упомянутого устройства (10) шлюза.

20. Устройство (10) шлюза по п.15, в котором упомянутый процессор (14) дополнительно определяет, включает ли в себя упомянутый первый файл по меньшей мере один элемент идентификации, совпадающий с по меньшей мере одним соответствующим элементом идентификации, связанным с упомянутым клиентским устройством, и идентифицирует упомянутый второй файл с использованием информации в упомянутом первом файле на основании упомянутого определения.