JP2001521253A - Meeting request and group scheduling generation from mobile devices - Google Patents

Abstract

SUMMARY The present invention includes a mobile device (3) that provides a user with the ability to schedule a meeting request from the mobile device (3). The mobile device (3) generates an object representing the meeting request and assigns the object a universal identification number that uniquely identifies the object from other devices (4, 10, 13) that are associated with the object. . Further, the mobile device (3) according to an aspect of the present invention provides properties of the object, which indicates whether the meeting request has already been transferred. Thus, to alleviate the problem of double meeting request forwarding, other devices (4, 10, 13) associated with the meeting request identify the request as a unique meeting request and the meeting request is already It can be determined whether the transfer has been performed.

Description

DETAILED DESCRIPTION OF THE INVENTION

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 trade name Handheld PC (or "H / PC") based on the Windows CE brand operating system offered by Microsoft in Redmond, Washington. ing. While a wide variety of computing tasks and applications can be performed on such mobile devices, 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
Including programs. Some commonly available PIMs are available from Microsoft Schedu
It is sold under the brand names le + and Microsoft Outlook, and is commercially available from Microsoft Corporation of 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] Usually, a mobile device is used together with a desktop computer. For example, a mobile device user may also have access to 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 the particular version of the PIM may be somewhat different between desktop computers and mobile devices). For this reason, it would be highly advantageous if the mobile device was designed to be able to connect to, exchange information with, and share information with a desktop computer.

[0004] Users can also make changes to PIMs on both mobile devices and desktops. Thus, regardless of whether recent changes to the PIM have been made on the mobile device or desktop computer, it is advantageous for the PIM on both the mobile device and desktop to include the latest information. 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 information updated is called synchronization.

[0005] Conventional PIMs that support electronic calendaring and scheduling functions (collectively referred to as schedulers, or scheduling applications) are classically supported on desktop computers. Such a PIM provides the user with the ability to schedule a meeting request for one or more desired attendees.

[0006] To generate a meeting request, a 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, a typical user interface allows a user to select the date and time (and often the location) at which a meeting will be held. Also, typically through a user interface, the user selects the group of attendees that he or she wants to attend the meeting, enters a text description of the meeting, and either has a single date or a regular meeting (ie, a regular meeting). , The meeting is held on one date only, or on the 15th of every month, on the first Monday of every month, every Monday, etc.).

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 typically defined by a number of characteristics, some of which are defined by user input provided by the user while generating the meeting request. Meeting information is critical time stamp (UTC)
, Which is updated whenever significant changes are made to the meeting object, such as changing the start or end time of the meeting, changing the location, etc.

[0008] Appointments entered in the calendar are viewed as meetings because other people are identified as attendees, and the scheduling application is typically a messaging application programming interface (MAPI).
Or invoke methods exposed by email applications according to other APIs that are well-proven and published sets of interfaces available from Microsoft Corporation of Redmond, Washington.

In response, the e-mail application creates another object representing the meeting request (an e-mail meeting request object), and the e-mail application (or a suitable transport) generates the e-mail meeting request object. Format into a well-defined and suitable email message for forwarding. In doing so, the critical time stamp from the meeting object is also placed in the email meeting request object. The email application then interacts with the particular transport, transporting the email meeting request object to the network, which routes it to the designated attendee. In doing so, the email application typically accesses an address book stored in a database to obtain a fully qualified email address for the attendee. This is also typically done by invoking MAPI or other suitable API methods associated with the database that stores the address book. The generation of a meeting object and the email meeting request object are collectively referred to herein as a meeting request creation.

Next, the potential attendee typically responds to the meeting request. In doing so, the caller's critical timestamp is returned (no change) along with the response. The response also includes the recipient's critical timestamp and the recipient's response (
For example, acceptance, rejection, provisional acceptance, etc.) are included. The recipient's critical timestamp is always the recipient (potential attendee) when the recipient makes a significant change
Will be updated by This allows the user to reliably order the receipt of multiple versions of the same meeting (eg, a caller has changed the time, date, or location of the meeting, resulting in a large number of meeting requests). Can be. Also, the caller can reliably order the receipt of the response,
Each response can be reliably correlated to the latest version of the meeting.

[0011] The response is then forwarded to the caller (eg, the calling computer). Next, the caller's email application and the scheduling application typically process the response (s) accordingly. For example, the caller stores, for each recipient (or potential attendee), the recipient's critical timestamp in a table along with each recipient's response code (representing acceptance, rejection, provisional acceptance response). The two commercially available PIMs identified above (Microsoft Schedu
le + and Microsoft Outlook branded PIMs) are examples of PIMs that support the features described above.

[0012] Meeting cancellations and exceptions to recurring meetings must also be handled. For example, PIM allows for cancellation of scheduled meetings and various exceptions to the recurring meeting pattern.

[0013] Scheduling of meeting requests as described above has heretofore been accomplished by a desktop or laptop computer equipped with a hard disk drive or other mass memory mechanism, or by a server or other similar including mass storage device itself. It has only been supported by low intelligence terminals permanently attached to computers. The ability to schedule a meeting request from a mobile device is simply not available. Depending on the current mobile device,
Some have a PIM that allows a user to view meeting requests and to view already scheduled meetings, but current mobile devices do not allow users to generate meeting requests from the mobile device itself.

There are a number of significant obstacles in attempting to provide a user with the ability to generate meeting requests from a mobile device. Exceptions to meeting cancellations and recurring meetings must be handled. Also, considerable problems arise with the possibility of forwarding duplicate 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.

Next, when the mobile device is synchronized with the desktop computer, the meeting object is synchronized with the calendar object storage on the desktop computer, and the e-mail 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, the synchronization of the meeting object with the calendar of the desktop computer may result in the desktop computer creating and transferring another email meeting request object. As a result, a duplicate email meeting request object is created (after synchronization, one by the mobile device and one by the desktop computer) and transferred. Under such circumstances, potential attendees may receive more than one meeting request and respond to both. This allows
A duplicate response is created for what should be one meeting request.

A similar problem may occur if, for example, a meeting request is generated in a conventional manner (to a desktop computer) and then synchronized to a mobile device capable of generating and transferring the meeting request. Meeting objects on the desktop calendar are synchronized to the calendar on the mobile device. The mobile device then recognizes the synchronized meeting object from the desktop, creates an email meeting request object, and attempts to transfer the object. As a result, substantially the same problem occurs. That is, 1
A double meeting request and a double response are generated for what should be one meeting request.

Further, the user of the mobile device may have one or more desktop computers (
The same problem results if the mobile device is equipped with this capability (e.g., home computer and work computer) when coupled to a mobile device. In that example, and using the traditional architecture,
Both desktop computers synchronize and recognize meeting objects and e-mail meeting request objects from the mobile device. Both desktop computers may create additional email meeting request objects and forward them to potential attendees.
Again, this results in a number of different meeting requests and responses being forwarded to what should be a single meeting request.

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 And can be scheduled on both mobile devices. However, the next time the first mobile device synchronizes with the desktop computer, the computer will again recognize the synchronized meeting object from the mobile device's calendar, create another email meeting request object, and May transfer objects. Thus, there is potentially a considerable problem with generating large numbers of meeting requests.

[0019] Similar problems, of course, arise when significant changes are made to the meeting objects on either the desktop computer or the mobile device. This also results in undesirable double email meeting requests.

Further problems arise because conventional mobile devices have significantly less memory capacity than desktop or similar computers. This creates a problem with the storage of the address book containing the fully qualified email addresses of all possible attendees on the mobile device.

A further obstacle exists because many desktop computers that must process meeting requests have different scheduling applications. Therefore, the meeting request generated by the mobile device may not be compatible with the associated scheduling application.

Further, localization of meeting requests can present a problem. For example, depending on locality, when writing data, it is common to first place the month, then the day, and the third year. For other localities, they are usually in a different order. further,
A text description that describes the meeting and contains the meeting request,
It may need to be rearranged to accommodate local convenience. Also, a meeting request can be generated in one time slot and forwarded to a recipient in another time slot. This is easy to get confused.

The present invention addresses some or all of these obstacles.

SUMMARY OF THE 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 generates 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. Further, the mobile device according to one aspect of the present invention provides a property of the object, which indicates whether the meeting request has already been transferred. In this way, other devices associated with the meeting request may identify the request as a unique meeting request, reducing the problem of double meeting request forwarding.

According to another preferred feature of the invention, the email application or calendar application on the mobile computer is completely capable of attending from a reduced address book or possibly stored directly on the mobile device itself. Get an email address that meets the conditions. This reduces issues related to the storage capacity of the mobile device.

According to another preferred embodiment of the present invention, the mobile device creates a meeting object and an e-mail meeting request object using a set of properties 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.

According to yet another preferred feature of the invention, the localizer implements the plurality of templates on the mobile device used to format the properties of the object associated with the meeting request. Since the data stream representing the meeting request is parsed by the mobile device and placed in a pre-selected field in the appropriate template, the text viewed by the user of the mobile device better adapts to local conventions. Further, time zone information is also included in one embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Overview FIG. 1 is a block diagram of a typical system or environment 2 in which the present invention operates. Environment 2 includes mobile device 3 and desktop computer 4. FIG. 1 also shows that the mobile device 3 optionally has another mobile device 10.
Or, it can be shown that it can be separately connected to another desktop computer 13.

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.

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 desktop computers 4 and 13 and the operation of mobile devices 3 and 10 are preferably similar. Therefore, for the sake of simplicity, the description will proceed with reference to mobile device 3 and desktop computer 4 only.

In one preferred embodiment of the present invention, the application program 7 on the desktop 4 is a personal information manager (PIM), which supports email messaging, scheduling and calendaring, and an address book containing contact information.

A PIM application is not always integrated. For example,
Some scheduling programs do not include an e-mail function, but may interface with anything equipped with an e-mail program (or vice versa). Of course, PIM7 (either a single application or a single integrated application or multiple interfaced applications) has a wide range of other features, such as task lists and (to name a few) personalized It can be configured to support an address book or the like. However, for clarity, features relating only to email messaging, scheduling and calendaring functions, and address book functions will be described in detail with respect to the present invention.

The object storage 8 is a memory configured to store a plurality of separate records or objects, each containing a plurality of fields or characteristics related to the above functions. In one preferred embodiment, PIM7 is Microsoft Ou
It is a program such as that available under the trade name tlook 97. The object storage 8 is configured to store objects each having a plurality of properties that may be associated with email messaging, scheduling and calendaring, and contact information.

For example, some properties included in objects related to email messaging include sender name, recipient name, text message, whether any given email message has an attachment attached. Indications, and possibly other similar characteristics. Also, some properties related to scheduling and calendaring include critical timestamp information, date and time information, potential attendees, repetitive properties that describe a recurring meeting or meeting request, and text of the meeting request. A description is included. Some characteristics related to contact information include the exact life of the contact list, or known names, the addresses and phone numbers of the people listed, and the full conditions of the people on the list Email address is included. 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.

The application program shown as PIM 5 for mobile device 3 is a PIM similar to that stored on desktop computer 4. Object storage 6 on mobile device 3 is configured to store a plurality of separate records or objects, each including a plurality of fields or characteristics related to the supported functions described above. Like PIM7, PIM5
May also support a wide variety of other features. However, for clarity, only those features relevant to the present invention are described in detail herein.

In one exemplary embodiment, each object in object store 6 contains the same set of characteristics stored in object store 8 or a subset of these characteristics for the associated message. Further, the object storage device 6
The object stored in the meeting request also includes a material change timestamp, and a property that indicates whether attendees that may have been identified in the meeting request have responded,
And a generic identifier for each individual meeting request (described in more detail below). The mobile device 3 executes the PIM 5 and holds the object in the object storage device 6.

In the exemplary embodiment, each object stored in the object storage 8 is also stored in the object storage 6. However, there are actually two instances for each object (one in object storage 6 and one in object storage 8). Thus, when a user makes a change to one instance of an object stored in either storage device 6 or storage device 8, a second instance of the object in the other of storage devices 6 and 8 will Preferably, the device 3 is updated when it is connected to the desktop computer 4 so that any instance of the same object contains the latest data. This is called synchronization.

To achieve synchronization, the synchronization component runs on mobile device 3 and 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.

The components of the mobile device 3 and the desktop computer 4 are:
It communicates with each other via any suitable and commercially available communication link 9 and using a suitable communication protocol. For example, in one preferred embodiment, mobile device 3 is connectable to desktop computer 4 with a physical cable that communicates using a serial communication protocol. Other communication mechanisms, such as infrared (IR) communications, direct modem communications, remote dial-up networking communications, communications over commercially available network cards (ie using TCP / IP), remote access services (RAS), wireless modems, Wireless cellular digital packet data (CDPD), or any other suitable communication mechanism, is also contemplated by the present invention.

FIG. 2 and the associated description are intended to provide a brief, general description of a suitable desktop computer 4 that may implement some of the present invention. 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. Further, 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. An example of a distributed program is Ex
These include those marketed under the trade names change, Schedule +, and MS Mail (all available from Microsoft).

Referring to FIG. 2, an exemplary system for implementing desktop computer 4 includes a general-purpose computing device in the form of a conventional personal computer 4, which includes a processing unit 21, a system memory 22, And a system bus 23 for connecting various system components including a system memory to the processing device 21. 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 a read-only memory (ROM) 24 and a random access memory (RAM) 25.

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
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 removable optical disk 31 such as a CD-ROM or other optical medium And an optical disk drive 30 for reading from and writing to the optical disk. The hard disk drive 27, the magnetic disk drive 28, and the 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 nonvolatile storage of computer-readable media, data structures, program modules, and other data for desktop computer 4.

Although the exemplary environment described herein employs a hard disk, removable magnetic disk 29, and removable optical disk 31, other types of computer-accessible, data-storable computer-readable media are available. For example, magnetic cassettes, flash memory cards, digital video disks (DVD), Bernoulli cartridges, random access memory (RAM), read only memory (ROM), etc. may also be used in the exemplary operating environment. The trader will understand.

The operating system 35, one or more application programs 36 (including the PIM 7), other program modules 37, and a number of program modules, including program data 38, are stored on a hard disk, magnetic disk 29, optical disk 31, ROM 24, Alternatively, it may be stored in the RAM 25. A user inputs commands and information to 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 a joystick,
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 include a sound card, parallel port, game port, or universal serial bus (USB). ) May be connected by 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, a desktop computer may typically include speakers 45 and other peripheral output devices such as a printer.

