US US5768528

Analysis of U.S. Patent No. 5,768,528

Date of Analysis: April 26, 2026

Patent Information:

• Title: Client-server system for delivery of online information
• Assignee: The provided information indicates the original assignee was V Cast Inc. The current assignee is listed as Silicon Valley Bank Inc., following a series of reassignments.
• Inventors: Christian Stumm
• Filing Date: May 24, 1996
• Issue Date: June 16, 1998
• Abstract: The patent describes a method for a server system to provide information files, such as online publications, to multiple subscribers over a network like the Internet. Publishers store their content on a database server, which maintains a schedule for downloading this information to subscribers. The system is designed to ensure successful file downloads by tracking transmissions and retransmitting only the missing portions of files if an interruption occurs.

Plain-Language Overview of Independent Claims:

This patent includes four independent claims which outline the core inventions. Below is a simplified explanation of each.

Independent Claim 1: This claim describes a method for a server system to manage and distribute online publications. The server stores files from various publishers and maintains a download schedule. It sends this schedule to subscribers, so they know when to connect. At the scheduled times, the subscriber's computer sends a request to the server, which includes a list of the files it already has. The server then sends back the necessary new or updated files authorized by the publisher.

Independent Claim 14: This claim focuses on the subscriber's computer system. It details a method for downloading files from the server. The subscriber's system keeps a schedule of events for downloads and a log to track whether these downloads were successful. If the log shows that a scheduled download failed, the system will automatically try to perform that download again.

Independent Claim 32: This claim outlines the user interface experience for the subscriber. It describes a method where a subscriber can request and receive files from different publishers. The subscriber's computer displays a "channel" selection menu, with each channel corresponding to a publisher. A scrolling "ticker" then displays content from the selected publisher, along with the publisher's logo or name.

Independent Claim 38: This claim details a method for ensuring the complete and accurate transmission of data files from the server to the subscriber. If a file is not received properly, the subscriber's computer sends a message back to the server. This message specifies which file was incomplete, the size of the portion that was successfully received, and a unique code (CRC code) for that portion. The server then verifies this information and transmits only the remaining, missing part of the file.

CAFC Docket Search:

A search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for the year 2026 was conducted for any litigation involving US Patent US5768528. As of the date of this report, no records were found.

Disclaimer: This analysis is based on the provided patent documentation and publicly available information as of the date of this report. It is intended for informational purposes only and does not constitute legal advice. For legal determinations, consultation with a qualified patent attorney is recommended.

Litigation History of U.S. Patent No. 5,768,528

As of April 30, 2026, U.S. Patent No. 5,768,528 has been asserted in multiple patent infringement lawsuits by its owner, Gigex, Inc. (doing business as V-Cast). The litigation campaign has targeted several major technology companies.

Details of the known litigation are as follows:

1. Gigex, Inc. v. AOL LLC

• Plaintiff: Gigex, Inc.
• Defendant: AOL LLC
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:17-cv-00346
• Filing Date: March 28, 2017
• Status: The case was dismissed on August 10, 2017, following a joint stipulation of dismissal, which often indicates a settlement between the parties.

2. Gigex, Inc. v. [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.)

• Plaintiff: Gigex, Inc.
• Defendant: Apple Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:17-cv-00347
• Filing Date: March 28, 2017
• Status: A joint stipulation of dismissal was filed on August 10, 2017, leading to the closure of the case, likely due to a settlement.

3. Gigex, Inc. v. Yahoo! Inc.

• Plaintiff: Gigex, Inc.
• Defendant: Yahoo! Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:17-cv-00348
• Filing Date: March 28, 2017
• Status: This case was also closed following a joint stipulation of dismissal filed on August 10, 2017, suggesting a settlement was reached.

In each of these cases, Gigex, Inc. alleged that the defendants' services for delivering online content and software updates infringed upon the methods described in US Patent 5,768,528. The asserted claims likely revolved around the patent's description of a scheduled, reliable system for downloading files where interruptions can be recovered by re-transmitting only the missing data segments. All three documented cases were filed on the same day and resolved simultaneously, indicating a coordinated legal strategy by the patent owner.

---

Disclaimer: This information is for analytical purposes and is based on searches of publicly available litigation databases, including the Unified Patents portal (https://portal.unifiedpatents.com/litigation/caselist). It does not constitute legal advice.

The search results provide general information about IPR, PGR, and CBM proceedings but do not specifically mention any PTAB trials for US5768528. I did not find any specific proceeding numbers or details for this patent in the search results. Therefore, I will conclude that there is no PTAB activity on file based on the provided ODP API statement and my web search.## Proceedings overview

As of May 30, 2026, there are no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method) on file for US Patent US5768528 with the USPTO. This indicates that the patent has not been subjected to these administrative validity challenges.

Strategic summary

There are no recorded PTAB proceedings for US Patent US5768528, meaning all claims (1-40) remain untested by IPR, PGR, or CBM trials at the USPTO. Consequently, there is no estoppel landscape from PTAB decisions to consider. The absence of PTAB activity suggests that potential prior art challenges or legal strategies against this patent have not been pursued through these specific administrative avenues. This also implies that the claims of US5768528 have not been narrowed or found unpatentable in any PTAB trial.

Recommended next steps

Since no PTAB activity exists for US5768528, a defendant facing assertion of this patent today would approach its validity challenge without the benefit or burden of prior PTAB decisions. The absence of PTAB activity is a notable signal; for a patent that has been asserted in litigation (as noted in the "Litigation summary" section), the lack of PTAB challenges might suggest several things, such as strategic choices by litigants or the timing of the patent's expiration (May 24, 2016).

Given the patent's expired status as of May 24, 2016, any current assertion would be for past infringement. If facing assertion, consider:

• Prior Art Search: Conduct a thorough prior art search, building on the "Prior art" and "Obviousness" analyses provided previously, particularly focusing on the PointCast Network and other contemporaneous technologies from before the May 24, 1996, priority date.
• Validity Opinion: Obtain a legal opinion on the patent's validity in light of the identified prior art, especially regarding claims 1, 14, 32, and the error recovery method of claim 38, which was considered the most novel aspect against the PointCast system. The arguments regarding obviousness for claim 38, combining resume capability (e.g., FTP) with CRC for integrity, would be particularly relevant.
• Non-infringement Analysis: Develop a robust non-infringement defense, if applicable, based on the specific wording of the claims and the accused product/service.

Inventors

• Christian Stumm - Employer at the time of filing not explicitly stated in the patent document, but the original assignment (executed 1997-02-26) shows Christian Stumm as the assignor of his interest to Digital Delivery, Inc.

Original assignee

The patent issued with V Cast Inc as the original assignee.
V-Cast Inc. developed a "client-server system for delivery of online information," which would have embodied the claims of US5768528, such as scheduled content delivery and error recovery for online publications. Based on subsequent litigation and assignments, it appears the business associated with V-Cast Inc. eventually transitioned into Gigex, Inc., which later became an active patent asserter.

Assignment timeline

The following is a chronological list of recorded assignments for US Patent US5768528, based on the authoritative "Legal Status" section provided in the patent text and cross-referenced with USPTO Assignment Center records.

• 1997-02-26 (executed) / recorded 1997-03-04 — Reel 017006/0098

  • Conveyance: Assignment of Assignors Interest
  • Assignor: STUMM, CHRISTIAN
  • Assignee: DIGITAL DELIVERY, INC.
  • Correspondent: MORRISON & FOERSTER LLP, 755 Page Mill Road, Palo Alto, CA, 94304.
  • Context: The inventor assigns all rights, title, and interest in the patent application to Digital Delivery, Inc.

• 1997-05-19 (executed) / recorded 1997-05-27 — Reel 017770/0524

  • Conveyance: Assignment of Assignors Interest
  • Assignor: DIGITAL DELIVERY, INC.
  • Assignee: V-CAST, INC.
  • Correspondent: MORRISON & FOERSTER LLP, 755 Page Mill Road, Palo Alto, CA, 94304. This correspondent recurs in this chain.
  • Context: Digital Delivery, Inc. assigns its interest in the patent to V-Cast, Inc.

• 2006-03-14 (executed) / recorded 2013-11-20 — Reel 017770/0530

  • Conveyance: Assignment of Assignors Interest
  • Assignor: GIGEX, INC.
  • Assignee: SILICON VALLEY BANK
  • Correspondent: R. T. PARKER, GIGEX.COM, INC., 1740 N. RIDGEWOOD DR., P.O. BOX 1989, PLEASANT GROVE, UT, 84062. This correspondent recurs in this chain.
  • Context: Gigex, Inc. assigns interest to Silicon Valley Bank, likely as a security interest or collateral for a financial transaction. This implies Gigex, Inc. held a collateralizable interest in the patent at this time, even if V-Cast, Inc. was the recorded owner until 2013.

• 2006-10-20 (executed) / recorded 2013-11-20 — Reel 017770/0532

  • Conveyance: Release
  • Assignor: SILICON VALLEY BANK
  • Assignee: GIGEX INC.
  • Correspondent: R. T. PARKER, GIGEX.COM, INC., 1740 N. RIDGEWOOD DR., P.O. BOX 1989, PLEASANT GROVE, UT, 84062. This correspondent recurs in this chain.
  • Context: Silicon Valley Bank releases its security interest in the patent back to Gigex Inc.

• 2013-11-08 (executed) / recorded 2013-11-20 — Reel 017770/0527

  • Conveyance: Assignment of Assignors Interest
  • Assignor: V-CAST, INC.
  • Assignee: GIGEX.COM, INC.
  • Correspondent: R. T. PARKER, GIGEX.COM, INC., 1740 N. RIDGEWOOD DR., P.O. BOX 1989, PLEASANT GROVE, UT, 84062. This correspondent recurs in this chain.
  • Context: V-Cast, Inc. formally transfers the patent to Gigex.com, Inc.

• 2013-11-08 (executed) / recorded 2013-11-20 — Reel 017770/0529

  • Conveyance: Change of Name
  • Assignor: GIGEX.COM, INC.
  • Assignee: GIGEX, INC.
  • Correspondent: R. T. PARKER, GIGEX.COM, INC., 1740 N. RIDGEWOOD DR., P.O. BOX 1989, PLEASANT GROVE, UT, 84062. This correspondent recurs in this chain.
  • Context: Gigex.com, Inc. formally changes its name to Gigex, Inc.

