Сообщение непредвиденных ответов сервера для совместной работы на повторное соединение

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

 

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

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

[0002] Когда существует возможность сетевого соединения, толстые или тонкие клиенты обеспечивают цельное восприятие пользователем. С другой стороны, если возможность сетевого соединения теряется, клиентское приложение может все еще предоставлять некую функциональность пользователю, но не иметь возможности синхронизироваться с сервером. Таким образом, некоторые из служб связи могут быть прерваны. Например, сообщения электронной почты могут не быть отправлены или извлечены, элементы календаря не могут быть обновлены и т.д. В некоторых реализациях клиентское приложение может действовать нормально и выполнять функции, даже когда возможность сетевого соединения отсутствует, и воспроизводить действия пользователя, после того как возможность соединения восстанавливается. Однако прерывание работы сети не всегда может продолжаться в течение короткого периода. Если прерывание работы продолжается относительно длительный период (например, часы или дни), воспроизведение действия пользователя после восстановления возможности соединения или ошибка в воспроизведении пользовательского действия после восстановления возможности соединения может приводить к замешательству пользователя. Например, запланированная встреча может быть предоставлена пользователю, после того как запланированное время прошло. Некоторые традиционные системы предупреждают пользователя каждый раз, когда существует прерывание работы, что может ухудшать восприятие пользователем. Другие системы просто не сообщают о каких-либо авариях, что потенциально может приводить в результате к плохим ситуациям, таким как потеря доверия пользователя в системе связи.

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

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

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

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

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

[0006] Фиг. 1 иллюстрирует примерную систему для обеспечения служб асинхронной связи, где варианты осуществления могут быть реализованы;

[0007] Фиг. 2 иллюстрирует примерную веб-архитектуру службы электронной почты согласно вариантам осуществления;

[0008] Фиг. 3 иллюстрирует примерные последовательности действий в службе связи согласно вариантам осуществления;

[0009] Фиг. 4 иллюстрирует архитектуру примерной системы с оффлайновой поддержкой согласно вариантам осуществления;

[0010] Фиг. 5 иллюстрирует примерный пользовательский интерфейс для службы электронной почты с поддержкой для уведомлений об оффлайновом действии согласно вариантам осуществления;

[0011] Фиг. 6 - это сетевое окружение, где система согласно вариантам осуществления может быть реализована;

[0012] Фиг. 7 - это блок-схема примерного вычислительного операционного окружения, где варианты осуществления могут быть реализованы; и

[0013] Фиг. 8 иллюстрирует логическую блок-схему последовательности операций для процесса сообщения непредвиденных ответов сервера совместной работы при повторном соединении согласно вариантам осуществления.

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

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

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

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

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

[0018] Варианты осуществления могут быть реализованы как реализуемый компьютером процесс (способ), вычислительная система или как продукт производства, такой как компьютерный программный продукт или машиночитаемые носители информации. Компьютерный программный продукт может быть компьютерным носителем хранения информации, считываемым посредством компьютерной системы, и кодирующим компьютерную программу, которая содержит инструкции, чтобы заставлять компьютер или вычислительную систему выполнять примерный процесс(ы). Читаемый компьютером носитель хранения информации может, например, быть реализован посредством одного или более из энергозависимой компьютерной памяти, энергонезависимой памяти, накопителя на жестком диске, флэш-накопителя, гибкого диска или компакт-диска и аналогичных носителей.

