Patent Application
20150223157
This disclosure relates generally to the field of electrical communications, and in particular, to multi-transport communication systems and methods.
Most of the computing and embedded devices are enabled with some communication medium. However, in some instances, different electronic devices in a particular area may not be able to communicate with each other directly because they may not have a common communication medium available to them. For example, a desktop personal computer (PC) without a wireless radio cannot communicate directly with a smartphone due to lack of common communication medium. As such, a system for allowing communication between various electronic devices regardless of specific communication technologies available to individual electronic devices is required.
In the description that follows, like components have been given the same reference numerals, regardless of whether they are shown in different embodiments. To illustrate an embodiment(s) of the present disclosure in a clear and concise manner, the drawings may not necessarily be to scale and certain features may be shown in somewhat schematic form. Features that are described and/or illustrated with respect to one embodiment may be used in the same way or in a similar way in one or more other embodiments and/or in combination with or instead of the features of the other embodiments.
In accordance with various embodiments of this disclosure, what is disclosed is a transport mechanism-agnostic communication system. The system may include a plurality of electronic devices, each configured with at least one transport mechanism, and at least one electronic device being configured with two or more heterogeneous transport mechanisms. The at least one electronic device is capable of communicating with each of the plurality of electronic devices and may include a processor, in communication with a memory, configured to execute instructions to translate and route data packets received from a first electronic device over a first transport to a second electronic device over a second heterogeneous transport, wherein the first electronic device can communicate with the second electronic device via the at least one electronic device.
In another embodiment, a method for transport mechanism-agnostic communication between a first electronic device and a second electronic device is described. The method may include connecting the first electronic device and the second electronic device, each enabled with at least one transport with a third electronic device enabled with two or more heterogeneous transports such that each of the first electronic device and the second electronic device can communicate with the third electronic device directly or indirectly over at least one transport, and translating and routing data packets received by the third electronic device from the first electronic device over a first transport to the second electronic device over the second transport.
Typically, communication between electronic devices in a network may include signal exchange or data transfer between two or more electronic devices such as, for example, control signals, short messaging service (point-to-point, cell broadcast or application-to-person) signals, multimedia messaging service signals, encoded audio signals, paging signals, voice over internet protocol (VoIP), peer-to-peer file uploading, peer-to-peer file downloading, video-over-wireless communication, TCP IP, and the like, or any combination thereof.
A network may include fixed devices, mobile devices, or a combination of both, that are connected by wired links, wireless links, or a combination of both. In various embodiments, wireless links may include, without limitation, WiFi, WiFi Direct, WiMax, Bluetooth, WWAN, WiGig, ZigBee, WiDi, one way radio, two way radio, any mobile broadband communication system (for example UMTS, CDMA, HIPERMAN, ETSI, BRAN, GSM/GPRS, EDGE, HSPA, LTE, etc.), and the like. Various devices within the network may have, for example, one or more radios, transmitters, receivers, transceivers, chipsets, amplifiers, filters, control logic circuits, network interface cards, antennas, antenna arrays, and the like.
In various embodiments, the network may include fixed devices having wired communication or wireless communication capabilities such as, for example, a wireless access point (AP), base station or node B, router, switch, hub, gateway, or any combination thereof. A fixed device may have generalized equipment set providing connectivity and/or information to another wireless device, such as one or more mobile devices. A fixed device may be, for example, a kitchen appliance (e.g. a refrigerator), a television, a temperature controller, household devices, a desktop PC, a router, a switch, a modem,
In various embodiments, the network may include electronic devices such as, for example, a computer, server, workstation, notebook computer, handheld computer, telephone, cellular telephone, personal digital assistant (PDA), combination cellular telephone and PDA, and so forth. In some embodiments, the fixed devices or the mobile devices may be capable of running software applications.
With this said, MTAP 100, in various embodiments, may be an electronic device capable of wired or wireless communication using multiple communication methods. For example, MTAP 100 may be capable of communicating with the various other electronic devices (105, 115, 125, 135, 145, and 155) using Ethernet, WiFi, WiFi Direct, Bluetooth, WiMax, WWAN, WiGig, ZigBee, any mobile broadband communication system (for example UMTS, CDMA, HIPERMAN, ETSI, BRAN, GSM/GPRS, EDGE, HSPA, LTE, etc.), one-way radio, two-way radio, and the like. MTAP 100 may include, for example, one or more radios, transmitters, receivers, transceivers, chipsets, amplifiers, filters, control logic circuits, network interface cards, antennas, antenna arrays, and the like. In some embodiments MTAP 100 may be a dedicated device. In other embodiments, MTAP 100 may be soft-implemented on a generic electronic device such as, for example, a computer, server, workstation, notebook computer, handheld computer, tablet, telephone, cellular telephone, personal digital assistant (PDA), combination cellular telephone and PDA, and so forth.
MTAP 100, in various embodiments, may run protocol stack implementations for the various transport mechanisms desired to be supported, depending on the transport mechanisms supported by the devices intended to be operated with MTAP 100. In the example depicted in
In addition, the electronic devices that intend to communicate through MTAP 100 may also run middleware applications that are capable of, inter alia, enabling device discovery, managing connections and supporting various services. The software running on MTAP 100 is capable of receiving data through one protocol stack and passing it down to another protocol stack. The software running on MTAP 100 is further capable of managing connections and routing data between various devices connected to it. Thus, MTAP 100 enables transport mechanism-agnostic communication between various electronic devices enabled with heterogeneous transport mechanisms when the various electronic devices are connected to MTAP 100.
Electronic devices may communicate with each other to provide services including, but not limited to, file transfer, media (images, audio and/or video) streaming, raw data transfer, exchange of control signals, VoIP signals, paging signals and so on. In various embodiments, service discovery may be integrated with device discovery. Each electronic device that can communicate with or through MTAP 100 runs the middleware which provides means for end-to-end device and service discovery. MTAP 100 keeps track of the list of services supported and/or offered by various electronic devices connected to it. Table 1 shows an example the device list maintained by MTAP 100. Various device specific parameters in the device list may include, for example, IsReal (to identify whether an interface is real or virtual), IsPassive (to identify whether a device is passive or active), and so forth.
Referring, again, to
One skilled in the art will appreciate that MTAP 100 may be able to communicate with multiple devices at the same time. For example, MTAP 100 may receive data from electronic device 105 and transmit it to electronic devices 115, 135 and 145 all at the same time using WiDi, 4G and Bluetooth transports, or receive data from electronic devices 115 and 135 and transmit it to electronic devices 125, 105 and 145. Accordingly, various combinations of one-to-many, many-to-one and many-to-many communications are conceived.
In some embodiments, MTAP 100 may not be able to act as a host (convergence point) for a particular transport. In such embodiments, MTAP 100 may act as a client to another device which can work as the host for that transport. This augments the capabilities of MTAP 100.
In some embodiments, MTAP 100 may not have all transports available to it. In such embodiments, another MTAP which supports a different set of transports can be used to augment the capabilities of MTAP 100, provided that they share at least one common transport between them. Hence, by chaining MTAPs, the number of transport mechanisms supported by the system can be extended, and a variety of electronic devices equipped with different transport mechanisms can be supported.
Referring, again, to
An electronic device supporting WiFi communication, for example, as depicted in
Alternately, an electronic device supporting a peer-to-peer transport such as, for example, Bluetooth, as depicted in
Similarly, in case of an electronic device supporting peer-to-peer transport such as, for example, WiFi Direct (case not shown in figure), MTAP 100 may act as a group owner or a client or both depending on the group owner intent of the devices connected to it. MTAP 100 advertises high group owner intent so as to become a group owner. However, MTAP 100 may not advertise group owner intent so high as to prevent group owner-only devices from connecting to MTAP 100. Depending on which role MTAP 100 assumes, it may discover devices differently. For example, if MTAP 100 is in peer-to-peer device role, it may periodically send device discovery request frames which advertise MTAP service (similar to the Bluetooth case). On discovering a WiFi Direct device in range, it will perform service discovery to identify support for the middleware. If MTAP 100 is in peer-to-peer client role, it may turn on the device discoverability and may listen for and accept any incoming connections. On the other hand, if MTAP 100 is in peer-to-peer group owner role, it may periodically send a Notice of Absence for listening on other channels and band for beacons from new WiFi Direct devices. Once a device is successfully connected to MTAP 100, MTAP 100 obtains available service list from the device.
In various embodiments, MTAP 100 maintains a device list as depicted in Table 1. Likewise, upon receipt of service information, MTAP 100 updates the device list from Table 1 and sends this updated list to all devices connected to it. This allows every device connected to MTAP 100 to discover the presence of other devices connected to MTAP 100 and also discover the services supported by each of those devices. This information may be made transparent to a user of MTAP 100 or any of the devices connected to MTAP 100.
Such a device list may be indexed using unique device IDs. For each ID, the associated device may be given a name derived from the advertisement data. If the device name is not available, a generic class of the device may be mentioned. Additionally, the device list may include an array of interface identifier for each device connected to MTAP 100 such as, for example, a BD address for Bluetooth devices or an IP address for Ethernet, WiFi or WiFi Direct devices. Further, each interface identifier may be associated with a bit containing information as to whether the interface is real or virtual. Every device connected to MTAP 100 has at least one real interface. If, for a device, a transport (interface) supported by MTAP 100 is not available to the device, MTAP 100 may assign a unique virtual address for such an interface. All interfaces available on connected devices may be represented in this manner in the device list.
Similarly, another bit containing information as to whether a device is passive or active may be associated with the device ID. The table may further contain, for each connected device, a descriptor for the control socket which is established at the time of device discovery as well as a listing of all the services supported by a particular device.
A passive device, as described herein, is a device where an end-user is not be able to configure or add software to what already exists on the device. As such, passive devices may not run the middleware for communicating with MTAP 100. Examples of passive devices include, but are not limited to, a Bluetooth headset, a key fob, a temperature controller, a kitchen appliance, a WiFi printer, a WiDi adapter, and so forth. For a passive device, the software running on MTAP 100 may include in the service list a known service provided by that passive device, which would have been discovered by MTAP 100 using the service discovery procedure intrinsic to the transport supported by the passive device.
It is to be noted that the device discovery process described herein is illustrative and a skilled artisan will appreciate that the device discovery process described herein is not restricted to WiFi, WiFi Direct or Bluetooth transports. The skilled artisan would easily be able to extend this process to other types of transports.
In various embodiments, the middleware may require user intervention so as to establish security and trust between various communicating devices connected to MTAP 100. For example, when the middleware on a client device detects the presence of MTAP 100 based on device discovery, it may prompt the user of the client device before establishing connection with MTAP 100. If the user accepts the connection, the client device and MTAP 100 may add one another to their respective trusted device lists such that any future connection between this particular MTAP and the client device can happen without any further user intervention. Particular transport protocols used by MTAP 100 and the client device may provide further security for any data communicated between the two.
Table 2 depicts an example of a connection map table for a routing entry maintained by MTAP 100 once two electronic devices supporting disparate transports are connected to each other through MTAP 100. Such routing entry allows data from one of the electronic devices connected to MTAP 100 to be forwarded directly to the second electronic device and vice-versa, for a particular service being used, while converting the transport protocols between the two. The initiating and responding socket descriptors are used for receiving data from one device and forwarding to the other. The routing entry may be cleared off once the transfer of data or communication between the two electronic devices is completed. It will be appreciated that Table 2 is illustrative and non-limiting. One skilled in the art will be able to conceive a connection map table including other parameters.
Upon receipt of an E2E connection request from SRC, at block 520, the MTAP looks up its device list for the real interface addresses of SRC and DEST, starts a data server on port (port Y) available on MTAP 100 and forwards the E2E connection request to DEST which includes the device ID for SRC, the device ID for DEST, desired E2E service supported by DEST (e.g. file sharing) and information about port Y on which the data server of MTAP 100 is open. MTAP 100 also appends an incomplete entry to the connection map table, containing the device IDs, the service requested and the initiating socket descriptor.
Once DEST receives the E2E connection request from MTAP 100, at block 525, the DEST notifies the user (e.g. User 2) DEST of the E2E connection request asking for permission for SRC to use the desired service (Service A, e.g file sharing). If User 2 accepts the connection request (YES), at step 541, DEST issues a Read command over port Y on which the data server for MTAP 100 is open and sends back a connection acceptance to the MTAP. At block 542, MTAP 100 completes the entry in its connection map table with the responding socket descriptor, issues a Read command over port X on which the data server for SRC is open and forwards the connection acceptance to SRC.
When SRC receives the connection acceptance, at block 543, SRC writes out to MTAP 100 via port X. At block 544, MTAP 100 receives the data from SRC via port X and writes out to DEST via port Y. In turn, at block 545, DEST receives the data from MTAP 100 via port Y and sends it to the designated application of Service A. When SRC encounters an end-of-file (EOF) for the data to be communicated to MTAP 100, at block 546, SRC closes its data server and port, following which MTAP 100 closes its data server and port Y and then, DEST notifies MTAP 100 of completion of data which then forwards it to SRC. MTAP 100 then removes the corresponding entry from the connection map table.
If, at block 530, User 2 declines the connection request (NO), at block 561, DEST sends out a connection rejection response to MTAP 100. MTAP 100, at block 562, forwards this connection rejection response to SRC. At block 563, MTAP 100 and SRC close their data servers and ports Y and X respectively. At block 564, MTAP 100 clears the corresponding connection map table entry and at block 565, SRC notifies its user (User 1) regarding the connection rejection.
Alternatively, the process can be understood using
When a user with SRC 550 selects a device from the list of DESTs and a service to connect to from the list of services supported by the chosen DEST 580 (e.g., file sharing, where the user intends to send a file from SRC 550 to DEST 580), SRC 550 does the following: (a) starts a data server (e.g., on port/channel ‘X’); and (b) sends an E2E connection request to MTAP 100 (on the control connection) with parameters including, but not limited to, the following: (i) SRC Device ID, (ii) DEST Device ID, (iii) E2E Service desired (e.g., file sharing), and (iv) Port/Channel ‘X’.
Upon receiving the E2E connection request, MTAP 100 does the following: (a) looks up its Available Devices table for the Real interface addresses of SRC 550 and DEST 580; (b) starts a data server (e.g., on port/channel ‘Y’); and (c) sends an E2E connection request to the DEST 580 (on the control connection) with parameters including, but not limited to, the following: (i) SRC Device ID, (ii) DEST Device ID, (iii) E2E Service desired (e.g., file sharing), and (iv) Port/Channel ‘Y’.
Upon receiving the E2E connection request, DEST 580 does the following: (a) displays a pop-up to the user asking for permission for SRC 550 to use the requested service (e.g., file sharing); and assuming that the user of DEST 580 accepts the request; (b) issues Read(Y) on the MTAP 100 and blocks; and (c) sends back a connection acceptance response to the MTAP 100.
Subsequently, upon receiving the E2E connection acceptance response, MTAP 100 does the following: (a) appends an entry to its Connection Map table; (b) issues Read(X) on SRC 550 and blocks; and (c) forwards the connection acceptance response to the SRC 550.
Upon receiving the E2E connection acceptance response, SRC 550 keeps writing out the file on the socket it had opened on its port/channel ‘X’.
MTAP 100, on receiving the bytes, keeps writing out (forwarding) the bytes on the socket it had opened on its port/channel ‘Y’.
DEST 580, on receiving the bytes, keeps writing out the bytes to the requested application (e.g., to a file when SRC 550 has requested file sharing application).
When SRC 550 encounters end-of-file (EOF), it closes down the server. MTAP 100 does the same. When DEST 580 encounters EOF, it notifies of transfer complete.
In some embodiments, one or more of the devices connected to MTAP 100 may be passive devices.
In the example of
Once the two devices 615 and 625 are in range and connected to MTAP 100, they are discoverable to each other. MTAP 100, in its device list, contains information of both the devices 615 and 625. Based on this information, MTAP 100 concludes that device 615 is a passive device and does not run the middleware. Thus, when device 625 requests connection to device 615 through the control channel between MTAP 100 and device 625, MTAP 100 uses its implementation of the protocol stack for transport 1 to establish connection with device 615. Once the handshake between MTAP 100 and device 615 completes, device 615 goes into “streaming state” (e.g. for a Bluetooth headset) for receiving data from MTAP 100. At this point, MTAP 100 notifies device 625 via the middleware on device 625 to relay the data desired by the user of device 615. The middleware of device 625 may then use any application suitable to relay the requested data to MTAP 100, which in turn relays the requested data to device 615 using the suitable protocol stack present on MTAP 100.
In embodiments where device 615 wishes to send a command (e.g. Pause, Play, Next Track, Previous Track, etc. e.g. for a Bluetooth headset), MTAP 100 receives the commands from device 615 via transport 1 and routes the information to the middleware of device 625 using a suitable protocol defined by the application being used by device 625 for relaying the requested data. Device 625 then takes the appropriate action. A skilled artisan will be able to conceive communication between various pairs of passive and active devices.
These and other features and characteristics, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of claims. As used in the specification and in the claims, the singular form of “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise.
Embodiments within the scope of the present disclosure may further include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or a special purpose computer. Such computer-readable media may include, but are not limited to, RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures. When information is transferred or provided over a network or another communications connection (either hardwired, wireless or a combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed as computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media.
Computer-executable instructions include, but are not limited to, instructions and data which cause a general purpose computer, a special purpose computer, or a special purpose processing device to perform a certain function or a group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, objects, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.
Having thus described the basic concepts, it will be rather apparent to those skilled in the art after reading this detailed disclosure that the foregoing detailed disclosure is intended to be presented by way of example only and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested by this disclosure, and are within the spirit and scope of the exemplary embodiments of this disclosure.
Moreover, certain terminology has been used to describe embodiments of the present disclosure. For example, the terms “one embodiment,” “an embodiment,” and/or “some embodiments” mean that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the present disclosure. In addition, the term “logic” is representative of hardware, firmware, software (or any combination thereof) to perform one or more functions. For instance, examples of “hardware” include, but are not limited to, an integrated circuit, a finite state machine, or even combinatorial logic. The integrated circuit may take the form of a processor such as a microprocessor, an application specific integrated circuit, a digital signal processor, a micro-controller, or the like.
Furthermore, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes and methods to any order except as can be specified in the claims. Although the above disclosure discusses through various examples what is currently considered to be a variety of useful embodiments of the disclosure, it is to be understood that such detail is solely for that purpose, and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover modifications and equivalent arrangements that are within the spirit and scope of the disclosed embodiments.
Similarly, it should be appreciated that in the foregoing description of embodiments of the present disclosure, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various inventive embodiments. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive embodiments lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description.
The following examples highlight non-limiting characteristics and attributes of the various and principles of the present disclosure:
Example 1 is a transport mechanism-agnostic communication system. The system may include a plurality of electronic devices, each configured with at least one transport mechanism and at least one electronic device being configured with two or more heterogeneous transport mechanisms, the at least one electronic device is capable of communicating with each of the plurality of electronic devices. The at least one electronic device includes a processor, in communication with a memory, configured to execute instructions to translate and route data packets received from a first electronic device over a first transport to a second electronic device over a second heterogeneous transport, wherein the first electronic device can communicate with the second electronic device via the at least one electronic device.
Example 2 is the system of example 1, wherein the at least one electronic device enables the plurality of electronic devices to discover one another upon establishment of connection between the plurality of electronic devices and the at least one electronic device.
Example 3 is the system of any one of examples 1 and 2, wherein the at least one electronic device enables the plurality of electronic devices to discover services supported by each of the plurality of electronic devices upon establishment of connection of the plurality of electronic devices with the at least one electronic device.
Example 4 is the system of any one of examples 1-3, wherein one or more of the plurality of electronic devices comprises a passive electronic device.
Example 5 is the system of any one of examples 1-4, wherein the at least one electronic device is enabled with two or more of transports including Ethernet, WiFi, WiFi Direct, WiMax, Bluetooth, WiGig, ZigBee, WiDi, CDMA, GSM, LIE, one way radio, and two way radio.
Example 6 is the system of any one of examples 1-5, wherein the plurality of electronic devices are enabled with at least one transport including Ethernet, WiFi, WiFi Direct, WiMax, Bluetooth, WiGig, ZigBee, WiDi, CDMA, GSM, LIE, one way radio, and two way radio.
Example 7 is the system of any one of examples 1-6, wherein the at least one electronic device routes a data packet to a second electronic device enabled with a second transport via a first electronic device enabled with a first transport and a second transport, and wherein the first electronic device communicates with the second electronic device over the second transport and the at least one electronic device communicates with the first electronic device over the first transport.
Example 8 is the system of any one of examples 1-7, wherein the at least one electronic device maintains, in a memory, a list comprising the plurality of electronic devices connected to the at least one electronic device and services offered by the plurality of electronic devices.
Example 9 is the system of example 8, wherein the list further comprises real and virtual transport identifiers for transport mechanisms supported by the at least one electronic device.
Example 10 is the system of any one of examples 1-9, wherein the first electronic device and the second electronic device establish mutual trust using explicit user confirmation.
Example 11 is a method for transport mechanism-agnostic communication between a first electronic device and a second electronic device. The method includes connecting the first electronic device and the second electronic device, each enabled with at least one transport with a third electronic device enabled with two or more heterogeneous transports such that each of the first electronic device and the second electronic device can communicate with the third electronic device directly or indirectly over at least one transport; and translating and routing data packets received by the third electronic device from the first electronic device over a first transport to the second electronic device over the second transport.
Example 12 is the method of example 11, wherein the third electronic device enables the first electronic device and the second electronic device to discover each other upon establishment of connection with the third electronic device.
Example 13 is the method of any one of examples 11 and 12, wherein the third electronic device enables the first electronic device to discover services supported by the second electronic device and vice-versa upon establishment of connection with the third electronic device.
Example 14 is the method of any one of examples 11-13, wherein the third electronic device is enabled with two or more transports including Ethernet, WiFi, WiFi Direct, WiMax, Bluetooth, WiGig, ZigBee, WiDi, CDMA, GSM, LTE, one way radio, and two way radio.
Example 15 is the method of any one of examples 11-14, wherein the first electronic device and the second electronic device are enabled with at least one transport including Ethernet, WiFi, WiFi Direct, WiMax, Bluetooth, WiGig, ZigBee, WiDi, CDMA, GSM, LTE, one way radio, and two way radio.
Example 16 is the method of any one of examples 11-15, further comprising maintaining, in a memory of the third electronic device, a list comprising electronic devices and services offered by the electronic devices connected to the third electronic device.
Example 17 is the method of example 16, wherein the list further comprises real and virtual transport identifiers for transport mechanisms supported by the third electronic device.
Example 18 is the method of any one of examples 11-17, further comprising establishing mutual trust between the first electronic device and the second electronic device using explicit user confirmation.
Example 19 is an electronic device comprising means for performing a method of any one of examples 11-18.
Example 20 is an electronic device comprising a processor, in communication with a memory, for executing instructions to perform a method of any one of examples 11-18.
Example 21 is a system comprising means for performing a method of any one of examples 11-18.
Example 22 is a system comprising at least one electronic device comprising a processor, in communication with a memory, for executing instructions to perform a method of any one of examples 11-18.
Example 23 is a computer-readable medium comprising computer-readable code physically embodied thereon which, when executed by a processor, causes the processor to perform a method of any one of examples 11-18.
Example 24 is a computer-readable medium comprising computer-readable instructions to implement, when executed, the method of any one of examples 11-18.
Example 25 is a computer program product comprising a computer-readable medium having computer program logic recorded thereon arranged to execute the method of any one of examples 11-18.
Example 26 is the system of example 1, wherein the at least one electronic device enables the plurality of electronic devices to discover one another upon establishment of connection between the plurality of electronic devices and the at least one electronic device.
Example 27 is the system of example 1, wherein the at least one electronic device enables the plurality of electronic devices to discover services supported by each of the plurality of electronic devices upon establishment of connection of the plurality of electronic devices with the at least one electronic device.
Example 28 is the system of example 1, wherein one or more of the plurality of electronic devices comprises a passive electronic device.
Example 29 is the system of example 1, wherein the at least one electronic device is enabled with two or more of transports including Ethernet, WiFi, WiFi Direct, WiMax, Bluetooth, WiGig, ZigBee, WiDi, CDMA, GSM, LTE, one way radio, and two way radio.
Example 30 is the system of example 1, wherein the plurality of electronic devices are enabled with at least one transport including Ethernet, WiFi, WiFi Direct, WiMax, Bluetooth, WiGig, ZigBee, WiDi, CDMA, GSM, LTE, one way radio, and two way radio.
Example 31 is the system of example 1, wherein the at least one electronic device routes a data packet to a second electronic device enabled with a second transport via a first electronic device enabled with a first transport and a second transport, and wherein the first electronic device communicates with the second electronic device over the second transport and the at least one electronic device communicates with the first electronic device over the first transport.
Example 32 is the system of example 1, wherein the at least one electronic device maintains, in a memory, a list comprising the plurality of electronic devices connected to the at least one electronic device and services offered by the plurality of electronic devices.
Example 33 is the system of example 32, wherein the list further comprises real and virtual transport identifiers for transport mechanisms supported by the at least one electronic device.
Example 34 is the system of example 1, wherein the first electronic device and the second electronic device establish mutual trust using explicit user confirmation.
Example 35 is the method of example 11, wherein the third electronic device enables the first electronic device and the second electronic device to discover each other upon establishment of connection with the third electronic device.
Example 36 is the method of example 11, wherein the third electronic device enables the first electronic device to discover services supported by the second electronic device and vice-versa upon establishment of connection with the third electronic device.
Example 37 is the method of example 11, wherein the third electronic device is enabled with two or more transports including Ethernet, WiFi, WiFi Direct, WiMax, Bluetooth, WiGig, ZigBee, WiDi, CDMA, GSM, LTE, one way radio, and two way radio.
Example 38 is the method of example 11, wherein the first electronic device and the second electronic device are enabled with at least one transport including Ethernet, WiFi, WiFi Direct, WiMax, Bluetooth, WiGig, ZigBee, WiDi, CDMA, GSM, LTE, one way radio, and two way radio.
Example 39 is the method of example 11, further comprising maintaining, in a memory of the third electronic device, a list comprising electronic devices and services offered by the electronic devices connected to the third electronic device.
Example 40 is the method of example 39, wherein the list further comprises real and virtual transport identifiers for transport mechanisms supported by the third electronic device.
Example 41 is the method of example 11, further comprising establishing mutual trust between the first electronic device and the second electronic device using explicit user confirmation.
Example 42 is a computer-readable medium comprising computer-readable code physically embodied thereon which, when executed by a processor, causes the processor to perform a method of example 11.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US13/48715 | 6/28/2013 | WO | 00 |
