Office Action Analysis — App 19629591 (public record)

Candidate arguments for counsel, ranked strongest-first. Each names the limitation it hangs on, the argument for the record with pin-cites, the MPEP frame, and what the examiner is likely to say back. These are brainstorming inputs for counsel to evaluate — not a drafted response.

1. [Eligibility rebuttal]: Claim 7 — cryptographic attestation on a distributed ledger as a concrete technical feature, not mere data output

Claims addressed: 7

Limitation hook: generate a cryptographic attestation of a routing decision that identifies the at least one AI agent of the selected AI agent set; and maintain the cryptographic attestation in a distributed ledger

For counsel to weigh: the examiner characterizes the cryptographic-attestation and distributed-ledger limitations of claim 7 alternately as 'apply it' instructions, mere data output, and extra-solution activity. Counsel may argue instead that generating a cryptographic attestation of a routing decision and maintaining it in a distributed ledger is a specific, non-generic technical operation that provides verifiable integrity/auditability of the routing decision, supporting integration into a practical application at Step 2A Prong Two (MPEP § 2106.05(e)) or an inventive concept at Step 2B (MPEP § 2106.05(d)). The examiner's treatment moves the same limitation across multiple rationales ('apply it,' data output, extra-solution) without addressing it as an ordered part of the claimed routing process, which counsel can press as internally shifting and conclusory. This is a claim-7-specific fallback that survives even if the independent-claim eligibility arguments do not carry the day.

Supporting evidence:

• Office action (claim 7, Prong Two): the attestation elements 'amounts to no more than adding the words "apply it" to the judicial exception' and 'amounting to mere data output (see MPEP 2106.05(g)).'
• Office action (claim 7): 'a distributed ledger which is recited at a high-level of generality and amounts to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)).'
• Claim 7: 'generate a cryptographic attestation of a routing decision that identifies the at least one AI agent of the selected AI agent set; and maintain the cryptographic attestation in a distributed ledger.'

Doctrine: MPEP § 2106.05(e) (practical application) and § 2106.05(d) (Berkheimer support for any WURC finding as to the ledger/attestation)

Examiner's likely response / risk: The examiner will likely respond that distributed ledgers and cryptographic attestations are known generic components merely invoked at a high level, and that recording a decision is post-solution data output. Prosecution-history caution: emphasizing the security/integrity purpose may narrow how 'cryptographic attestation' and 'distributed ledger' are later construed.

Evidence needed: Cite as-filed specification passages describing the technical function and benefit of the cryptographic attestation and distributed-ledger recordation; that spec text is not included in the record provided here.

2. [Eligibility rebuttal]: Step 2B — unsupported 'well-understood, routine, conventional' finding (Berkheimer evidentiary gap)

Claims addressed: 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20

Limitation hook: obtain an input for generation of an output using one or more AI agents ... cause transmission of the input to at least one AI agent of the selected AI agent set (claim 6); and dependent additional elements (cryptographic attestation / distributed ledger — claim 7; persistent memory structure — claim 8)

For counsel to weigh: the examiner's Step 2B conclusion that the additional elements are well-understood, routine, and conventional rests on citations to MPEP 2106.05(d)(II) generic categories ('receiving or transmitting data over a network,' 'electronic record keeping,' 'storing and retrieving information in memory') without any factual support tied to these claims. Under Berkheimer (MPEP § 2106.05(d)), a conclusion that a claim element is WURC must be supported by one of the four evidentiary showings — a citation, a court holding, an express applicant admission, or an official-notice-type finding — and an unsupported conventionality assertion is a defect counsel can press. This lever is available at least for the distributed-ledger/cryptographic-attestation limitation of claim 7 and the persistent-memory limitation of claim 8, which the examiner swept into generic 'record keeping'/'storing and retrieving' categories without record evidence that a cryptographic attestation maintained in a distributed ledger is conventional in this context. Counsel can request that the examiner supply the Berkheimer support or withdraw the WURC finding.

Supporting evidence:

• Office action Step 2B (claim 6): 'The courts have found limitations directed to obtaining information electronically, recited at a high level of generality, to be well-understood, routine, and conventional (see MPEP 2106.05(d)(II) ...).'
• Office action (claim 7): the cryptographic attestation and distributed ledger are characterized as 'extra-solution activity' and 'electronic record keeping' without a supporting evidentiary citation
• Claim 7: 'generate a cryptographic attestation of a routing decision ... and maintain the cryptographic attestation in a distributed ledger.'

Doctrine: MPEP § 2106.05(d) — Berkheimer: a WURC finding at Step 2B must be evidentiarily supported (citation, court holding, applicant admission, or official notice)

