Patent 11200252
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Active provider: Google · gemini-2.5-pro
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Here is the Defensive Disclosure document for U.S. Patent 11,200,252.
Defensive Disclosure and Prior Art Generation
Title: Systems and Methods for Hierarchical and Context-Aware Item Selection
Publication Date: 2026-05-13
Disclosure ID: D260513-01
Related Art: U.S. Patent 11,200,252
Abstract
This document discloses a series of derivative methods, systems, and applications building upon the core concept of hierarchical item selection through partial identifier completion. These disclosures are intended to enter the public domain as prior art. The disclosed variations explore alternative components and data structures, application to extreme operational parameters, cross-domain implementations, integration with emerging technologies like AI and IoT, and inverse operational modes. The intent is to render obvious any future patent claims on these incremental but foreseeable adaptations of the foundational technology.
Derivative Disclosures
Axis 1: Material & Component Substitution
1.1. Phonetic Segment Selection for Voice-Controlled Systems
Enabling Description: This variation replaces text-based segments with phonetic ones for use in voice-controlled or hands-free environments. The system's engine pre-processes the database of item identifiers (e.g., contact names, song titles) into their constituent phonemes using a standard phonetic alphabet like ARPABET or IPA. The divergence analysis is performed on these phonetic sequences. The user interface, instead of displaying text, audibly presents the next most likely phonetic segments. For example, to select "Jessica," after the user says "jeh," the system might offer "sih" and "koh" as audible choices, mapped to voice commands like "Select one" and "Select two." The ranking algorithm can be biased by an acoustic model that analyzes the user's accent to prioritize more likely phoneme choices. The input is captured by a far-field microphone array and processed by a speech-to-phoneme converter.
Diagram:
sequenceDiagram participant User participant AUI as Audio UI participant Engine participant DB as Phonetic Database User->>+AUI: Initiates selection (e.g., "Find contact") AUI->>+Engine: Request initial phoneme segments(num_options=3) Engine->>+DB: Query root phoneme branches DB-->>-Engine: Returns segments ["/dʒ/ (J)", "/k/", "/l/"] with high frequency Engine-->>-AUI: Provides top 3 audible phonemes AUI->>-User: Plays sounds: "Say 'Jay', 'Kay', or 'Ell'" User->>+AUI: Says "Jay" AUI->>+Engine: User selected "/dʒ/" Engine->>+DB: Query branches following "/dʒ/" DB-->>-Engine: Returns segments ["/ɛ/ (e)", "/oʊ/ (o)"] Engine-->>-AUI: Provides next phoneme options AUI->>-User: Plays sounds: "Say 'Eh' or 'Oh'"
1.2. Haptic Segment Selection for Non-Visual Interfaces
Enabling Description: This derivative uses distinct haptic patterns as the selectable segments, designed for visually impaired users or for interfaces where a screen is unavailable or unsafe to view (e.g., a motorcycle handlebar controller). The item identifiers in the database are mapped to unique sequences of haptic patterns. The system uses a specialized haptic actuator array (e.g., piezoelectric or eccentric rotating mass motors) to render the patterns. For example, to select the "Navigate Home" function, the first set of options might be a short pulse (for "Navigate"), a long vibration (for "Call"), and two quick taps (for "Media"). After the user selects the short pulse via a button press, the next set of options for destinations ("Home," "Work," "Office") are presented as new, distinct haptic patterns. The physical input device could be a multi-way joystick where each direction is associated with confirming the haptic pattern currently being rendered.
Diagram:
flowchart TD subgraph Haptic Controller A[Start Selection] --> B{Render Option Set 1}; B --> C1["Pattern 1 (e.g., Pulse)"]; B --> C2["Pattern 2 (e.g., Vibrate)"]; B --> C3["Pattern 3 (e.g., Taps)"]; end subgraph User Input D[Multi-way Joystick]; end subgraph System Logic E[Concatenate Selection]; F{Render Option Set 2}; G[Target Item Selected]; end C1 -- User Presses Up --> E; C2 -- User Presses Down --> E; C3 -- User Presses Left --> E; D -- User Input --> C1; D -- User Input --> C2; D -- User Input --> C3; E --> F; F --> G;
Axis 2: Operational Parameter Expansion
2.1. Nanoscale Genomic Sequence Construction
Enabling Description: The method is applied to the design and selection of synthetic DNA or guide RNA sequences for CRISPR-based gene editing. The "database" is the entirety of a target genome (e.g., Homo sapiens, GRCh38) and a library of functional genetic elements (promoters, terminators, etc.). The "segments" are not characters, but specific codons, transcription factor binding sites, or short nucleotide sequences (k-mers). A bioinformatician using a specialized GUI selects segments to construct a target sequence. The system's ranking engine prioritizes segments that avoid off-target binding sites (pre-calculated via BLAST against the genome), maintain a desired GC content for thermal stability, and conform to codon optimization tables for a target expression organism. This significantly reduces the design time and error rate for creating new genetic constructs.
Diagram:
graph TD A(Start gRNA Design) --> B{Select Target Gene}; B --> C[Analyze Gene for PAM Sites]; C --> D{Generate Initial Segments}; D -- Top On-Target Score --> E1["Segment: G.T.A.C (k-mer 1)"]; D -- 2nd Best Score --> E2["Segment: C.C.G.A (k-mer 2)"]; E1 -- User Selects --> F{Generate Next Segments}; F -- Avoids Off-Target --> G1["Segment: T.T.A.G (k-mer 3)"]; F -- High GC-Content --> G2["Segment: G.C.C.G (k-mer 4)"]; G1 -- User Selects --> H[Append Segment to Construct]; H --> I{...Continue until full gRNA sequence is built}; I --> J[Final Sequence Ready for Synthesis];
2.2. High-Frequency Trading (HFT) Strategy Selection
Enabling Description: In this application, the selection method operates at microsecond latencies to construct and deploy algorithmic trading strategies. The "database" is a library of pre-defined trading "primitives" (e.g.,
MeanReversion,MomentumIndicator,ArbitragePair). The "segments" are these primitives and their tunable parameters (e.g.,lookback_period=50ms,symbol=USD/EUR). A supervisory trading algorithm or human operator uses the interface to assemble a complete trading strategy on the fly in response to changing market conditions. The ranking engine is a real-time system that prioritizes primitives based on current market volatility, liquidity, and correlation matrices. A selection is not made by a human click, but by an automated signal, and the concatenated "identifier" is a fully-formed, executable script that is immediately deployed on a co-located exchange server.Diagram:
sequenceDiagram participant Market as Market Data Feed participant Ranking as Real-time Ranking Engine participant Selector as Automated Selector participant Assembler as Strategy Assembler participant Exchange Market->>Ranking: Tick data (volatility, volume) loop Respond to Spike in Volatility Ranking->>Selector: Update primitive priorities (boost Momentum) Selector->>Assembler: Select segment "MomentumIndicator" Assembler->>Selector: Request next segment (parameters) Selector->>Assembler: Select segment "lookback=10ms" Assembler->>Selector: Request next segment (asset) Selector->>Assembler: Select segment "asset=ES_mini" Assembler-->>Exchange: Deploy constructed strategy: MomentumIndicator(asset=ES_mini, lookback=10ms) end
Axis 3: Cross-Domain Application
3.1. Aerospace: Emergency Procedure Selection in Cockpit
Enabling Description: This system is integrated into an aircraft's Electronic Flight Bag (EFB) or a primary flight display. The database contains the full Quick Reference Handbook (QRH) of emergency and non-normal procedures, indexed by structured identifiers (e.g.,
ENG-1-FIRE-SEVERE,HYD-A-FAIL-LEAK). During a high-workload event, the pilot uses a physical control, such as a rotary knob on the instrument panel, to select segments. Rotating the knob cycles through the current segment options, and pressing the knob selects one. The ranking engine is coupled to the aircraft's flight data computer; it automatically prioritizes procedures that match active fault warnings from the Engine-Indicating and Crew-Alerting System (EICAS). For example, if EICAS shows an "L ENG FIRE" warning, the segments "ENG," "1," and "FIRE" are immediately promoted to the top of the selection list.Diagram:
stateDiagram-v2 [*] --> Idle Idle --> EICAS_Alert: EICAS shows "HYD A SYS FAULT" EICAS_Alert --> ActiveSelection: Pilot engages selection knob ActiveSelection: Display ranked segments: 1. HYD, 2. ENG, 3. ELEC ActiveSelection --> Segment1_Selected: Pilot selects "HYD" Segment1_Selected: Display ranked segments: 1. A, 2. B, 3. C Segment1_Selected --> Segment2_Selected: Pilot selects "A" Segment2_Selected: Display ranked segments: 1. FAIL, 2. LEAK, 3. OVHT Segment2_Selected --> Procedure_Identified: Pilot selects "FAIL" Procedure_Identified: Display full "Hydraulic System A Failure" checklist Procedure_Identified --> [*]
Axis 4: Integration with Emerging Tech
4.1. Generative AI-based Semantic Completion
Enabling Description: The deterministic, tree-based engine of the original patent is replaced with a fine-tuned, large language model (LLM) like a transformer. The LLM is trained on the database of items and a large corpus of user selection sessions. Instead of finding literal divergence points in strings, the engine generates the most probable next segments based on the semantic meaning of the previously selected segments. This allows for more intuitive and flexible selections. For example, if a user is selecting from a recipe database and has selected the segment "Italian," the system may propose "Pasta," "Risotto," and "Tomato" as the next segments, even if no recipe names begin with "ItalianPasta." The LLM has learned the conceptual relationship. The "entry so far" is a vector embedding, not just a string, allowing for fuzzy and conceptual matching.
Diagram:
flowchart LR subgraph User Interaction A[User selects segment "Spicy"] end subgraph Generative Engine B[Input: "Spicy"] --> C{Convert to Token Embedding}; C --> D[LLM Inference]; D --> E{Generate Probability Distribution over Vocabulary}; E --> F[Sample Top-K Next Segments]; end subgraph UI Display G[Display Segment: "Taco"] H[Display Segment: "Curry"] I[Display Segment: "Chili"] end A --> C; F --> G; F --> H; F --> I;
4.2. IoT-Modulated Prioritization for Predictive Maintenance
Enabling Description: The system is used by a field technician to access maintenance procedures for industrial equipment on a ruggedized tablet. A network of IoT sensors (vibration, thermal, acoustic) is attached to the machinery. The sensor data streams to a cloud-based analytics platform that runs a predictive failure model. The ranking of the selectable segments in the technician's partial word completion interface is dynamically modulated by the output of this model. If sensors on Pump-7B indicate anomalous high-frequency vibrations, the failure model will increase the priority score for any maintenance procedure containing the identifiers "Pump-7B," "bearing," "seal," or "impeller." When the technician begins a search, these contextually relevant segments are presented first, drastically reducing the time to find the correct troubleshooting guide.
Diagram:
sequenceDiagram participant IoT_Sensor as IoT Sensor (Pump-7B) participant Analytics as Cloud Analytics Platform participant PWC_Engine as PWC Ranking Engine participant Technician as Technician's Tablet loop Real-time Monitoring IoT_Sensor->>+Analytics: Vibration telemetry data Analytics->>Analytics: Predictive model detects bearing wear signature Analytics->>+PWC_Engine: Send priority boost: {item: "bearing", device: "Pump-7B", score: +50} end Technician->>+PWC_Engine: Initiate search PWC_Engine-->>-Technician: Display initial segments ( "bearing" is now #1) Technician->>PWC_Engine: Selects "bearing" PWC_Engine-->>-Technician: Display next segments ("Pump-7B" is now #1)
Axis 5: The "Inverse" or Failure Mode
5.1. Ambiguity-Prioritizing "Discovery Mode"
Enabling Description: This variation inverts the primary goal from rapid convergence to guided exploration. It is designed for users who are browsing or are unsure of the specific item they need. When presenting the next set of selectable segments, the ranking algorithm prioritizes segments that lead to the most diverse or largest remaining sets of items. The UI is modified to display not just the segment string, but also a "result count" for the branch that segment opens. For example, when searching a music library, after selecting "Rock," the system might display "Classic [5,300 items]," "Alternative [2,100 items]," and "Progressive [450 items]." This allows the user to understand the structure of the database and make informed decisions to either narrow the search or explore a broad category. This mode is explicitly selectable by the user (e.g., via a "Search vs. Discover" toggle).
Diagram:
graph TD A(Start Discovery) --> B{Select Genre}; B -- User Selects --> C(Electronic); C --> D{Render Next Segments by Result Count}; D --> E["House [7201 items]"]; D --> F["Trance [4880 items]"]; D --> G["Ambient [1230 items]"]; D --> H["Dubstep [950 items]"]; E -- User wants to explore a large sub-genre --> I{Select Sub-Genre}; I --> J["Deep House [3105 items]"]; I --> K["Progressive House [2500 items]"];
Combination Prior Art Scenarios
1. Combination with WAI-ARIA Standard
- Disclosure: A method for selecting an item from a database, wherein the user interface presenting selectable segments is implemented as a web component conforming to the W3C WAI-ARIA 1.2 standard. The selection container has a role of
listbox, and each selectable text segment is an element with a role ofoption. The currently focused-on option is indicated via thearia-activedescendantproperty of the listbox, and user selection updates thearia-selectedstate of the chosen option. This implementation ensures the selection mechanism is fully operable via assistive technologies like screen readers, making the application of web accessibility standards to this method obvious.
2. Combination with MQTT Open Standard
- Disclosure: A distributed system for selecting an item, wherein the interface component and the engine component communicate via the ISO/IEC 20922 standard MQTT protocol. The user's selection of a segment on a client device causes the device to publish a message containing the "entry so far" to a shared MQTT topic (e.g.,
kannuu/query). A server-side engine, subscribed to that topic, processes the query and publishes the next set of ranked segments to a response topic (e.g.,kannuu/response/[clientID]). This architecture demonstrates the obvious use of a standard lightweight messaging protocol to enable the patented method in a distributed or IoT environment.
3. Combination with Unicode CLDR Standard
- Disclosure: A process for selecting an item from a database containing items in multiple languages, wherein the initial step of analyzing item identifiers to create segments is performed according to the locale-specific word boundary rules defined in the Unicode Common Locale Data Repository (CLDR). For a database of Thai song titles, the engine uses the CLDR's Thai segmentation dictionary to correctly identify word-based segments despite the absence of spaces. For German, it can use CLDR's rules to identify meaningful sub-components in long compound words. This makes the adaptation of the segmentation logic to be linguistically correct using open-source internationalization standards an obvious extension.
Generated 5/13/2026, 12:28:14 AM