DETAILED ACTION
Response to Amendment
This Action is in response to communications filed on 03/16/2026.
Claims 1, 3, 8-10, 12, 15 and 17 are amended (1, 8 and 15 being independent claims).
Claim 4, 11 and 18 are cancelled. There are no new claims.
Claims 1-3, 5-10, 12-17 and 19-20 are presented for examination.
Claims 1-3, 5-10, 12-17 and 19-20 remain pending in this application.
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 .
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 03/18/2026 and on 04/10/2026 were filed after the Non-Final Rejection was mailed on 12/16/2025. The IDSs are in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDSs are being considered by the examiner.
Specification
The amendment to title of the invention, as well as to specification paragraph [0053] were received on 03/16/2026. These amendments are acceptable, and as a result, the respective specification objections made in the non-final Office Action have been withdrawn.
Response to Arguments Regarding Claim Objections
In the non-final office Action mailed on 12/16/2025, claims 1, 3, 8, 10 15 and 17 were objected to because of minor informalities. In the response filed on 03/16/2026, applicant amends the claims to obviate the objections. As a result, the respective claim objections made in the non-final Office Action have been withdrawn.
Response to Arguments Regarding Double Patenting Rejections
In the non-final office Action mailed on 12/16/2025, claims 1-20 were rejected on the ground of non-statutory double patenting as being unpatentable over claims of co-pending application No. 18/699,958, 18/038,773 and 18/030,565. In the response filed on 03/16/2026, applicant filed a Terminal Disclaimer to overcome the rejections. As a result, the Double Patenting Rejections are withdrawn.
Response to Arguments Regarding Claim Rejections - 35 USC § 101
The applicant’s amendment/ arguments, see page 11 of REMARKS, filed 03/16/2026, with respect to Claim Rejections - 35 USC § 101 have been fully considered and are persuasive. The rejections of claims 8-14 under 35 U.S.C. 101 (Step 1, as being software per se) made in the non-final Office Action mailed on 07/05/2017 have been withdrawn.
Response to Arguments Regarding Claim Rejections - 35 USC § 112
In the non-final office Action mailed on 12/16/2025, claims 1-20 were rejected under 35 U.S.C. 112(b) as being indefinite. In the response filed on 03/16/2026, applicant amends the respective claims to obviate the rejections. These amendments are acceptable, and as a result, the respective claim rejections under 35 U.S.C. 112(b) made in the non-final Office Action mailed 12/16/2025 have been withdrawn.
Response to Arguments Regarding Claim Rejections - 35 USC § 103
Applicant’s amendment/ arguments, see pages 11-13 of REMARKS, filed 03/16/2026, with respect to the rejection(s) of claim(s) under 35 USC § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Yang et al. (US 20180006873 A1) and Ittah et al. (US 20110289137 A1).
Claim Rejections - 35 USC § 103
Claim(s) 1-2, 8-9 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over ERICKSEN et al. (hereinafter, ERICKSEN, US 20200344607 A1) in view of ATARIUS (WO 2023214316 A1) in view of Yang et al. (hereinafter, Yang, US 20180006873 A1) in view of Ittah et al. (hereinafter, Ittah, US 20110289137 A1).
Regarding claim 1, ERICKSEN discloses a method comprising:
receiving, by an application programming interface (API) producer (Fig.3:120 “ZTCP”), a Hypertext Transfer Protocol (HTTP) GET configuration data request (see Fig.3:306; also see [0035]; server computing device that implements a zero touch configuration proxy (ZTCP) may be configured to receive a service request for a specified service and a client certificate that includes information in a SSL_CLIENT_S_DN_CN field from a user equipment (UE) device; also see [0076]; the UE 104 device may send an HTTP GET message to the ZTCP 120; The HTTP GET message may include a client certificate, a $file variable or a request for a configuration file), wherein the HTTP GET configuration data request originates from an API consumer (see Fig.3:104; also see [0076]; the UE 104 device may send an HTTP GET message to the ZTCP 120; also see [0069]; the processor may issue various commands/API calls), and wherein the HTTP GET configuration data request comprises query criteria, wherein the query criteria includes a field parameter (see [0005]; receiving the service request and the client certificate that includes the information in the SSL_CLIENT_S_DN_CN field may include receiving an HTTP GET message that includes the client certificate and a $file variable);
determining, by the API producer (Fig.3:120 “ZTCP”), whether the HTTP GET configuration data request is valid or not (see [0048]; The ZTCP component may be configured to use a public key infrastructure (PKI) to uniquely identify a specific UE device, determine whether the UE device requests a configuration file that the UE device is authorized to access, and provide the configuration file to the UE device in response to determining that the UE device is authorized to access the configuration file and/or receive the requested specified service; also see [0050]; the ZTCP component may use a public key infrastructure (PKI) and the SSL_CLIENT_S_DN_CN field in the client certificate to uniquely identify the UE device, and issue a series of commands/API calls to a provisioning system to determine whether the specific UE device is currently authorized to receive a particular specified service (e.g., VoIP, etc.) and/or whether the specific UE device is allowed to access the requested configuration file; also see [0077] in view of Fig.3:308; the ZTCP 120 may verify the client and/or client certificate (e.g., via SSL_CLIENT_VERIFY, etc.). For example, the ZTCP 120 may verify the authenticity of the received client certificate and that the UE 104 device belongs to a group of approved devices that are authorized);
upon determining that the HTTP GET configuration data request is valid (see [0048], [0050] and [0077] in view of Fig.3:308), obtaining, by the API producer (Fig.3:120 “ZTCP”), a configuration data based on the resource URI and the query criteria (see [0078]-[0085]; If the verification operations in operation block 308 are successful, the system may perform the operations in block 350; also see [0007]; the method may include sending an HTTPS GET $Repository_URL message to a provisioning server; receiving HTTPS XML file that includes a content of the configuration file associated with the $file variable; and sending the HTTPS XML file to the UE device in response); and
sending, by the API producer (Fig.3:120 “ZTCP”), a HTTP GET response, wherein the HTTP GET response comprises a message based on the determination of whether the HTTP GET configuration data request is valid or not, wherein the message includes the configuration data based on the HTTP GET configuration data request being determined as being valid (see [0078]-[0085]; If the verification operations in operation block 308 are successful, the system may perform the operations in block 350; also see [0007]; the method may include sending an HTTPS GET $Repository_URL message to a provisioning server; receiving HTTPS XML file that includes a content of the configuration file associated with the $file variable; and sending the HTTPS XML file to the UE device in response).
ERICKSEN does not explicitly disclose that HTTP GET configuration data request comprises a resource Uniform Resource Identifier (URI), wherein the query criteria includes a scope parameter, and an attribute parameter. ERICKSEN also does not explicitly disclose indicating an error if the HTTP GET configuration data request had been determined as not being valid.
However, in an analogous art, ATARIUS discloses HTTP configuration data request comprises a resource Uniform Resource Identifier (URI) (see [0073]; network slice configuration request… using … associated Resource URI structure; also see [0013]; configuration request is part of a hypertext transfer protocol (HTTP) message).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of ATARIUS with ERICKSEN so that the HTTP GET configuration data request comprises a resource URI.
One of ordinary skill in the art would have been motivated to identify an entity (i.e. network resource) (ATARIUS: see [0013]).
ERICKSEN (modified by ATARIUS) does not explicitly disclose wherein the query criteria includes a scope parameter, and an attribute parameter, and indicating an error if the HTTP GET configuration data request had been determined as not being valid.
However, in an analogous art, Yang discloses wherein the query criteria includes a scope parameter (see [0018]; embedded query is implemented as GET(ARG1, [CONTEXT]); The semantic [CONTEXT] is used to identify a set of context parameters for the data collection implemented for the embedded query; examiner articulates that the context parameters corresponds to the claimed “scope parameter”), and an attribute parameter (see [0024]; embedded query will include an attribute variable; After injecting the arguments, the evaluator invokes the implementation instance of the embedded query with the collected OID and the context parameters; The evaluator then waits for a response to the invoked implementation instance).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Yang with ERICKSEN and ATARIUS so that the query criteria includes a scope parameter, and an attribute parameter.
One of ordinary skill in the art would have been motivated to reduce collection configuration as well as to significantly reduce the amount of management traffic (i.e. network resource) (Yang: see [0029]).
Although, and as set forth above, ERICKSEN teaches the HTTP GET configuration data request (see Fig.3:306), ERICKSEN (modified by ATARIUS and Yang) does not explicitly disclose indicating an error if the HTTP GET configuration data request had been determined as not being valid.
However, in an analogous art, Ittah discloses indicating an error if the HTTP GET data request had been determined as not being valid (see [0045]; The "HTTP Get" request is received by the HTTP server 590. If the process ID does not have access permissions to read the content of the virtual file 570, the HTTP server 590 can return an error response).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ittah with ERICKSEN, ATARIUS and Yang to indicate an error if the HTTP GET data request had been determined as not being valid.
One of ordinary skill in the art would have been motivated so that access control for remote records can be used in order to receive the true content (Ittah: see [0044]).
Regarding claim 2, ERICKSEN (modified by ATARIUS ) discloses the method of claim 1, as set forth above. ERICKSEN further discloses wherein determining whether the HTTP GET configuration data request is valid or not further comprises:
determining, by the API producer, whether the HTTP GET configuration data request originates from a valid API consumer (see [0048]; The ZTCP component may be configured to use a public key infrastructure (PKI) to uniquely identify a specific UE device, determine whether the UE device requests a configuration file that the UE device is authorized to access, and provide the configuration file to the UE device in response to determining that the UE device is authorized to access the configuration file and/or receive the requested specified service; also see [0050]; the ZTCP component may use a public key infrastructure (PKI) and the SSL_CLIENT_S_DN_CN field in the client certificate to uniquely identify the UE device, and issue a series of commands/API calls to a provisioning system to determine whether the specific UE device is currently authorized to receive a particular specified service (e.g., VoIP, etc.) and/or whether the specific UE device is allowed to access the requested configuration file; also see [0077] in view of Fig.3:308; the ZTCP 120 may verify the client and/or client certificate (e.g., via SSL_CLIENT_VERIFY, etc.). For example, the ZTCP 120 may verify the authenticity of the received client certificate and that the UE 104 device belongs to a group of approved devices that are authorized).
As for Claim(s) 8 and 15, the claims list all the same elements of claim 1, but in an apparatus (see ERICKSEN: Fig.3:300) comprising a memory storing instruction and at least one processor configured to execute the instruction (see ERICKSEN [0016]); and a non-transitory computer-readable recording medium having recorded thereon instructions (see ERICKSEN [0016]) form to carry out the steps of claim 1, rather than the method form. Therefore, the supporting rationale of the rejection to claim 1 applies equally as well to claims 8 and 15.
As for Claims 9 and 16, the claims depend on claims 8 and 15 respectively, but do not teach or further define over the limitations in claim 2. Therefore, claims 9 and 16 are rejected for the same reasons as set forth in claim 2.
Claim(s) 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over ERICKSEN et al. (hereinafter, ERICKSEN, US 20200344607 A1) in view of ATARIUS (WO 2023214316 A1) in view of Yang et al. (hereinafter, Yang, US 20180006873 A1) in view of Ittah et al. (hereinafter, Ittah, US 20110289137 A1) in view of Hu et al. (hereinafter, Hu, US 20150295983 A1).
Regarding claim 3, ERICKSEN (modified by ATARIUS, Yang and Ittah) discloses the method of claim 1, as set forth above. ERICKSEN (modified by ATARIUS, Yang and Ittah) does not explicitly disclose wherein the resource URI comprises an rApp identifier, a URI first-part, and a class name identifier.
However, in an analogous art, Hu discloses wherein the resource URI comprises an rApp identifier (see [0032]; web resource identified by the URI; also see [0046]; examiner articulates that “my_app” in example URI “/my_server/my_app” corresponds to an rApp identifier), a URI first-part (see [0046]; examiner articulates that “/my_server/” in example URI “/my_server/my_app” corresponds to a URI-LDN-first-part), and a class name identifier (see [0004]; extracts a class name from a uniform resource identifier (URI) of an application header).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Hu with ERICKSEN so that the resource URI comprises an rApp identifier, a URI first-part, and a class name identifier.
One of ordinary skill in the art would have been motivated to allow class declarations to function, at least in part, as a portion of interface description language (Hu: see [0004]).
As for Claims 10 and 17, the claims depend on claims 8 and 15 respectively, but do not teach or further define over the limitations in claim 3. Therefore, claims 10 and 17 are rejected for the same reasons as set forth in claim 3.
Claim(s) 5-7, 12-14 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over ERICKSEN et al. (hereinafter, ERICKSEN, US 20200344607 A1) in view of ATARIUS (WO 2023214316 A1) in view of Yang et al. (hereinafter, Yang, US 20180006873 A1) in view of Ittah et al. (hereinafter, Ittah, US 20110289137 A1) in view of Wysocki et al. (hereinafter, Wysocki, US 20110007895 A1).
Regarding claim 5, ERICKSEN (modified by ATARIUS, Yang and Ittah) discloses the method of claim 1, as set forth above, including obtaining, by the API producer, a configuration data based on the resource URI and the query criteria (see [0078]-[0085]; also see [0007]). ERICKSEN (modified by ATARIUS, Yang and Ittah) does not explicitly disclose such obtaining further comprises obtaining objects, wherein the obtained objects have a scope level which match the scope parameter.
However, in an analogous art, Wysocki discloses obtaining objects, wherein the obtained objects have a scope level which match the scope parameter (see [0021] in view of Fig.2:206; the service 104 providing the configuration file with associated unique identifier (the computing device 102 provided the unique identifier to the service 104 in step 202); also see [0019]; The service 104 provides a collection of configuration data to the computing device 102… the configuration data has been properly generated for use by the computing device having the particular unique identifier; also see [0025]; the configuration file includes an indication of the unique identifier associated with the computing device 102).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wysocki with ERICKSEN, ATARIUS, Yang and Ittah so that the obtaining further comprises obtaining objects, wherein the obtained objects have a scope level which match the scope parameter.
One of ordinary skill in the art would have been motivated to securely configure a computing device via a service (Wysocki: see [0016]).
Regarding claim 6, ERICKSEN (modified by ATARIUS, Yang, Ittah and Wysocki) discloses the method of claim 5, as set forth above. Wysocki further discloses wherein the obtained objects have an attribute which matches the attribute parameter (see [0021] in view of Fig.2:206; the service 104 providing the configuration file with associated unique identifier (the computing device 102 provided the unique identifier to the service 104 in step 202); also see [0019]; The service 104 provides a collection of configuration data to the computing device 102… the configuration data has been properly generated for use by the computing device having the particular unique identifier; also see [0025]; the configuration file includes an indication of the unique identifier associated with the computing device 102).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wysocki with ERICKSEN, ATARIUS, Yang and Ittah so that the obtained objects have an attribute which matches the attribute parameter.
One of ordinary skill in the art would have been motivated to securely configure a computing device via a service (Wysocki: see [0016]).
As for Claims 12-13 and 19-20, the claims depends on claim 8 and 15 respectively, but do not teach or further define over the limitations in claims 5-6 respectively. Therefore, claims 12-13 and 19-20 are rejected for the same reasons as set forth in claims 5-6 respectively.
Regarding claim 7, ERICKSEN (modified by ATARIUS, Yang, Ittah and Wysocki) discloses the method of claim 6, as set forth above. Wysocki further discloses wherein the obtained objects have an attribute field which matches the field parameter (see [0021] in view of Fig.2:206; the service 104 providing the configuration file with associated unique identifier (the computing device 102 provided the unique identifier to the service 104 in step 202); also see [0019]; The service 104 provides a collection of configuration data to the computing device 102… the configuration data has been properly generated for use by the computing device having the particular unique identifier; also see [0025]; the configuration file includes an indication of the unique identifier associated with the computing device 102).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wysocki with ERICKSEN, ATARIUS, Yang and Ittah so that the obtained objects have an attribute field which matches the field parameter.
One of ordinary skill in the art would have been motivated to securely configure a computing device via a service (Wysocki: see [0016]).
As for Claim 14, the claims depend on claim 8, but does not teach or further define over the limitations in claim 7. Therefore, claim 14 is rejected for the same reasons as set forth in claim 4.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
NEGM MOHAMED (EP 4239967 A1) discloses query may include parameters such as, for example, latency, performance, and footprint.
WERNER (US 20230030421 A1) teaches one or more parameters, characteristics, queries are queried against various data generated by the centralized data verification system.
Conclusion
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 SANDARVA KHANAL whose telephone number is (571)272-8107. The examiner can normally be reached MON-FRI, 0800-1700.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
/SANDARVA KHANAL/Primary Examiner, Art Unit 2453
Prosecution Insights