US 11379651

US patent 11379651, titled "Methods and systems for interactive content creation," was filed on June 15, 2021, and issued on July 5, 2022. The original assignee was Turtl Surf and Immerse Ltd, which also remains the current assignee following a corrective assignment on October 28, 2024. Nicholas Kingsley Mason is the inventor.

Abstract:
The patent describes a system for personalizing interactive content. This system includes a content creation component that creates modular content items for a document, with at least one item having rules defining links to other documents or assembly instructions for a personalized document. A content personalization component receives personalization instructions, assembles multiple modular content items from various documents based on these rules, and then renders the resulting personalized document using a specified brand style.

Plain-language overview of independent claims:

The provided patent text does not explicitly list numbered claims, but the "Summary" section outlines two primary aspects which typically correspond to the independent claims:

1. System for Automatically Assembling an Interactive Document: This system comprises a server connected to user devices over a network. The server is configured to embed a first set of rules into a modular item of a first document. It then receives parameters for personalizing the first document, and based on these parameters and the embedded rules, pulls a second modular item from a second document. Finally, it assembles this second modular item with the first document to create a new, personalized "derivative document".
2. System for Personalizing an Interactive Document: This system includes two main components. A first component creates modular content items for a document, where at least one item contains rules that define a link to another document or dictate how it should be assembled into a derivative document. A second component receives instructions for personalizing a specific document. It then assembles various modular items from the given document and other documents, guided by the rules associated with the modular items of the given document, to generate a derivative document. This derivative document is then rendered using a style associated with the original document.

Litigation Status:
As of April 26, 2026, the patent US11379651B1 is listed as "Active". The Google Patents record indicates that "Family has litigation" and that "First worldwide family litigation filed". A link to Darts-ip is provided for more details on this litigation. Searching the CAFC 2026 dockets for patent number 11379651 did not return any direct results as of April 26, 2026. This suggests that while there may be litigation involving the patent family, it might not be a direct appeal case in the CAFC for 2026, or the public docket information is not yet available through standard searches. Further investigation into the Darts-ip record would be necessary for specific litigation details.

I'll search for litigation involving US patent 11379651 across patent litigation databases, court dockets, and legal news sources.

Initial results reveal PTAB activity. Let me dig deeper into district court litigation and verify the specific patent-owner party.

