RU2327300C2

RU2327300C2 - Система и способ передачи системных сообщений в протоколе инициирования сеанса связи (sip)

Info

Publication number: RU2327300C2
Application number: RU2006129247A
Authority: RU
Inventors: Паттан Дж. БАСАВАРАДЖ (IN); Паттан Дж. БАСАВАРАДЖ; Рагхавендран РАДХИКА (IN); Рагхавендран РАДХИКА
Original assignee: Самсунг Электроникс Ко., Лтд.
Priority date: 2005-08-12
Filing date: 2006-08-11
Publication date: 2008-06-20
Also published as: US9043394B2; TW200711424A; EP1753201A3; EP1753201A2; AU2006203487B2; EP2822249A3; AU2006203487A1; CN1972302A; JP4728193B2; CN1972302B; EP1753201B1; EP2822249A2; RU2006129247A; KR101075768B1; JP2007052784A; KR20070101194A; IL177472A0; EP2822249B1; US20150256628A1; TWI337490B

Abstract

Изобретение относится к системам связи. Технический результат заключается в повышении удобства обслуживания пользователя. Предложены система и способ осуществления обмена системными сообщениями по протоколу SIP путем введения в существующую структуру протокола SIP нового информационного содержимого в виде "тела" MIME и нового дескриптора признака для передачи конкретной служебной информации и получения ответа от пользователя. Системные сообщения могут содержать перечень возможных вариантов выбора и требовать наличия ответа от пользователя. 11 з.п. ф-лы, 5 ил., 10 табл.

Description

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

Настоящее изобретение относится, в общем случае, к технологии протокола инициирования сеанса связи (SIP) и, в частности, к способу передачи системных сообщений различным абонентам услуг, основанных на протоколе SIP, например услуги мгновенного обмена сообщениями (IM), услуги предоставления функции "нажми и говори по сотовому телефону" (Push-to-Talk Over Cellular (PoC)), услуги передачи мультимедийных сообщений (MMS) и любых иных услуг, основанных на протоколе SIP, которые организованы поставщиком услуг.

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

Протокол SIP представляет собой протокол инициирования сеанса связи, предназначенный для управления сеансом связи для передачи мультимедийной информации через сеть Интернет, в том числе, способом "MESSAGE" (передачи сообщения), способом на основе протокола "Message Session Relay Protocol (MSRP)" (протокола передачи сообщений в сеансе связи) и способом "SIP INFO" (информирования по протоколу SIP), но эти примеры не являются ограничивающим признаком,.

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

Ниже приведено описание способа "MESSAGE", способа на основе протокола MSRP и способа "SIP INFO".

СПОСОБ "MESSAGE" - РАСШИРЕНИЕ ПРОТОКОЛА SIP СОГЛАСНО ЗАПРОСУ НА КОММЕНТАРИИ № 3428 (RFC 3428))

Способ "MESSAGE". В документе (ссылка: Запрос на комментарии № 3428 (RFC 3428), "Session Initiation Protocol (SIP) Extension for Instant Messaging", B. Campbell, Ed., et. al., RFC 3428, December 2002) изложен способ "MESSAGE", который представляет собой расширение протокола SIP (ссылка: Запрос на комментарии № 3261 (RFC 3261), "SIP: Session Initiation Protocol", J. Rosenberg, et. al., RFC 3261, June 2002), обеспечивающее возможность передачи мгновенных сообщений. Запрос MESSAGE представляет собой расширение протокола SIP, следовательно, он наследует все признаки маршрутизации запроса и средств обеспечения безопасности протокола SIP. Запросы MESSAGE являются носителями находящегося в них содержимого в виде частей "тела" многоцелевого расширения электронной почты в сети Интернет (MIME). Запросы MESSAGE сами по себе не создают диалог протокола SIP. Каждое мгновенное сообщение обычно является отдельным, во многом, подобно сообщениям пейджера. Запросы MESSAGE могут быть переданы в контексте диалога, созданного иным запросом протокола SIP.

СПОСОБ НА ОСНОВЕ ПРОТОКОЛА MSRP

Протокол "Message Session Relay Protocol (MSRP)" (протокол передачи сообщений в сеансе связи) (ссылка, "The Message Session Relay Protocol", B. Campbell, Ed., et. al., draft-ietf-simple-message-sessions)) представляет собой протокол для передачи последовательности связанных мгновенных сообщений во время сеанса связи. Протокол MSRP представляет собой текстовый протокол на основе соединений, предназначенный для обмена произвольным или двоичным содержимым MIME, в частности, мгновенными сообщениями.

СПОСОБ "SIP INFO" - ЗАПРОС НА КОММЕНТАРИИ № 2976 (RFC 2976)

Способ "SIP INFO" (ссылка: запрос на комментарии № 2976 (RFC 2976), "The SIP INFO Method", S. Donovan, RFC 2976, October 2000) обеспечивает возможность транспортировки управляющей информации, связанной с сеансом связи, генерация которой осуществлена во время сеанса связи.

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

Согласно еще одному объекту настоящего изобретения, предложен способ передачи системных сообщений, применимый для способа "MESSAGE" (передачи сообщения), способа "MSRP SEND" (передачи по протоколу MSRP) и способа "SIP INFO" (информирования по протоколу SIP).

Согласно одному из объектов настоящего изобретения для реализации вышеупомянутых и иных объектов, предложен способ передачи системных сообщений по протоколу SIP, содержащий следующие операции, выполняемые сервером: вводят дескриптор признака, указывающий наличие системных сообщений, в заголовок сообщения протокола SIP и тип информационного содержимого многоцелевых расширений электронной почты в сети Интернет (MIME), указывающий факт включения информационного содержимого, связанного с системным сообщением, в "тело" сообщения, и являющийся носителем документа с запросом в виде системного сообщения на расширяемом языке гипертекстовой разметки (XML), содержащего в "теле" сообщения информационное содержимое, связанное с системным сообщением, посредством чего создают запрос в виде системных сообщений, соответствующий текущей ситуации, для его передачи клиенту; и следующие операции, выполняемые клиентом: принимают запрос в виде системного сообщения, добавляют дескриптор признака и тип информационного содержимого MIME в заголовок сообщения протокола SIP в соответствии с принятым запросом в виде системного сообщения, и, таким образом, создают ответ в виде системных сообщений, являющийся носителем документа с ответом на системное сообщение на расширяемом языке гипертекстовой разметки (XML), информационное содержимое которого связанно с ответом на запрос в виде системного сообщения, в "теле" сообщения, для передачи в сервер.

А передачу запроса в виде системного сообщения и ответа на системное сообщение осуществляют способом "MESSAGE", способом "MSRP SEND", способом "SIP INFO" или иным надлежащим способом, предусмотренным протоколом SIP.

В предпочтительном варианте транспортировка дескриптора признака может быть осуществлена в поле Accept-Contact ("одобрить контакт") заголовка сообщения протокола SIP, а транспортировку типа информационного содержимого MIME осуществляют в поле Content-Type ("тип информационного содержимого").

В предпочтительном варианте дескриптор признака может представлять собой дескриптор "+g.application.smsg", а типом информационного содержимого MIME может являться "vnd.example.system-message+xml".

Преимущественно, документ запроса в виде системного сообщения на расширяемом языке гипертекстовой разметки (XML) может начинаться с корневого элемента <system-message> (<системное-сообщение>), а документ запроса в виде системного сообщения на языке XTML содержит элемент <smsg-type> (<тип-системного-сообщения>), который указывает, что системное сообщение является запросом в виде системного сообщения или ответом на системное сообщение, элемент <smsg> (<системное сообщение>), который содержит уникальный идентификационный номер для установления соответствия между ответом на системное сообщение и запросом в виде системного сообщения, элемент <smsg-text> (<текст-системного-сообщения>), который содержит информацию, предназначенную для передачи клиенту, элемент <smsg-response-type> (<тип-ответа-на-системное-сообщение>), который указывает пользователю тип ответа, требуемый от клиента согласно запросу в виде системного сообщения, элемент <answer-options> (<варианты-ответа>), включение которого в состав документа определяется типом ответа, содержащимся в элементе <smsg-response-type> (<тип-ответа-на-системное-сообщение>), причем этот элемент имеет конкретное содержимое и идентификатор ответа, элемент <verification> (<верификация>), который имеет код для подтверждения того, что запрос в виде системного сообщения был прочитан пользователем, элемент <time-out> (<время-простоя>), который указывает продолжительность времени ожидания, в течение которого ожидают ответ пользователя на запрос в виде системного сообщения, и элемент <restrict-access> (<ограничение-доступа>), который позволяет серверу настоятельно требовать, чтобы клиент заблокировал дальнейший доступ к соответствующей услуге до тех пор, пока пользователь не ответит на запрос в виде системного сообщения.

В предпочтительном варианте элемент <smsg-response-type> (<тип-ответа-на-системное-сообщение>) может содержать, по меньшей мере, один из следующих типов ответа: "без-ответа" ("no-answer"), "только-один-ответ" ("only-one-answer") и "множество-ответов" ("multiple-answer"), при этом тип "без ответа" используют в том случае, когда ответ от пользователя не ожидают, тип "только-один-ответ" используют в том случае, когда должен быть выбран только один из двух различных ответов: одобрение или отказ, а тип "множество-ответов" используют в том случае, когда для ответа на системные сообщения от пользователя требуется ответ в виде множества ответов.

В предпочтительном варианте элемент <answer-options> (<варианты-ответа>) может не входить в состав документа запроса в виде системного сообщения в том случае, когда значением элемента <smsg-response-type> (<тип-ответа-на-системное-сообщение>) является "без-ответа", а когда этим значением является "только-один-ответ" или "множество-ответов", то каждый элемент <answer-options> (<варианты-ответа>) содержит дочерний элемент <answer-option-id> (<идентификатор-варианта-ответа>), имеющий идентификатор, соответствующий уникальному номеру, для идентификации варианта ответа, и дочерний элемент <answer-option-text> (<текст-варианта-ответа>), содержащий текст, указывающий конкретный смысл каждого варианта ответа.

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

В предпочтительном варианте элемент <time-out> (<время-простоя>), элемент <restrict-access> (<ограничение-доступа>) и элемент <verification> (<верификация>) по выбору включены в состав документа запроса в виде системного сообщения на расширяемом языке гипертекстовой разметки (XML).

Кроме того, документ ответа на системное сообщение на расширяемом языке гипертекстовой разметки (XML) может содержать элемент <smsg-type> (<тип-системного-сообщения>), элемент <smsg> (<системное сообщение>), элемент <answer> (<ответ>), содержащий ответ пользователя на запрос в виде системного сообщения, и элемент <verification> (<верификация>), содержащий строку алфавитно-цифровых символов, введенных пользователем в соответствии со строкой алфавитно-цифровых символов, содержащейся в элементе <verification> (<верификация>) запроса в виде системного сообщения.

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

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

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

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

на фиг.3 изображена схема последовательности операций, на которой проиллюстрирован процесс передачи системных сообщений согласно общему способу "MESSAGE" протокола SIP;

на фиг.4 изображена схема последовательности операций, на которой проиллюстрирован процесс передачи системных сообщений согласно способу "MSRP SEND"; и

фиг.5 - схема последовательности операций, иллюстрирующая процесс сообщений передающей системы согласно способу "SIP INFO".

ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

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

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

В этом изобретении предложен способ передачи системного сообщения, охватывающий различные требования, предъявляемые к системному сообщению, путем введения нового информационного содержимого в виде многоцелевого расширения электронной почты в сети Интернет (MIME) "тела" сообщения протокола инициирования сеанса связи (SIP), путем введения нового дескриптора признака в существующий заголовок сообщения протокола SIP и путем последующей его передачи как системного сообщения для передачи информации и получения ответа от пользователя. Способ транспортировки нового содержимого в "теле" сообщения протокола SIP типа MIME может быть применен, например, для способа "MESSAGE", для способа "MSRP SEND", для способа "SIP INFO" и т.д.

