Five questions your CTO should be asking about reconciliation infrastructure

If you run blockchain infrastructure, your patent counsel should be asking your technical team these questions. If they are not, you have a gap in your IP risk assessment. These map directly to claim elements in the Rock Innovation patent family.

1. Do we maintain persistent connections to one or more blockchains and retrieve data from them based on preconfigured parameters?

Many blockchain products connect to a network such as Ethereum, Arbitrum, or Polygon and specify data to watch, including contract events, transaction types, block ranges, or account balances. Document the actual connection and retrieval behavior rather than assuming it from the product category.

Connection, parameter configuration, and data retrieval resemble language in the claims. Counsel should determine whether the actual components and relationships meet those limitations.

2. Do we apply any form of logic to that data before recording an output?

This is where most engineering teams say "of course." Your system does more than copy blockchain data from one place to another. It validates, filters, transforms, aggregates, or otherwise processes the data before writing a result. A rollup applies execution rules. A bridge applies verification rules. An oracle applies aggregation rules. A DeFi protocol applies financial rules.

Rule application and output compilation appear as distinct limitations. General processing is not enough to conclude that those terms are met without examining what the system actually does.

3. Do we store the output on-chain or use it to trigger on-chain transactions?

The '711 independent claims include storage of compilation objects on one or more blockchains. A state root, mint transaction, price update, or settlement record may be a comparison point, but the claim term and surrounding limitations still require analysis.

Systems that never write results to a ledger differ from systems that do. Writing back does not, by itself, complete the full claim.

4. Can we document when our architecture first went into production?

Rock Innovation claims priority through November 19, 2016. Evidence that an architecture was publicly available before the relevant effective filing date may matter to a prior-art analysis; a later production date does not itself establish exposure.

Production date is not the same as founding date or first commit date. It is the date your system first performed the claimed operations in a live environment. Engineering teams should be able to document this with deployment logs, release records, or customer contracts. If you cannot pin down when your reconciliation architecture went live, that is a problem independent of any specific patent.

5. Has anyone on our team actually read the patent claims?

Engineering teams sometimes assume independent development ends the patent inquiry. Under U.S. patent law, independent development generally is not, by itself, a complete defense, but the facts and available defenses should be reviewed by qualified counsel.

The Rock Innovation family has three patents with 28 total claims. A useful review requires claim construction, a defined product version, reliable technical evidence, and an element-by-element comparison. The time and outcome cannot be predicted from the claim count.

What comes after the questions

If the first questions identify possible comparison points, review the claims and prosecution history rather than drawing a conclusion from the checklist. Claim-chart templates are available at rockinnovationip.com for counsel to adapt to verified product evidence.

Ignoring the questions does not eliminate the risk. It eliminates your ability to manage it.