Defensive Publication: TID-Anchored Authentication of Pharmaceutical Items via Manufacturer-Published EPCIS Aggregation as a Replacement for Centralized Decommissioning Registries

Author: Aaron Sundman, CCL eAgile

First public disclosure: GS1 Connect annual conference, Las Vegas, June 2026, in front of an audience of approximately 200 RFID industry attendees during a presentation given by the author.

Publication date of this document: June 30, 2026

Purpose: This document is published defensively to establish prior art. Its purpose is to make the methods, systems, and combinations of techniques described below freely available for adoption by any party in the pharmaceutical supply chain, and to prevent any party from obtaining a patent that would block the industry from using these techniques. The author makes no claim of patent rights over the methods described herein and explicitly places these methods into the public technical record.

1. Abstract

This document discloses a method and system for authenticating individual pharmaceutical items, including units of use such as syringes and vials, by pairing a programmable Electronic Product Code (EPC) carried on an RFID tag with the chip's factory-burned Tag Identifier (TID), and by publishing that pairing as part of the manufacturer's EPCIS 2.0 aggregation event records. The combination is resolved at scan time using a GS1 Digital Link URL constructed from a hostname encoded directly in the SGTIN++ or SSCC++ EPC, which routes the verification query to the manufacturer's own EPCIS resolver. The disclosed method allows any party in possession of the physical RFID-tagged item to independently verify that the chip is the same physical chip the manufacturer encoded, without consulting any central registry, and therefore eliminates the operational and architectural need for a centralized decommissioning system of the type currently used under the European Union's Falsified Medicines Directive (EU FMD). The method extends authentication coverage from the unit of sale, which is the scope of present-day pharmaceutical serialization, down to the unit of use level (individual vials, syringes, ampoules, and similar items) without any change to the underlying EPCIS or RAIN UHF standards.

2. Background and Motivation

2.1 The unit-of-sale versus unit-of-use gap

Pharmaceutical traceability regulations, including the United States Drug Supply Chain Security Act (DSCSA) and the EU FMD, require serialization of pharmaceutical products at the unit of sale. The unit of sale is the sealed outer package that moves through the regulated supply chain, for example a sealed carton containing ten pre-filled syringes or twenty-four vials. The individual syringes and vials inside the box (the units of use) are not serialized under these regulations. Once a sealed box is opened in a pharmacy, the items inside become electronically anonymous. They are interchangeable from the perspective of any electronic verification system, and there is no automatic way to confirm at the point of administration that a particular vial pulled from a shelf is the same vial that was packed at the manufacturer.

2.2 The decommissioning approach

To prevent counterfeit items with valid-looking serial numbers from being introduced into the supply chain after a legitimate item has been consumed, the EU FMD requires a decommissioning event: when a pharmacy dispenses a pack, that pack's serial number is reported to a central national repository, which marks the serial as consumed. Subsequent scans of the same serial number can then be flagged as suspicious. The decommissioning approach requires three things to function:

  1. A central registry, operated nationally or supra-nationally.
  2. Universal participation by every dispensing party.
  3. A network round trip from every point of dispensing to the registry.

The decommissioning approach functions in jurisdictions with a strong centralized regulator that can compel participation, as the EU does for EU FMD. It is unlikely to scale globally because global participation is voluntary, regulatory regimes vary, and the registry itself is a single point of failure and a central authority that many participants resist. Decommissioning also operates at the unit-of-sale level only; it does not address counterfeiting or substitution at the unit-of-use level once a box is opened.

2.3 The TID and prior art on TID usage

Every RFID chip compliant with the EPCglobal Class-1 Generation-2 (Gen2) protocol, including RAIN UHF chips manufactured by Impinj, NXP, Alien, and others, carries a Tag Identifier (TID) in its TID memory bank. The TID is a unique identifier programmed during semiconductor fabrication, before the chip is encoded with application data. The TID is read-only and cannot be modified by any field-programmable RFID writer. It is, in a meaningful semiconductor sense, immutable. The TID is structured according to the Gen2 standard and includes a vendor mask designator (for example, the prefix E280 identifies an Impinj-manufactured chip), followed by vendor-specific structure.

The general concept of "TID pairing" or "TID-based authentication" has existed since the introduction of unique TIDs on RFID chips. Various industries, including retail apparel and luxury goods, have used TID lookups for anti-counterfeit purposes, typically by maintaining a vendor-side database that maps EPC values to TID values and offering a query API.

What this document discloses is not the bare concept of TID pairing. What it discloses is a specific combination of TID pairing with the GS1 EPCIS 2.0 aggregation event format, the SGTIN++ and SSCC++ EPC encodings (as standardized in GS1 Tag Data Standard 2.3), and the GS1 Digital Link resolver pattern, applied to the pharmaceutical supply chain as a replacement for centralized decommissioning systems and as an extension of serialization coverage from the unit of sale down to the unit of use.

3. The Disclosed Method, in Brief

