ОБМЕН СООБЩЕНИЯМИ В СТРАНИЧНОМ РЕЖИМЕ

ОБЛАСТЬ ТЕХНИКИ

Настоящее изобретение относится к обмену сообщениями, более конкретно к страничному обмену сообщениями, также называемому "разовым" обменом сообщениями.

УРОВЕНЬ ТЕХНИКИ

С развитием технологий связи, особенно технологий IP-связи и терминалов конечного пользователя, стали доступны разносторонние возможности связи и предоставление различных услуг. Все более часто услуги реализованы с использованием примитивов, предоставляемых протоколом инициирования сессии (Session Initiation Protocol, SIP), который не интегрирован вертикально в систему связи, а является средством для построения архитектуры мультимедиа. Боле точно, SIP - это определенный управляющий протокол (сигнализация) прикладного уровня, разработанный IETF для создания, изменения и прекращения сессий с одним или более участником. Эти сессии включают, например, телефонные интернет-звонки, распространение мультимедиа, мультимедиа-конференции и сессии РоС (Push to talk over Cellular, "нажми кнопку и говори по сотовой"). Для услуг обмена сообщениями IETF был определен протокол SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions, расширения протокола SIP для мгновенных сообщений и функций присутствия), использующий SIP и существующие реализации SIP для обеспечения службы присутствия и мгновенного обмена сообщениями. ОМА (Open Mobile Alliance, "Открытый Мобильный Альянс") также определяет поставщика службы мгновенных сообщений (IM, Instant Messaging) на базе протоколов SIP/SIMPLE. SIMPLE определяет два режима для обмена мгновенными сообщениями: страничный и сессионный. Страничный режим использует метод SIP MESSAGE, которым отсылается страничное мгновенное сообщение, и где (на уровне протокола) последовательные мгновенные сообщения не связаны с предыдущими: каждое текущее сообщение, даже ответ на предыдущее сообщение, считается независимой транзакцией. Таким образом, SIP MESSAGE имеет сходство с обычным электронным письмом или услугой коротких сообщений (SMS). Сессионный режим использует SIP для сигнализации и установления сессии и MSRP (Message Session Relay Protocol, протокол ретрансляции сессионных сообщений) для передачи последовательности мгновенных сообщений после того, как сессия будет установлена. Далее эта комбинация упрощенно названа «MSRP-механизм». Другими словами, MSRP-механизм обеспечивает обмен сообщениями по типу чата, названный сессионным обменом сообщениями.

Проблема возникает, когда пользователь желает отправить большое страничное сообщение. Метод SIP MESSAGE может использовать либо UDP, либо TCP-транспорт. TCP обеспечивает надежный способ транспортировки также и для больших сообщений, однако TCP-транспорт не всегда может быть гарантированно предоставлен для метода SIP MESSAGE. Если для отправки больших сообщений использован UDP, пакеты, большие, чем максимальный размер UDP, фрагментированы и могут прибывать к получателю в неправильном порядке. Кроме того, даже если TCP может быть гарантирован, остается другая проблема, связанная с контролем нагрузки. Поскольку метод SIP MESSAGE является частью сигнализации управления сессией SIP, сообщения отправляются и принимаются с использованием в точности тех же ресурсов, что и для сигнализации SIP. Для терминала пользователя это означает, что действующая сигнализация SIP может быть блокирована на время передачи или приема большого сообщения терминалом пользователя. Вышеуказанный ресурс для сигнализации SIP может, например, являться контекстом общего применения протокола PDP (Packed Data Protocol, протокол передачи пакетных данных) или специальным контекстом сигнализации протокола PDP в случае систем GERAN (GSM/EDGE Radio Access Network) и/или UTRAN (UMTS Terrestrial Radio Access Network). В других системах для ресурса может, например, резервироваться и/или использоваться специальная полоса канала для сигнализации. Вдобавок к блокированию сигнализации SIP может возникнуть дальнейшая проблема, связанная с нагрузкой на прокси-сервер SIP. Поскольку страничное сообщение обычно использует метод SIP MESSAGE, все сообщения, использующие метод SIP MESSAGE, передаются через прокси-сервер SIP. В итоге страничные сообщения большого размера, передаваемые через прокси-сервер SIP, могут вызвать резкое уменьшение производительности прокси-сервера SIP, ведущее к фактическому блокированию всей сигнализации SIP и уменьшению общей производительности сети SIP. Таким образом, в некоторых случаях метод SIP MESSAGE не пригоден к использованию для сообщения большого размера.

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

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

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

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

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

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

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

