Here's a concise summary of US Patent 11664123:

Title: Barcode generation and implementation method and system for processing information

Assignee: Iscan2d Technologies LLC

Inventors: Sean McKirdy

Filing Date: 2021-02-22

Issue Date: 2023-05-30

Abstract: A method for generating and implementing a barcode in a mobile device is disclosed. The method involves receiving user data via a data generation device, with this data associated with the use of that device. Barcode data is then generated in response to this user data and sent to a barcode generator. The barcode generator creates a barcode based on this data, which is then displayed to the user. The user uploads this barcode data into a mobile device, which then processes the barcode data in response to its content.

Plain-Language Overview of Independent Claims:

• Claim 1: This claim describes a method for generating and implementing a barcode. It involves a data generation device receiving user data related to its use. This data is converted into barcode data, which is then sent to a barcode generator. The barcode generator creates a barcode that is displayed. A mobile device then uploads this barcode data and processes it, optionally sending a data string to a web server if a URL is present or using the URL for authentication before processing.
• Claim 10: This claim describes a system for generating and implementing a barcode. The system includes a data generation device that receives data and creates barcode data. A barcode generation device then receives this barcode data and generates a barcode. A display device shows the barcode, and a barcode receiving device (e.g., a mobile device) receives and processes the barcode, operating in response to its data.
• Claim 19: This claim describes a method for processing a barcode via a mobile device. It involves a mobile device uploading barcode data by scanning a displayed barcode. The mobile device determines if a Uniform Resource Locator (URL) is present in the barcode data. If a URL is present, the mobile device uses it for data transfer to a web server or for authenticating the barcode content before further processing the data string. If no URL is present, the mobile device directly processes and stores the barcode data for display and user interaction.

CAFC 2026 Dockets: A search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not yield any specific litigation cases involving patent US11664123. The provided patent information indicates that a litigation case has been filed in the Texas Western District Court, but this is not a CAFC docket.

Known litigation involving US patent 11664123:

Case 1:

• Plaintiff(s): iScan2D Technologies, LLC
• Defendant(s): [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.)
• Jurisdiction: Western District of Texas
• Case Number: 1:25-cv-01794
• Filing Date: November 7, 2025 (Initial filing), February 2, 2026 (First Amended Complaint)
• Outcome or Current Status: This case is ongoing. iScan2D Technologies, LLC alleges that Apple's Apple Watch and iPhone products infringe claims of US Patent 11664123 (and US Patent 12230394) related to wirelessly pairing devices using a color-coded digital scannable media. The alleged infringement by Apple Watch products began on or after May 30, 2023.

Proceedings overview

There is currently one AIA trial proceeding on file for US Patent 11664123. This Inter Partes Review (IPR) is in a pending status. This means the patent's claims remain untested by the PTAB, and no claims have been invalidated or sustained through an AIA trial. For a defendant, this indicates that the patent is currently under challenge, but its validity has not yet been substantively reviewed by the PTAB.

IPR2026-00316 — [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.) v. Sean McKirdy

• Type: Inter Partes Review
• Filed: 2026-05-18
• Status: Pending. The petition has been filed and is awaiting a decision on institution.
• Judge panel: Not yet assigned. As of October 2025, decisions on institution for IPR and PGR trials are made by the USPTO Director in consultation with at least three Administrative Patent Judges (APJs).
• Petition grounds: Details of the specific claims challenged and the prior art asserted are not yet publicly available, as the petition has only just been filed.
• Institution decision: Not yet issued. The USPTO Director's decision on whether to institute the trial is typically due within six months of the petition's filing date. For this proceeding, the institution decision is anticipated around November 18, 2026.
• Final Written Decision: Not applicable, as the trial has not yet been instituted.
• Settlement / termination: Not applicable.
• Appeal: Not applicable.
• Defensive value: This proceeding indicates that US Patent 11664123 is currently under challenge by Apple Inc. However, since the IPR is in its very early stages, no claims have been determined to be unpatentable. A defendant facing assertion of this patent should monitor the institution decision closely, as institution of the IPR would signal a potentially viable validity challenge.

Strategic summary

Currently, all claims of US Patent 11664123 remain UNTESTED by the PTAB. No claims have been canceled or sustained through an AIA trial proceeding. The ongoing IPR2026-00316 is a newly filed petition by Apple Inc., and as such, the PTAB has not yet made a determination on whether to institute a trial. This means the scope and validity of the patent's claims have not been narrowed by any PTAB decision to date.

Regarding the estoppel landscape, since IPR2026-00316 has not yet reached a final written decision (or even an institution decision), no statutory estoppel under 35 U.S.C. § 315(e)(2) has attached to Apple Inc. or its privies. This means that if the IPR is denied institution, or if it settles before a final written decision, Apple would not be estopped from raising the same or reasonably could have raised prior-art grounds in other forums (e.g., district court litigation), subject to other doctrines like Fintiv discretionary denials (though the Fintiv factors for discretionary denial have been significantly refined and are now influenced by U.S. manufacturing considerations and directorial review).

There are no apparent pattern signals of multiple IPRs by the same petitioner on this specific patent, given only one proceeding is currently on file. The involvement of Apple Inc. as a petitioner, however, signals a significant challenger, especially considering the existing litigation in the Western District of Texas.

Recommended next steps

• Monitor IPR2026-00316 closely: The critical next milestone for this proceeding is the institution decision, which is expected around 2026-11-18. This decision will indicate whether the PTAB believes there is a reasonable likelihood that at least one challenged claim is unpatentable.
• Review the petition: Once the petition for IPR2026-00316 becomes publicly accessible via the USPTO PTAB E2E portal, it is crucial to review the specific claims challenged, the prior art asserted, and the legal arguments presented by Apple Inc. This will provide insight into the perceived weaknesses of US11664123.
• Consider discretionary denial factors: Recent changes in PTAB policy, including the USPTO Director's direct role in institution decisions and the consideration of U.S. manufacturing activity, may influence the outcome of the institution decision. These factors should be taken into account when assessing the likelihood of institution.

Inventors

• Sean McKirdy: Employer not determinable from the patent text. The original assignee is listed as "Individual", suggesting Sean McKirdy was self-employed or acting in an individual capacity at the time of filing.

Original assignee

The entity named as the original assignee on the issued patent is Individual, referring to the inventor, Sean McKirdy. As an individual inventor, they do not typically ship products embodying the claims. Their primary line of business was invention and development related to the patent's subject matter. The individual subsequently assigned the patent rights, so they are no longer the current assignee.

Assignment timeline

• 2025-10-31 (executed) / recorded 2025-11-06 — Reel 062752/0146
  • Conveyance: ASSIGNMENT OF ASSIGNOR'S INTEREST
  • Assignor: MCKIRDY, SEAN
  • Assignee: ISCAN2D TECHNOLOGIES, LLC
  • Correspondent: BRENTON A. PALMER, ESQ., THE LAW OFFICE OF BRENT PALMER LLC, 502 E. JOHN CARPENTER FWY., SUITE 500, IRVING, TX 75062.
  • Context: Transfer of patent rights from the individual inventor to an asserting entity.

Timeline diagram

timeline
    title Ownership of US 11664123
    2021 : Filed by Sean McKirdy Individual
    2023 : Issued to Sean McKirdy Individual
    2025 : Assigned to ISCAN2D Technologies LLC
         : First infringement suit filed

NPE / troll-pattern signals

1. Shell-entity transfer — present. The patent was transferred from the individual inventor (Sean McKirdy) to "ISCAN2D TECHNOLOGIES, LLC" (Reel 062752/0146, executed 2025-10-31 / recorded 2025-11-06). The assignee's name, "Technologies, LLC," often indicates a licensing-focused entity, and its involvement in litigation (as noted in the litigation summary) supports this.
2. Known asserter in the chain — present. iScan2D Technologies, LLC is identified as the plaintiff in the Western District of Texas litigation (Case 1:25-cv-01794), actively asserting the patent against [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.)
3. Repeat correspondent across the chain — not present (in this chain). Brenton A. Palmer, Esq. is the correspondent for the single assignment recorded for this patent (Reel 062752/0146). While this attorney may represent multiple asserting entities, their recurrence within this specific patent's assignment chain cannot be confirmed from the provided data.
4. Cascading transfers — not present. Only one assignment is recorded in the chain.
5. Pre-litigation transfer — present. The assignment from Sean McKirdy to ISCAN2D TECHNOLOGIES, LLC was executed on 2025-10-31 and recorded on 2025-11-06 (Reel 062752/0146). The first infringement suit by iScan2D Technologies, LLC against Apple Inc. was filed just seven days later, on 2025-11-07. This tight timeframe strongly indicates the transfer was arranged to enable assertion.
6. Bankruptcy fire-sale — not present. There is no indication of the original assignee undergoing bankruptcy proceedings.
7. Privateering — unclear. While ISCAN2D TECHNOLOGIES, LLC is asserting the patent, there is no explicit information linking this assertion back to a specific operating company's strategic interests against its competitors.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at a known defensive aggregator.

Verdict

NPE — high confidence

This verdict is based on the strong signals of a shell-entity transfer from the individual inventor to ISCAN2D TECHNOLOGIES, LLC (Reel 062752/0146) and the immediate pre-litigation timing of this transfer (executed 2025-10-31 / recorded 2025-11-06, with litigation filed on 2025-11-07). Furthermore, ISCAN2D TECHNOLOGIES, LLC is actively asserting the patent, confirming its role as a patent assertion entity.

Verification: https://assignmentcenter.uspto.gov/ (search for patent number 11664123).

To identify the most relevant prior art for US patent 11664123, I will access the USPTO database for the patent and review its cited references. The USPTO provides a Patent Public Search tool for this purpose.

Based on a direct review of the patent document US11664123B2, the following prior art references are cited:

US Patent Documents:

• US2011/0267232 A1
  • Full Citation: US2011/0267232 A1 (McKirdy, Sean)
  • Publication Date: 2011-11-03 (This is a publication date, not a filing date. The priority date for US11664123 is 2011-08-05).
  • Brief Description: This patent application, also by Sean McKirdy, describes a system and method for creating and implementing an exercise regime based on user data, including biometric data and exercise equipment data. It discusses generating unique codes (which could be barcodes) based on this data to track and manage workouts.
  • Potential Anticipation (35 U.S.C. § 102): US2011/0267232 A1 is a prior publication by the same inventor as US11664123. Given the common inventorship and the description of generating codes (including barcodes) responsive to user and exercise data, this document is highly relevant. It could potentially anticipate claims in US11664123, especially those related to generating barcode data from exercise and biometric information, and using a mobile device to interact with it (e.g., Claim 1 and Claim 10 which describe generating barcode data from user data and displaying a barcode for a mobile device to receive and process, and Claim 19 which describes a mobile device processing barcode data). However, since it is a publication by the same inventor, the "grace period" provisions of 35 U.S.C. § 102(b)(1)(A) would likely apply if the disclosure was made less than one year before the effective filing date of US11664123. The priority date of US11664123 is 2011-08-05, and the publication date of US2011/0267232 A1 is 2011-11-03, which falls within this one-year grace period.
• US8118709 B2
  • Full Citation: US8118709 B2 (McKirdy, Sean)
  • Publication Date: 2012-02-21 (This is the issue date. The filing date for this patent was 2011-03-09.)
  • Brief Description: This patent, also by Sean McKirdy, describes a method and system for controlling and communicating with exercise equipment, including the ability to transfer data to and from mobile devices and backend systems. It focuses on using a "communication module" to obtain data from exercise machines. The contents of this patent are explicitly incorporated by reference into US11664123.
  • Potential Anticipation (35 U.S.C. § 102): US8118709 B2, as a prior patent by the same inventor, covers aspects of data communication with exercise equipment. Since US11664123 refers to sending data to a mobile device, USB drive, computer, etc., "using a method such as that described in U.S. Pat. No. 8,118,709," it indicates that US8118709 B2 lays foundational elements. The claims of US11664123 could be anticipated if they merely re-state or are obvious variations of the methods for data transfer and communication described in US8118709 B2, particularly concerning the interaction between exercise machines and other devices. For instance, elements of Claim 1 and Claim 10 that involve receiving user data from a device and processing it could be anticipated.

It is important to note that both of the highly relevant prior art documents cited are by the same inventor, Sean McKirdy. This suggests that US11664123 is likely a continuation or a related patent application building upon previous work, which is common. In such cases, the analysis under 35 U.S.C. § 102 (anticipation) often involves considering whether the new claims introduce novel and non-obvious subject matter over the inventor's own prior work, especially if the earlier disclosures are not covered by the grace period or if the claims of the later patent are not entitled to the filing date of the earlier applications.

Obviousness Analysis of US Patent 11664123 under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the claims of US Patent 11664123 obvious to a person having ordinary skill in the art (PHOSITA) as of the patent's priority date of August 5, 2011. The motivation to combine these references is also discussed.

Prior Art References:

1. US2011/0267232 A1 (McKirdy, Sean): Filed on March 9, 2011, and published on November 3, 2011, this prior art describes a system and method for creating and implementing an exercise regime based on user data, including biometric data and exercise equipment data. It specifically discusses generating unique codes, which could be barcodes, based on this data to track and manage workouts.
2. US8118709 B2 (McKirdy, Sean): Filed on March 9, 2011, and issued on February 21, 2012, this patent describes a method and system for controlling and communicating with exercise equipment. It includes the ability to transfer data to and from mobile devices and backend systems, focusing on using a "communication module" to obtain data from exercise machines. This patent is explicitly incorporated by reference into US11664123.

Both US2011/0267232 A1 and US8118709 B2 are considered prior art because their effective filing dates (March 9, 2011) precede the priority date of US11664123 (August 5, 2011). Furthermore, both references are by the same inventor, Sean McKirdy, indicating a strong inherent motivation for a PHOSITA to combine or integrate aspects of these related disclosures.

Combination: US2011/0267232 A1 in view of US8118709 B2

A PHOSITA, at the time of the invention, would have been aware of:

• The widespread use of barcodes (including 2D barcodes like QR codes) for storing various types of information, such as URLs, and their scanning by mobile device cameras.
• Mobile applications capable of decoding barcodes and performing actions based on their content (e.g., opening web pages, storing data).
• The growing need for efficient collection and management of personal health and fitness data.
• Existing methods for transferring data between electronic devices and backend systems.

The motivation to combine US2011/0267232 A1 with US8118709 B2 would be to create a more comprehensive and integrated system for managing exercise and health-related information, leveraging the strengths of both prior art documents.

Analysis of Claims:

Independent Claim 1: Method for generating and implementing a barcode.
Claim 1 outlines a method including:

• Receiving user data associated with device use.
• Generating barcode data responsive to the user data.
• Sending barcode data to a generator to create and display a barcode.
• Uploading the barcode data into a mobile device.
• Processing the barcode data, optionally involving a URL for data transfer to a web server or for authentication, or direct processing if no URL is present.

US2011/0267232 A1 explicitly teaches the core elements of generating codes (including barcodes) from user data (such as individual/machine performance and biological data) obtained from devices like exercise equipment, and then displaying these codes for scanning by a mobile device for processing and interaction.

The aspect of determining if a URL is present and then sending data to a web server or using the URL for authentication is made obvious by combining US2011/0267232 A1 with US8118709 B2. US2011/0267232 A1 broadly mentions "user data may include hyperlink information (i.e. Universal Resource Locator data)." Given the common knowledge that 2D barcodes (which are encompassed by the term "barcode" as defined in US11664123) can embed URLs, a PHOSITA would readily envision embedding a URL in the barcode data generated as per US2011/0267232 A1. US8118709 B2 explicitly describes methods for "sending data to a smart phone, USB drive, computer, tablet PC, etc using a method such as that described in U.S. Pat. No. 8,118,709, the contents of which is incorporated herein in its entirety." This clearly teaches the transfer of data to mobile devices and backend systems. The use of a URL to direct this data transfer to a web server, or to authenticate the barcode content, would be a conventional and obvious application of known internet and security protocols by a PHOSITA when combining the barcode generation and data communication aspects taught by these two references.

Independent Claim 10: System for generating and implementing a barcode.
Claim 10 describes a system comprising a data generation device, a barcode generation device, a display device, and a barcode receiving device (e.g., a mobile device).

The individual components of this system are either explicitly taught or clearly implicit in the combination of US2011/0267232 A1 and US8118709 B2. US2011/0267232 A1 describes a "data generation device" (e.g., an exercise device) that receives user data, and a "barcode generator internal or external to the machine" that processes this data to create a "barcode" for display. It also describes a mobile device for scanning the displayed barcode. US8118709 B2 further details communication modules for interacting with exercise equipment and mobile devices to transfer data. A PHOSITA would find it obvious to integrate these known functional blocks and devices to create the claimed system, as they are complementary and designed to work together to achieve the goal of data management, as already envisioned by the same inventor.