The method has six elements that are routinely combined in the disclosed system. Each element is described in greater detail in subsequent sections.

  1. The manufacturer programs each RFID tag with an EPC. The encoding used depends on the role of the tag in the supply chain. Parent containers that may be scanned without prior context (units of sale, cases, pallets) use the SGTIN++ or SSCC++ encoding, which carries a manufacturer resolver hostname directly in the EPC memory bank, in addition to the conventional GTIN or SSCC and serial number fields. The hostname is what allows a stand-alone scanner to discover the manufacturer's EPCIS resolver for an unknown container without consulting any central directory. Unit-of-use items inside a parent container (individual syringes, vials, ampoules) can be encoded with plain SGTIN (GTIN and serial only). SGTIN+ (which can add lot and expiry to the basic GTIN and serial) is a recommended practical choice for pharmaceutical unit-of-use items where the additional clinical context is useful at the bedside, but neither SGTIN+ nor SGTIN++ is required for the authentication method described here. Unit-of-use items do not need to carry the resolver hostname because their identity and authenticity are resolved through the parent container's aggregation record, which already names every child by GTIN and serial.
  2. At the moment of tag programming, the manufacturer reads the chip's factory-burned TID from the tag's TID memory bank, and records the triple (GTIN, serial, TID) in the manufacturer's EPCIS database alongside any other aggregation data (parent serial, lot, expiry, and so forth).
  3. The manufacturer publishes EPCIS 2.0 aggregation events through a resolver service hosted at the hostname encoded into the tag. Each aggregation event includes, for every child item listed in the aggregation, the child's EPC together with the child's TID, in extension fields of the EPCIS JSON-LD document.
  4. The aggregation event is published at a URL constructed according to the GS1 Digital Link standard, of the form https://<host>/01/<GTIN>/21/<serial>?linkType=gs1:epcis, where <host> is the hostname extracted from the tag, and <GTIN> and <serial> are the corresponding values from the tag's EPC.
  5. At the receiving point in a supply chain (a distributor receiving dock or a pharmacy receiving area), the receiving party scans all tags in an inbound shipment, reads both the EPC and the TID from each tag, resolves the manufacturer's aggregation record via the GS1 Digital Link URL, and caches the manufacturer's record in a local database. The cache key is the EPC; the cached value includes the manufacturer's TID for that EPC and the EPCs and TIDs of all child items in the aggregation.
  6. At any subsequent point in the lifecycle of the item, including at the point of administration of an individual vial or syringe to a patient, an RFID reader scans the item, reads its EPC and TID, performs a local lookup against the cached manufacturer record, and confirms that the TID read from the physical chip in hand matches the TID published by the manufacturer for that EPC. A match constitutes authentication. A mismatch indicates a clone of the EPC on a different physical chip and is treated as a counterfeit. The lookup at the point of administration is a local operation only; no network call to the manufacturer is required.

The combination of these six elements is what is being disclosed.

4. Standards and Technical Components

Each component below is a published, public standard. The disclosed method does not require modification of any of these standards; it composes them in a specific way.

4.1 EPCglobal Class-1 Gen-2 UHF RFID protocol (RAIN UHF)

The RAIN UHF protocol defines a chip with four memory banks:

The TID memory bank includes at minimum a 32-bit TID consisting of a class identifier, a vendor mask designator, and a vendor-specific structure. Most modern chips include an extended TID that adds a 48-bit or longer factory serial number, making the full TID globally unique across all chips produced by all vendors. The full TID is read-only at the silicon level. There is no field operation that can rewrite TID memory; the TID is established during semiconductor fabrication and cannot be modified after that point.

4.2 GS1 Tag Data Standard (TDS) 2.3 SGTIN++ and SSCC++

GS1 TDS 2.3 defines the SGTIN++ EPC encoding for unit-of-sale and unit-of-use items, and the SSCC++ EPC encoding for shipping containers. Both encodings include a field for a manufacturer's resolver hostname directly in the EPC memory bank of the tag. Decoding the EPC at scan time yields the GTIN, the serial number, optional fields including lot and expiry, and the resolver hostname. The hostname field is the architectural innovation that makes the method described here decentralized: every tag carries, in its own memory, the address of the manufacturer's resolver where the authoritative aggregation record can be retrieved. There is no centralized directory of manufacturer resolvers. The tag is the directory.

Typical SGTIN++ encoded data sizes approach 256 bits once the resolver hostname, the GTIN, the serial number, and optional lot data are all included. The 256-bit envelope is well within the capacity of modern RAIN UHF chips, including chips with extended EPC memory banks supporting up to 496 bits.

4.3 EPCIS 2.0

EPCIS (Electronic Product Code Information Services) 2.0 is a published standard for representing supply chain events as structured data records, typically encoded as JSON-LD. The EPCIS 2.0 specification includes the AggregationEvent type, which records the act of packing one or more child items (for example, syringes) into a parent container (for example, a 10-pack box). EPCIS supports extension fields under custom namespaces, allowing implementers to add data fields that the standard does not specify, while remaining compliant with the standard.

4.4 GS1 Digital Link

GS1 Digital Link is a published standard for encoding GS1 identifiers (including GTIN and serial number) into HTTPS URLs. A typical Digital Link URL for a serialized item is https://<resolver-host>/01/<GTIN>/21/<serial>. The standard allows query parameters indicating the type of resource being requested, for example ?linkType=gs1:epcis to request an EPCIS document, or ?linkType=gs1:pip to request product information.

4.5 Operation Brilliance (RAIN Alliance)

Operation Brilliance is the RAIN Alliance work item that promotes the use of SGTIN++ encodings, EPCIS 2.0 aggregation events, and unit-of-use serialization in the pharmaceutical supply chain. The disclosed method is consistent with the goals of Operation Brilliance and uses encodings and event formats it advocates.

5. Tag Programming, TID Capture, and the Manufacturer's Authoritative Record

