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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 8 October 2025 has been entered.
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-5, 8-14, and 17 are directed to a method. Thus, each claim falls within at least one of the four categories of patent-eligible subject matter enumerated in 35 U.S.C. § 101 (see MPEP § 2106.03, II. Eligibility Step 1: Whether a Claim is to a Statutory Category).
However, Claims 1-5, 8-14, and 17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1 recites prompting a user for credit application information […] for processing of a credit card application, wherein said credit application information is numerical information; receiving said credit application information […]; presenting approval of a credit card account based on said credit application information […]; storing a credit card number for said credit card account at a remote location and not providing it to said mobile device such that it is not available on said mobile device; and pre-populating a credit card number field with said stored credit card number for an […] payment, wherein said pre-populating is provided by a credit card issuer […].
This is an abstract idea that falls under the grouping of certain methods of organizing human activity – commercial or legal interactions including marketing or sales activities or behaviors and business relations (see MPEP 2106.04(a)(2), subsection II.B) at least because the claim recites processing of a credit card application, presenting approval of a credit card account based on received credit application information, storing a credit card number, and populating a credit card number field with the credit card number for payment.
The additional elements (beyond the abstract idea) of the claim include: computer-implement[ation], mobile device, and online.
The additional claim elements are recited at a high-level of generality; and so, generally link the use of the judicial exception to a particular technological environment of networked computers and do not impose any meaningful limits on practicing the abstract idea. The claimed invention does not improve the functioning of a computer or improve another technology or technical field. Limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception cannot integrate a judicial exception into a practical application. See MPEP 2106.05(h).Thus, the judicial exception is not integrated into a practical application.
Independent claim 9 recites substantially the same limitations as claim 1 but does not include the steps of prompting a user for credit application information or presenting approval of the credit card account. Removal of these steps does not render the claim eligible because the remaining steps are directed to the same abstract idea identified in claim 1 because claim 9 recites processing a credit card application, inputting credit card [application] information, storing a credit card number, and populating a credit card number field with the stored credit card number for payment.
Claim 9 recites the same additional limitations identified in claim 1, above, and is not patent-eligible under 35 U.S.C. § 101 for the same reasons given for claim 1.
Claims 2 and 11 depend from claims 1 or 9 and merely add that the recited mobile device is personal property of the user. The ownership status of the mobile device is part the abstract idea of commercial interactions and does not integrate the abstract idea into a practical application or provide significantly more.
Claims 3 and 12 depend from claims 1 or 9 and recite the additional limitation of displaying a link to an application form at the mobile device. The application form is part of the abstract idea of commercial interactions and “a link” is a generic computing element that does not integrate the abstract idea into a practical application or provide significantly more, but merely limits the abstract idea to the particular technological environment of networked computers.
Claims 4 and 13 depend from claims 1 or 9 and recite the additional limitation of displaying said credit card application at said mobile device. Displaying a credit card application is part of the abstract idea and using a mobile device as a generic computing element does not integrate the abstract idea into a practical application or provide significantly more, but merely limits the abstract idea to the particular technological environment of networked computers.
Claims 5 and 14 depend from claims 1 or 9 and recite the additional limitation of redeeming a reward associated with the credit account. This is part of the abstract idea of commercial interactions and using a mobile device as a generic computing element does not integrate the abstract idea into a practical application or provide significantly more, but merely limits the abstract idea to the particular technological environment of networked computers.
Claims 8 and 17 depend from claims 1 or 9 and recite the additional limitation of authenticating said user with biometrics prior to populating a credit number field for payment. Authentication of a user is part of the abstract idea of commercial interactions or fundamental economic principle or practice of mitigating risk. Although, the specification at ¶[0073] provides examples of authenticating by biometrics such as “thumb print scanning, voice detection, heart rate monitoring, etc.”, claims 8 and 17 generically recite “authentication […] with biometrics.” Such a generic recitation does not integrate the abstract idea into a practical application or provide significantly more, but merely limits the abstract idea (which includes authentication of a user) to the particular technological environment of networked computers.
Claim 10 depends from claim 9. Claim 10 recites the additional limitation of presenting approval of a credit card account at the mobile device. Presenting approval of a credit card account is part of the abstract idea of commercial interactions and using a mobile device as a generic computing element to present approval does not integrate the abstract idea into a practical application or provide significantly more, but merely limits the abstract idea to the particular technological environment of networked computers.
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.
Claims 1-5 and 9-14 are rejected under 35 U.S.C. 103 as being unpatentable over SANCHEZ (US 20140070001 to Sanchez; J. Scott et al.) in view of ANDERSON (US 9064246 B1 to ANDERSON, K. et al.) in further view of MATTHEWS (US 20120116933 A1 to Matthews; Bradley Owen et al.).
Regarding claim(s) 1,
SANCHEZ discloses:
A computer-implemented method comprising (SANCHEZ [0108]: a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block or blocks.):
prompting a user for credit application information via a mobile device for processing of a credit card application (see, at least, SANCHEZ figure 3, step 320 “Present credit application prompts on the mobile device associated with the consumer” and SANCHEZ figure 3 step 322: receive consumer inputs at the mobile device associated with consumer in response to prompts and SANCHEZ [0072], [0082], [0092]: credit card application fillable fields related to a consumer's personal, financial, and employment information and user inputs certain identification information such as a name, home address, social security number or other personal identification information, mobile telephone number, email or messaging address, work history, salary and/or other financial asset information),
wherein said credit application information is numerical information (see, at least, SANCHEZ figure 3 step 322: receive consumer inputs at the mobile device associated with consumer in response to prompts and SANCHEZ [0072], [0082], [0092]: credit card application fillable fields related to a consumer's personal, financial, and employment information and user inputs certain identification information such as a name, home address, social security number or other personal identification information, mobile telephone number, email or messaging address, work history, salary and/or other financial asset information);
receiving said credit application information at said mobile device (see, at least, SANCHEZ figure 3 step 322: receive consumer inputs at the mobile device associated with consumer in response to prompts and SANCHEZ [0072], [0082], [0092]: credit card application fillable fields related to a consumer's personal, financial, and employment information and user inputs certain identification information such as a name, home address, social security number or other personal identification information, mobile telephone number, email or messaging address, work history, salary and/or other financial asset information);
presenting approval of a credit card account based on said credit application information at said mobile device (SANCHEZ: at least Abstract and Sections [0032] and [0033] and SANCHEZ [0012]: In one aspect of an embodiment, the user device may display the notification of approval and the credit account number on a display of the user device.);
storing a credit card number for said credit card account at a remote location (SANCHEZ: figure 1, item 106 “Server Transaction Processing System 106” associated with data store 151 and separate from Mobile Device 1 and N (items 120(1) and 120(N); ¶[0077]: Item 120 is labeled “consumer mobile device”; [0077]: In block 332, the credit card account information can be transmitted to the consumer mobile device 120. For example, the credit card account information can be stored in a database associated with the server 106 and can be associated with the authorization token or mPIN by the server 106.; figure 1, item 126 “Network”; ¶[0071]: the server 106 can transmit the credit card application to the consumer mobile device 120 via the network 126.); SANCHEZ ¶[0077]: “For example, the credit card account information can be stored in a database associated with the server 106 and can be associated with the authorization token or mPIN by the server 106. The authorization token or mPIN and identifying information about the credit card (such as the name of the card) can be stored in memory 118 of the consumer mobile device 120 for access by the mobile commerce application program 116 as one of the optional payment methods provided to the consumer on the consumer mobile device 120)
SANCHEZ does not expressly disclose the following limitations, which ANDERSON teaches:
and not providing it to said mobile device such that it is not available on said mobile device (ANDERSON: Column 8, lines 64-67 to column 9, lines 1-12: payment server 110 and stores payment account information previously furnished by portable electronic devices 150 to the mobile payment application 120 for use in making online transactions (including information associated with credit card accounts); Column 4, lines 7-30: Many of the system's interactions are transparent to both the portable electronic device and the online merchant. the network access identifier of the portable electronic device or other identification passed to the mobile payment server can be used to matched the portable electronic device with the subscriber and his/her registered payment options; figure 3, block 304: Mobile Payment server sends message to the portable electronic device containing payment options to complete the transaction with the online merchant, where the message does not contain secure account information associated with the payment options, Column 11, lines 30-43: At block 304, the mobile payment server 110 sends a second message to the portable electronic device 150 containing the payment options requested by the online merchant 160 at block 302. The second message includes payment options available to the portable electronic device 150 but does not include account information related to the payment options. For example, in an embodiment, the second message may identify a payment option as "Credit Card X of Robert R Roberts" but not include confidential account and/or financial information such as an account number, an authorization number, or a PIN.)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SANCHEZ which relates to mobile commerce, and to systems and methods for facilitating the approval and use of a credit account via mobile commerce (see SANCHEZ [0002]), with these teachings from ANDERSON with the motivation of “reduc[ing] the risk of identity theft” and “exposing confidential information associated with a user of the portable device”) (see ANDERSON col. 11, ll. 50-56).
SANCHEZ does not expressly disclose the following limitations, which MATTHEWS however, teaches:
and pre-populating a credit card number field with said stored credit card number for an online payment, wherein said pre-populating is provided by a credit card issuer and not said mobile device (MATTHEWS: [0056] online transaction process begins with a cardholder 1 desiring to purchase from an online merchant's website. the cardholder 1 selects products from a merchant's online website 2, is routed or clicks to the merchant's payment page 2a (FIG. 5). The cardholder obtains a STN 15 that may then be automatically filled by the card provider 3 into the payment fields 144, 146, 148 (FIG. 7) on the payment web page 2b (FIG. 7). STN 15 is generated by the card provider's application server 5 and STN database 6.; MATTHEWS [0066]: The cardholder 1 suitably links to an online shopping site, orders a product or service or fills a shopping cart and goes to the payment page. […] [T]he STN 15 and other transaction information are automatically filled into the web shopping page by the card provider's web server; [0038]: a secondary transaction number (STN) 15 that was generated by an issuer ("card provider 3"); [0043]:the STN 15 is a purchasing number that acts as a charge card number; [0044]: In an exemplary embodiment involving credit, debit or other banking cards, the STN 15 has the same industry standard format that is used for the regular banking cards (e.g., 15 or 16 digit numbers).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SANCHEZ which relates to mobile commerce, and to systems and methods for facilitating the approval and use of a credit account via mobile commerce (see SANCHEZ [0002]), with these teachings from MATTHEWS, which relates to the automated reconciliation of card member spend (MATTHEWS ¶[0002]) with the motivation of allowing users to provide payment card information without having to “cut and paste[…]” or “drag[…] and drop[…]”the information (MATTHEWS ¶[0056]), thereby increasing efficiency and convenience.
Regarding claim(s) 2,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 1, as shown above.
SANCHEZ further discloses:
wherein said mobile device is personal property of said user (SANCHEZ: [0077] In block 332, the credit card account information can be transmitted to the consumer mobile device 120; SANCHEZ ¶[0034]: “the consumer's mobile device,” SANCHEZ [0070]: “the consumer mobile device” [versus] “merchant’s mobile payment program” and “location of the consumer mobile device” implying distinct merchant and consumer ownership of systems/devices; SANCHEZ ¶[0072]: “The downloadable credit card application is received at the consumer mobile device 120 [...]”).
Regarding claim(s) 3,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 1, as shown above.
SANCHEZ further discloses:
comprising: displaying a link to an application form at said mobile device (SANCHEZ [0072]: The downloadable credit card application is received at the consumer mobile device 120; the consumer can receive a display of an icon associated with the mobile commerce application program 116 and can select the icon on the I/O interface 142 to launch or open the mobile commerce application program 116. In block 320, credit application prompts are presented on the consumer mobile device 120 by the mobile commerce application program 116; ¶[0080]: the consumer mobile device 120 can receive a selection to obtain the offer. the consumer can input via the I/O interface 142 of the consumer mobile device 120 an acceptance of the offer by depressing the portion of the touch-screen display of consumer mobile device 120 provided with an "accept" radio button; In block 414, the server 106, such as the mobile commerce application program 102, can receive a request to download the credit card application associated with the offer from the instant issuance module 228 of the mobile commerce application program 116 of the consumer mobile device 120.; […] In block 414, the server 106, such as the mobile commerce application program 102, can receive a request to download the credit card application associated with the offer from the instant issuance module 228 of the mobile commerce application program 116 of the consumer mobile device 120.; ¶[0082]: [0082] The downloadable credit card application is received at the consumer mobile device 120).
Regarding claim(s) 4,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 1, as shown above.
SANCHEZ further discloses:
comprising: displaying said credit card application at said mobile device (SANCHEZ: ¶[0082]: The downloadable credit card application is received at the consumer mobile device 120. In block 422, credit application prompts are presented on the consumer mobile device 120 by the mobile commerce application program 116. For example, the instant issuance module 228 of the mobile commerce application program 116 can generate and display on the consumer mobile device 120 one or more prompts associated with applying for a credit card or similar product. These prompts can include, for example, radio buttons or fillable fields related to a consumer's personal, financial, and employment information. In block 424, the consumer can input information in response to the displayed prompts at the consumer mobile device 120.).
Regarding claim(s) 5,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 1, as shown above.
SANCHEZ discloses at [0057], the server transaction processing system providing loyalty/reward services; and at [0064], The mobile commerce application program can include a loyalty/rewards module 202), however, SANCHEZ does not expressly disclose the following limitations, which MATTHEWS however, teaches:
comprising: redeeming a reward at said mobile device, wherein said reward is associated with said credit card account (MATTHEWS: [0047] cardholder to can select preferences to control spending; These preferences may include: s Reward Points as Currency (cardholder 1 can use reward points (e.g. Membership Rewards.TM., Blue Loot.TM.) as currency to pay for purchases; ¶[0034]: The account number may optionally be located on or associated with a rewards card; ¶[0089]: One embodiment of this system, allows a cardholder 1 to create a STN 15 to be used to spend membership rewards points. In general, a membership or incentive rewards program is a loyalty program that rewards cardholders for using their charge card to make purchases. Cardholders accumulate points by using a participating charge card or by purchasing products at a participating merchant. These points may then be converted to a monetary value and redeemed to purchase merchandise.; ¶[0090]: cardholder 1 proceeds indicates that she would like to use her membership reward points that are available in her MR account; ¶[0093]: the cardholder 1 is able to choose to use membership reward points when shopping at a merchant 2 site that supports the membership rewards as a payment option.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SANCHEZ which relates to mobile commerce, and to systems and methods for facilitating the approval and use of a credit account via mobile commerce (see SANCHEZ [0002]) and discloses a rewards module (SANCHEZ ¶[0064]), with these teachings from MATTHEWS, which relates to the automated reconciliation of card member spend (MATTHEWS ¶[0002]) in order to allow a user to receive monetary value for accumulated reward points, to encourage cardholder use of an incentive reward program (MATTHEWS: ¶[0089]), and provide a cardholder with the flexibility to use reward points to effectuate a transaction (MATTHEWS ¶[0092]).
Regarding claim(s) 9,
SANCHEZ discloses:
A computer-implemented method comprising (SANCHEZ [0108]: a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block or blocks.):
accessing user input of credit application information via a mobile device for processing of a credit card application (see, at least, SANCHEZ figure 3, step 320 “Present credit application prompts on the mobile device associated with the consumer” and SANCHEZ figure 3 step 322: receive consumer inputs at the mobile device associated with consumer in response to prompts and SANCHEZ [0072], [0082], [0092]: credit card application fillable fields related to a consumer's personal, financial, and employment information and user inputs certain identification information such as a name, home address, social security number or other personal identification information, mobile telephone number, email or messaging address, work history, salary and/or other financial asset information),
wherein said credit application information is numerical information (see, at least, SANCHEZ figure 3 step 322: receive consumer inputs at the mobile device associated with consumer in response to prompts and SANCHEZ [0072], [0082], [0092]: credit card application fillable fields related to a consumer's personal, financial, and employment information and user inputs certain identification information such as a name, home address, social security number or other personal identification information, mobile telephone number, email or messaging address, work history, salary and/or other financial asset information);
inputting said credit application information in said credit card application via said mobile device (see, at least, SANCHEZ figure 3 step 322: receive consumer inputs at the mobile device associated with consumer in response to prompts and SANCHEZ [0072], [0082], [0092]: credit card application fillable fields related to a consumer's personal, financial, and employment information and user inputs certain identification information such as a name, home address, social security number or other personal identification information, mobile telephone number, email or messaging address, work history, salary and/or other financial asset information),
wherein said credit card application is for establishing a credit card account (SANCHEZ: at least Abstract and Sections [0032] and [0033] and SANCHEZ [0012]: In one aspect of an embodiment, the user device may display the notification of approval and the credit account number on a display of the user device.);
storing a credit card number for said credit card account at a remote location (SANCHEZ: figure 1, item 106 “Server Transaction Processing System 106” associated with data store 151 and a separate from Mobile Device 1 and N (items 120(1) and 120(N); ¶[0077]: Item 120 is labeled “consumer mobile device”; [0077] In block 332, the credit card account information can be transmitted to the consumer mobile device 120. For example, the credit card account information can be stored in a database associated with the server 106 and can be associated with the authorization token or mPIN by the server 106.; figure 1, item 126 “Network”; ¶[0071]: [0071] the server 106 can transmit the credit card application to the consumer mobile device 120 via the network 126.);
SANCHEZ does not expressly disclose the following limitations, which ANDERSON teaches:
and not providing it to said mobile device such that it is not available on said mobile device (ANDERSON: Column 8, lines 64-67 to column 9, lines 1-12: payment server 110 and stores payment account information previously furnished by portable electronic devices 150 to the mobile payment application 120 for use in making online transactions (including information associated with credit card accounts); Column 4, lines 7-30: Many of the system's interactions are transparent to both the portable electronic device and the online merchant. the network access identifier of the portable electronic device or other identification passed to the mobile payment server can be used to matched the portable electronic device with the subscriber and his/her registered payment options; figure 3, block 304: Mobile Payment server sends message to the portable electronic device containing payment options to complete the transaction with the online merchant, where the message does not contain secure account information associated with the payment options, Column 11, lines 30-43: At block 304, the mobile payment server 110 sends a second message to the portable electronic device 150 containing the payment options requested by the online merchant 160 at block 302. The second message includes payment options available to the portable electronic device 150 but does not include account information related to the payment options. For example, in an embodiment, the second message may identify a payment option as "Credit Card X of Robert R Roberts" but not include confidential account and/or financial information such as an account number, an authorization number, or a PIN.)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SANCHEZ which relates to mobile commerce, and to systems and methods for facilitating the approval and use of a credit account via mobile commerce (see SANCHEZ [0002]), with these teachings from ANDERSON with the motivation of “reduc[ing] the risk of identity theft” and “exposing confidential information associated with a user of the portable device”) (see ANDERSON col. 11, ll. 50-56).
SANCHEZ does not expressly disclose the following limitations, which MATTHEWS however, teaches:
and pre-populating a credit card number field with said stored credit card number for an online payment, wherein said pre-populating is provided by a credit card issuer and not said mobile device (MATTHEWS: [0056] online transaction process begins with a cardholder 1 desiring to purchase from an online merchant's website. the cardholder 1 selects products from a merchant's online website 2, is routed or clicks to the merchant's payment page 2a (FIG. 5). The cardholder obtains a STN 15 that may then be automatically filled by the card provider 3 into the payment fields 144, 146, 148 (FIG. 7) on the payment web page 2b (FIG. 7). STN 15 is generated by the card provider's application server 5 and STN database 6.; MATTHEWS [0066]: The cardholder 1 suitably links to an online shopping site, orders a product or service or fills a shopping cart and goes to the payment page. […] [T]he STN 15 and other transaction information are automatically filled into the web shopping page by the card provider's web server; [0038]: a secondary transaction number (STN) 15 that was generated by an issuer ("card provider 3"); [0043]:the STN 15 is a purchasing number that acts as a charge card number; [0044]: In an exemplary embodiment involving credit, debit or other banking cards, the STN 15 has the same industry standard format that is used for the regular banking cards (e.g., 15 or 16 digit numbers).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SANCHEZ which relates to mobile commerce, and to systems and methods for facilitating the approval and use of a credit account via mobile commerce (see SANCHEZ [0002]), with these teachings from MATTHEWS, which relates to the automated reconciliation of card member spend (MATTHEWS ¶[0002]) with the motivation of allowing users to provide payment card information without having to “cut and paste[…]” or “drag[…] and drop[…]”the information (MATTHEWS ¶[0056]), thereby increasing efficiency and convenience.
Regarding claim(s) 10,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 9, as shown above.
SANCHEZ further discloses:
comprising: presenting approval of a credit card account based on said credit application information at said mobile device (SANCHEZ: at least Abstract and Sections [0032] and [0033] and SANCHEZ [0012]: In one aspect of an embodiment, the user device may display the notification of approval and the credit account number on a display of the user device.).
Regarding claim(s) 11,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 9, as shown above.
SANCHEZ further discloses:
wherein said mobile device is personal property of said user (SANCHEZ: [0077] In block 332, the credit card account information can be transmitted to the consumer mobile device 120; SANCHEZ ¶[0034]: “the consumer's mobile device,” SANCHEZ [0070]: “the consumer mobile device” [versus] “merchant’s mobile payment program” and “location of the consumer mobile device” implying distinct merchant and consumer ownership of systems/devices; SANCHEZ ¶[0072]: “The downloadable credit card application is received at the consumer mobile device 120 [...]”).
Regarding claim(s) 12,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 9, as shown above.
SANCHEZ further discloses:
comprising: displaying a link to an application form at said mobile device (SANCHEZ [0072]: The downloadable credit card application is received at the consumer mobile device 120; the consumer can receive a display of an icon associated with the mobile commerce application program 116 and can select the icon on the I/O interface 142 to launch or open the mobile commerce application program 116. In block 320, credit application prompts are presented on the consumer mobile device 120 by the mobile commerce application program 116; ¶[0080]: the consumer mobile device 120 can receive a selection to obtain the offer. the consumer can input via the I/O interface 142 of the consumer mobile device 120 an acceptance of the offer by depressing the portion of the touch-screen display of consumer mobile device 120 provided with an "accept" radio button; In block 414, the server 106, such as the mobile commerce application program 102, can receive a request to download the credit card application associated with the offer from the instant issuance module 228 of the mobile commerce application program 116 of the consumer mobile device 120.; […] In block 414, the server 106, such as the mobile commerce application program 102, can receive a request to download the credit card application associated with the offer from the instant issuance module 228 of the mobile commerce application program 116 of the consumer mobile device 120.; ¶[0082]: [0082] The downloadable credit card application is received at the consumer mobile device 120).
Regarding claim(s) 13,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 9, as shown above.
SANCHEZ further discloses:
comprising: displaying said credit card application at said mobile device (SANCHEZ: ¶[0082]: The downloadable credit card application is received at the consumer mobile device 120. In block 422, credit application prompts are presented on the consumer mobile device 120 by the mobile commerce application program 116. For example, the instant issuance module 228 of the mobile commerce application program 116 can generate and display on the consumer mobile device 120 one or more prompts associated with applying for a credit card or similar product. These prompts can include, for example, radio buttons or fillable fields related to a consumer's personal, financial, and employment information. In block 424, the consumer can input information in response to the displayed prompts at the consumer mobile device 120.).
Regarding claim(s) 14,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 9, as shown above.
SANCHEZ discloses at [0057], the server transaction processing system providing loyalty/reward services; and at [0064], The mobile commerce application program can include a loyalty/rewards module 202), SANCHEZ does not expressly disclose the following limitations, which MATTHEWS however, teaches:
comprising: redeeming a reward at said mobile device, wherein said reward is associated with said credit card account (MATTHEWS: [0047] cardholder to can select preferences to control spending; These preferences may include: s Reward Points as Currency (cardholder 1 can use reward points (e.g. Membership Rewards.TM., Blue Loot.TM.) as currency to pay for purchases; ¶[0034]: The account number may optionally be located on or associated with a rewards card; ¶[0089]: One embodiment of this system, allows a cardholder 1 to create a STN 15 to be used to spend membership rewards points. In general, a membership or incentive rewards program is a loyalty program that rewards cardholders for using their charge card to make purchases. Cardholders accumulate points by using a participating charge card or by purchasing products at a participating merchant. These points may then be converted to a monetary value and redeemed to purchase merchandise.; ¶[0090]: cardholder 1 proceeds indicates that she would like to use her membership reward points that are available in her MR account; ¶[0093]: the cardholder 1 is able to choose to use membership reward points when shopping at a merchant 2 site that supports the membership rewards as a payment option.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SANCHEZ which relates to mobile commerce, and to systems and methods for facilitating the approval and use of a credit account via mobile commerce (see SANCHEZ [0002]), with these teachings from MATTHEWS, which relates to the automated reconciliation of card member spend (MATTHEWS ¶[0002]) in order to allow a user to receive monetary value for accumulated reward points, to encourage cardholder use of an incentive reward program (MATTHEWS: ¶[0089]), and provide a cardholder with the flexibility to use reward points to effectuate a transaction (MATTHEWS ¶[0092]).
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over SANCHEZ (US 20140070001 to Sanchez; J. Scott et al.) in view of ANDERSON (US 9064246 B1 to ANDERSON, K. et al.) in further view of MATTHEWS (US 20120116933 A1 to Matthews; Bradley Owen et al.) and in further view of UBERTI (US 20030046237 A1 to UBERTI, J.) .
Regarding claim(s) 8,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 1, as shown above.
SANCHEZ does not expressly disclose the following limitations, which UBERTI however, teaches:
further comprising: authenticating said user with biometrics prior to said pre-populating said credit card number field with said stored credit card number for said online payment (UBERTI: [0125] The biometric shopping assistant receives a verification biometric sample from the buyer and generates a verification biometric template using the sample as previously described. The biometric shopping assistant transmits the verification biometric template and the transaction value to a server where the verification biometric template is compared to a registration biometric template using the transaction value to determine an acceptance threshold as previously described. If the verification biometric template is verified, then the biometric shopping assistant receives buyer and credit account information that the biometric shopping assistant displays in a transaction information screen 510; [0126] In one embodiment of a biometric shopping assistant in accordance with the present invention, the biometric shopping assistant populates data entry form 400 with the buyer and credit account information; ¶[0121]: a "fill in the form" option that automatically populates each field in any online personal information form; ¶[0033]: Once approved by the financial institution, authenticated applicants are prompted to enroll their biometric information via any biometric device (i.e. voice-scan, finger-scan or keystroke-scan). After enrollment of a biometric identifier, the financial institution approves an amount of credit that is made available for immediate use to the applicant; now buyer, and forwards a biometrically protected credit number for storage within the biometric system at a separate and secure database. Buyers submit biometric identifier(s) to facilitate future online purchases. When prompted for payment information for future online purchases, buyers provide a live biometric sample. A biometric template is extracted on a local client from the buyer's live biometric sample, and transmitted along with a unique account number through a detection server to a biometric clearinghouse computer system for match scoring. If a match occurs, the template code accesses a stored biometric certificate to verify the identity of the individual proposing the transaction; [0034]: A successful verification results in a transaction origination. The biometrically protected credit number and expiration date, which are hosted by the biometric system in a separate and secure database, are supplied to the merchant's Web page and the transaction proceeds as normal. The merchants' payment gateway providers verify this credit account number and expiration date as submitted from the biometric system, and this information proceeds through the normal payment system without any modification. [0035]: the biometric system's biometric credit verification is based on finger-scan biometrics. In other biometric systems in accordance with exemplary embodiments of the present invention, other biometric technologies are used such as such as facial-scans, iris-scan, retinal-scans, voice-scans, and keystroke-scans; ¶[0043]: Simultaneously with buyer identification, the biometric verification interface can automatically detect the payment interface on the e-commerce site. This is to provide a destination for the individual's biometrically protected credit account number and expiration date after the biometric match.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SANCHEZ which relates to mobile commerce, and to systems and methods for facilitating the approval and use of a credit account via mobile commerce (see SANCHEZ [0002]), with these teachings from UBERTI with the motivation of reducing the risk of an unauthorized buyer using a stolen credit card to make purchases online) (see UBERTI ¶[0003]).
Regarding claim(s) 17,
The combination of SANCHEZ, ANDERSON, and MATTHEWS teaches the limitations of claim 9, as shown above.
SANCHEZ does not expressly disclose the following limitations, which UBERTI however, teaches:
further comprising: authenticating said user with biometrics prior to said pre-populating said credit card number field with said stored credit card number for said online payment. (UBERTI [0125] The biometric shopping assistant receives a verification biometric sample from the buyer and generates a verification biometric template using the sample as previously described. The biometric shopping assistant transmits the verification biometric template and the transaction value to a server where the verification biometric template is compared to a registration biometric template using the transaction value to determine an acceptance threshold as previously described. If the verification biometric template is verified, then the biometric shopping assistant receives buyer and credit account information that the biometric shopping assistant displays in a transaction information screen 510; [0126] In one embodiment of a biometric shopping assistant in accordance with the present invention, the biometric shopping assistant populates data entry form 400 with the buyer and credit account information; ¶[0121]: a "fill in the form" option that automatically populates each field in any online personal information form; ¶[0033]: Once approved by the financial institution, authenticated applicants are prompted to enroll their biometric information via any biometric device (i.e. voice-scan, finger-scan or keystroke-scan). After enrollment of a biometric identifier, the financial institution approves an amount of credit that is made available for immediate use to the applicant; now buyer, and forwards a biometrically protected credit number for storage within the biometric system at a separate and secure database. Buyers submit biometric identifier(s) to facilitate future online purchases. When prompted for payment information for future online purchases, buyers provide a live biometric sample. A biometric template is extracted on a local client from the buyer's live biometric sample, and transmitted along with a unique account number through a detection server to a biometric clearinghouse computer system for match scoring. If a match occurs, the template code accesses a stored biometric certificate to verify the identity of the individual proposing the transaction; [0034]: A successful verification results in a transaction origination. The biometrically protected credit number and expiration date, which are hosted by the biometric system in a separate and secure database, are supplied to the merchant's Web page and the transaction proceeds as normal. The merchants' payment gateway providers verify this credit account number and expiration date as submitted from the biometric system, and this information proceeds through the normal payment system without any modification. [0035]: the biometric system's biometric credit verification is based on finger-scan biometrics. In other biometric systems in accordance with exemplary embodiments of the present invention, other biometric technologies are used such as such as facial-scans, iris-scan, retinal-scans, voice-scans, and keystroke-scans; ¶[0043]: Simultaneously with buyer identification, the biometric verification interface can automatically detect the payment interface on the e-commerce site. This is to provide a destination for the individual's biometrically protected credit account number and expiration date after the biometric match.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SANCHEZ which relates to mobile commerce, and to systems and methods for facilitating the approval and use of a credit account via mobile commerce (see SANCHEZ [0002]), with these teachings from UBERTI with the motivation of reducing the risk of an unauthorized buyer using a stolen credit card to make purchases online) (see UBERTI ¶[0003]).
Response to Arguments
35 U.S.C. § 101
Applicant's arguments filed 8 October 2025 have been fully considered but they are not persuasive.
Applicant argues at pages 7-9 that the additional elements include:
storing a credit card number for said credit card account at a remote location and not providing it to said mobile device such that it is not available on said mobile device; and -pre-populating a credit card number field with said stored credit card number for an online payment, wherein said pre-populating is provided by a credit card issuer and not said mobile device.
And that these features related to remote storage and pre-population amount to significantly more.
These arguments have been considered but are unpersuasive. MPEP 2106.05(d)II lists as well-understood, routine, and conventional functions or insignificant extra-solution activity the following:
i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network.
Accordingly, storage and retrieval of credit card information using a remote location does not represent significantly more than the abstract idea. Storing the credit card information remains an abstract idea. Additionally, retrieving credit card information from a remote source can be viewed as insignificant extra-solution activity under MPEP 2106.05(g)(3) and thus fails to integrate the abstract idea into a practical application.
In addition, MPEP 2106(f) lists the following case when determining whether a claim amounts to mere instructions to implement an abstract idea on a computer:
Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017), the steps in the claims described "the creation of a dynamic document based upon ‘management record types’ and ‘primary record types.’" 850 F.3d at 1339-40; 121 USPQ2d at 1945-46. The claims were found to be directed to the abstract idea of "collecting, displaying, and manipulating data." 850 F.3d at 1340; 121 USPQ2d at 1946.
Accordingly, the retrieval and prepopulating features of the claim do not represent significantly more than the abstract idea and amount to no more than instructions to implement an abstract idea of providing credit card information to complete a payment on a computer.
35 U.S.C. § 103
Applicant's arguments filed 8 October 2025 have been fully considered but they are not persuasive.
Applicant argues that the existing references (SANCHEZ and MATTHEWS) do not teach the amended claims including “storing a credit card number for said credit card account at a remote location and not providing it to said mobile device such that it is not available on said mobile device”. Applicant’s arguments with respect to claims 1 and 9 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Amended claims 1 and 9 are now rejected as being unpatentable over SANCHEZ (US 20140070001 to Sanchez; J. Scott et al.) in view of ANDERSON (US 9064246 B1 to ANDERSON, K. et al.) in further view of MATTHEWS (US 20120116933 A1 to Matthews; Bradley Owen et al.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20090289110 A1 to Regen; P. (Wireless Biometric Computer Mouse With Integrated Credit Card Reader) teaches at paragraph [0036]: a Quick-load button on a wireless mouse adapted to enable a user to load data into a Web form without requiring the user to manually type the data into the Web form. For example, when the button is pressed while navigating a Web form a computing appliance hosting the biometric mouse will quickly populate specific data fields of the form with credit card data and personal information like user's name, expiration date of the credit card, the three digit security code provided on the back of credit card, the user's home address, telephone number, and so on. This feature is utilized during an online shopping session such as at a virtual checkout page of an online store and at paragraph [0045]: In one embodiment an encrypted Internet connection is used to transmit the user's fingerprint or thumbprint for matching with information stored in a database set up by the credit card company or third-party service organization. When the scanned biometric data and the stored biometric data are same, information is then released and sent back to the user's computer where it is displayed including the credit card data and particulars of the user such as contact information and the like that typically is submitted with the credit card information in an online purchase form.
US 20160148309 A1 to CANAPINI; T et. Al (Systems and Methods for Onsite or Remote Dispensing of Credit Instruments) teaches storing a digital credit card associated with said a card account at a mobile device via text messaging
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BOLKO HAMERSKI whose telephone number is (571)270-7621. The examiner can normally be reached Monday-Friday 10:00 AM to 6:00 PM.
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, BENNETT SIGMOND can be reached at (303) 297-4411. 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.
BOLKO HAMERSKI
Examiner
Art Unit 3694
/BOLKO M HAMERSKI/ Examiner, Art Unit 3694
/BENNETT M SIGMOND/ Supervisory Patent Examiner, Art Unit 3694