T 1379/11 (Audit trail/SAP) 25-10-2016

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

The invention

2. The application relates to auditing of a business object when it has reached a designated status and, in particular, to the interaction between a status management service and an audit trail service for enabling such auditing (see paragraph [001] of the description as originally filed).

2.1 The system of the invention includes an application server and implements a service-oriented architecture, such as SAP's Enterprise Services Architecture (ESA) (paragraph [033], Figure 1, paragraph [035]). The business objects may include methods implementing services, such services describing "complete elementary steps in business processes, such as making a purchase order, providing a product cost estimate, invoicing a customer for a service". By invoking services of the business objects, external applications may access and manipulate the business objects via the Internet, SAP Exchange Infrastructure (XI), DCOM or CORBA. Objects stored in the database may be accessed by means of Business Application Programming Interfaces (BAPI) (paragraph [039]).

2.2 According to the application, in a service-oriented architecture, such as SAP's ESA, "business objects may use a status management service and an audit trail service". Systems and methods consistent with the invention "implement an interaction between a status management service and an audit trail service", activating the audit trail service when a business object has reached a designated status (paragraph [024]).

A status management service provides methods and interfaces to generically handle a status management process for business objects, for example to obtain an overview of the status of a given business object or allow and/or prevent actions on it (e.g. changing values, deleting the object) (paragraph [025]). An audit trail service may provide functionality to implement generic auditing of business objects; for example, it may log changes to business objects and allow access to logged changes as needed (paragraphs [027] to [029]).

In order to use the status management service and the audit trail service, business objects preferably implement respective interfaces (paragraphs [026] to [028]). The application describes exemplary methods that can be called by the application server, namely the "status function set", shown in Table 1 (see page 17, line 5, to page 18, line 2) and the "auditable function set" shown in Table 2 (see page 19, lines 4 to 14).

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.