Using a blockchain to log supply-chain custody transfers: non-technical

The application underlying the discussed decision concerns a system that uses blockchain encryption technology to record and maintain the chain-of-custody of physical or digital products as they move through a supply chain. The key features at issue were the use of a blockchain to log supply-chain custody transfers, including product registration, documentation of custody changes, and quantity verification at each transfer point. The Board concluded that these features lacked technical character, as they merely defined business content recorded on known blockchain infrastructure without improving the underlying technology.

Here are the practical takeaways from the decision: T 2078/22 (Blockchain storing supply-chain data/STOLLMAN AND MATEEV) of 19 November 2025, of the Technical Board of Appeal 3.5.01.

Key takeaways

Recording supply-chain custody transfer data on a blockchain does not constitute a technical contribution under the EPC, as it merely defines business content stored on known blockchain infrastructure. Applying the Comvik approach, the Board held that neither the choice of what data to record nor operational design choices such as who records a transaction or when involve technical considerations.

The invention

The Board of Appeal summarized the invention as follows:

The invention applies blockchain technology to record the movements of a product through a supply chain. The blockchain (or “chain-of-custody data file configured to use blockchain encryption technology”) contains the full history of a product’s transfers between parties (“agents”) in the supply chain. Agents run a client application that enables them to submit digitally signed transactions (“linked changes”) to the blockchain. The blockchain is initiated by the product’s manufacturer, who creates its genesis block (“initial custody record”) that identifies the product and its initial quantity supplied. Subsequently, each transfer of a quantity of the product is recorded on the blockchain by a receiving agent. Independently of the above, the invention generates reports (“change records”) detailing the product transfers and provides them to the agents involved. At each change of custody, the system confirms that the quantity transferred by an agent does not exceed the quantity they previously received, thereby detecting potential counterfeiting, gray-marketing, or product dilution. If an anomaly such as a quantity discrepancy is detected, the system triggers an alert and identifies the responsible agent.

Claim 1 of the first auxiliary request

A system (10) for ensuring integrity of an physical or digital product supply chain,

1.1 said system (10) comprising at least one computer server, a plurality of terminals, each of said plurality of terminals being associated with at least one of a plurality of agents along said supply chain, and a software application operating on said at least one computer server, said system (10) configured for creating and using an electronic chain-of-custody data file;

1.2 said chain-of-custody data file configured to use blockchain encryption technology to record and maintain physical or digital product chain-of-custody change information using a chain-of-custody log distributed among the plurality of agents through a client application comprising:

1.2.1 a plurality of linked changes;

1.2.2 that is configured to utilize cryptographic techniques;

1.2.3 that enable detection of attempts to compromise data integrity of the physical or digital product supply chain including any of said plurality of linked changes;

wherein

1.3 said attempts are configured to be detected using said blockchain encryption technology by tracking a physical or digital product to be transferred along said supply chain, configured to:

1.3.1 register (200) said physical or digital product in an initial custody record in the chain-of-custody log, said initial custody record including an initial quantity and information identifying said physical or digital product;

1.3.2 wherein said initial custody record creates a beginning point of the chain-of-custody log in said encrypted chain-of-custody data file;

1.3.3 document (300) each change of custody of said physical or digital product in said encrypted chain-of-custody data file comprising quantity of the physical or digital product being transferred;

1.3.4 generate (400, 410, 420, 430), at each change of custody of said physical or digital product, at least one change record documenting said change in custody of said physical or digital product based on the encrypted chain-of-custody log, said at least one change record confirming the information identifying said physical or digital product and that a quantity of said physical or digital product transferred is not greater than the initial quantity of said physical or digital product; and

1.3.5 update (350) the chain-of-custody log based on the at least one change record.

Is it patentable?

The Examining Division’s position

The Examining Division refused the application for lack of inventive step (Article 56 EPC). It considered that the claims of the main request and all six auxiliary requests did not involve an inventive step over a notoriously known blockchain system, as evidenced by document D2, a Wikipedia entry on “Blockchain” published on 7 August 2015. The Examining Division took the position that the features defining what data is stored on the blockchain (i.e., the supply-chain content such as product registration, custody transfers, and quantity tracking) did not improve the known blockchain technology in terms of security or otherwise. Rather, these features merely used a known blockchain to record a particular business content. The design choice of assigning the creation of a blockchain entry to the receiving agent was found not to be based on any technical considerations, but rather on non-technical considerations relating to who records the product transfer and when. Similarly, using separate blockchains for product components, generating reports for agents, and recording sensor data on the blockchain were found to either lack technical character or constitute obvious implementations of non-technical business requirements.

The Appellant’s arguments

The Appellant argued that recording data documenting how a product moved within a supply chain onto a distributed blockchain eliminated the possibility of compromising supply-chain data through a single attack, thus providing the technical effect of assuring the integrity of the recorded supply-chain data. For the second auxiliary request, the Appellant contended that having the receiving party record a product transfer, rather than the transferring party as in conventional cryptocurrency blockchains, was a technical design choice that improved the security of supply-chain operations. For the fourth auxiliary request, the Appellant argued that maintaining separate blockchains for product components enabled tracking ownership changes at a more granular component level, ensuring integrity of supply-chain data more effectively. Regarding the fifth and sixth auxiliary requests, the Appellant submitted that sending reports to parties involved in product transfers and alerting multiple parties of policy violations improved the integrity and security of the supply chain. For the seventh auxiliary request, the Appellant argued that tracking product integrity through the supply chain using sensors enabled automatic alerts indicating when and where adverse conditions occurred, with these alerts being recorded on the blockchain. Finally, the Appellant filed a new main request during the appeal proceedings, intending to shift the invention from a distributed blockchain to a centralised database to distinguish it from the Bitcoin blockchain disclosed in D4.

The Board’s analysis

Choice of closest prior art

The Board preferred to start its inventive step analysis from document D4 (“Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies,” published 15 May 2015) rather than from the Wikipedia entry D2 used by the Examining Division. D4 discusses the security features of blockchain technology in greater detail, including the use of digital signatures and distributed transaction logs. As D4 already disclosed the distributed nature of the blockchain and the use of digital signatures to ensure data integrity, the Appellant’s arguments emphasising these features as advantageous were no longer relevant.

First auxiliary request (main focus)

The Board identified three groups of distinguishing features over D4:

Feature A: The blockchain’s genesis block indicates a product and its initial quantity, and subsequent transactions record how the product moves within the supply chain (features 1.3.1, 1.3.2, 1.3.3). The Board agreed with the Examining Division that this feature merely defines the blockchain’s business content and lacks technical character. It does not improve the known blockchain technology in terms of security or otherwise but merely uses it to record particular business content.
Feature B: Generating reports indicating product transfers and confirming that the quantity transferred does not exceed the quantity previously received (feature 1.3.4). The Board found this to be a business feature with no technical implementation and, therefore, no technical contribution. Even assuming that reports are provided to supply-chain parties to assist in detecting irregularities, this is a purely business effect.
Feature C: The server computer and the application it runs (feature 1.2). As long as the server application is not used, this feature has no technical effect. Even assuming it is used to register a new agent, applying the Comvik approach (T 641/00), this would be an obvious implementation of the business requirement to enable such a registration.

The Board also noted potential added subject-matter and clarity issues with features 1.2.2, 1.2.3, and 1.3 (use of cryptographic techniques to detect attempts to compromise data integrity), but interpreted them as referring to the use of asymmetric cryptography to sign blockchain transactions and proceeded with the inventive step analysis.

Second to seventh auxiliary requests

Second auxiliary request (registering acceptance by the receiving agent): The Board found that this design choice was not based on technical considerations but merely involved non-technical considerations relating to who records the product transfer and when.
Third auxiliary request (use of encryption key pairs to sign transactions): This was already disclosed in D4, section 2.4.
Fourth auxiliary request (separate blockchains for product components): The Board agreed with the Examining Division that this was a business requirement, as the advantage of tracking at a component level rather than a product level is of a purely business nature.
Fifth auxiliary request (sending reports to agents involved in transfers): This lacked technical character for the same reasons given for feature B of the first auxiliary request.
Sixth auxiliary request (reporting policy violations to parties within and outside the supply chain): This was a further business idea whose implementation was not really claimed. Even assuming it contributed to preventing commercial abuse, this remained a purely business effect.
Seventh auxiliary request (recording product damage on the blockchain using sensors): Recording what information to store on the blockchain lacked technical character. The use of a sensor (e.g., a camera) to capture damage was an obvious implementation of the non-technical requirement to record evidence of it, as sensor-based monitoring architectures were commonly known at the priority date, as also evidenced by documents D3 and D5.

Late-filed main request

The Board accepted that the introduction of new prior art D4 could constitute an exceptional circumstance under Article 13(2) RPBA. However, the late-filed main request gave rise to new objections under Article 123(2) EPC, as several claim features significantly paraphrased the description rather than being literally disclosed. In particular, the concepts of “each change in status of said agent identifier” and “source exogenous to said at least one host compute device” extended beyond the supporting passages in the application. The Board therefore did not admit the main request into the proceedings.

Conclusion

The Board dismissed the appeal in its entirety. The late-filed main request was not admitted into the proceedings under Article 13(2) RPBA because it introduced added subject-matter (Article 123(2) EPC). All auxiliary requests (first through seventh) were found to lack inventive step (Article 56 EPC) because the features distinguishing them from the prior art D4 were either non-technical business features (defining what data to store on a blockchain, who records a transaction, or what reports to generate) or obvious implementations of non-technical business requirements (using known sensors to monitor product condition). The decision underscores that using blockchain technology to record supply-chain data does not, by itself, constitute a technical improvement to blockchain technology but amounts to specifying non-technical business content for a known technical infrastructure.

More information

You can read the full decision here: T 2078/22 (Blockchain storing supply-chain data/STOLLMAN AND MATEEV) of 19 November 2025, of the Technical Board of Appeal 3.5.01.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy Yes, I consent to the collection, processing and use of my above-mentioned personal data for the purposes of processing my message and for the purposes of contacting me via email. The legal basis of the processing shall be formed by my consent pursuant to Art. 6 (1) lit. a GDPR. The data will be deleted three months after expiry of the purpose, provided that longer retention periods are not required by law. I can revoke this consent with future effect at any time. I have taken note of the privacy statement and consent to it. With regard to the processing of my data, I am entitled to inalienable rights, information on which can be found in the privacy statement.

* = Required field