Obviousness — US Patent 5978773

Obviousness Analysis of U.S. Patent 5,978,773 under 35 U.S.C. § 103

This analysis examines whether the invention claimed in U.S. Patent 5,978,773 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time the invention was made, based on the prior art references previously identified. The legal standard for obviousness is defined in 35 U.S.C. § 103, which prevents the patenting of an invention if the differences between the invention and the prior art are such that the invention as a whole would have been obvious to a PHOSITA.

1. Definition of a Person Having Ordinary Skill in the Art (PHOSITA)

At the time of the invention (priority date: June 20, 1995), a PHOSITA would be a software developer or computer engineer with:

A bachelor's degree in computer science or a related field.
Two to three years of professional experience in client-server application development, networking, and database management.
Familiarity with the state of the commercial internet, including the World Wide Web, early web browsers (e.g., NCSA Mosaic, Netscape Navigator), HTTP, and the structure of Uniform Resource Locators (URLs).
Working knowledge of data capture technologies, such as barcode scanners, and established product identification standards like the Uniform Product Code (UPC).

2. The Problems to Be Solved

The '773 patent sought to solve clear problems existing in 1995 for connecting consumers with online content related to physical products:

Manual Entry of URLs: URLs were often long, complex, and prone to error when typed manually.
Impracticality of Barcoding URLs: Encoding long URLs directly into barcodes was impractical, as it would result in very long symbols that would clutter product packaging and advertisements.
Static Nature of Printed URLs: If a company's URL changed, any physical product, package, or advertisement bearing the old URL would become obsolete, leading to broken links and wasted marketing efforts.

3. Combination of Prior Art

The independent claims of U.S. Patent 5,978,773 would have been obvious to a PHOSITA by combining the teachings of U.S. Patent 5,115,326 ('326 patent) and U.S. Patent 5,420,943 ('943 patent) with the common knowledge of relational database principles.

U.S. Patent 5,115,326 ('326 patent): This reference teaches the core concept of using a machine-readable barcode to encode a network address (an email address) to automate a network action (routing a fax). This establishes the idea of scanning a physical document to initiate a digital communication over a network.
U.S. Patent 5,420,943 ('943 patent): This reference teaches a universal input method for barcode scanners, allowing them to function like a keyboard. This makes it simple to input scanned data into any standard computer application, such as a web browser's address bar or a database query form, without special software.
Common Knowledge of Databases: In 1995, using a database to create a layer of indirection was a fundamental and widespread principle in computer science. The concept of using a unique, stable identifier (a "primary key" such as an employee ID or a part number) to look up other, more complex or changeable data (such as a name, address, or price) was elementary.

4. Motivation to Combine and Reasonable Expectation of Success

A PHOSITA, faced with the problems outlined above, would have been motivated to combine these elements for the following reasons:

Solving the Long URL Problem: The '326 patent suggests encoding an address directly. A PHOSITA would immediately recognize that this approach does not scale to the long URLs of the World Wide Web. The obvious solution to avoid a long, product-specific barcode is to use a short, pre-existing identifier that is already on the product: the UPC. The '943 patent provides the seamless mechanism to input this UPC into a computer.
Solving the Changing URL Problem: The most significant motivation is to solve the problem of static, printed URLs. A PHOSITA would know that storing the relationship between the stable UPC and the changeable URL in a central database is the standard, textbook solution for managing such data. By doing so, the link can be updated in one place (the database) without altering the millions of physical products in circulation. This creates a persistent and manageable link between the physical and online worlds.

The logical train of thought for a PHOSITA would be as follows:

"We want to link a physical product to a website. The '326 patent shows we can use a barcode to initiate a network action."
"However, directly encoding a URL into a barcode is clumsy and problematic because URLs are long and they change. This will be a maintenance nightmare."
"What if we don't encode the URL itself? Every product already has a short, unique, machine-readable identifier: the UPC."
"We can use the UPC as a key. Where do we store the URL that this key points to? In a database, of course. That is what databases are for—linking one piece of data to another."
"So, the user scans the UPC. The '943 patent shows that the scanner can just 'type' the UPC numbers into our application. The application then sends this UPC to a server, which looks it up in our database, finds the current URL, and sends it back to the user's browser."

This combination is not a leap of inventive genius but rather the application of routine engineering and computer science principles to a new commercial context (the World Wide Web). There was a clear market need for this functionality, and the tools and concepts to build it were readily available and well understood. Therefore, a PHOSITA would have had a reasonable expectation of success in combining these known elements to create the system described in the '773 patent.

Conclusion

The core inventive concept of U.S. Patent 5,978,773—using a database to link a standard product identifier (UPC) to a network address (URL)—represents an obvious combination of prior art elements. The prior art taught the use of barcodes for network actions and the seamless input of barcode data into computers. The motivation to use a database for indirection was driven by the clear and pressing technical and business problems associated with long and changing URLs. A Person Having Ordinary Skill in the Art in 1995 would have found this combination to be a logical and straightforward solution to the problem at hand.