Derivative works

Defensive Disclosure and Prior Art Generation for Innovations in Software Registration and Licensing

Publication Date: May 11, 2026
Subject: This document discloses novel methods, systems, and applications derived from the foundational concepts of remote software registration and mode-switching as described in US Patent 5,490,216. The purpose of this disclosure is to place these derivative concepts into the public domain, thereby establishing them as prior art.

---

Axis 1: Component and Process Substitution

Derivative 1.1: Asymmetric Cryptography and Certificate-Based Activation

• Enabling Description: This variation replaces the shared-secret algorithm with an asymmetric public-key infrastructure (PKI). The local software on the licensee's platform generates a standard 2048-bit RSA or P-256 elliptic curve public/private key pair. The generated public key, along with a hash of unique platform identifiers (e.g., CPU ID, motherboard serial, MAC address) and user-provided information, is encapsulated in a Certificate Signing Request (CSR) per RFC 2986. This CSR constitutes the "local licensee unique ID." The CSR is transmitted to the remote registration authority, which acts as a Certificate Authority (CA). The CA validates the user information and signs the CSR, generating a unique X.509 client certificate. This certificate, returned to the user, serves as the "enabling key." The local software's mode-switching means unlocks the "use mode" by validating that the installed certificate is signed by the trusted CA root and that the public key in the certificate corresponds to its locally stored private key. Subsequent checks can involve Online Certificate Status Protocol (OCSP) requests to the CA to ensure the license has not been revoked.
• Mermaid Diagram:

  sequenceDiagram
      participant LicenseePlatform as Licensee Platform
      participant RemoteCA as Remote Registration Authority (CA)
  
      LicenseePlatform->>LicenseePlatform: 1. Generate ECC Key Pair (Public/Private)
      LicenseePlatform->>LicenseePlatform: 2. Generate Platform/User Hash
      LicenseePlatform->>RemoteCA: 3. Send Certificate Signing Request (CSR) with Public Key + Hash
      RemoteCA-->>RemoteCA: 4. Verify User & Payment
      RemoteCA-->>LicenseePlatform: 5. Issue and send signed X.509 Certificate (Enabling Key)
      LicenseePlatform->>LicenseePlatform: 6. Install Certificate
      LicenseePlatform->>LicenseePlatform: 7. Validate Cert Chain & Private Key Match
      Note right of LicenseePlatform: Mode switches from 'Demonstration' to 'Use'
      LicenseePlatform-->>RemoteCA: 8. (Optional) Subsequent OCSP check for revocation status
  

Derivative 1.2: Physical Hardware Attestation via Trusted Platform Module (TPM)

• Enabling Description: This method uses a hardware-based root of trust, such as a TPM 2.0 compliant chip, to generate the platform-specific portion of the identifier. The "local licensee unique ID generating means" is a software routine that requests the TPM to generate a quote over a specific set of Platform Configuration Registers (PCRs) and a nonce provided by the remote server. The PCR values reflect the boot state of the platform (firmware, bootloader, OS kernel). The TPM signs this quote with a unique, non-exportable Attestation Identity Key (AIK). The resulting signed quote is sent to the remote registration authority. The "remote licensee unique ID generating means" validates the AIK's authenticity against a database of legitimate TPM manufacturers and verifies the signature on the quote. If the PCR values match a known-good configuration and the signature is valid, the authority returns an enabling key. The software enters "use mode" only on a platform that can produce a valid, signed quote from the same TPM, effectively binding the license to a specific hardware and software state.
• Mermaid Diagram:

  flowchart TD
      subgraph Licensee Platform
          A[Software initiates registration] --> B{Query TPM 2.0};
          B --> C[TPM reads PCR values];
          C --> D{Sign PCRs + Server Nonce with AIK};
          D --> E[Signed Quote (Local ID)];
      end
      subgraph Remote Authority
          F[Receive Signed Quote] --> G{Validate AIK & Signature};
          G -- Valid --> H{Check PCR values against golden measurement};
          H -- Match --> I[Generate & Return Enabling Key];
          H -- No Match --> J[Deny Registration];
          G -- Invalid --> J;
      end
      E --> F;
      I --> K[Software on Platform];
      K --> L{Install Key & Switch to Use Mode};
  

---

Axis 2: Operational Parameter Expansion

Derivative 2.1: Micro-Licensing for High-Frequency API Transactions

