US20060095549A1 - Managing asynchronous objects received over multiple communication protocols - Google Patents

Abstract

Systems and methods for managing asynchronous object transfers over multiple wireless networks. At a device, each received object is detected and parsed to extract identifying information such as sender and object type. Each object is stored in a temporary storage without being processed by any application of the device. The user is prompted to either accept or reject each object, one at a time or all together. Each accepted object is persistently stored on the device and processed by an application that is associated with the type of object. Rejected objects are deleted from the temporary storage and are not persistently stored on the device.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of application Ser. No. 09/964,318, filed Sep. 26, 2001, and entitled “MANAGING ASYNCHRONOUS OBJECTS RECEIVED OVER MULTIPLE COMMUNICATION PROTOCOLS” and which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
• 1. The Field of the Invention
• The present invention relates to systems and methods for managing asynchronous object transfers over multiple networks that have different communication protocols. More particularly, the present invention relates to systems and methods for managing incoming object transfers by temporarily storing each incoming object in temporary storage for presentation to a user who accepts or rejects the received objects.
• 2. Background and Relevant Art
• Devices such as personal digital assistants (PDAs), cellular telephones, and laptop computers are becoming increasingly popular and have capabilities that make them indispensable tools rather than conveniences. PDAs, for example, allow a user to store a wide range of data including address data, calendar data, and contact data in a device that is easy to carry and convenient to use. With a PDA, a user can receive emails, write memos, create to do lists, and the like with relative ease.
• Another advantage of devices like PDAs is that a user can share data stored on their PDA with the PDA of another user. This is typically accomplished using an infrared (IR) port that is usually provided with each device. To share data over an IR port, the user that is sharing an object will select or identify the object to be shared and the user receiving the selected object will enable their device to receive an incoming object transfer. Then, the users place their devices in a manner that permits their respective IR ports to “see” each other. The user sending the object then sends the selected object to the other user over the IR connection. When the object transfer is complete, the connection is automatically terminated and the object has been successfully transferred to the other user's device where it is processed and stored.
• These types of connections present relatively little security risk to either user because an IR connection requires that the two devices be able to “see” each other. Because of this limitation on IR object transfer, the users will also be able to see and identify each other. For at least these reasons, it is very difficult for a malicious user to transfer an object to a particular user's device without the user knowing that an object has been transferred to their device.
• The advent of technologies that do not require a line of sight, however, introduces security risks that were not previously present. Bluetooth, for example, can transfer files over longer distances and through barriers such as walls using radio links. Bluetooth also permits a device to process more than one incoming object transfer at a time. If a user has configured their device to receive incoming object transfers (often referred to as beams), it is possible that an unwanted object could be received on the user's device, thus placing the user's data at risk. A malicious user, for example, could transfer a virus onto the user's device that could cause the user's data to be broadcast back to the malicious user or otherwise affect the user's data and/or the user's device. What is needed are systems and methods that permit a user to manage incoming object transfers or beams and that provide additional security to the user for the data on their device.
SUMMARY OF THE INVENTION
• These and other problems are overcome by the present invention which is directed to systems and methods for managing all asynchronous incoming object transfers or beams to a device. The present invention provides the ability to receive and process all asynchronous object transfers that are received over various wireless and/or wired communication networks or protocols, such as infrared transmission and bluetooth.
• All asynchronously received objects are placed in temporary storage and are presented to the user, who decides how to process or otherwise handle the received objects by either accepting or rejecting each object. One advantage is that the objects received by the device are not processed by corresponding applications before they are accepted or rejected by the user. For example, a contact application does not receive or process a contact object until the contact object has been accepted by the user.
• When an incoming object transfer is received or when an object is received by a device, the object is usually parsed. Parsing the object provides the device with the ability to provide the user with some information about the object, such as what type of object has been received, who sent the object, and the like, although this information is not always available from the received object or may be included in the object transfer.
• The object is placed in temporary storage, such as a queue, and the user is notified about the received object. As other objects are received, they are also parsed and stored in the same queue. Notifications to the user will usually indicate how many objects have been received or are in the queue awaiting action from the user. The notifications or prompts will provide the user with various options (accept, reject, accept all, reject all, for example) that have certain consequences. Accepting an object will result in the object being processed by the device and accepting all of the objects results in all objects being processed by the device without further user input. Rejecting an object results in the object being deleted from the queue and the object is never processed or handled by any corresponding application of the device. Rejecting all of the objects causes all of the current objects in the queue to be deleted. The user is not required to respond to the notification immediately, but can decide what to do about the received objects at a later time. For devices that are partners, incoming object transfers can be accepted without prompting the user.
• Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGS
• In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
• FIG. 1 illustrates an exemplary system that provides a suitable operating environment for the present invention;
• FIG. 2 is a block diagram illustrating a device capable of receiving objects from multiple devices over multiple communication or data transmission protocols;
• FIG. 3 is a block diagram illustrating how a device processes each of the objects that are received from other devices over various communication or data transmission protocols; and
• FIG. 4 is a flow diagram of an exemplary method for processing objects received at a device over different protocols.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
• The present invention relates to systems and methods for managing asynchronous incoming object transfers or beams to a device. In accordance with the present inventions, many devices will have the capability to receive and transfer data over more than one protocol including, but not limited to, infrared, bluetooth, Wi-Fi, 802.11a, 802.11b, and other wireless and/or wired communication or data transmission protocols and networks. When a device has this ability, it is possible that the device will receive multiple asynchronous object transfers from multiple devices.
• The present invention provides the advantage of being able to receive asynchronously transferred objects while reducing any security risk that may be posed to the device or to data/applications/operating systems stored on the device. This is essentially accomplished by implementing a temporary storage for the incoming objects and having the user determine whether the received objects should be accepted or rejected. By providing the user with the ability to receive and/or reject each received object, an object cannot be stored or activated on the user's device unknowingly. This creates a layer of security such that the received objects do not have the opportunity act on other data of the device until the user makes a decision about the received objects. Objects that are compatible with particular applications are not provided to those applications until the objects are accepted by the user.
• The present invention thus extends to both methods and systems for managing incoming or asynchronous object transfers. The embodiments of the present invention may comprise a special purpose or general-purpose computer including various computer hardware, as discussed in greater detail below.
• Embodiments within the scope of the present invention also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.
• FIG. 1 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by computers in network environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.
• Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, personal digital assistants (PDAs), multi-processor 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 local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
• With reference toFIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of aconventional computer20, including aprocessing unit21, asystem memory22, and asystem bus23 that couples various system components including thesystem memory22 to theprocessing unit21. Thesystem bus23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM)24 and random access memory (RAM)25. A basic input/output system (BIOS)26, containing the basic routines that help transfer information between elements within thecomputer20, such as during start-up, may be stored inROM24.
• Thecomputer20 may also include a magnetichard disk drive27 for reading from and writing to a magnetichard disk39, amagnetic disk drive28 for reading from or writing to a removablemagnetic disk29, and anoptical disk drive30 for reading from or writing to removableoptical disk31 such as a CD-ROM or other optical media. The magnetichard disk drive27,magnetic disk drive28, andoptical disk drive30 are connected to thesystem bus23 by a harddisk drive interface32, a magnetic disk drive-interface33, and anoptical drive interface34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data structures, program modules and other data for thecomputer20. Although the exemplary environment described herein employs a magnetichard disk39, a removablemagnetic disk29 and a removableoptical disk31, other types of computer readable media for storing data can be used, including magnetic cassettes, flash memory cards, digital versatile disks, Bernoulli cartridges, RAMs, ROMs, and the like.
• Program code means comprising one or more program modules may be stored on thehard disk39,magnetic disk29,optical disk31,ROM24 orRAM25, including anoperating system35, one ormore application programs36,other program modules37, andprogram data38. A user may enter commands and information into thecomputer20 throughkeyboard40, pointingdevice42, or other input devices (not shown), such as a microphone, joy stick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to theprocessing unit21 through aserial port interface46 coupled tosystem bus23. Alternatively, the input devices may be connected by other interfaces, such as a parallel port, a game port or a universal serial bus (USB). Amonitor47 or another display device is also connected tosystem bus23 via an interface, such asvideo adapter48. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.
• Thecomputer20 may operate in a networked environment using logical connections to one or more remote computers, such asremote computers49aand49b.Remote computers49aand49bmay each be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically include many or all of the elements described above relative to thecomputer20, although onlymemory storage devices50aand50band their associatedapplication programs36aand36bhave been illustrated inFIG. 1. The logical connections depicted inFIG. 1 include a local area network (LAN)51 and a wide area network (WAN)52 that are presented here by way of example and not limitation. Such networking environments are commonplace in office-wide or enterprise-wide computer networks, intranets and the Internet.
• When used in a LAN networking environment, thecomputer20 is connected to thelocal network51 through a network interface oradapter53. When used in a WAN networking environment, thecomputer20 may include amodem54, a wireless link, or other means for establishing communications over thewide area network52, such as the Internet. Themodem54, which may be internal or external, is connected to thesystem bus23 via theserial port interface46. In a networked environment, program modules depicted relative to thecomputer20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing communications overwide area network52 may be used.
• The present invention is described in terms of a device such as a PDA, but it is understood that the systems and methods described herein can be applied on other devices such as cellular telephones, laptop computers, pagers, and other devices that can receive incoming object transfers over wireless and/or wired systems, networks and protocols. As used herein, an “incoming object transfer,” “asynchronous object transfer,” and “object transfer” are interchangeable and refer to objects or files that are being sent or beamed from one or more devices to a receiving device. Exemplary objects or files include, but are not limited to, address objects, calendar objects, contact objects, and other types of objects and files, including executables and the like or any combination thereof.
• FIG. 2 is a block diagram that illustrates an exemplary environment in which the systems and methods of the present invention may be implemented.FIG. 2 illustrates adevice200 that is representative of multiple devices as previously mentioned. Thedevice200 includes aport202 over which data such as objects and files are received from other devices and over which data is transferred to other devices. Theport202 is representative of ports including, but not limited to, aIR port204 and aBluetooth port206. With respect to incoming object transfers, the objects are stored in atemporary storage208. Theobject management210, processes the objects as will be described below in more detail.
• Thedevices220,230, and240 represent devices that may send an object to thedevice200 using theirrespective ports222,232, and242. These devices are not required to be the same type of device as the receivingdevice200. Thus thedevice220 may be a PDA, thedevice230 may be a cellular telephone, and thedevice240 may be a laptop computeer. The ports on thedevices220,230, and240 can be IR ports, Bluetooth ports or other ports complying with different protocols as previously described. In general, thedevices220,230, and240 communicate with thedevice200 over a wireless network or wireless communication protocol. Thedevice200 is able to receive an object transfer from one or more of thesedevices220,230, and240.
• For example, thedevice230 may communicate, beam or transfer an object over an IR port, which implies that thedevice230 and thedevice200 have a direct line of sight between the IR port of thedevice230 and theIR port204 of thedevice200. As the same time, thedevice220 may communicate, beam or transfer an object to thedevice200 using a bluetooth port. Because bluetooth allows for more than one object to be transferred at a time, it is also possible that thedevice240 is attempting to send or beam an object to thedevice200. Thus, thedevice200 is receiving asynchronous object transfers from multiple devices over multiple protocols and the present invention is directed to managing these asynchronous object transfers regardless of the protocol used to transfer and receive the object at thedevice200.
• FIG. 3 is a block diagram that more fully describes object management from the perspective of a device such as a PDA. Thedevice200, as shown inFIG. 3, has aport204 over which incoming object transfers are received. As a general rule, thedevice200 will only accept one incoming object transfer at a time. If more than one device is attempting to send an object, only the first device will be serviced. Additional incoming object transfers will be ignored or denied until the current incoming object transfer is completed. Alternatively, thedevice200 may be configured to receive multiple objects concurrently in accordance with the particular protocol used to transfer the object.
• By focusing on a single incoming object transfer at a time, however, thedevice200 is provided with additional security. Typically, thedevice200 is always listening for incoming object transfers or is configured to always receive incoming object transfers. In some instances, however, thedevice200 can be configured to not listen for incoming object transfers. In other words, the ability to receive objects may be disabled.
• When an incoming object is received via theport204, thedetection module250 detects the object and the received object is parsed by theparser252. By parsing the received object, thedevice200 can determine, for example, what type of object has been received, who sent the object, and other data. After the object is parsed, the detection module provides the parsed object to thenotification module250.
• Thenotification module250 generates a notification to the user and stores the object in a temporary storage such as aqueue262, although other structures may be used to temporarily store the received objects. After the notification is generated, the user is prompted (270) that an object has been received. In the prompt, the user can accept the object by selecting ayes option272, in which case the object is persistently stored in the device. In other instances, the object is also processed by an appropriate application or by an application that processes objects of a given type. For example, an accepted calendar object is processed by the calendar application and is stored on the calendar, an accepted contact object is processed by the contact application and stored as a contact, and so forth.
• As previously stated, some information is usually obtained from object as it is parsed. Thus, the user may receive this information in the prompt. For example, if a contact object is received, the user may be prompted with text that incorporates information associated with the object such as “Do you wish to add ‘FIRST-NAME-FIELD’ to your contact list?” If the object is unidentified or if the object type is unknown, the user may be prompted with text such as “Do you want to accept the file “filename.file-extension”?” If the user decides to cancel or not accept the object, the user can select a nooption274, in which case the object is simply deleted from thequeue262 without having been processed by any other application of thedevice200. The objects are usually stored in thequeue262 until they are accepted or rejected by the user.
• The prompt (270) provided to the user may also indicate how many objects are currently in thequeue262. The user may select an accept alloption276, which causes all of the objects to be processed by the relevant applications and incorporated into the data of the device and persistently stored. Alternatively, the user may select a cancel alloption278, which will cause all of the objects currently stored in thequeue262 to be deleted or discarded.
• When a user is initially notified of a received object, the notification or prompt is global and can be received or accessed from anywhere on the device. However, the user is not required to immediately accept or reject the objects that have been received. They can be stored in the queue until the user is ready to accept and/or reject the objects stored in the queue.
• FIG. 4 is a flow diagram that illustrates an example of how asynchronous object transfers are processed by a device. At400, multiple asynchronous object transfers are received at the device. However, only one incoming object transfer is processed at a time (402). Other incoming object transfers are either ignored until the current object transfer is complete or the other object transfers are rejected by the device. In another embodiment, more than one incoming object transfer is accepted. Each received object, however, is handled in similar manner thereafter by the device.
• Next, each received object is parsed (402) and certain information may be extracted to obtain more details about the object without processing the object with its associated application. In some instances, the extracted information is included in the object transfer and is not part of the actual object. As used herein, the identifying information or extracted information refers to data obtained from the object transfer and may or may not be part of the actual object, but may have been included in the object transfer.
• For example, the sender of the object is determined if possible and the object's type is also determined. Other properties, such as object size, object name, and the like can also be determined and made known to the user. Using the extracted information, the user is prompted (406) that an object has been received from “sender” and that it is a “type” of object. Other details about the received object may also be presented to the user and the present invention is not limited to identifying the sender and/or the type of the object. The information about the object presented to the user in the prompt is arbitrary and may be configured by the user in some instances. In any event, the received object is stored in a queue (408) or other temporary storage until the user determines how to handle (accept or reject, for example) the received object.
• If the user immediately responds to the prompt, then the object is processed or handled immediately and it may not be necessary to store the object in the queue. If the user does not immediately respond to the prompt, then the received object(s) are stored in the queue and they remain in the queue until they are handled or processed by the user at a later time. In one example where the user does not immediately respond to the prompt and the object is stored in the queue (408), the user will again be prompted for the objects stored in the queue after a certain amount of time or according to a pre-determined schedule. In this manner, the user is reminded that the device has received objects and that the user needs to make a decision regarding those objects.
• There is no requirement on the user that immediate action be taken with respect to the object(s) in the queue. If the queue becomes excessively large, then the user can be notified of this fact or other actions may be taken, such as refusing to receive additional objects or overwriting some of the objects that currently exist in the queue. When the user decides to process or handle the objects, then the user is prompted for each object in the queue. Thus, prompting a user with respect to one or more objects refers to prompting the user when an object is initially received and/or prompting the user for the objects that were not processed when they were initially received at the device and are currently stored in the queue.
• When the user responds to the prompt or provides a user response (410), either when prompted or at a later time, various options are presented to the user. The user can accept the object by selecting YES and the object is processed (412) by the appropriate application. The user can reject or cancel the object by selecting NO and the object is deleted from the queue (414). In both of these instances, thedevice200 will check to see if additional objects are in the queue (416). If other objects are in the queue, then the user is prompted with regard to the next object in the queue as described above. Otherwise, the user is finished and the device simply waits for new objects to be received (422).
• The user also has the option of selecting the ACCEPT ALL option with respect to the objects in the queue, in which case all of the objects in the queue are processed (420) by the appropriate applications. Similarly, the user can select the CANCEL ALL option with respect to the objects in the queue, in which case all of the objects are deleted (418) from the queue or other temporary storage. If the user accepts or rejects all of the objects, the device again waits for additional new objects to be received (422). If no action is received from the user at user response (410), then the objects remain in the queue. In effect, the user is postponing his or her response to the prompt by not responding to the initial prompt.
• Consider the following example where a user attends a meeting with five other individuals that also have a device. At the meeting, each of the individuals decides to send their contact information to the other devices. The contact information of each individual is transferred as a contact object. Thus, each device will receive five object transfers that contain contact data. These objects, as previously described, are parsed and stored in a temporary queue or other temporary storage of each device.
• Each user is then prompted about the first object. In the prompt, the user will be informed that there are 5 objects that have been received. Because the user knows that he or she just received contact data from 5 people, the user will likely select the accept all option, in which case all 5 objects are processed by the contact application of the device. If the user is informed in the prompt that 6 objects have been received, then the user will likely accept each contact object one at a time in order to perhaps receive more detailed information about the sixth object. This provides the user with the ability to either accept or reject the sixth object.
• Another aspect of the present invention refers to devices that have an established relationship or are partners. When two devices are partners, then incoming object transfers from partners are automatically accepted by the device and the user is not usually prompted about these objects. However, the user may be notified that an object was received from a partner. Often, a user can establish a partnership by entering a pin number on both devices. When an object is received, the pin number included in the incoming object transfer is compared against the pin number of the device and the object transfer is automatically processed only if the pin numbers match.
• The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (20)

1. A computer program product for use in a device that has one or more ports for receiving and transferring objects over one or more wireless networks that have different communication protocols, the computer program product comprising one or more computer-readable media having computer-executable instructions for implementing a method for managing objects received from other devices without regard to which network the objects were transferred over and without regard to the different communication protocols of the networks, and wherein the method comprises:

receiving one object at a time over each of the one or more ports of a receiving device, wherein other object transfers are ignored or are postponed until a current object transfer is completed at each port;

detecting each received object at the receiving device, wherein each received object is parsed;

generating a corresponding notification regarding the receipt of each object;

after each object has been parsed, storing each object in a temporary queue;

notifying a user of the receiving device with the notification that an object has been received via a global prompt, wherein the global prompt allows the user of the receiving device to accept a current object corresponding to the notification, reject the current object, accept all objects currently in the temporary queue, or reject all objects in the temporary queue;

persistently storing each object accepted by the user of the receiving device only upon first being accepted; and

deleting each object rejected by the user of the receiving device from the temporary queue and in such a manner that the deleted objects are deleted without being stored in persistent memory of the receiving device and without being processed by corresponding applications at the receiving device.

2. A computer program product as recited inclaim 1, wherein the global prompt is global because it is enabled to be received and accessed from anywhere on the receiving device, and such that the global prompt allows the user of the receiving device to accept a current object corresponding to the notification from anywhere on the receiving device.

