DETAILED ACTION
This is first office action on the merits in response to the application filed on 01/05/2026.
Claims 1-20 have been filed by the applicant.
Claims 1-20 are currently pending and have been examined.
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-8 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The broadest reasonable interpretation of a claim drawn to a computer readable media typically covers form of non-transitory tangible medial and transitory propagating signal per se in when specification is silent. See MPEP 2111.01. When the broadest reasonable interpretation of claim covers a signal per se, the claim must be rejected under 35 U.S.C. 101 as covering non-statutory subject matter. See In re Nuijted, 500 F.3d 1346, 1356-57 (Fed cir 2007) (transitory embodiments are not directed to statutory subject matter) and Interim Examination Instructions for Evaluating Subject Matter Eligibility Under 35 U.S.C 101, Aug 24, 2009; p. 2. 7. Applicant advised to amend the claim reciting "non-transitory computer readable media” to overcome rejection under 35 U.S.C. 101.
In the instant case, claims 9-16 are directed to a system comprising a memory and a processor, claims 17-20 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
The limitations of independent claim 1, which is representative of independent claims 9 and 17, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 1 are identified in bold below:
One or more computer-readable storage media having instructions stored thereon that when executed by a processing system, direct the processing system to:
receive, from a sender, a P2P transfer request comprising at least a receiver token PAN corresponding to a receiver account of a receiver;
obtain a sender token PAN corresponding to a sender account of the sender;
communicate, to an enhanced processing platform, a P2P transfer advice request comprising at least the sender token PAN and the receiver token PAN;
receive, from the enhanced processing platform, an account authorization message comprising at least a sender account number corresponding to the sender account and a receiver account number corresponding to the receiver account; and
provide, to a receiver account holding institution (AHI) system via a payment network, funds to be transferred from the sender account associated with the sender account number to the receiver account associated with the receiver account number
Limitations B-C and F under the broadest reasonable interpretation covers steps or functions that are making transaction. Other than reciting generic computer hardware in limitation A and D-F, nothing in the claim element differentiates the limitation from making transaction. Therefore, limitations B-C and F recite an abstract idea, as highlighted above, that is consistent with the commercial interactions aspects of certain methods of organizing human activities.
Furthermore, limitation D-F recites process of detokenization which is mitigating risks. Therefore, recites an economics interactions aspect of the “certain methods of organizing human activity” grouping of abstract ideas.
Accordingly, claim 1, and by analogy similar claims 9 and 17, recite at least two abstract ideas and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular, claim 1 recites the additional elements in bold below:
One or more computer-readable storage media having instructions stored thereon that when executed by a processing system, direct the processing system to:
receive, from a sender, a P2P transfer request comprising at least a receiver token PAN corresponding to a receiver account of a receiver;
obtain a sender token PAN corresponding to a sender account of the sender;
communicate, to an enhanced processing platform, a P2P transfer advice request comprising at least the sender token PAN and the receiver token PAN;
receive, from the enhanced processing platform, an account authorization message comprising at least a sender account number corresponding to the sender account and a receiver account number corresponding to the receiver account; and
provide, to a receiver account holding institution (AHI) system via a payment network, funds to be transferred from the sender account associated with the sender account number to the receiver account associated with the receiver account number
The additional element(s) in limitation A are recited at a high level of generality (e.g., consistent. The “platform” and “network” elements of limitations D-F merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment defined by high level recitations of a computer and the Internet. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than generally link the abstract idea to a technological environment through “instructions” performed by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer. This is not enough to provide an inventive concept. Therefore, claims 1, 9, and 17 are not patent eligible.
Dependent claims 2, 10 and 18 further recite the receiver token PAN in the P2P request is in a form of QR code which merely describes the data itself and does not integrate the abstract idea to a practical application nor provide significantly more than the abstract idea. The additional element of QR code generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 3, 11 and 19 further recites the sender token PAN does not contain PII which merely describes the data itself and does not integrate the abstract idea to a practical application nor provide significantly more than the abstract idea. The claim does not recite additional elements that integrate the abstract idea to a practical application nor provide significantly more than the abstract idea.
Dependent claims 4, 12 and 20 further recites identifying sender token PAN which further recites the abstract idea of commercial interactions. The claim does not recite additional elements that integrate the abstract idea to a practical application nor provide significantly more than the abstract idea.
Dependent claims 5 and 13 further recites the P2P request comprises the sender token PAN which further recites the abstract idea of commercial interactions. The claim does not recite additional elements that integrate the abstract idea to a practical application nor provide significantly more than the abstract idea.
Dependent claims 6 and 14 further recites translating token PAN, which is detokenization, further recites the abstract idea of mitigating risks. The claim does not recite additional elements that integrate the abstract idea to a practical application nor provide significantly more than the abstract idea.
Dependent claims 7 and 15 further recites authorizing fund transfer from sender account to receiver account which further recites the abstract idea of commercial interactions. The claim does not recite additional elements that integrate the abstract idea to a practical application nor provide significantly more than the abstract idea.
Dependent claims 8 and 16 further the sender initiated the P2P request which further recites the abstract idea of commercial interactions. The element of “PII secure P2P payment” merely describes the type of the request but does not integrate the abstract idea to a practical application nor provide significantly more than the abstract idea. The claim does not recite additional elements that integrate the abstract idea to a practical application nor provide significantly more than the abstract idea.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lavender (US 20170272253 A1), and further in view of Kumnick (US 20150319158 A1).
With respect to claim 1, 9 and 17:
Lavender teaches (in italic):
receive, from a sender, a P2P transfer request comprising at least a receiver token PAN corresponding to a receiver account of a receiver; obtain a sender token PAN corresponding to a sender account of the sender. (Peer-to-peer transactions allow individuals to directly exchange information and value. Peer-to-peer transactions can be enabled by intermediary applications, such as a digital wallet provider. A “token” may be a substitute value for a credential. At step S506, the coordination application may cause the sender device 510 to send a payment instruction and associated cryptogram to the coordination computer 515 (which may be a computer that provides digital wallet services). The payment instruction can include the sender token, the amount, the receiver-identifying information (e.g., an alias, contact information, a token, a wallet identifier, or a device identifier), and/or any other suitable information. [0002 0044-0045 0113])
provide, to a receiver account holding institution (AHI) system via a payment network, funds to be transferred from the sender account associated with the sender account number to the receiver account associated with the receiver account number. (At step S518, the coordination computer 515 may send the transfer instruction to the interaction processing computer 550. At step S522, the interaction processing computer 550 may de-tokenize the sender's payment token and/or the receiver's payment token. The interaction processing computer 550 can identify a set of sender payment credentials (e.g., a payment account number) associated with the sender's payment token. The interaction processing computer 550 can similarly obtain a set of receiver payment credentials associated with the receiver's payment token. the interaction processing computer 550 may coordinate the transfer of funds from the sender's account at the sending institution computer 560 to the receiver's account at the receiving instituting computer 530. [0122 0128 0129])
Lavender does not explicitly teach the following limitations. However,
Kumnick teaches:
communicate, to an enhanced processing platform, a P2P transfer advice request comprising at least the sender token PAN and the receiver token PAN. (At step S630, the transaction processing network 140 may determine that a payment token is included in the authorization request message. The transaction processing network 140 may send a de-tokenization request to the token vault 110, the de-tokenization request including the payment token, the token code, the domain ID, and/or any other suitable information. [0132])
receive, from the enhanced processing platform, an account authorization message comprising at least a sender account number corresponding to the sender account and a receiver account number corresponding to the receiver account. (The token vault 110 may confirm that the mobile device 315 is authorized to use the payment token. At step S634, the token vault 110 may identify the payment credentials (e.g., the PAN) that are associated with the payment token in the token database 110C (e.g., via the de-tokenization module 110G). At step S636, the token vault 110 may send a de-tokenization response to the transaction processing network 140, the de-tokenization response including the payment credentials. [0133-0135])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lavender to detokenize the token to get PAN with the technique as disclosed by Kumnick to enhance transaction efficiency, improve transaction security, increase service transparency as Kumnick suggested [0030].
Claim 9, a system with the same scope as claim 1, is rejected.
Claim 17, a method with the same scope as claim 1, is rejected.
With respect to claim 2, 10 and 18:
Kumnick further teaches wherein the receiver token PAN received in the P2P transfer request is received in a form of a QR code. (In one example, the digital wallet application 315F may generate single data element such as an NFC transmission packet or a QR code including the token 315N, the token code 315Q, and the domain ID 315P, and any other suitable information. [0076])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lavender to utilizing QR code with the technique as disclosed by Kumnick to enhance transaction efficiency, improve transaction security, increase service transparency as Kumnick suggested [0030].
Claim 10, a system with the same scope as claim 2, is rejected.
Claim 18, a method with the same scope as claim 2, is rejected.
With respect to claim 3, 11 and 19:
Lavender further teaches wherein the sender token PAN and the receiver token PAN do not contain personally identifiable information. (A “payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN). For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” [0045])
Claim 11, a system with the same scope as claim 3, is rejected.
Claim 19, a method with the same scope as claim 3, is rejected.
With respect to claim 4, 12 and 20:
Lavender further teaches wherein the instructions to obtain the sender token PAN further direct the processing system to: identify the sender token PAN corresponding to a sender identifier received in the P2P transfer request. (The payment instruction can include the sender token, the amount, the receiver-identifying information (e.g., an alias, contact information, a token, a wallet identifier, or a device identifier), and/or any other suitable information. [0113])
Claim 12, a system with the same scope as claim 4, is rejected.
Claim 20, a method with the same scope as claim 4, is rejected.
With respect to claim 5 and 13:
Lavender further teaches wherein the P2P transfer request further comprises the sender token PAN. (The payment instruction can include the sender token, the amount, the receiver-identifying information (e.g., an alias, contact information, a token, a wallet identifier, or a device identifier), and/or any other suitable information. [0113])
Claim 13, a system with the same scope as claim 5, is rejected.
With respect to claim 6 and 14:
Kumnick further teaches wherein the P2P transfer advice request is a request to translate the sender token PAN into the corresponding sender account number and the receiver token PAN into the corresponding receiver account number. (At step S630, the transaction processing network 140 may determine that a payment token is included in the authorization request message. The transaction processing network 140 may send a de-tokenization request to the token vault 110, the de-tokenization request including the payment token, the token code, the domain ID, and/or any other suitable information. [0132])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lavender to convert token to PAN with the technique as disclosed by Kumnick to enhance transaction efficiency, improve transaction security, increase service transparency as Kumnick suggested [0030].
Claim 14, a system with the same scope as claim 6, is rejected.
With respect to claim 7 and 15:
Lavender further teaches wherein the account authorization message authorizes funds to be transferred from the sender account associated with the sender account number to the receiver account associated with the receiver account number. (The interaction processing computer 550 can identify a set of sender payment credentials (e.g., a payment account number) associated with the sender's payment token. The interaction processing computer 550 can similarly obtain a set of receiver payment credentials associated with the receiver's payment token. the interaction processing computer 550 may coordinate the transfer of funds from the sender's account at the sending institution computer 560 to the receiver's account at the receiving instituting computer 530. [0122 0128 0129])
Claim 15, a system with the same scope as claim 7, is rejected.
With respect to claim 8 and 16:
Lavender further teaches wherein the P2P transfer request is a request for a sender-initiated (Push) PII secure P2P payment. (At step S506, the coordination application may cause the sender device 510 to send a payment instruction and associated cryptogram to the coordination computer 515 (which may be a computer that provides digital wallet services). The payment instruction can include the sender token, the amount, the receiver-identifying information (e.g., an alias, contact information, a token, a wallet identifier, or a device identifier), and/or any other suitable information. [0113])
Claim 16, a system with the same scope as claim 8, is rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20120259782 A1: Embodiments of the present invention are directed generally to systems, methods, and apparatuses for authenticating a cardholder using multiple tokenization authentication. Embodiments of the invention are directed at a method. The method includes receiving at a first entity a first token from a consumer and determining a second token associated with the first token. Once the second token is determined, the second token is sent to a server computer at a second entity. The server computer then determines an account identifier associated with the second token and processes a transaction using the account identifier.
US 20150032627 A1: A network token system provides a platform that can be leveraged by external entities (e.g., third party wallets, e-commerce merchants, payment enablers/payment service providers, etc.) or internal payment processing network systems that have the need to use the tokens to facilitate payment transactions. A token registry vault can provide interfaces for various token requestors (e.g., mobile device, issuers, merchants, mobile wallet providers, etc.), merchants, acquirers, issuers, and payment processing network systems to request generation, use and management of tokens. The network token system further provides services such as card registration, token generation, token issuance, token authentication and activation, token exchange, and token life-cycle management.
US 20160321652 A1: Embodiments are directed to systems and methods for performing consumer authentication in a tokenized transaction. The token in the authentication request may be resolved to corresponding credentials before the consumer authentication process is initiated.
US 20240281777 A1: Systems, methods, and computer-readable storage media for performing a peer-to-peer (P2P) transfer by a third-party, where a method includes receiving transfer information and a first token including sender information of a sender and a second token including receiver information of a receiver, processing the first token and the second token, transmitting a request for a guarantee, receiving an issued guarantee, transferring funds, and transmitting a transfer confirmation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 8:30-5 M-F.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/Z.X./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights