(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2002/0109580 A1
`Shreve et al.
`(43) Pub. Date:
`Aug. 15, 2002
`
`US 2002O10958OA1
`
`(54) WIRELESS UNIVERSAL PERSONAL
`ACCESS SYSTEM
`
`(76) Inventors: Gregory A. Shreve, Huntsville, AL
`S. Barry Dunbridge, Torrance, CA
`
`Correspondence Address:
`Patent Counsel
`TRW Inc.
`S&EG Law Department, E2/6051
`One Space Park
`Redondo Beach, CA 90278 (US)
`
`(21) Appl. No.:
`
`09/784,526
`
`(22) Filed:
`
`Feb. 15, 2001
`
`
`
`12
`
`Publication Classification
`(51) Int. Cl." ....................................................... H04Q 1700
`(52) U.S. Cl. ........................ 340/5.61; 713/201; 340/5.74
`(57)
`ABSTRACT
`The invention relates to a two-way bi-directional wireless
`based acceSS communication System that allows a user to
`acceSS any one of multiple independent Secured domain
`Systems from a single handheld remote keyleSS entry device,
`whereupon activation of the remote keyleSS device by the
`user, an encoded request Signal containing a predetermined
`acceSS code is generated and transmitted by the remote
`keyleSS entry device to one of the multiple Secure domain
`Systems. And, based on the acceSS code contained within the
`encoded request Signal, the domain System determines the
`validity of the acceSS code and transmits a corresponding
`encoded authorization signal to user at the transceiver
`device.
`
`-
`
`Authentication
`Algorithm
`
`Petitioner's Exhibit 1012, Page 1
`
`

`

`Patent Application Publication Aug. 15, 2002 Sheet 1 of 9
`
`US 2002/0109580 A1
`
`
`
`Petitioner's Exhibit 1012, Page 2
`
`

`

`Patent Application Publication Aug. 15, 2002. Sheet 2 of 9
`
`US 2002/0109580 A1
`
`
`
`ez eun61-I
`
`Petitioner's Exhibit 1012, Page 3
`
`

`

`Patent Application Publication Aug. 15, 2002. Sheet 3 of 9
`
`US 2002/0109580 A1
`
`
`
`
`
`Petitioner's Exhibit 1012, Page 4
`
`

`

`Patent Application Publication Aug. 15, 2002. Sheet 4 of 9
`
`US 2002/0109580 A1
`
`14
`
`
`
`24
`
`Authentication
`Algorithm
`
`Figure 2c
`
`Petitioner's Exhibit 1012, Page 5
`
`

`

`Patent Application Publication Aug. 15, 2002. Sheet 5 of 9
`
`US 2002/0109580 A1
`
`
`
`Microprocessor
`
`Figure 3a
`
`Petitioner's Exhibit 1012, Page 6
`
`

`

`Patent Application Publication Aug. 15, 2002 Sheet 6 of 9
`
`US 2002/0109580 A1
`
`
`
`H
`2.
`
`
`
`i.:
`
`O (Y)
`
`O
`Y
`c
`
`O
`LL
`
`3
`c
`s
`9?
`l
`
`S
`
`&S
`
`S i
`
`RS
`
`SS.
`
`y
`y
`y
`y
`
`N
`&
`
`9
`D
`O)
`l
`
`-
`
`w
`cy
`
`CN
`w
`
`P
`-D
`
`O)
`
`\ .
`s
`9.
`
`CN
`wn
`
`o
`CN
`--
`
`Od
`CN
`
`i
`
`i
`
`Petitioner's Exhibit 1012, Page 7
`
`

`

`Patent Application Publication Aug. 15, 2002. Sheet 7 of 9
`
`US 2002/0109580 A1
`
`12
`
`12
`
`12
`
`2
`
`28
`
`46
`
`40
`
`27
`
`t
`
`40<
`
`46
`
`Figure 4a
`
`Figure 4b
`
`Figure 4c
`
`
`
`Microprocessor
`
`Figure 4d
`
`Petitioner's Exhibit 1012, Page 8
`
`

`

`Patent Application Publication Aug. 15, 2002. Sheet 8 of 9
`
`US 2002/0109580 A1
`
`48
`
`48
`
`12
`
`40
`
`12
`
`12
`
`51
`
`Figure 4e
`
`Figure 4f
`
`Figure 4g
`
`
`
`Petitioner's Exhibit 1012, Page 9
`
`

`

`Patent Application Publication Aug. 15, 2002. Sheet 9 of 9
`
`US 2002/0109580 A1
`
`50
`v
`
`12
`/
`
`52
`
`12
`
`54
`
`Figure 5a
`
`Figure 5b
`
`50
`
`54
`
`Figure 5c
`
`Figure 5d
`
`Petitioner's Exhibit 1012, Page 10
`
`

`

`US 2002/0109580 A1
`
`Aug. 15, 2002
`
`WIRELESS UNIVERSAL PERSONAL ACCESS
`SYSTEM
`
`BACKGROUND OF THE INVENTION
`0001) 1. Field of the Invention
`0002 The present invention relates generally to a com
`munication System and, more Specifically to a long range,
`interactive and wireleSS personal access communication
`System that, using a single two-way remote keyleSS entry
`based interactive wireleSS device, facilitates transactions
`between a user and any one of Several independent Secure
`domain Systems.
`0003 2. Description of the Prior Art
`0004 Increasingly, a majority of individuals are faced
`with having to access many different Secured domain SyS
`tems, each having its own unique Security access require
`ments. And as the number of Such Systems increases, So too
`increase the number of access codes, acceSS devices and the
`like for which an individual must be accountable. For
`example, a consumer wanting to withdraw money from an
`automated teller machine (ATM) is currently required to
`Swipe a magnetically Striped bank card acroSS a card reader
`and manually input his or her personal identification number
`(PIN). Similarly, in many building access Systems, an indi
`vidual is required to Swipe a badge acroSS a card reader
`and/or manually enter his or her own personal access code
`into a keypad. Moreover, approximately 10 to 20 million
`automobile owners currently use remote keyleSS entry
`(RKE) systems (see U.S. Pat. Nos., 5.896,094, 5,499, 022
`and 5,844.517) to turn on or off the automotive security
`systems of their vehicles. And with the advent of Smart
`cards, a consumer wanting to perform a point of Sale
`transaction using an automated payment System like those
`popularized by the Mobile SpeedpassTM system and the EZ
`PassTM toll-collection system, must pay from a prepaid
`account that is linked to a card, or to a decal that is mounted
`on the windshield of the an automobile. Likewise, with Such
`Smart badge systems such as IBM's IBM PANTM (personal
`access network) system and Hewett Packard's TM Smart
`badge System, a card or decal is embedded with a chip
`containing an individual's account information. And a ter
`minal located at a transaction Site utilizes a card reader or
`emits a radio Signal that reads the account information
`contained within the Smart badge chip. Various other acceSS
`methods known in the art include, biometrics (e.g. finger
`print, Voiceprint, retina, face recognition, Skin temperature
`Sensing, body measurement, dynamic signatures), bar codes,
`conventional keys, forensics, one-wire buttons, radio fre
`quency (RF) identification.
`0005. Unfortunately, because each of the systems men
`tioned above exists independently of each other System, an
`individual must conduct transactions with each of the SyS
`tems using a variety of access platforms. The invention
`embodied in U.S. Pat. Nos. 5,982,891; 5,949,876; 5,917,
`912; 5,915,019; 5,910,987; and 5,892,900 seeks to over
`come this disadvantage by disclosing a capability to conduct
`Secure transactions from one remote location, Such as a
`Secure computer. However, the invention does not provide a
`convenient enabling device that an individual could carry to
`provide the Security acceSS codes and identification proce
`dures necessary to conduct remote transactions with many
`different Secure Systems.
`
`0006 Therefore, based on techniques known in the art for
`accessing Secured domain Systems, a universal personal
`acceSS System having the capability to utilize an enabling
`device, such as a remote keyless entry (RKE) fob device
`already carried by a majority of individuals, to provide the
`Security codes and identification procedures necessary to
`conduct Secured transactions with many independent
`Secured domain Systems is highly desirable.
`
`SUMMARY OF THE INVENTION
`0007. The present invention provides an access commu
`nication System having a transceiver device for transmitting
`and receiving Signals and an electronic database Storage
`element for Storing an acceSS code that provides the neces
`Sary identification of a user. The transceiver device is
`responsive to activation by the user, whereupon a coded
`request Signal containing the predetermined acceSS code is
`generated and transmitted by the remote keyleSS entry
`transceiver device to any one of many Secured domain
`Systems. The Secured domain Systems, each being remote
`from the transceiver device and independent from each other
`Secure domain System, each have a base unit and Service
`provider for receiving the digitally encoded request Signals
`from the remote keyleSS entry transceiver device and trans
`mitting a digitally encoded authorization signal to the
`remote keyleSS entry transceiver device in response to the
`receipt of the appropriate encoded request Signal.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0008 Reference is now made to the following description
`and attached drawings, wherein:
`0009 FIG. 1 is a block diagram illustration of a remote
`keyleSS entry based wireleSS universal access System in
`accordance with a preferred embodiment of the present
`invention;
`0010 FIG. 2a is a functional illustration of a remote
`authentication Server configuration between a two-way
`remote keyleSS entry device and a domain System Service
`provider in accordance with an alternate embodiment of the
`present invention;
`0011 FIG. 2b is a functional illustration of a hybrid
`authentication Server configuration between a two-way
`remote keyleSS entry device and a domain System Service
`provider in accordance with an alternate embodiment of the
`present invention;
`0012 FIG.2c is a functional illustration of a standalone
`authenticator in accordance with an alternate embodiment of
`the present invention;
`0013 FIG. 3a is a functional illustration of a remote
`keyleSS entry device in accordance with a preferred embodi
`ment of the present invention;
`0014 FIG. 3b is a front view illustration of a remote
`keyleSS entry device in accordance with the remote keyleSS
`entry device of FIG. 3a;
`0.015 FIG. 3c is a front view illustration of a remote
`keyleSS entry device including an intelligent control button
`in accordance with an alternate embodiment of the present
`invention;
`0016 FIG. 3d is a side view illustration of the remote
`keyless entry device of FIG. 3c,
`
`Petitioner's Exhibit 1012, Page 11
`
`

