T 1553/10 (Bar codes for starting process execution/SONY) of 9.12.2015

Summary of Facts and Submissions

I. The appeal lies from the decision of the Examining Division to refuse European patent application No. 99306100.1 by a "decision according to the state of the file", using EPO Form 2061, referring to the communication dated 12 October 2009. In that communication the Examining Division was of the opinion that the subject-matter of claims 1 to 9 was not inventive over the disclosure of document

D2: US 5 218 699, published on 8 June 1993.

II. In the statement of grounds of appeal the appellant requested that the decision be set aside and that a patent be granted on the basis of the main request considered in the decision under appeal, and resubmitted with the grounds of appeal, or of one of the two auxiliary requests filed with the grounds of appeal.

III. The appellant was invited to oral proceedings. In a subsequent communication sent in advance of the oral proceedings, the Board cited document D2 as well as the the following documents:

D3: WO 98/20411, published on 14 May 1998;

D4: US 5 764 992, published on 9 June 1998;

D5: US 5 331 547, published on 19 July 1994;

D6: EP 0 813 133, published on 17 December 1997.

Documents D3 to D5 were mentioned in the European search report. Document D6 was introduced by the Board.

The Board expressed its preliminary opinion that the subject-matter of claim 1 of the main request was not novel or not inventive over document D3. None of the two auxiliary requests appeared to fulfil the requirements of Article 56 EPC over the disclosure of document D3 in combination with either the standard knowledge of the skilled person or one of documents D2 and D6. In the preliminary view of the Board the auxiliary requests also had deficiencies relating to lack of clarity and added subject-matter. The Board explained the relevance of prior art documents D3 to D6 with respect to features described in the present application.

IV. With a letter of reply the appellant stated that although the request for oral proceedings was maintained, it would not be attending the hearing.

V. Oral proceedings were held on 9 December 2015 in the absence of the appellant. At the end of the oral proceedings, the chairman pronounced the Board's decision.

VI. The appellant requested that the contested decision be set aside and that a patent be granted on the basis of the main request or, alternatively, one of the two auxiliary requests.

VII. Claim 1 of the main request reads as follows:

"An information processing apparatus comprising:

an image acquiring means (23, 81, 82) for acquiring an image (101) representing identification information;

an identification information recognising means (52) arranged to recognise from the image (101) acquired by said image acquiring means, identification information represented by the image;

a decision means (52) arranged to decide whether said identification information recognised by said identification information recognising means is local identification information in response to which the apparatus is arranged to start a local process stored in the apparatus or remote identification information for starting a process in a remote server (300);

a local executing means arranged to execute the said local process if said identification information is local identification information;

a remote processing requesting means (52, 50) arranged to request the remote server to execute the remote process corresponding to said identification information if said identification information is remote identification information; and

a remote processing result acquiring means (50, 52) arranged to acquire the result of said remote processing by said remote server."

VIII. Claim 1 of the first auxiliary request differs from claim 1 of the main request in that the features

"is arranged to start a local process [...] in a remote server (300);", and

"a remote processing requesting means (52, 50) [...] is remote identification information;"

of claim 1 of the main request were amended respectively to

"is arranged to start a local process previously registered and stored in the apparatus or remote identification information for starting a process common to a plurality of apparatuses in a remote server (300);" and

"a remote processing requesting means (52, 50) arranged, if said identification information is remote identification information, to request the remote server to check whether a code corresponding to the identification information is stored on the remote server, and if so to execute, at the remote server, the remote process corresponding to said identification information;".

IX. Claim 1 of the second auxiliary request differs from claim 1 of the first auxiliary request in that the following features have been added at the end of the claim:

"wherein if said identification information is remote identification information, said local executing means first checks whether a valid code corresponding to the identification information is stored at the apparatus, and if so executes the remote process at the apparatus."

Reasons for the Decision

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

The invention

2. The idea of the invention is to let a user of a personal computer start execution of a local or remote program by means of a two-dimensional bar code (2D code).

2.1 According to the description, each 2D code, or the identifier it represents (the 2D code ID), is associated with a program. There are both local and global codes. A local 2D code identifies a local program, whereas a global 2D code identifies a program stored in a global 2D code server connected to the network. The different types of codes use different ranges of values for the 2D code IDs, for example the hexadecimal range 0x010000 to 0x0FFFFF for local 2D code IDs, and the range 0x100000 to 0xFFFFFF for global 2D code IDs (page 32, last full paragraph of the description as originally filed).

