T 2267/16 26-01-2021
Download and more information:
Smart card with external memory
Novelty - main request (no)
Novelty - auxiliary request 1 (no)
Auxiliary request 2 filed after summons to attend oral proceedings - admitted (no)
I. The appeal is against the decision of the examining division to refuse European patent application No. 13 159 147.
The following document was cited:
D3: WO 00/26866 A1
The examining division decided that the subject-matter of claims 1 and 7 according to the former main request lacked novelty (Articles 52(1), 54 (1) and (2) EPC) over D3, and that the subject-matter of claims 1 and 6 according to the former first auxiliary request and of claims 1 and 5 according to the former second auxiliary request lacked an inventive step (Article 56 EPC) in view of D3.
II. In a communication pursuant to Article 15(1) RPBA 2020, the Board provided its preliminary view that the requests filed with the statement of grounds of appeal did not meet the requirements of Articles 123(2), 84, 52(1), 54(1) and (2) EPC.
III. The appellant (applicant) requests that the decision be set aside and a European patent be granted based on the basis of claims 1-4 of the main request, or alternatively on the basis of the 1**(st) or 2**(nd) auxiliary request, all filed with a letter dated 9 December 2020.
IV. Oral proceedings were held on 26 January 2021, at the end of which the Chairman announced the Board's decision.
V. Claim 1 according to the main request has the following wording:
A smart card (2) comprising:
a) a communication unit (25) configured to exchange data with an external terminal (1);
b) a recording unit (24) configured to record data defined by definition information;
c) a first reception processor (21, S11) configured to receive a read command from the external terminal via the communication unit, which read command requests to read data in the recording unit;
d) a determination unit (21, S23) configured to determine whether data required for execution of the read command is stored in the recording unit or in an external device, if the first reception processor receives the read command; and
e) a first transmission processor (21, S27) configured to transmit a response indicating start of a session, which is required to acquire related data from the external terminal, the related data being related to the data required for execution of the read command, to the external terminal via the communication unit, if the determination unit determines that the data required for execution of the read command is stored in the exterior of the smart card.
Claim 1 according to the first auxiliary request corresponds to claim 1 of the main request and further specifies (Board's feature labelling f) to j)) that the smart card comprises:
f) a second transmission processor (21, S42) configured to transmit a proactive command required to acquire the related data related to the data required for execution of the read command from the external terminal after the first transmission processor outputs the response indicating the start of the session to the external terminal;
g) a second reception processor (21, S52) configured to receive a terminal response command including the related data from the external terminal as a response to the proactive command;
h) a third transmission processor (21, S57, S59) configured to output an execution result of the read command as a response to the terminal response command; and
i) a third reception processor (21, S4) configured to receive a command transmission request command, which requests to transmit the proactive command, from the external terminal after the first transmission processor outputs the response indicating the start of the session, and before the second transmission processor outputs the proactive command,
j) wherein the second transmission processor transmits the proactive command based on reception of the transmission request command, which requests to transmit the proactive command, from the external terminal after the first transmission processor outputs the response indicating the start of the session to the external terminal.
Claim 1 according to the second auxiliary request corresponds to claim 1 according to the first auxiliary request, wherein the "start of a session" is "required to acquire from the external terminal encrypted data obtained by encrypting the data required for execution of the read command" (amended feature e')), wherein "the second transmission processor (21, S42)" is "configured to transmit a proactive command required to acquire the encrypted data" (amended feature f')), wherein the second reception processor (21, S52)" is "configured to receive a terminal response command including the encrypted data" (amended feature g')) and the smart card further comprises "a saving unit (24b) configured to save a key required to decrypt the encrypted data; and a decryption unit (21, S54) configured to decrypt the encrypted data included in the terminal response command using the key stored in the saving unit" (feature k)).
VI. The appellant's relevant arguments to support novelty over document D3 and admission of the second auxiliary request can be summarized as follows:
Novelty over document D3
(a) The term "terminal" in claim 1 could only be identified with the application 152 in computer 4, as it was the application residing in computer 4 that sent a read command, see figure 5, block 100 and page 32, lines 8 and 9 of document D3.
In D3, the communication according to figure 11 between the smart card 2 and the external database BDA 74 on the data storage medium 12 of external server 8 was performed through a separate connection or command channel, as shown by the arrow pointing from smart card 2 towards BDA 74, see figure 20.
There was no indication in D3 that the communication between the smart card and the database 12 was through the same terminal as used for the communication with application 152. For the appellant, the communication between smart card 2 and the application 152 in computer 4 on the one hand, and the communication between the smart card and the BDA 74 on the other hand must be treated "as logically separate", i. e. as two "logically separate communication instances". Hence, for the appellant, figure 11 of D3 did not describe that an exchange of a "response", a "proactive command" or a "terminal response" in the sense of features e), f) and g) took place between the smart card and an external terminal.
(b) The present invention transcended the common paradigm of master-slave control by enabling the card to take control, but without sacrificing the basis protocol according to which the terminal sent commands and the chip card reacted. Figure 4 gave as an example a communication in the form of pairs (S1, S3), (S4, S5), (S7, S8), each consisting of a request from the terminal and a response from the smart card.
The start of a "session" by the card was indicated as an example of the card taking control; the "session" included response S3, FETCH S4, proactive command S5 to obtain the "related data", see Figure 4 of the application. The session was started after the card "on its own" determined whether data required was stored in its memory. Although the card took control by proactively starting a session and informing the terminal of a start of a session ("indicating the start of a session"), the basic master-slave protocol was maintained.
D3 did not disclose that the smart card began some sort of session, either with the data base or with the terminal in the sense of feature e).
(c) The process according to D3 involved two reading requests for an object index and an data object, whereas the claimed smart card processed only one reading request (feature c)). In the process according to the invention, the smart card did not respond with the requested content, but indicated the start of a session (messages S4 to S7 in figure 4 of the present application).
(d) Moreover, the execution result output to the external terminal (feature h)) would refer to the initial read request according to feature c) with the consequence that the process of D3 could not be mapped onto claim 1 of the first auxiliary request.
(e) With respect to the first auxiliary request: D3 did not disclose a "command transmission request command" according to feature i), which was a command containing a request to send a command from the smart card to the terminal (see e. g. the present application, Figure 4, step S4). This was a "special feature" that provided the effect of retaining the formal master/slave hierarchy while at the same time transcending that hierarchy in letting the smart card proactively send commands to the terminal (see the appellant's letter dated 9 December 2020, page 9, third paragraph). The read command for an indexed non-resident data object in D3 was nothing more than a command to read an object and return the result of that reading and was not a "command transmission request command" (see the appellant's letter dated 9 December 2020, page 10, penultimate paragraph).
Admission of the second auxiliary request
(f) The second auxiliary request was filed in response to objections that were raised for the first time in the Board's communication, namely the clarity objection raised in section 3.2.2. The proceedings would not be protracted by the admission of the second auxiliary request.
1. The appeal is admissible.
2. The invention
The present application deals with the problem of limited data amount that can be stored internally, i.e. in the memory of a smart card, see page 1, lines 7-14.
According to the invention, data is stored - typically in encrypted form - in the exterior of the smart card, e. g. in the memory of an external smart card processing terminal (see page 4, lines 22 to 26, Figure 1, external terminal with memory 12a, 12a) or in a third apparatus connected to the external terminal (see page 4, lines 26 to 33).
In case the smart card receives a read command from the external terminal, which read command requests to read data in the recording medium of the smart card, a determination unit determines whether data required for the execution of the read command is stored in the recording unit (i. e. inside the smart card) or not. If the data required for the execution of the read command is stored in the exterior of the smart card, a transmission processor transmits a response indicating the start of a "session" to the external terminal. The "session" is required to acquire "related data from the external terminal, the related data being related to the data required for execution of the read command".
3. Prior art - document D3
3.1 Similarly to the present application, document D3 relates to a memory management process involving IC portable devices, e. g. a smart card 2 (see page 1, line 3 to page 2, line 13; page 7, lines 10 to 18) and concerns, in particular, a method of securely expanding the storage capacity of a smart card by storing data (e. g. data object 14) remotely from the smart card as encrypted "non-resident objects" (see Figure 2; page 7, line 19 to page 14, line 13). The location of the data objects 14 can be traced by assigning a location attribute ("resident state" or "non-resident state") to each data object (see page 16, lines 18 to 25).
3.2 According to D3, data objects stored outside the card are traced and retrieved using indexes (see e. g. page 7, lines 19 to 25) stored either in the smart card or remotely (as "non-resident object indexes 58" pointing to non-resident data objects 14, see page 15, lines 22 to 27, page 18, lines 1 to 18, Figure 4, page 24, lines 20 to 24, page 25, lines 6 to 13, "NR_OBJ" referring to non-resident data objects, "INDX_OBJ_NR"/"INDX_NR_OBJ" referring to non-resident object indexes). The passages on page 18, lines 1 to 11, page 27, lines 8 to 15 or page 30, line 31 to page 31, line 1 specify that a non-resident object index belonging to the class INDX_OBJ_NR contains references to non-resident data objects (e. g. NR_OBJ) residing in the external memory, e. g. databases BDA of data storage medium 12 of server 8, see Figure 1, page 26, lines 1 to 18, page 27, lines 18 to 31. In other words, a non-resident object index always makes reference to a non-resident data object, but not to a resident data object.
3.3 Figure 5 in combination with Figures 9 to 10 describe a reading operation, see page 32, lines 3 to 34 and page 33, line 33 to page 34, line 19, Figures 20 and 21, page 36, lines 11 to 24. As claim 1 according to the appellant's requests concerns a smart card receiving a read command from an external terminal, these are the most relevant passages in D3.
Figure 5 in combination with Figures 6 to 8 and page 33, line 1 to 32 concerns a writing operation, see also Figures 13 to 17.
3.4 The passages on page 34, lines 10 to 14 and page 32, lines 24 to 30 make it clear that when an external terminal requests to read a non-resident data object, first the corresponding object index is to be read and thereafter the indexed data object itself is to be retrieved. For case of an non-resident object index - as described e. g. on page 18, lines 1 to 11, page 27, lines 8 to 15 or page 30, line 31 to page 31, line 1 - it follows that an external terminal has to sequentially read the non-resident object index and the non-resident data object from the smart card.
Thus, the Board understands that D3 discloses a method, wherein an application 152 in a computer 4 first requests (100) a non-resident data object that is an index (Figure 5, 118, YES), i. e. an non-resident object index. After receiving (Figure 5, 116) the object index from the smart card, the application 152 decides that it requires (Figure 5, 120, YES) the indexed data object and, finally, the application prepares a second request (Figure 5, 122, 100) for its retrieval (100). For each request, i. e. the first request for the object index and the second request for the indexed data object to be retrieved, the steps shown in Figures 9 - 11, 20 and 21 are performed.
In more explicit terms, D3 discloses the following sequence of method steps in a communication between a an external terminal 4, 6 and a smart card 2:
(i) the smart card 2 receives a first reading request (Figure 5, 108) from application 152 for reading a non-resident data object that is an index, i. e. an object index (Figure 5, 100 - 106)
(ii) the smart card 2 determines that a non-resident object index is to be read (Figure 9, 136, NO)
(iii) the smart card 2 transmits a request to BDA 12 (Figure 10, 144, Figure 11, "Transmit request to BDA") to receive an encrypted version of the object index
(iv) the smart card 2 receives the encrypted version of the object index as the response from BDA 12 (Figure 11, "Receive response from BDA") and decrypts the object index (Figure 11, "Decrypt response")
(v) the smart card 2 transmits the decrypted object index to the application (Figure 5, 116)
(vi) the smart card 2 receives a second reading request (Figure 5, 106 after 118, YES, 120, YES, 122) from application 152 for reading the non-resident data object (Figure 5, 100 - 106)
(vii) the smart card 2 determines that a non-resident data object is to be read (Figure 9, 136, NO)
(viii) the smart card 2 transmits a request to BDA 12 (Figure 10, 144, Figure 11, "Transmit request to BDA") to receive an encrypted version of the data object
(ix) the smart card 2 receives the encrypted version of the data object as the response from BDA 12 (Figure 11, "Receive response from BDA") and decrypts the data object (Figure 11, "Decrypt response")
(x) the smart card 2 transmits the decrypted data object to the application 152 (Figure 5, 116)
4. Main request
4.1 D3 discloses (in the wording of claim 1) a smart card (2, Figure 1, page 6, line 15) comprising:
a) a communication unit (Figure 1) configured to exchange data with an external terminal (Figure 1, terminal card reader 6, computer 4);
b) a recording unit (page 8, line 2, "memory 22 of the IC card 2") configured to record data defined by definition information (Figure 4, "data object 14", "virtual memory management index 150 of the card 2", "applicative index 160 located in the card 2", "non-resident object indexes 58", "object dictionary 68");
c) a first reception processor (Figure 1) configured to receive a read command (figures 5, 20 and 21, steps 100 - 106, "reading request", Figures 9 and 10, see section 3.4, step (i)) from the external terminal via the communication unit (Figure 1), which read command requests to read data (object index, see section 3.4 above, step (i)) in the recording unit (22);
d) a determination unit (Figure 9, step 136) configured to determine (see section 3.4 above, step (ii)) whether data required for execution of the read command (encrypted version of object index) is stored in the recording unit ("resident object") or in an external device ("non-resident object", page 16, lines 18 to 25), if the first reception processor receives the read command; and
e) a first transmission processor configured to transmit a response indicating start of a session (Figures 20 and 21, array pointing from smart card 2 to BDA 74, Figure 11: "transmit request to BDA", see section 3.4, step (iii)), which is required to acquire related data (encrypted version of the data object, see section 3.4, steps (viii) and (ix)) from the external terminal (4, 6), the related data (encrypted version of the data object, see section 3.4, steps (viii) and (ix)) being related to the data (encrypted version of object index, see section 3.4, step (iv)) required for the execution of the read command (see section 3.4, step (i)), to the external terminal (4, 6) via the communication unit, if the determination unit determines that the data (encrypted version of object index, see section 3.4, step (iv)) required for the execution of the read command (section 3.4, step (i)) is stored in the exterior of the smart card (Figure 9, 136, NO, see section 3.4, step (ii)).
Moreover, the smart card necessarily includes the elements (transmission and reception processors) configured to perform the above operations.
4.2 The appellant's arguments - see section VI. above - could not convince the Board for the reasons as follows:
4.2.1 ad VI.(a):
According to the present application, an external terminal 1 includes a CPU 11, a memory 12 and a communication unit 13, all connected via a system bus, see Figure 1, page 8 to 12. The Board considers that the computer 4 with the card reader 6 shown in Figure 3 of D3 is therefore to be considered as the external terminal within the meaning of claim 1. The term "external terminal" is thus not limited to the application run in computer 4.
As shown in Figure 1 of D3, servers 8 with storage media 12 are connected to computer 4 via a network 10. From page 6, lines 19 to 26, page 7, lines 3 to 9 and Figure 1 a skilled reader of D3 understands that any exchange of instructions between the smart card 2 and the database BDA is performed through the computer 4, once the smart card is put into the card reader 6. In other words, any request transmitted from the smart card to the BDA or any response of BDA received at the smart card 2 necessarily implies corresponding transmission to/responses from the external terminal, i. e. computer 4.
In other words, step (iii) according to section 3.4 above involves a transmission of a response to the external terminal in the sense of feature e).
4.2.2 ad VI.(b):
The Board is of the view that the terms "a response indicating start of a session" and "related data" are to be understood broadly.
The "read command" in D3 (see section 3.4, step (i)) corresponding to feature feature c) of claim 1 concerns a read request for reading a non-resident object index so that the "data required for the execution of the read command" is the encrypted version of said object index.
It follows that the "related data", which is "related to the data required for execution of the read command" can be any data somehow linked or associated to the encrypted version of said object index. It is the Board's view that the encrypted version of the data object received by the smart card in step (ix) (see section 3.4 above) falls under this definition. Hence, in the Board's understanding, a session in the sense of feature e) of claim 1 is an exchange of instructions and/or data between the smart card and the external terminal with the aim to acquire said encrypted version of the data object.
As the request according to step (iii) in the process of section 3.4 above implies a response from the smart card to the external terminal and triggers an exchange of instructions and data (steps (iv) to (ix)) between the smart card 2 and the external terminal 4, 6 in order to acquire the encrypted version of the data object (steps (viii) and (ix)), it is a response "indicating the start of a session" in the sense of feature e).
The Board is also of the view that the basic communication hierarchy (see section 3.4) between the terminal and the smart card is retained in D3, i. e. the terminal sends commands (see steps (i), (iv), (vi), (ix)) and the smart card responds (see steps (ii)/(iii), (v), (vii)/(viii), (x)).
4.2.3 ad VI.(c):
The Board is of the opinion that the wording to claim 1 does not exclude that two reading requests, one for an object index and one for the corresponding data object, are received by the smart card from the external terminal. As stated before, the smart card reacts to the reading request for a non-resident object index by starting a "session" required to acquire an encrypted version of the data object.
4.3 The Board is therefore of the opinion that the subject-matter of claim 1 according to the main request is not novel (Articles 52(1), 54(1) and (2) EPC) over the disclosure of document D3.
5. First auxiliary request
5.1 For the reasons given for the main request, features a) to e) are known from D3.
The smart card (2) according to D3 further comprises:
f) a second transmission processor (Figure 11, "Transmit request to BDA", see section 3.4, step (viii), corresponding to step S5 in Figure 4 of the present application) configured to transmit a proactive command (see section 3.4, step (viii)) required to acquire the related data (encrypted version of the data object, Figure 11, see section 3.4, steps (viii) and (ix)) related to the data (encrypted version of the object index, see section 3.4, step (iv)) required for execution of the read command (see section 3.4, step (i)) from the external terminal (4, 6) after the first transmission processor (see section 4.1, feature e)) outputs the response indicating the start of the session to the external terminal (4, 6);
g) a second reception processor configured to receive a terminal response command (Figure 11, "Receive response of BDA", see section 3.4, step (ix), corresponding to step S7 of Figure 4 of the application) including the related data (encrypted version of the data object, see section 3.4, steps (viii) and (ix)) from the external terminal (4, 6) as a response to the proactive command (Figure 11, see section 3.4, step (viii));
h) a third transmission processor configured to output an execution result of the read command (Figure 10, "Return object to requesting source"; Figure 5, 116, "Application receives reading result"; see section 3.4, step (x), decrypted version of data object, corresponding to step S8 in Figure 4 of the present application) as a response to the terminal response command (see section 3.4, step (ix)); and
i) a third reception processor configured to receive a command transmission request command (Figure 5, steps 100 - 106, after step 122, see section 3.4, step (vi)), which requests to transmit the proactive command (see section 3.4, step (viii)), from the external terminal (4, 6) after the first transmission processor outputs the response indicating the start of the session (see section 4.1 above, Figure 5, see section 3.4, step (iii)), and before the second transmission processor
outputs the proactive command (Figure 5, see section 3.4, step (viii)),
j) wherein the second transmission processor transmits the proactive command (Figure 5, see section 3.4, step (viii)) based on reception of the transmission request command (see section 3.4, step (vi)), which requests to transmit the proactive command, from the external terminal (4, 6) after the first transmission processor outputs the response indicating the start of the session (see section 4.1 above, Figure 5, see section 3.4, step (iii)) to the external terminal (4, 6).
As indicated above document D3 necessarily discloses a smart card including the elements (transmission and reception processors) configured to perform the above operations.
5.2 The appellant's arguments - see section VI. above - could not convince the Board for the reasons as follows:
5.2.1 ad VI.(a) to (c): see section 4.2.1 above
For the same reasons as given for the main request, the Board takes the view that a "proactive command" in the sense of feature f) is transmitted from the smart card 4 to the external terminal in step (viii) of the method known from D3 and that a "terminal response" in the sense of feature g) is transmitted from the terminal to the smart card in step (ix) of the method of D3.
5.2.2 ad VI.(d):
As stated in section 3.4 above, the relevant embodiment in D3 is a method, wherein an external terminal requests to read a non-resident data object from a smart card. The method requires that the corresponding non-resident object index and the non-resident data object itself are sequentially read. The Board is of the view that the term "execution result of the read command" is to be interpreted broadly. Therefore, the "execution result" of the read command (see section 3.4, step (i)) is the decrypted version of the data object, which is transmitted at the end of the process to the external terminal (see section 3.4, step (x)) as the smart card's final output to the computer 4. The provision of the decrypted object index (step (v)) can be considered an intermediate result.
5.2.3 ad VI.(e):
Since the term "proactive command" defines a command sent by the smart card based on a decision of the smart cart (e. g. command sent in step (viii) after step (vii) according to the method of section 3.4 above), the expression "command transmission request command, which requests to transmit the proactive command" is not limited to a command that prompts the smart card to transmit directly a command to the application.
Rather, the Board is of the view that the term "command transmission request command" is to be interpreted more broadly, namely as any instruction (or command) from the external terminal that requests to send data with the direct consequence that the smart card transmits a command e. g. to acquire data. In the method known from document D3 (see section 3.4 above), the request for reading a non-resident data object (step (vi)) necessarily implies that the smart card transmits a request ("proactive command", step (viii)) via the terminal 4, 6 to the BDA in order to acquire the encrypted version of the data object, i. e. the "related data". Step (vi) thus entails that the smart card 2 transmits a "command", namely the read command to the BDA 74 (step (viii)) via the terminal 4, 6 so that step (vi) concerns a "command transmission request command" in the sense of feature i).
5.3 Hence the Board is of the opinion that the subject-matter of claim 1 according to the first auxiliary request is not novel (Articles 52(1), 54(1) and (2) EPC) over the disclosure of document D3.
6. Second auxiliary request
According to Article 13(2) RPBA 2020, which is applicable in the present case (Article 25 RPBA 2020), any amendment to a party's appeal case made after notification of a summons to oral proceedings shall, in principle, not be taken into account unless there are exceptional circumstances, which have been justified with cogent reasons by the party concerned.
The Board does not question the admission of the main request and the first auxiliary request, as they correspond to the main request and the second auxiliary request underlying the impugned decision with amendments made to address and indeed overcome the objections under Articles 123(2) and 84 EPC raised for the first time in the Board's communication pursuant to Article 15(1) RPBA 2020.
However, the Board is of the view that the amendments made to claim 1 of the second auxiliary request not only address clarity objections raised by the Board, but also introduce new aspects that have never been discussed in the context of an independent claim, namely the encryption/decryption of data objects. Furthermore, the the appellant has not provided any reasons why the second auxiliary request would overcome the objections under Articles 52(1), 54(1) and (2) EPC raised against the higher ranking requests, neither in the letter dated 9 December 2020 nor during the oral proceedings before the Board. No arguments were submitted by the appellant why the amendments made to claim 1 according to the second auxiliary request would render claim 1 novel over D3 or justify the presence of an inventive step. Moreover, the Board cannot agree with the appellant's statement that the admission of the second auxiliary request would not protract the proceedings.
Hence, the Board is of the view that no exceptional circumstances have been justified for the late amendments, i.e. the filing of the second auxiliary request, which is therefore not taken into account under Article 13(2) RPBA 2020, i.e. not admitted into the appeal proceedings.
7. As no allowable request is on file, the appeal must fail.
For these reasons it is decided that:
The appeal is dismissed.