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
This Non-Final Action is in reply to the RCE filed 1/6/2026.
Claims 1, 11 and 20 have been amended.
Claims 1-20 are pending.
Request for Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/6/2026 has been entered.
Response to Arguments/Amendments
As it relates to the 35 USC 103 rejection, and independent claims 1, 11 and 20, applicant argues that Fox does not teach and/or suggest any card-based payment authorization request carrying a workflow identifier in an auxiliary data field, or indeed, any card-based messaging standard at all”, and that, “Fox does not teach and/or suggest executing a workflow associated with the workflow identifier such that the output is provided to the user device rather than the initiator device that sent the payment authorization request”. Applicant then states, “Fox is unrelated to online card payments and would not reasonably be understood by one or ordinary skill as being an “online card payment system”, the authentication system of Fox does not include any "card-based payment attempt by a user with the initiator device" and certainly fails to teach and/or suggest "wherein the payment authorization request comprises an electronic message configured to initiate a card-based payment with a user account associated a payment card of the card-based payment attempt" as required in amended claim 1”. Therefore, Fox fails to teach and/or suggest all elements of amended claim 1”. Applicant’s arguments have been reconsidered but are unpersuasive, as noted in the Advisory action and subsequent Examiner Interview Summary, Fox teaches an authentication server associated with one or more accounts associated with a user including but not limited to a government, bank, credit card company and the like (see Fox ¶6, ¶26, ¶27 (client server may be involved in one or more transactions initiated by user …associated with a merchant, vendor, financial instruction or an online bank), ¶47, ¶54, ¶59 (interface provides an opportunity for user to sign in using online banking credentials), ¶60, ¶62 for performing various operations (verifying credentials, initiating a multi-factor authentication challenge, registration process, transmitting redirect instructions, etc.) Hence, Examiner maintains that Fox teaches applicant’s online card payment system.
Applicant then argues, “Bouse does not teach and/or suggest executing a workflow associated with the workflow identifier such that the output is provided to the user device rather than the initiator device that sent the payment authorization request. Thus, Bouse fails to remedy the deficiencies of Fox”. As noted above, Fox is used to teach applicant’s online card payment system, not Bouse. Bouse is used to teach an identity database for enforcing business rules that prescribe the scope of services—see at least Bouse ¶169: “workflow for determining a trustworthiness of a transaction request submitted by a user at a participant entity…VIE 502 may provide feedback to user 202 indicating status change (602) … VIE 502 may detect an unauthorized participant entity attempting to verify an identity of user 202”. While Georgi us used to teach the features for generating a UID from a plurality of sources for identifying transactions including a composite string including additional data derived from one of a single field and multiple fields or columns in a database whereby the additional data may not be contained in the custom identifier. Therefore, Examiner does not consider Bouse to be as limiting as applicant avers.
Applicant subsequently states, with respect to Georgi, “Different information that can be used as an identifier is not the same as populating a field in a messaging protocol with a different kind of information. Thus, Georgi fails to remedy the deficiencies of Bouse and Fox as detailed above. Applicant’s arguments have been considered but are unpersuasive. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e.,” populating a field in a messaging protocol with a different kind of information”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). With respect to the limitation, “wherein the at least one auxiliary card payment authorization data field is different from the at least one standardized card payment authorization data field”, Examiner points applicant to Georgi, ¶77: “(viii) in at least some cases, a UID120 is a composite string including additional data derived, for example, from one or more of a single field and multiple fields or columns in a database, said additional data useful for various purposes including analytics and secure unique string generation, which may not be contained in a CID122 or an XID124”. Examiner therefore maintains that combining the teachings of Fox, Bouse and Georgi produce the claimed invention. Hence, based on the combination of Fox, Bouse and Georgi the claimed invention would have been obvious before the effective filing date of applicant’s invention to a person having ordinary skill in the art.
Examiner has updated the rejection based on applicant’s amendments to further explain how the claims are being interpreted and has addressed each of applicant’s limitations as noted below in this Non Final action.
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 for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fox (WO 2018/009564 A1) in view of Bouse (WO 2015/027216 A1) in further view of Georgi, US Patent Application Publication No US 2014/0039990 A1.
With respect to claims 1, 11 and 20,
Fox discloses,
receiving, by at least one processor via an online card payment system, a card payment authorization request from an initiator device associated with an entity in response to a card-based payment attempt by a user with the initiator device (Abstract: “authenticating an identity of a user requesting a resource or service from an entity”; ¶6: “a system for verifying an identity of a user is provided. The system may comprise at least one processor; and a non-transitory computer readable medium containing instruction, that when executed by the at least one processor, cause the system to perform operations. The operations may include receiving an identity verification request from a device associated with a remote user, the request including information associated with the remote user. The operations may also include requesting, from a server, a transaction identifier for the identity verification request. The operations may also include transmitting, to the device, redirect information for redirecting the device to the server. The operations may also include receiving, from the server, the transaction identifier identifying the identity verification request, hashing the information associated with the remote user, and transmitting the hashed information to the server. The operations may also include receiving from the server, an indication of the authenticity of the user”; ¶14: “Fig. 4 is a logical depiction of an exemplary authentication server”; ¶16: “Fig. 6 is a flowchart of an exemplary authentication process”; Fig 1, ¶23: “Network 102 may comprise any type of computer networking arrangement used to exchange data. For example, network 102 may be the Internet, a private data network, a virtual private network using a public network, and/or other suitable connection(s) that enables system 100 to send and receive information between the components of system 100”; ¶26: “Authentication server 108 may be owned and/or operated by an entity responsible for issuing and maintaining one or more accounts associated with a user 101. In some embodiments, authentication server 108 may be associated with one or more of a government entity (such as, e.g., a state government or department of motor vehicles), a bank, a credit card company, a credit bureau, a merchant, or any other entity that may issue and maintain one or more accounts or otherwise retain information about user 101. In some embodiments, authentication server 108 may store or have access to sensitive information related to user 101 such as personally identifying information (PII) or sensitive personal information (SPI). Such information may include, for example, a social security number, driver's license number, address, phone number, answers to security questions, etc”; ¶27: “Client server 1 10 may be owned, operated, and/or associated with a third-party entity different from that of authentication server 108 and may be associated with any entity interacting remotely with user 101 over network 102. Client server 1 10 may be involved in one or more transactions initiated by user 101 using a device such as user device 104 or 106. For example, client server 1 10 may be associated with a merchant, vendor, healthcare organization, telecom organization, financial institution, or an online bank.”; ¶40: “Programs 350 stored in memory 340 and executed by processor(s) 320 may include one or more server app(s) and/or operating system(s). Server app(s) may incorporate one or more account information apps that cause processor(s) 320 to execute one or more processes related to managing or transmitting information related to user profiles, user account activity, and/or verifying a user identity”; Fig 1, Fig 4, Fig 6, ¶46: “Authentication server 108 may also include consent interface software 406. Consent interface 406 may generate warnings and disclaimers that must be acknowledged by user 101 before accessing particular features of authentication server 108. Consent interface 406 may generate custom interfaces based on characteristics of user 101, products or services that user 101 is associated with, or other factors”; ¶47: “Authentication server 108 may include multi-factor authentication software 408. For example, multi-factor authentication software 408 may provide interfaces and interoperability with various systems to require multiple forms of evidence of identity before providing access to a resource”; Fig 5A, ¶52: “Validation API 416 may receive information related to user 101 and compare the received information with information known to authentication server 108. The results of the comparison may be reported to client server 110 or another entity involved in validating user 101 's identity”; ¶54: “Fig. 6 is a flowchart of an exemplary authentication process 600. In some embodiments, process 600 may be carried out such that client server 110 may authenticate the identity of a user via authentication server…”; ¶59: “the interface provides an opportunity for user 101 to sign in using online banking credentials. Upon receiving input from user 101, user device 106 may submit the credentials to authentication server 108”; Fig4, Fig 6, ¶62: “authentication server 108 may initiate a multi-factor authentication challenge. The challenge may comprise one or more forms of multi-factor authentication, such as those described in relation to multi-factor authentication software 408. For example, authentication server 108 may send a message to user 101 via a known means of communication with user 101, such as an email address or mobile phone number associated with user 101. The message may request user 101 to reply confirming the identity of user 101. Alternatively, the message may be sent via a mobile application as shown in Fig. 5B. In this example, user device 104 may display an interface identifying the entity involved in the identity verification and inviting user 101 to reply confirming the identity of user 101 (if user 101 did in fact initiate the verification). At step 620, user device 104 may transmit an indication of approval to authentication server 108”; ¶63: “authentication server 108 may generate and provide an access token to client server 110. The access token may be any form of information that may facilitate access communication with authentication server 108. For example, the token may be a transaction ID token identifying the particular verification transaction taking place and may be created based on the unique ID stored in customer identity database 414”; ¶72: “ At step 640 client server 110 may enable user 101 to access the requested resource or service requested in step 602 via user device 106”)
Applicant’s disclosure only generically teaches a payment system- see ¶12: The present disclosure provides exemplary technically improved computer-based systems and methods as set forth above, where the initiator device includes a payment system associated with a merchant”; and ¶37: “In some embodiments, the initiator component110 may be a third-party computing device or system with which a user may use to initiate an electronic activity with the third-party. For example, the initiator component110 may be, e.g., a social network server, cloud storage system, online payment system, point-of-sale device, website account server, or other system and/or device for electronic activities”. Examiner interprets the system for verifying an identity of a user including a network, user device(s), authentication server and client server to gather process transmit, receive, verify and provide account information as taught by Fox as teaching applicant’s online card payment system.
Further, giving the broadest reasonable interpretation of applicant’s initiator device in light of the specification- see ¶43, ¶44 Applicant’s initiator device (component) is simply generating an electronic message that uses customized or a specific type of data/field to specify a workflow identifier, workflow type or workflow data; and ¶107: “the initiator device is associated with an entity with which a user is engaging in an electronic activity.” Fox discloses ¶26, ¶27 authentication server associated with a bank, credit card company, merchant and client server as well as a client server associated with a third-party entity different from the authentication server; while, ¶54 further discloses an authentication process including verification and authentication of user and transactions. Examiner interprets the system including at least the authentication server, client server, transaction identifier and network as taught by Fox as teaching applicant’s initiator device.
wherein the payment authorization request comprises an electronic message configured to initiate a card-based payment with a user account associated a payment card of the card-based payment attempt, (Fig4, Fig 6, ¶62: “authentication server 108 may initiate a multi-factor authentication challenge. The challenge may comprise one or more forms of multi-factor authentication, such as those described in relation to multi-factor authentication software 408. For example, authentication server 108 may send a message to user 101 via a known means of communication with user 101, such as an email address or mobile phone number associated with user 101. The message may request user 101 to reply confirming the identity of user 101. Alternatively, the message may be sent via a mobile application as shown in Fig. 5B. In this example, user device 104 may display an interface identifying the entity involved in the identity verification and inviting user 101 to reply confirming the identity of user 101 (if user 101 did in fact initiate the verification). At step 620, user device 104 may transmit an indication of approval to authentication server 108”; ¶63: “authentication server 108 may generate and provide an access token to client server 110. The access token may be any form of information that may facilitate access communication with authentication server 108. For example, the token may be a transaction ID token identifying the particular verification transaction taking place and may be created based on the unique ID stored in customer identity database 414”; ¶72: “ At step 640 client server 110 may enable user 101 to access the requested resource or service requested in step 602 via user device 106”)
wherein the authorization request comprises a plurality of card payment data fields associated with a card payment messaging standard for encoding card-based payment details associated with the user interaction configured to initiate the card-based payment with a user account associated a payment card of the card-based payment attempt (¶50: “Authentication server 108 may include application programming interfaces (APIs) such as validation API 416 and salt/pepper API 418. APIs 416 and 418 are not intended to be limiting, and any number of other APIs may be included in authentication server 108. Client server 1 10 may call APIs on authentication server 108 using a direct connection via network 102, or may employ external API gateway 402 to provide additional security and isolation. ¶52: “Validation API 416 may receive information related to user 101 and compare the received information with information known to authentication server 108. The results of the comparison may be reported to client server 110 or another entity involved in validating user 101 's identity. Validation API 416 may compare information received from client server 1 10 with information held in customer identity database 414 or an external data source 415. The compared information may include one or more of plaintext, ciphertext, hashed values, or any other form or format of information. External data source 415 may comprise an external database or a third-party server operated by a partner entity such as a credit bureau or public records repository”; ¶53: “Salt/pepper API 418 may provide cryptographic salt and/or pepper to client server 110 that may be used to secure information related to user 101 before providing the information to authentication server 108 via validation API 416. Any form or format of cryptographic salt and/or pepper may be used in various embodiments”.
Applicant’s disclosure teaches at ¶43: “In some embodiments, the data fields may conform to a standard, such as, e.g., an application programming interface (API) specification, standardized messaging structure (e.g., according to an International Organization for Standardization (ISO) standard), or other format for electronic messages” Examiner interprets at least the External API Gateway, Validation API and Salt/pepper APIs performing specific operations based on data attributes/parameters or fields as taught by Fox as teaching applicant’s card payment messaging standard for encoding card-based payment details.
the electronic message having a plurality of data fields associated with a card payment authorization messaging standard of the online card payment system (¶6: “The operations may also include requesting, from a server, a transaction identifier for the identity verification request. The operations may also include transmitting, to the device, redirect information for redirecting the device to the server. The operations may also include receiving, from the server, the transaction identifier identifying the identity verification request, hashing the information associated with the remote user, and transmitting the hashed information to the server. The operations may also include receiving from the server, an indication of the authenticity of the user”; ¶51: “Authentication server 108 may include application programming interfaces (APIs) such as validation API 416 and salt/pepper API 418. APIs 416 and 418 are not intended to be limiting, and any number of other APIs may be included in authentication server 108. Client server 1 10 may call APIs on authentication server 108 using a direct connection via network 102, or may employ external API gateway 402 to provide additional security and isolation”; ¶77: “authentication sever 108 may receive the request via salt/pepper API 418”)
the card payment authorization messaging standard being configured for encoding payment authorization details associated with the user interaction (¶6: “requesting, from a server, a transaction identifier for the identity verification request. The operations may also include transmitting, to the device, redirect information for redirecting the device to the server. The operations may also include receiving, from the server, the transaction identifier identifying the identity verification request, hashing the information associated with the remote user, and transmitting the hashed information to the server. The operations may also include receiving from the server, an indication of the authenticity of the user”; ¶7: “receiving, from a server associated with an entity, a request to authenticate a remote user. The operations may also include transmitting, to a first computer device associated with the remote user, a request for credential information and receiving, from the first computer device, credential information associated with the remote user. The operations may also include transmitting, to the server associated with the entity, information identifying the request and receiving, from the server associated with the entity, first hash information. The operations may also include generating second hash information based on information associated with the user, comparing the first hash information with the second hash information, and transmitting, to the server associated with the entity, an indication based on the comparison”; ¶26: “ authentication server 108 may be associated with one or more of a government entity (such as, e.g., a state government or department of motor vehicles), a bank, a credit card company, a credit bureau, a merchant, or any other entity that may issue and maintain one or more accounts or otherwise retain information about user 101”; Fig 5A, Fig 5B, ¶48: “Fig. 5A depicts an example of a username/password prompt displayed via user device 106 as an example of a knowledge factor that may be employed by authentication server 108. Possession factors may include software or hardware tokens such as those marketed by RSA Security LLC, or may be implemented by contacting user 101 via an alternative known means of communication. In some embodiments, the tokens may be time sensitive. For example, as shown in Fig. 5B, after providing a valid username and password via the interface shown in Fig. 5 A, a message may be sent to user device 104, requesting approval of the login. This makes user device 104 the possession factor. In other embodiments, other similar communications channels such as email, SMS, or various other forms of electronic messaging may be used as a party of multi-factor authentication software 408”; ¶51: “Authentication server 108 may include application programming interfaces (APIs) such as validation API 416 and salt/pepper API 418. APIs 416 and 418 are not intended to be limiting, and any number of other APIs may be included in authentication server 108. Client server 1 10 may call APIs on authentication server 108 using a direct connection via network 102, or may employ external API gateway 402 to provide additional security and isolation”)
wherein the card-based payment is associated with at least one of a credit card, a debit card or a bank card (¶26: “Authentication server 108 may be owned and/or operated by an entity responsible for issuing and maintaining one or more accounts associated with a user 101. In some embodiments, authentication server 108 may be associated with one or more of a government entity (such as, e.g., a state government or department of motor vehicles), a bank, a credit card company, a credit bureau, a merchant, or any other entity that may issue and maintain one or more accounts or otherwise retain information about user 101. In some embodiments, authentication server 108 may store or have access to sensitive information related to user 101 such as personally identifying information (PII) or sensitive personal information (SPI). Such information may include, for example, a social security number, driver's license number, address, phone number, answers to security questions, etc”; ¶27: “ Client server 1 10 may be involved in one or more transactions initiated by user 101 using a device such as user device 104 or 106. For example, client server 1 10 may be associated with a merchant, vendor, healthcare organization, telecom organization, financial institution, or an online bank”)
wherein the initiator device is configured to modify the electronic message of the card payment authorization request to populate the at least one auxiliary card payment authorization data field with non-transaction authorization-related data comprising an identifier of a workflow associated with the entity (¶6: “The operations may also include requesting, from a server, a transaction identifier for the identity verification request. The operations may also include transmitting, to the device, redirect information for redirecting the device to the server. The operations may also include receiving, from the server, the transaction identifier identifying the identity verification request, hashing the information associated with the remote user, and transmitting the hashed information to the server”; Fig 5A, Fig 5B, ¶48: “Fig. 5 A, a message may be sent to user device 104, requesting approval of the login. This makes user device 104 the possession factor. In other embodiments, other similar communications channels such as email, SMS, or various other forms of electronic messaging may be used as a party of multi-factor authentication software 408”; Fig 6, ¶57: “At step 606 authentication server 108 may receive the request from client server 1 10 and assign it a unique ID, for example a globally unique identifier (GUID). Authentication server 108 may save the unique ID in association with user 101 in customer identity database 414 and transmit to client server 110 instructions to redirect user to authentication server 108. The instructions may include for example, a URL which points to web page associated with authentication server 108. The URL may include the assigned unique ID”; ¶58: “At step 608 client server 1 10 may associate the unique ID with the pending request and transmit the redirect instructions to user device 106. client server 100 may modify the instructions such that the webpage associated with authentication server 108 is displayed within an interface employed by client server 1 10. For example, the verification may take place as a part of a registration process with client server 1 10. In this case, client server 1 10 may provide a redirect URL to user device 106 such that user device 106 displays the redirected web page in a popup above a registration interface or in a frame within the interface”; ¶59: “user device 106 may display a web page presenting user 101 an opportunity to sign in with credentials associated with the entity associated with authentication server”; ¶61: “authentication server 108 may redirect user device 106 to a consent interface, for example an interface generated by consent interface 406. At step 616, user device 106 may submit an indication of consent to authentication server 108”; ¶62: “authentication server 108 may initiate a multi-factor authentication challenge. The challenge may comprise one or more forms of multi-factor authentication, such as those described in relation to multi-factor authentication software 408. For example, authentication server 108 may send a message to user 101 via a known means of communication with user 101, such as an email address or mobile phone number associated with user 101. The message may request user 101 to reply confirming the identity of user 101. Alternatively, the message may be sent via a mobile application as shown in Fig. 5B. In this example, user device 104 may display an interface identifying the entity involved in the identity verification and inviting user 101 to reply confirming the identity of user 101 (if user 101 did in fact initiate the verification). At step 620, user device 104 may transmit an indication of approval to authentication server 108”)
extracting, by the at least one processor, the identifier of the workflow from the auxiliary card payment authorization field of the card payment authorization request (¶6: “The operations may also include requesting, from a server, a transaction identifier for the identity verification request. The operations may also include transmitting, to the device, redirect information for redirecting the device to the server. The operations may also include receiving, from the server, the transaction identifier identifying the identity verification request, hashing the information associated with the remote user, and transmitting the hashed information to the server”; ¶54: Authentication server 108 may be configured to perform a strong authentication event of user 101 in steps 612-622. For example, authentication server 108 may be configured to complete a secure login with multifactor authentication of user 101. Upon successful multifactor authentication, authentication server 108 may be configured to provide an indication of successful authentication to client server 1 10. Client server 1 10 may be configured to generate a first cryptographic hash for verifying user 101 in steps 624- 628. In some aspects, the first cryptographic hash may depend on information received from a user device (e.g., at least one of user device 104 and 106). In some aspects, the first cryptographic hash may depend on information received from authentication server 108.”; “¶58: “At step 608 client server 1 10 may associate the unique ID with the pending request and transmit the redirect instructions to user device 106. client server 100 may modify the instructions such that the webpage associated with authentication server 108 is displayed within an interface employed by client server 1 10. For example, the verification may take place as a part of a registration process with client server 1 10. In this case, client server 1 10 may provide a redirect URL to user device 106 such that user device 106 displays the redirected web page in a popup above a registration interface or in a frame within the interface”; ¶59: “user device 106 may display a web page presenting user 101 an opportunity to sign in with credentials associated with the entity associated with authentication server”)
Applicant’s disclosure generally teaches at ¶4, ¶5, “where the at least one auxiliary data field includes an identifier of a workflow request associated with the entity”; ¶43: “auxiliary data fields may be employed for specifying the workflow identifier or workflow type, or other workflow data and combinations thereof”. Giving the broadest reasonable interpretation of the claim limitations, in light of the specification, Examiner interprets at least the transaction identifier, and instructions/redirect instructions associated with authentication server (registration interface, sign in web page, identity verification, consent interface and the like) as taught by Fox as teaching applicant’s auxiliary field (for specifying the workflow identifier or workflow type or other workflow data).
determining, by the at least one processor, a secure workflow based at least in part on: i) the identifier of the workflow, and ii) at least one registered workflow; (¶6: “The operations may also include requesting, from a server, a transaction identifier for the identity verification request. The operations may also include transmitting, to the device, redirect information for redirecting the device to the server. The operations may also include receiving, from the server, the transaction identifier identifying the identity verification request, hashing the information associated with the remote user, and transmitting the hashed information to the server. The operations may also include receiving from the server, an indication of the authenticity of the user”; ¶47: “multi-factor authentication may require two or more of knowledge factors (i.e., "something you know"), possession factors (i.e., "something you have"), and inherence factors (i.e. "something you are"). Knowledge factors may include information intended to be known only by user 101 , such as a username and password combination, a personal identification number (PIN) or out of wallet questions either provided by user 101 at an earlier registration or assembled from information related to user 101 available to authentication server 108 but not the general public”; ¶58: “At step 608 client server 1 10 may associate the unique ID with the pending request and transmit the redirect instructions to user device 106. client server 100 may modify the instructions such that the webpage associated with authentication server 108 is displayed within an interface employed by client server 1 10. For example, the verification may take place as a part of a registration process with client server 1 10. In this case, client server 1 10 may provide a redirect URL to user device 106 such that user device 106 displays the redirected web page in a popup above a registration interface or in a frame within the interface”; ¶59: “user device 106 may display a web page presenting user 101 an opportunity to sign in with credentials associated with the entity associated with authentication server”; ¶60: “authentication server 108 may verify the credentials received from user device 106”; ¶62: “authentication server 108 may initiate a multi-factor authentication challenge”)
receiving, by the at least one processor from the initiator device, a workflow request comprising workflow data and the device-specific workflow token (¶48: “Fig. 5A depicts an example of a username/password prompt displayed via user device 106 as an example of a knowledge factor that may be employed by authentication server 108. Possession factors may include software or hardware tokens such as those marketed by RSA Security LLC, or may be implemented by contacting user 101 via an alternative known means of communication. In some embodiments, the tokens may be time sensitive. For example, as shown in Fig. 5B, after providing a valid username and password via the interface shown in Fig. 5 A, a message may be sent to user device 104, requesting approval of the login. This makes user device 104 the possession factor. In other embodiments, other similar communications channels such as email, SMS, or various other forms of electronic messaging may be used as a party of multi-factor authentication software 408”)
executing, by the at least one processor, within the workflow service, the device-specific instance of the secure workflow based at least in part on: i) the workflow request, and ii) user data of the user;(¶46: “Authentication server 108 may also include consent interface software 406. Consent interface 406 may generate warnings and disclaimers that must be acknowledged by user 101 before accessing particular features of authentication server 108. Consent interface 406 may generate custom interfaces based on characteristics of user 101, products or services that user 101 is associated with, or other factors”; Fig 5A, Fig 5B, ¶48: “Fig. 5A depicts an example of a username/password prompt displayed via user device 106 as an example of a knowledge factor that may be employed by authentication server 108. Possession factors may include software or hardware tokens such as those marketed by RSA Security LLC, or may be implemented by contacting user 101 via an alternative known means of communication …as shown in Fig. 5B, after providing a valid username and password via the interface shown in Fig. 5 A, a message may be sent to user device 104, requesting approval of the login. This makes user device 104 the possession factor. In other embodiments, other similar communications channels such as email, SMS, or various other forms of electronic messaging may be used as a party of multi-factor authentication software 408”)
generating, by the at least one processor, a device-specific workflow token for a workflow service to execute a device-specific instance of the secure workflow; wherein the device-specific workflow token is associated with the initiator device (¶46: “Authentication server 108 may also include consent interface software 406. Consent interface 406 may generate warnings and disclaimers that must be acknowledged by user 101 before accessing particular features of authentication server 108. Consent interface 406 may generate custom interfaces based on characteristics of user 101, products or services that user 101 is associated with, or other factors”; ¶47: “multi-factor authentication software 408 may provide interfaces and interoperability with various systems to require multiple forms of evidence of identity before providing access to a resource. Multi-factor authentication may require two or more of knowledge factors”; Fig 5A, Fig 5B, ¶48: “Fig. 5A depicts an example of a username/password prompt displayed via user device 106 as an example of a knowledge factor that may be employed by authentication server 108. Possession factors may include software or hardware tokens such as those marketed by RSA Security LLC, or may be implemented by contacting user 101 via an alternative known means of communication …as shown in Fig. 5B, after providing a valid username and password via the interface shown in Fig. 5 A, a message may be sent to user device 104, requesting approval of the login. This makes user device 104 the possession factor. In other embodiments, other similar communications channels such as email, SMS, or various other forms of electronic messaging may be used as a party of multi-factor authentication software 408”; ¶56: “client server 110 may receive the request from user device 106 and submit to authentication server 108 a request for an access token”; ¶63: “authentication server 108 may generate and provide an access token to client server 110. The access token may be any form of information that may facilitate access communication with authentication server 108. For example, the token may be a transaction ID token identifying the particular verification transaction taking place and may be created based on the unique ID stored in customer identity database 414”)
wherein the user data of the user is confidentially stored separate from the entity (¶22: “Authentication server 108 may be configured to provide user 101 a secure login using existing credentials and verify the login with a multi-factor authentication event. Client server 1 10 and authentication server 108 may each be configured to perform coordinated cryptographic hash functions on two sets of information, client server 1 10 hashing the information submitted as a part of the request and authentication server 108 hashing information existing in established records related to user 101. Authentication server 108 may compare the results of the two hash functions and, if the results match, notify client server 110 that the identity of user 101 has been verified”; ¶40 teaches transmitting data related to user profiles, activity and verifying user identify”)
transmitting, by the at least one processor, the at least one status notification to the initiator device, a computing device associated with the user, or both (¶5: “operations may also include transmitting, to the server associated with the entity, information identifying the request and receiving, from the server associated with the entity, first hash information, he operations may also include generating second hash information based on information associated with the user, comparing the first hash information with the second hash information, and transmitting, to the server associated with the entity, an indication based on the comparison”; ¶43: “if client server 1 10 is associated with an insurance company, programs 350 may comprise programs related to creating new insurance accounts, accessing account status, managing risk, and/or filing claims”; ¶75: “At step 704, authentication server 108 may send a message to client server 1 10, the message indicating that the client server's salt has expired and that the requested authentication cannot be completed”)
Fox discloses all of the above limitations, Fox does not distinctly describe the following limitations, but Bouse however as shown discloses,
wherein the workflow data comprises: i) at least one trigger condition, and ii) an indication of the at least one trigger condition having been satisfied; (¶83: “For the TAE 122 to process the submitted inquiries from data originators 1-5, the respective data owner may provide discrimination methods for the TAE 122. The discrimination methods may enable context-dependent processing of the transaction request for which the trustworthiness is being investigated. In some configurations, the trustworthiness investigation may be performed in accordance with varying threshold level requirements that are commensurate with the character of the underlying transaction, trust level of each electronic proof of identity, as well as the custom policies of the participant entities managing the data targeted by the transaction being requested …discrimination method may include threshold level of the transaction amount to trigger increased scrutiny... financial transaction over the amount of $500 may automatically trigger increased scrutiny and if the amount is over $100,000, then more than one source may be consulted to verify the identity of the requestor”; ¶84: “Thus, TAE 122 may function as an infrastructure apparatus to determine whether the transaction request is sufficiently trustworthy for the recipient entity to process the requested transaction”; ¶85: “The electronic proof of identity may be compared against an identity database during the validation process...identity proof may become available only after a vetting process at an authoritative institution, such as the department of motor vehicles (DMV), the state department, etc”; Fig 4, ¶164: “information is stored in a business rules (biz rules) repository, for example, associated with access policies 108. In other instances, technical information is also declared (e.g. mutually agreed upon communication and authentication protocols, and allowable contact windows) and stored in a workflow database, for example, associated with access methods 106. As illustrated in Fig. 4, APS 128 may then confirm each relationship and the terms stored in the business rules repository (402B). The technical information including protocols can be similarly verified (402 A)”; ¶172: “If the user authentication is successful, VIE 502 may proceed to provide identity functionalities for the homeowner to sign off the mortgage refinance application… send the transaction request of the refinance application to the bank ..bank initiated the work flow and hence the transaction”; ¶260: “The registry service may require authorization from the user to use the newly configured token, and may need the authentication that the token is valid. In this manner, the user may interface directly to the identity data eco-system, as well as the proxy certificate authority and associated policy engines. As an additional layer of security, a temporary PIN number assigned by the identity data eco-system may further secure the registry transaction from unauthorized access”; ¶261: “The registry may create a unique identifier, for example a token type ID, a hash of the token ID or serial number combined with a unique identity ID and a secondary hash of one or more of the multi-factor authentication templates, thereby creating a unique identifier string unique to that User. This unique identifier may be encrypted upon creation, and can be reduced in string size by applying a hash, a digest, a checksum, or other algorithmic shortening. Once the identity token has been defined and secured, the identity token may be tied to the physical identity of the user”)
transmitting, by the at least one processor, a user notification produced by the device-specific instance of the secure workflow to a user device associated with the user so as to notify the user of the at least one trigger condition; (¶83: “For the TAE 122 to process the submitted inquiries from data originators 1-5, the respective data owner may provide discrimination methods for the TAE 122. The discrimination methods may enable context-dependent processing of the transaction request for which the trustworthiness is being investigated. In some configurations, the trustworthiness investigation may be performed in accordance with varying threshold level requirements that are commensurate with the character of the underlying transaction, trust level of each electronic proof of identity, as well as the custom policies of the participant entities managing the data targeted by the transaction being requested …discrimination method may include threshold level of the transaction amount to trigger increased scrutiny... financial transaction over the amount of $500 may automatically trigger increased scrutiny and if the amount is over $100,000, then more than one source may be consulted to verify the identity of the requestor.¶85: “The electronic proof of identity may be compared against an identity database during the validation process...identity proof may become available only after a vetting process at an authoritative institution, such as the department of motor vehicles (DMV), the state department, etc”; ¶99: “transaction may be financial, payments, account balances”; ¶169:“workflow for determining a trustworthiness of a transaction request submitted by a user at a participant entity... User 202 may register participant entity 204 at VIE 502 as an authorized business partner of user 202 in the integrated identity management system (601). VIE 502 may provide feedback to user 202 indicating status change (602). In some implementations, VIE 502 may detect an unauthorized participant entity attempting to verify an identity of user 202. VIE 502 may promptly block the attempted verification by, for example, instructing TAE 122 to drop the verification request”; Fig 4, ¶164: “information is stored in a business rules (biz rules) repository, for example, associated with access policies 108. In other instances, technical information is also declared (e.g., mutually agreed upon communication and authentication protocols, and allowable contact windows) and stored in a workflow database, for example, associated with access methods 106. As illustrated in Fig. 4, APS 128 may then confirm each relationship and the terms stored in the business rules repository (402B). The technical information including protocols can be similarly verified (402 A)”; ¶172: “If the user authentication is successful, VIE 502 may proceed to provide identity functionalities for the homeowner to sign off the mortgage refinance application… send the transaction request of the refinance application to the bank ..bank initiated the work flow and hence the transaction”; ¶180: “determining that the participant entity, as an authorized business partner of the user, is authorized to engage in the requested transaction between the user and the participant entity, signaling the participant entity to proceed with the requested transaction”)
generating, by the at least one processor, at least one status notification in response to the executing of the device-specific instance of the secure workflow; wherein the at least one status notification comprises the indication of the at least one trigger condition having been satisfied; (¶85: “The determination of trustworthiness of the transaction request may incorporate validating electronic proof of identity accompanying the submitted transaction request. The electronic proof of identity may be compared against an identity database during the validation process… Examples electronic proof of identity may include a digital identification document, such as, for example, a digital driver's license, a digital passport, a digital social security card, a digital Medicare/Medicaid card, etc. The electronic proof of identity may also include a biometric in digital form, such as an electronic signature, a digital finger print, a digital palm print, a digital iris scan, a digital retina scan, or even a DNA digitally captured… possession of a verifiable electronic proof of identity may establish prima facie showing that the holder is the person identified by the electronic proof of identity”; ¶86: “The access methods layer 106 generally refers to a work flow including protocols for verifying, for example, the electronic proof of identity, identity databases to compare against, as well as user authorization of business partners to query an identity database to verify the user's identity”; Fig 4, ¶164: “information is stored in a business rules (biz rules) repository, for example, associated with access policies 108. In other instances, technical information is also declared (e.g., mutually agreed upon communication and authentication protocols, and allowable contact windows) and stored in a workflow database, for example, associated with access methods 106. As illustrated in Fig. 4, APS 128 may then confirm each relationship and the terms stored in the business rules repository (402B). The technical information including protocols can be similarly verified (402 A)”; ¶169: “workflow for determining a trustworthiness of a transaction request submitted by a user at a participant entity... User 202 may register participant entity 204 at VIE 502 as an authorized business partner of user 202 in the integrated identity management system (601). VIE 502 may provide feedback to user 202 indicating status change (602). In some implementations, VIE 502 may detect an unauthorized participant entity attempting to verify an identity of user 202. VIE 502 may promptly block the attempted verification by, for example, instructing TAE 122 to drop the verification request”; ¶172: “If the user authentication is successful, VIE 502 may proceed to provide identity functionalities for the homeowner to sign off the mortgage refinance application… send the transaction request of the refinance application to the bank ..bank initiated the work flow and hence the transaction”; ¶173: “access control is on an individual level and specific to each user 202, as compared to a systematic control of access right by APS 128. VIE 502 may return a numerical score indicating the level of authorization possessed by a participant entity with regard to a specific user, or even the level of authorization possessed by the participant entity with regard to a specific transaction request from the specific user”; ¶180: “determining that the participant entity, as an authorized business partner of the user, is authorized to engage in the requested transaction between the user and the participant entity, signaling the participant entity to proceed with the requested transaction”)
Fox teaches a method/system for verifying and authenticating an identity of a user requesting a resource or service from an entity including receiving credential information associated with the user and hash information from a server associated with an entity. Bouse discloses a method/system for identity management including an identity database for enforcing business rules that prescribe the scope of services that each participant entity may obtain from a particular identity database via an APS. Fox and Bouse are directed to the same field of endeavors since they are related to method/system for verifying/validating and/or authenticating data related to transactions in a computing environment. Therefore, it would have been obvious before the effective filing date of applicant's invention to combine the method/system for verifying and authenticating an identify of a user of Fox with the method/system for identity management as taught by Bouse since it allows for determining the trustworthiness of a requested transaction via an authentication policy, authorized identity database, and communication protocols (¶12, ¶78-¶83, ¶85, ¶169, ¶172- ¶180, ¶260, ¶261, Fig 5, Fig 6A, Fig 6B).
Fox and Bouse disclose all of the above limitations, the combination of Fox and Bouse does not distinctly describe the following limitations, but Georgi however as shown discloses,
wherein the plurality of data fields comprise at least one standardized card payment authorization data field associated with at least one standardized data type of the card payment authorization messaging standard, and at least one auxiliary card payment authorization data field associated with auxiliary data of the card payment authorization request(Fig 1B, ¶71: “A functionally equivalent transaction associating identifier shall mean a transaction associating identifier, including a UID120, a CID122, and an XID124, which in at least some cases (i) may exist, (ii) may be used, (iii) may be recorded in a database, and (iv) may serve its function in one of several forms, formats, versions, fields, and records, wherein each variation is deemed "functionally equivalent" as may be appropriate for its intended use. For example, a version of a UID120 may exist in a secure database, while a public version may be embedded in an object 126 after tokenization”; ¶75: “in reference to a CID122, a CID122 shall mean a first consumer identifier or source of identification including at least one of a digital string associated with a consumer 108, an object 126 associated with a consumer 108, a digital string associated with an object 126, a consumer 108 account, and any presented consumer identifier not necessarily identifying the individual 108 personally or any account. A digital string may include one of a value, a code, a token, a data entry, and a digitized representation of a data source. Any source of identification which is a digital string, which contains a digital string, or which is subject to digitization into a digital string, and which may be presented at each transaction in a rewards program, may be used as a CID122. A CID122 may consist of one or more of a plurality of identification types”; ¶76: “an XID124 may utilize a standardized format for ease of use, in contrast to the diverse formats of various types of a CID122; (viii) in at least some cases, an XID124 is a composite string including additional data which may be derived, for example, from one of a single field and multiple fields or columns in a database, wherein the additional data is useful for various purposes including analytics and secure unique string generation and wherein the additional data may not be contained in a CID122; ¶77: “a UID120 may use a standardized format for ease of use; (viii) in at least some cases, a UID120 is a composite string including additional data derived, for example, from one or more of a single field and multiple fields or columns in a database, said additional data useful for various purposes including analytics and secure unique string generation, which data may not be contained in a CID122 or an XID124; (ix) a UID120 is recorded in a database including the identifiers database 190”)
wherein the at least one auxiliary card payment authorization data field is different from the at least one standardized card payment authorization data field; (¶76: “in at least some cases, an XID124 may utilize a standardized format for ease of use, in contrast to the diverse formats of various types of a CID122; (viii) in at least some cases, an XID124 is a composite string including additional data which may be derived, for example, from one of a single field and multiple fields or columns in a database, wherein the additional data is useful for various purposes including analytics and secure unique string generation and wherein the additional data may not be contained in a CID122”; ¶77: “a UID120 may use a standardized format for ease of use; (viii) in at least some cases, a UID120 is a composite string including additional data derived, for example, from one or more of a single field and multiple fields or columns in a database, said additional data useful for various purposes including analytics and secure unique string generation, which data may not be contained in a CID122 or an XID124; (ix) a UID120 is recorded in a database including the identifiers database 190; (x) all fields, columns, and data associated with a UID120 are regarded as part of the UID120; (xi) a UID120 may be indexed and is searchable, including for additional data”)
transmitting, by the at least one processor to the initiator device via the online card payment system, a card payment authorization response comprising at least one card payment authorization response auxiliary card payment authorization data field encoding the device-specific workflow token (¶117: “At block 586 a determination is made if the payment is to be authorized or not. At block 588 the payment processor 102/106 generates a reply indicating an authorization or declination. At block 590 the payment processor 102/106 may encrypt and/or tokenize all or part of the reply and data, which the resource provider 110 receives at 592”; ¶130: “At block 540, if consumer 108 has presented a CID122 for the first time in the rewards program in the current transaction, then at process block 542 a UID120 is generated by a transaction associating identifier generation processor by a computer implemented process which may include one or more of an algorithm, conversion, salting, encryption, and tokenization, wherein the generated UID120 is associated with the XID124 generated at block 524 from data including said CID122 and transmitted at block 530. In various embodiments, a random number generator may create a token as a UID120 associated with said XID124. In various embodiments, a second set of additional data (e.g., salting) is added to an XID124 in order to generate a secure unique UID120”)
Applicant’s disclosure only vaguely discusses at ¶6: “In some embodiments, the present disclosure provides another exemplary technically improved computer-based method that includes at least the following steps of receiving, by at least one processor, an authorization request from an initiator device associated with an entity in response to a user interaction of a user with the initiator device; where the authorization request includes a plurality of data fields associated with a messaging standard; and ¶10: “the present disclosure provides exemplary technically improved computer-based systems and methods as set forth above, where the messaging standard includes an authorization message standard”; and ¶82: “In some embodiments, the authorization request203 may be communicated as an electronic message via any suitable messaging protocol” Examiner interprets at least the payment processor as taught by Georgio as teaching applicant’s card payment authorization response.
Georgi teaches method/system for a transaction associating identifier generation processor for generating a unique universal transaction associating identifier (UID) from a plurality of sources (consumer identifier CID) for identifying transactions. A CID may include a digital string associated with various information (an object (credit/debit card), a data entry using an input device, a pattern detectible in an object...) used to combine with additional data to generate a second string (XID). Georgi further teaches that the XID may utilize a standardized format for ease of use and in some cases a composite string including additional data derived from one of a single field and multiple fields or columns in a database for various purposes whereby the additional data may not be contained in the CID. Fox, Bouse and Georgi are directed to the same field of endeavors since they are related to method/system for verifying/validating and/or authenticating data related to transactions in a computing environment. Therefore, it would have been obvious before the effective filing date of applicant's invention to combine the method/system for verifying and authenticating an identify of a user of Fox with the method/system for identity management of Bouse and the techniques for string generation as taught by Georgi since it allows for utilizing a standardize format for ease of use and transaction associating identifier purposes (¶71, ¶75-¶77).
Independent claims 11 and 20 recite substantially similar limitations as independent claim 1, therefore they are rejected based on the same rationale.
With respect to claims 2 and 12,
Fox, Bouse and Georgi disclose all of the above limitations, Fox further discloses,
further comprising electronically communicating, by the at least one processor, the at least one status notification to contact information identified in the user data, wherein the contact information identifies a communication address of the computing device (Fig 5A, Fig 5B, ¶62: “authentication server 108 may send a message to user 101 via a known means of communication with user 101, such as an email address or mobile phone number associated with user 101. The message may request user 101 to reply confirming the identity of user 101. Alternatively, the message may be sent via a mobile application as shown in Fig. 5B. In this example, user device 104 may display an interface identifying the entity involved in the identity verification and inviting user 101 to reply confirming the identity of user 101 (if user 101 did in fact initiate the verification). At step 620, user device 104 may transmit an indication of approval to authentication server 108”)
With respect to claims 3 and 13,
Fox, Bouse and Georgi disclose all of the above limitations, Fox further discloses,
wherein the contact information comprises a telephone number specified in a user account at a financial institution and the at least one status notification comprises a text message to the telephone number (¶26: “authentication server 108 may store or have access to sensitive information related to user 101 such as personally identifying information (PII) or sensitive personal information (SPI). Such information may include, for example, a social security number, driver's license number, address, phone number, answers to security questions, etc”; ¶52: “Validation API 416 may receive information related to user 101 and compare the received information with information known to authentication server 108. The results of the comparison may be reported to client server 110 or another entity involved in validating user 101 's identity. Validation API 416 may compare information received from client server 1 10 with information held in customer identity database 414 or an external data source 415. The compared information may include one or more of plaintext, ciphertext, hashed values, or any other form or format of information.)
With respect to claims 4 and 14,
Fox, Bouse and Georgi disclose all of the above limitations, Fox further discloses,
wherein the device-specific workflow token is a one-time token that expires upon generating the at least one status notification (Fig 5A, 5B, ¶48: “the tokens may be time sensitive. For example, as shown in Fig. 5B, after providing a valid username and password via the interface shown in Fig. 5 A, a message may be sent to user device 104, requesting approval of the login. This makes user device 104 the possession factor. In other embodiments, other similar communications channels such as email, SMS, or various other forms of electronic messaging may be used as a party of multi-factor authentication software 408”)
With respect to claims 5 and 15,
Fox, Bouse and Georgi disclose all of the above limitations, Fox further discloses,
wherein the messaging standard comprises an authorization message standard (¶49: “Authentication sever 108 may also include software implementing an authentication layer such as OpenID Connect (OIDC), for example OIDC service 410. The authentication layer may allow authentication server 108 to manage user accounts and share information related to authenticated users with client servers through secure, standardized channels of communication. The use of OIDC is merely exemplary, and other means of authentication, such as other implementations of OAuth or OAuth 2.0 may be employed alternatively or additionally”; ¶60: “At step 612 authentication server 108 may verify the credentials received from user device 106. Any means of authenticating the credentials may be used, for example any variant of the OAuth or OAuth 2.0 authentication standards or any other authentication standard”)
With respect to claims 6 and 16,
Fox, Bouse and Georgi disclose all of the above limitations, Georgi further discloses,
wherein the at least one auxiliary data field comprises at least one data field of the messaging standard that is reserved for private use (¶76: “in at least some cases, an XID124 may utilize a standardized format for ease of use, in contrast to the diverse formats of various types of a CID122; (viii) in at least some cases, an XID124 is a composite string including additional data which may be derived, for example, from one of a single field and multiple fields or columns in a database, wherein the additional data is useful for various purposes including analytics and secure unique string generation and wherein the additional data may not be contained in a CID122”; ¶77: “a UID120 may use a standardized format for ease of use; (viii) in at least some cases, a UID120 is a composite string including additional data derived, for example, from one or more of a single field and multiple fields or columns in a database, said additional data useful for various purposes including analytics and secure unique string generation, which data may not be contained in a CID122 or an XID124; (ix) a UID120 is recorded in a database including the identifiers database 190; (x) all fields, columns, and data associated with a UID120 are regarded as part of the UID120; (xi) a UID120 may be indexed and is searchable, including for additional data”; ¶123: “the key may comprise a private key which decrypts data encrypted with a public key. In a typical embodiment, reward handler 112 does not possess a key to decrypt transaction data encrypted for payment purposes with algorithm 1, so data in system 100 remains secure and visible only to the respective parties entitled to certain specific data”)
Fox, Bouse and Georgi are directed to the same field of endeavors since they are related to method/system for verifying/validating and/or authenticating data related to transactions in a computing environment. Therefore, it would have been obvious before the effective filing date of applicant's invention to combine the method/system for verifying and authenticating an identify of a user of Fox with the method/system for identity management of Bouse and the techniques for string generation as taught by Georgi since it allows for keeping data secure and visible only to the respective parties entitled to certain specific data ¶71, ¶75-¶77).
With respect to claims 7 and 17,
Fox, Bouse and Georgi disclose all of the above limitations, Fox further discloses,
wherein the initiator device comprises a payment system associated with a merchant (¶6: “a system for verifying an identity of a user is provided. The system may comprise at least one processor; and a non-transitory computer readable medium containing instruction, that when executed by the at least one processor, cause the system to perform operations. The operations may include receiving an identity verification request from a device associated with a remote user, the request including information associated with the remote user. The operations may also include requesting, from a server, a transaction identifier for the identity verification request. The operations may also include transmitting, to the device, redirect information for redirecting the device to the server. The operations may also include receiving, from the server, the transaction identifier identifying the identity verification request, hashing the information associated with the remote user, and transmitting the hashed information to the server. The operations may also include receiving from the server, an indication of the authenticity of the user”; Fig 1, ¶23: “Network 102 may comprise any type of computer networking arrangement used to exchange data. For example, network 102 may be the Internet, a private data network, a virtual private network using a public network, and/or other suitable connection(s) that enables system 100 to send and receive information between the components of system 100”; ¶26: “Authentication server 108 may be owned and/or operated by an entity responsible for issuing and maintaining one or more accounts associated with a user 101. In some embodiments, authentication server 108 may be associated with one or more of a government entity (such as, e.g., a state government or department of motor vehicles), a bank, a credit card company, a credit bureau, a merchant, or any other entity that may issue and maintain one or more accounts or otherwise retain information about user 101. In some embodiments, authentication server 108 may store or have access to sensitive information related to user 101 such as personally identifying information (PII) or sensitive personal information (SPI). Such information may include, for example, a social security number, driver's license number, address, phone number, answers to security questions, etc”; ¶27: “Client server 110 may be involved in one or more transactions initiated by user 101 using a device such as user device 104 or 106. For example, client server 110 may be associated with a merchant, vendor, healthcare organization, telecom organization, financial institution, or an online bank”; ¶40: “Programs 350 stored in memory 340 and executed by processor(s) 320 may include one or more server app(s) and/or operating system(s). Server app(s) may incorporate one or more account information apps that cause processor(s) 320 to execute one or more processes related to managing or transmitting information related to user profiles, user account activity, and/or verifying a user identity”; Fig 5A, ¶48, ¶54: “Fig. 6 is a flowchart of an exemplary authentication process 600. In some embodiments, process 600 may be carried out such that client server 110 may authenticate the identity of a user via authentication server…”)
Applicant’s disclosure only generically teaches a payment system- see ¶12: The present disclosure provides exemplary technically improved computer-based systems and methods as set forth above, where the initiator device includes a payment system associated with a merchant”; and ¶37: “In some embodiments, the initiator component110 may be a third-party computing device or system with which a user may use to initiate an electronic activity with the third-party. For example, the initiator component110 may be, e.g., a social network server, cloud storage system, online payment system, point-of-sale device, website account server, or other system and/or device for electronic activities”. Examiner interprets the system for verifying an identity of a user including a network, user device(s), authentication server and client server to gather process transmit, receive, verify and provide information as taught by Fox as teaching applicant’s payment system.
Further, giving the broadest reasonable interpretation of applicant’s initiator device in light of the specification- see ¶43, ¶44 Applicant’s initiator device (component) as simply generating an electronic message that uses customized or a specific type of data/field to specify a workflow identifier, workflow type or workflow data; and ¶107: “the initiator device is associated with an entity with which a user is engaging in an electronic activity.” Fox discloses ¶26, ¶27 authentication server associated with a bank, credit card company, merchant and client server as well as a client server associated with a third-party entity different from the authentication server; while, ¶54 further discloses an authentication process including verification and authentication of user and transactions. Examiner interprets the system including at least the authentication server, transaction identifier and network as taught by Fox as teaching applicant’s initiator device.
With respect to claims 8 and 18,
Fox, Bouse and Georgi disclose all of the above limitations, Fox further discloses,
further comprising receiving, by the at least one processor, the workflow request comprising a transaction fulfillment message from a merchant associated with the initiator device, wherein the transaction fulfillment message indicates a fulfillment of a status of a transaction associated with the payment authorization request (¶70: “At step 636 authentication server 108 may compare the two sets of hashed sensitive data. If the same hash function, keys, and salt and/or pepper were used by client server 110 as used by authentication server 108, the result of the comparison may be a match if the sensitive information applied to the hash function was the same as the sensitive information identified by authentication server 108. Thus, a match may verify that the information corresponds to known information related to user 101, without transmitting that information over network 102 in any form that could reasonably be reverted to the original sensitive information”; ¶71: “At step 638 authentication server 108 may transmit a result of the match to client server 1 10. The transmitted result may be a Boolean (i.e., true or false) result”; ¶72: “At step 640 client server 110 may enable user 101 to access the requested resource or service requested in step 602 via user device 106”)
With respect to claims 9 and 19,
Fox, Bouse and Georgi disclose all of the above limitations, Fox further discloses,
further comprising: generating, by the at least one processor, a multi-factor authentication token based on the secure workflow; and electronically communicating, by the at least one processor, the multi-factor authentication token to the initiator device, the at least one computing device, or both to authenticate the user with the initiator device (¶22: “Authentication server 108 may be configured to provide user 101 a secure login using existing credentials and verify the login with a multi-factor authentication event. Client server 1 10 and authentication server 108 may each be configured to perform coordinated cryptographic hash functions on two sets of information, client server 1 10 hashing the information submitted as a part of the request and authentication server 108 hashing information existing in established records related to user 101. Authentication server 108 may compare the results of the two hash functions and, if the results match, notify client server 110 that the identity of user 101 has been verified”)
With respect to claim 10,
Fox, Bouse and Georgi disclose all of the above limitations, Fox further discloses,
wherein the at least one status notification comprises a purchased item shipping status (¶112: “An example scenario may be when user 202 submits a transaction request to purchase alcohol from participant entity 204. In addition to take payment for the alcohol product, local regulations may require participant entity to confirm that user 202 is indeed over, for example, 21 years of age. An identification document of user 202 may be presented by user 202 along with the transaction request. The identification document may include, for example, a driver's license, a passport, a national identification card, etc. The transaction request may include an online transaction request. A copy of the identification document may be may be forwarded to the TAE 122. In turn, TAE 122 may query identity database, through AVE 126, based on the identification document. If query results confirm that the identification document is authentic and has not been tampered with, and that user 202 is over 21 years of age, AVE 126 may return a full authenticity score to TAE 122. TAE 122 may subsequently determine that the transaction request is trustworthy, as submitted by user 202. Thereafter, TAE 122 may notify the participant entity 204 of the determined trustworthiness of the transaction request (242)”; ¶180: “VIE 502 may query the database at the verified identity engine to determine whether the participant entity, as an authorized business partner of the user, is authorized to engage in the requested transaction between the user and the participant entity. In response to determining that the participant entity, as an authorized business partner of the user, is authorized to engage in the requested transaction between the user and the participant entity, signaling the participant entity to proceed with the requested transaction”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pearce, US Patent No US 11,501,292 B1, “Systems and Methods for Third Party Token Based Authentication” relating to a method of identifying user activity and authenticating a user based on the related user activity.
Grassadonia et al., US Patent Application Publication No US 2018/0005203 A1, “Display Notification of Information Upon Payment Authorization”, relating to a notification authorization messaging system.
Hogg et al., US Patent Application Publication No US 2014/0003231 A1, “Systems and Methods for Conducting a Quick Transaction”, relating to a number of methods for displaying data within a browser-based document. Data may be represented as standard text or within a fixed list, scrollable list, drop-down list, editable text field, fixed text field, pop-up window, and/or the like. In response to a user accessing VTS 115 (e.g., by logging onto an application or app), Internet server may invoke an application server. Application server invokes logic in VTE 147 by passing parameters relating to the user's requests for data. VTS 115 manages requests for data from VTE 147 and communicates with system components.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KIMBERLY L EVANS whose telephone number is (571)270-3929. The examiner can normally be reached M-F 730a-5p. 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, Lynda Jasmin can be reached at (571)272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KIMBERLY L EVANS/Examiner, Art Unit 3629
/LYNDA JASMIN/Supervisory Patent Examiner, Art Unit 3629
Prosecution Insights