I. Field of the Invention
The present invention relates generally to authentication using audio tones.
II. Background of the Invention
As Internet use has grown, many types of convenient electronic commerce have been made possible, such as, for example, buying goods and services online, banking online, and using automatic teller machines (ATM) that are linked to remote banks. But the very convenience of electronic commerce has made it easier for thieves to steal valuable information and/or to pose as someone they are not to purchase goods, withdraw money from bank accounts, and so on.
Accordingly, affording security in electronic transactions is crucial. To this end, many electronic transactions are encrypted, to conceal private information being exchanged. But encryption is only one aspect of security, since it only provides confidentiality. Encryption does not authenticate the parties involved or ensure the integrity/authenticity of the information being exchanged.
With this in mind, it readily may be appreciated that authentication is an important aspect of security. In terms of electronic commerce, the person seeking authentication does so through a computer interface. Consequently, it normally is not feasible to resort to checking a biological feature of the person (appearance, handwritten signature, fingerprint, and so on) to verify that the person is who he says he is, absent the widespread installation of an infrastructure of bio-sensing computer accessories.
This leaves two authentication factors available, namely, authenticating a person based on something the person has, such as a credit card or key fob, or based on something the person knows, such as a password or personal identification number (PIN). For some particularly sensitive applications such as ATM money withdrawals, both factors might be desirable.
The above-identified patent applications disclose hand-held sonic-based “tokens” that a person can manipulate to transmit an acoustic signal to a device, referred to as an “authenticator” or “verifier”, to authenticate the person based on the signal. As recognized in those applications, the advantage of sonic-based tokens is that a large installed infrastructure already exists to receive and transmit sound and electronic signals derived from sound. Specifically, the global telephone system exists to transmit data representative of acoustic information, and apart from telephones many computing devices that are now linked by this same system (as embodied in the Internet) have microphones and speakers (or can easily be modified to have them).
In the above-disclosed systems, a user can manipulate a token to send an acoustic signal to a verifier, with the acoustic signal representing a digital signature generated by using a private key known only to the user's token. The verifier receives the signal, converts it to electrical signals, and then uses a public key associated with the private key to verify the signature. Use of public key-private key principles facilitates robustness, in that a single token can be used for multiple purposes, such as for building access, vehicle access, ATM access, and so on, without the possibility that, for example, an unscrupulous security guard having access to a list of tokens authorized for building access could gain entrance to a vehicle or bank account that grants authorization to a token that happens to be on the building access list. Without the private key provided by the token, authorization cannot be granted by a verifier.
As recognized herein, the verifier can be controlled by a central computer that contains an access list used to verify a user's identity, based on the sonic signal received from a token. An example of such a verifier might be a building entrance verifier that allows entry into one or more buildings in a complex of buildings. To add or delete users from the access list, one need simply to modify the centrally-located list.
As also recognized herein, however, for certain other applications such as vehicle entry or home entry, verification is done at the location of the verifier, e.g., at the car or home. In these applications, adding or deleting a user from an access list can be more of a problem, because the verifier might not include a data entry device. Moreover, the present invention further recognizes that while it is desirable to enable a single token to be used to gain access to multiple verifiers, two closely located verifiers might receive the sonic activation signal and both grant access, when the user desires only access to one. For example, if a user has two vehicles parked in a driveway, both of which grant access based on a sonic token, it is desirable that the user be able to gain access to one of the vehicles without also unlocking the other vehicle, the front door of the house, etc. Having recognized these considerations, the invention described below is provided.
The present invention understands that authentication and authorization are related but different aspects of electronic security. Authentication establishes the user's identity, whereas authorization refers to permissions that the user has. After being authenticated, the user must still select one or more of the authorized functions to perform. That is one of the problems addressed herein.
As discussed in further detail below, one way to accomplish the above, is by using separate dedicated keys for each function. In this case, the authorization is implicitly accomplished by authentication. Another way recognized herein is for the message generated by the token to include a function identifier that specifies the requested function. In either case, the token must allow the user to specify either the key to use or function to request.
A still different approach is to select the desired function directly on the verifier, as also discussed herein. For example, the token can be used to log into a computer on which the user has multiple accounts, with the computer prompting the user to select or otherwise indicate the desired account.
As further recognized herein, a related problem is that the authorization details for each user must be programmed into the verifier. If the verifier has a convenient interface and staff assigned to program it, then the problem is simple. However, if the verifier is intended to be a standalone verifier and must be programmed by the owner directly (e.g., when the verifier is a vehicle), the verifier has a user management function and indicates a user authorized to use it. In case of a verifier with a centralized programming interface, the mere fact that one has physical access to it may provide the necessary authorization credentials (although an additional password would be more likely).
For standalone verifier, however, there are two basic problems to solve: getting authorization to perform the programming, and performing the actual programming. The first problem is fairly straightforward. If the verifier has been programmed to allow certain users to program it, then those users can authenticate and choose the programming function as described below.
The second part is somewhat more involved. Adding a new user to the verifier is easy since all that needs to be done is for the token to output its public key and current timestamp and for the manager to specify which functions this new user is authorized to perform.
Accordingly, a system for authentication includes a token that is operable to generate an acoustic signal. The token has at least one key identifier, such as a public key of a private key/public key pair. Plural verifiers are configured for receiving the acoustic signal and in response thereto accessing respective data structures that represent identities of authorized tokens to selectively grant access to respective components. Means are coupled to the token and/or to a verifier for adding the key identifier to the data structure that is associated with the verifier. The verifier can also access the public key corresponding to the token and a token clock value.
In an exemplary embodiment the means for adding may include means for inputting an addition request to the verifier, and means for causing the verifier to transmit a first signal that alerts the user that the verifier is ready to receive the key identifier. Means on the token are operable by a user to transmit the key identifier in an acoustic signal. If desired, means can be provided at the verifier for transmitting an acknowledgement signal that the key identifier has been successfully added to the data structure, which can be a list, database table, or other structure.
In another aspect, a system for authentication includes a token that can be operated to generate an acoustic signal. Plural verifiers are configured for receiving the acoustic signal and in response thereto accessing respective data structures representing identities of authorized tokens to selectively grant access to respective components. Means are coupled to the token and/or to a verifier for removing the key identifier from the data structure associated with the verifier.
In an exemplary embodiment, the means for removing may include means on the token for inputting a removal request to the verifier, and means for removing the key identifier from the data structure in response to the removal request. Or, the means for removing may include means for retrieving a recording of the key identifier, and means accessing the recording to remove the key identifier from the data structure. Still further, if neither the token nor recording are available, means can be provided for associating an audio label with the token, with means facilitating removal of the key identifier from the list based on the audio label.
In still another aspect, a method for authentication includes transmitting a public key identifier associated with a token in an acoustic signal to a verifier. The method also includes adding the key identifier to a data structure that is accessible to the verifier, with the data structure representing identities of authorized tokens. An acoustic signal is generated from the token. The signal is associated with a private key identifier. The acoustic signal is received at the verifier and in response thereto the data structure is accessed to selectively grant access to a component.
In yet another aspect, a method for authentication includes adding a key identifier to a data structure that is accessible to a verifier, with the key identifier identifying a token. The method includes selectively granting access to a component associated with the verifier in response to acoustic authorization signals from the token, and then selectively removing the key identifier from the data structure.
In another aspect, an authentication system includes a token configured for generating at least first and second acoustic signals, with each signal representing a private key-generated digital signature. A first verifier is configured for receiving acoustic signals and granting authorization to the user upon receipt of the first acoustic signal but not upon receipt of the second acoustic signal. Also, a second verifier is configured for receiving acoustic signals and granting authorization to the user upon receipt of the second acoustic signal but not upon receipt of the first acoustic signal.
In another aspect, a method is disclosed for selectively granting authorization to a bearer of a token to one of plural verifiers. The method includes establishing a keyword for each verifier, and gaining authorization access from a verifier. The access is gained by speaking the keyword associated with the verifier and operating an activation element on the token to generate an acoustic authorization request receivable by the verifier. Authorization is selectively granted, based on the keyword and acoustic authorization request.
In another aspect, an authorization system includes plural tokens, with each generating a unique acoustic authorization request. The tokens are stackably engageable with each other.
The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:
Referring initially to
In any case, the token 12 can generate an acoustic signal, represented schematically by the lines 14, that can be received by a verifier 16. The verifier 16 selectively grants access to a component 18, based on the acoustic signal 14. The component 18 may be a building, a home, a vehicle, an ATM, or any other component to which it is desired to limit access to pre-authorized users.
The acoustic signal 14 can represent a digital signature generated by a private key stored in an electronic data store 20 of the token 12. Corresponding public keys can also be stored therein for purposes to be shortly disclosed. In accordance with private key/public key principles known in the art and set forth in, e.g., the National Institute for Standards and Technology (NIST) Federal Information Processing Standards Publication 186-2, January, 2000, the signature algorithm in the token 12 (executed by a microprocessor 22 within the token 12) combines the private key with the message to be signed and with a random number “k” from a PN generator associated with the microprocessor 22 to render a digital signature which is a random pair (r,s). The identification of the corresponding public key may also be transmitted along with the digital signature.
The microprocessor 22 receives activation signals from, e.g., one or more activation elements 24 such as toggle switches, voice activation devices, or pushbuttons. It is to be understood that the microprocessor 22 can include a digital processor proper as well as necessary analog to digital and digital to analog conversion circuitry known in the art.
The microprocessor 22 accesses the data store 20, such that when multiple activation elements 24 are used, one or more can be associated with a respective key in the store 22. An electronic signature signal generated by using the particular key associated with the activation element that has been manipulated is sent to an audio speaker 26 for transformation of the electronic signal to the acoustic signal 14. The acoustic signal may or may not be audible. If desired, a microphone 28 can also be provided on the token 12 to receive acoustic signals and transform them to electronic signals, which are sent to the microprocessor 22 for processing.
The acoustic signal 14 is received by a microphone or other acoustic receiving device 30 at the verifier 16. The acoustic signal is transformed by the microphone 20 to an electronic signal and sent to a microprocessor 32, which accesses a data store 34 to retrieve from a data structure such as a list or database table the public key associated with the private key that generated the signal. Alternatively, the microprocessor 32 and data store 34 can be located centrally, away from the verifier, e.g., the microprocessor 32 and data store 34 can be located at the component 18. In any case, using the public key, the microprocessor 32 verifies the signature from the token 12 and based thereon, grants access to the user of the token 12 provided the token 12 is on an access data structure such as a list or database table in the data store 34. If desired, a speaker 36 can also be provided on the verifier 16 to send acoustic signals back to the token 12, which signals are received by the microphone 28 on the token 12.
Now referring to
When using the token 12 or a management token to undertake the logic of
At block 64, the verifier receives the request to add signal and when it is ready to receive the key identifier, transmits back an “OK” beep or other acoustic signal or visual signal that the user can hear (or see) to alert the user that the verifier is ready to receive the key identifier. Moving to block 66, the user manipulates one of the above-described input device mechanisms to acoustically transmit to the verifier the identifier associated with the token's key or keys. The identifier can be or can include, e.g., the public key of the token. If desired, the verifier can transmit back an acknowledgement signal at block 68, signifying that the token has been added to the access list. The acknowledgement signal can be audible, or visual, or other appropriate signal such as a tactile signal that might be generated by the token in response to a signal from the verifier. The verifier preferably accesses the public key of a token on its list as well as a token clock value as set forth in the above-referenced applications.
On the other hand, if the token sought to be removed is lost, stolen, or otherwise unavailable, decision diamond 78 simply indicates that if a recording of the public key of the token, or indeed of a previous authorization session with the token is available, it is provided to the verifier at block 80 by, e.g., playing back an acoustic version of the recording in range of the microphone of the verifier, or by sending an electronic signal representing the recording of the public key to the verifier through any suitable communication interface. At block 82, the user requests that the public key (and, hence, the token) be removed from the access list by, e.g., manipulating or causing to be manipulated an input device associated with the verifier. Proceeding to block 84, the verifier removes the public key from its access list and if desired sends an acoustic acknowledgement message to the person requesting removal.
In contrast, if the token sought to be removed is unavailable and no recording of the public key is available, at block 86 a recorded audio label representing the token can be played back or otherwise displayed in response to the user inputting a request for removal in accordance with input principles discussed above. In one exemplary embodiment, when a token is added to the list of a verifier, the user or verifier manager can speak the label (e.g., the user's name) into the microphone of the verifier so that the verifier can associate the label with the key identifier (e.g., the public key). Then, when the user or manager desires to remove the token (as represented by the token's key or keys) from the access list, the label is spoken or otherwise input to the verifier, where it is correlated with the key identifier at block 88. The logic then flows to block 82 and removes the key identifier from the access list as described above.
In the case of the token 40 shown in
While the particular SYSTEM AND METHOD FOR MANAGING SONIC TOKEN VERIFIERS as herein shown and described in detail is fully capable of attaining the above-described objects of the invention, it is to be understood that it is the presently preferred embodiment of the present invention and is thus representative of the subject matter which is broadly contemplated by the present invention, that the scope of the present invention fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope of the present invention is accordingly to be limited by nothing other than the appended claims, in which reference to an element in the singular is not intended to mean “one and only one” unless explicitly so stated, but rather “one or more”. All structural and functional equivalents to the elements of the above-described preferred embodiment that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the present invention, for it to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. No claim element herein is to be construed under the provisions of 35 U.S.C. §112, sixth paragraph, unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited as a “step” instead of an “act”.
This application is related to co-pending U.S. patent application Ser. No. 10/077,365, filed Feb. 15, 2002, for an invention entitled “Method and Apparatus for Simplified Audio Authentication”, is related to co-pending U.S. patent application Ser. No. 09/611,569, filed Jul. 7, 2000, for an invention entitled “Method and Apparatus for Simplified Audio Authentication”, and to co-pending U.S. provisional patent application Ser. No. 60/380,651, filed May 15, 2002, for an invention entitled “System and Method for Managing Sonic Token Verifiers”, all of which are incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
4305143 | Simms et al. | Dec 1981 | A |
4601011 | Grynberg | Jul 1986 | A |
4961142 | Elliott et al. | Oct 1990 | A |
5196840 | Leith et al. | Mar 1993 | A |
5200993 | Wheeler et al. | Apr 1993 | A |
5422953 | Fischer | Jun 1995 | A |
5481611 | Owens et al. | Jan 1996 | A |
5561710 | Helms | Oct 1996 | A |
5613004 | Cooperman et al. | Mar 1997 | A |
5623637 | Jones et al. | Apr 1997 | A |
5696879 | Cline et al. | Dec 1997 | A |
5745555 | Mark | Apr 1998 | A |
5757918 | Hopkins | May 1998 | A |
5784464 | Akiyama et al. | Jul 1998 | A |
5802176 | Audebert | Sep 1998 | A |
5892900 | Ginter et al. | Apr 1999 | A |
5953700 | Kanevsky et al. | Sep 1999 | A |
5983347 | Brinkmeyer et al. | Nov 1999 | A |
6018739 | McCoy et al. | Jan 2000 | A |
6023676 | Erell | Feb 2000 | A |
6084967 | Kennedy et al. | Jul 2000 | A |
6130859 | Sonnenschein et al. | Oct 2000 | A |
6157820 | Sourour et al. | Dec 2000 | A |
6188717 | Kaiser et al. | Feb 2001 | B1 |
6213391 | Lewis | Apr 2001 | B1 |
6216231 | Stubblebine | Apr 2001 | B1 |
6236724 | Labaton et al. | May 2001 | B1 |
6272176 | Srinivasan | Aug 2001 | B1 |
6275934 | Novicov et al. | Aug 2001 | B1 |
6282522 | Davis et al. | Aug 2001 | B1 |
6297795 | Kato et al. | Oct 2001 | B1 |
6327314 | Cimini, Jr. et al. | Dec 2001 | B1 |
6327578 | Linehan | Dec 2001 | B1 |
6343049 | Toda | Jan 2002 | B1 |
6389055 | August et al. | May 2002 | B1 |
6397368 | Yonge, III | May 2002 | B1 |
6408388 | Fischer | Jun 2002 | B1 |
6460138 | Morris | Oct 2002 | B1 |
6463537 | Tello | Oct 2002 | B1 |
6505160 | Levy et al. | Jan 2003 | B1 |
6553494 | Glass | Apr 2003 | B1 |
6594705 | Philyaw | Jul 2003 | B1 |
6607136 | Atsmon et al. | Aug 2003 | B1 |
6615171 | Kanevsky et al. | Sep 2003 | B1 |
6768778 | Chen et al. | Jul 2004 | B1 |
6778828 | Chander et al. | Aug 2004 | B1 |
6889209 | Rabin et al. | May 2005 | B1 |
7093131 | Kobayashi | Aug 2006 | B1 |
7146500 | Hawkins et al. | Dec 2006 | B2 |
7181621 | Labaton | Feb 2007 | B2 |
7251730 | Rose | Jul 2007 | B2 |
7349481 | Steentra et al. | Mar 2008 | B2 |
7401224 | Gantman et al. | Jul 2008 | B2 |
7433452 | Taylor et al. | Oct 2008 | B2 |
7487362 | Steenstra et al. | Feb 2009 | B2 |
7533735 | Gantman et al. | May 2009 | B2 |
7575177 | Killian et al. | Aug 2009 | B2 |
7606760 | Hutchison et al. | Oct 2009 | B2 |
7966497 | Gantman et al. | Jun 2011 | B2 |
8391480 | Steenstra et al. | Mar 2013 | B2 |
8510228 | Lu et al. | Aug 2013 | B2 |
20010021980 | Linden et al. | Sep 2001 | A1 |
20010039619 | Lapere et al. | Nov 2001 | A1 |
20010055352 | Bannasch et al. | Dec 2001 | A1 |
20020095587 | Doyle et al. | Jul 2002 | A1 |
20020114270 | Pierzga et al. | Aug 2002 | A1 |
20020122465 | Agee et al. | Sep 2002 | A1 |
20020141575 | Hird | Oct 2002 | A1 |
20020154772 | Morishita et al. | Oct 2002 | A1 |
20020184526 | Bender et al. | Dec 2002 | A1 |
20020191765 | Labaton | Dec 2002 | A1 |
20030026197 | Crawford | Feb 2003 | A1 |
20030028770 | Litwin, Jr. et al. | Feb 2003 | A1 |
20030055892 | Huitema et al. | Mar 2003 | A1 |
20030212549 | Steentra et al. | Nov 2003 | A1 |
20050047514 | Bolinth et al. | Mar 2005 | A1 |
20050228720 | Pavlic et al. | Oct 2005 | A1 |
20050229009 | Fujii et al. | Oct 2005 | A1 |
20090141890 | Steenstra et al. | Jun 2009 | A1 |
20110191253 | Pilskalns | Aug 2011 | A1 |
20110270764 | Mizani Oskui | Nov 2011 | A1 |
20120173433 | Park et al. | Jul 2012 | A1 |
20130185214 | Azen et al. | Jul 2013 | A1 |
Number | Date | Country |
---|---|---|
1263324 | Aug 2000 | CN |
0374012 | Jun 1990 | EP |
1211836 | Jun 2002 | EP |
1349031 | Oct 2003 | EP |
2753860 | Mar 1998 | FR |
2360618 | Sep 2001 | GB |
3214834 | Sep 1991 | JP |
7254897 | Oct 1995 | JP |
9502038 | Feb 1997 | JP |
10134157 | May 1998 | JP |
11289324 | Oct 1999 | JP |
11316740 | Nov 1999 | JP |
2000508099 | Jun 2000 | JP |
2000224156 | Aug 2000 | JP |
2000235340 | Aug 2000 | JP |
2000284689 | Oct 2000 | JP |
2001007802 | Jan 2001 | JP |
2001203688 | Jul 2001 | JP |
2001265217 | Sep 2001 | JP |
2001285286 | Oct 2001 | JP |
2001309159 | Nov 2001 | JP |
2003500957 | Jan 2003 | JP |
2005518721 | Jun 2005 | JP |
2006528391 | Dec 2006 | JP |
9506371 | Mar 1995 | WO |
WO9724857 | Jul 1997 | WO |
WO9731437 | Aug 1997 | WO |
9736264 | Oct 1997 | WO |
WO9813971 | Apr 1998 | WO |
WO9825220 | Jun 1998 | WO |
WO9929058 | Jun 1999 | WO |
WO0021020 | Apr 2000 | WO |
WO0110071 | Feb 2001 | WO |
WO0111575 | Feb 2001 | WO |
WO0116140 | Mar 2001 | WO |
0131594 | May 2001 | WO |
WO0158080 | Aug 2001 | WO |
WO0161640 | Aug 2001 | WO |
WO0171590 | Sep 2001 | WO |
WO 0205078 | Jan 2002 | WO |
WO0213455 | Feb 2002 | WO |
WO0217530 | Feb 2002 | WO |
WO0219590 | Mar 2002 | WO |
WO2011112158 | Sep 2011 | WO |
Entry |
---|
Australian OA dated May 14, 2009 for AU Patent Application No. 2004262288, 2 pages. |
Chilean Office Action mailed Sep. 3, 2010 for CL Application Serial No. 0283-03, 6 pages. |
Chinese OA dated Jan. 10, 2011 for CN Patent Application No. 200480021026.9, 7 pages. |
European OA dated Sep. 21, 2006 for EP Patent Application No. 03 716 025.6-2221, 6 pages. |
International Search Report—PCT/US2003/015633—International Search Authority, European Patent Office, Jul. 23, 2003. |
Japanese OA dated Aug. 10, 2010 for JP Patent Application No. 2006-521236, 3 pages. |
Korean OA dated Jan. 18, 2011 for KR Patent Application No. 2006-7001477, 3 pages. |
Miyoshi, Preliminary Design of OFDM and CDMA—../IEEE Explore Jan. 23, 20, 4 pages. |
OA dated Oct. 15, 2009 for Chinese Patent Application Serial No. 03807031.6, 11 pages. |
OA dated Oct. 28, 2009 for U.S. Appl. No. 10/139,873, 49 pages. |
OA dated Nov. 4, 2009 for European Patent Application Serial No. 02798566.2, 26 pages. |
OA dated Dec. 10, 2008 for U.S. Appl. No. 10/139,873, 10 pages. |
OA dated May 28, 2009 for U.S. Appl. No. 101139,873, 39 pages. |
OA dated Jun. 23, 2009 for European Patent Application Serial No. 03742418.1, 5 pages. |
OA dated Jul. 22, 2009 for European Patent Application Serial No. 02798566.2, 8 pages. |
OA dated Aug. 14, 2009 for Chinese Patent Application Serial No. 02828136.5, 3 pages. |
OA dated Aug. 19, 2010 for U.S. Appl. No. 10/139,873, 38 pages. |
OA dated Aug. 21, 2009 for European Patent Application Serial No. 03742418.1, 4 pages. |
OA dated Sep. 30, 2009 for Korean Patent Application Serial No. 10-2004-7009836, 3 pages. |
OA dated Jan. 9, 2009 from Chinese Application Serial No. 03807031.6, 17 pages. |
OA dated Jul. 16, 2010 for Colombian Patent Application Serial No. 04090727, 2 pages. |
OA dated Jun. 17, 2010 for Australian Patent Application Serial No. 2004262288, 3 pages. |
OA dated Jun. 3, 2010 for Canadian Patent Application Serial No. 2476485, 3 pages. |
OA mailed Jan. 9, 2009 for CN Patent Application Serial No. 03807031.6, 10 pages. |
OA mailed Apr. 6, 2008 for IN Patent Application Serial No. 244/CHENP/2006, 2 pages. |
OA mailed May 1, 2009 for IN Patent Application Serial No. 1801/CHENP/2004, 2 pages. |
OA mailed May 20, 2009 for EP Patent Application Serial No. 03716025.6, 7 pages. |
OA mailed May 6, 2009 for Chilean Patent Application Serial No. 0283-2003, 4 pages. |
OA mailed Jun. 23, 2008 for MX Patent Application Serial No. PA/a/2006/000801, 2 pages. |
OA mailed Jul. 1, 2009 for IL Patent Application Serial No. 163527, 4 pages. |
OA mailed Jul. 10, 2009 for CN Patent Application Serial No. 200480021026.9, 10 pages. |
OA mailed Jul. 11, 2008 for CN Patent Application Serial No. 03807031.6, 3 pages. |
OA mailed Jan. 9, 2009 for CN Patent Application Serial No. 02828136.5, 3 pages. |
OA mailed Nov. 9, 2007 for CN Patent Application Serial No. 03807031.6, 4 pages. |
OA mailed Dec. 24, 2007 for SG Patent Application Serial No. 200600213-3, 5 pages. |
OA mailed Feb. 18, 2009 for EP Patent Application Serial No. 03742418.1, 6 pages. |
OA mailed Apr. 16, 2007 for AU Patent Application Serial No. 2003219752, 1 page. |
OA mailed Apr. 29, 2008 for CN Patent Application Serial No. 02828136.5, 8 pages. |
OA mailed Apr. 2, 2009 for Japanese Patent Application Serial No. 2003-557137, 9 pages. |
OA mailed May 1, 2009 for CN Patent Application Serial No. 02828136.5, 8 pages. |
OA mailed Jun. 16, 2009 for Japanese Patent Application Serial No. 2003-570546, 5 pages. |
OA mailed Sep. 19, 2008 for CN Patent Application Serial No. 02828136.5, 7 pages. |
Supplementary European Search Report—EP03728996—Search Authority—Berlin—Jun. 29, 2007. |
Gerasimov V., et al., “Things that Talk: Using Sound for Device-to-Device and Device-to Human Communication,” IBM Systems Journal, 2000, vol. 39, No. 384, pp. 530-546. |
Imai, “Java Network Programming [Security Version], Let's Make a Secret Bulletin Board,” Software Design, No. 134, Japan, Gijitsu-HyohronCo., Ltd., Dec. 2001, pp. 26-37. |
International Search Report and Written Opinion—PCT/US2012/069420—ISA/EPO—Mar. 22, 2013. |
Number | Date | Country | |
---|---|---|---|
20090044015 A1 | Feb 2009 | US |
Number | Date | Country | |
---|---|---|---|
60380651 | May 2002 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 10172469 | Jun 2002 | US |
Child | 12172930 | US |