The (EPC, TID) pairing is established by the pharmaceutical manufacturer and recorded in the manufacturer's EPCIS database. Two manufacturing patterns produce this record in practice; the disclosed method covers both, and the remainder of the method (EPCIS publishing, resolver hosting, receiving-party caching, point-of-administration authentication) is identical under either pattern.

Path A. In-line tag programming on the manufacturer's packaging line

In Path A, the pharmaceutical manufacturer programs blank-EPC tags on its own packaging line. This pattern is appropriate when the manufacturer wants to encode dynamic per-unit fields (lot, expiry) into the EPC at the time of packaging, using SGTIN+ or SGTIN++ encoding. The eight-step workflow is as follows.

  1. The chip arrives on the programming line with a factory-burned TID already in TID memory and incomplete application data in EPC memory.
  2. The programming station performs a Gen2 inventory and singulates a single tag.
  3. The programming station reads the full TID from TID memory bank 10. The TID is captured as a hexadecimal string and held in the programming station's working memory. A typical TID is 96 bits, for example E28011C020000F7D42440317, of which the first 32 bits encode the vendor mask designator and chip model, and the remaining bits encode the factory serial number.
  4. The programming station encodes EPC data for the item. For parent containers (units of sale, cases, pallets) the encoding is SGTIN++ or SSCC++, including the GTIN or SSCC, the serial number, optional lot and expiry data, the filter value, and the manufacturer resolver hostname. The hostname is selected from a configurable list per product line, typically the manufacturer's primary EPCIS resolver hostname. For unit-of-use items inside a parent container the encoding is plain SGTIN (GTIN and serial only) or SGTIN+ (GTIN, serial, lot, and expiry); the resolver hostname is omitted at the unit-of-use level because authentication of unit-of-use items is performed against the parent's aggregation record, which already names every child.
  5. The programming station writes the constructed EPC to EPC memory bank 01 of the tag.
  6. The programming station optionally locks the EPC memory bank with a permanent write lock to prevent any field-side modification.
  7. The programming station records the (GTIN, serial, TID, lot, expiry, hostname, programming timestamp, programming line identifier) tuple into the manufacturer's tag-programming database.
  8. The tag is associated with a physical item (vial, syringe, or whatever is being tagged) by automation or manual workflow at the manufacturing line, with the resulting (item, EPC, TID) association persisted.

Path B. Pre-programmed tags, TID captured at the aggregation step

In Path B, the pharmaceutical manufacturer sources pre-programmed RFID tags from a label converter or tag supplier rather than encoding them on the packaging line. Pre-programmed tags arrive at the manufacturer's packaging line and the manufacturer does no on-line EPC writing. This pattern is in use by several large pharmaceutical manufacturers as of this publication date, because it lets them adopt RFID without modifying the existing labeling process to support per-unit on-line encoding. Under Path B:

  1. Tags arrive at the manufacturer's packaging line already programmed with EPC values by the upstream converter. The TID is already present in TID memory from chip fabrication; the EPC is already present in EPC memory from converter-side programming.
  2. As each tag is applied to a physical item (vial, syringe, ampoule) and the item is packed into a parent container, the manufacturer's aggregation reader reads the tag and captures both the EPC and the TID in a single Gen2 read.
  3. The manufacturer's software records the (GTIN, serial, TID, parent EPC, parent TID, aggregation timestamp, packaging line identifier) tuple into the manufacturer's EPCIS database at this aggregation reading.
  4. The tag is associated with both the physical item and the parent container at the same moment, producing the same aggregation data structure that Path A produces at programming time.

Under Path B, the (EPC, TID) pair is established in the manufacturer's authoritative record at the aggregation step rather than at programming. The upstream converter knows the (GTIN, serial) pair (because the converter wrote it) but has no obligation to capture or report the TID, because the manufacturer captures the TID itself at the aggregation reading regardless of who did the original EPC programming.

Either path: the TID capture moment is the foundation

The TID capture step, whether performed at programming (step 3 of Path A) or at the aggregation reading (step 2 of Path B), is the critical point at which the (EPC, TID) pairing is established in the manufacturer's authoritative record. This pairing is the foundation of all subsequent authentication. No party other than the pharmaceutical manufacturer can establish this pairing in the manufacturer's EPCIS database, because the manufacturer is the party reading the physical chip at the capture moment and recording what it saw. A counterfeiter who later produces a tag with a cloned EPC but a different physical chip will produce a different TID at scan time, and the mismatch against the manufacturer's recorded TID is the authentication failure signal.

6. Aggregation and EPCIS Record Publication

Items are typically packed into parent containers. For example, ten pre-filled syringes are packed into a 10-pack box (the unit of sale), and ten 10-pack boxes are packed into a shipping case. Each parent container is also tagged, typically with an SGTIN++ tag for the unit of sale and an SSCC++ tag for the shipping case. The parent tags follow the same programming process as the child tags. The manufacturer's aggregation system records which children are packed into which parent.

Once all children have been packed into a parent, the manufacturer's EPCIS publishing system generates an AggregationEvent record for that parent. The AggregationEvent is published at the GS1 Digital Link URL associated with the parent's EPC, accessible by HTTPS GET.

The AggregationEvent record contains, in addition to the standard EPCIS fields (event time, biz step, action, parent EPC, child EPCs), an extension array of child item records. Each child item record contains, at minimum, the child's EPC and the child's TID. A representative child item record, using an eagile namespace prefix for the extension fields, has the form:

{
  "eagile:epc": "https://id.gs1.org/01/00376045223033/21/84173524345281",
  "eagile:tid": "E28011C020000F7D42440317"
}

The eagile:epc field encodes the child's EPC as a GS1 Digital Link URL, using the canonical GS1 namespace id.gs1.org. The eagile:tid field encodes the child's TID as a hexadecimal string. The prefix eagile: is illustrative; any namespace prefix valid under EPCIS 2.0 extension rules may be used. The salient point is that the AggregationEvent published by the manufacturer contains, for every child item in the aggregation, both the child's EPC and the child's TID, as captured at programming time.

A complete aggregation event for a 10-pack of syringes therefore contains the parent's EPC, the parent's TID, the EPCs of all ten children, and the TIDs of all ten children. A complete aggregation event for a case of ten 10-packs of syringes contains the case-level SSCC, the case-level TID (if SSCC++ is used at the case level), the EPCs and TIDs of all ten 10-pack boxes, and optionally the EPCs and TIDs of all 100 individual syringes (the units of use) if the manufacturer chooses to publish unit-of-use aggregation directly.

The manufacturer may also publish more granular aggregations as separate AggregationEvent records keyed by parent EPC, allowing a consumer of the EPCIS data to drill down from the case to the unit of sale to the unit of use independently. The disclosure does not require any particular nesting strategy; it requires only that every aggregation event include the TIDs of the items it lists.

7. Resolver and GS1 Digital Link

The manufacturer hosts an EPCIS resolver service at the hostname that the manufacturer programmed into the EPC memory bank of every tag for the product line. The resolver answers HTTPS GET requests at URLs of the form:

https://<resolver-host>/01/<GTIN>/21/<serial>?linkType=gs1:epcis

The response is the AggregationEvent record for the item identified by the GTIN and serial, encoded as EPCIS 2.0 JSON-LD, with the TID extension fields described in section 6.

A representative request and response pair, using the demonstration resolver epcis.cc, is:

GET https://epcis.cc/01/30376045223300/21/17724760500010655?linkType=gs1:epcis

200 OK
Content-Type: application/json
{
  "@context": ["https://gs1.github.io/EPCIS/epcis-context.jsonld"],
  "type": "EPCISDocument",
  "epcisBody": {
    "eventList": [
      {
        "type": "AggregationEvent",
        "eventTime": "2026-06-04T12:00:00Z",
        "action": "ADD",
        "parentID": "https://id.gs1.org/01/30376045223300/21/17724760500010655",
        "childEPCs": [
          "https://id.gs1.org/01/00376045223033/21/84173524345281",
          "https://id.gs1.org/01/00376045223033/21/84173524345282",
          "..."
        ],
        "bizStep": "packing",
        "eagile:children": [
          {
            "eagile:epc": "https://id.gs1.org/01/00376045223033/21/84173524345281",
            "eagile:tid": "E28011C020000F7D42440317"
          },
          {
            "eagile:epc": "https://id.gs1.org/01/00376045223033/21/84173524345282",
            "eagile:tid": "E28011C020000F7D42440318"
          },
          "..."
        ]
      }
    ]
  }
}

The resolver is read-only from the perspective of every party other than the manufacturer. The manufacturer publishes records and updates them on its own schedule, typically immediately after aggregation events occur on the manufacturing line.

8. Receiving and Caching at the Distribution and Pharmacy Levels

The receiving workflow at a distributor or pharmacy, on receipt of a shipment of pharmaceutical items, is as follows.

  1. The receiving party operates an RFID reader, typically a fixed reader at a receiving dock or a handheld reader at a verification station.
  2. The reader scans all tags on items, boxes, and shipping containers within range. For each tag, the reader reads both the EPC and the TID.
  3. For each scanned EPC, the receiving party's software constructs the GS1 Digital Link URL using the hostname encoded in the EPC, the GTIN, and the serial. The software requests the URL via HTTPS GET and receives the AggregationEvent record from the manufacturer.
  4. The software persists the AggregationEvent record to a local database. The local database is keyed by partition (for multi-tenant systems), GTIN, and serial. The persisted value includes the parent TID, the EPCs of all children, and the TIDs of all children.
  5. The software performs a first-pass verification: for each scanned tag, it compares the TID just read from the physical chip against the TID published by the manufacturer for that EPC. A match confirms that the physical chip on the receiving dock is the same physical chip the manufacturer programmed. A mismatch is flagged for investigation.
  6. The software performs a second-pass verification of the aggregation: it verifies that every child EPC published by the manufacturer is present in the scan and that no extra children appear. Missing children are flagged subject to a configurable threshold; for example, the system may allow a unit-of-sale box to pass if at least 95% of expected unit-of-use children are present in the physical scan, on the theory that RFID reads are not 100% reliable in real-world conditions.
  7. The verified aggregation record is retained in the local database for the lifetime of the items, plus any audit retention period required by regulation.

After step 7, the local database contains a complete copy of the manufacturer's authoritative pairing data for every item the receiving party has admitted into inventory. Subsequent verification at the point of administration does not require a network call to the manufacturer.

9. Authentication at the Point of Administration

