T 1148/11 (Remote file attachments/BLACKBERRY) 07-08-2014

1. The appeal is admissible.

2. Non-attendance of the appellant at oral proceedings

2.1 The appellant decided not to attend the scheduled oral proceedings before the board (cf. point VI above). Pursuant to Article 15(3) RPBA, the board is not "obliged to delay any step in the proceedings, including its decision, by reason only of the absence at the oral proceedings of any party duly summoned who may then be treated as relying only on its written case".

2.2 In the present case, the board reconsidered its objections raised in the board's communication under Article 15(1) RPBA (cf. point III above), taking into account the last written submissions made with the letters dated 7 July 2014 and 5 August 2014 (cf. points IV and VI above and points 3.1.2 to 3.1.43.1.4 below), and was in a position to take a decision at the end of the oral proceedings held in the absence of the appellant, in the exercise of its discretion according to Article 15(3) RPBA.

3. MAIN REQUEST

This request was filed in response to the objections raised in the board's communication under Article 15(1) RPBA, and claim 1 of this request differs from claim 1 of the auxiliary request underlying the impugned decision essentially in that it now specifies that the corresponding file browsing service is requested in response to receiving the user instruction.

The board is satisfied that this amendment is supported by the disclosure of paragraphs [0036] and [0037] in conjunction with Fig. 4 of the application as filed and thus complies with Article 123(2) EPC.

3.1 Article 52(1) EPC: Novelty and inventive step

In the board's judgment, claim 1 of this request does not meet the requirements of Article 52(1) EPC in conjunction with Article 56 EPC, for the following reasons:

3.1.1 The board concurs with the finding of the decision under appeal in considering D1 as the closest prior art for the subject-matter claimed. Like the present invention, D1 is concerned with remote file attachments to e-mail messages sent via a wireless system and discloses, with regard to the phraseology of claim 1, the following features (as labelled by the board):

A method in a wireless hand-held device of composing an e-mail message that will include a remote file attachment (see e.g. page 422, section 3.2.1 in combination with Fig. 11), comprising:

a) receiving a user instruction to attach a file ("F1") to an e-mail message for a recipient (see page 420, right-hand column, fourth paragraph, second sentence: "... the mobile user wants to send an email to another user 'plin' with subject 'Hello', content 'test', and 'F1'.");

b) requesting a file browser service ("file explorer application") from a file delivery server ("CIFS server") via a network to obtain a list of files in a directory (see e.g. page 423, section 3.3 in conjunction with Fig. 14, step 3);

c) if file access credentials are required to access the directory, prompting for file access credentials ("password") needed to access the directory (see page 420, right-hand column, third paragraph, fifth sentence: "... to login on WIRAP with ID 'plin' and password '1234', the mobile user needs to send a short message: login plin 1234 ..." in connection with Fig. 10, step 1 and Fig. 14, step 3.2.3) and furnishing the file access credentials to the file browsing service (see page 424, right-hand column, first paragraph: "... The RAPshell object invokes the ... CIFSHandler ... to connect to the CIFS server and passes the user ID and password for authentication ..." in conjunction with Fig. 14, steps 3.2.4 and 3.2.5);

d) presenting the list of user-accessible files from a directory ("Dir1") selected by the user using a user interface of the wireless hand-held device (see e.g. page 424, right-hand column, fifth paragraph: "... The RAPshell invokes the ... CIFSHandler to retrieve the name list of directories and files from the directory (linked by ... directory 'Dir1') on the remote CIFS server" in combination with Fig. 14, steps 3, 5.4, and 6);

e) receiving another user instruction to send the

e-mail message, along with a file ("F1") from the list of files to attach to the e-mail message (see e.g. page 422, left-hand column, first paragraph: "... the mobile user uses the a-Mail application to send a mail (with the ... attached file 'F1') ..." and page 420, right-hand column, message (2): "Hello plin test F1" Fig. 11, step 1);

f) sending, to a mail agent ("MailClient"), a portion of the e-mail message and an attachment instruction identifying the file (file name "F1")(see e.g. Fig. 11, steps 1 and 1.3),

g) wherein the attachment instruction causes the mail agent to assemble a complete e-mail message comprising the portion of the e-mail message and the file identified in the attachment instruction using the file delivery server (see page 422, left-hand column, last paragraph to right-hand column, first paragraph: "... The MailClient invokes the ... RAPShell ... to get the path where the file 'Fl' locates in the personal disk quota. At this step, the file 'Fl' is attached in the mail" in combination with Fig. 11, steps 1.3.3 and 1.3.4).

3.1.2 The board agrees with the appellant (cf. appellant's letter of reply dated 7 July 2014, page 6, third and fourth paragraphs) that the difference between the subject-matter of claim 1 and the disclosure of D1 consists in that (emphasis added by the board)

i) requesting the file browsing service on the file delivery server is performed in response to receiving the user instruction to attach a file to the e-mail message in step b)b) ;

ii) the attachment instruction sent to the mail agent also comprises the file access credentials in step f)f) ;

iii) the complete e-mail message is assembled by the mail agent using the file delivery system and the file access credentials in step g)g) .

Consequently, the subject-matter of claim 1 of this request is held to be novel over D1 (Article 54 EPC).

3.1.3 As to distinguishing features ii)ii) and iii)iii) , the board finds that sending the file access credentials more than once to the file delivery server, i.e. not only for login on WIRAP in the file selection phase but also in the e-mail sending phase, constitutes one of several equally likely implementation measures for performing authentication in the field of mobile messaging. This measure is, moreover, solely dictated by practical constraints such as the desired security level, bandwidth efficiency or implementation complexity. Therefore, the board considers that the skilled person would apply such a solution, based on the applicable circumstances, without exercising inventive skills. This observation was communicated to the appellant in the board's communication under Article 15(1) RPBA and was not contested by the appellant in its letters of reply dated 7 July 2014 and 5 August 2014. In view of the above, authenticating the file access credentials more than once according to features ii)ii) and iii)iii) cannot contribute to an inventive step.

3.1.4 As to distinguishing feature i)i) , i.e. requesting a list of files via a remote file browser service in response to the user instruction to attach a file to an e-mail message, the appellant argued that it had the effect that the corresponding list of files provided to the user was up-to-date because that list was provided after the user had begun composing an e-mail message. Therefore, the claimed invention provided for dynamic and real-time remote file browsing for attaching a file to an e-mail being composed, so that the user is provided with the ability to attach any currently available file on the remote server to the respective e-mail message, including new files that have been added to the file server since the user last browsed, rather than only those files which are available on the mobile device through a previous use of the browser application according to the teaching of D1. The technical problem solved by the claimed invention was therefore "how to provide, in a wireless hand-held device, a more efficient and flexible method of composing an e-mail message with a file attachment" (cf. appellant's letter of reply dated 7 July 2014, page 6, penultimate paragraph to page 7, fourth paragraph). However, the board cannot accept that such technical effects may credibly be derived and that such a problem be solved based on feature i)i) , for the following reasons.

3.1.5 According to the wording of claim 1, the attachment of a file selected via the file browsing service to the

e-mail message takes place upon receipt of "another user instruction" (see step e)e) above). This implies in turn that the question whether the corresponding list of files is up-to-date or whether dynamic and real-time remote file browsing is indeed enabled hinges entirely on the receipt of that "another user instruction" rather than on the receipt of the "user instruction to attach a file to an e-mail message" according to feature i)i) . In other words, if the "another user instruction" is generated and received long after the generation and receipt of the "user instruction to attach a file to an e-mail message", all the alleged technical effects or advantages may self-evidently not be achieved. Also, feature i)i) does not credibly contribute to the solution of the technical problem of providing "an e-mail system for use with wireless

