T 1340/06 (Consistency of registration data/CARDINALCOMMERCE) of 16.7.2009

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division dispatched 28 March 2006, refusing European patent application No. 01918364.9 for lack of an inventive step according to Article 56 EPC 1973 based on publication:

D2: http://web.archive.org/web/19991004130922/ pages.ebay.com/aw/help/help-faq-verify.html ("Verified eBay User FAQ", 04.10.1999 by Archive.org) (the numbering following the appealed decision).

II. In the statement setting out the grounds of appeal filed with letter dated 4 August 2006 it was requested that the decision under appeal be set aside and that a patent be granted on the basis of claims 1 to 10 submitted with the statement setting out the grounds of appeal (main request). Further, oral proceedings were requested as an auxiliary measure.

III. A summons to oral proceedings to be held on 16 July 2009 was issued on 14 April 2009. In an annex accompanying the summons the board expressed the preliminary opinion that the subject-matter of independent claim 1 of the main request was considered obvious (Article 56 EPC 1973) in the light of the disclosure of D2 when combined with

D3: WO 99/60483,

which was introduced into the proceedings by the board of its own motion according to Article 114(1) EPC. The board gave its reasons for the objection and why the appellant's arguments were not convincing.

IV. With a letter dated 16 June 2009 the appellant filed two sets of amended claims 1 to 12 according to auxiliary requests 1 and 2, and an amended set of claims 1 to 8 according to an auxiliary request 3 together with arguments that the main request and auxiliary request 1 involved an inventive step. However, no arguments supporting auxiliary requests 2 and 3 were presented.

V. Oral proceedings were held on 16 July 2009 in the course of which the appellant's representative submitted an amended set of claims 1 to 10 as a new auxiliary request 1' to replace auxiliary request 1. The previous requests were renumbered to form auxiliary requests 2 to 4.

VI. Independent claim 1 of the main request reads as follows:

"1. A method of centralized identity authentication for use in connection with a communications network (20) comprising:

(a) registering users (40) of the communications network (20) in a centralized identity authentication system (a) such that each registered user´s identity is uniquely defined and determinable wherein registration data are obtained from the user (40);

(b) registering a plurality of vendors (30a-n) having a presence on the communications network (20) in said centralized identity authentication system (a);

(b1) verifying the user´s identity by determining the consistency of the registration data with information made available from databases (34a-n) of the registered vendors (30a-n);

wherein said registered vendors selectively transact with registered users (40), said transactions including at least one of:

(i) the registered vendors (30a-n) selling at least one of goods and services to the registered user (40),

(ii) the registered vendor (30a-n) granting the registered user (40) access to personal records maintained by the registered vendor (30a-n), and,

(iii) the registered vendor (30a-n) communicating to the registered user (40) personal information maintained by the registered vendor (30a-n); and

(c) authenticating each user´s identity over the communications network (20) by said centralized identity authentication system (a) prior to completion of transactions between registered vendors (30a-n) and registered users (40)."

VII. Independent claim 1 of auxiliary request 1' reads as follows:

"1. A method of centralized identity authentication for use in connection with a communications network (20) comprising:

(a) registering users (40) of the communications network (20) in a centralized identity authentication system (a) including an authenticating agent (10) such that each registered user´s identity is uniquely defined and determinable wherein registration data are obtained from the user (40);

(b) registering a plurality of vendors (30a-n) having a presence on the communications network (20) in said centralized identity authentication system (a);

(b1) verifying the user´s identity by determining the consistency of the registration data with information made available from databases (34a-n) of the registered vendors (30a-n);

(b2) opening the user account (112) and notifying the user of the outcome

wherein said registered vendors selectively transact with registered users (40), said transactions including at least one of:

(i) the registered vendors (30a-n) selling at least one of goods and services to the registered user (40),

(ii) the registered vendor (30a-n) granting the registered user (40) access to personal records maintained by the registered vendor (30a-n), and,

(iii) the registered vendor (30a-n) communicating to the registered user (40) personal information maintained by the registered vendor (30a-n); and

