T 0634/08 (Network events/ACCENTURE) of 8.5.2012

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division to refuse European patent application No. 03253075.0 entitled "Distributed transaction event matching" and published as

A2: EP-A2-1 365 342,

on the ground of lack of inventive step, Articles 52(1) and 56 EPC 1973. The examining division considered the claimed subject-matter to relate to a billing method among content and service providers based on (non-technical) business rules concerning contractual uses of networks. The technical framework for monitoring network events was considered to be known while technical partial problems were regarded as solved by the skilled person without an inventive step relying on prior art such as

D1: WO-A-01/28141 and

D2: US-A-2001/0049632.

II. In the statement setting out the grounds of appeal (received 4 December 2007), the appellant requested that the decision under appeal be set aside and the case be remitted to the department of first instance with the order to grant a patent on the basis of one of four claim sets (Main Request, First, Second or Third Auxiliary Request) filed with the statement of grounds of appeal. Oral proceedings were requested on an auxiliary basis.

The main request was said to address "a clearly technical problem": "to enhance efficiency of data transactions and/or exchange among network entities in distributed tracking and reporting systems and thereby in particular, to reduce network overload in such systems" (statement of grounds of appeal, bottom of page 8).

III. The Board presented a preliminary analysis of the case in a communication under Rule 100(2) EPC, dated 23 August 2011. The overall goal of the application seemed to be a business policy, and the claimed solution amounted to a reformulation of that policy while the technical implementation appeared to be readily available to the skilled person. Therefore, the Board did not identify any non-obvious technical contribution within the meaning of Article 56 EPC 1973.

IV. In response to the Board's communication, the appellant has restricted its set of requests (letter received on 9 December 2011):

- the second auxiliary request filed with the statement of grounds of appeal has been upgraded to the current Main Request;

- the third auxiliary request filed with the statement of grounds of appeal has been upgraded to the (only) Auxiliary Request, with a feature from the description (paragraphs 0069 and 0084 of the A2 publication) incorporated into the independent claims.

The appellant emphasises technical aspects of the implementation. The method of tracking network events is said to prevent errors in data processing. In particular, the auxiliary request tackles the problem of a server crash followed by a recovery procedure.

(a) Claim 1 according to the main request reads:

"1. A method of tracking network events, comprising:

storing (304), in a database (224), a plurality of rules corresponding to a contract entered into between entities, the entities including a third party entity and at least two of a plurality of providers (202, 204, 212, 216, 220), the providers separately operable on a plurality of different platforms, and the at least two of the providers each operable on a respective different one of the different platforms;

monitoring (402), with a metering application (602), a plurality of network events conducted across the at least two different platforms, the plurality of network events including the transmission, by the plurality of providers, of information and electronic products to end users (208);

identifying, with the metering application (602), from among the plurality of network events, only those network events that match contractual events between the entities as defined within clauses of the contract between the entities;

evaluating (1412), with an event collection application (604) the identified network events to identify one or more of the identified network events that match with at least one rule stored in the database (224) to create one or more business events (1414) when the identified network events match a clause of the contract between the entities;

creating (1422) at a bundle producer distinct bundles of like business events based on the clause of the contract matched to the corresponding one or more business events;

receiving the distinct bundles at a conditioning application (606);

applying, with the conditioning application (606), valuation information to the business events of the bundles based on the clause of the contract, comprising:

comparing (1512) at least one business attribute of at least one of the business events against acceptable values listed in one or more validation strategies tables,

applying (1516) a base-value to each of the business events upon completing execution of base-value determination activities defined within the clause of contract,

applying (1518) one or more modifiers to the base value to obtain a macro-value for each of the business events, and

updating and committing (1524) a macro value counter at the database (224), wherein the macro value counter keeps a count that represents a total sum of the macro values of the business events; receiving bundles of like conditioned event objects at a settlements processing application (608), wherein the conditioned event objects are generated from information contained within the business events at the conditioning application (606); and

receiving events from the event collection application (604), from the conditioning application (606), and from the settlement processing application (608) at an audits and controls application."

