T 0935/14 (Associated accounts/BLACKBERRY) 28-04-2021

Reasons for the Decision

Admittance (Article 13(2) RPBA 2020)

1. The request filed with the grounds of appeal was an amended version of a request refused by the Examining division for lack of clarity and added matter. While the Board, in its provisional opinion, found that some objections were overcome by amendment, or not valid, it maintained part of the clarity objections under Article 84 EPC, and it formulated a new objection under Article 83 EPC.

2. The current request responds in part to that latter new objection. This is seen as an exceptional circumstance warranting the admittance of the request.

The invention

3. The invention relates to providing access to messaging services normally accessed from (trusted) mobile devices. Such a mobile device is said to have a primary account associated with it (paragraph 58), allowing access to a messaging application on the server (paragraphs 39 and 40).

4. According to the application, it would be beneficial for the user to be able to access the application from terminals (e.g. a desktop computer) providing ease of use (keyboard, larger screen etc.) - see paragraphs 2 and 3 of the description. The invention proposes enabling such use by using the mobile device to request the server to create associated accounts for the terminal. Three types are exemplified: a hosted account (paragraphs 59, 63, 64, figure 2A), a temporary account (paragraphs 60, 65, figure 2B), and a meta account (paragraphs 61, 66, figure 2C). All these accounts provide access to the messaging service from the terminal, as long as the terminal-mobile device connection is maintained (paragraph 21). This is said to provide flexibility, and security for the primary account (paragraph 58).

Clarity (Article 84 EPC)

5. Claims 1 and 2 of the sole request on file define methods comprising steps corresponding to the creation of an associated account, including a definition of the three types of associated accounts, and a final step of providing access to the messaging services using the created associated account. Upon reading the claims, the Board made the following provisional observations.

6. It is not clear what is the structure and content of the three types of associated accounts, i.e. what is actually stored on the server.

6.1 The claims distinguish the three accounts only on the basis of their name, and of the content of the messages that would go through those accounts, which are said to include unique identifiers. These identifiers are:

- hosted account: identifier unique to the mobile device

- temporary account: temporary unique identifier associated with the mobile device and the terminal device

- meta account: unique identifier based on unique identification data associated with the mobile device.

On the basis of this wording, no difference can be identified between at least the meta and the hosted types.

6.2 An associated account (any of the three types) is further said to be created using identification data relating to the terminal device and the primary account associated with the mobile device. This expression defines neither what is actually stored when creating the account, nor how the three types of accounts are distinguished.

7. It is also not clear how, and if, the associated accounts are used. These accounts are said to be associated with a primary account for said mobile device. Message formats for the primary account are not defined, but one possible, even standard, option, is to use a device identification number (see paragraph 54), i.e. the same messaging scheme as for the hosted and meta accounts. This raises the question as to how can the server distinguish between messages formatted for an associated account (e.g. hosted or meta) and the ones for the primary account, in particular when the messages come from the mobile device itself, as according to claim 1 (see also paragraph 63 describing the hosted account: "With a proxy implementation, commands/instructions/messages from computer 116 may appear to server 114 as originating from device 108c".). If this is not possible, are the associated accounts used at all, or do all messages go through the primary account in this context?

8. The appellant acknowledged that there was overlap between the definitions of the associated accounts, and acknowledged that the claim language left the possibility that account creation was redundant, i.e. that the messages might go through the primary account. According to claim 2 though, one could differentiate messages based on the (third) communication link used, so messages coming from the terminal would have to go through an associated account.

9. The appellant argued that the claim might be considered broad in its definitions, including overlapping or redundant implementations, but that this was not a problem of clarity. The scope of the claim needed to be clear, which was the case here. One would know whether a certain method was covered by the scope of the claim or not, there was no need to detail the embodiments in the claim. The claim required, upon request from the mobile device, the creation of an associated account, using mobile and terminal information, defined the three types of accounts, and required a corresponding certain format of messages, and further required that the associated account be used. All this could be verified, because the wording of the features, though broad, was clear.

10. The Board disagrees with the appellant's conclusions for the following reasons. Under the EPC, claim construction is not a purely linguistic exercise. The board endorses the established case law according to which it is the skilled person who will construe the claim with a mind willing to understand such as to arrive at a claim interpretation which is technically sensible (see Case Law of the Boards of Appeal, 9th edition, II.A.6.1, esp. the first paragraph). If such an interpretation is not possible, then the claim is not clear.

10.1 In view of the appellant's argument that the features are worded clearly, the Board further notes that a prerequisite for arriving at a technically sensible claim interpretation is that the claim is technically consistent: if two features are separately clear, but are inconsistent with each other from a technical point of view, then their combination, and the claimed matter, cannot be clear.

10.2 The Board agrees with the appellant that broad features may be considered clear, but only under the proviso that the borders of the - broad - scope of protection can be clearly inferred by the skilled person. This makes the distinction between broad but clear and broad and vague. If a feature formulation is such that some further technical features appear to be implied, particularly in view of the features' technical function, but it is not clear what those precisely are, then the claimed feature is vague and not clear.

11. In the present case, the claim fails on more than one account in view of the above considerations.

11.1 As detailed before (point 6), the three types of associated accounts are not clearly distinguished. In the Board's judgment it is unclear to the skilled person whether the overlap between the three definitions was intended or not. If it were, the technical purpose of specifying two indistinguishable accounts (hosted and meta) would be technically questionable and, arguably, render claims 1 and 2 inconcise, Article 84 EPC. If it were not, the question would arise as to which other features might be implied - esp. by the terms hosted or meta - so that the accounts could be effectively differentiated.

11.2 A minimal claim construction, i.e. with no further implied features, would also be technically inconsistent: for instance, in that a hosted account is created to be used for messaging by the terminal, but is actually not used (point 7 above). This raises the question as to which other features may be implied, either as message formatting, or upon the server side, or both, so that the account is used.

11.3 The (intended) answer may lie in the account creation steps. But, as noted above, the creation steps are vaguely defined. For instance, under a literal reading, an account creation wherein the server merely checks whether the identification data relating to the terminal device is properly formatted falls under the claim scope. But then, the question arises how this account can be used, as required by the claim? For the claim to make technical sense, some further technical features need to be read into the claim. It is not clear which those are.

12. The Board concludes that claims 1 and 2 of the sole request lack clarity in the sense of Article 84 EPC.