US 5905248

An analysis of United States Patent 5,905,248 reveals the following details:

Title: System and method for carrying out information-related transactions using web documents embodying transaction enabling applets automatically launched and executed in response to reading URL-encoded symbols pointing thereto

Assignee: Metrologic Instruments, Inc.

Inventors: Garrett Russell, David M. Wilz, Sr., Carl Harry Knowles

Filing Date: August 22, 1997

Issue Date: May 18, 1999

Abstract: A novel transaction-enabling method and system are disclosed, wherein a transaction-enabling Java-Applet is embedded within an HTML-encoded document stored in an HTTP server at a predetermined URL. When a code symbol (e.g., magstripe or bar code) encoded with the URL is read using a code symbol reader interfaced with a Java-enabled Internet terminal, the corresponding HTTP document is automatically accessed and displayed at the terminal, and the transaction-enabling Java-Applet initiated for execution so that the customer, consumer or client desiring the transaction can simply and conveniently conduct the information-related transaction over the Internet. The transaction-enabling Internet terminal can be in the form of an Internet kiosk installed in a public location, in the manner as conventional ATMs. By virtue of the present invention, universal transaction machine (UTMs) can be easily deployed for use by the mass population so that they can easily conduct various types of transaction over the Internet.

Overview of Independent Claims:

This patent contains several independent claims that define the core of the invention. In plain language, these claims cover:

• Claim 1: A system for conducting transactions over the internet. This system includes a client computer with a web browser that is connected to the internet. It also has a code symbol reader (like a barcode scanner) connected to the computer. When this reader scans a symbol that has a URL encoded in it, the system automatically goes to that web address. The webpage at that address contains a special mini-program (an "applet") that then runs automatically to allow a user to perform a specific transaction.

• Claim 15: A method for carrying out transactions over the internet. This involves first creating a web document that includes a transaction-enabling applet. This document is stored on a web server at a specific URL. A physical symbol, like a barcode, is then created which contains this URL. When a user at a client computer scans this symbol with a reader, the computer automatically accesses the web document. The applet within the document is then launched, enabling the user to complete a transaction.

• Claim 29: An internet-based system for enabling transactions. This system is comprised of a client system with a web browser and a code symbol reader. There is also an internet server that stores a web document with an embedded transaction applet at a specific URL. When a code symbol encoded with this URL is read by the client's reader, the client system automatically retrieves and displays the web document, and the applet is executed to facilitate the transaction.

A search of the dockets for the Court of Appeals for the Federal Circuit (CAFC) for the current year, 2026, did not produce any public records of litigation involving US Patent 5,905,248. This does not definitively mean no litigation exists, as some records may not be publicly accessible or may not yet be docketed.

Litigation Search for US Patent 5,905,248

As of April 28, 2026, a comprehensive search of publicly available litigation databases reveals no known lawsuits or legal disputes specifically involving US Patent 5,905,248.

The search included the Unified Patents litigation portal, PACER (Public Access to Court Electronic Records), and general legal archives. These databases, which are standard tools for patent litigation research, yielded no records of infringement suits, declaratory judgments, or other legal actions where US Patent 5,905,248 was asserted.

This absence of litigation is not unusual. Many patents are never the subject of a lawsuit. It can indicate that the patent holder, Metrologic Instruments, Inc. (later acquired by Honeywell), chose to use the patent for defensive purposes, licensed it without conflict, or that its claims were not infringed upon in a manner that warranted legal action. While early litigation in the 1980s and 1990s involved Metrologic Instruments and other patents related to barcode scanning technology, none of the available records connect that litigation to the '248 patent, which was filed in 1997.

Proceedings overview

There are no AIA trial proceedings on file for U.S. Patent 5,905,248 as of today, 2026-05-30. The USPTO Open Data Portal API indicates no records, and a targeted web search for Inter Partes Review (IPR), Post-Grant Review (PGR), or Covered Business Method (CBM) proceedings against this patent did not yield any results. This means all claims of the patent are currently untested by PTAB proceedings.

Strategic summary

Currently, all claims of U.S. Patent 5,905,248 (claims 1-29) are UNTESTED by any AIA trial proceeding before the PTAB. There are no claims that have been canceled or sustained through these administrative processes. Consequently, there is no estoppel landscape established under § 315(e)(2) for potential petitioners, meaning all prior-art grounds remain available for future challenges, subject to the statutory time bars for filing such petitions. The absence of PTAB activity suggests that this patent may not have been aggressively asserted in litigation that would typically trigger such challenges, or that its claims are perceived as difficult to challenge under AIA standards, or that no party has yet had sufficient motivation to file a petition.

Recommended next steps

Since there is no PTAB activity on file for US Patent 5,905,248, the recommended next steps would depend on your specific defensive posture. If you are a defendant facing assertion of this patent, you would need to conduct your own prior art search and analysis to determine the strength of the patent's claims against potential invalidity challenges. The absence of PTAB activity means that all claims are still presumed valid, and any defensive strategy would need to account for the cost and effort of being the first to challenge the patent at the PTAB.

Inventors

• Garrett Russell: Metrologic Instruments, Inc.
• David M. Wilz, Sr.: Metrologic Instruments, Inc.
• Carl Harry Knowles: Metrologic Instruments, Inc.