At the point of administration, when a clinician removes an individual unit-of-use item from inventory to administer to a patient, the verification workflow is as follows.

  1. The clinician's reader scans the tag on the individual item. The reader reads both the EPC and the TID.
  2. The reader's software constructs the local cache key from the GTIN and serial decoded from the EPC.
  3. The software looks up the cached aggregation record for that EPC in the local database. The lookup is a single indexed read; in a normal pharmacy database, this completes in milliseconds.
  4. The software compares the TID read from the physical chip against the TID stored in the cache for that EPC. A match is the authentication success signal. A mismatch is the authentication failure signal.
  5. The software also verifies that the cached record is not flagged as recalled, expired, or otherwise unavailable. These secondary checks are independent of the TID pairing logic.
  6. The reader displays the result to the clinician. Authentication success is a confirmation that the physical chip in hand is the same physical chip the manufacturer encoded for this EPC.

The entire workflow above is a local operation. No network call to the manufacturer is required at the moment of administration. The clinician does not wait on a remote API.

This is the property that makes the disclosed method operationally compatible with the pace and reliability requirements of bedside medication administration. Centralized decommissioning, by contrast, requires a network call to a national registry at the moment of dispensing. The TID-pairing method moves the network call to the receiving step, which can absorb network latency without affecting clinical workflow.

10. Why This Replaces Centralized Decommissioning

A centralized decommissioning system serves a single purpose: to prevent counterfeit items bearing valid-looking serial numbers from being accepted into the supply chain after a legitimate item bearing the same serial number has already been consumed. The decommissioning model assumes that a counterfeiter can produce a tag with an arbitrary EPC, and therefore the only defense is to track which EPCs have already been used and reject any subsequent claim.

The TID pairing model breaks the assumption that a counterfeiter can produce a tag with an arbitrary EPC. The counterfeiter can produce a tag with an arbitrary EPC; what the counterfeiter cannot produce is a tag with an arbitrary TID. The TID is factory-burned into the silicon at chip manufacture. To produce a counterfeit tag whose TID matches a legitimate manufacturer's published TID, the counterfeiter would have to physically obtain the original tag, extract the chip, and reuse it; producing a new chip with a chosen TID is not within the capabilities of any field-side adversary, and is at the level of cost and complexity of an actual semiconductor fabrication run for a state-level actor.

Once the counterfeiter cannot freely produce a tag with a chosen EPC, the need for a centralized "used" registry disappears. Authenticity becomes a property that can be verified from the physical chip itself, given access to the manufacturer's authoritative pairing data. The manufacturer's authoritative pairing data is published at a URL the tag itself names; the receiving party caches that data; the bedside scanner does a local lookup. Authentication is decentralized, asynchronous (with respect to the manufacturer), and globally scalable, because every manufacturer publishes their own data and every reader resolves it independently.

A side-by-side comparison of the two approaches is useful:

PropertyCentralized decommissioningTID-paired EPCIS authentication
Where authenticity data livesNational central registryManufacturer's resolver, cached at receiving party
Required network round-trip at administrationYes, to central registryNo, local cache lookup
CoverageUnit of sale onlyUnit of sale and unit of use
Requires regulator to compel participationYesNo
Single point of failureCentral registryManufacturer's resolver (per manufacturer)
Counterfeit detection mechanismSerial-already-used flagPhysical chip TID mismatch
Global scalabilityLimited by regulatory reachScales with internet itself
Effort to add a new manufacturerRegistry update, regulatory negotiationManufacturer hosts its own resolver
Effort to add a new reader / pharmacyOnboard with registryLocal software install only
Behavior when central system is offlineCannot dispenseContinues working from cache

The disclosed method matches every protective function of centralized decommissioning, extends coverage to the unit of use level, and removes the operational constraints that make global adoption of centralized decommissioning impractical.

11. Failure Modes and Edge Cases

This section enumerates failure modes and the disclosed method's behavior in each case. Some failure modes have additional disclosed handling, and some are simply acknowledged.

11.1 TID read but no TID in manufacturer record

If the manufacturer's aggregation record does not contain a TID for an EPC that has been physically scanned, the system falls back to EPC-only verification. The EPC-only verification confirms that the manufacturer expects an item with this EPC to exist (a serialization-level check), but cannot confirm physical chip identity. The system labels such items as "EPC verified, TID not available." This handling is necessary for backward compatibility with legacy aggregation records that predate TID publication.

11.2 TID read but does not match manufacturer record

This is the counterfeit detection signal. The system rejects the item as authenticated, logs the mismatch with both the read TID and the published TID, and routes the item for manual investigation. False positives are possible in principle (for example, if a chip is replaced under warranty by the manufacturer but the EPCIS record is not updated); the system supports a manual override workflow that requires authenticated reviewer approval.

11.3 EPC read but TID unreadable

If the TID memory bank cannot be read (damaged chip, antenna problem, hostile RF environment), the system falls back to EPC-only verification, labeled as "EPC verified, TID unread." This is operationally similar to section 11.1.

11.4 Manufacturer resolver unreachable at receiving time

If the manufacturer's resolver cannot be reached at receiving (network failure, manufacturer downtime, DNS issue), the receiving party retries on a configurable schedule. Items with unverified aggregation records may be held in quarantine until verification completes, or admitted to inventory with a "pending verification" flag, depending on the receiving party's policy. The point-of-administration workflow is unaffected by manufacturer resolver availability because all administration-time lookups are local.

11.5 Manufacturer resolver compromise

The trust root of the disclosed method is the manufacturer's resolver. If the manufacturer's resolver is compromised by an adversary who can publish arbitrary TID pairings, the disclosed method's authentication guarantee is undermined for that manufacturer. This failure mode is shared by any architecture that places trust in the manufacturer (including centralized decommissioning, which assumes the manufacturer's reported serial-issuance data is accurate). The disclosed method does not attempt to defend against this case; standard practices for resolver hardening (TLS, signing of EPCIS documents, audit logging) are appropriate.

