JP4575591B2 - Meeting requests and group scheduling generation from mobile devices - Google Patents

Description

【図面の簡単な説明】
【図１】 本発明の基本環境を示すブロック図である。
【図２】 本発明によるモバイルデバイスと併用される従来のデスクトップコンピュータの一実施形態のブロック図である。
【図３】 本発明によるモバイルデバイスの一実施形態を示す簡略化した絵図である。
【図４】 図３に示すモバイルデバイスの一実施形態の簡略化したブロック図である。
【図５】 図２に示すデスクトップコンピュータの一部の一実施形態と、図３および図４に示すモバイルデバイスとを示すブロック構造図であり、デスクトップコンピュータ上および本発明によるモバイルデバイス上のオブジェクト記憶装置に記憶された同期情報を示す。
【図６】 図２に示すデスクトップコンピュータの一部の一実施形態と、図３および図４に示すモバイルデバイスとを示すブロック構造図であり、ミーティング要求の生成および転送を示す。
【図７】 本発明の好ましい一実施形態によるミーティング要求の生成を示す流れ図である。
【図８】 本発明の好ましい一実施形態による図３および図４に示すモバイルデバイス上のミーティング要求に対する応答処理を示す流れ図である。
【図９】 本発明の好ましい一実施形態による図２に示すデスクトップコンピュータ上のミーティング要求に対する応答処理を示す流れ図である。
【図１０】 本発明の好ましい一実施形態によるミーティング要求のテキスト記述をローカライズするローカライザの利用を示す流れ図である。
【図１１】 図１１Ａおよび図１１Ｂは、本発明によるミーティング要求のテキスト記述をローカライズするために使用されるテンプレートの一実施形態を示す。[0001]
(Background of the Invention)
Mobile devices are small electronic computing devices often referred to as personal digital assistants. One such mobile device is sold under the brand name Handheld PC (or “H / PC”) based on the Windows CE brand operating system provided by Microsoft in Redmond, Washington. ing. While such mobile devices can perform a wide range of computing tasks and applications, personal information managers (PIMs) are particularly suitable for mobile devices.
[0002]
PIM typically includes applications that allow mobile device users to better manage scheduling, communication, and other such tasks. Some commonly available PIMs include scheduling and calendar programs, task lists, address books, and e-mail programs. Some commonly available PIMs are sold under the brand names Microsoft Schedule + and Microsoft Outlook, and are available from Microsoft Corporation in Redmond, Washington. For the purposes of this discussion, PIM also includes a separate email application, such as that available under the brand name Microsoft Exchange.
[0003]
Ordinarily, mobile devices are used in conjunction with desktop computers. For example, a user of a mobile device can also have and use an office, home, or both desktop computer. Users typically run the same type of PIM on both desktop computers and mobile devices (although certain versions of PIM may differ somewhat between desktop computers and mobile devices). For this reason, it is highly advantageous if the mobile device is designed to be connectable to a desktop computer, to exchange information with it, and to share information.
[0004]
The user can also make changes to the PIM on both the mobile device and the desktop. Thus, it is advantageous if the PIM on both the mobile device and the desktop contains the latest information, regardless of whether recent changes to the PIM were made on the mobile device or desktop computer. The procedure of connecting the mobile device to the desktop computer and integrating the information stored by the PIM on the mobile device and the desktop computer so that both have the same updated information is called synchronization.
[0005]
Traditional PIMs that support electronic calendar and scheduling functions (collectively referred to as schedulers or scheduling applications) are classically supported on desktop computers. Such a PIM provides the ability for a user to schedule a meeting request for one or more desired attendees.
[0006]
In order to generate a meeting request, the user typically interacts with a scheduling application via a user interface. The user interface provides the user with a plurality of selectable options for parameterizing the meeting request. For example, the normal user interface allows the user to select the date and time (and often the location) that the meeting will be held. Ordinarily, the user interface selects the attendees that the user wants to join the meeting, enters a text description with the meeting and has only one date, or a recurring meeting (meeting) (ie , Whether the meeting is held on only one date, or the 15th of every month, the first Monday of every month, every Monday, etc.).
[0007]
Based on this information, the scheduling application creates an object representing the meeting and enters it into the user's calendar as an appointment. Such objects are usually defined by a number of characteristics, some of which are defined by user input information provided by the user while generating the meeting request. The meeting information also includes a critical time stamp (UTC), which is updated whenever a significant change is made to the meeting object, such as a meeting start or end time change, location change, etc.
[0008]
Appointments entered in the calendar are viewed as meetings because other people are identified as attendees, and scheduling applications are typically commercially available from the Messaging Application Programming Interface (MAPI) or Microsoft Corporation in Redmond, Washington. Invoke methods exposed by email applications according to other APIs that are well-proven and exposed sets of interfaces.
[0009]
In response, the email application generates another object that represents the meeting request (an email meeting request object), and the email application (or suitable transport) well defines this email meeting request object. And format it into an email message suitable for transfer. In doing this, a critical timestamp from the meeting object is also placed in the email meeting request object. The email application then interacts with the specific transport, transports the email meeting request object to the network, and the network routes it to the designated attendee. In doing this, the email application typically accesses an address book stored in a database to obtain an email address that is fully qualified for the attendee. This is also typically done by calling a MAPI or other suitable API method associated with the database storing the address book. The creation of the meeting object and the email meeting request object are collectively referred to herein as meeting request creation.
[0010]
Then, typically a potential attendee responds to the meeting request. In doing this, the caller's critical timestamp is sent back (no change) with the response. The response also includes an indication of the recipient's critical timestamp and the recipient's response (eg, accept, reject, provisional accept, etc.). The recipient's critical timestamp is updated by the recipient (possible attendees) whenever the recipient makes a significant change. This allows the user to reliably order the receipt of multiple versions of the same meeting (for example, a caller has changed the meeting time, date, or location, resulting in multiple meeting requests) Can do. In addition, the caller can order the receipt of responses in a reliable manner to ensure that each response correlates to the latest version of the meeting.
[0011]
The response is then forwarded to the caller (eg, calling computer). The caller's email application and scheduling application then typically processes the response (s) accordingly. For example, for each recipient (or potential attendee), the caller stores the recipient's critical timestamp along with each recipient's response code (representing an acceptance, rejection, provisional acceptance response) in a table. The two commercially available PIMs identified above (Microsoft Schedule + and Microsoft Outlook branded PIMs) are examples of PIMs that support the functions described above.
[0012]
Meeting cancellations and exceptions to recurring meetings must also be handled. For example, PIM allows cancellation of scheduled meetings and various exceptions to the regular meeting pattern.
[0013]
The scheduling of meeting requests as described above has been perpetual until now by a desktop or laptop computer with a hard disk drive or other mass memory mechanism, or on a server or similar other computer including its own mass storage. Has been supported only by intelligently attached low intelligence terminals. The ability to schedule meeting requests from mobile devices is simply not available. Some current mobile devices have a PIM that allows users to view meeting requests and view meetings that have already been scheduled, but on current mobile devices, users can request meeting requests from the mobile device itself. Cannot be generated.
[0014]
There are a number of significant obstacles in attempting to provide users with the ability to generate meeting requests from mobile devices. Exceptions to meeting cancellations and recurring meetings must be handled. There is also a considerable problem with the possibility of transferring double meeting requests. While it is not necessary to generate duplicate meeting requests at every PIM, as described below, it presents a potential problem that must be considered. For example, if a mobile device user can generate a meeting request, the meeting object is first entered into the mobile device's calendar. The email application on the mobile device then creates a corresponding email meeting request object.
[0015]
Next, when the mobile device is synchronized with the desktop computer, the meeting object is synchronized with the calendar object store on the desktop computer, and the email meeting request object is synchronized with the desktop outbox. The desktop computer recognizes the email meeting request object in the outbox, formats it for transfer, and transfers it over the network. In addition, as a result of synchronizing the meeting object with the desktop computer calendar, the desktop computer may create and forward another e-mail meeting request object. This results in the creation of a dual email meeting request object (after synchronization, one by the mobile device and one by the desktop computer). Under such circumstances, a potential attendee may receive more than one meeting request and respond to both. This creates a double response to what should be a single meeting request.
[0016]
For example, a similar problem may occur if a meeting request is generated in a conventional manner (to a desktop computer) and then synchronized to a mobile device that has the ability to generate and forward the meeting request. Meeting objects on the desktop calendar are synchronized to the mobile device calendar. The mobile device then recognizes the synchronized meeting object from the desktop and creates an email meeting request object and attempts to transfer the object. This results in substantially the same problem. That is, a double meeting request and a double response are generated for what should be a single meeting request.
[0017]
Furthermore, if the user of the mobile device is coupled to one or more desktop computers (if the mobile device has this capability, such as a home computer and a work computer) mobile device, the same problem results. In that example, and using conventional architecture, both desktop computers synchronize and recognize the meeting object and email meeting request object from the mobile device. Both desktop computers may create additional email meeting request objects and forward them to potential attendees. Again, this results in many different meeting requests and responses being forwarded for what should be a single meeting request.
[0018]
In addition, if a mobile device has the ability to connect directly to another mobile device and communicate with each other without going through a desktop or similar computer, a meeting request is generated on one mobile computer and the other mobile device And can be scheduled on both mobile devices. However, the next time the first mobile device synchronizes with the desktop computer, the computer again recognizes the synchronized meeting object from the mobile device's calendar, creates another e-mail meeting request object, and the e-mail meeting request May transfer objects. For this reason, there are potentially considerable problems associated with generating a large number of meeting requests.
[0019]
Of course, a similar problem occurs when a significant change is made to a meeting object on either a desktop computer or a mobile device. This also creates an undesirable double email meeting request.
[0020]
Further problems arise because conventional mobile devices are much less than the memory capacity of desktop or similar computers. This creates a problem with the storage of address books on the mobile device that contain fully qualified email addresses of all potential attendees.
[0021]
An additional obstacle exists because many desktop computers that have to process meeting requests have different scheduling applications. Thus, a meeting request generated by a mobile device may not be compatible with an associated scheduling application.
[0022]
In addition, localization of meeting requests can present problems. For example, depending on locality, when writing data, it is usual to place the month first, then the day, and third the year. For other localities, it is usually a different order. In addition, the text description that describes the meeting and that accommodates the meeting request may need to be rearranged to accommodate local convenience. Meeting requests can also be generated in one time zone and forwarded to recipients in another time zone. This is confusing.
[0023]
The present invention addresses some or all of these obstacles.
[0024]
(Summary of Invention)
The present invention includes a mobile device that provides a user with the ability to schedule a meeting request from the mobile device. The mobile device creates an object representing the meeting request and assigns the object a universal identification number that uniquely identifies the object from other devices associated with the object. In addition, a mobile device according to an aspect of the present invention provides object characteristics that indicate whether a meeting request has already been forwarded. In this way, other devices associated with the meeting request can identify the request as a unique meeting request and alleviate the problem of double meeting request forwarding.
[0025]
According to another preferred feature of the invention, the email application or calendar application on the mobile computer is perfectly qualified for attendees who may be stored from a reduced address book or directly on the mobile device itself. Get your email address. This alleviates problems associated with the storage capacity of the mobile device.
[0026]
According to another preferred embodiment of the present invention, the mobile device creates a meeting object and an email meeting request object using a set of characteristics supported by a plurality of PIMs capable of receiving the object. This provides compatibility with an increased number of devices that may be associated with the object.
[0027]
According to yet another preferred feature of the invention, the localizer implements a plurality of templates on a mobile device used for formatting the characteristics of an object associated with a meeting request. Since the data stream representing the meeting request is parsed by the mobile device and placed in pre-selected fields in the appropriate template, the text viewed by the user of the mobile device is better adapted to the local convention. Furthermore, time zone information is also included in one embodiment.
[0028]
Detailed Description of Preferred Embodiments
Overview
FIG. 1 is a block diagram of an exemplary system or environment 2 in which the present invention operates. The environment 2 includes a mobile device 3 and a desktop computer 4. FIG. 1 also shows that the mobile device 3 can optionally be coupled separately to another mobile device 10 or another desktop computer 13.
[0029]
The mobile device 3 includes an application program 5 and an object storage device 6. The desktop computer 4 also includes an application program 7 and an object storage device 8. The mobile device 10 includes an application program 11 and an object storage device 12. Further, the desktop computer 13 includes an application program 14 and an object storage device 15.
[0030]
The mobile device 3 can be connected to the desktop computer 4, the mobile device 10, or the desktop computer 13 by one or more connection mechanisms 9. The operation of the desktop computers 4 and 13 and the operation of the mobile devices 3 and 10 are preferably similar. Therefore, for the sake of simplicity, this description will proceed with reference to the mobile device 3 and the desktop computer 4 only.
[0031]
In a preferred embodiment of the present invention, the application program 7 on the desktop 4 is a personal information manager (PIM) that supports an email book, scheduling and calendaring, and an address book containing contact information.
[0032]
PIM applications are not always integrated. For example, some scheduling programs do not include an email function, but may interface with anything equipped with an email program (or vice versa). Of course, PIM7 (a single application or a single integrated application or multiple interfaced applications) has a wide variety of other functions such as task lists and personalization (to name a few) It can be configured to support an address book, etc. However, for clarity, functions relating only to email messaging, scheduling and calendaring functions, and address book functions are described in detail with respect to the present invention.
[0033]
The object store 8 is a memory configured to store a plurality of separate records or objects, each containing a plurality of fields or characteristics associated with the function. In a preferred embodiment, PIM 7 is a program such as that available under the trade name Microsoft Outlook 97. The object store 8 is configured to store objects each having a plurality of characteristics that may be associated with email messaging, scheduling and calendaring, and contact information.
[0034]
For example, some characteristics included in objects related to email messaging include sender name, recipient name, text message, and whether an attachment is attached to any given email message , And possibly other similar characteristics. In addition, some characteristics related to scheduling and calendaring include critical timestamp information, date and time information, potential attendees, repetitive characteristics that describe a recurring meeting or meeting request, and meeting request text. Contains a description. Some characteristics related to contact information are exactly the exact life of the contact list, or a known name, the address and phone number of the person listed, and the person who is on the list perfectly Contains an email address. Any number of other characteristics may also be included. The desktop computer 4 executes an application identified as the PIM 7 and holds an object stored in the object storage device 8.
[0035]
The application program shown as the PIM 5 for the mobile device 3 is the same PIM as that stored in the desktop computer 4. The object store 6 on the mobile device 3 is configured to store a plurality of separate records or objects, each including a plurality of fields or characteristics associated with the supported functions described above. Like PIM7, PIM5 can also support a wide range of other functions. However, for the sake of clarity, only the functions relevant to the present invention are described in detail herein.
[0036]
In an exemplary embodiment, each object in the object store 6 includes the same set of characteristics or a subset of these characteristics stored in the object store 8 for the associated message. In addition, the object stored in the object store 6 also includes a critical change timestamp, a characteristic that indicates whether an attendee who may have been identified in the meeting request has responded, and a general identifier for each individual meeting request (Details will be described later). The mobile device 3 executes the PIM 5 and holds the object in the object storage device 6.
[0037]
In the exemplary embodiment, each object stored in the object storage device 8 is also stored in the object storage device 6. However, there are actually two instances for each object (one in object store 6 and one in object store 8). Thus, when a user makes a change to one instance of an object stored in either storage device 6 or storage device 8, the second instance of the object in the other of storage devices 6 and 8 is then mobile. Preferably, when the device 3 is connected to the desktop computer 4, any instance of the same object will contain the latest data. This is called synchronization.
[0038]
In order to achieve the synchronization, the synchronization component is executed on the mobile device 3 and the desktop computer 4. The synchronization component communicates with the PIMs 5 and 7 on the mobile device 3 and the desktop computer 4 via a well-defined interface to manage communication and synchronization.
[0039]
The components of the mobile device 3 and the desktop computer 4 communicate with each other via any suitable and commercially available communication link 9 and using a suitable communication protocol. For example, in a preferred embodiment, the mobile device 3 can be connected to the desktop computer 4 with a physical cable that communicates using a serial communication protocol. Other communication mechanisms such as infrared (IR) communication, direct modem communication, remote dial-up networking communication, communication via a commercially available network card (ie using TCP / IP), remote access service (RAS), wireless modem, Wireless cellular digital packet data (CDPD), or other suitable communication mechanism or the like is also contemplated by the present invention.
[0040]
FIG. 2 and the associated description are intended to provide a simplified and general description of a suitable desktop computer 4 on which part of the invention may be implemented. Although not required, the invention will be described at least in part in the general context of computer-executable instructions, such as program modules, being executed by a personal computer 4 or mobile device 3. Generally, program modules include routine programs, objects, components, data structures, etc. that perform particular tasks or implement particular summary data types. Furthermore, the desktop computer 4 may be implemented in other computer system configurations including multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. Examples of distributed programs include those sold under the trade names Exchange, Schedule +, and MS Mail (all available from Microsoft).
[0041]
With reference to FIG. 2, an exemplary system for implementing a desktop computer 4 includes a general purpose computing device in the form of a conventional personal computer 4 that includes a processing unit 21, a system memory 22, and a system memory. Includes a system bus 23 that couples various system components including the. The system bus 23 using any of various bus structures may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25.
[0042]
A basic input / output system (BIOS) 26 including a basic routine for assisting the transfer of information between elements in the desktop computer 4 at the time of startup or the like is stored in an EEPROM which is a part of the ROM 24. The desktop computer 4 further includes a hard disk drive 27 for reading and writing to a hard disk (not shown), a magnetic disk drive 28 for reading and writing to a removable magnetic disk 29, and a CD-ROM or other optical. It is preferable to include an optical disc drive 30 for reading from and writing to a removable optical disc 31 such as a medium. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 via a hard drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. The drive and associated computer readable media provide computer readable media, data structures, program modules, and other non-volatile storage of data for the desktop computer 4.
[0043]
Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 29, and a removable optical disk 31, other types of computer-readable media that can be accessed by a computer and that can store data, such as magnetic Those skilled in the art will appreciate that cassettes, flash memory cards, digital video discs (DVDs), Bernoulli cartridges, random access memory (RAM), read only memory (ROM), etc. may also be used in an exemplary operating environment. It will be understood.
[0044]
A number of program modules including operating system 35, one or more application programs 36 (including PIM 7), other program modules 37, and program data 38 are stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 25. You may remember. A user inputs commands and information into the desktop computer 4 via input devices such as a keyboard 40, a pointing device 42, and a microphone 62. Other input devices (not shown) include joysticks, game pads, sanitary dishes, scanners, and the like. These and other input devices are often connected to the processing unit 21 via a serial port interface 46 coupled to the system bus 23, but may be a sound card, parallel port, game port, or universal serial bus (USB). Or other interfaces. A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor 47, desktop computers typically can include other peripheral output devices such as speakers 45 and printers.
[0045]
The desktop computer 4 may operate in a networking environment using a logical connection to one or more remote computers (excluding the mobile device 3) such as the remote computer 49. The remote computer 49 may be another personal computer, server, router, network PC, peer device or other network node, and typically includes many or all of the elements described above in connection with the desktop 4, but with memory. Only the storage device 50 is shown in FIG. The logical connection shown in FIG. 2 includes a local area network (LAN) 51 and a wide area network (WAN) 52. Such networked environments are common in offices, corporate wide computer network intranets, and the Internet.
[0046]
When used in a LAN networking environment, the desktop computer 4 is connected to the local area network 51 via a network interface or adapter 53. When used in a WAN networking environment, the desktop computer 4 typically includes a modem 54 or other means for establishing communications over a wide area network 52 such as the Internet. The built-in or external modem 54 is connected to the system bus 23 via the serial port interface 46. In a network environment, the program modules illustrated with respect to the desktop computer 4 or portions thereof may be stored in a remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
[0047]
The desktop computer 4 executes an operating system 35 that is usually stored in the non-volatile memory 24 and executed on the processor 21. One suitable operating system is a Windows brand operating system sold by Microsoft, for example, WINDOWS95 or WINDOWS NT operating system, other derivative versions of the WINDOWS brand operating system, or other suitable operating system, etc. It is. Other suitable operating systems include the Macintosh OS sold by Apple, and the OS / 2 Presentation Manager sold by International Business Machines (IBM) in Armonk, New York. PIM 7 is preferably stored in program module 37, volatile memory, or non-volatile memory, or loaded from floppy disk 29, CD-ROM drive 31 to any component shown in FIG. Can be downloaded from the network via network or loaded using another suitable mechanism.
[0048]
A dynamic link library (DLL) including a plurality of executable functions is coupled to the PIM 7 for execution by the processor 21. Internal processor and internal component calls are facilitated using the Component Object Model (COM), as is common to programs written for MICROSOFT WINDOWS brand operating systems. Briefly, when using COM, software components such as DLLs have multiple interfaces. Each interface is presented to multiple methods, which are invoked individually to take advantage of different services provided by the software component. In addition, an interface can optionally receive one or more parameter arguments and invoke methods or functions from other software components.
[0049]
In general, the DLL associated with PIM7 is presented in a desktop synchronization interface that operates specifically with PIM7 and functions in accordance with the synchronization protocol as described in more detail in the above-referenced co-pending US patent application. Designed. The DLL calls an interface presented by the PIM 7 to access data representing individual object characteristics held in the object store 8. Of course, the object store 8 may reside in any one of the appropriate memory components described in connection with FIG.
[0050]
FIG. 3 is a pictorial diagram of a preferred embodiment of a mobile device 3 that can be used in accordance with the present invention. The mobile device 3 in one preferred embodiment is a desktop assistant sold under the trade name H / PC and is based on, for example, a WINDOWS CE brand operating system from Microsoft. In a preferred embodiment, the mobile device 3 is housed in a housing that fits comfortably in a typical user's hand. The mobile device 3 has several components similar to those of the desktop computer 4. For example, in a preferred embodiment, the mobile device 3 includes a small keyboard 82, a display 84, and a stylus 86. Of course, other configurations may be used, such as a configuration without a keyboard.
[0051]
In the embodiment shown in FIG. 3, the display 84 is a liquid crystal display (LCD) using a contact reaction display screen with a stylus 86. The stylus 86 is used to press or touch the display 84 at specified coordinates to achieve a specific user input function. Of course, other user input configurations may be used as well. For example, user input mechanisms may include keyboards, trackballs, and other various types of small keyboards. Further, the mobile device 3 is not embodied as a digital assistant H / PC brand, but another type of personal digital assistant (PDA), another personal organizer, a palmtop computer, or similar computerized notepad. It may be implemented as a device.
[0052]
FIG. 4 is a more detailed block diagram of the mobile device 3. Mobile device 3 preferably plugs into microprocessor 88, memory 90, input / output (I / O) components 92 (including keyboard 82 and touch screen 84), spare expansion slot 93 (PC card, compact flash memory, etc.) And a serial interface 94. In the exemplary embodiment, these components of mobile device 3 are coupled together by a suitable bus 96 for communication.
[0053]
In the exemplary embodiment, memory 90 is implemented as a non-volatile electronic memory, such as a random access memory (RAM) having a battery backup module (not shown), so that the information stored in memory 90 is stored in mobile device 30. Will not be lost even if the power to the is turned off. One portion of memory 90 is preferably allocated as addressable memory for program execution, while another portion of memory 90 is preferably used to simulate storage on a disk drive.
[0054]
The memory 90 includes an operating system 98 and applications (ie, PIM) 5. In operation, operating system 98 is preferably loaded from memory 90 to processor 88 and executed by processor 88. In a preferred embodiment, the operating system 98 is a Windows CE brand operating system. Operating system 98 is preferably designed for mobile devices and implements database functions that can be utilized by PIM 5 through a set of presented application programming interfaces and methods. Objects in object store 6 are preferably held by PIM 5 and operating system 98 in response to calls to at least partially presented application program interfaces and methods.
[0055]
The PIM 5 does not necessarily have to be designed to be completely compatible with the PIM 7 executed on the desktop computer 4. For example, there may not be a strict one-to-one match between characteristics of a particular object type. Some characteristics supported by the email messaging function of PIM 5 may not have a corresponding function in PIM 7 on desktop computer 4 and vice versa.
[0056]
Object synchronization
To assist in understanding the present invention, object synchronization is briefly described here.
[0057]
FIG. 5 illustrates the preferred structural components of the mobile device 3 and the desktop computer 4 that are used to synchronize objects stored in the object store 6 on the mobile device 3 and the object store 8 on the desktop computer 4. It is a block structure diagram showing an embodiment. Note that the synchronization architecture shown in FIG. 5 is only one preferred embodiment, and other architectures may be used as well. Furthermore, a synchronization operation can be performed between any two connected storage devices (computers 4 and 13, any connected peers of mobile devices 3 and 10). All that is required is a sync manager component, described below, that supports the synchronization of two linked storage devices. The synchronization manager may reside on either device, both devices, or a third computer coupled to the two storage devices. However, for simplicity, only embodiments in which the desktop computer 4 is coupled to the mobile device 3 will be described herein. Also, this synchronization protocol is only one preferred embodiment, and another suitable protocol may be implemented over a standard email protocol.
[0058]
In addition to the PIM 5 and the object storage device 6, the mobile device 3 includes a synchronization module 97, which includes an interface component 100 and a synchronization manager 102. Mobile device 3 also includes a communication component 94, a remote application programming interface (RAPI) server 116, and email messaging transports 132, 134, and 136.
[0059]
In addition to the PIM 7 and the object storage device 8, the desktop computer 4 includes an interface component 108, a synchronization manager 110, a reference storage device 112, and a RAPI component 114. The desktop computer 4 also includes a communication component 115.
[0060]
In general, in the embodiment shown in FIG. 5, the synchronization manager 110 is executed on the desktop computer 4 to synchronize the objects in the object storage device 6 in the handheld device 3 and the objects in the object storage device 8 in the desktop computer 4. command. The synchronization manager 110 also keeps the reference storage device 112 away from the desktop object storage device 8, as will be described in detail below. The synchronization manager 110 implements a synchronization protocol to compare the object stored in the object storage device 6 in the mobile device 3 with the corresponding object in the object storage device 8 in the desktop computer 4 and from the object storage device 8. The object is received, and the object in the object storage device 8 can be updated. The synchronization protocol also facilitates retrieval of objects stored in the object storage device 6 in the mobile device 3 via the synchronization interface component 100 and the synchronization manager 102 and the communication component 94.
[0061]
On the mobile device 3 side, the synchronization interface component 100 is presented in the application programming interface, which is called by the synchronization manager 102 to read and store objects and object characteristics on the object store 6. In general, the application programming interface allows database creation of different types of objects and allows application programs to write and read property names and values for objects in the object storage device 6.
[0062]
Referring to FIG. 1, the PIM 5 is executed on the mobile device 3 and holds the object storage device 6. The PIM 7 is executed on the desktop computer 4 and holds the object storage device 8. There are many ways in which the PIMs 5 and 7 can store objects in the object stores 6 and 8. However, in the preferred embodiment, PIMs 5 and 7 create a separate database for each object type. For example, different databases are created for meetings, contacts, tasks, email messages, etc. Predefined characteristics are supported for each object type, and each database is assigned a name by the application program that created it.
[0063]
In an alternative embodiment, the application programs on PIMs 5 and 7 may use one database for all object types, with the first characteristic of each object defining the type of object. In any case, the object is uniquely identified in the mobile device 3 and the desktop computer 4 by the object identifier regardless of the name assigned to the application program that creates the object.
[0064]
The synchronization manager 110 does not necessarily have to be connected near the PIM 7. Rather, the synchronization manager 110 is a separate component that synchronizes objects from any application program that supports a suitable desktop synchronization interface. Specific synchronization interfaces are described in further detail in the co-pending US patent application incorporated above. Communication components 94 and 115 perform serial communication between computers using a suitable link 9.
[0065]
The synchronization manager 110 communicates with the PIM 7 and accesses the object storage device 8 via the synchronization interface component 108. The synchronization interface component 108 generally corresponds to the DLL described above in connection with FIG. 2 (above) and is presented in one or more application program interfaces and methods.
[0066]
Interfaces and methods are described in further detail in a co-pending patent application incorporated by reference. Preferred among these interfaces is a form known as the Messaging Application Program Interface (MAPI) developed and published by Microsoft for Windows brand operating systems, although other suitable interfaces may be used as well. . In a preferred embodiment, the MAPI presented by component 108 is a C language application programming interface that allows programmable access to the functionality of an email messaging program known as MS Mail, commercially available from Microsoft Corporation. . In another preferred embodiment, the MAPI presented by the component 108 is sometimes referred to as an extended MAPI and includes a set of automatic interfaces to a messaging system for use in Visual Basic or the like, a component object model base (COM base) Is a set of interfaces. However, the synchronization interface component 108 and associated application program interfaces and methods can be any suitable synchronization interface component designed for any particular application in PIM7. The application program interface is preferably standardized and the sync manager 110 can access and synchronize any number of different desktop PIMs as long as the required interface methods are implemented for each PIM.
[0067]
The reference storage device 112 maps between an object stored in the object storage device 6 on the mobile device 3 and an instance of the object stored in the object storage device 8 on the desktop computer 4. This mapping is necessary because the object identifier that PIM 5 uses to identify the object in object store 6 is not the same as the object identifier that PIM 7 uses to identify the object in object store 8. Become.
[0068]
The synchronization manager 110 references and stores identification data segments respectively corresponding to a plurality of object instances in the object storage device 8 on the desktop computer 4 that are synchronized with instances of the same object in the object storage device 6 on the mobile device 3. Hold the device 112 for inclusion. The identification data segment is updated each time the corresponding object instance is synchronized.
[0069]
The exact configuration of the identification data segment used to identify a particular object instance can be assigned by the developer of the desktop synchronization interface component 108 and is processed and stored by the synchronization manager 110. The identification data segment preferably includes some type of time stamp information since the identification data was last recorded in the reference storage device 112, and this is compared to determine whether the object has changed.
[0070]
In addition to holding a plurality of identification data segments, the synchronization manager 110 also maintains a list of object identifiers corresponding to objects held in the object storage device 6. These identifiers are provided to the sync manager 110 each time a new object is added to the object store 6 on the mobile device 3.
[0071]
Synchronization protocol
The exact protocol for achieving full synchronization achieved according to one embodiment of the system is briefly described below. A brief description of the protocol will assist in understanding the present invention. In order to synchronize objects, the sync manager 110 first creates two lists of handles that reference a particular object. The term “handle” refers to a number or other identifiers that can be used to uniquely identify and access an object. In general, a handle is valid for a particular time interval or session, such as during the time that an object is “open”. If the same object is reopened, its handle will be different.
[0072]
A first list of handles is obtained from the reference store 112 and shows objects that have been synchronized in the past and identified in the reference store 112. The second list of handles is a list for identifying objects stored in the object storage device 8. The two lists of handles are compared with each other to determine whether the same object is stored in the reference storage device 112 and the object storage device 8.
[0073]
If an object is identified in the reference storage device 112 but not in the object storage device 8, that particular object has been deleted from the desktop 4 since it was last synchronized. On the other hand, if an object is identified in the object storage device 8 but is not found in the reference storage device 112, the object has been added to the desktop since it was last synchronized. In either case, the sync manager 110 determines how to process the object. In a preferred embodiment, objects deleted from the desktop object store 8 are also deleted from the reference store 112. Further, the object added to the object storage device 8 is also added to the reference storage device 112.
[0074]
Next, the synchronization manager 110 determines whether any object stored in the object storage device 8 has been changed on the desktop since the synchronization was last performed. In other words, handles corresponding to the same object are found in both the object store 8 and the reference store 112, but they are not identical (time stamp, revision number, or another suitable identification segment is not the same). If this is the case, this indicates that the object in the object store 8 has changed since the last synchronization.
[0075]
Next, the synchronization manager 110 determines whether any object stored in the object storage device 6 on the mobile device 3 has been added or changed since the last synchronization. To determine whether an object has been added to the object store 6, the sync manager 110 stores the object list in the reference store 112 (reflecting all objects since the last sync) in the sync manager 102. Is compared with the object list of the object storage device 6 held by the. To determine whether an existing object has been modified, the synchronization manager 102 is configured to maintain a status bit associated with each object stored in the object store 6. The status bit reflects whether the particular object associated with the bit has changed since the last synchronization. If so, the sync manager 102, if the device 3 is coupled to the desktop computer 4, notifies the sync manager 110 of the change or simply logs a status bit so that the device 3 Is sent to the synchronization manager 110 when it is next linked.
[0076]
In any of these procedures, the synchronization manager 110 or the synchronization manager 102 need not be aware of the particular nature or format of the identification data segment or the corresponding object. Rather, interface components 100 and 108 are invoked for all actions that depend on the actual content of the identification data segment and the content of the object. It is up to the designer of these interfaces to define the format of the identification data segment that allows the interface to perform the required functions.
[0077]
Once changes, additions and deletions are determined by the synchronization manager 110, the items are synchronized. To do this, the sync manager 110 forms a list of changed objects on the object store 8 or object store 6 and requests each sync interface component to update the old object. If the same object is modified on both the mobile device 3 and the desktop computer 4, a conflict occurs. The sync manager 110 resolves the conflict by either prompting the user or referring to profile information entered by the user during setup. The property information determines which device and which instance performs the procedure. The process of setting up profile information is described in detail in the above patent application.
[0078]
If an object is created on either the desktop computer 4 or the mobile device 3, the object needs to be exchanged with the other device. When the mobile device 3 needs to get a new object from the desktop computer 4, the synchronization manager 110 calls an interface method known as "Set-Up". With this interface method, an object is obtained from the object storage device 8 of the desktop computer 4 and the handle transmitted to the object storage device 6 of the mobile device 3 is specified. Once the handle is obtained, a method known as “GetPacket” is called repeatedly to retrieve the data stream representing the object and formatted by the interface component 108. The sync manager 110 only treats the data as a data stream that is retrieved and sent via the link 9 to the sync manager 102 and ultimately to the object store 6. The appropriate synchronization interface component 100 parses the data stream to identify a particular property value associated with the property corresponding to the object. These characteristics are then stored in the object storage device 6.
[0079]
Finally, the synchronization manager 110 updates the identification data segment associated with either the synchronized or exchanged object and stores the updated data segment in the reference storage device 112.
[0080]
It is worth noting that the architecture described here provides for synchronization of objects related to email message meetings or appointments, or contact information, along with other objects held in PIM5, PIM7. Thus, using the synchronization protocol, the objects associated with these functions are synchronized during the synchronization process. The sync manager 110 detects any new objects in the object store 8 that represent new email messages, meetings or appointments or contact information, and those objects are mobile to alert the user of the mobile device 3. It is transferred to the object storage device 6 on the device 3.
[0081]
In addition, if the user writes an email message or schedules a meeting (and hence creates a meeting object and an email meeting request object), or uses the appropriate application in PIM 5 to obtain contact information on the mobile device 3 If entered, the objects related to these items are stored in the object storage device 6 as new objects. During synchronization, these new objects are transferred to the desktop computer 4 and the object store 8.
[0082]
Meeting request
FIG. 6 is a block diagram illustrating one preferred embodiment of a mechanism for generating a meeting request. As shown in FIG. 5, the mobile device 3 and the desktop computer 4 are connected to each other. However, FIG. 6 also shows that the mobile device 3 and the desktop computer 4 may be another mobile device, another desktop computer, a LAN 51 (shown in FIG. 2), a WAN 52 (shown in FIG. 2), or any other suitable network. It is also possible to connect to a wide area network 138 including
[0083]
Items similar to those in FIG. 5 are given similar numbers. However, PIMs 5 and 7 are shown in greater detail in FIG. FIG. 6 illustrates that in one preferred embodiment, the PIM 5 includes an email application 140, a calendar and scheduling application 142 and a shortened address book 144. Similarly, each application may have a designated application programming interface (API), but only a single API component 146 is shown in FIG. 6 for simplicity.
[0084]
FIG. 6 further shows that the object store 6 interfaces with applications 140, 142 and 144, preferably via its own set of application programming interfaces 148. Thus, the applications 140, 142, and 144 secure the object store 6 with the invocation method presented by the application programming interface 148 associated with the object store 6. In addition, the communication component 94 and the synchronization component 99 communicate with the application programs 140, 142, and 144 through call methods presented in the application programming interface 146.
[0085]
The PIM 7 of the desktop computer 4 is also shown in a more detailed block diagram. In one preferred embodiment, the PIM 7 includes an email application program 150, a scheduling and calendaring program 152 and a full address book program 154. Although application programs 150, 152, and 154 each have an associated set of application programming interfaces, only a single application programming interface component 156 is shown in FIG. 6 for simplicity.
[0086]
FIG. 6 further illustrates that in one preferred embodiment, the object store 8 is associated with its own set of application programming interfaces 158 (API 156, preferably the same as or separate from MAPI). Thus, the method of calling application programs 150, 152 and 154 presented by application programming interface 158 maintains and interacts with object storage device 8. In addition, the communication component 115 calls methods presented by the application programming interface 156 to interact with the application programs 150, 152 and 154.
[0087]
FIG. 6 shows that the desktop computer 4 preferably includes an email transport 160. The email transport 160 is preferably a commercially available email transport, such as an SMTP transport. However, it should be noted that the desktop computer 4 includes any suitable transport or combination of transports.
[0088]
FIG. 7 is a flowchart illustrating a procedure for generating a meeting request on the mobile device 3. Hereinafter, a description will be given with reference to FIGS.
[0089]
To generate a meeting request from the mobile device 3, the user first enters meeting request information via an appropriate user interface. In one preferred embodiment, the user opens the scheduling application program 142 so that the appropriate user interface is displayed on the screen 84. Using stylus 86 and possibly keypad 82 (or any other suitable input mechanism), the user enters the appropriate information to request the meeting. Such information is typically entered in the date and time of the meeting (which may be entered using a fully qualified email address or by entering a well-known name, or a non-empty email address area). This includes the requested attendees (which may be selected from the registration information in your contact database), the subject of the meeting, whether the meeting is recurring or single, preferably the location of the meeting. The scheduling application 142 generates an object that represents the meeting request.
[0090]
This information is used to create a meeting object and associate that object with a calendar on the mobile device 3 to enter the storage device. As a result of the generation of the meeting object, an e-mail meeting request object is also generated. It should also be noted that an updated email meeting request is also generated and sent with subsequent significant modifications to the meeting object.
[0091]
In the preferred embodiment, the selection has already been made to specify the transport through which the email meeting request object is sent. Alternatively, the transport used can be implied by the complete email address itself. For example, it can be specified that any of the transports 132-136 is used when the mobile device 3 attempts to send the meeting request itself. In addition, selections that specify particular options used in the synchronization protocol already described are also preferably already used. For example, if the inbox synchronization option is enabled, the email meeting request object is synchronized with the outbox of the desktop computer 4. Similarly, the meeting object is synchronized with the calendar of desktop computer 4 if the calendar synchronization option is enabled. The desktop computer 4 then sends an email meeting request object, preferably synchronized with the outbox.
[0092]
Receiving meeting request information from the user and creating a meeting object and an email meeting object representing the meeting are indicated by blocks 162 and 164 in FIG.
[0093]
Next, a critical timestamp is added to the object (indicated by block 165), and scheduling application 142 assigns a global object identification tag to the generated meeting object. The global object identification tag is a tag, such as a number, that uniquely identifies an object that represents a meeting request to the mobile device 3, the desktop computer 4, and all other devices that may encounter the object. The global identification tag is carried with the email meeting request object when sent and remains with the object on the other device. This is indicated by block 166.
[0094]
Because the email meeting request object must be sent to another device, the scheduling application 142 operates the email program 140 to fully restrict all emails of attendees who may receive the meeting request. A method of API 146 for retrieving an address is called. In one preferred embodiment, scheduling application 142 obtains a fully qualified email address from the address book. In another embodiment, the mobile device 3 includes a shortened address book program 144. In the preferred embodiment, the shortened address book program 144 is implemented as a contact function provided by Microsoft Outlook 97. The shortened address book includes the names, addresses, phone numbers, and fully qualified email addresses of people that the user has chosen to add to the shortened address book. These people are probably those who may receive a large number of email messages from the user of the mobile device 3. Therefore, the information probably includes the fully qualified email address of attendees who may be meeting requests. In addition, if the address is not fully met, the sync component 97 on the desktop 4 will attempt to determine the name on the desktop prior to sending the email.
[0095]
Thus, either the email application 140 or the scheduling application 142 retrieves frequently heard names entered by users as potential attendees, with email addresses fully confined to the shortened address book program 144. In order to do this, the API 146 method is called. This reduces memory overhead that would otherwise be required if, for example, the user was requested to download the complete address book from the desktop computer 4 to send an email message or meeting request. . This is indicated by block 168. In another preferred embodiment, the function associated with block 168 is performed at block 162 as soon as the user enters the appropriate information.
[0096]
Similarly, a transport option indicating the specific transport over which the email message is sent has already been preferably selected. These transports can be any of the transports 132-136 on the mobile device 3 or can be synchronized with the desktop computer 4 using one of those transports. Based on the selected option, the email meeting request object is sent via the appropriate transport and, when sent, is removed from the outbox of the mobile device 3.
[0097]
If the email meeting request object is sent directly from one of the transports on the mobile device 3, the appropriate transport formats the meeting request to send. In the preferred embodiment, the characteristics that the scheduling application program 142 contributes to the email meeting request object that represents the meeting request are compatible with many other PIMs. Therefore, these properties are a subset or superset of all properties recognized by multiple PIMs, so that objects can be accepted and handled appropriately by those PIMs. Appendix A attached at the end of this specification is a message property list, by which the objects associated with the meeting request are defined by the MICROSOFT SCHEDULE + brand scheduling program. These properties notably include a modified repeat notification property that is backward compatible with other versions of MICROSOFT SCHEDULE + scheduling software. For example, in the embodiment described in Appendix A, the recurring notification used to confirm a recurring meeting is formatted as a superset of single instance notifications. In this way, previous versions of MICROSOFT SCHEDULE + scheduling software provide well-formed meeting notifications even for regular meetings.
[0098]
In the preferred embodiment, the scheduling program 142 then invokes a method presented by the API 146 associated with the email application program 140. The email message containing the email meeting request object is formulated into one of a predetermined number of classes by the email application 140. A potential attendee's receive scheduler program distinguishes between types of meeting notifications based on the mail message class. For example, in one preferred embodiment, a mail message such as a meeting cancellation notice from the organizer, a meeting request from the organizer, a meeting acceptance from the attendee, a meeting decline from the attendee, a meeting provisional acceptance from the attendee, etc. There is a classification. Thus, this is preferably included with the object when the transport formats the email meeting request object for transmission. The meeting request is sent to the nominated transport 132, 134 or 136 via the communication component 94, which formats the message and sends it to the network 138.
[0099]
The format and transmission of the email meeting request object from the transport on the mobile device 3 is shown in blocks 172 and 174 of FIG.
[0100]
After the email meeting request object is sent, it is removed from the outbox of the mobile device 3 to indicate that the message has been sent. This is indicated by block 190. When next connected to the desktop computer 4, the meeting object is synchronized to the storage device containing the calendar on the desktop computer 4. Preferably, since the meeting object is only synchronized to the calendar on the desktop, the PIM also provides a function that can be used to prevent the PIM from simply generating and sending an email meeting request object. Its function may simply be to create an email meeting request object for the meeting request generated on the desktop. This feature is further implemented to address the problem of sending duplicate messages.
[0101]
If the transport option is selected to send an email meeting request object using the synchronization protocol on the desktop computer 4 and the mail transport, the email meeting request object is synchronized to the outbox of the desktop computer 4 The process is substantially the same except that it is allowed (shown in block 173). The mobile device 3 simply waits until it is connected to the desktop computer 4 before any processing is taken regarding the meeting request. When the mobile device 3 is connected to the desktop computer 4, the synchronization protocol already described is executed. During the synchronization process, the meeting object is synchronized to the calendar on the desktop computer 4 and then the email meeting request object is synchronized to the outbox of the desktop computer 4 via the synchronization components 97 and 99. Upon receiving an e-mail meeting request object that displays the meeting request, e-mail application program 150 recognizes that the meeting request needs to be sent. The email application program 150 calls the necessary methods presented by the API to ensure that the appropriate objects are sent to the network 138 via the communication component 115 and transport 160. This is again indicated by blocks 172, 173, 174 and 190.
[0102]
It is also worth noting that in a preferred alternative embodiment, the meeting request does not have to be completely formatted on the mobile device 3. Instead, the data representing the email meeting request object can only be stored and transferred during synchronization to the desktop computer 4 where it is fully formatted. For example, in one preferred embodiment, the mobile device 3 does not store a specific transport used by the desktop computer 4 when sending a meeting request. Since this information is not stored by the mobile device 3, it is not synchronized with the desktop computer 4. Instead, the email application program 150 on the desktop computer 4 (before sending the meeting request) retrieves the transport identified by the user associated with each of the attendees for which the full address book 154 is likely. In order to do so, a necessary method is called through the API 156. That information is then used by the email application program 150 in selecting the appropriate transport 160 to send the email meeting request object. In this way, additional storage capacity for storing such transport information does not have to be consumed on the mobile device 3. This is indicated by block 188.
[0103]
In any case, when an email meeting request object is sent by the email application program 150 to the network 138, the email meeting request object is removed from the outbox. This is indicated by block 190.
[0104]
After the email meeting request object is sent, it is determined whether any other meeting request has been synchronized to the desktop computer 4 during the latest synchronization process. If not, normal processing continues. If so, processing returns to block 172 where the email application program 150 calls the API required to send the object. This is indicated by block 192.
[0105]
FIG. 8 is a procedural flow diagram illustrating a preferred embodiment of how mobile device 3 processes a response to a meeting request sent according to FIG. In a preferred embodiment, the recipient of the response to the meeting request is the meeting organizer. Both the originator and recipient of the meeting request are properly negotiated for delegation processing. Publicly available MAPI specifications fully disclose how such properties should be interpreted.
[0106]
Thus, the meeting request recipient is provided with an appropriate user interface to indicate the response. The response is addressed to the meeting organizer or another appropriate representative. The response is then forwarded by the device operated by the recipient and received by any one of the transports 132, 134, or 136, or via the communication component 94 of the mobile device 3. This is indicated by block 194 in FIG.
[0107]
Upon receipt of the response, scheduling application program 142 associates the response with the meeting object created by scheduling application program 142 when the user generates a request stored in object store 6. This association is performed by using a global identification number that uniquely identifies a meeting request to all devices that may encounter it. This is indicated by block 196.
[0108]
The critical timestamp information is then checked to determine if the response corresponds to the most recent meeting object. Preferably, the response actually contains two timestamps. The first stamp is the opinion of the recipient of the organizer's critical time stamp. The second stamp is a time stamp assigned by the recipient. The first stamp is checked to determine if it is the same as the organizer's timestamp. If so, the response is considered in date. If not, the response is rejected or ignored as an expired response. The second stamp must be equal to or greater than any of the previously recorded time stamps from this particular recipient in order for the response to be in time. Otherwise, the response is rejected or ignored as expired. This is indicated by block 197.
[0109]
Note that in the preferred embodiment, the time stamp is always advanced. Thus, even if the user resets the clock to a sufficient time, the next time stamp is always after the current clock time and the latest time stamp plus one second.
[0110]
The scheduling application program 142 then calls the necessary methods presented by the API 148 to update the attendee status associated with the request. This is updated based on the specific response received from the attendee. This is indicated by block 198.
[0111]
Thereafter, the mobile device 3 simply waits to be connected to the desktop computer 4. Once connected, the updated object (including updated attendee status characteristics) is synchronized to the instance where the object is stored in the object store 8. This is done using the synchronization protocol discussed above. This is indicated by blocks 200 and 202. The meeting object is then available to the scheduling application program 152 and the desktop computer 4 and can be displayed on the user's calendar at the desktop computer 4 for user observation and interaction.
[0112]
FIG. 9 is a procedural flow diagram of a preferred embodiment of how a response is processed when it is received via transport 160 on the desktop computer 4. Initially, the user enters information through an appropriate user interface that defines the user's response to the meeting request. The response is then sent back to desktop computer 4 via transport 160 and communication component 115. This is indicated by block 204.
[0113]
The scheduling application program 152 associates the response with the meeting object using the global identification number assigned to the meeting object and received along with the response to the meeting request, as the mobile device 3 did. This is indicated by block 206. Thereafter, as described above, the time stamp information is checked to determine if the response corresponds to the most recent meeting object. If not, the response is rejected or ignored as an expired response. This is indicated by block 207. Thereafter, the scheduling application program 152 calls the necessary information presented by the API 158 to modify and update the attendance status of the meeting object stored in the object storage device 8. This is indicated by block 208. Thereafter, the desktop computer 4 just waits until it is next connected to the mobile device 3.
[0114]
At that point, the updated object in the object store 8 (which has been updated to accurately reflect the new attendee status based on the response) is the other object that is then stored in the object store 6. Be synchronized to the instance. Synchronization is realized by the synchronization protocol described above. The updated object is then made available for review and processing by the user of the mobile device 3. This is indicated by blocks 210 and 212.
[0115]
The mobile device of the illustrated embodiment according to the invention handles exceptions for recurring meetings and meeting cancellations. In one embodiment, upon receipt of recurring pattern update information for a periodic meeting, the scheduling PIM also erases all exceptions. Thus, when a periodic meeting pattern change is sent, a new email object must be created and sent for each exception. For example, assume that a user enters a periodic meeting request on the mobile device 3. The scheduling application 142 creates a recurring meeting object and registers it in the user's calendar. The email application 140 also generates an email periodic meeting request to send to potential attendees. The recipient (possible attendee) can generally respond as described above.
[0116]
For the purposes of this example, assume that the regular meeting takes place from 1 April every Tuesday from 10:00:00 to 11:00 am. However, the user (host) needs to cancel the April 8 meeting. The user launches the scheduling application 142 and deletes the desired instance. The email application 140 then generates another object (an exception to the repeat pattern) for transmission indicating this deletion. The organizer then needs to change the April 15 meeting from 11:00 to 12:00 noon. A similar process is also performed to generate the exception. The organizer then changes the location of the regular meeting and applies the change to all repeating patterns. This requires sending three new emails.
[0117]
The first email is generated simply to indicate a new location for repeated pattern correction. In some PIMs, the previous two exceptions may be deleted. Thus, two new emails are generated to re-establish two exceptions (ie, the April 8 meeting cancellation and the April 15 meeting time change). These emails are automatically generated by the email application 140. These same actions may be taken in response to other suitable changes such as amendment of the attendee list.
[0118]
Localization
As described above, in the preferred embodiment, a meeting object is typically accompanied by a text phrase that describes the nature of the meeting request. The text phrase is generated based on the characteristic values entered by the user during the generation of the meeting request. For example, a user may request potential attendees to attend a 10:00 am meeting on the third Monday of each month between January 1, 2000 and March 20, 2001. In that case, a typical text message looks like this, which is retrieved and attached within the meeting request object for display to potential attendees.
“This meeting shall take place on the third Monday of each month at 10:00 am on the third Monday of every month from January 1, 2000 to March 20, 2001. 10:00 am beginning January 1, 2000, and ending March 20, 2001.)
[0119]
However, in different regions, it may be agreed that the date is placed before the month when marking the date. Furthermore, the order of the words or phrases in the text message and the components of the text message must be rearranged to follow the local convention.
[0120]
In a preferred embodiment, a predetermined text message of the type described above is generated to describe each different type of recurring meeting that a user of the mobile device 3 can request.
[0121]
According to one aspect of the present invention, a text message used to request a regular meeting is broken down into a plurality of phrases. Each generated phrase is broken down into multiple fields. The specific phrases that can be generated to define the meeting request and the specific field from which the phrases are separated can be any suitable phrase or field.
[0122]
With respect to the phrases described above, FIG. 11A illustrates one embodiment of a field in which phrases can be resolved. FIG. 11A shows that the first part of the phrase “This meeting is to be held on the third Monday of every month” is placed in the field 214. The term “at” is placed in field 216. The time designation “10:00” is placed in field 218 and the AM / PM designator is placed in field 220. The term “beginning” is placed in field 222 and the remaining messages are similarly broken down into fields 224, 226, 228, 230, 234, 236, 238, 240 and 242.
[0123]
FIG. 10 is a procedural flow diagram showing how the localization process works. Generation of text phrases defining meeting requests and decomposition of those requests into various predetermined fields is indicated by block 242. Next, during manufacture of the mobile device 3, the localizer program is executed for each message generated on the mobile device 3 so that the messages each follow the local convention, and the fields 214-240 are relocated. Of course, the specific localizer program executed on the mobile device 3 depends on the specific locality and consumer base for which the mobile device 3 is intended. When executing the localizer program, the mobile device 3 includes multiple sets of fields called templates for arranging message data to display text messages in a manner that is local. Executing the localizer program in setting up the template is indicated by block 244.
[0124]
After the mobile device 3 owns the template that was in the region, the mobile device 3 receives the meeting request and is ready to correctly display the text description of the meeting request. Upon receiving the meeting request, a data stream representing a text phrase describing the meeting is also received by the scheduling application program 142. This is indicated by block 246. The scheduling application program 142 parses the incoming data stream into values associated with various fields in the appropriate template (the appropriate template corresponds to the particular text description being received). This is indicated by block 248.
[0125]
The parsed data is then placed in a preselected field in the template based on the generated phrase. This is indicated by block 250. Since the localizer program has already been run, the fields in the template are already arranged in the proper order to follow the local convention.
[0126]
FIG. 11B shows the rearrangement according to the different arrangement of fields in the template shown in FIG. 11A. FIG. 11B shows the case where the phrase follows a convention where the phrasing is slightly different from that shown in FIG. 11A and the day in the date is conventionally placed before the month. The phrase here includes the same terms, but becomes:
“This meeting will be held at 10:00 am on the third Monday of every month from January 1 / January 2000 to March 20th 2001 (Beginning 1 January, 2000 and ending 20 March, 2001 this meeting shall take place on the third Monday of each month at 10:00 AM)
[0127]
All appropriate phrases are of course localized as well.
[0128]
Also, in the illustrated embodiment, time zone information is processed in an advantageous manner. For example, when a recurring meeting request is generated and sent to a device located at a different time zone, the text phrase indicating the recurring meeting includes an indication of the time zone when the recurring meeting request was generated. For example, for a meeting to be held every Tuesday from March 3rd at 8:00 am, a user in Paris (France) sends a regular meeting request to a recipient in Seattle (with a 9 hour time difference) So the text phrase is:
“This meeting will be held every March from 8:00 am on March 3rd; (GMT + 1) Madrid, Paris. (This meeting occurs every Tuesday at 8:00 am beginning March 3; (GMT + 1) Paris, Madrid.) "
[0129]
This allows the recipient to see the repeating pattern originally constructed by the sender.
[0130]
On the other hand, if the meeting is not recurring, the time is preferably simply displayed as appropriate for the recipient (eg, “This meeting is scheduled for Tuesday at 11:00 pm”).
[0131]
Conclusion
Thus, it can be seen that the present invention provides significant advantages over conventional systems. First, according to the present invention, a meeting request can be generated from the mobile device itself. The present invention further identifies objects associated with such meeting requests so as to uniquely identify objects to all other devices likely to be associated. The present invention also utilizes a PIM function that indicates whether a meeting request has been sent to a potential attendee. These functions eliminate duplicate message transmission.
[0132]
The present invention also preferably implements a function that reduces the memory required to perform a meeting request function using a shortened address book. In addition, the present invention uses a set of scheduling characteristics that are compatible with multiple different PIMs that are likely to encounter meeting requests. In addition, the present invention preferably utilizes a localization procedure that localizes meeting requests according to more local arrangements in an advantageous manner and to process time zone information. The present invention preferably supports the use of multiple email transfers, not to mention a synchronization protocol.
[0133]
Although the present invention has been described with reference to preferred embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit of the invention and the scope of the claims.
[Table 1]

