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 .
Detailed Action
Claims 1, 8, 14, and 17 have been amended
Claims 2 and 7 have been cancelled
Claims 21 and 22 are added new
Claims 1, 3-6, 8-22 are pending
Priority
This application claims no priority. Therefore, the effective filing date of this application is 11/06/2024.
Response to Arguments
Applicant’s arguments filed on 05/11/2026 have been fully considered.
With respect to the claim objection for claim 17. The objection has been overcome due to Applicant’s filed amendment
With respect to the USC 112(b) rejection for claim 2. The rejection has been overcome due to Applicant canceling the claim.
With respect to the USC 101 abstract rejection for claims 1-20 Applicant has argued that the amendment of “reencode the request into an envelope, using the permanent identifier instead of the virtual identifier, that is transparent to the second card network, wherein the envelope is transparent to the second card network by refraining from indicating the proxy device as a source of the request, and the envelope indicates the acquiring device as the source of the request” overcomes the 101 abstract rejection. Examiner respectfully disagrees. The limitation of reencoding the request envelope using a permanent identifier is just a form of data manipulation/transformation. The request is being transformed into an envelope with a permanent identifier, this is transforming the request data. Simply by refraining to indicate the proxy device as a source of the request does not overcome the 101 abstract rejection. Furthermore, the claim limitations do not integrate the claim into a practical application. The claim recites of “transmit the envelope to the second card network for processing”. However, simply transmitting data is not a practical application. As discussed during the interview held on 05/06/2026 Examiner suggests amending the claim with features of para. 0031 of the specification in particular “process a transaction according to the request and may transmit an approval of the event to the second card network device … the processing device may output the approval to a user (e.g., via an output component of the processing device)”. Examiner believes approving a transaction and outputting the approval to a user via an output component will incorporate the limitations into a practical application.
With respect to the arguments of the USC 103 rejection Applicant has argued that YOO-GOODMAN-O'SULLIVAN fail to teach the newly amended limitation of “wherein the envelope is transparent to the second card network by refraining from indicating the proxy device as a source of the request, and the envelope indicates the acquiring device as the source of the request”. Examiner respectfully disagrees. After further review GOODMAN teaches ([GOODMAN, para. 0050] “the authentication module 216 may be configured to verify a unique identifier included in a transaction request as corresponding to an ATM 106 at which a transaction related to the transaction request may be processed.”) ([GOODMAN, para. 0044] “The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some embodiments, the receiving device 202 may be configured to receive data from ATMs 106”), ([GOODMAN, para. 0045] “the receiving device 202 may be further configured to receive data signals electronically transmitted by the ATM 106, which may be transmitted using a communication channel separate from the payment rails, and may be superimposed or otherwise encoded with a unique identifier, such as for use in verifying the ATM 106 as one intended in a received transaction request.”) ([GOODMAN, para. 0041] “The payment network 110 may receive the authorization request from the ATM 106, or from the processing server 102 acting on behalf of the ATM 106, and may process the transaction using traditional methods and systems. … The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”). As can be seen from these citations, GOODMAN teaches of receiving data from the ATM device to a processing server. Furthermore, GOODMAN teaches of superimposing the received data signals with the unique identifier of the ATM. The processing server then relays the request over to the processing server acting on behalf of the ATM. Examiner is interpreting the ATM as the acquirer device and the processing server as the proxy device. The unique identifier is the source of the ATM machine and superimposing the data with the unique identifier teaches of an envelope that indicates the acquiring device as the source of the request. Therefore, GOODMAN teaches this amended limitation.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation is:
“a proxy device configured to receive requests” in claim 1
Because this claim limitation(s) is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it is being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
See specification para. [0003, 0023] for functional support
See specification para. [0039, 0052-0054] for hardware support
If applicant does not intend to have this limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 3-6, 8-22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 8 recite the limitation “receive, from an acquiring device at a proxy device configured to receive requests”. It is unclear from this limitation if the acquiring device is a part of the of the proxy device, or a separate device sending requests from the acquiring device to the proxy device. For the purpose of examination Examiner is interpreting this limitation with a comma after acquiring device to separate the two devices, as “receive, from an acquiring device, at a proxy device configured to receive requests”. Appropriate correction is required.
Claims 3-6 and 9-13 depend on claims 1 and 8. Therefore, they also inherit the rejection.
Claims 14, 17, and 18 recite the limitation “as a source of the request”. However, claim 14 recites of two requests “a request to link a virtual identifier” and “a request to authorize an event”. It is unclear which of the requests “the request” is referring to. For the purpose of examination Examiner is interpreting “the request” in claim 14 as “as a source of the request to authorize the event” and Examiner is interpreting “the request” in claims 17 and 18 as “the request to link the virtual identifier”. Appropriate correction is required.
Claims 15, 16, 19-22 depend on claim 14. Therefore, they also inherit the rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-6, 8-22 are rejected under 35 U.S.C. 101 because they directed to an abstract idea.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites of a system for routing requests across card networks, the system comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to: receive, from an acquiring device at a proxy device configured to receive requests on behalf of a first card network, a request to authorize an event, wherein the request includes a virtual identifier that is associated with the first card network; map the virtual identifier to a permanent identifier that is associated with a second card network different from the first card network; reencode the request into an envelope, using the permanent identifier instead of the virtual identifier, that is transparent to the second card network, wherein the envelope is transparent to the second card network by refraining from indicating the proxy device as a source of the request, and the envelope indicates the acquiring device as the source of the request; and transmit the envelope to the second card network for processing.
The limitation of system for routing requests across card networks, the system comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to: receive, from an acquiring device at a proxy device configured to receive requests on behalf of a first card network, a request to authorize an event, wherein the request includes a virtual identifier that is associated with the first card network, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually route requests and receive a request to authorize an event from a first card network.
The limitation of map the virtual identifier to a permanent identifier that is associated with a second card network different from the first card network, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually map a virtual identifier to a permanent identifier that is associated with a second card network different from the first card network.
The limitation of reencode the request into an envelope, using the permanent identifier instead of the virtual identifier, that is transparent to the second card network, wherein the envelope is transparent to the second card network by refraining from indicating the proxy device as a source of the request, and the envelope indicates the acquiring device as the source of the request, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually reencode a request envelope by using the permanent identifier instead of the virtual identifier.
The limitation of transmit the envelope to the second card network for processing, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually transmit an envelope of data.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic statement such as “system comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to”, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. The claim recites of a limitation of “transmit the envelope to the second card network for processing”. This limitation is used to generally send data over to a second network for processing without placing any limits on how the “processing” functions and what is the outcome of sending the envelope of data to the second card network. Merely receiving a request, performing mapping, reencoding the request into an envelope, and transmitting the envelope does not integrate the abstract idea into a practical application. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, the claim only recites one additional element of “system comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to”. The “processors” recited at a high-level of generality (i.e., as a generic processor performing the method) such that it amounts no more than mere instructions to apply the exception using a generic processor. Mere instructions to apply an exception using a generic processor cannot provide an inventive concept. The claim is not patent eligible.
Claim 3 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the one or more processors, to map the virtual identifier to the permanent identifier, are configured to: use a data structure, stored in the one or more memories, that stores virtual identifiers in association with permanent identifiers. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine a data structure that stores virtual identifiers in association with permanent identifiers. Furthermore, mere instructions to apply an exception using a generic processor cannot provide an inventive concept.
Claim 4 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the one or more processors are configured to: receive the data structure from an issuing device. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually receive data from an issuing device. Furthermore, mere instructions to apply an exception using a generic processor cannot provide an inventive concept.
Claim 5 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the one or more processors, to map the virtual identifier to the permanent identifier, are configured to: identify an indicator, included in the virtual identifier, that the virtual identifier is to be detokenized; transmit, to a detokenizer device, a request for the permanent identifier that indicates the virtual identifier; and receive, from the detokenizer device, a response to the request that indicates the permanent identifier. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually identify an indicator, included in the virtual identifier, send a request for the permanent identifier that indicates the virtual identifier to detokenizer device, and receive a response to the request that indicates the permanent identifier. The claim simply recites of sending a request comprising data and receiving back requested data. Furthermore, mere instructions to apply an exception using a generic processor or device cannot provide an inventive concept.
Claim 6 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the indicator is associated with the detokenizer device from a plurality of possible detokenizer devices. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine an indicator is associated with the detokenizer device.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Furthermore, claim 8 recites of features similar to that of claim 1. Therefore, claim 8 is rejected in a similar manner as in the rejection of claim 1.
This judicial exception is not integrated into a practical application. The claim recites of a limitation of “proxy device”. This limitation is used to generally use a device to receive requests, perform mapping, replace virtual identifier in the request with the permanent identifier, and transmit a detokenized request. Merely receiving a request, performing mapping, reencoding the request into an envelope, and transmitting the envelope does not integrate the abstract idea into a practical application. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claim is directed to an abstract idea. The claim is not patent eligible.
Claim 9 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein transmitting the detokenized request to the second card network comprises: transmitting the detokenized request to an acquiring device for delivery to the second card network. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually transmit detokenized request to an acquiring device.
Claim 10 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein mapping the virtual identifier to the permanent identifier comprises: applying an algorithm, by the proxy device, to convert the virtual identifier into the permanent identifier. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually apply an algorithm, to convert the virtual identifier into the permanent identifier.
Claim 11 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Furthermore, this claim recites of features similar to that of claim 5. Therefore, claim 11 is rejected in a similar manner.
Claim 12 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the request is received from an acquiring device, and the detokenized request indicates the acquiring device as a source. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually receive from an acquiring device the detokenized request which indicates the acquiring device as a source.
Claim 13 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the detokenized request indicates the proxy device as a source. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine the detokenized request indicates the proxy device as a source.
Claim 14 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites of a non-transitory computer-readable medium storing a set of instructions for generating a virtual identifier that routes across card networks, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a device, cause the device to: receive a request to link a virtual identifier, associated with a first card network, to a permanent identifier that is associated with a second card network different from the first card network; generate a data structure that stores the virtual identifier in association with the permanent identifier; and transmit the data structure to a detokenizer device associated with a proxy device of the first card network; wherein the data structure enables the proxy device to route a request to authorize an event, from an acquiring device, from the first card network to the second card network for processing using the permanent identifier and identifying the acquiring device, to the second card network, as a source of the request instead of the proxy device.
The limitation of receive a request to link a virtual identifier, associated with a first card network, to a permanent identifier that is associated with a second card network different from the first card network, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually receive a request to link a virtual identifier to a permanent identifier.
The limitation of generate a data structure that stores the virtual identifier in association with the permanent identifier, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually generate a data structure.
The limitation of transmit the data structure to a detokenizer device associated with a proxy device of the first card network, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually transmit data structure to a detokenizer device.
The limitation of wherein the data structure enables the proxy device to route a request to authorize an event, from an acquiring device, from the first card network to the second card network for processing using the permanent identifier and identifying the acquiring device, to the second card network, as a source of the request instead of the proxy device, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually transform the data structure to enable second card network to identify the acquiring device as the source of the request instead of the proxy device.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic statement such as “non-transitory computer-readable medium storing a set of instructions”, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. The claim recites of a limitation of “transmit the data structure to a detokenizer device associated with a proxy device of the first card network”. This limitation is used to generally send data over to a detokenizer device without placing any limits on what is the outcome of sending the data structure. Merely receiving a request, generating a data structure, and transmitting the data structure does not integrate the abstract idea into a practical application. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, the claim only recites one additional element of “the set of instructions comprising: one or more instructions that, when executed by one or more processors of a device, cause the device to”. The “one or more processors of a device” recited at a high-level of generality (i.e., as a generic processor performing the method) such that it amounts no more than mere instructions to apply the exception using a generic processor. Mere instructions to apply an exception using a generic processor cannot provide an inventive concept. The claim is not patent eligible.
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the detokenizer device is at least partially integrated with the proxy device. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine a detokenizer device is at least partially integrated with the proxy device.
Claim 16 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of transmit, to the proxy device, an indication that the data structure was sent to the detokenizer device. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually transmit, to the proxy device, an indication that the data structure was sent to the detokenizer device.
Claim 17 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of cause the device to receive the request to link the virtual identifier to the permanent identifier, cause the device to: receive the request from a user device. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually receive a request from a user device to link the virtual identifier to the permanent identifier.
Claim 18 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of cause the device to: receive, from the user device, a set of credentials, wherein the request is received based on verifying the set of credentials. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually receive, from the user device, a set of credentials and verify the credentials.
Claim 19 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of cause the device to: validate the permanent identifier, wherein the data structure is generated in response to validating the permanent identifier. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually validate the permanent identifier.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites “cause the device to: transmit, to a user device, a confirmation that the virtual identifier was linked to the permanent identifier”. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually send a confirmation that the virtual identifier was linked to the permanent identifier. This judicial exception is not integrated into a practical application. This limitation is used to generally send data over to user device without placing any limits on what the outcome of sending the confirmation is.
Claim 21 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites “wherein the virtual identifier is generated using pseudo-random number generation or algorithmic modification of the permanent identifier”. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually generate virtual identifiers by algorithmically modifying the permanent identifier.
Claim 22 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites wherein the data structure includes an encrypted version of the permanent identifier. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually store data in encrypted form.
The dependent claims 3-6, 9-13, and 15-22 are directed to abstract ideas and do not include additional elements that are sufficient to amount to significantly more than the judicial exception. This judicial exception is not integrated into a practical application. Therefore, the claims are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) 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.
Claims 1, 3-6, 8-13 are rejected under 35 U.S.C. 103 as being unpatentable over YOO (US-20220067704-A1), in view of GOODMAN (US-20180068297-A1), and further in view of O'SULLIVAN (US-20200160298-A1), hereinafter YOO-GOODMAN-O'SULLIVAN.
Regarding claim 1, YOO teaches “A system for routing requests across card networks, the system comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to: receive from an acquiring device at a proxy device configured to receive requests on behalf of a first card network, a request to authorize an event, wherein the request includes a virtual identifier that is associated with a first card network, wherein the system is configured to receive requests …; ([YOO, para. 0069] “when a POS device 30 makes a payment through the virtual token generation means 10 (e.g., a mobile terminal equipped with a virtual token generation program), the virtual token verification means 20 may receive the virtual token from a payment settlement service server 40 that receives the virtual token from the POS device 30.”) ([YOO, para. 0132] “Referring to FIG. 7, a virtual token-based payment providing method according to an embodiment of the inventive concept includes a step S200 (a step for receiving a virtual token) for receiving a virtual token provided by a virtual token generation means, by a virtual token verification means, a step S400 for extracting multiple detailed codes included in the virtual token by the virtual token verification means”) ([YOO, para. 0135] “Moreover, the virtual token further includes the fixed code. The fixed code includes a code for determining the card issuer or the card type corresponding to the actual card number or a code for identifying whether to correspond to the virtual token. The fixed code is combined at the predetermined location within the virtual token.”) ([YOO, para. 0148] “Accordingly, the virtual token verification means receives the virtual token from the payment settlement service server. At this time, the payment settlement service server receives the virtual token from the payment program driven by the financial transaction terminal (e.g., a POS device) 30 or a computer.”) ([YOO, para. 0081] “The virtual token verification means 20 may include several virtual token generation functions corresponding to several groups (e.g., a plurality of card issuers and card types)”) ([YOO, para. 0139] “the virtual token includes the fixed code corresponding to an issuer identification code, the virtual token verification device 200 (e.g., a card issuer server) assigns a virtual token generation function for each card type of each card issuer distinguished by an issuer identification number.” map the virtual identifier to a permanent identifier that is associated with a … card network …; ([YOO, para. 0150] “step S400 for extracting the detailed code may extract the fixed code from the virtual token, may determine the card type group of the virtual token generation means based on the fixed code, and may determine the virtual token generation function or the storage location search algorithm for the card type group.”) ([YOO, para. 0153] “In S1000, the virtual token verification means 20 searches for the storage location of the actual card number based on a plurality of detailed codes (a step for searching for the actual card number). The plurality of detailed codes have the correlation between each other; the virtual token verification means 20 searches for the storage location of the actual card number based on the correlation between the detailed codes.”) ([YOO, para. 0169] “the step S1000 for searching for the actual card number includes the step S1001 for selecting a specific storage location search algorithm for a specific card type based on the fixed code within the virtual token and the step S1002 for extracting the actual card number at the found storage location”)
However, YOO does not teach “receive requests on behalf of the first card network … permanent identifier that is associated with a second card network different from the first card network … reencode the request into an envelope, using the permanent identifier instead of the virtual identifier, that is transparent to the second card network; and transmit the envelope to the second card network for processing.”.
In analogous teaching GOODMAN teaches “… reencode the request into an envelope, using the permanent identifier instead of the virtual identifier, that is transparent to the second card network, wherein the envelope is transparent to the second card network by refraining from indicating the proxy device as a source of the request, and the envelope indicates the acquiring device as the source of the request; ([GOODMAN, para. 0041] “As part of the processing of the payment transaction, the authorization request may be forwarded to the processing server 102, such as via the payment rails associated with the payment network 110. The processing server 102 may be configured to detokenize the primary account number or otherwise identify the detokenized primary account number for the transaction account and replace the tokenized primary account number with the detokenized counterpart in the first data element included in the authorization request. The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”) ([GOODMAN, para. 0050] “the authentication module 216 may be configured to verify a unique identifier included in a transaction request as corresponding to an ATM 106 at which a transaction related to the transaction request may be processed.”) ([GOODMAN, para. 0044] “The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some embodiments, the receiving device 202 may be configured to receive data from ATMs 106”) ([GOODMAN, para. 0045] “the receiving device 202 may be further configured to receive data signals electronically transmitted by the ATM 106, which may be transmitted using a communication channel separate from the payment rails, and may be superimposed or otherwise encoded with a unique identifier, such as for use in verifying the ATM 106 as one intended in a received transaction request.”) ([GOODMAN, para. 0041] “The payment network 110 may receive the authorization request from the ATM 106, or from the processing server 102 acting on behalf of the ATM 106, and may process the transaction using traditional methods and systems. … The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”) and transmit the envelope to the … card network for processing.” ([GOODMAN, para. 0053] “The transmitting device 220 may also be configured to electronically transmit transaction messages to payment networks 110 and other entities via the associated payment rails, such as may be transmitted following the swapping of a tokenized primary account number for its detokenized counterpart.”) ([GOODMAN, para. 0092] “In step 734, the acquiring financial institution 710 may electronically transmit the authorization request to a transaction processing server 712 for processing. The transaction processing server 712 may be comprised of one or more computing devices as part of a payment network configured to process payment transactions.”) ([GOODMAN, para. 0022] “Examples of networks or systems configured to perform as payment networks include those operated by MasterCard®, VISA®, Discover®, American Express®, PayPal®, etc.”)
Thus, given the teaching of GOODMAN, it would have been obvious to one of ordinary skill in the art before the effective filling date of reencode the request into an envelope, using the permanent identifier instead of the virtual identifier, that is transparent to the second card network; and transmit the envelope by GOODMAN into the teaching of system for routing requests by YOO. One of ordinary skill in the art would have been motivated to do so because GOODMAN recognizes the need to improve transactions ([GOODMAN, para. 0005] “there is a need for a technical solution whereby an ATM may be used for traditional transactions related thereto while being configured to operate entirely “cardless,” without the presentation of a payment card directly to the ATM by the individual attempting a transaction.”) ([GOODMAN, para. 0006] “The present disclosure provides a description of systems and methods for the initiation and processing of a cardless automated teller machine (ATM) transaction via a mobile computing device.”)
However, YOO-GOODMAN does not teach “receive requests on behalf of the first card network … permanent identifier that is associated with a second card network different from the first card network … and transmit the envelope to the second card network …”
In analogous teaching, O'SULLIVAN teaches “receive requests on behalf of the first card network … permanent identifier that is associated with a second card network different from the first card network … and transmit the envelope to the second card network …”([O’SULLIVAN, para. 0002] “When a cardholder tokenizes a payment card stored in an electronic wallet on a user device, a payment network may receive related provisioning data such as a first primary account number (PAN) and a first device identifier. The first PAN and the first device identifier may be stored by the payment network in a database record associated with the cardholder.”) ([O’SULLIVAN, para. 0055] “the payment network may receive a transaction record (e.g., Travel Data 150, Transaction Data 219, etc.) associated with a purchase of travel arrangements (e.g., airline ticket, bus fare, rail ticket, hotel, rental car, etc.) using the first tokenized PAN. … The payment network may then determine, based on the first mapping data, the first PAN associated with the first tokenized PAN. The payment network may also determine, based on the second mapping data, the second PAN associated with the second tokenized PAN. Based on the data element of the first data structure indicative of the first relationship identifier, the payment network may determine that the first PAN is associated with the second PAN.”) ([O’SULLIVAN, para. 0056] “Using a portion of the first PAN (e.g., the first 6 digits of the 15 or 16 digit numerical identifier), the payment network may determine that the portion of the first PAN is indicative of a first issuer identifier (e.g., a BIN) associated with a first issuer network. Using a portion of the second PAN (e.g., the first 6 digits of the 15 or 16 digit numerical identifier), the payment network may determine that the portion of the second PAN is indicative of second issuer identifier (e.g., a BIN) associated with a second issuer network. The payment network may then send the second PAN and one or more portions of the transaction record (e.g., one or more data fields, ISO transaction record fields, etc.) indicative of the transaction addenda to the second issuer network.”)
Thus, given the teaching of O'SULLIVAN, it would have been obvious to one of ordinary skill in the art before the effective filling date of permanent identifier that is associated with a second card network by O'SULLIVAN into the teaching of system for routing requests by YOO-GOODMAN. One of ordinary skill in the art would have been motivated to do so because O'SULLIVAN recognizes the need for data tokenization to safeguard sensitive data ([O'SULLIVAN, para. 0001] “data tokenization has become a popular tool for safeguarding sensitive data; however, current methods that implement data tokenization do not provide a high level of data accessibility. Thus, what is needed are systems and methods that improve data tokenization processes and mobile device data accessibility. These and other considerations are addressed by the present disclosure”) ([O'SULLIVAN, para. 0002] “Methods and systems are described herein relating to, among other things, providing cross-issuer notification of a cardholder's travel arrangements without requiring personally identifiable information. “)
Regarding claim 8, this claim recites of method claim that corresponds to system claim 1. Therefore, claim 8 is rejected in a similar manner as in the rejection of claim 1. YOO further teaches “a proxy device” ([YOO, para. 0010] “embodiment, a virtual token-based payment providing method includes receiving, by a virtual token verification means, a virtual token provided by a virtual token generation means from a payment terminal, extracting, by the virtual token verification means, a plurality of detailed codes included in the virtual token, searching, by the virtual token verification means, for the actual card number”)
Regarding claim 3, YOO-GOODMAN-O'SULLIVAN teach all limitations of claim 1. YOO further teaches “wherein the one or more processors, to map the virtual identifier to the permanent identifier, are configured to: use a data structure, stored in the one or more memories, that stores virtual identifiers in association with permanent identifiers. ([YOO, para. 0150] “step S400 for extracting the detailed code may extract the fixed code from the virtual token, may determine the card type group of the virtual token generation means based on the fixed code, and may determine the virtual token generation function or the storage location search algorithm for the card type group.”) ([YOO, para. 0153] “In S1000, the virtual token verification means 20 searches for the storage location of the actual card number based on a plurality of detailed codes (a step for searching for the actual card number). The plurality of detailed codes have the correlation between each other; the virtual token verification means 20 searches for the storage location of the actual card number based on the correlation between the detailed codes.”) ([YOO, para. 0091] “The virtual token verification means 20 may receive the unique value (e.g., the chip unique value in the smart card, the unique value of a smartphone installed in an app card, or the like) of the virtual token generation device 100 upon registering the actual card number to store the unique value in the storage location of the actual card number”)
Regarding claim 4, YOO-GOODMAN-O'SULLIVAN teach all limitations of claim 3. YOO further teaches “wherein the one or more processors are configured to: receive the data structure from an issuing device. ([YOO, para. 0121] “The actual card number search unit 230 searches for the storage location of the actual card number based on the plurality of detailed codes. Various methods may be applied such that the actual card number search unit 230 searches for the storage location of the actual card number based on each detailed code. The actual card number search unit 230 may include the correlation between detailed codes to search for a storage location based on a plurality of detailed codes.”) ([YOO, para. 0132] “receiving a virtual token provided by a virtual token generation means, by a virtual token verification means, a step S400 for extracting multiple detailed codes included in the virtual token by the virtual token verification means, a step S1000 for searching for a storage location of an actual card number on the basis of the multiple detailed codes by the virtual token verification means (a step for searching for the actual card number)”)
Regarding claims 5 and 11, YOO-GOODMAN-O'SULLIVAN teach all limitations of claims 1 and 8. GOODMAN further teaches “wherein the one or more processors, to map the virtual identifier to the permanent identifier, are configured to: identify an indicator, included in the virtual identifier, that the virtual identifier is to be detokenized; ([GOODMAN, para. 0038] “The ATM 106 may receive the transaction data, which may include the desired transaction details (e.g., without any account identifying information) and the tokenized primary account number. The ATM 106 may then initiate the transaction using traditional methods related thereto, using the tokenized primary account number in place of the traditional reading of primary account number read from a payment card presented to the ATM 106.”) ([GOODMAN, para. 0040] “the transaction message submitted by the ATM 106 may be an authorization request that includes at least a first data element configured to store the tokenized primary account number and additional data elements configured to store the additional transaction data (e.g., currency type, withdrawal amount, transaction type, transaction time, transaction date, geographic location, etc.).”) ([GOODMAN, para. 0037] “a virtual card number may be used in place of and/or in addition to a tokenized primary account number. … the mobile computing device 108 may be provisioned with a tokenized virtual card number”) transmit, to a detokenizer device, a request for the permanent identifier that indicates the virtual identifier; and receive, from the detokenizer device, a response to the request that indicates the permanent identifier. ([GOODMAN, para. 0041] “The processing server 102 may be configured to detokenize the primary account number or otherwise identify the detokenized primary account number for the transaction account and replace the tokenized primary account number with the detokenized counterpart in the first data element included in the authorization request. The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”) ([GOODMAN, para. 0045] “The receiving device 202 may also be configured to receive transaction messages from the payment network 110 for processing thereof, such as the detokenization of a primary account number stored therein.”)
The same motivation to modify YOO with GOODMAN as in the rejection of claim 1 applies.
Regarding claim 6, YOO-GOODMAN-O'SULLIVAN teach all limitations of claim 5. GOODMAN further teaches “wherein the indicator is associated with the detokenizer device from a plurality of possible detokenizer devices. ([GOODMAN, para. 0065] “The transmitting device 320 may be configured to electronically transmit data signals to processing servers 102, which may be superimposed or otherwise encoded with a transaction request. A transaction request may include at least desired transaction details, account identifying information, authentication information and/or a digital signature, and a unique identifier associated with an ATM 106.”) ([GOODMAN, para. 0041] “The processing server 102 may be configured to detokenize the primary account number or otherwise identify the detokenized primary account number for the transaction account and replace the tokenized primary account number with the detokenized counterpart in the first data element included in the authorization request. The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”)
The same motivation to modify YOO with GOODMAN as in the rejection of claim 1 applies.
Regarding claim 9, YOO-GOODMAN-O'SULLIVAN teach all limitations of claim 8. GOODMAN further teaches “wherein transmitting the detokenized request to the second card network comprises: transmitting the detokenized request to an acquiring device for delivery to the second card network. ([GOODMAN, para. 0041] “The processing server 102 may be configured to detokenize the primary account number or otherwise identify the detokenized primary account number for the transaction account and replace the tokenized primary account number with the detokenized counterpart in the first data element included in the authorization request. The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”) ([GOODMAN, para. 0044] “The receiving device 202 may also be configured to receive data over specially configured payment rails associated with the payment network 110, which may be specialized infrastructure associated therewith. In some embodiments, the receiving device 202 may be comprised of multiple devices, such as different receiving devices for receiving data over different networks, such as a first receiving device for receiving data via the payment network 110”).
The same motivation to modify YOO with GOODMAN as in the rejection of claim 1 applies.
Regarding claim 10, YOO-GOODMAN-O'SULLIVAN teach all limitations of claim 8. YOO further teaches “wherein mapping the virtual identifier to the permanent identifier comprises: applying an algorithm, by the proxy device, to convert the virtual identifier into the permanent identifier.” ([YOO, para. 0124] “for the purpose of searching for the storage location of the actual card number by using a plurality of detailed codes having the correlation, the actual card number search unit 230 may include the storage location search algorithm. The storage location search algorithm is an algorithm capable of being searching for the storage location when each detailed code included in the virtual token is applied.”) ([YOO, para. 0101] “when there is a virtual token verification means within the virtual token verification server for each card type and a single storage location search algorithm is included in the virtual token verification means) or a storage location search algorithm”)
Regarding claim 12, YOO-GOODMAN-O'SULLIVAN teach all limitations of claim 8. GOODMAN further teaches “wherein the request is received from an acquiring device, and the detokenized request indicates the acquiring device as a source.” ([GOODMAN, para. 0041] “As part of the processing of the payment transaction, the authorization request may be forwarded to the processing server 102, such as via the payment rails associated with the payment network 110. The processing server 102 may be configured to detokenize the primary account number or otherwise identify the detokenized primary account number for the transaction account and replace the tokenized primary account number with the detokenized counterpart in the first data element included in the authorization request. The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”) ([GOODMAN, para. 0050] “ the authentication module 216 may be configured to verify a unique identifier included in a transaction request as corresponding to an ATM 106 at which a transaction related to the transaction request may be processed.”) ([GOODMAN, para. 0044] “The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some embodiments, the receiving device 202 may be configured to receive data from ATMs 106”) ([GOODMAN, para. 0045] “the receiving device 202 may be further configured to receive data signals electronically transmitted by the ATM 106, which may be transmitted using a communication channel separate from the payment rails, and may be superimposed or otherwise encoded with a unique identifier, such as for use in verifying the ATM 106 as one intended in a received transaction request.”) ([GOODMAN, para. 0041] “The payment network 110 may receive the authorization request from the ATM 106, or from the processing server 102 acting on behalf of the ATM 106, and may process the transaction using traditional methods and systems. … The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”)
The same motivation to modify YOO with GOODMAN as in the rejection of claim 1 applies.
Regarding claim 13, YOO-GOODMAN-O'SULLIVAN teach all limitations of claim 8. YOO further teaches “wherein the detokenized request indicates the proxy device as a source.” ([GOODMAN, para. 0041] “The processing server 102 may be configured to detokenize the primary account number or otherwise identify the detokenized primary account number for the transaction account and replace the tokenized primary account number with the detokenized counterpart in the first data element included in the authorization request. The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”) ([GOODMAN, para. 0051] “The processing server 102 may also include a transaction processing module 218. … The transaction processing module 218 may also be configured to modify transaction messages, such as by replacing a tokenized primary account number with the detokenized counterpart prior to the forwarding of the authorization request to an issuing financial institution.”) ([GOODMAN, para. 0092] “The authorization request may be a transaction message that includes a message type indicator indicative of an authorization request, which may indicate that the merchant 706 involved in the payment transaction is requesting payment or a promise of payment from the issuing financial institution 702 for the transaction. The authorization request may include a plurality of data elements, each data element being configured to store data as set forth in the associated standards, such as for storing an account number, application cryptogram, transaction amount, issuing financial institution 702 information, etc.”)
The same motivation to modify YOO with GOODMAN as in the rejection of claim 1 applies.
Claims 14-18, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over YOO (US-20220067704-A1), in view of O'SULLIVAN (US-20200160298-A1), and further in view of GOODMAN (US-20180068297-A1), hereinafter YOO-O'SULLIVAN-GOODMAN.
Regarding claim 14, YOO teaches “A non-transitory computer-readable medium storing a set of instructions for generating a virtual identifier that …, the set of instructions comprising: ([YOO, para. 0063] “The virtual token generation means 10 generates the virtual token including information through which the virtual token verification means 20 is capable of searching for an actual card number. That is, the virtual token generation means 10 generates the virtual token depending on a virtual token generation function.”) one or more instructions that, when executed by one or more processors of a device, cause the device to: receive a request to link a virtual identifier, associated with a first card network, to a permanent identifier that is associated with a …; ([YOO, para. 0135] “the virtual token further includes the fixed code. The fixed code includes a code for determining the card issuer or the card type corresponding to the actual card number or a code for identifying whether to correspond to the virtual token. The fixed code is combined at the predetermined location within the virtual token.”) ([YOO, 0123] “Moreover, according to another embodiment, the virtual token generation means 10 (or the virtual token generation device 100) provides a new virtual token for each unit count, the virtual token verification device 200 may set the search start point and the search path based on the first code and the second code, which are changed for each count, to search for the storage location of the actual card number.”) ([YOO, para. 0150] “step S400 for extracting the detailed code may extract the fixed code from the virtual token, may determine the card type group of the virtual token generation means based on the fixed code, and may determine the virtual token generation function or the storage location search algorithm for the card type group.”) generate a data structure that stores the virtual identifier in association with the permanent identifier; … ([YOO, para. 0077] “The virtual token generation unit 120 may generate the virtual token by combining one or more detailed codes. According to an embodiment, the virtual token may be generated by combining a plurality of detailed codes depending on a specific rule. The virtual token generation function includes the rule (i.e., the detailed code combining function) that combines a plurality of detailed codes.”) ([YOO, para. 0081] “the virtual token may include the unchanged fixed code for distinguishing groups, together with a plurality of detailed codes.”) ([YOO, para. 0121] “The actual card number search unit 230 searches for the storage location of the actual card number based on the plurality of detailed codes. Various methods may be applied such that the actual card number search unit 230 searches for the storage location of the actual card number based on each detailed code.”) ([YOO, para. 0023] “The virtual token generation function corresponds to a storage location search algorithm where the actual card number is stored in the virtual token verification means. The storage location search algorithm moves a storage location of the actual card number to a location corresponding to a plurality of detailed codes of a specific count or searches for a fixed storage location of the actual card number by the plurality of detailed codes of the specific count.”)
However, YOO does not teach “identifier that routes across card networks … permanent identifier that is associated with a second card network different from the first card network … and transmit the data structure to a detokenizer device associated with a proxy device of the first card network; wherein the data structure enables the proxy device to route a request to authorize an event, from an acquiring device, from the first card network to the second card network for processing using the permanent identifier and identifying the acquiring device, to the second card network, as a source of the request instead of the proxy device.”
In analogous teaching O’SULLIVAN teaches “identifier that routes across card networks … permanent identifier that is associated with a second card network different from the first card network … ([O’SULLIVAN, para. 0055] “the payment network may receive a transaction record (e.g., Travel Data 150, Transaction Data 219, etc.) associated with a purchase of travel arrangements (e.g., airline ticket, bus fare, rail ticket, hotel, rental car, etc.) using the first tokenized PAN. … The payment network may then determine, based on the first mapping data, the first PAN associated with the first tokenized PAN. The payment network may also determine, based on the second mapping data, the second PAN associated with the second tokenized PAN. Based on the data element of the first data structure indicative of the first relationship identifier, the payment network may determine that the first PAN is associated with the second PAN.”) ([O’SULLIVAN, para. 0056] “Using a portion of the first PAN (e.g., the first 6 digits of the 15 or 16 digit numerical identifier), the payment network may determine that the portion of the first PAN is indicative of a first issuer identifier (e.g., a BIN) associated with a first issuer network. Using a portion of the second PAN (e.g., the first 6 digits of the 15 or 16 digit numerical identifier), the payment network may determine that the portion of the second PAN is indicative of second issuer identifier (e.g., a BIN) associated with a second issuer network. The payment network may then send the second PAN and one or more portions of the transaction record (e.g., one or more data fields, ISO transaction record fields, etc.) indicative of the transaction addenda to the second issuer network.”) … and transmit the data structure to a detokenizer device associated with a proxy device of the first card network.” ([O'SULLIVAN, para. 0030] “The PAN and all associated information that is tokenized may be referred to herein as “the tokenized PAN” or simply “the token,” and the identifier for the mobile device or other computing device the individual uses during the tokenization process may be referred to as a “device identifier.” Data indicating an association of the token to the PAN and the device identifier may be held in a “Token Vault,”) ([O'SULLIVAN, para. 0036] “The payment network may store the provisioning data 112 in a secure repository such as Token Vault 114. The provisioning data for the first PAN 104 may be associated with a first token (e.g., token number, token identifier, etc.).”) ([O'SULLIVAN, para. 0036] “The Token Vault 224 may detokenize the Tokenized PAN 208A by using the first mapping data stored in Data Structure 226 to determine a value of the first PAN (e.g., a 15 or 16 digit numerical identifier). The Token Vault 224 may then determine that Data Structure 226 contains a reference to Data Structure 228. The Token Vault 224 may detokenize the Tokenized PAN 208B by using the second mapping data stored in Data Structure 228 to determine a value of the second PAN”)
Thus, given the teaching of O'SULLIVAN, it would have been obvious to one of ordinary skill in the art before the effective filling date of permanent identifier that is associated with a second card network by O'SULLIVAN into the teaching instructions for generating a virtual identifier by YOO. One of ordinary skill in the art would have been motivated to do so because O'SULLIVAN recognizes the need for data tokenization to safeguard sensitive data ([O'SULLIVAN, para. 0001] “data tokenization has become a popular tool for safeguarding sensitive data; however, current methods that implement data tokenization do not provide a high level of data accessibility. Thus, what is needed are systems and methods that improve data tokenization processes and mobile device data accessibility. These and other considerations are addressed by the present disclosure”) ([O'SULLIVAN, para. 0002] “Methods and systems are described herein relating to, among other things, providing cross-issuer notification of a cardholder's travel arrangements without requiring personally identifiable information. “)
In analogous teaching GOODMAN teaches “wherein the data structure enables the proxy device to route a request to authorize an event, from an acquiring device, from the first card network to the second card network for processing using the permanent identifier and identifying the acquiring device, to the second card network, as a source of the request instead of the proxy device.” ([GOODMAN, para. 0041] “As part of the processing of the payment transaction, the authorization request may be forwarded to the processing server 102, such as via the payment rails associated with the payment network 110. The processing server 102 may be configured to detokenize the primary account number or otherwise identify the detokenized primary account number for the transaction account and replace the tokenized primary account number with the detokenized counterpart in the first data element included in the authorization request. The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”) ([GOODMAN, para. 0050] “the authentication module 216 may be configured to verify a unique identifier included in a transaction request as corresponding to an ATM 106 at which a transaction related to the transaction request may be processed.”) ([GOODMAN, para. 0044] “The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some embodiments, the receiving device 202 may be configured to receive data from ATMs 106”) ([GOODMAN, para. 0045] “the receiving device 202 may be further configured to receive data signals electronically transmitted by the ATM 106, which may be transmitted using a communication channel separate from the payment rails, and may be superimposed or otherwise encoded with a unique identifier, such as for use in verifying the ATM 106 as one intended in a received transaction request.”) ([GOODMAN, para. 0041] “The payment network 110 may receive the authorization request from the ATM 106, or from the processing server 102 acting on behalf of the ATM 106, and may process the transaction using traditional methods and systems. … The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”) ([GOODMAN, para. 0022] “Examples of networks or systems configured to perform as payment networks include those operated by MasterCard®, VISA®, Discover®, American Express®, PayPal®, etc.”)
Thus, given the teaching of GOODMAN, it would have been obvious to one of ordinary skill in the art before the effective filling date of reencode the request into an envelope, using the permanent identifier instead of the virtual identifier, that is transparent to the second card network; and transmit the envelope by GOODMAN into the teaching of system for routing requests by YOO-O'SULLIVAN. One of ordinary skill in the art would have been motivated to do so because GOODMAN recognizes the need to improve transactions ([GOODMAN, para. 0005] “there is a need for a technical solution whereby an ATM may be used for traditional transactions related thereto while being configured to operate entirely “cardless,” without the presentation of a payment card directly to the ATM by the individual attempting a transaction.”) ([GOODMAN, para. 0006] “The present disclosure provides a description of systems and methods for the initiation and processing of a cardless automated teller machine (ATM) transaction via a mobile computing device.”)
Regarding claim 15 YOO-O'SULLIVAN-GOODMAN teach all limitations of claim 14. O'SULLIVAN further teaches “wherein the detokenizer device is at least partially integrated with the proxy device. ([O'SULLIVAN, para. 0030] “The Token Vault may store the token (e.g., a token identifier for the tokenized PAN) as well as the PAN and the device identifier in a data structure within the Token Vault.”) ([O'SULLIVAN, para. 0031] “The Token Vault may be maintained by a token service provider (e.g., a payment network, an issuer network associated with the tokenized PAN, a third party service provider, or the like).”) ([O'SULLIVAN, para. 0049] “The Token Vault 224 may detokenize the Tokenized PAN 208A by using the first mapping data stored in Data Structure 226”) ([O'SULLIVAN, para. 0040] “The Token Vault 114 may then send the first PAN 104 stored in the first data structure 104A to the payment network 160”) ([O'SULLIVAN, para. 0041] “The payment network 160 may then send the debit PAN 104 and the travel data 150 (e.g., the one or more travel dates as well as the one or more travel locations associated with the travel arrangements) to debit issuer network 168.”)
The same motivation to modify YOO with O'SULLIVAN as in the rejection of claim 1 applies.
Regarding claim 16, YOO-O'SULLIVAN-GOODMAN teach all limitations of claim 14. GOODMAN further teaches “wherein the one or more instructions, when executed by the one or more processors, cause the device to: transmit, to the proxy device, an indication that the data structure was sent to the detokenizer device. ([GOODMAN, para. 0038] “The ATM 106 may receive the transaction data, which may include the desired transaction details (e.g., without any account identifying information) and the tokenized primary account number. The ATM 106 may then initiate the transaction using traditional methods related thereto, using the tokenized primary account number in place of the traditional reading of primary account number read from a payment card presented to the ATM 106.”). ([GOODMAN, para. 0041] “The processing server 102 may be configured to detokenize the primary account number or otherwise identify the detokenized primary account number for the transaction account and replace the tokenized primary account number with the detokenized counterpart in the first data element included in the authorization request. The authorization request may then be forwarded (e.g., by the processing server 102 or the payment network 110) to the issuing financial institution associated with the transaction account for authorization thereby.”).
The same motivation to modify YOO-O'SULLIVAN with GOODMAN as seen in the rejection of claim 14 applies.
Regarding claim 17, YOO-O'SULLIVAN-GOODMAN teach all limitations of claim 14. YOO further teaches “wherein the one or more instructions, that cause the device to receive the request to link the virtual identifier to the permanent identifier, cause the device to: receive the request from a user device. ([YOO, para. 0017] “Furthermore, according to another embodiment, the receiving of the virtual token includes receiving, by the virtual token verification means, the virtual token from the payment settlement service server as a virtual token payment is selected in the payment terminal by the user in a store by the virtual token”) ([YOO, para. 0020] “generating, by the virtual token generation means, a plurality of detailed codes matched with the payment request time point without performing communication with the virtual token verification means at a payment request time point of a user, generating, by the virtual token generation means, a virtual token by combining the plurality of detailed codes, and outputting, by the virtual token generation means, the virtual token to an outside to provide the virtual token to a virtual token verification server. The virtual token generation function corresponds to a storage location search algorithm in which the actual card number is stored”)
Regarding claim 18, YOO-O'SULLIVAN-GOODMAN teach all limitations of claim 17. GOODMAN further teaches “wherein the one or more instructions, when executed by the one or more processors, cause the device to: receive, from the user device, a set of credentials, wherein the request is received based on verifying the set of credentials. ([GOODMAN, para. 0033] “The processing server 102 may receive the data from the mobile computing device 108, and may perform any necessary authentication or verification. Authentication may include authenticating any authentication data provided by the consumer 104 or verifying a digital signature provided as proof of authentication performed by the mobile computing device 108, as well as verification of the unique identifier associated with the ATM 106 that is to be used in the transaction.”) ([GOODMAN, para. 0027] “the processing server 102 may be configured to tokenize primary account numbers and other account identifiers (e.g., bank account numbers) for use in performing the functions discussed herein”)
The same motivation to modify YOO-O'SULLIVAN with GOODMAN as in the rejection of claim 14 applies.
Regarding claim 21, YOO-O'SULLIVAN-GOODMAN teach all limitations of claim 14. YOO further teaches “wherein the virtual identifier is generated using pseudo-random number generation or algorithmic modification of the permanent identifier” ([YOO, para. 0085] “the virtual token generation device 100 may generate the detailed code so as to be the code of the same digits as the actual card number by combining a plurality of detailed codes and the fixed code. The virtual token generation device 100 needs to generate a code having the same digits as the actual card number as the virtual token, for the purpose of using the virtual token while the conventional financial transaction system (e.g., when the payment is made in a store, a POS device and a VAN server) is maintained as it is. To this end, the virtual token generation device 100 utilizes the digits of a plurality of detailed codes by dividing digits other than the fixed code for determining the card issuer and the card type of the corresponding card issuer. For example, when the actual card number has the card identification number of 16 digits and includes the first code and the second code as the detailed code, the virtual token generation device 100 may generate the first code and the second code, each of which has 5 digits, by identically dividing 10 digits other than the fixed code of 6 digits among 16 digits. Afterward, the virtual token generation unit to be described later may combine the first code and the second code depending on the specific rule and then may combine the fixed code with the front portion of the card identification number of the actual card number to generate the card identification number of the virtual token.”)
Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over YOO-O'SULLIVAN-GOODMAN in view of SETHI (US-20200356986-A1).
Regarding claim 19, YOO-O'SULLIVAN-GOODMAN teach all limitations of claim 14. However, YOO-O'SULLIVAN-GOODMAN does not teach “wherein the one or more instructions, when executed by the one or more processors, cause the device to: validate the permanent identifier, wherein the data structure is generated in response to validating the permanent identifier.”
In analogous teaching SEHTI teaches “validate the permanent identifier, wherein the data structure is generated in response to validating the permanent identifier. ([SETHI, para. 0017] “Once the payment account number has been entered at 120, the digital wallet provider 104 may establish an account for the consumer 102. In one embodiment, the digital wallet provider 104 may send the information to the payment exchange 106 for verification at 124. As part of the verification, the digital wallet provider 104 may transmit information or data to the payment exchange 106 so that the payment exchange 106 may populate the received information into a data structure 400, to be described below. In one embodiment, the payment exchange 106 may generate a virtual account number as part of the verification. Once the data structure 400 creation has completed, the payment exchange 106 may transmit a confirmation back to the digital wallet provider 104 at 124, and the digital wallet provider 104 may confirm with the consumer 102 at 126 that the account and the payment account number has been added to the account.”)
Thus, given the teaching of SETHI, it would have been obvious to one of ordinary skill in the art before the effective filling date of transmit, to a user device, a confirmation by SETHI into the teaching of system for routing requests by YOO-O'SULLIVAN-GOODMAN. One of ordinary skill in the art would have been motivated to do so because SETHI recognizes the benefits of virtual account number ([SETHI, para. 0006] “The virtual account number created by embodiments of the invention further enable security features that prevent fraud and protect the consumer's financial assets.”)
Regarding claim 20, YOO-O'SULLIVAN-GOODMAN teach all limitations of claim 14. However, YOO-O'SULLIVAN-GOODMAN does not teach “wherein the one or more instructions, when executed by the one or more processors, cause the device to: transmit, to a user device, a confirmation that the virtual identifier was linked to the permanent identifier.”
In analogous teaching SETHI teaches “wherein the one or more instructions, when executed by the one or more processors, cause the device to: transmit, to a user device, a confirmation that the virtual identifier was linked to the permanent identifier. ([SETHI, 0028] “Once the consumer 102 completes the request at 130 in FIG. 1B, the first digital wallet provider 114 may transmit the request to the payment gateway 106 at 132. The payment gateway 106 may match the virtual account number with the actual payment account number … Once the second digital wallet provider 118 verifies the recipient having an account with the second digital wallet provider 118, the second digital wallet provider 118 may send a confirmation to the payment gateway 106 at 136. The payment gateway 106 may forward the confirmation to the first digital wallet provider 114 at 138 before the consumer 102 may receive the confirmation at 140.”)
The same motivation to combine YOO-O'SULLIVAN-GOODMAN with SETHI as in the rejection of claim 19 applies.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over YOO-O'SULLIVAN-GOODMAN in view of CARLSON (US-9639714-B1).
Regarding claim 22, YOO-O'SULLIVAN-GOODMAN teach all limitations of claim 14. However, YOO-O'SULLIVAN-GOODMAN does not teach “wherein the data structure includes an encrypted version of the permanent identifier.”.
In analogous teaching CARLSON teaches “wherein the data structure includes an encrypted version of the permanent identifier.” (CARLSON, col. 4 Lines 1-4] “transmitting encoded information corresponding to the credit card number to a payment provider (or storing the encoded information in a local database, etc.).”)
Thus, given the teaching of CARLSON, it would have been obvious to one of ordinary skill in the art before the effective filling date to store encrypted permanent identifiers by SETHI into the teaching of system for routing requests by YOO-O'SULLIVAN-GOODMAN. One of ordinary skill in the art would have been motivated to do so because CARLSON recognizes the need to improve prevention of unauthorized access ([CARLSON, col 1 lines 24-26] “Currently, many different encoding techniques are designed to prevent unauthorized access to communicated and/or stored data. However, these techniques are associated with various drawbacks”) ([CARLSON, col 1 lines 43-48] “a method of providing secure communication of a data string along a communication path including a plurality of devices is implemented in a server that includes one or more processors and a memory storing a registry database. The method includes adding to the registry database a first entity and a first identifier associated with the first entity”)
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
MAHAJAN (US-11489825-B2): This prior art teaches of a device may determine that a network function of a network is to use a secure communication protocol. The network function may be configured to facilitate communication via the network. The device may identify a component of a resource configuration that is to instantiate the network function. The device may instantiate, using the component, a proxy for the network function. The device may configure the proxy to obtain a certificate that is associated with the secure communication protocol. The device may cause the proxy to use the certificate to communicate with another proxy that is associated with the network function to perform an operation associated with the network function.
ATHLUR (US-20200220863-A1): This prior art teaches of a server for detecting a proxy device in a communications path may include a processor and a memory associated therewith. The processor may obtain an encrypted first portion of an encryption key from the client device. The encryption key may be based upon user-input credentials for a given user. The processor may also communicate an encrypted second portion of the encryption key to the client device based upon determining that the encrypted first portion matches a corresponding first portion of the encryption key indicative of an absence of the proxy device in the communications path. The processor may also detect a loss in connectivity between the server and the client device in response to the client device determining that the decrypted second portion of the encryption key does not match a corresponding second portion of the encryption key indicative of a proxy device in the communications path.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AFAQ ALI whose telephone number is (571)272-1571. The examiner can normally be reached Mon - Fri 7:30am - 5:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ALI SHAYANFAR can be reached at (571) 270-1050. 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.
/A.A./
07/30/2026
/AFAQ ALI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights