СПОСОБ, УСТРОЙСТВО И СИСТЕМА ДЛЯ ИДЕНТИФИКАЦИИ СЕРВИСА Российский патент 2011 года по МПК G06F21/00 H04L12/56 

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

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

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

В области технологий связи пользователю необходимо контактировать с сервисным провайдером при инициировании сервисного запроса. Когда сервисный запрос удовлетворяет условиям, сервисный провайдер предоставляет сервисы в ответ на сервисный запрос. Например, в сервисах данных пользователь может инициировать сервисный запрос для сервиса обмена мультимедийными сообщениями (MMS) через терминал, такой как сотовый телефон. Для того чтобы связываться с сервисным провайдером, IP-адрес и порт шлюза протокола беспроводных приложений (WAP GW), так же как и имя точки доступа (APN), должны быть сконфигурированы в сотовом телефоне. Адрес сервисного шлюза должен также быть сконфигурирован правильно в то же время. Когда все эти параметры сконфигурированы правильно, цель сервисного запроса может быть реализована.

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

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

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

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

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

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

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

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

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

На чертежах:

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

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

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

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

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

Подробное описание

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

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

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

M-Send.req - сообщение, предоставляемое сервис-центру обмена мультимедийными сообщениями (MMSC) терминалом отправителя через WAP GW;

M-Send.conf - ответное сообщение, возвращаемое терминалу отправителя посредством MMSC после приема сообщения, предоставленного терминалом отправителя;

M-Notification.ind - выдаваемое уведомляющее сообщение для уведомления терминала получателя получить сообщение от MMSC, которое передается терминалу получателя посредством MMSC после приема мультимедийного сообщения, предоставленного терминалом отправителя;

M-NotifyResp.ind - сообщение для указания того, успешно ли принято мультимедийное сообщение, которое отправлено в MMSC терминалом получателя;

M_GET_REQ передается терминалом получателя в MMSC, что инструктирует извлекать мультимедийное сообщение;

M_Retrieve.req передается терминалом получателя в MMSC, что инструктирует запрашивать извлечение мультимедийного сообщения;

M-Retrieve.conf - ответное сообщение, возвращаемое посредством MMSC после приема сообщения GET от терминала получателя; и

M-Acknowledge.ind - сообщение для указания состояния приема, которое передается в WAP GW терминалом получателя после выполнения приема мультимедийного сообщения.

Вариант осуществления настоящего изобретения описан ниже.

Мультимедийное сообщение является сообщением, которое включает в себя текст, изображение, видео- и аудиосодержимое, и является расширением сервиса коротких сообщений. Если пользователь хочет использовать MMS, ему/ей необходимо сконфигурировать IP-адрес и порт WAP GW и APN на терминале сотового телефона, и кроме того необходимо конфигурирование адреса сервисного шлюза. После того как все три параметра сконфигурированы правильно, мультимедийное сообщение может быть передано правильно. Типичным сервисным шлюзом является, например, MMSC. Если оператор разворачивает множество MMSC, множество MMSC взаимосвязаны. Когда пользователь передает MMS-сообщение, домашний MMSC типично используется для предоставления сервиса. В это же время WAP GW должен пересылать сервисный запрос домашнему MMSC пользователя. Для того чтобы реализовать пересылку посредством WAP GW, он должен опрашивать сервер преобразования электронного номера к унифицированному идентификатору ресурса (URI) (ENUM), чтобы получать домашний MMSC пользователя согласно адресу MMSC, сообщенному терминалом пользователя. Для удобства описания сервер преобразования электронного номера к унифицированному идентификатору ресурса называется ENUM-сервером. Примерная процедура может быть описана следующим образом: пользователь может перемещаться из домашней области B в область A и передает сервисный запрос для получения доступа к MMS из гостевого (т.е. где он находится) WAP GW; гостевой WAP GW может принимать сервисный запрос для получения доступа к MMS, переданный пользователем, и опрашивать ENUM-сервер, чтобы получать адрес унифицированного локатора ресурса (URL) домашнего MMSC пользователя (далее в данном документе называемый URL-адресом); гостевой WAP GW может передавать непосредственно сервисный запрос для получения доступа к MMS домашнему MMSC пользователя; и домашний MMSC пользователя может возвращать ответ на передачу MMS-сообщения.

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

S1: Терминал 100 может передавать запрашивающее сообщение M-Send.req в WAP GW 500, используя WAP в качестве несущего протокола. Терминал 100 упоминается как терминал отправителя, который сконфигурирован с адресом MMSC.

S2: WAP GW 500 может принимать запрашивающее сообщение от терминала 100 и решать URL-адрес, включенный в сервисный запрос. Если адресом является http://mmsc.monternet.com, считается, что сервисный запрос является сервисным запросом обмена мультимедийными сообщениями, и из сервисного запроса получается пользовательская идентификация отправителя, и инициируется опрос, который извлекает адрес домашнего MMSC отправителя из ENUM-сервера 300.

