Secure protocol for peer-to-peer network

Description

BACKGROUND

Many computers today have radios to support wireless communication. Wireless communication is used, for example, to connect to an access point of a network. By associating with the access point, a wireless computer can access devices on the network or on other networks reachable through that network, such as the Internet. As a result, the wireless computer can exchange data with many other devices, enabling many useful functions.

To enable computers to be configured for association with an access point, it is common for the access points to operate according to a standard. A common standard for devices that connect to access points is called Wi-Fi. This standard was promulgated by the Wi-Fi Alliance, and is widely used in portable computers. There are multiple versions of this standard, but any of them can be used to support connections through access points.

Wireless communications may also be used to form connections directly to other devices without using an access point. These connections are sometimes called “peer-to-peer” connections and may be used, for example, to allow a computer to connect to a mouse or keyboard wirelessly. More generally, peer-to-peer connections may be used to establish a group of devices of any type that may communicate without requiring an infrastructure. Wireless communications for these direct connections also have been standardized. A common standard for such wireless communications is called BLUETOOTH®.

In some instances, a wireless computer may concurrently connect to other devices through an access point and as part of a group engaging in peer-to-peer communications. To support such concurrent communication, some computers have multiple radios. More recently a standard has been proposed, called Wi-Fi Direct, that enables both an infrastructure connection and communication as part of a peer-to-peer group with similar wireless communications that can be processed with a single radio. This standard, also published by the Wi-Fi Alliance, extends the popular Wi-Fi communications standard for infrastructure-based communications to support direct connections.

Equipping computing devices to support direct connections is expected to expand the scenarios in which a wireless computing device can connect to other wireless devices. For example, computer users working together may more readily form a group that allows the users to share data without requiring any specific infrastructure. Similarly, a computer may more readily connect wirelessly to a printer, camera or devices providing other desired services.

SUMMARY

Secure communications are achieved, with very low user burden, in a peer-to-peer group by configuring a device, capable of operating as a controller of the peer-to-peer group, to provide unique master keys for each remote device that joins the group. The group controller may selectively remove one or more remote devices from the group by selectively invalidating the master keys for the devices to be removed. Other remote devices may continue on in the peer-to-peer group without disruption or a need to re-form the group.

Upon removal of a device from the group, the group controller, in addition to invalidating a master key associated with the device, may invalidate other keys generated from the master key. If the removed device attempts to further communicate as part of the group, its communications will not be recognized because the group controller does not have a key that will decrypt those communications. If the removed device attempts to re-join the group, the group controller will not recognize the master key used by that remote device. When an unrecognized device attempts to join the group without a recognized master key, the group controller may deny access, require user input or take other security actions.

However, remote devices that retain their master keys may continue on in the group. Such devices may even disconnect from the group and, using their master keys that remain valid, reconnect with the group.

The foregoing is a non-limiting summary of the invention, which is defined by the attached claims.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:

FIG. 1A is a sketch of an illustrative peer-to-peer group at a first time;

FIG. 1B is a sketch of an illustrative peer-to-peer group at a second time when a device has been removed from the group;

FIG. 1C is a sketch of a graphical user interface through which a user may input a command to remove a device from a peer-to-peer group;

FIG. 2 is a high level bock diagram of an illustrative computing device that may serve as a group controller of the group of FIG. 1A;

FIG. 3 is a block diagram of an illustrative embodiment of components within the computing device of FIG. 2 that control interactions with remote devices in the group;

FIG. 4A is a schematic representation of an illustrative embodiment of the key store of FIG. 3;

FIG. 4B is a schematic illustration of an alternative embodiment of the key store of FIG. 3;

FIGS. 5A and 5B, when connected at the points labeled A, form a flow chart of an illustrative method of operation of a computing device controlling a peer-to-peer group; and

FIG. 6 is a functional block diagram of an illustrative computing device in which embodiments of the invention may be implemented.

DETAILED DESCRIPTION

The inventors have recognized and appreciated a need for enhanced security in peer-to-peer groups. As peer-to-peer groups become more prevalent and are formed with protocols, such as the Wi-Fi Direct protocol, that are more powerful, usage patterns may create subtle security issues. However, it is undesirable for enhancing security to interfere with ease of use of peer-to-peer groups. Accordingly, the inventors have recognized and appreciated techniques to address security issues without significant impact on a user.

Security may be enhanced in a peer-to-peer group by equipping a device capable of acting as a controller for the group to generate a unique master key for each remote device connecting to the group. The controlling device may be further configured to selectively invalidate a master key for a device to be removed from the group, thereby preventing the removed device from later reconnecting to the group and possibly accessing data that a user of the removed device is not intended to view or creating other security issues. Other remote devices, for which a master key remains valid, can remain in the peer-to-peer group and even may disconnect and later reconnect in the group.

Such a controlling device may be readily implemented using known techniques for implementing a device controlling a peer-to-peer group, with modifications to support the generation, distribution and selective invalidation of unique master keys and to support selection of the appropriate unique master key for authentication of remote devices. A component to provide a user interface through which a user may control the selective invalidation of master keys may be included. However, each remote device may receive and use its unique master key in a conventional way such that enhanced security may be provided even with remote devices having conventional configurations.

As an example of how a subtle security issue may arise using conventional peer-to-peer techniques, FIG. 1 illustrates a peer-to-peer group formed in accordance with a peer-to-peer protocol. Such a peer-to-peer protocol may allow multiple wireless devices to connect without requiring any infrastructure.

In the example of FIG. 1A, five devices have joined in a group 110A in accordance with the protocol. One device, in this example device 120, serves as a controller for the group. The controller may perform functions that allow other wireless devices to join the group. Those functions may include, for example, provisioning each device in the group with a group address, such that information may be routed to the device. Additionally, the group controller may provision other wireless devices in the group with security information that allows those devices to be authenticated as they join or re-join the group. Further, the security information may be used to encrypt communications between the device controlling the group and other devices in the group.

Any suitable device may control a group. In the embodiment illustrated in FIG. 1A, device 120 is a general purpose computing device, such as a laptop computer. Such a device may be readily configured to perform control operations as described herein. For example, such a computing device may be configured to perform operations associated with the control of a peer-to-peer group by appropriately configuring communication software in the computing device. Though, it should be appreciated that the form of computing device that controls the group is not critical to the invention. To the contrary, in accordance with some peer-to-peer protocols, including the Wi-Fi Direct protocol, the device that controls a group may be identified by a negotiation among the devices seeking to form a group such that any suitably equipped device may act as the group controller.

In the example of FIG. 1, remote devices 132, 134, 136 and 140 have joined in group 110A with computing device 120. As a result of negotiation among those devices in accordance with a peer-to-peer protocol, or based on any other suitable selection criteria, computing device 120 has been determined to be the controller of group 110A and remote devices 132, 134, 136 and 140 have been determined to be clients. Accordingly, computing device 120 has provisioned each of the remote devices 132, 134, 136 and 140 with an address and keys for communication with computing device 120 as part of peer-to-peer group 110A. The formation and operation of group 110A maybe performed in accordance with a known standard or in any other suitable way.

As an example, computing device 120 may generate a master key for each of the remote devices 132, 134, 136 and 140. Conventionally, the same master key is provided to each of the devices that is admitted to group 110A. The master key may be distributed to each device authorized to join group 110A using a protocol that uses cryptographic techniques to avoid unauthorized entities from obtaining the master key. An example of such cryptographic techniques are reflected in a protocol called Wi-Fi protected setup (WPS). In that protocol, a user may input into computing device 120 a PIN or other identifying information for a remote device. Input of that information may signify to computing device 120 that a remote device is authorized by the user to join group 110A if the remote device similarly can demonstrate that it has a copy of the identifying information.

Input of a PIN or other identifying information provides computing device 120 with information shared with a remote device that is not obtainable by other devices in the vicinity. Accordingly, this information may be used in encrypting communications exchanged between computing device 120 and a remote device seeking to join network 110A. Through use of cryptographic techniques based on this information, computing device 120 may securely communicate the master key for group 110A to a remote device authorized to join group 110A.

Once a remote device has the master key for group 110A, the remote device can enter into a further exchange with computing device 120 to generate a transient key. Though the same master key is conventionally used for each of the remote devices in a group, a different transient key may be generated for each device. This transient key may then be used to encrypt and decrypt communications exchanged between the remote device for which the transient key was generated and computing device 120 acting as the controller for group 110A.

The exchange between computing device 120 and a remote device by which a transient key is generated may be performed according to any suitable protocol. An example of a suitable protocol is the Wi-Fi Protected Access (WPA2) protocol. An exchange of messages in accordance with this protocol, in addition to generating a transient key for a remote device, may also be used to authenticate that a device has the master key for the group.

Accordingly, a device that temporarily is disconnected from group 110A may re-join the group without further user authentication. Such a capability, may be particularly useful for groups involving portable electronic devices. Because peer-to-peer networking is generally performed with low power communications, when mobile devices are moved, sometimes as little as 10 or 50 feet, the devices forming the group may lose the ability to communicate. However, when the devices are brought back into proximity, a user may intend that the devices reconnect to re-form the group. In order to re-form the group, a remote device with the group master key may exchange communications with the device acting as the group controller in accordance with the WPA2 protocol, or other protocol used by the group, such that the remote device with the master key is authenticated to the device acting as the group controller and a new transient key is generated for that device.

The Applicants have recognized and appreciated that this flexibility to form and later re-form a group, though desirable in some scenarios, may be undesirable in other scenarios. FIG. 1A illustrates a scenario in which computing device 120, acting as a controller for group 110A is in close proximity to remote devices 132, 134 and 136. These remote devices, may represent other devices used by a user of computing device 120. For example, remote device 132 may be a Smartphone. Remote device 134 may be a camera, and remote device 136 may be a printer. The user of computing device 120 may intend that computing device 120 re-form a group including any or all of remote devices 132, 134 and 136 whenever computing device 120 is moved to be near those remote devices. In this way, for example, a user of computing device 120 may be able to print on the printer, represented as remote device 136. Similarly, the user may be able to upload pictures from the camera represented as remote device 134 or synchronize contact information with the Smartphone, represented as remote device 132.

So long as the user of computing device 120 controls the remote devices, little security risk is posed by allowing a group to be reformed without further user action. However, if a user of computing device 120 allows another remote device to join the group, even if that remote device is disconnected from the group, it may re-join the group at any time, which may not be a behavior expected or desired by a user of computing device 120.

For example, a user of computing device 120 may authorize remote device 140, representing another portable computing device, to join group 110A. Such authentication may be given to temporarily allow a user of computing device 140 to use device 136 to print a document or to access another of the remote devices in group 110A. Such authorization may be given to allow the user of computing device 140 to exchange a file or some other limited amount information with computing device 120. Though, once these actions are complete, particularly if remote device is disconnected from group 110A, a user of computing device 120 may neither expect nor want remote device 140 to rejoin group 110A.

The ability of a remote device to join a group without user authorization may pose a security issue in some circumstances. A security issue may be posed, for example, if a third party operating remote device 140 can access information on computing device 120 or other remote devices within group 110A. Moreover, a security issue may arise if remote device 140 can access information on other devices within group 110A. Further, a security issue may arise if remote device 140 can, through computing device 120 access services from computing device 120 or other remote devices in group 110A. As a specific example, the Wi-Fi Direct protocol allows a computing device, such as computing device 120 to be a member of a peer-to-peer group while being connected to an infrastructure network, such as may exist in an enterprise. If a third party using remote device 140 can access other networks to which computing device 120 is connected, security issues may be compounded.

With a conventional implementation of a peer-to-peer group in which each remote device obtains a copy of a master key for the group, removing a remote device from the group, if a user of computing device 120 is even aware of the need to completely remove the device, would entail disbanding the group and forming a new peer-to-peer group. FIG. 1B shows that a new group 110B has been formed including remote devices 132, 134 and 136, but excluding remote device 140. Such a group may be formed by repeating the group formation steps, including obtaining user authorization to admit each of the devices 132, 134 and 136 into the group.

The applicants have recognized and appreciated that making a new group in order to remove a remote device may be undesirable for a user. Accordingly, in some embodiments, computing device 120 or other device that may act as a group controller may be configured such that a remote device may be removed from a group. A device that is removed from the group may not be able to re-join the group without re-authorization from a user.

As an example, computing device 120 may be configured with components that represent a graphical user interface through which a user may input a command to remove a remote device from a group. FIG. 1C shows a graphical user interface 150 through which a user may input such a command.

In the example of FIG. 1C, the user interface 150 may be a portion of a user interface presented by a device manager component executing within the operating system of computing device 120. Such a user interface may be presented in response to user input indicating a desire to provide commands related to devices installed in or coupled to computing device 120. Through such a device manager interface, the user may select a display area 160 relating to managing wireless devices in a group involving computing device 120.

In the embodiment illustrated, each of the devices actively in the group 110A is illustrated in display area 160 by an icon. In this example, icon 162 represents remote device 132. Icon 164 represents remote device 134. Icon 166 represents remote device 136. Icon 170 represents remote device 140. Additionally, display area 160 contains an icon 168.

Icon 168 is shown in a fashion that is visually distinct from the icons 162, 164, 166 and 170. The different visual presentation of icon 168 may represent that a device corresponding to icon 168 is not actively connected in the group 110A at the time display area 160 was rendered. In this example, icon 168 is shown grayed-out and appears in phantom. Though, any suitable representation of a device that is not actively connected in the group may be used. In this example, a grayed-out icon represents a device that has been given the master key for group 110A and could re-join group 110A at a later time.

