US 7679637

US Patent 7,679,637, titled "Time-shifted web conferencing," was granted to Jeffrey Alan Kohler, who was the original assignee. The current assignee is US Patent 7,679,637 LLC. The patent was filed on October 5, 2007, and issued on March 16, 2010.

Abstract:
The patent describes a web conferencing system with time-shifting capabilities. This system allows participants to observe a session in real-time, delayed while the session is still in progress, or after it has completed. Participants can also view the session at different playback rates while maintaining substantially consistent perceived audio quality.

Plain-language Overview of Independent Claims:

• Claim 1 (Method of presenting audio data): This claim describes a method where a presenting participant shares audio data, which is recorded by a storage means. An observing participant can then listen to this audio data via an output means. Crucially, an interface means allows the observing participant to pause, resume, seek, and adjust the playback rate of the audio data. A time-scale modification means ensures that the perceived audio quality remains substantially consistent across different playback rates. The core aspect is that the observing participant can interact with the audio data (live or previously recorded) with time-shifting controls and consistent audio quality, even while the presenting participant is still sharing.

• Claim 2 (Web conferencing system): This claim defines a web conferencing system that includes a first client application for a presenting participant to share computer screen video and other data streams (e.g., chat, documents, web pages, white-boarding sessions). A storage means records this content. A second client application allows an observing participant to view the computer screen video and data streams live, or to selectively view a previously presented and recorded part of this content while the presenting participant is still sharing a current part, or after the presentation has concluded. The system is designed to simultaneously record and allow observation of current and past content.

• Claim 7 (Web conferencing system with audio and video): This claim outlines a web conferencing system comprising a first client application for a presenting participant to share audio and computer screen video data streams, and a second client application for an observing participant to view these streams. A server application receives and records the data streams in a storage device and retrieves them to send to the second client application. A time-scale modification component, connected to the second client application, maintains substantially consistent perceived audio quality at various playback rates. This enables simultaneous recording and retrieval of data streams, allowing the observing participant to view in real-time, or selectively view a previously presented and recorded part of the data streams at different playback rates while the presentation is ongoing or after it has stopped, all with consistent audio quality.

Litigation Information:
US Patent 7,679,637 has been the subject of litigation in the United States Court of Appeals for the Federal Circuit (CAFC) in a case titled US Patent No. 7,679,637 LLC v. Google LLC, Case: 24-1520. On January 22, 2026, the Federal Circuit affirmed a district court's order granting Google LLC's motion to dismiss for failure to state a claim upon which relief can be granted. The appeal concerned the patent eligibility of the asserted claims under 35 U.S.C. § 101.

The Federal Circuit agreed with the district court that the asserted claims were directed to the abstract idea of "allowing asynchronous review of presentations" as a live web conference progresses. The court found that the claims described the results of time-shifting web conferencing rather than providing specific technological improvements or novel techniques to achieve these functions. The court noted that the features, such as client applications, data streams, and the audio time-scale modification component, were described in generic terms and relied on conventional technology, which was acknowledged in the patent's own description. The Federal Circuit's opinion reinforces that patent eligibility for software and web-based patents requires claims to describe how a desirable result is achieved in a novel and non-obvious way, beyond simply applying known techniques to a new context. An en banc review was requested to clarify guidelines for Alice Step One, arguing the panel's abstract idea was an "impermissibly high level of generality," but the outcome of this request is not available in the provided search results.

Known litigation involving US patent 7679637:

Case 1: US Patent No. 7,679,637 LLC v. Google LLC

• Plaintiff(s): US Patent No. 7,679,637 LLC
• Defendant(s): Google LLC
• Jurisdiction: United States District Court for the Western District of Washington (original dismissal) and United States Court of Appeals for the Federal Circuit (appeal)
• Case Number: 24-1520 (Federal Circuit)
• Filing Date: The initial district court filing date is not explicitly provided in the snippets, but the Federal Circuit's opinion was issued on January 22, 2026.
• Outcome/Current Status: The Federal Circuit, on January 22, 2026, affirmed the district court's order granting Google LLC's motion to dismiss for failure to state a claim upon which relief can be granted. The asserted claims were found to be patent-ineligible under 35 U.S.C. § 101, as they were directed to the abstract idea of "allowing asynchronous review of presentations" and lacked an inventive concept. The district court had denied leave to amend the complaint, finding it futile, and the Federal Circuit also affirmed this decision.

Proceedings overview

There are no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method) on file for US Patent 7,679,637 according to the USPTO ODP API and supplementary web searches. This means all claims of the patent are currently untested by PTAB proceedings.

Strategic summary

As of today, July 10, 2026, all claims of US Patent 7,679,637 (claims 1-9) remain untested by any AIA trial proceeding at the Patent Trial and Appeal Board. The patent has not been subjected to IPR, PGR, or CBM challenges. This means there is no estoppel landscape established by the PTAB for this patent, and all prior art grounds remain available for potential challenges. The absence of PTAB activity, particularly for a patent that has been involved in Federal Circuit litigation concerning patent eligibility under 35 U.S.C. § 101, is notable.

Recommended next steps

Since there is no PTAB activity on file for US Patent 7,679,637, the recommended next step for a defendant facing assertion of this patent would be to conduct a thorough prior art search to assess the patentability of the claims under 35 U.S.C. §§ 102 and 103. Given the Federal Circuit's affirmation of the patent's ineligibility under § 101, a re-evaluation of potential § 101 challenges in other jurisdictions or contexts could also be considered, though this is distinct from PTAB's validity review. The absence of PTAB challenges means that, if a defendant decides to pursue an IPR, PGR, or CBM, they would be the first to do so, and would not face estoppel based on previous PTAB decisions on this patent.

Proceedings overview

There are no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method) on file for US Patent 7,679,637 according to the USPTO ODP API and supplementary web searches. This means all claims of the patent are currently untested by PTAB proceedings.

Strategic summary

As of today, July 10, 2026, all claims of US Patent 7,679,637 (claims 1-9) remain untested by any AIA trial proceeding at the Patent Trial and Appeal Board. The patent has not been subjected to IPR, PGR, or CBM challenges. This means there is no estoppel landscape established by the PTAB for this patent, and all prior art grounds remain available for potential challenges. The absence of PTAB activity, particularly for a patent that has been involved in Federal Circuit litigation concerning patent eligibility under 35 U.S.C. § 101, is notable.

Recommended next steps

Since there is no PTAB activity on file for US Patent 7,679,637, the recommended next step for a defendant facing assertion of this patent would be to conduct a thorough prior art search to assess the patentability of the claims under 35 U.S.C. §§ 102 and 103. Given the Federal Circuit's affirmation of the patent's ineligibility under § 101, a re-evaluation of potential § 101 challenges in other jurisdictions or contexts could also be considered, though this is distinct from PTAB's validity review. The absence of PTAB challenges means that, if a defendant decides to pursue an IPR, PGR, or CBM, they would be the first to do so, and would not face estoppel based on previous PTAB decisions on this patent.

Inventors

Jeffrey Alan Kohler is the sole named inventor on US Patent 7,679,637. The patent indicates that the original assignee was "Individual," implying Jeffrey Alan Kohler himself was the owner at the time of filing. No employer at the time of filing is explicitly stated.

Original assignee

The original assignee was Jeffrey Alan Kohler, an individual inventor. It is not determinable from the patent record whether he shipped a product embodying the claims, nor is his primary line of business as an individual inventor specified. His current status, as an individual patent owner, is that he assigned the patent to US Patent 7,679,637 LLC in March 2023.

Assignment timeline

• 2023-03-19 (executed) / recorded 2023-03-31 — Reel 063193/0213
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: KOHLER, JEFF
  • Assignee: US PATENT 7,679,637 LLC
  • Correspondent: WESLEY W. HORTON; Horten Lee, P.C.; 1770 St. James Place, Suite 230, Houston, TX 77056.
  • Context: Transfer from individual inventor to an LLC, likely for the purpose of patent assertion.

Timeline diagram

timeline
    title Ownership of US 7679637
    2007 : Filed by Jeffrey Alan Kohler
    2010 : Issued to Jeffrey Alan Kohler
    2023 : Assigned to US Patent 7,679,637 LLC

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was transferred from an individual inventor (Jeffrey Alan Kohler) to "US PATENT 7,679,637 LLC" (Reel 063193/0213, recorded 2023-03-31). The assignee's name, explicitly containing "Patent" and "LLC," is a strong indicator of a licensing-only or assertion entity.

2. Known asserter in the chain — Unclear. While "US Patent 7,679,637 LLC" has initiated litigation against Google LLC regarding this patent, it is not explicitly identified as a high-frequency plaintiff on commonly recognized NPE lists from the provided data. Its status as a "known asserter" across multiple patents or jurisdictions is not directly confirmed here.

3. Repeat correspondent across the chain — Not present. There is only one recorded assignment in this chain, so no recurrence of a correspondent can be observed for this patent. The correspondent for the sole assignment is WESLEY W. HORTON of Horten Lee, P.C.

4. Cascading transfers — Not present. Only a single transfer from the inventor to the LLC is recorded (Reel 063193/0213, recorded 2023-03-31).

5. Pre-litigation transfer — Present. The assignment to US Patent 7,679,637 LLC was executed on March 19, 2023, and recorded on March 31, 2023 (Reel 063193/0213). Litigation against Google LLC in the Washington Western District Court (case 2:23-cv-00592) was filed in 2023, indicating this transfer occurred within months of, or in close proximity to, the initiation of the lawsuit.

6. Bankruptcy fire-sale — Not present. The assignor was an individual inventor, not a company undergoing bankruptcy proceedings.

7. Privateering — Not present. There is no information in the patent record or associated legal events to suggest that an operating company transferred this patent to an NPE to assert on its behalf.

8. Defensive aggregator (anti-NPE) — Not present. The patent was assigned to "US Patent 7,679,637 LLC", which is not a defensive aggregator.

Verdict

NPE — high confidence

The presence of two strong NPE signals—a transfer to a shell entity named "US PATENT 7,679,637 LLC" (Reel 063193/0213, recorded 2023-03-31) and this transfer occurring as a pre-litigation maneuver immediately preceding the filing of an infringement lawsuit against Google LLC—establishes a high confidence that this is an NPE assertion. The Federal Circuit's decision affirming patent ineligibility further reinforces that the current assignee's primary activity related to this patent is assertion rather than product development.

