Способ доставки источника руководства услуги для генерирования руководства услуги в мобильной системе широковещательной передачи и способ и система доставки события, требующего уведомления/сообщения об уведомлении

Изобретение относится к области мобильной связи. Технический результат заключается в расширении функциональных возможностей. Сущность изобретения заключается в том, что мобильная система широковещательной передачи данных включает в себя первое устройство, предназначенное для управления информацией абонента услуги широковещательной передачи, выполняющее обработку генерирования, по меньшей мере, одного сообщения уведомления в соответствии с, по меньшей мере, одним уведомлением о событии и генерирования ответного сообщения, обозначающего конец генерирования сообщения уведомления; и второе устройство, предназначенное для передачи сообщения уведомления о событии, для запроса генерирования сообщения уведомления в первое устройство в соответствии с, по меньшей мере, одним уведомлением о событии, принимающее ответное сообщение в ответ на него и затем выполняющее обработку доставки сообщения уведомления по каналу широковещательной передачи данных или по каналу взаимодействия. 4 н. и 26 з.п. ф-лы, 14 ил., 47 табл.

 

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

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

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

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

Открытый союз мобильной связи (OMA, ОСМС), группа, предназначенная для изучения стандарта взаимодействия между отдельными мобильными станциями, была организована для определения стандартов различных приложений для мобильных игр и услуг, предоставляемых через Интернет. Среди рабочих групп OMA Рабочая подгруппа разработки браузера Открытого союза мобильной связи и мобильной широковещательной передачи содержания (OMA BAC BCAST, БОСМС МШПС) разрабатывает технологию, обеспечивающую услуги широковещательной передачи с использованием мобильных терминалов. Ниже приведено краткое описание системы мобильной широковещательной передачи (BCAST), которая обсуждается в OMA.

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

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

Таблица 1
Название	Описание
SG1(103)	Обмен данными между серверами для доставки атрибутов содержания, таких как информация описания, информация о месте расположения, информация о возможностях целевого терминала, профиль целевого параметра пользователя и так далее либо в форме фрагментов руководства услуги BCAST, или в собственном формате.
SG2 (106)	Обмен данными между серверами для доставки атрибутов услуги BCAST, таких как информация описания услуги/содержания, информация планирования, информация о месте расположения, информация о возможностях целевого терминала, профиль целевого пользователя и так далее, в форме фрагментов руководства услуги BCAST.
SG-B1 (116)	Обмен данными между серверами либо для доставки специфичных атрибутов BDS из Системы широковещательного распространения (BDS, СШР) в функцию адаптации руководства услуги BCAST, с тем чтобы способствовать адаптации руководства услуги к специфичным BDS, или для доставки атрибутов руководства услуги BCAST в BDS для специфичной для BDS адаптации и распространения.
SG4(112)	Обмен данными между серверами для доставки информации об основных положениях, информации о возможностях покупки, информации о подписке, рекламной информации и так далее в форме фрагментов руководства услуги BCAST.
SG5(117)	Доставка руководства услуги BCAST через канал широковещательной передачи по IP.
SG6(118)	Доставка руководства услуги BCAST через канал взаимодействия. Интерактивный доступ для получения руководства услуги или дополнительной информации, относящейся к руководству услуги, например, с использованием HTTP, SMS или MMS.

Таблица 2
Название	Описание
X-1(124)	Опорная точка между распределением услуги BDS и BDS.
X-2(125)	Опорная точка между распределением услуги и сетью взаимодействия BDS.
X-3(126)	Опорная точка между BDS и терминалом.
X-4(127)	Опорная точка между распределением услуги BDS и терминалом по каналу широковещательной передачи.
X-5(128)	Опорная точка между распределением услуги BDS и терминалом по каналу взаимодействия.
X-6(129)	Опорная точка между сетью взаимодействия и терминалом.

Рассмотрим фиг.1, на которой блок 101 формирования содержания (CC) представляет собой автора содержания или провайдера содержания, который представляет собой провайдера услуги широковещательной передачи (BCAST), и услуга BCAST может включать в себя обычную услугу широковещательной передачи аудио/видеоданных, услугу загрузки музыкального файла/файла данных и так далее. Формирование 101 содержания, включающее в себя источник 102 формирования содержания руководства услуги (SGCCS), передает информацию о содержании, необходимую для формирования руководства услуги для услуги BCAST, информацию о возможностях мобильных терминалов, информацию о профиле пользователя и информацию о времени содержания в источник 105 приложения руководства услуги (SGAS) блока 104 приложения услуги BCAST (BSA) через интерфейс 103 SG1 по таблице 1.

Блок 104 приложения услуги BCAST обрабатывает данные услуги BCAST, предоставляемые из блока 101 формирования содержания, в форме, соответствующей сети BCAST, формируя данные услуги BCAST. Кроме того, блок 104 приложения услуги BCAST генерирует стандартизированные метаданные, необходимые для руководства мобильной широковещательной передачи. SGAS 105 доставляет различные источники, необходимые для генерирования руководства услуги, такие как подробная информация об услуге/содержании, информация о планировании и информация о месте расположения, включающая в себя информацию, предоставляемую из SGCCS 102, в блок 109 генерирования руководства услуги (SG-G, Г-РУ) в блоке 108 (BSD/A) распределения/адаптации услуги BCAST через интерфейс 106 SG2.

Блок 108 распределения/адаптации услуги BCAST имеет функцию установки несущей, по которой он будет доставлять данные услуги BCAST, предоставляемые из блока 104 приложения услуги BCAST, функцию определения планирования передачи услуги BCAST и функцию формирования информации руководства мобильной широковещательной передачи. Блок 108 распределения/адаптации услуги BCAST соединен с системой 122 широковещательного распространения (BDS, СШР), которая представляет собой сеть, предназначенную для передачи данных услуги BCAST, и сеть 123 взаимодействия, поддерживающую интерактивную передачу данных.

Руководство услуги, сгенерированное SG-G 109, доставляют в терминал 119 через блок 110 распределения SG (SG-D, Р-РУ) и интерфейс 117 SG5. Если руководство услуги будет доставлено через BDS 122 или сеть 123 взаимодействия, которая поддерживает интерактивную передачу данных, или если существует потребность согласования с соответствующей системой или сетью, руководство услуги, генерируемое SG-G 109, согласуют в блоке 111 адаптации SG (SG-A, А-РУ) и затем доставляют в SG-D 110, или доставляют в блок 121 распространения услуги BDS через интерфейс 116 SG-B1.

Блок 113 управления подпиской BCAST управляет информацией о подписке и информацией о предоставлении услуги для получения услуги BCAST, и информацией об устройстве для терминала, получающего услугу BCAST. Источник 114 подписки на руководство услуги (SGSS, ИПРУ) в блоке 113 управления подпиской BCAST доставляет источники, связанные с генерированием подписки и предоставлением руководства услуги, и такие источники, как информация о покупке и информация, относящаяся к публичности в SG-G 109, которая генерирует руководство услуги через интерфейс 112 SG4.

Блок 121 распространения услуги BDS предназначен для распространения всех услуг, принимаемых BCAST через канал широковещательной передачи или канал взаимодействия, и представляет собой объект, который может либо существовать, или может не существовать в соответствии с типом BDS 122. BDS 122 представляет собой сеть, которая передает услугу BCAST, и может представлять собой сеть широковещательной передачи, такую как Цифровое телевидение в карманных устройствах (DVB-H, ЦТВ-К), услуги Мультимедийной широковещательной и многоадресной передачи на основе 3GPP (MBMS, МШМА), услуги широковещательной и многоадресной передачи на основе 3GPP2 (BCMCS, ШВМАП). Сеть 123 взаимодействия передает услугу BCAST на основе принципа "из точки в точку" или в интерактивном режиме осуществляет обмен информацией управления и дополнительной информацией, относящейся к получению услуги BCAST, и может представлять собой, например, существующую сотовую сеть.

Терминал 119 представляет собой терминал, способный принимать услугу BCAST через интерфейс 130 Ai (ИИ, искусственного интеллекта) и может быть соединен с сотовой сетью связи в соответствии с возможностями терминала. Терминал 119, включающий в себя клиент 120 руководства услуги (SG-C), принимает руководство услуги, передаваемое через интерфейс 117 SG5, или принимает сообщение-уведомление, передаваемое через интерфейс 118 SG6, выполняя, таким образом, соответствующую операцию по приему услуги BCAST.

В таблице 3 - таблице 5, приведенных ниже, представлено краткое описание основных элементов (например, логических объектов), показанных на фиг.1, определенных в стандарте услуги BCAST.

Таблица 3
Название	Описание
Формирование содержания (101)	Источник формирования содержания руководства услуги (SGCCS, ИФСРУ) может предоставлять содержание и атрибуты, такие как информация описания содержания, возможности целевого терминала, профиль целевого пользователя, информация о времени содержания и так далее, и передает их через SG1 в форме стандартизованных фрагментов руководства услуги BCAST или в собственном формате.
Приложение услуги BCAST (104)	Источник приложения руководства услуги (SGAS) предоставляет информацию описания услуги/содержания, информацию планирования, информацию о месте расположения, возможностях целевого терминала, профиля целевого пользователя и так далее и передает их через SG2 в форме стандартизованных фрагментов руководства услуги BCAST.
Управление Подпиской BCAST (113)	Источник подписки на руководство услуги (SGSS) предоставляет информацию предоставления, информацию о покупке, информацию о подписке, рекламную информацию и так далее и передает их через SG4 в форме фрагментов руководства услуги.

Таблица 4
Название	Описание
Генерирование руководства услуги (SG-G) (109)	SG-G в сети отвечает за прием фрагментов руководства услуги из различных источников, таких как SGCCS, SGAS, SGSS через интерфейсы SG-2 и SG-4. SG-G собирает фрагменты, такие как информация доступа к услугам и содержанию в соответствии со стандартизованной схемой и генерирует руководство услуги, которое передают в блок распространения руководства услуги (SG-D) для передачи. Перед передачей, в случае необходимости, ее адаптируют в функции 111 адаптации руководства услуги (SG-A) так, чтобы она соответствовала конкретной BDS.
Функция клиента руководства услуги (SG-C, К-РУ) (120)	SG-C в терминале отвечает за прием информации руководства услуги из соответствующей BDS и делает руководство услуги доступным для мобильного терминала. SG-C получает специфичную информацию руководства услуги. Она может фильтровать ее так, чтобы она соответствовала определенным критериям терминала (например, местоположение, профиль пользователя, возможности терминала), или она просто получает всю доступную информацию руководства услуги. Обычно пользователь может просматривать информацию руководства услуги в виде меню, в виде списка или табличном формате. SG-C может передавать запрос в сеть через SG-6 для получения специфичной информации руководства услуги или всего руководства услуги.

Таблица 5
Название	Описание
Распространение руководства услуги (SG-D, Р-РУ) (110)	SG-D генерирует поток IP для передачи руководства услуги через интерфейс SG5 и канал широковещательной передачи в SG-C. Перед передачей SG-G может передать руководство услуги в функцию адаптации руководства услуги (SG-A) для адаптации руководства услуги, так, чтобы она соответствовала специфичной BDS, в соответствии с атрибутами BDS, переданными функцией распространения услуги BDS через SG-B1. В результате адаптации может быть выполнена модификация руководства услуги. Следует отметить, что с целью адаптации SG-A может также передавать атрибуты руководства услуги BCAST или фрагменты руководства услуги BCAST через SG-B1 в распространение услуги BDS для адаптации, эта адаптация в пределах распространения услуги BDS находится за пределами объема BCAST. SG-D также может принимать запрос на информацию руководства услуги и передавать запрашиваемую информацию руководства услуги в терминал непосредственно через канал взаимодействия. SG-D также может фильтровать информацию руководства услуги из SG-G на основе заранее определенного профиля конечного пользователя. И SG-D может также передавать руководство услуги в BDS, которая модифицирует руководство услуги (например, добавляя специфичную информацию BDS), и дополнительно распространяет руководство услуги SG-C специфичным для BDS способом.

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

Как показано на фиг.2, блок 201 формирования содержания (CC, ФС) представляет собой провайдера услуги BCAST, и услуга BCAST может включать в себя обычную услугу широковещательной передачи аудио/видеоданных, услугу загрузки музыкальных файлов/файлов данных и так далее. Когда возникает проблема, связанная с предоставлением услуги BCAST, или происходит изменение услуги BCAST, блок 201 формирования содержания уведомляет об этом изменении функцию 202-1 события, требующего уведомления, (NTE, СДУ), которая расположена в приложении 202 услуги BCAST.

Приложение 202 услуги BCAST обрабатывает данные услуги BCAST, предоставляемые из блока 201 формирования содержания в форме, соответствующей сети BCAST, формируя данные услуги BCAST, и генерирует стандартизованные метаданные, необходимые для руководства мобильной широковещательной передачи. Кроме того, приложение 202 услуги BCAST уведомляет об изменении в услуге BCAST, предоставляемом из блока 201 формирования содержания, в функцию 204-1 генерирования уведомления (NTG, ГНУ), которая расположена в управлении 204 подпиской BCAST (BSM).

Приложение 203 распространения/адаптации услуги BCAST отвечает за установку несущего канала, по которому оно будет передавать данные услуги BCAST, предоставляемые из приложения 202 услуги BCAST, определяя планирование передачи услуги BCAST и генерируя руководство мобильной широковещательной передачи, и соединено с системой 206 распространения широковещательной передачи (BDS), которая способна предоставлять услуги BCAST, и с сетью 207 взаимодействия, поддерживающей интерактивную передачу данных. Кроме того, приложение 203 распространения/адаптации услуги BCAST, включающее в себя функцию 203-1 адаптации распространения уведомления (NTDA, АРУВ), принимает сообщение уведомления из приложения 204 управления подпиской BCAST и доставляет сообщение уведомления одному или множеству пользователей через BDS 206 или сеть 207 взаимодействия.

Приложение 204 управления подпиской BCAST управляет информацией о подписке для получения услуги BCAST, информацией о предоставлении услуги и информацией об устройстве для устройства, принимающего услугу BCAST. В частности, приложение 204 управления подпиской BCAST, включающее в себя функцию 204-1 генерирования уведомления, генерирует сообщения уведомления путем приема информации о событии, требующем уведомления, из блока 201 формирования содержания и BDS 206, или генерирует сообщение уведомления для события услуги BCAST.

Приложение 205 распространения услуги BDS предназначено для распространения всех принимаемых услуг BCAST через канал широковещательной передачи или канал взаимодействия и представляет собой объект, который может существовать или может не существовать в соответствии с типом BDS 206.

BDS 206 представляет собой сеть, которая доставляет услугу BCAST, и может представлять собой, например, DBV-H, MBMS на основе 3GPP и BCMCS на основе 3GPP2. Кроме того, когда происходит изменение в поставке определенной услуги BCAST, BDS 206 уведомляет об этом изменении приложение 203 распространения/адаптации услуги BCAST через интерфейс 231 X-1, или через интерфейс 224 NT-B1, если существует функция 205 распространения услуги BDS.

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

Терминал 208 представляет собой терминал, имеющий возможность приема услуги BCAST, и может быть соединен с сотовой сетью в соответствии с возможностями терминала. Здесь предполагается, что терминал 208 представляет собой терминал, выполненный с возможностью доступа к сотовой сети. Терминал 208 выполняет соответствующую операцию путем приема сообщения уведомления, поставляемого через интерфейс 225 NT-5, с помощью функции 208-1 уведомления клиента (NTC, УВК) или выполняет соответствующую операцию путем приема сообщения уведомления, переданного через интерфейс 226 NT-6.

Далее приведено описание серверных интерфейсов между логическими объектами по фиг.2.

Интерфейс 221 NT-1, представляющий собой интерфейс между функцией 202-1 события, требующего уведомления, размещенной в приложении 202 услуги BCAST, и блоком 201 формирования содержания, используют для доставки события, требующего уведомления, возникающего в блоке 201 формирования содержания с функцией 202-1 события, требующего уведомления.

Интерфейс 222 NT-3 представляет собой интерфейс между функцией 202-1 события, требующего уведомления, размещенной в блоке 202 приложения услуги BCAST, и функцией 204-1 генерирования уведомления в приложении 204 управления подпиской BCAST, доставляет информацию, необходимую для генерирования события, требующего уведомления, или сообщения уведомления таким образом, что функция 204-1 генерирования уведомления может генерировать сообщение уведомления.

Интерфейс 223 NT-4 представляет собой интерфейс между функцией 204-1 генерирования уведомления, размещенной в приложении 204 управления подпиской BCAST, и функцией 203-1 адаптации распространения уведомления в приложении 203 распространения/адаптации услуги BCAST, используется для доставки сообщения уведомления, генерируемого в функции 204-1 генерирования уведомления, в функции 203-1 адаптации распространения уведомления таким образом, что ее доставляют через BDS 206 или сеть 207 взаимодействия, или поставляют событие, требующее уведомления, возникшее в BDS 206, из функции 203-1 адаптации распространения уведомления в функцию 204-1 генерирования уведомления.

Интерфейс 225 NT-5 представляет собой интерфейс, используемый, когда сообщение уведомления, составленное из функции 203-1 адаптации распространения уведомления в распространении/адаптации 203 услуги BCAST, непосредственно доставляют в терминал 208 через канал широковещательной передачи данных. Интерфейс 225 NT-5 используется для доставки сообщения уведомления в один или множество терминалов.

Интерфейс 226 NT-6 представляет собой интерфейс, используемый, когда сообщение уведомления, доставленное из функции 203-1 адаптации распространения уведомления в приложении 203 распространения/адаптации услуги BCAST, непосредственно доставляют в терминал 208 через выделенный канал с терминала 208, через сеть 207 взаимодействия или через канал широковещательной передачи, предусмотренный в сети 207 взаимодействия. Интерфейс 226 NT6 используется для доставки сообщения уведомления в один или множество терминалов.

Интерфейс 224 NT-B1 представляет собой интерфейс между приложением 203 распространения/адаптации услуги BCAST и приложением 205 распространения услуги BDS, используется для установления тракта передачи, предназначенного для использования в BDS 206 распространения/адаптации 203 услуги BCAST, или тракта приема события, требующего уведомления, возникшего в BDS 206.

Интерфейс 231 X-1 представляет собой интерфейс, используемый для установления тракта передачи, предназначенного для использования в BDS 206 приложения 203 распространения/адаптации услуги BCAST, или тракта приема события, требующего уведомления, возникшего в BDS 206, когда приложение 205 распространения услуги BDS не существует. Когда приложение 205 распространения услуги BDS существует, интерфейс 231 X-1 используется как интерфейс между BDS 206 и приложением 205 распространения услуги BDS для доставки события, требующего уведомления, возникшего в BDS 206.

Интерфейс 232 X-2 представляет собой интерфейс, используемый для установления тракта передачи, предназначенного для использования в сети 207 взаимодействия с помощью приложения 203 распространения/адаптации услуги BCAST, когда приложение 205 распространения услуги BDS не существует. Когда приложение 205 распространения услуги BDS существует, интерфейс 232 X-2 используется как интерфейс между BDS 206 и сетью 207 взаимодействия для установки несущего канала передачи, по которому сообщение уведомления будет передано в сеть 207 взаимодействия.

Интерфейс 233 X-3 представляет собой интерфейс между BDS 206 и терминалом 208, используется для услуги BCAST или всех сообщений, переданных через канал широковещательной передачи.

Интерфейс 234 X-4 представляет собой интерфейс канала широковещательной передачи между приложением 205 распространения услуги BDS и терминалом 208.

Интерфейс 235 X-5 представляет собой интерфейс канала взаимодействия между приложением 205 распространения услуги BDS и терминалом 208.

Интерфейс 236 X-6 представляет собой интерфейс канала взаимодействия, с помощью которого сеть 207 взаимодействия может передавать информацию управления, относящуюся к услуге BCAST.

Функция 202-1 события, требующего уведомления, доставляет информацию, необходимую для генерирования сообщения уведомления, в функцию 204-1 генерирования уведомления и после распознавания возникновения события, требующего уведомления (например, события, требующего уведомления), передают информацию о событии, требующем уведомления, в функцию 204-1 генерирования уведомления. Функция 204-1 генерирования уведомления генерирует сообщение уведомления путем приема события, требующего уведомления, и информацию, необходимую для генерирования сообщения уведомления, из функции 202-1 события, требующего уведомления, или генерирует сообщение уведомления, используя событие, требующее уведомления, BDS 206, принятое через функцию 203-1 адаптации распространения уведомления, и передает сгенерированное сообщение уведомления в функцию 203-1 адаптации распространения уведомления. Сообщение уведомления может быть сгенерировано, (i) когда существует необходимость в уведомлении о начале услуги, (ii) когда существует необходимость доставить новое руководство мобильной широковещательной передачи после приема уведомления, обозначающего изменение в информации услуги, из блока 201 формирования содержания, и (iii) когда определенное событие происходит в BDS 206.

Функция 203-1 адаптации распространения уведомления предназначена для доставки сообщения уведомления через NT5 225 или NT6 226, и после приема из BDS 206 уведомления, обозначающего изменение конкретной услуги мобильной широковещательной передачи данных, например, обозначающей регулировку скорости передачи данных, на основе среды беспроводной сети или невозможности предоставления услуги, предназначенной для доставки соответствующего события, требующего уведомления, в функцию 204-1 генерирования уведомления через NT4 223.

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

Здесь номером 301 ссылочной позиции обозначен SGCCS 102 в блоке 101 формирования содержания, номером 302 ссылочной позиции обозначен SGAS 105 в блоке 104 приложения услуги BCAST, номером 303 ссылочной позиции обозначен SGSS 114 в блоке 113 управления подпиской BCAST и номером 304 ссылочной позиции обозначены SG-G/D/A 109, 110 и 111 в блоке 108 распространения/адаптации услуги BCAST.

Рассмотрим фиг.3, на этапе 311 SGCCS 301 доставляет информацию о содержании и атрибуты, ассоциированные с услугой BCAST, в SGAS 302. На этапе 312 SGAS 302 доставляет информацию широковещательной передачи содержания/услуги и атрибуты в SG-G/D/A 304 в соответствии с форматом BCAST, используя атрибуты, полученные из SGCCS 301. На этапе 313 SG-G/D/A 304 передает запрос на информацию, относящуюся к предоставлению, в SGSS 303. На этапе 314 SGSS 303 предоставляет запрошенную информацию, относящуюся к предоставлению, в SG-G/D/A 304. На этапе 315 SG-G/D/A 304 генерирует руководство услуги (SG).

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

Здесь номер 401 ссылочной позиции обозначает функцию 202-1 события, требующего уведомления, (NTE) в блоке 202 приложения услуги BCAST, номером 402 ссылочной позиции обозначена функция 204-1 генерирования уведомления (NTG) в блоке 204 управления подпиской BCAST и номером 403 ссылочной позиции обозначена функция 203-1 адаптации распространения уведомления (NTDA) в блоке 203 распространения/адаптации услуги BCAST.

Как показано на фиг.4, событие уведомления генерируется в NTE 401 или NTDA 403, и затем его доставляют в NTG 402, или генерируют в блоке 204 управления подпиской BCAST или BDS 206. Таким образом, если в блоке 201 формирования содержания или BSA 202 происходит событие, требующее уведомления, NTE 401 доставляет на этапе 411 уведомление о событии в NTG 402 в BSM 204 через интерфейс 222 NT3. Если событие, требующее уведомления, произошло в распространении/адаптации 203 услуги BCAST или в BDS 206, информацию о событии, требующем уведомления, поставляют из NTDA 403 в NTG 402 через интерфейс 223 NT4 на этапе 412. Событие, требующее уведомления, также может быть сгенерировано спонтанно в BSM 204 и затем доставлено в NTDA 403 через NTG 402. На этапе 413 NTG 402 спонтанно генерирует событие, требующее уведомления, или принимает событие, требующее уведомления, через NT3 222 или NT4 223. На этапе 414 NTG 402 генерирует сообщение уведомления. После этого NTG 402 доставляет сообщение уведомления в NTDA 403 через интерфейс 223 NT4 на этапе 415.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

на фиг.7 показана схема передачи сигналов, иллюстрирующая процесс передачи сообщения запроса информации предоставления по SG-4 в соответствии с примерным вариантом воплощения настоящего изобретения;

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

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

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

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

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

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

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

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

Подробное описание изобретения

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

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

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

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

Как показано на фиг.11, "Название 1101" обозначает название элементов и атрибутов, составляющих соответствующее сообщение. "Тип" 1103 обозначает, имеет ли соответствующее название 1101 тип элемента или атрибута. Каждый элемент имеет значения E1, E2, E3 и E4. E1 представляет верхний элемент для всего сообщения, E2 обозначает вспомогательный элемент E1, E3 обозначает вспомогательный элемент E2 и E4 обозначает вспомогательный элемент E3. Атрибут обозначен как A, и A обозначает атрибут соответствующего элемента. Например, А под E1 обозначает атрибут E1.

"Категория" 1105 используется для обозначения, является ли соответствующий элемент или атрибут обязательным или необязательным в сети N или в терминале T, и имеет значение М, если это значение является обязательным, и значение O, если это значение является необязательным. Поэтому обязательное содержание в сети обозначено как "NM", обязательное содержание в терминале обозначено как "ТМ", необязательное содержание в сети обозначено как "NO", и необязательное содержание в терминале обозначено как "OT". "Мощность связи" 1107 обозначает взаимосвязь между элементами и имеет значения "0", "0..1", "1", "0..n" и "1..n", где "0" означает необязательную взаимосвязь, "1" означает обязательную взаимосвязь и "n" означает возможность множества значений. Например, "0.. n" означает возможность того, что отсутствует соответствующий элемент или имеется n соответствующих элементов. "Описание" 1109 определяет значение соответствующего элемента или атрибута. "Тип данных" 1111 обозначает тип данных соответствующего элемента или атрибута, то есть тип программного языка, используемого для генерирования. Например, можно использовать расширяемый язык разметки (XML, РЯР).

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

Примерное руководство услуги, которое показано на фиг.5, состоит из административной группы 500, предназначенной для предоставления информации верхнего элемента всего руководства услуги, группы 510 предоставления, предназначенной для предоставления информации о подписке и покупке услуги, основной группы 520, предназначенной для предоставления основной информации руководства услуги, такой как услуга содержания и планирования услуги, и группы 530 доступа, предназначенной для предоставления информации доступа для доступа к услуге или содержанию. На фиг.5 сплошная линия, соединяющая фрагменты, означает перекрестную ссылку между фрагментами.

Административная группа 500 представляет собой группу для предоставления основной информации, необходимой для мобильного терминала, для приема руководства услуги, включает в себя фрагмент 501 контекста руководства услуги и фрагмент 502 дескриптора доставки руководства услуги (SGDD, ДДРУ). Фрагмент 501 контекста руководства услуги предоставляет способ, в соответствии с которым терминал может распознать руководство услуги, и также предоставляет информацию об операторе или владельце для распространения руководства услуги и о месте расположения, из которого терминал может принять руководство услуги, и информацию соединения с SGDD для приема руководства услуги. Фрагмент 502 дескриптора доставки руководства услуги предоставляет информацию о сеансе доставки, в котором расположен модуль доставки руководства услуги (SGDU), содержащий фрагмент, который представляет собой минимальный модуль, составляющий руководство услуги, и также предоставляет информацию группирования для SGDU и информацию о точке входа для приема сообщения уведомления.

Группа 510 предоставления представляет собой группу для предоставления информации о начислении счетов за прием услуги. Группа 510 предоставления включает в себя фрагмент 511 предмета покупки, фрагмент 512 данных покупки и фрагмент 513 канала покупки. Фрагмент 511 предмета покупки предоставляет комплект, такой как услуга, содержание и время, для помощи пользователю при подписке или покупке соответствующего предмета покупки. Фрагмент 512 данных покупки включает в себя подробную информацию о покупке и подписке, такую как информация о начислении счета, и рекламную информацию для услуги или комплекта услуг. Фрагмент 513 канала покупки предоставляет информацию доступа для абонирования или покупки.

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

Группа 530 доступа включает в себя фрагмент 531 доступа и фрагмент 532 описания сеанса. Фрагмент 531 доступа обеспечивает информацию, относящуюся к доступу, которая позволяет пользователю просматривать услугу, а также предоставляет способ доставки соответствующего сеанса доступа и информацию сеанса. Фрагмент 532 описания сеанса также может быть включен в фрагмент 531 доступа и предоставляет информацию о месте расположения в форме URI (УИР, унифицированный идентификатор ресурса) таким образом, что терминал может детектировать соответствующую информацию описания сеанса. Кроме того, фрагмент 532 описания сеанса предоставляет информацию адреса и информацию кодека для мультимедийного содержания, существующего в соответствующем сеансе.

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

Руководство услуги на фиг.5 сгенерировано в SG-G 109 по фиг.1, и информация (ниже информация предоставления) группы 510 предоставления предусмотрена SGSS 114 по фиг.1. Соответствующую информацию предоставления доставляют на этапе 314 по фиг.3, и информация на этапе 314 может быть доставлена без запроса на этапе 313. Однако, поскольку информация на этапе 313 не обязательно требуется для получения информации для предоставления, SGSS 114 вначале должен иметь соответствующую услугу и содержание, или информацию планирования, но это не поддерживается обычной системой. Поэтому, в соответствии с примерным вариантом воплощения, в настоящем изобретении решается потребность в интерфейсе SG3 для обмена информацией между SGAS и SGSS. Как описано ниже, услуга/содержание и ее информация планирования предоставляются из SGAS в SGSS через этап 903.

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

Сообщение, передаваемое через SG-4, может быть доставлено в текстовой форме или в форме XML. Соответствующее сообщение будет подробно описано со ссылкой на фиг.7. Сообщение, передаваемое через SG-4, доставляют с использованием IP, TCP (ПУП, протокол управления передачей) и HTTP (ППГТ, протокол передачи гипертекста), и SG-G в BSD/A передает сообщение запроса информации предоставления в SGSS в BSM через HTTP POST. После приема сообщения из SG-G SGSS может передать информацию предоставления вместе с сообщением HTTP RESPONSE (ответ), или может передать сообщение результата через HTTP POST (почтовый протокол).

На фиг.7 показана схема передачи сигналов, иллюстрирующая процесс передачи сообщения запроса информации предоставления через SG-4 в соответствии с вариантом воплощения настоящего изобретения.

На этапе 703 SG-G 701 передает сообщение запроса информации предоставления, включающее в себя ServiceId, ContentId и ScheduleId в SGSS 702. Информация предоставления, как описано на фиг.5, включает в себя информацию начисления счетов за прием услуги абонентом. Сообщение запроса информации предоставления, представленное на этапе 703, показано в таблице 6, приведенной ниже. На этапе 704 SGSS 702 генерирует информацию предоставления руководства услуги с информацией, принятой из SG-G 701, и передает соответствующую информацию в SG-G 701. Когда информация предоставления генерируется и немедленно доставляется, SGSS 702 может передать полученное в результате сообщение вместе с ответным сообщением HTTP, в ответ на сообщение запроса, принятое на этапе 703. Если требуется время для генерирования информации предоставления руководства услуги, SGSS 702 может уведомить об этом с передачей полученного сообщения результата в SG-G 701 через HTTP POST, используя ProvReqId и BSDAAddress во время окончания генерирования информации предоставления после выбора сеанса между SG-G 701 и SGSS 702. Детали сообщения результата показаны в таблицах 7A и 7B, приведенных ниже. В ответном сообщении по таблице 7B, PurchaseItem передают в PurchaseItemInfo в соответствии с таблицами 8A-8E, PurchaseData передают в PurchaseDataInfo по таблицам 9A-9F, и PurchaseChannel передают в PurchaseChannelInfo по таблицам 10A-10E. Что касается ответа на запрос SG-G на этапе 704, ответы на несколько запросов SG-G могут быть переданы из SGSS в SGAS, используя одно сообщение.

Таблица 6
Название	Тип	Категория	Мощность связи	Описание	Тип данных
ProvReq				Определяет сообщение запрос для доставки блока предоставления руководства услуги. Содержит следующие атрибуты: ProvReqId. Содержит следующие элементы: услуга содержание план
ProvReqId	A	M	1	Идентификатор ProvReq, который представляет собой сообщение для SG-G, для запроса информации предоставления.	Целое без знака (32 бита)
BSDAAddress	A	M	l	Адрес BSDA, для приема ответа на этот запрос.	AnyURI (любой УИР)
ServiceId	E1	O	0..N	ID фрагментов услуги	AnyURI
ContentId	E1	O	0..N	ID фрагментов содержания	AnyURI
ScheduleId	E1	О	0..N	ID фрагментов плана	AnyURI
PreviewDataId	E1	О	0..N	ID фрагментов PreviewData

Таблица 7A
Название	Тип	Кате-гория	Мощность связи	Описание	Тип данных
ProvRes	E			Определяет ответное сообщение на ProvReq. Содержит следующие элементы: ProvReqId.
ProvReqId	E1	M	0..N	Идентификатор ProvReqID содержит следующие атрибуты: Ответ. Содержит следующие элементы: Предоставление.	Целое без знака (32 бита)
Response	A	M	1	Определяет результат, как обрабатывается ProvReq в SGSS. Если Response=0, генерируют фрагменты предоставления руководства услуги, и фрагменты предоставления ДОЛЖНЫ быть включены в это ответное сообщение. Если Response=1, генерирование фрагментов предоставления не было выполнено, и запрашивается повторная передача.	Целое (8 битов)

Таблица 7B
Предос-тавление	E2	О	0..1	Определяет фрагменты предоставления для руководства услуги. Содержит следующие элементы: PurchaseItem PurchaseData PurchaseChannel.
PurchaseItem	E3	M	1..N	Определяет PurchaseItem	Purchase ItemInfo
PurchaseData	E3	O	0..N	Определяет PurchaseData	Purchase DataInfo
PurchaseChannel	E3	M	1..N	Определяет PurchaseChannel	Purchase ChannelInfo

Таблица 8A
Название	Тип	Категория	Мощность связи	Описание	Тип данных
PurchaseItemInfo	E			Фрагмент PurchaseItem содержит следующие атрибуты: Id версия validFrom validTo Вес Закрыто. Содержит следующие подэлементы: ExtensionURL ServiceIdRef ScheduleIdRef ContentIdRef PurchaseItemIDRef Название Описание ParentalRating PurchaseDataIDRef.
id	A	M	1	ID (ИД, идентификатор) фрагмента PurchaseItem, глобально уникальный.	anyURI
version	A	M	1	Версия этого фрагмента. Новая версия отменяет предыдущую, как только она будет принята.	Целое без знака (32 бита)

Таблица 8B
validFrom	A	О	0..1	Первый момент, когда этот фрагмент является действительным. Если он не задан, предполагается, что действительность начинается в некоторый момент времени в прошлом. Примечание: время validFrom для PurchaseItem ДОЛЖНО быть не ранее, чем последнее время (времена) validFrom PurchaseItem(s), на которое делается ссылка.	Целое (32 бита), выраженное как время NTP
validTo	A	О	0..1	В последний момент, когда этот фрагмент является действительным. Если не задан, предполагается, что действительность заканчивается в неопределенное время в будущем. Примечание: время validTo PurchaseItem ДОЛЖНО быть не позже, чем самое раннее время (времена) validTo PurchaseItem, на которое делается ссылка.	Целое (32 бита), выраженное как время NTP
Вес	A	NO/TM	1	Предполагаемый порядок отображения этого предмета покупки относительно других пунктов покупки в том виде, как он представлен для конечного пользователя. Порядок отображения определяется на основе увеличения величины веса (то есть предмет покупки с наименьшим весом отображается первым).	целое без знака (32 бита)

Таблица 8C
Закрыт	A	NO/TM	0..1	Если присутствует, и значение = 1, это означает, что предмет покупки закрыт для новых абонентов.	Булево
URL расширения	E1	O	0..N	URL, содержащий дополнительную информацию, относящуюся к этому фрагменту на веб-странице. Терминал может сделать выборку дополнительной информации путем доступа к этому URL.	AnyURI
ServiceIdRef	E1	O	0..N	Ссылки на фрагменты услуги, которые принадлежат этому PurchaseItem. Примечание: к фрагменту услуги могут обращаться множество PurchaseItems. Атрибуты содержания: Presentation WindowID Presentation WindowIDs, декларированные в этом атрибуте, ДОЛЖНЫ представлять собой полный набор или поднабор PWId, декларированных в фрагменте ScheduleId, к которому принадлежит эта ссылка.	anyURI

Таблица 8D
PresentationWindowID	A	NO/TM	0..N	Относительная ссылка на Presentation WindowID, которому принадлежит фрагмент доступа.	anyURI
ScheduleIDRef	E1	О	0..N	Ссылается на фрагменты плана, которые принадлежат этому PurchaseItem. Примечание: к фрагменту плана могут обращаться множество PurchaseItems.	anyURI
ContentIDRef	E1	O	0..N	Ссылки на фрагменты содержания, которые принадлежат этому PurchaseItem. Примечание: на фрагмент содержания может ссылаться множество PurchaseItems.	anyURI
PurchaseItemIDRef	E1	NO/TM	0..N	Ссылки на фрагменты PurchaseItem, которые принадлежат этому PurchaseItem по ссылке Примечание: к фрагменту PurchaseItem могут обращаться множество PurchaseItems. Примечание: глубина дерева PurchaseItem не ДОЛЖНА быть больше чем три.	anyURI

Таблица 8E
Название	E1	M	1..N	Название PurchaseItem, возможно на множестве языков. Этот язык выражен с использованием встроенного атрибута XML xml:lang с этим элементом.	Строка
Описание	E1	NO/TM	0..N	Описание пункта покупки возможно на множестве языков. Язык выражен с использованием встроенного атрибута XML xml:lang с этим элементом.	Строка
ParentalRating	E1	O	0..1	Уровень рейтинга, обозначающий критерии, которые родители могут использовать для определения, пригоден ли ассоциированный пункт для доступа детей, определенный в соответствии с требованиями законодательства в зоне обслуживания. Это определяет возрастной предел уровня рейтинга для услуги покупки, а не возрастной предел уровня рейтинга фактического потребления услуги.	Строка

Таблица 9A
Название	Тип	Кате-гория	Мощность связи	Описание	Тип данных
PurchaseD ataInfo	E	O	0..N	Фрагмент PurchaseData Содержит следующие атрибуты: id версия validFrom validTo. Содержит следующие подэлементы: ExtensionURL Описание PurchaseItemIDRef PurchaseChannelIDRef PriceInfo PreviwDatalDRef PromotionInfo
id	A	M	1	ID фрагмента PurchaseData, глобально уникальный	anyURI
version	A	M	1	Версия этого фрагмента. Более новая версия отменяет старую, сразу после ее приема.	целое без знака (32 бита)

Таблица 9B
validFrom	A	О	0..1	В первый момент, когда этот фрагмент является действительным. Если он не задан, предполагается, что действительность начинается в некоторый момент времени в прошлом.	Целое (32 бита) выражено как время NTP
validTo	A	O	0..1	В последний момент, когда этот фрагмент является действительным. Если он не задан, предполагается, что действительность заканчивается в неопределенное время в будущем.	Целое(32 бита) выражено как время NTP
URL расшире-ния	E1	О	0..N	URL, содержащий дополнительную информацию, относящуюся к этому фрагменту на веб-странице. Терминал может получить дополнительную информацию путем доступа к этому URL.	AnyURI
Описание	E1	NO/TM	0..N	Описание канала покупки возможно на множестве языков. Язык выражен с использованием встроенного атрибута XML xml:lang с этим элементом.	Строка
PurchaseItemIDRef	E1	M	1	PurchaseItem, к которому применяются эти PurchaseData.	anyURI

Таблица 9C
PurchaseC hannelIDRef	E1	M	1..N	PurchaseChannel, через который может быть получен идентифицированный PurchaseItem.	anyURI
PriceInfo	E1	M	1..N	Если стоимость не задана, она обговаривается с пользователем как часть транзакции при покупке. В этом случае фрагмент PurchaseData просто отражает, что определенный предмет покупки может быть куплен из этого PurchaseChannel. Содержит следующие подэлементы: SubscriptionUnit UnitText Стоимость
Subscriptio nUnit	E2	M	1	Описание модуля времени подписки Атрибуты: тип значение модуль

Таблица 9D
Тип	A	M	1	Тип подписки	Целое
Значение	A	M	1	Количество модулей	Целое
Модуль	A	M	1	Модуль времени	Целое
UnitText	E2	M	1..N	Модуль времени, в котором длительность выражена для пользователя, возможно на многих языках. Язык выражен с использованием встроенного атрибута XML xml:lang с этим элементом.	Строка
Стоимость	E2	M	0..N	Стоимость предмета покупки для определенной длительности Атрибуты: валюта значение

Таблица 9E
Валюта	A	M	1	Валюта стоимости	ISO 4217 Международные коды валюты
Значение	A	M	1	Значение в обозначенной валюте	Целое
PreviewDa taIDRef	E1	0	0..N	Ссылка на фрагмент PreviewData, который определяет уменьшенное изображение, пиктограмму, анимацию или звук. Атрибут: Использование.	anyURI
Исполь-зование	A	M	1	Возможные значения: фоновое, уменьшенное изображение (например).	Целое (8 битов)
PromotionInfo	E1	O	0..N	Информация рекламных действий/купонов, относящихся к PurchaseItem, содержит следующие атрибуты: id validFrom validTo Содержит следующие подэлементы: название TargetUserProfile Описание URL

Таблица 9F
Id	A	M	1	Идентификатор одной определенной PromotionInfo, уникальной для BSM. PromotionID может использоваться в процессе покупки для идентификации определенной рекламы.	целое без знака
validFrom	A	O	0..1	Начало достоверности; если не задано, предполагается, что действительность начинается в прошлом.	Целое (32 бита) выражено как время NTP
validTo	A	O	0..1	Окончание достоверности; если не задано, предполагается, что действительность заканчивается в отдаленный момент в будущем, и время окончания может быть указано позже, в результате обновления объекта.	Целое (32 бита), выраженное как время NTP
Title	E2	M	1	Название PromotionInfo	Строка
TargetUser Profile	E2	O	0..1	Профиль пользователей, на которых направлена услуга или содержание. Например, возраст, пол, профессия и так далее.

Таблица 9G
Описание	E2	NO/TM	0..1	Описание или пояснение PromotionInfo. Описание или URL, или они оба должны быть определены BSM, для предоставления подробной информации об этом PromotionInfo.	Строка
URL	E2	NO/TM	0..1	URL, содержащий подробную рекламную информацию (например, информацию о спонсорах купона, месте расположения сервера для покупок с использованием купонов). Либо описание, или URL, или они оба должны быть определены BSM, для предоставления подробной информации по этому PromotionInfo.	AnyURI

Таблица 10A
Название	Тип	Кате-гория	Мощность связи	Описание	Тип данных
PurchaseChannel	E	О	0..N	Фрагмент PurchaseChannel содержит следующие атрибуты: id версия validFrom validTo LocalFlag RightsIssuerURI Селектор Содержит следующие подэлементы: ExtensionURL Название PortalURL Описание Соединение ContactInfo.
id	A	M	1	ID фрагмента канала покупки, глобально уникальный	anyURI
version	A	M	1	Версия этого фрагмента. Более новая версия отменяет старую, сразу после ее приема.	целое без знака (32 бита)

Таблица 10B
validFrom	A	О	0..1	Первый момент, когда этот фрагмент действительный. Если не задан, предполагается, что действительность началась в некоторый момент времени в прошлом.	Целое (32 бита), выраженное как время NTP
validTo	A	О	0..1	В последний момент, когда действителен фрагмент действителен. Если не задано, предполагается, что действительность заканчивается в неопределенное время в будущем.	Целое (32 бита), выраженное как время NTP
LocalFlag	A	M	1	Если имеет значение true, обозначает, что BSM рекламирует информацию о доступности и покупке полностью в руководстве услуги.	Булево
RightsIssuerURI	A	NO/TO	1	ID издателя прав, ассоциированный с BSM (требуется, чтобы не соединенным устройствам было разрешено идентифицировать услугу RI, которой может оперировать их домашнее BSM).	AnyURI
				Если система защиты услуги или система защиты содержания основана на OMA DRM2.0, то ДОЛЖЕН быть указан RightsIssuerURI.

Таблица 10C
Селектор	A	M	1	Позволяет терминалу определять, какой канал покупки следует использовать вместе с каналами покупки, которые анонсируются в SG. Атрибуты: тип (например, возможное значение: "SIMCode") Примечание: канал покупки должен быть предоставлен провайдером услуг BCAST.	Строка
URL расширения	E1	О	0..N	URL, содержащий дополнительную информацию, относящуюся к этому фрагменту на веб-странице. Терминал может выбрать дополнительную информацию путем доступа к этому URL.	AnyURI
Название	E1	M	1..N	Название канала покупки возможно на множестве языков. Язык выражен с использованием встроенного атрибута XML xml:lang атрибута с этим элементом.	Строка

Таблица 10D
PortalURL	E1	О	0..1	URL для BSM, по которому могут быть выполнены все транзакции, связанные с покупкой.	AnyURI
Описание	E1	NO/TM	0..N	Описание канала покупки возможно на множестве языков. Язык выражен с использованием встроенного атрибута XML xml:lang с этим элементом.	Строка
Connection	E1	M	1..N	Позволяет терминалу, создать запрос на покупку и передавать его в канал покупки. В случае, когда множество вариантов соединения указаны, терминал сам выбирает, например, использовать ли IP (через GPRS), с SMS как вариант перехода на более низкую скорость. Содержит следующие подэлементы: PurchaseURL.

Таблица 10E
PurchaseURL	E2	M	1..N	URL, на который должен быть адресован запрос на покупку. Содержит следующий атрибут: Несущий канал.	AnyURI
Несущий канал	A	M	1	Несущий канал, поддерживающий этот канал покупки.	Целое
ContactInfo	E1	O	0..1	Текстовая строка, которая обозначает для пользователя, как войти в контакт с BSM для инициирования транзакции, связанной с покупкой, выходящей за пределы полосы пропускания (например, номер телефона, URL и так далее).	Строка

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

Сообщение, передаваемое через NT-4, может быть передано в текстовой или XML форме. Соответствующее сообщение будет подробно описано со ссылкой на фиг.9 или 10. Сообщение через NT-4 передают с использованием IP, TCP и HTTP, и NTDA в BSD/A может запрашивать генерирование сообщения уведомления путем передачи сообщения о событии, требующем уведомления, в NTG в BSM через HTTP POST. В ответ на сообщение о событии, требующем уведомления, NTG в BSM генерирует уведомление и передает это сообщение уведомления в NTDA, запрашивая, таким образом, доставку сообщения уведомления в терминал. Кроме того, после приема сообщения о событии, требующем уведомления, NTG может передавать результат запроса о событии, требующем уведомления, в NTDA вместе с сообщением HTTP RESPONSE, или может передавать полученное в результате сообщение через HTTP POST.

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