FIG. 1C illustrates that, through user interface 150, a user may enter a command that may place a device in a disconnected state. For example, a user, through manipulation of a mouse or other human interface device, may select an icon. In response to such a selection, computing device 120 may present a menu, allowing a user to input a command controlling the connection of the selected device. In the state illustrated in FIG. 1C, a user has selected icon 170 corresponding to remote device 140. In response, computing device 120 has presented menu 180. Menu 180 contains, in this example, options for selecting one of multiple commands. In this example, an option to select between two commands, commands 182 and 184, is shown.

Command 182 corresponds to a disconnect command. Upon user selection of disconnect command 182, computing device 120 may take action that precludes remote device 140 from communicating as part of group 110A. That action, for example, may include invalidating a transient key used by remote device 140 to encrypt or decrypt information exchanged with computing device 120. Invalidation of this transient key, though it temporarily precludes remote device 140 from participating in group 110A, does not preclude remote device 140 from re-joining the group. Specifically, the remote device may use the master key it has previously obtained to re-join the group and receive a new transient key to replace the transient key invalidated in response to user selection of disconnect command 182.

To preclude remote device 140 from re-joining group 110A, a user may select from menu 180 command 184. Command 184 is a remove command. Upon selection of remove command 184, computing device 120 may instead of or in addition to invalidating the transient key generated for remote device 140, invalidate the master key used by remote device 140.

In conventional systems in which all remote devices joined in a group are provided with the same master key, invalidating the master key for remote device 140 would invalidate the master key for all remote devices in group 110A. Accordingly, removing a device would require re-establishing a group 110B (FIG. 1B) for the remote devices that the user desires to remain joined in the group. Re-forming the group entails executing a key generation and distribution protocol, such as the WPS protocol, for each of the devices. The WPA2 protocol, or other protocol used for the peer-to-peer group, would also have to be repeated. Because the WPS protocol requires user interaction, forming a new group 110B may be undesirable.

To avoid requiring a user to form a new group as a way to exclude a removed device from re-joining the group, in some embodiments, computing device 120 may be configured to provide a unique master key for each remote device that joins group 110A. Unique master keys may be generated for each device by repeating the key generation protocol for each device. Thereafter, when a remote device seeks to authenticate to the computing device 120, the computing device 120 may access the appropriate master key for the device. That unique master key could then be used to authenticate the device and generate a transient key for the device. Thereafter, communication between computing device 120 and the remote device could be performed as in a conventional peer-to-peer protocol until an event is encountered that triggers computing device 120 to remove a remote device from the group. Such a triggering event, for example, may be a user selecting command 184 (FIG. 1C).

Regardless of an event triggering removal of a device from a group, in response to such an event, computing device 120 could invalidate the master key assigned to the device to be removed. Invalidating a master key for a remote device precludes that remote device from re-joining a group. However, because all of the other remote devices that are joined in group 110A may have unique master keys, invalidating the master key for remote device 140 does not impact the validity of the master keys assigned to other devices, such as remote device 132, 134 and 136. Accordingly, those remote devices are not impacted by the removal of remote device 140.

Computing device 120 may be configured in any suitable way to provide unique master keys for each remote device that joins in a group according to a peer-to-peer protocol. FIG. 2 is an example of an architecture for a computing device 210, which may represent an embodiment of a computing device, such as computing device 120, that may act as a controller for a peer-to-peer group.

FIG. 2 illustrates, at a high level, an architecture for computing device 210 that may be operated to transmit and/or receive information as part of exchanges with remote devices joined in a peer-to-peer group. In the example of FIG. 2, computing device 210 includes a radio 250. Radio 250 may be adapted to send and receive wireless communications. Radio 250, for example, may be used for wireless communication in a frequency spectrum that is above 2 GHz and below 6 GHz. Such frequencies are appropriate for communication in accordance with a Wi-Fi Direct protocol. Though, it should be appreciated that any suitable spectrum and any suitable protocol may be used.

In the example of FIG. 2, an application 220 is illustrated. Application 220 may generate information for wireless transmission or may process information received wirelessly. In the embodiment illustrated, that information may be sent to or received from one or more remote devices joined in a peer-to-peer group. Accordingly, application 220 may represent any suitable application that generates or processes information exchanged in a peer-to-peer group. It may, for example, be an application for processing photographs or a word processing application that generates text for printing. Though, in some instances, application 220 may perform any suitable actions, including actions that connect or disconnect from devices in a peer-to-peer group. As an example, in some embodiments, action described as being done by a user may done indirectly by the user by initiating execution of application 220.

In the example of FIG. 2, application 220 interfaces with operating system 230. In some embodiments, operating system 230 may be a general purpose operating system, such as the WINDOWS® operating system. Such a configuration may be desirable when computing device 210 executes applications other than application 220. Though, in embodiments in which computing device 210 is configured specifically for communication as part of a peer-to-peer group, operating system 230 may have more limited functionality.

Regardless of whether operating system 230 is a special purpose or general purpose operating system, in the embodiment illustrated, a function of operating system 230 is to provide services that facilitate wireless transmission and reception of information processed by application 220. For transmission, operating system 230 may receive a request from application 220 to establish a connection with a nearby device. Thereafter, operating system 230 may receive from application 220 a stream of data representing audio/video content to be transmitted over that connection. Such a connection may be formed using techniques as are known in the art. In the illustrated example, that connection may be a direct, device-to-device connection. Though any suitable technique may be used.

In the embodiment illustrated, operating system 230 includes a network stack 262. Network stack 262 may perform functions as are known in the art for wireless communication, including successively formatting data from application 220 in accordance with different protocol layers used as part of the wireless communication. Network stack 262 may perform a reverse operation on received information by successively checking compliance with various protocol layers and removing header and other information added in accordance with those protocol layers to recover data intended for use by application 220. Such processing may be performed using techniques as are known in the art.

To send and receive data, stack 262 may interact with one or more radios, of which radio 250 is illustrated. Radio 250 may be controlled through software, represented as driver 240 in FIG. 2. Here, driver 240 includes an interface 242 through which operating system 230 may issue commands to driver 240 and through which driver 240 may report status and notify operating system 230 of received data. Interface 242 may be implemented in any suitable way, including according to a known standard. An example of such a known standard is called NDIS, but that standard is not critical to the invention.

Interface 242 may support a number of commands in a format that does not depend on the construction of radio 250. These commands may include commands to configure radio 250 for transmission at certain frequencies or to use certain modulation schemes or error control coding for symbols to be transmitted. Additionally, through interface 242, driver 240 may receive data for transmission by radio 250.

Regardless of the specific commands, driver 240 may translate the commands, in the standardized format of interface 242, into specific control signals that are applied to radio 250. Additionally, driver 240 may be programmed to perform certain low level functions associated with a wireless connection. For example, upon receipt of a packet, driver 240 may check that the packet is properly formatted. If the packet is properly formatted, driver 240 may control radio 250 to generate an acknowledgement. Conversely, if the packet is not properly formatted, driver 240 may control radio 250 to transmit a negative acknowledgement.

Though driver 240, and in some instances radio 250, may automatically perform low level functions associated with establishing and maintaining a wireless connection, higher level functions may be performed under control of operating system 230 or applications 220. In some embodiments, an application 220 or operating system 230 may provide a user interface such that ultimate control of wireless communication is provided by a user of computing device 210.

The architecture illustrated in FIG. 2 may be modified in any suitable way to configure computing device 210 to issue, use and selectively invalidate a unique master key for each device joining a peer-to-peer group. For example, components to control such operation of computing device 210 may be incorporated within application 220, operating system 230 or within driver 240. In some embodiments, some or all of the functions of a controller may be implemented in radio 250. Accordingly, the specific components configured for implementation of the controller functions are not critical to the invention.

FIG. 3 illustrates a controller 310 that may be incorporated into any suitable portion of the architecture of computing device 210. Controller 310, for example, may be incorporated into operating system 230. As a specific example, controller 310 may be incorporated into network stack 262. Though, it should be appreciated that it is not a requirement that all of the components of controller 310 be implemented in a single portion of the architecture of computing device 210. The components of controller 310, for example, may be distributed across multiple components.

In the example illustrated, controller 310 includes interfaces 312, 314 and 316, which are configured for connecting to portions of stack 262 where frames representing wireless communication in accordance with a peer-to-peer protocol may be diverted to controller 310 and where such frames may be passed to stack 262 for wireless transmission. In the embodiment illustrated, each of the interfaces 312, 314 and 316 may be integrated into stack 262 such that frames in accordance with the peer-to-peer protocol implemented by computing device 210 may pass between controller 310 and stack 262. Though three interfaces are illustrated, it should be appreciated that any number of interfaces may be provided. For example, a single interface may be provided or more than three interfaces may be provided to accommodate different types of interactions between controller 310 and stack 262. Moreover, it should be appreciated the form of these interfaces is not critical to the invention and the specific form of the interfaces may depend on the implementation of controller 310. For example, the interfaces may be implemented as defined application programming interfaces (APIs) and controller 310 may be implemented in way that it makes calls on the interfaces. Though, it other embodiments, interfaces 312, 314 and 316 may be any other form of connection.

FIG. 3 illustrates that controller 310 may be implemented with multiple components. FIG. 3 may represent a software architecture for controller 310, with each of the designated components being implemented as a separate module, such as a dynamically linked library. Though, the specific structure of each component is not critical to the invention and any suitable structure may be used in implementing the functionality of controller 310.

In the illustrated embodiment of FIG. 3, controller 310 includes a key setup component 320. Key setup component 320 may control interactions with a remote device during a setup phase for the device in which controller 310 and the remote device each arrive at the same unique master key for the remote device.

Setup component 320 may interact with the remote device in any suitable way. As one example, setup component 320 may interact via interface 312 and stack 262 such that frames that constitute exchanges of messages between computing device 210 and a remote device, may pass to setup component 320 for processing or may be generated by setup component 320 for transmission to the remote device. The specific message that pass through interface 312 for processing by setup component 320 may depend on the protocol used for the peer-to-peer group being formed. As one example, these messages may be formatted as management frames defined by the peer-to-peer protocol. One or more of these frames may include information elements indicating a request or a response to a request that is not expressly provided for in the protocol.

For example, an initial message may indicate a request from a remote device to obtain a master key for use in joining or communicating within the group. Other messages may include responses by which such a key is generated.

In response to such message, key setup component 320 may determine whether the remote device is authorized to receive a master key. Key setup component 320 may determine if a remote device is authorized in part based on an exchange of messages with the remote device. Key setup component 320 may access additional authentication information to determine whether the remote device is authorized to receive a master key.

Those additional sources of authentication information may include interaction with a user. Such interactions may be performed through user interface component 350 or in any other suitable way. In some embodiments, for example, key setup component 320 may, through user interface 350, prompt a user to provide a PIN or other suitable identification code associated with an authorized remote device. Key setup component 320 may use this identification code to verify whether messages received from the remote device were generated using the same identification code. Though, it should be appreciated that the specific source of the authentication information is not critical to the invention and it need not be provided directly by a user through a user interface. As an example of an alternative source of such authenticating information, computing device 210 may maintain a store (not shown) of PIN numbers for authorized devices, which key setup component 320 may access when receiving a request for a master key from a device seeking to join a peer-to-peer group.

The specific messages processed by key setup component 320 are not critical to the invention. In some embodiments, key setup component 320 may be configured to implement the Wi-Fi Protected Setup protocol (WPS) when receiving a request for a master key and communicating the master key to the remote device, if the remote device is authorized to receive the master key.

To obtain a master key, when the remote device is authorized to receive one, key setup component 320 may interact with key generator 322. Key generator 322 may utilize cryptographic techniques to generate a key in response to a request from key setup component 320. Key generator 322 may operate according to known cryptographic principles and may be implemented using techniques as are known in the art. However, in contrast to a conventional wireless computing device implementing a peer-to-peer group, key generator 322 and key setup component 320 may interact such that a unique master key is generated for each remote device requesting to join the group.

Key setup component 320 may record the unique master keys for subsequent use in authenticating the remote devices. In the example of FIG. 3, key setup component 320 records master keys in key store 340. Key store 340 may represent any suitable computer storage medium on or accessible to computing device 210. Key store 340 may be implemented in non-volatile storage medium, such as a disk drive, and, for example, may be formatted as a file or other data structure maintained by a file management system on computing device 210. Though, in other embodiments, key store 340 may be stored in an encrypted format and may have no readily recognizable structure in the non-volatile storage medium. Accordingly, it should be appreciated that the specific implementation of key store 340 is not critical to the invention.

Other components within controller 310 may perform other functions associated with interactions with one or more remote devices in connection with a peer-to-peer group, including use and selective invalidation of the master keys in key store 340. For example, FIG. 3 shows that controller 310 may also include an authentication and transient key component 330. Authentication and transient key component 330 may interact with a remote device seeking to connect with other devices in the peer-to-peer group. Authentication and transient key component may validate that the remote device seeking to connect as a member of the group possesses a valid master key for the group.

Accordingly, authentication and transient key component 330 may interact with key store 340 to verify that the remote device has access to a valid master key for the group. Upon authenticating a remote device, authentication and transient key component may generate one or more transient keys for use in encrypting and/or decrypting communications with the remote device. As part of generating the transient key. Authentication and transient key component 330 may interact with the remote device. Accordingly, authentication and transient key component 330 is shown having an interface 314, which may connect to stack 262 (FIG. 2) or other suitable component that allows authentication and transient key component 330 to exchange messages with the remote device.

The exchanged messages allow the remote device to generate transient key or keys that match the keys generated by authentication and transient key component 330. In this way, authentication and transient key component 330 may provide a transient key or keys to the remote device.

Authentication and transient key component 330 may interact with the remote device using messages appropriate for the peer to peer protocol used in forming the group. In some embodiments, authentication and transient key component 330 may implement a four way hand shake in accordance with the WPA2 protocol and may therefore be implemented using techniques as are known in the art. However, in contrast to a conventional computing device serving as a controller for a peer-to-peer group, authentication and transient key component 330 may access key store 340 to obtain the unique device key for the remote device attempting to connect to the peer-to-peer group.

Authentication and transient key component 330 may retrieve the unique master key applicable to the remote device in any suitable way. For example, FIG. 4A illustrates a possible organization of data maintained in key store 340, which may allow authentication in transient key component 330 to obtain the appropriate unique master key for the remote device. In the example of FIG. 4A, a data set 410 represents information in key store 340 for the set of remote devices for which unique master keys have been generated. In this example, each remote device is represented by a record in data set 410. In FIG. 4A four record, 412A, 412B, 412C and 412D are illustrated, each of the records 412A . . . 412D corresponds to a remote device.

In this example, each of the records has the same format. Taking record 412A as illustrated, the record contains multiple fields. In this example, three fields, fields 420, 422 and 424 are shown. Field 422 stores a value indicating the master key for a remote device associated with record 412A. Field 420 contains a value that may be used to identify the remote device. In this example, Field 420 stores a value representing a Media Access Control (MAC) address for the remote device. In accordance with some peer-to-peer protocols, the MAC address of a device sending or intended to receive a frame is incorporated into the frame. Accordingly, key setup component 320 may have access to the MAC address of a remote device at the time it generates a unique master key for the device. When key setup component 320 generates a unique master key and writes a record to key store 340, it may include in that record a value of the MAC address for the remote device. Authentication and transient key component 330 may similarly receive a MAC address for a remote device in conjunction with messages from a remote device seeking to be authenticated as part of connecting in the peer-to-peer group. Accordingly, authentication and transient key component 330 may identify an appropriate master key for a remote device by comparing a MAC address received from the remote device with a MAC address stored in data set 410.

Though, other mechanisms are possible. For example, FIG. 4B illustrates an alternative embodiment of a data set 450 that may constitute key store 340. Data set 450, in this example, contains a structure similar to that of data set 410. Multiple records 452A, 452B, 452C and 452D are illustrated. Each such record may correspond with a remote device for which a master key has been generated. Taking record 452 as illustrated, each record may include fields such as fields 460, 462 and 464. Field 460 may contain a value of the master key. In this example, fields 462 and 464 do not contain identification information comparable to that in field 420 (FIG. 4A). Rather, fields 462 and 464 contain information that may be used in other operations. For example, field 462 may contain a value defining a time at which the master key was generated. Such information, for example, may be used in an embodiment in which keys time out or devices otherwise are removed from a group after some threshold period of time. Field 464 may contain information useful, for example, in rendering a user interface such as user interface 150. Field 464, for example, may contain a code or other description of the device for which the master key was generated. Such information may be used by user interface component 350 to select icons to use in interface 150.

In this example, data set 450 does not include MAC addresses or other direct identification of the remote devices. Nonetheless, authentication and transient key component 330 may use data set 450 to determine whether the remote device requesting authentication has a valid master key.

As part of the protocol applied by authentication and transient key component 330 to determine whether a remote device as a valid key, authentication and transient key component 330 performs a cryptographic function on a block of data sent by the remote device. In accordance with the protocol used by authentication and transient key component 330, the remote device is expected to encrypt with a valid master key a block of data having a value known by authentication and transient key component 330. Authentication and transient key component 330 authenticates the remote device if it can decrypt a block of data received from the remote device to generate that known value. Accordingly, even if authentication and transient key component 330 does not know the specific master key used by the remote device, if any of the master keys in data set 450 can be used to decrypt the received block of data in order to generate the expected value, authentication and transient key component 330 may conclude that the remote device has access to a valid master key, thereby authenticating the remote device.

Accordingly, in embodiments in which a specific identifier for the remote device is not stored in data set 450, authentication and transient key component 330 may identify the appropriate master key by testing multiple master keys in the data set until a master key can be used to appropriate decrypt the block of data is identified. That master key can thereafter be used in the generation of a transient key for the remote device.

Regardless of the manner in which authentication and transient key component 330 identifies the appropriate master key for the device requesting connection to the peer-to-peer group, once the appropriate master key is identified, authentication and transient key component 330 may use the master key to provide a transient key to the remote device for connection to the peer-to-peer group.

FIG. 3 illustrates that controller 310 includes a group owner control component 360. Group owner control component 360 may perform operations as are known in the art for a computing device operating as a controller for a peer-to-peer group. In the embodiment illustrated, device 210 may be programmed to operate in accordance with the Wi-Fi Direct protocol. In that protocol, devices forming a group may exchange messages by which one of the devices is identified as a group owner. The group owner performs control functions for the group, including provisioning devices that form part of the group such that the devices may appropriately send and receive data. In the embodiment illustrated, the group owner also participates in routing the data between devices that are admitted to the group. These operations, and any other suitable operations, may be performed by group owner control component 360.

Operations performed by group owner control component 360 may entail sending and receiving data from one or more of the remote devices that are connected in the peer-to-peer group. Such data may be communicated in an encrypted format. Accordingly, group owner control component 360 may be coupled to interface 316 through encryption/decryption component 362. Interface 316 may couple encryption/decryption component 362 to stack 262 (FIG. 2) or other component of computing device 210 that facilitates the transmission and receipt of information exchanges wireless with the remote device.

Group owner control component 360 and encryption/decryption component 362 may be implemented in any suitable way, including using components as are known in the art. These components may operate such that data frames or other frames exchanged with a remote device that is connected in the peer-to-peer group may be encrypted with the transient key generated for that remote device. Encryption/decryption component 362 may access such a transient key in any a suitable way. For example, authentication and transient key component 330 may generate a key table or other suitable data structure linking transient keys with addresses used by remote devices to communicate as part of the peer-to-peer group.

As one example, FIG. 4A illustrates that each of the records 412A, 412B, 412C and 412D in data set 410 may include a field, such as field 424 containing a transient key for the remote device represented by the record. In this example, a MAC address in field 420 may be used to selected an appropriate record from data set 410 such that a transient key may be identified for use in encrypting or decrypting data. Though, it is not a requirement that the transient keys be stored in the same data store as the master keys. In some embodiments, the transient keys may be stored in volatile memory, for example, such that the transient keys are not retained if computing device 210 powers down. Also, it is not a requirement that the transient keys be linked to a MAC address. In some embodiments, the transient keys may be linked to a group address assigned to each remote device as it is admitted to the peer-to-peer group.

Regardless of the manner in which the transient key is identified, encryption/decryption component 362 may use the transient key to encrypt and decrypt frames exchanged between group owner control component 360 and the remote device. These operations may be performed using techniques as are known in the art or in any other suitable way.

FIG. 3 also illustrates that controller 310 may include a user interface component 350. User interface component 350 may present one or more user interfaces through which information may be obtained from a user. For example, user interface component 350 may present user interface 150 (FIG. 1C) to receive user input concerning disconnecting or removing a remote device from a peer-to-peer group. Additionally, user interface component 350 may interface with a user to obtain information or commands used by key setup component 320 or other components of controller 310.

User interface component 350 may be implemented using techniques as are known in the art or in any other suitable way. User interface component 350 may be configured to respond to user input in any suitable way. For example, in response to user input received through user interface 150 indicating that a remote device is to be removed from a peer-to-peer group, user interface component 350 may modify key store 340 to invalidate a master key associated with the device to be removed. User interface component 350 may invalidate a master key in any suitable way. In some embodiments, user interface component 350 may invalidate a key either by deleting from a record associated with the device a value of the master key or deleting the entire record. Though, any suitable mechanism signifying that a master key has been invalidated may be used. For example, user interface component 350 may write a value to the record associated with the master key to indicate that the key has been invalidated.

In contrast, in response to user information received through user interface 150 to disconnect a remote device from a peer-to-peer group, user interface 350 may leave the master key value in key store 340 intact. Rather, user interface component may delete transient keys or other data structures used to establish the connection with the remote device to be disconnected. But, leaving the master key in key store 340 allows the disconnected remote device to reconnect at a later time.

The components illustrated in FIG. 3, or any other suitable components, may interact to control computing device 210 to perform a method of secure operation in which remote devices may be selectively removed from the group. FIGS. 5A and 5B, when joined at the point labeled A, represent a flow chart of such a method of secure operation.

In the example of FIG. 5A, method 500 begins at block 510 where a remote device is discovered. Remote discovery of a device may be performed in any suitable way and may be initiated by either the computing device executing method 500 or the remote device. Processing at block 510 may be performed in any suitable way. In the embodiment illustrated, that processing may be performed using techniques specified as part of a peer-to-peer protocol as is known in the art.

For example, processing at block 510 may include sending and/or responding to management frames. As an example, discovery at block 510 may include transmitting a beacon and/or receiving a probe request. Accordingly, the specific actions taken by which a computing device identifies that a remote device desires to engage in peer-to-peer communication is not critical to the invention. Regardless of the manner in which the device is identified, processing may proceed to decision block 520.

At decision block 520, process 500 may branch, depending on whether the remote device identified at block 510 is known to the computing device executing process 500. In this example, a device is deemed known when it is a device that has previously been admitted as a member of a peer-to-peer group controlled by the computing device executing process 500. If so, process 500 branches from decision block 520 to perform subprocess 550 (FIG. 5B).

In scenarios in which the discovered device is not known, the process 500 precedes from decision block 520 to subprocess 522. At subprocess 522, the computing device executing process 500 and the remote device may exchange further management frames to negotiate a group owner. The negotiations performed as part of subprocess 522 may be specified in the peer-to-peer protocol being used by the devices to form a peer-to-peer group. Accordingly, subprocess 522 may be performed as known in the art. In this example, the negotiations are performed in accordance with the Wi-Fi Direct protocol such that, as a result of the negotiations, one of the devices will be identified as the group owner, and will perform control functions for the peer-to-peer group.

Upon completion of the negotiations in subprocess 522, the process continue to decision block 522. At decision block 522, process 500 may branch depending on the result of the group owner negotiations conducted in 522.

If the computing device executing process 500 is not selected as the group owner, process 500 may branch from decision block 524 to subprocess 530. In scenarios in which the device executing process 500 is not identified as the group owner, no special action on the part of the device is necessary in order to receive a unique master key. Accordingly, when the process branches from decision block 524 to subprocess 530, operations within subprocess 530 may be conventional operations as are appropriate for a computing device designated to have the role of a client device in the peer-to-peer network.

Processing within subprocess 530 may result in the client authenticating and associating with the device selected as the group owner as a result of the negotiations conducted in subprocess 522. Additionally, subprocess 530 may include provisioning steps, as in a conventional peer-to-peer network. Regardless of the specific steps taken, upon execution of subprocess 530, the computing device may be equipped for communication with the selected group owner. Accordingly, from subprocess 530, the process 500 may proceed to subprocess 532 where the computing device executing process 500 and the remote device discovered at block 510 may communicate using techniques as are known in the art. Such communication may continue for any amount of time, but when communication is completed, process 500 may end.

Conversely, when, as a result of negotiations in subprocess 522, the computing device executing process 500 is identified as the group owner, the process branches from decision block 524 to decision block 540. Processing at decision block 540 may determine, in any suitable way, whether the device discovered at block 510 is authorized to join the group being controlled by the device executing process 500. As an example, user input may be provided indicating whether the device is authorized.

The input may be in a form that allows cryptographic functions used in communications with the remote device that can indicate whether the device is authorized. For example, the controlling device executing process 500 may send a message containing text or a numeric code that operates as a challenge phrase. The remote device may encrypt that challenge phrase with the PIN or other valued derived from authentication information to perform a cryptographic function on the challenge phrase. The cryptographic function, may involve encryption, digital signing, a hash function or other suitable cryptographic function.

Regardless of the specific cryptographic function performed, the remote device may then send back to the controlling device the challenge phrase suitably processed. The controlling device may perform a similar operation on the challenge phrase based on the authentication information provided by the user. If the processed value generated by the controlling device matches the value returned by the remote device, the controlling device may deem that the remote device is authorized to connect to the peer-to-peer group. Though, it should be appreciated that such an exchange of messages based on authentication information provided by a user is just one example of an approach that the controlling device may use to determine whether the remote device is authorized to join the group. Regardless of the manner in which the authorization is validated, if the remote device is not authorized for access to the group, the process may branch from decision block 540 to the end of the process such that the remote device is not granted access to the peer-to-peer group.

Conversely, if, as a result of processing at decision block 540, the controlling device determines that the remote device is authorized to join the peer-to-peer group, the process branches from decision block 540 to block 542. At block 542, the controlling device may generate and store a unique master key for the remote device. The master key may be generated in any suitable way, such as through the use of a random number generator and/or computations involving one or more cryptographic functions.

Regardless of the manner in which the master key is generated, process 500 may proceed to subprocess 544. At subprocess 544, the master key may be distributed to the remote device. Subprocess 544 may be performed in any suitable way. In some embodiments, the controlling device may convey the master key to the remote device using the Wi-Fi protected setup protocol (WPS).

Regardless of the manner in which the key is distributed, process 500 may proceed to subprocess 550 (FIG. 5B). Subprocess 550 may entail authenticating a device seeking to join the peer-to-peer group. FIG. 5B illustrates that the processing performed within subprocess 550 is the same, regardless of whether process 500 reaches subprocess 550 from subprocess 544, in which the remote device receives a unique master key, or from decision block 520 where it may be determined that the remote device already has a master key. Accordingly, subprocess 550 is shown beginning at block 552 where the controlling device checks whether the remote device has a valid master key. In embodiments in which the remote device has just been assigned a master key through subprocess 544, this processing may be bypassed.

