Derivative works

Defensive Disclosure of Derivative Inventions

Reference Patent: U.S. Patent 6,108,329
Title: Telephone apparatus used for computer network telephone system
Purpose: To create prior art that renders incremental improvements obvious or non-novel, this document discloses a series of derivative works based on the core claims of the '329 patent.

---

Derivative Set 1: Based on Material & Component Substitution

Variation 1.1: System-on-a-Chip (SoC) with Integrated Digital Signal Processor (DSP)

• Enabling Description: The telephone apparatus described in claim 1 is implemented using a single Application-Specific Integrated Circuit (ASIC) or System-on-a-Chip (SoC) instead of a general-purpose CPU, ROM, and RAM. This SoC integrates a dedicated Digital Signal Processor (DSP) core for real-time audio compression/decompression (e.g., G.729, Opus codecs) and echo cancellation, offloading these tasks from the main processor. The modem functionality (modulator/demodulator circuit) is also integrated as a software-defined radio (SDR) block within the same silicon, allowing for dynamic updates to support new line modulation standards (e.g., V.92, G.fast) via firmware pushes. The approved caller list is stored in on-chip non-volatile flash memory for faster boot-up and lookup times.
• Diagram:

  graph TD
      subgraph SoC [System-on-a-Chip]
          A[ARM Cortex-M Core] -- Manages OS & Logic --> B{On-Chip Flash};
          A --> C[DSP Core];
          D[SDR Modem Block] -- I/Q Data --> C;
          C -- Audio Codec --> E[Audio I/O];
          B -- Stores --> F[Approved Caller List];
      end
      G[Telephone Network] --> D;
      H[Handset Mic/Speaker] --> E;
      A -- Accesses --> F;
  

Variation 1.2: Field-Programmable Gate Array (FPGA) for Protocol Agnosticism

• Enabling Description: The means for determining call type and establishing a PPP connection is implemented on a Field-Programmable Gate Array (FPGA) rather than a fixed-function CPU. This allows the apparatus to be dynamically reconfigured in the field to support communication protocols beyond PPP, such as SLIP, PPPoE, or proprietary Layer 2 protocols. The FPGA is partitioned into a "modem core" that handles the physical layer signaling and a "protocol core" that manages the data link layer. A small microcontroller supervises the FPGA, loading the appropriate configuration bitstream based on initial handshake tones detected from the server. This provides a hardware-level defense against protocol obsolescence.
• Diagram:

  sequenceDiagram
      participant TN as Telephone Network
      participant FPGA as Reconfigurable Apparatus
      participant Server as Network Server
      TN->>FPGA: Incoming Ring Signal
      FPGA->>Server: Off-hook, Initiate Handshake
      Server-->>FPGA: Transmit Protocol-Specific Tone (e.g., V.8 bis)
      FPGA->>FPGA: Microcontroller selects Bitstream (PPP/SLIP/etc.)
      FPGA->>FPGA: Reconfigure Protocol Core
      FPGA->>Server: Establish Connection (e.g., LCP/IPCP)
      Server-->>FPGA: Send Caller Info Packet
      FPGA->>FPGA: Compare Caller Info to Local List
      FPGA-->>Server: Accept/Reject Connection
  

---

Derivative Set 2: Based on Operational Parameter Expansion

Variation 2.1: High-Latency Satellite Network Adaptation

• Enabling Description: The system is adapted for use over a geostationary satellite link, where round-trip latency can exceed 500 ms. The PPP connection negotiation timers (e.g., LCP Echo-Request timeouts) are expanded to a minimum of 1000 ms to prevent premature disconnection. The server database includes a "Network Type" field (Terrestrial/Satellite) for each user. When the server detects it is calling a satellite-based user, it pre-fetches the caller's information and injects it into the very first data packet following the IPCP address assignment, minimizing the number of round-trips required for the destination apparatus to perform its screening function. Audio data is buffered in a 1-second jitter buffer on the client-side apparatus to compensate for variable latency.
• Diagram:

  stateDiagram-v2
      [*] --> Dialing
      Dialing --> Handshaking: Server Dials User
      Handshaking --> PPP_Negotiation: Line Connected
      state PPP_Negotiation {
          [*] --> LCP
          LCP --> Auth
          Auth --> IPCP
          IPCP --> Done
          note right of LCP
              LCP Echo-Request Timeout > 1000ms
          end note
          note right of IPCP
              Server injects caller info
              with IPCP ACK packet
          end note
      }
      PPP_Negotiation --> Screening: Connection Established
      Screening --> Connected: Caller Approved
      Screening --> Disconnected: Caller Rejected
  