2.2 When an image is captured at the personal computer and the image data is recognised as a 2D code, the personal computer acquires the corresponding 2D code ID from the 2D code and determines, on the basis of the range to which it belongs, whether it is a local or a global 2D code ID. If the 2D code ID is local, the personal computer executes the associated local program. If it is a global 2D code ID, the personal computer sends the 2D code ID to the global 2D code server. The server then executes the program and returns the processing result to the personal computer, which then further processes the received processing result (see page 27, third paragraph to page 29, first full paragraph, Figure 12).

2.3 In another described embodiment, an expiration period is associated with a program in the global 2D code server. The program may be downloaded to the personal computer and registered. When its global 2D code is received, the personal computer checks whether the program is registered and whether the expiration time has not been exceeded, and executes it locally if the result of the checks is positive (page 35, first full paragraph to page 41, second full paragraph, Figures 18 to 21).

2.4 The description gives examples of applications of the invention. In a first example, a program stored in the global 2D code server creates the image of a new year's greeting card and returns it to the personal computer where it is displayed (page 31, first full paragraph). According to a second example, a weather forecast program stored at the global 2D code server is sent to the personal computer and registered there with an associated expiration time. Until it expires, each time it is called, the program is executed locally at the personal computer. The expiration time can be set according to the time at which the weather forecast is updated (page 41, last paragraph to page 45, second full paragraph).

Main Request

3. Novelty and inventive step

3.1 In the grounds for appeal, the appellant argued that the objective problem considered by the Examining Division, "how to provide an alternative way of launching processing", did not appear to be a meaningful technical problem in the context of D2. Document D2 related to calling procedures by an application program, procedures being defined in column 1, lines 26 to 30, as program segments such as procedures, functions and subroutines. Document D2 could not be taken out of context by assuming that such procedures could be "launched" in any other way.

The Board agrees that document D2 is not a good starting point for assessing inventive step of the present invention, as it is not directed to the same purpose as the invention of launching processes by a user.

3.2 Document D3, on the contrary, discloses a system which reads a machine-readable code printed on a document in order to provide automated access to information stored in a database in either a local or a remote location, or to launch a program (page 3, line 21 to page 4, line 17) and is therefore directed to a purpose similar to that of the present invention. Document D3 is therefore an appropriate starting point for the assessment of inventive step.

3.3 Figures 3 and 4 of document D3, where Figure 4 shows in detail the de-obfuscate block 37 of Figure 3, give an overview of the functioning of the system, as described on page 15, line 18 to page 18, line 11, and throughout document D3. The machine-readable code 12 may be a two-dimensional bar code (page 4, line 19 to page 5, line 13) and "comprises encoded source data, wherein the source data comprises application launch information as well as file location information" (see Figures 3 and 4, file location pointer 21 and launch application command 22; page 3, lines 27 to 29; page 14, lines 20 to 27).

In the system of document D3, when a user scans the machine-readable code with a computer input device, such as a two-dimensional bar code scanner coupled to the client computer, the input device "transposes an input data string from the machine readable symbol" (Figure 3, bar code scanner 34; page 15, lines 20 to 23; page 4, lines 26 to 29). The resulting string is decoded and de-obfuscated to generate a "clear data string" comprising several fields for identifying the file to be returned, the program to be launched and additional parameters for generation of a document (Figures 3 and 4, reference signs 34, 36 and 37; page 15, line 23 to page 16, line 10; page 19, lines 9 to 15).

Therefore, document D3 describes an information processing apparatus comprising image acquiring means (bar code scanner 34 of Figure 3) and identification information recognising means (process/decode 36 and deobfuscate 37 of Figure 3) as recited in claim 1 of the main request. The "clear data string" obtained from the machine-readable code, corresponding to the output from blocks 36 and 37 of Figure 3, constitutes "identification information represented by the code image" of claim 1.

3.4 The clear data string is parsed to extract the fields, which may include a launch command, a file location pointer, a user demographics field, a source ID, a key, and a code type field (see Figures 3 and 4, page 16, lines 5 to 10; Figure 2, page 10, lines 8 to 22).

The launch command is "an executable command to launch a software utility resident on the client computer" (page 7, lines 23 to 27). The software utility, for example an Internet browser or a word processor, is automatically launched when the code is read (page 7, line 23 to page 8, line 2; page 3, lines 27 to 29; Figure 3: launch application 22, application program 92, Internet browser 40). Therefore, the apparatus of document D3 also includes local executing means as recited in claim 1 of the main request.

