JP2012503449A - System and method for dynamic and automatic communication path selection, distributed device synchronization, and task delegation - Google Patents

Abstract

  Includes systems, software, and devices that provide wired and wireless telecommunications under conditions where signal strength is weak or intermittent, and particularly intermittent or unreliable communication links under such conditions Coordinate and synchronize data and workflow between various communication links and manage wireless mobile applications in such an environment. The technology of the present invention herein relates to the fields of computer science, telecommunications, and data management.

Description

[Cross-reference of related applications]
This application is a continuation-in-part of co-pending US patent application Ser. No. 11 / 169,149 filed Jun. 29, 2005, and provisional application No. 61/098 filed Sep. 22, 2008. 886 claims the benefit of 886. Each of these prior applications is incorporated herein by reference in its entirety for all purposes.

[Technical field]
The techniques herein relate particularly to systems, software, and devices that provide wired and wireless telecommunications under conditions of poor or intermittent signal strength. Exemplary, exemplary, and non-limiting techniques herein include, among other things, data and workflows between various communication links, particularly intermittent or unreliable communication links under such conditions. Coordination and synchronization and management of wireless mobile applications in such an environment. The technology herein further relates more generally to the fields of computer science, telecommunications, and data management.

[Background and Overview]
General wireless communication Wireless communication (“wireless”) allows two or more electronic devices to exchange information without requiring a physical connection (ie, wire or cable) between them. Wireless may be fixed or mobile / portable. In general, fixed wireless allows wireless communication from one fixed position to another or between a fixed position and a mobile / portable device. Mobile / portable wireless allows communication between a fixed (eg central) site and a mobile device and / or between two or more mobile / portable devices. Because the level of connectivity between two sites in a fixed wireless environment (eg, signal strength and other relevant parameters) does not move at any time, typically (weather and other conditions are constant) (Assuming that) it is fairly constant. However, the level of connectivity in mobile wireless includes, for example, the location of wireless devices, the relative location of transmitters, receivers, and / or transceivers for mobile wireless communications, and trees, buildings, mountains, or multipath or other interference. Depending on other objects or phenomena that may occur or otherwise change the propagation of the wireless signal, it can vary significantly.

  Just a few examples of mobile wireless devices (also referred to herein as wireless devices or mobile devices) include pagers, mobile phones, and mobile phone, pager, personal digital assistant (PDA) functionality Combination devices are mentioned. These devices can allow for the exchange of voice and data (eg, using cell phones and PDAs) as well as the exchange of textual information (eg, using pagers, cell phones, or PDAs). Many current wireless devices include, for example, telephony data (eg, GPRS, EDGE, etc.), wireless local area networks (LAN) (eg, Wi-Fi), and short-range device interconnects (eg, Bluetooth), Incorporates support for multiple communication interfaces. Multiple communication interfaces can optimize the use of communication paths by selecting the communication path (s) that best matches the transmission requirements and the characteristics and characteristics of the communication paths. Such optimization is not necessarily common or is done using predefined preferences provided by the device manufacturer. Devices that support only one communication interface usually cannot accommodate such optimization. Wireless devices are also recently useful, such as global positioning system (GPS) access, cameras, scanners (including scanners that can handle wireless automatic identification (RFID) and barcodes), and magnetic / optical data storage cards Integrated with features. These types of devices allowed people to stay in touch with each other from multiple remote locations while traveling or working and facilitated the collection of multiple types of data. Furthermore, the information exchanged between people has become significantly rich in recent years due to the integration of features and the consolidation of the features just described.

  Mobile wireless devices typically communicate using electromagnetic waves such as radio waves as non-limiting examples. The transmitter transmits a signal from a wireless communication point-of-presence to the wireless device, and the receiver processes the signal from the device received at the access point. The transceiver performs both transmission and reception. Under this circumstance, the access point includes one or more transmitters, receivers, and / or transceivers that can communicate with the mobile wireless device. For example, a communication tower of a mobile phone network and a wireless LAN connection in a coffee shop are non-limiting examples of access points. A central site in communication with the network of access points can control communication between the device and the appropriate access point. In some cases, the access points are spaced apart so that their service areas partially overlap to allow continuous communication as the device moves. As long as a connection is established between the access point and the mobile wireless device, information can be transmitted and received according to the capability of the device. However, in many environments, this is between the access point because there are areas that are not within range of the access point, and because land undulations, building materials, or other factors can interfere with the signal. It is impossible to maintain constant communication. As a result, pagers can go out of service for minutes or hours, mobile phone calls can be interrupted in the middle of a conversation, and data services can only partially complete communication sequences and transactions. Data may be lost. Currently, various services with various characteristics are used to connect wireless devices to each other or to connect wireless devices to non-mobile devices or the Internet.

Cellular telecommunications mobile phone companies often provide data services as well as voice call services to their subscribers. As an example of such a data service, CSD (Circuit Switched
Data, GPRS (General Packet Radio Service), EDGE (Enhanced Data rates for GSM Evolution) or EGPRS (Enhanced GPRS), as well as “next generation” systems such as UMTS (Universal Mobile Telecommunications System) It is done. Such a system operates over a wireless link to provide data connectivity between supported devices and systems such as the SMS (Short Message Service) provided by the Internet or cellular operators. The details of the implementation of each of these services vary, but are transparent to most users. The most obvious difference is the bandwidth or data rate that each provides. Depending on the system used, the data rate is currently between 9.6 kilobits / second for CSD and 16 megabits / second for UMTS. For example, the so-called 3G mobile communication standard allows simultaneous use of call and data services and data rates up to 14.0 Mbit / s on the downlink and 5.8 Mbit / s on the uplink. Faster technologies are under development. In some cases, these services are used directly by devices such as PDAs other than mobile phones, or through the use of mobile phones or other devices connected to adapter cards or as data communication devices, such as laptops Used indirectly by the device.

  Cellular data services typically support various data protocols, including TCP / IP, through cellular data networks, and often through gateways, to systems on the Internet. Such a connection is considered to be slower than the wired technology, and is also considered expensive because it is charged by the provider based on the fixed monthly fee or based on the number of transmitted data bytes. The service area of these services may be more limited than the service area of voice calls through the same mobile carrier, but is usually available along most cities and major routes between cities. In the addressing scheme (s) used for TCP / IP and the implementation method (s) often used in mobile devices, the device is often And sometimes even while connected, it is assigned a different network address ("Dynamic IP"), and the device's address is unknown and can change frequently, so it uses TCP / IP to connect to the mobile device from other devices That is sometimes difficult. In some cases, service providers can take special measures to enable such connections, such as assigning a specific fixed network address ("static IP") to the device, but this approach is generally It is often unintentional and usually involves increased costs. TCP / IP connections are therefore usually originated from mobile devices. This is because only the mobile device can recognize its current TCP / IP address and include it in the TCP / IP data packet header as required by the TCP / IP protocol. Some hot spot providers use a technique called NAT (Network Address Translation) so that all devices in the hot spot can share one IP address. In a typical implementation, the NAT will block connections from devices outside the hotspot to the device using the hotspot unless it first establishes a connection from a device within the hotspot, even if allowed However, the connection to devices in the hotspot can be limited to a specific protocol such as FTP (File Transfer Protocol). A connection is typically bi-directional once formed, and data is sent to and received from a mobile device, a server device, or another mobile device. These protocol and infrastructure limitations can prevent TCP / IP push mode connections to mobile devices and can reduce overall system responsiveness when it is desired to send data to the mobile device from a server or another mobile device. .

  Mobile devices and services that connect to mobile devices that support other data protocols such as SMS (Short Message Service) or MMS (Multimedia Messaging Service) in addition to or instead of TCP / IP There is. These protocols have advantages over TCP / IP, such as the ability to send to mobile devices using push mode, with delayed transmission, limited message size, limited content, and high cost (eg: It is considered that each message has a disadvantage of several cents (about several yen). Delivery of data is often unreliable, such as SMS and its “best attempt” delivery where delivery is attempted but not guaranteed.

Peer-to-Peer Communication When one non-server device sends data to another non-server device, the exchange is referred to as “Peer-to-Peer” (P2P). This is accomplished using various protocols and communication mechanisms such as TCP / IP, Bluetooth, SMS, Ethernet. However, some mechanisms or protocols are more problematic for this use than others. For example, the dynamic address assignment used by many mobile TCP / IP support devices results in having a different TCP / IP address each time you connect to the Internet, and other devices have no way of knowing this address, Therefore, if a connection to this device cannot be initiated and therefore a system that can connect to both devices can serve as a coordinator to supply address information to one or both devices Except for P2P connection using TCP / IP is blocked. One common way to achieve such coordination is to use Dynamic DNS (Dynamic Domain Name System), where the device registers its address with a DNS server and the address is stored elsewhere. Devices can learn and initiate communication with themselves, but because of information caching, and sometimes on mobile devices that can move from one hot spot to another hot spot in a short time Due to the sudden change of an address, this solution is often unreliable and even completely useless. In addition to the addressing issues inherent in some protocols, P2P also has device discovery and authentication issues. In some situations, a device may be asked to obtain the method or information necessary to establish communication with those other devices as well as information regarding the presence of other devices. Means for providing or obtaining this information are considered useful.

  Some devices can support connections using Bluetooth or other short-range device connections. Bluetooth can be used in areas that are blocked from technologies such as GPRS (ie, inside structures such as factories or large buildings, or underground deep underground), or in areas where Wi-Fi is not practical or desirable. Can be useful for extending connectivity. For example, if the wide range of Wi-Fi can raise security concerns, connecting portable devices through vehicle links, or devices need to exchange data, and Bluetooth peer-to-peer capabilities can do this. This is the case when restrictions on Wi-Fi TCP / IP addressing for mobile devices prevent this. Bluetooth is also often used as a link to devices that support methods such as dial-up modems, Ethernet interfaces, Token Ring Adapter, etc. for connecting to remote devices. Such links can expand communication options for Bluetooth enabled devices by functioning as the first or other link of possible communication paths.

  Bluetooth enabled devices can connect and communicate wirelessly over a wireless link through a short-range ad hoc network known as a piconet. In one standard implementation, each device can communicate with up to seven other devices in one piconet, where one device acts as the “master” and the other devices are “slave” ". Each device can also belong to several piconets at the same time. A piconet is dynamically and automatically established when a Bluetooth enabled device enters and exits the radio wave proximity area. The radio proximity area can range from 1 to 2 feet to several hundred feet depending on the class of device involved. A piconet can also be connected by a system that acts as a bridge between them. Such a configuration is known as a “scatter net”.

  Bluetooth devices are resistant to interference and use various protocols, including TCP / IP on some devices, in a way that can include data encryption and cryptographic identification of other devices. , And transfer data at a rate of 721 kbps. Not all Bluetooth devices support the same protocol, and many are special purpose devices such as headphones or barcode readers that do not support the use of nodes or other externally supplied programming. However, other Bluetooth devices are intended to function as a network interface and can support connection of a Bluetooth enabled PDA, computer, or other similar device to a LAN or the Internet. It is also possible for two or more PDAs, notebook computers, or other Bluetooth enabled devices to exchange data on a peer-to-peer basis. The specific protocols and functions of Bluetooth or other criteria that are supported by a given device are determined by the manufacturer of the device, and in some cases, at least some devices cannot be changed later.

Some Wi-Fi communication wireless devices support connection to a wireless LAN, such as those using Wi-Fi (Wireless Fidelity). Wi-Fi is a brand name of wireless technology owned by Wi-Fi Alliance for the purpose of improving the interoperability of wireless LAN products based on the IEEE 802.11 standard. The Wi-Fi Alliance is a group of individual companies that agree on a series of common interoperable products based on the IEEE 802.11 standard series. A Wi-Fi device such as a laptop, mobile phone, or PDA can connect to the network when it is in the area of a wireless network access point (WAP) connected to the LAN. If the network is connected to the Internet, the Wi-Fi device can access the Internet through a network gateway or other means. An area covered by one or more interconnected access points is called a “hot spot”. A hot spot can cover an area as small as one room, or as large as several square miles using overlapping access points. Hotspots can be used in many companies, homes, and public facilities (airports, etc.), and some areas have implemented Wi-Fi networks that cover the entire city or university campus.

  In general, Wi-Fi also allows connection in peer-to-peer (wireless ad hoc network) mode, which allows direct connection between devices, but this capability is often disabled for security reasons. . An ad hoc wireless network is advantageous, for example, when two or more devices share a network connection but do not require access to an external server or the Internet.

  Wi-Fi can support bandwidths up to several megabits / second or multi-megabits / second, and most private hotspots charge a fixed fee or are free as a means to attract customers Since access is provided, it is inexpensive or free, has a very small delay, and is highly reliable. In many or most cases, the service area is limited to a small area, and leaving the service area typically disconnects with little or no warning. In addition, as with TCP / IP on a cellular phone network, the addressing method used in the Wi-Fi hotspot makes it impossible to connect to a mobile device from a device that is not on the hotspot LAN. Usually, it must be mobile device outgoing. This can be done using Wi-Fi unless there is another contact method such as SMS used to send or request the mobile device to initiate contact with the server using Wi-Fi. Disable server outbound transmission mode when sending to device. Using this server pushable communication path to request a mobile device to initiate a connection to a server using a different communication path that is not server pushable may be referred to as a “cooperative push”. The server can use any server pushable communication path to initiate a cooperative push exchange.

Some multi-communication interface devices have the ability to support more than one communication interface. For example, some devices can support two or more interfaces simultaneously. Other devices can support different interfaces at different times. Such an implementation is usually determined by the design and configuration of the particular device. Devices that can support multiple communication interfaces typically manage the use of these interfaces in various ways. In some typical implementations, the device may automatically select which interface (s) to use at a given time using configuration settings that define user preferences. it can. In other devices, the selection of the communication interface is made manually by the user or by application software or by the design of the device or its operating system. As an example, a prior art system such as Apple Phone by Apple Computer in Cupertino, California communicates in a manner that is transparent to the application software running on the device so that it can maintain some form of communication. A device implementation capable of automatically switching an interface is provided. Other prior art systems do not transparently switch communication paths and require application software to take specific actions to switch communication interfaces when the communication interface used by the application loses connectivity There is. These actions may vary depending on the design or configuration of the mobile device, for example, trying to re-establish a connection to let the device find a communication interface with available connectivity, from among those still available Choose a new communication interface to re-establish the server connection, or take other actions familiar to those familiar with the particular device implementation. Devices that detect loss of connectivity typically do so based on the signal strength, polling, or other characteristics of the connectivity link to the closest access point, from the access point to the service provider infrastructure. It does not necessarily detect loss of connectivity that occurs in other segments of the connection, such as a failure in the connection or the connection from the service provider to the Internet. If a loss other than signal loss occurs, most devices do not necessarily fail over to an alternate interface. This can adversely affect communication between the mobile device and disparate devices or servers.

  Some devices that can support multiple communication interfaces do not necessarily switch communication interfaces until a detectable loss of connectivity occurs. Some such devices do not necessarily dynamically switch between available interfaces even if the availability of the interface connection changes. This can result in less efficient communication interfaces being used even after more efficient interfaces become available. This can lead to high costs, slow data transmission, slow responsiveness to users, and other undesirable results.

When a device changes from one communication interface to another, the change can disrupt some applications. This is most apparent when the application relies on the functionality or characteristics of the communication interface not provided by the communication interface chosen for fault bypass. For example, interactive responsiveness (the length of time from when an action requiring communication to implementation is taken until the outcome of that action appears) and the required bandwidth are examples of such characteristics. Some applications such as streaming video and database access to image data require both responsiveness and bandwidth to be functional. Different communication interfaces may have different characteristics, for example, Wi-Fi can provide sufficient bandwidth but not EDGE. When a device receiving streaming video at a Wi-Fi hotspot exits the hotspot service area and enters an area without Wi-Fi service, the device can switch to using EDGE. However, streaming video applications do not work using EDGE with the same fidelity and features as Wi-Fi. As another example, intermittent tasks such as downloading e-mail messages often do not necessarily require a lot of bandwidth. Intermittently connected e-mail applications are less likely to be confused by such changes in the communication interface, and will retry and communicate in the background to provide higher capacity or more e-mail. You can download the message. Bandwidth is usually only one of many characteristics that make a particular communication interface preferred over other communication interfaces or constrain a particular application depending on the choice of the communication interface, and some of these examples Cost, reliability, out-of-band support, transmission delay, geographic distribution, and duration of service. The ability to be aware of the available communication interfaces and their characteristics and characteristics and to select the appropriate interface for the type of data to be transmitted or received is often the most efficient of all available communication interfaces. Useful for utilization.

  Current wireless applications are often more difficult and time consuming than mobile users prefer, and can cause unexpected failures when connectivity is performed in intermittent areas. is there. The ability of a device to utilize multiple communication interfaces simultaneously or sequentially over time can mitigate the effects of this problem, but current devices usually or often do not use or efficiently utilize multiple communication interfaces. I can't.

Wireless Applications Due to the limitations imposed by current wireless protocols and the lack of built-in device support, the burden of providing reliable and efficient data transmission for wireless devices is imposed on the programmer. The programmer will have to anticipate problems associated with loss of connectivity, the efficiency of various communication interfaces related to the type of data to be transmitted, or waiting to download large blocks of data. However, such considerations are often not adequately addressed in part because many programmers are unskilled in wireless applications and due to the tight release deadlines associated with many projects. Thus, programmers may create the following wireless applications: That is, when connectivity is performed in intermittent areas, it can fail unexpectedly, use too much available bandwidth, or cost more than expected. In some cases, the available communication and storage capabilities cannot be utilized efficiently, or a wireless application is created in which the user must withstand long-term data transmission. In some cases, such problems are very serious and mobile users will not use the devices and applications at all. If a device can utilize multiple communication interfaces simultaneously or sequentially over time in a reliable and easy way, the impact of this problem can be reduced.

Another problem associated with wireless applications is synchronizing data held in the storage of the mobile device with data maintained on the server or on other devices. Some applications are created assuming that connectivity is always or almost always maintained, and such applications simply access servers or other devices from time to time for the necessary data. Some classes of mobile devices cannot frequently connect to servers or other devices, and critical applications have been disabled for most of the time. Other applications are created with the assumption that communication will be unavailable frequently, but connectivity may exist often enough that the application can communicate with the required server or other device for many times. is assumed. Such applications can cache data at the same time as it is used in order to keep it in the device's storage for short-term use where connectivity is not available. it can. This solution exposes drawbacks when the connection is unavailable for a long period of time or when the data usage pattern does not repeatedly use the same data. To reduce the impact of such outages on mobile device users, there is a better way to cache data that is likely to be needed during periods of no connectivity using periods of connectivity. It is considered useful.

  A related issue is performing updates to local cached data in environments where connectivity appears and disappears without warning. To avoid the use of stale information, the data stored on the mobile device can be peer-to-peer or other connection, either between the mobile device and the server or between two mobile devices Thus, the synchronization method is considered useful. Many ways to synchronize data accumulation include comparing blocks of data or values such as checksums calculated from blocks of data to detect differences, and then all data found to be different Transfer and reconcile these differences. Interrupts to such a process can result in the process being retried when connectivity is re-established. Depending on how the process is performed and how much data is involved, repeated transmissions can waste a large amount of bandwidth. These problems can be amplified when the number of devices that need to keep data synchronized is large and the connectivity between devices is intermittent. Possible solutions to this problem include the “Tubes” product from Adesso Systems, Boston, Massachusetts. Tubes is a network-based service that maintains a group of data on multiple devices so that changes made to the data on any device are propagated to all other devices. Since data is maintained on each device, it can be used whether or not the device has connectivity. If connectivity is lost before synchronization is complete, the software will automatically resume the task when connectivity is restored.

Those skilled in the art are familiar with the concept of mesh networking. Mesh networking utilizes one of two node connection configurations, a full mesh topology or a partial mesh topology. In the full mesh topology, the nodes are directly connected to each other. In the partial mesh topology, there are nodes that can be connected to all other nodes, and there are nodes that are connected only to counterpart nodes that exchange most data. The connection may be wired or wireless. Simply put, a mesh network is a continuous continuation by routing data, voice, and / or instructions between nodes and passing data from node to node ("hopping") until the destination node is reached. And allows reconfiguration to bypass the destruction or blocking path. In general, mesh networks differ from other networks in that all components can be connected to each other via multiple hops. Mesh networks were originally developed for military applications and have attracted great attention and experimentation because of the additional capabilities and challenges presented. As an example, Wang, which is incorporated herein by reference
See et al's Wireless Mesh Networks (Advanced Texts in Communications and Networking) (Wiley 2009) including Chapter 7 ("mobility management").

Many of the problems beyond the system for managing distributed applications are addressed in Applicant's co-pending US patent application Ser. No. 11 / 169,149, incorporated herein by reference. As a non-limiting example, the technology marketed by assignee Jumpstart provides a number of useful technologies for managing distributed applications, for example, communication between devices is unreliable and intermittent. Be able to provide a reliable method of interaction between users of different devices, even when bandwidth is limited or when resources of one or more of the devices are limited And a method of exchanging “nodes”, commands, and other data between devices. Node is a non-limiting example:
Data and / or instructions describing at least one action or at least one characteristic comprising the process and information that allows the node itself to be processed, ordered, identified, transmitted, and handled. The descriptions in the '149 application regarding the basic creation, handling, storage, transmission, structure, and processing of nodes are incorporated herein by reference.

  A node can be a collection of data having a defined configuration and variable content. These data are created, stored and transferred between devices. A node can control a device, for example, by controlling the processing of data and program instructions by the device. This technology uses text, images (both a single image and a series of images), signature information, audio encoded data, data from input devices (eg, barcodes, optical data, wireless automatic identification (RFID)) , And magnetic card scanners), information obtained from magnetic materials (eg, credit cards or identification cards), information sent to printing devices, information related to geographic location (eg, global positioning system “GPS” )), As well as other configurations can be configured to manage a variety of data types, which are given as non-limiting examples. According to one typical implementation of the technology, the management of such various data types is implemented using a defined node type, but those skilled in the art will use ordinary technology and knowledge. It can be seen that other node types are defined and implemented.

  As shown in FIG. 1, an exemplary, non-limiting implementation is a TMC device (1300a) connected to a mobile wireless device (1110) through one or more wireless networks (1200a, 1200b). (Server) is included. Nodes and commands are retrieved from the node storage (1540) of the server by the node manager (1570), transmitted over the wireless network (1200a or 1200b) through the communication interface (not shown), and the wireless mobile device communication interface (2210). 2220 or 2230). The operating system of the wireless device that manages the communication interface sends the nodes to the dispatch module (2310) of the wireless mobile device, which processes them and the node storage module (2330) where they are stored or processed. ) Or the display module (2320).

  Despite the useful technology that has been provided to the market by Jumpstart so far, wireless connectivity to a location is still intermittent, but users in the immediate vicinity can still use local wireless access. There remains a need to benefit for certain situations. For example, a construction site may include one or more trailers, and each trailer may have Wi-Fi or other communications that are available within itself but also to the immediate site. Wireless connectivity between the trailer (s) and more permanent locations (eg, central office) suffers from intermittent connectivity, but local wireless communication is essentially all If not, it can cover most sites and is accessed by workers using the devices and systems described above. In such cases, it would be beneficial to extend the service to such additional devices to provide additional capabilities.

