Obviousness

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.