T 0693/11 (Brokering Services / LEXINGTON SERVICES LTD) of 7.2.2017

European Case Law Identifier: ECLI:EP:BA:2017:T069311.20170207
Date of decision: 07 February 2017
Case number: T 0693/11
Application number: 02394064.6
IPC class: G06F 17/60
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 293 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: Service request broking system
Applicant name: Lexington Services Limited
Opponent name: -
Board: 3.5.01
Headnote: -
Relevant legal provisions:
European Patent Convention Art 56
Keywords: Inventive step - brokering a service request (no
Inventive step - not technical)
Catchwords:

-

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. This appeal is against the Examining Division's decision to refuse European patent application 02394064.6. That decision was taken on the grounds of lack of clarity (Article 84 EPC) and lack of inventive step (Article 56 EPC).

II. In the statement setting out the 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 new set of claims. The appellant requested oral proceedings, should the Board not allow the appeal.

III. The Board arranged to hold oral proceedings on 7 February 2017, and, with the summons, sent a communication outlining its provisional view of the case: the Examining Division had correctly categorised the invention as a technical implementation of a non-technical method, which lacked inventive step.

IV. By letter dated 31 January 2017, the appellant informed the Board that there would be no attendance at the oral proceedings.

V. Oral proceedings were held as scheduled.

VI. Claim 1 of the sole request, submitted with the statement setting out the grounds of appeal, reads as follows:

A computer implemented method of routing a request for a computer implemented service between computer applications in a computer installation, the method comprising the step of:

sending a service request from a requester application executing on a first computer (11) to a broker application executing on a second computer (12), the service request being made in accordance with a requester-side protocol and a broker interface definition;

characterised in that the service request identifies a service required by the requester application but not a provider application which will provide the service, and whereby on receiving the service request, the broker application performs the steps of:

extracting from the service request the identity of the requester application and the identity of the service required by the requester application;

selecting a provider application to provide the requested service by processing data in a data store (35), said processing comprising:

i. using the identity of the requester application and the identity of the service required to extract data from the data store (35) regarding optimal delivery of the requested service, and

ii. applying pre-set rules stored in the data store (35) to the extracted data to select a specific provider application from a known set of provider applications to provide the requested service,

encoding the service request for the selected provider application in accordance with a provider-side protocol;

sending the encoded service request to the selected provider application executing on a third computer (13) and awaiting a response from the selected provider application, and

upon receiving a response from the selected provider application sending the response in the requester-side protocol to the requester application in fulfillment of the service request.

The appellant's arguments can be summarised as follows.

The invention addressed a useful, real, and industrially applicable issue, which was the computing industry's need for better means of connecting service consumers with service providers. In particular, it addressed problems which arose when interfaces were different or changed. These were technical, rather than business, matters.

Technical considerations were needed for at least:

- the arrangement of first, second, and third computers,

- their programming,

- the implementation of a request for a service without identifying the provider,

- the development of the broker's data store,

- the development of rules regarding optimal delivery,

- adaptation of the broker to identify a requester and a provider,

- extraction of data from the store, and the application of rules to select a service provider,

- encoding in the protocol of the service provider,

- transmission of the encoded request to the service provider,

- transmission of the provider's response to the broker and its encoding according to the requester's protocol,

- transmission of the response to the requester.

The closest prior art was a data processing system with at least two terminals, in which there was a single agreed mechanism of communication, or in which terminals knew how to communicate with the others. An application, in this prior art, would have had to know the structure of a database before being able to use it.

In contrast, the invention allowed heterogenous computers to communicate. To arrive at the invention, the skilled person would have had to recognise that it was not necessary for a provider application to have anything in common with a requester application. That was counter-intuitive. The skilled person would have had to conceive of a broker that could identify a provider, and then to realise such a broker, which would involve doing something to a request. D9, however, showed that the broker was simply a messenger.

Reasons for the Decision

The appellant's right to be heard

1. The Board is not obliged to delay any step by reason only of the appellant's failure to attend oral proceedings (Article 15(3) RPBA). The Board set out its provisional view in the communication sent with the summons. This decision is based upon that provisional view, and the appellant's written arguments. There are, therefore, no additional grounds or evidence that could potentially infringe the appellant's right to be heard (Article 113(1) EPC).

Background

2. The invention is about linking providers of services with consumers of services. Services are provided by computer, but one example of a service is the provision of business information in order to "accelerate business change" (see paragraph 0029 of the published application).

3. A computer network comprises a plurality of nodes. Some of them require services; some of them provide services; some, of course, do both. The invention provides an intermediary between seekers and providers. The advantages of using an intermediary are twofold. Firstly, seekers do not need to know how to find providers. It is enough that the intermediary know that. Seekers need only know how to find the intermediary. Secondly, seekers do not need to adapt their communications to the needs of different possible providers; nor do providers need to adapt to the various possible seekers. Only the intermediary needs to be able to handle different forms of communication.

Inventive Step, Claim 1

4. The application calls the intermediary a broker. It can communicate with a requester using a requester-side protocol and with a provider using a provider-side protocol. The broker translates between the two, as needed. The broker also has the function of choosing a provider to match a requested service.

5. In order to choose a provider, the broker must identify the requester and the service (this information is extracted from the request), obtain information about "optimal" delivery (this information is in a "data store"), and apply a rule to make the selection (rules are also in the "data store"). Once the provider has been chosen, the broker forwards the request (translated as necessary), and passes any response (translated as necessary) back to the requester.

6. The Board agrees with the appellant, that the starting point for the assessment of inventive step is a network with at least two devices, but cannot agree that the devices use an agreed, common protocol. The application points out that devices did not always know how to communicate (see paragraph 0002 of the published application). Nor did service seekers necessarily know where to obtain the services they required. Indeed, if all devices used an agreed protocol and all knew where to find what was needed, there would have been no problem. The Board, therefore, takes as starting point a network in which devices requiring a service and those offering a service do not always know how to find one another and do not share a common interface.

7. The use of a computer network means the invention as a whole is technical. However, the Board finds that the claim defines the invention broadly, and it can be seen as a technical implementation of an underlying non-technical method. The services sought are not restricted to technical services. Nor are the reasons services are sought restricted to technical reasons. The claim covers a business seeking business information for help in taking business decisions (paragraph 0002 of the published application). It is within the ambit of the business person to seek an agent who knows where to find the required information and how to obtain it.

8. The invention, therefore, can be seen as the adaptation of the prior art network so as to implement a non-technical method in which an intermediary agent receives a request and then chooses a provider in consideration of who is making the request, the service requested, and information about "optimal" delivery of the service. The technically skilled person, starting from the network outlined above, has the task of implementing this method. There is an inventive step, if there is something in the technical implementation that would not have been obvious to the technically skilled person.

9. Any implementation requires some device to perform the role of the broker. In order to perform its function, the broker would have to receive requests, identify the requester and the service being requested. In making the identification, there is a choice as to how the broker might make it, but as any request must perforce identify the service and the requester, it would have been obvious to use it.

10. The broker, in any implementation, must also find information about optimal delivery, about possible providers of the requested service, and about how to choose a provider once that information is known. That is a requirement of the non-technical method. In the Board's view, it would have been obvious to provide the broker with a store of this data.

11. Finally, the broker must be able to communicate with the requester and with the chosen service provider. It would have been obvious to provide protocols on the requester and provider sides.

12. In the Board's judgment, therefore, the technical modifications that would produce the claimed invention from the prior art would have been obvious to the technically-skilled person. The claimed subject-matter, therefore, does not involve an inventive step (Article 56 EPC).

Order

For these reasons it is decided that:

Quick Navigation