S3: ENUM-сервер 300 может возвращать в WAP GW 500 результат опроса, включающий в себя адрес домашнего MMSC отправителя.

S4: Согласно ответному сообщению WAP GW 500 может пересылать запрашивающее сообщение M-Send.req домашнему MMSC 400 отправителя, чтобы запрашивать передачу мультимедийного сообщения.

S5: Домашний MMSC 400 отправителя может отвечать на запрашивающее сообщение от WAP GW 500 и включать M-Send.conf в ответ, чтобы указывать, что запрос был принят.

S6: WAP GW 500 может пересылать M-Send.conf терминалу 100.

В вышеупомянутом варианте осуществления для того, чтобы передавать мультимедийное сообщение, необходимо сконфигурировать правильно адрес "http://mmsc.monternet.com" MMSC в терминале (обращаясь к этапу S2 в вышеупомянутом варианте осуществления). Если адрес сконфигурирован неверно, как, например, "http://mms.monternet.com", WAP GW будет идентифицировать неверно и не сможет обработать запрос как MMS, следовательно, приводя к сбою передачи мультимедийного сообщения. Это может вызывать неприятные переживания у пользователей и является нежелательным для оператора при активном продвижении сервиса.

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

Процедура обработки PIM-сервиса похожа на процедуру MMS-сервиса. WAP GW может принимать запрашивающее сообщение от терминала и решать URL-адрес, включенный в сервисный запрос. Если определяется, что сервисом, который должен быть выполнен, является PIM-сервис, ENUM-сервер опрашивается для того, чтобы получить адрес домашнего PIM-сервера пользователя, и сервисный запрос пересылается домашнему PIM-серверу пользователя посредством WAP GW. Однако, если терминал сконфигурирован с неправильным URL-адресом, WAP GW будет идентифицировать неправильно и не сможет обрабатывать сервисный запрос как PIM-сервис. Таким образом, цель сервисного запроса не может быть реализована, что может вызывать неприятные переживания у пользователей и является нежелательным для оператора при активном продвижении сервиса.

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

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

S11: Принимается сервисный запрос, включающий в себя URL-адрес.

S22: Определяется, соответствует ли URL-адрес сервисному потоку.

S33: Тип сервиса из сервисного запроса идентифицируется согласно типу содержимого сервиса, включенному в сервисный запрос, когда результат определения указывает, что URL-адрес не соответствует сервисному потоку.

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

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

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

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

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

S201: Сервисный запрос от пользователя в роуминге принимается гостевым WAP GW.

S202: Решается URL-адрес, включенный в сервисный запрос.

S203: Определяется, является ли URL-адрес URL-адресом MMSC, таким как "http://mmsc.monternet.com".

S204: Является ли сервисный запрос запросом MMS, который идентифицируется непрерывно согласно типу содержимого сервиса, включенному в сервисный запрос. Включенный тип содержимого сервиса является, например, содержимым в поле "тип содержимого". Если содержимое является MMS-типом содержимого сервиса, например, содержимым является "Application/vnd.wap.mms-message", определяется, что сервисный запрос является MMS-запросом.

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

S205: Необходимо, чтобы запрос MMS-сервиса являлся запросом для передачи MMS-сервиса, а тип информации о содержимом из поля "тип содержимого" являлся MMS. Например, если содержимым поля способа в сервисном запросе является "m-send-req", определяется, что сервисный запрос является запросом MMS-сервиса.

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

S206: Запрос для опроса адреса домашнего MMSC пользователя передается ENUM-серверу, если WAP GW определяет, что сервисный запрос, удовлетворяющий вышеупомянутым условиям, является запросом MMS-сервиса.

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

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

Гостевой WAP GW может решать URL-адрес, включенный в сервисный запрос, после приема сервисного запроса от пользователя в роуминге.

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

Вариант осуществления настоящего изобретения может также предоставлять шлюз протокола приложения, такой как WAP GW. Обращаясь к фиг. 5, WAP GW 500 включает в себя блок 501 приема, блок 502 определения и блок 503 решения.

Блок 501 приема сконфигурирован для приема сервисного запроса, включающего в себя URL-адрес.

Блок 502 определения сконфигурирован для определения, соответствует ли URL-адрес сервисному потоку.

Блок 503 решения сконфигурирован для решения типа содержимого сервиса, включенного в сервисный запрос, чтобы идентифицировать тип сервиса из сервисного запроса, когда результат определения из блока 502 определения указывает, что URL-адрес не соответствует сервисному потоку.

Блок 502 определения может определять, соответствует ли URL-адрес сервисному потоку. Дополнительно, блок 502 определения может определять, является ли URL-адрес, включенный в сервисный запрос, URL-адресом MMSC или адресом домашнего PIM-сервера пользователя.

