Розширена платформа обміну повідомленнями

Реферат: Описана система обміну повідомленнями, що включає щонайменше один сервер, настроєний для отримання повідомлення від передавального пристрою для доставки щонайменше одному приймаючому пристрою через перший канал доставки; і де щонайменше цей один сервер далі настроєний для вибору альтернативного каналу доставки у випадку, якщо доставка повідомлення через перший канал доставки не може бути здійснена. Винахід далі розкриває спосіб маршрутизації повідомлень, що включає стадії отримання на сервері повідомлення від передавального пристрою для доставки щонайменше одному одержувачеві; пересилки повідомлення щонайменше одному приймаючому пристрою через перший канал доставки; очікування отримання повідомлення підтвердження щонайменше від одного згаданого приймаючого пристрою, і, у разі неотримання повідомлення підтвердження, щонайменше цей один сервер повторно відправляє повідомлення щонайменше згаданому одному приймаючому пристрою через альтернативний канал доставки. UA 100722 C2 (12) UA 100722 C2 UA 100722 C2 5 10 15 20 25 30 35 40 45 50 55 60 Область винаходу Даний винахід відноситься до систем і способів для забезпечення розширених служб обміну повідомленнями. Зокрема, хоча і не виключно, даний винахід відноситься до забезпечення розширених служб обміну повідомленнями і/або сумісного використання файлів в рамках мережі мобільного зв'язку. Розгляд передумов винаходу Наймасовішою формою обміну повідомленнями, задіяному в системах мобільному зв'язку, є служба коротких повідомлень (SMS). Зазвичай повідомлення відправляють з вихідного пристрою на SMS-центр (SMSC), який забезпечує зберігання і передачу повідомлень. Передача коротких повідомлень між SMSC і телефоном здійснюється за допомогою прикладної програми Mobile Application Part (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 також надають опцію «переслати і забути», при якій передача робиться тільки одноразово. Таким чином, доставка повідомлень є максимально сприятливим варіантом, проте, немає гарантій, що повідомлення буде дійсно доставлено одержувачеві, а затримка або повна втрата повідомлення не є рідкістю, зокрема, при пересилці між мережами. Останніми роками в мобільне середовище мігрували додаткові послуги, такі як миттєве повідомлення і email. У стандартному комп'ютерному середовищі передача миттєвих повідомлень (IM) забезпечувала спілкування за допомогою тексту між двома або більше абонентами мережі в реальному часі або майже в реальному часі. Таким чином, ключовою відмінністю між IM і такою службою, як email, є синхронність спілкування, що досягається, між користувачами, а обмін повідомленнями відбувається в реальному або майже в реальному часі. Миттєві повідомлення зазвичай протоколюються в локальній історії повідомлень, що заповнює нішу, яка відокремлює їх від постійної суті email-повідомлень і полегшує швидкий обмін такою інформацією, як URL або фрагменти документів (що може бути об'ємним для передачі за допомогою телефону). IM надає ефективне і результативне спілкування, що надає миттєві повідомлення про отримання повідомлення або відповіді. Мобільний обмін миттєвими повідомленнями (MIM) трохи відрізняється від такої стандартної комп'ютерної прикладної програми IM. MIM - це служба обміну повідомленнями з ефектом присутності, яка прагне перенести досвід обміну повідомленнями за допомогою комп'ютера на призначений для користувача сценарій обміну повідомленнями на ходу. Тоді як деякі з основних ідей комп'ютерного досвіду з одного боку застосовуються до підключеного мобільного пристрою, інші не застосовуються. Наприклад, для створення дійсно придатного, могутнього і при цьому зручного мобільного досвіду повинні бути враховані деякі форм-фактори і відмінності, що відносяться до мобільності, такі як, пропускна спроможність, об'єм пам'яті, доступність медіа-форматів, введення з клавіатури, вивід на екран, продуктивність центрального процесора і живлення від батареї, які є основними параметрами для забезпечення з'єднання з мережею користувачів комп'ютерів і мобільних користувачів. Як було описано вище, мобільні мережі даних можуть бути ненадійними і повідомлення можуть втрачатися (якщо доставка повідомлень є максимально сприятливим варіантом). Існуючі мобільні шлюзові пристрої обміну миттєвими повідомленнями (IM) трактують IM повідомлення як «випадковий чат». Немає гарантії, що повідомлення буде доставлено цільовому одержувачеві, унаслідок того, що MIM не бачить втрату повідомлення. Такі сучасні виконання як MIM не є цілком відповідними для ділового середовища або для інших застосувань, в яких доставка інформації є украй важливою. Як було описано вище, більшість існуючих систем обміну повідомленнями (наприклад, SMS) надають обмежений об'єм зберігання. Для SMS можна використовувати можливість резервного 1 UA 100722 C2 5 10 15 20 25 30 35 40 45 50 55 60 збереження повідомлень будь-якого типу у вигляді резервних копій/архівів на локальному комп'ютері, і тому, зазвичай, процес виконується уручну. Користувач, що бажає зберегти повідомлення і звільнити пам'ять для нових повідомлень, повинен виконати цей процес уручну перед видаленням повідомлень на своєму мобільному пристрої. Відповідно, існує необхідність забезпечення надійного вирішення обміну повідомленнями, яке буде прийнятне як для випадкового, так і для ділового або критичного користувача. Також буде забезпечена можливість, що дозволить користувачам створювати резервні копії відправлених і отриманих повідомлень для подальшого перегляду. СУТЬ ВИНАХОДУ Опис винаходу Унаслідок вищесказаного, в одному аспекті даного винаходу передбачається розширена система повідомлень, названа системою, яка включає: щонайменше, один сервер, настроєний для прийому повідомлення з передавального пристрою, для доставки повідомлення, щонайменше, одному приймаючому пристрою через перший канал доставки; і де, щонайменше, один сервер надалі настроєний для вибору альтернативного каналу доставки у випадку, якщо доставка повідомлення через перший канал доставки не може бути здійснена; Альтернативно передавальний пристрій може бути настроєно для вибору альтернативного каналу доставки у випадку, якщо доставка повідомлення через перший канал доставки не може бути здійснена. Мережа обміну повідомленнями може бути розглянута як мережа, що включає передавальний пристрій, щонайменше, один сервер і один або більше одержувачів (вони можуть бути мобільними пристроями або Email або іншими типами одержувачів). Повідомлення може бути розглянуте як текстове повідомлення або ж воно може бути інформаційним повідомленням іншого типу або файлом, що є, окрім іншого, зображенням, музичним файлом або документом. Принцип гарантування доставки застосовується на всіх етапах доставки повідомлення. Отже, передавальний пристрій може мати одне зумовлене правило або ряд зумовлених правил, що визначають передачу повідомлення. Ряд правил може включати інформацію про період часу очікування передавальним пристроєм повторної відправки повідомлення по першому каналу доставки, про те як часто і наскільки довго повторні спроби продовжуються по першому каналу доставки перед перемиканням на альтернативний канал доставки. Повідомлення може включати лічильник повторних спроб, число яких зростатиме при кожній спробі передавального пристрою доставити повідомлення, щонайменьше, до одного сервера. Система може дозволяти користувачеві перенастроювати ряд правив відповідно до переваг. Передавальний пристрій може мати індикатор, що надає користувачеві інформацію про статус доставки повідомлення. Перший канал доставки може бути каналом обміну повідомленнями на основі Інтернетпротоколу (IP), а повідомлення може бути миттєвим повідомленням або чат-повідомленням. Переважно альтернативним каналом доставки є SMTP, MIME, POP, IMAP або подібний канал обміну повідомленнями. Відповідним альтернативним каналом доставки може бути SS7 або подібний канал обміну повідомленнями. У випадках коли для доставки повідомлення використовується альтернативна доставка, передавальний пристрій або, щонайменше, один сервер можуть переформатувати повідомлення до відповідності стандарту обміну повідомленнями альтернативного каналу доставки. Переважно передавальний пристрій призначений для отримання повідомлення підтвердження отримання повідомлення через перший канал обміну повідомленнями від, щонайменше, одного згаданого сервера. Якщо до передавального пристрою не повертається повідомлення підтвердження, передавальний пристрій застосовує ділові правила і призначені для користувача настройки відправника для визначення дій, що робляться. Зазвичай це може включати певну кількість повторних спроб, після яких послідує перемикання на альтернативний канал доставки, на який і буде здійснена доставка. Тут також може бути потрібне втручання користувача для визначення дії, що робиться. Далі це може включати доставку по первинному каналу доставки до сервера з інструкціями, включеними в заголовок повідомлення інструкції для перемикання сервера на вторинний канал доставки. Як тільки повідомлення досягає, щонайменше, одного згаданого сервера, його слід направити до одного або більше одержувачів. Щонайменше, один цей сервер першим зробить спробу доставити повідомлення по каналу доставки, визначеному користувачем 2 UA 100722 C2 5 10 15 20 25 30 35 40 45 50 55 60 передавального пристрою. Сервер може включати один або більше зумовлений ряд правив для управління передачею повідомлення. Ряд правил може включати інформацію, що відноситься до періоду часу, протягом якого, щонайменше, один цей сервер чекає повторну відправку повідомлення по першому каналу доставки, і інформацію про те, як часто і наскільки довго повторні спроби продовжуються по першому каналу доставки до перемикання на альтернативний канал доставки. Повідомлення може включати лічильник повторних спроб, число яких зростатиме при кожній спробі сервера доставити повідомлення, щонайменше, до одного приймаючого пристрою. Система може дозволяти користувачеві перенастроювати ряд правив відповідно до його переваг. Альтернативно, сервер може відмовитися від відповідальності управління повторними спробами звернення до передавального пристрою. Переважно, щонайменше, цей один сервер пристосовано для отримання повідомлення підтвердження, щонайменше, від одного приймаючого пристрою про отримання повідомлення через перший канал обміну повідомленнями. Система може також бути настроєна так, що, щонайменше, цей один сервер повідомлюватиме передавальний пристрій про отримання повідомлення, щонайменше, одним приймаючим пристроєм. Дане безперервне повідомлення потрібне тільки для забезпечення доставки при управлінні повторними процесами передавальним пристроєм. У іншому випадку, якщо, щонайменше, один сервер продовжує контролювати процес і забезпечує надійність доставки, повернення повідомлення підтвердження отримання до передавального пристрою не обов'язково. Повідомлення підтвердження може бути в будь-якому відповідному форматі за умови, що воно містить, як мінімум, достатню інформацію для пов'язання підтвердження з повідомленням. Підтвердження може, наприклад, включати серійний номер, відмітку часу, унікальний ID тощо. Унікальний ID можна згенерувати з серійного номера і відмітки часу, пов'язаної з отриманням повідомлення. Альтернативно, сервер може просто пропустити підтвердження отримання на передавальний пристрій. При цьому підході передавальний пристрій приймає більше відповідальності за управління гарантією доставки до приймаючого пристрою. Якщо, щонайменше, до одного сервера не повертається повідомлення підтвердження, сервер застосовує ділові правила і призначені для користувача настройки відправника і одержувача для визначення дій, що робляться. Зазвичай, це може включати певну кількість повторних спроб, і подальше перемикання на альтернативний канал доставки, на який і буде здійснена доставка. Щонайменше, один сервер може бути сполучений з базою даних. Сервер може бути настроєний для періодичної реєстрації протоколу кожної спроби доставки повідомлення і спеціальної мережевої інформації в базі даних. База даних може також бути використана як сховище повідомлень для всіх повідомлень, що проходять через сервер доставки. Система може дозволити користувачеві з відповідним інтерфейсом отримати доступ до всіх відправлених і отриманих повідомлень користувача. У подальшому аспекті даного винаходу представлено згаданий спосіб маршрутизації повідомлень, цей спосіб включає стадії: отримання сервером повідомлення від передавального пристрою для доставки, щонайменше, одному одержувачеві; пересилки повідомлення, щонайменше, одному приймаючому пристрою через перший канал доставки очікування отримання повідомлення підтвердження від, щонайменше, одного згаданого приймаючого пристрою, і повторної пересилки повідомлення, щонайменше, одному вказаному приймаючому пристрою через альтернативний канал доставки, у разі неотримання повідомлення підтвердження. Спосіб може включати стадію повторної пересилки повідомлення через перший канал доставки зумовленою кількістю разів перед пересилкою повідомлення через альтернативний канал доставки. Відповідно стадія повторної пересилки повідомлення через перший канал доставки включає стадію збільшення числа повторних спроб лічильника, пов'язаного з повідомленням. Спосіб може факультативно включати на передавальному пристрої стадію ініціації передачі повідомлення через альтернативний канал доставки, у разі невдалої передачі через попередній перший канал доставки (тобто передавальний пристрій має можливість відмінити повторну спробу на першому каналі доставки). Відповідно, стадія пересилки повідомлення через альтернативний канал доставки також включає стадію переформатування повідомлення для відповідності стандарту обміну повідомленнями каналу. Спосіб може також включати обробку на приймаючому пристрої для ідентифікації копій 3 UA 100722 C2 5 10 15 20 25 30 35 40 45 50 55 60 повідомлень. В умовах низької надійності мережі при нагоді повідомлення можуть бути відправлені кілька разів до відправки, щонайменше, один сервер або передавальний пристрій отримає відповідь, підтверджуючу успішну доставку. Якщо це відбувається із-за невдалої передачі отримання, а не самого повідомлення, результатом можуть бути копії повідомлення, що приходять на приймаючий пристрій. До цього звертаються з використанням унікального ідентифікатора, що міститься в повідомленні, як і описано вище. Приймаючий пристрій перевіряє унікальні ідентифікатори в отриманих раніше повідомленнях і не відображає повторно повідомлення, отримане і відображене раніше. У подальшому аспекті винаходу для користувача може бути відображений індикатор, що показує статус доставки повідомлення. У одному варіанті, при якому повторні спроби відправки повідомлення контролюються передавальним пристроєм, бажано повідомляти користувача при спробі виходу з прикладної програми про те, що підтвердження про доставку повідомлення ще не отримане і що спроби повторної відправки ще не закінчені. Стислий опис графічних матеріалів Для детальнішого розуміння винаходу на основі опису і для його практичного застосування нижче будуть приведені відповідні графічні матеріали, що ілюструють переважні варіанти винаходу, де: На фіг. 1 схематично представлена блок-схема розширеної системи обміну повідомленнями згідно одному варіанту здійснення даного винаходу. На фіг. 2 представлена схема процесу, що відображає обмін сигналами між різними пунктами системи обміну повідомленнями згідно одному варіанту здійснення даного винаходу. Опис варіантів здійснення винаходу На фіг. 1 показана система обміну повідомленнями 100 згідно одному варіанту здійснення даного винаходу. У контексті даного винаходу повідомлення може бути розглянуте як текстове повідомлення або ж воно може бути інформаційним повідомленням іншого типу або файлом, що є, окрім іншого, зображенням, музичним файлом або документом. Як показано, передавальний пристрій 101 (наприклад, мобільний телефон, КПК, портативний комп'ютер тощо) застосовується користувачем для створення повідомлення за допомогою прикладної програми 102 обміну повідомленнями пристрою. В цьому випадку прикладна програма обміну повідомленнями є мобільною прикладною програмою IM. Після створення користувачем бажаного повідомлення, він вибирає одного або більше одержувачів 107 із списку контактів або друзів 103. Одержувачі 107 можуть бути абонентами тієї ж мережі 104 або абонентами іншої мережі 106. Після вибору одержувачів 107, прикладна програма 102 обміну повідомленнями пристрою пересилає повідомлення через мережу 104 на сервер доставки 105 з інформацією, відповідно до вибраних одержувачів і переважного каналу доставки, який буде задіяний для доставки повідомлення до приймаючого пристрою (пристроїв) 107. Переважні канали доставки можуть мати формат обміну повідомленнями на основі даних (Інтернет-протокол/ip), (наприклад, миттєві повідомлення або чат), SMS, MMS, email або будьякий інший визначений формат обміну повідомленнями. Після пересилки передавальним пристроєм 101 повідомлення на сервер доставки 105, воно чекає отримання повідомлення/пакету підтвердження від сервера доставки 105, підтверджуючого отримання повідомлення. Особливий формат підтвердження не завжди є обов'язковим, він може бути легко пов'язаний з початковим відправленим повідомленням. Існує велика кількість підходів для пов'язання повідомлення підтвердження з початковим відправленим повідомленням. Наприклад, зв'язок може бути здійснений через використання серійного номера, відмітки часу тощо, що використовується для генерації унікального повідомлення ID, яке пов'язує повідомлення підтвердження з початковим відправленим повідомленням. Якщо передавальний пристрій 101 не отримує підтвердження, він чекає протягом зумовленого часу, згідно зумовленому ряду правив перед спробою повторної відправки повідомлення. Зумовлений ряд правил не тільки визначає проміжок часу, протягом якого пристрій чекає повторну відправку повідомлення, але також визначає, як часто і як довго повторні спроби продовжуватимуться. Наприклад, ряд правил може бути настроєний так, щоб дозволяти передавальному пристрою 101 здійснювати максимум 10 повторних спроб, при цьому кожна спроба повинна відбуватися через 5-хвилинні інтервали після початкової спроби відправки повідомлення. Якщо після вичерпання максимальної кількості повторних спроб передавальному пристрою 101 все ще не вдалося завершити доставку повідомлення, пристрій зможе після зумовленого періоду спробувати здійснити доставку альтернативним способом направлення повідомлення на сервер доставки 105. Далі, якщо користувач робить спробу вийти з мережі або вийти з клієнта прикладної 4 UA 100722 C2 5 10 15 20 25 30 35 40 45 50 55 60 програми передавального пристрою, тоді як передача повідомлень залишається незавершеною, клієнт прикладної програми передавального пристрою проінформує користувача про статус відправки повідомлення і запропонує альтернативні опції доставки перед завершенням роботи або виходом. Як показано на Фіг.1, сервер доставки 105 в цьому випадку сполучений, щонайменше, з одним email сервером 108 і/або, щонайменше, з одним центром повідомлень (SMSC, MMSC) 109 для забезпечення безлічі надмірних альтернативних каналів доставки. У випадку якщо неможливо відправити повідомлення на приймаючий пристрій (приймаючі пристрої) через первинний канал доставки (тобто вихідний формат повідомлення), сервер доставки перемкнеться на наступний переважний формат доставки. Наприклад, сервер доставки 105 може перемикатися з IM на SMS для здійснення доставки повідомлення. Альтернативно передавальний пристрій 101 може нагадати користувачеві про вибір альтернативного каналу доставки у випадку, якщо повідомлення не може бути доставлене через первинний канал доставки, вибраний користувачем. В деяких випадках користувач може вибрати канал доставки, про недоступність якого відомо серверу, наприклад, користувач може вибрати обмін повідомленнями на основі IP, але сервер знатиме, що приймаючий пристрій недоступний для отримання цього типу повідомлення. В цьому випадку сервер доставки 105 конвертує повідомлення в альтернативний формат повідомлення (SMS, email тощо) для доставки через альтернативний канал доставки (наприклад, email-шлюз 108, SMSC109). Первинний канал доставки може включати ряд інструкцій, включених в заголовок повідомлення, для перемикання сервера на вторинний канал доставки. Кожного разу при відправці (і повторній відправці) сервером доставки 105 повідомлень, воно міститиме лічильник повторних спроб, з відліком від 0 (початкова передача) і далі по збільшенню. Повторні спроби відображаються на лічильнику і їх число збільшується з кожною подальшою спробою. На основі ряду правив, прийнятих на сервері доставки, сервер доставки може потім вибрати спробу використання альтернативних способів доставки повідомлення на основі підрахунку повторних спроб. Це дозволяє конвертувати повідомлення в SMS, MMS або email після певної кількості повторних спроб. У початковому повторенні буде зроблена спроба доставки повідомлення через SMS, після третьої повторної спроби. Протокол кожної спроби доставки повідомлення разом з мережевою інформацією, що включає вузол стільникового зв'язку і так далі, зберігається сервером в базі даних 110. У таких випадках сервер доставки 105 може бути сполучений з HLR (регістром положення) 104 мережі. Якщо не вдається успішно доставити повідомлення, в базу даних 110 записується протокольне повідомлення. Протокол не тільки включає інформацію про невдалу доставку, а також включає інформацію HLR, що відноситься до приймаючого мобільного пристрою. Подальший аналіз забезпечених таким чином даних з використанням стандартних засобів аналізу даних може виявити особливі області мережі, що вимагають обслуговування або нарощування ресурсів. Таке протоколювання може визначати особливі проблеми на несучій частоті, або інші недоліки мережі. Додатково, база даних 110 може бути використана як сховище для повідомлень користувача, що і буде детально описано нижче. На фіг. 2 представлено обмін сигналами, застосований системою обміну повідомленнями 100 згідно одному варіанту здійснення даного винаходу. Для здійснення доставки повідомлення сервер доставки 105 потребує в першу чергу ідентифікації призначеного одержувача (одержувачів) 107 і каналу доставки, якому віддають перевагу користувачі. Кожен пристрійклієнт (передавальний або приймальний 101, 107) в мережі сполучається з сервером з використанням синхронізованих тактових транзакцій 213, і це дозволяє серверу відстежувати присутність всіх пристроїв в мережі. У даному прикладі кожен пристрій-клієнт посилає тактовий сигнал на сервер кожні 10 хвилин. Якщо сервер не отримує тактовий сигнал, після закінчення часу очікування, він позначає пристрій-клієнт як «офлайн». Тактова транзакція застосовується не тільки для індикації присутності пристрою-клієнта, але також і для рівня послуг, доступних у нинішній момент для пристрою-клієнту. Наприклад, якщо користувач відзначив переважну доставку з використанням, наприклад, IM зв'язку, сервер виконує перевірку для підтвердження підключення одержувача 107 до сервера і доступності для отримання повідомлень за допомогою інформації, наданої через тактовий сигнал пристрою одержувача. В деяких випадках приймаючий пристрій 107 може бути не готов або не здатен прийняти IM повідомлення, тоді сервер доставки 105 зробить спробу відправити повідомлення кожного одержувача з використанням відповідного альтернативного каналу доставки, такого як SMS 209, Еmail 207 або іншого придатного формату обміну повідомленнями. Для кожної спроби доставки очікується повідомлення підтвердження/ухвалення від одержувача (або агента доставки, у вигляді можливого варіанту у разі використання SMS і email), після доставки 5 UA 100722 C2 5 10 15 20 25 30 35 повідомлення. Потім воно буде передано початковому відправникові повідомлення. Як згадано вище, особливий формат повідомлення підтвердження не завжди є обов'язковим за умови, що воно дозволить системі пов'язати підтвердження із спочатку відправленим повідомленням. Як показано на Фіг. 2, передавальний пристрій 101 пересилає IM повідомлення 201 на сервер доставки 105 для доставки на приймаючий пристрій 107 через первинний канал доставки 202. Сервер доставки 105 посилає повідомлення підтвердження назад на передавальний пристрій 101. Сервер доставки далі передає IM повідомлення на приймаючий пристрій 107. Приймаючий пристрій 107 потім посилає назад повідомлення підтвердження 203 на сервер доставки 105, сервер доставки 105 потім факультативно повідомляє передавальний пристрій 101 про успішну крізну доставку повідомлення 204. У випадку, якщо первинний канал доставки 202 недоступний, сервер доставки 105 потім робить спробу направити повідомлення через альтернативний канал доставки, такий як email 205 через email-шлюз 108, або SMS 206 через SMSC 109. Якщо вибраним альтернативним маршрутом доставки є email, то сервер доставки 105 конвертує повідомлення з його вихідного формату у відповідний формат email перед відправкою повідомлення 205 на шлюз email. Шлюз email 108 потім пересилає повідомлення 207 на приймаючий пристрій 107, потім приймальний пристрій посилає назад повідомлення підтвердження 208. Аналогічно, якщо як альтернативний канал доставки вибирають SMS або MMS, сервер доставки 105 конвертує повідомлення з його вихідного формату в SMS-пакет відповідного розміру перед пересилкою повідомлення на SMSC 109. В цьому випадку факультативно може бути здійснене урізування повідомлення, проте в даному варіанті здійсненні винаходу відправляється стільки SMS пакетів, скільки потрібно для доставки повідомлення в його повному об'ємі до приймаючого пристрою (пристроів) 107. SMSC 109 потім пересилає повідомлення 209 на приймаючий пристрій 107, а потім приймаючий пристрій посилає назад повідомлення підтвердження 210. У приведеному прикладі сервер не шукає підтвердження для повідомлень 211, 212 (показано пунктирною лінією), відправлених за допомогою email або SMS через email-сервери і/або SMSC/SMS шлюз, оскільки обидваформати вважаються допустимо надійними. Проте, фахівцями в даній області буде оцінено те, що така процедура підтвердження може бути легко включена в систему. Як згадувалося вище, вибір маршруту повідомлень від сервера доставки 105 до приймаючого пристрою 107 може бути здійснений відповідно до ряду зумовлених правил, якими забезпечений сервер доставки 105. Ряд правил визначає кількість повторних спроб; використані альтернативні канали доставки і їх порядок; час, протягом якого повторні спроби продовжуватимуться; частоту повторних спроб. Наступна таблиця показує один приклад ряду правив, вживаного для маршрутизації повідомлень з текстовою системою обміну повідомленнями відповідно до одного варіанту здійснення даного винаходу: Таблиця Приклад ряду правив для маршрутизації повідомлення Пристрійклієнт Статус користувача Офлайн установки У мережі Доступний або Недоступний SMS У мережі Доступний або Недоступний Email Дії з маршрутизації - Спроба доставити, використовуючи звичайний спосіб (IP). - Повторна спроба доставки у разі неотримання повідомлення підтвердження. - Перемикання на SMS (вторинний підхід до доставки) після закінчення спроб доставки (у даному варіанті винаходу - 3 спроби протягом 15 хвилин). - Спроба доставити, використовуючи спосіб за умовчанням (IP). - Повторна спроба доставки у разі неотримання повідомлення підтвердження. - Перемикання на email (вторинний спосіб доставки) після вичерпання спроб доставки (у даному варіанті 3 спроби протягом15 хвилин). 6 UA 100722 C2 Продовження таблиці Пристрійклієнт Згідно вищезгаданому (SMS або email) - Згідно вищезгаданому - статус невидимий не впливає на спосіб доставки. Не турбувати Доступний або Недоступний Офлайн Доступний або Недоступний Офлайн Доступний або Недоступний Офлайн Доступний або Недоступний Офлайн Невидимий Офлайн Невидимий Офлайн 20 Невидимий Офлайн 15 Дії з маршрутизації У мережі 10 Офлайн установки У мережі 5 Статус користувача Не турбувати Збереження повідомлення на сервері до зміни статусу користувачем Серверу відомо, що пристрій-клієнт користувача не здатний прийняти IP повідомлення. SMS - Негайне перемикання на SMS (визначений користувачем спосіб доставки офлайн) Серверу відомо, що пристрій-клієнт користувача не здатний прийняти IP повідомлення. - Спроба запуску прикладної програми - клієнта, використовуючи SS7 або SMS0. Режим запуску - Відправка повідомлення, з використанням IP (Wake-Up) каналу. Продовження нормальних гарантованих спроб доставки, у разі неотримання підтвердження отримання повідомлення (як для описаних вище «у мережі»/SMS). Серверу відомо, що пристрій-клієнт користувача не здатний прийняти повідомлення. Email - Негайне перемикання на Email (визначений користувачем спосіб доставки офлайн) Серверу відомо, що пристрій-клієнт користувача не здатний прийняти повідомлення. Збереження на - Не намагатися доставити повідомлення сервері зберегти повідомлення у файлі на сервері для негайної доставки наступного разу, при підключенні користувача до пристрою. Як і для «офлайн» SMS або режиму запуску SMS або Режим (описано вище). Статус Невидимий не впливає запуску (Wake-Up) на спосіб доставки. Email або Як для «офлайн» Email (описано вище). Статус збереження на Невидимий не впливає на спосіб доставки. сервері Збереження повідомлення на сервері до зміни Недоступний статусу користувачем Недоступний У іншому варіанті здійсненні винаходу, у випадку якщо повідомлення включає зображення або інший файл, альтернативний канал доставки може бути настроєний як MMS або як якийнебудь інший протокол передачі файлів. Користувач може настроювати ряд правив, відповідно до переваг, наприклад, через мережевий інтерфейс тощо. Зміна статусу правила потім передається на сервер доставки, який модифікує операцію ряду правив для конкретного користувача. У даному прикладі по настройкам статусу, офлайн настройкам і поточному знаходженні в мережі користувач може визначити, як йому доставляється повідомлення. Як згадувалося вище, тактова транзакція інформує сервер доставки про присутність користувача. Проте здатність користувача приймати повідомлення визначається на підставі визначених користувачем установок статусу, його «офлайн установок» і того, чи підключений він в системи (чи увійшов він в систему): - Направлення через SMS в режимі офлайн інформує сервер про направлення повідомлень через SMS, у випадку якщо статус пристрою-клієнта встановлений як офлайн; - Направлення через email, при якому повідомлення прямує на email, у випадку якщо користувач не підключений до пристрою-клієнта; - Режим запуску (Wake-Up), що дозволяє системі запустити прикладну програму-клієнт на приймаючому пристрої, використовуючи SS7 або SMS0, а потім передати повідомлення користувача; 7 UA 100722 C2 5 10 15 20 25 30 35 40 45 50 55 60 - Збереження на сервері, що інформує сервер про збереження повідомлення на сервері до тих пір, поки користувач знову не підключиться до пристрою-клієнта. Доступність стає визначеним користувачем атрибутом, що дозволяє користувачеві змінювати застосування ряду системних правил. Як показано в таблиці 1, існує безліч статусів усередині системи, з яких користувач може вибирати залежно від того, знаходиться користувач в мережі або офлайн. Існує чотири основні статуси - доступний, недоступний, не турбувати і невидимий. У мережі офлайн установки, вибрані користувачем, дозволяють здійснювати своєчасну доставку повідомлень через альтернативний канал доставки, статус, вибраний користувачем, зберігається при знаходженні користувача офлайн. Якщо користувач, що знаходиться в мережі, вибирає офлайн установки, що не дозволяють своєчасну доставку, такі як email або «збереження на сервері», їх доступність буде показана як «недоступність для зв'язку» при знаходженні офлайн. Для користувачів «поза мережею» пристрою-клієнту доступні обмежені офлайн установки, наприклад такі як збереження на сервері і email. Таким чином, позамережевий офлайн користувач завжди розглядається як «недоступний для зв'язку». На додаток до вищеописаного, система також може надавати користувачеві можливість привласнювати різні характеристики повідомленню, наприклад, важливість повідомлення. Важливість повідомлення може бути встановлена відправником як нормальна або висока. Важливість повідомлення зберігається у вигляді даних в заголовку повідомлення і використовується по всій мережі для визначення обробки повідомлення. Якщо користувач вибирає високу важливість, правила доставки повідомлення в усій мережі, інфраструктурі сервера та приймаючого пристрою оброблюють повідомлення різними способами. Звичайно повідомлення високої важливості відправляються через канали пересилання з більш високою швидкістю. Для повідомлень високої важливості, в порівнянні із звичайною обробкою згідно ряду правив, вносять наступні зміни: - повторні спроби від передавального пристрою на сервер відбуваються кожну 1 хвилину і їх кількість не перевищує 3 спроби. У разі невдалої відправки повідомлення, відправникові виводиться попередження на передавальному пристрої і надається можливість продовжити або переключитися на альтернативний канал доставки. - повторні спроби від сервера до приймаючого пристрою відбуваються кожну 1 хвилину і їх кількість не перевищує 3 спроби перед перемиканням на альтернативний канал. - повідомлення високої важливості ніколи не направляють тільки на email. Якщо одержувач вказав email в його офлайн установках, то повідомлення будуть скопійовані на email, але також направлені на SMS. - на приймаючому пристрої при отриманні повідомлення високої важливості звучить спеціальний сигнал повідомлення. - на приймаючому пристрої користувача відображається запит про підтвердження отримання, і підтвердження у вигляді повідомлення відправляється назад початковому відправникові (з часом/датою підтвердження). - Повідомлення будуть відмічені в базі даних 110 (описано нижче) як повідомлення високої важливості. Як вже стисло згадувалося вище, база даних 110 може бути використана як блок видаленого сховища. Ці функціональні можливості зберігання («STOREIT») забезпечують можливість зберігання повного архіву всіх повідомлень, відправлених на сервер і з сервера доставки 105. Доступ до повідомлень забезпечується через вебсайт. Користувач може увійти до системи і потім використовувати розширені можливості пошуку і відміток для доступу до своїх повідомлень. Користувачеві надається достатній об'єм пам'яті, і йому не потрібно видаляти попередні повідомлення. Сервер доставки записує кожне відправлене і отримане повідомлення в асинхронному процесі в блок сховища даних 110. Повідомлення зазвичай записуються окремо для кожного відправника/одержувача. Вимоги до пам'яті можна понизити за рахунок запису однієї копії повідомлення і використання посилань для пов'язання цього повідомлення з багатьма відправниками/одержувачами. У цьому підході можуть прийматися компроміси з низькою швидкістю пошуку. Відзначення повідомлень мітками може здійснюватися автоматично, якщо, наприклад, повідомлення містить деякі характеристики: - Містить веб-сервер-посилання - Містить число, що задовольняє критерію розгляду його як номеру телефону - Містить адресу (на основі бази даних ключових слів, таких як «вулиця», «квартира», «вул.», 8 UA 100722 C2 5 10 15 20 25 30 35 40 45 «кв.» тощо) Призначений для користувача інтерфейс «STOREIT» також надає можливість через ПКверсію клієнта обміну повідомленнями пересилати і відповідати на повідомлення. Веб-серверінтерфейс може включати наступне: - здатність входити в систему, використовуючи той же ID користувача і пароль, що і в мобільній прикладній програмі обміну повідомленнями користувача; - Доступ до всіх відправлених і прийнятих повідомлень; Метадані повідомлень, що включають час/дату відправки, інформацію одержувача/відправника - Відзначення повідомлень мітками (вибирані користувачем мітки разом з автоматичними мітками, наприклад, відзначення повідомлень, що містять веб-посилання або номера) - Опції обміну повідомленнями (відповідь на повідомлення, відправка нового повідомлення тощо) - Доступ до списку друзів - Управління архівом повідомлень (видалення деяких або всіх повідомлень для вибраних або всіх одержувачів) - Установки користувача (відключення STOREIT, відключення для окремих одержувачів, включення для окремих одержувачів тощо) Слід розуміти, що вищеописані варіанти здійснення приведені тільки як приклади даного винаходу, і подальші зміни і удосконалення даного винаходу, як буде ясно фахівцеві в даній області, імовірно входять в широкий об'єм і межі даного винаходу, описаного тут. Зокрема, в рамках винаходу можна внести наступні додавання і/або зміни (що не обмежують): - Управління повторними спробами може здійснюватися передавальним пристроєм 101 замість сервера доставки 105. - Підтвердження отримання може йти в обхід сервера доставки 105. У цьому варіанті передавальний пристрій 101 настроєно для забезпечення доставки на приймаючий пристрій 107. - Передавальний пристрій 101 може бути настроєно для відображення користувачеві індикатора з інформацією про статус доставки повідомлення. - Передавальний пристрій 101 може бути настроєно так, щоб вибирати альтернативний канал доставки у випадку, якщо доставка повідомлення по першому каналу доставки не може бути здійснена. - У випадках, коли для доставки повідомлення використовується альтернативна доставка, або передавальний пристрій, або, щонайменше, один сервер можна переформатувати повідомлення для відповідності стандарту обміну повідомленнями альтернативного каналу доставки. - Якщо до передавального пристрою не повертається повідомлення підтвердження, то на додаток до ділових правил і установок користувача, описаних у варіантах здійснення, первинний канал доставки може бути далі настроєний для відправки повідомлення на сервер доставки 105; сервер доставки 105 включає в заголовок повідомлення для перемикання сервера на вторинний канал доставки. Користувачеві може відображатися індикатор, що показує статус доставки повідомлення. Як приклад, для випадку коли повторні спроби повідомлення контролюються передавальним пристроєм, при спробі виходу з прикладної програми, користувач отримує попередження про те, що підтвердження про доставку повідомлення ще не було отримане і що повторні спроби ще не завершені. ФОРМУЛА ВИНАХОДУ 50 55 1. Система обміну повідомленнями, що включає: щонайменше один сервер, настроєний для прийому повідомлення від передавального пристрою для доставки щонайменше одному приймаючому пристрою через перший канал доставки; цей щонайменше один приймаючий пристрій налаштовано для періодичного відправлення рівня сервісної інформації до щонайменше одного серверу, і де щонайменше один цей сервер, у разі, якщо перша доставка не може бути виконана, надалі налаштовується на вибір альтернативного каналу доставки для виконання доставки повідомлення на основі рівня сервісної інформації, отриманої від приймаючого пристрою. 2. Система обміну повідомленнями за п. 1, яка відрізняється тим, що перший канал доставки є каналом інтернет-протоколу і повідомлення є миттєвим повідомленням. 9 UA 100722 C2 5 10 15 20 25 30 35 40 45 50 55 60 3. Система обміну повідомленнями за п. 1, яка відрізняється тим, що перший канал доставки вибирається з щонайменше одного з каналів SMTP, MIME, POP, IMAP, і згадане повідомлення є email-повідомленням. 4. Система обміну повідомленнями за п. 1, яка відрізняється тим, що перший канал доставки є каналом SS7, а повідомлення є SMS або MMS. 5. Система обміну повідомленнями за будь-яким з пп. 1-4, яка відрізняється тим, що сервер настроєний для переформатування повідомлення для відповідності стандарту обміну повідомленнями альтернативного каналу доставки. 6. Система обміну повідомленнями за п. 1, яка відрізняється тим, що щонайменше один сервер пристосований для отримання повідомлення підтвердження від згаданого щонайменше одного приймаючого пристрою про отримання повідомлення через перший канал обміну повідомленнями, при цьому згаданий щонайменше один сервер повідомляє передавальний пристрій про отримання повідомлення щонайменше цим одним приймаючим пристроєм. 7. Система обміну повідомленнями за п. 6, яка відрізняється тим, що передавальний пристрій може проінформувати сервер про негайну відправку повідомлення через альтернативний канал доставки за відсутності отримання повідомлення підтвердження. 8. Система обміну повідомленнями за п. 6 або п. 7, яка відрізняється тим, що повідомлення підтвердження включає серійний номер, відмітку часу або унікальний ID, які пов'язують повідомлення підтвердження з повідомленням, відправленим з передавального пристрою. 9. Система обміну повідомленнями за будь-яким з попередніх пунктів, яка відрізняється тим, що надалі сервер включає один або більше зумовлених рядів правил для управління передачею повідомлення щонайменше на один приймаючий пристрій. 10. Система обміну повідомленнями за п. 9, яка відрізняється тим, що зумовлений ряд правил включає інформацію, що відноситься до періоду часу, протягом якого сервер чекає повторну відправку повідомлення по першому каналу доставки, і до максимальної кількості повторів сервером спроб доставки повідомлення по першому каналу доставки перед перемиканням на альтернативний канал доставки. 11. Система обміну повідомленнями за п. 10, яка відрізняється тим, що повідомлення включає лічильник повторних спроб, на якому з кожною повторною спробою сервера доставити повідомлення щонайменше одному приймаючому пристрою, збільшується число спроб, що відображається. 12. Система обміну повідомленнями за п. 11, яка відрізняється тим, що щонайменше один сервер може бути настроєний для періодичного запису протоколу кожної спроби доставки повідомлення разом із спеціальною інформацією мережі в базу даних. 13. Система обміну повідомленнями за п. 12, яка відрізняється тим, що копії всіх повідомлень, що проходять щонайменше через один сервер, зберігаються в базі даних для подальшого пошуку користувачем. 14. Система обміну повідомленнями за будь-яким з попередніх пунктів, яка відрізняється тим, що копії повідомлень на приймаючому пристрої не відображаються користувачам на основі унікального ідентифікатора. 15. Спосіб маршрутизації повідомлень, що включає стадії, на яких: отримують на сервері повідомлення від передавального пристрою для доставки щонайменше одному приймаючому пристрою; отримують на сервері рівень сервісної інформації від щонайменше одного приймаючого пристрою, де щонайменше один приймаючий пристрій налаштований на періодичне відправлення рівня сервісної інформації до щонайменше одного сервера; пересилають повідомлення щонайменше одному приймаючому пристрою через перший канал доставки; чекають отримання повідомлення підтвердження щонайменше від згаданого одного приймаючого пристрою, а у разі неотримання повідомлення підтвердження щонайменше цей один сервер вибирає альтернативний канал доставки для повторної пересилки повідомлення до щонайменше одного приймаючого пристрою на основі рівня сервісної інформації, отриманної від щонайменше одного приймаючого пристрою. 16. Спосіб за п. 15, який відрізняється тим, що перший канал доставки є каналом інтернетпротоколу (IP), а повідомлення є миттєвим повідомленням. 17. Спосіб за п. 15, який відрізняється тим, що перший канал доставки вибирається щонайменше з одного з каналів SMTP, MIME, POP, IMAP, а згадане повідомлення є emailповідомленням. 18. Спосіб за п. 15, який відрізняється тим, що перший канал доставки є каналом SS7, а повідомлення є SMS або MMS. 10 UA 100722 C2 5 10 15 20 25 30 35 40 45 50 55 19. Спосіб за будь-яким з пп. 15-18, який відрізняється тим, що сервер настроюють для переформатування повідомлення для відповідності стандарту обміну повідомленнями альтернативного каналу доставки. 20. Спосіб за будь-яким з пп. 15-19, який відрізняється тим, що додатково включає стадію, на якій повторно відправляють повідомлення через перший канал доставки зумовлену кількість разів перед здійсненням спроби відправки повідомлення через альтернативний канал доставки. 21. Спосіб за п. 20, який відрізняється тим, що стадія повторної відправки повідомлення через перший канал доставки включає стадію, на якій збільшують число повторів, пов'язаних з повідомленням. 22. Спосіб за будь-яким з пп. 15-21, який відрізняється тим, що копії повідомлень на приймаючому пристрої не відображаються користувачам на основі унікального ідентифікатора. 23. Спосіб за будь-яким з пп. 15-22, який відрізняється тим, що сервер зберігає копії всіх повідомлень для подальшого пошуку користувачем. 24. Спосіб за будь-яким з пп. 15-23, який відрізняється тим, що сервер автоматично відзначає повідомлення мітками на основі визначених системою правил змісту разом з правилами, визначеними користувачем, для подальшого пошуку користувачем. 25. Спосіб маршрутизації повідомлень, що включає стадії, на яких: отримують на сервері повідомлення від передавального пристрою для доставки щонайменше одному приймаючому пристрою; отримують на сервері рівень сервісної інформації від щонайменше одного приймаючого пристрою, де щонайменше один приймаючий пристрій налаштований на періодичну відправку рівня сервісної інформації до щонайменше одного сервера; пересилають повідомлення щонайменше одному приймаючому пристрою через первинний канал доставки; чекають отримання повідомлення підтвердження щонайменше від одного згаданого приймаючого пристрою і пересилки підтвердження назад передавальному пристрою і, у разі неотримання передавальним пристроєм повідомлення підтвердження, передавальний пристрій повторно пересилає повідомлення згаданого сервера, указуючи, що повідомлення повинне бути направлене на приймаючий пристрій шляхом використання альтернативного каналу доставки, де передавальний пристрій вибирає альтернативний канал доставки на базі рівня сервісної інформації, переданої від щонайменше одного приймального пристрою. 26. Спосіб за п. 25, який відрізняється тим, що перший канал доставки є каналом інтернетпротоколу (IP), а повідомлення є миттєвим повідомленням. 27. Спосіб за п. 25, який відрізняється тим, що перший канал доставки вибирають щонайменше з одного з каналів SMTP, MIME, POP, ІМАР, а згадане повідомлення є emailповідомленням. 28. Спосіб за п. 25, який відрізняється тим, що перший канал доставки є каналом SS7, а повідомлення є SMS або MMS. 29. Спосіб за будь-яким з пп. 25-28, який відрізняється тим, що сервер настроюють для переформатування повідомлення для відповідності стандарту обміну повідомленнями альтернативного каналу доставки. 30. Спосіб за будь-яким з пп. 25-29, що далі включає стадію, на якій повторно відправляють повідомлення через перший канал доставки зумовлену кількість разів перед здійсненням спроб відправки повідомлення через альтернативний канал доставки. 31. Спосіб за п. 30, який відрізняється тим, що стадія повторної відправки повідомлення через перший канал доставки включає стадію, на якій збільшують число повторних спроб лічильника, пов'язаного з повідомленням. 32. Спосіб за будь-яким з пп. 25-31, який відрізняється тим, що копії повідомлень на приймаючому пристрої не відображають користувачам на основі унікального ідентифікатора. 33. Спосіб за будь-яким з пп. 25-32, який відрізняється тим, що сервер зберігає копії всіх повідомлень для подальшого пошуку користувачем. 34. Спосіб за будь-яким з пп. 25-33, який відрізняється тим, що сервер автоматично відзначає повідомлення мітками на основі системних певних правил змісту разом з правилами, визначеними користувачем, для подальшого пошуку користувачем. 35. Спосіб за будь-яким з пп. 25-34, який відрізняється тим, що передавальний пристрій відображає користувачеві індикатор із статусом доставки повідомлення. 36. Спосіб за будь-яким з пп. 25-35, який відрізняється тим, що передавальний пристрій, перед здійсненням операції виключення або виходу з системи, попереджає користувача про те, що повідомлення не доставлене. 11 UA 100722 C2 Комп’ютерна верстка А. Крулевський Державна служба інтелектуальної власності України, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601 12