All named inventors appear to have been employed by Metrologic Instruments, Inc. at the time of filing, as the initial assignment of interest on 2000-02-09 transferred the patent from them to Metrologic Instruments.

Original assignee

The original assignee named on the issued patent is Metrologic Instruments Inc.

Metrologic Instruments, Inc. was a global provider of laser and imaging barcode scanners and related hardware/software for data capture and collection. The company developed the first handheld retail laser barcode scanner in 1975 and held a substantial patent portfolio. It was an operating company that shipped products embodying the claims, serving various applications in retail, industrial, healthcare, inventory, and distribution.

Current Status: Metrologic Instruments, Inc. was acquired by Honeywell in July 2008 for approximately $720 million. It is now a division within Honeywell's Imaging & Mobility business unit.

Assignment timeline

• 2000-02-09 (executed) / recorded 2000-02-17 — Reel 022935/0675

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: KNOWLES, C. HARRY; RUSSELL, GARRETT; WILZ, DAVID M. SR.
  • Assignee: METROLOGIC INSTRUMENTS
  • Correspondent: REED SMITH SHAW & MCCLAY LLP 435 SIXTH AVE PITTSBURGH, PA 15219
  • Context: Original assignment of patent rights from the inventors to the initial corporate assignee.

• 2001-02-12 (executed) / recorded 2001-03-08 — Reel 011504/0073

  • Conveyance: SECURITY AGREEMENT
  • Assignor: ADAPTIVE OPTICS ASSOCIATES, INC.; METROLOGIC INSTRUMENTS, INC.
  • Assignee: PNC BANK, NATIONAL ASSOCIATION
  • Correspondent: BLANK ROME LLP ONE LOGAN SQUARE PHILADELPHIA, PA 19103-6998. This correspondent recurs in this chain.
  • Context: A security interest was granted to PNC Bank, likely for a loan or financing arrangement involving Metrologic Instruments, Inc. and Adaptive Optics Associates, Inc.

• 2004-11-15 (executed) / recorded 2004-12-07 — Reel 015383/0656

  • Conveyance: RELEASE
  • Assignor: PNC BANK, NATIONAL ASSOCIATION
  • Assignee: METROLOGIC INSTRUMENTS, INC.
  • Correspondent: BLANK ROME LLP ONE LOGAN SQUARE PHILADELPHIA, PA 19103-6998. This correspondent recurs in this chain.
  • Context: PNC Bank released its security interest in the patent back to Metrologic Instruments, Inc.

• 2007-02-28 (executed) / recorded 2007-03-22 — Reel 020083/0746

  • Conveyance: SECURITY AGREEMENT
  • Assignor: METEOR HOLDING CORP.; METROLOGIC INSTRUMENTS, INC.; OMNIPLANAR, INC.
  • Assignee: MORGAN STANLEY & CO. INCORPORATED
  • Correspondent: KUTAK ROCK LLP 1800 CENTURY PARK EAST 8TH FLOOR LOS ANGELES, CA 90067-1510. This correspondent recurs in this chain.
  • Context: A security interest was granted to Morgan Stanley by Metrologic and related holding entities.

• 2007-02-28 (executed) / recorded 2007-03-22 — Reel 020083/0754

  • Conveyance: SECURITY AGREEMENT
  • Assignor: METEOR HOLDING CORP.; METROLOGIC INSTRUMENTS, INC.; OMNIPLANAR, INC.
  • Assignee: MORGAN STANLEY & CO. INCORPORATED
  • Correspondent: KUTAK ROCK LLP 1800 CENTURY PARK EAST 8TH FLOOR LOS ANGELES, CA 90067-1510. This correspondent recurs in this chain.
  • Context: A second security interest was granted to Morgan Stanley by Metrologic and related holding entities.

• 2009-08-12 (executed) / recorded 2009-08-25 — Reel 024032/0833

  • Conveyance: RELEASE
  • Assignor: MORGAN STANLEY & CO. INCORPORATED
  • Assignee: OMNIPLANAR, INC.; METEOR HOLDING CORPORATION; METROLOGIC INSTRUMENTS, INC.
  • Correspondent: SHEARMAN & STERLING LLP 599 LEXINGTON AVENUE NEW YORK, NY 10022. This correspondent recurs in this chain.
  • Context: Morgan Stanley released its security interest in the patent back to Metrologic and related entities.

• 2009-08-12 (executed) / recorded 2009-08-25 — Reel 024032/0834

  • Conveyance: RELEASE
  • Assignor: MORGAN STANLEY & CO. INCORPORATED
  • Assignee: OMNIPLANAR, INC.; METEOR HOLDING CORPORATION; METROLOGIC INSTRUMENTS, INC.
  • Correspondent: SHEARMAN & STERLING LLP 599 LEXINGTON AVENUE NEW YORK, NY 10022. This correspondent recurs in this chain.
  • Context: Morgan Stanley released a second security interest in the patent back to Metrologic and related entities.

Timeline diagram

