Способ, система и устройство для реализации услуги обмена мультимедийными сообщениями

Иллюстрации

Показать все

Изобретение относится к области связи, в частности к способу, системе и устройству для реализации услуг обмена мультимедийными сообщениями (MMS). Техническим результатом является снижение нагрузки на центр услуг обмена мультимедийными сообщениями (MMSC). Указанный технический результат достигается тем, что предложен способ для реализации услуги обмена MMS, включающий в себя: прием посредством MMSC, запроса подачи сообщения; отыскание посредством MMSC из хранимой информации о подписке на сообщение и согласно ID пользователя, передаваемой в запросе подачи сообщения, точки запуска услуги, на которую подписывается функциональный модуль управления услугой обмена сообщениями (MSCF) за пользователя; и отправку посредством MMSC запроса обработки услуги в MSCF, когда достигнута точка запуска услуги, и запрос обработки услуги включает в себя ID пользователя, так что MSCF отыскивает, из хранимой информации о подписке на сообщение и согласно ID пользователя, несомой в запросе обработки сообщения, услугу, на которую подписывается пользователь, и выполняет соответствующую обработку услуги. 5 н. и 5 з.п. ф-лы, 6 ил.

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Услуга обмена мультимедийными сообщениями (MMS) является дальнейшим развитием службы коротких сообщений (SMS) и службы расширенных сообщений (EMS), и она предоставляет полное сквозное решение для персональных мультимедийных услуг мобильной связи.

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

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

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

прием посредством центра услуг обмена мультимедийными сообщениями (MMSC) запроса подачи сообщения;

поиск посредством MMSC, по хранимой информации о подписке на сообщение и согласно идентификации (ID) пользователя, несомой в запросе подачи сообщения, точки запуска услуги, на которую подписывается функциональный модуль управления услугой обмена сообщениями (MSCF) за пользователя; и

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

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

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

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

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

блок приема запроса обработки услуги, сконфигурированный для приема запроса обработки услуги;

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

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

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

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

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

блок отправки запроса обработки услуги, сконфигурированный для отправки запроса обработки услуги в MSCF, когда достигнута точка запуска услуги.

Варианты осуществления настоящего изобретения, кроме того, предусматривают систему для реализации MMS, включающую в себя: MMSC и MSCF, при этом

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

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

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

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

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

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

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

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

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

фиг.5 - конструктивная схема MSCF согласно варианту осуществления настоящего изобретения; и

фиг.6 - конструктивная схема системы для реализации MMS согласно варианту осуществления настоящего изобретения;

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

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

Техническая спецификация 24.140 3GPP определяет интерфейс MM10, вводит концепцию функционального модуля управления услугами обмена сообщениями (MSCF) и излагает последовательность операций взаимодействия между MMSC и MSCF.

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

Таблица 1
Сообщение Тип Направление
Запрос подписки на сообщение (MM10_Subscribe.REQ) Запрос MSCF -> MMSC
Ответ подписки на сообщение (MM10_Subscribe.RES) Ответ MMSC -> MSCF
Запрос обработки услуги (MM10_Interrogation.REQ) Запрос MMSC -> MSCF
Ответ обработки услуги (MM10_Interrogation.RES) Ответ MSCF -> MMSC

Сообщение MM10_Subscribe.REQ инициировано посредством MSCF для подписки на сообщение из MMSC. Сообщение MM10_Interrogation.REQ/.RES является сообщением, полученным расширением нескольких полей в сообщении MM10_Interogation.REQ/.RES, предписанном в текущем протоколе стандарта 3GPP; сообщение MM10_Interrogation.REQ инициируется посредством MMSC для запуска сообщения, поданного пользователем в MSCF для соответствующей обработки услуги.

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

