Расширенная платформа для обмена сообщениями

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

 

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

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

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

Самой производительной формой обмена сообщениями, реализованной в системах мобильной связи, является служба коротких сообщений (SMS). Обычно сообщения посылаются с инициирующего устройства в центр службы коротких сообщений (SMSC), который поддерживает механизм передачи данных с промежуточным хранением. Передача коротких сообщений между SMSC и мобильным телефоном выполняется с использованием подсистемы мобильных приложений (MAP) протокола SS7. Сообщения посылаются посредством операций MAP mo- и mt-ForwardSM, длина полезной нагрузки которых ограничивается ограничениями протокола передачи сигналов до ровно 140 октетов (140 октетов = 140 * 8 бит = 1120 бит). Короткие сообщения могут кодироваться с использованием ряда алфавитов: 7-битный алфавит GSM по умолчанию (показан ниже), алфавит 8-битных данных и 16-битный алфавит UTF-16/UCS-2.

В зависимости от того, какой алфавит клиент настроил в своем мобильном телефоне, это приводит к максимальным размерам индивидуальных коротких сообщений, составляющим 160 7-битных символов, 140 8-битных символов или 70 16-битных символов (включая пробелы). Поддержка 7-битного алфавита GSM является обязательной для мобильных телефонов и сетевых элементов стандарта GSM [15], но символы для алфавитов таких языков, как арабский, китайский, корейский или кириллические алфавиты (например, русский) должны быть закодированы с использованием 16-битной UCS-2 кодировки символов (Unicode). Данные маршрутизации и другие метаданные добавляются к размеру полезной нагрузки.

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

В последнее время дополнительные службы сообщений, такие как мгновенные сообщения и электронная почта, переместились в среду мобильной связи. В стандартной среде настольного компьютера мгновенный обмен сообщениями (IM) обеспечивает основанное на тексте взаимодействие между двумя участниками сети в реальном времени, или в режиме, близком к реальному времени. Таким образом, ключевым отличием IM от таких служб, как электронная почта, является имеющаяся синхрония взаимодействия пользователей, при этом обмен сообщениями выполняется в реальном времени или близко к этому. Мгновенные сообщения обычно протоколируются в локальной истории сообщений, что устраняет расхождение с непрерывной природой электронных писем и способствует быстрому обмену информацией, такой как URL-ссылки или фрагменты документов (что может быть громоздким при передаче через телефон). IM позволяет осуществлять эффективное и производительное взаимодействие, включающее немедленный прием квитирования или ответа.

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

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

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

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

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

Соответственно, в одном из аспектов настоящего изобретения представлена расширенная система обмена сообщениями, включающая в себя:

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

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

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

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

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

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

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

Первый канал доставки может представлять собой канал обмена сообщениями, базирующийся на протоколе Интернет (IP), и сообщение может представлять собой мгновенное сообщение или сообщение чата. Предпочтительным альтернативным каналом доставки является SMTP, MIME, POP, IMAP или аналогичный канал обмена сообщениями. Подходящим альтернативным каналом доставки может быть SS7 или аналогичный канал обмена сообщениями. В случаях когда для доставки сообщения применяется альтернативная доставка, инициирующее устройство или по меньшей мере один сервер может переформатировать сообщения для согласования со стандартом обмена сообщениями альтернативного канала доставки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание вариантов осуществления изобретения

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

Как показано на чертеже, инициирующее устройство 101 (например, мобильный телефон, КПК, портативный компьютер и т.п.) используется пользователем для создания сообщения посредством приложения обмена сообщениями 102 устройства. В этом случае приложение обмена сообщениями представляет собой мобильное IM-приложение. После того как пользователь создал желаемое сообщение, он затем выбирает одного или более получателей 107 из своего списка контактов или списка 103 друзей. Получатели 107 могут быть членами той же сети 104 или членами другой сети 106. После выбора получателей 107 приложение 102 обмена сообщениями устройства пересылает сообщение через сеть 104 серверу 105 доставки, при этом сообщение завершается информацией относительно предполагаемых получателей и предпочтительного канала доставки, используемого для доставки сообщения принимающим(ему) устройствам(у) 107. В предпочтительных каналах доставки может выполняться обмен сообщениями, основанными на данных (протокол Интернета/IP, например, обмен мгновенными сообщениями или чат), на формате SMS, MMS, электронной почты или другом заданном формате сообщения. После того как инициирующее устройство 101 переслало сообщение серверу 105 доставки, оно ожидает прием сообщения квитирования/пакета от сервера 105 доставки, которое подтверждает прием сообщения. Конкретный формат квитирования не является критическим, при условии что она может быть легко ассоциирована с исходно отправленным сообщением. Существует ряд подходов для ассоциирования сообщения квитирования с исходно отправленным сообщением. Например, ассоциирование может выполняться посредством использования порядкового номера, временной метки и т.п., которые используются для генерирования уникального идентификатора сообщения, связывающего сообщение квитирования с исходно отправленным сообщением.

Если инициирующее устройство 101 не принимает квитирование, то оно ожидает в течение заранее определенного на основании заранее заданного набора правил периода времени до начала повторной передачи сообщения. Заранее заданный набор правил не только определяет период времени, в течение которого устройство ожидает до повторной отправки сообщения, но также определяет, как долго и насколько часто будут выполняться повторные попытки отправки. Например, набор правил может быть настроен таким образом, чтобы давать устройству отправки 101 максимум 10 повторных попыток, при этом каждая повторная попытка имеет место через 5 минут после исходной попытки отправки сообщения. Если после исчерпания максимального количества повторных попыток устройство отправки 101 все еще не может завершить доставку сообщения, то оно может по прошествии заранее заданного периода попытаться выполнить доставку посредством альтернативного способа маршрутизации сообщения на сервер 105 доставки.

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

Как показано на Фиг.1, сервер 105 доставки в рассматриваемом случае соединен по меньшей мере с одним сервером электронной почты 108 и/или по меньшей мере с одним центром обмена сообщениями (SMSC, MMSC) 109 с целью обеспечения множества резервных каналов доставки. В случае когда сообщение не может быть маршрутизировано на принимающие(ее) устройства(о) через первичный канал доставки (то есть в собственном формате сообщения), сервер доставки будет переключаться на следующий предпочтительный формат доставки. Например, сервер 105 доставки может переключиться с IM на SMS для выполнения доставки сообщения.

В качестве альтернативы, инициирующее устройство 101 может предлагать пользователю выбрать альтернативный канал доставки в случае, когда сообщение не может быть доставлено через первичный канал доставки, выбранный пользователем. В некоторых случаях пользователь может выбрать канал доставки, о недоступности которого известно серверу, например, пользователь может выбрать основанный на IP обмен сообщениями, но серверу известно, что принимающее устройство не может принимать сообщения этого типа. В этом случае сервер 105 доставки конвертирует сообщение в альтернативный формат сообщения (SMS, электронная почта и т.д.) для доставки через альтернативный канал доставки (например, шлюз 108 электронной почты, SMSC 109). Первичный канал доставки может включать в себя набор инструкций, включенных в заголовок сообщения, для управления переключением сервера на вторичный канал доставки. Каждый раз при отправке (или повторной отправке) сообщения сервером 105 доставки, в нем передается счетчик повторных попыток отправки, который имеет значения, начинающиеся с 0 (первоначальная доставка) и возрастающие. Для каждой повторной попытки счетчик увеличивается для указания повторных попыток. На основании набора правил, сконфигурированных в сервере доставки, сервер доставки может затем выбрать попытку использования альтернативных способов доставки для сообщения на основании значения счетчика повторных попыток. Это позволяет преобразовывать сообщение SMS, MMS или электронное письмо после заданного количества попыток доставки. В исходной итерации попытка доставки сообщения через SMS будет начинаться с третьей попытки.

Записи в журнале для каждой попытки доставки сообщения, а также информация сети, включающая место размещения сот и т.д., хранится сервером в базе данных 110. В таких случаях сервер 105 доставки может быть соединен с HLR (домашний регистр местоположения) сети 104. Если сообщение не было успешно доставлено, то запись в журнале заносится в базу данных 110. Журнал содержит не только информацию о неуспешной доставке, он также содержит информацию HLR, относящуюся к принимающему мобильному устройству. Последующий анализ данных, полученных указанным образом, выполняется с использованием стандартных инструментов анализа данных и может выявить конкретные области сети, которым требуется текущий ремонт или усовершенствование. Такое ведение записей в журнале может идентифицировать конкретные проблемы покрытия несущей или другие несоответствия требованиям сети. Кроме того, база данных 110 может быть использована в качестве хранилища для пользовательских сообщений, которое подробнее обсуждается ниже.

На Фиг.2 изображена передача сигналов, используемая системой 100 обмена сообщениями, в соответствии с одним из вариантов осуществления настоящего изобретения. Для выполнения доставки сообщения сервер 105 доставки должен сначала идентифицировать предполагаемых(ого) получателей(я) 107 и предпочтительный для пользователя канал доставки. Каждое клиентское устройство (инициирующее или принимающее, 101, 107) в сети взаимодействует с сервером с использованием регулируемых по времени периодических контрольных сообщений 213, что позволяет серверу отслеживать присутствие всех устройств в сети. В представленном примере каждое клиентское устройство отправляет контрольное сообщение серверу каждые 10 минут. Если сервер не принимает контрольное сообщение в ожидаемое время, он обозначает клиентское устройство как неактивное.

