Patent Application
20150302023
While the use of electronic devices continues to grow, an increasing number of users of these devices desire to incorporate the use of small computer devices with their other computing systems. For example, users often desire to incorporate voice mail messages, electronic mail (email), short message service (SMS) messages, contacts, notes, calendar-type application appointments, and/or tasks between their mobile, or handheld, devices and their client computer or server at their place of employment and/or home. Such incorporation allows users to track their messages, email, calendar-type application appointments, contacts, notes, and/or tasks, etc. from nearly any location and at any time of day with their mobile device. While such incorporation is desired, it is also desired to synchronize these voice mail messages, email, calendar-type application appointments, contacts, notes, and/or tasks, etc. amongst the user's mobile device(s), client computer(s), and server(s) such that changes made at any of the devices may be reflected across all devices.
However, when a particular folder or collection of items is synchronized, a common schema is typically applied to all items, e.g., email, voice mail, calendar-type application appointments, tasks, contacts, notes, etc., in that folder regardless of the differences in the classes of items present in the collection. Further, the same options are applied to all classes within the collection. For example, the same filters are applied to each class, as well as the same truncation and body type settings. Where all classes are synchronized altogether and according to a common schema for the entire folder, the synchronization of some class items may be lost where one of the computing systems does not support the particular class of items. For example, a mobile device may not support the receipt of tasks, for example. Alternatively, the user may experience a poor viewing experience in attempting to open a particular message not supported by its system.
Although specific problems have been addressed in this Background, this disclosure is not intended in any way to be limited to solving those specific problems.
Embodiments generally relate to synchronizing multiple classes with disparate schema per class in the same collection or folder through the use of the same synchronization request. Thus, items are synchronized amongst a mobile device, a client computer, and a message server, for example. Any number of types of computing systems known to or understood by those of ordinary skill in the art may be synchronized amongst the other applicable computing systems. By allowing for multiple classes within a collection to have disparate schema appropriate to each particular class of items, e.g., an email schema for email and a voice mail schema for voice mail, a collection of different types of items may be synchronized while still using the unique schema and, thus, properties, for each type of class of items. Further, by allowing for multiple classes with disparate schemas to be synchronized within the same collection while maintaining each class's unique schema, different options may be applied to each different class of items, if desired, in accordance with another embodiment. For example, different filtering, truncation, and body type options may be applied to each specific class. Any number of options, option settings, and types of details specific to such options and option settings as known to or understood by those of ordinary skill in the art may be available in accordance with embodiments disclosed herein. In a particular embodiment, these multiple classes with disparate schemas within a collection are synchronized by using multiple option blocks within a synchronization command. The presence of an option block in a synchronization command notifies the server to synchronize the class specified in the option block. Each such option block represents a single class of item(s) for synchronization. The option block specifies the options, or settings, if any, to apply to the class specified according to an aspect of an embodiment. Where multiple classes have been specified to be synchronized, the response from the applicable server to the synchronization request includes the synchronized items of all classes specified and with each class maintaining its unique schema.
This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in any way as to limit the scope of the claimed subject matter.
Embodiments of the present disclosure may be more readily described by reference to the accompanying drawings in which like numerals refer to like items.
This disclosure will now more fully describe exemplary embodiments with reference to the accompanying drawings, in which specific embodiments are shown. Other aspects may, however, be embodied in many different forms and the inclusion of specific embodiments in this disclosure should not be construed as limiting such aspects to the embodiments set forth herein. Rather, the embodiments depicted in the drawings are included to provide a disclosure that is thorough and complete and which fully conveys the intended scope to those skilled in the art. Dashed lines may be used to show optional components or operations.
Embodiments generally relate to synchronizing multiple classes with disparate schemas within the same collection or folder through the use of the same synchronization transaction (request/response). Where synchronization is initiated, items are synchronized amongst a mobile device, a client, and a message server, for example, in accordance with embodiments. As noted, any number of types of computing systems known to or understood by those of ordinary skill in the art may be synchronized amongst the other applicable computing systems. Further, any type of synchronization key to initiate synchronization may be used as known to or understood by those of ordinary skill in the art without departing from the spirit and scope of the embodiments disclosed herein. Further yet, any type of class of items known to those of ordinary skill in the art may be used in accordance with embodiments disclosed herein. For example, classes may include voice mail messages, email, SMS messages, enhanced messaging service (EMS) messages, multimedia messaging service (MMS) messages, calendar-type application appointments, tasks, contacts, notes, etc. These example classes are offered for purposes of illustration only. Any number of types of classes may be available as known to or understood by those of ordinary skill in the art in accordance with embodiments disclosed herein.
In an embodiment, a request for synchronization may specify the particular class or classes of items within a folder that the user desires to have synchronized. The ability to select specific classes for synchronization allows for the multiple classes within a collection to maintain their unique, and different, schemas. Thus, each schema may have only those properties appropriate for its specific class, as opposed to having a common schema applicable to the collection as whole with the majority of properties named in such being inapplicable to the majority of classes in the collection. Accordingly, an SMS schema may be used for a SMS class, while a voice mail schema may be used for a voice mail class, even where both the SMS items and the voice mail items are located in the email folder. In an embodiment, a user may request that the SMS class be synchronized in the email folder, while not specifying the voice mail class. In such a situation, only the SMS items will be synchronized and returned with their individual schema to the device. As noted, these specific classes and folders are offered for purposes of illustration only and are in no way intended to be limiting. Any number of types of classes and folders may be used as known to or understood by those of ordinary skill in the art without departing from the spirit and scope of the present disclosure.
In accordance with embodiments disclosed herein, the class schemas are defined and published by developers in accordance with embodiments disclosed herein. For example, in an embodiment, client developers write code for the classes according to particular specification(s) which include schema definitions. In writing the schema definition for a particular class, properties are defined for the particular schema for that class, for example.
In another embodiment where both the SMS class and the voice mail class are selected for synchronization, the request for synchronization may specify the particular options to be applied in synchronizing each selected class. For example, the user may specify that all voice mail messages be filtered and that only SMS messages received within the last five (5) days be filtered in accordance with an embodiment. In other embodiments, the request for synchronization may also specify whether truncation of a message is desired so that only a portion of the message is sent to the devices to save bandwidth, local memory and processing, etc. Further, the request for synchronization may specify other options known to or understood by those of ordinary skill in the art, including body type, such as to have the body of a message be viewed in rich text format (RTF), HTML, etc. In an embodiment, where no class is specified, a default class is applied for a given folder. In another embodiment, where a class(es) is specified but no options are specified, default options are applied to the synchronization for a given collection. In yet another embodiment, a set of options is explicitly specified for a particular class even where no class is specified by the synchronization request.
An exemplary logical environment or system 100 for synchronizing multiple classes with disparate schemas within a collection between a client computer, a server, and a mobile device is shown in
Logical environment 100 is not limited to any particular implementation and instead embodies any computing environment upon which the functionality of the environment described herein may be practiced. Further, network 106, although shown as a single network may be any type of network conventionally known to or understood by those of ordinary skill in the art. In accordance with an exemplary embodiment, the network may be the global network (e.g., the Internet or World Wide Web, i.e., “Web” for short). It may also be a local area network, e.g., intranet, or a wide area network. In accordance with embodiments, communications over network 106 occur according to one or more standard packet-based formats, e.g., H.323, IP, Ethernet, and/or ATM. Further, mobile network 108 may use any kind of format known to or understood by those of ordinary skill in the art. Any conceivable environment or system may be understood by those of ordinary skill in the art.
As shown in
It is worth noting at the outset that
Although only one mobile device 110, server 104, and client computer 102 are shown, for example, another embodiment provides for multiple small computer devices to communicate with server 104 and client computer 102. In an embodiment, each small computer device communicates with the same mobile operator network 108, or, in other embodiments, multiple and separate mobile operator networks communicate with the small computer devices. In yet another embodiment, each small computer device communicates with a separate mobile operator network.
While
Turning to server 104, communication module 212 communicates with client computer 102 and mobile device 110, such as by transmitting data packets, according to an embodiment. Configuration module 214 configures for server 104 to send and receive data to and from client computer 102 and mobile device 110 and provides other capabilities, including synchronization. Translation engine 216 translates messages into formats appropriate for the mobile device 110 or client computer 102. For example, translation engine 216 changes the format of an email message from rich text format to XML, for example, before sending it to client computer 102 or mobile device 110. In one aspect of an embodiment, translation engine 216 receives a recorded voice mail message and translates it into a data file including text to send to mobile device 110 as a visually viewable message to be read through user interface 224. Any number of types of translations may occur as known to or understood by those of ordinary skill in the art in accordance with embodiments disclosed. Further, comparison module 215 compares the criteria specified for synchronization, e.g., the class or classes and/or options for the selected class or classes, against the stored items for each class on the folder and applies the selections for synchronization of those items with synchronization module 218. Information/data stored in database 219 may be accessed, retrieved, searched, etc. As noted, these modules and databases are offered by way of example only. As shown by ellipses 217, other or additional modules or storage means as known to or understood by those of ordinary skill in the art may be used.
Further, mobile device 110 includes communication module 220 for providing communications, such as the transmittal of data packets specifying classes desired for synchronization in a particular folder, between mobile device 110 and server 104 in accordance with an embodiment. Such data packets may include XML requests specifying the classes for synchronization and options and identification information of mobile device 110, for example. Configuration module 222 configures mobile device 110 to receive and send data from and to server 104 and provides other capabilities, including message viewing, synchronization capabilities, etc. Messages, prompts, queries, selection menus, etc. are displayed on mobile device 110 for viewing through user interface module 224. Further, playback component 226 provides for voice mails and other messages to be played back to the user using output device(s) on mobile device 110. Information/data stored in database 230 may be accessed, retrieved, searched, etc. As noted, while specific modules and databases are shown, other or additional modules or storage means as known to or understood by those of ordinary skill in the art may be used, as shown by ellipses 228.
While
Upon selecting the class or classes in the specified folder or collection that the user would like to synchronize,
While
If no options are selected, process 500 branches NO to the default 514 to synchronize the class or classes with the options specified by a common schema. If the user specifies the option(s) for synchronization, process 500 branches YES to translate operation 516, in which the boxes and fields or other selection/entry mechanisms for options indicated for the class or classes selected are translated into an XML request. Upon sending this XML request, the option(s) are applied against the items in the class or classes specified in the folder or collection and synchronized 518. The synchronized items are then sent to the devices in send operation 520, and process 500 terminates at end operation 522.
As noted, the synchronization of specific classes with disparate schemas within a single folder or collection may be initiated through user interaction as shown in
Table 1 below provides an example XML synchronization request for using option blocks to notify the server to synchronize a class specified in the option block in accordance with embodiments disclosed herein. In embodiments, the options, or settings, for the synchronization of the specified class in the option block are also specified. Table 1 is offered for purposes of illustration only and is in no way intended to be limiting. As noted, any number of types of options, specific settings, and details specific to those options and settings as reasonably known to or understood by those of ordinary skill in the art may be used in accordance with embodiments disclosed herein. Further, while Table 1 shows the use of option blocks in an example synchronization command, any number of types of option blocks or other mechanisms, synchronization commands, etc., may be used as known to or understood by those of ordinary skill in the art in accordance with embodiments disclosed herein. For example, <CollectionID>15</CollectionID> in Table 1 below indicates synchronization of the Email folder is desired. Option blocks below show that the SMS class, <Class>SMS</Class>, for example, is to be synchronized with the specific settings, e.g., TruncationSize, BodyPreference, Filter, etc., shown for that class:
Turning to
Finally,
System 700 may also contain communications connection(s) 716 that allow the device to communicate with other devices. Additionally, to input content into the fields of the UI on mobile device 110 as provided by UI module 224, for example, in accordance with an embodiment of the present disclosure, system 700 may have input device(s) 714 such as a keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 712 such as a display, speakers, printer, etc. may also be included, in which such devices may be used to display the UI for viewing messages, selecting specific class(es) for synchronization, etc., in accordance with embodiments. All of these devices are well known in the art and need not be discussed at length here.
Having described embodiments of the present disclosure with reference to the figures above, it should be appreciated that numerous modifications may be made to the embodiments that will readily suggest themselves to those skilled in the art and which are encompassed within the scope and spirit of the present disclosure and as defined in the appended claims. Indeed, while embodiments have been described for purposes of this disclosure, various changes and modifications may be made which are well within the scope of the present disclosure.
Similarly, although this disclosure has used language specific to structural features, methodological acts, and computer-readable media containing such acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific structure, acts, features, or media described herein. Rather, the specific structures, features, acts, and/or media described above are disclosed as example forms of implementing the claims. Aspects of embodiments allow for multiple client applications, multiple data packet types, etc. Or, in other embodiments, a single client computer with a single server and single mobile device are used. One skilled in the art will recognize other embodiments or improvements that are within the scope and spirit of the present disclosure. Therefore, the specific structure, acts, or media are disclosed as exemplary embodiments of implementing the present disclosure. The disclosure is defined by the appended claims.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12334314 | Dec 2008 | US |
| Child | 14755617 | US |
