T 1261/12 (Persistent servicing agent I/ABSOLUTE SOFTWARE) of 7.10.2015

European Case Law Identifier: ECLI:EP:BA:2015:T126112.20151007
Date of decision: 07 October 2015
Case number: T 1261/12
Application number: 05735599.2
IPC class: G06F 1/00
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 348 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: Persistent servicing agent
Applicant name: Absolute Software Corporation
Opponent name: -
Board: 3.5.06
Headnote: -
Relevant legal provisions:
European Patent Convention 1973 Art 84
European Patent Convention 1973 Art 56
European Patent Convention Art 123(2)
Rules of procedure of the Boards of Appeal Art 13(1)
Rules of procedure of the Boards of Appeal Art 11
European Patent Convention R 111(2)
European Patent Convention Art 106
European Patent Convention 1973 Art 107
European Patent Convention R 137(3)
Keywords: Inventive step - main request (no)
Amended claims filed during oral proceedings - first and third auxiliary requests admitted (no)
Claims - clarity
Claims - second auxiliary request (no)
Catchwords:

-

Cited decisions:
-
Citing decisions:
T 0827/16

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, with reasons dated 28 December 2011, to re­fuse European patent application No. 05735599.2 for lack of inventive step of the main request and first to third and fifth and sixth auxiliary requests over

D1: US 5 680 547 A.

The examining division did not admit the fourth auxil­ia­ry request, filed during oral proceedings, pur­suant to Rule 137(3) EPC. The decision made reference to further documents, including

D3: US 6 507 914 B1 and

D4: WO 98/43151 A1,

but did not rely on any of them for its reasons.

II. A notice of appeal was received on 10 February 2012, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 27 April 2012. The appellant requested that the decision under appeal be set aside and that a patent be granted based on claims according to the main or first to sixth au­xil­ia­ry re­quests filed with the grounds of appeal, the other applica­tion documents being the ­description and the drawings as origi­nally filed.

III. With a summons to oral proceedings, the board informed the appellant of its preliminary opinion that the claims according to all requests lacked cla­rity, Ar­ticle 84 EPC 1973, and inventive step vis-à-vis D1 and vis-à-vis D3 or D4 in view of D1, Article 56 EPC 1973.

IV. In response to the summons, with letter dated 2 Sep­tember 2015 the appellant filed amended claims 1-16 and 1-14 according to a main and a first auxiliary request, respectively.

V. Oral proceedings were held on 7 October 2015, together with the oral proceedings in case T 951/12. During the oral proceedings, the appellant filed amended claims 1-15 according to a second and a third auxiliary request (both bearing the date of 6 Octo­ber 2015) and with­drew its earlier fourth to sixth re­quests. Its fi­nal request was that a patent be granted on the basis of the main or first auxiliary request dated 2 Septem­ber 2015 or the second or third auxil­ia­ry request dated 6 October 2015.

VI. Claim 1 according to the main request reads as follows:

"An electronic device comprising a persistent servicing agent disposed in the electronic device, the electronic device connected to a network to a remote server [sic], the persistent servicing agent configured to enable, support and/or provide at least one service with respect to the electronic device, the persistent servicing agent comprising:

a driver agent comprising a partial driver agent concealed in the electronic device and a full function driver agent, wherein the full function driver agent is configured to communicate with the network in enabling, supporting and/or providing the service, and the partial driver agent is configured with a reduced set of functions compared to the full function driver agent, and to determine whether a full function driver agent is available in the electronic device; and

wherein the partial driver agent is configured to reload portions of the full function driver agent, across the network, that may have been removed or are missing from the electronic device; and

a run module configure to automatically initiate operation of the driver agent without user initiation or user intervention."

Claim 1 of the first auxiliary request differs from claim 1 of the main request by the following text added at the end:

"[...], the run module comprising:

an installer module configured to automatically adapt an installer mode instance of the partial driver agent to an operating system of the electronic device; and

a loader module configured to automatically load the installer module, which in turn loads the installer mode instance of the partial driver agent;

wherein the installer mode instance of the partial driver agent creates another instance of itself and registers the copy as an operating system service; and

wherein upon subsequent start of the operating system the partial driver agent determines whether a full function diver agent is available in the electronic device and retrieves over the network a copy of the full function driver agent if it is determined to be not available in the electronic device."

Claim 1 of the second auxiliary request differs from claim 1 of the main request by the following text added at the end:

"[...], wherein the run module comprises:

an installer module configured to automatically adapt the driver agent to the operating environment of the electronic device to provide the service without user intervention; and

a loader module configured to automatically load the installer module, which in turn loads the driver agent."

Claim 1 of the third auxiliary request differs from claim 1 of the second auxiliary request in that the phrases "enable, support and/or" and "enabling, supporting and/or" have been deleted and in that the passage defining the installer module now reads as follows:

"[...] an installer module configured to automatically adapt the driver agent to the operating environment of the electronic device that controls input/output operations of the device by deleting the operating environment to provide the service without user intervention; [...]"

VII. At the end of the oral proceedings, the chairman announced the decision of the board.

Reasons for the Decision

Non-admission of the then fourth auxiliary request by the examining division, Article 11 RPBA

1. The discretionary decision not to admit amendments to a European patent application adversely affects the appli­­­cant because they then cannot form the basis of decision in its favour. Therefore, in view of Ar­ticle 107 EPC 1973, it is a decision which is open to appeal pursuant to Article 106 EPC and which is to be reasoned according to Rule 111(2) EPC. That a request is not admitted is thus not a simple fact but a deci­sion, the reasons for which form part of the reasons of the de­ci­sion as a whole. To avoid any doubt about this, the non-ad­mission of a request must be dealt with in the written decision as part of the reasons.

2. In the present case, the decision mentions that a new fourth auxiliary request was filed during the oral pro­ceedings but not admitted pursuant to Rule 137(3) EPC (see facts and submissions, point 7). No further men­tion is made of this request in the decision, and in particular not in the reasons.

2.1 In the board's view this means that the decision was not reasoned within the meaning of Rule 111(2) EPC, which is a funda­men­­tal deficiency in the sense of Article 11 RPBA.

2.2 In such a case, Article 11 RPBA requires the board to remit the case to the department of first instance, unless special reasons present themselves for doing otherwise.

2.3 In the present case, the board notes that the minutes of the oral proceedings (point 21) do mention briefly that the fourth auxiliary request was not admitted due to a lack of clarity about "what exactly the difference be­tween the full and reduced function driver agent is, in par­ti­cular with respect to network communication". Moreover, this deficiency in the decision did not cause the appeal, because higher-ranking requests were re­fused as well and maintained on appeal. It is also no­ted that the appellant did not specifically challenge the decision of the examining division not to admit the fourth auxiliary request.

2.4 The board considers that these circumstances constitute special reasons within the meaning of Article 11 RPBA for not remitting the case to the department of first instance without addressing its substantive merits.

The invention

3. The application relates to the provision of a tamper-re­sistant "agent" for enabling, supporting and/or pro­vi­ding protective services on a networked client device.

3.1 In particular, the application discusses an asset tracking service meant to reduce the risk that net­worked devices (assets) are lost or stolen and, if they are, that confidential data is lost or the integrity of the enterprise network is compromised. Data dele­tion and software deployment services are spe­cifically men­tioned, too (see e.g. the paragraph bridging pages 1 and 2, and page 6, 1st paragraph of the published applica­tion). In per­for­ming its services, the agent automati­cally and regu­lar­ly contacts a moni­toring cen­tre in or­der to transmit service-re­levant infor­ma­tion, e.g. about the identity of the device and its location (see page 4, lines 19-23).

3.2 An agent deployed on a device is protected against de­tection, i.e. hidden ("stealthy"; page 5, last para­graph), and tamper-resistant, i.e. protected against unautho­rised modi­fi­cation or removal, even against "ope­rating system installation, hard drive for­mat and hard drive replacement" (see page 16, 2nd paragraph). To achieve this, the agent is disclosed as incor­po­ra­ting "self-healing tech­no­logy" which is meant to re­store the agent if removed. The "self-healing function" is "not resident within the file sys­tem" (loc. cit.).

3.3 The description explains that the agent may consist of three "modules", the "Computrace" Loader Module CLM, the Adaptive Installer Module AIM and the Communi­ca­tions Driver Agent CDA (page 17, 3rd paragraph). The CDA con­tains a driver, the "mini CDA", which checks whether the entire CDA is present and, if not, ini­ti­ates the down­load or up­date of the CDA (page 18, 3rd paragraph; page 21, penultimate paragraph et seq.; page 34, 2nd paragraph).

The prior art

4. D3, also filed by the present applicant­, discloses an asset tracking system based on the same soft­ware pro­duct ("Computrace"; see e.g. figure 2a). D3 also dis­closes an "agent" which is "concealed" and pro­tected against tampering ("hides with­in the soft­ware/firm­ware/hardware" of the protected device so as to "evade de­tec­tion" and "resist possible attempts to disable it by an unauthorized user" (see e.g. column 2, lines 14-24; column 5, lines 32-36). The agent is loaded and started during boot-up without user initia­tion or intervention (see e.g. column 5, line 23 to column 6, line 18; esp. column 6, lines 17-18). D4 also stems from the present applicant and is very simi­lar to D3 (see in D4 esp. figure 3-1; page 4, lines 8-11 and 21-23; and page 36, lines 10-12).

5. D1 discloses a system providing for pre-boot file and informa­tion transfer between networked devices (see abstract, lines 1-3). Whenever a client connects to a net­work, the client firm­ware (column 4, lines 47-50) exe­cutes a program which seeks a server with which to commu­­nicate. The server management appli­ca­tion (SMA) then "performs whatever tasks it is preprogrammed to per­form", for instance "file transfers, file updates or operating system rescue (due to malicious or acciden­tal damage)" (column 4, lines 43-46 and 60-63). It is al­so dis­closed that the SMA might check whether the cli­ent boot sector is virus-free and, if not, remove the virus and restore the boot sector (column 4, lines 63-67).

Main request

6. The board considers that D3 constitutes a suitable star­ting point for the assessment of inventive step.

7. The appellant argued that "persistent" in the context of the claimed invention referred to the partial driver agent's function of reconstituting the full servicing agent if it was corrupted or parts of it were removed or lost, and that D3 therefore did not disclose a "per­sis­tent servicing agent".

7.1 The board disagrees, noting that appellant's use of the term "persistent" is not established in the art. Speci­fi­cally, it does not correspond to ­­the conven­tio­nal understanding that memory may be called "persistent" if its contents are not lost when the power is switched off and that program code may be called "persis­tent" if it is held in persistent memory.

7.2 The board also notes that the capa­bility of the agent to reconstitute itself is expressly claimed, so the characterisation of the servicing agent as "persis­tent" - as interpreted by the appellant - does not limit the claim further.

7.3 The board concludes that D3 discloses a "persistent ser­vicing agent" according to a conventional under­stan­ding of the term, because the servicing agent of D3 is held in persistent memory (see column 2, lines 38-54).

8. Claim 1 according to the main request differs from D3 in that

i) the "persistent servicing agent disposed in the electronic device" comprises two parts, a "full function driver agent" and a "partial driver agent [...] with a reduced set of functions", and

ii) the partial driver agent is "configured to deter­mine whether a full function driver is available in the electronic device" and "to reload portions of the full function driver" should that not be the case.

8.1 The board considers that an effect of this arrangement is that the servicing agent can be made larger than would fit in the concealed section of memory. The board however considers that occasions will na­tu­rally arise in which the functionality of the servi­cing agent must be exten­ded. It may further happen that the concealed memory location allocated for the servi­cing agent becomes too small. This corresponds to a state­ment made in the description itself (see page 27, section B, lines 1-3).

