Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS8582570 B2
Publication typeGrant
Application numberUS 13/758,866
Publication date12 Nov 2013
Filing date4 Feb 2013
Priority date27 Mar 2000
Fee statusPaid
Also published asUS6804232, US7218633, US7756129, US8068489, US8149829, US8582571, US8588196, US8588231, US8589599, US8675590, US8683092, US8700815, US8732347, US8732361, US8949484, US9003074, US9445260, US20050053065, US20070274309, US20100135219, US20100135293, US20100138585, US20130003667, US20130265947, US20130265998, US20130265999, US20130268696, US20130268698, US20130268699, US20130304945, US20130304946, US20140074955, US20140082222, US20140289380, US20140289429, US20140307723, US20150019684, US20170070846
Publication number13758866, 758866, US 8582570 B2, US 8582570B2, US-B2-8582570, US8582570 B2, US8582570B2
InventorsRobert J Donaghey
Original AssigneeTri-County Excelsior Foundation
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Automatic attachment and detachment for hub and peripheral devices
US 8582570 B2
Abstract
A network (100) includes a hub device (110) and at least one unattached peripheral device (120). The hub device comprises circuitry and a transceiver in communication with the circuitry. In operation, the hub device is configured to cause the transceiver to i) send a message to indicate the availability of the hub device for attachment to a first peripheral device, ii) receive, from the first peripheral device, a message indicating the availability of the first peripheral device for communication with the hub device, iii) send, to the first peripheral device, a signal including a first peripheral device identifier, iv) receive, from the first peripheral device, a response, v) send a hub response to the first peripheral device, and vi) receive, from the first peripheral device, a second peripheral response including the first peripheral device identifier.
Images(18)
Previous page
Next page
Claims(30)
What is claimed is:
1. A hub device for use within a personal area network, comprising:
circuitry, and
a transceiver in communication with the circuitry, the hub device configured to cause the transceiver to
i) send a message to indicate the availability of the hub device for attachment to a first peripheral device,
ii) receive, from the first peripheral device, a message indicating the availability of the first peripheral device for communication with the hub device,
iii) send, to the first peripheral device, a signal including a first peripheral device identifier,
iv) receive, from the first peripheral device, a response,
v) send a hub response to the first peripheral device, and
vi) receive, from the first peripheral device, a second peripheral response including the first peripheral device identifier;
wherein the hub device is operable such that a plurality of unique addresses is operable for being used for identification in association with the first peripheral device;
wherein the hub device is operable such that a first one of the unique addresses is operable for being utilized in connection with a first attachment to the first peripheral device and a second one of the unique addresses is operable for being utilized for data transfer;
wherein the hub device is operable such that the first one of the unique addresses is operable for being initially used in connection with the first attachment to the first peripheral device, after which the second one of the unique addresses is operable for being utilized for the data transfer;
wherein the hub device is operable such that the first one of the unique addresses has a first one or more channels associated therewith with a capability of transferring a first size of communication and the second one of the unique addresses has a second one or more channels associated therewith with a capability of transferring a second size of communication different than the first size of communication.
2. The device according to claim 1, wherein the hub device is operable such that prior to an initiation of the first attachment, there is no communication between the first peripheral device and the hub device.
3. The device according to claim 1, wherein the hub device is operable such that the unique addresses include MAC addresses; and the hub device is operable such that the unique addresses are generated by the hub device.
4. The device according to claim 1, wherein the hub device is operable such that the unique addresses each uniquely identify the first peripheral device on a shared communication medium.
5. The device according to claim 1, wherein the hub device is operable such that the transceiver is caused to follow a protocol that involves a plurality of data blocks and a plurality of status blocks that each include a channel identifier, wherein the status blocks are utilized for controlling retransmission.
6. The device according to claim 1, wherein the hub device is operable for providing the first attachment in the personal area network such that i) occurs before ii), ii) occurs before iii), iv) occurs before v), v) occurs before vi), no other communications occur between ii)-iii), no other communications occur between iii)-iv), no other communications occur between iv)-v), and no other communications occur between v)-vi).
7. A peripheral device for use within a personal area network, comprising:
circuitry, and
a transceiver in communication with the circuitry, the peripheral device configured to cause the transceiver to
i) receive a sent message from a hub device to indicate the availability of the hub device for attachment,
ii) send, to the hub device, a message indicating the availability of the peripheral device for communication with the hub device,
iii) receive, from the hub device, a signal including a peripheral device identifier,
iv) send a response to the hub device,
v) receive, from the hub device, a hub response, and
vi) send, to the hub device, a second peripheral response including the peripheral device identifier;
wherein the peripheral device is operable such that a plurality of unique addresses is operable for being used for identification in association therewith;
wherein the peripheral device is operable such that a first one of the unique addresses is utilized in association with a first attachment to the hub device, after which a second one of the unique addresses is utilized for data transfer;
wherein the peripheral device is operable such that the first one of the unique addresses has a first one or more channels associated therewith with a capability of transferring a first amount and the second one of the unique addresses has a second one or more channels associated therewith with a capability of transferring a second amount different than the first amount.
8. The device according to claim 7, wherein the peripheral device is operable such that i), ii), iii), iv), v), and vi) are carried out by a first entity; and i), ii), iii), iv), v), and vi) are further carried out by a second entity.
9. The device according to claim 8, wherein the peripheral device is operable such that the hub device associated with the first entity and the second entity includes the same hub device.
10. The device according to claim 7, wherein the peripheral device is operable such that the first one of the unique addresses is used for the first attachment without use of the second one of the unique addresses, after which the second one of the unique addresses is utilized.
11. A peripheral device, comprising:
circuitry, and
a transceiver in communication with the circuitry, the peripheral device configured to cause the transceiver to
receive a sent message from a hub device to indicate the availability of the hub device for attachment,
send, to the hub device, a message indicating the availability of the peripheral device for communication with the hub device,
receive, from the hub device, a signal including a peripheral device identifier,
send a response to the hub device,
receive, from the hub device, a hub response, and
send, to the hub device, a second peripheral response including the peripheral device identifier;
wherein the peripheral device is operable such that a unique address is operable for being assigned by the peripheral device prior to a completion of attachment to the hub device for use in identifying the peripheral device in connection with a group associated with the hub device;
wherein the peripheral device is operable such that a first one of a plurality of unique addresses has a first one or more channels associated therewith with a first data transfer capability associated therewith and a second one of the plurality of unique addresses has a second one or more channels associated therewith with a second data transfer capability associated therewith that is different than the first data transfer capability.
12. The device according to claim 11, wherein the peripheral device is configured such that a unique identifier is operable for being assigned by the hub device for use only in connection with the group associated with the hub device.
13. A device, comprising:
a first entity configured to:
receive a first entity-related other device message from at least one other device to indicate the availability of the at least one other device for attachment,
send, to the at least one other device, a first entity-related message indicating the availability for communication with the at least one other device,
receive, from the at least one other device, a first entity-related signal including a first entity-related device identifier,
send a first entity-related response to the at least one other device,
receive, from the at least one other device, a first entity-related other device response, and
send, to the at least one other device, a first entity-related second response including the first entity-related device identifier; and
a second entity configured to:
receive a second entity-related other apparatus message from at least one other apparatus to indicate the availability of the at least one other apparatus for attachment,
send, to the at least one other apparatus, a second entity-related message indicating the availability for communication with the at least one other apparatus,
receive, from the at least one other apparatus, a second entity-related signal including a second entity-related device identifier,
send a second entity-related response to the at least one other apparatus,
receive, from the at least one other apparatus, a second entity-related other apparatus response, and
send, to the at least one other apparatus, a second entity-related second response including the second entity-related device identifier;
wherein the first entity is configured such that a particular unique address is operable for being assigned by the first entity prior to a completion of attachment to the at least one other device for use in identifying the first entity in connection with a group associated with the at least one other device.
14. The device according to claim 13, wherein the device is configured such that the first entity includes a first virtual entity and the second entity includes a second virtual entity.
15. The device according to claim 13, wherein the device is configured such that the first entity includes an associated first controller and the second entity includes an associated second controller.
16. The device according to claim 13, wherein the device is configured such that the first entity includes an associated first transceiver and the second entity includes an associated second transceiver.
17. The device according to claim 13, wherein the device is configured such that the at least one other device is the at least one other apparatus.
18. The device according to claim 13, wherein the device is configured such that the at least one other device or the at least one other apparatus includes at least one hub device, and the device includes a peripheral device.
19. The device according to claim 13, wherein the device is configured such that a first unique address is used for identification in association with the first entity and a second unique address is used for identification in association with the second entity.
20. The device according to claim 19, wherein the device is configured such that the first unique address uniquely identifies the first entity on a shared communication medium and the second unique address uniquely identifies the second entity on the shared communication medium.
21. The device according to claim 13, wherein the second entity is configured such that a plurality of unique addresses is operable for being used for identification in association therewith.
22. The device according to claim 21, wherein the second entity is configured such that a first one of the unique addresses has a first one or more channels associated therewith with a capability of transferring a first amount and a second one of the unique addresses has a second one or more channels associated therewith with a capability of transferring a second amount different than the first amount.
23. The device according to claim 22, wherein the second entity is configured such that the first one of the unique addresses is operable for being utilized for a first attachment to the second entity and the second one of the unique addresses is operable for being utilized for data transfer; the first one of the unique addresses is operable for being initially used for the first attachment to the second entity, after which the second one of the unique addresses is operable for being utilized; there is no communication between the second entity and the at least one other apparatus prior to an initiation of the first attachment; each send and receive capability of the second entity includes no communication therebetween; and each send and receive capability of the second entity is for attachment purposes in a personal area network.
24. The device according to claim 21, wherein the second entity is configured such that a first one of the unique addresses is operable for being selected by the second entity, a second one of the unique addresses is operable for being selected by the at least one other apparatus, and the first entity is configured such that the particular unique address is assigned by the first entity by being self-selected by the first entity.
25. The device according to claim 13, wherein the first entity is configured such that a unique identifier is operable for being assigned by the at least one other device for use only in connection with the group associated with the at least one other device.
26. The device according to claim 13, wherein the first entity is configured such that the particular unique address is operable for being assigned by the first entity by being selected from one or more already-existing unique addresses.
27. The device according to claim 13, wherein the first entity is configured such that the particular unique address remains assigned for only a duration of the attachment.
28. The device according to claim 13, wherein the first entity is configured such that the particular unique address remains assigned for a duration of the attachment of the first entity to the at least one other device.
29. The device according to claim 1, wherein the one or more channels includes at least one of: one or more links, or one or more streams; one of the plurality of unique addresses includes the first peripheral device identifier; the size relates to a block size; and the message to indicate the availability of the hub device for attachment to the first peripheral device indicates by indicating the availability of the hub device for attachment to any peripheral device.
30. The device according to claim 11, wherein the unique address is either the first one of the plurality of unique addresses or the second one of the plurality of unique addresses;
and the unique address is the first peripheral device identifier.
Description
RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 13/430,650 filed on Mar. 26, 2012, which is a continuation of U.S. patent application Ser. No. 12/699,846 filed on Feb. 3, 2010, now U.S. Pat. No. 8,149,829, which is a continuation of U.S. patent application Ser. No. 11/728,246 filed on Mar. 23, 2007, now U.S. Pat. No. 7,756,129, which is a continuation of U.S. patent application Ser. No. 10/894,406 filed on Jul. 19, 2004, now U.S. Pat. No. 7,218,633, which is a continuation of U.S. patent application Ser. No. 09/535,591 filed on Mar. 27, 2000, now U.S. Pat. No. 6,804,232, which is related to U.S. patent application Ser. No. 09/536,191 filed on Mar. 27, 2000, all of which are incorporated herein by reference in their entirety for all purposes.

