Patent Drafting Analysis of Milestone Entertainment’s Program Defined Transaction & Cryptocurrency System | US 2024/0127063 A1
Patent Drafting Analysis of Milestone Entertainment's Program Defined Transaction & Decentralized Cryptocurrency System | US 2024/0127063 A1
A structural and strategic analysis of US 2024/0127063 A1, examining claim architecture, drafting quality, §101 eligibility risk, critical gaps, and prosecution positioning for Milestone Entertainment's three-plane blockchain transaction system.
Spec Words
18,500
Across 7 sections
Draft now ↗
Total Claims
20
1 independent · 19 dependent
Draft now ↗
Figure Sheets
17
System architecture, blockchain, AI, smart contracts, UI
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 80% of total words (~14,800 words), reflecting an unusually expansive glossary section (paragraphs [0166]–[0489]) that adds substantial bulk without directly supporting claim limitations. The claim architecture is notably thin — just 1 independent claim with 19 dependents — which creates a single point of failure risk during prosecution. The 17-figure sheets provide strong visual coverage of the three-plane system architecture, blockchain mechanics, smart contract flows, and ecosystem interactions, though several figures (FIGs. 1–2) are labeled prior art and provide no claim support.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 17 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Prior art centralized network topology showing a single central station connected to peripheral stations via links.Search in Eureka ↗ | Other |
| FIG. 2 | Prior art decentralized network topology showing distributed nodes with multiple interconnections and no central hub.Search in Eureka ↗ | Other |
| FIG. 3 | System block diagram of the Program Defined Entertainment State System (PD-ESS) showing the application plane, control plane, and state data plane layers with ACI and CSDI interfaces.Search in Eureka ↗ | System architecture |
| FIG. 4 | Explosion diagram of the PD-ESS application plane layer showing GUI elements, processor, bus, database, logic modules, ACI Drivers, and memory.Search in Eureka ↗ | Claim support |
| FIG. 5 | Explosion diagram of the PD-ESS control plane layer showing Cognitive Computing unit (AI Unit, Machine Learning), Analytics, SD-ESS Control Logic, Processor, Storage, Application Interfaces, and CSDPI Drivers.Search in Eureka ↗ | Claim support |
| FIG. 6 | Explosion diagram of the PD-ESS state data plane layer showing Entertainment State Network Element with I/O Controller, State Processor, GUI Generator, Display, and Value/Title Transfer Network Element with I/O Controller and Processor.Search in Eureka ↗ | Claim support |
| FIG. 7 | Ecosystem interfaces and interconnections diagram showing Developers, Affiliates, Operators, Platform (Vaporized Lottery), Consumers, Regulator, and State with financial transfer flows.Search in Eureka ↗ | Key embodiment |
| FIG. 8 | Neural network model architecture block diagram showing multi-GPU encoder-decoder architecture with GPU1 through GPUN layers.Search in Eureka ↗ | Key embodiment |
| FIG. 9 | Neural network architecture showing three parallel recurrent network chains with memory nodes (X0, X1, X2) across time steps.Search in Eureka ↗ | Key embodiment |
| FIG. 10 | System level diagram showing multiple data sets (DA1–DAn) feeding into a Data Analyzer and Difference Engine to produce output data sets (D1–Dn).Search in Eureka ↗ | Claim support |
| FIG. 11 | Response system display showing AR/VR/standard headset users, a Controller Processor with Behavior Detection Hardware and Software, Camera, Microphone Array, and Physiologic Sensors feeding output to an AI/Machine Learning System.Search in Eureka ↗ | Key embodiment |
| FIG. 12 | Dynamic systems d-API diagram showing Developer/Affiliate/Operator interacting with an API connected to System, with an Intelligent Update component above.Search in Eureka ↗ | System architecture |
| FIG. 13 | Dynamic systems d-SDK diagram showing Developer connected to a Software Developer Kit linked to System with an Intelligent Update component above.Search in Eureka ↗ | System architecture |
| FIG. 14 | Architecture diagram showing distributed apps layered above Transaction Manager, Crypto Enclave, Quorum Chain, and Network Manager modules, all sitting on an Ethereum foundation.Search in Eureka ↗ | System architecture |
| FIG. 15 | Permissioned system diagram showing Client A and Client B each with a Dapp User Interface, API, TxPayload Store, Tx Manager, and Quorum Nodes exchanging TxPayload requests/responses via Ethereum Protocol.Search in Eureka ↗ | System architecture |
| FIG. 16 | Blockchain platform diagram showing Identity Module, Device Operation Module, Consensus Module, and Smart Contract Module on FABRIC Hyperledger in Cloud/Hybrid configurations.Search in Eureka ↗ | System architecture |
| FIG. 17 | Open chain platform architecture showing Membership Services, Blockchain Services (Consensus Manager, Distributed Ledger, PP2P Protocol, Ledger Storage, Event Hub), and Chain-code Services (Secure Container, Secure Registry) under Openchain APIs/SDKs/CLI.Search in Eureka ↗ | System architecture |
| FIG. 18 | Schematic of a decentralized cryptocurrency system with smart contracts showing Users inputting Money and Data into a Contracts block with Code and Storage, producing Mined Blocks chained sequentially.Search in Eureka ↗ | Claim support |
| FIG. 19 | Sequential hash value creation schematic showing Hash Value + Block + Nonce chained sequentially to produce New Hash Values.Search in Eureka ↗ | Claim support |
| FIG. 20 | Flowchart for cryptocurrency lottery showing Define Conditions → Receive Cryptocurrency → Time Limit Reached? → Generate Random Event → Effect Title/Value Transfer.Search in Eureka ↗ | Flow diagram |
| FIG. 21 | Smart contract flowchart showing Define 'If Then' Conditions → Monitor For 1st 'If' → 1st 'if' Met? → Fulfill 'Then'.Search in Eureka ↗ | Flow diagram |
| FIG. 22 | Smart-Smart (Smart²) contracts diagram showing 1st Input and 1st Output connected to 1st Smart Contract with an Intelligent Update component above.Search in Eureka ↗ | Claim support |
| FIG. 23 | Smart contracts with mandated and variable parameters flowchart showing Define Sequence of Events → Input and Store Mandated Parameters → Time Limit Reached? → Obtain Random Outcome → Transfer Value/Title.Search in Eureka ↗ | Flow diagram |
| FIG. 24 | Cryptocurrency wallet GUI showing Wallet and Send tabs, account total in Ether, Coins, Points (Loyalty, Frequency, Airtimes), and latest transactions list.Search in Eureka ↗ | UI/interface |
| FIG. 25 | Schematic diagram of segregated public and secure functions showing End Users connecting through Interface Portal (Control, GUI, Processor) to a Secure Entity (Game Engine, User Secure Information, Financial Engine) with interface to Tax and Financial Institutions.Search in Eureka ↗ | Key embodiment |
| FIG. 26 | Interface of segregated secure and public functions diagram showing Public Functions calling Secure Functions (Game RNG, User Information, Financial Information) with Return path to Financial Institutions.Search in Eureka ↗ | Key embodiment |
| FIG. 27 | Network implementation of segregated secure and public functions showing multiple User Devices connecting via cloud to Public Interface / State Lottery N modules which call/return to a Secure Entity.Search in Eureka ↗ | System architecture |
| FIG. 28 | Combined centralized and decentralized systems architecture showing a Central System connected via cloud to a distributed peer network.Search in Eureka ↗ | System architecture |
| FIG. 29 | Hierarchical systems diagram showing a Master node controlling two Slave nodes (Slave 1 and Slave 2).Search in Eureka ↗ | System architecture |
| FIG. 30 | Plan view of a lottery linked credit card showing 'First USA Lottery' branding with cardholder name Joseph A. Smith and masked card number.Search in Eureka ↗ | UI/interface |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent presents only 1 independent claim (Claim 1) of method type, with 19 dependent claims building on it — a dependent-to-independent ratio of 19:1, significantly above the typical 4–8:1 norm for the G06Q/G07F IPC classes. The sole independent claim employs the 'comprising' transition, reciting a three-plane architecture (application plane, control plane with cognitive computing unit, data plane with title/value transfer and cryptocurrency elements). Importantly, the filing omits system/apparatus and computer-readable medium claim types entirely, leaving significant design-around opportunities and enforcement gaps in a technology area where multi-format claim suites are standard.
Core inventive concept: Claim 1 addresses the problem of interoperability and intelligent control in gaming/transaction systems by reciting a programmatically-defined three-layer architecture: an application plane layer that receives operating instructions, a control plane layer including a cognitive computing unit (AI/ML) with a difference engine and transformation engine, and a data plane layer that interfaces with a decentralized distributed ledger and a title/value transfer element for storing cryptocurrency information — where the control plane translates application requirements to the data plane and receives IoT/sensor data for AI training.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method for the control of a program defined transaction system utilizing a decentralized distributed ledger, the system including at least an application plane layer, a control plane layer including an adaptive control unit including a cognitive computing unit, and a data plane layer | comprising | receiving instructions at application plane layer coupled to application plane layer interface communicating to control plane via application controller interface; interfacing control plane layer with application plane layer via application plane layer interface; control plane including cognitive computing unit; control plane including difference engine and transformation engine; control plane translating requirements to data plane; receiving at data plane input interface information related to cryptocurrency transfer; data plane including title and value transfer element; data plane coupled to control plane layerSearch prior art ↗ |
Claim Dependency Tree
1 Method for control of program defined transaction system using decentralized distributed ledger; three-plane architecture with cognitive computing unit, difference engine, transformation engine, and cryptocurrency data planeSearch Claim 1 prior art ↗
2 Adds: decentralized distributed ledger is a blockchainSearch in Eureka ↗
3 Adds: information received at data plane stored in title and value transfer element to implement smart contract via decentralized distributed ledgerSearch in Eureka ↗
4 Further: smart contract implements a lotterySearch in Eureka ↗
5 Further: smart contract to implement lottery includes a time frame in which to receive cryptocurrencySearch in Eureka ↗
6 Further: smart contract implements a game mechanicSearch in Eureka ↗
7 Further: smart contract implements a core loopSearch in Eureka ↗
8 Further: smart contract implements mandated parametersSearch in Eureka ↗
9 Further: smart contract implements a player's clubSearch in Eureka ↗
10 Further: smart contract transfers a smart propertySearch in Eureka ↗
11 Adds: further receiving at input interface sensor output data used to train the cognitive computing unitSearch in Eureka ↗
12 Adds: further including a geolocation limitSearch in Eureka ↗
13 Adds: data plane layer further including permissioned accessSearch in Eureka ↗
14 Adds: data plane layer further including permission less accessSearch in Eureka ↗
15 Adds: control plane layer includes an analytics unitSearch in Eureka ↗
16 Adds: further receiving at data plane input interface information related to Internet of Things (IoT) dataSearch in Eureka ↗
17 Adds: further storing information in title and value transfer element to transfer a digital asset via decentralized distributed ledgerSearch in Eureka ↗
18 Further: digital asset is an imageSearch in Eureka ↗
19 Further: digital asset is audible contentSearch in Eureka ↗
20 Further: digital asset is a digital documentSearch in Eureka ↗
| Metric | This Application | Software / Blockchain Norm |
|---|---|---|
| Total claims | 20 | 15 – 25 |
| Independent claim count | 1 | 3 – 5 |
| Dependent : Independent ratio | 19.00 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Common |
| System / apparatus claims? | No | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The specification's most notable strength is its unusually extensive technical disclosure — 17 figures and a comprehensive glossary covering blockchain, AI/ML, and smart contract mechanics — which provides a broad written description base for potential continuation claims. However, the critical weakness is the single-independent-claim structure: Claim 1 carries all prosecution weight with no system or CRM fallback, leaving the entire patent vulnerable to a single Alice/§101 rejection that could invalidate the only independent claim without any alternative claim type to retreat to.
✅
Antecedent Basis
The claim set is structurally clean with respect to antecedent basis. Key elements introduced in Claim 1 — 'the application plane layer,' 'the control plane layer,' 'the cognitive computing unit,' and 'the data plane layer' — are each properly introduced before being referenced with the definite article in subsequent dependent claims. Claims 4–10 all reference 'the smart contract' which finds its antecedent basis in Claim 3's introduction of 'a smart contract via the decentralized distributed ledger,' creating a clean dependency chain. No orphaned 'the' references were identified across the 20 claims.
✅
Spec–Claim Consistency
The three-plane architecture recited in Claim 1 maps directly to FIG. 3 (overall PD-ESS block diagram), FIG. 4 (application plane explosion), FIG. 5 (control plane explosion showing cognitive computing, AI unit, machine learning, analytics, and CSDPI Driver), and FIG. 6 (state data plane explosion with Entertainment State Network Element and Value/Title Transfer Network Element). Paragraphs [0061]–[0067] provide detailed textual support for each layer. The difference engine limitation in Claim 1 is directly supported by FIG. 10 and paragraphs [0089]–[0090]. The cryptocurrency data limitation is supported by FIGs. 14–19 and paragraphs [0105]–[0119].
✅
Transition Word Usage
The sole independent Claim 1 uses 'comprising,' which is the broadest and most appropriate transition for a method claim in this technology space — it permits the system to include additional components (e.g., additional network layers, regulatory interfaces) without limiting the claim scope. All 19 dependent claims use the correct form 'further including' or 'wherein,' which is standard and appropriate. No 'consisting of' or 'consisting essentially of' language is used anywhere in the claims, correctly preserving maximal breadth for this type of system claim.
⚠️
§112(f) Means-Plus-Function Risk
Claim 1 recites 'a difference engine to identify differences between at least a first set of stored data and a second set of stored data' and 'a transformation engine to transform data' — both of which use functional label language ('engine to [perform function]') without explicit structural definition in the claim body. While 'engine' is not 'means for,' USPTO examiners may argue these terms invoke §112(f) treatment, particularly if the specification does not clearly define hardware structure for each engine. FIG. 10 and paragraph [0089]–[0090] provide some support for the difference engine as a distinct hardware/software module, but the transformation engine has thinner specification support, creating potential §112(f) and §112(b) indefiniteness exposure.
⚠️
§101 Eligibility Risk
Claim 1 faces significant Alice/Mayo exposure: its core operations — receiving instructions, interfacing layers, translating requirements, and receiving cryptocurrency data — are framed as abstract information processing steps without a clear, hardware-specific inventive concept beyond generic computing components. The 'cognitive computing unit' and 'decentralized distributed ledger' elements provide the strongest §101 defense, but examiners in Art Units 3685 and 3689 (blockchain/fintech) routinely reject such three-layer software architectures as directed to an abstract idea of organizing information. The absence of apparatus or CRM claims means a successful §101 rejection against Claim 1 leaves the entire application with no independent claim to prosecute. Continuations or claim amendments adding specific technological improvements would materially reduce this risk.
⚠️
Dependent Claim Fallback Quality
The dependent claim set has mixed quality. Claims 2 (blockchain specification), 11 (sensor training data), 12 (geolocation), 16 (IoT data), and 17 (digital asset transfer) add genuinely distinct technical limitations that could survive as narrowing fallback positions if Claim 1 is rejected. However, Claims 4–10 all depend through the intermediate Claim 3 (smart contract implementation) and collectively narrow only the type of smart contract function (lottery, game mechanic, core loop, mandated parameters, player's club, smart property transfer) — these are commercially important but legally thin distinctions that offer little structural differentiation from a prior art perspective. Claims 13 and 14 (permissioned vs. permissionless access) are legally meaningful alternatives but could have been written as competing independent claims for stronger fallback protection.
⚠️
Abstract Quality
The abstract describes the three-plane architecture accurately but at a high level that obscures the specific novel contribution: it states the system 'includes an application plane layer adapted to receive instructions regarding operation of the transaction state system' — language so broad it could describe any software-defined network. The abstract does not mention the difference engine, transformation engine, or the specific cognitive computing mechanism that distinguishes this filing from generic blockchain systems. An examiner reading only the abstract would likely classify this as a routine blockchain transaction management application, potentially triggering a formulaic §101 rejection before the examiner reaches the claims' more specific limitations.
✅
Figure Support Quality
Figure support for the structural limitations in Claim 1 is strong. FIG. 3 maps directly to the three-plane overview; FIG. 5 supports the cognitive computing unit, AI unit, machine learning, and analytics elements; FIG. 10 supports the difference engine; FIG. 6 supports the title and value transfer element; and FIGs. 14–19 collectively support the decentralized distributed ledger and cryptocurrency elements. The transformation engine limitation in Claim 1 has the weakest figure support — FIG. 10 shows the Difference Engine as a separate module but does not clearly depict the transformation engine as a distinct structural component, creating a potential written description vulnerability for this specific limitation.
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Scorecard
Strategic Intent Scorecard
Multi-dimensional assessment of this application's patent strategy quality, based on claim structure, specification depth, and prosecution positioning.
Claim Breadth
3
Prosecution Defensibility
2
Spec–Claim Consistency
3.8
Dependent Claim Coverage
2.5
Claim Type Diversity
1.5
Figure Support Quality
3.5
Key observation: The highest-scoring dimension is Spec–Claim Consistency (3.8/5.0): FIGs. 3–6 and 10, along with paragraphs [0061]–[0067] and [0089]–[0090], provide direct, named structural support for nearly every limitation in Claim 1, reflecting the benefit of a long continuation family that has refined the disclosure over multiple prosecution cycles. The lowest-scoring dimension is Claim Type Diversity (1.5/5.0): the filing presents only a single method independent claim with no system, apparatus, CRM, or Beauregard-style claims — a significant strategic omission that means a competitor can implement the identical three-plane architecture in hardware or ship it on a storage medium without infringing this patent. A practitioner reviewing this family should file a continuation with apparatus and CRM claims drawn to the same three-plane architecture before the application publishes any further prior art against the family.
See how your own draft compares — Open Eureka IP Drafting →
Critical Gaps
3 Critical Gaps in This Claim Set
A senior-attorney lens on the three highest-priority structural weaknesses — what each exposes in prosecution and litigation, and what a stronger filing would have done differently.
🔒
3 Critical Gaps in This Claim Set
See the full attorney-level analysis of what this application leaves unprotected — and how to draft it more defensively for your own filings.
Missing system and CRM claim types Transformation engine §112 vulnerability Segregated secure/public function unclaimed
Unlock Full Analysis — Free Frequently asked questions
US 2024/0127063 A1 — key questions answered
Still have questions? PatSnap Eureka can answer them from patent data instantly. Search in Eureka
Disclaimer: This analysis is generated by PatSnap Eureka AI based on publicly available patent data from the USPTO. It does not constitute legal advice and should not be relied upon as such. Patent data may be subject to change as prosecution progresses. Scores and assessments reflect automated analysis and may not capture all relevant legal or technical nuances. Always consult a qualified patent attorney for formal legal opinions on patentability, freedom to operate, or infringement.
Ask anything about this patent.
PatSnap Eureka searches patents and data to answer instantly.
PatSnap Eureka searches patents and data to answer instantly.
Powered by PatSnap Eureka
Link copied to clipboard