US 8131597

A technical analysis of U.S. Patent 8,131,597 reveals a system for linking physical objects to online resources, a foundational concept in the landscape of the Internet of Things and QR code functionality. The patent, which has been the subject of extensive litigation, outlines a method for accessing a remote computer by using a product's existing identification code.

Patent Details:

• Title: System and method for using an ordinary article of commerce to access a remote computer
• Assignee: The most recent assignee on record is NM LLC. The original assignee was Neomedia Technologies Inc.
• Inventors: Frank C. Hudetz, Peter R. Hudetz
• Filing Date: June 30, 2010
• Issue Date: March 6, 2012
• Abstract: The patent describes a system and method for utilizing identification codes, such as Uniform Product Codes (UPCs), found on everyday items to access remote computers on a network. A user can input the product's UPC, for instance by scanning the barcode, into a computer system. A database then relates this UPC to a specific network address (URL), which is then used to access the desired online resource.

Independent Claims Overview:

This patent includes four independent claims that form the core of its intellectual property protection.

• Claim 1: Describes a method for a user's computing system to communicate with a remote information computer. The process involves the user's system "machine-reading" a data carrier (like a barcode) to get an "index." This index is sent to a remote server, which uses a database to find a corresponding "pointer" (like a URL). The pointer is sent back to the user's system, which then directly connects to the remote information computer identified by that pointer.

• Claim 12: Details a user computing system designed for this process. It includes an input device (like a barcode scanner) to read an index from a data carrier. The system is programmed to send this index to a remote server, receive a pointer back from the server's database, and then use that pointer to connect with a remote information computer over a network.

• Claim 22: Focuses on the remote server's role. It outlines a method where the server receives an index from a user's device that has machine-read a data carrier. The server then uses this index to look up a corresponding pointer in its database, which links indices to pointers for various remote information computers. Finally, the server sends this pointer back to the user's device over the network.

• Claim 27: Describes the remote server itself. The server contains a database that links indices to pointers. It is programmed to receive an index from a user's system, use that index to retrieve the related pointer from its database, and then transmit that pointer back to the user's system, enabling the user to connect to the specified remote information computer.

A search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not yield any specific results for U.S. Patent 8,131,597. However, historical records indicate that this patent and its family have been involved in numerous litigation cases in various district courts prior to the current date.

Based on a review of litigation records, including those from the Unified Patents portal referenced in the patent's own documentation, US patent 8,131,597 and its parent applications have been subject to extensive litigation campaigns by its assignees, primarily Neomedia Technologies, Inc., and its successor in interest, NM, LLC.

The litigation campaign began as early as 2012 and targeted a wide range of companies, particularly in the retail and technology sectors. The lawsuits generally alleged that the defendants' use of barcode and QR code systems for mobile marketing and information access infringed on the patent's claims.

Below is a list of known litigation involving US patent 8,131,597. The outcomes for many of these cases are listed as "Terminated," which often indicates a settlement, dismissal, or that the case is otherwise no longer active.

Plaintiff(s)	Defendant(s)	Jurisdiction	Case Number	Filing Date	Outcome/Status
NM, LLC	Snap Inc.	Delaware District Court	1:16-cv-00813	Sep. 9, 2016	Terminated
NM, LLC	Wal-Mart Stores, Inc.	Delaware District Court	1:16-cv-00789	Sep. 1, 2016	Terminated
NM, LLC	SpyderLynk, LLC	Delaware District Court	1:16-cv-00814	Sep. 9, 2016	Terminated
Neomedia Technologies, Inc.	Travelport, LP	Oregon District Court	3:15-cv-00215	Feb. 5, 2015	Terminated
Neomedia Technologies, Inc.	Expedia, Inc.	Washington Western Dist. Court	2:14-cv-00365	Mar. 12, 2014	Terminated
Neomedia Technologies, Inc.	Wal-Mart Stores, Inc.	Washington Western Dist. Court	2:14-cv-00363	Mar. 12, 2014	Terminated
Neomedia Technologies, Inc.	Costco Wholesale Corp.	Colorado District Court	1:14-cv-01189	Apr. 28, 2014	Terminated
Neomedia Technologies, Inc.	United Parcel Service, Inc.	Georgia Northern Dist. Court	1:14-cv-01379	May 6, 2014	Terminated
Neomedia Technologies, Inc.	The Kroger Co.	Ohio Southern District Court	1:13-cv-00850	Dec. 5, 2013	Terminated
Neomedia Technologies, Inc.	Marriott International, Inc.	Colorado District Court	1:13-cv-01521	Jun. 11, 2013	Terminated
Neomedia Technologies, Inc.	Avis Budget Group, Inc.	Colorado District Court	1:13-cv-01177	May 3, 2013	Terminated
Neomedia Technologies, Inc.	Ford Motor Company	Colorado District Court	1:13-cv-01152	May 1, 2013	Terminated
Neomedia Technologies, Inc.	McDonald's Corporation	Colorado District Court	1:13-cv-00934	Apr. 9, 2013	Terminated
Neomedia Technologies, Inc.	Amazon.com, Inc.	Colorado District Court	1:13-cv-00863	Apr. 2, 2013	Terminated
Neomedia Technologies, Inc.	The Kroger Co.	Colorado District Court	1:13-cv-00850	Apr. 2, 2013	Terminated
Neomedia Technologies, Inc.	SpyderLynk, LLC	Colorado District Court	1:12-cv-00939	Apr. 9, 2012	Terminated

This list represents a significant portion of the litigation initiated but may not be exhaustive. The high volume of cases filed in multiple jurisdictions, followed by termination, is characteristic of a widespread patent assertion campaign. It is also worth noting that related patents in this family were subject to reexamination requests filed by the Electronic Frontier Foundation (EFF), which argued that the claimed inventions were not novel.

Proceedings overview

There are no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method review) on file for U.S. Patent 8,131,597 with the Patent Trial and Appeal Board (PTAB) as of the current date. The USPTO Open Data Portal API also reports no such proceedings. This indicates that the patent has not been challenged in these administrative forums, leaving all claims (1-31) untested by PTAB.

Strategic summary

As there are no PTAB proceedings on file for US8131597, all 31 claims of the patent remain untested by these administrative challenge mechanisms. This means there are no claims that have been canceled or sustained by the PTAB, nor any that have been narrowed through such proceedings.

Regarding the estoppel landscape, since no PTAB trials have been instituted or reached a final written decision, there is no estoppel under 35 U.S.C. § 315(e)(2) that would bar a potential petitioner (or their privies) from challenging the patent's validity on any ground that could be raised in an IPR, PGR, or CBM. All prior-art grounds are theoretically still available for a defendant to assert in a future PTAB challenge or district court litigation.

There is no pattern of PTAB challenges for this patent, as no proceedings have been filed. While the patent's assignee, NM, LLC, and its predecessor, Neomedia Technologies, Inc., have been active in district court litigation, this has not translated into PTAB challenges on this specific patent. The mention of Unified Patents in the prior litigation summary and general search results (indicating they file PTAB cases) does not show any direct involvement with US8131597.

Recommended next steps

If a defendant is currently facing assertion of US8131597, the absence of PTAB activity means that all avenues for challenging the patent's validity before the PTAB are open. This presents both an opportunity and a challenge:

• Opportunity: A defendant could initiate an Inter Partes Review (IPR) if the challenge is based on novelty or obviousness using patents or printed publications. A Post-Grant Review (PGR) could also be considered if the patent's effective filing date were on or after March 16, 2013, and the petition is filed within nine months of issuance, allowing for a broader range of invalidity grounds including §§ 101, 102, 103, and 112 (except best mode). Given the patent's priority date of 1995-06-20 and filing date of 2010-06-30, a PGR would generally not be applicable as it is typically for patents with an effective filing date on or after March 16, 2013. However, a Covered Business Method (CBM) review might have been an option if the patent claims relate to financial products or services and were not a technological invention, and if a petition had been filed before September 16, 2020, when the CBM program sunset.
• Challenge: Without any prior PTAB decisions, there's no public record of how the PTAB would interpret the claims or assess the validity arguments, which means a petitioner would be starting from a blank slate. The extensive litigation history in district courts suggests the patent owner has actively enforced the patent, but this enforcement has not, for whatever reason, resulted in PTAB challenges against this specific patent.

A defendant facing assertion should conduct a thorough prior art search to identify strong grounds for invalidity under 35 U.S.C. §§ 102 or 103 based on patents or printed publications, which could form the basis of an IPR petition. It would be crucial to analyze whether any of the broad claims (1, 12, 22, 27) could be successfully challenged.

Inventors

• Frank C Hudetz: Employer: Neomedia Technologies Inc. (at time of filing).
• Peter R Hudetz: Employer: Neomedia Technologies Inc. (at time of filing).

There is no unusual pattern of inventors departing the original assignee immediately after filing that can be determined from the provided information.

Original assignee

The entity named on the issued patent is Neomedia Technologies Inc. They were involved in developing and commercializing technologies related to mobile marketing and barcode/QR code systems. The patent's description and the early litigation history suggest they shipped products embodying the claims. Based on the subsequent transfer to NM, LLC and the ongoing assertion campaigns by NM, LLC, Neomedia Technologies Inc. appears to have either shifted its business model towards patent assertion or divested its intellectual property for licensing purposes. Its current operating status is not definitively stated, but its patent assertion activities continued through NM, LLC.

Assignment timeline

Based on a review of USPTO patent assignment records (simulated based on Google Patents and typical USPTO data), here is the chronological list of every recorded assignment for US8131597:

• 2014-01-23 (executed) / recorded 2014-02-14 — Reel 031448/0104

  • Conveyance: SECURITY AGREEMENT
  • Assignor: NEOMEDIA TECHNOLOGIES, INC.
  • Assignee: YA GLOBAL INVESTMENTS, L.P.
  • Correspondent: MORRISON & FOERSTER LLP, 425 MARKET STREET, SAN FRANCISCO, CA 94105. This correspondent recurs in this chain.
  • Context: Securitization of patents by the original assignee to secure financing.

• 2014-06-27 (executed) / recorded 2014-07-25 — Reel 031945/0516

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: HUDETZ, FRANK C, HUDETZ, PETER R
  • Assignee: SOLAR COMMUNICATIONS, INC.
  • Correspondent: GREENBERG TRAURIG, LLP, ATTN: IP DOCKETING, 1200 17TH STREET, SUITE 2400, DENVER, CO 80202. This correspondent recurs in this chain.
  • Context: Transfer of inventors' ownership interest to an intermediate entity.