[0019] По всему этому описанию термин "платформа" может быть комбинацией программного обеспечения и компонентов аппаратных средств для предоставления служб асинхронной связи, таких как электронная почта или обмен текстовыми сообщениями. Примеры платформ включают в себя, без ограничения, размещенную на сервере службу, выполняемую посредством множества серверов, приложение, выполняемое на одном вычислительном устройстве, и аналогичные системы. Термин "сервер", как правило, ссылается на вычислительное устройство, выполняющее одну или более программ системы программного обеспечения типично в сетевом окружении. Однако сервер может также быть реализован как виртуальный сервер (программы программного обеспечения), выполняемый на одном или более вычислительных устройствах, рассматриваемых в качестве сервера в сети. Больше подробностей по этим технологиям и примерным операциям предоставлено ниже. Как используется в данном документе, термин "действие" относится к взаимодействию с приложением связи, такое как выбор/активация элемента пользовательского интерфейса или обеспечение ввода через пользовательский интерфейс. Термин "задача" относится к операциям, выполняемым системой в ответ на "действия" или другие события в предоставлении служб связи пользователям.

[0020] Фиг. 1 иллюстрирует, в схеме 100, примерную систему для обеспечения служб асинхронной связи, где варианты осуществления могут быть реализованы. Служба 102 связи может обеспечивать службы асинхронной связи, такие как обмен электронной почтой, обмен текстовыми сообщениями и аналогичные, вместе с такими дополнительными особенностями, как службы планирования (календарь), контакты, списки задач и аналогичные. Служба 102 связи может взаимодействовать с клиентскими приложениями 104, 106 по сети(ям) 110, чтобы обеспечивать связь.

[0021] Клиентские приложения 104, 106 могут быть толстыми или тонкими клиентами. Толстые клиенты являются локально установленными клиентскими приложениями, которые выполняют большую часть функциональности локально, синхронизируясь с сервером периодически или по запросу. Тонкие клиенты типично являются типовыми приложениями, такими как веб-браузеры, которые предоставляют возможность доступа к службам связи через пользовательский интерфейс, управляемый посредством сервера, где большая часть функциональности основывается на сервере. В любом случае, функциональность клиентских приложений зависит от возможности связи со службой 102 связи.

[0022] Клиентское приложение может быть отсоединено от сети(ей) 110, когда предоставляет признаки электронной почты, календаря или контактов службы обмена электронной почтой, например, особенно на переносном устройстве. Действия, которые пользователь предпринимает, могут быть воспроизведены после того, как возможность соединения восстанавливается, без вмешательства пользователя. Период разъединения может, однако, измеряться секундами, минутами, часами или днями. Если действие не удается воспроизвести целиком или частично, проблема заключается в том, указывать ли и как указывать отказ воспроизведения пользователю.

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

[0024] Фиг. 2 иллюстрирует примерную веб-архитектуру службы электронной почты согласно вариантам осуществления на схеме 200.

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

[0026] Другие основные функциональные компоненты в системе согласно вариантам осуществления могут включать в себя управляющие элементы клиентских элементов 214 управления, такие как список, текстовое окно, редактор и т.д.; клиентское представление 212, которое является совокупностью шаблонов, которые являются композицией примитивных элементов управления; модель 216 клиентского представления, которая включает в себя логику приложения; и клиентскую модель 218, которая включает в себя администратор данных, календари, папки, контакты и т.д.

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

[0028] Клиентское представление 212 может привязывать интерфейс к пользовательскому восприятию и выступать как отражение модели 216 клиентского представления в пользовательском интерфейсе. Привязка данных является главным механизмом для связи между клиентским представлением 212 и нижними уровнями. Клиентское представление 212, которое является совокупностью шаблонов, содержащих примитивные элементы управления, может иметь соответствие 1:1 с моделью 216 клиентского представления. Конфигурация, применяющая привязку данных между клиентским представлением 212 и моделью 216 клиентского представления, может предоставлять возможность создания полного представления для модели представления с помощью шаблонов. В системе, такой как показанная на схеме 200, уведомления 226 могут быть направлены от службы 220 связи к элементам 214 управления клиента, в то время как события направляются от элементов 214 управления клиента к службе 220 связи или к клиентскому кэшу 222.

[0029] Фиг. 3 иллюстрирует примерную последовательность действий в службе связи согласно вариантам осуществления на фиг. 300. В системе согласно вариантам осуществления действия 334 могут быть получены посредством моделей 332 представления, как обсуждалось выше.

[0030] Когда приложение связи соединено, пользовательский интерфейс может считывать и записывать пользовательские действия из и в локальное хранилище данных (посредник 336 клиентского хранилища) и записывать действия как в локальное хранилище данных, так и на сервер, чтобы поддерживать синхронизацию. Когда приложение теряет возможность соединения, действия 334 могут совершаться локально до тех пор, пока возможность соединения не будет восстановлена. Чтобы отразить эти действия на сервере, после того как возможность соединения была восстановлена, действия 334 могут быть сохранены в очередь (прокси-сервер 344 с организацией очереди) в локальной таблице веб-базы данных или собственной таблице базы данных устройства в то же время, когда они совершаются локально. В некоторых вариантах осуществления объединенный прокси-сервер 340 может применяться между посредником 336 клиентского хранилища и онлайновым посредником 342 сервера. Последовательность может быть непосредственной от объединенного прокси-сервера 340 к онлайновому прокси-серверу 342 или через прокси-сервер 344 с организацией очереди. Всякий раз, когда устройство восстанавливает соединение (что определяется посредством отдельного процесса, такого как администратор соединения), действия могут быть воспроизведены серверу (в онлайновом прокси-сервере 342).

[0031] Если сервер не имеет возможности обрабатывать действие, он может возвращать ответ об отказе. Ответ об отказе может быть передан процессору 330 ответов в архитектуре администратора действий. Процессор 330 ответов может предоставлять информацию, чтобы предоставлять возможность коду пользовательского интерфейса выбирать, нужно ли и как делать явным отказ для пользователя, на основе множества факторов. Данные о каждом из этих факторов могут быть возвращены с ответом об отказе процессору ответов. Факторы могут включать в себя, но не только, тип отказа, зависят ли другие действия от успешности этого действия, время с момента, когда было предпринято действие, устройство, на котором действие было предпринято, пользовательский профиль и/или частоту использования, способ связи (например, электронная почта в сравнении с обменом текстовыми сообщениями), или характер действия. Например, создание/модификация/удаление элемента календаря, которое затрагивает собственное время пользователя, может быть менее критичным, чем когда элемент календаря затрагивает также других пользователей (например, встреча). Кратковременные разъединения могут быть прозрачны для пользователя (например, для связанных с элементом календаря или контакта действий), тогда как долговременные разъединения могут иметь значение с точки зрения планирования, связи, анализа и т.д.

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

[0033] Зависимостью других действий от успешности конкретного действия может быть, например, сообщение, имеющее получателя, адрес которого не существует в организации. Отправка может быть успешной, но разрешение имени адреса для этого единичного получателя может быть неуспешным. В случае единичных отказов, от которых зависят другие действия, может выполняться откат всех связанных действий, или другим действиям может быть предоставлена возможность продолжаться, и возвращается отказ только этого действия. Таким образом, процессор 330 ответов может вызывать код, чтобы соответствующим образом реагировать на ответ об успешности или отказе и в зависимости от ответов об успешности или отказе связанного или зависимого действия, с сервера всякий раз, когда возможность соединения восстанавливается, причем в это время действие может быть воспроизведено, повторно запрошено или удалено (проигнорировано).

[0034] Фиг. 4 иллюстрирует архитектуру примерной системы с оффлайновой поддержкой согласно вариантам осуществления на схеме 400.

[0035] Пользовательский интерфейс 452 является верхним уровнем системы, предоставляющим возможность взаимодействия с пользователями и включающим в себя объекты представления и модели представления. Действия 458, такие как ответ на сообщение, изменение свойства элемента, удаление свойства, чтение сообщения и т.д., принятые с уровня 452 пользовательского интерфейса, могут быть использованы для объектов 456 привязки данных пользовательского интерфейса, которые передаются по обратной связи на уровень 452 пользовательского интерфейса. Действия 458 и объекты 456 привязки данных представлены на уровне 454 модели (клиентская сторона).

[0036] На серверной стороне уровень 460 постоянного доступа к данным может включать в себя диспетчер 464 действий и администратор 462 синхронизации. Диспетчер 464 действий может принимать действия (например, с помощью вызова запроса действия). Действия и задачи могут быть предоставлены в ответ на действия (для пользовательского интерфейса), принятые от онлайновой или оффлайновой бизнес-логики и хранилищ данных. Администратор 462 синхронизации может обеспечивать синхронизацию действий и ответов об отказах между онлайновыми и оффлайновыми состояниями.

[0037] Онлайновая бизнес-логика 468 может включать в себя папки, сообщения, вложения, календари, контакты и аналогичные элементы, ассоциированные со службой связи. Онлайновая бизнес-логика 468 может также включать в себя представления для этих элементов, а также логику синхронизации папок, логику уведомлений и логику схемы свойств. Онлайн-хранилище 470 может хранить папки, сообщения и вложения, а также представления для них. Онлайн-хранилище 470 может дополнительно включать в себя синхронизацию интерфейса, уведомления и схему свойств. Абстракция физического уровня для 472 для онлайновой бизнес-логики может включать в себя индексы, таблицы и столбцы и предоставлять возможность взаимодействия с базами данных, такими как реляционные базы данных или другие.

[0038] Комбинация 466 оффлайновой бизнес-логики и хранилища может включать в себя элементы, попадающие в папки, вложения, календари, контакты и аналогичные элементы, а также представления для них. Комбинация 466 оффлайновой бизнес-логики и хранилища может дополнительно включать в себя уведомления, представления и действия сохранения и выгрузки. Абстракция физического уровня для 474 для оффлайновой бизнес-логики может также включать в себя индексы, таблицы и столбцы и предоставляет возможность взаимодействия с базами данных, такими как реляционные веб-базы данных, индексированные базы данных или другие.

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

[0040] Фиг. 5 иллюстрирует примерный пользовательский интерфейс для службы электронной почты с поддержкой уведомлений об оффлайновом действии согласно вариантам осуществления. Уведомления пользователя об отказе могут быть предоставлены множеством способов через любой пользовательский интерфейс приложения связи. Примерный пользовательский интерфейс 500 на фиг. 5 представлен лишь в иллюстративных целях.

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

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

[0043] Пример пользовательского интерфейса 500 представляет папку "Черновики" приложения электронной почты. Элемент 582 пользовательского интерфейса предоставляет возможность пользователю вернуться к списку всех папок. Краткое состояние обновления 584 указывает пользователю последнее время, когда была обновлена локальная версия. Как обсуждалось выше, визуальное уведомление 586 может подчеркивать для пользователя характер отказа. Визуальное уведомление 586 может сопровождаться звуковым уведомлением 588, таким как характерный звук. В других вариантах осуществления более подробная информация об отказе, такая как связь, ассоциированная с отказом, время отказа, пользовательские варианты смягчения последствий отказа и т.д., может также быть отображена в зависимости от конфигурации пользовательского интерфейса, доступного экранного пространства, типа устройства и т.д.

[0044] Фиг. 6 является примерным сетевым окружением, где варианты осуществления могут быть реализованы. Система для сообщения непредвиденных ответов сервера для совместной работы при повторном соединении может быть реализована через программное обеспечение, выполняемое на одном или более серверах 614, таком как размещаемая на сервере служба. Платформа может осуществлять связь с клиентскими приложениями на индивидуальных вычислительных устройствах, таких как смартфон 613, переносной компьютер 612 или настольный компьютер 611 ('клиентские устройства'), через сеть(и) 610.

[0045] Клиентские приложения, выполняемые на любом из клиентских устройств 611-613, могут обеспечивать связь через приложение(я), выполняемое серверами 616, или на индивидуальном сервере 616. Приложение связи, выполняемое на одном из серверов, может обеспечивать предоставление уведомлений об отказах пользователям и исполнение соответствующих задач на основе предварительно определенных критериев, как обсуждалось выше. Приложение может извлекать релевантные данные из хранилищ(а) 619 данных непосредственно или через сервер 618 базы данных и предоставлять запрошенные службы пользователю(ям) через клиентские устройства 611-613.

[0046] Сеть(и) 610 может содержать любую топологию серверов, клиентов, поставщиков Интернет-услуг и сред связи. Система согласно вариантам осуществления может иметь статическую или динамическую топологию. Сеть(и) 610 может включать в себя безопасные сети, такие как корпоративная сеть, небезопасные сети, такие как беспроводная открытая сеть или Интернет. Сеть(и) 610 может также координировать связь через другие сети, такие как телефонная коммутируемая сеть общего пользования (PSTN) или сотовые сети. Кроме того, сеть(и) 610 может включать в себя беспроводные сети ближнего действия, к примеру, по технологии Bluetooth и т.п. Сеть(и) 610 предоставляет связь между узлами, описанную в данном документе. В качестве примера, а не ограничения, сеть(и) 610 может включать в себя беспроводные среды, такие как акустическая, RF, инфракрасная и другие беспроводные среды передачи.

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

[0048] Фиг. 7 и последующее обсуждение предназначены, чтобы предоставить краткое общее описание подходящего вычислительного окружения, в котором могут быть реализованы варианты осуществления. Со ссылкой на фиг. 7, иллюстрируется блок-схема примерного вычислительного операционного окружения для применения согласно вариантам осуществления, такого как вычислительное устройство 700. В базовой конфигурации вычислительное устройство 700 может быть любым вычислительным устройством, таким как сервер, выполняющий приложение связи, обеспечивающее уведомление об относящемуся к соединению отказе согласно вариантам осуществления и включающее в себя, по меньшей мере, один процессор 702 и системную память 704. Вычислительное устройство 700 может также включать в себя множество процессоров, которые совместно выполняют программы. В зависимости от точной конфигурации и типа вычислительного устройства системная память 704 может быть энергозависимой (такой как RAM), энергонезависимой (такой как ROM, флеш-память и т.д.) или некоторой комбинацией обеих. Системная память 704 типично включает в себя операционную систему 705, подходящую для управления работой платформы, такую как операционные системы семейства WINDOWS® от корпорации MICROSOFT из Редмонда, штат Вашингтон. Системная память 704 может также включать в себя одно или более приложений системы программного обеспечения, такое как служба 724 связи и модуль 726 администратора синхронизации.

[0049] Когда приложение 724 связи теряет возможность соединения, действия могут совершаться локально до тех пор, пока возможность соединения не будет восстановлена. Всякий раз, когда клиентское устройство вновь получает возможность соединения, действия могут воспроизводиться серверу. Если сервер не имеет возможности обрабатывать действие, он может возвращать ответ об отказе. Модуль 726 администратора синхронизации может определять, как сделать явным отказ для пользователя на основе множества факторов. Факторы могут включать в себя, но не только, тип отказа, зависят ли другие действия от успешности этого действия, время с момента приема действия, или устройство, на котором действие было предпринято. Эта основная конфигурация иллюстрирована на фиг. 7 такими компонентами в пределах пунктирной линии 708.

