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 May 26, 2026, has been entered.
Status of Claims
Applicant filed an amendment on May 26, 2026. Claims 1-22 were pending in the Application. Claim 1 has been amended. Claim 14 has been canceled, with claims 15-20 remaining withdrawn. No new claims have been added. Claim 1 is the independent claim, the remaining claims depend on claim 1. Thus claims 1-13 and 21-22 are currently pending. After careful and full consideration of Applicant arguments and amendments, the Examiner finds them to be moot and/or not persuasive.
Response to Arguments
In the context of 35 U.S.C. §101, Applicant respectfully disagrees with and respectfully traverses the rejection. Applicant is of the opinion that the claims are statutory and respectfully asserts that “the amended claims provide multiple technological improvements to technical problems arising in the secure payment industry, thus preempting the need for further analysis with regard to §101; Step 2A (Prong One): Applicant's Claims Do Not Recite an Abstract Idea; under Prong One, Applicant's claims do not recite a judicial exception and at most, involve, an abstract idea; the pending claims do not recite a "commercial or legal interaction" nor any other "certain method of organizing human activity" as defined by MPEP § 2106.04(a)(2)(II)(B); Applicant’s claims neither directly state nor describe any of the concepts of a contract, legal obligation, marketing or sales activities, or business relations; the present claims recite an improvement to an application on a mobile device and user interface to reduce and isolate fraud, not any commercial and legal interaction within the meaning of MPEP§ 2106.04(a)(2)(II)(B); providing enhanced fraud protections (for instance, when using a unique access token containing an entity identification code associated with an entity) is not a "commercial or legal interaction"; methods of providing enhanced fraud protections based on different conditions is not analogous to any of the examples of abstract “commercial or legal interactions” provided under MPEP § 2106.04(a)(2)(II)(B); under Step 2A (Prong Two): Applicant's Claims Recite a Practical Application; using computer hardware and software to reduce fraud and improve secure transactions is a practical application; the limitations in amended claim 1, in combination, recite specific steps for authorizing transactions by using an identifier provided by a point-of-sale device that goes on to match the entity identification code stored in the unique access token; the present claims are an improvement for reducing fraud exposure by making it easier for merchants and financial institutions to isolate and contain suspicious activity at the individual location level; the present claims integrate the alleged judicial exception into a practical application and are patent eligible at Step 2A Prong One and Prong Two; under Step 2B: The Claims, as a Whole, Recite "Significantly More" than the Alleged Abstract Idea; even assuming the pending claims were determined to be directed to a judicial exception, which Applicant does not concede, the claims would still be patent eligible at Step 2B; the claims do amount to more than generally linking the abstract idea to a technological environment; claim 1 recites a specific method of using unique access tokens associated with a geographic location and containing an entity identification code to present and issue a selected arrangement, which, when considered in an ordered combination, are not generally linking the abstract idea to a technological environment; the recitations of the claims also go beyond what is “well understood, routine and conventional”; the Office's analysis does not consider the specific requirements in the claimed combination of steps, now further in view of the amendments presented; by dismissing the claim elements as allegedly abstract, and labeling the identified additional elements as known or generic devices individually, the Office failed to fully consider the inventive concept; a proper analysis at Step 2B demonstrates that Applicant's claims recite significantly more because the claims have "additional elements that amounted to significantly more than the abstract idea." MPEP. § 2106.05(d); amended claim 1 has specific additional claim elements that provide significantly more by improving the technology in the field of secure transactions; the present claims are an improvement for reducing fraud exposure by making it easier for merchants and financial institutions to isolate and contain suspicious activity at the individual location level; amended claim 1 recites "significantly more" than the alleged abstract idea and for this additional reason is patent-eligible; the Office Action's Allegation that the Claims Recite a "Commercial Interaction" is Conclusory; while the Office recites and makes reference to many claim elements collectively, the Office does not explain how the claim language of any claim element recites a "commercial interaction" of "location based payment options"; the Office has failed to "identify and evaluate each claim limitation," and instead relied purely on conclusory assertions that the referenced claim elements collectively recite a commercial interaction; and that the Office has not provided a prima facie case to support its conclusion that the claims of the present application are directed to non-statutory subject matter in light of the decision in Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 134 S. Ct. 2347 (2014).”
Initially, the Examiner would like to point out that the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106, which applies a two-step framework, earlier set out in Mayo Collaborative Services v. Prometheus Laboratories, Inc., 566 U.S. 66 (2012), "for distinguishing patents that claim laws of nature, natural phenomena, and abstract ideas from those that claim patent-eligible applications of those concepts." Alice, 573 U.S. at 217.
Under the two-step framework, it must first be determined if "the claims at issue are directed to a patent-ineligible concept." If the claims are determined to be directed to a patent-ineligible concept, e.g., an abstract idea, then the second step of the framework is applied to determine if "the elements of the claim ... contain an "inventive concept" sufficient to 'transform' the claimed abstract idea into a patent-eligible application." (citing Mayo, 566 U.S. at 72-73, 79).
With regard to step one of the Alice framework, we apply a "directed to" two-prong test: 1) evaluate whether the claim recites a judicial exception, and 2) if the claim recites a judicial exception, evaluate whether the claim "applies, relies on, or uses the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception," i.e., whether the claim integrates the judicial exception into a practical application. (MPEP §2106.04 II.A.1. and II.B.2.).
The specification, (para 1), provides evidence as to what the claimed invention is directed. In this case, the specification, (para 1), discloses that the invention relates to generating a variety of banking arrangement options with a geographically distinct entity, and is grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)”, and is grouped under “Certain Methods of Organizing Human Activity, fundamental economic principles or practices (including hedging, insurance, mitigating risk)”, in prong one of step 2A. (MPEP §2106.04 II.A.1.).
Claim 1 provides additional evidence, and recites the limitations “A non-transitory computer readable medium containing instructions that, when executed by at least one processor, cause the at least one processor to generate a variety of arrangement options for use with an entity at a unique geographic location, the instructions comprising: providing a unique token at the unique geographic location, wherein the unique token is associated with the entity and contains an entity identification code such that access to the unique token is limited to geographic locations associated with the unique token; receiving a request for an arrangement, wherein the request is transmitted from a mobile device associated with a requestor; querying a first database for a first information associated with the requestor; receiving the first information associated with the requestor, wherein the first information includes one or more of a name, address, date of birth, and an identification number; querying, using the first information associated with the requestor, a second database; receiving a second information associated with the requestor from the second database; generating the variety of arrangement options, wherein the variety of arrangement options is determined using one or more of the first information, the second information, and the unique token; presenting the variety of arrangement options to the requestor; receiving an input from the requestor, wherein the input is indicative of a selected arrangement within the variety of arrangement options; querying, using the first information associated with the requestor, a third database; receiving a third information associated with the requestor from the third database; issuing the selected arrangement based on the input from the requestor and the third information, wherein the selected arrangement includes a borrowed amount and repayment terms, and wherein the selected arrangement is issued for use by the requestor with the entity associated with the unique token; generating a virtual card based on the selected arrangement, wherein the virtual card is added to the mobile device or a point-of-sale device and the virtual card enables transactions initiated by the requestor at the unique geographic location; receiving a signal from a device at the unique geographic location indicating that the virtual card was used by the requestor in the entity at the unique geographic location; wherein a transaction initiated using the virtual card is authorized after determining that an identifier provided by a point-of-sale device matches the entity identification code encoded in, or derived from, the unique token; and deactivating the virtual card by removing the virtual card from the mobile device's application or marking the virtual card as inactive”, where the italicized claim language represents the abstract idea of “location based payment options”, and the bolded claim language represents the additional elements (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “a non-transitory computer readable medium containing instructions that, when executed by at least one processor, cause the at least one processor …”, “a first database”, “a second database”, “presenting the variety of arrangement options to the requestor”, “a third database”, “generating a virtual card based on the selected arrangement, wherein the virtual card is added to the mobile device or a point-of-sale device and the virtual card”, “a signal from a device”, “a point-of-sale device”, and “deactivating the virtual card by removing the virtual card from the mobile device's application or marking the virtual card as inactive”, amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “location based payment options.”
Examiner notes the basis of the rejection was, and is not as any mental process covering performance in the mind, but classified as an abstract idea, “location based payment options”, grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)”, and grouped under “Certain Methods of Organizing Human Activity, fundamental economic principles or practices (including hedging, insurance, mitigating risk)”.
With respect to the additional elements operating in a non-conventional and non-generic way and reflecting an improvement to a particular technological environment, the cited additional elements represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “location based payment options.” The claim is not directed to improving computers or related technologies, but improving the abstract idea “location based payment options”. For potential improvement in an abstract idea, “location based payment options”, it is important to keep in mind that an improvement in the abstract idea itself (e.g. a location based payment options concept) is not an improvement in technology. (MPEP § 2106.04(d)(1)). Therefore, claim 1 is non-statutory.
Finally, Examiner notes the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106. And, based on this standard, the claims are non-statutory, and correctly rejected under 35 U.S.C. § 101.
In the context of 35 U.S.C. § 103, Applicant respectfully submits that, solely to advance prosecution and without acquiescing to the rejection, Applicant amends claim 1 to further distinguish the claims over the cited references. None of the cited references teach or suggest the newly recited claim elements. Amended independent claim 1 now recites, for example "providing … and contains an entity identification code such that access to the unique token is limited to geographic locations associated with the unique token", "issuing …, and wherein the selected arrangement is issued for use by the requestor with the entity associated with unique token ," and "wherein a transaction initiated using the virtual card is authorized after determining that an identifier provided by a point-of-sale device matches the entity identification code encoded in, or derived from, the unique token". Anderson, the primary reference used in all the rejections, fails to disclose or suggest at least the above-recited subject matter. The amended claims now make clear that device-derived location information does not disclose or suggest a unique token that is associated with a particular entity, contains an entity identification code, and limits access to that token (and downstream transaction authorization) based on a matching entity identifier.
While the claims as originally drafted associated the token with a unique geographic location, the present amendments clarify that the token is not merely a proxy for location data. Rather, the token functions as a merchant or entity specific credential, encoded with an entity identification code that must be matched with a point-or-sale identifier before a transaction is authorized. Anderson does not disclose or suggest a transaction-authorization mechanism that requires a match between a point-of-sale-provided identifier and an entity identification code embedded in or derived from a token issued at or for a specific entity.
While the Examiner only cites Anderson for its “location information”, the other cited references of Matthews, Jung, and Zakaras also fail for the same reasons. Even if these references are considered alongside Anderson, they do not reflect the presently claimed arrangement in which transaction authorization is gated on a match between a point-of-sale-provided identifier and an entity identification code encoded in, or derived from, a unique token associated with the entity.
Therefore, neither Anderson, Matthews, Jung, nor Zakaras (alone or in combination) teach or suggest the newly recited elements of amended claim 1, from which claims 2-13 and 21-22 depend.
Examiner finds the applicant arguments moot in view of new grounds of rejection, and therefore, amended claim 1 is not patentable. Amended claim 1 stands rejected under 35 U.S.C §103 in the analysis below, and is therefore, not patentable in view of Laracey (US 20130238455 A1) now applying to the applicable amended sections for claim 1. Therefore, amended claim 1 stands rejected under 35 U.S.C. § 103. Claims 2-13 and 21-22, which depend on claim 1, also stand rejected under 35 U.S.C. § 103. The current rejection under 35 U.S.C. § 103 for claims 1-13 and 21-22 is maintained.
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-13 and 21-22 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 1-13 and 21-22 are directed to a “non-transitory computer readable medium”. Therefore, these claims are directed to one of the four statutory categories of invention.
Claim 1 recites “location based payment options”, which is a form of commercial and legal interaction and a form of fundamental economic principles or practices (i.e., organizing human activity), and therefore, an abstract idea. Specifically, the claim recites “A non-transitory computer readable medium containing instructions that, when executed by at least one processor, cause the at least one processor to generate a variety of arrangement options for use with an entity at a unique geographic location, the instructions comprising: providing a unique token at the unique geographic location, wherein the unique token is associated with the entity and contains an entity identification code such that access to the unique token is limited to geographic locations associated with the unique token; receiving a request for an arrangement, wherein the request is transmitted from a mobile device associated with a requestor; querying a first database for a first information associated with the requestor; receiving the first information associated with the requestor, wherein the first information includes one or more of a name, address, date of birth, and an identification number; querying, using the first information associated with the requestor, a second database; receiving a second information associated with the requestor from the second database; generating the variety of arrangement options, wherein the variety of arrangement options is determined using one or more of the first information, the second information, and the unique token; presenting the variety of arrangement options to the requestor; receiving an input from the requestor, wherein the input is indicative of a selected arrangement within the variety of arrangement options; querying, using the first information associated with the requestor, a third database; receiving a third information associated with the requestor from the third database; issuing the selected arrangement based on the input from the requestor and the third information, wherein the selected arrangement includes a borrowed amount and repayment terms, and wherein the selected arrangement is issued for use by the requestor with the entity associated with the unique token; generating a virtual card based on the selected arrangement, wherein the virtual card is added to the mobile device or a point-of-sale device and the virtual card enables transactions initiated by the requestor at the unique geographic location; receiving a signal from a device at the unique geographic location indicating that the virtual card was used by the requestor in the entity at the unique geographic location; wherein a transaction initiated using the virtual card is authorized after determining that an identifier provided by a point-of-sale device matches the entity identification code encoded in, or derived from, the unique token; and deactivating the virtual card by removing the virtual card from the mobile device's application or marking the virtual card as inactive”. The abstract idea is in italics, and the additional elements are in bold. (MPEP § 2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional element of the claim, such as “a non-transitory computer readable medium containing instructions that, when executed by at least one processor, cause the at least one processor …”, “a first database”, “a second database”, “presenting the variety of arrangement options to the requestor”, “a third database”, “generating a virtual card based on the selected arrangement, wherein the virtual card is added to the mobile device or a point-of-sale device and the virtual card”, “a signal from a device”, “a point-of-sale device”, and “deactivating the virtual card by removing the virtual card from the mobile device's application or marking the virtual card as inactive”, amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “location based payment options.”
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of “location based payment options” using computer technology (e.g., “a non-transitory computer readable medium” and “at least one processor”). Therefore, the additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 1 is non-statutory.
Dependent claims 2-13 and 21-22 further describe the abstract idea of “location based payment options”, which is insufficient to overcome the rejection of claim 1.
Dependent claims 2-13 and 21-22 do not recite any new additional elements that integrate the abstract idea into a practical application, and that do no more than represent a computer performing functions that correspond to implementing the acts of “location based payment options”, when analyzed under Step 2A, Prong Two. Under Step 2B, when taken, alone or in ordered combination, they do not amount to significantly more than the abstract idea alone.
Hence, claims 1-13 and 21-22 are not patent eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. § 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. § 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-13 and 21-22 are rejected under 35 U.S.C. § 112(a) or 35 U.S.C. § 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. § 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
New Matter
Claim 1 recites “wherein a transaction initiated using the virtual card is authorized after determining that an identifier provided by a point-of-sale device matches the entity identification code encoded in, or derived from, the unique token; and …” The specification does not adequately inform one of ordinary skill how the limitation “a transaction initiated using the virtual card is authorized after determining that an identifier provided by a point-of-sale device matches the entity identification code encoded in, or derived from, the unique token” is to be performed. Specification, para 86, recites “… Upon receiving this request, the POS device may encrypt and transmit the received card information, transaction amount, and merchant identifier to a financial institution computing system. The financial institution computing system may evaluate the transaction details and send an authorization response back to the POS device. The authorization response may be encrypted with secured communication. Simultaneously, the financial institution computing system may also transmit the authorization response to the mobile wallet application …”, which discloses the financial institution computing system evaluating the transaction details and sending an authorization response back to the POS device, but does not disclose a transaction initiated using the virtual card is authorized after determining that an identifier provided by a point-of-sale device matches the entity identification code encoded in, or derived from, the unique token.
Thus, specification, para 86, does not disclose a transaction initiated using the virtual card is authorized after determining that an identifier provided by a point-of-sale device matches the entity identification code encoded in, or derived from, the unique token. Therefore, this is an issue of new matter, which is matter not present on the filing date of the application in the specification, claims, or drawings that has been added after the application filing. Dependent claims 2-13 and 21-22, which depend from claim 1, are also similarly rejected. (MPEP § 2163.06 I).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. § 102 and § 103 (or as subject to pre-AIA 35 U.S.C. § 102 and § 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U. S. 1. 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-11 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson et al (U. S. Patent Application Publication No. 20230004951 A1), herein referred to as Anderson, in view of Matthews et al (U. S. Patent Application Publication No. 20230087384 A1), herein referred to as Matthews, and in further view of Laracey (U. S. Patent Application Publication No. 20130238455 A1), herein referred to as Laracey.
As per claim 1, Anderson discloses a non-transitory computer readable medium (FIG. 9, item 902; para 267, “FIG. 9, portions of the technology for providing a communication composed of computer-readable and computer-executable instructions that reside, for example, in non-transitory computer-readable medium for storing instructions of a computer system …”; para 268, “… As shown in FIG. 9, computer system 900 of FIG. 9 is well adapted to having peripheral computer read-able media 902 such as, for example, an external hard drive, a compact disc, a flash drive, a thumb drive, a wireless radio enabled device, and the like coupled thereto …”) containing instructions that, when executed by at least one processor (FIG. 9, item 906A, 906B, 906C; para 269, “… a processor 906A coupled to bus 904 for processing information and instructions … FIG. 9, system 900 is also well suited to a multi-processor environment in which a plurality of processors 906A, 906B, and 906C are present … system 900 is also well suited to having a single processor such as, for example, processor 906A. Processors 906A, 906B, and 906C may be any of various types of microprocessors. Computer system 900 also includes data storage features such as a computer usable volatile memory 908, e.g., random access memory (RAM), coupled to bus 904 for storing information and instructions for processors 906A, 906B, and 906C …”; para 270, “System 900 also includes computer usable non-volatile memory 910, e.g., read only memory (ROM), coupled to bus 904 for storing static information and instruc-tions for processors 906A, 906B, and 906C … in system 900 is a data storage unit 912 (e.g., a magnetic disk drive, optical disk drive, solid state drive (SSD), and the like) coupled to bus 904 for storing information and instructions …”), cause the at least one processor to generate a variety of arrangement options for use with an entity at a unique geographic location, the instructions comprising:
providing a unique token at the unique geographic location, wherein the unique token is associated with the entity at the unique geographic location (FIG. 8B, items 803, 851, 852, 853, 854; para 169, “… the transaction could also include information from the device such as customer biometric information, location information (e.g., provided by GPS 118), the transaction time, the transaction date, etc. … the location information provided by the mobile device 110 will include time and date stamp information … the location, time and/or date could be obtained from the POS 104, a combination of the customer's mobile device 110 and the POS 104, etc. …”; para 170, “… for the transaction to occur, BNPL product pass 170 would be validated using the internet connection from the POS 104, the biometric infor-mation for the customer (as provided via a token or the like) from the customer's mobile device 110, the location obtained from GPS 118, the time, the date of the transaction initiation, the mobile device identification number, etc. …”; para 175, “… BNPL offer 105 is provided via a beacon such as one or more of beacons 103-1 through 103-n. In another embodiment, BNPL offer 105 is provided by an application on the customer's mobile device 110 after the customer's mobile device 110 is determined to be in store 100, within range of beacon 103-1 and/or 103-n. In yet another embodiment, the offer is provided on the customer's mobile device 110 when a location capability of the customer's mobile device 110 determines that the customer 101 is located near store 100 …”; para 232, “With reference now to 851 of FIG. 8B … obtains authorization for the BNPL product provider 230 to access location information 803 about the BNPL application …”; para 233, “With reference now to 852 of FIG. 8B, one embodiment receives, at the computer system location information 803 about the BNPL application … the location information 803 generated by a positioning system tracking such as GPS 118 on the mobile device 110 …”; para 238, “At 854, location information 803 includes real-time location information obtained from the positioning system. Real-time location information would be location information 803 that is generated in real time by the positioning system. The real-time location information would be constantly replaced as location information 803 generated by the positioning system received at the computer system, e.g., location information evaluator 804 ...”), …;
receiving a request for an arrangement, wherein the request is transmitted from a mobile device associated with a requestor (FIG. 7, item 705; para 174, “At 705, one embodiment receives an inquiry about a BNPL product for a customer 101, the inquiry including identification information for the customer … the inquiry is initiated when the customer interacts with BNPL offer 105 (of FIG. 1) which may be provided by the entrance 102 to store 100, in a section of the store such as a furniture, clothing, shoes or the like … BNPL offer 105 may be presented on a physical item such as a poster, or the like and include a visual code such as a barcode, QR code, or the like. As such, BNPL offer 105 may be scanned by the customer 101 with the customer's mobile device …”);
querying a first database for a first information associated with the requestor (FIG. 3, item 16; para 77, “… the device ID 216 and user ID 218 information to perform a proprietary search 5 of at least one proprietary database 16 … the proprietary database 16 may be one or more databases such as a credit accounts database, or the like, that store a company's private database such as an Alliance Data Legacy database or the like. Proprietary database 16 will include user specific information 223 for customers that have existing accounts with the company, have previously applied for an account, or the like …”; para 80, “… the search would use an internal account holder proprietary database 16 to see if the customer has another account within the shared information database …”);
receiving the first information associated with the requestor, wherein the first information includes one or more of a name, address, date of birth, and an identification number (FIG. 3, 5A, items 220, 223, 520; para 71, “User ID 218 can be the customer's identification information such as, name, zip code, social security number or portion thereof, driver's license number or portion thereof, or the like that is used to identify a specific customer …”; para 75, “… user specific information engine 220 will use device ID 216 and user ID 218 to obtain user specific information 223 to prepopulate an electronic form such as a BNPL application. In general, user specific information 223 could be at least two of: a name and full or partial address, a driver's license number, a social security number, or the like …”; para 86, “… if a match is made, then the user specific information 223 can be used to prepopulate a portion of the application, e.g., name, address, city, state, zip, mobile device number, email, etc. …”; para 118, “… user specific information 223 could be one or more of: a name and full or partial address, a driver's license number, a social security number, an exist-ing credit account, or the like …”);
querying, using the first information associated with the requestor, a second database (FIG. 3, item 26; para 84, “If no user specific information 223 is found during the proprietary search 5 or if the found user specific infor-mation 223 cannot be validated, then the device ID 216 and user ID 218 are passed on to a secondary search 25. At secondary search 25, a second source search engine 28 will search at least one secondary source database 26. One example of secondary source database 26 is a reverse phone number look up. However, other secondary source databases may be searched such as, but not limited to: social media sites, search engines, online public and/or private records, reverse name and phone number engines, and the like … the user specific information 223 may be obtained by performing a secondary source database 26 search with the user ID 218 and the device ID 216 …”; para 85, “the secondary search 25 may be for example, a real-time call to a reverse phone look-up product to try and locate the customer … reverse phone look-up products provide accurate and current customer telephone information … the data is updated regularly from a broad range of sources, including regional bell operating companies, white pages and proprietary sources. … also integrates validation and authentication aspects that add further benefits to append address information for a customer … validation and authentication aspects match customer name and zip code information that was returned from the reverse phone look-up, against data from a secondary source to return full address data …”; FIG. 5B, item 524; para 119, “… At 524 of FIG. 5B, if the user specific information 223 cannot be found on the proprietary database, or if the user specific information 223 found does not overcome the confidence factor threshold, one embodiment uses the user ID 218 and device ID 216 information to perform a search of a secondary source database 26 …”);
receiving a second information associated with the requestor from the second database (para 86, “If the customer is found 36, then the user specific information 223 is returned via return information 12 to user specific information engine 220. If no user specific information 223 is found from the secondary search 25, then no user specific information 223 will be pre-populated into the forms. That is, the user specific information engine 220 will receive a return empty 39. However, if a match is made, then the user specific information 223 can be used to prepopulate a portion of the application, e.g., name, address, city, state, zip, mobile device number, email, etc. …”);
generating the variety of arrangement options, wherein the variety of arrangement options is determined using one or more of the first information, the second information, and the unique token (FIG. 7, item 715; para 68, “A number of different options may be available to respond to the BNPL offer 105 … the response may be in the form of a message interaction, as shown and described in further detail in FIGS. 6A through 6F … the response to the BNPL offer 105 requires the customer to provide a device ID 216 and a user ID 218 …”; para 131, “… the BNPL product includes a number of options such as payment amount per payment and the payment timeframe … if the customer is looking at making a 500-dollar transaction, they could be offered a BNPL l that is 5 monthly payments of 100 dollars, BNPL 2 that is 10 monthly payments of 50 dollars, BNPLX that is 50% due at transaction and then some number of weekly, bi-weekly, or monthly payments to cover the remaining 250 dollars …”; para 132, “… one or more different BNPL product options are presented to the customer as one or more payment scenarios …, the BNPL product can be offered to the customer with a number of different payment scenarios such that the customer can select the payment amount and schedule, and use the BNPL product with the appropriate terms to complete the transaction. E.g., one or more optional payback schedules including amounts, number of payments, different interest rates, available offers, discounts, and the like …”; para 135, “… the different transaction payment scenarios may include different offers dependent upon the customer's credit history … a customer with a good credit history could be offered a BNPL product that has a no interest plan … depending upon the goals of the BNPL product provider 230, the BNPL product provider 230 may decide to weigh the BNPL product with respect to the existing customer credit account in order to drive one or more different customers toward the BNPL product. In one embodiment, the weighing may be based upon a customer's credit history, a brand or retailer's desires, available incentives, and the like …”);
presenting the variety of arrangement options to the requestor (FIG. 7, item 720; para 131, “… the BNPL product includes a number of options such as payment amount per payment and the payment timeframe … if the customer is looking at making a 500-dollar transaction, they could be offered a BNPL l that is 5 monthly payments of 100 dollars, BNPL 2 that is 10 monthly payments of 50 dollars, BNPLX that is 50% due at transaction and then some number of weekly, bi-weekly, or monthly payments to cover the remaining 250 dollars …”; para 132, “… one or more different BNPL product options are presented to the customer as one or more payment scenarios …, the BNPL product can be offered to the customer with a number of different payment scenarios such that the customer can select the payment amount and schedule, and use the BNPL product with the appropriate terms to complete the transaction. E.g., one or more optional payback schedules including amounts, number of payments, different interest rates, available offers, discounts, and the like …”; para 144, “… a reduced monthly payment amount, will provide a limit as to the longest allowable term, have a predefined minimum monthly payment amount, or the like … the reduced monthly payment amount could provide a BNPL product term range, a minimum monthly payment range, or the like … when the customer looks at the different options, the appropriate BNPL product fee will be incorporated into the BNPL product information including payment option terms and/or conditions 612 …”);
receiving an input from the requestor, wherein the input is indicative of a selected arrangement within the variety of arrangement options (FIG. 7, item 725; para 181, “At 725, one embodiment selects, via a customer input to the mobile device 110, one of the plurality of BNPL payment scenarios with associated terms …”);
querying, using the first information associated with the requestor, a third database (FIG. 4, item 227; para 93, “… customer account identifier 261 accesses database 227 which stores a plurality of customer credit accounts and utilizes the user specific infor-mation 223 in order to identify any accounts related to the customer … customer account identifier 261 accesses database 227 via cloud 226 …”);
receiving a third information associated with the requestor from the third database (FIG. 4, item 227; para 94, “… database 227 stores a plurality of customer credit accounts, a plurality of customer reward accounts and/or offers, coupons, and the like. Customer account identifier 261 searches database 227 for one or more customer accounts (e.g., credit accounts, reward accounts, and/or offers, coupons, and the like) that are held by the identified customer. When any customer credit accounts are found, they are provided by the customer account identifier 261 to BNPL product builder 262 which links the one or more customer accounts with the BNPL product pass 170 information to build a customer data file …”);
issuing the selected arrangement based on the input from the requestor and the third information, wherein the selected arrangement includes a borrowed amount and repayment terms, and wherein the selected arrangement is issued for use by the requestor with the entity at the unique geographic location (FIG. 7, item 735; para 183, “At 735 … from the mobile device 110 and to the BNPL product provider 230 computing system, the agreement with the associated terms of the selected BNPL payment scenarios … the associated terms include an interest rate, a reward information, a time period for repayment, a predefined payment amount, a recurring payment due date within the time period for repayment, and the like …”) associated with the unique token (FIG. 4, item 170; para 47, “… Mobile wallet 129 includes BNPL product pass 170 … BNPL product pass 170 allows a customer to utilize a single mobile payment method that is linked to one or more credit account information, reward account information, offers, coupons, and the like, and is carried in a secure digital form on a mobile device 110. Instead of using a physical plastic card to make purchases, a mobile wallet allows a customer to pay via mobile device 110 in stores, in apps, or on the web …”; para 96, “… the BNPL product pass 170 could include an image and a token embedded within the image data … the token could be provided via NFC between the mobile device 110 and the POS when BNPL product pass 170 is presented at the POS 104 … metadata within BNPL product pass 170 includes an instruction that causes the BNPL product pass 170 to be placed in a first location of mobile wallet 129 on the customer's mobile device 110 …”); …
Anderson does not specifically disclose, however, Matthews discloses generating a virtual card based on the selected arrangement (FIG. 1, item 104; para 69, “Virtual card generator 104 may comprise one or more processors that are configured to receive requests for virtual cards, generate the requested virtual cards, and transmit the requested virtual cards to the requesting device …”; para 70, “… components 116-128 may cooperate to generate virtual cards and profiles for various users and provision the virtual cards to provisioning device 102 to forward to various client devices, such as client devices 106 and/or 108 … ”; para 71, “Performance of method 200 may enable the data processing system to operate as a software-as-a-service system that can receive requests to generate virtual cards, generate the requested virtual cards, and provision the generated virtual cards to the requesting devices. The data processing system may generate the virtual cards such that the cards may be scanned at a point-of-sale terminal or used online to perform transactions … the data processing system may electronically generate and provision cards and determine whether to allow transactions to occur via the provisioned cards …”; para 74, “… the request may be a bulk request to create virtual cards for multiple individuals. The bulk request may include information that the data processing system can use to generate virtual cards for the individuals … the data processing system may receive identifications of multiple individuals and information for each individual to use to create or generate virtual cards … such requests may include a spreadsheet that includes the data to include for the virtual cards included in rows that each correspond to a different virtual card … the requests may be data that was input into forms on an application (e.g., a web application). The request may include the same or different rules or parameters between the requested virtual cards …”), wherein the virtual card is added to the mobile device or a point-of-sale device and the virtual card enables transactions initiated by the requestor at the unique geographic location (FIG. 4, item 400; para 113, “FIG. 4, an illustration of a sequence 400 for storing a virtual card in a virtual wallet is shown … Sequence 400 may include an application that receives a request to add a virtual card to a wallet in the application. The application then communicates with a software developer kit with data for a virtual card being added to the wallet. The software development kit then communicates with a validation server to validate that the data for the virtual card may be stored in the digital wallet and then an encryption server that uses encryption logic to encrypt the data of the virtual card so the virtual card can be stored… ”; FIG. 5, item 500; para 114,“… Sequences 500 may include a sequence for assigning a virtual card to a specific subscriber (e.g., a provisioning entity) with a subscriber identifier, a sequence for viewing information about the card such as the card security code based on the subscriber identifier, a sequence for adding the virtual card to a digital wallet, and a sequence for deactivating the virtual card …”);
receiving a signal from a device at the unique geographic location indicating that the virtual card was used by the requestor in the entity at the unique geographic location (para 171,“… The transaction server may store the profiles that correspond to the virtual cards, thus enabling the transaction server to either enable or restrict the transactions from occurring. For each transaction, the transaction server may send an indication of the transaction back to the provisioner's device with data for the transaction to inform the provisioners of any transactions that occurred using the provisioned virtual cards…”; para 225, “… responsive to determining the transaction does comply with the use restrictions of the virtual card account, at operation 3630, the data processing system updates the virtual card account. The data processing system may update the virtual card account by inserting an indication that the virtual card account was used to complete a transaction into the virtual card account or by otherwise incrementing a counter that indicates the number of transactions the virtual card account has been used to complete …”); …
deactivating the virtual card by removing the virtual card from the mobile device's application or marking the virtual card as inactive (FIG. 5, item 500; para 114,“… Sequences 500 may include a sequence for assigning a virtual card to a specific subscriber (e.g., a provisioning entity) with a subscriber identifier, a sequence for viewing information about the card such as the card security code based on the subscriber identifier, a sequence for adding the virtual card to a digital wallet, and a sequence for deactivating the virtual card …”; para 177, “… A provisioner may access and view user interface 220 to view information about a provisioned virtual card and/or deactivate the virtual card so it cannot be used … a provisioner may select a deactivate button from user interface 2200 that will change a setting in the profile that corresponds to the virtual card to indicate to restrict or stop any transactions that are performed using the virtual card … when the provisioner selects the deactivate button, a virtual card generation and provisioning system (e.g., virtual card generator 104) may transmit a signal to the mobile device that stores the virtual card to remove the virtual card from memory, make the virtual card inaccessible, and/or to otherwise update a setting on the device so the virtual card cannot be used for purchases …”).
Matthews discloses virtual card generation and provisioning for bulk requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include virtual card generation and provisioning for bulk requests, as in Matthews, to improve and/or enhance the technology for providing a buy now pay later product to a credit account holder, as in Anderson, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a computer system that enables companies to provision virtual cards, as data packets to individuals, that can be used according to companies’ policies by providing an accessible remote device that can generate and provision virtual cards to a company accessing the system, and including rules and policies about how, when, and/or where the virtual cards may be used to make purchases.
Anderson and Matthews do not specifically disclose, however, Laracey discloses
… and contains an entity identification code such that access the unique token is limited to geographic locations associated with the unique token (para 93, “… The static checkout token is generated such that it uniquely identifies details about the merchant, including but not limited to the location of the store, the merchant's account number, and the specific point of sale device 212 within a store with which the static checkout token is associated, and may be an alphanumeric identifier (e.g., such as a 4-7 character identifier) allowing it to be easily keyed in or entered into a mobile device 202, or it may be an encoded bar code image, or a radio signal such as that produced by an RFID device …”; para 94, “… the dynamic checkout token may be created as an encoded bar code image that, when decoded, reveals an identifier that uniquely identifies a number of items associated with the point of sale device 212 and a particular checkout transaction. The decoding of the bar code image may … reveal a checkout identifier that may be used (e.g., by the transaction management system 230) to identify information about the POS device 212 … the merchant, the particular POS device 212, the lane or checkout location, the location of the merchant, or a particular transaction, etc. … each dynamic checkout token may be associated with: a particular merchant, a specific checkout lane at a specific merchant location, a particular checkout transaction, and a specific POS device. Each POS device 212 may have a POS identifier, and that POS identifier may be associated with a specific dynamic checkout token generated for a transaction … a dynamic checkout token generated for a grocery store may identify the name of the grocery store (e.g., such as the chain), the location of the grocery store (such as the specific geographical location of the store), the checkout lane within the specific store, and the POS device in the checkout lane … for each dynamic token there may be several ways the information encoded in the token can be used by the transaction management system 230 to reveal information about the merchant or the actual transaction. First, the information can be stored inside the checkout token itself (in such scenarios, the token may not be appropriate for key-entry by a human, and instead should be captured or scanned by the mobile device). Next, the checkout token itself may be an identifier that can be used to "lookup" or reference the transaction details stored in a database table … the checkout token may be … a 4 to 7 position combination of alphanumeric characters or shapes. Such tokens may be either key-entered by a human or captured by a mobile device …”; FIG. 5, item 518; para 136, “… A merchant management system module 518 is provided to allow the management of retailer or merchant profiles, their identification codes, and the like … the module 518 may manage the distribution, assignment and use of checkout tokens for each merchant location, so that payment transaction requests received from customer mobile devices may be properly matched to pending transactions of the correct merchant …”); …
wherein a transaction initiated using the virtual card is authorized after determining that an identifier provided by a point-of-sale device matches the entity identification code encoded in, or derived from, the unique token; (para 41, “… either a "static" checkout token or a "dynamic" checkout token may be used … where a "static" checkout token is used (e.g., such as one that is assigned for use by a specific check-out location and which does not include any variable information for each transaction), the transaction management system 130 matches the information in the customer transaction lookup request (received from the mobile device 102) with the information in the merchant payment authorization request (received from the merchant 108) by matching the checkout token information received in each of the messages. Once a match is found, the transaction management system 130 transmits a transaction detail message (via path 114) to the customer's mobile device 102. The information from the transaction detail message provides the customer with details about the transaction, including but not limited to the amount due, the name and location of the merchant (information contained in or derived from the merchant payment authori-zation request), and possibly one or more marketing messages … the transaction management system may also send to the phone a list of payment accounts the customer has registered with the system, including credit, debit, checking, prepaid and other types of accounts … Now the customer can see on the display 136 of their mobile device 102 the name of the merchant they are about to pay, the amount to be paid, and a list of their payment accounts they can use to pay the merchant 108 …”; para 42, “… the merchant's checkout token may be derived from a unique identifier in the merchant payment authorization request The checkout token may be derived using a mapping table which maps a merchant identifier, a terminal identifier, or other information (passed by the merchant system to the transaction management system 130) to a checkout token. Based on the received identifier, a mapping process may occur to identify the appropriate checkout token for use in that payment transaction. The selected checkout token is associated with the transaction in the merchant transaction queue where it is made available to be matched with transactions from the customer message queue … the checkout token is an identifier (consisting of a combination of letters, numbers, and/or symbols) used to link a merchant payment authorization request to a payment authorization request received from a customer operating a mobile device …”; para 103, “… While the customer is waiting for the transaction total, a message may be displayed on the mobile device 202 informing her that the device is "waiting for an amount due" (or similar message). After the merchant calculates the transaction total, the merchant transmits the total in an updated merchant payment authorization request message to the transaction management system 230. The system 230 uses this information to update the pending transaction record and then causes a message to be transmitted to the mobile device 202 to update the mobile device 202 with the total amount due (and may also include information about a list of available payment accounts that may be used in the transaction). The mobile device 202 may be updated to display the total as well as any loyalty savings (if any were earned in the transaction) as well as the list of available payment accounts. The customer then selects her desired payment account(s) to complete the transaction as normal …”) and …
Laracey discloses methods and systems for selecting accounts and offers in payment transactions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include methods and systems for selecting accounts and offers in payment transactions, as in Laracey; and to include virtual card generation and provisioning for bulk requests, as in Matthews, to improve and/or enhance the technology for providing a buy now pay later product to a credit account holder, as in Anderson, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide systems and methods in which payment card information is not stored, captured, or transmitted by merchants; to provide a customer with information about which account(s) should be used in a given transaction (e.g., in order to save on transaction costs, to earn rewards, to manage balances and spend, etc.); and to provide an ability to conduct purchase transactions (both online and at brick and mortar stores) using a mobile device, which provides added security, decreases the potential for fraud, and provides convenience and ease of completing a transaction using a mobile device containing a wallet with multiple tokens.
As per claim 2, Anderson, Matthews, and Laracey disclose all the limitations of claim 1. Anderson further discloses the non-transitory computer readable medium of claim 1, wherein the first database is a collection of requestor account data (FIG. 3, item 16; para 77, “… information to perform a proprietary search 5 of at least one proprietary database 16. In general, the proprietary database 16 may be one or more databases such as a credit accounts database, or the like, that store a company's private database such as an Alliance Data Legacy database or the like. Proprietary database 16 will include user specific information 223 for customers that have existing accounts with the company, have previously applied for an account, or the like …”).
As per claim 3, Anderson, Matthews, and Laracey discloses all the limitations of claim 1. Anderson further discloses the non-transitory computer readable medium of claim 1, wherein the selected arrangement has a term of 12 months or less (para 131, “… the BNPL product includes a number of options such as payment amount per payment and the payment timeframe … if the customer is looking at making a 500-dollar transaction, they could be offered a BNPL l that is 5 monthly payments of 100 dollars, BNPL2 that is 10 monthly payments of 50 dollars, BNPLX that is 50% due at transaction and then some number of weekly, bi-weekly, or monthly payments to cover the remaining 250 dollars …”; para 142, “… if the customer pays off the BNPL product in 2 months, there would be no interest charged and the BNPL product fee would be reduced to 5 dollars. If that opportunity is accepted, the amount of the BNPL product would be 505 dollars (e.g., 500 dollars+5-dollar fee) broken down over 2 months thereby resulting in a monthly payment of 252.50 per month for the next 2 months …”; para 145, “… if the customer would like to make monthly payments of 50 dollars toward the BNPL product, the customer would select the 50-dollar payment option and the modified BNPL product information including payment option terms and/or conditions 612 would be presented to the customer … when the customer chooses to pay 50 dollars a month toward the BNPL product, the BNPL product fee would be increased by a defined amount and presented to the customer along with the terms and conditions … the amount of the one-time BNPL product would be 520 dollars (e.g., 500 dollars+l0-dollar fee+l0 dollars in interest). Since the customer has selected to pay 50 dollars a month, the customer's BNPL product term would be 11 months, with 10 months of 50-dollar payments and the 11th month being a 20-dollar payment …”).
As per claim 4, Anderson, Matthews, and Laracey discloses all the limitations of claim 1. Anderson further discloses the non-transitory computer readable medium of claim 1, wherein the second database is associated with a credit collecting organization (FIG. 4, item 241; para 88, “… credit screener 240 accesses a credit reporting agency database 241, such as a credit reporting agency, via cloud 226 to determine credit information for the customer based on the user specific information 223 …”).
As per claim 5, Anderson, Matthews, and Laracey discloses all the limitations of claim 1. Anderson further discloses the non-transitory computer readable medium of claim 1, wherein the second information is a measure of the requestor's ability to obtain goods or services before payment (para 90, “… after the customer passes the credit screening then BNPL product provider 230 provides an application for a BNPL product to the customer's mobile device … BNPL product provider 230 populates the application for the BNPL product with the user specific information 223. That is, BNPL product provider 230 will place the user specific information 223 provided by the user specific information engine 220 into the forms that are provided to the customer's mobile device. By populating the forms prior to presenting them to the customer, the abandonment rate will be improved as the application pro-cess will be shortened due to the pre-filling of the customer's information into the application forms …”).
As per claim 6, Anderson, Matthews, and Laracey discloses all the limitations of claim 1. Anderson further discloses the non-transitory computer readable medium of claim 1, wherein the third database is associated with a credit collecting organization (FIG. 4, item 227; para 93, “… customer account identifier 261 accesses database 227 which stores a plurality of customer credit accounts and utilizes the user specific infor-mation 223 in order to identify any accounts related to the customer … customer account identifier 261 accesses database 227 via cloud 226 …”).
As per claim 7, Anderson, Matthews, and Laracey discloses all the limitations of claim 1. Anderson further discloses the non-transitory computer readable medium of claim 1, wherein the third information is a measure of the requestor's ability to obtain goods or services before payment (FIG. 5A, item 530; para 149, “With reference now to 530 of FIG. SA, once the customer passes the credit screening, one embodiment pro-vides the BNPL product pass 170 to the customer … at FIG. 6D, an embodiment of a screen capture 630 of the identified customer's BNPL product 631 information and a ready for purchase feature such as code 632 (which may be a visual code, an aural code, and/or a combination thereof) as viewed on a customer's mobile device 110 is shown in accordance with an embodiment …”).
As per claim 8, Anderson, Matthews, and Laracey discloses all the limitations of claim 1. Anderson further discloses the non-transitory computer readable medium of claim 1, the instructions further comprising generating a data structure associated with the requestor, wherein the data structure represents at least one table, and wherein the at least one table is determined using one or more of the first information and the second information (FIG. 3, item 16; para 77, “… information to perform a proprietary search 5 of at least one proprietary database 16 … the proprietary database 16 may be one or more databases such as a credit accounts database, or the like, that store a company's private database such as an Alliance Data Legacy database or the like. Proprietary database 16 will include user specific information 223 for customers that have existing accounts with the company, have previously applied for an account, or the like …”; para 78, “… the proprietary search 5 will only search a database related to a specific company … if the BNPL product provider 230 is a specific company, e.g., Nash's skate and bike emporium, then in a company specific database search, only the existing customer information related to Nash's skate and bike emporium will be searched … a check is performed to see if the customer has an existing PLCC account, e.g., is already an existing customer in the database …”; FIG. 3, items 216, 218; para 79, “… if the proprietary search 5 is for a group of companies, a shared information database, or the like, then all of the customer information in the databases may be searched for a match with the device ID 216 or the user ID 218 … if the database includes Nash's skate and bike, Mike's hardware, and Tarrin's dress stores, and all three companies are sharing information, then the search would encompass all three store's databases of information …”; para 80, “… the search would use an internal account holder proprietary database 16 to see if the customer has another account within the shared information database …”; FIG. 4, item 241; para 89, “Credit screener 240 will analyze the customer's credit information obtained from the credit reporting agency database 241 to determine if the customer passes the credit criteria. If the customer does not pass the credit screening process, no further action is taken …”; FIG. 5B, 522, 523; para 119, “… At 522 of FIG. 5B, one embodiment uses the device ID 216 and user ID 218 information to perform a proprietary search 5 of a propri-etary database 16. At 523 of FIG. 5B, in one embodiment, user specific information 223 that is found in the proprietary database 16 will be verified using a confidence factor threshold …”).
As per claim 9, Anderson, Matthews, and Laracey discloses all the limitations of claims 1 and 8. Anderson further discloses the non-transitory computer readable medium of claim 8, wherein receiving the data structure prompts generating the variety of arrangement options (FIG. 6A, 6B, items 610, 611, 612; para 103, “FIG. 6A is a block diagram of a BNPL offer 105 shown in accordance with an embodiment. FIG. 6B is a screen capture 610 of a BNPL application including a customer's credit account information 611, the BNPL product information including payment option terms and/or conditions 612, and an apply or place order 615 input, as viewed on a customer's mobile device 110 in accordance with an embodiment …”; para 124, “… BNPL product information including payment option terms and/or conditions 612 describes the payment plan that is established and agreed upon by the customer. In one embodiment, the BNPL product information including payment option terms and/or conditions 612 will take an initial payment at the time of the transaction, and then the rest of the payments for the purchase are automatically taken out as installment pay-ments from the initial account provided based on the cus-tomer accepted terms in the BNPL agreement …”; para 125, “… included in BNPL product information including payment option terms and/or condi-tions 612 is an autopayment scenario. In one embodiment, the autopayment will be prefilled by the system using the customer's credit account information 611 … the offer would be to obtain the BNPL product and make the payments automatically from the customer's credit account. If the customer does not want to set up the autopay, then in one embodiment, the BNPL application process is stopped and no BNPL product is obtained …”; para 131, “… the BNPL product includes a number of options such as payment amount per payment and the payment timeframe … if the customer is looking at making a 500-dollar transaction, they could be offered a BNPL l that is 5 monthly payments of 100 dollars, BNPL 2 that is 10 monthly payments of 50 dollars, BNPLX that is 50% due at transaction and then some number of weekly, bi-weekly, or monthly payments to cover the remaining 250 dollars …”; para 132, “… one or more different BNPL product options are presented to the customer as one or more payment scenarios. In other words, the BNPL product can be offered to the customer with a number of different payment scenarios such that the customer can select the payment amount and schedule, and use the BNPL product with the appropriate terms to complete the transaction. E.g., one or more optional payback schedules including amounts, num-ber of payments, different interest rates, available offers, discounts, and the like …”).
As per claim 10, Anderson, Matthews, and Laracey discloses all the limitations of claims 1 and 8. Anderson further discloses the non-transitory computer readable medium of claim 8, wherein the variety of arrangement options are generated by the at least one processor and further based on the at least one table (FIG. 6B, item 611, 612; para 120, “With reference now to FIG. 6B, a screen capture 610 of a BNPL application including a customer's credit account information 611, the BNPL product information including payment option terms and/or conditions 612, and an apply or place order 615 input, as viewed on a customer's mobile device 110 …”; para 122, “… the customer identifies the account, e.g., customer's credit account information 611, to be used to obtain payments therefrom for the BNPL product … when the customer has a number of existing accounts (such as a co-brand credit account, a PLCC account, a UPLCC account, an installment loan, or the like), the customer will have the option to select/elect which account will be used … when the customer has a number of existing accounts (such as a co-brand credit account, a PLCC account, a UPLCC account, an installment loan, or the like), the BNPL producer 360 will automatically select/elect which account will be used …”; para 141, “If the customer chooses to review the opportunities offered by the optional changes to the BNPL product infor-mation including payment option terms and/or conditions 612, the customer will move to the modify one or more aspects thereof … the customer will be able to review offers, additional fees, additional opportunities, and the like available by selecting a non-default monthly payment amount (or length of the BNPL product payback schedule) …”; para 143, “ … instead of obtaining a discount by reducing the BNPL product term, the customer could select to modify the payment options by extending the BNPL product term and obtain a reduced monthly payment amount … extending the BNPL product term will also result in a larger cost than the cost included in the BNPL product information, including payment option terms and/or conditions 612 …”; para 144, “ … a reduced monthly payment amount, will provide a limit as to the longest allowable term, have a predefined minimum monthly payment amount, or the like … the reduced monthly payment amount could provide a BNPL product term range, a mini-mum monthly payment range, or the like … when the customer looks at the different options, the appropriate BNPL product fee will be incorporated into the BNPL product information including payment option terms and/or conditions 612 …”; para 145, “… if the customer would like to make monthly payments of 50 dollars toward the BNPL product, the customer would select the 50-dollar payment option and the modified BNPL product information including payment option terms and/or conditions 612 would be presented to the customer …”).
As per claim 11, Anderson, Matthews, and Laracey discloses all the limitations of claim 1. Anderson further discloses the non-transitory computer readable medium of claim 1, wherein the generating the variety of arrangement options is further based on a monetary value designated by the requestor (para 129, “… the due at transaction time percentage can be a specific amount, e.g., 25% for example, or it could be based on the purchase price and the total number of monthly payments … if the transac-tion is 500 dollars, the customer could choose a BNPL product with 5 equal payments such that the first payment due at time of purchase is 100 dollars and then there will be four additional payments taken out at the agreed upon payment schedule …”; para 131, “… the BNPL product includes a number of options such as payment amount per payment and the payment timeframe … if the customer is looking at making a 500-dollar transaction, they could be offered a BNPL l that is 5 monthly payments of 100 dollars, BNPL2 that is 10 monthly payments of 50 dollars, BNPLX that is 50% due at transaction and then some number of weekly, bi-weekly, or monthly payments to cover the remaining 250 dollars …”; para 145, “… if the customer would like to make monthly payments of 50 dollars toward the BNPL product, the customer would select the 50-dollar payment option and the modified BNPL product information including payment option terms and/or conditions 612 would be presented to the customer … when the customer chooses to pay 50 dollars a month toward the BNPL product, the BNPL product fee would be increased by a defined amount and presented to the customer along with the terms and conditions … the amount of the one-time BNPL product would be 520 dollars (e.g., 500 dollars+l0-dollar fee+l0 dollars in interest). Since the customer has selected to pay 50 dollars a month, the customer's BNPL product term would be 11 months, with 10 months of 50-dollar payments and the 11th month being a 20-dollar payment …”; para 147, “… the amount of the one-time BNPL product would be 520 dollars (e.g., 500 dollars+ 10-dollar fee+ 10 dollars in interest). Since the customer has selected a BNPL product term of 10 months, the monthly payment would be 52 dollars per month …”).
As per claim 22, Anderson, Matthews, and Laracey discloses all the limitations of claim 1. Anderson further discloses the non-transitory computer readable medium of claim 1, wherein presenting the variety of arrangement options to the requestor includes an interactive user interface that allows the requestor to select a desired arrangement amount using a slider or input box (FIG. 6A, 6B; para 103, “FIG. 6A is a block diagram of a BNPL offer 105 shown in accordance with an embodiment. FIG. 6B is a screen capture 610 of a BNPL application including a customer's credit account information 611, the BNPL prod-uct information including payment option terms and/or conditions 612, and an apply or place order 615 input, as viewed on a customer's mobile device 110 in accordance with an embodiment …”; para 120, “With reference now to FIG. 6B, a screen capture 610 of a BNPL application including a customer's credit account information 611, the BNPL product information including payment option terms and/or conditions 612, and an apply or place order 615 input, as viewed on a customer's mobile device 110 is shown in accordance with an embodiment …”; para 141, “If the customer chooses to review the opportunities offered by the optional changes to the BNPL product information including payment option terms and/or conditions 612, the customer will move to the modify one or more aspects thereof … the customer will be able to review offers, additional fees, additional opportunities, and the like available by selecting a non-default monthly payment amount (or length of the BNPL product payback schedule) …”).
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson et al (U. S. Patent Application Publication No. 20230004951 A1), herein referred to as Anderson, in view of Matthews et al (U. S. Patent Application Publication No. 20230087384 A1), herein referred to as Matthews, in view of Laracey (U. S. Patent Application Publication No. 20130238455 A1), herein referred to as Laracey, and in further view of Jung et al (U. S. Patent Application Publication No. 20070136185 A1), herein referred to as Jung.
As per claim 12, Anderson, Matthews, and Laracey disclose all the limitations of claim 1. Anderson, Matthews, and Laracey do not specifically disclose, however, Jung discloses the non-transitory computer readable medium of claim 1, wherein the selected arrangement is presented by the at least one processor and as a virtual card (FIG. 4, items 190, 192; para 83, “In some instances the virtual card features such as credit terms, payment terms, penalties, benefits, and the like may be selected by the user (block 190). In other instances a program may select the virtual card features (block 192), which features may be determined from stored application data (block 194) that is evaluated by the program (block 196). The virtual card features that are selected for each user are stored (block 198) for future reference. Where virtual account terms for a virtual card are being programmed for a new user, such programming may be based on user demo-graphic information …”; FIG. 10, item 406, para 106, “The virtual charge card server 402 includes various predetermined data records as well as other dynamically updated records that are used by the server to help provide virtual credit services based on different types of credit arrangements and accounts. Exemplary categories of records available to the virtual charge card server 402 include user ID data and related individual virtual card terms 406, user demographic parameters 408, user ID virtual account status data 410 (e.g., entity/person owed, compensation already received, and remaining balance due), virtual account statements 412, user ID performance records 414, and bench-mark standards for virtual card usage 416 …”).
Jung discloses disposition of proprietary virtual rights. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include disposition of proprietary virtual rights, as in Jung; to include methods and systems for selecting accounts and offers in payment transactions, as in Laracey; and to include virtual card generation and provisioning for bulk requests, as in Matthews, to improve and/or enhance the technology for providing a buy now pay later product to a credit account holder, as in Anderson, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide methods and systems using a virtual card with buy now pay later (BNPL) services that provide enhanced security, as it protects the user’s core financial data from merchants and potential data breaches, and offers greater control over spending by allowing the user to set limits for each transaction; and increases the reach of the BNPL services, as the user can use the virtual card to make purchases at almost any online or even in-store merchant that doesn’t partner directly with the BPNL provider.
As per claim 13, Anderson, Matthews, and Laracey disclose all the limitations of claim 1. Anderson, Matthews, Laracey, and Jung disclose all the limitations of claim 12. Anderson further discloses the non-transitory computer readable medium of claim 12, wherein the virtual card is used for one of an online transaction and an in-person transaction (para 32, “… the co-branded credit account can have an associated virtual card that can be stored in a mobile wallet or otherwise digitally stored by the customer and includes the credit account information required for a purchase … the co-branded credit account can have both a physical card and a virtual card …”; para 34, “… the PLCC account can have an associated physical card, e.g., a credit card that is carried by a customer and includes the credit account information required for a purchase … the PLCC account can have an associated virtual card that can be stored in a mobile wallet or otherwise digitally stored by the customer and includes the credit account information required for a purchase … the PLCC account can have both a physical card and a virtual card …”).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Anderson et al (U. S. Patent Application Publication No. 20230004951 A1), herein referred to as Anderson, in view of Matthews et al (U. S. Patent Application Publication No. 20230087384 A1), herein referred to as Matthews, in view of Laracey (U. S. Patent Application Publication No. 20130238455 A1), herein referred to as Laracey, and in further view of Zakaras et al (U. S. Patent Application Publication No. 20170154328 A1), herein referred to as Zakaras.
As per claim 21, Anderson, Matthews, and Laracey disclose all the limitations of claim 1. Anderson, Matthews, and Laracey do not specifically disclose, however, Zakaras discloses the non-transitory computer readable medium of claim 1, wherein at least one of a passcode, biometric data is received from the mobile device to authenticate the requestor (para 17, “A financial institution application running on a user device may require a user to enter one or more credentials before requesting information from a backend system … credentials may include user authentication credentials, which may be a user authentication input … a password entry, PIN, gesture, which may include a motion, tap, rotation, button press, a signature entry, symbol, and/or biometric data (fingerprint, facial recognition, and the like) …”; para 18, “A financial institution application running on a user device may require a user to enter one or more credentials before requesting information from a backend system … credentials may include user authentication credentials, which may be a user authentication input, such as for example, a password entry, PIN, gesture, which may include a motion, tap, rotation, button press, a signature entry, symbol, and/or biometric data (fingerprint, facial recognition, and the like) …”; FIG. 1, item 160; para 65, “User authentication system 160 may utilize software including user authentication input recognition algorithms, which may include a pattern matching algorithm that will compare the card user performed user authentication input, which may be a gesture or voiceprint, to the prerecording of the predetermined user authentication input which may be saved on EMV™ chip 122, backend 318 system, and/or user authentication system 160. Microcontroller 224 may perform voice recognition to determine if EMVTM chip 212 and/or a dynamic transaction card 200's magnetic stripe should be activated to activate the dynamic transaction card for usage …”).
Zakaras discloses a dynamic transaction card protected by gesture and voice recognition. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a dynamic transaction card protected by gesture and voice recognition, as in Zakaras; to include methods and systems for selecting accounts and offers in payment transactions, as in Laracey; and to include virtual card generation and provisioning for bulk requests, as in Matthews, to improve and/or enhance the technology for providing a buy now pay later product to a credit account holder, as in Anderson, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a dynamic transaction card including components, such as sensors that may be used to activate the dynamic transaction card by authenticating the card user as authorized to use the card through user authentication input recognition, which may be a gesture, voice recognition, and/or biometric data (fingerprints, facial recognition, and the like), and thus being a more secure authentication of the user.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Chumbley (U. S. Patent Application Publication No. 20180108008 A1) – Digital
Wallet Merchant-Specific Virtual Payment Accounts
Chumbley discloses systems and methods for securely and efficiently updating account information across resource providers. Embodiments of the invention provide a method for managing account data that is an improvement in both speed and security over prior methods used by account data management systems. According to embodiments of the invention, account data is linked to resource provider specific tokens stored and managed by a digital wallet provider. Resource provider specific tokens may be stored by resource providers to conduct future transactions, also including recurring or automatic transactions. To manage the resource provider specific tokens, a user may simply send requests to the digital wallet provider using a single interface displayed on a user device rather than by logging into accounts for numerous resource providers and continuously entering updated account data.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN CHISM whose telephone number is (571) 272-5915. The examiner can normally be reached during 9:00 AM – 3:00 PM Monday – Thursday, 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, Ryan D. Donlon can be reached (571) 270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN CHISM/
Examiner, Art Unit 3692
/DAVID P SHARVIN/Primary Examiner, Art Unit 3692
Prosecution Insights