Examiner's likely response / risk: The examiner may cure the gap by supplying a citation or taking official notice that transmitting data and electronic record-keeping (including ledgers) are conventional, which would shift the burden back to applicant. Note also that the examiner may respond that the hashing/comparison steps are part of the abstract idea (not 'additional elements') and thus not subject to Berkheimer — counsel should target the genuine additional elements (transmission, storage, ledger, attestation).

3. [Eligibility rebuttal]: Step 2A Prong Two — hash-signature agent routing as a practical application / technical improvement

Claims addressed: 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20

Limitation hook: determining an input signature by applying one or more hash functions to the feature set ... access, for each AI agent ... an associated agent signature generated by applying the one or more hash functions to a description of a computer-executable operation set ... compare the input signature to the accessed agent signatures to select one or more AI agents (claim 6; parallel fingerprint language in claim 13)

For counsel to weigh: the claims recite a specific ordered mechanism — reducing an input to a hash-derived signature/fingerprint, accessing precomputed agent signatures each generated by applying the same hash functions to a description of an AI agent's operation set, and comparing signatures to route the input — which counsel may argue integrates any recited exception into a practical application under Step 2A Prong Two (MPEP § 2106.05(a)/(e); Enfish; McRO). The point to develop is that the claimed signature-comparison routing is a particular technical way of selecting among AI agents, not merely a result recited at a high level of generality. The examiner's Step 2A Prong Two treats the hashing and signatures as merely 'generally linking the use of the judicial exception to a particular environment' (office action, MPEP 2106.05(h) discussion), which counsel can contest as failing to address the claim as an ordered combination. Counsel should anchor this argument to specific specification passages describing the technical benefit of signature-based routing (e.g., routing efficiency or scalability) before relying on it.

Supporting evidence:

• Office action Step 2A Prong Two (claim 6): 'The recitation of AI agents, input signature, and hash function amounts to generally linking the use of the judicial exception to a particular environment of field of use (See MPEP 2106.05(h)).'
• Claim 6: 'determining an input signature by applying one or more hash functions to the feature set' and 'compare the input signature to the accessed agent signatures to select one or more AI agents from the plurality of AI agents'
• Claim 13 parallel: 'determine an input fingerprint by applying one or more sets of hash functions to the feature set'

Doctrine: MPEP § 2106.05(a) (improvement to technology / computer functioning) and § 2106.05(e) (integration into a practical application); Step 2A Prong Two — integration ends the eligibility inquiry

Examiner's likely response / risk: The examiner will likely respond that the claims recite only a desired result (select an agent) using generic hashing, and that no specific technical improvement is claimed rather than merely described. Prosecution-history caution: characterizing the invention narrowly as 'signature-based routing for efficiency' may narrow claim scope in the file wrapper and could later be used to limit the term 'signature'/'fingerprint' or 'hash function'; counsel should frame the improvement carefully.

Evidence needed: Identify and cite specific as-filed specification passages establishing the concrete technical improvement (e.g., routing accuracy, latency, or scalability) that the signature-comparison mechanism provides; the office-action record supplied here does not include that spec text.

4. [Eligibility rebuttal]: Step 2A Prong One — hashing and bitwise distance computation are not practically performed in the mind

Claims addressed: 6, 9, 12, 13

Limitation hook: determining an input signature by applying one or more hash functions to the feature set (claim 6); perform a bitwise operation between the input signature and an agent signature to determine a distance value (claim 9); the one or more hash functions comprise locality-sensitive hash functions (claim 12)

For counsel to weigh: the examiner's Prong One characterization equates 'applying one or more hash functions' to a human 'determin[ing] a distinct identifier' and 'compar[ing] a current signature to past signature,' but counsel can argue these lay analogs substitute a simplified mental task for the actual claimed operation. Applying hash functions (and, in claim 12, locality-sensitive hash functions) to a feature set to generate a signature, and in claim 9 performing a bitwise operation to compute a distance value, are operations that a person cannot practically perform in the mind or with pen and paper (MPEP § 2106.04(a)(2)(III)(C) — the mental-process grouping does not cover concepts that cannot practically be performed in the human mind). The point for counsel is that the examiner's own examples ('a human can determine a distinct identifier') do not correspond to computing a hash or a bitwise Hamming-type distance over signatures. This attacks whether the claim actually 'recites' a mental process at Prong One rather than merely resembling one.

Supporting evidence:

• Office action Prong One (claim 6): 'determining an input signature by applying one or more hash functions to the feature set ... For example, a human can determine a distinct identifier for each and every AI agent.'
• Claim 9: 'perform a bitwise operation between the input signature and an agent signature to determine a distance value; and select an AI agent based on the distance value satisfying a threshold.'
• Claim 12: 'wherein the one or more hash functions comprise locality-sensitive hash functions.'

Doctrine: MPEP § 2106.04(a)(2) — mental-process grouping; a limitation that cannot practically be performed in the human mind is not a mental process (Step 2A Prong One)

Examiner's likely response / risk: The examiner will likely respond that under BRI the claim does not preclude a simple/trivial hash that a human could compute, and that reciting a generic 'hash function' at a high level keeps it within the mental-process grouping. Prosecution-history caution: arguing the hashing is computationally complex may invite an argument that simpler embodiments fall outside the claim; counsel should avoid statements that read a complexity requirement into 'hash function.'

5. [Eligibility rebuttal]: Claim 9 — bitwise distance thresholding as a specific machine-implemented comparison, not an abstract 'apply it'

Claims addressed: 9

Limitation hook: perform a bitwise operation between the input signature and an agent signature to determine a distance value; and select an AI agent based on the distance value satisfying a threshold

For counsel to weigh: the examiner treats the claim 9 bitwise-operation/distance-value limitation as an 'apply it' instruction and 'mere data output,' but counsel may argue that computing a distance value by a bitwise operation between signatures and gating selection on a threshold is a concrete, machine-specific comparison technique that contributes to a practical application rather than a mental judgment. This limitation also reinforces the rank-3 Prong One point that the claimed comparison is a defined computational operation, not the examiner's generalized 'compare a current signature to past signature.' Note the internal record discrepancy: the office action's claim 9 analysis references 'a distributed ledger,' a component that does not appear in claim 9, suggesting the analysis was not tailored to the actual claim language — a point counsel can flag to press for a claim-specific eligibility analysis.

Supporting evidence:

• Office action (claim 9): the bitwise-operation limitation 'amounts to no more than adding the words "apply it" to the judicial exception ... amounting to mere data output (see MPEP 2106.05(g)).'
• Office action (claim 9) mismatched reference: 'The claim further recites a distributed ledger which is recited at a high-level of generality' — no distributed ledger appears in claim 9.
• Claim 9: 'perform a bitwise operation between the input signature and an agent signature to determine a distance value; and select an AI agent based on the distance value satisfying a threshold.'

Doctrine: MPEP § 2106.05(e) (practical application) / § 2106.04(a)(2) (whether the comparison is practically a mental process); note claim-specific-analysis requirement under MPEP § 2106.07(a)

Examiner's likely response / risk: The examiner will likely respond that a bitwise distance calculation is a mathematical/comparison concept and that thresholding to select is a routine decision, both within the abstract idea. The distributed-ledger discrepancy may be corrected as a harmless typographical error rather than a substantive defect.

6. [Eligibility rebuttal]: Claim 14 — embedding-model feature extraction as more than an 'apply it' instruction

Claims addressed: 14

Limitation hook: wherein determining the feature set from the input comprises applying an embedding model to a representation of the input

For counsel to weigh: the examiner dismisses the claim 14 embedding-model limitation as recited at a high level of generality amounting to 'apply it' / mere use of a computer as a tool. Counsel may argue that applying an embedding model to a representation of the input is a specific machine-learning feature-extraction technique that is part of the technical routing pipeline, supporting a practical-application or inventive-concept position for the dependent claim, and that the examiner made no factual finding that embedding-model-based feature extraction is conventional in this context (Berkheimer gap, MPEP § 2106.05(d)). This is a narrow dependent-claim fallback and its strength depends on specification support describing the embedding model's role and benefit.

Supporting evidence:

• Office action (claim 14): the embedding-model limitation 'is recited at a high-level of generality with no detail of the applying an embedding model process and amounts to no more than adding the words "apply it" ... or merely uses a computer as a tool to perform an abstract idea.'
• Claim 14: 'wherein determining the feature set from the input comprises applying an embedding model to a representation of the input.'

Doctrine: MPEP § 2106.05(e) (practical application) and § 2106.05(d) (unsupported conventionality); § 2106.05(f) ('apply it' analysis)

Examiner's likely response / risk: The examiner will likely respond that 'an embedding model' is claimed generically with no disclosed algorithmic detail, so it merely uses a computer as a tool. Prosecution-history caution: arguing specificity of the embedding model may invite a narrowing construction of 'embedding model' or an argument that the independent claims (which lack it) are broader and remain abstract.

Evidence needed: Cite as-filed specification passages detailing the embedding-model implementation and its technical contribution; that text is not part of the record provided here.