The application relates to a method for the distribution of electronic assets to a test application in a manufacturing process. The Board noted that the solution of providing a daemon that takes over the management of assets reduces the load of the server and thus solves the technical problem of how to minimise the overhead of the server. Since none of the cited documents would lead the skilled person to the solution without hindsight, the subject-matter was inventive. Here are the practical takeaways from the decision T 0447/19 of May 11, 2022, of the Technical Board of Appeal 3.4.03:

Key takeaways

Reducing the load of the server is a technical effect, and it solves a technical problem of how to minimise the overhead of the server

The invention

Products today are on a System-on-Chip (SoC) where manufacturers may use the same SoC with various features enabled/disabled in order to differentiate the final products in the market. In distributed manufacturing, the devices are manufactured at remote locations, and unauthorized enablement of features represents significant revenue loss to companies. Therefore, there is a need for the central producer to monitor and control the device to avoid fraud by local manufacturing (sub)contractors.

Common practice is to provide cryptographic keys with each electronic asset which is distributed from the central producer to a local server at each remote manufacturer. The assets are then tested by an agent (log generated) before inserting into the device.

The invention relates to the management of the asset distribution where the agent is executed as a separate daemon process, independent from the corresponding test application. This allows the agent takes over the communication with the appliance and the request/receipt of electronic assets for the corresponding test application.

Therefore, it is not necessary to establish a connection with the test application or monitor the usage of the assets every time the application needs assets for insertion into the device, as the daemon takes over this task. Moreover, assets left at the daemon’s cache at the termination of the test application are not lost but can be used by a subsequent instance of the test application

Fig. 6B of EP 2 977 941 A1
  • Claim 1 (Sole Request)

Is it patentable?

The Examining Division refused the application and considered the subject-matter of the claims lacked inventive step over documents D1 (WO 2006/133545 A1) combined with document D3 (US 2008/0040550 A1). The distinguishing features and the technical problem were defined as follows:

3.1 It is common ground that document D1 represents the closest prior art.

According to the appellant, claim 1 differs from D1 in that (numbering by the board in line with the impugned decision):

(a) the agent software program is executed as a daemon process separately from the test application and comprises an agent API for communicating with the appliance, and

(b) the daemon maintains a record of assets not used when the instance of the test application terminates for a next instance of the test application.

These distinguishing features were also identified by the examining division, although the division interpreted feature (b) differently, in that it was not the daemon which maintained the assets for the next instance of the test application but simply “assets not used … are maintained …” (see the middle of page 6 of the impugned decision). Since the board agrees with the appellant’s interpretation of feature (b), it also adopted the appellant’s definition of the distinguishing features (see page 3 of the statement of the grounds of the appeal).

3.2 According to the appellant, these two distinguishing features combine to provide the technical effect of the daemon taking over the management of assets, reducing thus the load of the server. Hence, the objective technical problem the skilled person starting from D1 would be faced with was how to minimise the overhead of the server 18 when dealing with equipment 20 (ibid., page 5).

3.2.1 As the appellant further explained during the oral proceedings, the daemon was monitoring the use of the cached assets by the test application. Receiving the log data from the test application regarding the assets inserted into the devices, the daemon was monitoring the use of the cached assets (see also Figure 6B of the published application). In D1 it was the controller of the producer which was receiving all the log data from the key agent and was monitoring which keys (assets) were inserted into the devices, whether there were any unused keys left, etc. (see e.g. Figures 1 and 4 of D1). Hence, by having this monitoring performed by the daemon, the overhead of the server was indeed minimised.

3.3 The board accepts the appellant’s formulation of the objective technical problem.

In the decision under appeal, the examining division considered that the two identified distinguishing features did not combine to produce a synergistic technical effect and assessed them separately. However, since the board does not accept the division’s interpretation of the second distinguishing feature, it does not follow its formulation of the technical problem, either. Since both distinguishing features (a) and (b) relate to the daemon, and the appellant’s formulation of the objective technical problem is considered plausible, the board decided to follow the appellant in this respect.

The Board did not agree with the Examination Division that the skilled person will arrive at the feature from document D3 as it provides a different solution to the problem:

3.4 The examining division referred also to D3. D3 describes a network in which a series of client applications 120 are connected to a directory server 110 (see Figure 1). Normally such client applications access the directory server by establishing a direct connection through a binding operation, which initiates a protocol session between the application and the server, allows authentication of the client to the sever, etc. (see paragraph [0009]).

A problem in such a network architecture is that each application needs to establish a direct connection to the server before it can request any information from it. The server needs to establish separate connections (sessions) to each application for any exchange of information to take place. This increases the load on the server affecting its performance (see paragraph [0010]).

D3 solves this problem by installing a Light Directory Access Protocol (LDAP) caching daemon 210 between the applications and the server (see Figure 2). The daemon obtains data from the server and stores (caches) them in its data cache so that it can directly provide them to the requesting applications without any need for the applications to connect to the server. At the same time, the daemon connects to the directory server and retrieves any information requested by an application but not stored in its cache. In this way, the server has to manage only one individual connection (to the daemon) and can perform its main task of information retrieval more efficiently (see paragraphs [0023] to [0027]).

Furthermore, the Board also agreed with the applicant that even starting from document D1, the skilled person will seek other solutions to the problem, and will not arrive at the solution without hindsight:

3.7 The examining division considered that executing the key agent (21) as a separate background daemon process would have been an obvious choice for the skilled person which would be aware of the advantages of such a modular implementation based only on their common general knowledge. Moreover, such an a implementation would also have been obvious in view of the teaching of D3 (see first two paragraphs on page 7 of the impugned decision).

3.7.1 As explained previously, the board does not agree with the examining division’s separate assessment of the distinguishing features or its formulation of the objective technical problem.

Even if this argument were followed and it were to be accepted that moving the key agent (21) of the manufacturing equipment (see Figure 1 of D1) to a separate daemon process would have been obvious to the skilled person, the board notes that there would still be feature (b) missing from such an implementation to arrive at the claimed invention.

In the claimed invention it is the daemon which, using the log data received from the test application, maintains a record of the unused assets remaining in its cache. The key agent (21) in D1 does not do anything similar. As explained in point 3.6 above, the monitoring of the keys (assets) and their usage in D1 is performed by the controller of the producer and not by the key agent. Implementing the key agent in a separate daemon process would not change this. The log data would still be sent by the manufacturing equipment (20) to the server (18) through the key agent (21). The evaluation and monitoring of the key usage would still be done by the controller of the producer based on the received log report “R”.

Since according to the method of D1 the evaluation and monitoring of key usage based on the log data are effected at the producer and not at the server of the manufacturer, the skilled person wishing to reduce the load to the server would not have any reason to move this functionality from the producer to the key agent. They would rather seek functionalities that could be moved from the server of the manufacturer to the key agent.

Hence, there is no incentive in D1 for the skilled person to introduce any key usage monitoring functionality at the key agent without hindsight. D3, which does not mention any keys/assets or any monitoring of the usage/access of the data cached at the daemon by the applications would not provide any such incentive, either.

3.8 The board’s conclusion is, therefore, that the subject-matter of claim 1 involves an inventive step within the meaning of Article 56 EPC.

Therefore, the Board concluded that the subject-matter of the claims involves an inventive step, and the appeal is allowed with an order to grant a patent

More information

You can read the whole decision here: T 0447/19 of May 11, 2022, of the Technical Board of Appeal 3.4.03

Stay in the loop

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

Privacy policy *
* = Required field

Please share this article if you enjoyed it!