[Brief description of the drawings]
FIG. 1 is a block diagram showing a basic environment of the present invention.
FIG. 2 is a block diagram of one embodiment of a conventional desktop computer for use with a mobile device according to the present invention.
FIG. 3 is a simplified pictorial diagram illustrating one embodiment of a mobile device according to the present invention.
FIG. 4 is a simplified block diagram of one embodiment of the mobile device shown in FIG.
FIG. 5 is a block structural diagram illustrating an embodiment of a portion of the desktop computer shown in FIG. 2 and the mobile device shown in FIGS. 3 and 4, with object storage on the desktop computer and on the mobile device according to the present invention. The synchronization information memorize | stored in the apparatus is shown.
6 is a block structural diagram illustrating an embodiment of a portion of the desktop computer illustrated in FIG. 2 and the mobile device illustrated in FIGS. 3 and 4, illustrating the generation and transfer of a meeting request.
FIG. 7 is a flow diagram illustrating generation of a meeting request according to a preferred embodiment of the present invention.
FIG. 8 is a flow diagram illustrating response processing for a meeting request on the mobile device shown in FIGS. 3 and 4 according to a preferred embodiment of the present invention.
FIG. 9 is a flowchart illustrating a response process to a meeting request on the desktop computer shown in FIG. 2 according to a preferred embodiment of the present invention.
FIG. 10 is a flow diagram illustrating the use of a localizer to localize a text description of a meeting request according to a preferred embodiment of the present invention.
11A and 11B show one embodiment of a template used to localize a text description of a meeting request according to the present invention.