фиг.1 - упрощенная архитектура системы;

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

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

фиг.5А и 5D - примеры сообщений SIP INVITE в соответствии с реализациями данного изобретения;

фиг.6, 7, 8 и 9 - сигнализация в соответствии с реализациями данного изобретения.

ПОДРОБНОЕ ОПИСАНИЕ НЕКОТОРЫХ РЕАЛИЗАЦИЙ

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

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

Далее настоящее изобретение будет описано с использованием в качестве примера среды, в которой может быть применено настоящее изобретение, весьма упрощенной системной среды, использующей SIP и MSRP, без ограничения этим примером данного изобретения. Ясно, что система связи и промежуточные узлы, такие как прокси-сервер и другие используемые протоколы, кроме SIP и MSRP, либо соответствующие протоколы, не относятся к данному изобретению. Поэтому они не нуждаются здесь в более конкретном обсуждении. Настоящее изобретение в основном относится к передаче сообщений на прикладном уровне.

Фиг.1 - упрощенная архитектура системы, показывающая только систему связи 1, два терминала пользователя UT 2, 2' и сеть 3. Для специалиста ясно, что система (системы) также включает (включают) другие устройства, системные объекты, такие как серверы мгновенных сообщений, функции и структуры, которые не нуждаются здесь в описании.

Терминал пользователя UT 2, 2' - это часть оборудования или устройство, которое позволяет пользователю взаимодействовать с системой связи напрямую или через компьютерную систему, то есть предоставлять информацию и возможность ввода информации пользователю, т.е. терминал пользователя - это конечная точка отдельно взятой передачи информации. Другими словами, терминал пользователя UT 2, 2' может быть любым узлом или хостом, который поддерживает обмен сообщениями и способен к обмену информацией с сетью системы по сети доступа (не показанной на фиг.1), если таковая сеть доступа существует. Терминал пользователя UT 2, 2' может быть немобильным устройством, таким как персональный компьютер (PC), подключенный к сети 3 беспроводной или фиксированной связью. Терминал пользователя UT 2, 2' также может быть беспроводным мобильным терминалом, поддерживающим обмен сообщениями, мультисервисным терминалом, который работает в качестве платформы услуг и поддерживает загрузку и выполнение различных функций, относящихся к услугам, лаптопом, подключенным к сети (посредством возможной сети доступа), персональным цифровым ассистентом (PDA), подключаемым к сети (посредством возможной сети доступа), и т.д.

Терминал пользователя 2 включает хотя бы один интерфейс пользователя (UI) 21, посредством которого пользователь может создавать и/или читать сообщения, одно или более приложение (Аррl) 22 для обмена сообщениями, память (Mem) 23 (либо терминал пользователя имеет возможность для доступа к памяти) для сохранения принятых страничных сообщений (хотя бы временно) и приемопередатчик (TRx) 24 для отправки и приема информации (сообщений).

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

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

Фиг.2 начинается с момента, когда пользователь создал страничное сообщение и дал посредством интерфейса пользователя инструкции отослать сообщение в приемник (шаг 201). Другими словами, терминал пользователя принимает на шаге 201 команду «послать сообщение по этому адресу». В ответ на эту команду терминал пользователя определяет на шаге 202 размер сообщения и проверяет на шаге 203, превышает размер сообщения заранее заданный предел размера или нет. Заранее заданный предел может быть определен, например, использованным протоколом услуги, пользователем, оператором, либо это может быть изначально сконфигурировано для терминала. Предпочтительно, чтобы заранее заданный предел соответствовал размеру, который укладывается в сообщение транспортного протокола. Однако значение заранее заданного предела и путь, которым этот лимит определен, не существенен для настоящего изобретения. В некоторых реализациях данного изобретения даже возможно, чтобы все страничные сообщения независимо от их размера посылались с использованием MSRP-механизма или соответствующего механизма. Например, терминал пользователя может быть изначально сконфигурирован для использования сессионного режима всегда, из-за того что оператор не позволяет использовать страничный режим.

Если размер сообщения не превышает предел (шаг 203), терминал пользователя посылает (на шаге 204) содержимое с использованием метода SIP MESSAGE (сообщение SIP).

Если размер сообщения превышает предел (шаг 203), терминал пользователя посылает (на шаге 205) сообщение с использованием MSRP-механизма, причем в соответствии с данным изобретением с признаком страничного режима. В зависимости от реализации терминал пользователя может либо добавлять к страничному сообщению, отосланному посредством MSRP, информацию о реальном размере сообщения либо нет. Реальная процедура отправки сообщения показана более подробно на фиг.6, 7 и 8.

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

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

В ответ на прием SIP INVITE (приглашение SIP) (MSRP) (шаг 301) терминал пользователя проверяет на шаге 302, для страничного сообщения используется данный SIP INVITE (MSRP) или нет. Если да, терминал пользователя устанавливает на шаге 303 сессию; принимает на шаге 304 сообщение и сохраняет на шаге 305 сообщение; затем прекращает на шаге 306 сессию. После этого или одновременно терминал пользователя указывает на шаге 307 пользователю, что сообщение принято. Следовательно, пользователь может прочитать сообщение позже. Другими словами, терминал пользователя взаимодействует с пользователем, как если бы сообщение было принято методом SIP MESSAGE.

Если SIP INVITE (MSRP) предназначено для чата (т.е. для сессионного обмена сообщениями), а не для страничного сообщения (шаг 302), терминал пользователя устанавливает на шаге 308 сессию и показывает на шаге 309 диалог до конца сессии.

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

Принимающий терминал пользователя может быть сконфигурирован для перенаправления запроса страничного сообщения во входящий почтовый ящик сети, на другой терминал и т.д., в этом случае сессия не устанавливается, а вместо шагов 303…307 запрос перенаправляется. Примеры таких ситуаций показаны на фиг.7 и 8. Даже если все страничные сообщения перенаправлены для сохранения где-то в другом месте и пользователю для их просмотра нужен другой терминал, перенаправляющий терминал считается обеспечивающим страничный обмен сообщениями.

В другой реализации данного изобретения проверка выполняется после приема сообщения (т.е. шаг 302 выполняется после шага 304, и процесс продолжается после проверки либо на шаге 305, либо на шаге 308).

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

В ответ на прием приглашения SIP INVITE (MSRP) (шаг 401) терминал пользователя проверяет на шаге 402, используется данный SIP INVITE (MSRP) для страничного сообщения или нет. Если да, терминал пользователя уведомляет на шаге 403 пользователя о размере сообщения. Если пользователь принимает сообщение (шаг 404), терминал пользователя устанавливает на шаге 405 сессию; принимает на шаге 406 сообщение и сохраняет на шаге 407 сообщение. Следовательно, пользователь может прочитать сообщение позже. Затем терминал пользователя прекращает на шаге 408 сессию. Другими словами, терминал пользователя взаимодействует с пользователем, как если бы сообщение было принято методом SIP MESSAGE. В этом конкретном примере терминал пользователя не уведомляет пользователя о получении сообщения, так как предполагается, что принимая доставку сообщения, пользователь тем самым уже уведомляется о сообщении. Однако в других реализациях устройство пользователя может быть сконфигурировано также и для уведомления пользователя о получении сообщения.

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

Если приглашение SIP INVITE (MSRP) предназначено для чата (т.е. для сессионного обмена сообщениями), а не для страничного сообщения (шаг 402), терминал пользователя устанавливает на шаге 410 сессию и показывает на шаге 411 диалог до конца сессии.

В другой реализации данного изобретения вместо запроса о том, принимает пользователь сообщение или нет (т.е. вместо шага 403), терминал пользователя сконфигурирован для принятия сообщения, которое не превышает заранее заданный предел размера. Заранее заданный предел может быть определен, например, оператором, производителем терминала пользователя и/или пользователем.

Далее будет более подробно описана сигнализация с некоторыми примерами, показанными на фиг.5А…8, с использованием SDP (Session Description Protocol, протокол описания сессии) для инициирования сессии и MSRP поверх TCP для передачи реального содержимого без ограничения данного изобретения этими примерами. Другое предположение, сделанное в связи со следующими примерами, заключается в том, что принимающий терминал пользователя не отклоняет сообщение. Если требуется, дальнейшая информация может быть найдена в документе http://www.ietf.org/intemet-drafts/draft-ietf-simple-message-sessions-10.txt,

который включен в данное описание путем ссылки. Однако для данного изобретения несущественно, какой из протоколов использовать, и вышеуказанные протоколы являются только примерами. Например, вместо SDP могут быть использованы другие протоколы с механизмом запроса-ответа, и вместо TCP могут быть использованы другие протоколы с контролем нагрузки, такие как SCTP (Signaling Common Transport Protocol, общий транспортный протокол сигнализации).

Фиг.5A…5D показывают некоторые примеры того, как сессионные сообщения могут указывать, что сессионное приглашение предназначено для страничного сообщения.

В реализации на фиг.5А страничное сообщение указано комбинацией m-строки, содержащей новый признак страничного режима 5-1 (m=message 9 msrp page-mode) и параметр a=max-size, указывающий действительный размер сообщения 5-2 (a=max-size: actual size).

В реализации на фиг.5В страничное сообщение указано комбинацией m-строки, содержащей новый признак страничного режима 5-1 (m=message 9 msrp page-mode) и параметр 5-3 a=actual-size, указывающий действительный размер сообщения (a=max-size: actual size). В этой реализации параметр a=max-size указывает максимальный размер сообщения.

В реализации на фиг.5С страничное сообщение указано параметром 5-3 a=actual-size. Когда значение параметра отличается от нуля, это неявно указывает, что сообщение является страничным, и наоборот. В этой реализации информация m-строки указывает, что будет использован MSRP, и параметр a=max-size указывает максимальный размер сообщения.

В реализации на фиг.5D страничное сообщение указано параметром m-строки, содержащим новый признак страничного режима 5-1 (m=message 9 msrp page-mode). В этой реализации параметр a=max-size указывает максимальный размер сообщения, и дополнительного а-параметра не требуется.

В схеме сигнализации на фиг.6. показана сигнализация только между конечными точками, хотя могут быть вовлечены один или более посредников. Фиг.6 демонстрирует сигнализацию, когда получатель, точнее соответствующий клиент в пользовательском терминале получателя, принимает сообщение. Фиг.6 начинается с момента, когда Элис желает отправить сообщение Бобу. Терминал пользователя UT1 Элис (точнее соответствующий клиент в UT1) извещает в точке 6-1, что страничное сообщение должно быть отправлено с использованием сессионного механизма. (Точка 6-1 описана подробно выше, на фиг.2.) Поэтому UT1 посылает сообщение сессионного приглашения 6-2 с признаком страничного режима PMI к терминалу пользователя UT2 Боба. Сообщение 6-2 - предпочтительно одно из сообщений, показанных на фиг.5A…5D. В ответ на прием сообщения 6-2 UT2 определяет в точке 6-3, что это сообщение является сессионным приглашением для страничного сообщения, и принимает приглашение, отправляя сообщение 6-4. UT1 подтверждает прием отправкой сообщения 6-5, и затем UT1 посылает реальное содержимое страничного сообщения в сессионном сообщении 6-6. В ответ на получение содержимого UT2 сохраняет в точке 6-7 содержимое, и Боб может посмотреть его позже. UT2 может также уведомить Боба, как описано выше в отношении фиг.3 и 4. В ответ на получение содержимого UT2 также подтверждает прием отправкой сессионного подтверждения в сообщении 6-8. В реализации, показанной на фиг.6, посылающий терминал пользователя UT1 сконфигурирован на прекращение сессии в ответ на подтверждение путем отправки сообщения 6-9 к UT2, который затем посылает сообщение 6-10, подтверждающее прекращение.