8.2 The objective technical problem solved by the above diffe­rence can therefore be considered as how to handle the situation that an extended servicing agent does not fit in the concealed memory space of D3.

8.3 In this situation the board considers it obvious for the skilled person to store parts of the servicing agent­­ elsewhere. The skilled person may also be forced to store the additional functionality in a place in which it is less "concealed" and thus can be removed or corrup­ted.

8.4 D3 teaches the skilled person to protect the servicing agent against tampering. The skilled person would there­fore be led to search for known ways of protecting the non-concealed parts of the servicing agent.

9. In the board's view, D1 provides such a teaching.

9.1 D1 discloses that the client workstation, in a pre-boot process, initiates communication with a server running "server management application" SMA, which then per­forms "whatever tasks it is preprogrammed to perform", such as "file transfers" and "file updates" (column 4, lines 42-50 and 56-57). As an example, D1 discloses that the SMA may remove a virus from the boot sector and restore the boot sector (column 4, lines 63-67). The board considers that detecting that a piece of software is virus-infected falls within the claimed determi­na­tion of whether the software is "available" or "missing". The board therefore finds that D1 discloses the reloading of software which may be missing from or not available at the electronic device.

9.2 The appellant argued that D1 did not disclose a "ser­vicing agent" within the meaning of the claim because it was confined to pre-boot activities. The term "ser­vi­­cing agent" and "service" clearly related to an "ope­ra­ting system service", whereas D1 taught ter­mi­nating the SMA's interaction with the client before running the operating system. As a consequence, it was argued, the skilled person would not turn to D1 in trying to solve a problem with D3.

9.3 The board notes that the claims do not explicitly spe­ci­fy when the agent programs are to run, i.e. before or after the boot phase, and disputes that the term "ser­vice" alone must be con­strued, as the appellant suggests, to imply that they are run after booting. The board there­fore takes the posi­tion that whatever the SMA accor­ding to D1 performs can va­lid­ly be called a ser­vice, notwith­standing the fact that it runs before booting. More­over, the board con­si­ders that the skilled person, star­ting from D3, would be taught by D1 that - and how - missing or corrupted software can be recon­sti­tuted in the pre-boot phase and would not hesitate to apply this teaching to D3.

9.4 The appellant further argued that D1 did not disclose a pro­gram arranged in such a way that a part of it was set up to reload other parts of itself. D1 disclosed that the operating system could be the subject of the pre­-boot service, and that the latter had a "functional sub­set of the operation system" at its disposal (co­lumn 5, lines 1-15) but that the missing portions were reloaded not by the partial opera­ting system itself but by a separate service.

9.5 The board is not convinced. The claimed in­ven­tion does not specify which service the servicing agent is meant to "enable, support and/or provide". Therefore, what does or does not belong to this ser­vice is, in the board's view, an exclusively concep­tual definition. Accordingly, it is justified to consi­der the reloading function of the SMA according to D1 (see point 9.1 above) to constitute a part of the provided service which, hence, is equipped to reload "itself".

10. In view of the above, the board considers that the skilled person would, without exercising any inventive skill, apply the cited teaching of D1 to D3 and arrive at the claimed invention - except for the fact that the "reloading" service of D1 is carried out under the con­trol of software (the SMA) running at the server, where­­­as the claimed driver agent controls the reloading it­self.

10.1 In this regard, the board considers it obvious for the skilled person to transfer some functions from the ser­ver to the client and to run some of the pre-boot ac­ti­vi­ties locally rather than on the server, for in­stance if the number of clients communicating with the same server made better load-balancing desirable.

10.2 In summary, the board concludes that claim 1 of the main request lacks inventive step over D3 in combina­tion with D1, Article 56 EPC 1973.

First auxiliary request

11. Claim 1 of the first auxiliary request differs from claim 1 of the main request by additional features meant to characterise the run module.

11.1 These specify that the run module comprises "an installer module which is configured to automatically adapt an installer mode instance of the partial driver agent to an operating system of the electronic device".

11.2 Originally filed claim 4 defines the run module as com­prising "an installer module configured to automati­cal­ly adapt the driver agent to the operating environ­ment of the electronic device" but does not mention that an installer mode instance is generated and adap­ted in the process.

11.3 For further original disclosure, the appellant referred to sections B and C on pages 21-22 and to page 18, se­cond paragraph, of the application as originally filed. On page 21 (section B) it is disclosed that the in­staller module AIM "creates and installs the installer mode instance" of the agent, but not that the installer mode instance is further adapted before installation, and it is disclosed that "the installation mechanism is specific and unique for each OS", but not that the installer mode instance itself is. On pages 18 and 22 (2nd paragraph) it is disclosed that the agent may be adapted to the operating system or the platform, but not that an installer mode instance of the agent is adapted further.

11.4 Therefore, the board concludes that the basis indicated by the appellant does not disclose that it is an "in­staller mode instance", i.e. an instance of the partial driver agent, which is adap­ted to the operating system of the electronic device.

12. Article 13(1) RPBA provides that any amendment to a party's case after it has filed its grounds of appeal or reply may be admitted and considered at the board's discretion and that this discretion is to be exercised in view of inter alia the current state of the pro­cee­dings and the need for procedural economy.

12.1 The board considers that considerations of procedural economy justify not admitting a request is not admitted which has substantial defi­ci­encies and does not further the proceedings, especially if it is filed at such a late stage.

12.2 Therefore, the board exercises its discretion under Ar­ticle 13(1) RPBA not to admit the first auxil­iary re­quest due to its deficiencies under Article 123(2) EPC.

Second auxiliary request

13. Claim 1 of the second auxiliary request incorporates in­to claim 1 of the main request the features of ori­gi­nal claim 4, according to which the driver agent is "au­tomatically adapt[ed] [...] to the operating environ­ment of the electronic device".

13.1 The board considers this feature to be unclear. Given that the operating environment of the device is entire­ly undefined in the claim and is thus unlimited by it, the skilled person would not know which operations fell under the claimed adapta­tion of an agent to this "ope­ra­ting environ­ment".

13.2 For clarification, the appellant referred to the second paragraph of page 18 of the description which discloses that "The AIM [...] detects active operating systems, and adapts the mini CDA" - i.e., the partial driver agent - "to the discovered installations". It argued that the skilled person would understand from this passage that the driver agent had to be modified to be­come, and registered as, an "operating system ser­vice".

13.3 The board is not convinced that the disclosed adapta­tion to the installed operating system[s] would have to be construed as the agent's registration as an opera­ting system service, apart from the fact that the board considers the notion of an "operating system service" in itself to be vague and unclear. And the board con­si­ders that the cited passage is insufficient to cla­rify what modi­fi­cations to the agent are meant to be implied by the adaptation mentioned.

13.4 The board concludes that claim 1 of the second auxilia­ry request is unclear, Article 84 EPC 1973.

Third auxiliary request

14. The third auxiliary request was filed in an attempt to overcome the board's clarity objection against claim 1 of the second auxiliary request.

14.1 Amended claim 1 specifies that the installer module "adapt[s] the driver agent to the operating system of the electronic device that controls input/output ope­rations of the device by detecting the operating en­viron­ment".

14.2 This amendment indicates that the adaptation relates to "input/output operations" and relies on the "operating environment" to be detected. The board notes that it is a matter of necessity that the opera­ting environ­ment (and system) be "detected" if the agent is to be adap­ted to the operating system, and that this feature was therefore already implicit in previous claim 1. More importantly, however, neither of these amendments cla­ri­fies to the board's satisfaction the adaptation ope­ration itself.

14.3 The board therefore concludes that the amendment is insufficient to overcome its clarity objection.

14.4 Therefore the board again exercises its discretion under Article 13(1) RPBA as explained above and de­clines to admit the third auxiliary request into the pro­ce­edings because it cannot overcome the clarity ob­jection raised, Article 84 EPC 1973.

Summary

15. In the absence of any allowable request, the appeal has to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation