DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1-21 are pending in this instant application per original claims filed on 10/15/2024. Claims 1, 8 and 15 are independent claims reciting method, system and non-transitory computer-readable storage medium claims. Claims 2-7, 9-14 and 16-21 are respective dependent claims.
This Office Action is a non-final rejection on merits in response to the original claims filed by the Applicant on 15 OCTOBER 2024 for its original application of the same date that is titled: “Systems and Methods for Automatic Claims Settlement”.
Accordingly, pending claims 1-21 are now being rejected herein.
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-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more, wherein Claims 1, 8 and 15 are independent computer-implemented method, system and non-transitory computer-readable storage medium claims respectively.
Exemplary Analysis.
Claim 1: Ineligible.
The claim recites a series of steps. The claim is directed to a computer-implemented method reciting a series of steps, which is a statutory category of invention (Step 1 -- YES).
The claim is analyzed to determine whether it is directed to a judicial exception. The claim recites the limitations of: receiving a reimbursement request, wherein the reimbursement request includes an invoice and account information; processing the invoice to determine a reimbursement amount for the reimbursement request; transmitting a balance information application programming interface (API) call corresponding to the reimbursement request, wherein the API call includes the account information; receiving a transaction token and balance information associated with the payment, wherein the transaction token corresponds to a tokenized version of the payment; evaluating the reimbursement amount and the balance information to generate a determination, wherein the determination indicates whether fulfillment of the reimbursement request results in a negative balance for the payment, and wherein the determination is generated to prevent transmission of impermissible API calls corresponding to reimbursement requests that would not be fulfilled as a result of the negative balance; identifying a reimbursement method for the reimbursement request, wherein the reimbursement method is identified based on the determination; and wherein when the reimbursement API call is received at a service corresponding to the reimbursement method, the service uses the transaction token to provide the reimbursement amount according to the reimbursement method. In other words, the claim describes a framework through which automatic reimbursement for adjudicated claims is performed through dynamic evaluation of claims and of available reimbursement methods (per para [0002] in Specification, Field). These limitations, as drafted, are steps of a method that, under its broadest reasonable interpretation, covers performance of the limitations via a method of organizing human activity such as fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), and/or managing behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions), but for the recitation of generic computer/s and/or computer component/s such as the devices/ mobile devices. These limitations fall under the “certain methods of organizing human activity” group (Step 2A1 -- YES).
Next, the claim is analyzed to determine if it is integrated into a practical application. The claim recites additional elements of: a payment instrument (it has been considered as hardware based on Specification para [0048]). These additional elements are considered extra-solution activities. The devices and servers (service) in the steps are recited at a high level of generality, i.e., as generic processors performing generic computer/s functions of processing data. These generic processors are no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. Accordingly, these additional elements do not integrate the abstract idea into a practical application, because they do not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to the abstract idea (Step 2A2 -- NO).
Next, the claim is analyzed to determine if there are additional elements in this claim that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements in the claim amount to no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer and/or computer components over a network cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Because the additional elements described above were considered to be extra-solution activities in Step 2A, they are re-evaluated in Step 2B to determine if they are more than what is well-understood, routine and conventional in the field. The disclosure does not provide any indication that these devices (processors) are anything other than generic processors and the Symantec, TLI, and OIP Techs. court decisions (MPEP 2106.05 (d) (II)) indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here). Also, paras [0045]-[0050] of the Applicant’s own Specification describe (it has already been published as US Pub. No. 2025/ 0124480) ---
{“[0045] In an embodiment, once the claims reimbursement system 104 has determined, from the digitized version of the invoice 112, the payment amount being requested by the user 110, the claims reimbursement system 104 can determine whether the payment amount may be reimbursed to the user 110 through the selected reimbursement method. For example, if the user 110 has selected, as their reimbursement method, a particular payment instrument associated with the payment instrument service 108, the claims reimbursement system 104 may transmit an API call to the payment instrument service 108 to determine the existing balance (if any) associated with the particular payment instrument. This API call may include any available account information associated with the particular payment instrument that may be used by the payment instrument service 108 to identify the target payment instrument account and return the existing balance (if any) associated with this payment instrument. ………
[0046] In some instances, the API call to the payment instrument service 108 may include an access token or other authentication information that may be used by the payment instrument service 108 to authenticate the claims reimbursement system 104. This access token or other authentication information may be provided to the claims reimbursement system 104 through one or more available authentication processes (e.g., shared secrets, symmetric key cryptography, asymmetric key cryptography, etc.). Accordingly, in response to the API call from the claims reimbursement system 104, the payment instrument service 108 may authenticate the API call through evaluation of the provided access token or other authentication information. ……………………………………………………………………………………………………………………………
[0047] In response to the API call from the claims reimbursement system 104, the payment instrument service 108 may return the existing balance (if any) for the particular payment instrument selected by the user 110. Additionally, in some instances, the payment instrument service 108 may further return a transaction token 114 that may be used for any transactions between the claims reimbursement system 104 and the payment instrument service 108 for the particular payment instrument. The transaction token 114 may include a tokenized version of the particular payment instrument associated with the user 110. To generate the transaction token 114 corresponding to the particular payment instrument, the payment instrument service 108 may dynamically generate, in real-time, a unique payment instrument number that may be associated with the particular payment instrument selected for the present reimbursement. The unique payment instrument number may include one or more characteristics that may be used to associate the transaction token 114 with the payment instrument service 108. For instance, a certain number of digits associated with the unique payment instrument number may be fixed and may correspond to the payment instrument service 108. For instance, the unique payment instrument number may include an issuer identification number (IIN) or bank identification number (BIN), which may uniquely identify the payment instrument service 108. The remaining digits corresponding to the unique payment instrument number may be randomized and the complete unique payment instrument number may be automatically associated with the payment instrument selected by the user 110. ………
[0048] In addition to generating a unique payment instrument number for the transaction token 114, the payment instrument service 108 may assign an expiration date and Card Verification Value (CVV) or other security code for the transaction token 114. The combination of the unique payment instrument number, expiration date, and CVV or other security code may provide a unique combination of elements used to define a new transaction token 114 that may be uniquely associated with the pairing of the actual payment instrument selected by the user and the reimbursement for which the unique transaction token 114 is being generated. The transaction token 114, in an embodiment, is configured for a single use, whereby if a reimbursement is completed using the transaction token 114, the transaction token 114 is automatically expired by the payment instrument service 108. In some instances, the expiration date for the transaction token 114 may be short (e.g., one hour, two hours, one day, etc.) such that the transaction token 114 may be automatically expired if not used within a short window of time for the reimbursement. ………………………………………………………………………..
[0049] In an embodiment, prior to submitting an API call to the payment instrument service 108 to determine the existing balance associated with a selected payment instrument, the claims reimbursement system 104 queries a token vault 106 implemented by the claims adjudication service 102 to determine whether an existing stored token 116 corresponding to the selected payment instrument is stored within the token vault 106. The stored token 116 for a particular payment instrument may be similar to the transaction token 114 described above. For instance, the stored token 116 maintained in the token vault 106 may include a tokenized version of the particular payment instrument associated with the user 110. However, the stored token 116 may have a longer expiration date (e.g., one year, etc.), which may allow for continued retrieval of transaction tokens associated with the particular payment instrument without having to repeatedly provide payment instrument account information through the API call to the payment instrument service 108. This may reduce the payload size of any API calls to the payment instrument service 108, thereby reducing the required network bandwidth for obtaining transaction tokens. Further, by using a stored token 116, the amount of processing performed by the systems of the payment instrument service 108 is reduced, as these systems may not need to perform continued authentication of the claims reimbursement system 104 and evaluate payment instrument account information for generation of transaction tokens. ….
[0050] The stored token 116, in an embodiment, is provided by the payment instrument service 108 in exchange for a previously generated transaction token 114 associated with the selected payment instrument. For instance, if the token vault 106 does not maintain a stored token 116 for a particular payment instrument that is associated with a current claim reimbursement, the claims reimbursement system 104 may transmit a request to the payment instrument service 108 to obtain a stored token 116 corresponding to the particular payment instrument. This request may be transmitted to the payment instrument service 108 in response to an indication from the payment instrument service 108 that the reimbursement to the particular payment instrument was completed successfully. Once the claims reimbursement system 104 has obtained the stored token 116 from the payment instrument service 108, the claims reimbursement system 104 may store the stored token 116 in the token vault 106. For instance, the claims reimbursement system 104 may define a new entry corresponding to the payment instrument selected by the user 110 in the token vault 106. This new entry may include the payment instrument account information provided by the user 110. Once the claims reimbursement system 104 defines a new entry for the payment instrument or identifies an existing entry corresponding to the payment instrument, the claims reimbursement system 104 may associate the newly obtained stored token 116 with this entry within the token vault 106. This may allow the claims reimbursement system 104 to query the token vault 106 for the stored token 116 if the user 110 later submits a new reimbursement request that specifies the corresponding payment instrument as the preferred reimbursement method for the underlying claim. ”} ---
and indicate that the concept described by the extra-solution additional elements is conventional. Accordingly, a conclusion that the aforementioned extra-solution additional elements are well-understood, routine and conventional activity is supported under Berkheimer options 2 and 3, respectively.
Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional elements do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claim does not amount to significantly more than the recited abstract idea (Step 2B -- NO), and the claim is not patent eligible.
The analysis above applies to all statutory categories of the invention including independent system Claim 8 and independent non-transitory computer-readable storage medium Claim 15, which perform the steps similar to those of the independent computer-implemented method Claim 1. Furthermore, the limitations of dependent method Claims 2-7, further narrow the independent method Claim 1 with additional steps and limitations (e.g., generating a digitized version of the invoice, wherein the digitized version of the invoice is generated according to a machine-readable format, …; … wherein when the transaction token is received at the service, the service applies the reimbursement amount to an account associated with the payment instrument; transmitting a request to exchange the transaction token for a stored token, wherein the stored token corresponds to a second tokenized version of the payment instrument, and wherein the stored token is exchangeable for new transaction tokens associated with the payment instrument, …; the invoice is associated with a policy corresponding to an insured entity, …; wherein the reimbursement method corresponds to a payment method indicated on the invoice; and retrieving a stored token, wherein the stored token corresponds to the account information associated with the payment instrument; etc.), and do not resolve the issues raised in rejection of the independent method Claim 1. Similarly, dependent system Claims 9-14 and dependent non-transitory computer-readable storage medium Claims 16-21 also further narrow their independent Claims 8 and 15 respectively, which are rejected as ineligible for patenting under 35 U.S.C. 101 based upon the same analysis.
Therefore, said Claims 1-21 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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.
This application currently names joint inventors. In considering patentability of the claims the Examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. The Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the Examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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:
1.) Determining the scope and contents of the prior art.
2.) Ascertaining the differences between the prior art and the claims at issue.
3.) Resolving the level of ordinary skill in the pertinent art.
4.) Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-21 are rejected under 35 USC 103 as unpatentable over a combination of references (Ng, Bull and Tooke for all independent and dependent claims, plus Cella for some dependent claims) as described below for each claim/ limitation.
Independent Claim 1 is rejected under 35 USC 103 as unpatentable over Pub. No. US 2023/ 0196319 filed by Ng et al. (hereinafter “Ng”) in view of Pub. No. US 2023/ 0342737 filed by Bull et al. (hereinafter “Bull”), and further in view of US Patent no. 7,617,114 issued to Tooke, III et al. (hereinafter “Tooke”), and as described below for each claim/ limitation.
Examiner notes that all claims have been copied as recited by the Applicant to keep them readable and whole, even if the limitations within a claim that are not taught explicitly by the primary/previous reference (are noted in parentheses), but these limitations are noted explicitly as taught by a secondary/new reference whenever a secondary/new reference has been used.
Examiner notes that, for brevity in this rejection, the motivation statement has not been repeated herein every time a secondary reference has been used.
With respect to Claim 1, Ng teaches ---
1. A computer-implemented method, comprising:
receiving a reimbursement request, wherein the reimbursement request includes an invoice and account information corresponding to a payment instrument;
(see at least: Ng Abstract; and para [0002] about {“… and the customers provide the server with multiple payment instruments (e.g., credit cards or transaction cards), which often require customer signatures. …”}; and para [0016] about {“…… In such examples, the merchant may process multiple payments for the multiple bills, which often can necessitate the use of multiple payment instruments, multiple authorizations, and the like.”}; and para[0017] about {“...provide the customers with multiple bills (e.g., invoices) for the purchased items …”}; and para [0018] about {“…… systems and methods disclosed herein reduce network congestion, network calls, or bandwidth associated with reimbursement requests …”}; and para [0033] about {“...receiving payment data from a payment instrument or payment application 120, initiating or processing payments associated with transactions, receiving indications that payments for transactions are complete, or any combination thereof. …”}; and para [0035] about {“…… one or more identifiers associated with a payment instrument. For example, a payment instrument of the customer may include a card having one or more magnetic strips for providing card and customer information when swiped in a card reader. In other examples, other types of payment instruments may be used, ...... In other examples, other types of payment instruments can include cards or devices that communicate via radio frequencies such as radio frequency identification tags, near field communication devices, etc. In some examples, the payment instrument can be a payment identifier in a particular syntax or format, …”}; and para [0036] about {“….an identifier of a payment instrument (e.g., payment card number, account credentials, or other payment device identifier), a time, location (e.g., street address, GPS coordinates, IP address, etc.) and date of the transaction, the payment card network 140 associated with the payment instrument, an issuing bank of the payment instrument, …”}; and para [0042] about {...... Each of the accounts of customer accounts 132 may include information related to the respective balance and transaction history associated with each customer account. Each of the accounts of customer accounts 132 may include one or more balances associated with a payment service and further include access to external bank accounts. …”}; and para [0066] about {“Customers can provide identification data 206, such as account information or the like, for accessing or registering with the payment service 210 (e.g., via payment application 204). …”}; and para [0182] about {“……Other user accounts of the user account(s) 904 can be similarly structured to the user account 920, according to some examples. In other examples, other user accounts may include more or less data and/or account information than that provided by the user account 920. In at least one example, the user account 920 can include user account data 928, which can include, but is not limited to, data associated with user identifying information …”}; and para [0194] about {“In at least one example, the user account 920 can be associated with an asset wallet 940. The asset wallet 940 of the user can be associated with account information that can be stored in the user account data 928 and, in some examples, can be associated with the user wallet key(s) 932. …”}; which together are the same as claimed limitations above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, and ‘account information’)
Ng teaches ---
processing the invoice to (determine a reimbursement amount) for the reimbursement request;
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’)
Ng teaches as disclosed above, but it may be argued that it may not explicitly disclose about ‘determine a reimbursement amount’. However, Bull teaches it explicitly.
(see at least: Bull Abstract and Brief Summary of the Disclosure in paras [0004]--[0128]; and para [0054] about {“……The policy engine applies a second policy to the data to determine a reimbursement amount based on the first monetary amount of the transaction. The server electronically provides, via the computer network, the reimbursement amount to a second purse of the electronic account. The second purse can be different from the first purse.”}; and para [0061] about {“…… The policy engine applies a second policy to the data to determine a reimbursement amount based on the first monetary amount of the transaction. The transaction engine provides, via a network, the reimbursement amount to a second purse of the electronic account, the second purse different from the first purse.”}; and para [0062] about {“In some embodiments, the server provides a real-time notification of the reimbursement amount responsive to transferring the reimbursement amount to the second purse of the electronic account. In some embodiments, the server determines that the first purse of the electronic purse is configured for prescription purchases. …”}; and para [0218] about {“...... The second policy can be associated with a monetary amount, transaction amount, or reimbursement amount. The policy engine 212 can use the second policy to determine a reimbursement amount. The policy engine 212 can use a reimbursement policy. The reimbursement policy can be applied to the data that identifies the transaction amount, merchant category, and electronic account. …… Using this reimbursement policy, the policy engine 212 can determine a reimbursement amount. …”}; and para [0219] about {“Responsive to determining the reimbursement amount, the policy engine 212 can further select a second purse of the electronic account for the reimbursement. …”}; and para [0222] about {“…… The claims processor 220 can process an insurance claim to determine a reimbursement amount. The claims processor 220 can be configured to use one or more policies or rules to process the insurance claim and determine a reimbursement amount .…… The claims processor 220 can adjudicate the claim, determine a reimbursement amount, and provide an indication to the system 120 regarding the reimbursement amount. The indication can identify the electronic account, user identifier, time, original transaction amount, reimbursement policy, or reimbursement amount. …”}; and para [0223] about {“The system 120, upon receiving the indication of the reimbursement amount from the claims processor 220, can select a second policy to determine to which purse of the multipurse electronic account to transfer the reimbursement amount. …”}; and para [0228] about {“…… At step 320, the server applies a second policy to the data to determine a reimbursement amount. At step 325, the server electronically provides the reimbursement amount to a second purse of the electronic account.”}; and para [0235] about {“At step 320, the server applies a second policy to the data to determine a reimbursement amount. The second policy can refer to a policy that determines an amount of the transaction amount that is to be reimbursed to the electronic account. …”}; and para [0236] about {“The second policy can include one or more policies that facilitate determining a reimbursement amount or a purse to which the reimbursement amount to be allocated. For example, the reimbursement policy can include: if prescription purchase at qualified merchant category, then reimbursement amount is 70% of the prescription amount. In some embodiments, the reimbursement amount can be an absolute value …”}; and para [0288] about {“……… The claims processor 220 can process an insurance claim to determine a reimbursement amount. The claims processor 220 can be configured to use one or more policies or rules to process the insurance claim and determine a reimbursement amount. …… The claims processor 220 can adjudicate the claim, determine a reimbursement amount, and provide an indication to the MPTS 408 regarding the reimbursement amount. …”}; and para [0308] about {“…… For example, the MPTS 408 can be configured to use the determination to identify multiple electronic reimbursement accounts, to provide a qualifying amount to a reimbursement account, or to notify a user associated with the electronic benefits account that the amount of expenditures qualifying under the electronic benefits account is different from the total amount of expenditures. …”}; which together are the same as claimed limitations above to include ‘determine a reimbursement amount’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Ng with the teachings of Bull. The motivation to combine these references would be to allow customers to write down the amounts owed by an individual customer on the back of the bill or instruct the server to charge specific amounts to the payment instruments (see para [0002] of Ng), and in managing electronic transaction portals connected to heterogeneous electronic funding sources for funding electronic benefits accounts (see para [0002] of Bull).
Examiner notes that Bull reference also teaches about related limitations such as “multiple electronic reimbursement accounts” and “electronic benefits account” and “electronic reimbursement configured to allow transactions” and “total amount of expenditures is reimbursed” and “execute a reimbursement transaction” and “maintaining the reimbursement policy” and “electronic reimbursement account is updated” and “determine that that the maximum amount of expenditures in a particular time period or billing cycle will be exceeded if the total amount of expenditures is reimbursed”, which together are the same as claimed ‘a reimbursement request’ per BRI rules.
Ng and Bull teach ---
transmitting a balance information application programming interface (API) call corresponding to the reimbursement request, wherein the API call includes the account information;
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’; and para [0041] about {“…… In some examples, the payment processing service 126 and P2P service 186 can be integrated via one or more application programming interface(s) (API(s)), software developer kit(s) (SDK(s)), or the like.”}; and para [0042] about {“According to one example, data store 128 may be used to store merchant accounts 130 and customer accounts 132, among other data. Customer accounts 132 may store records of customer accounts associated with each user of payment service 108. …… Each of the accounts of customer accounts 132 may include information related to the respective balance and transaction history associated with each customer account. Each of the accounts of customer accounts 132 may include one or more balances associated with a payment service and further include access to external bank accounts. …”}; and para [0169] about {“……In some examples, the service provider can send additional or alternative information to the instances of the payment application 818 (e.g., low balance to the payor, current balance to the payor or the payee, etc.). …”}; which together are the same as claimed limitations above to include ‘API’ and ‘a balance information’)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’; and para [0014] about {“......an electronic benefits account transaction application programming interface (“API”) configured to receive transaction requests from the plurality of heterogeneous electronic funding sources, and configured to receive, via the electronic benefits account transaction API, …”}; and para [0226] about {“…… The request for information can include information about a balance of the electronic account, available purses, balance of an individual purse, status of a reimbursement, policies associated with purses, or transaction history. …”}; and para [0304] about {“……The request for information can include information about a balance of the electronic account, available purses, balance of an individual purse, status of an adjudication associated with the account, status of a reimbursement, status of an update notification, policies associated with purses, policies associated with adjudication, or transaction history. ...... For example, a first security level requiring a first item of authentication information can be associated with information such as a balance of the electronic account, …”}; and para [0361] about {“…… an electronic benefits account application programming interface (“API”) configured to receive transaction requests from the plurality of heterogeneous electronic funding sources 702a-n via the client devices 102a-n. …”}; and para [0421] about {“In some embodiments, the server receives a request for account information from a device. The request for information can include information about a balance of the electronic benefits account (e.g., an in-process transaction amount, a reportable contribution amount, a virtual transaction balance), enforcement rules, or transaction histories. …”}; which together are the same as claimed limitations above to include ‘API’ and ‘a balance information’)
Ng and Bull teach ---
receiving a transaction token and balance information associated with the payment instrument, wherein the transaction token corresponds to a tokenized version of the payment instrument;
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; and para [0028] about {“…… As yet another example, items associated with a transaction can be apportioned to indicate which user account such items are to be associated with. As an example, if a transaction includes multiple non-fungible tokens (NFTs) or content items, individual users associated with the transaction can indicate which NFTs or content items to associate with each of their user accounts. …”}; which together are the same as claimed limitations above to include ‘a transaction token’ and ‘a tokenized version of the payment instrument’)
Examiner notes that, as taught by Ng above, NFTs can represent transactions, because they are unique digital assets that utilize smart contracts to manage transactions; and thus, NFT can be ‘a transaction token’.
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’ and ‘a balance information’)
Ng and Bull teach ---
evaluating the reimbursement amount and the balance information to generate a determination, wherein the determination indicates whether fulfillment of the reimbursement request results in (a negative balance) for the payment instrument, and wherein the determination is generated to prevent transmission of impermissible API calls corresponding to reimbursement requests that would not be fulfilled as a result of (the negative balance);
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; plus ‘a transaction token’ and ‘a tokenized version of the payment instrument’)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’ and ‘a balance information’)
Ng and Bull teach as disclosed above, but they may not explicitly disclose about ‘a/ the negative balance’. However, Tooke teaches it explicitly.
(see at least: Tooke Abstract; and Claims 1, 8 and 15 about {“…the benefits manager computer deducting the requested reimbursement from the employee's health savings account balance, wherein the resulting balance is negative; the benefits manager computer transferring the deducted reimbursement to the health service provider computer making the first request to effect an electronic funds transfer therefor; …… the benefits manager computer receiving an electronic funds transfer from the insurance company computer to provide reimbursement for the covered portion; the benefits manager computer deducting at least some of the outstanding negative balance from the amount for reimbursement to compensate for the employee's negative balance; …”}; which together are the same as claimed ‘a/the negative balance’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Ng and Bull with the teachings of Tooke. The motivation to combine these references would be to allow customers to write down the amounts owed by an individual customer on the back of the bill or instruct the server to charge specific amounts to the payment instruments (see para [0002] of Ng), and in managing electronic transaction portals connected to heterogeneous electronic funding sources for funding electronic benefits accounts (see para [0002] of Bull), and to permit health insurance providers that are under increased pressure to become more flexible and responsive while still maintaining adequate safeguards in managing limited health care resources (see C1,~L25-40 of Tooke).
Ng, Bull and Tooke teach ---
identifying a reimbursement method for the reimbursement request, wherein the reimbursement method is identified based on the determination; and
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; plus ‘a transaction token’ and ‘a tokenized version of the payment instrument’)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’ and ‘a balance information’; and para [0247] about {“……Systems and methods of the present solution can adjudicate a single claim against the electronic benefits account (e.g., determine that the single claim is approved for reimbursing an electronic account by an amount of expenditures associated with the electronic transaction) and provide notifications relating to such claims. …”}; which together are the same as claimed limitations above to include ‘a/the reimbursement method’ and ‘based on the determination’ per BRI rules)
(see at least: Tooke ibidem and citations listed above to include ‘a/the negative balance’)
Ng, Bull and Tooke teach ---
transmitting a reimbursement API call corresponding to the reimbursement request and according to the reimbursement method, wherein the reimbursement API call includes the transaction token, and wherein when the reimbursement API call is received at a service corresponding to the reimbursement method, the service uses the transaction token to provide the reimbursement amount according to the reimbursement method.
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; plus ‘a transaction token’ and ‘a tokenized version of the payment instrument’; and ‘P2P service 186’ and ‘payment service 108’; and para [0018] about {“…… systems and methods disclosed herein reduce network congestion, network calls, or bandwidth associated with reimbursement requests. …”}; which together are the same as claimed limitations above to include ‘a reimbursement API call’ per BRI rules)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’ and ‘a balance information’ plus ‘a/the reimbursement method’)
(see at least: Tooke ibidem and citations listed above to include ‘a/the negative balance’)
Dependent Claims 2-3 & 5-6 are rejected under 35 USC 103 as unpatentable over Ng in view of Bull and Tooke as applied to the rejection of independent Claim 1 above, and as described below for each claim/ limitation.
With respect to Claim 2, Ng, Bull and Tooke teach ---
2. The computer-implemented method of claim 1, wherein processing the invoice includes:
generating a digitized version of the invoice, wherein the digitized version of the invoice is generated according to a machine-readable format; and
dynamically evaluating the digitized version of the invoice to determine the reimbursement amount.
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; plus ‘a transaction token’ and ‘a tokenized version of the payment instrument’; and ‘P2P service 186’ and ‘payment service 108’; and ‘a reimbursement API call’; and para [0072] about {“.....the interactive element can be presented on or with: a printed bill or receipt associated with the transaction, …… a digital receipt user interface (e.g., a user interface that presents data associated with the transaction, payment, and the like), …”}; which together are the same as claimed limitations above to include ‘a/the digitized version of the invoice’ per BRI rules)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’ and ‘a balance information’ plus ‘a/the reimbursement method’)
(see at least: Tooke ibidem and citations listed above to include ‘a/the negative balance’)
With respect to Claim 3, Ng, Bull and Tooke teach ---
3. The computer-implemented method of claim 1, wherein the determination indicates that fulfillment of the reimbursement request does not result in the negative balance for the payment instrument, and wherein when the transaction token is received at the service, the service applies the reimbursement amount to an account associated with the payment instrument.
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; plus ‘a transaction token’ and ‘a tokenized version of the payment instrument’; and ‘P2P service 186’ and ‘payment service 108’; and ‘a reimbursement API call’; and ‘a/the digitized version of the invoice’)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’, ‘a balance information’ plus ‘a/the reimbursement method’; and paras [0225] & [0300] for “reimbursement complete” as in {“…… the notifications can include status information regarding the reimbursement transaction (e.g., processing reimbursement, reimbursement approved, reimbursement denied, reimbursement submitted for transfer, transferring reimbursement, or reimbursement complete). …”}; which are the same as claimed limitations above to include ‘fulfillment of the reimbursement request’ per BRI rules)
(see at least: Tooke ibidem and citations listed above to include ‘a/the negative balance’; and C14,~L3-13 about {“Before enabling the withdrawal, the health care intermediary 150 settles pending transactions. This typically includes completing all transactions and debiting the HSA 425 to reimburse health care providers for health care provided. For example, the health care intermediary 150 may receive the request to withdraw funds and determine that several transactions for reimbursement have not been completed and the health care providers have not been compensated. Implementations may include waiting for a certain time to elapse to ensure that there are no pending transactions that may not be reimbursed before the withdrawal.”}; which together are the same as claimed limitations above to include ‘fulfillment of the reimbursement request’)
With respect to Claim 5, Ng, Bull and Tooke teach ---
5. The computer-implemented method of claim 1, wherein:
the invoice is associated with a policy corresponding to an insured entity; and
the computer-implemented method further comprises identifying a set of reimbursement methods corresponding to the insured entity, wherein the set of reimbursement methods are identified based on the policy.
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; plus ‘a transaction token’ and ‘a tokenized version of the payment instrument’; and ‘P2P service 186’ and ‘payment service 108’; and ‘a reimbursement API call’; and ‘a/the digitized version of the invoice’)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’, ‘a balance information’ plus ‘a/the reimbursement method’; and para [0222] about {“In some embodiments, the policy engine 212 can receive an indication from a claims processor 220 external to the system 120 via network 104. …… The claims processor 220 can process an insurance claim to determine a reimbursement amount. The claims processor 220 can be configured to use one or more policies or rules to process the insurance claim and determine a reimbursement amount. The policies can be based on a type of insurance coverage associated with a user of the electronic account. The claims processor 220 can automatically receive the insurance claim responsive to a user conducting a transaction using the multipurse card connected with the electronic account. …… The claims processor 220 can adjudicate the claim, determine a reimbursement amount, and provide an indication to the system 120 regarding the reimbursement amount. The indication can identify the electronic account, user identifier, time, original transaction amount, reimbursement policy, or reimbursement amount.”}; and para [0235] about {“At step 320, the server applies a second policy to the data to determine a reimbursement amount. The second policy can refer to a policy that determines an amount of the transaction amount that is to be reimbursed to the electronic account. This second policy can be based on an insurance policy, claim policy, plan information, or benefits information. This second policy can include adjudication an insurance claim. …”}; and paras [0276] & [0278]; and para [0288] about {“..... The claims processor 220 can process an insurance claim to determine a reimbursement amount. The claims processor 220 can be configured to use one or more policies or rules to process the insurance claim and determine a reimbursement amount. The policies can be based on a type of insurance coverage associated with a user of the electronic account. …… The claims processor 220 can adjudicate the claim, determine a reimbursement amount, and provide an indication to the MPTS 408 regarding the reimbursement amount. The indication can identify the electronic account, user identifier, time, original transaction amount, reimbursement policy, or reimbursement amount.”}; which together are the same as claimed limitations above to include ‘a policy corresponding to an insured entity’ and ‘a/the set of reimbursement methods’)
(see at least: Tooke ibidem and citations listed above to include ‘a/the negative balance’)
With respect to Claim 6, Ng, Bull and Tooke teach ---
6. The computer-implemented method of claim 1, wherein the reimbursement method corresponds to a payment method indicated on the invoice.
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; plus ‘a transaction token’ and ‘a tokenized version of the payment instrument’; and ‘P2P service 186’ and ‘payment service 108’; and ‘a reimbursement API call’; and ‘a/the digitized version of the invoice’; and para [0018] about {“The systems and methods described herein greatly streamline processes for apportioning payments by enabling merchant devices and customer devices to exchange data via a payment service. As such techniques described herein, allow customers to use their computing devices to collaborate on payment through use of interactive elements presented on bills, receipts, or graphical user interfaces on computing devices, such as merchant devices or customer devices. …”}; and para [0060] about {“In some examples, cash, check, or other payment method can be used for providing payment for amounts of a transaction allocated to respective customers 104 and 156. In some examples, the payment service 108 can track individual payments and settle the transaction, as individual payments are received or when all payments have been received. …”}; and para [0068] about {“Furthermore, while the description references a customer being able to pay the merchant through merchant- or payment service-generated codes, in additional or alternative examples, the “scan-to-pay” method described herein may refer to, for example, a process of generating an interactive element on a customer device, and the merchant device 105 reading information in the interactive element using a sensor device, and sending the information to the payment service 108 to initiate a payment. …”}; and para [0073] about {“Payment service 370 can provide (308a) the interactive element to customer device 380 via a text message, email, in-app notification (e.g., presented via a payment application 378), instant application, or other communication methods for displaying on customer device 380 associated with payment application 378. Customer device 380 can correspond to either customer device 103 or 158 and payment application 378 can correspond to payment application 120 of FIG. 1. …… The merchant device 368 can print a bill or receipt with the interactive element or can present the interactive element on a display of merchant device 368. Accordingly, customer device 380 can receive the interactive element directly from payment service 370 or indirectly from merchant device 368 (e.g., on a printed bill, receipt, or display).”}; and paras [0083] & [0085]; and para [0200] about {“…….. That is, based at least in part on receiving an indication of which payment method a user (e.g., customer or merchant) intends to use for a transaction, techniques described herein utilize an integration between a peer-to-peer payment platform and payment processing platform (which can be a first- or third-party integration) such that a QR code, or other transaction code, specific to the transaction can be used for providing transaction details, location details, customer details, or the like to a computing device of the customer, such as the user device 808(A), to enable a contactless (peer-to-peer) payment for the transaction.”}; which together are the same as claimed limitations above to include ‘a payment method indicated on the invoice’)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’, ‘a balance information’ plus ‘a/the reimbursement method’)
(see at least: Tooke ibidem and citations listed above to include ‘a/the negative balance’)
Dependent Claims 4 & 7 are rejected under 35 USC 103 as unpatentable over Bull in view of Ng and Tooke as applied to the rejection of Claims 1-3 & 5-6 above, and further in view of Pub. No. US 2025/ 0199512 filed by Cella et al. (hereinafter “Cella”), and as described below for each claim/ limitation.
With respect to Claim 4, Ng, Bull and Tooke teach ---
4. The computer-implemented method of claim 1, further comprising:
transmitting a request to exchange the transaction token for a stored token, wherein the stored token corresponds to a second tokenized version of the payment instrument, and wherein the stored token is exchangeable for new transaction tokens associated with the payment instrument; and
obtaining the stored token, wherein when the stored token is obtained, the transaction token is automatically expired.
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; plus ‘a transaction token’ and ‘a tokenized version of the payment instrument’; and ‘P2P service 186’ and ‘payment service 108’; and ‘a reimbursement API call’; and ‘a/the digitized version of the invoice’; and ‘a payment method indicated on the invoice’)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’, ‘a balance information’ plus ‘a/the reimbursement method’)
(see at least: Tooke ibidem and citations listed above to include ‘a/the negative balance’)
Ng, Bull and Tooke teach as disclosed above, but they may not explicitly disclose about ‘a request to exchange …… for a stored token’. However, Cella teaches it explicitly.
(see at least: Cella Abstract and Summary in paras [0010]-[0055]; and para [0201] about {“Without limitation to any other aspect or description of the present disclosure, a token includes any token including, without limitation, a token of value, such as collateral, an asset, a reward, such as in a token serving as representation of value, such as a value holding voucher that can be exchanged for goods or services. Certain components may not be considered tokens individually, but may be considered tokens in an aggregated system—for example, a value placed on an asset may not be in itself be a token, but the value of an asset may be placed in a token of value, such as to be stored, exchanged, traded, and the like. For instance, in a non-limiting example, a blockchain circuit may be structured to provide lenders a mechanism to store the value of assets, where the value attributed to the token is stored in a distributed ledger of the blockchain circuit, but the token itself, assigned the value, may be exchanged or traded such as through a token marketplace. In certain embodiments, a toke may be considered a token for some purposes but not for other purposes—for example, a token may be used to as an indication of ownership of an asset, but this use of a token would not be traded as a value where a token including the value of the asset might. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered a token herein, while in certain embodiments a given system may not be considered a token herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a token and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation, access data such as relating to rights of access, tickets, and tokens; use in an investment application such as for investment in shares, interests, and tokens; a token-trading application; a token-based marketplace; forms of consideration such as monetary rewards and tokens; translating the value of a resources in tokens; a cryptocurrency token; indications of ownership such as identity information, event information, and token information; a blockchain-based access token traded in a marketplace application; pricing application such as for setting and monitoring pricing for contingent access rights, underlying access rights, tokens, and fees; trading applications such as for trading or exchanging contingent access rights or underlying access rights or tokens; tokens created and stored on a blockchain for contingent access rights resulting in an ownership (e.g., a ticket); and the like.”}; and para [0270]; which together are the same as claimed limitations above to include ‘a request to exchange …… for a stored token’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Ng, Bull and Tooke with the teachings of Cella. The motivation to combine these references would be to allow customers to write down the amounts owed by an individual customer on the back of the bill or instruct the server to charge specific amounts to the payment instruments (see para [0002] of Ng), and in managing electronic transaction portals connected to heterogeneous electronic funding sources for funding electronic benefits accounts (see para [0002] of Bull), and to permit health insurance providers that are under increased pressure to become more flexible and responsive while still maintaining adequate safeguards in managing limited health care resources (see C1,~L25-40 of Tooke), and to allow lending transactions that are plagued by problems such as opacity and asymmetry of information, moral hazard induced by shifting of the consequences of risky or inappropriate behavior, complexity of application and negotiation processes, burdensome regulatory and policy regimes, difficulty in determining the value of property that is used as collateral or backing for obligations, difficulty in determining the reliability or financial health of entities, and others (see para [0009] of Cella).
With respect to Claim 7, Ng, Bull, Tooke and Cella teach ---
7. The computer-implemented method of claim 1, wherein receiving the transaction token further includes:
retrieving a stored token, wherein the stored token corresponds to the account information associated with the payment instrument; and
transmitting the stored token, wherein when the stored token is received at a payment instrument service associated with the payment instrument, the payment instrument service provides the transaction token.
(see at least: Ng ibidem and citations listed above to include ‘a/the reimbursement request’, ‘an invoice’, ‘a payment instrument’ and “payment application 120”, plus ‘account information’, ‘API’ and ‘a balance information’; plus ‘a transaction token’ and ‘a tokenized version of the payment instrument’; and ‘P2P service 186’ and ‘payment service 108’; and ‘a reimbursement API call’; and ‘a/the digitized version of the invoice’; and ‘a payment method indicated on the invoice’)
(see at least: Bull ibidem and citations listed above to include ‘determine a reimbursement amount’, ‘API’, ‘a balance information’ plus ‘a/the reimbursement method’)
(see at least: Tooke ibidem and citations listed above to include ‘a/the negative balance’)
(see at least: Cella ibidem and citations listed above to include ‘a request to exchange …… for a stored token’; and para [0307] for {‘back a payment obligation’…with …’tokens of value’}; which together are the same as claimed limitations above )
With respect to Claims 8-14, the limitations of these system claims are rejected under 35 USC 103 based on the exemplary analysis above for the rejection of method Claims 1-7 as described above using cited references of Ng, Bull, Tooke and Cella, because the limitations of these system Claims 8-14 are commensurate in scope to limitations, and thus duplicates, of the above rejected method Claims 1-7 as described above.
With respect to Claims 15-21, the limitations of these non-transitory computer-readable storage medium claims are rejected under 35 USC 103 based on the exemplary analysis above for the rejection of method Claims 1-7 as described above using cited references of Ng, Bull, Tooke and Cella, because the limitations of these non-transitory computer-readable storage medium Claims 15-21 are commensurate in scope to limitations, and thus duplicates, of the above rejected method Claims 1-7 as described above.
Conclusion
The prior art made of record and not relied upon, listed in Form 892, that is considered pertinent to the Applicant's disclosure and review for not traversing already issued patents and/or claimed inventions by the claims of the current invention of the Applicant. Examiner notes that Form 892 contains more references than those cited in the rejection above under 35 USC 103, and that all the references cited on said Form 892 are relevant to this application and form a part of the body of prior art.
The Examiner has pointed out particular references contained in the prior art of record in the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. The Applicant should consider the entire prior art as applicable as to the limitations of the claims.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Sanjeev Malhotra whose telephone number is (571) 272-7292. The Examiner can normally be reached during Monday-Friday between 8:30-17:00 hours on a Flexible schedule.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, the Applicant is encouraged to contact the Examiner directly.
If attempts to reach the Examiner by telephone are unsuccessful, the examiner’s
supervisor, Abhishek Vyas, can be reached on (571) 270-1836. The facsimile/fax phone number for the organization, where this application or proceeding is assigned, is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center & https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Electronic Communications
Prior to initiating the first e-mail correspondence with an Examiner, Applicant is
responsible for filing a written statement with the USPTO in accordance with MPEP §502.03(II). All received e-mail messages including e-mail attachments shall be placed into this application’s record. The Examiner’s e-mail address is provided below at the end of this Office Action.
/S.M./
Examiner, Art Unit 3691
sanjeev.malhotra@uspto.gov
/HANI M KAZIMI/Primary Examiner, Art Unit 3691