Таблица 2 Определение запроса подписки, MM10_Subscribe.REQ
Элемент информации Наличие Описание
Тип сообщения Обязательное Тип сообщения, и его значением является "MM10_Subscribe.REQ"
ID транзакции Обязательное ID транзакции, для идентификации соответствующей взаимосвязи с MM10_Subscribe.RES
Абонент Обязательное Номер абонента, который подписался на услугу
Точка запуска Обязательное Точка запуска для MMSC для пересылки сообщения в MSCF.4 точки запуска заданы для пользователя отправителя:• точка 1 запуска услуги отправителя (TPA1): MMSC принимает поданное сообщение наряду с тем, что не отправляет ответ, код 0xF0• точка 2 запуска услуги отправителя (TPA2): MMSC принимает поданное сообщение и отправил ответ, код 0xF1• точка 3 запуска услуги отправителя (TPA3): MMSC начал отправлять уведомляющее сообщение получателю, код 0xF2• точка 4 запуска услуги отправителя (TPA4): MMSC обработал сообщение, поданное пользователем, код 0xF33 точки запуска заданы для получателя:• точка 1 запуска услуги получателя (TPB1): Прежде, MMSC доставляет уведомление с активной доставкой получателю, код 0xF4• точка 2 запуска услуги получателя (TPB2): MMSC успешно доставляет уведомление с активной доставкой получателю, код 0xF5• точка 3 запуска услуги получателя (TPB3): MMSC завершил поток доставки сообщений, код 0xF6
Необходимо тело Необязательное Должно ли тело сообщения переноситься в сообщении, пересылаемом из MMSC в MSCF
Ожидать ответа Необязательное Должен ли ожидаться ответ после того, как MMSC пересылает сообщение в MSCF
Таблица 3 Определение ответа на запрос подписки, MM10_Subscribe.RES
Элемент информации Наличие Описание
Тип сообщения Обязательное Тип сообщения, и его значением является "MM10_Subscribe.RES"
ID транзакции Обязательное ID транзакции, для идентификации соответствующей взаимосвязи с MM10_Subscribe.REQ
Код состояния Обязательное Индикация, имеет ли успех подписка
Таблица 4 Определение запроса обработки услуги, MM10_Interrogation.REQ
Элемент информации Наличие Описание
Тип сообщения Обязательное Тип сообщения, и его значением является "MM10_Interrogation.REQ"
ID транзакции Обязательное ID транзакции для идентификации соответствующей взаимосвязи с MM10_Interrogation.RES
Событие запуска Обязательное Точка запуска, которая инициируется отправкой MM10_Interrogation.REQ
ID сообщения Обязательное ID мультимедийного сообщения (MM)
ID сообщения инициатора Необязательное Исходный ID сообщения. Если сообщение пересылается из другого MMSC, ID сообщения в исходном MMSC будет размещено в этом поле и перенесено в MSCF
Адрес получателя(ей) Обязательное Адрес получателя сообщения: могут быть многочисленные адреса
Адрес отправителя Обязательное Адрес отправителя сообщения
Представление отправителя Необязательное ID отправителя, представленный получателю
Тип контента Обязательное Тип контента, соответствующий контенту сообщения
Класс сообщения Необязательное Класс сообщения (например, персональная услуга, рекламная услуга и информационная услуга)
Дата и время Обязательное Дата и время, когда UA в последнее время обрабатывает (то есть подает или пересылает) MM
Время истечения Необязательное Время прекращения действия с истечением срока у сообщения
Самое раннее время доставки Необязательное Самое раннее время доставки
Отчет о доставке Необязательное Запрос отчета о доставке
Отчет о доставке R/S инициатора Необязательное Запрос отчета о доставке MMSC. Что касается сообщения, пересланного из другого MMSC, поле указывает, запрашивает ли MMSC отправителя отчет о доставке MM
Приоритет Необязательное Приоритет сообщения
Видимость отправителя Необязательное Требование отображения или сокрытия ID отправителя, когда сообщение отправляется получателю
Читать ответ Необязательное Запрос отчета о прочтении ответа
Тема Необязательное Тема сообщения
Счетчик пересылки Необязательное Счетчик для индикации количества раз, которое пересылается сообщение
Ранее отправлено от Необязательное При условии пересылки информационное устройство адресует одного или более UA MMS, обработавших (то есть переславших или подавших) сообщение, эти UA являются предшествующими, нежели UA MMS, имеющий адрес, включенный адрес "отправителя" информационного устройства. Очередности выданных адресов будут отмечены. Адрес UA MMS инициатора будет отмечен.
Отправленные ранее дата и время Необязательное Дата и время, когда UA MMS заблаговременно обрабатывает (пересылает или подает) MM
ID приложения Необязательное Целевой ID приложения
ID приложения ответа Необязательное ID тракта воспроизведения MM
Информация о вспомогательном приложении Необязательное Информация об адресе вспомогательного приложения
Класс контента Необязательное Класс полезной информации, включенной в контент MM
Контент DRM Необязательное Указание, что контент MM включает в себя информацию о защите цифровым водяным знаком
Адаптации Необязательное Указание, может ли быть выполнена адаптация контента в отношении контента MM (задано значение по умолчанию Истина)
Адрес системы инициатора Необязательное Адрес MMSC отправителя, для сообщения, пересланного из другого MMSC, это поле должно быть заполнено
Состояние отправки Необязательное Состояние отправки сообщения, которое может быть действительным только в TPA4 и TPB3
Содержимое Необязательное Контент MM
Таблица 5 Определение ответа на запрос обработки услуги, MM10_Interrogation.RES
Информационное устройство Состояние существования Описание
Тип сообщения Обязательное Тип сообщения, и его значением является "MM10_Interrogation.RES"
ID транзакции Обязательное ID транзакции для идентификации соответствующей взаимосвязи с MM10_Interrogation.REQ
Состояние обработки Обязательное Состояние обработки, включающее в себя: допущено, отклонено, сообщение модифицировано, нормально завершено, завершено аномально
ID сообщения Обязательное ID MM
Адрес получателя(ей) Обязательное Адрес получателя сообщения: могут быть многочисленные адреса
Адрес отправителя Обязательное Адрес отправителя сообщения
Тип контента Обязательное Тип контента, соответствующий контенту сообщения
Класс сообщения Необязательное Класс сообщения (например, персональная услуга, рекламная услуга и информационная услуга)
Время истечения Необязательное Время прекращения действия с истечением срока у сообщения
Самое раннее время доставки Необязательное Самое раннее время доставки
Отчет о доставке Необязательное Запрос отчета о доставке
Приоритет Необязательное Приоритет сообщения
Видимость отправителя Необязательное Требование отображения или сокрытия ID отправителя, когда сообщение отправляется получателю
Читать ответ Необязательное Запрос отчета о прочтении ответа
Тема Необязательное Тема сообщения
Счетчик пересылки Необязательное Счетчик для индикации количества раз, которое пересылается сообщение
Класс контента Необязательное Класс полезной информации, включенной в контент MM
Содержимое Необязательное Контент MM

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

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

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

