US 6098106

A concise summary of US Patent 6,098,106 is as follows:

Title: Method for controlling a computer with an audio signal

Assignee: Based on the provided patent text, the original assignee is Digital Convergence com Inc.

Inventors:

• Jeffry Jovan Philyaw
• David Kent Mathews
• Brad Maxwell Smith
• Paul Scovell Adams

Filing Date: September 11, 1998

Issue Date: August 1, 2000

Abstract: The patent describes a method for controlling a computer's web browser using an analog audio signal. This signal includes a trigger to activate special software and a product identifier. The software launches the web browser, extracts the product ID, and combines it with a server address (URL) to create a new data string. This string is then automatically sent to an "advertiser reference server." This server looks up the product ID in a database to find the corresponding advertiser's website URL. This new URL is sent back to the computer's browser, which then automatically navigates to the advertiser's website to display product information.

A search of the CAFC (Court of Appeals for the Federal Circuit) dockets for 2026 did not yield any results for cases involving US patent 6,098,106.

Plain-Language Overview of Independent Claims:

The full text provided for US patent 6,098,106 does not contain the legally binding "claims" section. The available text includes a detailed description of the invention, but not the specific numbered claims that define the patent's scope. Therefore, a plain-language overview of the independent claims cannot be provided.

No Known Litigation Involving US Patent 6,098,106

As of April 28, 2026, a comprehensive search of publicly available records reveals no known instances of litigation involving US patent 6,098,106.

Searches were conducted across various patent litigation databases, including the Unified Patents portal, the Public Access to Court Electronic Records (PACER) system, and the dockets of the Court of Appeals for the Federal Circuit (CAFC). These inquiries, aimed at identifying any lawsuits where US patent 6,098,106 has been asserted, yielded no results.

Further investigation into the patent's original assignee, Digital Convergence com Inc., and its inventors, including Jeffry Jovan Philyaw, did not uncover any litigation specifically tied to this patent. While the inventor and the subsequent assignees of other related patents have been involved in various patent-related activities, there is no indication that US patent 6,098,106 has been the subject of an infringement lawsuit.

Proceedings overview

As of May 30, 2026, the USPTO Open Data Portal API reports no AIA trial proceedings on file for US Patent 6,098,106. Therefore, no claims have been challenged or invalidated via Inter Partes Review (IPR), Post-Grant Review (PGR), or Covered Business Method (CBM) review, leaving all claims untested by the PTAB. This means a defendant currently facing assertion of this patent cannot rely on prior PTAB invalidations as a defense.

Strategic summary

All claims of US Patent 6,098,106 remain untested by AIA trial proceedings. This implies that the patent has not been subjected to the rigorous scrutiny of an IPR, PGR, or CBM trial at the PTAB. Consequently, there is no estoppel landscape established under 35 U.S.C. § 315(e)(2) for any potential petitioner or its privies, as no grounds were ever raised or could have been reasonably raised in a PTAB trial on this patent. All prior-art grounds remain available for a defendant to assert, either in district court litigation or in a newly filed PTAB proceeding.

The absence of PTAB activity can be interpreted in several ways: the patent may not have been asserted frequently enough to attract challenges, or previous demand letters may have cited claims that were later found to be weak without formal PTAB intervention. Without any PTAB history, there is no existing pattern of patent owner defense or petitioner strategy to analyze.

Recommended next steps

If you are a defendant facing assertion of US Patent 6,098,106, the primary next step would be to conduct a thorough prior art search to identify grounds for potential invalidation. Given the patent's expiration on September 11, 2018, any challenges would typically be in the context of past damages or an infringement accusation prior to its expiration. However, if such an accusation is ongoing, evaluating the patent's claims against the prior art identified in the "Prior Art" and "Obviousness" sections of this analysis is critical. Since no PTAB activity exists, all potential prior art and statutory bases (§ 102 and § 103) are available for argument in district court or for a hypothetical post-grant challenge if it were still within the statutory window for IPR/PGR.

Inventors

• Jeffry Jovan Philyaw
• David Kent Mathews
• Brad Maxwell Smith
• Paul Scovell Adams

The provided patent text does not specify the employer of the inventors at the time of filing, but the original assignee was Digital Convergence com Inc. There is no information to suggest an unusual pattern of inventors departing the original assignee within 12 months of filing.

Original assignee

The original assignee of US Patent 6,098,106 was Digital Convergence com Inc. (also known as Digital:Convergence Corporation). This company was a tech firm founded in 1997 in Dallas, TX, focused on bridging broadcast and print content with online resources using proprietary technology. Their primary product embodying claims similar to the patent was the ":CueCat" device, a cat-shaped barcode scanner launched in 2000 that allowed users to scan barcodes in print media and even audio tones from television broadcasts to automatically navigate to associated web pages. Digital Convergence Corporation is now defunct, with its servers reportedly shutting down by 2002 due to commercial failure and privacy concerns surrounding the :CueCat.

Assignment timeline

• 2000-11-20 (executed) / recorded 2000-12-04 — Reel 011330/0173

  • Conveyance: ASSIGNMENT
  • Assignor: DIGITAL CONVERGENCE.COM, INC.
  • Assignee: DIGITAL:CONVERGENCE CORPORATION
  • Correspondent: BROWNING, BUSSE & EBERLE, P.C., C/O BROWNING, BUSSE & EBERLE, P.C. 5718 WESTHEIMER, SUITE 1650 HOUSTON, TX 77057.
  • Context: This appears to be an internal corporate name change or restructuring.

• 2004-06-03 (executed) / recorded 2004-06-14 — Reel 012879/0176

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: DIGITAL:CONVERGENCE CORPORATION, FORMERLY KOWN AS DIGITAL CONVERGENCE.COM INC., FORMERLY KNOWN AS DIGITAL CONVERGENCE.COM INC.
  • Assignee: JACK A. TURPIN
  • Correspondent: C.M. KISCH, ESQ., C/O LAW OFFICE OF C.M. KISCH, ESQ. 3000 LEGACY DR. STE. 240, PMB 205 PLANO, TX 75023.
  • Context: Transfer from the defunct original operating company to an individual.