На этапе 903 NTG 901 передает сообщение запроса на доставку в NTDA 902 для запроса доставки сообщения уведомления в терминал. Примерный запрос на доставку (NTDReq), на этапе 903, представлен в таблицах 11A и 11B. Когда генерируют сообщение запроса на доставку, представленного в таблицах 11A и 11B, для сообщения уведомления, фактическое сообщение уведомления прикрепляется к сообщению запроса на доставку с использованием кодирования MIME перед его доставкой. В связи с соответствующим сообщением уведомления, NTG 901 определяет приоритет, обозначающий приоритет доставки, и целевой адрес, на который он будет доставлять сообщение уведомления, и доставляет сообщение запроса на доставку в NTDA 902. NTDA 902 проверяет соответствующий атрибут для сообщения уведомления, доставляет сообщение уведомления в соответствии с приоритетом и также доставляет сообщение уведомления пользователю в соответствии с целевым адресом. В соответствии с TargetAddress (целевым адресом) сообщение уведомления доставляют пользователю, использующему определенную услугу через AccessID, соединенный с соответствующей услугой, и оно также быть может доставлено множеству пользователей с использованием определенного многоадресного IP-адреса.

BSD/A может принимать AccessID или многоадресный IP-адрес из BSM через NTDA или SG-G. На этапе 904 NTDA 902 доставляет сообщение уведомления, принятое из NTG 901, в терминал через доступный BDS и затем передает сообщение, обозначающее окончание доставки сообщения уведомления в NTG 901. Когда сообщение уведомления доставляется немедленно, NTDA 902 может передать сообщение результата, обозначающее окончание доставки сообщения уведомления, вместе с сообщением запроса HTTP в ответ на сообщение запроса, принятое на этапе 903. В противном случае, если требуется время для доставки сообщения уведомления, NTDA 902 может закрыть сеанс для NTG 901 и затем доставляет сообщение о результате, обозначающее окончание доставки сообщения уведомления, в NTG 901, используя NTDReqId и BSMAddress для сообщения NTDReq, принятого на этапе 903, и HTTP POST в момент времени окончания доставки сообщения уведомления. Подробно полученные в результате сообщения представлены в таблице 12, приведенной ниже.

Таблица 11A
Название	Тип	Категория	Мощностьсвязи	Описание	Тип данных
NTDReq	E			Запрашивает доставку сообщения запроса для сообщения уведомления из NTG в NTDA. Содержит следующие элементы: NTDId BSMAddress
NTDReqId	A	M	1	Идентификатор NTDReq	Целое без знака (32 бита)
BSMAddress	A	M	1	BSM Адрес для приема ответа на этот запрос.	AnyURI
NotificationId	A	M	1	Идентификатор ID сообщения уведомления, сгенерированный NTG.	AnyURI

Таблица 11B
Приоритет	A	M	1	Определяет приоритет доставки сообщения уведомления. Если Приоритет = 0, это означает высокий приоритет. Если Приоритет = 1, это означает общее сообщение.	Булево
TargetAddress	A	O	0..1	TargetAddress для доставки сообщения уведомления. Если не указан, сообщение уведомления ДОЛЖНО быть доставлено всем пользователям, с использованием SGSS. Если TargetAddress указан с AccessID или с конкретным адресом, сообщение уведомления ДОЛЖНО быть доставлено конкретному пользователю, который связан с этим AccessID или конкретным адресом.	AnyURI
Сообщение уведомления	E1	M	1	Тип MIME. Сообщение уведомления ДОЛЖНО быть внедрено в этот элемент.

Таблица 12
Название	Тип	Кате-гория	Мощность связи	Описание	Тип данных
NTDRes	E			Определяет ответное сообщение на NTDReq. Содержит следующие элементы: NTDReqId.
NTDReqId	E1	M	0..N	Идентификатор NTDReq содержит следующие атрибуты: Ответ	Целое без знака (32 бита)
Ответ	A	M	1	Определяет результат, как NTDReq обрабатывается в BSDA. Если Response=0, доставляют сообщение уведомления. Если Response=1, доставка сообщения уведомления не происходит, и требуется повторная передача.	Целое (8 битов)

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

На этапе 1003 NTDA 1002 передает сообщение, запрашивающее генерирование сообщения уведомления, то есть сообщение о событии, требующем уведомления, в NTG 1001. Примерное сообщение о событии, требующем уведомления, доставляемое в NTG 1001 на этапе 1003, представлено в таблицах 13А-13I, приведенных ниже. Событие, требующее уведомления, генерируемое в NTDA 1002, соответствует событию, возникающему в системе распространения широковещательной передачи (BDS) или NTDA 1002. На этапе 1004 NTG 1001 генерирует сообщение уведомления на основе информации о событии, требующем уведомления, принимаемой из NTDA 1002, и передает ответное сообщение, обозначающее конец генерирования сообщения уведомления в NTDA 1002. Если сообщение уведомления будет немедленно сгенерировано в NTDA 1002 и затем доставлено в NTG 1001, NTG 1001 может передать полученное в результате сообщение вместе с ответным сообщением HTTP, в ответ на сообщение запроса, принятое на этапе 1003. В противном случае, если требуется время для генерирования сообщения уведомления, NTG 1001 может закрыть сеанс для NTDA 1002 и затем передать полученное в результате сообщение в NTDA 1002, используя NTDAEReqId и BSAAddress сообщения NTDAEReq, принятого на этапе 1003 и HTTP POST во время окончания генерирования сообщения уведомления. Подробно полученные результаты сообщения представлены в таблице 14, приведенной ниже.

Таблица 13A
Название	Тип	Кате-гория	Мощность связи	Описание	Тип данных
NTDAEReq	E			Определяет сообщение запроса события, требующего уведомления, из NTDA в NTG. Содержит следующие элементы: NTDAEReqId BSAAddress
NTDAEReqId	A	M	1	Идентификатор события, требующего уведомления, из BSD/A	Целое без знака (32 бита)
BSDAAddress	A	M	1	Адрес BSDA для приема ответа на этот запрос.	AnyURI
NotificationEvent	E1	M	1..N	Определяет событие, требующее уведомления, из CC. Содержит следующие атрибуты: Приоритет TargetAddress NotificationType Достоверность Содержит следующие элементы: Название Описание Приоритет ExtensionURL SessionInformation MediaInformation

Таблица 13B
Приоритет	A	M	1	Определяет приоритет доставки сообщения уведомления. Если Приоритет = 0, это означает высокий приоритет. Если Приоритет = 1, это означает общее сообщение. Эти элементы будут использоваться при генерировании NTDReq.	Булево
TargetAddress	A	О	0..1	TargetAddress для доставки сообщения уведомления. Если не определен, сообщение уведомления ДОЛЖНО быть доставлено всем пользователям с использованием SGDD. Если TargetAddress определен с AccessID или конкретным адресом, сообщение уведомления ДОЛЖНО быть доставлено определенному пользователю, связанному с AccessID или конкретным адресом. Эти элементы будут использоваться при генерировании NTDReq.	AnyURI

Таблица 13C
NotificationType	A	M	1	Тип уведомления: Если NotificationType=0, это сообщение представляет собой сообщение, ориентированное на пользователя, такое как уведомление из SP, мультимедийное сообщение, срочное сообщение и так далее. Если NotificationType=1, это сообщение представляет собой сообщение, ориентированное на терминал, такое как начало услуги или загрузка файла и так далее. Другой NotificationType может быть определен в соответствии с провайдерами услуги, операторами или для операторов, осуществляющих широковещательную передачу.	Целое
Validity	A	O	0..1	Время действительности фрагмента сообщения уведомления. Если действительность указана, действительность сообщения уведомления истекает в заданный момент времени.	Целое (32 бита), выраженное как время NTP

Таблица 13D
Название	E2	O	0..N	Название или титул сообщения уведомления возможно на множестве языков. Язык выражен с использованием встроенного атрибута XML xml:lang с этим элементом.	Строка
Описание	E2	О	0..N	Описание или сообщения уведомления, возможно на множестве языков, язык выражен с использованием встроенного атрибута XML, xml:lang с этим элементом.	Строка
Приоритет	E2	M	1	Определяет приоритет этого события, требующего уведомления. Эта информация применяется для генерирования типа представления сообщения уведомления.	Целое
URL расширения	E2	О	0..N	URL, содержащий дополнительную информацию, относящуюся к сообщению уведомления.	AnyURI

Таблица 13E
SessionInf ormation	E2	O	0..N	Определяет информацию сеанса доставки, информацию цели или фрагментов, доставляемых через обозначенный сеанс, и URI, как альтернативный способ доставки. После приема сообщения уведомления с SessionInformation терминал обращается к соответствующему сеансу, определенному по SessionInformation и предпринимает соответствующее действие, такое как прием содержания. Содержит следующие атрибуты: ValidFrom ValidTo UsageType Содержит следующие элементы: DeliverySession TransportObjectID AlternativeURI
ValidFrom	A	О	0..1	Первый момент, когда сеанс для терминала, для приема данных является действительным.	Целое (32 бита), выраженное как время NTP
ValidTo	A	O	0..1	В последний момент, когда сеанс для терминала, для приема данных является действительным.	Целое (32 бита), выраженное как время NTP

Таблица 13F
UsageType	A	О	0..1	Определяет тип объекта, переданного через обозначенный сеанс доставки. Если UsageType=0, обозначенный сеанс доставки будет использоваться для доставки файла. Если UsageType=1, услуга может начаться через обозначенный сеанс доставки по плану. Другой PresentationType может быть определен в соответствии с провайдерами услуги, операторами, или для операторов широковещательной передачи.	Целое
DeliverySession	E3	О	0..1	Информация сеанса целевой доставки обозначена с помощью сообщения уведомления. Содержит следующие атрибуты: SourceIP TransportSessionID
SourceIP	A	M	1	Адрес IP-источника сеанса доставки	Строка

