Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following is a non-final Office Action in response to application number 19286368 filed on July 31, 2026. Claims 1-20 are currently pending, and have been examined.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-10 are directed to a “method”, and claims 11-20 are directed to a “non-transitory computer-readable medium”. Therefore, these claims are directed to one of the four statutory categories of invention.
Claim 1 recites “authentication for approving a transaction request”, which is a form of commercial or legal interactions and of fundamental economic principles or practices (i.e., organizing human activity), and an abstract idea. Specifically, the claim recites “receiving, by a consumer authentication computing system, account registration information from a consumer computing device associated with a consumer, the account registration information including a unique identifier (UID); generating a consumer account including the account registration information and the UID; receiving a biometric profile of the consumer, the biometric profile including a digital representation of a select physical feature of the consumer; storing the generated consumer account and the biometric profile in a memory device of the consumer authentication computing system; receiving, from the consumer computing device, a transaction request message including a transaction request; in response to the transaction request, transmitting an authentication request message to the consumer computing device; receiving an authentication response message from the consumer computing device, the authentication response message including a biometric sample; determining that the biometric sample matches the biometric profile of the consumer above a predetermined lower threshold value and below a predetermined upper threshold value; in response to the determination, establishing a wireless connection to an integrated electronic circuit device that is separate from the consumer computing device, the integrated electronic circuit device being associated with a face covering of a user and storing the UID thereon, the UID being associated with the integrated electronic circuit device; reading, via the wireless connection, the UID from the integrated electronic circuit device; and approving the transaction request if the read UID matches the UID of the generated consumer account”. The abstract idea is in italics, and the additional elements are in bold. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “a consumer authentication computing system”, “a consumer computing device”, “a digital representation”, “a memory device of the consumer authentication computing system”, “establishing a wireless connection to an integrated electronic circuit device that is separate from the consumer computing device, the integrated electronic circuit device”, and “reading, via the wireless connection, the UID from the integrated electronic circuit device”, amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “authentication for approving a transaction request”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of “authentication for approving a transaction request” using computer technology (e.g., “a consumer authentication computing system” and “a memory device”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 1 is non-statutory.
Claim 11 also recites the abstract idea of “authentication for approving a transaction request”, as well the additional elements of “a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to: …”, “a consumer authentication computing system”, “a digital representation”, “a memory device of the consumer authentication computing system”, “establish a wireless connection to an integrated electronic circuit device that is separate from the consumer computing device, the integrated electronic circuit device”, and “read, via the wireless connection, the UID from the integrated electronic circuit device”, which amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “authentication for approving a transaction request”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of “authentication for approving a transaction request” using computer technology (e.g., “a non-transitory computer-readable medium storing instructions” and “one or more processors”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 11 is non-statutory.
Dependent claims 2-10 and 12-20 further describe the abstract idea of “authentication for approving a transaction request”, which is insufficient to overcome the rejections of claims 1 and 11.
Dependent claims 2-3, 5-10, 12-13, and 15-20 do not recite any new additional elements that integrate the abstract idea into a practical application, and that do no more than represent a computer performing functions that correspond to implementing the acts of “authentication for approving a transaction request”, when analyzed under Step 2A, Prong Two. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field, when analyzed under Step 2B.
Dependent claim claims 4 and 14 recite a new additional element of “a digital wallet application on the consumer computing device”, which does no more than employ a computer as a tool to implement the abstract idea. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality nor improve another technology or a technical field.
Hence, claims 1-20 are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. § 102 and § 103 (or as subject to pre-AIA 35 U.S.C. § 102 and § 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U. S. 1. 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 6, 9-13, 16, and 19-20 are rejected under 35 U.S.C. § 103 as being unpatentable over McKenna (U. S. Patent Application Publication No. 20140214670 A1), herein referred to as McKenna, in view of Kopf (U. S. Patent Application Publication No. 20190139051 A1), herein referred to as Kopf, and in further view of Dershem (U. S. Patent Application Publication No. 20220147972 A1), herein referred to as Dershem.
Regarding claims 1 and 11, McKenna discloses a method comprising:
receiving, by a consumer authentication computing system (McKenna, FIG. 1, items 108, 114; para 58, “… The secured transaction server 108 can be seen having an identity verification agent (IVA) 114 running on the STS 108, both of which are connected to the network 100 …”), account registration information from a consumer computing device associated with a consumer (McKenna, FIG. 1, item 104; para 56, “… the network includes a mobile electronic device 104, a merchant 106, a secured transaction server (STS) 108, and a financial institution 110 … the merchant 106 is communicatively coupled to the mobile electronic device 104 such that is may receive and transfer information, …”; para 71, “… The mobile electronic device 104 also includes a computing means, e.g., a processor, and a storing means, e.g., a memory. The processor is operable to run one or more programs/applications and interfaces associated with the mobile electronic device 104 or stored on the memory in order to effectuate the data transfer and communications required by the present invention …”) the account registration information including a unique identifier (UID) (McKenna, para 77, “… the user installs and launches a mobile application on the portable electronic device 104 that facilitates the log-in with the IVA 114. The user then uses the mobile electronic device 104 to upload a user-identifier with the IVA 114. This user-identifier may consist of a unique log-in user name or password. This may also include user-identifying information such the user's address, phone number, a photo of the user, biometric data, e.g., retinal/facial scan and fingerprints, and other user-identifying information. This user-identifying information may also be received and associated with any authorized persons desired by the user, e.g., a child/parent of the user. When the user uploads at least one piece of user-identifying information, a "user account" is created that resides on, or is otherwise accessible to, the STS 108 for future reference. This user-identifying information may be stored on the database 120 that is communicatively coupled to the IVA 114 … financial information of the user, e.g., credit/debit card information, may also be received by the STS 108 and stored on the database 120. Importantly, this database 120 and IVA 114 is not operated or maintained by the merchant 106. Therefore, the user's personal information is securely stored on a remote server which is symptomatic of most other known fraud pre-vention systems associated with merchant transactions …”);
generating a consumer account including the account registration information and the UID (McKenna, para 14, “… a method for verifying a consumer's identity in connection with a transaction involving a consumer and a merchant includes the steps of receiving a user-identifier from a user, receiving a unique mobile device identifier from a mobile electronic device associated with the user, associating the user-identifier and the unique mobile device identifier of the user to a user account that resides on or is at least accessible to a secured transaction server, where the secured transaction server is not operated by the merchant and includes an identity verification agent …”; para 27, “… verifying a consumer's identity in connection with transaction involving a consumer and a merchant includes the steps of communicating a user-identifier from a user to a secured transaction server, communicating a unique mobile device identifier from a mobile electronic device associated with the user to the secured transaction server, associating the user-identifier and the unique mobile device identifier of the user to a user account residing on the secured transaction server, the secured transaction not operated by the merchant …”; para 77, “… When the user uploads at least one piece of user-identifying information, a "user account" is created that resides on, or is otherwise accessible to, the STS 108 for future reference. This user-identifying information may be stored on the database 120 that is communicatively coupled to the IVA 114 … financial information of the user, e.g., credit/debit card information, may also be received by the STS 108 and stored on the database 120 …”); …
receiving, from the consumer computing device (McKenna, FIG. 1, item 104; paras 56 and 71), a transaction request message including a transaction request (McKenna, FIG. 17, item 1702; para 132, “… The process 436 starts at step 1700 and then immediately proceeds to step 1702 of the consumer submitting the payment identifier and the payment amount to the secured transaction server (STS) 108 … this is generally transmitted through the consumer's mobile electronic device 104 … the inventive consumer authentication process should be carried out before the payment request is sent to the user's financial institution 110, i.e., the settlement process … the settlement process 436 may occur after the consumer's identity has been authenticated …”; FIG. 17, item 1704; para 134, “… The next step 1704 includes the STS 108 submitting the payment request to the consumer's financial institution 110 for reimbursement …”; FIG. 17, item 1706; para 136, “… The next step 1706 includes the STS 108 receiving an approval or denial from the user's financial institution 110. This financial transaction data may be stored on the database 120 of the STS 108 or any other storing medium …”);
in response to the transaction request, transmitting an authentication request message to the consumer computing device (McKenna, FIG. 4b, items 422, 424; para 98, “… With reference to FIG. 4b, after the step 422 of communicating the payment identifier to the STS 108, the process continues to the step 424, or the identity verification agent (IVA) 114 engaging in the verification process, thereby comparing the information generated by the user with the information generated by the consumer. This verification process is shown in more detail in FIG. 11. As this financial transaction is initiated, at least partially, with the mobile device … the IVA 114 compares the unique mobile device identifier, e.g., MAC address, of the user (including authorized users) to the unique mobile device identifier of the consumer …”; FIG. 11, item 1118; para 112, “… the process 424 includes the authentication step 1118 of requesting an authentication passcode, or "code" from the consumer. This code may be inputted by the consumer at the POS terminal or on an inter-face generated by the exemplary application running on the consumer's mobile device 104. This code may be provided by the user at initial registration, or at some point thereafter …”); …
approving the transaction request if the read UID matches the UID of the generated consumer account (McKenna, FIG. 11, items 1102, 1104; para 103, “… process starts at step 1100 and then immediately flows to step 1102, which, in one inventive authentication protocol, includes receiving the unique mobile device identifier from the consumer, e.g., the MAC address. Step 1104 includes comparing the consumer's mobile device identifier with the user's mobile device identifier. Step 1106 includes querying, through the IVA 114 … whether the consumer's and user's mobile device identifier match with one another. This allows the STS 108 to verify whether the mobile electronic device 104 utilized for the financial transaction is authorized or unauthorized in accordance with the user's preference ...”; para 109, “… If the consumer's voice identifier matches or corresponds to the stored user identifier, the STS 108, or IVA 114, may authorize the transaction. Again, if there is no match, identity verification is denied … ).
McKenna does not specifically disclose, however, Kopf discloses receiving a biometric profile of the consumer, the biometric profile including a digital representation of a select physical feature of the consumer (Kopf, FIG. 8, item 801; para 104, “… At step 801 a unique identifier is received from a registration device. The unique identifier can be derived from a first biometric sample associated with a registrant using a derivation process. The first biometric sample can be captured by a biometric sample reader associated with the registration device. Additionally, the unique identifier can be derived by the registration device by applying the derivation process …”; FIG. 8, item 804; para 107, “… At step 804 a second biometric sample associated with the registrant is received from a biometric repository and transaction information corresponding to an attempted transaction of the registrant with a merchant is also received … The biometric repository can be configured to receive the second biometric sample from a merchant computing device associated with the merchant and verify that the second biometric sample corresponds to a known biometric sample prior to transmitting the second biometric sample …);
storing the generated consumer account and the biometric profile in a memory device of the consumer authentication computing system (Kopf, para 60, “… During the registration step, account information is also entered or captured utilizing the registration unit which encrypts the account information and sends it to the first repository. The first repository then decrypts the submitted account information data …”; para 61, “… Upon completion of the registration of multiple biometric samples, the first repository generates a digital secure identification number (SIN) utilizing quantum random number generation. This SIN is linked to the first repository's biometric samples and utilized internally, only, to compare and validate the biometric sample to the registered account of the end-user. During registration, this SIN is provided by the system to the identified card/account issuer for linking to the identified account …”); …
receiving an authentication response message from the consumer computing device, the authentication response message including a biometric sample (Kopf, FIG. 8, item 804; para 104, “… At step 804 a second biometric sample associated with the registrant is received from a biometric repository and transaction information corresponding to an attempted transaction of the registrant with a merchant is also received … The biometric repository can be configured to receive the second biometric sample from a merchant computing device associated with the merchant and verify that the second biometric sample corresponds to a known biometric sample prior to transmit-ting the second biometric sample, as discussed earlier. Since the second biometric sample is from the same registrant (e.g., a fingerprint of the same finger from the same user), the second biometric sample matches the first biometric sample, where matching can assessed by the pattern recognition algorithms discussed earlier …”);
determining that the biometric sample matches the biometric profile of the consumer above a predetermined lower threshold value and below a predetermined upper threshold value (Kopf, para 48, “… Fingerprint data may also be collected from a pre-selected finger for emergency alarm purposes such that when the pre-selected finger is read by the system's finger print reader, an alarm is forward to authorities Fingerprint data is translated by the system into a template storage format, thus not only preserving accuracy but also reducing data size. Specifically, the minutiae from a fingerprint are extracted by a software algorithm; images from the fingerprint reader are extracted into templates. These templates are data structures created by an algorithm that map the minutiae and patterns in relation to the center of the fingerprint. The resulting map is a set of coordinates that can be searched using matching algorithms …”; FIG. 8, item 804; para 107, “… The biometric repository can be configured to receive the second biometric sample from a merchant computing device associated with the merchant and verify that the second biometric sample corresponds to a known biometric sample prior to transmit-ting the second biometric … Since the second biometric sample is from the same registrant (e.g., a fingerprint of the same finger from the same user), the second biometric sample matches the first biometric sample, where matching can assessed by the pattern recognition algorithms …”; …
Kopf discloses a biometric secure transaction system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a biometric secure transaction system, as in Kopf, to improve and/or enhance the technology for a method for verifying a consumer’s identity within a consumer/merchant transaction, as in McKenna, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a system to overcome and/or eliminate the following drawbacks related to convenience and security in current technology when conducting a transaction: card use – must utilize the card in the transaction; risk of a lost card or data/personally identifiable information (PII) hacking or “interception” before or during use in a transaction; card replacement with new account number; radio frequency and related electronic payment methods – PII/account data is still resident in the “unit” subject to hacking, theft and misuse; lost unit precludes use and allows for possible identity theft; PII/account data transmitted unencrypted from POS subject to “intermediary” interception/hacking, which would be an improvement for authentication and implementing secure transactions be they financial, data-based or identity-based.
McKenna and Kopf do not specifically disclose, however, Dershem discloses in response to the determination, establishing a wireless connection to an integrated electronic circuit device (Dershem, FIG. 3, item 40; para , “… FIG. 3 shows mask 10 in operation as the user 80 pays for the goods and services using electronic device 40. The electronic device 40 may be a near-field communication (NFC) device, a Wi-Fi device, a Bluetooth device, a 4G, 5G, 3GPP or other electronic device which can communicate by emission or reception of electromagnetic communication waves 60. Whether the device 40 emits or receives waves 60 will be dependent on the nature of payment device 50 that electronic device 40 is intended to interact with …”) that is separate from the consumer computing device (Dershem, FIG. 3, item 50; para 15, “… Any type of reciprocal payment device 50 may be used with mask 10 and electronic device 40 so long as the electronic device 40 is adapted to communicate with payment device 50. When QR codes are used in electronic device 40, then payment device 50 scans electronic device 40 so that data and information can be exchanged between the two devices to effect payment for goods or services …”), the integrated electronic circuit device being associated with a face covering of a user (Dershem, FIG. 3, item 10; para 12, “… The mask 10 is further constructed to include an electronic device 40 sewn or otherwise secured to the pliable material 20. The electronic device 40 may be an active or passive electronic device that allows the user to interact with a payment device 50 in an appropriate socially distant manner to allow the user to pay for goods or services at the payment device. Electronic device 40 may be … and electronic semiconductor chip adapted to interact with the payment device 50, a small, printed circuity board adapted to interact with the payment device, a flexible printed circuit board adapted to interact with the electronic device, or any other electronic device that is attachable to the pliable material 20 by a glue, stitching or similar modality. The electronic device may be a readable bar code or quick code known to those skilled in the art depending on the capabilities of the payment device that will read electronic device 40 …) and storing the UID thereon, the UID being associated with the integrated electronic circuit device (Dershem, para 13, “… The quick codes can be embedded at time of manufacturing or placed on mask 10 in a replaceable or reloadable fashion. Each code is uniquely identified when the consumer first registers and receives their masks. The mask 10 may be tied to a user account where a smart digital wallet is accessed. Other self-authorized information could also be provided as well … in a healthcare setting instead of using a paper and pen, iPad, or kiosks for providing patient intake forms and insurance information, the masks and electronic devices described herein could be utilized to store the user or patient information for each user or patient in a personalized manner and the electronic device could transfer that information to the network in a touch-free manner …”); …
reading, via the wireless connection, the UID from the integrated electronic circuit device (Dershem, FIG. 3; para 8, “… FIG. 3 is a view of the smart mask of FIG. 1 interacting with an electronic reader …”; para 15, “… Whether the device 40 emits or receives waves 60 will be dependent on the nature of payment device 50 that electronic device 40 is intended to interact with. Any type of reciprocal payment device 50 may be used with mask 10 and electronic device 40 so long as the electronic device 40 is adapted to communicate with payment device 50 …”) ; and …
Dershem discloses smart masks for data exchange. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include smart masks for data exchange, as in Dershem; and to include a biometric secure transaction system, as in Kopf, to improve and/or enhance the technology for a method for verifying a consumer’s identity within a consumer/merchant transaction, as in McKenna, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide protective face coverings having the capability to interact electronically with devices while avoiding physical contact with devices or machine readers involving frequent touching, avoiding physical interaction with a person, and/or avoiding close personal contact and proximity to engage in commerce, while providing identification of the user.
Regarding claims 2 and 12, McKenna, Kopf, and Dershem disclose the limitations of claims 1 and 11. McKenna further discloses the method in accordance with claim 1, wherein receiving the account registration information comprises receiving an enrollment request message from the consumer computing device (McKenna, para 77, “… the user installs and launches a mobile application on the portable electronic device 104 that facilitates the log-in with the IVA 114. The user then uses the mobile electronic device 104 to upload a user-identifier with the IVA 114. This user-identifier may consist of a unique log-in user name or password. This may also include user-identifying information such the user's address, phone number, a photo of the user, biometric data, e.g., retinal/facial scan and fingerprints, and other user-identifying information. This user-identifying information may also be received and associated with any authorized persons desired by the user, e.g., a child/parent of the user. When the user uploads at least one piece of user-identifying information, a "user account" is created that resides on, or is otherwise accessible to, the STS 108 for future reference. This user-identifying information may be stored on the database 120 that is communicatively coupled to the IVA 114 … financial information of the user, e.g., credit/debit card information, may also be received by the STS 108 and stored on the database 120. Importantly, this database 120 and IVA 114 is not operated or maintained by the merchant 106. Therefore, the user's personal information is securely stored on a remote server which is symptomatic of most other known fraud pre-vention systems associated with merchant transactions …”).
Regarding claims 3 and 13, McKenna, Kopf, and Dershem disclose the limitations of claims 1 and 11. McKenna further discloses the method in accordance with claim 1, further comprising prompting, via a push notification, the consumer to input the biometric profile via the consumer computing device (McKenna, FIG. 4b, item 424; FIG. 11, item 1116; para 109, “…the process 424 includes step 1116 of capturing the consumer's biometric data … prompting the consumer for voice identification data …”; para 110, “… Other biometric data that may be captured from consumer includes a retinal scan of the consumer's retina (using the camera of the mobile electronic device 104 for example), a fingerprint of the consumer (using the screen of the mobile electronic device 104 for example), among other biometric identifier …”; para 111, “… Another biometric authentication protocol includes capturing an image of the consumer's face. With reference to FIG. 13, a screenshot 1300 of an interface generated by the exemplary software implementing this feature is shown. Although this may be accomplished by the mobile device 104 of the consumer, an image may also be captured by a camera associated with, or located within the physical proximity of, the POS terminal of the merchant 106 … the image is captured and communicated to the IVA 114 for facial recognition, based on a stored set of facial data values for an authorized user. As methods and devices for determining facial data values from a person is known in the art …”).
Regarding claims 6 and 16, McKenna, Kopf, and Dershem disclose the limitations of claims 1 and 11. McKenna further discloses the method in accordance with claim 1, further comprising:
determining the read UID matches the UID of the generated consumer account based on comparing the biometric sample to the biometric profile (McKenna, para 22, “… the secondary user authentication includes receiv-ing and storing a digital image of the user, communicating the user's digital image to the merchant, displaying the user's digital image to a display associated with the merchant, visually comparing the user's digital image to a consumer's image to determine the at least one of the positive user-identity verification and the failed user-identity verification, and receiving, from the merchant, the at least one of the positive user-identity verification and the failed user-identity verification for the user-identity-verification indicator …”; para 30, “… initiating a secondary user authentication upon determining the at least one of the positive user-identity verification and the failed user-identity verification, where the secondary user authentication includes receiving a user's biometric data at the secured transaction server, receiving a consumer's biometric data at the secured transaction server, and comparing, through the identity verification agent, the user's biometric data and the consumer's biometric data to determine the at least one of the positive user-identity verifi-cation and the failed user-identity verification …”; para 111, “… Another biometric authentication protocol includes capturing an image of the consumer's face. With reference to FIG. 13, a screenshot 1300 of an interface generated by the exemplary software implementing this feature is shown. Although this may be accomplished by the mobile device 104 of the consumer, an image may also be captured by a camera associated with, or located within the physical proximity of, the POS terminal of the merchant 106 … the image is captured and communicated to the IVA 114 for facial recognition, based on a stored set of facial data values for an authorized user. As methods and devices for determining facial data values from a person is known in the art, a detailed description will not be done … the merchant 106, through software including the 114, may carry out the facial comparison between the user and the consumer … the image is communicated to the secured transaction server 108 for analysis by the IVA 114. The comparison option is shown on the exemplary interface with the link 1302 … the IVA 114 may be operable to read images associated or available on one or more social media servers 202 and compare those facial data values to those of the consumer …”); and
determining a match percentage of the comparison (McKenna, FIG. 12, item 1202; para 108, “… FIG. 12 is a screenshot 1200 of an exemplary application running on a server associated with the merchant 106 … once the STS 108 receives a payment/identity verification request, the IVA 114 will cause an image 1202 of the user to display. This image 1202 will allow visual confirmation by an agent/representative of the merchant 106. Opposed to those known fraud prevention systems, the present invention requires an active verification by the agent/ representative of the merchant before the financial transaction can be carried out. Therefore, the agent/representative will either confirm or deny the identity of the consumer. Again, if the clerk confirms the identity the transaction may continue. If the clerk denies the identity, the transaction will be refused by the IVA 114, STS 108, or both …”; FIG.11, items 424, 1116; para 109, “… the process 424 includes step 1116 of capturing the consumer's biometric data … prompting the consumer for voice identification data. This voice identification data may be taken from a microphone associated with the mobile device 104 or a device associated with the merchant 106. The voice identification data, e.g., audio signal, may then be converted from an analog wave to a digital fingerprint of the consumer's voice. This digital data may then be compared to the registered/authorized user sample taken at registration (or some time thereafter). If the consumer's voice identifier matches or corresponds to the stored user identifier, the STS 108, or IVA 114, may authorize the transaction. Again, if there is no match, identity verification is denied …”).
Regarding claims 9 and 19, McKenna, Kopf, and Dershem disclose the limitations of claims 1 and 11. McKenna further discloses the method in accordance with claim 1, wherein determining whether the read UID matches the unique identifier UID of the generated consumer account comprises:
retrieving the UID included in the generated consumer account (McKenna, FIG. 4a, item 404; para 79, “… Before, during, or after the initial log-in with the IVA 114, the IVA 114 may receive a mobile electronic device identifier from the mobile electronic device 104 that is associated with the user or any other authorized persons … the mobile electronic device identifier may be an electronic device identifier, i.e., a unique identifier from an electronic device that is not necessarily mobile … the unique electronic device identifier originates from what is known in the art as a "smart device," or an electronic device that is cordless, mobile, connected to the above described network, and capable of voice and video communication, Internet browsing, and providing a geographic location. This is reflected in step 404 of FIG. 4a. As the mobile electronic device 104 is used to initiate the financial transaction with the merchant, this advantageously gives the user and the merchant a baseline comparison parameter to verify the identity of the consumer, i.e., is the consumer authorized or unauthorized? … the mobile electronic device identifier is the only authentication protocol used by inventive fraud prevention process … the mobile electronic device identifier may be used in combination with other authentication protocols …”); and
comparing the read UID to the retrieved UID stored in the generated consumer account (McKenna, para 80, “… The unique mobile device identifier permits the IV A 114 to determine whether portable electronic device 104 initiating the merchant/consumer transaction is the actual/authorized portable computing device 104, instead of a fraudulent device alleging to be the portable computing device 104. The unique identifier can be a piece of information that is generally only shared or associated with a limited number of mobile electronic devices 104 … fraudulent device may attempt to submit a financial transaction between a merchant 106 and the consumer to the STS 108, claiming to be an authentic user; however, if the Wi-Fi or MAC address indicates that the fraudulent device is not the registered mobile device 104, but instead a desktop computer, then the STS 108 will alert the merchant 106 or simply deny the transaction. Included within step 404, in one embodiment, is the STS 108 associating the user-identifying information and the mobile device identifier with the user's account …”; FIG. 11, item 1104; para 103, “… process starts at step 1100 and then immediately flows to step 1102, which, in one inventive authentication protocol, includes receiving the unique mobile device identifier from the consumer, e.g., the MAC address. Step 1104 includes comparing the consumer's mobile device identifier with the user's mobile device identifier. Step 1106 includes querying, through the IVA 114 … whether the consumer's and user's mobile device identifier match with one another. This allows the STS 108 to verify whether the mobile electronic device 104 utilized for the financial transaction is authorized or unauthorized in accordance with the user's preference …”; para 106, “… This digital image, which essentially is a physical likeness or representation of the user, allows the merchant 106 to actively confirm the identity of the user before the transaction is approved without any financial information actually exchanging between the merchant and the consumer. Following the process out, step 1128 includes comparing the consumer response to the user response data … the consumer response is the consumer's visual appearance wherein the stored user response data is the image of the registered/authorized user ...”; para 145, “… The consumer then sends that information to the secured transaction server (STS) where the STS participates in an authentication process based on one or more verification parameters. One important verification parameter/protocol includes comparing a stored unique mobile device identifier, e.g., MAC address, given by the user to the unique mobile device identifier generated by the portable device of the consumer ...”).
Regarding claims 10 and 20, McKenna, Kopf, and Dershem disclose the limitations of claims 1, 9, 11, and 19. McKenna further discloses the method in accordance with claim 9, further comprising denying the transaction request, if the read UID and the retrieved UID do not match (McKenna, FIG. 4b, item 430; para 99, “… As security and authentication protocols of financial institutions continually increase and change, the financial institution may require other information to carry out the financial transaction. If the IVA 114 determines that the consumer's identity has not been verified (also referred to as a "failed user-identity verification"), the process follows to the step 430 of denying the financial transaction …”).
Claims 4-5 and 14-15 are rejected under 35 U.S.C. § 103 as being unpatentable over McKenna (U. S. Patent Application Publication No. 20140214670 A1), herein referred to as McKenna, in view of Kopf (U. S. Patent Application Publication No. 20190139051 A1), herein referred to as Kopf, in view of Dershem (U. S. Patent Application Publication No. 20220147972 A1), herein referred to as Dershem, and in further view of Lacoss-Arnold (U. S. Patent Application Publication No. 20180189788 A1), herein referred to as Lacoss-Arnold.
Regarding claims 4 and 14, McKenna, Kopf, and Dershem disclose the limitations of claims 1 and 11. McKenna, Kopf, and Dershem do not specifically disclose, however, Lacoss-Arnold discloses the method in accordance with claim 1, wherein transmitting the authentication request message to the consumer computing device (Lacoss-Arnold, FIG. 1, items 112; para 49, “… System 100 further includes at least one client device 112 with access to a digital wallet 122 …”) comprises pushing the authentication request message (Lacoss-Arnold, para 24, “… the card-holder uses the client device to access the digital wallet app in order to initiate the two factor authentication process. The two factor authentication process utilizes the digital wallet to send an authentication signal to the authentication comput-ing device over a first communication network (Internet, cellular network, etc.), or first computer network. The two factor authentication method includes a two-step verification that provides an extra layer of security by requiring a password/username and a piece of information that only the user can provide, such as a biometric ( e.g., fingerprint, iris scan, selfie picture, etc.) as the first authentication step. The authentication computing device is further configured to store account data, device metadata, and biometric data (sample biometric data) when the cardholder registers and downloads the digital wallet to the user device, which is used for the second step of authentication …”; para 25, “… the cardholder initiates a payment transaction with a simple merchant. Because the cardholder's digital wallet cannot be used with the simple merchant, the cardholder must initiate the payment transaction with a physical payment card … the cardholder may want to take advantage of using the two factor pre-authentication process or may be required to use the pre-authentication process by certain controls that may be applied to the account by either the issuer or the payment processor … the cardholder initiates the pre-authentication process by accessing the digital wallet on their client device ...”) to a digital wallet application (Lacoss-Arnold, FIG. 1, items 122; para 49, “… Digital wallet 122 stores and processes cardholder 114 and card account information … device metadata, biometric data, and/or a card account number … digital wallet 122 is a software application that stores card payment data, wherein client device 112 is a mobile device or a non-mobile electronic device and is configured to access digital wallet 122 application software …”) on the consumer computing device.
Lacoss-Arnold discloses pre-authenticating a user of a payment card over a network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include pre-authenticating a user of a payment card over a network, as in Lacoss-Arnold; to include smart masks for data exchange, as in Dershem; and to include a biometric secure transaction system, as in Kopf, to improve and/or enhance the technology for a method for verifying a consumer’s identity within a consumer/merchant transaction, as in McKenna, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a system that allows merchants to provide the increased security of digital payment transactions that use digital enablement services without having to incur the expenses of adding or upgrading company equipment to accept such digital payment transactions.
Regarding claims 5 and 15, McKenna, Kopf, and Dershem disclose the limitations of claims 1 and 11. McKenna, Kopf, Dershem, and Lacoss-Arnold disclose the limitations of claims 4 and 14. McKenna, Dershem, and Lacoss-Arnold do not specifically disclose, however, Kopf discloses the method in accordance with claim 4, said authentication request message comprising an instruction to enter the biometric sample into the consumer computing device (Kopf, FIG. 7; para 58, “… During registration, the participant registers within the system utilizing a registration unit having a biometrics reader associated thereto by submitting multiple biometric samples using the system's stand-alone biometric capture hardware tied directly to a repository system including two separate, out-of-band secure repositories. The system is capable of capturing and analyzing biometric samples individually and in multiples including one specific identified biometric sample to be utilized solely for critical or special purposes. Biometric samples are captured by the biometrics reader and are also translated into template storage format using encryption to ensure secure transmission capability to the repository …”; para 61, “… Upon completion of the registration of multiple biometric samples, the first repository generates a digital secure identification number (SIN) utilizing quantum ran-dom number generation. This SIN is linked to the first repository's biometric samples and utilized internally, only, to compare and validate the biometric sample to the regis-tered account of the end-user. During registration, this SIN is provided by the system to the identified card/account issuer for linking to the identified account …”).
Kopf discloses a biometric secure transaction system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a biometric secure transaction system, as in Kopf; to include pre-authenticating a user of a payment card over a network, as in Lacoss-Arnold; and to include smart masks for data exchange, as in Dershem, to improve and/or enhance the technology for a method for verifying a consumer’s identity within a consumer/merchant transaction, as in McKenna, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a secure transaction system that does not require or rely on any additional tokens or devices that are stored or used, all of which are subject to being hacked, intercepted, stolen and typically utilized in ID theft/fraud.
Claims 7-8 and 17-18 are rejected under 35 U.S.C. § 103 as being unpatentable over McKenna (U. S. Patent Application Publication No. 20140214670 A1), herein referred to as McKenna, in view of Kopf (U. S. Patent Application Publication No. 20190139051 A1), herein referred to as Kopf, in view of Dershem (U. S. Patent Application Publication No. 20220147972 A1), herein referred to as Dershem, and in further view of Sarin (U. S. Patent Application Publication No. 20190199793 A1), herein referred to as Sarin.
Regarding claims 7 and 17, McKenna, Kopf, and Dershem disclose the limitations of claims 1 and 11. McKenna, Kopf, and Dershem do not specifically disclose, however, Sarin discloses the method in accordance with claim 1, further comprising, in response to the determination, determining that a wireless connection cannot be established to the integrated electronic circuit device (Sarin, para 13, “… On detection of the condition indicating a predicted non-operation or failure of the communication device or loss of communication signaling between the device and the service provider … The mode may correspond to a low power mode or transition mode, where the service provider estab-lishes or triggers a state for the device that begins caching data as it is input into an application to store the data in case of device failure or lack of communications with the device …”; para 15, “… if the service provider determines that the device is no longer active, such as if the device has become inoperable due to battery power or no longer has network connectivity, the service provider may proceed to utilize the data cache to successfully complete electronic transaction processing for the transaction. The device may be detected as inoperable based on a signal sent to the device or received from the device, or may be detected based on a lack of responsive signals to the service provider … if the service provider pings the communication device and does not receive a responsive signal. Thus, if the device is detected as being inoperable or unable to send and receive communication signals, …”; para 26, “… System 100 includes a first communication device 110, a second communication device 120, and a service provider server 130 in communication over a network 150. A first user (not shown) may utilize first communication device 110 to request service provider server 130 execute and/or complete processes of first communication device 110 in the event of failure of first communication device 110. First communication device 110 may detect a condition of future non-operation and/or failure of first communication device 110, and determine electronic transaction processing data for a pending transaction being processed on first communication device 110 with second communication device 120 …”).
Sarin discloses a network cache of device input for redundancy during device inoperability. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a network cache of device input for redundancy during device inoperability, as in Sarin; to include smart masks for data exchange, as in Dershem; and to include a biometric secure transaction system, as in Kopf, to improve and/or enhance the technology for a method for verifying a consumer’s identity within a consumer/merchant transaction, as in McKenna, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide methods for handling situations that occur where the users may be left without device functionality, and thus be prevented using their devices to continue utilizing processes and applications on their devices, which may cause repeated entry of data and use of a process, thereby potentially causing multiple transaction processes.
Regarding claims 8 and 18, McKenna, Kopf, and Dershem disclose the limitations of claims 1 and 11. McKenna, Kopf, Dershem, and Sarin disclose the limitations of claims 7 and 17. McKenna, Kopf, and Dershem do not specifically disclose, however, Sarin discloses the method in accordance with claim 7, further comprising denying the transaction request based on the determination that a wireless connection cannot be established (Sarin, para 15, “… if the service provider determines that the device is no longer active, such as if the device has become inoperable due to battery power or no longer has network connectivity, the service provider may proceed to utilize the data cache to successfully complete electronic transaction processing for the transaction. The device may be detected as inoperable based on a signal sent to the device or received from the device, or may be detected based on a lack of responsive signals to the service provider … if the service provider pings the communication device and does not receive a responsive signal. Thus, if the device is detected as being inoperable or unable to send and receive communication signals, the service provider may mark the pending transaction a pending or transition pending based on the cached data instead of marking the transaction as failed. The service provider may not delete the transaction and transaction data without completing the transaction, and thereby restore the user's account and financial instruments to a previous state prior to loss of the transaction processing, which may be done if the transaction is marked as failed. Instead, by marking the transaction as transition pending, the service provider may proceed with electronic transaction processing using the cached data ...”; para 28, “… first communication device 110 may correspond to a failing device or a device predicted to fail or become non-opera-tional with respect to a specific process being handled by the device, generally a device that may not be able to complete a current or predicted process or operation of an application for electronic transaction processing …”; para 49, “… Note that failure, non-operation, inoperability, or similar descriptions of the communication device generally refers to the communication device being unable to perform or complete an action or process currently being performed by the communication device at a future time and does not require the device to fail completely, which may include signal loss or unresponsive communications with first communication device 110. In this regard, device operations monitoring application 140 may correspond to specialized hardware and/or software to perform one or more of the processes described in references to transaction processing application 112 of first communication device 110 to receive signaling of an inoperable condition and determine if and when first communication device 110 has failed …”; para 50, “… Device operations monitoring application 140 may be used for detection of a condition of future failure/non-operation of first communication device 110, determination of process data in use on first communication device 110 during electronic transaction processing, cache the data as pending transaction data, and detect if/when first commu-nication device 110 has failed …”).
Sarin discloses a network cache of device input for redundancy during device inoperability. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a network cache of device input for redundancy during device inoperability, as in Sarin; to include smart masks for data exchange, as in Dershem; and to include a biometric secure transaction system, as in Kopf, to improve and/or enhance the technology for a method for verifying a consumer’s identity within a consumer/merchant transaction, as in McKenna, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide methods for handling situations that occur where the users may be left without device functionality, and thus be prevented using their devices to continue utilizing processes and applications on their devices, which may cause repeated entry of data and use of a process, thereby potentially causing multiple transaction processes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Torre (U. S. Patent Application Publication No. 20220075862 A1) – System And Method For Facial Recognition Authentication For Mask Wearers
Torre discloses a system and method for authenticating a face mask with a user for providing secure access to a user device whereby received on the user device is a request from the user to pair a user face mask having a pre-printed unique identifier with the user device for user authentication purposes. The user device captures an image of the pre-printed unique identifier on the user face mask so as to associate the captured image of the unique identifier with the user device. Afterwards, when the user requests access to the user device in a locked state, the user device is caused to capture of an image of the unique identifier affixed to the user face mask. The user device may further be caused to capture an image of at least a portion of the user's face to authenticate the captured unique identifier affixed to the user face mask with the captured portion of the user's face to verify the captured unique identifier and the captured portion of the user's face are associated with the user device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN CHISM whose telephone number is (571) 272-5915. The examiner can normally be reached during 9:00 AM – 3:00 PM Monday – Thursday, EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan D. Donlon can be reached (571) 270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN CHISM/
Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
Prosecution Insights