DETAILED ACTION
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 .
This office action is in response to the applicant’s amendment received on September 23, 2025 (“Amendment”).
Claim Status
Claim 1 has been amended.
Claim 16 has been canceled.
Claims 5-13 are withdrawn.
Claims 1-15 and 17-19 are pending.
Claim Objection
Per claims 1 and 3, the recited “the financial institution” should be changed to “the issuing financial institution” to avoid any confusion related to antecedent basis issue.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-4, 14-15, and 17-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Per claim 1, the claim recites in part “generating, by the token provider, the payment token by issuing the limited-use payment token from a pool of available payment tokens”. While the specification discloses generating of the payment token and maintaining/storing a mapping of the payment token to the primary account number (see at least [0003], [0004], [0008], [0012], [0033], [0038]), there is no support that the payment token is generated by issuing the limited-use payment token from a pool of available payment tokens. The specification merely mentions pool of payment tokens in paragraph [0030] that recites “In embodiments, once expired, the payment tokens may be returned to a pool of payment tokens, and may be reused at a later time”. The reuse of the token is not equivalent to generating the payment token by issuing the limited-use payment token from a pool of available payment tokens since the “generating” suggests that the payment token is not in existence.
The dependent claims are rejected as they depend on claim 1.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-4, 14-15, and 17-19 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.
Per claim 1, the claim recites “generating, by the token provider, the payment token …” Here, the scope of the claim is unclear as it is unclear which one of the previous recited payment token refer to “the payment token” that is generated, i.e., the payment tokens recited in preamble or the limited-use payment token previously recited.
Claims 3, 14, 15, 17, and 18 also recite “the payment token”. As such, the claims are rejected as it is unclear as to which one of the previously recited payment tokens refer to “the payment token”.
The dependent claims are rejected as they depend on claim 1.
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-4, 14-15, and 17-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does not fall within at least one of the four categories of patent eligible subject matter because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
MPEP 2106 provides step(s) in determining eligibility under 35 U.S.C. § 101. Specifically, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any additional elements in the claim must integrate the judicial exception into a practical application. If not, the inquiry continues to see whether any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself. Examples of abstract ideas include mathematical concepts, mental processes, and certain methods of organizing human activities.
Under Step 1, claims 1-4 and 14-19 are directed to a method (i.e. process). Thus, the claimed inventions are directed towards one of the four statutory categories under 35 USC § 101. Nevertheless, the claims also fall within the judicial exception of an abstract idea without significantly more.
Step 2A, 1st prong:
Claim 1 recites: A method for use and management of issuer provided payment tokens, comprising:
receiving, at an issuing financial institution computer program executed by a backend for an issuing financial institution, a request for a limited-use payment token for a primary account number (PAN) with the issuing financial institution from a token requestor computer program, wherein the request comprises the PAN;
requesting, by the issuing financial institution computer program, the limited-use payment token for the PAN from a token provider;
generating, by the token provider, the payment token by issuing the limited-use payment token from a pool of available payment tokens, wherein the limited-use payment token is limited to use with a merchant;
storing, by the token provider, a mapping of the PAN to the limited-use payment token in a token provider token vault;
receiving, by the issuing financial institution computer program and from the token provider, the limited-use payment token;
storing, by the issuing financial institution computer program, the mapping of the PAN to the limited-use payment token in an issuing financial institution token vault;
providing, by the issuing financial institution computer program, the limited-use payment token to the token requestor computer program;
receiving, by the financial institution computer program, the limited-use payment token and a transaction; and
executing, by the financial institution computer program, the transaction in response to the transaction involving the merchant with which the limited-use payment token is limited.
(Emphasis added on the additional element(s))
The claim recites a process of receiving at an issuing financial institution a request for a limited-use payment token, i.e., substitution/proxy account number that expires, from a requestor, for a primary account number from a token requestor; requesting by the issuing financial institution the limited payment token for the PAN from a token provider; generating by the token provider, the payment token by issuing the limited-use payment token from a pool of available payment tokens, wherein the limited-use payment token is limited to use with a merchant; storing by the token provider a mapping of the PAN to the limited-use payment token; receiving by the issuing financial institution the limited-use payment token from the token provider; storing by the issuing financial institution the mapping of the PAN to the limited-use payment token, providing by the issuing financial institution the limited-use payment token to the requestor; receiving by the issuing financial institution the limited-use payment token and a transaction; and executing by the financial institution the transaction in response to the transaction involving the merchant with which the limited-use payment token is limited. As such, the claim recites a certain method of organizing human activity (i.e., commercial/financial interaction regarding limited-use substitute account, i.e., substitute/proxy account that expires, provision and its use in a transaction) using a third party in generation of substitute/proxy account. Hence, the claim recites abstract idea.
Under the Step 2A (prong 2), this judicial exception is not integrated into a practical application. Specifically, the additional elements in the claim(s), i.e., computer program executed by a backend, computer program(s), and token vault(s), are recited at a high-level generality such that it amounts to no more than mere instructions to implement the abstract idea as described above in the Step 2A (prong 1), and/or merely uses a computer (i.e., backend computer and programs) as a tool to perform an abstract idea – see MPEP 2106.05(f). These limitation, e.g. abstract idea as described above, do not represent: Improvements to the functioning of device(s) or the components of the device(s) individually or in combination or to any other technology or technical field - see MPEP 2106.05(a).
Under Step 2B, examiners should evaluate additional elements individually and in combination to determine whether they provide an inventive concept (i.e. whether the additional elements amount to significantly more than the exception itself). Here, the claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Specifically, the claims as a whole, taken individually and in combination, do not provide an inventive concept. As explained above with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea on a computer, and/or merely uses a computer as a tool to perform an abstract idea. Mere instructions to implement the abstract idea on a computer, or merely using the computer as a tool to perform an abstract idea to apply the exception using a generic computer component cannot provide an inventive concept. Looking at the limitations as a combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of the elements improves the functioning of the recited financial institution computer program executed by a backend, computer programs, and token vaults individually or in combination.
For these reasons, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Dependent claims 2-4, 14-15, and 17-19 recite further abstract idea. The additional element of merchant computer program (claim 2), a payment network (claim 4), and mobile electronic wallet (claim 19) are recited at high level generality amount no more than mere instructions to implement the abstract idea as described above in the Step 2A (prong 1), and/or merely uses a computer as a tool to perform an abstract idea.
Accordingly, it is determined that claims 1-4, 14-15, and 17-19 are directed to non-statutory subject matter under 35 U.S.C. § 101 and are ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-4 and 14-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Publication No. 2016/0125396 (“Brickell”) in view of US Patent Publication No. 2015/0032627 (“Dill”).
Per claim 1, Brickell discloses as method for use and management of issuer provided payment tokens, comprising:
receiving, at an issuing financial institution computer program executed by a backend for an issuing financial institution, a request for a limited-use payment token for a primary account number (PAN) with the issuing financial institution from a token requestor computer program, wherein the request comprises the PAN (see ¶0002, tokenization; ¶0003, communicates the payment card information to the issuer system; ¶0018; ¶0025; ¶0097; ¶0098);
storing, by the issuing financial institution computer program, the mapping of the PAN to the limited-use payment token in an issuing financial institution token vault (see ¶0026, associates the token with the payment card information; ¶0125, associates the token with the payment card information; ¶0148); and
providing, by the issuing financial institution computer program, the limited-use payment token to the token requestor computer program, wherein the limited-use payment token is limited to use with a merchant (see ¶0003, the issuer system transmits the token to the user computing device; ¶0018; ¶0026, the token is stored in the digital wallet application resident on the user computing device and can be used in place of the actual credit number that can be used in place of the actual credit number; ¶0121);
receiving, by the financial institution computer program, the limited-use payment token and a transaction (see ¶0026, token can be used in place of the actual credit number in a transaction with a POS device. The issuer system transmits the token the payment processing system; ¶0027; ¶0042); and
executing, by the financial institution computer program, the transaction in response to the transaction involving the merchant with which the limited-payment token is limited (see ¶0027, the payment system transmits a transaction authorization request … and the token to the issuer system. The issuer system verifies and approves the payment authorization request; ¶0042; ¶0057).
Brickell does not specifically teach requesting, by the issuing financial institution computer program, the limited-use payment token for the PAN from a token provider, generating, by the token provider, the payment token by issuing the limited-use payment token from a pool of available payment tokens; storing, by the token provider, a mapping of the PAN to the limited-use payment token in a token provider token vault; receiving, by the issuer financial institution computer program and from the token provider, the limited-use payment token. In other word, in the issuing financial institution generates the token in Brickell.
Dill, however, teaches requesting, by the computer program, the limited-use payment token for the PAN from a token provider; generating, by the token provider, the payment token by issuing the limited-use payment token from a pool of available payment tokens; storing, by the token provider, a mapping of the PAN to the limited-use payment token in a token provider token vault; receiving, by the computer program and from the token provider, the limited-use payment token (see Fig. 4: Token Expiration Date 412 and Merchant Restriction: 414; ¶0011, various entity including wallet providers, acquirers, issuers, etc. to request payment tokens from a token registry; ¶0029, tokenization description; ¶0042, token request; ¶0050; ¶0054, provisioning token on a device and storing of the token information in the token vault; ¶0062, expired token can be recycled for re-use; ¶0098, token requester may be application; ¶0103 ; ¶0104, token vault used to maintain issued or generated tokens along with their corresponding PAN; ¶0108, token requestor may request token and the token system may generate and return tokens; ¶0109; ¶0167, merchant restrictions 414 indicate that the token may be restricted to merchants).
Hence as Brickell teaches a token management by the bank computer system including issuance of the token as described above, it would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to substitute the generation of the token as taught by Dill as generation of the token in Brickell. Thus, the simple substitution of one known technique for another producing a predictable result renders the claim obvious. Furthermore, it has been held that constructing a formerly integral structure in various element involves only routine skill in the art.
The application is reminded that the description of purpose of the request, i.e., for a payment token for a primary account number (PAN) from a token requestor computer program, does not move to distinguish over prior art as the description is merely describes intent of the request.
As per claims 2 and 19, Brickell/Dill further teaches wherein the token requestor computer program comprises a merchant computer program and/or a mobile electronic wallet (see Brickell: ¶0002, digital wallet; ¶0003; ¶0018, transaction at a merchant system or online merchant website via the digital wallet application; ¶0027). Furthermore, description of what the computer program comprises is non-functional descriptive material as the description does not affect the positively recited step(s) in the claim in a manipulative sense.
As per claim 3, Brickell /Dill further teaches wherein the token provider is configured to generate a cryptogram for the payment token, and the method further comprises receiving, by the financial institution computer program, the cryptogram from the token provider (see Dill: ¶0117, request values including cryptograms for tokens using their respective interface).
As per claim 4, Brickell /Dill further teaches wherein the token provider comprises a payment network or a third-provider provider (see Dill: Fig. 2, network token system). Furthermore, description of what the token provider comprises does not move to distinguish over prior art as the description does not affect the positively recited step(s) in the claim in a manipulative sense.
As per claim 14, Brickell/Dill further teaches wherein the payment token is limited to transaction with a specific merchant (Dill: ¶0047, limiting tokens to specific domain, i.e., specified merchant). Furthermore, “is limited to transaction with a specific merchant” is intended use of the payment token.
As per claim 15, Brickell /Dill further teaches wherein the payment token is limited to a certain number of transactions (see Dill: ¶0058, limited or restricted in use, i.e., time, amount, or number of use).
As per claims 17-18, Brickell /Dill further teaches wherein the payment token is returned to the pool of available payment tokens after it expires, wherein the token provider is configured to re-issue the payment token from the pool of payment tokens for another PAN after the payment token expires (see Dill: ¶0062, token system may recycle or reuse of previously issued token … life-cycle expiration date may be maintained by the network token system for the entire life-cycle of a token once a token has been used for a transaction).
Response to Argument(s)
112
The claims remain rejected under 112 as described above in the 112 sections.
101
The applicant asserts that “by only executing transactions involving the merchant with which the limited-use token is limited, the claims employ the information provided by the alleged judicial exception and provide a meaningful way of using the alleged judicial exception beyond generally linking the use of the judicial exception to a particular technological environment”.
First, in responding to the applicant’s assertion of “the transaction is not executed if the transaction does not involve the merchant for which the payment token is limited”, the claim does not recite such features. The claim merely describes the payment token as being limited-use payment token. Under the broadest reasonable interpretation, a payment token that is tied to a credit card with limit as in the case of most credit card account is considered to be limited-use as the user is not allowed to spend above the limit that the credit card account allows. The examiner also finds that a payment token with an expiration date is a limited-use token.
Even if the applicant’s interpretation, i.e., that the payment token is limited to a particular merchant, is read into the claim, in arguendo, the concept of limiting a payment token to be used with a particular merchant only is an abstract idea, i.e., economic principle and/or sales activity. As such, the claim does not provide a meaningful way of using the alleged judicial exception beyond generally linking the use of the judicial exception to a particular technological environment, rather the additional elements amount to no more than mere instructions to implement the abstract idea and/or merely uses a computer (i.e., backend computer and programs) as a tool to perform an abstract idea – see MPEP 2106.05(f).
103
The applicant asserts that the Office Action has failed to establish a prima facie case of obviousness on page 10 of the Amendment. The applicant, however, does not provide any rationale or arguments to the assertion.
The applicant asserts that neither Brickell nor Dill discloses a token that is limited to use with a specific merchant. The examiner respectfully disagrees. By Brickell/Dill disclosing the use of payment token with a merchant, Brickell/Dill necessarily teach limited-use (i.e., limit on the account and/or expiratory on the account, see Brickell: ¶0048, expiration date and Dill: Fig. 4) with a specific merchant (i.e., specific merchant that the user chooses to perform the transaction).
Furthermore, Dill particularly teaches the limited-use payment token that is limited to use with a specific merchant (see ¶0167, Merchant restriction 414 indicate that the token 402 may be restricted to merchants with merchant category code 5111).
The applicant asserts that Dill’s disclosing of reusing or recycling a token is not a disclosure of issuing the limited-use payment token from a pool of available payment tokens. The examiner respectfully disagrees with the applicant’s assertion. One of ordinary skill in the art would appreciate that Dill invention is limited to single user or single account. As such, one of ordinary skill would understand that by Dill disclosing that the token system may recycle or reuse a previously issued token, one of ordinary skill in the art would appreciate the token to include multiple tokens, i.e., pool of tokens.
The rejections are maintained for the reasons outlined above.
Conclusion
THIS ACTION IS MADE FINAL. 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20120317036 discloses merchant-specific tokens;
US20170004501, US20240220967, and US 20210287223 discloses outsourcing of the tokenization and/or detokenization function;
US20210256506 discloses tokenization system that the financial bank, i.e., acquirer computer, interacting with tokenization server to achieve tokenization of PAN;
US20180174138 discloses issuer interacting with a third-party tokenizer in achieving tokenization of PAN;
US20140344153 discloses a tokenization module can provide and store tokens for mobile payment transactions, transit transactions, digital wallet applications, merchant point of sale (POS) applications, personalization services, and the like.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN S KIM whose telephone number is (571)270-5287. The examiner can normally be reached Monday -Friday: 7:00 - 3:30.
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.
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights