T 0315/06 () of 15.12.2006

European Case Law Identifier: ECLI:EP:BA:2006:T031506.20061215
Date of decision: 15 December 2006
Case number: T 0315/06
Application number: 99112367.0
IPC class: H04N 1/00
Language of proceedings: EN
Distribution: C
Download and more information:
Decision text in EN (PDF, 38 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: Device control system
Applicant name: SEIKO EPSON CORPORATION
Opponent name: -
Board: 3.5.04
Headnote: -
Relevant legal provisions:
European Patent Convention 1973 Art 84
European Patent Convention 1973 Art 111(1)
European Patent Convention 1973 R 67
European Patent Convention 1973 R 68(2)
Keywords: Claims - clarity (yes)
Decision re appeals - remittal (yes)
Decision under appeal reasoned (yes)
Reimbursement of the appeal fee (no)
Catchwords:

-

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division to refuse European patent application No. 99 112 367.0.

II. The reasons for the refusal were that the independent claims according to the main request were not clear and their subject-matter was not new with respect to the general prior art in the field of networking and computers and that the subject-matter of claim 1 according to the first and second auxiliary requests did not involve an inventive step with respect to the same general prior art.

III. In the oral proceedings before the board on 15 December 2006 the appellant withdrew the main request and the first to thirteenth auxiliary requests filed during the appeal proceedings and submitted claims 1 to 7 of a new main request.

IV. The appellant requests that the decision under appeal be set aside, that the case be remitted to the first instance for further prosecution and that the appeal fee be reimbursed.

V. The independent claims according to the sole request read as follows:

"1. A device control system for controlling at least two devices (34a, 34b, 240, 340), said device control system comprising:

at least two device abstraction units (28a, 28b, 220, 320) that respectively correspond to the devices (34a,34b, 240, 340) and transmit data or information to and from the corresponding devices (34a, 34b, 240, 340);

at least two interface units (22a, 22b, 120, 140) that respectively correspond to the device abstraction units (28a, 28b, 220, 320) and are connected to the corresponding device abstraction units (28a, 28b, 220, 320) via respective communications paths (26a, 26b), the interface units (22a, 22b, 120, 140) mediating transmission of data or information between the corresponding device abstraction units (28a, 28b, 220, 320) and an application unit (20, 110), which is constructed by a specified applications program; and

at least two communications path abstraction units (24a, 24b, 210, 180, 310, 190) that are respectively interposed between the corresponding device abstraction units (28a, 28b, 220, 320) and the corresponding interface units (22a, 22b, 120, 140), which mutually correspond to each other,

wherein the device abstraction units (28a, 28b, 220, 320) apparently remove a difference in control procedure due to respective types of the corresponding devices (34a, 34b, 240, 340), so as to provide the application unit (20, 110) with an identical control environment, which does not depend upon the types of the devices (34a, 34b, 240, 340), via the interface units (28a, 28b, 220, 320), and

the communications path abstraction units (24a, 24b, 210, 180, 310, 190) apparently remove a difference in control procedure due to respective types of the communications paths (26a, 26b), which connect the corresponding device abstraction units (22a, 22b, 120, 140) with the corresponding interface units (22a, 22b, 120, 140), so as to provide the application unit (20, 110) with an identical control environment, which does not depend upon the types of the communications paths (26a, 26b), via the interface unit (22a, 22b, 120, 140)."

"6. A method of controlling at least two devices (34a, 34b, 240, 340), said method comprising the steps of:

(a) creating at least two device abstraction units (28a, 28b, 220, 320) that respectively correspond to the devices (34a, 34b, 240, 340), transmit data or information to and from the corresponding devices (34a, 34b, 240, 340), and apparently remove a difference in control procedure due to respective types of the corresponding devices (34a, 34b, 240, 340), so as to provide an application unit (20, 110), which is constructed by a specified applications program, with an identical control environment, which does not depend upon the types of the devices (34a, 34b, 240, 340);

(b) creating at least two interface units (22a, 22b, 120, 140) that respectively correspond to the device abstraction units (28a, 28b, 220, 320), are connected to the corresponding device abstraction units (28a, 28b, 220, 320) via at least two communications paths (26a, 26b), and mediate transmission of data or information between the corresponding device abstraction units (28a, 28b, 220, 320) and the application unit (20, 110);

(c) creating at least two communications path abstraction units (24a, 24b, 210, 180, 310, 190) that respectively correspond to the interface units (22a, 22b, 120, 140) and apparently remove a difference in control procedure due to respective types of the communications paths (26a, 26b), which connect the corresponding interface units (22a, 22b, 120, 140) with the corresponding device abstraction units (28a, 28b, 220, 320) further corresponding to the interface units (22a, 22b, 120, 140), so as to provide the application unit (20, 110) with an identical control environment, which does not depend upon the types of the communications paths (26a, 26b); and

(d) causing the application unit (20, 110) to control the devices (34a, 34b, 240, 340) via the interface units (22a, 22b, 120, 140), the communications path abstraction units (24a, 24b, 210, 180, 310, 190), and the device abstraction units (28a, 28b, 220, 320)."

"7. A computer program product for constructing a device control system for controlling at least two devices (34a, 34b, 240, 340), said computer program product comprising:

a computer readable medium;

a first program code segment that causes a computer to create at least two device abstraction units (28a, 28b, 220, 320) that respectively correspond to the devices (34a, 34b, 240, 340), transmit data or information to and from the corresponding devices (34a, 34b, 240, 340), and apparently remove a difference in control procedure due to respective types of the corresponding devices (34a, 34b, 240, 340), so as to provide an application unit (20, 110), which is constructed by a specified applications program, with an identical control environment, which does not depend upon the types of the devices (34a, 34b, 240, 340);

a second program code segment that causes the computer to create at least two interface units (22a, 22b, 120, 140) that respectively correspond to the device abstraction units (28a, 28b, 220, 320), are connected to the corresponding device abstraction units (28a, 28b, 220, 320) via corresponding communications paths (26a, 26b), and mediate transmission of data or information between the corresponding device abstraction units (28a, 28b, 220, 320) and the application units (20, 110); and

a third program code segment that causes the computer to create at least two communications path abstraction units (24a, 24b, 210, 180, 310, 190) that respectively correspond to the interface units (22a, 22b, 120, 140) and apparently remove a difference in control procedure due to respective types of the communications paths (26a, 26b), which connect the corresponding interface units (22a, 22b, 120, 140) with the device abstraction units (28a, 28b, 220, 320) further corresponding to the interface units (22a, 22b, 120, 140), so as to provide the application unit (20, 110) with an identical control environment, which does not depend upon the types of the communications paths (26a, 26b),

wherein each of the program code segments is stored in the computer readable medium."

Claims 2 to 5 are dependent claims.

VI. As regards clarity, the appellant argues that the concept of abstraction is functionally defined in the claims as consisting in a higher unit being independent from a lower unit in terms of control environment by removing differences in control procedure due to different types of devices and communications paths. The adopted functional definition may be broad but is not unclear.

VII. As regards novelty and inventive step, the appellant stresses the benefits of the invention for data transfer between a first and a second device by activating a single application program.

VIII. As regards the request for reimbursement of the appeal fee, the appellant holds that the argumentation relating to lack of novelty and inventive step in the appealed decision is unclear and cannot be understood, so that a substantial procedural violation results from the absence of a reasonable line of argumentation, which does not comply with Rule 68(2) EPC. More particularly:

- The decision neglects to perform a complete feature analysis and does not clearly identify the known features relevant for the claims.

- The decision does not refer to a document of prior art but confuses the prior art with the invention by citing as prior art features described in the context of the device control system according to the invention (e.g. by reference to figures 2B, 2C and 5 of the application).

- The WindowsTM computer platform mentioned in the decision is a general platform with a variety of different software evolving over time, so that it is not clear which specific features were already known at the priority date of the application.

- Models such as COM/DCOM or features such as remote procedure calls, stubs and proxies are known per se from WindowsTM platforms. However, the special use of the features to implement the claimed communications path abstraction is not addressed in the decision.

Reasons for the Decision

1. The appeal is admissible.

2. Amendments

The independent claims 1, 6 and 7 according to the sole request are based on claims 1, 7 and 8 as originally filed with the essential difference that they now refer to at least two device abstraction units, interface units and communications path abstraction units, as disclosed for instance in figure 1 and claims 2 and 3 as originally filed. As a result, the amended claims comply with Article 123(2) EPC.

3. Article 84 EPC

3.1 A device abstraction unit or a communications path abstraction unit are specified in the claims as removing a difference in control procedure due to a type of the corresponding device or communications path, respectively. The decision under appeal regards as obscure the device abstraction unit because it "does not specify in which way an abstraction transmits data or information and to what degree", and the communications path abstraction unit because "it is left open what the abstraction means removes and how the control procedure is flattened".

3.2 The functional definition of abstraction in the claims ("apparently remove a difference in control procedure", "so as to provide the application unit ... with an identical control environment") and its explanation in the description (e.g. "substantially fixed control environment" in paragraph [0013] of the published patent application) is consistent with the meaning of abstraction commonly accepted in the relevant field of computer system architecture, in which it consists in hiding specifics as to the implementation at a lower level. The expression "apparently remove..." in this context has to be understood as meaning that a difference in control procedure is removed by an abstraction unit so that different types of devices or communications paths appear to be identical for the controlling unit.

3.3 The fact that the amended independent claims now define at least two (distinct) devices with their respective communications paths makes clear that abstraction has to be such as to hide the specifics relating to different types of devices (e.g. printer vs. scanner) and their location (e.g. local vs. remote) from the standpoint of the application unit, so as to appear as a "composite device" which may be set up in different configurations (see e.g. paragraphs [0073] to [0075] and [0150] to [0163] of the published application). The introductory part of the description (see e.g. paragraph [0004]) accordingly sets out that this solves the problem of avoiding to "activate the plurality of applications programs for supporting the respective devices and implement the data transfer between the devices..."

3.4 The general definition in the claims is therefore in line with both the common meaning of the terms in the relevant technical field and with the description of the invention, so that the person skilled in the art can determine the boundaries of the claimed subject-matter. In the judgment of the board, the subject-matter of the claims also solves the technical problem described in the application, as set out in point 3.3 above. The claims are therefore supported by the description.

3.5 As a result, claims 1, 6 and 7 comply with the requirements of Article 84 EPC.

4. Remittal

4.1 The claimed inventions including (at least) two devices together with their associated device abstraction units and communications path abstraction units define features of a composite device with an improved operability (see point 3.3 above and point 3.4 of the statement setting out the grounds of appeal).

4.2 The decision under appeal explains the mechanism of data transmission between a client and a server and concludes that there is a lack of novelty or inventive step based on general prior art in the field of networking and computers. These objections are not convincing for the subject-matter of the present claims associating (at least) two devices to form a composite device, which goes beyond generally known computer networks, device drivers and mechanisms provided by usual Windows**(TM) platforms. Since the essential features for achieving the technical effect, as understood from the description, are specified in the claims, an objection of lack of novelty or of lack of inventive step needs to set out reasons including verifiable concrete facts of prior art and arguments which deal with the features as now claimed and the underlying problem.

4.3 Since the examining division has not yet had the opportunity to present such reasons relating to the new claims, the board decides, in accordance with Article 111(1) EPC, to set aside the decision under appeal and to remit the case to the first instance in accordance with the appellant's request, for the first instance to examine whether the application as amended fulfils the requirements of the EPC.

5. Reimbursement of the appeal fee (Rule 67 EPC)

5.1 Where the appeal is deemed allowable, reimbursement of the appeal fee is possible only if it is equitable by reason of a substantial procedural violation. The appellant holds in the present case that such a violation arises from the absence of a reasonable line of argumentation in the decision under appeal, depriving him of a reasoned decision as required by Rule 68(2) EPC.

5.2 The claims on which the examining division took a decision were not restricted to subject-matter relating to corresponding units of a composite device as supported by the embodiments of the description. The board takes the view that the decision under appeal, referring to generally known network topologies, drivers and Windows**(TM) mechanisms, enables a skilled reader to identify the specific features regarded as known or obvious by the examining division, for the following reasons.

5.3 The decision under appeal relies on figures 2 and 5, which are respectively described as block diagrams showing typical states of connection and a data transfer technique in the device control system embodying the present invention. It mentions figures 2B and 2C to illustrate a distributed computer network with a collection of client nodes that communicate over a network with various server nodes and figure 5 to illustrate a general protocol stack used to transmit data between a client node and a server node in a network. Although a reference to the figures is in the present case not necessarily conducive to strengthen an argumentation based on general knowledge, the person skilled in the art seeking to make sense of the decision is nevertheless able to identify the particular known features the decision associates with the cited figures, namely (only) those generally known of a data transmission mechanism to a single device in a usual basic client/server network architecture. The board further notes that the appellant agrees that such features are common general knowledge.

As a result, the decision under appeal merely illustrates by reference to figures of the application what kind of network topologies are considered as generally known and it does not confuse the prior art with the invention.

5.4 The decision further mentions "the general prior art such as implemented for Windows" and thereby explicitly refers to passages in the application as originally filed (page 25, line 15 to page 27, line 5, corresponding to paragraphs [0088] to [0094] of the published application). The cited passages explain the operation of remote procedure calls (RPC, LRPC), stubs and proxies, which are stated to be generated by the mechanism of COM/DCOM normally supported by WindowsTM platforms (see paragraph [0088]), so as to apparently remove a difference in the control procedure ascribed to the different types of the communication paths (see paragraph [0094]).

The board recognises that the various versions of the WindowsTM operating system have undergone changes and evolved over time, and that they are also more comprehensive and general than the features addressed in the foregoing paragraph. The decision does not however rely on a vague reference to WindowsTM in general but refers to specific paragraphs in the description of the application reflecting particular models and features implemented in (possibly various versions of) the operating systems, enabling the person skilled in the art to identify the features of WindowsTM considered by the examining division to be known.

Furthermore, neither during the examination proceedings nor during the appeal proceedings did the appellant contest the correctness of the description of the relevant features of the COM/DCOM model or the fact that they were known before the priority date of the present application. There was therefore no need for the examining division to cite a document as evidence for that very prior art.

5.5 The appellant also argues that the decision under appeal does not discuss the special use of stubs and proxies according to the invention. However, as already set out above, the claims then on file were not restricted to subject-matter where stubs and proxies are used in a special configuration, for instance in a composite device.

5.6 In conclusion, the board considers that the decision under appeal enables the appellant to understand, and to counter, the facts and the essential line of reasoning put forward by the examining division for the subject-matter which was then covered by the claims. It is therefore sufficiently reasoned, as required by Rule 68(2) EPC. The examining division has thus not committed a substantial procedural violation. Therefore, the reimbursement of the appeal fee cannot be ordered.

ORDER

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the first instance for further prosecution.

3. The request for reimbursement of the appeal fee is refused.

Quick Navigation