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 filed December 16, 2025. Claims 1-4, 6-11, 13-19, 22-24, and 27, are pending in this case. Claims 24 -27 are newly added. Claims 5, 12, and 20-21 were previously canceled. Claims 25-26 are currently canceled. Claims 1, 7, 9, 15, 17, 23, 24, and 27 are currently amended.
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 December 16, 2025, has been entered.
Response to Arguments
Applicant's arguments filed December 16, 2025, have been fully considered but they are not persuasive.
Applicant argues, regarding claims 1, 9, and 15, as currently amended, that nothing in the cited references teaches, discloses, or suggests indicating a plurality of validity rules that restrict a usability of the temporary payment card information, wherein the plurality of validity rules include a plurality of validity criteria to be satisfied prior to approval of the transaction, and wherein the plurality of validity criteria includes at least one of: a maximum transaction amount, a maximum number of transactions, a restriction that limits usability of the temporary payment card to the merchant, or an expiration time.
Examiner respectfully disagrees.
Attention is directed to Sandstrom at par 5 “validating the time-limited number for the transaction based on the digits indicating the expiration date . . . .”, par 58 “allocate 50,000 of the available numbers to be used as single-use payment card numbers . . . If the number has not been involved in a previous transaction, the financial institution authorizes the current transaction and removes the number from the list of useable numbers. Otherwise, the transaction is rejected . . .” where single use is a validity rule/criterion which is satisfied then the number has not been previously used.
Further attention is directed to Sandstrom at par 31-33 “user device 12 (FIG. 1) transmits information capable of identifying the user, other than information corresponding to the user's payment card number, along with the time-limited number. The other information could be a device signature, such as a service-subscriber or international mobile subscriber identity (“IMSI”). . . . financial institution software normalizes the date on which the payment card transaction was effected to 00:00:00 GMT in a manner identical to that described above with respect to step 114. At step 144, the financial institution software calculates the number of days between the normalized transaction-effected date and the payment card's expiration date. At step 146, the software extracts the last five digits of the PAN of the alternate number and, at step 148, compares the extracted digits to the number of days determined at step 144. If the number of days calculated at step 144 is less than the extracted five digits, this indicates that the alternate, time-limited number has expired. The transaction is thus rejected at step 136. Otherwise, the transaction is authorized at step 150.”
Note that at least two (2) rules must be met for met for the transaction to be approved --- the user device must be correctly identified and the time-limited number must be un-expired or still-valid.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6-7, 9-11, 13-17, 19, and 22-27, are rejected under 35 U.S.C. 103 as being unpatentable over Mogollon et al (US 2013/0346314) in view of Scipioni et al (US 2009/0132417), Sandstrom et al (US 2010/0089998), and Hoffman et al (EP 1 117 035 A1).
Regarding claims 1, 9 and 15 –
Mogollon discloses receiving, at the service provider and from the service provider hardware, a request to perform a transaction with the merchant via a user account associated with the user device; (par 27-29 “User 102 may interact with a merchant point of sale, such as merchant 104 website/webpage. User 102 may select items for purchase from the merchant 104 website/webpage. At any point, once third party web browser application 150 is enabled, user 102 may log on to third party web browser application 150 to access secure preference information and/or to enable various personalized enhanced capabilities of third party web browser application 150 application” at par 27)
generating, by the service provider, based at least in part on the request and in near real-time, temporary payment card information associated with the user account, (see, par 50 with respect to temporary/proxy account information; also “At any point, once third party web browser application 150 is enabled, user 102 may log on to third party web browser application 150 to access secure preference information and/or to enable various personalized enhanced capabilities of third party web browser application (par 27) ... 102 may select a particular transaction account designator, such as a by accessing a virtual icon displayed by third party web browser application 150 (step 1105). This may prompt third party web browser application 150 to automatically populate various fields of the merchant checkout website with data associated with the selected transaction account (par 29) ...User 102 may input the DSC in the security code field on the merchant webpage (step 1145). According to various embodiments, the transaction account issuer system 140 message may automate this inputting...” (par 36, also par 26-29, 36)) the temporary payment card information:
representing a temporary payment card using a payment card number, an expiration date, and a verification value; (“The personalized web browsing application may be configured to perform electronic form filling. The method may include generating the dynamic security code, and determining the contact information of a holder of a transaction account associated with the request to generate a dynamic security code (par 14) ... to complete the transaction (e.g. to make a purchase) such as by using third party web browser application 150. (par 25) “When communicating with merchant 104 through a mobile device or a computer user 102 may provide information associated with a transaction instrument (e.g., transaction account number or code, expiration date, account name, and billing address) to merchant 104 to complete a transaction.” (par 26) “Third party web browser application 150 may determine the transaction account issuer 140 of the transaction account selected (step 1110)... (par 30) Third party web browser application 150 may transmit identification information, such as a user name, proxy user identifier, transaction account identifier, and/or the like (par 32) ...issuer 140, may issue a proxy account number to be populated by third party web browser application 150...” (par 50))
sending, by the service provider and responsive to the request to perform the transaction with the merchant, the temporary payment card information to the user device (par 14 “financial institution computer based system receiving a request to generate a dynamic security code from a personalized web browsing application. The personalized web browsing application may be configured to perform electronic form filling. The method may include generating the dynamic security code, and determining the contact information of a holder of a transaction account associated with the request to generate a dynamic security code” (where dynamic security code = temporary payment card information); also par 23, 26-30, “At any point, once third party web browser application 150 is enabled, user 102 may log on to third party web browser application 150 to access secure preference information and/or to enable various personalized enhanced capabilities of third party web browser application... 102 may select a particular transaction account designator, such as a by accessing a virtual icon displayed by third party web browser application 150 (step 1105). This may prompt third party web browser application 150 to automatically populate various fields of the merchant checkout website with data associated with the selected transaction account.”)
automatically populating, by the service provider, at least a portion of the temporary payment card information into a plurality of fields of the user interface; (par 23, 26-30, “At any point, once third party web browser application 150 is enabled, user 102 may log on to third party web browser application 150 to access secure preference information and/or to enable various personalized enhanced capabilities of third party web browser application... 102 may select a particular transaction account designator, such as a by accessing a virtual icon displayed by third party web browser application 150 (step 1105). This may prompt third party web browser application 150 to automatically populate various fields of the merchant checkout website with data associated with the selected transaction account.”)
receiving, from the merchant, a request to approve the transaction, the request comprising at least the portion of the temporary payment card information. (par 39 “the transaction account issuer 140 may transmit separate authorization responses to the merchant 104 and user 102.”)
Sandstrom discloses, as Mogollon does not, and in analogous art, indicating a plurality of validity rules that restrict a usability of the temporary payment card information, wherein the plurality of validity rules include a plurality of validity criteria to be satisfied prior to approval of the transaction, and wherein the plurality of validity criteria includes at least one of: a maximum transaction amount, a maximum number of transactions, a restriction that limits usability of the temporary payment card to the merchant, or an expiration time. (par 5 “validating the time-limited number for the transaction based on the digits indicating the expiration date . . . .”, par 58 “allocate 50,000 of the available numbers to be used as single-use payment card numbers . . . If the number has not been involved in a previous transaction, the financial institution authorizes the current transaction and removes the number from the list of useable numbers. Otherwise, the transaction is rejected . . .” where single use is a validity rule/criterion which is satisfied then the number has not been previously used, also par 31-33 “user device 12 (FIG. 1) transmits information capable of identifying the user, other than information corresponding to the user's payment card number, along with the time-limited number. The other information could be a device signature, such as a service-subscriber or international mobile subscriber identity (“IMSI”). . . . financial institution software normalizes the date on which the payment card transaction was effected to 00:00:00 GMT in a manner identical to that described above with respect to step 114. At step 144, the financial institution software calculates the number of days between the normalized transaction-effected date and the payment card's expiration date. At step 146, the software extracts the last five digits of the PAN of the alternate number and, at step 148, compares the extracted digits to the number of days determined at step 144. If the number of days calculated at step 144 is less than the extracted five digits, this indicates that the alternate, time-limited number has expired. The transaction is thus rejected at step 136. Otherwise, the transaction is authorized at step 150.” Note that at least two (2) rules must be met for met for the transaction to be approved --- the user device must be correctly identified and the time-limited number must be un-expired or still-valid.
verifying, by the service provider, that the transaction satisfies the plurality of validity rules based on plurality of validity criteria; (par 5, 58, also par 31-33, as above) and
approving the transaction based at least in part on the transaction satisfying the plurality of validity rules. (par 5, 58, also par 31-33, as above)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more secure temporary card.
Mogollon does not specifically disclose publishing, by service provider hardware that operates in a user device, a user interface at the user device, wherein the user interface displays a control to obtain temporary payment card information via a service provider associated with the service provider hardware, the service provider being remote from a merchant and being configured to facilitate transactions involving user accounts of users of the service provider.
However, Hoffman discloses, in analogous art, publishing, by service provider hardware that operates in a user device, a user interface at the user device (par 179, “ . . publish an interface in another environment. That means an interface is mapped from a source environment to a target environment so that methods may be invoked on a mapped interface in the target environment.”)
It would be obvious to one of ordinary skill in the art to combine Mogollon with the published interface of Hoffman for enhanced user ease.
Scipioni discloses, as Mogollon does not, wherein the user interface displays a control to obtain temporary payment card information via a service provider associated with the service provider hardware, the service provider being remote from a merchant and being configured to facilitate transactions involving user accounts of users of the service provider. (Par 9, 11, abs)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Hoffman, with the interface functions of Scipioni for greater user ease.
Mogollon does not specifically disclose publishing, by service provider hardware that operates in a user device, a user interface at the user device, wherein the user interface displays a control to obtain temporary payment card information via a service provider associated with the service provider hardware, the service provider being remote from a merchant and being configured to facilitate transactions involving user accounts of users of the service provider.
However, Hoffman discloses, in analogous art, publishing, by service provider hardware that operates in a user device, a user interface at the user device (par 179, “ . . publish an interface in another environment. That means an interface is mapped from a source environment to a target environment so that methods may be invoked on a mapped interface in the target environment.”)
It would be obvious to one of ordinary skill in the art to combine Mogollon with the published interface of Hoffman for enhanced user ease.
Scipioni discloses, as Mogollon does not, wherein the user interface displays a control to obtain temporary payment card information via a service provider associated with the service provider hardware, the service provider being remote from a merchant and being configured to facilitate transactions involving user accounts of users of the service provider. (Par 9, 11, abs)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Hoffman, with the interface functions of Scipioni for enhanced user ease.
Regarding claim 2 –
Sandstrom discloses that generating the temporary payment card information is based at least in part on receiving previous user input requesting use of the temporary payment card information. (par 18-20, 34-35)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for better and more flexible temporary card.
Regarding claim 3 –
Sandstrom discloses that generating the temporary payment card information is based at least in part on determining that a payment instrument is unassociated with the user account when the request is received. (par 18-20, 34-35)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for better and a more flexible temporary card.
Regarding claim 4 –
Sandstrom discloses that generating the temporary payment card information is based at least in part on determining that a payment instrument of the service provider is absent from the user account when the request is received. (par 18-20, 34-35)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card.
Regarding claim 6 –
Sandstrom discloses receiving, from a merchant device of the merchant, an indication that the temporary payment card information has been utilized to satisfy a cost of the transaction; (par 58)
determining the user account associated with the temporary payment card information; (par 58) and
withdrawing funds equal to the cost from the user account. (par 58)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card.
Regarding claim 7 –
Sandstrom discloses wherein the plurality of validity rules include a first validity criterion that indicates that the temporary payment card information is valid for exactly one transaction, (par 58) and further comprising:
determining that the temporary payment card information has yet to be used, (par 58) wherein sending the temporary payment card information is based at least in part on the temporary payment card information not yet being used. (par 58)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card for greater ease by the user.
Regarding claim 10 –
Mogollon teaches wherein, prior to sending the temporary payment card information to the user device: a merchant interface is presented in association with a payment application on the user device, wherein the merchant interface is associated with the merchant. (par 46).
Regarding claim 11 –
Mogollon teaches that the merchant interface is associated with a merchant ecommerce website; (par 46) and
sending the temporary payment card information comprises sending the temporary payment card information to the merchant ecommerce website. (par 46)
Regarding claim 13 -
Sandstrom teaches wherein generating the temporary payment card information is based at least in part on receiving the user input data. (par 18-20, 34-35)
Scipioni discloses causing display, on the merchant interface, of a selectable element; (par 11, 47,52)
receiving user input data indicating selection of the selectable element. (par 11, 47,52)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom with the elements of Scipioni for enhanced user ease.
Regarding claim 14 –
Mogollon teaches the operations further comprising:
in response to receiving the request, requesting authentication input from a user associated with a user account; (par 49, 63) and
receiving the authentication input; (par 49, 63)
wherein sending the temporary payment card information is based at least in part on receiving the authentication input. (par 49, 63)
Regarding claim 16 –
Mogollon teaches that the merchant interface is associated with a merchant ecommerce website; (par 46) and sending the temporary payment card information comprises sending the temporary payment card information to the merchant ecommerce website. (par 46)
Regarding claim 17 –
Sandstrom discloses wherein the plurality of validity rules include a first validity criterion that indicates indicating that the temporary payment card information is valid for exactly one transaction (par 58), and further comprising:
determining that the temporary payment card information has yet to be used, wherein sending the temporary payment card information is based at least in part on the temporary payment card information not yet being used. (par 58)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card for greater ease by the user.
Regarding claim 19 –
Sandstrom discloses wherein generating the temporary payment card information is based at least in part on determining that a payment instrument of the service provider is absent from the user account when the request is received. (par 18-20, 34-35)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card for greater ease by the user.
Regarding claim 22 –
Sandstrom discloses wherein the temporary payment card information corresponds to a real payment card that is associated with the user account. (par 20)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more secure temporary card.
Regarding claim 23 –
Sandstrom discloses determining a number of transactions for which the temporary payment card is valid based at least in part on an association between the payment card number and the plurality of validity rules comprising the number of transactions for which the temporary payment card is valid; (par 58) and
responsive to an actual number of transactions associated with the temporary payment card satisfying the number of transactions for which the temporary payment card is valid, authorizing transfer of funds equal to a cost of the transaction based at least in part on real payment card information associated with the user account. (par 58)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more secure temporary card.
Regarding claims 24 and 17 –
Mogollon in view of Sandstrom fails to expressly disclose wherein the plurality of at least one validity criteria includes a maximum individual or collective transaction amount.
However, the difference between one validity rule or another are only found in the non-functional descriptive material and are not functionally involved in the steps recited. In other words, it has to do with whether one rule or another is being met, not what the rule is. The various steps 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, 70 USPQ2d 1862 (CAFC 2004); In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
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 one rule or another 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.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mogollon et al (US 2013/0346314) in view of Scipioni et al (US 2009/0132417), Hoffman et al (EP 1 117 035 A1), and Sandstrom et al (US 2010/0089998) and further in view of Mukherjee (US 2012/0259768).
Mogollon, in view of Sandstrom, Hoffman, and Scipioni, teaches as above.
Regarding claim 8 –
Mukherjee discloses that generating the temporary payment card information is based at least in part on an indication that the merchant corresponds to a predetermined merchant and the transaction is set to occur at a predetermined time. (par 24, 49)
It would be obvious for one of ordinary skill in the art to combine Mogollon, Sandstrom, Hoffman, and Scipioni, with Mukherjee for better control over finances.
Regarding claim 18 -
Mukherjee teaches wherein generating the temporary payment card information is based at least in part on an indication that the merchant corresponds to a predetermined merchant and the transaction is set to occur at a predetermined time. (par 24, 49)
It would be obvious for one of ordinary skill in the art to combine Mogollon, Sandstrom, Hoffman, and Scipioni, with Mukherjee for better control over finances.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CRISTINA OWEN SHERR whose telephone number is (571)272-6711. The examiner can normally be reached 8:30 - 5: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, 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.
/Cristina Owen Sherr/Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697