Клиент и сервер должны обеспечивать поддержку функциональной возможности обмена системными сообщениями. Кроме того, клиент и сервер должны, в частности, распознавать системные сообщения, отличая системные сообщения от других обычных сообщений. Следовательно, согласно настоящему изобретению, введение нового дескриптора признака в заголовок сообщения протокола SIP может помочь серверу в определении того, обеспечивает ли клиент поддержку обмена системными сообщениями, а также может помочь системам передачи и приема однозначно определять системное сообщение. Новый дескриптор признака может именоваться "+g.application.smsg", и этот новый дескриптор признака применим для любого вида обслуживания, например, для услуги мгновенного обмена сообщениями (IM), для услуги предоставления функции "нажми и говори по сотовому телефону" (Push-to-Talk Over Cellular (PoC)), для услуги передачи мультимедийных сообщений (MMS). Идентификатор дескриптора признака на языке абстрактного синтаксиса версии 1 (ASN.1), то есть "+g.application.smsg", представляет собой новый идентификатор, установленный Комитетом по цифровым адресам в сети Интернет (IANA), и дескриптор признака указывает, что клиент обеспечивает поддержку системных сообщений. Значения, подходящие для использования с этим дескриптором признака, являются булевыми значениями. Дескриптор признака предназначен для использования, главным образом, в описанных ниже прикладных задачах, протоколах, видах обслуживания или в механизмах согласования, а также является наиболее полезным при его использовании в средствах связи для описания возможностей устройства, например, телефонного аппарата или персонального информационного устройства (PDA).

Одним из примеров такого типичного использования может являться маршрутизация системного сообщения в телефонный аппарат мобильной связи, который может поддерживать обмен системными сообщениями. Новый дескриптор признака должен быть зарегистрирован клиентом во время операции SIP REGISTER (регистрация по протоколу SIP). Поле заголовка протокола SIP используют для указания факта поддержки системных сообщений для того, чтобы, например, в качестве носителя нового дескриптора признака вместе с параметрами 'require' ('требуется') и 'explicit' ('в явном виде') согласно правилам и процедурам документа RFC 3841 "Caller Preferences for the Session Initiation Protocol" мог быть использован заголовок Accept-Contact ("одобрить контакт"). Новый дескриптор признака может быть использован в различных способах протокола SIP для передачи системных сообщений. В настоящем изобретении для передачи и приема системных сообщений может быть использован способ "MESSAGE" протокола SIP, не зависящий от того, передано ли системное сообщение в рамках сеанса связи или нет. Кроме того, в настоящем изобретении для передачи системных сообщений во время сеанса связи могут быть использованы следующие способы: способ "SIP INFO" и способ "MSRP SEND".

Согласно настоящему изобретению для системных сообщений должен быть определен новый тип MIME. Новый тип MIME однозначно определен, например, при помощи следующего типа информационного содержимого MIME: "vnd.example.system-message+xml". Этот тип информационного содержимого MIME используют для идентификации того, что "тело" сообщения протокола SIP (SIP MESSAGE) содержит системное сообщение, соответствующее конкретной схеме (схеме расширяемого языка гипертекстовой разметки (XML)). Новый тип информационного содержимого MIME применим для любого типа обслуживания, например, для услуги мгновенного обмена сообщениями (IM), для услуги предоставления функции "нажми и говори по сотовому телефону" (PoC), для услуги передачи мультимедийных сообщений (MMS). Кроме того, новый тип информационного содержимого MIME должен быть указан в различных способах протокола SIP для системных сообщений. Для передачи и приема системных сообщений может быть использован способ "MESSAGE" протокола SIP, не зависящий от того, передано ли системное сообщение в рамках сеанса связи или нет, а для передачи системных сообщений во время сеанса связи также могут быть использованы следующие способы: способ "SIP INFO" и способ "MSRP SEND". Транспортировка нового типа MIME может быть осуществлена в поле заголовка сообщения протокола SIP (SIP MESSAGE), например, в заголовке Content-Type ("тип информационного содержимого").

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

Ниже приведено описание структуры документа запроса в виде системного сообщения. Запрос в виде системного сообщения представляет собой документ на расширяемом языке гипертекстовой разметки (XML), который должен иметь надлежащую структуру и должен быть правильным. Этот документ запроса в виде системного сообщения основан на расширяемом языке гипертекстовой разметки (XML) версии 1.0, и в нем использовано преобразование уникода формата 8 (кодировка UTF-8). В этом изобретении для однозначной идентификации документов запроса в виде системного сообщения или фрагментов документа используют пространства имен расширяемого языка гипертекстовой разметки (XML). Пространством имен универсального указателя ресурса (URI) для элементов, указанных в подробном описании настоящего изобретения, являются унифицированные имена ресурса (URN), в которых используют идентификатор 'example' ('пример') пространства имен. Эти URN имеют следующий вид:

"urn:example:params:xml:ns:application:system-message"

Такой документ запроса в виде системного сообщения может начинаться с корневого элемента <system-message> (<системное-сообщение>) и может дополнительно содержать элемент <smsg-type> (<тип-системного-сообщения>), элемент <smsg> (<системное сообщение>), элемент <smsg-text> (<текст-системного-сообщения>), элемент <smsg-response-type> (<тип-ответа-на-системное-сообщение>), элемент <answer-options> (<варианты-ответа>), элемент <answer-option-id> (<идентификатор-варианта-ответа>), элемент <answer-option-text> (<текст-варианта-ответа>), элемент <verification> (<верификация>), элемент <verification-text> (<текст-для-верификации>), элемент <verification-uri> (<uri-для-верификации>), элемент <time-out> (<время-простоя>) и элементы <restrict-access> (<ограничение-доступа>). Определения каждого элемента даны в приведенной ниже таблице 1.

ТАБЛИЦА 1
Наименование элемента	Содержимое, описанное в элементе
smsg-type	указывает, является ли системное сообщение "запросом" или "ответом"
smsg	уникальное число для обеспечения соответствия ответа запросу
smsg-text	текст системного сообщения
smsg-response-type	тип ответа на запрос: "без-ответа" ("no-answer"), либо "только-один-ответ" ("only-one-answer"), либо "множество ответов" ("multiple-answer")
answer-options	перечень вариантов ответа
answer-option-id	уникальный номер для идентификации варианта ответа
answer-option-text	вариант ответа в виде текста в свободной форме
verification	подтверждение того, что системное сообщение прочитано пользователем
verification-text	код верификации, который пользователь должен повторно ввести в ответ
verification-uri	универсальный указатель ресурса (URI) того места, из которого пользователь должен ввести код в ответ
Time-out	продолжительность промежутка времени, в течение которого ожидают ответ от пользователя
restrict-access	настоятельно требует, чтобы клиент заблокировал дальнейший доступ к услуге до тех пор, пока пользователь не ответит на системное сообщение

