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 .
Applicant filed a response dated December 24, 2025 in which claims 1-6 have been amended. Therefore, claims 1-6 are currently pending in the application.
Priority
Application 18/393,592 filed on 12/21/2023 is a CON of PCT/JP2022/025420 06/24/2022 and claims priority to JAPAN 2021-105263 06/24/2021.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
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-6 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method and system, which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A transaction processing method executed by a computer in a transaction management system comprising a billing information memory, and a vendor information memory, the method comprising:
maintaining, in the billing information memory, a structured data set in which a plurality of billing records respectively corresponding to transactions occurring at a different stages of a multi-stage supply chain are commonly linked through a chain identifier that identifies a transaction chain;
receiving, from a computer that manages deposit account information, a deposit notification including a purchaser identifier, a deposit amount, and a deposit account identifier;
performing, by the computer, and based on a predetermined multi-factor matching rule, a match between the deposit notification and one billing record in the structured data set;
retrieving, from the billing information memory, all billing records that share the chain identifier included in the matched billing record;
automatically updating, by the computer, payment states of all retrieved billing records to a payable state in a single integrated operation based on the shared chain identifier;
for each of the billing records whose payment state is set to the payable state, reading a billing source identifier, a billing recipient identifier, and a billing amount from the billing information memory; and
reading deposit account information corresponding to the billing source identifier, and withdrawal account information corresponding to the billing recipient identifier, from the vendor information memory;
generating, by the computer, transfer instruction information including the deposit account information, the withdrawal account information, and a transfer amount based on the billing amount; and
transmitting, by the computer, the transfer instruction information to a computer that manages the withdrawal account information.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate a financial transaction management system, e.g., providing payment transactions between multiple vendors and recording of ledgers related to payments among multiple vendors. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting a “A transaction processing method executed by a computer in a transaction management system comprising a billing information memory, and a vendor information memory, the method comprising:”, “a computer that manages deposit account information”, and “a computer that manages the withdrawal account information”, to perform the steps of “maintaining”, “performing”, “retrieving”, “reading”, and “generating”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a financial transaction management system in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification discloses “[0014] The transaction management system 10, as well as the computers 20 through 70 of each of the transaction parties and the consumer computer 80, basically adopt the general hardware configuration of a computer. That is, as shown in FIG. 2, the system includes an input device 110 such as a keyboard and a display device 120 such as a liquid crystal display. It also includes a communication device 130 such as NIC (a network interface card) that enables data communication between computers through a computer network N. Furthermore, it includes a memory 140 such as a memory that stores information necessary for computer processing, and a processor 150 such as a CPU (Central Processing Unit) that realizes various functions by executing a program. [0015] Here, the appearance of the computer does not matter. It may be a server type, desktop type, notebook type, tablet type, portable terminal type, etc. It may also be a ledger of distributed computing with multiple computers.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “A transaction processing method executed by a computer in a transaction management system comprising a billing information memory, and a vendor information memory, the method comprising:”, “a computer that manages deposit account information”, and “a computer that manages the withdrawal account information”, to perform the steps of “maintaining”, “performing”, “retrieving”, “reading”, and “generating”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a financial transaction management system in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claims 3 and 5 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 3 recites the additional elements of “A transaction management system for processing a transaction, the transaction management system comprising: a computer, a billing information memory, and a vendor information memory, the billing information memory maintains a structured data set in which a plurality of billing records respectively corresponding to transactions occurring at different stages of multi-stage supply chain are commonly linked through a chain identifier that identifies a transaction chain; the computer is configured to:”.
Claim 5 recites the additional elements of “A non-transitory computer readable medium storing a program for transaction processing in a transaction management system comprising a computer, a billing information memory, and a vendor information memory, maintaining, in the billing information memory, a structured data set in which a plurality of billing records respectively corresponding to transactions occurring at different stages of a multi-stage supply chain are commonly linked through a chain identifier that identifies a transaction chain; the program when read and executed, causes a computer, in response to receiving remittance by the system for the transaction, to automatically perform operations comprising:”.
For similar reasons as explained above with regard to claim 1, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Dependent claims 2, 4, and 6 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-6 are not patent-eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Quillian, U.S. Patent Application Publication Number 2018/0330436; in view of Klein, U.S. Patent Application Publication Number 2012/0116963; in view of Miller, U.S. Patent Application Publication Number 2014/0244490.
As per claim 1,
Quillian explicitly teaches:
A transaction processing method executed by a computer in a transaction management system comprising a billing information memory, and a vendor information memory, the method comprising: maintaining, in the billing information memory, a structured data set in which a plurality of billing records respectively corresponding to transactions occurring at a different stages of a multi-stage supply chain are commonly linked through a chain identifier that identifies a transaction chain;
(Quillian US20180330436 at Figs. 28-B, 31, paras. 13-18, 140-141, 232-234, 302-304) ("[0303] Still referring to FIG. 1D, once an irrevocable sell offer is accepted, then steps 7 though 13 occur in rapid succession. As a result of the OSA, supplier 108 agrees that all of its right, title, and interest in and to the drafts will be sold, assigned, and transferred to financial institution 110 via negotiation of associated drafts, without any further action or documentation on the part of supplier 108, buyer 106, or financial institution 110. As part of the CMSA, buyer 106 agrees that any draft that is transferred by supplier 108 will be recognized by the buyer as having been validly sold and assigned to the relevant transferee. Pursuant to the Financial Institution Agreement, the sell offer's acceptance and resulting execution of time drafts associated with the payment obligations on the buyer's behalf, along with the supplier's indorsement to the financial institution, negotiate the drafts to the financial institution's possession. In the case of electronic drafts, the community manager retains custody of the drafts on the financial institution's behalf. At step 7, for trade receivables and electronic or printable time drafts, financial institution 110 first deposits the net financial institution amount into a financial institution payment account 44. Financial institution 110 may also use a “zero balance account” for this purpose. Once an acceptance has been registered in SCF system 10 and the net financial institution amount deposited into financial institution payment account 44, the trade receivable's or draft's purchase is agreed by the parties to be complete, as a function of the contracts. Title to a draft, whether electronic or printable, changes from supplier 108 to financial institution 110, in that the time draft(s) is/are negotiated from the supplier to the financial institution at this time.")
retrieving, [from the billing information memory,] all billing records that share the chain identifier included [in the matched billing record];
(Quillian US20180330436 at Figs. 28-B, 31, paras. 13-18, 140-141, 232-234, 302-304) ("[0303] Still referring to FIG. 1D, once an irrevocable sell offer is accepted, then steps 7 though 13 occur in rapid succession. As a result of the OSA, supplier 108 agrees that all of its right, title, and interest in and to the drafts will be sold, assigned, and transferred to financial institution 110 via negotiation of associated drafts, without any further action or documentation on the part of supplier 108, buyer 106, or financial institution 110. As part of the CMSA, buyer 106 agrees that any draft that is transferred by supplier 108 will be recognized by the buyer as having been validly sold and assigned to the relevant transferee. Pursuant to the Financial Institution Agreement, the sell offer's acceptance and resulting execution of time drafts associated with the payment obligations on the buyer's behalf, along with the supplier's indorsement to the financial institution, negotiate the drafts to the financial institution's possession. In the case of electronic drafts, the community manager retains custody of the drafts on the financial institution's behalf. At step 7, for trade receivables and electronic or printable time drafts, financial institution 110 first deposits the net financial institution amount into a financial institution payment account 44. Financial institution 110 may also use a “zero balance account” for this purpose. Once an acceptance has been registered in SCF system 10 and the net financial institution amount deposited into financial institution payment account 44, the trade receivable's or draft's purchase is agreed by the parties to be complete, as a function of the contracts. Title to a draft, whether electronic or printable, changes from supplier 108 to financial institution 110, in that the time draft(s) is/are negotiated from the supplier to the financial institution at this time.")
based on the shared chain identifier;
(Quillian US20180330436 at Figs. 28-B, 31, paras. 13-18, 140-141, 232-234, 302-304) ("[0303] Still referring to FIG. 1D, once an irrevocable sell offer is accepted, then steps 7 though 13 occur in rapid succession. As a result of the OSA, supplier 108 agrees that all of its right, title, and interest in and to the drafts will be sold, assigned, and transferred to financial institution 110 via negotiation of associated drafts, without any further action or documentation on the part of supplier 108, buyer 106, or financial institution 110. As part of the CMSA, buyer 106 agrees that any draft that is transferred by supplier 108 will be recognized by the buyer as having been validly sold and assigned to the relevant transferee. Pursuant to the Financial Institution Agreement, the sell offer's acceptance and resulting execution of time drafts associated with the payment obligations on the buyer's behalf, along with the supplier's indorsement to the financial institution, negotiate the drafts to the financial institution's possession. In the case of electronic drafts, the community manager retains custody of the drafts on the financial institution's behalf. At step 7, for trade receivables and electronic or printable time drafts, financial institution 110 first deposits the net financial institution amount into a financial institution payment account 44. Financial institution 110 may also use a “zero balance account” for this purpose. Once an acceptance has been registered in SCF system 10 and the net financial institution amount deposited into financial institution payment account 44, the trade receivable's or draft's purchase is agreed by the parties to be complete, as a function of the contracts. Title to a draft, whether electronic or printable, changes from supplier 108 to financial institution 110, in that the time draft(s) is/are negotiated from the supplier to the financial institution at this time.")
Quillian does not explicitly teach, however, Klein does teach:
receiving, from a computer that manages deposit account information, a deposit notification including a purchaser identifier, a deposit amount, and a deposit account identifier;
(Klein US20120116963 at paras. 10-17, 55-58) ("[0012] According to some embodiments of the invention, another method is provided. The method comprising: receiving, via a computing device, invoice data from a merchant; identifying, via a computing device processor, a user based on the invoice data, wherein the user is associated with a payment; sending information associated with the invoice data to the user and receiving payment instructions from the user, wherein the payment instructions include an alias; and determining, via a computing device processor, that the merchant is a registered payment recipient based on the alias. [0013] In some embodiments of the method, the method further comprises determining, via a computing device processor, that the user owes the merchant a payment amount; presenting an invitation to the user to transfer a payment amount to the merchant; and communicating, via computing device, a payment notification to the merchant. In other embodiments, the method further comprises: determining, via a computing device processor, that the merchant owes the user a payment amount; receiving payment instructions from the merchant, wherein the payment instructions include an alias associated with the user; determining, via a computing device processor, that the user is a registered payment recipient based on the alias; and communicating, via a computing device, a payment notification to the user. In still other embodiments, wherein the payment amount is associated with a rebate amount that is owed to the user.")
performing, by the computer, and based on a predetermined multi-factor matching rule, a match between the deposit notification and one billing record in the structured data set;
(Klein US20120116963 at paras. 10-17, 55-58) ("[0011] In some embodiments, the method further comprises: identifying, via a computing device processor, one or more additional users; and presenting a list of the additional users to the merchant. In other embodiments, the invoice comprises data selected from the group consisting of: product identification; quantity of items ordered; price of each item; fees for services or products; tax amounts; total amount due; date payment is due; payment history; explanation of fees; explanation of services; shipping information, or combinations thereof. [0012] According to some embodiments of the invention, another method is provided. The method comprising: receiving, via a computing device, invoice data from a merchant; identifying, via a computing device processor, a user based on the invoice data, wherein the user is associated with a payment; sending information associated with the invoice data to the user and receiving payment instructions from the user, wherein the payment instructions include an alias; and determining, via a computing device processor, that the merchant is a registered payment recipient based on the alias.")
retrieving, from the billing information memory, [all billing records that share the chain identifier included] in the matched billing record;
(Klein US20120116963 at paras. 10-17, 55-58) ("[0010] In some embodiments, the method further comprises: determining that the alias is associated with a registered bank account of the merchant. In other embodiments, the alias comprises an identifier selected from the group consisting of: a mobile telephone number, an email address, a social networking ID, a name, an address, a URL address, a logo, a brand, a picture, graphical art, a trade name, a trade mark, or combinations thereof. In still other embodiments, the method further comprises: receiving a search term from the merchant; matching, via a computing device processor, the search term with the at least one invoice in the storage device; identifying, via a computing device processor, the user based on the at least one invoice. [0011] In some embodiments, the method further comprises: identifying, via a computing device processor, one or more additional users; and presenting a list of the additional users to the merchant. In other embodiments, the invoice comprises data selected from the group consisting of: product identification; quantity of items ordered; price of each item; fees for services or products; tax amounts; total amount due; date payment is due; payment history; explanation of fees; explanation of services; shipping information, or combinations thereof.")
reading deposit account information corresponding to the billing source identifier, and withdrawal account information corresponding to the billing recipient identifier,
(Klein US20120116963 at paras. 10-17, 55-58) ("[0010] In some embodiments, the method further comprises: determining that the alias is associated with a registered bank account of the merchant. In other embodiments, the alias comprises an identifier selected from the group consisting of: a mobile telephone number, an email address, a social networking ID, a name, an address, a URL address, a logo, a brand, a picture, graphical art, a trade name, a trade mark, or combinations thereof. In still other embodiments, the method further comprises: receiving a search term from the merchant; matching, via a computing device processor, the search term with the at least one invoice in the storage device; identifying, via a computing device processor, the user based on the at least one invoice. [0011] In some embodiments, the method further comprises: identifying, via a computing device processor, one or more additional users; and presenting a list of the additional users to the merchant. In other embodiments, the invoice comprises data selected from the group consisting of: product identification; quantity of items ordered; price of each item; fees for services or products; tax amounts; total amount due; date payment is due; payment history; explanation of fees; explanation of services; shipping information, or combinations thereof.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Quillian and Klein, because it allows for improved user-friendly systems and methods for invoicing and electronic billing. (Klein at Abstract and paras. 2-10).
Quillian and Klein do not explicitly teach, however, Miller does teach:
automatically updating, by the computer, payment states of all retrieved billing records to a payable state in a single integrated operation
(Miller US20140244490 at paras. 59-63) ([0060] As shown in FIG. 2, bills can enter the bill paying system from a number of points: electronic bills 201 (e.g., an email request or digital image), redirected physical paper mail 202, as well as physical paper mail provided by the client, or via other means 203. An individual that manages the paying of bills for a client or group of clients can submit bills for processing, or an individual can submit their own bills. From there this “mail” is collected into one central or multiple sorting stations 200 and converted into a digital form, such as by being scanned to produce an image file. A sorting station can be configured to receive only a particular type of mail or any type of mail. Optical character recognition (OCR) software 204 may be used to find and extract information to be loaded into an Internet based management system. At this point, the bills are loaded and filed by client and according to vendor identifiers or data fields. The clients as well as an operator are able to access this internet based database to review statements current and past. The mail is sorted by client and reviewed against a subsystem to determine any missing or irregular mail. The OCR system and corresponding software program extracting data from each bill loads the data into three databases, one for vendor information 205, one for client information 206 and one for bill images per client 207. Within the client database there is a database of client preferences, operator notes, averages of previous and expected future payments as well as expected arrival and payment dates, as well as personal ledger profiling and other information. The operating system 208 receives data from the client database 206, the vendor database 205 and the image database 207 to determine which bills are payable 209 and which bills are not payable 210. [0061] As shown in FIG. 3, an automated bill paying system 300 can review the incoming bills 301 against historical data, client preferences 302 and aggregate data from the system and then either recommend each bill for payment 306 to the operator using client bank account data 305 or flag the bill and submit it to a file for further review 307. For the payable bills, the operators can then go ahead and submit for payment. The system may also produce a record indicating why the bill was paid, where this record is provided for the client's option to view. For the paid bill, the client is alerted on the front or starter page for the client of the management system that the bill is paid and what the corresponding amount has been. For unpaid bills that require further attention by the system operator, a subsystem notes changes to the account as well as logs disputes or trouble with a particular vendor 304. These notes are made available to the client and other operators. The operator communicates via email, through the bill paying system itself via a vendor dispute subsystem, or over the phone to collect and pass along information potentially required to overcome the dispute. If this process is successful, the bill is catalogued per the payable bill process.)
for each of the billing records whose payment state is set to the payable state, reading a billing source identifier, a billing recipient identifier, and a billing amount from the billing information memory; and
(Miller US20140244490 at paras. 59-63, 94-96) ("[0060] The operating system 208 receives data from the client database 206, the vendor database 205 and the image database 207 to determine which bills are payable 209 and which bills are not payable 210. [0061] As shown in FIG. 3, an automated bill paying system 300 can review the incoming bills 301 against historical data, client preferences 302 and aggregate data from the system and then either recommend each bill for payment 306 to the operator using client bank account data 305 or flag the bill and submit it to a file for further review 307. For the payable bills, the operators can then go ahead and submit for payment. The system may also produce a record indicating why the bill was paid, where this record is provided for the client's option to view. For the paid bill, the client is alerted on the front or starter page for the client of the management system that the bill is paid and what the corresponding amount has been. For unpaid bills that require further attention by the system operator, a subsystem notes changes to the account as well as logs disputes or trouble with a particular vendor 304. These notes are made available to the client and other operators. The operator communicates via email, through the bill paying system itself via a vendor dispute subsystem, or over the phone to collect and pass along information potentially required to overcome the dispute. If this process is successful, the bill is catalogued per the payable bill process. [0062] On an ongoing basis, the client presentation subsystem is able to provide current and past data and employs a database to sort bills by month. Each digital image of a paid bill is matched to a corresponding vendor and amount paid and displayed to the client. This data is sorted by month and then by year. Each operator can be assigned to multiple clients and is thus given the ability to sort by client and manage each client individually from one bill paying system. The ability also exists in the bill paying system to change the user profile so that a user is defined as an operator with one client assigned to them and this client is the user themself. In this setting the user is managing their own account and the module settings are adjusted to reflect this change. An administrator is given full access to both operator and client views as well as the ability to create and terminate client and operator accounts when needed.")
reading account information … from the vendor information memory;
(Miller US20140244490 at paras. 59-63, 94-96) ("[0060] The operating system 208 receives data from the client database 206, the vendor database 205 and the image database 207 to determine which bills are payable 209 and which bills are not payable 210. [0061] As shown in FIG. 3, an automated bill paying system 300 can review the incoming bills 301 against historical data, client preferences 302 and aggregate data from the system and then either recommend each bill for payment 306 to the operator using client bank account data 305 or flag the bill and submit it to a file for further review 307. For the payable bills, the operators can then go ahead and submit for payment. The system may also produce a record indicating why the bill was paid, where this record is provided for the client's option to view. For the paid bill, the client is alerted on the front or starter page for the client of the management system that the bill is paid and what the corresponding amount has been. For unpaid bills that require further attention by the system operator, a subsystem notes changes to the account as well as logs disputes or trouble with a particular vendor 304. These notes are made available to the client and other operators. The operator communicates via email, through the bill paying system itself via a vendor dispute subsystem, or over the phone to collect and pass along information potentially required to overcome the dispute. If this process is successful, the bill is catalogued per the payable bill process. [0062] On an ongoing basis, the client presentation subsystem is able to provide current and past data and employs a database to sort bills by month. Each digital image of a paid bill is matched to a corresponding vendor and amount paid and displayed to the client. This data is sorted by month and then by year. Each operator can be assigned to multiple clients and is thus given the ability to sort by client and manage each client individually from one bill paying system. The ability also exists in the bill paying system to change the user profile so that a user is defined as an operator with one client assigned to them and this client is the user themself. In this setting the user is managing their own account and the module settings are adjusted to reflect this change. An administrator is given full access to both operator and client views as well as the ability to create and terminate client and operator accounts when needed.")
generating, by the computer, transfer instruction information including the deposit account information, the withdrawal account information, and a transfer amount based on the billing amount; and
(Miller US20140244490 at paras. 59-63, 94-96) ("[0060] The operating system 208 receives data from the client database 206, the vendor database 205 and the image database 207 to determine which bills are payable 209 and which bills are not payable 210. [0061] As shown in FIG. 3, an automated bill paying system 300 can review the incoming bills 301 against historical data, client preferences 302 and aggregate data from the system and then either recommend each bill for payment 306 to the operator using client bank account data 305 or flag the bill and submit it to a file for further review 307. For the payable bills, the operators can then go ahead and submit for payment. The system may also produce a record indicating why the bill was paid, where this record is provided for the client's option to view. For the paid bill, the client is alerted on the front or starter page for the client of the management system that the bill is paid and what the corresponding amount has been. For unpaid bills that require further attention by the system operator, a subsystem notes changes to the account as well as logs disputes or trouble with a particular vendor 304. These notes are made available to the client and other operators. The operator communicates via email, through the bill paying system itself via a vendor dispute subsystem, or over the phone to collect and pass along information potentially required to overcome the dispute. If this process is successful, the bill is catalogued per the payable bill process. [0062] On an ongoing basis, the client presentation subsystem is able to provide current and past data and employs a database to sort bills by month. Each digital image of a paid bill is matched to a corresponding vendor and amount paid and displayed to the client. This data is sorted by month and then by year. Each operator can be assigned to multiple clients and is thus given the ability to sort by client and manage each client individually from one bill paying system. The ability also exists in the bill paying system to change the user profile so that a user is defined as an operator with one client assigned to them and this client is the user themself. In this setting the user is managing their own account and the module settings are adjusted to reflect this change. An administrator is given full access to both operator and client views as well as the ability to create and terminate client and operator accounts when needed.")
transmitting, by the computer, the transfer instruction information to a computer that manages the withdrawal account information.
(Miller US20140244490 at paras. 59-63, 94-96) ("[0060] The operating system 208 receives data from the client database 206, the vendor database 205 and the image database 207 to determine which bills are payable 209 and which bills are not payable 210. [0061] As shown in FIG. 3, an automated bill paying system 300 can review the incoming bills 301 against historical data, client preferences 302 and aggregate data from the system and then either recommend each bill for payment 306 to the operator using client bank account data 305 or flag the bill and submit it to a file for further review 307. For the payable bills, the operators can then go ahead and submit for payment. The system may also produce a record indicating why the bill was paid, where this record is provided for the client's option to view. For the paid bill, the client is alerted on the front or starter page for the client of the management system that the bill is paid and what the corresponding amount has been. For unpaid bills that require further attention by the system operator, a subsystem notes changes to the account as well as logs disputes or trouble with a particular vendor 304. These notes are made available to the client and other operators. The operator communicates via email, through the bill paying system itself via a vendor dispute subsystem, or over the phone to collect and pass along information potentially required to overcome the dispute. If this process is successful, the bill is catalogued per the payable bill process. [0062] On an ongoing basis, the client presentation subsystem is able to provide current and past data and employs a database to sort bills by month. Each digital image of a paid bill is matched to a corresponding vendor and amount paid and displayed to the client. This data is sorted by month and then by year. Each operator can be assigned to multiple clients and is thus given the ability to sort by client and manage each client individually from one bill paying system. The ability also exists in the bill paying system to change the user profile so that a user is defined as an operator with one client assigned to them and this client is the user themself. In this setting the user is managing their own account and the module settings are adjusted to reflect this change. An administrator is given full access to both operator and client views as well as the ability to create and terminate client and operator accounts when needed.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Quillian, Klein, and Miller, because automating certain aspects of the bill-paying process allows for improved efficiency, security and customer service, managing the payment of bills for an individual or group of individuals, improves automation, security, and oversight of the process, and the system is designed to pay bills for a large number of individuals on their behalf, and allows the operator the ability to not only display client data but primarily to capture client preferences, notes, records, vendor disputes, improve client data security, automate and improve system auditing capabilities, as well as automating some of the more basic yet essential tasks, including the creation of a personalized ledger. (Miller at Abstract and paras. 2-14, 47, 104, 107).
Claims 3 and 5 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claims 2, 4, and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Quillian, U.S. Patent Application Publication Number 2018/0330436; in view of Klein, U.S. Patent Application Publication Number 2012/0116963; in view of Miller, U.S. Patent Application Publication Number 2014/0244490 ; in view of Erbey, U.S. Patent Application Publication Number 2011/0302047.
As per claim 2,
Quillian explicitly teaches:
wherein the transaction management system further comprises a ledger data memory that store, for each vendor, a vendor identifier and accounting ledger information associated with the vendor identifier, and
(Quillian US20180330436 at Figs. 28-B, 31, paras. 644-646) ("[0645] FIG. 30 illustrates a screen image 851 of a document tracking search page available in the user interfaces for all system participants, i.e. suppliers, financial institutions, buyers, community managers, and the service provider. In the presently-described embodiment, only those entity users having a “track documents” security role may access this page. Upon selecting the document search, the user is presented with a first screen 852 at which the user selects the desired document type from a pull-down menu. Upon selecting a document type, a secondary window 853 presents a series of search criteria specific to that document type. In the example shown in FIG. 30, the user has selected “time drafts,” and the search criteria in window 853 relate to data stored in database 452 for time drafts and that may be used to generate a search query. Upon defining the desired search criteria, the user executes the search by activating a “search” button. FIG. 31 provides an image of a search report screen 854 resulting from the search executed from page 851 in FIG. 30. Activation of the hyperlink for a given draft reference ID in the search results page presents a time draft detail report, as shown in FIG. 28. This screen presents a list 855 providing information regarding the payment obligations underlying a given time draft. Buy offer details may be viewed on a buy offer details page 856 illustrated in FIG. 32. Screen 856 may be accessed by activating a hyperlink under the “buy offer reference ID” column of screen 854 in FIG. 31. Screen 856 identifies the number of time drafts associated with the buy offer. The trade cost is the amount the trade cost the financial institution. It consists of the amounts paid to the supplier, the service provider, and the community manager. The difference between trade cost and certified value is the financial institution margin. The program management/interest fee is the sum of the amounts paid to the service provider and the community manager. Screen 856 provides access to a details page 857, shown in FIG. 33, through activation of a “view” hyperlink. Activation of the hyperlink in the “draft” column of screen 857 for any row brings the time draft detail page, shown in FIG. 28, for that time draft. If, at screen 852 in FIG. 30, the user selects “trades,” and executes a search in a resulting page 853 for trades, the system presents a screen 858, as shown in FIG. 34. Note the “trade type” column, which indicates whether the trade is a trade of receivables (TR) or of time drafts (TD). The “suppliers funds received” is the amount paid to the supplier based on the trade. It is displayed immediately after the trade occurs. The “supplier interest/fees” is the supplier rate amount plus the supplier transaction fees, if any. The “program management interest/fees” is the service provider rate amount, the service provider's portion of transaction fees (if any), the community rate amount, and the community portion of any transaction fees.")
Quillian, Klein, and Miller do not explicitly teach, however, Erbey does teach:
the computer is further configured to: after receiving a remittance completion notification corresponding to the transfer instruction information record, in the account ledger information associated with a vendor identifier of a vendor that requested the completed transfer, a journal entry for a withdrawal corresponding to the completed transfer; and
(Erbey US20110302047 at paras. 80-84) ("[0081] FIGS. 4A and 4B show an example flow diagram of a process for providing ordering, invoice presentment, and payment, in accordance with an embodiment of the present invention. As shown in FIG. 4A, a request for an ordered item, such as a good or service (e.g., order placement) first occurs 40, such as between a requestor (e.g., payor) and a transaction repository (e.g., transaction database). A receivable call (e.g., unbilled and in real time) is then generated from the transaction repository to a charging system 41. The receivable call includes, for example, information about accounts receivable, such as payment due from the payor for the ordered item. A journal entry or other record is transmitted to a general ledger (GL) repository (e.g., database) 42. [0082] As further shown in FIG. 4A, a pricing module is then accessed to determine the vendor/requestor price for the requested good or service 43. The order is placed with the vendor 44. A confirmation process then occurs 45, such as passing of a final agreed upon price and an original price through a charging module. A call (e.g., unbilled and in real-time) is then generated from the transaction repository to the vendor 46. The call includes, for example, information about accounts payable, such as payment due to the vendor for the ordered item. [0083] In an embodiment of the present invention, upon approval, a communication occurs from the vendor to the transaction repository and to the requestor 47. The transaction repository then communicates approval to the charging system 48, and an electronic invoice is generated 49. The invoice is approved 50, billing presentment occurs 51, any dispute resolution occurs 52, and payment is made 53. Information regarding the transaction is then communicated to an accounts payable (AP) repository, the GL repository, and an accounts receivable (AR) repository 54.")
record, in the accounting ledger information associated with a vendor identifier of a vendor that is a billing source of the completed transfer, a journal entry for a deposit corresponding to the completed transfer.
(Erbey US20110302047 at paras. 80-84) ("[0081] FIGS. 4A and 4B show an example flow diagram of a process for providing ordering, invoice presentment, and payment, in accordance with an embodiment of the present invention. As shown in FIG. 4A, a request for an ordered item, such as a good or service (e.g., order placement) first occurs 40, such as between a requestor (e.g., payor) and a transaction repository (e.g., transaction database). A receivable call (e.g., unbilled and in real time) is then generated from the transaction repository to a charging system 41. The receivable call includes, for example, information about accounts receivable, such as payment due from the payor for the ordered item. A journal entry or other record is transmitted to a general ledger (GL) repository (e.g., database) 42. [0082] As further shown in FIG. 4A, a pricing module is then accessed to determine the vendor/requestor price for the requested good or service 43. The order is placed with the vendor 44. A confirmation process then occurs 45, such as passing of a final agreed upon price and an original price through a charging module. A call (e.g., unbilled and in real-time) is then generated from the transaction repository to the vendor 46. The call includes, for example, information about accounts payable, such as payment due to the vendor for the ordered item. [0083] In an embodiment of the present invention, upon approval, a communication occurs from the vendor to the transaction repository and to the requestor 47. The transaction repository then communicates approval to the charging system 48, and an electronic invoice is generated 49. The invoice is approved 50, billing presentment occurs 51, any dispute resolution occurs 52, and payment is made 53. Information regarding the transaction is then communicated to an accounts payable (AP) repository, the GL repository, and an accounts receivable (AR) repository 54.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Quillian, Klein, Miller, and Erbey, because it provides a wide range of electronic ordering, invoice presentment, and payment functions within a single method and system, which are useful, for example, for large organizations and allows for automated ordering, invoice presentment, and payment of third party goods and services. (Erbey at Abstract and paras. 2-22).
Claims 4 and 6 are substantially similar to claim 2, thus, they are rejected on similar grounds.
Response to Arguments
Applicant’s arguments filed on December 24, 2025 have been fully considered but are not persuasive for the following reasons:
With respect to Applicant’s arguments as to the § 101 rejections for now pending claims 1-6, Examiner notes the following:
Applicant argues that the claims are not directed to an abstract idea.
Examiner disagrees, however, and notes that the claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate a financial transaction management system, e.g., providing payment transactions between multiple vendors and recording of ledgers related to payments among multiple vendors. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Applicant argues that the amended features would integrate the abstract idea into a practical application, the examiner respectfully disagrees. In particular, the applicant argues that “the claims as amended clarify improvements in the technology.” Applicant argues that various effects “demonstrate improvements in system efficiency and reliability”, e.g., utilizing a chain identifier as a technical data structure, automated state transitions and integrated operations, and reduction of computer and network resource consumption.
Examiner disagrees and notes that the additional elements of the computer system - “A transaction processing method executed by a computer in a transaction management system comprising a billing information memory, and a vendor information memory, the method comprising:”, “a computer that manages deposit account information”, and “a computer that manages the withdrawal account information”, to perform the steps of “maintaining”, “performing”, “retrieving”, “reading”, and “generating”, in all steps is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. The claims at issue covers collecting, analyzing, and transmitting data to facilitate a financial transaction management system, e.g., providing payment transactions between multiple vendors and recording of ledgers related to payments among multiple vendors. The claims invoke the “A transaction processing method executed by a computer in a transaction management system comprising a billing information memory, and a vendor information memory, the method comprising:”, “a computer that manages deposit account information”, and “a computer that manages the withdrawal account information”, to perform the steps of “maintaining”, “performing”, “retrieving”, “reading”, and “generating” merely as tools to execute the abstract idea. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a certain method of organizing human activity or mental process or mathematical calculation) does not integrate a judicial exception into a practical application. (MPEP 2106.05 (f))
Examiner notes that the stated problems of “a more efficient and reliable system” is not a technical problem, and the claimed solution is not a technical solution. In the claim, the solution of utilizing a chain identifier as a technical data structure, automated state transitions and integrated operations, and reduction of computer and network resource consumption is part of the abstract idea, as it is merely involves collecting, analyzing, and transmitting data to facilitate a financial transaction management system. Furthermore, the data manipulation and analysis could be completed mentally or manually by paper or pen.
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1-6, Examiner notes that the arguments are moot in light of the new grounds for rejection.
Additionally, Applicant argues that Quillian and Miller fail to teach “Quillian fails to disclose generating [real-time] transfer instruction information based on vendor-specific account information and transmitting it to an external withdrawal-account-management computer.” Examiner notes that the claims do not require a “real-time” transfer instruction. Applicant’s argument relies on importing limitations from the specification into the claims. It is improper to import claim imitations from the specification. (See MPEP 2111).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9: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, Christine Tran can be reached on 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.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695