,.
`
`PROHlffilTY
`
`PROXEnJE
`
`T!CHROl061£/
`
`lruplOH™TOUCH TECHnOLOGY
`
`John Giobbi
`689 NW Stonepine Dr.
`Bend, OR 97701
`
`Confidential
`
`The information provided in this document is the exclusive property of Proxense, LLC. Recipient .hereby
`acknowledges that such information is confidential and privileged, and will not be disclosed, copied,
`distributed or used without the express written consent of Proxense, LLC.
`
`1
`
`MICROSOFT 1010
`
`

`

`TruProx™ Touch Technology
`
`Background:
`
`Optimizing sales transactions, providing secure access to physical & digital assets, and uniquely identifying individuals,
`are challenges faced by many businesses and organizations. Ensuring these processes are safe, efficient and simple
`is important to merchants, providers, users and consumers alike. Well known technologies such as magnetic cards
`(credit & debit cards, employee badges, etc.), and more recent developments such as contactless cards or tokens
`(designed to be waved near compatible readers), are examples of attempts to address these needs.
`
`While these technologies have improved transaction-processing and access-control ("transactions"), they have
`inherent problems and shortfalls. In particular, none directly address one critical concern, knowing an individual
`attempting to perform a transaction is who they claim to be, and is actually authorized to do so. And the problem is
`worsening as Internet-based sales continue their rapid growth. In general, this shortfall has become a serious problem
`in need of a solution. And it is critical that the "solution" does not significantly increase the complexity, risk, or speed of
`processing such transactions.
`
`Common attempts to address this ·issue involve using PINs or passwords in conjunction with account numbers. While
`these options do help combat fraudulent use/access, they also go against the desired goal of not adding complexity
`and delay to transactions ... and they are often defeated. Quite simply, in attempts to deal with an ever-growing need
`to memorize PINs and passwords, individuals often resort to using the same, simple phrase to protect many items, or
`worse, write the phrases on notes kept in their purse/wallet or stuck to their computer. Neither is a best practice ... but
`both routinely occur, and highlight some of the shortfalls inherent in current methodologies.
`
`A technology capable of addressing the underlying issue, authenticating users, is biometrics. On the surface,· biometric
`authentication (for example, comparing an individual's fingerprint to a known sample) is a logical solution. Yet, it too
`suffers from significant problems. The primary being it potentially exposes the participating parties - the entities
`administering the authentication ("controlling-entities"), and the individuals being authenticated .("users") - to serious
`liabilities, risks, and inefficiencies. Biometric authentication techniques in use today nearly always require users to
`release their most personal, private and unchangeable (biometric) data to the controlling-entity, or a third-party relied
`on by the entity, exposing that data to the possibility of theft and fraudulent use. And correspondingly, controlling(cid:173)
`entities must either assume the risks & liabilities of storing such data in their databases, or trust (or expect their
`users/customers to trust) the data to a third-party's care.
`
`And though the above highlights the primary problems with today's biometric options, another critical problem also
`exists. As today's biometric options generally function by accepting an individual's fingerprint "sample" (at the time of a
`. transaction), and then comparing the sample to ones retrieved from a database, it is clear that at some point prior to
`the transaction, the individual was required to submit a "sample" for storage within the database. This "enrollment''
`process is time-consuming, risky, error-prone, and considered intrusive by many individuals. And highlighting the
`scope of this issue is the realization that currently, the process must be performed for each individual for every
`intended use. For example, if a user intends to enroll for biometric authentication with their company (e.g. for secure
`access to digital files or the business' facilities), and also with merchants utilizing various biometrically-based security
`technologies, the individual will likely need to repeat the enrollment process for each entity, and be comfortable with
`their personal biometric data being stored on each of those entities' databases. This issue alone is enough to prevent
`many people from ever considering these options.
`
`While at first glance, one alternative, having individuals agree to store their biometric data in a shared centralized
`database, appears logical and simple, it too suffers from significant problems/issues. These include: theft and privacy
`risks/exposures (similar to the above options), inherent search & transaction delays (due to the need to provide a
`secondary form of identification in order to initiate a transaction), and importantly, the need to be "on-line" to take
`advantage of any of the security capabilities (making the option inappropriate for many "internal" business needs such
`as protecting digital or physical assets).
`
`In summary, the above-defined issues represent serious roadblocks to the widespread deployment & acceptance of
`currently-available biometric authentication options. There is uncertainty as to whether the benefits will eventually
`outweigh the negatives, but (minimally) unless the identified deficiencies are addressed, the full potential of biometric
`solutions will never be realized. Therefore, a new technology, one fully capable of addressing these needs, is likely to
`be positively embraced, and have the potential to gain widespread acceptance.
`
`Confidential • Proxense, LLC
`
`Page2
`
`2
`
`

`

`,..
`
`TruProx™ Touch Technology
`
`Introduction - The TruProx™ Touch Technology:
`Building on the TruProx™ proximity-based, multi-layered security technology, the invention, herein referred to as the
`TruProx™ Touch Technology ("Touch", "Touch technology", "Touch model"), defines a biometrically-authenticated
`security technology/system. Touch authentication addresses applications where it is important to ensure a specific
`individual is authorized to perform a given task/transaction. Examples of such transactions include: enabling secure
`. financial dealings, providing secure access to physical and/or digital items, and simple user ID & age verifications.
`
`NOTES: For clarity in this document, the biometric option discussed & used in examples, is that of fingerprint
`sensing/comparison. The reader should note, however, Touch technology is·not limited to fingerprint-based
`options. Nearly any biometric authentication technology - including retinal scan, facial recognition, palm
`recognition, etc. - could be utilized by the model.
`
`Model Overview:
`The underlying premise of the Touch technology is that of enabling users to carry on their person a wireless, Liniquely(cid:173)
`identifiable device (in TruProx™ terminology, a "Personal Digital Key', or "POK'') containing their personal biometric
`data. This POK, when needed, can prove beyond question that the biometric data it contains is that of the individual
`attempting to utilize it. This capability, when applied as defined by the Touch model, provides users/customers and
`merchants/businesses/organizations with unparalleled security, ease & efficiencies of use, and risks & liabilities
`substantially lower than comparable options. It should be noted, that while PDKs referred to in this document are (for
`simplicity sake) described as simple, stand-alone devices, in practice they may take many different forms. Some
`examples include: direct integration into commonly carried items such as cell phones & PDAs, attached to/replacing
`employee ID tags, and even incorporated into jewelry items such as watches, rings or bracelets.
`
`To implement the Touch model, many new concepts, processes and components have been defined. These include:
`1) special hardware devices (such as PDKs containing biometric-equivalent profile storage able to be written to only
`once), 2) the concept of an Authorized TruProx™ Notary, 3) a biometric user setup process that is easily verified,
`audited & trusted, and importantly, only needs to be performed once, and 4) a flexible POK & user verification process,
`enabling multiple levels of authentication (applicable as needed). The levels ranging from simple local verification of a
`POK as an authentic TruProx™ device, through secure lookup of a PDK's background & status in a Centralized
`Registry managed by a trusted third-party.
`
`The Touch model defines a complete, highly-efficient and safe transaction processing model. Illustrating an example
`use/transaction, and assuming a user and their POK have been properly setup (see below), to complete an ·in-store
`purchase, the user simply places their finger on the merchant's Touch Reader device (see below) for a quick scan.
`Once read, the Reader and the user's POK, utilizing a secure wireless communications channel, automatically & ·
`invisibly perform an instantaneous, yet exhaustive & comprehensive authentication involving multiple levels of
`validation. When completed, the device then requests a credit card account number (or similar) from the PDK, and
`either directly or indirectly conducts a standard account number validation check. And assuming a valid account
`number, the transaction is complete. From the user's standpoint, even though a complex authentication &
`authorization has occurred, it appeared as if the entire transaction includes nothing more than a quick swipe of their
`finger. No credit cards or tokens were handled, no signatures were needed, and no PINs, passwords, or search codes
`had to be remembered or entered. The entire process was highly efficient, extremely safe, and_ required no
`participating parties to accept additional risks or liabilities.
`
`Couple the capabilities defined in the above scenario with the fact that this same POK also provides the user with an
`elegantly simple & efficient, biometrically-protected, digital & physical access/use "key" and personal ID system, and
`the value of the model's underlying concept and technology becomes obvious. The sections that follow describe
`important aspects of the TruProx™ Touch Technology.
`
`Note: While the Touch model addresses many needs/uses, because financial transaction .processing best
`illustrates its capabilities and features, most examples herein relate specifically to this use. Some of the
`models other
`intended needs/uses
`include: digital automation/access-control, physicaUdevice
`automation/access-control, basic & biometric ID/Access systems, as well as, in-store, on-line and vending(cid:173)
`based transaction processing.
`
`Confidential - Proxense, LLC
`
`Page3
`
`3
`
`