In embodiments in which processing is performed at block 552, the controlling device may check whether the remote device seeking to join the peer-to-peer group has a valid master key through an exchange of messages. The exchange of messages, for example, may entail exchanging information between the controlling device and the remote device that allows the controlling device to determine whether the remote device has performed a cryptographic function using a valid master key. Such an exchange of communications may be performed according to any suitable protocol. In some embodiments, subprocess 550 may be performed according to a known protocol, such as the WPA2 protocol. In such an embodiment, processing performed at block 552 may be in accordance with that protocol, though the specific protocol used is not critical to the invention.

However, a difference between the processing at block 552 and a conventional process for checking the validity of a master key of a remote device is that, at block 552, the controlling device may select an appropriate master key that corresponds with the remote device. The master key used by the controlling device at block 552 may be selected in any suitable way. In some embodiments, the controlling device may access a key store, such as key store 340 (FIG. 3) based on an identifier associated with the remote device. Though, in other embodiments, the controlling device may sequentially attempt to validate the master key used by the remote device against each valid master key stored in a key store until the master key applied by the remote device validates against a key in the key store, in which case the key is validated, or the controlling device unsuccessfully attempts to validate the master key used by the remote device against all of the master keys in the key store, in which case the remote device is determined not to have a valid master key.

Regardless of the technique used to validate the master key at block 552, process 500 may continue to decision block 554 where there process may branch depending on the result of that validation. If, as a result of processing at block 552, the controlling device determines that remote device does not have a valid master key, the process may branch from decision block 544 to the end of process 500 without the remote device being able to connect to the peer-to-peer group.

Conversely, if the remote device is determined to have a valid master key, the process may continue from decision block 554 to block 556. At block 556, the controlling device may generate one or more transient keys that may be distributed to the remote device. A transient key generated at block 556 may enable communication between the remote device and the controlling device. If multiple transient keys are generated, for example, one transient key may be used with the controlling device and the additional keys may be used for communication with other devices in the peer-to-peer group.

The transient keys may be generated in any suitable way. In an embodiment in which subprocess 550 is performed in accordance with the WPA2 protocol, processing at block 556 may be performed in accordance with that protocol. Though, any suitable mechanism may be used to generate transient keys and distribute those transient keys to the remote device.

Regardless of the number of transient keys generated at block 556 they may be stored at block 558 for future use in encrypting or decrypting communications with the remote device.

Process 500 may then continue to subprocess 560. During subprocess 560, the controlling device and the remote device may communicate using the transient keys generated at block 556. Subprocess 560 may include any suitable steps. In the example illustrated, processing within subprocess 560 begins with block 562. At block 562, the controlling device may encrypt data for transmission to the remote device using a transient key generated at block 556. The specific data to be transmitted to the remote device is not critical to the invention and may depend on the nature of both the remote device and the controlling device. Moreover, the manner in which the transient key is used to encrypt data at block 562 also is not critical to the invention. Encryption may provide confidentiality, authentication or integrity or some combination of those functions.

Regardless of how and why data is encrypted with the transient key, at block 564, the encrypted data may be transmitted to the remote device at block 564. Transmission of encrypted data at block 564 may be performed in any suitable way. Though, embodiments in which the peer-to-peer group is formed in accordance with a standard protocol, transmission at block 564 may be in accordance with the standard protocol. In the embodiment illustrated, the communication subprocess 560 may also include receiving data from the remote device. In this scenario, the received data may also be encrypted using the transient keys generated and transmitted to the remote device at block 556. Accordingly, data received at block 566 may be encrypted with the transient key for the remote device.

At block 568, the controlling device may decrypt the received data, also using the transient key. The received data may then be used within the controlling device. The specific use of the data is not critical to the invention and the data may be put to any suitable use.

Process 500 may then continue to decision block 570. At decision block 570, the process may branch, depending on whether a trigger event has been detected that indicates that the remote device should be removed from the peer-to-peer group. An example of a trigger advice may be user input. As a specific example, a user may select command 184 (FIG. 1C) from a user interface on the controlling device. Though, any other suitable event may serve as a trigger. For example, FIG. 4B illustrates that records in a data set 450 containing information about remote devices may include a time value, such as the time value illustrated in field 462. In some embodiments, a suitable trigger for removing a remote device from a peer-to-peer group may be passage of a predetermined amount of time. That time may be determined, for example, from a value in field 462.

Regardless of the specific trigger event, if the trigger event is detected, process 500 branches from decision block 570 to block 572. At block 572, the controlling device may invalidate the master key associated with the remote device. Processing at block 572 may be performed in any suitable way. In some embodiments, a master key may be invalidated by deleting it from a key store, such as key store 340. Though, in other embodiments, the key may be invalidated by setting a flag in a record associated with the key or in any other suitable way.

Following invalidation of the master key at block 572, process 500 may continue to block 582 where transient keys associated with the remote device may also be invalidated, such as by deletion. Following deletion of the transient keys, process 500 may end. When processing arrives at the end after having passed through blocks 572 and 582, the remote device will be unable to further communicate as in subprocess 560 because it will not have transient keys to encrypt and decrypt data. Further, the remote device will be unable to re-establish communication by repeating subprocess 550 to establish transient keys that can be used for communication. If the remote device seeks to re-establish communication, it will be forced to pass through decision block 540 where it must be reauthorized to obtain a new master key.

Though, FIGS. 5A and 5B illustrate other sequences of steps through which processing may arrive at the end of process 500. For example, if at decision block 570, no indication to remove the remote device is received, processing may proceed to decision block 580. At decision block 580, process 500 may branch, depending on whether communications have been completed. If not, processing may loop back where some or all of subprocess 560 may be repeated.

Conversely, if communications are completed, the process may branch from decision block 580 to block 582. At block 582, transient keys assigned to the remote device may be deleted, and then process 500 may end. In scenarios in which processing reaches the end without execution of block 572, the remote device may retain a valid master key. Though the remote device may lack transient keys because they were deleted at block 582, the remote device may nonetheless resume communication as part of the peer-to-peer group without further express user authorization. For example, if at a later time, the remote device attempts to re-establish communication, processing may branch through decision block 520 directly to subprocess 550 where, because the remote device retains a valid master key, the remote device may receive new transient keys. In this way, process 500 illustrates an approach by which a master key for a remote device that is part of a peer-to-peer group may be selectively removed.

Though FIGS. 5A and 5B depict interactions between a controlling device and a single remote device, it should be appreciated that process 500 may be repeated for each of multiple remote devices forming a peer-to-peer group. Processing for each of the remote devices may be independent. Accordingly, selective invalidation of a master key for one remote device does not impact the validity of the master keys held by other remote devices. Accordingly, a remote device may be selectively removed in accordance with the process of FIGS. 5A and 5B. Though, it should be appreciated that FIGS. 5A and 5B illustrate an exemplary process and any suitable processing may be used to selectively remove one or more remote devices from a peer-to-peer group.

FIG. 6 illustrates an example of a suitable computing system environment 600 on which the invention may be implemented. The computing system environment 600 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 600 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 600.

The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

The computing environment may execute computer-executable instructions, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

With reference to FIG. 6, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 610. Components of computer 610 may include, but are not limited to, a processing unit 620, a system memory 630, and a system bus 621 that couples various system components including the system memory to the processing unit 620. The system bus 621 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

Computer 610 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 610 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 610. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.

The system memory 630 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 631 and random access memory (RAM) 632. A basic input/output system 633 (BIOS), containing the basic routines that help to transfer information between elements within computer 610, such as during start-up, is typically stored in ROM 631. RAM 632 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 620. By way of example, and not limitation, FIG. 6 illustrates operating system 634, application programs 635, other program modules 636, and program data 637.

The computer 610 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 6 illustrates a hard disk drive 640 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 651 that reads from or writes to a removable, nonvolatile magnetic disk 652, and an optical disk drive 655 that reads from or writes to a removable, nonvolatile optical disk 656 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 641 is typically connected to the system bus 621 through an non-removable memory interface such as interface 640, and magnetic disk drive 651 and optical disk drive 655 are typically connected to the system bus 621 by a removable memory interface, such as interface 650.

The drives and their associated computer storage media discussed above and illustrated in FIG. 6, provide storage of computer readable instructions, data structures, program modules and other data for the computer 610. In FIG. 6, for example, hard disk drive 641 is illustrated as storing operating system 644, application programs 645, other program modules 646, and program data 647. Note that these components can either be the same as or different from operating system 634, application programs 635, other program modules 636, and program data 637. Operating system 644, application programs 645, other program modules 646, and program data 647 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 610 through input devices such as a keyboard 662 and pointing device 661, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 620 through a user input interface 660 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 691 or other type of display device is also connected to the system bus 621 via an interface, such as a video interface 690. In addition to the monitor, computers may also include other peripheral output devices such as speakers 697 and printer 696, which may be connected through a output peripheral interface 695.

The computer 610 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 680. The remote computer 680 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 610, although only a memory storage device 681 has been illustrated in FIG. 6. The logical connections depicted in FIG. 6 include a local area network (LAN) 671 and a wide area network (WAN) 673, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 610 is connected to the LAN 671 through a network interface or adapter 670. When used in a WAN networking environment, the computer 610 typically includes a modem 672 or other means for establishing communications over the WAN 673, such as the Internet. The modem 672, which may be internal or external, may be connected to the system bus 621 via the user input interface 660, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 610, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 6 illustrates remote application programs 685 as residing on memory device 681. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated that various alterations, modifications, and improvements will readily occur to those skilled in the art.

Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.

The above-described embodiments of the present invention can be implemented in any of numerous ways. For example, the embodiments may be implemented using hardware, software or a combination thereof. When implemented in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers. Such processors may be implemented as integrated circuits, with one or more processors in an integrated circuit component. Though, a processor may be implemented using circuitry in any suitable format.

Further, it should be appreciated that a computer may be embodied in any of a number of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, or a tablet computer. Additionally, a computer may be embedded in a device not generally regarded as a computer but with suitable processing capabilities, including a Personal Digital Assistant (PDA), a smart phone or any other suitable portable or fixed electronic device.

Also, a computer may have one or more input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer may receive input information through speech recognition or in other audible format.

Such computers may be interconnected by one or more networks in any suitable form, including as a local area network or a wide area network, such as an enterprise network or the Internet. Such networks may be based on any suitable technology and may operate according to any suitable protocol and may include wireless networks, wired networks or fiber optic networks.

Also, the various methods or processes outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and/or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.

In this respect, the invention may be embodied as a computer readable storage medium (or multiple computer readable media) (e.g., a computer memory, one or more floppy discs, compact discs (CD), optical discs, digital video disks (DVD), magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other non-transitory, tangible computer storage medium) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above. The computer readable storage medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above. As used herein, the term “non-transitory computer-readable storage medium” encompasses only a computer-readable medium that can be considered to be a manufacture (i.e., article of manufacture) or a machine. Alternatively or additionally, the invention may be embodied as a computer readable medium other than a computer-readable storage medium, such as a propagating signal.

The terms “program” or “software” are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of the present invention as discussed above. Additionally, it should be appreciated that according to one aspect of this embodiment, one or more computer programs that when executed perform methods of the present invention need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present invention.

Computer-executable instructions may be in many forms, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments.

Also, data structures may be stored in computer-readable media in any suitable form. For simplicity of illustration, data structures may be shown to have fields that are related through location in the data structure. Such relationships may likewise be achieved by assigning storage for the fields with locations in a computer-readable medium that conveys relationship between the fields. However, any suitable mechanism may be used to establish a relationship between information in fields of a data structure, including through the use of pointers, tags or other mechanisms that establish relationship between data elements.

Various aspects of the present invention may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.

Also, the invention may be embodied as a method, of which an example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

Use of ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having,” “containing,” “involving,” and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

Claims

