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 .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are: “at least one profile provider interface allowing”, “at least one use case owner interface allowing”, “at least one UICC requester interface allowing”, and “a business relation manager managing” in claims 1. “an access control layer manager managing” in claim 7.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure for “at least one profile provider interface”, “at least one use case owner interface”, and “at least one UICC requester interface” described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation: [0082] of the Specification, filed 10/20/2023. However, the specification fails to disclose the corresponding structures for “a business relation manager” and “an access control layer manager”.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-10 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 recites limitation of “a business relation manager managing” which invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed functions and to clearly link the structure, material, or acts to the functions. The specification is devoid of adequate structure to perform the claimed functions. The use of the term “business relation manager” does not describe a particular structure for performing the claimed functions. Applicant discloses in Fig. 1 of the Drawing that “business relation manager” merely as a square box. The Claims, Specification and Drawings fail to describe a particular structure for the “business relation manager”. As would be recognized by those of ordinary skill in the art, the recited functions can be performed in any number of ways in hardware, software or a combination of the two. Therefore, claim 1 is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Same rationales apply to “an access control layer manager managing” recited in claim 7. Therefore, claims 1-10 are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1-10 are rejected under 112(a) because the specification is devoid of clear and adequate structure for the “business relation manager” and “access control layer manager” performing the claimed functions. The written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed functions and to clearly link the structure, material, or acts to the functions. See the 112(b) rejection, set forth above, for more details.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Namiranian (US 20220086621 A1).
Regarding claim 1, Namiranian teaches a profile provisioning platform comprising: (Fig. 1)
a profile database storing data related to a profile for an UICC; (Fig. 1: centralized database 132. [0036])
at least one profile provider interface allowing a profile provider to exchange data with the profile database; (Fig. 1, [0029] and [0036]: ESIM Profile Vendor(s) exchange data with centralized database via Subscription Management Service(s).)
at least one use case owner interface allowing a use case owner to exchange data with the profile database; (Fig. 1-2: user device 204 (e.g., use case owner interface). [0037]-[0038]: an entity may send to the eSIM profile management platform 106 a request 212 to provision the eUICC 202(N) of the user device 204(N) with a particular eSIM profile 214, in which the request includes an ICCID of the eSIM profile 214 and an entity identifier of the entity. In turn, the eSIM profile management platform 106 may input the ICCID of the eSIM profile 214 into the centralized database 132 to determine whether a responsible subscription management service has reported that it actually received the eSIM profile 214 from an eSIM profile vendor.)
at least one UICC requester interface allowing a UICC requester to exchange data with the profile database, said exchange including at least to request profiles or/and receive profiles from the profile database; ([0028]: as the central interface, the eSIM profile management platform 106 may receive a request from an entity to provision an eUICC of a user device with an eSIM profile, delete an eSIM profile from the eUICC, activate an eSIM profile that is stored in the eUICC for use to obtain communication services from a wireless communication carrier. [0037]-[0038]: an entity may send to the eSIM profile management platform 106 a request 212 to provision the eUICC 202(N) of the user device 204(N) with a particular eSIM profile 214, in which the request includes an ICCID of the eSIM profile 214 and an entity identifier of the entity. In turn, the eSIM profile management platform 106 may input the ICCID of the eSIM profile 214 into the centralized database 132 to determine whether a responsible subscription management service has reported that it actually received the eSIM profile 214 from an eSIM profile vendor.)
wherein
at one of the at least one UICC requester interfaces, said exchange of data includes: to provide a UICC request to the database, or/and to provide metadata or other formal information on a UICC to the database, to provide an EIS of a UICC to the database; ([0028]: as the central interface, the eSIM profile management platform 106 may receive a request from an entity to provision an eUICC of a user device with an eSIM profile, delete an eSIM profile from the eUICC, activate an eSIM profile that is stored in the eUICC for use to obtain communication services from a wireless communication carrier.)
a business relation manager managing access of the different profile providers, use case owners and UICC requesters to data in the profile database based on access rules related to the data. ([0041]: the entity may make a request to perform an action with respect to an M2M EID. In such embodiments, the eSIM profile management platform 106 may compare the entity identifier of the entity to a subscription management service permission list, an MNO identifier, and/or a partner identifier that are associated with the M2M EID to determine whether the entity has access to perform the action on the M2M EID. The action may be in the form of reading, modifying, or deleting the M2M EID from a SM-SR or an eUICC of a user device.)
Regarding claim 2, Namiranian teaches the profile provisioning platform according to claim 1.
Namiranian teaches wherein the profile database allows access by at least two different profile providers or/and at least two different use case owners or/and at least two different UICC requesters. (Fig. 1-2. [0029]: Profile vendors, [0037]: User devices. [0030]: eSIM profiles tha are ordered by different entities.)
Regarding claim 3, Namiranian teaches the profile provisioning platform according to claim 1.
Namiranian teaches wherein the business relation manager applies, as included in the access rules, a set of business relation governance rules so as to allow or disallow access of certain profile providers, use case owners and UICC requesters to data in the profile database, including access to data provided by a party, use case owner or UICC requester, different from the accessing party, use case owner or UICC requester. ([0038]: Thus, by comparing the entity identifier of the entity to the entity identifiers of entities that either have permission or are denied permission in the permission list, the eSIM profile management platform 106 may determine whether the entity has access to the subscription management service 104(N). [0055]-[0057]: the eSIM profile management platform may determine whether the entity has access to the particular eSIM profile based on a partner identifier or an MNO identifier associated with the particular eSIM profile.)
Regarding claim 4, Namiranian teaches the profile provisioning platform according to claim 1.
Namiranian teaches wherein, at the interfaces: at one of the at least one profile provider interfaces, said exchange of data includes: to provide profile data to the database, including providing an ICCID of a profile or/and a EID of a chip to the database, or/and to provide profiles to the profile database; or/and at any one of the at least one profile provider interfaces or/and the at least one use case owner interfaces, said exchange of data includes: to provide a profile order or a UICC order to the profile database, wherein the profile order includes profile data, including an ICCID of a profile or/and an EID of a UICC, or/and to retrieve profile data from the database, particularly retrieve an ICCID of a profile or/and an EID of a UICC from the database. (Fig. 1. [0031]: the eSIM profile vendor also provides eUICC ID (EIDs) of eUICCs that are for use by the M2M devices. [0036]: the centralized database is used by the eSIM profile management platform to track the ICCID of each eSIM profile that has been loaded, the specific subscription management service that is responsible for managing each loaded eSIM profile or each loaded M2M EID, an identity of the specific SM-DP or SM-DP+ whose data store holds each loaded eSIM profile, an identity of the specific SM-SR whose data store holds each loaded M2M EID.
Regarding claim 5, Namiranian teaches the profile provisioning platform according to claim 1.
Namiranian teaches wherein: at least one profile provider interface is provided as an interface ES4 or ES2 according to GSMA SGP.02; and/or at least one UICC requester interface is provided by a proprietary interface USAPI; and/or at least one use case owner interface is provided by a proprietary interface USAPI. (Fig. 1-2. [0027]: the eSIM profile management platform may be an application program interface (API) abstraction layer that provides multiple APIs to the various entities, in which the entities may call the APIs to perform specific tasks. Accordingly, the eSIM profile management platform enables these entities to manage eSIM profiles for deployment into eUICCs of user devices.
Regarding claim 6, Namiranian teaches the profile provisioning platform according to claim 1.
Namiranian teaches comprising one or several of the following elements: a data generation instance allowing two or more different profile providers to input data related to profile for a UICC for data generation; a data preparation server allowing two or more different profile providers to input profile data for data preparation; a secure router allowing two or more UICC requesters to request profiles and receive profiles. (Fig. 1: Subscription management services and ESIM profile vendors. [0025]: The eUICC may store one or more eSIM profiles, such as the eSIM profile 112(1-N).)
Regarding claim 7, Namiranian teaches the profile provisioning platform according to claim 1.
Namiranian teaches further comprising an access control layer manager managing physical access of profile providers, use case owners and UICC requesters to the profile provisioning platform. (Fig. 2 and [0037]: enables the eSIM profile management platform to perform error reporting and eSIM profile access control based on the service data feeds provided by the subscription management services. [0038]: by comparing the entity identifier of the entity to the entity identifiers of entities that either have permission or are denied permission in the permission list, the eSIM profile management platform may determine whether the entity has access to the subscription management service.)
Regarding claim 8, Namiranian teaches the profile provisioning platform according to claim 1.
Namiranian teaches wherein the access rules include any one or several of the following: one or several rules that access to data is allowed to an owner of the data and to partners or delegates, if any, of the owner of the data; a Whitelist of partners, and/or of partners of partners, for which access to data is allowed. ([0038]: The permission list for the subscription management service 104(N) may grant third-party partner 210(1) access, but denies third-party partner 210(N) access. By comparing the entity identifier of the entity to the entity identifiers of entities that either have permission or are denied permission in the permission list, the eSIM profile management platform may determine whether the entity has access to the subscription management service. [0039]: the eSIM profile management platform 106 may further compare the MNO identifier or the partner identifier associated with eSIM profile 214 to the entity identifier of the entity to determine whether the entity has access to the eSIM profile 214.)
Regarding claim 9, Namiranian teaches the profile provisioning platform according to claim 8.
Namiranian teaches wherein an identifier of the owner of the data and identifiers of the partners are stored in data information fields related to the data. ([0033]: The ICCID for an eSIM profile that is contained in a service data feed may be accompanied by other associated identification information, such as a mobile network operator (MNO) identifier, a subscription management service identifier, a partner identifier, and/or an EUM identifier.)
Regarding claim 10, Namiranian teaches the profile provisioning platform according to claim 1.
Namiranian teaches wherein the data related to a profile for a UICC is or comprises either one or several of: profile data required to generate a profile, and including at least IMSI, Ki, ICCID; one or several profiles; one or several eUICC Information Sets, EISs, or one or several sets of metadata related to an UICC, including metadata similar to an EIS. (Fig. 1: a plurality of profiles. [0034]: he M2M EIDs of the eUICCs for the M2M devices that are loaded into an EID data store of a SM-SR. The M2M EID for an eUICC that is contained in the service data feed may also be accompanied by other associated identification information, such as a MNO identifier, a partner identifier, a subscription management service identifier, an SM-SR identifier, and/or an EUM identifier.)
Regarding claim 10, Namiranian teaches a method for provisioning data to a profile provisioning platform according to claim 1.
Namiranian teaches comprising the steps: at one or several interfaces, selected from the profile provider interface, the use case owner interface and the UICC requester interface, receive data related to a profile for a UICC and access rules related to the data; (Fig. 1, [0035]-[0038]: subscription management service permission list must be maintained for each subscription management service over a specific interface.)
store the received data to the profile database; (Fig. 1 and [0036]: data is stored in the centralized database.)
implement the received access rules to the business relation manager. ([0038]. [0041]: the entity may make a request to perform an action with respect to an M2M EID. In such embodiments, the eSIM profile management platform 106 may compare the entity identifier of the entity to a subscription management service permission list, an MNO identifier, and/or a partner identifier that are associated with the M2M EID to determine whether the entity has access to perform the action on the M2M EID. The action may be in the form of reading, modifying, or deleting the M2M EID from a SM-SR or an eUICC of a user device.)
Regarding claim 12, Namiranian teaches the method according to claim 11.
Namiranian teaches wherein the data related to a profile for a UICC is or comprises either one or several of: profile data required to generate a profile, and including at least IMSI, Ki, ICCID; one or several profiles; one or several eUICC Information Sets, EISs, or one or several sets of metadata related to an UICC, including metadata similar to an EIS. (Fig. 1: a plurality of profiles. [0034]: he M2M EIDs of the eUICCs for the M2M devices that are loaded into an EID data store of a SM-SR. The M2M EID for an eUICC that is contained in the service data feed may also be accompanied by other associated identification information, such as a MNO identifier, a partner identifier, a subscription management service identifier, an SM-SR identifier, and/or an EUM identifier.)
Regarding claim 13, Namiranian teaches a method for provisioning data to a profile provisioning platform according to claim 1.
Namiranian teaches comprising the steps: at an interface, selected from the profile provider interface, the use case owner interface and the UICC requester interface, receive from a requesting party, being a profile provider, a use case owner or a UICC requester, a request for data to be output from the profile provisioning platform to a specified output interface; ([0038]: an entity may send to the eSIM profile management platform 106 a request 212 to provision the eUICC 202(N) of the user device 204(N) with a particular eSIM profile 214, in which the request includes an ICCID of the eSIM profile 214 and an entity identifier of the entity.)
at the business relation manager, verify the access rules, and output the requested data only under the condition the access rules allow providing the requested data to the specified output interface. ([0038]: In turn, the eSIM profile management platform 106 may input the ICCID of the eSIM profile 214 into the centralized database 132 to determine whether a responsible subscription management service has reported that it actually received the eSIM profile 214 from an eSIM profile vendor. If the centralized database 132 shows that a subscription management service, such as the subscription management service 104(N), has stored the eSIM profile 214 into its profile data store, the eSIM profile management platform may use the entity identifier of the entity to determine whether the entity has access to the subscription management service 104(N).)
Regarding claim 14, Namiranian teaches the method according to claim 13.
Namiranian teaches wherein the specified output interface is: implicitly specified in that it is the interface at which the request is received; or explicitly specified as a particular interface, including the interface at which the request is received or a different interface. ([0038]: an entity may send to the eSIM profile management platform 106 a request 212 to provision the eUICC 202(N) of the user device 204(N) with a particular eSIM profile 214, in which the request includes an ICCID of the eSIM profile 214 and an entity identifier of the entity. [0039]: when there is a match between the entity identifier of the entity that initiated the request with respect to the eSIM profile 214 and the MNO identifier or the partner identifier, the eSIM profile management platform 106 may forward the request of the entity to the subscription management service 104(N). In this way, the subscription management service 104 may initiate a procedure that eventually provisions the eUICC 202(N) of the user device 204(N) with the eSIM profile 214.)
Regarding claim 15, Namiranian teaches the method according to claim 13.
Namiranian teaches wherein the request for data is a profile order, the requested data is or comprises a profile to be provided to a target UICC. ([0038]: an entity may send to the eSIM profile management platform 106 a request 212 to provision the eUICC 202(N) of the user device 204(N) with a particular eSIM profile 214, in which the request includes an ICCID of the eSIM profile 214 and an entity identifier of the entity.)
Response to Arguments
Applicant's arguments, see pages 9-13, filed 12/08/2025, with respect to the rejection(s) of claim(s) 1-10 under 112(b) and 112(a) in view of 112(f) have been fully considered but they are not persuasive.
On page 10, applicant submits that "an access control layer manager" is described in at least para. [056] of the Specification.
In response to applicant’s arguments, it is noted that para. [056] of the Specification disclose the structure for the “access control layer”, not the “access control layer manager”. Para. [056] of the Specification disclose that “The access control layer, managed by the access control layer manager” which clearly discloses that the “access control layer” and the “access control layer manager” are two separate components. Therefore, the “access control layer manager” recited in claim 1 is indefinite.
On pages 10-11, applicant submits that "a business relation manager" is described in at least para. [034]. As would be understood by one skilled in the art from the teachings of at least paras. [008-27] of the disclosure, "a business relation manager" may be implemented as software executed by a profile provisioning platform.
In response to applicant’s arguments, it is noted that para. [034] of the Specification disclose what functions the “business relation manager” perform. Para. [034] of the Specification does not provide a particular structure for the “business relation manager”. In addition, applicant submits that “As would be understood by one skilled in the art from the teachings of at least paras. [008-27] of the disclosure, "a business relation manager" may be implemented as software executed by a profile provisioning platform.”. Applicant’s arguments further support that the “business relation manager” can be implemented in any number of ways in hardware, software or a combination of the two. Therefore, the “business relation manager” recited in claim 1 is indefinite.
Applicant’s arguments, see pages 13-15, filed 12/08/2025, with respect to the rejection(s) of claims 1-15 under 35 U.S.C. § 102(a)(1) have been fully considered but they are not persuasive.
Applicant submits that prior art of record, Namiranian fail to teach the amended independent claim 1. However, the Examiner respectfully disagrees. Namiranian teaches in [0028] that as the central interface, the eSIM profile management platform 106 may receive a request from an entity to provision an eUICC of a user device with an eSIM profile which teaches “at one of the at least one UICC requester interfaces, said exchange of data includes: to provide a UICC request to the database”.
Conclusion
THIS ACTION IS MADE FINAL. 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 ZI YE whose telephone number is (571)270-1039. The examiner can normally be reached Monday - Friday, 8:00am - 4: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, Emmanuel Moise can be reached at 5712723865. 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.
/ZI YE/Primary Examiner, Art Unit 2455