Настоящее изобретение относится к способам и устройству для обмена данными между пользовательским устройством, таким как приемник-декодер, и удаленным устройством, которым может быть, например, система ведения учетных записей для использования Интернет или провайдер Интернет-услуг.
Приемники-декодеры используются для приема и/или декодирования сигналов, таких как телевизионные сигналы, которые могут передаваться в аналоговой или цифровой форме. В случае цифровой передачи цифровые каналы кодируются в поток цифровых данных на стороне передатчика и декодируются на стороне приемника с помощью приемника-декодера, который может располагаться либо в цифровой приставке для телевизора (DSTB), либо в интегрированном телевизоре. В случае аналоговой передачи у подписчика может использоваться приемник-декодер для преобразования передаваемых сигналов в формат, который может быть отображен на экране телевизора.
Приемники-декодеры обычно имеют процессор, на котором могут выполняться программы, называемые приложениями. Примером приложения, которое может быть выполнено на приемнике-декодере, является приложение для доступа к Интернет, которое может обеспечивать подписчику доступ к Интернет с помощью данного приемника-декодера.
Для уменьшения себестоимости приемников-декодеров их конструкцию стремятся упростить. Из-за этого могут возникнуть трудности при необходимости использования приемника-декодера для обмена данными с удаленной сетью, такой как Интернет. В частности, подключение к Интернет требует использования межсетевых протоколов и аутентификации, что может быть труднореализуемо применительно к приемнику-декодеру. Например, некоторые приемники-декодеры могут быть не в состоянии выдавать данные в формате, пригодном для прямого соединения с Интернет. Такие приемники-декодеры именуются не являющимися "IP-поддерживающими".
Согласно первому аспекту настоящего изобретения предлагается способ аутентификации обмена данными между приемником-декодером и удаленным сервером для предоставления доступа к некоторой сети, включающий использование для аутентификации обмена данными некоторого идентификатора упомянутого приемника-декодера, причем упомянутый идентификатор основан на идентификаторе, используемом для доступа к вещательным сервисам.
Благодаря использованию настоящего изобретения аутентификация обмена данными между приемником-декодером и удаленным сервером может быть основана на использовании некоторого уникального идентификатора приемника-декодера, уже имеющегося у данного приемника-декодера, что может снизить требования к приемнику-декодеру. Приемники-декодеры часто снабжают уникальным идентификатором для доступа к вещательным сервисам, и такой идентификатор представляет собой удобное средство для идентификации данного приемника-декодера.
Предпочтительно упомянутый идентификатор хранится на съемном компоненте, таком как смарт-карта.
Предпочтительно упомянутый идентификатор независим от регистрационного идентификатора для входа в сеть (login). Благодаря этому приемник-декодер может быть упрощен, поскольку упомянутый идентификатор может быть проще, чем регистрационный идентификатор для входа в сеть, который обычно представляет собой сложный многосимвольный идентификатор, для облегчения его запоминания пользователем. Еще одним недостатком регистрационных идентификаторов является то, что они могут время от времени изменяться, либо для доступа к различным сервисам может требоваться более одного идентификатора; настоящее изобретение может обеспечить возможность соотнесения (в удаленном сервере) одного единственного идентификатора, передаваемого приемником-декодером, с идентификатором для сети, который может изменяться, или с несколькими идентификаторами для сети. Эта особенность настоящего изобретения может быть реализована независимо.
Предпочтительно упомянутый идентификатор основывается на некотором числе, уникальном для каждой смарт-карты. Термин "смарт-карта", как он используется в данном тексте, охватывает, но не ограничиваясь ими, любое карточное устройство на основе микросхемы, или предмет с аналогичными назначением и рабочими характеристиками, снабженный, например, микропроцессором и/или запоминающим устройством. Этим термином также охвачены устройства, имеющие отличную от карты физическую форму, например устройства в форме ключа, подобные тем, что часто применяются в телевизионных системах, использующих декодеры.
Упомянутый удаленный сервер может быть сервером для доступа к Интернет, или он может быть системой ведения учетных записей для использования Интернет, либо сервером любого другого типа, например, для доступа к удаленной сети любого типа.
Используя упомянутый идентификатор приемника-декодера, система ведения учетных записей для использования Интернет может создавать для пользователя учетную запись для использования Интернет. Для создания учетной записи упомянутый идентификатор может сравниваться системой ведения учетных записей для использования Интернет с сохраненным перечнем идентификаторов приемников-декодеров, которые могут создавать учетные записи для использования Интернет.
Упомянутый удаленный сервер может содержать средство для передачи данных провайдеру Интернет-услуг, а предлагаемый способ включать операции предоставления данных упомянутой учетной записи для использования Интернет провайдеру Интернет-услуг, для организации между приемником-декодером и провайдером Интернет-услуг двунаправленного канала передачи данных.
Упомянутый идентификатор может сопровождаться данными, идентифицирующими канал передачи данных, который должен применяться для передачи данных между приемником-декодером и удаленным сервером. Таким образом, приемник-декодер может задавать канал передачи данных, который должен применяться для передачи данных; например, в качестве обратного канала может использоваться спутниковый канал.
В одном предпочтительном варианте осуществления настоящего изобретения регистрационные данные (login) имеют следующую форму:
login={номер смарт-карты} {тип сервисов},
где "тип сервисов" (type of services - TOS) может определять каналы, по которым должна происходить передача данных, например, указывая на случай, когда ответы некоторого типа на абонентский терминал должен передавать спутник.
В одном предпочтительном варианте осуществления настоящего изобретения упомянутый удаленный сервер предоставляет приемнику-декодеру доступ к сети, имеющей некоторые сетевые протоколы, и данные, выдаваемые приемником-декодером, преобразуются в данные, совместимые с упомянутыми сетевыми протоколами, в некотором месте, удаленном от данного приемника-декодера. Таким образом, приемник-декодер, который не снабжен упомянутыми сетевыми протоколами, может, тем не менее, обмениваться данными с упомянутой сетью. Упомянутый сетью может быть, например, Интернет, а сетевым протоколом может быть, например, TCP/IP. Упомянутое удаленное место может, например, располагаться у оператора, который может иметь систему ведения учетных записей для использования Интернет.
Предпочтительно упомянутые данные преобразуются в упомянутые совместимые с сетевыми протоколами данные шлюзом, расположенным между упомянутыми приемником-декодером и удаленным сервером.
В одном предпочтительном варианте осуществления настоящего изобретения упомянутая сеть включает в себя множество удаленных устройств, и упомянутые преобразованные данные передаются упомянутым шлюзом в одно из упомянутых удаленных устройств, указанное в упомянутых данных, организовывая таким образом канал передачи данных между приемником-декодером и указанным удаленным устройством.
Согласно второму аспекту настоящего изобретения предлагается способ передачи данных из поддерживающего немежсетевой протокол пользовательского терминала в одно из множества поддерживающих межсетевой протокол удаленных устройств, включающий операции передачи данных с использованием упомянутого немежсетевого протокола из упомянутого пользовательского терминала в шлюз, причем упомянутые данные включают в себя некоторое сообщение и указывают адресат этого сообщения из числа упомянутого множества удаленных устройств, преобразования упомянутых данных в упомянутом шлюзе в данные, использующие упомянутый межсетевой протокол, и передачи упомянутых данных, использующих упомянутый межсетевой протокол, из упомянутого шлюза в указанное удаленное устройство-адресат, организовывая таким образом канал передачи данных между упомянутым пользовательским терминалом и указанным удаленным устройством. Упомянутый пользовательский терминал может быть приемником-декодером.
Предлагается также способ обмена данными между приемником-декодером и удаленной сетью, в котором протоколы, необходимые для обмена данными с упомянутой удаленной сетью, реализуются в некотором удаленном от приемника-декодера месте.
Из приемника-декодера в шлюз с использованием упомянутого немежсетевого протокола может быть передано некоторое сообщение, инициирующее закрытие упомянутого канала передачи данных, и упомянутый шлюз, в свою очередь, передает в указанное удаленное устройство команду закрытия, используя упомянутый межсетевой протокол. Предпочтительно перед организацией упомянутого канала передачи данных шлюз осуществляет аутентификацию идентификационных данных приемника-декодера.
Согласно третьему аспекту настоящего изобретения предлагается устройство для аутентификации обмена данными между приемником-декодером и удаленным сервером для предоставления доступа к некоторой сети, содержащее средство (например, систему, сервер или шлюз) для использования для аутентификации обмена данными некоторого идентификатора упомянутого приемника-декодера, причем упомянутый идентификатор основан на идентификаторе, используемом для доступа к вещательным сервисам. Упомянутый идентификатор может сопровождаться данными, идентифицирующими канал передачи данных, который должен применяться для передачи данных между приемником-декодером и удаленным сервером.
Упомянутый удаленный сервер может предоставлять приемнику-декодеру доступ к сети, имеющей некоторые сетевые протоколы, при этом предлагаемое устройство может содержать средство (например, систему, сервер или шлюз) для преобразования данных, выдаваемых приемником-декодером, в данные, совместимые с упомянутыми сетевыми протоколами.
Предпочтительно предлагаемое устройство является шлюзом, расположенным между упомянутыми приемником-декодером и удаленным сервером.
Предпочтительно упомянутая сеть включает в себя множество удаленных устройств, и упомянутый шлюз выполнен с возможностью передачи упомянутых преобразованных данных в одно из упомянутого множества удаленных устройств, указанное в упомянутых данных, организовывая таким образом канал передачи данных между приемником-декодером и указанным удаленным устройством.
Согласно четвертому аспекту настоящего изобретения предлагается шлюз для передачи данных, полученных от поддерживающего немежсетевой протокол пользовательского терминала, в одно из множества поддерживающих межсетевой протокол удаленных устройств, содержащий
средство (например, вход) для приема переданных из упомянутого пользовательского терминала с использованием упомянутого немежсетевого протокола данных, включающих в себя некоторое сообщение и указывающих адресат этого сообщения из числа упомянутого множества удаленных устройств;
средство (например, преобразователь) для преобразования принятых данных в данные, использующие упомянутый межсетевой протокол; и
средство (например, выход) для передачи упомянутых данных, использующих упомянутый межсетевой протокол, в указанное удаленное устройство-адресат, организовывая таким образом канал передачи данных между упомянутым пользовательским терминалом и указанным удаленным устройством.
Предлагаемый шлюз может иметь множество портов ввода-вывода, каждый из которых предназначается для соединения с соответствующим удаленным устройством.
Предлагаемый шлюз может содержать средство (например, устройство распознавания) для распознавания некоторого сообщения из пользовательского терминала, инициирующего закрытие упомянутого канала передачи данных; и средство (например, выход) для передачи команды закрытия в указанное удаленное устройство.
Согласно настоящему изобретению предлагается также способ и устройство, по существу как они описаны со ссылками на фигуры чертежей и иллюстрируются ими.
Признаки одного аспекта могут быть применены к другим аспектам; аналогичным образом признаки способов могут применяться к аспектам, касающимся устройств, и наоборот.
Ниже будут описаны предпочтительные особенности настоящего изобретения, исключительно в качестве примера и со ссылками на фигуры чертежей, на которых:
фиг.1 - архитектура типичной системы цифрового телевидения;
фиг.2 - схематическое изображение приемника-декодера;
фиг.3 - система доступа к Интернет в общем виде;
фиг.4 - программные уровни оборудования пользователя, показанного на фиг.3;
фиг.5 - архитектура системы доступа к Интернет; и
фиг.6 - основные элементы системы ведения учетных записей для использования Интернет;
фиг.7 - часть конфигурации системы доступа к Интернет в случае, когда приемник-декодер не является IP-поддерживающим;
фиг.8 - протокольные уровни системы, показанной на фиг.7;
фиг.9 схематически иллюстрирует протокол, используемый для обмена данными между оборудованием пользователя и шлюзом в системе, показанной на фиг.7; и
фиг.10 схематически иллюстрирует протокол, используемый для обмена данными между оборудованием пользователя и шлюзом в системе, показанной на фиг.7, при осуществлении аутентификации.
На фиг.1 показана система 1 цифрового телевидения в общем виде. В настоящем изобретении используется в основном обычная система 2 цифрового телевидения, в которой для передачи сжатых цифровых сигналов применяется система сжатия MPEG-2. Конкретнее, MPEG-2 компрессор 3 в центре вещания принимает поток цифровых сигналов (обычно поток видеосигналов). Компрессор 3 подключен к мультиплексору-скремблеру 4 посредством соединения 5.
Мультиплексор 4 получает множество дополнительных входных сигналов, компонует транспортный поток и передает сжатые цифровые сигналы в передатчик 6 центра вещания посредством соединения 7, которое, разумеется, может принимать широкое разнообразие форм, включая телекоммуникационные каналы связи. Передатчик 6 передает электромагнитные сигналы по каналу 8 "Земля-спутник" на спутниковый транспондер 9, где они подвергаются обработке электронными средствами; оттуда они передаются путем вещания по виртуальному каналу 10 "спутник-Земля" в наземный приемник 12, обычно в форме тарелки, принадлежащий или арендуемый конечным пользователем. Возможны, разумеется, и другие транспортные каналы для передачи данных, такие как сети наземного вещания, каналы кабельной передачи, комбинированные кабельно-спутниковые соединения, телефонные сети и т.п.
Сигналы, принимаемые приемником 12, передаются в совмещенный приемник-декодер 13, принадлежащий или арендуемый конечным пользователем и подключенный к телевизору 14 конечного пользователя. Приемник-декодер 13 декодирует сжатый MPEG-2 сигнал в телевизионный сигнал для телевизора 14. Хотя на фиг.1 приемник-декодер показан как отдельный блок, он в равной степени может входить в состав интегрированного цифрового телевизора. Термин "приемник-декодер", как он используется в данном тексте, охватывает как отдельный приемник-декодер, такой как приставка для телевизора (STB), так и телевизор со встроенным в него приемником-декодером.
В многоканальной системе мультиплексор 4 обрабатывает звуковую и видеоинформацию, получаемую из нескольких параллельных источников, и взаимодействует с передатчиком 6 для вещания этой информации по соответствующему количеству каналов. Дополнительно к аудиовизуальной информации в некоторые или во все эти каналы могут вводиться сообщения, или приложения, или цифровые данные любого другого рода, перемежаемые с передаваемой цифровой звуковой и видеоинформацией.
К мультиплексору 4 и приемнику-декодеру 13 подключена система 15 условного доступа, размещенная частично в центре вещания и частично в декодере. Она позволяет конечному пользователю получать доступ к передачам цифрового телевидения одного или нескольких провайдеров вещания. В приемник-декодер 13 может устанавливаться смарт-карта, способная дешифрировать сообщения, относящиеся к коммерческим предложениям (т.е. к одной или нескольким телевизионным программам, продаваемым провайдером вещания). С помощью декодера 13 и смарт-карты конечный пользователь может покупать коммерческие предложения либо в режиме подписки, либо в режиме оплаты за отдельный просмотр (PPV-режим).
Как упоминалось выше, передаваемые системой программы скремблируются мультиплексором 4, причем параметры и ключи шифрования, применяемые к данной конкретной передаче, определяются системой 15 условного доступа. Передача скремблированных данных этим способом хорошо известна в области систем платного телевидения. Обычно скремблированные данные передаются вместе с управляющим словом, предназначенным для дескремблирования этих данных, причем само управляющее слово зашифровывается с помощью так называемого рабочего ключа и передается в зашифрованной форме.
Упомянутые скремблированные данные и зашифрованное управляющее слово затем принимаются декодером 13, имеющим доступ к эквиваленту упомянутого рабочего ключа, сохраненному на смарт-карте, установленной в декодер, чтобы дешифрировать зашифрованное управляющее слово и после этого дескремблировать переданные данные. Оплативший подписку абонент получит, например, в переданном на данный месяц EMM (сообщении управления предоставлением прав, или сообщении управления доступом), рабочий ключ, необходимый для дешифрирования зашифрованного управляющего слова, что, в свою очередь, необходимо для просмотра передачи.
Интерактивная система 16, также подключенная к мультиплексору 4 и приемнику-декодеру 13 и также размещенная частично в центре вещания и частично в декодере, позволяет конечному пользователю взаимодействовать в интерактивном режиме с различными приложениями через модемный обратный канал 17. Этот модемный обратный канал может также использоваться для обмена сообщениями с системой 15 условного доступа.
Для загрузки данных используются физические интерфейсы приемника-декодера 13. Как показано на фиг.2, приемник-декодер 13 содержит, например, шесть устройств для загрузки данных: последовательный интерфейс 30, параллельный интерфейс 32, модем 34, два устройства 36 считывания карт и тюнер 38 MPEG-потока.
Рассматриваемая система вещания и приема используется также для предоставления Интернет-сервисов, таких как просмотр Web-страниц (Web-browsing) и электронная почта. Выполняемое приемником-декодером 13 приложение позволяет приемнику-декодеру получать доступ к Интернет-сервисам и отображать Web-страницы и e-mail-сообщения либо на телевизоре 14, либо через компьютер, подключенный к приемнику-декодеру 13.
Со ссылками на фиг.3 ниже будет в общем виде описана система доступа к Интернет. Оборудование 20 пользователя (в которое входит приемник-декодер) связано с оператором 22 посредством телефонной коммутируемой сети 24 общего пользования (PSTN). Оборудование пользователя передает оператору 22 запрос на передачу в него конкретных данных, например, определенной Web-страницы или электронной почты. Оператор принимает этот запрос и передает его Интернет-провайдеру (ISP) 26. В ответ на этот запрос ISP предоставляет оператору ответ, который может содержать в себе запрошенную Web-страницу, полученную из Интернет 27, или e-mail-сообщение, имеющееся для этого подписчика у ISP. Оператор передает этот ответ в центр 28 вещания, где оно вводится в битовый MPEG-поток, например, в виде приватной секции, передается передатчиком 6 и принимается приемником 12, как было описано выше. В том случае, когда приемник-декодер является "IP-поддерживающим", т.е. снабжен протоколами для приема данных из Интернет, информация может передаваться как IP-кадр битового потока MPEG, т.е. в IP-формате. Если же приемник-декодер не является "IP-поддерживающим", тогда данные передаются каким-нибудь другим способом, например как приватная MPEG-секция. Оборудование 20 пользователя извлекает этот ответ из битового MPEG-потока и отображает его на телевизоре или подключенном к компьютеру мониторе. В качестве альтернативного варианта этот ответ может передаваться в оборудование 20 пользователя через PSTN 24.
На фиг.4 показаны программные уровни оборудования 20 пользователя. Уровень приложений содержит Web-браузер и приложение для работы с электронной почтой (почтовую программу), в качестве которых могут использоваться стандартные приложения, такие как Netscape или Microsoft Internet Explorer и Outlook Express, либо какое-либо приложение, специально разработанное для выполнения на приемнике-декодере. Под уровнем приложений расположены HTTP-уровень, уровень сокетов, TCP/IP-уровень, PPP/SLIP-уровень и уровень драйверов. Уровень драйверов модифицирован, отличаясь от браузера, обычным образом выполняемого на ПК, тем, что он разделен на драйвер модема для связи с PSTN 24 посредством модема пользовательского оборудования, и драйвер тюнера для обмена данными посредством тюнера 4028 для приема MPEG-потока.
Возможно использование оборудования 20 пользователя различных конфигураций. В одной из конфигураций ПК не используется, и все программное обеспечение пользователя выполняется на приемнике-декодере 13. В этой конфигурации приемник-декодер 13 связывается с PSTN 24 либо посредством внутреннего модема, либо с помощью внешнего модема и последовательного порта. Приемник-декодер 13 может принимать Интернет-ответы в битовом потоке, получаемом от наземного приемника 12. Пользовательский интерфейс (для взаимодействия пользователя и системы) обеспечивается пультом дистанционного управления или клавиатурой, а также телевизором, подключенным к приемнику-декодеру 13. В этой конфигурации TCP/IP-уровень, показанный на фиг.4, может отсутствовать, и в этом случае необходимые протоколы реализуются шлюзом, размещенным у оператора, как будет описано ниже.
В другой конфигурации предусматривается персональный компьютер (ПК), параллельный порт которого соединен с параллельным портом 32 приемника-декодера 13 (либо, в качестве варианта, последовательный порт которого соединен с последовательным портом 30 приемника-декодера 13). В этом случае верхние программные уровни, показанные на фиг.4, выполняются на ПК, а оставшиеся нижние программные уровни выполняются на приемнике-декодере 13. Пользовательский интерфейс обеспечивается клавиатурой и монитором, подключенными к ПК.
В еще одной конфигурации ПК подключен к PSTN 24 посредством своего внутреннего или внешнего модема. В этой конфигурации приемник-декодер 13 может иметь вид отдельного устройства, или может быть представлен платой расширения или съемной платой для ПК, подключенной к его шине ISA или PCI.
На фиг.5 представлена архитектура системы доступа к Интернет. Как показано на фиг.5, система ведения учетных записей для использования Интернет (IAMS - Internet account management system) 50 соединена с Интернет-провайдером (ISP) 26, предоставляющим такие сервисы, как просмотр Web-страниц и электронная почта. IAMS 50 также соединена с системой управления подписчиками (SMS) 60, управляющей подписчиками и передающей в IAMS запросы на предоставление или запрещение доступа к Интернет-сервисам. Приемник-декодер 13 соединен с IAMS посредством внутреннего модема, телефонной коммутируемой сети общего пользования (PSTN) 24, сервера 56 доступа к сети (NAS) и шлюза 58.
SMS также соединена с системой санкционирования подписчиков (SAS) 61, выдающей разрешения и обрабатывающей заказы подписчиков на вещательные сервисы, такие как вещательные телевизионные сервисы. SMS параллельно работает с системами SAS и IAMS и обеспечивает согласованность этих двух систем. Обмен информацией между SMS и SAS и SMS и IAMS осуществляется с помощью TCP/IP-соединений реального времени, с использованием командных файлов.
Шлюз 58 позволяет пользователям получать доступ к Интернет-сервисам в реальном масштабе времени. К таким сервисам относятся почтовые сервисы, для отправки и получения почты и другие сервисы, которые могут предоставляться ISP 26, а также сервис поддержки пользователя и сервис напоминаний, предоставляемые системой IAMS. С точки зрения его функций, шлюз 58 является маршрутизатором сообщений, делая возможным обмен данными с различными системами, используя одно единственное модемное соединение. В тех случаях, когда приемник-декодер не снабжен протоколами TCP/IP для связи с ISP, этот шлюз также реализует протоколы, необходимые приемнику-декодеру для обмена данными с ISP. В этом случае приемник-декодер 13 связывается с ISP через шлюз 58, как показано линией 59 на фиг.5. Если же приемник-декодер снабжен необходимыми протоколами, связь с ISP осуществляется напрямую, как показано на фиг.5 пунктирной линией 57. Шлюз включает в себя сервер связи и диспетчер электронной почты (e-mail dispatcher).
Интерфейс 66 ISP позволяет дублировать (копировать) каждое изменение в учетной записи пользователя, которое происходит в IAMS, в учетной записи пользователя у ISP 26, отвечающего за хостинг Интернет-сервисов, таких как почтовый сервис. Следует отметить, что вся информация, имеющая отношение к учетным записям подписчиков для использования Интернет, централизована в IAMS, которая отвечает за управление ТВ- и Интернет-параметрами. IAMS также управляет связью между Интернет-параметрами и ТВ-параметрами, взаимодействуя с системой управления подписчиками (SMS) 60. SMS 60 управляет правами подписчиков и передает в IAMS запросы, запрашивающие предоставление подписчикам прав на доступ либо отказ подписчикам в доступе к Интернет-сервисам.
Для того чтобы создать учетную запись в системе IAMS, сначала подписчик из приемника-декодера 13 передает в IAMS 50 запрос на новую учетную запись, вместе с такой информацией, как запрашиваемый e-mail-адрес и выбранные параметры настройки. IAMS проверяет, есть ли данный номер смарт-карты в перечне номеров смарт-карт, полученном из системы управления подписчиками (SMS) 60, соответствующем подписчикам, для которых могут быть открыты учетные записи для использования Интернет. Затем IAMS передает в ISP запрос на создание учетной записи для использования Интернет. После создания учетной записи ISP возвращает в IAMS соответствующее подтверждение, а также пароль. Изначально пароль определен SMS, но позднее он может быть изменен подписчиком. Данные учетной записи IAMS (пароль, e-mail-адрес и Интернет-параметры) сохраняются в IAMS вместе с номером смарт-карты данного подписчика. IAMS информирует подписчика о том, что для него создана учетная запись. После этого подписчик может передавать почту на почтовый сервер 28 и принимать почту от него.
На фиг.6 показаны основные элементы IAMS. Основными функциями IAMS являются следующие:
- ведение и поддержка централизованного перечня параметров почтовых учетных записей, привязанных к параметрам подписчиков, таким как номер смарт-карты;
- предоставление прав на доступ или отказ в доступе к Интернет-сервисам для подписчика по запросу SMS;
- настройка учетных записей для использования Интернет по запросу подписчиков (поддержка подписчиков);
- сервис напоминаний, в рамках которого пользователь электронной почты может записать (наметить) какое-либо событие и получить напоминание о нем посредством e-mail-сообщения в момент наступления этого события;
- сервис копирования, позволяющий копировать обновленное содержимое IAMS в соответствующий сервер, такой как ISP.
В центре IAMS находится система управления реляционной базой данных (RDBMS) 70, содержащая информацию о подписке на Интернет-сервисы и почтовые учетные записи, сохраненные в устройстве 72 хранения данных. Интерфейс 74 для обмена данными с SMS обеспечивает возможность передачи информации между IAMS и SMS, так что IAMS может снабжаться свежими сведениями о подписчиках, которым был предоставлен доступ к почтовым сервисам, или которым было отказано в таком доступе. Сервер 76 поддержки позволяет подписчику работать со своей почтовой учетной записью и изменять ее в соответствии со своими предпочтениями. Сервер 78 напоминаний предоставляет подписчику возможность работать с перечнем событий. Событие привязывается к почтовой учетной записи подписчика. Подписчик может записать какое-нибудь событие и получить автоматическое напоминание за некоторое предварительно заданное количество дней до наступления этого события посредством автоматически сгенерированного е-mail-сообщения. Интерфейс 84 для обмена данными с системой уведомления о поступлении электронной почты обеспечивает системе уведомления о поступлении электронной почты (EMNS) 62 возможность находить пользовательские настройки, имеющие отношение к уведомлению пользователя, в RDBMS 70 системы IAMS, для передачи уведомляющего сообщения через спутник (ОТА). Вспомогательный сервер 80 позволяет администратору проверять наличие и статус подписчика или пользователя электронной почты в IAMS. Сервер 82 копирования копирует обновленное содержимое RDBMS 70 системы IAMS в систему ведения учетных записей провайдера Интернет-услуг.
Запросы, передаваемые в IAMS из приемника-декодера 13, направляются шлюзом 58 в соответствующую часть IAMS, такую как сервер поддержки (для работы с почтовыми учетными записями) и сервер напоминаний (для работы с напоминаниями).
Описанная выше система доступа к Интернет позволяет провайдерам вещательных сервисов предоставлять также и Интернет-сервисы. Оператор такой системы ведет и поддерживает учетные записи для использования Интернет независимо от провайдеров Интернет-услуг, так что он не привязан к какому-либо конкретному провайдеру Интернет-услуг. Путем связывания подписок на вещательные сервисы и подписок на Интернет-сервисы друг с другом можно совместить обработку учетных записей для сервисов этих двух видов и управление ими, что может сократить объем необходимых вычислений по сравнению со случаем, когда учетные записи ведутся раздельно, при этом подписчику могут выставляться объединенные счета на эти две услуги.
Более подробно система IAMS описана в параллельно рассматриваемой заявке, озаглавленной "Internet Subscriber Management " и поданной на имя заявителя настоящей заявки, содержимое которой включено в настоящую заявку посредством ссылки. Система уведомления о поступлении электронной почты более подробно описана в параллельно рассматриваемой заявке, озаглавленной "Method and Apparatus for use with E-mail" и поданной на имя заявителя настоящей заявки, содержимое которой включено в настоящую заявку посредством ссылки.
Ниже со ссылками на фиг.7-10 будет описана конфигурация системы доступа к Интернет для случая, когда приемник-декодер не поддерживает межсетевого протокола. Обратимся к фиг.7, где показана часть системы, изображенной целиком на фиг.5, с детализацией некоторых ее аспектов; приемник-декодер 13 - это приемник упомянутого выше типа, т.е. не снабженный протоколом TCP/IP, необходимым для прямой связи с ISP 26. Соответственно обмен данными осуществляется через шлюз 58 для цифровой приставки для телевизора (DSTB). Сервер 76 поддержки и сервер 78 напоминаний показаны на данной фигуре как отдельные элементы IAMS 50, и в этом варианте осуществления данные направляются в каждый из них по линии связи 76а или 78а соответственно.
При любом обмене данными между приемником-декодером 13 и любым удаленным сервером, к которому требуется получить доступ, практический интерес представляют четыре подсистемы. Это сам приемник-декодер 13, NAS 56, шлюз 58 и удаленный сервер, который в данном варианте осуществления может быть либо сервером 76 поддержки, либо сервером 78 напоминаний, либо почтовым сервером 64. PSTN 24 фактически прозрачна для данных. В данном варианте осуществления доступ к почтовому серверу 64 осуществляется через интерфейс 66 и ISP 26, но это вовсе не обязательно, и доступ к почтовому серверу 64 может осуществляться и непосредственно через шлюз 58. Более того, хотя он и показан на фигуре одним блоком, почтовый сервер 64 может состоять из двух отдельных блоков: первый - для передачи электронной почты (это может быть, например, SMTP-сервер), и второй - для получения электронной почты (это может быть, например, IMAP-сервер). В подобной конфигурации шлюз 58 может обмениваться данными с этими двумя блоками, образующими почтовый сервер, через два отдельных порта.
Опишем со ссылками на фиг.8 различные протокольные уровни, с которыми работает каждая из описанных выше четырех подсистем. Как явствует из фиг.8, приемник-декодер 13 имеет четыре следующих протокольных уровня (начиная с наивысшего): протокол уровня приложения (который будет зависеть от приложения), который может быть, например, протоколом SMTP, IMAP или им подобным; протокол шлюза (уровень, используемый для обмена данными между приемником-декодером и шлюзом, более подробно описанный ниже); протокол РР4 и уровень модема, такой как v22 или v42bis. Использование двух последних уровней хорошо известна специалистам.
NAS 56 имеет один протокольный уровень и используется для преобразования уровня модема (используемого для связи с PSTN 24) в межсетевой протокол TCP/IP.
Шлюз 58 имеет три рабочих протокольных уровня (начиная с наивысшего): уровень протокола шлюза, уровень протокола РР4 и TCP/IP.
Наконец, удаленный сервер обычно будет иметь два протокольных уровня: верхний уровень - протокол уровня приложения, и нижний уровень - TCP/IP.
Таким образом, протокол шлюза обеспечивает шлюзу 58 возможность отвечать на сообщения и в соответствующих случаях идентифицировать получателя данных, которому они предназначаются, и передавать эти данные этому получателю. Этот протокол также обеспечивает приемнику-декодеру 13 возможность инициировать различные операции между шлюзом 58 и удаленным сервером. В рассматриваемом варианте осуществления шлюз 58 отвечает за направление SMTP- или IMAP-данных в почтовый сервер 64; направление в сервер 76 поддержки данных, которые могут включать в себя запросы на создание новых учетных записей; направление в сервер 78 напоминаний данных, которые могут включать в себя запросы на запись новых событий; составление сообщений, которые должны быть переданы в приемник-декодер 13, на основе данных, полученных от любого из упомянутых серверов: почтового сервера 64, сервера 76 поддержки, или сервера 78 напоминаний, и обеспечение передачи таких сообщений. Кроме того, упомянутый шлюз способен осуществлять аутентификацию приемника-декодера.
Опишем обмен данными между приемником-декодером 13 и шлюзом 58 на низком уровне. На первом этапе между приемником-декодером 13 и NAS 56 устанавливается модемное соединение через PSTN 24. Может использоваться любой подходящий модемный стандарт, например v22 или v42bis. На этом этапе между приемником-декодером 13 и NAS 56 на уровне модема осуществляется процедура установления соединения для организации канала передачи данных. После этого NAS 56 организовывает канал передачи данных со шлюзом 58 на уровне протокола TCP. После этого шлюз 58 передает в приемник-декодер 13 маркер, представляющий собой некоторую предварительно заданную последовательность символов. Прием такого маркера приемником-декодером 13 извещает его о наличии шлюза 58; таким образом, между приемником-декодером 13 и шлюзом 58 организовывается канал передачи данных на уровне протокола шлюза.
Фактически, организованный на уровне протокола шлюза канал передачи данных находится под управлением приемника-декодера 13. Именно приемник-декодер должен запросить канал, прежде чем сможет осуществляться обмен сообщениями. Кроме того, инициируемая для закрытия этого канала процедура разъединения (описанная ниже) инициируется приемником-декодером 13.
Следует отметить, что в рассматриваемом варианте осуществления протокол шлюза позволяет организовать один-единственный ТСР-канал с соответствующим удаленным сервером. Другими словами, в этом варианте осуществления в каждый конкретный момент времени приемник-декодер 13 не может быть соединен одновременно с более чем одним удаленным сервером. Однако приемник-декодер 13 может устанавливать и разрывать соединение с различными удаленными серверами без необходимости всякий раз заново организовывать канал передачи данных между собой и шлюзом 58.
Следует отметить также, что в рассматриваемом варианте осуществления уровень протокола шлюза не осуществляет никаких действий, направленных на исправление ошибок, - протоколы более низких уровней (модема и TCP) обеспечивают транспортировку данных, а протоколы более высоких уровней (протоколы приложения) обеспечивают работу с ошибками.
Опишем общую структуру сообщений при обмене данными по протоколу шлюза. Структура каждого сообщения предусматривает следующие поля:
{версия протокола} {идентификатор команды} {длина данных} [параметры],
где в фигурных скобках указаны обязательные поля, а в квадратных скобках - необязательные.
Структура сообщения является одинаковой, независимо от того, исходит ли сообщение из приемника-декодера 13 или шлюза 58. Поля содержат двоичный код, старшие разряды расположены первыми.
Поле "версия протокола" (PRT) содержит один байт, указывающий версию протокола.
Поле "идентификатор команды" (CI) содержит два байта и указывает тип данного сообщения. Различные типы сообщений станут понятными из приведенных ниже описаний событий обмена данными.
Поле "длина данных" (DL) имеет длину два байта и указывает общую длину присоединенного к сообщению поля параметров (если таковое имеется). Благодаря этому поле параметров может иметь переменную длину. При отсутствии присоединенных полей параметров это поле содержит нулевое значение.
Поле параметров кодируется в формате "тип-длина-значение" (Type Length Value - TLV) и содержит любые необходимые параметры, используемые с данным сообщением. Существуют три категории параметров, которые могут использоваться как отдельно, так и в сочетании друг с другом, в зависимости от типа сообщения. Другими словами, тип сообщения определяет наличие того или иного поля параметров. Понятно, что некоторые сообщения (например, сообщение-команда инициализации соединения (MG_RCNX)) могут использоваться без каких-либо параметров.
Первый тип параметра (УДАЛЕННЫЙ_СЕРВЕР) используется для идентификации удаленного сервера и содержит некоторое целое число, указывающее на то, является ли идентифицируемый сервер STMP частью почтового сервера 64, IMAP частью почтового сервера 64, сервером 76 поддержки или сервером 78 напоминаний. В рассматриваемом варианте осуществления длина этого параметра составляет два байта. Возможны модификации, в которых этот параметр может использоваться для идентификации других или дополнительных серверов.
Второй тип параметра (БЛОК_ДАННЫХ) используется для размещения данных, полученных из соответствующего удаленного сервера, или данных, которые подлежат передаче в него. Этот параметр имеет переменную длину, определяемую полем "длина данных", и это означает, что пакетам данных не нужно иметь предварительно заданную длину. Предварительно заданной является лишь максимальная длина этого параметра.
Третий типа параметра (КОД_ОШИБКИ) используется для обозначения состояния ошибки. Он может использоваться, например, для указания на то, что шлюз не в состоянии установить соединение с указанным удаленным сервером, что соединение с удаленным сервером оборвалось, что в полученном из приемника-декодера 13 сообщении обнаружена ошибка, что после команды из приемника-декодера 13 из удаленного сервера не было получено никаких данных, или что аутентификации завершилась с отрицательным результатом. В рассматриваемом варианте осуществления длина этого параметра составляет два байта.
В модификации рассматриваемого варианта осуществления может применяться четвертый тип параметра, содержащий информацию, используемую для аутентификации.
Ниже со ссылками на фиг.9 будет описана типичная последовательность операций обмена данными, характерная для обычного обмена данными по каналу передачи данных уровня протокола шлюза. На нем схематически представлены сообщения, передаваемые между приемником-декодером 13 и шлюзом 58, вместе с соответствующими событиями, происходящими между шлюзом 58 и выбранным удаленным сервером, в течение некоторого промежутка времени (время увеличивается по направлению к низу страницы).
Первой показанной последовательностью событий (е1) является процедура соединения приемника-декодера с указанным удаленным сервером на уровне протокола шлюза. Приемник-декодер 13 передает запрашивающее соединение сообщение 1000 (MG_CNX), содержащее два параметра, - параметр "УДАЛЕННЫЙ_СЕРВЕР", указывающий сервер, с которым он желает осуществлять обмен данными, и параметр "БЛОК_ДАННЫХ", содержащий данные, предназначенные для указанного удаленного сервера (если таковые имеются). Этим инициируется выполнение шлюзом двух операций, вместе обозначенных на данной фигуре стрелкой 1001, а именно установление соединения с указанным сервером через соответствующую линию связи и передача по этой линии связи в указанный сервер упомянутых данных (если таковые имеются), содержащихся в параметре "БЛОК_ДАННЫХ" этого сообщения.
После описанной выше последовательности операций удаленный сервер передает данные 1002 в шлюз 58 для последующей пересылки в приемник-декодер 13. Шлюз кодирует их в сообщение "обмен данными с удаленным сервером" 1003 (MG_REMOTE), имеющее одно поле параметров, а именно поле "БЛОК_ДАННЫХ", которое содержит упомянутые данные, и передает это сообщение в приемник-декодер 13. Таким образом устанавливается соединение.
Вторая показанная последовательность событий (е2) является типичной последовательностью операцией обмена данными. Эта последовательность начинается с передачи приемником-декодером 13 сообщения "обмен данными с удаленным сервером" (MG_OTHER), содержащего в поле "БЛОК_ДАННЫХ" данные, предназначаемые для данного сервера. Как станет понятно, в каждый момент времени приемник-декодер 13 обменивается данными только с одним удаленным сервером и, следовательно, поскольку этот сервер уже определен в устанавливающем соединение сообщении (е2), его уже не требуется указывать во время обычного обмена данными. Прием этого сообщения 1004 обмена данными шлюзом 58 инициирует передачу шлюзом содержащихся в сообщении данных в упомянутый удаленный сервер, что обозначено стрелкой 1005.
После этого упомянутый удаленный сервер может передавать данные в приемник-декодер (обозначено позициями 1006, 1007), как было описано выше.
Опишем со ссылками на обмен данными, обозначенный позициями 1008а, 1008Ь и 1009, еще одну особенность рассматриваемого варианта осуществления настоящего изобретения. Упомянутое сообщение "обмен данными с удаленным сервером" (MG_REMOTE), которое передавалось из шлюза 58 в приемник-декодер 13, включает в себя минимальный размер пакета данных. Поэтому шлюз 58 не будет передавать сообщения в приемник-декодер 13 до тех пор, пока из упомянутого удаленного сервера не будет получено некоторое предварительно заданное минимальное количество данных (фактически - пороговое значение) или пока не истечет некоторый предварительно заданный период времени после приема последних данных из данного удаленного сервера (фактически - пока не произойдет тайм-аут). Таким образом, хотя стрелкой 1008а обозначена передача данных из удаленного сервера в шлюз 58, объем этих данных меньше упомянутого предварительно заданного порогового значения, и поэтому в приемник-декодер 13 после этого не передается никакого сообщения. Затем происходит еще одна передача данных (стрелка 1008b) из удаленного сервера в шлюз 58. По результатам этой передачи в шлюзе 58 оказывается принятым достаточное количество данных, и, как следствие, он передает сообщение 1009 обмена данными, в которое включаются данные обеих операций передачи данных, 1008а и 1008b. Аналогичным образом в приемник-декодер 13 передается сообщение обмена данными как только количество данных, принятых шлюзом 58 из удаленного сервера, превысит некоторое максимальное значение. В таком случае одна операция обмена данными между удаленным сервером и шлюзом 58 может привести к обмену несколькими сообщениями между шлюзом 58 и приемником-декодером 13.
В рассматриваемом варианте осуществления упомянутый лимит времени (тайм-аут) составляет 200 мс, упомянутое минимальное пороговое количество данных составляет 128 байтов, и упомянутое максимальное пороговое количество данных составляет 512 байтов.
Хотя это и не показано на данной фигуре, может произойти так, что в течение некоторого предварительно заданного интервала времени, который в данном варианте осуществления составляет 5 секунд, шлюз 58 не получает из удаленного сервера никаких данных. В таком случае шлюз передает в приемник-декодер 13 сообщение "шлюзом обнаружена ошибка" (MG_ERROR), содержащее поле параметров типа "КОД_ОШИБКИ", содержимое которого указывает на возникновение такого события. Последующие действия будут определяться приемником-декодером 13 и могут включать, например, передачу сообщения "инициализация соединения" (MG_RCNX), в ответ на которое шлюз 58 закрывает TCP-соединение с удаленным сервером.
Как упоминалось выше, подобные сообщения об ошибке могут следовать и за другими событиями, такими как неспособность установить соединение с удаленным сервером, потеря соединения с удаленным сервером, или содержащее ошибку сообщение, принятое из удаленного сервера. Последний случай может включать прием шлюзом 58 из удаленного сервера данных неизвестного типа, неправильной длины, неприемлемого значения или имеющих неизвестную версию протокола.
Вновь обратившись к фиг.9, опишем событие отключения от удаленного сервера (е3). Это событие инициируется приемником-декодером 13, передающим сообщение "отключиться" (MG_DCNX) 1020. Это сообщение может включать в себя данные, которые должны быть переданы в удаленный сервер, - в параметре "БЛОК_ДАННЫХ". Эта команда и данные передаются в удаленный сервер (стрелка 1021), и после этого шлюз 58 ожидает подтверждения и ответных данных 1022 (если таковые предполагаются). После этого шлюз 58 отключается от удаленного сервера (1023) и передает в приемник-декодер 13 сообщение 1024, содержащее принятые данные, если таковые имеются. Хотя это и не показано на данной фигуре (как связанное с протоколом низкого уровня), приемник-декодер 13 может затем закрыть данное соединение на уровне модема. После этого шлюз 58 будет уведомлен сервером NAS 56 о закрытии TCP-соединения.
Ниже со ссылками на фиг.10 будет описана процедура аутентификации, обеспечиваемая протоколом шлюза. Эта процедура может понадобиться для различных сервисов, например сервисов поддержки, перед организацией канала передачи данными. Шлюз 58 обладает информацией о том, какие серверы требуют аутентификации перед предоставлением доступа, и, когда он получает сообщение "запрос соединения" (MG_CNX) 1100 в отношении такого сервера, он отвечает сообщением "запрос аутентификации" (MG_AUTHEB_REQ) 1101. Такое запрашивающее аутентификацию сообщение не включает в себя никаких параметров. После этого приемник-декодер 13 должен ответить соответствующим сообщением 1102 "аутентификации". Это сообщение имеет параметр, содержащий аутентификационные данные, которыми может быть, например, номер смарт-карты, как более подробно описано ниже. Эти аутентификационные данные могут передаваться в параметре типа "БЛОК_ДАННЫХ" или в одной из модификаций рассматриваемого варианта осуществления настоящего изобретения, в параметре отдельного специального типа.
Если шлюз 58 находит эту аутентификационную информацию правильной, результат аутентификации будет положительным (как схематически представлено событием 1103), и шлюз 58 установит соединение 1104 с указанным удаленным сервером. О положительном результате аутентификации шлюз 58 сообщает путем передачи сообщения 1106 обмена данными, в которое будут включены любые данные 1105, полученные из данного удаленного сервера в ответ на установление соединения. В случае отрицательного результата аутентификации передается сообщение об ошибке (MG_ERROR), имеющее параметр, указывающий на ошибку, как было описано выше.
Вернемся к системе, показанной на фиг.5; можно выделить два отдельных типа учетных записей для доступа к Интернет-сервисам и т.п. с помощью приемника-декодера 13, а именно так называемую "учетную запись соединения" (connection account) и так называемую "учетную запись для пользования сервисами" (directory account). В каждой учетной записи соединения могут содержаться несколько учетных записей для пользования сервисами.
Учетная запись соединения является той основой, используя которую подписчик может получить доступ к сети оператора. Оператор выделяет каждому подписчику одну учетную запись соединения, хотя она может соответствовать нескольким протоколам для соединения, как более подробно описывается ниже. Процедура аутентификации такой учетной записи реализуется на сетевом уровне и также будет более подробно описана ниже.
Опишем теперь действия, выполняемые при регистрации (logging-in) пользователя при подключении к системе с использованием учетной записи соединения. Понятно, что для того, чтобы пользователь мог быть идентифицирован, передаваемые при регистрации данные должны быть уникальными. В рассматриваемом варианте осуществления это достигается путем использования так называемого MSD-номера, который по меньшей мере частично является производным от номера смарт-карты оборудования пользователя. Кроме того, при регистрации пользователь должен указать протокол передачи данных, который может быть различным в зависимости от того, например, пытается ли пользователь получить доступ через модем для соединения по телефонной линии, подключенный к компьютеру (с использованием, например, продукта MediaWebPC компании Canal+), или приемник-декодер того типа, который обычно именуют "приставкой для телевизора" (set-top box). В случае использования модема для соединения по телефонной линии используемые протоколы могут быть, например, протоколами PAP, CHAP или РРР.
Таким образом, регистрационные данные (login information) включают в себя MSD-номер данного пользователя, поле, идентифицирующее тип пользовательского терминала, поле, определяющее тип ответных данных, который должен применяться, поле, указывающее номер версии клиентского оборудования, и в соответствующем случае доменное имя так называемой службы удаленной аутентификации пользователей по телефонным линиям (RADIUS). Регистрационный данные также будет включать в себя пароль. В рассматриваемом варианте осуществления эти данные имеют следующий формат:
login={msn_номер} {тип_терминала} {тип_ответа} {версия} [@доменное_имя_RADIUS]
Объясним теперь более подробно каждое из упомянутых выше полей.
Поле "msn_номер" в свою очередь состоит из следующей последовательности полей:
{номер_msn}={RSMC} {RSMN} {chck}
Первое из полей MSN-данных содержит код сменного защитного модуля (removable security module code - RSMC), идентифицирующий тип смарт-карты. Этот идентификатор типа может содержать данные, указывающие на один или несколько аспектов технического устройства карты, изготовителя и коммерческого оператора, предоставившего эту карту пользователю. В рассматриваемом варианте осуществления это поле имеет длину два байта и может содержать четыре цифры.
Второе из полей MSN-данных содержит номер сменного защитного модуля (removable security module number - RSMN). Это поле содержит код, идентифицирующий данную смарт-карту при ее использовании. Такой код предпочтительно предварительно задается поставщиком этой смарт-карты и является уникальным, позволяя, таким образом, уникально идентифицировать ее пользователя. В рассматриваемом варианте осуществления длина этого поля составляет четыре байта, и оно может содержать пятнадцать цифр.
Последнее поле (chck) содержит контрольные данные, которые могут вычисляться любым известным способом; например, это может быть контрольная сумма.
Опишем теперь поле "тип_терминала". Как пояснялось выше, терминал может быть разновидностью так называемой "приставки для телевизора", или это может быть компьютер, снабженный модемом. Это поле принимает значение "Р" для терминала типа ПК (PC) и значение "Т" для терминала типа "приставки для телевизора" (set-top box). Понятно, что данное поле может определять тип терминала и более конкретно, и что определение такого поля предоставляет возможность последующего расширения, путем определения дополнительных и альтернативных типов терминалов.
Поле "тип_ответа" позволяет определить способ, с помощью которого пользователю будут передаваться ответные данные. В настоящем варианте осуществления это поле принимает значение "М", когда все ответные данные должны направляться через модем, и значение "S", когда передача ответных данных должна происходить и через спутник, и через модемные каналы. Опять же, предусматривается возможность последующего расширения в том, что касается способов передачи ответных данных.
Поле "версия" позволяет передавать данные о версии из приемника-декодера 13 в сеть. В настоящем варианте осуществления это поле по умолчанию установлено равным "01".
Необязательное поле "доменное_имя_RADIUS" позволяет направлять пользовательский запрос на аутентификацию в сторонний (принадлежащий третьей стороне) сервер аутентификации, что может сделать возможным предоставление соответствующей третьей стороной шлюзов для, например, различных провайдеров сервисов.
Регистрационные данные будут также содержать поле "пароль", максимальная длина которого в настоящем варианте осуществления составляет 14 буквенно-цифровых символов.
Вернемся теперь назад и опишем учетную запись для пользования сервисами, которая является основой для доступа к отдельным Интернет-сервисам, например, proxy-сервера с идентификацией, электронной почты, конференций и т.п. Учетные записи подписчика для пользования сервисами привязаны к учетной записи соединения. Однако, в отличие от учетной записи соединения, аутентификация учетной записи для пользования сервисами происходит на уровне приложения.
Как указывалось выше, учетная запись для пользования сервисами позволяет использовать различные Интернет-серсисы с помощью приемника-декодера 13. Учетная запись для пользования сервисами будет обычно состоять из
- идентификатора и пароля;
- одного или нескольких так называемых "почтовых псевдонимов" (е-mail aliases);
- в соответствующих случаях, других данных, имеющих отношение к предлагаемым подписчику сервисам.
Упомянутый идентификатор (в соответствующих случаях в сочетании с паролем) используется для управления доступом подписчика к различным сервисам ISP, например, доступом к почтовому ящику подписчика. Другими примерами является доступ к конфиденциальным Web-сайтам, каталогам, управление доступом к услугам, сертификатам, регистрация для участия в "почтовой рассылке" (mailgroup) и т.п.
Упомянутый идентификатор может также использоваться для получения почтового адреса в формате "идентификатор@домен", в случае чего может потребоваться использование подписчиком своего пароля для доступа к почтовому ящику, идентифицированному указанным идентификатором.
Упомянутые почтовые псевдонимы обеспечивают возможность приема почтовым сервером электронной почты с адресом "псевдоним@домен".
В одном из вариантов осуществления с одной учетной записью соединения могут быть связаны несколько учетных записей для пользования сервисами (так называемая "семейная подписка"). В таком случае пользователю можно будет первоначально указать количество учетных записей для пользования сервисами, которое может быть создано для каждой учетной записи соединения, хотя следует отметить, что каждый идентификатор и псевдоним должен быть уникальным.
Термин "приемник-декодер", или "декодер", как он используется в данном тексте, может означать приемник для приема как закодированных, так и незакодированных сигналов, например, теле- и/или радиосигналов, которые можно передавать путем вещания или каким-либо другим способом. Этот термин может также обозначать декодер для декодирования принятых сигналов. Варианты исполнения таких приемников-декодеров могут включать в себя декодер, совмещенный с приемником, для декодирования принимаемых сигналов, как, например, в "приставке для телевизора" (set-top box), декодер, функционирующий в сочетании с физически отдельным приемником, или декодер, снабженный дополнительными функциями, такими как Web-браузер, или совмещенный с другими устройствами, такими как записывающее устройство или телевизор.
Естественно, настоящее изобретение было описано выше на исключительно иллюстративном примере, и без выхода за рамки настоящего изобретения возможны различные модификации.
Каждая особенность, раскрытая в описании изобретения, а также (в соответствующих случаях) в формуле изобретения и на чертежах, может быть реализована независимо либо в любом подходящем сочетании.
Приведенные в формуле изобретения номера позиций служат лишь для наглядности и не должны рассматриваться как имеющие какое-либо ограничивающее воздействие на объем формулы изобретения.
Изобретение относится к области радиотехники. Технический результат заключается в упрощении конструкции приемников-декодеров. Сущность изобретения заключается в том, что для аутентификации обмена данными используется идентификатор приемника-декодера, основанного на номере смарт-карты, и используется шлюз, выполненный с возможностью приема из приемника-декодера данных, передаваемых с помощью немежсетевого протокола, и преобразования этих данных в межсетевой протокол для их последующей передачи провайдеру Интернет-услуг. 2 н. и 18 з.п. ф-лы, 10 ил.
| WO 9843427 A, 01.10.1998 | |||
| RU 2058043 C1, 10.04.1996 | |||
| WO 9850862 A, 12.11.1998 | |||
| WO 9856188 А, 10.12.1998. |
