The European Patent Office refused to grant a software patent for a security token cache. Here are the practical takeaways from the decision T 1307/11 (Security token cache/ASSA ABLOY) of 14.3.2017 of Technical Board of Appeal 3.5.06:
Key takeaways
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 invention
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).
-
Claim 1 (main request)
Is it patentable?
Interestingly, the Board did not dispute that the concept of caching data is technical.
However, the Board took the view that caching, as well as refreshing a cache, is common general knowledge:
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.
One remaining difference over the prior art was that the data being cached is stored in the memory of a “hardware security token”. This, however, was considered to be straight-forward by Board:
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 technology 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.
Furthermore, the security token is accessed via a “security token API” and the cache is accessed via a “cache API”. However, also these differences were considered to be obvious:
5.2 As regards features (b) and (c), the board considers that the provision of APIs is a matter of workshop practice for a person with the appropriate programming skill.
Therefore, the Board ultimately decided that the subject-matter of the claims does not involve an inventive step.
More information
You can read the whole decision here: T 1307/11 (Security token cache/ASSA ABLOY) of 14.3.2017