14-15 November 2018
|European Case Law Identifier:||ECLI:EP:BA:2011:T143607.20111201|
|Date of decision:||01 December 2011|
|Case number:||T 1436/07|
|IPC class:||G06F 11/07
|Language of proceedings:||EN|
|Download and more information:||
|Title of application:||Methods and systems for transaction record delivery using thresholds and multi-stage protocol|
|Applicant name:||Intertrust Technologies Corp.|
|Relevant legal provisions:||
|Keywords:||Request for remittal - rejected
Inventive step - all requests (no)
Summary of Facts and Submissions
I. European patent application number 05001745.8, publication number 1 531 383, is a divisional application of application number 00955281.1 (cf T 0449/10; there is also a further divisional application number 05001746.6, cf T 1438/07). It relates to systems and methods for managing communications between computer systems involved in a transaction.
II. The application was refused by the examining division for lack of inventive step in a written decision issued on 2 March 2007. According to the reasons given, the claimed invention was related to a business method implemented on a distributed computer system, the implementation using ordinary computer means in an ordinary manner.
III. The appellant (applicant) lodged an appeal against the decision on 2 May 2007. By letter dated and received at the EPO on 11 July 2007, the appellant filed a statement setting out the grounds of appeal, including three sets of claims as main request and first and second auxiliary requests.
IV. In a communication annexed to summons to oral proceedings, the Board drew attention to prior art document D2 (WO 93/01550 A), pointing out that in particular the technical contribution of the claimed invention over the prior art in the light of document D2 would be a central issue in forthcoming oral proceedings.
V. Oral proceedings took place before the Board on 1 December 2011. The appellant requested that the decision under appeal be set aside and that the case be remitted to the department of first instance for further prosecution, or, that the decision under appeal be set aside and a patent be granted on the basis of the claims according to the main request, alternatively based on the first auxiliary request, both requests filed with the grounds of appeal, or alternatively based on the second auxiliary request, filed in the oral proceedings. The appellant declared the third auxiliary request, filed with letter dated 31 October 2011, to be withdrawn.
VI. The wording of respective claim 1 of the requests maintained in the oral proceedings is as follows (brackets **(1)<> etc. are added for convenience of reference):
1. **(1)<A method for managing a transaction between a first computer (104) system and a second computer system (102)>, the method including:
initiating communication between the first computer system (104) and the second computer system (102), the communication including a request from the first computer system (104) to the second computer (102) system for authorization to execute **(2)<the> transaction;
initiating a failure-recovery job **(4)<at the first computer system (104), the failure-recovery job being operable to automatically send a status signal to the second computer system (102) if the communication between the first computer system (104) and the second computer system (102) exhibits a predefined fault condition;
receiving a signal from the second computer system (102);
using the signal to modify a definition of the predefined fault condition>.
Claims 1 of the first and second auxiliary requests differ from claim 1 of the main request in the following passages (numbered brackets as indicated above):
First auxiliary request:
Passage **(1)< > reads: "A method, when carried out using a computer program, for communicating between a first computer (104) system and a second computer system (102)".
Passage **(2)< > reads: "a".
Second auxiliary request:
Passage **(1)< > reads: "A method, when carried out using a computer program running on a computer system, for communicating between a first computer (104) and a second computer (102)".
Insertion **(3)<> reads: "sending a communication from the second computer (102) to the first computer (104) indicating either authorization to execute the transaction or non-authorization;
sending an acknowledgement (328) from the first computer (104) to the second computer (102) indicating that the transaction was successfully completed, and in response to receipt of the acknowledgement (328) sending a resend acknowledgement signal (336) from the second computer (102) to the first computer (104);".
VII. In the oral proceedings, the appellant objected to the intention of the Board not to remit the case to the examining division but to decide the appeal on substantive issues. The appellant argued that the examining division had refused the application for reasons of excluded subject matter under Article 52(2) EPC only, which was clearly wrong. The objection of lack of inventive step was raised in the decision under appeal only in passing as an additional point. If the Board now decided on inventive step, the appellant would suffer a loss of instance and the fundamental right to be heard would be seriously disregarded. A negative decision would be final and cause substantial damages to the appellant. Therefore, in the present case, the loss of instance was not acceptable to the appellant. Nor would it be in compliance with the case law as set out by the Enlarged Board of Appeal in the decision G 10/93 Scope of examination in ex-parte appeal/SIEMENS (published in OJ EPO 1995, 172) at par. 4 f. of the Reasons.
VIII. Concerning patentability of the invention, the appellant cited, in the course of the written and oral proceedings, various decisions of the boards of appeal, concluding therefrom that the claimed method was not a method of doing business excluded from patentability. The computer context of the claimed method including computers, computer programs, and electronic signals should not be ignored. The invention addressed the technical problem to detect a fault in communications between computers on the basis of criteria that were remotely adjustable by another computer depending on the circumstances. The technical solution adopted by the invention was to cause a first computer to interrogate a second computer if there was a fault, and to use the response from the second computer to modify the fault criteria which the first computer was using. This provided a centralised and more efficient and versatile mechanism for controlling and managing communications, effective even under circumstances where the communication was lost, delayed or corrupted.
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.
For these reasons it is decided that:
The appeal is dismissed.