T 1436/07 (Managing a transaction I / INTERTRUST TECHNOLOGIES) 01-12-2011

Reasons for the Decision

1. The appeal, although admissible, is not successful since none of the appellant's requests is allowable.

2. Remission to the examining division

2.1 The Board decided to reject the request for remission of the case to the examining division.

Pursuant to Article 111(1) EPC 1973, a board must decide, after assessment of the due circumstances of the case, whether it will rule on the case itself or remit the matter for further prosecution to the examining division (cf G 10/93, Reasons, par.5). There is thus no obligation for a board to remit a case. The decision is a matter of discretion. In exercising its legal power of discretion, a board must take the relevant circumstances of the case into account. In ex parte proceedings, the boards are restricted neither to examination of the grounds for the contested decision nor to the facts and evidence on which the decision is based (see G 10/93, par.3 of the Reasons). The power of discretion encompasses also the subset of 'loss of instance' where a board finds a requirement of the EPC that was not considered by the examining division not to be met, and confirms the impugned decision on the basis of this 'new' ground. Although such a circumstance may justify remission, procedural efficiency has also to be taken into account and justifies in the present case a final decision of the Board.

2.2 Nevertheless, for reasons of completeness the Board notes that the allegedly 'new' ground argued by the appellant is in fact not new, since the objection of lack of inventive step has already been raised and considered in the impugned decision. Contrary to the appellant's reading of the decision as being exclusively based on a statutory exclusion of subject matter from patentability under Article 52(2) EPC 1973, the ground for refusing the application was actually lack of inventive step. The introductory paragraph of the Reasons for the decision reads as follows:

Claim 1 relates to a business method since it does not contain any subject-matter not falling under the exclusions of Article 52(2)(c) EPC which would contribute to the state of the art.

It is true that, read in isolation, this statement may be understood in the way that the subject matter of claim 1 is a business method excluded from patentability. However, the decision also acknowledges that the method claimed is implemented on and executed by means of the first and second computer systems ("Ignoring for the moment …", see 1.1). Therefore, the introductory paragraph should be construed to mean that the business method per se underlying the invention "does not contain any subject-matter ... which would contribute to the state of the art". The statement should thus be regarded as part of an inventive-step argument leading to the conclusion in 1.9 that "the subject-matter defined in claim 1 does not satisfy Article 56 EPC". Considering and deciding the appeal on the basis of inventive step hence does not create the type of 'loss of instance' situation argued by the appellant.

2.3 Considering that there are no other particular circumstances apparent which may outweigh the drawbacks of further procedural delays if the case were remitted, the Board has decided to reject the appellant's request for remission.

3. Lack of inventive step

3.1 The invention to which the main, first and second auxiliary requests relate does not meet the requirement of inventive step as set out in Articles 52(1) EPC and 56 EPC 1973. In the present case the Board can confine itself to give the reasons only in respect to claim 1 of the second auxiliary request since this claim has, compared to claim 1 of the main request and first auxiliary request, the most limited scope of definition, considering that the method of managing a transaction according to the main request encompasses the communication between the computer systems (first and second auxiliary requests).

3.2 Prior art document D2 (WO 93/01550 A) is undoubtedly an appropriate starting point for assessing inventive step. It discloses a computer-implemented method for managing commercial transactions between consumers (licensees) and a vendor (licensor) of much the same type as the present invention. Messages are exchanged between the computers of the business parties via a computer network under control of computer programs (cf D2, page 7, line 25 to page 8, line 6; page 11, lines 4 to 27 in connection with figure 1; and page 25, lines 3 to 12). In terms of present claim 1, the method of document D2 may thus be recited as a method, when carried out using a computer program running on a computer system, for communicating and managing a transaction between a first computer (at the licensee's or consumer's site) and a second computer (at the licensor's or vendor's site).

3.3 The computer-implemented method of document D2 has the following steps in common with the method of present claim 1:

Initiating communication between the first computer and the second computer, the communication including a request (request datagram 3, see figures 1 and 3, and page 11, lines 4 to 28) from the first computer to the second computer for authorization to execute a transaction (seeking permission to access content, cf figure 3, step 107.0), and sending a communication from the second computer to the first computer indicating either authorization to execute the transaction or non-authorization (steps 108.0, 109.0, authorisation code 0 for approval).

At the licensee's site, a failure-recovery job is executed which allows the first computer system to recover from specific fault conditions which may occur between the first and second computer systems, for example when a reply datagram has not been received within a "Wait Interval" (cf D2, License Check Monitor 2 in figure 1; process steps 104.0 to 104.3 in figures 3 and 5).

3.4 In respect to the prior art of document D2, the method of present claim 1 is characterised essentially by the following features (paragraph numbers added for convenience of reference):

i. sending an acknowledgement from the first computer to the second computer indicating that the transaction was successfully completed;

ii. sending, in response to receipt of the acknowledgement, a resend acknowledgement signal from the second computer to the first computer;

iii. the failure-recovery job is a background thread in the computer program running in the first computer and is operable

(a) to automatically resend the acknowledgement on a periodic basis if the resend acknowledgement signal is not received within a predefined time period and

(b) to automatically send an error message to the second computer if a predefined number of acknowledged attempts are made to send the acknowledgement; and

iv. sending a signal from the second computer to the first computer, the signal being operable to modify a definition of the predefined time period.

3.5 The term "acknowledgement" as used in present claim 1 requires closer consideration. In the field of computer networking and telecommunications the normal meaning of this term is a reply signal transmitted to indicate that some signal or data has been received correctly. The term as used in the present application does not fit under such a definition.

3.6 According to feature i. above, the signal "acknowledgement" indicates that the transaction was successfully completed. A transaction in terms of the present application is a business or commercial transaction between a consumer and vendor, as e.g. purchasing of digital content, executed online over a computer network (cf e.g. present application, page 5, lines 13 to 30).

Thus, the primary function of the "acknowledgement" is not to acknowledge the physical receipt of a signal but to inform the vendor about the successful completion of the business action, e.g. the release of the digital content to the user. The side-effect that the vendor might conclude from such a message that the signal indicating authorisation must have been received by the first computer system does not render the signal an acknowledgement within the normal technical meaning of the term.

3.7 According to the claim definition, feature ii. above, the "resend acknowledgement signal" is sent in response to receipt of a signal and, therefore, on the face of it, is an acknowledgement within the normal meaning of the term. However, this definition is not consistent with the embodiments disclosed in the description. As shown in figure 3D and described at page 8, line 32 ff., the completion of the commercial transaction, including withdrawal of funds from the consumer's account etc, is the actual event triggering the "resend acknowledgement signal" 336. This signal does thus not primarily acknowledge the physical receipt of a signal, but has rather to be construed as a piece of information indicating that a further part of the commercial transaction has been completed.

Both "acknowledgement" signals, therefore, serve commercial purposes, namely to inform the respective business partner of the fulfilment of the respective contractual duties, i.e. the delivery of the good and the payment of the price or charges incurred. Features i. and ii. above, therefore, do not provide a technical contribution to the prior art and are thus ignored in the further assessment of inventive step.

3.8 Feature iii. above defines the failure-recovery job "as a background thread in the computer program running in the first computer". It is common practice, however, to organise computer programs in functional subunits like functions, subroutines etc (an example is given in document D2, at page 20, line 2 ff.). Moreover, common operating systems organise processes in small units called threads that share resources but can be executed independently.

The failure-recovery job of feature iii. above is a solution of a common problem in communications systems, namely that a message should, but in fact does not, arrive at the receiver. The standard procedure that faces this situation is a kind of watchdog which triggers a corrective action. Such a watchdog is implemented in document D2 for monitoring the reply signal from the licensor's site to the licensee (see document D2, figure 4, step 103.10 and figure 5 steps 104.1 and 104.2). The corrective action might consist in resending the message (step 104.1, 103.10), generating an error message (step 104.2), or a combination of these actions.

3.9 The solution and the associated conditions defined in features (a) and (b) above may be determined by technical considerations, but as well by business considerations. The application does not give any hint to a technical purpose behind these features beyond the general teaching to react to a missing "resend acknowledgement signal" by resending and error signalling. Whereas in document D2 the fault conditions are at least partly determined by technical considerations concerning the communications network (cf D2, page 12, line 17 to page 13, line 10), such a connection lacks in the present application. The indication of 1, 2, or 5 minutes as examples of the predefined time period (cf the present application at page 9, line 15 ff.) seems to be arbitrary.

3.10 Similarly, feature iv. above concerning the modification of the predefined time period appears to be arbitrary from a technical viewpoint. Under business considerations, however, it might be reasonable or even required to give the vendor control over the time period, for example, in order to give the vendor sufficient time to communicate with a bank for charging the consumer's account. Providing such a control online via a computer network is an obvious solution to the problem of implementing such a type of business requirements. In document D2, for example, the control over time parameters is clearly motivated by business considerations: the licensor can fix licensing periods, determine free trial periods, and extend a licensing period, such a control serving no specific technical purpose (cf D2, page 21, lines 7 to 11).

3.11 The appellant did not present any technical effects or technical advantages which are causally related to the invention as claimed and go beyond a straightforward computer-implementation of a commercial transaction scheme and the normal technical functions of a distributed computer system.

The alleged improvements regarding security are speculative. For example, the statement that the operator of the remote system will be informed and can take immediate defensive action if the local system fails to obey the instructions not to release content (application, page 9, line 54 ff.), or the statement (page 9, lines 28 to 36) that sending or resending acknowledgement 377 (i.e. the acknowledgement 328 in terms of claim 1) makes it more difficult to disconnect or disrupt the communication, are not conclusive. Malicious attacks are still possible since a malicious user may intercept the communication and send faked acknowledgements. There are no countermeasures in claims 1 of the present requests which could clearly reduce the danger of such threats.