timeline
    title Ownership of US 5905248
    1997 : Filed
    1999 : Issued
    2000 : Assigned to Metrologic by inventors
    2001 : Security interest to PNC Bank
    2004 : PNC Bank releases security interest
    2007 : Security interests to Morgan Stanley
         : Second security interest to Morgan Stanley
    2008 : Metrologic acquired by Honeywell
    2009 : Morgan Stanley releases security interest
         : Second release by Morgan Stanley
    2010 : Patent expired

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent was originally assigned to an operating company (Metrologic Instruments, Inc.) and the subsequent recorded transactions are security agreements and releases. There is no explicit transfer to a shell entity in the USPTO assignment records.
2. Known asserter in the chain — not present. None of the assignors or assignees (Metrologic Instruments, Inc., PNC Bank, Morgan Stanley, Adaptive Optics Associates, Inc., Meteor Holding Corp., Omnipanar, Inc.) are publicly listed as known patent asserters.
3. Repeat correspondent across the chain — present.
   • BLANK ROME LLP appears as correspondent on Reel 011504/0073 and Reel 015383/0656.
   • KUTAK ROCK LLP appears as correspondent on Reel 020083/0746 and Reel 020083/0754.
   • SHEARMAN & STERLING LLP appears as correspondent on Reel 024032/0833 and Reel 024032/0834.
     This signal indicates that these firms handled multiple related transactions for the parties involved, particularly the security agreements and their releases.
4. Cascading transfers — not present. The recorded events are primarily security interests and releases, not consecutive ownership transfers.
5. Pre-litigation transfer — not present. There is no recorded litigation for this patent.
6. Bankruptcy fire-sale — not present. Metrologic Instruments, Inc. was acquired by Honeywell, not sold off in bankruptcy proceedings.
7. Privateering — unclear. While Metrologic was acquired by Honeywell, and the patent's ownership effectively resides with Honeywell, the USPTO assignment records do not show a direct assignment to Honeywell or any entity that would then assert on Honeywell's behalf against competitors. The recorded chain ends with the release of security interests, leaving Metrologic and related entities as the recorded owners in the context of the USPTO assignment system. Without a recorded transfer to Honeywell, or explicit evidence of privateering, it remains unclear.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at any known defensive aggregator.

Verdict

Insufficient data. The USPTO assignment records primarily show the initial assignment from inventors to Metrologic Instruments, Inc., followed by several security agreements and their subsequent releases. Although Metrologic Instruments, Inc. was acquired by Honeywell in July 2008, a direct assignment of this specific patent from Metrologic to Honeywell is not explicitly recorded in the USPTO Assignment Center. Therefore, without a clear change in ownership recorded in the assignment chain beyond Metrologic, and with no evidence of this patent ever being asserted, it is not possible to confidently categorize it as an NPE asset or an operating-company assertion, nor is there sufficient information to rule out a defensive posture post-acquisition without further investigation into Honeywell's patent management practices for acquired portfolios.

USPTO Assignment Center search for US5905248: https://assignmentcenter.uspto.gov/patent/5905248

Prior Art Analysis for U.S. Patent 5,905,248

An analysis of the prior art cited by the examiner during the prosecution of U.S. Patent 5,905,248 reveals several key patents that were considered relevant to the invention. The following is a breakdown of these references and their potential impact on the claims of the '248 patent.

U.S. Patent 5,424,524: "System for transferring information between a host computer and a terminal using bar codes"

• Full Citation: U.S. Patent 5,424,524, filed June 4, 1993, and issued June 13, 1995.
• Description: This patent describes a system where a host computer can generate and print a barcode that contains data and command information. A terminal with a barcode scanner can then read this barcode. The terminal is programmed to interpret the command information and use the data accordingly, such as by displaying it, storing it, or transmitting it back to the host or another computer. This allows for a streamlined, two-way communication process initiated by scanning a barcode.
• Potential Anticipation: This patent is relevant to the general concept of using a barcode to initiate a process on a computer. However, it does not specifically disclose the use of a URL (Uniform Resource Locator) within the barcode to automatically access a web document over the internet. Furthermore, the '524 patent does not teach the embedding of a transaction-enabling applet within that web document which is then automatically launched. Therefore, while it touches upon the idea of command sequences in barcodes, it likely does not anticipate the key elements of claims 1, 15, and 29 of the '248 patent, which are centered on internet-based transactions via URLs and applets.

U.S. Patent 5,602,377: "System and method for communication with a central computer using encoded indicia"

• Full Citation: U.S. Patent 5,602,377, filed June 7, 1995, and issued February 11, 1997.
• Description: This invention details a system where a user can use a scanner to read a barcode that contains product or service information. This information is then transmitted, often via a telephone network, to a central computer. The central computer can then process this information to, for example, place an order for the product or service. The system is designed to simplify remote ordering and information retrieval.
• Potential Anticipation: This patent moves closer to the '248 invention by linking a scanned barcode to a remote transaction. However, the communication method described is generally a direct dial-up or network connection to a specific central computer, not the open, standardized protocol of the internet using a URL and a standard web browser. The '377 patent also does not disclose the concept of accessing a web document containing a self-executing transaction applet. The core of the '248 patent's claims lies in leveraging the architecture of the World Wide Web, which is a distinct technological environment from the system described in the '377 patent. Therefore, it is unlikely to anticipate the independent claims of the '248 patent.

U.S. Patent 5,794,210: "Attention brokerage"

• Full Citation: U.S. Patent 5,794,210, filed May 30, 1996, and issued August 11, 1998.
• Description: This patent focuses on a system for online advertising where users are compensated for their attention. It describes a method where advertisements are distributed over a computer network like the Internet, and users can be paid for viewing or interacting with them. The system manages the buying and selling of user "attention".
• Potential Anticipation: While the '210 patent operates in the environment of the internet and involves user interaction with online content for a commercial purpose, its focus is on the business model of "attention brokerage" and advertising. It does not describe the specific mechanism of initiating this interaction by scanning a URL-encoded symbol. The fundamental inventive step of the '248 patent—using a physical code symbol to bridge the real world with a specific online transaction applet—is not present in the '210 patent. Therefore, it does not anticipate the claims of the '248 patent.

Other Cited U.S. Patents:

The file history of the '248 patent also lists several other patents that were considered by the examiner. These include:

• U.S. Patent 4,939,354: Describes a system for ordering items from a catalog using a barcode scanner and a telephone line.
• U.S. Patent 5,304,786: Pertains to a portable bar code reader that can store data and later upload it to a computer.
• U.S. Patent 5,594,232: Details a method for using a barcode to automatically dial a telephone number.
• U.S. Patent 5,661,294: Relates to a system for reading barcodes and transmitting the data to a remote computer for processing.

These patents, similar to the '524 and '377 patents, describe elements of scanning barcodes to initiate some form of communication or data transfer. However, none of them disclose the complete system and method claimed in the '248 patent, specifically the use of a URL to access a web document over the internet and the automatic execution of a transaction-enabling applet embedded within that document. The novelty of the '248 patent appears to be the integration of these specific technologies to create a seamless link from a physical object to an interactive online transaction.

Obviousness Analysis of U.S. Patent 5,905,248 under 35 U.S.C. § 103

This analysis evaluates whether the invention claimed in U.S. Patent 5,905,248 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time the invention was made, considering the prior art. The filing date is August 22, 1997, which establishes the relevant timeframe for the state of the art.

Legal Standard for Obviousness

Under 35 U.S.C. § 103, a patent claim is invalid "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." This requires an analysis of the scope and content of the prior art, the differences between the prior art and the claims at issue, and the level of ordinary skill in the pertinent art.

Person Having Ordinary Skill in the Art (PHOSITA)

At the time of filing in mid-1997, a PHOSITA would be an individual with a bachelor's degree in computer science or a related field, and several years of experience in client-server application development, network programming, and emerging World Wide Web technologies. This person would have been familiar with:

• The function of barcode scanners as computer input devices (keyboard wedges).
• The architecture of the Internet, including TCP/IP, HTTP, and the syntax of Uniform Resource Locators (URLs).
• HTML and the capabilities of web browsers like Netscape Navigator and Internet Explorer.
• Emerging technologies for creating interactive web content, most notably Java Applets, which were introduced in 1995 and had gained significant traction by 1997.

---

Obviousness Combination of Prior Art

The independent claims (1, 15, and 29) of the '248 patent are likely obvious in view of a combination of U.S. Patent 5,602,377 ("the '377 patent") and the general state of the art concerning the World Wide Web, as exemplified by patents like U.S. Patent 5,794,210 ("the '210 patent") and the well-known capabilities of Java Applets at the time.

1. Base Reference: U.S. Patent 5,602,377

The '377 patent discloses the core concept of using a scanner to read an encoded symbol on a physical item to initiate a remote transaction with a central computer. The system described allows a user to, for example, scan a product in a catalog to place an order. This reference teaches the fundamental "scan-to-transact" link between a physical object and a remote commercial action.

However, the '377 patent is deficient in two key areas relative to the '248 claims:

• It describes communication over a telephone network or a direct connection to a specific central computer, not via the open, standardized protocols of the World Wide Web (HTTP and URLs).
• It does not disclose the use of a web document containing an interactive, automatically executing "applet" to manage the transaction.

2. Motivation to Modify the '377 Patent

By 1997, the World Wide Web was experiencing explosive growth and was rapidly becoming the dominant platform for networked communication and electronic commerce. The '210 patent, filed in 1996, demonstrates that the Internet was already a well-established environment for conducting commercial transactions and user interactions.

A PHOSITA looking at the system in the '377 patent would have immediately recognized its limitations. A proprietary, direct-dial system is inefficient, difficult to scale, and lacks the universal accessibility of a web-based system. There would have been a strong and obvious motivation to update the '377 system by replacing its proprietary network infrastructure with the standardized, ubiquitous, and far more cost-effective architecture of the World Wide Web.

This motivation is not based on hindsight, but on the clear and well-documented technological and commercial trends of the mid-1990s. Porting existing networked applications to the Web was a common and logical engineering task at the time.

3. Applying Web Technologies to the '377 Concept

Making the '377 system web-based would involve predictable, non-inventive design choices for a PHOSITA in 1997:

• Replacing the Central Computer with a Web Server: The "central computer" in the '377 patent would naturally be replaced by a web server running HTTP server software.
• Encoding a URL in the Barcode: To direct a client computer to the correct web server and the specific transaction page, the standard and only logical addressing mechanism on the Web was a URL. Therefore, it would have been obvious to encode the URL for the transaction page in the barcode, rather than the proprietary product data and connection information used in the '377 system.
• Using a Web Browser as the Client: The client-side terminal would be a standard computer running a web browser, which was the universal tool for accessing resources on the Web.

This combination of the '377 patent's "scan-to-transact" method with standard Web architecture directly teaches the core elements of the '248 claims: a client system with a browser, a code reader, and a URL-encoded symbol that, when read, directs the browser to a specific web document on an Internet server.

4. The "Transaction-Enabling Applet"

The final key element of the claims is the "transaction-enabling applet" embedded in the web document that is "automatically launched and executed."

By 1997, Java Applets were a widely-publicized and well-understood technology. Their primary purpose, as promoted by Sun Microsystems and supported by browsers like Netscape, was to create rich, interactive, application-like experiences within a web page, overcoming the limitations of static HTML. For a PHOSITA tasked with creating a robust transaction interface on a web page, using a Java Applet was not an inventive leap but rather the selection of the most suitable, state-of-the-art tool for the job. The ability for an applet to launch automatically upon page load was an inherent and standard feature of how applets were implemented using the <APPLET> tag in HTML. The '248 patent itself describes this standard implementation (Detailed Description, Col. 14-16).

Therefore, once the decision was made to build the transaction system on the Web, employing a Java Applet to handle the transaction logic was an obvious design choice.

Conclusion

A person having ordinary skill in the art in 1997 would have found it obvious to combine the teachings of the prior art to arrive at the invention claimed in U.S. Patent 5,905,248. The '377 patent taught the core concept of scanning a symbol to initiate a remote transaction. The immense commercial and technical momentum of the World Wide Web, as evidenced by patents like '210 and general industry knowledge, would have provided a clear motivation to adapt the '377 system to the web's architecture. This adaptation would have involved the predictable use of web servers, URLs encoded in barcodes, and web browsers. Finally, implementing the transaction interface itself using a Java Applet was the obvious choice for creating an interactive application within a web page at that time. Each element existed, and the motivation to combine them in the claimed manner was driven by predictable trends and a desire for efficiency, scalability, and interoperability.

Analysis of U.S. Patent 5,905,248 Term, Status, and Family

Based on a review of the patent documentation and USPTO records, the following information has been determined for U.S. Patent 5,905,248.

Patent Term and Expiration

• Filing Date: August 22, 1997.
• Issue Date: May 18, 1999.
• Standard Term: For patents filed after June 8, 1995, the term is 20 years from the earliest non-provisional U.S. filing date.
• Calculated Expiration Date: The standard 20-year term calculated from the filing date would have ended on August 22, 2017.
• Patent Term Adjustments (PTA) / Extensions (PTE): A search of USPTO records indicates no Patent Term Adjustments or Extensions were granted for this patent. The provisions for PTA generally apply to applications filed on or after May 29, 2000, and therefore would not apply to this 1997 application.
• Actual Status: The patent is expired. The Google Patents record, which sources USPTO data, lists the legal status as "Expired - Fee Related." This indicates that the patent lapsed prior to its full term due to the non-payment of required maintenance fees. Maintenance fees for patents are due at 3.5, 7.5, and 11.5 years after the issue date. Failure to pay these fees results in the patent's expiration.

Continuity and Related Applications

The application for patent 5,905,248 (Ser. No. 08/916,694) is a Continuation-in-Part of a long line of preceding applications. The "Related Cases" section of the patent specification explicitly details this extensive family history. Key preceding applications include:

• Ser. No. 08/905,903, filed August 4, 1997
• Ser. No. 08/869,164, filed June 4, 1997
• Ser. No. 08/846,219, filed April 25, 1997
• Ser. No. 08/838,501, filed April 7, 1997
• Ser. No. 08/820,540, filed March 19, 1997
• Ser. No. 08/753,367, filed November 25, 1996
• Ser. No. 08/615,054, filed March 12, 1996
• Ser. No. 08/573,949, filed December 18, 1995
• ...and numerous others dating back to an application filed on September 11, 1990 (Ser. No. 07/580,740).

The application for this patent is one of many that claim priority to this long chain of development in barcode scanning and data systems by Metrologic Instruments, Inc. No divisional applications have been identified as originating from the '248 patent application itself.

Patent Family Members

The application that led to US 5,905,248 was part of a broader international filing strategy. The patent claims priority to several PCT (Patent Cooperation Treaty) applications, which resulted in a family of patents being granted in various countries. Key international family members include:

• PCT Application PCT/US1997/021975, which was published as WO1998024050A1.
• PCT Application PCT/US1997/021443, published as WO1998024049A1.
• PCT Application PCT/US1997/021970, published as WO1998024036A1.

These PCT applications led to patents and applications in jurisdictions such as:

• Europe (EP): EP1019844A4, EP0958546B1, EP0950226A4
• Canada (CA): CA2272467C, CA2272585C, CA2272583C
• Australia (AU): AU5367998A, AU7411698A, AU5513498A
• China (CN): CN1178147C, CN1171159C
• Japan (JP): JP2002512709A, JP2002516637A
• South Korea (KR): KR100461269B1, KR100355340B1
• Brazil (BR): BR9713426A, BR9713416A, BR9713425A
• Hong Kong (HK): HK1027882B, HK1026042B, HK1023828B

Defensive Disclosure and Prior Art Generation