The desktop computer 4 may operate in a networking environment with a logical connection to one or more remote computers, such as the remote computer 49 (excluding the mobile device 3). 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 desktop 4, Only the storage device 50 is shown in FIG. The logical connection shown in FIG. 2 is a local area network (LAN) 5
1 and a wide area network (WAN) 52. Such networked environments are common in offices, enterprise wide computer network intranets, and the Internet.

When used in a LAN networking environment, desktop computer 4 is connected to local area network 51 via a network interface or adapter 53. When used in a WAN networking environment, desktop computer 4 typically includes a modem 54 or other means for establishing communication over a wide area network 52, such as the Internet. The internal or external modem 54 is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the desktop computer 4, or portions thereof, may be stored in the remote memory storage device. It should be understood that the network connections shown are exemplary and other means of establishing a communication link between the computers may be used.

The desktop computer 4 executes an operating system 35 normally 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, the WINDOWS 95 or WINDOWS NT operating system, another derivative version of the WINDOWS brand operating system, or another suitable operating system. And so on. Other suitable operating systems include the Macintosh OS sold by Apple Inc. and the OS sold by International Business Machines (IBM) in Armonk, New York.
Includes S / 2 Presentation Manager. PIM 7 is a program module 37
, Is preferably stored in a volatile memory or a non-volatile memory, or is loaded from a floppy disk 29, a CD-ROM drive 31 into any of the components shown in FIG. Alternatively, it can be loaded using another suitable mechanism.

A dynamic link library (DLL) containing a plurality of executable functions is linked to the PIM 7 for execution by the processor 21. The internal processor and internal component calls are facilitated by using the component object model (COM), as is common in programs written for MICROSOFT WINDOWS brand operating systems. Briefly, when using COM, software components such as DLLs have a number of interfaces. Each interface is exposed to a plurality of methods, which are individually invoked to make use of different services provided by the software components. further,
Providing an interface allows for optionally receiving one or more parameter arguments and invoking methods or functions from other software components.

In general, the DLL associated with PIM7 is presented in a desktop synchronization interface that operates in particular with PIM7 and, according to the synchronization protocol, functions as described in more detail in the above-referenced co-pending US patent application. Designed to be. The DLL calls the interface presented by PIM 7 to access data representing individual object characteristics held in object storage 8. It will be appreciated that the object store 8 may reside in any one of the appropriate memory components described in connection with FIG.

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 a preferred embodiment is a desktop assistant sold under the trade name H / PC, for example Micros
It is based on the Windows CE brand operating system provided by oft. In one preferred embodiment, the mobile device 3 is housed in a housing that fits comfortably in the hands of a typical user. The mobile device 3 has some components similar to those of the desktop computer 4. For example, in one 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.

In the embodiment shown in FIG. 3, the display 84 is a liquid crystal display (LCD) using a stylus 86 and a contact response display screen. Stylus 8
6 is used to press or touch the display 84 at the specified coordinates to achieve a particular user input function. Of course, other user input configurations may be used as well. For example, user input mechanisms may include a keyboard, trackball, and various other types of small keyboards. Further, the mobile device 3 is not embodied as an H / PC brand that is a digital assistant, but instead is another type of personal digital assistant (PDA), another personal organizer, a palmtop computer, or similar computerized notepad. It may be implemented as a device.

FIG. 4 is a more detailed block diagram of the mobile device 3. The mobile device 3 preferably plugs into a microprocessor 88, memory 90, input / output (I / O) components 92 (including a keyboard 82 and a touch screen 84), a spare expansion slot 93 (PC card, compact flash memory, etc.). And a serial interface 94. In the exemplary embodiment, these components of the mobile device 3
Connected together by a suitable bus 96.