Передача периодических контрольных сообщений используется не только для того, чтобы показать присутствие клиентского устройства, но также и для того, чтобы показать уровень обслуживания, доступный клиентскому устройству в настоящее время. Например, если пользователь указал предпочтительную доставку с использованием IM-сообщений, то сервер выполняет проверку с целью подтверждения того, что получатель 107 соединен с сервером, и доступен для приема сообщений, через информацию, принятую в контрольном сообщении принимающего устройства. В некоторых случаях принимающее устройство 107 может быть не готово или может не иметь возможности приема IM-сообщения, тогда сервер 105 доставки пытается отправить сообщение каждому получателю с использованием соответствующего альтернативного канала доставки, такого как SMS 209, электронная почта 207 или другой подходящий формат сообщения. В каждом подходе к доставке от получателя (или агента доставки, в случае SMS или электронной почты) ожидается прием сообщения квитирования/квитирования после доставки сообщения. Оно затем будет передано исходному отправителю сообщения. Как упоминалось выше, конкретный формат сообщения квитирования не является критичным, при условии, что он позволяет системе ассоциировать квитирование с исходно отправленным сообщением.

Как показано на Фиг.2, инициирующее устройство 101 пересылает IM-сообщение 201 на сервер 105 доставки для доставки принимающему устройству 107 через первичный канал 202 доставки. Сервер 105 доставки отправляет в ответ квитирование инициирующему устройству 101. Сервер доставки отправляет IM-сообщение принимающему устройству 107. Принимающее устройство 107 затем отправляет в ответ сообщение 203 квитирования на сервер 105 доставки, и сервер 105 доставки затем, факультативно, сообщает устройству 101 отправки об успешной сквозной доставке сообщения 204. В случае если первичный канал 202 доставки недоступен, то сервер 105 доставки пытается маршрутизировать сообщения через альтернативный канал доставки, такой как электронная почта 205, через шлюз 108 электронной почты, или SMS 206 через SMSC 109.

Если в качестве альтернативного маршрута доставки была выбрана электронная почта, то сервер 105 доставки преобразует сообщение из его «родного» формата в соответствующий формат электронной почты до пересылки сообщения 205 шлюзу электронной почты. Шлюз 108 электронной почты затем пересылает сообщение 207 принимающему устройству 107, принимающее устройство затем отправляет в ответ сообщение 208 квитирования. Аналогично, если в качестве альтернативного канала доставки было выбрано SMS или MMS, то сервер 105 доставки преобразует сообщение из его «родного» формата в SMS-пакет соответствующего размера для пересылки сообщения в SMSC 109. Факультативно может быть выполнено укорачивание сообщения, однако в данном случае в текущем варианте осуществления изобретения отправляется столько пакетов SMS-сообщений, сколько требуется для доставки сообщения во всей его полноте на принимающее(ие) устройство(а) 107. SMSC 109 затем пересылает сообщение 209 принимающему устройству 107, а принимающее устройство отправляет в ответ сообщение 210 квитирования. В проиллюстрированном примере сервер не ожидает подтверждения для сообщений 211, 212 (показаны пунктирной линией), отправленного в виде электронного письма или SMS через серверы электронной почты и/или шлюз SMSC/SMS, поскольку оба этих формата считаются приемлемо надежными. Однако специалистам в данной области техники будет понятно, что процедура подобной проверки может быть легко встроена в систему.

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

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

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

- маршрутизация SMS в неактивном режиме - информирует сервер о необходимости маршрутизировать сообщения через SMS в случае, когда статус клиентских устройств установлен как «неактивный»;

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

- «пробуждение», при котором системе разрешается вызывать клиентское приложение на принимающем устройстве с использованием SS7 или SMS0 и затем представлять сообщение пользователю;

- «сохранение на сервере», при котором сервер информируется о необходимости сохранения сообщений на сервере до тех пор, пока пользователь снова не войдет в свое клиентское устройство.

Таким образом, доступность становится атрибутом, определяемым пользователем, который позволяет пользователю изменять применение набора правил системы. Как показано в Таблице 1, в пределах системы существует ряд статусов, которые пользователь может выбирать в зависимости от того, находится ли он в активном режиме или в неактивном режиме. Четыре основных статуса - «доступен», «недоступен», «не беспокоить» и «невидимый». Если настройки неактивного режима, выбранные пользователем, допускают оперативную доставку сообщения через альтернативный канал доставки, то статус, выбранный пользователем, сохраняется в сети, когда пользователь находится в неактивном режиме. Если пользователь сети выбирает такие настройки неактивного режима, которые не позволяют выполнять оперативную доставку, например «электронная почта» или «сохранить на сервере», то его доступность будет показана как «недоступен для передачи сообщений» в случае нахождения в неактивном режиме. Для пользователей клиентского устройства «не в сети» имеются ограниченные настройки неактивного режима, то есть «сохранить на сервере» и «электронная почта». Таким образом, пользователь вне сети и в неактивном режиме всегда рассматривается как «недоступный для передачи сообщений».

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

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

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

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

- попытки повторной доставки с сервера на принимающее устройство выполняются каждую минуту, максимально - 3 попытки до переключения на альтернативный канал;

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

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

- в принимающем устройстве пользователю будет показан запрос на подтверждение приема (на квитирование), и такое подтверждение будет отправлено в виде сообщения исходному отправителю (с указанием времени/даты подтверждения);

- сообщения будут помечены в базе данных 110 (обсуждается ниже) как имеющие высокую важность.

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

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

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

- содержит веб-ссылку;

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

- содержит адрес (на основании базы данных ключевых слов, таких как "улица", "квартира", "ул.", "кв." и т.д.).

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

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

- доступ ко всем отправленным и принятым сообщениям;

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

- присвоение меток сообщениям (выбираемые пользователем метки, а также автоматические метки, например, для присвоения меток сообщениям, содержащим ссылки или номера);

- действия с сообщением (ответ на сообщение, отправка нового сообщения и т.д.);

- доступ к списку контактов;

- управление архивом сообщений (удаление некоторых или всех сообщений для выбранных или всех получателей);

- настройки пользователя (выключение сохранения сообщений, выключение для конкретных получателей, включение для конкретных получателей и т.д.).

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

- управление попытками повторной передачи может выполняться инициирующим устройством 101 вместо сервера 105 доставки;

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

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

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

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

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

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

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

2. Система обмена сообщениями по п.1, в которой первый канал доставки представляет собой канал протокола Интернет, и сообщение представляет собой мгновенное сообщение.

3. Система обмена сообщениями по п.1, в которой первый канал доставки выбирается из по меньшей мере одного канала из SMTP, MIME, POP, IMAP, и упомянутое сообщение представляет собой сообщение электронной почты.

4. Система обмена сообщениями по п.1, в которой первый канал доставки представляет собой SS7-канал, и сообщение представляет собой SMS или MMS.

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

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

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

8. Система обмена сообщениями по п.6, в которой сообщение квитирования содержит порядковый номер, временную метку или уникальный идентификатор (ID), который ассоциирует сообщение квитирования с сообщением, отправленным инициирующим устройством.

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

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

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

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

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

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

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

16. Способ по п.15, в котором первый канал доставки представляет собой канал протокола Интернет (IP), и сообщение представляет собой мгновенное сообщение.

17. Способ по п.15, в котором первый канал доставки выбирается из по меньшей мере одного канала из SMTP, MIME, POP, IMAP, и упомянутое сообщение представляет собой сообщение электронной почты.

18. Способ по п.15, в котором первый канал доставки представляет собой SS7-канал, и сообщение представляет собой SMS или MMS.

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

20. Способ по п.15, дополнительно включающий в себя этап повторной отправки сообщения через первый канал доставки заранее определенное количество раз до попытки отправки сообщения через альтернативный канал доставки.

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

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

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

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

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

26. Способ по п.25, в котором первый канал доставки представляет собой канал протокола Интернет (IP), и сообщение представляет собой мгновенное сообщение.

27. Способ по п.25, в котором первый канал доставки выбирается из по меньшей мере одного канала из SMTP, MIME, POP, IMAP, и упомянутое сообщение представляет собой сообщение электронной почты.

28. Способ по п.25, в котором первый канал доставки представляет собой SS7-канал, и сообщение представляет собой SMS или MMS.

29. Способ по п.25, в котором сервер сконфигурирован для переформатирования сообщения для согласования со стандартом обмена сообщениями альтернативного канала доставки.

30. Способ по п.25, дополнительно включающий в себя этап повторной отправки сообщения через первый канал доставки заранее определенное количество раз до попытки отправки сообщения через альтернативный канал доставки.

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

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

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

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

35. Способ по п.25, в котором инициирующее устройство отображает пользователю индикатор в качестве статуса доставки сообщения.

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