DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action responds to the amendment and argument filed by applicant on July 22, 2026, in response to the Office Action mailed on April 22, 2026.
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–8, 10, 12, and 13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
I. Step 1 — Statutory Category
Claims 1–8 and 10 recite methods and therefore fall within the statutory category of a process. Claim 12 recites an electronic device comprising a processor and memory and therefore falls within the statutory category of a machine. Claim 13 recites a non-transitory storage medium and therefore falls within the statutory category of a manufacture.
Accordingly, the claims satisfy Step 1, and the analysis proceeds to Step 2A.
II. Step 2A, Prong One — Judicial Exception
Under Step 2A, Prong One, the Examiner determines whether a claim recites a judicial exception. The recognized abstract-idea groupings include mathematical concepts, certain methods of organizing human activity, and mental processes. The "certain methods of organizing human activity" grouping includes fundamental economic principles or practices and commercial or legal interactions, including business relations. MPEP §2106.04(a)(2).
A. Independent claim 1
Claim 1 recites, inter alia:
receiving ... a bill access request submitted by a user;
determining ... a request category of the bill access request;
collecting ... a business payment bill of the user based on the request category ... to obtain a bill list;
querying ... a ticket associated with each business payment bill;
configuring ... a ticket status ... based on a query result; and
determining the ticket status as a configuration parameter of a display page ... and rendering and generating the display page based on the configuration parameter.
When considered under their broadest reasonable interpretation, these limitations recite the concept of managing a user's business-payment records and corresponding supporting tickets/receipts by categorizing a bill request, selecting responsive bills, determining whether corresponding tickets exist, assigning a ticket status, and presenting the resulting bill/status information.
This concept constitutes a certain method of organizing human activity, particularly a commercial interaction and business/financial administrative practice. The claimed activity concerns managing business-payment bills, payment documentation, user/enterprise financial accounts, and corresponding receipt/ticket status. Such activities are ordinarily performed in connection with commercial transactions, accounting, reimbursement, expense administration, or other business relations.
The claimed steps of determining a request category, selecting responsive bills, determining whether a corresponding ticket exists, and assigning a status additionally encompass evaluation, judgment, categorization, and comparison of information. To the extent these limitations can be performed conceptually by a person reviewing billing records and corresponding receipts, they additionally implicate the mental-process grouping.
Accordingly, claim 1 recites an abstract idea under Step 2A, Prong One.
The Office's current guidance cautions that business methods are not categorically ineligible; rather, the claimed activity must actually fall within one of the enumerated abstract-idea groupings. Here, the claimed bill/payment/receipt administration falls within commercial interactions/business relations rather than being deemed abstract merely because a computer is involved.
III. Step 2A, Prong Two — Practical Application
Under Step 2A, Prong Two, the claim is evaluated as a whole to determine whether additional elements integrate the judicial exception into a practical application. If they do, the claim is not directed to the exception.
The additional elements of claim 1 include: a server; a user terminal; a category determining circuit; a list obtaining circuit; a ticket querying circuit; a status configuration circuit; personal and enterprise accounts; a ticket set; and generating/rendering a display page.
These additional elements do not integrate the abstract idea into a practical application.
Server and recited circuits
The server and named circuits are recited functionally as mechanisms for performing the abstract financial-information operations themselves. The category determining circuit determines a category; the list obtaining circuit obtains bills; the ticket querying circuit queries tickets; and the status configuration circuit configures status.
The claim does not recite a particular improved circuit architecture, database architecture, search technique, network protocol, memory structure, or other technological mechanism by which those operations are technically improved.
Merely assigning different portions of the abstract business process to nominally different computer circuits does not, without more, provide an improvement to the functioning of the computer itself.
Personal and enterprise accounts
The amendment requiring selection from:
“at least one of a personal account of the user and an enterprise account used by the user”
further limits the source of the financial information being processed. It does not alter the manner in which the computer operates or provide a technological solution to a technological problem. Rather, the limitation confines the abstract financial-administration process to particular sources of financial records.
Ticket querying and status determination
Querying the user's ticket set for a ticket corresponding to each bill and assigning ticket status constitute the information comparison and record-management portions of the abstract idea itself.
These limitations do not improve database querying technology. The claims do not, for example, specify a new indexing structure, query execution technique, distributed database arrangement, or improved data-retrieval algorithm.
Status-responsive display page
The amendment requiring: determining the ticket status as a configuration parameter of a display page; and rendering and generating the display page based on that configuration parameter also does not integrate the exception into a practical application.
The claimed display communicates the result of the preceding financial-record analysis—namely, ticket status—to the user. The claim does not recite a particular improvement in display technology, rendering technology, GUI operation, computer-resource utilization, or human-computer interaction. Instead, the display page is used to present the result of the abstract financial-administration process.
Thus, considering the additional elements individually and as an ordered combination, claim 1 merely implements the abstract commercial/financial process using computer components as tools.
The 2024 guidance emphasizes that a relevant practical-application consideration is whether the claim reflects an improvement to the functioning of a computer or another technology/technical field. No fixed terminology automatically makes a claim eligible; the claim must be evaluated as a whole. Here, no such technological improvement is recited.
Accordingly, claim 1 does not integrate the judicial exception into a practical application and is directed to the abstract idea under Step 2A.
IV. Dependent Claims 2–8 and 10
Claim 2 further recites determining a first request category corresponding to a bill label or bill group and selecting bills having the specified label or group.
The additional limitations merely further define categorization, grouping, and selection of financial records according to business attributes. Such limitations further refine the abstract financial-record management process itself and do not constitute additional technological elements integrating the exception into a practical application.
Accordingly, claim 2 remains directed to the judicial exception.
Claim 3 further recites: determining target bill type and quantity from a pre-filled application form; selecting bills from a personal and/or enterprise account; ranking the bills according to a preset rule; selecting corresponding bills according to quantity; and collecting the selected bills into a list.
These limitations recite application-form processing, classification, ranking, rule-based selection, and financial-record collection. Such steps represent business administration and evaluation/judgment that can conceptually be performed by a person reviewing an application form, identifying requested bill categories and quantities, ranking available bills according to established business rules, and selecting the required bills. The recitation of a computer performing those administrative decisions does not change the character of the underlying activity.
No particular ranking algorithm, improved data structure, improved search architecture, or technological mechanism is claimed. Accordingly, claim 3 remains directed to the abstract idea.
Claim 4 further recites determining application quantities and area identifiers from the application form, mapping each area identifier to a corresponding target bill type, and using the quantity entered in the area as the quantity for that bill type.
These limitations merely specify organizing and interpreting information entered into particular portions of a business form. They constitute data interpretation, association, and business-form processing and do not recite an improvement to electronic-form processing or computer operation. Accordingly, claim 4 remains directed to the judicial exception.
Claim 5 recites selecting bills according to a custom condition including: time period;
bill label; bill group; or reimbursement status.
These limitations merely refine the business rules used to filter financial records. Filtering billing records according to date, category, grouping, or reimbursement condition is part of the abstract commercial/administrative process itself.
Accordingly, claim 5 remains directed to the judicial exception.
Claim 6 further recites obtaining a ticket uploaded by a user and a user identifier, adding the ticket to the user's ticket set, and associating the ticket with a selected bill based upon a user-performed association operation.
These limitations constitute receiving supporting transaction documentation, filing that documentation with the appropriate user records, and associating the documentation with the corresponding bill.
Such receipt/bill recordkeeping is itself part of the claimed commercial/accounting activity. Uploading the electronic ticket merely uses the computer as the mechanism for receiving the underlying business documentation. Accordingly, claim 6 does not integrate the abstract idea into a practical application.
Claim 7 similarly recites receiving a ticket from a merchant together with bill and user identifiers, storing the ticket in the user's ticket set, and associating the ticket with the identified bill. These limitations merely automate the conventional commercial interaction of a merchant providing transaction documentation and the recipient maintaining the documentation with the corresponding financial record. The identifiers merely facilitate the information association and do not provide a technological improvement.
Accordingly, claim 7 remains directed to the judicial exception.
Claim 8 recites determining whether a bill associated with a ticket belongs to the bill list and, when it does, updating the ticket status.
This amounts to comparing identifiers/records and updating a financial-record status based upon the result of the comparison. Such evaluation and record updating merely further implement the abstract bill/ticket administration. Accordingly, claim 8 remains directed to the judicial exception.
Claim 10 recites implementing the method in a payment application, receiving a request containing a request-category identifier selected by the user, and determining the selected category from predetermined categories based upon the identifier. The payment application merely places the abstract idea in a particular commercial technological environment/field of use. The category identifier represents information identifying the user's business-selection choice. The claim does not recite a new communications protocol, application architecture, identifier structure, or computer-processing technique. Accordingly, claim 10 remains directed to the judicial exception.
V. Independent Claim 12 — Electronic Device
Claim 12 recites an electronic device comprising a processor and memory storing executable instructions that cause the processor to perform substantially the same bill-processing operations recited in claim 1.
The processor and memory are additional computer components used as tools to: receive a bill request; determine its category; retrieve responsive financial records; query associated tickets; determine ticket status; and generate a corresponding display.
The claimed processor and memory do not change the nature of the underlying abstract commercial activity. The claim does not specify an improvement to processor operation, memory architecture, database technology, communications technology, or computer performance.
The recitation of specifically named functional circuits—category determining, list obtaining, ticket querying, and status configuration—likewise does not provide a technological improvement because the circuits are defined according to the abstract information-processing function each performs rather than a particular improved circuit structure.
Therefore, for substantially the same reasons discussed with respect to claim 1, claim 12 recites a certain method of organizing human activity and does not integrate that exception into a practical application.
VI. Independent Claim 13 — Non-Transitory Storage Medium
Claim 13 recites a non-transitory storage medium containing instructions that cause a processor to perform substantially the same abstract financial-administration process.
Although the claimed non-transitory medium constitutes a statutory manufacture, storing instructions implementing an otherwise abstract process does not itself integrate the exception into a practical application.
The storage medium merely serves as the conventional vehicle by which the processor obtains instructions to perform: category determination to bill collection to ticket querying to status determination to display generation.
No particular improvement to storage technology, instruction execution, computer architecture, or other technical field is recited. Accordingly, claim 13 also is directed to the judicial exception under Step 2A.
VII. Step 2B — Significantly More / Inventive Concept
Because claims 1–8, 10, 12, and 13 are directed to a judicial exception under Step 2A, the claims are evaluated under Step 2B to determine whether any additional element, or combination of additional elements, amounts to significantly more than the judicial exception.
The abstract idea itself is not considered an additional element when determining whether significantly more is present.
The relevant additional computer elements include the: server; user terminal; processor; memory/non-transitory storage medium; functionally identified server circuits; electronic personal/enterprise accounts; electronic ticket storage/querying; and electronic display/rendering functionality.
These elements, as claimed, perform their ordinary computer functions of receiving data, storing data, querying stored records, executing instructions, processing information, and displaying results. Nothing in the claims requires unconventional computer hardware or a particular unconventional technological arrangement.
Importantly, the Step 2B inquiry differs from Step 2A, Prong Two because whether an activity is well-understood, routine, and conventional is considered under Step 2B. When an examiner relies upon a WURC determination, the Office requires appropriate factual support for that conclusion. MPEP §§2106.05(d), 2106.07(a).
Nor does the ordered combination provide an inventive concept. Considered together, the computer elements merely implement the sequence:
receive a financial request → classify the request → select responsive financial records → determine corresponding supporting documentation → assign status → present the result.
That sequence remains an implementation of the underlying financial/business administration rather than an unconventional technological solution.
The claims therefore do not recite additional elements, individually or as an ordered combination, sufficient to transform the judicial exception into patent-eligible subject matter.
Accordingly, claims 1–8, 10, 12, and 13 are rejected under 35 U.S.C. 101 as being directed to a judicial exception without significantly more.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1–8, 10, 12, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Kitchen et al., U.S. Patent No. 6,289,322 B1 (“Kitchen”), in view of US 2012/0084391 A1 (“Patel”), in further view of US 2006/0095373 A1 (“Venkatasubramanian”), US 2009/0119574 A1, US 2013/0232040 A1 (“Ricoh”), and US 2017/0103455 A1 (“Schroeder”), as specifically applied below.
With respect to claim 1, Kitchen discloses a bill processing method comprising receiving, at a server and from a user terminal, a bill access request submitted by a user, in that Kitchen provides a centralized network server connected with payor client stations, wherein a payor transmits a request for current billing information and the server receives the request and responsively transmits applicable bill-presentment information to the payor station (Kitchen, see FIGS. 1, 2A–2B and 7; disclosure corresponding to the network server receiving each payor request and transmitting applicable bill-presentment information responsive thereto).
Kitchen expressly describes the client/server architecture and on-demand request/response relationship.
Kitchen further discloses collecting business payment bills of the user to obtain a bill list, because billing information from multiple billers is stored in association with an identifier of the appropriate payor, the processor accesses the stored billing information associated with that payor, and generates bill-presentment information including a summary listing of bills of a desired status, such as paid or unpaid bills (Kitchen, FIGS. 1, 7, 9A–9C and 11; see disclosure of storing billing information by payor and generating a summary listing of bills of a desired status).
Kitchen further teaches selecting different subsets/categories of billing information responsive to the user's request, including current billing information and outstanding/unpaid bills, and generating the appropriate portion of billing information responsive to the request (Kitchen, FIGS. 9A–9C; see disclosure concerning requests for current billing information and requests concerning outstanding bills).
To the extent Kitchen does not expressly characterize the selection information as a “request category” determined by a category determining circuit, Venkatasubramanian teaches rule- and category-based invoice processing. In particular, its context builder may associate a category with each invoice entry; its process manager retrieves invoices from a repository and controls processing according to specified rules; and its exception manager provides filtering and searching of invoice subsets (Venkatasubramanian, FIGS. 7, 10–11; see, e.g., disclosure corresponding to invoice processor 1000, process manager 1010, exception manager 1120, and data-filtering rules).
With respect to collecting the business payment bill “from at least one of a personal account of the user and an enterprise account used by the user,” Ricoh expressly distinguishes personal credit-card transactions from corporate credit/debit-card transactions and processes expense data accordingly. For a personal transaction the system creates personal expense data and associates the expense with receipt data; for a corporate transaction the system compares the transaction against corporate credit-card data and creates corresponding corporate expense data when a match is found (Ricoh, FIGS. 14–16, particularly the processing illustrated by steps 1508–1518).
Accordingly, Kitchen in view of Venkatasubramanian and Ricoh teaches or suggests determining a request category and collecting bills associated with the user, including from personal and enterprise/corporate financial data sources, to obtain the requested bill list.
Kitchen does not expressly teach the claimed ticket-set processing.
Patel, however, discloses querying/accessing a ticket set of the user containing tickets associated with transactions of the user, in that Patel generates an electronic receipt for a customer's transaction and stores the electronic receipt in association with the customer's account; the receipt storage module stores the electronic receipt in association with a user identifier, and a web interface enables the user to access electronic receipts stored in the receipt-storage module (Patel, FIGS. 1–2; see disclosure corresponding to server 116, storage database 128, receipt storage module and web interface).
Patel further teaches that the stored electronic ticket/receipt includes transaction-identifying information including product identifier, merchant identifier, date, purchase price and receipt number, thereby supplying information by which the receipt can be associated with the corresponding financial transaction (Patel, FIGS. 1–2).
Ricoh strengthens the association requirement by expressly matching receipt information against corresponding transaction/credit-card information and associating the expense data with receipt image data and receipt data (Ricoh, FIGS. 15–16, including steps 1508–1518).
With respect to configuring a ticket status of each business payment bill based upon a query result, Venkatasubramanian teaches processing invoices according to verification results, maintaining invoice exception/status information, retrieving invoices and associated context, and providing an Inbox in which invoices and corresponding processing information are displayed. Its data structures expressly associate an INVOICE_ID with a STATUS, while exception manager 1120 retrieves invoice-related information and presents it through the Inbox (Venkatasubramanian, FIGS. 10–13F; see invoice processor 1000 and exception manager 1120).
Venkatasubramanian further teaches that the displayed information may be automatically modified based upon processing/user conditions, permits filtering of Inbox information, and allows a user to select an invoice and drill down to the invoice and its associated information (Venkatasubramanian, FIGS. 11 and 13A–13F).
With respect to the amended limitation wherein “the configuring comprises determining the ticket status as a configuration parameter of a display page of the business payment bill, and rendering and generating the display page based on the configuration parameter,”
Venkatasubramanian teaches generating GUI presentations according to the processing state of invoice information, including displaying invoice data and corresponding exception information in Inbox 1310, displaying particular invoice information when an invoice is selected, and presenting invoice data in invoice format through GUIs 1300A–1300F (Venkatasubramanian, FIGS. 13A–13F). The invoice information can be displayed in the same visual format as a paper invoice and processing-result information is used in determining what information is presented.
Kitchen independently teaches generating one or more display pages containing the user's selected bill-presentment information and generating a formatted detailed bill for presentation on the user's display (Kitchen, FIGS. 9A–9C and 11).
Accordingly, it would have been obvious to use the status determined from the Patel/Ricoh receipt association and Venkatasubramanian invoice-processing result as a parameter controlling the bill presentation generated by Kitchen, because Kitchen already generates bill pages according to bill status, while Venkatasubramanian teaches modifying/presenting invoice information according to invoice-processing state.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kitchen's centralized bill-presentment system to incorporate Patel's electronic-receipt storage and Ricoh's receipt/transaction matching because Kitchen already stores and presents user-specific financial transactions, while Patel and Ricoh teach known mechanisms for retaining and associating the corresponding electronic transaction documentation with those transactions. The combination would predictably permit the bill-presentment system to determine whether corresponding receipt/ticket documentation exists and to present that status together with the bill.
It further would have been obvious to incorporate Venkatasubramanian's invoice status, filtering and status-responsive GUI functionality because both Kitchen and Venkatasubramanian concern electronic processing and presentation of billing/invoice information, and Venkatasubramanian's teachings would permit Kitchen's bill-presentment pages to reflect the processing/status condition of the corresponding financial record. The modification amounts to the predictable use of known financial-record management techniques according to their established functions. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007).
Accordingly, claim 1 is unpatentable over the applied combination.
With respect to claim 2, the combination applied to claim 1 is relied upon.
Kitchen further discloses selecting and collecting business payment bills belonging to a specified category/group, because Kitchen generates summary listings containing bills satisfying a desired status, including paid bills, unpaid bills, or other desired-status bills (Kitchen, FIGS. 9A–9C).
Venkatasubramanian additionally teaches storing invoice categories, retrieving invoices according to specified rules, searching invoice records, and filtering an Inbox to specified subsets of invoices (Venkatasubramanian, FIGS. 7, 10–11; exception manager 1120 and associated data-filtering rules).
Thus, it would have been obvious to use a specified bill label or group as one of the filtering/category attributes used to select the requested subset, because Venkatasubramanian expressly contemplates user-configurable filtering of invoice records and Kitchen already retrieves bill subsets according to bill attributes/status.
Therefore, claim 2 is unpatentable over the combination applied to claim 1 further in view of Venkatasubramanian.
With respect to claim 3, the references applied to claim 1 teach the underlying collection of business-payment bills.
The combination does not expressly disclose all aspects of the claimed pre-filled application-form and quantity-driven selection. US 2009/0119574 A1 is therefore further relied upon.
US 2009/0119574 teaches an expense-report environment in which a receipt/document is processed and information is transferred into predetermined areas of an expense report according to a selected mapping. The processor permits selection of a map associating data types and associated data with corresponding cells of an expense-report spreadsheet, parses the document to identify the data types and values, and transfers the values to the designated expense-report fields (see FIGS. 1–3, 6, 8 and 15–20).
Thus, US 2009/0119574 teaches determining the type/category of expense information from a form structure and processing the corresponding financial data according to that predefined form mapping.
Schroeder further teaches obtaining multiple candidate invoice/receipt records and processing those records according to predetermined criteria. Specifically, invoice matching logic 110 retrieves invoice records and receipt records from respective databases and selects/matches records according to criteria data (Schroeder, FIG. 1, invoice matching logic 110, baseline matching logic 120 and best-match selection logic 130).
Schroeder teaches “ranking the to-be-processed bill according to a preset rule”, because best-match selection logic 130 considers multiple criteria in a prioritized order to select the best matching candidate record (Schroeder, FIG. 2, best-match selection logic 130).
Schroeder further teaches selection based upon quantity, because one of its predetermined best-match criteria selects the single candidate record having the lowest quantity variance, computes quantity variance for the candidate records, and selects the record satisfying that quantity criterion (Schroeder, FIG. 2).
Schroeder additionally performs line-level quantity matching by comparing invoice quantities against quantities of candidate receipt records, including aggregated receipt quantities, before determining whether records are matched.
Accordingly, it would have been obvious to apply Schroeder's known prioritized, quantity-sensitive financial-record selection to the bills obtained according to the expense/application-form categories taught by US 2009/0119574, thereby automatically selecting the most appropriate candidate bills satisfying the quantity information supplied through the form.
One of ordinary skill would have been motivated to combine these teachings because US 2009/0119574 provides structured form-driven processing of expense information while Schroeder addresses the predictable downstream problem of selecting the appropriate financial records when multiple candidates satisfy initial criteria. Schroeder expressly teaches automated prioritized matching to avoid manual resolution. Employing Schroeder's prioritized and quantity-sensitive selection rules in the expense/bill workflow would predictably reduce manual selection and permit the system automatically to identify the financial records best satisfying the requested quantity/category constraints.
Therefore, claim 3 is unpatentable over the references applied to claim 1 further in view of US 2009/0119574 and Schroeder.
With respect to claim 4, US 2009/0119574 more specifically teaches identifying different areas of a form/document and associating the respective areas with corresponding data types.
The reference describes receipt areas corresponding to different data types, including DateTime, Tax, Total and Vendor, and provides a tree-based interface associating those document areas with corresponding data types (see FIG. 1).
The reference further teaches mapping each data type and its associated value to a particular cell/address/area of the expense-report spreadsheet, including storing the data type together with the address of the desired cell (see FIGS. 2–3 and 15–20).
Thus, US 2009/0119574 teaches the claimed relationship of determining an identified form area, determining the corresponding financial/expense data type from that area mapping, and treating the value associated with that identified area as the value for the corresponding type.
When combined with Schroeder's explicit processing of invoice/receipt quantities, it would have been obvious to use a quantity entered in the corresponding mapped expense-form field as the quantity parameter for the associated bill/expense type because doing so is merely applying the known mapped field value to its identified financial-record category.
Accordingly, claim 4 is unpatentable over the references applied to claim 3.
With respect to claim 5, Kitchen teaches selecting subsets of a user's bills according to specified bill conditions, including paid, unpaid, or other desired status, and provides requests specifically directed to outstanding bills (Kitchen, FIGS. 9A–9C).
Venkatasubramanian further teaches user-customizable data filtering rules, searching invoices, and filtering Inbox records to desired subsets (Venkatasubramanian, FIG. 11, exception manager 1120).
Kitchen's billing information also includes billing dates/cycles and identifies the respective billers, while Venkatasubramanian's invoice data includes invoice number, invoice date, amount, vendor, description and processing information.
Accordingly, selecting the bills according to a custom condition such as time period, label, group, or reimbursement/status condition would have been an obvious use of the disclosed filtering functionality on known invoice attributes. Therefore, claim 5 is unpatentable over the combination applied to claim 1.
With respect to claim 6, Patel teaches obtaining an electronic ticket and a user identifier, generating a message containing the user identifier and electronic receipt, transmitting the message to receipt storage, and storing the receipt in association with the user identifier/account (Patel, FIGS. 1–2, particularly receipt-storage database 128). Patel therefore teaches adding the ticket to the ticket set of the user based on the ticket and user identifier.
For the additional limitation requiring associating the ticket with at least one bill based on a bill-ticket association operation performed by the user, Ricoh expressly teaches manual user association. Where automatic matching does not find a match between corporate credit-card data and receipt data, the system creates expense data and the user manually associates the expense data with the credit-card data and receipt image/receipt data (Ricoh, FIG. 15, step 1518).
Thus, Ricoh expressly supplies the user-performed association that was absent from Patel.
It would have been obvious to incorporate Ricoh's manual-association fallback into Patel's electronic-receipt account because both systems associate electronic receipts with corresponding financial transactions, and Ricoh's manual association provides the predictable benefit of permitting association when automatic matching cannot resolve the corresponding transaction.
Therefore, claim 6 is unpatentable over the references applied to claim 1 further in view of Ricoh.
With respect to claim 7, Patel teaches generating the electronic ticket/receipt in connection with a merchant POS transaction, obtaining the customer identifier, transmitting the identifier together with the electronic receipt, and storing the receipt in the customer's electronic-receipt account (Patel, FIGS. 1–2).
Patel further teaches that the receipt data includes identifying information including merchant identifier, date, purchase price and receipt number, thereby providing transaction/bill identifying information bound to the ticket.
Ricoh further teaches matching receipt information with corresponding credit-card transaction information and associating the resulting expense record with receipt data (Ricoh, FIGS. 15–16).
Accordingly, the combination teaches or suggests obtaining a merchant-generated ticket, obtaining identifying information corresponding to the associated transaction and user, adding the ticket to the user's stored ticket collection, and associating the ticket with the corresponding bill/transaction identified by that information.
Therefore, claim 7 is unpatentable over the references applied to claim 1 in further view of Patel and Ricoh.
With respect to claim 8, Schroeder teaches determining whether an invoice and corresponding receipt record are associated by querying/retrieving the candidate records and applying matching criteria, including vendor, purchase-order number, billing location, cost and quantity (Schroeder, FIGS. 1–3).
Schroeder further teaches that, when the criteria establish the association, the system updates the status of the corresponding financial records, marking the invoice and receipt records as matched; where a best match is selected, the selected receipt and invoice are marked as matching and the invoice is placed in a staging table for further financial processing (Schroeder, FIGS. 1–3).
Accordingly, when applied to the bill list of Kitchen and user ticket set of Patel, it would have been obvious to determine whether the bill associated with a particular ticket is contained within the retrieved bill set and, when such correspondence is found, update the corresponding ticket/bill status to indicate the match. Therefore, claim 8 is unpatentable over the references applied to claim 6 further in view of Schroeder.
With respect to claim 10, Kitchen teaches applying the bill-processing method in an electronic bill-payment/presentment application and receiving a user request from the payor station for selected billing information (Kitchen, FIGS. 7–15). Kitchen expressly provides different bill-presentment views/categories, including new bills, unpaid bills, other bill summaries, detailed bill views and biller-category screens (FIGS. 9A–9C, 11 and 14).
Venkatasubramanian further teaches that an invoice-processing request/search can specify criteria through fields, with the system searching and returning records satisfying the specified field values, while an empty field represents no requirement for that criterion. It also teaches user-configurable filtering of invoice information (Venkatasubramanian, FIG. 11 and exception-pool search functionality).
It would therefore have been obvious to represent the user's selected bill category by a category identifier carried in the electronic request and determine which of the preset categories is requested based on that identifier. Encoding a selected category as an identifier in a client/server request constitutes a conventional implementation of Kitchen's user selection of different bill-presentment categories and Venkatasubramanian's criterion-based record retrieval.
Therefore, claim 10 is unpatentable over the combination applied to claim 1.
Claim 12 recites substantially the same functional limitations as claim 1 in electronic-device form.
With respect to claim 12, Kitchen expressly discloses an electronic bill-presentment system having memory, processor and communications/network interface, wherein the memory stores billing information and the processor accesses the memory, processes the stored billing information, generates bill-presentment information, and directs transmission of the applicable information responsive to a user request (Kitchen, FIGS. 1, 2A–2B and 7).
Kitchen therefore teaches the claimed processor and memory implementation.
For the remaining functional limitations—receiving the request, determining/selecting bill information according to the request, obtaining bills from personal/corporate financial information, querying user-associated tickets, associating receipts with transactions, determining status, and rendering the resulting status-dependent bill display—the Examiner relies upon Kitchen, Patel, Venkatasubramanian and Ricoh for the same reasons set forth above with respect to claim 1, which reasons are incorporated herein.
Ricoh expressly supplies the personal/corporate distinction. Patel supplies the user-associated electronic receipt database. Venkatasubramanian supplies invoice processing/status and GUI functionality.
Accordingly, claim 12 is unpatentable over Kitchen in view of Patel, Venkatasubramanian and Ricoh.
Claim 13 recites substantially the same functionality in the form of a non-transitory storage medium containing processor-executable instructions.
The references applied above disclose computer-executed implementations of the respective financial-processing functions. In particular, Schroeder expressly describes invoice matching logic as a server-side software application controlling a processor and implemented as a computing/data-processing system (FIGS. 1 and 4). US 2009/0119574 expressly discloses a computer-readable storage medium containing instructions that, when executed by a processor, perform its document/expense-report mapping operations.
It would have been obvious to store the software instructions implementing the combined bill-processing functionality on a non-transitory computer-readable storage medium because each applied reference implements its respective financial-data operations through programmed computing equipment, and storing such program instructions on non-transitory memory represents the ordinary and predictable manner of implementing the disclosed computer functionality.
For the recited functional operations of claim 13, the Examiner relies upon the limitation-by-limitation findings made above for claim 1, which are incorporated herein. Accordingly, claim 13 is unpatentable over Kitchen in view of Patel, Venkatasubramanian, Ricoh and the computer-readable-medium teachings of US 2009/0119574.
Response to Arguments
Applicant's arguments filed in response to the rejection of claims 1–10 and 12–13 under 35 U.S.C. 101 have been fully considered but are not persuasive. The rejection is maintained with respect to pending claims 1–8, 10, 12, and 13, for the reasons set forth below.
The Examiner acknowledges Applicant's amendments to independent claims 1, 12, and 13 and has reconsidered the eligibility of the amended claims as a whole in accordance with the Alice/Mayo framework, the 2019 Revised Patent Subject Matter Eligibility Guidance, the 2024 Subject Matter Eligibility Guidance, and MPEP §§2106 et seq. When a claim has been amended in response to an eligibility rejection, the amended claim is interpreted under its broadest reasonable interpretation and the eligibility analysis is performed again. MPEP §2106.07(b).
Applicant's arguments concerning Step 2A, Prong One
Applicant argues that amended claim 1 is not directed to an abstract idea because the claim now recites specific technical features involving operation of a computer system in a particular manner, including a server, user terminal, category determining circuit, list obtaining circuit, ticket querying circuit, and status configuration circuit.
The argument is not persuasive.
Under Step 2A, Prong One, the relevant inquiry is whether the claim recites a judicial exception. Claim 1 recites, inter alia, determining the category of a user's request for bills; collecting business-payment bills according to that category; querying whether tickets corresponding to the bills exist; determining the corresponding ticket status; and presenting the bill information according to the determined status.
Considered together, these limitations recite the concept of managing business-payment records and their associated transaction documentation by categorizing a request, selecting responsive bills, determining the existence/status of corresponding tickets, and presenting the resulting bill/status information.
Such activity falls within the abstract-idea grouping of certain methods of organizing human activity, particularly commercial interactions and business relations involving payment, accounting, reimbursement, and maintenance of transaction documentation. See MPEP §2106.04(a)(2).
The mere fact that the claimed business process is performed electronically does not remove the underlying commercial interaction from the enumerated abstract-idea grouping.
Applicant additionally argues that the operations cannot be performed mentally. However, the rejection does not depend exclusively upon characterizing the entire claim as a mental process. Rather, the claimed financial administration falls within the independent abstract-idea grouping of certain methods of organizing human activity. Thus, even assuming arguendo that the complete claimed process could not practically be performed in the human mind because of the recited computer components, such fact would not remove the underlying commercial activity from the identified abstract-idea grouping.
Accordingly, the amendments do not overcome Step 2A, Prong One.
Applicant's arguments concerning the server and specialized circuits
Applicant argues under Step 2A, Prong Two that the server and the specifically recited "category determining circuit," "list obtaining circuit," "ticket querying circuit," and "status configuration circuit" constitute specialized software and hardware components that integrate the alleged exception into a practical application.
The argument is not persuasive.
The recited circuits are defined in the claims principally according to the information-processing functions they perform. The category determining circuit determines a request category; the list obtaining circuit obtains a bill list; the ticket querying circuit queries tickets; and the status configuration circuit configures ticket status.
Claim 1 does not require a particular improved electronic structure for any of these circuits, a particular circuit interconnection, an improved processor architecture, an improved database structure, an improved query execution mechanism, an improved memory organization, or a particular communications protocol.
Thus, the nominal allocation of portions of the financial-information process to separately named functional circuits does not itself establish an improvement in computer technology. The claims use computer components as tools for carrying out the underlying financial-record administration.
The USPTO's eligibility framework distinguishes a claim that improves computer capabilities from one that merely invokes a computer as a tool. Moreover, the claimed improvement must be reflected in the claim itself.
The present claims are unlike the technological improvements recognized in cases such as Enfish and McRO. Claim 1 does not recite an improved database structure comparable to the self-referential table of Enfish, nor does it recite specific technological rules that improve an automated technological process in the manner considered in McRO. Instead, the server and circuits carry out the recited business-information functions.
Applicant's personal-account/enterprise-account argument
Applicant next argues that collecting bills: "from at least one of a personal account of the user and an enterprise account used by the user" requires retrieval and integration across heterogeneous data sources and therefore provides a concrete technical implementation.
The argument has been considered but is not persuasive.
The claim does not recite the alleged heterogeneous-data integration mechanism relied upon by Applicant. For example, claim 1 does not specify different database formats, schemas, APIs, communication protocols, authentication mechanisms, transformation operations, normalization techniques, or reconciliation procedures required to combine heterogeneous data.
Instead, the claim identifies the business sources from which the records are collected—a personal account and/or an enterprise account.
The distinction between a personal financial account and an enterprise financial account concerns the nature or ownership of the underlying financial information, not an improvement in the operation of the computer retrieving the information.
Accordingly, this limitation further particularizes the financial information subjected to the abstract process but does not integrate the exception into a practical application.
Applicant's display-page/configuration-parameter argument
Applicant principally relies upon the newly added limitation:
"determining the ticket status as a configuration parameter of a display page of the business payment bill, and rendering and generating the display page based on the configuration parameter."
Applicant characterizes this limitation as a specific computer-graphics/UI rendering technique and argues that the status is encapsulated as a ready-to-use rendering parameter, thereby reducing separate per-item status queries, reducing front-end/backend interactions, decreasing logical-judgment overhead, simplifying coupling between front-end and backend code, and improving graphical-interface generation efficiency and system-resource utilization.
The argument is not persuasive.
The Examiner agrees that an improvement to computer functionality or another technology can establish integration into a practical application. Under MPEP §§2106.04(d)(1) and 2106.05(a), however, the Specification must provide sufficient technical detail such that the asserted technological improvement would be apparent to one of ordinary skill, and the claim itself must reflect the disclosed improvement. A conclusory characterization of a result as an improvement is insufficient.
Here, claim 1 requires determining ticket status as a configuration parameter and rendering/generating a display page based on that parameter. The claim does not require:
eliminating per-item status queries;
reducing the number of communications between front-end and backend components;
caching or precomputing status information;
transmitting a particular data structure containing ready-to-render status information;
eliminating backend requests during rendering;
reducing processor operations or memory accesses;
reducing network traffic or latency; or
implementing any particular front-end/backend architecture that achieves the asserted resource savings.
Thus, the claimed language does not impose the particular technical mechanism upon which Applicant's asserted improvement depends.
Moreover, the portions of the Specification identified by Applicant do not establish otherwise. Applicant relies on paragraphs [0003], [0070], and [0072]. As characterized by Applicant, paragraph [0003] identifies the difficulty that a merchant ticket may not immediately be obtained following payment, requiring the user to expend time and effort collecting tickets. This describes a business/administrative problem concerning collection and management of reimbursement documentation, rather than a technological deficiency in computer architecture or graphical rendering.
Likewise, Applicant acknowledges that paragraph [0070] describes differentially displaying business-payment bills having different ticket statuses so that the user may more intuitively perceive a bill having a particular ticket status. That disclosure concerns the organization and presentation of financial information to facilitate user comprehension. It does not, on the present record, disclose the asserted reduction in backend queries, network interactions, computational operations, or front-end/backend coupling.
Applicant's asserted technical effects therefore are not commensurate with what amended claim 1 actually requires. The Examiner cannot import into the claim unrecited implementation details concerning query elimination, reduced network interactions, or computational-resource savings.
Accordingly, the display limitation represents use of the determined financial-record status to control the content or manner in which the result of the underlying financial analysis is presented, rather than a claimed improvement to graphical rendering technology itself.
Applicant's reliance on Specification paragraph [0003]
Applicant further contends that the claimed invention improves "the technology of bill processing" by addressing the problem identified in paragraph [0003], namely that tickets used for reimbursement may not immediately be available following payment and users therefore expend additional time and effort collecting tickets.
The Examiner does not agree that this establishes a technological problem for purposes of Step 2A, Prong Two.
Improving the speed, convenience, or efficiency of a business process through computer automation is not, without more, an improvement to the functioning of the computer or another technological field. The relevant improvements inquiry asks whether the claim improves computer functionality or another technology, rather than merely whether the computer permits the underlying business task to be performed more efficiently. MPEP §2106.05(a).
The problem identified by Applicant—users spending time and effort obtaining and managing reimbursement tickets—is fundamentally associated with financial recordkeeping and reimbursement administration. Automating the determination of which bills have associated tickets may improve that business workflow, but the claim does not recite a technological improvement in how the underlying computer operates.
Accordingly, Applicant has demonstrated an improvement to the abstract business process, not a technological improvement sufficient to integrate the exception into a practical application.
Claim considered as an ordered combination
The Examiner has also reconsidered amended claim 1 as a whole, rather than dissecting the limitations in isolation.
In ordered combination, claim 1 performs:
receive bill request → classify request → collect responsive bills → query corresponding tickets → determine ticket status → use status in configuring and presenting the bill page.
This sequence provides an automated implementation of the underlying financial-administration workflow. The recited server, accounts, ticket set, circuits, and display functionality facilitate performance of that workflow, but the claim does not recite a technological mechanism that changes how the computer, database, network, or display technology itself operates.
Accordingly, considering the additional elements individually and in combination, the judicial exception is not integrated into a practical application, and amended claim 1 remains directed to an abstract idea under Step 2A.
Step 2B — Significantly More
Applicant contends that because claim 1 is eligible under Step 2A, Prong Two, Step 2B need not be reached. Because the Examiner does not agree with Applicant's Step 2A conclusion, Step 2B remains applicable.
At Step 2B, the claim is considered as a whole to determine whether the additional elements, individually and as an ordered combination, amount to significantly more than the judicial exception.
The additional elements include the server, user terminal, functionally identified circuits, electronic accounts, ticket data store, and electronic display/rendering functionality. As claimed, these components perform ordinary computer functions of receiving information, retrieving stored information, querying records, executing logical determinations, maintaining status information, and generating/displaying information.
The prior art of record additionally provides factual support relevant to the conventional computer implementation. For example, the references previously applied under §103 evidence that, before Applicant's filing, electronic bill-presentment servers, electronic receipt databases, computerized invoice-status systems, expense-management interfaces, and electronic receipt/transaction association were known implementations of financial-record processing. This evidence is not used to conflate novelty or obviousness with eligibility; rather, to the extent necessary, it corroborates the Step 2B finding concerning the conventional nature of the additional computer functionality. MPEP §2106.05(d) distinguishes the WURC inquiry at Step 2B from the Step 2A practical-application inquiry.
Nor does their ordered combination provide an inventive concept. The computer elements perform the same financial-information functions for which they are invoked, producing the expected result of identifying bills having corresponding tickets and presenting their status.
Applicant's alleged reduction in queries, network interactions, computational redundancy, and frontend/backend coupling does not alter this conclusion because, as discussed above, those alleged technical operations are not required by the claims.
Accordingly, amended claim 1 does not recite additional elements that, individually or as an ordered combination, amount to significantly more than the judicial exception.
Independent claims 12 and 13
Applicant argues that independent claims 12 and 13 are eligible because they recite limitations similar to amended claim 1.
The argument is not persuasive for substantially the same reasons discussed above.
Claim 12 places substantially the same financial-information operations in an electronic-device format comprising a processor and memory, while claim 13 places substantially the same operations in instructions stored on a non-transitory storage medium.
Neither claim requires the alleged technical mechanisms of eliminating individual status queries, reducing frontend/backend communications, reducing processor operations, implementing a particular data structure, or improving a rendering engine.
Accordingly, claims 12 and 13 remain directed to the same abstract financial-administration process and do not recite additional elements sufficient to integrate that exception into a practical application or provide significantly more.
Dependent claims 2–8 and 10
Applicant argues generally that dependent claims 2–10 are eligible because they incorporate the allegedly eligible limitations of their respective independent claims and recite additional limitations.
The argument is not persuasive because the underlying independent claim remains ineligible, and the additional limitations of pending dependent claims 2–8 and 10 do not cure the deficiency.
Claims 2 and 5 further specify business criteria for selecting bills, including labels, groups, time periods, and reimbursement status. Claims 3 and 4 further specify form-driven classification, quantities, ranking, and selection of financial records. Claims 6 and 7 further specify obtaining, storing, and associating transaction tickets with corresponding financial records. Claim 8 further specifies comparing bill identifiers and updating status based upon the comparison. Claim 10 specifies performing the process in a payment application using a request-category identifier.
These limitations further particularize the underlying financial/accounting administration and information processing but do not recite an improvement to computer functionality, database technology, networking, electronic-form technology, or another technological field.
Accordingly, dependent claims 2–8 and 10 likewise remain ineligible.
The amendments narrow the manner in which the claimed financial-information workflow is performed, but they do not change the fundamental character of the claims. The pending claims continue to recite the abstract commercial activity of managing business-payment bills and corresponding transaction documentation through categorization, selection, association, status determination, and presentation of financial records.
The recited server, terminal, circuits, personal/enterprise accounts, ticket repository, and status-responsive display generation do not integrate that exception into a practical application because the claims do not recite the particular technological mechanisms alleged by Applicant to improve computer operation. The asserted reductions in queries, frontend/backend interactions, processing overhead, and resource utilization are neither required by the claims nor shown by the cited portions of the Specification to constitute the claimed technological improvement.
The USPTO requires examiners responding to eligibility arguments to reconsider amendments and all arguments and evidence, and, if maintaining the rejection, provide a rebuttal explaining why the response does not establish eligibility. MPEP §2106.07(b). The foregoing provides that reconsideration and rebuttal.
Therefore, the rejection of pending claims 1–8, 10, 12, and 13 under 35 U.S.C. 101 is maintained.
Applicant’s argument with respect to 35 U.S.C. 103 rejections have been considered but are moot in view of new grounds of rejections.
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 ROKIB MASUD whose telephone number is (571)270-5390. The examiner can normally be reached Mon-Fri 8:00-5:00.
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, Fahd Obeid can be reached at 571-270-3324. 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.
/ROKIB MASUD/Primary Examiner, Art Unit 3627