Litigation Involving US Patent 11379651 (the '651 patent)

Bottom line

No district-court (or ITC) litigation naming US Patent 11379651 as an asserted patent could be confirmed from the sources searched. The patent's own Google Patents record carries the flag "Family has litigation / First worldwide family litigation filed" with a Darts-ip link, but that indicator is family-level and does not identify the specific patent, plaintiff, or forum. I could not retrieve the underlying Darts-ip record.

What the searches did surface is closely related PTAB activity and strong circumstantial evidence of a parallel district-court dispute — but over a different patent in the same family, not the '651 patent specifically. Details below, with the caveat that I was cut off mid-search and some follow-ups went unanswered.

---

1. Confirmed proceedings (PTAB — not district court)

Only IPR2026-00404 directly targets US 11,379,651. Grounds as reported by the Ex Parte petition analysis: claims 1–6, 8–10, 13–20 obvious over Harrop (WO 03/075191) in view of Hailey (US 2005/0080814); claims 11–12 further in view of Davis (US 5,796,952); claim 7 further in view of Lo (US 2005/0094205).

Sources: Ex Parte – IPR2026-00404 summary; Docket Alarm – IPR2025-01525; Docket Alarm blog – IPR2026-00403

---

2. Circumstantial evidence of a district-court case (patent not identified as the '651)

The IPR2025-01525 petition (Foleon v. Turtl, over US 12,118,290) states verbatim that "Petitioner has been accused of infringing the '290 Patent and is proactively seeking early cancellation..." This is a direct admission that Foleon is a defendant in an infringement action brought by Turtl. The accused patent in that action is US 12,118,290 — a continuation-family member of the '651 patent — not US 11,379,651.

I was unable to obtain the case caption, court, or docket number for that district-court action before the searches were cut off. No district-court docket naming US 11,379,651 was returned.

---

3. What I could NOT confirm (explicitly, per your instruction)

• Plaintiff, defendant, jurisdiction, case number, filing date, and status for any case asserting US 11,379,651 — none found.
• The Darts-ip "family litigation" record — not retrieved (subscription source).
• Whether Foleon's accused product is at issue under the '651 specifically, or only under the '290.
• §102/§103 prior art beyond the IPR petition grounds above.

---

4. Contradiction to flag against the previously generated "PTAB challenges" section

The prior section identified the proceeding as "IPR2026-00404 — Foleon Inc. et al. v. Nicholas Kingsley Mason." The search results contradict that caption on two points:

1. Patent owner is Turtl Surf & Immerse Limited, not inventor Nicholas Kingsley Mason. The Rule 42.10(b) power of attorney in the sibling IPR2025-01525 is signed by Nick Mason as CEO for Turtl Surf & Immerse Limited, and the PTAB caption reads "FOLEON INC., Petitioner, v. TURTL SURF & IMMERSE LIMITED, Patent Owner." (Note: in an IPR the named "patent owner" is the record owner; here that is Turtl.)
2. The prior section also stated the challenged patent's title as "Document Assembly Systems and Methods." That title belongs to US 12,118,290 (the '290 patent), not US 11,379,651, whose title is "Methods and systems for interactive content creation." The Ex Parte summary appears to have propagated this title mismatch for IPR2026-00404.

The filing date (2026-07-16) and challenged claims (1–20) in the prior section are consistent with the new results.

---

5. Recommended verification steps

1. Foleon Inc. v. Turtl Surf & Immerse Ltd / Limited — search PACER and Docket Navigator / Unified Patents' caselist for a district-court docket; establish whether US 11,379,651 is an asserted patent or whether only the '290 is.
2. Darts-ip family record (family=80003088) for the "family litigation" entry that Google Patents flags.
3. USPTO Patent Center / PTAB API for the IPR2026-00404 docket to confirm the challenged patent number and owner caption directly.

Caveat: My searches were truncated before I could run the follow-up queries (Turtl v. Foleon docket lookup, IPR2026-00403 patent identification, and a targeted "11,379,651" litigation query). The absence of a confirmed district-court case naming the '651 patent therefore reflects search limits as much as absence of litigation, and should be re-verified before being relied upon.

Proceedings overview

There is one active AIA trial proceeding on file for US patent 11379651. This Inter Partes Review (IPR) is currently in the preliminary stages, with the petition recently filed and the institution decision pending. This means the patent's claims are currently challenged but no final determination on validity has been made by the PTAB.

IPR2026-00404 — Foleon Inc. et al. v. Nicholas Kingsley Mason

• Type: Inter Partes Review
• Filed: 2026-07-16
• Status: Pending. The petition was recently filed, and the PTAB has not yet made a decision on whether to institute the IPR.
• Judge panel: The judge panel has not yet been made public at this early stage of the proceeding.
• Petition grounds: Details regarding the specific claims challenged, prior art references, and statutory bases (§ 102 / § 103 / § 112) of the petition are not publicly available from the provided information due to the very recent filing date.
• Institution decision: Not yet issued. The PTAB has approximately six months from the filing date to issue a decision on institution.
• Final Written Decision (if issued): Not applicable, as the IPR has not yet been instituted.
• Settlement / termination: Not applicable at this stage.
• Appeal: Not applicable at this stage.
• Defensive value: This proceeding indicates that Foleon Inc. et al. believe there are grounds to challenge the patent's validity. For a defendant, this means the patent is currently under PTAB scrutiny, and there is a possibility that claims could be invalidated. However, until an institution decision is made and, if instituted, a Final Written Decision is issued, all claims remain presumptively valid.

Strategic summary

As of the current date, all claims of US patent 11379651 are currently UNTESTED by a final PTAB decision. The patent is the subject of a newly filed Inter Partes Review, IPR2026-00404, by Foleon Inc. et al. Since the petition was just filed on 2026-07-16, the PTAB has not yet determined whether to institute the trial. Therefore, no claims have been canceled or definitively sustained by the PTAB.

Regarding estoppel, if IPR2026-00404 is instituted and proceeds to a Final Written Decision, Foleon Inc. et al. (and any parties in privity with them) would be estopped under 35 U.S.C. § 315(e)(2) from asserting in future litigation that a claim is invalid on any ground that the petitioner raised or reasonably could have raised during the IPR. Until then, the full range of prior art grounds remains available to other potential defendants. It is too early to discern any patterns regarding multiple IPR filings on this patent or aggressive PTAB appeal strategies by the patent owner, as this is the first and only PTAB proceeding recorded.

Recommended next steps

For a defendant facing assertion of US patent 11379651, the primary recommended next step is to closely monitor IPR2026-00404. The most critical upcoming milestone is the institution decision, which is expected around 2027-01-16 (six months from the petition filing date). A decision to institute would signal that the PTAB believes there is a reasonable likelihood that at least one claim is unpatentable, increasing the potential for claims to be invalidated. If the IPR is instituted, reviewing the institution decision will provide insight into the specific claims and prior art grounds the PTAB has accepted for trial.

Inventors

Nicholas Kingsley Mason is the sole named inventor. The patent does not explicitly state his employer at the time of filing.

Original assignee

The original assignee is Turtl Surf and Immerse Ltd. Based on the patent's description, which focuses on "methods and systems for interactive content creation" and mentions "digital magazines, case studies, product guides, sales playbooks," it appears Turtl Surf and Immerse Ltd is an operating company developing software and services in the interactive content space. The current legal status of the patent is "Active," and Turtl Surf and Immerse Ltd remains the current assignee, indicating it is likely still an operating entity.

Assignment timeline

• 2021-07-30 (executed) / recorded 2021-07-30 — Reel 057462/0058

  • Conveyance: Assignment of Assignors Interest
  • Assignor: MASON, NICHOLAS KINGSLEY
  • Assignee: Turtl Surf & Immerse Limited
  • Correspondent: BRENT JOHNSON, P.O. BOX 1071, LOS ALTOS, CA 94023
  • Context: Transfer from inventor to original assignee

• 2023-05-26 (executed) / recorded 2023-05-26 — Reel 060515/0501

  • Conveyance: Security Interest
  • Assignor: Turtl Surf & Immerse Limited
  • Assignee: SILICON VALLEY BANK UK LIMITED
  • Correspondent: BRENT JOHNSON, P.O. BOX 1071, LOS ALTOS, CA 94023. This correspondent recurs.
  • Context: Securitization of assets for a loan

• 2024-10-28 (executed) / recorded 2024-10-28 — Reel 063688/0001

  • Conveyance: Corrective Assignment
  • Assignor: MASON, NICHOLAS KINGSLEY
  • Assignee: Turtl Surf & Immerse Limited
  • Correspondent: BRENT JOHNSON, P.O. BOX 1071, LOS ALTOS, CA 94023. This correspondent recurs.
  • Context: Correction of a previous assignment from inventor to original assignee

Timeline diagram

timeline
    title Ownership of US 11379651
    2021 : Filed by Turtl Surf and Immerse Ltd
         : Assigned from Inventor Mason to Turtl Surf & Immerse Ltd
    2022 : Issued
    2023 : Security Interest to Silicon Valley Bank UK
    2024 : Corrective Assignment from Inventor Mason to Turtl Surf & Immerse Ltd

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent has remained with Turtl Surf and Immerse Ltd, an operating company. Transfers were from the inventor or for security purposes.
2. Known asserter in the chain — not present. None of the named assignees (Turtl Surf & Immerse Limited, SILICON VALLEY BANK UK LIMITED) are on common public NPE lists.
3. Repeat correspondent across the chain — present. BRENT JOHNSON, P.O. BOX 1071, LOS ALTOS, CA 94023, appears as the correspondent for all three recorded assignments (Reel 057462/0058, Reel 060515/0501, and Reel 063688/0001). This consistency in correspondent for different types of assignments (inventor assignment, security interest, corrective assignment) is a signal.
4. Cascading transfers — not present. There are only three assignments recorded over a period of several years, and they are not consecutive transfers through different LLCs.
5. Pre-litigation transfer — unclear. While the Google Patents record indicates "Family has litigation," no specific lawsuit filing dates naming this patent were found to compare against the assignment dates. Therefore, it's not possible to determine if any assignment preceded litigation within a 6-month window.
6. Bankruptcy fire-sale — not present. There is no indication that Turtl Surf and Immerse Ltd has filed for bankruptcy. The security interest with Silicon Valley Bank UK Limited is a normal business transaction, not necessarily indicative of bankruptcy.
7. Privateering — not present. No evidence from SEC filings or other sources suggests a privateering arrangement.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at any known defensive aggregators.

Verdict

Insufficient data. While there is a repeat correspondent, which can sometimes be a signal for NPE activity, the patent currently remains with the original operating assignee, Turtl Surf & Immerse Limited. There are no shell-entity transfers, known NPE assignees, or cascading transfers. The litigation status is unclear from public records regarding this specific patent, making it impossible to assess pre-litigation transfer signals. More information about the "family litigation" would be needed to make a more definitive assessment.

Verification: USPTO Assignment Center search for US11379651

To identify the most relevant prior art for US patent 11379651, I need to access the full patent document, specifically its "References Cited" section. The provided text is the full patent text, so I will analyze it directly.

Understanding Anticipation (35 U.S.C. § 102)

Anticipation under 35 U.S.C. § 102 means that an invention is "not novel" because every element of the claimed invention is found, either expressly or inherently described, in a single prior art reference that was publicly available before the effective filing date of the claimed invention. The elements must be arranged as required by the claim. If a prior art reference discloses a method that, when followed, inevitably produces the claimed invention, it can inherently anticipate the claim.

Analysis of Cited Prior Art for US11379651:

The patent text provided explicitly states:

"This application claims the priority and benefit of U.S. Provisional Application No. 63/048,512 filed on Jul. 6, 2020, the entire contents of which is incorporated herein by reference."

This provisional application is the primary prior art identified by the patent itself. Since it is a provisional application that this patent claims priority from, it generally would not anticipate the claims of this patent under 35 U.S.C. § 102, as long as the claims of US11379651 are fully supported by the provisional application. Instead, it serves as the priority document. Prior art for anticipation would typically come from earlier, distinct disclosures.

The provided patent text does not list any other "References Cited" from the patent examination process (e.g., U.S. Patents, Foreign Patent Documents, or Other Publications). Therefore, based on the provided document, the only explicit "prior art" reference is the provisional application from which it claims priority, which is not used for 35 U.S.C. § 102 anticipation against its own claims.

Conclusion on Most Relevant Prior Art (based solely on the provided patent text):

Based only on the full patent text provided, the patent US11379651 does not explicitly list any prior art references that were cited against its claims during prosecution (e.g., in a "References Cited" section). The only reference mentioned is U.S. Provisional Application No. 63/048,512, filed on July 6, 2020, which is a priority document and not typically used for anticipation under 35 U.S.C. § 102 against the claims of the patent claiming its benefit.

To perform a comprehensive prior art analysis for potential anticipation under 35 U.S.C. § 102, I would need to access the full prosecution history of US11379651, typically found in the USPTO's Patent Center or Patent Public Search tool, to review the Examiner's citations and any prior art submitted by the applicant. This information is not present in the provided patent grant document.

Based on the "Prior Art" section provided, US patent 11379651 does not explicitly list any prior art references that were cited against its claims during prosecution, other than its own priority document (U.S. Provisional Application No. 63/048,512).

An obviousness analysis under 35 U.S.C. § 103 requires identifying a combination of at least two prior art references, or a single reference combined with general knowledge in the art, that would have made the claimed invention obvious to a person having ordinary skill in the art (PHOSITA) at the time of the invention. This analysis also requires identifying a motivation to combine those references and a reasonable expectation of success.

Since the provided patent text does not include a "References Cited" section listing distinct prior art documents, and the only other reference is a priority document (which cannot be used for obviousness against its own claims), it is not possible to perform an obviousness analysis under 35 U.S.C. § 103 with the information currently available.

To conduct a proper obviousness analysis, access to the full prosecution history of US11379651 and any prior art cited by the examiner or applicant would be necessary.

I'll research this patent's term and family data through web searches, prioritizing authoritative sources.

Let me dig into the family members and the PTA/term details specifically.

Key finding located. Let me verify the front-page notice details and the terminal disclaimer target.

Patent Term, Continuity, and Family — US 11,379,651 (Application 17/347,899)

Scope note: I searched for the specific number 11379651. I deliberately did not return results for similar numbers (e.g., 11361144, 11755816, 12118290 are treated below only as family members of this patent, because the searches surfaced them as such — they are not substitutes for the target patent). One important caveat up front: several searches returned PTA/continuity content that is not specific to this patent (MPEP §2700, 35 U.S.C. §154, case law on Novartis/Supernus, and unrelated prosecution histories). I have discarded those and relied only on records that literally identify US 11,379,651 or its application/family.

---

1. Bibliographic verification (from the patent's own front page)

Source: patent PDF, https://patentimages.storage.googleapis.com/94/95/9e/724ec47b5419e4/US11379651.pdf (Figure/front page reproduced)

---

2. Patent Term Adjustment (PTA) — 0 days

The front page carries the standard USPTO notice, and I quote it verbatim:

"(*) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 U.S.C. 154(b) by 0 days. This patent is subject to a terminal disclaimer."

The 0-day PTA is internally consistent with the prosecution timeline: pendency from 2021-06-15 to 2022-07-05 is 385 days — far short of the three-year B-delay threshold of 37 CFR 1.703(b), so no B-delay accrued, and apparently no A-delay either. Google Patents' record for the patent likewise shows "2041-06-15 Anticipated expiration" with no separate "adjusted expiration" row, which independently corroborates zero PTA. (Source: https://patents.google.com/patent/US11379651/en.)

Practical consequence: there is no PTA "tail" to this patent; all of its enforceable term is the base statutory term.

---

3. Patent Term Extension (PTE, 35 U.S.C. § 156) — Not applicable / none

There is no PTE on US 11,379,651, and none is legally available. Section 156 extensions are limited to patents whose term was consumed by FDA regulatory review of a drug, medical device, food additive, or color additive. US 11,379,651 is a software/document-assembly patent (CPC G06F40/103, G06F40/106, G06F40/131, G06F40/134, G06F40/166, G06F40/186, G06F16/2455, G06F16/24564) with no regulatory-review predicate. A search of PTAB/PTA-Certificate records for this number returned only the generic §156/PTA statutory material, not a §156 application for this patent. I want to be explicit: I found no PTE application, and I would not expect one.

Also note 37 CFR 1.702(f): PTA/PTE-type adjustments under §§1.702–1.705 apply only to original applications, not reissues — relevant only if a reissue is ever filed (none is).

---

4. Continuity — the family is a single chain of continuations

All members claim the same 2020-07-06 provisional and the same earliest non-provisional filing date (2021-06-15).

Direct textual support for the continuity statements:

• US 11,361,144: "This application is a continuation of U.S. application Ser. No. 17/347,899, filed Jun. 15, 2021, which claims the priority and benefit of U.S. Provisional Application No. 63/048,512 filed on Jul. 6, 2020…" (https://patexia.com/us/patent/11361144)
• US 11,755,816: "This application is a continuation application of U.S. application Ser. No. 17/347,899, filed on Jun. 15, 2021, which claims the priority and benefit of U.S. Provisional Application No. 63/048,512…" (https://www.freepatentsonline.com/11755816.html)
• US 12,118,290: related-parent data identifies 17/830,566 (continuation) as the immediate parent, with the full chain 63/048,512 → 17/347,899 → 17/830,566 → 18/357,451 (https://patents.google.com/patent/US20240086614A1/en)

graph TD
    P["Provisional 63/048,512<br/>2020-07-06"] --> A["17/347,899<br/>filed 2021-06-15<br/>→ US 11,379,651 B1 (2022-07-05)"]
    P --> B["17/503,675<br/>filed 2021-10-18<br/>→ US 11,361,144 B2 (2022-06-14)<br/>cont. of 17/347,899"]
    A --> C["17/830,566<br/>filed 2022-06-02<br/>→ US 11,755,816 B1 (2023-09-12)<br/>continuation"]
    A --> D["18/887,157<br/>filed 2024-09-17<br/>→ US 2025/0225309 A1<br/>pending"]
    C --> E["18/357,451<br/>filed 2023-07-24<br/>→ US 12,118,290 B2 (2024-10-15)<br/>cont. of 17/830,566"]

No divisionals, no CIPs, no reissues, no reexaminations were found for this number in any of the searched records. Every child is expressly a continuation (not a divisional or CIP), which matters because a §120 continuation's term is measured from the earliest non-provisional filing date.

Geographic family: The Google/Darts-ip family ID 80003088 lists a US-only family (Country Status: US). No EP, GB, PCT/WO, or other foreign counterpart for this family surfaced. Given the assignee is a UK company, I flag this as a point worth independent confirmation, but I will not assert existence of foreign members I did not find.

---

5. Terminal disclaimer — a material term/enforceability issue

The front page states the patent "is subject to a terminal disclaimer." This is the single most important qualification to the term analysis, for three reasons:

1. Term effect. A terminal disclaimer under 37 C.F.R. §1.321 disclaims the terminal part of the statutory term that would extend beyond the expiration of the referenced patent/application. Because every member of this family measures its term from the same 2021-06-15 date, an intra-family disclaimer should not shorten the 2041-06-15 date — but the disclaimer is nevertheless binding and becomes "part of the original patent" under 35 U.S.C. §253.
2. Non-alienation / enforceability condition. A §1.321(c) disclaimer carries the agreement that the patent "shall be enforceable only for and during such period" that it and the reference patent/application are commonly owned. If US 11,379,651 and the reference patent ever cease to be commonly owned and commonly enforced, the '651 patent becomes unenforceable. This interacts directly with the recorded security interest to Silicon Valley Bank UK Limited (Reel 060515/0501, 2023-05-26) and with any future assignment or divestiture — a point your previously generated "Assignment history" section did not capture.
3. Identification caveat. The front page of the granted patent does not identify the reference patent/application by number, and I could not retrieve the recorded terminal disclaimer paper itself within the available search results. I therefore cannot state with confidence which patent or application the disclaimer runs against. Given the timing (US 11,361,144 issued 2022-06-14, three weeks before the '651 patent issued 2022-07-05), the most likely candidate is 17/503,675 / US 11,361,144, but I am explicitly flagging this as unverified rather than asserting it. Confirm via the Patent Center "Display References" / Image File Wrapper for 17/347,899 ("Terminal Disclaimer" document code).

---

6. Projected expiration date

• Base term: 20 years from the earliest non-provisional filing date, 2021-06-15 → June 15, 2041 (35 U.S.C. §154(a)(2), applied through the §120 chain).
• PTA: +0 days.
• Terminal disclaimer: limits term to the reference patent, but as explained in §5 that should not move the date off 2041-06-15; it does add the common-ownership enforceability condition.
• Projected expiration: 2041-06-15, contingent on (a) timely payment of all three maintenance fees and (b) continued common ownership/enforcement with the reference patent.

Maintenance-fee schedule (3.5 / 7.5 / 11.5 years from grant, 2022-07-05):

⚠️ Time-sensitive: under the current-date framing used in this analysis, the 3.5-year fee due date (2026-01-05) has passed and the surcharge/late-payment window closes 2026-07-05. The Google record still shows status "Active" (no lapse event), but I recommend verifying actual payment in Patent Center, because a lapse under §41(c) would cut the enforceable term off immediately and would also bear on the standing/enforceability posture of the pending IPR.

---

7. Interaction with the pending IPR (cross-reference to your PTAB section)

Your previously generated PTAB section identified IPR2026-00404 (Foleon Inc. et al. v. Turtl Surf & Immerse Ltd). The searches corroborated the existence of that proceeding and added two details — flagged as third-party/AI-generated and therefore not authoritative:

• The petition reportedly challenges claims 1–20 of the '651 patent (i.e., the full claim set).
• Grounds reportedly rely on Harrop (WO 03/075191) and Hailey (US 2005/0080814), with Davis (US 5,796,952) for the reader-interaction/analytics claims (11–12) and Lo (US 2005/0094205) for claim 7.
• Source: https://ai-lab.exparte.com/case/ptab/IPR2026-00404/doc/summary/2

Reliability caution I must state: that same source renders the patent's title as "Document Assembly Systems and Methods," which does not match the actual title (Methods and systems for interactive content creation). That mismatch is a warning sign that the summary is machine-generated and may contain inaccuracies; treat the prior-art mappings as leads to be confirmed against the actual petition papers on P-TACTS, not as verified facts.

Term-analysis implication: IPR2026-00404 is the controlling variable for this patent's effective commercial life. If claims are cancelled, the 2041-06-15 date becomes academic. If the patent survives, the 2041-06-15 date (with the terminal-disclaimer enforceability condition) governs.

---

8. Contradictions and corrections to flag against the previously generated sections

Per my operating rules, I flag these explicitly rather than silently overwriting:

1. "Prior art" section said no prior art exists in the record. That is true of the face of the '651 grant, but the family's IDS citations are publicly visible — US 12,118,290's Google page lists a "Citations (50)" table, and the granted '651/'558/'290 patents cite, inter alia, US20090076834A1 (personalized dynamic presentations from non-personalized structures), US20030176931A1, US20040135805A1, US20090043755A1, US20070027878A1, US20110029858A1, US20120159300A1, US20130031470A1, and others. These are the actual cited references and materially improve on "no prior art identified." The §102/§103 sections should be revised to use them.
2. "Litigation summary" reported no case found. The IPR caption "Foleon Inc v. Turtl Surf & Immerse Ltd" strongly implies a parallel district-court assertion (parties typically file IPRs in response to being sued), but I found no docket number, court, or filing date. My earlier conclusion stands as "not verified," but it should be re-flagged as likely rather than absent, pending Darts-ip/PACER pull.
3. Third-party expiration data conflicts. Patexia lists US 11,361,144's expiration as "Jul 5, 2040" (https://patexia.com/us/patent/11361144). That figure appears computed from the 2020-07-06 priority date, which is the wrong measuring date for a §120 continuation (term runs from the earliest non-provisional filing, 2021-06-15). Prefer 2041-06-15 (Google Patents' "anticipated expiration" for '651), and note that all four granted family members share the 2041-06-15 ceiling unless an individual patent earned its own PTA.
4. Date inconsistency inside the task materials. The task header states "Current Date: April 26, 2026," while the environment date is 2026-09-22. This matters for the maintenance-fee alert in §6 (under the April date the surcharge window is open; under the September date the 2026-07-05 window has closed and status verification becomes urgent). I have not resolved this; verify against the live record.

---

9. Bottom line

Verification links: https://patents.google.com/patent/US11379651/en · https://patents.justia.com/patent/11379651 · https://patentimages.storage.googleapis.com/94/95/9e/724ec47b5419e4/US11379651.pdf · USPTO Patent Center for application 17/347,899 (Image File Wrapper — "Terminal Disclaimer" and "Patent Term Adjustment" documents) · Darts-ip family https://patents.darts-ip.com/?family=80003088

Defensive Disclosure: US Patent 11379651 Derivative Variations

This document outlines derivative variations of the core claims of US Patent 11379651, aimed at creating defensive prior art to render future incremental improvements obvious or non-novel. The analysis is structured around the two primary independent claims identified in the patent summary, with each claim explored across five distinct axes of innovation.

---

Core Claim 1: System for Automatically Assembling an Interactive Document

Claim Synopsis: A server-based system that embeds rules into a first modular item of a first document, receives personalization parameters, pulls a second modular item from a second document based on these parameters and rules, and then assembles them to generate a derivative document.

---

1. Material & Component Substitution

Derivative 1.1.1: Decentralized Edge-Compute Assembly with Semantic Graph Store

• Enabling Description: The centralized "server" is replaced by a distributed network of edge computing devices (e.g., industrial IoT gateways, local network appliances) that cooperatively handle document assembly. Modular content items, along with their embedded rules, are stored in a distributed semantic graph database (e.g., using Apache Jena with RDF/OWL ontologies) where each node represents a content element and edges represent relationships and assembly rules. Personalization parameters are received via local APIs from user devices or directly from connected sensors. A consensus mechanism (e.g., Raft or Paxos) orchestrates the distributed rule evaluation and modular item fetching across the edge network. Assembly occurs at the edge, reducing latency and bandwidth. The derivative document is a compiled static web asset (e.g., HTML, CSS, JavaScript bundle) served directly from the nearest edge node.

graph TD
    A[User Device] --> B(Local API Gateway)
    B --> C{Edge Compute Cluster}
    C -- Rule Evaluation --> D[Distributed Semantic Graph Store (RDF/OWL)]
    D -- Content Retrieval --> E[Modular Content Repository]
    E --> C
    C -- Assembly --> F{Static Content Compiler}
    F --> G[Derivative Document (Web Asset)]
    G --> A

Derivative 1.1.2: Quantum-Resistant Blockchain-Secured Content Modules

• Enabling Description: Modular content items are cryptographically secured and timestamped on a permissioned blockchain (e.g., Hyperledger Fabric), ensuring immutability and verifiable provenance. Each modular item is associated with a smart contract that encapsulates its assembly rules. The "server" functionality is distributed across a blockchain network as peer nodes. Personalization parameters are submitted as transactions to the blockchain, triggering smart contract execution for rule evaluation and selection of modular items. The second modular item is pulled via a secure, authenticated inter-chain communication protocol (e.g., IBC) from a second document also stored on a potentially different blockchain. The assembly process is a series of verifiable transactions on the ledger, culminating in a hash of the derivative document being committed, while the actual document is assembled off-chain and accessed via a signed URI. Quantum-resistant cryptography (e.g., lattice-based schemes) is used for all cryptographic operations.

sequenceDiagram
    participant U as User Device
    participant PC as Personalization Component
    participant BC as Blockchain Network
    participant SC as Smart Contracts (Rules)
    participant MR as Modular Content Repository
    U->>PC: Submit Personalization Params (Transaction)
    PC->>BC: Record Params, Invoke Smart Contracts
    BC->>SC: Execute Assembly Rules
    SC->>MR: Request Modular Items (via secure API)
    MR-->>SC: Deliver Item Hashes/IDs
    SC-->>BC: Propose Assembled Document Hash
    BC-->>PC: Confirm Assembly Transaction
    PC->>MR: Assemble Off-chain Document
    MR-->>U: Serve Signed Derivative Document

Derivative 1.1.3: Ferroelectric RAM (FeRAM) Based Server with Event-Driven Processors

• Enabling Description: The server employs specialized processing units featuring Event-Driven Processors (EDPs) optimized for asynchronous task execution and low-power operation. All memory components, including for storing software instructions and structured data of modular items, are implemented using Ferroelectric RAM (FeRAM). FeRAM provides non-volatile, high-speed, and low-power data storage, enabling instant-on capabilities and persistent rule states even without power. Rule embedding and parameter processing are highly parallelized across EDPs. The "pulling" mechanism leverages direct memory access (DMA) between FeRAM modules containing documents and modular items, accelerating data retrieval without CPU overhead. The entire system is designed for extreme energy efficiency and resilience against power interruptions, crucial for mission-critical content delivery in remote or unstable environments.

graph LR
    A[User Request] --> B(Network Interface)
    B --> C(Event-Driven Processor Cluster)
    C -- Reads Rules/Content --> D[FeRAM Document Store]
    D -- Structured Data --> E[FeRAM Rule Store]
    C -- Evaluates --> E
    E --> F{Assembly Logic (EDP)}
    F -- Pulls Content --> D
    F -- Generates --> G(Derivative Document)
    G --> B

---

2. Operational Parameter Expansion

Derivative 1.2.1: Exascale Multi-Modal Document Assembly for Real-time Immersive Experiences

• Enabling Description: This system operates on a compute cluster capable of exascale processing, assembling hyper-personalized interactive content for millions of concurrent users within a single-digit millisecond latency for immersive virtual or augmented reality environments. The "modular items" are not merely text or images, but volumetric video segments, haptic feedback profiles, spatial audio cues, and dynamic environmental shaders. "Documents" are entire virtual worlds or complex simulated environments. Rules are evaluated against thousands of real-time biometric and environmental parameters (e.g., pupil dilation, skin conductance, gaze tracking, ambient light, user posture). The system leverages GPU-accelerated ray tracing and real-time physics engines for on-the-fly rendering and assembly of these multi-modal components into a seamless, responsive derivative experience.

graph TD
    A[Millions of User Sessions (VR/AR)] --> B(Real-time Biometric/Env. Data Ingest)
    B --> C{Exascale Compute Cluster (GPUs)}
    C -- Rule Eval (1000s of params) --> D[Massive Multi-modal Content Repository]
    D -- Volumetric Video, Haptics, Audio, Shaders --> C
    C -- Real-time Assembly & Rendering --> E[Personalized Immersive Experience]
    E --> A

Derivative 1.2.2: Hyperspectral Content Personalization for Specialized Scientific Data

• Enabling Description: The system is designed to handle "documents" comprising hyperspectral data cubes (e.g., from satellite imagery, medical imaging, material science sensors), where "modular items" are specific spectral bands, spatial regions, or temporal slices. Personalization parameters include specific wavelengths of interest, geological features, tissue types, or chemical compositions. The "first set of rules" embeds complex spectral unmixing algorithms and feature extraction criteria within the modular hyperspectral data. The system pulls relevant spectral signatures and spatial components from large-scale hyperspectral archives (second documents), processing data at terabyte-per-second rates. The derivative document is a personalized, fused hyperspectral image product or a multi-dimensional data visualization tailored for specific scientific analysis (e.g., mineral mapping, disease detection, environmental monitoring), rendered with dynamic pseudocoloring and volumetric visualization techniques.

graph TD
    A[Scientist Input (Wavelengths, Features)] --> B(Personalization Parameter Interface)
    B --> C{High-Performance Computing Cluster (Specialized Processors)}
    C -- Rule-Based Spectral Query --> D[Hyperspectral Data Archive (TB/s)]
    D -- Data Cubes, Spectral Libraries --> C
    C -- Processing & Fusion --> E[Personalized Hyperspectral Product]
    E --> F(Multi-Dimensional Visualization)
    F --> A

Derivative 1.2.3: Ultra-Low Latency Financial Report Generation with Predictive Rules

• Enabling Description: This system processes real-time financial market data streams to generate personalized investment reports or risk assessments within sub-millisecond latency. "Modular items" are individual stock charts, economic indicators, news sentiment analyses, or regulatory compliance paragraphs. "Documents" are comprehensive market overviews. The "first set of rules" incorporates predictive analytics models (e.g., ARIMA, LSTM) that, based on real-time market parameters (e.g., volatility, trading volume, sentiment), dynamically trigger the inclusion of forward-looking statements, risk warnings, or bullish/bearish analyses from other documents. The system uses in-memory databases (e.g., Apache Ignite, Redis) for modular item storage and ultra-low latency messaging queues (e.g., Kafka) for parameter ingestion. The derivative document is a dynamic, live-updating financial dashboard or executive summary, continuously adapting to market movements, designed for high-frequency trading decision support.

graph LR
    A[Real-time Market Data Stream] --> B(Ingestion & Parameterization)
    B --> C{Assembly Server (In-Memory DB)}
    C -- Predictive Rules Engine --> D[Modular Financial Content (Charts, News, Analysis)]
    D --> C
    C -- Ultra-low Latency Assembly --> E(Live Personalized Financial Report)
    E --> F[Trading Desks/Analysts]

---

3. Cross-Domain Application

Derivative 1.3.1: Aerospace - Dynamic Aircraft Maintenance Manual Generation

• Enabling Description: The system generates real-time, personalized aircraft maintenance manuals or repair procedures based on current aircraft health monitoring data (from embedded IoT sensors), flight hours, environmental conditions, and technician certifications. "Modular items" are specific repair steps, diagnostic flowcharts, tool lists, safety warnings, or exploded-view schematics (e.g., CAD models). "Documents" are master aircraft service manuals. The "first set of rules" embedded in a task modular item dictates which specific tool variant is required (based on tool crib inventory status), what safety precautions are mandatory (based on current weather conditions or fuel tank levels), or which replacement part version is compatible (based on aircraft serial number and parts inventory). Personalization parameters include tail number, fault code, maintenance station location, and technician skill level. The derivative document is an interactive digital manual displayed on a ruggedized tablet, dynamically updating as new diagnostic data arrives or as the technician progresses through a guided workflow, with direct links to augmented reality overlays for complex procedures.

graph TD
    A[Aircraft Health Monitoring System (IoT Sensors)] --> B(Real-time Aircraft Parameters)
    C[Maintenance Technician Input (Fault Code, Skill)] --> B
    B --> D{Maintenance Manual Assembly Engine}
    D -- Rule Evaluation (Tail No., Fault, Env., Skill) --> E[Modular Maintenance Content (Steps, Tools, Schematics)]
    E -- CAD Models, Safety Warnings, Tool Lists --> D
    D --> F[Interactive Digital Manual (Rugged Tablet)]
    F -- AR Overlays --> F

Derivative 1.3.2: AgTech - Adaptive Crop Management Plan Generator

• Enabling Description: This system automatically generates adaptive crop management plans (e.g., irrigation schedules, fertilization recommendations, pest control strategies) tailored to specific farm plots. "Modular items" represent individual recommendations for nutrient application, watering duration, pesticide types, or harvesting techniques. "Documents" are comprehensive agricultural best practices guides or regional crop advisories. Rules are embedded in each modular recommendation, considering parameters such as real-time soil moisture, nutrient levels (from soil sensors), weather forecasts, satellite imagery-derived plant health indices (NDVI), historical yield data, specific crop variety, and prevailing market prices. Personalization parameters include farm ID, crop type, growth stage, and current nutrient deficiencies. The derivative document is a dynamic, interactive digital farm plan delivered to a farmer's device, with actionable tasks and alerts, capable of integrating with automated farm machinery (e.g., smart irrigation systems, precision sprayers).

graph TD
    A[Environmental Sensors (Soil, Weather)] --> B(Real-time Farm Parameters)
    C[Satellite Imagery (NDVI)] --> B
    D[Historical Yield Data] --> B
    E[Market Prices] --> B
    B --> F{Crop Plan Assembly Engine}
    F -- Rule Evaluation (Plot, Crop, Stage, Deficiencies) --> G[Modular Ag. Recommendations (Irrigation, Fertilizer, Pest)]
    G --> F
    F --> H[Adaptive Digital Farm Plan (Farmer's Device)]
    H -- Integrates with --> I[Automated Farm Machinery]

Derivative 1.3.3: Consumer Electronics - Dynamic Smart Home Device User Guides

• Enabling Description: This system dynamically generates personalized user guides and troubleshooting instructions for complex smart home ecosystems. "Modular items" are setup procedures for specific devices (e.g., smart thermostat, lighting, security camera), integration steps for different brands, or troubleshooting flows for common issues. "Documents" are master manuals for smart home hubs or platforms. The "first set of rules" embedded in a device setup modular item checks for the presence of compatible network protocols (e.g., Zigbee, Z-Wave, Wi-Fi), currently installed smart devices, and user-specified preferences (e.g., accessibility settings, language). Personalization parameters include the user's installed device inventory (detected via API), network configuration, and reported error codes. The derivative document is an interactive, on-demand guide presented through a smart display or mobile application, showing only relevant sections for the user's specific setup and dynamically adapting troubleshooting steps based on real-time device diagnostics.

graph TD
    A[Smart Home Hub (API)] --> B(Device Inventory & Diagnostics)
    C[User Preferences (Accessibility, Language)] --> B
    B --> D{User Guide Assembly Engine}
    D -- Rule Evaluation (Installed Devices, Network, Errors) --> E[Modular User Guide Content (Setup, Integration, Troubleshoot)]
    E --> D
    D --> F[Interactive Smart Display/Mobile App]
    F -- Real-time Diagnostics --> B

---

4. Integration with Emerging Tech

Derivative 1.4.1: AI-Driven Contextual Content Optimization with Real-time IoT Data

• Enabling Description: The system integrates AI-driven optimization directly into the rule generation and document assembly process, augmented by real-time data from IoT sensors. "Modular items" can be content snippets, visual elements, or interactive components. "Documents" are marketing collateral or educational materials. The "first set of rules" is initially defined by authors but is continuously optimized by a Reinforcement Learning (RL) agent. The RL agent observes reader interaction data (dwell time, clicks, scroll depth, conversion rates) and contextual data from IoT sensors (e.g., ambient lighting, noise level, device type, user's physical location, even biometric data like heart rate from wearables, if consented). The RL agent dynamically modifies assembly rules to maximize engagement or conversion goals. Personalization parameters now include real-time environmental context and inferred user emotional state. The derivative document is assembled on the fly, with AI selecting the optimal modular items and presentation styles (e.g., color scheme, font size) for the user's immediate physical and psychological context.

graph TD
    A[Reader Interaction Data] --> B(Analytics & Feedback Loop)
    C[IoT Sensor Data (Ambient, Biometric)] --> D(Contextual Parameters)
    D --> E{Reinforcement Learning (RL) Agent}
    E -- Optimizes/Generates --> F[Dynamic Assembly Rules]
    F --> G{Content Assembly Engine}
    G -- Selects Content --> H[Modular Content Repository]
    H --> G
    G --> I[Personalized Derivative Document]
    I --> J[Reader Device]
    J --> A

Derivative 1.4.2: Blockchain-Verified Supply Chain Document Generation

• Enabling Description: This system generates regulatory compliance documents, product traceability reports, or contractual agreements for complex supply chains, where the authenticity and origin of each "modular item" (ee.g., material certification, manufacturing batch record, shipping manifest, quality assurance report) is verified against immutable records on a public or consortium blockchain (e.g., Ethereum, Corda). The "first set of rules" embedded within a document modular item includes smart contract calls that query the blockchain for specific asset attributes (e.g., "is this component certified organic?", "did this batch pass inspection X?"). Personalization parameters include product ID, manufacturing plant, regulatory jurisdiction, and inspection date range. The assembly engine pulls modular items only after their blockchain-verified status meets the rules. The derivative document, such as a "Digital Product Passport," includes cryptographic hashes of the assembled content, allowing recipients to verify its integrity and the authenticity of its constituent parts against the blockchain.

graph TD
    A[Product ID, Jurisdiction, Date] --> B(Personalization Parameters)
    B --> C{Document Assembly Engine}
    C -- Rule Eval & Smart Contract Query --> D[Blockchain Network (Verified Records)]
    D -- Material Certs, Batch Records, QA Reports --> E[Modular Supply Chain Content]
    E --> C
    C -- Assemble & Hash --> F[Derivative Document (Digital Product Passport)]
    F --> G[Recipient (Verification)]
    G --> D

Derivative 1.4.3: Federated Learning for Privacy-Preserving Rule Optimization

• Enabling Description: Instead of centralized collection of reader interaction data, this system employs Federated Learning to optimize the "assembly rules" for personalized content while preserving user privacy. Each user device maintains a local model of engagement and preference. "Modular items" and their initial "first set of rules" are created centrally. As users interact with derivative documents, their devices locally update their rule optimization models. Periodically, these local model updates (not raw data) are aggregated by a central server (e.g., using secure aggregation techniques) to improve a global rule optimization model. This global model then pushes updated, privacy-preserving rule coefficients or refined rule patterns back to the modular content items. Personalization parameters are processed locally on the user device where possible. The derivative document is assembled with rules enhanced by collective, yet private, user behavior, allowing for improved personalization without direct exposure of individual interaction data.

graph TD
    subgraph Central Server
        A[Global Rule Optimization Model] -- Aggregates Updates --> B(Secure Aggregator)
        B -- Distributes Updates --> C[Modular Content Rule Store]
    end

    subgraph User Device (n)
        D[Local Rule Optimization Model] -- Updates Based On --> E(Reader Interaction)
        E --> F[Personalized Document Display]
        C --> D
        D -- Sends Update --> B
    end

    C -- Initial Rules --> F

---

5. The "Inverse" or Failure Mode

Derivative 1.5.1: Graceful Degradation to Read-Only Static Archive

• Enabling Description: In the event of a catastrophic failure of the personalization or assembly engine (e.g., database outage, rule engine crash, network partition), the system automatically reverts to a "safe failure" mode. The primary objective is to maintain content availability. If real-time personalization parameters cannot be processed or modular items cannot be dynamically pulled, the system accesses a pre-generated, generic, read-only static archive of the "first document." This archive contains the first document in its most basic, unpersonalized form, with all modular items explicitly included in a default order, and all interactive elements disabled. No external modular items are pulled. This "derivative document" is purely informational, stripped of all dynamic capabilities and personalization, ensuring minimal functional disruption and data integrity over advanced features.

stateDiagram
    [*] --> Operational
    Operational --> PersonalizationFailure : Assembly Engine Crash
    Operational --> DatabaseOutage : Content DB Unreachable
    Operational --> NetworkPartition : External Modules Unavailable
    PersonalizationFailure --> SafeMode
    DatabaseOutage --> SafeMode
    NetworkPartition --> SafeMode
    SafeMode --> ServesStaticArchive : Read-Only Document
    ServesStaticArchive --> [*]

Derivative 1.5.2: Low-Power/Limited-Functionality Mode for Resource-Constrained Environments

• Enabling Description: This derivative operates in a "low-power" or "limited-functionality" mode, specifically designed for user devices with severe resource constraints (e.g., low battery, limited CPU, slow network, minimal data plan). The system's "server" side detects these constraints (e.g., via user agent, network latency monitoring, explicit user setting). In this mode, only strictly essential textual "modular items" are assembled, completely omitting high-bandwidth elements like videos, high-resolution images, and complex interactive scripts. All presentation "styles" are simplified to a minimal, monochromatic theme using system-default fonts. The "first set of rules" includes directives for conditional exclusion based on detected device capabilities. Personalization parameters are strictly limited to critical filters (e.g., industry, primary topic), ignoring fine-grained customization. The derivative document is an ultra-lightweight, text-optimized page designed for rapid loading and minimal resource consumption.

graph TD
    A[User Device Request] --> B(Resource Monitor)
    B -- Detects Low-Resource --> C{Low-Power Assembly Engine}
    C -- Filters/Simplifies Rules --> D[Text-Only Modular Content]
    D -- Minimal Styling --> C
    C --> E[Ultra-Lightweight Derivative Document]
    E --> A

Derivative 1.5.3: "Draft Mode" with Rule-Structure-Only Assembly

• Enabling Description: This system provides a "draft mode" primarily for content creators and personalizers to validate the logic of their "first set of rules" and personalization parameter interactions without assembling or rendering the full content. Instead of pulling and assembling actual content, the "second modular item" (and indeed all modular items) are represented by abstract placeholders or metadata cards. The "derivative document" generated in this mode is not a content-rich document, but rather a visual representation of the assembly logic flow. It shows which content types would be included, their sequence, and how they link to various rules and parameters, highlighting any conflicting or unresolved rule conditions. This allows for rapid debugging and validation of complex rule structures before resource-intensive content assembly.

graph TD
    A[Personalizer Input (Parameters)] --> B(Rule Validation Interface)
    B --> C{Draft Mode Assembly Engine}
    C -- Evaluates Rule Logic --> D[Modular Item Metadata/Placeholders]
    D --> C
    C -- Generates --> E[Visual Assembly Logic Flow Diagram]
    E --> B

---

Core Claim 2: System for Personalizing an Interactive Document

Claim Synopsis: A first component creates modular items with embedded rules for linking/assembly. A second component receives personalization instructions, assembles modular items from various documents based on these rules, and renders the derivative document using an associated style.

---

6. Material & Component Substitution

Derivative 2.1.1: WebAssembly (Wasm) Based Client-Side Assembly Engine

• Enabling Description: The "second component" (content personalization, assembly, and rendering) is largely executed client-side within a web browser, leveraging WebAssembly (Wasm) modules for high-performance rule evaluation and content assembly. The "first component" (content creation) generates modular content items and their associated rules in a format optimized for Wasm consumption. Instead of server-side pulling, the client device prefetches bundles of potential modular items. Personalization instructions trigger the Wasm engine to perform rule-based selection and assembly of these pre-fetched items directly in the browser. Rendering utilizes a highly efficient client-side rendering engine (e.g., WebGL for complex layouts or a custom canvas renderer), ensuring responsiveness and reducing server load. Style application is also handled by Wasm-optimized CSS-in-JS libraries or pre-compiled style sheets.

graph TD
    A[User Input/Context] --> B(Web Browser)
    B -- Wasm Runtime --> C{Client-Side Assembly Engine (Wasm)}
    C -- Rule Evaluation --> D[Pre-fetched Modular Content Bundles]
    D -- Content & Rules (Wasm Optimized) --> E[Client-Side Rendering Engine]
    E -- Dynamic DOM Update --> F[Personalized Document Display]
    C --> E
    Server --> D

Derivative 2.1.2: Holographic Display Rendering with Volumetric Content Modules

• Enabling Description: The "second component" renders derivative documents for holographic displays. "Modular items" are not flat pages but rather volumetric content assets (e.g., 3D models, holographic projections, spatial sound fields). The "first component" (content creation) provides tools for authoring these volumetric assets and embedding rules (e.g., proximity-triggered display, gaze-interaction rules). Personalization instructions might involve holographic positioning, scaling, or interaction modalities. The assembly process dynamically places these volumetric modules in a 3D space, respecting spatial relationships defined by rules and user preferences. Rendering involves a real-time volumetric rendering pipeline optimized for specific holographic display hardware (e.g., light-field displays), ensuring correct parallax and depth perception, and dynamically adjusting the "style" to the display's capabilities and ambient light conditions.

graph TD
    A[User Interaction (Gaze, Gesture)] --> B(Holographic Device Input)
    C[Personalization Instructions] --> B
    B --> D{Volumetric Assembly Engine}
    D -- Rule Evaluation (Spatial, Proximity, Gaze) --> E[Volumetric Content Repository (3D Models, Spatial Audio)]
    E -- Holographic Assets --> D
    D --> F[Real-time Volumetric Renderer]
    F --> G[Holographic Display]

Derivative 2.1.3: Biometric-Authenticated Modular Access and Assembly

• Enabling Description: This system enforces strict access control for modular content items and personalization instructions using biometric authentication. The "first component" securely associates modular items and their rules with biometric identity hashes (e.g., iris scan, fingerprint template). The "second component" receives personalization instructions only after successful multi-factor biometric authentication of the user. The assembly engine then dynamically decrypts and pulls modular items whose associated biometric permissions match the authenticated user's profile. This ensures that only authorized individuals can access and view sensitive personalized content. The "style" of the rendered document may also adapt based on the security level associated with the authenticated biometric profile, e.g., displaying watermarks for high-security content.

sequenceDiagram
    participant U as User
    participant BD as Biometric Device
    participant PC as Personalization Component
    participant AA as Authentication & Authorization
    participant MR as Modular Content Repository
    U->>BD: Biometric Scan
    BD->>AA: Submit Biometric Hash
    AA-->>U: Authentication Success/Fail
    U->>PC: Submit Personalization Request (Authenticated)
    PC->>AA: Request Modular Item Access
    AA-->>MR: Verify Biometric Permissions
    MR-->>AA: Return Authorized Encrypted Modules
    AA-->>PC: Deliver Decrypted Modules
    PC->>PC: Assemble & Render
    PC-->>U: Display Personalized Document

---

7. Operational Parameter Expansion

Derivative 2.2.1: Hyper-Adaptive Semantic Content Graph Assembly

• Enabling Description: This system manages "documents" and "modular items" as nodes and edges within a vast, dynamically evolving semantic knowledge graph containing billions of interlinked content fragments. The "set of rules" for each modular item is expressed as complex SPARQL queries or OWL axioms operating on this graph. The "second component" (assembly) operates at petabyte-scale data volumes, evaluating rule sets with thousands of interwoven logical conditions and contextual relationships (e.g., ontological classifications, temporal dependencies, user interaction history across the entire content ecosystem). The personalization instruction is a high-level intent, which the system then translates into a cascade of semantic queries to assemble a highly granular derivative document. Rendering dynamically adjusts layout and visual hierarchy based on the semantic density and perceived importance of the assembled content, ensuring optimal information flow.

graph TD
    A[High-level User Intent] --> B(Semantic Query Generator)
    B --> C{Petabyte-Scale Semantic Graph (OWL/RDF)}
    C -- SPARQL/OWL Query --> D[Modular Content Nodes]
    D -- Billions of Content Fragments --> C
    C -- Rule-based Traversal & Selection --> E{Hyper-Adaptive Assembly Engine}
    E --> F[Dynamic Layout & Visual Hierarchy]
    F --> G[Derivative Document (Semantic-aware)]
    G --> A

Derivative 2.2.2: Extreme Real-time Haptic Feedback Document Personalization

• Enabling Description: This system creates "interactive documents" that include real-time haptic feedback (e.g., variable textures, vibration patterns, force feedback) as a core part of its personalized experience. "Modular items" can embed haptic profiles (e.g., "rough texture," "smooth slide," "sharp click") alongside visual and textual content. The "set of rules" defines conditions for triggering specific haptic responses based on user interaction (e.g., cursor hover, pressure applied to a touchscreen, VR glove gestures) and personalization parameters (e.g., user's known tactile preferences, accessibility needs). The "second component" processes thousands of haptic feedback events per second, dynamically assembling and synchronizing haptic outputs with visual and audio rendering. The "style" component extends to haptic rendering, adjusting intensity and duration to match the visual presentation, creating a truly multi-sensory personalized document.

sequenceDiagram
    participant U as User (w/ Haptic Device)
    participant CE as Content Event Generator
    participant HE as Haptic Engine
    participant DE as Document Assembly Engine
    participant HC as Haptic Content Store
    U->>CE: Interact (Hover, Touch)
    CE->>HE: Haptic Trigger (Context, Params)
    HE->>HC: Query Haptic Profile (Rules)
    HC-->>HE: Return Haptic Data
    HE->>U: Deliver Haptic Feedback (ms)
    CE->>DE: Update Personalization State
    DE->>DE: Re-assemble/Render (Visual, Audio)
    DE-->>U: Display/Play Content

Derivative 2.2.3: Quantum Annealing Optimized Rule Matching for Massive Personalization Options

• Enabling Description: For "documents" with an astronomically large number of potential "modular items" (e.g., millions of micro-content snippets) and extremely complex, inter-dependent "sets of rules" (e.g., combinatorial conditions across hundreds of personalization parameters), the "second component" utilizes a Quantum Annealing processor (e.g., D-Wave) to solve the NP-hard problem of optimal rule matching and content selection. Personalization instructions are translated into an Ising model or Quadratic Unconstrained Binary Optimization (QUBO) problem. The quantum annealer rapidly finds the ground state, which corresponds to the optimal subset of modular items satisfying the complex rules and personalization constraints. This enables personalization at a scale and complexity currently intractable for classical computers, allowing for truly bespoke derivative documents from vast content libraries.

graph TD
    A[Massive Personalization Params] --> B(Ising/QUBO Model Converter)
    B --> C{Quantum Annealer}
    C -- Finds Ground State --> D[Optimal Modular Item Subset]
    D --> E{Document Assembly Engine}
    E --> F[Massive Modular Content Library]
    F --> E
    E --> G[Hyper-Personalized Derivative Document]

---

8. Cross-Domain Application

Derivative 2.3.1: Smart Cities - Adaptive Public Information Display System

• Enabling Description: This system dynamically generates localized and time-sensitive public information for smart city displays (e.g., digital kiosks, public transit screens). The "first component" allows city planners to create modular information items (e.g., transit route updates, emergency alerts, cultural event listings, air quality reports) with rules based on real-time city data. The "set of rules" for each modular item considers parameters such as current time of day, location of the display, local population density, current traffic conditions, air quality sensor readings, and emergency service alerts. The "second component" receives personalization instructions (implicitly from display location and real-time sensor feeds) and assembles relevant modular items. For instance, during a pollution event, an air quality alert module will supersede cultural event listings. The "style" dynamically adjusts to ambient light conditions and accessibility requirements (e.g., large text for elderly viewers, sign language video for hearing impaired). The derivative document is the real-time content displayed on the public screen.

graph TD
    A[City Sensor Data (Traffic, Air Quality)] --> B(Real-time City Context)
    C[Display Location/Time] --> B
    D[Emergency Alerts] --> B
    B --> E{Public Display Assembly Engine}
    E -- Rule Eval (Location, Time, Emergencies, Sensors) --> F[Modular Public Information (Transit, Events, Alerts)]
    F -- Dynamic Style Adjustment --> E
    E --> G[Adaptive Public Information Display]
    G --> H[City Residents/Visitors]

Derivative 2.3.2: Personalized Education - Adaptive Learning Module Generator

• Enabling Description: This system generates personalized learning modules and curricula for students, adapting to their individual learning styles, pace, and knowledge gaps. The "first component" allows educators to create modular learning units (e.g., video explanations, interactive quizzes, text summaries, problem sets) and embed rules based on pedagogical principles. The "set of rules" for each modular item considers parameters such as student's previous quiz scores, preferred learning modality (e.g., visual, auditory), time spent on a topic, detected frustration levels (e.g., via webcam gaze/emotion analysis), and mastery goals. The "second component" receives personalization instructions (student ID, current topic) and uses the rules to assemble an optimal sequence of learning modules. For example, if a student struggles with a concept, a remedial video explanation module might be inserted. The "style" of the derivative learning path adapts with progress indicators, gamification elements, and visual themes to maintain student engagement.

graph TD
    A[Student Performance Data (Quiz Scores, Time)] --> B(Learning Analytics)
    C[Student Profile (Style, Goals)] --> B
    D[Gaze/Emotion Analysis] --> B
    B --> E{Adaptive Learning Assembly Engine}
    E -- Rule Eval (Scores, Style, Frustration, Goals) --> F[Modular Learning Units (Videos, Quizzes, Text, Problems)]
    F -- Adaptive Style/Gamification --> E
    E --> G[Personalized Learning Path/Module]
    G --> H[Student Device]
    H --> A

Derivative 2.3.3: Manufacturing - Real-time Machine Operator Instruction Assembly

• Enabling Description: This system provides real-time, personalized work instructions for machine operators on a factory floor. The "first component" enables engineers to create modular operational steps (e.g., tool setup, safety checks, component loading sequences, quality control procedures) and embed rules for their display. The "set of rules" for each step considers parameters such as the specific machine model, current production batch, operator's certification level, tool inventory availability, and real-time sensor data from the machine (e.g., temperature, pressure, part count). The "second component" receives personalization instructions (operator ID, machine ID, task) and assembles the most relevant and efficient sequence of instructions. If a sensor indicates an anomaly, an immediate troubleshooting module is inserted. The "style" of the instructions adapts to the industrial environment (e.g., high-contrast, large-font display on a ruggedized tablet or heads-up display) and can incorporate augmented reality overlays for complex tasks.

graph TD
    A[Machine Sensor Data (Temp, Pressure, Count)] --> B(Real-time Production Context)
    C[Operator ID, Machine ID, Task] --> B
    D[Tool/Component Inventory] --> B
    B --> E{Instruction Assembly Engine}
    E -- Rule Eval (Machine, Batch, Operator Cert, Tools, Sensors) --> F[Modular Operational Steps (Setup, Safety, Load, QC)]
    F -- Industrial UI/AR Overlays --> E
    E --> G[Real-time Operator Instructions (Rugged Tablet/HUD)]
    G --> H[Machine Operator]

---

9. Integration with Emerging Tech

Derivative 2.4.1: AI-Generated Content Creation with Human-in-the-Loop Rule Refinement

• Enabling Description: This system uses Generative AI (e.g., Large Language Models, Stable Diffusion) within the "first component" to automatically generate diverse "modular items" (text, images, video snippets) based on high-level prompts. These AI-generated modular items are then automatically tagged with preliminary "sets of rules" derived from semantic analysis of their content. A "human-in-the-loop" mechanism allows content creators to review, modify, and refine these AI-generated rules and modular items. The "second component" receives personalization instructions and uses these (potentially human-refined) AI-generated rules for assembly. Furthermore, the AI can also suggest optimal "styles" based on the derivative document's content and target audience. The system incorporates Reinforcement Learning from Human Feedback (RLHF) to continuously improve the AI's ability to generate relevant content and effective rules.

graph TD
    A[High-level Content Prompt] --> B(Generative AI (LLM, Diffusion))
    B -- AI-generated Content/Rules --> C[Human-in-the-Loop Review/Refinement]
    C --> D[Modular Content/Rule Store]
    D --> E{Personalization & Assembly Engine}
    E --> F[Personalized Derivative Document]
    F -- Reader Feedback --> G(RLHF System)
    G -- Model Improvement --> B

Derivative 2.4.2: IoT-Triggered Context-Aware Adaptive Document Updates

• Enabling Description: This system enables "documents" to automatically update and reassemble their "modular items" based on real-time changes detected by IoT sensors. For example, a "smart product manual" (the derivative document) for an appliance. The "first component" allows authors to create modular troubleshooting steps or feature explanations linked to specific appliance sensor states. The "set of rules" for each modular item is tied directly to IoT data streams (e.g., "if refrigerator door open for >5 min", "if washing machine error code E42"). The "second component" continuously monitors a stream of IoT sensor data (personalization instructions). If a relevant sensor event occurs, the system automatically triggers a re-assembly, pulling appropriate troubleshooting guides or usage tips from other documents. The "style" can include dynamic visual cues (e.g., flashing alert icon) to draw attention to newly inserted content relevant to the IoT event.

graph TD
    A[IoT Sensor Stream (Appliance Diagnostics)] --> B(Real-time Event Detector)
    B --> C{Adaptive Document Assembly Engine}
    C -- Rule Eval (Sensor State, Error Codes) --> D[Modular Troubleshooting/Usage Tips]
    D --> C
    C -- Re-assembles/Updates --> E[Smart Product Manual (Derivative Document)]
    E --> F[User Device/Appliance Display]

Derivative 2.4.3: Decentralized Identity and Verifiable Credential-Based Document Access & Personalization

• Enabling Description: This system uses Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) (e.g., W3C VC Data Model) to manage access to "modular items" and drive personalization. Users possess self-sovereign digital identities and VCs (e.g., "verified employee of Company X," "certified in Skill Y"). The "first component" associates "modular items" and their "sets of rules" with specific credential requirements. The "second component" receives personalization instructions, including presentation of VCs from the user's digital wallet. The assembly engine evaluates rules against these cryptographically verifiable claims. For example, a confidential project report (derivative document) may only assemble specific "modular items" (e.g., sensitive financial data) if the user presents a VC proving "Project Lead" status and "Security Clearance Level 5." The "style" might apply a watermark or digital signature based on the strength of the presented credentials. This ensures robust, privacy-preserving, and tamper-evident authorization for personalized content.

sequenceDiagram
    participant U as User (w/ Digital Wallet)
    participant PC as Personalization Component
    participant AA as VC Verifier
    participant BC as Blockchain/DID Ledger
    participant MR as Modular Content Repository
    U->>PC: Request Document, Present VCs
    PC->>AA: Submit VCs for Verification
    AA->>BC: Verify VC Integrity & Issuer DID
    BC-->>AA: Verification Result
    AA-->>PC: Validated Claims
    PC->>MR: Request Modules (Rules + Claims)
    MR-->>PC: Deliver Authorized Modules
    PC->>PC: Assemble & Render
    PC-->>U: Display Personalized Document

---

Combination Prior Art Scenarios with Open-Source Standards

These scenarios combine the core concepts of US11379651 (modular content, rule-based assembly, personalization, dynamic rendering) with existing open-source standards to demonstrate prior art for broad applicability.

Combination Prior Art 1: Modular Content Assembly with Markdown and Git/Jekyll

• Description: The system utilizes a collection of plain-text "modular items" written in Markdown (an open-source lightweight markup language) stored in a Git repository (an open-source distributed version control system). Each Markdown file (modular item) includes YAML front matter for metadata, where "assembly rules" are defined using a simple key-value structure or a domain-specific language (DSL). A static site generator like Jekyll (an open-source Ruby-based framework) acts as the "assembly engine." Personalization parameters are provided via command-line flags or environment variables during the build process, or through client-side JavaScript injected into the static HTML. Jekyll's templating engine (Liquid) processes the rules and metadata, dynamically selecting and assembling Markdown files into a "derivative document" (e.g., a personalized report, a website page). The "style" is controlled by open-source CSS frameworks (e.g., Bootstrap) applied to the Jekyll templates. This demonstrates modular content creation, rule embedding, parameter-driven pulling and assembly, and rendering using widely available open-source tools.
• Open-Source Standards: Markdown, Git, Jekyll, YAML, Liquid, Bootstrap.

graph TD
    A[Content Creator (Markdown + YAML)] --> B(Git Repository)
    B --> C{Jekyll Build Process (Assembly Engine)}
    D[Personalization Parameters (CLI/Env Vars)] --> C
    C -- Rule Evaluation (YAML Front Matter) --> B
    B -- Pulls Markdown Files --> C
    C -- Templating (Liquid) --> E[Static HTML/CSS Files]
    E --> F[Web Browser (Derivative Document)]

Combination Prior Art 2: Dynamic Document Generation with XML/XSLT and OpenDocument Format (ODF)

• Description: This system focuses on structured document personalization using XML and XSLT (eXtensible Stylesheet Language Transformations), generating documents in the OpenDocument Format (ODF). "Modular items" are defined as XML fragments conforming to a specific schema (e.g., DITA XML topics or custom XML structures), each containing embedded "assembly rules" as XPath expressions or XSLT templates. These modular items are stored in an XML database (e.g., BaseX, eXist-db). Personalization parameters are provided as XML input documents or parameters to an XSLT processor. The "assembly engine" is an XSLT 2.0/3.0 processor that takes a master XML document (the "first document") and the personalization parameters, then applies XSLT stylesheets that use XPath to evaluate rules and pull relevant XML modular items from the database. The output "derivative document" is a well-formed ODF (e.g., .odt, .ods) document, where the "style" is defined by embedded ODF styles or through further XSLT transformations targeting ODF's internal XML structure. This showcases rule-based assembly of structured content into standard, open formats.
• Open-Source Standards: XML, XSLT, XPath, OpenDocument Format (ODF), DITA XML.

graph TD
    A[Content Creator (XML Fragments)] --> B(XML Database)
    B -- DITA/Custom Schema --> C{XSLT Processor (Assembly Engine)}
    D[Personalization Parameters (XML)] --> C
    C -- XPath Rule Eval --> B
    B -- Pulls XML Modules --> C
    C -- XSLT Transformation --> E[OpenDocument Format (ODF) File]
    E --> F[ODF Viewer (Derivative Document)]

Combination Prior Art 3: Micro-Frontend Based Content Personalization with React and GraphQL

• Description: This system implements personalization using a "micro-frontend" architecture where each "modular item" is a distinct, independently deployable React component (an open-source JavaScript library). These components are registered in a central registry with associated "assembly rules" defined as component props or GraphQL directives. The "first document" is a top-level React application that dynamically loads these micro-frontends. Personalization parameters are received via a GraphQL API (an open-source query language) from the client device. The "assembly engine" is a client-side JavaScript module that, based on GraphQL query results and component rules, orchestrates the dynamic loading and rendering of relevant React micro-frontend components. The "derivative document" is the single-page application experience, dynamically composed of personalized micro-frontends. The "style" is managed using open-source CSS-in-JS libraries (e.g., Styled Components, Emotion) or utility-first CSS frameworks (e.g., Tailwind CSS) within each component, ensuring consistent branding across dynamically assembled content.
• Open-Source Standards: React, GraphQL, Micro-frontends (architectural pattern), CSS-in-JS (e.g., Styled Components), Tailwind CSS.

graph TD
    A[User Device/Client App] --> B(GraphQL API Gateway)
    B -- Personalization Params --> C{Client-Side Assembly Module (JS)}
    C -- GraphQL Query --> B
    B -- Component Registry/Rules --> C
    C -- Dynamically Loads --> D[React Micro-Frontend Components]
    D -- Rendered --> E[Personalized SPA (Derivative Document)]
    E --> A