3. A computer program product as defined inclaim 1, wherein detecting each received object at the device further comprises identifying a sender of each object and identifying a type of each object.

4. A computer program product as defined inclaim 2, wherein persistently storing each accepted object at the device further comprises processing each accepted object with an application associated with the type of each accepted object.

5. A receiving device in system that includes a plurality of devices that are logically interconnectable over multiple wireless networks with one or more devices that each have a different communication protocol, wherein one or more devices transfer objects to the receiving device over the wireless networks, the receiving device comprising one or more computer-readable media having computer-executable instructions for implementing a method for managing incoming object transfers received from the one or more devices without regard to the wireless network used by each of the one or more devices, and wherein the method comprises:

a step for receiving, at a receiving device, one or more object transfers from one or more devices, wherein an object is received at the receiving device in each of the one or more object transfers corresponding to one or more applications;

a step for generating a corresponding notification regarding the receipt of each object;

a step for storing each object in a temporary storage of the receiving device;

a step for prompting a user at the receiving device with the corresponding notification, that each object has been received and also providing the user at the receiving device selectable options to either accept or reject each corresponding

a step for persistently storing, at the receiving device, each object that is accepted, and such that the objects received at the receiving device are only stored in persistent memory and subsequently processed by the receiving device upon being accepted in response to the prompting; and