BACKGROUND AND FIELD OF THE INVENTION

A. Field of the Invention

The present invention relates to network protocols and, more particularly, to attachment protocols for use in a network.

B. Description of Related Art

Over the last decade, the size and power consumption of digital electronic devices has been progressively reduced. For example, personal computers have evolved from laptops and notebooks into hand-held or belt-carriable devices commonly referred to as personal digital assistants (PDAs). One area of carriable devices that has remained troublesome, however, is the coupling of peripheral devices or sensors to the main processing unit of the PDA. Generally, such coupling is performed through the use of connecting cables. The connecting cables restrict the handling of a peripheral in such a manner as to lose many of the advantages inherent in the PDA's small size and light weight. For a sensor, for example, that occasionally comes into contact with the PDA, the use of cables is particularly undesirable.

While some conventional systems have proposed linking a keyboard or a mouse to a main processing unit using infrared or radio frequency (RF) communications, such systems have typically been limited to a single peripheral unit with a dedicated channel of low capacity.

Based on the foregoing, it is desirable to develop a low power data network that provides highly reliable bidirectional data communication between a host or server processor unit and a varying number of peripheral units and/or sensors while avoiding interference from nearby similar systems.

SUMMARY OF THE INVENTION

Systems and methods consistent with the present invention address this need by providing a wireless personal area network that permits a host unit to communicate with peripheral units with minimal interference from neighboring systems.

A system consistent with the present invention includes a hub device and at least one unattached peripheral device. The unattached peripheral device transmits an attach request to the hub device with a selected address, receives a new address from the hub device to identify the unattached peripheral device, and communicates with the hub device using the new address.

In another implementation consistent with the present invention, a method for attaching an unattached peripheral device to a network having a hub device connected to multiple peripheral devices, includes receiving an attach request from the unattached peripheral device, the attach request identifying the unattached peripheral device to the hub device; generating a new address to identify the unattached peripheral device in response to the received attach request; sending the new address to the unattached peripheral device; and sending a confirmation message to the unattached peripheral device using the new address to attach the unattached peripheral device.

In yet another implementation consistent with the present invention, a method for attaching an unattached peripheral device to a network having a hub device connected to a set of peripheral devices, includes transmitting an attach request with a selected address to the hub device; receiving a new address from the hub device to identify the unattached peripheral device; and attaching to the network using the new address.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings:

FIG. 1 is a diagram of a personal area network (PAN) in which systems and methods consistent with the present invention may be implemented;

FIG. 2 is a simplified block diagram of the Hub of FIG. 1;

FIG. 3 is a simplified block diagram of a PEA of FIG. 1;

FIG. 4 is a block diagram of a software architecture of a Hub or PEA in an implementation consistent with the present invention;

FIG. 5 is an exemplary diagram of communication processing by the layers of the software architecture of FIG. 4;

FIG. 6 is an exemplary diagram of a data block architecture within the DCL of the Hub and PEA in an implementation consistent with the present invention;

FIG. 7A is a detailed diagram of an exemplary stream usage plan in an implementation consistent with the present invention;

FIG. 7B is a detailed diagram of an exemplary stream usage assignment in an implementation consistent with the present invention;

FIG. 8 is an exemplary diagram of a time division multiple access (TDMA) frame structure in an implementation consistent with the present invention;

FIG. 9A is a detailed diagram of activity within the Hub and PEA according to a TDMA plan consistent with the present invention;

FIG. 9B is a flowchart of the Hub activity of FIG. 9A;

FIG. 9C is a flowchart of the PEA activity of FIG. 9A;

FIGS. 10A and 10B are high-level diagrams of states that the Hub and PEA traverse during a data transfer in an implementation consistent with the present invention;

FIGS. 11 and 12 are flowcharts of Hub and PEA attachment processing, respectively, consistent with the present invention; and

FIG. 13 is a flowchart of PEA detachment and reattachment processing consistent with the present invention.

DETAILED DESCRIPTION

The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.

Systems and methods consistent with the present invention provide a wireless personal area network that permits a host device to communicate with a varying number of peripheral devices with minimal interference from neighboring networks. The host device uses tokens to manage all of the communication in the network, and automatic attachment and detachment mechanisms to communicate with the peripheral devices.

Network Overview

A Personal Area Network (PAN) is a local network that interconnects computers with devices (e.g., peripherals, sensors, actuators) within their immediate proximity. These devices may be located nearby and may frequently or occasionally come within range and go out of range of the computer. Some devices may be embedded within an infrastructure (e.g., a building or vehicle) so that they can become part of a PAN as needed.

A PAN, in an implementation consistent with the present invention, has low power consumption and small size, supports wireless communication without line-of-sight limitations, supports communication among networks of multiple devices (over 100 devices), and tolerates interference from other PAN systems operating within the vicinity. A PAN can also be easily integrated into a broad range of simple and complex devices, is low in cost, and is capable of being used worldwide.

FIG. 1 is a diagram of a PAN 100 consistent with the present invention. The PAN 100 includes a single Hub device 110 surrounded by multiple Personal Electronic Accessory (PEA) devices 120 configured in a star topology. Other topologies may also be possible. Each device is identified by a Media Access (MAC) address.

The Hub 110 orchestrates all communication in the PAN 100, which consists of communication between the Hub 110 and one or more PEA(s) 120. The Hub 110 manages the timing of the network, allocates available bandwidth among the currently attached PEAs 120 participating in the PAN 100, and supports the attachment, detachment, and reattachment of PEAs 120 to and from the PAN 100.

The Hub 110 may be a stationary device or may reside in some sort of wearable computer, such as a simple pager-like device, that may move from peripheral to peripheral. The Hub 110 could, however, include other devices.

The PEAs 120 may vary dramatically in terms of their complexity. A very simple PEA might include a movement sensor having an accelerometer, an 8-bit microcontroller, and a PAN interface. An intermediate PEA might include a bar code scanner and its microcontroller. More complex PEAs might include PDAs, cellular telephones, or even desktop PCs and workstations. The PEAs may include stationary devices located near the Hub and/or portable devices that move to and away from the Hub.

The Hub 110 and PEAs 120 communicate using multiplexed communication over a predefined set of streams. Logically, a stream is a one-way communications link between one PEA 120 and its Hub 110. Each stream has a predetermined size and direction. The Hub 110 uses stream numbers to identify communication channels for specific functions (e.g., data and control).

The Hub 110 uses MAC addresses to identify itself and the PEAs 120. The Hub 110 uses its own MAC address to broadcast to all PEAs 120. The Hub 110 might also use MAC addresses to identify virtual PEAs within any one physical PEA 120. The Hub 110 combines a MAC address and a stream number into a token, which it broadcasts to the PEAs 120 to control communication through the network 100. The PEA 120 responds to the Hub 110 if it identifies its own MAC address or the Hub MAC address in the token and if the stream number in the token is active for the MAC address of the PEA 120.

Exemplary Hub Device

FIG. 2 is a simplified block diagram of the Hub 110 of FIG. 1. The Hub 110 may be a battery-powered device that includes Hub host 210, digital control logic 220, radio frequency (RF) transceiver 230, and an antenna 240.

