EP2340666A2 - Système et procédé destinés à la sélection d'une voie de communication automatique et dynamique, la synchronisation d'un dispositif distribué et une délégation de tâche - Google Patents

Système et procédé destinés à la sélection d'une voie de communication automatique et dynamique, la synchronisation d'un dispositif distribué et une délégation de tâche

Info

Publication number
EP2340666A2
EP2340666A2 EP09815336A EP09815336A EP2340666A2 EP 2340666 A2 EP2340666 A2 EP 2340666A2 EP 09815336 A EP09815336 A EP 09815336A EP 09815336 A EP09815336 A EP 09815336A EP 2340666 A2 EP2340666 A2 EP 2340666A2
Authority
EP
European Patent Office
Prior art keywords
communication
further characterized
node
communication path
devices
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP09815336A
Other languages
German (de)
English (en)
Other versions
EP2340666A4 (fr
Inventor
Jeffrey G. Bonar
Bryan Tafel
Adrian Pekarek
Subir Chhibber
Kenneth G. Tomazin
Karl Ginter
Michael Bartman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
JumpStart Wireless Corp
Original Assignee
JumpStart Wireless Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by JumpStart Wireless Corp filed Critical JumpStart Wireless Corp
Publication of EP2340666A2 publication Critical patent/EP2340666A2/fr
Publication of EP2340666A4 publication Critical patent/EP2340666A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/02—Diversity systems; Multi-antenna system, i.e. transmission or reception using multiple antennas
    • H04B7/022—Site diversity; Macro-diversity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/02—Diversity systems; Multi-antenna system, i.e. transmission or reception using multiple antennas
    • H04B7/022—Site diversity; Macro-diversity
    • H04B7/026—Co-operative diversity, e.g. using fixed or mobile stations as relays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/02—Arrangements for detecting or preventing errors in the information received by diversity reception
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Definitions

  • the technology herein relates to systems, software, and apparatuses that provide wired and wireless telecommunications under, among other things, conditions where signal strength is poor or intermittent.
  • the exemplary illustrative non-limiting technology herein provides for, among other things, the coordination and synchronization of data and workflows across various communication links under such conditions, including between intermittent or unreliable communications Sinks, and the management of wireless mobile applications in such environments.
  • the technology herein further relates more generally to the fields of computer science, telecommunications, and data management. BACKGROUND AND SUMMARY
  • Wireless communication allows two or more electronic devices to exchange information without the need for a physical connection (i.e., a wire or cable) between the devices.
  • Wireless can be fixed or mobile/portable.
  • fixed wireless allows wireless communication from one fixed location to another fixed location or between a fixed location and a mobile/portable device.
  • Mobile/portable wireless permits communication between a fixed (e.g., central) site and a movable device, and/or between two or more mobile/portable devices.
  • the level of connectivity e.g., the signal intensity and other relevant parameters
  • between two sites in a fixed wireless environment is typically fairly constant (assuming constant weather and other conditions), because neither site ever moves.
  • Mobile wireless devices also referred to herein as wireless devices or mobile devices
  • pagers include pagers, mobile phones, and combination devices that include the functionality of mobile phones, pagers, personal digital assistants (PDAs) as just some examples. These devices can allow the exchange of textual information (e.g., using pagers, cell phones, or PDAs) as well voice and data (e.g., using cell phones and PDAs).
  • textual information e.g., using pagers, cell phones, or PDAs
  • voice and data e.g., using cell phones and PDAs.
  • a plurality of communication interfaces can allow optimization of communication path use by selection of communication path(s) with the best match(es) between transmission requirements and communication path characteristics and features, but such optimizations are not necessarily common, or done using predefined preferences supplied by device manufacturers. Devices that support only a single communication interface are generally not capable of such optimizations.
  • Wireless devices have also recently been integrated with useful features such as global positioning system (GPS) access, cameras, and scanners (including scanners able to process radio frequency identification (RFID) and barcodes), and magnetic or optical data storage cards.
  • GPS global positioning system
  • RFID radio frequency identification
  • barcodes magnetic or optical data storage cards.
  • Mobile wireless devices generally communicate using electromagnetic waves such as but not limited to radio waves. Transmitters send a signal from a wireless communication point-of- presence to a wireless device, while receivers process a signal received at a point-of-presence from a device. Transceivers both send and receive.
  • a point-of-presence comprises one or more transmitters, receivers and/or transceivers that can communicate with a mobile wireless device.
  • a communication tower in a cellular telephone network and a wireless LAN connection at a coffee shop are non-limiting examples of points-of-presence.
  • a central site in contact with a network of points-of-presence can control the communication between the device and the appropriate point of presence.
  • Points-of-presence are sometimes spaced so that their coverage areas overlap to allow continuous communication as a device moves.
  • information can be sent and received appropriate to the capabilities of the device.
  • a pager can be out of range for a few minutes or hours, mobile phone calls are cut off in mid-sentence, and data services only partially compiete communications sequences and transactions, resulting in data loss.
  • Current practice has resulted in a number of different services with various characteristics for connecting wireless devices to each other or to non-mobile devices or to the Internet.
  • Cell phone providers often supply data services to their subscribers as well as voice phone service.
  • data services include Circuit Switched Data (CSD), General Packet Radio Service (GPRS), and enhanced versions of it, such as Enhanced Data rates for GSM Evolution (EDGE) or Enhanced GPRS (EGPRS), as well as "next generation” systems such as Universal Mobile Telecommunications System (UMTS).
  • CSD Circuit Switched Data
  • GPRS General Packet Radio Service
  • EDGE Enhanced Data rates for GSM Evolution
  • GPRS Enhanced GPRS
  • UMTS Universal Mobile Telecommunications System
  • SMS Short Message Service
  • the implementation details of each of these services vary, but are transparent to most users. The most apparent difference is the bandwidth, or data rate, that each provides.
  • the data rate is currently between 9.6 Kbits/second for CSD and 16 M bits/second for UMTS.
  • so-cailed 3G mobile communications standards allow simultaneous use of speech and data services and data rates of up to 14.0 Mbit/s on the downlink and 5.8 Mbit/s on the uplink.
  • these services are used directly by devices other than cell phones, such as PDAs, or indirectly by devices such as laptops though the use of adapter cards or the use of a tethered ceil phone or other device as a data communications device.
  • Cellular data services support various data protocols, usually including TCP/IP, over the ceil provider's data network and, often through a gateway, to systems on the Internet.
  • TCP/IP Transmission Control Protocol/IP
  • Such connections can be slow compared to some wired technologies, and can also be expensive, with some providers charging a fixed monthly fee and others charging based on the number of bytes of data transmitted.
  • Coverage for these services is sometimes more limited than coverage for voice phone calls through the same cell service provider, but is still generally available in most cities and along major routes between cities.
  • TCP/IP connections thus generally originate from the mobile device, because only the mobile device is aware of its own current TCP/IP address and can include this in TCP/IP data packet headers as required by the TCP/IP protocol.
  • some hotspot providers use a technique called Network Address Translation (NAT) to ailow sharing a single IP address by all of the devices in the hotspot.
  • NAT Network Address Translation
  • NAT prevents connection to devices using the hotspot from devices outside the hotspot, unless a device inside the hotspot first establishes a connection to a device outside the hotspot, and even then the connection to the device in the hotspot can be limited to specific protocols, such as File Transfer Protocol (FTP).
  • FTP File Transfer Protocol
  • connections are generally bi-directional, with data being sent to or from the mobile device, to or from a server device, or to/from another mobile device.
  • These protocol and infrastructure limitations can prevent TCP/IP push mode connections to mobile devices and can reduce the responsiveness of the system as a whole when servers or other mobile devices have data to send to a mobile device.
  • some mobile devices and the services that connect them support other data protocols, such as Short Message Protocol (SMS), or Multimedia Messaging Service (MMS).
  • SMS Short Message Protocol
  • MMS Multimedia Messaging Service
  • These protocols can have advantages over TCP/IP, such as the ability to send to a mobile device using push mode, and disadvantages, such as delayed transmission, limited message size, content limitations, and high cost (e.g. several cents per message). Delivery of data is often unreliable as well, such as with SMS and its "best attempt" delivery, where delivery is attempted, but is not guaranteed.
  • peer-to-peer P2P
  • TCP/IP Transmission Control Protocol
  • Bluetooth Bluetooth
  • SMS Short Streaming Protocol
  • Ethernet Ethernet
  • P2P peer-to-peer
  • Dynamic DNS Dynamic Domain Name System
  • a device registers its address with a DNS server, allowing other devices to learn its address and initiate communication with it, but due to information caching, and the sometimes rapid change in address common with mobile devices which can move from one hotspot to another in a brief time, this solution is often not reliable and sometimes may not be usable at all.
  • device discovery and authentication involved with P2P. Devices may in some contexts be asked to acquire information about the existence of other devices, as well as any methods or information necessary to establish communications with those other devices. A means of providing or obtaining this information would be useful.
  • Bluetooth can be useful for extending connectivity into areas which are shielded from technologies such as GPRS (i.e. inside structures such as factories or large buildings or underground in deep basements) as well as where Wi-Fi is not practical or desirable, such as connecting a portable device through a vehicle link where W ⁇ -Fi's greater range could constitute a security concern, or in cases where devices need to exchange data and Bluetooth's peer-to-peer capabilities permit this, whereas Wi-Fi's TCP/IP addressing limitations for mobile devices can prevent it.
  • Bluetooth also is often used as a link to devices that support methods for connecting to remote devices, such as dialup modems, Ethernet interfaces, Token Ring Adapters, or others.
  • Bluetooth-enabled devices can connect and communicate wirelessly over radio links through short-range, ad hoc networks known as piconets.
  • piconets short-range, ad hoc networks
  • each device can simultaneously communicate with up to seven other devices within a single piconet, with one device acting as "master” and the others acting as “slaves.”
  • Each device can also belong to several piconets simultaneously.
  • Piconets are established dynamically and automatically as Bluetooth-enabled devices enter and leave radio proximity. Radio proximity can vary from a foot or two to several hundred feet, depending on the class of the devices involved. Piconets also can be connected by systems acting as bridges between them. Such arrangements are known as "scatternets.”
  • Bluetooth devices transfer data at a rate of 721 Kbits/second, using various protocols, including TCP/IP in some devices, using methods that are resistant to interference and which can include encryption of data and cryptographic identification of other devices.
  • Bluetooth devices support the same protocols, and many are special purpose devices, such as headphones or barcode readers, which do not support use of nodes or other externally supplied programming.
  • Other Bluetooth devices are intended to act as network interfaces, however, and can support the connection of Bluetooth-enabled PDAs, computers, or other such devices to LANs or the internet. It also is possible for two or more PDAs, laptops, or other Bluetooth-enabled devices to exchange data in a Peer-To-Peer manner. Exactly which protocols and functions of the Bluetooth or other standard are supported by a given device are determined by the manufacturer of that device and in some instances cannot be altered afterward in at least some devices.
  • Wi-Fi Wireless Fidelity
  • Wi-Fi is a wireless technology brand owned by the Wt-Fi Alliance intended to improve the interoperability of wireless LAN products based on the IEEE 802.1 1 standards.
  • the Wi-Fi Alliance is a consortium of separate and independent companies agreeing to a set of common interoperable products based on the family of !EEE 802.1 1 standards.
  • a Wi-Fi device such as a laptop computer, cell phone, or PDA can connect to a LAN when in range of a wireless network access point (WAP) that is connected to the network. If the network is connected to the Internet, the Wi-Fi device can access the Internet through the network's gateway or other means.
  • WAP wireless network access point
  • Hotspots can cover as little as a single room or as much as several square miles by using overlapping access points. Hotspots are available in many businesses, homes, and public facilities (such as airports), and some localities have implemented Wi-Fi networks that cover entire towns, college campuses, etc. [0014] Generally speaking, Wi-Fi also allows connectivity in peer-to- peer (wireless ad ⁇ hoc network) mode, which enables devices to connect directly with each other, although this capability is often disabled for security reasons. Ad-hoc wireless networks are advantageous e.g., when two or more devices share network connections between themselves, but do not require access to external servers or the Internet.
  • Wi-Fi can support bandwidths up to several or many Mbits/second, is inexpensive or free with most commercial hotspots charging a fixed fee for use, or using provision of free access as a way to attract customers, and has very little delay and good reliability. In many or most cases, the coverage is limited to a small area, and leaving the coverage area terminates connectivity, usually with little or no warning.
  • the method of addressing used with Wi-Fi hotspots can make connecting to mobile devices from devices which are not on the hotspot's LAN impossible, and connections generally must be originated by the mobile devices.
  • This use of a server-push-capabie communication path to request the mobile device to initiate a connection to the server using a different communication path that is not server-push-capable is sometimes referred to as "cooperative-push.”
  • the server can employ any server- push-capable communication path to initiate a cooperative-push exchange.
  • Some devices have the capability 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 implementations are typically determined by the design and configuration of the specific device. Devices that can support a plurality of communication interfaces typically manage the use of these interfaces in various ways, in some exemplary implementations, the device can automatically choose which interface(s) to use at a given time using configuration settings that define user preferences. In other devices, the choice of communication interface is made manually by the user, by application software, or by the design of the device or its operating system.
  • Prior art systems such as the Apple iPhone, from Apple Computer, Cupertino, CA as one example, provide device implementations that can automatically switch communication interfaces so as to maintain some form of communication in a manner that is transparent to application software running on the device.
  • Other prior art systems do not switch communication paths transparently and may require application software to take certain actions to switch communication interfaces when a communication interface being used by an application loses connectivity. These actions may vary with the design or configuration of the mobile device, and can include such things as attempting to re-establish a connection so as to cause the device to discover communication interfaces with available connectivity, selecting a new communication interface from among those still available, and then re-establishing server connections, or other actions that are well known to those familiar with particular device implementations.
  • Devices which detect loss of connectivity generally do so based on signal strength, polling or other characteristics of the connectivity link to the nearest point of presence, and do not necessarily detect losses of connectivity that happen in other segments of the connection, such as a breakdown in the point of presence's connection to the service provider's infrastructure, or the service provider's connection to the Internet. Losses other than signal loss do not necessarily result in failover to an alternate interface in most devices. This can adversely affect communication between a mobile device and disparate devices or servers.
  • Some devices that can support a plurality of communication interfaces do not necessariiy switch between them until and unless there is a detectable loss of connectivity.
  • Some such devices do not necessariiy dynamically switch between available interfaces as interface connection availability changes. This can result in continued use of a less efficient communication interface even after a more efficient interface becomes usable. This can result in higher costs, slower data transmission, slower responsiveness for users, and other undesirable results.
  • a device When a device is currently receiving streaming video in a Wi-Fi hotspot, and the device is moved out of the coverage area of the hotspot into an area without Wi-Fi service, the device can switch to using EDGE, but the streaming video application does not function with the same fidelity and features using EDGE as it did with Wi-Fi.
  • intermittent tasks such as downloading e-mail messages do not necessarily require substantial bandwidth in most cases.
  • An intermittently connected e-mail application is unlikely to be disrupted by such a change in communication interface, and can retry and communicate in the background to download larger or more email messages.
  • Bandwidth is typically only one of many characteristics that can result in certain communications interfaces being preferable to others, or in certain applications being restricted as to choice of communications interface.
  • Cost, reliability, out of band support, transmission delays, geographic distribution, and terms of service are examples of some of these.
  • An ability to be aware of the available communication interfaces, their characteristics and features, and to select interfaces appropriate to the type of data to be transmitted or received is often useful to make the most efficient use of all available communication interfaces.
  • Another issue with wireless applications is synchronizing data held in the mobile device's storage with data maintained on servers or other devices.
  • Some applications are created with the assumption that connectivity is maintained all or most of the time; and the applications simply access the needed data from the servers or other devices as needed. Because some classes of mobile devices frequently cannot connect with servers or other devices, important applications may be rendered unusable much of the time.
  • Other applications are created with the assumption that communications are unavailable frequently, but that connectivity exists often enough to enable the applications to reach a required server or other device most of the time.
  • Such applications may cache data as it is used, in an attempt to keep data that is likely to be needed again in the device's storage for use during the short periods when connectivity is not available.
  • a related problem is performing updates of locally cached data in an environment where connectivity can appear and disappear without warning.
  • Tubes is a network-based service that maintains data sets on a plurality of devices such that changes made to the data on any device are propagated to all of the other devices. Because data is maintained on each device, the data is available for use whether or not the device has connectivity. If connectivity is lost before synchronization is complete, the software automaticaliy resumes the task when connectivity is restored.
  • mesh networking employs one of two node connection arrangements: full mesh topology or partial mesh topology.
  • full mesh topology each node is connected directly to each of the others.
  • partial mesh topology some nodes can be connected to all the others, but other nodes are connected only to those nodes with which they exchange the most data. Connections can be wired or wireless.
  • mesh networks route data, voice and/or instructions between nodes and allow for continuous connections and reconfiguration around broken or blocked paths by passing data from node to node ("hopping") until the destination node is reached.
  • hopping node to node
  • mesh networks differ from other networks in that the component parts can all connect to each other via multiple hops.
  • the nodes can, by way of non-limiting example, comprise data and/or instructions that describe at least one action or at least one aspect of the process they are a part of, as well as information that allows for the processing, ordering, identification, transmission, and handling of the nodes themselves.
  • the '149 application's descriptions of basic creation, handling, storage, transmission, structure, and processing of nodes is incorporated by reference here.
  • Nodes can be collections of data having defined configurations and varying content, which are created by, stored, and transferred between devices. Nodes can for example control the devices by controlling the processing of data and program instructions by the devices.
  • the technology can be configured to manage multiple data types, including, but not limited to, text, image (both single images and sequences of images), signature information, data encoding sounds, data from input devices (e.g. barcodes, optical data, radio-frequency identification (RFID), and magnetic card scanners), information obtained from magnetic materials (e.g., from credit or identification cards), information being sent to a printing device, and information related to geographic location (e.g., global positioning system, "GPS") as well as other arrangements.
  • GPS global positioning system
  • an exemplary illustrative non- limiting implementation includes a TMC device (1300a) (a server) connected to a mobile wireless device (1110) through one or more wireless networks (1200a, 1200b).
  • Nodes and Commands are retrieved from server Node Storage (1540) by the Node Manager (1570) and sent by the Dispatch Manager (1560) through a Communication Interface (not shown), over a wireless network (1200a or 1200b) to a Communication Interface (2210, 2220, or 2230) of the wireless mobile device.
  • the wireless device's operating system which manages the communication interfaces, sends the nodes to the Dispatch Module of the wireless mobile device (2310), which processes them and passes them to the Node Storage Module (2330), or the Display Module (2320), where they are stored or processed.
  • Exemplary illustrative non-limiting implementations described herein provide systems, apparatuses, software and other arrangements for enabling the exchange of "nodes," commands, and other data items between devices so as to provide a reliable method of interaction between a user of a first device and a user of a second device that can establish a local wireless connection even when communications between the wireless network and other more robust network devices are unreliable, intermittent, have limited bandwidth, or when one or more of the devices have iimited resources.
  • the implementation of the technology provided herein is provided using a hosted service provider business model, in which wireless infrastructure, mobile devices, and the various integration servers are provided by a central facility that is used by users on an as needed basis.
  • Providing the technology in this manner allows the users to focus on their business and not on the deployment and management of infrastructure components.
  • the nature of the architecture permits multiple users from different companies to transparently share common infrastructure without interfering with each other.
  • the technology is implemented using other models as will be familiar to persons having ordinary skill in the art, such as those wherein a single company owns the infrastructure and provides access to said infrastructure for their people.
  • systems, software, and apparatuses enable transmission of data items between two or more devices using one or more transmission technologies (Ae., a communication path), either one at a time (e.g. sequentially) or more than one at a time (e.g. in parallel) and whether the transmission technologies provide for in-band and/or out-of-band transmissions; so as to allow applications to communicate in an environment where each communication path's availability changes unpredictably and where various communication paths have differing capacities, reliability, capabiiities, and methods of operation.
  • transmission technologies Ae., a communication path
  • coordination of transmitted data items is performed over the available communication paths such that data item synchronization between devices involves one or more communication paths that are available, either serially or in parallel, with one or more of the communication paths being intermittently interrupted, such that the data items (e.g. templates, nodes, or node stacks) helpful to implement at least an aspect of the system are communicated without loss or undetected duplication.
  • Data items are intentionally sent by a first device using multiple transmission methods to compensate for unpredictable delays associated with some methods to reduce the transmission delay as perceived by the user as much as possible.
  • the second device detects data items that are duplicated by the manner of transmission, and duplicate copies are eliminated as redundant.
  • FIG. 30 Another exemplary illustrative non-limiting implementation of the technology described herein provides means to initiate transmissions from a first device to a second device ("push mode"), in contrast to prior art devices and systems that rely on the second device to poll a first device to initiate transmission of data items between first and second devices (“pull mode").
  • Push mode by an exemplary illustrative implementation of the technology herein is performed directly, where the first device initiates the transmission and sends data items using the same communication path used to initiate the transmission, or indirectly in "cooperative push mode," where the first device uses push mode to transmit a first portion of the data item(s), which is used by the a second device as a request for the second device to initiate a pull mode communication session to transfer a second portion of the data item(s) using the same or different transmission technology that can support moving the second portion of the data item(s), but which lacks characteristics required to support push mode for the entire data item or set of data items, or which have other desirable characteristics, such as large bandwidth, high reliability, or low cost.
  • the first device uses known information concerning the device type of the second device, in combination with a database of device capability information, to determine whether the second device supports push mode or any limitations that may exist on such ability where it exists. For instance, some device types do not accept push mode connections while a voice phone call is in progress or while certain applications are executing. Other device types do not have these limitations.
  • the push mode characteristics of a first communication path can differ from the push mode characteristics of a second communication path. For example, an SMS message can be delivered seconds or hours after it is sent, or not delivered at all, with no notification to the sender, while a TCP socket transmission will either succeed or fail within seconds, with the transmitting system being informed of the success or failure almost immediately.
  • the exemplary illustrative technology herein provides means to manage multiple communication technologies so as to, optionally, dynamically optimize one or more communication aspects for the device, such as cost, throughput, reliability, availability, transmission delay, interactive responsiveness, or others by using one or more communications technologies at a time, switching between available communications technologies as appropriate, using disparate communications technologies for those functions that each is best suited for, sending data items redundantly using a plurality of communication paths, each of which can make use of a different device communication technology, or by other means that will be apparent to those skilled in the art.
  • These extended capabilities can, for example, allow devices to switch to an alternative communication path when communication using a particular communication path is lost, or to increase total throughput by using multiple communication paths simultaneously.
  • a communication path established by means of a supported and available communication technology, is configured to specify additional mechanisms for its management and use.
  • the data items sent over a communication path are encrypted, compressed, or protected from tampering or damage through the use of checksums or other mechanisms.
  • additional optional mechanisms are used for some portions of a communication path and not for others or for an entire communication path from a first device to a second device.
  • the data Item transfer provided by the exemplary illustrative technology herein is carried out using one or more communication technologies, such as wireless telephony using GPRS/Edge, EVDO, wireless networking using 802.1 1 (Wi-Fi), or by other wireless and wired means, by the devices.
  • the devices are standard computers, such as server, desktop or laptop computers, wireless portable devices such as cell phones, PDAs, or other such devices, emulated devices, or any combination of any number of these.
  • the exemplary iilustrative technology herein provides additional capabilities and functions, such as permitting Peer-to-Peer (P2P) data item exchange, delegation of tasks from a first device to a second device with, or without, the assistance of a server, announcing an available task to a plurality of devices, collecting responses, selecting one or more devices to assign the task to from among those responding affirmatively, and assigning the task to the selected device(s), propagation of task completion, or task cancellation data items along a chain of delegations, synchronization of catalog data items between devices with or without the intervention of a server, and security templates that permit flexible specification of limitations and permissions for use of data items, sets of data items, or communication methods by devices.
  • P2P Peer-to-Peer
  • Additional exemplary illustrative non-limiting features and advantages include: Use of multiple communication paths, whether one at a time or more than one at a time, and regardless of differing characteristics, such as speed/bandwidth, reliability, cost, protocol, transmission medium, or other characteristics, of each communication path, for the transfer of messages from a first device to a second device.
  • Plural communication paths increases the likelihood of a device being able to establish communication with either servers or other devices when communication path availability is not continuous, varies from location to location, or is made available using different means at different times or places. In particular, it addresses the movement of node-based structures over the most advantageous available communications path, and extends the ability of the devices to operate in various operating conditions. E.g. .
  • a first communication path to transport a first portion of a node structure and a second communication path that is at least in part different from the first communication path to transport a second part of the same node structure which enables the devices in communication to switch communication paths without requiring retransmission of the already-sent portion of the message, as well as sending parts of a node structure in parallel over a plurality of communication paths so as to increase apparent bandwidth and reduce total time required for reception of the node structure at the receiver.
  • the receiver has the capability to recognize the parts of a given node structure, to reassemble them in the proper order, to deal with possible redundant reception of node structure parts, regardless of how many different communication paths are used to transmit it. It also adds complications by requiring the transmitting device to select the parts of the node structure to transmit by each communication path.
  • Optional dynamic switching of communication paths to increase the use of preferred communication paths over less preferred communication paths enables the device to make optimal use of the available communication paths as communication paths become available or fail.
  • Optimal use can refer to speed of transmission, reduction of costs, increased responsiveness to the device user, greater security, or other factors. Again, this requires the device to be able to select the portions of the node structure to transfer by each path.
  • OOB transmission where data items are sent at times, in orders, or by means other than a preferred communication path (e.g. sent using MMS over GPRS instead of using TCP/IP over Wi- Fi, or sent between scheduled polling times).
  • OOB transmission enables increases in responsiveness for users, and more timely transmission of high priority data.
  • Priority messaging where transmission methods are determined in part by characteristics of the node structures, or part of the node structure, to be sent. Node transmission priority is a factor in deciding which of a plurality of available communication paths to use, whether to dynamically switch communication paths, whether to send data OOB, and what mode of transmission is permitted for sending the data item. Prioritization of transmission of node structures, in whole or in part, can enable reduction in costs, increased responsiveness in interactive tasks, and flexibility in implementing tasks.
  • Detection and elimination of duplicate node structures can result in duplication of node structures or node structure portions as seen by the receiver, and methods are provided for dealing with this. These methods also deal with the potential for updated versions of node structures to be sent after prior versions of those same node structures have been sent, and for these to arrive at the receiving device in any order or with any timing.
  • a “push mode” transmission model in which a sender contacts a receiver and initiates transfer of messages. This enables an "asynchronous" communication model that can result in shorter communication delays and improved responsiveness for device users over the prior periodic polling, or "pull mode” transmission model. Reduction of bandwidth use is also possible through the elimination of polling requests when there is no data to be transmitted, and with some communication paths this can result in costs reductions.
  • a "cooperative push mode” transmission model in which a sender contacts a receiver and sends a message containing a command that requests that the receiver initiate a pull mode session to transfer one or more nodes and/or node structures. The sender's request and the receiver's pull mode session can occur over different communication paths.
  • Cooperative push mode transmisions permits asynchronous transmission over communication paths that do not support push mode, and is effective at accelerating the transmission of important portions of a node structure.
  • the push mode request can be sent OOB, sent over a plurality of communication paths at once to ensure delivery, and make use of any other supported capabiiity for transmission of one or more nodes and/or node structures.
  • One of the challenges in cooperative push mode style transmissions is the identification of the node and/or node structures to be moved so that the receiver can request them.
  • P2P peer-to-Peer node transmission model for sending nodes and/or node structures between two devices where either can initiate communication, and either or both can transmit nodes and/or node structures to the other.
  • This capability allows devices to interoperate without a requirement that each device has access to a server, permits a plurality of devices to share the communication path resources of any particular device, and thus improves overall connectivity and efficiency in environments of limited communication connectivity.
  • Challenges of P2P environments revolve around the unique identification of nodes so that node structures can be updated and reported back along a plurality of communication paths and topologies without the loss of the device(s) to recognize the unique instances of the node structures for reassembly and subsequent use of the node structures.
  • An "Announcement and Acceptance" (A&A) mechanism for identifying one or more users willing to accept assignment of one or more identified tasks, and then providing the tasks to them.
  • This capability relies on a broadcast capability, where a node and/or node structure can be sent to a plurality of devices. Such broadcasts can be done using a plurality of different communication paths or communication path types, and can be simulated by sending individual transmissions to each device where a one-to-many transmission capability is not supported by a communication path.
  • the A&A mechanism provides challenges in resolving the selection and acceptance of tasks represented by nodes and node structures, and the subsequent selection, prioritization, transmission over available communication paths, and subsequent reassembly and use reporting activities.
  • a task delegation method for transferring a task represented by a node or node structure from a first device to a second device, with or without the assistance of a server By enabling task transfer without a requirement for a server to mediate the transfer, efficiency is improved in scenarios where server communication can not be established or maintained for one or both devices (such as when there is a communication path failure). Methods are required for tracking task ownership for eventual notification of the server or other devices, and for limiting transfer of tasks between devices even when a server is not involved. Such methods must function regardless of what pattern of device to device or device to server communication paths exist during the time the task is active.
  • a task cancellation distribution method for notifying appropriate devices of the cancellation of a task This method supports the complexities resulting from task delegation and task delegation done between devices without the intervention of a server. Such methods must function regardless of what pattern of device to device or device to server communication paths exist during the time the task is active, and often require higher priority selection of the cancellation information over other node transmission requirements.
  • a catalog synchronization method for identifying and resolving differences between catalogs of a first device and catalogs of a second device must support resolution of differences between catalogs of two or more devices when the devices are not in communication with a server, and regardless of the order of updates applied to a device. Limitations on transfer of catalog data to particular devices or classes of device must be maintained even when a server is not involved and the transfer is between devices.
  • Provision of a flexible security model that permits limitation of access to, use or modification of, a data item, a set of data items, a device or server. Such limitations apply to relaying of data items by a first device that has a communication path to a server or a third device for a second device that does not have such a communication path.
  • a method for enabling the exchange of "nodes,” commands, and other data items between devices so as to provide reliable methods of interaction between a user of a first device and a user of a second device that can establish a locai wireless connection even when communications between the wireless network and other more robust network devices are unreliable, intermittent, have limited bandwidth, or when one or more of the devices have limited resources.
  • Figure 1 depicts a schematic diagram of a network comprising a server device, a client device, and network connections between them in accordance with the technology described in commonly-assigned US Patent Application No. 1 1/169,149 incorporated herein by reference.
  • Figure 2 depicts a schematic diagram of a device and network arrangement comprising two server devices, three mobile client devices, and network connections between them.
  • Figure 3 comprises a flowchart depicting exemplary illustrative non-limiting use of Push mode to both send data items and to send commands so as to implement Cooperative Push mode communication.
  • Figure 4 depicts exemplary illustrative non-limiting device and server interactions in a Cooperative Push Mode communication using SMS.
  • Figure 5 comprises a flowchart depicting an exemplary illustrative non-limiting implementation of a method for selecting a communication path.
  • Figure 6 depicts a schematic diagram of an exemplary illustrative non-limiting device having a plurality of communication paths available to a variety of other devices, through a plurality of communication interfaces, in accordance with the exemplary illustrative non-limiting technology herein.
  • Figure 7 comprises a flowchart depicting an exemplary illustrative non-limiting implementation of a Protocol Manager's processing of a message for transmission.
  • Figure 8 comprises a flowchart depicting an exemplary illustrative non-limiting implementation of a Protocol Manager's processing of a message being received.
  • Figure 9 depicts exemplary illustrative non-limiting message flows for the Announcement and Acceptance (A&A) and Catalog
  • Figure 10 comprises a flowchart depicting an exemplary illustrative non-limiting implementation of a method for performing an
  • Figure 11 comprises a flowchart depicting an exemplary illustrative non-limiting implementation of a method for collecting and processing responses to an A&A message.
  • Figure 12 comprises a flowchart depicting an exemplary illustrative non-limiting implementation of a method for delegating an assigned task from a first device to a second device (Method 1 ).
  • Figure 13 depicts exemplary illustrative non-limiting message flows for Task Delegation using either Method 1 or Method 2.
  • Figure 14 comprises a flowchart depicting a exempiary illustrative non-limiting implementation of a method for delegating an assigned task from a first device to a second device (Method 2).
  • Figure 15 depicts an exemplary illustrative non-limiting Security Specification.
  • the current exemplary illustrative non-limiting implementation provides communications systems and devices with important and heretofore unavailable capabilities including, but not limited to:
  • OOB Out Of Band
  • Priority messaging where transmission methods are determined in part by characteristics of the data items to be sent.
  • a "push mode” transmission model in which a sender contacts a receiver and initiates transfer of messages.
  • a "cooperative push mode” transmission model in which a sender contacts a receiver and sends a message containing a command that requests that the receiver initiate a pull mode session. The sender's request and the receiver's pull mode session can occur over different communication paths.
  • P2P Peer-to-Peer
  • A&A An “Announcement and Acceptance” (A&A) mechanism for identifying one or more users wiliing to accept assignment of one or more identified tasks, and then providing the tasks to them.
  • a catalog synchronization method for identifying and resolving differences between catalogs of a first device and catalogs of a second device • A catalog synchronization method for identifying and resolving differences between catalogs of a first device and catalogs of a second device.
  • Provision of a flexible security model that permits limitation of access to, use or modification of, a data item, a set of data items, a device or server.
  • the devices described herein include wireless devices, wired devices, emulated devices, server (TPC) devices and other devices. Aspects of the exemplary, illustrative technology are equally applicable to all classes of devices that experience intermittent or other connectivity, such as for example laptops and PDAs that are intermittently connected to a company LAN, mobile devices that are sometimes iocated where wireless signals are not available, or fixed location devices that do not have reliable communications availability. In addition, it will be appreciated by those with skill in the art that any arbitrary number of devices can communicate with each other in accordance with the technology herein as described herein. [0052] Data items are transferred between devices using communication paths.
  • Communication paths can consist of any communication technology supported by the devices, and can include, without limitation, traditional cellular or other wireless telephony data (e.g. GPRS, EDGE, EVDO 1 SMS), localized wireless networks (e.g. Wireless Fidelity (e.g. Wi-Fi, 802.1 1x) or Bluetooth), wired data mechanisms (e.g. Ethernet, PSTN, serial or parallel data cables, dialup modems, DSL, etc.) or any combination of these with or with additional or other protocols having the capability to transfer messages, or message segments, from one device to another.
  • a communication path comprises implementations of one or more communication technologies, used in sequence or parallel, effective to transfer messages, or message segments, from a first device to a second device.
  • Communication paths can differ in speed/bandwidth, protocol, reliability, availability, cost, or other characteristics.
  • Various implementations of the exemplary illustrative non-limiting implementation can restrict or promote use of particular communication paths by data item type, data item size, data item priority, by security specification permission or limitation, or based on any other characteristic as determined to be proper by those having skill in the art. Additional description of communication paths and their use appears below.
  • An exemplary, illustrative non-limiting implementation of the technology herein is provided using a hosted service provider business model, in which wireless infrastructure, mobile devices, and the various integration servers are provided by a centra! facility that is used by users on an as-needed basis.
  • An exemplary illustrative non-limiting implementation of the technology herein enables transmission of messages, or message segments, between devices using a plurality of communication paths, whether one at a time (e.g. sequential use of a plurality of communication paths), more than one at a time (e.g. use in parallel), and over non-server terminated communication paths.
  • the improved system supports transmission technologies that provide for in- band and/or out-of-band transmissions, so as to allow communication in an environment where each communication path's availability changes unpredictably and where various communication paths have differing capacities, reliability, capabilities, and methods of operation.
  • Coordination of transmitted messages is performed over the available communication paths such that synchronization between devices can involve one or more communication paths that are available, either serially or in parallel, with one or more of the communication paths being intermittently interrupted, such that the data items and/or commands required to implement at least one aspect of the system are communicated without loss or undetected duplication.
  • a first device can intentionally duplicate particular messages by sending using multiple communication paths to compensate for unpredictable delays associated with some communication paths, to reduce the effects of message loss by some communication paths, to reduce the transmission delay as perceived by the user as much as possible, or for any other purpose.
  • Messages or data stems that are duplicated by the manner of transmission are detected by the second device, and duplicate copies are eliminated as redundant.
  • the server devices (2500a & 2500b) ⁇ e.g. TPC devices
  • the wireless mobile devices (2110a, 2110b & 2110c) of the current exemplary illustrative non-limiting implementation can connect with each other in a plurality of ways.
  • a server device (2500b) can connect through a single communication path (2600c), such as a telephony-based EDGE communication path, to a wireless mobile device (2110c).
  • a server (TPC) device (2500a) is connected to a plurality of wireless mobile devices (2110a, 2110b & 2110c) through a plurality of communication paths (2600a, 2600b & 2600c) such as EDGE [260Oc), Ws-Fi (2600b), and SMS (2600a). Furthermore, a server (TPC) device (2500a) is connected to a plurality of wireless mobile devices (2110b & 2110c) through a single communication path (2600b). Additionally, a wireless mobile device (2110c) is connected to a plurality of server (TPC) devices (2300a & 2300b) using one or more communication paths.
  • TPC server
  • a first wireless mobile device (2110a) is connected using one or more Peer-to-Peer (P2P) technologies to a second wireless mobile device (2110b) using a P2P communication path (260Od), such as Bluetooth or Wi-Fi in ad hoc networking mode.
  • P2P Peer-to-Peer
  • Use of available communication paths can be restricted based on security templates, to control which types of data are sent over each. For example, sending a catalog of part numbers over a publicly shared Wi-Fi connection is acceptable, but sending personally identifiable employee payroll data is not.
  • the security specification for the Wi-Fi communication path for a device would specify that it has a low security level, and the security specifications for part number data and payroll data would specify that they require low security and high security, respectively.
  • the part number data's security requirements would match the security level of the Wi-Fi path, and that data could be sent on the Wi-Fi path, but the payroll data's requirement for high security would prohibit it being sent over the Wi-Fi path and it would be held until an appropriately secured communication path becomes available, such as a wired Ethernet connection, or an encrypted short range Bluetooth link, to a payroll system.
  • an exemplary illustrative non-limiting implementation of the technology described herein provides means for a first device to initiate transmissions from a first device to a second device ("push mode").
  • push mode means for a first device to initiate transmissions from a first device to a second device.
  • push mode means for a first device to initiate transmissions from a first device to a second device.
  • push mode means for a first device to initiate transmissions from a first device to a second device.
  • push mode the use of "push mode” as defined and described herein is performed when the first device initiates the transmission and sends one or more messages using a communication path.
  • a second device Upon receipt, a second device receives these transmissions and uses their contents and either operates upon them (e.g. "commands") or stores them for subsequent use (e.g. as with nodes or catalogs).
  • the devices operate in "cooperative push" mode, where the first device uses push mode to transmit a first portion of the data item(s) that is used by the a second device (e.g. as a command, or a data item(s) referencing additional data items) as a request for the second device to initiate a "pui! mode" communication to either a first device or a third device to transfer a second portion of the data item(s) using the same or a different communication path.
  • the selection of communication paths to use is made based upon one or more characteristics of the respective communication paths and the data items to be moved over them, e.g.
  • the user is prompted to activate or relocate the second device, through means such as a page or SMS message, causing the second device to invoke the device's push mode communication (so called "push registry"), vibrate, play a generated or recorded voice message, or other appropriate and available signal, or some combination of these or other prompts as wili be apparent to those of ordinary skill in the art.
  • push registry the device's push mode communication
  • the exemplary illustrative implementation herein also provides for use of alternative communication paths, each with its own characteristics (e.g. cost, bandwidth, push mode support, transmission delay, reliability, availability, etc.).
  • the exemplary illustrative technology herein provides means to manage multiple communication paths so as to, optionally, dynamically optimize one or more communication aspects for the device, such as cost, throughput, reliability, availabiiity, transmission delay, interactive responsiveness, or others by using one or more communication paths at a time, switching between available communication paths as appropriate, using disparate communication paths for those functions that each is best suited for, sending data items redundantly using a plurality of communication paths, or by other means that will be apparent to those skilled in the art,
  • These extended capabilities can, for example, allow devices to switch to an alternative communication path when communication using a particular communication path is lost, or to increase total throughput by using multiple communication paths simultaneously.
  • the exemplary implementation supports many new connection paths and connection path topologies, in addition to new methods of operating within the exemplary architecture. Some examples of these new techniques are described below.
  • a communication path is configured to specify additional mechanisms for its management and use.
  • the data items sent over a communication path are encrypted, compressed, or protected from tampering or damage through the use of checksums or other mechanisms.
  • Such additional optional mechanisms are used for some portions of a communication path and not for others or for an entire communication path from a first device to a second device.
  • a plurality of such optional mechanisms are used simultaneously; for example, when a checksum is computed and added to the data items, the data items and checksum are then compressed and transmitted, with one segment of the communication path performing encryption and decryption of the compressed data items and checksum to prevent disclosure in transit over that communication path segment.
  • security specifications are used to determine the use of data protection mechanisms such as encryption or tamper checks. For example, when sending with high security, data is encrypted and checked for tampering. When sending data items with low security, such means are dispensed with to reduce computational overhead. By use of encryption, tamper checks, or other methods of data protection, the effective security level of a communication path can be raised.
  • a pub ⁇ cly shared Wi-Fi hotspot is a iow security communication path due to the chances of the data being intercepted by others, but if data is strongly encrypted, data that requires moderate, or even high, security can be sent over such a path,
  • P2P Peer-to-Peer
  • TPC server
  • the exemplary illustrative technology herein provides additional capabilities and functions, such as enabling Peer-to-Peer (P2P) message exchange, Out-of ⁇ Band communications, delegation of tasks from a first device to a second device with, or without, the assistance of a server (TPC) device, announcement of an available task to a plurality of devices, collecting responses, selecting one or more devices to assign the task to from among those responding to the announcement, and assigning the task to the selected devices, and synchronization of catalog data items between devices with or without the intervention of a server (TPC) device.
  • P2P Peer-to-Peer
  • TPC server
  • the current exemplary illustrative non-limiting implementation is implemented over any data transfer technology, or combination of technologies, that permits sending blocks of digital data between devices (communication paths).
  • Some exemplary, non-limiting examples include TCP/IP protocol over GPRS, EDGE, Wi-Fi or Ethernet, SMS or MMS over telephony data communication paths, and Peer-to- Peer finks, such as Bluetooth or Wi-Fi "ad hoc" networking, but those having skill in the art can readily see that other technologies could be substituted, whether these technologies currently exist or are developed in the future.
  • Exemplary implementations support a flexible and extensible security capability involving the use of "security specifications.”
  • a security specification is an ordered arrangement of bytes, some of which have particular or limited ranges of values, which are associated with an entity, such as a data item, set of data items, device or server and is used to specify permissions and/or restrictions on access to, use or modification of, the associated entity.
  • Security specifications are associated with entities in various ways. With some entities, such as some data items (e.g. nodes), the security specification is embedded into the entity as a normal aspect of such entities. With other entities, such as communication paths, users, or devices/servers, the security specification is located separately from the entity and associated with it by name, ID, or other reference that permits the applicable security specification for the entity to be located or identified. When not embedded in the entity, security specifications are stored in locations such as catalogs, BLOB nodes, external databases, files, or other locations as determined to be appropriate by those having skill in the art. The method used to locate an externally located security specification for a given entity depends on the storage location and method chosen.
  • Security specifications are created in a variety of ways. When a security specification is embedded into an entity such as a node, the security specification is generated by the method that generates the entity, such as by from specifications in the FDL that creates a node, as part of the node creation process, in some exemplary implementations the security specification is created separately from the entity, whether from FDL specifications or otherwise, and inserted into the entity as a separate step.
  • the method of creation of the security specification can make use of FDL specifications, use a software application capable of creating security specifications from other inputs, such as user command line options, graphical user interface widgets (e.g. buttons, text fields, check boxes, radio buttons, drop-down lists, menus, etc.), descriptions of the security specification in other formats, such as text, XML, or SQL 1 through the use of scripts or templates, or by reference to existing security specifications, or a combination of any or all of these.
  • graphical user interface widgets e.g. buttons, text fields, check boxes, radio buttons, drop-down lists, menus, etc.
  • a security specification that is to be stored in a relational database can be created based on user inputs through a graphical user interface that are used to generate a command line invocation of a script that creates an SQL command from a stored template of an SQL command, which resulting SQL command is used to cause the MySQL database software to create the security specification record in the MySQL database.
  • Exemplary security specifications comprise a plurality of elements, including the ID of the associated entity (when the security specification is not embedded into the entity), a security level specification for the associated entity, security tags possessed by the associated entity, and zero or more rules that describe the tag or tags that must be possessed by a second entity for the second entity to be permitted to possess, use, modify, transfer, or perform other actions to or with the associated entity.
  • FIG. 15 An exemplary security specification is shown in Figure 15.
  • the items that comprise the exemplary security specification include an optional Associated Entity ID (15100), Associated Entity Security Level (15200), Associated Entity Tags (15300), and an optional section of action/rule combinations (15400), comprising zero or more action/rule pairs (15405/15410, 15415/15420, 15425/15430).
  • the Associated Entity ID (15100) is present in security specifications that are stored separately from the associated entity, and is optionally present in security specifications that are embedded into the associated entity.
  • the Associated Entity ID (15100) is used to identify the entity associated with a particular instance of a security specification.
  • the Associated Entity ID (15100) can comprise a device or server ID, communication path designation, user name or login ID, a node ID, catalog ID, or other entity identifier as may be determined to be useful by those having skill in the art.
  • the Associated Entity Security Level (15200) specifies a general security classification for grouping security specifications, regardless of security specification details, as described by the Associated Entity Tags (15300) or action/rule pairs (15400).
  • the Associated Entity Security Level (15200) is a numerical value with larger values indicating higher security level, and smaller values indicating lower security level.
  • the Associated Entity Security Level (15200) is one of a fixed set of security level indicators, such as "high,” “medium,” or "low,” having an assumed hierarchy with some indicators specifying higher levels of security and some other indicators specifying lower levels of security.
  • security specifications with higher levels of security are considered to be compatible with security specifications having lower levels of security when the receiving entity possesses the higher security level, but not when the receiving entity has the lower security level. These restrictions ensure that data can pass to a more secure entity, or over a more secure communication path, than required, but can not pass to a less secure entity, or over a less secure communication path, than required by the security specification of the data.
  • the security specifications of the sending entity, the receiving entity, the communication path used, and the data being transferred must all be compatible.
  • the Associated Entity Tags (15300) are used for specification of finer-grained security access permission than that provided by the Associated Entity Security Level (15200) item.
  • Associated Entity Tags (15300) comprise zero or more "tags."
  • a tag is a numerical, text, or other data object that has a particular meaning in the context of an exemplary implementation.
  • An arbitrary number and types of tags can be included in a security specification's Associated Entity Tags (15300) item. These are used to provide the associated entity with a specific set of permissions or restrictions when combined with the action/rule pairs (15400) of a second security specification as described below.
  • a security specification can comprise zero or more Action/Rule pairs (15400), Rules (15410, 15420, & 15430) in the security specification of a first entity are used to specify the Associated Entity Tags (15300) that must be included in, or that can not be included in, a security specification of a second entity for the second entity to be considered compatible with the first entity for purposes of carrying out a specified action (15405, 15415, & 15425).
  • Actions comprise a number, text, or other data object that has a particular meaning in the context of an exemplary illustrative non-limiting implementation, and are used to specify various actions that can be taken, such as possessing a particular data item, transferring a data item to another device, executing a set of nodes, updating catalogs on a device, etc.
  • the specific set of actions that can be specified is implementation dependent.
  • Rules (15410, 15420, & 15430) specify the tag or tags that must be, or must not be, in the second entity's Associated Entity Tags (15300) item for the second entity to be compatible with the first entity.
  • Rules are Boolean expressions that permit arbitrary specification of tag combinations or lack of tags, in ways that are well known to those of skill in the art. For example, a rule can specify that a second entity must possess the "MAINTENANCE” and “MANAGER” tags, but can not possess the "DIRECTOR” tag in order to be compatible for purposes of carrying out the associated action, which might be transfer of a machine's maintenance required alarm, Such a rule would prevent sending such an alarm to the director of maintenance, but would permit sending it to another manager in the maintenance division, who could then, for example, create a task and assign it to a worker to service the machine.
  • Action/Rule pairs (15400) and the Associated Entity Tags (15300) that drive the rule evaluations are only checked if the Associated Entity Security Levels are compatible. They can not be used to override restrictions on compatibility specified by the security level assigned. They can be used to provide finer-grained management of compatibility within compatible security level relationships, for instance to allow a manager to receive data about the employees they supervise from the human resources system, but not to permit the manager to receive data about employees they do not supervise, or to allow a worker to cancel a task assigned to the worker without permitting the worker to cancei other tasks.
  • security level assignments, tags and action/rule pairs for various entities any arbitrary pattern of data movement and use, data movement methods and data movement or use restrictions can be established.
  • exemplary devices can support Push mode, Cooperative Push mode, Out of Band Transmission, and Communication Path Switching.
  • Peer-to-Peer (P2P) communications involve direct connection between two or more devices without a requirement for a server or other device to enable communications.
  • P2P is used to permit transmission of messages and message segments between devices without the need for any connection to a server, such as to permit a first device to send data items representing a unit of work to a second device. This is advantageous in many ways, such as for permitting a supervisor to reassign a task to a subordinate, or for a worker to pass a task to a co- worker.
  • the devices When communication is initiated between devices using P2P, the devices must have a method of recognizing and iocating each other. In some exemplary implementations, this is accomplished though information being distributed to devices in the form of catalogs. Catalogs containing Bluetooth known device IDs, ad-hoc Wi-Fi network names and addresses, as well as device authentication materials, and other information useful for locating, connecting with, and authenticating between devices using P2P communication methods are distributed and updated by servers and stored by devices until needed.
  • a first device when a first device recognizes communication paths, such as ad-hoc Wi- Fi networks or Bluetooth devices, the first device's user can be prompted to authorize use of said communication paths, to specify characteristics to assign to such paths (e.g._weighting factors used to dynamically select communication paths), or to provide authentication materials required to use said communication paths (e.g. username, password, or credit card number).
  • Security specifications for communication paths are supplied by servers in most cases. When there is an appropriately privileged security specification associated with a user, the user also can supply security specification information for communication paths or other entities.
  • Push mode is used both to send data items and to send commands so as to impiement Cooperative Push mode communication.
  • the exemplary procedure described involves sending data items to an exemplary device which is capable of receiving SMS messages and which is capable of establishing a Wi-Fi link when located in a Wi-Fi hotspot.
  • the exemplary device is either not located in a Wi-Fi hotspot at the time the data items must be sent, its IP address is not known to the sender, or there is a firewall, router, or other component that blocks connections to the device.
  • SMS to convey the Communication Request command
  • any communication path capable of push mode to the device could be substituted.
  • MMS messages existing P2P or Wi-Fi connections, TCP/IP over any available interface (e.g. TCP packets though a socket connection, UDP packets, multicast or broadcast packets using IPv6 or IPv4 methods, or other protocols over Wi-Fi, Bluetooth links to wired Ethernet interfaces, dialup modems using SLIP, PPP or other protocols).
  • a first device (whether server, mobile device, or other device) must have information telling it how to contact a second device.
  • a first device is configured with required data about a second device's address, communication paths supported, etc., whether by a user of the device or by a server device periodically updating it with current address and other necessary data items, using catalogs or other means.
  • a first device obtains required information about a second device from a known service, such as Lightweight Directory Access Protoco! (LDAP) or Domain Name System (DNS), or by broadcasting a request and receiving a response from the second device or a disparate device, such as with Address Resolution Protocol (ARP).
  • LDAP Lightweight Directory Access Protoco!
  • DNS Domain Name System
  • address and other required information is provided to servers manually, through operators entering data items, while in other exemplary implementations devices automatically update servers with current information about their addresses and other required information using methods such as Dynamic DNS, catalog updates, or other methods as determined to be effective by those having skill in the art.
  • Devices can use a plurality of information sources to determine address or other necessary information about disparate devices, such as using DNS to determine TCP/IP addresses and a stored catalog for SMS addressing information.
  • OOB Out Of Band
  • data items are exchanged through a communication path other than a preferred path, or at a time other than a scheduled polling period or routine contact.
  • OOB is used to provide high priority transmissions, such as emergency alerts, software or data item updates, coordination of tasks between users, or other time critical matters that should not wait for a device to connect at its next polling interval, or when the user is next at a point of presence where service for the preferred communication path is available.
  • OOB also is used to implement Push Mode transfers, where a server initiates a connection to a client. Not all communication paths permit use of Push Mode due to their inherent design limitations, and some of these communication paths are likely to be preferred or primary use paths, due to their large bandwidths (e.g. Wi-Fi, wired Ethernet, etc.). in this scenario, a command that requests an immediate Pull Mode connection is sent OOB over a communication path that permits Push Mode (e.g. SMS or MMS).
  • Push Mode e.g. SMS or MMS
  • the receiving device then initiates a Puil Mode session with the server to transfer the required data items over a preferred connection selected as described previously, in some exemplary implementations the application software can request the user to make such a connection possible by moving to a hotspot, connecting to a wired Ethernet port, etc. as soon as is practical.
  • OOB as enabled by an exemplary illustrative non- limiting implementation is useful in situations where a device has a limited capacity for connecting over preferred communication paths, is currently connected in a way that exhausts that capacity, but high priority messages must be sent to it from a device that is not currently connected to it.
  • a device For example, if a device is limited to a single Bluetooth connection at a time and is currently connected to a server and exchanging messages, a second server with a high priority message for the device would not be able to connect to the device over Bluetooth to deliver it. In this scenario the server could send the message OOB using SMS or MMS, and thus bypass the Bluetooth connection iimitation.
  • Some communication paths are not capable of Push Mode transmission due to their design and the way they are commonly implemented.
  • the Internet uses the TCP/IP protocol, which requires that a connecting device specify the network address of the device to be connected to.
  • Server devices typically have fixed addresses that are known, or learned through systems such as the Domain name System (DNS), by other devices, which enables the other devices to initiate a connection to the server.
  • DNS Domain name System
  • the devices using such communication paths must be configured with any addressing, device ID, encryption keys, authentication information, or other data required to locate, connect with, and establish trusted communication between the devices over the communication path.
  • configuration information is included in the devices by their manufacturer, added by the users of the devices, sent from server devices (e.g. as configuration messages or catalog data items), be a normal aspect of the particular communication technology used, or any combination of these. Updates to configuration information are made by the users of the devices, sent from server devices, be a normal aspect of the particular communication technology used, or a combination of these.
  • Bluetooth P2P communication the establishment of a Bluetooth piconet involves the exchange of information that enables devices participating in the piconet to calculate the pattern of radio frequency changes that is used by the members of the piconet, and so maintains contact with them.
  • information exchange is a normal part of the Bluetooth technology protocols.
  • devices joining an "ad hoc" Wi-Fi network may need network name data ⁇ e.g. "SSID") and access information (e.g. "WAP keys”) to enable identification of other members of the network and permit communication with them.
  • SSID network name data
  • WAP keys access information
  • Such information must be provided to devices by means other than the "ad hoc" Wi-Fi network, such as by a user entering the information into the device configuration or a server sending the configuration information to the device.
  • configuration information can consist of account login and password values, or other forms of identification and authentication, or, in the case of SMS, the phone number of the disparate device that is to be contacted.
  • configuration information can consist of account login and password values, or other forms of identification and authentication, or, in the case of SMS, the phone number of the disparate device that is to be contacted.
  • One exemplary, non-limiting example of a method of collecting and distributing network access information such as Wi-Fi SSIDs and related authentication materials is for this information to be stored in a catalog and the catalog distributed to all devices that are granted access using the specific network accesses.
  • a mobiie device may receive a catalog of connection information supporting wireless "hot spots," including sets of SSIDs and related access keys (e.g.
  • WAP keys, account/password pair) that are usable by a Session Manager to establish a connection using a specific communications technology.
  • Differing communications technologies can have different catalogs (e.g. a catalog for each technology) or a single catalog can contain information for a plurality of communication technologies.
  • different users can have differing catalog(s) provided to their device, depending upon the access rights and connectivity to be granted to the specific user/device.
  • these communication technology catalogs are maintained on a common server (TPC) device, and are distributed to mobile devices on an as-needed basis. Pre-use distribution and caching of these catalogs permits their contents to be used when the mobiie device is in the field, and enables the device's seamless transition between supported communication paths.
  • TPC common server
  • a device can query a common server device for a particular communication technology's catalog when this technology is identified as being active in a particular location.
  • the response to the query is for the server device to send one or more catalogs, or one or more data items comprising portions of one or more catalogs to the requesting device.
  • the catalog distribution mechanism is used to distribute the known device ID's, user ID's, and authorization materials of known devices and users.
  • a mobile device when identifying a second mobile device on a Peer-to- Peer network or other network that does not rely on a connection to a server device, can use the device ID and authorization materials to establish a communication path between the two devices.
  • Sue's device can receive a catalog comprising a catalog element identifying Fred, Fred's device ID (e.g. 1), and the authentication materials (e.g. "secret”). Fred could receive a copy of the same (or a different) catalog that identifies Sue, Sue's device ID (e.g. 2), and the required authentication materials (e.g. "Sue's secret”).
  • Fred's device Upon recognizing a device on a network as device 2, Fred's device can look up the user (Sue), and determine if there are messages to be sent to Sue's device, if so, Fred's device can create a communication path between Fred's device and Sue's device, using the authentication materials (e.g. "Sue's secret,” and "secret”) to allow the endpoints to ensure that the other device is authentic and authorized to initiate the connection.
  • selected elements of the catalog of users, devices, and authentication materials are forwarded to specific devices. By limiting the catalog elements distributed to devices, the distributed catalog elements are used as a form of authorization for a first device to connect to a second device.
  • Security specifications can be used to further limit the types of data, specific data items, or communication paths that may be used to transmit data between devices independently of the authentication method just described. For example, even after Fred and Sue's device have exchanged secrets and recognized each other, Sue's device can still be prohibited from sending certain data, such as profit margin data or payroll information, that bears a high security level or that is restricted to particular recipients, to Fred's device due to lack of matching security specification requirements between the devices, or due to the level of security associated with the communication path between them.
  • each communication path also is configured with additional information or settings to specify characteristics (such as speed, cost, or reliability) of and functions (such as push mode or large message size) supported by each communication path, preference settings used to determine which communication path to use under various conditions of availability, data item priority, or other factors, or other communication path configuration as deemed appropriate by those having skill in the art.
  • characteristics such as speed, cost, or reliability
  • functions such as push mode or large message size
  • preference settings used to determine which communication path to use under various conditions of availability, data item priority, or other factors, or other communication path configuration as deemed appropriate by those having skill in the art.
  • the server (TPC) device updates a catalog of device communication addresses upon receipt of a message from a mobile device.
  • Loss of connectivity can happen at multiple points along the path.
  • the device can experience a failure in its communications hardware, there can be a loss of connection at the signal level (such as when leaving a Wi-Fi hotspot), some part of the communications infrastructure can be unavailable (e.g. a disruption of service at the cell provider, a connectivity outage in the Internet, an overloaded SMS server, etc.) or the server the device is communicating with could be unavailable (e.g. power failure, system maintenance, software errors, etc.).
  • Loss of connectivity on one communication path does not necessarily mean that all communication paths for a device are unavailable.
  • the device can have the option of switching to a communication path that retains availability.
  • Devices also can switch communication paths without loss of connectivity so as to optimize use of available communication paths and improve such aspects as speed, reliability or responsiveness, or decrease such aspects as cost, or delay.
  • Devices can re-evaluate their use of available communication paths only when a failure occurs, periodically on a configurable or hard-coded basis, when a new communication path becomes available, any combination of these, or other options as determined to be proper by those having skill in the art.
  • Some exemplary devices support auto-selection of communication paths, where communication path switching is done without action on the part of the user and, in some implementations, no action on the part of the application software.
  • Such exemplary devices are designed such that the device operating system selects the communication path and the application software always uses the currently selected communication path, and changes communication paths as the device directs. Such switching is transparent to the user or the application software in some exemplary implementations, and is detectable to the user or the application software in other implementations.
  • the communication path used by default is determined by the operating system of the device, but the application software can override this and use alternative communication paths through use of mechanisms supplied as part of the operating system by its manufacturer.
  • switching is done as a failover response to loss of connectivity on an existing communication path, or switching is done at any time that an alternate communication path is determined to be preferable to the communication path currently in use (path optimization).
  • path optimization path optimization
  • an Auto- Switching device can require an application to force a switch to a different communication path.
  • the device For example, if the device is using a Wi-Fi communication path and a change is made to the Wi-Fi configuration of the hotspot firewall which results in blocking of access to the address of the server the device is connected to, the device still detects the Wi-Fi signal and is able to send and receive TCP/IP packets, and so does not auto-switch to an alternate communication path, despite the fact that the device cannot use the Wi-Fi connection to reach its server.
  • the device's application software can re-establish a communication path to its server by forcing a switch to an alternate communication path, such as GPRS or EDGE.
  • the method for switching communication paths as a result of communication path failure involves several stages.
  • the loss of connectivity is detected.
  • an alternate communication path is selected.
  • connectivity over the new communication path is established, in more specific embodiments, when path optimization is in use, the device performs the second step in this process, selecting a communication path or paths, and if the path(s) selected are different from the currently preferred path(s), the device initiates communication path switching so as to make the selected path(s) the currently preferred path(s).
  • UDP packets over TCP/IP, or SMS there is no acknowledgement as part of the transport protocol and if the problem is not local to the device, it is not detectable unless the application level protocols include some form of feedback to detect communication problems. For example, if UDP or SMS is used to send a message from a server to a client, the client can send a UDP or SMS message back to the server when the message is received, acknowledging that the message arrived. If the message is lost in transit, there is no acknowledgement packet and the server can re-send the message after a suitable time has elapsed as determined by a suitable mechanism, such as a clock chip, loop counter, or programmable interrupt facility.
  • a suitable mechanism such as a clock chip, loop counter, or programmable interrupt facility.
  • the server again re-sends the message and the client can receive an additional copy and acknowledge receipt again. This continues until the message has been received and the server has gotten acknowledgement of the message being received, or until there have been enough unsuccessful attempts for the connection to be considered unavailable. Duplicate messages and nodes are detected and ignored by means described below. When a communication path is determined to be unavailable, a failover path switch is performed, if there is an appropriate alternative communication path available.
  • the device can retain data items that are waiting to be sent until connectivity is restored, or it can switch to another communication path that has, or might have, connectivity.
  • the device can do both, retaining some data items for iater transmission, and sending other data items over communication paths that have connectivity.
  • the decision as to whether to retain data items for a later transmission attempt or to send them over alternate communication paths is made based on factors such as the priority of the data items, cost of the alternate communication paths, capabilities of the alternate communication paths, or on other factors as determined to be proper by those having skiil in the art.
  • Devices also, in some exemplary implementations, switch communication paths proactively, without loss of availability of the current communication path, such as when a more preferred communication path becomes available, or when characteristics of data items to be transmitted, such as priority, permit use of a communication path that would otherwise not be selected for use. For example, if a device is connected by a communication path using GPRS, because that was the most preferred available communication path at the time the connection was established, and the user moves the device into an area where a more preferred communication path is available, such as a Wi- Fi hotspot, the device can establish a new connection over the more preferred communication path and terminate the less preferred path, even though it remains available. This is done to reduce costs, improve speed or reliability, or for any other reason.
  • the priority of those data items are raised.
  • the new priority value of the waiting data items can result in an alternate communication path being selected, which would otherwise not have been selected at that time, and a switch to that communication path made to allow the waiting data items to be transmitted.
  • the device can use the newly acceptable communication path without switching from a different communication path.
  • Similar factors are involved when determining which alternate communication path to switch to, whether in fail-over mode or for path optimization.
  • a device can have a priority scheme buiit into it that is used to choose an alternate communication path, or it can do so dynamically using rules to balance various factors (such as, without limitation, cost, speed, reliability, user preference, features supported (such as Push Mode), or the number and type of data items to be transferred), or it can ask a user to make the choice.
  • the decision is made by the device operating system in some exemplary implementations, or is left to the application software in other exemplary implementations. In implementations where the device operating system makes the communication path decision, it still is possible to force use of a particular communication path by altering device configuration settings so as to disable those that are more preferred by the operating system.
  • the communication path chosen is controlled so as to maximize or minimize the impact of any characteristic or feature, to force selection of a given communication path if it is available, or to prevent use of a given communication path or, alternatively, to prevent use unless there are no alternatives.
  • a separate initial calculation is made to compare the communication path capability or characteristic requirements of impending transmissions with the capabilities of the available communication paths, and those communication paths that do not support the required capabilities, such as Push Mode, are removed from consideration before the selection priority scores are calculated.
  • One exemplary process for selecting one or more communication path(s) for use is depicted by the flowchart of Figure 5.
  • the process begins by building a list of all currently available communication paths (5000). In some exemplary devices this consists of all of the communication paths supported by the device, such as SMS, EDGE, and Wi-Fi. In other exemplary devices it is possible to determine whether or not an interface is detecting a signal, and eliminate those communication paths that use an interface that is not currently receiving a signal (e.g. if the telephony data interface has no signal, neither SMS nor EDGE communication paths are available), in some exemplary devices it is possible to test a communication path for connectivity, such as by sending an iCMP "echo" packet (a "ping") to a known TCP/IP address over Wi-Fi and waiting for a response.
  • a communication path for connectivity such as by sending an iCMP "echo" packet (a "ping") to a known TCP/IP address over Wi-Fi and waiting for a response.
  • connectivity can be present in one part of a communication path and not present in other parts, thus preventing use of the communication path. For example, detection of a Wi-Fi signal and a response to a "ping" sent to a service provider do not mean that a server or other device is reachable through Wi-Fi.
  • the device includes substantially all paths that cannot be positively determined to be unavailable. For this purpose, a device can maintain a list of communication paths that have been recently determined by the device to be unavailable through lack of receipt confirmations for previously transmitted data items.
  • the process ends with a "no paths available" result (5020). In this case, the device cannot communicate at the current time and location. Some exemplary devices can alert the device user to this situation so that the user can move the device to a location where additional communication paths are available. Exemplary devices also can repeat the selection process periodically until an available communication path appears. [00106] If the list of available communication paths contains at least one communication path, the next step in the selection process is to eliminate all communication paths from the list that do not support all required capabilities (5030). For example, if a push mode transmission is required, any communication path that does not support push mode is removed from the list of available communication paths.
  • the list contains at least one communication path (5040). if not, the process ends with a "no paths available" result (5020). If the elimination of paths lacking required capabilities resulted in the list containing exactly the number of communication paths required (this is typically one, but some exemplary devices can use more than one communication path at a time and thus can require selection of a plurality of communication paths), the list of paths is returned and the process is complete,
  • the selection priority values are then increased for each characteristic associated with a path that is desirable, by an adjustment amount determined by configuration settings for that characteristic (5080). For example, if low cost is considered desirable, and has an adjustment value of six, then the selection priority value is increased by six for all communication paths in the list which have a characteristic of low cost. Such increases in selection priority are also cumulative in that if low cost and high bandwidths are both considered desirable, with adjustment values of six and four respectively, a communication path that has low cost and high bandwidth (e.g. Wi-Fi) would have its selection priority value increased by ten.
  • the communication path(s) with the highest selection priority values are selected (5090) and returned (5060) and the process is complete.
  • the choice of characteristics to include in the configuration, the assignment of characteristics to each communication method supported by a given device, and the priority increase and decrease values chosen for each characteristic can be used to adjust the preference for communication paths under different circumstances to any extent required.
  • An example of a typical scenario is a device capable of three communication methods: GPRS, Wi-Fi, and Bluetooth, located at a public Wi-Fi hotspot in a major city, where both GPRS (both TCP/IP and SMS protocols) and Wi-Fi are available, but Bluetooth is not.
  • the user has configured the device settings to prefer high bandwidth (- 10, +3), low transmission delay (-1 , +5) and low cost (-1 , +1 ), meaning that if a communication path is low bandwidth, decrease priority by 10, but if it has high bandwidth, increase priority by 3, and similar adjustments for transmission delay and cost, GPRS-TCP/IP is set as having low bandwidth, low transmission delay, and high cost.
  • GPRS- SMS is set as having low bandwidth, high transmission delay, and high cost.
  • Wi-Fi is set as having high bandwidth, low transmission delay, and low cost.
  • Bluetooth's settings are not relevant as it is not available. Both available communication paths have identical security specification characteristics, so this is not a relevant factor in deciding between them.
  • the device is not currently in need of push mode, so the lack of support for this capability is irrelevant as well.
  • the calculation results in the following scores for each method: GPRS-TCP/IP (-6), GPRS-SMS (-12), and Wi-Fi (+9).
  • the Wi-Fi communication path is selected for use.
  • the preference score total for a communication path must exceed a specified figure for the communication path to be used, and the priority of the data items to be sent, or the time elapsed since the last connection is added to the total score as another factor. In this manner, a communication path that is too costly to use under normal circumstances is selected for use if there is a great enough need (e.g.
  • data item priority can vary with the type of data item. For example, a user's response to a request might be given a very high priority, as might an emergency alert notification, while a request to pre-fetch image data items or to request a check to see if a given set of nodes have available updates would be given a lower priority.
  • the priority values are associated with the node type, while in another exemplary 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-descriptive data of the nodes that comprise it, or dealt with in other ways as determined to be proper by those having ski ⁇ in the art.
  • selection of the most preferred communication path, or paths is not done as described above, but is performed using a more complex method, for example, one involving artificial intelligence techniques, such as goal-seeking rule- based systems, inference methods, neural networks, and pattern recognition using historical data concerning communication path availability, user selections, or other data. Combinations of these or other methods can also be used.
  • An exemplary method of this type involves use of a "preference function”.
  • a "preference function” is implemented that computes a "preference value" for each pending data item if sent over each available communication path.
  • the preference function uses parameters describing available communication path capabilities, the size of the data item to be sent, the priority of the data item, recent history of transmission time delays for available communication paths, communication path costs (in some scenarios this can be adjusted for location, time of day, data item size, total data sent in a given time period, or other factors), or other parameters as will be well understood by those having skill in the art.
  • any communication path with a computed preference value that crosses a specified threshold is selected for sending the associated data item.
  • Preference value is recomputed as the parameters used to compute it change.
  • This method allows an arbitrary number of different factors to be combined to reach a decision about which available communication path, or paths, are preferred for sending a particular data item at a specific time, so as to optimize selected factors, such as cost, speed, delivery delay, or others.
  • This method permits use of more complex preference functions than simple weighting factors as described above. By comparing the computed preference value to other thresholds, this method can also be used for resolving other decisions, such as when to send data items Out Of Band, not just how to send them.
  • the mechanism used to cause a switch in communication path by an application is determined by the design of the exemplary device. Various methods are currently in use by different device manufacturers and additional methods are both possible and likely in future devices. !n some exemplary devices, such as the Blackberry, an application specifies the communication path to be used for a given connection by appending parameters to the address (URL) of the device being connected to and passes this to a connection object's "open" method. To switch communication paths on such a device, the application closes the existing connection and opens a new connection using different parameters that specify the alternate communication path.
  • URL address
  • the application closes the existing connection and opens a new connection using different parameters that specify the alternate communication path.
  • connection methods are used for each communications method supported by a device, and application software can use the methods required by the existing communication path to close that connection, and use the methods required by the new communication path to open a new connection on it.
  • the selection of a communication path is under control of the device user through physical controls or operating system utility software, and application software must interact with the user to request a change to a different communication path.
  • the ability to send messages and message segments over any appropriate communication path, without loss of functionality, and to switch communication paths in the middle of sending a segmented message without disrupting the process allows the devices to maximize throughput and minimize response delay by selecting the fastest available communication path at any given time, to improve reliability by failing over to an alternate communication path when the one in use loses connectivity, to minimize cost by selecting an appropriate communication path for the type of data item being sent, and to improve functionality by permitting communication paths to be chosen and used based on their capabilities, such as when Push Mode is required and not all available communication paths support this method of operation,
  • a device can send or receive SMS while also exchanging data items over Wi-Fi, or transferring data items with a Bluetooth link while also connected through a wired Ethernet port.
  • SMS short message service
  • a Bluetooth link while also connected through a wired Ethernet port.
  • the Node Store on the receiving system stores all data items that arrive intact, while eliminating any duplicates and so merges them, regardless of the communication path they arrived through. Because there is no difference in node structure or content once received, it makes no difference which communication path a given data item was sent through, and communication paths can lose connectivity or gain connectivity over time and messages continue to be sent and received over any other communication path that retains connectivity and meets requirements for characteristics, priority requirements or other factors as described herein.
  • the sending device can use a number of different procedures for selecting which data items to send through each communication path.
  • Examples of possible procedures include sending the next data item in a queue over the first communication path which becomes free to accept data items, matching data item characteristics with communication path characteristics (e.g. sending large data items over high bandwidth communication paths and small data items over low bandwidth communication paths, or sending data items that must be sent in Push Mode over communication paths that support Push Mode and not over communication paths that do not support Push Mode), sending data items in priority order with highest priority data items being sent before lower priority data items, sending data items that are being sent in response to Pull Mode requests over one communication path and reserving another communication path for Push Mode exchanges, or any combination of these procedures or others as are determined to be appropriate by those skilled in the art.
  • communication path characteristics e.g. sending large data items over high bandwidth communication paths and small data items over low bandwidth communication paths, or sending data items that must be sent in Push Mode over communication paths that support Push Mode and not over communication paths that do not support Push Mode
  • sending data items in priority order with highest priority data items being sent before lower priority data items e.g. sending data items that are being sent in response to Pull
  • Figure 6 illustrates exemplary, non-limiting implementations of the communications portions of devices compatible with a communication system architecture such as the exemplary architecture presented in Figure 1 , in which a first device (6000) communicates with one or more other devices (6610, 6620), through a particular instance of a communication path (6710, 6720). Each such device includes one or more communication interfaces (6300a, 6300b), which are capable of accessing at least one of a set of available communication technologies.
  • Exemplary devices further comprise a Dispatch Manager (6220), which in turn further comprises at least one Protocol Manager(s) (6210a, 6210b,), at least one Session Manager ⁇ 6200), and node store and cache (6500),
  • the Protocol Managers are provided on the device to alter data item format and content as required by the implementation of the communication technologies used by the communications interfaces (6300a, 6300b).
  • Device 6000 processes application tasks specified using computer program code devices (herein called "nodes") that are configured to be transmitted from a first device for receipt and processing on a second device.
  • a Session Manager component manages the activities of the Protocol Managers, and makes decisions as to whether to accept connections from other devices, how to route data items, and provides related functionality to the device.
  • a mechanism is supplied as part of the Session Manager that selects one or more communication paths for use from among those that are available. This is referred to herein as the "selection algorithm.”
  • Each communication path has characteristics that are used by the selection algorithm to establish a preference for the use of one or more communication paths and avoids the use of one or more other particular communication path(s).
  • the selection algorithm can also use characteristics of the messages to be sent, such as priority, size, or the time the messages have been waiting for transmission, as factors in selecting a preferred communication path or paths.
  • a communication path having a large bandwidth such as Wi-Fi
  • a bandwidth-limited communication path such as SMS or MMS.
  • one communication path allows unlimited use for a fixed cost while another charges a fee for each transmission, it is desirable to use the fixed cost path preferentially, and use the fee per transmission path only when the fixed cost path is unavailable, or to avoid use of the fee per transmission path entirely, or iimit its use to high priority messages, in another example, where push mode transmission is required, a communication path that supports this mode must be used, and communication paths that cannot support this mode due to their methods of implementation cannot be used.
  • a request such as a message comprising a communication request command with a cooperative push mode sub-function
  • This request message prompts the recipient device to initiate a pull mode connection with the requesting device using an appropriate communication path, over which the requesting device can transmit the message.
  • the device can store the message(s) until an appropriate communication path becomes available, if one ore more of the messages have a sufficiently high priority, and there is an appropriate communication path available, but not currently in use, the device can, in some exemplary implementations, be configured to switch communication paths and send the waiting message or messages.
  • the user is requested, by appropriate means, such as an SMS message or a voice message, to move the device to a location where an appropriate communication path is supported at the earliest convenience so that transmission can be accomplished,
  • a high priority transmission can result in use of a non-preferred communication path if it is the only one available, or if it has characteristics that are advantageous for the particular transmission (such as support for Push Mode) while other available communication paths do not have the required characteristics.
  • a high priority transmission can be done OOB while lower priority transmissions use the preferred communication path or are delayed until the preferred communication path becomes available.
  • Transmission priority values are established by configuration settings, by input from users when requesting a transmission, by the design of the transmission procedures, or by other means as determined to be proper by those with skill in the art.
  • Transmission priority values are associated with a transmission by the procedures implementing the transmission request through means such as function parameters, referenced data structures, or other commonly used methods. Transmission priority values are conveyed by use of priority values incorporated into the messages being transmitted, by associating priority values with such messages through indirect means (e.g. by putting high priority transmissions into high priority transmission queues and lower priority transmissions into lower priority transmission queues), or by any other appropriate mechanism.
  • Wi-Fi communication paths There are other characteristics that can make use of a given communication path for particular purposes impossible. For example, with Wi-Fi communication paths devices connected through the Wi-Fi service are typically given a different network address each time they connect to the service, which makes sending of data items to a Wi-Fi connected device impossible until the Wi-Fi connected device establishes a connection (Pull Mode). Other devices have no way of reaching the Wi-Fi connected device at other times. However, with some other communication paths, such as SMS or MMS, devices have fixed addresses and are reachable by any other device that has access to the address (push mode). Some communication paths are selected for use when the operation to be carried out requires characteristics supported by that communication path, even though other communication paths are preferred for the bulk of data item transmission.
  • devices can select one or more to use, and can switch between them either when the preferred path or paths become unavailable (path loss switching), or at other times so as to optimize various aspects of the communication, such as speed, responsiveness, cost, reliability, or others (optimization switching).
  • path loss switching path loss switching
  • optimization switching Detailed descriptions of some exemplary methods for detecting path loss, determining preferred path, etc. are provided below.
  • a device has both Wi-Fi and SMS capability.
  • Wi-Fi connectivity has a large bandwidth and unlimited data transfer for a fixed cost, but operates only in localized areas called “hotspots," and only in "Pull Mode,” where the mobile client device must initiate the connection.
  • SMS connectivity has a small bandwidth, and has a fee associated with each transmission, but has much wider service availability and can operate in "Push Mode,” where the server or the client can initiate communications.
  • the server device can use SMS to send a message containing a command to the client in Push Mode that results in the ciient device initiating an OOB connection to the server over Wi-Fi, which then is used to transfer data items over the faster and less costly Wi-Fi connection.
  • the message sent over the SMS communication path can result in the user being requested to move the device to a location where Wi-Fi service is available if the device was not already located in a Wi-Fi Hot Spot.
  • Push Mode also is used in some exemplary illustrative implementations to implement announcement and acceptance (A&A).
  • A&A is a process where there is a task to be performed, and a plurality of users that may be available to perform the task, but exactly which user or users are available, willing, and able is unknown.
  • the process involves sending announcement messages to one or more devices associated with one or more users selected as likely candidates for performing the task due to location, job function, by name, or other means, collecting user responses, returning them to the requesting server, and selecting one or more of those responding affirmatively to perform the task.
  • Performance of the task can involve additional A&A interactions, downloading data items associated with one or more tasks, using pre-cached data items already present on a device, or other processes.
  • normal functioning involves devices polling server devices at intervals, or whenever there is a need to request updated data items or to send response nodes, or when the device detects the availability of certain kinds of communication paths. For example, once every ten minutes, whenever the user enters data items for transmission, or whenever there's a Wi-Fi communication path available. This is adequate in most situations, but there are times when a server device has data items that need to be sent to a device at a time when the device is not connected to the server, or when a second, non-server, device has data items or other data to transfer to a device (P2P).
  • P2P device
  • the nodes that need to be updated are sent in push mode or cooperative push mode. This transmission can be made over a communication path other than the one preferentially used for such transfers (e.g. over SMS or MMS rather than Wi-Fi or Bluetooth) despite increased costs or the time required to transmit the data items.
  • a device is limited to a single connection at a time over a given type of communication path, and use of OOB transmission using a different communication path is used to implement additional connections or to increase overall bandwidth. Because some communication paths can at times include unacceptable delays in transmission or be unreliable or intermittent, it is sometimes desirable to send a given data item by several communication paths at once. Such redundancy increases the chances of timely reception of data items at the receiver, but also can result in duplicate transmission. Because nodes have unique node IDs and version information, the receiver can recognize such duplications and discard them, or recognize an out of date node that was delayed in transmission and discard it.
  • devices to exchange messages or message segments they must have information as to which communication paths are supported, what recipient specification information to provide, and in some exemplary implementations, additional information such as authentication credentials, encryption keys, polling schedules, or other information required to gain access to the communication path, route data items to the intended recipient, and send them in the required form.
  • Devices are initially configured by their manufacturers, users, or others, with sufficient information to permit them to connect with at least one server and exchange data items and commands with that server.
  • devices are configured with additional initial configuration information.
  • Devices can acquire additional communications configuration information that specifies information required to exchange data items with other devices from the initially configured server(s), and thereafter from the other devices.
  • Additional information acquired can include device IDs, device user names, communication paths supported by other devices, data routing information such as TCP/IP addresses, cell phone numbers, or Bluetooth device information, authentication information such as Wi-Fi hotspot login account and password information, server addresses for services such as SMS, DNS 1 or e-maii, scheduled polling interval or time data, communication path preference configuration data, data priority configuration data used to adjust communication path use based on priority of data waiting for transmission, or other information reiated to communication between devices.
  • data routing information such as TCP/IP addresses, cell phone numbers, or Bluetooth device information
  • authentication information such as Wi-Fi hotspot login account and password information
  • server addresses for services such as SMS, DNS 1 or e-maii, scheduled polling interval or time data
  • communication path preference configuration data such as SMS, DNS 1 or e-maii, scheduled polling interval or time data
  • data priority configuration data used to adjust communication path use based on priority of data waiting for transmission, or other information reiated to communication between devices.
  • Protocol Managers are used to make communication path-specific modifications to data items to be transmitted and to reverse these modifications upon reception. Modifications are necessary for some communication paths to cope with limitations on data representations, message sizes, or other characteristics of transmitted data items.
  • Figure 7 is a flowchart depicting the processing done by a Protocol Manager for data items being transmitted by a Dispatch Manager.
  • the Dispatch Manager passes the Protocol Manager a data block containing data to be transmitted (7000).
  • the Protocol Manager checks the data bytes for compatibility with the communication path supported by the Protocol Manager (0710).
  • Methods of encoding data are well known by those having skill in the art, and can include techniques such as "escaping" problematic bytes, using tag bytes to identify problematic byte locations, and substituting bytes which are compatible and which identify the problematic byte values.
  • the resulting data block is too large to be sent as a single transmission over the communication path associated with the Protocol Manager (7040), the data block is divided into segments which are no larger than the Maximum Transmission Unit size for the communication path, even after adding segment header data that allows segments to be re-assembied into the original data block by the receiving Protoco! Manager (7030).
  • FIG. 8 is a flowchart depicting the processing done by a Protocol Manager being used to process data items by a receiving Session Manager.
  • the Protocol Manager is given a message or message segment as received through the Communications Interface (8000). If it is given a segment of a larger message (8010), the Protocol Manager adds the segment to a message buffer, associating it with any previously received segments of the same message (8020).
  • the Protocol Manager removes any transmission modifications that were made by the sending Protocol Manager, such as encoding of problematic data bytes, compression, encryption, or others, and recovers the original data block (8040). This data block is passed to the Dispatch Manager for further non-communication path-dependent processing, and the process terminates.
  • the Node Store (6500) supports the storage and access of data items sent to the device, data items waiting to be sent from the device, and commands waiting to be sent from the device.
  • Data items are stored in a format appropriate for the device.
  • Some data items comprise nodes. Nodes can represent user data elements, user interface instructions (visual and interactive behavior), and executabie business logic.
  • the Node Store honors node attributes as related to storage, and encrypts, compresses, or applies other protections.
  • data items are stored as ASCII strings in a flat file similar to the form in which they are transferred over the communications network (but without segmentation, special character handling, compression, or encryption filtering applied).
  • the flat file is sequentially searched in order to locate or replace a specific node or specific field in a node.
  • nodes are stored in a database indexed by the node identifier.
  • a cache of data items, whether nodes or other types of data items, is maintained in local memory to improve the performance of operations supported by this module.
  • the Node Storage Module provides an interface to store, update, and access data items from the Dispatch and Display Modules.
  • the operations supported by this interface include replacing stored nodes with new nodes; adding or replacing a set of nodes; deleting a node, obtaining a specific node; finding the parent, next, or child node of a given node; obtaining one or more fields in a given node; and modifying one or more fields of a given node.
  • Node Stores can use a variety of means to store, maintain, retrieve, delete and manage nodes.
  • Data items in Node Stores are unique within that Node Store and any duplicate copies of data items are not accepted for storage.
  • Data item uniqueness is determined in some exemplary systems through such means such as comparing Node ID and Node Version information of nodes that comprise each data item, in such exemplary systems, nodes with identical Node IDs, but higher Node Version values are considered "updated nodes" and replace nodes with matching Node IDs but lower Node Version values.
  • Other means of comparing node uniqueness can be implemented, as will be apparent to those with skill in the art.
  • Nodes are also kept in Node Stores while waiting for transmission, waiting for processing by a device, post processing by the device, or when being stored for possible future use.
  • Node Stores are implemented in many ways, such as, without limitation, "flat files,” ISAM files, relational or other databases, in-memory data structures, as web browser "cookies,” or in any other manner that permits storage of nodes in a way that preserves their contents and logical structure and permits determination of which nodes are stored, and retrieval of specific nodes as needed.
  • Node Stores are implemented in different ways on different devices as long as the Node Store permits the necessary storage and retrieval operations on the nodes so stored. Node stores can be shared between devices if the devices are so configured, using synchronized database technologies.
  • Data items are held in Node Stores while waiting for transmission due to other data items being sent ahead of them (e.g. the other data items have higher priority for transmission, or were queued earlier), due to available communication paths not being appropriate for the delayed data items (e.g. the data items are large and are to be sent at a low priority, and the available communication paths are either slow and expensive), due to there being no available communication paths, due to the data items being queued between device polling intervals, or due to other factors.
  • Data items waiting for transmission are stored in a single Node Store, regardless of which communication path they are to be sent over.
  • Data items received by a device are stored in a single Node Store regardless of which communication path they arrived through.
  • Node Stores can incorporate additional data about data items they contain that is not a part of the stored nodes themselves. This data can include such information as which device a specific data item is to be sent to, the version of that data item, when a data item was entered into the Node Store, which devices a given data item was sent to and when, the number of attempts to transmit a data item that have been made without success, or any other data that those having skill in the art deem to be pertinent and appropriate for the functioning of the system or its monitoring.
  • Mobile client devices can improve responsiveness to their users by maintaining as many data items as device resources permit in their Node Stores, where the maintained data items have a likelihood of being required in the future. Indications of such likelihood include, but are not limited to, being a part of an application in current use, being part of an application that is used frequently, containing data items which are required by a plurality of applications (e.g. server addresses, company logos, address book information, parts list, price list, billing code list, etc.), or being tagged in a way that indicates that they should be retained if possible.
  • applications e.g. server addresses, company logos, address book information, parts list, price list, billing code list, etc.
  • Node Store Maintaining such data items in the device's Node Store reduces the number of data items that must be transmitted in subsequent transmissions, and increases the likelihood that the device can perform its required functions during periods when no communication path is available. By transmitting such data items to the device at times when an optimal communication path for their transmission is available, the need to transmit them later over a less optimal communication path is avoided.
  • Node Stores manage their contents through mechanisms well known to those with skill in the art, such as aging, prioritization, queuing, etc.
  • some exemplary implementations can proactively send the data items that are predicted to be useful or needed to a device.
  • a device can "pre-fetch" those data items in anticipation of their being needed at a time when an appropriate communication path is not available.
  • An example of when such a need is foreseen is the sending of image, sound, or form definition data items required by one or more nodes that define a given task.
  • Another example of foreseeing data item requirements is a server that maintains a list of tasks to be performed at particular times or at particular intervals.
  • Yet another example of foreseeing data item requirements is acquiring data items that are required by a plurality of tasks.
  • a server can look ahead at tasks scheduled to be performed and proactively send those data items required to perform the tasks to the scheduled device.
  • Device resource limitations can limit how much data is handled in this way, but typical caching algorithms well known to those with skill in the art are used to manage the available resources advantageously for the device.
  • Example algorithms include Least Recently Used (LRU), Most Recently Used (MRU), Least Frequently Used (LFU), or Adaptive Replacement Cache (ARC) methods.
  • LRU Least Recently Used
  • MRU Most Recently Used
  • LFU Least Frequently Used
  • ARC Adaptive Replacement Cache
  • the caching method chosen for an exemplary implementation can consider factors such as the expense or difficulty of re-acquiring data items (e.g.
  • nodes such as image or sound data which are sent over high bandwidth communication paths that have limited availability vs. smaii nodes such as short text strings or commands that are sent over any communication path
  • the number of other nodes that reference a given node or other factors. Additional examples of when such processing can improve efficiency, reduce costs, or otherwise be beneficial include updating frequently used data items or nodes listed by a plurality of Group Nodes or which form catalogs such as those containing server addresses, address books, or other data.
  • nodes each have a unique ID and version information defined as part of their structure.
  • the node version information should not be confused with the FDL version information of the exemplary implementation's message format.
  • the node version information specifies the version of the particular node so that the node is recognized as updating a node of the same node ID, being identical to a node of the same node ID, or being superseded by a node of the same node ID.
  • the node version information in some exemplary implementations, consists of a timestamp, an incrementing or decrementing numeric value, or other appropriate value, either alone or in combination with other information such as server identifiers, or manufacturer codes.
  • the node version information can consist of a separate field within the node, or a combination of fields within the node, such as the concatenation of a serial number combined with user or catalog ID value,
  • the Node's version information is compared to determine which node supersedes the other, and the older node is deleted and the newer node stored for use. If both the node ID and version information are the same, the nodes are identical and the duplicate node is deleted. The communication path used to transmit the node has no effect on this procedure. Only the data contained in the node is necessary to determine the uniqueness of a node, or whether it has been superseded by a new version, not the method of transferring it to the device.
  • the node ID and version information are still present and are used to determine whether the nodes are duplicates or which supersedes the other if they have identical node IDs. Switching communication paths does not interfere with moving data items between devices and detecting duplicate transmissions.
  • the elimination of duplicate nodes prior to, or as part of the step of placing them in the Node Store allows a given data item to be transmitted over a plurality of communication paths simultaneously so as to reduce the delay in getting the data item to the receiving device, without requiring any information about the current delays incurred by the various communication paths.
  • the communication path with the shortest transmission delay available at the time the data item is sent gets the data item to the receiving device, and data items sent over all other communication paths are treated as duplicates upon arrival, and ignored.
  • Node Stores also are used to hold response nodes containing user data provided in response to node processing until such time as these nodes are transmitted. Node Stores can track the time that such data items have been waiting for transmission and alert users to a lack of appropriate communication paths if this delay exceeds a specified threshold. The user then can arrange for an appropriate communication path by moving the device to a hotspot, changing configuration settings to allow an otherwise inappropriate communication path to be used, or in some other manner allowing a connection to be made and the data items to be transmitted. Alternatively, the device can take other actions upon exceeding a transmission delay threshold, such as choosing an alternative, perhaps more expensive, communication path for one or more nodes.
  • one example of the current illustrative non-limiting implementation can create a node type to be sent to a device so as to cause the device to make an inquiry of its user without disrupting the normal flow of the application in use, and a second node type to return the response of the user.
  • Either or both nodes are sent in- band via a preferred communication path, via an alternate communication path, or using an Out-of-Band communication path.
  • One use of such a capability is used to broadcast a task announcement to multiple devices simultaneously, possibly using a plurality of communication paths, and return responses indicating whether the task is acceptable or not (A&A) so as to allow scheduling of the task for one, or more, of the accepting users and not scheduling it to those refusing or not responding within a specified time period, according to logic defined by the particular implementation. Additional description of this aspect of the exemplary illustrative non-limiting implementation appears below.
  • each node specifies a Node Version value.
  • a first node which should supersede a second node in device node stores, should have the same Node ID value as the second node, and a Node Version value, which is greater than the Node Version value of the second node, in situations where both nodes are present on a device, such as when a second node has been created as an update to a first node and sent to a device that has previously received the first node, the device can determine which node to store, and which node to delete, by comparing Node ID and Node Version values and deleting the older node in favor of the one with the higher Node Version value.
  • the ability to determine which node is valid when more than one node with a given Node ID is present is required, such as in situations where nodes are sent using a plurality of communication paths simultaneously to reduce transmission delay and more than one of the copies is delivered to the device.
  • the preferred exemplary illustrative non-limiting implementation also includes a Node Transmission Priority value for each node.
  • Node Transmission Priority is used to adjust the transmission order of nodes, with nodes having higher transmission priority being sent before nodes having lower transmission priority, to assist in determining which communication path is appropriate for sending nodes or to allow use of communication paths for high transmission priority nodes that would not be selected for use if only low transmission priority nodes were waiting to be sent, to allow sending high transmission priority nodes over a plurality of communication paths simultaneously, or for other purposes as deemed appropriate by those having skill in the art.
  • some nodes are sent ahead of other nodes based on node type, such as "delete node" nodes being sent ahead of other nodes to ensure that nodes are deleted prior to nodes being inserted in node stores. Doing this reduces resource use on devices with limited storage capabilities.
  • ordering transmission by node type supersedes ordering based on Node Transmission Priority.
  • Some exemplary illustrative non-limiting implementations include a Node Cache Priority value for each node. Node Cache Priority is used as a consideration by Node Stores when determining which nodes to retain and which nodes to purge when all other factors are equal. Node Cache Priority is only one factor that is considered when making such decisions. Additional Exemplary Node Types
  • Some exemplary illustrative non-limiting implementations include a "Distribution List Node" node type, which contains a list of devices, or a reference to a catalog of devices, and a list of contact methods for each device, or references to one or more catalogs containing contact methods for each device.
  • Contact methods include not only the communication paths that are supported by each device, but any associated address, authorization, authentication, encryption, or other information required to make use of the communication path when contacting that device.
  • Distribution List Nodes can contain information about the users of the devices they list (e.g. name, shift, job category, supervisor's name, etc.), and/or about the devices themselves (e.g. device type, location, etc.).
  • Distribution List Nodes are useful for any procedure where a plurality of devices and contact methods must be specified, such as when limiting delegation for a task to a particular set of devices or synchronizing catalogs, especially when this is done using a P2P technology, such as Bluetooth or "ad hoc" Wi-Fi where a server is not available.
  • P2P technology such as Bluetooth or "ad hoc" Wi-Fi where a server is not available.
  • Some exemplary non-limiting implementations provide an "A&A" node type useful for implementing the Announcement and Acceptance capability, described below.
  • the A&A node is created by the Ul of a server or by use of an Application Programming Interface (API) designed to allow creation of A&A nodes by various software systems other than the Ui of the server.
  • API Application Programming Interface
  • An A&A node contains an FDL specification for a task, or a reference to such a specification, a "candidate list" comprising devices that are to be offered the task (in the form of a Distribution List Node), specification of the number of accepting devices required, specification of a procedure to be used to select the required number of devices from among those responding affirmatively, specification of an action to be taken if the number of devices responding affirmatively is less than the number of accepting devices required, and an optional specification of a maximum time to wait for responses.
  • Processing of the A&A node involves sending an announcement message to each device in the "candidate list,” waiting, optionally with a timeout if the wait becomes too long, while the devices present their users with the announcement and collect an affirmative or negative response and return this to the server, selection of the required number of affirmatively responding devices and generation of nodes from the FDL and queuing of the resulting data items for each selected device, or implementing the specified action if the number of affirmatively responding devices is smaller than the number required.
  • Some exemplary illustrative non-limiting implementations include a "Catalog Synchronization Node," which is used to check the contents of a catalog on a first device against the contents of a catalog on a second device and permit the resolution of differences such that both devices have catalogs containing the same data items, with that data items being the most recent available to either device.
  • Some exemplary impiementations permit association of a Distribution List Node with a Catalog Synchronization Node to specify a plurality of devices that might have copies of the catalog and require synchronization.
  • Distribution List Nodes can permit a first device to synchronize the catalogs of one or more second devices through Peer-To-Peer methods. This is useful in scenarios where the second devices do not have available communication paths to a server.
  • the exemplary illustrative non-limiting implementations may include the message types and formats described in co-pending US Patent Application No. 1 1/169,149 as well as extensions to permit implementation of additional capabilities and features as described below.
  • Configuration data representing communication paths and the address, authentication, security specifications, priority, preference, and other data associated with them, as well as other data used to control aspects of communication or other device behavior is sent using an Update Device Setting message (type 3).
  • the Update Device Setting message updates a set of preferences or configuration settings on the device.
  • Each record for this message type comprises the fields as described in US Patent Application No.11/169,149 with the following additional parameters and associated attributes: [00163] Parameter (2 -digit number) - the parameter to update.
  • the value associated with the "06" parameter comprises a character string containing an XML description of the Communication Path Selection Preferences to be set or changed. For example:
  • the value associated with the "07" parameter comprises a character string containing an XML description of the Communication Path Characteristics to be set or changed. For example:
  • the value associated with the "08" parameter comprises a character string containing a "1" if Dynamic Path Selection is to be activated, or a "0" if Dynamic Path Selection is to be deactivated.
  • the Dispatch Module determines the device settings provided and modifies the given settings with the new values.
  • the Communication Request message (type 9) is sent to request various communication-related actions be undertaken by the receiving device, such as cooperative push, "send back” (ping), "keep connection” (keep-alive), or others.
  • a Communication Request message may include the following fields of information.
  • Request Type (2-digit number) - the type of request being made.
  • Request ID (12-digit number) - the requestor-relative ID of the request in YYM MD DH H M MSS format.
  • Request Priority (3-digit number) - the priority of the request. Equivalent to Node Transmission Priority.
  • Associated Data (character string) - data associated with the particular Request Type.
  • the Request Type field can contain one of the following values:
  • the Requesting Device Address contains the address of the requesting device on the communication path used to send the request.
  • the Request ID is the time at which the request was sent.
  • the Associated Data string contains a list of addresses for various communication paths that the requestor can be reached using, and, in some exemplary implementations, additional information about each communication path, such as the address of the requestor on that communication path, the protocol to use, etc.
  • the Requesting Device Address is the address of the requesting device on the communication path the request was made using. This is also the address and communication path that are used to send the response message over, if possible.
  • the Request Priority can limit use of some communication paths in some situations, depending on communication path settings and selection preferences.
  • the action requested is that a Ping Response message be sent to the requesting device.
  • the Ping Response message has the same field values as the Ping Request message, with the exception of the Request Type, which is Ping Response ("03") and the Requesting Device Address, which is the address of the responding device.
  • KeepAiive messages are sent to keep a communication path from closing due to idleness and to notify other devices that the requesting device is still connected.
  • the Requesting Device Address is set as for the other request types, and the other fields are not used. Other than recording the receipt of the message for tracking connectivity, no action is required on the part of the recipient of a KeepAiive request message.
  • the Task Delegation (type 10) message body defines a set of materials corresponding to a single task encoded in a device independent manner, where node references have been made relative to the task in such a way that the receiving device can convert node linkages as required to process the nodes while preserving the same arrangement and ordering of the task's nodes as specified in the Task Delegation message.
  • the record format for the Task Delegation message is optimized to remove any fields set by the receiving device.
  • the CompletionStatusFlag should always be 0 (incomplete) and the Response Text should always be empty.
  • fields such as these are not included in messages sent over the communications network so as to optimize the available space. Instead, such fields are inserted automatically after the device receives the message as part of the processing of the Task Delegation message.
  • Catalog Synchronization (9200) can involve update messages being sent from servers to a plurality of client devices (9210 & 9230), between a first device and a second device (9220), and from a client device to a server (9240).
  • a server sends catalog update A to a first device (9220) that is in contact with a second device.
  • the server is not aware of this P2P connection.
  • the catalog update A message includes a Distribution Node specifying that the First Device and the Second Device should receive this update.
  • the first device updates its own catalog and sends the catalog update A to the other devices in the Distribution Node list (the second device) to ensure that the devices remain synchronized (9220).
  • the first device does not send the catalog update to the server, as that is where the first device received catalog update A from, and thus is assumed to have it already.
  • the server is not included in the Distribution Node list.
  • the server has also sent catalog update A to the second device (9230).
  • the redundancy of updates to the second device is handled as described elsewhere in this document, and is allowed to ensure that at least one copy of the update arrives at the second device, and with a minimum of delay.
  • the second device When the second device receives catalog update A (9220 or 9230), it finds that the data items contained in the update are out of date, perhaps due to a recent change in the address of the second device, or loss of availability of a communication path to the second device, or for any other reason.
  • the second device creates catalog update B and sends it to the first device (9240) and to the server 9250).
  • the server then sends catalog update B to the first device (9260), according to the Distribution Node included in catalog update B.
  • A&A consists of sending a task announcement simuitaneously to a plurality of devices associated with users who are candidates for performing the task and collecting responses from them, or, optionally, who respond within a time limit, so as to determine which users are willing and able to accept the announced task.
  • Candidate users are specified by the task creator or an externa! system, and are identified based on current location, job category, work schedule, current task load, experience level, recent task loading, an explicit listing by the creator of the task, or by any combination of these or other criteria as determined to be proper by those having skill in the art.
  • candidate user's devices The selection of candidate users and the determination of which devices are associated with those candidate users ("candidate user's devices"), is performed by automated systems having access to required data sources, such as Node Stores, databases or user interfaces, by the user who creates the task, or a combination of these. An appropriate number (as determined by the task creator) of those responding affirmatively is selected and assigned the task. Push Mode is not required to allow Announcement & Acceptance to be used, but it can enhance the process by reducing the delay required to transmit an announcement to ail candidates. [00180] As depicted in Figure 10, the A&A process is initiated, in some exemplary implementations, by interaction with the User Interface (Ul) of the server or by external program interaction through a defined Application Program Interface (API).
  • Ul User Interface
  • API Application Program Interface
  • the required information is provided (10000), comprising the task to be assigned (e.g. provided as an FDL specification, a reference to such a specification), or a reference to a task hard-coded into the system), a description of the users who are candidates to perform the task that permits identification of the devices to deliver the task announcement to so that a Distribution List Node can be created to refer to them, the number of users required for the task, the method to be used to select the required number of users from among those responding affirmatively, an optional maximum time to wait for responses to be returned, or a time at which to stop waiting, and an action to take if the number of affirmatively responding users is smaller than the required number of users.
  • the task to be assigned e.g. provided as an FDL specification, a reference to such a specification), or a reference to a task hard-coded into the system
  • a description of the users who are candidates to perform the task that permits identification of the devices to deliver the task announcement to so that a Distribution List Node can be created to refer to them
  • the method used to specify users who are candidates for performing the task can consist of a list of employees with check-boxes for selection, a pull-down menu of job categories, a form to be filled out with various fields specifying detailed requirements such as location, job skills, work shift, experience level, or others, or any combination of these or other methods well known to those skilled in the art.
  • an external system comprising various data bases, software systems and user interactions, is used to create a list of users and associated data which is provided through the API for use in the A&A procedure.
  • the external system can provide all of the inputs required to initiate and complete the A&A process automatically as part of a complete business method, such as a "purchase order — work order - accounts receivable” system.
  • the method used to select the required number of users from among those responding affirmatively is specified as one of several automatic methods, such as “first to respond,” “least number of tasks already assigned,” “most experienced,” “closest,” “least recently tasked,” etc., or a manual method involving display of the list of affirmative responders to the task creator, and input of the users to select made by that person. If the number of affirmative responses is equal to the required number of users specified when the A&A process was initiated, no selection is required and the responding users are automatically selected. In some exemplary implementations, confirmation of the selection of these users is required using a manual method as described previously.
  • Action to be taken if the number of affirmatively responding users is smaller than the required number of users is specified as cancellation of the A&A request, assignment of the task to the user(s) who responded affirmatively, assignment of the users who responded affirmatively as well as additional users selected using an appropriate selection method (such as any of those used to select candidate users), repetition of the request, or any other appropriate action.
  • a Notify Device (type 2) message is sent to all selected candidate user devices (1 1010), using communication paths appropriate to the priority of the message. In preferred exemplary implementations, this message has a high priority and is sent as soon as possible by one or more available communication paths. Push mode is preferred for this; however, cooperative push mode or even pull mode are used alternatively where push mode is unavailable.
  • the server waits for responses from the notified devices, or for the specified time limit to elapse (11020).
  • the Display Manager of each receiving device responds to a Notify Device command by causing a message to appear on the device's user interface requesting input from the user as to whether or not the advertised task is accepted.
  • the Display Manager collects the user's response, and sends it back to the server using a communication path consistent with the priority of the data item being returned and the available communication paths.
  • this can comprise cancellation of the A&A procedure (10025), repetition of the request process in hopes that more users respond affirmatively when asked again (10030), selection of those users who responded affirmatively despite their number being lower than requested (10035), notification of third parties (managers or supervisors), or forcing selection of additional users by some appropriate means (10040).
  • Other exemplary implementations can provide additional or different actions, as will be obvious to those skilled in the art. If the A&A procedure was not cancelled or repeated, the selected users are assigned the specified task (10015), and the procedure is complete.
  • the server waits only until the required number of users have responded affirmatively and select them (11070). Otherwise, the server waits until all candidate users have responded (11050), until the optional maximum wait time has elapsed, or until the time to wait for has arrived (11030), and select from those that responded affirmatively (11100), if their numbers are greater than the required number of users (11080), return the users that responded affirmatively (1 1120) if their number is equal to the required number of users (11110), or take the specified action if an insufficient number of users responded affirmatively (1 1090) as above.
  • A&A message exchange (9000) comprises a Notify Device message from a server to a first device (9010) and from a server to a second device (9020).
  • Notify Device messages can be sent to any number of devices, and that the simplest case, involving a server, a first device and a second device, is representative of all aspects involved with a larger plurality of devices.
  • the first device and the second device send responses representing the respective device users' input to the Notify Device message to the server (9030 and 9040).
  • the second device responds affirmatively.
  • the first device responds negatively, or does not respond to the Notify Device message, or does not respond within the allowed time period, or responds affirmatively, but is not selected by the selection method of the server.
  • 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 is used to request specific service actions ("change filters on pump #12,” “cleanup on aisle six,” “respond to an alarm with machine #34"), volunteers for some duty ("need someone to work overtime tonight,” “Can anyone work on Saturday?”), information ("Who knows where the MIG welder is?" "Testing - Can anyone see this message?”), or any other appropriate purpose.
  • a supervisor may be assigned all tasks for his group, and delegate them to subordinates as those subordinates become available, or a device with a reliable communication path to a server, such as wired Ethernet, can act as a local repository of tasks for transfer to mobile devices using a P2P communication path, or a worker who cannot complete a task for any reason can transfer the task to a co-worker who can complete it.
  • a task can require sequential assignment to a plurality of users or devices.
  • a time tracking task such as filling out a timecard
  • a time tracking task can be assigned to a worker. Once the worker has completed the worker's portion of the task by filling in hours worked, the task is re-assigned to the worker's supervisor for verification and approval If there is a problem, the task can be re-assigned back to the worker for correction. This pattern can be repeated a plurality of times until the supervisor approves the timecard and it is sent back to the server to complete the task.
  • task delegation of the timecard task rather than treating the process as a set of different tasks (Ae.
  • a "worker fill out timecard” task, a "supervisor approval” task, an optional "worker correction of timecard” task, etc.) mediated by the server the process of getting approved timecard data to the server can be done largely independent of contact with the server.
  • this capability for device-to- device task delegation can improve efficiency and reduce costs. For example, by assigning the timecard tasks for a work crew to the supervisor, who interacts with the workers until the completed tasks are ready to be sent back to the server, only the supervisor needs communication with the server.
  • Tasks eligible for delegation include a "Distribution List Node,” which contains information required to connect with devices to which the task can be transferred, and optionally about the users of those devices, as described above.
  • a first exemplary procedure for delegating a task from a first device to a second device is depicted in Figure 12.
  • the user of the first device interacts with the Display Manager of the first device to select an assigned task to delegate (12000).
  • the method of selection in some exemplary implementations is a menu of assigned tasks to select from.
  • the task is selected by presenting tasks one at a time until the desired task is located, or tasks may have to be dealt with in a specified order, or by some other means.
  • the task's Distribution List Node is referenced to determine which other devices the task can be delegated to (12005), Distribution List Nodes contain data, and/or references to Catalogs containing data, that specify device and communication path information for each device that a task can be delegated to.
  • the data is unique to a specific task, or it can be shared between a plurality of tasks; for example, when the set of devices comprises those used by a supervisor's subordinates and the supervisor routinely delegates tasks to those subordinates.
  • the devices to which the task can be delegated are provided to the user of the first device in an appropriate manner (12010).
  • the display can consist of communication path descriptions and device addresses.
  • the display can consist of the user name associated with the device.
  • additional data about the user is displayed, such as work shift, experience level, last known location, communication paths supported, or other information.
  • such other information can comprise limitations on the use of distribution information, such as specification of specific devices or sets of devices that can make use of particular task distribution information contained in the Distribution List Nodes. For example, when a task with Distribution List Nodes specifying a plurality of potential devices to assign the task to is delegated by a first device to a second device, the first device can alter the Distribution List Node content such that the oniy available distribution information usable by the second device specifies the first device.
  • the first device ensures that the task will be re-delegated to the first device, possibly after partial completion of the task by the second device, and that when the task is re-delegated, the Distribution List Node information will still be associated with the task for use by the first device, which is not restricted by the limitations that specify the second device,
  • the user of the first device selects a recipient to delegate the task to (12015), and the task is packaged for transmission (12020).
  • Packaging a task for transmission can comprise node tree packing in some exemplary implementations.
  • a Distribution List Node is added to the task package, which is different from the Distribution List Node used in the current delegation procedure (e.g. a supervisor may wish to limit or prohibit re-delegation of the task).
  • the task package is encoded, compressed, encrypted, or has other processing performed on it in various exemplary impiementations.
  • the task is transmitted to the second device (12030), which acknowledges acceptance of the task (12037), and the server is sent a notification of the delegation (12035).
  • the notification sent to the server can optionally request notification to the first device by the server when the task has been completed and the server notified of the completion.
  • the first device when a task is delegated from a first device to a second device, the first device creates a persistent record, such as by use of a BLOB node, that records information sufficient to identify the task and the second device. This record is referred to herein as a "delegation record.” Delegation records are useful in propagating task cancellation information to each device that has been assigned the task, whether by a server or by delegation from another device.
  • the task is unpackaged and installed on the second device (12040).
  • This can, in some exemplary implementations, comprise reversal of any compression, encryption or other operations performed on the task by the first device, converting node references from the task-relative form to a form required for processing of the task (node tree unpacking), as well as linking the task to the task list, task manager, or other such structures, systems, or procedures used by the second device for managing tasks.
  • the server When the task is completed by the user of the second device (12045), and the server is notified of the task completion, the server notifies the first device of the task's completion (12055) if such notification was requested (12050). The first device deletes the delegation record created at the time the task was delegated (12060) and the process is complete.
  • Task Delegation by the first method (13100) message exchange consists of the initial assignment of a task from a server to a first device 13110).
  • the first device then delegates the task to a second device (13120), which acknowledges the delegation (13125), and the first device notifies the server of the task delegation (13130).
  • the second device notifies the server (13140), and the server notifies (if notification was requested) the first device (13150).
  • Method 2 A second exemplary procedure for delegating a task from a first device to a second device (Method 2) is depicted in the diagram in Figure 14.
  • the initial steps of the user of the first device interacting with the Display Manager of the first device to select an assigned task to delegate, the task's Distribution List Node being referenced to determine devices the task can be delegated to, the user selecting a device to delegate to, and the task being packaged for transmission, of the second exemplary procedure are identical to the first exemplary procedure (14500).
  • the task package is transmitted in the same manner as in Method 1 (14510) as well, and the assignee's device acknowledges acceptance of the task (14535), and the server is sent a notification of the delegation by the delegator's device (14515) as in Method 1. In Method 2, however, the delegator's device is not sent any notification of the assignee's completion of the assigned task as in Method 1.
  • the delegator's device logs the assigned task as pending (14520), and sends a checkpoint message containing a unique ID to the assignee's device (14525), after which the procedure pauses until the checkpoint message with the unique ID is received from the server (14530).
  • This pause is a conceptual pause in the illustrated steps, not a literal pause in processing on the delegator's device, which continues to process other work normally.
  • a pending task log is maintained for each device that tasks are delegated to.
  • logs are logically distinct, but are implemented in any way that is determined to be appropriate by those having skill in the art, such as each log in a separate sequential or indexed file, all logs in a single sequential or indexed file, each log in a separate table in a relational database system, all logs in a single table in a relational database, logs kept in a single catalog, or a plurality of catalogs, logs kept in a BLOB node, etc..
  • a task acceptance message also is sent to the server (14545) along with the checkpoint message with the unique ID (14550).
  • the first device then delegates the task to a second device (13220), receives the second device's acknowledgment of acceptance of the delegation (13230), and notifies the server of the task delegation (13240).
  • the first device then sends a checkpoint message (13250) to the second device.
  • the second device sends a task delegation notification to the first device (13260) and forwards the checkpoint message to the server (13270).
  • the server receives the checkpoint message, it forwards it to the first device (13280).
  • the second device notifies the server (13290), and the process is complete.
  • Method 1 for Task Delegation is useful when at least the first device is in communication with the server, so that it is sure that the server is notified of the task delegation to the second device.
  • Method 1 still can be used, provided that the server is willing to accept a task completion from the second device for a task assigned to the first device.
  • the second device sends the task completion to the first device, which then sends the task completion to the server.
  • Such relaying of task completions back through the chain of second devices to first devices can be done for any number of devices in a task delegation chain, as will be obvious to those with skill in the art.
  • Each first device creates a delegation record as the task is delegated to a second device, and deletes the delegation record when the task completion is returned and relayed up the chain and processing for the task is completed.
  • the delegation record enables each first device to validate that the task completion is being sent from a second device. [00206] If a task is canceled at a server, the cancellation is sent to the first device, or devices, that the task has been assigned to. If a first device has delegated the task to a second device, the first device, upon receiving the task cancellation, uses the delegation record created at the time the task was delegated to forward the cancellation to the second device.
  • a second device If a second device has delegated the task to a third device, the second device, upon receiving the task cancellation from the first device, uses its own delegation record to forward the task cancellation to the third device. As will be apparent to those of ordinary skill in the art, this process can continue for any number of delegations to a fourth, fifth, etc. device. As each delegating device completes forwarding the task cancellation, it deletes the delegation record for the task. [00207] If a task is canceled at the device the task is assigned to, the cancellation is sent to the server, which forwards the cancellation to the first device that the task was assigned to. The first device forwards the cancellation to the second device and deletes its delegation record for the task. The forwarding process can be repeated for a third device, a fourth device, etc.
  • Task cancellation can be required for many reasons, such as the task being a duplicate of another task (as can happen when automated equipment generates repair tasks due to faults being detected, and the same malfunction causes a plurality of fault events), a task being generated in error (e.g. when an assembly line is started, the specific sequence of machine starts can appear to indicate device failures, when in fact nothing is wrong and all will stabilize once ail machines are running), or when one task is subsumed by another (e.g. a task is generated to perform maintenance on a machine, but a subsequent failure of that machine results in another task to replace it, making the maintenance task unnecessary).
  • a task being generated in error e.g. when an assembly line is started, the specific sequence of machine starts can appear to indicate device failures, when in fact nothing is wrong and all will stabilize once ail machines are running
  • one task is subsumed by another (e.g. a task is generated to perform maintenance on a machine, but a subsequent failure of that machine results in another task to replace it, making the maintenance
  • Method 2 for Task Delegation is useful when at least the first device is not in communication with the server at the time of the delegation, such as can happen when the delegation is done using a P2P link between the devices while both are isolated from GPRS, Wi-Fi and other methods of communicating with the server.
  • the checkpoint message sent to the second device by the first device is sent to the first device from the server, it is clear that the second device has been in contact with the server, and so the server has been notified of the task delegation, even if the first device has not had an opportunity to send such notification, and that the first device no longer needs to keep track of the delegated task and can clear log entries up to and including that of the task associated with the checkpoint message received.
  • the exemplary illustrative non-limiting implementations provide systems, apparatuses, and software for enabling the exchange of "nodes," commands, and other data items between devices so as to provide reliable methods of interaction between a user of a first device and a user of a second device that can establish a local wireless connection even when communications between the wireless network and other more robust network devices are unreliable, intermittent, have limited bandwidth, or when one or more of the devices have limited resources.
  • more efficient communications, assignment of resources, and delegation of tasks can be accomplished.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L’invention concerne des systèmes, des logiciels, et des appareils qui, lorsque l'intensité du signal est faible ou intermittente, fournissent des télécommunications câblées et sans fil, permettent la coordination et la synchronisation des données et des processus par l'intermédiaire de différentes liaisons de communication, spécialement des liaisons de communications intermittentes ou non fiables, et permettent la gestion des applications mobiles sans fil dans ces environnements. La technologie de la présente invention concerne les domaines de l'informatique, des télécommunications, et de la gestion de données.
EP09815336A 2008-09-22 2009-09-21 Système et procédé destinés à la sélection d'une voie de communication automatique et dynamique, la synchronisation d'un dispositif distribué et une délégation de tâche Withdrawn EP2340666A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US9888608P 2008-09-22 2008-09-22
PCT/US2009/057691 WO2010033919A2 (fr) 2008-09-22 2009-09-21 Système et procédé destinés à la sélection d'une voie de communication automatique et dynamique, la synchronisation d'un dispositif distribué et une délégation de tâche

Publications (2)

Publication Number Publication Date
EP2340666A2 true EP2340666A2 (fr) 2011-07-06
EP2340666A4 EP2340666A4 (fr) 2012-06-20

Family

ID=42040182

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09815336A Withdrawn EP2340666A4 (fr) 2008-09-22 2009-09-21 Système et procédé destinés à la sélection d'une voie de communication automatique et dynamique, la synchronisation d'un dispositif distribué et une délégation de tâche

Country Status (7)

Country Link
EP (1) EP2340666A4 (fr)
JP (1) JP2012503449A (fr)
CN (1) CN102224751A (fr)
AU (1) AU2009292966A1 (fr)
BR (1) BRPI0913793A2 (fr)
CA (1) CA2738152A1 (fr)
WO (1) WO2010033919A2 (fr)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8065161B2 (en) 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
US9123077B2 (en) 2003-10-07 2015-09-01 Hospira, Inc. Medication management system
JP2010507176A (ja) 2006-10-16 2010-03-04 ホスピラ・インコーポレイテツド 複数のデバイス管理システムからの動態情報および構成情報を比較および利用するためのシステムおよび方法
US8271106B2 (en) 2009-04-17 2012-09-18 Hospira, Inc. System and method for configuring a rule set for medical event management and responses
CN106211239A (zh) * 2010-04-26 2016-12-07 交互数字专利控股公司 启用ad hoc网络的方法和设备
CN102231728A (zh) * 2011-05-16 2011-11-02 铁道部运输局 列车控制数据的通信方法、设备及系统
AU2012325937B2 (en) 2011-10-21 2018-03-01 Icu Medical, Inc. Medical device update system
TWI517731B (zh) * 2012-03-01 2016-01-11 宏達國際電子股份有限公司 多媒體資料分配系統及其操作方法
US9295094B2 (en) * 2012-05-07 2016-03-22 Qualcomm Incorporated System and method for peer-to-peer connection reestablishment
US8972296B2 (en) * 2012-12-31 2015-03-03 Ebay Inc. Dongle facilitated wireless consumer payments
US9641432B2 (en) 2013-03-06 2017-05-02 Icu Medical, Inc. Medical device communication method
JP6222950B2 (ja) * 2013-03-15 2017-11-01 キヤノン株式会社 印刷装置、その制御方法、及びプログラム
GB2516886A (en) 2013-08-02 2015-02-11 Nec Corp Communications system
WO2015031774A1 (fr) 2013-08-30 2015-03-05 Hospira, Inc. Système et procédé de surveillance et de gestion d'un régime de perfusion à distance
KR102099204B1 (ko) 2013-09-02 2020-05-15 삼성전자주식회사 전자장치 및 전자장치의 통신연결방법
US9662436B2 (en) 2013-09-20 2017-05-30 Icu Medical, Inc. Fail-safe drug infusion therapy system
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
AU2014353130B9 (en) 2013-11-19 2019-09-05 Icu Medical, Inc. Infusion pump automation system and method
US9584402B2 (en) * 2014-01-27 2017-02-28 Fasetto, Llc Systems and methods for peer to peer communication
WO2015168427A1 (fr) 2014-04-30 2015-11-05 Hospira, Inc. Système de soins de patient ayant un transfert d'alarme conditionnel
US9724470B2 (en) 2014-06-16 2017-08-08 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US9539383B2 (en) 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein
CN107438982B (zh) * 2015-04-21 2020-11-10 谷歌公司 多信道上的消息收发
US10491512B2 (en) * 2015-05-20 2019-11-26 Qualcomm Incorporated Supporting packet query-response transactions at lower layer
EP3304370B1 (fr) 2015-05-26 2020-12-30 ICU Medical, Inc. Procédé et système de pompe à perfusion pouvant utiliser un éditeur de pharmacothèque à source multiple
JP5994957B1 (ja) * 2015-11-05 2016-09-21 三菱電機株式会社 通信装置及び通信方法
DE102015015770B3 (de) * 2015-12-08 2017-06-08 Sew-Eurodrive Gmbh & Co Kg Verfahren zum Betreiben eines Systems und System
JP6070867B2 (ja) * 2016-01-07 2017-02-01 日本電気株式会社 通信装置、通信接続制御方法、及びプログラム
CN106211047A (zh) * 2016-02-26 2016-12-07 江苏中利电子信息科技有限公司 一种基于Mesh网络的可移动设备的通信系统
JP6414120B2 (ja) 2016-03-30 2018-10-31 トヨタ自動車株式会社 無線通信装置および無線通信方法
JP6418194B2 (ja) 2016-03-30 2018-11-07 トヨタ自動車株式会社 無線通信装置および無線通信方法
JP6881437B2 (ja) 2016-04-19 2021-06-02 ソニーグループ株式会社 情報処理装置、情報処理システムおよび情報処理方法
WO2018013842A1 (fr) 2016-07-14 2018-01-18 Icu Medical, Inc. Sélection de trajet multi-communication et système de sécurité pour dispositif médical
US10200887B2 (en) * 2016-09-27 2019-02-05 GM Global Technology Operations LLC Optimizing user experience in vehicles with multiple hotspots
JP6389229B2 (ja) * 2016-11-28 2018-09-12 Kddi株式会社 端末装置、プッシュ通知受信方法、及び、コンピュータプログラム
JP6869746B2 (ja) * 2017-02-22 2021-05-12 キヤノン株式会社 通信装置、その制御方法、プログラム
CN107222902A (zh) * 2017-07-24 2017-09-29 海信集团有限公司 一种传输数据的方法和装置
CN108063688A (zh) * 2017-12-14 2018-05-22 国家电网公司 通信维护方法及装置
EP4297379A3 (fr) 2018-07-17 2024-01-10 ICU Medical, Inc. Systèmes et procédés pour faciliter la messagerie clinique dans un environnement de réseau
US11152108B2 (en) 2018-07-17 2021-10-19 Icu Medical, Inc. Passing authentication token to authorize access to rest calls via web sockets
WO2020018388A1 (fr) 2018-07-17 2020-01-23 Icu Medical, Inc. Mise à jour de bibliothèques de médicaments et de logiciel opérationnel de pompes à perfusion dans un environnement en réseau
US11139058B2 (en) 2018-07-17 2021-10-05 Icu Medical, Inc. Reducing file transfer between cloud environment and infusion pumps
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
AU2019309766B2 (en) 2018-07-26 2024-06-13 Icu Medical, Inc. Drug library management system
JP7284999B2 (ja) * 2019-10-01 2023-06-01 学校法人東京電機大学 電子メール送信装置及び電子メール送信方法
EP4097958A4 (fr) * 2020-01-30 2024-03-06 Johann Donikian Système et procédé de sélection d'un trajet de communication électronique parmi un groupe de trajets potentiels
CN111372325B (zh) * 2020-02-21 2022-04-26 华为技术有限公司 建立Wi-Fi点对点连接的方法和装置
CN112134763B (zh) * 2020-09-25 2022-08-02 北京浪潮数据技术有限公司 一种集群节点间分层消息传输方法、系统、设备及介质
US11706682B2 (en) * 2020-12-22 2023-07-18 Google Llc Switchable communication transport for communication between primary devices and vehicle head units
CN114024876B (zh) * 2021-10-15 2023-06-16 中国联合网络通信集团有限公司 一种网络拨测方法、装置、设备及存储介质
CN114697260B (zh) * 2022-04-15 2023-03-24 北京航天驭星科技有限公司 自适应信息传输的方法、装置、系统、电子设备及介质
JP2024008735A (ja) * 2022-07-08 2024-01-19 株式会社日立製作所 データ処理経路管理システムおよびデータ処理経路管理方法
CN117412316A (zh) * 2023-12-14 2024-01-16 泰州星畅软件科技有限公司 具有信号强度检测的物联网无线系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1335563A2 (fr) * 2002-02-06 2003-08-13 Xerox Corporation Procédé pour la sécurisation de la communication sur un réseau
US20050243857A1 (en) * 2004-04-30 2005-11-03 Padcom, Inc. Simultaneously routing data over multiple wireless networks
US20050273488A1 (en) * 2004-06-07 2005-12-08 Christopher Ryan Migration of data between computers

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7024214B2 (en) * 2002-02-26 2006-04-04 Microsoft Corporation Synchronizing over a number of synchronization mechanisms using flexible rules
EP1766824A4 (fr) * 2004-06-30 2009-11-11 Jumpstart Wireless Corp Systeme et procede pour l'extension de systemes d'entreprises vers une population active mobile
US7526310B2 (en) * 2005-11-21 2009-04-28 James Alan Billmaier Methods and apparatus to initiate the transmission of user data from a mobile device
US7710958B2 (en) * 2006-01-20 2010-05-04 Iona Technologies Limited Method for recoverable message exchange independent of network protocols

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1335563A2 (fr) * 2002-02-06 2003-08-13 Xerox Corporation Procédé pour la sécurisation de la communication sur un réseau
US20050243857A1 (en) * 2004-04-30 2005-11-03 Padcom, Inc. Simultaneously routing data over multiple wireless networks
US20050273488A1 (en) * 2004-06-07 2005-12-08 Christopher Ryan Migration of data between computers

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2010033919A2 *

Also Published As

Publication number Publication date
JP2012503449A (ja) 2012-02-02
CN102224751A (zh) 2011-10-19
EP2340666A4 (fr) 2012-06-20
BRPI0913793A2 (pt) 2015-10-20
WO2010033919A2 (fr) 2010-03-25
WO2010033919A3 (fr) 2010-07-08
AU2009292966A1 (en) 2010-03-25
CA2738152A1 (fr) 2010-03-25

Similar Documents

Publication Publication Date Title
US8495244B2 (en) System and method for dynamic automatic communication path selection, distributed device synchronization and task delegation
WO2010033919A2 (fr) Système et procédé destinés à la sélection d'une voie de communication automatique et dynamique, la synchronisation d'un dispositif distribué et une délégation de tâche
CN113225782B (zh) 用于会话管理的方法、设备和计算机可读存储介质
US10986626B2 (en) Robust control plane for management of a multi-band wireless networking system
US9319956B2 (en) Method and apparatus for maintaining communications connections over a distributed wireless network
US8825767B2 (en) Scalable secure wireless interaction enabling methods, system and framework
CN101690337B (zh) 管理无线局域网中的密集的无线接入点基础结构
US8155645B2 (en) Bypass routing to a mobile device
US20050037787A1 (en) Wireless intelligent portable-server system (WIPSS)
KR20070055525A (ko) 코어 기반 노드를 사용하여 상태를 전송하기 위한 향상된기술들
CN101124801A (zh) 客户机协助的防火墙配置
CN101491005A (zh) 用于无线通信系统中的策略执行的方法和装置
US20050202825A1 (en) Systems and methods for transmitting data in a wireless communications network
CN100527770C (zh) 无线终端和通信控制方法
JP2005229583A (ja) ネットワーク制御装置、通信端末、およびネットワーク選択方法
KR20150045639A (ko) 네트워크를 선택하기 위한 방법 및 그 전자 장치
US20200100158A1 (en) Method for managing handover roaming
US20140179306A1 (en) Method of Routing of Data Messages from Mobile Devices Through Satellite and Terrestrial Communication Networks
CA2530580C (fr) Trajet de contournement vers un dispositif mobile
JP6555627B2 (ja) 情報配信装置、プッシュ通知送信方法、及び、コンピュータプログラム
JP6420410B2 (ja) 情報配信装置、プッシュ通知送信方法、及び、コンピュータプログラム
JP6389229B2 (ja) 端末装置、プッシュ通知受信方法、及び、コンピュータプログラム
JP2017092972A (ja) 情報配信装置、プッシュ通知送信方法、及び、コンピュータプログラム
JP6227583B2 (ja) 情報配信装置、プッシュ通知送信方法、及び、コンピュータプログラム

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20110407

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

AX Request for extension of the european patent

Extension state: AL BA RS

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BARTMAN, MICHAEL

Inventor name: GINTER, KARL

Inventor name: TOMAZIN, KENNETH, G.

Inventor name: CHHIBBER, SUBIR

Inventor name: PEKAREK, ADRIAN

Inventor name: TAFEL, BRYAN

Inventor name: BONAR, JEFFREY, G.

DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20120521

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 40/02 20090101AFI20120514BHEP

Ipc: H04W 88/02 20090101ALI20120514BHEP

Ipc: H04L 29/08 20060101ALI20120514BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20140401