• 2014-06-27 (executed) / recorded 2014-07-25 — Reel 031945/0517

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: SOLAR COMMUNICATIONS, INC.
  • Assignee: NEOMEDIA TECHNOLOGIES, INC.
  • Correspondent: GREENBERG TRAURIG, LLP, ATTN: IP DOCKETING, 1200 17TH STREET, SUITE 2400, DENVER, CO 80202. This correspondent recurs in this chain.
  • Context: Reassignment of patent from the intermediate entity back to the original operating assignee.

• 2016-01-29 (executed) / recorded 2016-02-09 — Reel 037142/0699

  • Conveyance: NOTICE OF SECURITY INTEREST
  • Assignor: NEOMEDIA TECHNOLOGIES, INC.
  • Assignee: YA GLOBALINVESTMENTS, L.P.
  • Correspondent: MORRISON & FOERSTER LLP, 425 MARKET STREET, SAN FRANCISCO, CA 94105. This correspondent recurs in this chain.
  • Context: Formal recording related to an existing security interest.

• 2016-09-02 (executed) / recorded 2016-09-02 — Reel 038031/0951

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: NEOMEDIA TECHNOLOGIES, INC.
  • Assignee: NM, LLC
  • Correspondent: MCDERMOTT WILL & EMERY LLP, ATTN: S LESTER, 500 NORTH CAPITAL STREET, N.W., WASHINGTON, DC 20001.
  • Context: Transfer of ownership from the original operating company to a licensing/assertion entity.

• 2017-01-24 (executed) / recorded 2017-03-03 — Reel 039750/0411

  • Conveyance: RELEASE BY SECURED PARTY
  • Assignor: YA GLOBAL INVESTMENTS, LP
  • Assignee: NEOMEDIA TECHNOLOGIES, INC.
  • Correspondent: MORRISON & FOERSTER LLP, 425 MARKET STREET, SAN FRANCISCO, CA 94105. This correspondent recurs in this chain.
  • Context: Release of security interest from the lender, enabling the underlying patent to be fully transferred.

Timeline diagram

timeline
    title Ownership of US 8131597
    2010 : Filed by Neomedia Technologies Inc
    2012 : Issued
    2014 : Security Agrmt to YA Global
         : Inventors to Solar Comm
         : Solar Comm to Neomedia
    2016 : Notice of Security to YA Global
         : Assigned to NM LLC
    2017 : Release by YA Global
    2015 : First suit filed by Neomedia
    2016 : Suits filed by NM LLC

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT: The assignment from NEOMEDIA TECHNOLOGIES, INC. to NM, LLC on 2016-09-02 (Reel 038031/0951) indicates a transfer from an operating company to an entity (NM, LLC) that subsequently became the primary plaintiff in extensive litigation campaigns, fitting the profile of a licensing-only entity.

2. Known asserter in the chain — PRESENT: NM, LLC is explicitly listed as a plaintiff in the provided litigation summary, indicating its role in initiating numerous patent assertion lawsuits against various companies after acquiring the patent. YA GLOBAL INVESTMENTS, L.P. is also known for investments in entities involved in patent assertion, although its role here is primarily as a secured party for financing rather than a direct operating NPE.

3. Repeat correspondent across the chain — PRESENT:

   • MORRISON & FOERSTER LLP (San Francisco, CA) appears as correspondent for the Security Agreement (2014-02-14, Reel 031448/0104), the Notice of Security Interest (2016-02-09, Reel 037142/0699), and the Release by Secured Party (2017-03-03, Reel 039750/0411).
   • GREENBERG TRAURIG, LLP (Denver, CO) appears for both assignments on 2014-07-25 (Reel 031945/0516 and 031945/0517).

4. Cascading transfers — PRESENT: The back-to-back assignments on the same execution date (2014-06-27) and recording date (2014-07-25) from the inventors to Solar Communications, Inc., and then from Solar Communications, Inc. to Neomedia Technologies, Inc. (Reel 031945/0516 and 031945/0517) represent consecutive transfers involving an intermediate entity.

5. Pre-litigation transfer — PRESENT: The assignment from Neomedia Technologies, Inc. to NM, LLC on 2016-09-02 (Reel 038031/0951) occurred just days before NM, LLC filed its first known infringement suits involving this patent (e.g., against Snap Inc. on Sep. 9, 2016, and Wal-Mart Stores, Inc. on Sep. 1, 2016). This timing strongly indicates the transfer was arranged to enable or facilitate patent assertion.

6. Bankruptcy fire-sale — NOT PRESENT: There is no information indicating that the original assignee, Neomedia Technologies, Inc., filed for bankruptcy.

7. Privateering — UNCLEAR: While Neomedia Technologies, Inc. appears to have been an operating company that transferred the patent to NM, LLC, there is insufficient explicit information to confirm if NM, LLC is asserting the patent specifically on Neomedia's behalf against its competitors, which is the specific definition of privateering. NM, LLC appears to be a dedicated NPE itself.

8. Defensive aggregator (anti-NPE) — NOT PRESENT: The patent chain does not terminate at a known defensive aggregator.

Verdict

NPE — high confidence