(c) authenticating each user´s identity over the communications network (20) by said centralized identity authentication system (a) prior to completion of transactions between registered vendors (30a-n) and registered users (40)

(c1) including collecting authentication data by the agent (10) and comparing the authentication data for consistency to the user account information maintained in an agent's database (14)." (additions vis-à-vis the main request emphasised by the board)

VIII. Independent claim 1 of auxiliary request 2 reads as follows:

"1. A method of centralized identity authentication for use in connection with a communications network (20) comprising:

(a) registering users (40) of the communications network (20) in a centralized identity authentication system (a) such that each registered user´s identity is uniquely defined and determinable wherein registration data are obtained from the user (40);

wherein an authentication vehicle is set up for the user (40);

(b) registering a plurality of vendors (30a-n) having a presence on the communications network (20) in said centralized identity authentication system (a);

(b1) verifying the user´s identity by determining the consistency of the registration data with information made available from databases (34a-n) of the registered vendors (30a-n);

wherein said registration data is collected by one of the registered vendors (30a-n);

wherein said registered vendors selectively transact with registered users (40), said transactions including at least one of:

(i) the registered vendors (30a-n) selling at least one of goods and services to the registered user (40),

(ii) the registered vendor (30a-n) granting the registered user (40) access to personal records maintained by the registered vendor (30a-n), and,

(iii) the registered vendor (30a-n) communicating to the registered user (40) personal information maintained by the registered vendor (30a-n); and

(c) authenticating each user´s identity over the communications network (20) by said centralized identity authentication system (a) by said authentication vehicle prior to completion of transactions between registered vendors (30a-n) and registered users (40)." (additions vis-à-vis the main request emphasised by the board)

IX. Independent claim 1 of auxiliary request 3 reads as follows:

"1. A method of centralized identity authentication for use in connection with a communications network (20) comprising:

(a) registering users (40) of the communications network (20) in a centralized identity authentication system (a) such that each registered user´s identity is uniquely defined and determinable wherein registration data are obtained from the user (40), wherein an authentication vehicle is set up for the user (40);

(b) registering a plurality of vendors (30a-n) having a presence on the communications network (20) in said centralized identity authentication system (a);

(b1) verifying the user´s identity by determining the consistency of the registration data with information made available from databases (34a-n) of the registered vendors (30a-n);

wherein said registration data is collected by one of the registered vendors (30a-n);

wherein said registered vendors selectively transact with registered users (40), said transactions including a plurality of:

the registered vendors (30a-n) selling at least one of goods and services to the registered user (40), wherein the user (40) is permitted to make multiple requests from various registered vendors (30a-n), which are collected and stored in a virtual shopping cart and processed in a batch;

(c) authenticating each user´s identity over the communications network (20) by said centralized identity authentication system (a) by said authentication vehicle prior to completion of transactions between registered vendors (30a-n) and registered users (40)."

X. Independent claim 1 of auxiliary request 4 reads as follows:

"1. A method of centralized identity authentication for use in connection with a communications network (20) comprising:

(a) registering users (40) of the communications network (20) in a centralized identity authentication system (a) such that each registered user´s identity is uniquely defined and determinable wherein registration data are obtained from the user (40), wherein an authentication vehicle is set up for the user (40), wherein the authentication vehicle comprises a hardware token;

(b) registering a plurality of vendors (30a-n) having a presence on the communications network (20) in said centralized identity authentication system (a);

(b1) verifying the user´s identity by determining the consistency of the registration data with information made available from databases (34a-n) of the registered vendors (30a-n);

wherein said registration data is collected by one of the registered vendors (30a-n);

wherein said registered vendors selectively transact with registered users (40), said transactions including a plurality of:

the registered vendors (30a-n) selling at least one of goods and services to the registered user (40), wherein the user (40) is permitted to make multiple requests from various registered vendors (30a-n), which are collected and stored in a virtual shopping cart and processed in a batch;

(c) authenticating each user´s identity over the communications network (20) by said centralized identity authentication system (a) by said authentication vehicle prior to completion of transactions between registered vendors (30a-n) and registered users (40)."

XI. A corresponding independent claim is directed to a centralized authentication system (claim 7 for each, the main request and auxiliary requests 1 to 3, claim 5 for auxiliary request 4).

XII. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request filed with the statement of grounds of appeal dated 4 August 2006 or auxiliary request 1 filed during the oral proceedings before the board or the auxiliary requests filed with letter dated 16 June 2009 which were maintained as auxiliary requests 2 to 4.

XIII. After deliberation the board announced its decision.

Reasons for the Decision

1. The appeal is admissible.

Main request

2. Inventive step of claims 1 and 7 - Articles 52(1) EPC and 56 EPC 1973

2.1 It was common ground in the written procedure and in the oral proceedings that D2 discloses all the features of claim 1 except for feature b1) (see e.g. section 4.1 of the statement setting out the grounds of appeal). The board agrees with the analysis of corresponding features given in Reasons 1.1 of the appealed decision.

2.2 The appellant argues that the objective technical problem of distinguishing feature b1) can be considered to improve security and the user-friendliness of the claimed user authentication.

2.3 Publication D2 refers to the "Verified eBay User program" (which is apparently still in operation as the "ID Verify TM" programme). D2 discloses that registration information comprising name, address and phone number is collected, together with the Social Security number, driver's license information and the date of birth (see third question "What specific information is collected?" of the FAQ). D2 further mentions that the collected information from a user is submitted to the company "Equifax" (see second question "How do I get verified?" of the FAQ).

2.4 The question which immediately arises from D2 is what should be done with the information. Since D2 mentions Equifax, it would be natural for the skilled person to consult Equifax's published patent applications, and in particular D3, for an answer.

The appellant argued that the skilled person would not proceed in this manner but even if, for the sake of argument the board ignores the reference to the company "Equifax" in D2, the skilled person when looking for a solution to the problem how to implement an authentication method as disclosed in D2 would search in patent literature in general and would take notice of D3, which is titled "System and method for authentication of network users" and which also deals with the problem of improving security for identity authentication (see e.g. page 1, lines 13 to 15).

2.5 D3 teaches the skilled person to compare the user-supplied data to known data which may be obtained from separate sources including third party databases such as commercial or government databases, or internal databases. Thereby increased certainty of authentication is achieved by using additional databases and requiring internal consistency (see page 19, lines 6-25; page 22, lines 13-15; page 33, line 30 to page 34, line 1; figures 12, 31 to 36 and 41 to 45).

2.6 The appellant's argument that there was an inventive difference in comparison to the disclosure of D3 in that according to feature b1) the information for a consistency check is taken from "databases of the registered vendors (30a-n)" does not convince. According to the description of the present application possible embodiments of such a feature are, inter alia, governmental databases and governmental records (see page 5, paragraphs 4 and 6). However, the same type of information, i.e. government databases, is found in D3 (see page 19, line 9) to be used for the same purpose. That the databases belong to "registered vendors" represents, at most, a commercial relationship between the parties, since in both cases the verifying system must have a list of databases to look up. Thus, this feature is not considered to provide any technical effect and, therefore, does not contribute to the technical character of the claim. Feature b1) as a whole therefore does not provide an inventive technical contribution over the prior art.

2.7 Appellant's argument that the claimed subject-matter requires linking of separate databases of the vendor with the central databases of the agent to verify the user's identity, and that this involves technical considerations (see section 4.2.4 of the grounds of appeal) is not reflected by claim 1. The board rather agrees with the appellant's position expressed on page 9, second paragraph, of the statement setting out the grounds of appeal ("the core of the present invention is not the integration of two databases per se, but the use of various databases to verify the user's identity by carrying out a consistency check"), i.e. all that is specified in the claim is that information of different databases is accessed for a consistency check of such information. This is exactly what is known from document D3. Therefore argumentation based on an integration of two separate systems as in decision T 769/92 (SOHEI) does not have any relevance to the question of inventive step.

2.8 Thus the subject-matter of claim 1, and mutatis mutandis claim 7, lacks an inventive step over the disclosure of D2 combined with the teaching of D3.

Auxiliary request 1'

3. Inventive step of claims 1 and 7 - Articles 52(1) EPC and 56 EPC 1973

3.1 With regard to added feature b2) of claim 1 of this request, the board considers it an implicit feature of D2 that a user who registers with eBayTM opens a user account. According to the disclosure of D2, a user who has been successfully verified by EquifaxTM becomes a "Verified eBay User" with a corresponding icon, which means that a corresponding user account is opened. It is further implicit that a user is notified of the outcome of the registration process, at least by receiving the information that he/she has qualified as a "Verified eBay User" and has got the corresponding icon. Also according to the teaching of D3, a user is notified of having been successfully authenticated (see e.g. figure 36 of D3).

3.2 The further amendments, introducing an "authenticating agent" in feature a) and adding feature c1) to claim 1, is not considered by the board to add any technical functionality that goes beyond the technical teaching of claim 1 of the main request. D2 discloses a "User ID" (see box at the top, left hand side of page 1) and implicitly discloses the use of a password thereby disclosing authenticating a user's identity. This involves collecting authentication data which, of course, has to be compared for consistency with user account information. Using an "authentication agent" for this purpose is merely defining an entity for this functionality on an abstract level without any further technical implication and does not go beyond what is disclosed in D2 and D3.

3.3 Thus the subject-matter of claim 1 of this request, and mutatis mutandis claim 7, lacks an inventive step over the disclosure of D2 combined with the teaching of D3.

Auxiliary request 2

4. Inventive step of claims 1 and 7 - Articles 52(1) EPC and 56 EPC 1973

4.1 D3 discloses issuing a digital certificate to be used for later transactions (see e.g. page 8, lines 7 to 9; page 27, lines 4 and 12; figures 36 and 39 to 41) which can be considered a classical authentication vehicle according to the amended feature a).

4.2 D3 discloses that an authentication server can be operated by a vendor (see page 27, line 6). D3 further discloses batch processing of registration data (see e.g. page 14, lines 24 to 26 and page 31, lines 27 to 29) which indicates that a user does not have to be present at the time of registration. This at least implies that a third party can collect the registration data. Therefore, it is considered at least obvious to collect registration data by one of the registered vendors according to amended feature b1).

4.3 Thus, the subject-matter of claim 1 of this request, and mutatis mutandis claim 7, also lacks an inventive step (Article 56 EPC 1973).

Auxiliary requests 3 and 4

5. Admissibility

5.1 Claim 1 of both requests has been amended, inter alia, by further defining the way a transaction is performed, i.e. adding that a user is permitted to make multiple requests from various registered vendors, which are collected and stored in a virtual shopping cart and processed in a batch.

The appellant did not present convincing arguments that this amendment provides for any kind of synergetic effect with the process of registration for later authentication as claimed in the preceding requests. Neither does the board see such a synergetic effect. The amendment is therefore considered an aggregated feature not contributing to the solution of the technical problem of improving security in identity authentication; it is rather directed to the different problem of rendering a shopping transaction more convenient.

This amendment introduces at a late stage of the proceedings, i.e. one month before the oral proceedings, subject-matter for the first time which has not been claimed before, e.g. in a dependent claim, and which is not directly related to the original technical problem of improving security in identity authentication. These requests are therefore diverging rather than converging to a solution of the overall technical problem addressed in the preceding requests.

In addition, no arguments supporting an inventive step of those sets of claims were presented before the date of oral proceedings. According to Article 13(3) RPBA amendments after oral proceedings have been arranged shall not be admitted if they raise issues which the board cannot reasonably be expected to deal with without adjournment of the oral proceedings. If the board were to admit such requests in a situation like the present, the appellant applicant would effectively be able to prolong the procedure whenever it is desired. This, however, would be in contradiction to the principle of procedural economy.

5.2 In the light of the above mentioned considerations and when exercising the board's discretion in view of the late stage of the proceedings and the need for procedural economy (Article 13(1) RPBA), auxiliary requests 3 and 4 are not admitted into the proceedings by the board.

6. Since there is no admissible request which is also allowable, the appeal has to be dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.