`

`TruProx™ Touch Technology
`
`Setup:
`
`ATN Overview
`
`The concept of an Authorized TruProx™ Notary ("ATN") is a critical component of the Touch technology trust & audit system.
`An ATN can be conceptually thought of as an enhanced Public Notary. That is, as a trusted third-party providing verification
`that an individual's identification has been properly authenticated prior to the execution of a transaction. In the case of a
`Public Notary, a typical transaction includes witnessing an individual signing a legally-binding document. An ATN performs
`the substantially identical function, except that instead of witnessing a signature being given, an ATN witnesses the_
`acquisition of an authenticated user's biometric data. In Touch model terminology, this 1s referred to as (biometrically)
`initializjng PDKs. In short, an ATN accepts responsibility for ensuring a person's ID and biometric data comply with, and have
`been acquired·& processed according to, defined security protocols.
`
`In addition to initializing PDKs, ATNs are also responsible for adding them to registries. In Touch model terminology, this is
`referred to as registering PDKs. The model defines the concepts of private and central registries. Private registries are, as
`their name implies, private to a particular controlling-entity. For these registries, the controlling-entity is responsible for
`selecting
`its administrative ATN(s). The Central Registry (there
`is only one)
`is managed by a single trusted
`party/organization. The trusted party is solely responsible for selecting ATNs to administer its registry. These ATNs (which
`may also be responsible for administering private registries) are required to pass extensive background checks prior to
`acquiring the accreditation and associated rights.
`
`Importantly, every function an ATN performs, from initializing & registering new users/PDKs, to updating registry data, leaves
`an audit trail which includes the A TN's unique personal & PDK identifiers. An example of this trail is found inside every
`initialized/registered PDK, where the PDK ID of the ATN(s) who performed the processes is permanently stored, along with
`the user's data. This audit data can be retrieved from the PDK's memory (by authorized individuals/hardware) at any time.
`The utilization of ATNs, and the model's established processes & permanent audit system, establish the trust, credibility, and
`confidence underlying the Touch model.
`
`Initialization Overview
`
`The purpose of the initialization process is to load biometric data from the owner/holder of a POK (the "owner") into the
`PDK's permanent biometric profile storage. An initialization, which is administered by an ATN using a specialized Touch
`device ("TouchProgrammer", "Programmer"), can only be performed:once per type per POK. Type is defined within the
`TruProx™ model as a combination of the biologic metric (i.e. fingerprint, retinal scan, etc.) and the specific protection
`scheme/version securing the profile. While the data can be validated again at any time, as an element of the model's "trust",
`it becomes technically unable to be over-written, deleted, etc. Note: While performing initializations in-person with an A TN is
`the preferred method, utilizjng specialized hardware, and technologies such as video conferencing, performing the process
`remotely via PCs, public kiosks, or similar is an option. And depending on need, it may also be acceptable to utilize
`initialization procedures not including A TNs.
`
`Summarizing a fingerprint-based (biometric) initialization example, the process includes a TouchProgrammer performing
`various ATN & POK-related status checks, the owner providing fingerprint samples (usually of each finger but as few a single
`finger print or single biometric indicia) via the TouchProgrammer, and the Programmer writing the data, along with the ATN's
`unique POK ID, to the owner's POK. As a result of this process, the ATN's PDK ID becqmes a permanent element of the
`Touch audit system, and can be traced from any transaction in which the owner's PDK is used. Below are more detailed
`descriptions of these steps.
`
`To begin establishing the model's "trust", the TouchProgrammer.first performs status checks of the ATN's and owner's PDKs
`against the Central Registry. This occurs by the ATN inserting his/her personal PDK, as well as the owner's, into openings in
`the Programmer. Once inserted, the device executes a Central Registry validation on both PDKs (and indirectly, therefore,
`on the ATN) to: 1) ensure the ATN and the ATN's PDK are registered and in good-standing, and 2) ensure the owner's PDK
`is in good-standing (meaning it has not been reported as stolen, lost, or similar ... or has simply never been registered).
`
`Next, assuming the above checks were successfully completed, the TouchProgrammer begins the actual initialization. This
`involves the owner scanning each (desired) finger on the Programmer, one at a time. If needed, the Programmer allows (or
`the ATN and
`requests) re-scans during the process to ensure valid reads of each print are captured. When
`TouchProgrammer are satisfied all desired fingerprints have been adequately acquired, the ATN signals the Programmer to
`write the data to the owner's PDK. The TouchProgramrner then computes mathematical hashes of the data (or sjmilar) and
`instructs the owner's PDK to accept/store the new bio-equivalent data, as well as the ATN's PDK ID, and the Programmer's
`ID, to its permanent biometric profile storage. If desired, the PDK can now be registered. Importantly, when either POK is
`removed from a TouchProgrammer, the device automatically clears its own memory.
`
`Confidential - Proxense, LLC
`
`Page4
`
`4
`
`

`

`TruProx™ Touch Technology
`
`Registration Overview
`
`The purpose of the registration process is to enable enhanced authentication (i.e. additional layers) when processing
`standard/ongoing transactions (see below). As PDK's can only be initialized a single time per type, and o_nly ATNs can
`perform the registration process, an initialized/registeJed PDK effectively becomes a public, "trusted" device, with
`verifiable rights and status. Once registered, a PDK's rights and status can be fully verified by any Touch device in
`communications with the appropriate registry. It should be noted that any PDK, whether or not it has been
`(biometrically) initialized, can be registered. The rights of a given PDK, however, correspond to the type of initialization
`&- registration it has undergone. If desired, though, a PDK can always be re-registered to add additional bio-profiles,
`modify its rights, etc.
`
`In practice, registries are securely-accessed databases comprising, among other items, PDK, ATN, and Touch device
`information ... but no user biometric, bio-equivalent, or highly-personal/critical data. There are two basic registry types:
`private registries and the TruProx™ Central Registry. Private registries are established & administered by their
`controlling-entities (usually to manage specialized/independent needs). The Central Registry, in contrast, is a single,
`highly-secured, centrally-located database run by a trusted third-party entity/organization. To administer (add, modify,
`delete records) any registry, an ATN is required (and must be recorded & in good-standing in the Central Registry).
`ATNs wishing to administer only private registries, however, do not need to complete the extensive background
`checks, etc. required of those administrating the Central Registry.
`
`While a PDK is typically registered immediately following a standard initialization process, it does not have to be. And
`regardless of when performed, the end result is identical. Summarizing, the registration process generally includes an
`ATN validating a PDK's biometric profiles(s) as that of its owner, positively authenticating the owner's.identification,
`and adding/updating a record in an appropriate registry. While performing initializations in-person with an ATN is the
`preferred method, utilizing specialized hardware, and technologies such as video conferencing, performing the process
`remotely via PCs, public kiosks, or similar is an option. And depending on need, it may also be acceptable to utilize
`initialization procedures not including ATNs.
`
`is preferably
`A typical PDK registration session begins by validating the PDK's initialization process. This
`accomplished by the ATN having just witnessed/completed the process. If, however, the initialization process was
`performed at an earlier time, the ATN must re-validate each previously-stored bio-profile. This comprises (using an
`example fingerprint bio-profile) the ATN placing the owner's PDK into a TouchProgrammer (along with their own which,
`as always, is verified by the Programmer against the Central Registry before proceeding), and the owner.subsequently
`placing one finger at a time on the TouchProgrammer. The Programmer (or optionally the PDK, a separate hardware
`and/or software processor, or some combination therein) then compares the newly-acquired prints to what should be
`their equivalents stored in the PDK. If each is successfully matched, the PDK's biometric data is considered authentic,
`and its initialization valid. It should be noted that PDKs can be registered without their biometric data being validated.
`These PDKs, however, cannot successfully authenticate transactions requiring biometric validation (many do not).
`
`Next,
`the ATN
`identification. This generally comprises
`the owner's
`the ATN manually authenticates
`reviewing/validating a defined number of publicly-available/accepted forms of personal identification. These may
`include: a valid driver's license, passport, social security card, or credit card. The specifics of this process can change
`from time-to-time as the managing parties (those defining the model's "trust'') determine/refine what is "acceptable".
`
`With the owner's identity successfully validated, the ATN commands the TouchProgrammer to add/update a record in
`the appropriate registry's database (the ATN must, of course, be recognized as a valid administrator of the registry to
`proceed). The TouchProgrammer then automatically updates certain fields in the record such as the owner & ATN's
`unique POK IDs, while other elements are manually entered by the ATN via a PC/terminal connected to the registry.
`These elements may include the user's name, address, phone number, and date of birth, as well as, optional items
`such as auto-expiration date/time (where the registry automatically "expires" a PDK at a certain point in time).
`
`The final step in the registration process is for the TouchProgrammer to update various fields in the newly-registered
`PDK's internal profile storage. These fields include: the PDK's rights information, the registering ATN's ID, and the
`TouchProgrammer's ID. These audit items, as always, are intended to enhance the underlying "trust" of the Touch
`model by being traceable in the event of fraudulent use. The registered PDK can now; depending on its established
`rights, satisfy private and/or Central registry authentications (as defined below).
`NOTE: Throughout the initialization and/or registration processes, 11.!2. actual biometric data is ever stored or
`maintained anywhere. And bio-equiva'Jent data is stored only in the owner's PDK. And · importantly, when
`either PDK is removed from a TouchProgrammer, the device automatically clears its own memory.
`
`Confidential - Proxense, LLC
`
`Pages
`
`5
`
`

`

`TruProx™ Touch Technology
`
`TouchProgrammer & System
`
`To eliminate the possibility of unintended
`PDKs becoming involved in a programming
`session, the intended PDKs must be placed
`in very close proximity (e.g. in the openings
`shown) of the Programmer in order to
`properly communicate with the device.
`
`Telephone
`Interface
`
`NetwOlk
`Interface
`
`Central
`Registry
`
`Private
`Registry
`#2
`
`TouchProgrammer - A "setup"
`device used to modify a PDK's internal
`profile storage. Consists of: an RDC,
`biometric-reader, status LEDs &
`display, and various 1/0 ports.
`
`PPK Cong,ptt,al llser::Blo PTPtu• Pata fonNl
`
`User Blo-Oata (induding up to 10 fingerprint l"lashes)
`
`~---100-NoReg
`
`01 • Private Reg
`
`10 • Central Reg
`
`11-Multl-Reg
`
`See following page for a step-by-step review of
`TruProx™ Touch Technology Setup Procedures
`
`Confidential • Proxense, LLC
`
`Page6
`
`6
`
`

`

`TruProx™ Touch Technology
`
`Setup: Step-by-Step
`
`The ATN Role & Designation Process
`
`.
`.
`.
`To become an ATN, an individual completes a detailed application (possibly including biometric data, and indicating their
`willingnE:iss to assume certain legal obligaUons), and submits it to ttieATN approval committee (members to be determined).
`When/if approval-is granted, the individual is provided a PDK if needed, and their applicatjon data & unique PDK ID are
`. permanently added to the Central Registry (and updated as needE3_d to indicate chang7s in status, violations incurred, etc.) ..
`If an _ATN does not h_ave access to a· TouchProgrammer ("Programmer"), he/she .is provided one. Each programmer's
`·
`unique ID is recorded in the Central Registry at i~uance,
`
`Any ATN. in good-standing may conduct user (biom~tric) initializations. For aud_it purposes, the unique IDs of the ATN, the
`ATN's POK, and the Touch Programmer utilized in the pro6ess, are permanently stored in the memory of an initialized PDK.
`
`•
`
`•
`
`•
`
`•. To register an initialized PDK (registering rion~initializedPDKs is allowed; but such PDKs are unable to satisfy biometric
`.3uthentications) an ATN designated as an active ,adminj~trator for the interided registry,· is required. ATNs are designated
`as follows:
`·
`·
`·
`·
`•
`. •
`..•·
`.
`:
`• For-a private registry, the owner otthe regi$1ry may designate (or withdraw) ATN(s) of their choosing,
`• • For.. th_e Central Registry, only Proxense (or ,_a . selected third-party, such. as. the_ /ffN apptoval . committee) may
`designate ATNs (who must successfully complete a stringent approval process).'
`· ·
`
`•
`
`•
`
`•
`
`(Biometrically) Initializing PDKs
`
`the
`it),
`in
`Before a new user's PDK can be initialized (have its owner's biometric data permanently stored
`Touch Programmer's ID, an_d _the ATN's _PDK ID must _be validated against the Central Registry as active & in good-standing.
`If all validate, and the ATN has properly conducted the initialization process (see below), the new user's PDK is
`permanently programmed with their new personal bio-profile data. Once written, this data is .. physically" unable to be over-
`.written, modified, or deleted, but can be re-validated by an ATN if needed.""The PDK is. now (biometrically) initialized.
`Following this process, a PDK is typically registered (added to a registry). ThilS _is· not mandatory though, as ATNs can re-
`.
`.
`validate (then register) a PDK at any time.
`
`The initialization process:.
`- A new user's PDK and an ATN's PDK are inserted into the TouchProgrammer.
`- The ATN completes a standard biometric authentication to validate their (personal) presence.
`- The ATN's PDK ID and TouchProgra~mer's 10 ).re authenticated ag.;iinst the Central Registry; Assuming both
`validate, the Programmer becomes temporari_ly enal;lled :(though tim_es-out if not. utilized within a.certain period of time).
`. ..
`.
`.
`- The ATN then instructs the user to scan their fingerprints into the TouchProgrammer. The Programmer allows the user
`·
`to perform each scan as many times·as needed to ensure valid data has been captured.
`- When all prints are input & validated, the ATN instructs the Programmer to permanently write the new bi<rprofile data
`to the user's PDK. Once completed, this procedure can never be redone, though the profile can be re-validated.
`- When either PDK is removed from the TouchProgrammer, the Programmer's memory is automatically erased.
`
`•· ·,
`
`Registering PDKs
`
`To add a PDK to a registry, or "register" it, two basic validations must be successfully completed (regardless of the registry
`type - private or Central). The first is to.confirm the POK being registered is properly initialized. The second is to confirm the
`user's personal identification is correct. This generally consists of the ATN manually authenticating a pre-defined quantity of
`approved personal identifiers (e.g. driver's license, passport, social security card, credit card, etc.) provided by the user. If
`the validations are successfully completed, the ATN enters the following into a database record permanently added to the
`registry:
`• The initializing ATN's personal POK ID
`- The registering ATN's personal POK ID
`• The user's PDK ID
`- The TouchProgrammer's ID
`• The site ID
`- The registration date & time
`- Certain user data items (typically publicly-available items such as an address, phone number, date of birth, etc.)
`- Optional data items such as auto-expiration date/time
`
`•
`
`Finally, the appropriate biometric profile in the user's PDK is updated to indicate the current Registry Code, as well as
`various other identifiers enabling future audits (see "PDK Conceptual User-Bio Profile Data Format" on previous page).
`
`Confidential - Proxense, LLC
`
`Page?
`
`7
`
`

`

`TruProx™ Touch Technology
`
`General Use:
`
`Authentication
`
`The Touch model's critical "trust'' elements - the role of ATNs, and the initialization & registration processes - come
`together in the (transaction) authentication process. The "trust'' established by the previously-described setup
`processes enables an extremely efficient, secure and elegant, yet powerful and scalable authentication process. At the
`very core of the Touch model, and every transaction protected by it, the authentication process builds on, and takes
`advantage of the foundation they provide.
`
`The Touch model's efficiencies begin with the need to perform the model's setup process only once per user. When an
`ATN has completed a user's setup, that user is automatically able to utilize their PDK for any Touch-based application.
`This·is very significant in that, while users clearly benefit by not needing to continually "re-enroll", controlling-entities
`(merchants, account issuers, etc.) similarly benefit by not needing to conduct massive customer enrollments when
`migrating to the technology, as any properly-setup user/PDK is "enrolled". Similarly, both parties greatly benefit from
`the model's specifications for the storage of sensitive biometric data. As a user's biometric data is never stored
`anywhere except within their own PDK, they are never required to put the data at risk by allowing it to be stored in
`merchant or third-party databases ... and merchants, correspondingly, are never required to handle, store, or maintain
`this sensitive data, or expect their customers to trust a third-party to do so. Summarizing, the combination of the Touch
`model's one-time setup design and its data storage specifications, provide the basis for the model's extremely efficient,
`low-risk and scalable protections.
`·
`
`The primary hardware component users interact with during authentication is the Touch Reader. Two general versions
`are defined (though others are envisioned), the simplest of which. is a device called a TouchPad. A TouchPad
`generally has a bio-reader (a fingerprint scanner in these examples), a standard TruProx™ Reader/Decoder/Circuit
`(an "RDC",), a network connection (wired or wireless), and some form of communications (1/0) port (typically USB or
`serial). TouchPads can be thought of as signature-replacement devices, as they are commonly configured as
`supplemental components to credit card terminals. In this role they replace the signature pads typically attached to
`these terminals with the Touch model's wireless digital user/PDK authentication process. The other basic Touch
`Reader is a device called a TouchTerminal. TouchTerminals are simply TouchPads with integrated credit card
`terminals, and are intended to replace standard credit card terminals. But regardless of the Touch Reader, the
`underlying user/PDK authentication process is identical to the point where credit card authorization takes place.
`
`Illustrating a typical in-store check-out scenario with a merchant employing TouchPads at its checkout counters, and a
`customer wishing to utilize their (properly initialized & registered) PDK to complete the purchase: The customer
`presents the items to be purchased to a clerk who scans/rings-up the items, and informs the customer of the amount
`due. To then complete the transaction, the customer simply presses a finger to the TouchPad ... and from their
`standpoint, the sale is complete. No signatures, passwords, PINs, or search codes required, no fumbling with credit
`cards/tokens needed ... a simple fingerprint scan completes the process.
`
`Behind the scenes however, utilizing core TruProx™ technologies (see .related TruProx™ patent filings), the
`customer's PDK and merchant's TouchPad have performed an instantaneous, yet exhaustive & comprehensive
`authentication process involving multiple levels of validation. And importantly, the levels performed were chosen by the
`merchant. As the model's levels are scalable - the higher the level used, the greater the authentication protection -
`merchants can select an appropriate level of authentication for any given transaction. Note: This is generally
`accomplished in one of two ways. A merchant either specifies certain levels for particular transaction types (e.g. sales
`less than $50 do not require biometric authentication, those $50 or greater do), or they simply establish a default level
`in each Touch Reader to be applied to all transactions processed by the device.
`
`Assuming the customer's PDK satisfies the required authentication