3.5 As described on page 5, the file location pointer may be in the form of a uniform resource locator (URL), and may be used to access a file either locally or remotely in a target server computer (page 5, lines 15 to 30). The file location pointer and the launch command can be used together to obtain a document from a website (page 10, lines 14 to 20, page 11, line 27 to page 12, line 13), or for launching an application and simultaneously passing a particular document to the application, for example to edit a document (page 14, lines 8 to 27). The same features are disclosed with reference to the embodiment of Figure 3. As shown in that figure, the launch application command 22 is sent from the parse module 34 to the Internet browser 40 or to the application program 92. The file location pointer and other fields are assembled into a file transfer request 90 and then sent to the appropriate interface in order to obtain the requested file (page 16, line 22 to page 17, line 13; page 17, lines 28 to 30; Figure 3: file location pointer 21, file transfer request 90). The interfaces are the Internet browser 40, the local area network (LAN) interface 96, and the local memory 94. In order to send the request to the appropriate interface, a decision takes place.

The system of document D3 supports complex requests to a Web server, such as requests involving decrypting sensitive user information or customising a document for a specific user at the remote server (page 6, line 5 to page 7, line 21). In those requests, the machine-readable code includes further information, for example information for determining a decryption key from a lookup table at the server, or information about the user or the targeted group of users. In an example given on page 7, lines 14 to 18, the decrypted user information includes a credit card number of the user of the client computer to be used in an online electronic transaction at the server. In other examples, the server adapts the result of the request to a target user group or to the user's preferences, for example with regard to the language of the document (page 7, lines 18 to 21, page 19, lines 9 to 24).

It is clear that those requests involve the execution of remote processes at the remote server. The further information is also included in the file transfer request to be used in further processing by the target server, for example for decrypting encrypted sensitive user information at the remote server (page 6, line 5 to page 7, line 21), or for dynamically generating the file or files to be sent back to the client computer on the basis of the further information (page 19, lines 9 to 24). Since the client computer prepares the computer file request and sends it to the target server for execution of the remote process, document D3 discloses remote processing requesting means (Figure 3: launch application 22, Internet browser 40, file transfer request 90).

3.6 After processing the request, either locally or remotely, the result of the request is received by the client, for instance for being displayed (page 12, lines 6 to 13, Figure 3: "returned file", page 19, lines 9 to 11). The system of document D3 hence also comprises remote processing result acquiring means (Figure 3: browser 40, application program 92).

3.7 Depending on the launch application command and the content of the file transfer request, the request is processed locally or remotely by a different application. Therefore, the system of document D3 also includes decision means for deciding which process to execute, which is schematically represented by the lines "file transfer request" 90 and "launch application" 22 of Figure 3 (page 17, line 28 to page 18, line 11).

3.8 Taking the above into account, the Board has strong doubts that the subject-matter of independent claim 1 is novel over the apparatus of document D3.

Nevertheless, the Board notes that the decision means of the apparatus of document D3 decides primarily which application to launch locally, and only decides indirectly whether the source data, or identification information, is local or remote. The decision involves several steps, including, for instance, sending the file transfer request to one of three interfaces, or having the Internet browser send a request to a remote server.

Interpreting the decision means of claim 1 in the light of the description, the claimed apparatus can be considered to differ from the apparatus of document D3 in that the decision means directly decides on the basis of the identification information whether a remote or a local process should be started.

Such a modification could be useful, for instance, if pre-processing specific to remote or local identification information was necessary. In some embodiments described in the application, such a distinguishing feature has the advantage of allowing, in case the identification information is global (or "remote" in the language of the claim), checking whether the global process is registered and can be run locally. However, these features are not recited in claim 1 of the main request.

In the opinion of the Board, the distinguishing feature hence corresponds to a minor obvious modification of the implementation of the decision means of document D3, which would be adopted by the skilled person, depending on the circumstances, as a matter of routine work. In particular, it would be obvious for the skilled person that, in order to be able to perform specific remote or local pre-processing, the decision means had to be able to determine directly whether the identification information was for a local or a remote process.

3.9 From the above, the Board concludes that the subject-matter of claim 1 of the main request does not involve an inventive step (Articles 52(1) and 56 EPC).

First auxiliary request

4. Claim 1 of the first auxiliary request differs from that of the main request essentially in that it further defines that

(a) the local process is previously registered and stored in the apparatus, and