`

`US 2002/0109580 A1
`
`Aug. 15, 2002
`
`0017 FIG. 3e is a front view illustration of the remote
`keyless entry device of FIG. 3b including a modular remov
`able microdisplay;
`0018 FIG. 3f is a front view illustration of a remote
`keyleSS entry device without an internal display, but includ
`ing a modular removable microdisplay in accordance with
`an alternate embodiment of the present invention;
`0019 FIG. 3g is a front view illustration of the remote
`keyless entry device of FIG. 3f with the modular removable
`microdisplay removed;
`0020 FIG. 3h is a side view illustration of a remote
`keyleSS entry device including a modular removable micro
`display that includes a microdisplay Screen and lens for
`magnifying the view the microdisplay Screen view in accor
`dance with an alternate embodiment of the present inven
`tion;
`FIG. 4a is a side view illustration of remote
`0021
`keyleSS entry device including a button control interface;
`0022 FIG. 4b is a side view illustration of a remote
`keyleSS entry device including a skin conduction Sensing
`interface in accordance with an alternate embodiment of the
`present invention;
`0023 FIG. 4c is a back view illustration of the remote
`keyless entry device of FIG. 4b;
`0024 FIG. 4d is a schematic illustration of the skin
`conduction interface of FIG. 4b,
`0025 FIG. 4e is a side view illustration of a remote
`keyleSS entry device including an electrode for contact
`transactions in accordance with an alternate embodiment of
`the present invention;
`0026 FIG. 4f is a back view illustration of the remote
`keyless entry device of FIG. 4e,
`0027 FIG. 4g is a back view illustration of the remote
`keyleSS entry device of the present invention including an
`input/output (I/O) port for providing a physical connection
`to a domain System;
`0028 FIG. 4h is a functional illustration of the physical
`connection between the remote keyless entry device of FIG.
`4g and a domain System;
`0029 FIG. 5a is a side view illustration of a remote
`keyleSS entry device of the present invention including a
`biometric Sensor attachment;
`0030 FIG. 5b is a back view illustration of the remote
`keyless entry device of FIG. 5a with the biometric sensor
`attachment removed from an electrical connector and
`mechanical attachment Socket of the remote keyleSS entry
`device;
`0031 FIG. 5c is a side view illustration of the biometric
`sensor attachment of FIG. 5a; and
`0032 FIG. 5d is a back view illustration of the biometric
`sensor attachment of FIGS. 5a and 5c including an active
`area for extracting Sensor data.
`DETAILED DESCRIPTION OF THE
`INVENTION
`Referring to FIG. 1, the present invention discloses
`0.033
`a remote keyless entry (RKE) based, wireless access System
`
`10 that allows a user to independently access any one of a
`variety of independent Secured Systems from a Single uni
`versal platform. To accomplish this, the system 10 includes
`a single transceiver device 12, preferably, but not necessar
`ily, a remote keyleSS entry-based transceiver device, that is
`capable of performing two-way bi-directional wireleSS data
`communication with any one of a plurality of independent
`Secure electronic domain Systems 14. More particularly,
`Specific digitally encoded pulse command signals (18.20)
`are continuously and Securely transmitted and received
`between the transceiver device 12 and a particular domain
`System 14 until a transaction between the two is complete.
`Typically, a user 16 initiates the transaction with the par
`ticular domain System 14 by activating the transceiver fob
`device 12 using the interface methods described and illus
`trated in FIGS. 3 and 4. Upon activation, the transceiver
`device 12 digitally encodes a request signal 18 with certain
`acceSS code information, described below, and transmits the
`request signal 18 to the domain system 14. The domain
`System 14 may respond to the user's request 18 in a variety
`of ways, for example, the domain System 14 may send an
`authorization signal 20 to the transceiver device 12 notifying
`the user 16 that access has been granted or denied. Alter
`natively, the domain System 14 may send an authorization
`Signal 20 to the transceiver device 12 requesting additional
`information from the user 16. In this case, either the user 16
`will activate the fob device 12 to Send Subsequent request
`Signals 18 containing the information requested by the
`domain system 14 or the fob device 12 will, itself, auto
`matically Send the information.
`0034. As noted above, the transceiver device 12 sends a
`digitally encoded request Signal 18 to the domain System 14
`either upon initial activation by the user 16 or automatically.
`As illustrate in detail in FIG. 2, each domain system 14
`preferably includes a base unit 22 and a Service provider 24
`that may be either directly or remotely connected to each
`other. Communication between the RKE fob device 12 and
`the domain system 14 is established once the base unit 22
`receives the encoded request signal 18 from the fob device
`12. The base unit 22 forwards the request signal 18 to the
`Service provider 24, and the Service provider 24, acting as an
`issuing authority, determines whether to authorize the user's
`request and generates an authorization signal 20 correspond
`ing thereto. The service provider 24 then sends the autho
`rization signal 20 to the base unit 22 where the base unit 22
`forwards the authorization signal 20 to the user's RKE fob
`device 12.
`0035. The digitally encoded request signals 18 transmit
`ted by the device 12 to the base unit 22 may be encoded with
`access codes Such as a user identification (ID) code, a user
`account number, a personal identification number, a written
`Signature recorded from a touch Screen display, a personal
`biometric Signature, Voice authentication information, or
`other personal information Such as a mother's maiden name.
`An advantage of the present invention is that all acceSS codes
`can be converged into the single RKE fob device 12 by
`Storing the codes in a Secure electronic memory element 30
`(see FIG.3a) of the device 12. And, as a result of having all
`of the user's 16 access codes Stored in the device memory
`element 30, the present invention is able to provide multiple
`layers of Security for transactions between the user 16 and
`the domain system 14. In other words, the more value that
`is attached to a particular transaction, the more levels of
`Security the user 16 may be required to provide to complete
`
`Petitioner's Exhibit 1012, Page 12
`
`

`

`US 2002/0109580 A1
`
`Aug. 15, 2002
`
`the transaction. So, for example, level one Security may
`require a user ID or a user account number, level two
`Security may require a personal identification number (PIN),
`level three Security may require personal information Such
`as mother's maiden name, and level four Security may
`require a biometric Signature. For example, as shown in
`FIG. 5., biometric-based security levels may be imple
`mented using a detachable biometric sensor device 50. As
`illustrated in FIGS. 5a and 5b, in side and back views
`respectively, the biometeric sensor device 50 may attach to
`an electrical connector and mechanical Socket 52 located at
`the back-side of the fob device 12. As illustrated in FIGS.
`5c and 5b, inside and back views respectively, the biometric
`sensor device 50 includes an active region 54 that is utilized
`to extract invariant features from the user 16, the combina
`tion of which is called the biometric signature. The biomet
`ric sensor device 50 may be selected having the capability to
`extract invariant Such features from the user 16 as finger
`prints, voice data, eye iris or retina data, handwritten Sig
`nature and/or dynamic handwritten signature force measure
`ments, optical imaging of the face or palm, or other similar
`features. Although it is preferable that the biometeric Sensor
`device 50 be small enough to integrate mechanically with
`the fob device 12, this is not necessary requirement of the
`invention.
`0036) Referring now to FIG. 2, the base unit 22 and the
`service provider 24 of the domain system 14 may be directly
`or remotely connected, depending on the particular needs of
`the system 10. For example, FIG. 2a illustrates a remote
`authentication architecture, FIG. 2b illustrates a hybrid
`authentication architecture, and FIG. 2c illustrates a Stan
`dalone authentication architecture. However, it is important
`to note that the present invention is not limited to the
`architectures illustrated in FIG. 2 and can accommodate any
`domain System 14 architecture So long as the domain System
`14 is capable of processing a Secure transaction request from
`an fob device 12.
`0037 Referring specifically to FIG.2a, a remote authen
`tication embodiment of the domain System 14 includes a
`base unit 22 that is located within range of the fob device 12
`and is located remotely from the Service provider 24. A data
`communication network 25 is also included in the domain
`System 14 that provides a communication link between the
`base unit 22 and Service provider 24. The data communica
`tion network 25 may generally be any Secure communica
`tion link maintained by the service provider 24-for
`example, the Internet, a virtual private network (VPN), a
`telephone line a Satellite link an optical fiber, or a microwave
`or laser link. In other words, the data communication
`network 25 may be any communication path connecting the
`location at which a transaction occurs, here the base unit 22,
`with a location(s) at which an authentication of the trans
`action occurs, here the Service provider 24. The domain
`system 14 configuration illustrated in FIG.2a is likely to be
`a typical domain System configuration Since today many
`conventional service providers 24-for example, ATM
`machines, credit card point of Sale terminals, Service pro
`Viding public web kiosks or the like-already require Such
`a configuration.
`0038) Referring still to FIG.2a, because the base unit 22
`does no data processing or encryption/decryption, at least
`for the purposes of the transaction itself, it may include a
`simple transceiver 27. The transceiver 27 provides the base
`
`unit 22 with the capability to convert the data signals (18.20)
`sent between the key fob device 12 and the service provider
`24 from a wireless medium that can be recognized by the fob
`device 12 to a medium that can be recognized by the Service
`provider 24, and Vice-versa. Additionally, the base unit 22
`may include a computer (not shown) for managing the data
`communication to and from the data communication net
`work 25.
`0039. The FIG. 2a service provider 24 preferably
`includes a central processing unit (CPU) 29 and a secured
`database 31. Moreover, to provide authentication of a trans
`action initiated by the fob device 12 at the base unit 22, an
`“authentication algorithm'23-for example, a Software pro
`gram or a hardware encryption chip-is executed within the
`CPU 29. The authentication algorithm 23 typically requires
`information from the user 16, as input by the user 16 to the
`fob device 12, as well as information from the database 31
`to perform what are typically known complex mathematical
`encryption and decryption operations, Such as those
`described in “Applied Cryptography,” Bruce Schneier, 1996.
`In other words, the key fob device 12, or perhaps the user 16
`of the device 12, has to be identified uniquely, typically via
`a key fob identification code (ID) that may be a large number
`stored in a nonvolatile memory 30 (see also FIG.3a) of the
`fob device 12. In addition to the key fob ID, authentication
`algorithm 23 may require the fob device 12 to provide the
`service provider 24 with other user specific information. All
`of the information may be provided by the fob device 12 to
`the service provider 24 by way of the data signals (18.20)
`sent between the fob device 12 and the base unit 22. Once
`provided to the authentication algorithm 23, the information
`may be combined, in an unambiguous way, with information
`already stored on the service provider database 31. For
`example, the encryption/decryption keys which, as previ
`ously mentioned are Stored in the database 31, can be used
`in combination with the key fob ID to provide authentication
`for a particular transaction. The database 31 may also
`contain cross-references between the key fob ID and other
`user Specific information (e.g., accounts, access privileges,
`biometrics, etc) that can be used by the authentication
`algorithm 23 to further facilitate the authentication process.
`Thus, as part of the execution of the authentication algorithm
`23, the CPU 29 uses keys stored in the database 31, to
`decrypt and encrypt the various data signals (1820) trans
`mitted between the fob device 12 and the service provider
`24. Based on the results of the authentication process, the
`CPU 29 may also query and take responses from the
`database 31 to acceSS certain customer information Stored in
`the database 31.
`0040. Referring now to FIG.2b, a hybrid authentication
`embodiment of the domain system 14 is illustrated having
`Similar components and operation as the embodiment shown
`in FIG. 2a, except that here the base unit 22, in addition to
`having the transceiver 27, also includes an authentication
`algorithm 15 and a database 35. The CPU 33, the authen
`tication algorithm 15 and the database 35 work together to
`provide the base unit 22 with Some type of authentication,
`validation or other processing (not necessarily related to a
`Specific user) which takes place at the Site of the key fob
`device 12 transaction. In other words, for various reasons,
`Such as a need to reduce bandwidth over the data commu
`nication network 25 or to perform a check that “any valid
`user' or particular user tier is involved in a transaction, the
`base unit 22 includes the CPU 33, the authentication algo
`
`Petitioner's Exhibit 1012, Page 13
`
`

`