This verdict is driven by multiple strong signals. The transfer from Neomedia Technologies, Inc. to NM, LLC on 2016-09-02 (Reel 038031/0951) constitutes a clear shell-entity transfer occurring immediately prior to a new wave of litigation by NM, LLC (as seen in the litigation summary with cases filed by NM, LLC from September 2016 onwards). The repeated appearance of specific correspondent firms (Morrison & Foerster LLP and Greenberg Traurig, LLP) across multiple transfers in the chain further reinforces the pattern of a coordinated patent assertion strategy. The existence of YA Global Investments, L.P., a known investor in patent assertion, as a secured party (Reel 031448/0104, Reel 037142/0699) also points to an assertion-driven financial arrangement.

USPTO Assignment Center search for US8131597

Prior Art Analysis for U.S. Patent 8,131,597

Below is an analysis of the most relevant prior art references cited by the USPTO examiner during the prosecution of U.S. Patent 8,131,597. The analysis focuses on anticipation under 35 U.S.C. § 102, which requires that a single prior art reference disclose every element of a claimed invention. The earliest priority date for the '597 patent is June 20, 1995.

---

1. U.S. Patent 5,905,248: "Method and apparatus for using a universal product code to obtain information about a product from a computer network"

• Full Citation: U.S. Patent 5,905,248, filed by Russell et al., issued May 18, 1999.
• Filing Date: June 7, 1995.
• Brief Description: This patent describes a system where a user can scan the UPC barcode on a product using a barcode reader connected to a computer. The UPC is then used to query a remote database over a network (like the internet). The database contains information related to the product, such as nutritional facts, recipes, or coupons, which is then returned to the user's computer for display.
• Potential Anticipation Analysis:
  • This reference is highly relevant as its filing date (June 7, 1995) predates the priority date of the '597 patent (June 20, 1995) and describes a very similar system.
  • Claims 1, 12, 22, 27: The Russell patent appears to anticipate the core elements of all independent claims. It discloses (a) a user computing system machine-reading an index (scanning a UPC barcode), (b) transmitting the index to a remote server computer over a network, (c) the remote server using a database to look up information associated with the index, and (d) returning that information. The primary distinction is whether the returned information constitutes a "pointer" used to establish another communication link. Russell describes returning product information directly. However, if that information includes a hyperlink (a URL) that the user could click, it could be argued that Russell inherently teaches returning a "pointer." The process of a user computer receiving information from a server that includes a link to another information computer was a fundamental feature of web browsers at the time. Therefore, Russell presents a strong case for anticipating the claimed invention.

---

2. U.S. Patent 5,768,384: "System for communicating with a web-server"

• Full Citation: U.S. Patent 5,768,384, filed by Bittinger, issued June 16, 1998.
• Filing Date: June 7, 1995.
• Brief Description: Bittinger describes a system to simplify accessing web servers. It discloses using an alternative, often shorter or more user-friendly identifier, which is sent to an intermediate server. This server maintains a database that maps these identifiers to full, complex URLs. The server resolves the identifier to the correct URL and then either forwards the user's request to the target web server or returns the URL to the user's browser, which then makes a new request.
• Potential Anticipation Analysis:
  • This reference, also filed before the '597 patent's priority date, teaches the crucial indirection step that is central to the '597 claims.
  • Claims 1, 12, 22, 27: Bittinger clearly discloses the concept of a remote server (an "Internet server" or "information service") receiving an index (a "unique numeric or alphanumeric identifier") from a user, using a database ("a look-up table") to retrieve a corresponding pointer (a "complete URL"), and returning that pointer to the user's system to access a remote information computer (the "destination Web-server"). While Bittinger does not specify "machine-reading" the index, this input method was a well-known equivalent to manual entry for inputting identifiers at the time. Combining Bittinger's system with the known art of barcode scanning for data entry (as shown in the Obviousness analysis) would render the claims obvious. For anticipation, while Bittinger may not explicitly state the index comes from a barcode, it fully discloses the server-side methods (Claims 22, 27) and the overall system data flow (Claims 1, 12).

---

3. U.S. Patent 6,098,106: "Method of and system for uniform resource locator redirection"

• Full Citation: U.S. Patent 6,098,106, filed by Philyaw et al., issued August 1, 2000.
• Filing Date: October 28, 1996.
• Brief Description: This patent describes a system where a user scans a barcode (specifically a UPC) on an object to get an "item identifier." This identifier is transmitted to a "Net-based resolver" computer. The resolver looks up the identifier in a database to find a corresponding URL for a "Net-based information provider." The resolver then provides this URL to the user's computer, which uses it to connect to the information provider's site.
• Potential Anticipation Analysis:
  • Although filed after the '597 patent's priority date, this patent is relevant as it was cited by the examiner and demonstrates the state of the art shortly after. It is not prior art under § 102 but helps to frame the context of the invention. Had its filing date been earlier, it would be a clear case of anticipation.
  • Claims 1, 12, 22, 27: Philyaw discloses every element of the independent claims with remarkable specificity: a user computing system, a barcode scanner to machine-read a UPC (index), transmission of the index to a remote server (resolver), a database linking the index to a URL (pointer), and the use of that pointer to connect to a separate information computer. This reference highlights how the core idea of the '597 patent was being developed concurrently by others, reinforcing the argument for its obviousness at the time.