hand-held devices that allows the attachment to e-mail messages of files arbitrarily selected by the user, while minimizing transport of attachment content over the wireless network" according to the present application (cf. paragraph [0008] of the description as filed) or of "providing, in a wireless hand-held device, a more efficient and flexible method of composing an e-mail message with a file attachment" as formulated by the appellant. This is due to the fact that those problems are not causally solved by a specific ordering of the file attachment request and the initiation of the file browsing service, as implied by feature i)i) . Rather, they are already solved by the other features of claim 1, i.e. basically by attaching remotely a file previously selected by the mobile user to an e-mail message in a secure manner. Therefore, in accordance with consistent case law, distinguishing feature i)i) can only be regarded as an arbitrary feature and is therefore of no relevance for the question of inventive step (see e.g. T 206/91, point 5.5; T 1009/12, point 2.7).

3.1.6 Even if feature i)i) were to credibly contribute to the underlying technical problem, the board sees no good reason why the skilled person in the field of mobile messaging, e.g. in view of possible user needs or preferences, would be deterred from modifying the order or from combining the steps of the a-Mail and the file explorer applications of D1 to enable the wireless user to switch from one application like the a-Mail application initially selected via the application list page (see e.g. Fig. 9(b) of D1) to another application such as the file explorer application.

In this regard, the appellant argued that the present invention used a single transaction to provide a file list from which an e-mail attachment was subsequently selected by the mobile user, i.e. the user only had to log in once to access files after the user has begun composing an e-mail message. In contrast, the system of D1 required multiple transactions, where the file list was first stored at the mobile device before a file was later selected to be sent as an attachment, i.e. the user had to download and store the file list prior to opening the corresponding a-Mail application (see e.g. statement setting out the grounds of appeal, page 3, last paragraph to page 4, first line). However, this line of argument must fail, for basically two reasons. Firstly, it cannot be derived from the method steps recited in claim 1 that the provision of a file list is in fact done within a single transaction, for the same reasons as outlined in point 3.1.53.1.5 above. Secondly, contrary to the assertion of the appellant, D1 merely teaches that the file list is sent to the user and not that the file list is also stored at the mobile device (see e.g. page 424, right-hand column, sixth paragraph: "... The iSMSClient sends the short message containing the name list of directories and files to the user" together with Fig. 14, steps 5.4 and 6).

3.1.7 In view of the above, the subject-matter of claim 1 of this request does not involve an inventive step having regard to D1 and the skilled person's common general knowledge.

3.2 In conclusion, this request is not allowable under Article 56 EPC.

4. FIRST AUXILIARY REQUEST

Claim 1 of this request differs from claim 1 of the main request in that the phrase "in response to receiving the user instruction" has been replaced by the clause "subsequent to receiving the user instruction" (emphasis added by the board).

This amendment can also be derived from the teaching of paragraphs [0036] and [0037] in conjunction with Fig. 4 of the application as filed and is thus compliant with Article 123(2) EPC.

4.1 Article 52(1) EPC: Novelty and inventive step

Since the above amendment merely emphasises that the file browsing service is activated after receipt of the corresponding user instruction as to file attachments and thus does not add anything of substance to the claimed subject-matter, the observations concerning the main request set out in points 3.1.33.1.3 to 3.1.63.1.6 above apply mutatis mutandis to claim 1 of this request.

Hence, the subject-matter of claim 1 of this auxiliary request does not involve an inventive step either.

4.2 In conclusion, the first auxiliary request is also not allowable under Article 56 EPC.

5. SECOND AUXILIARY REQUEST

Claim 1 of this request corresponds to claim 1 of the auxiliary request considered in the impugned decision and differs from claim 1 of the pending main request in that it no longer includes the phrase "in response to receiving the user instruction".

5.1 Article 52(1) EPC: Novelty and inventive step

The feature analysis concerning the main request set out in point 3.1.13.1.1 above applies mutatis mutandis to claim 1 of this auxiliary request. Since, moreover, the difference between present claim 1 and D1 merely consists in distinguishing features ii)ii) and iii)iii) , its subject-matter cannot be considered inventive for the same reasons as given in point 3.1.33.1.3 above.

5.2 In conclusion, the second auxiliary request is likewise not allowable under Article 56 EPC.