HYBRID DEVICE HAVING A PERSONAL DIGITAL KEY AND RECEIVER-
`DECODER CIRCUIT AND METHODS OF USE
`
`CROSS-REFERENCE TO RELATED APPLICATIONS
`
`[0001]
`
`The present application claimspriority under 35 U.S.C. § 120 to U.S. Patent
`
`Application 14/171,705 entitled “Hybrid Device Having a Personal Digital Key and Receiver
`
`Decoder Circuit and Method of Use,” filed February 3, 2014, which claims priority under 35
`
`U.S.C. § 120 to U.S. Patent Application 13/445,825 entitled “Hybrid Device Having a Personal
`
`Digital Key and Receiver Decoder Circuit and Method of Use,” filed April 12, 2012, now U.S.
`
`Patent No. 8,646,042, which claimspriority under 35 U.S.C. § 120 to U.S. Patent Application
`
`12/329,329 entitled “Hybrid Device Having a Personal Digital Key and Receiver Decoder
`
`Circuit and Methodof Use,” filed December 5, 2008, now U.S. Patent No. 8,171,528, which
`
`claims the benefit of priority under 35 U.S.C. § 119(e) of U.S. Provisional Application
`
`No. 60/992,953 entitled “Reverse Prox,” filed on December 6, 2007 by David L. Brown, John J.
`
`Giobbi and Fred S. Hirt. The entire contents ofall of the foregoing are incorporated by reference
`
`herein.
`
`[0002]
`
`Applicants hereby notify the USPTO that the claims of the present application are
`
`different from those of the aforementionedrelated applications. Therefore, Applicant rescinds
`
`any disclaimer of claim scope madein the parent application, grandparent application or any
`
`other predecessor application in relation to the present application. The Examineris therefore
`
`advised that any such disclaimer and the cited reference that it was made to avoid may need to be
`
`revisited at this time. Furthermore, the Examineris also reminded that any disclaimer made in
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 1
`
`Petitioner’s Ex. 1002 , Page 1
`
`

`

`the present application should not be read into or against the parent application, the grandparent
`
`application or any other related application.
`
`I.
`
`FIELD OF ART
`
`BACKGROUND
`
`[0003]
`
`The invention generally relates to personal digital keys and corresponding
`
`sensors, capable of proximity detection/location determination and auxiliary data
`
`services/application services. Still more particularly, the present invention relates to a hybrid
`
`device including a personal digital key (PDK) and a receiver-decoder circuit (RDC) and methods
`
`for using same.
`
`2.
`
`DESCRIPTION OF THE RELATED ART
`
`[0004]
`
`Proximity sensors and location tracking are technologies with many applications.
`
`For example, proximity sensors can be used to provide secure access to physical and/ordigital
`
`assets, based on biometrics, passwords, PINs, or other types of authentication. Proximity sensors
`
`typically have advantages of being less cumbersome,easier to use, and moreflexible in form
`
`factor and implementation. Proximity sensors can be used to control access to resources and/or
`
`to authenticate individuals, for example.
`
`[0005]
`
`Onepossible application that can take advantage of proximity sensors is location
`
`tracking. RFID tracking is one example. In RFID, RFID tags are attached to objects to be
`
`tracked. RFID readers then interact with the RFID tags to determine the location ofthe tag.
`
`Regardless of how it is accomplished, location tracking (1.e., knowledge about the location of an
`
`object or person) is generally useful. For example, location tracking information can be used to
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 2
`
`Petitioner’s Ex. 1002 , Page 2
`
`

`

