T 0280/09 (Transaction management/YANTRA) of 11.10.2012

Summary of Facts and Submissions

I. This appeal is against the Examining Division’s decision to refuse European patent application 01930662.0 for lack of inventive step, since the invention as claimed was a straightforward automation of an administrative scheme.

II. In the statement setting out its grounds of appeal, the appellant requested that the Examining Division’s decision be set aside, and that a patent be granted on the basis of a main request, or else one of first to fourth auxiliary requests. A set of claims for each of those requests was submitted with the statement of grounds. The claims of the main request and of the first to third auxiliary requests were identical to those of the correspondingly numbered requests before the Examining Division. The claims of the fourth auxiliary request were identical to those of the fifth auxiliary request before the Examining Division.

The appellant requested oral proceedings, if the Board intended to refuse any of the above-mentioned requests.

In addition, the appellant noted that the Examining Division had "apparently ignored and seemingly did not address the request for correction of page 22," which had been submitted with the letter dated 12 February 2008.

III. The Board arranged oral proceedings for 11 October 2012, and summoned the appellant accordingly. In a communication which accompanied the summons, the Board set out, inter alia, its preliminary view that the subject matter of claim 1, according to all requests, lacked inventive step.

IV. By letter dated 4 October 2012, the appellant informed the Board that it did not intend to be represented at oral proceedings.

V. Oral proceedings were held as scheduled on 11 October 2012, and, after closing the debate, the chairman announced the Board's decision.

VI. Claim 1 according to the main request and to first and second auxiliary requests, reads as follows.

A real-time transaction order management system for enabling a plurality of independent entities to cooperatively process a transaction order, the system comprising:

a central repository containing transaction order attribute and status information;

and

a central repository controller to control real-time access to the central repository by a plurality of transaction participants wherein at least one of the transaction participants is an independent entity relative to at least one other of the transaction participants, wherein:

the central repository controller is configurable to register an independent entity from the plurality of independent entities as a transaction participant, to enable the transaction participant to access the central repository, and to constrain at least one action of the transaction participant;

the central repository controller is configurable to allow at least one of the transaction participants to initiate cooperative processing of a transaction order by depositing transaction order attribute information into the central repository through real-time interaction with the central repository controller via a communications network, and wherein cooperative processing of the transaction order includes accessing and modifying at least one transaction order attribute of the transaction order using remote real-time interaction with the central repository controller via the communications network.

VII. Claim 1 according to the third auxiliary request reads as follows.

A transaction order management system comprising:

a computer in communication with a plurality of transaction order participants via a communications network, the computer to store attribute and status information of a transaction, to store a first profile of at least one of the plurality of transaction order participants at a database, and to select a transaction order participant from the plurality of transaction order participants to contribute to completion of the transaction, wherein the selection is based at least partially on the first profile;

wherein the computer comprises a controller to control access to contents of the database and to constrain at least one action of the plurality of transaction order participants, the controller accessible via the communications network; and

a market interface to compare the first profile to a second profile of an end-user, the second profile provided to the market interface by the end-user, to determine one or more transactions available to the end-user, and to enable the end-user to perform the one or more transactions.

VIII. Claim 1 according to the fourth auxiliary request reads as follows.

A transaction order management system (100) comprising

at least one transaction order participant (160) for contributing to the completion of a transaction supported by the system, the at least one transaction order participant being in communication with a communications network;

a central repository computer (102) in communication with said network, the central repository computer storing transaction order attribute and status information in a central repository (272) , and registering a respective profile for each of the at least one transaction order participant (160) which describes the participant in sufficient detail to enable its selection for participation in the processing of transactions;

the central repository computer (102) having a central repository controller (270) for controlling access to the contents of the central repository (272), the central repository controller (270) being accessible through remote real-time interaction on demand via the communications network; and

a market interface (120) in communication with said central repository controller (270) via said network; wherein

on the basis of a comparison between the at least one participant profile held in the central repository (272) and an end-user profile, which end-user profile indicates the location of the end-user and which is provided to the market interface by the end-user, the market interface (120) is arranged to determine which transactions are available to the end-user, the market interface (120) being configured to present only these available transactions to the end-user.

IX. The appellant’s arguments as relevant to the present decision, can be summarised as follows.

The application should not have been refused for lack of inventive step, before a search had been carried out. In particular, according to T 1242/04 at 8.4, a search is necessary unless there is a fundamental lack of clarity or an absence of any technical character whatsoever. The invention did not lack technical character and there was no fundamental lack of clarity.

