T 1379/11 - Combinations of technical and non-technical features
In this appeal against a decision of the Examining Division the claims have a combination of technical and non-technical features and this plays an important role in the inventive step reasoning of the Board. The question is whether the applicant has really added something technical or that the claimed method is an obvious implementation of business requirements in a know technical system. In this case there are also some interesting paragraphs about the selection of the closest prior art - the Board writes "The Examining Division made an attempt to apply both criteria... but failed to do so in a convincing manner.".
Summary of Facts and Submissions
I. The applicant appealed under its former name, SAP AG, against the decision of the Examining Division to refuse European patent application No. 06290710.0 for lack of inventive step (Articles 52(1) and 56 EPC) of the subject-matter of the claims of the sole request filed with letter of 5 October 2010.
[...]
VII. Claim 1 of the sole request reads as follows:
"A computer-implemented method for providing an interaction between a status management service and an audit trail service, the interaction enabling an audit of a business object when the business object reaches a designated status, comprising:
receiving, at an application server, a notification of [28] change associated with the business object;
determining, at the application server [52], in response to the change, whether the business object is a status business object and an auditable business object;
when the business object is a status business object and an auditable business object, the business object has implemented [44] a status function set to interface with the application server to determine whether the change to the business object is allowed;
receiving, at the application server [53], through a first called method of the status function set, a notification indicating whether the change is allowed;
determining, in case the change is allowed at the application server [54] through a second called method of the status function set, whether the business object has reached the designated status;
when the business object has reached the designated status, requesting at the application server [56] auditing data for the business object, wherein the business object implements an auditable function set to interface with the application server;
receiving, at the application server [56] through a called method of the auditable function set, the requested auditing data; and
storing by the application server the received auditing data in a repository."
VIII. The main reasons given in the decision under appeal are the following:
The examples of the description corresponded to the following business requirements:
(a) changes to business operations such as purchase orders should be recorded for internal or regulatory reasons, such as for financial audits (paragraphs [006] and [007] of the application as originally filed);
(b) there are situations where a business would like to use status information regarding business operations/transactions, for example to decide whether a transaction/operation may be changed (paragraph [007]);
(c) item (a), i.e. the recording of changes to a business operation, is only allowed if a certain business condition is met (paragraph [046]).
The subject-matter of claim 1 defined an automation of such conditional monitoring of changes by providing an interaction between a status management and an audit trail implemented in a computer. The business scheme above would be given to the skilled person to be implemented into an electronic system. Requirement (a) directly led to an audit trail service, requirement (b) immediately implied the use of a status management service, and requirement (c) led to the implementation of the condition for logging information by the audit trail.
Since object-oriented design was a commonplace programming method, the skilled person, who was a software programmer, would find document D3. That document was considered to be the closest prior art because its teaching fulfilled the purpose of monitoring changes, which was essential for an audit trail, and had more features in common with claim 1 than any other cited prior-art document. Document D3 was a standard software design book which disclosed design patterns. The features distinguishing the claimed subject-matter from that prior art were the following:
- "an interaction between a status management service and an audit trail service, the interaction enabling an audit of a business object when the business object reaches a designated status",
- "an application server",
- "determining, at the application server, in response to the change, whether the business object is a status business object and an auditable business object";
"when the business object is a status business object and an auditable business object, the business object has implemented a status function set to interface with the application server to determine whether the change to the business object is allowed";
- "receiving, at the application server, through a first called method of the status function set, a notification indicating whether the change is allowed";
- "determining, in case the change is allowed at the application server through a second called method of the status function set, whether the business object has reached the designated status"; and
- requesting that the auditing data is performed "at the application server" and "when the business object has reached the designated status".
The distinguishing features consisted of non-technical features, technical features which were directly derived from the business requirements, and a further feature, an application server. Application servers interacting with business objects were well-known at the date of priority of the present application. Applying a known design pattern to a known software architecture did not require any inventive skills.
[...]
Reasons for the Decision
1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.
The invention
[...]
3. The method according to the invention essentially determines, in response to a change associated with the business object, whether the business object is a status business object and an auditable business object. If both conditions are true, it determines whether the change is allowed and changes the object if it is allowed. It then determines whether the new status of the business object is auditable and, if so, audits the change to the object (paragraphs [051] to [056], Figure 4).
Inventive step
4. The Board agrees with the Examining Division that some aspects of the claimed method are non-technical. In addition to requirements (a) to (c) identified by the Examining Division (see section VIII above), the Board also mentions the following further requirement:
(d) changes to data are to be performed only if allowed.
4.1 At the oral proceedings the appellant reiterated its argument that in the decision under appeal the Examining Division had misapplied the problem-solution approach (see section IX above). Document D3 had a completely different background. The closest prior art had to be a logical choice for the skilled person dealing with the kind of matter to which the invention related, and should have technical and non-technical features in common with the invention.
4.1.1 According to the jurisprudence of the boards of appeal, the skilled person is an expert in a technical field. The state of the art to be considered in the context of Articles 54 and 56 EPC concerns everything which is relevant to some field of technology, i.e. from which a skilled person would expect to derive technically relevant information (see decision T 172/03 of 27 November 2003, reasons 4 to 10). It follows that the closest prior art, which is part of the state of the art, does not normally have to include non-technical features of the claim. On the other hand, features which would, when taken in isolation, be considered non-technical may nonetheless impose technical requirements or contribute to the technical character of the invention (see e.g. G 3/08, OJ EPO 2011, 10, reasons 12.2.2, T 1145/10 of 26 February 2016, reasons 5). Such features should be taken into account when choosing a starting point for assessing inventive step. In the present case, even though business auditing is per se non-technical, its implementation involves logging data about changes performed to data objects in persistent storage.
4.1.2 Inventive step should be assessed on the basis of a realistic starting point which discloses subject-matter that could realistically have been considered by the inventor on the effective filing date as a starting point for further development possibly leading to the invention. Otherwise, any attempt to develop without hindsight a logical chain of reasoning showing that the skilled person would arrive at the invention in an obvious manner is bound to fail. In order to choose a realistic starting point for assessing inventive step, the real-world circumstances should be taken into account, as also mentioned by the appellant. The assessment should start from a situation close to one that the inventor could have realistically faced on the effective filing date (T 710/97 of 25 October 2000, reasons 3.2.1). If, starting from a prior-art disclosure, no relevant technical problem can be formulated without inappropriate hindsight, the invention is not obvious with respect to that prior art (see also Case Law of the Boards of Appeal, 8th edition 2016, I.D.3.2 to 3.3, 3.4.3, 3.6).
In order to arrive at the conclusion that inventive step is lacking, a discussion of which prior art is "closer" or "closest" to the invention is not needed (T 967/97 of 25 October 2001, reasons 3.2). For efficiency, it is nevertheless common to identify the closest prior art, i.e. the most promising starting point for an obvious development leading to the claimed invention.
In the light of those principles, the Boards of Appeal have developed certain criteria for identifying the closest prior art. According to decision T 698/10 of 27 April 2015, as a first criterion the closest prior art should disclose subject-matter related to the claimed invention, i.e. subject-matter conceived for the same purpose or aiming at the same objective, corresponding to a similar use, or relating to the same or a similar technical problem or at least to the same or a closely related technical field (see also T 686/91 of 30 June 1994, reasons 4). A second possible criterion is that the closest prior art should disclose subject-matter having the greatest number of relevant technical features in common with the claimed invention, i.e. requiring the minimum of structural and functional modifications (see T 686/91, reasons 3). This second criterion is on its own not sufficient since a disclosure meeting it does not necessarily qualify as the closest prior art or as a promising starting point (see T 698/10, reasons 3.5 and 3.9, T 686/91, reasons 4, and Case Law of the Boards of Appeal, 8th edition 2016, I.D.3.2 to 3.4).
4.1.3 The Examining Division made an attempt to apply both criteria mentioned in the preceding point to choose the closest prior art but failed to do so in a convincing manner.
In the present case, document D3 concerns the "observer pattern" which is used for defining "a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically" (see page 293, "Intent"). The document describes the observer pattern in rather abstract terms and gives some examples of applications of the disclosed concepts, namely in programming a digital clock (pages 301 to 303) and user interface tool kits (page 303). None of the examples is similar to that of the present application. The Examining Division was of the opinion that the disclosure of document D3 fulfilled the purpose of monitoring changes, which was essential for an audit trail. The Board however notes that document D3 is related to the problem of event notification between distributed objects for the purpose of maintaining consistency between those objects. This, or the associated monitoring, is only remotely related to auditing interpreted according to its technical meaning in the application of logging data with regard to a data object in a persistent storage in response to data changes. Document D3 therefore does not fulfil the first criterion mentioned above.
The Examining Division was furthermore of the opinion that document D3 had more features in common with the claim than all the other prior-art documents. As can be derived from point 4.1.2 above, that criterion should be given less weight than the other considerations for choosing a closest prior art (see also T 458/07 of 23 September 2009, reasons 75). In addition, the Board finds that although document D3 describes object-oriented programming it does not disclose its use in the context of an application server or a similar environment. Nor does it disclose many features in common with the claim (see also section VIII above).
The Board considers that the skilled person would not realistically start from the abstract observer design pattern for event notification to solve the problem of auditing, and arrive at a method of auditing implemented on an application server. The Board therefore concurs with the appellant in finding that document D3 would not be a logical choice for the skilled person dealing with the kind of matter to which the invention relates. It is not a realistic starting point.
5. As explained in the application, at the date of filing of the present application prior-art systems existed which were based on a service-oriented architecture (SOA) such as SAP's ESA. Some of those systems supported business objects, as a "software bundle of variables (e.g. data) and related methods" (paragraphs [004] to [006] and [024]) using object-oriented programming (paragraph [006]). In the Board's view, as expressed in its preliminary opinion and not contested by the appellant, the application acknowledges that some of those prior-art systems provided a status management service and an audit trail service implemented as central services (paragraphs [008] and [024]) in a "'distributed objects' architecture" (paragraph [004]), typically through an interface provided by a system such as an "application server".
Such a prior-art system, i.e. a "prior art SOA system", supports audit trail and status management services and is therefore a realistic starting point for the assessment of inventive step.
5.1 Claim 1 further recites a particular sequence of steps performed by the system and that
(i) some business objects implement a status function set to interface with the application server to determine whether a change to the business object is allowed and whether the business object has reached a designated status;
(ii) some business objects implement an auditable function set to interface with the application server, the auditable function set including a method to return audit data;
(iii) auditing is performed only if a designated status is achieved; and
(iv) the application server receives the auditing data and stores it in a repository.
5.2 Those features solve the problem of implementing, in the known SOA system, a method fulfilling the non-technical requirements (a) to (d) mentioned above.
5.3 Feature (iii) is directly derived from the business requirement of triggering the audit only if a designated status is achieved (see also requirement (c) under section VIII above).
With regard to the remaining distinguishing features, the Board notes that, at the date of filing of the present application, SOA was a well-known software architectural concept that defined the use of services to support the requirements of software users. Following the associated modelling and design methodology for SOA applications, known by the terms service-oriented analysis and design and SODA (service-oriented development of applications), software developers created common services, which clients or middleware then "orchestrated" to implement processes. Document D5 describes common general knowledge in that area at the date of filing of the present application, including SOA patterns for business applications (see e.g. title, pages 18 and 28).
The Board finds, in line with the contested decision, that it is a matter of customary object-oriented design and programming of a distributed system to establish which methods are necessary, which objects or software components perform them, where data is stored, and how the objects and components interact. The skilled person, using his ordinary skills and his knowledge of SODA to implement a method according to the business requirements in the known SOA system, would consider as an obvious alternative the inclusion of methods supporting auditing and status management functionality in the business objects and the use of the application server to coordinate both services and store the audit data (corresponding to features (i), (ii) and (iv) above). This coordination is similar to that of service brokers used in SOA systems (see D5, page 21, last two lines, and page 55, section titled "Broker and SOA").
In addition, document D5 illustrates that prior-art SOA systems were known that supported "access control of service consumers invoking services" (page 26, "Quality of service aspects", page 281, "Central security control point"), and auditing functions (page 147, "Auditing", pages 230 and 231).
The particular sequence of steps chosen is the result of routine programming by the skilled person given the non-technical constraints. With respect to the feature of determining whether the business object is a status and auditable one, the Board agrees with the appealed decision that such a feature is implicit in a software system, in particular one implemented using object-oriented techniques, since a function can only be called if it is provided.
5.4 With the grounds of appeal the appellant argued that the technical problem solved by the distinguishing features was "how to provide flexible auditing services for any kind of business objects with minimized data transmission accounting for the business constraint that not every change of an object is worth auditing".
The Board, however, follows the contested decision in finding that there are no technical details which ensure that such an effect is achieved, and that the transmission of audit data only when a predetermined condition is met merely reflects business requirements.
Regarding the provision of flexible auditing for any kind of business objects, it is questionable whether it can be recognised from the wording of the claim and whether it constitutes a technical effect. The Board is in any case of the opinion that it corresponds to a well-known advantage of object-oriented design or SODA which would be achieved following standard design methodology.
5.5 From the above it follows that the subject-matter of claim 1 does not involve an inventive step (Articles 52(1) and 56 EPC).
Conclusion
6. Since the sole request on file is not allowable, the appeal is to be dismissed.
Order
For these reasons it is decided that:
The appeal is dismissed.
SHARE:
Comments
Post a Comment