`track inventory and trace the route of objects through variouslocations. It can be used for time
`
`and motion studies. If tags are attached to people, then tracking of people can be usedto better
`
`understand their behavior. Knowledge about a person’s location (and/or their past locations and
`
`projected future locations) could be used to provide better services to that person.
`
`[0006]
`
`However, most proximity systems and location tracking systems have limited
`
`capabilities. Typically, the proximity sensor, RFID tag or similar device is a dumb device, in the
`
`sense that the device is designed and hasthe capability only to report its location. For example,
`
`such devices typically do not have the capabilities to run different applications or to even interact
`
`with different applications. Furthermore, these systems typically are proprietary and narrowly
`
`tailored for a specific situation, thus preventing easy expandability to other situations or third
`
`party applications.
`
`SUMMARY
`
`[0007]
`
`Various drawbacksof the prior art are overcomeby providing a hybrid device
`
`including a personal digital key (PDK) and a receiver-decoder circuit (RDC). The PDK and
`
`RDC ofthe hybrid device are coupled for communication with each other. In one embodiment,
`
`the hybrid device also provides a physical interconnect for connecting to other devices to send
`
`and receive control signals and data, and receive power. The hybrid device operates in one of
`
`several modesincluding, PDK only, RDC only, or PDK and RDC. This allowsa variety of
`
`system configurations for mixed operation including: PDK/RDC, RDC/RDC or PDK/PDK. The
`
`present invention also includes a numberof system configurations for use of the hybrid device
`
`including: use of the hybrid device in a cell phone; simultaneous use of the PDK and the RDC
`
`functionality of hybrid device; use of multiple links of hybrid device to generate an authorization
`
`-3-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 3
`
`Petitioner’s Ex. 1002 , Page 3
`
`

`

`signal, use of multiple PDK links to the hybrid device to generate an authorization signal; use of
`
`the hybrid device for authorization inheritance and use of the hybrid device for automatically
`
`disabling a service or feature.
`
`[0008]
`
`Other aspects of the invention include systems and components corresponding to
`
`the above, and methods correspondingto all of the foregoing.
`
`BRIEF DESCRIPTION OF THE FIGURES
`
`[0009]
`
`FIG. 1 is a block diagram illustrating one embodiment of a system according to
`
`the invention.
`
`[0010]
`
`FIG. 2 is a block diagram illustrating one embodimentof a Personal Digital Key
`
`(PDK).
`
`[0011]
`
`FIG. 3 is a block diagram illustrating one embodimentof a sensor.
`
`[0012]
`
`FIGS. 4-6 are block diagramsillustrating further embodiments of systems
`
`according to the invention.
`
`[0013]
`
`FIG. 7 is a block diagram illustrating one embodimentof a system with
`
`networked sensors.
`
`[0014]
`
`FIGS. 8-9 are block diagramsillustrating operation of the system in FIG. 7.
`
`[0015]
`
`FIG. 10 is a diagram illustrating operation of the system in FIG. 7.
`
`[0016]
`
`FIG. 11 is a block diagram of one embodimentof a hybrid device in accordance
`
`with the present invention.
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 4
`
`Petitioner’s Ex. 1002 , Page 4
`
`

`

`[0017]
`
`FIG. 12 is a block diagram of one embodiment of a system in which the hybrid
`
`device is part of a cell phone in accordance with the present invention.
`
`[0018]
`
`FIG. 13 is a block diagram of one embodiment of a system using the PDK and the
`
`RDCfunctionality of hybrid device in accordance with the present invention.
`
`[0019]
`
`FIG. 14 is a block diagram of one embodimentof a system using the multiple
`
`links of hybrid device to generate an authorization signal in accordance with the present
`
`invention.
`
`[0020]
`
`FIG. 15 is a block diagram of one embodimentof a system using the multiple
`
`PDKlinks to the hybrid device to generate an authorization signal in accordance with the present
`
`invention.
`
`[0021]
`
`FIG. 16 is a block diagram of one embodiment of a system using the hybrid
`
`device for authorization inheritance in accordance with the present invention.
`
`[0022]
`
`The figures depict various embodiments of the present invention for purposes of
`
`illustration only. One skilled in the art will readily recognize from the following discussion that
`
`alternative embodiments ofthe structures and methodsillustrated herein may be employed
`
`without departing from the principles of the invention described herein.
`
`DETAILED DESCRIPTION
`
`[0023]
`
`FIG. 1 is a high level block diagram illustrating a system for allowing access to
`
`multiple applications (or services). The system 100 comprises a Personal Digital Key (PDK)
`
`102, a sensor 108, a network 110 and one or more applications 120 (including services). The
`
`-5-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 5
`
`Petitioner’s Ex. 1002 , Page 5
`
`

`