Hub host 210 may include anything from a simple microcontroller to a high performance microprocessor. The digital control logic (DCL) 220 may include a controller that maintains timing and coordinates the operations of the Hub host 210 and the RF transceiver 230. The DCL 220 is specifically designed to minimize power consumption, cost, and size of the Hub 110. Its design centers around a time-division multiple access (TDMA)-based network access protocol that exploits the short range nature of the PAN 100. The Hub host 210 causes the DCL 220 to initialize the network 100, send tokens and messages, and receive messages. Responses from the DCL 220 feed incoming messages to the Hub host 210.

The RF transceiver 230 includes a conventional RF transceiver that transmits and receives information via the antenna 240. The RF transceiver 230 may alternatively include separate transmitter and receiver devices controlled by the DCL 220. The antenna 240 includes a conventional antenna for transmitting and receiving information over the network.

While FIG. 2 shows the exemplary Hub 110 as consisting of three separate elements, these elements may be physically implemented in one or more integrated circuits. For example, the Hub host 210 and the DCL 220, the DCL 220 and the RF transceiver 230, or the Hub host 210, the DCL 220, and the RF transceiver 230 may be implemented as a single integrated circuit or separate integrated circuits. Moreover, one skilled in the art will recognize that the Hub 110 may include additional elements that aid in the sending, receiving, and processing of data.

Exemplary PEA Device

FIG. 3 is a simplified block diagram of the PEA 120. The PEA 120 may be a battery-powered device that includes a PEA host 310, DCL 320, RF transceiver 330, and an antenna 340. The PEA host 310 may include a sensor that responds to information from a user, an actuator that provides output to the user, a combination of a sensor and an actuator, or more complex circuitry, as described above.

The DCL 320 may include a controller that coordinates the operations of the PEA host 310 and the RF transceiver 330. The DCL 320 sequences the operations necessary in establishing synchronization with the Hub 110, in data communications, in coupling received information from the RF transceiver 330 to the PEA host 310, and in transmitting data from the PEA host 310 back to the Hub 110 through the RF transceiver 330.

The RF transceiver 330 includes a conventional RF transceiver that transmits and receives information via the antenna 340. The RF transceiver 330 may alternatively include separate transmitter and receiver devices controlled by the DCL 320. The antenna 340 includes a conventional antenna for transmitting and receiving information over the network.

While FIG. 3 shows the exemplary PEA 120 as consisting of three separate elements, these elements may be physically implemented in one or more integrated circuits. For example, the PEA host 310 and the DCL 320, the DCL 320 and the RF transceiver 330, or the PEA host 310, the DCL 320, and the RF transceiver 330 may be implemented as a single integrated circuit or separate integrated circuits. Moreover, one skilled in the art will recognize that the PEA 120 may include additional elements that aid in the sending, receiving, and processing of data.

Exemplary Software Architecture

FIG. 4 is an exemplary diagram of a software architecture 400 of the Hub 110 in an implementation consistent with the present invention. The software architecture 400 in the PEA 120 has a similar structure. The software architecture 400 includes several distinct layers, each designed to serve a specific purpose, including: (1) application 410, (2) link layer control (LLC) 420, (3) network interface (NI) 430, (4) link layer transport (LLT) 440, (5) link layer driver (LLD) 450, and (6) DCL hardware 460. The layers have application programming interfaces (APIs) to facilitate communication with lower layers. The LLD 450 is the lowest layer of software. Each layer may communicate with the next higher layer via procedural upcalls that the higher layer registers with the lower layer.

The application 410 may include any application executing on the Hub 110, such as a communication routine. The LLC 420 performs several miscellaneous tasks, such as initialization, attachment support, bandwidth control, and token planning. The LLC 420 orchestrates device initialization, including the initialization of the other layers in the software architecture 400, upon power-up.

The LLC 420 provides attachment support by providing attachment opportunities for unattached PEAs to attach to the Hub 110 so that they can communicate, providing MAC address assignment, and initializing an NI 430 and the layers below it for communication with a PEA 120. The LLC 420 provides bandwidth control through token planning. Through the use of tokens, the LLC 420 allocates bandwidth to permit one PEA 120 at a time to communicate with the Hub 110.

The NI 430 acts on its own behalf, or for an application 410 layer above it, to deliver data to the LLT 440 beneath it. The LLT 440 provides an ordered, reliable “snippet” (i.e., a data block) delivery service for the NI 430 through the use of encoding (e.g., 16-64 bytes of data plus a cyclic redundancy check (CRC)) and snippet retransmission. The LLT 440 accepts snippets, in order, from the NI 430 and delivers them using encoded status blocks (e.g., up to 2 bytes of status information translated through Forward Error Correction (FEC) into 6 bytes) for acknowledgments (ACKs).

The LLD 450 is the lowest level of software in the software architecture 400. The LLD 450 interacts with the DCL hardware 460. The LLD 450 initializes and updates data transfers via the DCL hardware 460 as it delivers and receives data blocks for the LLT 440, and processes hardware interrupts. The DCL hardware 460 is the hardware driven by the LLD 450.

FIG. 5 is an exemplary diagram of communication processing by the layers of the software architecture 400 of FIG. 4. In FIG. 5, the exemplary communications involve the transmission of a snippet from one node to another. This example assumes that the sending node is the Hub 110 and the receiving node is a PEA 120. Processing begins with the NI 430 of the Hub 110 deciding to send one or more bytes (but no more than will fit) in a snippet. The NI 430 exports the semantics that only one transaction is required to transmit these bytes to their destination (denoted by “(1)” in the figure). The NI 430 sends a unique identifier for the destination PEA 120 of the snippet to the LLT 440. The LLT 440 maps the PEA identifier to the MAC address assigned to the PEA 120 by the Hub 110.

The LLT 440 transmits the snippet across the network to the receiving device. To accomplish this, the LLT 440 adds header information (to indicate, for example, how many bytes in the snippet are padded bytes) and error checking information to the snippet, and employs reverse-direction status/acknowledgment messages and retransmissions. This is illustrated in FIG. 5 by the bidirectional arrow between the LLT 440 layers marked with “(n+m).” The number n of snippet transmissions and the number m of status transmissions in the reverse direction are mostly a function of the amount of noise in the wireless communication, which may be highly variable. The LLT 440 may also encrypt portions or all of the snippet using known encryption technology.

The LLT 440 uses the LLD 450 to provide a basic block and stream-oriented communications service, isolating the DCL 460 interface from the potentially complex processing required of the LLT 440. The LLT 440 uses multiple stream numbers to differentiate snippet and status blocks so that the LLD 450 need not know which blocks contain what kind of content. The LLD 450 reads and writes the hardware DCL 460 to trigger the transmission and reception of data blocks. The PEA LLT 440, through the PEA LLD 450, instructs the PEA DCL 460 which MAC address or addresses to respond to, and which stream numbers to respond to for each MAC address. The Hub LLT 440, through the Hub LLD 450, instructs the Hub DCL 460 which MAC addresses and stream numbers to combine into tokens and transmit so that the correct PEA 120 will respond. The Hub DCL 460 sends and receives (frequently in a corrupted form) the data blocks across the RF network via the Hub RF transceiver 230 (FIG. 2).

The Hub LLT 440 employs FEC for status, checksums and error checking for snippets, and performs retransmission control for both to ensure that each snippet is delivered reliably to its client (e.g., PEA LLT 440). The PEA LLT 440 delivers snippets in the same order that they were sent by the Hub NI 430 to the PEA NI 430. The PEA NI 430 takes the one or more bytes sent in the snippets and delivers them in order to the higher-level application 410, thereby completing the transmission.

Exemplary DCL Data Block Architecture

FIG. 6 is an exemplary diagram of a data block architecture 600 within the DCL of the Hub 110 and the PEA 120. The data block 600 contains a MAC address 610 designating a receiving or sending PEA 120, a stream number 620 for the communication, and a data buffer 630 which is full when sending and empty when receiving. As will be described later, the MAC address 610 and stream number 620 form the contents of a token 640. When the LLD 450 reads from and writes to the hardware DCL 46.0, the LLD 450 communicates the MAC address 610 and stream number 620 with the data buffer 630. When a PEA 120 receives a data block, the DCL 460 places the MAC address 610 and stream number 620 contained in the preceding token 640 in the data block 600 to keep track of the different data flows.

Exemplary Stream Architecture

The LLD 450 provides a multi-stream data transfer service for the LLT 440. While the LLT 440 is concerned with data snippets and status/acknowledgements, the LLD 450 is concerned with the size of data blocks and the direction of data transfers to and from the Hub 110.

FIG. 7A is a detailed diagram of an exemplary stream usage plan 700 in an implementation consistent with the present invention. A single stream usage plan may be predefined and used by the Hub 110 and all PEAs 120. The PEA 120 may have a different set of active streams for each MAC address it supports, and only responds to a token that specifies a MAC address of the PEA 120 and a stream that is active for that MAC address. In an implementation consistent with the present invention, every PEA 120 may support one or more active Hub-to-PEA streams associated with the Hub's MAC address.

