T 0401/10 (Restricted trading/SAP) 10-07-2013
Download und weitere Informationen:
RESTRICTED PARTY SCREENING
Summary of Facts and Submissions
I. This appeal is against the decision, taken by the Examining Division, to refuse European patent application 03789357.5, without a search having been carried out. The Examining Division found the main request unallowable because of a lack of inventive step, and declined to admit an auxiliary request.
II. With the statement setting out its grounds of appeal, submitted by letter dated 22 January 2010, the appellant maintained the main and auxiliary requests considered by the Examining Division, and submitted a new, second auxiliary request. It also requested a further opportunity to amend, if the Board were not inclined to allow the main and two auxiliary requests; and that oral proceedings be held, if the Board intended to reject the main and auxiliary requests, and the request for a further opportunity to amend.
III. Oral proceedings were arranged, and a summons sent to the appellant. The Board set out its preliminary view of the case in an annex.
IV. With a letter of reply, dated 3 June 2013, the appellant submitted a main and an auxiliary request with the following conditional formulation:
Provided that a new request is admitted into the procedure, the currently valid requests are replaced by the new request for the issuance of a communication under Rule 71(3) EPC on the basis of [the documents submitted as main and auxiliary requests].
Provided that a new request is admitted into the procedure, the currently valid requests are replaced by the new request for the issuance of a communication under Rule 71(3) EPC on the basis of [the documents submitted as main and auxiliary requests].
The main request submitted with this letter was identical to the second auxiliary request submitted with the statement setting out its grounds of appeal. The auxiliary request was new.
Claim 1 according to the main request read as follows:
A computer-implemented method of blocking workflow transactions in an enterprise resource planning system (12) residing on one or more servers computers, the method comprising:
monitoring, by a trading party monitor module (80) residing on the same server computer as a part of the enterprise resource planning system (12), the work- flow transactions of the enterprise resource planning system (12) for party identifying information (14) of a potential trading party;
receiving, by a party identification normalizer (84) being part of the trading party monitor module (80), of the identifying information (14);
normalizing, by the party identification normalizer (84), at least a portion of the received identifying information (14) to generate a normalized identifier (16) for the potential trading party as a normalized string, wherein normalizing comprises following a number of conversion steps to reduce the information to be normalized according to a set of conversion rules;
comparing, by the party identification normalizer (84), the normalized identifier (16) with one or more other normalized identifiers (22) corresponding to parties with whom trade should be restricted;
generating, by a party match generator (86, 90) being part of the trading party monitor module (80), a match signal if the normalized identifier (16) for the potential trading party matches one of the normalized identifiers (22) corresponding to parties with whom trade should be restricted based on the comparison; and
placing, by the enterprise resource planning system (12), a block indicator on the workflow transaction based on the match signal to selectively block the workflow transaction with the potential trading party.
Claim 1 according to the auxiliary request read identically, except for the steps of normalizing and comparing , as shown by the added emphasis:
normalizing, by the party identification normalizer (84), at least a portion of the received identifying information (14)to generate a normalized identifier (16) for the potential trading party as a normalized string, wherein normalizing comprises following a number of conversion steps to reduce the information to be normalized to a lowest common denominator according to a set of conversion rules so as to reduce the variability among various pieces of information;
comparing, by the party identification normalizer (84), the normalized identifier (16) with one or more other normalized identifiers (22) corresponding to parties with whom trade should be restricted, the parties being listed in one or more restricted parties sets (20) that correspond to a restricted party list, wherein the comparison is conducted by using the normalized identifier (16) as a search key;
V. By a further letter, dated 11 June 2013, the appellant informed the Board that it would not attend the oral proceedings.
VI. Oral proceedings were held as scheduled.
VII. The appellant's arguments can be summarized as follows.
An unsearched application should not be refused for lack of inventive step, as long as at least one technical feature is not "notorious". In the present case, at least the placing of the "trading party monitor module" on the same server as part of the enterprise resource planning system was technical and not notorious (both requests). In the auxiliary request, the use of the "normalized identifier" as a search key was also technical and not notorious. An additional search was, therefore, necessary.
Those non-notorious technical features were not part of a general purpose computer system, and the skilled person, starting from such a system, would have had no incentive to provide them.
The method according to the invention was implemented on a computer, and all its features were technical. The entities that carried out the steps of the method were technical means because they were part of the computer system, and the steps they carried out were technical by virtue of the technical means.
A "transaction" in the sense of claim 1 (both requests) was technical, and must be understood as an operation that allowed a user to make changes to a database. By blocking restricted transactions, a technical effect was obtained. A transaction involved access to a database, storage, data processing, and communication operations. When a transaction was blocked, none of that took place.
The Examining Division, in assessing inventive step, took the starting point as a general purpose computer. Such a computer did not hint at the technical steps of the method according to the invention. In particular, it did not hint at normalization, at the generation of a match signal, or at the blocking of restricted transactions; nor did it provide any motivation to consider avoiding the unnecessary use of computer resources.
The Examining Division's argument that the invention amounted to an automation of an administrative scheme was incorrect. Even if a method of information processing could be performed by passing a piece of paper between entities, that did not mean the method was not technical. If it did, then no telecommunication method would be patentable.
Reasons for the Decision
1. The Board admits the main and auxiliary requests, filed with the letter dated 3 June 2013. Accordingly, only those requests need be considered.
Introduction
2. The invention concerns trading, and deals with the problem of identifying parties with whom business should not be conducted. That may be because of legal restrictions, but it could be for any reason. The aim of the invention is to flag transactions that involve a party with whom trade is restricted.
3. To that end, a module monitors transactions and looks for party identifiers. If any are found, they are put into some normal form, and compared with an index of restricted parties which are in the same normal form. If there is a match, the transaction is flagged.
Issues of technicality
4. The approach taken by the Board in T 0641/00, Two identities/COMVIK, OJ 2003, 352 is now well-established. When an invention consists of a mixture of technical and non-technical features, then the assessment of inventive step proceeds by distinguishing those features which contribute to the technical character of the invention from those that do not. Only the former count towards inventive step. Furthermore, the features that do not contribute to the technical character of the invention may appear as (part of) the formulation of the technical problem. In particular, one legitimate approach to the assessment of inventive step can be to consider the skilled person faced with the task of automating a non-technical method.
5. That was the approach taken by the Examining Division with regard to claim 1 according to the main request before them. The appellant contests that at all points. It is, therefore, necessary to consider how, if at all, the various features contribute to the technical character of the invention.
6. The first issue is the appellant's contention that a "transaction" is technical per se, because it means an operation in a database. Claim 1 according to both requests refers to "workflow transactions in an enterprise resource planning system." That system resides "on one or more server computers." The computers form the technical infrastructure that supports the resource planning system, but resource planning, and systems of doing it, are not inherently technical. It is possible to make plans mentally, or using pencil and paper. In the latter case, the pencil and paper are the technical infrastructure. In the Board's judgment, resource planning is an administrative or business matter. That is not changed if some technical assistance is used.
7. In the present case, a "workflow transaction" is something that may involve a party with whom trade is restricted. It might be a proposal to buy a particular product at a particular time from a particular vendor. According to the two versions of claim 1, it resides on one or more server computers. It is stored in a technical manner, but remains an administrative or business transaction.
8. The second issue is the appellant's argument regarding passing messages on a piece of paper. The argument is that, if a method that could be implemented by passing such messages is, by virtue of that fact, non-technical, then no telecommunication method would be patentable. The Board does not accept that. An example might be a comparison of post and telegraph. Any message sent by telegraph could be sent by post. If the appellant's argument were correct, there would be, or would have been, no valid patents for telegraphy. In the Board's view, telegraphy involved many technological issues: the design of cables, the generation of suitable currents, the encoding of information, the detection of signals, the coupling of one circuit with another are just a few examples. Each of those presented a technical challenge and a solution would have supported a technical effect on which a claim of inventive step could be founded. Nevertheless, a method of organising a dinner party, characterised by sending invitations and receiving replies by telegraphy would engage no technical issues other than how to send messages by telegraphy, a problem already solved by the telegraph system itself. In the Board's view, the fact that a method could be implemented by passing messages on pieces of paper might well have consequences for patentability, but in no way precludes patentability when technical issues are engaged.
9. The third issue to be considered is the appellant's argument that every step in the claimed method (both requests) is technical, because they are all carried out by technical means. That is correct. Nevertheless, a method step may be technical and, at the same time, implement a non-technical step. An example might be communication of the word "yes." It could be accomplished non-technically, by speaking or by sign language. It could be done technically, by writing it on a piece of paper, sending it by telegraph, or transmitting it over a computer network. All the technical implementations are technical steps, but they all serve the non-technical end of communicating the word "yes."
10. The Board sees the following basic method as underlying the invention. It applies to both requests. There are some additional points to be made with respect to the auxiliary request, and these will be dealt with separately.
Workflow transactions are monitored.
Any party identifiers are found.
Any found party identifier is put into some normal form.
The normalized party identifiers are compared with a list of restricted parties, also in the same normal form.
Indicating a match, if a match is found.
Indicating that a transaction should be blocked, if a match has been indicated.
11. The appellant has argued that normalization is technical. Claim 1 (both requests) does not specify any particular manner of normalization, and the Board's view is that it includes the writing of a name using only upper case letters, or in the form "surname, given name." Indeed, the concept of normalization is so broad, that it covers even the use of correct, rather than incorrect, spelling. There is, therefore, no technical implication in the term "normalization" in the present context.
12. Having rejected the appellant's arguments regarding technicality, the Board concludes that there is indeed a non-technical method underlying the invention defined in the two pending versions of claim 1, and that it is legitimate to consider inventive step from the point of view of the automation of that method using a conventional computer system.
The main request
The main request
13. The Board must decide whether it would have been obvious to the skilled person, who had the task of automating the method outlined above, to provide the features defined by claim 1.
14. In order to arrive at the claimed invention, the skilled person would have to implement the invention on a computer, provide a "trading party monitor module" on the same server as (part of) the enterprise planning system, a "party identification normalizer," and a "party match generator." She would also have to arrange for the enterprise resource planning system to "selectively block the workflow transaction," when that is called for. When implementing the normalization, she would have to do it by "following a number of conversion steps to reduce the information to be normalized according to a set of conversion rules."
15. Computers are good at storing data, processing it, and comparing it. To implement the method on a computer would have amounted to no more than using a computer to do what computers were good at. That much would have been obvious.
16. The non-technical method requires the monitoring of workflow transactions and the finding of any party identifiers. Any device or program module that does that can be termed a "trading party monitor module." The skilled person, would, therefore, have no choice but to provide such a module. She would, however, face a choice as to where to position it. Since it has to interact with the enterprise resource planning system, using one of its servers would have been one of the obvious choices.
17. The non-technical method requires the normalization of party identifiers. Any device which does that can be called a "party identification normalizer." According to claim 1, it must receive the party-identifying information, but that is implicit in the method. It must also be part of the monitoring module, but that is only a matter of nomenclature. If one regards the normalization and comparison as part of the monitoring, then, in the technical implementation, it will be part of the monitor module. The normalizer must make the comparison, but that, again, is a matter of nomenclature. Finally, any normalizer that works must take an identifier and put it into some normal form. That counts as a conversion step in accordance with some conversion rule. Presumably, also, once an identifier has been normalized, there is then less information (fewer identifiers) in need of normalization. In that sense, there is a reduction in the information to be normalized. The Board, therefore, considers that any technical implementation of the normalization and comparison steps must involve a "party identification normalizer" as defined in claim 1.
18. The non-technical method requires that a comparison be made, and that matches be somehow flagged. Whatever does that can be called a "party match generator."
19. Finally, the non-technical method requires that, if a match is found, some indication be given that the corresponding trade should not take place. The skilled person seems to have a choice as to how that is done, but the Board considers that putting the indication in the enterprise resource planning system would be an obvious one. It would have the evident advantage that the planning system could take account of it.
20. In summary, the skilled person has little choice about the provision of the features defined in claim 1, and where there is a choice, it would have been obvious to choose what claim 1 defines. The Board concludes that the main request cannot be allowed, because the subject matter defined by claim 1 does not involve an inventive step (Article 56 EPC 1973) over a general-purpose computer system. Since such a system is notoriously known, no search was necessary.
The auxiliary request
The auxiliary request
21. Claim 1 in accordance with this request differs in two ways. The normalization involves reduction to a "lowest common denominator," and the comparison involves using the normalized party identifier as a "search key."
22. The Board considers the term "lowest common denominator," as it is used here, to be unclear. It is a mathematical term that relates to pairs of rational numbers, but here there is no mathematical context, and no pair of entities to which the "denominator" would be "common." However, whatever meaning the term has, the Board can see nothing technical in it, because it concerns the meaning of the information. As such, it could not be a feature that contributes to inventive step.
23. The use of the normalized party identifier as a search key amounts to no more than looking at the list of restricted parties to see whether the normalized party identifier appears it in. That, too, is not a technical matter: it is a straightforward way of consulting an index, as a librarian might do. The Board does note, however, that one obvious way of storing a list of restricted parties would have been in a database, in which case searching the database for the normalized party identifier would have been the most straightforward approach.
24. In summary, the Board considers that the method defined by claim 1 does not involve an inventive step for the reasons already given with respect to the main request. As a result, the auxiliary request cannot be allowed.
Order
For these reasons it is decided that:
The appeal is dismissed.