`sensor 108 is coupled to the PDK 102 by a wireless link 106 and coupled to a network 110 by
`
`either a wired or wireless link. In this example, the applications 120 are also accessed over
`
`network 110. The sensor 108 is also adapted to receive a biometric input 104 from a user andis
`
`capable of displaying status to a user. In alternative embodiments, different or additional
`
`resources and databases may be coupled to the network 110, including for example registries and
`
`databases used for validation or to check variousregistrations of the user. In another
`
`embodiment, the sensor 108 operates as a standalone device without a connection to the network
`
`110.
`
`[0024]
`
`The PDK 102 includes multiple service blocks 112A-N as described in more
`
`detail in FIG. 2. Each service block 112 is accessed using a corresponding service block access
`
`key 118. In this example, the sensor 108 contains three of the service block access keys 118A,
`
`D, F. The service block access keys 118 allow the sensor 108 to unlock information stored in the
`
`corresponding service blocks 112, which informationis used as local secured information.
`
`[0025]
`
`In one example, a biometric is required in order to access specific service blocks
`
`112 inthe PDK 102. Verification of the biometric is achieved by using service block 112A. The
`
`sensor 108 stores the corresponding service block access key 118A and usesthis key to unlock
`
`the biometric service block 112A, which stores a valid biometric. A current biometric is
`
`received using biometric input 104. The sensor 108 then verifies the stored biometric (from
`
`service block 112A) against the recently acquired biometric (from input 104). Upon proper
`
`verification, various applications 120 are permitted to connect to the PDK 102 via the sensor 108
`
`and/or to gain access to other service blocks 112.
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 6
`
`Petitioner’s Ex. 1002 , Page 6
`
`

`

`[0026]
`
`The system 100 can be used to address applications 120 whereit is important to
`
`authenticate an individual for use. Generally, the sensor 108 wirelessly receives information
`
`stored in the PDK 102 that uniquely identifies the PDK 102 and the individual carrying the PDK
`
`102. The sensor 108 can also receive a biometric input 104 from the individual. Based on the
`
`received information, the sensor 108 determinesif access to the application 120 should be
`
`granted. In this example, the system 100 provides authentication without the need for PINs or
`
`passwords(although PINs and passwords maybeused in other implementations). Moreover,
`
`personal biometric information need not be stored in any local or remote storage database andis
`
`only stored on the user’s own PDK(in one embodiment).
`
`[0027]
`
`Thecredibility of the system 100 is ensured by the use of a PDK 102 that stores
`
`trusted information. The PDK 102 is a compact, portable uniquely identifiable wireless device
`
`typically carried by an individual. The PDK 102 stores digital information in a tamper-proof
`
`format that uniquely associates the PDK 102 with an individual. Example embodiments of
`
`PDKsare described in more detail in U.S. Patent Application No. 11/292,330, entitled “Personal
`
`Digital Key And Receiver/Decoder Circuit System And Method” filed on November30, 2005;
`
`U.S. Patent Application No. 11/620,581 entitled “Wireless Network Synchronization Of Cells
`
`And Client Devices On A Network” filed on January 5, 2007; and U.S. Patent Application No.
`
`11/620,577 entitled “Dynamic Real-Time Tiered Client Access” filed on January 5, 2007, the
`
`entire contents of whichare all incorporated herein by reference.
`
`[0028]
`
`The sensor 108 wirelessly communicates with the PDK 102 when the PDK 102 is
`
`within a proximity zone(i.e., within a microcell) of the sensor 108. The proximity zone canbe,
`
`for example, several meters in radius and preferably can be adjusted dynamically by the sensor
`
`108. Thus, in contrast to many conventional RF ID devices, the sensor 108 can detect and
`
`-7-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 7
`
`Petitioner’s Ex. 1002 , Page 7
`
`

`

`communicate with the PDK 102 without requiring the owner to remove the PDK 102 from
`
`his/her pocket, wallet, purse, etc. Generally, the sensor 108 receives uniquely identifying
`
`information from the PDK 102 andinitiates an authentication process for the individual carrying
`
`the PDK 102. In one embodiment, the sensor 108 is adapted to receive a biometric input 104
`
`from the individual. The biometric input 104 comprises a representation of physical or
`
`behavioral characteristics unique to the individual. For example, the biometric input 104 can
`
`include a fingerprint, a palm print, a retinal scan, an iris scan, a photograph,a signature, a voice
`
`sample or any other biometric information such as DNA, RNAortheir derivatives that can
`
`uniquely identify the individual. The sensor 108 compares the biometric input 104 to
`
`information received from the PDK 102 to determine authentication. Alternatively, the
`
`biometric input 104 can be obtained by a biometric sensor on the PDK 102 and transmitted to the
`
`sensor 108 for authentication. In additional alternative embodiment, someorall of the
`
`authentication process can be performed by the PDK 102 instead of the sensor 108.
`
`[0029]
`
`In this example, the sensor 108 is further communicatively coupled to the network
`
`110 in order to receive and/or transmit information to remote databases for remote
`
`authentication. In an alternative embodiment, the sensor 108 includes a non-volatile data storage
`
`that can be synchronized with one or more remote databasesor registries. Such an embodiment
`
`alleviates the need for a continuous connection to the network 110 and allows the sensor 108 to
`
`operate in a standalone mode andfor the local data storage to be updated when a connectionis
`
`available. For example, a standalone sensor 108 can periodically download updated registry
`
`entries and perform authentication locally without any remote lookup.
`
`[0030]
`
`In yet another alternative, a standalone sensor 108 may havea pre-configured
`
`secure access key 118 and encryption algorithm, or a variable access key 118 that changes, for
`
`-8-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 8
`
`Petitioner’s Ex. 1002 , Page 8
`
`

`