Этап 101: Агент пользователя подает запрос подписки на услугу, несущий информацию о подписке на услугу, в MSCF;

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

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

Когда запрос подписки является запросом подписки на услугу подписи, информация о подписке на услугу дополнительно несет подпись, заданную пользователем.

Этап 102: MSCF сохраняет информацию о подписке на услугу и отправляет, в MMSC, запрос подписки на сообщение (например, MM10_Subscribe.REQ), несущий информацию о подписке на сообщение;

Информация о подписке на сообщение может включать в себя: ID пользователя и точку запуска услуги, для указания MMSC того, что MMSC будет отправлять запрос обработки услуги в MSCF после приема сообщения, поданного пользователем, соответствующим ID пользователя, и указания точки запуска, когда MMSC будет отправлять запрос обработки услуги в MSCF.

Этап 103: MMSC сохраняет информацию о подписке на сообщение и возвращает ответ на запрос подписки на сообщение (например, MM10_Subscribe.REQ) в MSCF.

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

Этап 104: UA отправителя (UA инициатора) подает запрос подачи сообщения (например, MM1_Submit.REQ) в MMSC;

Этап 105: MMSC отыскивает, из хранимой информации о подписке на сообщение и согласно ID пользователя, несомой в запросе подачи сообщения, точки запуска услуги, на которую подписывается MSCF за пользователя; и MMSC отправляет запрос обработки услуги (например, MM10_Interrogation.REQ) в MSCF, когда достигается точка запуска услуги.