Verification Link: https://assignmentcenter.uspto.gov/patent/index.html?qs=7679637

To identify the most relevant prior art for US Patent 7,679,637 and assess potential anticipation under 35 U.S.C. § 102, we will review the patents cited by the examiner, as listed in the patent document.

Here are the patent citations and an analysis of their potential relevance:

1. US6278387B1

• Full Citation: US6278387B1, "Audio encoder and decoder utilizing time scaling for variable playback"
• Publication/Filing Date: Publication Date: 2001-08-21; Priority Date: 1999-09-28
• Brief Description: This patent describes an audio encoder and decoder system that enables variable speed playback of audio signals while maintaining the original pitch. It uses time-scaling techniques to achieve this.
• Potential Anticipation (35 U.S.C. § 102): This patent is highly relevant to the audio time-scaling aspect of US7679637.
  • Claim 1: Directly anticipates the "time-scale modification means which is able to maintain substantially consistent perceived audio quality at a plurality of playback rates" (claim 1(f)) and the manipulation of audio data with such means (claim 1(h)). The core idea of pitch-preserving variable speed audio playback is disclosed.
  • Claim 4: Anticipates the "audio time-scale modification component" and its function of maintaining "substantially consistent perceived aspects of audio quality at a plurality of chosen playback rates of speed" in a web conferencing system that allows adjustable playback rate for audio data.
  • Claim 7: Anticipates the "time-scale modification component" (claim 7(d)) for audio data streams in a web conferencing system for similar reasons as Claim 1 and 4.

2. US6298129B1

• Full Citation: US6298129B1, "Teleconference recording and playback system and associated method"
• Publication/Filing Date: Publication Date: 2001-10-02; Priority Date: 1998-03-11
• Brief Description: This patent describes a system and method for recording teleconferences and allowing playback of the recorded content. It focuses on the general concept of storing and retrieving teleconference data.
• Potential Anticipation (35 U.S.C. § 102): This patent broadly covers the recording and playback of conference content.
  • Claim 2: Potentially anticipates the "storage means for recording said computer screen video and said data stream" (claim 2(c)) and the general idea of allowing an observing participant to "sense a previously presented and recorded part" of the content (claim 2(e) and 2(f)). However, it may not explicitly teach the "while said presenting participant is sharing a current part" aspect or the comprehensive types of data streams.
  • Claim 7: Similar to Claim 2, it potentially anticipates the "server application arranged to: i. receive said data streams from said first client application and record it in a storage device ii. retrieve said data streams from said storage device and send it to said second client application" (claim 7(c)(i) and 7(c)(ii)) in a general conferencing context.

3. US20020165721A1

• Full Citation: US20020165721A1, "Real-time control of playback rates in presentations"
• Publication/Filing Date: Publication Date: 2002-11-07; Priority Date: 2001-05-04
• Brief Description: This application describes systems and methods for controlling the playback rate of presentations in real-time, allowing users to speed up or slow down content.
• Potential Anticipation (35 U.S.C. § 102): This reference is directly pertinent to variable playback rates in presentations.
  • Claim 1: Potentially anticipates the "adjust the playback rate of said audio data" (claim 1(e)(ii)) and the retrieval and manipulation of audio data in accordance with these instructions (claim 1(g), 1(h)). The system's ability to "selectively listen to a previously presented and recorded part of said audio data at a plurality of playback rates" (claim 1 preamble) is strongly suggested. The distinguishing feature for 7679637 might be the explicit "substantially consistent perceived audio quality" with time-scale modification, though "real-time control of playback rates" implies some level of quality preservation.
  • Claim 4: Directly anticipates the feature of allowing a participant to observe content at an adjustable rate of speed in a conferencing context.
  • Claim 7: Anticipates the ability of the "second client application also allows said observing participant to selectively sense a previously presented and recorded part of said data streams at a plurality of playback rates."

4. US6847778B1

• Full Citation: US6847778B1, "Multimedia visual progress indication system"
• Publication/Filing Date: Publication Date: 2005-01-25; Priority Date: 1999-03-30
• Brief Description: This patent describes a system, such as a DVR (e.g., TiVo), for time-shifting television content, allowing pausing, rewinding, and fast-forwarding live broadcasts.
• Potential Anticipation (35 U.S.C. § 102): This patent discloses core time-shifting functionality in the context of live media.
  • Claim 1: Anticipates the "pause, resume, and seek said audio data" (claim 1(e)(i)) functionality, applied to live content that is simultaneously recorded and retrieved, allowing "selectively listen to said audio data live and allowing said observing participant to selectively listen to a previously presented and recorded part of said audio data."
  • Claim 5: Anticipates the "time-shifting operations comprising pausing, resuming and seeking."
  • Claim 9: Similar to Claim 5, it anticipates the "time-shifting operations comprising pausing, resuming and seeking said data streams." The key distinguishing element for US7679637 would be its specific application to "web conferencing" and the interaction between presenting and observing participants, which might not be fully disclosed in a general DVR system.

5. US6906741B2

• Full Citation: US6906741B2, "System for and method of conferencing with a handheld computer using multiple media types"
• Publication/Filing Date: Publication Date: 2005-06-14; Priority Date: 2002-01-29
• Brief Description: This patent describes a conferencing system capable of handling multiple media types (e.g., audio, video, chat) on a handheld computer.
• Potential Anticipation (35 U.S.C. § 102): This patent is relevant for web conferencing systems handling multiple media types.
  • Claim 2: Potentially anticipates a "first client application allowing at least one presenting participant to share computer screen video," and other "data stream selected from the group consisting of chat data, documents, web pages and white-boarding session" (claim 2(a) and 2(b)), and a "second client application allowing at least one observing participant to sense said computer screen video and said data stream live" (claim 2(d)). The novelty of US7679637 would hinge on the time-shifting aspects (e.g., observing recorded parts while the session is live).
  • Claim 7 & 8: Similar to Claim 2, it anticipates sharing and sensing data streams, including audio, computer screen video, and other data like chat/documents/web pages/white-boarding sessions, in a conferencing system.

6. US6967599B2

• Full Citation: US6967599B2, "Method of reproducing audio signals without causing tone variation in fast or slow playback mode and reproducing apparatus for the same"
• Publication/Filing Date: Publication Date: 2005-11-22; Priority Date: 2000-12-19
• Brief Description: This patent describes a method and apparatus for playing back audio at variable speeds without changing the pitch or tone, essentially a pitch-preserving time-scaling of audio signals.
• Potential Anticipation (35 U.S.C. § 102): Very similar to US6278387B1, this patent directly addresses pitch-preserving time-scale modification for audio.
  • Claim 1: Directly anticipates the "time-scale modification means which is able to maintain substantially consistent perceived audio quality at a plurality of playback rates" (claim 1(f)) and the manipulation of audio data with such means (claim 1(h)).
  • Claim 4: Anticipates the "audio time-scale modification component" and its function of maintaining "substantially consistent perceived aspects of audio quality at a plurality of chosen playback rates of speed" in a system that allows adjustable playback rate for audio data.
  • Claim 7: Anticipates the "time-scale modification component" (claim 7(d)) for audio data streams for similar reasons as Claims 1 and 4.

7. US20060146124A1

• Full Citation: US20060146124A1, "Video conference recorder"
• Publication/Filing Date: Publication Date: 2006-07-06; Priority Date: 2004-12-17
• Brief Description: This application describes a video conference recording system that can record various streams (video, audio, text chat) and allow for their later playback.
• Potential Anticipation (35 U.S.C. § 102): This reference explicitly focuses on recording video conferences.
  • Claim 2: Potentially anticipates the "storage means for recording said computer screen video and said data stream" (claim 2(c)) and the ability to "selectively sense a previously presented and recorded part" of the content (claim 2(e) and 2(f)) in a web conferencing context. Again, the specific "while said presenting participant is sharing a current part" and the time-shifting interactivity in real-time remain key differentiating factors for US7679637.
  • Claim 7 & 8: Similar to Claim 2, it anticipates the recording and retrieval of data streams including audio, computer screen video, and other data (chat).

8. US20080247730A1

• Full Citation: US20080247730A1, "System and method for internet access to a personal television service"
• Publication/Filing Date: Publication Date: 2008-10-09; Priority Date: 2000-03-02
• Brief Description: This application describes a system for providing internet access to personal television services, including time-shifting capabilities for broadcast content. It is a broader application of DVR-like functionality.
• Potential Anticipation (35 U.S.C. § 102): This broadens the time-shifting concept to internet-delivered content, similar to a DVR.
  • Claim 1, 5, 9: Similar to US6847778B1, it anticipates the core time-shifting functions (pause, resume, seek) for media content accessed via the internet. The distinguishing factor for US7679637 is its application to interactive "web conferencing" with simultaneous live sharing and time-shifted observation, which is distinct from consuming a broadcast TV service.

9. US7466334B1

• Full Citation: US7466334B1, "Method and system for recording and indexing audio and video conference calls allowing topic-based notification and navigation of recordings"
• Publication/Filing Date: Publication Date: 2008-12-16; Priority Date: 2002-09-17
• Brief Description: This patent describes a system for recording, indexing, and navigating audio and video conference calls, with features like topic-based notifications and navigation within the recordings.
• Potential Anticipation (35 U.S.C. § 102): This patent is directly related to recording and navigating conference calls.
  • Claim 2, 3, 7, 8: Potentially anticipates the "storage means for recording" (claim 2(c), 3(b), 7(c)(i)) and the ability to "sense a previously presented and recorded part" of the content (claim 2(e), 2(f), 7 preamble) in a conference call setting. The indexing and navigation features described in US7466334B1 could be considered a form of "seeking" which is mentioned in US7679637's claims 1, 5, and 9. However, the unique aspect of US7679637 is the simultaneous live presentation and time-shifted observation while the session is still in progress, which this patent primarily addresses for after the recording.

Summary of Most Relevant Prior Art

The most relevant prior art documents for US7679637, particularly concerning direct anticipation under 35 U.S.C. § 102, are those that address time-scale modification of audio and recording/playback in conferencing or live media environments:

• US6278387B1 and US6967599B2 are highly relevant to Claims 1, 4, and 7 due to their disclosure of pitch-preserving time-scale modification for audio. This is a critical component for maintaining audio quality at varying playback rates, a feature explicitly claimed in US7679637.
• US20020165721A1 is highly relevant to Claims 1, 4, and 7 for its disclosure of real-time control of playback rates in presentations.
• US6847778B1 (TiVo patent) is highly relevant to Claims 1, 5, and 9 for its disclosure of core time-shifting functionalities (pause, resume, seek) in a live media context.
• US7466334B1 and US20060146124A1 are relevant to Claims 2, 3, 7, and 8 for their general disclosure of recording and playing back conference content. The novelty for US7679637 often lies in the real-time, in-progress time-shifting capabilities beyond simple post-session recording playback.

Obviousness Analysis of US Patent 7,679,637 Under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the independent claims of US Patent 7,679,637 obvious to a person having ordinary skill in the art (POSA) as of the priority date (October 28, 2006).

A POSA in the field of web conferencing and multimedia systems would have knowledge of streaming media technologies, network protocols, audio/video processing, and user interface design for interactive applications. They would be familiar with the concepts of time-shifting media content, recording and playback systems, and techniques for modifying audio time-scale while preserving quality.

Independent Claim 1: Method of presenting audio data in a web conference

Claim 1 Elements:
(a) providing an input means which allows at least one presenting participant to share audio data,
(b) providing a storage means which is able to record said audio data and is operatively connected to said input means,
(c) recording said audio data with said storage means,
(d) providing an output means which is operatively connected to said storage means and allows at least one observing participant to listen to said audio data,
(e) providing an interface means which can receive instructions and which allows said observing participant to:
i. pause, resume, and seek said audio data, and
ii. adjust the playback rate of said audio data,
(f) providing a time-scale modification means which is able to maintain substantially consistent perceived audio quality at a plurality of playback rates,
(g) retrieving said audio data from said storage means in accordance with said instructions given to said interface means,
(h) manipulating said audio data with said time-scale modification means in accordance with said instructions given to said interface means,
(i) providing said audio data to said observing participant with said output means,
whereby said observing participant can provide said instructions to said interface means at the same time that said presenting participant is sharing said audio data, and said audio data from said presenting participant can be simultaneously recorded by and retrieved from said storage means, allowing said observing participant to selectively listen to said audio data live and allowing said observing participant to selectively listen to a previously presented and recorded part of said audio data at a plurality of playback rates at the same time that said presenting participant is sharing said audio data, and said observing participant will perceive substantially consistent audio quality.

Combination 1: US6847778B1 (TiVo) in view of US6278387B1 or US6967599B2, and US6906741B2 or US7466334B1

• Primary Reference: US6847778B1 (TiVo, "Multimedia visual progress indication system")
  • Teaches the core concept of time-shifting for live media (e.g., television), including simultaneously recording and playing back content, and providing an interface for pausing, resuming, and seeking (elements a-e(i), g, i, and the simultaneous recording/retrieval aspect). A POSA would understand that a "multimedia" system could encompass audio data. The "whereby" clause regarding observing live or previously recorded parts simultaneously with ongoing presentation is explicitly taught by the DVR functionality.
• Secondary Reference 1: US6278387B1 ("Audio encoder and decoder utilizing time scaling for variable playback") or US6967599B2 ("Method of reproducing audio signals without causing tone variation in fast or slow playback mode and reproducing apparatus for the same")
  • These references explicitly teach "time-scale modification means which is able to maintain substantially consistent perceived audio quality at a plurality of playback rates" and manipulating audio data with such means (elements f and h). Both describe playing audio at variable speeds without pitch distortion.
• Secondary Reference 2: US6906741B2 ("System for and method of conferencing with a handheld computer using multiple media types") or US7466334B1 ("Method and system for recording and indexing audio and video conference calls")
  • These references teach the context of a "web conference" and the sharing of "audio data" by a "presenting participant" and listening by an "observing participant" (elements a, d, and the overall web conference context). US7466334B1 specifically addresses recording and navigation of conference calls.

Motivation for Combination:
A POSA would have been motivated to combine the time-shifting capabilities of a DVR system (US6847778B1) with audio time-scale modification techniques (US6278387B1 or US6967599B2) and apply them to the established domain of web conferencing (US6906741B2 or US7466334B1) to address known problems. The patent itself highlights that "current web conferencing systems are unable to enable participants to asynchronously observe a live meeting" and that existing solutions like DVRs "have empowered consumers by allowing them to time-shift real-time television content."

The motivation for combining these would be clear: to improve the flexibility and user experience of web conferencing by allowing participants to:

1. Catch up on missed content: By integrating DVR-like time-shifting into a live web conference, participants joining late could immediately rewind and observe what they missed while the session was still in progress.
2. Manage interruptions: Pausing and resuming live content would allow participants to handle interruptions without missing crucial information.
3. Enhance comprehension: Adjusting playback speed, especially with pitch-preserving audio, would allow participants to review complex segments slowly or speed through less critical parts.

Applying known time-shifting controls from DVRs to web conferencing is a straightforward implementation given the shared characteristics of streaming media. Furthermore, it would be obvious to a POSA to integrate existing audio processing algorithms (time-scale modification) to ensure that variable speed playback does not distort the audio, as poor audio quality would degrade the user experience of a web conference. The references to conferencing systems (US6906741B2, US7466334B1) provide the specific context for applying these time-shifting and audio manipulation techniques.

Independent Claim 2: Web conferencing system

Claim 2 Elements:
(a) a first client application allowing at least one presenting participant to share computer screen video,
(b) said first client application also being arranged to allow said presenting participant to share at least one data stream selected from the group consisting of chat data, documents, web pages and white-boarding session,
(c) storage means for recording said computer screen video and said data stream, and
(d) a second client application allowing at least one observing participant to sense said computer screen video and said data stream live,
(e) said second client application also being arranged to allow said observing participant to selectively sense a previously presented and recorded part of said computer screen video and said data stream while said presenting participant is sharing a current part of said computer screen video and said data stream,
(f) said second client application also being arranged to allow said observing participant to selectively sense a previously presented and recorded part of said computer screen video and said data stream after said presenting participant has finished sharing a said computer screen video and, said data stream
whereby said web conferencing system is able to simultaneously record said computer screen video and said data stream and allow said observing participant to sense current and previously presented parts of said computer screen video and said data stream.

Combination 2: US7466334B1 or US20060146124A1 in view of US6847778B1 (TiVo)

• Primary Reference: US7466334B1 ("Method and system for recording and indexing audio and video conference calls") or US20060146124A1 ("Video conference recorder")
  • These references teach a web conferencing system with client applications for presenting and observing, capable of sharing and recording various data streams like video and other content (e.g., chat, documents). Specifically, US7466334B1 discusses recording audio and video conference calls with navigation of recordings, and US20060146124A1 describes a video conference recording system for various streams. These cover elements a, b, c, d, and f (observing recorded parts after the session).
• Secondary Reference: US6847778B1 (TiVo, "Multimedia visual progress indication system")
  • Teaches the concept of time-shifting live multimedia content, including the ability to simultaneously record and play back, allowing an observer to view previously recorded parts while the live event is still in progress (element e and the "whereby" clause related to simultaneous recording and sensing current/previously presented parts).

Motivation for Combination:
A POSA would have been motivated to combine a conventional web conferencing system with recording capabilities (US7466334B1 or US20060146124A1) with the time-shifting paradigm of a DVR (US6847778B1) to enhance the functionality of web conferences. The problem of participants joining late and missing content in real-time web conferences was known.

The motivation would be to:

1. Improve participant flexibility: Directly apply the widely popular DVR concept of "time-shifting" from television to live web conferences. This allows participants to watch from the beginning if they join late, or review earlier segments if they missed something, without waiting for the entire conference to conclude.
2. Maximize content value: Enable the recorded content to be accessible and interactive even while the live event is ongoing, increasing the immediate utility of the recording.
3. Meet user expectations: Consumers were already accustomed to time-shifting capabilities in other media (e.g., TiVo DVRs), leading to an expectation that similar functionality would be beneficial in web conferencing.

It would be obvious to a POSA to adapt the simultaneous recording and delayed playback mechanism of a DVR to the different data streams (screen video, chat, documents) present in a web conference. The technical challenges would involve adapting the streaming and storage mechanisms, but the underlying concept of maintaining a buffer of live content for delayed playback is directly transferable.

Independent Claim 7: Web conferencing system with audio and video

Claim 7 Elements:
(a) a first client application that allows at least one presenting participant to share data streams comprised of audio data and computer screen video data
(b) a second client application that allows at least one observing participant to sense said data streams
(c) a server application operatively connected to said first client application and to said second client application, said server application arranged to:
i. receive said data streams from said first client application and record it in a storage device
ii. retrieve said data streams from said storage device and send it to said second client application
(d) a time-scale modification component operatively connected to said second client application which is able to maintain substantially consistent perceived audio quality at a plurality of playback rates
whereby said data streams from said first client application can be simultaneously recorded by and retrieved from said storage device, and said second client application allows said observing participant to sense said data streams in real-time, and said second client application also allows said observing participant to selectively sense a previously presented and recorded part of said data streams at a plurality of playback rates at the same time that said presenting participant is sharing a current part of said data streams and after said presenting participant has stopped sharing, and said observing participant will perceive substantially consistent audio quality.

Combination 3: US7466334B1 or US20060146124A1 in view of US6847778B1 (TiVo) and US6278387B1 or US6967599B2

• Primary Reference: US7466334B1 ("Method and system for recording and indexing audio and video conference calls") or US20060146124A1 ("Video conference recorder")
  • These references teach a web conferencing system with client applications, a server, and storage for sharing and recording audio and video data streams (elements a, b, c(i), c(ii)). They describe the basic architecture for recording conference content.
• Secondary Reference 1: US6847778B1 (TiVo, "Multimedia visual progress indication system")
  • Teaches the concept of time-shifting live multimedia content, including simultaneous recording and playback, allowing an observer to view previously recorded parts while the live event is still in progress (the "whereby" clause regarding simultaneous recording and retrieval, sensing current/previously presented parts while presenting is ongoing, and after presenting has stopped).
• Secondary Reference 2: US6278387B1 ("Audio encoder and decoder utilizing time scaling for variable playback") or US6967599B2 ("Method of reproducing audio signals without causing tone variation in fast or slow playback mode and reproducing apparatus for the same")
  • These references explicitly teach "time-scale modification means which is able to maintain substantially consistent perceived audio quality at a plurality of playback rates" (element d and the audio quality aspect of the "whereby" clause).

Motivation for Combination:
The motivation for combining these references to achieve Claim 7 is a straightforward extension of the motivations for Claims 1 and 2. A POSA would seek to create a comprehensive time-shifted web conferencing system that handles both audio and video streams (taught by US7466334B1 or US20060146124A1). To integrate the time-shifting capabilities for live content (from US6847778B1) and ensure a high-quality user experience, especially with variable playback rates for audio, it would be obvious to incorporate known audio time-scale modification techniques (from US6278387B1 or US6967599B2).

The integration of these functionalities would address the identified drawbacks of existing real-time web conferencing systems, such as inflexibility for late joiners or those needing to review content, and the inability to adjust presentation speed without loss of audio fidelity. This combination simply applies known solutions for time-shifting and audio quality preservation to the well-understood problem space of improving live web conferencing. The resulting system would perform predictably based on the functions of the individual components.

For US Patent 7,679,637, here's a breakdown of its term adjustments, extensions, family members, and projected expiration:

Patent Term Adjustments (PTA) and Extensions (PTE):

• Patent Term Adjustment (PTA): The patent was granted a Patent Term Adjustment of 683 days. PTA is added to the standard 20-year patent term to compensate for delays caused by the USPTO during prosecution. It is calculated automatically at the time of grant.
• Patent Term Extension (PTE): There is no information in the provided patent text or search results to indicate that US Patent 7,679,637 has received a Patent Term Extension. PTEs are typically granted to compensate for delays in obtaining regulatory approval for certain patented products, such as pharmaceuticals, and require a separate application after product approval.

Continuation and Divisional Applications, and Related Family Members:

• Priority Applications: US Patent 7,679,637 claims the benefit of provisional patent application Ser. No. 60/855,076, filed on October 28, 2006. The non-provisional application number is US11/973,219, filed on October 5, 2007, which matured into US7679637B1.
• Continuation/Divisional Applications: The provided information does not explicitly list any continuation or divisional applications for US Patent 7,679,637.
• Family Members: The patent family (ID=41819530) lists only one application: US11/973,219, which is US7679637B1 itself.

Projected Expiration Date:

• The statutory patent term for applications filed on or after June 8, 1995, is 20 years from the earliest effective filing date of the application. The priority date for US7679637 is October 28, 2006.
• Therefore, the unadjusted expiration date would be October 28, 2026.
• With the 683 days of Patent Term Adjustment, the adjusted expiration date is December 26, 2027. This information is directly stated in the Google Patents record under "Legal status," which shows "Active, expires 2027-12-26".

Defensive Disclosure: Time-Shifted Web Conferencing Derivatives (US7679637)

This document outlines derivative variations of the inventions described in US Patent 7,679,637. The intent of this defensive disclosure is to establish prior art for potential future incremental improvements by competitors, thereby rendering such improvements obvious or non-novel. The derivatives are structured around the independent claims of US7679637, focusing on Claim 1 (Method of presenting audio data), Claim 2 (Web conferencing system), and Claim 7 (Web conferencing system with audio and video). The current date of this disclosure is April 26, 2026.

---

Derivatives for Independent Claim 1: Method of presenting audio data in a web conference

Claim 1 Preamble Summary: A method of presenting audio data in a web conference, including sharing, recording, output, interface for time-shifting (pause, resume, seek, adjust playback rate), time-scale modification for consistent audio quality, and retrieving/manipulating/providing audio data. The "whereby" clauses emphasize simultaneous recording/retrieval, selective listening live or recorded, at variable playback rates with consistent audio quality while the presenting participant is still sharing.

---

1.1. Material & Component Substitution: Distributed P2P Audio Processing with WebAssembly and Custom Codecs

Enabling Description:
This derivative implements the audio data time-shifting and quality preservation entirely within a peer-to-peer (P2P) network topology, eliminating a central server for audio stream storage and manipulation. Presenting participants' client applications capture audio data, which is then encoded using a highly efficient, low-latency, open-source audio codec such as Opus configured for variable bitrate (VBR) streaming. Instead of a central storage means, each presenting client multicasts or broadcasts encrypted audio data segments (frames) directly to observing clients within the session via WebRTC data channels or a custom UDP-based protocol. Each observing client's browser-based application, incorporating a WebAssembly (Wasm) module, acts as the "storage means" by maintaining a local, ring-buffer cache of recent audio frames. The Wasm module also contains the "time-scale modification means," implemented using a custom pitch-synchronous overlap-add (PSOLA) algorithm, directly processing the Opus-decoded audio samples. The client-side interface (HTML5/JavaScript) allows local pause, resume, seek, and playback rate adjustments. Retrieval of "previously presented and recorded parts" involves fetching from the local client-side buffer. If a client joins late or seeks beyond its local buffer, a temporary, on-demand P2P request is initiated to a peer client with a more complete cache or, as a fallback, a minimal archival server. Audio output occurs via the Web Audio API.

graph TD
    P[Presenting Client A] -- Encoded Opus Audio --> O1[Observing Client 1 (Wasm)]
    P -- Encoded Opus Audio --> O2[Observing Client 2 (Wasm)]
    P -- Encoded Opus Audio --> O_N[Observing Client N (Wasm)]
    O1 -- WebRTC Data Channel/UDP --> O2
    O_N -- WebRTC Data Channel/UDP --> O1
    O1 -- Local Cache Request --> O1_Buffer[Ring Buffer Cache]
    O1_Buffer -- Decompress & PSOLA --> O1_Output[Web Audio API]
    O1_UI[UI (HTML5/JS)] -- Instructions --> O1_Wasm[Wasm Module (Time-Scale Mod)]
    O1_Wasm -- Playback Control --> O1_Buffer
    subgraph Observing Client Architecture
        O1_Wasm
        O1_Buffer
        O1_Output
        O1_UI
    end

---

1.2. Operational Parameter Expansion: Ultra-Low Latency, High-Frequency Audio Analysis with Adaptive Playback for Critical Control Environments

Enabling Description:
This derivative targets critical control environments requiring sub-10ms audio latency and the ability to analyze high-frequency acoustic data (e.g., machinery diagnostics, medical sonography feedback). The system operates with a base audio sampling rate of 192 kHz (e.g., for industrial ultrasonic monitoring) and a bit depth of 24-bit. The "input means" utilizes specialized transducers and high-resolution ADCs. Audio data is streamed using a custom, uncompressed, or perceptually lossless codec (e.g., FLAC or uncompressed PCM over a dedicated, low-latency gigabit Ethernet link or 5G private network). The "storage means" is an in-memory, distributed, persistent queue optimized for real-time append/read operations (e.g., Apache Kafka with NVMe-backed storage). The "interface means" includes haptic feedback controls and a graphical spectral analysis display, allowing observing participants to adjust playback rates from 0.05x (extreme slow-motion for detailed artifact inspection) to 10x (rapid scan for overview) while meticulously preserving acoustic fidelity across the entire frequency spectrum. The "time-scale modification means" is implemented via a GPU-accelerated phase vocoder, capable of real-time processing of high-frequency audio without spectral smearing, and dynamically adjusting its window size and hop factor based on the requested playback rate and signal characteristics to maintain transient preservation. The "output means" drives specialized headphones or speakers with a flat frequency response up to 96 kHz. The system incorporates predictive buffering and adaptive bitrate streaming to maintain the ultra-low latency requirement, dynamically re-negotiating QoS parameters.

graph TD
    A[High-Res ADCs/Transducers] -- 192kHz/24bit Audio --> P[Presenting Module]
    P -- Dedicated Low-Latency Network --> KQ[Kafka Distributed Queue (In-Memory)]
    KQ -- Real-time Stream --> O[Observing Client (GPU-Accelerated)]
    O -- GPU Phase Vocoder --> H[High-Fidelity Haptic/Spectral Display & Audio Output]
    UI[Interface: Haptic/Spectral Controls] -- Playback Instructions --> O
    Haptic[Haptic Feedback] -- Enhanced Perception --> UI
    subgraph Observing Module
        O
        H
        UI
    end
    subgraph Data Flow
        P -- Store --> KQ
        KQ -- Retrieve --> O
    end

---

1.3. Cross-Domain Application 1: Remote Surgical Training & Review

Enabling Description:
In remote surgical training, the "presenting participant" is a lead surgeon, and the "audio data" includes their verbal instructions, physiological sounds from the patient (e.g., heart monitor beeps, suction noises), and instrument sounds (e.g., drill, cautery). The "input means" consists of integrated microphones in the surgical suite and direct feeds from medical monitoring equipment. The "storage means" securely records all audio streams to a HIPAA-compliant cloud storage with immutable logging. "Observing participants" are medical residents or remote specialists. The "interface means" on their training workstations allows them to rewind to specific surgical steps, pause during complex maneuvers, and adjust playback speed (e.g., 0.5x for detailed auditory analysis of tissue manipulation, 2.0x to review routine steps). The "time-scale modification means" ensures that crucial auditory cues (e.g., changes in instrument pitch indicating resistance, specific beeps from monitors) retain their characteristic quality, even at altered speeds, using advanced spectral preservation algorithms. This enables asynchronous, yet high-fidelity, review of live or recorded procedures.

sequenceDiagram
    participant Surgeon as Presenting Surgeon
    participant Mon as Medical Monitors
    participant Input as Audio Input Means
    participant Storage as HIPAA Cloud Storage
    participant Res as Observing Resident
    participant UI as Resident Workstation UI
    participant TSMod as Time-Scale Mod Module

    Surgeon->>Input: Verbal Instructions
    Mon->>Input: Physiological/Instrument Sounds
    Input->>Storage: Encrypted Audio Streams
    Storage->>Res: Retrieve Stream (on instruction)
    Res->>UI: View Live/Recorded Session
    UI->>TSMod: Playback Instructions (Pause, Seek, Rate)
    TSMod->>Res: Manipulated Audio Data
    Res->>Res: Listen with Consistent Quality
    Note over Res,Storage: Simultaneous Record & Retrieve

---

1.4. Cross-Domain Application 2: Smart Agriculture - Livestock Monitoring

Enabling Description:
In smart agriculture, the "presenting participant" is an automated acoustic monitoring system deployed in a livestock enclosure. The "audio data" comprises animal vocalizations (e.g., distress calls, feeding sounds, mating calls), environmental sounds, and sounds from automated feeding/watering systems. The "input means" are robust, weatherized acoustic sensor arrays. The "storage means" is a ruggedized edge device with secure, redundant storage, periodically syncing to a central farm management cloud. "Observing participants" are veterinarians or farm managers. The "interface means" on their mobile or desktop devices allows them to review detected anomalies. For instance, if an AI system flags a potential distress event, the manager can instantly "seek" to the event's start, "pause" to analyze a specific vocalization, and "adjust the playback rate" (e.g., 0.25x to discern subtle nuances in animal calls, 4.0x to quickly scan background ambient noise) without distorting the acoustic characteristics that are vital for diagnosis. The "time-scale modification means" is critical for preserving the unique spectral and temporal features of animal sounds at variable speeds.

graph TD
    A[Acoustic Sensor Array (Input)] --> E[Ruggedized Edge Device (Storage)]
    E --> C[Farm Management Cloud]
    AI[AI Anomaly Detection] --> E
    E -- Anomaly Alert --> V[Veterinarian/Farm Manager (Observing)]
    V --> UI[Mobile/Desktop UI (Interface)]
    UI -- Playback Controls --> V_Client[Client Application]
    V_Client -- Request Audio --> E
    E -- Retrieved Audio --> V_Client
    V_Client -- Time-Scale Mod --> Output[Audio Output]
    subgraph Client-Side
        UI
        V_Client
        Output
    end

---

1.5. Cross-Domain Application 3: Maritime Sonar Data Analysis

Enabling Description:
For maritime sonar data analysis, the "presenting participant" is an autonomous underwater vehicle (AUV) or ship-mounted sonar system. The "audio data" consists of raw or pre-processed sonar returns, passive acoustic monitoring (PAM) data for marine mammal detection, and ambient ocean noise. The "input means" are advanced hydrophone arrays and active sonar transducers. The "storage means" on the AUV/ship provides high-capacity, fault-tolerant local storage, uploading data to a secure maritime operations center. "Observing participants" are oceanographers, naval intelligence analysts, or marine biologists. The "interface means" on their specialized analysis workstations provides a rich visualization of sonar waterfall displays alongside synchronized audio playback. Analysts can "pause" on a detected contact, "seek" back to its first appearance, and "adjust the playback rate" (e.g., 0.1x for fine-grained analysis of faint echoes or unique bio-acoustic signatures, 8.0x for rapid survey of vast datasets) while the "time-scale modification means" maintains the integrity of the acoustic patterns crucial for target classification or species identification.

stateDiagram-v2
    state AUV_Sonar <<presenting>>
    state Data_Storage <<storage>>
    state Workstation <<observing>>
    state Interface <<interface>>
    state TS_Mod <<time-scale modification>>
    state Audio_Out <<output>>

    AUV_Sonar --> Data_Storage: Transmit Sonar Data
    Data_Storage --> Workstation: Retrieve Data Stream
    Workstation --> Interface: Display/Playback Controls
    Interface --> TS_Mod: Playback Instructions
    TS_Mod --> Audio_Out: Manipulated Sonar Audio
    Audio_Out --> Workstation: Analyst Listens
    Workstation --> Data_Storage: Request (Live/Recorded)
    
    state "Playback Rate Control" as RateControl
    Interface --> RateControl
    RateControl --> TS_Mod
    
    [*] --> AUV_Sonar
    TS_Mod --> Audio_Out
    Audio_Out --> [*]

---

1.6. Integration with Emerging Tech: AI-Driven Adaptive Audio Time-Shifting with IoT-Contextualization and Blockchain Verification

Enabling Description:
This derivative enhances Claim 1 with AI, IoT, and Blockchain. The "input means" includes traditional audio capture but is augmented by IoT sensors (e.g., participant biometric data, room acoustics, environmental noise levels, emotion detection via facial recognition linked to audio). Audio data, enriched with IoT context metadata, is routed to a central "storage means" implemented as a decentralized ledger (blockchain) for tamper-proof recording and content integrity verification. Each audio frame's hash and associated metadata (e.g., timestamp, IoT sensor readings, speaker identity) are committed to the blockchain. An AI-driven "playback optimization engine" (part of the "server logic" and integrated with the "time-scale modification means") dynamically adjusts the default playback rate and time-shifting behavior based on real-time and historical IoT context, participant engagement levels (detected via biometrics/facial recognition), and content complexity (analyzed by NLP on transcriptions). For instance, if a participant's cognitive load is high (detected via biometrics) or the content is complex, the AI might suggest a slower playback rate with enhanced audio processing. The "interface means" provides AI-recommended time-shifting options and transparently displays the blockchain-verified metadata for each segment. When an observing participant issues time-shifting instructions, the "retrieval" and "manipulation" steps are verified against the blockchain ledger to ensure data authenticity and proper sequencing before feeding into the "time-scale modification means," which itself might use an AI-optimized neural audio codec for rate adjustment and quality preservation.

graph TD
    PC[Presenting Client] -- Audio + IoT Data --> DLT[Decentralized Ledger (Blockchain Storage)]
    IoT[IoT Sensors (Biometrics, Environment)] -- Metadata --> DLT
    DLT -- Verified Audio Frames/Metadata --> OC[Observing Client]
    AI_Engine[AI Playback Optimization Engine] -- Recommendations/Adaptive Control --> OC
    OC_UI[Client UI] -- Instructions/AI Feedback --> OC
    OC -- Verify & Process --> TS_Mod[Time-Scale Modification (AI-Optimized)]
    TS_Mod -- Output --> OS[Audio Output System]
    subgraph Observing Client with AI/Blockchain
        OC_UI
        OC
        TS_Mod
        OS
    end
    subgraph Backend
        DLT
        AI_Engine
    end

---

1.7. The "Inverse" / Failure Mode: Graceful Degradation for Intermittent Network Conditions

Enabling Description:
This derivative describes a system designed to gracefully degrade functionality under intermittent or severely constrained network conditions, prioritizing audio intelligibility over real-time synchronization or high fidelity time-shifting. The "input means" and "storage means" (server-side) operate as normal. However, the "client-side communication component" (part of the "output means") actively monitors network bandwidth and latency. If detected network quality drops below a predefined threshold (e.g., packet loss > 10%, latency > 500ms), the client application automatically switches to a "limited-functionality mode." In this mode, the "interface means" disables all playback rate adjustment and seek functionality beyond a small, fixed buffer (e.g., 5 seconds of rewind). The "time-scale modification means" is bypassed or operates in a simplified, non-pitch-preserving mode if necessary, to minimize computational load and ensure basic audio delivery. Audio data is streamed at a significantly reduced bitrate (e.g., mono, low sample rate, aggressive lossy compression like G.729 or Speex for narrow-band audio) prioritizing the most recent available audio. The "whereby" clause is modified such that the observing participant cannot selectively listen to previously presented data beyond the small buffer, nor adjust playback rate, but can continue to listen to the live stream with reduced quality and delayed synchronization, preventing a complete drop-out. As network quality improves, the system progressively re-enables time-shifting features and increases audio fidelity.

stateDiagram-v2
    state LiveStream
    state TimeShifted
    state DegradedMode

    [*] --> LiveStream

    LiveStream --> TimeShifted: Good_Network
    TimeShifted --> LiveStream: Good_Network (Default)

    LiveStream --> DegradedMode: Poor_Network
    TimeShifted --> DegradedMode: Poor_Network

    DegradedMode --> LiveStream: Network_Recovery
    DegradedMode --> TimeShifted: Network_Recovery_Full

    state "Normal Operation (Full Features)" as Normal
    state "Limited Functionality (Live Audio Only)" as Limited
    
    LiveStream --> Normal
    TimeShifted --> Normal
    DegradedMode --> Limited
    
    Normal --> Limited: Poor_Network
    Limited --> Normal: Network_Recovery_Full

    DegradedMode : Disable Rate Adjust, Seek
    DegradedMode : Bypass/Simplify Time-Scale Mod
    DegradedMode : Reduced Bitrate Audio
    DegradedMode : Prioritize Live Stream (Delayed)

---

Derivatives for Independent Claim 2: Web conferencing system

Claim 2 Preamble Summary: A web conferencing system with a first client for a presenting participant to share computer screen video and other data streams (chat, documents, web pages, white-boarding), storage means for recording, and a second client for an observing participant to sense live, or selectively sense previously presented/recorded parts while presenting is ongoing, or after presenting has finished. Emphasizes simultaneous recording and sensing current/previously presented parts.

---

2.1. Material & Component Substitution: GPU-Accelerated WebRTC Clients with Decentralized Storage and WASM-based Renderers

Enabling Description:
This derivative replaces traditional client-server video processing with GPU-accelerated WebRTC peer-to-peer connections for direct screen video and data stream sharing, coupled with decentralized storage. The "first client application" utilizes WebRTC's getDisplayMedia API for screen video capture, with real-time hardware-accelerated H.264 or VP9 encoding performed by the GPU. Other data streams (chat, documents) are transmitted via WebRTC data channels. The "storage means" is a distributed hash table (DHT) like IPFS, where clients upload segmented chunks of their encoded streams. Each chunk is uniquely addressed by its content hash. The "second client application" features a WebAssembly (Wasm) module that acts as a high-performance, GPU-accelerated video decoder and renderer (e.g., using WebGPU or WebGL2 for canvas rendering). When an observing participant requests a "previously presented and recorded part," the Wasm module fetches the relevant content-addressed chunks from the IPFS network (which might be cached by other peers). The Wasm renderer manages a local ring buffer of decoded video frames for seamless time-shifting operations (pause, resume, seek). This eliminates a central server bottleneck for video processing and storage, shifting the heavy lifting to client-side GPUs and a decentralized storage network.