(b) According to the auxiliary request, the following paragraph is inserted before the comparing step (1512) in claim 1:

"checking (1504) a redelivered flag of the bundles of like business events, wherein if the redelivered flag of a bundle is TRUE, then the bundle is passed to a dedicated error file and if the redelivered flag of a bundle is FALSE, then the bundle is passed to a retrieve contract clause plan step (1506);"

V. With a communication dated 27 December 2011, the Board issued summons to oral proceedings, scheduled for 8 May 2012, and voiced its preliminary opinion that the feature added from the description seemed to reflect a standard way of handling critical jobs in electronic data processing.

VI. In response to the summons, the appellant reiterated and detailed its argumentation in favour of an inventive step asserting technical aspects implied on the implementation level (letter received 23 March 2012, page 7, paragraph 2).

VII. By a letter received on 2 May 2012, the Board was informed that neither the representative nor the appellant would attend the oral proceedings. The request for oral proceedings was withdrawn, and it was requested that a decision be taken based on the state of the file.

VIII. The Board held oral proceedings in the appellant's absence on 8 May 2012.

Reasons for the decision

1. The application

1.1 The application addresses "a need in the art for tracking and reporting tools that monitor and report commerce and promotional activities conducted across networks, so that entities involved in transactions are not limited in the complexity of the compensation agreements that they can enter into" (A2, paragraph 0004).

The application proposes to meet that need "by providing methods and systems that monitor and report network events that occur across multiple platforms", which "allows entities to enter into increasingly complex compensation agreements that may be performance-based" (A2, paragraph 0005).

Paragraph 0025 of A2 describes an exemplary contract between two provider entities (202, 212, see Figure 2) and a third party entity (store 220) in relation to an end user (208).

1.2 The application does not mention any "network overload" which the statement of grounds of appeal puts forward as a problem to be reduced. The application uses the word "efficiently" only in relation to a commercial goal (A2, paragraph 0005).

Unlike the statement of grounds of appeal, the application does not mention "electronically billing third parties". A2 mentions "billing" only in passing (paragraphs 0034, 0082, 0099), and it does not mention electronic billing.

Main Request

2. Article 56 EPC 1973 - Inventive step

In the light of Article 52(1)(2)(3) EPC, Article 56 EPC 1973 requires an inventive technical contribution. Obvious features and non-technical aspects cannot meet that requirement and, thus, need not be checked any further when applying Article 56 EPC 1973 (see e.g. T 641/00-Two identities/COMVIK, Headnote I, OJ EPO 2003, 352).

2.1 The overall goal of the application is a (potentially innovative) business policy: contractual rules are established among providers and, thus, give network events a (potentially new) commercial meaning. Network events are monitored against that commercial background regardless of the technical platforms on which the providers conduct their business. The potential innovation aims at compensating a plurality of providers based on their combined performances (A2, paragraphs 0005 and 0025), whereas conventional billing schemes compensate each provider for its individual services to an end user (see e.g. D1, page 16, paragraph 3).

However, such a (potential) innovation serves a commercial or administrative rather than any technical purpose and, thus, does not enter into the examination for inventive step.

Therefore, it does not matter whether or not D1 or D2 (referenced by the decision under appeal and the statement of grounds of appeal) discloses any contract between provider entities, i.e. whether or not this type of contract is an innovation by the present application.

2.2 The features of claim 1 reiterate the business policy: network events are collected from all platforms, network events relevant to the (potentially innovative) contracts are identified, and relevant data records are processed and distributed to the providers concerned so that they can enforce their (potentially innovative) contracts.

2.3 Technically speaking, the Board does not consider the proposed data exchange to be efficient. All network events across plural platforms are tracked and reported to a computer (222 in Figure 2 of A2) hosting contractual rules. This is a brute force approach rather than an efficient network usage.

2.4 Claim 1 recites means for carrying out the method steps (in the pre-existing multi-platform environment) in abstract language (means plus function), leaving the implementation to the skilled programmer and relying on conventional software modules, programming techniques and file formats: applications (A2, Figures 6 to 16), JAVA objects (A2, paragraphs 0050, 0065), a session bean (A2, paragraph 0045), HTML and XML files/batches (A2, paragraphs 0021, 0032, 0053...0056), etc.