The stream usage plan 700 includes several streams 710-740, each having a predefined size and data transfer direction. The plan 700 may, of course, have more or fewer entries and may accommodate more than the two data block sizes shown in the figure. In the plan 700, streams 0-2 (710) are used to transmit the contents of small data blocks from the PEA 120 to the Hub 110. Streams 3-7 (720) are used to transmit the contents of larger data blocks from the PEA 120 to the Hub 110. Streams 8-10 (730), on the other hand, are used to transmit the contents of small data blocks from the Hub 110 to the PEA 120. Streams 11-15 (740) are used to transmit the contents of larger data blocks from the Hub 110 to the PEA 120.

To avoid collisions, some of the streams are reserved for PEAs desiring to attach to the network and the rest are reserved for PEAs already attached to the network. With such an arrangement, a PEA 120 knows whether and what type of communication is scheduled by the Hub 110 based on a combination of the MAC address 610 and the stream number 620.

FIG. 7B is a detailed diagram of an exemplary stream usage assignment by the LLT 440 in an implementation consistent with the present invention. The LLT 440 assigns different streams to different communication purposes, reserving the streams with small block size for status, and using the streams with larger block size for snippets. For example, the LLT 440 may use four streams (4-7 and 12-15) for the transmission of snippets in each direction, two for odd parity snippets and two for even parity snippets. In other implementations consistent with the present invention, the LLT 440 uses different numbers of streams of each parity and direction.

The use of more than one stream for the same snippet allows a snippet to be sent in more than one form. For example, the LLT 440 may send a snippet in its actual form through one stream and in a form with bytes complemented and in reverse order through the other stream. The alternating use of different transformations of a snippet more evenly distributes transmission errors among the bits of the snippet as they are received, and hence facilitates the reconstruction of a snippet from multiple corrupted received versions. The receiver always knows which form of the snippet was transmitted based on its stream number.

The LLT 440 partitions the streams into two disjoint subsets, one for use with Hub 110 assigned MAC addresses 750 and the other for use with attaching PEAs' self-selected MAC addresses (AMACs) 760. Both the LLT 440 and the LLD 450 know the size and direction of each stream, but the LLT 450 is responsible for determining how the streams are used, how MAC numbers are assigned and used, and assuring that no two PEAs 120 respond to the same token (containing a MAC address and stream number) transmitted by the Hub 110. One exception to this includes the Hub's use of its MAC address to broadcast its heartbeat 770 (described below) to all PEAs 120.

Exemplary Communication

FIG. 8 is an exemplary diagram of a TDMA frame structure 800 of a TDMA plan consistent with the present invention. The TDMA frame 800 starts with a beacon 810, and then alternates token broadcasts 820 and data transfers 830. The Hub 110 broadcasts the beacon 810 at the start of each TDMA frame 800. The PEAs 120 use the beacon 810, which may contain a unique identifier of the Hub 110, to synchronize to the Hub 110.

Each token 640 (FIG. 6) transmitted by the Hub 110 in a token broadcast 820 includes a MAC address 610 (FIG. 6) and a stream number 620 for the data buffer 630 transfer that follows. The MAC address 610 and stream number 620 in the token 640 together specify a particular PEA 120 to transmit or receive data, or, in the case of the Hub's MAC address 610, specify no, many, or all PEAs to receive data from the Hub 110 (depending on the stream number). The stream number 620 in the token 640 indicates the direction of the data transfer 830 (Hub 110 to PEA 120 or PEA 120 to Hub 110), the number of bytes to be transferred, and the data source (for the sender) and the appropriate empty data block (for the receiver).

The TDMA plan controls the maximum number of bytes that can be sent in a data transfer 830. Not all of the permitted bytes need to be used in the data transfer 830, however, so the Hub 110 may schedule a status block in the initial segment of a TDMA time interval that is large enough to send a snippet. The Hub 110 and PEA 120 treat any left over bytes as no-ops to mark time. Any PEA 120 not involved in the data transfer uses all of the data transfer 830 bytes to mark time while waiting for the next token 640. The PEA 120 may also power down non-essential circuitry at this time to reduce power consumption.

FIG. 9A is an exemplary diagram of communication processing for transmitting a single data block from the Hub 110 to a PEA 120 according to the TDMA plan of FIG. 8. FIGS. 9B and 9C are flowcharts of the Hub 110 and PEA 120 activities, respectively, of FIG. 9A. The reference numbers in FIG. 9A correspond to the flowchart steps of FIGS. 9B and 9C.

With regard to the Hub activity, the Hub 110 responds to a token command in the TDMA plan [step 911] (FIG. 9B) by determining the location of the next data block 600 to send or receive [step 912]. The Hub 110 reads the block's MAC address 610 and stream number 620 [step 913] and generates a token 640 from the MAC address and stream number using FEC [step 914]. The Hub 110 then waits for the time for sending a token 640 in the TDMA plan (i.e., a token broadcast 820 in FIG. 8) [step 915] and broadcasts the token 640 to the PEAs 120 [step 916]. If the stream number 620 in the token 640 is zero (i.e., a NO-DATA-TRANSFER token), no PEA 120 will respond and the Hub 110 waits for the next token command in the TDMA plan [step 911].

If the stream number 620 is non-zero, however, the Hub 110 determines the size and direction of the data transmission from the stream number 620 and waits for the time for sending the data in the TDMA plan (i.e., a data transfer 830) [step 917]. Later, when instructed to do so by the TDMA plan (i.e., after the PEA 120 identified by the MAC address 610 has had enough time to prepare), the Hub 110 transmits the contents of the data buffer 630 [step 918]. The Hub 110 then prepares for the next token command in the TDMA plan [step 919].

With regard to the PEA activity, the PEA 120 reaches a token command in the TDMA plan [step 921] (FIG. 9C). The PEA 120 then listens for the forward error-corrected token 640, having a MAC address 610 and stream number 620, transmitted by the Hub 110 [step 922]. The PEA 120 decodes the MAC address from the forward error-corrected token [step 923] and, if it is not the PEA's 120 MAC address, sleeps through the next data transfer 830 in the TDMA plan [step 924]. Otherwise, the PEA 120 also decodes the stream number 620 from the token 640.

All PEAs 120 listen for the Hub heartbeat that the Hub 110 broadcasts with a token containing the Hub's MAC address 610 and the heartbeat stream 770. During attachment (described in more detail below), the PEA 120 may have two additional active MAC addresses 610, the one it selected for attachment and the one the Hub 110 assigned to the PEA 120. The streams are partitioned between these three classes of MAC addresses 610, so the PEA 120 may occasionally find that the token 640 contains a MAC address 610 that the PEA 120 supports, but that the stream number 620 in the token 640 is not one that the PEA 120 supports for this MAC address 610. In this case, the PEA 120 sleeps through the next data transfer 830 in the TDMA plan [step 924].

Since the PEA 120 supports more than one MAC address 610, the PEA 120 uses the MAC address 610 and the stream number 620 to identify a suitable empty data block [step 925]. The PEA 120 writes the MAC address 610 and stream number 620 it received in the token 640 from the Hub 110 into the data block [step 926]. The PEA 120 then determines the size and direction of the data transmission from the stream number 620 and waits for the transmission of the data buffer 630 contents from the Hub 110 during the next data transfer 830 in the TDMA plan [step 927]. The PEA 120 stores the data in the data block [step 928], and then prepares for the next token command in the TDMA plan [step 929].

FIGS. 9A-9C illustrate communication of a data block from the Hub 110 to a PEA 120. When the PEA 120 transfers a data block to the Hub 110, similar steps occur except that the Hub 110 first determines the next data block to receive (with its MAC address 610 and stream number 620) and the transmission of the data buffer 630 contents occurs in the opposite direction. The Hub 110 needs to arrange in advance for receiving data from PEAs 120 by populating the MAC address 610 and stream number 620 into data blocks with empty data buffers 630, because the Hub 110 generates the tokens for receiving data as well as for transmitting data.

FIGS. 10A and 10B are high-level diagrams of the states that the Hub 110 and PEA 120 LLT 440 (FIG. 4) go through during a data transfer in an implementation consistent with the present invention. FIG. 10A illustrates states of a Hub-to-PEA transfer and FIG. 10B illustrates states of a PEA-to-Hub transfer.

During the Hub-to-PEA transfer (FIG. 10A), the Hub 110 cycles through four states: fill, send even parity, fill, and send odd parity. The fill states indicate when the NI 430 (FIG. 4) may fill a data snippet. The even and odd send states indicate when the Hub 110 sends even numbered and odd numbered snippets to the PEA 120. The PEA 120 cycles through two states: want even and want odd. The two states indicate the PEA's 120 desire for data, with ‘want even’ indicating that the last snippet successfully received had odd parity. The PEA 120 communicates its current state to the Hub 110 via its status messages (i.e., the state changes serve as ACKs). The Hub 110 waits for a state change in the PEA 120 before it transitions to its next fill state.

During the PEA-to-Hub transfer (FIG. 10B), the Hub 110 cycles through six states: wait/listen for PEA-ready-to-send-even status, read even, send ACK and listen for status, wait/listen for PEA-ready-to-send-odd status, read odd, and send ACK and listen for status. According to this transfer, the PEA 120 cannot transmit data until the Hub 110 requests data, which it will only do if it sees from the PEA's status that the PEA 120 has the next data block ready.

The four listen for status states schedule when the Hub 110 asks to receive a status message from the PEA 120. The two ‘send ACK and listen for status’ states occur after successful receipt of a data block by the Hub 110, and in these two states the Hub 110 schedules both the sending of Hub status to the PEA 120 and receipt of the PEA status. The PEA status informs the Hub 110 when the PEA 120 has successfully received the Hub 110 status and has transitioned to the next ‘fill’ state.