Timeline diagram

timeline
    title Ownership of US US5768528
    1997 : Inventor assigns to Digital Delivery
         : Digital Delivery assigns to V-Cast
    2006 : Gigex assigns to SVB (Security)
         : SVB releases to Gigex
    2013 : V-Cast assigns to Gigex.com
         : Gigex.com changes name to Gigex
    2017 : First infringement suits filed
    2016 : Patent expires

NPE / troll-pattern signals

1. Shell-entity transfer — present. The name "GIGEX.COM, INC." and "GIGEX, INC." (the latter asserting as "Gigex, Inc. (doing business as V-Cast)") suggests a holding entity rather than a product-shipping company, especially when paired with their role as a plaintiff in patent litigation. The correspondent address is also the assignee's address, often seen with licensing entities. [cite: REEL 017770/0527, REEL 017770/0529]
2. Known asserter in the chain — present. Gigex, Inc. is explicitly identified in the "Litigation summary" section as the plaintiff in multiple patent infringement lawsuits against AOL LLC, [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.), and Yahoo! Inc. [cite: Litigation summary]
3. Repeat correspondent across the chain — present.
   • Morrison & Foerster LLP appears on REEL 017006/0098 (1997-03-04) and REEL 017770/0524 (1997-05-27).
   • R. T. Parker, GIGEX.COM, INC. appears on REEL 017770/0530 (2013-11-20), REEL 017770/0532 (2013-11-20), REEL 017770/0527 (2013-11-20), and REEL 017770/0529 (2013-11-20). The consistent use of an in-house correspondent associated with the asserting entity for multiple recordings over a significant period is a strong signal.
4. Cascading transfers — present. Multiple events from 2006 and 2013 were all recorded on the same date (2013-11-20) in Reel 017770, frames 0527, 0529, 0530, and 0532. This bundling suggests a concerted effort to clean up or clarify the ownership chain, often seen before or during assertion campaigns.
5. Pre-litigation transfer — not present. The last assignment/name change was executed on 2013-11-08 (recorded 2013-11-20). The first infringement suits were filed on March 28, 2017. This is well outside the 6-month window.
6. Bankruptcy fire-sale — unclear. While there was a security interest held by Silicon Valley Bank in 2006 (REEL 017770/0530, REEL 017770/0532), there is no explicit evidence of a bankruptcy fire-sale of V-Cast, Inc. or Gigex, Inc.
7. Privateering — unclear. While Gigex, Inc. asserts the patent, there is no direct evidence to suggest it is doing so on behalf of an operating company against competitors.
8. Defensive aggregator (anti-NPE) — not present. The chain ends with Gigex, Inc., an asserting entity, not a defensive aggregator.

Verdict

NPE — high confidence

The assignment chain clearly exhibits multiple strong NPE signals. Gigex, Inc. is a known asserter, having filed multiple infringement suits [cite: Litigation summary]. The transfers involving Gigex.com, Inc. and Gigex, Inc. (REEL 017770/0527, REEL 017770/0529) point to shell-entity transfers, especially when considering the continuous use of the same in-house correspondent (R. T. Parker) for all later recordings. The cascading transfers on 2013-11-20 (REEL 017770/0527, REEL 017770/0529, REEL 017770/0530, REEL 017770/0532) further indicate a structured process typical of IP monetization efforts.

For verification, refer to the USPTO Patent Assignment Search for US5768528: https://assignmentcenter.uspto.gov/

Analysis of Prior Art for U.S. Patent No. 5,768,528

As a technical patent analyst, I have examined the prior art cited during the prosecution of U.S. Patent No. 5,768,528. The following analysis details the most relevant references and their potential impact on the patent's claims under 35 U.S.C. § 102, which pertains to novelty and anticipation. The filing date of the '528 patent is May 24, 1996, making any reference publicly available before this date potential prior art.

Based on the patent's file wrapper, no prior art references were cited by the examiner during the prosecution of this application. This is an unusual occurrence and may suggest that the examiner did not find any sufficiently relevant art to cite, or that the applicant successfully argued against any citations made. The patent itself does not list any "References Cited" on its face, which is also atypical.

However, a manual search for contemporaneous technologies and patents reveals several relevant documents that could have been considered prior art. For the purpose of this analysis, I will detail a key piece of prior art that was highly relevant at the time and would likely have been considered by an examiner today.

---

Key Relevant Prior Art:

PointCast, Inc. and the PointCast Network

PointCast was a pioneering "push" technology and news aggregation service that launched in 1996, prior to the '528 patent's filing date. The service delivered personalized news and information to users' computers.

• Description: The PointCast Network was a client-server system. Users would install the PointCast client software on their PCs. This client would connect to PointCast's servers at scheduled intervals or during periods of user inactivity (e.g., when a screensaver was active). The client would download news, stock quotes, weather, and other information based on the user's pre-selected "channels" or preferences. The downloaded content was then displayed to the user, often in a scrolling ticker format or as a dynamic screensaver.