graph TD
    PC[Presenting Client A] -- WebRTC Video/Data --> OC[Observing Client B]
    PC -- GPU H.264/VP9 Encode --> IPFS[IPFS Network (Decentralized Storage)]
    OC -- Fetch Chunks --> IPFS
    OC -- WASM GPU Decode/Render --> Display[Display Output]
    UI[Client UI] -- Time-Shift Commands --> OC_WASM[WASM Video Processor]
    OC_WASM -- Frame Buffer --> Display
    subgraph Presenting Client
        PC
    end
    subgraph Observing Client
        OC
        UI
        OC_WASM
        Display
    end

---

2.2. Operational Parameter Expansion: Hyper-Scale Archival Web Conferencing with Petabyte-Scale Data Streams and Millisecond-Level Time Synchronization

Enabling Description:
This derivative envisions a web conferencing system designed for hyper-scale archival, supporting thousands of simultaneous presenters and millions of observing participants, where individual "data streams" (e.g., high-resolution 8K screen video, CAD model interactions, holographic projections) can generate petabytes of data per session. The "storage means" is a multi-tiered, globally distributed object storage system (e.g., AWS S3 Glacier Deep Archive, Google Cloud Storage Coldline) with intelligent data lifecycle management. The core innovation lies in millisecond-level time synchronization across all disparate data streams for both live presentation and archival playback, even over long durations. Each frame from every stream is timestamped using a high-precision, network-time-protocol (NTP)-synchronized global clock source, with timestamps granular to microseconds. The "second client application" employs advanced caching strategies and predictive pre-fetching mechanisms, leveraging CDN edge nodes, to retrieve and present selected segments from the petabyte-scale archives within milliseconds of a "seek" command. It maintains a dynamic manifest of all stream segments and their associated micro-timestamps, allowing precise, frame-accurate time-shifting across all media types, regardless of their originating source or recording duration. Playback rates can be adjusted from 0.001x (extreme slow-motion for forensic analysis) to 100x (ultra-fast review of vast data segments).

graph TD
    P[Presenting Clients (Thousands)] -- 8K Video, CAD, Holographic Data --> C[Global CDN Edge Network]
    C -- Ingest --> GTS[Globally Timestamped Storage (Petabyte-Scale)]
    GTS -- Microsecond-Granular Index --> O[Observing Clients (Millions)]
    O -- Predictive Pre-fetching/Caching --> LCache[Local Client Cache]
    O_UI[Client UI] -- Seek/Playback --> O_Sync[Multi-Stream Sync Engine]
    O_Sync -- Frame-Accurate Retrieval --> LCache
    LCache -- Render --> Display[High-Res Display]
    subgraph Data Flow & Access
        P
        C
        GTS
        O
    end
    subgraph Observing Client Core
        O_UI
        O_Sync
        LCache
        Display
    end

---

2.3. Cross-Domain Application 1: Remote Construction Site Monitoring & Progress Review

Enabling Description:
In construction, the "first client application" is installed on ruggedized tablets or cameras carried by foremen or mounted on drones, sharing "computer screen video" (e.g., live drone feeds, augmented reality overlays of blueprints on site photos) and "data streams" such as daily progress reports, safety checklists (documents), and collaborative markups on site plans (white-boarding sessions). The "storage means" resides on a secure, private cloud accessible only to project stakeholders. The "second client application" is used by architects, engineers, and project managers in their offices. They can monitor the construction site live, or if they missed a critical event (e.g., a specific concrete pour, a crane lift), they can "selectively sense a previously presented and recorded part" of the drone video and review associated documents while the site continues to operate. For example, an engineer can review a structural element's installation from yesterday's recorded drone footage and compare it with the live feed, ensuring immediate compliance checks without delaying ongoing work.

graph TD
    D[Drone Camera] --> FC[First Client (Ruggedized)]
    FC -- Screen Video, Reports --> PCS[Private Cloud Storage]
    Foreman[Foreman Tablet] --> FC
    Arch[Architect Workstation] --> SC[Second Client]
    Eng[Engineer Workstation] --> SC
    PM[Project Manager Tablet] --> SC
    SC -- Live Feed/Recorded Playback --> Display[Monitoring Display]
    SC -- Access Records --> PCS
    subgraph Presenting Side
        D
        Foreman
        FC
    end
    subgraph Observing Side
        Arch
        Eng
        PM
        SC
        Display
    end
    PCS -- Records/Live Stream --> SC

---

2.4. Cross-Domain Application 2: Autonomous Vehicle Fleet Debugging & Incident Recreation

Enabling Description:
For autonomous vehicle (AV) fleet management, the "first client application" is integrated into the AV's onboard computer, sharing "computer screen video" (e.g., dashboard display, sensor fusion visualizations like LIDAR/RADAR point clouds, camera feeds) and "data streams" (e.g., diagnostic logs, telemetric data, route plans). The "storage means" is a secure, encrypted data recorder within the AV, which uploads critical incident data (e.g., near-misses, system failures) to a central cloud forensics platform. The "second client application" is used by AV engineers or accident investigators. During a live debugging session of a test vehicle, an engineer can observe the real-time sensor data and visualizations. If an anomaly occurs, they can instantly "selectively sense a previously presented and recorded part" of the sensor fusion visualization (rewind the incident) while the vehicle continues its test drive, and simultaneously review associated diagnostic logs and compare with live telemetric data to quickly pinpoint failure points. Post-incident, the entire drive and related data streams can be fully recreated for detailed analysis.

sequenceDiagram
    participant AV as Autonomous Vehicle (First Client)
    participant Sensor as Sensors (LIDAR, Camera, etc.)
    participant Onboard as Onboard Computer
    participant Forensics as Cloud Forensics Platform (Storage)
    participant Engineer as AV Engineer (Second Client)
    participant DebugUI as Debugging Workstation UI

    Sensor->>Onboard: Raw Data
    Onboard->>Onboard: Sensor Fusion & Visualizations
    Onboard->>Forensics: Record Data Streams (Video, Logs, Telemetry)
    Engineer->>DebugUI: Connect to Live AV Feed
    DebugUI->>Onboard: Request Live Streams
    Onboard->>DebugUI: Send Live Streams
    Note over AV,Engineer: Engineer observes live
    Engineer->>DebugUI: Seek/Rewind Incident
    DebugUI->>Forensics: Request Recorded Incident Data
    Forensics->>DebugUI: Send Recorded Data
    Note over Engineer,DebugUI: Engineer reviews recorded while AV is still live/running

---

2.5. Cross-Domain Application 3: Smart Retail Analytics - Shopper Journey Mapping

Enabling Description:
In smart retail, the "first client application" is integrated into high-resolution overhead cameras and smart shelf sensors, sharing "computer screen video" (e.g., anonymized shopper movement heatmaps, product interaction video) and "data streams" (e.g., real-time inventory levels, point-of-sale data, customer sentiment analysis from audio snippets if privacy compliant). The "storage means" is an on-premise AI appliance with secure, local storage. The "second client application" is used by retail analysts or store managers. They can observe live shopper traffic flows and product engagement. If a new promotional display is launched, analysts can "selectively sense a previously presented and recorded part" of the shopper heatmap from the hour before launch while live data is still being collected, to compare with the current live impact of the promotion. They can simultaneously review sales data from both periods. This allows for real-time campaign optimization and instant A/B testing insights without waiting for a full day's data.

graph LR
    C[Overhead Cameras] --> FC[First Client (Smart Sensors)]
    S[Smart Shelf Sensors] --> FC
    FC -- Shopper Heatmaps, Product Video, Inventory, POS --> AIApp[On-Premise AI Appliance (Storage)]
    AIApp -- Live/Recorded Data --> SC[Second Client (Retail Analyst)]
    SC -- Review Display, Heatmaps, Sales --> Display[Analysis Dashboard]
    SC -- Time-Shift Controls --> SC

---

2.6. Integration with Emerging Tech: Predictive AI for Proactive Content Pre-fetching with Digital Twin Synchronization and Immutable Ledger for Session Integrity

Enabling Description:
This derivative extends Claim 2 by integrating AI-driven predictive analytics, digital twin technology, and blockchain. The "first client application" streams computer screen video and data (CAD models, sensor readouts) from a physical asset (e.g., a complex machine) or its "digital twin." An AI engine, integrated with the "server application" and "storage means," continuously analyzes observing participant behavior (e.g., scroll speed, zoom levels, areas of interest in previous sessions) and the content itself to predict future viewing patterns. Based on these predictions, the AI proactively triggers "pre-fetching" of relevant "previously presented and recorded parts" to the "second client application" before the participant even requests them, ensuring zero-latency time-shifting. All actions, content changes, and participant interactions within the conference are hashed and logged to an immutable blockchain ledger, ensuring verifiable session integrity for compliance and auditing. When observing a digital twin, "sensing a previously presented and recorded part" automatically synchronizes the digital twin's state to that past point in time, allowing interactive exploration of the past state while the physical asset (or its live twin) continues to operate, or while other participants view the live stream.

flowchart TD
    PA[Presenting Asset/Digital Twin (First Client)] -- Live Video/Data --> Server[Server Application]
    Server -- Record & Hash --> Blockchain[Blockchain (Immutable Storage)]
    Server -- Analyze Data --> AI_Predict[AI Predictive Engine]
    AI_Predict -- Pre-fetch Instructions --> Server
    Server -- Proactive Data Push --> OC[Observing Client (Second Client)]
    OC_UI[Client UI] -- Time-Shift Controls --> OC_Render[Renderer/Digital Twin Sync]
    OC_Render -- Synchronize Past State --> DT_Local[Local Digital Twin Instance]
    OC -- Verify Session Integrity --> Blockchain
    subgraph Data Flow with Emerging Tech
        PA
        Server
        Blockchain
        AI_Predict
        OC
        OC_UI
        OC_Render
        DT_Local
    end

---

2.7. The "Inverse" / Failure Mode: Read-Only, Minimum-Bandwidth Archival Viewer for Disaster Recovery

Enabling Description:
This derivative describes a system optimized for disaster recovery scenarios or extreme bandwidth constraints, offering a read-only, minimum-bandwidth archival viewer. The "first client application" (presenter) is assumed to have successfully transmitted its streams to the "storage means." The "second client application" in this inverse mode is a highly stripped-down, lightweight application (e.g., a static HTML/JS web page or a console-based viewer) that only allows "sensing previously presented and recorded parts" of the conference. All live sensing capabilities are disabled. The system prioritizes essential text-based data streams (chat, documents) over computer screen video when bandwidth is critically low. If video is retrieved, it is heavily compressed (e.g., Motion JPEG at 1 fps, or highly artifacted H.264 at extremely low bitrates) and potentially downscaled to a minimal resolution (e.g., 320x240). The "interface means" only provides basic navigation (next/previous frame, jump to timestamp from a text index) without smooth scrubbing or playback rate adjustment. The intent is to provide some access to critical recorded information in adverse conditions, even if the user experience is severely degraded and real-time interaction is impossible. The "whereby" clause is modified to reflect that the system can only allow observing recorded parts, and only with severely constrained resources and functionalities.

graph TD
    S[Storage Means (Archived Session)] --> DC[Disaster Recovery Client (Second Client)]
    DC_UI[Minimal UI] -- Basic Navigation (Next/Prev, Jump) --> DC
    DC -- Low-Bandwidth Request --> S
    S -- Prioritized Text/Low-Res Video --> DC
    DC -- Display Text/Static Frames --> Output[Text/Image Display]
    subgraph Disaster Recovery Operation
        S
        DC
        DC_UI
        Output
    end

---

Derivatives for Independent Claim 7: Web conferencing system with audio and video

Claim 7 Preamble Summary: A web conferencing system with a first client for a presenting participant to share audio and computer screen video data streams, a second client for an observing participant to sense streams, a server application to record and retrieve, and a time-scale modification component for consistent audio quality at various playback rates. Emphasizes simultaneous recording/retrieval, real-time sensing, and selective sensing of previously recorded parts at variable playback rates with consistent audio quality, while presenting is ongoing or after.

---

7.1. Material & Component Substitution: FPGA-Accelerated Hybrid Server/Edge Processing with AV1 Codecs and Content-Addressable Storage

Enabling Description:
This derivative utilizes a hybrid server/edge architecture for the "server application," where computationally intensive tasks (e.g., real-time transcoding, time-scale modification, frame indexing) are offloaded to Field-Programmable Gate Array (FPGA) acceleration cards at network edge locations. The "first client application" encodes audio using Opus and video using the royalty-free AV1 codec, configured for adaptive bitrate streaming. The "server application" (with FPGA accelerators) receives these streams, performs real-time decompression and re-compression if necessary (e.g., for different client device capabilities), and processes them for the "time-scale modification component," which is also implemented as an FPGA hardware block for parallel audio processing. The "storage device" is a content-addressable storage (CAS) system, where each audio/video frame segment is stored as an immutable object identified by its cryptographic hash (e.g., similar to IPFS backend, but managed by the server for performance). The "second client application" fetches segments from the CAS. For time-shifting, the FPGA-accelerated "time-scale modification component" directly manipulates the AV1-decoded audio at the edge or server before transmission, ensuring high-quality, variable-rate playback for observing participants, especially for low-power client devices.

graph TD
    PC[Presenting Client] -- Opus/AV1 Streams --> Edge[Edge Server (FPGA-Accelerated)]
    Edge -- Real-time Transcoding/Indexing --> CAS[Content-Addressable Storage]
    Edge -- FPGA Time-Scale Mod --> OC[Observing Client]
    OC_UI[Client UI] -- Playback Controls --> OC
    OC -- Request Data --> Edge
    Edge -- Retrieve/Process --> OC
    subgraph Edge Processing Unit
        Edge
        CAS
    end
    subgraph Client Interaction
        OC_UI
        OC
    end

---

7.2. Operational Parameter Expansion: Immersive VR/AR Web Conferencing with Haptic Feedback and Millimeter-Wave Streaming

Enabling Description:
This derivative expands the web conferencing system into an immersive Virtual Reality (VR) or Augmented Reality (AR) environment, streaming multi-modal data over high-bandwidth millimeter-wave (mmWave) 5G networks for untethered experiences. The "first client application" for presenting participants captures not only audio and computer screen video but also 3D spatial data (e.g., lidar scans of the presenter's environment, motion capture of gestures), biometric data (e.g., gaze tracking), and haptic input. These are all packaged as synchronized "data streams." The "server application" processes these multi-modal streams, creating a dynamic 3D virtual environment or AR overlay. The "second client application" is a VR/AR headset, enabling observing participants to navigate the virtual space or interact with AR overlays. Time-shifting operations (pause, resume, seek, adjust playback rate) apply to the entire synchronized multi-modal stream. When a participant pauses, the 3D environment freezes, and the "time-scale modification component" (now extended to spatial audio and haptic feedback profiles) ensures that 3D audio directionality, reverberation, and simulated haptic sensations remain consistent at variable playback speeds, allowing detailed review of gestures, spatial interactions, or 3D object manipulation at 0.1x to 5x speed. mmWave streaming ensures the extremely low latency and high bandwidth required for real-time 3D data and haptic feedback.

classDiagram
    class PresentingClient {
        +CaptureAudio()
        +CaptureVideo()
        +Capture3DSpatial()
        +CaptureBiometric()
        +CaptureHapticInput()
        +StreamMultiModalData()
    }
    class ServerApplication {
        +ReceiveMultiModalData()
        +RecordToStorage()
        +Process3DEnvironment()
        +RetrieveMultiModalData()
        +SendToClient()
    }
    class StorageDevice {
        +StoreMultiModalStreams()
        +RetrieveMultiModalStreams()
    }
    class ObservingClient {
        +ReceiveMultiModalData()
        +RenderVR_AR_Environment()
        +DisplayUIControls()
        +SenseLiveStreams()
        +SenseRecordedStreams()
        +ControlPlayback()
    }
    class TimeScaleModificationComponent {
        +ManipulateAudioTimeScale()
        +ManipulateSpatialAudio()
        +ManipulateHapticProfiles()
        +MaintainPerceivedQuality()
    }
    class VR_AR_Headset {
        +DisplayVisuals()
        +OutputAudio()
        +ProvideHapticFeedback()
    }
    class mmWave_5G_Network {
        +HighBandwidthLowLatencyTransmission()
    }

    PresentingClient "1" --> "1" mmWave_5G_Network : Streams via
    mmWave_5G_Network "1" --> "1" ServerApplication : Transmits to
    ServerApplication "1" --> "1" StorageDevice : Records in
    ServerApplication "1" --> "1" TimeScaleModificationComponent : Processes Audio/Haptic
    ServerApplication "1" --> "1" mmWave_5G_Network : Sends to
    mmWave_5G_Network "1" --> "1" ObservingClient : Receives from
    ObservingClient "1" --> "1" VR_AR_Headset : Powers
    TimeScaleModificationComponent "1" --> "1" ObservingClient : Provides enhanced processing
    ObservingClient "1" --> "1" ServerApplication : Requests
    VR_AR_Headset "1" --> "1" ObservingClient : Provides interface

---

7.3. Cross-Domain Application 1: Remote Repair and Maintenance (Digital Twin Synchronization)

Enabling Description:
In remote repair and maintenance, a "first client application" is on a technician at a remote facility, sharing "audio data" (e.g., machinery sounds, technician's verbal descriptions) and "computer screen video data" (e.g., live video from a borescope inspecting internal components, AR overlays showing repair instructions). The data streams are also synchronized with a "digital twin" of the machinery being repaired. The "server application" records these streams to a central maintenance log. A "second client application" is on an expert engineer at headquarters. They can view the technician's live feed and hear the live audio. If the technician identifies a specific malfunction, the expert can immediately "selectively sense a previously presented and recorded part" of the technician's borescope video from 30 seconds ago while the technician is still live, simultaneously reviewing the associated machinery sounds at a slower playback rate (e.g., 0.5x) with the "time-scale modification component" to diagnose subtle changes in engine knock. Crucially, rewinding the video automatically synchronizes the digital twin's state to that exact past point in time, allowing the expert to manipulate the virtual machine model in its past state for diagnostic purposes, without interrupting the technician's live work.

sequenceDiagram
    participant Technician as Remote Technician (First Client)
    participant Borescope as Borescope Video
    participant Mic as Audio Input
    participant DT as Digital Twin
    participant Server as Server Application
    participant Engineer as Expert Engineer (Second Client)
    participant Workstation as Engineer Workstation

    Technician->>Borescope: Operate Borescope
    Technician->>Mic: Speak Instructions/Observations
    Borescope->>Server: Video Stream
    Mic->>Server: Audio Stream
    DT->>Server: Digital Twin State Sync
    Server->>Engineer: Live Streams
    Engineer->>Workstation: Observe Live
    Note over Technician,Engineer: Technician works live, Engineer observes
    Engineer->>Workstation: Seek/Change Playback Rate
    Workstation->>Server: Request Recorded Segment & DT State
    Server->>Engineer: Recorded Video/Audio, Past DT State
    Engineer->>Workstation: Analyze Recorded Data & Interact with Past DT State
    Note over Engineer,Workstation: Time-shifted analysis without interrupting live

---

7.4. Cross-Domain Application 2: Remote Art Restoration & Conservation

Enabling Description:
For art restoration and conservation, the "first client application" is on a conservator working on a valuable artifact, sharing "audio data" (e.g., subtle sounds of material removal, conservator's commentary) and "computer screen video data" (e.g., high-magnification video of brush strokes, chemical reactions under UV light, X-ray imagery overlays). The "server application" meticulously records these multi-modal streams to a secure, long-term archival storage system. A "second client application" is on a lead art historian or senior conservator in a different location. They can observe the live restoration process, providing real-time guidance. If a specific technique is applied, the art historian can "selectively sense a previously presented and recorded part" of the high-magnification video from a few minutes ago while the conservator is still live, replaying the audio commentary at a slower speed (e.g., 0.75x) with the "time-scale modification component" to analyze the precise pressure and angle of a tool. This enables detailed, asynchronous review of delicate procedures without disrupting the ongoing live work, allowing for both immediate guidance and long-term documentation.

graph TD
    Conservator[Conservator (First Client)] -- Borescope/Microphone --> LiveStream[Live A/V Streams]
    LiveStream --> Server[Server Application]
    Server -- Record to --> Archival[Archival Storage]
    Server -- Live Feed --> Senior[Senior Conservator (Second Client)]
    Senior -- UI Controls (Seek, Speed) --> Senior
    Senior -- Playback Request --> Server
    Server -- Retrieve/Manipulate --> Senior
    subgraph Data Flow
        Conservator
        LiveStream
        Server
        Archival
        Senior
    end

---

7.5. Cross-Domain Application 3: Interactive Museum Exhibits with Visitor Analytics

Enabling Description:
In an interactive museum exhibit, the "first client application" is integrated into a multi-sensor kiosk or a curated exhibit area. It shares "audio data" (e.g., visitor questions, ambient exhibit sounds) and "computer screen video data" (e.g., anonymized visitor gaze tracking on displays, interaction with touchscreens, specific gestures). The "server application" captures and records these streams. The "second client application" is for exhibit designers, educational researchers, or museum staff. They can observe live visitor interactions. If a particular display is underperforming, a designer can "selectively sense a previously presented and recorded part" of the visitor gaze tracking video from the past hour while live visitor data is still being collected for the current hour. They can simultaneously listen to recorded visitor comments at a variable playback rate with the "time-scale modification component" to understand engagement patterns and optimize the exhibit in real-time, or identify points of confusion. The system allows concurrent analysis of historical and live data without interruption.

stateDiagram-v2
    state ExhibitSensors <<presenting>>
    state ServerRecording <<server/storage>>
    state AnalystWorkstation <<observing>>
    state TimeShiftControls <<interface>>
    state AudioVideoOutput <<output>>
    state TimeScaleMod <<time-scale modification>>

    [*] --> ExhibitSensors: Visitor Interaction
    ExhibitSensors --> ServerRecording: A/V Data Streams
    ServerRecording --> AnalystWorkstation: Live Feed
    AnalystWorkstation --> TimeShiftControls: Interact
    TimeShiftControls --> ServerRecording: Request Recorded Data
    ServerRecording --> TimeScaleMod: Send Audio Data
    TimeScaleMod --> AudioVideoOutput: Manipulated Audio/Video
    AudioVideoOutput --> AnalystWorkstation: Perceive Output
    AnalystWorkstation --> ServerRecording: Record & Retrieve Simultaneously
    TimeScaleMod --> AudioVideoOutput

---

7.6. Integration with Emerging Tech: Real-time ML-driven Semantic Search and Summarization with AR Annotation and NFT-Secured Content Rights

Enabling Description:
This derivative augments Claim 7 with Machine Learning (ML) for semantic search and summarization, Augmented Reality (AR) for annotation, and Non-Fungible Tokens (NFTs) for content rights. The "first client application" streams audio and screen video. An ML engine, integrated into the "server application," performs real-time speech-to-text transcription, speaker diarization, and semantic analysis of both audio and screen content (e.g., identifying key terms, concepts, active windows). This processed metadata is recorded alongside the raw streams in the "storage device." The "second client application" is an AR-enabled device. The "interface means" allows observing participants to trigger ML-driven semantic searches (e.g., "show me where 'Project X' was discussed") that instantly "seek" to relevant "previously presented and recorded parts" of the session. During time-shifted playback, the AR device overlays ML-generated summaries, key concept tags, and participant-created AR annotations (e.g., virtual sticky notes, 3D pointers) onto the screen video. Playback rate adjustments are intelligently handled by the "time-scale modification component" for audio, while the AR annotations dynamically adapt their display duration. Crucially, session recordings and individual content segments can be tokenized as NFTs, with ownership and access rights managed on a blockchain, allowing for granular control over content usage and distribution by the presenting participant or organization.

graph TD
    PC[Presenting Client] -- A/V Stream --> Server[Server Application]
    Server -- Record & Process --> ML[ML Engine (Semantic Search, Summarization)]
    ML -- Metadata/Index --> DB[Storage Device]
    Server -- Raw A/V --> DB
    DB -- Authenticated Access --> OC[Observing Client (AR Device)]
    NFT[NFT Platform (Content Rights)] -- Access Control --> Server
    OC_UI[AR Interface] -- Semantic Search, Playback Controls --> OC
    OC -- Fetch Data/Metadata --> DB
    OC -- AR Overlay, Summaries --> Display[AR Headset Display]
    OC -- Playback Rate --> TS_Mod[Time-Scale Modification]
    TS_Mod -- Audio Output --> Display
    subgraph Integrated System
        PC
        Server
        ML
        DB
        NFT
        OC
        OC_UI
        Display
        TS_Mod
    end

---

7.7. The "Inverse" / Failure Mode: Audio-Only Emergency Broadcast with Visual Cues for Time-Shift Disruption

Enabling Description:
This derivative describes a failure mode for critical web conferences where the system defaults to an "audio-only emergency broadcast" with explicit visual cues indicating time-shift functionality is unavailable or compromised. In a severe network or server failure where video streams cannot be maintained or synchronized, or complex time-shifting logic is impossible, the "server application" and "client applications" automatically revert to this emergency mode. The "first client application" prioritizes transmitting only compressed audio data (e.g., G.711 or GSM codecs for telephony compatibility). The "second client application" immediately ceases all video display and presents a static error screen or a simplified text console. The "time-scale modification component" is either completely disabled or operates in a rudimentary, non-pitch-preserving mode to ensure any audio is delivered. The "interface means" visibly greys out or removes all playback rate adjustment, pause, resume, and seek controls. Instead, a prominent, flashing visual indicator (e.g., a "LIVE - AUDIO ONLY - SYNCHRONIZATION IMPAIRED" banner) is displayed, clearly informing the observing participant that they are receiving a delayed, low-fidelity, audio-only stream and cannot perform time-shifting operations. The system's "whereby" clause is modified to reflect that, under emergency conditions, participants can only listen to a linear, delayed audio stream, with visual notification that the advanced features are temporarily unavailable, ensuring critical communication continues even at the expense of functionality and quality.

stateDiagram-v2
    state NormalOperation
    state EmergencyMode

    NormalOperation --> EmergencyMode: Severe_Network_Failure
    EmergencyMode --> NormalOperation: Network_Restored

    NormalOperation : Full A/V Streaming
    NormalOperation : Time-Shifting Enabled
    NormalOperation : Quality Preserved
    
    EmergencyMode : Audio-Only Broadcast
    EmergencyMode : Disable Time-Shifting
    EmergencyMode : Basic Audio Codec
    EmergencyMode : Visual Alert (Live, Audio Only)
    EmergencyMode : Synchronization Impaired
    
    [*] --> NormalOperation

---

Combination Prior Art Scenarios with Open-Source Standards

Here are at least three "Combination Prior Art" scenarios for US Patent 7,679,637, combining elements of the patent with existing open-source standards. These scenarios describe how well-known technologies, if integrated, would achieve the patent's core functionalities.

1. Time-Shifted Audio in a SIP-based Teleconference with Asterisk and SoundTouch:

   • Prior Art: US6298129B1 (Teleconference recording and playback system) provides the foundational concept of recording teleconferences. The "telephony device" (540 in FIG. 5 of US7679637) can be realized by an Asterisk PBX, which is an open-source framework for building communication applications, including teleconferencing bridges that handle SIP (Session Initiation Protocol).
   • Open-Source Standard Integration: A combination of US6298129B1 with the open-source Asterisk PBX (implementing SIP) to manage teleconference audio streams and the open-source SoundTouch library (explicitly mentioned in US7679637's description for time-scale modification) would make Claim 1 obvious. Asterisk can record calls (storage means) and route audio (input/output means). Integrating SoundTouch directly into the Asterisk media processing pipeline (e.g., as a custom application or module) would provide the "time-scale modification means" and allow for variable speed playback with pitch preservation. A simple web interface controlling Asterisk's playback and SoundTouch's parameters would fulfill the "interface means" for pause, resume, seek, and rate adjustment. This configuration would enable observing participants to interact with audio data (live or recorded) with time-shifting and quality preservation, mirroring the core of Claim 1, especially given Asterisk's capabilities for dynamic playback of recorded media.

2. Time-Shifted Screen Sharing and Data Streams in a WebRTC-based Collaborative Editor:

   • Prior Art: US6906741B2 (System for and method of conferencing with a handheld computer using multiple media types) teaches multi-media conferencing. US20060146124A1 (Video conference recorder) describes recording video conference streams. The concepts of sharing computer screen video and various data streams (chat, documents) are well-established.
   • Open-Source Standard Integration: Combining US6906741B2 and US20060146124A1 with the open-source WebRTC (Web Real-Time Communication) standard for real-time peer-to-peer media streaming, and an open-source collaborative editor framework like Etherpad or a CRDT (Conflict-free Replicated Data Type) library for documents/white-boarding, would render Claim 2 obvious. A WebRTC client could capture screen video (first client sharing screen video). Data channels within WebRTC or an integrated Etherpad instance would handle chat/documents/white-boarding (other data streams). A server component (or even a peer with sufficient storage) could record these WebRTC streams (storage means). An observing WebRTC client could then connect to the live streams or request recorded segments from the storage. The "selectively sense a previously presented and recorded part" while live could be implemented by having the client buffer the incoming WebRTC streams locally (like a DVR, a concept taught by US6847778B1) and offer a playback control for the local buffer.

3. Comprehensive Time-Shifted A/V Web Conference using Jitsi Meet, FFmpeg, and a Distributed Database:

   • Prior Art: US7466334B1 (Method and system for recording and indexing audio and video conference calls) provides a system for recording and navigating conference calls. US20020165721A1 (Real-time control of playback rates in presentations) describes controlling playback rates.
   • Open-Source Standard Integration: A combination of US7466334B1 and US20020165721A1 with the open-source Jitsi Meet (a complete web conferencing solution providing clients and server/media bridge), the open-source FFmpeg library (for robust audio/video transcoding, de/compression, and potential time-scale modification processing similar to SoundTouch but for a broader range of media), and a distributed key-value store database like Redis or Cassandra for storing indexed media frames, would make Claim 7 obvious. Jitsi Meet provides the client applications for sharing audio/video and the server infrastructure. A Jitsi "recorder" component, enhanced with FFmpeg capabilities, could store streams frame-by-frame with timestamps in the distributed database (server application recording to storage). FFmpeg's extensive filter graph capabilities include pitch-preserving time-stretching (achieving the "time-scale modification component"). The Jitsi client UI could be extended to provide pause, resume, seek, and playback rate controls, fetching segments from the Redis/Cassandra store and processing them with FFmpeg on the server or client side before display. This leverages existing, mature open-source projects to create the exact functionality claimed.