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 .
Status of Claims
The following is a non-final Office Action in response to application number 19277849 filed on July 23, 2025. Claims 1-20 are currently pending, and have been examined.
Claim Objections
Claim 17 is objected to because of the following informalities: “transmit, …, a selected arrangement of the variety of arrangements.” should end in a semicolon, “transmit, …, a selected arrangement of the variety of arrangements[[.]];”
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-20 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-14 are directed to a “non-transitory computer-readable medium”; claims 15-16 are directed to a “system”; and claims 17-20 are directed to a “system”. 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 or legal interactions and of fundamental economic principles or practices (i.e., organizing human activity), and 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 operations comprising: providing a unique token at the unique geographic location, wherein the unique token is associated with the entity at the unique geographic location; 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 at the unique geographic location”, where the italicized claim language represents the abstract idea “location based payment options”. (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 (the bolded claim language), such as “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 operations comprising: …”, “a mobile device”, “a first database”, “a second database”, “presenting the variety of arrangement options to the requestor”, and “a third database”, which 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, these 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.
Claim 15 also recites the abstract idea of “location based payment options”, as well the additional elements of “a system for issuing an arrangement for use with an entity at a unique geographic location, the system comprising: at least one processor configured to: …”, “a mobile device”, “a first database”, and “a second database”, which 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 mobile device” and “a first database”). Therefore, these 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 15 is non-statutory.
Claim 17 also recites the abstract idea of “location based payment options”, as well the additional elements of “a system for receiving an arrangement for use with an entity at a unique geographic location, the system comprising: at least one processor configured to: …”, “a mobile device”, “a computing device associated with the financial institution”, and “present, on a screen of the mobile device, the variety of arrangement options”, which 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 computing device associated with a financial institution” and “at least one processor”). Therefore, these 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 17 is non-statutory.
Dependent claims 2-14, 16, and 18-20 further describe the abstract idea of “location based payment options”, which is insufficient to overcome the rejections of claims 1, 15, and 17.
Dependent claims 2-11, 13, and 18-20 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. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field, when analyzed under Step 2B.
Dependent claim 12 recites a new additional element of “a virtual card”, which does no more than employ a computer as a tool to implement the abstract idea. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality nor improve another technology or a technical field.
Dependent claim 14 recites a new additional element of “a device at the unique geographic location”, which does no more than employ a computer as a tool to implement the abstract idea. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality nor improve another technology or a technical field.
Dependent claim 16 recites a new additional element of “a wallet associated with the mobile device”, which does no more than employ a computer as a tool to implement the abstract idea. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality nor improve another technology or a technical field.
Hence, claims 1-20 are not patent eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 16 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Improper Dependent Claim
Claim 15 recites “A system for issuing an arrangement for use with an entity at a unique geographic location, the system comprising: …”. Claim 16 recites “The method of claim 15, wherein the selected arrangement is in the form of a virtual card stored in a wallet associated with the mobile device”. Claim 16 recites limitations of a method for the selected arrangement being in the form of a virtual card stored in a wallet associated with the mobile device, which does not further limit and incorporate by reference all the limitations of the system of claim 15. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. Following the statute, the test as to whether a claim is a proper dependent claim is that it shall include every limitation of the claim from which it depends and specify a further limitation of the subject matter claimed. For examination purposes, Examiner is interpreting claim 16 as being a system limitation depending from the system of claim 15.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-11 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 20230004951 A1 (Anderson).
As per claim 1, Anderson teaches,
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 … in non-transitory computer-readable medium for storing instructions of a computer system … FIG. 9 illustrates one example of a type of computer that can be used to implement embodiments of the present technology …”; para 268, “… As shown in FIG. 9, computer system 900 of FIG. 9 is well adapted to having peripheral computer readable media 902 such as … 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. As depicted in 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 … 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, “… storing static information and instructions for processors 906A, 906B, and 906C. Also present 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. Computer system 900 also includes an optional alphanumeric input device 914 including alphanumeric and function keys coupled to bus 904 for communicating information and command selections to processor 906A or processors 906A, 906B, and 906C …”), cause the at least one processor to generate a variety of arrangement options for use with an entity at a unique geographic location, the operations 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. 4, item 263; para 95, “… Token generator 263 then generates a token identifying the customer data file … the token is an identification number, hash, or other type of anti-tamper encrypted protection that is generated as an identifier for the customer data file …”; para 96, “… BNPL product generator 265 generates a BNPL product pass 170 formatted for mobile wallet 129 … 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 …”; para 157, “… the BNPL product pass 170 includes a token … the token embedded in code 632 will also be added to the BNPL product pass 170 stored in mobile wallet 129 …”);
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, “… uses 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, item 218; 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 …”; FIG. 3, items 218, 220, 223; 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 … 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 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. …”; FIG. 5B, item 520; para 118, “… With reference now to 520 of FIG. 5A and as shown and expanded in the flowchart 550 of FIG. 5B and shown in FIGS. 3 and 4, one embodiment utilizes device ID 216 and user ID 218 to obtain user specific information 223 useable for a credit screen and/or to prepopulate the BNPL application … 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 26; 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. 6A-6F, 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 1 that is 5 monthly payments of 100 dollars, BNPL 2 that is 10 monthly payments of 50 dollars, BNPL X 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. Similarly, 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 … the weighing may be based upon a customer's credit history, a brand or retailer's desires, available incentives, and the like …”; FIG. 7, item 715; para 177, “… At 715, one embodiment generates, at the BNPL product provider 230 computing system and based on a result of the credit prescreen, a plurality of BNPL payment scenarios with associated terms …”);
presenting the variety of arrangement options to the requestor (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 …”; FIG. 7, item 720, para 179, “… At 720, … provides, to mobile device 110 of the customer and from the BNPL product provider 230 computing system, the plurality of payment scenarios with associated terms … such as internet shopping or on a mobile device 110 during a real-world shopping experience, the customer may be provided with tender reminder messages for either rewards or "pay as low as" messaging. E.g., "if you use a BNPL product you will be able to make the purchase while paying as low as 25 dollars a month for 6 months" …”);
receiving an input from the requestor, wherein the input is indicative of a selected arrangement within the variety of arrangement options (FIG. 7, items 725; para 181, “… At 725, … 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 … Database 227 may include store specific data, brand specific data, retailer specific data, a shared database, a conglomerate database, a portion of a larger storage data-base, and the like. Moreover, database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof …”);
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, … provides, 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 …”).
As per claim 2, Anderson teaches all the limitations of claim 1. Anderson further teaches 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, “… uses 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 …”).
As per claim 3, Anderson teaches all the limitations of claim 1. Anderson further teaches 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 1 that is 5 monthly payments of 100 dollars, BNPL 2 that is 10 monthly payments of 50 dollars, BNPL X 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, “… 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 teaches all the limitations of claim 1. Anderson further teaches 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 teaches all the limitations of claim 1. Anderson further teaches 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 process will be shortened due to the pre-filling of the customer's information into the application form …”; FIG. 5A, item 530; para 149, “… With reference now to 530 of FIG. 5A, once the customer passes the credit screening, … provides 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 …”).
As per claim 6, Anderson teaches all the limitations of claim 1. Anderson further teaches 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 information 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 teaches all the limitations of claim 1. Anderson further teaches the non-transitory computer readable medium of claim 1, wherein the third information is 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. 5A, once the customer passes the credit screening, … provides 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 teaches all the limitations of claim 1. Anderson further teaches the non-transitory computer readable medium of claim 1, the operations 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, items 216, 218, 223; 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 … 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 …”; FIG. 6B, item 610; 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 …”).
As per claim 9, Anderson teaches all the limitations of claims 1 and 8. Anderson further teaches 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 …”; 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 … 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 payments from the initial account provided based on the customer accepted terms in the BNPL agreement …”; para 125, “… included in BNPL product information including payment option terms and/or conditions 612 is an autopayment scenario … 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 1 that is 5 monthly payments of 100 dollars, BNPL 2 that is 10 monthly payments of 50 dollars, BNPL X 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 …”).
As per claim 10, Anderson teaches all the limitations of claims 1 and 8. Anderson further teaches the non-transitory computer readable medium of claim 8, wherein the variety of arrangement options are generated 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 is shown …”; 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 …”).
As per claim 11, Anderson teaches all the limitations of claim 1. Anderson further teaches 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 transaction 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 1 that is 5 monthly payments of 100 dollars, BNPL 2 that is 10 monthly payments of 50 dollars, BNPL X 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 …”).
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 12-14 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 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 discloses all the limitations of claim 1. Anderson does not specifically disclose, however, Jung discloses the non-transitory computer readable medium of claim 1, wherein the selected arrangement is presented as a virtual card (FIG. 4, items 190, 192; para 82, “… The detailed exemplary flow chart of FIG. 4 shows a process 180 for implementing an application procedure for a virtual charge card. A person who is not already an authorized user can make application (block 182) for a virtual charge card. An evaluation or screening confirms whether or not the person meets predetermined criteria (block 184) for having the virtual charge card. Persons that do not meet the criteria are rejected (block 186). When a person does meet the criteria, their application is accepted and a user ID established (block 188) …”; para 83, “… the virtual card features such as credit terms, payment terms, penalties, benefits, and the like may be selected by the user (block 190) … 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 benchmark 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 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 using a virtual card for enhanced security through unique, single-use numbers that protect sensitive data, better spend management via customizable limits and merchant restrictions, improved efficiency through automated processes and faster supplier payments, and greater convenience for both personal online shopping and business expense management.
As per claim 13, Anderson discloses all the limitations of claim 1. Anderson and Jung disclose all the limitations of 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 …”).
As per claim 14, Anderson discloses all the limitations of claim 1. Anderson does not specifically disclose, however, Jung discloses the non-transitory computer readable medium of claim 1, the operations further comprising:
generating a virtual card based on the selected arrangement, wherein the virtual card is configured for the requestor to use in the entity at the unique geographic location (FIG. 4, items 190, 192; para 83, “… the virtual card features such as credit terms, payment terms, penalties, benefits, and the like may be selected by the user (block 190) … 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 demographic information …”; FIG. 7, item 318; para 93, “… virtual credit parameters 318 may include categories such as interest rates, variable interest, fixed interest, credit limit, penalties, late payment fee, minimum periodic payment, payment due date, method of pay-ment, cash advance, balance transfers, and account checks … user purchase selections 320 may include categories such as housing, automobile, entertainment, vacations, insurance, food, clothing, appliances, fur-nishings, and virtual world items …”; FIG. 10, items 402, 420; 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 state-ments 412, user ID performance records 414, and bench-mark standards for virtual card usage 416 …”);
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 (FIG. 9, items 370, 372, 374; para 97, “… schematic block diagram of FIG. 9 shows an exemplary embodiment wherein multiple users (e.g., user ID #31 through user ID #39) can use virtual accounts such as virtual charge cards 370, 372 in order to participate in virtual financial transactions. When the virtual charge card is used, a record of the transaction is transmitted as indicated by arrows 373 for storage in a memory device 374 that keeps records for virtual credit arrangements. A processor 376 is operatively coupled to the memory device 374 and also to a transceiver 377 for bi-directional communication regarding the virtual financial transaction through link 378 with the users #31 through #39 …”; para 98, “… These same users #31 through #39 also have access to hybrid actual charge cards 380, 382 in order to participate in actual real-world financial transactions. When the hybrid actual charge card is used, a record of the transaction is transmitted as indicated by arrows 383 for storage in a memory device 385 that keeps records for real financial transactions. Such real financial transactions may or may not be related to a virtual credit arrangement … the hybrid actual charge card usage may be directly or indirectly related to a virtual credit arrangement, including but not limited to down payments, guarantees, compensation, renegotiation, resolution, transferability, etc. The details of such relationship will be communicated to the virtual credit arrangements storage memory device 374 as indicated by arrows 384. The bi-directional communication link 378 serves shared functional purposes for both the virtual charge card and the actual charge card, including but not limited to transmitting messages regarding credit terms associated with each different user ID account as well as feedback and status information for purchases, payments, negotiations, remuneration, and resolution involving the virtual credit arrangements …”; para 204, “… real time interaction may be initiated or received by players or other entities in the virtual world environment through links in the virtual world environment as shown by a real-world website link 1090 activated to commence at time 1091 and terminate at time 1093, a virtual environment link 1092 activated to commence at time 1095 and terminate at time 1097, and a real-world entity link 1094 activated to commence at time 1098 and terminate at time 1099. It is therefore to be understood that both unidirectional and bi-directional links across a boundary between a virtual world environment and a real-world location or real-world entity may be used to effectuate, implement, resolve or perpetuate a virtual world transaction or arrangement …”); and
deactivating the virtual card (FIG. 30, items 1092, 1097; para 204, “… real time interaction may be initiated or received by players or other entities in the virtual world environment through links in the virtual world environment as shown by a real-world website link 1090 activated to commence at time 1091 and terminate at time 1093, a virtual environment link 1092 activated to commence at time 1095 and terminate at time 1097, and a real-world entity link 1094 activated to commence at time 1098 and terminate at time 1099. It is therefore to be understood that both unidirectional and bi-directional links across a boundary between a virtual world environment and a real-world location or real-world entity may be used to effectuate, implement, resolve or perpetuate a virtual world transaction or arrangement …”; FIG. 39, 1145; para 221, “… The possibility of a player acquiring something of potential value pursuant to a credit transaction with another party (block 1103) may be based on enabled interaction in the virtual world environment between a debtor participant and a creditor participant regarding one or more of the following activities: creating the credit transaction, negotiating credit transaction terms, revising the credit transaction, resolving the credit transaction, transferring the debtor's obligation, transferring the creditor's rights, and terminating the credit transaction (block 1145) …”).
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 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.
Claims 15-16 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 Laracey (U. S. Patent Application Publication No. 20130238455 A1), herein referred to as Laracey, and in further view of Rozman et al (U. S. Patent Application Publication No. 20150235310 A1), herein referred to as Rozman.
As per claim 15, Anderson discloses a system for issuing an arrangement for use with an entity at a unique geographic location, the system comprising:
at least one processor (FIG. 2, item 114; para 46, “… Referring now to FIG. 2, a block diagram of a mobile device 110 is shown … mobile device 110 includes a display 112, a processor 114, a memory 116, a GPS 118 (or other location determining application), a camera 119, and the like …”; FIG. 9, items 906A, 906B, 906C; para 269, “… a processor 906A coupled to bus 904 for processing information and instructions … in 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. Conversely, system 900 is also well suited to having a single processor such as … processor 906A. Processors 906A, 906B, and 906C may be any of various types of microprocessors …”) configured to:
receive, from a mobile device (FIG. 2, item 110; para 46, “… Referring now to FIG. 2, a block diagram of a mobile device 110 is shown … mobile device 110 includes a display 112, a processor 114, a memory 116, a GPS 118 (or other location determining application), a camera 119, and the like …”; para 48, “… mobile device 110 is an example of a customer's mobile device. Mobile device 110 could be a mobile phone, a smart phone, a tablet, a smart watch, a piece of smart jewelry, smart glasses, or other customer portable devices having wireless telephony connectivity via a mobile service provider … mobile device 110 is also capable of broadcasting and receiving via at least one network, such as, but not limited to, WiFi, Bluetooth, near field communication (NFC), and the like …”), a unique token, wherein the unique token is linked to the entity at the unique geographic location (FIG. 4, item 263; para 95, “… Token generator 263 then generates a token identifying the customer data file … the token is an identification number, hash, or other type of anti-tamper encrypted protection that is generated as an identifier for the customer data file …”; para 96, “… BNPL product generator 265 generates a BNPL product pass 170 formatted for mobile wallet 129 … 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 …”; para 157, “… the BNPL product pass 170 includes a token … the token embedded in code 632 will also be added to the BNPL product pass 170 stored in mobile wallet 129 …”);
receive, from the mobile device, a first data associated with a requestor, wherein the first data includes one or more of a name, address, date of birth, and an identification number (FIG. 3, item 218; 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 …”; FIG. 3, items 218, 220, 223; 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 … 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 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. …”; FIG. 5B, item 520; para 118, “… With reference now to 520 of FIG. 5A and as shown and expanded in the flowchart 550 of FIG. 5B and shown in FIGS. 3 and 4, one embodiment utilizes device ID 216 and user ID 218 to obtain user specific information 223 useable for a credit screen and/or to prepopulate the BNPL application … 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 …”);
query, using the first data, a first database for a second data associated with the requestor (FIG. 3, item 16; para 77, “… uses 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 …”; );
receive the second data associated with the requestor, wherein the second data includes a credit score (para 126, “… This could be based on a customer's credit score, risk factors, or the like … if the customer has a credit score that is higher than a pre-defined threshold, the autopayment is not a requirement, such that if the customer chooses not to join an autopayment process, the ability to continue the BNPL application process is not interrupted …”); …
query, using the first data, a second database for a third data associated with the requestor (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 information 223 in order to identify any accounts related to the customer … customer account identifier 261 accesses database 227 via cloud 226 … Database 227 may include store specific data, brand specific data, retailer specific data, a shared database, a conglomerate database, a portion of a larger storage database, and the like. Moreover, database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof …”); …
issue the selected arrangement based on the input from the requestor and the third data, wherein the selected arrangement is for use by the requestor with the entity at the unique geographic location (FIG. 7, item 735; para 183, “… At 735, … provides, 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 …”).
Anderson does not specifically disclose, however, Laracey discloses generate a data structure comprising at least one table based on one or more of the unique token, the first data, and the second data, wherein the table contains information suitable to generate a variety of arrangement options (FIG. 10A, 10B; para 73, “… the customer may also register one or more discounts or offers in an offer database such as shown in FIG. l0A, and/or one or more loyalty program accounts such as shown in FIG. l0B … the discounts or offers stored or accessible in a database table such as that shown in FIG. 10A may be "clipped" or "accepted" by the customer by browsing a set of offers or discounts available to the customer (e.g., by interacting with an offer or discount selection system on their mobile device, or via a Web browser). Once an offer or discount has been accepted by the customer, details of the offer or discount may be stored in a table associated with the customer such as the table shown in FIG. 10A. Each offer or discount may be identified by an offer identifier 1028 and associated with the customer (e.g., via a user ID 1022 and a specific mobile device ID 1026) and may have offer details 1030, preferences or rules 1032, and possibly a balance 1034 …”; para 74, “… During the customer registration process (and subsequently, during account update transactions), the customer may provide information about one or more loyalty or reward accounts that the customer wishes to make available via their mobile device. This account information may be stored in a database table such as the illustrative table shown in FIG. l0B. Each loyalty account 1048 associated with a customer (e.g. via a user ID 1042 and a specific mobile device ID 1046) may have account details and one or more rules or preferences associated with the use of the loyalty account …”);
transmit the data structure to the mobile device (FIG. 11A, items 1102, 1130; para 188, “… The transaction management system 1130 may also use informa-tion associated with the customer, the transaction informa-tion, and the merchant to identify one or more offers or discounts available for use in the transaction (e.g., by consulting a database such as that shown in FIG. 10A). The transaction management system 1130 transmits a response "10" to the mobile device 1102 which includes information identifying a list of available payment accounts, the list of available payment accounts, information identifying a list of available offers or discounts, as well as the transaction details (obtained from the merchant, e.g., at message "2") … the information identifying a list of available payment accounts may include a reference number or identifier that allows the mobile payment application of the mobile device 1102 to cause a display of information to the customer associated with one of the available accounts … the reference number or identifier received from the list of available payment accounts received at "10" may be used by the mobile payment application to determine that the customer's Chase Credit Card is available for use in the transaction, and the mobile payment application may use that information to display an image or other information associated with the customer's Chase Credit Card on a display device of the mobile device 1102, allowing selection of the payment account by the customer … the information received at "10" may include detailed information about the available accounts, discounts and transaction details …”; FIG. 11B, items 1108, 1130; para 194, “… The offers or discounts available for use in the transaction may include offers or discounts established by the merchant 1108 for specific customers … referring to FIG. 10A, the customer named "Jane Doe" may be a frequent patron of "Mom & Pop Mexican Restaurant", and the restaurant may offer a frequent customer benefit such as "buy 10 burritos and get 1 free" … in transactions such as shown in FIG. 11B, allow such a retailer to track and administer such a program, and allow the customer to enjoy the discount during the transaction … a wide variety of types and combinations of offers, discounts, rewards, rebates and loyalty benefits may be administered in transactions pursuant to the present invention. Each transaction allows the system 1130 to apply a wide variety of rules, conditions and filters to determine which of such offers are available for use in a transaction …”;
receive, from the mobile device, an input from the requestor, wherein the input is indicative of a selected arrangement (FIG. 11A, items 10, 11, 1102, 1130; para 191, “… Referring again to the mobile device 1102 side of the transaction, the customer, operating the mobile device 1102 based on the information received at "10", may select one or more of the available payment accounts to use the transaction and may also select an offer or discount to apply to the transaction. The customer confirms or authorizes the transaction and transmits the selected payment account information and any selected offers or discounts to the transaction management system 1130 in message "11". The transaction management system 1130 uses the information from message "11" to update the pending transaction record. If a discount or offer was selected, the transaction management system 1130 calculates a new payment amount which is equal to the transaction amount received from the merchant (at "2" or the updated transaction amount received at "9") less the amount of the discount or offer …”); …
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, 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 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 (i.e., 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, all of which provide for completing a secure, cost efficient, and user-friendly transaction.
Anderson and Laracey do not specifically disclose, however, Rozman discloses receive, from the second database, the third data associated with the requestor, wherein the third data includes a credit score (para 33, “… An example report includes various information, including an identification of one or more pre-qualification messages that indicate that one or more lenders have pre-qualified the user for some type of product. If no such offers are available for a user, the report may include a likelihood of the user's ability to obtain lender financing. Or both types of information may be shown … a report may include an indication of one or more credit scores obtained from third party credit bureaus, as well as a discussion of the meaning of such scores …”; FIG. 8B, item 895; para 66, “… at block 895 various amounts of this education information may be provided by way of report to the user, including consumer credit score, credit report and credit score assessment …”; FIG. 9D, items 972-979; para 72, “… such consumer credit education information may include one or more of: a FICO consumer credit score; information regarding what consumer credit reports and scores are; information regarding how lenders view a given score (e.g., as exceptional, very good, good, not good, poor); and making available one or more consumer credit reports (blocks 972-979). Understand that while shown this particu-lar set of educational information in the embodiment of FIG. 9, the scope of the present invention is not so limited …”); …
Rozman discloses a system and method for gathering and presenting credit information and loan information for individuals and small businesses. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a system and method for gathering and presenting credit information and loan information for individuals and small businesses, as in Rozman; and to include methods and systems for selecting accounts and offers in payment transactions, as in Laracey, 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, methods, and computer program products providing prospective business borrowers information as to their likelihood of securing financing, educational content, and pre-qualification offers based upon independent (non-self-reported) data, regarding borrowing availability in real time with respect to one or more lenders via a third party technique, and also not affecting a customer’s credit score.
As per claim 16, Anderson, Laracey, and Rozman disclose all the limitations of claim 15. Anderson and Rozman do not disclose, however, Laracey discloses the method of claim 15, wherein the selected arrangement is in the form of a virtual card stored in a wallet associated with the mobile device (FIG. 3, item 306; para 76, “… the customer named "Jane" may also enter information about several loyalty or reward accounts she possesses, such as her Kroger shopping card number ("K123456"), her CVS discount card number ("C5554431") and her Groupon account number and password ("G434567" and "sam123"). Other information may be provided to allow the identification and access to one or more loyalty, reward or other accounts associated with the customer. By providing this account information, Jane is able to access or interact with her registered loyalty or reward accounts using her mobile wallet … Jane may also provide information identifying one or more discounts or offers she wishes to take advantage of. This information may be provided during processing at 306, or it may be provided during subsequent processing in which Jane clips or otherwise selects from a variety of offers or discounts that are available to her. Once she has clipped or otherwise selected an offer, details of the offer may be associated with her account information and be accessible to the transaction management system during transaction processing …”.
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 a system and method for gathering and presenting credit information and loan information for individuals and small businesses, as in Rozman, 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 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 (i.e., 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, all of which provide for completing a secure, cost efficient, and user-friendly transaction.
Claim 17 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, and in further view of Laracey (U. S. Patent Application Publication No. 20130238455 A1), herein referred to as Laracey.
As per claim 17, Anderson discloses a system for receiving an arrangement for use with an entity at a unique geographic location, the system comprising:
at least one processor (FIG. 2, item 114; para 46, “… Referring now to FIG. 2, a block diagram of a mobile device 110 is shown … mobile device 110 includes a display 112, a processor 114, a memory 116, a GPS 118 (or other location determining application), a camera 119, and the like …”; FIG. 9, items 906A, 906B, 906C; para 269, “… a processor 906A coupled to bus 904 for processing information and instructions … in 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. Conversely, system 900 is also well suited to having a single processor such as … processor 906A. Processors 906A, 906B, and 906C may be any of various types of microprocessors …”) configured to:
receive, at a mobile device (FIG. 2, item 110; para 46, “… Referring now to FIG. 2, a block diagram of a mobile device 110 is shown … mobile device 110 includes a display 112, a processor 114, a memory 116, a GPS 118 (or other location determining application), a camera 119, and the like …”; para 48, “… mobile device 110 is an example of a customer's mobile device. Mobile device 110 could be a mobile phone, a smart phone, a tablet, a smart watch, a piece of smart jewelry, smart glasses, or other customer portable devices having wireless telephony connectivity via a mobile service provider … mobile device 110 is also capable of broadcasting and receiving via at least one network, such as, but not limited to, WiFi, Bluetooth, near field communication (NFC), and the like …”), a unique token, wherein the unique token is linked to the entity at the unique geographic location (FIG. 4, item 263; para 95, “… Token generator 263 then generates a token identifying the customer data file … the token is an identification number, hash, or other type of anti-tamper encrypted protection that is generated as an identifier for the customer data file …”; para 96, “… BNPL product generator 265 generates a BNPL product pass 170 formatted for mobile wallet 129 … 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 …”; para 157, “… the BNPL product pass 170 includes a token … the token embedded in code 632 will also be added to the BNPL product pass 170 stored in mobile wallet 129 …”); …
transmit, from the mobile device (FIG. 2, item 110; para 46, “… Referring now to FIG. 2, a block diagram of a mobile device 110 is shown … mobile device 110 includes a display 112, a processor 114, a memory 116, a GPS 118 (or other location determining application), a camera 119, and the like …”; para 48, “… mobile device 110 is an example of a customer's mobile device. Mobile device 110 could be a mobile phone, a smart phone, a tablet, a smart watch, a piece of smart jewelry, smart glasses, or other customer portable devices having wireless telephony connectivity via a mobile service provider … mobile device 110 is also capable of broadcasting and receiving via at least one network, such as, but not limited to, WiFi, Bluetooth, near field communication (NFC), and the like …”), a first data to a computing device associated with the financial institution, wherein the first data includes one or more of a name, address, date of birth, and an identification number (FIG. 3, item 218; 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 …”; FIG. 3, items 218, 220, 223; 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 … 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 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. …”; FIG. 5B, item 520; para 118, “… With reference now to 520 of FIG. 5A and as shown and expanded in the flowchart 550 of FIG. 5B and shown in FIGS. 3 and 4, one embodiment utilizes device ID 216 and user ID 218 to obtain user specific information 223 useable for a credit screen and/or to prepopulate the BNPL application … 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 …”); …
present, on a screen of the mobile device, the variety of arrangement options (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 …”; FIG. 7, item 720, para 179, “… At 720, … provides, to mobile device 110 of the customer and from the BNPL product provider 230 computing system, the plurality of payment scenarios with associated terms … such as internet shopping or on a mobile device 110 during a real-world shopping experience, the customer may be provided with tender reminder messages for either rewards or "pay as low as" messaging. E.g., "if you use a BNPL product you will be able to make the purchase while paying as low as 25 dollars a month for 6 months" …”); …
receive, from the computing device associated with the financial institution, the selected arrangement, wherein the selected arrangement is for use by the requestor with the entity at the unique geographic location (FIG. 7, item 735; para 183, “… At 735, … provides, 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 …”).
Anderson does not specifically disclose, however, Laracey discloses transmit, from the mobile device, the unique token to a computing device associated with a financial institution (FIG. 1, items 102, 130; para 40, “… After a successful authentication process, the customer is prompted to scan, capture (or otherwise enter) a checkout token from a device associated with the merchant 108 (shown as interaction 112 between the mobile device 102 and the merchant 108). The checkout token is used … to link messages from the mobile device 102 and the merchant 108, and the transaction management system 130, so that transactions pursuant to the present invention may be accomplished. After capture of the checkout token, the mobile device 102 transmits the token to the transaction management system 130 in a customer transaction lookup request message (over communication path 114) …”; para 47, “… The transaction management system 130 may also be in communication with other financial transaction networks (such as ACH and EFT networks, private label networks, alternative payment systems such as Pay Pal®, or the like) to allow customers operating mobile devices 102 to conduct transactions using a wide variety of different forms of pay-ment instruments and accounts …”; para 117, “… If the transaction is successful (e.g., the transaction management system 230 is able to use the selected payment accounts to obtain a payment authorization from the financial institutions associated with the accounts), processing contin-ues at 442 where the mobile device 202 receives a transaction complete message …”) …
receive, from the computing device associated with the financial institution, a data structure comprising at least one table, wherein the at least one table contains information suitable to generate a variety of arrangement options (FIG. 11A, 11B; para 185, “… FIG. 11A depicts portions of a system configured pursuant to some embodiments which allows a consumer operating a mobile device 1102 to conduct a transaction with a merchant 1108 where the transaction involves one or more loyalty or reward accounts associated with the merchant 1108 as well as the application of one or more discounts, coupons or offers to the transaction … allow merchants that have loyalty programs to continue to operate their loyalty programs as usual … many grocery stores and pharmacies have store loyalty programs in which customers are issued cards or tokens that are swiped or presented at the point of sale during transactions at the retailer. The retailer's point of sale systems look up the account associated with the customer to determine whether the transaction may enjoy a discount or earn some other loyalty benefits … allow such retailers to continue to use such loyalty programs in transactions of the present invention … provide customers benefits in that customers no longer need to carry multiple discount or loyalty cards in their wallet - instead, the loyalty or discount account information is stored at or accessible to the transaction management system (e.g., in a database associated with the customer information, such as shown in FIGS. 9 and 10) …”);
generate, based on at least the data structure, the variety of arrangement options (FIG. 10A, 10B; para 73, “… the customer may also register one or more discounts or offers in an offer database such as shown in FIG. 10A, and/or one or more loyalty program accounts such as shown in FIG. 10B … the discounts or offers stored or accessible in a database table such as that shown in FIG. 10A may be "clipped" or "accepted" by the customer by browsing a set of offers or discounts available to the customer (e.g., by interacting with an offer or discount selection system on their mobile device, or via a Web browser). Once an offer or discount has been accepted by the customer, details of the offer or discount may be stored in a table associated with the customer such as the table shown in FIG. 10A. Each offer or discount may be identified by an offer identifier 1028 and associated with the customer (e.g., via a user ID 1022 and a specific mobile device ID 1026) and may have offer details 1030, preferences or rules 1032, and possibly a balance 1034 …”; para 74, “… During the customer registration process (and subsequently, during account update transactions), the customer may provide information about one or more loyalty or reward accounts that the customer wishes to make available via their mobile device. This account information may be stored in a database table such as the illustrative table shown in FIG. 10B. Each loyalty account 1048 associated with a customer (e.g. via a user ID 1042 and a specific mobile device ID 1046) may have account details and one or more rules or preferences associated with the use of the loyalty account …”); …
transmit, to the computing device associated with the financial institution, a selected arrangement of the variety of arrangements (para 127, “… Jane may then select to use her Starbucks gift card for the transaction by clicking on the image of the card and confirming her selection. The mobile device then transmits a payment request message to the transaction management server indicating that Jane wants to use her Starbucks gift card to complete a purchase associated with a particular checkout token for a particular amount. The transaction management server authorizes the transaction and sends a confirmation message to Jane and to the Starbucks point of sale system … Jane enjoys the ability to complete the transac-tion even if she forgot her purse or her Starbucks card ...”; FIG. 6, items 17, 602, 630; para 155, “… before generating and transmitting message "17", the customer selects which payment account he or she would like to use for the transaction. The customer may select from a variety of available payment accounts displayed by the mobile application on a display screen of the mobile device 602. The message transmitted at "17'' may include a code that represents the particular payment account to be used by the customer (that is, the actual payment account information is not transmitted at "17''- instead, a proxy or representation of the payment account is sent) …”).
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, 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 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 (i.e., 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, all of which provide for completing a secure, cost efficient, and user-friendly transaction.
Claims 18-20 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 Laracey (U. S. Patent Application Publication No. 20130238455 A1), herein referred to as Laracey, and in further view of Ebihara et al (JP 2015097014 A), herein referred to as Ebihara.
As per claim 18, Anderson and Laracey disclose all the limitations of claim 17. Anderson and Laracey do not disclose, however, Ebihara discloses the system of claim 17, wherein the data structure comprises a base table and an adder table (FIG. 3, items (a), (b); “… As shown in FIG. 3, the application risk rank table 133 stores a risk score (at the time of enrollment or an ongoing credit score) and an application risk rank in association with each other … it is possible to determine the application risk rank corresponding to the enrollment credit score or the enrollment credit score. The application risk rank can be managed for each card company type (hereinafter referred to as a company unit) such as whether the credit card is a proper card or a partner company card. Therefore, the application risk rank table 133 can be held for each company, and different risk rank systems can be applied to different card company types … the application risk rank can be set based on the risk score or can be set by taking in external data from the external system 108. Can be specified on a company basis …”; FIG. 3, “… Reference is now made to FIG. 3 is a diagram showing an example of the application risk rank table according to the embodiment of the present invention. The application risk rank table 133 stores the enrollment score or developing credit score and the application risk rank in association with each other. Therefore, the processing unit 120 identifies the application risk rank corresponding to the enrollment score determined in step S206 from the application card rank table 133 of the corresponding card company …”; FIG. 4, items (a), (b); “… The risk pricing fluctuation rate table 134 holds the interest rate fluctuation rate to be applied to each contract interest rate for each risk rank (for example, for each applied risk rank). The risk pricing fluctuation rate table 134 will be described in detail below with reference to FIG. 4, but the risk pricing fluctuation rate table 134 can also be held in units of companies in the same manner as the risk rank table …”).
It would have been obvious before the effective filing date to provide an application risk rank table and a risk pricing fluctuation rate table modifying the application risk rank table based on a risk pricing change rate, as in Ebihara. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to modify the base table with additional relevant information of the creditworthiness and profitability of an entity to automatically determine an updated risk rank or credit score.
As per claim 19, Anderson and Laracey disclose all the limitations of claim 17. Anderson, Laracey, and Ebihara disclose all the limitations of claim 18. Anderson and Laracey do not disclose, however, Ebihara discloses the system of claim 18, wherein the adder table discloses increased rates for a requestor with a low credit score (“… the latest rank among application risk ranks for a plurality of applications can be set as the customer risk rank, or the lowest (or highest) rank can be set as the customer risk rank …”; “… If one or more application risk ranks for the member are redetermined, a customer risk rank is determined in step S718 based on the redetermined application risk rank. When there is only one application for the same member, the processing unit 120 can make the customer risk rank equal to the application risk rank. The lowest of the application risk ranks may be the customer risk rank, or the latest rank may be the customer risk rank … a customer risk rank can be selected from a plurality of application risk ranks according to other conditions …”; FIG. 5; “… referring again to FIG. 5, in the example of FIG. 5, in the case of Mr. Yamada, the application risk rank has changed from “C” to “B” due to the annual review regarding the application for the proper card shopping rib. The pricing fluctuation rate is also changed from “−2.0%” to “−2.5%”, and the applicable interest rate is reduced from “10.0%” to “9.5%” … the application for the shopping card of the partner card, since the applied risk rank has changed from “C” to “B” due to the annual review, the risk pricing fluctuation rate has changed from “−1.5%” to “−2. 5% "and the applicable interest rate is reduced from" 13.5% "to" 12.5% " … in the case of Mr. Suzuki, at the time of enrollment, “-3.0” for the application of a cashing ribo with a contract interest rate of “16.0%” and for a shopping ribo with an interest rate of “14.0%”. % Risk pricing fluctuation rate was applied, but after that it became a “suspended qualification” and met the monthly credit status check, so the applicable risk rank was determined as “X” … the risk pricing fluctuation rate is “0.0%”, and the original contracted interest rates “16.0%” and “14.0%” are applied to each application … in the case of Mr. Sato, the risk pricing fluctuation rate of “-2.0%” was applied to the application for a cashing ribo with a contract interest rate of “16.0%”, but there were two arrears. The redetermined applied risk rank is “X”, the risk pricing fluctuation rate is “0.0%”, and the original contracted interest rate “16.0%” is applied as the applied interest rate. The number of delinquencies may be counted only for applications that are subject to risk pricing (for example, in this example, cashing ribo with a contract interest rate of “16.0%” by a proper card), or it is not subject to risk pricing. It is also possible to count the number of delinquent payments for an application (e.g., use of two-pay shopping) … regarding the monthly credit status check, in addition to whether or not a member is suspended due to a credit code or the number of delinquencies, an evaluation using an additional credit status indicator can be performed …”).
It would have been obvious before the effective filing date to provide an application risk rank table and a risk pricing fluctuation rate table modifying the application risk rank table based on a risk pricing change rate, as in Ebihara. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to modify the base table with additional relevant information of the creditworthiness and profitability of an entity to automatically determine an updated risk rank or credit score.
As per claim 20, Anderson and Laracey disclose all the limitations of claim 17. Anderson, Laracey, and Ebihara disclose all the limitations of claim 18. Anderson and Laracey do not disclose, however, Ebihara discloses the system of claim 18, wherein the base table reflects preferred rates negotiated by a vendor at the unique geographic location and the financial institution (FIG. 3, table 133; “… As shown in FIG. 3, the application risk rank table 133 stores a risk score (at the time of enrollment or an ongoing credit score) and an application risk rank in association with each other … it is possible to determine the application risk rank corresponding to the enrollment credit score or the enrollment credit score. The application risk rank can be managed for each card company type (hereinafter referred to as a company unit) such as whether the credit card is a proper card or a partner company card. Therefore, the application risk rank table 133 can be held for each company, and different risk rank systems can be applied to different card company types … the application risk rank can be set based on the risk score or can be set by taking in external data from the external system 108. Can be specified on a company basis …”; FIG. 3, table 134; “… The risk pricing fluctuation rate table 134 holds the interest rate fluctuation rate to be applied to each contract interest rate for each risk rank (for example, for each applied risk rank). The risk pricing fluctuation rate table 134 will be described in detail below with reference to FIG. 4, but the risk pricing fluctuation rate table 134 can also be held in units of companies in the same manner as the risk rank table …”).
It would have been obvious before the effective filing date to provide an application risk rank table and a risk pricing fluctuation rate table modifying the application risk rank table based on a risk pricing change rate, as in Ebihara. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to modify the base table with additional relevant information of the creditworthiness and profitability of an entity to automatically determine an updated risk rank or credit score.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Vyas et al (U. S. Patent No. 10997577 B2) – Systems And Methods Generating Electronic Tokens In Response To User Location
Vyas discloses a system, including: a non-transitory memory; and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations including: determining a first physical location of a user; comparing the first physical location to data indicative of network availability; and in response to comparing the first physical location to data indicative of network availability, generating a first electronic token and a second electronic token for a mobile computing device associated with the user.
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
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
September 24, 2026