`example based on time and sensor ID. One example application would be a sensor 108 located
`
`in a hotel room door, where the sensor could constantly compute a different access key 118
`
`based on time, and the PDK 102 could be associated with this key during the hotel registration
`
`process.
`
`[0031]
`
`The network 110 provides communication between the sensor 108 and various
`
`validation databases and/orregistries, in addition to the applications 120. In one embodiment,
`
`the network 110 uses standard communications technologies and/or protocols. Thus, the
`
`network 110 can include links using technologies such as Ethernet, 802.11, 802.16, integrated
`
`services digital network (ISDN), digital subscriber line (DSL), asynchronoustransfer mode
`
`(ATM), etc. Similarly, the networking protocols used on the network 110 can include the
`
`transmission control protocol/Internet protocol (TCP/IP), the hypertext transport protocol
`
`(HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc. The data
`
`exchanged over the network 110 can be represented using technologies and/or formats including
`
`the hypertext markup language (HTML), the extensible markup language (XML), etc. In
`
`addition, all or some oflinks can be encrypted using conventional encryption technologies such
`
`as the secure sockets layer (SSL), Secure HTTP and/orvirtual private networks (VPNs). In
`
`another embodiment, the entities can use custom and/or dedicated data communications
`
`technologies instead of, or in addition to, the ones described above.
`
`[0032]
`
`In one aspect, the sensor 108 may connectto a validation database that stores
`
`additional information that may be used for authorizing a transaction to be processed at the
`
`sensor. For example, in purchase transactions, the sensor 108 may interact with a credit card
`
`validation database that is separate from the merchant providing the sale. Alternatively, a
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 9
`
`Petitioner’s Ex. 1002 , Page 9
`
`

`

`different database may be usedto validate different types of purchasing meanssuchas a debit
`
`card, ATM card, or bank account number.
`
`[0033]
`
`In another aspect, the sensor 108 may connectto variousregistries that store,
`
`amongother items, PDK, notary, and/or sensor information. In one embodiment, a registry
`
`stores biometric or other types of information in an encoded formatthat can only be recovered
`
`using an algorithm or encoding key stored in the PDK. Information stored in the registries can
`
`be accessed by the sensor 108 via the network 110 for use in the authentication process. Two
`
`basic types of registries are private registries and a Central Registry. Private registries are
`
`generally established and administered by their controlling entities (e.g., a merchant, business
`
`authority, or other entity administering authentication). Private registries can be custom
`
`configured to meet the specialized and independent needs of each controlling entity. A Central
`
`Registry is a highly-secured, centrally-located database administered bya trusted third-party
`
`organization. In one embodiment, all PDKs 102 are registered with the Central Registry and
`
`may be optionally registered with one or more selected private registries. In alternative
`
`embodiments, a different numberor different types of registries may be coupled to the network
`
`110.
`
`[0034]
`
`The service blocks 112 can be used for purposes other than user authentication.
`
`For example, information used or produced by an application 120 can be transferred back and
`
`forth to the corresponding service block 112. That is, each service block 112 can be used as a
`
`local secure memory for the corresponding application 120. Thus, a service 120B maystore
`
`certain sensitive information in service block 112B, and a separate service 120C will not be able
`
`to access that information without the corresponding access key 118B. In this example, the
`
`sensor 108 only holds access keys 118A, D, F and doesnot hold access key 118B. The
`
`-10-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 10
`
`Petitioner’s Ex. 1002 , Page 10
`
`

`

`application 120B may hold the access key 118B, thus allowing it to access service block 112B
`
`but preventing application 120C from accessing the service block 112B. Note that this
`
`implementation would also prevent the sensor 108 acting alone from accessing the service block
`
`112B.
`
`[0035]
`
`Turing now to FIG. 2, an example embodiment of a PDK 102is illustrated. The
`
`PDK 102 comprises a memory 210, control logic 250, wireless application 260 and a transceiver
`
`270. The PDK 102 can be standaloneas a portable, physical device or can be integrated into
`
`commonlycarried items. For example, a PDK 102 can be integrated into a portable electronic
`
`device such as a cell phone, Personal Digital Assistant (PDA), or GPS unit, an employee
`
`identification tag, clothing, or jewelry items such as watches, rings, necklaces or bracelets. In
`
`one embodiment, the PDK 102 can be, for example, about the size of a Subscriber Identity
`
`Module (SIM)card and be as small as a square inch in area or less. In another embodiment, the
`
`PDK 102 can be easily contained in a pocket, on a keychain, or in a wallet. The PDK can also
`
`contain other components not shown, for example various other inputs, outputs and/or interfaces
`
`(serial or parallel).
`
`[0036]
`
`The memory 210 can be a read-only memory, a once-programmable memory, a
`
`read/write memory or any combination of memory types, including physical access secured and
`
`tamperproof memories. The memory 210 typically stores a unique PDK ID 212. The PDK ID
`
`212 comprises a public section and a private section of information, each of which can be used
`
`for identification and authentication. In one embodiment, the PDK ID 212 is stored in a read-
`
`only format that cannot be changed subsequent to manufacture. The PDK ID 212 is used as an
`
`identifying feature of a PDK 102 anddistinguishes between PDKs 102 in private or Central
`
`registry entries. In an alternative embodiment, the registries can identify a PDK 102 bya
`
`-ll-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 11
`
`Petitioner’s Ex. 1002 , Page 11
`
`

`

`different ID than the PDK ID 212 stored in the PDK 102, or may use both the PDK ID 212 and
`
`the different ID in conjunction. The PDK ID 212 canalso be used in basic PDK authentication
`
`to ensure that the PDK 102 is a valid device.
`
`[0037]
`
`The memory 210 also stores the various service blocks 112A-N. Whether a
`
`particular service block 112 is stored in volatile or non-volatile memory may be determined by
`
`the specific application. In one approach,the original issuer of the PDK defines how theinternal
`
`memory 210 may be used for service blocks 112. In some cases, the issuer may chooseto only
`
`allow their service blocks to be stored, in which case third party applications will not be able to
`
`store service blocks in memory 210. In other cases, the issuer may allow anythird party service
`
`120 to use available service blocks 112. If anew service block is created, then memoryforthat
`
`service block is allocated. The specific location of the service block and generation of the
`
`corresponding service block access key can be handled by the PDK 102, or can be handled via an
`
`external service.
`
`[0038]
`
`Regardless of how created, once created, external applications (such as
`
`applications 120 in FIG. 1) can gain accessto a specific service block 112 by proving the
`
`corresponding access key 118. In FIG. 2, this is shown conceptually by control logic 250. The
`
`wireless application 260 on the PDK 102 communicatesto the sensor (not shown in FIG. 2) via
`
`transceiver 270. The wireless application providesa service block select 226 and a service block
`
`access key 118 in orderto store, retrieve and/or modify data in a service block 112. The selector
`
`252 selects a service block 112 based on the select signal 226 and the access key 118. The
`
`encryption engine 254 encrypts/decrypts data 228 flowing to/from the service block 112 based
`
`on the access key 118 (or some other key generated based on the access key, for example a
`
`-12-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 12
`
`Petitioner’s Ex. 1002 , Page 12
`
`

`

`session key). In an alternate method, the service block 112 may be selected based on the service
`
`block access key 118, eliminating the need for a separate select signal 226.
`
`[0039]
`
`The PDK 102 mayalso include other data and applications. For example, the
`
`PDK102 typically will include various profiles. Many different types of profiles are possible. A
`
`biometric profile, for example, includes profile data representing physical and/or behavioral
`
`information that can uniquely identify the PDK owner. A PDK 102 can store multiple biometric
`
`profiles, each comprising a different type of biometric information. The same biometric
`
`information can also be stored multiple times in a PDK 102. For example, two different
`
`applications mayusethe right index fingerprint, and that biometric information may bestored in
`
`two different service blocks, one for each application. In addition, the PDK 102 mayalso store
`
`one or more biometric profile “samples” associated with each biometric profile. Profiles may
`
`also store one or more PINsor passwordsassociated with the PDK owner, or one or more
`
`pictures of the PDK owner. A profile can further include personal identification information
`
`such as name, address, phone number, etc., bank information, credit/debit card information, or
`
`membership information. This information can be useful for transactions.
`
`[0040]
`
`The transceiver 270 is a wireless transmitter and receiver for wirelessly
`
`communicating with a sensor 108 or other wireless device. The transceiver 270 can send and
`
`receive data as modulated electromagnetic signals. Moreover, the data can be encrypted by the
`
`transceiver 270 and transmitted over a secure link. Further, the transceiver 270 can actively send
`
`connection requests, or can passively detect connection requests from another wireless source.
`
`In one embodiment, the transceiver 270 is adapted to communicate over a range of up to around
`
`5 meters. In another embodiment, the transceiver 270 range can be varied.
`
`-13-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 13
`
`Petitioner’s Ex. 1002 , Page 13
`
`

`

`[0041]
`
`Turning now to FIG. 3, an example embodimentof a sensor 108 is illustrated.
`
`The embodiment includes one or more biometric readers 302, a receiver-decoder circuit (RDC)
`
`304, a processor 306, a network interface 308 and an I/O port 312. In alternative embodiments,
`
`different or additional modules can be included in the sensor 108.
`
`[0042]
`
`The RDC 304provides the wireless interface to the PDK 102. Generally, the
`
`RDC 304 wirelessly receives data from the PDK 102 in an encrypted format and decodes the
`
`encrypted data for processing by the processor 306. An example embodiment of an RDC is
`
`described in U.S. Patent Application No. 11/292,330 entitled “Personal Digital Key And
`
`Receiver/Decoder Circuit System And Method,” the entire contents of which are incorporated
`
`herein by reference. Encrypting data transmitted between the PDK 102 and sensor 108
`
`minimizes the possibility of eavesdropping or other fraudulent activity. In one embodiment, the
`
`RDC 304is also configured to transmit and receive certain types of information in an
`
`unencrypted, or public, format.
`
`[0043]
`
`The biometric reader 302 receives and processes the biometric input 104 from an
`
`individual. In one embodiment, the biometric reader 302 is a fingerprint scanner. Other
`
`embodiments of biometric readers 302 includeretinal scanners, iris scanners, facial scanner,
`
`palm scanners, DNA/RNAanalyzers, signature analyzers, cameras, microphones, and voice
`
`analyzers. Furthermore, the sensor 108 can include multiple biometric readers 302 of different
`
`types.
`
`[0044]
`
`The network interface 308 can be a wired or wireless communication link
`
`between the sensor 108 and network 110. For example, in one type of authentication,
`
`information is received from the PDK 102 at the RDC 304, processed by the processor 306, and
`
`-14-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 14
`
`Petitioner’s Ex. 1002 , Page 14
`
`

`

`transmitted to external authentication databases through the network interface 308. The network
`
`interface 308 can also receive data sent through the network 110 for local processing by the
`
`sensor 108. In one embodiment, the network interface 308 provides a connection to a remote
`
`system administrator to configure the sensor 108 accordingto various controlsettings.
`
`[0045]
`
`The I/O port 312 provides a general input and outputinterface to the sensor 108.
`
`The I/O port 312 may be coupled to any variety of input devices to receive inputs such as a
`
`numerical or alphabetic input from a keypad, control settings, menu selections, confirmations,
`
`and so on. Outputs can include, for example, status LEDs, an LCD, or other display that
`
`provides instructions, menusor control optionsto a user.
`
`[0046]
`
`FIGS. 4-6 are high level block diagramsillustrating additional examples of
`
`applications accessing service blocks. FIGS. 4 and 5 illustrate that the application 120 need not
`
`be located at any particular location on the network. Rather, the service block 112 is accessed
`
`from any application 120 that can attach (in a network sense) to the sensor 108.
`
`[0047]
`
`In FIG. 4, the sensor 108 attaches to the PDK 102 within its microcell, using
`
`service block access key 118(A) and service block 112(A). A personal computer or other
`
`standalone device 510 is attached to the sensor 108, either directly or via a network. In this
`
`example, the device 510 communicates with the sensor via a standardized API 520. An
`
`application 120 executes on the device 510 and has access to the service block access key
`
`118(B). It uses this key to gain access to the corresponding service block 112(B). This is an
`
`example of a local application 120.
`
`[0048]
`
`FIG. 5 illustrates a remote application. In this example, the sensor 108 attaches to
`
`the PDK 102 in the same manneras FIG. 4, using service block access key 118A and service
`
`-15-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 15
`
`Petitioner’s Ex. 1002 , Page 15
`
`

`

