Intrinsic Innovation received US12715127B2 on Aug. 25 for a software interface that separates a real-time robot action from the particular hardware parts used to perform it. Claim 1 defines feature interfaces for hardware functionality, groups those interfaces into slots, maps each slot to a particular part and invokes the action by supplying part identifiers. The claimed abstraction is intended to let the control system determine whether selected parts implement the capabilities an action requires.
The portability mechanism is explicit in the dependent claims. The same real-time action can be invoked on a different robotic system by providing different identifiers, and the controller can raise an error when an assigned part does not implement every interface required by a slot. In plain terms, the action specifies the capabilities it needs while the invocation binds those capabilities to actual component modules. The patent does not claim every possible reusable robot program; it claims a defined interface, slot and identifier arrangement.
The real-time action is invoked including providing a respective part identifier of a part for each of the one or more feature interfaces called by the real-time action.— Feature interfaces for real-time robotics control, US12715127B2
That arrangement addresses a practical industrial problem. A motion or process routine can be difficult to reuse when it is tightly coupled to one arm, gripper, sensor or drive implementation. A capability interface offers a compatibility layer, but the record does not publish integration-time savings, cycle-time benchmarks or the range of hardware tested. The issued claims establish the software structure and validation behavior rather than measured interoperability across a named fleet.
How the surrounding record changes the read
Two other Aug. 25 grants fill out the real-time control layer. US12715125B2 covers an error object returned from a custom action to the invoking real-time session and a recovery process in response. US12715118B2 links an onsite execution subsystem to a cloud-based belief-world store that receives workcell sensor data. Together, the records address capability binding, fault recovery and the relationship between local control and cloud-maintained state.
The surrounding portfolio reaches planning and perception. US12718391B2 uses polarization maps and surface normals to regularize stereo-image correspondence. The Aug. 18 grant US12709005B2 checks resource and occupied-volume footprints before running robot skills concurrently, while US12697732B2 adapts manipulation plans to deformation estimates built from point-cloud edge constraints. These are separate claims, not features automatically imported into the interface patent.
Because the hero record is granted, its claims have passed examination in their issued form. That does not determine validity in every later dispute, prove infringement by another control stack or establish that a commercial product implements each element. It does make the status materially different from a pending publication: the public record now contains an enforceable claim directed to the stated feature-interface architecture.
What the documents establish
The portfolio maps a layered robot software problem. Hardware capabilities must be described and bound to actions; errors must return through real-time-safe paths; world state can be maintained beyond the controller; planners must avoid resource conflicts; and perception must turn sensor data into geometry. The recent grants distribute those responsibilities across distinct records rather than presenting a single all-purpose autonomy claim.
The Aug. 25 contribution is therefore best stated precisely. Intrinsic now has issued coverage on invoking real-time actions through feature-interface slots mapped to identified component modules, including compatibility checks and reuse on different systems. Whether that abstraction reduces deployment cost or becomes a de facto integration layer is a product and market question. The patent record supplies the architecture, while later documentation and deployments must supply the outcome.
The evidentiary boundary is important when reading any patent record as news. The abstract explains the disclosed idea at a high level, the specification supplies examples and alternatives, and the claims define the combinations for which legal coverage is requested or granted. Those layers are related but not interchangeable. A feature described in the specification may be optional rather than claimed, and a result named in an abstract may depend on implementation choices not recited in claim 1. For a pending application, examination may alter the language before any right issues. For a granted patent, the issued text is enforceable in principle but remains subject to construction, validity and application to particular facts. None of those documents, standing alone, proves that a product ships, that a prototype met a target, or that the assignee assigns the work a particular commercial priority.
Portfolio context needs the same discipline. A same-day cohort can reveal repeated technical problems, shared interfaces and adjacent layers of a system, but separate records remain separate legal instruments. Counts may also include continuations, related applications, spelling variants in assignee names or parallel claim formats. The useful signal comes from reading representative claims and mechanisms together, not from treating every document as equal or adding them into a synthetic super-patent. Later events provide the tests: amendments show what an applicant gives up, grants show what survives examination, assignments show ownership changes, and product or financial disclosures can connect the public claim record to operating reality. Until those confirmations appear, the analysis should describe direction and architecture while leaving performance, adoption, value, infringement and competitive outcome unresolved.
A final distinction concerns timing. The issue or publication date marks when the record entered its present public form; it is not the invention date, the filing date or a product-launch date. Related engineering may be older, newer or proceeding on a different schedule. The date is still useful because it gives the portfolio analysis a reproducible boundary and lets later readers compare what was public at a particular moment. It should not be converted into a claim that research began, ended or reached production that week.
Comments
Loading comments…