Reference Patent: U.S. Patent 5,905,248
Subject Matter: System and method for initiating an internet-based transaction by scanning a physical symbol encoded with a Uniform Resource Locator (URL), which directs a client device to a web document containing a transaction-enabling applet that is automatically launched and executed.
Purpose: This document establishes public prior art for a series of derivative inventions and improvements related to the core claims of U.S. Patent 5,905,248. The disclosures herein are intended to be enabling for a person having ordinary skill in the art, thereby rendering subsequent patent applications for these concepts as obvious or lacking novelty.

---

Axis 1: Material & Component Substitution

Derivative 1.1: Near-Field Communication (NFC) Initiated Transaction Applet

• Enabling Description: The optical barcode symbol is replaced with a passive Near-Field Communication (NFC) tag (ISO/IEC 14443 compliant). The URL is written to the tag's NDEF (NFC Data Exchange Format) record. The code symbol reader is an NFC-enabled mobile device (smartphone, tablet). When the device is brought within proximity (typically < 4 cm) of the NFC tag, the device's operating system automatically reads the NDEF record, identifies the URI (Uniform Resource Identifier), and launches the default web browser to the specified URL. The web server at this URL serves an HTML5 document containing a JavaScript-based transaction application (replacing the Java Applet) which executes automatically upon page load to handle the transaction.

• Mermaid Diagram:

  sequenceDiagram
      participant UserDevice as Mobile Device (NFC Enabled)
      participant NFCTag as NFC Tag
      participant WebServer as HTTP Server
      participant TransactionApp as Web App (JavaScript)
  
      UserDevice->>+NFCTag: Tap device on tag
      NFCTag-->>-UserDevice: Transmit NDEF Record (contains URL)
      UserDevice->>UserDevice: OS URI Handler launches browser
      UserDevice->>+WebServer: HTTP GET Request (URL from tag)
      WebServer-->>-UserDevice: HTTP 200 OK (HTML/JS Payload)
      UserDevice->>+TransactionApp: Browser executes JavaScript on load
      TransactionApp-->>-UserDevice: Render transaction interface
  

Derivative 1.2: Biometric-Indexed Transaction Applet Launch

• Enabling Description: The transaction initiation is triggered by a biometric scan rather than a manufactured symbol. A user's biometric data (e.g., a fingerprint hash, iris template) is pre-registered in a secure database and linked to a specific transaction URL. The "reader" is a standard biometric scanner (e.g., FAP 30 fingerprint sensor) connected to a client terminal. Upon a successful scan, the terminal generates a hash of the biometric data and sends it to a secure lookup server. The server retrieves the corresponding URL and returns it to the client terminal. The client terminal then launches a web browser and navigates to the returned URL, where the transaction applet is served and executed.

• Mermaid Diagram:

  flowchart TD
      A[User presents biometric] --> B{Biometric Scanner};
      B --> C[Generate Biometric Hash];
      C --> D[Send Hash to Lookup Server];
      subgraph Secure Backend
          D --> E{Biometric DB};
          E -- URL --> F[Retrieve Associated URL];
      end
      F --> G[Return URL to Client];
      G --> H{Client Terminal};
      H --> I[Launch Browser with URL];
      I --> J[Execute Transaction Applet];
  

Derivative 1.3: Thermochromic Ink for Conditional URL Visibility

• Enabling Description: The URL is encoded in a 2D barcode (e.g., QR Code) printed using thermochromic ink that is invisible at a standard ambient temperature (e.g., 20°C) but becomes visible and scannable above a specific activation temperature (e.g., 35°C). A transaction kiosk is equipped with a standard optical scanner and a controlled heating element (e.g., a Peltier device or infrared lamp). To initiate a transaction, the user places their transaction card on a designated platen. The heating element raises the surface temperature of the card, revealing the barcode. The optical scanner then reads the URL, and the system proceeds to launch the transaction applet. This provides a physical security layer, as the URL is not scannable via casual photography.

• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Inactive
      Inactive: Card at ambient temp. Barcode invisible.
      Inactive --> Heating: User places card on platen
      Heating: Peltier element warms card to >35°C
      Heating --> Scannable: Barcode becomes visible
      state Scannable {
          direction LR
          [*] --> Scanning
          Scanning --> Success: Scanner reads URL
          Scanning --> Timeout: Scanner fails to read
          Success --> [*]
          Timeout --> Inactive
      }
      Scannable --> Inactive: Card cools down
  

---

Axis 2: Operational Parameter Expansion

Derivative 2.1: DNA-Encoded URL for Nanoscale Biological Transactions

• Enabling Description: The URL is encoded as a sequence of nucleotide bases (A, C, G, T) and synthesized into a single-stranded DNA molecule. This DNA is suspended in a solution or affixed to a substrate. The "reader" is a nanopore sequencing device (e.g., Oxford Nanopore MinION). The DNA sample is introduced to the sequencer, which determines the base sequence in real-time. A connected computer translates the base sequence back into an ASCII URL string using a predefined encoding scheme (e.g., 2 bits per base). The computer then launches a browser to this URL, which opens a specialized web applet for bioinformatics, such as ordering a custom synthetic gene from a genomics foundry or querying a protein folding database.

• Mermaid Diagram:

  graph LR
      A(DNA Strand w/ Encoded URL) -- Sampled --> B(Nanopore Sequencer);
      B -- Electrical Signals --> C(Basecalling Software);
      C -- Nucleotide Sequence --> D(Decoder Module);
      D -- "ACGT -> 'http://...'" --> E(ASCII URL String);
      E --> F(Web Browser);
      F -- HTTP Request --> G(Genomics Web Server);
      G -- Applet --> F;
  

Derivative 2.2: Long-Range Optical Scan for Industrial Asset Management

• Enabling Description: A large-format (e.g., 1m x 1m) 2D barcode with high error correction (e.g., QR Code Level H) is affixed to industrial equipment, such as a wind turbine nacelle or a large chemical tank. The "reader" is a drone or robotic vehicle equipped with a high-resolution camera and a telephoto lens. The drone navigates to the asset, captures an image of the barcode from a standoff distance (e.g., 50-100 meters), and performs image processing to decode the URL. The URL includes the unique asset ID and points to a web-based industrial IoT platform. The platform's applet launches, displaying real-time telemetry from the asset's sensors, its complete maintenance history, and providing controls for remote diagnostics.

• Mermaid Diagram:

  sequenceDiagram
      participant Drone as UAV with Camera
      participant Asset as Industrial Equipment
      participant GroundControl as Ground Control Station
      participant IIoT_Platform as Industrial IoT Server
  
      GroundControl->>+Drone: Fly to Asset Coordinates
      Drone->>Asset: Capture image of large-format barcode
      Drone-->>-GroundControl: Transmit image
      GroundControl->>GroundControl: Decode URL from image
      GroundControl->>+IIoT_Platform: HTTP Request (URL with Asset ID)
      IIoT_Platform-->>-GroundControl: Serve Asset Management Applet
      GroundControl->>GroundControl: Display telemetry and controls
  

---

Axis 3: Cross-Domain Application

Derivative 3.1: Aerospace In-Situ Component Analysis

• Enabling Description: A unique Data Matrix code is laser-etched onto a critical, life-limited aerospace component (e.g., a compressor disk in a jet engine). During an on-wing inspection, a technician uses a ruggedized borescope equipped with a camera to scan the code. The borescope is connected to a tablet. The decoded URL contains the component's unique serial number. It directs the tablet's browser to a secure manufacturer's portal. A WebGL-based applet loads, rendering a 3D model of that specific component. The applet overlays historical manufacturing quality data, previous inspection reports, and live data from nearby sensors (e.g., vibration, temperature) streamed via a local avionics bus gateway. The technician can then log new inspection data directly into the applet, which updates the component's digital twin record.

• Mermaid Diagram:

  flowchart TD
      subgraph On-Wing Inspection
          A(Technician uses Borescope) --> B{Scan Etched Data Matrix};
          B --> C[Decode URL with Serial Number];
      end
      subgraph Tablet
          C --> D[Browser requests URL];
      end
      subgraph Secure Cloud
          D --> E(Manufacturer Server);
          E --> F[Authenticate Technician];
          F --> G{Serve Component Digital Twin Applet};
          G --> H(Load Manufacturing & Sensor Data);
      end
      H --> I{Render 3D Model & Data Overlay};
      I --> Tablet;
      Tablet --> J(Technician logs new inspection);
      J --> G;
  

Derivative 3.2: AgTech Livestock Health Management

• Enabling Description: An electronic ear tag on a farm animal (e.g., a cow) contains an NFC chip storing a URL. The URL includes the animal's unique ID. A farmhand uses an NFC-enabled mobile device to scan the tag. This action launches a web applet connected to a farm management platform. The applet automatically pulls the animal's history (birth, vaccinations, breeding). It then uses the mobile device's camera and a client-side machine learning model (e.g., TensorFlow.js) to perform a real-time visual health assessment (e.g., analyzing gait, eye clarity, or body condition). The results are logged in the applet and a recommendation for action (e.g., quarantine, dietary change) is displayed.

• Mermaid Diagram:

  sequenceDiagram
      participant Farmer as Farmer's Mobile Device
      participant CowTag as Animal NFC Tag
      participant FarmServer as Farm Management Server
      participant MLModel as On-Device ML Model
  
      Farmer->>+CowTag: Scan NFC Ear Tag
      CowTag-->>-Farmer: Return URL with Animal ID
      Farmer->>+FarmServer: GET /animal/{ID}
      FarmServer-->>-Farmer: Serve Health Applet + Animal History
      Farmer->>Farmer: Activate Camera via Applet
      Farmer->>+MLModel: Perform Visual Health Analysis
      MLModel-->>-Farmer: Return Health Score/Metrics
      Farmer->>+FarmServer: POST /health-log/{ID} (Data from ML Model)
      FarmServer-->>-Farmer: Acknowledge & provide recommendation
  

---

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Optimized Equipment Calibration

• Enabling Description: A QR code on a scientific instrument (e.g., a mass spectrometer) encodes a URL pointing to a cloud-based management platform. When a technician scans the code, the launched web applet sends the instrument's unique ID to an AI backend. The AI model has been trained on performance data from thousands of similar instruments. It analyzes the specific instrument's recent usage patterns, error logs, and environmental sensor data (via IoT). The AI generates a dynamic, optimized calibration procedure tailored to the instrument's current state and anticipated workload, rather than a generic, fixed schedule. The applet then guides the technician through this custom procedure step-by-step.