`US 2002/0109580 A1
`
`Aug. 15, 2002
`
`rithm 15, and the database 35 together may perform certain
`pre-processing on post-processing procedures on the infor
`mation eXchanged between the fob device 12 and the Service
`24 provider. However, it is important to note that in the
`present embodiment, user-specific authentication Still takes
`place at the remotely located Service provider 24 in the
`manner previously described and illustrated in FIG. 2a.
`0041
`Referring now to FIG. 2c, a standalone authenti
`cation embodiment of the domain system 14 is illustrated in
`which, similar to the FIGS. 2a and 2b embodiments, the
`base unit 22 is located within range of the fob device 12.
`However, unlike the FIG.2a and FIG.2b embodiments, the
`domain System 14 here is configured So that the base unit 22
`and the Service provider 24 are centrally located. Here, the
`base unit 22 is similar to the base unit shown in FIG. 2a,
`namely it includes a transceiver 27 that provides the base
`unit 22 with the capability to convert the data signals (18.20)
`sent between the key fob device 12 and the service provider
`37. Alternatively, the base unit 22 may also include its own
`CPU (not shown), authentication algorithm and database
`(not shown) in a configuration similar to the configuration
`illustrated in FIG. 2b.
`0.042
`Referring still to FIG. 2c, the service provider 24
`includes a CPU 29, an authentication algorithm 23 and a
`database 31 that operate in a manner Similar to that described
`by the FIGS. 2a and 2b embodiments. The domain system
`14 architecture of the present embodiment is preferred for
`conducting the short-range contact messaging transactions
`described in detail in FIGS. 4e and 4f. In such transactions,
`the nonvolatile memory 30 (see also FIG. 3a) of the fob
`device 12 Stores encrypted information in a manner Similar
`to that used with Smart cards or Similar devices. Thus, the
`CPU 29, the authentication algorithm 23 and the database 31
`work together to process a transaction by crediting a mon
`etary amount of an account located within the Service
`provider database 31 and, correspondingly, debiting the
`Same amount from an account located within the memory 30
`of the key fob device 12. Moreover, if the same architecture
`were used as a physical acceSS mechanism, Such as that used
`for a door or a gate, it is possible that the Service provider
`database 31 could also be configured to provide authentica
`tion for Specific users 16.
`0043 Referring now to FIGS. 3a and 3b, a preferred
`embodiment of the key fob transceiver device 12 is
`described and illustrated. The fob device 12 is preferably a
`two-way handheld bi-directional remote keyleSS entry
`(RKE) fob device that, for the convenience of the user 16,
`can be physically attached to a key ring (not shown) or
`Similar article, and Stored in a pocket, purse or wallet. The
`fob device 12 includes a microprocessor element 47, the
`memory element 30, a display element 26 and a control
`interface 28, each facilitating a transaction between the user
`16 and the secured domain system 14. The fob device 12
`may also include a power source 45 (see FIG. 4d) that
`provides power supply to the fob device 12. The power
`Source 45 is preferably an interchangeable and rechargeable
`battery that, for example, may be charged from a conven
`tional base unit (not shown) whose external contacts make
`contact with the external contacts of the fob device 12 once
`the device 12 is placed in the base unit. The power source 45
`may also be charged by using a known induction coil
`approach that allows the battery 45 to be charged without the
`use of external contacts on the device 12. Charging by an
`
`induction coil approach is accomplished by Setting the fob
`device 12 in a charging base (not shown) having a primary
`coil with alternating current flowing through it.
`0044) The display 26 of the fob device 12 is preferably a
`liquid crystal display (LCD) with backlight. The display 26
`may provide feedback capabilities to the user 16 that
`include, but are not limited to, whether a particular domain
`System 14 is available for acceSS and, if So, whether Such
`acceSS has been granted or denied. The display 26 preferably
`includes an approximately 600 to 800 pixel high-resolution
`screen 37 whose resolution is substantially similar to present
`state of the art video cameras. Alternatively, the screen 37
`may include a touch Sensitive interface. The backlight of the
`display 26 may be provided using the Indiglo TM technology
`currently used in ultra low power wristwatches. And in
`addition to having the capability to display textual charac
`ters, the display 26 may also include the capability to display
`Symbols that, for example, may indicate the operational
`mode of the fob device 12.
`004.5 The memory element 30, preferably a non-volatile
`memory chip, is included in the key fob device 12 to allows
`for, among other things, rewritable and updatable access
`information to be input to the display 26 directly or through
`the control interface 28 and stored within the memory 30.
`The fob device memory 30 may also store a history of prior
`transactions. For example, a transaction history might
`include recent account balance information, latest medical
`record information, the levels of Security required for par
`ticular transactions, acceSS expiration information, or
`encrypted proof of a past transactions.
`0046) As shown in FIGS. 3c and 3d, in side and back
`ViewS respectively, an intelligent button 42 can be used in
`addition to, or in place of the volatile memory 30. Intelligent
`buttons 42, like the iButton device manufactured by Dallas
`Semiconductor, are typically packaged processor and
`memory devices (chips) that carry information that can be
`used for remote authorization to gain access to a Secured
`System. Thus, during a transaction, information Stored in the
`intelligent button device 42 is transmitted to the domain
`System 14 into which access is desired. By providing the
`intelligent button 42 in addition to the device memory 30,
`the user 16 is given an additional means of identification that
`may be used to acquire access to a particular domain System
`14. And by providing the intelligent button 42 as an inter
`changeable replacement for the device memory 30, the fob
`device 12 could function as it did with the device memory
`30, So long as the intelligent button 42 is plugged into a
`device port 44. Here, the fob device 12 provides a more
`universal means of access for the user 16, Since the user 16
`can not only Select from a variety of interchangeable intel
`ligent buttons 42, but the intelligent button 42 can be shared
`among multiple fob devices 12.
`0047 Because the memory elements (30, 42) of fob
`device 12 may contain proprietary information, it is worth
`mentioning here what approaches might be taken to mitigate
`against a Situation where the fob device 12 is lost or Stolen.
`For example, prior to a loSS, a domain System 14 may, on an
`ongoing basis, duplicate or backup the contents of the device
`memory 30 to a database contained within the domain
`system 14 each time the user 16 transacts with the domain
`System 14. Such backups can automatically occur depending
`upon Such criteria as the time elapsed Since the last trans
`
`Petitioner's Exhibit 1012, Page 14
`
`

