Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Application
Claims 1-6, 9-17, and 21-22 have been examined in this application.
The filling date of this application number recited above is 13-September-2023. No priority has been claimed in the Application Data Sheet, thus the examination will be undertaken in consideration of the effective filing date as the priority date.
No additional information disclosure statement (IDS) has been filed to date.
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, 9-17, and 21-22 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. The Claims are directed to an abstract idea, Certain Methods of Organizing Human Activity and/or Mental Process. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea.
As per Claims 1, 12, and 18, the claims recite “a method comprising:
receiving, at a transaction data service for an expense management [service] used by a company, transaction information of a plurality of merchant transactions made with a corporate payment card of a plurality of corporate payment cards, each linked to the company, said corporate payment cards being registered at the expense management [service], the transaction information for each of the plurality of merchant transactions including at least a merchant identification associated with a given merchant transaction of the merchant transactions and identification of the corporate payment card of the plurality of corporate payment cards associated with the given merchant transaction;
responsive to receipt of the transaction information, obtaining, from a merchant data mapping resource, for each of the plurality of merchant transactions made with the corporate payment card, merchant content corresponding to the merchant identification associated with each of the plurality of merchant transactions made using the corporate payment card, wherein each instance of the merchant content comprises a merchant identifying image and a merchant commercial brand name;
generating, at the transaction data service, a plurality of transaction display packages for each at least a portion of the plurality of merchant transactions for display in an expense review session for the corporate payment card, wherein each of the transaction display packages comprises the merchant identifying image and a merchant commercial brand name; and
providing, for display via a [display board] at the expense management [service] used by the company, merchant transaction specific line items, one per each of the plurality of merchant transactions associated with at least the corporate payment card, wherein each transaction specific line item comprises a corresponding transaction display package of the plurality of transaction display packages.”
As per Claim 21, the claim recites “a method for reducing human error when approving business expenses for reimbursement, the method comprising:
receiving transaction records for employee payment card transactions with merchants made via a payment [entity], each of said records needing to be approved by an expense manager utilizing a [booklet] with a [paper] for approval purposes;
identifying at least one of the received transaction records for a charged expense between an employee and a merchant, where the merchant is identified in the transaction records via a merchant identifier insufficient to clearly convey an identity of the merchant to the expense manager responsible for selectively approving the charged expense;
prior to presenting the transaction records on the [paper] to the expense manager, a transaction data service, … obtaining, … a merchant brand image associated with the merchant identifier;
responsive to the obtaining, constructing a transaction display package correlating the merchant brand image to respective a respective record of the transaction records; and
sending the transaction display package for display at the [paper] of the [booklet] so that upon being displayed via the [paper] to the expense manager responsible for approving a corresponding charged expense, the identified transaction records comprise the merchant brand image as the corresponding merchant identifier was identified as being insufficient to clearly convey the identity of the merchant to the expense manager.”
The limitation of the claims recited above, considering the claims without the additional elements (e.g. processor, platform, graphical user interface, etc.), under its broadest reasonable interpretation (BRI), recites certain methods of organizing human activities, specifically under fundamental economic principles or practices and/or commercial or legal interactions. The method recited above is a process of analyzing information with respect to the merchant transaction data made with a payment card, wherein the data analysis includes receiving information, finding or comparing information based on stored resource, generating information, and providing information for display. Performing all these steps associated with the transaction information is fundamental economic principles or practices, and the interactions with another entity for the transaction data service involved to receive information, provide information, and display information associated with the transaction data may be commercial or legal interactions, which are all under certain methods of organizing human activities. Therefore, the claims recite an abstract idea.
Additionally, under BRI, the claims also recite Mental Process. The claims recite a process of receiving information, obtaining a resource used to compare and identify information, generating information, and providing information for display. All these steps can be performed in the human mind and/or by a human with pen and paper, as disclosed by MPEP 2106.04(a)(2)(III):
“In contrast, claims do recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include:
• a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016);
• claims to "comparing BRCA sequences and determining the existence of alterations," where the claims cover any way of comparing BRCA sequences such that the comparison steps can practically be performed in the human mind, University of Utah Research Foundation v. Ambry Genetics, 774 F.3d 755, 763, 113 USPQ2d 1241, 1246 (Fed. Cir. 2014);
• a claim to collecting and comparing known information (claim 1), which are steps that can be practically performed in the human mind, Classen Immunotherapies, Inc. v. Biogen IDEC, 659 F.3d 1057, 1067, 100 USPQ2d 1492, 1500 (Fed. Cir. 2011); and
• a claim to identifying head shape and applying hair designs, which is a process that can be practically performed in the human mind, In re Brown, 645 Fed. App'x 1014, 1016-17 (Fed. Cir. 2016) (non-precedential).”
Although the claim may recite using a computer to receive, determine, and display data, performing a mental process on a generic computer still recite a mental process. See MPEP 2106.04(III)(C):
“Claims can recite a mental process even if they are claimed as being performed on a computer. The Supreme Court recognized this in Benson, determining that a mathematical algorithm for converting binary coded decimal to pure binary within a computer’s shift register was an abstract idea. The Court concluded that the algorithm could be performed purely mentally even though the claimed procedures "can be carried out in existing computers long in use, no new machinery being necessary." 409 U.S at 67, 175 USPQ at 675. See also Mortgage Grader, 811 F.3d at 1324, 117 USPQ2d at 1699 (concluding that concept of "anonymous loan shopping" recited in a computer system claim is an abstract idea because it could be "performed by humans without a computer").”
Therefore, the claims recite an abstract idea, mental process.
This judicial exception is not integrated into practical application. In particular, the claims recite an additional element of “platform”, “graphical user interface”, “computer-readable storage medium”, “network”, “user device”, and “computing system”, to perform the method recited above by instructing the abstract idea to be performed “by” these generic computer components. These general computer components are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. These additional elements are generic, off-the-shelf components available to the public, and does not require any specialized hardware or equipment to perform the claimed method, but are merely applied to perform its basic functionalities and perform them “automatically”, such as: receive data, compare data, generate data, and provide data, as disclosed by Figure 6 and Specification:
[0062] “Figure 6 illustrates components of a computing system. Embodiments of the described expense management platform and transaction data service may be implemented as computing system 600. Referring to Figure 6, system 600 may be implemented within a single computing device or distributed across multiple computing devices or sub-systems that cooperate in executing program instructions. The system 600 can include one or more blade server devices, standalone server devices, personal computers, routers, hubs, switches, bridges, firewall devices, intrusion detection devices, mainframe computers, network- attached storage devices, and other types of computing devices.”
[0063] “The system 600 can include a processing system 620, which may include one or more processors and/or other circuitry that retrieves and executes software 605 from storage system 615 … Examples of processing system 620 include general purpose central processing units, application specific processors, and logic devices, as well as any other type of processing device, combinations, or variations thereof.”
For example, mere instructions to display information on a GUI does not improve computer functionality, see MPEP 2106.05(a)(I) example that the courts have indicated may not be sufficient to show an improvement in computer-functionality: “Arranging transactional information on a graphical user interface in a manner that assists traders in processing information more quickly, Trading Technologies v. IBG LLC, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019)”. Mere instructions to implement the abstract idea on the generic computer system, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of integration into a practical application; see MPEP 2106.05(f). Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, transmit, compare, or display data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activities or mental process) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). 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 claims are directed to an abstract idea.
The claims do not include additional elements 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, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, the additional element of using a computer based system is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. The claims lack sufficient technical details to provide how these limitations may provide technological steps or technical details on how it is particularly implemented on a computer to improve its system or any of its underlying hardware or components (e.g. how it is performed on the system, how it could improve the system itself, how it could manipulate the system to function in a specific way other than its generic functionality, and/or how it could improve any of the underlying technology), but merely applies the generic computer system to perform its generic functionalities. Mere instructions to implement the abstract idea on the generic computer system, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of an inventive concept (aka “significantly more”). In view of the Specification, the judicial exception is not applied with or used by a particular machine. As held in Parker v. Flook, 437 U.S. 584, 590, 198 USPQ 193, 199 (1978) and Bancorp Services v. Sun Life, 687 F.3d 1266, 1276, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012), “the routine use of a computer to perform calculations cannot turn an otherwise ineligible mathematical formula or law of nature into patentable subject matter.” The claims are not patent eligible.
Regarding dependent claims, they are still directed to an abstract idea without significantly more.
Claims 2 and 13 recite “wherein generating the plurality of transaction display packages for at least a portion of the plurality of merchant transactions for display comprises replacing the merchant identification associated with each of the plurality of merchant transactions in the transaction information with a corresponding of the obtained merchant identifying images.” The claims provide further steps regarding the information (e.g. replace information), which is still part of the abstract idea, and mere “apply it” is not indicative of integration into a practical application.
Claim 3 recites “wherein the merchant identifying image comprises a merchant logo.” The claims provide further details regarding the information, which is still part of the abstract idea, and mere “apply it” is not indicative of integration into a practical application.
Claim 4 recites “wherein each instance of the merchant content further comprises a merchant location and wherein each of the plurality of transaction display packages further comprises a map image of the merchant location.” The claims provide further details regarding the information, which is still part of the abstract idea, and mere “apply it” is not indicative of integration into a practical application.
Claim 5 recites “wherein the transaction information of the plurality of merchant transactions made with the corporate payment card is received at the transaction data service in response to the expense management platform receiving a call to provide content to display to a particular endpoint where the content to display includes the transaction information of the plurality of merchant transactions made with the corporate payment card.” The claim provides further steps to display information, which is still part of the abstract idea, and mere “apply it” is not indicative of integration into a practical application.
Claims 6 and 14 recite “wherein generating the transaction display package comprises selecting a particular size of each merchant identifying image of the merchant content to customize the transaction display package according to the particular endpoint.” The claims provide further details regarding the information, which is still part of the abstract idea, and mere “apply it” is not indicative of integration into a practical application.
Claims 9 and 15 recite “further comprising: applying, by the expense management platform, persona rules to the plurality of transactions merchant transactions made using the corporate payment card.” The claims provide further steps of applying rules, which is still part of the abstract idea, and mere “apply it” is not indicative of integration into a practical application.
Claims 10 and 16 recite “wherein applying persona rules to each of the plurality of merchant transactions made using the corporate payment card comprises: identifying an employee associated with the corporate payment card having conducted the plurality of merchant transactions; retrieving persona rules corresponding to a particular persona assigned to the employee; determining that at least one merchant transaction of the plurality of merchant transactions does not satisfy the persona rules corresponding to the particular persona; and applying indicators to the transaction specific line item associated with the at least one merchant transaction to cause flags or highlighting to surface in the graphical user interface at the expense management platform.” The claims provide further details regarding the rules, which is still part of the abstract idea, and mere “apply it” is not indicative of integration into a practical application.
Claims 11 and 17 recite “further comprising: identifying an employee associated with the corporate payment card having conducted the plurality of merchant transactions; determining an assigned persona of the employee; and providing an indication of the assigned persona with each of the transaction display packages.” The claims provide further steps of identifying an employee and providing information, which is still part of the abstract idea, and mere “apply it” is not indicative of integration into a practical application.
Claim 22 recites “wherein the method is performed by the transaction data service of an expense management platform for tracking, reporting, and reimbursing employee business expenses, where the transaction data service manages and aggregates expense management platform related data from multiple remotely located, independent sources, including a transaction data resource, a merchant data mapping resource, and a user device.” The claim provides further details regarding data gathering and/or manipulation which is still part of the abstract idea, and the additional elements are merely applied to implement the abstract idea, which is not indicative of integration into a practical application.
These additional steps of each claims fail to remedy the deficiencies of their parent claim above because they are merely further limiting the rules used to conduct the previously recited abstract idea, and are therefore rejected for at least the same rationale as applied to their parent claim above.
Claims 1-6, 9-11, 13-17, and 22, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitations fail to establish that the claims are sufficient to integrate into a practical application and do not amount to significantly more than the judicial exception. Similarly to the independent claims, each claim recites using a generic computer component to perform the abstract idea as mentioned above, wherein mere “apply it” is not “significantly more”. Therefore, prong 2 and step 2B analysis are similar to above and these claims are not eligible.
Therefore, Claims 1-6, 9-17, and 21-22 are not drawn to eligible subject matter as they are directed to an abstract idea 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 9, 12-13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Dodson et al. (US 20050222944 A1), in view of Johnsrud et al. (US 20170243217 A1) in further view of ELDER et al. (US 20220245103 A1), and in view of Tavares et al. (US 20130151344 A1).
As per Claims 1, 12, Dodson discloses a method comprising:
receiving, at a transaction data service for an expense management platform used by a company, transaction information of a plurality of merchant transactions made with a corporate payment card of a plurality of corporate payment cards ([0015] “In general, a system is provided for managing expense reports and the reimbursement of expenses, such as business-related expenses incurred by an employee using a corporate credit card, for example. An employee uses a corporate credit card to make various business-related, reimbursable transactions”), each linked to the company, said corporate payment cards being registered at the expense management platform ([0021] “Human resources module 14 is generally operable to store and manage employee data 40 regarding any number of employees of one or more organizations, one or more of which may be cardholders of credit cards 32 managed by credit card processing module 12. For example, in an embodiment in which system 10 is associated with a credit card provider organization, human resources module 14 may store and manage employee data 40 regarding employees of the credit card provider organization, some or all of which may be cardholders of corporate credit cards 32a provided by or otherwise associated with the credit card provider organization, for example”), the transaction information for each of the plurality of merchant transactions including at least a merchant identification associated with a given merchant transaction of the merchant transactions and identification of the corporate payment card of the plurality of corporate payment cards associated with the given merchant transaction ([0045] “At step 104, card processing module 12 automatically identifies, from the transactions details 34 of the transactions made by the employee using corporate credit card 32a” wherein [0019] “Credit card processing module 12 may also be operable to receive and process transaction details 34 of credit card transactions made using various credit cards 32 from various merchants, points of sale, or any other entity that performs credit card transactions”);
…;
generating, at the transaction data service, a plurality of transaction display packages for each at least a portion of the plurality of merchant transactions for display in the expense review session for the corporate payment card ([0056] “At step 126, image management module 18 may then create an index in image database 68 for the received receipt images 60 with the ID number determined from the identifier 58. The received receipt images 60 may be stored in image database 68 under the created index. The index may act as a link between the receipt images 60 stored in image database 68 and the expense report 44 maintained by expense report application 52 such that the receipt images 60 may be easily accessed and/or retrieved in connection with the expense report 44, such as for review by an expense manager or an accounting system, for example”), …; and
providing, for display via a graphical user interface at the expense management platform used by the company, merchant transaction specific line items, one per each of the plurality of merchant transactions associated with at least the corporate payment card, wherein each transaction specific line item comprises a corresponding transaction display package of the plurality of transaction display packages ([0057] “Management module 20 may communicate with expense report application 52 to generate a display of the expense report 44, the display identifying each of the transactions included in the expense report 44, including one or more transactions made using the corporate credit card 32a and/or one or more other transactions. The display may include an interface for accessing the receipt images 60 of the receipts 62 indexed in image database 68 under the ID number associated with the expense report 44. For example, the display of the expense report 44 may include a hotlink button which may be clicked in order to retrieve the receipt images 60 associated with the expense report 44”).
Although Dodson teaches a expense report management system for transactions used by corporate cards, which provides a display including each transactions with details, along with a link to access receipt images, the prior art reference does not seem to explicitly disclose the specific details that the transaction details include merchant identification or merchant contents. However, Johnsrud discloses:
receiving, at a transaction data service for an expense management platform …, transaction information of a plurality of merchant transactions … the transaction information for each of the plurality of merchant transactions including at least a merchant identification associated with a given merchant transaction of the merchant transactions … (See Figure 7 – step 704, as disclosed [0075] “In some embodiments, the process may include block 704, where the system receives a transaction request comprising transaction information associated with a new transaction, wherein the transaction information comprises a payment end point associated with an alternate merchant name of the one or more alternate merchant names that is not the legal merchant name. In some embodiments, the system is operated by a financial institution or other entity capable of processing payment requests between a customer and a merchant”);
responsive to receipt of the transaction information, obtaining, from a merchant data mapping resource, for each of the plurality of merchant transactions …, merchant content corresponding to the merchant identification associated with each of the plurality of merchant transactions …, wherein each instance of the merchant content comprises … a merchant commercial brand name (See Figure 7 – step 708, as disclosed [0079] “Once the payee name is matched with an alternate merchant name, the process 700 may progress to block 708, where the system determines, based on the block chain ledger, the legal name of the merchant associated with the transaction request”);
generating, at the transaction data service, a plurality of transaction display packages for each at least a portion of the plurality of merchant transactions for display in the expense review session for the corporate payment card, wherein each of the transaction display package comprises the merchant identifying image and a merchant commercial brand name (See Figure 7 – steps 710 and 712, as disclosed [0081] “With the appropriate legal name of the merchant identified, the system, as shown in block 710, can adjust the payment end point of the transaction information to replace the identified alternate merchant name with the legal name of the merchant” wherein [0085] “In some embodiments, the system may request a confirmation from the payer of the transaction request. The system may establish an electronic communication channel with a computing device (e.g., a mobile device) of the payer, and prompt a user interface of the computing device to display a request for confirmation of the name change. Such a confirmation request may describe the change from the alternate merchant name currently associated with the payment end point to the legal name of the merchant”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize the system of determining the details regarding the transaction information, such as the merchant’s legal name, as in Johnsrud in the system executing the method of Dodson with the motivation of offering to [0001-0003] provide efficient and reliable mode of recording and viewing information utilizing blockchain system as taught by Johnsrud over that of Dodson.
Although Johnsrud teaches of mapping the merchant transaction to a merchant’s legal name, the prior art reference does not seem to explicitly disclose of mapping the transaction to a merchant identifying image. However, ELDER discloses:
… wherein each instance of the merchant content comprises a merchant identifying image and a merchant commercial brand name ([0012] “Furthermore, in some implementations, the merchant key may provide an index to enhancement data that provides more detailed and useful information about the merchant and/or the transaction, such as image data (e.g., a corporate logo)”);
… wherein each of the transaction display package comprises the merchant identifying image and a merchant commercial brand name ([0027] “Additionally, or alternatively, the data cleansing platform may transform and/or otherwise reformat the information contained in the raw transaction records for the corresponding merchants (e.g., according to a standardized schema or data structure used for the lookup table) and/or associate the new and/or updated merchant keys with enhancement data based on one or more attributes associated with a corresponding merchant (e.g., a website, a logo, and/or an alternate business name such as a “doing business as” (DBA) trade name, among other examples)”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize image data (e.g. logo) of the merchant as in ELDER in the system executing the method of Johnsrud with the motivation of offering to [0010-0011] improve data quality as taught by ELDER over that of Johnsrud.
Although Dodson teaches a expense report management system for transactions used by corporate cards, which provides a display including each transactions with details, along with a link to access receipt images, the prior art reference does not seem to explicitly disclose the exact claim limitation that each transaction specific line item corresponds to the receipt image link. However, Tavares discloses:
providing, for display via a graphical user interface at the expense management platform used by the [user], merchant transaction specific line items, one per each of the plurality of merchant transactions associated with at least the … payment card, wherein each transaction specific line item comprises a corresponding transaction display package of the plurality of transaction display packages ([0031] “In other instances, a cardholder may request to view a receipt later, e.g., when a monthly statement is received. For example, an on-line monthly statement might include, for each transaction item on the statement, a hypertext link for viewing the receipt, and the cardholder uses that link to access the electronic receipt (e.g., using personal computer 160)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize the link to the receipt for each line item on the online card statement as in Tavares in the system executing the method of Dodson with the motivation of offering to [0002-0003] improve user experience by providing convenience and accessibility to electronic receipts while reducing the need of generating paper receipts as taught by Tavares over that of Dodson.
As per Claims 2 and 13, Dodson may not explicitly disclose, but ELDER discloses the method of claim 1, and the computer-readable storage medium of claim 12, wherein generating the plurality of transaction display packages for at least a portion of the plurality of merchant transactions for display comprises replacing the merchant identification associated with each of the plurality of merchant transactions in the transaction information with a corresponding of the obtained merchant identifying images ([0027] “Additionally, or alternatively, the data cleansing platform may transform and/or otherwise reformat the information contained in the raw transaction records for the corresponding merchants (e.g., according to a standardized schema or data structure used for the lookup table) and/or associate the new and/or updated merchant keys with enhancement data based on one or more attributes associated with a corresponding merchant (e.g., a website, a logo, and/or an alternate business name such as a “doing business as” (DBA) trade name, among other examples)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize reformatting the information with the corresponding merchant data as in ELDER in the system executing the method of Dodson with the motivation of offering to [0010-0011] improve data quality as taught by ELDER over that of Dodson.
As per Claim 3, Johnsrud may not explicitly disclose, but ELDER discloses the method of claim 1, wherein the merchant identifying image comprises a merchant logo ([0012] “Furthermore, in some implementations, the merchant key may provide an index to enhancement data that provides more detailed and useful information about the merchant and/or the transaction, such as image data (e.g., a corporate logo)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize image data (e.g. logo) of the merchant as in ELDER in the system executing the method of Johnsrud with the motivation of offering to [0010-0011] improve data quality as taught by ELDER over that of Johnsrud.
As per Claim 4, Dodson may not explicitly disclose, but ELDER discloses the method of claim 1, wherein each instance of the merchant content further comprises a merchant location and wherein each of the plurality of transaction display packages further comprises a map image of the merchant location ([0012] “Furthermore, in some implementations, the merchant key may provide an index to enhancement data that provides more detailed and useful information about the merchant and/or the transaction, such as … location data (e.g., to identify the merchant location on a map), among other examples”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize merchant location data and map data as in ELDER in the system executing the method of Dodson with the motivation of offering to [0010-0011] improve data quality as taught by ELDER over that of Dodson.
As per Claim 5, Dodson teaches the method of claim 1, wherein the transaction information of the plurality of merchant transactions made with the corporate payment card is received at the transaction data service in response to the expense management platform receiving a call to provide content to display to a particular endpoint where the content to display includes the transaction information of the plurality of merchant transactions made with the corporate payment card ([0057] “At step 128, an expense manager using management module 20 may review the expense report 44 maintained by expense report application 52. Management module 20 may communicate with expense report application 52 to generate a display of the expense report 44, the display identifying each of the transactions included in the expense report 44, including one or more transactions made using the corporate credit card 32a and/or one or more other transactions”).
As per Claims 9 and 15, Dodson teaches the method of claim 1, and the computer-readable storage medium of claim 12, further comprising: applying, by the expense management platform, persona rules to the plurality of transactions merchant transactions made using the corporate payment card ([0037] “Accounting module 22 may apply a set of accounting rules 70 to the expenses listed in an expense report 44 to identify any relevant accounting issues with the expense report 44, such as whether the threshold amount for a particular type of expense has been exceeded, whether required receipts 62 have been submitted, and whether "miscellaneous" expenses are valid for reimbursement, for example”).
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Dodson, in view of Johnsrud in further view of ELDER, in view of Tavares, and in view of Foran et al. (US 20060155613 A1).
As per Claims 6 and 14, Dodson may not explicitly disclose, but Foran teaches he method of claim 5, and the computer-readable storage medium of claim 12, wherein generating the transaction display package comprises selecting a particular size of each merchant identifying image of the merchant content to customize the transaction display package according to the particular endpoint ([0051-0053] “Ideally, there is stored different sizes of the same logo in the user file and the size of logo is chosen for display having regard to one or both of: the identity of the merchant computer; and the call code of the page).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize choosing the size of the logo based on the identity of the computer and the call code (i.e. particular enpoint) as in Foran in the system executing the method of Dodson with the motivation of offering to [0001-0004] reinforce the user friendliness of the merchant as taught by Foran over that of Dodson.
Claims 10-11 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Dodson, in view of Johnsrud in further view of ELDER, in view of Tavares, and in view of Cherry et al. (US 20140122305 A1).
As per Claims 10 and 16, Dodson may not explicitly disclose, but Cherry teaches the method of claim 9, and the computer-readable storage medium of claim 15, wherein applying persona rules to each of the plurality of merchant transactions made using the corporate payment card comprises:
identifying an employee associated with the corporate payment card having conducted the plurality of merchant transactions (See Figure 5 – employee name 502 which identifies the employee);
retrieving persona rules corresponding to a particular persona assigned to the employee ([0066] “Once data is received at 445, purchase card risk assessment is completed at 450. During this process, the risk factor rules are applied, by the risk assessment generator 315, to the purchase card transaction data, the purchase card user data, the purchase card data and any other relevant data in order to identify and apply and appropriate weighting (according to the risk factor rules) to any transactions”);
determining that at least one merchant transaction of the plurality of merchant transactions does not satisfy the persona rules corresponding to the particular persona ([0066] “Transactions identified as in violation of a risk factor rule are "risky transactions." The severity (e.g. dollar amount over a credit limit or number of prior flagged transactions) of the risk may be weighted based upon default settings or administer-altered settings of the risk assessment generator 315”); and
applying indicators to the transaction specific line item associated with the at least one merchant transaction to cause flags or highlighting to surface in the graphical user interface at the expense management platform ([0067] “So, the risk assessment generator 315 would identify the flagged transaction and, further, indicate that the prior flagged transaction rule has been violated for the purchase card user at 460. The resulting risk report provided at 470 may, for example, in the form of an email or a web page viewed by a supervisor or administrator, would highlight both issues as "risky" and have an associated risk weighting associated therewith” or see also Figure 5 – flag 512, as disclosed [0081] “The flag 512 may identify the specific risk factor rule that has been violated and that prompted the employee and transaction's identification in the purchase card management report 500”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize credit report displaying the transaction information (e.g. employee name, flagged risk rule, etc.) as in Cherry in the system executing the method of Dodson with the motivation of offering to mitigate risk by providing review and identification of transactions of the employees as taught by Cherry over that of Dodson.
As per Claims 11 and 17, Dodson may not explicitly disclose, but Cherry teaches the method of claim 1, and the computer-readable storage medium of claim 12, further comprising:
identifying an employee associated with the corporate payment card having conducted the plurality of merchant transactions (See Figure 5 – Employee Name 502);
determining an assigned persona of the employee (See Figure 5 – Auditor 518); and
providing an indication of the assigned persona with each of the transaction display packages ([0069] “Further, the risk report provided at 470 may be displayed or provided to a supervisor or administrator based upon the type or "risky transaction" identified”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize credit report displaying the transaction information (e.g. employee name, flagged risk rule, etc.) as in Cherry in the system executing the method of Dodson with the motivation of offering to mitigate risk by providing review and identification of transactions of the employees as taught by Cherry over that of Dodson.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Dodson in view of Johnsrud in further view of ELDER.
As per Claim 21, Dodson teaches a method for reducing human error when approving business expenses for reimbursement ([0015] “In general, a system is provided for managing expense reports and the reimbursement of expenses, such as business-related expenses incurred by an employee using a corporate credit card, for example. An employee uses a corporate credit card to make various business-related, reimbursable transactions”), the method comprising:
receiving transaction records for employee payment card transactions with merchants made via a payment network, each of said records needing to be approved by an expense manager utilizing a user device with a graphical user interface for approval purposes ([0045] “At step 104, card processing module 12 automatically identifies, from the transactions details 34 of the transactions made by the employee using corporate credit card 32a” wherein [0019] “Credit card processing module 12 may also be operable to receive and process transaction details 34 of credit card transactions made using various credit cards 32 from various merchants, points of sale, or any other entity that performs credit card transactions”);
identifying at least one of the received transaction records for a charged expense between an employee and a merchant, where the merchant is identified in the transaction records via a merchant identifier insufficient to clearly convey an identity of the merchant to the expense manager responsible for selectively approving the charged expense ([0056] “At step 126, image management module 18 may then create an index in image database 68 for the received receipt images 60 with the ID number determined from the identifier 58. The received receipt images 60 may be stored in image database 68 under the created index. The index may act as a link between the receipt images 60 stored in image database 68 and the expense report 44 maintained by expense report application 52 such that the receipt images 60 may be easily accessed and/or retrieved in connection with the expense report 44, such as for review by an expense manager or an accounting system, for example”);
…
sending the transaction display package for display at the graphical user interface of the user device so that upon being displayed via the graphical user interface to the expense manager responsible for approving a corresponding charged expense, the identified transaction records comprise the merchant brand image as the corresponding merchant identifier was identified as being insufficient to clearly convey the identity of the merchant to the expense manager ([0057] “Management module 20 may communicate with expense report application 52 to generate a display of the expense report 44, the display identifying each of the transactions included in the expense report 44, including one or more transactions made using the corporate credit card 32a and/or one or more other transactions. The display may include an interface for accessing the receipt images 60 of the receipts 62 indexed in image database 68 under the ID number associated with the expense report 44. For example, the display of the expense report 44 may include a hotlink button which may be clicked in order to retrieve the receipt images 60 associated with the expense report 44”).
Although Dodson teaches a expense report management system for transactions used by corporate cards, which provides a display including each transactions with details, along with a link to access receipt images, the prior art reference does not seem to explicitly disclose the specific details that the transaction details include merchant identification or merchant contents. However, Johnsrud discloses:
identifying at least one of the received transaction records for a charged expense between an employee and a merchant, where the merchant is identified in the transaction records via a merchant identifier insufficient to clearly convey an identity of the merchant to the expense manager responsible for selectively approving the charged expense (See Figure 7 – step 704, as disclosed [0075] “In some embodiments, the process may include block 704, where the system receives a transaction request comprising transaction information associated with a new transaction, wherein the transaction information comprises a payment end point associated with an alternate merchant name of the one or more alternate merchant names that is not the legal merchant name. In some embodiments, the system is operated by a financial institution or other entity capable of processing payment requests between a customer and a merchant”);
prior to presenting the transaction records on the user interface to the expense manager, a transaction data service, automatically obtaining, over a network, a merchant brand [name] associated with the merchant identifier (See Figure 7 – step 708, as disclosed [0079] “Once the payee name is matched with an alternate merchant name, the process 700 may progress to block 708, where the system determines, based on the block chain ledger, the legal name of the merchant associated with the transaction request”);
responsive to the obtaining, constructing a transaction display package correlating the merchant brand [name] to respective a respective record of the transaction records; and sending the transaction display package for display at the graphical user interface of the user device so that upon being displayed via the graphical user interface to the expense manager responsible for approving a corresponding charged expense, the identified transaction records comprise the merchant brand [name] as the corresponding merchant identifier was identified as being insufficient to clearly convey the identity of the merchant to the expense manager (See Figure 7 – steps 710 and 712, as disclosed [0081] “With the appropriate legal name of the merchant identified, the system, as shown in block 710, can adjust the payment end point of the transaction information to replace the identified alternate merchant name with the legal name of the merchant” wherein [0085] “In some embodiments, the system may request a confirmation from the payer of the transaction request. The system may establish an electronic communication channel with a computing device (e.g., a mobile device) of the payer, and prompt a user interface of the computing device to display a request for confirmation of the name change. Such a confirmation request may describe the change from the alternate merchant name currently associated with the payment end point to the legal name of the merchant”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize the system of determining the details regarding the transaction information, such as the merchant’s legal name, as in Johnsrud in the system executing the method of Dodson with the motivation of offering to [0001-0003] provide efficient and reliable mode of recording and viewing information utilizing blockchain system as taught by Johnsrud over that of Dodson.
Although Johnsrud teaches of mapping the merchant transaction to a merchant’s legal name, the prior art reference does not seem to explicitly disclose of mapping the transaction to a merchant brand image. However, ELDER discloses:
… automatically obtaining, over a network, a merchant brand image associated with the merchant identifier ([0012] “Furthermore, in some implementations, the merchant key may provide an index to enhancement data that provides more detailed and useful information about the merchant and/or the transaction, such as image data (e.g., a corporate logo)”);
… the identified transaction records comprise the merchant brand image as the corresponding merchant identifier was identified as being insufficient to clearly convey the identity of the merchant to the expense manager ([0027] “Additionally, or alternatively, the data cleansing platform may transform and/or otherwise reformat the information contained in the raw transaction records for the corresponding merchants (e.g., according to a standardized schema or data structure used for the lookup table) and/or associate the new and/or updated merchant keys with enhancement data based on one or more attributes associated with a corresponding merchant (e.g., a website, a logo, and/or an alternate business name such as a “doing business as” (DBA) trade name, among other examples)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize image data (e.g. logo) of the merchant as in ELDER in the system executing the method of Johnsrud with the motivation of offering to [0010-0011] improve data quality as taught by ELDER over that of Johnsrud.
As per Claim 22, Dodson teaches the method of claim 21, wherein the method is performed by the transaction data service of an expense management platform for tracking, reporting, and reimbursing employee business expenses, where the transaction data service manages and aggregates expense management platform related data from multiple remotely located, independent sources, including a transaction data resource, a merchant data mapping resource, and a user device ([0015] “In general, a system is provided for managing expense reports and the reimbursement of expenses, such as business-related expenses incurred by an employee using a corporate credit card, for example. An employee uses a corporate credit card to make various business-related, reimbursable transactions” wherein Figure 1 discloses the multiple data sources, including Image Management Module 18, Card Processing Module 12, Expense Report Management Module 16, Employee Terminal 56, and so forth).
Response to Arguments
Applicant's arguments, see pages 10 to 12, filed 05-March-2026, with respect to 35 U.S.C. 101 rejection have been fully considered but they are not persuasive. As discussed above under 35 U.S.C. 101 rejection, considering the claims without the additional elements (e.g. graphical user interface, user device, network, etc.), the method is merely a process of receiving information, obtaining a resource used to compare and identify information, generating information, and providing information for display, which is an abstract idea. The data recited by the claims (e.g. merchant data mapping resource, plurality of transaction display packages comprising a merchant identifying image and a merchant commercial brand name, merchant transactions, merchant transaction specific line items, etc.) are mere data or information used in the method of data analysis (e.g. receive, compare, store, transmit, or display information), which is still part of the abstract idea.
Additionally, mere instructions to display information on a GUI does not improve computer functionality, see MPEP 2106.05(a)(I) example that the courts have indicated may not be sufficient to show an improvement in computer-functionality: “Arranging transactional information on a graphical user interface in a manner that assists traders in processing information more quickly, Trading Technologies v. IBG LLC, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019)”. Mere instructions to implement the abstract idea on the generic computer system, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of integration into a practical application; see MPEP 2106.05(f). Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, transmit, compare, or display data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activities or mental process) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit).
As discussed above under 35 U.S.C. 101 rejection, the claims, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, the additional element of using a computer based system is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. The claims lack sufficient technical details to provide how these limitations may provide technological steps or technical details on how it is particularly implemented on a computer to improve its system or any of its underlying hardware or components (e.g. how it is performed on the system, how it could improve the system itself, how it could manipulate the system to function in a specific way other than its generic functionality, and/or how it could improve any of the underlying technology), but merely applies the generic computer system to perform its generic functionalities. Mere instructions to implement the abstract idea on the generic computer system, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of an inventive concept (aka “significantly more”). In view of the Specification, the judicial exception is not applied with or used by a particular machine. As held in Parker v. Flook, 437 U.S. 584, 590, 198 USPQ 193, 199 (1978) and Bancorp Services v. Sun Life, 687 F.3d 1266, 1276, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012), “the routine use of a computer to perform calculations cannot turn an otherwise ineligible mathematical formula or law of nature into patentable subject matter.” Therefore, the 35 U.S.C. 101 rejection is maintained.
Applicant's arguments, see pages 12 to 17, with respect to 35 U.S.C. 103 rejection have been fully considered but they are not persuasive.
Prior art reference Dodson discloses the claim limitation of generating a plurality of transaction display packages in the expense review session for the corporate payment card, as disclosed by [0056] which teaches the expense report comprising receipt images stored as an index in the image database (e.g. expense report is the expense review session for display comprising plurality of receipt images), wherein [0057] discloses of generating the display of the expense report with the identified transactions made with the corporate credit card, which includes the indexed receipt images. One of ordinary skilled in the art before the effective filing date of the invention would understand that an image of a “receipt”, which is a written or printed statement of the items or products that have been paid, would obviously include “merchant transaction specific line items”. The expense report includes “one or more transactions made using the corporate credit card”, along with the receipt images that can be accessed. Additionally, the claim limitation regarding the merchant transaction specific line items is also taught by Tavares. Therefore, for at least the recited disclosure, Dodson in view of Tavares teaches the claim limitations.
Prior art reference Johnsrud teaches of identifying a legal merchant name to be replaced on the transaction for display. Although the present application discloses [0053] “A brand name is the particular name of the merchant that is the name usually marketed for that merchant”, it merely states that the particular name “usually” marketed for that merchant, which does not explicitly disclose that any other name for the merchant cannot be the brand name, nor does it exclude any other name from being the brand name of the merchant. Additionally, the “alternate merchant name” disclosed by Johnsrud is read as the “merchant identification” associated with the merchant transaction, which is used to identify and replace with the “legal name” of the merchant (i.e. merchant brand name). Therefore, for at least the recited disclosure, Johnsrud teaches the claim limitations.
The office action has provided motivation to combine the references, which is reproduced below:
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize the system of determining the details regarding the transaction information, such as the merchant’s legal name, as in Johnsrud in the system executing the method of Dodson with the motivation of offering to [0001-0003] provide efficient and reliable mode of recording and viewing information utilizing blockchain system as taught by Johnsrud over that of Dodson.
Therefore, the 35 U.S.C. 103 rejection is maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
VanFleet (US 20190251589 A1) discloses [0018] “Cardholder Value Settlement—the gateway offers a settlement facility for publishers to credit earned discounts back to the registered debit card via the debit networks credit processing infrastructures” and [0024] “In certain other aspects, a transaction that matches a card linked offer comprises a transaction at a registered merchant using a registered debit card”;
Foote et al. (US 20210133875 A1) discloses [0066] “After the first hash is added to the blockchain, the blockchain may generate a transaction ID. The second data object can be updated to include the transaction ID, a logo, and a company description prior to saving the second data object to the company database”;
Deuskar et al. (US 11188976 B1) discloses [Col 11 Lines 36-51] “Each template 607 may identify a set of customizable elements for a site. Each customizable element may set the location and size for content that is to be presented for that customizable element. Each customizable element may also include parameters that limit the type of content that may be presented for that customizable element. For instance, a first customizable element may be used to present a customizable banner advertisement of a particular size, and a second customizable element may be used to present clothing items of a merchant. Each customizable element may correspond to an entry in the template that may be modified by custom content generator 611 to include a link to selected content and/or the data for selected content.”;
Kilat et al. (US 8243074 B1) discloses [Col 5 Lines 27-46] “As an even more specific example, if an analysis of the updated financial data associated with the user indicates an increase in amount of transactions associated with eating out or food, the visual representation of the user can be shown as gaining weight. As another example, if an analysis of the updated financial data associated with the user indicates a significant amount of transactions associated with a new retail store, the visual representation of the user can be changed to include a shopping bag having a logo or trademark associated with the new retail store on it”;
THIS ACTION IS MADE FINAL. 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 HENRY H JUNG whose telephone number is (571)270-5018. The examiner can normally be reached Mon - Fri 9:30 - 5:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine M Tran (Behncke) can be reached at (571) 272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HENRY H JUNG/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights