DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Jun. 23, 2026, and is made Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Interviews are “indispensable to advance the prosecution of a patent application.” MPEP § 713. Accordingly, the following Examiner’s guidance and suggested workflow maximizes this benefit to Applicant by: (1) avoiding back and forth telephone calls for scheduling, (2) permitting Examiner out-of-office notifications to the Applicant when emailing the agenda, and (3) permitting real-time document collaboration and screen sharing.
Interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. If an interview is needed more quickly than permitted by the AIR scheduling tool, note this in the AIR remarks for consideration. The Examiner routinely considers such urgent requests when practicable.
An agenda submitted when filing the AIR is strongly encouraged, because Examiners use agendas when determining whether to grant an interview. The AIR has character limits, so send the agenda contemporaneously to James.Miller1@uspto.gov and reference the AIR.
After-Final Interviews Requests are granted only at the Examiner’s discretion and only if disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. An advance agenda explaining how the interview advances prosecution—e.g., through targeted arguments, identified Examiner error, or proposed claim amendments—is strongly suggested.
For GRANTED requests, expect an email within two (2) business days confirming a date/time slot and collaboration tool access instructions. For DENIED requests, the record will include an explanation for the denial.
The examiner is generally available for interviews, Monday through Friday, 10:00 a.m. to 4:00 p.m. ET.
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 Status
The status of claims is as follows:
Claims 1–4, 6, 7, and 15–20 are currently pending and examined with Claims 1 and 15 in independent form.
Claims 1, 4, 15, 18, and 19 are presently amended.
No Claims are presently cancelled or added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Jun. 13, 2024, [“Applicant’s Specification”] and accepted for examination.
Response to Arguments
35 U.S.C. § 101 Argument
Applicant argues that “[e]ven assuming, solely for argument, that the claims recite an abstract idea, the amended claims recite additional elements that integrate any such idea into a practical application” because amended claims “require a specific distributed architecture in which a server generates an account rule data structure and provides it, via a network and in a one-way direction, to one or more medium processing devices of a client.” Applicant’s Reply at 10. The client uses the account rule data structure “after accepting input regarding an input account” “at runtime” to “determine[ ] a set of executable transactions” and “executes a transaction” “without setting the account rule data structure locally in the one or more medium processing devices.” Applicant’s Reply at 10–11. Applicant asserts this specific distributed architecture is an “improvement to the functioning of the distributed transaction-processing system and to the technological field, like Enfish and DDR Holdings because “the medium processing device is no longer confined to a fixed, predefined transaction set, and its executable-transaction capability is defined dynamically rather than hard-coded locally,” citing the Specification ¶¶ 11–13. Applicant’s Reply at 11.
Examiner respectfully disagrees. Applicant’s amendments do not integrate the abstract idea into a practical application. The amended claims are directed to the abstract idea of managing account information, determining transactions available under account rules and carrying out a transaction based of the determination, which recites certain The methods of organizing human activity and mental process.
The limitations requiring a server to “provide [transmit], via a network, the account rule data structure to the one or more medium processing devices [client]”; and requiring the medium devices [clients] to “accept [receive] input regarding an input account” recite the use of generic computer and network components to transmit, receive, and process information. MPEP § 2106.05(f)(2). The Specification describes the server, network, client, GUI, processors, medium processing devices, and memory broadly as generic computing and networking components performing their ordinary functions. Spec. ¶¶ 38–54.
The claimed determination of “a set of executable transactions” “based on the account rule data structure and the input account” is part of the organizing human activity and mental process exceptions. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP § 2106.05(I); MPEP § 2106.04(d)(III).
The account rule data structure “not being generated in the one or more medium processing devices but being sent in a one-way direction from the server” and “remotely provided from the server and used at the client without setting the account rule data structure locally in the one or more medium processing devices” does not integrate the abstract idea into a practical application or inventive concept. These limitations identify where rule information is generated and used, and the direction of communication between generic computing devices but do not recite a specific technological manner in which the data structure is generated, transmitted in a one way direction, prevented from “setting the account locally” or used to improve the operation of the computer of network. Rather, the claims are results-orientated: an account rule data structure is generated at the claimed server, communicated by a generic network to the claimed client, another generic computing device, and used with the input account to determine a set of executable transactions and execute a determined transaction. The Specification describes “entity terminal device 108 may send, and the medium processing device 110 may receive, the entity account rule data structure (e.g., including the information identifying the selected allowable transactions for each account or account type and/or the corresponding rules that govern performance of the selected allowable transactions for each account or account type)” but does not describe a technical improvement to data transmission, or client server operations. Spec. ¶ 28.
The recitation of “execute a transaction in accordance with the set of executable transactions that are determined” also does not integrate the abstract idea exception into a practical application because it is part of the account management exception. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP § 2106.05(I); MPEP § 2106.04(d)(III). Alternatively, even if this limitation is treated as an additional element, the claims do not recite a particular transaction execution mechanism or improvement in the way the medium processing devices execute transactions. The Specification teaches “the medium processing device 110 may perform the withdrawal transaction (e.g., based on interacting with a backend system related to withdrawal transactions) according to the corresponding rules that govern the performance of the withdrawal transaction. Although the medium processing device 110 is described as performing the withdrawal transaction, the medium processing device may perform any suitable transaction (e.g., by accessing one or more backend systems, as needed to perform the transaction.” Spec. ¶ 35.
Applicant argues the amended claims do not recite a mental process exception because they require a server-generated account rule data structure, one way transmission to the client, client-side determination based on the received data structure and an input account and transaction execution. Applicant’s Reply at 11.
Examiner respectfully disagrees. The § 101 rejection does not depend on a finding that the client/server implementation can be performed mentally. Rather, under BRI, the mental process exception is directed to the underlying abstract concept that can reasonably be performed in the human mind or with pen and paper. The server/client features are evaluated as additional elements.
Applicant argues the amended claims considered as an ordered combination provide significantly more because “[t]he specific interaction among the server, the network, and the client's medium processing devices - including one-way provisioning of a server-generated rule data structure and client-side runtime determination of the set of executable transactions without local configuration - is not well-understood, routine, or conventional.”
Examiner respectfully disagrees. Considered as an ordered combination, the claimed additional elements perform their ordinary functions. A server generates information, a network communicates information, a client device receives and processes information regarding account rules, and a transaction is performed based on the rules. The Specification describes the hardware and networking components in generic terms and does not identify a nonconventional technical interaction that improves the functioning of a computer, server, client or network, or transaction processing itself. Spec. ¶¶ 38–54.
An ordered combination does not supply an inventive concept because the claims describe at a high functional level the sequence in which generic information processing functions occur. Although the claims recite a sequence and allocation of functions between a server and client, they do not recite a technical mechanism by which the asserted one way transmission, remote provision, or absence of local setting improves a computer. The combination amounts to applying the exception using generic computer components.
Accordingly, the amended claims recite an abstract account rule management concept implemented through generic distributed computing components. Merely allocating information processing between a server and a client does not, without more, establish an improvement in computer or network functionality. The “a one-way direction from the server”, “the account rule data structure is remotely provided from the server and used at the client without setting the account rule data structure locally in the one or more medium processing devices” recite results of information processing but do not recite how the claimed results are technically achieved, how they improves a computer, or why they are an unconventional architecture.
35 U.S.C. § 103 Argument
Applicant’s arguments with respect to Claims 1–4, 6, 7, and 15–20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Interpretation
Under the broadest reasonable interpretation, the following claim terms are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. MPEP § 2111.
the account rule data structure not being generated in the one or more medium processing devices. The medium processing devices do not generate the account rule data structure as claimed. This limitation is surplusage.
the account rule data structure … being sent in a one-way direction from the server. The server to client transmission of the account rule data structure is a one-way direction from the server to the client. This limitation is surplusage and redundant of the claimed network provision from server to medium processing device.
without setting the account rule data structure locally in the one or more medium processing devices. The medium processing device does not locally configure the received account rule data structure. The account rule data structure is received from the server by the client.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1–4, 6, 7, and 15–20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 1–4, 6, 7, and 15–20 are directed to a statutory category. Claims 1–4, 6, 7 recite a “system” and are therefore, directed to the statutory category of a “machine.” Claims 15–20 recite a “non-transitory computer-readable medium” and are therefore, directed to the statutory category of an "article of manufacture.”
Representative Claim
Claim 1 is representative [“Rep. Claim 1”] of the subject matter under examination and recites, in part, emphasis added by Examiner to identify limitations with normal font indicating the abstract idea exception, bold limitations indicating additional elements. Each limitation is identified by a letter for later use as a shorthand notation in referencing/describing each limitation. Portions of the claim use italics to identify intended use limitations1 and underline, as needed, in further describing the abstract idea exception:
[A] 1. A system, comprising: a server including one or more memories and one or more processors; and a client including one or more medium processing devices, wherein the one or more processors of the server, communicably coupled to the one or more memories, are configured to:
[B] obtain account information associated with a set of accounts managed by an entity;
[C] generate, based on the account information, a set of allowable transactions associated with the set of accounts and a set of rules that govern performance of the set of allowable transactions;
[D] provide a graphical user interface (GUI) that displays the set of allowable transactions;
[E] receive, via the GUI, user input indicating a selection of one or more allowable transactions, included in the set of allowable transactions, associated with one or more accounts included in the set of accounts;
[F] generate an account rule data structure that indicates the one or more allowable transactions and one or more rules, included in the set of rules, corresponding to the one or more allowable transactions; and
[G] provide, via a network, the account rule data structure to the one or more medium processing devices, wherein the one or more medium processing devices of the client are configured to:
[H] accept input regarding an input account;
[I] determine, based on the account rule data structure and the input account, a set of executable transactions at the client, the account rule data structure not being generated in the one or more medium processing devices but being sent in a one-way direction from the server;
[J] execute a transaction in accordance with the set of executable transactions that are determined, and
[K] wherein the account rule data structure is remotely provided from the server and used at the client without setting the account rule data structure locally in the one or more medium processing devices.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 1 recites a method of organizing human activity in the un-bolded limitations supra. These un-bolded limitations supra describe [B] obtaining account information; [C] generating allowable transaction and governing rules; [D] displaying allowable transactions; [E] receiving user input indicating allowable transactions; [F] generating an account rule data structure that indicates allowable transactions and rules; [H] receiving an input accept; [I] determining a set of executable transactions; and [J] executing a permitted transaction. Managing account permissions, determining which financial transactions are allowable or executable for an account, and carrying out a transaction for that account that comports with those applicable rules is an old and well-known commercial practice. MPEP § 2106.04(a)(2)(II)(A) (citing Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1313, 120 USPQ2d 1353, 1356 (Fed. Cir. 2016) ("The category of abstract ideas embraces ‘fundamental economic practice[s] long prevalent in our system of commerce,’ … including ‘longstanding commercial practice[s]’").
Alternatively2, Limitations B–F and H–I, as drafted, recite the abstract idea exception of mental processes that under the broadest reasonable interpretation, cover performance in the human mind or with pen and paper, but for the recitation of the generic computer components indicated in bold. MPEP § 2106.04(a)(2)(III).
Claims recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include:
• a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016);
. . .
• a claim to collecting and comparing known information (claim 1), which are steps that can be practically performed in the human mind, Classen Immunotherapies, Inc. v. Biogen IDEC, 659 F.3d 1057, 1067, 100 USPQ2d 1492, 1500 (Fed. Cir. 2011).
MPEP § 2106.04(a)(2)(III)(A). For example, but for the generic computer components claim language, here, Limitations B–F and H–I, recite collecting information (Limitations B, E, H) and analyzing it (Limitations C, F, I, J) and displaying certain results of the collection and analysis (Limitation D), where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind. For example, Limitation C is a mental process that is practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” to generate, based on the account information, a set of allowable transactions associated with the set of accounts and a set of rules that govern performance of the set of allowable transactions. A human banker could, for example upon obtaining an account balance, generate, based on that account balance, a set of allowable transactions (payments) that permit payment only when there is sufficient funds available. Likewise, Limitation F is a mental process that is practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” to generate an account rule data structure that indicates the one or more allowable transactions and one or more rules, included in the set of rules, corresponding to the one or more allowable transactions. Limitation F covers data structure with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, which is so broad as to encompass mental processes. Limitations I and J are mental processes that are practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” to determine, based on the account rule data structure and the input account, a set of executable transactions and execute a transaction in accordance with the set of executable transactions that are determined.
If a claim limitation under BRI, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract idea exception. MPEP § 2106.04(a)(2)(III). Accordingly, the pending claims recite the combination of these abstract idea exceptions.
Step 2A, Prong Two: Rep. Claim 1 does not contain additional elements that integrate the abstract idea exception into a practical application because the additional elements are mere instructions to apply the abstract idea exception. MPEP § 2106.05(f).The additional elements are limited to the computer components and indicated in bold, supra. The additional elements are: Limitation A, provide a graphical user interface (GUI); Limitation G; the account rule data structure not being generated in the one or more medium processing devices but being sent in a one-way direction from the server; and Limitation K.
Regarding Limitation A, provide a graphical user interface (GUI); Limitation G; the account rule data structure not being generated in the one or more medium processing devices but being sent in a one-way direction from the server; and Limitation K, Applicant’s Specification does not otherwise describe them or describes them using exemplary language as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. Thus, Applicant takes the position that such hardware/software is so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Meyers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). E.g., Spec. ¶¶ 39–41 (describing the automated service system 102, entity server device 104, entity backend system 106, entity terminal device 108, and medium processing device 110 as servers or computing devices, including cloud-computing implementations, using standard networking), ¶ 46 (describing the entity terminal device 108 as any of various conventional computing/communication devices such as mobile phones, laptops, tablets, desktops, etc.), ¶ 47 (describing the medium processing device 110 as one or more servers or computing hardware that process transactions), ¶¶ 50–55 (describing a generic device 300 with a bus, processor, memory, input/output components, and a communication component, implemented using conventional processor and memory technologies), ¶¶ 59, 60 (describing providing a GUI that displays allowable transactions and receiving user input via the GUI in high-level, functional terms), ¶¶ 64–71 (describing providing a GUI, receiving input, and performing transactions using a generic medium processing device). The generic processor, here, appears to perform calculations (functions) that are programmed by software. Spec. ¶¶ 50–55 (describing processor 320 as any conventional processing component, memory 330 as conventional volatile/non-volatile memory storing instructions, and noting that a processor executes stored instructions or hardwired circuitry to perform the described operations), ¶¶ 56–61 (describing the process 400 as being performed by the automated service system and the generic device 300, where the processor executes instructions to obtain account information, generate allowable transactions and rules, provide a GUI, receive user input, and generate an account rule data structure). This is a computer doing what it is designed to do—performing directions it is given to follow
The displaying step, Limitation D fails to transform the claims into patent eligible material, as this is part of the field of use and technical environment in which the abstract idea is being implement and does not result in an improvement to additional elements, a practical application, or inventive concept. MPEP 2106.05(h) (citing Electric Power Group). Further, requiring the use of software to tailor information and provide it to the user on a generic computer also does not provide a practical application or inventive concept. MPEP § 2106.05(f)(2) (citing Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015)).
The limitations requiring a server to “provide [transmit], via a network, the account rule data structure to the one or more medium processing devices [client]”; and requiring the medium devices [clients] to “accept [receive] input regarding an input account” recite the use of generic computer and network components to transmit, receive, and process information. MPEP § 2106.05(f)(2). The Specification describes the server, network, client, GUI, processors, medium processing devices, and memory broadly as generic computing and networking components performing their ordinary functions. Spec. ¶¶ 38–54.
The account rule data structure “not being generated in the one or more medium processing devices but being sent in a one-way direction from the server” and is “remotely provided from the server and used at the client without setting the account rule data structure locally in the one or more medium processing devices” is not a practical application or inventive concept. These limitations identify where rule information is generated and used, and the direction of communication between generic computing devices but does not recite a specific technological manner in which the data structure is generated, transmitted in a one way direction, prevented from “setting the account locally” or used to improve the operation of the computer of network. Rather, the claims are results-orientated: an account rule data structure is generated at a first generic computing device (server), communicated by a generic network to a second computer device (client) another generic computing device, and used with the input account to determine a set of executable transactions and execute a determined transaction. The Specification describes “entity terminal device 108 may send, and the medium processing device 110 may receive, the entity account rule data structure (e.g., including the information identifying the selected allowable transactions for each account or account type and/or the corresponding rules that govern performance of the selected allowable transactions for each account or account type)” but does not describe a technical improvement to data transmission, or client server operations. Spec. ¶ 28.
Limitation A describes the memory “coupled” in some way with the processor. Limitation A further describes the processor “configured to” (programmed instructions) to perform the steps of the claimed invention. This takes generic hardware and describes the functions of receiving, storing, and sending data (programmed instructions) between the processor and memory device, which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2). Limitations B–F and H–J describe the processor, memory, and instructions, performing the steps of the claimed invention, which represents the abstract idea exception itself. Performing the steps of the abstract idea exception itself simply adds a general-purpose computer after the fact to an abstract idea exception, MPEP § 2106.05(f)(2), or generically recites an effect of the judicial exception. MPEP § 2106.05(f)(3).
Therefore, the claim as a whole, looking at the additional elements individually and in combination, are no more than mere instructions to apply the exception using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 1 is directed to an abstract idea.
Rep. Claim 1 is not substantially different than Independent Claim 15 and includes all the limitations of Rep. Claim 1. Independent Claim 15 contains no additional elements. Therefore, Independent Claim 15 is also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 1 fails Step 2B because the claim as whole, even when considering the additional elements individually and in combination, does not amount to significantly more than the recited judicial exception. As discussed with respect to Step 2A, Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer and generic computer components. See MPEP § 2106.05(f). The same analysis applies here in Step 2B. Mere instructions to apply a judicial exception on a computer and/or with basic computer components do not provide an inventive concept. MPEP § 2106.05(I).
The additional elements, taken individually and in combination, do not result in the claim, as a whole, amounting to significantly more than the identified judicial exception.
The pending claims’ combination of additional elements is not inventive. First, as explained above, the claims are directed to an abstract idea. Second, each additional element represents currently available generic computer technology, used in a conventional manner (individually generic). Third, Applicant’s Specification discloses that the combination of additional elements relies on conventional computer components and functions. Spec. ¶¶ 39–41, 46, 47, 50–55, 56–61, 62, 63–71, 72.
Accordingly, the generic server, client, processor, memory, GUI, network, input/output, and communication components of Rep. Claim 1 are elements that have been recognized, based on Applicant’s own disclosure3, as well-understood, routine, and conventional (“WURC”) activity in the field. Spec. ¶¶ 39–41, 46, 47, 50–55, 56–61, 62, 63–71, 72. Limitations I and K do not recite a technological mechanism that improves the computer, network, memory, or transaction processing. MPEP § 2106.05(d). These elements do no more than “apply” the recited abstract idea(s) using known computer and computer-related components. The Specification also shows that the functions of receiving, storing, transmitting, displaying, and processing (e.g., performing logic or mathematical operations on) data performed by generic computer and networking components. See, e.g., Spec. ¶¶ 15–19, 23–25, 29–31, 39–41, 46–47, 50–55, 56–61, 63–71.
The amended limitations do not alter this conclusion. Rep. Claim 1 recites that “[I] … the account rule data structure not being generated in the one or more medium processing devices but being sent in a one-way direction from the server” and is “[K] … remotely provided from the server and used at the client without setting the account rule data structure locally in the one or more medium processing devices.” These limitations identify where account rule information is generated and used and the direction in which information is communicated, but do not recite a particular technological mechanism that improves the operation of the server, client, network, processor, memory, or transaction processing system. Thus, even in combination, the additional elements do not amount to significantly more that the recited exception. The claims sequence and allocation of functions between a server and a client are recited at a high-level and do not recite a technological mechanism that improves how computers operate.
There is no indication in the claim language or in the Specification that the combination of elements improves the functioning of a computer itself or improves any other technology or technical field. Rather, the additional elements simply implement the abstract idea—managing account information, defining allowable transactions, and applying corresponding rules—on a conventional computer system at a high level of generality. Looking at the additional elements in combination adds nothing that is not already present when looking at the elements individually. Their collective functions merely provide a conventional computer implementation of the abstract idea. Thus, Rep. Claim 1 does not provide an inventive concept.
Independent Claim 15 is a computer-readable medium claim whose instructions cause a system to perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claim 15 adds no additional elements beyond those of Rep. Claim 1 that would amount to significantly more than the abstract idea. Therefore, Independent Claim 15 also does not recite an inventive concept under Step 2B.
Dependent Claims Not Significantly More
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. § 101. Dependent claims are dependent on Independent Claims and include all the limitations of the Independent Claims. Therefore, all dependent claims recite the same Abstract Idea. Dependent claims do not contain additional elements that integrate the abstract idea exception into a practical application or recite an inventive concept because the additional elements: (1) are mere instructions to apply the abstract idea exception; and/or (2) further limit the abstract idea exception of the Independent Claims. The abstract idea itself cannot provide the inventive concept or practical application. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claims 2, 6, 16, and 20 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims and contain no additional elements. For Claims 2 and 16, Using unique identifiers for accounts is a conventional data practice in financial and database systems and merely narrows the abstract idea being processed. It neither provides improves computer functionality nor any technical field. See, e.g., Spec. ¶¶ 16, 17 (describing entity account identifiers as part of ordinary account business information, ¶¶ 50–55 (generic data stored in memory). Claims 6 and 20 further narrow and label the “entity” as a “financial institution”. This is a non-technical business context limitation that does not introduce any hardware or technical features. Limiting the abstract idea to the environment of a financial institution is a field of use limitation that under MPEP § 2106.05(h) does not amount to significantly more than the abstract idea itself. Further, the specification consistently treats the financial institution context as exemplary. Spec. ¶¶ 15, 16, 17, 41–44. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claims 3, 4, 7, 17, 18, and 19 all recite “wherein” clauses that further limits the abstract idea of the Independent Claims but contains the additional elements of: a backend system (Claims 3, 17); a medium processing device (Claims 4, 17, 18); and multiple backend systems (Claim 7). Regarding Claims 3 and 17, obtaining data from a backend system is a routine operation in distributed computing and financial systems. Spec. ¶¶ 15–19, 41–44 (backend systems for core banking, payment processing, risk management, etc.). The recitation the account information comes “from a backend system” therefore applies the abstract idea in a conventional client-server environment and does not provide a specific improvement to the computer or computer technology or any inventive concept. This limitation merely provides a source of the account information and further narrows how the abstract data gathering idea is performed. Claims 4, 18, and 19, clarify that the rule data structure is used by a downstream device to perform transactions or assign accounts, which are both uses that are part of the same abstract idea of enforcing account rules in a financial environment. The communication of a data structure between generic computer devices and its use to govern user-initiated transactions is a conventional business practice in computer networked applications. Any networked device mandates data structure for operation. Spec. ¶¶ 24–28, 29–36, 39–47 (depicting ordinary data transmissions among conventional devices). The claims do not recite any new data structure or protocol that changes how computers operate. Regarding Claim 7, consulting multiple backend systems to apply rules is a common technique in distributed networked systems. The claim does not recite any new data structure or protocol that changes how computers operate. Rather, it merely requires more data sources for the same abstract account management logic. Spec. ¶¶ 13, 36 (stating in general terms that the system may obtain/process data from multiple backend systems). An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Conclusion
Claims 1–4, 6, 7, and 15–20 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 1 otherwise styled as another statutory category is subject to the same analysis.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1–3, 6, 7, 15–17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mackouse (U.S. Pat. Pub. No. 2012/0109822) [“Mackouse”] in view of Barry et al. (U.S. Pat. Pub. No. 2009/0204516) [“Barry”] and further in view of Bloom et al. (U.S. Pat. Pub. No. 2021/0365922) [“Bloom”].
Regarding Claim 1, Mackouse discloses:
A system, comprising: a server [server] including one or more memories [database] and one or more processors [¶ 150, “microprocessors”]; and a client [¶ 150, “client terminal”] [… Bloom], are configured to:
(See at least ¶ Claim 5, “A transaction system … a central entity accessible through the network, the central entity comprising any of a terminal, a computer, a server, and a website, the central entity associated with any of an account issuer and a service provider that is associated with the account issuer; a database accessible to any of the account issuer and the service provider, comprising storage of a first set of rules associated with one or more accounts and controlled by any of the issuer and the service provider.”)
obtain account information associated with a set of accounts managed by an entity [Institutions 12];
(See at least Abstract, “An account is established for an account holder through a central entity, e.g. an issuer.” Customers may have more than one account, i.e., “accounts” for controlling security structures and processes for credit card accounts and check card accounts operating across a [payment] network.” ¶ 2. “Institutions 12, such as financial institutions (FI) 12 and/or other organizations 12 typically issue consumers or businesses USR with access "devices" (credit cards, debit cards etc.). Authorized users USR of such access devices 15 can then make purchases and/or obtain financial instruments remotely.” ¶ 38. Fig 12 discloses “Customer Account Storage,” “Financial Institution Rules 16,” and Customer Account Rules 160” being managed by an Institutional Issuer 12 to make purchases. The system obtains account information and rules when a customer makes a purchase. See also, ¶ 84 (updating “customer controllable parameters”.)
generate, based on the account information, a set of allowable transactions associated with the set of accounts and a set of rules that govern performance of the set of allowable transactions;
(See at least Abstract, “Use of the access devices is defined by a set of rules defined by the central entity and are controllable by the customer, including comprising any of the account holder and the user of the account. The customer inputs, controls, and/or updates
parameters associated with the customer-controllable rules. Subsequent authorization of the access devices is controlled based on the customer input and other controls.” “establishing a first set of rules associated with one or more financial accounts, the first set of rules established and controlled through any of a central terminal, an electronic system and a computing system; establishing a second set of rules associated with the financial accounts, the second set of rules customizable by a customer associated with a respective financial account, the customer comprising any of one of the account holders
and one of the users of the respective financial account” Claim 1. Fig, 6 discloses a “Setting Rules 280” GUI listing user-specified allowable transaction types as rule categories, such as allowing “Transactions Over $300” and not allowing “Gaming/Gambling”. Additionally, corresponding institutional rules 16 also govern performance of transaction. Fig. 5, element 160. Alternatively, see Berry, infra)
provide a graphical user interface (GUI) that displays the set of allowable transactions;
(See at least Fig. 6)
receive, via the GUI, user input indicating a selection of one or more allowable transactions, included in the set of allowable transactions, associated with one or more accounts included in the set of accounts;
(See at least Abstract, “The customer inputs, controls, and/or updates parameters associated with the customer-controllable rules.” See also, Fig. 4, step 208; ¶ 18. Fig. 6, element 290 specifically shows a specific rule entry of “Amazon <$200”.
Alternatively, to the extent Mackouse does not expressly disclose generating a set of allowable transactions based on account information, Berry discloses:
generate, based on the account information, a set of allowable transactions associated with the set of accounts and a set of rules that govern performance of the set of allowable transactions;
(See at least ¶ 77, The “memory system 14” stores “entity/organization data 28 (e.g., data defining: a governing entity, a dependent entity, etc), accounting rules/ data 15 ( e.g., data associated with: purchases, purchase types, rules for making purchases, accounting input forms, etc), and purchase type lists 27.” [collectively, the “claimed account information” Based on the “account information,” “Software application 18 generates an initial list of allowable purchase types. Only those purchase types configured for the governing entity are included.” ¶ 83; see also ¶ 99. The allowable purchases (transaction) correspond to specific general ledger (GL) accounts, which are the claimed “set of accounts.” After generating the allowable purchase transactions, “Software application 18 generates a list of valid general ledger (GL) account Ids (i.e., account numbers) from which the requester may select one.” ¶ 87. “Types of purchases which may be used (e.g.,
expense, capital, etc), scenarios that apply to various purchases (e.g., when expense applies vs. capital), and rules that govern which scenario is appropriate for a given purchase.” ¶ 74. “Software application 18 generates a modified list of allowable purchase types from the initial list of allowable purchase types. The set of purchase types configured in the modified list are sensitive to dependent entity rules.” ¶ 84.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined generate, based on the account information, a set of allowable transactions associated with the set of accounts and a set of rules that govern performance of the set of allowable transactions, as taught by Barry, to the known invention of Mackouse, in the same field of financial account transaction systems, with the motivation to improve Mackouse’s authorization system by proactively constraining permissible transaction types based on account-level rules before a transaction is submitted, rather than reactively declining transactions after the fact, thereby reducing the false positives Mackouse itself identifies as a key problem with existing systems. Mackouse, ¶ 10.
To the extent Mackouse does not expressly disclose, Berry discloses:
generate an account rule data structure that indicates the one or more allowable transactions and one or more rules, included in the set of rules, corresponding to the one or more allowable transactions; and … the account rule data structure not being generated in the one or more medium processing devices
(See at least ¶ 77, cited supra. The “accounting rules/data 15 (e.g., data associated with: purchases, purchase types, rules for making purchases, accounting input forms, etc)” stored in the memory system 14 and used by the system of Barry to generate allowable purchase type lists is the “Account rule data structure recited by the claims. “Software application 18 generates an initial list of allowable purchase types. Only those purchase types configured for the governing entity are included.” ¶ 83. The governing entity and dependent entity each define “types of purchases which may be used (e.g., expense, capital, etc.).” Spec. ¶ 74. The “purchase type lists 27” stored in memory system 14, derived from the accounting rules data, thus indicate the one or more allowable transactions. Spec. ¶ 77. The account rule data structure contains rules that correspond directly to each allowable purchase type. The governing entity defines “types of purchases which may be used (e.g., expense, capital, etc.), scenarios that apply to various purchases (e.g., when expense applies vs. capital), and rules that govern which scenario is appropriate for a given purchase.” Spec. ¶ 74. These rules are paired with and correspond to specific purchase types — precisely the “one or more rules … corresponding to the one or more allowable transactions” recited in the claim.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined generate an account rule data structure that indicates the one or more allowable transactions and one or more rules, included in the set of rules, corresponding to the one or more allowable transactions, as taught by Barry, to the known invention of Mackouse, in the same field of invention, with the motivation to accept data associated with two companies and provide a structured, per-transaction mapping of rules to allowable transaction types for both companies. Barry, ¶ 2. A person of ordinary skill would have been motivated to apply Berry’s structured rule-per-transaction architecture to Mackouse’s dual-rule account system as a predictable combination of known techniques yielding no more than expected results.
Mackouse does not disclose but Bloom discloses:
a client including one or more medium processing devices, wherein the one or more processors of the server, communicably coupled to the one or more memories, are configured to:
(See at least ¶ 67, “Machine (e.g., computer system) 700 may include a hardware processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, field programmable gate array (FPGA), or any combination thereof), a main memory 704 and a static memory 706, some or all of which may communicate with each other via an interlink (e.g., bus) 708.” ¶ 68, “The instructions 724 may also reside, completely or at least partially, within the main memory 704, within static memory 706, or within the hardware processor 702 during execution thereof by the machine 700.” Thus, Bloom discloses the server processor and memory coupling. ¶ 15, “The application 125 may provide access and functions to a user's financial account, such as account balances and performing actions such as transfers. The application 125 may include an account control dashboard 130 for controlling and providing criteria for allowable transactions with different services and vendors.” ¶ 27, “The settings described in FIGS. 1 and 2 may be communicated to a transactional server, such as a server associated with the accounts of the user.” Thus, Bloom also discloses a client and uniquely discloses the client including one or more medium processing devices. See also, Fig. 7.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mackouse’s central rule system having a network accessible central server with a processor account rule database, and client processing devices, using Bloom’s server processor and memory coupling and a client including one or more medium processing devices in a networked client architecture since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Mackouse discloses “a central entity accessible through the network” and “a database accessible to any of the account issuer and the service provider, comprising storage of a first set of rules associated with one or more accounts.” Mackouse, Claim 5. Bloom discloses:
provide, via a network, the account rule data structure to the one or more medium processing devices, … the account rule data structure … being sent in a one-way direction from the server;
(See at least ¶ 63, “The technique 600 may further include an operation to receive, at the user device, a generated personalized transaction rule.” The server to client transmission of the account rule data structure is a one-way direction from the server to the client. This limitation is surplusage and redundant of the claimed network provision from server to medium processing device.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined Mackouse’s and Berry’s centralized account rule storage and generating system with Bloom’s receipt of a personalized transaction rule, in the same field of invention, with the motivation to “identify trends, habits, or common practices of the user through the data of the previous transactions” (Bloom, ¶ 63) to prevent “fraudulent charges.” Bloom, ¶ 1.
Mackouse discloses “Subsequent authorization of at least one of the established access devices is then controlled based on the customer input and other controls.” ¶ 18. Bloom discloses:
wherein the one or more medium processing devices of the client are configured to: accept input regarding an input account; determine, based on the account rule data structure and the input account, a set of executable transactions at the client,
(See at least ¶ 15, “The application 125 may include an account control dashboard 130 for controlling and providing criteria for allowable transactions with different services and vendors.” ¶ 27, “The settings described in FIGS. 1 and 2 may be communicated to a transactional server, such as a server associated with the accounts of the user. The transactional server may be part of the account control system and may be operated by the account provider for managing transactions of the account holders. The transactional server may approve or decline requests for money, transactions, or requests for data. The approval may depend on factors such as an authentication of the requester and funds in the account the request is for. The approval may depend on the personal settings and preferences the user has provided, such as the settings found in the control dashboard 130 of the application 125.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined Mackouse’s and Berry’s centralized account rule storage and generating system with Bloom’s acceptance of input regarding an input account and determining, based on the account rule data structure and the input account, a set of executable transactions at the client, in the same field of invention, with the motivation to “receive input at a GUI of a user device for a set of personalized transaction rules for transactions with a service … for how their personal accounts may interact with services. The rules may be unique for each service. Each personal account may have different types of rules.” Bloom, ¶ 58.
Mackouse discloses “If the request 52 meets both the centralized, i.e. financial issuer rules 16 as well as the customer-controlled rules 160, the transaction is typically authorized.” Boom discloses:
execute a transaction in accordance with the set of executable transactions that are determined, and
(See at least ¶ 54, “The technique 500 includes an operation 506 to determine that the contextual data meets the respective transactional parameters of a personalized transaction rule of the set of personalized transaction rules.” ¶ 55, “The technique 500 includes an operation 508 to transmit, to the service, an indication of permission for the transaction request.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined Mackouse’s and Berry’s centralized account rule storage and generating system with Bloom’s execute a transaction in accordance with the set of executable transactions that are determined, in the same field of invention, with the motivation to “provide criteria for allowable and non-allowable transactions may assist in preventing fraudulent transactions.” Bloom, ¶ 12.
Mackouse discloses “a database accessible to any of the account issuer and the service provider, comprising storage of a first set of rules associated with one or more accounts.” Mackouse, Claim 5. Bloom discloses:
wherein the account rule data structure is remotely provided from the server and used at the client without setting the account rule data structure locally in the one or more medium processing devices.
(See at least ¶ 63, “The technique 600 may further include an operation to receive, at the user device, a generated personalized transaction rule. … The generated personalized transaction rules may then be automatically implemented or transmitted to the user device for approval by the user.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined Mackouse’s and Berry’s centralized account rule storage and generating system with Bloom’s account rule data structure being remotely provided from the server and used at the client without setting the account rule data structure locally in the one or more medium processing devices, in the same field of invention, with the motivation to “provide criteria for allowable and non-allowable transactions may assist in preventing fraudulent transactions.” Bloom, ¶ 12.
Regarding Claim 2, Mackouse, Barry, and Bloom disclose:
The system of claim 1 and the account information
Mackouse further discloses
wherein the account information includes one or more unique identifiers of the one or more accounts.
(See at least ¶ 66, “Each of a access devices 15 typically includes information that appears on the card 17, such as but not limited to an account number 185, a user name 186, indicia relating to card type 183, indicia 184 relating to the issuer 12, an expiration, i.e. good thru date 188, other information 190, and typically including encoded information, such as within a magnetic region, e.g. a stripe 192.”)
Regarding Claim 3, Mackouse, Barry, and Bloom disclose:
The system of claim 1 and the account information
Mackouse further discloses
wherein the account information is obtained from a backend system associated with the entity [“Wells Fargo”].
(See at least ¶ 131, ““the authorization request 52 is then sent for processing, e.g. 300, such as to the institutional issuer computer 12 or to a service provider computer 14 associated with the institutional issuer 12,” which accesses stored account data and rules to process the request. In FIG. 10, a back-end architecture comprising “Financial Institution Rules 272,” “Customer Account Rules 160,” and “Customer Account Storage 270,” all residing behind the network 20 and accessible to the institutional issuer 12 and service provider 14. The Institutional Issuer 12 is identified as “Well Fargo.” E.g., ¶ 126)
Regarding Claim 6, Mackouse, Barry, and Bloom disclose:
The system of claim 1 and the entity
Mackouse further discloses
wherein the entity is a financial institution.
(See at least ¶ 126, The Institutional Issuer 12 is identified as “Well Fargo.”
Regarding Claim 7, Mackouse, Barry, and Bloom disclose:
The system of claim 1 and the one or more rules require obtaining information
Mackouse further discloses
wherein the one or more rules require obtaining information from multiple backend systems.
(See at least ¶ 74, “the institutionally established set of rules 16, such as comprising the financial institution rules, the network rules, and/or rules that are based on the predictive models” These rules reside in and are obtained from the institutional issuer computer 12 (backend system #1). In FIG. 10, a back-end architecture comprising “Financial Institution Rules 272,” “Customer Account Rules 160,” and “Customer Account Storage 270,” all residing behind the network 20 and accessible to the institutional issuer 12 and service provider 14.
Regarding Claim 15, Mackouse discloses
A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a system, cause the system to:
(See at least ¶¶ 40, 63, 73, 74, 75, Figs. 5, 10)
The remaining limitations of Claim 15 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Mackouse, Barry, and Bloom for the same rationale presented in Claim 1 supra.
Regarding Claims 16, 17, and 20, Mackouse and Barry disclose:
The non-transitory computer-readable medium of claim 15.
The remaining limitations of Claims 16, 17, and 20 are not substantively different than those presented in Claims 2, 3, and 6, respectively, and are therefore, rejected, mutatis mutandis, based on Mackouse, Barry, and Bloom for the same rationale presented in Claims 2, 3, and 6, respectively, supra.
Claims 4, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mackouse, Barry, and Bloom and further in view of Nogin et al. (U.S. Pat. Pub. No. 2017/0352013) [“Nogin”]
Regarding Claim 4, Mackouse, Barry, and Bloom disclose:
The system of claim 1 and the one or more processors are configured
Mackouse discloses that the institutional issuer 12 maintains financial institution rules 272 and customer account rules 160, which is an account rule data structure that are stored and used by the issuer computer and service provider 14 to determine which transactions are allowed as explained above in more detail. Mackouse, ¶¶ 73–75; Claim 1. Mackouse discloses that “[s]ubsequent authorization of at least one of the established access devices is then controlled based on the customer input and other controls.” ¶ 18. Mackouse discloses the institutional issuer computer 12 and service provider 14 are a processing device with the entity that the account rules are provided for transaction processing. ¶ 131. Mackouse does not explicitly disclose a “rule data structure” or “medium processing device”. Thus, Mackouse does not disclose but Nogin teaches:
wherein the one or more processors are configured to: provide the account rule data structure to one medium processing device among the one or more medium processing devices, associated with the entity, that enables the one or more allowable transactions to be performed according to the one or more rules based on user input, or
(See at least ¶ 3, “The forms are, in turn, manually entered into a settlement rules data structure maintained by the payment network.” “At one or more regular or irregular intervals, or at some interval (or immediately) after receiving and/or storing the submission to the data structure 120, the rules engine 118 attempts to load the user's indicated parameters, in the form of settlement rules, to the settlement data structure 112. In particular, the rules engine 118 invokes a settlement data structure API, at 322. The settlement data structure API is a service-based API that enables customers (e.g., the issuer 108b, etc.) with active settlement profiles to retrieve and update their settlement parameters. The rules engine 118 employs the settlement data structure API to save a rule based on the submitted parameters to the working data structure 120, at 324. In turn, the payment network 106 uses the settlement data structure 112 in further settlement operations involving the issuer 108b … The API may provide data to the NSIF and/or other external programs in the form of Extensible Markup Language (XML) documents, JavaScript Object Notation (JSON) documents, or the like.” ¶ 63. “The memory 204 may be configured, as one or more data structures, to store, without limitation, issuer settlement profiles (e.g., biographical data, issuer preferences, etc.), acquirer settlement profiles (e.g., biographical data, acquirer preferences, etc.), transaction data, batch files, business rules, settlement procedures, internet-based interfaces ( e.g., as defined by internet-based applications, websites, etc.), and/or other types of data (and/or data structures) suitable for use as described herein.” ¶ 23. “[T]he rules engine 118 interacts with one or more users associated with the issuers 108a-c and/or the acquirers 104a and 104c in soliciting and/or receiving the parameters as described herein. As shown in FIG. 1, for example, the issuer 108b includes the user 122 (e.g., an employee, manager, administrator, etc.), associated with a workstation computing device 124 (consistent with computing device 200).” ¶ 32. “MasterCard will qualify only those cle0ring transactions that mast the selected clearing criteria for the given settlement setup.” Fig. 7. “The payment network 106 then settles the transactions by debiting funds from appropriate accounts at the issuer 108a ( as defined by clearing records received from the acquirer 104c) and crediting the funds to accounts associated with the acquirer 104c for the net amount of the transactions, less any interchange and/or network fees charged by the payment network 106.” ¶ 18. “the payment network 106 abides by established settlement procedures defined by settlement data structure 112” ¶ 19.
provide the account rule data structure to the one medium processing device among the one or more medium processing devices, associated with the entity, that enables the one or more accounts to be assigned to a user associated with the entity.
(For “provide the account rule data structure to the medium processing device, associated with the entity, that enables the one or more accounts” see rejection prior limitation. See at least Fig. 11. Which discloses a “Member Assignment” interface displaying “Account Assignment Input Source”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined provide the account rule data structure to a medium processing device [workstation computing device 124], associated with the entity, that enables the one or more allowable transactions to be performed according to the one or more rules based on user input and provide the account rule data structure to the medium processing device, associated with the entity, that enables the one or more accounts to be assigned to a user associated with the entity, as taught by Nogin, to the known invention of Mackouse, in the same field of invention, with the motivation for dynamic, user-driven settlement rules data structure and formal account assignment mechanisms, as Nogin expressly recognizes that managing rules through “complex and extensive static forms” was inefficient and that a dynamic rules engine would allow settlement procedures and account assignment to be “defined, at last in part, by the parameters” provided by the entity’s authorized user. Nogin, ¶¶ 3, 12.
Regarding Claim 18, Mackouse, Barry, and Bloom disclose
The non-transitory computer-readable medium of claim 15
The remaining limitations of Claim 18 are not substantively different than those presented in Claim 4 and are therefore, rejected, mutatis mutandis, based on Mackouse, Barry, Bloom, and Nogin for the same rationale presented in Claim 4 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 18.
Regarding Claim 19, Mackouse, Barry, and Bloom disclose
The non-transitory computer-readable medium of claim 15
The remaining limitations of Claim 19 are not substantively different than those presented in Claim 4 and are therefore, rejected, mutatis mutandis, based on Mackouse, Barry, Bloom, and Nogin for the same rationale presented in Claim 4 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 19.
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 JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/Primary Examiner, Art Unit 3694
1 Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
2 “It should be noted that these groupings are not mutually exclusive, i.e., some claims recite limitations that fall within more than one grouping or sub-grouping. … Accordingly, examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible, if a claim limitation(s) is determined to fall within multiple groupings and proceed with the analysis in Step 2A Prong Two.” MPEP § 2106.04(a).
3 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").
Prosecution Insights