In the exemplary embodiment, memory 90 includes a battery backup module (
The information stored in the memory 90 is implemented as a non-volatile electronic memory such as a random access memory (RAM) having a mobile device 30 (not shown).
Will not be lost if power to the power is turned off. Some portions of memory 90 are preferably allocated as addressable memory for program execution while memory 9
Another portion of 0 is preferably used to simulate storage to a disk drive.

The memory 90 includes an operating system 98 and an application (ie, PIM) 5. In operation, operating system 98 stores memory 90
From the processor 88 and executed by the processor 88. In a preferred embodiment, the operating system 98 includes a Window
s CE brand operating system. Operating system 9
8 is preferably designed for mobile devices and provides a PIM through a set of application programming interfaces and methods presented.
5 implements database functions that can be used by Object storage device 6
The object in the PI preferably responds to calls to at least partially presented application program interfaces and methods,
M5 and operating system 98.

Note that the PIM 5 does not need 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 features supported by the email messaging feature of PIM 5 may not have a corresponding feature in PIM 7 on desktop computer 4 and vice versa.

Object Synchronization To aid in understanding the present invention, object synchronization is briefly described here.

FIG. 5 shows the structure of the mobile device 3 and the desktop computer 4 used for synchronizing the objects stored in the object storage device 6 on the mobile device 3 and the object storage device 8 on the desktop computer 4. FIG. 2 is a block structural diagram showing a preferred embodiment of a component. FIG.
Is only one preferred embodiment, and other architectures may be used as well. Furthermore, the synchronization operation is performed by any two connected storage devices (
(Computers 4 and 13, and any connected peer of mobile devices 3 and 10). All that is required is a Sync Manager component, described below, that supports the synchronization of the two linked storage devices. The synchronization manager may reside on one or both devices, or on a third computer coupled to the two storage devices. However, for simplicity, only embodiments in which the desktop computer 4 is connected to the mobile device 3 will be described herein. Also, the synchronization protocol is only one preferred embodiment, and another suitable protocol may be implemented over a standard email protocol.

In addition to the PIM 5 and the object storage 6, the mobile device 3 includes a synchronization module 97, and the synchronization module 97
00 and the synchronization manager 102. In addition, the mobile device 3 includes a communication component 94, a remote application programming interface (
RAPI) server 116 and email messaging transport 13
2, 134, and 136.

The desktop computer 4 includes an interface component 108, a synchronization manager 110, a reference storage device 112, and a RAPI component 114 in addition to the PIM 7 and the object storage device 8. The desktop computer 4 also includes a communication component 115.

In general, in the embodiment shown in FIG. 5, the synchronization manager 110 is executed on the desktop computer 4 and operates between the object in the object storage device 6 in the handheld device 3 and the object in the object storage device 8 in the desktop computer 4. Command synchronization. Sync Manager 11
0 also holds the reference storage 112 away from the desktop object storage 8, as will be described in detail below. The synchronization manager 110 implements a synchronization protocol to compare objects stored in the object storage 6 in the mobile device 3 with corresponding objects in the object storage 8 in the desktop computer 4, Upon receiving the object, the object in the object storage device 8 can be updated. The synchronization protocol also facilitates retrieval of objects stored in object storage 6 on mobile device 3 via synchronization interface component 100 and synchronization manager 102, and communication component 94.

On the mobile device 3 side, the synchronization interface component 100 is presented in the application programming interface and the synchronization manager 10
2 calls this to read and store the objects and object properties on the object storage device 6. In general, the application programming interface allows for the creation of a database of different types of objects and allows application programs to write and read property names and values for objects in the object storage 6.

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 an object storage device 8. There are many ways in which PIMs 5 and 7 can store objects in object stores 6 and 8. But,
In the preferred embodiment, PIMs 5 and 7 create a separate database for each object type. For example, meetings, contacts, tasks,
Different databases are created for email messages and the like. Predefined properties are supported for each object type, and each database is assigned a name by the application program that created it.

In an alternative embodiment, the application programs on PIMs 5 and 7 may use one database for all object types, where the first property of each object defines the type of the object. In any case, the object is uniquely identified within 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.

The synchronization manager 110 does not necessarily need to be connected near the PIM 7. Rather, synchronization manager 110 is a separate component that synchronizes objects from any application program that supports the appropriate desktop synchronization interface. Certain synchronization interfaces are described in further detail in the co-pending US patent application incorporated by reference above. Communication components 94 and 115 implement serial communication between computers using a suitable link 9.

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 exposed to one or more application program interfaces and methods.

The interfaces and methods are described in further detail in co-pending patent applications incorporated by reference. Preferred among these interfaces is the messaging application program interface (M) developed and published by Microsoft for Windows brand operating systems.
API), but 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 provides programmable access to the functionality of an e-mail messaging program known as MS Mail, which is commercially available from Microsoft Corporation. . In another preferred embodiment, the MAPI presented by component 108 is sometimes extended M
A set of component object model based (COM based) interfaces, called APIs, including a set of automatic interfaces to messaging systems for use in Visual Basic and the like. 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 so that the synchronization manager 110 can access and synchronize any number of different desktop PIMs as long as the required interface methods are implemented for each PIM.

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 an object stored in the object storage device 8 on the desktop computer 4. The object identifier used by the PIM 5 to identify the object in the object storage 6 is the PIM
This mapping is necessary because 7 is not the same as the object identifier used.

The synchronization manager 110 synchronizes the desktop computer 4 with an instance of the same object in the object storage 6 on the mobile device 3.
The reference storage device 112 holds the identification data segments respectively corresponding to the plurality of object instances in the object storage device 8 above. The identification data segment is updated each time the corresponding object instance is synchronized.

The exact structure of the identification data segment used to identify a particular object instance depends on the desktop synchronization interface component 108
And are processed and stored by the sync manager 110. The identification data segment preferably includes some type of time stamp information since the last time the identification data was recorded in reference storage 112, and compares this to determine if the object has changed.

In addition to holding multiple identification data segments, the synchronization manager 110 also
A list of object identifiers corresponding to the objects held in the object storage device 6 is also held. These identifiers are provided to the synchronization manager 110 each time a new object is added to the object storage device 6 on the mobile device 3.

Synchronization Protocol The exact protocol for achieving perfect synchronization achieved according to one embodiment of the present system is briefly described below. A brief description of the protocol will aid in understanding the present invention. To synchronize objects, the synchronization manager 110 first creates two lists of handles that reference the particular object. The term "handle" refers to a number or other identifier that uniquely identifies an object and can be used to access the object. Generally, a handle is valid for a particular time interval or session, such as during the time the object is "open." When the same object is reopened, its handle will be different.

The first list of handles is obtained from the reference store 112, synchronized in the past,
And an object identified in the reference storage device 112. The second list of handles is a list that identifies 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 reference storage 112 and object storage 8.

If an object is identified in the reference storage 112 but not in the object storage 8, the particular object has been deleted from the desktop 4 since the last synchronization. On the other hand, if an object is identified in the object storage 8 but not found in the reference storage 112,
The object has been added to the desktop since it was last synchronized. In either case, synchronization manager 110 determines how to handle the object.
In a preferred embodiment, objects deleted from desktop object storage 8 are also deleted from reference storage 112. Further, the object added to the object storage device 8 is also added to the reference storage device 112.

Next, the synchronization manager 110 determines whether or not an arbitrary object stored in the object storage device 8 has been changed on the desktop since the synchronization was last performed. In other words, the handles corresponding to the same object are found in both object storage 8 and reference storage 112, but they are not the same (the time stamp, revision number, or another suitable identification segment is not the same). If so, this indicates that the object in the object store 8 has changed since the last synchronization.

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 storage 6, the synchronization manager 110
(Reflecting all objects since the last synchronization) with the object list in the object storage device 6 held by the synchronization manager 102. To determine whether an existing object has been modified, synchronization manager 102 is configured to maintain a state bit associated with each object stored in object storage 6. The status bits reflect whether the particular object associated with the bit has changed since the last synchronization. If so, the sync manager 102 notifies the sync manager 110 of the change, or simply logs a status bit, if the device 3 is connected to the desktop computer 4 so that the device 3 Is sent to the synchronization manager 110 the next time it is connected to

In any of these procedures, it is not necessary for the synchronization manager 110 or 102 to be aware of the specific properties 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 designers of these interfaces to define the format of the identification data segment that causes the interface to perform the required functions.

When 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 6, and requests the respective sync interface component to update the old objects. If the same object is modified on both mobile device 3 and desktop computer 4, a conflict occurs. The sync manager 110 resolves conflicts either by prompting the user or by referring to profile information entered by the user during setup. The characteristic information determines on which device and in which instance the procedure is performed. The process of setting up profile information is described in detail in the above-mentioned patent application specification.

When an object is created on either the desktop computer 4 or the mobile device 3, the object needs to be exchanged for the other device. When the mobile device 3 needs to get a new object from the desktop computer 4, the synchronization manager 110 invokes an interface method known as "Set-Up". With this interface method, the object is obtained from the object storage device 8 of the desktop computer 4 and the handle to be transmitted to the object storage device 6 of the mobile device 3 is specified. When the handle is obtained, "Get packet (GetP
A method known as "acket") is called repeatedly to retrieve the data stream that represents the object and is formatted by the interface component 108. The sync manager 110 is searched and links 9
, And only treats the data as a data stream that is sent to the synchronization manager 102 and finally to the object storage device 6. The appropriate synchronization interface component 100 parses the data stream to identify certain property values associated with properties corresponding to the object. Thereafter, those characteristics are stored in the object storage device 6.

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 112.