Этап 106: MSCF отыскивает, из хранимой информации о подписке на услугу и согласно ID пользователя, несомой в запросе обработки услуги, услугу, на которую подписывается пользователь, выполняет соответствующую обработку услуги и возвращает ответ на запрос обработки услуги (например, MM10_Interrogation.RES) в MMSC.

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

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

I. Услуга подписи

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

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

Этап 201: Агент пользователя подает запрос подписки на услугу подписи в MSCF;

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

Этап 202: MSCF сохраняет информацию о подписке на услугу и отправляет запрос подписки на сообщение (например, MM10_Subscribe.REQ), несущий информацию о подписке на сообщение, в MMSC;

Точка запуска услуги в информации о подписке на сообщение может быть точкой TAP1 или точкой TAP2, а информация о подписке на услугу может включать в себя: индикатор тела сообщения (например, поле "Необходимо тело") и индикатор ожидания ответа (например, поле "Ожидание ответа") для указания MMSC того, что MMSC будет нести тело сообщения запроса подачи сообщения (например, MM1_Submit.REQ) в запросе обработки услуги при отправке запроса обработки услуги, а затем ожидать ответа из MSCF.

В практической реализации, поле "Абонент" в запросе подписки на сообщение (например, MM10_Subscribe.REQ) используется для переноса ID пользователя, поле "Точка запуска" используется для переноса точки запуска услуги, а поля "Необходимо тело" и "Ожидание ответа" используются для указания MMSC того, что MMSC будет нести тело сообщения при отправке запроса обработки услуги, а затем ожидать ответа из MSCF.

Этап 203: MMSC сохраняет информацию о подписке на сообщение, несомую в запросе подписки на сообщение (например, MM10_Subscribe.REQ), и возвращает ответ на запрос подписки на сообщение (например, MM10_Subscribe.RES) в MSCF.

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

Этап 204: UA отправителя подает запрос подачи сообщения (например, MM1_Submit.REQ) в MMSC;

Запрос подачи сообщения (например, MM1_Submit.REQ) несет ID отправителя, ID получателя и тело сообщения.

Этап 205: Из хранимой информации о подписке на сообщение, MMSC находит, согласно ID отправителя, несомой в запросе подачи сообщения (MM1_Submit.REQ), что точкой запуска услуги, на которую MSCF подписывается за пользователя, является TPA2; и MMSC возвращает ответ на запрос подачи сообщения (например, MM1_Submit.RES) на UA отправителя.

Этап 206: MMSC достигает TPA2, затем отправляет запрос обработки услуги (например, MM10_Interrogation.REQ) в MSCF и ожидает ответа из MSCF.

Запрос обработки услуги (например, MM10_Interrogation.REQ) может включать в себя поле "Адрес отправителя", "Тип контента" и "Контент", и поле "Контент" используется для переноса тела сообщения.

Этап 207: Из хранимой информации о подписке на услугу, после приема запроса обработки услуги (например, MM10_Interrogation.REQ), MSCF находит, согласно ID отправителя, что пользователь подписывается на услугу подписи; затем MSCF выполняет разбор полей "Тип контента" и "Контент", добавляет подпись, предварительно заданную отправителем, к телу сообщения и возвращает ответ на запрос обработки услуги (например, MM10_Interrogation.RES) в MMSC.

В практической реализации, MSCF помещает тело сообщения, дополненное подписью, в поле контента ответа на запрос обработки услуги (например, MM10_Interrogation.RES) и возвращает его на MMSC, и указывает MMSC, через поле "Состояние обработки" ответа на запрос обработки услуги (например, MM10_Interrogation.RES), что MMSC будет модифицировать сообщение.

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