Exemplary, exemplary, and non-limiting embodiments are not reliable, intermittent, and limited in bandwidth for communication between wireless network devices and other more robust network devices. Or a method of reliable interaction that allows a local wireless connection to be established even when the resources of one or more of the devices are limited, with a user of the first device and a second Provides systems, devices, software, and other configurations to enable the exchange of “nodes”, commands, and other data items between devices so that they can be provided to users of other devices To do.
In some embodiments, an implementation of the technology provided herein is a hosted service where wireless infrastructure, mobile devices, and various integrated servers are provided by a central facility used as needed by the user. Provided using the provider business model. Providing technology in this manner allows users to focus on their business rather than deploying and managing infrastructure components. The nature of this architecture allows multiple users from different companies to transparently share a common infrastructure without interfering with each other. Alternatively, the technology is implemented using other models familiar to those skilled in the art, such as one company owning the infrastructure and providing its employees access to the infrastructure.

  In one exemplary, exemplary, and non-limiting implementation of the technology herein, the system, software, and apparatus may vary in the availability of each communication path and the various communication paths may differ unexpectedly. One at a time (eg, sequential) or two or more at a time (eg, parallel) to allow applications to communicate in an environment with capacity, reliability, capability, and mode of operation Two or more, using one or more transmission technologies (ie, communication paths), whether they provide in-band transmission and / or provide out-of-band transmission Allows transmission of data items between devices. Data item synchronization between devices is a communication path that can be used by using one or more communication paths serially or in parallel in a state where one or more communication paths are intermittently interrupted. Implemented above, this allows data items (eg, templates, nodes, or node stacks) useful for implementing at least one aspect of the system to be communicated without loss or undetectable duplication. In order to compensate for unpredictable delays associated with some communication paths and to reduce transmission delays noticed by the user as much as possible, the data items are intentionally used by the first device using multiple communication paths. Sent. The second device detects the data item duplicated in such a transmission method, and the duplicate copy is deleted as a duplicate.

Another exemplary, exemplary, and non-limiting implementation of the techniques described herein is a second method for initiating transmission of data items between a first device and a second device. In contrast to prior art devices and systems where the device relies on polling the first device (“pull mode”), means for initiating transmission from the first device to the second device (“ Push mode "). The use of “push mode” according to exemplary exemplary implementations of the techniques herein is performed directly or indirectly in “cooperative push mode”. In a direct implementation, the first device initiates transmission and transmits the data item using the same communication path that was used to initiate the transmission. An indirect implementation in “cooperative push mode” is when the first device uses a push node to transmit a first part of the data item (s), which part (one or Can support movement of the second part of the data item (s) but lacks the characteristics required to support push mode for the entire data item or group of data items, or has high bandwidth and high reliability The second device is in pull mode to transfer the second portion of the data item (s) using the same or different transmission techniques, having other desirable characteristics such as Used by the second device as a request to initiate a communication session. In some exemplary implementations, the first device uses known information about the device type of the second device in conjunction with a database of device capability information, and the second device supports push mode. Determine whether or not there is a limit that can exist where such a capability exists. For example, some device types do not accept push mode connections while a voice call is in progress or a particular application is running. Other device types do not have such restrictions. Similarly, the push mode characteristic of the first communication path may be different from the push mode characteristic of the second communication path. For example, an SMS message may be delivered in seconds, hours after delivery, or may not be delivered at all without notification to the sender. On the other hand, TCP socket transmission succeeds or fails within a few seconds, and the transmission system is almost immediately informed about its success or failure. Exemplary and exemplary implementations of the techniques herein can use pull mode, push mode, cooperative push mode, or any combination thereof when an appropriate communication path is available. The exemplary and exemplary implementations herein can use alternative communication paths. Each of these alternative communication paths has its own specific characteristics (eg, cost, bandwidth, push mode support, transmission delay, reliability, availability, etc.). Exemplary and exemplary techniques herein include the use of one or more communication technologies at a time, appropriate switching between available communication technologies, and heterogeneous communication in search of the most suitable function. Cost, throughput by using multiple technologies, using multiple communication paths that can utilize different device communication technologies, or by other means apparent to those skilled in the art Providing a means to manage multiple communication technologies so that one or more communication characteristics for a device can be arbitrarily and dynamically optimized, such as reliability, availability, transmission delay, interactive responsiveness, etc. . These extended capabilities, for example, allow a device to switch to an alternate communication path when communication using a specific communication path is lost, or to increase overall throughput by using multiple communication paths simultaneously Can be.

  In some exemplary, exemplary, and non-limiting implementations, communication paths established by supported available communication technologies are configured to define additional mechanisms for their management and use Is done. For example, data items transmitted over a communication path are encrypted, compressed, or protected from tampering or damage through the use of checksums or other mechanisms. Such further optional mechanisms are used in part of the communication path from the first device to the second device and not in other parts, or are used throughout such communication path. Several such optional mechanisms are used simultaneously. For example, when a checksum is calculated and added to a data item, the data item and checksum are then compressed and transmitted, when the compressed data item and checksum are Encryption and decryption are performed by the communication path segment so as not to be exposed when transported over one segment.

  The transfer of data items provided by the exemplary exemplary techniques herein is wireless telephony using GPRS / EDGE, EVDO, wireless networking using 802.11 (Wi-Fi), or other radio And implemented by the device using one or more communication technologies, such as wired means. In some typical exemplary non-limiting implementations, the device is a standard computer such as a server or desktop or laptop computer, a wireless portable device such as a mobile phone or PDA, an emulated device, or Any number of these combinations.

By using the various communication methods described above, the exemplary and exemplary techniques herein are from a peer-to-peer (P2P) message exchange and a first device with or without server assistance. Delegating a task to a second device, announcing valid tasks to multiple devices, collecting responses, selecting one or more devices to which a task is assigned among those responding positively, Task assignment to selected device (s) and propagation of task completion or cancellation data items along the delegate chain and catalog data between devices with or without server intervention Flexible synchronization of items and restrictions on and restrictions on the use of data items, data items, or communication methods by devices Providing a security template to ability, and further the ability to enable such features and. The ability to manage complex node structures using an indirect client-server architecture is not a useful technology that Jumpstart has ever offered to the market, but node-based tasks, information gathering, and more Greatly expands the usefulness and applicability of devices to manage these tasks. Additional exemplary and non-limiting additional features and advantages include:
• One at a time, two or more at a time, and regardless of differences in the characteristics of each communication path, such as speed / bandwidth, reliability, cost, protocol, transmission medium, or other characteristics Using multiple communication paths for the transfer of messages from the first device to the second device. Multiple communication paths are used when a device is a server or other device when the availability of the communication path is not continuous, changes from place to place, or is made available using different means depending on time or place. Increase the likelihood that communication with the device can be established. In particular, it addresses the movement of node-based structures on the most advantageous available communication paths and extends the device capabilities to operate in various operating conditions.
A method for determining which of a plurality of available communication paths to use for a given data item at a particular time. Communication paths differ in terms of capabilities, costs, inherent restrictions based on current device location, security constraints, and / or delivery speed and guarantees, limited by the choice of forwarding nodes and catalogs. Choosing an appropriate path that is efficient enough to be used on a portable device with limited resources for a given set of nodes (with associated priority, size, type, etc.) is a challenge.
Use multiple communication paths to carry multiple copies of one or more node structures basically in parallel. Multiple communications increase the chances that a node structure sufficient to allow effective use of the node structure will be received at the destination regardless of possible disruption of the communication path, and which communication path is the fastest at that time Reduces transport delay to the same level as the fastest communication path without the need for knowledge of what is present. However, this increases the hassle of having to reconstruct the node structure by eliminating duplicate copies at the receiving device.
Using a first communication path to carry a first part of the node structure and a second communication path at least partly different from the first communication path to carry a second part of the same node structure To use. This is because the devices involved in the communication do not need to retransmit the transmitted part of the message, increase the apparent bandwidth and reduce the total time required to receive the node structure at the receiver. It is possible to switch communication paths without having to transmit parts of the node structure in parallel. Regardless of how many different communication paths were used to transmit a given node structure, the recipient recognizes parts of that given node structure, reconstructs them in the correct order, and possible node structures Ability to deal with duplicate reception of parts. This again increases the hassle of having to select the part of the node structure transmitted by each communication path.
• Optional dynamic communication path switching to increase the use of preferred communication paths over less desirable communication paths. Such switching allows the device to optimally use the available communication path when the communication path becomes available or fails. Optimal use is related to transmission speed, cost reduction, improved responsiveness to device users, increased security, or other factors. This again requires that the device be able to select the portion of the node structure that is transferred by each path.
Data items are sent by time, order, or means other than the preferred communication path (eg, sent or scheduled using MMS over GPRS instead of using TCP / IP over Wi-Fi) Out-of-band (OOB) transmission (sent between polling times). OOB transmission enables improved responsiveness to users and more timely transmission of high priority data.
Priority messaging in which the transmission method is determined in part based on the characteristics of the data item to be transmitted or part thereof. Node transmission priority determines which of the available communication paths to use, whether to dynamically switch communication paths, whether to send data OOB, and which transmission mode to send data items. It is a factor that determines what is done. Prioritizing transmission of node structures, whether in whole or in part, can allow for cost reduction, improved responsiveness in interactive tasks, and flexibility in task implementation.
-Detect and eliminate duplicate node structures, whether they occur accidentally or intentionally. Dynamic switching of communication paths can result in the recipient seeing overlapping node structures or node structure portions, and thus a way to deal with this is provided. These methods also address the possibility that an updated version of the node structure will be transmitted after transmission of an older version of the same node structure and that they may reach the receiving device in any order or at any time .
A “push mode” transmission model in which the sender contacts the receiver and initiates message transfer. This enables an “asynchronous” communication model that can reduce communication delays and improve responsiveness to device users compared to previous periodic polling, ie “pull mode” transmission models. It is also possible to reduce bandwidth usage through eliminating polling requests when there is no data to be transmitted, which can lead to cost savings coupled with some communication paths.
Send a message containing a command that requests the receiver to contact the receiver and initiate a pull mode session to transfer one or more nodes and / or node structures, "Push mode" transmission model. The sender's request and the recipient's pull mode session can occur on different communication paths. Cooperative push mode transmission enables asynchronous transmission over communication paths that do not support push mode, and is effective in accelerating transmission of critical parts of the node structure. Push mode requests can be sent OOB, can be sent at once through multiple communication paths to ensure delivery, and for transmission of one or more nodes and / or node structures Other support capabilities can be utilized. One of the difficulties in cooperative push mode scheme transmission is identifying the node and / or node structure to be moved so that the recipient can request it.
"Peer-to-two" for sending a node and / or node structure between two devices, one of which can initiate communication and one or both can transmit the node and / or node structure to the other Peer (P2P) node transmission model. This capability allows devices to interact without the requirement that each device has access to the server, allowing multiple devices to share the communication path resources of any particular device. And thus improve overall connectivity and efficiency in environments where communication connectivity is limited. The difficulty of the P2P environment is that due to the reconfiguration and subsequent use of the node structure, the node structure along multiple communication paths and topologies without the device (s) losing recognition of the unique instance of the node structure. Revolve around identifying nodes uniquely so that they can be updated as well as reports can be returned.
An “Announcement and Acceptance” (A & A) mechanism to identify one or more users who are willing to accept the assignment of one or more designated tasks and provide tasks to them. This capability depends on the broadcast capability that can transmit a node and / or node structure to multiple devices. Such a broadcast can be made using a plurality of different communication paths or communication path types, and is simulated by sending individual transmissions to each device that does not support one-to-many transmission capabilities by the communication path. can do. The A & A mechanism addresses challenges in resolving selection and acceptance of tasks represented by nodes and node structures, as well as subsequent selection, prioritization, and transmission over available communication paths, and subsequent restructuring and usage reporting activities. provide.
A task delegate method for transferring a task represented by a node or node structure from a first device to a second device with or without the aid of a server. Increases efficiency in situations where server communication cannot be established or maintained for one or both devices (when there is a communication path failure) by enabling task transfer that does not require transfer mediation by the server Is done. What is needed is a way to track task ownership in preparation for final notification to a server or other device and to limit the transfer of tasks between devices even when the server is not involved. Such a method must work regardless of the pattern in which the device-to-device or device-to-server communication path exists while the task is active. For encoding the nodes by the first device for transfer to the second device, and decoding the nodes after reception by the second device, enabling them to be functionally incorporated into the second device There is a need for further methods for this.
A task cancellation distribution method for notifying an appropriate device of task cancellation. This method supports the complexity resulting from task delegates and task delegates made between devices without server intervention. Such a method must work regardless of the pattern in which the device-to-device or device-to-server communication path exists while the task is active, often in other nodes Cancel information selection with higher priority than transmission requirements is required.
A catalog synchronization method for identifying and resolving differences between the catalog of the first device and the catalog of the second device. Such a method must support resolving differences between catalogs of devices when two or more devices are not communicating with the server and regardless of the order of updates applied to the devices. Don't be. Restrictions on the transfer of catalog data to a specific device or class of devices must be maintained even when the server is not involved and the transfer is between devices.
Providing a flexible security model that can restrict access, use, or modification to data items, data items, devices, or servers. Such restrictions apply to a first device having a communication path to a server or a third device relaying data items for a second device that does not have such a communication path. .
Even if communication between the wireless network device and other more robust network devices is unreliable, intermittent, bandwidth limited, or one of the devices or Providing a reliable interaction method between a user of a first device and a user of a second device that can establish a local wireless connection even when resources of multiple devices are limited A system to allow the exchange of “nodes”, commands, and other data items between devices.
Even if communication between the wireless network device and other more robust network devices is unreliable, intermittent, bandwidth limited, or one of the devices or Providing a reliable interaction method between a user of a first device and a user of a second device that can establish a local wireless connection even when resources of multiple devices are limited A method for enabling the exchange of “nodes”, commands, and other data items between devices.

  These and other features and advantages will be better and more fully understood by reference to the following detailed description of exemplary, non-limiting, exemplary embodiments in conjunction with the drawings.

Network overview including server devices, client devices, and network connections between them according to the techniques described in co-owned US patent application Ser. No. 11 / 169,149, incorporated herein by reference. The figure is shown. FIG. 2 shows a schematic diagram of a device and network configuration including two server devices, three mobile client devices, and a network connection between them. FIG. 6 is a flowchart illustrating exemplary, exemplary, and non-limiting push mode usage in both data item transmission and command transmission for the purpose of implementing cooperative push mode communication. FIG. 2 illustrates a typical, exemplary, non-limiting device-server interaction in cooperative push mode communication using SMS. FIG. 6 is a flowchart illustrating an exemplary, exemplary, and non-limiting implementation of a method for selecting a communication path. Exemplary, exemplary, and non-limiting devices having multiple communication paths that are reachable to various other devices through multiple communication interfaces in accordance with the exemplary, exemplary, and non-limiting techniques herein. FIG. FIG. 6 is a flowchart illustrating an exemplary, exemplary, and non-limiting implementation of processing by a protocol manager for a transmitted message. FIG. 4 is a flowchart illustrating an exemplary, exemplary, and non-limiting implementation of processing by a protocol manager for a message that is being received. FIG. 3 illustrates an exemplary, non-limiting message flow in an announcement and acceptance (A & A) process and a catalog synchronization process. FIG. 6 is a flowchart illustrating an exemplary, exemplary, and non-limiting implementation of a method for performing an A & A procedure and for addressing a lack of sufficient acknowledgment. FIG. 6 is a flowchart illustrating an exemplary, exemplary, and non-limiting implementation of a method for collecting and processing responses to A & A messages. FIG. 4 is a flowchart illustrating an exemplary, exemplary, and non-limiting implementation of a method for delegating assigned tasks from a first device to a second device (Method 1). FIG. 4 illustrates an exemplary, exemplary, non-limiting message flow for a task delegate using either Method 1 or Method 2. FIG. FIG. 6 is a flowchart illustrating an exemplary, exemplary, and non-limiting implementation of a method for delegating assigned tasks from a first device to a second device (Method 2). Fig. 2 illustrates a typical, exemplary and non-limiting security policy.

Definition of terms [OOB]: “Out Of Band”. Data item transmission that takes place over unfavorable communication paths. For example, transmission using a connectionless protocol instead of a connection-based protocol, transmission performed at a time other than the scheduled polling interval, data items with high priority sent before data items with low priority, etc. Transmission performed in an order other than the order in which data items are requested to be sent.

  Data item: A data object (eg, node, node stack, catalog, task, or combination thereof) that is required for a typical implementation to function properly.

  [Device]: A “device” as used herein, in one exemplary, non-limiting implementation, further includes at least one protocol manager and at least one communication interface (as described below). ) A computer configured to include a dispatch manager. Some typical device implementations are provided with multiple protocol managers and communication interfaces. In operation, a message is transmitted from a first device to a second device through one or more communication paths. The hardware and software configuration within the device is a characteristic of the operation of the programs and data items on the device to enable efficient message transmission between the devices even if there is no strong communication path between the devices. To control. In addition, the device may be a mobile device, such as a device that is connected using wireless technology and moves with the user, a device with a fixed location (eg, a desktop computer or server, or another mechanism such as a vending machine or pressure monitor). Embedded in a computer) or an emulated device. The mobile device can sometimes or always use a wired connection, can support a wireless connection, or both.

  [Catalog]: A set of data items having similar structures (eg, data table, parts list, job code list, cost code list, end code list).

  [Command]: an ordered array of bytes, some of which have specific values and are sent from the first device to the second device with the intent to cause the second device to take the desired action .

  [Message segment]: A fragment of a message that allows all of the fragments that make up a given message to be reconstructed into that message, and for such message fragments that are required to reconstruct a complete message. Accompanying information describing the number.

  Communication path: An implementation of a technique or combination technique that allows transmission of a message or message segment from a first device to a second device.

  [Pull mode]: A transmission model in which the receiver contacts the sender and requests message transfer.

  [Push mode]: A transmission model in which the sender contacts the receiver and starts forwarding the message.

  [Cooperative Push Mode]: A transmission model in which a sender contacts a receiver and sends a message containing a command requesting the receiver to initiate a pull mode session. Requests by the sender and pull mode sessions by the receiver can occur on different communication paths.

  [P2P]: “Peer to Peer”. Used to refer to a message transmission model between two devices, one can initiate communication and one or both can transmit messages to the other.

  [Task]: An individual unit of work to be performed on a device, defined by one or more data items.

  [LAN]: “Local Area Network”. A LAN consists of two or more devices that are located close to each other and connected by one or more networking technologies such as Ethernet, Wi-Fi, Token Ring.

[DNS]: “Domain Name System”. An Internet system that includes a distributed database that is used to translate a human readable address such as “anycompany.com” into a TCP / IP binary address that Internet software can use to transmit data items.
[Node]: As used herein, a “node” is a data item similar to a node defined by US patent application Ser. No. 11 / 169,149. Extended by including additional data fields and node types.
[Security provisions]: A rule-ordered array of bytes with some specific or limited range values, associated with a data item, data item group, device, or server, data item, data item group, communication path Used to define permissions and / or restrictions on access, use, or modification of devices, servers, or servers.

Overview Exemplary, exemplary, and non-limiting implementations provide communication systems and communication devices with significant capabilities not previously available that are listed below as non-limiting examples.
-One at a time or more than two at a time, and regardless of the characteristics of each communication path, such as speed / bandwidth, reliability, cost, protocol, transmission medium, or other characteristics Using multiple communication paths to transfer a message from a first device to a second device;
• Optional dynamic communication path switching to increase the use of preferred communication paths over less desirable communication paths.
Data items are sent by time, order, or means other than the preferred communication path (eg, sent or scheduled using MMS over GPRS instead of using TCP / IP over Wi-Fi) Out-of-band (OOB) transmission (sent between polling times).
Priority messaging in which the transmission method is determined based in part on the characteristics of the data item to be transmitted.
• Detect and eliminate duplicate messages and data items, whether duplicates are accidental or intentional.
A “push mode” transmission model in which the sender contacts the receiver and initiates message transfer.
A “cooperative push mode” transmission model in which the sender contacts the receiver and sends a message containing a command requesting the receiver to initiate a pull mode session. The sender's request and the recipient's pull mode session can occur on different communication paths.
A “peer-to-peer” (P2P) message transmission model for sending messages between two devices where one can initiate communication and one or both can send messages to the other.
An “Announcement and Acceptance” (A & A) mechanism for identifying one or more users who are willing to accept assignments for one or more designated tasks and providing tasks to them.
A task delegate method for transferring a task from a first device to a second device with or without the assistance of a server.
A task cancellation distribution method for notifying an appropriate device of task cancellation.
A catalog synchronization method for identifying and resolving differences between the catalog of the first device and the catalog of the second device.
Provide a flexible security model that allows restrictions on access, use, or modification of data items, data items, devices, or servers.

  The devices described herein include wireless devices, wired devices, emulated devices, server (TPC) devices, and other devices. Typical exemplary technical aspects include, for example, laptops and PDAs that are intermittently connected to a corporate LAN, mobile devices that may be in locations where wireless signals are not available, or reliable communication availability. It is equally applicable to any class of devices that suffer from connectivity continuity, such as fixed location devices that do not have. Also, as described herein, those skilled in the art will recognize that any number of devices can communicate with each other in accordance with the techniques herein.

