The decision T 1072/09 of 13 November 2014 is a good example that data encryption methods are technical and therefore generally patent-eligible at the European Patent Office. To overcome the inventive step hurdle, however, more is needed than the general idea of using encryption.
The patent application underlying the decision dealt with a secure scheme for making payments over a non-secure computer network. The scheme verifies a consumer’s account number (e.g. ATM card number) with the help of an associated personal identification number (PIN). The consumer supplies his account number to an on-line merchant and the PIN to a third party (bank). The third party receives both numbers from the merchant computer and the consumer computer, verifies the correctness of the numbers, checks for sufficiency of funds, and either authorises or denies the transaction. Fig. 4 of the underlying patent application WO 01/18719 illustrates this communication scheme:
A central feature of the application was that the numbers (card number and PIN) are transmitted via encrypted connections.
According to the Board of Appeal, using an encrypted data communication protocol is indeed a technical feature and therefore generally patent-eligible (in line with this earlier decision). However, it was considered to be conventional at the priority date (1999) and therefore eventually not inventive.
As the skilled reader will expect, the decision closely follows the COMVIK approach for assessing the patentability of inventions consisting of a mix of technical and non-technical features:
From the reasons
2. In the light of Article 52(1)(2)(3) EPC, Article 56 EPC 1973 requires a non-obvious technical contribution (see e.g. T 641/00-Two identities/COMVIK, Headnote 1, OJ EPO 2003, 352; T 1784/06-Classification method/COMPTEL).
3. While claim 1 refers to a method of making a “purchase” over a computer network, the method focuses on a payment scheme. In either case, document D1 — “Method and system for billing on the Internet” — represents the closest available prior art.
4. D1 is silent on how the consumer terminal (100) sends the card ID to the merchant (200) (D1, column 15, lines 7 to 12) and on how the merchant (200) forwards the card ID to the card management server (300) (paragraph 0041).
Therefore, the method of claim 1 differs from D1 (only) in that the first number (card ID) is explicitly said to be transmitted via encrypted connections (from the consumer to the merchant and from the merchant to the third party).
5. However, using an encrypted Secure Socket Layer (SSL) is a conventional way of safely transmitting data packets according to the Internet protocol, as acknowledged in the present application (A1, page 2, lines 2 to 4: “most popular approach”). Notably banking schemes use that layer or any other security protocol (https). When such a secure transport layer is used, it is used for the whole data traffic under that protocol; no selective exception is made for data items that might be less sensitive among the bulk of data being transmitted.
Hence, it is obvious to transmit also the first number (card ID) via the encrypted connections typically used for data streams including sensitive items.
6. Therefore, the Board does not identify any non-obvious technical contribution in the method according to claim 1 of the main request.
Read the whole decision here.
Originally published at www.europeansoftwarepatents.com on August 18, 2015.