Этап 208: MMSC сохраняет тело сообщения, дополненное подписью, согласно команде поля "Состояние обработки" и отправляет уведомляющее сообщение (например, MM1_Notification.REQ) на UA получателя.

Этап 209: UA получателя возвращает ответ на уведомление (например, MM1_Notification.RES).

Этап 210: Агент пользователя-получателя отправляет запрос извлечения сообщения (например, MM1_Retrieve.REQ).

Этап 211: MMSC возвращает ответ на запрос извлечения сообщения (например, MM1_Retrieve.RES) на UA получателя и отправляет тело сообщения, дополненное подписью, на UA получателя через ответ на запрос извлечения сообщения (например, MM1_Retrieve.RES).

Этап 212: UA получателя отправляет сообщение подтверждения успеха извлечения (например, MM1_Acknowledge.REQ) в MMSC.

Кроме того, если отправитель требует, чтобы MMSC возвращал отчет о доставке, способ дополнительно включает в себя, после того, как MMSC принимает сообщение подтверждения успеха извлечения (например, MM1_Acknowledge.REQ):

Этап 213: MMSC возвращает запрос отчета о доставке (например, MM1_DeliveryReport.REQ) на UA отправителя.

Этап 214: UA отправителя возвращает ответ на отчет о доставке (например, MM1_DeliveryReport.RES) в MMSC.

Выше описана последовательность операций реализации услуги подписи, предусмотренная вариантом осуществления настоящего изобретения, когда точкой запуска услуги является TPA2. Вторая последовательность операций реализации, когда точкой запуска услуги является TPA2, состоит в том, что MMSC сначала может возвращать ответ на запрос подачи сообщения (например, MM1_Submit.RES) на UA отправителя на этапе 205, а затем отыскивает точку запуска услуги, на которую MSCF подписывается за пользователя, что не оказывает влияния на реализацию настоящего изобретения. Если точкой запуска услуги является TPA1, последовательность операций реализации является по существу такой же, как в случае TPA2, а разница состоит всего лишь в том, что MMSC отправляет запрос обработки услуги на MSCF до возврата ответа на запрос подачи сообщения (например, MM1_Submit.RES) на UA отправителя.

II. Услуга приема вызова

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

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

Этап 301: Пользователь подает, в MSCF, запрос подписки на услугу приема вызова, несущий информацию о подписке на услугу;

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

Этап 302: MSCF сохраняет информацию о подписке на услугу и отправляет запрос подписки на сообщение (например, MM10_Subscribe.REQ), несущий информацию о подписке на сообщение, в MMSC;

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

В практической реализации, поле "Подписаться" запроса подписки на сообщение (например, MM10_Subscribe.REQ) используется для переноса ID пользователя, а поле "Точка запуска" используется для переноса точки запуска услуги.

Этап 303: MMSC сохраняет информацию о подписке на сообщение и возвращает ответ на запрос подписки на сообщение (например, MM10_Subscribe.RES) в MSCF.

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

Этап 304: UA отправителя подает, в MMSC, запрос подачи сообщения (например, MM1_Submit.REQ).

Этап 305: Из хранимой информации о подписке на сообщение, MMSC находит, согласно ID отправителя, что точками запуска, на которые MSCF подписывается за пользователя, являются TPA3 и TPA4, и возвращает ответ на запрос подачи сообщения (например, MM1_Submit.RES) на UA отправителя.

Этап 306: MMSC отправляет уведомляющее сообщение (например, MM1_Notification.REQ) на UA получателя.

Этап 307: UA получателя возвращает ответ на уведомление (например, MM1_Notification.RES) в MMSC.

Этап 308: MMSC достигает TPA3, затем отправляет запрос обработки услуги (например, MM10_Interrogation.REQ) в MSCF.

В практической реализации, поле адреса отправителя в запросе обработки услуги (например, MM10_Interrogation.REQ) несет ID отправителя.

Этап 309: Из хранимой информации о подписке на услугу, MSCF находит, согласно ID отправителя, что пользователь подписывается на услугу приема вызова, и отправляет сообщение приема на UA отправителя, чтобы напомнить отправителю, что было отправлено уведомление с активной доставкой.