Variation 2.2: Ultra-Low-Power IoT Mesh Network Implementation

• Enabling Description: The invention is scaled down to operate on battery-powered nodes within an 802.15.4 (Zigbee/Thread) mesh network. The "telephone apparatus" is a sensor node. The "server" is a gateway node connecting the mesh to the internet. The "public phone number" is a 64-bit MAC address. To conserve power, nodes remain in a deep sleep state (sub-microamp). A calling node sends a low-frequency radio "wake-up" pattern. Upon waking, the destination node establishes a lightweight CoAP (Constrained Application Protocol) session with the gateway. The gateway sends the source node's MAC address and a security token. The destination node compares this against a micro-list of approved peer addresses stored in its EEPROM. If approved, it opens a full communication channel; otherwise, it immediately returns to sleep.
• Diagram:

  flowchart LR
      subgraph Calling Node
          A[Request to Connect]
      end
      subgraph Gateway
          B[Server Logic]
          C[Peer Address DB]
      end
      subgraph Destination Node (Sleep Mode)
          D{Wake on RF Pattern?}
      end
      A --> B;
      B -- Lookup MAC --> C;
      B -- Send Wake-up + Src MAC --> D;
      D -- Yes --> E{Establish CoAP};
      E --> F[Compare Src MAC];
      F -- Approved --> G[Full Communication];
      F -- Rejected --> H[Return to Sleep];
      D -- No --> H;
  

---

Derivative Set 3: Based on Cross-Domain Application

Variation 3.1: Aerospace - Secure Flight Control Command Authentication

• Enabling Description: The core mechanism is adapted for authenticating commands sent to an unmanned aerial vehicle (UAV). The "server" is the Ground Control Station (GCS). The "telephone apparatus" is the UAV's flight computer. The "internet network" is the command-and-control datalink (e.g., C-band). The GCS maintains a database of authorized operators, mapping their cryptographic public keys ("internet protocol address") to their unique operator IDs ("public phone number"). Before sending a critical command (e.g., "change flight plan"), the GCS sends the command digitally signed with the operator's private key. The UAV receives this command, extracts the operator ID, and compares it against an onboard list of authorized mission operators. It then uses the corresponding public key from its secure memory to verify the signature. If the ID is on the list and the signature is valid, the command is executed.
• Diagram:

  sequenceDiagram
      participant GCS as Ground Control Station
      participant UAV as Flight Computer
      GCS->>UAV: Signed Command {OperatorID, Command, Signature}
      UAV->>UAV: Is OperatorID in Approved List?
      alt Approved
          UAV->>UAV: Verify Signature with Stored Public Key
          alt Signature Valid
              UAV->>UAV: Execute Command
          else Signature Invalid
              UAV->>UAV: Reject Command, Log Anomaly
          end
      else Not Approved
          UAV->>UAV: Reject Command
      end
  

Variation 3.2: AgTech - Authenticated Irrigation Actuator Control

• Enabling Description: The system is applied to a smart agriculture irrigation network. The "server" is a central farm management server connected to the internet. The "telephone apparatus" is a solenoid valve controller in a field, connected via a LoRaWAN network. The server's database maps specific sensor nodes (e.g., soil moisture sensors) to the valve controllers they are authorized to trigger. When a sensor reading crosses a threshold, it sends a data packet to the server. The server verifies the sensor is authorized for a specific valve, then sends a "request to connect" (an "open valve" command) to the valve controller, including the ID of the triggering sensor. The valve controller checks its internal memory to see if that sensor ID is on its pre-configured "approved list." If it is, the controller opens the valve for a prescribed duration. This prevents rogue sensors or network errors from causing flooding.
• Diagram:

  graph TD
      A[Soil Sensor] -- Moisture Data --> B(Farm Mgmt Server);
      B -- Lookup Auth --> C{Sensor-to-Valve DB};
      B -- "Open Valve (Src: SensorID)" --> D[Valve Controller];
      subgraph Valve Controller
          D --> E{Is SensorID in my approved list?};
          E -- Yes --> F[Activate Solenoid];
          E -- No --> G[Ignore Command];
      end
  

Variation 3.3: Consumer Electronics - Smart Home Device Interaction Permissions

• Enabling Description: The invention is used to manage permissions between smart home devices. The "server" is the home's local hub (e.g., Home Assistant). The "telephone apparatus" is a device capable of action, such as a smart lock. The hub's database stores a list of which devices (e.g., a specific user's smartphone, a doorbell camera) are authorized to trigger the lock. When the doorbell camera detects a known face via facial recognition, it sends a message to the hub ("request to connect"). The hub forwards this request, including the camera's unique device ID, to the smart lock. The lock checks its internal list of "approved callers" to see if the doorbell camera is authorized to trigger an unlock command. If so, it unlocks. This prevents an unauthorized device that has gained network access from controlling critical infrastructure.
• Diagram:

  sequenceDiagram
      participant Camera as Doorbell Camera
      participant Hub as Smart Home Hub
      participant Lock as Smart Lock
      Camera->>Hub: "Person Detected: [FaceID]"
      Hub->>Hub: Lookup permissions for FaceID & CameraID
      Hub->>Lock: "Unlock Request (Source: CameraID)"
      Lock->>Lock: Check if CameraID is in Approved List
      alt Is Approved
          Lock->>Lock: Execute Unlock Motor
      else Not Approved
          Lock->>Hub: "Request Denied"
      end
  

---

Derivative Set 4: Integration with Emerging Tech

Variation 4.1: AI-Driven Dynamic Caller Approval List

• Enabling Description: The "list of approved user-designated callers" is no longer static. It is managed by a machine learning model running on the telephone apparatus or a local server. The model is trained on the user's communication patterns (call logs, frequency, duration, time of day) and contact lists. It generates a "trust score" for incoming callers. Instead of a binary approved/denied list, the apparatus now compares the incoming caller's info against a trust threshold. The AI can dynamically add a new caller to a temporary approved list if they are, for example, from the same organization as a frequent contact or are calling shortly after an email exchange was initiated. This provides adaptive, context-aware call screening.
• Diagram:

  flowchart TD
      A[Incoming Call Info] --> B{AI Trust Engine};
      C[Historical Call Logs] --> B;
      D[Contact/Email Data] --> B;
      B -- Trust Score --> E{Score > Threshold?};
      E -- Yes --> F[Connect Call];
      E -- No --> G[Divert to Voicemail/Reject];
      F -- Feedback --> C;
  

Variation 4.2: IoT-Enhanced Contextual Call Handling

• Enabling Description: The telephone apparatus is integrated with the user's IoT environment. The means for judging whether a caller is approved now includes contextual data from IoT sensors. For example, if the user's calendar indicates they are in a meeting and their smartphone's GPS shows them in an office building, the system will automatically reject calls from numbers not on the "Family" or "Urgent" lists. If a smoke detector is triggered, the system automatically elevates the priority of incoming calls from known emergency service numbers, bypassing all other screening.
• Diagram:

  graph TD
      A[Call from Other Apparatus] --> B{Screening Logic};
      C[Approved Caller List] --> B;
      D[IoT Sensor Data] -- Context --> B;
      subgraph IoT Sensors
          E[GPS Location]
          F[Calendar State]
          G[Home Smoke Detector]
      end
      E & F & G --> D;
      B -- Decision --> H[Connect / Disconnect];
  

Variation 4.3: Blockchain-Based Decentralized Caller Identity

• Enabling Description: The centralized server database is replaced with a decentralized identity ledger (a permissioned blockchain). Each "telephone apparatus" has a cryptographic key pair, and its public key serves as its identity, registered on the blockchain. The "list of approved user-designated callers" is a smart contract controlled by the user, which lists the public keys of approved contacts. When a call is initiated, the calling apparatus signs the connection request with its private key. The destination apparatus receives the request, looks up the caller's public key on the blockchain, and checks its own smart contract to see if that key is listed as approved. This removes the single point of failure and control of a central server and provides a tamper-proof, user-controlled identity and permissioning system.
• Diagram:

  sequenceDiagram
      participant Alice as Calling Apparatus
      participant Blockchain as Identity Ledger
      participant Bob as Receiving Apparatus
      Alice->>Bob: Connection Request (Signed with Alice's Private Key)
      Bob->>Blockchain: Fetch Public Key for Alice's ID
      Blockchain-->>Bob: Returns Alice's Public Key
      Bob->>Blockchain: Query my Smart Contract: Is Alice's Public Key approved?
      Blockchain-->>Bob: Returns True/False
      alt Is True
          Bob->>Alice: Accept Connection
      else Is False
          Bob->>Alice: Reject Connection
      end
  

---

Derivative Set 5: The "Inverse" or Failure Mode

Variation 5.1: Graceful Degradation with Cached Credentials

• Enabling Description: The invention is designed to fail safely if the connection to the internet network or the primary server is lost. The telephone apparatus maintains a local, encrypted cache of the X most recently approved or frequently contacted callers' information. When an incoming call is detected, the apparatus first attempts to establish a PPP connection and query the server. If this fails due to a network outage (e.g., timeout), it enters a "limited functionality" mode. It falls back to operating as a standard telephone but uses its local cache and standard Caller ID to screen against this high-priority subset of callers. For these cached callers, it can still provide a distinct ringtone or automatically accept the call. All other calls are sent to a local answering machine.
• Diagram:

  flowchart TD
      A[Incoming Call] --> B{Attempt PPP to Server?};
      B -- Success --> C[Normal Screening];
      B -- Failure/Timeout --> D[Enter Limited Mode];
      D --> E{Check Caller ID};
      E --> F{Is Number in Local Cache?};
      F -- Yes --> G[Connect w/ Priority Handling];
      F -- No --> H[Divert to Local Answering Machine];
  

---

Combination Prior Art Scenarios

1. Combination with SIP (Session Initiation Protocol - RFC 3261): The '329 patent's server logic is integrated into a SIP Proxy/Registrar server. A user's telephone apparatus is a SIP User Agent (UA). When a user is offline, the Registrar holds their last known public telephone number for PPP access. When an INVITE request arrives for that offline user, the Proxy server, instead of returning a "404 Not Found," initiates a dial-out via a PSTN gateway using the stored PPP number. Once the user's SIP UA comes online and REGISTERS, the Proxy server then forwards the queued INVITE. The screening logic is implemented on the UA, which compares the P-Asserted-Identity header of the incoming INVITE against a locally stored "buddy list" or contact directory before responding with "200 OK."

2. Combination with WebRTC (Web Real-Time Communication): The apparatus is a web browser. The "server" is a signaling server using WebSockets. A user's identity is tied to a login, and the server's database maps this identity to a public phone number. When a peer wishes to connect to an offline user, the signaling server sends an SMS message containing a unique URL to the stored phone number. Clicking this URL opens the browser (the "apparatus"), which establishes a WebSocket connection to the signaling server. The server then relays the WebRTC offer/answer negotiation. The browser's JavaScript compares the caller's ID (provided by the signaling server) against contact data stored in the browser's localStorage to decide whether to create and return an SDP answer, effectively connecting or rejecting the call.

3. Combination with XMPP (Extensible Messaging and Presence Protocol - RFC 6120): The telephone apparatus is an XMPP client. The server is an XMPP server. A user's presence state is "Offline." The server database contains a custom vCard field mapping the user's JID (Jabber ID) to a PPP phone number. When another user sends a Jingle (XEP-0166) session-initiate IQ stanza to the offline user, the server intercepts it. It uses a server-side component to dial the stored PPP number via a gateway. Once the client apparatus connects and authenticates, its presence becomes "Available," and the server delivers the queued Jingle stanza. The client then checks if the initiating JID is in its roster (the "approved list") before proceeding with the Jingle session.