Data items are transferred between devices using a communication path. The communication path may consist of any communication technology supported by the device, including, but not limited to, conventional cellular or other wireless telephony data (eg, GPRS, EDGE, EVDO, SMS), localized wireless networks ( Example: Wireless fidelity (eg Wi-Fi, 802.11x) or Bluetooth), wired data mechanism (Ethernet, PSTN, serial or parallel data cable, dial-up modem, DSL, etc.), or any combination thereof Combinations with or with additional or other protocols that have the ability to transfer messages or message segments from one device to another. The communication path includes one or more implementations of communication technologies that are used sequentially or in parallel to transfer a message or message segment from a first device to a second device. Communication paths may differ in speed / bandwidth, protocol, reliability, availability, cost, or other characteristics. Various implementations of exemplary, exemplary, and non-limiting implementations may limit or facilitate the use of specific communication paths, depending on data item type, data item size, data item priority, or security This can be done by regulatory permission or restriction, or based on any other characteristic deemed appropriate by those skilled in the art. Further explanation regarding communication paths and their use can be found below.

  A typical, exemplary, and non-limiting implementation of the technology herein is a hosted service where wireless infrastructure, mobile devices, and various integrated servers are provided by a central facility that is used as needed by the user. Provided using the provider business model. Providing technology in this manner allows users to focus on their business rather than deploying and managing infrastructure components. The nature of this architecture allows multiple users from different companies to transparently share a common infrastructure without interfering with each other. Alternatively, this technology is implemented in a traditional model where one company owns the infrastructure and provides its employees and devices with access to the infrastructure. Still other suitable models will be apparent to those skilled in the art.

  Typical, exemplary, and non-limiting implementations of the techniques herein are two or more at a time (eg, parallel use), one at a time (eg, sequential use of multiple communication paths). ) Or through communication paths that do not terminate at the server, multiple communication paths are used to enable transmission of messages or message segments between devices. The improved system also enables communication in environments where the availability of each communication path changes unexpectedly and the various communication paths have different capacities, reliability, capabilities, and operating methods. As such, it supports transmission techniques that provide in-band transmission and / or out-of-band transmission. Allows adjustment of transmission data to be synchronized between devices using available communication paths in sequence or in parallel with one or more communication paths interrupted intermittently On the communication path. This is done so that the data items and / or commands required to implement at least one aspect of the system are communicated without loss or undetected duplication. The first device is capable of compensating for unpredictable delays associated with some communication paths, or reducing the effects of message loss due to some communication paths, or transmission delays noticed by the user. In order to reduce as much as possible, or for any other purpose, a particular message can be intentionally replicated by sending it using multiple communication paths. Messages or data items replicated in such a transmission manner are detected by the second device, and these duplicate copies are deleted as duplicates.

  As shown in FIG. 2, typical, exemplary, and non-limiting implementations of current implementations of server devices (2500a, 2500b) (eg, TPC devices) and wireless mobile devices (2110a, 2110b, 2110c) include multiple Can be connected to each other. For example, server device (2500b) may connect to wireless mobile device (2110c) through a single communication path (2600c), such as a telephony-based EDGE communication path. Alternatively, the server (TPC) device (2500a) may be connected to a plurality of wireless mobile devices (2110a) through a plurality of communication paths (2600a, 2600b, 2600c) such as EDGE (2600c), Wi-Fi (2600b), and SMS (2600a). 2110b, 2110c). Further, the server (TPC) device (2500a) is connected to a plurality of wireless mobile devices (2110b, 2110c) through a single communication path (2600b). The wireless mobile device (2110c) is connected to a plurality of server (TPC) devices (2300a, 2300b) using one or a plurality of communication paths. In yet another exemplary, exemplary, and non-limiting implementation, the first wireless mobile device (2110a) uses one or more peer-to-peer (P2P) technologies and uses Bluetooth or ad hoc networking. Connected to the second wireless mobile device (2110b) through a P2P communication path (2600d) such as mode Wi-Fi. The use of available communication paths can be restricted based on a security template to control what type of data is transmitted on each path. For example, it is allowed to send a catalog of part numbers through a public shared Wi-Fi connection, but not to send employee salary data that is personal information. In such a case, the device security provisions for the Wi-Fi communication path stipulate that it has a low security level, and the security provisions for part number data and salary data indicate that they are low and high levels, respectively. It is considered that it stipulates that security is required. The part number data is considered that its security requirements match the security level of the Wi-Fi path, and therefore may be sent over the Wi-Fi path, but the salary data is Wi- It is forbidden to be transmitted over the Fi path and therefore will be held until a properly secured communication path, such as a wired Ethernet connection or an encrypted short range Bluetooth link, is available to the payroll system It is done.

  In addition to supporting multiple communication paths, exemplary exemplary non-limiting implementations of the techniques described herein allow a first device to transmit from itself to a second device. Provides a means to initiate ("push mode"). As will be appreciated by those skilled in the art, the use of “push mode” as defined and described herein allows the first device to initiate transmission using a communication path and send one or more messages. To be implemented. Upon receipt, the second device receives these transmissions and uses them to act on them (eg, “commands”) or to use them for later use (eg, as a node or catalog). To save). Alternatively, the device operates in a “cooperative push” mode. In this mode, the first device transmits the first part of the data item (s) using push mode, which uses the same or different communication paths (1 As a request for the second device to initiate "pull mode" communication to either the first device or the third device to transfer the second portion of the data item (s) Used by the device (eg, as a command or as data item (s) referring to further data items)). The selection of the communication path to use is made based on the respective communication path and one or more characteristics of the data items to be moved through them, eg, the second part of the data item (s) Can support movement but lacks the characteristics required to support push mode for the entire data item set, or has other desirable characteristics such as high bandwidth, high reliability, or low cost ( One or more communication paths may be selected. Exemplary and exemplary implementations of the techniques herein may use pull mode, push mode, cooperative push mode, or any combination thereof or multiple simultaneously when appropriate communication means are available. it can.

In some situations, it is necessary for the first device to involve and participate in the user of the second device in order to initiate push mode transmission. For example, if the second device is placed in sleep mode, or if the second device is not currently located where push mode transmission technology can function, the user can send the push mode to the second device. Any of these or other prompts apparent to those skilled in the art, invoking communication, so-called “push registries”, vibrating, producing or recording voice messages or other appropriate and available signals You are prompted to activate or reposition the second device through means such as a page or SMS message that generates a combination or the like.

  The exemplary and exemplary implementations herein also provide for the use of alternative communication paths, each with its own characteristics (eg, cost, bandwidth, push mode support, transmission delay, reliability, availability, etc.) To do. The exemplary and exemplary implementations herein use one or more communication paths at a time, switch between available communication paths as appropriate, and seek out the most appropriate function. Cost, throughput, reliability, availability, transmission delay, transmission of data items using multiple communication paths, or other means obvious to those skilled in the art, Means are provided for managing multiple communication paths so that one or more communication characteristics for a device, such as interactive responsiveness, or the like, can be optimized arbitrarily and dynamically. These extended capabilities, for example, allow a device to switch to an alternate communication path when communication using a specific communication path is lost, or to increase overall throughput by using multiple communication paths simultaneously Can be.

  A typical implementation supports a number of new connection paths and connection path topologies in addition to new methods that operate within a typical architecture. Some examples of these new technologies are described below.

  In some exemplary, exemplary, and non-limiting implementations, the communication path is configured to define additional mechanisms for its management and use. For example, data items transmitted over a communication path are protected from tampering or damage through the use of encryption, compression, checksums or other mechanisms. Such further optional mechanisms are used in part of the communication path from the first device to the second device and not in other parts, or are used throughout such communication path. Several such optional mechanisms are used simultaneously. For example, when a checksum is calculated and added to a data item, the data item and checksum are then compressed and transmitted, when the compressed data item and checksum are Encryption and decryption are performed by the communication path segment so as not to be exposed when transported over the segment. In some typical implementations, security provisions are used to determine the use of data protection mechanisms such as encryption or tamper checking. For example, when transmitting with high security, the data is encrypted and checked for tampering. When transmitting data with low security, such means are omitted to reduce computational overhead. The use of encryption, tamper checking, or other data protection methods can increase the effective security level of the communication path. For example, a public shared Wi-Fi hotspot is a low security communication path because of the possibility of data being intercepted by others, but medium or even high if the data is strongly encrypted Data requiring security can be transmitted through such a route.

  By using various available communication paths, exemplary exemplary techniques herein are facilitated by peer-to-peer (P2P) message exchange, out-of-band communication, and server (TPC) devices. A task delegate from the first device to the second device that does not depend on it, and a task assignment destination from among those responding to notifications of valid tasks, collecting responses, and notifications to a plurality of devices Or additional capabilities that allow selection of multiple devices and assignment of tasks to selected devices, synchronization of catalog data items between devices with or without server (TPC) intervention, etc. And provide functionality.

  Exemplary, exemplary, and non-limiting current implementations are implemented through any data transfer technique or combination technique (communication path) that allows transmission of blocks of digital data between devices. Some typical non-limiting examples include TCP / IP protocol over GPRS, EDGE, Wi-Fi, or Ethernet, SMS or MMS over telephony data communication paths, and Bluetooth or Wi-Fi “ad hoc” networking. Including peer-to-peer links, etc., but those skilled in the art will readily recognize that it can be replaced by other technologies, whether currently present or developed in the future .

Security Specification Example A typical implementation supports a flexible and extensible security capability with the use of a “security specification”. A security specification is an ordered array of bytes that has some specific or limited range of values and is associated with an entity such as a data item, data item group, device, or server, and access to the associated entity Used to define permissions and / or restrictions on use, or change.

  Security rules are associated with entities in various ways. For some entities, such as data items (eg, nodes), security specifications are embedded in the entity as its normal attributes. In the case of communication paths, users, or other entities such as devices / servers, the security provision is located away from the entity and allows for the discovery or identification of a name, ID, or security provision applicable to the entity. Associated with an entity by other references. Security provisions that are not embedded in the entity are stored in catalogs, BLOB nodes, external databases, files, or other locations deemed appropriate by those skilled in the art. The method used to find an externally located security policy for a given entity depends on the selected storage location and method. For example, if a security policy for an entity such as a user, device, or communication path is stored in a relational database, the security policy is stored with the entity ID as a key to the record containing the security policy, By using the entity ID, security regulations can be searched. Other storage and retrieval methods will be apparent to those skilled in the art.

Security rules are created in various ways. When security rules are embedded in an entity such as a node, the security rules are generated by a method of generating an entity, such as generated from the FDL rules for creating a node as part of the node creation process. In some exemplary implementations, the security specification is created separately from the entity, whether from the FDL specification or otherwise, and inserted into the entity in a separate step. If the security policy is created separately from the entity with which it is associated, the security policy can be created using FDL rules or by using user command line options or graphical user interface widgets (eg buttons, text fields, Scripts describing security rules in other formats such as text, XML, or SQL, using software applications that can create security rules from other inputs such as check boxes, radio buttons, drop-down lists, menus, etc. Alternatively, it can be utilized through the use of a template, or it can refer to existing security provisions, or a combination of any or all of these can be used. For example, security rules to be stored in a relational database such as MySQL can be created based on user input through a graphical user interface, and these inputs can be generated from a script that creates SQL commands from a SQL command storage template. Used to generate command line calls and the resulting SQL command is used to cause the MySQL database software to create a security specification record in the MySQL database.

  A typical security specification consists of multiple elements, including the ID of the related entity (if the security specification is not embedded in the entity), the security level specification for the related entity, the security tag held by the related entity, and the related entity Zero or more rules describing one or more tags that must be held by the second entity in order to be allowed to hold, use, modify, transfer, or perform other actions Including.

  A typical security policy is shown in FIG. The items that make up a typical security policy include an optional associated entity ID (15100), an associated entity security level (15200), an associated entity tag (15300), and zero or more actions / rules. It includes an optional action / rule combination section (15400) containing pairs (15405/15410, 15415/15420, 15425/15430).

  The related entity ID (15100) is present in a security rule stored separately from the related entity, and is optionally present in the security rule embedded in the related entity. The related entity ID (15100) is used to identify the entity associated with a particular security policy instance. The related entity ID (15100) may include a device or server ID, a communication path designation, a user name or login ID, a node ID, a catalog ID, or other entity identifier that may be deemed useful by those skilled in the art. it can.

  The related entity security level (15200) is a general security classification for grouping security rules, regardless of the details of the security rules as described by the related entity tags (15300) or action / rule pairs (15400). Is specified. In some exemplary exemplary implementations, the related entity security level (15200) is a number that indicates a higher security level with a higher value and a lower security level with a lower value. In other exemplary exemplary implementations, the related entity security level (15200) indicates that one of the indicators indicates a high security level, such as “high”, “medium”, “low”, and any other indicator. Is a fixed security level index group that assumes a hierarchy indicating a low security level. Regardless of the implementation chosen, a security policy with a higher security level is considered compatible with a security policy with a lower security level when the receiving entity has that higher security level. However, this is not considered when the receiving entity has a low security level. These constraints allow data to move to a safer entity or take a safer communication path than required by its security regulations, but to move to a less secure entity or to a less secure communication path. Guarantee that you cannot pass. In order for data to be transferred, the sending entity, the receiving entity, the communication path used, and all security regulations for the transferred data must be met.

The related entity tag (15300) is used to define finer security permissions than provided by the related entity security level (15200) item. The related entity tag (15300) includes zero or more “tags”. A tag is a number, letter, or other data object that has a specific meaning when backed by a typical implementation. Any number and type of tags can be included in the related entity tag (15300) item of the security provision. These are used to provide a specific set of permissions or constraints to related entities when combined with the second security stipulated action / rule pair (15400), as described below.

  A security policy may include zero or more action / rule pairs (15400). The rules (15410, 15420, 15430) in the security provisions of the first entity allow the second entity to be compatible with the first entity for the purpose of performing the specified action (15405, 15415, 15425) In order to be considered, it is used to define an associated entity tag (15300) that must or cannot be included in the security specification of the second entity. Actions (15405, 15415, 15425) include various numbers, characters, or other data objects that have specific meanings in the context of a typical, exemplary, non-limiting implementation, Used to specify actions (keep specific data items, transfer data items to another device, execute nodes, update catalog on device, etc.). The set of specific actions that can be specified depends on the implementation. The rule (15410, 15420, 15430) is one that must or must not be in the related entity tag (15300) of the second entity in order for the second entity to be compatible with the first entity. Or, specify a plurality of tags. A rule is a Boolean expression that allows arbitrarily specifying a combination of tags or lack of tags in a manner well known to those skilled in the art. For example, in order for a second entity to be compatible with the purpose of performing a related action, such as a warning that machine maintenance is required, the second entity may include a “MAINTENANCE” tag and a “MANAGER” tag. A rule can specify that the "DIRECTOR" tag must be retained but not retained. Such a rule would prevent such warnings from being sent to the maintenance director, but would allow it to be sent to another manager in the maintenance department, For example, the administrator can create a task and assign it to a worker to repair the machine.

  Action / rule pairs (15400) and related entity tags (15300) that drive the evaluation of rules are only checked if the related entity security level is compatible. They cannot be used to overturn the conformance constraints specified by the assigned security level. These can be used to provide fine conformance management within a conformable security level relationship, for example, when an administrator receives data about an employee under his supervision from a talent system Allow but not allow the same manager to receive data about employees who are not under his / her supervision, or allow workers to cancel certain tasks assigned to them but not cancel other tasks Do not allow. By carefully using security level assignments and tags and action / rule pairs for various entities, it is possible to establish any pattern of data movement and use, methods of data movement, and constraints on the movement or use of data. it can.

Examples of Communication Methods In addition to pull mode operation supported by typical prior art devices, a typical device can support push mode, cooperative push mode, out-of-band transmission, and communication path switching.

[Peer-to-peer communication]
As mentioned above, peer-to-peer (P2P) communication involves a direct connection between two or more devices without the need to enable communication by a server or other device. There are multiple technologies that can support this mode of connection, such as Bluetooth or Wi-Fi in "ad hoc" mode. In some embodiments, P2P can be used between devices without having to connect to a server, such as allowing a first device to send data items representing a piece of work to a second device. Used to enable transmission of messages and message segments. This is advantageous in many ways, such as to allow supervisors to assign tasks to subordinates or for workers to deliver tasks to colleagues.

  P2P communication is also advantageous because devices with available communication paths to the server device function as a “data item cache” for mobile devices that do not have such connectivity. For example, a data item is transmitted to a first device having a high-speed connection path, such as a wired Ethernet connection, and a second device or other device that does not have connectivity to the server due to environmental factors such as location or signal shielding. Hold for. The second device or other device may receive the first by means of P2P technology, such as Bluetooth or Wi-Fi in “ad hoc” mode, for the transfer of their data items to the second device or other device. Can be connected to any device. Data items that must be transmitted from the second device or other devices to the server device are transmitted to the first device. The first device forwards the data items to the server via another communication path or other connection as deemed appropriate, such as by the method described below.

  When communication is initiated between devices using P2P, the devices must have a way to recognize and discover each other. In some typical implementations, this is accomplished by distributing information to devices in the form of a catalog. Catalog containing Bluetooth known device ID, ad hoc Wi-Fi network name and address, and device authentication material as well as other information useful for discovery, connection, and authentication between devices using P2P communication methods Are distributed and updated by the server and stored on the device until needed. Alternatively, when the first device recognizes a communication path such as an ad hoc Wi-Fi network or a Bluetooth device, the user of the first device may permit the use of the communication path or such a path. Authentication material (eg, username, etc.) required to specify characteristics for assignment (eg, weighting factor used to dynamically select a communication path) or to use the above communication path You may be prompted to provide a password or credit card number. Security provisions for communication paths are often supplied by the server. When properly privileged security rules are associated with the user, the user can also provide security policy information for the communication path or other entity.

[Push mode and cooperative push mode]
As shown in the flowchart of FIG. 3, push mode is used to both send data items and send commands so that cooperative push mode communication can be implemented. The exemplary procedure described includes sending data items to an exemplary device that can receive SMS messages and that can establish a Wi-Fi link when located at a Wi-Fi hotspot. . A typical device is not located at a Wi-Fi hotspot when a data item must be sent, its IP address is unknown to the sender, or a firewall, router, Or there are other components.

In one embodiment, the first step in transmitting the data item to the device is determining 3010 the characteristics of the transmitted data item. SMS has very limited bandwidth and message size limitations, which may require dividing a large transmission into a series of segments and sending each segment in a separate SMS message. is there. Since SMS can vary in cost depending on the number of messages sent, it is often desirable to limit the number of data items sent using SMS.

  If the data item to be sent is small enough to fit in one SMS message, or if it is determined that it should be sent using SMS for other reasons (3020), One or more SMS messages containing data items are constructed (3030) and sent to the device (3040), completing the process.

  If it is determined that the data item to be transmitted is not suitable for transmission using SMS (3020), the cooperative push mode is used instead of the push mode, and a communication request command (described later) is issued. Constructed and placed in an SMS message (3050), which is then sent to the device (3040) to complete the process. In the latter case, the actual data item is transmitted when the device responds to the communication request command and performs a pull mode communication session. This is outlined in FIG. 4 (4100), where a communication request message is sent from the server to the device (4110). The device responds by establishing a pull mode connection on an appropriate communication path, such as Wi-Fi (4120), and the server uses this communication path to send a wait data item to the device (4130). As will be apparent to those skilled in the art, the use of SMS to carry communication request commands is exemplary only and can be replaced with any communication path that allows a push mode to the device. For example, there are MMS messages, existing P2P connections or Wi-Fi connections, TCP / IP on any available interface (eg TCP packets through socket connections, UDP packets, IPv6 or IPv4 or other Wi-Fi Multicast or broadcast packets using the above protocol, Bluetooth link to the wired Ethernet interface, dial-up modem using SLIP, PPP or other protocols).

  As with any form of communication, the first device (whether it is a server, mobile device, or other device) has information to know how to contact the second device. Must have. In some exemplary implementations, the first is either by the device's own user or by the server device periodically updating with the latest address and other required data items using a catalog or other means. Are configured to have required data regarding the address of the second device, supported communication paths, and the like. In other exemplary implementations, the first device broadcasts a request from a known service, such as Lightweight Directory Access Protocol (LDAP) or Domain Name System (DNS), or similar to ARP (Address Resolution Protocol). The required information about the second device is obtained by receiving a response from the second device or a different device. In some typical implementations, the address and other required information is provided to the server manually through an operator entering data items, while in other typical implementations the device is Using methods such as dynamic DNS (DNS), catalog updates, or other methods deemed to be valid by those skilled in the art, the server is automatically kept up to date with respect to its address and other required information. Update to To determine the address or other required information about disparate devices, such as using DNS to determine TCP / IP addresses and using a stored catalog for SMS addressing information Multiple information sources can be used.

[Out-of-band transmission (OOB)]
Multi-communication path capability provides further opportunities for out-of-band (OOB) transmission. In out-of-band transmission, data items are exchanged over communication paths other than the preferred path or at times other than scheduled polling periods or periodic contacts. In some embodiments, OOB is used to provide high priority transmission. High-priority transmission, for example, emergency alerts, software or data item updates, task coordination between users, or devices connect at the next polling interval or users use the next preferred communication path service For example, you should not wait to go to a possible access point.

  In other embodiments, OOB is also used to implement push mode transfers where the server initiates a connection to the client. Because of inherent design limitations, not all communication paths allow the use of push mode, and some of these communication paths are preferred or primarily used because of their high bandwidth. There is a tendency (eg, Wi-Fi, wired Ethernet, etc.). In this scene, a command requesting an immediate pull mode connection is OOB transmitted through a communication path permitting the push mode (eg, SMS or MMS). The receiving device then initiates a pull mode session and the server transfers the required data items over the preferred connection selected as described above. In some typical implementations, the application software may request the user to enable such a connection, such as by moving to a hotspot, connecting to a wired Ethernet port, etc. when possible. Can do.

  As will be appreciated by those skilled in the art, the OOB enabled by a typical, exemplary, non-limiting implementation has limited capacity for a device to connect through a preferred communication path. It is useful in situations where it is connected in a way that uses up its capacity, but it must receive a high priority message from another device that is not currently connected. For example, if a device is limited to one Bluetooth connection at a time and is currently connected to a server and exchanging messages, a second server with a high priority message for that device You will not be able to connect to the device through Bluetooth to send In this scene, the server can send messages OOB using SMS or MMS, thus avoiding the limitations of Bluetooth connections.

  Some communication paths are not capable of push mode transmission due to their design and their common implementation. For example, the Internet uses the TCP / IP protocol, which requires that the connecting device specifies the network address of the connected device. Server devices usually have a fixed address that is known or learned by other devices through a system such as DNS (Domain Name System), which means that other devices connect to the server. Makes it possible to start. Non-server devices, including most mobile devices, are usually not given a fixed address and are temporarily (if necessary) (such as through Dynamic Host Configuration Protocol) when connected to the network. Request a valid address. Thus, such a device cannot receive a connection because its address is not known, but can itself connect to a server device or other device having a known address. Communication paths that can be connected to any device can support push mode transmission, and as mentioned above, even communication paths with limited capacity do not themselves support push mode, but are more capable. It can be used in push mode to request another device to initiate a pull mode session over the communication path.

[Configuration of communication path]
To enable the use of communication paths by devices that use P2P technology or certain private Wi-Fi hotspots, etc., devices that use such communication paths can use any addressing, device ID, encryption Must be configured with keys, authentication information, or other data required for discovery, connection, and establishment of reliable communication between devices over the communication path. Such configuration information may be included in the device by the device manufacturer, added by the user of the device, transmitted from the server device (eg, as a configuration message or catalog data item), or the specific communication technology used Standard qualities, or any combination of these. Updates to the configuration information can be made by the user of the device, transmitted from the server device, standard on the specific communication technology used, or a combination thereof. For example, in the case of Bluetooth P2P communication, the establishment of a Bluetooth piconet means that devices participating in the piconet calculate the radio frequency change pattern used by the members of the piconet and maintain contact with those members. With the exchange of information to enable. Such information exchange is a standard part of the Bluetooth technology protocol. In another example, devices subscribing to an “ad hoc” Wi-Fi network can identify network other members of the network and allow network name data to allow communication with those members (eg, “ SSID ") and access information (eg" WAP key "). Such information must be provided to the device by means other than an “ad hoc” Wi-Fi network, such as a user entering information into the device configuration or a server sending configuration information to the device. In non-P2P scenes, such as using a private Wi-Fi hotspot, the configuration information can consist of account login and password values, or other forms of identification and authentication, or in the case of SMS, contact It can consist of phone numbers of different devices to power.

  A typical, non-limiting example of a method for collecting and distributing network access information such as Wi-Fi SSID and related authentication material is to store such information in a catalog and store the catalog in a specific network access To distribute to all devices to which access is granted. For example, a mobile device may include a wireless set that includes a set of SSIDs and associated access keys (eg, WAP keys, account / password pairs) that can be used by a session manager to establish a connection using a particular connection technology. A catalog of connection information supporting “hot spots” can be received. Different communication technologies can have different catalogs (eg, one catalog per technology), or one catalog can contain information about multiple communication technologies. Users can also have different catalog (s) provided to their devices depending on the access rights and connectivity granted to a particular user / device. In one implementation, these communication technology catalogs are maintained on a common server (TPC) device and distributed to mobile devices as needed. Distribution and caching of these catalogs prior to use allows the content of these catalogs to be used when the mobile device is in the region, allowing seamless migration of devices between supported communication paths To. Alternatively, when a device is identified as being active at a particular location, it can query a common server device for a catalog of that technology. The response to the query is for the server device to send to the requesting device one or more catalogs, or one or more data items that form part of the one or more catalogs.

In an alternative typical non-limiting example, the catalog distribution mechanism is used to distribute known device IDs, user IDs, and known device and user authorization materials. When the mobile device identifies a second mobile device on the peer-to-peer network or on another network that does not rely on a connection to the server device, the device ID and Approved materials can be used. For example, if Fred's device has device ID 1 and the required authentication string “secret”, Sue's device authenticates the catalog element that identifies Fred, namely Fred's device ID (eg, 1) and authentication. A catalog containing material (eg, “secret”) can be received. Fred will receive the same (or different) copy identifying Sue, ie Sue's device ID (eg, 2) and the required authentication material (eg, “Sue's Secret”). In recognizing a device on the network as device 2, Fred's device searches for a user (Sue) and determines whether there is a message to send to the Sue device. If so, Fred's device uses the authentication material so that both endpoints can guarantee that the other device is authentic and authorized to initiate the connection. A communication path can be created between the device and the Sue device. In some alternative embodiments, only the user, device, and authentication material elements selected from the catalog are transferred to the particular device. By limiting the catalog elements that are distributed to the device, the distributed catalog element is used as an authorization form for the first device to connect to the second device. Connection attempts when both devices do not have both a catalog element for themselves and for the connected device fail due to the lack of authentication material. This technology is advantageous for peer-to-peer connections such as those created using Bluetooth or ad hoc Wi-Fi. Security provisions can be used to further limit the communication paths that can be used to transmit data between devices independently of the type of data, specific data items, or authentication methods just described. For example, even after Fred's device and Sue's device have exchanged secrets and recognized each other, Sue's device still remains associated with the communication path between devices, either due to a lack of matching security regulatory requirements between devices. Because of the level of security provided, it may be prohibited to send certain data, such as profit rate data or salary information, having a high security level or restricted to certain recipients, to a Fred device.

  In addition to connection and access configuration, each communication path identifies the characteristics (speed, cost, reliability, etc.) of each communication path and the functions supported by each communication path (such as push mode or large message size). Additional information or settings, or preference settings used to determine which communication path to use under conditions of various availability, data item priority, or other factors, or as appropriate by those skilled in the art It is also configured with other communication path configurations that are considered to be.

  When the mobile device is operating using a temporary communication address, such as an IP address assigned using a Wi-Fi access point, the current communication address is the same as the current communication address of the heterogeneous device. Is required to contact the first mobile device using. In one embodiment, the server (TPC) device updates the catalog of device communication addresses upon receipt of a message from the mobile device. The updated catalog element (s) is distributed to other devices as needed. Alternatively, in establishing a connection to a communication technology that assigns a temporary communication address, the mobile device updates its catalog element stored on the device, and then transmits the catalog element to the server device (or destination). Any other device). This means that two devices establish a low-bandwidth connection using a peer-to-peer communication path and exchange temporary communication addresses for the currently connected high-bandwidth network And then establish a high bandwidth communication path between the devices. In yet another embodiment, the mobile device can update the central service using a standard dynamic addressing protocol such as DDNS when receiving a temporary communication address. This eliminates the need to synchronize catalog elements with temporary communication addresses, but limits the available communication paths to those that are resolved using standard dynamic addressing protocols.

[Switch communication path]
As described above, all communication paths are subject to connectivity disruptions and losses. Loss of connectivity can occur at multiple points along the path. The device may suffer from failure of its communication hardware, loss of connection may occur at the signal level (eg when leaving a Wi-Fi hotspot), or part of the communication infrastructure may be unavailable (eg mobile Service disruption at telephone companies, suspension of internet connectivity, SMS server overload, etc., and the server with which the device communicates may become unusable (eg, power failure, system maintenance, software) Error). Loss of connectivity on one communication path does not necessarily mean that all communication paths for that device will be unavailable. When there are multiple available communication paths and one or more of them become unusable for any reason, the device may have the option of switching to a communication path that maintains availability. The device also loses connectivity so that it can optimize the use of available communication paths and improve attributes such as speed, reliability, or responsiveness or reduce attributes such as cost or delay. The communication path can be switched without accompanying. The device will only be in the event of a failure, or periodically on a basis that is changed or hardcoded in settings, or when a new communication path becomes available, or any combination of these Alternatively, other options deemed appropriate by those skilled in the art can reevaluate their use of available communication paths.

  Some typical devices support automatic selection of communication paths. Here, the communication path is switched without an action on the user side, and in some implementations, the communication path is switched without an action on the application software side. Such a typical device is designed so that the operating system of the device selects the communication path, the application software always uses the currently selected communication path, and changes the communication path according to the instructions of the device. Is done. Such switching is transparent to the user or application software in some exemplary implementations and can be detected by the user or application software in other implementations.

  In other typical devices, the communication path used by default is determined by the operating system of the device, but the application software can override it and route the alternative communication path through the use of mechanisms supplied by the manufacturer to the operating system. It is possible to use.

  For example, in some implementations, the switch is made as a failover response to a loss of connectivity on an existing communication path, or the switch is preferably a different communication path than the currently used communication path. It is done at any time when it is judged (route optimization). In some situations where the communication path failure is not due to a local factor in the device, it may be necessary for the device to automatically switch to another communication path to be pushed by the application. For example, if the device uses a Wi-Fi communication path and access to the address of the server to which the device is connected is blocked as a result of changes to the Wi-Fi configuration of the hotspot firewall, Despite the fact that the device can still detect the Wi-Fi signal and send and receive TCP / IP packets, it cannot reach the server using the Wi-Fi connection. Does not automatically switch to the communication path. In such a situation, the application software of the device can re-establish communication with the server by promoting switching to another communication path such as GPRS or EDGE.

In some embodiments, a method for switching a communication path as a result of a communication path failure involves several stages. First, connectivity loss is detected. Second, an alternative communication path is selected. Third, connectivity is established through the new communication path. In a more specific embodiment, when route optimization is used, the device performs the second step of this process to select one or more communication paths, if (1 If the selected route (s) is different from the currently preferred route (s), the device may prefer the chosen route (s) as currently preferred. The switching of the communication path is started so that the path (one or a plurality of paths) can be made.

  As will be appreciated by those skilled in the art, connection loss detection can be easy or difficult depending on the communication path. For example, when using a connection-oriented protocol, such as a TCP packet on a TCP / IP communication path, whether this is done using Wi-Fi, Bluetooth, or some other means, the packet is destined for the destination system. An acknowledgment is returned when received by, and if no acknowledgment is received after repeated retransmissions, it means a loss of connection. In this case, the loss of connection can be detected regardless of where the fault occurred along the route. For other protocols such as UDP packets over TCP / IP and SMS, acknowledgments are not included as part of the transmission protocol, and if the problem is not local to the device, the application level protocol is used to detect communication problems. Detection is not possible unless some form of feedback is included. For example, if UDP or SMS is used to send a message from the server to the client, the client acknowledges the arrival of the message by returning a UDP or SMS message to the server when the message is received. Can do. If the message is lost during the move, there is no acknowledgment packet and the server will send the message after an appropriate time determined by an appropriate mechanism such as a clock chip, loop counter, or programmable interrupt function. Can be resent. If an acknowledgment packet is lost during the move, the server resends the message and the client can receive a further copy and acknowledge it again. This continues until a message is received and the server gets an acknowledgment to receive the message, or until enough attempts have failed to consider the connection unavailable. Duplicate messages and nodes are detected and ignored by means described below. When it is determined that the communication path is unusable, failover path switching is performed if an appropriate alternative communication path is available.

  Even if the protocol includes a feedback mechanism indicating success or failure of delivery, there is a delay before a loss of connection is detected. In the case of a TCP connection, this can take several minutes before a lost connection is detected, and retransmissions are tried many times before it is determined that the connection is not available. Device hardware problems or signal loss, at least in some cases, can be detected by the device operating system and reported to the application, regardless of the protocol used. Connection, either through error reporting by the hardware or device operating system, or through the passage of time without an acknowledgment being received, or by some other means commonly done by those skilled in the art Sexual loss is ultimately recognized.

  When a loss of connectivity occurs, the device may hold the data item waiting to be sent until connectivity is restored and switch to another communication path that has or may have connectivity. Also good. The device can do both. That is, some data items may be retained for later transmission, and other data items may be transmitted through a communication path having connectivity. The decision as to whether the data item is retained for later transmission attempts or transmitted over an alternative communication path is determined by the priority of the data item, the cost of the alternative communication path, the capacity of the alternative communication path, or one skilled in the art. This is based on factors such as other factors that are deemed appropriate.

The device may also be selected for use in some exemplary implementations, such as when a preferred communication path becomes available, or the priority of the data item to be transmitted. When the use of a communication path that will not be performed is permitted, the communication path is switched in anticipation of the current communication path without loss of availability. For example, if a device is connected by a communication path that uses GPRS because it was the most preferred available communication path when the connection was established, the user would connect the device to the more preferred Wi-Fi. When a communication path, such as a hotspot, is moved to an available area, the device establishes a new connection through the more preferred communication path, and the less desirable path, even if it is still available. Even if it exists, it can be terminated. This is done for cost reduction, speed or reliability improvement, or any other reason. In another exemplary embodiment, if data items are waiting to be transmitted for an excessive amount of time (eg, determined by configuration settings), the priority of these data items is increased. As a result of the new priority value for the waiting data item, an alternative communication path that was not initially selected is selected and switching to that communication path is enabled to allow transmission of the waiting data item. Made.

  In cases where there is no acceptable communication path based on the configuration of the device, the priority of the data item to be transmitted is changed, the communication path configuration setting of the device is changed, the communication path or transmission is performed when there is no communication path available. Due to changes in security regulations associated with data items to be made, or other changes that allow previously unacceptable communication paths, the device can make a new allowance without switching from a different communication path. It is possible to use possible communication paths.

  Similar factors are involved in selecting which communication path to switch to, whether in failover mode or for route optimization. The device can have a built-in priority system used to choose an alternative communication path, or various factors (non-limiting examples include cost, speed, reliability, user preferences, supported Can be done dynamically using rules to balance features (such as push mode), or the number and type of data items to be transferred, or ask the user to make a choice be able to. The determination is made by the device operating system in some exemplary implementations, and is left to application software in other exemplary implementations. In an implementation in which the device operating system determines the communication path, it is possible to change the device configuration settings to invalidate the communication path that is preferred by the operating system and to promote the use of a specific communication path. is there.

  In one possible typical implementation, each communication path characteristic such as cost, speed, and reliability is assigned a selection priority adjustment value. The selection priority adjustment value is large for an important factor, small for an unimportant factor, and a zero adjustment value is assigned to an unrelated factor. By adding the adjustment values, the selection priority score for each available communication path is calculated, the adjustment value for the desired characteristic is treated as positive, the adjustment value for the undesirable characteristic is treated as negative, and the highest selection priority. A communication path (one or more) having a score is selected for use. By appropriate selection of the selection priority score adjustment value well known to those skilled in the art, the selected communication path will have a selection of a given communication path to proceed if the path is available, or In order to prevent the use of a communication path, or to prevent the use of a predetermined communication path except when there is no alternative path, control is performed so that the influence of any characteristic or feature can be maximized or minimized. In some typical implementations, pushes that do not support the required capabilities have a separate initial calculation to compare the capability or characteristic requirements of the impending transmission channel with the capability of the available channel. Communication paths such as modes are excluded from consideration before the selection priority score is calculated.

One exemplary process for selecting the communication path (s) for use is shown in the flowchart of FIG. The process begins by building a list listing all currently available communication paths (5000). For some typical devices, this consists of all communication paths supported by the device, such as SMS, EDGE, and Wi-Fi. In other typical devices, it is possible to determine whether an interface is detecting a signal and to exclude communication paths that use an interface that is not currently receiving a signal (eg, telephony). If the data interface has no signal, neither the SMS communication path nor the EDGE communication path is available). Some typical devices may test the connectivity of a communication path, such as by sending an ICMP “echo” packet (“ping”) to a known TCP / IP address via Wi-Fi and waiting for a response. Is possible. As described above, connectivity may be present in one part of a communication path but not in the other part, preventing use of that communication path. For example, detection of a response to a Wi-Fi signal and “ping” sent to a service provider does not mean that the server or other device is reachable via Wi-Fi. In creating the list of currently available communication paths, the device includes substantially all of the paths that cannot be reliably determined to be unavailable. For this purpose, the device can maintain a list of communication paths that have recently been determined by the device as unavailable due to lack of acknowledgment for previously transmitted data items. This avoids a preferred communication path that appears to be available by the presence of a signal, a “ping” reply, or other means but fails to transfer the data item in the recent past (here The “proximity past” is a period determined by the configuration setting or incorporated in the device or application software by design). Such exclusion of communication paths from consideration makes it possible to select communication paths that may be less useful but may be more useful.

  Communication paths that do not retain the required security characteristics required to be useful for transmission of standby data are considered unavailable for communication path selection purposes. When the purpose of route selection is to perform a pull mode session (eg polling the server for waiting data or messages), the security specification property is not used to exclude communication routes, In a typical implementation, it is used to treat some communication paths as preferred over other communication paths (eg, a higher security level path is preferable to a lower security level path).

  If an available communication path is not included in the list (5010), the process ends with a result of "no available path" (5020). In this case, the device cannot communicate at the present time and the current location. Some exemplary devices can alert the user to this situation so that the user can move the device to a location where additional communication paths are available. A typical device can also periodically repeat the selection process until an available communication path appears.

  If the list of available communication paths includes at least one communication path, the next step in the selection process is to remove all communication paths that do not support all the required capabilities from the list (5030). ). For example, if push mode transmission is required, any communication path that does not support push mode is excluded from the list of available communication paths. When such communication path exclusion is complete, it is rechecked (5040) whether the list includes at least one communication path. If not, the process ends with a result of “no route available” (5020). As a result of excluding communication paths lacking the required capacity, just the required number (this is usually one, but some typical devices may use more than one communication path at a time. Therefore, the list of paths may be returned and the process is complete.

If the list of available communication paths includes a larger number of available communication paths than required, it is necessary to select the most preferable path (one or more) from the list. In an exemplary embodiment, each path in the list is given an initial selection priority value of zero. The selection priority value for each path is then adjusted downward (5070) for each undesirable characteristic associated with the path by an amount determined by configuration settings for that characteristic. For example, if low bandwidth is considered undesirable and has an adjustment value of 3, the selection priority value is reduced by 3 for all communication paths in the list that have the characteristic of low bandwidth. The selection priority value is a signed number and may be negative. Such a reduction in selection priority is due to unreliable communication paths with low bandwidth (eg, if both low bandwidth and unreliable with adjustment values of 3 and 5 respectively are considered undesirable) : SMS) is also cumulative in the sense that its selection priority value is reduced by 8.

  The selection priority value is then adjusted up (5080) for each desired characteristic associated with the path by an amount determined by configuration settings for that characteristic. For example, if low cost is considered desirable and has an adjustment value of 6, the selection priority value is increased by 6 for all communication paths in the list that have the property of low cost. Such an increase in selection priority can be attributed to a communication path having a low cost and a high bandwidth (eg, Wi−) if both low cost and high bandwidth with adjustment values of 6 and 4 are considered desirable, respectively. Fi) is also cumulative in the sense that its selection priority value is increased by 10.

  The selection priority adjustment just described as an alternative, as will be apparent to those skilled in the art, is implemented as a step in some exemplary implementations using signed adjustment values.

  When the selection priority adjustment is complete, the communication path (s) with the highest selection priority value is selected (5090) and returned (5060), and the process is complete.

  Selection of characteristics to be included in the configuration, assignment of characteristics for each communication method supported by a given device, and priority increase and decrease values selected for each characteristic are preferences for communication paths under various circumstances. Can be used to adjust as much as you need. As an example of a typical scene, a device capable of supporting three communication methods: GPRS, Wi-Fi, and Bluetooth can use both GPRS (both TCP / IP and SMS protocols) and Wi-Fi. However, Bluetooth may be located in public Wi-Fi hotspots in major cities that are not available. The user has configured the device settings to prefer high bandwidth (−10, +3), low transmission delay (−1, +5), and low cost (−1, +1), which is the communication path Means that the priority is reduced by 10 if it has a low bandwidth, and if it has a high bandwidth, the priority is increased by 3 and a similar adjustment is made for transmission delay and cost. GPRS-TCP / IP is configured to have low bandwidth, low transmission delay, and high cost. GPRS-SMS is configured as having low bandwidth, high transmission delay, and high cost. Wi-Fi is configured as having high bandwidth, low transmission delay, and low cost. Since Bluetooth is not available, its configuration is irrelevant. Since both available communication paths have the same security regulatory characteristics, this is not a relevant factor for making a decision between them. The device does not currently require push mode, so the lack of support for this capability is also irrelevant. The calculation gave the following scores for each method: GPRS-TCP / IP (-6), GPRS-SMS (-12), and Wi-Fi (+9). A Wi-Fi communication path is selected for use.

In another possible implementation, the total number of preference points for a communication path must exceed the specified total number for that communication path to be used, and the number of data items to be transmitted The priority or time elapsed since the last connection is added to the total score as another factor. In this way there is a sufficient need (e.g. high priority data items are waiting or need to be polled for updates within a given time) and there is a better available communication path If not, a communication path that is too expensive to use under normal circumstances is selected for use. In some typical implementations, the data item priority may vary depending on the type of data item. For example, a user's response to a request may be given a very high priority, as is an emergency alert notification, while a request or pre-determined node group is used to preempt image data items. A request to check if it has a possible update is considered to be given a lower priority. In one typical implementation, the priority value is associated with the node type, and in another typical implementation, the priority is specified by the sending software at the time the data item is submitted for transmission. Or recorded in the data item itself as part of the self-describing data of the node containing the data item or otherwise processed as deemed appropriate by those skilled in the art.

  In an alternative exemplary embodiment, the selection of the most preferred communication path or paths is not made as described above, eg, target search rule-based system, inference method, neural network, and communication path utilization. It is implemented using more complex methods, such as with artificial intelligence techniques, such as pattern recognition using historical data on possibilities, user choices, or other data. Combinations of these or other methods can also be used. A typical method of this type involves the use of a “preference function”. A “preference function” is implemented to calculate a “preference value” for each pending data item when it is sent over each available communication path. The preference function is the capacity of the available communication path, the size of the data item to be transmitted, the priority of the data item, the latest history of the transmission time delay of the available communication path, the cost of the communication path (in some situations This can be adjusted depending on location, time of day, size of data item, total amount of data transmitted in a given time, or other factors), or is well understood by those skilled in the art Use other parameters. After calculating a preference value for each combination of data item and communication path, any communication path for which the calculated preference value exceeds a specified threshold is selected for transmitting the associated data item. The preference value is recalculated as the parameters used for the calculation change. This method allows any one or more communications to transmit a particular data item at a specified time so that selected factors such as cost, speed, transmission delay, or others can be optimized. Allows any number of different factors to be combined to arrive at a determination as to whether a route is preferred. This method allows the use of preference functions that are more complex than simple weighting factors as described above. By comparing the calculated preference value with other thresholds, this method resolves not only how to send data items, but also other decisions such as when to send data items out of band. Can also be used for.

  Once an alternative communication path is selected, communication must be established through that path. For some communication paths, such as unconnected SMS, this is only a matter of using the new communication path for future transmissions, but in some cases the data item's Reformatting may be necessary. For other communication paths that rely on establishing a connection prior to sending the data item, switching the communication path requires that a new connection be established before the data item is sent. In some devices, this task is handled transparently to application software by the device operating system. Other device implementations require application software to handle this task. In either case, the application software is required to complete handshaking tasks such as providing authentication data or re-establishing session context before resuming data item transmission.

In some embodiments, the mechanism used to cause the application to switch communication paths is determined by typical device design. At present, various methods are used by various device manufacturers, and in future devices, further methods are possible and expected. For some typical devices, such as Blackberry, the application adds a parameter to the address (URL) of the connected device and passes it to the “open” method to connect to for a given connection. Specifies the communication path to be used for. To switch communication paths on such a device, the application closes the existing connection and opens a new connection using different parameters that specify an alternative communication path. In other typical devices, a different connection method is used for each communication method supported by the device, and the application software closes the connection using the method required by the existing communication path and creates a new one. A new connection can be opened on it using the methods required by the communication path. In yet other typical device implementations, the communication path selection is under the control of the device user through physical control or operating system utility software, and the application software interacts with the user to route to different communication paths. You must request a change.

  The ability to send messages and message segments over any suitable communication path without loss of functionality, and to switch communication paths in the middle of segmented message transmission without process interruption is Reliability by maximizing throughput and minimizing response delay by always selecting the fastest available communication path, and failing over to an alternate communication path when the communication path in use loses connectivity To minimize costs by selecting a communication path suitable for the type of data item being transmitted, and for example push mode is required, and all available communication paths support this method of operation Select the communication path based on the communication path capability when not And it makes it possible to improve the functionality by allowing use.

[Multi-route data routing]
Some typical device implementations can use more than one communication path at a time. For example, a device can send or receive SMS while exchanging data items over Wi-Fi, or can transfer data items over a Bluetooth link while connecting through a wired Ethernet port. The above-mentioned problems and solutions regarding the use of a single communication path include switching the communication path when connectivity is lost, and a method for selecting an appropriate communication path from the available options. All apply to the use of multiple communication paths. The use of multiple communication paths, however, introduces additional capabilities and additional issues that must be considered.

  Using multiple communication paths simultaneously increases the total bandwidth of the device because data items are transmitted through all available communication paths. The node accumulator on the receiving system saves all data items arriving intact and eliminates any duplication and merges them regardless of the communication path that has passed. Once received, there is no difference in node structure or content, so there is no difference in which communication path a given data item was sent through, even if the communication path loses or gains connectivity over time. , Messages can continue to be sent and received through any other communication path that maintains connectivity and satisfies characteristics requirements, priority requirements, or other factors described herein.

The sending device can use several different procedures to select which data items to send through each communication path. Examples of possible procedures are: The next data items are transmitted one by one through the first communication path that is free and can accept the data items. Match the characteristics of the data item with the characteristics of the communication path (eg, a data item that must be sent in a push mode or a large data item sent over a high bandwidth path and a small data item sent over a low bandwidth path) Is sent over a communication path that supports push mode, not a communication path that does not support push mode). Data items are transmitted in order of priority, with the data item having the highest priority prior to the data item having the lowest priority. The data item being transmitted in response to the pull mode request is transmitted through a certain communication path, and another communication path is reserved for push mode exchange. And any combination of these procedures or other procedures deemed appropriate by those skilled in the art. Procedures can maximize throughput, improve responsiveness to users, minimize costs, maximize flexibility for application developers, or any combination of these or other purposes Selected to achieve. In some exemplary implementations, a method based on the priority adjustment method described above is used to determine which communication path to use. When the priority value is determined for each available communication method, the one having a score exceeding the set value is used. Those below the set value are not used. Alternatively, those with a score below the set value need to be communicated (messages are waiting to be sent or scheduled polling time), and there is no higher score available method As long as not used. In some typical implementations, the user needs to explicitly approve the use of a communication method that has a score below a set threshold. This provides an opportunity to move the device to a Wi-Fi hotspot, connect the device to a wired Ethernet, or otherwise make another communication method available instead.

  If all available communication paths tend to be unreliable or occasionally have significant delays before delivery occurs, maximize delivery opportunities and minimize time to delivery Therefore, the same data item can be transmitted through two or more communication paths. Although duplicate delivery can occur in this scene, the duplicate detection and handling procedure described above handles this problem and eliminates these duplicates prior to storage. In some typical implementations, duplicate transmission of such data items is limited to high priority data items, and lower priority data items are transmitted only through a single communication path, A level protocol handles lost or corrupted data items in the manner described above.

Example Device FIG. 6 illustrates an exemplary, non-limiting implementation of a communication portion of a device that is compatible with a communication system architecture such as the exemplary architecture presented in FIG. (6000) communicates with one or more other devices (6610, 6620) through a particular communication path instance (6710, 6720). Each such device includes one or more communication interfaces (6300a, 6300b) that are accessible to at least one of a series of available communication technologies. The exemplary device further includes a dispatch manager (6220) further including at least one protocol manager (6210a, 6210b), at least one session manager (6200), and a node storage and cache unit (6500). A protocol manager is provided on the device to change the format and content of the data items as required by the communication technology implementation used by the communication interface (6300a, 6300b). Device 6000 uses computer program code devices (referred to herein as “nodes”) to process specified application tasks that are received and processed on a second device. The first device is configured to be transmitted.

[Session Manager]
The session manager component manages the protocol manager activity, makes decisions regarding whether to accept connections from other devices, how to route data items, and provides related functionality to the device.

  When a typical, non-limiting implementation of a device supports the use of multiple communication paths, a mechanism for selecting one or more communication paths for use from those available is a session. Supplied as part of the manager. This is referred to herein as a “selection algorithm”. The characteristics of each communication path are used by the selection algorithm to establish the preferred use of one or more communication paths and avoid the use of other specific communication path (s). . The selection algorithm should also use the characteristics of the message to be sent, such as priority, size, or time waiting for transmission, as factors in selecting the preferred communication path or paths. Can do. For example, when a very large message such as a video clip is transmitted, the message is transmitted through a communication path with a large bandwidth such as Wi-Fi, instead of a communication path with a limited bandwidth such as SMS or MMS. It is preferable. If one communication path can be used at a fixed cost and the other communication path charges a fee for each transmission, the fixed cost path is preferentially used, and the path charged for each transmission is fixed. It is desirable to use only when the cost path is not available, or to avoid the use of a path that is charged for each transmission, or to limit its use to only high priority messages. In another example where push mode transmission is required, a communication path that supports this mode must be used, and a communication path that cannot support this mode because of the implementation scheme cannot be used. . In some cases, it is advantageous to use multiple communication paths in cooperative push mode, in which case the available communication paths that support push mode but are otherwise inappropriate choices for transmission are coordinated push. Used to send a request, such as a message, including a communication request command with a mode assist function to the recipient device. This request message prompts the recipient device to initiate a pull mode connection with the requesting device using an appropriate communication path through which the requesting device can transmit the message.

  If the device has one or more messages to transmit, but the communication path in use is not suitable for some reason, the device will continue to have the appropriate communication path (s) available (s) You can save the message. If one or more of the messages has a sufficiently high priority and there is a suitable communication path that is not currently used but available, the device may in some typical implementations: The standby message can be transmitted by switching the communication path. In some typical implementations, the user requests by appropriate means, such as an SMS message or voice message, to move the device to a place where transmission can be achieved by supporting an appropriate communication path as soon as possible. Is done.

In some typical implementations, the preference associated with some transmissions is incorporated into the preference calculation when determining whether to use a given communication path. For example, high-priority transmissions may be used if the unfavorable communication path is the only available path, or the unfavorable communication path has characteristics that favor certain transmissions (such as support for push mode) If an available communication path does not have the required characteristics, it may result in using the undesired communication path. Devices that support the simultaneous use of multiple communication paths perform such high-priority transmission using OOB, and low-priority transmission uses a preferred communication path or delays until a preferred communication path becomes available. I will let you. The transmission priority value is established by configuration settings or by input from the user when requesting transmission, or by design of the transmission procedure, or by other means deemed appropriate by those skilled in the art. The transmission priority value is associated with the transmission through means such as function parameters, reference data structures, or other commonly used methods, depending on the procedure that implements the transmission request. The transmission priority value may be determined by the use of a priority value embedded in the message being transmitted or through a means that is non-direct to the priority value such as a message (eg high priority transmission waiting for high priority transmission). Carried by associating (by placing low priority transmissions into a low priority transmission queue) or by any other suitable mechanism.

  In addition, there is a characteristic that makes it impossible to use a predetermined communication path for a specific purpose. For example, in the case of a Wi-Fi communication path, a device connected through a Wi-Fi service is usually given a different network address each time it connects to the service. Therefore, the data item cannot be transmitted to the Wi-Fi connection device until the Wi-Fi connection device establishes the connection (pull mode). Other devices have no way to reach the Wi-Fi connected device at other times. However, for other communication paths such as SMS or MMS, the device has a fixed address and can be reached (push mode) by any other device that has access to that address. . Some communication paths are selected for use when the action to be performed requires characteristics that are supported by the communication path, even if other communication paths are preferred for transmitting large amounts of data items It may be done.

  When there are multiple available communication paths, the device can select one or more for use, and when one or more preferred paths become unavailable (path loss switching ), Or in some cases, can be switched between communication paths to optimize speed, responsiveness, cost, reliability, or other various communication characteristics (optimization switching). A detailed description of some exemplary methods, such as to detect path loss and to determine a preferred path, is provided below.

  A plurality of different communication paths can be used jointly to perform a specific operation that would be impossible to implement if the communication paths were used individually. In one exemplary exemplary implementation, the device has both Wi-Fi and SMS capabilities. Wi-Fi connectivity has high bandwidth and is free to transfer data at a fixed cost, but only within a local area called a “hot spot” and the mobile client device needs to initiate a connection Only works in “pull mode”. SMS connectivity has a small bandwidth and is charged for each transmission, but has a wider service availability and operates in a “push mode” where a server or client can initiate communication Can do. In situations where the server device needs to transfer data items to the client device when the client device is not connected and would normally not initiate a connection, the server device uses SMS. , A message containing the command can be sent to the client in push mode, and the client device initiates an OOB connection to the server via Wi-Fi. Wi-Fi is then used to transfer data items over a faster and cheaper Wi-Fi connection. In some typical implementations, as a result of the message being sent over the SMS communication path, the user moves the device to a location where Wi-Fi service is available if the device is not already at the Wi-Fi hotspot. You may be required to

Push mode is also used in some exemplary exemplary implementations to implement announcements and acceptances (A & A). An A & A has a task to be performed, and there are multiple users who are considered capable of performing that task, however, which (one or more) users are available and willing to do so, and This is the process when you don't know if you have that ability. The process sends an announcement message to one or more devices associated with one or more users selected as potential candidates to perform the task due to location, job function, name, or other means Collecting user responses, returning them to the request server, and selecting one or more of those that respond positively to the performance of the task. Task implementation includes further A & A interactions, downloading data items associated with one or more tasks, using pre-cache data items that already exist on the device, or other processes. be able to.

  In some exemplary exemplary implementations, the normal function is to poll the server device from the device, periodically, or when requesting an updated data item or sending a response node At any time or when the device detects the availability of a particular type of communication path. For example, once every 10 minutes, or whenever the user enters a data item to be transmitted, or whenever there is an available Wi-Fi communication path. This is sufficient for most situations, but when the server device has a data item that needs to be sent to the device when it is not connected to the server, or transferred to the device. Sometimes the second non-server device has a data item or other data to do (P2P). For example, when a data item in the catalog has changed, or when the supervisor's device has a task represented by a series of nodes that must be transferred to the worker's device for reassignment There are times when an updated version of a node that has been sent to the device in advance is available, and the device needs to be synchronized so that the node of that updated version can be obtained as soon as possible. . In such situations, the use of push mode is sought, but it may not be possible or optimal to use the push mode as described above to trigger a pull mode connection. For example, if no communication path configured for use for a pull mode connection is available, the device may delay a response to the trigger until such a communication path becomes available. If the need to synchronize the device is urgent, or if pull mode cannot function without an update version of the node (eg, update price information in order or server address information has changed), update is required The node that performs the transmission is transmitted in the push mode or the cooperative push mode. This transmission may be performed over a communication path other than that preferentially used for such transfer (eg, SMS or not Wi-Fi or Bluetooth), regardless of the increased cost or time taken to transmit the data item. Through MMS).

  In some typical implementations, the device is limited to a single connection through one predetermined type of communication path at a time, and the use of OOB transmission using different communication paths is a further connection. Used to implement or increase the overall bandwidth. Some communication paths contain unacceptable delays during transmission, or can be unreliable or intermittent, so in some cases, a given data item may be sent at once by several communication paths. Desirable. Such redundancy increases the chance that a data item is received in a timely manner at the receiver, but may also duplicate transmissions. Since the node has a unique node ID and version information, the receiver can recognize and discard such duplication, or can recognize and discard an expired node whose transmission has been delayed.