Ниже приведено подробное описание соответствующих вышеизложенных элементов со ссылкой на приведенную выше таблицу 1.

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

Элемент <smsg-text> (<текст-системного-сообщения>) представляет собой элемент, дающий некоторую информацию, которую следует предоставить пользователю. Элемент <smsg-response-type> (<тип-ответа-на-системное-сообщение>) представляет собой указатель, который информирует пользователя о типе ответа, ожидаемого от пользователя при ответе на запрос в виде системного сообщения, при этом существуют следующие типы ответа: "без-ответа" ("no-answer"), "только-один-ответ" ("only-one-answer") и "множество-ответов" ("multiple-answer"), где тип "без-ответа" используют в том случае, когда системные сообщения, переданные сервером, предназначены только для информирования этого пользователя, и от пользователя не ожидают какого-либо ответа, тип "только-один-ответ" используют в том случае, когда для системных сообщений, переданных сервером, необходимо знать ответ пользователя, причем видом ответа является только одобрение/отказ или да/нет, а тип "множество-ответов" используют в том случае, когда для системных сообщений, переданных сервером, необходимо знать ответ пользователя в виде множества ответов. Сервер выбирает значение элемента <smsg-response-type> (<тип-ответа-на-системное-сообщение>) на основании вид ответа, требуемого от пользователя. Клиент должен передать обратно соответствующий ответ с типом ответа, запрошенным сервером.

Элемент <answer-options> (<варианты-ответа>) представляет собой элемент, описывающий возможные варианты ответа, которые могут быть выбраны пользователем и могут состоять из нескольких элементов. Наличие этого элемента означает, что сервер ожидает ответ от пользователя. Следовательно, элемент <answer-options> (<варианты-ответа>) отсутствует в том случае, когда значением элемента <smsg-response-type> (<тип-ответа-на-системное-сообщение>) является "без ответа". Элемент <answer-options> (<варианты-ответа>) дает возможность клиенту отображать на дисплее варианты ответа, из которых пользователь может производить выбор. В случае "только-один-ответ" или "множество-ответов" каждая пара вариантов ответа содержит уникальный идентификатор и текстовое сообщение, указывающее смысл варианта выбора. Уникальный идентификатор помогает серверу распознавать вариант выбора, выбранный пользователем в ответ на системное сообщение. Каждый элемент <answer-options> (<варианты-ответа>) содержит элемент <answer-option-id> (<идентификатор-варианта-ответа>), который соответствует уникальному номеру для идентификации варианта ответа, и элемент <answer-option-text> (<текст-варианта-ответа>), который представляет собой элемент для предоставления текста в свободной форме, объясняющего соответствующий вариант ответа. Если этот дочерний элемент отсутствует, то это означает, что клиент предоставляет пользователю вариант заполнения ответа.

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

Элемент <time-out> (<время-простоя>) представляет собой элемент, информирующий пользователя о продолжительности промежутка времени, в течение которого ожидают ответ от пользователя. Этот элемент имеет условие, заключающееся в том, что сервер ожидает от пользователя ответ на системное сообщение в течение определенного промежутка времени/продолжительности. Если пользователь не отвечает в течение заранее заданного промежутка/периода времени, то сервер может принять решение о будущем ходе действий на основании локальной политики. Наличие этого элемента <time-out> (<время-простоя>) является необязательным, и решение об этом принимает сервер.

Элемент <restrict-access> (<ограничение-доступа>) представляет собой элемент, позволяющий серверу содействовать клиенту в блокировании дальнейшего доступа к услуге до тех пор, пока пользователь не ответит на системное сообщение. Наличие этого элемента также является необязательным, и решение об этом принимает сервер. Если сервер выдает запрос на блокирование доступа к услуге посредством элемента <restrict-access> (<ограничение-доступа>), то клиент не должен разрешать пользователю дальнейший доступ к услуге. Следовательно, в том случае, когда сервер желает ограничить доступ к услуге до тех пор, пока не поступит ответ от клиента, сервер поддерживает состояние доступа и ожидает ответа до тех пор, пока не истечет время простоя, и в случае простоя принимает решение о дальнейших действиях на основании политики поставщика услуг. В состоянии простоя сервер может производить повторную передачу системного сообщения, но решение о повторной передаче системного сообщения принимают в соответствии с политикой поставщика услуг. Документ запроса в виде системного сообщения должен быть распознан по типу информационного содержимого MIME, которым является "vnd.example.system-message+xml".

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

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

Ниже приведено описание структуры документа ответа на системное сообщение. Документ ответа на системное сообщение представляет собой документ на расширяемом языке гипертекстовой разметки (XML), который должен иметь надлежащую структуру и должен быть правильным. Документ ответа на системное сообщение основан на расширяемом языке гипертекстовой разметки (XML) версии 1.0, и в нем использована кодировка UTF-8. В этом изобретении для однозначной идентификации документов ответа на системное сообщение или фрагментов документов используют пространства имен расширяемого языка гипертекстовой разметки (XML). Пространством имен универсального указателя ресурса (URI) для элементов, указанных в этом изобретении, являются унифицированные имена ресурса (URN), в которых используют идентификатор 'example' ('пример') пространства имен. Эти URN имеют следующий вид:

urn:example:params:xml:ns:application:system-message