В схеме сигнализации на фиг.7 показана сигнализация между конечными точками с участием сервера мгновенных сообщений в качестве принимающей конечной точки, хотя могут быть вовлечены один или более посредников. Фиг.7 демонстрирует сигнализацию, когда получатель, точнее соответствующий клиент в пользовательском терминале получателя, не принимает сообщение, а запрашивает сеть сохранить это сообщение для дальнейшего извлечения. Фиг.7 начинается с момента, когда Элис желает отправить сообщение Бобу. Терминал пользователя UT1 Элис (точнее соответствующий клиент в UT1) извещает в точке 7-1, что страничное сообщение должно быть отправлено с использованием сессионного механизма. (Точка 7-1 описана подробно выше, на фиг.2.) Поэтому UT1 посылает сообщение сессионного приглашения 7-2 с признаком страничного режима PMI к терминалу пользователя UT2 Боба посредством сервера. Сообщение 7-2 - предпочтительно одно из сообщений, показанных на фиг.5A…5D. В ответ на прием сообщения 7-2 UT2 определяет в точке 7-3, что это сообщение является сессионным приглашением для страничного сообщения. По некоторым причинам UT2 не принимает страничное сообщение, а посылает перенаправляющее сообщение 7-4 к серверу. Одним из примеров перенаправляющего сообщения является сообщение SIP 302 "Moved Temporarily" (временно перемещено), которое может содержать информацию о том, как должно быть обработано сообщение. Однако для данного изобретения несущественно, как и по какому протоколу осуществляется перенаправление, а дополнительные инструкции/информация могут быть даны при необходимости. Другие примеры включают реализацию раздельных транзакций с использованием протоколов SIP, таких как SIP PUBLISH, SIP OPTIONS, вызываемых возможностей в SIP REGISTER, либо с использованием ХСАР (расширяемый язык Configuration Access Protocol с разметкой). UT2 может также уведомить Боба о сообщении, как описано выше на фиг.3 и 4.

В этом примере сервер, точнее двусторонний пользовательский агент, принимает предложение альтернативной услуги, поэтому сервер считает себя конечной точкой сессии и принимает начальное приглашение отправкой сообщения 7-5. UT1 подтверждает прием, отправляя сообщение 7-6 серверу, и затем посылает реальное содержимое страничного сообщения в сессионном сообщении 7-7 серверу. В ответ на прием содержимого сервер сохраняет в точке 7-8 содержимое, и Боб может посмотреть его позже. В ответ на прием содержимого сервер также подтверждает прием отправкой сессионного подтверждения в сообщении 7-9. В реализации, показанной на фиг.7, посылающий терминал пользователя UT1 сконфигурирован на прекращение сессии в ответ на подтверждение путем отправки сообщения 7-10 серверу, который затем посылает сообщение 7-11, подтверждающее прекращение. Боб может посмотреть содержимое сообщения позже, но реализация этого просмотра несущественна для изобретения, поэтому не будет обсуждаться здесь подробно.

В схеме сигнализации на фиг.8, как и на фиг.7, показана сигнализация между конечными точками с участием сервера мгновенных сообщений в качестве принимающей конечной точки, хотя могут быть вовлечены один или более посредников. Фиг.8 демонстрирует сигнализацию, когда получатель, точнее соответствующий клиент в пользовательском терминале получателя, не принимает сообщение, а запрашивает шлюз GW в сети сохранить это сообщение для дальнейшего извлечения. Фиг.8 начинается с момента, когда Элис желает отправить сообщение Бобу. Терминал пользователя UT1 Элис (точнее соответствующий клиент в UT1) извещает в точке 8-1, что страничное сообщение должно быть отправлено с использованием сессионного механизма. (Точка 8-1 описана подробно выше в отношении фиг.2.) Поэтому UT1 посылает сообщение сессионного приглашения 8-2 с признаком страничного режима РМ1 к терминалу пользователя UT2 Боба посредством сервера. Сообщение 8-2 - предпочтительно одно из сообщений, показанных на фиг.5A…5D. В ответ на прием сообщения 8-2 UT2 определяет в точке 8-3, что это сообщение является сессионным приглашением для страничного сообщения. По некоторым причинам UT2 не принимает страничное сообщение, а посылает перенаправляющее сообщение 8-4 к серверу, перенаправляющее сообщение указывает, что сообщение должно быть перенаправлено к шлюзу GW. (Перенаправляющие сообщения обсуждены выше со ссылкой на фиг.7.) UT2 может также уведомить Боба о сообщении, как описано выше со ссылкой на фиг.3 и 4.

