T 2519/11 (Info card selector/APPLE) of 13.9.2016

European Case Law Identifier: ECLI:EP:BA:2016:T251911.20160913
Date of decision: 13 September 2016
Case number: T 2519/11
Application number: 09152616.0
IPC class: G06F 21/20
H04L 29/06
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 326.857K)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: Info card selector reception of identity provider based data pertaining to info cards
Applicant name: Apple Inc.
Opponent name: -
Board: 3.5.06
Headnote: -
Relevant legal provisions:
European Patent Convention Art 56
Keywords: Inventive step - both requests (no)


Cited decisions:
T 0641/00
Citing decisions:

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, with reasons dispatched on 27 June 2011, to refuse European patent applica­tion No. 09 152 616.0 for lack of inventive step over the combination of the documents

D4: Nanda A, Microsoft Corporation, "Identity Selector Interoperability Profile V1.0", April 2007, and

D5: Anon, Microsoft and Ping Identity Corporations, "An Implementer's Guide to the Identity Selector Interoperability Profile V1.0", April 2007.

II. Notice of appeal was filed on 29 August 2011, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 26 October 2011.

III. The board understands the appellant's requests to be that the decision be set aside and that a patent be granted based on claims 1-15 as filed on 31 March 2011 (main request), or on only claims 1-6, filed as an auxiliary request with the grounds of appeal, in combination with the documents presently on file, namely:

description, pages

8-13 as originally filed,

1-5, 7 filed on 25 November 2009

6 filed on 31 March 2011

drawings, sheets

1/11-11/11 as originally filed.

IV. Claims 1 and 7 of the main request read as follows:

"1. An apparatus, comprising:

a receiver (210) at a card selector (205) to receive a request for an information card (220), said information card (220) being used to request a security token (160) from an identity provider (135), the security token (160) including data a user wants released to a relying party (130) in an on-line transaction;

an identifier to identify metadata (240) applicable to said information card (220), wherein said metadata includes at least one of data pertaining to the last time the information card was used, the frequency with which the information card is used, whether the information card was last used successfully, a balance associated with the information card, state of the user's account (710), advertisement (705), or policy update (715);

a metadata engine (245) adapted to use said metadata (240) in support of a response from said card selector (205) to said request for said information card (220),

wherein said information card (220) is used to request said security token (160) from said identity provider (135), and said security token (160) is transmitted to said relying party (130).

7. A method for using metadata, comprising:

receiving (805) at a card selector (205) a request for an information card (220), said information card being used to request a security token (160) from an identity provider (135), the security token (160) including data a user wants released to a relying party (130) in an on-line transaction;

identifying (810) metadata (240) applicable to the information card (220), wherein said metadata includes at least one of data pertaining to the last time the information card was used, the frequency with which the information card is used, whether the information card was last used successfully, a balance associated with the information card, state of the user's account (710), advertisement (705), or policy update (715);

using (815) the metadata (240) to support a response from the card selector (205) to the request for the information card (220), so that the user can use the metadata (240) in selecting the information card (220);

requesting the security token (160) from the identity provider (135) using the information card (220); and

transmitting the security token (160) to the relying party (130)."

Claim 1 of the auxiliary request is identical with that of the main request.

V. In the annex to a summons to oral proceedings, the board informed the appellant of its preliminary opinion that the independent claims of both requests lacked inventive step over D4, Article 56 EPC. A few clarity objections were also raised, Article 84 EPC.

VI. In response to the summons, no amendments or arguments were filed. Instead, with a letter dated 22 July 2016, the representative informed the board that he had been instructed by the applicant not to attend the oral proceedings. According­ly, at the oral proceedings on 13 September 2016 the appellant was not represented.

VII. At the end of the oral proceedings, the chairman announced the decision of the board.

Reasons for the Decision

Appellant's absence from oral proceedings

1. The appellant was duly summoned but chose not to attend the oral proceedings. According 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. The following reasons are based on the board's preliminary opinion as set out in the annex of the summons to oral proceedings.

The invention

2. In general, the application relates to "identity management" for users conducting online transactions (see e.g. description, page 2, paragraph 2).

2.1 The application observes that users may want or have to provide different bits of their "identity" to diffe­rent service providers on the Internet (see for instance page 2, lines 11-14, and page 5, paragraph 1). Some service providers (in the appli­cation more gene­rally referred to as "relying parties") may require no more than an email address, others may insist that an officially validated license be submitted. And users may have good reason to dis­close no more than ne­cessary to the relying party. To help users manage their "identities", Microsoft has developed a system called CardSpace (see page 4, last paragraph to page 5, paragraph 1).

