T 2052/15 (Asychronous antivirus processing/KASPERSKY) 19-06-2018

The invention

1. The application relates to the field of malware detection.

1.1 Several types of prior-art system are discussed. Signature scanning systems search for known malicious code patterns and allow a program to execute only if it is found to be "clean" (page 2, paragraph 2; all references hereinafter to the description are to the description as originally filed). Emulation-based systems analyse the behaviour of unknown programs in a protected environment (paragraph 3). Other systems allow unknown programs to run, but intercept "events" which may cause harm and perform an analysis at that point (paragraph 5).

1.2 It is said that the prior-art methods are too time-consuming and thus cause inconvenient delays in the operation of a computer system (see page 2, line 2, to page 3, line 7).

1.3 The invention thus proposes a system based on event interception and asynchronous, on-the-fly behavioural analysis.

1.4 More specifically, system events are intercepted and passed through one of several filters (see e.g. figure 2, no. 240). Each of the filters represents a "security criterion", and an event not fulfilling such a criterion is said "not [to] pass through" the corresponding filter (see page 6, paragraph 2, and figure 3). If an event "does not pass through at least on[e] of the filters", i.e. if it does not fulfil at least one "filtering security criteri[on]", it is considered safe and "sent for further processing"; if it passes through all the filters, a "copy" of the event is created and added to an event queue before the event is "released for further processing" (loc. cit.). The copy is then asynchronously processed. It is "converted into a control record" by adding "information about the event" and passed to an antivirus (AV) utility (see page 6, paragraph 3, and figure 4, in particular step 440), which performs "signature scanning" using "short signatures" representing "behaviour characteristics taken over a period of time" and executes the process which caused the event in an emulator. Emulation of the process produces a "behavior log" for further analysis (see figure 5 and page 6, last paragraph, to page 7, paragraph 2).

1.5 If the AV utility reveals that an event is malicious, the process causing it is "blocked and terminated" (loc. cit.). It is disclosed that the "harm caused by malware during the delay period can be easily compensated by roll backs, incremental backups (snapshots), virtual copies etc." (see page 6, penultimate paragraph). No further details on these "repair" activities are disclosed.

Article 123(2) EPC

2. The wording of claim 1 as it now reads is disclosed in the application as originally filed, in figures 3-5 and the corresponding passages of the description. More specifically, the "by" phrase in step (e) is disclosed in figure 4, item no. 440, and the use of an emulator and the creation of a behavior log are disclosed in figure 5, items no. 530 and 580. Feature (h) as it now reads corresponds to feature (h) in claim 1 as originally filed.

Article 84 EPC

3. Claim 1 comprises some very broad features.

3.1 The control record is created from the queued copy of the system event to be analysed and undergoes "signature scanning" (see claim 1, lines 9-10, and steps (e) and (g)) and must thus be construed as a data structure. Compared with the copy of the system event, the control record contains some additional - albeit undefined - "information about the event". The control record and the copy of the system event are therefore different from each other. Although the signature scanning of the control record (see step (g)) is not further defined in the claim, the board takes the view that the skilled person would interpret it, by analogy with the signature scanning of program code (as explained on page 2 of the description, in paragraph 2), as a comparison of the control record with predetermined patterns in order to determine whether it represents a malicious or non-malicious system event.

3.2 Step (h) specifies that a process may be found to be non-malicious - even though it has "behavior differences" from a known non-malicious process - if it also has "substantial similarities" to that process. This feature does not define what similarities are considered or which ones might be considered "substantial" enough for the process under consideration to benefit from the classification of the earlier process as non-malicious. The board understands this feature to imply, in very broad terms, that the decision whether a process is malicious is based on behaviour and code similarity.

3.3 The board considers that the breadth of these features does not render the claims unclear.

The prior art

4. D8 discloses "dynamically detecting computer viruses through associative behavioral analysis" (see abstract and column 2, lines 32-41). A "monitor/analyzer" component is used to intercept system calls (see figures 2, 3 and 5, and column 4, lines 15-22 and 53-58). If the intercepted event is a "monitored event" (see column 5, lines 26-39, and column 6, lines 26-42), it is determined whether the calling application performs a sequence of actions which are known to be characteristic of computer viruses and thus suspicious (column 4, lines 22-25); such actions may, for instance, be the writing of a few bytes to the end of a file or the sending of an email to a name in an address book (see column 5, line 43, to column 6, line 7). If a suspicious sequence of actions is detected, the event is stored in a database (see figure 2, no. 37) in the form of an "event log record" (figure 4; see also column 6, lines 55-58). Based on the event log records in the database, histograms are generated and analysed so as to detect "repetitions of suspicious behavioral patterns" (column 4, lines 25-27, 35-36 and 62-67; column 5, lines 7-17 and 55-58; and column 6, lines 5-7). If suspicious behaviour is detected, an "alert" is produced (column 5, lines 24-25).

5. Documents D2 and D3 were cited in the decision (see points 3.5 and 3.6 of the reasons) to establish that it was known in the art to block or terminate processes determined to be unsafe and to classify processes as safe or unsafe based on comparison with known objects. As the appellant did not challenge these assumptions, no further reference to D2 and D3 is required.

Inventive step, Article 56 EPC

6. Irrespective of whether D8 discloses or suggests "asynchronous antivirus processing" in general, which was the decisive issue for the appellant (see the grounds of appeal, page 6, point e)), D8 does not disclose or suggest the use of an emulator for that purpose. More explicitly, D8 clearly does not disclose carrying out behavioural analysis on a copy of a suspicious process while the process itself is allowed to proceed.

6.1 The board takes the view that this set-up provides a new balance between the security provided by antivirus processing and the responsiveness of a process which is being analysed. In other words, the invention makes it possible to carry out antivirus processing whilst disturbing the user owning that process only when necessary.

6.2 The board takes the view that increasing the responsiveness of a computer in a way which does not depend on which - or which type of - software it is executing affects the computer technically and thus is a technical problem. Moreover, using the available computing resources in an asynchronous - and thus possibly parallel - manner is a technical solution to that problem.

6.3 As the subject-matter of claim 1 - and, as a consequence, of claim 6 - is the non-obvious technical solution to a technical problem, a patent is to be granted for the claimed invention.