Once the PEA 120 has prepared its next snippet, it changes its status to ‘have even’ or ‘have odd’ as appropriate. When the Hub 110 detects that the PEA 120 has advanced to the fill state or to ‘have even/odd,’ it stops scheduling the sending of Hub status (ACK) to the PEA 120. If the Hub 110 detects that the PEA 120 is in the ‘fill’ state, it transitions to the following ‘listen for status’ state. If the PEA 120 has already prepared a new snippet for transmission by the time the Hub 110 learns that its ACK was understood by the PEA 120, the Hub 110 skips the ‘listen for status’ state and moves immediately to the next appropriate ‘read even/odd’ state. In this state, the Hub 110 receives the snippet from the PEA 120.

The PEA 120 cycles through four states: fill, have even, fill, and have odd (i.e., the same four states the Hub 110 cycles through when sending snippets). The fill states indicate when the NI 430 (FIG. 4) can fill a data snippet. During the fill states, the PEA 110 sets its status to ‘have nothing to send.’ The PEA 120 does not transition its status to ‘have even’ or ‘have odd’ until the next snippet is filled and ready to send to the Hub 110. These two status states indicate the parity of the snippet that the PEA 120 is ready to send to the Hub 110. When the Hub 110 receives a status of ‘have even’ or ‘have odd’ and the last snippet it successfully received had the opposite parity, it schedules the receipt of data, which it thereafter acknowledges with a change of status that it sends to the PEA 120.

Exemplary Attachment Processing

The Hub 110 communicates with only attached PEAs 120 that have an assigned MAC address 610. An unattached PEA can attach to the Hub 110 when the Hub 110 gives it an opportunity to do so. Periodically, the Hub 110 schedules attachment opportunities for unattached PEAs that wish to attach to the Hub 110, using a small set of attach MAC (AMAC) addresses and a small set of streams dedicated to this purpose.

After selecting one of the designated AMAC addresses 610 at random to identify itself and preparing to send a small, possibly forward error-corrected, “attach-interest” message and a longer, possibly checksummed, “attach-request” message using this AMAC and the proper attach stream numbers 620, the PEA 120 waits for the Hub 110 to successfully read the attach-interest and then the attach-request messages. Reading of a valid attach-interest message by the Hub 110 causes the Hub 110 believe that there is a PEA 120 ready to send the longer (and hence more likely corrupted) attach-request.

Once a valid attach-interest is received, the Hub 110 schedules frequent receipt of the attach-request until it determines the contents of the attach-request, either by receiving the block intact with a valid checksum or by reconstructing the sent attach-request from two or more received instances of the sent attach-request. The Hub 110 then assigns a MAC address to the PEA 120, sending the address to the PEA 120 using its AMAC address.

The Hub 110 confirms receipt of the MAC address by scheduling the reading of a small, possibly forward error-corrected, attach-confirmation from the PEA 120 at its new MAC address 610. The Hub 110 follows this by sending a small, possibly forward error-corrected, confirmation to the PEA 120 at its MAC address so that the PEA 120 knows it is attached. The PEA 120 returns a final small, possibly forward error-corrected, confirmation acknowledgement to the Hub 110 so that the Hub 110, which is in control of all scheduled activity, has full knowledge of the state of the PEA 120. This MAC address remains assigned to that PEA 120 for the duration of the time that the PEA 120 is attached.

FIGS. 11 and 12 are flowcharts of Hub and PEA attachment processing, respectively, consistent with the present invention. When the Hub 110 establishes the network, its logic initializes the attachment process and, as long as the Hub 110 continues to function, periodically performs attachment processing. The Hub 110 periodically broadcasts heartbeats containing a Hub identifier (selecting a new heartbeat identifier value each time it reboots) and an indicator of the range of AMACs that can be selected from for the following attach opportunity [step 1110] (FIG. 11). The Hub 110 schedules an attach-interest via a token that schedules a small PEA-to-Hub transmission for each of the designated AMACs, so unattached PEAs may request attachment.

Each attaching PEA 120 selects a new AMAC at random from the indicated range when it hears the heartbeat. Because the Hub 110 may receive a garbled transmission whenever more than one PEA 120 transmits, the Hub 110 occasionally indicates a large AMAC range (especially after rebooting) so that at least one of a number of PEAs 120 may select a unique AMAC 610 and become attached. When no PEAs 120 have attached for some period of time, however, the Hub 110 may select a small range of AMACs 610 to reduce attachment overhead, assuming that PEAs 120 will arrive in its vicinity in at most small groups. The Hub 110 then listens for a valid attach-interest from an unattached PEA [step 1120]. The attach-interest is a PEA-to-Hub message having the AMAC address 610 selected by the unattached PEA 120.

Upon receiving a valid attach interest, the Hub 110 schedules a PEA-to-Hub attach-request token with the PEA's AMAC 610 and reads the PEA's attach-request [step 1130]. Due to the low-power wireless environment of the PAN 100, the attach-request transmission may take more than one attempt and hence may require scheduling the PEA-to-Hub attach-request token more than once. When the Hub 110 successfully receives the attach-request from the PEA, it assigns a MAC address to the PEA [step 1140]. In some cases, the Hub 110 chooses the MAC address from the set of AMAC addresses.

The Hub 110 sends the new MAC address 610 in an attach-assignment message to the now-identified PEA 120, still using the PEA's AMAC address 610 and a stream number 620 reserved for this purpose. The Hub 110 schedules and listens for an attach-confirmation response from the PEA 120 using the newly assigned MAC address 610 [step 1150].

Upon receiving the confirmation from the PEA 120, the Hub 110 sends its own confirmation, acknowledging that the PEA 120 has switched to its new MAC, to the PEA 120 and waits for a final acknowledgment from the PEA 120 [step 1160]. The Hub 110 continues to send the confirmation until it receives the acknowledgment from the PEA 120 or until it times out. In each of the steps above, the Hub 110 counts the number of attempts it makes to send or receive, and aborts the attachment effort if a predefined maximum number of attempts is exceeded. Upon receiving the final acknowledgment, the Hub 110 stops sending its attach confirmation, informs its NI 430 (FIG. 4) that the PEA 120 is attached, and begins exchanging both data and keep-alive messages (described below) with the PEA 120.

When an unattached PEA 120 enters the network, its LLC 420 (FIG. 4) instructs its LLT 440 to initialize attachment. Unlike the Hub 110, the PEA 120 waits to be polled. The PEA 120 instructs its DCL 460 to activate and associate the heartbeat stream 770 (FIG. 7B) with the Hub's MAC address and waits for the heartbeat broadcast from the Hub 110 [step 1210] (FIG. 12). The PEA 120 then selects a random AMAC address from the range indicated in the heartbeat to identify itself to the Hub 110 [step 1220]. The PEA 120 instructs its DCL 460 to send an attach-interest and an attach-request data block to the Hub 110, and activate and associate the streams with its AMAC address [step 1230]. The PEA 120 tells its driver to activate and respond to the selected AMAC address for the attach-assignment stream.

The unattached PEA 120 then waits for an attach-assignment with an assigned MAC address from the Hub 110 [step 1240]. Upon receiving the attach-assignment, the PEA 120 finds its Hub-assigned MAC address and tells its driver to use this MAC address to send an attach-confirmation to the Hub 110 to acknowledge receipt of its new MAC address [step 1250], activate all attached-PEA streams for its new MAC address, and deactivate the streams associated with its AMAC address.

The PEA 120 waits for an attach confirmation from the Hub 110 using the new MAC address [step 1260] and, upon receiving it, sends a final acknowledgment to the Hub 110 [step 1270]. The PEA 120 then tells its NI 430 that it is attached.

The PEA 120, if it hears another heartbeat from the Hub 110 before it completes attachment, discards any prior communication and begins its attachment processing over again with a new AMAC.

Exemplary Detachment and Reattachment Processing

The Hub 110 periodically informs all attached PEAs 120 that they are attached by sending them ‘keep-alive’ messages. The Hub 110 may send the messages at least as often as it transmits heartbeats. The Hub 110 may send individual small, possibly forward error-corrected, keep-alive messages to each attached PEA 120 when few PEAs 120 are attached, or may send larger, possibly forward error-corrected, keep-alive messages to groups of PEAs 120.

Whenever the Hub 110 schedules tokens for PEA-to-Hub communications, it sets a counter to zero. The counter resets to zero each time the Hub 110 successfully receives a block (either uncorrupted or reconstructed) from the PEA 120, and increments for unreadable blocks. If the counter exceeds a predefined threshold, the Hub 110 automatically detaches the PEA 120 without any negotiation with the PEA 120. After this happens, the Hub 110 no longer schedules data or status transfers to or from the PEA 120, and no longer sends it any keep-alive messages.

FIG. 13 is a flowchart of PEA detachment and reattachment processing consistent with the present invention. Each attached PEA 120 listens for Hub heartbeat and keep-alive messages [step 1310]. When the PEA 120 first attaches, and after receiving each keep-alive message, it resets its heartbeat counter to zero [step 1320]. Each time the PEA 120 hears a heartbeat, it increments the heartbeat counter [step 1330]. If the heartbeat counter exceeds a predefined threshold, the PEA 120 automatically assumes that the Hub 110 has detached it from the network 100 [step 1340]. After this happens, the PEA 120 attempts to reattach to the Hub 110 [step 1350], using attachment processing similar to that described with respect to FIGS. 11 and 12.