2.2 In CardSpace, the user can have several "information cards", each of which con­tains different kinds and amounts of information about the user and may be thought of as representing a different "identity" of the user.

2.3 When a relying party requests identity information and/or cre­dentials according to its security policy, the user selects a suitable one of his information cards and requests an "identity ser­ver" to provide a suitable secu­ri­ty token on his behalf (see fi­gure 1). The security token will contain the relevant iden­ti­ty "claims" and be encrypted and/or signed (see page 5, paragraph 2).

2.4 The application is concerned with improving the CardSpace system by making additional "meta­data" "about the information card" available for the user to take into account in order to make a fully informed decision when selecting the infor­mation card (see page 5, penultimate paragraph to page 6, paragraph 1; see also pages 2 and 10, penultimate paragraphs).

2.5 Metadata can be data about the last time a particular card was used (at all or successfully), usage fre­quen­cy, card expiry date etc. (see page 6, para­graph 3). Metadata can also contain an advertise­ment (see page 10, lines 22-24).

The prior art

3. D4 and D5 are separate documents on different aspects of a software product called "Identity Selector Inter­ope­rability Profile", in its version "V1.0", used by Windows CardSpace (see e.g. the note at the bottom of page 1 in D5). D5 discloses more details about the overall architecture of the system and the protocols used (see esp. figures 1-3), whereas D4 discloses more detail about the metadata (pages 10-11 and 33).

3.1 The examining division noted that D4 and D5 refer to the same software pro­duct and therefore considered D4 and D5 in combi­na­tion to constitute the closest prior art (see decision, facts 2, last paragraph, and reasons 11, paragraph 2).

3.2 As the board understands this approach, it means starting the assessment of inventive step from the software product described in D4 and D5 rather than from D4 and D5 themselves. This approach relies on the assumption that both D4 and D5 contain accurate and consistent information about the software product. Although difficult to validate, this assumption is plau­sible, inter alia because D4 and D5 refer to the same version of the same software product. The board also notes that the appellant did not challenge the approach.

3.3 Nonetheless, the board prefers to start the assessment of inventive step from one document only, namely D4. This avoids the need to rely on mere plausibility assumptions regarding the prior art. Moreover, no reference to D5 is necessary for the present decision.

4. D4 discloses a "service requester" acting on behalf of a party (i.e. a "user") who wants to obtain a service from some network entity also referred to as a "relying party" (see page 3, last two paragraphs).

4.1 The user has at its disposal several "digital identit[ies]" stored on "information cards", and an "identity selector" through which the user selects an identity and dispatches it as needed (see page 4, pa­ra­graphs 1-5). The user may choose the identity in view of the privacy policy offered by the service provider (see pages 8 and 18, last paragraphs). Based on the chosen identi­ty, a security token is produced and for­warded to the relying party (page 4, para­graph 5; page 9, last paragraph; page 19, paragraph 1).

4.2 D4 further discloses that the information cards contain metadata (see page 4, paragraph 5; pages 10, 11 and 33) representing in particular "a token issuance relationship between an identity provider and a subject" (see page 11, paragraphs 2-4 and 7) and a "visual representation of the digital entity" (see e.g. page 10, last paragraph, but also, albeit not "visual" form, the "friendly textual name" on page 10, penultimate para­graph). It is disclosed that "additional attributes" and "additional meta­data" to those initially anticipated may have to be added later, and suitable "extensibility points" are provided to this end (see page 11, paragraphs 10 and 11).

The decision and the appeal

5. The examining division found that the claimed invention differed from the prior art only in the use of different me­ta­­data fields (see page 4, last two lines), relating in particular to the card's "usage history" such as "last time of using the card". It considered that allowing the card se­lection to be based on usage history was a business require­ment and that the technical problem to be solved was therefore "to allow the user to utilise a card usage history based card selection policy". The implementation of such a card selection policy was found to be obvious based on the extensibility points of D4 (see reasons, page 5, first two paragraphs).

6. The appellant argues that the examining division misinterpreted the prior art.

6.1 Whereas D4 disclosed the metadata to "represent[] the token issuance relationship between an identity provider and a subject, and [to] provide[] a visual representation of the digital iden­tity", the "recited" - i.e. claimed - alternatives for metadata all relate[d] to the information card" itself "without refe­rence to the identity provider" (see grounds of appeal, page 1, point (1)).