1. A method of managing wireless communications, the method comprising: operating a wireless user device as a member of a peer-to-peer group, including, at the wireless user device: identifying a first remote device that is attempting to join the peer-to-peer group, including obtaining a media access control (MAC) address from the first remote device;handshaking with the first remote device, including: determining, based on the MAC address, whether a pairwise master key of the first remote device is valid; andin response to determining that the pairwise master key of the first remote device is valid, generating a transient key for the first remote device based on the pairwise master key of the first remote device.
2. The method of claim 1, wherein operating the wireless user device as the member of the peer-to-peer group further includes: removing the first remote device from the peer-to-peer group, including: invalidating the pairwise master key of the first remote device; andinvalidating the transient key generated for the first remote device.
3. The method of claim 2, wherein operating the wireless user device as the member of the peer-to-peer group further includes: after invalidating the pairwise master key of the first remote device and invalidating the transient key generated for the first remote device, exchanging data with another remote device that is a member of the peer-to-peer group.
4. The method of claim 2, wherein: operating the wireless user device as the member of the peer-to-peer group further includes: storing the pairwise master key of the first remote device in a key store; andinvalidating the pairwise master key of the first remote device comprises: deleting the pairwise master key of the first remote device from the key store.
5. The method of claim 2, wherein: operating the wireless user device as the member of the peer-to-peer group further includes: receiving a user request to remove the first remote device from the peer-to-peer group; andthe invalidating of the pairwise master key of the first remote device is in response to the user request.
6. The method of claim 1, wherein operating the wireless user device as the member of the peer-to-peer group further includes: performing a group owner negotiation with the first remote device.
7. The method of claim 1, wherein operating the wireless user device as the member of the peer-to-peer group further includes: at a first time, disconnecting the first remote device from the peer-to-peer group; andat a second time, reconnecting the first remote device to the peer-to-peer group, the reconnecting comprising: authenticating the first remote device based on the pairwise master key of the first remote device; andgenerating another transient key based on the pairwise master key of the first remote device.
8. The method of claim 1, wherein operating the wireless user device as the member of the peer-to-peer group further includes: transmitting the generated transient key to the first remote device; andreceiving a communication from the first remote device, wherein the communication was encrypted by the first remote device using the generated transient key.
9. The method of claim 1, wherein determining whether the pairwise master key of a first remote device is valid includes: performing a handshake in accordance with a Wi-Fi Protected Access (WPA2) protocol.
10. At least one computer readable storage medium comprising a memory, or a disk, storing computer executable instructions for performing operations, the operations comprising: operating a first user device as a controller for a peer-to-peer wireless network, including, at the first user device: determining that a second user device is attempting to join the peer-to-peer group, including obtaining a media access control (MAC) address from the second user device;handshaking with the second user device, including: determining, based on the MAC address whether a pairwise master key transmitted to the first user device by the second user device is valid; andin response to determining that the pairwise master key transmitted to the first user device by the second user device is valid, issuing a transient key to the second user device based on the pairwise master key of the first remote device.
11. The at least one computer readable storage medium of claim 10, wherein the operations further comprise: receiving a communication from the second user device, wherein the communication was encrypted by the second user device using the issued transient key.
12. The at least one computer readable storage medium of claim 10, wherein operating the first user device as the controller for the peer-to-peer wireless network further includes: removing the second user device from the peer-to-peer wireless network, including: invalidating a pairwise master key for the second user device; andinvalidating the transient key issued to the second user device.
13. The at least one computer readable storage medium of claim 12, wherein: operating the first user device as the controller for the peer-to-peer wireless network further includes: receiving a user request to remove the second user device from the peer-to-peer wireless network; andthe invalidating of the pairwise master key for the second wireless device is in response to the user request.
14. The at least one computer readable storage medium of claim 10, wherein operating the first user device as the controller for the peer-to-peer wireless network further includes: at a first time, disconnecting the second user device from the peer-to-peer wireless network; andat a second time, reconnecting the second user device to the peer-to-peer wireless network, including: authenticating the second user device based on a pairwise master key transmitted to the first user device by a second user device in association with an attempt by the second user device to reconnect to the peer-to-peer wireless network; andissuing another transient key for the peer-to-peer wireless network to the second user device.
15. The at least one computer readable storage medium of claim 10, wherein determining whether the pairwise master key transmitted to the first user device by the second user device is valid includes: performing a process in accordance with a Wi-Fi Protected Access (WPA2) protocol.
16. A user computing device comprising: a radio;at least one processor; andcomputer storage medium storing computer-executable instructions for execution on the at least on processor, the computer-executable instructions for causing the user computing device to perform operations, the operations including: operating the user computing device as a member of a peer-to-peer group, including, at the user computing device:identifying a first remote device that is attempting to join the peer-to-peer group, including obtaining a media access control (MAC) address from the first remote device;handshaking with the first remote device, including: determining, based on the MAC address, whether a pairwise master key of the first remote device is valid; andin response to determining that the pairwise master key of the first remote device is valid, generating a transient key for the first remote device based on the pairwise master key of the first remote device.
17. The computing device of claim 16, wherein operating the user computing device as the member of the peer-to-peer group further includes: removing the first remote device from the peer-to-peer group, including: invalidating the pairwise key of the first remote device; andinvalidating the transient key generated for the first remote device.
18. The computing device of claim 16, wherein the operations further include: invalidating the pairwise master key for remote device without invalidating a pairwise master key for another remote device.
19. The computing device of claim 18, wherein invalidation of the pairwise master key for the other remote device removes the other remote device from the peer-to-peer group.
20. The computing device of claim 16, wherein the operations further include: receiving a communication from the second user device, wherein the communication was encrypted by the second user device using the issued transient key.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. patent application Ser. No. 14/600,477, filed Jan. 20, 2015, entitled “SECURE PROTOCOL FOR PEER-TO-PEER NETWORK”, which is a continuation of U.S. patent application Ser. No. 12/970,159, filed Dec. 16, 2010, entitled “SECURE PROTOCOL FOR PEER-TO-PEER NETWORK,”. The entirety of each of these afore-mentioned applications is incorporated herein by reference.

US Referenced Citations (314)

Number	Name	Date	Kind
4949299	Pickett	Aug 1990	A
5574964	Hamlin	Nov 1996	A
5682382	Shepard	Oct 1997	A
5689825	Averbuch et al.	Nov 1997	A
5729682	Marquis et al.	Mar 1998	A
5963915	Kirsch	Oct 1999	A
5966441	Calamera	Oct 1999	A
6288749	Freadman	Sep 2001	B1
6317490	Cameron et al.	Nov 2001	B1
6338046	Saari et al.	Jan 2002	B1
6343205	Threadgill et al.	Jan 2002	B1
6553060	Souissi et al.	Apr 2003	B2
6628965	Larosa et al.	Sep 2003	B1
6665709	Barron	Dec 2003	B1
6711617	Bantz et al.	Mar 2004	B1
6789228	Merril et al.	Sep 2004	B1
6823379	Heckel et al.	Nov 2004	B1
7020472	Schmidt	Mar 2006	B2
7027808	Wesby	Apr 2006	B2
7058696	Phillips et al.	Jun 2006	B1
7107009	Sairanen et al.	Sep 2006	B2
7110843	Pagnano et al.	Sep 2006	B2
7177288	Mooney et al.	Feb 2007	B2
7194278	Cook	Mar 2007	B1
7274911	Li	Sep 2007	B2
7280978	Joao	Oct 2007	B1
7290132	Aboba et al.	Oct 2007	B2
7349342	Carpenter et al.	Mar 2008	B2
7400253	Cohen	Jul 2008	B2
7412534	Tsang et al.	Aug 2008	B2
7454191	Dawson et al.	Nov 2008	B2
7460253	Osada	Dec 2008	B2
7461253	Braskich	Dec 2008	B2
7496637	Han et al.	Feb 2009	B2
7512401	Muhonen et al.	Mar 2009	B2
7558604	Narayanaswami et al.	Jul 2009	B2
7562129	Lee et al.	Jul 2009	B1
7577125	Abhishek et al.	Aug 2009	B2
7580678	Byman-Kivivuori et al.	Aug 2009	B2
7584296	Sun et al.	Sep 2009	B2
7589693	Locke	Sep 2009	B2
7640213	Reunert et al.	Dec 2009	B2
7650137	Jobs et al.	Jan 2010	B2
7672459	Ohara et al.	Mar 2010	B2
7721093	Sundararajan	May 2010	B2
7729689	Chakraborty et al.	Jun 2010	B2
7751317	Toyama et al.	Jul 2010	B2
7769394	Zhu	Aug 2010	B1
7783019	Mahone et al.	Aug 2010	B2
7788703	Jou et al.	Aug 2010	B2
7792920	Istvan et al.	Sep 2010	B2
7925739	Kocho et al.	Apr 2011	B2
7962854	Vance et al.	Jun 2011	B2
7991770	Covell et al.	Aug 2011	B2
8014415	Alapuranen	Sep 2011	B2
8095111	Henry, Jr. et al.	Jan 2012	B2
8098803	Croak et al.	Jan 2012	B1
8115658	Griffin	Feb 2012	B2
8204013	Lewis	Jun 2012	B2
8239516	Huslak et al.	Aug 2012	B2
8254878	Howard et al.	Aug 2012	B2
8254992	Ashenbrenner et al.	Aug 2012	B1
8260998	Ganesh et al.	Sep 2012	B2
8285250	Rubin et al.	Oct 2012	B2
8323040	Prest	Dec 2012	B2
8326958	Raleigh	Dec 2012	B1
8375328	Koh et al.	Feb 2013	B2
8397982	Slaby et al.	Mar 2013	B2
8437736	Rubin et al.	May 2013	B2
8479225	Covell et al.	Jul 2013	B2
8493931	Nix	Jul 2013	B1
8565928	Venkatakrishnan et al.	Oct 2013	B2
8577329	Momtahan et al.	Nov 2013	B2
8589991	Hassan et al.	Nov 2013	B2
8606911	Raleigh et al.	Dec 2013	B2
8621097	Venkatakrishnan et al.	Dec 2013	B2
8633616	Soar	Jan 2014	B2
8659565	Sirpal et al.	Feb 2014	B2
8700641	Covell et al.	Apr 2014	B2
8792429	Hassan et al.	Jul 2014	B2
8813201	Lambert	Aug 2014	B2
8892691	Pantos et al.	Nov 2014	B2
8971841	Menezes et al.	Mar 2015	B2
8977731	Venkatakrishnan et al.	Mar 2015	B2
8984628	Mahaffey et al.	Mar 2015	B2
9008610	Menezes et al.	Apr 2015	B2
9009828	Ramsey et al.	Apr 2015	B1
9148238	Dureau	Sep 2015	B2
9178652	Hassan et al.	Nov 2015	B2
9237366	Schaffer et al.	Jan 2016	B2
9294545	Desai et al.	Mar 2016	B2
9338309	Menezes et al.	May 2016	B2
9392462	Raleigh et al.	Jul 2016	B2
9450995	Hassan et al.	Sep 2016	B2
9542203	Hassan et al.	Jan 2017	B2
9596220	Hassan et al.	Mar 2017	B2
9801074	Hassan et al.	Oct 2017	B2
9870028	Hassan et al.	Jan 2018	B2
9998522	Desai et al.	Jun 2018	B2
10044515	Menezes et al.	Aug 2018	B2
20010021950	Hawley et al.	Sep 2001	A1
20010037399	Eylon et al.	Nov 2001	A1
20010042124	Barron	Nov 2001	A1
20010046298	Terada et al.	Nov 2001	A1
20010052052	Peng	Dec 2001	A1
20020067268	Lee et al.	Jun 2002	A1
20020116485	Black et al.	Aug 2002	A1
20020120935	Huber et al.	Aug 2002	A1
20020143819	Han et al.	Oct 2002	A1
20020154751	Thompson et al.	Oct 2002	A1
20020156876	Hartman et al.	Oct 2002	A1
20020183038	Comstock et al.	Dec 2002	A1
20030142651	Matta	Jul 2003	A1
20030187992	Steenfeldt et al.	Oct 2003	A1
20030231586	Chheda	Dec 2003	A1
20040002305	Byman-Kivivuori et al.	Jan 2004	A1
20040002326	Maher	Jan 2004	A1
20040006606	Marotta et al.	Jan 2004	A1
20040049576	Schweitzer et al.	Mar 2004	A1
20040061716	Cheung et al.	Apr 2004	A1
20040128363	Yamagami et al.	Jul 2004	A1
20040174395	Liu	Sep 2004	A1
20040198374	Bajikar	Oct 2004	A1
20040203815	Shoemake et al.	Oct 2004	A1
20040205154	Dalton et al.	Oct 2004	A1
20040210320	Pandya	Oct 2004	A1
20040260630	Benco et al.	Dec 2004	A1
20050028208	Ellis et al.	Feb 2005	A1
20050071319	Kelley et al.	Mar 2005	A1
20050083975	Macri	Apr 2005	A1
20050085222	Przybilski et al.	Apr 2005	A1
20050097248	Kelley	May 2005	A1
20050105632	Catreux-Erces et al.	May 2005	A1
20050128995	Ott et al.	Jun 2005	A1
20050135235	Maruyama et al.	Jun 2005	A1
20050136886	Aamio et al.	Jun 2005	A1
20050136920	Rink et al.	Jun 2005	A1
20050159179	Sainton et al.	Jul 2005	A1
20050174962	Gurevich	Aug 2005	A1
20050177715	Somin et al.	Aug 2005	A1
20050198238	Sim et al.	Sep 2005	A1
20050221844	Trethewey et al.	Oct 2005	A1
20050223226	Sundararajan	Oct 2005	A1
20050229246	Rajagopal et al.	Oct 2005	A1
20050249266	Brown et al.	Nov 2005	A1
20060015904	Marcus	Jan 2006	A1
20060041916	Mcquaide	Feb 2006	A1
20060059462	Yamamoto	Mar 2006	A1
20060107036	Randle et al.	May 2006	A1
20060140135	Bonta et al.	Jun 2006	A1
20060143027	Jagannathan et al.	Jun 2006	A1
20060145815	Lanzieri et al.	Jul 2006	A1
20060171304	Hill et al.	Aug 2006	A1
20060200678	Yamada	Sep 2006	A1
20060239208	Roberts et al.	Oct 2006	A1
20060290519	Boate et al.	Dec 2006	A1
20060294112	Mandato et al.	Dec 2006	A1
20070011022	Wright et al.	Jan 2007	A1
20070054616	Culbert	Mar 2007	A1
20070057793	Alden	Mar 2007	A1
20070064604	Chen et al.	Mar 2007	A1
20070124485	Frost et al.	May 2007	A1
20070124756	Covell et al.	May 2007	A1
20070153695	Gholmieh et al.	Jul 2007	A1
20070153729	Alapuranen	Jul 2007	A1
20070161411	Liao et al.	Jul 2007	A1
20070171915	Toyama et al.	Jul 2007	A1
20070192735	Lehto et al.	Aug 2007	A1
20070207750	Brown et al.	Sep 2007	A1
20070223398	Luo et al.	Sep 2007	A1
20070225831	Sakurada	Sep 2007	A1
20070248179	Hassan et al.	Oct 2007	A1
20070254628	Rybak	Nov 2007	A1
20070271525	Han et al.	Nov 2007	A1
20070274488	Callaghan	Nov 2007	A1
20070280332	Srikanteswara et al.	Dec 2007	A1
20070280481	Eastlake et al.	Dec 2007	A1
20080002658	Soliman	Jan 2008	A1
20080016338	Sun	Jan 2008	A1
20080031155	Korus	Feb 2008	A1
20080049700	Shah et al.	Feb 2008	A1
20080055399	Woodworth et al.	Mar 2008	A1
20080055423	Ying et al.	Mar 2008	A1
20080063204	Braskich	Mar 2008	A1
20080065238	Igoe	Mar 2008	A1
20080081597	Cole	Apr 2008	A1
20080104170	Ananthanarayanan	May 2008	A1
20080111822	Horowitz et al.	May 2008	A1
20080130519	Bahl et al.	Jun 2008	A1
20080130639	Costa-Requena et al.	Jun 2008	A1
20080132201	Karlberg	Jun 2008	A1
20080152098	Paryzek et al.	Jun 2008	A1
20080195861	Salomone	Aug 2008	A1
20080197802	Onishi et al.	Aug 2008	A1
20080207119	Chang	Aug 2008	A1
20080207128	Mikko	Aug 2008	A1
20080227384	Placzek et al.	Sep 2008	A1
20080252410	Lin	Oct 2008	A1
20080252419	Batchelor et al.	Oct 2008	A1
20080275993	Mohammed et al.	Nov 2008	A1
20080285496	Fuchs et al.	Nov 2008	A1
20080293375	Swanburg	Nov 2008	A1
20080293419	Somasundaram et al.	Nov 2008	A1
20080311952	Sugiyama	Dec 2008	A1
20080319857	Dobbins et al.	Dec 2008	A1
20090011738	Sasakura	Jan 2009	A1
20090013175	Elliott	Jan 2009	A1
20090039828	Jakubowski	Feb 2009	A1
20090045913	Nelson et al.	Feb 2009	A1
20090055266	Brody et al.	Feb 2009	A1
20090068984	Burnett	Mar 2009	A1
20090089885	Noble et al.	Apr 2009	A1
20090092060	Goto	Apr 2009	A1
20090100080	Toms et al.	Apr 2009	A1
20090103481	Mahajan et al.	Apr 2009	A1
20090106542	Dubs et al.	Apr 2009	A1
20090111378	Sheynman et al.	Apr 2009	A1
20090138715	Xiao et al.	May 2009	A1
20090144622	Evans et al.	Jun 2009	A1
20090154343	Fitch et al.	Jun 2009	A1
20090158394	Oh	Jun 2009	A1
20090170431	Pering et al.	Jul 2009	A1
20090196180	Bahl et al.	Aug 2009	A1
20090203352	Fordon et al.	Aug 2009	A1
20090210940	Dean	Aug 2009	A1
20090249322	Sugiyama et al.	Oct 2009	A1
20090254924	Anirudh et al.	Oct 2009	A1
20090303902	Liu et al.	Dec 2009	A1
20090303921	Manchanda et al.	Dec 2009	A1
20090307683	Gharabally	Dec 2009	A1
20090319663	Giles	Dec 2009	A1
20100017506	Fadell	Jan 2010	A1
20100042297	Foster et al.	Feb 2010	A1
20100049971	Oh	Feb 2010	A1
20100056124	Keating et al.	Mar 2010	A1
20100081473	Chatterjee et al.	Apr 2010	A1
20100091965	Ma et al.	Apr 2010	A1
20100097830	Wang	Apr 2010	A1
20100100637	Bowra et al.	Apr 2010	A1
20100103850	Gossain et al.	Apr 2010	A1
20100104078	Henry, Jr. et al.	Apr 2010	A1
20100110890	Rainer et al.	May 2010	A1
20100111033	Erceg et al.	May 2010	A1
20100115278	Shen et al.	May 2010	A1
20100121744	Belz et al.	May 2010	A1
20100123598	Brodersen et al.	May 2010	A1
20100123834	Brodersen et al.	May 2010	A1
20100144274	Mcdowall et al.	Jun 2010	A1
20100153762	Radulescu et al.	Jun 2010	A1
20100157167	Lawther et al.	Jun 2010	A1
20100175101	Devictor et al.	Jul 2010	A1
20100186066	Pollard	Jul 2010	A1
20100191576	Raleigh	Jul 2010	A1
20100191847	Raleigh	Jul 2010	A1
20100195580	Samarasooriya et al.	Aug 2010	A1
20100198952	Kneckt et al.	Aug 2010	A1
20100220856	Kruys et al.	Sep 2010	A1
20100226253	Bugenhagen	Sep 2010	A1
20100232332	Abdel-Kader	Sep 2010	A1
20100246818	Yao	Sep 2010	A1
20100248599	Voigt	Sep 2010	A1
20100257251	Mooring et al.	Oct 2010	A1
20100284316	Sampathkumar	Nov 2010	A1
20100302005	Popovski	Dec 2010	A1
20100333032	Lau et al.	Dec 2010	A1
20110010433	Wilburn et al.	Jan 2011	A1
20110107388	Lee et al.	May 2011	A1
20110145581	Malhotra et al.	Jun 2011	A1
20110149806	Verma et al.	Jun 2011	A1
20110176463	Cowan et al.	Jul 2011	A1
20110188391	Sella et al.	Aug 2011	A1
20110188419	Filoso et al.	Aug 2011	A1
20110188420	Filoso et al.	Aug 2011	A1
20110202189	Venkatakrishnan et al.	Aug 2011	A1
20110230209	Kilian	Sep 2011	A1
20110238498	Hassan et al.	Sep 2011	A1
20110261001	Liu	Oct 2011	A1
20110274020	Filoso et al.	Nov 2011	A1
20110275316	Suumaeki et al.	Nov 2011	A1
20110276442	Momtahan et al.	Nov 2011	A1
20110280413	Wu et al.	Nov 2011	A1
20110293095	Ben Ayed	Dec 2011	A1
20110320963	Wong	Dec 2011	A1
20110321126	Maniatopoulos	Dec 2011	A1
20120101952	Raleigh et al.	Apr 2012	A1
20120139690	Gupta et al.	Jun 2012	A1
20120144083	Hassan et al.	Jun 2012	A1
20120147268	Hassan et al.	Jun 2012	A1
20120147274	Hassan et al.	Jun 2012	A1
20120147825	Hassan et al.	Jun 2012	A1
20120155643	Hassan et al.	Jun 2012	A1
20120157038	Menezes et al.	Jun 2012	A1
20120158839	Hassan et al.	Jun 2012	A1
20120158947	Hassan et al.	Jun 2012	A1
20120158981	Desai et al.	Jun 2012	A1
20120178429	Camps Mur et al.	Jul 2012	A1
20120197792	Raleigh	Aug 2012	A1
20130033800	Bartnik et al.	Feb 2013	A1
20130097422	Salomone	Apr 2013	A1
20130103779	Bai et al.	Apr 2013	A1
20130125107	Bandakka et al.	May 2013	A1
20130138792	Preden et al.	May 2013	A1
20130182614	Kumar	Jul 2013	A1
20130211893	Bryant et al.	Aug 2013	A1
20130217357	Menezes et al.	Aug 2013	A1
20130322846	Ferren et al.	Dec 2013	A1
20140323084	Menezes et al.	Oct 2014	A1
20140328251	Hassan et al.	Nov 2014	A1
20160112579	Menezes et al.	Apr 2016	A1
20160234030	Menezes et al.	Aug 2016	A1
20170115696	Hassan et al.	Apr 2017	A1
20170329366	Hassan et al.	Nov 2017	A1
20180359633	Liu et al.	Dec 2018	A1
20190020488	Menezes et al.	Jan 2019	A1