В этом примере сервер, точнее двусторонний пользовательский агент, генерирует новый запрос к URI (унифицированный идентификатор ресурсов) шлюза GW, указанного в сообщении 8-4, и посылает запрос в сообщении 8-5. Этот запрос - предпочтительно сессионное приглашение без признака страничного режима. GW принимает начальное приглашение, посылая сообщение 8-6. UT1 подтверждает прием, отправляя сообщение 8-7 к GW, и затем посылает реальное содержимое страничного сообщения в сессионном сообщении 8-8 к GW. В ответ на прием содержимого GW сохраняет в точке 8-9 содержимое, и Боб может посмотреть его позже. В ответ на прием содержимого GW также подтверждает прием отправкой сессионного подтверждения в сообщении 8-10. В реализации, показанной на фиг.8, посылающий терминал пользователя UT1 сконфигурирован на прекращение сессии в ответ на подтверждение путем отправки сообщения 8-11 к GW, который затем посылает сообщение 8-12, подтверждающее прекращение. Боб может посмотреть содержимое сообщения позже, но реализация этого просмотра несущественна для изобретения, поэтому не будет обсуждаться здесь подробно.

Фиг.9 показывает сигнализацию в соответствии с дальнейшей реализацией данного изобретения, в которой сервер мгновенных сообщений также сконфигурирован для обнаружения признака. Сервер мгновенных сообщений может быть отдельным сервером или компонентом сервера в сетевом узле, содержащем один или более других компонентов. В примере, показанном на фиг.9, предполагается, что получатель (UT2) недоступен или имеет конфигурацию, в соответствии с которой страничные сообщения получателя сохраняются в сетевом ящике входящей почты получателя, в данном примере расположенном на сервере. Такой вариант также может быть конфигурацией сети. В схеме сигнализации на фиг.9 показана сигнализация между посылающей конечной точкой UT1 с участием сервера мгновенных сообщений в качестве принимающей конечной точки, хотя могут быть вовлечены один или более посредников. Фиг.9 начинается с момента, когда Элис желает отправить сообщение Бобу. Терминал пользователя UT1 Элис (точнее соответствующий клиент в UT1) извещает в точке 9-1, что страничное сообщение должно быть отправлено с использованием сессионного механизма. (Точка 9-1 описана подробно выше со ссылкой фиг.2.) Поэтому UT1 посылает сообщение сессионного приглашения 9-2 с признаком страничного режима PMI к терминалу пользователя UT2 Боба посредством сервера. Сообщение 9-2 - предпочтительно одно из сообщений, показанных на фиг.5A…5D. В ответ на прием сообщения 9-2 сервер, точнее двусторонний пользовательский агент, определяет в точке 9-3, что это сообщение является сессионным приглашением для страничного сообщения, и поэтому проверяет конфигурации Боба (т.е. UT2) для страничных сообщений. Поскольку эти конфигурации показывают, что страничные сообщения будут сохранены для извлечения позднее, сервер считает себя конечной точкой сессии и принимает приглашение отправкой сообщения 9-4. UT1 подтверждает прием, отправляя сообщение 9-5 серверу, и затем посылает реальное содержимое страничного сообщения в сессионном сообщении 9-6 серверу. В ответ на прием содержимого сервер сохраняет в точке 9-7 содержимое, и Боб может посмотреть его позже. В некоторой другой реализации изобретения сообщение может быть сохранено в другом узле сети, в удаленной базе данных либо перенаправлено к шлюзу. В ответ на прием содержимого сервер также подтверждает прием отправкой сессионного подтверждения в сообщении 9-8. В реализации, показанной на фиг.9, посылающий терминал пользователя UT1 сконфигурирован на прекращение сессии в ответ на подтверждение приема путем отправки сообщения 9-9 серверу, который затем посылает сообщение 9-10, подтверждающее прекращение. Боб может посмотреть содержимое сообщения позже, но реализация этого просмотра несущественна для изобретения, поэтому не будет обсуждаться здесь подробно.

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

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

Шаги, точки и сигнальные сообщения, показанные на фиг.2, 3, 4, 6, 7, 8 и 9, не находятся в абсолютном хронологическом порядке, и некоторые из шагов/точек могут быть выполнены одновременно или в порядке, отличном от данного здесь. Также могут быть выполнены другие функции между шагами/точками или в шагах/точках. Также могут быть опущены некоторые шаги/точки или часть шагов/точек. Сигнальные сообщения являются только примерами и могут даже содержать несколько отдельных сообщений для передачи одной и той же информации. В дополнение сообщения могут также содержать другую информацию. Сообщения и шаги/точки могут быть также свободно комбинированы или разделены на несколько частей. Более того, имена, типы и/или содержимое сообщений, а также используемые протоколы могут отличаться от вышеупомянутых.

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

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

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

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