`

`US 2002/0109580 A1
`
`Aug. 15, 2002
`
`action or the nature of the transaction itself. However, once
`a loSS has occurred, the loSS may be mitigated using the
`measures Similar to those typically taken when an ATM card,
`credit card or similar item is lost or Stolen. In other words,
`the user 16 would notify the appropriate domain system 14
`administrator that the device 12 had been lost or stolen and
`the administrator would, in turn, invalidate any authorization
`requests that are associated with the access codes (keys)
`stored in the memory 30 of the lost or stolen fob device 12.
`0048 Referring now to FIGS. 3e through 3f, the RKE
`fob device 12 may alternatively include a removable micro
`display module 32 that plugs into the RKE device 12, thus
`allowing the device 12 to exploit a variety of display
`options. For example, as shown in FIG. 3e, the fob device
`12 is illustrated including the display module 32 in addition
`to the existing LCD display 26. Alternatively, as shown in
`FIGS. 3f and 3g, the fob device 12 may include only the
`display module 32. And, as shown in FIG.3h, the removable
`module 32 may optionally include a microdisplay Screen 34
`and a magnifying lens assembly 36 that is capable of
`magnifying the high-resolution display of the Screen 34 by
`at least a factor of approximately ten.
`0049 Referring now to FIG. 4a, the control interface 28
`of the fob device 12 preferably includes features such as
`conventional keypad buttons 40, that are similar to those
`used in present State of the art remote keyleSS entry devices.
`0050 Referring to FIGS. 4b, 4c and 4d, the control
`interface 28 may also include features that mitigate against
`unintentional wireless transactions that can occur as a result
`of inadvertent actions by the user 16. For example, as shown
`in FIGS. 4b and 4c in side and back views, respectively, one
`Such control feature is a skin conduction interface. The skin
`conducti