T 1608/15 (Personalisation of a UICC/GEMALTO) of 21.5.2019

European Case Law Identifier: ECLI:EP:BA:2019:T160815.20190521
Date of decision: 21 May 2019
Case number: T 1608/15
Application number: 11791540.5
IPC class: H04W 8/20
G06F 21/00
H04L 29/06
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 282 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: METHOD FOR REMOTELY DELIVERING A FULL SUBSCRIPTION PROFILE TO A UICC OVER IP
Applicant name: Gemalto SA
Opponent name: -
Board: 3.5.03
Headnote: -
Relevant legal provisions:
European Patent Convention Art 56
Keywords: Inventive step - (no)
Catchwords:

-

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division refusing European patent application No. 11791540.5, with international publication number WO 2012/076425 A1. The refusal was based on the ground that the subject-matter of independent claim 1 did not involve an inventive step having regard to the disclosure of document D6 (= WO 2009/141024 A1) and taking into account the common general knowledge of the skilled person.

II. The appellant requests that the decision under appeal be set aside and that a patent be granted on the basis of a sole request, submitted on 24 September 2014.

III. Claim 1 reads as follows:

"Method for remotely delivering a full subscription profile to a UICC over IP, said UICC being installed in a terminal able to provide an IP connectivity to a remote server and give access to said UICC, said UICC being pre-personalised with a unique serial number and with a bootstrap application and bootstrap credentials allowing to establish a secure transport channel with said remote server, said remote server hosting a stock of subscription profiles and acting as a web server, said method consisting in [sic]:

- opening (101), at the request of said UICC, a data channel between said terminal and said server;

- performing (102) a mutual authentication between said UICC and said server by using said bootstrap credentials;

- requesting (103), from said UICC to said server, the delivery of a subscription profile by using said unique serial number;

- if a subscription profile exists for said UICC, downloading (106, 107) said subscription profile to said UICC."

Reasons for the Decision

1. Claim 1 - inventive step

1.1 D6 is considered to represent the closest prior art. It relates to a method for the personalisation of a smart card (SIM) in which an individual subscriber record is transmitted to and stored on the SIM (abstract).

More particularly and using the language of claim 1, D6 discloses that the SIM, which may be a UICC (page 1, penultimate paragraph), is pre-personalised with a unique serial number ("Seriennummer (ICCID)", page 7, first paragraph) and with a bootstrap application and bootstrap credentials ("Satz (S*) initialer Identifizierungs- und Authentisierungsparameter" including a preliminary subscriber identification "IMSI*i", abstract) allowing to establish a secure transport channel to a remote server ("Personalisierungs-Server PS"; after transmitting the preliminary subscriber identification IMSI*i, a connection between the SIM and the remote server is established, page 10, second and fourth paragraphs). The SIM is implicitly installed in a terminal and the connectivity provided by the terminal may also use TCP/IP (page 12, fifth paragraph, or page 13, third and fourth bullet points).

Operating the SIM for the first time triggers the execution of the following steps which therefore are executed at the SIM's request (page 10, first paragraph, and Fig. 1):

- opening, at the request of the SIM, a data channel between said terminal and said server ("... sichere OTA-Session nach dem Stand der Technik zur betreffenden SIM ..." , page 10, second and fourth paragraphs);

- performing a mutual authentication between said SIM and said server by using said bootstrap credentials (page 10, second paragraph);

- requesting, from said SIM to said server, the delivery of a subscription profile ("Dazu werden endgültige Teilnehmerdaten ... zur SIM gesendet und dort gespeichert ...", page 10, fourth and fifth paragraphs, and page 11, first paragraph) by using said unique serial number (prior to the personalisation including the delivery of the subscription profile the serial number ICCID may be checked which is a use of the serial number, page 10, fifth paragraph; see point 1.5.1 below).

1.2 The method of claim 1 thus differs from the method disclosed in D6 in that (i) the remote server acts as a web server, and (ii) the server hosts a stock of subscriptions profiles and acts as a web server and, if a subscription profile exists for the requesting UICC, this subscription profile is downloaded.

