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
Claim 1, 3-11, and 13-22 are currently pending and rejected.
Claim 2 and 12 are canceled.
Claim Rejection – 35 U.S.C. 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, 3-11, and 13-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The rationale for this finding is explained below. In the instant case, the claims are directed towards identifying purchase amount and tax amount in a transaction and transferring the purchase amount and tax amount separately to different accounts. The concept is related to managing human transactions, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. The claims do not include limitations that are “significantly more” than the abstract idea because the claims do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Note that the limitations, in the instant claims, are done by the generically recited computer device. The limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry. Therefore, claims 1, 3-11, and 13-22 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Step 1: The claims 1, 3-11, and 13-22 are directed to a process, machine, manufacture, or composition matter.
In Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014), the Supreme Court applied a two-step test for determining whether a claim recites patentable subject matter. First, we determine whether the claims at issue are directed to one or more patent-ineligible concepts, i.e., laws of nature, natural phenomenon, and abstract ideas. Id. at 2355 (citing Mayo Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1296–96 (2012)). If so, we then consider whether the elements of each claim, both individually and as an ordered combination, transform the nature of the claim into a patent-eligible application to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself.
Claims 1-10 are directed to a process (i.e., method claims).
Claims 11-19 are directed to a machine (i.e., apparatus claims).
Claims 20-22 are directed to a manufacture (i.e., computer product claim).
Step 2A: The claims are directed to an abstract idea.
Prong One
The present claims are directed towards identifying purchase amount and tax amount in a transaction and transferring the purchase amount and tax amount separately to different accounts. The concept comprises receiving a digital transaction request, determining a purchase amount and a tax amount, generating a modified digital transaction request based on the purchase amount (i.e., separating the purchase amount and tax amount), identifying one or more target recipient accounts, and causing a first transfer of funds to at least one target recipient account and a second transfer of funds with the tax amount to a custodian account. The claimed concept is related to managing human transactions, thus the present claims clearly fall within the Certain Method of Organizing Human Activity grouping. The performance of the claim limitations using generic computer components (i.e., communications hardware, transaction management circuitry, and authentication circuitry) does not preclude the claim limitation from being in the certain methods of organizing human activity grouping. Accordingly, the present claims recite an abstract idea.
Prong Two
Independent claim 1 and 11 recite communications hardware, transaction management circuitry, and authentication circuitry as additional elements. Dependent claims 2-10 and 12-19 do not recite any other additional element. Independent claim 20 recites a computer program product comprising storage medium as additional elements. The additional elements are claimed to perform basic computer functions, such as receiving transaction request, determining a purchase amount and a tax amount, generating a modify transaction request (splitting purchase amount and tax amount as separate fund transfer), authenticating the modified transaction request, identifying recipient account, and performing fund transfers. The recitation of the computer elements amounts to mere instruction to implement an abstract concept on computers, as these claimed steps can be easily performed by human. The present claims do not solve a problem specifically arising in the realm of computer networks. The present claims do not recite limitation that improve the functioning of computer, effect a physical transformation, or apply the abstract concept in some other meaningful way beyond generally linking the use of the abstract concept to a particular technological environment. As such, the present claims fail to integrate into a practical application.
Step 2B: The claims do not recite additional elements that amount to significantly more than the abstract idea.
As discussed earlier, independent claim 1 and 11 recite communications hardware, transaction management circuitry, and authentication circuitry as additional elements. Dependent claims 2-10 and 12-19 do not recite any other additional element. Independent claim 20 recites a computer program product comprising storage medium as additional elements. The additional elements are claimed to perform basic computer functions, such as receiving transaction request, determining a purchase amount and a tax amount, generating a modify transaction request (splitting purchase amount and tax amount as separate fund transfer), authenticating the modified transaction request, identifying recipient account, and performing fund transfers. According to MPEP 2106.05(d), “performing repetitive calculations”, “receiving, processing, and storing data”, “electronically scanning or extracting data from a physical document”, “electronic recordkeeping”, “storing and retrieving information in memory”, and “receiving or transmitting data over a network, e.g., using the Internet to gather data” are considered well-understood, routine, and conventional functions of computer. The present claims do not improve the functioning of computer. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Claim Rejection – 35 U.S.C. 103
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.
Claim(s) 1, 3, 4, 7, 8, 10, 11, 13, 14, 17, and 19-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agee et al. (Pub. No.: US 2015/0058190), in view of Deshpande (Pub. No.: US 2023/0206192) and Hall et al. (Patent No.: US 8,719,126).
As per claim 1, Agee teaches a method comprising:
receiving, by communications hardware, a digital transaction request for a transaction (see paragraph 0049-0050);
determining, by transaction management circuitry, a purchase amount and a tax amount based on the cost amount identifier (see paragraph 0047, “the forwarded transaction information includes the transaction amount, including a portion for taxes…the merchant’s computer 14A, 114A or the third-party service provider computer 22A of the FIG. 1B or other, may determine the amount of tax to be collected from the consumer…based on knowledge of the location of the consumer 12, location of the merchant 14, the tax laws of the various taxing entities 29 and predetermined distribution rules”; see paragraph 0060, “along with the total amount of funds to be collected from the various issuer banks 18, the information may include the portion of those funds accounting for the merchant’s revenue and the portion accounting for the taxes, as well as taxing entity(ies) to which those taxes are to be disbursed”);
generating, by the transaction management circuitry, a modified digital transaction request based on the purchase amount (see paragraph 0086, “The third-party service provider computer 62A may transmit the non-tax portion of the funds to a computer 163A at a merchant’s bank 163 (line AR in FIG. 7B), and may forward the tax portion, along with tax distribution information, to a computer 167A at a central financial entity 167 (line AS in FIG. 7B) for distribution to the various taxing entity banks”; prior art modifies the original payment to the merchant to two separate fund transfers – one for the cost amount and the other for the tax amount);
authenticating, by authentication circuitry, the modified digital transaction request (see paragraph 0053-0054 and 0057);
in response to a successful authentication of the modified digital transaction request: identifying, by the transaction management circuitry, one or more target recipient accounts based on the modified digital transaction request, and automatically causing, by the transaction management circuitry and based on the modified digital transaction request, at least one transfer of funds to at least one target recipient account of the one or more target recipient accounts (see paragraph 0067, “The credit card association’s computer 25A and/or other card organizations then forwards the balance of the funds to the acquiring bank’s computer 21A…The acquiring bank’s computer 21A may then forward the funds either directly to a merchant’s specified account or…to a computer 23A at the merchant’s bank 23”; see paragraph 0085, “transfer funds to a computer 63A at the merchant’s bank 63 in amount of the transaction less the tax portion”; see paragraph 0086, “The third-party service provider computer 62A may transmit the non-tax portion of the funds to a computer 163A at a merchant’s bank 163”; also see paragraph 0069-0070 and 0087).
Examiner notes however, Agee does not explicitly teach wherein the digital transaction request is associated with a digital payment network and comprises a first digital payment network user identifier associated with a business, a second digital payment network user identifier associated with a customer, one or more product identifiers, a tax operation indicator, and a cost amount identifier.
Deshpande teaches wherein the digital transaction request is associated with a digital payment network and comprises a first digital payment network user identifier associated with a business, a second digital payment network user identifier associated with a customer, one or more product identifiers, a tax operation indicator, and a cost amount identifier (see paragraph 0018, “Transactions details can include any data associated with the payment transaction that includes at least a unique identifier, referred to herein as a product identifier, for each product purchased in the payment transaction. Additional transaction details can include, for instance, time, date, geographic location, transaction type, currency, payment method, merchant identifier, point of sale identifier, user device identifier, reward data, loyalty data, coupon data, transaction amount, sale data, tax data, other purchase data for each purchase product, etc.”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Agee with teaching from Deshpande to include wherein the digital transaction request is associated with a digital payment network and comprises a first digital payment network user identifier associated with a business, a second digital payment network user identifier associated with a customer, one or more product identifiers, a tax operation indicator, and a cost amount identifier. The modification would have been obvious, because it is merely applying a known technique (i.e., attaching various types of information in transaction request) to a known method (i.e., separating cost portion and tax portion in a transaction) ready to provide predictable result (i.e. provide sufficient data for tax calculation).
Examiner notes the combination of Agee and Deshpande is unclear with regards to a digital payment network transaction configured to transfer funds directly between accounts associated with users of a digital payment network; generating a modified digital transaction request including the purchase amount, a tax custodian account identifier, and the tax amount, wherein generating the modified digital transaction request at least partly overwrites the digital transaction request; and automatically causing at least one transfer of funds to a tax custodian account corresponding to the tax custodian account identifier.
Hall teaches a digital payment network transaction configured to transfer funds directly between accounts associated with users of a digital payment network; generating a modified digital transaction request including the purchase amount, a tax custodian account identifier, and the tax amount, wherein generating the modified digital transaction request at least partly overwrites the digital transaction request; and automatically causing at least one transfer of funds to a tax custodian account corresponding to the tax custodian account identifier (see claim 1, “digitally receive credit card transaction data sent electronically from a card reader and to automatically separate a sales tax amount from a purchase amount owed to a merchant by a consumer, by using the credit card transaction data, wherein the accounting module is configured to separate a sales tax amount from a purchase amount which has been actually collected by using the automatic incremental billing computer system; wherein the system is configured to manage funds as follows: to provide a transfer of sales tax funds to a sales tax holding account”, prior art teaches the modification of digital transaction is done by the billing computer system without a third party payment processor; tax amount is sent to a tax holding/custodian account, which suggests that the transaction instruction must have comprise the tax holding/custodian account information to enable the transfer; prior art also teaches the purchase amount and the tax amount are separated automatically).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the combination of Agee and Deshpande with teaching from Hall to include a digital payment network transaction configured to transfer funds directly between accounts associated with users of a digital payment network; generating a modified digital transaction request including the purchase amount, a tax custodian account identifier, and the tax amount, wherein generating the modified digital transaction request at least partly overwrites the digital transaction request; and automatically causing at least one transfer of funds to a tax custodian account corresponding to the tax custodian account identifier. The modification would have been obvious, because it is merely applying a known technique (i.e., modifying digital transaction by separating tax amount and purchase amount, and automatically transfer the two separated amounts to corresponding accounts) to a known method (i.e., separating cost portion and tax portion in a transaction) ready to provide predictable result (i.e. save time and effort from human processing).
Claim 2 is canceled.
As per claim 3, Agee teaches determining, by the transaction management circuitry, the tax amount based on metadata of the digital transaction request (see paragraph 0047, “the forwarded transaction information includes the transaction amount, including a portion for taxes…the merchant’s computer 14A, 114A or the third-party service provider computer 22A of the FIG. 1B or other, may determine the amount of tax to be collected from the consumer…based on knowledge of the location of the consumer 12, location of the merchant 14, the tax laws of the various taxing entities 29 and predetermined distribution rules”; location information of merchant and consumer and tax laws are part of the transaction metadata).
As per claim 4, Agee teaches wherein the metadata comprises one or more of geolocation data, timestamp data, biometric data, user-supplied text input, and customer identity data (see paragraph 0047, “the forwarded transaction information includes the transaction amount, including a portion for taxes…the merchant’s computer 14A, 114A or the third-party service provider computer 22A of the FIG. 1B or other, may determine the amount of tax to be collected from the consumer…based on knowledge of the location of the consumer 12, location of the merchant 14, the tax laws of the various taxing entities 29 and predetermined distribution rules”).
As per claim 7, Agee teaches wherein determining the purchase amount comprises combining, by the transaction management circuitry, the tax amount and a cost amount indicated by the cost amount identifier such that the purchase amount is equal to a sum of the tax amount and the cost amount (see paragraph 0060, “along with the total amount of funds to be collected from the various issuer banks 18, the information may include the portion of those funds accounting for the merchant’s revenue and the portion accounting for the taxes, as well as taxing entity(ies) to which those taxes are to be disbursed”).
As per claim 8, Agee does not teach automatically recording, by ledger management circuitry, completed transaction data in a digital ledger; generating, by the ledger management circuitry, a receipt based on the modified digital transaction request; and causing, by the communications hardware, transmission of the receipt to a customer device associated with the second digital payment network user identifier.
Deshpande teaches automatically recording, by ledger management circuitry, completed transaction data in a digital ledger (see paragraph 0024 and 0026-0027);
generating, by the ledger management circuitry, a receipt based on the modified digital transaction request; and causing, by the communications hardware, transmission of the receipt to a customer device associated with the second digital payment network user identifier (see paragraph 0005, “A digital receipt can be generated for the transaction that includes the generated provenance, which is then transmitted to the consumer’s device for presentation thereto”; see paragraph 0018, “Transaction details can include…user device identifier”; also see paragraph 0006-0007, 0027, 0031).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Agee with teaching from Deshpande to include automatically recording, by ledger management circuitry, completed transaction data in a digital ledger; generating, by the ledger management circuitry, a receipt based on the modified digital transaction request; and causing, by the communications hardware, transmission of the receipt to a customer device associated with the second digital payment network user identifier. The modification would have been obvious, because it is merely applying a known technique (i.e., using a ledger to record transactions and generating a receipt and transferring the receipt to user) to a known method (i.e., separating cost portion and tax portion in a transaction) ready to provide predictable result (i.e. recording transactions).
As per claim 10, Agee teaches wherein the tax operation indicator identifies the cost amount identifier as identifying a cost amount as one of a pre-tax cost amount or a post-tax cost amount (see paragraph 0060, “along with the total amount of funds to be collected from the various issuer banks 18, the information may include the portion of those funds accounting for the merchant’s revenue and the portion accounting for the taxes, as well as taxing entity(ies) to which those taxes are to be disbursed”).
Claim 11 is rejected for the same reason as claim 1.
Claim 12 is canceled.
Claim 13 is rejected for the same reason as claim 3.
Claim 14 is rejected for the same reason as claim 4.
Claim 17 is rejected for the same reason as claim 8.
Claim 19 is rejected for the same reason as claim 10.
Claim 20 is rejected for the same reason as claim 1.
Claim 21 is rejected for the same reason as claim 3.
Claim 22 is rejected for the same reason as claim 8.
Claim(s) 5, 6, 15, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agee et al. (Pub. No.: US 2015/0058190), in view of Deshpande (Pub. No.: US 2023/0206192), further in view of Schneider et al. (Patent No.: US 11,321,693).
As per claim 5, Agee does not teach wherein the tax amount is determined based on a usage of a hyperlink associated with the digital transaction request.
Schneider teaches the tax amount is determined based on a usage of a hyperlink associated with the digital transaction request (see col 27 line 65 through col 28 line 11, “such transaction record data may include data that allows the SoC 630 to generate one or more scannable indicia, such as Quick Response (QR) code, that when scanned by a computing device (e.g., smartphone), directs that computing device to a particular website associated with the transaction”; see col 48 line 1-9, “In response to scanning the QR code 1320, the customer’s mobile device may be directed to a unique payment URL that may link to a unique transaction webpage”; see col 2 line 9-33, “In particular embodiments, the transaction data comprises…(a) a total sales amount; (b) an amount of sales tax”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Agee with teaching from Schneider to include the tax amount is determined based on a usage of a hyperlink associated with the digital transaction request. The modification would have been obvious, because it is merely applying a known technique (i.e., using QR code to direct user to a payment webpage and determining tax amount from transaction data) to a known method (i.e., separating cost portion and tax portion in a transaction) ready to provide predictable result (i.e. apply tax processing to mobile transaction).
As per claim 6, Agee does not teach wherein the hyperlink is accessed via scannable indicia associated with the digital transaction request.
Schneider teaches the hyperlink is accessed via scannable indicia associated with the digital transaction request (see col 27 line 65 through col 28 line 11, “such transaction record data may include data that allows the SoC 630 to generate one or more scannable indicia, such as Quick Response (QR) code, that when scanned by a computing device (e.g., smartphone), directs that computing device to a particular website associated with the transaction”; see col 48 line 1-9, “In response to scanning the QR code 1320, the customer’s mobile device may be directed to a unique payment URL that may link to a unique transaction webpage”; see col 2 line 9-33, “In particular embodiments, the transaction data comprises…(a) a total sales amount; (b) an amount of sales tax”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Agee with teaching from Schneider to include the hyperlink is accessed via scannable indicia associated with the digital transaction request. The modification would have been obvious, because it is merely applying a known technique (i.e., using QR code to direct user to a payment webpage and determining tax amount from transaction data) to a known method (i.e., separating cost portion and tax portion in a transaction) ready to provide predictable result (i.e. apply tax processing to mobile transaction).
Claim 15 is rejected for the same reason as claim 5.
Claim 16 is rejected for the same reason as claim 6.
Claim(s) 9 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agee et al. (Pub. No.: US 2015/0058190), in view of Deshpande (Pub. No.: US 2023/0206192), further in view of Singh et al. (Pub. No.: US 2025/0363491).
As per claim 9, Agee does not teach wherein authenticating the modified digital transaction request comprises: authenticating, by the authentication circuitry, credential data received from a customer device associated with the second digital payment network user identifier.
Singh teaches authenticating, by the authentication circuitry, credential data received from a customer device associated with the second digital payment network user identifier (see paragraph 0006-0007 and 0081-0087).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Agee with teaching from Schneider to include authenticating, by the authentication circuitry, credential data received from a customer device associated with the second digital payment network user identifier. The modification would have been obvious, because it is merely applying a known technique (i.e., authenticating transaction credential) to a known method (i.e., separating cost portion and tax portion in a transaction) ready to provide predictable result (i.e. prevent fraud).
Claim 18 is rejected for the same reason as claim 9.
Prior Arts Cited Not Applied
Hall et al. (Patent No.: US 8,719,126) is cited because the prior art teaches separating purchase price amount from sale tax amount, and sale tax is automatically calculated based on the transaction’s location (see col 9 line 28-37).
Response to Arguments
Rejection under 35 U.S.C. 101
Applicant's arguments filed on 05/22/2026 with regards to rejection under 35 U.S.C. 101 have been fully considered but they are not persuasive.
Applicant argued that the Office Action fails to allege any abstract idea is recited at all. Examiner disagrees. Examiner clearly stated the present claims are directed towards identifying purchase amount and tax amount in a transaction and transferring the purchase amount and tax amount separately to different accounts. The amended claims still recite this abstract concept – receiving a digital transaction request, determining a purchase amount and a tax amount, generating a modified digital transaction request by separating the purchase amount and the tax amount, authenticating the modified digital transaction request, and automating fund transfer according to modified digital transaction request so that the purchase amount is sent to a target recipient account and the tax amount is sent to a tax custodian account.
Applicant argued that the amended claims cannot be characterized as certain methods of organizing human activity. Examiner disagrees and points out that the present claims are clearly directed to managing transactions between people – a transaction request is modified into two transactions where purchase amount is sent to a recipient account and tax amount is sent to a tax custodian account. The claimed invention manages the transactions between fund sender, recipient, and tax custodian. Therefore, the present claims fall under the grouping of certain methods of organizing human activity.
Applicant argued that the amended claims provide a practical application by reciting “generating, by the transaction management circuitry, a modified digital transaction request including the purchase amount, a tax custodian account identifier, and the tax amount, wherein generating the modified digital transaction request at least partly overwrites the digital transaction request”. Applicant argued that the generation of modified digital transaction requests alter the data structure of the original digital transaction request by appending additional data. Examiner disagrees and points out that the limitation in question is merely modifying a fund transfer instruction into two transactions where purchase amount is sent to a recipient account and tax amount is sent to a tax custodian account. However, there is no change of data structure similar to the change of data structure in Enfish. Attaching purchase amount, custodian account identifier, and tax amount is just adding information to fund transfer instruction. The data structure does not become more space efficient as a result. The specification also does not support change of data structure. Applicant also argued that “automatically causing, by the transaction management circuitry and based on the modified digital transaction request, at least one transfer of funds to at least one target recipient account of the one or more target recipient accounts and at least one transfer of funds to a tax custodian account corresponding to the tax custodian account identifier” is not a combination of elements performable by any legacy systems or practically performed by human mentally or aided with pen and paper. Examiner disagrees and points out that automating two fund transfers according to instruction can clearly be performed by existing banking systems. Sending part of the fund to a recipient account and the rest to a tax custodian account does not require new computer technology.
Applicant argued that McRO supports the eligibility of the amended claims, because the amended claims do not merely automate a manual tax calculation, rather, they “recite a specific technical process of generating a modified digital transaction request that at least partly overwrites the original digital transaction requests that newly causes the concurrent routing of funds to two accounts”. Examiner disagrees and points out that the claimed process is analogous to how a human would have processed the fund transfer - receiving a transaction request, determining a purchase amount and a tax amount, generating a modified transaction request by separating the purchase amount and the tax amount, and executing fund transfer according to modified transaction request so that the purchase amount is sent to a target recipient account and the tax amount is sent to a tax custodian account. In McRO, the Federal Circuit held the claimed methods of automatic lip synchronization and facial expression animation using particular computer-implemented rules patent eligible under 35 U.S.C. 101, because the claims were directed to an improvement in computer-related technology (i.e. allowing computer to produce “accurate and realistic lip synchronization and facial expressions in animated characters” that previously could only be produced by human animators). As part of its analysis, the McRO court examined the specification, which described the claimed invention as improving computer animation through the use of specific rules, rather than human artists, to set morph weights and transition parameters between phonemes. As explained in the specification, human artists did not use the claimed rules, and instead relied on subjective determinations to set morph weights and manipulate the animated face to match pronounced phonemes. As such, McRO's claims are not focused on a mere automation of known manual process, but on an improvement in computer technology. In the present claims however, automation uses the same steps/rules as human.
Applicant argued that the amended claims are similar to Enfish in reciting a particular data structure (the modified digital request comprising the purchase amount, a tax custodian account identifier, and the tax amount). Examiner disagrees and points out that the modified digital request only comprises additional information rather than different data structure similar to the “self-referential table” in Enfish. An improved data structure should provide improvement in storage efficiency, retrieval speed, and/or data security. The data structure in the present application does not provide any of these technical benefits. Moreover, the Specification does not disclose any improvement of data structure.
Applicant further argued that “the combination of additional elements present in the amended claims addresses specific technical deficiencies of legacy digital payment network-based tax reconciliation methods and achieves concreate improvements to technology described throughout the Specification”. The Specification explains that “manually tracking sales taxes for transactions conducted over digital payment networks can be time consuming and introduces many pitfall”. Examiner points out that the present application is a classic automation application of manual processes. The claimed invention utilizes computation power of existing computers to perform repetitive processes that could be performed manually to speed up processing and avoid human errors. However, these are known benefits of computer automation. The present claims are not improving computer function or addressing technical problems in automation. Rather, the present claims merely automate processes that could be preformed by human. As such, the claims do not recite sufficient limitations to improve computer function or integrate the abstract concept into practical application.
Applicant argued that the claims do not merely apply generic computer components or functions to an abstract idea, and rather, the specific ordered combination of elements recites in the amended claims is not well-understood, routine, and conventional in the art. Examiner points out that the computer elements in the claims perform nothing more than receiving transaction request, determining purchase amount and tax amount (based on simple tax calculations), modifying the transaction request by splitting it into two transaction instructions – sending purchase amount to a recipient account and sending tax amount to tax custodian account, then automate the execution of the transaction instructions. These functions do not require anything other than an off-the-shelf computer. For example, Hall et al. (Patent No.: US 8,719,126) filed on 10/28/2005 teaches “digitally receive credit card transaction data sent electronically from a card reader and to automatically separate a sales tax amount from a purchase amount owed to a merchant by a consumer, by using the credit card transaction data, wherein the accounting module is configured to separate a sales tax amount from a purchase amount which has been actually collected by using the automatic incremental billing computer system; wherein the system is configured to manage funds as follows: to provide a transfer of sales tax funds to a sales tax holding account” (see claim 1, prior art separates an original credit card transaction to two transactions – sending purchase amount to a merchant account and tax amount to sales holding account). The claimed invention does not require novel data structure that improves data storage, improve data transmission security, reduce bandwidth requirement, or improve any computer function. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Examiner maintains the ground of rejection under 35 U.S.C. 101.
Rejection under 35 U.S.C. 103
In response to Applicant’s amendment, Examiner cites an additional prior art, Hall et al. (Patent No.: US 8,719,126), to support the argument that modifying a transaction instruction by separating purchase amount and tax amount, and automatically transfer the purchase amount to a merchant account and the tax amount to a tax holding account was well-known. Updated rejection is provided in this Office Action.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO FU whose telephone number is (571)270-3441. The examiner can normally be reached 9:00 AM - 6:00 PM PST.
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, Christine M Behncke can be reached at (571) 272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HAO FU/Primary Examiner, Art Unit 3695
JULY-2026
Prosecution Insights