T 2138/15 09-02-2021
Download and more information:
MULTI-APPLICATION IC CARD SYSTEM
Inventive step - main request (no)
Inventive step - auxiliary request (no)
I. The appeal of the patent Proprietor concerns the decision of the Opposition Division to revoke the patent EP 0 963 580 with the application
No. 98 907 003 on the grounds that the initial Main Request was not allowable under Art 54(2) EPC, as held in decision T 0621/08, the initial Auxiliary Requests 1 to 3 were not allowable under Article 56 and initial Auxiliary Requests 2 and 3 contravened in addition Article 123(2) EPC.
II. The opposition was based on the grounds of opposition under Article 100 (a) EPC, i.e. novelty and inventive step, for all requests.
III. In a first oral proceedings before the Opposition Division the patent was revoked for lack of novelty. An appeal was filed against this decision.
IV. In decision T 0621/08 this board (in a different composition) held that the subject-matter of initial Main Request was not novel within the meaning of Article 54 EPC. Initial Auxiliary Request 1 was held to be novel. Auxiliary Requests 2 and 3 were not discussed by the board. The case was then remitted to the Opposition Division for further prosecution on the basis of the requests submitted before the board in T 0621/08.
V. The former Opponent withdrew the opposition and is, hence, no longer party to the appeal proceedings.
VI. With the statement of grounds of appeal, the Appellant Proprietor filed as new Main Request the former Auxiliary Request 1 and a new Auxiliary Request.
VII. In its preliminary opinion dated 29 November 2019 the Board concluded that the Main Request and Auxiliary Request as filed with the statement of grounds of appeal did not meet the requirements of Articles 52(1) and 56 EPC. The Appellant was summoned to oral proceedings on 15 May 2020.
VIII. With letter dated 23 April 2020 the Appellant withdrew the request for oral proceedings. The Board proposed with letter dated 29 April 2020 the possibility to hold oral proceedings by Video Conference on the 15 May 2020. The Appellant however did not accept this proposal.
IX. The procedure was therefore continued by writing and with a communication dated 4 May 2020, the Appellant was invited to file observations to the Board's communication of 29 November 2019 within a time limit of 2 months. The Appellant did not reply within this time limit.
X. The Appellant - Patent Proprietor (hereafter "Appellant") requests that the decision under appeal be set aside and that the patent be maintained on the basis of the Main Request or Auxiliary Request filed with the statement of grounds.
XI. Reference is made to the following document:
D9 =|Handbuch der Chipkarten, W. Rankl/W. Effing, 2nd ed. 1996, pp. 125, 126, 134-138, 197, 205, 2077, 241-244, 322, 323, 332-337, 367|
XII. Claim 1 of the Main Request reads:
1. An IC card system comprising at least one IC card for storing multiple applications, an application to be loaded onto said card and means for determining whether said card is qualified to accept the loading of said application onto said card, wherein said IC card contains card personalization data, and said application is assigned application permissions data representing at least one set of IC cards upon which said application may be loaded and wherein said determining means compares said card personalization data with said application permissions data and wherein said application is loaded onto said IC card in dependence on the result of said comparison; wherein said card personalization data comprises data loaded onto said card at a card personalization bureau which configures the card for a card issuer to a specific user or class of users by using data representative of a card issuer and data representative of a product class, said determining means is provided on said card, and said permissions data set includes one or more card issuers and one or more product classes.
XIII. In claim 1 of the Auxiliary Request the last paragraph was amended as follows (the differences with respect to claim 1 of the Main Request were highlighted by the Board): [deleted: one or more] a plurality of product classes.
1. The invention as claimed
1.1 A conventional single application IC card, such as a telephone card or an electronic cash card, is loaded with a single application at its personalization stage. That application, however, cannot be modified or changed after the card is issued even if the modification is desired by the card user or card issuer.
1.2 The invention has the objective to make it possible to store multiple applications on the same IC card. For example, a card user may have both a purse application and a credit/debit application on the same card so that the user could select which type of payment (by electronic cash or credit card) to use to make a purchase. Multiple applications could be provided to an IC card if sufficient memory exists and an operating system capable of supporting multiple applications is present on the card.
1.3 The invention further aims to provide the ability to load and delete applications for card post-production as needed and to provide the capability of the IC card system to exchange data among cards, card issuers, system operators and application providers securely and to load and delete applications securely at any time (paragraphs [0003]-[0005] of the patent).
2. Admissibility
The appeal is admissible.
3. Main Request - Article 56 EPC (inventive step)
3.1 Closest Prior art
As in T 0621/08 D9 is considered to be the closest prior art.
3.2 Difference
3.2.1 D9 discloses an IC card system comprising at least one IC card for storing multiple applications, an application to be loaded onto said card and means for determining whether said card is qualified to accept the loading of said application onto said card, wherein said IC card contains card personalization data (e.g. AID = RID + PIX + "Nachladeschlüssel", AID, RID and PIX stand for "Application Identifier", "Registered Application Provider Identifier" and Proprietary Application Identifier eXtension", respectively), and said application is assigned application permissions data ("Temporary AID" of the application to be loaded, see page 137, last paragraph to page 138, third paragraph, page 243, 2nd paragraph) representing at least one set of IC cards upon which said application may be loaded and wherein said determining means compares said card personalization data with said application permissions data ("Authentisierung", use of the AIDs and the "Nachladeschlüssel") and wherein said application is loaded onto said IC card in dependence on the result of said comparison; wherein said card personalization data comprises data loaded onto said card at a card personalization bureau (page 138) which configures the card for a card issuer to a specific user or class of users by using data representative of a card issuer (in ATR / "Historical Characters", page 197, last but one paragraph) and data representative of a product class (in ATR), said determining means is provided on said card.
3.2.2 As previously decided by the Board of Appeal in T 0621/08, point 3.4, claim 1 of the enclosed Main Request is distinguished over the disclosure of D9, because D9 fails to disclose that the permissions data set includes a card issuer or a product class.
3.3 Effect
3.3.1 The appellant noted that in the claimed subject-matter personalization data was stored on the card at a more granular level, i.e. the card issuer and card product type were stored as separately readable records used for the comparison with the application permissions data set rather than as a combined alphanumerical identifier value as the AID.
3.3.2 By specifying the elements of the application permissions data set in the manner as specified in the claimed invention, it was not necessary to determine, at time of creation of the card, which applications would be allowed to be loaded onto the card in the future. This was in particular advantageous for applications not created at the time of creation of the card, where the unique AID was not already known.
3.3.3 Therefore the technical effect compared with the system of D9 was that the flexibility of installing applications on an IC card was increased. A further advantage was that the card issuer had much greater control over which applications could be loaded (T 0621/08, section VI, last sentence).
3.3.4 The Board agrees that the effect compared with the system of D9 is that the flexibility of installing applications on an IC card is increased. Paragraphs [0036], [0050] and [0053] specify the purpose of the product class: The product class may be a standard credit card, a gold credit card or a platinum credit card. Depending on the card issuer (bank, service provider) specific services and privileges may be linked to a class of cards.
3.3.5 Therefore, the product class and card issuer correspond to specific commercial business models. The business model consists in providing more applications, if a client pays for a specific card type (product class) or a specific service provider (card issuer). Therefore, in the present case the achieved increased flexibility with respect to D9 serves especially for an improved business model.
3.4 Problem
The Appellant proposes that the objective technical problem may be expressed as "how to increase the flexibility of installing applications on an IC card". The Board follows this proposal in view of its understanding of flexibility, i.e. that applications can be installed depending on the business models underlying the different product classes and card issuers.
3.5 Obviousness
3.5.1 The Opposition Division argued as to the feature "product class" that D9 specified on page 138 that the AID was made up of two data elements, one of them being the registered identifier (RID). The RID comprised among others the category of the application ("Anwendungskategorie").
3.5.2 As the feature "card issuer" is concerned, D9 disclosed on page 138 that the RID identified the application service provider ("Nummer für den Anwendungsanbieter").
3.5.3 The Opposition Division was of the opinion that giving permission for loading an application according to the "application category" had the same technical effect as making the comparison based on a "product class". Hence this differentiating feature was not considered to be sufficient to establish inventive step. Concerning the feature "card issuer", the Opposition Division was of the opinion that it was also obvious from D9, page 243, that the data for "authorized application service providers" was preregistered in the card by the card issuer via the temporary AID.
3.5.4 Thus, the difference of claim 1 to D9 in this respect was that the permission to load an application or not was based on the "card issuer" and not on the "application service provider" information. The alleged effect of "giving the card issuer much greater control over which applications can be loaded" was also achieved in D9.
3.5.5 The card issuer preregistered the application providers that subsequently were able to load their applications on the card. At this later stage, this operation could only be performed with a key provided by the card issuer ("Nachladeschlussel", page 243 of D9). Given the above, this slightly alternative way of providing the same technical effect was not considered to contribute to inventive step, either.
3.5.6 As observed in T 0621/08, the data representing the card issuer and the product class are written on the card by the personalization bureau. This data is encoded into the "ATR" (Answer To Reset) as a combined alphanumerical identifier value and is not available as separately readable records to be used for the comparison with the application permissions data (and not in the "AID" format). The question to be answered is
(a) whether the skilled person would have used this ATR data for the decision making process whether new software is to be installed or not, or
(b) whether the skilled person would have based their decision (alternatively to the category of the application and the application service provider, as available in the AID) on a card issuer or a product class as claimed in present claim 1.
ad a)
3.5.7 As to the argument that the present invention does not need an additional code ("Nachladeschlüssel") it is submitted that whether or not a Nachladeschlüssel control takes place is not reflected in the claim wording and therefore is not in contradiction to the disclosure of D9.
3.5.8 The Board is of the opinion that the skilled person would consider any available information registered on the chip card for deciding whether to install a new application, even if the data is not registered in the AID format. The card issuer and product class information on the other hand are encoded in the ATR data set. The ATR format is defined by norm ISO/IEC 7816-3 and is the first data set to be read when a chip card is connected to a voltage supply (D9, page 197, section "Die Historical Characters"). Data contained in the ATR is therefore always present in the card reader. The format of these "Historical Characters", where the card issuer and the product class are saved, is however not defined by any norm. Nevertheless, this data is read out and is hence available for the decision making process.
3.5.9 The skilled person has to solve the problem of providing more flexibility in the decision making and installation process of a new application. Increased flexibility also means that alternative criteria and parameters are considered, which make the deciding process easier or more efficient. As discussed in the impugned patent (passages cited above) the purpose of a product class does not correspond to specific technical settings, but only serves commercial purposes (different business contract conditions for gold and platinum card). Therefore in the present case the achieved flexibility serves especially for an improved business model.
3.5.10 The Board is of the opinion that the skilled person faced with the problem of increasing the flexibility of installing applications on an IC card would in the present case consider whether and where data representing "one or more card issuers and one or more product classes" are available on the chip card. They would take this data being present on the card into account for deciding whether a new application is to be installed. In the present case this provides more (commercial) flexibility for the user in installing new software applications.
3.5.11 Once the skilled person has decided to use this data, they would also optimise the format and location of this data as well as the reading and comparing process. The technical implementation would not represent any technical difficulty and would lead to the combination of features of present claim 1.
ad b)
3.5.12 In addition, the Board agrees with the reasoning of the Opposition Division that giving permission for loading an application according to the application category has the same technical effect as making the comparison based on a product class. Hence this differentiating feature cannot be considered to be sufficient to establish inventive step, because the skilled person would take a product class as alternative option into account for realising the business models described above.
3.5.13 The same reasoning can be made for the feature that the permission to load an application or not is based on the card issuer and not on the application service provider information. The skilled person would adapt the data format, location and the comparison process of the data accordingly.
3.5.14 The Board therefore finds that the subject-matter of claim 1 of the Main Request does not involve an inventive step within the meaning of Article 56 EPC.
4. Auxiliary Request
The claims of the auxiliary request are based on the claims of the Main Request, wherein independent claims 1, 10, 15 and 18 are amended to recite that the permissions data includes a plurality of product classes. This amendment is a restriction of the Main Request and falls within the wording of the claims of the Main Request, i.e. "one or more product classes".
4.1 Article 56 EPC (inventive step)
Neither the Opposition Division nor the Board of Appeal had decided on this combination of features.
4.2 Difference
As observed in T 0621/08, D9 discloses only one product class and not a plurality of product classes. This plurality of product classes corresponds to different types of IC cards, e.g. standard credit card, gold credit card, platinum credit card etc. These types therefore correspond to different business models of credit cards.
4.3 Effect
The Appellant argued that in the amended claims of the Auxiliary Request, an additional technical effect was obtained through the use of a plurality of product classes. The Appellant noted that this avoided the need to maintain separate applications for each type of IC card that a card issuer may have. In fact a list of product classes or card providers suitable for one application was saved on the card. The Board sees here an increased efficiency, because a bundle of product classes can be allocated to an application. This may save memory space and reduce the number of applications to be saved and maintained.
4.4 Problem
The Appellant proposes that starting from D9, the objective technical problem may be expressed as "how to improve the efficiency of application maintenance".
The Board agrees with this approach.
4.5 Obviousness
4.5.1 The Appellant argued that according to the Opposition Division the AID included a Registered Identifier component (RID), which included an application category ("Anwendungskategorie"). Each AID could only include a maximum of one application category. There was no reason why the RID/AID should include more than one application category. Its purpose was purely to provide a unique number, which was obtained already by the use of a single application category. Therefore the skilled person would not have any motivation to include additional application categories in the AID.
4.5.2 The Board notes that product class and card issuer are saved in the ATR data set. The Historical Character field in the ATR data set is not predefined by any norm (D9, page 197). Therefore, a plurality of card types can be registered in this field. For the reasons given above under a) the Board is of the opinion that the skilled person would consider registering a plurality of card type / card issuer data in the Historical Character field, if in this manner there would be no need to maintain separate applications for each type of card type / issuer.
4.5.3 It is a common practice in software development that, if one application is valid for a plurality of different data sets, the skilled person would register the names of these data sets in a list and flag the application for all these data sets accordingly. The skilled person would not be faced with any technical difficulty to implement this in the given context.
4.5.4 The Board is of the opinion that the skilled person would consider registering the different card types / card issuer in the Historical Character field of the ATR data set for which a specific application applies and taking this data into account for deciding whether a new application can be installed or not. In this context the skilled person would also consider any other suitable data format and data location.
4.5.5 The Board therefore is of the opinion that the subject-matter of claim 1 of the Auxiliary Request does not involve an inventive step.
5. To summarise, since none of the Appellant's requests are allowable, the appeal must fail.
For these reasons it is decided that:
The appeal is dismissed.