Mapping Patent Evidence for Intelligent Coding Agents and Layered Knowledge

1. Background and Scope of the Report

Intelligent coding agents are evolving quickly. Public materials are often scattered across feature descriptions, demos, log excerpts, and configuration documents. Patent literature, by contrast, is organized around claims and emphasizes combinations of elements, step order, and technical effects. The two are not naturally one-to-one.

A coarse comparison based only on feature names can produce two errors: similar names with incomplete technical elements, or an observable function whose evidence chain cannot be fixed. A neutral, reviewable mapping method is therefore needed. Public capabilities should be broken into verifiable technical elements and compared, sentence by sentence, with the independent claims of high-priority patents and applications.

This report is an internal technical evidence draft. Its focus is infringement-lead screening and item-by-item claim comparison. It is not a final legal opinion. The goal is not to reach an infringement conclusion, but to answer three questions:

1. Which technical elements of granted patents have a strong functional correspondence with the public capabilities of intelligent coding agents?
2. Which patents are suitable as combination theories or second-layer support?
3. Which pending or filed applications should be treated only as reserve and tracking items, and should not be used as strong assertion entry points before grant?

2. Comparison Scope and Deliverables

This extension builds on the previous high-priority patent screen and produces three deliverables.

2.1 Sentence-Level Claim Comparison Table

For 13 high-priority patents and applications, the comparison uses claim 1 or the first independent claim and produces 109 element mappings. Each independent claim is split into its preamble, essential technical features, and step limitations. Every element is annotated with candidate evidence, evidence strength, missing evidence, and review comments.

Sentence-level decomposition prevents “overall functional similarity” from being treated as coverage of the technical elements. For example, a capability may appear in the interface as “automatic blocking,” while a claim may require rule evaluation based on policy context, generation of a blocking instruction, and output of an alternative result. Those requirements must be mapped separately to request entry, policy evaluation, blocking execution, and alternative output.

2.2 Evidence Screenshot Appendix

The evidence appendix has three parts: verified public web-page evidence panels, snapshots of claim pages from local patent or application files, and family and legal-status verification panels for granted patents.

Public web evidence should retain access time, page title, the location of key passages, and a hash of the redacted screenshot. Local claim-page snapshots should retain page numbers, claim numbers, and version information. Family and legal-status panels should record filing date, publication date, grant date, current status, claim version, and family members.

Screenshots should not retain identifiable third-party brand domains, account information, or command-line tool names. Cropping and masking should be used where necessary.

2.3 Family and Legal-Status Verification Table

Five granted Chinese invention patents are checked item by item against public patent-database pages. For eight pending or filed applications, the review only confirms that the uploaded materials match the summary table and clearly distinguishes cases whose public status was not independently verified.

The verification table should use status labels such as granted, substantive examination, unpublished, unverifiable, and materials consistent but status not verified. An unverified status must not be presumed to mean granted or not granted, and it must not be used as an established fact in an evidence-strength rating.

3. Abstracted Core Findings

The strongest current entry point among granted patents is the class covering content-compliance modeling and transmission methods. These patents have a relatively strong functional correspondence with the event hooks, permission rules, automatic modes, and sandbox control planes disclosed for intelligent coding tools.

They are especially suitable for fixing an evidence chain around “request entry, rule evaluation, blocking or adjustment, and out-of-bounds alert or alternative output.” The key is not a single feature, but a continuous sequence: the request enters with context; rules are evaluated against a policy set; execution blocks, degrades, or rewrites the request or output; and an out-of-bounds condition produces an alert and an alternative result.

Combination theories can cover continuous operations across the software lifecycle, including large-codebase analysis, version-update impact, testing, repair, and maintenance. Public evidence is still insufficient for elements such as multi-level knowledge-representation models and backup, authorization, or concept-space comparison.

Second-layer supporting patents correspond respectively to intent recognition and path derivation, and to graph updates and memory evolution. They are suitable as supplements, but stronger assertions still require more evidence about internal state structure, memory write-back format, plan or path representation, and relationship updates.

Among pending or filed applications, the themes closest to publicly described coding-tool capabilities include semantic security firewalls, semantic boundaries and control mechanisms, autonomous planning loops, multi-agent collaboration, and cross-task transfer. Before grant, these applications should be reserve and tracking items only, not strong assertion entry points.

4. Method and Procedure for Sentence-Level Mapping

Sentence-level mapping should follow a fixed procedure so that different reviewers can produce comparable results.

1. Identify the independent claim. Prefer claim 1 or the first independent claim, and record the published version and claim number.
2. Decompose the claim at sentence level. Number the elements E01, E02, and so on. Preserve the abstract meaning of the original wording without changing the technical features.
3. Build capability candidates. Extract matching capability descriptions, log fields, configuration items, process descriptions, and screenshot evidence from public materials.
4. Rate evidence strength. High strength requires mutually corroborating evidence from multiple sources. Medium strength means a functional correspondence without internal implementation evidence. Low strength is only a similarity in name or interface.
5. Record evidence gaps. State whether the missing item is time alignment, version alignment, policy content, execution result, or alternative output.
6. Review and redact. Remove information that identifies third-party brands, while retaining reviewable hashes and timestamps.

A mapping record can use the following structure:

{
  "claim_id": "independent-claim-01",
  "element_id": "E03",
  "claim_element_abstract": "On request entry, evaluate rules according to policy context",
  "evidence_candidates": [
    "Context fields in request-entry logs",
    "Rule-set description on the policy configuration page",
    "Screenshot of a decision node in the execution chain"
  ],
  "strength": "medium",
  "gap": "No time alignment between the policy version and the request log",
  "review_note": "Add a reproducible record under the same version"
}

This structure emphasizes the four-tuple of element, evidence, strength, and gap, which makes later evidence collection and cross-review easier.

5. Building the Control-Plane Evidence Chain

The sequence “request entry, rule evaluation, blocking or adjustment, and out-of-bounds alert or alternative output” is the most valuable evidence chain in an intelligent coding agent’s control plane. Evidence should be fixed at each stage.

5.1 Request Entry

Show that the request is not isolated text, but enters the processing chain with context. Fixable evidence includes entry logs, call-chain fragments, session identifiers, codebase version identifiers, and policy context. Times and versions must be consistent. Screenshots from different versions should not be joined into one chain.

5.2 Rule Evaluation

Show that a rule set or policy decision exists, rather than unrestricted model generation. Record the policy configuration page, rule-matching logs, decision-result fields, and matched rule identifiers. If public material only shows an “automatic mode,” mark it cautiously as functional-layer evidence. It cannot be equated directly with the rule evaluation required by a claim.

5.3 Blocking or Adjustment

Distinguish blocking, degradation, rewriting, and alternative output. Blocking refuses execution. Degradation reduces privileges or narrows scope. Rewriting changes the request or output. Alternative output provides a safe substitute result. Different actions correspond to different claim elements and should be evidenced separately.

5.4 Out-of-Bounds Alert or Alternative Output

An out-of-bounds alert should include the alert event, trigger condition, notification target, and audit record. Alternative output should include the output content, the basis for generating it, and its relationship to the original request. An alert-interface screenshot alone does not prove that a rule decision triggered the alert. Event logs and trigger conditions are also required.

6. Lifecycle Capabilities and Evidence Gaps in Supporting Patents

Large-codebase analysis, version-update impact analysis, testing, repair, and maintenance belong to continuous operations across the software lifecycle. Evidence commonly appears as analysis reports, impact-scope lists, generated test cases, repair suggestions, and change records. For a combination theory, fix “analysis, impact, testing, repair, and maintenance” as a continuous chain rather than capturing a single feature page.

Public evidence is currently insufficient for elements related to multi-level knowledge-representation models. If a claim involves multiple representation levels—such as data, information, knowledge, intent, and practice—the conversion relationships, storage structures, and usage patterns among those levels must be shown. Names such as “knowledge base” or “memory” cannot replace level structure and conversion rules.

Supporting patents on intent recognition and path derivation require internal state structure, plan representation, and the basis for path selection. Supporting patents on graph updates and memory evolution require memory write-back formats, relationship-update rules, and version-evolution records. If public evidence shows only a “plan list” or a “memory summary,” rate it low to medium and list the additional evidence required.

7. Standardizing Family and Legal-Status Verification

A family and legal-status table should include at least the document identifier, filing date, publication date, grant date, current legal status, claim version, family members, verification date, reviewer, and notes.

For granted patents, compare the granted text with the published text item by item. For pending or filed applications, state explicitly that the materials are consistent but public status was not independently verified. Information in a summary table must not be treated as public status.

The main risk is version mismatch. Comparing claims from an early published text with later product evidence may miss amendments made before grant. Every mapping record should therefore be bound to a claim version, and review should check whether the text has been updated.

8. Managing Pending Applications and Compliance Boundaries

Pending or filed applications are suitable for a tracking matrix. Fields should include technical theme, independent-claim summary, publication status, evidence maturity, priority for additional evidence, and review cycle. Reserve management is not a way to reach conclusions early. It maintains technical tracking and evidence accumulation.

For semantic security firewalls, semantic boundaries and control mechanisms, autonomous planning loops, multi-agent collaboration, and cross-task transfer, record the correspondence with existing public capabilities and mark each item as “reserve only before grant.”

For compliance, all evidence should come from lawful sources, be sufficiently redacted, and be traceable in time. Internal logs that may contain trade secrets should be authorized and minimized. Public web evidence should not retain identifiable third-party brand domains or account information. Technical review and legal review should remain separate: the technical side handles element mapping and evidence strength, while the legal side handles claim interpretation and the final judgment.

9. Conclusion

The core of mapping intelligent coding agents to layered-knowledge patent evidence is not a list of feature names. It is a closed loop of claim element, public capability, evidence chain, gap, and review.

Granted patents on content-compliance modeling and transmission can serve as the strongest entry point, with evidence fixed around the continuous steps of the control plane. Lifecycle-operations patents are suitable for combination use, but evidence for multi-level representation and comparison mechanisms still needs to be supplemented. Intent-path and memory-evolution patents can provide second-layer support. Pending applications should continue to be tracked as reserve items.

Sentence-level mapping, an evidence appendix, and legal-status verification together can substantially improve the reviewability and decision value of the comparison while remaining neutral and compliant.