• Enabling Description: This disclosure applies the registration concept to a serverless, high-frequency environment for licensing individual API calls. The "software" is a set of premium API endpoints. The "licensee" is a developer's application. During an initial setup, the developer's application authenticates with the remote authority and receives a short-lived JSON Web Token (JWT) per RFC 7519, which contains claims defining the scope of the license (e.g., feature_x: true, rate_limit: 1000/hr). For each API call, the client-side library (the "local generating means") creates a new, temporary signature using a hash of the request payload and a timestamp, signed with a secret key. This signature is included in the request headers. The API gateway (the "remote generating means") validates the JWT and the request signature. A valid combination results in the API call being processed ("use mode"). An invalid signature or expired JWT results in a 403 Forbidden or 429 Too Many Requests error, which functions as the "demonstration mode" (i.e., a failed attempt to use the service).
• Mermaid Diagram:

  stateDiagram-v2
      direction LR
      [*] --> Unlicensed: App Start
  
      Unlicensed --> Authenticating: Provide API Key
      Authenticating --> Licensed: Receive JWT (Enabling Key)
      Licensed --> Licensed: Make API Call (Use Mode)\n[Local: Sign Request]\n[Remote: Verify JWT + Signature]
      Licensed --> Unlicensed: JWT Expires
      Licensed --> Throttled: API Call Failure (Demo Mode)\n[Invalid Signature or Rate Limit]
      Throttled --> Licensed: Wait for cool-down
  

Derivative 2.2: Lightweight Registration for Massive IoT Deployments

• Enabling Description: A registration system is disclosed for environments with millions or billions of constrained, low-power IoT devices (e.g., running on LoRaWAN or NB-IoT networks). The "platform unique ID" is derived from a Physically Unclonable Function (PUF) circuit within the device's microcontroller, providing a unique and unclonable hardware fingerprint. The registration algorithm is an extremely lightweight challenge-response protocol based on symmetric-key cryptography (e.g., AES-128). During provisioning, the device's PUF-derived key is registered with a cloud-based IoT platform (the "remote authority"). To activate a licensed feature (e.g., higher frequency data transmission), the cloud platform sends a challenge (a random number). The device ("local generator") encrypts the challenge with its PUF key and returns the response. The cloud platform ("remote generator") performs the same operation with the stored key and verifies the match. A successful match results in a signed command being sent to the device to unlock the feature ("use mode").
• Mermaid Diagram:

  flowchart TD
      subgraph IoT Device (Local)
          A[Initiate Activation] --> B{PUF generates unique key K};
          D[Server Challenge 'C'] --> E{Encrypt C with K -> R1};
          E --> F[Send Response R1];
          H[Server Command] --> I{Validate Signature & Unlock Feature};
          I --> J[Enter Use Mode];
      end
      subgraph Cloud Platform (Remote)
          C{Generate Challenge 'C'} --> D;
          G{Encrypt C with stored K -> R2} --> K{Compare R1 == R2};
          K -- Match --> L[Generate Signed 'Unlock' Command];
          L --> H;
          K -- No Match --> M[Activation Failed];
      end
      A --> C;
      F --> G;
  

---

Axis 3: Cross-Domain Application

Derivative 3.1: AgTech - Dynamic Licensing of Precision Farming Algorithms

• Enabling Description: A system for licensing algorithms on autonomous agricultural equipment. The "platform" is the tractor's ISO 11783 (ISOBUS) compliant control unit. A premium feature, such as a variable-rate seeding algorithm that adjusts seed placement based on real-time soil sensor data, is the "software." In "demonstration mode," the tractor operates using a fixed-rate, less efficient algorithm. To activate, the farmer uses a tablet interface to connect to the manufacturer's remote server. The "local licensee unique ID" is generated by combining the tractor's unique Vehicle Identification Number (VIN), the GPS-defined boundary (geofence) of the licensed field, and the farmer's account ID. The remote server verifies this data and returns a signed activation key valid only for the specified VIN and geofence. The tractor's control unit will only execute the premium algorithm when its GPS confirms it is inside the licensed boundary, reverting to demonstration mode otherwise.
• Mermaid Diagram:

  classDiagram
      direction LR
      class TractorECU {
          +String VIN
          +GPS_Coordinates currentPosition
          +String activeAlgorithm
          +verifyLicense(ActivationKey) bool
          +executeAlgorithm()
      }
      class FarmerTablet {
          +String farmerID
          +FieldGeofence fieldData
          +requestLicense()
      }
      class RemoteServer {
          +validateRequest(VIN, geofence, farmerID) bool
          +generateActivationKey() Key
      }
      class ActivationKey {
          +String licensedVIN
          +FieldGeofence licensedGeofence
          +Date expiryDate
          +Signature signature
      }
      FarmerTablet --|> RemoteServer : "requests"
      RemoteServer --|> ActivationKey : "generates"
      TractorECU --|> ActivationKey : "consumes"
  

Derivative 3.2: Medical Devices - Per-Patient Therapy Personalization

• Enabling Description: A system for licensing bespoke therapeutic algorithms on an implantable neurostimulator. The "platform" is the implanted device. The default "demonstration mode" provides a generic, low-amplitude stimulation pattern. A physician prescribes a custom stimulation algorithm ("software") tailored to a specific patient's condition. Using a secure, HIPAA-compliant portal, the physician (licensee) uploads the patient's anonymized case ID and the prescribed algorithm parameters to the device manufacturer's remote server. The "local ID" is the unique serial number of the implanted device, read by the physician's external programmer wand. The remote server validates the physician's credentials, logs the prescription, and generates an enabling key that encodes the specific algorithm parameters. The physician transmits this key to the implant via the programmer wand. The implant's firmware (the "mode switcher") verifies the key's signature and activates the personalized therapy ("use mode"). This ensures only validated, prescribed therapies are run on the device.
• Mermaid Diagram:

  sequenceDiagram
      participant Physician
      participant ProgrammerWand as Programmer
      participant Implant
      participant ManufacturerServer as Remote Server
  
      Physician->>Remote Server: 1. Login & Upload Prescription (Patient ID, Params)
      Physician->>Programmer: 2. Initiate implant communication
      Programmer->>Implant: 3. Read Implant Serial Number
      Implant-->>Programmer: 4. Return Serial Number
      Programmer-->>Physician: 5. Display Serial Number
      Physician->>Remote Server: 6. Request Enabling Key for Serial Number
      Remote Server->>Remote Server: 7. Validate & Generate Key
      Remote Server-->>Physician: 8. Provide Enabling Key
      Physician->>Programmer: 9. Load Enabling Key
      Programmer->>Implant: 10. Transmit Key to Implant
      Implant->>Implant: 11. Verify Key & Activate Personalized Therapy (Use Mode)
  

---

Axis 4: Integration with Emerging Technology

Derivative 4.1: AI-Based Behavioral Attestation for Continuous Licensing

• Enabling Description: This disclosure describes a continuous, dynamic licensing system where the "match" is not a one-time event but an ongoing verification of user behavior. The "local licensee unique ID generating means" is a lightweight, trained neural network (e.g., a recurrent neural network or transformer) embedded in the software. This model generates a vector embedding based on real-time telemetry, including API call sequences, data access patterns, and even mouse movement dynamics. This embedding serves as a behavioral fingerprint. The remote server maintains a corresponding AI model that has been trained on the licensee's legitimate usage patterns. Periodically, the local embedding is sent to the remote server. The server compares the incoming vector with its expected profile using cosine similarity. If the similarity score drops below a pre-defined threshold (indicating anomalous behavior, possibly due to account sharing or malware), the remote server invalidates the session, and the local software reverts to a "limited functionality" mode pending manual re-authentication.
• Mermaid Diagram:

  graph TD
      subgraph Local Client
          A[User Interaction] --> B(Local RNN Model);
          B --> C[Generate Behavioral Embedding Vector];
      end
      subgraph Remote Server
          D[Store User's Profile Embedding]
          F(AI Comparison Engine)
          E[Receive Behavioral Embedding] --> F;
          D --> F;
          F -- Cosine Similarity > 0.95 --> G[Session Valid (Use Mode)];
          F -- Cosine Similarity <= 0.95 --> H[Session Invalid (Revert to Demo Mode)];
      end
      C --> E;
      H --> I[Send "Invalidate" Command to Local Client];
  

Derivative 4.2: Blockchain and NFT-Based License Management

• Enabling Description: A decentralized software licensing system using a public blockchain (e.g., Ethereum) and Non-Fungible Tokens (NFTs) conforming to the ERC-721 standard. The "remote licensee unique ID generating means" is a smart contract deployed by the software publisher. To acquire a license, a user pays cryptocurrency to a function on the smart contract, which then mints a unique NFT license and assigns it to the user's wallet address. This transaction is immutable and publicly verifiable. The "local software" integrates with a crypto wallet. To unlock "use mode," the software prompts the user to sign a message with their wallet's private key. The software (the "mode switcher") then verifies on-chain that (1) the signing wallet address is the owner of a valid license NFT, and (2) the signature is valid. License transfer is achieved simply by the user selling or transferring the NFT to another wallet.
• Mermaid Diagram:

  sequenceDiagram
      participant User
      participant Software
      participant Wallet
      participant Blockchain as Ethereum Smart Contract
  
      User->>Blockchain: 1. Purchase License (calls mint() function)
      Blockchain-->>User: 2. Mints and transfers License NFT to User's Wallet
      User->>Software: 3. Run software (starts in Demo Mode)
      Software->>User: 4. Prompt for license verification
      User->>Wallet: 5. "Connect Wallet"
      Software->>Wallet: 6. Request signature for challenge message
      Wallet-->>Software: 7. Return signed message + public address
      Software->>Blockchain: 8. Query: Does this address own a license NFT?
      Blockchain-->>Software: 9. Response: True
      Software->>Software: 10. Verify signature & Switch to Use Mode
  

---

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation Licensing for Unreliable Networks

• Enabling Description: This system is designed for applications that operate in environments with intermittent or non-existent network connectivity (e.g., field research, maritime vessels). The license is based on a "lease" model. Upon initial registration with the remote server, the local software receives an enabling key that has a defined expiry time (e.g., 30 days). This key unlocks full "use mode." The software stores this lease token. If the device is offline, it continues to operate in full use mode. The "mode switcher" periodically checks the lease expiry. If the device can connect to the remote server before expiry, it automatically renews the lease for another 30 days. If the lease expires while the device is still offline, the software does not shut down but instead enters a pre-defined "graceful degradation mode." In this mode, core functionality remains (e.g., data viewing and local logging) but premium features requiring connectivity or heavy processing (e.g., cloud sync, advanced analytics) are disabled. This ensures the user is never left with a non-functional application due to connectivity issues, providing a safe failure state.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Unregistered
      Unregistered --> Registered: Successful remote registration
      note on link: Receives 30-day lease token
  
      state Registered {
          direction LR
          [*] --> Full_Use
          Full_Use --> Full_Use: Check Lease: OK
          Full_Use --> Degradation_Mode: Check Lease: Expired
          Full_Use --> [*]: Network available, lease renewed
      }
  
      Degradation_Mode --> Registered: Network restored, re-register & renew lease
      note on link: Regains full functionality
  

---

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with FIDO2/WebAuthn: The system is implemented where the "local licensee unique ID" is a cryptographic assertion generated by a FIDO2-compliant authenticator (e.g., YubiKey, Windows Hello). The registration process involves a WebAuthn navigator.credentials.create() call where the public key credential is sent to the remote authority. Activation of the software's "use mode" requires a subsequent navigator.credentials.get() call, where the authenticator signs a server-provided challenge. The successful cryptographic verification of this signature acts as the "match," tying the software license directly to a hardware-backed, un-phishable user credential instead of user-entered data.

2. Combination with OAuth 2.0: The registration flow is modeled as an OAuth 2.0 authorization grant. The "remote licensee unique ID generating means" is the Authorization Server. The software acts as the client application. To switch to "use mode," the user is directed to the Authorization Server to log in and grant consent. The server returns an authorization code, which the client exchanges for an access token (the "enabling key"). Full functionality is enabled as long as the access token is valid and can be used to access protected backend resources. "Demonstration mode" is the state of the application before or after the token has expired.

3. Combination with Kerberos: In an enterprise environment, the system is integrated with a Kerberos Key Distribution Center (KDC). The "remote authority" is the KDC. To activate the software, the client authenticates with the KDC and receives a Ticket-Granting Ticket (TGT). It then requests a service ticket for the specific licensed software. The received service ticket is the "enabling key." The software ("mode switcher") decrypts the ticket to verify the user's identity and permissions, switching to "use mode." This allows licensing to be managed centrally via the existing enterprise identity and access management infrastructure.