(b) the remote process is common to a plurality of apparatuses,

and in that

(c) the request of the remote processing requesting means to the remote server is to check whether a code corresponding to the identification information is stored on the remote server, and if so to execute, at the remote server, the remote process.

5. Inventive step

5.1 Since any file system registers the applications or programs stored locally, feature (a) as defined in the claim can be considered to be implicitly disclosed in document D3.

Taking the description into account, the registration of processes appears to be used only in connection with downloading processes from the remote server to the local system. It is used for deciding whether to run the process locally or whether to download the program from the remote server (page 43, first full paragraph to page 45, second full paragraph, Figure 21). However, the claim does not specify those features. Feature (a) therefore cannot be distinguished from the usual registration implicit in document D3.

5.2 Feature (b) is not a limiting feature of the claimed apparatus because claim 1 is directed to the local information processing apparatus, and feature (b) relates to the remote server. In any case, the remote process in document D3 is also "common" to a plurality of apparatuses (feature (b)), since the programs of the Web server can be called by a plurality of clients.

5.3 The appellant argued, with regard to the first auxiliary request, that document D2 did not disclose feature (c). The technical effect associated with this feature was that there was no need to keep the local node updated with identification information relating to centralised processes. The claimed apparatus could therefore be considered to solve the technical problem of simplifying the library updating process at the local node.

In the opinion of the Board, this argument is not convincing, because the question of whether to keep local information relating to centralised processes or to request the information from a remote server reflects an obvious trade-off. In any case, the argument does not apply with respect to the apparatus of document D3, since it does not need to keep more information locally than the claimed apparatus. Furthermore, the argument of the appellant might be based on an interpretation of feature (c) according to which the request for checking is performed independently of the request for execution. However, that interpretation cannot be derived from either the wording of feature (c) or the disclosure of the application as originally filed.

In the opinion of the Board, each request for execution of a process in a remote server will cause the server to automatically check whether the process exists. Since the claim does not further define the code, that automatic check can be seen as "a check whether a code corresponding to the identification information is stored". Feature (c) can therefore be considered to be implicitly disclosed in document D3.

5.4 From the above it follows that the subject-matter of claim 1 of the first auxiliary request is not inventive (Article 56 EPC).

Second auxiliary request

6. Claim 1 of the second auxiliary request adds to claim 1 of the first auxiliary request the following feature:

(d) if said identification information is remote identification information, said local executing means first checks whether a valid code corresponding to the identification information is stored at the apparatus, and if so executes the remote process at the apparatus.

7. Added subject-matter

7.1 The appellant indicated page 42 of the description as the basis for feature (d). Page 42 describes features of the embodiment of Figure 21, the complete embodiment being explained in the passage from page 38, first full paragraph, to page 45, first full paragraph. In the opinion of the Board, feature (d) is described on page 44, last full paragraph to page 45, first line, and corresponds to the sequence of steps S15a, S20a and S19a of Figure 21. However, in the embodiment of Figure 21 the global process is never executed in the remote server, whereas according to claim 1 a process from a remote server, the "remote process", is executed remotely if a valid code is not stored locally. The embodiment of Figure 21 discloses instead that in that case the global or remote process is downloaded, registered, and run locally (steps S15a to S19a of Figure 21). The appellant did not provide any further support for the amendment, and the Board could not identify any embodiment combining remote execution of global processes and local execution of global processes with a valid code.

7.2 Therefore, the particular combination of features of claim 1 cannot be directly and unambiguously derived from the application as filed, and claim 1 of the second auxiliary request infringes Article 123(2) EPC.

8. Inventive step

8.1 Claim 1 of the second auxiliary request is directed to an apparatus which executes a process from a remote server either locally, if a valid code for it is stored (locally) at the apparatus, or remotely at the remote server. The phrase "valid code ... stored at the apparatus" is interpreted on the basis of the description as meaning that the process has been downloaded previously, is registered, and has not expired (Figure 21, steps S15a and S20a).

8.2 The Board considers that, at the time of priority of the present application, it was well known in the art, for example in the area of distributed processing, to execute a process either locally or remotely (e.g. Java applets, see also D6, column 1, lines 17 to 19). The skilled person was also acquainted with the possibility of loading such a program from a remote server, registering it, and later executing it locally whenever needed.

8.3 The Board is therefore of the opinion that the apparatus of claim 1 of the second auxiliary request is not inventive (Article 56 EPC).

Concluding remarks

9. Since none of the requests on file is allowable, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.