Результат решения блока 503 решения может включать в себя тип содержимого сервиса, к которому принадлежит сервисный запрос, например MMS-сервис или PIM-сервис.

WAP GW 500 может дополнительно включать в себя блок 504 передачи, сконфигурированный для передачи запроса для опроса адреса сервера сервиса, соответствующий идентифицированному типу сервиса. Например, когда результатом решения является MMS-сервис, блок 504 передачи может передавать ENUM-серверу 300 запрос для опроса адреса домашнего MMSC пользователя.

WAP GW 500 в процедуре обработки сервисного запроса может быть описан следующим образом.

WAP GW 500 может типично быть гостевым WAP GW. После того, как блок 501 приема принимает от пользователя в роуминге сервисный запрос, включающий в себя, как правило, URL-адрес, блок 503 решения может решать тип содержимого сервиса, включенный в сервисный запрос. Перед решением блока 503 решения блок 502 определения может определять, является ли URL-адрес, включенный в сервисный запрос, URL-адресом MMSC, таким как "http://mmsc.monternet.com". Если определяется, что URL-адрес, включенный в сервисный запрос, не является URL-адресом MMSC, блок решения может решать тип содержимого сервиса, включенный в сервисный запрос, и тип сервиса из сервисного запроса идентифицируется согласно результату решения (а именно, по типу содержимого сервиса). Если идентифицируется, что тип сервиса из сервисного запроса является MMS-сервисом, может также быть определено, что сервисный запрос является запросом для передачи MMS-сервиса. После чего запрос для опроса адреса домашнего MMSC пользователя передается ENUM-серверу 300. Последующие этапы переходят к процедуре предшествующего уровня техники и не описаны дополнительно в данном документе.

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

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

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

Шлюзом протокола приложений может быть, например, WAP GW 500, показанный на фиг. 5 и сконфигурированный для решения сервисного запроса, переданного терминалом, идентификации типа сервиса из сервисного запроса согласно полю типа содержимого сервиса и обработки сервисной процедуры согласно идентифицированному типу сервиса.

Сервер приложений может быть, например, ENUM-сервером 300, показанным на фиг. 5 и сконфигурированным для приема опрашивающего запроса от шлюза протокола приложений и опроса адреса сервера сервиса, соответствующего идентифицированному типу сервиса. Опрос адреса сервера сервиса, соответствующего идентифицированному типу сервиса, дополнительно описан следующим образом: Обращаясь к фиг. 5, например, когда тип сервиса, идентифицированный посредством WAP GW 500, является MMS-сервисом, ENUM-сервер 300 может принимать от WAP GW 500 запрос для опроса адреса домашнего MMSC пользователя и возвращать в WAP GW 500 результат опроса, включающий в себя адрес домашнего MMSC пользователя. Здесь, сервер, соответствующий MMS-сервису, является домашним MMSC пользователя. Снова в качестве примера, когда тип сервиса, идентифицированный посредством WAP GW 500, является PIM-сервисом, ENUM-сервер 300 опрашивается, чтобы получать адрес домашнего PIM-сервера пользователя, и WAP GW 500 может пересылать сервисный запрос домашнему PIM-серверу пользователя. Здесь, сервер сервиса, соответствующий PIM-сервису, является PIM-сервером.

Обращаясь к фиг. 5, WAP GW 500 может дополнительно включать в себя блок 501 приема, блок 502 определения и блок 503 решения.

Блок 501 приема сконфигурирован для приема сервисного запроса, включающего в себя URL-адрес.

Блок 502 определения сконфигурирован для определения, соответствует ли URL-адрес сервисному потоку.

Блок 503 решения сконфигурирован для решения типа содержимого сервиса, включенного в сервисный запрос, и идентификации типа сервиса из сервисного запроса, когда результат определения блока 502 определения указывает, что URL-адрес не соответствует сервисному потоку.

Блок 502 определения может определять, соответствует ли URL-адрес сервисному потоку. Дополнительно, блок 502 определения может определять, является ли URL-адрес, включенный в сервисный запрос, URL-адресом MMSC или адресом домашнего PIM-сервера пользователя.

Результат решения блока 503 решения может включать в себя тип содержимого сервиса, к которому принадлежит сервисный запрос, например MMS-сервис или PIM-сервис.

WAP GW 500 может дополнительно включать в себя блок 504 передачи, сконфигурированный для передачи запроса для опроса адреса сервера сервиса, соответствующего идентифицированному типу сервиса. Например, когда результатом решения является MMS-сервис, блок 504 передачи может передавать ENUM-серверу 300 запрос для опроса адреса домашнего MMSC пользователя.

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

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

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

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

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

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

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

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

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

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

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

9. Система сервисной обработки по п.8, отличающаяся тем, что терминал является гостевым терминалом, а сервисный запрос передается гостевым терминалом.