The invention exhibited the technical effect of integrating "disparate methods and systems for processing data into one over-arching system which is self-consistent and self-compatible," and this was not obvious from the notorious prior art. Using the invention, although the different nodes may use different methods and systems, the over-arching system allowed them to interact in real time.

The invention was applicable to business, but was not limited to business. Inventive step, therefore, should not be judged on the basis that the invention was an implementation of a business method.

Reasons for the Decision

1. The main request, and the first and second auxiliary requests share the same claim 1. The Board is of the opinion that its subject matter does not involve an inventive step (Article 56 EPC 1973). As a consequence, none of these requests is allowable.

1.1 Claim 1 defines a "real-time transaction order management system" which comprises a "central repository," and a "central repository controller," the latter allowing a participant to interact with the former via a "communications network." The repository is a collection of information ("transaction order attribute and status information"). The controller can be configured to register participants, control access to the repository, and to constrain some action; it can also be configured to allow a participant to access and modify an attribute in the repository.

1.2 Neither the repository nor the controller is necessarily technical. The central repository is a collection of information, and the latter may be a person who registers participants and enforces some constraint. It should be noted that the constraint is not further defined, and may be something as simple, and non-technical, as a shopkeeper agreeing to provide an item only if the buyer pays.

1.3 It is arguable that the controller must be technical, because the claim defines it as "configurable." As will become apparent, the outcome would not be affected by that.

1.4 The invention defined in claim 1 has a mixture of technical and non-technical features. Only the technical features can be taken into account when assessing inventive step. In the present case, the Board sees the technical problem as one of providing a technical tool to allow a participant to register and initiate "cooperative processing of a transaction", while enforcing some constraint. The technical solution is to provide a communications network. In the Board's judgment, the use of a communications network would have been obvious, because some means of communication is necessary to the underlying non-technical system.

1.5 Even if the controller were seen as necessarily technical, on the basis of its being "configurable", the invention would still have been obvious. The technical solution to the problem of providing a technical tool which allows a participant to register and initiate cooperative processing of a transaction would have been the provision of a communication network and of a machine to control registration and initiation. Suitable machines were known. A general-purpose computer would have been one obvious choice.

1.6 The Board is not persuaded by the appellant's arguments. It is certainly true that the system defined by claim 1 is not limited to business systems. What is important, however, is that the underlying systems of managing transactions is not limited to technical management or technical transactions. It is, therefore, legitimate to consider the invention as a technical tool which facilitates the underlying non-technical system. It also seems to be true that the invention provides an “over-arching system,” but the provision of such a system, in the context of non-technical subsystems, has no technical implications. The argument that the invention works in real time also refers to a non-technical issue. To make a computer system operate in real time may involve special measures, which are technical, but neither the claim, nor the application as a whole, sets out any such measures. As set out in the claim, real-time processing need be nothing more than starting to process an order as soon as it has been made, and there is nothing technical in that.

1.7 The subject matter of claim 1, therefore, in the light of a network of general-purpose computers, does not involve an inventive step. It is beyond dispute that these were known. According to T 1242/04, "Provision of product-specific data/MAN, OJ EPO 2007, 421 (see point 9.2), an application can be refused for lack of inventive step, without documented prior art, if the objection is based on prior art which is "notorious." That is the case here, and so an "additional" search is not necessary.

2. Claim 1 according to the third auxiliary request does not refer to a central repository, but its role is taken by a database. Otherwise, the situation is no different from that of the main request. In the Board’s judgment, databases were as "notorious" as communications networks, or networks of computers. Therefore, although there are more technical features, the third auxiliary request is no more allowable than the main request.

3. Claim 1 according to the fourth auxiliary request, as compared with the main request, has been amended in a number of ways: the central repository is now a computer, and there is a "market interface" which, on the basis of an "end-user profile," determines which transactions are available, and which presents only those. The central repository computer is clearly technical, but is no less "notorious" than the database in the third auxiliary request. "Market interface" seems to be no more than a renaming of the controller. The presentation of only those transactions which are available is not technical. It might correspond to a seller showing a customer with only €100 only items which cost no more than €100. The Board concludes that the fourth auxiliary request is not allowable.

4. Since a patent cannot be granted, the request for correction of page 22 is redundant.

Order

For these reasons it is decided that:

The appeal is dismissed.