DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant’s arguments, see pages 1-5, filed 07/07/2026, with respect to the rejection of claims 1-8, 10, and 12-19 35 U.S.C. § 112(b) have been fully considered. The rejection of claims 1-8, 10, and 12-19 35 U.S.C. § 112(b) has been withdrawn in response to the amended claims rectifying the antecedent basis issues.
Applicant's arguments, see pages 5-15, filed 07/07/2026, with respect to the rejection of claims 1-8, 10, and 12-15 under 35 U.S.C. § 102(a)(1) have been fully considered but they are not persuasive.
Applicant first argues on page 6 that the previously presented Long reference is “fundamentally different from that of the pending claims, in which the assigned role, corresponding to the authorized administrative action, is contained within the administrative entity's certificate itself. In the pending claims, the certificate, signed by the master entity's secret key, serves as the carrier for the authorization information. The structure of this embodiment of Long does not disclose the integration of the authorization into the certificate (the PKI certificate of the SM-SR)”.
The Examiner respectfully disagrees.
The claim merely recites “said certificate of the administrative entity… containing information indicated a role assigned by the master entity to the administrative entity, the assigned role corresponding to an authorized administrative action”. The BRI of this limitation is clearly met by Long disclosing at least the SM-SR of Long sending a request comprising at least a certificate signed by a master entity (met under the BRI by the CA disclosed by Long), the request disclosed by Long may include a management operation type (which meets the BRI of the claimed “role”) and it is then checked that the authorization information allows the SM-SR to execute the management operation type upon the eUICC (see Long [0049-0051]).
Applicant’s argument that “It is clear from this paragraph that the authorization check relies exclusively on the first authorization information (list of identifiers), without any reference to the optionally transmitted "management operation type". In other words, even when the operation type is sent by the SM-SR, the eUICC does not use it to determine whether the entity is authorized to perform that operation” is particularly moot as the claims do not require such an operation of using the operation type to determine whether the entity is authorized to perform the operation. The claim recites sending an authorization to execute in response to a verification that the certificate of the administrative entity is legitimate (clearly anticipated by Long disclosing the eUICC verifying validity of the certificate) [this is the only verification claimed] and if the administrative action of the request to execute an administrative action is identical to the authorized administrative action corresponding to the assigned role (clearly anticipated by Long disclosing at least in paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type). There is no “step of comparing two distinct administrative actions” currently claimed as Applicant argues.
Applicant then makes the conclusory argument and alleges on pages 6-7 without evidence “Long neither discloses nor suggests that a master entity signs the SM-SR entity's certificate so as to encode therein a role corresponding to an authorized administrative action. The certificate sent by the SM-SR is a PKI certificate issued by a CA, without any role specific to an administrative action being inscribed therein by a master entity. The trust model of Long is that of a general-purpose CA certifying the identity of the SM- SR, not that of a master entity assigning roles by signing administrative entity certificates”.
The Examiner respectfully disagrees.
The claim does not require any “inscribed” as argued by the Applicant, the claim only requires “contains information indicating a role assigned by the master entity to the administrative entity”. Long discloses at least in paragraphs [0091-0095] whether the token to perform management operations is correct, and that the tokens separately authorize different management operation types; further paragraphs [0049-0051] of Long explicitly discloses at least the SM-SR entity sending its PKI certificate signed by a CA and a management operation type.
Applicant then argues on page 7 that the pending independent claims allegedly differ from the Long reference because the claims allegedly require “comparison between an administrative action and an authorized administrative action”, no such comparison is claimed. No “comparative verification” that “determines whether the authorized administrative action corresponds to the administrative action to be executed” is claimed either. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant next argues on page 7 without evidence that “In Long, the authorization
information is stored in a credential or certificate belonging to the eUICC. In the pending claims, the information that serves for authorization purposes is the role corresponding to the authorized administrative action and is carried by the certificate of the administrative entity itself”. Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections.
Applicant then argues on page 7 about the alleged “nature of the authorization information”. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant next argues on page 8 that there is allegedly “no master entity present in the Figures 2/3 embodiment”.
The Examiner respectfully disagrees.
In the Non-Final Rejection mailed 04/07/2026, the claimed master entity was properly mapped as being clearly anticipated by the CA of Long (see Non-Final rejection mailed 04/07/2026 pages 3-4).
Applicant then argues on page 9 that the pending claims are fundamentally different as the authorized administrative action is allegedly derived from the role encoded in the certificate of the administrative entity. No such derivation is currently claimed.
Applicant next argues on page 9 that, “The pending claims are built on an entirely different trust model: the authorized administrative action is derived from a role encoded in the certificate of the administrative entity (using information related to the role that is contained in the certificate), the certificate being signed by a master entity. The security module verifies the certificate's legitimacy through public-key cryptography, not by matching tokens”.
The Examiner respectfully disagrees.
Long explicitly discloses at least verification of PKI certificates, and the currently claimed role is recited at such a high level of generality that it is clearly anticipated by paragraphs [0091-0095] of Long disclosing at least that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”.
Applicant then argues on pages 9-10 that there is allegedly no master entity signing roles by certificate signature. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “that there is allegedly no master entity signing roles by certificate signature”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claims only require that the certificate contains information indicated a role.
Applicant next argues on page 11 the technical effects of the invention. The Examiner respectfully submits that the illustration is helpful, however, although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant then argues on page 12 regarding claims 3 and 13 their own summarization of the Long reference and alleges that Long “does not disclose, and does not suggest, that a certificate of the requesting administrative entity (the SM-SR in the embodiment of figures 2 and 3) itself should contain a field encoding a role - as distinct from an identity - that corresponds to an authorization to execute a given authorized administrative action”. Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not particularly point out the alleged deficiencies in the previously presented rejection and are based upon Applicant’s summarization of the Long reference.
Applicant then argues on pages 12-13 regarding claims 4 and 14 their own summarization of the Long reference and alleges that “This feature corresponds to the second embodiment described in the description with reference to Figure 3B, in which the master entity holds a distinct certificate per role - CertInstall, CertEnD, CertDel - and uses the secret key of the role-specific certificate to sign the certificate of the corresponding administrative entity. The role is thereby encoded not in a field of the certificate (as in the first embodiment of claims 3 and 13), but by virtue of the identity of the signing certificate itself: the security module, holding the public key of each role-specific certificate, can determine which role was assigned by verifying which role-specific key was used to sign the administrative entity's certificate. Long discloses no structure remotely analogous to this mechanism. In neither the embodiment of Figures 2/3 nor the embodiment of Figure 4 does Long describe a master entity holding role-specific certificates whose secret keys are used to sign the certificates of administrative entities”. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “This feature corresponds to the second embodiment described in the description with reference to Figure 3B… The role is thereby encoded not in a field of the certificate (as in the first embodiment of claims 3 and 13), but by virtue of the identity of the signing certificate itself”, etc.) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Claims 4 and 14 merely require that the certificate of the master entity be “associated” with the role at a high level of generality.
Applicant next argues on pages 13-14 regarding claims 16 and 17 that Long allegedly does not disclose a master entity that is entitled to assign multiple roles and that “The roles in the pending claims are conferred by the master entity through the act of signing the certificate of the administrative entity - for example by encoding a role field in the certificate (first embodiment) or by using a role-specific signing certificate (second embodiment). There is no entity in Long that assigns roles in this manner, let alone a master entity entitled to assign a plurality of such roles. Furthermore, the several roles of claims 16 and 17 are structurally tied to the certificates of the respective administrative entities: each administrative entity's certificate encodes the role - and therefore the authorized administrative action - assigned to it by the master entity. Long contains no disclosure of this certificate-based, master-entity-driven plurality of roles”.
The Examiner respectfully disagrees.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “The roles in the pending claims are conferred by the master entity through the act of signing the certificate of the administrative entity… the several roles of claims 16 and 17 are structurally tied to the certificates of the respective administrative entities: each administrative entity's certificate encodes the role”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Claims 16 and 17 merely require that the assigned role to the administrative entity is one among several and that the roles correspond to different actions. This is clearly anticipated by Long disclosing at least that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type.”
Applicant lastly argues on pages 14-15 that new claims are allegedly allowable over Long. The Examiner defers to the rejection below in response to this argument.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-8, 10, 12-19, and 21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Long Shuiping (EP 3073770 A1) hereinafter Long.
Regarding Claim 1:
Long discloses a method of administration of a profile for access to a communication network by a security module (Long Fig. 3A-3B), said method comprising: receiving a request to execute an administrative action relating to an access profile from an administrative entity (Long [0048-0050] administrative actions “the SM-SR entity also sends an eUICC management operation type (for example, profile installation, profile downloading, profile enabling, profile disabling, profile status switching, profile deletion, or an associated SM-SR change) to the eUICC.”; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said request comprising a certificate of said administrative entity (Long [0048-0050] “the SM-SR entity sends a certificate and a signature to the eUICC.”; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said certificate of the administrative entity being signed by a secret key of a master entity and containing information indicating a role assigned by the master entity to the administrative entity (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]), the assigned role corresponding an authorized administrative action (Long [0049-0054], Figure 4 and paragraphs [0091-0095]; [0038] and [0119]); sending an authorization to execute the administrative action in cooperation with the administrative entity in response to a verification that the certificate of the administrative entity is legitimate and if the administrative action is identical to the authorized administrative action corresponding to the assigned role (Long [0057], [0049-0055] verification process; Figure 4 and paragraphs [0091-0095] token is verified to be correct and the entity is authorized to perform the requested management operation; [0038] and [0119]); and sending a rejection of the execute request in if the administrative action is different from the authorized administrative action (Long [0055] failure message sent if verification has failed; Figure 4 and paragraphs [0091-0095] no is sent if entity is not authorized because token is not correct; [0038] and [0119]).
Regarding Claim 2:
Long discloses a method of administration of a profile for access to a communication network by an administrative entity, said method comprising (Long Fig. 3A-3B): sending to a security module a request to execute an administrative action relating to an access profile (Long [0048-0050]; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said request comprising a certificate of said administrative entity (Long [0048-0050]; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said certificate containing information indicating a role assigned to the administrative entity by a master entity (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]), said certificate of the administrative entity being signed by a secret key of the master entity (Long [0049-0054], Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), the assigned role corresponding to an authorized administrative action (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]); and receiving an authorization to execute the action in cooperation with the security module, in response to a verification by the security module that the certificate of the administrative entity is legitimate and if the administrative action is identical to the authorized administrative action corresponding to the assigned role (Long [0057], [0067], [0071], [0049-0054] verification process; Figure 4 and paragraphs [0091-0095] token is verified to be correct and the entity is authorized to perform the requested management operation; [0038] and [0119]).
Regarding Claim 3:
Long discloses the method as claimed in claim 1 (Long Fig. 3A-3B), wherein the information indicating the role assigned to the administrative entity is comprised in a field of the certificate (Long [0051-0054], Figure 4 and paragraphs [0091-0095]).
Regarding Claim 4:
Long discloses the method as claimed in claim 1 (Long Fig. 3A-3B), wherein the secret key used by the master entity to sign the certificate of the administrative entity is the secret key of a certificate of the master entity, said certificate of the master entity being associated with the role assigned to the administrative entity (Long [0053] certificate information, [0049-0054] signature verification).
Regarding Claim 5:
Long discloses the method as claimed in claim 1 (Long Fig. 3A-3B), wherein the authorized administrative action belongs to the group consisting of downloading an access profile, enabling an access profile, disabling an access profile, and deleting an access profile (Long [0048-0050] administrative actions, [0091-0095]).
Regarding Claim 6:
Long discloses a security module, configured to store in memory a profile for access to a communication network, said module comprising: a processor; and a non-transitory computer-readable medium (Long Fig. 8, [0116]) comprising instructions stored thereon which when executed by the processor configure the security module to (Long Fig. 1, [0106-0109] eUICC security module, Fig. 3A-3B): receive a request to execute an administrative action relating to an access profile from an administrative entity (Long [0048-0050] administrative actions “the SM-SR entity also sends an eUICC management operation type (for example, profile installation, profile downloading, profile enabling, profile disabling, profile status switching, profile deletion, or an associated SM-SR change) to the eUICC.”; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said request comprising a certificate of said administrative entity (Long [0048-0050] “the SM-SR entity sends a certificate and a signature to the eUICC.”; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said certificate of the administrative entity being signed by a secret key of a master entity and containing information indicating a role assigned to the administrative entity by the master entity (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]), the role corresponding to an authorized administrative action (Long [0049-0054], Figure 4 and paragraphs [0091-0095]; [0038] and [0119]); and authorize execution of the administrative action in cooperation with the administrative entity in response to a verification that the certificate received is legitimate and if the administrative action is identical to the authorized administrative action corresponding to the assigned role (Long [0057], [0049-0054] verification process; Figure 4 and paragraphs [0091-0095] token is verified to be correct and the entity is authorized to perform the requested management operation; [0038] and [0119]).
Regarding Claim 7:
Long discloses an administrative entity for administering a profile for access to a communication network, said entity comprising: a processor; and a non-transitory computer-readable medium comprising instructions stored thereon which when executed by the processor configure the administrative entity to (Long [0117-0118] admin entity can be implemented with memory and a processor, Fig. 3A-3B): send, to a security module, a request to execute an administrative action relating to an access profile (Long [0048-0050]; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said request comprising a certificate of said administrative entity (Long [0048-0050]; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said certificate of the administrative entity containing information indicating a role assigned to the administrative entity by a master entity (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]), said certificate of the administrative entity being signed by a secret key of the master entity (Long [0049-0054], Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), the role corresponding to an authorized administrative action (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]), and receive an authorization to execute the administrative action in cooperation with the security module, in response to a verification by the security module that the certificate is legitimate and if the administrative action is identical to the authorized administrative action corresponding to the assigned role (Long [0057], [0067], [0071], [0049-0054] verification process; Figure 4 and paragraphs [0091-0095] token is verified to be correct and the entity is authorized to perform the requested management operation; [0038] and [0119]).
Regarding Claim 8:
Long discloses an administrative system comprising the administrative entity as claimed in claim 7 (Long [0117], Fig. 3A-3B) and a master entity that is configured to sign the certificate of the administrative entity ([0053] certificate information contains issuer name and validity period), said certificate of the administrative entity containing the information indicating the role assigned to the administrative entity (Long [0051-0054]).
Regarding Claim 10:
Long discloses a non-transitory computer-readable storage medium comprising program-code instructions stored thereon (Long Fig. 8, [0116]) to command execution of a method of administration of a profile for access to a communication network, when the instructions are executed by a processor of a security module, said method comprising (Long [0116-0117], Fig. 3A-3B): receiving a request to execute an administrative action relating to an access profile from an administrative entity (Long [0048-0050] administrative actions “the SM-SR entity also sends an eUICC management operation type (for example, profile installation, profile downloading, profile enabling, profile disabling, profile status switching, profile deletion, or an associated SM-SR change) to the eUICC.”; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said request comprising a certificate of said administrative entity (Long [0048-0050] “the SM-SR entity sends a certificate and a signature to the eUICC.”; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said certificate of the administrative entity being signed by a secret key of a master entity and containing information indicating a role assigned to the administrative entity by the master entity (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]), the assigned role corresponding to an authorized administrative action (Long [0049-0054], Figure 4 and paragraphs [0091-0095]; [0038] and [0119]); sending an authorization to execute the administrative action in cooperation with the administrative entity in response to a verification that the certificate of the administrative entity is legitimate and if the administrative action is identical to the authorized administrative action corresponding to the assigned role (Long [0057], [0049-0055] verification process; Figure 4 and paragraphs [0091-0095] token is verified to be correct and the entity is authorized to perform the requested management operation; [0038] and [0119]); and sending a rejection of the execute request in if the administrative action is different from the authorized administrative action (Long [0055] failure message sent if verification has failed; Figure 4 and paragraphs [0091-0095] no is sent if entity is not authorized because token is not correct; [0038] and [0119]).
Regarding Claim 12:
Long discloses a non-transitory computer-readable storage medium comprising program-code instructions stored thereon (Long [0117-0118]) to command execution of a method of administration of a profile for access to a communication network by an administrative entity, when the instructions are executed by a processor of the administration entity, said method comprising (Long [0117], Fig. 3A-3B): sending to a security module a request to execute an administrative action relating to an access profile (Long [0048-0050]; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said request comprising a certificate of said administrative entity (Long [0048-0050]; Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), said certificate of the administrative entity containing information indicating a role assigned to the administrative entity by a master entity (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]), said certificate being signed by a secret key of the master entity (Long [0049-0054], Figure 4 and paragraphs [0091-0095]; [0038] and [0119]), the assigned role corresponding to an authorized administrative action (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]); and receiving an authorization to execute the action in cooperation with the security module, in response to a verification by the security module that the certificate of the administrative entity is legitimate and if the administrative action is identical to the authorized administrative action corresponding to the assigned role (Long [0057], [0067], [0071], [0049-0054] verification process; Figure 4 and paragraphs [0091-0095] token is verified to be correct and the entity is authorized to perform the requested management operation; [0038] and [0119]).
Regarding Claim 13:
Long discloses the method as claimed in claim 2 (Long Fig. 3A-3B), wherein the information indicating the role assigned to the administrative entity is comprised in a field of the certificate (Long [0051-0054]).
Regarding Claim 14:
Long discloses the method as claimed in claim 2 (Long Fig. 3A-3B), wherein the secret key used by the master entity to sign the certificate of the administrative entity is the secret key of a certificate of the master entity, said certificate of the master entity being associated with the role assigned to the administrative entity (Long [0053] certificate information, [0049-0054] signature verification).
Regarding Claim 15:
Long discloses the method as claimed in claim 2 (Long Fig. 3A-3B), wherein said authorized administrative action belongs to the group consisting of downloading an access profile, enabling an access profile, disabling an access profile, and deleting an access profile (Long [0048-0050]).
Regarding Claim 16:
Long discloses the method as claimed in claim 1 (Long Fig. 3A-3B), wherein the assigned role assigned to the administrative entity is one among several roles that the master entity is entitled to assign (Long [0048-0054]), the several roles corresponding to different authorized administrative actions (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]).
Regarding Claim 17:
Long discloses the method as claimed in claim 2 (Long Fig. 3A-3B), wherein the assigned role assigned to the administrative entity is one among several roles that the master entity is entitled to assign (Long [0048-0054]), the several roles corresponding to different authorized administrative actions (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]).
Regarding Claim 18:
Long discloses the method according to claim 16 (Long Fig. 3A-3B), wherein the several roles comprise one or more of the following roles: a role of an install entity corresponding to an authorized administrative action being to download of an access profile; a role of an enable/disable entity corresponding to an authorized administrative action being to enable or disable an access profile; a role of a delete entity corresponding to an authorized administrative action being to delete an access profile (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]).
Regarding Claim 19:
Long discloses the method according to claim 17 (Long Fig. 3A-3B), wherein the several roles comprise one or more of the following roles: a role of an install entity corresponding to an authorized administrative action being to download of an access profile; a role of an enable/disable entity corresponding to an authorized administrative action being to enable or disable an access profile; a role of a delete entity corresponding to an authorized administrative action being to delete an access profile (Long [0049-0054], Figure 4 and paragraphs [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0038] and [0119]).
Regarding Claim 21:
Long discloses the method as claimed in claim 14 (Long Fig. 3A-3B), wherein the master entity has a plurality of certificates, a respective one of said certificates of the master entity being associated with a respective role among several roles that the master entity is entitled to assign (Long [0053] certificate information, [0049-0054] signature verification, paragraph [0050] discloses that the CA of Long issued a SM-SR a PKI certificate for the SM-SR and then paragraph [0058] discloses that the CA of Long also issued an eUICC another PKI certificate; [0091-0095] that a SM-DP entity, communicating with a SM-SR entity as well, may communicate to a eUICC and include, in the sent authorization information, included in an X.509 certificate, contains a token or multiple tokens “which indicates that an SM-DP entity that has the Token 1 is authorized to perform management. It should be noted that SM-DP token information may include multiple tokens (Token 1, Token 2, ...), so as to separately authorize different management operation types. For example, the Token 1 is used to authorize a profile load management operation type, and a Token 2 is used to authorize a profile installation management operation type”; [0119]).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 20 is rejected under 35 U.S.C. 103 as being unpatentable over Long.
Regarding claim 20:
Long teaches the method as claimed in claim 4 (Long Fig. 3A-3B), wherein the security module stores a plurality of public keys stored in memory (Long [0051-0053] ), a respective one of said public keys being associated with a respective role among several roles that the master entity is entitled to assign (Long [0053] certificate information, [0049-0054] signature verification), the security module being configured to verify the certificate of the administrative entity by means of the one of said public keys that is associated with the role assigned to the administrative entity (Long [0057], [0067], [0071], [0049-0054] verification process; Figure 4 and paragraphs [0091-0095] token is verified to be correct and the entity is authorized to perform the requested management operation; [0038] and [0119]).
Although the Long reference does not explicitly disclose a plurality of keys per se, the Long reference discloses at least a CA having a public key and assigning a certificate to at least a SM-SR entity and assigning a certificate to at least a eUICC (more specifically, paragraph [0050] discloses that the CA of Long issued a SM-SR a PKI certificate for the SM-SR and then paragraph [0058] discloses that the CA of Long also issued an eUICC another PKI certificate). Therefore, the claim limitations at issue are obvious in view of Long because although the Long reference does not explicitly disclose a plurality of keys per se, mere duplication of parts has no patentable significance unless a new and unexpected result is produced, In re Harza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960). See MPEP § 2144.04. Here it is clear that no new or unexpected result is produced by the mere duplication of parts as the claimed master entity is only required to store a plurality of keys, each key being associated with a role, and the claimed security module is configured to perform certificate verification using one of the said keys; which is already met by the public key infrastructure (PKI) taught throughout the Long reference in verifying certificates using public keys.
Conclusion
The prior art made of record in the submitted PTO-892 Notice of References Cited and not relied upon is considered pertinent to applicant’s disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MIGUEL A LOPEZ whose telephone number is (703)756-1241. The examiner can normally be reached 8:00AM-5:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached on 5712727624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M.A.L./ Examiner, Art Unit 2496 /JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights