T 1512/08 (Financial transaction/VILMOS) 25-10-2011
Download und weitere Informationen:
Set of equipment for the preparation and execution of the financial performance of a business transaction between a seller and a buyer
Summary of Facts and Submissions
I. The appeal is against the Examining Division's decision to refuse European patent application 02807520.8. The refusal was on the grounds of lack of inventive step, because the claimed invention was an obvious automation of a business transaction.
II. On 1 July 2008, the appellant filed a statement setting out his grounds of appeal, which was supplemented by a letter dated 12 November 2008. With the letter, he filed a new main request and a new auxiliary request.
III. The Board arranged for oral proceedings to be held. In a communication accompanying the summons, the Board informed the appellant of its provisional view that the invention, according to both the main and auxiliary requests, amounted to automatic versions of business methods, using straightforward technical means. The Board also drew attention to Figure 4 of D1 (WO 95/12859), which seemed to show the configuration of devices defined in both versions of claim 1.
IV. With his response to the summons, dated 11 August 2011, the appellant filed a second auxiliary request.
V. Oral proceedings were held, as scheduled, on 25 October 2011. At the end of them, the appellant stated his final requests as follows. That the decision under appeal be set aside and that a patent be granted on the basis of the main request or of the first auxiliary request, both filed with the letter dated 12 November 2008, or on the basis of the second auxiliary request, filed with the letter dated 11 August 2011.
VI. Claim 15 according to the main request reads as follows (steps numbered [S1] - [S12] by the Board). Method of performing a financial transaction via the set of equipment according to any of claims 1 to 15, characterised by [S1] - loading buyer identification data (1a) into an own-data register (11a) of the own-data input part-unit (11) of the external buyer communication unit (10); [S2] - loading the seller identification data (2a) into an own-data register (21a) of the own-data input part-unit (21) of the external seller communication unit (20) [S3] generating transaction data (2b) by the external seller communication unit (20); [S4] - creating a message from the seller identification data (2a) and the transaction data (2b) via the data-unification part-unit (23) of the external seller communication unit (20); [S5] - transmitting the message over the directed data channel (30) connecting the external seller communication unit (20) and the external buyer communication unit (10); [S6] - receiving the message and setting up a transaction information (1b) from the message via the seller-data receiving part-unit (12) of the external buyer communication unit (10), the transaction information (1b) comprising data allowing the buyer's (1) financial institution (40, 90) to identify the seller's (2) financial institution (50, 90) and the amount to be transferred; [S7] - creating a message from the buyer identification data (1a) and the transaction information (1b) via the data-unification part-unit (13) of the external buyer communication unit (10); [S8] - transmitting the message from the data-unification part-unit (13) either directly or indirectly over the data-transmission channel (14) to the internal communication unit (41, 91) of the buyer's (1) financial institution (40,90); [S9] - if the buyer's (1) financial institution (40) and the seller's financial institution (50) are not the same, on the basis of the message received by the internal communication unit (41) of the buyer's (1) financial institution (40) transmitting a message to the internal communication unit (51) of the seller's (2) financial institution (50) over the information transmission network (60); [S10] - determining the seller (2) on the basis of the received message at the seller's (2) financial institution (50, 90); and [S11] - transmitting the message received by the seller's financial institution (50,90) via the data-transmission channel (26) to the data-receiving part-unit (25) of the external seller communication unit (20); [S12] - carrying out the financial transaction at the buyer's (1) financial institution (40, 90).
VII. Claim 15 according to the first auxiliary request reads identically up the end of S11, and subsequently reads as follows:
- checking the transaction data (2b) contained in the message at the external seller communication unit (20) and sending a reply message to the seller's (2) financial institution (50, 90) - if the buyer's (1) financial institution (40) and the seller's financial institution (50) are not the same, transmitting the reply message to the buyer's (1) financial institution (40); - carrying out the financial transaction at the buyer's (1) financial institution (40, 90); - sending a confirmation message from the buyer's (1) financial institution (40, 90) to the information-receiving part-unit (15) of the external buyer communication unit (10) over the data transmission channel (14).
VIII. Claim 1 according to the second auxiliary request reads as follows. Method for the preparation and execution of the financial performance of a business transaction between a seller (2) and a buyer (1), characterised by allowing for a real-time sale by; - loading buyer identification data (1a) into an own-data register (11a) of an own-data input part-unit (11) of an external buyer communication unit (10); - loading seller identification data (2a) into an own-data register (21a) of an own-data input part-unit (21) of an external seller communication unit (20); - generating transaction data (2b) by the external seller communication unit (20); - creating a message from the seller identification data (2a) and the transaction data (2b) via the data-unification part-unit (23) of the external seller communication unit (20); - transmitting the message over a directed data channel (30) connecting the external seller communication unit (20) and the external buyer communication unit (10); - receiving the message and setting up a transaction information (1b) from the message via a seller-data receiving part-unit (12) of the external buyer communication unit (10), the transaction information (1b) comprising data allowing the buyer's (1) financial institution (40) to identify the seller's (2) financial institution (50) and the amount to be transferred; - creating a message from the buyer identification data (la) and the transaction information (1b) via a data-unification part-unit (13) of the external buyer communication unit (10); - transmitting the message from the data-unification part-unit (13) either directly or indirectly over a data-transmission channel (14) to an internal communication unit (41) of the buyer's (1) financial institution (40); - transmitting a message from the internal communication unit (41) of the buyers (I) financial institution (40) to the internal communication unit (5 1) of the seller's (2) financial institution (50) over the information transmission network (60) on the basis of the message received by the internal communication unit (41) of the buyer's (1) financial institution (40); - determining the seller (2) on the basis of the received message at the seller's (2) financial institution (50); and - transmitting the message received by the seller's financial institution (50) via the data- transmission channel (26) to the data-receiving part-unit (25) of the external seller communication unit (20); - carrying out the financial transaction at the buyer's (1) financial institution (40).
IX. The appellant's written and oral arguments can be summarized as follows. The invention involved a combination of technical and non-technical features, but the approach taken by T 641/00 "Two identities/COMVIK", OJ EPO 2003, 352 was inappropriate, because it did not reflect how such inventions were really made. The relationship between financially and technically skilled persons was not simply that the former present the latter with a task. Rather, both cooperated to find a solution to a problem which has both financial and technical aspects. In the present case, the correct starting point for the assessment of inventive step was a known method in which the buyer sends his bank details to the seller. Such a system required strong encryption, because of the sensitivity of the data being sent. Thus, the technical aspect of the problem was security, and the technical solution was provided by reversing the flow of data: rather than the buyer providing his information to the seller, it was the seller who provided hers to the buyer. The invention required technical difficulties to be overcome. The buyer's communications device did not run server software, and so it was difficult to send an invoice to it. The invention overcame that by providing the buyer's device with a seller-data receiving part-unit.
The invention provided for real-time sales. The seller was immediately informed that the buyer had requested money to be transferred, and so was assured of payment. That was not the case in the prior art.
Reasons for the Decision
1. The main request, claim 15
1.1 Claim 15 defines a method performed by a number of communication devices. The devices are held by a seller, a buyer, and their respective financial institutions, which may or may not be different.
1.2 The method performed by the communications devices is a business transaction. With the details of the devices left out, it looks like this:
- The seller gives the buyer information that identifies the seller and is sufficient to allow the buyer's financial institution to identify both the seller's financial institution, and the amount of money to be transferred.
- The buyer passes that information to his financial institution, together with some more information identifying the buyer.
- If the financial institutions are different, the buyer's sends a message to the seller's, which passes it on to the seller.
- The money is transferred.
1.3 That transaction is not technical. It could be carried out by people talking to one another. What is important is what information is given to whom.
1.4 The appellant has asserted that the transaction is technical, because it avoids security problems which the prior art has. The Board does not follow that. Problems of security may be technical or not, and the problems the appellant asserts are not. The facts that the seller learns sensitive details about the buyer's bank account, and that sensitive data are transmitted, are not problems of the specific infrastructure, i.e. of how the transmission occurs; they are disadvantages due to the fact that the information is passed at all. That much is apparent from claim 1, which does not define any technical means of transmission beyond what is generically able to carry out the various steps.
1.5 The Board follows the approach set out in T 641/00. The skilled person has the task of technically implementing the business method, and the question of inventive step becomes that of whether the technical means defined in the claim would have been an obvious implementation.
1.6 The Board recognizes that the approach of T 641/00 need not reflect the way in which inventions are really made, but does not see that as invalidating the approach. T 641/00 excludes features with no technical effect from making a contribution to inventive step. Inventive step, in the terms of Article 56 EPC 1973, is a matter of what the fictional "person skilled in the art" would or would not have found obvious. It is not a matter of what a real inventor did or did not do.
1.7 In the Board's view, each of the steps S1 - S12 (see point VI, above) is inherent in any technical implementation of the business transaction. That is, the skilled person would inevitably arrive at S1 - S12 simply by implementing the steps of the business method.
1.7.1 In step S1, buyer identification data is loaded into an own-data register of the own-data input part-unit of the buyer's communication unit. In the business transaction, the buyer must identify himself to his financial institution. The skilled person would have been obliged to provide means for the input and storage of identifying data. Whatever the storing means is, it can be reasonably called an own-data register of the own-data input part unit. Similarly, step S2 must be implemented as claim 1 defines.
1.7.2 Step S3 must be implemented, because the seller's communication unit must identify the financial transaction.
1.7.3 Step S4 calls for the use of a data-unification part-unit. The skilled person would be obliged to provide one, because both the identification data and the transaction data must be sent to the buyer. Similarly, S7 must also involve such a unit.
1.7.4 Step S5 calls for a message to be sent over a directed data channel. Since the message must contain data, and must be sent from the seller's communication unit to the buyer's, this too is inherent in any implementation. Similarly, S8 and S11 could not be implemented other than using a data-transmission channel in each case.
1.7.5 Step S6 calls for the use of a seller data receiving part unit. The communication unit of the buyer's financial institution must have one, because it must receive data from the seller.
1.7.6 Step S9 (which is optional), calls for the user of an information transmission network. Since information must be sent, and since two communications devices are involved, at least a rudimentary network is inevitable.
1.7.7 Steps S10 and S12 does not involve any technical means. They are simply steps in the business method.
1.8 The Board concludes that the technical implementation defined in claim 15 does not involve an inventive step (Article 56 EPC 1973).
1.9 The appellant has argued that technical difficulties were overcome by the invention, which the above analysis ignores: it was difficult to send the invoice to the buyer's communications device, because the latter did not run server software. Dealing with that had involved serious technical difficulties which had taken a long time to resolve.
1.10 As set out in the application, the buyer's device is simply able to receive the message sent to it by the seller's device. The description (page 11, lines 13 - 16 of the application as published) states that the seller's and buyer's devices may be mobile phones, and it does not seem technically difficult to arrange for a message to be sent from one mobile phone to another. In addition, if the Board were to follow the appellant's argument, it would have to conclude that the invention is not sufficiently disclosed (Article 83 EPC), and that claim 15 is missing some essential feature (Article 84 EPC), because the application does not mention any difficulties in sending an invoice to the buyer's device, or describe how they can be overcome.
2. The first auxiliary request, claim 15
2.1 The differences in claim 15, compared with claim 15 according to the main request, are set out at VII, above.
2.2 The additional steps are part of the business transaction, and form part of what the skilled person is required to implement.
2.3 Apart from being able to perform the extra steps, the technical means involved are no different from those discussed under the main request. Thus, all the technical differences follow directly from the skilled person implementing what he has been asked to implement.
2.4 The Board, therefore, considers that the subject matter of claim 15 does not involve an inventive step (Article 56 EPC 1973).
3. The second auxiliary request, claim 1
3.1 As compared with claim 15 according to the main request, claim 1 has been modified in two significant ways. Firstly, it defines the method as allowing for a real-time sale. Secondly, the seller's and buyer's financial institutions are not the same. The other amendments are a result of the fact that there is no device claim to which claim 1 might refer; they make no substantive difference.
3.2 According to the appellant's arguments, the stipulation that the method allows for a real-time sale excludes any possibility of the method being carried out without the use of computers.
3.3 The Board find the term real-time sale somewhat unclear. The appellant stated that if the transaction were carried out using phone calls, and took ten minutes, that would not count as real-time. Ten minutes does not seem, to the Board, an unreasonably long time for a sale. The Board, therefore, does not follow the argument that a computer network is implied. Furthermore, if a computer network were needed to provide for real-time operation, it would be necessary to define it in the claim. Otherwise, an essential feature would be missing.
3.4 Whatever the import of real-time sale, the Board's assessment of inventive step includes the possibility of messages being passed over a computer network.
3.5 The appellant also argued that the limitation to the distinct financial institutions means that the centralised system known from D1 is not relevant. However, the Board's assessment of inventive step does not involve D1, and the limitation to distinct financial institutions does not affect it.
3.6 The Board, therefore, does not see any difference, compared with claim 15 according to the main request, which would lead to a different outcome, and concludes the second auxiliary request is not allowable due to a lack of inventive step (Article 56 EPC 1973).
ORDER
For these reasons it is decided that:
The appeal is dismissed.