Derivative works — US Patent 9804819

This document serves as a defensive disclosure for US Patent 9804819, titled "Receiving apparatus and control method." The purpose of this disclosure is to establish prior art for potential future incremental improvements by competitors, rendering such advancements obvious or non-novel. The core inventive concept of US9804819 relates to an improved volume control locking mechanism that allows for temporary adjustment within a predetermined range before re-locking, preventing sudden unintended volume changes during reset. The following derivations expand upon the core claims by exploring alternative implementations, operational contexts, and integrations with emerging technologies.

2. Combination Prior Art Scenarios with Open-Source Standards

For each scenario, the core inventive concept of US9804819 (locked volume with specific unlock/update mechanism) is combined with an existing open-source standard.

Scenario 1: Integration with Voice over IP (VoIP) using Session Initiation Protocol (SIP)
- Description: The control method of US9804819 (Claim 8) is applied to a softphone or hardware VoIP terminal that uses the Session Initiation Protocol (SIP) for call management and audio streaming. The "receiving apparatus" is the VoIP endpoint. The "audio output unit" is the speaker/headset output. The "volume operating unit" is the digital volume control within the softphone UI or a physical knob on the VoIP phone. The "lock controller" functions to prevent unintended changes to call volume, especially in professional or emergency communication environments. The "predetermined operating part" is a specific button or sequence in the VoIP client (e.g., a "Mute" button held for 2 seconds, or a "Volume Reset" menu option). This allows for temporary adjustment of the VoIP call volume within a safe range (e.g., +/- 10% of the current locked level) while the user is actively monitoring the call, before re-locking the volume, leveraging the SIP standard for call establishment and media handling.
- Prior Art Value: Establishes the application of sophisticated volume locking mechanisms to internet telephony and networked audio, a common open-source enabled standard.
Scenario 2: Integration with Robot Operating System (ROS) for Robotic Feedback Systems
- Description: The receiving apparatus of US9804819 (Claim 1) is incorporated into a robotic system managed by the Robot Operating System (ROS). Here, the "audio output unit" is conceptualized as a haptic feedback actuator or a warning siren/speaker on the robot, and the "volume level" corresponds to the intensity of the haptic feedback or the loudness of the warning. The "volume operating unit" is a ROS-controlled parameter adjusted via a rosparam or rqt_gui interface. The "lock controller" functions to maintain critical safety feedback levels (e.g., proximity alert intensity) in a locked state to ensure operator awareness. The "predetermined operating part" is a ROS service call or a physical override button on the robot's pendant. The system temporarily allows adjustment of the feedback intensity within a safety-defined range (e.g., from 50% to 70% intensity) before re-locking, all within the ROS framework for inter-process communication and parameter management.
- Prior Art Value: Extends the volume locking concept to robotic control and human-robot interaction using a widely adopted open-source robotics framework.
Scenario 3: Integration with Home Assistant (HA) for Smart Home Audio Control
- Description: A smart home audio system, controlled by the open-source Home Assistant (HA) platform, implements the receiving apparatus and control method of US9804819 (Claims 1 and 8). The "receiving apparatus" is a smart speaker or multi-room audio zone. The "audio output unit" is the actual speaker. The "volume operating unit" is a slider or button group within the Home Assistant frontend or a physical smart button (e.g., Zigbee/Z-Wave button) configured through HA. The "lock controller" is implemented as an HA automation script or custom component, fixing the volume level for a specific zone (e.g., a child's room or a notification-only speaker) to prevent accidental high volume output. The "predetermined operating part" is a specific voice command ("Hey Google, unlock volume for 30 seconds"), a button press on an HA-integrated remote, or a specific toggle switch in the HA UI. This allows for temporary adjustment within a safe operating range before returning to the locked state, all managed and monitored by the Home Assistant ecosystem.
- Prior Art Value: Demonstrates the application of the invention to consumer smart home devices and distributed audio control via a popular open-source home automation platform.

3. Derivative Variations

3.1. Material & Component Substitution

Derivative 1.1: Multi-Modal Biometric Volume Operating Unit with Eye-Tracking Predetermined Operating Part
- Enabling Description: For the receiving apparatus (Claim 1), the "volume operating unit" is a multi-modal biometric system comprising a facial expression recognition module and a vocal intensity analysis module. The "operating value" is derived from a weighted average of detected emotional intensity (e.g., frustration, excitement) and spoken volume, mapped to a desired audio output level. For instance, a relaxed facial expression and a moderate speaking tone result in a moderate operating value. The "predetermined operating part" is implemented via an eye-tracking sensor (e.g., Pupil Labs eye-tracker). When the user maintains a focused gaze on a specific, non-obtrusive on-screen indicator (e.g., a small, designated icon in the corner of a display) for a predefined duration (e.g., 1.5 seconds) while the audio is in the locked state, the eye-tracking system signals the lock controller 74. This action corresponds to "turning on" the predetermined operating part. The "control method" (Claim 8) would involve acquiring biometric data, processing it to derive the operating value, monitoring gaze patterns for activation, and managing the state transitions based on these inputs. This allows for highly intuitive and hands-free control, especially beneficial in sterile environments or situations requiring full manual dexterity.
- ```
graph TD
    User_Face["User Facial Expressions"] --> Facial_Rec_Module["Facial Recognition Module"]
    User_Voice["User Vocal Intensity"] --> Voice_Anal_Module["Vocal Analysis Module"]
    Facial_Rec_Module -- "Emotional Intensity" --> Biometric_Fusion["Biometric Fusion Algorithm"]
    Voice_Anal_Module -- "Vocal Volume" --> Biometric_Fusion
    Biometric_Fusion -- "Operating Value" --> Lock_Controller_74["Lock Controller 74"]
    User_Gaze["User Gaze on UI Indicator"] --> Eye_Tracking_Sensor["Eye-Tracking Sensor"]
    Eye_Tracking_Sensor -- "Gaze Duration Signal" --> Predetermined_Operating_Part["Predetermined Operating Part (Functional)"]
    Predetermined_Operating_Part --> Lock_Controller_74
    Lock_Controller_74 -- "Control Signal" --> Volume_Controller_76["Volume Controller 76"]
    Volume_Controller_76 --> Audio_Output_Unit_62["Audio Output Unit 62"]
```

3.2. Operational Parameter Expansion

Derivative 2.1: Ultra-Low Latency, High-Frequency Acoustic Monitoring System in a Microfluidic Environment
- Enabling Description: The receiving apparatus (Claim 1) is deployed in a microfluidic lab-on-a-chip device, where the "audio output unit" consists of an array of micro-electromechanical systems (MEMS) acoustic transducers operating at ultra-high frequencies (e.g., 50 MHz to 200 MHz) with extremely low latency (<100 nanoseconds). These transducers generate highly localized acoustic waves for manipulating microscopic particles or cells within the fluid channels. The "volume operating unit" is a high-precision digital potentiometer controlled by a custom FPGA interface, outputting an "operating value" that represents the acoustic power density (mW/cm²). The "locked state" fixes this acoustic power density to prevent damage to biological samples or unintended reactions. The "predetermined operating part" is a specialized, debounced piezo-electric touch sensor integrated directly onto the microfluidic chip housing, requiring precise force and duration to activate. The "predetermined range" for lock value adjustment is extremely tight (e.g., +/- 0.5% of the current acoustic power density) to maintain experimental integrity, which is temporarily permitted when the piezo-electric touch sensor is activated. The "control method" (Claim 8) involves real-time monitoring of acoustic emissions, extremely fast digital signal processing, and precise control of MEMS actuators to maintain sub-nanosecond response times for power adjustments within the defined parameters.
- ```
graph TD
    FPGA_Interface["FPGA Interface"] --> Digital_Potentiometer["High-Precision Digital Potentiometer"]
    Digital_Potentiometer -- "Operating Value (Acoustic Power)" --> Lock_Controller_74["Lock Controller 74"]
    Piezo_Touch_Sensor["Piezo-Electric Touch Sensor"] --> Predetermined_Operating_Part["Predetermined Operating Part (Functional)"]
    Predetermined_Operating_Part --> Lock_Controller_74
    Lock_Controller_74 -- "Control Signal (<100ns)" --> Volume_Controller_76["Volume Controller 76"]
    Volume_Controller_76 --> MEMS_Transducer_Array["MEMS Acoustic Transducer Array (50-200MHz)"]
    MEMS_Transducer_Array --> Microfluidic_Environment["Microfluidic Environment (Particle Manipulation)"]
```

3.3. Cross-Domain Application

Derivative 3.1: Subterranean Environmental Monitoring System for Geophone Sensitivity Control
- Enabling Description: The receiving apparatus (Claim 1) is integrated into a subterranean environmental monitoring system, such as for seismic activity detection or underground fluid flow analysis. The "audio output unit" is conceptualized as the gain setting for an array of geophones or hydrophones, and the "volume level" corresponds to the amplification factor applied to the received seismic or acoustic signals. The "volume operating unit" is a ruggedized rotary encoder accessible via a sealed enclosure. The "locked state" fixes the sensitivity (gain) of the geophones to a specific "lock value" to maintain consistent data acquisition parameters over long deployments in harsh environments. The "predetermined operating part" is a magnetically actuated switch, operable from outside the sealed enclosure. When activated, the system temporarily enters a "non-locked state," allowing an operator to adjust the geophone gain within a "predetermined range" (e.g., +/- 10% of the current gain) for specific data calibration events or to adapt to changing environmental noise (e.g., nearby drilling). Upon deactivation of the magnetic switch, the new gain setting is locked. The "control method" (Claim 8) ensures robust operation and parameter integrity in extreme conditions.
- ```
graph TD
    Geophone_Array["Geophone / Hydrophone Array (Subterranean)"] --> Pre_Amplifier["Low-Noise Pre-Amplifier"]
    Pre_Amplifier --> Signal_Acquisition_Unit["Signal Acquisition Unit"]
    Signal_Acquisition_Unit -- "Gain Control" --> Audio_Output_Unit_62["Audio Output Unit (Functional: Gain)"]
    Rugged_Encoder["Ruggedized Rotary Encoder"] --> Volume_Operating_Unit_72["Volume Operating Unit (Functional)"]
    Magnetically_Actuated_Switch["Magnetically Actuated Switch"] --> Predetermined_Operating_Part["Predetermined Operating Part (Functional)"]
    Volume_Operating_Unit_72 -- "Operating Value (Gain)" --> Lock_Controller_74["Lock Controller 74"]
    Predetermined_Operating_Part --> Lock_Controller_74
    Lock_Controller_74 -- "Gain Adjustment Command" --> Volume_Controller_76["Volume Controller 76"]
    Volume_Controller_76 --> Audio_Output_Unit_62
```

3.4. Integration with Emerging Tech

Derivative 4.1: AI-Optimized Adaptive Predetermined Range with Contextual IoT Triggers
- Enabling Description: The receiving apparatus (Claim 1) includes an embedded AI inference engine (e.g., a TinyML model running on an ARM Cortex-M microcontroller) that dynamically adjusts the "predetermined range" based on real-time contextual data from integrated IoT sensors. These sensors include a broadband acoustic sensor measuring ambient noise spectrum, an accelerometer detecting device motion, and a light sensor detecting environmental brightness. The AI model analyzes this data to predict user intent or environmental necessity for volume adjustment. For example, if the user is in a quiet meeting room, the AI may shrink the predetermined range to prevent accidental large volume changes. If the user is in a noisy industrial environment, the AI may widen the range to facilitate quicker adjustment. The "predetermined operating part" is triggered by a combination of a double-tap gesture on the device casing (detected by the accelerometer) and a voice command ("unlock volume"). The "control method" (Claim 8) involves continuous sensor data acquisition, AI inference for dynamic range calculation, and a multi-modal trigger for the temporary unlock, ensuring the system intelligently adapts the unlock sensitivity to context.
- ```
graph TD
    IoT_Sensors_Input["IoT Sensors (Acoustic, Accelerometer, Light)"] --> TinyML_AI_Engine["TinyML AI Inference Engine"]
    TinyML_AI_Engine -- "Dynamic Range Parameters" --> Lock_Controller_74["Lock Controller 74"]
    Volume_Operating_Unit_72["Volume Operating Unit 72"] -- "Operating Value" --> Lock_Controller_74
    Double_Tap_Gesture["Double-Tap Gesture (Accelerometer)"] --> Multi_Modal_Trigger["Multi-Modal Trigger Logic"]
    Voice_Command["Voice Command ('unlock volume')"] --> Multi_Modal_Trigger
    Multi_Modal_Trigger --> Predetermined_Operating_Part["Predetermined Operating Part (Functional)"]
    Predetermined_Operating_Part --> Lock_Controller_74
    Lock_Controller_74 -- "Volume Control" --> Volume_Controller_76["Volume Controller 76"]
    Volume_Controller_76 --> Audio_Output_Unit_62["Audio Output Unit 62"]
```

3.5. The "Inverse" or Failure Mode

Derivative 5.1: Critical System Malfunction-Activated Fail-Mute/Emergency Broadcast Mode
- Enabling Description: The receiving apparatus (Claim 1) incorporates a "system health monitor" that continuously checks the operational integrity of all critical components, including the audio output unit, volume operating unit, and lock controller. This monitor performs diagnostic self-tests and CRC checks on firmware. In the event of detecting a critical system malfunction (e.g., memory corruption in the lock controller, open circuit in the volume operating unit, or power supply instability) while the device is in the locked state, the system health monitor overrides normal operation. It forces the "audio output unit" (Claim 1) into a "fail-mute" state (volume level 0) for non-essential audio, or immediately switches to a pre-defined "emergency broadcast mode" where it outputs a specific, non-adjustable, maximum-priority emergency audio signal (e.g., an alarm tone or critical voice instruction) regardless of the previous lock value or operating value. During this emergency mode, the "predetermined operating part" is automatically disabled, and the volume operating unit is prevented from making any adjustments. The device's display 34 (if present) activates a high-contrast emergency warning. This "control method" (Claim 8) prioritizes safety and critical communication over user-set preferences in hazardous conditions.
- ```
graph TD
    System_Components["Audio Output Unit, Volume Op. Unit, Lock Controller, Power Supply"] --> System_Health_Monitor["System Health Monitor (Diagnostics, CRC)"]
    System_Health_Monitor -- "Critical Malfunction Detected" --> Emergency_Control_Module["Emergency Control Module"]
    Emergency_Control_Module -- "Force Fail-Mute / Emergency Broadcast" --> Audio_Output_Unit_62["Audio Output Unit 62"]
    Emergency_Control_Module -- "Disable Controls" --> Volume_Operating_Unit_72["Volume Operating Unit 72"]
    Emergency_Control_Module -- "Disable Controls" --> Predetermined_Operating_Part["Predetermined Operating Part"]
    Emergency_Control_Module -- "Activate Emergency Display" --> Display_34["Display 34"]
    style Emergency_Control_Module fill:#FCC,stroke:#F00,stroke-width:2px
```