11.6 Cache poisoning at receiving party

If the receiving party's local cache is tampered with (a malicious actor inside the pharmacy modifies cached TIDs to accept counterfeit items), the disclosed method's authentication guarantee is undermined at that receiving party. Defenses include signing the cached EPCIS records at the manufacturer with a public-key signature that the receiving party verifies on cache read, and rotating the cache from the resolver on a schedule that limits the window for cache tampering. These defenses are recommended but not required for the disclosed method to function.

11.7 Mixed-vendor chip support

Different chip vendors use different TID structures. The Impinj prefix is E280, the NXP prefix is E282, and so forth. The disclosed method makes no assumption about chip vendor; the TID is stored and compared as an opaque hexadecimal string. The receiving party need not know which vendor manufactured the chip; the TID string equality test is sufficient.

11.8 Tag with no resolver hostname

Legacy SGTIN-96 tags (96-bit EPC with no extension) do not include a resolver hostname. The disclosed method requires that parent containers (units of sale, cases, pallets) use an encoding that carries the resolver hostname: SGTIN++ for unit-of-sale containers (TDS 2.3), SSCC++ for shipping cases and pallets (TDS 2.3), or any future GS1 encoding that includes a resolver hostname field. Child items inside the parent (unit-of-use syringes and vials, or unit-of-sale boxes inside a higher-level container) can be encoded with plain SGTIN, SGTIN-96, or SGTIN+; they do not require the resolver hostname because they are looked up via the parent's aggregation record. If a parent container itself uses a legacy non-hostname-carrying encoding, the disclosed method falls back to centralized lookup directories or out-of-band manufacturer routing, which is outside the scope of this disclosure.

11.9 Multiple identical TIDs (cloning at the silicon level)

As discussed in section 4.1, producing a chip with a chosen TID is not within the capabilities of any field-side adversary. The TID is factory-burned during fabrication. An adversary capable of running a semiconductor fabrication facility with sufficient process control to produce chips with chosen TID values is operating at a level of resource and capability that exceeds the threat model the disclosed method is designed to defeat. Defense against such an adversary requires additional measures (for example, cryptographic challenge-response with a key fused into the chip at fabrication), which are out of scope for this disclosure.

11.10 Specialty chips with writable TID memory

A small minority of specialty RAIN UHF chips, generally aimed at research, RFID security testing, prototyping, and specific industrial applications, permit field-side modification of the TID memory bank. These chips exist in the commercial market and can be purchased in single quantities for prices on the order of ten US dollars per chip, compared to pennies per chip for standard production-grade RAIN UHF tags used at scale in commercial supply chains. They are sold by a small number of specialty vendors in low volumes and are not stocked in the quantities required for mass counterfeit production.

An adversary using writable-TID specialty chips to defeat the disclosed method faces a per-counterfeit-unit cost that exceeds the value of most counterfeit pharmaceutical doses, undermining the economics of large-scale counterfeiting. A counterfeiter targeting a sufficiently high-value injectable medication where per-vial economics could absorb ten-dollar tag costs still faces secondary problems: the chips themselves are sold by a small number of vendors whose order patterns can be monitored, the chips often include vendor-specific markings or extended TID structures that distinguish them from standard production chips even before TID comparison, and producing the volume of counterfeits needed to monetize the attack at scale rapidly outstrips the inventory and lead times of the specialty supply channels.

The disclosed method's threat model assumes adversaries using commercially available production-grade RAIN UHF chips with read-only TID, which describes the overwhelming majority of RAIN UHF chips in commercial circulation. The author acknowledges that writable-TID specialty parts exist and that a sufficiently motivated adversary with sufficient operating budget could in principle use them to produce counterfeits that pass TID-pair authentication. In supply chains where this matters, the disclosed method should be combined with additional defenses, including signed EPCIS records (section 13.6), monitoring of specialty-chip vendor sales patterns, and cryptographic challenge-response if the chips and readers in question support it.

12. Security Properties

The disclosed method has the following security properties.

Physical possession is required for forgery. An adversary cannot produce a counterfeit tag that passes authentication without physically obtaining a legitimate tag and extracting or relocating its chip. The cost of doing so for each counterfeit unit exceeds the value of most counterfeit pharmaceutical doses, breaking the economics of counterfeiting.

Eavesdropping does not enable attacks. The TID and EPC are both readable over the air by any reader within range. An adversary who eavesdrops on a legitimate scan obtains the TID and EPC, but obtaining these does not enable the adversary to construct a counterfeit tag with the same TID, because TIDs cannot be written.

Replay attacks are not effective. The authentication signal is "this physical chip's TID matches the manufacturer's record." An adversary cannot replay a previous successful authentication; each authentication requires the physical chip to be present.

Counterfeit detection is automatic, not statistical. The disclosed method does not require statistical inference (anomaly detection on serial number usage patterns, for example). A single scan of a counterfeit item with a cloned EPC produces a TID mismatch and is detected on the first read.

Privacy: TIDs are not personal data. TIDs identify chips, not individuals. The disclosed method does not require tracking which patient received which TID, only that the TID matches the manufacturer's record. Compliance with patient privacy regulations (HIPAA in the US, GDPR in the EU, and equivalents in other jurisdictions) is unaffected by the disclosed method, provided the receiving party's cache does not link TID values to patient identifiers.