Independent Claim 19: Method for processing a barcode via a mobile device.
Claim 19 details a method where a mobile device uploads barcode data by scanning, determines if a URL is present, and then either uses the URL for data transfer/authentication or directly processes and stores the data.

US2011/0267232 A1 teaches that a "user may then upload the barcode data by scanning the barcode with their mobile device," and that the "mobile device processes the barcode data and if necessary, operates in response to the barcode data." This reference also discusses the mobile device storing and displaying processed barcode data for user interaction.

The addition of the URL-related logic (determining if a URL is present, using it for data transfer to a web server or for authentication) becomes obvious when considering the known capabilities of 2D barcodes (which were prevalent by the priority date) to embed URLs, combined with the data transfer mechanisms described in US8118709 B2. A PHOSITA would recognize that using an embedded URL for transferring scanned data to a web server, as enabled by the communication methods of US8118709 B2, is a conventional and logical extension of the mobile device processing described in US2011/0267232 A1. Similarly, using a URL for authentication is a standard practice in networked systems to ensure data integrity and user identity.

Conclusion:

The combination of US2011/0267232 A1 and US8118709 B2 would render the claims of US11664123 obvious to a PHOSITA. The motivation to combine these references is inherent due to their common inventorship and complementary subject matter aimed at developing an integrated solution for managing and processing health and exercise data. The specific features of embedding URLs in barcodes and using them for data transfer to web servers or authentication were well-known concepts in the art that a PHOSITA would have readily applied to the barcode generation and processing framework taught by the inventor's own prior work.

tool_code
print(google_search.search(queries=["US11664123 USPTO patent term adjustments", "US11664123 USPTO patent term extensions", "US11664123 continuation applications", "US11664123 divisional applications", "US11664123 related family members", "US11664123 projected expiration date"]))
thought
The user is asking for specific details about US patent 11664123 from the USPTO database. I need to find information regarding:

• Patent Term Adjustments (PTA)
• Patent Term Extensions (PTE)
• Continuation applications
• Divisional applications
• Related family members
• Projected expiration date

I will use Google Search to find this information, focusing on USPTO sources or reputable patent databases that provide such details. I will interpret the patent number literally as "US11664123".

Given the current date is 2026-05-18, I will ensure the information is as up-to-date as possible.

Let's break down the search strategy for each item:

1. PTA/PTE: I'll look for official USPTO records or patent database entries that specifically state PTA or PTE for US11664123. These are typically calculated and noted on the patent's front page or in the prosecution history.
2. Continuation/Divisional/Related Family Members: I'll look for sections within the patent document itself (e.g., "Cross-Reference to Related Applications") or in patent databases that list related applications (e.g., parent applications, child applications, continuations, divisionals, continuation-in-parts). The Google Patents link provided in the prompt already lists "Other versions" and "Priority to US17/181,423" and "Priority to US18/320,937", which will be useful for this.
3. Projected Expiration Date: This is typically calculated as 20 years from the earliest non-provisional filing date (or priority date if it's a continuation/divisional and claims benefit), plus any PTA, minus any disclaimers. The Google Patents page provides an "Anticipated expiration" date, which I will use and cross-reference with any other found information.

I already have the Google Patents link (https://patents.google.com/patent/US11664123/en) from the previous prompt, which is a good starting point to extract a lot of this information. I will prioritize this authoritative source.

Let's re-examine the provided Google Patents data for US11664123:

• Priority date: 2011-08-05
• Filing date: 2021-02-22 (for US17/181,423)
• Publication date: 2023-05-30
• Anticipated expiration: 2039-05-15

Under "Other versions" it lists:

• US20210350923A1

Under "Priority to" it lists:

• US17/181,423 (Filing date: 2021-02-22)
• US18/320,937 (Priority date: 2023-05-19) - This seems to be a later application, possibly a continuation. "patent/US12230394B2/en" is linked here, suggesting US12230394B2 is a child of US18/320,937.

Let's refine the plan:

1. Extract all family member information from the provided Google Patents data first.
2. Look for explicit mentions of PTA/PTE within the Google Patents text if available, or confirm with a search.
3. Confirm the expiration date calculation based on the earliest priority date and PTA/PTE.

From the Google Patents page, I can see:

• Application number: US17/181,423
• Priority date: 2011-08-05 (This is the earliest priority date mentioned)
• Filing date: 2021-02-22 (This is the filing date for US17/181,423, which matured into US11664123)
• Publication number: US11664123B2
• Publication date: 2023-05-30
• Anticipated expiration: 2039-05-15

The patent document itself should have the most authoritative information on related applications and PTA/PTE.

Let's check the Google Patents page for the "Cross-Reference to Related Applications" section in the full patent text to identify continuation, divisional, or continuation-in-part applications.

Looking at the full patent text provided in the prompt:

"CROSS-REFERENCE TO RELATED APPLICATIONS
This application is a continuation of U.S. patent application Ser. No. 17/181,423, filed on Feb. 22, 2021, which is a continuation-in-part of U.S. patent application Ser. No. 13/203,040, filed on Aug. 5, 2011, which is a continuation-in-part of U.S. patent application Ser. No. 12/625,699, filed on Nov. 25, 2009, which claims the benefit of U.S. Provisional Application No. 61/198,126, filed on Nov. 6, 2008, all of which are incorporated herein by reference in their entirety."

This section is crucial!
It states: "This application is a continuation of U.S. patent application Ser. No. 17/181,423, filed on Feb. 22, 2021".
However, the Google Patents info for US11664123 itself states its application number is US17/181,423. This appears to be a contradiction or a typo in the provided full text's "CROSS-REFERENCE TO RELATED APPLICATIONS" section, as a patent is its application.
Let's re-read the "Info" section from the Google Patents page at the very beginning of the provided text:
"Publication number US11664123B2
US17/181,423 (This is listed as a separate number, often indicating the application number for the granted patent.)"

So, US11664123B2 is the granted patent from application US17/181,423.
Therefore, the statement "This application is a continuation of U.S. patent application Ser. No. 17/181,423" is incorrect in the provided text for US11664123B2. It should rather state what US17/181,423 itself is a continuation of.

Let's assume the "CROSS-REFERENCE TO RELATED APPLICATIONS" section within the patent text describes the lineage of US17/181,423, which then became US11664123B2.

Corrected interpretation of "CROSS-REFERENCE TO RELATED APPLICATIONS" (as it applies to the application that led to US11664123B2, which is US17/181,423):

• US17/181,423 (filed Feb. 22, 2021, and matured into US11664123B2) is a continuation-in-part of:
  • U.S. patent application Ser. No. 13/203,040 (filed Aug. 5, 2011). This explains the "Priority date 2011-08-05" listed on Google Patents.
  • Which in turn is a continuation-in-part of:
    • U.S. patent application Ser. No. 12/625,699 (filed Nov. 25, 2009).
    • Which claims the benefit of:
      • U.S. Provisional Application No. 61/198,126 (filed Nov. 6, 2008).

This establishes the priority chain. The earliest priority date is November 6, 2008 (provisional). However, the Google Patents page explicitly lists "Priority date 2011-08-05". This is a discrepancy. I need to clarify which priority date is relevant for expiration calculation. Typically, expiration is 20 years from the earliest non-provisional filing date to which the patent is entitled, plus PTA. The "Priority date" listed on Google Patents usually refers to the earliest effective filing date from which benefits are claimed, for the purposes of prior art analysis.

Let's use the explicit "Priority date 2011-08-05" from the Google Patents "Info" section as the primary date for expiration calculation, as it's the one highlighted. The chain of continuations/CIPs listed in the full text must lead to this 2011-08-05 date as its effective filing date for the claims of US11664123. If 13/203,040 (filed Aug 5, 2011) is a CIP of 12/625,699 (filed Nov 25, 2009), then the claims in 11664123 could be entitled to the 2009 or even 2008 date if they are fully supported by those earlier disclosures. However, for a quick calculation, the earliest cited priority date in the Google Patents summary (2011-08-05) is usually what's used for the 20-year term.

Let's assume the "Anticipated expiration 2039-05-15" from Google Patents already accounts for PTA, and is based on the 2011-08-05 priority date, plus patent term adjustments.

Patent Term Adjustments (PTA) and Patent Term Extensions (PTE):
The Google Patents page itself does not explicitly state the PTA or PTE calculations, only the anticipated expiration. I need to search for this specifically.

Related Family Members:

• Parent applications:
  • U.S. patent application Ser. No. 17/181,423 (the application that matured into US11664123B2)
  • U.S. patent application Ser. No. 13/203,040, filed on Aug. 5, 2011
  • U.S. patent application Ser. No. 12/625,699, filed on Nov. 25, 2009
  • U.S. Provisional Application No. 61/198,126, filed on Nov. 6, 2008
• Other versions (publications): US20210350923A1 (this is the publication of application 17/181,423)
• Priority to US18/320,937: "Priority to US18/320,937 (Priority date: 2023-05-19) patent/US12230394B2/en" - This suggests US11664123 is a parent for US18/320,937 which eventually became US12230394B2. So this is a child application, not a parent.

Let's re-evaluate the "CROSS-REFERENCE TO RELATED APPLICATIONS" in the patent text and clarify the application that became US11664123.
The patent number is US11664123B2.
The application number is US17/181,423 (as stated on the Google Patents info page).

So, the "CROSS-REFERENCE TO RELATED APPLICATIONS" section within US11664123B2 is describing the lineage of US17/181,423.
Therefore:

• US17/181,423 (filed 2021-02-22) is a continuation-in-part of US13/203,040 (filed 2011-08-05).
• US13/203,040 (filed 2011-08-05) is a continuation-in-part of US12/625,699 (filed 2009-11-25).
• US12/625,699 (filed 2009-11-25) claims benefit of US Provisional Application No. 61/198,126 (filed 2008-11-06).

This confirms the chain of priority. The earliest effective filing date to which claims in US11664123 could be entitled, depending on the subject matter, dates back to the provisional application filed on November 6, 2008. However, the Google Patents summary for US11664123 explicitly lists the "Priority date" as 2011-08-05. This means that for at least the claims of US11664123, the earliest subject matter support for patentability purposes is considered to be from the application filed on that date (US13/203,040). The 20-year patent term is generally calculated from the earliest non-provisional filing date to which the patent claims benefit. Here, that would be 2011-08-05 (application 13/203,040), not the 2008 provisional or 2009 non-provisional, implying the claims of 116641423 are only supported by the 2011 application.

Let's confirm the expiration date. 20 years from 2011-08-05 is 2031-08-05. The "Anticipated expiration 2039-05-15" (from Google Patents) is significantly later than this, suggesting a substantial amount of Patent Term Adjustment (PTA) has been granted.

I will conduct targeted searches for PTA/PTE information, as Google Patents typically doesn't detail the breakdown of these adjustments.

Google search queries to confirm PTA/PTE:

• "US11664123 USPTO PTA"
• "US11664123 patent term adjustment"
• "US11664123 patent term extension"

And to confirm related applications and family members:

• "US11664123 family"
• "US11664123 continuation divisional"

I will use the Google Patents page as the primary source of truth for its directly listed information.

From the Google Patents page already provided in the prompt:
Publication number: US11664123B2
Application number: US17/181,423
Filing date: 2021-02-22
Priority date: 2011-08-05
Publication date: 2023-05-30
Anticipated expiration: 2039-05-15

Other versions:

• US20210350923A1 (This is the application publication of US17/181,423)

Priority to:

• US17/181,423 (This is the application itself, which is confusingly listed as a priority. It's the application that granted into US11664123.)
• US18/320,937 (Priority: 2023-05-19) which leads to US12230394B2. This means US11664123 is a parent of an application that matured into US12230394B2.

Let's use the explicit "CROSS-REFERENCE TO RELATED APPLICATIONS" from the full patent text to clearly define the family relationships for US11664123.

"This application [US17/181,423 leading to US11664123B2] is a continuation of U.S. patent application Ser. No. 17/181,423, filed on Feb. 22, 2021, which is a continuation-in-part of U.S. patent application Ser. No. 13/203,040, filed on Aug. 5, 2011, which is a continuation-in-part of U.S. patent application Ser. No. 12/625,699, filed on Nov. 25, 2009, which claims the benefit of U.S. Provisional Application No. 61/198,126, filed on Nov. 6, 2008, all of which are incorporated herein by reference in their entirety."

This first part of the sentence: "This application is a continuation of U.S. patent application Ser. No. 17/181,423, filed on Feb. 22, 2021" is a misstatement if "This application" refers to the granted patent US11664123. It should instead say that application 17/181,423 is a continuation of something else. However, the initial Google Patents data says the application number for US11664123 is US17/181,423.

So, the most accurate way to interpret the "CROSS-REFERENCE TO RELATED APPLICATIONS" is that it describes the lineage of the application (US17/181,423) that resulted in the patent (US11664123).

Therefore:

• US17/181,423 (the application for US11664123B2) is a continuation-in-part of US13/203,040.
• US13/203,040 is a continuation-in-part of US12/625,699.
• US12/625,699 claims benefit of US Provisional 61/198,126.

The earliest non-provisional filing date to which the patent is entitled, and from which the 20-year term typically begins, is the filing date of application 13/203,040, which is 2011-08-05.

So, the baseline expiration would be 2031-08-05.
The Google Patents anticipated expiration is 2039-05-15. This implies a PTA of about 7 years and 9 months.
I need to check if there is specific PTA or PTE information.
It's rare for Google Patents to explicitly show PTA/PTE breakdowns, but it does show an "anticipated expiration."
Let's confirm with a quick search if there's any explicit mention of PTA or PTE for US11664123.

If I don't find explicit PTA/PTE figures from external searches, I will rely on the "Anticipated expiration" from Google Patents and deduce that it includes any adjustments.

Regarding "continuation applications, divisional applications, related family members":

• Continuation/Continuation-in-Part applications (Parents):
  • U.S. patent application Ser. No. 13/203,040, filed on Aug. 5, 2011 (CIP of 12/625,699)
  • U.S. patent application Ser. No. 12/625,699, filed on Nov. 25, 2009 (CIP of 61/198,126)
• Provisional application (Parent):
  • U.S. Provisional Application No. 61/198,126, filed on Nov. 6, 2008
• Divisional applications: None explicitly mentioned as "divisional" in the cross-reference section for US11664123's lineage.
• Child applications (from Google Patents "Priority to"):
  • US18/320,937 (filed 2023-05-19), which matured into US12230394B2. This is a child application for which US11664123 serves as a parent.

Let's execute the search to confirm PTA/PTE.For US patent 11664123, here is a detailed breakdown of its prosecution history and projected expiration:

Patent Term Adjustments (PTA) and Patent Term Extensions (PTE)

The Google Patents record for US11664123 indicates an "Anticipated expiration" date of 2039-05-15. The statutory patent term is generally 20 years from the earliest non-provisional filing date to which the patent is entitled. For US11664123, based on its cross-reference to related applications, the earliest non-provisional filing date providing support for its claims is August 5, 2011 (for application Ser. No. 13/203,040).

A 20-year term from August 5, 2011, would lead to a base expiration date of August 5, 2031. The difference between this base date and the anticipated expiration date of 2039-05-15 suggests that a substantial Patent Term Adjustment (PTA) of approximately 7 years and 9 months has been granted. Specific details of the PTA calculation are typically found in the official USPTO patent issuance documents or the prosecution history, which are not explicitly provided in the current patent text or Google Patents summary beyond the anticipated expiration date. There is no information to suggest any Patent Term Extensions (PTE) have been applied.

Continuation and Divisional Applications

The "CROSS-REFERENCE TO RELATED APPLICATIONS" section within US11664123 details its lineage as follows:

• US17/181,423 (filed 2021-02-22), which matured into US11664123B2, is a continuation-in-part of U.S. patent application Ser. No. 13/203,040 (filed 2011-08-05).
• U.S. patent application Ser. No. 13/203,040 (filed 2011-08-05) is a continuation-in-part of U.S. patent application Ser. No. 12/625,699 (filed 2009-11-25).
• U.S. patent application Ser. No. 12/625,699 (filed 2009-11-25) claims the benefit of U.S. Provisional Application No. 61/198,126 (filed 2008-11-06).

Therefore, the parent applications to US11664123 are:

• U.S. patent application Ser. No. 13/203,040, filed on August 5, 2011.
• U.S. patent application Ser. No. 12/625,699, filed on November 25, 2009.
• U.S. Provisional Application No. 61/198,126, filed on November 6, 2008.

There are no explicit divisional applications mentioned in the cross-reference section for the lineage of US11664123.

Related Family Members

• Application for US11664123: US17/181,423 (Filing date: 2021-02-22)
• Publication of US17/181,423: US20210350923A1 (Publication date: 2021-11-11)
• Child Application: US11664123 also lists "Priority to US18/320,937" (Priority date: 2023-05-19), which later matured into US12230394B2. This indicates that US11664123 serves as a parent application for applications that led to US12230394B2.

Projected Expiration Date

The "Anticipated expiration" date for US11664123B2 is 2039-05-15. This date factors in any Patent Term Adjustments (PTA) applied to the standard 20-year patent term, which typically begins from the earliest non-provisional effective filing date, in this case, August 5, 2011.

Defensive Disclosure for US Patent 11664123: Barcode Generation and Implementation Method and System for Processing Information

This defensive disclosure aims to broaden the scope of publicly available prior art related to barcode generation, implementation, and processing, thereby rendering future incremental improvements by competitors obvious or non-novel. This document presents derivative variations for the core claims of US Patent 11664123, expanding upon its disclosed subject matter across various technical axes.

---

Derivatives of Independent Claim 1: Method for generating and implementing a barcode

Claim 1: A method for generating and implementing a barcode, comprising: receiving user data via a data generation device, the user data being associated with the use of the data generation device; generating barcode data responsive to the received user data; sending the barcode data to a barcode generator; creating the barcode responsive to the barcode data; displaying the barcode; uploading the barcode data into a mobile device; and processing the barcode responsive to the barcode data, wherein if a Uniform Resource Locator (URL) is present in the barcode data, the mobile device sends a data string to a web server via the URL, or the mobile device uses the URL to authenticate the barcode content for processing on the mobile device, and if no URL is present in the barcode data, the mobile device processes and stores the barcode data.

---

Derivative 1.1: Material & Component Substitution - Acoustic Barcodes for Sub-Optimal Visual Conditions

Enabling Description:
A method wherein the barcode is an acoustic barcode, generated by a specialized acoustic emitter (e.g., an ultrasonic transducer array or a modulated audible speaker system) and transmitted as a series of distinct sound patterns or modulated frequencies. The "displaying" step is replaced by "emitting" the acoustic barcode. The mobile device is equipped with a high-fidelity microphone array and a signal processing unit configured to perform Fast Fourier Transform (FFT) and spectral analysis to "scan" and decode the acoustic patterns. User data, such as machine diagnostics or environmental parameters, is encoded into varying pitch, tempo, and timbre sequences. Authentication URLs could be represented by specific, complex frequency signatures, allowing the mobile device to distinguish genuine acoustic barcodes. This enables information transfer in low-light, underwater, or visually obstructed environments.

flowchart TD
    A[Data Generation Device] --> B{Receive User Data (e.g., machine diagnostics)};
    B --> C[Generate Acoustic Barcode Data];
    C --> D[Acoustic Barcode Generator];
    D --> E[Acoustic Emitter Array];
    E -- Emit Acoustic Barcode --> F[Mobile Device w/ Mic Array];
    F --> G[Signal Processing & Decoding];
    G{URL Present?} -- Yes --> H[Transmit Data String to Web Server via URL (Acoustic Signature)];
    G{URL Present?} -- No --> I[Process & Store Acoustic Barcode Data];
    G{URL Present?} -- Yes & Authenticate --> J[Authenticate Barcode Content via Acoustic URL];

---

Derivative 1.2: Operational Parameter Expansion - Nanoscale Biological Barcodes for In-Situ Diagnostics

Enabling Description:
A method wherein "user data" comprises real-time molecular-level biological data (e.g., gene expression, protein concentrations, cellular metabolic states) obtained from a nanoscale biosensor array (the "data generation device") implanted within a biological sample or organism. "Barcode data" is generated responsive to these molecular signatures, encoding diagnostic information. The "barcode" is then created as a three-dimensional (3D) molecular construct, such as a DNA origami structure or a precisely arranged quantum dot array, which acts as a "nanobarcode." "Displaying" involves presenting this nanobarcode to a specialized molecular imaging system (e.g., a super-resolution microscope or a nanopore sequencing device acting as the "barcode receiving device"). The mobile device (e.g., a clinician's specialized tablet with a molecular imaging interface) then "uploads" (acquires and interprets) the nanobarcode data. Processing involves correlating the molecular patterns with known disease biomarkers, potentially using a URL (encoded as a specific molecular sequence) to access a distributed ledger for patient medical history.

flowchart TD
    A[Nanoscale Biosensor Array] --> B{Receive Molecular Biological Data};
    B --> C[Generate Molecular Barcode Data];
    C --> D[Molecular Barcode Assembler];
    D --> E[3D Molecular Nanobarcode];
    E -- Present to Imaging System --> F[Specialized Molecular Imaging System (Mobile Device Interface)];
    F --> G[Acquire & Interpret Nanobarcode Data];
    G{URL Present (Molecular Sequence)?} -- Yes --> H[Access Distributed Ledger for Patient History via Molecular URL];
    G{URL Present (Molecular Sequence)?} -- No --> I[Process & Store Molecular Barcode Data (e.g., Disease Biomarkers)];

---

Derivative 1.3: Cross-Domain Application - Geospatial Barcodes for Environmental Monitoring in AgTech

Enabling Description:
A method for managing environmental data in precision agriculture. The "data generation device" is an autonomous agricultural drone equipped with multispectral sensors, collecting "user data" such as soil moisture, nutrient levels, crop health indices, and pest presence across a large farm field. This geospatial data is processed into "barcode data." The "barcode generator" then creates a dynamic, high-density 2D barcode (e.g., a color-coded QR code or Data Matrix) that encapsulates location-specific environmental parameters. This barcode is "displayed" on a high-resolution, sunlight-readable display mounted on a ground-based weather station or a mobile robotic unit within the field. A farmer's "mobile device" (e.g., a ruggedized tablet with a high-resolution camera) "uploads" this barcode data. The processing involves overlaying the decoded data onto a farm management system's GIS map, with URLs embedded in the barcode directing to specific meteorological data archives or agricultural chemical databases for authenticated product recommendations.

flowchart TD
    A[Agricultural Drone w/ Multispectral Sensors] --> B{Receive Geospatial Environmental Data (Soil, Crop Health, Pests)};
    B --> C[Generate Geospatial Barcode Data (Location-Specific)];
    C --> D[Dynamic 2D Barcode Generator];
    D --> E[Sunlight-Readable Display (Weather Station/Robot)];
    E -- Display Barcode --> F[Ruggedized Tablet (Mobile Device)];
    F --> G[Scan & Decode Barcode Data];
    G{URL Present?} -- Yes --> H[Overlay Data on GIS Map & Access Ag Chemical/Meteorological DBs via URL];
    G{URL Present?} -- No --> I[Process & Store Geospatial Data for Farm Management];

---

Derivative 1.4: Integration with Emerging Tech - AI-Driven Barcode Generation with IoT and Blockchain for Supply Chain Logistics

Enabling Description:
A method applied to critical supply chain logistics. The "data generation device" consists of a network of IoT sensors monitoring a shipping container's internal environment (temperature, humidity, shock, light exposure) and the status of its contents (e.g., real-time inventory levels, item integrity via RFID tags). This IoT sensor data, combined with shipping manifests and provenance information, constitutes "user data." An AI-driven "barcode generation engine" (the "barcode generator") analyzes this data, predicts potential anomalies (e.g., spoilage risk), and generates "barcode data" that includes a dynamic status indicator and an embedded blockchain transaction hash. The "barcode" (e.g., a High Capacity Color Barcode or holographic QR code) is displayed on a flexible e-paper display affixed to the container. A logistics operator's "mobile device" (e.g., a custom industrial scanner with a cryptographic module) "uploads" the barcode data. Processing involves authenticating the blockchain hash against a distributed ledger, triggering smart contracts, and using embedded URLs to access AI-driven route optimization services or generate immediate insurance claims based on detected anomalies.

graph TD
    A[IoT Sensors (Container Temp, Humidity, Shock, RFID)] --> B{Collect Real-time Sensor Data & Shipping Manifests};
    B --> C[AI-Driven Barcode Generation Engine];
    C -- Predict Anomalies & Encode Data --> D[Dynamic HCCB/Holographic QR Barcode Data (Status, Blockchain Hash)];
    D --> E[Flexible E-Paper Display on Container];
    E -- Display Barcode --> F[Industrial Scanner w/ Cryptographic Module (Mobile Device)];
    F --> G[Scan Barcode & Decrypt Data];
    G{Blockchain Hash/URL Present?} -- Yes --> H[Authenticate against Distributed Ledger & Trigger Smart Contracts/Access AI Optimization Services via URL];
    G{Blockchain Hash/URL Present?} -- No --> I[Process & Store Logistics Data (e.g., Anomaly Reports)];

---

Derivative 1.5: The "Inverse" or Failure Mode - Emergency Low-Power Barcode for Critical Infrastructure

Enabling Description:
A method for emergency information dissemination from critical infrastructure components (e.g., a malfunctioning nuclear reactor cooling pump, a gas pipeline valve in distress). The "data generation device" is a diagnostic module within the component, continuously monitoring operational parameters. In the event of a critical system failure or power loss (the "failure mode"), the module automatically generates "user data" specifically detailing the failure type, safety protocols, and emergency contact information. The "barcode generator" creates a minimal, highly robust, and easily scannable barcode (e.g., a high-contrast 1D barcode or an optical pattern requiring minimal processing) optimized for low-power display. This "emergency barcode" is "displayed" on a chemically etched, phosphorescent display panel or a simple LCD powered by a backup supercapacitor. A first responder's "mobile device" (e.g., a ruggedized phone with enhanced low-light scanning capabilities) "uploads" this barcode data. If a URL is present (e.g., a direct link to an emergency response manual or a secure communication channel), the mobile device automatically establishes a secure connection. If no URL is present or connectivity is lost, the mobile device displays pre-loaded, cached emergency procedures relevant to the scanned failure code, ensuring operational continuity even in isolated environments.

stateDiagram-v2
    state Normal_Operation {
        [*] --> Monitoring
        Monitoring --> Failure_Detected : Critical System Failure
    }
    state Failure_Detected {
        Failure_Detected --> Generate_Emergency_Data : Low Power Mode Activated
        Generate_Emergency_Data --> Create_Low_Power_Barcode : Minimal Data Encoding
        Create_Low_Power_Barcode --> Display_Emergency_Barcode : Phosphorescent/Backup LCD
        Display_Emergency_Barcode --> Scan_by_First_Responder : Mobile Device
        Scan_by_First_Responder --> Process_Emergency_Data
        Process_Emergency_Data --> Check_URL_Presence
        Check_URL_Presence --> Send_Secure_Data : If URL Present
        Check_URL_Presence --> Display_Cached_Procedures : If No URL/No Connectivity
    }
    Send_Secure_Data --> End_Emergency_Protocol
    Display_Cached_Procedures --> End_Emergency_Protocol

---

Derivatives of Independent Claim 10: System for generating and implementing a barcode

Claim 10: A system for generating and implementing a barcode, comprising: a data generation device configured to receive data and generate barcode data responsive to the received data; a barcode generation device, configured to receive the barcode data and generate a barcode responsive to the received barcode data; a display device, configured to display the barcode; and a barcode receiving device, configured to receive the barcode and operate in response to the barcode.

---

Derivative 10.1: Material & Component Substitution - Tactile Barcode System for Visually Impaired Users

Enabling Description:
A system designed for visually impaired users. The "data generation device" receives environmental sensor data (e.g., temperature, humidity, light intensity) from a smart building system. The "barcode generation device" converts this data into a sequence of haptic patterns. The "display device" is a dynamic tactile display, comprising a grid of individually actuated pins (e.g., piezoelectric or shape-memory alloy actuators) that form a transient Braille-like "tactile barcode" or a pattern of raised textures. The "barcode receiving device" is a wearable haptic glove or a specialized finger-mounted sensor with an array of pressure-sensitive detectors that "reads" the tactile barcode. The barcode receiving device vibrates or provides audio feedback to the user based on the decoded environmental data, and can transmit this data to a paired mobile device for further processing or navigation assistance.

classDiagram
    class DataGenerationDevice {
        +receiveEnvironmentalData()
        +generateHapticBarcodeData()
    }
    class BarcodeGenerationDevice {
        +receiveHapticBarcodeData()
        +generateTactileBarcode()
    }
    class DynamicTactileDisplay {
        +actuatePins(pattern)
        +displayTactileBarcode()
    }
    class BarcodeReceivingDevice {
        +readTactileBarcode()
        +provideHapticFeedback()
        +transmitDataToMobileDevice()
    }
    DataGenerationDevice --> BarcodeGenerationDevice : generates
    BarcodeGenerationDevice --> DynamicTactileDisplay : outputs
    DynamicTactileDisplay <--> BarcodeReceivingDevice : interacts with
    BarcodeReceivingDevice --> MobileDevice : transmits data

---

Derivative 10.2: Operational Parameter Expansion - High-Energy Particle Barcode System for Astrophysical Data

Enabling Description:
A system for encoding and transmitting astrophysical data in extreme environments. The "data generation device" is a deep-space probe or ground-based observatory sensor array, collecting data on cosmic ray flux, neutrino detections, or gravitational wave signatures (the "data"). This data is processed by a "barcode generation device" into a sequence of high-energy particle emissions (e.g., modulated gamma-ray bursts or controlled neutrino streams). The "display device" is a directional particle accelerator or an exotic matter emitter, directing the "particle barcode" across vast interstellar distances. The "barcode receiving device" is a specialized celestial observatory or a deep-underground detector array capable of sensing and decoding these particle sequences. Operation at these scales involves immense energy levels and sophisticated error correction due to interstellar noise, allowing for robust data transfer across light-years. The receiving device would operate in response to detected particle patterns, triggering alerts for transient astrophysical events or cataloging new celestial phenomena.

sequenceDiagram
    participant P as Deep-Space Probe/Observatory
    participant BGD as Barcode Generation Device
    participant E as Particle Emitter (Display Device)
    participant D as Deep-Space Detector (Barcode Receiving Device)
    participant C as Central Computing System
    P->>BGD: Collect Astrophysical Data (Cosmic Ray, Neutrino, Grav Wave)
    BGD->>E: Generate & Encode Particle Barcode Data
    E->>D: Emit Particle Barcode (Light-Years)
    D->>D: Sense & Decode Particle Sequences (Error Correction)
    D->>C: Transmit Decoded Data (e.g., Event Alert, Catalog Update)
    C->>D: Operate in Response (e.g., Adjust Observation Parameters)

---

Derivative 10.3: Cross-Domain Application - Bio-Integrated Barcode System for Personalized Medicine

Enabling Description:
A system for in-vivo monitoring and personalized drug delivery within the medical domain. The "data generation device" is an array of biocompatible micro-sensors embedded within a patient, continuously measuring physiological markers (blood glucose, hormone levels, specific drug metabolites). The "barcode generation device," also implantable, translates this real-time biometric data into a sequence of biochemical signals. The "display device" is a bio-luminescent or fluorescent polymer matrix, embedded just beneath the skin, which generates a visible or near-infrared "bio-barcode" pattern directly readable through the skin. The "barcode receiving device" is a wearable diagnostic patch (e.g., a smart watch with optical sensors) that captures the bio-barcode. This device operates in response, initiating precise, localized drug release from an integrated microfluidic delivery system, or wirelessly communicating health alerts to a physician's mobile device, using encrypted URLs embedded in the bio-barcode to access electronic health records for dosage verification.

flowchart LR
    A[Implantable Micro-Sensors] --> B(Real-time Biometric Data);
    B --> C[Implantable Barcode Generation Device];
    C --> D(Biochemical Signal Sequence);
    D --> E[Bio-Luminescent/Fluorescent Polymer Matrix (Display Device)];
    E -- Emit Bio-Barcode (Through Skin) --> F[Wearable Diagnostic Patch (Barcode Receiving Device)];
    F --> G(Capture & Decode Bio-Barcode);
    G{Embedded URL/Data?} -- Yes --> H[Initiate Localized Drug Release / Transmit Health Alert to Mobile Device w/ EHR Access];
    G{Embedded URL/Data?} -- No --> I[Local Data Logging & Analysis];

---

Derivative 10.4: Integration with Emerging Tech - Quantum Barcode System with AI and Decentralized Ledger for Intellectual Property Verification

Enabling Description:
A system for immutable intellectual property (IP) verification. The "data generation device" receives digital content (e.g., source code, high-resolution media, CAD files) and metadata (creator, timestamp, revision history). An AI-driven "barcode generation device" analyzes this content, identifies unique cryptographic features, and generates "quantum barcode data." This data encodes a quantum state that is then imprinted onto a physical medium (e.g., a quantum dot array, a polarized light pattern) by a "quantum emitter display device." This ephemeral "quantum barcode" is displayed (or momentarily manifested). The "barcode receiving device" is a quantum sensor or a specialized optical-cryptographic scanner that can measure and interpret the quantum state. This system operates by verifying the quantum barcode against a decentralized quantum-resistant ledger (blockchain) for IP ownership and authenticity. The AI component continually monitors global data streams for potential IP infringement, generating new quantum barcodes with embedded URLs that link to legal enforcement smart contracts if violations are detected.

graph TD
    A[Digital Content (Source Code, Media, CAD)] --> B(Metadata: Creator, Timestamp, Revision);
    B --> C[AI-Driven Quantum Barcode Generation Device];
    C -- Encode Quantum State --> D[Quantum Barcode Data];
    D --> E[Quantum Emitter Display Device];
    E -- Manifest Quantum Barcode (Ephemeral) --> F[Quantum Sensor/Optical-Cryptographic Scanner (Barcode Receiving Device)];
    F --> G(Measure & Interpret Quantum State);
    G --> H[Verify against Decentralized Quantum-Resistant Ledger (Blockchain)];
    H{IP Verified?} -- Yes --> I[Immutable IP Record Stored];
    H{IP Verified?} -- No --> J[AI Triggers Legal Enforcement Smart Contract via Embedded URL];

---

Derivative 10.5: The "Inverse" or Failure Mode - Privacy-Preserving Ephemeral Barcode System for Anonymous Transactions

Enabling Description:
A system designed to prioritize user privacy by limiting data persistence and traceability. The "data generation device" is a user's local payment terminal generating transactional data (e.g., amount, merchant ID) without direct personal identifiers. The "barcode generation device" creates an "ephemeral barcode data" set that includes a single-use token and a short-lived, anonymized URL. The "display device" is a low-power, high-refresh-rate e-ink display that rapidly flashes the "ephemeral barcode" for a fraction of a second, making it difficult for unauthorized persistent capture. The "barcode receiving device" is a secure mobile payment application, configured to capture and process this fleeting barcode data within its secure enclave. The system operates such that the embedded URL is used only for immediate, anonymous transaction authorization and then immediately invalidates itself, preventing tracking. If the barcode is not scanned within its brief display window, it self-destructs and the transaction is aborted, preventing data leakage or misuse. Any attempt to re-scan an invalidated barcode results in a "fail-safe" response, displaying a generic "transaction expired" message without revealing any specific data.

stateDiagram-v2
    state Ready_for_Transaction {
        [*] --> Generate_Transactional_Data
        Generate_Transactional_Data --> Create_Ephemeral_Barcode : Single-Use Token, Anonymized URL
        Create_Ephemeral_Barcode --> Display_Ephemeral_Barcode : High-Refresh E-ink, Brief Flash
        Display_Ephemeral_Barcode --> Timeout : if not scanned quickly
        Display_Ephemeral_Barcode --> Scan_by_Mobile_App : Secure Enclave
        Scan_by_Mobile_App --> Process_Ephemeral_Barcode
    }
    state Process_Ephemeral_Barcode {
        Process_Ephemeral_Barcode --> Authenticate_Transaction_via_URL
        Authenticate_Transaction_via_URL --> Invalidate_URL : One-time use
        Authenticate_Transaction_via_URL --> Transaction_Complete : Success
        Authenticate_Transaction_via_URL --> Transaction_Aborted : Failure
    }
    state Timeout {
        Timeout --> Barcode_Self_Destructs
        Barcode_Self_Destructs --> Transaction_Aborted
    }
    state Scan_by_Mobile_App_After_Invalidation {
        Barcode_Self_Destructs --> Attempt_Re_Scan
        Attempt_Re_Scan --> Fail_Safe_Response : "Transaction Expired"
    }

---

Derivatives of Independent Claim 19: Method for processing a barcode via a mobile device

Claim 19: A method for processing a barcode via a mobile device, comprising: uploading barcode data into a mobile device by scanning a displayed barcode; determining if a Uniform Resource Locator (URL) is present in the barcode data; if a URL is present in the barcode data, the mobile device sending a data string to a web server via the URL; or if a URL is present in the barcode data, the mobile device using the URL to authenticate the barcode content for processing on the mobile device; and if no URL is present in the barcode data, the mobile device processing and storing the barcode data for display and user interaction.

---

Derivative 19.1: Material & Component Substitution - Olfactory Barcode Processing via Integrated Chemical Sensor Array

Enabling Description:
A method for processing "olfactory barcodes" representing chemical compositions. The "displayed barcode" is a modulated chemical vapor or a matrix of precisely arranged micro-capsules containing volatile organic compounds (VOCs) that release a specific scent profile. The "mobile device" is equipped with an integrated chemical sensor array (e.g., an electronic nose or a miniaturized gas chromatograph) rather than a camera. "Uploading barcode data by scanning" involves drawing air over the chemical sensors or physically interacting with the micro-capsules to detect the unique scent profile. The mobile device's processor analyzes the sensor output to "determine if a URL is present" – where a URL is represented by a specific, recognized combination of VOCs or a temporal release sequence. If present, the mobile device "sends a data string" (e.g., an alert about air quality or food spoilage) to a web server via this chemically encoded URL. Alternatively, the olfactory URL could "authenticate the barcode content" for processing, e.g., verifying the safety of a chemical substance. If no URL is detected, the device processes and stores the raw chemical signature for local analysis and display (e.g., identifying a particular fragrance or detecting environmental pollutants).

flowchart TD
    A[Displayed Olfactory Barcode (Chemical Vapor/Micro-capsules)] --> B[Mobile Device w/ Integrated Chemical Sensor Array];
    B --> C[Detect & Analyze Scent Profile (Scanning)];
    C{Specific VOC Combo/Sequence (URL) Present?} -- Yes --> D[Send Data String (e.g., Air Quality Alert) to Web Server via Olfactory URL];
    C{Specific VOC Combo/Sequence (URL) Present?} -- Yes & Authenticate --> E[Authenticate Olfactory Barcode Content (e.g., Chemical Safety)];
    C{Specific VOC Combo/Sequence (URL) Present?} -- No --> F[Process & Store Raw Chemical Signature for Local Analysis];

---

Derivative 19.2: Operational Parameter Expansion - Hyper-Spectral Barcode Processing for Geological Composition Analysis

Enabling Description:
A method for processing "hyper-spectral barcodes" from geological samples. The "displayed barcode" is a naturally occurring or synthetically enhanced mineralogical pattern on a rock face or core sample, exhibiting unique spectral reflectivity characteristics across a broad range of electromagnetic wavelengths. The "mobile device" is a handheld geological scanner with an integrated hyper-spectral imager and a broadband tunable laser (the "scanning" mechanism). "Uploading barcode data by scanning" involves illuminating the sample and capturing its reflected spectrum from UV to SWIR. The mobile device determines "if a URL is present" – where a URL is a predefined hyper-spectral signature linked to a specific mineral database or geological survey archive. If present, the mobile device "sends a data string" (e.g., mineral identification, elemental composition) to a specialized geological web server via this spectral URL for authenticated data comparison. If no URL is present, the device processes and stores the raw hyper-spectral data cube, enabling geologists to interact with 3D renderings of mineral distributions and identify novel formations locally. This operates at scales ranging from microscopic mineral inclusions to large rock formations.

graph TD
    A[Geological Sample w/ Hyper-Spectral Barcode] --> B[Handheld Geological Scanner (Mobile Device) w/ Hyper-Spectral Imager & Tunable Laser];
    B --> C[Illuminate & Capture Reflected Spectrum (Scanning)];
    C{Predefined Spectral Signature (URL) Present?} -- Yes --> D[Send Data String (e.g., Mineral ID, Elemental Comp) to Geological Web Server via Spectral URL];
    C{Predefined Spectral Signature (URL) Present?} -- Yes & Authenticate --> E[Authenticate Spectral Barcode Content (e.g., Sample Provenance)];
    C{Predefined Spectral Signature (URL) Present?} -- No --> F[Process & Store Raw Hyper-Spectral Data Cube for Local 3D Analysis];

---

Derivative 19.3: Cross-Domain Application - Linguistic Barcode Processing for Archival Document Management

Enabling Description:
A method for processing "linguistic barcodes" embedded within historical or archival documents for cultural heritage management. The "displayed barcode" is a unique textual or symbolic pattern, a specific font, or even a subtle watermark embedded within a scanned historical manuscript or microfiche. The "mobile device" is a specialized document scanner or a high-resolution camera-equipped tablet with Optical Character Recognition (OCR) and pattern recognition software. "Uploading barcode data by scanning" involves capturing a digital image of the document and performing advanced OCR and image analysis to extract the linguistic barcode data. The mobile device "determines if a URL is present" – where the URL is encoded as a specific string of characters, a unique glyph sequence, or a recognized watermark pattern. If present, the mobile device "sends a data string" (e.g., provenance metadata, transcription status) to a digital archive web server via the linguistic URL. This also allows for authentication of the document's originality. If no URL is present, the device processes and stores the document's textual content for local indexing, digital preservation, and display, allowing researchers to interact with annotated historical texts.

sequenceDiagram
    participant D as Archival Document w/ Linguistic Barcode
    participant M as Mobile Device (Scanner/Tablet w/ OCR)
    participant W as Digital Archive Web Server
    D->>M: Capture Digital Image (Scanning Document)
    M->>M: Extract Linguistic Barcode Data (OCR & Pattern Recognition)
    M->>M: Determine if URL Present (Specific Text/Glyph/Watermark)
    alt URL Present
        M->>W: Send Data String (Provenance/Transcription) via Linguistic URL
        M->>M: Authenticate Document Content via Linguistic URL
    else No URL Present
        M->>M: Process & Store Document Text for Local Indexing
    end
    M->>User: Display Content for User Interaction (Annotated Text)

---

Derivative 19.4: Integration with Emerging Tech - Biometric Barcode Processing with Federated Learning and Secure Enclave

Enabling Description:
A method for secure and privacy-preserving biometric authentication using a mobile device. The "displayed barcode" is a transient, pseudo-random pattern projected onto a user's skin (e.g., dynamic vein pattern, iris scan, facial micro-expression map) by a biometric sensor module, generated from unique physiological data. The "mobile device" is equipped with a high-speed optical sensor and a dedicated secure enclave (hardware-isolated processing unit). "Uploading barcode data by scanning" involves the mobile device capturing this projected biometric pattern. The device then "determines if a URL is present" – where the URL is a cryptographically signed instruction embedded within the biometric barcode, pointing to a federated learning server. If present, the mobile device uses this URL to initiate a federated learning round: it locally processes the biometric barcode data within its secure enclave (e.g., calculates a similarity score against a local biometric template) and then sends only the encrypted model update (the "data string"), not the raw biometric data, to the federated learning server for privacy-preserving authentication. This distributed model allows continuous, privacy-preserving authentication. If no URL is present, the device performs local, privacy-enhanced biometric verification against an on-device template and stores only an anonymized success/failure log.

stateDiagram-v2
    state Ready_for_Biometric_Scan {
        [*] --> Project_Biometric_Pattern : User's Skin
        Project_Biometric_Pattern --> Capture_Biometric_Barcode : Mobile Device (High-Speed Optical Sensor)
        Capture_Biometric_Barcode --> Process_in_Secure_Enclave
    }
    state Process_in_Secure_Enclave {
        Process_in_Secure_Enclave --> Determine_URL_Presence
        Determine_URL_Presence --> Initiate_Federated_Learning : If URL Present (Signed Instruction to FL Server)
        Initiate_Federated_Learning --> Send_Encrypted_Model_Update : Data String (Not Raw Biometric)
        Initiate_Federated_Learning --> Authenticate_Biometric : Using FL Server via URL
        Determine_URL_Presence --> Local_Biometric_Verification : If No URL
        Local_Biometric_Verification --> Store_Anonymized_Log
    }
    Authenticate_Biometric --> User_Authenticated
    User_Authenticated --> [*]
    Store_Anonymized_Log --> [*]

---

Derivative 19.5: The "Inverse" or Failure Mode - Data Redaction Barcode Processing for Privacy Breach Mitigation

Enabling Description:
A method where the mobile device actively protects sensitive information when processing barcodes under compromised conditions. The "displayed barcode" contains potentially sensitive "user data" (e.g., a medical record summary, financial transaction details). The "mobile device" has a built-in "privacy firewall" and context-aware sensors (e.g., ambient light, proximity, network security assessment). "Uploading barcode data by scanning" proceeds as usual. However, before "determining if a URL is present," the mobile device first assesses its operating environment and the barcode's content for sensitivity. If the environment is deemed insecure (e.g., public Wi-Fi, detected surveillance) or the barcode contains classified sensitive data (as identified by embedded metadata or content analysis), the device enters a "data redaction mode." In this mode, if a URL is present, the mobile device will not send the full data string. Instead, it sends only a "redacted data string" (e.g., anonymized aggregated data, a privacy-preserving zero-knowledge proof) to the web server, or uses the URL only for a minimal cryptographic authentication handshake, explicitly avoiding content transfer. If no URL is present, the mobile device processes and stores only the non-sensitive or redacted portions of the barcode data, displaying a heavily masked version for user interaction, actively preventing sensitive information exposure in a compromised state.

flowchart TD
    A[Displayed Barcode (Potentially Sensitive Data)] --> B[Mobile Device w/ Privacy Firewall & Context Sensors];
    B --> C[Scan & Upload Barcode Data];
    C --> D{Assess Operating Environment & Barcode Sensitivity?};
    D -- Insecure/Sensitive --> E[Enter Data Redaction Mode];
    E --> F{URL Present?};
    F -- Yes --> G[Send Redacted Data String/Minimal Crypto Auth to Web Server via URL];
    F -- No --> H[Process & Store ONLY Non-Sensitive/Redacted Data];
    H --> I[Display Masked Content for User Interaction];
    D -- Secure/Non-Sensitive --> J{URL Present?};
    J -- Yes --> K[Send Full Data String/Authenticate via URL];
    J -- No --> L[Process & Store Full Barcode Data];
    L --> M[Display Full Content for User Interaction];

---

Combination Prior Art Scenarios

These scenarios combine the concepts of US Patent 11664123 with existing open-source standards, thereby expanding the prior art landscape.

Combination Prior Art 1: Barcode-Driven IoT Device Provisioning using MQTT and QR Codes

Enabling Description:
A system and method for provisioning Internet of Things (IoT) devices in a smart home or industrial setting. A data generation device (e.g., an IoT gateway or a manufacturing line controller) generates configuration data (e.g., network credentials, device ID, security keys). This data is encoded into a standard QR code (the "barcode"). The barcode is displayed on a display device (e.g., a temporary screen on the IoT device itself, or a provisioning station). A mobile device (e.g., a technician's smartphone running an open-source provisioning app) scans the QR code. The mobile device processes the barcode data, extracts the configuration information, and then uses the MQTT open-source protocol to securely transmit this data to the IoT device over a local network. If an embedded URL (e.g., an mqtt://broker.example.com URI) is present in the QR code, the mobile device uses it to automatically discover and connect to the correct MQTT broker. This allows for rapid, standardized, and secure deployment of IoT devices without manual configuration.

Open-source standard: MQTT (Message Queuing Telemetry Transport) protocol for lightweight messaging.

Combination Prior Art 2: Geospatial Barcode for Field Data Collection and OpenStreetMap Integration

Enabling Description:
A method for decentralized, crowdsourced geospatial data collection. Environmental sensors (the "data generation device") deployed in remote areas periodically generate location-tagged observations (e.g., air quality, water levels, wildlife sightings). This data is converted into a geospatial barcode (e.g., a high-density Data Matrix or Aztek code) which includes latitude/longitude, sensor readings, and a timestamp. The barcode is displayed on a robust, low-power e-ink display at the sensor location. A hiker's mobile device (e.g., a smartphone with a custom app) scans this barcode. The mobile device processes the data, and if a URL is present (linking to an OpenStreetMap-based data repository), it automatically uploads the sensor readings, authenticated by a user token, to the shared geospatial database. If no URL is available (e.g., offline mode), the data is stored locally and overlaid onto an OpenStreetMap layer within the mobile application for later synchronization, enabling community-driven mapping and environmental monitoring.

Open-source standard: OpenStreetMap (OSM) for collaborative mapping data.

Combination Prior Art 3: Barcode-Driven Educational Content Delivery with SCORM Integration

Enabling Description:
A system and method for delivering interactive educational content in a physical learning environment. An educational kiosk or interactive exhibit (the "data generation device") provides learning modules. Based on a user's progress or selection, the kiosk generates "barcode data" containing a reference to a specific SCORM (Sharable Content Object Reference Model) package and a user's session ID. This barcode is displayed on the kiosk's screen. A student's mobile device (e.g., a tablet running a learning management system app) scans the barcode. The mobile device determines if a URL is present (e.g., linking to a SCORM-compliant Learning Management System - LMS). If a URL is present, the mobile device sends the student's session ID and SCORM package reference to the LMS server, which then streams the relevant educational content. The LMS can track the student's progress and scores within the SCORM standard. If no URL is present (e.g., for offline practice), the mobile device retrieves and executes a cached SCORM package locally, allowing the student to interact with the content even without an internet connection, with progress stored for later LMS synchronization.

Open-source standard: SCORM (Sharable Content Object Reference Model) for e-learning content packaging and tracking.