T 0005/13 (Resolving transactions/APOLLO) 06-12-2018
Download and more information:
SYSTEM AND METHOD FOR RESOLVING TRANSACTIONS
Inventive step - rules based transaction settlement (no
Inventive step - non technical)
Inventive step - use of XML-based dictionaries to translate credit reports in different data formats (no
Inventive step - obvious)
Inventive step - revert to starting point in the closest prior art (no)
I. This appeal is against the decision of the examining division, posted on 19 July 2012 refusing European patent application No. 05812200.3 pursuant to Article 97(2) EPC on the ground of lack of inventive step (Article 56 EPC) based on either commonplace data processing technology or WO 01/55891 (D1) as closest prior art in combination with common general knowledge.
II. In the statement setting out the grounds of appeal, dated 29 November 2012, the appellant requested that the appealed decision be set aside and that a patent be granted on the basis of the main request or auxiliary requests 1 or 2, all submitted with the statement setting out the grounds of appeal. Oral proceedings were requested on an auxiliary basis.
III. In its communication accompanying the summons to oral proceedings, the Board expressed its preliminary opinion that all requests lacked inventive step (Article 56 EPC). The Board additionally referred to US 5732400 A1 (D2), which was cited in the International Search Report and considered to be pertinent prior art.
IV. In a reply, the appellant informed the Board that neither the applicant nor the representative would be attending the oral proceedings and requested to issue a decision on the basis of the documents on file.
V. Oral proceedings were held on 6 December 2018 in absentia. After due consideration of the appellant's written requests and arguments the Chairman announced the decision.
VI. Independent claim 1 of the main request reads as follows:
"1. A method for settling a transaction, comprising:
establishing network communications between a user and a server (102);
receiving information, at the server (102), regarding the transaction;
seeking available information pertinent to the transaction from at least one source external to the server (102) and the user;
parsing said available information using a parser module (204) to provide a set of information pertinent to a party to the transaction located at the server (102) based upon rules provided by a dictionary (214) in XML format, the rules being established on behalf of the party to the transaction located at the server;
processing said pertinent information using a rules based engine (206) including the rules established on behalf of a party to the transaction located at the server (102); and
presenting a transaction settlement offer set to the user based on at least one decision made by the rules based engine (206);
wherein the rules based engine relies on at least the dictionary (214) in XML format to translate received information into information used within the server (102);
wherein the received information comprises a credit report associated with the user; and
wherein the dictionary (214) in XML format provides for translation of terms received from credit reports, including at least first and second credit reports in different data formats, to a term that can be recognized by the rules based engine (206)."
Claim 1 according to auxiliary request 1 reads as follows:
"1. A method for settling a transaction, comprising:
establishing network communications between a user and a server (102);
receiving information, at the server (102), regarding the transaction;
seeking available information pertinent to the transaction from at least one source external to the server (102) and the user;
parsing said available information using a parser module (204) to provide a set of information pertinent to a party to the transaction located at the server (102) based upon rules provided by at least one of a plurality of dictionaries (214) in XML format, the rules being established on behalf of the party to the transaction located at the server;
processing said pertinent information using a rules based engine (206) including the rules established on behalf of a party to the transaction located at the server (102); and
presenting a transaction settlement offer set to the user based on at least one decision made by the rules based engine (206);
wherein the rules based engine relies on at least one of a plurality of schemas (216) and on at least one of the plurality of dictionaries (214) in XML format to translate received information into information used within the server (102);
wherein the received information comprises a credit report associated with the user; and
wherein the plurality of schemas (216) is usable to import credit reports to the server (102), wherein each schema (216) is defined to match to credit report data produced by a different data source, and wherein credit report data is mapped to one or more dictionaries (214) using the schemas (216);
wherein each of the plurality of dictionaries (214) provides for translation of terms within at least one of the schemas (216) to a term that can be recognized by the rules based engine (206)."
The additional features of claim 1 according to auxiliary request 2 are dealt with in point 6 below.
VII. The appellant's arguments are dealt with in the reasons for the decision.
Admissibility
1. The appeal complies with Articles 106 to 108 EPC. It is therefore admissible.
Non-attendance at oral proceedings
2. By letter dated 22 May 2018 the Board was informed that neither the applicant nor the representative would be attending the oral proceedings. The Board nonetheless considered it expedient to maintain the date set for oral proceedings. Nobody attended on behalf of the appellant.
Since neither the applicant nor its representative attended oral proceedings as indicated in the response to the summons, the Board's decision is based only on the written case (Article 15(3) RPBA).
Main request
3. Article 56 EPC - Inventive step
The Board agrees with the decision under appeal that the subject-matter of independent claim 1 lacks an inventive step for essentially the same reasons.
3.1 The claim is directed to a mix of technical and non-technical features. The Board does not dispute that the method according to claim 1 appears in a technical context. The method can be considered to be performed by technical means, because it involves a server computer with means for storing data, means for processing data and means for transmitting and receiving data, and, therefore, has technical character. Accordingly, the claimed subject-matter is an invention in the sense of Article 52(1) EPC (see T 258/03 "Auction method/HITACHI").
3.2 However, the question of inventive step requires an assessment of whether the invention makes a technical contribution over the prior art. Features which do not make such a contribution cannot support the presence of an inventive step (see T 641/00 "Two identities/COMVIK", Headnote I).
3.3 The Board agrees that the features outlined in point 1.2 of the contested decision "per se" pertain to an administrative method, i.e. to the non-technical part of claim 1. These features are:
- receiving information regarding a transaction;
- seeking available information pertinent to the transaction from an external source, other than the user;
- processing the available information to provide a set of information pertinent to a party to the transaction based upon rules provided by a dictionary, the rules being established on behalf of a party to the transaction;
- processing the pertinent information using rules, including the rules established on behalf of a party to the transaction; and
- presenting a transaction settlement offer set to the user based on at least one decision made by using the rules.
3.4 The appellant essentially argued (see page 6 of the grounds of appeal) that the rules based engine of the present invention relied on at least the dictionary (214) in XML format to translate received information into information used within the server (102), wherein the received information comprised a credit report associated with the user. To this end, the newly submitted claims defined that the dictionary (214) in XML format provided for translation of terms received from credit reports, including at least first and second credit reports in different data formats, to a term that can be recognized by the rules based engine (206). This solved the problem of an efficient processing of information from different providers.
In contrast to claim 1, D1 proposed an XML-based communications standard which was enforced among the participants. Document D1 did not disclose an XML-based dictionary which provided for translation of terms received from credit reports, including at least first and second credit reports in different data formats, to a term that could be recognized by a rules based engine. Instead, D1 followed the opposite approach of forcing the trading partners to use one and the same format for their transaction documents (see page 8, last paragraph of the grounds of appeal).
3.5 The Board does not agree with this point of view. D1 discloses as a starting point for its teaching of having a common communications standard, existing measures of a commonly used standard called Electronic Data Interchange EDI for commercial communications, where private data sets are mapped using translators (see D1, page 1, lines 14 to 22). Also D2 discloses EDI translators for rules based credit analysis (see e.g. D2, column 10, lines 4 to 51, notably lines 45 and 46 "...rules for the credit analysis..."; see also figures 5A and 5B with a set of rules).
The improvement that the present invention is alleged to provide, is exactly what D1 sets out from as having been prior art, i.e. having a collection of translators for data of various formats to be translated into a (common) format that can be analysed (see e.g. D1, page 1, lines 23 to 25, "Each time a new trading partner is added to a client list, a new translation program is required to format their data in conformance with the other trading partners on the list"; lines 30 and 31 "generating a translator for every pair of trading partners").
3.6 According to the description of the present application (see e.g. page 23, lines 3 to 9; page 25, line 4 onwards with reference to figure 8), 'dictionary 214 generally represents a translator of terms employed within the credit report, schemas, and creditor decision criteria. For example, one credit report may use the term "Last Name" while another credit report may call the field "Surname," essentially meaning the same thing. The dictionary provides for translation of terms received from credit reports or within creditor schemas to a term that can be recognized by decision engine 206'. In particular figure 8 shows that a "dictionary" according to the claims is a collection of translators.
3.7 In the view of this interpretation of the word "dictionary" according to claim 1, which can be seen to be at least equivalent to such a collection of translators, it can hardly be considered to require inventive skills to go back to what has been described as prior art in D1. In particular, the appellant's argument that D1 leads away from the claimed invention of the present application does not convince in view of the above.
Furthermore, D1 also discloses the use of XML (see e.g. page 3, line 3) for the purpose of communicating and processing documents.
3.8 The Board further considers the concept of letting a parser and rules-based engine both rely on the same rules to be within the non-technical administrative concept (see point 3.3 above), since it is not driven by technical considerations. Trading related non-technical considerations and dependencies for mapping rather than compatibility and interoperability are the criteria for choosing the set of rules. These, however, would be given to the skilled person as part of the specification requirement for implementation.
3.9 It is noted that D1 discloses or at least renders obvious the concept of code packaging and reuse (see D1, section E, page 10, lines 17 to 22, "desirable to re-use this schema").
3.10 For the aforementioned reasons, the additional features added by amendment do not render the subject-matter of claim 1 inventive.
Auxiliary request 1
4. Claim 1 of this request specifies that a plurality of schemas match credit report data produced by different data sources and map the data to one or more dictionaries which translate terms from the schemas to a term that can be recognized by the parser or the rules based engine. Essentially, the claim defines a relationship between each schema and a dedicated data source.
4.1 According to D1, page 1, lines 23 to 25, "Each time a new trading partner is added to a client list, a new translation program is required to format their data in conformance with the other trading partners on the list", and according to lines 30 and 31 a translator is generated for every pair of trading partners. In the Board's view, each translator according to the teaching of D1 is defined to match to credit report data produced by a different trading partner and, hence, defines a relationship which corresponds to the claimed schema. The additional features of claim 1 are therefore obvious in view of D1.
4.2 In addition, the subject-matter of the additional features merely further refines the administrative concept and, hence, does not provide for an inventive technical contribution.
Auxiliary request 2
5. Claim 1 according to this request further specifies that:
a) the user is presented with a series of identification questions to establish the user's identity;
b) if the information pertinent to the transaction which is sought from at least one external source is available, the steps of parsing and processing said information and presenting the corresponding transaction settlement offer set are performed;
c) in the other case, i.e. if the information sought cannot be obtained within a reasonable amount of time, a message is transmitted to the user telling the user to return at a specified time, wherein the message includes a session code or password(s) so that the user does not need to go through the identification process questioning again.
5.1 The additional features a) and b) are within the non-technical administrative concept, because asking questions relating to the user's identity and processing information once this information is available are further non-technical measures, such as would be performed by a business person when settling transactions. The use of general purpose computer functions (e.g. storing and retrieving information in electronic form) is a straightforward implementation that does not give rise to any further technical effect.
5.2 Regarding further feature c), the Board does not agree with the appellant that a particularly safe and convenient authentication process is achieved with technical means. Instead of providing more efficient technical means, it is rather an administrative decision to postpone the processing to a later point of time. Implementing such an administrative measure by using well-known session codes or passwords is regarded as an obvious design option without a surprising technical effect.
5.3 In contrast to case T 1582/07 referred to by the appellant, present claim 1 does not further specify the use of the session key and the way it is transmitted. The conclusions in this decision therefore cannot be applied to the present application. However, the underlying patent application in that case, WO 2004/036513 A1, discloses the use of session codes and is pre-published prior art for the present case.
5.4 Therefore, the subject-matter of claim 1 of this request does not involve an inventive step (Article 56 EPC).
6. The same reasoning applies, mutatis mutandis, to corresponding independent system claims of all requests.
7. Thus, none of the requests fulfils the requirements of the EPC.
For these reasons it is decided that:
The appeal is dismissed.