`block 112A. However, application 120 is not executing on a local device. Rather, it executes
`
`remotely. Here, it is shown as an external service 120. However, service 120 can still gain
`
`access to service block 112B byuseofservice block access key 118B, although it does so via
`
`network 110 and intermediate device 512. Although the sensor 108 is the device that attaches to
`
`the PDK 102, a local or remote application 120 with the right credentials maystore or retrieve
`
`information in a service block 112 in the PDK 102.
`
`[0049]
`
`The PDKitself can also be configured to prevent the same source from repeating
`
`invalid access attempts to the PDK’s service blocks. The PDK may monitor access to the service
`
`blocks. When an attached service makes multiple unsuccessful attempts to unlock a service
`
`block, the PDK tracks this and eventually ignores the requests from that service for a period of
`
`time. Alternately, the PDK may disconnect from the network or take otheractions.
`
`[0050]
`
`An example of a local application (FIG. 4) is an auto login/logoff of a personal
`
`computer. When a PDK 102 is within the proximity of the personal computer 510, the PDK 102
`
`is detected and the sensor 108 attaches to the PDK 102 (using service block 112A). The
`
`login/logoff application 120 then sends the service block access key 118B along with a request
`
`for the contents of the service block 112B to the PDK 102 via the sensor 108. For example, a
`
`standard may specify that particular service block 112B contains username and password. These
`
`are returned to the application 120, allowing automatic login to the personal computer 510.
`
`[0051]
`
`An example of a remote application (FIG. 5) is a credit card transaction. The
`
`sensor 108 in this case could be a credit card terminal. When the PDK 102 is brought in close
`
`proximity, the credit card terminal 108 attaches to the PDK 102 (using service block 112A). The
`
`terminal 108 then sends the PDK ID 212 to the credit card issuer (the external service) for
`
`-16-
`
`10001-04683 US
`
`Petitioner’s Ex. 1002 , Page 16
`
`Petitioner’s Ex. 1002 , Page 16
`
`

`

`identification. The credit card issuer may then send a service block access key 118B back to the
`
`sensor 108, whereit is passed on to the PDK 102 to unlock a specific service block 112B. The
`
`contents of the service block 112B could then be sent back to the credit card issuer where further
`
`decryption could occur and the credit card holder could be verified. Once verified, the credit
`
`card terminal displays that the transaction is approved.
`
`[0052]
`
`These two examplesillustrate basic concepts of the capabilities of the service
`
`blocks and how anapplication (service) may use them. Since service blocks preferably are both
`
`readable and writable, services may use them astheyseefit (1.e. debit, username/password,
`
`credit card information, etc.). In some sense, the service block acts as a secure local memory on
`
`the PDK.
`
`[0053]
`
`FIGS. 4 and 5 illustrate a basic case where a single application accesses a single
`
`service block on a single PDK via a single sensor. The invention is not limited to this case. FIG.
`
`6 illustrates a case with multiple applications, sensors, and service blocks. Thisillustrates the
`
`sharing of service blocks. As shown, service blocks may be limited to a single service or source
`
`or may be shared across multiple services and sources. A service block 112 is a protected
`
`memory element which allows an application 120 with the right credentials to access it. In this
`
`example, applications 120W, 120X and 120Y1 can each accessservice block 112C since each
`
`application has access to service block access key 118C. Similarly, applications 120V, 120Z2
`
`and 120Z3 can each access service block 112B. Although not shown in FIG. 6, it is also possible
`
`for an application to access more than one service block. FIG. 6 also showsa situation where
`
`applications 120Z1-3 running on different devices 510Z1-3 all access the PDK 102 through the
`
`same sensor 108Z. Each sensor 108 covers a certain proximity zone(i.¢.