Таблица 13G
TransportsessionID	A	M	1	Идентификатор сеанса целевой доставки	Короткое без знака (16 битов)
TransportObjectID	E3	O	0..N	ID объекта транспортирования (TOI, ИДТ) для объекта, передаваемого через обозначенный сеанс доставки, включающий в себя следующие элементы фрагмента.	Короткое целое (32 бита)
Alternative URI	E3	O	0..1	Альтернативный URI для приема объекта через канал взаимодействия. Если терминал не может обратиться к обозначенному сеансу доставки, терминал может быть принят через объект, ассоциированный с сеансом уведомления с использованием альтернативного URI.	AnyURI
MediaInformation	E2	О	0..1	Мультимедийная информация, которая требуется для построения мультимедийных сообщений уведомлений. Содержит следующие элементы: Изображение Видеоданные Аудиоданные

Таблица 13H
Изображение	E3	О	0..N	Определяет, как получают изображение и тип MIME. Содержит следующие элементы: MIMEtype PictureURI
MIMEtype	A	О	0..1	Тип MIME видеоизображения.	строка
PictureURI	A	О	0..1	URI, ссылающийся на изображение.	AnyURI
Видео	E3	О	0..N	Определяет, как получить видеоданные и тип MIME. Содержит следующие элементы: MIMEtype VideoURI
MIMEtype	A	О	0..1	Тип MIME видеоданных.	Строка
VideoURI	A	О	0..1	URI, ссылающийся на видеоданные.	AnyURI

Таблица 13I
Аудио	E3	О	0..N	Определяет, как получить аудиоданные и тип MIME. Содержит следующие элементы: MIMEtype AudioURI
MIMEtype	A	O	0..1	Тип MIME аудиоданных	Строка
AudioURI	A	О	0..1	URI, ссылающийся на аудиоданные	AnyURI

Таблица 14
Название	Тип	Кате-гория	Мощность связи	Описание	Тип данных
NTDAERes	E			Определяет ответное сообщение для NTDAEReq. Содержит следующие элементы: NTDAEReqId
NTDAEId	E1	M	0..N	Идентификатор NTDAEReq содержит следующие атрибуты: Ответ	Целое без знака (32 бита)
Ответ	A	M	1	Определяет результат того, как NTDAEReq обрабатывается в BSM. Если Response=0, сообщение уведомления генерируют и передают в NTD/A. Если Response=1, генерирование сообщения уведомления не происходит, и запрашивается повторная передача.	Целое (8 битов)

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

Для доставки сообщения через интерфейс 1201 SG-4 или NT-4 сообщение может быть доставлено непосредственно в HTTP, как показано на фиг.6 или 8. Кроме того, как показано на фиг.12, соответствующее сообщение запроса может быть передано с использованием протокола сетевой услуги для передачи данных XML, такого как Простой протокол доступа к объектам (SOAP, ППДО), Расширяемый язык разметки вызов удаленной процедуры (XML-RPC, РЯР-ВУП) и Расширяемый протокол обмена блоками (BEEP). Номерами 1203-1209 ссылочных позиций на фиг.12 обозначена иерархическая структура, включающая в себя IP, TCP, HTTP и Протокол сетевой услуги.

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

Как показано на фиг.13, на этапе 1311 SGSS 1301 передает сообщение запроса на доставку источника руководства услуги, определенного в таблице 15, в SG-G 1302. На этапе 1312, после приема источника руководства услуги через сообщение запроса, SG-G 1302 передает ответное сообщение, показанное в таблице 16, приведенной ниже, включающее в себя результат обработки источника руководства услуги в SGSS 1301.

Таблица 15
Название	Тип	Кате-гория	Мощность связи	Описание	Тип данных
SGSDelivery				Определяет сообщение доставки источника руководства услуги, который используется для генерирования руководства услуги в SG-G. Содержит следующие атрибуты: Id EntityAddress Содержит следующие элементы: SGData.
SGSDid	A	M	1	Идентификатор SGSDelivery, уникальный в сетевом объекте, который генерирует это сообщение.	Целое без знака (32 бита)
EntityAddress	A	M	1	Адрес сетевого объекта, который генерирует это сообщение и принимает ответ.	anyURI
SGData	E1	О	0..1	Содержит информацию из функции формирования содержания, которая должна быть включена в руководство услуги. РЕКОМЕНДУЕТСЯ, чтобы информация была доставлена в форме фрагментов руководства услуги BCAST. МОГУТ использоваться другие форматы. Если используются фрагменты руководства услуги BCAST, обязательные сетевые элементы или атрибуты, которые не соответствуют, ДОЛЖНЫ быть доставлены как пустое поле, необязательные сетевые элементы, или атрибуты, которые не соответствуют, НЕ ДОЛЖНЫ быть представлены для обработки. Содержит атрибут: Namespace.
namespace	A	O	0..1	Установлен для названия Namespace XML руководства услуги BCAST, для передачи сигнала о том, что содержание SGData соответствует SG BCAST.

Таблица 16
Название	Тип	Кате-гория	Мощность связи	Описание	Тип данных
SGSDRes				Определяет Ответное сообщение на SGSDelivery. Содержит следующие элементы: SGSDid.
SGSDid	E1	M	1..N	Идентификатор сообщения SGSDelivery. Содержит следующие атрибуты: StatusCode.	Целое без знака (32 бита)
StatusCode	A	M	1	Обозначает общий результат того, как обрабатывается SGSDelivery, в соответствии с глобальным кодом состояния.	байт без знака

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

На этапе 1411 NTG 1401 доставляет сообщение уведомления, определенное в таблице 17A и в таблице 17B для NTDA 1402. Соответствующее сообщение уведомления, доставленное в NTDA 1402 на этапе 1411, доставляют по соответствующему TargetAddress через канал широковещательной передачи или канал взаимодействия через NTDA 1402. После передачи сообщения уведомления в TargetAddress NTDA 1402 передает на этапе 1412 результат обработки по событию уведомления в NTG 1401, используя ответное сообщение, определенное в таблице 18.

Таблица 17A
Название	Тип	Катего-рия	Мощность связи	Описание	Тип данных
NTDReq	E			Определяет сообщение запроса для доставки сообещения уведомления из NTG в NTDA. Содержит следующие атрибуты: NTDReqId BSMAddress DeliveryPriority Содержит следующие элементы: TargetAddress NotificationMessage
NTDReqId	A	M	1	Идентификатор NTDReq	Целое без знака (32 бита)
EntityAd dress	A	M	1	Адрес сетевого объекта для приема ответа на этот запрос.	anyURI
Приоритет доставки	A	O	0..1	Определяет приоритет доставки этого сообщения уведомления. NTG может запрашивать NTDA на доставку этого сообщения уведомления с высоким приоритетом. Если приоритет = TRUE, это означает высокий приоритет. Если приоритет = FALSE, это означает общее сообщение.	Булево
TargetAddress	E1	O	0..N	Определяет TargetAddress для доставки сообщения уведомления. Для уведомления, специфичного для услуги AccessID или IP-адреса в соответствии с NotificationReception в AccessFragment может иметь возможное значение. Если сообщение уведомления должно быть доставлено через канал взаимодействия, его значение может представлять собой адрес электронной почты, IMSI и так далее. Если не задано, сообщение уведомления должно быть доставлено всем пользователям, с использованием SGDD. Содержит следующий атрибут.	Строка

Таблица 17B
Канал доставки	A	M	1	Определяет канал доставки. Если TRUE, сообщение уведомления ДОЛЖНО быть доставлено через канал широковещательной передачи Если FALSE, сообщение уведомления ДОЛЖНО быть доставлено через канал взаимодействия.	Булево
				Определяет тип TargetAddress Значение
Тип адреса	A	M	1	0-IPAddress, 2-люблой URI 3-IMSI 4-200: Для будущего использования 201-255: Для частного использования.	байт без знака
Notification Message	E1	M	1	Определяет сообщение уведомления, содержащее информацию, которая должна быть включена в сообщение- уведомление. РЕКОМЕНДУЕТСЯ, чтобы информация была доставлена в форме формата уведомления BCAST. Другие форматы МОЖНО использовать. Если используется формат сообщения уведомления BCAST, обязательны сетевые элементы, или атрибуты, которые не являются соответствующими, должны быть доставлены как пустые поля, необязательные сетевые элементы или атрибуты, которые не являются существенными, НЕ ДОЛЖНЫ подвергаться обработке. Содержит атрибут: Namespace
Namespace	A	O	0..1	Установить для названия XML уведомления BCAST namespace для сигнализации о том, что содержание NotificationEvent соответствует формату сообщения уведомления BCAST.	anyURI

Таблица 18
Название	Тип	Кате-гория	Мощность связи	Описание	Тип данных
NTDRes	E			Определяет ответное сообщение для NTDReq. Содержит следующие элементы: NTDReqId
NTDReq Id	E1	M	1..N	Идентификатор NTDReq Содержит следующие атрибуты: StatusCode	Целое без знака (32 бита)
StatusCo de	A	M	1	Обозначает общий результат того, как NTDReq обрабатывается в соответствии с глобальным кодом статуса.	Байт без знака

В таблице 19A - таблице 19E, приведенных ниже, представлены примерные значения кода, обозначающие результаты обработки события, требующего уведомления, включенные в ответное сообщение, определенное в таблице 18. Если требование сообщения уведомления было хорошо обработано, значение кода ответного сообщения устанавливается равным "000", и NTG может распознать, что это требование было обработано, путем проверки соответствующего значения кода.