This implies that the implementation is readily available to the skilled person. (Otherwise, it would not be sufficiently disclosed.) In fact, means for monitoring network events must have been used in the conventional billing schemes which compensate each provider for its individual services to an end user (D1).

2.5 Claim 1 bases the implementation of its business concept on common knowledge and desiderata mapped to the concept:

- a "metering application (602)" is said to monitor network events and identify network events relevant to a contract;

- an "event collection application (604)" is said to create business events out of the identified network events;

- a "bundle producer" is said to create bundles of like business events in relation to a contract clause;

- a "conditioning application (606)" is said to apply valuation information to the business events based on an underlying clause of the contract.

While each of those partial functions may imply a technical aspect on the implementation level, those aspects do not imply an inventive contribution.

Collecting network event data in the computer site where the data is subsequently processed, according to rules stored in that computer site, is a straightforward choice of the person skilled in computerised networks. Network event data have been collected in conventional billing schemes such as D1. The cognitive meaning of data and administrative rules of processing (e.g. bundling data records according to contractual criteria, such as by a clause) do not add any technical character, whereas the underlying database operations are commonplace technical features. This assessment is implicitly acknowledged by the authors of the application who refrained from describing those features in any greater detail.

Applying a "base-value" to a business event and applying "one or more modifiers to the base value" only means that the commercial value of a business event is calculated in one or more stages according to the contractual terms which may be innovative without however implying or requiring any non-obvious technical implementation. The bookkeeping and accounting functions (value counter; settlement processing) recited in the final paragraphs of claim 1 likewise rely on notorious technical means of automation. The appellant has argued that by updating and committing a macro-value counter it is ensured that counts are not double-counted in case a bundle must be reprocessed, eg after a system shut-down (statement of grounds of appeal, page 10, with reference to paragraph 0080 of the description). The Board, however, regards this step as a commonplace security measure that the skilled person would always consider when dealing with sensitive data.

2.6 The Board concludes that the method according to claim 1 of the main request does not involve an inventive step.

Auxiliary Request

3. Article 56 EPC 1973 - Inventive step

3.1 The amendment introduced by the auxiliary request addresses a technical partial problem mentioned in paragraphs 0069 and 0084 of the A2-publication (in relation to Figures 15 and 16): When a server crashes, the bundle of event data processed after the server is recovered might be a duplicate bundle and would thus adversely affect the processing results.

To avoid duplicate processing of a bundle of event data, a "redelivered flag" is used. When the flag indicates that a bundle is delivered a second time ("redelivered") to the comparing step (in which the event data is compared to contract clauses to allow a clause-specific evaluation of the data), then the bundle "is passed to a dedicated error file" so that special attention (e.g. by a human operator) can be paid to that bundle. Otherwise, the bundle is directly processed, i.e. evaluated according to a pertinent contract clause.

3.2 The use of a flag bit represents a notorious standard programming technique for tracking the workflow in electronic data processing. The application does not tell how or where the flag is set, it just relies on common programming knowledge and applies it to event data processing considering the well-known problem of computer crashes.

The Board accepts that the skilled person has such common knowledge regarding the use and purpose of a flag. It is well-known for an automatic process to monitor its own interruptions (see e.g. photocopying machines which resume an unfinished job after a paper jam).

This finding implies at the same time that the use of a workflow flag does not involve an inventive step.

3.3 Nor does the use of a workflow flag produce any non-obvious synergetic technical effect with the other steps of claim 1. The reliability of the automatic evaluation process is increased (i.e. double counts are ruled out) by controlling and checking the flag, regardless of any contractual rule for evaluating the network events that have been monitored.

4. Therefore, the Board judges that neither version of claim 1 (main request, auxiliary request) involves an inventive step (Article 56 EPC 1973).

ORDER

For these reasons it is decided that:

The appeal is dismissed.