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 .
Continued Examination
1. 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 8/5/2026 has been entered.
Claim Status
2. Claims 1, 11, and 16 have currently been amended. Claim 8 has currently been cancelled.
Response to Arguments
3. The applicant’s arguments filed 8/5/2026 have been taken into consideration, but are moot in view of new grounds of rejection.
In response to the applicant’s argument (disclosed on pg. 2-3 of the remarks segment) that the cited prior art fails to teach or suggest a request comprising a set of parameters defining a condition for routing data between a first remote computing system and a second remote computing system, wherein the condition comprises at least one of an amount and a percentage of a transaction to be transferred from the first remote computing system to the second remote computing system:
In light of the claim amendments, see newly cited prior art reference Guglani et al (US 10,255,456), which discloses (fig. 1, ‘180, col. 25, lines 40-52, col. 26, lines 1-12, and col. 26, lines 55-65 of Guglani et al) a stored token containing an encrypted account identification information for an account associated with a mobile device (e.g., wherein the token includes encrypted account association information associated with the second remote computing system), a token server receiving and decrypting the encrypted account identifier (e.g., the encrypted account association information being decipherable by the server computer system) and the encrypted account identifier being shared between a remote application server and the token server, external to the mobile device in which the account information is associated with (e.g., inaccessible to the first remote computing system).
Claim Rejections – 35 USC 103
4. 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 of this title, 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.
5. Claims 1-5, 7, 9, 11-13, 15-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al (US 2016/0180325) in view of Charles et al (US 2010/0088520), further in view of Guglani et al (US 10,255,456).
Regarding claim 1, Davis et al teaches computer-implemented method performed by a server computer system (fig. 1, ‘108) for processing a routing of data between a first remote computing system and a second remote computing system (fig. 1, ‘108, ‘200a, ‘200b, which disclose a server device for facilitating transactions between a mobile consumer device and a mobile merchant device), comprising:
the request comprising a set of parameters, wherein at least one of the parameters defines a condition for routing the data between the first remote computing system and the second remote computing system (fig. 3A-3D, par [0133], lines 10-15, & par [0222], which disclose the request for the server to transmit data between the mobile consumer client device and the mobile merchant device containing stipulations, including risk associated with the remote consumer or merchant and/or cost, corresponding to the consumer device and merchant device);
generating, by a processing system of the server computer system, the token for the routing of data, the token referencing at least the first remote computing system, the second remote computing system, and the set of parameters (par [0123] & par [0130], which disclose the generated token containing data corresponding to the consumer and merchant devices);
sending, by the server computer system, that the token to the second remote computing system (par [0130], lines 14-19, which discloses transmitting the token to the merchant device);
verifying, by the server computer system, one or more of the set of parameters are satisfied by one or more corresponding current parameters associated with the routing of data between the first remote computing system and the second remote computing system (par [0223], lines 4-9, which discloses the server providing a notification disclosing that data corresponding to user payment credentials have been received and merchant payment credentials have been successfully processed), the one or more satisfied parameters comprising the condition (par [0130], lines 16-19 and par [0131], lines 1-5, which disclose the server payment engine validating credentials corresponding to both the client and merchant); and
subsequent to verifying that the one or more of the parameters are satisfied by the one or more corresponding current parameters, processing, by the server computer system, the routing of data between the first remote computing system and the second remote computing system using the set of parameters referenced by the token (fig. 2-3D & par [0074], which disclose validating data transfer between the merchant and consumer device, via the intermediary server, upon the token referencing payment credentials associated with the consumer and merchant devices).
Davis et al does not explicitly teach receiving, by an interface of the server computer system from the first remote computing system, a request to generate a token for the routing of data between the first remote computing system and the second remote computing system and receiving, by the interface of the server computer system, a request to initiate the routing of data between the first remote computing system and the second remote computing system, the request comprising the token.
However, Charles et al teaches receiving, by an interface of the server computer system from the first remote computing system, a request to generate a token for the routing of data between the first remote computing system and the second remote computing system (par [0049], lines 1-10 and par [0050], lines 5-15, which disclose a client transmitting a token generation request to a central server for initiating a transaction with another peer), and
receiving, by the interface of the server computer system (par [0050], lines 13-15, “central server received the request”), a request to initiate the routing of data between the first remote computing system and the second remote computing system, the request comprising the token (par [0050], lines 16-18, which discloses sending the token in a peer-to-peer transaction).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Charles et al within the teachings of Davis et al would provide the predictive result of improving security of processing transactions in a client transaction provisioning environment by using certificated to prevent potentially malicious peers from altering or forging secure content belonging to other peers (as disclosed in par [0047-0048] of Charles et al) because this feature would prevent user payment credentials disclosed by Davis et al from being fraudulently tampered before the requesting client has been authorized to access the content.
Davis et al and Charles et al do not explicitly teach wherein the token includes encrypted account association information associated with the second remote computing system, the encrypted account association information being decipherable by the server computer system and inaccessible to the first remote computing system.
However, Guglani et al teaches wherein the token includes encrypted account association information associated with the second remote computing system (col. 26, lines 1-12, which discloses a stored token containing an encrypted account identification information for an account associated with a mobile device), the encrypted account association information being decipherable by the server computer system (fig. 1, ‘180 & col. 26, lines 55-65, which discloses a token server receiving and decrypting the encrypted account identifier) and inaccessible to the first remote computing system (col. 25, lines 40-52, which discloses the encrypted account identifier being shared between a remote application server and the token server, external to the mobile device in which the account information is associated with).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Guglani et al within the teachings of Davis et al and Charles et al would provide the predictive result of improving security in a payment transaction processing environment by utilizing an encryption key that is transmitted between a token server and an application server, that allows only the token server and application server to view encrypted account information associated with a payor’s mobile device, while preventing a payment processing merchant device from viewing the payor’s secure account credentials (as disclosed in fig. 1 & col. 25, lines 35-55 of Guglani et al).
Regarding claim 2, Davis et al, Charles et al, and Guglani et al teach the limitations of claim 1.
Davis et al further teaches generating, by the server computer system, a randomly generated identifier that references the set of parameters (fig. 3A, ‘320, “generate transaction ID”); and
transmitting, by the server computer system to at least one of the first remote computing system and the second remote computing system, the randomly generated identifier that references the set of parameters (par [0101], lines 9-13, “provide users access to the transaction ID”).
Regarding claim 3, Davis et al, Charles et al, and Guglani et al teach the limitations of claim 1.
Davis et al further teaches receiving, by the server computer system, the randomly generated identifier from one of the first remote computing system or the second remote computing system (par [0106], lines 8-12, “include the transaction ID in any information sent from the client devices”);
accessing, by the server computer system, the set of parameters referenced by the randomly generated identifier (par [0106], lines 12-15, “identify a particular transaction to which the information corresponds”); and
performing the processing, by the server computer system, of the routing of data between the first remote computing system and the second remote computing system subsequent to verification that one or more of the parameters are satisfied (par [0132], lines 7-9, “provide additional authorization information, agree to terms and conditions…”).
Regarding claim 4, Davis et al, Charles et al, and Guglani et al teach the limitations of claim 1.
Davis et al further teaches wherein the randomly generated identifier comprises a pointer or link to a data storage location of a data store where the set of parameters are stored by the server computer system, and wherein the pointer or the link is the token (par [0123], lines 5-10, “random string called a “token” as a pointer to the stored payment credential”).
Regarding claim 5, Davis et al, Charles et al, and Guglani et al teach the limitations of claim 1.
Davis et al further teaches wherein the randomly generated identifier is stored in an object or file, and wherein the object or file comprises the token (par [0074], lines 1-4, “token can reference a payment credential stored by the network application”).
Regarding claim 7, Davis et al, Charles et al, and Guglani et al teach the limitations of claim 1.
Davis et al further teaches wherein the interface comprises an application programming interface (API) request interface (par [0086], lines 1-5, “employ one or more application programming interfaces (APIs)”), and wherein the request to initiate the routing of data between the first remote computing system and the second remote computing system is received as an API message transmitted to the API request interface over a communications network.
Regarding claim 9, Davis et al, Charles et al, and Guglani et al teach the limitations of claim 1.
Davis et al further teaches analyzing, by the server computer system, one or more fraud detection parameters associated with the request to generate the token (par [0096], lines 1-10, “determining the likelihood of fraudulent activity”);
detecting, by the server computer system, whether a risk of fraud determined based on the analysis of the one or more fraud detection parameters satisfies a fraud detection threshold (fig. 2, ‘238, “risk calculator”);
rejecting, by the server computer system, the request to generate the token when the risk of fraud fails to satisfy the fraud detection threshold (par [0097], “risk associated with the consumer/merchant is below a predetermined threshold”); and
accepting, by the server computer system, the request to generate the token when the risk of fraud satisfies the fraud detection threshold (par [0123], lines 1-5, “after determining the risk, the payment engine 206 can generate 316 a token”).
Regarding claim 11, Davis et al teaches a non-transitory machine-readable medium, having instructions stored thereon, which when executed by a processing system of a server computer system (fig. 1, ‘108) cause the server computer system to perform operations for processing a routing of data between a first remote computing system and a second remote computing system (fig. 1, ‘108, ‘200a, ‘200b, which disclose a server device for facilitating transactions between a mobile consumer device and a mobile merchant device), comprising:
the request comprising a set of parameters, wherein at least one of the parameters defines a condition for routing the data between the first remote computing system and the second remote computing system (fig. 3A-3D, par [0133], lines 10-15, & par [0222], which disclose the request for the server to transmit data between the mobile consumer client device and the mobile merchant device containing stipulations, including risk associated with the remote consumer or merchant and/or cost, corresponding to the consumer device and merchant device);
generating, by a processing system of the server computer system, the token for the routing of data, the token referencing at least the first remote computing system, the second remote computing system, and the set of parameters (par [0123] & par [0130], which disclose the generated token containing data corresponding to the consumer and merchant devices);
sending, by the server computer system, the token to the second remote computing system (par [0130], lines 14-19, which discloses transmitting the token to the merchant device);
verifying, by the server computer system, that one or more of the parameters are satisfied by one or more corresponding current parameters associated with the routing of data between the first remote computing system and the second remote computing system (par [0223], lines 4-9, which discloses the server providing a notification disclosing that data corresponding to user payment credentials have been received and merchant payment credentials have been successfully processed), the one or more satisfied parameters comprising the condition (par [0130], lines 16-19 and par [0131], lines 1-5, which disclose the server payment engine validating credentials corresponding to both the client and merchant); and
subsequent to verifying that the one or more of the parameters are satisfied by the one or more corresponding current parameters, processing, by the server computer system, the routing of data between the first remote computing system and the second remote computing system using the set of parameters referenced by the token (fig. 2-3D & par [0074], which disclose validating data transfer between the merchant and consumer device, via the intermediary server, upon the token referencing payment credentials associated with the consumer and merchant devices).
Davis et al does not explicitly teach receiving, by the interface of the server computer system from the first remote computing system, a request to generate a token for the routing of data between the first remote computing system and the second remote computing system and in response to receiving a request to initiate the routing of data between the first remote computing system and the second remote computing system, the request comprising the token.
However, Charles et al teaches receiving, by an interface of the server computer system from the first remote computing system, a request to generate a token for the routing of data between the first remote computing system and the second remote computer system (par [0049], lines 1-10 and par [0050], lines 5-15, which disclose a client transmitting a token generation request to a central server for initiating a transaction with another peer), and
in response to receiving a request to initiate the routing of data between the first remote computing system and the second remote computing system, the request comprising the token (par [0050], lines 16-18, which discloses sending the token in a peer-to-peer transaction).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Charles et al within the teachings of Davis et al would provide the predictive result of improving security of processing transactions in a client transaction provisioning environment by using certificated to prevent potentially malicious peers from altering or forging secure content belonging to other peers (as disclosed in par [0047-0048] of Charles et al) because this feature would prevent user payment credentials disclosed by Davis et al from being fraudulently tampered before the requesting client has been authorized to access the content.
Davis et al and Charles et al do not explicitly teach wherein the token includes encrypted account association information associated with the second remote computing system, the encrypted account association information being decipherable by the server computer system and inaccessible to the first remote computing system.
However, Guglani et al teaches wherein the token includes encrypted account association information associated with the second remote computing system (col. 26, lines 1-12, which discloses a stored token containing an encrypted account identification information for an account associated with a mobile device), the encrypted account association information being decipherable by the server computer system (fig. 1, ‘180 & col. 26, lines 55-65, which discloses a token server receiving and decrypting the encrypted account identifier) and inaccessible to the first remote computing system (col. 25, lines 40-52, which discloses the encrypted account identifier being shared between a remote application server and the token server, external to the mobile device in which the account information is associated with).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Guglani et al within the teachings of Davis et al and Charles et al would provide the predictive result of improving security in a payment transaction processing environment by utilizing an encryption key that is transmitted between a token server and an application server, that allows only the token server and application server to view encrypted account information associated with a payor’s mobile device, while preventing a payment processing merchant device from viewing the payor’s secure account credentials (as disclosed in fig. 1 & col. 25, lines 35-55 of Guglani et al).
Regarding claim 12, Davis et al, Charles et al, and Wong teach the limitations of claim 11.
Davis et al further teaches generating, by the server computer system, a randomly generated identifier that references the set of parameters (fig. 3A, ‘320, “generate transaction ID”); and
transmitting, by the server computer system to at least one of the first remote computing system and the second remote computing system, the randomly generated identifier that references the set of parameters (par [0101], lines 9-13, “provide users access to the transaction ID”).
Regarding claim 13, Davis et al, Charles et al, and Wong teach the limitations of claim 11.
Davis et al further teaches receiving, by the server computer system, the randomly generated identifier from one of the first remote computing system or the second remote computing system (par [0106], lines 8-12, “include the transaction ID in any information sent from the client devices”);
accessing, by the server computer system, the set of parameters referenced by the randomly generated identifier (par [0106], lines 12-15, “identify a particular transaction to which the information corresponds”); and
performing the processing, by the server computer system, of the routing of data between the first remote computing system and the second remote computing system subsequent to verification that one or more of the parameters are satisfied (par [0132], lines 7-9, “provide additional authorization information, agree to terms and conditions…”).
Regarding claim 15, Davis et al, Charles et al, and Wong teach the limitations of claim 11.
Davis et al further teaches analyzing, by the server computer system, one or more fraud detection parameters associated with the request to generate the token (par [0096], lines 1-10, “determining the likelihood of fraudulent activity”);
detecting, by the server computer system, whether a risk of fraud determined based on the analysis of the one or more fraud detection parameters satisfies a fraud detection threshold (fig. 2, ‘238, “risk calculator”);
rejecting, by the server computer system, the request to generate the token when the risk of fraud fails to satisfy the fraud detection threshold (par [0097], “risk associated with the consumer/merchant is below a predetermined threshold”); and
accepting, by the server computer system, the request to generate the token when the risk of fraud satisfies the fraud detection threshold (par [0123], lines 1-5, “after determining the risk, the payment engine 206 can generate 316 a token”).
Regarding claim 16, Davis et al teaches a server computer system (fig. 1, ‘108) for processing a routing of data between a first remote computing system and a second remote computing system (fig. 1, ‘108, ‘200a, ‘200b, which disclose a server device for facilitating transactions between a mobile consumer device and a mobile merchant device), comprising:
a memory storing instructions (fig. 7, ‘704); and
a processing system, coupled with the memory, and configured to execute the instructions causing the server computer system to perform operations (fig. 7, ‘702/‘704), comprising:
the request comprising a set of parameters, wherein at least one of the set of parameters defines a condition for routing the data between the first remote computing system and the second remote computing system (fig. 3A-3D, par [0133], lines 10-15, & par [0222], which disclose the request for the server to transmit data between the mobile consumer client device and the mobile merchant device containing stipulations, including risk associated with the remote consumer or merchant and/or cost, corresponding to the consumer device and merchant device);
generating the token for the routing of data, the token referencing at least the first remote computing system, the second remote computing system, and the set of parameters (par [0123] & par [0130], which disclose the generated token containing data corresponding to the consumer and merchant devices);
sending the token to the second remote computing system (par [0130], lines 14-19, which discloses transmitting the token to the merchant device);
verifying that one or more of the parameters are satisfied by one or more corresponding current parameters associated with the routing of data between the first remote computing system and the second remote computing system (par [0223], lines 4-9, which discloses the server providing a notification disclosing that data corresponding to user payment credentials have been received and merchant payment credentials have been successfully processed), the one or more satisfied parameters comprising the condition (par [0130], lines 16-19 and par [0131], lines 1-5, which disclose the server payment engine validating credentials corresponding to both the client and merchant); and
subsequent to verifying that the one or more of the set of parameters are satisfied by the one or more corresponding current parameters the routing of data between the first remote computing system and the second remote computing system using the set of parameters referenced by the token (fig. 2-3D & par [0074], which disclose validating data transfer between the merchant and consumer device, via the intermediary server, upon the token referencing payment credentials associated with the consumer and merchant devices).
Davis et al does not explicitly teach receiving, by an interface of the server computer system from the first remote computing system, a request to generate a token for the routing of data between the first remote computing system and the second remote computing system and receiving a request to initiate the routing of data between the first remote computing system and the second remote computing system, the request comprising the token.
However, Charles et al teaches receiving, by an interface of the server computer system from the first remote computing system, a request to generate a token for the routing of data between the first remote computing system and the second remote computing system (par [0049], lines 1-10 and par [0050], lines 5-15, which disclose a client transmitting a token generation request to a central server for initiating a transaction with another peer), and
receiving a request to initiate the routing of data between the first remote computing system and the second remote computing system, the request comprising the token (par [0050], lines 16-18, which discloses sending the token in a peer-to-peer transaction).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Charles et al within the teachings of Davis et al would provide the predictive result of improving security of processing transactions in a client transaction provisioning environment by using certificated to prevent potentially malicious peers from altering or forging secure content belonging to other peers (as disclosed in par [0047-0048] of Charles et al) because this feature would prevent user payment credentials disclosed by Davis et al from being fraudulently tampered before the requesting client has been authorized to access the content.
Davis et al and Charles et al do not explicitly teach wherein the token includes encrypted account association information associated with the second remote computing system, the encrypted account association information being decipherable by the server computer system and inaccessible to the first remote computing system.
However, Guglani et al teaches wherein the token includes encrypted account association information associated with the second remote computing system (col. 26, lines 1-12, which discloses a stored token containing an encrypted account identification information for an account associated with a mobile device), the encrypted account association information being decipherable by the server computer system (fig. 1, ‘180 & col. 26, lines 55-65, which discloses a token server receiving and decrypting the encrypted account identifier) and inaccessible to the first remote computing system (col. 25, lines 40-52, which discloses the encrypted account identifier being shared between a remote application server and the token server, external to the mobile device in which the account information is associated with).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Guglani et al within the teachings of Davis et al and Charles et al would provide the predictive result of improving security in a payment transaction processing environment by utilizing an encryption key that is transmitted between a token server and an application server, that allows only the token server and application server to view encrypted account information associated with a payor’s mobile device, while preventing a payment processing merchant device from viewing the payor’s secure account credentials (as disclosed in fig. 1 & col. 25, lines 35-55 of Guglani et al).
Regarding claim 17, Davis et al, Charles et al, and Guglani et al teach the limitations of claim 16.
Davis et al further teaches generating a randomly generated identifier that references the set of parameters (fig. 3A, ‘320, “generate transaction ID”); and
transmitting to at least one of the first remote computing system and the second remote computing system, the randomly generated identifier that references the set of parameters (par [0101], lines 9-13, “provide users access to the transaction ID”).
Regarding claim 18, Davis et al, Charles et al, and Guglani et al teach the limitations of claim 16.
Davis et al further teaches receiving the randomly generated identifier from one of the first remote computing system or the second remote computing system (par [0106], lines 8-12, “include the transaction ID in any information sent from the client devices”);
accessing the set of parameters referenced by the randomly generated identifier (par [0106], lines 12-15, “identify a particular transaction to which the information corresponds”); and
performing the processing, by the server computer system, of the routing of data between the first remote computing system and the second remote computing system subsequent to verification that the one or more parameters is satisfied (par [0132], lines 7-9, “provide additional authorization information, agree to terms and conditions…”).
Regarding claim 20, Davis et al, Charles et al, and Guglani et al teach the limitations of claim 16.
Davis et al further teaches analyzing one or more fraud detection parameters associated with the request to generate the token (par [0096], lines 1-10, “determining the likelihood of fraudulent activity”);
detecting whether a risk of fraud determined based on the analysis of the one or more fraud detection parameters satisfies a fraud detection threshold (fig. 2, ‘238, “risk calculator”);
rejecting the request to generate the token when the risk of fraud fails to satisfy the fraud detection threshold (par [0097], “risk associated with the consumer/merchant is below a predetermined threshold”); and
accepting the request to generate the token when the risk of fraud satisfies the fraud detection threshold (par [0123], lines 1-5, “after determining the risk, the payment engine 206 can generate 316 a token”).
7. Claims 6, 10, 14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al (US 2016/0180325) in view of Charles et al (US 2010/0088520), in view of Guglani et al (US 10,255,456), further in view of Hazel et al (US 2016/0027003).
Regarding claim 6, Davis et al does not explicitly teach receiving, by the interface of the server computer system, a validation challenge and a challenge response defined by the first remote computing system; and performing, by the server computer system, a validation of the second remote computing system based on the validation challenge and the challenge response defined by the first remote computing system.
However, Charles et al teaches receiving, by the interface of the server computer system, a validation challenge and a challenge response defined by the first remote computing system (par [0041], “challenge & response”); and
performing, by the server computer system, a validation of the second remote computing system based on the validation challenge and the challenge response defined by the first remote computing system (par [0041-0042], “authorizing the client to perform the series of transactions with the peer”).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Charles et al within the teachings of Davis et al would provide the predictive result of improving security of processing transactions in a client transaction provisioning environment by using certificated to prevent potentially malicious peers from altering or forging secure content belonging to other peers (as disclosed in par [0047-0048] of Charles et al) because this feature would prevent user payment credentials disclosed by Davis et al from being fraudulently tampered before the requesting client has been authorized to access the content.
Davis et al, Charles et al, and Guglani et al do not explicitly teach wherein the set of parameters comprises an incomplete set of parameters, and subsequent to a successful validation of the second remote computing system, receiving, by the interface of the server computer system, a second set of parameters from the second remote computing system, wherein the incomplete set of parameters and the second set of parameters form a complete set of parameters referenced by the token.
However, Hazel et al further teaches wherein the set of parameters comprises an incomplete set of parameters (par [0031], lines 7-12, “blank fields for input of transaction information”), and
subsequent to a successful validation of the second remote computing system, receiving, by the interface of the server computer system, a second set of parameters from the second remote computing system, wherein the incomplete set of parameters and the second set of parameters form a complete set of parameters referenced by the token (par [0050], lines 1-15, which discloses populating the field data with referenced information).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Hazel et al within the teachings of Davis et al, Charles et al, and Guglani et al would provide the predictive result of expediting token-based authentication for accessing secure content by incorporating the automatic populating of encrypted user credentials (as disclosed in par [0033] of Hazel et al) because this feature allows for faster access to authentication-requiring credentials while ensuring the automatically populated data remains encrypted.
Regarding claim 10, Davis et al, Charles et al, and Guglani et al do not explicitly teach wherein the one or more fraud detection parameters associated with the request to generate the token comprise: one or more of a total number of tokens requested by the first remote computing system over a period of time, a total number of routings of data processed by the server computer system for the first remote computing system, and whether one of the set of parameters deviates from an expected parameter value.
However, Hazel et al further teaches wherein the one or more fraud detection parameters (par [0071], lines 12-16) associated with the request to generate the token comprise:
one or more of a total number of tokens requested by the first remote computing system over a period of time (par [0044], lines 6-8, “obtain the information from a variety of different types of tokens”), a total number of routings of data processed by the server computer system for the first remote computing system, and whether one of the set of parameters deviates from an expected parameter value (par [0070], lines 13-15, “transaction amounts”).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Hazel et al within the teachings of Davis et al, Charles et al, and Guglani et al according to the motivation disclosed regarding claim 6.
Regarding claim 14, Davis et al does not explicitly teach receiving, by the interface of the server computer system, a validation challenge and a challenge response defined by the first remote computing system; and performing, by the server computer system, a validation of the second remote computing system based on the validation challenge and the challenge response defined by the first remote computing system.
However, Charles et al teaches receiving, by the interface of the server computer system, a validation challenge and a challenge response defined by the first remote computing system (par [0041], “challenge & response”); and
performing, by the server computer system, a validation of the second remote computing system based on the validation challenge and the challenge response defined by the first remote computing system (par [0041-0042], “authorizing the client to perform the series of transactions with the peer”).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Charles et al within the teachings of Davis et al would provide the predictive result of improving security of processing transactions in a client transaction provisioning environment by using certificated to prevent potentially malicious peers from altering or forging secure content belonging to other peers (as disclosed in par [0047-0048] of Charles et al) because this feature would prevent user payment credentials disclosed by Davis et al from being fraudulently tampered before the requesting client has been authorized to access the content.
Davis et al, Charles et al, and Guglani et al do not explicitly teach wherein the set of parameters comprises an incomplete set of parameters, and in response to a successful validation of the second remote computing system, receiving, by the interface of the server computer system, a second set of parameters from the second remote computing system, wherein the incomplete set of parameters and the second set of parameters form a complete set of parameters referenced by the token.
However, Hazel et al further teaches wherein the set of parameters comprises an incomplete set of parameters (par [0031], lines 7-12, “blank fields for input of transaction information”), and
subsequent to a successful validation of the second remote computing system, receiving, by the interface of the server computer system, a second set of parameters from the second remote computing system, wherein the incomplete set of parameters and the second set of parameters form a complete set of parameters referenced by the token (par [0050], lines 1-15, which discloses populating the field data with referenced information).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Hazel et al within the teachings of Davis et al, Charles et al, and Guglani et al would provide the predictive result of expediting token-based authentication for accessing secure content by incorporating the automatic populating of encrypted user credentials (as disclosed in par [0033] of Hazel et al) because this feature allows for faster access to authentication-requiring credentials while ensuring the automatically populated data remains encrypted.
Regarding claim 19, Davis et al does not explicitly teach receiving, by the interface of the server computer system, a validation challenge and a challenge response defined by the first remote computing system; and performing a validation of the second remote computing system based on the validation challenge and the challenge response defined by the first remote computing system.
However, Charles et al teaches receiving, by the interface of the server computer system, a validation challenge and a challenge response defined by the first remote computing system (par [0041], “challenge & response”); and
performing a validation of the second remote computing system based on the validation challenge and the challenge response defined by the first remote computing system (par [0041-0042], “authorizing the client to perform the series of transactions with the peer”).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Charles et al within the teachings of Davis et al would provide the predictive result of improving security of processing transactions in a client transaction provisioning environment by using certificated to prevent potentially malicious peers from altering or forging secure content belonging to other peers (as disclosed in par [0047-0048] of Charles et al) because this feature would prevent user payment credentials disclosed by Davis et al from being fraudulently tampered before the requesting client has been authorized to access the content.
Davis et al, Charles et al, and Guglani et al do not explicitly teach wherein the set of parameters comprises an incomplete set of parameters, and in response to a successful validation of the second remote computing system, receiving, by the interface of the server computer system, a second set of parameters from the second remote computing system, wherein the incomplete set of parameters and the second set of parameters form a complete set of parameters referenced by the token.
However, Hazel et al further teaches wherein the set of parameters comprises an incomplete set of parameters (par [0031], lines 7-12, “blank fields for input of transaction information”), and
subsequent to a successful validation of the second remote computing system, receiving, by the interface of the server computer system, a second set of parameters from the second remote computing system, wherein the incomplete set of parameters and the second set of parameters form a complete set of parameters referenced by the token (par [0050], lines 1-15, which discloses populating the field data with referenced information).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to combine the disclosure of Hazel et al within the teachings of Davis et al, Charles et al, and Guglani et al would provide the predictive result of expediting token-based authentication for accessing secure content by incorporating the automatic populating of encrypted user credentials (as disclosed in par [0033] of Hazel et al) because this feature allows for faster access to authentication-requiring credentials while ensuring the automatically populated data remains encrypted.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Randy A. Scott whose telephone number is (571) 272-3797. The examiner can normally be reached on Monday-Thursday 7:30 am-5:00 pm, second Fridays 7:30 am-4pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Luu Pham can be reached on (571) 270-5002. 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 http://pair-direct.uspto.gov. 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.
/RANDY A SCOTT/Primary Examiner, Art Unit 2439
20260923