[0050] Вычислительное устройство 700 может иметь дополнительные признаки или функциональность. Например, вычислительное устройство 700 может также включать в себя дополнительные устройства хранения данных (съемные и/или несъемные) такие как, например, магнитные диски, оптические диски или лента. Такое дополнительное запоминающее устройство иллюстрировано на фиг. 7 съемным устройством 709 хранения данных и несъемным устройством 710 хранения данных. Машиночитаемые носители хранения данных могут включать в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения информации, такой как читаемые компьютером инструкции, структуры данных, программные модули или другие данные. Системное запоминающее устройство 704, съемное устройство 709 хранения данных и стационарное устройство 710 хранения данных являются примерами машиночитаемых носителей хранения данных. Машиночитаемые носители хранения данных включают в себя, но не только, RAM, ROM, EEPROM, флэш-память или другую технологию памяти, CD-ROM, цифровые многофункциональные диски (DVD) или другое оптическое устройство хранения данных, устройство хранения данных на магнитном диске или другие магнитные устройства хранения, или любой другой носитель, который может быть использован, чтобы хранить желаемую информацию, и к которому может быть осуществлен доступ посредством вычислительного устройства 700. Любые такие машиночитаемые носители хранения данных могут быть частью вычислительного устройства 700. Вычислительное устройство 700 может также иметь устройство(а) 712 ввода, такое как клавиатура, мышь, перо, устройство голосового ввода, устройство сенсорного ввода и аналогичные устройства ввода. Устройство(а) 714 вывода, такое как дисплей, динамики, принтер и другие типы устройств вывода, может также быть включено в состав. Эти устройства хорошо известны в области техники, и нет необходимости обсуждать их долго здесь.

[0051] Вычислительное устройство 700 может также содержать соединения 716 связи, которые позволяют устройству связываться с другими устройствами 718, например, по проводной или беспроводной сети в распределенном вычислительном окружении, спутниковой линии связи, сотовой линии связи, сети ближнего действия, и посредством аналогичных механизмов. Другие устройства 718 могут включать в себя компьютерное устройство(а), которое выполняет приложения связи, веб-серверы и аналогичные устройства. Соединение(я) 716 связи являются одним примером сред связи. Среда связи может включать в себя в данном документе читаемые компьютером инструкции, структуры данных, программные модули или другие данные. В качестве примера, но не в качестве ограничения, среда связи включает в себя проводную среду, такую как проводная сеть или прямое проводное соединение, и беспроводную среду, такую как акустическая среда, RF, инфракрасное излучение и другая беспроводная среда.

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

[0053] Другой необязательный вариант заключается в выполнении одного или более отдельных этапов способов в сочетании с выполнением нескольких из них одним или более людей-операторов. Этим операторам не нужно располагаться рядом друг с другом, каждому может быть предоставлена машина, которая выполняет часть программы.

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

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

[0056] На необязательном этапе 820 действия могут быть предоставлены серверу и сохранены в локальном кэше в качестве резервной копии в случае потери возможности сетевого соединения. Когда приложение теряет возможность соединения, действия могут совершаться локально до тех пор, пока возможность соединения не будет восстановлена. Чтобы отразить эти действия на сервере, после того как возможность соединения была восстановлена, действия могут быть сохранены в очереди в локальной таблице веб-базы данных или собственной таблице базы данных устройства в то же время, когда они совершаются локально.

[0057] На этапе 830 процессор ответов может определять, когда и как делать явным ответ об отказе для пользователя (через пользовательский интерфейс), на основе одного или более факторов. Если сервер не имеет возможности обрабатывать действие, он может возвращать ответ об отказе. Ответ об отказе может быть передан процессору ответов в архитектуре администратора действий. Процессор ответов может предоставлять информацию, чтобы предоставлять возможность коду пользовательского интерфейса выбирать, нужно ли и как делать явным отказ для пользователя, на основе множества факторов. Данные о каждом из этих факторов могут быть возвращены с ответом об отказе процессору ответов. Факторы могут включать в себя, но не только, тип отказа, зависят ли другие действия от успешности этого действия, время с момента, когда было предпринято действие, или устройство, на котором действие было предпринято.

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

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

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

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

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

3. Способ по п. 2, дополнительно содержащий этапы, на которых:
воспроизводят сохраненное действие серверу после восстановления возможности соединения.

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

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

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

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

8. Система по п. 7, при этом модель клиентского представления поддерживает состояния приложения.

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

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