1.3 Re (i): The use of a web server is commonplace and here does not contribute to inventive step, especially as D6 already suggests the use of TCP/IP for OTA applications and the internet for wired applications (see also point 1.5.2 below).

1.4 Re (ii):

1.4.1 The technical effect of a remote server hosting a stock of subscription profiles is that the time for generating the requested subscription profile can be saved and the personalisation process thereby accelerated.

1.4.2 Starting out from the method of D6, the technical problem underlying this feature may be seen as to reduce the response time of the server for the delivery of the subscription profile.

1.4.3 It is well-known that any computation, like the generation of the final personalisation profile S (D6, page 7, fourth paragraph and Fig. 1, "generieren IMSI, K, OPc, Qc, OK"), is time-consuming. D6 does not disclose that, for the generation of the final personalisation profile S comprising IMSI, K, OPc, Qc, OK for a specific UICC, any information is required from the UICC, and consequently the profiles S can be generated in advance. It is therefore obvious that computation time at the moment the profiles are requested can be saved by generating the profiles S in advance and by storing them on the server (see also point 1.5.3 below).

1.4.4 In view of the above, the skilled person, when starting out from the method of D6 and faced with the above-mentioned problem, would, based on common general knowledge, implement the remote server as web server and arrange for the remote server to host a stock of subscription profiles, thereby arriving at a method which includes all the features of claim 1 without exercising inventive skill.

1.5 Appellant's arguments

1.5.1 The appellant argues that D6 does not disclose that the subscription profile to be downloaded to a UICC is selected in view of its ICCID (Integrated Circuit Card Identifier); in D6, the ICCID is only used to check whether or not the corresponding card is blacklisted. Further, with reference to page 7, first paragraph, it argues that in D6 it is not mandatory to send the ICCID.

The board notes that the corresponding feature of claim 1 reads "requesting (103), from said UICC to said server, the delivery of a subscription profile by using said unique serial number" (underlining added by the board). The wording "using" embraces the use of the ICCID to check whether the corresponding UICC is black- or whitelisted. In D6 the card, after the check with respect to a white or black list, is individually personalised (page 11, line 2) and D6, in a list of possible embodiments, makes reference to a card-specific personalisation("kartenspezifische Personalisierung", page 13, eleventh bullet point). Thus, an individual or card-specific personalisation is generated for the respective card and, hence, D6 also discloses the generation of a specific subscription profile based on a unique serial number of the UICC (cf. page 7, last paragraph).

1.5.2 The appellant further argues that in the method of claim 1 the UICC does not connect itself to the network of an operator but to a dedicated server hosting a plurality of subscription profiles and acting as a web server, whereas in D6 the temporary parameters are used to connect to a given operator.

As noted above, D6 discloses transmitting the subscription profiles over the internet ("Internet", page 12, fifth paragraph), and using wired or wireless IP channels ("LAN", "WLAN", page 12, penultimate bullet point, page 13, fourth bullet point). Further, the method of claim 1 does not exclude that the server belongs to a given operator or that the connection between the server and the UICC includes the operator's network. Further, claim 1 does not stipulate that for the steps 101 to 103 prior to the download of the subscription profile the IP connection is used.

1.5.3 The appellant further argues that in the method of D6 the subscription profiles are not held as a stock of profiles but generated on the fly as required. This may cause serious delays in circumstances in which the personalisation of many UICCs in a short period of time is requested, for example when mobile phones are given as Christmas presents.

The board notes that claim 1 is not limited to the personalisation of many UICCs in a short space of time but embraces embodiments where this advantage would be minimal. That notwithstanding, the advantage of saving time for the simultaneous personalisation of many UICCs comes as no surprise. Indeed, the manifestation of serious delays caused by performing calculations on the fly would rather prompt the skilled person to take the obvious step of performing calculations in advance. The board therefore finds the appellant's argument unconvincing.

1.6 In view of the above, the board concludes that the subject-matter of claim 1 of the main request does not involve an inventive step (Articles 52(1) and 56 EPC). The request is therefore not allowable.

Order

For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation