T 1379/11 (Audit trail/SAP) 25-10-2016
Téléchargement et informations complémentaires:
Systems and methods for providing an interaction between a status management service and an audit trail service
Inventive step (no)
Inventive step - mixture of technical and non-technical features
Inventive step - closest prior art
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.
The decision's reasoning with regard to inventive step relied on the following documents:
D3: Gamma, E.: "Design Patterns: Elements of Reusable Object-Oriented Software", pages 13 to 18 and 293 to 303, Addison-Wesley, 1997;
D4: Minka, T.: "Observer Pattern", retrieved from the Internet, http://alumni.media.mit.edu/~tpminka/patterns/Observer.html, 23 January 1997.
The Examining Division considered that the claimed invention related to business requirements and lacked inventive step in view of either document D3, which was considered to be the closest prior art, or document D4 and the common general knowledge of the person skilled in the art.
In an obiter dictum the Examining Division drew attention to a possible deficiency of the claims due to added subject-matter (Article 123(2) ECP).
II. With the statement of grounds of appeal, the appellant requested that the decision be set aside and that a patent be granted on the basis of the request then on file, corresponding to the claims on which the contested decision was based. With the notice of appeal the appellant also requested reimbursement of the appeal fee.
III. With effect from 12 September 2014 the EPO registered a change of name of the applicant/appellant to SAP SE.
IV. The appellant was invited to oral proceedings. In a subsequent communication informing the appellant about its preliminary opinion, the Board agreed with the Examining Division that some aspects of the claimed invention were non-technical, but expressed doubts that document D3 was a good starting point for assessing inventive step and that the skilled person would arrive at the claimed invention from that starting point without having to exercise inventive skills.
The Board cited the following documents:
D2: US 2002/0188513 Al, published on 12 December 2002; and
D5: Endrei, M. et al.: "Patterns: Service-Oriented Architecture and Web Services", IBM Redbooks, pages 17 to 69, 144 to 150, 229 to 233, and 279 to 281, April 2004.
Document D2 had been cited in the first-instance proceedings. Document D5 was introduced by the Board.
In the Board's preliminary opinion, the subject-matter of claim 1 of the sole request was not inventive taking into account a prior-art system based on service-oriented architecture, such as one of those acknowledged in the application, and the ordinary skills and common knowledge of the skilled person. Document D5 illustrated the common general knowledge in the technical field of the invention. In addition, the Board expressed the view that document D2 was relevant for the assessment of inventive step, and compared the subject-matter of claim 1 with that disclosure. The Board drew attention to possible issues with regard to Articles 84 and 123(2) EPC.
V. The appellant did not comment in writing on the issues raised in the Board's communication. Oral proceedings were held on 25 October 2016. During the oral proceedings the appellant withdrew its request for reimbursement of the appeal fee. At the end of the oral proceedings, the chairman announced the Board's decision.
VI. The appellant's final request was that the contested decision be set aside and that a patent be granted on the basis of claims 1 to 7 filed with letter dated 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.
IX. The arguments of the appellant, insofar as relevant for the present decision, can be summarised as follows:
The Examining Division had not applied the problem-solution approach correctly. It had established the closest prior art after formulating the technical problem. Furthermore, it had performed an ex post facto analysis.
The Examining Division had argued in the decision that the prior art for "monitoring of changes" was computer programming in general. However, the invention did not relate to the technical field of monitoring changes generally, but specifically to enabling an audit of a business object.
In accordance with the Guidelines for Examination, the closest prior art should be directed to a similar purpose or effect as the invention, or at least belong to the same or a closely related technical field as the claimed invention. Document D3 related to event notification between distributed objects for the purpose of maintaining consistency between related objects. Without prior knowledge of the technical solution according to the claim, a skilled person would not have had the idea to transfer the principles known from some specifically described "observer patterns" within the broad field of computer programming to a computer implementation of audit trail services.
In the appellant's view, it would be similarly obscure to cite hinges of refrigerators as closest prior art for a new door hinge of a truck with the sole argumentation that both refrigerators and trucks related to the same technical field of mechanical engineering.
The fact that business methods were excluded from patentability did not mean that the technical field of prior art selected could be so broad that any kind of computer software implementations was covered. What was important was a realistic consideration of prior art already covering implementations of the business method in combination with notoriously known technical features like simple client-server architectures or data transmissions between different computers.
As a consequence, document D3 could not be considered as the closest prior art.
The closest prior art was that of documents D1 (not cited in this decision) and D2, since those documents related to the same technical field as the invention, namely the computer implementation of audit trail services. All that was known from that prior art was that changes to data were recorded in an audit trail. Further, it was known as a business constraint that not every change to an object was worth auditing. The distinguishing features had the advantage that flexible auditing services could be provided for any kind of business objects with minimised data transmission since not every change to an object was audited (the appellant cited paragraphs [007], [057] and [058] of the patent application), and solved the corresponding problem of providing flexible auditing with minimised data transmission. The distinguishing features were not the direct result of business requirements. Documents D1 and D2 did not suggest the claimed solution. The skilled person would not have chosen the claimed solution on the basis of the prior art considered by the Examining Division.
Reasons for the Decision
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.
Order
For these reasons it is decided that:
The appeal is dismissed.