T 0602/03 (Programmable smart card/TRANSACTION TECHNOLOGY) 25-04-2006

Claim 1 of the main request

1. Amendments

Claim 1 refers to the data location of the data "in their respective master files", a formulation introduced into the claim during the proceedings before the examining division. In the description as well as in figures 1 and 2, however, a single master file is disclosed. Thus, this amendment constitutes a deficiency of a more formal nature, contravening Article 123(2) EPC. For the purpose of the present decision, this feature will be interpreted in accordance with the description.

2. Construction of claim 1

2.1 Claim 1 specifies that the card according to the invention mimics the functionality of a "first application program". Judging from the description (p. 17, second paragraph; p. 24, last paragraph), the term "first application program" designates a standard smart card programmed specifically for use with a particular kind of automatic teller machine (ATM). In the same way, the term "second application program" designates a standard smart card programmed for use with another (and incompatible) particular kind of ATM. The card according to claim 1 is thus such that an ATM cannot distinguish it from a standard card. The standard functionality is however not specified in the claim, nor indeed described in any detail in the description. It follows that the reference to the first and second applications in the claim has no limiting effect beyond what the claim explicitly sets out, ie that the programmed application modules are capable of performing first and second applications, whatever these applications may be.

2.2 Similarly, the same parts of the description (p. 17; p. 24) suggest that the feature "the first and second application modules provide the interpreter with respective maps of data locations that map the data location of the data in their respective master files with the respective data structures specified in the application programs" refers to application programs on such standard cards. But since the standard cards are undefined, their data structure is completely arbitrary. It could for example be the same as the structure of the master file. If so, an indication of the location of particular data in the master file is automatically an indication (map) of the location of the same data on a standard card. It follows from this consideration that also this feature cannot serve to limit the claimed subject-matter.

3. The prior art

3.1 D1 and D2 are regarded as the two closest pieces of prior art because each relates to a smart card having stored on itself the application programs to be executed by the terminals for which it is intended. In the decision under appeal, and also in the Board's communication, D1 was regarded as the closest document. However, after the last amendments to the claims D2 appears to be the more proper point of departure.

3.2 D2 concerns a programmable smart card having instructions stored on it which define one or more financial transactions. An associated terminal is programmed to read these instructions, interpret them and execute them to conduct one or more transactions. The program is in the form of a core program with subroutines (fig. 6). The terminal may for example be an ATM or a pay telephone (col. 4, l. 40-48). Subroutines for preferred functions may be added using special terminals (paragraph bridging col. 8 and 9).

4. Novelty

4.1 D2 describes the following features of claim 1:

- an interpreter ("core program") which manages an interface between the smart card and a first system for smart cards that is used by a first terminal (eg a pay telephone) and a second system for smart cards used by a second terminal (eg a bank terminal) for interacting with the smart card;

- a first application module (subroutine, see fig. 6B-6E) resident on the smart card and programmed with a first application for interfacing the smart card with the first system;

- a second programmable application module (subroutine) resident on the smart card and programmed with a second application for interfacing the smart card with the second system;

- the first application being incompatible with the second application (cf col. 8, l. 49-54);

- the interpreter (core program) using application information from the first and second application modules to manage the interfaces between the smart card and the first and second systems, respectively;

- the management of the interfaces including the interpreter dynamically loading first parameters from the first application module characteristic of the first application program being used by the first terminal and thereby mimicking (performing) the functionality of the first application program;

- the interpreter further dynamically loading second parameters from the second application module characteristic of the second application program being used by the second terminal and thereby mimicking (performing) the functionality of the second application program; - new application programming (eg concerning a particular bank service) can be added to the programmable module of the smart card via a terminal (the "special terminals" mentioned in the paragraph bridging col. 8 and 9) on the second system used by the second terminal in such a way that the smart card can be used with the second terminal and such that, without being reprogrammed, the smart card can still be used with terminals using the first system (eg the pay telephones).

4.2 Claim 1 further specifies that

- the first and second application modules provide the interpreter with respective maps of data locations that map the data location of the data in their respective master files with the respective data structures specified in the application programs.

In accordance with the interpretation above (cf point 2.2), this feature implies that the application modules provide the interpreter with data locations at which certain data can be found.

In D2, some data items, such as the account number (fig. 6, ACCOUNT#), are used by the core program as well as by subroutines (cf 601 in fig. 6A and 613 in fig. 6B). The account number is stored in the card's data area (fig. 4, 405). The use of the name ACCOUNT#, recognizable by the core program, for a variable in the subroutine automatically defines the location of the variable. In other words, the application module (subroutine) provides the interpreter (core program) with information which allows the interpreter to find data (ACCOUNT#) at a certain location of the data area.

Thus, this feature is also regarded as known from D2.

4.3 The invention is distinguished from the card described in D2 by the feature that

- the first parameters and second parameters include security procedures, keying schemes and access conditions used in the first and second systems, respectively.

This feature allows specific access control.

4.4 It follows that the invention is new (Article 54 EPC).

5. Inventive step

In D2 it is apparently assumed that the card is used by a single customer, and the security check seems to be limited primarily to checking a "security code" (col. 6, l. 20). Whether or not the different subroutines require individual codes is not said. Specific access control by means of individual codes would however be natural, considering that sensitive applications need more elaborate protection than others and that different companies accepting the card (eg banks and telephone providers) might insist on applying their own security standards. Also, if the card is to be used by different people, for example employees of a firm, it would be necessary to provide security procedures within the subroutines to restrict each person's use of the card to applications for which he is authorized. Therefore, it was obvious for the skilled person to add the distinguishing feature as identified above to the card known from D2.

Thus, the subject-matter of claim 1 does not involve an inventive step (Article 56 EPC).

Claim 1 of the auxiliary request

6. Novelty

Again starting out from D2, it is clear from the discussion above in respect of the main request that this document discloses:

- an interpreter (core program) which manages an interface between the smart card and a system transacting with the smart card;

- at least two application modules of which each is programmed with an application for interfacing the smart card with the system, and the application modules have different application programming;

- the interpreter using application information from an application module to manage the interface between the smart card and the system.

Furthermore, the core program is arranged to signal the system what application programming is available on the smart card (col. 7, l. 1-3; col. 9, l. 38-44). The terminal is also aware that the smart card is programmable since it identifies the card as a "customized programming card" (col. 6, l. 38-43), allowing it to be (re-)programmed (col. 8, l. 57 - col. 9, l. 6).

Thus, the subject-matter of claim 1 is not new (Article 54 EPC).

Procedural matters

7. Document D2 was mentioned in the annex to the summons to oral proceedings but was not discussed in detail since the final amendments to the claims, intended to distinguish the invention from D1, were filed only in response to the summons. By filing amended claims shortly before oral proceedings and subsequently not attending these proceedings, the appellant must expect a decision based on objections which may arise against such claims in his absence (Article 11(3) and (6) RPBA).