6.2 The appellant states that the "extensibi­lity point" known from D4 was "at odds with the claimed usage". It also criticises the exami­ning divi­sion's limitation of the objective technical problem to "his­to­ry-based card selection" (see point 5 above) although some of the recited me­ta­data had nothing to do with history (pages 1-2 of the grounds of appeal, point (2)) and proposes the following alternative objective technical problem (page 2, point (3)): "how to allow a user to use data about an information card in selecting an information card to use with a relying party, where the data about the information card does not relate to the identity provider".

6.3 In this context, the appellant states that "[i]t might not involve an inventive step to add other types of me­tadata that relate to the identity provider", but that "extending metadata usage to other forms as recited in claim 7 would involve an inventive step", and argues that it should be relevant for inventive step "how much effort is involved in implementing the improve­ment/solving the real technical problem" (loc. cit.).

7. The board is not convinced by the appellant's argu­ments.

7.1 Firstly, the board does not agree with the appellant's assessment of D4 vis-à-vis the claimed invention. It is noted that D4 expressly discloses the me­tadata as defining when or how the information card was issued, when it was last updated and when it is about to expire (see page 11, paragraphs 3 and 4, "TimeIssued and "TimeExpires", and page 33, paragraphs 7 and 10, "isSelfIssued" and "TimeLastUpdated"). These bits of metadata make as little "refe­rence to the identity provider" as the ones specifically claimed. At any rate, however, they are of the same type as some of the claimed ones, namely "last time [...] used" or "last used successfully". The board also notes that the visual aspects of the information cards of D4 (see e.g page 10, last paragraph) are as unrelated to the "token issuance relationship" as the "advertise­ment" claimed. For this reason, the technical problem proposed by the appellant does not correspond to the difference between the invention and D4.

7.2 Secondly, the description also does not disclose anything that would support the appellant's suggestion that the imple­men­tation of specific bits of metadata might require par­ti­cular effort or specific provisions in the CardSpace system.

7.3 Thirdly, the board notes that the claims list metadata "alternatives". Hence, although not all metadata examples relate to usage history, the claims are satisfied by a suitable method and apparatus which provide only metadata which does. Likewise, although the objective technical problem considered by the examining division may not reflect all claimed examples for meta­data, the board considers it to be appropriate for at least some of them and thus to be sufficient for an inventive-step assessment of the claimed subject-matter as a whole.

7.4 Fourthly, the alternative objective technical problem proposed by the appellant does not, in the board's judgement, render invalid the fundamental argument of the examining division. Whether the data used to select an information card does or "does not relate to the identity provider" does not, in the board's view, solve a technical problem (see T 641/00, headnote 2). In this re­gard, the board agrees with the exa­mining division's assumption that the specific metadata chosen follows from a given business requirement. The appellant did not challenge this understanding either.

7.5 And lastly, the board disagrees with the appellant's argument that a positive finding on inventive step would acknowledge the "effort involved in implementing the im­provement/solving the real technical problem" involved. According to Article 56 EPC, an invention is to be con­sidered as involving an inventive step if, having re­gard to the state of the art, it is not obvious to a person skilled in the art. Conversely, an invention is considered as not involving an inventive step if it is obvious to a person skilled in the art. The finding of obviousness, however, does not exclude the possibility that actually carrying out the invention involves some or even considerable effort, provided that this effort does not in itself require the skilled person to exercise inventive skill.


8. In summary, the board agrees with the examining division that the only difference between the claimed invention and D4 is the kind of metadata stored and provided to the user to aid the selection of an infor­ma­­tion card, and the appellant seems to agree with this assessment. Unlike the appellant, however, the board cannot see that D4 would be incompatible with the particular metadata recited in the claim, let alone teach away from using the metadata in question. Rather, the board considers that the choice of that metadata is based on non-technical considerations: this is arguably most obvious in the case of advertisements, but in the board's view (and as argued in the decision) also true for the claimed metadata relating to usage history. Moreover, D4 provides all technical means required to support additional metadata of any type.

8.1 With regard to the auxiliary request the board accepts the appellant's observation that the examining division has only explicitly addressed the independent method claim 7, and has therefore formally raised no objection against apparatus claim 1. However, the board notes that the appellant has not argued that or why the examining divi­sion's objection fails in substance for the appa­ratus claim. The board considers that the above assessment applies to both the method and the apparatus claims alike.

8.2 The board thus comes to the conclusion that the subject-matter of independent claim 7 (of the main request) and claim 1 (of both requests) lacks inventive step, Article 56 EPC.


For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation