T 1780/09 (REHLE/Deferred web-based transaction) of 24.1.2014

Summary of Facts and Submissions

I. The appeal is against the decision by the examining division, with reasons dispatched on 26 March 2009, to refuse European patent application 00 952 156.8, on the basis that the subject-matter of the independent claim 1 of all requests was not clear, Article 84 EPC 1973, and lacked inventive step, Article 56 EPC 1973, and the auxiliary requests 1 and 2 introduced additional subject-matter, Article 123(2) EPC. The following document was cited as the closest prior art during the first instance procedure:

D1: M. Szmurlo et al.: "A network of asynchronous micro-servers as a framework for server development", Computer Networks and ISDN Systems, vol. 29, no. 8-13, September 1997 (1997-09), pages 1041-1051, XP002158003

II. A notice of appeal was received on 29 May 2009, the appeal fee being paid on the same day. A statement of the grounds of the appeal was received on 5 August 2009.

III. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of claims 1 to 3 of the request filed with the statement of grounds of appeal, description pages 1, 2 and 4 to 16 as originally filed, description page 3 as filed with letter of 10 February 2009, description pages 3A and 17 as filed with letter of 19 April 2005, and figures 1 to 8 as originally filed. The appellant made a conditional request for oral proceedings.

IV. The board issued a summons to oral proceedings. In an annex to the summons, the board set out its preliminary, negative opinion on the appeal.

V. The appellant's representative announced by telefax on 17 January 2014 that he would not attend the oral proceedings. No substantive response was made to the board's arguments. The oral proceedings were held on 24 January 2014, in the absence of the appellant.

VI. The independent claim 1 reads as follows:

A computer-implemented method for handling a deferred completion of a transaction between a server process (1300) and a client application (1100), wherein the server process (1300) is executing on a server computer system (2000), said method comprising:

the server computer system (2000) providing a page to the client application (1100), the provided page including one or more form fields, wherein the page is one of multiple pages used to complete the transaction;

the server computer system (2000) receiving a user response (7700) including values for the one or more form fields, wherein the values are input by a user of the client application (1100);

the server computer system (2000) updating a state object (4200) to include the values for the one or more form fields, and to alter a position identifier (4220) to reflect that the transaction has advanced a page, wherein the position identifier (4220) specifies a page within the transaction to which the user should be returned when resuming the transaction after a deferral of the transaction;

in response to determining that a next page in the multiple pages is yet to be completed, the server computer system (2000) providing the next page of the transaction to the client application (1100);

the server computer system (2000) monitoring an elapsed time since said next page was provided;

the server computer system (2000) determining whether said elapsed time exceeds a predetermined time limit;

upon not receiving a response from the client application (1100) within the predetermined time limit, the server computer system (2000) deferring completion of the transaction;

the server computer system (2000) generating an identifier for the state object (4200), wherein the identifier is usable by the server computer system (2000) to resume the transaction at the page specified by the position identifier (4220); and

the server computer system (2000) transmitting said identifier to the client application (1100).

VII. The independent claims 2 and 3 are respectively apparatus and "computer program product" claims containing features that correspond to the method features of claim 1.

VIII. At the end of the oral proceedings, the chairman announced the board's decision.

Reasons for the Decision

1. The appellant's non-attendance at the oral proceedings

As announced in advance, the duly summoned appellant did not attend the oral proceedings. In accordance with Article 15(3) RPBA, the board relied for its decision only on the appellant's written submissions. The board was in a position to decide at the conclusion of the oral proceedings, since the case was ready for decision (Article 15(6) RPBA), and the voluntary absence of the appellant was not a reason for delaying a decision (Article 15(3) RPBA).

2. The admissibility of the appeal

In view of the facts set out at points I and II above, the appeal is admissible, since it complies with the EPC formal admissibility requirements.

3. Inventive step, Article 56 EPC 1973

3.1 In the appealed decision, D1 is considered to represent the closest prior art. The board agrees that it is a suitable starting point for considering the question of inventive step. It is remarked that, when referring to D1, the appellant actually refers to a different document, which is conceivably the original paper that was presented at the Sixth International World Wide Web Conference in 1997. Although the relevant content of that document is the same as that of D1 as identified under I above, it is differently formatted. As a result, relevant passages in D1 are on different places than the ones indicated by the appellant.

3.2 D1 is concerned with the problem of maintaining state through a series of HTTP requests which together constitute a "multi-page transaction", described as a "session" in D1. It does so by maintaining a data-structure which represents a hierarchy of "server automata", which satisfies the requirement for a "state object" as presently claimed. The board therefore disagrees with the appellant's argument that the state object is not updated (grounds, page 7, paragraph 3); the hierarchy is indeed updated at each step by the addition of a new branch.

3.3 After each step of the transaction, the server of D1 sends an updated cookie to the client (page 1046, column 1, line 5 to column 2, line 11, specifically column 1, lines 23 to 26). This cookie includes a "userID", which identifies the active session (left column, lines 29 to 33) and an "operationID", which serves to identify the step of the transaction which has been reached (column 1, lines 33 to 38). The board considers that the cookie is an "identifier for the state object" as specified in the last seven lines of claim 1.

3.4 D1 does not deal explicitly with suspending or interrupting a transaction and resuming it later, although it does imply that it is a problem solved by the method disclosed (page 1042, column 1, lines 31 to 33). However, it does not need to explain in detail how to resume a transaction; it would be clear to the skilled person that resumption would be a trivial issue. The appellant asserts that "D1 implies that when a HTTP session becomes inactive, all intermediate results are lost." However, there is no such thing as an "HTTP session" as such. HTTP is well known to be a stateless protocol; a fresh TCP connection to the server is created for each single request, and it is in principle irrelevant to the server whether requests are separated by thirty seconds or thirty days. "Sessions" are only created by the maintenance of state, so that in D1 an "active session" is merely a transaction which has not been completed. In practical terms, resumption in D1 would trivially be implemented by the user revisiting the main page of the application using the cookie it has, the server detecting the cookie and applying it as described in the passage cited above. It is true that a practical implementation of the method in D1 would include measures to reclaim memory at some point, including deleting the state object for completed transactions and presumably killing uncompleted transactions after an appropriate time (e.g. one month). But that does not affect the fact that suspension and resumption is intrinsic to the method described.

3.5 Therefore the only feature claimed which is not disclosed by D1 is that the "identifier" is generated and sent when a timeout for response by the client occurs. In D1 the identifier is sent after every response by the client. The two alternatives are considered obvious to the skilled person, either alternative having possible advantages and disadvantages. In particular, the method adopted in the present claim would appear to have a significant weakness in that a common cause of failure to respond by the client would be the loss of the network connection; in this case the identifier would not reach the client, and those steps carried out between the previous sending of an identifier and this one would be lost.

3.6 The skilled person would therefore arrive at the subject-matter of claim 1 without the need for an inventive step. As a consequence, claim 1 and, for similar reasons, claims 2 and 3, do not satisfy the requirements of Articles 52(1) and 56 EPC 1973.

3.7 Apart from the arguments in the grounds of appeal that have already been dealt with above, the appellant has emphasised that in D1 user identification is used. In the board's view, the skilled person would realise firstly that in the present application the client requests would also have to use some form of transaction identifier in each request so that the server could match the request to the transaction, since in any realistic scenario the server would be dealing with multiple transactions concurrently. The application is silent on this point; in particular, it does not exclude that the transaction identifier used also includes a user identification. Secondly, it would be realised that there is no need in D1 for the identifier used to be a user identifier, it could be any transaction identifier. The board therefore finds the appellant's arguments on this point not to hold ground.

Order

For these reasons it is decided that:

The appeal is dismissed.