T 0144/11 (Security rating System / SATO MICHIHIRO) 14-08-2018
Download and more information:
Security rating system
Inventive step - objective calculation of the safety rating of an investment (no
Inventive step - part of business requirement)
Inventive step - including count of transmissions of rating information in the rating (no
Inventive step - obvious implementation of business requirement)
Inventive step - technical prejudice in the art (no)
A problem of the type "implement [the business requirement]" will normally never lead to an allowable claim. Either the implementation will be obvious or have no technical effect, or if not, the implementation will have a technical effect that can be used to reformulate the problem essentially to "achieve [the effect of the implementation]".
However, the implementation-type problem is just a starting point that might have to be modified when the implementation is considered. It helps when a technical problem is not apparent at the outset. Examining the business requirements carefully and correctly establishing what is to be implemented ensures that all technical matter arising from the idea of the invention and its implementation is taken into account for inventive step (see point 2.7).
I. This appeal is against the decision of the examining division refusing European patent application No. 03012362.4 pursuant to Article 97(2) EPC on the ground of lack of inventive step (Article 56 EPC).
The examining division found that the invention did not solve a problem in a technical field. The technical features of the mixed-type invention were considered to be part of common general knowledge, but also readily apparent from the prior art, for example, US 2002/023048 (D2), WO 01/80539 (D3) or WO 02/09003 (D4).
II. In the statement setting out the grounds of appeal, dated 24 December 2010, 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 a first to fourth auxiliary request, filed therewith.
The appellant also requested oral proceedings on an auxiliary basis.
III. In a communication, the Board's preliminary view was that the examining division was correct to consider that the invention did not involve an inventive step.
IV. In a response, dated 18 August 2017, the appellant filed a fifth and sixth auxiliary request and presented arguments why the invention solved a technical problem and was inventive over the prior art cited.
V. In the annex to the summons to oral proceedings, the Board confirmed its preliminary view.
VI. The oral proceedings were held on 14 August 2018 during the course of which the appellant confirmed its requests. At the end of the oral proceedings the Chairman announced the Board's decision.
VII. The main request contains corresponding independent system and method claims, claim 1 reading as follows:
"1. A security rating system comprising a security rating server (100d) and a security rating client (200b) connected with said security rating server (l00d) via a communication network (300), wherein said security rating server (100d) comprises:
a security information table storing means (171d) configured for storing a security information table that records security elements, i.e., data that constitute a security measure, for each security;
a rating value calculating means (173d) configured for calculating a sum of rating contribution values for each security information table using a rating contribution value table, which stores contributing values for rating of securities belonging to said security elements as rating contribution values, and for recording said sum of rating contribution values thus calculated as a rating value in said security information table;
a security information table transmitting means (174d) configured for transmitting said security information table to said security rating client (200b) when a security information table transmission request is received from said security rating client (200b); and
a transmission counting means (177d) configured for incrementing by one the number of transmissions, which is a security element recorded on said security information table, each time when said security information table is transmitted to said security rating client (200b) by said security information table transmitting means, wherein
said security rating client (200b) comprises:
a security information table transmission request transmitting means configured for transmitting said security information table transmission request to said security rating server (100d); and
a security information table receiving means configured for receiving said security information table from said security rating server (100d)."
VIII. Claim 1 of the first auxiliary request adds to claim 1 of the main request (and correspondingly to the independent method claim) a "managing client", reading as follows:
"a managing client (400) connected with said security rating server (100d) via said communication network (300), wherein said security rating server (100d) comprises:
a rating contribution value table updating means (175d) configured for updating said rating contribution value to be recorded on said rating contribution value table when a rating contribution value table updating request is received from said manager (400), and wherein
said managing client (400) comprises a rating contribution value table updating request transmitting means configured for transmitting said rating contribution value table updating request to said security rating server (100d)."
IX. Claim 1 of the second auxiliary request further adds to claim 1 of the first auxiliary request (and correspondingly to the independent method claim):
"wherein said security rating server (100d) further comprises: a verifying means configured to make the rating contribution value table inaccessible for any security rating client (200b) except for the managing client (400)."
X. The third auxiliary request is equivalent to the second auxiliary request with the system claims having been deleted.
XI. Claim 1 of the fourth auxiliary request adds to the method claim of the third auxiliary request:
an enumeration of security elements in the first feature, reading "[security elements] comprising at least one of the security elements of the group title of security, face value, contents of public work, planer, executor, guarantor, redemption limit, interest rate, guaranteed limit, dividend and number of issues";
and to the end of the rating value calculating step "wherein the rating contribution values being equal for equal security elements for all securities".
XII. Claim 1 of the fifth auxiliary request (which has no method claims) is based on claim 1 of the second auxiliary request, with the enumeration of security elements as in the fourth auxiliary request and a reworded "verifying means", reading as follows:
"a verifying means configured for verifying a client attempting to have an access to the rating contribution value table so that the rating contribution value table is inaccessible except by the managing client (400)."
XIII. Claim 1 of the sixth auxiliary request is a combination of claims 1 and 2 of the fifth auxiliary request and the addition at the end of:
"wherein said security rating server (100d) further comprises:
a comparative security rating value information generating and transmitting means (176d) configured for generating comparative security rating value information comparing said security rating values for a plurality of securities recorded on their respective security information tables and for transmitting it to said security rating client (200b) when a comparative security rating value information transmission request is received from said security rating client (200b), and
said security rating client (200b) further comprises:
a comparative security rating value information transmission request transmitting means configured for transmitting said comparative security rating value information transmission request to said security rating server (100d); and
a comparative security rating value information receiving means configured for receiving said comparative security rating value information from said security rating server (100d)."
XIV. The appellant essentially argued as follows:
The present invention enabled a safe and reliable security rating system which automatically provided investors with objectively calculated security rating values. This was technical.
The popularity of a security was taken into account by counting the transmissions of rating values to investors. The counting of transmissions was output twice to an investor, once as part of the sum of rating contribution values, and secondly as one of the security elements of a security. This addressed a performance and security issue, which would not be found in markets of financial products with a high liquidity.
The counting of transmissions was inherently technical. It was an idea which the technical person skilled in the art would come up with when asked by a business person to propose a good rating of securities.
1. Background
1.1 The invention concerns assessing the credibility of securities, e.g. bonds, and calculates rating values for them. The rating values provide a ground for investors to judge the safety of a bond prior to investments on certainties of redemptions of principals and payments of interests of the bonds, see paragraphs [0003] and [0004] of the published application.
1.2 The general idea of the invention is to provide an "objective calculation" of these rating values which means that the rating of a security is done in relation to the rating of other securities, see paragraph [0006]. According to paragraphs [0007] and [0077], all securities that share a common aspect, called "security element", for example a common guarantor such as the government of Japan, are provided with an equal "rating contribution value".
The overall rating value is calculated by summing the rating contribution values of the different security elements, e.g. guarantor, executor, face value, interest rate, etc. [0062] to [0066].
The number of times that a client has queried a particular security is provided as an additional security element [0135]. This takes the popularity of the security into account [0142].
2. Article 56 EPC - Deriving the technical problem
2.1 This case, like many in this field, is all about drawing the line between technical and non-technical subject-matter. This is of critical importance since as stated in decision T 641/00 (COMVIK), only features with technical character can support the presence of inventive step. As a result, non-technical aspects of the invention may legitimately appear in the formulation of the problem as part of the framework of the technical problem that is to be solved, in particular as a constraint that has to be met.
2.2 Recent decision T 1463/11 (Universal Merchant Platform / CardinalCommerce) considered this framework in the form of business requirements that a "notional business person" could give to the technical skilled person to implement. The decision stated at point 13 that the business requirements should not contain any technical aspects.
2.3 The invention in that case was about authenticating consumer-merchant transactions with financial entities using different authentication protocols. The idea of the invention was to move the software plug-ins that authenticate transactions from merchants' individual servers to a separate centralised transaction processing service provider server. The examining division had considered that the invention amounted to outsourcing the authentication of a commercial transaction to a third-party, which was a business activity. The technical problem was thus how to implement this, the use of a separate server being obvious.
2.4 The Board considered that this abstraction overlooked technical considerations that were inherent in the use of plug-ins and servers. As a result, the concept of centralisation could not be included in the problem as a business requirement.
2.5 During the course of the present appeal, the appellant alleged that T 1463/11 did not actually state the technical problem that centralising the authentication plug-ins in a separate server solved. However, the present Board considers that it was implicit from the statements in points 21 and 23 of this decision that the problem was to simplify software maintenance at the merchant servers.
2.6 Removing the concept of "centralising" from the business requirement meant that it became part of the solution. The technical problem changed from implementing the business requirement to achieving the effect of the centralisation, namely to simplify software maintenance at the merchant servers. The Board went on to find that solution inventive. This case demonstrated that a careful analysis of which parts of a claimed feature involve a business requirement can help to resolve the grey area between technical and non-technical features.
2.7 A corollary of this approach, and what is seen in practice, is that a problem of the type "implement [the business requirement]" will normally never lead to an allowable claim. Either the implementation will be obvious or have no technical effect, or if not, the implementation will have a technical effect that can be used to reformulate the problem essentially to "achieve [the effect of the implementation]". However, the implementation-type problem is just a starting point that might have to be modified when the implementation is considered. It helps when a technical problem is not apparent at the outset. Examining the business requirements like that and correctly establishing what is to be implemented ensures that all technical matter arising from the idea of the invention and its implementation is taken into account for inventive step.
2.8 In the Board's view, another constraint is that the technical skilled person must receive a complete description of the business requirement, or else he would not be able to implement it and he should not be providing any input in the non-technical domain.
3. Article 56 EPC - Main request
3.1 The Board agrees with the examining division's finding and it was not disputed that the present invention generally addresses a commercial problem which is to provide reliable ratings for investors to decide about investments in securities.
3.2 The rating of securities, the recording of security elements constituting a security, the calculation of contribution values, as well as the determination of the popularity of security ratings are fundamentally non-technical, being essentially aspects of either a business method, a mathematical method or both.
3.3 Claim 1 contains the above-mentioned ideas of summing the rating contribution values of the security elements, including the popularity of the security as measured by the number of transmissions of the security information to clients. The security elements, the rating contribution values, and the overall rating are all stored in tables.
3.4 The appellant formulated the problem to be solved as "determining reliable ratings for securities". In the Board's judgement this problem is too broad. It omits the details of the "objective calculation" of rating values of securities, which aims to rate a security in relation to other securities, see paragraph [0006]. Thus, according to paragraph [0007], an equal rating contribution value is provided to all securities that share a common security element. When more than two national or local governments or public institutions, etc., become planners, the rating contribution values provided by them is summed up [0060] to [0066].
3.5 These details of the "objective calculation" are part of the overall business concept which the invention addresses and must be given to the technical skilled person as part of the requirements specification. Indeed if this were not the case, the technical skilled person would have to devise them in order to provide a solution, which is, as stated above, not his task.
3.6 The appellant also argued that counting the number of transmissions was inherently technical and was an idea which the technical person skilled in the art would come up with when asked by a business person to propose a good rating of securities. Counting transmissions does indeed sound technical, but in the Board's view the question is why would the technical skilled person come up with the idea of counting transmissions. It can only come from the above-mentioned requirement to reflect the popularity of the security in its rating value.
3.7 Reflecting the popularity in the rating value of the securities is also a business-related idea. Within a business context of investors who seek the most accurate and reliable information prior to making investments, see paragraph [0003], the most credible rating of securities is fundamental. According to paragraph [0142], this is one which reflects the popularity of these securities among the users.
3.8 The popularity is measured by counting the number of transmissions. The observation that the "transmission of data" between a client and server is technical - which is undoubted - does not necessarily imply that the mere idea of "counting" these transmissions is also technical. The question is whether the idea of counting is on the business side of the line or on the side of the technical implementation.
3.9 The Board judges that counting is rather part of the business specification. The more popular a security is, the higher is the number of investors interested in receiving information about it. Within a business setting, this would amount to counting the number of telephone calls, the number of emails sent, the number of letters, votes received, etc. All these thoughts are made by the notional business person.
3.10 The appellant argued that it was not inevitable to count the number of interested investors; polls or advertisements could be used. However, this is irrelevant since the idea is part of the business requirements. In any case, the ratings in such liquid markets are expected to be done in real-time to be reliable. Polls and advertisement campaigns are certainly unsuitable.
3.11 Accordingly, the Board concludes that it is part of the business concept to count the number of investors interested in the security information tables. The implementation by counting the number of transmissions and choice of technology to do this are then part of the technical solution.
3.12 Finally, the establishment of tables for representing and storing the information and calculated values are also part of the business considerations. They are structural representations of financial information.
3.13 In the Board's view, technical considerations only come into play when implementing the above business concepts. The technical person skilled in the art is given the requirement of performing the given objective calculation of rating values of securities.
3.14 The Board agrees with the examining division that the sole clearly technical features are the server and clients which exchange data over a computer network. These features are notorious. By way of example, D3, Figure 1, illustrates a client/server-based real-time online trading system with a central database where investors connect via trading client computers to a server for accessing, submitting and processing trading orders, filtering and messaging preferences, credit limits and/or historic trading data, current holdings data and generating and communicating messages, see page 14, lines 7 to 12. D3 addresses the problem of "aggregat[ing] a critical mass of trade prices to provide accurate, real time estimates of a security's fair value and make these estimates widely available by publishing them...", see page 6, lines 26 to 28, which is close to that of the present application.
3.15 The Board also agrees with the examining division that the skilled person would have no difficulty in implementing the invention on such a conventional client and server system. All major functions of the business concept are implemented as modules on a server, as shown for example in Figure 3 of the application, which is in connection with clients, see for example Figure 1. It is clear from the application that these are standard servers and clients, see for example paragraphs [0049] and [0076].
3.16 Faced with the problem of counting the number of interested investors, the Board judges that it would be self-evident to consider the number of client requests for information. This is equivalent to counting the number of transmissions of a security information table to a client as claimed. Thus, the counting and storing of data as part of the implementation does not involve an inventive step.
3.17 Claim 1 of the main request therefore does not involve an inventive step, because it amounts to an obvious implementation of a business concept using a notorious client/server system.
4. First auxiliary request
4.1 The first auxiliary requests adds a "managing client" and at the server an "updating means" to claim 1. Both are technical features, but are a direct consequence of the business specification and therefore do not involve an inventive step.
4.2 A "managing client" is a client computer which is used by a manager, a person managing securities, and which is able to send updates of rating contribution values to the server. This is nothing more than a transmission of data. The application explains in paragraph [0100] that it is intended to reflect business trends and the popularity of securities in international situations in the rating contribution values of security elements. If the popularity of a security is increasing in a local market, this should be reflected. This means that the rating contribution values need to be updated in the rating contribution table on the server. These updates are done by a person who is a responsible manager for these tables, as explained in paragraphs [0088] and [0089].
4.3 The technical problem facing the person skilled in the art is how to enable the manager in such a geographically dispersed situation to update rating contribution tables when he is remote from the security rating server.
4.4 An obvious solution is to provide a managing client with updating request transmitting means which is connected to the security rating server with corresponding updating means as claimed. According to the application, paragraph [0098], the managing client is not required to have any specific technical structure. It is only required to be capable of transmitting rating contribution value table update requests to a security rating server.
4.5 The appellant argued that it would be a technical prejudice to spread the system of D3 in several parts, because this would lead to reduced security and more possible points for attacks and hacking. The Board cannot recognise such a technical prejudice, because no spread of functions is implied. All functions are located at the server, see 3.15 above. The reasons given in T 1463/11, paragraph 31, about the technical prejudice against a relocation of plug-ins from a server to clients therefore do not apply in the present case.
4.6 Claim 1 of the first auxiliary request therefore does not involve an inventive step, because it amounts to an obvious implementation of a business concept using a notorious client/server system.
5. Second auxiliary request
5.1 The second auxiliary request adds a "verifying means" to claim 1 of the first auxiliary request. According to the appellant this has the effect of providing a secure system which is not manipulable in the sense that the values of a rating contribution table cannot be changed by a person other than a manager. The rating contribution value tables are inaccessible for viewing, as set out in paragraphs [0101] and [0102] of the application.
5.2 Apart from being another business requirement, the Board considers making a manager's data inaccessible as self-evident. The application does not provide any further technical details about the verifying means other than the result of making a rating contribution value table "inaccessible". This is like defining a safe as having the property of making documents stored in it inaccessible. It is an intrinsic and self-evident feature of any safe. The application does not define any technical solution, but just a wish.
5.3 Claim 1 of the second auxiliary request therefore does not add anything inventive.
6. Third and fourth auxiliary requests
6.1 Both requests comprise only method claims. The third auxiliary request is equivalent to the second auxiliary request with the system claims having been deleted. The fourth auxiliary request additionally gives examples of possible security elements, in other words, the attributes of a financial product and it adds that rating contribution values are equal for equal security elements, which is a business rule.
6.2 Therefore, the same reasoning applies to these requests as to the second auxiliary request. Accordingly, claim 1 of the third and the fourth auxiliary request does not involve an inventive step.
7. Fifth auxiliary request
7.1 Claim 1 of the fifth auxiliary request adds to claim 1 of the second auxiliary request the above-mentioned list of security elements - a business feature - and defines the "verifying means" slightly differently. It adds that a client attempting to access the rating contribution value table is verified.
7.2 This however does not alter the function of the verifying means of claim 1 of the second auxiliary request which is to keep rating contribution value tables inaccessible except by the managing client.
7.3 Claim 1 of the fifth auxiliary request therefore does not add anything inventive.
8. Sixth auxiliary request
8.1 The sixth auxiliary request adds to claim 1 of the fifth auxiliary request the feature of generating comparative security rating value information.
8.2 This feature belongs to the business concept. The application, paragraphs [0112] and [0113], explains that this information is for a user for comparing rating values of securities recorded in security information tables for a plurality of securities and presented in the form of bar graphs or pie charts. This is a visual presentation of business-related information and, therefore, non-technical.
8.3 Claim 1 of the sixth auxiliary request therefore does not add anything inventive.
9. Further points
9.1 Decisions T 38/86, T 858/02 and T 163/85 were cited to support the view that the objectively calculated security rating value would have technical character, because the number of received requests is calculated by a technical means.
The Board does not doubt that technical means are used for implementing the counting of transmissions between a client and a server. However, as set out previously in this decision, the fundamental concept behind the "counting" is a business-driven one which is non-technical.
9.2 The appellant also argued that T 641/00 (COMVIK) and T 26/86 support the argument that a minority of technical features in a mixed-type invention, comprising a majority of non-technical features, would be sufficient as a basis for an invention.
The Board does not disagree. In a mixed-type invention features with a clear technical character overcome the so-called "first hurdle" of Article 52(2) and (3) EPC. This does not automatically imply that the invention is inventive. As explained above, an invention is to be assessed by taking account of only those features which contribute to its technical character, whereas features making no such contribution cannot support the presence of inventive step.
For these reasons it is decided that:
The appeal is dismissed.