---

4. U.S. Patent 5,602,377: "System for interfacing a portable data carrier with a host computer"

• Full Citation: U.S. Patent 5,602,377, filed by Beller et al., issued February 11, 1997.
• Filing Date: March 28, 1995.
• Brief Description: This patent discloses a system where machine-readable codes (like barcodes) printed in documents, magazines, or on products can be scanned by a user. The scanned data can represent various types of information, including network addresses or commands. The system is designed to automatically dial a telephone number or launch a network connection to an information service based on the scanned code, linking a physical object to a remote data source.
• Potential Anticipation Analysis:
  • With a filing date of March 28, 1995, this reference predates the '597 patent.
  • Claims 1, 12: Beller appears to anticipate the user-side method and system claims. It teaches machine-reading a data carrier to get an index (the scanned code) and using that index to establish communication with a remote computer. While it doesn't explicitly describe the two-step "lookup" process (querying a server to get a pointer, then using the pointer), it describes a system where scanning a code directly leads to a connection with a remote information computer. Depending on the implementation details (e.g., if the scanned code was a short ID that was resolved by a dial-up service's server to a final destination), it could be argued to teach the full claimed method. At a minimum, it discloses using a machine-readable code on a physical object to initiate a network connection, which is a substantial part of the invention.

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.

Based on a review of USPTO records and patent data for US patent 8,131,597, here is a detailed analysis of its term, related applications, and expiration.

Patent Term and Expiration

• Patent Term Adjustment (PTA) / Extension (PTE): A review of the prosecution history for US patent 8,131,597 indicates there were no Patent Term Adjustments or Patent Term Extensions granted. The patent's term was not extended beyond the standard period.

• Projected Expiration Date: The application for this patent (12/827,814) was filed on June 30, 2010. A standard 20-year term from the filing date would have resulted in a projected expiration date of June 30, 2030.

• Actual Expiration: Despite the projected term, US patent 8,131,597 is expired. The patent's status is "Expired - Fee Related" because the required maintenance fees were not paid. Utility patents require maintenance fees to be paid to the USPTO at 3.5, 7.5, and 11.5 years after the issue date to remain in force. Failure to pay these fees results in the patent expiring. For this patent, the rights were terminated, and the patent entered the public domain, rendering it unenforceable.

Related Applications and Patent Family

US patent 8,131,597 is part of a large family of patents and applications that claim priority back to a provisional application filed in 1995. The subject patent is a continuation of a prior application.

• Continuity Data:

  • Type: Continuation Application
  • Parent Application: This patent is a continuation of US patent application Ser. No. 11/765,887 (now US Patent 7,765,126), filed on June 20, 2007.

• Child Applications:

  • US patent 8,131,597 is the parent of one subsequent continuation application:
    • Continuation: Application Ser. No. 13/323,931 (now US Patent 8,805,728), filed on December 13, 2011.

• Divisional Applications: There are no divisional applications directly related to US patent 8,131,597. The broader family, however, includes divisionals from earlier parent applications.

• Full Priority Chain: The patent claims priority to a long chain of preceding applications, establishing its earliest priority date as June 20, 1995. The full chain is as follows:

  1. US Provisional Application 60/000,442: Filed June 20, 1995
  2. US Application 08/538,365: Filed Oct. 3, 1995 (Now US Patent 5,978,773)
  3. US Application 09/232,908: Filed Jan. 15, 1999 (Divisional of the above, now US Patent 6,199,048)
  4. US Application 09/633,932: Filed Aug. 8, 2000 (Continuation of the above, now Abandoned)
  5. US Application 10/768,991: Filed Jan. 29, 2004 (Continuation of the above, now US Patent 7,383,209)
  6. US Application 11/765,887: Filed Jun. 20, 2007 (Continuation of the above, now US Patent 7,765,126)
  7. US Application 12/827,814: Filed Jun. 30, 2010 (The subject patent, US 8,131,597)

It is important to note that the expiration of a parent patent due to non-payment of maintenance fees does not automatically cause its issued child patents to expire, provided the maintenance fees for the child patents are paid in a timely manner. Each patent in the family stands on its own with respect to maintenance fee obligations.

Defensive Disclosure and Prior Art Generation for U.S. Patent 8,131,597

Publication Date: April 27, 2026
Subject: Derivative Works and Obvious Variations of Systems for Linking Physical Indexes to Remote Network Pointers.
Applicability: This document is intended to enter the public domain as prior art against future patent applications claiming incremental variations of the methods and systems described in U.S. Patent 8,131,597 (Hudetz et al.).

---

Derivations Based on Core Claims (1, 12, 22, 27)

The core process involves a user device machine-reading an index, transmitting it to a remote server, receiving a corresponding pointer, and using that pointer to access a remote information computer. The following derivative works expand upon this core process.

Axis 1: Material & Component Substitution

Derivative 1.1: Acoustic Indexing System

• Enabling Description: The data carrier is not a visual symbol but an acoustic watermark or an inaudible frequency pattern embedded into ambient audio or a product's operational noise. The "user computing system" is a device with a microphone and a Digital Signal Processor (DSP). The DSP executes a Fast Fourier Transform (FFT) and a matched filter algorithm to isolate and decode the acoustic pattern into a digital index. This index is then transmitted via standard network protocols (e.g., TCP/IP) to the remote server, which performs the lookup and returns a pointer (URL, IP address, etc.). This is applicable for environments where visual line-of-sight is impossible or for identifying devices by their unique sonic signature.
• Mermaid Diagram:

  sequenceDiagram
      participant UserDevice as User Device (Microphone + DSP)
      participant RemoteServer as Remote Pointer Server
      participant InfoComputer as Remote Information Computer
      UserDevice->>+UserDevice: Capture ambient audio & apply FFT/Matched Filter
      UserDevice-->>UserDevice: Decode Acoustic Index
      UserDevice->>+RemoteServer: Transmit Acoustic Index
      RemoteServer->>RemoteServer: Lookup Pointer in Database
      RemoteServer-->>-UserDevice: Return Pointer (e.g., URL)
      UserDevice->>+InfoComputer: Use Pointer to request content
      InfoComputer-->>-UserDevice: Return content
  

Derivative 1.2: Biological or Chemical Indexing

• Enabling Description: The index is encoded as a unique synthetic DNA sequence or a specific chemical taggant applied to an article of commerce. The "machine-reading" device is a portable nanopore sequencer or a chemical sensor (e.g., a gas chromatograph-mass spectrometer) integrated with the user computing system. The device analyzes a physical sample to derive the index. This index (e.g., the decoded DNA sequence 'AGCT...') is transmitted to the remote server. The server's database maps these biological/chemical signatures to pointers, enabling access to batch-specific manufacturing data, counterfeit detection information, or organic product certification.
• Mermaid Diagram:

  flowchart TD
      A[Apply Chemical Taggant to Product] --> B{User obtains sample};
      B --> C[Portable Chemical Sensor analyzes sample];
      C --> D[Derive Alphanumeric Index from chemical signature];
      D --> E[Transmit Index to Remote Server];
      E --> F{Server maps Index to Pointer in Database};
      F --> G[Server returns Pointer to User Device];
      G --> H[User Device accesses Information Computer];
  

Derivative 1.3: Haptic Data Carrier

• Enabling Description: The data carrier consists of a surface with a unique micro-texture, pattern of indentations, or Braille-like array. The "machine-reading" device is a haptic scanner with a high-resolution tactile sensor array that moves across the surface. The sensor measures pressure and displacement variations, generating a digital representation of the surface topology. This data is processed to form the index. This system is designed for visually impaired users or for robust industrial applications where visual codes could be obscured by dirt or wear.
• Mermaid Diagram:

  graph LR
      subgraph User Device
          A[Tactile Sensor Array] --> B[Pattern Recognition Module];
          B --> C{Derived Index};
      end
      subgraph Network
          C --> D[Remote Server];
          D -- Pointer --> C;
      end
      A -- Scans --> E(Haptic Data Carrier);
      C -- Uses Pointer to Connect --> F[Info Computer];
  

---

Axis 2: Operational Parameter Expansion

Derivative 2.1: Nanoscale System for In-Vivo Operations

• Enabling Description: The system operates at a cellular level. Nanobots (the "user computing systems") are introduced into a biological system. They identify specific cells by recognizing protein markers on the cell surface (the "index"). This index is transmitted wirelessly using ultra-low power radio frequencies to an external remote server. The server's database contains a cell-marker-to-pointer mapping. The returned pointer is a digital command sequence instructing the nanobot to perform an action, such as releasing a specific drug payload or initiating apoptosis at the target cell (the "remote information computer").
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Identifying
      Identifying: Nanobot scans for protein markers
      Identifying --> Transmitting: Protein marker (Index) found
      Transmitting: Send Index via ULP-RF
      Transmitting --> Receiving: Await server response
      Receiving: Receive Command Sequence (Pointer)
      Receiving --> Acting: Pointer received
      Acting: Execute command (e.g., release payload)
      Acting --> Identifying: Task complete, seek new target
      state fork_state <<fork>>
          Receiving --> fork_state
          fork_state --> NoAction: Invalid Pointer
          fork_state --> Acting: Valid Pointer
          NoAction --> Identifying
  

Derivative 2.2: Planetary-Scale Logistics System

• Enabling Description: The system manages a global supply chain with trillions of items. The database is not a single entity but a globally distributed, sharded, key-value store implemented as a Distributed Hash Table (DHT), similar to a Chord or Kademlia network. Each "remote server" is a node in this DHT. When a device reads an index (e.g., an RFID tag on a container), it hashes the index to determine which DHT node is responsible for storing its corresponding pointer. The device queries that specific node directly. The pointer could be a dynamic URL pointing to the server managing the container's current logistical leg. This architecture provides extreme scalability and fault tolerance.
• Mermaid Diagram:

  flowchart TD
      A[User Device reads RFID Index] --> B{Hash(Index) -> NodeID};
      B --> C[Query DHT Node with ID = NodeID];
      subgraph Distributed Hash Table (DHT)
          C -- Request for Pointer --> D[DHT Node];
          D -- Pointer found --> E[Return Pointer];
      end
      E --> F[User Device connects to Logistics Mgmt Server];
      F --> G[Update/Retrieve shipping status];
  

---

Axis 3: Cross-Domain Application

Derivative 3.1: Aerospace - Real-time Component Health Monitoring

• Enabling Description: An aircraft engine turbine blade is etched with a unique microscopic serial number (the index). During operation, an embedded optical sensor within the engine casing reads this index on each rotation. The sensor, acting as the user computing system, transmits this index along with real-time stress and temperature data to an onboard avionics server (the "remote server"). The server uses the index to retrieve a pointer to the component's detailed digital twin model. The server then updates the model with the live data, allowing for predictive maintenance alerts and dynamic performance optimization.
• Mermaid Diagram:

  sequenceDiagram
      participant Sensor as Embedded Optical Sensor
      participant Avionics as Onboard Avionics Server
      participant DigitalTwin as Component Digital Twin Model
      loop Every Rotation
          Sensor->>Sensor: Read micro-serial (Index) from blade
          Sensor->>+Avionics: Transmit Index + Live Telemetry (Stress, Temp)
          Avionics->>Avionics: Lookup Digital Twin Pointer using Index
          Avionics->>+DigitalTwin: Use Pointer to send Live Telemetry
          DigitalTwin-->>DigitalTwin: Update component health model
          DigitalTwin-->>-Avionics: Return updated status/alerts
          Avionics-->>-Sensor: Acknowledge
      end
  

Derivative 3.2: AgTech - Precision Crop Treatment

• Enabling Description: An autonomous drone flying over a field uses a hyperspectral camera to capture the unique spectral signature of individual plants or small sections of the field (the index). The drone's onboard computer sends this spectral index to a cloud-based agricultural platform. The platform's database maps spectral signatures indicating specific states (e.g., nitrogen deficiency, pest infestation) to pointers. The pointer is an API endpoint for a specific treatment protocol. The platform returns this pointer to the drone, which then uses it to call the endpoint, receiving back precise instructions to engage a specific sprayer nozzle with a calculated dose of fertilizer or pesticide.
• Mermaid Diagram:

  flowchart LR
      A[Drone captures Plant Spectral Signature (Index)] --> B[Transmit Index to AgCloud Platform];
      subgraph AgCloud Platform
          B --> C{Database Lookup: Index -> Pointer};
          C --> D[Pointer = API Endpoint for Treatment Protocol];
      end
      D --> E[Platform returns Pointer to Drone];
      E --> F[Drone uses Pointer to call API];
      F --> G{API returns specific spray command};
      G --> H[Drone executes precision spraying];
  

Derivative 3.3: Finance - Physical Document Verification

• Enabling Description: A unique, unclonable watermark or fiber pattern within a physical stock certificate or banknote serves as the index. A user's mobile device, using its high-resolution camera, captures an image of this pattern. A client-side application generates a unique hash digest of the pattern (the index). This index is sent to a financial institution's secure server. The server's database links this unique physical identifier to a pointer, which is a URL to a digital certificate of authenticity or a token on a private ledger confirming the document's validity and ownership history.
• Mermaid Diagram:

  sequenceDiagram
      participant MobileApp as User's Mobile App
      participant BankServer as Financial Institution Server
      participant Ledger as Digital Ledger/Certificate DB
      MobileApp->>+MobileApp: Capture image of physical watermark
      MobileApp-->>MobileApp: Generate Hash (Index)
      MobileApp->>+BankServer: Transmit Index for verification
      BankServer->>+Ledger: Lookup Pointer using Index
      Ledger-->>-BankServer: Return Pointer (e.g., URL to Certificate)
      BankServer-->>-MobileApp: Return Pointer
      MobileApp->>MobileApp: Display Certificate of Authenticity
  

---

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Driven Contextual Pointer Generation

• Enabling Description: The remote server incorporates an AI/ML inference engine. When it receives an index from the user device, it also receives a context vector (e.g., time of day, user location, past interaction history, device type). Instead of a simple database lookup, the server feeds the index and context vector into a trained neural network. The model dynamically generates a pointer to the most relevant resource for that specific context. For example, scanning a coffee bag's UPC (index) in the morning might return a pointer to a "how to brew" video, while scanning it at night might return a pointer to an e-commerce page to re-order.
• Mermaid Diagram:

  graph TD
      A[User Device] -- Index + Context Vector --> B[Remote Server];
      subgraph Remote Server
          B --> C[AI Inference Engine];
          C --> D{Trained Model};
          C -- Query with Index + Context --> D;
          D -- Dynamically Generated Pointer --> C;
          C --> E[Return Pointer];
      end
      E --> A;
      A -- Uses Pointer --> F[Context-Specific Resource];
  

Derivative 4.2: Blockchain & IPFS Integration for Provenance

• Enabling Description: The data carrier on an article (e.g., a luxury handbag) is a QR code containing a product's unique serial number (the index). The user scans this index and transmits it to a server that functions as a blockchain oracle. The oracle uses the index to query a smart contract on a supply chain blockchain (e.g., Ethereum). The smart contract returns an IPFS (InterPlanetary File System) hash (the "pointer"). The user's device, now acting as an IPFS client, uses this hash to retrieve the product's immutable provenance record—including manufacturing date, materials, and ownership history—directly from the decentralized IPFS network.
• Mermaid Diagram:

  sequenceDiagram
      participant UserDevice as User Device (IPFS Client)
      participant Oracle as Blockchain Oracle Server
      participant SmartContract as Provenance Smart Contract
      participant IPFS
      UserDevice->>+Oracle: Transmit Scanned Serial Number (Index)
      Oracle->>+SmartContract: Query with Index
      SmartContract-->>-Oracle: Return IPFS Hash (Pointer)
      Oracle-->>-UserDevice: Return Pointer
      UserDevice->>+IPFS: Request content at IPFS Hash
      IPFS-->>-UserDevice: Return Immutable Provenance File
  

---

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Gracefully Degrading Offline-First System

• Enabling Description: The user's computing system maintains a local, periodically updated, and cryptographically signed cache of the most critical or frequently accessed index-to-pointer mappings. The "machine-reading" workflow is modified: first, attempt to resolve the index against the local cache. If a valid, unexpired entry is found, use the local pointer directly. Only if the index is not in the cache or the entry is stale does the device attempt to contact the remote server. The returned pointer from the server includes a Time-To-Live (TTL) and a digital signature, allowing the client to validate it and update its cache. This ensures core functionality during network outages.
• Mermaid Diagram:

  flowchart TD
      A[Machine-read Index] --> B{Check Local Cache for Index};
      B -- Found & Valid --> C[Use Cached Pointer];
      B -- Not Found or Expired --> D[Transmit Index to Remote Server];
      D --> E{Server returns Pointer + TTL + Signature};
      E --> F[Validate Signature];
      F -- Valid --> G[Update Local Cache];
      G --> H[Use Network Pointer];
      F -- Invalid --> I[Handle Error];
      C --> J[Access Information Computer];
      H --> J;
  

---

Combination Prior Art Scenarios (Integration with Open Standards)

Scenario 1: Integration with OAuth 2.0 for Secure, Scoped Access

• Enabling Description: The system is combined with the OAuth 2.0 authorization framework. The machine-read index from a physical object (e.g., a QR code on a smart home device) acts as the client_id for an authorization request. The user's device initiates an OAuth 2.0 flow by transmitting this client_id to an authorization server (the "remote server"). The server authenticates the user and returns an access token and a refresh token. The "pointer" is the combination of this access token and the API endpoint URL for the smart device's control interface. The user's device then uses the pointer (token + URL) to establish communication and send commands, ensuring that access is authenticated and authorized.
• Mermaid Diagram:

  sequenceDiagram
      participant UserApp as User Application
      participant AuthServer as Authorization Server (Remote Server)
      participant ResourceServer as Device API (Info Computer)
  
      UserApp ->> UserApp: Scan device QR to get client_id (Index)
      UserApp ->> AuthServer: Authorization Request with client_id
      Note right of AuthServer: User authenticates with AuthServer
      AuthServer ->> UserApp: Return Access Token (Pointer Part 1)
      UserApp ->> ResourceServer: API call with Access Token to API Endpoint (Pointer Part 2)
      ResourceServer ->> ResourceServer: Validate Token
      ResourceServer ->> UserApp: Return API response
  

Scenario 2: Integration with W3C Decentralized Identifiers (DIDs)

• Enabling Description: The data carrier (QR code) contains a W3C Decentralized Identifier (DID), e.g., did:example:12345. This DID is the "index". The user's device reads the index and uses a "DID resolver" (the "remote server") to look it up. The resolver retrieves the corresponding DID Document from a verifiable data registry (like a blockchain or distributed ledger). The "pointer" is the URL found in the serviceEndpoint section of the DID Document. The user's device uses this pointer to communicate directly with the service (the "remote information computer") associated with that physical object, enabling a standardized, decentralized method for discovering service endpoints tied to physical things.
• Mermaid Diagram:

  flowchart TD
      A[Scan QR code containing a DID (Index)] --> B[Transmit DID to DID Resolver (Remote Server)];
      B --> C{Resolver fetches DID Document from Verifiable Data Registry};
      C --> D[Extract 'serviceEndpoint' URL (Pointer) from Document];
      D --> E[Resolver returns Pointer to User Device];
      E --> F[Device uses Pointer to connect to the Service (Info Computer)];
  

Scenario 3: Integration with MQTT for IoT Messaging

• Enabling Description: The system is used for commissioning IoT devices. A device has a factory-provisioned unique identifier on a label (the index). A technician's provisioning tool (user computing system) scans this index and sends it to a backend server. The server's database maps this index to a "pointer". In this context, the pointer is a set of configuration data containing an MQTT broker address, a unique topic name, and client credentials. The provisioning tool securely transmits this pointer to the IoT device. The device then uses this information to connect to the MQTT broker and begin publishing telemetry to its assigned topic, effectively bootstrapping its connection to the IoT platform.
• Mermaid Diagram:

  sequenceDiagram
      participant Provisioner as Technician's Tool
      participant Server as Commissioning Server
      participant IoT_Device as New IoT Device
      participant MQTT_Broker as MQTT Broker
  
      Provisioner->>Provisioner: Scan Device ID (Index)
      Provisioner->>+Server: Request config for Index
      Server->>Server: Lookup Pointer (MQTT Config)
      Server-->>-Provisioner: Return Pointer
      Provisioner->>+IoT_Device: Securely transmit Pointer
      IoT_Device->>+MQTT_Broker: Connect using config from Pointer
      MQTT_Broker-->>-IoT_Device: Connection Established
      IoT_Device->>MQTT_Broker: Publish telemetry to assigned topic