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 .
Claim(s) 1-18 are pending for examination. This action is FINAL. See MPEP § 706.07(b).
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.
Claim(s) 1-18 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
Step 1: claim(s) 1-18 are directed to a machine and/or process. Therefore, the claims are directed to statutory subject matter under Step 1 (Step 1: YES). See MPEP 2106.03.
Prong 1, Step 2A: claim 1, and similar claim(s) 18, taken as representative, recites at least the following limitations that recite an abstract idea:
The above limitations, under their broadest reasonable interpretation, fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas, enumerated in MPEP 2106.04(a)(2)(II), in that they recite "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. The broadest reasonable interpretation of these limitations for claim 1 includes receives a purchasing entity identifier and a user supplied transaction identifier, produce a transmission packet containing transaction data..., transmitting the data packet, and receiving the transaction data packet from [a system], thus, claim 1, falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas as they recite “commercial interactions" or "legal interactions" in the form of sales activities or behaviors.
Accordingly, these claims recite an abstract idea. (Prong 1, Step 2A: YES). The types of identified abstract ideas are considered together as a single abstract idea for analysis purposes.
Prong 2, Step 2A: Limitations that are not indicative of integration into a practical application include: (1) Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f)), (2) Adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)). Claim 1, and for similar claim(s) 18, recite systems comprising processor(s), medium(s), and code and are recited at a high-level of generality (i.e., as a generic computing environment that can receive data from devices and transmit data to systems/devices). Further the mobile device/point of sale are recited at a high-level of generality (i.e., generic data transfer between mobile device (i.e., including data input) and point of sale) and a point of sale/system are recited at a high-level of generality (i.e., generic data transfer between point of sale and system). Overall, the claims recite a system at a at a high-level of generality as a mobile computing device, point of sale, and system receives data, produces data, and transmits data for reception and receiving. These additional elements are described at a high level in Applicant’s specification without any meaningful detail about their structure or configuration. These elements in the steps 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 component and merely invoke such additional elements as a tool to perform the abstract idea. See MPEP 2106.05(f). Accordingly, these additional elements, even in combination, 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.
As such, under Prong 2 of Step 2A, when considered both individually and as a whole, the limitations of claim 1, and for similar claim(s) 18 are not indicative of integration into a practical application (Prong 2, Step 2A: NO). See MPEP 2106.04(d).
Since claim 1, and similar claim(s) 18 recites an abstract idea and fails to integrate the abstract idea into a practical application, claim 1, and similar claim(s) 18 is “directed to” an abstract idea under Step 2A (Step 2A: YES). See MPEP 2106.04(d).
Step 2B: The recitation of the additional elements is acknowledged, as identified above with respect to Prong 2 of Step 2A. These additional elements do not add significantly more to the abstract idea for the same reasons as addressed above with respect to Prong 2 of Step 2A.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of for claim 1, and for similar claim(s) 18, i.e., processor(s), medium(s), and code and concepts of a mobile communication device, a point of sale and system involving steps of receiving/producing/transmitting/receiving; thus, amounts to no more than mere instructions to apply the exception using a generic computer component and do not add anything that is not already present when they are considered individually or in combination. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Of note: MPEP 2106.05(d)(ii) highlights that receiving or transmitting data over a network and electronic recordkeeping are well‐understood, routine, and conventional functions and cover the performance of such additional elements. Further the mobile device/POS and the communication as noted is found to be routine, convention, and well-understood elements see Arthur et al. (US 2008/0208762 A1), Background - [0007], Owen et al. (US 2010/0049599 A1), Background [0003], and Jain et al. (US 2013/0260734 A1), Background, [0007]-[0008]. Therefore, under Step 2B, there are no meaningful limitations in claim 1, and similar claim(s) 18 that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself (Step 2B: NO). See MPEP 2106.05.
Accordingly, under the Subject Matter Eligibility test, claim 1, and similar claim(s) 18 is ineligible.
Regarding Claims 2-17, claims 2-17 further defines the abstract idea that is present in their respective independent claims and hence are abstract for at least the reasons presented above w/ respect to “Certain Methods of Organizing Human Activity” as the claims recite further concepts of "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. These dependent claim does not include any additional elements that integrate the abstract idea into a practical application; as such elements are recited at a high level of generality such that it amounts not more than mere instructions to apply the exception using a generic computer component (i.e., claim 5 – user interface, Claim 6 and 8 – interfaces). Even in combination, these additional elements do not integrate the abstract idea into a practical application and do no not amount to significantly more than the abstract idea itself. Thus, the aforementioned claims 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.
Claim(s) 1, 4-6, 9, 14, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smirnoff et al. (US 2003/0093373 A1) in view of Kurian (US 9,171,296 B1) and Farrar et al. (US 6,647,376 B1).
Regarding Claim 1, and, similarly, representative Claim 18;
Smirnoff discloses system including:
a merchant computing system including: at least one processor (FIG. 1 – Merchant device and [0027] - The merchant device 10 may be, for example, a Point Of Sale (POS) terminal, a Credit Authorization Terminal (CAT) device, or a server associated with a merchant); and a computer readable storage medium having computer readable program code embodied therewith and executable by the at least one processor (FIG. 1 – Merchant device and [0027] - The merchant device 10 may be, for example, a Point Of Sale (POS) terminal, a Credit Authorization Terminal (CAT) device, or a server associated with a merchant) the computer readable program code including:
computer readable program code that receives a purchasing entity identifier and a user supplied transaction identifier.... [at a merchants point of sale device] ([0032] - At 202, information associated with a customer's credit card transaction is received. For example, the invoice controller 800 may receive credit card transaction information from the credit card account device 20 (e.g., based on information that was originally received by the credit card account device 20 from the merchant device 10). The received information may include, for example, a credit card account identifier (e.g., a credit card number), a merchant identifier, an invoice date, one or more invoice amounts (e.g., a total invoice amount or itemized invoice amounts), and/or one or more item descriptions (e.g., describing goods or services that were purchased by the customer). The received information may also include a buyer identifier (e.g., when a number of different buyers are associated with a commercial credit card account) and [0033] - According to one embodiment, the information received by the invoice controller 800 also includes a project identifier. The project identifier may be, for example, a project name or code, a purchase order identifier, and/or job number that the customer associates with the transaction. The project identifier may be based on, for example, information provided from the customer to the merchant during the transaction (e.g., by verbally providing a project code to a POS terminal operator). According to one embodiment, the customer can subsequently provide (or adjust) the project identifier associated with a particular transaction (e.g., by accessing a Web site and entering an appropriate project name).
computer readable program code that produces a transaction data packet containing transaction data related to the purchase of goods or services, the purchasing entity identifier, and the user supplied transaction identifier ([0027] - The transaction system 100 includes a merchant device 10 in communication with a credit card account device 20 and [0028] - The credit card account device 20 and the invoice controller 800 may be any devices capable of performing the various functions described herein. For example, these devices may be Web-based servers and/or devices that communicate via proprietary networks. ... and [0032]-[0033] - For example, the invoice controller 800 may receive credit card transaction information from the credit card account device 20 (e.g., based on information that was originally received by the credit card account device 20 from the merchant device 10) (i.e., transaction data packet). The received information may include, for example, a credit card account identifier (e.g., a credit card number), a merchant identifier, an invoice date, one or more invoice amounts (e.g., a total invoice amount or itemized invoice amounts), and/or one or more item descriptions (e.g., describing goods or services that were purchased by the customer). The received information may also include a buyer identifier (e.g., when a number of different buyers are associated with a commercial credit card account). According to one embodiment, the information received by the invoice controller 800 also includes a project identifier (i.e., user supplied transaction identifier). The project identifier may be, for example, a project name or code, a purchase order identifier, and/or job number (i.e., user supplied transaction identifier) that the customer associates with the transaction. The project identifier may be based on, for example, information provided from the customer to the merchant during the transaction (e.g., by verbally providing a project code to a POS terminal operator). According to one embodiment, the customer can subsequently provide (or adjust) the project identifier associated with a particular transaction (e.g., by accessing a Web site and entering an appropriate project name); (emphasis added)
a transaction processing computing system including: at least one processor (FIG. 1 – Invoice Controller); and a computer readable storage medium having computer readable program code embodied therewith and executable by the at least one processor (FIG. 1 – Invoice Controller and [0027]-[0028] and [0032]-[0033] - For example, the invoice controller 800 may receive credit card transaction information from the credit card account device 20 (e.g., based on information that was originally received by the credit card account device 20 from the merchant device 10).... The project identifier may be based on, for example, information provided from the customer to the merchant during the transaction (e.g., by verbally providing a project code to a POS terminal operator)), the computer readable program code including:
computer readable program code that receives the transaction data packet from the merchant computing system (FIG. 1 and [0027]-[0028] and [0032]-[0033] - For example, the invoice controller 800 may receive credit card transaction information from the credit card account device 20 (e.g., based on information that was originally received by the credit card account device 20 from the merchant device 10).... The project identifier may be based on, for example, information provided from the customer to the merchant during the transaction (e.g., by verbally providing a project code to a POS terminal operator)).
While Smirnoff discloses concepts of the purchasing entity identifier and/or user supplied transaction identifier being is provided to the merchant computing system ([0032]-[0033]); Smirnoff fails to explicitly disclose computer readable program code that receives a purchasing entity identifier and a user supplied transaction identifier from a user's mobile communication device by one or more of: scanning of the mobile communication device, or via the mobile communication device effecting payment at a merchant's point of sale, wherein the user supplied transaction identifier is entered into the mobile communication device by a user; and computer readable program code that transmits the transaction data packet, wherein transmission of the transaction data packet is distinct to communication between the merchant computing system and a financial institution to effect an electronic funds transfer authorised by the user via the point of sale device;
However, in an analogous art, Kurian teaches computer readable program code that receives a purchasing entity identifier and a user supplied transaction identifier from a user's mobile communication device by one or more of: scanning of the mobile communication device, or via the mobile communication device effecting payment at a merchant's point of sale, wherein the user supplied transaction identifier is entered into the mobile communication device by a user (col. 3, lines 47-54 - In response, the process flow includes generating a virtual check comprising a checking account number, a banking account number, and a date, as shown in block 104. In response to generating a virtual check, the process flow includes initiating display of the virtual check on a display of the mobile device, as shown in block 106. The system may then be configured to receive input from the user corresponding to at least one of a plurality of check fields, as shown in block 108 and col. 4, lines 1-8 - In one aspect, the one or more check fields include at least one of a personalization field including a name field (i.e., purchasing entity identifier) and an address field, date field, a check number, a memo field (i.e., user supplied transaction identifier), and a signature field. In another aspect, the virtual check may include bank identification numbers such as a checking account number, a routing number, a user number, and a check number. This information may be used by a bank to identify the transaction and resolve payment issues and col. 4, lines 9-25 - In some embodiments, the system may be configured to enable the user to receive the virtual check and utilize the virtual check to execute a financial transaction... In some other embodiments, the virtual check may be transmitted wirelessly to the point-of-sale terminal of the merchant. In this regard, the system may be configured to enable the merchant to receive the virtual check as a valid payment vehicle and process the received virtual check to complete the transaction. For example, the virtual check may be transmitted using Near Field Communication (NFC), such as by the user “bumping”/“tapping” the send and/or receive the virtual check and/or other information.).
A person of ordinary skill in the art would have the technical skills to make the mere substitution and the outcome would be predictable. Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself. Mainly, substituting one for the other achieves a predictable result (e.g., the means to provide information to merchant computing) because Kurian uses computer readable program code that receives a purchasing entity identifier and a user supplied transaction identifier from a user's mobile communication device by one or more of: scanning of the mobile communication device, or via the mobile communication device effecting payment at a merchant's point of sale, wherein the user supplied transaction identifier is entered into the mobile communication device in the same role as Smirnoff’s use of credit the credit card and verbally providing the user supplied transaction identifier. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute teachings of Kurian for the means to provide information to merchant computing within Smirnoff to arrive at the claimed invention because such a step is known and results of the substitution would have been predictable.
Further, in an analogous art, Farrar teaches computer readable program code that transmits the transaction data packet, wherein transmission of the transaction data packet is distinct to communication between the merchant computing system and a financial institution to effect an electronic funds transfer authorized by the user via the point of sale device and [a transaction processing computing system including: at least one processor; and a computer readable storage medium having computer readable program code embodied therewith and executable by the at least one processor, the computer readable program code including: computer readable program code that receives the transaction data packet from the merchant computing system] (col. 14, lines 18-58 - To initiate payment in accordance with the seventh embodiment, the customer hands the check to the merchant in payment for goods or services. The merchant then swipes the check through the MICR reader to scan in the MICR data printed thereon. The scanned data is forwarded to the merchant processor at step S800, preferably together with transaction data, such as the check amount.... The MICR and transaction information is forwarded in the form of an electronic message to the payor bank through the EFT switch. First, at step S803, the message, which includes an account inquiry, is forwarded to the EFT switch together with the transaction and MICR information. The EFT switch, at step S804, routes this information to the participating payor bank. The EFT switch communicates with the bank's front end computer, and the bank preferably is equipped with software that allows the message from the EFT switch to be processed, directly or indirectly, by the bank's DDA account computer).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Farrar to the merchant system of Smirnoff in view of Kurian to include computer readable program code that transmits the transaction data packet, wherein transmission of the transaction data packet is distinct to communication between the merchant computing system and a financial institution to effect an electronic funds transfer authorised by the user via the point of sale device and [a transaction processing computing system including: at least one processor ;and a computer readable storage medium having computer readable program code embodied therewith and executable by the at least one processor, the computer readable program code including: computer readable program code that receives the transaction data packet from the merchant computing system]
One would have been motivated to combine the teachings of Farrar to Smirnoff in view of Kurian to do so as it allows merchants to continue to accept customers [payment]with the assurance [payment is] valid ... having sufficient funds to cover the transaction (Farrar, col. 3, lines 44-49).
Regarding Claim 4;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff further teaches wherein the transaction includes a plurality of line items ([0032]), and a user supplied transaction identifier is provided for at least one of: each line item, one or more subsets of line items, and an entire set of line items ([0032] and [0033] – Project Identifier and/or Job Number).
Regarding Claim 5;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff further discloses wherein the transaction processing computing system includes computer readable program code that provides a user interface by which a user is enabled to access and review accounting information associated with received transaction data packet ([0034]-[0035] and [0036] - The information transmitted through the communication network 50 may be used, for example, to display information to the customer via a Web site... and [0054]), and gain access to actions provided by the transaction processing computing system ([0043] and [0047] and [0054]-[0056] - The account display 44 may also let the customer adjust the account information (i.e., via an "update account" icon), view invoice information (i.e., via an "invoices" icon), and/or arrange to provide payment (i.e., via a "payment" icon)).
Regarding Claim 6;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff further discloses wherein the transaction processing computing system includes computer readable program code that provides a payment interface, for one or more of: payment of invoices, expense reimbursement, and payment of tax ([0043] and [0047] and [0054]-[0056] - The account display 44 may also let the customer adjust the account information (i.e., via an "update account" icon), view invoice information (i.e., via an "invoices" icon), and/or arrange to provide payment (i.e., via a "payment" icon).)
Regarding Claim 9;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff further discloses wherein the transaction processing computing system includes: computer readable program code that identifies a transaction relating to a purchase on account which has yet to be paid (FIG. 5 and [0057] - The invoices display 46 includes a number of different invoices and, for each invoice, provides an invoice date, an invoice number, a Purchase Order (PO) or job identifier (i.e., a project identifier), a merchant identifier, an invoice balance, and an invoice status. The invoice status may indicate, for example, that an invoice is "open" (e.g., not paid) or "paid."); computer readable program code that facilitates review of accounting information relating to the transaction ([0056] - The account display 44 may also let the customer adjust the account information (i.e., via an "update account" icon), view invoice information (i.e., via an "invoices" icon), and/or arrange to provide payment (i.e., via a "payment" icon and [0058]3); and computer readable program code that facilitates payment of the purchase on account ([0056] - The account display 44 may also let the customer adjust the account information (i.e., via an "update account" icon), view invoice information (i.e., via an "invoices" icon), and/or arrange to provide payment (i.e., via a "payment" icon)).
Regarding Claim 14;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff further discloses wherein the transaction processing computing system includes computer readable program code that produces a customer consolidated invoice, including transaction data from a plurality of transactions relating to a customer ([0081] - According to another embodiment, the invoice database 1000 stores a project identifier on an item-by-item basis. That is, a single transaction may be associated with a number of different project identifiers. According to another embodiment, a single transaction may be associated with a number of different invoices. Similarly, a single invoice may be associated with a number of different transactions (e.g., a single daily invoice may be created for every transaction having a projection identifier of "Smith")).
Claims 2 and 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smirnoff et al. (US 2003/0093373 A1) in view of Kurian (US 9,171,296 B1) and Farrar et al. (US 6,647,376 B1) and further in view in view of Peterson et al. (US 2001/0011232 A1).
Regarding Claim 2;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff further discloses wherein the merchant device is configured to receive [transaction information] ([0032])
Smirnoff in view of Kurian and Farrar to explicitly disclose wherein the merchant device is configured to receive purchase justification for entry with the transaction.
However, in an analogous art, Peterson teaches wherein the merchant device is configured to receive purchase justification for entry with the transaction (Peterson, [0133]-[0134] - The Menu Options area lets the user choose the vendor's application that the user may wish to run. The menu options may include: "Place a New Order", "Request a New Quote", "Make a New Requisition", "Get Order Status", "Get Quote Status", and "Get Requisition Status" and [0151] - In a step 342, the user can enter comments for the line item that will be generated by selecting the item, if the user wishes. The user then clicks on the "Add To Order" button in a step 346. The line item will then be created).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Peterson to the transaction information “entry” at the merchant computing system of Smirnoff and Kurian and Farrar to include wherein the merchant device is configured to receive purchase justification for entry with the transaction.
One would have been motivated to combine the teachings of Peterson to Smirnoff and Kurian and Farrar to do so as it provides “parties” to enter into an agreement (i.e., a contract) which will govern or regulate the terms of interaction, including sales, between the parties to the agreement (Peterson, [0128]).
Regarding Claim 3;
Smirnoff in view of Kurian and Farrar and Peterson disclose the system to Claim 2.
Smirnoff further discloses wherein the transaction includes a plurality of line items, ([0032])
Peterson further teaches wherein the transaction includes a plurality of line items, and a purchase justification is provided for at least one of: each line item, one or more subsets of line items, and an entire set of line items (Peterson, [0133]-[0134] - The Menu Options area lets the user choose the vendor's application that the user may wish to run. The menu options may include: "Place a New Order", "Request a New Quote", "Make a New Requisition", "Get Order Status", "Get Quote Status", and "Get Requisition Status" and [0151] - In a step 342, the user can enter comments for the line item that will be generated by selecting the item, if the user wishes. The user then clicks on the "Add To Order" button in a step 346. The line item will then be created).
Similar rationale and motivation is noted for the combination of Peterson to Smirnoff in view of Kurian and Farrar and Peterson, as per Claim 5 noted above.
Claims 7 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smirnoff et al. (US 2003/0093373 A1) in view of Kurian (US 9,171,296 B1) and Farrar et al. (US 6,647,376 B1) and further in view of Fitzpatrick (US 2006/0206506 A1).
Regarding Claim 7;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff further discloses [a] the user supplied transaction identifier ([0032] and [0033] – Project Identifier and/or Job Number).
Smirnoff in view of Kurian and Farrar fail to explicitly disclose wherein the transaction processing computing system includes computer readable program code that identifies a transaction associated with a transaction data packet as being eligible for reimbursement to an individual based at least in part on the ... supplied transaction identifier.
However, in an analogous art, Fitzpatrick teaches wherein the transaction processing computing system includes computer readable program code that identifies a transaction associated with a transaction data packet as being eligible for reimbursement to an individual based at least in part on the ... supplied transaction identifier (Fitzpatrick, [0011]-[0012] - ... the invention provides a payment card company automation apparatus including a receiver to receive from a merchant a data collection of purchased product(s) in a single transaction with a payment card customer, each of the product(s) being identified with an expenditure identifier and an event code identifier and [0029] - The data storage unit 212 may also include information that will identify the employee cardholder to certain payroll related functionality for reimbursement/repayment purposes, as well as proper department ledger recording classification and accounting treatment and [0034] - As part of the checkout process, a cardholder will respond to a point-of sale terminal inquiry regarding the nature of the transaction--business or personal. Thus all line items associated with the transaction are designated business or personal by associating a database identifier to all of the transaction line items.).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Fitzpatrick to transaction processing system of Smirnoff in view of Kurian and Farrar to include wherein the transaction processing computing system includes computer readable program code that identifies a transaction associated with a transaction data packet as being eligible for reimbursement to an individual based at least in part on the ... supplied transaction identifier.
One would have been motivated to combine the teachings of Fitzpatrick to Smirnoff in view of Kurian and Farrar to do so as it provides for an automated expenditure accounting management system that provides a plurality of identifiers for processing, reporting, recording and reimbursing/collecting of expenditure spending related to each line item of transaction data comprising multiple line items of activity associated with a cardholder's purchase of products (goods and/or services) (Fitzpatrick, [0003]).
Regarding Claim 8;
Smirnoff in view of Kurian and Farrar and Fitzpatrick discloses the system to Claim 7.
Smirnoff further teaches wherein the transaction processing computing system includes computer readable program code that automatically populates a payment interface... (FIG. 6).
Fitzpatrick further teaches wherein the transaction processing computing system includes computer readable program code that automatically populates a payment interface for reimbursement based in part on the purchasing entity identifier (Fitzpatrick, [0035] - Step 510 also depicts the transaction data being generated, transmitted and stored on the payment card company subsystem as a result of the transaction between the cardholder and the merchant. The transaction data may include one line for each merchant product purchased with its corresponding associated expenditure identifier or one line for each expenditure identifier associated with the transaction, plus a database identifier, the cardholder account number, purchase price of the product or the expenditure identifier subtotal amount, and an amount representing a pro-rata allocation of any general transaction fees associated to the product or expenditure identifier purchased and [0037] - At step 530 of FIGS. 2 and 3, the payment card company provides a authorized cardholder access to the stored transaction data such as through one or more client user terminals 320 as shown in more detail in FIG. 7. Typically, this step is performed using a public communications network such as the internet. The authorized cardholder logs on the payment card company subsystem to gain secure access to the stored transaction data... It is also at step 530 that the cardholder reviews all transaction data, merchant transmitted transaction data and cardholder reimbursable mileage and currency transaction data, to associate an event code identifier with each transaction data line item, as well as to input any other data required in order to process an expense report; such as cost allocation identifiers with corresponding amounts and/or disclosure identifiers for any transaction data line items).
Similar rationale and motivation is noted for the combination of Fitzpatrick to Smirnoff in view of Kurian and Farrar, as per Claim 10 noted above.
Claims 10 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smirnoff et al. (US 2003/0093373 A1) in view of Kurian (US 9,171,296 B1) and Farrar et al. (US 6,647,376 B1) and further in view of Gannon (US 2014/0032437 A1).
Regarding Claim 10;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff teaches concepts of a... end of month statement ([0002])
Smirnoff in view of Kurian and Farrar fail to explicitly disclose wherein the transaction processing computing system includes: computer readable program code that receives a “merchant’s”... statement; computer readable program code that reconciles invoices from received transaction data packets with the received ... statement.
However, in an analogous art, Gannon teaches wherein the transaction processing computing system includes: computer readable program code that receives a “merchant’s”... statement ([0013] and [0144] – Table 1: - Inbound Freight Statements); computer readable program code that reconciles invoices from received transaction data packets with the received ... statement ([0013] - comparing the invoice to the freight statement; determining a dispute of the values associated with the invoice to the values associated with the freight statement; transmitting an EDI dispute message; and receiving an EDI dispute response message and [0144] – Table 1: - Inbound Invoices and Inbound Friend Statements and Outbound Dispute).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Gannon to the transaction processing computing system of Smirnoff in view of Kurian and Farrar to include wherein the transaction processing computing system includes: computer readable program code that receives a “merchant’s”... statement; computer readable program code that reconciles invoices from received transaction data packets with the received ... statement.
One would have been motivated to combine the teachings of Gannon to Smirnoff in view of Kurian and Farrar to do so as it provides for automated data processing (Gannon, [0002] and [0012]).
Regarding Claim 11;
Smirnoff and Kurian and Farrar Gannon disclose the system to Claim 10.
Gannon further discloses wherein the transaction processing computing system includes computer readable program code that identifies discrepancies between the statement and information associated with the individual invoices ([0013] - comparing the invoice to the freight statement; determining a dispute of the values associated with the invoice to the values associated with the freight statement; transmitting an EDI dispute message; and receiving an EDI dispute response message and [0144] – Table 1: - Inbound Invoices and Inbound Friend Statements and Outbound Dispute).
Similar rationale and motivation is noted for the combination of Gannon to Smirnoff in view of Kurian and Farrar and Gannon, as per Claim 13 noted above.
Claims 12 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smirnoff et al. (US 2003/0093373 A1) in view of Kurian (US 9,171,296 B1) and Farrar et al. (US 6,647,376 B1) and further in view of Guzman et al. (US 2017/0169292 A1).
Regarding Claim 12;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff in view of Kurian and Farrar fail to explicitly disclose wherein the transaction processing computing system includes computer readable program code that determines a tax component associated with at least one transaction recorded with the transaction processing computing system.
However, in an analogous art, Guzman teaches wherein the transaction processing computing system includes computer readable program code that determines a tax component associated with at least one transaction recorded with the transaction processing computing system (Guzman, [0006] and [0019] - The various disclosed embodiments include a method and system for automatically verifying requests based on electronic documents. In an embodiment, a dataset is created based on a first electronic document indicating information related to a request. The request may be for a reclaim of value-added taxes (VATs) paid during a transaction and [0023] - The data stored by the enterprise system 130 may include, but is not limited to, electronic documents (e.g., an image file showing, for example, a scan of an invoice, a text file, a spreadsheet file, etc.). Each electronic document may show, e.g., an invoice, a tax receipt, a purchase number record, a VAT reclaim request, and the like. Data included in each electronic document may be structured, semi-structured, unstructured, or a combination thereof. The structured or semi-structured data may be in a format that is not recognized by the request verifier 120 and, therefore, may be treated as unstructured data and [0059]).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Guzman to the transaction processing computing system of Smirnoff in view of Kurian and Farrar to include wherein the transaction processing computing system includes computer readable program code that determines a tax component associated with at least one transaction recorded with the transaction processing computing system.
One would have been motivated to combine the teachings of Guzman to Smirnoff in view of Kurian and Farrar to do so as it provides for verifying requests based on contents of electronic documents (Guzman, [0002]).
Regarding Claim 13;
Smirnoff in view of Kurian and Farrar and Guzman disclose the system to Claim 12.
Guzman further teaches wherein the transaction processing computing system includes computer readable program code that communicates with a taxation agency system to complete an action associated with the determined tax component (Guzman, [0006] – ...reclaim request... and [0019] - The various disclosed embodiments include a method and system for automatically verifying requests based on electronic documents. In an embodiment, a dataset is created based on a first electronic document indicating information related to a request. The request may be for a reclaim of value-added taxes (VATs) paid during a transaction and [0023] - The data stored by the enterprise system 130 may include, but is not limited to, electronic documents (e.g., an image file showing, for example, a scan of an invoice, a text file, a spreadsheet file, etc.). Each electronic document may show, e.g., an invoice, a tax receipt, a purchase number record, a VAT reclaim request, and the like. Data included in each electronic document may be structured, semi-structured, unstructured, or a combination thereof. The structured or semi-structured data may be in a format that is not recognized by the request verifier 120 and, therefore, may be treated as unstructured data and [0059]).
Similar rationale and motivation is noted for the combination of Guzman to Smirnoff in view of Kurian and Farrar and Guzman, as per Claim 15 noted above.
Claims 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smirnoff et al. (US 2003/0093373 A1) in view of Kurian (US 9,171,296 B1) and Farrar et al. (US 6,647,376 B1) and further in view of Slavin et al. (US 7,805,365 B1).
Regarding Claim 15;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff in view of Kurian and Farrar fail to explicitly disclose wherein the transaction processing computing system includes computer readable program code that produces a merchant consolidated invoice, including transaction data from a plurality of transactions from related merchants.
However, in an analogous art, Slavin teaches wherein the transaction processing computing system includes computer readable program code that produces a merchant consolidated invoice, including transaction data from a plurality of transactions from related merchants (Slavin, Abstract - In general, one or more orders are received from a buyer in which each of the orders corresponds to at least one seller subsidiary. The orders are consolidated into a consolidated invoice. The consolidated invoices are then made available to the buyer. An indication is received from the buyer as to which of the orders a payment is being approved. The payment, once received, is allocated to a corresponding at least one seller subsidiary for which the payment has been made).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Slavin to the transaction processing computing system of Smirnoff in view of Kurian and Farrar to include wherein the transaction processing computing system includes computer readable program code that produces a merchant consolidated invoice, including transaction data from a plurality of transactions from related merchants
One would have been motivated to combine the teachings of Slavin to Smirnoff in view of Kurian and Farrar to do so as it allows the seller to maximize profits by booking and fulfilling orders and obtaining payment (Slavin, col. 3, lines 21-37).
Claims 16 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable Smirnoff et al. (US 2003/0093373 A1) in view of Kurian (US 9,171,296 B1) and Farrar et al. (US 6,647,376 B1) and further in view of Rucker et al. (US 2010/0153241 A1).
Regarding Claim 16;
Smirnoff in view of Kurian and Farrar disclose the system to Claim 1.
Smirnoff further teaches data associated with received transaction data packets.../merchant from which the transaction data packets are received ([0032]-[0033])
Smirnoff in view of Kurian and Farrar fails to explicitly disclose wherein the transaction processing computing system includes computer readable program code that compares data ... received .... against at least one purchase order issued to the one or more merchants ....
However, in an analogous art, Rucker teaches wherein the transaction processing computing system includes computer readable program code that compares data ... received .... against at least one purchase order issued to the one or more merchants ... (Rucker, [0017] - The present disclosure relates generally to reconciling purchase orders ("PO's") and invoices and/or billing statements in an enterprise software environment. A PO is a commercial document issued by a buyer to a seller, indicating the type, quantities and agreed prices for products or services that the seller will provide to the buyer. PO's also usually specify additional conditions such as terms of payment, terms for liability and freight responsibility, and required delivery date. In the course of the accounts payable process for a business, PO's are matched with transactions including invoices, purchasing card statements and packing slips before the transactions are paid, this process may also be referred to as reconciliation.).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Rucker to transaction processing computing system of Smirnoff in view of Kurian and Farrar to include wherein the transaction processing computing system includes computer readable program code that compares data ... received .... against at least one purchase order issued to the one or more merchants ....
One would have been motivated to combine the teachings of Rucker to Smirnoff in view of Kurian and Farrar to do so as it for automatic reconciliation of transaction data (Rucker, [0005])
Regarding Claim 17;
Smirnoff in view of Kurian and Farrar and Rucker discloses the system to Claim 16.
Smirnoff further teaches ... at least one user supplied transaction identifier ([0033])
Smirnoff in view of Kurian and Farrar and Rucker fail to explicitly disclose wherein the transaction processing computing system includes {2064201;}4computer readable program code that issues the at least one purchase order..., and optionally at least one purchase justification.
Rucker further teaches wherein the transaction processing computing system includes {2064201;}4computer readable program code that issues the at least one purchase order, including at least [data] (i.e., PO number), and optionally at least one purchase justification (Rucker, [0017] - PO is a commercial document issued by a buyer to a seller 3and [0039] – conditions (i.e., can represent a form of purchase justification)).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Rucker to transaction processing computing system/user supplied transaction identifier of Smirnoff in view of Kurian and Farrar and Rucker to include wherein the transaction processing computing system includes {2064201;}4computer readable program code that issues the at least one purchase order, including at least [data], and optionally at least one purchase justification.
One would have been motivated to combine the teachings of Rucker to Smirnoff in view of Kurian and Farrar to do so as it for automatic reconciliation of transaction data (Rucker, [0005]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kelly et al. (US 2005/0177494 A1) discusses a system and method is provided that enables the processing of electronic payment transactions. The system and method includes a data transaction provider which is configured for receiving a request to process electronic payment transactions, funding the transactions and generating reports respecting such transactions. In accordance with an embodiment of the invention, payment to a merchant is effectuated by funding transactions that transpired during a predetermined period, regardless of whether confirmation that the funds have been transferred by the consumer is received (Abstract).
This is a continuation of applicant's earlier Application No. 16/626,664. All claims are identical to, patentably indistinct from, or have unity of in