The information that a device must have in order to exchange messages or message segments is information about which communication paths are supported, information about which recipient designation information is provided, and some In a typical implementation of, to gain access to authentication credentials, encryption keys, polling schedules, or communication paths, route data items to the intended recipient, and send them in the required form You must also have any other information that is needed. The device is initially configured to have enough information to allow it to connect to and exchange data items and commands with that server by its manufacturer, user, or others. Optionally, the device is configured to have further initial configuration information. The device sends further communication configuration information specifying the information needed to exchange data items with the other device from the initially configured server (s) and thereafter the other device. Can be obtained from. Additional information to be acquired includes device ID, device user name, communication path supported by other devices, TCP / IP address, mobile phone number,
Or data routing information such as Bluetooth device information, authentication information such as Wi-Fi hotspot login account and password information, server address for services such as SMS, DNS, or e-mail, scheduled polling interval or time data, Communication path preference configuration data, data priority configuration data used to adjust the use of the communication path based on the priority of the data waiting for transmission, or other information related to communication between devices. .

[Protocol Manager]
In the above description of transmission and reception, reference is made to processing by a typical protocol manager in a typical, exemplary and non-limiting implementation. The protocol manager is used to make communication path specific changes to the data items being transmitted and to undo those changes upon receipt. Changes are necessary for some communication paths to address restrictions on data representation, message size, or other characteristics of the transmitted data items.

  FIG. 7 is a flowchart showing processing performed by the protocol manager on the data item transmitted by the dispatch manager. The dispatch manager delivers a data block containing the data to be transmitted to the protocol manager (7000). The protocol manager checks the data bytes for compatibility with the communication paths supported by the protocol manager (0710).

  If not (7020), the data block is encoded to remove its incompatibility. Methods of encoding data are well known to those skilled in the art and “escape” the problematic byte, ie, use the tag byte to identify the location of the problematic byte, There are techniques such as replacing with a suitable byte that identifies the value.

  If the resulting data block is too large to be transmitted at once (7040) over the communication path associated with the protocol manager, the data block can be reconstructed into the original data block by the recipient protocol manager Even after the segment header data to be added is added, it is divided into a plurality of segments that do not exceed the maximum transmission unit size of the communication path (7030).

  While there are remaining segments or data blocks to send (7060), they are sent (7050), after which the process ends and control is returned to the dispatch manager.

  FIG. 8 is a flowchart showing the processing performed by the protocol manager when it is being used to process data items by the receiver session manager. The protocol manager is given a message or message segment as received through the communication interface (8000). Given a segment of a larger message (8010), the protocol manager adds the segment to the message buffer and associates it with the segment of the same message received so far (8020).

  If the complete message was obtained because the complete message was received, or because all segments of the larger message were received (8030), the protocol manager will encode the problematic data bytes, The original data block is restored (8040), eliminating any transmission changes made by the sender's protocol manager, such as compression, encryption, or others. This data block is passed to the dispatch manager for further processing independent of the communication path, and the process ends.

  After the data item is received, it is checked to exclude duplicate nodes, and if it is found to be unique (as described herein) or an update to an existing node, the node of the device It is placed in the storage unit (Node Store). This allows data items to be sent through any available communication path or simultaneously through multiple communication paths, and the communication path (s) in use or available for use It is possible to switch between various communication paths as needed without creating the need that components other than the dispatch manager know about. This simplifies the implementation of the node store and data item processing components.

[Node accumulation / cache section]
Referring back to the embodiment illustrated by FIG. 6, the node store (6500) receives data items sent to the device, data items waiting to be sent from the device, and sent from the device. Supports saving and accessing waiting commands. Data items are stored in a format suitable for the device. Some data items include nodes. Nodes can represent user data elements, user interface instructions (visual or interactive actions), and executable business logic. In a preferred exemplary, exemplary, and non-limiting implementation, the node store maintains node attributes as storage related attributes and adds encryption, compression, or other protection.

  In an alternative exemplary, exemplary, and non-limiting implementation, the data items are contained in a flat file (but segmented, special character processing, compressed, or encrypted) similar to the format that is transferred over the communications network. Stored as an ASCII string (without sparse filtering). In this exemplary, exemplary, and non-limiting implementation, flat files are searched sequentially to locate or replace specific nodes or specific fields within nodes. In an alternative exemplary exemplary non-limiting implementation, nodes are indexed by node identifier and stored in a database. Preferably, a cache of data items, whether a node or other type of data item, is maintained in local memory to improve the performance of operations supported by this module.

  Regardless of the storage format, the node storage module provides an interface for storing, updating, and accessing data items from the dispatch module and the display module. Preferably, the operations supported by this interface include replacing a stored node with a new node, adding or replacing a group of nodes, deleting a node, obtaining a specific node, Finding a parent node, next node, or child node, obtaining one or more fields in a given node, and changing one or more fields in a given node.

  The data item is held in the node storage unit and is managed by the node storage unit while waiting for transmission or after being received by the device. The node storage unit can use various means for storing, maintaining, searching, deleting, and managing nodes. A data item in a node store is unique within that node store and does not accept saving any duplicate copies of the data item. The uniqueness of data items is determined in some typical systems through means such as comparing the node ID and node version information of the nodes that make up each data item. In such a typical system, a node with the same node ID but a high node version value is considered an “updated node” and becomes a node with a matching node ID but a lower node version value. Take over. Other means of comparing node uniqueness can be implemented, as will be apparent to those skilled in the art.

  A node is also held in the node store while waiting for transmission, waiting for processing by the device, during post-processing by the device, or when stored for possible future use. As a non-limiting example, the node store can maintain a “flat file”, or an ISAM file, or a relational or other database, or an in-memory data structure, or a web browser “cookie”, or a node content and logical structure Implemented in a number of ways, such as saving a node with, determining which node is saved, and any other format that allows you to search for a specific node as needed . The node store is implemented in different ways on different devices as long as it allows the necessary storage and search operations for such stored nodes. Node storage can be shared between devices using synchronized database technology if the devices are so configured.

  Data items are held in the node store while waiting for transmission. Possible reasons for waiting for transmission are other data items being sent first (eg, other data items have higher transmission priority or are in the front of the queue) and available communication paths Is not suitable for delayed data items (eg, data items are large and should be transmitted with low priority, but the available communication paths are slow and expensive), there are no available communication paths, There are data items queued between device polling intervals or other factors. A data item waiting for transmission is stored in one node storage unit regardless of which communication path is scheduled to be transmitted. Data items received by the device are stored in one node store regardless of which communication path they arrive through. The node accumulator can capture further data that is not part of the stored node itself for the data items it contains. This data includes the device to which a particular data item is to be sent, the version of that data item, when the data item was placed in the node store, and where the given data item was sent Is the device and when it was transmitted, the number of unsuccessful attempts to transmit the data item, or any that one skilled in the art deems appropriate and appropriate for the functioning of the system or its monitoring Information such as other data can be included.

  The mobile client device can improve responsiveness to the user by maintaining as many data items in the node store as the device resources allow that are likely to be needed in the future. Such indications include, but are not limited to, being part of an application that is currently in use, being part of a frequently used application, and data items required by multiple applications ( Eg, server address, company logo, address book information, parts list, price list, billing code list, etc.) or tagged to indicate that it should be retained if possible There is. By maintaining such data items in the device's node store, the number of data items that must be transmitted in subsequent transmissions is reduced, and the device performs the required function during periods of no available communication path. The likelihood of being implemented increases. By transmitting such data items when an optimal communication path for their transmission is available, the need to transmit them later through a non-optimal communication path is avoided. The node storage unit manages its content through mechanisms well known to those skilled in the art, such as aging, priority, and queues.

It is predicted that a particular data item is likely to be needed by a particular device before that need emerges, and that device can now use a suitable communication path for the transmission of that particular data item Sometimes, some exemplary implementations can proactively send those data items that are expected to be useful or necessary to the device. Alternatively, the device can “pre-fetch” data items in anticipation of what is needed when a suitable communication path is not available. One example where such a need is foreseen is when sending an image, audio, or form definition data item that is needed by one or more nodes that define a given task. Another example where the need for data items is foreseen is a server that maintains a list of tasks that are performed at specific times or at specific intervals. Yet another example where the need for data items is foreseen is the acquisition of data items required by multiple tasks. Such a server can look ahead to tasks that are scheduled to be performed and send data items required to perform those tasks in anticipation to the expected device. How much data can be handled in this way may be limited by device resource limits, but typical caching algorithms well known to those skilled in the art manage the available resources to the device Used to do. Examples of algorithms include least recently used (LRU) method, least recently used (MRU) method, least frequently used (LFU) method, or adaptive replacement cache (Adaptive). Replacement Cache, ARC) method. The caching method chosen for a typical implementation is optionally the cost or difficulty of reacquiring data items (eg, images transmitted over high bandwidth communication paths with limited availability or Factors such as large nodes such as voice data vs short text strings or commands transmitted over any communication path), the number of other nodes referring to a given node, or other factors can be considered. Further examples that may increase efficiency, reduce costs, or otherwise be beneficial by such processing are listed by multiple group nodes, or server addresses, address books, or other data There are times when frequently used data items or nodes are updated to form a catalog containing.

  To handle duplication of nodes transmitted over multiple communication paths, and for other purposes, each node has a unique ID and version information defined as part of its structure. The node version information should not be mixed with the FDL version information of the message format of the typical implementation. Node version information allows a particular node to be recognized as an updated version of a node with the same node ID, as being identical to a node with the same node ID, or as being replaced by a node with the same node ID , Specify the version of the node. Node version information, in some typical implementations, alone or in combination with other information, such as a server identifier or manufacturer code, is a time stamp, a numeric value to increment or decrement, or other Consists of appropriate values. In some typical implementations, the node version information can consist of individual fields within the node, or multiple fields within the node, such as a concatenation combining a serial number with a user or catalog ID value. Can consist of combinations. When a device receives a node, it can search its own node store to determine whether it already has a node with that node ID. If you do not have a node with that node ID, the new node is not duplicated and is saved for use. If a node with that node ID is already in the node store, the version information of the nodes is compared and the older node is deleted to determine which node has priority over the other node, The newer node is saved for use. If the node ID and version information are the same, these nodes are the same and the duplicate node is deleted. The communication path used to transmit the node does not affect this procedure. Only the data contained in the node is required to determine the uniqueness of the node, or whether it has been superseded by a new version, not the method of transferring the node to the device. If one node is sent over Wi-Fi, but another copy of the same node is sent over SMS or over a Bluetooth link, the node ID and version information are still present and the node is duplicated Or if it has the same node ID, it is used to determine which takes precedence. Switching the communication path does not prevent the movement of data items between devices and the detection of duplicate transmissions.

  By eliminating duplicate nodes before or as part of the step of entering the node storage unit, a predetermined data item is simultaneously transmitted through a plurality of communication paths, and a delay in causing the data item to reach the receiving device is Any information about the current delay occurring in the various communication paths can be reduced without the need. The communication path with the shortest transmission delay at the time of data item transmission causes the data item to reach the receiving device, and data items transmitted through all other communication paths are treated as duplicates upon arrival and are ignored.

  The node accumulator is also used to hold response nodes containing user data provided in response to node processing until these nodes are transmitted. The node accumulator tracks the time that such data items are waiting to be transmitted and can alert the user about the lack of an appropriate communication path if this delay exceeds a specified threshold. . The user can then move the device to a hotspot, change configuration settings, allow use of a communication path that would otherwise be inappropriate, or transmit connections and data items in some other way By enabling this, an appropriate communication path can be prepared. Alternatively, the device can take other actions such as choosing an alternative, perhaps more expensive communication path for one or more nodes when the transmission delay threshold is exceeded.