Foreign Referenced Citations (44)

Number	Date	Country
2712480	Sep 2009	CA
1571341	Jan 2005	CN
1592210	Mar 2005	CN
1607780	Apr 2005	CN
1677975	Oct 2005	CN
1929424	Mar 2007	CN
1960474	May 2007	CN
101021774	Aug 2007	CN
101044718	Sep 2007	CN
101075820	Nov 2007	CN
101094140	Dec 2007	CN
101137960	Mar 2008	CN
101147308	Mar 2008	CN
101179359	May 2008	CN
101288063	Oct 2008	CN
101657828	Feb 2010	CN
1662920	Apr 2010	CN
101841637	Sep 2010	CN
101867623	Oct 2010	CN
2256663	Dec 2010	EP
2418809	Apr 2006	GB
2001160927	Jun 2001	JP
2005004089	Jan 2005	JP
2005295286	Oct 2005	JP
2005341094	Dec 2005	JP
2006050216	Feb 2006	JP
2007527156	Sep 2007	JP
20020018991	Mar 2002	KR
20070111592	Nov 2007	KR
2008032979	Apr 2008	KR
20100038089	Apr 2010	KR
81863	Mar 2009	RU
0147248	Jun 2001	WO
0154342	Jul 2001	WO
2002025397	Mar 2002	WO
2004003801	Jan 2004	WO
2006131077	Dec 2006	WO
2008021855	Feb 2008	WO
2008089854	Jul 2008	WO
2008127507	Oct 2008	WO
2009046869	Apr 2009	WO
2010044599	Apr 2010	WO
2010128391	Nov 2010	WO
2010132296	Nov 2010	WO

Non-Patent Literature Citations (239)

