Patent Application
20080081608
The present invention relates to a dual-function, NFC-capable portable communication device. The user may employ the NFC-capable portable communication device to communicate voice and/or data with one or more remote parties via a wireless communication network. The user may also use the device as a “smartcard” or “keycard” to gain entry to a building or unlock door, or as a Point-of-Sale (PoS) device to purchase items from a merchant, for example. Typically, such dual-function NFC-capable devices transfer user data, such as financial data and proof of identity or authorization, to an external NFC device when the two devices are placed in close physical proximity with each other. In addition to transferring this user data, however, the present invention configures the dual-function devices to also transfer detailed diagnostic data to a remote server via the external NFC device, and to receive data and instructions from a remote server via the external NFC device. The diagnostic data may comprise information related to the communications functions of the device that service providers and/or manufacturers can use, for example, to troubleshoot problems and establish a baseline operation for the device.
Portable wireless communication device 10 comprises a user interface (UI) 12 and a communication circuit 14 disposed within a housing 40. UI 12 includes a display 16, a keypad 18, a speaker 20, and a microphone 22. Communication circuit 14 comprises a controller 24, an audio I/O circuit 26, memory 28, and a long-range transceiver circuit 32 connected to an antenna 34. The operation of the UI 12 and the communication circuit 14 with respect to communicating with a remote party is well known in the art. Therefore, this functionality is not described in detail herein. It is sufficient for the purposes of the present invention to understand that the device 10 is a fully functional cellular radio device capable of operating according to any known standard. Such standards include, but are not limited to, Global System for Mobile Communications (GSM), Universal Mobile Telecommunication System (UMTS), TIA/EIA-136, Code Division Multiple Access (CDMA), cdmaOne, cdma2000, and Wideband CDMA.
In addition to the components that facilitate long-range communications, device 10 also comprises a Near Field Communication (NFC) interface 30. Near Field Communication is a short-range wireless connectivity technology that uses magnetic field induction to permit devices to share information with each other. Usually, NFC devices operate at a frequency of 13.56 MHz and may transfer data at rates up to 424 Kbs; however, data transfer rates of up to 2 Mbps and above may soon be possible. Communication between two NFC-capable devices occurs when they are brought into contact with each other, or within close physical proximity of one another. The distance separating two NFC-capable devices can be anywhere between about 0 and 4 centimeters; however, the distance can be up to about 20 centimeters.
Near Field Communication technology is known in the art, therefore, only a brief description of this technology appears here for context. However, interested readers can learn more about NFC technology by reading any of the specifications available from the NFC Forum (http://www.nfc-forum.org). Currently, there are four specification documents available standardizing this technology. These are, the “NFC Data Exchange Format (NDEF) Technical Specification,” the “NFC Record Type Definition (RTD) Technical Specification,” the “NFC Text RTD Technical Specification,” and the “NFC URI RTD Technical Specification.” Each of these documents was released as version 1.0 on Jul. 24, 2006.
The NFC interface 30 may comprise, for example, a “tag” or chip, and may or may not include its own internal power supply. NFC interface 30 may also draw power from a battery (not shown) of device 10. Those NFC interfaces 30 having their own power supply draw power are termed “active” devices, while those NFC interfaces 30 that do not include their own power supply are termed “passive” devices. Passive NFC interfaces utilize a magnetic field radiated by an “active” NFC device, such as an NFC reader, for power. Once the device 10 is close enough to the NFC device, the energy from the magnetic field powers the NFC interface 30 so that it can establish the NFC link and communicate data.
In one embodiment, NFC interface 30 comprises an “active” transceiver circuit capable of communicating data to/from a corresponding NFC-capable device. To conserve power, the NFC interface 30 may operate in a “tag emulation” mode. In this mode, the NFC interface 30 “sleeps” until it detects magnetic energy from an external NFC device. Detecting the magnetic energy triggers the NFC interface 30 to “wake up.” The NFC interface 30 may then operate like a programmable tag to communicate data to/from the external NFC device.
In other embodiments, the NFC interface 30 comprises an active device such that it powers other passive NFC devices. In these embodiments, the magnetic field generated by the NFC interface 30 activates other “passive” NFC devices or NFC devices operating in a tag emulation mode. In still other embodiments, the NFC interface 30 is an active device that operates in a “peer” mode with other external NCF devices. In the peer mode, both the NFC interface 30 and the external NFC device may be active devices. Once the two devices are placed within close physical proximity of each other, the data exchange between the two devices is bi-directional.
As previously stated, device 10 may be configured to collect and store diagnostics data for download to another NFC-capable device. Therefore, an application program 36 that monitors the communication functions of device may be stored in memory 28. Controller 24 may execute instructions according to the application program 36 to collect diagnostics data over time or responsive to a predetermined event. For example, controller 24 may increment a counter whenever the device 10 experiences a dropped call. Controller 24 may store the collected diagnostics data 38 in memory 26 for later retrieval and download via the NFC interface 30, as described in more detail later.
NFC network 70 comprises an NFC reader 72 that connects to an IP network 76 such as the Internet, and a server 78. “Swiping” or contacting the NFC reader 72 with device 10 establishes an NFC link 74 as previously described. In embodiments where the user employs device 10 as a keycard, the NFC reader 72 receives ID codes or other user data from the device 10 and transfers that data to the server 78. The NFC reader may transmit the data to the server 78 via a local connection or the IP network 76. The server 78 may validate the received data and, if valid, generates a control signal to an access function 80. The access function 80 may, for example, unlock a door for the user or allow the user entry through a turnstile.
In other embodiments, the NFC reader 72 may send the received user data to one or more external servers via the IP network 76. For example, where NFC reader 72 comprises part of a PoS system, the NFC reader 72 may receive a user account number, credit card number, a merchant identifier, and the desired amount of the transaction over the NFC link 74. The NFC reader 72 sends this data to a server 82 associated with a bank or other financial institution. Depending upon the validity of this data and/or the availability of user funds, the bank server 82 will return a message to the NFC reader 72 either denying or confirming the requested transaction.
According to the present invention, device 10 is also configured to “passively” transfer all or portions of the diagnostics data stored in memory 28 whenever the user employs the device 10 to unlock a door or purchase an item, for example. That is, no explicit user interaction is required to download the diagnostic data other than bring the device 10 into close physical proximity of the NFC reader 72. This permits a service provider or manufacturer to periodically collect diagnostics data collected by device 10 with minimal inconvenience to the user.
As seen in method 90 of
In one embodiment, the authentication process comprises a bi-directional challenge/response process by which the device 10 and a remote server authenticate each other. Particularly, the device 10 sends a challenge to a remote server via the NFC device 72. The server may then respond to the challenge via the NFC device 72 with a valid authentication code, and may include a challenge of its own with the response. If the device 10 determines that the received response is an invalid authentication code (box 98), the device 10 may disconnect from the NFC device 72 (box 110). Otherwise, the controller 24 may cause the NFC interface 30 to send an ID of device 10 to the server in response to the challenge sent by the server (box 100). The ID sent by device 10 may be any indicator or identifier known in the art such the telephone number of the device 10. The server would check the response and, if valid, return instructions to device 10 via the NFC reader 72 for downloading the diagnostics data stored in memory 28 to the NFC reader 72 (box 102).
The instructions sent by the NFC reader 72 may comprise a command having one or more parameters that causes controller to access and download all or selected portions of the stored diagnostics data to the NFC reader 72. For example,
At some point, the NFC interface 30 may receive a command from NFC reader 72 to delete the diagnostics data from memory 28 (box 106). This may occur, for example, during the diagnostics data transfer (e.g., when a user removes the device 10 from within the proximity of NFC reader 72), or after the device 10 has completed transferring the diagnostics data to NFC reader 72. The command may identify which portions of the data were successfully received. The controller 24 could delete those identified portions of the diagnostics data and maintain the remaining portions in memory 28 to be downloaded later (box 108). Then, the NFC interface 30 may disconnect from the NFC reader 72.
It should be noted that the present invention is not limited to the authentication process previously described. Rather, the present invention may employ any authentication process known in the art. In addition, some embodiments of the present invention do not require direct authentication between the device 10 and the server prior to transferring diagnostics data. In one embodiment, for example, the NFC reader 72 includes sufficient logic and resources to perform the authentication process without connecting to a remote server. In these cases, the NFC reader 72 could, upon successful authentication, communicate data to/from device 10. Later, the NFC reader 72 could transfer the diagnostics data to an appropriate server, which may or may not include another authentication process between the NFC reader 72 and the server.
In other embodiments not requiring user interaction, the user may employ device 10 to conduct a transaction with an NFC-enabled PoS system. In these cases, the device 10 would transfer user data relating to an intended purchase or transaction to NFC reader 72. For example, the NFC reader 72 may transfer data to the device 10 relating to the transaction and possible settlement options. Device 10 could then reply with data identifying a particular settlement option (e.g., pay with a credit card, debit card, e-coupon, etc.). The NFC reader 72 would then communicate this user data to a server 82 for processing the settlement of the transaction. The NFC reader 72 could also receive the diagnostics data from device 10, and forward it to one or more of the servers 82, 84, 86 as previously described.
In addition to these passive downloads, the present invention also contemplates an embodiment wherein the NFC reader 72 comprises a dedicated diagnostics data collector. The service provider's and/or the manufacturer's servers 84, 86, could connect to such dedicated NFC devices 72 via the Internet or other IP network. In these cases, the service providers and/or the manufacturers could collect and store the downloaded diagnostics data directly, and analyze the data as needed or desired.
Method 120 of
As in the previous embodiments, using NFC reader 72 to transfer the authentication information between device 10 and remote server 84, 86 is not required. In other embodiments, NFC reader 72 may perform the authentication process without the server 84, 86.
As can be seen from the above embodiments, the present invention allows service providers, manufacturers, or other entities granular control over the diagnostics collection abilities of device 10. Further, the present invention allows these entities to exert this control over many devices 10 generally, or over one or more specifically identified devices 10.
Method 140 begins when the NFC reader 72 detects the presence of device 10 and establishes the NFC link (box 142). After receiving the unique identifier of the device 10 over the NFC link 74 (box 144), the NFC reader 72 may request instructions from the appropriate server 84, 86 (box 146). The NFC device 72 could include the received unique identifier in the instruction request such that the appropriate server 84, 86 return instructions and/or parameters specifically intended for that device 10. As stated above, the requested instructions may include commands or parameters for specific diagnostic information from device 10. However, the instructions may also include other data that is to be uploaded to device 10 via NFC reader 72. Such data includes, but is not limited to, new application logic and new parameters for the controller 24 to monitor. The NFC device 72 may then upload the instructions and/or data to device 10 (box 148), and receive diagnostics data (box 150) as previously described. The NFC reader 72 then forwards the received diagnostics data to the appropriate server 84, 86 (box 152), and sends a delete command as previously described (box 154). The NFC reader 72 then disconnect from the device 10 (box 156).
This ability to upload instructions and other data to device 10 via the NFC reader 72 permits the service provider and/or manufacturer to remotely control some relatively complex aspects of the diagnostics collection abilities of targeted devices 10 while minimizing user interaction. For example, uploading new application logic may facilitate control over how and when the device 10 monitors and collects diagnostic data. Likewise, new parameters may be sent so that the controller 24 can monitor aspects of the communications functions not typically monitored by device 10. For example, service providers and/or manufacturers may detect a pattern of errors by analyzing the downloaded diagnostics data for one or more particular devices 10. In response, to this data, these entities may send new parameters for device 10 to monitor that comprise elements designed to provide a more detailed picture of the device 10 or its interaction with the wireless network.
In the previous embodiments, the NFC reader 72 is described as communicating with one or more of the servers 82, 84, 86 at substantially the same time as the device 10 is downloading diagnostic data. However, this may result in an unacceptable delay in some cases by requiring the user to leave the device 10 in close physical proximity with the NFC reader 72 for an extended time. Therefore, the NFC reader 72 may be configured to collect and temporarily store the diagnostics data received from the device 10. Later, at a predetermined time for example, the NFC reader 72 could connect to an appropriate server 82, 84, 86, and transfer the diagnostics data stored in its memory. Transferring the diagnostics data in this “off-line” manner could reduce the length of time that the user must maintain the NFC link 74 with the NFC reader 72.
Likewise, one or more of the servers 82, 84, 86 can upload the application logic, parameters, and/or instructions to one or more NFC readers 72 “off-line” (e.g., before the device 10 establishes an NFC link 74 with the NFC reader 72). For example, one or both of the servers 84, 86 may determine from historical information that a specific device 10 normally establishes an NFC link 74 with a specific NFC reader 72 at a typical time of day (e.g., the user may use device 10 at a particular NFC reader to enter his work building every morning at 8:00 a.m.). The servers 84, 86 could upload that particular NFC reader 72 with logic, parameters, and/or instructions specially designated for that device 10. The next time the user reports to work, the NFC reader 72 simply uploads the logic and/or instructions to device 10 without having to request instructions from the servers 84, 86. This reduces the need to exchange messages between the NFC reader 72 and the servers 84, 86 while the NFC link 74 is established thereby reducing the length of time the user must maintain the NFC link 74.
Additionally, the previous embodiments illustrate the service providers and/or manufacturers having a direct communications link to the NFC readers 72 via a public or private IP network. However, this direct communications link is not required. In other embodiments, such as those associated with PoS systems, the NFC reader 72 transfers the diagnostic data received from the user's device 10 to a third party server such as server 82 associated with the financial institution. In addition to confirming or denying the user's transaction, server 82 may temporarily store the diagnostic data received from device 10. Provided the service providers and manufacturers have an agreement with the financial institution, servers 84, 86 may retrieve this diagnostic data at predetermined times.
The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.