Документ ответа на системное сообщение начинается с корневого элемента <system-message> (<системное-сообщение>) и может дополнительно содержать элемент <smsg-type> (<тип-системного-сообщения>), элемент <smsg> (<системное сообщение>), элемент <answer> (<ответ>), элемент <answer-id> (<идентификатор-ответа>, элемент <answer-text> (<текст-ответа>) и элемент <verification> (<верификация>). Определения соответствующих элементов показаны в приведенной ниже таблице 4.

ТАБЛИЦА 4
Наименование элемента	Содержимое, описанное в элементе
smsg-type	указывает, является ли системное сообщение "запросом" или "ответом"
smsg	уникальное число для обеспечения соответствия ответа запросу
answer	перечень выбранных ответов
answer-id	для идентификации варианта ответа, выбранного пользователем
answer-text	необязательный ответ с текстом в свободной форме
verification	для подтверждения того, что системное сообщение прочитано пользователем

Ниже приведено подробное описание соответствующих элементов со ссылкой на приведенную выше таблицу 4.

Элемент <smsg-type> (<тип-системного-сообщения>) указывает, что системное сообщение имеет тип "ответ", а это означает, что оно направлено от клиента в сервер. Элемент <smsg> (<системное сообщение>) представляет собой элемент, который имеет значение, содержащееся в атрибуте "id" ("идентификатор") элемента <smsg> (<системное сообщение>) запроса в виде системного сообщения. Этот элемент помогает находить соответствие между запросом и ответом в сервере. Этот элемент <smsg> (<системное сообщение>) также помогает устанавливать соответствие ответов в тех случаях, когда в одном сообщении передают более одного системного сообщения для уменьшения непроизводительных издержек при обмене сообщениями и при передаче служебных сигналов.

Элемент <answer> (<ответ>) представляет собой элемент, предназначенный для указания варианта, выбранного пользователем, из перечня вариантов ответа, и он может содержать несколько элементов. Этот элемент представляет собой вариант, выбранный из ряда вариантов ответа, заданных в запросе в виде системного сообщения. Каждый элемент <answer> (<ответ>) имеет дочерний элемент <answer-id> (<идентификатор-ответа>). Если элемент <smsg-response-type> (<тип-ответа-на-системное-сообщение>) в запросе в виде системного сообщения имеет значение "множество ответов", то может существовать множество элементов <answer-id> (<идентификатор-ответа>). Это позволяет пользователю передавать множество ответов на запрос с использованием того же самого сообщения. Использование только идентификатора служит для уменьшения размера сообщения. К тому же, наряду с элементом <answer-id> (<идентификатор-ответа>), каждый элемент <answer> (<ответ>) может иметь дочерний элемент <answer-text> (<текст-ответа>), в котором имеется введенный пользователем ответ в виде текста в свободной форме. Реакция в виде ответа может облегчить для поставщика услуг принятие решения о том, какой уровень обслуживания следует предоставить пользователю, и относительно таких различных факторов, как восстановление пароля, новая регистрация, начисление оплаты, функциональные возможности и т.д.

Элемент <verification> (<верификация>) представляет собой элемент для подтверждения того, что системное сообщение прочитано пользователем. Например, пользователь вводит код, который имеется в запросе в виде системного сообщения, и, таким образом, предоставляет возможность серверу подтвердить то, что системное сообщение прочитано пользователем. В ином случае, этот элемент может представлять собой код, имеющийся в месте, описанном как конкретный универсальный указатель ресурса (URI) (который указан в запросе в виде системного сообщения). Если верификация ответа, предоставленного пользователем, является неудачной, то решение о дальнейших действиях принимают на основании политики сервера. Например, может существовать вариант, что сервер не разрешает дальнейший доступ к услуге, и что сервер может произвести повторную передачу системного сообщения. Документ ответа на системное сообщение должен быть распознан по типу информационного содержимого MIME, которым является "vnd.example.system-message+xml".

Схема документа ответа на системное сообщение на расширяемом языке гипертекстовой разметки (XML) описана в приведенной ниже таблице 5.

Пример документа ответа на системное сообщение согласно настоящему изобретению показан в приведенной ниже таблице 6.

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

Сначала приведено описание процесса передачи запроса на получение системных сообщений со ссылкой на фиг.1. Если сервер X (130) определяет, что необходимо передать системное сообщение клиенту X, что зависит от текущих условий связи, то он передает сообщение запроса по протоколу SIP, то есть, запрос в виде системного сообщения, в ядро (120) протокола SIP/протокола сети Интернет (SIP/IP). Здесь запрашиваемый универсальный указатель ресурса (URI) в сообщении с запросом протокола SIP содержит адрес клиента X (110), а заголовок Accept-Contact ("одобрить контакт") заголовка сообщения протокола SIP содержит дескриптор признака "+g.application.smsg". Кроме того, поле Content-Type ("тип информационного содержимого") заголовка сообщения содержит элемент "application/vnd.example.system-message+xml", который представляет собой тип информационного содержимого MIME, для указания того, что "тело" сообщения имеет информационное содержимое, связанное с системным сообщением, а "тело" сообщения протокола SIP может быть выполнено в виде документа на расширяемом языке гипертекстовой разметки (XML), содержимое которого связано с запросом в виде системного сообщения.

Пример этого сообщения с запросом протокола SIP показан в приведенной ниже таблице 7.

ТАБЛИЦА 7
Запрашиваемый универсальный указатель ресурса (URI)	sip:UserX@networkX.net
ЗАГОЛОВКИ ПРОТОКОЛА SIP
P-Asserted-Identity (утвержденная протоколом идентичность):	"Server X" <sip:ServerX@networkX.net>
Accept-Contact ("одобрить контакт"):	*;+g.application.smsg;require;explicit
Content-Type ("тип информационного содержимого"):	application/vnd.example.system-message+xml
"ТЕЛО" MIME НА РАСШИРЯЕМОМ ЯЗЫКЕ ГИПЕРТЕКСТОВОЙ РАЗМЕТКИ (XML)
	<?xml version="1.0" encoding="UTF-8"?> <system-message xmlns="urn:example:params:xml:ns:application:system-message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:example:params:xml:ns:application:system-message"> <smsg-type>request</smsg-type> <smsg id="ghi789"> <smsg-text>Желаете ли Вы продолжить получение услуги?</smsg-text> <smsg-response-type>only-one-answer</smsg-response-type> <answer-options> <answer-option-id>1</answer-option-id> <answer-option-text>Согласен</answer-option-text> </answer-options> <answer-options> <answer-option-id>2</answer-option-id> <answer-option-text>Не согласен</answer-option-text> </answer-options> </smsg> </system-message>

При операции 203 ядро X (120) протокола SIP/протокола сети Интернет (SIP/IP) передает клиенту X (110) сообщение запроса протокола SIP, полученное из сервера (130), на основании информации, запомненной при операции регистрации. При операции 205 клиент X (110) разрешает отобразить полученное сообщение запроса протокола SIP, то есть запрос в виде системного сообщения, на дисплее для пользователя X. Затем выполняют операцию 207, при которой клиент X (110) передает ответ 200 об успешном получении ("OK") по протоколу SIP в ядро X (120) протокола SIP/протокола сети Интернет (SIP/IP) для подтверждения того, что запрос в виде системного сообщения был получен. Ответ 200 об успешном получении ("OK") по протоколу SIP, который может иметь конфигурацию, показанную в приведенной ниже таблице 8, передают по тракту передачи служебных сигналов в сервер X.

ТАБЛИЦА 8
ЗАГОЛОВКИ ПРОТОКОЛА SIP
P-Asserted-Identity: (утвержденная протоколом идентичность)	"User X" <sip:UserX@networkX.net>

При операции 209 ядро X (120) протокола SIP/протокола сети Интернет (SIP/IP), получившее ответ 200 об успешном получении ("OK") по протоколу SIP, передает ответ в сервер X. Сервер X (130) получает ответ 200 об успешном получении ("OK") по протоколу SIP, посредством чего подтверждают, что запрос в виде системного сообщения получен клиентом X (110). Со ссылкой на фиг.2 описан процесс передачи ответа на системные сообщения после того, как клиент X (110) получает сообщение запроса протокола SIP, то есть запрос в виде системного сообщения, с использованием новой структуры ответного сообщения протокола SIP согласно настоящему изобретению. Как показано на чертеже фиг.2, клиент X (110) передает в ядро X (120) протокола SIP/протокола сети Интернет (SIP/IP) ответное сообщение протокола SIP в ответ на сообщение запроса протокола SIP, полученное при операциях, показанных на фиг.1. Здесь запрашиваемый универсальный указатель ресурса (URI) в ответном сообщении протокола SIP может содержать адрес сервера X (130), а заголовок Accept-Contact ("одобрить контакт") заголовка сообщения протокола SIP может содержать дескриптор признака "+g.application.smsg". Кроме того, поле Content-Type ("тип информационного содержимого") заголовка сообщения может содержать элемент "application/vnd.example.system-message+xml", который представляет собой тип информационного содержимого MIME, для указания того, что "тело" сообщения имеет информационное содержимое, связанное с системным сообщением, а "тело" сообщения протокола SIP может быть выполнено в виде документа на расширяемом языке гипертекстовой разметки (XML), содержимое которого связано с ответом на системное сообщение. Пример этого ответного сообщения протокола SIP показан в приведенной ниже таблице 9.

ТАБЛИЦА 9
Универсальный указатель ресурса (URI) запроса	sip:ServerX@networkX.net
ЗАГОЛОВКИ ПРОТОКОЛА SIP
P-Preferred-Identity (предпочтительная идентичность согласно протоколу):	"User X" <sip:UserX@networkX.net>
Accept-Contact ("одобрить контакт"):	*;+g.application.smsg;require;explicit
Content-Type ("тип информационного содержимого"):	application/vnd.example.system-message+xml
"ТЕЛО" MIME НА РАСШИРЯЕМОМ ЯЗЫКЕ ГИПЕРТЕКСТОВОЙ РАЗМЕТКИ (XML)
	<?xml version="1.0" encoding='*UTF-8"?>
	<system-message xmlns="urn:example:params:xml:ns:application: system-message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:example:params:xml:ns: application:system-message"> <smsg-type>response</smsg-type> <smsg id="ghi789"> <answer> <answer-id>1</answer-id> </answer> <verification> <verification-text>354agr67h</verification-text> </verification> </smsg> </system-message>

При операции 303 ядро протокола SIP/протокола сети Интернет (SIP/IP) передает полученное ответное сообщение протокола SIP в сервер X (130) на основании дескриптора признака "+g.application.smsg" в заголовке Accept-Contact ("одобрить контакт"). При операции 305 сервер X (130) получает ответное сообщение протокола SIP, получая, таким образом, ответ клиента X (110) на запрос в виде системного сообщения. Затем выполняют операцию 307, при которой сервер X (130) передает в ядро X (120) протокола SIP/протокола сети Интернет (SIP/IP) ответ 200 об успешном получении ("OK") по протоколу SIP, показанный в приведенной ниже таблице 10.

ТАБЛИЦА 10
ЗАГОЛОВКИ ПРОТОКОЛА SIP
P-Asserted-Identity (утвержденная протоколом идентичность):	<sip:ServerX@networkX.net>

После этого выполняют операцию 308, при которой ядро X (120) протокола SIP/протокола сети Интернет (SIP/IP) передает ответ 200 об успешном получении ("OK") по протоколу SIP клиенту X (110).

В настоящем изобретении предложен способ передачи системных сообщений, охватывающий различные требования, предъявляемые к системному сообщению, путем введения типа информационного содержимого MIME и нового дескриптора признака, указывающего наличие этих системных сообщений, в заголовок сообщения протокола SIP, а также путем транспортировки документа на расширяемом языке гипертекстовой разметки (XML), имеющего информационное содержимое, связанное с системным сообщением, в "теле" сообщения протокола SIP типа MIME. Здесь сообщение протокола SIP может быть реализовано способом "MESSAGE", способом "MSRP SEND", способом "SIP INFO" и т.д.

Со ссылкой на чертежи фиг.3-5, приведено описание способа передачи системных сообщений согласно соответствующему вышеописанному способу. На чертежах изображено следующее: на фиг.3 проиллюстрирован процесс передачи системных сообщений согласно общему способу "MESSAGE" протокола SIP, на фиг.4 проиллюстрирован процесс передачи системных сообщений согласно способу "MSRP SEND", а на фиг.5 проиллюстрирован процесс передачи системных сообщений согласно способу "SIP INFO".

В способе "MESSAGE" протокола SIP, показанном на фиг.3, при операции 11 сервер 20 формирует запрос в виде системного сообщения для предоставления информации или для предупреждения, выдавая запрос на получение одобрения/отказа и множества ответов согласно схеме на расширяемом языке гипертекстовой разметки (XML), показанной в таблице 2. То есть сервер 20 формирует информационное содержимое, содержащееся в запросе в виде системного сообщения, с использованием элемента <smsg-type> (<тип-системного-сообщения>), элемента <smsg> (<системное сообщение>), элемента <smsg-text> (<текст-системного-сообщения>), элемента <smsg-response-type> (<тип-ответа-на-системное-сообщение>), элемента <answer-options> (<варианты-ответа>), элемента <verification> (<верификация>), элемента <verification-text> (<текст-для-верификации>) и элемента <restrict-access> (<ограничение-доступа>), а затем при операции 13 осуществляет его передачу клиенту 10 с использованием способа "MESSAGE". При операции 15 клиент 10 отображает принятый запрос в виде системного сообщения, отличимого от обычного сообщения, на дисплее и осуществляет управление доступом пользователя к конкретной услуге, если этого требует запрос в виде системного сообщения, а затем при выполнении операции 17 передает ответ 200 об успешном получении ("OK") по протоколу SIP в сервер 20. После этого выполняют операцию 19, при которой клиент 10 формирует ответное сообщение на запрос в виде системного сообщения согласно схеме на расширяемом языке гипертекстовой разметки (XML), показанной в таблице 5, в пределах промежутка времени, заранее заданного посредством запроса в виде системного сообщения, если это необходимо. Например, клиент 10 формирует информационное содержимое, содержащееся в ответе на системное сообщение, с использованием элемента <smsg-type> (<тип-системного-сообщения>), элемента <smsg> (<системное сообщение>), элемент <answer> (<ответ>), элемента <answer-id> (<идентификатор-ответа>), элемента <answer-text> (<текст-ответа>) и элемента <verification> (<верификация>), а затем при выполнении операции 21 осуществляет его передачу в сервер 20 с использованием способа "MESSAGE" протокола SIP. После того как переданное ответное сообщение распознано сервером 20, он подтверждает, что сообщение прочитано пользователем, и передает ответ 200 об успешном получении ("OK") клиенту 10.

В способе "MSRP SEND", показанном на фиг.4, при операции 31 сервер 20 формирует запрос в виде системного сообщения для предоставления информации или для предупреждения, выдавая запрос на получение одобрения/отказа и множества ответов согласно схеме на расширяемом языке гипертекстовой разметки (XML), показанной в таблице 2. Например, сервер 20 формирует информационное содержимое, содержащееся в запросе в виде системного сообщения, с использованием элемента <smsg-type> (<тип-системного-сообщения>), элемента <smsg> (<системное сообщение>), элемента <smsg-text> (<текст-системного-сообщения>), элемента <smsg-response-type> (<тип-ответа-на-системное-сообщение>), элемента <answer-options> (<варианты-ответа>), элемента <verification> (<верификация>), элемента <time-out> (<время-простоя>) и элемента <restrict-access> (<ограничение-доступа>), а затем при операции 33 осуществляет его передачу клиенту 10 с использованием способа "MSRP SEND". При операции 35 клиент 10 отображает принятый запрос в виде системного сообщения, отличимого от обычных сообщений, на дисплее и осуществляет управление доступом пользователя к конкретной услуге, если этого требует запрос в виде системного сообщения, а затем при выполнении операции 37 передает ответ 200 об успешном получении ("OK") по протоколу SIP в сервер 20. После этого выполняют операцию 39, при которой клиент 10 формирует ответное сообщение на запрос в виде системного сообщения согласно схеме на расширяемом языке гипертекстовой разметки (XML), показанной в таблице 5, в пределах промежутка времени, заранее заданного посредством запроса в виде системного сообщения. Например, клиент 10 формирует информационное содержимое, содержащееся в ответе на системное сообщение, с использованием элемента <smsg-type> (<тип-системного-сообщения>), элемента <smsg> (<системное сообщение>), элемента <answer> (<ответ>), элемента <answer-id> (<идентификатор-ответа>), элемента <answer-text> (<текст-ответа>) и элемента <verification> (<верификация>), а затем при выполнении операции 41 осуществляет его передачу в сервер 20 с использованием способа "MSRP SEND". После того как переданное ответное сообщение распознано сервером 20, он подтверждает, что сообщение прочитано пользователем, и передает ответ 200 об успешном получении ("OK") клиенту 10.

В способе "SIP INFO", показанном на фиг.5, при операции 51 сервер 20 формирует запрос в виде системного сообщения для предоставления информации или для предупреждения, выдавая запрос на получение одобрения/отказа и множества ответов согласно схеме на расширяемом языке гипертекстовой разметки (XML), показанной в таблице 2. То есть сервер 20 формирует информационное содержимое, содержащееся в запросе в виде системного сообщения, с использованием элемента <smsg-type> (<тип-системного-сообщения>), элемента <smsg> (<системное сообщение>), элемента <smsg-text> (<текст-системного-сообщения>), элемента <smsg-response-type> (<тип-ответа-на-системное-сообщение>), элемента <answer-options> (<варианты-ответа>), элемента <verification> (<верификация>), элемента <time-out> (<время-простоя>) и элемента <restrict-access> (<ограничение-доступа>), а затем при операции 53 осуществляет его передачу клиенту 10 с использованием способа "SIP INFO". При операции 55 клиент 10 отображает принятый запрос в виде системного сообщения на дисплее и осуществляет управление доступом пользователя к конкретной услуге, если этого требует запрос в виде системного сообщения, а затем при выполнении операции 57 клиент 10 передает ответ 200 об успешном получении ("OK") в сервер 20. После этого выполняют операцию 59, при которой клиент 10 формирует ответное сообщение на запрос в виде системного сообщения согласно схеме на расширяемом языке гипертекстовой разметки (XML), показанной в таблице 5, в пределах промежутка времени, заранее заданного посредством запроса в виде системного сообщения. Например, клиент 10 формирует информационное содержимое, содержащееся в ответе на системное сообщение, с использованием элемента <smsg-type> (<тип-системного-сообщения>), элемента <smsg> (<системное сообщение>), элемента <answer> (<ответ>), элемента <answer-id> (<идентификатор-ответа>), элемента <answer-text> (<текст-ответа>) и элемента <verification> (<верификация>), а затем при выполнении операции 61 осуществляет его передачу в сервер 20 с использованием способа "SIP INFO". Сервер 20 обнаруживает переданное ответное сообщение, подтверждает, что системное сообщение прочитано пользователем, и затем передает ответ 200 об успешном получении ("OK") клиенту 10.

Из приведенного выше описания понятно, что в настоящем изобретении предложен способ передачи системных сообщений с использованием сообщений протокола SIP путем введения типа "системное сообщение" в информационное содержимое MIME и дескриптора признака, указывающего наличие системных сообщений, в заголовок сообщения протокола SIP, и обеспечивающий, тем самым, транспортировку документа на расширяемом языке гипертекстовой разметки (XTML), описывающего информационное содержимое, связанное с системным сообщением, в "теле" сообщения протокола SIP. Следовательно, способ передачи системных сообщений с использованием протокола SIP согласно настоящему изобретению позволяет отличать системные сообщения от обычных сообщений, и позволяет серверу распознавать ответы на системное сообщение, полученные от клиента. Кроме того, способ позволяет обеспечить режим ожидания в течение заданного промежутка времени во время ожидания сервером ответа от клиента, и обеспечить управление доступом на удобном для пользователя уровне обслуживания со стороны сервера. Кроме того, сервер может осуществлять передачу системных сообщений клиенту, и сервер может получать ответ на них от клиента. Сервер может принимать решения относительно любых последующих действий на основании политики поставщика услуг. Кроме того, этот способ передачи системных сообщений применим для способа "MESSAGE" протокола SIP, для способа "MSRP SEND" и для способа "SIP INFO".

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

[Ссылки]

[RFC 2976]	"The SIP INFO Method", S.Donovan. RFC 2976, October 2000, URL: http://www.ietf.org/rfc/rfc2976.txt

[RFC 3261]	"SIP: Session Initiation Protocol". J.Rosenberg, et. al., RFC 3261. June 2002. URL: http://wmv.ietf.org/rfc/rfc3261.txt

[RFC 3428]	"Session Initiation Protocol (SIP) Extension for Instant Messaging", B. Campbell, Ed., et. al., RFC 3428, December 2002, URL: http://www.ietf.org/rfc/rfc3428.txt

[MSRP]	"The Message Session Relay Protocol", B. Campbell. Ed., et. al., draft-ietf-simple-message-sessions, URL: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-15.txt

Claims

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

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

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

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

5. Способ по п.4, в котором передачу ответа на системное сообщение осуществляют согласно одному из следующих способов: способу "MESSAGE" протокола SIP, способу "MSRP SEND" или способу "SIP INFO".

6. Способ по п.5, в котором транспортировку дескриптора признака осуществляют в поле Accept-Contact ("одобрить контакт") заголовка сообщения, а транспортировку типа информационного содержимого MIME осуществляют в поле Content-Type ("тип информационного содержимого").

7. Способ по п.6, в котором дескриптором признака является дескриптор "+g.application.smsg", а типом информационного содержимого MIME является "vnd.example.system-message+xml".

8. Способ по п.6, в котором упомянутый документ запроса в виде системного сообщения на расширяемом языке гипертекстовой разметки (XML) начинается с корневого элемента<system-message> (<системное-сообщение>).

9. Способ по п.8, в котором упомянутый документ запроса в виде системного сообщения на расширяемом языке гипертекстовой разметки (XML) содержит: элемент <smsg-type> (<тип-системного-сообщения>), который указывает, что системное сообщение является запросом в виде системного сообщения; элемент<smsg> (<системное сообщение>), который содержит уникальный идентификационный номер для установления соответствия ответа с запросом в виде системного сообщения; элемент <smsg-text> (<текст-системного-сообщения>), который содержит информацию, предназначенную для передачи клиенту; элемент <smsg-response-type> (<тип-ответа-на-системное-сообщение>), который указывает пользователю тип ответа, требуемый от клиента согласно запросу в виде системного сообщения; элемент<answer-options> (<варианты-ответа>), включение которого в состав документа определяется типом ответа, содержащимся в элементе <smsg-response-type> (<тип-ответа-на-системное-сообщение>), причем этот элемент имеет конкретное содержимое и идентификатор ответа; элемент <verification> (<верификация>), который содержит код для подтверждения того, что запрос в виде системного сообщения был прочитан пользователем; элемент <time-out> (<время-простоя>), который указывает продолжительность времени ожидания, в течение которого ожидают ответ пользователя на запрос в виде системного сообщения; и элемент <restrict-access> (<ограничение-доступа>), который позволяет серверу содействовать клиенту в блокировании дальнейшего доступа к соответствующей услуге до тех пор, пока пользователь не ответит на запрос в виде системного сообщения.

10. Способ по п.9, в котором элемент <smsg-response-type> (<тип-ответа-на-системное-сообщение>) содержит, по меньшей мере, один из следующих типов ответа: "без-ответа" ("no-answer"), "только-один-ответ" ("only-one-answer") и "множество-ответов" ("multiple-answer"), при этом тип "без ответа" используют в том случае, когда ответ от пользователя не ожидают, тип "только-один-ответ" используют в том случае, когда должен быть выбран любой один из двух различных ответов, а тип "множество-ответов" используют в том случае, когда для ответа на системные сообщения от пользователя требуется ответ в виде множества ответов; элемент <answer-options> (<варианты-ответа>) не входит в состав документа запроса в виде системного сообщения в том случае, когда значением элемента <smsg-response-type> (<тип-ответа-на-системное-сообщение>) является "без-ответа", а когда этим значением является "только-один-ответ" или "множество-ответов", то каждый элемент <answer-options> (<варианты-ответа>) содержит дочерний элемент <answer-option-id> (<идентификатор-варианта-ответа>), имеющий идентификатор, соответствующий уникальному номеру, для идентификации варианта ответа, и дочерний элемент <answer-option-text> (<текст-варианта-ответа>), содержащий текст, указывающий конкретный смысл каждого варианта ответа; и элемент <verification> (<верификация>) содержит два дочерних элемента: элемент <verification-text> (<текст-для-верификации>) и элемент <verification-uri> (<uri-для-верификации>), при этом элемент <verification-text> (<текст-для-верификации>) содержит алфавитно-цифровой код, который пользователь должен ввести в ответ на системное сообщение, а элемент <verification-uri> (<uri-для-верификации>) содержит универсальный указатель ресурса (URI), указывающий местоположение алфавитно-цифрового кода.

11. Способ по п.10, в котором элемент <time-out> (<время-простоя>), элемент <restrict-access> (<ограничение-доступа>) и элемент <verification> (<верификация>) по выбору включены в состав документа запроса в виде системного сообщения на расширяемом языке гипертекстовой разметки (XML).

12. Способ по п.11, в котором документ запроса в виде системного сообщения на расширяемом языке гипертекстовой разметки (XML) содержит элемент <smsg-type> (<тип-системного-сообщения>), элемент <smsg> (<системное сообщение>), элемент <answer> (<ответ>), содержащий ответ пользователя на запрос в виде системного сообщения, и элемент <verification> (<верификация>), содержащий строку алфавитно-цифровых символов, введенных пользователем в соответствии со строкой алфавитно-цифровых символов, содержащейся в элементе <verification> (<верификация>).