a step for deleting, at the receiving device, each object that is rejected by the user at the receiving device without being stored in persistent memory of the receiving device and without being processed by the corresponding one or more applications at the receiving device.

6. A receiving device as defined inclaim 5, wherein prompting the user to accept or decline each object further comprises a step for prompting the user to accept or reject all objects currently stored in the temporary storage.

7. A receiving device as defined inclaim 6, wherein prompting the user to accept or reject all objects currently stored in the temporary storage further comprises one of:

persistently storing all of the objects on the device that are currently stored in the temporary storage; and

deleting all of the objects from the temporary storage.

8. A receiving device as defined inclaim 5, wherein prompting the user includes generating a global prompt.

9. A receiving device as defined inclaim 5, wherein persistently storing each object that is accepted further comprises a step for processing each object with an associated application.

10. A receiving device as defined inclaim 5, wherein receiving one or more object transfers from one or more devices further comprises a step for parsing each object received over the one or more object transfers.

11. A receiving device as defined inclaim 10, wherein the parsing further comprises and act of extracting identifying information from each object, wherein the identifying information is presented to the user during the step for prompting the user to accept or decline each object, wherein the identifying information comprises a sender identity and an object type.

12. A receiving device as recited inclaim 5, wherein the notification is generated with information from the object transfer, rather than the object, that specifies a type of the corresponding object and a sender of the object.

