Obviousness

As a senior US patent analyst, I am providing an analysis of the obviousness of US patent 8,131,597 under 35 U.S.C. § 103, based on the state of the art at the time of the invention.

Analysis of Obviousness under 35 U.S.C. § 103

Under 35 U.S.C. § 103, a patent claim is unpatentable if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (PHOSITA). An obviousness rejection typically involves combining two or more prior art references to show that all elements of the claimed invention were known, and that a PHOSITA would have been motivated to combine them to achieve the claimed invention with a reasonable expectation of success.

Person Having Ordinary Skill in the Art (PHOSITA)

At the time of the invention (priority date: June 20, 1995), a PHOSITA would have been a computer scientist or software engineer with a bachelor's degree in a relevant field and a few years of experience in client-server architecture, database management, and network programming. This individual would have been familiar with the internet, the nascent World Wide Web, browsers like NCSA Mosaic, the function of URLs, and common data-entry technologies such as barcode scanning used in retail and logistics.

Prior Art & Rationale for Combination

The independent claims (1, 12, 22, and 27) of the '597 patent describe a system of indirection: using a machine-readable index (like a UPC) on an object to look up a network pointer (like a URL) in a remote database, which is then used to access a final destination. The following combination of prior art concepts, widely known before 1995, renders these claims obvious.

• Reference A: Standard Client-Server Database Systems. By 1995, client-server architectures were fundamental in computing. It was commonplace for a client application to send a key (e.g., a customer ID, part number, or product code) over a network to a server. The server would use this key to query a database and return associated data (e.g., customer details, inventory levels, or product price) to the client. This teaches the core elements of transmitting a key/index to a remote server for a database lookup and receiving the corresponding data back.

• Reference B: Barcode-based Data Entry for Database Lookups. The use of barcode scanners to read Uniform Product Codes (UPCs) was ubiquitous in retail point-of-sale (POS) systems for over a decade before 1995. A scanner would "machine-read" a barcode symbol, and the resulting UPC number would be used as a key to look up the product's price and description in a database. This teaches the specific input method of machine-reading a standard code on an article of commerce to serve as the key (the "index") for a database lookup.

• Reference C: The World Wide Web Architecture. The World Wide Web, though young, was well-established by 1995. The concepts of a Uniform Resource Locator (URL) as a unique address or "pointer" for a resource, and of a web browser using a URL to directly access a remote information computer (a web server), were foundational. The problem the '597 patent purports to solve—that URLs are long and tedious to type manually from printed materials—was also a known usability issue at the time.

Motivation to Combine

A PHOSITA in 1995, faced with the known problem of cumbersome URL entry, would have been motivated to combine these elements for a predictable and obvious solution.

1. Combining A and B: It was already standard practice to combine the database lookup model (Reference A) with barcode input (Reference B) for efficiency and accuracy. Replacing manual keyboard entry of a product code with a barcode scan in any client-server lookup system was an obvious design choice to improve usability.

2. Combining (A+B) with C: With the rise of commercial activity on the web, companies began advertising their URLs on products and in print (as acknowledged in the '597 patent's background). A PHOSITA would have recognized that a URL (Reference C) is simply a string of text data. The existing barcode-driven lookup systems (A+B) were designed precisely to retrieve text and numerical data associated with a scanned UPC. Therefore, it would have been an obvious extension to store a URL as just another piece of data in the product database, alongside the price and description.

The motivation would be to leverage the existing, convenient, and widespread infrastructure of UPCs and barcode scanners to solve the new problem of getting users to a website without manual typing. The system works as follows: a user scans the UPC (per B), the UPC is sent to a server for a database lookup (per A), and the server returns the corresponding URL (a new data type from C). The user's browser then uses this returned URL to access the site (per C). This combination represents the application of a known technique (barcode-driven database lookups) to a new but analogous problem (accessing a web resource) with a predictable result.

Conclusion on Obviousness

• Claim 1 (Method of a user computing system): This claim is rendered obvious. The method steps of machine-reading an index (B), transmitting it for a database lookup (A), receiving a pointer (A+C), and using the pointer to connect to a remote computer (C) are all taught by the combination.

• Claim 12 (User computing system): This claim, which describes the user-side apparatus, is obvious for the same reasons. A system programmed to perform an obvious method is itself obvious.

• Claim 22 (Method of a remote server): This claim, detailing the server's actions, is obvious. Receiving an index, looking up a pointer in a database, and returning it (A+B+C) is the necessary server-side component of the overall obvious method.

• Claim 27 (Remote server computer): This claim for the server apparatus is obvious as it describes the hardware and database programmed to carry out the obvious server-side method.

In summary, the core inventive concept of the '597 patent—using a UPC as an index to retrieve a URL from a remote database—would have been obvious to a person of ordinary skill in the art in 1995. The invention is a straightforward application of well-known barcode scanning techniques and client-server database principles to the then-emerging domain of the World Wide Web.