Typical Node Extensions and Node Additions Typical exemplary non-limiting node details of current devices are described in US patent application Ser. No. 11 / 169,149, but additional attributes as follows: And having a type.

  One exemplary, exemplary, and non-limiting implementation may be used to define new node types or other as needed to achieve the further objectives of a typical, exemplary, and non-limiting current implementation. This capability can be exploited to extend the structure of the nodes previously defined by the exemplary exemplary implementation of For example, one example of an exemplary, non-limiting implementation is one node type that is sent to a device and allows the device to query the user without interrupting the normal flow of the application in use. And a second node type for returning a user response. Either one or both nodes are transmitted in-band via a preferred communication path, transmitted via an alternative communication path, or transmitted using an out-of-band communication path. One use of such capability is for users who have scheduled tasks for one or more undertakers according to the logic defined by this particular implementation and rejected or did not respond within a specified period of time. Indicate task announcements, perhaps to broadcast to multiple devices at the time, possibly using multiple communication paths, and whether the task is acceptable Used to return a response (A & A). Further details of this aspect of exemplary, exemplary, and non-limiting implementations can be found below.

[More typical node attributes]
In a preferred exemplary, exemplary, and non-limiting implementation, each node specifies a node version value. The first node that should take precedence over the second node in the device node storage unit should have the same node ID value as the second node and a node version value that is greater than the node version value of the second node. . In situations where both nodes exist on one device, such as when the second node is created as an update to the first node and sent to a device that previously received the first node, the device Can determine which node is to be saved and which node is to be deleted by comparing the node ID and the node version value, selecting the node with the larger node version value, and deleting the old one. The ability to determine which node is valid when there are two or more nodes with a given node ID is that nodes are sent using multiple communication paths simultaneously to reduce transmission delays. Required in situations such as when more than one copy is sent to the device.

  A typical, exemplary, non-limiting preferred implementation also includes a node transmission priority value for each node. The use of node transmission priority is to adjust the transmission order of nodes so that nodes with higher transmission priorities are transmitted before nodes with lower transmission priorities, or which communication path Use a communication path for high transmission priority nodes to help determine if it is suitable for transmission, or if only low low transmission priority nodes are waiting for transmission Or to allow a high transmission priority node to be transmitted simultaneously over multiple communication paths, or for other purposes deemed appropriate by those skilled in the art. In some typical implementations, to ensure that a node is deleted before entering the node store, a “node delete” node is sent before other nodes, such as node type. Based on this, some nodes are transmitted prior to others. This reduces the use of resources on devices with limited storage capabilities. In such an implementation, the ordering of transmissions by node type takes precedence over the ordering based on node transmission priority.

  Some exemplary, non-limiting implementations include a node cache priority value for each node. The node cache priority is used as a material to be considered by the node accumulator when deciding which node to keep and which node to kick when all other factors are equal. Node cache priority is the only factor considered when making such a determination.

[More typical node types]
Some exemplary, non-limiting implementations include a “distribution list node” node type. This includes a list of devices, i.e. a reference to a catalog of devices, and a list of contact methods for each device, i.e. a reference to one or more catalogs containing contact methods for each device. The contact method is not only the communication path supported by each device, but any associated address, authorization, authentication, encryption, or other required to utilize the communication path when contacting that device. Includes information. Optionally, the distribution list node can contain information about the users of the listed devices (eg name, shift, job title, supervisor name, etc.) and / or information about the device itself (eg device type, location, etc.). Can be included. Distribution list nodes are useful for any procedure where multiple devices and contact methods must be specified, such as when restricting a delegate of a task to a specific set of devices or synchronizing a catalog. This is especially true when done using P2P technologies such as Bluetooth or “ad hoc” Wi-Fi where the server is not available.

Some exemplary, non-limiting implementations provide a node type “A & A” that is useful for implementing announcement and acceptance capabilities, as described below. A & A nodes are created by the server's UI or by using an application programming interface (API) designed to allow the formation of A & A nodes by various software systems other than the server's UI. The A & A node includes an FDL specification for the task, or a reference to such a specification, a “candidate list” (in the form of a distribution list node) that includes the devices to which the task is offered, a specification of the number of accepting devices required, affirmation The procedure used to select the required number of devices from among the responding devices, the action to be taken if the number of positive responding devices is less than the required number of accepting devices, and the response Includes an optional provision for the maximum time to wait. The process of the A & A node is to send a notification message to each device in the “candidate list”, and optionally wait for the user to time out with a timeout while waiting for too long. Present and collect positive or negative responses, return them to the server, select the required number of acknowledgment devices, create a node based on the FDL for each selected device, and the resulting data Including queuing items, or taking specified actions when the number of acknowledgment devices is less than required.

  Some exemplary, exemplary, and non-limiting implementations include a “catalog synchronization node” that matches catalog content on a first device with catalog content on a second device. , Used to make it possible to resolve the differences so that both devices have catalogs containing the same data items and those data items are the latest available for both devices. Some exemplary implementations allow a distribution list node to be associated with a catalog synchronization node to specify multiple devices that have a copy of the catalog and are considered to require synchronization . Such a distribution list node may allow a first device to synchronize with a catalog of one or more second devices through a peer-to-peer approach. This is useful in situations where the second device does not have an available communication path to the server.

[Typical node structure]
The following table describes the fields that make up the structure of a node, as defined by a typical, non-limiting implementation. Where the field description is the same as that of US patent application Ser. No. 11 / 169,149, it has been omitted for clarity. Each field description below includes only additions and extensions to the structure or application described by US patent application Ser. No. 11 / 169,149. However, because of the context, all field names and types remain.

Exemplary Message Extensions Exemplary exemplary non-limiting implementations include the message types and message formats described in co-pending US patent application Ser. No. 11 / 169,149, as well as further described below. Extensions to allow for the implementation of capabilities and features may also be included.

[Configuration data]
A configuration that represents communication paths and other data used to control the nature of communication or other device activity, as well as their associated addresses, authentication, security provisions, priorities, preferences, and other data. Data is sent using an update device setup message (type 3). The update device settings message updates a set of preferences or configuration settings for the device. Each record of this message type includes fields as described in US patent application Ser. No. 11 / 169,149, and the following additional parameters and associated attributes:

Parameter (2-digit number)-Parameter to be updated 06-communication path selection preference (specified as a character string including the XML description of the preference)
・ 07-Communication route characteristics ・ 08-Dynamic route selection

  Value (string)-new value for the parameter

The value associated with the “06” parameter includes a character string including the XML description of the communication path selection preference to be set or changed. For example:

The value associated with the “07” parameter includes a character string including an XML description of the communication path characteristic to be set or changed. For example:

  The value associated with the “08” parameter includes a string containing “1” if dynamic routing is activated and “0” if dynamic routing is deactivated. .

  In the case of an update device configuration message, the dispatch module determines the device configuration to be provided and changes the predetermined configuration to a new value.

[Communication request]
Communication supply message (type 9) is used to request that various communication-related actions such as cooperative push, "reply" (ping), "maintain connection" (keep-alive), etc. be taken by the receiving device Is done. The communication request message may include the following information fields:
Request type (2 digits)-the type of request being made.
Request device address (character string)-Address of the request device.
Request ID (12-digit number)-Request source relative ID of the request expressed in the YYMMDDDHMMSS format.
Request priority (3 digits)-Request priority. Equal to node transmission priority.
Related data (string) —Data associated with a specific request type.

In a typical implementation, the request type field may contain one of the following values:
-01-Cooperative push-02-Ping request-03-Ping response-04-Keep alive

  In the case of a cooperative push request, the request device address includes the address of the request device on the communication path used to send the request. The request ID is the time when the request is transmitted. The associated data string is a list of the addresses of the various communication paths that can be used to reach the requestor, and in some typical implementations, the address of the requestor on that communication path and the used And further information about each communication path, such as a protocol.

  In the case of a ping request, the request device address is the address of the request device on the communication path used to make the request. This is also the address and communication path used to send the response message, if possible. The request priority can limit the use of a part of communication paths depending on the situation depending on the communication path setting and selection preference. The requested action is sending a ping response message to the requesting device. The ping response message has the same field values as the ping request message except that the request type is a ping response (“03”) and the request device address is a response device.

  A keep-alive message is sent to keep the communication path from being closed because it is idle and to inform other devices that the requesting device is still connected. The request device address is set in the same manner as for other request types, and other fields are not used. On the recipient side of the keep-alive request message, no action is required other than recording the receipt of the message to track connectivity.

[Task Delegate]
The task delegate (type 10) message body defines a series of materials corresponding to one task, encoded in a device-independent manner. Relative to the task so that the receiving device can transform the connection between the nodes as needed for node processing while maintaining the placement and order of the nodes of the task as specified in the task delegate message. In particular, node references are made.

  In some exemplary implementations, the recording format for the task delegate message is optimized to exclude any fields set by the receiving device. In particular, CompletionStatusFlag is always 0 (incomplete), and the response text is always empty. In this exemplary, exemplary, non-limiting implementation, such fields are not included in messages sent over the communication network so that the available space can be optimized, such fields are Rather, it is automatically inserted as part of processing the task delegate message after the device receives the message.

Exemplary Catalog Synchronization As shown in FIG. 9, catalog synchronization (9200) is an update message sent from a server to multiple client devices (9210, 9230), first device and second Sent to and from the device (9220) and sent from the client device to the server (9240). In the exchange shown in the figure, the server sends catalog update A to the first device in contact with the second device (9220). The server is not aware of this P2P connection. The catalog update A message includes a distribution node that has specified that the first device and the second device should receive this update. The first device updates its catalog and sends catalog update A to the other device (second device) in the distribution node list to ensure that the devices remain synchronized. Transmit (9220). Since the server is the source from which the first device has received the catalog update A and is therefore considered to already have that update,
The first device does not send catalog updates to the server. In some typical implementations, the server is not included in the distribution node list.

  Meanwhile, the server has also sent catalog update A to the second device (9230). Update redundancy for the second device is handled as described elsewhere in this document, ensuring that at least one copy of the update arrives at the second device with the shortest delay.

  When the second device receives catalog update A (9220 or 9230), it is probably because the address of the second device has recently changed or because the availability of the communication path to the second device has been lost. Or, for some other reason, discover that the data item included in the update is already invalid. The second device creates a catalog update B and sends it to the first device (9240) and to the server (9250). The server then transmits the catalog update B to the first device according to the distribution node included in the catalog update B (9260).

A typical Announcement & Acceptance A & A sends a task announcement to multiple devices associated with a user who is a candidate to perform a task simultaneously, a response from those users, or optionally who responds within time limits And determine which users have the will and ability to accept the announced task. Candidate users are specified by the task creator or by an external system and are current location, job title, work schedule, current task load, experience level, recent task load, explicit list by task creator, or these or Identified based on any combination of other criteria deemed appropriate by those skilled in the art. Selection of candidate users and determination of which devices are associated with which candidate users ("candidate user's device") by an automated system with access to a required data source such as a node store or database, or Implemented by the user creating the task through the user interface or a combination thereof. An appropriate number of responders (determined by the task creator) is chosen and assigned a task. Push mode is not required to enable the use of announcements & accepts, but can improve the process by reducing the delay required to transmit the announcement to all candidates.

  As shown in FIG. 10, the A & A process may, in some exemplary implementations, interact with an external program through interaction with a server user interface (UI) or through a specified application program interface (API). Started by action. Whether the interaction is via UI or API, the required information is provided (10000). This information includes tasks to be assigned (eg provided as FDL specifications, references to such specifications, or references to hard-coded tasks in the system), candidates to perform the task A description of a user, a description that allows the identification of those devices so that a distribution list node can be created to reference the devices to which task notifications are sent, the number of users required for the task, positive Requires the method used to select the required number of users from among responding users, the optional maximum time to wait for responses to be returned, or the time to stop waiting, and the number of users responding positively This action should be taken when the number of users is smaller.

The method used to specify a user who is a candidate to perform a task can be an employee list with a checkbox for selection, or a job pull-down menu, or location, vocational skill, work shift, experience level, or It can consist of an entry form with various fields specifying detailed requirements, such as others, or any combination of these methods or other methods well known to those skilled in the art. Alternatively, external systems including various databases, software systems, and user interactions are used to create a list of users and associated data provided through the API for use in A & A procedures. In some typical implementations, the external system has all the input required to automatically start and complete the A & A process as part of a complete business method such as a “Purchase-Work Order-Receivable” system. Can be provided.

  The methods used to select the required number of users who respond positively are: “In order of response”, “In order of number of assigned tasks”, “In order of experience”, “ As one of several automatic methods such as “close order”, “in order of long no-task time”, or presenting a list of respondents to the task creator and the selected user made by the creator Specified as a manual method involving input. If the number of acknowledgments is equal to the number of required users specified at the start of the A & A process, no selection is required and the responding user is automatically selected. In some typical implementations, these user selections need to be confirmed using a manual method as described above.

  Actions to be taken when the number of acknowledged users is less than the required number of users are: canceling A & A requests, assigning tasks to positively responding user (s), responding positively Designated as an assignment to additional users, repeated requests, or any other suitable action selected using the user and the appropriate selection method (any of the methods used to select candidate users) .

  As shown in the diagram of FIG. 11, once the necessary information has been provided to the server (11000), the device notification (type 2) message uses all the communication paths appropriate for the priority of the message, It is transmitted to the selected candidate user device (11010). In a preferred exemplary implementation, this message has a high priority and is sent as soon as possible by one or more available communication paths. For this, the push mode is preferred, but when the push mode is not available, the cooperative push mode or eventually the pull mode is used instead. The server waits for a response from the notified device or waits for the specified time limit to expire (11020).

  The display manager of each receiving device responds to the device notification command by causing a message to appear on the user interface of the device and requesting input from the user regarding whether to accept the advertised task. The display manager collects the user's response and sends it back to the server using a communication path appropriate to the priority of the returned data item and an available communication path.

If all devices that received the notification respond (11050), or if the specified deadline elapses before all devices that received the notification respond (11030), the number of acknowledgments received is greater than the number of users required Is also checked (11080). If the number of acknowledgments exceeds the required number of users, a designated selection algorithm is used to select the required number of users from those positively responding (11100). If the number of positively responding users (11080) is equal to the required number of users (11110), those positively responding users are selected (11120). If the number of positively responding users is less than the required number of users, the specified action is performed (11090). As shown in FIG. 10, this is an A & A cancellation procedure (10025), a repeat of the request process that expects more users to respond positively when asked again (10030), the number of requests than requested. The selection of a user who responded small but positively (10035), notification to a third party (administrator or supervisor), or forced selection of additional users by any suitable means may be included. Other exemplary implementations can provide further or different actions, as will be apparent to those skilled in the art. If the A & A procedure has not been canceled or repeated, the selected user is assigned a designated task (10015) and the procedure is complete.

  Referring again to FIG. 11, if the selected selection method is “fastest response” or another method that depends only on the required number of available users (11060), then the server will return the required number of users Simply wait until they respond positively and select them (11070). Otherwise, the server either waits until all candidate users respond (11050), waits until the optional longest waiting time has elapsed, or waits for a wait time (11030), If the number of positively responding users is greater than the required number of users (11080), make a selection from them, and if the number of positively responding users is equal to the required number of users, then select If the number of users who responded positively is insufficient, the specified action is taken as described above (11090).

  Once users (one or more) are selected, tasks are assigned to them. This uses the specified FDL to create data items suitable for each user, and if those data items are not already pre-cached on the user's device, they are transmitted to the user's device. Including queuing of data items. Alternatively, a message is sent to prompt the user's device to request the materials that make up the task.

  Returning to FIG. 9, the A & A message exchange (9000) includes a device notification message (9010) from the server to the first device and a device notification message (9020) from the server to the second device. Anyone skilled in the art will be able to send a device notification message to any number of devices, and the simplest case involving a server, first device, and second device would involve more devices. It is clear that all attributes can be represented. The first device and the second device send a response representing the respective user's user input to the device notification message to the server (9030 and 9040). In the exchange shown in the figure, the second device responds positively. Depending on the scene, the first device responds negatively, or does not respond to device notification messages, or does not respond within an acceptable time, or responds positively, but is not selected by the server selection method. A task assignment message such as a node update command is sent from the server to the second device (9050), and the A & A exchange is complete.

  The A & A capability requires a specific service action (“Replace pump # 12 filter”, “Clean passage 6”, “Respond to machine # 34 alarm”), and therefore apply for any mission ( "I need someone who can work overtime tonight", "Is there anyone who can work on Saturday?") To ask for information ("Who knows where the MIG welder is?", "Test-Who can read this message?" Used for any other appropriate purpose.

Typical task delegates In some situations, it is advantageous to be able to migrate assigned tasks to another device with or without server intervention. For example, in some typical implementations, the supervisor can be assigned all tasks for that group and delegate them to available subordinates, or wired Ethernet to the server. A device with a reliable communication path such as can serve as a local repository of tasks to transfer tasks to the mobile device using a P2P communication path, or to complete the task for any reason An unsuccessful worker can transfer the task to a colleague who can complete it.

  In some exemplary embodiments, a task may require sequential assignment to multiple users or devices. For example, time tracking tasks such as filling in time cards may be assigned to workers. Once the worker completes the worker portion of the task by entering the number of hours worked, the task is reassigned to the worker's supervisor for verification and approval. If there is a problem, the task can be reassigned to a worker for correction. This pattern can be repeated multiple times until the supervisor approves the time card and sends it back to the server to complete the task. Treat the time card task process as a series of different tasks done through the server (ie "worker time card entry" task, "supervisor approval" task, optional "worker time card modification" task, etc.) Instead, by using a task delegate, the process of reaching authorized time card data to the server can be completed with little dependence on contact with the server. This capability of device-to-device task delegates improves efficiency when work teams are spending time in remote locations, mines, or areas where data is not fully protected, such as fully protected equipment. And cost can be reduced. For example, if a worker's time card task is assigned to a supervisor and the supervisor interacts with the worker until the completed task is ready to be sent back to the server, only the supervisor needs to communicate with the server. Just do it. To establish communications with the server, whether you need access to special communications hardware, such as satellite phone or wired Ethernet connection, or need to move to a location with equipment, By not having to be done individually by the worker, the time required to complete the task can be reduced and the need for additional communication hardware can be avoided.

  Tasks that are eligible for a delegate have a “distribution list node” that contains the information necessary to connect to the devices to which the task can be forwarded, and optionally information about the users of those devices, as described above. is there.

  In some typical implementations, the nodes that make up the task link to each other using a reference or node ID that is unique to the first device. In order to transfer such a node to the second device, the node reference must be relative to the task itself, not relative to the nodes present in the first device. This is referred to as “Node Tree Packing”. After the transfer, the transferred node (s) must adjust its node reference to a unique addressing or node ID on the second device. This is referred to as “Node Tree Unpacking”. In order to indicate that such node tree packing has been performed on the task's node and to allow the receiving device to perform the appropriate node tree pack decompression, the delegated task is Transferred.

  A first exemplary procedure (Method 1) for delegating a task from a first device to a second device is shown in FIG. The user of the first device interacts with the display manager of the first device to select an assignment task to delegate (12000). The method of selection in some typical implementations is a menu of assignment tasks from which selections are made. In other typical implementations, tasks are selected by presenting them one at a time until the desired task is found, or tasks must be processed in a specified order or by some other means. It may not be.

Once a task is specified, the task's distribution list node is consulted (12005) to determine which other devices can be delegated to the task. The distribution list node includes data and / or a catalog containing the data specifying the devices that can be delegated to the task and the communication path information for each device. Data is specific to a particular task, or between multiple tasks, for example, when a group of devices are used by a supervisor's subordinates and the supervisor delegates tasks to them regularly Can be shared on Devices that can be delegated to the task are provided to the user of the first device in an appropriate manner (12010). In some typical implementations, the display can consist of a description of the communication path and the device address. In other exemplary implementations, the display can consist of a username associated with the device. In other exemplary implementations, additional data about the user is displayed, such as work shift, experience level, last known location, supported communication path, or other information. In some typical implementations, such other information includes distribution information, such as a specific device or group of devices that can utilize specific task distribution information contained in a distribution list node. May include restrictions on the use of For example, when a task with a distribution list node that specifies a plurality of possible devices to assign a task to is delegated from a first device to a second device, the first device The contents of the distribution list node can be changed so that the only available distribution information that can be used by the device specifies the first device. This restricts the re-delegation of tasks by the second device without constraining the re-delegation by the first device so that the second device can only re-delegate the task back to the first device. . By disabling the use of such remaining distribution information by the second device without removing the remaining distribution information from the distribution list node, the first device is possibly part of the task by the second device. The task is re-delegated to the first device after completion, and when the task is re-delegated, the distribution list node information is still associated with the task so that it can be used by the first device; Guarantees that it is not constrained by the restrictions that specify two devices.

  The user of the first device selects the recipient to whom the task is to be delegated (12015), and the task is packaged for transmission (12020). Packaging tasks for transmission can include node tree packing in some exemplary implementations. In some typical implementations, a distribution list node is added to the task package that is different from the distribution list node used in the current delegate procedure (eg, supervisor wants to restrict task re-delegation) Or if you want to ban it). The task package can be encoded, compressed, encrypted, or otherwise processed in various exemplary implementations.

  Using the communication path information in the distribution list node (12025), the task is transmitted to the second device (12030), the second device approves the task acceptance (12037), and the server delegates Is sent (12035). The notification sent to the server may optionally request that the server notify the first device when the task is completed and the server receives notification of the completion. In some exemplary implementations, when a task is delegated from the first device to the second device, the first device records sufficient information to identify the task and the second device. A permanent record is created, such as by using a BLOB node. This recording is referred to herein as “delegate recording”. Delegate records are useful for propagating task cancellation information to each device that is assigned a task, whether by a server or by a delegate from another device.

  When a task is received by the second device, the task is unpacked and installed on the second device (12040). This is, in some typical implementations, reversing the compression, encryption, or other operations performed on the task by the first device, node references from the form relative to the task. Convert tasks into the form needed for processing (node tree pack decompression) and tasks into task list, task manager, or other structure, system, or procedure used by the second device to manage tasks Can be linked.

  Once the task is completed by the user of the second device (12045), the server is notified about the completion of the task, and the server is first notified if such notification is requested (12050) for the completion of the task. (12055). The first device deletes the delegate record that was created when the task was delegated (12060) and the process is complete.

  As shown in FIG. 13, the message exchange in the task delegate (13100) according to the first method involves the initial assignment of tasks from the server to the first device (13110). The first device then delegates the task to the second device (13120), the second device approves the delegate (13125), and the first device notifies the server about the task delegate (13130). ). When the task is complete, the second device notifies the server (13140), and the server notifies the first device (if notification is requested) (13150).

  A second exemplary procedure (Method 2) for delegating a task from the first device to the second device is shown in FIG. The initial step of the second exemplary procedure, i.e. the user of the first device interacts with the display manager of the first device to select the assignment task to be delegated, the task can be delegated to The steps of referring to the distribution list node of the task to determine the device, the user selecting the device to delegate to, and the step of packaging the task for transmission are first typical. The procedure is the same (14500). The task package is also transmitted in the same manner as Method 1 (14510), and again as in Method 1, the delegated device approves the task acceptance (14535) and the server receives the delegate's A notification is sent (14515). In Method 2, however, the delegate device is not sent as in Method 1 that the delegate has completed the assignment task. Instead, the delegating device logs the assignment task as pending (14520) and sends a checkpoint message containing the unique ID to the delegating device (14525), after which the procedure It pauses until a checkpoint message with a unique ID is received from the server (14530). This pause is a conceptual pause in the illustrated steps, and the processing on the delegate device is not literally paused, but the processing of other work continues normally. A log of pending tasks is maintained for each device that the task is delegated to. These logs are logically distinct, but each log is in a separate sequential file or index file, all logs are in one sequential file or index file, each log is All logs in separate tables of relational database system, all logs are in one table in relational database, logs are kept in one catalog or multiple catalogs, logs are kept in BLOB nodes It is implemented in any manner deemed appropriate by those skilled in the art.

