CyberMDCare
CyberMDCare Files Five Non-Provisional Patent Applications with the USPTO for the CMD Nova AI Platform and BioSignBox.
Filing window Jul 3–8, 2026.
Between July 3 and July 8, 2026, CyberMDCare filed a total of five Non-Provisional Patent Applications with the United States Patent and Trademark Office (USPTO) under 35 U.S.C. § 111(a) — Patent Pending — covering the foundational architecture of the CMD Nova AI Platform and, as of today, its BioSignBox biometric signature technology.
Filing as non-provisional applications — rather than provisional placeholders — moves CyberMDCare's technology directly into USPTO examination and establishes an early priority date for the claimed innovations. As with any pending patent application, the scope of protection will be determined through the examination process and formalized only upon issuance; CyberMDCare will provide further updates as prosecution of these applications progresses.
Patent Portfolio01 / 05
The Five-Application Patent Portfolio
CyberMDCare's portfolio now consists of five related, non-provisional patent applications: a foundational platform application filed July 3, 2026, three module-specific applications describing distinct AI components of the CMDNova platform filed July 7, 2026, and a dedicated BioSignBox application filed July 8, 2026. The applications cross-reference one another as part of a single, integrated system. Rather than standalone features, the applications are designed so that each module's raw-data output is intended to feed directly into the next module in sequence — an architecture we refer to internally as a sequential inference pipeline.
| Application # | Filing Date | Title / Internal Module Name |
|---|---|---|
| 19/730,874 | July 3, 2026 | Foundational Application — Integrated Multi-Tenant SaaS Platform for Asynchronous PQR Clinical Data-Driven Real-Time Wellness Visit Progress Calculation, Automated Drop-off Management, Chronic Disease Patient Sorting, and Monthly Electronic Signature-Integrated Billing Progress Computation |
| 19/732,954 | July 7, 2026 | Application 1 — Multi-Modal Clinical Data Organization and Prioritization Engine (clinical30DayDataStore) |
| 19/732,985 | July 7, 2026 | Application 2 — Predictive HCC AI Inference Engine (clinicalEvidenceEngine) |
| 19/733,006 | July 7, 2026 | Application 3 — Secure Communication Gateway (clinicalSecureDsmGateway) |
| 19/734,208 | July 8, 2026 | BioSignBox — A Multi-Modal Biometric Evidentiary Capture System and Method for Electronic Signature Non-Repudiation and Signature Fraud Prevention |
Application numbers reflect USPTO electronic filing receipts as of July 8, 2026 and are provided for transparency; confirmation numbers, examination assignment, and any renumbering upon formal Filing Receipt issuance remain subject to USPTO processing.
Conceptual illustration — the sequential inference pipeline: each module's raw-data output is designed to feed directly into the next.
Sequential Inference Pipeline02 / 05
How the Applications Work, Step by Step
Select a stage below to read its technical description — each module's raw-data output is designed to feed directly into the next.
Conceptual illustration — P-FLOW / Q-FLOW / R-FLOW streams combined into a composite risk tier.
Application 1 — Multi-Modal Clinical Data Organization and Prioritization Engine (P·Q·R Clinical Engine)
Internally, this module is referred to as clinical30DayDataStore. It is designed to ingest three distinct streams of raw clinical data over a rolling 30-day window: touch-coordinate anatomical pain-location data (referred to internally as P-FLOW), structured clinical questionnaire responses (Q-FLOW), and continuous biometric vital-sign telemetry (R-FLOW). Rather than relying on a single static score, the module is designed to combine these raw data streams through what we refer to internally as a Dynamic Tensor Fusion Engine — a dynamic weighting process intended to recalibrate automatically when a given data modality is incomplete or unavailable for a particular patient.
The output is a composite clinical risk stratification across three tiers — Major Risk (MJ), Minor Risk (MN), and No Significant Risk — generated, in our design intent, in real time and as part of clinician workflow preparation. Alongside each risk tier, the module is designed to generate a per-modality contributing-factor weight breakdown, showing the relative contribution of the P-FLOW, Q-FLOW, and R-FLOW data streams to the resulting output. This is intended to give a treating clinician a transparent, human-readable view of which underlying data points most influenced a given result, consistent with the explainable-AI (XAI) design approach discussed further below.
Conceptual illustration — candidate HCC codes ranked by statistical confidence, generated ahead of physician diagnosis entry.
Application 2 — Predictive HCC AI Inference Engine
Internally, this module is referred to as clinicalEvidenceEngine. Rather than simply absorbing a static risk grade, this module is designed to take the Major Risk / Minor Risk grade generated by Application 1 and cross-reference it against the underlying P-FLOW, Q-FLOW, and R-FLOW raw data arrays, together with patient demographic variables. Using a multi-label deep learning model, it is designed to generate a probability-ranked set of Hierarchical Condition Category (HCC) codes intended to align with CMS risk-adjustment models, including both CMS-HCC Version 24 and Version 28.
Each candidate code is designed to be presented together with an associated statistical confidence level and the underlying clinical data features that contributed to the prediction. This process is intended to occur at the Pre-Diagnostic stage — before a physician's formal diagnosis entry — so that the output functions as reference information a clinician can consider, modify, or reject, with the goal of supporting, not replacing, the clinician's diagnostic process. No code is designed to be entered into the clinical record without an affirmative clinician action.
Conceptual illustration — raw clinical data sealed into a tamper-resistant integrity structure (DSM) with a chained audit log.
Application 3 — Secure Communication Gateway
Internally, this module is referred to as clinicalSecureDsmGateway. The module is designed to be triggered once a clinical attestation has been captured through an electronic-signature interface referred to internally as BioSignBox (described in more detail below). Upon that attestation, the module is designed to align the validated HCC code set with actuarial tables to generate a forward-looking risk-adjustment concept illustration, intended purely as an informational reference for the treating clinician rather than as a coding recommendation in itself.
In parallel, the module is designed to cryptographically process the underlying P-FLOW, Q-FLOW, and R-FLOW raw data — using SHA-3 hashing, RSA-4096 or ECDSA-P384 digital signatures, and AES-256 encryption — to generate what we refer to internally as a Digital Security Message (DSM). The DSM is designed to be delivered to a clinician's Electronic Health Record (EHR) system as a tamper-resistant, timestamped document attachment transmitted via the HL7 FHIR R4 DocumentReference standard, and to be accompanied by an append-only, cryptographically chained audit log recording each inference event and the clinician's corresponding action — accept, modify, or reject. This architecture is intended to preserve, in a forensically verifiable format, the underlying clinical data that existed at the moment a coding determination was made, supporting documentation integrity alongside, rather than in place of, a clinician's own clinical notes.
How the Three Applications Are Designed to Work Together
The three applications are designed so that each module's output is intended to become the next module's input: Application 1 stratifies raw P-FLOW, Q-FLOW, and R-FLOW data into a composite risk tier; Application 2 re-examines that tier against the same underlying raw data to generate a ranked set of candidate HCC codes; and Application 3 converts clinician-confirmed codes into a risk-adjustment concept illustration while cryptographically sealing the underlying data trail into a DSM record. Because each stage is designed to depend on the raw data and outputs of the prior stage, we view the three applications as describing interdependent components of a single integrated architecture, rather than as three independent, severable features — a distinction we believe supports a stronger overall patent position than protecting any single module in isolation.
Portfolio Highlights03 / 05
Key Characteristics of the Patent Portfolio
Filed as non-provisional applications. Establishes an early priority date and places the technology on a direct path toward examination, rather than relying on a provisional placeholder.
An integrated, cross-referenced architecture. The applications describe interconnected modules of a single platform rather than standalone, unrelated features.
BioSignBox as a differentiated capability, now non-provisional. Our dual-biometric identity verification technology — protected by its own non-provisional utility patent application (No. 19/734,208, filed July 8, 2026) — is designed to address identity verification and beneficiary fraud risks unique to virtual care, a capability we believe is not currently offered by competitors.
Pre-diagnostic design. The system is built to generate risk intelligence before physician diagnosis entry, distinguishing it from retrospective, post-encounter tools.
Layered cryptographic architecture. Application 3 is designed to incorporate SHA-3 hashing, RSA-4096 / ECDSA-P384 digital signatures, and AES-256 encryption to generate a tamper-resistant integrity structure (DSM), together with a cryptographically chained, append-only audit log of each AI inference event and clinician action.
Built-in explainability (XAI). Application 1 is designed to accompany every risk-stratification output with a per-modality contributing-factor weight breakdown, intended to let a treating clinician see which underlying data points most influenced a given result.
Patent protection is not final or guaranteed until a patent is examined and formally issued by the USPTO. The scope of any resulting patent claims may differ from what is described in the original filings.
Compliance04 / 05
Legal and Regulatory Considerations — and How We're Addressing Them
Operating at the intersection of AI, clinical decision support, and federal healthcare billing involves real regulatory complexity. CyberMDCare has designed its platform with the following considerations in mind, and continues to work with legal and compliance advisors to refine these safeguards as the platform evolves.
01 Intellectual property risk: competitors attempting to replicate the technology.
Our approach: The patent applications describe an interconnected architecture, and we believe pursuing protection across the full pipeline — from data capture through inference to secure delivery — provides a stronger overall position than protecting a single, isolated feature. We will continue to monitor the market and pursue our IP rights as the applications proceed through examination.
02 Regulatory risk: potential scrutiny under the Federal False Claims Act (FCA) regarding automated coding.
Our approach: CyberMDCare's platform is designed to function as an advisory clinical decision-support tool. Final review, validation, and submission of any billing code remain the responsibility of the treating clinician. We believe this design supports a lower-risk profile relative to tools that generate or submit codes without clinician consideration, though outcomes ultimately depend on how the platform is implemented and used by each customer.
03 Regulatory risk: CMS Risk Adjustment Data Validation (RADV) audits.
Our approach: Application 3 (clinicalSecureDsmGateway) is designed to preserve the underlying P-FLOW, Q-FLOW, and R-FLOW clinical data used to generate its outputs in a cryptographically sealed, tamper-resistant integrity structure (DSM), delivered to the EHR alongside the resulting documentation via the HL7 FHIR R4 DocumentReference standard. We believe this is intended to help health systems demonstrate the basis for coding decisions if reviewed, though it does not eliminate audit risk, does not replace physician-signed clinical notes, and is not a substitute for each customer's own documentation and compliance practices.
04 Regulatory risk: restrictions on opaque (“black-box”) AI in clinical and billing contexts, including under Executive Order 14110.
Our approach: Application 1 (clinical30DayDataStore) is designed to provide feature-level transparency, generating a per-modality contributing-factor weight breakdown across the P-FLOW, Q-FLOW, and R-FLOW data streams alongside every risk-stratification output, with the goal of supporting clinician consideration and explainability rather than functioning as an unreviewable system.
05 Data privacy and security risk related to biometric identity data, including facial and behavioral biometric information.
Our approach: Data captured through BioSignBox — including facial topography parameters and behavioral ink dynamics — is intended to be encrypted, access-controlled, and used strictly for identity verification purposes. We recognize that facial and behavioral biometric identifiers are subject to a growing body of state biometric privacy laws (such as Illinois' Biometric Information Privacy Act and comparable statutes in other states), which can impose specific consent, notice, and data-retention requirements. As BioSignBox advances from development toward commercialization, CyberMDCare intends to align its data-handling practices with applicable biometric privacy requirements in the jurisdictions where it operates. Customers remain responsible for their own HIPAA and applicable state biometric privacy law compliance obligations in connection with their use of the platform.
06 Jurisdictional Restriction & Geocontrol Notice.
CyberMDCare and its BioSignBox identity assurance platform operate strictly outside the State of Illinois. Our services, applications, and technical platforms are not available to, nor do they process raw data for, any individuals, residents, or entities operating within the State of Illinois. The platform does not collect, process, or store biometric identifiers or biometric information subject to the Illinois Biometric Information Privacy Act (BIPA) regulations. Any access from unauthorized jurisdictions is strictly prohibited.
07 Platform Provider Limitation of Liability & Documentation Support Disclaimer.
BioSignBox is a technical Software-as-a-Service (SaaS) architecture designed solely to support and streamline administrative clinician documentation and care-management workflows. The platform does not generate medical diagnoses, determine clinical codes, or execute sovereign legal consent independently. Any clinical utilization, final Hierarchical Condition Category (HCC) coding, Medicare Annual Wellness Visit (AWV) billing progress computation, or the determination of the legal validity of consent is strictly dependent upon, and the sole legal responsibility of, the deploying healthcare organization, independent physician association (IPA), or licensed provider. Full compliance with HIPAA safeguards, federal audit guidelines, and state-level electronic signature requirements remains explicitly vested in the clinical end-user entity.
CyberMDCare's philosophy is to build legal and regulatory considerations into the architecture from the outset. We believe this approach supports a responsible path into the U.S. Medicare Advantage and Accountable Care Organization (ACO) markets, while recognizing that regulatory outcomes depend on a range of factors outside any single company's control.
Identity Assurance05 / 05
BioSignBox: Identity Verification in Virtual Care
One of the most critical challenges arising from the expansion of virtual care is the vulnerability of patient identity verification. BioSignBox is our dual-biometric signature technology currently under development to address this challenge proactively.
Conceptual illustration — dual-biometric capture combining facial topography parameters and behavioral ink dynamics into a single verified signature.
Dual Biometric Capture
BioSignBox is our proprietary dual-biometric framework engineered to cross-verify intent by combining facial topography parameters, behavioral ink dynamics, and secure session logs — directly confronting the identity verification and beneficiary fraud challenges inherent in virtual care.
Non-Repudiation
The goal is to create a structure that can technically verify — in the event of a future dispute — that consent was given by the actual patient.
Risk Management
Given the U.S. medical litigation environment and regulatory audit risks, this capability aims to serve as a meaningful risk management tool for medical institutions.
Development Status
BioSignBox is currently under active development and has not yet been commercialized. As of July 8, 2026, CyberMDCare's six prior-filed U.S. provisional patent applications covering BioSignBox have been converted and consolidated into a single, formal Non-Provisional Utility Patent Application — “BioSignBox: A Multi-Modal Biometric Evidentiary Capture System and Method for Electronic Signature Non-Repudiation and Signature Fraud Prevention” (Application No. 19/734,208), filed under 35 U.S.C. § 111(a) and claiming priority to those six provisional filings. This moves BioSignBox directly into the USPTO examination track, alongside the four related CMD Nova AI Platform applications described above. The scope of any eventual patent protection will be determined upon completion of the USPTO examination process, and formal claims may differ from those in the original filings.
We are not aware of publicly documented solutions in the digital health or value-based care space offering a comparable dual-biometric, non-repudiation capability purpose-built for virtual care identity verification. We believe this differentiates CyberMDCare's approach to fraud prevention and beneficiary verification in ways current competitors do not address.
As part of its broader IP strategy, CyberMDCare has filed 21 Provisional Patent Applications with the USPTO covering its core technology architecture — including the P·Q·R clinical engine and BioSignBox — to establish priority dates across its full technology ecosystem. Of these, six relating to BioSignBox have since been converted and consolidated into the non-provisional application described above (No. 19/734,208), alongside the four other non-provisional applications covering the CMD Nova AI Platform. The remaining provisional applications continue to secure priority across other elements of CyberMDCare's technology ecosystem as they progress toward their own non-provisional filings.
// Outlook
Market Opportunity
Within Medicare Advantage and ACO value-based care models, reimbursement is closely tied to CMS Risk Adjustment Factor (RAF) scores, and under-coding driven by clinician workload is a well-documented industry challenge. CyberMDCare believes its technology is well positioned to address this challenge and to capture meaningful value in this market over time. These statements reflect our current expectations and are forward-looking; actual results may differ based on regulatory, competitive, and other factors.
This page is provided for general informational purposes and does not constitute legal, financial, or investment advice. Statements regarding patent protection describe applications that are currently pending before the USPTO and have not yet been examined or issued; statements regarding market opportunity and future performance are forward-looking and involve inherent uncertainty. CyberMDCare encourages readers with specific legal or compliance questions to consult qualified counsel.