13. A receiving device as recited inclaim 5, wherein the prompting includes prompting the user multiple times based on at least one of a certain amount of time and a pre-determined schedule.

14. A receiving device in a system including multiple sending devices that are able to send an object to a receiving device over one or more wireless networks using different communication protocols and wherein the receiving device is unaware of an identity of at least some of the sending devices, the receiving device comprising one or more computer-readable media having computer-executable instructions for implementing a method for the receiving device to determine which objects received from the sending devices are accepted and incorporated into the receiving device and which objects received from the sending devices are rejected, and wherein the method comprises:

receiving each object transfer at the receiving device;

after each object is received, parsing each object at the receiving device to determine identifying information, if available, about the object, wherein the identifying information comprises a sender identity and an object type;

generating a corresponding notification regarding the receipt of each object;

storing each parsed object in a queue;

prompting the user, at the receiving device, to either accept or reject each object in the queue, with the corresponding notification and selectable options, one at a time until no objects remain in the queue;

processing each accepted object, at the receiving device, with an associated application of the receiving device to incorporate each accepted object into the receiving device, only after first being accepted by the user at the receiving device in response to the prompting; and

deleting each rejected object from the queue upon being rejected, without being processed at the receiving device.

15. A receiving device as defined inclaim 14, wherein receiving each object transfer at the receiving device further comprises a step for processing only one object transfer at a time, wherein other object transfers are not processed by the device until a current object transfer is complete.

16. A receiving device as defined inclaim 14, wherein receiving each object transfer at the receiving device comprises storing each object in a temporary storage.

17. A receiving device as defined inclaim 16, wherein the method further comprises one or more of:

processing all objects in the queue if the user accepts all objects; or

deleting all objects in the queue if the user rejects all objects.

18. A receiving device as defined inclaim 14, wherein the associated application is one of a contact application, an address application, and a calendar application, and the object is one of a contact object, an address object, and a calendar object, wherein processing each accepted object with an associated application of the device further comprises one or more of:

processing contact objects with the contact application on the device;

processing address objects with the address application on the device; or

processing calendar objects with the calendar application on the device.

19. A receiving device as defined inclaim 14, wherein prompting the user to either accept or reject each object in the queue one at a time until no objects remain in the queue further comprises providing the identifying information to the user in the prompt.

20. A receiving device as defined inclaim 14, wherein prompting the user includes generating a global prompt.

Images