DETAILED ACTION
Status of the Claims
1. This action is in reply to the Request for Reconsideration dated 02/05/2026
2. The claims were preliminarily amended on April 18, 2023 cancelling Claims 1-27 and adding Claims 28-47.
3. Claims 28, 31-35, 38-41 and 44-47 are currently pending and have been examined.
4. Claims 1-27, 29-30, 36-37 and 42-43 have been cancelled.
5. Claims 28, 31, 35, 38, 41 and 44 are currently amended.
Notice of Pre-AIA or AIA Status
6. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
7. Claims 35 and 41 are objected to because of the following informalities:
- As amended, Claim 35 appears to the repeat the same limitation in current limitations three and four of the claim. This appears to be a typographical oversight.
- As amended, Claim 41 appears to repeat the same limitation in the first and second limitations of the claim. This appears to be a typographical oversight.
For purposes of examination, Examiner assumes that Applicant did not intend to repeat the limitation and will interpret the claims as reciting the limitation only once in each claim.
Appropriate correction is required.
Claim Interpretation – Broadest Reasonable Interpretation
8. In determining patentability of an invention over the prior art, all claim limitations have been considered and interpreted using the “broadest reasonable interpretation consistent with the specification during the examination of a patent application since the applicant may then amend his claims.” See In re Prater and Wei, 162 USPQ 541, 550 (CCPA 1969); MPEP § 2111. Applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. See In re Prater, 162 USPQ 541, 550-51 (CCPA 1969); MPEP § 2111. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 26 USPQ2d 1057 (Fed. Cir. 1993). See also MPEP 2173.05(q) All claim limitations have been considered. Additionally, all words in the claims have been considered in judging the patentability of the claims against the prior art. See MPEP 2143.03.
Claim limitations that contain statement(s) such as “if, may, might, can, could”, are treated as containing optional language. As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted.
Claim limitations that contain statement(s) such as “wherein, whereby”, that fail to further define the steps or acts to be performed in method claims or the discrete physical structure required of system claims.
Similarly, a method step exercised or triggered upon the satisfaction of a condition, where there remains the possibility that the condition was not satisfied under the broadest reasonable interpretation, is an optional claim limitation. see MPEP § 2103(I)(C); In re Johnson, 77 USPQ2d 1788 (Fed Cir 2006). As the Applicant does not address what happens should the optional claim limitations fail, Examiner assumes that nothing happens (i.e., the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
The subject matter of a properly construed claim is defined by the terms that limit its scope. It is this subject matter that must be examined.
As a general matter, grammar and the plain meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. see MPEP §2013(I)(C). Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. see MPEP §2013(I)(C).
Claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009). See MPEP 2111.04, 2143.03.
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art. In other words, if the prior art structure is capable of performing the intended use, then it meets the claim.
The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Statements of intended use or field of use, including statements of purpose or intended use in the preamble (MPEP 2111.02);
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby” (MPEP 2111.04)
Contingent limitations (MPEP 2111.04)
Printed matter (MPEP 2111.05) and
Functional language associated with a claim term (MPEP 2181)
Examiner notes that during examination, “claims … are to be given their broadest reasonable interpretation consistent with the specification, and … claim language should be read in light of the specification as it would be interpreted by one of ordinary skill in the art.” See In re Bond, 15 USPQ 1566, 1568 (Fed. Cir. 1990), citing In re Sneed, 218 USPQ 385, 388 (Fed. Cir. 1983). However, "in examining the specification for proper context, [the examiner] will not at any time import limitations from the specification into the claims". See CollegeNet, Inc. v. ApplyYourself, Inc., 75 USPQ2d 1733, 1738 (Fed. Cir. 2005). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984), citing In re Prater, 162 USPQ 541, 550 (CCPA 1969).
The preamble of instant claim 28 recites "[a] computer implemented method for executing electronic transactions with dynamically loadable transaction processing modules, the method comprising:”
The preamble of instant claim 35 recites “[a] system for executing electronic transactions with dynamically loadable transaction processing modules, the system comprising:”
The preamble of instant claim 41 recites “[a] non-transitory computer-readable medium storing instructions for executing electronic transactions with dynamically loadable transaction processing modules, the instructions, when executed by one or more processors, causing the one or more processors to perform operations comprising:”
In general, a preamble limits the invention if it recites essential structure or steps, or if it is "necessary to give life, meaning, and vitality" to the claims. Pitney Bowes, Inc. v. Hewlett-Packard Co. 51 USPQ2d 1161 (Fed. Cir. 1999), Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002). Conversely, where a patentee defines a structurally complete invention in the claim body and uses the preamble only to state a purpose or an intended use for the invention, the preamble is not a claim limitation given patentable weight. Rowe v. Dror, 42 USPQ2d 1550 (Fed. Cir. 1997); Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002); Bell Communications Research, Inc. v. Vitalink Communications Corp., 34 USPQ2d 1816 (Fed. Cir. 1995) If a prior art structure is capable of performing the intended use as recited in the preamble, then it meets the claim. See, e.g., In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed. Cir. 1997) See MPEP 2111.02
In the instant case, “for executing electronic transactions with dynamically loadable transaction processing modules” as recited in the preamble of Claims 28, 35 and 41 only states a purpose and/or the intended use of the invention and accordingly is not being assigned any patentable weight. Further, the following italicized limitations are further not limiting and are not being assigned any patentable weight.
For purposes of this examination, the following terms are being defined as broadly represented in the Applicant’s specification.
The term “transaction management controller” is defined as follows:
“The transaction management controller 102 can be embodied as any type of computing device or server or capable of processing, communicating, storing, maintaining, and transferring data. For example, the transaction management controller 102 can be embodied as a server, a microcomputer, a minicomputer, a mainframe, a desktop computer, a laptop computer, a mobile computing device, a handheld computer, a smart phone, a tablet computer, a personal digital assistant, a telephony device, a custom chip, an embedded processing device, or other computing device and/or suitable programmable device. In some embodiments, the transaction management controller 102 can be embodied as a computing device integrated with other systems or subsystems. In the illustrative embodiment of FIG. 1, the transaction management controller 102 includes a processor 104, a system bus 106, a memory 108, a data storage 110, communication circuitry 112, and one or more peripheral devices 114. Of course, the transaction management controller 102 can include other or additional components, such as those commonly found in a server and/or computer (e.g., various input/output devices), in other embodiments. Additionally, in some embodiments, one or more of the illustrative components can be incorporated in, or otherwise from a portion of, another component. For example, the memory 108, or portions thereof, can be incorporated in the processor 104 in some embodiments. Furthermore, it should be appreciated that the transaction management controller 102 can include other components, sub-components, and devices commonly found in a computer and/or computing device, which are not illustrated in FIG. 1 for clarity of the description.” (See Applicant Specification paragraph 22)
Thus, Examiner is interpreting the term “transaction management controller” as being any type of computing device or server or capable of processing, communicating, storing, maintaining and transferring data, i.e., any computing or processing device.
The term “business management engine” is defined as follows:
“The business management engine 120 can be embodied as any type of computing device capable of performing the functions described herein. As such, the business management engine 120 can include devices and structures commonly found in computing devices such as processors, memory devices, communication circuitry, and data storages, which are not shown in FIG. 1 for clarity of the description. The business management engine 120 can be configured to perform certain business-related functions, such as, without limitation, sales tabulation, inventory management, scheduling, accounting processes, payroll, and the like. As it to be appreciated, the particular business-related functions facilitated by a business management engine may depend on the needs of the particular business (e.g., merchant) utilizing the business management engine. In this regard, a business management engine of a salon may provide different business-related functions than that of a specialty retailer, for example. In some embodiments, the business management engine 120 is configured to initiate payment transactions. As discussed in more detail below, the business management engine 120 is configured to communicate with the transaction management controller 102 to facilitate such payment transactions. For example, in some embodiments, the business management engine 120 is configured to transmit a payment request to the transaction management controller 102. The payment request can be embodied as an HTTP message that includes the amount of the transaction. Additionally, the business management engine 120 can be configured to receive a payment authorization response message from the transaction management controller 102. As discussed in more detail below, the business management engine can be communicatively isolated from the POI device 130 (e.g., not in direct communication with the POI device 130). As such, instead of being directly connected to the POI device 130, the business management engine 120 is communicatively coupled to the transaction management controller 102, which manages communications with the POI device 130. It should be appreciated that in doing so, the complexity of configuring (e.g., coding, certification, initialization, etc.) of that business management engine 120 is reduced.” (See Applicant Specification paragraph 33)
Thus, Examiner is interpreting the term “business management engine” as being any type of computing device capable of performing the functions described in the claims.
The point of interaction (POI) device is disclosed as follows:
“The point of interaction (POI) device 130 can be embodied as any type of computing or payment device capable of performing the functions described herein. For example, in the illustrative embodiment, the POI device 130 can be embodied as a card reader or a PIN pad configured to facilitate receipt of a payment card for a payment transaction (e.g., a credit or debit transaction). The POI device 130 can include devices and structures commonly found in computing and payment devices such as processors, memory devices, communication circuitry, and data storages, which are not shown in FIG. 1 for clarity of the description. For example, in some embodiments, the POI device 130 can include payment hardware and functionality configured for receiving traditional payment cards containing magnetic stripes (e.g., magstripes, swipe cards, etc.). The POI device 130 can also include payment hardware and functionality configured for receiving payment cards via Near Field Communication (NFC) technologies, BLUETOOTH communication technologies, and other contactless and/or short range wireless communication technologies. Additionally, or alternatively, in some embodiments, the POI device 130 can include integrated circuit payment hardware and functionality configured for receiving a EUROPAY, MASTERCARD, and VISA (EMV) payment card or other smartcard or chip-based card. Of course, the POI device 130 can include any other type of payment hardware and functionality for receiving a payment or vehicle. (See Applicant Specification paragraph 35)
For purposes of examination, Examiner is interpreting a POI as broadly disclosed to be any type of computing or payment device capable of performing the functions described in the claims.
Applicant, via the instant amendments, has recited “payment vehicle type” and “payment vehicle type-specific transaction processing module” in numerous places in the amended claims.
As to the term “payment vehicle type”, Applicant’s specification notes the following germane recitations:
“For simplicity, the description that follows will be provided by reference to a “payment vehicle” or a “payment card”, which generally refers to any type of financial alternative to currency. As is to be clear to those skilled in the art, no aspect of the present disclosure is specifically limited to a specific type of payment vehicle or payment card. Therefore, it is intended that the following description encompasses the use of the present disclosure with many other forms of financial alternatives to currency, including credit cards, debit cards, smart cards, single-use cards, prepaid cards, electronic currency (such as might be provided through a cellular telephone or personal digital assistant) and the like. Payment vehicles or payment card can be traditional plastic transaction cards, titanium-containing, or other metal-containing, transaction cards, clear and/or translucent transaction cards, foldable or otherwise unconventionally-sized transaction cards, radio-frequency enabled transaction cards, or other types of transaction cards, such as credit, charge, debit, prepaid or stored-value cards, electronic benefit transfer cards, or any other like financial transaction instrument.” (See Applicant Specification paragraph 16)
“…The requested payment transaction type corresponds to the payment card or payment vehicle that is to be used for the payment transaction.” (See Applicant Specification paragraph 17)
“In response to receiving the requested payment transaction type from the POI device 130, the transaction management controller 102 dynamically loads or initializes a transaction processing module that corresponds to the received payment transaction type. The transaction processing module includes transaction processing parameters, rules, and/or instructions for processing payment transactions of the received payment transaction type. Subsequently, the transaction management controller 102 requests payment card data (e.g., a payment card number, etc.) for the payment transaction from the POI device 130 (e.g., via a card reader, a PIN pad, etc.) based on the transaction processing parameters of the initialized transaction processing module. Once the payment card data is received from the POI device 130, and based upon the transaction processing parameters of the initialized transaction processing module. Once the payment card data is received from the POI device 130, and based upon the transaction processing module loaded into the transaction management controller 102, the transaction management controller 102 inserts the received transaction amount and the payment card data into a payment authorization request message.” (See Applicant Specification paragraph 18)
“In some embodiments, the data storage device 110 can be configured to store one of more [sic] transaction processing modules. Each transaction processing module defines one or more transaction processing parameters for processing credit transactions, another transaction module processing module can include transaction processing parameters for processing debit transactions, and another transaction processing module can include transaction processing parameters for processing chip-based payment transactions. It should be appreciated that the data storage device 110 can store any number of additional transaction processing modules for processing payment transactions of a variety of other transaction types. It should also be appreciated that in other embodiments, all or a portion of the transaction processing modules may be stored remotely by another computing device such as, for example, the remote configuration device 150.” (See Applicant Specification paragraph 27)
“In some embodiments, the transaction processing parameters for each transaction processing module can be embodied as, or otherwise include, one or more rules or instructions for processing payment transactions of a particular type. In such embodiments, the instructions or rules, once loaded or initialized by the transaction management controller 102, can be configured to cause the transaction management controller 102 to perform one or more transaction type-specific processing functions and/or control or manage transaction type-specific functions of other devices of the system 100 (or the systems 200, 300 illustratively shown in FIGS. 2 and 3). For example, the instructions or rules of a particular transaction processing module can be configured to cause the transaction management controller 102 to initialize a signature prompt feature on the POI device 130, initialize a PIN entry feature on the POI device 130, route payment authorization request messages to a particular payment network 140 (e.g., a VISA payment network, a MASTERCARD payment network, a DISCOVER payment network, an AMERICAN EXPRESS payment network, etc.), route payment authorization request messages to a payment transaction type-specific payment gateway communicatively coupled to the payment network 140, and/or initialize a payment transaction type-specific processing feature on the POI device.” (See Applicant Specification paragraph 28)
As currently recited, the term “payment vehicle type”, in view of Applicant’s Specification, will be interpreted as nothing more than a payment card or payment type. Further, the “payment vehicle type-specific transaction processing module” as noted by the Applicant Specification appears to be nothing more than rules and/or instructions for processing payment transactions of the received payment vehicle type and will be interpreted as such.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
9. Claims 28, 31-35, 38-41 and 44-47 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 28 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are: receiving the transaction amount from a business management engine where the business management engine is configured to communicate with the transaction management controller computing device and communicatively isolated from the point of interaction device. Absent the recitation of the business management engine, the configuration of the systemization that is described to function in the specification does not occur and the final step of transmitting the payment authorization response message to the business management engine also does not make sense as there is no connection between the business management engine and the limitations of the claim that are remaining.
Claims 35 and 41 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are: receiving the transaction amount from a business management engine where the business management engine is configured to communicate with the transaction management controller computing device and is communicatively isolated from the point of interaction device and generating, by the transaction management controller computing device a payment authorization request message based on the transaction amount received from the business management engine.
Absent the recitation of the business management engine, the configuration of the systemization that is described to function in the specification does not occur and the claims are also confusing. There is no initiation of a payment authorization request, no transaction amount, and no apparent connection to the transmission of a payment authorization response message to the business management engine. The claims and process just do not make sense either on their face or in view of the invention disclosed in the specification.
Dependent Claims 21-34, 38-40 and 44-47 are further rejected as dependent on a rejected base claim.
It appears that there has been some issue with how the independent claims have been amended in general. Applicant is requested to review the claims in view of the specification and present a cogent claim set. Examiner is currently giving the benefit of the doubt to Applicant, however based upon Applicant’s response, this may result in a reassertion of a prior art rejection and/or 112(a) rejections.
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.
10. Claims 28, 31-35, 38-41 and 44-47 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
ANALYSIS:
STEP 1:
Does the claimed invention fall within one of the four statutory categories of invention (process, machine, manufacture or composition matter?
Yes, the claimed invention discloses a method, system a non-transitory computer-readable storage medium claim via a series of steps.
STEP 2A:
Prong One: Does the Claim Recite A Judicial Exception (An Abstract Idea, Law of Nature or Natural Phenomenon)? (If Yes, Proceed to Prong Two, If No, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material)
Claim 28 recites the abstract idea of executing transactions. The idea is described by the following limitations:
generating a payment authorization request message based on a transaction amount;
receiving a transaction payment vehicle type associated with the payment transaction from a point of interaction;
dynamically loading and initializing a payment vehicle type specific transaction processing corresponding to the received transaction payment vehicle type from the point of interaction; and
transmitting, a payment authorization response message associated with the payment transaction based on the processing parameters included in the payment vehicle-type specific transaction processing.
Claim 35 recites the abstract idea of executing transactions. The idea is described by the following limitations:
receiving a transaction payment vehicle type associated with the payment transaction from the point of interaction;
dynamically loading and initializing a payment vehicle type specific transaction processing corresponding to the received transaction payment vehicle type from the point of interaction; and
transmitting a payment authorization response message associated with the payment transaction based on the transaction processing parameters included in the payment vehicle type-specific processing;
Claim 41 recites the abstract idea of executing transactions. The idea is described by the following limitations:
receiving a transaction payment vehicle type associated with the payment transaction from the point of interaction;
dynamically loading and initializing a payment vehicle type specific transaction processing corresponding to the received transaction payment vehicle type from the point of interaction; and
transmitting a payment authorization response message associated with the payment transaction based on the transaction processing parameters included in the payment vehicle type-specific processing.
As recited above, the independent claims recite a series of steps that describe a fundamental economic practice and commercial or legal interactions and thus are grouped as certain methods of organizing human activity which is an abstract idea.
As to certain methods of organizing human activity, the steps involve fundamental economic principles or practices and/or commercial interactions (including marketing or sales activities or behaviors and/or business relations) and/or managing personal behavior or relationships or interactions between people (i.e., receiving a transaction payment vehicle type associated with the payment transaction from the point of interaction; dynamically loading and initializing a payment vehicle type specific transaction processing corresponding to the received transaction payment vehicle type from the point of interaction; and transmitting a payment authorization response message associated with the payment transaction based on the transaction processing parameters included in the payment vehicle type-specific processing
In the case of the instant claims, the claims may be using no more than generic computer technology to execute transactions.
Claim 28 recites a transaction management controller computing device, a point of interaction (POI) device, a payment vehicle type-specific transaction processing module, and a business management engine.
Claim 35 recites a memory configured to store instructions; one or more processors configured to execute the instructions, a transaction management controller computing device, a point of interaction (POI) device, a payment vehicle type specific processing module, and a business management engine.
Claim 41 recites a non-transitory computer readable medium, instructions, one or more processors, a transaction management controller computing device, a point of interaction (POI) device, a payment vehicle type specific processing module, and a business management engine.
The claims recite a transaction management controller computing device, a point of interaction (POI) device, a business management engine, a memory configured to store instructions, one or more processors configured to execute the instructions, and a non-transitory computer readable medium and are applying generic computer components to the recited abstract limitations. The recited a payment vehicle type specific transaction module and instructions appear to be software. (Step 2A – Prong 1: Yes, the claims are abstract)
Prong Two: Does the Claim Recite Additional Elements That Integrate The Judicial Exception Into A Practical Application of the Exception? (If Yes, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material. If No, Proceed to Step 2B)
The claims do not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field, improvements to the functioning of the computer itself, are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, are not applying the judicial exception with, or by use of a particular machine, are not effecting a transformation or reduction of a particular article to a different state or thing, and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
In the instant case, the additional elements are mere instructions to apply an exception because they do no more than merely invoke computers or machinery as a tool in its ordinary capacity for receiving and processing data. As currently claimed, the limitations are using computers or other machinery as a tool to perform an existing process and is therefore equivalent to “applying it”.
In the instant case, the claim limitations that add insignificant extra-solution activity to the judicial exception (e.g., mere data gathering in conjunction with a law of nature or abstract idea), and type of data to be manipulated that do not add a meaningful limitation equating to significantly more than the process of managing executing transactions via a series of steps.
In particular, the claims only recite a transaction management controller computing device, a point of interaction (POI) device, a business management engine, a memory configured to store instructions, one or more processors configured to execute the instructions, a plurality of payment vehicle type specific transaction modules, instructions, storage device of a remote configuration device and a non-transitory computer readable medium which are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, Claims 28, 35 and 41 are directed to an abstract idea without a practical application. (Step 2A – Prong 2: No, the additional claimed elements are not integrated into a practical application)
STEP 2B: If there is an exception, determine if the claim as a whole recites significantly more than the judicial exception itself.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: i) receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); ii) performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); iii) electronic recordkeeping, Alice Corp., 134 S. Ct. at 2359, 110 USPQ2d at 1984 (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv) storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; v) electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition); and vi) a web browser’s back and forward button functionality, Internet Patent Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1418 (Fed. Cir. 2015). (MPEP §2106.05(d)(II))
This listing is not meant to imply that all computer functions are well‐understood, routine, conventional activities, or that a claim reciting a generic computer component performing a generic computer function is necessarily ineligible. Courts have held computer‐implemented processes not to be significantly more than an abstract idea (and thus ineligible) where the claim as a whole amounts to nothing more than generic computer functions merely used to implement an abstract idea, such as an idea that could be done by a human analog (i.e., by hand or by merely thinking). On the other hand, courts have held computer-implemented processes to be significantly more than an abstract idea (and thus eligible), where generic computer components are able in combination to perform functions that are not merely generic. (MPEP §2106.05(d)(II) – emphasis added)
Below are examples of other types of activity that the courts have found to be well-understood, routine, conventional activity when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: recording a customer’s order, Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1244, 120 USPQ2d 1844, 1856 (Fed. Cir. 2016); shuffling and dealing a standard deck of cards, In re Smith, 815 F.3d 816, 819, 118 USPQ2d 1245, 1247 (Fed. Cir. 2016); restricting public access to media by requiring a consumer to view an advertisement, Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716-17, 112 USPQ2d 1750, 1755-56 (Fed. Cir. 2014); identifying undeliverable mail items, decoding data on those mail items, and creating output data, Return Mail, Inc. v. U.S. Postal Service, -- F.3d --, -- USPQ2d --, slip op. at 32 (Fed. Cir. August 28, 2017); presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; and arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331, 115 USPQ2d 1681, 1699 (Fed. Cir. 2015) (MPEP 2106.05(d))
Here, the steps are receiving or transmitting data over a network (Symantec, TLI, OIP Techs – MPEP 2106.05(d)(II); performing repetitive calculations (Bancorp – MPEP 2106.05(d)(II); storing and retrieving information in memory (Versata, OIP Techs – MPEP 2106.05(d)(II) and electronically scanning or extracting data (Content Extraction – MPEP 2106.05(d)(II)– all of which have been recognized by the courts as well-understood, routine and conventional functions.
The claims are directed to an abstract idea with additional generic computer elements that do not add meaningful limitations to the abstract idea because they require no more than a generic computer to perform generic computer functions that are well-understood, routine, and conventional activities previously known in the industry.
For the next step of the analysis, it must be determined whether the limitations present in the claims represent a patent-eligible application of the abstract idea. A claim directed to a judicial exception must be analyzed to determine whether the elements of the claim, considered both individually and as an ordered combination are sufficient to ensure that the claim as a whole amounts to significantly more than the exception itself.
For the role of a computer in a computer implemented invention to be deemed meaningful in the context of this analysis, it must involve more than performance of “well-understood, routine, [and] conventional activities previously known to the industry.” Further, “the mere recitation of a generic computer cannot transform a patent ineligible abstract idea into a patent-eligible invention.”
Applicant’s specification discloses the following:
“The transaction management controller 102 can be embodied as any type of computing device or server or capable of processing, communicating, storing, maintaining, and transferring data. For example, the transaction management controller 102 can be embodied as a server, a microcomputer, a minicomputer, a mainframe, a desktop computer, a laptop computer, a mobile computing device, a handheld computer, a smart phone, a tablet computer, a personal digital assistant, a telephony device, a custom chip, an embedded processing device, or other computing device and/or suitable programmable device. In some embodiments, the transaction management controller 102 can be embodied as a computing device integrated with other systems or subsystems. In the illustrative embodiment of FIG. 1, the transaction management controller 102 includes a processor 104, a system bus 106, a memory 108, a data storage 110, communication circuitry 112, and one or more peripheral devices 114. Of course, the transaction management controller 102 can include other or additional components, such as those commonly found in a server and/or computer (e.g., various input/output devices), in other embodiments. Additionally, in some embodiments, one or more of the illustrative components can be incorporated in, or otherwise from a portion of, another component. For example, the memory 108, or portions thereof, can be incorporated in the processor 104 in some embodiments. Furthermore, it should be appreciated that the transaction management controller 102 can include other components, sub-components, and devices commonly found in a computer and/or computing device, which are not illustrated in FIG. 1 for clarity of the description.” (See Applicant Specification paragraph 22)
“The processor 104 can be embodied as any type of processor capable of performing the functions described herein. For example, the processor 104 can be embodied as a single or multi-core processor, a digital signal processor, microcontroller, a general purpose central processing unit (CPU), a reduced instruction set computer (RISC) processor, a processor having a pipeline, a complex instruction set computer (CISC) processor, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), or other processing/controlling circuit or controller.” (See Applicant Specification paragraph 23)
“In various configurations, the transaction management controller 102 includes a system bus 106 for interconnecting the various components of the transaction management controller 102. The system bus 106 can be embodied as, or otherwise include, memory controller hubs, input/output hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations with the processor 104, the memory 107, and other components of the transaction management controller 102. In some embodiments, the transaction management controller 102 can be integrated into one or more chips such as a programmable logic device or an application specific integrated circuit (ASIC). In some embodiments, the system bus can form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor 104, the memory 108, and other components of the transaction management controller 102, on a single integrated circuit chip.” (See Applicant Specification paragraph 24)
“The memory 108 can be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. For example, the memory 108 can be embodied as read only memory (ROM), random access memory (RAM), cache memory associated with the processor 104, or other memories such as dynamic RAM (DRAM), static RAM (SRAM), programmable ROM (PROM), electrically erasable PROM (EEPROM), flash memory, a removable memory card or disk, a solid state drive, and so forth. In operation, the memory 108 can store various data and software used during operation of the transaction management controller 102 such as operating systems, applications, programs, libraries and drivers.” (See Applicant Specification paragraph 25)
“The data storage 110 can be embodied as any type of device or devices configured for short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. For example, in some embodiments, the data storage 110 includes storage media such as a storage device that can be configured to have multiple modules, such as magnetic disk drives, floppy drives, tape drives, hard drives, optical drives and media, magneto-optical drives and media, Compact Disc (CD) drives, Compact Disc Read Only Memory (CD-ROM), Compact Disc Recordable (CD-R), Compact Disc Rewriteable (CD-RW), a suitable type of Digital Versatile Disc (DVD) or Blu-Ray disc, and so forth. Storage media such as flash drives, solid state hard drives, redundant array of individual disks (RAID), virtual drives, networked drives and other memory means including storage media on the processor 104, or the memory 108 are also contemplated as storage devices. It should be appreciated that such memory can be internal or external with respect to operation of the disclosed embodiments. It should also be appreciated that such memory can be internal or external with respect to operation of the disclosed embodiments. It should also be appreciated that certain portions of the processes described herein can be performed using instructions stored on a computer-readable medium or media that direct or otherwise instruct a computer system to perform the process steps. Non-transitory computer-readable media, as used herein, comprises all computer-readable media except for transitory, propagating signals. (See Applicant Specification paragraph 26)
“The communication circuitry 112 of the transaction management controller 102 may be embodied as any type of communication circuit, device, interface, or collection thereof, capable of enabling communications between the transaction management controller 102 and the business management engine 120, POI device 130, payment network 140, remote configuration device 150, and/or any other computing device communicatively coupled thereto. For example, the communication circuitry 112 may be embodied as one or more network interface controllers (NICs), in some embodiments. The communication circuitry 112 may be configured to use any one or more communication technologies (e.g., wireless or wired communications) and associated protocols (e.g., Ethernet, Wi-Fi, WiMAX, etc.) to effect such communication.” (See Applicant Specification paragraph 30)
“In some embodiments, the transaction management controller 102, business management engine 120, POI device 130, payment network 140, remote configuration device 150, and/or any other computing devices of the system 100, can communicate with each other over one or more networks. The network(s) can be embodied as any number of various wired and/or wireless communication networks. For example, the network(s) can be embodied as or otherwise include a local area network (LAN), a wide area network (WAN), a cellular network, or a publicly accessible, global network such as the Internet. Additionally, the network(s) can include any number of additional devices to facilitate communication between the computing devices of the system 100.” (See Applicant Specification paragraph 31)
“The business management engine 120 can be embodied as any type of computing device capable of performing the functions described herein. As such, the business management engine 120 can include devices and structures commonly found in computing devices such as processors, memory devices, communication circuitry, and data storages, which are not shown in FIG. 1 for clarity of the description. The business management engine 120 can be configured to perform certain business-related functions, such as, without limitation, sales tabulation, inventory management, scheduling, accounting processes, payroll, and the like. As it to be appreciated, the particular business-related functions facilitated by a business management engine may depend on the needs of the particular business (e.g., merchant) utilizing the business management engine. In this regard, a business management engine of a salon may provide different business-related functions than that of a specialty retailer, for example. In some embodiments, the business management engine 120 is configured to initiate payment transactions. As discussed in more detail below, the business management engine 120 is configured to communicate with the transaction management controller 102 to facilitate such payment transactions. For example, in some embodiments, the business management engine 120 is configured to transmit a payment request to the transaction management controller 102. The payment request can be embodied as an HTTP message that includes the amount of the transaction. Additionally, the business management engine 120 can be configured to receive a payment authorization response message from the transaction management controller 102. As discussed in more detail below, the business management engine can be communicatively isolated from the POI device 130 (e.g., not in direct communication with the POI device 130). As such, instead of being directly connected to the POI device 130, the business management engine 120 is communicatively coupled to the transaction management controller 102, which manages communications with the POI device 130. It should be appreciated that in doing so, the complexity of configuring (e.g., coding, certification, initialization, etc.) of that business management engine 120 is reduced.” (See Applicant Specification paragraph 33)
“The point of interaction (POI) device 130 can be embodied as any type of computing or payment device capable of performing the functions described herein. For example, in the illustrative embodiment, the POI device 130 can be embodied as a card reader or a PIN pad configured to facilitate receipt of a payment card for a payment transaction (e.g., a credit or debit transaction). The POI device 130 can include devices and structures commonly found in computing and payment devices such as processors, memory devices, communication circuitry, and data storages, which are not shown in FIG. 1 for clarity of the description. For example, in some embodiments, the POI device 130 can include payment hardware and functionality configured for receiving traditional payment cards containing magnetic stripes (e.g., magstripes, swipe cards, etc.). The POI device 130 can also include payment hardware and functionality configured for receiving payment cards via Near Field Communication (NFC) technologies, BLUETOOTH communication technologies, and other contactless and/or short range wireless communication technologies. Additionally or alternatively, in some embodiments, the POI device 130 can include integrated circuit payment hardware and functionality configured for receiving a EUROPAY, MASTERCARD, and VISA (EMV) payment card or other smartcard or chip-based card. Of course, the POI device 130 can include any other type of payment hardware and functionality for receiving a payment or vehicle. (See Applicant Specification paragraph 35)
Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system.
Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. The collective functions appear to be implemented using conventional computer systemization.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Upon reconsideration of the indicia noted under Step 2A in concert with the Step 2B considerations, the additional claim element(s) amounts to no more than mere instructions to apply the exception using generic computer components. The same analysis applies in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The claim does not provide an inventive concept significantly more than the abstract idea.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The independent claims 28, 35 and 41 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent Claims 31-34, 38-40 and 44-47 further define the abstract idea that is presented in the respective independent Claims 28, 35 and 41 and are further grouped as certain methods of organizing human activity and are abstract for the same reasons and basis as presented above.
Dependent Claim 31 further discloses a plurality of payment vehicle type-specific transaction processing modules.
Dependent Claims 33 and 47 further detail that the payment response authorization message comprises a HTTP. Dependent Claim 34 recites a payment network and a payment gateway.
Dependent Claims 38 and 44 further disclose a storage device of a remote configuration device, a plurality of payment vehicle type-specific transaction modules, wherein the storage device is one of a local storage device or a remote storage device.
In each case, the additional elements are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
No further additional hardware components other than those found in the respective independent claims is recited, thus it is presumed that the claim is further utilizing the same generic systemization as presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application of the exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Therefore, the dependent claims are also directed to an abstract idea .
Thus, Claims 28, 31-35, 38-41 and 44-47 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Relevant Prior Art of Record Not Currently Cited
Laracey (US PG Pub. 2011/0251892) – disclosing systems, methods, processes, computer program code and means for using mobile devices to conduct payment transactions at merchant locations that can involve a number of different payment accounts that may be processed over a variety of different payment networks.
Wagner et al. (US PG Pub. 2016/0277380) – disclosing techniques for verifying a transaction that may include receiving an authorization request from an access device to conduct a transaction. Wagner further discloses that messages between the computers, networks and devices may be transmitted using secure communications protocols such as, but not limited to FTP, HTTP, HTTPS, SSL, ISO and the like.
Calman (US PG Pub. 2013/0339165) – disclosing systems and methods for providing payment vehicle recommendations. In the systems and methods, a transaction associated with one of a transaction amount and purchase items is identified based on the transaction data; one or more payment rules associated with the transaction are identified; the terms of one or more payment rules are compared with the transaction amount or purchase items and the most favorable payment vehicle for the transaction is determined based on the comparison of the terms of the one or more payment rules and transaction amount or purchase items. A recommendation of the at least one payment vehicle is provided based on the determination of the most favorable payment vehicle on a display of a mobile device of a user.
Dix (US PG Pub. 2017/0083877) – disclosing a method and system for managing payment card transaction instructions at a point of interaction device. The method includes storing one or more payment card transaction instructions received from an entity responsible for a plurality of payment cards usable with the POI device wherein the payment card transaction instructions are associated with at least one of a brand and a product of the entity.
Response to Arguments
Applicant's arguments filed on February 5, 2026 have been fully considered as follows:
Regarding the Claim Objections:
Applicant is thanked for the correction to Claim 44 to address the previously raised claim objection. The previous objection has been withdrawn. (See Applicant Arguments dated 02/05/2026, page 11)
Regarding the 112(a) Rejections:
As amended, the claims did resolve the 112(a) issue previously raised, however, has caused a number of 112(b) issues, as fully disclosed in the rejection in chief. (Id. at pages 11-14)
Regarding the 101 Rejection:
Applicant traverses the 101 rejections as being directed to non-statutory subject matter. (Id. at pages 14-15) No substantive arguments have been additionally presented. As amended, the claims are still subject to a 101 rejection as seen in the rejection in chief.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMBREEN A. ALLADIN whose telephone number is (571)270-3533. The examiner can normally be reached Monday - Friday 9-5.
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, Abhishek Vyas can be reached at 571-270-1836. 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.
/AMBREEN A. ALLADIN/Primary Examiner, Art Unit 3691 March 8, 2026