T 0149/20 (Automated error detection/HONEYWELL INTERNATIONAL) 15-12-2022
Download and more information:
Method for automated error detection and verification of software
Claims - clarity
Claims - all requests (no)
I. The appellant (applicant) filed an appeal against the examining division's decision to refuse European patent application No. 11160323.9 (published as EP 2 386 954).
II. The documents cited in the contested decision included:
D1: US 2008/0126902 A1, published on 29 May 2008.
III. The examining division refused the application on the grounds that claims 1, 9 and 10 of the sole request on file did not comply with Article 84 EPC. In the section of the decision entitled "Obiter Dictum", the examining division remarked that the subject-matter of claim 1 also lacked an inventive step in view of document D1.
IV. In its statement of grounds of appeal, the appellant requested that the contested decision be set aside and that a patent be granted on the basis of a main request or a first auxiliary request, both of which were submitted with the grounds of appeal. The main request was based on the refused request but contained a minor language correction, and the first auxiliary request was identical to the refused request.
V. In a communication under Article 15(1) RPBA 2020 accompanying a summons to oral proceedings, the board expressed its provisional opinion that neither the subject-matter of claim 1 of the main request nor that of claim 1 of the first auxiliary request complied with Article 84 EPC. Additionally, the board expressed doubts about the admissibility of the main request, as it appeared to give rise to further objections.
VI. Oral proceedings were held as scheduled and the appellant was heard on the relevant issues. At the end of the oral proceedings, the Chair announced the board's decision.
VII. The appellant's final requests were that the contested decision be set aside and that a patent be granted on the basis of the set of claims of the main request submitted with the statement of grounds of appeal or on the basis of the claims of the first auxiliary request, which was identical to the request on which the impugned decision was based.
VIII. Claim 1 of the main request reads as follows (the itemisation of the features has been added by the board):
"[A] A processor based method for automated error detection and verification of software, the method comprising, with a processor:
[B] providing a model of the software, the model comprising one or more model inputs and one or more model outputs, and a plurality of blocks embedded within the model each with an associated block type, the block types each having a plurality of associated block-level requirements;
[C] topologically propagating from the model inputs, a range of signal values or variable values, and error bounds, across computational semantics of all the blocks to the model outputs (110) with implementation-independent and implementation-dependent type information;
[D] identifying and examining each behavioral pivot value for a given block;
[E] determining if modifying or extending the propagated range by the error bound will or may cause a signal value to fall on either side of the behavioral pivot value (120); and
[F] reporting all occurrences of the signal value that will or may fall on either side of the behavioral pivot value (130)."
IX. Claim 1 of the first auxiliary request differs from claim 1 of the main request in that steps D and E are worded as follows:
"identifying and examining each behavioral pivot value for a given block to determine if modifying or extending the propagated range by the error bound will or may cause a signal value to fall on either side of the behavioral pivot value (120); and"
X. The appellant's arguments, where relevant to the present decision, are discussed in detail below.
1. The application relates to automated error detection and verification of software using a model of the software.
Main request
2. Admissibility
Claim 1 of the main request differs from claim 1 of the first auxiliary request, i.e. the sole request considered by the examining division, only in a change in the wording of steps D and E (see section IX. above). Since the board's clarity objections regarding steps B and C of claim 1 of the first auxiliary request also apply to claim 1 of the main request, the board has decided to admit the main request into the appeal proceedings in view of the need for procedural economy (see Article 12(4) RPBA 2007).
3. Article 84 EPC
3.1 In the contested decision, several objections under Article 84 EPC were raised against claim 1 of the sole request pending at that time. As it is not necessary to review all of these objections in order to arrive at a decision, in the following the board will only consider certain objections regarding the wording of steps B and C of claim 1 (cf. section VIII. above for the itemisation of claim 1), which is identical in claim 1 of both pending requests.
3.1.1 The examining division objected that step B was unclear and not supported by the description. The application presented the model of the software as an input to the method, i.e. providing the model was not a step of the method. In addition, it was unclear how such a model was determined, and the expressions "embedded within the model" and "block-level requirements" were unclear.
3.1.2 According to the examining division, step C was unclear and not supported by the description. The terms "topologically", "across computational semantics", "implementation-independent" and "implementation-dependent" left the reader in doubt as to the meaning of the technical features to which the terms referred. In addition, it was unclear how the range of signal values or variable values and the error bounds were
determined, in particular in view of computational feasibility, for example for texts and images as input. Furthermore, step C defined the subject-matter in terms of the result to be achieved.
3.2 The appellant submitted relevant arguments in its statement of grounds of appeal and in the oral proceedings before the board.
3.2.1 In its statement of grounds of appeal, the appellant argued that the "model of the software" could be thought of as a data flow diagram. A data flow diagram was a graph where each node ("block") in the graph represented a function and the edges in the graph indicated how data flowed from one function to another. The "blocks" were "embedded within the model" because they were the nodes within said graph. The "block type" associated with each "block" determined its functionality - each "block" was an instance of the "block type" class, to use object-oriented terminology. Each "block type" had an associated set of "block-level requirements" describing what its behaviour should be.
Regarding the meaning of the terms used in step C, the appellant argued that the terms "topologically" and "across computational semantics" merely referred to the model usage being carried out in a logical order ("topologically") within an automated computer system ("computational semantics"). The "implementation-independent" and "implementation-dependent" type information specified the use of default data values and model-generated data values respectively. In this respect, the appellant referred to lines 4 to 8 on page 6 of the application as originally filed.
The appellant also submitted that "error bounds" could be determined in two ways: by manual selection a priori, which was typically used for the outer bounds of a graph/diagram, or by propagation. The ranges of signal/variable values could be determined through the use of forward propagation as disclosed in lines 18 and 19 on page 4 of the application as filed.
3.2.2 In the oral proceedings before the board, the appellant argued that the skilled person would consider the claim in its entirety, i.e. in combination with the further features, and with a mind willing to understand the claim rather than with a mind willing to "break" the clarity of the claim. In the context of claim 1, the skilled person would be an expert in software development who was familiar with software, its modelling and its verification in general. The terms of the claim were broad, but the model had some semantics that were specified in the claim. In particular, it modelled the behaviour of the software which allowed it to identify when errors in the software's input could cause the output of the software to pivot, i.e. when the system behaviour could deviate from the model. The terms used in the claims were not to be considered in isolation. For example, the expression "behavioural pivot value" had to be interpreted as a whole, i.e. as a combined expression.
The model could be provided as input to the method as disclosed in the description as originally filed or it could be generated automatically (see page 3, lines 13 to 17, and page 5, lines 6 to 11 and 18 to 20). The wording of claim 1, step B, encompassed both possibilities.
As to the terms "blocks", "block types" and "block-level requirements" in step B, the appellant argued that blocks were a very general concept that reflected the fact that software could be regarded as a set of decisions that were somehow connected to each other with associated types and requirements representing the semantics of the blocks. The appellant submitted that according to decision T 238/88, broad claims did not imply a lack of clarity and that according to decision T 630/93, the function of essential features was to define the claimed subject-matter in a sufficiently clear manner for it to be prosecuted.
The wording "topologically propagating" in step C of claim 1 meant that data was propagated according to the topological order corresponding to the logical interconnections between blocks and thus across the computational semantics of all blocks as claimed. Regarding the terms "implementation-independent" and "implementation-dependent" type information, the appellant argued that when the software was for navigation in general, for example, the corresponding type information was implementation-independent. When the software was for navigation with a helicopter, for example, then the corresponding type information was implementation-dependent.
3.3 The board has duly considered the appellant's arguments and has arrived at the following conclusions.
3.3.1 Regarding the general principle of interpretation of claims, the board agrees with the appellant that the skilled person would read claim 1 using their
background knowledge of software development and would consider all of the features of the claim in the context in which they are found.
3.3.2 The appellant cited decision T 238/88, arguing that broad claims did not imply a lack of clarity. Point 5.1 of that decision reads as follows (with emphasis added by the board):
"Looked at more closely, the position taken by the Examining Division cannot be upheld. The criticised feature "alkyl" in the definition of the R substituents undoubtedly relates to a well-known technical term of art which is commonly used in the chemical field and which does not imply any lack of clarity or ambiguity as alleged by the Examining Division, i.e. it is clear as it stands. Unless sound reasons are given, the breadth of the term cannot be a bar to its incorporation into the claim. [...]"
In view of the above, the question at issue is whether the opposed broad terms in claim 1 have a well-defined, unambiguous meaning in the field of software development.
3.3.3 With regard to the requirement that claims are supported by the description, decision T 630/93 stated the following (with emphasis added by the board) in Reasons 3.2: "[...] it must, however, be kept in mind, that the main purpose of a claim is to set out the scope of protection sought for an invention [...]. Therefore, the function of the essential features, although they normally are expressed in technical terms, is often to define the borders of an invention rather than to define the invention in detail within the borders. The detailed definition is normally made by the additional features, which may concern specific embodiments of the invention, in dependent claims appended to the main claim. [...]". Thus, in view of decision T 630/93, Reasons 3.2, the crucial issue here is whether the features of claim 1 clearly define the borders of the invention as necessary to prosecute the application.
3.3.4 The board observes that according to the application as filed (see description, page 3, lines 13 to 17), the "inputs to the present method are (i) a model of the system behavioural requirements, (ii) behavioural semantics of a model's computational elements, (iii) data type- and platform-dependent constraints/characteristics, and (iv) normal and maximum operating signal ranges at models inputs".
The appellant acknowledged that the model could be provided as input, but argued that page 5, lines 10 to 11 and 18 to 20, of the description as filed also disclosed that "a source code parser can be used to automatically generate the model from existing source code", which supported an automatic generation of the model.
The board points out that claim 1 expressly specifies that the method is "processor based" and that step B is performed "with a processor". In the oral proceedings, the board informed the appellant that according to the description as filed, page 8, first paragraph, the word "processor" appeared to be used as a synonym for "computer". Consequently, the board takes the view that the wording of claim 1 appears to exclude the possibility that the model is provided as (manually-generated) input to claim 1, further noting that step B is silent regarding any input or interaction with a user. The appellant's arguments concerning the different possible interpretations of step B of claim 1 are an indication that claim 1 is not only broad but also ambiguous and thus unclear (Article 84 EPC), since the appellant itself arrives at different, alternative interpretations of step B of claim 1.
Furthermore, the board agrees that the description discloses on page 5 that the model can be generated by parsing existing source code. However, claim 1 is entirely silent on using any existing source code as input and on parsing source code. For this reason alone, step B, when interpreted as providing the model of the software automatically by the computer, is not sufficiently supported by the description as it does not define the borders of the invention (Article 84 EPC). In view of the above, the board agrees with the examining division that the skilled person cannot understand how the "model" of the software is provided in step B (Article 84 EPC), and therefore the claimed subject-matter is not sufficiently clearly defined to prosecute the application.
As to the clarity of the terminology, the board agrees with the examining division that the expressions "embedded within the model" and "block-level requirements" are unclear. It is not understandable what aspects of the software the various "blocks" represent at which level of detail, and which requirements are associated with these blocks. Claim 1 does not further specify what is meant by terms such as "embedded" or "block-level requirements" and also does not refer to "requirements" in any of the other steps of the method of claim 1. The board is not convinced that these terms, which represent essential features of the invention, have a well-defined, unambiguous meaning in the field of software development and the appellant did not provide any suitable evidence that this was the case. The further features of claim 1 provide some context for step B, but are insufficient to clearly define the meaning of the terms in step B that were called into question.
Consequently, step B of claim 1 is unclear (Article 84 EPC).
3.3.5 Regarding step C of claim 1, the board takes the view that the skilled person reading claim 1 will not understand that the terms "implementation-independent" and "implementation-dependent" specify the use of default data values and model-generated values, respectively, as argued by the appellant in its statement of grounds of appeal. Rather, as explained in the oral proceedings, since the software, i.e. the implementation, is modelled, it is unclear what is meant by "implementation-independent" type information in the context of claim 1. The board is of the opinion that the appellant's further explanations in the oral proceedings regarding the meaning of these terms using navigation software as an example are neither convincing nor consistent with the appellant's submissions in its statement of grounds of appeal. Rather, it is evident that these terms do not have a well-defined, unambiguous meaning in the field and are not defined by the further features of claim 1 either. Consequently, the appellant's arguments have failed to convince the board, which has concluded that step C does not clearly define the boundaries of the invention claimed.
It follows that step C of claim 1 lacks clarity (Article 84 EPC).
3.4 In summary, claim 1 of the main request does not meet the requirements of Article 84 EPC.
First auxiliary request
4. Claim 1 of the first auxiliary request is identical to the sole request considered in the contested decision and differs from claim 1 according to the main request in that steps D and E are combined into a single step by amending "determining" to "to determine".
5. The above objections to the main request under Article 84 EPC also apply to independent claim 1 of the first auxiliary request since the amendments do not impact the board's objections and the appellant relied on the same arguments for both the main request and the first auxiliary request. Consequently, claim 1 of the first auxiliary request does not meet the requirements of Article 84 EPC either.
Conclusion
6. Since none of the appellant's requests can form the basis for the grant of a patent, the appeal is to be dismissed.
Order
For these reasons it is decided that:
The appeal is dismissed.