Entry
Final Office Action dated Nov. 13, 2012 in U.S. Appl. No. 12/748,829, 42 pages.
Final Office Action dated Nov. 15, 2010 in U.S. Appl. No. 11/726,862, 21 pages.
Final Office Action dated Dec. 26, 2013 in U.S. Appl. No. 12/967,638, 34 pages.
Final Office Action dated Dec. 4, 2014 in U.S. Appl. No. 12/960,730, 22 pages.
Final Office Action dated Dec. 5, 2014 in U.S. Appl. No. 12/970,069, 21 pages.
Final Office Action dated Feb. 11, 2014 in U.S. Appl. No. 12/970,069, 26 pages.
Final Office Action dated Feb. 15, 2013 in U.S. Appl. No. 12/967,761, 28 pages.
Final Office Action dated Feb. 15, 2013 in U.S. Appl. No. 12/970,069, 23 pages.
Final Office Action dated Mar. 11, 2016 in U.S. Appl. No. 12/960,753, 17 pages.
Final Office Action dated Mar. 28, 2013 in U.S. Appl. No. 12/967,638, 22 pages.
Final Office Action dated Jun. 9, 2016 in U.S. Appl. No. 14/600,477, 9 pages.
Final Office Action dated Jul. 12, 2016 in U.S. Appl. No. 14/981,271, 10 pages.
Final Office Action dated Jul. 13, 2015 in U.S. Appl. No. 14/318,380, 8 pages.
Final Office Action dated Sep. 15, 2011 in U.S. Appl. No. 11/726,862, 24 pages.
Final Office Action dated Sep. 20, 2012 in U.S. Appl. No. 11/726,862, 35 pages.
Final Office Action dated Sep. 23, 2013 in U.S. Appl. No. 12/970,034, 22 pages.
Guide to IEEE 802.11i: Establishing Robust Security Networks;Published Date: Jun. 2006; 155 pages.
Haas, Robert et al., “Cost- and Quality-of-Service-Aware Network-Service Deployment,” 2001, 6 pages.
Hassan, Amer, “Cognitive Use of Multiple Regulatory Domains”; U.S. Appl. No. 14/458,203, filed Aug. 12, 2014; 58 pages including Preliminary Amendment filed Oct. 9, 2014.
Hassan, Amer, “Cognitive Use of Multiple Regulatory Domains”; U.S. Appl. No. 14/863,290, filed Sep. 23, 2015; 57 pages including Preliminary Amendment filed Nov. 1, 2015.
Hassan, Amer, “Cognitive Use of Multiple Regulatory Domains”; U.S. Appl. No. 15/233,348, filed Aug. 10, 2016; 57 pages including Preliminary Amendment filed Sep. 21, 2016.
Hassan, Amer, “Direct Connection With Side Channel Control”; U.S. Appl. No. 14/333,386, filed Jul. 16, 2014; 65 pages including Preliminary Amendment filed Sep. 26, 2014.
Hassan, Amer, “Direct Connection With Side Channel Control”; U.S. Appl. No. 14/993,786, filed Jan. 12, 2016; 64 pages including Preliminary Amendment filed Jan. 13, 2016.
Hassan, Amer, “Secure Protocol for Peer-To-Peer Network”; U.S. Appl. No. 14/600,477, filed Jan. 20, 2015; 62 pages including Preliminary Amendment filed May 8, 2014.
How Do You Use a Laptop As a TV Remote Control?; Published Date: Jul. 15, 2008; 6 pages.
International Search Report dated Jul. 24, 2012 in PCT Application No. PCT/US2011/065691, Filing Date: Dec. 17, 2011, 11 pages.
International Search Report dated Sep. 5, 2012 in PCT Application No. PCT/US2011/065692, Filing Date: Dec. 17, 2011, 8 pages.
International Search Report; dated Aug. 31, 2012; Application No. PCT/US2011/064753; Filed Date: Dec. 14, 2011, pp. 8.
International Search Report; dated Jul. 31, 2012; Application No. PCT/US2011/065285; Filed Date: Dec. 15, 2011, pp. 9.
Kaasinen, et al., “Ambient Functionality—Use Cases”, In Proceedings of the 2005 joint conference on Smart objects and ambient intelligence: innovative context-aware services: usages and technologies, Oct. 12, 2005, 6 pages.
Kitson, Fred., “Mobile Media Making it a Reality”, In Proceedings of Mobile Computing, vol. 3, Issue 4, Jun. 7, 2005, 17 pages.
Klym, et al., “The Evolution of RFID Networks: The Potential for Disruptive Innovation”, In White Paper, Mar. 2006, 20 pages.
Lun, Desmond S. et al., “Network Coding with a Cost Criterion,” MIT LIDS Technical Report P-2584, Apr. 2004, 18 pages.
Manage Subscription Products & Automate Recurring Billing Operations; Copyright 2008-2009; Retrieved Date: Jan. 12, 2010, 1 page.
Manifest Permission; Published Date: Jul. 21, 2004; 19 pages.
Meinrath et al.; “Unlicensed ‘White Space Device’ Operations on the TV Band and the Myth of Harmful Interferences”, Mar. 2008, 13 pages.
Meinrath et al.; “White Space Devices & The Myths of Harmful Interference”, 11 N.Y.U.J. Legis&Pub. Policy 495, 2008, 24 pages.
Menezes, Pascal; “Operating System Supporting Cost Aware Applications”; U.S. Appl. No. 13/844,932, filed Mar. 16, 2013; 57 pages.
Menezes, Pascal; “Operating System Supporting Cost Aware Applications”; U.S. Appl. No. 14/318,380, filed Mar. 16, 2013; 56 pages.
Menezes, Pascal; “Operating System Supporting Cost Aware Applications”; U.S. Appl. No. 14/981,271, filed Dec. 28, 2016; 63 pages including Preliminary Amendment filed Jan. 20, 2016.
Menezes, Pascal; “Operating System Supporting Cost Aware Applications”; U.S. Appl. No. 15/098,321, filed Apr. 14, 2016; 57 pages.
MIST: Cellular Data Network Measurement for Mobile Applications; Published Date: Apr. 24, 2006; 9 pages.
Mobile Internet Usage Measurements—Case Finland; Published Date: Apr. 24, 2006; 140 pages.
Mohammed, “Web Service for User and Subscription Data Storage”, U.S. Appl. No. 13/772,275, filed Feb. 20. 2013, 49 pages.
Motorola, “TV White Space Position Paper,” 2008, 10 pages.
Non-Final Office Action dated Jan. 21, 2016 in U.S. Appl. No. 14/863,290, 7 pages.
Non-Final Office Action dated Jan. 4, 2013 in U.S. Appl. No. 12/960,730, 14 pages.
Non-Final Office Action dated Oct. 2, 2012 in U.S. Appl. No. 12/967,638, 33 pages.
Non-Final Office Action dated Oct. 16, 2012 in U.S. Appl. No. 12/970,069, 23 pages.
Non-Final Office Action dated Oct. 2, 2014 in U.S. Appl. No. 14/318,380, 5 pages.
“International Preliminary Report on Patentability Issued in PCT Application No. PCT/US11/65691”, dated Jun. 18, 2013, 5 Pages.
“International Search Report”, dated Aug. 14, 2012, Application No. PCT/US2011/065276, Filed Date: Dec. 15, 2011, pp. 9.
“International Search Report”, dated Jul. 12, 2012, Application No. PCT/US2011/063207, Filing Date: Dec. 4, 2011, pp. 9.
“International Search Report”, dated Jun. 22, 2012, Application No. PCT/US2011/063340, Filed Date: Dec. 5, 2011, pp. 9.
“Notice of Allowance Issued in Chinese Patent Application No. 201110423031.4”, dated Jan. 23, 2015, 3 Pages.
“Notice of Allowance Issued in Chinese Patent Application No. 201110426179.3”, dated Nov. 4, 2014, 3 Pages.
“Notice of Allowance Issued in U.S. Appl. No. 12/970,069” dated Dec. 8, 2015, 3 Pages.
“Notice of Allowance Issued in U.S. Appl. No. 12/970,069” dated Nov. 12, 2015, 3 Pages.
“Notice of Allowance Issued in U.S. Appl. No. 12/970,069”, dated Jan. 29, 2016, 4 Pages.
“Notice of Allowance Issued in U.S. Appl. No. 12/970,069”, dated May 15, 2015, 4 Pages.
“Office Action and Search Report Issued in Chinese Patent Application No. 201110400472.2”, dated Oct. 27, 2014, 14 Pages.
“Office Action Received in Australia Patent Application No. 2011343700”, dated Jul. 24, 2015, 2 Pages.
“Omnidrive”, 2006, retrieved Oct. 26, 2006, 2 pages.
“Xdrive”, 2006, retrieved Oct. 26, 2006, 2 pages.
“Second Office Action Issued in Chinese Patent Application No. 201110408217.2”, dated May 23, 2014, Filed Date: Dec. 9, 2011, 8 Pages including partial translation.
02 Network Scraps Unlimited Data for Smartphones; Published Date: Jun. 10, 2010; 2 pages.
802.11 Fast BSS Transition (FT) Part 1 of 2; Published Date: Aug. 21, 2007, 5 pages.
A New Location Technique for the Active Office—Published Date: 1997, http://citeseerx.ist.nsu.edu/viewdoc/download?doi=10.1.1.20.5052&rep=repl&type=pdf.
Advisory Action dated Jan. 2, 2013 in U.S. Appl. No. 11/726,862, 3 pages.
Araujo, Joao Taveira et al., “Towards Cost-Aware Multipath Routing,” AIMS 2009, LNCS 5637, 2009, pp. 207-210.
Butler, Kevin R.B. et al.; Leveraging Identity-Based Cryptography for Node ID Assignment in Structured P2P Systems; IEEE Transactions on Parallel and Distributed Systems; vol. 20, No. 12; Dec. 2009; pp. 1803-1815.
Chinese Office Action dated Dec. 4, 2013 in CN Patent Application No. 201110426187.8, 8 pages including Concise Explanation of Relevance and/or partial translation.
Chinese Office Action dated Feb. 28, 2014 in CN Patent Application No. 201110426179.3, 9 pages including Concise Explanation of Relevance and/or partial translation.
Chinese Office Action dated Jan. 6, 2014 in CN Patent App. No. 201110423068.7, 8 pages including concise explanation of relevance and partial translation.
Chinese Office Action dated Jan. 7, 2015 in CN Patent App. No. 201110400433.2, 10 pages including partial translation.
Chinese Office Action dated Nov. 20, 2013 in CN Patent App. No. 201110423001.3, 18 pages translation.
Chinese Office Action dated Dec. 4, 2013 in CN Patent App. No. 201110408217.2, 12 pages, including Concise Explanation of Relevance and/or partial translation.
Chinese Office Action dated Dec. 4, 2013 in CN Patent App. No. 201110423031.4, 26 pages including translation.
Chinese Office Action dated Feb. 17, 2014 in CN Patent App. No. 201110400433.2, 12 pages including partial translation.
Chinese Office Action dated Feb. 27, 2014 in CN Patent App. No. 201110400472.2, 13 pages including Concise Explanation of Relevance and partial translation.
Chinese Office Action dated Jul. 11, 2014 in CN Patent App. No. 201110423031.4, 13 pages, including partial translation and/or concise explanation of relevance.
Chinese Office Action dated Jul. 13, 2015 in CN Patent App. No. 201110400433.2, 3 pages.
Chinese Office Action dated Aug. 5, 2014 in CN Patent App. No. 201110426179.3, 6 pages, including partial translation.
Chinese Office Action dated Sep. 2, 2014 in CN Patent App. No. 201110408217.2, 6 pages, including partial translation.
Chinese Office Action dated Sep. 4, 2014 in CN Patent App. No. 201110423001.3, 6 pages, including partial translation.
Chinese Office Action dated Sep. 9, 2014 in CN Patent App. No. 201110400433.2, 13 pages including partial translation.
Choi, Jongmyung., “RFID Context-aware Systems”, In Proceedings of Sustainable Radio Frequency Identification Solutions, Feb. 1, 2010, pp. 307-331.
CISCO Systems, Inc., “802.11 n Wireless Technology Overview,” 2007, 7 pages.
Creating Customized Web Experiences with Windows Media Player 9 Series; Published Date: Nov. 2002; 4 pages.
CRTDH; An Efficient Key Agreement Scheme for Secure Group Communications in Wireless Ad Hoc Networks; Published Date: 2005, 5 pages.
Currie, et al., “Experimental Evaluation of Read Performance for RFID-based Mobile Sensor Data Gathering Applications”, In Proceedings of the 7th International Conference on Mobile and Ubiquitous Multimedia, Dec. 3, 2008, pp. 92-95.
Desai, Mitesh, K.; “Fast Join of Peer to Peer Group With Power Saving Mode”; U.S. Appl. No. 14/975,818, filed Dec. 20, 2015; 56 pages including Preliminary Amendment filed Dec. 29, 2015.
Extended European Search Report dated May 20, 2014 in EP Patent App. No. 11847426.1, 8 pages.
Extended European Search Report dated Jun. 8, 2015 in EP Patent App. No. 11849551.4, 6 pages.
Final Office Action dated Jan. 11, 2016 in U.S. Appl. No. 12/970,034, 25 pages.
Final Office Action dated Jan. 16, 2015 in U.S. Appl. No. 12/960,753, 12 pages.
Final Office Action dated Jan. 28, 2015 in U.S. Appl. No. 12/970,034, 24 pages.
Final Office Action dated Jan. 9, 2015 in U.S. Appl. No. 14/318,380, 8 pages.
Final Office Action dated Oct. 25, 2013 in U.S. Appl. No. 12/972,104, 10 pages.
Final Office Action dated Oct. 6, 2014 in U.S. Appl. No. 12/972,104, 10 pages.
Notice of Allowance dated Mar. 25, 2013 in U.S. Appl. No. 12/972,230, 8 pages.
Notice of Allowance dated Mar. 4, 2013 in U.S. Appl. No. 12/972,230, 7 pages.
Notice of Allowance dated Mar. 6, 2014 in U.S. Appl. No. 12/967,638, 11 pages.
Notice of Allowance dated Apr. 2, 2014 in U.S. Appl. No. 12/964,492, 9 pages.
Notice of Allowance dated May 23, 2016 in U.S. Appl. No. 14/863,290, 12 pages.
Notice of Allowance dated May 24, 2016 in JP Patent Application No. 2013-544714, 4 pages.
Notice of Allowance dated May 7, 2014 in U.S. Appl. No. 13/844,932, 7 pages.
Notice of Allowance dated Jun. 24, 2015 in U.S. Appl. No. 14/458,203, 11 pages.
Notice of Allowance dated Jun. 27, 2014 in U.S. Appl. No. 12/970,159, 8 pages.
Notice of Allowance dated Jun. 28, 2016 in JP Patent Application No. 2013-544795, 3 pages.
Notice of Allowance dated Jun. 8, 2015 in U.S. Appl. No. 13/772,275, 8 pages.
Notice of Allowance dated Jul. 12, 2013 in U.S. Appl. No. 12/967,761, 12 pages.
Notice of Allowance dated Jul. 24, 2014 in U.S. Appl. No. 12/972,230, 7 pages.
Notice of Allowance dated Aug. 20, 2014 in U.S. Appl. No. 12/964,492, 13 pages.
Notice of Allowance dated Sep. 17, 2014 in U.S. Appl. No. 12/972,230, 7 pages.
Notice of Allowance dated Sep. 3, 2014 in U.S. Appl. No. 12/970,159, 9 pages.
Office Action dated Oct. 26, 2015 in JP Pat. App. No. 2013-543239, 13 pages including translation.
Office Action dated Nov. 16, 2015 in JP Pat. App. No. 2013-544795, 9 Pages.
Office Action dated Nov. 24, 2015 in RU Pat. App. No. 2013127235, 4 Pages w/o English Translation.
Office Action dated Apr. 13, 2015 in CN Pat. App. No. 201110400472.04, 14 pages, including partial translation and/or concise explanation of relevance.
Office Action dated Aug. 13, 2015 in AU Pat. App. No. 2011343943, 5 pages.
Office Action dated Aug. 28, 2015 in JP Pat. App. No. 2013-544714, 5 pages including translation.
Office Action dated Apr. 1, 2014 in CN Pat. App. No. 201110423001.3, 8 pages, including partial translation.
Office Action dated Apr. 3, 2014 in CN Pat. App. No. 201110417153.2, 15 pages, including partial translation and/or concise explanation of relevance.
Office Action dated Aug. 14, 2015 in CN Pat. App. No. 201110417226.8, 6 pages, including partial translation.
Office Action dated Dec. 15, 2014 in CN Pat. App. No. 201110417153.2, 8 pages, including partial translation.
Office Action dated Feb. 3, 2015 in CN Pat. App. No. 201110417226.8, 7 pages, including partial translation and/or concise explanation of relevance.
Office Action dated Jun. 5, 2014 in CN Pat. App. No. 201110417226.8, 14 pages, including partial translation and/or concise explanation of relevance.
Pawar, Pravin et al. “Towards Location based QoS-Aware Network Selection Mechanism for the Nomadic Mobile Services,” Dec. 5, 2009, 5 pages.
Roduner, et al., “Operating Appliances with Mobile Phones—Strengths and Limits of a Universal Interaction Device”, In Proceedings of the 5th international conference on Pervasive computing, May 13, 2007, 18 pages.
Shared Spectrum, Inc., “Our Technology,” Nov. 2010, 2 pages.
Shih, Eugene et al.; Wake on Wireless: An Event Driven Energy Saving; Published Date: Sep. 23-26, 2002; 12 pages.
Sridhar, T.; Wi-Fi, Bluetooth and WiMAX; The Internet Protocol Journal, vol. 11, No. 4; Retrieved Date: Sep. 30, 2010, 9 pages.
Subscription Management; Copyright 2009; Retrieved Date: Jan. 12, 2010; 2 pages.
Symbian Foundation Peer-to-Peer WiFi Inititative (WiFi irect); Published Date: Sep. 10, 2010, 11 pages.
Texas Instruments, MSP430 Ultra-Low-Power MCUs and TI-RFid Devices, 2 pages, 2009.
T-mobile “Unlimited” Data Usage; Published Date: Mar. 9, 2010; 6 pages.
Torres Service Management Platform; Retrieved Date: Jan. 12, 2010; 2 pages.
VAS Subscription Manager; Retrieved Date: Jan. 12, 2010; 1 page.
Wi-Fi Alliance: FAQs; Published Date: 2010; 19 pages.
Wi-Fi Certified Wi-Fi Direct, Personal, Portable Wi-Fi Technology; Oct. 2010, 14 pages.
WinLIRC; Published Date: Mar. 17, 2008; 5 pages.
Wireless PC to TV; Retrieved Date: Sep. 9, 2010; 2 pages.
Wood, “Kowari: A Platform for Semantic Web Storage and Analysis”, May 27, 2005, 16 pages.
Yuan, Y. et al., “Allocating Dynamic Time-Spectrum Blocks in Cognitive Radio Networks,” Sep. 9-14, 2007, 10 pages.
Hassan, Amer, “Universal Dock for Context Sensitive Computing Device”; U.S. Appl. No. 15/399,728, filed Jan. 5, 2017, including Preliminary Amendment filed Jan. 19, 2017; 50 pages.
Final Office Action dated Feb. 2, 2017 in U.S. Appl. No. 12/972,104, 16 pages.
Non-Final Office Action dated Feb. 8, 2017 in U.S. Appl. No. 15/399,728, 11 pages.
Final Office Action dated Feb. 10, 2017 in U.S. Appl. No. 14/993,786, 14 pages.
Non-Final Office Action dated Feb. 10, 2017 in U.S. Appl. No. 15/233,348, 7 pages.
Examiner's Answer dated Dec. 27, 2016 in U.S. Appl. No. 12/970,034, 4 pages.
European Office Action dated Feb. 13, 2017 in EP Patent App. No. 11847426.1, 7 pages.
Non-Final Office Action dated Apr. 14, 2017 in U.S. Appl. No. 15/098,321, 16 pages.
Notice of Allowance dated May 18, 2017 in U.S. Appl. No. 15/399,728, 7 pages.
Notice of Allowance dated Jun. 19, 2017 in U.S. Appl. No. 15/233,348, 11 pages.
Final Office Action dated Jun. 20, 2016 in U.S. Appl. No. 14/981,271, 9 pages.
Notice of Allowance dated Jun. 23, 2017 in U.S. Appl. No. 14/993,786, 9 pages.
Non-Final Office Action dated Oct. 26, 2012 in U.S. Appl. No. 12/967,761, 24 pages.
Non-Final Office Action dated Oct. 27, 2014 in U.S. Appl. No. 13/772,275, 14 pages.
Non-Final Office Action dated Nov. 6, 2013 in U.S. Appl. No. 12/960,730, 16 pages.
Non-Final Office Action dated Nov. 8, 2013 in U.S. Appl. No. 13/844,932, 6 pages.
Non-Final Office Action dated Dec. 7, 2016 in U.S. Appl. No. 14/981,271, 5 pages.
Non-Final Office Action dated Feb. 1, 2016 in U.S. Appl. No. 14/981,271, 8 pages.
Non-Final Office Action dated Feb. 26, 2016 in U.S. Appl. No. 14/600,477, 10 pages.
Non-Final Office Action dated Feb. 28, 2014 in U.S. Appl. No. 12/970,159, 22 pages.
Non-Final Office Action dated Mar. 31, 2015 in U.S. Appl. No. 14/318,380, 7 pages.
Non-Final Office Action dated Apr. 11, 2013 in U.S. Appl. No. 12/972,104, 15 pages.
Non-Final Office Action dated Apr. 14, 2011 in U.S. Appl. No. 11/726,862, 22 pages.
Non-Final Office Action dated Apr. 23, 2015 in U.S. Appl. No. 14/458,203, 10 pages.
Non-Final Office Action dated Apr. 5, 2012 in U.S. Appl. No. 11/726,862, 23 pages.
Non-Final Office Action dated May 23, 2014 in U.S. Appl. No. 12/748,829, 30 pages.
Non-Final Office Action dated May 23, 2014 in U.S. Appl. No. 12/960,730, 18 pages.
Non-Final Office Action dated May 30, 2013 in U.S. Appl. No. 12/970,034, 22 pages.
Non-Final Office Action dated Jun. 10, 2015 in U.S. Appl. No. 12/972,104, 10 pages.
Non-Final Office Action dated Jun. 18, 2014 in U.S. Appl. No. 12/960,753, 12 pages.
Non-Final Office Action dated Jun. 20, 2014 in U.S. Appl. No. 12/972,104, 10 pages.
Non-Final Office Action dated Jun. 23, 2010 in U.S. Appl. No. 11/726,862, 16 pages.
Non-Final Office Action dated Jun. 30, 2015 in U.S. Appl. No. 12/970,034, 26 pages.
Non-Final Office Action dated Jun. 9, 2014 in U.S. Appl. No. 12/970,069, 20 pages.
Non-Final Office Action dated Jul. 18, 2014 in U.S. Appl. No. 12/970,034, 24 pages.
Non-Final Office Action dated Jul. 29, 2016 in U.S. Appl. No. 14/993,786, 16 pages.
Non-Final Office Action dated Aug. 14, 2015 in U.S. Appl. No. 12/960,753, 16 pages.
Non-Final Office Action dated Aug. 14, 2013 in U.S. Appl. No. 12/967,638, 30 pages.
Non-Final Office Action dated Aug. 16, 2013 in U.S. Appl. No. 12/970,069, 26 pages.
Non-Final Office Action dated Aug. 18, 2016 in U.S. Appl. No. 12/972,104, 13 pages.
Non-Final Office Action dated Aug. 5, 2014 in U.S. Appl. No. 13/844,932, 7 pages.
Non-Final Office Action dated Aug. 9, 2012 in U.S. Appl. No. 12/748,829, 29 pages.
Non-Final Office Action dated Sep. 24, 2012 in U.S. Appl. No. 12/964,492, 10 pages.
Non-Final Office Action dated Sep. 29, 2014 in U.S. Appl. No. 12/748,829, 30 pages.
Non-Final Office Action dated Sep. 4, 2015 in U.S. Appl.No. 14/318,380, 6 pages.
Non-Final Office Action dated Sep. 6, 2012 in U.S. Appl. No. 12/972,230, 10 pages.
Notice of Acceptance dated Oct. 16, 2015 in AU Pat. App. No. 2011343943, 2 pages.
Notice of Allowance dated May 24, 2016 in JP Pat. App. No. 2013-544714, 3 pages.
Notice of Allowance dated Jul. 1, 2016 in RU Pat. App. No. 2013127235, 12 Pages w/o English Translation.
Notice of Allowance dated Sep. 2, 2016 in U.S. Appl. No. 12/960,753, 9 pages.
Notice of Allowance dated Jan. 7, 2016 in U.S. Appl. No. 14/318,380, 8 pages.
Notice of Allowance dated Oct. 19, 2015 in U.S. Appl. No. 13/772,275, 8 pages.
Notice of Allowance dated Oct. 27, 2016 in U.S. Appl. No. 14/600,477, 8 pages.
Notice of Allowance dated Oct. 28, 2015 in U.S. Appl. No. 14/333,386, 12 pages.
Notice of Allowance dated Oct. 8, 2015 in U.S. Appl. No. 12/970,069, 9 pages.
Notice of Allowance dated Nov. 12, 2014 in U.S. Appl. No. 13/844,932, 8 pages.
Notice of Allowance dated Nov. 20, 2012 in U.S. Appl. No. 12/972,230, 9 pages.
Notice of Allowance dated Dec. 26, 2013 in U.S. Appl. No. 12/972,230, 8 pages.
Notice of Allowance dated Feb. 19, 2014 in U.S. Appl. No. 13/844,932, 8 pages.
Notice of Allowance dated Mar. 10, 2014 in U.S. Appl. No. 12/972,230, 8 pages.
Notice of Allowance dated Mar. 20, 2013 in U.S. Appl. No. 12/964,492, 9 pages.
Notice of Allowance dated Mar. 20, 2015 in U.S. Appl. No. 12/970,069, 11 pages.
Final Office Action dated Sep. 29, 2017 in U.S. Appl. No. 15/098,321, 16 pages.
Hassan, Amer, “Universal Dock for Context Sensitive Computing Device”; U.S. Appl. No. 15/664,416, filed Jul. 31, 2017, including Preliminary Amendment filed Sep. 27, 2017; 49 pages.
Non-Final Office Action dated Sep. 15, 2017 in U.S. Appl. No. 14/975,818, 8 pages.
Non-Final Office Action dated Sep. 29, 2017 in U.S. Appl. No. 12/972,104, 17 pages.
Office Action dated Aug. 3, 2017 in KR Pat. App. No. 10-2013-7015396, 4 pages, including English Summary.
“Notice of Allowance Issued in Chinese Patent Application No. 201110400472.2”, dated Oct. 22, 2015, 4 Pages.
“Supplementary Search Report Issued in European Patent Application No. 11848261.1”, dated May 24, 2017, 8 Pages.
Decision on Appeal dated Jan. 8, 2018 in U.S. Appl. No. 12/970,034, 9 pages.
Non-Final Office Action dated Nov. 16, 2017 in U.S. Appl. No. 15/664,416, 6 pages.
Notice of Allowance dated Jan. 24, 2018 in U.S. Appl. No. 14/975,818, 8 pages.
Office Action dated Jan. 22, 2018 in KR Pat. App. No. 10-2013-7015189, 13 pages, including English Translation.
“Office Action Issued in Canadian Patent Application No. 2,821,338”, dated Oct. 25, 2017, 6 Pages.
Appleyard, David, “4 Ways to Monitor Bandwidth Usage on Your Mac Usage”, Retrieved from <>, Jul. 9, 2010, 2 Pages.
Non-Final Office Action dated Nov. 3, 2017 in U.S. Appl. No. 14/981,271, 6 pages.
Purdy, Kevin, “How to Keep Track of Your Cellphone Data Usage”, Retrieved from <>, Jun. 8, 2010, 12 Pages.
“Final Office Action Issued in U.S. Appl. No. 15/664,416”, dated Apr. 24, 2018, 15 Pages.
“Notice of Allowance Issued in U.S. Appl. No. 14/981,271”, dated Apr. 4, 2018, 8 Pages.
“Office Action Issued in Korean Patent Application No. 10-2013-7015189”, dated May 21, 2018, 2 Pages. (Without English Translation).
“Notice of Allowance Issued in Korean Patent Application No. 10-2013-7015396”, dated Dec. 28, 2017, 7 Pages.
“Non Final Office Action Issued in U.S. Appl. No. 15/664,416”, dated Aug. 7, 2018, 17 Pages.
“Non Final Office Action Issued in U.S. Appl. No. 16/037,916”, dated Oct. 17, 2018, 9 Pages.
“Notice of Allowance Issued in Russian Patent Application No. 2013127116”, dated Jan. 14, 2016, 7 Pages.
“Office Action Issued in European Patent Application No. 11848261.1”, dated Nov. 22, 2018, 4 Pages.
“Office Action Issued in Indian Patent Application No. 4191/CHENP/2013”, dated Dec. 11, 2018, 6 Pages.
“Apndroid API”, Retrieved from https://code.google.com/archive/p/apndroid/wikis/API.wiki, Jul. 15, 2019, 4 Pages.
“Bandwidth Monitor 3.4 build 757”, Retrieved from https://scloud.ws/blog/lan/2895.html, Jul. 15, 2019, 1 Page.
“Notice of Allowance Issued in U.S. Appl. No. 16/037,916”, dated Aug. 7, 2019, 8 Pages.
Cosand, Holly, “Wi-Fi Protected Access (WPA) Security and Exploits”, Retrieved from https://courses.cs.washington.edu/courses/csep590/06wi/finalprojects/cosand.doc, Mar. 7, 2006, 6 Pages.
“Final Office Action Issued in U.S. Appl. No. 15/664,416”, dated Mar. 22, 2019, 12 Pages.
“Non Final Office Action Issued in U.S. Appl. No. 16/037,916”, dated Apr. 11, 2019, 10 Pages.
“Office Action Issued in Indian Patent Application No. 4338/CHENP/2013”, dated Sep. 30, 2019, 6 Pages.
“Hearing Notice Issueed in Indian Patent Application No. 4191/CHENP/2013”, dated Nov. 22, 2019, 02 Pages.

Related Publications (1)

	Number	Date	Country
	20170127282 A1	May 2017	US

Continuations (2)

	Number	Date	Country
Parent	14600477	Jan 2015	US
Child	15409383		US
Parent	12970159	Dec 2010	US
Child	14600477		US

Secure protocol for peer-to-peer network

Information

Patent Number

Date Filed

Date Issued

Inventors

Original Assignees

Examiners

Agents

CPC

Field of Search

US

International Classifications

Disclaimer

Abstract