• Mermaid Diagram:

  graph TD
      A[Scan QR Code on Instrument] --> B(Launch Calibration Applet);
      B -- Instrument ID --> C{AI Backend};
      subgraph Cloud Platform
          C -- Analyzes --> D(Historical Usage Data);
          C -- Analyzes --> E(IoT Sensor Data);
          C --> F[Generate Optimized Calibration Workflow];
      end
      F -- Custom Steps --> B;
      B --> G[Guide Technician through steps];
  

Derivative 4.3: Blockchain-Verified Supply Chain Audit

• Enabling Description: A QR code on a pallet of high-value goods (e.g., organic produce) contains a URL. The URL points to a decentralized application (dApp) front-end. When a supply chain participant (e.g., a customs officer) scans the code, the dApp is launched. The dApp prompts the officer to connect their decentralized identity wallet (e.g., MetaMask). Using their wallet, the officer signs a transaction that records the scan event (location, timestamp, their public key) on a permissioned blockchain. The dApp then reads the blockchain and displays the complete, immutable chain of custody for that specific pallet, verifying its origin and path.

• Mermaid Diagram:

  sequenceDiagram
      participant Officer as Customs Officer's Device
      participant QRCode as Pallet QR Code
      participant dApp as dApp Frontend
      participant Wallet as Identity Wallet (MetaMask)
      participant Blockchain as Supply Chain Ledger
  
      Officer->>QRCode: Scan QR Code
      QRCode-->>Officer: Provide URL to dApp
      Officer->>+dApp: Load dApp Frontend
      dApp->>+Wallet: Request Wallet Connection
      Wallet-->>-dApp: Wallet Connected
      dApp->>+Wallet: Request Signature for Scan Event
      Wallet-->>-dApp: Return Signed Transaction
      dApp->>+Blockchain: Broadcast Signed Transaction
      Blockchain->>Blockchain: Record new custody event in block
      Blockchain-->>-dApp: Confirmation
      dApp->>+Blockchain: Read full history for Pallet ID
      Blockchain-->>-dApp: Return complete audit trail
      dApp-->>-Officer: Display verified chain of custody
  

---

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation with Embedded Fallback URL

• Enabling Description: The data encoded in a QR code is a structured format (e.g., a JSON object) containing a primaryUrl and a fallbackUrl. A custom scanner application (instead of the OS-default) reads the QR code. It first attempts to make an HTTP HEAD request to the primaryUrl. If the request succeeds within a 500ms timeout and returns a 200-series status code, the app launches a full web view with this URL. If it fails or times out, the app immediately launches the fallbackUrl. The fallbackUrl points to a statically-generated, CDN-hosted, text-only HTML page that allows for submission of the most critical transaction data via a simple form, ensuring core functionality even in poor network conditions.

• Mermaid Diagram:

  flowchart TD
      A[Scan QR with structured data] --> B{Custom Scanner App};
      B --> C{"Extract primaryUrl & fallbackUrl"};
      C --> D{HTTP HEAD to primaryUrl};
      D -- Success (200 OK, <500ms) --> E[Launch full applet at primaryUrl];
      D -- Fail (Timeout, Error) --> F[Launch lite page at fallbackUrl];
      E --> G[Full Transaction];
      F --> H[Limited Transaction];
  

---

Combination Prior Art with Open-Source Standards

• Scenario 1: OAuth 2.0 for Secure Service Onboarding: A QR code on a newly purchased IoT device contains a pre-formatted OAuth 2.0 authorization URL for the device manufacturer's service. The URL includes the client_id (representing the device model), a unique state parameter (tied to the device serial number), and the requested scope (e.g., device_registration, data_sync). When the user scans this code with their phone, it launches their browser, directs them to their chosen identity provider (e.g., Google, Apple), and initiates an authorization flow. Upon user consent, the provider redirects back to the manufacturer's service with an authorization code, which is then exchanged for an access token. This token securely links the physical device to the user's account without the user ever needing to manually enter serial numbers or passwords.

• Scenario 2: WebAuthn for Phishing-Resistant Kiosk Authentication: An interactive kiosk for financial services displays a QR code containing a session-specific URL. A user scans the QR code with their mobile phone, which opens the URL in their phone's browser. The web page served is a remote authenticator interface. It initiates a WebAuthn ceremony, prompting the user to authenticate on their phone using a platform authenticator (Face ID, Android fingerprint). The phone signs a challenge and sends the signed assertion back to the kiosk's session via a secure WebSocket connection established by the applet. The kiosk verifies the assertion and logs the user into their account, completely bypassing the need for passwords on the public kiosk.

• Scenario 3: Verifiable Credentials for Decentralized Access Control: A secure facility uses QR codes at entry points. The QR code contains a URL that initiates a request for a Verifiable Credential (VC) based on the W3C DID and VC standards. When an employee scans the code, the launched web applet communicates with their digital wallet on their device. The wallet presents a cryptographically signed VC issued by the company's HR department, proving their identity and access level (role: "Level 3 Engineer"). The applet verifies the VC's signature against the company's public DID. If valid, the applet sends a signal to the physical access control system to open the door.