Этап 310: UA получателя отправляет запрос извлечения сообщения (например, MM1_Retrieve.REQ);

Этап 311: MMSC возвращает ответ на запрос извлечения сообщения (например, MM1_Retrieve.RES);

Поле контента сообщения ответа извлечения сообщения (например, MM1_Retrieve.RES) включает в себя тело сообщения, и если пользователь-отправитель также подписывается на услугу подписи, ответ на запрос извлечения сообщения (например, MM1_Retrieve.RES) несет тело сообщения, дополненное подписью.

Этап 312: UA получателя отправляет сообщение подтверждения успеха извлечения (например, MM1_Acknowledge.REQ) в MMSC.

Этап 313: MMSC достигает TPA4, затем отправляет запрос обработки услуги (например, MM10_Interrogation.REQ) в MSCF.

В практической реализации, запрос обработки услуги (например, MM10_Interrogation.REQ) может нести поля "Адрес отправителя" и "Состояние отправки".

Этап 314: MSCF извлекает ID отправителя из поля "Адрес отправителя" после приема запроса обработки услуги (например, MM10_Interrogation.REQ), извлекает состояние доставки сообщения согласно полю "Состояние отправки" и отправляет сообщение приема на UA отправителя для уведомления пользователя об окончательном результате доставки сообщения.

Кроме того, если пользователь требует, чтобы MMSC возвращал отчет о доставке, после того, как MMSC отправляет запрос обработки обслуживания (например, MM10_Interrogation.REQ) в MSCF, способ дополнительно включает в себя:

Этап 315: MMSC возвращает запрос отчета о доставке (например, MM1_DeliveryReport.REQ) на UA отправителя.

Этап 316: UA отправителя возвращает ответ на запрос отчета о доставке (например, MM1_DeliveryReport.RES) в MMSC.

То, что было описано выше, является одним из способов для реализации услуги приема вызова, предусмотренным вариантом осуществления настоящего изобретения, и, в других вариантах осуществления настоящего изобретения, этап 305 может выполняться после этапа 306 или между этапами 307 и 308, а реализация вариантов осуществления настоящего изобретения не будет подвергаться влиянию.

III. Спонсорская услуга

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

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

Этап 401: Пользователь подает запрос подписки на спонсорскую услугу, несущий информацию о подписке на услугу, в MSCF;

Информация о подписке на услугу включает в себя ID пользователя и ID типа услуги.

Этап 402: MSCF сохраняет информацию о подписке на услугу и отправляет запрос подписки на сообщение (например, MM10_Subscribe.REQ), несущий информацию о подписке на сообщение, в MMSC;

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

Этап 403: MMSC сохраняет информацию о подписке на сообщение в запросе подписки на сообщение (например, MM10_Subscribe.REQ) и возвращает ответ на запрос подписки на сообщение (например, MM10_Subscribe.RES) в MSCF.

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

Этап 404: UA отправителя подает запрос подачи сообщения (например, MM1_Submit.REQ) в MMSC.

Запрос подачи сообщения (например, MM1_Submit.REQ) включает в себя: ID отправителя, ID получателя и тело сообщения.

Этап 405: Из хранимой информации о подписке на сообщение, MMSC находит, согласно ID отправителя, что точками запуска, на которые MSCF подписывается для пользователя, являются TPB1 и TPB3, и возвращает ответ на запрос подачи сообщения (например, MM1_Submit.RES) на UA отправителя.

Этап 406: MMSC достигает TPB1, отправляет запрос обработки услуги (например, MM10_Interrogation.REQ) в MSCF и ожидает ответа из MSCF.

В практической реализации, поля "Тип контента" и "Контент" могут включать в себя запрос обработки услуги (например, MM10_Interrogation.REQ).

Этап 407: После приема запроса обработки услуги (например, MM10_Interrogation.REQ) MSCF находит, из хранимой информации о подписке на услугу и согласно ID получателя, что пользователь-получатель