If the Hub 110 had not actually detached the PEA 120, then the attempt to reattach causes the Hub 110 to detach the PEA 120 so that the attempt to reattach can succeed. When the PEA 120 is out of range of the Hub 110, it may not hear from the Hub 110 and, therefore, does not change state or increment its heartbeat counter. The PEA 120 has no way to determine whether the Hub 110 has detached it or how long the Hub 110 might wait before detaching it. When the PEA 120 comes back into range of the Hub 110 and hears the Hub heartbeat (and keep-alive if sent), the PEA 120 then determines whether it is attached and attempts to reattach if necessary.

Conclusion

Systems and methods consistent with the present invention provide a wireless personal area network that permit a host device to communicate with a varying number of peripheral devices with minimal power and minimal interference from neighboring networks by using a customized TDMA protocol. The host device uses tokens to facilitate the transmission of data blocks through the network.

The foregoing description of exemplary embodiments of the present invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The scope of the invention is defined by the claims and their equivalents.

Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US454929329 Dec 198322 Oct 1985The United States Of America As Represented By The Secretary Of The ArmyTime division multiple access communications system
US47759312 Apr 19874 Oct 1988Hewlett-Packard CompanyDynamically configured computing device
US502918329 Jun 19892 Jul 1991Symbol Technologies, Inc.Packet data communication network
US51286645 Mar 19867 Jul 1992Ampex CorporationSearch technique for identifying slave devices connected to a serial bus
US515959229 Oct 199027 Oct 1992International Business Machines CorporationNetwork address management for a wired network supporting wireless communication to a plurality of mobile users
US52766801 May 19914 Jan 1994Telesystems Slw Inc.Wireless coupling of devices to wired network
US53176934 Apr 199131 May 1994Digital Equipment CorporationComputer peripheral device network with peripheral address resetting capabilities
US53966535 Jun 19927 Mar 1995Nokia Mobile Phones Ltd.Cellular telephone signalling circuit operable with different cellular telephone systems
US542505130 Jun 199413 Jun 1995Norand CorporationRadio frequency communication network having adaptive parameters
US542874824 Sep 199227 Jun 1995National Semiconductor CorporationMethod and apparatus for automatically configuring a computer peripheral
US546162724 Dec 199124 Oct 1995Rypinski; Chandos A.Access protocol for a common channel wireless network
US550272631 Jan 199226 Mar 1996Nellcor IncorporatedSerial layered medical network
US555081629 Dec 199427 Aug 1996Storage Technology CorporationMethod and apparatus for virtual switching
US557252820 Mar 19955 Nov 1996Novell, Inc.Mobile networking method and apparatus
US559478224 Feb 199414 Jan 1997Gte Mobile Communications Service CorporationMultiple mode personal wireless communications system
US562361031 Oct 199422 Apr 1997Intel CorporationSystem for assigning geographical addresses in a hierarchical serial bus by enabling upstream port and selectively enabling disabled ports at power on/reset
US565731722 Jul 199412 Aug 1997Norand CorporationHierarchical communication system using premises, peripheral and vehicular local area networking
US56595986 Oct 199419 Aug 1997Nokia Telecommunications OyDual mode subscriber terminal and a handover procedure of the dual mode subscriber terminal in a mobile telecommunication network
US568237923 Dec 199328 Oct 1997Norand CorporationWireless personal local area network
US5699357 *6 Mar 199616 Dec 1997Bbn CorporationPersonal data network
US570642814 Mar 19966 Jan 1998Lucent Technologies Inc.Multirate wireless data communication system
US579083711 Sep 19964 Aug 1998Ensoniq CorporationMethod and system for device virtualization based on an interrupt request in a dos-based environment
US57941597 Aug 199611 Aug 1998Nokia Mobile Phones LimitedDual band mobile station employing cross-connected transmitter and receiver circuits
US58128195 Jun 199522 Sep 1998Shiva CorporationRemote access apparatus and method which allow dynamic internet protocol (IP) address management
US583572328 Dec 199510 Nov 1998Intel CorporationDynamic assignment of multicast addresses
US583572521 Oct 199610 Nov 1998Cisco Technology, Inc.Dynamic address assignment and resolution technique
US584212510 Oct 199624 Nov 1998Amsc Subsidiary CorporationNetwork control center for satellite communication system
US590754410 May 199625 May 1999Rypinski; Chandos A.Hub controller architecture and function for a multiple access-point wireless communication network
US590943031 Dec 19961 Jun 1999Northern Telecom LimitedAddress assignment in an ATM switched network
US592610116 Nov 199520 Jul 1999Philips Electronics North America CorporationMethod and apparatus for routing messages in a network of nodes with minimal resources
US592834530 Sep 199627 Jul 1999Rosemont Inc.Field instrument with data bus communications protocol
US593874218 Aug 199517 Aug 1999General Magic, Inc.Method for configuring an intelligent low power serial bus
US594663423 Dec 199731 Aug 1999Nokia Mobile Phones LimitedMobile communications
US596034427 Jun 199728 Sep 1999Norand CorporationLocal area network having multiple channel wireless access
US596666714 Jul 199712 Oct 1999Motorola, Inc.Dual mode communication device and method
US597447524 Jun 199726 Oct 1999Microchip Technology IncorporatedMethod for flexible multiple access on a serial bus by a plurality of boards
US60029188 Nov 199614 Dec 1999Symbol Technologies, Inc.Power-saving arrangement and method for mobile units in communications network
US60061006 May 199421 Dec 1999Norand CorporationMulti-level, hierarchical radio-frequency communication system
US601631814 Jul 199718 Jan 2000Nec CorporationVirtual private network system over public mobile data network and virtual LAN
US60527252 Jul 199818 Apr 2000Lucent Technologies, Inc.Non-local dynamic internet protocol addressing system and method
US605810620 Oct 19972 May 2000Motorola, Inc.Network protocol method, access point device and peripheral devices for providing for an efficient centrally coordinated peer-to-peer wireless communications network
US605835530 Jun 19972 May 2000Ericsson Inc.Automatic power outage notification via CEBus interface
US611186530 May 199729 Aug 2000Qualcomm IncorporatedDual channel slotted paging
US6128290 *14 Oct 19973 Oct 2000Bbn CorporationPersonal data network
US619571213 Jun 199727 Feb 2001Intel CorporationDynamic discovery of wireless peripherals
US6272140 *2 Jul 19987 Aug 2001Gte Service CorporationBandwidth allocation in a wireless personal area network
US630822724 Jun 199823 Oct 2001Intel CorporationSystem for detecting a wireless peripheral device by a host computer transmitting a hail message including a persistent host identifier and a host address generated
US631116512 Jan 199930 Oct 2001Ncr CorporationTransaction processing systems
US631401929 Mar 19996 Nov 2001Hewlett-Packard CompanyMolecular-wire crossbar interconnect (MWCI) for signal routing and communications
US6331972 *3 Feb 199718 Dec 2001Motorola, Inc.Personal data storage and transaction device system and method
US6351468 *2 Jul 199826 Feb 2002Gte Service CorporationCommunications protocol in a wireless personal area network
US63536145 Mar 19985 Mar 20023Com CorporationMethod and protocol for distributed network address translation
US639326127 Feb 200121 May 2002Telxon CorporationMulti-communication access point
US6424623 *7 Dec 199923 Jul 2002Motorola, Inc.Virtual queuing system using proximity-based short-range wireless links
US64456908 Jun 19983 Sep 2002Koninklijke Philips Electronics N.V.Wireless coupling of incompatible nodes via a virtual network
US64456918 Jun 19983 Sep 2002Koninklijke Philips Electronics N. V.Wireless coupling of standardized networks and non-standardized nodes
US647818022 Aug 200012 Nov 2002William F. Dehn, Sr.Integral cap assembly for liquid container having a reversible pour spout
US65078737 Jul 199914 Jan 2003Nec CorporationNetwork address assigning system
US650795331 Jan 199714 Jan 2003Thomson Licensing S.A.System and method for interfacing multiple electronic devices
US651963430 Aug 199911 Feb 2003Samsung Electronics Co., Ltd.Method of generating IEEE 1394 virtual network in which a virtual network controller is connected to generate self ID packets as virtual node ID
US652911928 Aug 19984 Mar 2003Intel CorporationEstablishment of communications with a selected device in a multi-device environment
US653236819 Jan 200011 Mar 2003International Business Machines CorporationService advertisements in wireless local networks
US653948830 Nov 199925 Mar 2003Agere Systems Inc.System with a plurality of media access control circuits with a shared memory for storing data and synchronizing data from a clock domain to a host clock domain
US655682016 Dec 199829 Apr 2003Nokia CorporationMobility management for terminals with multiple subscriptions
US656044328 May 19996 May 2003Nokia CorporationAntenna sharing switching circuitry for multi-transceiver mobile terminal and method therefor
US656739613 Dec 199920 May 2003Telefonaktiebolaget Lm Ericsson (Publ)Adaptive throughput in packet data communication systems using idle time slot scheduling
US657085715 Dec 199827 May 2003Telefonaktiebolaget L M EricssonCentral multiple access control for frequency hopping radio networks
US657087513 Oct 199827 May 2003Intel CorporationAutomatic filtering and creation of virtual LANs among a plurality of switch ports
US65711039 May 200027 May 2003Agere Systems Inc.Establishing a communication link
US657426625 Jun 19993 Jun 2003Telefonaktiebolaget Lm Ericsson (Publ)Base-station-assisted terminal-to-terminal connection setup
US658070426 Aug 199917 Jun 2003Nokia CorporationDirect mode communication method between two mobile terminals in access point controlled wireless LAN systems
US659092817 Sep 19978 Jul 2003Telefonaktiebolaget Lm Ericsson (Publ)Frequency hopping piconets in an uncoordinated wireless multi-user system
US660072612 Nov 199929 Jul 2003Mobilian CorporationMultiple wireless communication protocol methods and apparatuses
US660073417 Dec 199829 Jul 2003Symbol Technologies, Inc.Apparatus for interfacing a wireless local network and a wired voice telecommunications system
US66037446 Aug 19985 Aug 2003International Business Machines CorporationConnection establishment method, communication method, state change transmission method, state changing method, wireless apparatus, wireless device, and computer
US66037581 Oct 19995 Aug 2003Webtv Networks, Inc.System for supporting multiple internet service providers on a single network
US660632331 Dec 199812 Aug 2003At&T Corp.Mobile MAC protocol for LAN-coupled devices interconnected by an ATM wide area network
US66147883 Mar 19982 Sep 2003Sun Microsystems, Inc.Network address management
US661528523 Nov 19982 Sep 2003Lucent Technologies Inc.Method and apparatus for dynamically determining an address uniquely identifying a hardware component on a common bus
US661876425 Jun 19999 Sep 2003Koninklijke Philips Electronics N.V.Method for enabling interaction between two home networks of different software architectures
US662201124 Sep 199916 Sep 2003Nokia Mobile Phones LimitedPaging
US664026828 Aug 199828 Oct 2003Intel CorporationDynamic polling mechanism for wireless devices
US665087114 Oct 199918 Nov 2003Agere Systems Inc.Cordless RF range extension for wireless piconets
US666553620 Jul 199916 Dec 2003Broadcom CorporationLocal area network having multiple channel wireless access
US66911736 Jul 199910 Feb 2004Widcomm, Inc.Distributed management of an extended network containing short-range wireless links
US669763829 Oct 199924 Feb 2004Denso CorporationIntelligent portable phone with dual mode operation for automobile use
US67013772 Sep 19982 Mar 2004Phoenix Contact Gmbh & Co. KgAutomation system and connecting apparatus for communication between two networks that use two different protocols with conversion between TCP/IP and PCP
US677233121 May 19993 Aug 2004International Business Machines CorporationMethod and apparatus for exclusively pairing wireless devices
US677527330 Dec 199910 Aug 2004At&T Corp.Simplified IP service control
US681052015 Dec 200026 Oct 2004Texas Instruments IncorporatedProgrammable multi-standard MAC architecture
US684509031 Mar 200018 Jan 2005Kabushiki Kaisha ToshibaRadio communication system and radio terminal device using faster and slower radio networks cooperatively
US685385118 Mar 19998 Feb 2005Nokia Mobile Phones LimitedDual mode terminal for accessing a cellular network directly or via a wireless intranet
US687414718 Nov 199929 Mar 2005Intel CorporationApparatus and method for networking driver protocol enhancement
US687417411 Jan 20025 Apr 2005Hotballs (Uk) LimitedPool insulation system
US68918206 Jul 199910 May 2005Broadcom CorporationUtilization of the internet protocol to facilitate communication involving mobile devices
US68922301 Feb 200010 May 2005Microsoft CorporationDynamic self-configuration for ad hoc peer networking using mark-up language formated description messages
US689498829 Sep 199917 May 2005Intel CorporationWireless apparatus having multiple coordinated transceivers for multiple wireless communication protocols
US691762630 Nov 199912 Jul 2005Cisco Technology, Inc.Apparatus and method for automatic cluster network device address assignment
US693761518 Feb 200030 Aug 2005Logitech Europe S.A.Multi-purpose bridge for wireless communications
US694414527 Oct 200313 Sep 2005Kabushiki Kaisha ToshibaCommunication node for enabling internetworking of network using request/response based data transfer and network using non-request/response based data transfer
US694739813 Nov 199820 Sep 2005Lucent Technologies Inc.Addressing scheme for a multimedia mobile network
US69730677 Jul 19996 Dec 2005Telefonaktiebolaget L M Ericsson (Publ)Multi-media protocol for slot-based communication systems
US698066021 May 199927 Dec 2005International Business Machines CorporationMethod and apparatus for efficiently initializing mobile wireless devices
US69900828 Nov 199924 Jan 2006Intel CorporationWireless apparatus having a transceiver equipped to support multiple wireless communication protocols
US701313826 Aug 200314 Mar 2006Broadcom CorporationLocal area network having multiple channel wireless access
US704286313 Mar 20009 May 2006Broadcom CorporationEfficient time-division multiplexed addressing protocol
US704664916 Jan 200116 May 2006Agere Systems Inc.Interoperability for bluetooth/IEEE 802.11
US706817112 Apr 200427 Jun 2006Telefonaktiebolaget Lm Ericsson (Publ)Radio transceiver on a chip
US710705226 Aug 200312 Sep 2006Broadcom CorporationLocal area network having multiple channel wireless access
US712692618 Sep 200024 Oct 2006Symbol Technologies, Inc.Multi-tier wireless communications architecture, applications and methods
US71619418 Aug 20009 Jan 2007Texas Instruments IncorporatedWireless packet communications with extended addressing capability
US719732624 Nov 200327 Mar 2007The Regents Of The University Of CaliforniaAdaptive local wireless communication system
US723961517 Jun 20033 Jul 2007Intel CorporationMultiple wireless communication protocol methods and apparatuses
US724565120 Dec 199917 Jul 2007Intel CorporationDual mode filter for mobile telecommunications
US725413127 Oct 20037 Aug 2007Texas Instruments IncorporatedInterconnected Ethernet and 1394 network
US738278631 Jan 20013 Jun 20083E Technologies International, Inc.Integrated phone-based home gateway system with a broadband communication device
US740336626 Jul 200322 Jul 2008Moeller GmbhControl circuit for an electromagnetic drive
US742402412 Aug 20049 Sep 20083E Technologies International, Inc.Broadband communications access device
US757772525 Feb 200018 Aug 2009Cisco Technology, Inc.IP address allocation in a network environment
US760624327 Oct 200320 Oct 2009Kabushiki Kaisha ToshibaRadio communication system and radio terminal device using faster and slower radio networks cooperatively
US76166218 May 200610 Nov 2009Broadcom CorporationEfficient time-division multiplexed addressing protocol
US769747029 Dec 200413 Apr 2010Broadcom CorporationUtilization of the internet protocol to facilitate communication involving mobile devices
US77109071 Aug 20064 May 2010Broadcom CorporationLocal area network having multiple channel wireless access
US773388529 Oct 20048 Jun 2010Microsoft CorporationExtending access to a device in a limited connectivity network to devices residing outside the limited connectivity network
US785600322 Mar 201021 Dec 2010Broadcom CorporationLocal area network having multiple channel wireless access
US801004210 Aug 200930 Aug 2011Andrew LlcRepeaters for wireless communication systems
US802732011 Apr 200727 Sep 2011Symbol Technologies, Inc.Wireless local area networks
US200100029125 Dec 20007 Jun 2001Larsson TonyMethods and arrangements in a telecommunications system
US2001001130126 Nov 19972 Aug 2001Canon Kabushiki KaishaCommuncation method, communication apparatus, and communication system with the communication apparatus
US2007008328711 Dec 200612 Apr 2007Defosse Erin MSystem, Method And Apparatus For Vending Machine Wireless Audit And Cashless Transaction Transport
US2007010999411 Jan 200717 May 2007Symbol Technologies, Inc.Cell controller for multiple wireless local area networks
US2010018904131 Mar 201029 Jul 2010Broadcom CorporationUtilization of the internet protocol to facilitate communication involving mobile devices
US2011005101831 Aug 20103 Mar 2011Sony CorporationBi-directional remote control unit and method of using the same
CA2179349A118 Jun 199619 Dec 1997Roger Yiu Ming CheungMethod and Apparatus for Providing a 3-Way Connection Between a Mobile Computing Device, a Stationary Computing Device and a Computer Network
EP874248A2 Title not available
GB2309856A Title not available
JP2000069046A Title not available
WO1997047125A13 Jun 199711 Dec 1997Gte Mobile Communications Service CorporationMulti-mode communication network with handset-assisted cordless base station activation
WO1999014897A216 Sep 199825 Mar 1999Telefonaktiebolaget Lm Ericsson (Publ)Frequency hopping piconets in an uncoordinated wireless multi-user system
Non-Patent Citations
Reference
1"ACCESS.bus, Specifications, Version 3.0," ACCESS.bus Industry Group, Sep. 1995.
2"Am79C930, PCnet(TM)-Mobile, Single-Chip Wireless LAN Media Access Controller," Advanced Micro Devices, Inc., Apr. 1997.
3"Am79C930, PCnet™—Mobile, Single-Chip Wireless LAN Media Access Controller," Advanced Micro Devices, Inc., Apr. 1997.
4"Bluetooth Whitepaper," AU-System, Jan. 2000.
5"Comprehensive Description of the Bluetooth System," Bluetooth SIG, Jun. 17, 1998.
6"DECT Standard, ETS 300 175-1, Digital Enhanced Cordless Telecommunications," ETSI, Sep. 1996.
7"DECT Standard, ETS 300 175-3, Digital Enhanced Cordless Telecommunications," ETSI, Sep. 1996.
8"DECT Standard, ETS 300 175-5, Digital Enhanced Cordless Telecommunications," ETSI, Jun. 1996.
9"Harris Semiconductor to Develop a Single-Chip PHY for Frequency Hopped Wireless Networking," Harris, Oct. 22, 1998.
10"IEEE 802.11 Specifications," IEEE, 1997.
11"IEEE Standard 802.2," IEEE, 1998.
12"IrDA Control Specification 1.0," Infrared Data Association, Jun. 30, 1998.
13"ISO/IEC 7498-1," ISO/IEC, Nov. 15, 1994.
14"PCD5095, DECT baseband controller," Philips Semiconductors, Nov. 19, 1997.
15"Shared Wireless Access Protocol (Cordless Access) Specification 1.21," The HomeRF Technical Committee, Jan. 27, 1999.
16"Specification of the Bluetooth System, v0.7," Bluetooth SIG, Oct. 15, 1998.
17"Specification of the Bluetooth System, v0.8," Bluetooth SIG, Jan. 21, 1999.
18"Specification of the Bluetooth System, v1.0," Bluetooth SIG, Dec. 1, 1999.
19Banyan VINES docwiki.cisco.com, Dec. 17, 2009.
20Barber, T., "BodyLAN(TM): A Low-Power Communications System," Massachusetts Institute of Technology, Feb. 1996.
21Barber, T., "BodyLAN™: A Low-Power Communications System," Massachusetts Institute of Technology, Feb. 1996.
22Bilgic, M., "A PCS Terminal Architecture to Access Multiple Networks," Omnipoint Corporation, 1996.
23Chang, H.; Sunwoo, M., "Implementation of a DSSS Modem ASIC Chip for Wireless LAN," Oct. 8, 1998.
24Croft, B.; Gilmore, J., "Bootstrap Protocol (BOOTP)," Sep. 1995.
25Dayem, R., "Mobile Data and Wireless LAN Technologies," Prentice Hall PTR, 1997.
26Diepstraten, W.; Belanger, P., "IEEE 802.11 Tutorial, MAC Basic Access Mechanism Privacy and Access Control," IEEE, Mar. 1996.
27Documents from Case 6:11-cv-00139.
28Droms, R., "Dynamic Host Configuration Protocol, RFC 1531," Bucknell University, Oct. 1993.
29Droms, R., "Dynamic Host Configuration Protocol, RFC 1541," Bucknell University, Oct. 1993.
30Droms, R., Dynamic Host Configuration Protocol, RFC 2131, Bucknell University, Mar. 1997.
31Ennis, G., "Impact of Bluetooth on 802.11 Direct Sequence," Ennis Associates, Sep. 15, 1998.
32Finlayson, R.; Mann, T.;Mogul, J.; Theimer, M., "A Reverse Address Resolution Protocol (RARP)," Computer Science Department, Stanford University, Jun. 1984.
33G. Maguire, Jr., "Personal Computing and Communication: the Near Future," Royal Institute of Technology, Stokholm, Nov. 10, 1998.
34Haartsen, J., "Baseband Overview," Ericsson Mobile Communications, Oct. 1998.
35Haartsen, J.; Allen, et al., "Bluetooth: Vision, Goals and Architecture," Mobile Computing and Communications Review, vol. 1, No. 2, 1998.
36I. Millar et al., "The IrDA Standard for High-Speed Infrared Communications," Hewlett Packard, Feb. 1998.
37J. Haartsen, et al., "The Bluetooth Radio System," IEEE Personal Communications, Feb. 2000.
38J. Zyren, "IEEE 802.11-98/378 Extension of Bluetooth and 802.11 Direct Sequence Interference Model," Harris Semiconductor, Nov. 11, 1998.
39J. Zyren, "IEEE 802.11—98/378 Extension of Bluetooth and 802.11 Direct Sequence Interference Model," Harris Semiconductor, Nov. 11, 1998.
40Kahn, J.; Barry, J.; Audeh, M.; Carruthers, J.; Krause, W.; Marsh, G., "Non-Directed Infrared Links for High-Capacity Wireless LANs," IEEE Personal Communications, 1994.
41Kardach, J., "Bluetooth Architecture Overview," Intel Corporation, 1998.
42Li, Y.; Leung, V., "Protocol Architecture for Universal Personal Computing," IEEE Journal on Selected Areas in Communications, Oct. 1997.
43N. Johansson, "Wireless Ad-hoc Networking with Bluetooth," Lund University, Sweden, 1999.
44Newman, P., "ATM Local Area Networks," IEEE Communications Magazine, Mar. 1994.
45Notice of Allowance in U.S. Appl. No. 13/763,604 dated Aug. 7, 2013.
46Notice of Allowance in U.S. Appl. No. 13/941,431 dated Aug. 27, 2013.
47Office Action Summary in U.S. Appl. No. 13/430,650 dated Jun. 11, 2013.
48Office Action Summary in U.S. Appl. No. 13/763,604 dated Jul. 8, 2013.
49Office Action Summary in U.S. Appl. No. 13/789,544 dated Jun. 10, 2013.
50Office Action Summary in U.S. Appl. No. 13/789,576 dated Jun. 10, 2013.
51O'Hara, B.; Petrick, A., "IEEE 802.11 Handbook: A Designer's Companion," The IEEE Press, 1999.
52P. Bhagwat et al., "BlueSky: A Cordless Networking Solution for Palmtop Computers," Mobicom '99, Sep. 1999.
53P. Bhagwat, "Networking over Bluetooth: Overview and issues," IBM, Feb. 29, 2000.
54P. Johansson, et al., "Short Range Radio Based Ad-hoc Networking: Performance and Properties," IEEE, 1999.
55R. Morrow, "Bluetooth Operation and Use," McGraw-Hill, 2002.
56S. Preus, et al., "Overview of Spontaneous Networking-Evolving Concepts and Technologies," University of Rostock, Germany, 1998.
57S. Preus, et al., "Overview of Spontaneous Networking—Evolving Concepts and Technologies," University of Rostock, Germany, 1998.
58Schiller, J.; Rosenstein, M., "A Protocol for the Dynamic Assignment of IP Addresses for use on the Ethernet," Massachusetts Institute of Technology, Sep. 1988.
59Shellhammer, S., "Coexistence Task Group Project Authorization Request (PAR)," IEEE, Sep. 15, 1999.
60Sidhu, G.; Andrews, R.; Oppenheimer, A., "Inside AppleTalk, Second edition," Addison-Wesley Publishing Co., Inc., 1990.
61T. Ors et al., "Analysis of an Adaptive Random Reservation MAC Protocol," VTC, Apr. 1998.
62Tourrilhes, J., "SWAP and TCP performance," HP Laboratories, Mar. 23, 1998.
63U.S. Appl. No. 13/430,650 dated Mar. 26, 2012.
64U.S. Appl. No. 13/754,807 dated Jan. 30, 2013.
65U.S. Appl. No. 13/763,604 dated Feb. 8, 2013.
66U.S. Appl. No. 13/763,609 dated Feb. 8, 2013.
67U.S. Appl. No. 13/789,544 dated Mar. 7, 2013.
68U.S. Appl. No. 13/789,576 dated Mar. 7, 2013.
69U.S. Appl. No. 13/941,427, filed Jul. 12, 2013.
70U.S. Appl. No. 13/941,431, filed Jul. 12, 2013.
71V. Bhagharhavan, "A Dynamic Addressing Scheme for Wireless Media Access," IEEE, Feb. 1995.
72Zyren, J., "Extension of Bluetooth and 802.11 Direct Sequence Interference Model," Harris Semiconductor, Nov. 11, 1998.
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US917412612 Aug 20053 Nov 2015Nintendo Co., Ltd.Wireless communication game system
US917412914 Mar 20133 Nov 2015Nintendo Co., Ltd.Wireless communication game system
US918037615 Jan 201510 Nov 2015Nintendo Co., Ltd.Game system, game apparatus, storage medium storing game program and game data exchange method
US932097214 Mar 201326 Apr 2016Nintendo Co., Ltd.Wireless communication game system
US934596818 Feb 201524 May 2016Nintendo Co., Ltd.Game system, game apparatus, storage medium storing game program and game data exchange method
US937071519 Feb 201521 Jun 2016Nintendo Co., Ltd.Game system, game apparatus, storage medium storing game program and game data exchange method
US938740416 Apr 201512 Jul 2016Nintendo Co., Ltd.Game system, game apparatus, storage medium storing game program and game data exchange method
US945726713 Aug 20154 Oct 2016Nintendo Co., Ltd.Game system, game apparatus, storage medium storing game program and game data exchange method
US945726813 Aug 20154 Oct 2016Nintendo Co., Ltd.Game system, game apparatus, storage medium storing game program and game data exchange method
US95049157 Apr 201629 Nov 2016Nintendo Co., Ltd.Wireless communication game system
US95269867 Apr 201627 Dec 2016Nintendo Co., Ltd.Wireless communication game system
US955011718 Aug 201524 Jan 2017Nintendo Co., Ltd.Game system, game apparatus, storage medium storing game program and game data exchange method
US978939817 Nov 201617 Oct 2017Nintendo Co., Ltd.Wireless communication game system
Legal Events
DateCodeEventDescription
12 May 2017FPAYFee payment
Year of fee payment: 4