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 .
Election/Restrictions
Applicant’s election without traverse of claims 6-21 (Species B) and cancellation of claims 1-5 (Species A) in the reply filed on 06/25/2025 is acknowledged.
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 6-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 6-13 are directed to a method and claims 14-21 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
Claim 6 recites: A method of integrating a digital payment card with a card issuer mobile application, the method comprising:
receiving, at a wallet server from a card issuer, card identification information including a card identifier that identifies a payment card and an identifier of a cardholder associated with the payment card;
sending, from the wallet server, card push data to the card issuer; and
receiving first information representative of funding card push data from a mobile device having a mobile application installed thereon, the mobile application interfacing with the wallet server via a software package installed on the mobile device and configured to directly communicate with the wallet server, the funding card push data including an identifier associated with the mobile device.
(Additional elements emphasized in bold)
The above claim describes a process for receiving from a card issuer, card identification information including a card identifier that identifies a payment card and an identifier of a cardholder associated with the payment card; sending tokenized card information to the card issuer; and receiving first information representative of tokenized card information from a client, the tokenized card information including an identifier associated with the client. Therefore, claim 6 is directed to the abstract idea of payment card tokenization which is grouped within the “certain methods of organizing human activity” grouping under the “fundamental economic principles and practices” sub-grouping of abstract ideas in prong one of step 2A. Accordingly, the claims recite an abstract idea (See MPEP 2106.04).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (See MPEP 2106.04), the additional elements of the claim such as digital payment card, mobile application, wallet server, card push data, mobile device, and software package merely uses a computer as a tool to perform an abstract idea. The use of digital payment card, mobile application, card push data, and software package does no more than generally link the abstract idea to a particular field of use (e.g. digital payments and mobile devices) due to reciting such elements at no more than a high level of generality (e.g. digital payment card and card push data are merely substitutes for physical payment card information and mobile application and software package are merely generic software programmed to carry out the abstract idea). Finally, the use of a processor/computer (wallet server, mobile device) as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B (See MPEP 2106.05), the additional elements of digital payment card, mobile application, wallet server, card push data, mobile device, and software package do not amount to significantly more than the abstract idea. As discussed above, taking the claim elements separately, the use of digital payment card, mobile application, card push data, and software package does no more than generally link the abstract idea to a particular field of use (e.g. digital payments and mobile devices) due to reciting such elements at no more than a high level of generality (e.g. digital payment card and card push data are merely substitutes for physical payment card information and mobile application and software package are merely generic software programmed to carry out the abstract idea). Finally, the use of a wallet server and mobile device does no more than use processors/computers as tools to implement and/or automate the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of managing a digital wallet. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-13 further recite characteristics of data (e.g. types of card push data) and the additional elements of SDK, cipher, and token service provider/token-based payment feature do no more than continue to generally link the abstract idea to a particular field of use. Accordingly, the dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Claim 14 recites: A method comprising:
receiving a request for a token-based payment feature at a wallet server, the request being received directly from a software development kit (SDK) installed at a mobile device and integrated with a mobile application associated with a card issuer, the SDK being provided by an entity controlling the wallet server;
submitting card and transaction information from the wallet server to a token service provider for use of the token-based payment feature;
receiving, at the wallet server, a response from the token service provider indicating a result of submitting the card and transaction information; and
forwarding the result to the mobile device via the SDK, the result being provided to the mobile application provided by the card issuer.
(Additional elements emphasized in bold)
The above claim describes a process for receiving a request for a tokenized payment card from a cardholder at a card issuer; submitting card and transaction information to a tokenization service; receiving a response form the tokenization service indicating a result of submitting the card and transaction information; and forwarding the result to the cardholder at the card issuer. Therefore, claim 14 is directed to the abstract idea of payment card tokenization which is grouped within the “certain methods of organizing human activity” grouping under the “fundamental economic principles and practices” sub-grouping of abstract ideas in prong one of step 2A. Accordingly, the claims recite an abstract idea (See MPEP 2106.04).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (See MPEP 2106.04), the additional elements of the claim such as token-based payment feature, wallet server, SDK, mobile device, mobile application, and token service provider merely uses a computer as a tool to perform an abstract idea. The use of token-based payment feature, SDK, and mobile application does no more than generally link the abstract idea to a particular field of use (e.g. digital payments and mobile devices) due to reciting such elements at no more than a high level of generality (e.g. token-based payment feature is merely a substitute for physical payment card information and mobile application and SDK are merely generic software programmed to carry out the abstract idea). Finally, the use of a processor/computer (wallet server, mobile device, token service provider) as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B (See MPEP 2106.05), the additional elements of token-based payment feature, wallet server, SDK, mobile device, mobile application, and token service provider do not amount to significantly more than the abstract idea. As discussed above, taking the claim elements separately, The use of token-based payment feature, SDK, and mobile application does no more than generally link the abstract idea to a particular field of use (e.g. digital payments and mobile devices) due to reciting such elements at no more than a high level of generality (e.g. token-based payment feature is merely a substitute for physical payment card information and mobile application and SDK are merely generic software programmed to carry out the abstract idea). Finally, the use of a wallet server, mobile device, and token service provider does no more than use processors/computers as tools to implement and/or automate the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of digital payment card tokenization. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 15-21 further recite characteristics of data (e.g. types of requests and identifiers) and the additional elements of card push data and cipher do no more than continue to generally link the abstract idea to a particular field of use. Accordingly, the dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also 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.
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.
Claims 1-21 are rejected under 35 U.S.C. 103 as being unpatentable over Arora (US 20190236592 "Arora") in view of Kim et al. (US 20170337542 "Kim").
Regarding claim 6, Arora discloses: A method of integrating a digital payment card with a card issuer mobile application, the method comprising:
receiving, at a wallet server ("payment network server") from a card issuer, card identification information including a card identifier that identifies a payment card and an identifier of a cardholder associated with the payment card (Fig. 1-2, 0055-0057, 0062-0063);
sending, from the wallet server, card push data ("payment token") to the card issuer (Fig. 1-2, 0057-0058, 0064-0065);
and receiving first information representative of funding card push data from a mobile device having a mobile application installed thereon (Fig. 1-2, 0059, 0066)...
Arora does not disclose: ...the mobile application interfacing with the wallet server via a software package installed on the mobile device and configured to directly communicate with the wallet server, the funding card push data including an identifier associated with the mobile device.
However, in the same field of endeavor, Kim discloses: the mobile application interfacing with the wallet server via a software package installed on the mobile device and configured to directly communicate with the wallet server (Fig. 6, 0135-0136, 0140, 0142), the funding card push data including an identifier associated with the mobile device (0178-0179, 0293, 0296).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 6 disclosed by Arora by including mobile application interfacing with a wallet server via a software package as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to allow easy customization of payment tools associated with a specific card company and their technology (Kim 0138).
Regarding claim 7, Arora in view of Kim discloses all limitations of claim 6. Arora further discloses: wherein the mobile application is provided by the card issuer (0055).
Kim further discloses: wherein the wallet server receives the funding card push data from the mobile device via the software package, and wherein the software package comprises a software development kit (SDK) installed on the mobile device, the SDK being provided by an entity controlling the wallet server for integration with the mobile application (Fig. 6, 0138, 0142, 0199, 0254)...
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 7 disclosed by Arora in view of Kim by including an SDK as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to allow easy customization of payment tools associated with a specific card company and their technology (Kim 0138).
Regarding claim 8, Arora in view of Kim discloses all limitations of claim 6. Arora further discloses: wherein the funding card push data includes at least one of a unique identifier of the payment card or a primary account number (PAN) and an expiry date of the payment card (0057, 0064).
Regarding claim 9, Arora in view of Kim discloses all limitations of claim 6. Arora further discloses: wherein the information representative of the funding card push data comprises the funding card push data (0059, 0064, 0066).
Regarding claim 10, Arora in view of Kim discloses all limitations of claim 6. Arora further discloses: wherein the information representative of the funding card push data includes a cipher of the funding card push data (0057, 0064).
Regarding claim 11, Arora in view of Kim discloses all limitations of claim 10. Kim further discloses: wherein the SDK retains second information representative of the funding card push data, and wherein reconstruction of the funding card push data at the SDK requires both the first information and the second information (Fig. 9, 0201, 0203).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 11 disclosed by Arora in view of Kim by including reconstructing card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
Regarding claim 12, Arora in view of Kim discloses all limitations of claim 11. Kim further discloses: wherein the cipher comprises an exclusive-or operation executed on the funding card push data at the SDK to generate the first information and the second information (Fig. 9, 0201, 0203).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 12 disclosed by Arora in view of Kim by including reconstructing card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
Regarding claim 13, Arora in view of Kim discloses all limitations of claim 6. Kim further discloses: receiving a request for a token-based payment feature at the wallet server, the request being received directly from the SDK (Fig. 6, 0138, 0142, 0199, 0254);
submitting card and transaction information from the wallet server to a token service provider for use of the token-based payment feature (Fig. 6, Fig. 15, 0290-0294);
receiving, at the wallet server, a response from the token service provider indicating a result of submitting the card and transaction information (Fig. 15, 0304, 0308);
and forwarding the result to the mobile device via the SDK, the result being provided to the mobile application provided by the card issuer (Fig. 15, 0306, 0309).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 13 disclosed by Arora in view of Kim by including a token service provider as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to issue and manage payment information in a secure tokenized format (Kim 0143).
Regarding claim 14, Arora discloses: A method comprising:
receiving a request for a token-based payment feature at a wallet server,...a software development kit (SDK) installed at a mobile device and integrated with a mobile application associated with a card issuer, the SDK being provided by an entity controlling the wallet server (Fig. 1-2, 0055-0057, 0062-0064).
Kim further discloses: receiving a request for a token-based payment feature at a wallet server, the request being received directly from a software development kit (SDK) installed at a mobile device and integrated with a mobile application associated with a card issuer, the SDK being provided by an entity controlling the wallet server (Fig. 6, 0138, 0142, 0199, 0254);
submitting card and transaction information from the wallet server to a token service provider for use of the token-based payment feature (Fig. 6, Fig. 15, 0290-0294);
receiving, at the wallet server, a response from the token service provider indicating a result of submitting the card and transaction information (Fig. 15, 0304, 0308);
and forwarding the result to the mobile device via the SDK, the result being provided to the mobile application provided by the card issuer (Fig. 15, 0306, 0309).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 13 disclosed by Arora in view of Kim by including a token service provider and SDK as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to issue/manage payment information in a secure tokenized format and to allow easy customization of payment tools associated with a specific card company/technology (Kim 0138, 0143).
Regarding claim 15, Arora in view of Kim discloses all limitations of claim 14, Kim further discloses: receiving, at the SDK, a user request for use of a token-based payment feature provided by a token service provider via the mobile application (Fig. 6, 0138, 0142, 0199, 0254);
and receiving, at the SDK, user authentication information from a user of the mobile device, wherein receiving the user request and the user authentication information occurs prior to receiving the request at the wallet server (Fig. 15, 0293-0294, 0296).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 15 disclosed by Arora in view of Kim by including authentication information as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification as a simple substitution of one known element for another to obtain predictable results (KSR International Co. v. Teleflex Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007)).
Regarding claim 16, Arora in view of Kim discloses all limitations of claim 15. Arora in view of Kim does not disclose: wherein the request for the token-based payment feature is generated by the SDK at least in part based on successful authentication of the user via the user authentication information.
However, the above limitation contains intended result language and as such will not differentiate claims from the prior art. Applicant(s) are reminded that intended result language does not have patentable weight. See Texas Instruments Inc. v. International Trade Commission, 26 USPQ2d 1010 (Fed. Cir. 1993); Amazon.com Inc. v. Barnesandnoble.com Inc., 57 USPQ2d 1747 (CAFC 2001). ("A (whereby/wherein) clause that merely states the result of the limitations in the claim adds nothing to the patentability or substance of the claim"); Griffin v. Bertina, 62 USPQ2d 1431 (Fed. Cir. 2002).
Regarding claim 17, Arora in view of Kim discloses all limitations of claim 14. Arora further discloses: prior to receiving the request: receiving, at the wallet server from the card issuer, card identification information including a card identifier that identifies a payment card and an identifier of a cardholder associated with the payment card (Fig. 1-2, 0055-0057, 0062-0063);
sending, from the wallet server, card push data to the card issuer (Fig. 1-2, 0057-0058, 0064-0065);
and receiving first information representative of funding card push data from the mobile device (Fig. 1-2, 0059, 0066).
Kim further discloses: the funding card push data including an identifier associated with the mobile device (0178-0179, 0293, 0296).
Regarding claim 18, Arora in view of Kim discloses all limitations of claim 17. Arora in view of Kim fails to expressly disclose: wherein the identifier of the cardholder comprises at least one of a wallet identifier or a client identifier.
However, the difference between a cardholder identifier and a wallet or client identifier is only found in the non-functional descriptive material and is not functionally involved in the steps recited. The receiving card identification information step would be performed the same regardless of the descriptive material since none of the steps explicitly interact therewith. Limitations that are not functionally interrelated with the useful acts, structure, or properties of the claimed invention carry little or no patentable weight. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See In re Ngai 367 F.3d 1336, 1339, 70 USPQ2d 1862 (Fed. Cir. 2004); In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP § 2111.05; Cf. In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983).
Therefore, it would also have been obvious to a person of ordinary skill in the art at the time of applicant' s invention to include any identification information because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention.
Regarding claim 19, Arora in view of Kim discloses all limitations of claim 17. Arora further discloses: wherein the information representative of the funding card push data includes a cipher of the funding card push data (0057, 0064)...
Kim further discloses: ...and wherein the SDK retains second information representative of the funding card push data (Fig. 9, 0201, 0203).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 19 disclosed by Arora in view of Kim by including retaining representative card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
Regarding claim 20, Arora in view of Kim discloses all limitations of claim 19. Kim further discloses: wherein reconstruction of the funding card push data at the SDK requires both the first information and the second information (Fig. 9, 0201, 0203).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 19 disclosed by Arora in view of Kim by including reconstructing card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
Regarding claim 21, Arora in view of Kim disclose all limitations of claim 17. Kim further discloses: in response to the request, providing information representative of funding card push data from the wallet server to the SDK (Fig. 15, 0297-0298);
and receiving reconstructed funding card push data from the SDK at the wallet server and providing the funding card push data as part of the card and transaction information to the token service provider (Fig. 15, 0301-0303), wherein reconstructed funding card push data is based on the information representative of the funding card push data stored at the wallet server and second information maintained at the SDK (Fig. 15, 0291-0292).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 19 disclosed by Arora in view of Kim by including reconstructing card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ko et al. (US 20190236592) generally discloses an apparatus and method for registering and issuing tokens for virtual currency in coordination with an issuer server and token server (see Figs. 6a-6c, 7a, 0102-0110).
Lahkar et al. (US 20170032362) generally discloses a method for enrolling a payment card in a mobile wallet app via a wallet server requesting EMV data from an issuer server and generating a payment token to return to the mobile wallet app (see Fig. 2, 0034-0045).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR RAK whose telephone number is (571)270-1575. The examiner can normally be reached Monday-Friday 11:00-7:00 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, John W Hayes can be reached at (571)-272-6708. 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.
/T.R./Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697