• Relevance to US5768528:

  • Client-Server Architecture: PointCast utilized a client-server model to deliver online information, similar to the architecture described in the '528 patent.
  • Scheduled Delivery: The PointCast service operated on a scheduled basis, automatically connecting to the server to download updated information, a core concept in claim 1 and claim 14 of the '528 patent.
  • Channels and Personalization: The concept of "channels" corresponding to different content providers or topics is a key feature of PointCast and is directly analogous to the "channel selection menu" described in claim 32 of the '528 patent, where each channel corresponds to a publisher.
  • Scrolling Ticker: The PointCast client was famous for its use of a scrolling news ticker to display headlines, a specific element recited in claim 32.

• Potential Anticipation of Claims:

  • Claim 1: PointCast's system of storing publisher information on a server and having clients request information at scheduled times strongly anticipates the method described in claim 1. The client, by connecting, implicitly sends a request for new data. While PointCast may not have explicitly sent a "list of existing files," the server would determine which new information to send based on the user's channel subscriptions and the last update time.
  • Claim 14: The PointCast client software inherently maintained a schedule for downloading data. While the claim adds the element of a "log file" to track success and re-launch failed events, this could be considered an obvious implementation detail for a system designed for reliable, unattended operation.
  • Claim 32: The user interface of the PointCast Network appears to directly anticipate the elements of this claim. It featured a menu to select channels (publishers), a scrolling ticker display for content, and branding/logos for each channel.
  • Claim 38: This claim focuses on the method of recovering from an incomplete file transfer by sending only the missing portion. It is not clear from publicly available technical descriptions of the original PointCast service whether it employed this specific "resume" functionality using CRC codes for partial files. Therefore, while PointCast anticipates the broader system, it may not anticipate the specific error recovery method of claim 38. This specific method of ensuring data integrity would likely be considered the most novel aspect of the '528 patent in light of the PointCast system.

Conclusion

While the official file history of US5768528 does not contain cited art, the commercial and widely-known PointCast Network, which was operational before the patent's priority date, serves as highly relevant prior art. The PointCast system appears to anticipate the core concepts of scheduled information delivery, publisher channels, and the user interface described in independent claims 1, 14, and 32. The novelty of the '528 patent, when viewed against this prior art, would likely reside in the more detailed implementation of the data transfer protocol, specifically the method for resuming interrupted downloads as detailed in claim 38.

---

Disclaimer: This analysis is based on publicly available information and is for informational purposes only. A definitive legal determination of patent validity would require a formal invalidity search and legal analysis by a qualified patent attorney.

Analysis of Obviousness for U.S. Patent No. 5,768,528 under 35 U.S.C. § 103

This analysis evaluates whether the claims of U.S. Patent No. 5,768,528 would have been obvious to a person having ordinary skill in the art (a "POSITA") at the time of the invention, with a priority date of May 24, 1996. The analysis is based on a combination of the prior art reference identified previously—the PointCast Network—and other well-known technologies and protocols that existed before the patent's filing date.

Person Having Ordinary Skill in the Art (POSITA)

A POSITA in 1996 in the field of client-server software and internet technologies would have had a bachelor's degree in computer science or a related field, along with practical experience in network programming. This individual would be familiar with client-server architectures, data transfer protocols like FTP and TCP/IP, and common methods for ensuring data integrity, such as checksums and Cyclic Redundancy Checks (CRCs). They would also have been aware of emerging internet services and "push" technologies.

Combination of Prior Art

The primary argument for obviousness rests on combining the functionalities of the PointCast Network with established and widely used data transfer and error recovery protocols.

• Reference 1: The PointCast Network. As established in the prior art analysis, PointCast was a well-known service launched in February 1996 that embodied many of the core features of the '528 patent. It utilized a client-server model to deliver scheduled, channel-based news and information to a user's computer, often displayed in a scrolling ticker format.

• Reference 2: Data Transfer Protocols with Resume Capability (e.g., FTP). The File Transfer Protocol (FTP), one of the oldest internet protocols, had long-established mechanisms for transferring files. By the mid-1990s, many FTP clients and servers had the capability to resume interrupted downloads. This functionality was crucial given the slow and unreliable dial-up connections common at the time. A client could determine the size of a partially downloaded file and request the server to restart the transfer from that point.

• Reference 3: Data Integrity Verification using CRC. Cyclic Redundancy Check (CRC) was a well-established technique for detecting errors in data transmission, first proposed for communication networks in 1961. By the 1990s, CRCs were a standard feature in many communication protocols and file formats (e.g., PKZip, Ethernet) to ensure that transmitted data had not been corrupted. The process involved calculating a checksum for a block of data before transmission and having the receiver perform the same calculation to verify integrity.

Motivation to Combine

A POSITA in 1996, observing the PointCast system, would have recognized its reliance on the successful and complete transfer of data files over often-unreliable network connections. The PointCast service, which pushed content automatically in the background, was particularly vulnerable to interruptions (e.g., a user turning off their computer, or a dropped dial-up connection). A failed or corrupted download would result in an incomplete or broken user experience, a significant problem for a service designed to be seamless and automatic.

Therefore, a POSITA would have been highly motivated to improve the reliability of PointCast's data delivery mechanism. The most logical and direct way to achieve this would be to integrate a known, robust error-checking and recovery method into the system. The combination of a resume-download feature (like that in FTP) with a data integrity check (like CRC) would have been a predictable solution to a known problem.

Analysis of Independent Claims

• Claims 1, 14, and 32 (The System, the Client Method, and the UI):
  As argued in the prior art analysis, PointCast substantially anticipates the broader system concepts in these claims: a server storing publisher data, a client with a schedule for downloads, and a user interface with channels and a ticker. The remaining elements, such as the client sending a "list of existing files," are obvious implementations for managing updates. A server needs to know the client's state to send the correct new files, and sending a list of file names, sizes, and CRCs is a straightforward way to do so. A POSITA would have seen this as a standard method for synchronizing files between a client and a server. Therefore, the combination of PointCast's system with standard file synchronization techniques renders these claims obvious.

• Claim 38 (The Error Recovery Method):
  This claim describes the most specific technical detail: resuming an interrupted download by having the client report the size and CRC of the received portion. The server then verifies the CRC of its copy of that initial portion and, if it matches, sends only the remainder of the file.

  This method is a clear combination of the principles of Reference 2 (resume capability) and Reference 3 (CRC for integrity).

  1. The concept of resuming a download based on the size of the partially received file was already known from protocols like FTP.
  2. The use of CRC to verify that a block of data is uncorrupted was also standard practice.

  A POSITA, tasked with creating a reliable resume-download feature, would naturally consider how to ensure the partially downloaded file wasn't corrupt before appending the rest of the data. Simply resuming based on file size alone is risky; if the initial part is corrupted, the final combined file will also be useless. The logical next step would be to verify the integrity of the received portion. Using a CRC for this verification would have been an obvious choice for a POSITA in 1996. The client would calculate the CRC of the part it has, send it to the server along with the size, and the server would do the same check. This ensures that both client and server are working from an identical, uncorrupted starting point before completing the transfer. This is not an inventive leap but a logical and predictable combination of known techniques to solve a known problem.

Conclusion

The core concepts of the client-server architecture, scheduled delivery, and user interface of US Patent 5,768,528 were largely present in the publicly known PointCast Network before the patent's priority date. The key inventive feature appears to be the specific method for resuming interrupted downloads with data integrity verification as described in claim 38.

However, this method represents an obvious combination of two well-established technologies: the ability of data transfer protocols to resume downloads and the use of CRC for error detection. A person of ordinary skill in the art in 1996, faced with the challenge of making a PointCast-like service more reliable over unstable internet connections, would have been motivated to combine these known elements in the manner described. Therefore, the claims of US patent US5768528 would likely be rendered obvious under 35 U.S.C. § 103.

Analysis of Patent Term, Adjustments, and Family for U.S. Patent No. 5,768,528

Date of Analysis: April 30, 2026

This analysis details the term, continuity data, and related family members for U.S. Patent No. 5,768,528.

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

• PTA/PTE Status: U.S. Patent No. 5,768,528 is not eligible for Patent Term Adjustment (PTA). The provisions for PTA were established by the American Inventors Protection Act of 1999 and apply to applications filed on or after May 29, 2000. Since the '528 patent was filed on May 24, 1996, it predates the enactment of the PTA system. There is no indication of any Patent Term Extension (PTE), which is typically granted for delays related to regulatory review and is uncommon for software patents.

Continuity and Divisional Applications

A review of the USPTO's public records for U.S. Patent No. 5,768,528 indicates that this patent has no parent or child applications.

• Continuation Applications: There are no continuation applications that claim priority to the '528 patent.
• Divisional Applications: There are no divisional applications that claim priority to the '528 patent.

This indicates that the application which resulted in the '528 patent was a standalone filing and was not part of a broader prosecution strategy involving subsequent continuing applications in the United States.

Patent Family Members

While there are no direct continuations or divisionals in the U.S., the application for the '528 patent served as a priority document for international filings. The known patent family members are:

• United States (US):

  • Application Number: US08/653,611 (Filed: May 24, 1996)
  • Patent Number: US5768528A (Granted: June 16, 1998)

• Australia (AU):

  • Application Number: AU26083/97A (Filed: April 8, 1997)
  • Title: Client-server system for delivery of on-line information

• World Intellectual Property Organization (WO):

  • Application Number: PCT/US1997/005691 (Filed: April 8, 1997)
  • Publication Number: WO1997045786A1
  • Title: Client-server system for delivery of on-line information

These filings indicate an effort to seek patent protection in multiple jurisdictions based on the original U.S. application.

Projected Expiration Date

The expiration date of a U.S. patent is determined by its filing date and the laws in effect at that time.

• Applicable Law: For patent applications filed on or after June 8, 1995, the patent term is 20 years from the earliest effective filing date.
• Filing Date: The application for US5768528 was filed on May 24, 1996.
• Calculation: Adding 20 years to the filing date (May 24, 1996) results in a projected expiration date.

Projected Expiration Date: May 24, 2016

Based on this calculation, U.S. Patent No. 5,768,528 has expired and is no longer in force as of the date of this analysis. The legal status is "Expired - Lifetime." This confirms that the patent completed its full statutory term and was not abandoned for failure to pay maintenance fees.

---

Disclaimer: This analysis is for informational purposes only and is based on publicly available data from the USPTO and other patent databases. It does not constitute a legal opinion on the patent's status. The USPTO does not calculate official expiration dates.

Defensive Disclosure and Technical Variations of U.S. Patent No. 5,768,528

Publication Date: May 6, 2026
Subject: Technical Disclosures Related to Client-Server Information Delivery Systems
Purpose: This document discloses a series of technical variations, enhancements, and alternative implementations related to the system and methods described in U.S. Patent No. 5,768,528, titled "Client-server system for delivery of online information." The purpose of this disclosure is to place these concepts into the public domain, thereby establishing them as prior art for any future patent applications.

---

Section 1: Derivatives of the Core Server/Client Data Transfer Method (Claims 1, 14, 38)

Axis 1: Component Substitution

Derivative 1.1: Quantum-Resistant File Identification and Verification

• Enabling Description: The Cyclic Redundancy Check (CRC) file identification code is replaced with a cryptographic hash derived from a Quantum Key Distribution (QKD) protocol. A server and subscriber client first establish a shared secret key using a QKD channel (e.g., BB84 protocol). For file transfer verification, particularly for resuming interrupted downloads as in Claim 38, the identification code sent by the subscriber is not a simple CRC of the partial file. Instead, it is a SHA-3 hash of the partial file's content, which is then XORed with a one-time pad segment from the pre-shared quantum key. The server performs the same operation on its version of the file segment. A match provides quantum-resistant assurance that the partial file is both intact and authentic, preventing spoofing.
• Diagram:

  sequenceDiagram
      participant Client
      participant Server
      participant QKD_Channel
      Client->>QKD_Channel: Establish Shared Secret Key
      Server->>QKD_Channel: Establish Shared Secret Key
      Note over Client, Server: Pre-download key exchange complete
      Client->>Server: Request File Download
      Server-->>Client: Transmit File (interrupted)
      Client->>Client: 1. Calculate SHA-3 hash of partial file
      Client->>Client: 2. XOR hash with QKD one-time-pad
      Client->>Server: Send(FileSize, Quantum-Verified-Hash)
      Server->>Server: 1. Get corresponding file segment
      Server->>Server: 2. Calculate SHA-3 hash of segment
      Server->>Server: 3. XOR hash with QKD one-time-pad
      Server->>Server: Compare Hashes
      alt Hashes Match
          Server-->>Client: Transmit remaining portion of file
      else Hashes Do Not Match
          Server-->>Client: Request full re-transmission
      end
  

Derivative 1.2: Neuromorphic Predictive Scheduling

• Enabling Description: The static schedule of events file is replaced by a dynamic, predictive scheduling system managed by a neuromorphic processing unit (NPU) on the server. The NPU implements a spiking neural network that continuously processes real-time data streams, including the subscriber's historical access patterns, current network latency metrics for the subscriber's ISP, time-of-day, and the publisher's content release cadence. The NPU predicts optimal, personalized download windows for each subscriber to maximize transfer success and minimize network cost. The schedule is no longer a fixed file but a probabilistic model that pushes a "next optimal time" to the client after each successful or failed connection.
• Diagram:

  flowchart TD
      subgraph Server
          A[Real-time Data Streams<br/>- User History<br/>- Network Latency<br/>- Publisher Cadence] --> B{Neuromorphic Processor (NPU)};
          B -- Predicts --> C(Probabilistic Schedule Model);
          C -- Pushes --> D[Next Optimal Download Time];
      end
      subgraph Client
          E[Client Scheduler] -- Receives --> D;
          E -- Triggers at Optimal Time --> F(Initiate Connection);
      end
      Server -- Transmits Data --> Client;
      F --> G{Download Success?};
      G -- Yes/No --> H(Send Result to Server);
      H --> A;
  

Axis 2: Operational Parameter Expansion

Derivative 2.1: Interplanetary Data Synchronization Protocol

• Enabling Description: The system is adapted for synchronizing mission-critical data (e.g., habitat telemetry, geological surveys) between a Mars habitat (subscriber) and Earth-based Mission Control (server). The protocol explicitly accounts for communication windows and extreme latency (4 to 24 minutes one-way). The schedule of events file becomes a "communications window manifest" based on orbital mechanics. The error-recovery mechanism of Claim 38 is modified to handle multi-day interruptions. The client stores a journal of received and verified data blocks. Upon re-establishing a connection, the client transmits a bitfield representing the journal of successfully received blocks, allowing the server to calculate the exact set of missing blocks and transmit them without requiring a CRC check of a contiguous partial file. Forward Error Correction (FEC) using LDPC codes is applied to all transmissions to mitigate data corruption from cosmic radiation.
• Diagram:

  sequenceDiagram
      participant Mars_Client
      participant Earth_Server
      Note over Mars_Client, Earth_Server: Latency: 4-24 mins each way
      Mars_Client->>Earth_Server: Request Data Sync (during comms window)
      Earth_Server-->>Mars_Client: Transmit File Segments (with FEC)
      Note right of Mars_Client: Connection Lost (e.g., dust storm, planet rotation)
      Mars_Client->>Mars_Client: Store received/verified segments in journal
      loop Next Comms Window (Hours/Days Later)
          Mars_Client->>Mars_Client: Generate bitfield from journal
          Mars_Client->>Earth_Server: Request Resume, send(FileID, Block_Bitfield)
      end
      Earth_Server->>Earth_Server: Compare bitfield to original file map
      Earth_Server-->>Mars_Client: Transmit only missing segments
  

Axis 3: Cross-Domain Application

Derivative 3.1: Agricultural Technology (AgTech) Drone Fleet Management

• Enabling Description: A central farm server pushes mission-critical data files (e.g., multispectral imagery analysis, variable-rate fertilization maps, firmware updates) to a fleet of autonomous agricultural drones. The drones, acting as subscribers, connect to the server via a mesh Wi-Fi network when they return to their charging pads. The connection is often intermittent. The drone client transmits a list of its current file versions (filename, size, SHA-256 hash). The server compares this to the master repository and transmits only the delta (new or updated files). The error-resume protocol is used for large map files to ensure that a drone does not depart for a mission with a corrupted or incomplete instruction set.
• Diagram:

  graph TD
      subgraph Farm_Control_Hub
          Server[Central Server]
          Repo[Mission File Repository]
          Server --- Repo
      end
      subgraph Drone_Fleet
          Drone1[Drone A<br/>- Client Software]
          Drone2[Drone B<br/>- Client Software]
          Drone3[Drone C<br/>- Client Software]
      end
      Pad1[Charging Pad 1] -- Wi-Fi Mesh --> Server
      Pad2[Charging Pad 2] -- Wi-Fi Mesh --> Server
      Pad3[Charging Pad 3] -- Wi-Fi Mesh --> Server
      Drone1 -- Lands on --> Pad1
      Drone2 -- Lands on --> Pad2
      Drone3 -- Lands on --> Pad3
      Pad1 -- Connection established --> ClientA_Request{Drone A requests sync}
      ClientA_Request -- "filename, size, hash" --> Server
      Server -- "Sends delta files/patches" --> ClientA_Request
  

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Driven Predictive Content Delivery

• Enabling Description: An AI/ML model on the server analyzes each subscriber's profile, content consumption history, and real-world event triggers (via news APIs) to predict which files the subscriber will need. The system pre-emptively pushes these predicted files to a local cache on the subscriber's device during off-peak hours. The scheduled download event is then transformed from a full download into a lightweight "manifest verification" event. The client simply reports the hashes of the files in its predictive cache, and the server sends a small confirmation message or a patch for any files that were updated since being cached. This dramatically reduces perceived download times.
• Diagram:

  flowchart LR
      subgraph Server
          A[AI/ML Engine] --> B{Predicts User Needs};
          C[Publisher Content] --> A;
          D[Network & User Data] --> A;
          B --> E[Push Predictive Cache];
      end
      subgraph Subscriber_Device
          F[Local Predictive Cache]
          G[Client Agent]
      end
      E -- Off-peak hours --> F;
      G -- Scheduled "download" --> H((Verify Cache Manifest));
      H -- "List of cached file hashes" --> Server;
      Server -- "Confirmation or small patch" --> H;
      I[User] --> J{Requests Content};
      J -- "Instant load" --> F;
  

Derivative 4.2: Blockchain-Verified File Provenance and Integrity

• Enabling Description: The system is integrated with a permissioned blockchain to provide immutable proof of file origin and integrity. When a publisher uploads a file to the server, the server calculates the file's hash (e.g., IPFS CID) and registers it in a smart contract on the blockchain, creating a permanent record of the file's content, publisher, and timestamp. When the subscriber client receives a file, it re-calculates the hash and queries the smart contract to verify it matches the publisher's registered version. For resumed downloads, the CRC is supplemented with a Merkle proof; the client provides the root hash of the partial file's Merkle tree, which the server can efficiently verify against the full file's Merkle tree.
• Diagram:

  sequenceDiagram
      participant Publisher
      participant Server
      participant Blockchain
      participant Subscriber
      Publisher->>Server: Upload File
      Server->>Server: Calculate File Hash (CID)
      Server->>Blockchain: Register(File_CID, Publisher_ID) via Smart Contract
      Subscriber->>Server: Request File
      Server-->>Subscriber: Transmit File
      Subscriber->>Subscriber: Calculate received file's hash
      Subscriber->>Blockchain: Verify(File_CID)
      alt Verification OK
          Subscriber->>Subscriber: Install File
      else Verification Fails
          Subscriber->>Subscriber: Discard File, Report Error
      end
  

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation for Metered/Unstable Networks

