Caching security information of a smart card: technical but obvious

This examination appeal concerns a system for caching information retrieved from a hardware security token, i.e. a smart card or any other tamper-resistant hardware device used to store digital credentials, cryptographic keys or the like. Since it was not even questioned that this is technical subject-matter, the decision is quite straight-forward and “only” deals with inventive step.

tl;dr: (?)

  • Caching data to speed up frequent accesses is common general knowledge
  • Using APIs is a matter of workshop practice for a person with the appropriate programming skill

The case at hand

The patent application states that when a token receives many requests in a short period of time, some requests may have to wait, which may be aggravated by a slow serial data connection, but also by the need for exclusive access to the smart card to protect data integrity.

As a solution to this problem, the application proposes the provision of a “memory cache” for the token:

In essence, claim 1 defines that when an application requests information from the token (5), it will first be referred to the memory cache (45) to see whether the information is available and “current” in the cache. If yes, the information is retrieved and returned from the cache (45), otherwise the request is forwarded to the token (5).

What the board said

2. D2 relates to a cache for a web server. In its background section, it discloses caching to be a known technology to speed up frequent accesses to slow storage devices (page 1, line 9, to page 2, line 2). D2 also discloses that cached data may become “invalid” when the original data in the storage device has been changed, and that the data in the cache may then have to be refreshed (see paragraph bridging pages 1 and 2). The board considers these features of caching to belong to the common general knowledge in the art , and the appellant did not challenge that view.

5. From common general knowledge on caching, the subject-matter of claim 1 differs in that (a) the data being cached is stored in the memory of a “hardware security token”, (b) the security token is accessed via a “security token API” and © the cache is accessed via a “cache API”.

5.1 As regards feature (a), the board takes the view that the idea of providing a cache for memory on a security token is, in itself, obvious. As explained above, the claimed “hardware security token” is in particular a slow memory device. Caching was an established tech­nology for speeding up access to slow memory devices. Therefore, in the board’s judgement, the skilled person would not hesitate to use a cache for a “hardware security token” if the cost of the cache was justified by the gained speed.

5.2 As regards features (b) and ©, the board considers that the provision of APIs is a matter of workshop practice for a person with the appropriate programming skill.

5.3 Thus the board concludes that claim 1 of the main request lacks inventive step over common knowledge in the art, Article 56 EPC 1973, and so does claim 19.

Read the whole decision here: T 1307/11 (Security token cache/ASSA ABLOY) of 14.3.2017

As always, for specific questions and requests for advice, email me directly at

Originally published at on July 3, 2017.

Leave a Reply