Claims (18)

And Symbol憶equipment store the objects and the application program,
A user input mechanism for receiving user input information;
A synchronization component for synchronizing an object stored in the storage device with an object stored in a remote storage device of a remote device;
A mobile device comprising a communication component configured to communicate with a remote device,
The application program is
A meeting object is generated based on the user input information and stored in the storage device;
Generating an email meeting request object based on the meeting object and storing it in an outbox in the storage device;
If the email meeting request object is sent to a remote device of a prospective meeting attendee, the email meeting request object is deleted from the storage outbox;
If the email meeting request object has not been sent, hold the email meeting request object in the outbox of the storage device;
When synchronizing with the remote device, the remote device is configured to transfer the e-mail meeting request object stored in the outbox of the storage device to a remote device of a meeting attendee. Mobile device. The application program, the mobile device according to claim 1, characterized in that it is configured to generate a meeting object having a general identifier that uniquely identifies the meeting object among the plurality of other objects. The application program is
A first application program configured to generate the meeting object based on the user input information;
A second application program configured to generate the email meeting request object based on the meeting object ;
The mobile device according to claim 2, comprising: The application program further includes
Includes a contact application program that is configured to hold before crisis憶device object representing the contact information comprising information enabling the identification of individuals, including electronic mail address,
The mobile device according to claim 1, wherein the application program is configured to obtain an email address of a meeting attendee identified by the contact information through interaction with the contact application program. The application program is configured to generate the meeting object and the email meeting request object so that they can be synchronized with the meeting object and the email meeting request object stored in the remote storage device via the synchronization component. The mobile device according to claim 1. The application program receives a data stream representing text phrases describing the meeting object, is configured to place the corresponding fields of the parsing the data stream template preselected data of each section, the The mobile device of claim 1, wherein a preselected template is associated with the received text phrase.   The mobile device according to claim 6, wherein the pre-selected template is created by being arranged in the field in an order based on a specific regionality. A method for setting up a meeting using a mobile device with a storage device, comprising:
Receiving user input information;
Generating a meeting object based on the user input information and storing it in the storage device;
Generating an email meeting request object based on the meeting object and storing it in an outbox provided in the storage device;
Synchronizing an object stored in the storage device with an object stored in a remote storage device of a remote device;
Deleting the email meeting request object from the outbox when the mobile device sends the email meeting request object to a remote device of a prospective meeting attendee;
Holding the email meeting request object in the outbox if the mobile device has not sent the email meeting request object;
Causing the remote device to forward the e-mail meeting request object held in the outbox to a remote device of a meeting attendee when synchronizing with the remote device . Connecting the mobile device to the remote device ;
A step of an object before Symbol in storage to synchronize with the object of the remote Symbol憶the apparatus,
Forwarding said email meeting request object from the e-mail transport on the remote device,
9. The method of claim 8, further comprising: The mobile device has at least one email transport ;
The method of claim 8 further comprising the step of transferring the e-mail meeting request object from the e-mail transport on the mobile device. The method of claim 10, wherein forwarding from an email transport includes selecting an email transport when the mobile device has multiple email transports. The steps to create a meeting object are:
The meeting object, comprising the step of assigning a time stamp indication indicating a time at which the meeting object is created,
The method of claim 11, characterized in that it comprises the step of assigning the time stamp displayed on the e-mail meeting request object that generates an e-mail meeting request object. Receiving a response object including the generic identifier and the timestamp indication from a destination of the email meeting request object ;
On the basis of the generic identifier and the time stamp display, associating the response object to the meeting objects on the mobile device,
On the basis of the received response object, the method according to claim 12, further comprising a <br/> and updating the response state associated with the meeting object. The method of claim 13, further comprising a said response state step of synchronizing with the remote object store. A first computing device comprising:
First storage device for storing the objects and the first application program,
A user input mechanism;
A first e-mail transport;
The first application program is:
Receiving user input information from the user input mechanism, generating a first object based on the user input information, and storing the first object in the first storage device ;
Generating a first email object based on the first object and storing it in an outbox in the first storage device;
If the first email object is sent to a predetermined computing device, the first email object is deleted from the outbox of the first storage device;
A first computing device configured to retain the first email object in an outbox of the first storage device when not transmitting the first email object ;
A synchronization manager configured to synchronize objects in the first storage device with objects in the second storage device;
A second computing device comprising:
A second storage device that stores objects, and the second application program,
A second e-mail transport;
The second application program is:
Accessing the first storage device via the synchronization manager to determine whether the first email object is stored in an outbox of the first storage device;
When the first email object is stored in an outbox of the first storage device, the first email object is transferred from the second email transport to a predetermined computing device. configured, and a second computing device,
Data transfer system, which comprises a. A third computing device, the third computing device comprising:
A third storage device that stores objects, and the third application program,
The third e-mail transport;
The third application program is
May access the storage device of the third, the second to receive the first e-mail object from a computing device, stores the object corresponding to the first electronic mail objects in said third storage device is configured to,
An e-mail response based on the response object that generates a response object for responding to the first object, assigns a first time stamp representing the time when the response object is generated to the response object, and includes the time stamp The system of claim 15, wherein the system is configured to generate and send an object to a source of the first email object . A fourth storage device storing an object and a fourth application program ;
The fourth e-mail transport;
A fourth computing device comprising:
The synchronization manager is further configured to synchronize an object in the third storage device with an object in the fourth storage device;
The fourth application program is
An e-mail response based on the response object that generates a response object for responding to the first object, assigns a second time stamp representing the time when the response object was generated to the response object, and includes the time stamp The system of claim 16, wherein the system is configured to generate and send an object to a source of the first email object . The synchronization manager
A first synchronization manager on at least one of the first and second computing devices;
The system of claim 17, further comprising a second synchronization manager on at least one of the third and fourth computing devices.

Images