It is worth noting that the architecture described herein, along with other objects held in PIM5, PIM7, provides synchronization of objects related to email message meetings or appointments, or contact information. Thus, using the synchronization protocol, objects associated with these functions are synchronized during the synchronization process. Sync Manager 110
Detects any new objects in the object store 8 that represent new email messages, meetings or appointments or contact information, and places those objects on the mobile device 3 to alert the user of the mobile device 3. To the object storage device 6.

Further, if the user writes an email message, schedules a meeting (and therefore creates a meeting object and an email meeting request object), or on the mobile device 3 using the appropriate application of the PIM 5 When the contact information is input, the objects related to those items are stored in the object storage device 6 as new objects. During synchronization, those new objects are transferred to the desktop computer 4 and the object storage 8.

Meeting Request FIG. 6 is a block diagram illustrating one preferred embodiment of the mechanism by which a meeting request is generated. As shown in FIG. 5, the mobile device 3 and the desktop computer 4 are interconnected. However, FIG. 6 also shows that the mobile device 3 and the desktop computer 4 can 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 can also be connected to a wide area network 138 including

Items similar to those in FIG. 5 are assigned similar numbers. However, FIG.
M5 and 7 are shown in considerable detail. FIG. 6 shows 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, although each application may have a designated application programming interface (API), only a single API component 146 is shown in FIG. 6 for simplicity.

FIG. 6 further shows that the object store 6 interfaces with the applications 140, 142 and 144, preferably via its own set of application programming interfaces 148. Thus,
Applications 140, 142, and 144 secure object storage 6 through a call method presented by application programming interface 148 associated with object storage 6. In addition, the communication component 94 and the synchronization component 99 communicate with the application programs 140, 142, and 144 by calling methods presented in the application programming interface 146.

The PIM 7 of the desktop computer 4 is also shown in a more detailed block diagram. In one preferred embodiment, PIM 7 includes an email application program 150, a scheduling and calendaring program 15
2 and a full address book program 154. Application program 15
Although each of 0, 152 and 154 has an associated set of application programming interfaces, only a single application programming interface component 156 is shown in FIG. 6 for simplicity.

FIG. 6 further illustrates that, in a preferred embodiment, the object store 8 has its own set of application programming interfaces 158 (API
156, preferably the same as or separate from MAPI). Thus, the application programming interface 1
The method of calling application programs 150, 152 and 154 presented by 58 secures and interacts with the object store 8. in addition,
The communication component 115 includes application programs 150, 152 and 15
Call the methods exposed by application programming interface 156 to interact with.

FIG. 6 shows that the desktop computer 4 preferably includes an email transport 160. 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.

FIG. 7 is a flowchart illustrating a procedure for generating a meeting request on the mobile device 3. Hereinafter, description will be made with reference to FIGS.

To generate a meeting request from the mobile device 3, the user first enters meeting request information via a suitable 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. Stylus 86 and preferably keypad 82 (or any other suitable input mechanism)
, The user enters the appropriate information to request a meeting. Such information is generally entered in the meeting date and time, which may be entered using a fully qualified email address, by entering a well-known name, or by providing a non-empty email address area. (Which may be selected from registration information in a contact database that has) a required attendee, the subject of the meeting, an indication of whether the meeting is regular or one-time, preferably the location of the meeting. Scheduling application 142 creates an object representing the meeting request.

This information is used to create a meeting object and enter the object into storage in association with a calendar on the mobile device 3.
As a result of creating the meeting object, an email meeting request object is also created. It should also be noted that subsequent significant modifications to the meeting object will generate and send an updated e-mail meeting request.

In the preferred embodiment, an option has also been made to specify the transport over which the email meeting request object will be sent. Alternatively, the transport used can be implied by the full email address, itself. For example, when the mobile device 3 attempts to send the meeting request itself, it can be specified that any of the transports 132-136 will be used. In addition, options specifying particular options used in the synchronization protocols already described are preferably already used. For example, if the inbox synchronization option is available, the email meeting request object is synchronized with the desktop computer 4 outbox. Also, if the calendar synchronization option is enabled, the meeting object is synchronized with the calendar on desktop computer 4.
The desktop computer 4 then sends the e-mail meeting request object, preferably synchronized with the outbox.

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.

Next, a critical time stamp is added to the object (block 16).
5), and the scheduling application 142 assigns a global object identification tag to the created 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, desktop computer 4, and any 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 other devices.
This is indicated by block 166.

Because the e-mail meeting request object must be sent to another device, the scheduling application 142 operates the e-mail program 140 to completely restrict all attendees who may receive the meeting request. The method of the API 146 for searching for the e-mail address is called. In one preferred embodiment, the scheduling application 142 retrieves a fully qualified email address from the address book. In another embodiment, mobile device 3 has a shortened address book program 144
including. In a preferred embodiment, the shortened address book program 144 is
Implemented as a contact function provided by Microsoft Outlook 97. The shortened address book contains the first and last names, addresses, telephone numbers, and fully qualified email addresses of the people the user has chosen to add to the shortened address book. These people are likely to receive a large number of email messages from the user of the mobile device 3. Therefore, the information likely includes the fully qualified email address of attendees who may be meeting requests. In addition, if the address is not fully qualified, the synchronization component 97 on the desktop 4 attempts to determine a name on the desktop prior to sending the email.

Thus, either the e-mail application 140 or the scheduling application 142 listens to the shortened address book program 144 with the fully qualified e-mail address entered by the user as a potential attendee. Call the method of API 146 to retrieve the name. This reduces memory overhead that would otherwise be required, for example, if the user was required to download a complete address book from the desktop computer 4 to send an e-mail 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.

Also, a transport option indicating the particular transport to which the e-mail message will be 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 options selected, the email meeting request object will be sent over the appropriate transport,
When transmitted, it is removed from the outbox of the mobile device 3.

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 properties that the scheduling application program 142 contributes to the email meeting request object representing the meeting request are compatible with a number of other PIMs. Therefore, these properties are a subset or superset of all properties recognized by multiple PIMs, so that objects have their P
It can be accepted by the IM and handled appropriately. Appendix A attached at the end of this specification is a message property list whereby the objects associated with the meeting request are defined by the MICROSOFT SCHEDULE + branded scheduling program. These properties are remarkably MICROSOFT SCHEDU
Includes a modified repetition notification property that is backward compatible with other versions of LE + scheduling software. For example, in the embodiment described in Appendix A, recurring notifications used to confirm a recurring meeting are formatted as a superset of single instance notifications. In this way, previous versions of the MICROSOFT SCHEDULE + scheduling software provide well-formed meeting notifications, even for regular meetings.

In the preferred embodiment, the scheduling program 142 then calls the methods exposed by the API 146 associated with the email application program 140. The email message containing the email meeting request object is formulated by the email application 140 into one of a predetermined number of classes. The potential attendee's reception scheduler program distinguishes the types of meeting notifications based on the mail message class.
For example, in one preferred embodiment, a meeting cancellation notification from the host, a meeting request from the host, meeting acceptance from attendees,
There are mail message classifications such as meeting decline from attendees and provisional acceptance of meeting from attendees. Thus, this is preferably included with the object when the transport formats the e-mail meeting request object for transmission. The meeting request is sent via communication component 94 to the nominated transport 132, 134 or 136, which formats the message and sends it to network 138.

The format and transmission of the e-mail meeting request object from the transport on the mobile device 3 is shown in blocks 172 and 174 of FIG.

After the email meeting request object has been sent, it is removed from the mobile device 3 outbox to indicate that the message has been sent. This is indicated by block 190. Next, desktop computer 4
The meeting object is synchronized to a storage device on the desktop computer 4 containing the calendar. Preferably, the meeting object is only synchronized to the calendar on the desktop, so P
The IM also provides functionality that can be used to prevent the PIM from simply generating and sending an email meeting request object. The function may simply create an email meeting request object for the meeting request generated on the desktop. This feature is implemented to further address the issue of duplicate message delivery.

If the transport option is selected to send an e-mail meeting request object using the synchronization protocol and mail transport on desktop computer 4, the e-mail meeting request object The process is substantially the same, except that it is synchronized to the box (shown at block 173). The mobile device 3 simply waits until it is connected to the desktop computer 4 before any action is taken on the meeting request. When the mobile device 3 connects to the desktop computer 4, the synchronization protocol described above is executed. During the synchronization process, the meeting object is synchronized to the calendar on desktop computer 4 and then the e-mail meeting request object is synchronized to the outbox of desktop computer 4 via synchronization components 97 and 99. Upon receiving an email meeting request object displaying a meeting request, the email application program 150
Recognizes that a meeting request needs to be sent. Email application program 150 calls the necessary methods exposed by the API to cause the appropriate objects to be sent to network 138 via communication component 115 and transport 160. This is again block 17
2, 173, 174 and 190.

It is also worth noting that in a preferred alternative embodiment, the meeting request does not need to be completely formatted on the mobile device 3. Instead,
The data representing the email meeting request object is stored and can only be 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 particular transport used by the desktop computer 4 when sending a meeting request. Since this information is not stored by the mobile device 3, it does not synchronize with the desktop computer 4. Instead, the e-mail application program 150 on the desktop computer 4 sends the complete address book 15 (before sending the meeting request).
4 calls the necessary methods via API 156 to cause it to retrieve the transport identified by the user associated with each of the possible attendees. The information is then used by the email application program 150 in selecting an appropriate transport 160 to send the email meeting request object. In this way, no additional storage capacity for storing such transport information need be consumed on the mobile device 3. This is indicated by block 188.

In any case, when the e-mail meeting request object is sent by the e-mail application program 150 to the network 138, the e-mail meeting request object is removed from the outbox. This is indicated by block 190.

After the e-mail meeting request object has been sent, it is determined whether any other meeting requests have been synchronized to the desktop computer 4 during the most recent synchronization process. If not, normal processing continues. If so, processing returns to block 172, where the email application program 150 calls the necessary API to send the object. This is indicated by block 192.

FIG. 8 is a procedural flow chart illustrating a preferred embodiment of how the 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 with respect to the delegation process. The publicly available MAPI specification fully discloses how to interpret such properties.

Thus, the recipient of the meeting request is provided with a suitable user interface to indicate the response. Responses will be 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.

Upon receiving the response, the scheduling application program 142 associates the response with the meeting object created by the scheduling application program 142 when the user generates the request stored in the object storage 6. This association is performed by using a global identification number that uniquely identifies the meeting request to all devices that may encounter it. This is indicated by block 196.

Then, the critical time stamp information is 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 time stamp. 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 timestamps from this particular recipient for the response to be due. Otherwise, the response is rejected or expired and ignored. This is indicated by block 197.

It should be noted that in the preferred embodiment, the time stamp is always forward. Thus, even if the user resets the clock sufficiently far into the past, any subsequent time stamps will always be later than the current clock time and will be the latest time stamp plus one second.

Thereafter, the scheduling application program 142 calls the necessary methods presented by the API 148 to update the attendee status associated with the request. It is updated based on the specific response received from the attendee. This is indicated by block 198.

After that, the mobile device 3 simply waits to be connected to the desktop computer 4. Once connected, the updated object (including the updated attendee status characteristics) is synchronized to the instance where the object is stored in the object store 8. This is performed using the synchronization protocol discussed above. This is indicated by blocks 200 and 202. Thereafter, the meeting object is made available to the scheduling application program 152 and the desktop computer 4 for user observation and interaction.
It can be displayed on the user's calendar on the desktop computer 4.

FIG. 9 is a procedural flow diagram in a preferred embodiment of how a response is processed when the response is received via transport 160 on desktop computer 4. First, the user enters information via an appropriate user interface that defines the user's response to the meeting request. Thereafter, the response is sent back to the desktop computer 4 via the transport 160 and the communication component 115. This is indicated by block 204.

The scheduling application program 152 is used for the mobile device 3
As described above, the response is associated with the meeting object using the global identification number assigned to the meeting object and received with the response to the meeting request. 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 attendee status of the meeting object stored in the object storage 8. This is indicated by block 208. Thereafter, the desktop computer 4 simply waits until it is next connected to the mobile device 3.

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 then stored in the object store 6 Synchronized with other instances. Synchronization is achieved by the synchronization protocol described above. Thereafter, the updated object is available for the user of the mobile device 3 to review and process. This is indicated by blocks 210 and 212.

The mobile device of the illustrated embodiment according to the present invention handles exceptions for recurring meetings and meeting cancellations. In one embodiment, upon receiving updates of the recurring pattern of the periodic meeting, the scheduling PIM
Also removes all exceptions. Thus, when changes to the periodic meeting pattern are sent, a new e-mail object must be created and sent for each exception. For example, assume that a user has entered a recurring meeting request on mobile device 3. The scheduling application 142 creates a recurring meeting object and registers it in the user's calendar. Email application 140 also generates an email recurring meeting request for transmission to potential attendees. Recipients (potential attendees) can generally respond as described above.