В таблице 19A - таблице 19B, приведенных ниже, показаны коды глобального состояния, используемые как значения кода, и они сохранены в NTG и NTDA для будущего использования. Дополнительные коды могут быть определены в соответствии с назначением провайдера услуг. Также возможно сохранить значения кода в терминале для будущего использования. Эти коды можно использовать для уведомления результата через значение кода StatusCode, когда существует потребность передачи не только нового ответного сообщения, но также и результатов обработки мобильной системы широковещательной передачи или мобильного терминала. Кроме того, поле ответа в таблице 14 также можно использовать таким же образом, как и значения кода.

Таблица 19A
Код	Статус
000	Успех Запрос был обработан успешно.
001	Неудачная аутентификация устройства Этот код обозначает, что BSM не смог аутентифицировать устройство, что может произойти вследствие того, что пользователь или устройство не зарегистрированы в BSM. В этом случае, пользователь может связаться с BSM и заключить контракт, или получить регистрационные данные вместо тех, которые использовались для аутентификации.
002 2	Неудачная аутентификация пользователя Этот код обозначает, что BSM не смог аутентифицировать пользователя, что может быть связано с тем, что пользователь или устройство не зарегистрированы в BSM. В этом случае, пользователь может связаться с BSM и заключить контракт или получить новые идентификационные данные вместо использовавшихся для аутентификации.
003 3	Предмет покупки неизвестен Этот код обозначает, что запрашиваемый пункт услуги является неизвестным. Это может случиться, например, если устройство разместило в кэше руководство услуги вместе со старой информацией. В этом случае, пользователь может повторно получить руководство услуги.
004	Неудачная авторизация устройства Этот код обозначает, что устройство не авторизовано для получения ключевых сообщений длительного срока действия из RI, например, из-за того, что был отозван сертификат устройства. В этом случае, пользователь может связаться с оператором BSM.
005	Неудачная авторизация пользователя Этот код обозначает, что пользователь не авторизован для получения ключевых сообщений длительного срока действия из RI, например, в связи с тем, что сертификат устройства был отозван. В этом случае, пользователь может связаться с оператором BSM.

Таблица 19B
006	Устройство не зарегистрировано Этот код обозначает, что устройство не зарегистрировано d RI, который используется для транзакции. Когда передан этот код, ответное сообщение включает в себя триггер регистрации, который позволяет устройству зарегистрироваться. В этом случае, устройство может автоматически выполнить регистрацию и, если эта регистрация будет успешной, повторно инициировать исходную транзакцию.
007	Ошибка сервера
Этот код обозначает, что возникла ошибка сервера, такая как проблема, связанная с удаленной серверной системой. В таком случае транзакция может быть успешно проведена, если она будет повторно инициирована позже.
008	Ошибка неправильно сформированного сообщения
Этот код обозначает, что возникла ошибка в устройстве, такая как неправильно сформированный запрос XML. В таком случае транзакция может быть, или может не быть успешно проведена (например, если имеется проблема, связанная со взаимодействием), если она будет повторно инициирована позже.
009	Ошибка, связанная с начислением счета
Этот код обозначает, что произошла ошибка на этапе начисления счета (например, был достигнут согласованный лимита, счет заблокирован), и поэтому запрашиваемое ключевое сообщение длительного срока действия не может быть предоставлено. Пользователь в таком случае может связаться с оператором BSM.
010	Отсутствие подписки
Этот код обозначает, что подписка для этого пункта услуги никогда не была оформлена, или что подписка на этот пункт была прекращена. Пользователь может в таком случае подать запрос на услугу для оформления новой подписки.

Таблица 19C
011	Операция не разрешена Этот код обозначает, что операция, которую попыталось выполнить устройство, не разрешена в соответствии с контрактом между BSM и пользователем. Пользователь может в этом случае связаться с оператором BSM и изменить контракт.
012	Неподдерживаемая версия Этот код обозначает, что номер версии, указанный в сообщении запроса, не поддерживается сетью. В этом случае пользователь может связаться с оператором BSM.
013	Нелегальное устройство Этот код обозначает, что устройство, запрашивающее услугу, является не приемлемым для BSM. Например, помещено в черный список. В этом случае пользователь может связаться с оператором BSM.
014	Область обслуживания не разрешена Этот код обозначает, что не разрешено обслуживание устройства в запрашиваемой области, из-за ограничений подписки. В этом случае пользователь может связаться с оператором BSM или подписаться на приемлемую услугу.
015	Запрашиваемая услуга недоступна. Этот код обозначает, что запрашиваемая услуга является недоступной из-за проблем с передачей. В этом случае запрос может быть повторно инициирован в более позднее время.

Таблица 19D
016	Запрос уже обработан Этот код обозначает, что идентичный запрос был ранее обработан. В этом случае пользователь или объект может проверить, был ли запрос уже обработан (то есть, принят LTK), если не так, повторить запрос.
017	Информационный элемент не существует Этот код обозначает, что сообщение включает в себя информационный элементы, не распознанные из-за того, что идентификатор информационного элемента не определен или он определен, но не воплощен объектом, принимающим сообщение. В этом случае соответствующие объекты должны связаться друг с другом.
018	Не определен Этот код обозначает, что возникла ошибка, которая не может быть идентифицирована. В этом случае соответствующие объекты должны связаться друг с другом.
019	Процесс задержан Из-за большой нагрузки, запрос помещен в очередь, ожидая обработки. В этом случае пользователь или объект должны подождать завершения транзакции.
020	Ошибка генерирования Этот код обозначает, что информация (сообщение) запроса не может быть сгенерирована. В этом случае пользователь или объект должен еще раз попробовать позже.

Таблица 19E
021	Информация недействительна Этот код обозначает, что приведенная информация является недействительной и не может быть использована системой. В этом случае запрос должен быть повторно проверен и снова отправлен.
022	Неправильный запрос Этот код обозначает, что запрашиваемые ключевые материалы и сообщения (например, LTKM), не являются действительными и не могут быть выполнены. В этом случае запрос должен быть повторно проверен и снова отправлен.
023	Неправильное место назначения Этот код обозначает, что место назначения сообщения не является предполагаемым местом назначения. В этом случае запрос необходимо повторно проверить и снова отправить.
024	Доставка неправильной ключевой информации Этот код обозначает, что доставленная ключевая информация и сообщения (например, LTKM) являются недействительными. В этом случае запрос следует повторно проверить и снова отправить.
025~127	Зарезервировано для будущего использования
128~255	Зарезервировано для частного использования

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

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

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

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

2. Способ по п.1, в котором сообщение уведомления о событии включает в себя информацию адреса сетевого объекта, принимающего ответное сообщение.

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

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

5. Способ по п.1, в котором мобильная система широковещательной передачи включает в себя систему мобильного широковещания «Browser and Content» Открытого Мобильного Альянса (ОМА ВАС BCAST).

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

7. Способ по п.6, в котором обмен сообщением уведомления о событии и ответным сообщением выполняют с использованием протокола HTTP POST.

8. Способ по п.5, в котором первое устройство включает в себя функцию формирования уведомления (NTG) управления подпиской BCAST (BSM), и второе устройство включает в себя функцию рассылки и настройки уведомления (NTDA) при рассылке/настройке услуги BCAST (BSD/A).

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

10. Мобильная система широковещательной передачи по п.9, в которой сообщение уведомления о событии включает в себя информацию адреса сетевого объекта, принимающего ответное сообщение.

11. Мобильная система широковещательной передачи по п.9, в которой первое устройство закрывает сеанс со вторым устройством перед формированием сообщения уведомления.

12. Мобильная система широковещательной передачи по п.9, в которой множество из, по меньшей мере, одного первого устройства и второго устройства существует для каждого индивидуального провайдера услуг.

13. Мобильная система широковещательной передачи по п.9, в которой мобильная система широковещательной передачи включает в себя систему мобильного широковещания «Browser and Content» Открытого Мобильного Альянса (ОМА ВАС BCAST).

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

15. Мобильная система широковещательной передачи по п.14, в которой обмен сообщением уведомления о событии и ответным сообщением выполняют с использованием протокола HTTP POST.

16. Мобильная система широковещательной передачи по п.13, в которой первое устройство включает в себя функцию формирования уведомления (NTG) управления подпиской BCAST (BSM), и второе устройство включает в себя функцию рассылки и настройки уведомления (NTDA) в рассылке/настройке услуги BCAST (BSD/A).

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

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

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

20. Способ по п.17, в котором мобильная система широковещательной передачи включает в себя браузер Открытого союза мобильной связи и мобильной широковещательной передачи содержания (ОМА BCAST) систему мобильного широковещания «Browser and Content» Открытого Мобильного Альянса (ОМА ВАС BCAST).

21. Способ по п.20, в котором первое и второе устройства выполняют обмен сообщением уведомления о событии и ответным сообщением, используя внутренний интерфейс.

22. Способ по п.21, в котором обмен сообщением уведомления о событии и ответным сообщением выполняют с использованием протокола HTTP POST.

23. Способ по п.20, в котором первое устройство включает в себя функцию формирования уведомления (NTG) управления подпиской BCAST (BSM), и второе устройство включает в себя функцию распределения уведомления (NTDA) в рассылке/настройке услуги BCAST (BSD/A).

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

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

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

27. Мобильная система широковещательной передачи по п.24, в которой мобильная система широковещательной передачи включает в себя систему мобильного широковещания «Browser and Content» Открытого Мобильного Альянса (ОМА ВАС BCAST).

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

29. Мобильная система широковещательной передачи по п.28, в которой обмен сообщением уведомления о событии и ответным сообщением осуществляют с использованием протокола HTTP POST.

30. Мобильная система широковещательной передачи по п.29, в которой первое устройство включает в себя функцию формирования уведомления (NTG) управления подпиской BCAST (BSM), и второе устройство включает в себя функцию рассылки и настройки уведомления (NTDA) в рассылке/настройке услуги BCAST (BSD/A).