When a task is received by the second device, it is approved for the delegating device (14535), and the task is unpacked and installed on the second device (14540). Along with a checkpoint message with a unique ID (14550), a task acceptance message is also sent to the server (14545). When the server receives the checkpoint message, it forwards it to the delegating device (14555), which indicates that the delegated device has contacted the server and therefore the server is informed about the task delegate. The delegate log is deleted until the delegate log includes the delegated task (14560). When the task is complete, the delegated device contacts the server to report the completion of the task (14565), as in Method 1, and the process is complete.

  As shown in FIG. 13, the message exchange in the task delegate (13200) according to the second method involves the initial assignment of tasks from the server to the first device (13210). The first device then delegates the task to the second device (13220), receives approval to accept the delegate by the second device (13230), and notifies the server about the task delegate (13240). The first device then sends a checkpoint message (13250) to the second device. The second device sends a task delegate notification to the first device (13260) and forwards the checkpoint message to the server (13270). When the server receives the checkpoint message, it forwards it to the first device (13280). When the task is complete, the second device notifies the server (13290) and the process is complete.

  Method 1 for task delegates is useful when at least the first device is in communication with the server and the server is reliably notified of the task delegate to the second device. In situations where this is not the case, Method 1 can still be used for tasks assigned to the first device if the server is willing to accept the task completion from the second device. This addresses the situation where the second device completes the task and sends it to the server before the first device notifies the server about the delegate of the task to the second device. In an alternative exemplary implementation, the second device sends a task completion message to the first device, and the first device then sends the task completion message to the server. Such relaying of task completion through the chain from the second device to the first device can be made to any number of devices, as will be apparent to those skilled in the art. Each first device creates a delegate record when the task is delegated to the second device, a task completion message is returned, relayed back in the chain, and the processing for that task is completed Delete the delegate record. The delegate record allows each first device to verify that the task completion has been transmitted from the second device.

  If the task is canceled at the server, the cancellation is sent to the first device (s) to which the task is assigned. If the first device delegates the task to the second device, the first device uses the delegate record created when the task was delegated upon receipt of the task cancellation. The cancellation notice is transferred to the second device. If the second device delegates the task to the third device, the second device uses its delegate record to receive the third device upon receipt of the task cancellation from the first device. Forward the task cancellation message to. As will be apparent to those skilled in the art, this process can continue for any number of delegates, such as to a fourth device, to a fifth device, and so on. Each delegate-source device deletes the delegate record for the task at the time when the transfer indicating task cancellation is completed.

If the task is canceled in the device to which the task is assigned, the cancellation is transmitted to the server, and the server transfers the cancellation to the first device to which the task is assigned. The first device forwards the cancellation to the second device and deletes its own delegate record for the task. The transfer process can be repeated, such as to a third device, to a fourth device, etc. if the task is redegated multiple times. In an alternative implementation, the cancellation source device sends a cancellation message to the destination device to which it has assigned the task. That is, the second device transmits a cancellation message to the first device, and the first device deletes its own delegate record and forwards the cancellation message to the server. Again, this cancellation process can be performed for any number of delegates (eg, cancellation is from the fourth device to the third device, to the second device, and to the first device To the server by the first device).

  Canceling a task is a duplicate of another task (which can occur when an automatic device has generated a repair task because it has detected a failure, but the same malfunction caused multiple failure events), and the task is incorrect Generated (eg, when starting an assembly line, a particular series of machine activations appear to indicate a device failure, but in fact nothing has happened and all machines start to stabilize) or The task is contained in another task (eg, a task is generated to perform maintenance on the machine, but as a result of the failure of the same machine, another task replaces the maintenance task. May be needed for many reasons, such as

  Task Delegate Method 2 can occur when a delegate is made using a P2P link between devices while both devices are isolated from GRPS, Wi-Fi, and other methods of communication with the server. This is useful when at least the first device is not in communication with the server at the time of the delegate. If the checkpoint message sent by the first device to the second device is sent from the server to the first device, then the second device is in contact with the server, so even if the first device is Even if there was no opportunity to send a task delegate notification, the server was notified about the task delegate, and the first device no longer needs to track the delegate task, and therefore is associated with the received checkpoint message. It is clear that the log entry can be erased to the point where it contains the task that was submitted.

  Thus, as will be appreciated, a typical, exemplary, and non-limiting implementation is, for example, when communication between a wireless network device and other more robust network devices is unreliable. Reliable interoperability that can establish a local wireless connection, even when intermittent, when bandwidth is limited, or when resources of one or more of the devices are limited To enable the exchange of “nodes”, commands, and other data items between devices so that a method of action can be provided between a user of a first device and a user of a second device; A system, apparatus, and software are provided. More efficient communication, resource allocation, and task delegates can be achieved using the methods, systems, and apparatus described herein.

  Although the techniques herein have been described in connection with exemplary, exemplary, and non-limiting embodiments, the invention is not limited to this disclosure. The invention is defined by the following claims and is intended to cover any and all equivalent and equivalent configurations, whether specifically disclosed herein or otherwise. .

Claims (49)

Ability to communicate successfully in any or all cases where the availability of the communication path lacks continuity, changes from place to place, becomes available using different means depending on time or place A method for communicating with a mobile / portable device (1110) while enhancing
Enabling communication with a mobile / portable device (1110) through a first communication path (1200);
Enabling communication with the mobile / portable device (1110) through a second communication path (1200) that is at least partially different from the first communication path (1200);
Communicating a signal representative of at least a first portion of a node structure through the first communication path (1200);
Communicating a signal representative of at least a second portion of the node structure through the second communication path (1200);
Features
Further, in order to increase the possibility of successful communication of the node structure, the signal transmitted through the first communication path (1200) and the signal transmitted through the second communication path (1200) Using, wherein the use includes coordinating overlapping information carried through the first and second communication paths (1200). The method of claim 1, further comprising:
In order to use a communication path (1200) that is more preferable than a less preferable communication path (1200) for different parts of the same node structure depending on the situation, the first communication path and the second communication path ( 1200). The method according to claim 1, further comprising:
A method of dynamically switching between the first communication path and the second communication path (1200). The method according to any one of claims 1 to 3, further comprising:
A method of using the first and second communication paths (1200) one at a time. The method according to any one of claims 1 to 4, further comprising:
Method of using both said first and second communication paths (1200) simultaneously for said same or different parts of said node structure. The method according to any one of claims 1 to 5, further comprising:
The method, wherein the first and second communication paths (1200) have different characteristics. The method of claim 6, further comprising:
The method, wherein the first and second communication paths (1200) have different speed / bandwidth characteristics. The method of claim 6, further comprising:
The method, wherein the first and second communication paths (1200) have different reliability. The method of claim 6, further comprising:
The method, wherein the first and second communication paths (1200) have different usage costs. The method of claim 6, further comprising:
The method, wherein the first and second communication paths (1200) use different communication protocols. The method of claim 6, further comprising:
The method wherein the first and second communication protocols use different transmission media. 12. The method according to any one of claims 1 to 11, further comprising:
A method characterized by using out-of-band transmission to transmit the data items by any or all of the time, sequence, means other than the preferred communication path (1200). A method according to any of claims 1 to 12, further comprising:
Providing preferential messaging in which a transmission method is determined based in part on characteristics of the data item to be transmitted. A method according to any of claims 1 to 13, further comprising:
A method of detecting and eliminating duplicate node structures and data items, whether the occurrence of duplicates is accidental or intentional. 15. A method according to any of claims 1 to 14, further comprising:
A method using a push mode transmission model in which a sender contacts a receiver to initiate a transfer of a node structure. A method according to any of claims 1 to 15, further comprising:
A method using a coordinated push mode transmission model in which a sender contacts a recipient and sends a node structure that includes a command requesting the recipient to initiate a pull mode session. 17. A method according to any of claims 1 to 16, further comprising:
The method wherein the sender request and the recipient pull mode session occur on different communication paths (1200). A method according to any of claims 1 to 17, further comprising:
Using a peer-to-peer (P2P) node structure transmission model to transmit a node structure between said device (1110) and another device (1110), further comprising: Can initiate communication and one or both can transmit a node structure to the other. A method according to any of claims 1 to 18, further comprising:
Using an announcement and acceptance (A & A) mechanism to identify one or more users who are willing to accept the assignment of one or more identified tasks and provide them with those tasks And how to. A method according to any of claims 1 to 19, further comprising:
From the first device (1110) to the second device (with or without the help of the server)
1110) using a task delegate to forward the task to. A method according to any of claims 1 to 20, further comprising:
A method characterized by using a flexible security model that allows restricting access, use, or modification to data items, data items, devices (1110), or servers. A method according to any of claims 1 to 21, further comprising:
A method for identifying and resolving differences between a catalog of a first device (1110) and a catalog of a second device (1110). Successful if any or all of the availability of the communication path (1200) lacks continuity, changes from place to place, becomes available using different means depending on time or place A mobile / portable device (1110) comprising a configuration that increases the likelihood of communication, comprising:
A first communication interface that enables communication through a first communication path (1200);
A second communication interface enabling communication through a second communication path (1200) that is at least partially different from the first communication path (1200);
In addition,
A signal representing at least a first part of the node structure is communicated through the first communication path (1200), and a signal representing at least a second part of the node structure is communicated through the second communication path (1200). A communication controller;
In order to increase the possibility of successful communication of the node structure, the signal transmitted through the first communication path (1200) and the signal transmitted through the second communication path (1200) are used. The use includes coordinating overlapping information carried through the first and second communication paths (1200); and
Device characterized by. The device (1110) of claim 23, further comprising:
In order to use a communication path (1200) that is more preferable than a less preferable communication path (1200) for different parts of the same node structure depending on the situation, the first communication path and the second communication path ( 1200). A device characterized by means for making a selection between. 25. A device (1110) according to any of claims 23 to 24, further comprising:
A device characterized by a switch configured to dynamically switch between the first communication path and the second communication path (1200). A device (1110) according to any of claims 23 to 25, comprising:
Further, the device is characterized in that the first and second communication interfaces are configured to use the first and second communication paths (1200) one at a time. 27. A device (1110) according to any of claims 23 to 26, comprising:
Further, the first and second communication interfaces are configured to simultaneously use both the first and second communication paths (1200) for the same or different portions of the node structure. A device characterized by that. 28. A device (1110) according to any of claims 23 to 27, comprising:
Further, the device wherein the first and second communication paths (1200) have different characteristics. 29. A device (1110) according to claim 28, comprising:
Further, the device wherein the first and second communication paths (1200) have different speed / bandwidth characteristics. 29. A device (1110) according to claim 28, comprising:
Further, the device characterized in that the first and second communication paths (1200) have different reliability. 29. A device (1110) according to claim 28, comprising:
The device wherein the first and second communication paths (1200) have different usage costs. 30. The device (1110) of claim 28, further comprising:
The device, wherein the first and second communication paths (1200) use different communication protocols. 30. The device (1110) of claim 28, further comprising:
The device, wherein the first and second communication protocols use different transmission media. 34. A device (1110) according to any of claims 23 to 33, further comprising:
The first and second communication interfaces are configured to use out-of-band transmission to transmit the data item by any or all of time, order, means other than the preferred communication path (1200). A device characterized by that. A device (1110) according to any of claims 23 to 34, further comprising:
A device characterized by a node structure prioritization module that provides preferential messaging by determining a transmission technique based in part on the characteristics of a data item to be transmitted. 36. A device (1110) according to any of claims 23 to 35, further comprising:
The processor detects and eliminates duplicate node structures and data items, whether the occurrence of duplicates is accidental or intentional. A device (1110) according to any of claims 23 to 36, further comprising:
The communication controller uses a push mode transmission model in which a sender contacts a receiver to initiate a transfer of a node structure. A device (1110) according to any of claims 23 to 37, further comprising:
The device, wherein the communication controller uses a coordinated push mode transmission model that sends a node structure that includes a command that requests the receiver to contact the receiver and initiate a pull mode session. The device (1110) according to claim 38, further comprising:
The device, wherein the sender request and the recipient pull mode session occur on different communication paths (1200). 40. The device (1110) according to any of claims 23 to 39, further comprising:
The communication controller uses a peer-to-peer (P2P) node structure transmission model to transmit a node structure between the device (1110) and another device (1110); A device, characterized in that it can initiate communication and either can transmit a node structure to the other. 41. A device (1110) according to any of claims 23 to 40, further comprising:
A device characterized by an announcement and acceptance (A & A) mechanism for identifying one or more users who are willing to accept an assignment of one or more identified tasks and providing them with those tasks. A device (1110) according to any of claims 23 to 41, further comprising:
A device characterized by a task delegate module that transfers tasks from the first device (1110) to the second device (1110) with or without the aid of a server. Device (1110) according to any of claims 23 to 42, further comprising:
A device characterized by a flexible security configuration that allows restricting access, use, or modification to data items, data items, devices (1110), or servers. The device (1110) of claim 23, further comprising:
A device characterized by a catalog module for identifying and resolving differences between the catalog of the first device (1110) and the catalog of the second device (1110). A method for providing task selection comprising:
Transferring the task assignment from the first device (1110) to the second device (1110);
Notifying the second device (1110) that the task assignment has been canceled;
Identifying and resolving differences between the catalog of the first device (1110) and the catalog of the second device (1110);
A method characterized by. A handheld portable messaging / tasking device (1110) comprising:
A hand-held case,
A display arranged on the case;
A processor disposed within the case and coupled to the display;
A first wireless communication interface disposed within the case and coupled to the processor for communicating through a first wireless path (1200) using a first wireless protocol; A wireless communication configuration comprising: a second wireless communication interface for communicating through a second wireless path (1200) using a second wireless protocol different from the first wireless protocol;
In addition,
A node processor for communicating messaging related to node synchronization via the wireless communication configuration, wherein the wireless communication configuration includes node information that overlaps information communicated through the second communication path (1200). Increasing the likelihood of successful synchronized node communication by communicating through the first communication path (1200), the tasking corresponding to the synchronized node at least in part on the display A device characterized by a node processor for displaying messaging information. The device (1110) of claim 46, further comprising:
The device, wherein the node processor coordinates overlapping information carried through the first and second communication paths (1200). The device (1110) of claim 46, further comprising:
The device, wherein the first protocol includes cellular wireless telephony and the second protocol includes Bluetooth. The device (1110) of claim 46, further comprising:
The device, wherein the first protocol includes 802.11 and the second protocol includes Bluetooth.

Images