• Enabling Description: The subscriber client actively monitors network status (e.g., using netinfo API) and device power level. If it detects a metered connection (non-WiFi), low signal strength (<2 bars), or low battery (<20%), it enters a "graceful degradation" mode. It sends a special flag in its information request to the server. The server responds by sending a low-fidelity version of the publication: text-only files, images replaced with low-resolution placeholders (e.g., 10KB LQIP), and video/audio files replaced with metadata-only stubs. The download schedule is also automatically deferred until a stable, unmetered network is available.
• Diagram:

  stateDiagram-v2
      [*] --> Stable_Network
      Stable_Network: Full content downloads
      Stable_Network --> Low_Power: Battery < 20%
      Stable_Network --> Unstable_Network: Low signal or metered network detected
      Low_Power --> Stable_Network: Device charging
      Unstable_Network --> Stable_Network: Stable WiFi detected
      state Degraded_Mode {
          direction LR
          Low_Power
          Unstable_Network
          [*] --> Request_Low_Fi: Client sends 'degraded' flag to server
          Request_Low_Fi --> Receive_Low_Fi: Server sends text-only, LQIPs
          Receive_Low_Fi --> Defer_Schedule: Postpone next check
      }
  

---

Section 2: Derivatives of the User Interface (Claim 32)

Derivative 6.1: Augmented Reality (AR) Contextual Channel Display

• Enabling Description: The user interface is implemented as an augmented reality overlay on smart glasses. The "channel selection menu" is context-aware and triggered by the user's gaze. For example, looking at a stock market terminal brings up the "Bloomberg" channel. The "scrolling ticker" is not fixed to the screen but is world-locked, appearing as a persistent holographic display in the user's environment. The publisher's logo is a 3D object that anchors the ticker in place. The user changes channels through gesture control (e.g., a swiping motion) or voice commands.
• Diagram:

  flowchart TD
      A[User wearing AR Glasses] -- Gazes at --> B(Object of Interest<br/>e.g., a Tesla car);
      C[AR System] -- Recognizes object --> D{Trigger Contextual Channel};
      D -- "Automotive News Channel" --> E[Display 3D Logo & Ticker];
      E -- World-locked in user's view --> F((Holographic Ticker scrolls news about Tesla));
      A -- Performs swipe gesture --> G{Change Channel};
      G -- "Financial News" --> H((Ticker content switches to TSLA stock price));
  

---

Section 3: Combination with Open-Source Standards

Combination 1: Delivery System Over the Tor Network

• Enabling Description: The entire client-server communication protocol is tunneled through The Onion Router (Tor) open-source network to provide privacy and anonymity for subscribers. The server hosts its service as a Tor onion service, and the subscriber client is configured to route all its traffic through a local Tor proxy. The scheduled connection and error-resume protocol function as described, but the underlying TCP/IP connection is anonymized. This is applicable for publishers and subscribers in environments with heavy censorship or surveillance, ensuring that both the content being delivered and the identity of the subscriber are protected.
• Diagram:

  graph TD
      subgraph Subscriber
          A[Client Application] -- traffic --> B(Local Tor Proxy)
      end
      subgraph Internet
          C(Tor Entry Node)
          D(...)
          E(Tor Exit Node)
          B --> C --> D --> E
      end
      subgraph Server_Infrastructure
          F[Server Onion Service]
      end
      E --> F
  

Combination 2: Using WebSockets for Real-Time Ticker Updates

• Enabling Description: While the main file downloads operate on the scheduled request-response model, the scrolling ticker display (Claim 32) is powered by a persistent WebSocket connection (RFC 6455). After the initial content download, the client opens a WebSocket connection to a specific ticker service endpoint on the server. The server can then push real-time, low-latency updates (e.g., stock price changes, sports scores) to the ticker without waiting for the next scheduled download event. This creates a hybrid system combining scheduled bulk downloads with a real-time stream for immediate updates, using an open web standard.
• Diagram:

  sequenceDiagram
      participant Client
      participant Server
      Client->>Server: Initiate scheduled download (HTTP)
      Server-->>Client: Respond with publication files
      Client->>Server: Open WebSocket connection for Ticker
      Server-->>Client: Connection established
      loop Real-time
          Server-->>Client: Push Ticker Update (JSON payload)
          Client->>Client: Update scrolling ticker UI
      end
  

Combination 3: Integration with ActivityPub Federated Protocol

• Enabling Description: The system is decentralized using the W3C ActivityPub standard. Publishers run their own ActivityPub-compatible servers (e.g., Mastodon, PeerTube instances). A subscriber's client is an ActivityPub client that "follows" various publisher actors. The "server" component of the patent becomes a personalized caching and delivery agent that pulls content from the federated network on behalf of the user. This agent subscribes to the user's followed publishers, aggregates the content, and then uses the scheduled, resumable download protocol to push a personalized "digest" to the user's end device. This combines the open, decentralized social networking standard with the patent's efficient and reliable client-side delivery mechanism.
• Diagram:

  graph LR
      P1[Publisher 1<br/>(ActivityPub Server)]
      P2[Publisher 2<br/>(ActivityPub Server)]
      P3[Publisher 3<br/>(ActivityPub Server)]
  
      subgraph User's Ecosystem
          Agent[Personal Caching & Delivery Agent]
          Client[End-User Client Device]
          Agent -- Follows --> P1
          Agent -- Follows --> P2
          Agent -- Follows --> P3
          Agent -- Scheduled/resumable push --> Client
      end
      P1 -- Pushes content --> Agent
      P2 -- Pushes content --> Agent
      P3 -- Pushes content --> Agent