13. Extensions and Variations

The disclosed method extends in several directions; each variation is part of this disclosure.

13.1 SSCC++ for shipping containers

SSCC++ is the SSCC-level analog of SGTIN++. A shipping container (a pallet, a case) carries an SSCC++ tag containing the SSCC value, the resolver hostname, and so forth. The same TID-pairing approach applies: the manufacturer publishes the SSCC++ tag's TID alongside the SSCC, and the receiving party verifies the case-level chip identity before opening the case. The disclosed method handles SSCC++ identically to SGTIN++, switching only the Digital Link URL path from /01/<GTIN>/21/<serial> to /00/<SSCC>.

13.2 Nested aggregations

A typical pharmaceutical shipment has nested aggregation: a pallet contains cases, each case contains boxes, each box contains unit-of-use items. The disclosed method publishes a separate AggregationEvent for each parent, each event listing the parent's TID and the EPCs and TIDs of its immediate children. A receiving party scanning a pallet on arrival can resolve every level of the aggregation by following parent-child links, and verify TID pairings at every level.

13.3 Cross-manufacturer pharmacy inventory

A pharmacy receives items from multiple manufacturers. Each manufacturer hosts its own resolver. The receiving workflow described in section 8 works without modification: each tag carries the hostname of its own manufacturer's resolver, and the receiving party's software resolves each tag's record independently. No central directory of manufacturers is required.

13.4 Backward compatibility with non-TID-aware EPCIS records

The disclosed method's extension fields (eagile:tid and so forth) are EPCIS extension fields under a custom namespace. EPCIS consumers that do not recognize the extension namespace ignore the extension fields and process the AggregationEvent as a standard EPCIS event. The disclosed method is therefore strictly additive; deploying it does not break existing EPCIS-based systems that do not yet support TID pairing.

13.5 Use of the TID for non-pharma items

The disclosed method is described in the pharmaceutical context, where the centralized decommissioning replacement argument is strongest. The same combination of techniques (TID pairing, SGTIN++/SSCC++ with resolver hostname, EPCIS aggregation extension, GS1 Digital Link resolution, local caching at receiving, point-of-use authentication against local cache) applies equally well to any other supply chain where item-level authenticity matters, including but not limited to luxury goods, electronic components, food safety, and aerospace parts traceability. The disclosure should be read as covering these applications as well.

13.6 Signing of EPCIS documents

A defensive enhancement to the disclosed method is for the manufacturer to sign the published EPCIS documents using a public-key signature (for example, JSON Web Signature, or detached XML-DSig for XML representations), with the manufacturer's signing key published in a well-known location associated with the resolver hostname (for example, a .well-known/keys.json document at the resolver root). The receiving party verifies the signature before caching. This addition does not change the core method but raises the bar against resolver compromise.

13.7 Time-bounded caching with refresh

A receiving party may choose to refresh its cached EPCIS records on a schedule (for example, every 24 hours for items not yet dispensed) to pick up any corrections the manufacturer publishes (recall flags, expiry adjustments). The refresh schedule is a policy choice; the disclosed method functions with or without refresh.

13.8 SGTIN++ on every unit-of-use item

A future variation of the disclosed method encodes every unit of use with the SGTIN++ encoding (carrying the manufacturer resolver hostname directly on the unit-of-use tag) rather than with plain SGTIN or SGTIN+. The manufacturer publishes a per-unit-of-use EPCIS record at each unit's GS1 Digital Link URL, in addition to or in place of the parent's aggregation record. The (EPC, TID) pairing is established the same way for unit-of-use items as for parent containers: the manufacturer captures the TID (at programming for Path A, at aggregation reading for Path B), records the (GTIN, serial, TID) triple, and publishes a per-unit EPCIS record at https://<host>/01/<GTIN>/21/<serial>?linkType=gs1:epcis that includes the TID in the extension fields.

This variation enables several capabilities that the baseline method does not.

This variation is consistent with the rest of the disclosed method: the EPCIS extension fields, the GS1 Digital Link URL pattern, the TID pairing verification logic, the receiving-party caching, and the point-of-administration authentication all work identically whether the unit-of-use tag is plain SGTIN, SGTIN+, or SGTIN++. The variation is included in this disclosure to ensure that the SGTIN++-on-every-unit-of-use configuration is not patentable by a third party as a separate invention; it is, in the author's view, a straightforward extension of the disclosed method to the unit-of-use level, and the entire combination (TID-paired authentication via manufacturer-published EPCIS aggregation, applied at unit-of-use granularity, with self-resolving SGTIN++ tags) is hereby placed into the public technical record.

14. Reference Database Schema for a Receiving Party

The following schema is offered as a reference implementation of the local cache at a receiving party. It is not the only possible schema; it is one that has been used successfully in the demonstration system that accompanies this disclosure.

CREATE TABLE epcis_aggregation_cache (
    partitionid INT NOT NULL,
    observationUUID VARCHAR(64),
    parent_gtin VARCHAR(20) NOT NULL,
    parent_serial VARCHAR(64) NOT NULL,
    parent_tid VARCHAR(64),
    parent_hostname VARCHAR(255),
    child_gtin VARCHAR(20) NOT NULL,
    child_serial VARCHAR(64) NOT NULL,
    child_tid VARCHAR(64),
    validation_status VARCHAR(16),
    epcis_fetch_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_parent (partitionid, parent_gtin, parent_serial),
    INDEX idx_child (partitionid, child_gtin, child_serial)
);

Authentication at the point of administration uses an indexed lookup against idx_child, retrieving the cached child_tid for the scanned (GTIN, serial). A typical query is on the order of single-digit milliseconds against a database holding records for tens of thousands of items.

15. Reference Authentication Workflow Pseudocode

function authenticate(epc_hex, tid_hex):
    epc = decode_epc(epc_hex)
    gtin = epc.gtin
    serial = epc.serial

    record = cache.lookup_by_child(partition_id, gtin, serial)
    if record == NULL:
        return Result(status="unknown", reason="no manufacturer record for this EPC")

    if record.child_tid == NULL or record.child_tid == "":
        return Result(status="epc_verified_tid_unavailable", reason="manufacturer record lacks TID")

    if normalize_hex(record.child_tid) == normalize_hex(tid_hex):
        return Result(status="authenticated", reason="TID matches manufacturer record")

    return Result(status="counterfeit_suspected", reason="TID mismatch")

The normalize_hex function strips whitespace, removes any colon or dash separators, and converts to uppercase, allowing the comparison to be robust to formatting differences between readers.

16. Specific Disclosed Methods and Combinations

The following is an enumeration of the specific disclosed methods and their combinations, written in the style of patent claims and explicitly published here to serve as prior art against any subsequent patent application that attempts to claim these methods or their combinations.

Disclosure 1. A method of authenticating a serialized RFID-tagged item by, at a point of scanning, reading both the Electronic Product Code (EPC) and the Tag Identifier (TID) from the tag, retrieving from a manufacturer-published record a previously stored (EPC, TID) pairing for the item, and comparing the read TID against the stored TID to confirm physical chip identity.

Disclosure 2. The method of Disclosure 1, where the manufacturer-published record is an EPCIS 2.0 AggregationEvent that includes, in extension fields under a manufacturer namespace, the TID values of all child items listed in the aggregation.

Disclosure 3. The method of Disclosure 1 or Disclosure 2, where the manufacturer-published record is retrieved by HTTPS request to a URL constructed according to the GS1 Digital Link standard, the URL having a hostname that is encoded directly into the EPC memory bank of the tag at the time of tag programming, using the SGTIN++ encoding defined by GS1 TDS 2.3, or the SSCC++ encoding defined by GS1 TDS 2.3, or any future GS1 encoding that includes a resolver hostname field.

Disclosure 4. The method of any preceding Disclosure, where the manufacturer-published record is retrieved by a receiving party at a receiving step in the supply chain (a distributor receiving dock or a pharmacy receiving area) and is cached in a local database keyed by GTIN and serial, and where subsequent authentications at the point of administration of the item are performed by local lookup against the cache without an additional network call to the manufacturer.

Disclosure 5. The method of any preceding Disclosure, applied to pharmaceutical items at the unit of use level, where the unit-of-use item is a pre-filled syringe, a vial, an ampoule, a blister-packed dose, or any other individually dispensable pharmaceutical item, and where the authentication is performed at the time of administration of the unit-of-use item to a patient.

Disclosure 6. The method of any preceding Disclosure, used as a substitute for or alternative to a centralized decommissioning system, where the centralized decommissioning system is one that maintains a registry of serial numbers known to have been dispensed and requires a network query to that registry at the point of dispensing.

Disclosure 7. A system implementing the method of any preceding Disclosure, comprising: a manufacturer tag-programming station that captures TID values at programming time and persists (GTIN, serial, TID) tuples to a manufacturer EPCIS database; a manufacturer EPCIS resolver service that publishes AggregationEvent records via GS1 Digital Link URLs; one or more receiving-party reader stations that scan tags, resolve and cache EPCIS records; and one or more point-of-administration reader stations that perform local TID-pairing authentication against the cached records.

Disclosure 8. The method or system of any preceding Disclosure, extended to nested aggregations of containers (case containing unit-of-sale boxes, each box containing units of use), where the manufacturer publishes a separate AggregationEvent for each parent container and the receiving party can independently verify TID pairings at every nesting level.

Disclosure 9. The method or system of any preceding Disclosure, where the manufacturer's published EPCIS documents are cryptographically signed by the manufacturer and the receiving party verifies the signature before caching, with the manufacturer's signing key discoverable via a well-known endpoint at the resolver hostname.

Disclosure 10. The method or system of any preceding Disclosure, applied outside the pharmaceutical supply chain to any other supply chain where item-level authentication is desired, including but not limited to luxury goods, electronic components, food safety, and aerospace parts traceability.

17. Statement of Public Dedication

The methods, systems, and combinations described in this document are hereby dedicated to the public technical record. No party, including the author, claims patent rights over any of the disclosed methods or combinations. Any party is free to implement, deploy, sell, license, and otherwise use the disclosed methods without seeking permission from the author or paying any license fee.

This disclosure is published with the explicit intent of preventing any party from obtaining patent rights that would block the pharmaceutical industry, or any other industry, from adopting the described techniques. Any patent claim covering the methods described herein, filed on or after the publication date of this document, should be considered invalid for lack of novelty in view of this disclosure.

18. Citations and References

19. Author and Contact

Aaron Sundman

Business Development
CCL eAgile
asundman@eagile.com

This document is the unilateral defensive publication of the author and does not represent a position of CCL Industries or any affiliated entity.

20. Document History

End of disclosure.