T 2015/12 (Job distribution/MATHWORKS) 07-03-2017

Reimbursement of the appeal fee

1. The appellant correctly observes that the decision reproduced claim 1 inaccurately in point IX of the facts and submissions. Specifically, in each of S1-S4 the phrase "one or more instructions" was omitted compared with claim 1 as submitted on 24 July 2009.

1.1 However, the board finds it to be clear from the minutes of the oral proceedings before the examining division (see first paragraph) and the decision (see facts and submissions, points V and VIII) that the examining division considered and took a decision on the correct requests. A request containing claim 1 as reproduced in the decision was never filed.

1.2 Moreover, the clarity objections in the decision were to all three independent claims alike, i.e. to the computer-readable medium (claim 1), the method (claim 7) and the distributed computing system (claim 13). Claims 7 and 13, which are not reproduced in the decision, do not refer to "one or more instructions". Apart from the fact that, therefore, there is no doubt as to which version of claims 7 and 13 was considered in the decision, it is evident that the reasons in the decision do not depend on whether steps are claimed or "one or more instructions" to carry out steps. In other words, the omission in point IX is manifestly immaterial for the decision in substance.

1.3 Therefore, the board takes the view that the omission in point IX of the decision does not constitute a substantial procedural violation. The reimbursement of the appeal fee under Rule 103(1)(a) EPC is thus not possible.

The invention

2. In general terms, the application relates to the distribution of jobs in a distributed computing environment, preferably to speed up the execution of complex MATLAB programs (see pages 1 and 2, last paragraphs).

2.1 The distributed computing environment considered in the application has the general form depicted in figure 3, comprising at least a client computer (no. 221), a "scheduler" (no. 230; also referred to as a "job" or "task manager", see page 6, lines 24-27) and several "workers" (no. 240, 250, 260). The application mentions in particular the need to be able to use "an arbitrary job manager provided by an arbitrary vendor" (page 3, lines 1-2) from which, if there are several, the user is to select one (see page 12, lines 17-24).

2.2 At the client computer a "job" is created, possibly comprising several "tasks" (see e.g. page 3, lines 12-14, and page 5, lines 24-26), and a request indicating (or implying) which scheduler is to mediate the transmission of the job to the workers (see e.g. page 12, lines 32-33). The client encodes the job for transmission to the scheduler (see, e.g. page 19, lines 1-3, and page 6, lines 12-13) via an interface, which establishes and manages the necessary communication using a "communication channel" and its software representation referred to as a "scheduler object" (see figure 3, no. 222; figure 4; and page 14, lines 26-27). Along with the job, additional information is transmitted to be used by the scheduler to distribute the job to the workers (see page 19, lines 23-29).

2.3 It is disclosed that the individual tasks can be encoded and transmitted to the scheduler separately (see paragraph bridging pages 19 and 20 and figure 3: Task 1 ... Task N), or that the job can be distributed as a whole (see esp. page 20, lines 30-31). The claimed invention is limited to the latter alternative.

2.4 If the job is transferred as a whole, the scheduler may send information "on the designation of [the] tasks in the job" too so that the individual workers know which tasks to process (see page 20, lines 31-33, and page 21, lines 4-5).

2.5 The application stresses the importance of encoding "job objects" in a "portable format" so that any scheduler "can handle the job or tasks regardless of the platform structure", or the "architecture", of the scheduler (see page 3, lines 14-16, and the paragraph bridging pages 18 and 19). As described above, it appears not to be necessary for the scheduler to access the encoded job object since all the information necessary for the scheduler to do its job is transferred separately from the job object. For the scheduler, that is, the format of the job object is immaterial. The workers however are supposed to support the same environment as the client and hence be able to process the tasks of the job, once decoded (e.g. MATLAB; see paragraph bridging pages 9 and 10, and page 21, paragraph 1).

2.6 As an example of a portable format, the application refers to the MAT-file format as used in the MATLAB environment, in particular for serialisation using the "save" and "load" commands (see page 6, lines 9-10; lines 13-17, page 19, lines 1-3, and page 21, lines 1-2).

Article 123(2) EPC

3. The board is satisfied that the subject-matter of the amended claims was disclosed in the application as originally filed. A basis for the claim language is found in the passages just summarised, more specifically: as regards the encoding of the job object to a continuous byte stream, see page 19, lines 2-3; as regards the information on the job based on which the scheduler distributes it, see page 19, lines 23-28; and as regards the workers receiving designation information, decoding the job object and restoring the original job object, see page 20, line 27, to page 21, line 8.

Clarity, Article 84 EPC 1973

4. The decision is based solely on lack of clarity.

4.1 Architecture-independence

The then claims 1, 7 and 13 were objected to (reasons 1.1.1) because the feature that the "portable job format" was "independent of an architecture of the plurality of different schedulers" was impermissibly claimed "in terms of the result to be achieved".

This objection has become moot vis-à-vis independent claims 1 and 7 because the language referring to the job format's independence of a number of undefined schedulers has been deleted. Moreover, the term "portable format" has been deleted from claims 1, 5 and 7. That it is still used in claims 3, 4 and 6 without antecedent in the higher-ranking claims is a marginal problem which remains to be corrected. The skilled person reading these claims would, however, understand that the term related to the format into which the "job object" was "encoded" and that it was "portable" in the sense that the job was passed over a network from the client through the scheduler to the workers for execution.

4.2 Job distribution

Similarly, it was argued (reasons 1.1.2 and 1.2.1, C2) that the then claims 1, 6-7 and 13 were impermissibly claimed in terms of the result to be achieved due to the features "the information allowing the scheduler to cause the job object in the portable format to be distributed to the at least one worker" and "breaking the job down into a plurality of portable format files".

While it is true that neither the "information" is defined in the claims nor the way in which the scheduler uses it for the distribution of the job, this is, in the board's view, a matter of permissible breadth rather than of impermissible lack of clarity (or result to be achieved). In passing, the board notes that the application as a whole contains very little detail about the distribution. The present claims no longer refer to a "breaking [of] the jobs" into parts, so this objection has become moot, too.

4.3 Job object creation

It was found that whether the claimed creation of the job object was fully automated or required user intervention was undefined (reasons 1.2.1, C1). This caused a lack of clarity because a method step "carried out by a human programmer [could] not be used to cha­racterise the technical subject matter of" the claims "because the input data received from a user [did] not characterize the system receiving the user input".

The board agrees with the decision that the independent claims do not imply from where the "instructions to create a job object" are received, and hence do not exclude their being received from a human operator. The board does not, however, consider this to be a clarity problem. The claimed subject-matter is limited by this feature insofar as the "technical computing client" must be equipped to "receive instructions", irrespec­tive of whether they are input by a human operator or not, and, in response, to "create a job object".

4.4 Job object transfer

The examining division also took issue (reasons 1.2.1, C2) with the features of the then claims 1, 7 and 13 according to which a job object was transferred "via a network of the distributed computing environment", along with "information allowing [...] the job object [...] to be distributed", because it was not defined (a) to which target system the job object was sent, (b) which scheduler was selected and how, and (c) how the "information" allowed the distribution of the job object.

It is now specified in the independent claims that the "request" received at the interface indicates which scheduler is selected and that, hence, the selection of the scheduler must have taken place before that. The claims do not contain a selection step and thus leave open how or when the selection has been made. The claims now specify that the job object is sent as a whole and with "designation" information to the workers. It is not claimed how the scheduler produces the designation information - just as, in fact, the specifics of the designation appear to be missing from the application as a whole, too. Again, however, the board considers this not to cause a clarity problem but to be a matter of breadth.

5. In the board's view, claim 1 now specifies an architecture for the distribution of a "job object" containing "tasks" from a "client" via a "scheduler" to a number of "workers" for execution. The transfer from the client to the scheduler is controlled by information which is undefined except from being separate from the "job object" itself; the transfer execution of the job object by the worker is controlled by "designation information". The format into which the job object is encoded is undefined but must be such that it allows the claimed transfer. This claim still is rather broad but, in the board's judgment, clear.

Remittal for further prosecution

6. The only objection on which the refusal is based has thus been overcome.

6.1 At this point, Article 111(1) EPC gives the board discretion to decide whether to continue examination of the case or to remit it to the examining division for further prosecution.

6.2 The decision was based solely on lack of clarity and the present claims are considerably amended over the ones subject to the decision, so that the inventive step of the present claims has effectively not been discussed before the examining division, and certainly not exhaustively.

6.3 Moreover, the board notes that the new feature by which the job is transferred to the worker as a whole and with designation information was not in the claims as originally filed. The board is therefore not in a position to ascertain that the subject-matter of the amended claims was covered by the search and would therefore be unable to come to a positive conclusion on inventive step in the sense of Article 56 EPC 1973, even if it were to keep the case.

6.4 In view of these facts, the board exercises its discretion by remitting the case to the examining division for further prosecution.