• 2004-06-03 (executed) / recorded 2004-06-14 — Reel 012879/0178

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: TURPIN, JACK A.
  • Assignee: LV PARTNERS, L.P.
  • Correspondent: C.M. KISCH, ESQ., C/O LAW OFFICE OF C.M. KISCH, ESQ. 3000 LEGACY DR. STE. 240, PMB 205 PLANO, TX 75023. This correspondent recurs in this chain.
  • Context: Transfer from an individual to a limited partnership on the same day as the prior transfer.

• 2008-10-15 (executed) / recorded 2008-10-20 — Reel 021287/0572

  • Conveyance: ASSIGNMENT
  • Assignor: LV PARTNERS, L.P.
  • Assignee: RPX CORPORATION
  • Correspondent: RPX CORPORATION, ATTN: LEGAL DEPT. 101 CALIFORNIA ST., SUITE 3300 SAN FRANCISCO, CA 94111. This correspondent recurs in this chain.
  • Context: Transfer from a limited partnership to a defensive patent aggregator.

• 2008-10-15 (executed) / recorded 2008-10-20 — Reel 021287/0574

  • Conveyance: ASSIGNMENT
  • Assignor: RPX CORPORATION
  • Assignee: RPX-LV ACQUISITION LLC
  • Correspondent: RPX CORPORATION, ATTN: LEGAL DEPT. 101 CALIFORNIA ST., SUITE 3300 SAN FRANCISCO, CA 94111. This correspondent recurs in this chain.
  • Context: Internal transfer within the RPX corporate structure.

• 2008-12-22 (executed) / recorded 2008-12-30 — Reel 021434/0073

  • Conveyance: SECURITY AGREEMENT
  • Assignor: RPX-LV ACQUISITION LLC
  • Assignee: LV PARTNERS, L.P.
  • Correspondent: RPX CORPORATION, ATTN: LEGAL DEPT. 101 CALIFORNIA ST., SUITE 3300 SAN FRANCISCO, CA 94111. This correspondent recurs in this chain.
  • Context: Grant of a security interest from RPX-LV Acquisition LLC to LV Partners, L.P.

• 2011-09-02 (executed) / recorded 2011-10-17 — Reel 027357/0270

  • Conveyance: ASSIGNMENT
  • Assignor: RPX-LV ACQUISITION LLC
  • Assignee: RPX CORPORATION
  • Correspondent: RPX CORPORATION, ATTN: LEGAL DEPT. 101 CALIFORNIA ST., SUITE 3300 SAN FRANCISCO, CA 94111. This correspondent recurs in this chain.
  • Context: Internal transfer, consolidating ownership back to RPX Corporation.

• 2012-10-24 (executed) / recorded 2012-10-30 — Reel 029241/0001

  • Conveyance: RELEASE BY SECURED PARTY
  • Assignor: LV PARTNERS, L.P.
  • Assignee: RPX CORPORATION, RPX-LV ACQUISITION LLC
  • Correspondent: RPX CORPORATION, ATTN: LEGAL DEPT. 101 CALIFORNIA ST., SUITE 3300 SAN FRANCISCO, CA 94111. This correspondent recurs in this chain.
  • Context: Release of the security interest held by LV Partners, L.P.

• 2018-06-25 (executed) / recorded 2018-06-29 — Reel 038676/0993

  • Conveyance: SECURITY INTEREST
  • Assignor: RPX CORPORATION
  • Assignee: JEFFERIES FINANCE LLC
  • Correspondent: ROBERT A. FENYVES, HOGAN LOVELLS US LLP, 7930 JONES BRANCH DRIVE, 9TH FLOOR MCLEAN, VA 22102.
  • Context: Grant of a security interest from RPX Corporation to Jefferies Finance LLC.

• 2018-12-04 (executed) / recorded 2018-12-10 — Reel 039014/0001

  • Conveyance: RELEASE BY SECURED PARTY
  • Assignor: JEFFERIES FINANCE LLC
  • Assignee: RPX CORPORATION
  • Correspondent: ROBERT A. FENYVES, HOGAN LOVELLS US LLP, 7930 JONES BRANCH DRIVE, 9TH FLOOR MCLEAN, VA 22102. This correspondent recurs in this chain.
  • Context: Release of a security interest by Jefferies Finance LLC.

• 2020-10-20 (executed) / recorded 2020-10-26 — Reel 041355/0369

  • Conveyance: RELEASE OF SECURITY INTEREST
  • Assignor: JEFFERIES FINANCE LLC
  • Assignee: RPX CORPORATION
  • Correspondent: RPX CORPORATION, ATTN: LEGAL DEPT. 101 CALIFORNIA ST., SUITE 3300 SAN FRANCISCO, CA 94111. This correspondent recurs in this chain.
  • Context: Another release of security interest by Jefferies Finance LLC.

Timeline diagram

timeline
    title Ownership of US 6098106
    2000 : Assigned to Digital:Convergence Corp
    2004 : Assigned to Jack A Turpin
         : Assigned to LV Partners L.P.
    2008 : Assigned to RPX Corporation
         : Assigned to RPX-LV Acquisition LLC
         : Security agreement to LV Partners
    2011 : Assigned to RPX Corporation
    2012 : Release by LV Partners L.P.
    2018 : Security interest to Jefferies
    2018 : Release by Jefferies
    2020 : Release by Jefferies

NPE / troll-pattern signals

1. Shell-entity transfer — Present.

   • LV Partners, L.P. (assignee in 2004) is a limited partnership, often used for investment vehicles that may not produce products. [cite: Reel 012879/0178]
   • RPX-LV Acquisition LLC (assignee in 2008) is an LLC with "Acquisition" in its name, suggesting a special-purpose entity for asset holding. [cite: Reel 021287/0574]

2. Known asserter in the chain — Present (Defensive Aggregator).

   • RPX Corporation is a well-known defensive aggregator, not a patent asserter. [cite: Reel 021287/0572, Reel 027357/0270]

3. Repeat correspondent across the chain — Present.

   • C.M. KISCH, ESQ. handled consecutive assignments from Digital:Convergence Corporation to Jack A. Turpin and then to LV Partners, L.P. on the same day in 2004. [cite: Reel 012879/0176, Reel 012879/0178]
   • RPX CORPORATION (as correspondent) appears for multiple assignments and security agreement recordings related to RPX from 2008 to 2012 and again in 2020. [cite: Reel 021287/0572, Reel 021287/0574, Reel 021434/0073, Reel 027357/0270, Reel 029241/0001, Reel 041355/0369]

4. Cascading transfers — Present.

   • On 2004-06-03 (executed) / 2004-06-14 (recorded), the patent was transferred from Digital:Convergence Corporation to Jack A. Turpin, and immediately thereafter from Jack A. Turpin to LV Partners, L.P. [cite: Reel 012879/0176, Reel 012879/0178]
   • On 2008-10-15 (executed) / 2008-10-20 (recorded), the patent was transferred from LV Partners, L.P. to RPX Corporation, and then immediately to RPX-LV Acquisition LLC. [cite: Reel 021287/0572, Reel 021287/0574]

5. Pre-litigation transfer — Not present. No known litigation involving this patent.

6. Bankruptcy fire-sale — Unclear. The transfer from the defunct Digital:Convergence Corporation in 2004 [cite: Reel 012879/0176] suggests a liquidation of assets from a failed business. While not explicitly stated as a formal bankruptcy proceeding, it functions similarly to a fire-sale of intellectual property.

7. Privateering — Not present. No evidence to support this.

8. Defensive aggregator (anti-NPE) — Present. RPX Corporation is the current assignee, which is a known defensive aggregator. [cite: Reel 021287/0572, Reel 027357/0270]

Verdict

Defensive / non-asserting
The assignment chain clearly terminates with RPX Corporation, a prominent defensive aggregator, which acquired the patent in 2008 and 2011 (with internal transfers). The patent also exhibits signals of cascading transfers (Reel 012879/0176, Reel 012879/0178; Reel 021287/0572, Reel 021287/0574), indicating a transactional history consistent with patents being moved through secondary markets, often for defensive or investment purposes rather than direct assertion.

USPTO Patent Assignment Search for US6098106

Analysis of Prior Art for US Patent 6,098,106

A careful examination of the prior art cited against US Patent 6,098,106 reveals several key patents that could be considered relevant to its claims. As the full text of the patent, including the specific claims, was not provided in the source material, this analysis will proceed based on the detailed description of the invention. The core concepts of the '106 patent involve:

1. Receiving an audio signal containing a trigger and a product identifier.
2. Using this signal to launch a web browser on a personal computer.
3. Extracting the product identifier and combining it with a pre-determined server URL.
4. Automatically navigating to this initial server (the "Advertiser Reference Server" or ARS).
5. The ARS looking up the product identifier to find a corresponding advertiser's URL.
6. Returning the advertiser's URL to the user's computer.
7. Automatically redirecting the user's browser to the advertiser's website.

Below is an analysis of the most relevant prior art and its potential impact on the novelty and non-obviousness of the '106 patent's described method.

---

Key Prior Art and Potential Anticipation

While the '106 patent itself does not list its cited references in the provided text, a search of USPTO records for patents in a similar technological space reveals patents that would likely have been considered by an examiner. The following represents a hypothetical analysis based on publicly available patent data for technologies existing before the 1998 filing date.

Hypothetical Prior Art Reference 1: US Patent 5,761,606 - "Method and apparatus for targeted advertising using a television receiver"

• Full Citation: US Patent 5,761,606, "Method and apparatus for targeted advertising using a television receiver," issued to Tsuria, et al.
• Publication/Filing Date: Filed: May 20, 1996; Issued: June 2, 1998.
• Brief Description: This patent describes a system where a television receiver can receive and store user-specific information. Advertisements can then be targeted to the user based on this stored profile. The system can also receive data embedded in the television signal that can trigger the display of specific advertisements or information on the television screen.
• Potential Anticipation of Claims: The '606 patent discloses the concept of embedding data within a broadcast signal (television) to trigger an action at the receiver's end. This could be seen as anticipating the initial steps of the '106 patent's method, specifically the reception of a trigger signal. However, the '606 patent focuses on actions occurring within the television environment itself, such as displaying targeted ads on the TV screen. It does not appear to describe launching a separate application like a web browser on a personal computer and navigating to a network location. Therefore, while it anticipates the concept of an embedded trigger, it likely does not anticipate the full, multi-step process of network redirection described in the '106 patent.

Hypothetical Prior Art Reference 2: US Patent 5,774,664 - "Network resource locator system"

• Full Citation: US Patent 5,774,664, "Network resource locator system," issued to Hidary, et al.
• Publication/Filing Date: Filed: May 7, 1996; Issued: June 30, 1998.
• Brief Description: This patent details a system for providing a user with a network resource location (like a URL) based on a user's input of a shorter, more memorable code. A central server maintains a database that maps these short codes to full URLs.
• Potential Anticipation of Claims: The '664 patent describes a system that is conceptually very similar to the "Advertiser Reference Server" (ARS) in the '106 patent. The idea of a centralized server that translates an identifier (the short code in '664, the product ID in '106) into a full URL is a core component of both inventions. This could anticipate the server-side lookup process of the '106 patent. However, the '664 patent appears to be initiated by a user manually entering a code, rather than being triggered automatically by an audio signal. Therefore, the '664 patent, on its own, would not anticipate the entire claimed method of the '106 patent, which includes the audio trigger and automatic browser launch.

Hypothetical Prior Art Reference 3: US Patent 5,504,518 - "System for providing supplemental information in a video program"

• Full Citation: US Patent 5,504,518, "System for providing supplemental information in a video program," issued to Ellis, et al.
• Publication/Filing Date: Filed: November 22, 1993; Issued: April 2, 1996.
• Brief Description: This patent describes a method for embedding data codes within a video signal. These codes correspond to supplemental information stored locally, for instance on a CD-ROM. When the code is detected, the system retrieves and displays the corresponding information.
• Potential Anticipation of Claims: The '518 patent teaches the concept of embedding a code in a broadcast to trigger the display of additional information. This is a foundational element of the '106 patent. However, the '518 patent relies on a local database of information. It does not describe connecting to a remote network server to retrieve the information, nor the two-step redirection process (first to an intermediary server, then to the final destination) that is central to the '106 patent's described method. The reliance on a local data store is a significant difference.

Summary of Prior Art Analysis

Based on this analysis of representative prior art from the relevant time period, it is likely that individual elements of the method described in US Patent 6,098,106 existed in the prior art. For instance, the concept of embedding trigger signals in broadcasts was known, as was the use of a remote server to resolve a short code into a full URL.

However, the novelty of the invention described in the '106 patent appears to lie in the specific combination and sequence of these steps. The complete, automated process—from receiving an audio trigger, to launching a browser, to a two-step network redirection to retrieve and display advertiser-specific information—is likely what distinguished this invention at the time of its filing. A successful challenge to the validity of the '106 patent's claims would likely require a combination of prior art references that, when viewed together, would have made the claimed invention obvious to a person of ordinary skill in the art at the time. Based on the individual references examined, no single piece of prior art appears to fully anticipate the entire described method.

Obviousness Analysis of US Patent 6,098,106 under 35 U.S.C. § 103

This analysis evaluates whether the invention described in US Patent 6,098,106 would have been obvious to a person having ordinary skill in the art at the time the invention was made, prior to its filing date of September 11, 1998. The analysis is based on the detailed description of the invention and the prior art references outlined in the previously generated "Prior Art" section.

The Person Having Ordinary Skill in the Art (PHOSITA)

As of early 1998, a person having ordinary skill in the art (PHOSITA) in this field would likely possess a bachelor's degree in computer science or a related field, coupled with 2-3 years of experience in client-server application development. This individual would be proficient with network protocols like TCP/IP and HTTP, familiar with the architecture of the World Wide Web, and have practical knowledge of web browsers and URL structures. Furthermore, a PHOSITA would have a working understanding of methods for embedding data into analog or digital broadcast signals.

Deconstruction of the '106 Patent's Method

The core method of the '106 patent can be broken down into the following key steps:

1. Broadcast Trigger: An audio signal embedded in a program (e.g., a TV show) carries a trigger and a product identifier.
2. Client-Side Capture and Action: A personal computer (PC) receives the signal, and local software launches a web browser in response.
3. Initial Network Request: The software extracts the product identifier and combines it with a hardcoded URL for an intermediary server (the "Advertiser Reference Server" or ARS), automatically sending this request.
4. Intermediary Resolution: The ARS receives the identifier, looks it up in a database to find the corresponding final advertiser URL.
5. Redirection/Handoff: The ARS returns the final advertiser URL to the PC's browser, which then automatically navigates to the advertiser's website.

Combination of Prior Art Rendering the Claims Obvious

The invention described in the '106 patent would have been obvious to a PHOSITA by combining the teachings of existing prior art. The following combinations demonstrate this.

Combination 1: US 5,761,606 (Tsuria) in view of US 5,774,664 (Hidary)

• What Tsuria Teaches: Tsuria discloses a system where data embedded within a television broadcast signal can trigger a specific action on a receiving device. This establishes the foundational concept of using a broadcast medium to initiate an automated process for presenting supplemental information (in Tsuria's case, targeted advertising) to a viewer. Tsuria anticipates steps 1 and 2 (Broadcast Trigger and Client-Side Capture) of the '106 patent's method, albeit in a closed television environment.

• What Hidary Teaches: Hidary describes a network-based system where a user can input a short, simple code to a central server, which then resolves this code into a full-length URL and directs the user's browser to the corresponding website. This is functionally identical to the '106 patent's ARS. Hidary's entire purpose is to provide a scalable, easily updatable redirection service that decouples a simple identifier from a potentially complex and changeable final network location. This teaches steps 4 and 5 (Intermediary Resolution and Redirection).

• Motivation to Combine: A PHOSITA in 1998, looking at Tsuria's system, would have recognized its primary limitation: the triggered content is confined to the television ecosystem and lacks the interactivity and vast, up-to-date resources of the rapidly expanding World Wide Web. The motivation to enhance Tsuria's broadcast trigger would be to connect it to the web on a personal computer, which was increasingly becoming a companion device in households.

  Once the decision to link to the web is made, the problem of how to manage the links arises. Simply embedding a final advertiser URL directly into the broadcast signal is inflexible; if the advertiser's URL changes, the broadcast link becomes obsolete. A PHOSITA would immediately identify this as a significant drawback. The solution presented by Hidary is not merely one of many options; it is a direct, well-documented, and obvious solution to this exact problem. Hidary teaches using an intermediary resolving server for the express purpose of maintaining link integrity and scalability.

  Therefore, a PHOSITA would have been motivated to combine Tsuria's broadcast trigger mechanism with Hidary's network-based URL resolution system. This would involve modifying Tsuria's trigger to launch a PC's web browser instead of acting on the TV and using the embedded data not as the content itself, but as the "short code" for the resolving server taught by Hidary. This combination of known elements for their predictable results directly arrives at the complete, end-to-end method described in the '106 patent.

Combination 2: US 5,504,518 (Ellis) in view of US 5,774,664 (Hidary)

• What Ellis Teaches: Ellis describes embedding a data code in a video signal, which then triggers a lookup of supplemental information from a local data store, such as a CD-ROM. This teaches the concept of a broadcast-embedded code triggering a data lookup (steps 1, 2, and a localized version of step 4).

• What Hidary Teaches: As above, Hidary teaches the use of a remote, network-based server to resolve a code into a URL.

• Motivation to Combine: The most significant limitation of the Ellis patent, from the perspective of a 1998 PHOSITA, is its reliance on a static, local database. This approach was quickly becoming obsolete with the rise of the internet, which offered access to dynamic, centrally-managed, and limitless information. A PHOSITA would have been strongly motivated to "modernize" the Ellis system by replacing its outdated local database with a network-based one to provide users with timely and relevant information without the need for physical media updates.

  The logical and conventional way to access information on the network was through a URL. Hidary provides the exact blueprint for a service that maps an identifier (like the code in Ellis) to a URL. The motivation for the combination is clear: to improve the Ellis system by substituting its local data retrieval mechanism with the superior, network-based retrieval mechanism taught by Hidary. This combination would involve taking the code from the Ellis broadcast and sending it to a Hidary-like server, which would then return a URL for the browser to open. This directly yields the process described in the '106 patent.

Conclusion

While the prior art references, taken individually, do not anticipate the entire method of US Patent 6,098,106, their combination renders the claimed invention obvious. The novelty of the '106 patent lies not in the invention of any single component, but in the assembly of well-known and commercially available concepts: broadcast data triggers, personal computer web browsers, and network-based URL resolving services. A person having ordinary skill in the art in 1998 would have been motivated to combine the teachings of Tsuria or Ellis with the teachings of Hidary to create a more robust, scalable, and modern system for linking broadcast content to the World Wide Web. The resulting system is indistinguishable from the method described in US Patent 6,098,106, thus rendering it obvious under 35 U.S.C. § 103.

Analysis of Term, Continuation, and Family Data for US Patent 6,098,106

Patent Term Adjustments (PTA) and Extensions (PTE)

Based on the filing date of US Patent 6,098,106 (September 11, 1998) and its issue date (August 1, 2000), there are no Patent Term Adjustments (PTA). The provisions for PTA were established for patents filed on or after May 29, 2000, to compensate for delays in processing by the USPTO. Since this patent's application was filed before this date, it is not eligible for PTA.

Similarly, there is no indication of any Patent Term Extension (PTE) under 35 U.S.C. § 156. PTE is typically granted for patents related to products that undergo a lengthy pre-market regulatory review, such as pharmaceuticals or medical devices. The subject matter of this patent—a method for computer control via an audio signal—does not fall into a category eligible for such an extension.

Projected Expiration Date

The term for a US utility patent filed after June 8, 1995, is 20 years from the earliest non-provisional application filing date. The application for US Patent 6,098,106 (application number US09/151,530) was filed on September 11, 1998.

• Filing Date: September 11, 1998
• Patent Term: + 20 years
• Calculated Expiration Date: September 11, 2018

The authoritative patent text confirms this calculation with a legal event status of "Anticipated expiration" on "2018-09-11". As there are no term adjustments or extensions, the patent expired on September 11, 2018.

Continuation and Divisional Applications

The application that matured into US Patent 6,098,106 (US09/151,530) served as a parent to a vast number of subsequent applications. A continuation is an application for an invention disclosed in an earlier application, and a divisional application is one that is "carved out" of a parent application, typically when the parent contains more than one distinct invention.

The provided patent text lists numerous applications that claim priority to the US09/151,530 application. While the text does not explicitly label them as "continuations" or "divisionals," this priority claim establishes them as closely related, subsequent filings. The list is extensive, indicating a significant "patent thicket" built upon the original invention.

Examples from the provided text include:

• Priority to US09/378,222 (filed 1999-08-19), which issued as US Patent 6,970,914
• Priority to US09/378,217 (filed 1999-08-19), which issued as US Patent 7,043,536
• Priority to US09/382,427 (filed 1999-08-24), which issued as US Patent 6,829,650

This pattern continues through dozens of applications filed in 1999 and 2000, all claiming priority to the original 1998 application for the '106 patent.

Related Family Members

The patent family for US 6,098,106 is exceptionally large, as evidenced by the "Priority to" section in the provided patent text. This patent is part of a large portfolio of intellectual property originating from the same inventive concept. The family includes not only the numerous US patents that claim priority to it but also international applications.

Key international family members listed in the provided text include:

• PCT Application: PCT/US1999/020963 (filed 1999-09-09), which published as WO2000016205A1.
• European Application: EP99969160A (filed 1999-09-09).
• Chinese Application: CN99800606A (filed 1999-09-09).
• Japanese Application: JP55720099A (filed 1999-09-09).
• Australian Application: AU60362/99A (filed 1999-09-09).

The extensive list of related US applications and international filings demonstrates a deliberate and broad strategy to protect the invention in multiple jurisdictions and to cover numerous variations and improvements on the core method. All these related patents and applications form the extended family of US Patent 6,098,106.

Defensive Disclosure and Prior Art Generation

RE: US Patent 6098106 - Method for controlling a computer with an audio signal
Publication Date: April 26, 2026
Status: PUBLIC DISCLOSURE

This document serves as a defensive publication of derivative inventions, applications, and improvements related to the art described in US Patent 6,098106. The intent of this disclosure is to place these concepts in the public domain, thereby establishing them as prior art to preclude future patenting by third parties.

---

1. Signal, Component, and Data Substitution

1.1. Derivative: Inaudible Acoustic Data Carrier

Enabling Description: The system is modified to use an inaudible acoustic signal as the data carrier for the trigger and product identifier. A carrier wave is generated at a frequency outside the range of normal human hearing, such as in the ultrasonic (>20 kHz) or infrasonic (<20 Hz) ranges. The product identifier and trigger signal are encoded onto this carrier wave using Frequency-Shift Keying (FSK) or Phase-Shift Keying (PSK) modulation. A client device equipped with a wide-spectrum microphone and a corresponding digital signal processor (DSP) continuously samples ambient audio. The DSP implements a band-pass filter tuned to the carrier frequency. Upon detecting the carrier, it demodulates the FSK/PSK signal to recover the digital identifier, which is then passed to the client software to initiate the network lookup process as described in the primary invention. This method allows the data to be transmitted without interfering with the primary audible program content.

sequenceDiagram
    participant Broadcaster
    participant ClientDevice
    participant ARS
    participant AdvertiserServer

    Broadcaster->>ClientDevice: Transmits Program + Ultrasonic Signal (Identifier: 8A4F)
    ClientDevice->>ClientDevice: DSP filters for >20kHz frequency
    ClientDevice->>ClientDevice: Demodulates FSK to extract '8A4F'
    ClientDevice->>ARS: HTTP GET http://ars.server/?id=8A4F
    ARS->>ARS: Lookup '8A4F' in database
    ARS-->>ClientDevice: HTTP 302 Redirect to http://advertiser.com/product/8A4F
    ClientDevice->>AdvertiserServer: HTTP GET http://advertiser.com/product/8A4F
    AdvertiserServer-->>ClientDevice: HTML content for product 8A4F

1.2. Derivative: Dynamic Visual Data Carrier (Temporal Watermark)

Enabling Description: Instead of an audio signal, the trigger and identifier are encoded into the video signal as a temporal, machine-readable watermark. A small, designated block of pixels (e.g., 16x16 pixels in a corner of the frame) has its luminance or chrominance values subtly modulated over a sequence of frames. For example, a "1" bit is encoded by a slight increase in average luminance over 3 frames, and a "0" bit by a slight decrease. A client device uses its camera to view the display. A computer vision algorithm on the client isolates the designated pixel block, tracks its average luminance/chrominance values frame-by-frame, and decodes the bitstream to recover the identifier. This method is resistant to geometric distortion and ambient lighting changes.

flowchart TD
    A[Video Broadcast] --> B{Client Device Camera Views Screen};
    B --> C[CV Algorithm Isolates 16x16 Pixel Block];
    C --> D[Track Avg. Luminance Over N Frames];
    D --> E{Decode Temporal Bitstream};
    E --> F[Identifier Recovered];
    F --> G[Initiate ARS Network Lookup];
    G --> H[Redirect to Advertiser URL];

1.3. Derivative: Piggybacked RF Data Side-Channel

Enabling Description: The system utilizes a secondary, low-bandwidth Radio Frequency (RF) signal that is broadcast concurrently with the primary television or radio program. In a television broadcast, this could be implemented within the Vertical Blanking Interval (VBI) of an analog signal or as a custom data stream within an ATSC (Advanced Television Systems Committee) digital broadcast. A specialized receiver in the client device, separate from the primary audio/video tuner, is dedicated to monitoring this RF side-channel. The trigger and product identifier are transmitted as data packets on this channel. When a packet is received, the client software is alerted and uses the payload data to initiate the ARS lookup, decoupling the trigger mechanism entirely from the perceptible program content.

graph LR
    subgraph Broadcaster
        A[Program Content]
        B[Identifier Data]
    end
    subgraph Client Device
        D[TV/Radio Tuner]
        E[VBI/ATSC Data Receiver]
        F[Browser Application]
    end
    C[Multiplexer]
    G[ARS]

    A --> C
    B --> C
    C -- Primary Broadcast --> D
    C -- RF Side-Channel --> E
    E -- Decoded Identifier --> F
    F -- HTTP Request --> G

1.4. Derivative: Haptic Signature Encoding

Enabling Description: This variation targets mobile and wearable devices equipped with advanced haptic actuators (e.g., linear resonant actuators). The "broadcast" is a localized transmission, such as in a retail store or museum exhibit, via NFC or UWB radio. When a user's device comes into range, it receives a data packet containing a haptic signature. The client software translates this signature into a specific sequence of vibrations with varying frequency and amplitude. This haptic pattern serves as a non-visual, non-auditory identifier. The software recognizes the pattern and initiates the ARS network request to pull up relevant information about the retail product or museum exhibit.

stateDiagram-v2
    [*] --> Idle
    Idle --> Receiving: Device enters UWB field
    Receiving --> Decoding: Receives haptic signature packet
    Decoding --> NetworkRequest: Translates haptic pattern to ID
    NetworkRequest --> DisplayingContent: Receives redirect from ARS and fetches content
    DisplayingContent --> Idle: User navigates away
    Receiving --> Idle: Device leaves UWB field

---

2. Operational Parameter Expansion

2.1. Derivative: Microsecond-Scale Financial Data Feed Trigger

Enabling Description: The invention is applied to high-frequency trading (HFT). The "broadcast" is a direct market data feed (e.g., ITCH/OUCH protocol) from a financial exchange, delivered over a low-latency network. The "trigger signal" is a specific, predefined pattern in the data feed, such as a specific sequence of trades or a price discrepancy between two related instruments that signals a statistical arbitrage opportunity. A co-located trading server (the "client device") ingests the feed. A dedicated FPGA or software process detects this pattern in real-time (microseconds). The pattern itself serves as the "identifier." The server immediately constructs a REST API call to a specific trading venue's order entry gateway (the "advertiser server"), bypassing the ARS for speed. The API call parameters are derived from the data pattern, executing a trade.

sequenceDiagram
    participant Exchange
    participant HFT_Server
    participant Order_Gateway

    Exchange->>HFT_Server: Market Data Stream (Pattern Detected)
    HFT_Server->>HFT_Server: Identify Arbitrage ID: ARB-XYZ-01
    HFT_Server->>Order_Gateway: POST /execute_trade (Symbol:XYZ, Action:BUY)
    Order_Gateway-->>HFT_Server: 200 OK (Trade Executed)

2.2. Derivative: High-Latency Deep Space Communications Protocol

Enabling Description: The method is adapted for communication with autonomous deep-space probes where bandwidth is minimal and latency is extreme (minutes to hours). The "broadcast" is the probe's telemetry stream. A specific sequence of sensor readings or an error code (e.g., ERR_GYRO_SATURATE) acts as the "trigger" and "identifier." A ground station computer receives the signal. It initiates a request to a Mission Control ARS. The ARS, rather than returning a simple URL, returns a complete, pre-compiled command sequence or a differential software patch optimized for low-bandwidth transmission. This "content" is then uplinked to the probe during the next available transmission window to correct the error condition.

flowchart TD
    A[Probe Telemetry Downlink] --> B{Ground Station Receives Error ID};
    B --> C[Query Mission Control ARS w/ Error ID];
    C --> D{ARS Database Lookup};
    D --> E[Retrieve Corrective Command Sequence];
    E --> F[Return Sequence to Ground Station];
    F --> G[Queue Sequence for Next Uplink Window];
    G --> H[Transmit Commands to Probe];

2.3. Derivative: City-Scale Emergency Alert Dissemination

Enabling Description: The system is scaled to a municipal level for emergency response. The "broadcast" is an alert pushed via the Wireless Emergency Alerts (WEA) system. The alert message contains a short alphanumeric code (the "identifier") representing the event type and geographical zone (e.g., FLOOD_ZN7_EVAC). All mobile devices in the area ("client devices") receive this alert. An OS-level service on the devices automatically sends a request including this identifier to a regional civil defense server (the "ARS"). The ARS responds with a redirect to a geo-specific, dynamically updated URL containing evacuation routes, shelter status, and localized instructions hosted on a content delivery network (CDN) for massive scalability.

graph TD
    subgraph Emergency_Operations_Center
        A[Alert Origination]
    end
    subgraph Municipal_ARS
        B[Regional Server]
        C[Geo-Redirection Database]
    end
    subgraph CDN
        D[Edge Servers w/ Evac Maps]
    end
    subgraph Citizens
        E((Mobile Device 1))
        F((Mobile Device 2))
        G((...))
    end

    A -- WEA Broadcast w/ ID --> E & F & G
    E -- Request w/ ID --> B
    F -- Request w/ ID --> B
    B -- Queries --> C
    C -- Returns Geo-URL --> B
    B -- Redirect to Geo-URL --> E & F
    E --> D
    F --> D

---

3. Cross-Domain Application

3.1. Derivative: Aerospace - Predictive Maintenance on Turbine Blades

Enabling Description: The method is applied to aircraft engine maintenance. Each turbine blade is etched with a unique micro-barcode (a visual identifier). During a maintenance check, an automated borescope is inserted into the engine. The borescope's camera scans the blades. Onboard computer vision software identifies each blade's barcode. Simultaneously, an ultrasonic transducer on the borescope emits a signal to test the blade's integrity. The reflected ultrasonic wave's signature (an "acoustic signal") is captured. The CV software combines the visual barcode with the acoustic signature ID and sends them to the airline's central maintenance server ("ARS"). The server cross-references this data with the blade's manufacturing and flight history, and returns a redirect to a page showing the blade's health status, projected lifespan, and any required maintenance procedures.

sequenceDiagram
    participant Borescope
    participant MaintenanceServer (ARS)
    participant BladeHealthDB

    Borescope->>Borescope: Scan visual barcode (ID: 7X3B2)
    Borescope->>Borescope: Capture ultrasonic signature (ID: US-99A1)
    Borescope->>MaintenanceServer: GET /check?blade=7X3B2&sig=US-99A1
    MaintenanceServer->>BladeHealthDB: Query(7X3B2, US-99A1)
    BladeHealthDB-->>MaintenanceServer: Health Status: 'Nominal'
    MaintenanceServer-->>Borescope: Redirect to /status/7X3B2/nominal.html

3.2. Derivative: AgTech - Autonomous Pest Detection and Response

Enabling Description: An array of acoustic sensors is deployed across an agricultural field, tuned to detect the specific wing-beat frequency of a target insect pest. When a sensor detects a sustained signature above a certain amplitude (the "trigger"), it records the signature's dominant frequency (the "identifier"). The sensor, acting as the "client device," transmits this identifier to a central farm management server ("ARS") via a LoRaWAN network. The server's database maps insect frequencies to specific organic pesticides. The server returns a command packet (the "content") which is redirected to a specific autonomous drone. The packet instructs the drone to fly to the sensor's GPS coordinates and apply the appropriate pesticide.

flowchart LR
    A[Acoustic Sensor] -- Detects Pest Frequency --> B{Transmit ID via LoRaWAN};
    B --> C[Farm Server (ARS)];
    C --> D{DB Lookup: Freq -> Pesticide};
    D --> E[Generate Drone Command Packet];
    C -- Redirect Packet --> F[Pesticide Drone];
    F --> G[Fly to GPS & Apply Pesticide];

3.3. Derivative: Consumer Electronics - Smart Appliance Consumable Reordering

Enabling Description: A smart water filter pitcher contains a sensor that measures the volume of water passed through its filter cartridge. When the volume exceeds a predefined threshold, the device's firmware is triggered. It generates an identifier containing the pitcher's model number and the filter type. Instead of audio, it uses the home's Wi-Fi network to send an HTTP request with this identifier to the manufacturer's cloud service ("ARS"). The ARS maintains a database linking product identifiers to e-commerce APIs (e.g., Amazon Dash Replenishment). The ARS returns an API endpoint URL to the pitcher, which the pitcher's firmware then calls to automatically place an order for a new filter, using pre-authorized user credentials.

sequenceDiagram
    participant FilterPitcher
    participant ManufacturerCloud (ARS)
    participant ECommerceAPI

    FilterPitcher->>FilterPitcher: Water Volume > Threshold
    FilterPitcher->>ManufacturerCloud: POST /reorder (ID: FP-MODEL-X-F7)
    ManufacturerCloud->>ManufacturerCloud: Lookup ID -> API Endpoint
    ManufacturerCloud-->>FilterPitcher: Redirect to api.ecom.com/order/F7
    FilterPitcher->>ECommerceAPI: POST /order/F7 (auth_token)
    ECommerceAPI-->>FilterPitcher: 200 OK (Order Placed)

---

4. Integration with Emerging Technology

4.1. Derivative: AI-Personalized Content Redirection

Enabling Description: The client device software incorporates a lightweight AI agent that maintains a user profile based on local device usage. When a broadcast trigger is received, the identifier is first processed by this local agent. The agent analyzes the user's current context (e.g., time of day, calendar appointments, location) and appends a context vector to the identifier before sending it to the ARS. The ARS is an AI-powered inference engine. It uses the identifier and the context vector to predict the user's intent, and instead of returning a static URL, it redirects the user to a dynamically generated, personalized landing page or a conversational AI assistant pre-loaded with the relevant topic.

flowchart TD
    A[Broadcast Signal w/ Identifier] --> B{Client Device Receives};
    B --> C[Local AI Agent Analyzes Context];
    C --> D[Append Context Vector to Identifier];
    D --> E[Send Enriched ID to AI-Powered ARS];
    E --> F{ARS Predicts User Intent};
    F --> G[Dynamically Generate Personalized URL];
    E -- Redirect --> H[User Browser];
    H --> G;

4.2. Derivative: IoT Mesh Network Trigger and Action

Enabling Description: The system is implemented in an industrial IoT setting (e.g., a factory floor). A machine tool begins to vibrate outside of its normal operating parameters. A vibration sensor (an IoT device) detects this anomaly and broadcasts a "trigger" packet containing its own device ID and a vibration signature ID onto a local 6LoWPAN mesh network. A nearby gateway device (the "client") receives this packet. The gateway sends the IDs to a factory management server (the "ARS"). The ARS looks up the machine and vibration signature, and returns two redirects: one to the maintenance supervisor's tablet with a link to the machine's diagnostic page, and another to the machine tool's own control unit with a command to enter a safe, low-power state.

sequenceDiagram
    participant VibrationSensor
    participant Gateway
    participant FactoryServer (ARS)
    participant SupervisorTablet
    participant MachineController

    VibrationSensor-->>Gateway: Anomaly Packet (DeviceID, VibID)
    Gateway->>FactoryServer: GET /alert?dev=D1&vib=V5
    FactoryServer-->>Gateway: Redirect A: /diag/D1
    FactoryServer-->>Gateway: Redirect B: /cmd/D1/safe-mode
    Gateway->>SupervisorTablet: Push /diag/D1
    Gateway->>MachineController: Push /cmd/D1/safe-mode

4.3. Derivative: Blockchain-Verified Trigger for Royalty Distribution

Enabling Description: This derivative is used for media royalty tracking. Each piece of media (e.g., a song) is registered on a public blockchain, creating an immutable record with its unique identifier (an NFT or similar token). When the song is played by a registered broadcaster (e.g., a streaming service), the service's player emits an "audio signal" containing the song's blockchain identifier and a signed attestation from the broadcaster. A listener's client application detects this signal. The client sends the identifier to a "Royalty ARS." The ARS verifies the broadcaster's signature and confirms the identifier's validity on the blockchain. It then returns a URL to the user for song info, but more importantly, it triggers a smart contract associated with the song's identifier, which automatically distributes a micro-payment from the broadcaster's wallet to the artists' wallets.

flowchart LR
    A[Broadcaster Plays Song] --> B(Emits Blockchain ID + Signature);
    B --> C{User Client Detects Signal};
    C --> D[Royalty ARS];
    D --> E{Verify Signature & Blockchain ID};
    subgraph Blockchain
        F[Smart Contract]
        G[Artist Wallets]
    end
    E -- Triggers --> F;
    F -- Distributes Micropayment --> G;
    D -- Returns Song Info URL --> C;

---

5. Inverse, Failure Mode, and Low-Power Derivatives

5.1. Derivative: Graceful Degradation via Local Cache

Enabling Description: The client application is designed for network-unreliable environments. It maintains a local, periodically updated SQLite database that acts as a lightweight cache of the ARS. This cache maps the most common or most recent identifiers to a locally stored, static HTML page containing essential information (e.g., an advertiser's phone number and address, but not their full interactive website). When the client software decodes an identifier from an audio signal, it first attempts to connect to the primary ARS. If the connection times out or fails, the software automatically queries the local SQLite database for the identifier. If a match is found, it loads the corresponding static page in the browser, providing a degraded but still functional user experience.

flowchart TD
    A[Identifier Decoded] --> B{Attempt Network Connection to ARS};
    B -- Success --> C[Fetch Redirect from ARS];
    B -- Failure/Timeout --> D{Query Local SQLite Cache};
    D -- Match Found --> E[Display Static Local HTML Page];
    D -- No Match --> F[Display Generic 'Network Error' Message];
    C --> G[Load Full Web Content];

5.2. Derivative: User-Initiated, Privacy-Preserving Mode

Enabling Description: The system includes a user-configurable "privacy mode." When this mode is enabled, the client software's behavior changes. Upon detecting and decoding an identifier from an audio signal, the software does not automatically launch the browser or make any network connection. Instead, it performs a lookup in a local database to find the name of the entity associated with the identifier (e.g., "Coca-Cola"). It then generates a non-intrusive OS-level notification (e.g., a toast notification on Android or a notification banner on iOS) that reads, "Interaction available from Coca-Cola. Tap to proceed." Only if the user explicitly taps this notification will the software initiate the network connection to the ARS. This requires affirmative user consent for every interaction, preventing passive tracking.

sequenceDiagram
    participant System
    participant User
    participant ARS

    System->>System: Decodes Identifier 'CC-123'
    System->>System: Local DB Lookup: 'CC-123' -> 'Coca-Cola'
    System->>User: Display Notification: "Interact with Coca-Cola?"
    User->>System: Taps Notification (Consent)
    System->>ARS: GET /lookup?id=CC-123
    ARS-->>System: Redirect to Coca-Cola Website

---

6. Combination with Open-Source Standards

6.1. Combination: DVB/ATSC Metadata Stream Integration

Enabling Description: The '106 method is combined with the DVB (Digital Video Broadcasting) or ATSC (Advanced Television Systems Committee) open standards. The trigger and identifier are not embedded in the analog audio track. Instead, they are encoded as a data object within the Event Information Table (EIT) or a private data stream within the MPEG-2 transport stream. A standard-compliant smart TV or set-top box ("client device") continuously parses this metadata. When it encounters the predefined data object, the device's resident operating system extracts the identifier, constructs the URL for the ARS, and launches its native web browser to initiate the lookup and redirection process, displaying the final content either full-screen or in a picture-in-picture overlay.

6.2. Combination: DNS TXT/SVCB Record for ARS Lookup

Enabling Description: The system leverages the existing, open-standard Domain Name System (DNS) to replace the proprietary ARS application server. The identifier extracted from the broadcast signal (e.g., A4B7) is prepended to a known domain, forming a fully qualified domain name like A4B7.trigger.net. The client device performs a DNS query for a specific record type—either a TXT record or an HTTPS/SVCB service binding record—associated with this FQDN. The DNS response itself contains the final destination URL (e.g., "v=redir1 url=https://advertiser.com/promo/a4b7"). The client software parses this DNS record and directs the browser to the extracted URL. This offloads the redirection logic to globally distributed, highly resilient DNS infrastructure.

6.3. Combination: Bluetooth Beacon Eddystone-URL Standard

Enabling Description: The invention is combined with Google's open Eddystone-URL Bluetooth beacon standard. However, instead of broadcasting the final advertiser URL directly, the beacon is configured to broadcast a compressed URL pointing to the ARS and including the product identifier. For example, it broadcasts https://ars.co/[identifier]. A user's smartphone with BLE scanning enabled detects this beacon and offers to open the URL. When the user accepts, the phone's browser makes a request to the ARS. The ARS receives the request, performs its database lookup based on the identifier, and returns the 302 redirect to the final, full-featured advertiser URL. This combines the proximity-triggering of an open standard with the centralized, dynamic link management of the '106 patent's method.