For the purposes of this example, a regular meeting is held every Tuesday from April 1st at 10 am
: 10:00 to 11:00. However, the user (organizer) needs to cancel the April 8 meeting. The user launches the scheduling application 142 and deletes the desired instance. The email application 140 then creates another object (repeat pattern exception) for transmission indicating this deletion. Organizer is next April 1
The meeting on the 5th needs to be changed from 11:00 to 12:00 noon. A similar process is performed to generate the exception. The organizer then changes the location of the recurring meeting and applies the changes to the entire repeating pattern. For this, three new e-mails need to be sent.

The first e-mail is generated simply to indicate a new location for repetitive pattern correction. In this case, the above two exceptions may be deleted in some PIMs. Thus, two new emails are generated to reestablish the two exceptions (ie, canceling the April 8 meeting and rescheduling the April 15 meeting). These emails are automatically generated by the email application 140. These same actions may be taken in response to other appropriate changes, such as modifying the attendee list.

Localization As described above, in a preferred embodiment, a meeting object is generally accompanied by a text phrase that describes the nature of the meeting request. The text phrase is generated based on characteristic values entered by the user during generation of the meeting request. For example, a user may request a potential attendee to join a meeting at 10:00 am on the third Monday of every month from January 1, 2000 to March 20, 2001. In that case, a typical text message looks like this, which is retrieved and attached in the meeting request object for display to potential attendees: "This meeting shall be held at 10:00 am on the third Monday of every month from January 1, 2000 to March 20, 2001. (This meeting shall
take place on the third Monday of each month at 10:00 am beginning Ja
nuary 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 writing the date. Further, the order of the words or phrases in the text message and the components of the text message need to be rearranged so as to conform to local conventions.

In a preferred embodiment, a predefined 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.

According to one aspect of the invention, a text message used to request a recurring meeting is broken up into multiple phrases. Each of the generated phrases is decomposed into a plurality of fields. The specific phrases that can be generated to define the meeting request and the specific fields from which those phrases are separated can be any suitable phrases or fields.

With respect to the phrases described above, FIG. 11A shows one embodiment of a field in which the phrases can be decomposed. 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 field 214. The term "at" is placed in field 216. The hour designation "10:00" is placed in field 218 and the AM / PM designator is in field 2
Placed at 20. The term "beginning" is placed in field 222, and the remaining messages are similarly in fields 224, 226, 228, 230, 234,
236, 238, 240 and 242.

FIG. 10 is a procedural flow chart showing how the localization process works. The generation of text phrases that define the meeting request and the decomposition of those requests into various predetermined fields is indicated by block 242. Next, during manufacture of the mobile device 3, a localizer program is executed for each message generated on the mobile device 3 and the fields 214-240 are rearranged so that each message complies with local conventions. Of course, the particular localizer program running on the mobile device 3 is
It depends on the specific geography and consumer base that is intended. Upon execution of the localizer program, the mobile device 3 includes a plurality of sets of fields, called templates, for arranging message data to display text messages in a manner appropriate for the region. Running the localizer program in setting up the template is indicated by block 244.

After the mobile device 3 owns the local template, 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 textual description being received). This is indicated by block 248.

Next, the parsed data is placed in a pre-selected field in the template based on the generated phrase. This is indicated by block 250. Since the localizer program has already been executed, the fields in the template will already be arranged in the proper order to conform to local conventions.

FIG. 11B shows the rearrangement of fields in the template shown in FIG. 11A according to different conventions. FIG. 11B shows the case where the phrasing is slightly different from that shown in FIG. 11A, and the phrase follows a convention where the date is conventionally placed before the month in the date. The phrase now includes the same term, but as follows: "This meeting shall be held from 1 January / January 2000 to 20 / March 2001 every third Monday at 10:00 am (Beginning 1 Ja)
nuary, 2000 and ending 20 March, 2001 this meeting shall take place on t
he third Monday of each month at 10:00 AM) "

All appropriate phrases are, of course, localized as well.

Also, in the illustrated embodiment, time zone information is advantageously processed. For example, when a recurring meeting request is generated and sent to a device located at a different time period, the text phrase indicating the recurring meeting includes an indication of the time period when the recurring meeting request was generated. For example, for a meeting held every Tuesday from March 3 at 8:00 am, a user in Paris (France) sends a periodic meeting request to a recipient in Seattle (9 hours behind the clock). Then the text phrase looks like this: "This meeting will be held every Tuesday from March 3 at 8:00 am;
(GMT + 1) Paris, Madrid. (This meeting occurs every Tuesday at 8
: 00 am beginning March 3; (GMT + 1) Paris, Madrid.) "

This allows the recipient to see the repetition pattern that was originally configured by the sender.

[0130] On the other hand, if the meeting is not regular, the time is preferably displayed simply as appropriate for the recipient (eg, "This meeting is scheduled for Tuesday at 11:00 pm").

Conclusion It can therefore be seen that the present invention offers 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 a meeting request so as to uniquely identify objects to all other devices that are likely to be relevant. The present invention also makes use of the PIM's ability to indicate whether a meeting request has been sent to a potential attendee. These functions eliminate duplicate message transmission.

The present invention also preferably implements the function of reducing the memory required to perform the meeting request function using the shortened address book. In addition, the present invention uses a set of scheduling characteristics compatible with multiple different PIMs that are likely to encounter meeting requests. In addition, the present invention preferably employs a localization procedure that localizes meeting requests in a more advantageous manner according to more regional conventions and processes time zone information. The present invention preferably also supports the use of multiple email transfers, let alone a synchronization protocol.

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 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 shows one embodiment of a portion of the desktop computer shown in FIG. 2 and FIGS. 3 and 4;
FIG. 3 is a block diagram showing the mobile device shown in FIG. 1 and synchronization information stored in an object storage device on a desktop computer and on the mobile device according to the present invention.

FIG. 6 is a block diagram illustrating one embodiment of a portion of the desktop computer shown in FIG. 2 and the mobile device shown in FIGS. 3 and 4, illustrating the generation and transfer of a meeting request.

FIG. 7 is a flowchart illustrating generation of a meeting request according to a preferred embodiment of the present invention.

FIG. 8 is a flowchart illustrating a process for responding to 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 process for responding 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 flowchart 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 illustrate one embodiment of a template used to localize a text description of a meeting request according to the present invention.

[Procedure amendment]

[Submission date] June 12, 2000 (2000.6.12)

[Procedure amendment 1]

[Document name to be amended] Drawing

[Correction target item name] Fig. 1

[Correction method] Change

[Correction contents]

FIG.

[Procedure amendment 2]

[Document name to be amended] Drawing

[Correction target item name] Figure 2

[Correction method] Change

[Correction contents]

FIG. 2

[Procedure amendment 3]

[Document name to be amended] Drawing

[Correction target item name] Fig. 4

[Correction method] Change

[Correction contents]

FIG. 4

[Procedure amendment 4]

[Document name to be amended] Drawing

[Correction target item name] Fig. 5

[Correction method] Change

[Correction contents]

FIG. 5

[Procedure amendment 5]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6

[Correction method] Change

[Correction contents]

FIG. 6

[Procedure amendment 6]

[Document name to be amended] Drawing

[Correction target item name] Fig. 7

[Correction method] Change

[Correction contents]

FIG. 7

[Procedure amendment 7]

[Document name to be amended] Drawing

[Correction target item name] Fig. 8

[Correction method] Change

[Correction contents]

FIG. 8

[Procedure amendment 8]

[Document name to be amended] Drawing

[Correction target item name] Fig. 9

[Correction method] Change

[Correction contents]

FIG. 9

[Procedure amendment 9]

[Document name to be amended] Drawing

[Correction target item name] FIG.

[Correction method] Change

[Correction contents]

FIG. 10

──────────────────────────────────────────────────続 き Continued on front page (31) Priority claim number 09 / 058,679 (32) Priority date April 10, 1998 (1998.4.10) (33) Priority claim country United States (US) ( 81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), CA, JP (72) Inventor Scorpa, Scott 98059, Washington, United States of America, Newcastle, South East 81st Court, 14329 (72) Inventor Alam, Salim 98052, Washington, United States of America 98052, Redmond, North East Ninety First Way 15833 (72) Inventor Vargas, Garrett Earl United States of America 9431 (72) Inventor Whitney, Dave USA, 98008, Bellevue, Washington, USA One Hundred Sixties Avenue North East 2648 (72) Inventor Ulrich, Blythe 98034, Washington, USA, Kirkland, North East One Hundred Redififs Street 13105 (72) Inventor Farrel, John Eye 98236, Washington, United States of America 98236, Clinton, East Fidalgo Drive 3638 F-term ( Reference) 5B019 KA04

Claims (20)

[Claims] 1. An object storage device, an application program configured to hold an object in the object storage device, a user input mechanism configured to receive user input information, and an individual storage device stored in the object storage device. A synchronization component configured to synchronize the object of the remote object stored in the remote object storage device; and a communication component configured to communicate with a remote device including the remote object storage device, wherein the application program A mobile device further configured to generate a meeting object and an email meeting request object based on the user input information. 2. The mobile device of claim 1, wherein the application program is configured to generate a meeting object having a universal identifier that uniquely identifies the meeting object among a plurality of other objects. 3. The application program, wherein the first application program is configured to generate the meeting object based on the user input information, and the second application program is configured to generate the electronic mail meeting request object.
The mobile device according to claim 2, comprising: an application program. 4. The application program further includes a contact application program configured to hold an object in the object storage representing contact information, wherein the contact information is completely associated with an individual identified by the contact information. Address information representing a qualified email address, wherein the application program is a fully qualified email address that may be an attendee identified by the contact information upon interaction with the contact application program Claim 1 configured to obtain
The described mobile device. 5. The application program according to claim 1, wherein the meeting object and the electronic object are associated such that a characteristic of the object is associated with the remote object storage device and matches at least one of a second application program different from the application program. The mobile device of claim 1, configured to generate a mail meeting request object. 6. The application program receives a data stream representing a text phrase describing a meeting object, parses the data into sections, and places the sections in corresponding fields of a preselected template. The mobile device of claim 1, wherein the preselected template is configured to be associated with the received text phrase. 7. The mobile device of claim 6, wherein the preselected templates are created by being placed in the fields in an order based on a particular locality. 8. A method of operating a mobile device, the method comprising: providing a first object storage device in the mobile device, providing a first application program to the mobile device; Holding an object in one object storage device; intermittently synchronizing the object in the first object storage device with an object in a remote object storage device; receiving user input information representing a meeting request; Creating a meeting object in the first application program such that at least some of the input information defines characteristics of the meeting object; and e-mail meeting based on the information in the meeting object. Generates a ring request object, for transfer, storing said meeting object and the e-mail meeting request object to the first object store includes a method. 9. The method of claim 1, further comprising: coupling the mobile device to a computing device having the remote object storage; synchronizing an object in the first data storage with an object in the remote data storage; 9. The method of claim 8, comprising forwarding the request from an email transport on the computing device. 10. The method of claim 8, further comprising: providing an email transport on the mobile device; and transferring the email meeting request object from an email transport on the mobile device. 11. The method according to claim 11, wherein providing the mobile device with an email transport comprises: providing the mobile device with a plurality of email transports, through which the email meeting request object is transferred. The method of claim 10, comprising selecting one of the ports. 12. Creating a meeting object further comprises assigning the meeting object a timestamp indication that indicates when the meeting object was created, and creating the email meeting request object comprises: The method of claim 11, comprising assigning the time stamp indication to an email meeting request object. 13. Receiving a response object, correlating the response object to the meeting object on the mobile device based on the universal identifier and the timestamp indication, wherein the meeting is performed based on the received response object. 13. The method of claim 12, further comprising: updating a response status associated with the object. 14. The method of claim 13, further comprising synchronizing the response state with the remote object storage. 15. A first computing device, comprising: a first data storage device configured to store an object; a user input mechanism; receiving user input information from the user input mechanism; A first application program configured to generate a first object based on user input information and to store the first object in the first data storage device. A synchronization manager configured to synchronize an object in the first data storage device with an object in a second data storage device; and a second computing device, configured to store the object. Accessing the second data storage device, and accessing the first data storage device. A second computing device, comprising: a second application program configured to create an email object based on the first object synchronized from a storage device to the second data storage device; An electronic mail transport, wherein the second application program is configured to transfer the electronic mail object by the electronic mail transport. 16. The system further comprising a third computing device, the third computing device comprising:
A third data storage device configured to store an object; accessing the third data storage device to receive an email object from the second computing device; The system of claim 15, further comprising: a third application program configured to store an e-mail object in the third data storage device. 17. The computer system further comprising a fourth computing device, the fourth computing device comprising:
The computing device comprises: a fourth data storage device; and a fourth application program configured to access the fourth data storage device and store an object in the fourth data storage device. 17. The system of claim 16, comprising: wherein the synchronization manager is configured to synchronize objects in the third and fourth data storage devices. 18. The synchronization manager, wherein: a first synchronization manager on at least one of the first and second computing devices; and a first synchronization manager on at least one of the third and fourth computing devices. 18. The system of claim 17, comprising two synchronization managers. 19. An object storage device, a user input mechanism configured to receive user input values, a plurality of e-mail transports, creating an object based on the user input values, A first application program configured to transfer using a preselected one of the mail transports. 20. The mobile device of claim 24, further comprising a housing that holds the object storage device, the application program, and the plurality of email transports, and has a size that fits in a hand.