DETAILED ACTION
This Office action is in response to Amendment filed on 5/11/2026. Claims 1, 8, and 15 have been
amended. Claims 1-20 remain pending in the 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 statement (IDS) submitted on 3/24/2026, 4/10/2026, 5/11/2026,
5/13/2026, 6/22/2026, and 7/16/2026 were filed on or after the filing date of the instant application on 5/23/2025. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e),
was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/11/2026 has been entered.
Response to Amendment
The Amendment filed on 5/11/2026 has been entered.
Response to Remarks/Arguments
Applicant’s remarks/arguments (page 9-13), filed on 5/11/2026, with respect to the 103 rejections of
claim 1 have been fully considered but are moot because the arguments are based on newly added limitations in the amendment and new ground of rejections using a newly introduced references (SONG et al.) are applied in the current rejection.
Claim Objections
Claims 1, 8, and 15 are objected to because of the following informalities:
Claim 1, in lines 17-18, “configures a network element of the O-RAN,” should be replaced by “configures the network element of the O-RAN,”.
Claim 8, in lines 19-20, “configures a network element of the O-RAN,” should be replaced by “configures the network element of the O-RAN,”.
Claim 15, in lines 18-19, “configures a network element of the O-RAN,” should be replaced by “configures the network element of the O-RAN,”.
Appropriate corrections are required.
Claim Rejections - Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in
public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1)-706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being
unpatentable over claims 1-20 of Copending Application No. 18/030,565 (18/030,565, hereinafter “Copending Application”). Although the conflicting claims are not identical, they are not patentably distinct from each other because claims 1-20 of the instant application are broader in every aspect than the corresponding claims of Copending Application (18/030,565) and are therefore anticipated by claims 1-20 of Copending Application (18/030,565).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims
have not in fact been patented.
Current Application No. 18/038,773
Co-pending Application No. 18/030,565
1. A method, performed by at least one processor, for managing configuration data for a Non-Real-Time Radio Access Network Intelligent Controller
(Non-RT RIC) Application (rApp) of an Open Radio Access Network (O-RAN), the method
comprising:
receiving, by a radio access network (RAN) operation and maintenance (OAM)-related
function of a Service Management and Orchestration (SMO) framework of the O-RAN via an R1 interface of the Non-RT RIC, a read configuration request, wherein the read configuration request originates from the rApp, and wherein the read configuration request indicates requested configuration data of a network element of the O-RAN;
determining, by the RAN OAM-related function, whether or not the read configuration request is valid; and
sending, by the RAN OAM-related function, a read configuration response to the rApp, in response to the read configuration request.
wherein the SMO comprises the Non-RT RIC and the OAM-related function, and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element
Management System, and
wherein the requested configuration data is configuration data that configures a network
element of the O-RAN, the network element being an O-RAN centralized unit (O-CU) or an 0-
RAN distributed unit (O-DU).
1. A method, performed by at least one processor, for managing configuration schema for an rApp, the method comprising:
receiving, by a Radio Access Network Operation and Maintenance (RAN OAM)-related
function, a get configuration schema request, wherein the get configuration schema request
originates from the rApp, and wherein the get configuration schema request is a request to
provide the rApp with a configuration schema of a network element, the configuration schema
indicating being a schema of readable and/or writeable configuration parameters of the network
element;
determining, by the RAN OAM-related function, whether or not the get configuration
schema request is valid; and
sending, by the RAN OAM-related function, a get configuration schema response to the
rApp, in response to the get configuration schema request,
wherein the network element is one of a centralized unit (CU) and a distributed unit (DU)
of an Open Radio Access Network (O-RAN).,_
wherein the get configuration schema request comprises an identifier (ID) of the rApp
and information about the one of the CU and the DU, and
wherein determining whether or not the get configuration schema request is valid
comprises determining, by the RAN OAM-related function, whether the rApp is authorized to
request the configuration schema.
2. The method as claimed in claim 1, wherein the read configuration response comprises the requested configuration data.
2. The method as claimed in claim 1, wherein the get configuration schema response comprises the requested configuration schema.
3. The method as claimed in claim 2, wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria.
3. The method as claimed in claim 2, The method as claimed in claim 2, wherein the get configuration schema request further comprises a query criteria.
4. The method as claimed in claim 3, wherein the read configuration request further comprises information about managed entities of a service producer.
4. canceled
5. The method as claimed in claim 3, wherein determining whether or not the read configuration request is valid comprises:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
5. The method as claimed in claim 3, wherein:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the
configuration schema comprises determining, by checking the ID of the rApp, whether the rApp
is included in an authorized rApps list of rApps authorized to request configuration schemas of
DUs and CUs.
6. The method as claimed in claim 5, wherein determining whether or not the read configuration request is valid comprises:
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria.
6. The method as claimed in claim 3, wherein determining whether or not the get configuration schema request is valid further comprises:
based on a determination that the rApp is authorized to request the configuration schema,
determining, by the RAN OAM-related function, whether the get configuration schema request is
valid based on the query criteria.
7. The method as claimed in claim 1, wherein the read configuration response indicates whether or not the read configuration request was successful, or failed.
7. The method as claimed in claim 1, wherein the get configuration schema response indicates whether or not the get configuration schema request was successful, or failed.
8. An apparatus for managing configuration data for a Non-Real-Time Radio Access Network Intelligent Controller (Non-RT RIC) Application (rApp) of an Open Radio Access Network (O-RAN), the apparatus comprising:
at least one memory storing computer-executable instructions; and
at least one processor configured to execute the computer-executable instructions to:
receive, by a radio access network (RAN) operation and maintenance (OAM)-related
function of a Service Management and Orchestration (SMO) framework of the O-RAN via an R1 interface of the Non-RT RIC, a read configuration request, wherein the read configuration request originates from the rApp, and wherein the read configuration request indicates requested configuration data of a network element of the O-RAN, the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU);
determine, by the RAN OAM-related function, whether or not the read configuration
request is valid; and
send, by the RAN OAM-related function, a read configuration response to the rApp, in
response to the read configuration request.,_
wherein the SMO comprises the Non-RT RIC and the OAM-related function, and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element
Management System, and
wherein the requested configuration data is configuration data that configures a network
element of the O-RAN, the network element being an O-RAN centralized unit (O-CU) or an 0-RAN distributed unit (O-DU).
8. An apparatus for managing configuration schema for an rApp, the apparatus comprising:
at least one memory storing computer-executable instructions; and
at least one processor configured to execute the computer-executable instructions to:
receive, by a Radio Access Network Operation and Maintenance (RAN OAM)-related function, a get configuration schema request, wherein the get configuration schema request originates from the rApp, and wherein the get configuration schema request is a request to provide the rApp with a configuration schema of a network element, the configuration schema being a schema of readable and/or writeable configuration parameters of the network element;
determine, by the RAN OAM-related function, whether or not the get configuration schema request is valid; and
send, by the RAN OAM-related function, a get configuration schema response to the rApp, in response to the get configuration schema request.
wherein the network element is one of a centralized unit (CU) and a distributed unit (DU) of an Open Radio Access Network (O-RAN).
wherein the get configuration schema request comprises an identifier (ID) of the rApp and information about the one of the CU and the DU, and wherein the at least one processor is further configured to execute the computer executable
instructions to determine whether or not the get configuration schema request is valid by determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema.
9. The apparatus as claimed in claim 8, wherein the read configuration response comprises the requested configuration data.
9. The apparatus as claimed in claim 8, wherein the get configuration schema response comprises the requested configuration schema.
10. The apparatus as claimed in claim 9, wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria.
10. The apparatus as claimed in claim 9, wherein the get configuration schema request further comprises a query criteria.
11. The apparatus as claimed in claim 10, wherein the read configuration request further comprises information about managed entities of a service producer.
11. canceled
12. The apparatus as claimed in claim 10, wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the read configuration request is valid by:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
12. The apparatus as claimed in claim 10, wherein the at least one processor is further configured to execute the computer-executable instructions to determine, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema by determining, by checking the ID of the rApp, whether the rApp is
included in an authorized rApps list.
13. The apparatus as claimed in claim 12, wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the read configuration request is valid by:
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria.
13. The apparatus as claimed in claim 10, wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the get configuration schema request is valid by:
based on a determination that the rApp is authorized to request the configuration schema, determining, by the RAN OAM-related function, whether the get configuration schema request is valid based on the query criteria.
14. The apparatus as claimed in claim 8, wherein the read configuration response indicates whether or not the read configuration request was successful, or failed.
14. The apparatus as claimed in claim 8, wherein the get configuration schema response indicates whether or not the get configuration schema request was successful, or failed.
15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor to cause the at least one processor to perform a method comprising:
receiving, by a radio access network (RAN) operation and maintenance (OAM)-related
function of a Service Management and Orchestration (SMO) framework of an Open Radio
Access Network (O-RAN) via an R1 interface, a read configuration request, wherein the read
configuration request originates from a Non-Real-Time Radio Access Network Intelligent
Controller (Non-RT RIC) Application (rApp ), and wherein the read configuration request
indicates requested configuration data of a network element of the O-RAN, the network element
being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU);
determining, by the RAN OAM-related function, whether or not the read configuration request is valid; and
sending, by the RAN OAM-related function, a read configuration response to the rApp, in response to the read configuration request.
wherein the SMO comprises the Non-RT RIC and the OAM-related function, and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element
Management System, and
wherein the requested configuration data is configuration data that configures a network
element of the O-RAN, the network element being an O-RAN centralized unit (O-CU) or an ORAN
distributed unit (O-DU).
15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor to cause the at least one processor to perform a method comprising:
receiving, by a Radio Access Network Operation and Maintenance (RAN OAM)-related function, a get configuration schema request, wherein the get configuration schema request originates from an rApp, and wherein the get configuration schema request is a request to provide the rApp with a configuration schema of a network element, the configuration schema being a schema of readable and/or writeable configuration parameters of the network element;
determining, by the RAN OAM-related function, whether or not the get configuration schema request is valid; and
sending, by the RAN OAM-related function, a get configuration schema response to the rApp, in response to the get configuration schema request.
wherein the network element is one of a centralized unit (CU) and a distributed unit (DU) of an Open Radio Access Network (O-RAN).
wherein the get configuration schema request comprises an identifier (ID) of the rApp and information about the one of the CU and the DU, and
wherein determining whether or not the get configuration schema request is valid comprises determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema.
16. The non-transitory computer-readable recording medium as claimed in claim 15, wherein the read configuration response comprises the requested configuration data.
16. The non-transitory computer-readable recording medium as claimed in claim 15, wherein the get configuration schema response comprises the requested configuration schema.
17. The non-transitory computer-readable recording medium as claimed in claim 16, wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria.
17. The non-transitory computer-readable recording medium as claimed in claim 16, wherein the get configuration schema request further comprises a query criteria.
18. The non-transitory computer-readable recording medium as claimed in claim 17, wherein the read configuration request further comprises information about managed entities of a service producer.
18. canceled
19. The non-transitory computer-readable recording medium as claimed in claim 17, wherein determining whether or not the read configuration request is valid comprises:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
19. The non-transitory computer-readable recording medium as claimed in claim 17, wherein
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema comprises determining, by checking the ID of the rApp, whether the rApp
is included in an authorized rApps list.
20. The non-transitory computer-readable recording medium as claimed in claim 19, wherein determining whether or not the read configuration request is valid comprises:
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria.
20. The non-transitory computer-readable recording medium as claimed in claim 17, wherein determining whether or not the get configuration schema request is valid further comprises:
based on a determination that the rApp is authorized to request the configuration schema, determining, by the RAN OAM-related function, whether the get configuration schema request is valid based on the query criteria.
However, Co-pending application remain silent on wherein the SMO comprises the Non-RT RIC and the OAM-related function, and wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System, and wherein the requested configuration data is configuration data that configures a network element of the O-RAN, the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU).
Song teaches "the OAM function of the SMO provides data of RAN slice SLA assurance to the non-RT RIC. The non-RT RIC may collect data and create a policy, based on the information received from the OAM function. the NEF of the 5GC may be connected with the 3rd party entity over the N33/Nnef interface, and the 3rd party entity may be connected with the O-RAN (e.g., the EMS, the near-RT RIC). O-RAN has newly defined a radio unit (RU), a digital unit (DU), a central unit (CU)control plane (CP) and a CU-user plane (UP) which are nodes constituting a 3GPP network entity (NE) and a base station as an O-RAN (O)-RU, an O-DU, an O-CU-CP, and an O-CU-UP respectively, Song: Fig. 12A, 13B, [0050]-[0051], [0110], [0140]".
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Co-pending application’s system with SMO which comprises the Non-RT RIC and the OAM-related function, and the requested configuration data which is configuration data that configures a network element of the O-RAN of Song, in order to help enhanced functions and performances of 5G mobile communication systems (Song: 0007).
Claim Rejections - 35 USC § 103
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 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 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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that
are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or onobviousness.
Claims 1-4, 7-11, and 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over Dent et al.
(US 2023/0388844 A1, hereinafter “Dent”) in view of HAN (WO 2022/060923 A1, hereinafter “Han”) and in further view of SONG et al. (US 2023/0239776 Al, hereinafter “Song”).
.
Regarding claim 1, Dent discloses:
A method, performed by at least one processor, for managing configuration data for a Non-Real-Time Radio Access Network Intelligent Controller (Non-RT RIC) Application (rApp) of an Open Radio Access Network (O-RAN), the method comprising (the rApp can provide this data directly to other O-RAN components. method for modifying settings of a legacy radio access network (RAN) by an application executing on a 5G RAN intelligent controller (MC) framework (e.g., a non-real-time (non-RT) RIC). The processing unit(s) may be a single processor. 5G network elements via Distributed Unit (O-DU) and/or Centralized Unit (O-CU) elements of the 5G Open RAN (O-RAN), Dent: [0009], [0020], [0050]):
receiving, bone of the rApps sends a command to read configuration setting data from the legacy RAN. these data types allow the rApps to read configuration setting data from the legacy RAN. the rApps 215 and 220 either use the Al interface to communicate with the near-RT MC or use the SMO layer to communicate directly with the O-Cloud and/or managed functions of the O-RAN, Dent: [0029]-[0031], [0046]);
determining, commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]); and
sending, the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., therApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
wherein the requested configuration data is configuration data that configures a network element of the O-RAN (The rApps 215 and 220 may need to read and/or modify configuration settings of both 5G RAN settings. For the 5G network, the rApps 215 and 220 either use the Al interface to communicate with the near-RT MC or use the SMO layer to communicate directly with the O-Cloud and/or managed functions of the O-RAN, Dent: [0031]),
Dent does not explicitly disclose:
by a radio access network (RAN) operation and maintenance {OAM)-related function of a Service Management and Orchestration (SMO) framework of the O-RAN via an R1 interface of the Non-RT RIC,
wherein the SMO comprises the Non-RT RIC and the OAM-related function, and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System, and
the network element being an O-RAN centralized unit (O-CU) or an 0-RAN distributed unit (O-DU).
However, in the same field of endeavor, Han teaches:
The O-RAN Non-Real Time (RT) RAN Intelligent Controller (RIC) 212is a logical function within the SMO framework 102, 202 that enables non-realtime control and optimization of RAN elements and resources. receiving the model structure and training configurations from rApp 301 in the data 507 and collecting training 25 data from RAN. The monitoring services and management services in the Non-RT RIC are exposed to the rApps via the R1 interface, Han: [0033], [0042], [0061]),
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dent in view of Han in order to further modify a Service Management and Orchestration (SMO) framework of the O-RAN via an R1 interface of the Non-RT RIC from the teachings of Han.
One of ordinary skill in the art would have been motivated because further enhanced operation of LTE and NR systems in the licensed, as well as unlicensed spectrum, is expected in future releases and 5G systems such as O-RAN systems (Han: [0005]).
Yet, Dent in view of Han does not explicitly disclose:
by a RAN OAM-related function,
wherein the SMO comprises the Non-RT RIC and the OAM-related function, and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System, and
the network element being an O-RAN centralized unit (O-CU) or an 0-RAN distributed unit (O-DU).
However, in the same field of endeavor, Song teaches:
by a RAN OAM-related function (The non-RT RIC may collect data and create a policy, based on the information received from the OAM function. the NEF of the 5GC may be connected with the 3rd party entity over the N33/Nnef interface, and the 3rd party entity may be connected with the O-RAN (e.g., the EMS, the near-RT RIC), Song: Fig. 13B, [0110], [0140]),
wherein the SMO comprises the Non-RT RIC and the OAM-related function (the OAM function of the SMO provides data of RAN slice SLA assurance to the non-RT RIC, Song: Fig. 12A, [0140]), and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System (The non-RT RIC may collect data and create a policy, based on the information received from the OAM function. the NEF of the 5GC may be connected with the 3rd party entity over the N33/Nnef interface, and the 3rd party entity may be connected with the O-RAN (e.g., the EMS, the near-RT RIC), Song: Fig. 13B, [0110], [0140]), and
the network element being an O-RAN centralized unit (O-CU) or an 0-RAN distributed unit (O-DU) (O-RAN has newly defined a radio unit (RU), a digital unit (DU), a central unit (CU)control plane (CP) and a CU-user plane (UP) which are nodes constituting a 3GPP network entity (NE) and a base station as an O-RAN (O)-RU, an O-DU, an O-CU-CP, and an O-CU-UP respectively, Song: [0050]-[0051]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dent and Han in view of Song in order to further modify a RAN OAM-related function, and the SMO which comprises the Non-RT RIC and the OAM-related function, and the OAM-related function which is external to the Non-RT RIC and distinct from an Element Management System, and the network element from the teachings of Song.
One of ordinary skill in the art would have been motivated because it is also expected that wireless communication services for various purposes such as internet of things and a service requiring high reliability for a specific purpose may be provided (Song: [0009]).
Regarding claim 2, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Dent further discloses:
wherein the read configuration response comprises the requested configuration data (the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0044]-[0046]).
Regarding claim 3, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 2 above.
Dent further discloses:
wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria (DME service then identifies the translation application as the producing rApp for the job and sends the job to the translation application. Once the translation application has performed its translation and received confirmation of the completion of the command, the translation application directly notifies the consuming rApp through the R1 interface, Dent: [0030]).
Regarding claim 4, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 3 above.
Dent further discloses:
wherein the read configuration request further comprises information about managed entities of a service producer (rApp can evaluate when certain cell sites (both NR and LTE cell sites) should be powered off to save energy. rApp uses machine learning to analyze historical cell site usage data to determine when a particular cell site will not be needed for a long enough period that it is useful to power off the cite. The translation module translates the network element (cell site) identifiers, configuration parameter identifiers, and the values into the correct scheme used by the EMS. to power cell sites on or off, one EMS might require a call to change the administrative state to locked (from unlocked) while another EMS instead requires a call to change a power setting to off, Dent: [0039], [0041]-[0042]).
Regarding claim 7, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Dent further discloses:
wherein the read configuration response indicates whether or not the read configuration request was successful, or failed (the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., the rApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
Regarding claim 8, Dent discloses:
An apparatus for managing configuration data for a Non-Real-Time Radio Access Network Intelligent Controller Application (rApp) of an Open Radio Access Network (O-RAN), the apparatus comprising (In some embodiments, an rApp will change the set of NR anchor cell sites for one or more LTE cell sites (based on analysis of network topology. Applications may modify settings of 5G network elements via Distributed Unit (O-DU) and/or Centralized Unit (O-CU) elements of the 5G Open RAN (O-RAN), Dent: [0008], [0020]):
at least one memory storing computer-executable instructions (Such an electronic system includes various types of computer-readable media and interfaces for various other types of computer readable media. Electronic system includes a bus, processing unit(s), a system memory, a read-only memory. the processing unit(s) retrieve instructions to execute and data to process, Dent: Fig.7, [0048]-[0050], [0055]); and
at least one processor configured to execute the computer-executable instructions to (Electronic system includes a bus, processing unit(s), a system memory, a read-only memory. the processing unit(s) retrieve instructions to execute and data to process. The processing unit(s) may be a single processor or a multi-core processor, Dent: Fig.7, [0048]-[0050], [0055]):
receive, by a radio access network (RAN} operation and maintenance (OAM)-related function of a Service Management and Orchestration (SMO) framework of the O-RAN via an R1 interface of the Non-RT RIC, a read configuration request, wherein the read configuration request originates from the rApp, and wherein the read configuration request indicates requested configuration data of a network element of the O-RAN (The O-RAN architecture 100 includes a service management and orchestration framework (SMO). the non-RT RIC 200 includes an inter-application communication interface (referred to as the R1 interface) 205. one of the rApps sends a command to read configuration setting data from the legacy RAN. these data types allow the rApps to read configuration setting data from the legacy RAN and modify these configuration setting , Dent: Fig. 2, [0021], [0027], [0029]-[0030], [0046]),
determine, commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]); and
send, the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., therApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
wherein the requested configuration data is configuration data that configures a network element of the O-RAN (The rApps 215 and 220 may need to read and/or modify configuration settings of both 5G RAN settings. For the 5G network, the rApps 215 and 220 either use the Al interface to communicate with the near-RT MC or use the SMO layer to communicate directly with the O-Cloud and/or managed functions of the O-RAN, Dent: [0031]),
Dent does not explicitly disclose:
the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU);
wherein the SMO comprises the Non-RT RIC and the OAM-related function, and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System, and
However, in the same field of endeavor, Han teaches:
the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU) (The O-Cloud 206 is a cloud computing platfonn including a collection of physical infrastmcture nodes to host the relevant O-RAN functions. The radio portion/side of the logical architecture 200 includes the near-RT 15 RIC 214, the O-DU 215, the O-RAN Radio Unit (O-RU) 216, the O-CU-CP 221, and the O-CU-UP 222 functions, Han: [0021]-[0022]);
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dent in view of Han in order to further modify the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU) from the teachings of Han.
One of ordinary skill in the art would have been motivated because further enhanced operation of LTE and NR systems in the licensed, as well as unlicensed spectrum, is expected in future releases and 5G systems such as O-RAN systems (Han: [0005]).
Yet, Dent in view of Han does not explicitly disclose:
wherein the SMO comprises the Non-RT RIC and the OAM-related function, and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System, and
However, in the same field of endeavor, Song teaches:
wherein the SMO comprises the Non-RT RIC and the OAM-related function (the OAM function of the SMO provides data of RAN slice SLA assurance to the non-RT RIC, Song: Fig. 12A, [0140]), and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System (The non-RT RIC may collect data and create a policy, based on the information received from the OAM function. the NEF of the 5GC may be connected with the 3rd party entity over the N33/Nnef interface, and the 3rd party entity may be connected with the O-RAN (e.g., the EMS, the near-RT RIC), Song: Fig. 13B, [0110], [0140]), and
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dent and Han in view of Song in order to further modify the SMO which comprises the Non-RT RIC and the OAM-related function, and the OAM-related function which is external to the Non-RT RIC and distinct from an Element Management System, and the network element from the teachings of Song.
One of ordinary skill in the art would have been motivated because it is also expected that wireless communication services for various purposes such as internet of things and a service requiring high reliability for a specific purpose may be provided (Song: [0009]).
Regarding claim 9, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 8 above.
Dent further discloses:
wherein the read configuration response comprises the requested configuration data (the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0044]-[0046]).
Regarding claim 10, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 9 above.
Dent further discloses:
wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria (DME service then identifies the translation application as the producing rApp for the job and sends the job to the translation application. Once the translation application has performed its translation and received confirmation of the completion of the command, the translation application directly notifies the consuming rApp through the R1 interface, Dent: [0030]).
Regarding claim 11, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 10 above.
Dent further discloses:
wherein the read configuration request further comprises information about managed entities of a service producer (rApp can evaluate when certain cell sites (both NR and LTE cell sites) should be powered off to save energy. rApp uses machine learning to analyze historical cell site usage data to determine when a particular cell site will not be needed for a long enough period that it is useful to power off the cite. The translation module translates the network element (cell site) identifiers, configuration parameter identifiers, and the values into the correct scheme used by the EMS. to power cell sites on or off, one EMS might require a call to change the administrative state to locked (from unlocked) while another EMS instead requires a call to change a power setting to off, Dent: [0039], [0041]-[0042]).
Regarding claim 14, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 8 above.
Dent further discloses:
wherein the read configuration response indicates whether or not the read configuration request was successful, or failed (the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., the rApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
Regarding claim 15, Dent discloses:
A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor to cause the at least one processor to perform a method comprising (Some embodiments include electronic components, such as microprocessors. storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media), Dent: [0055]):
receiving, one of the rApps sends a command to read configuration setting data from the legacy RAN. these data types allow the rApps to read configuration setting data from the legacy RAN. the rApps 215 and 220 either use the Al interface to communicate with the near-RT MC or use the SMO layer to communicate directly with the O-Cloud and/or managed functions of the O-RAN, Dent: [0029]-[0031], [0046]);
determining, commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]); and
sending, the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., therApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
wherein the requested configuration data is configuration data that configures a network element of the O-RAN (The rApps 215 and 220 may need to read and/or modify configuration settings of both 5G RAN settings. For the 5G network, the rApps 215 and 220 either use the Al interface to communicate with the near-RT MC or use the SMO layer to communicate directly with the O-Cloud and/or managed functions of the O-RAN, Dent: [0031]),
Dent does not explicitly disclose:
by a radio access network (RAN) operation and maintenance {OAM)-related function of a Service Management and Orchestration (SMO) framework of the O-RAN via an R1 interface of the Non-RT RIC,
the network element being an O-RAN centralized unit (O-CU) or an 0-RAN distributed unit (O-DU).
wherein the SMO comprises the Non-RT RIC and the OAM-related function, and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System, and
However, in the same field of endeavor, Han teaches:
The O-RAN Non-Real Time (RT) RAN Intelligent Controller (RIC) 212 is a logical function within the SMO framework 102, 202 that enables non-realtime control and optimization of RAN elements and resources. receiving the model structure and training configurations from rApp 301 in the data 507 and collecting training 25 data from RAN. The monitoring services and management services in the Non-RT RIC are exposed to the rApps via the Rl interface, Han: [0033], [0042], [0061]]),
the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU) (The O-Cloud 206 is a cloud computing platfonn including a collection of physical infrastmcture nodes to host the relevant O-RAN functions. The radio portion/side of the logical architecture 200 includes the near-RT 15 RIC 214, the O-DU 215, the O-RAN Radio Unit (O-RU) 216, the O-CU-CP 221, and the O-CU-UP 222 functions, Han: [0021]-[0022]);
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dent in view of Han in order to further modify a Service Management and Orchestration (SMO) framework of the O-RAN via an R1 interface of the Non-RT RIC, and the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU) from the teachings of Han.
One of ordinary skill in the art would have been motivated because further enhanced operation of LTE and NR systems in the licensed, as well as unlicensed spectrum, is expected in future releases and 5G systems such as O-RAN systems (Han: [0005]).
Yet, Dent in view of Han does not explicitly disclose:
by a RAN OAM-related function,
wherein the SMO comprises the Non-RT RIC and the OAM-related function, and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System, and
However, in the same field of endeavor, Song teaches:
by a RAN OAM-related function (the OAM may query its RAN nodes according to the configuration messages detailed on the RAN function above. For example, the OAM may (transparently or not to intermediary nodes) pass on configuration requests it received from RAN, targeted to another RAN, or the OAM may pass such information directly to the RAN, via peer OAM, or via the Global OAM, Song: [0108]-[0111]),
wherein the SMO comprises the Non-RT RIC and the OAM-related function (the OAM function of the SMO provides data of RAN slice SLA assurance to the non-RT RIC, Song: Fig. 12A, [0140]), and
wherein the OAM-related function is external to the Non-RT RIC and distinct from an Element Management System (The non-RT RIC may collect data and create a policy, based on the information received from the OAM function. the NEF of the 5GC may be connected with the 3rd party entity over the N33/Nnef interface, and the 3rd party entity may be connected with the O-RAN (e.g., the EMS, the near-RT RIC), Song: Fig. 13B, [0110], [0140]), and
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dent and Han in view of Song in order to further modify a RAN OAM-related function, and the SMO which comprises the Non-RT RIC and the OAM-related function, and the OAM-related function which is external to the Non-RT RIC and distinct from an Element Management System, and the network element from the teachings of Song.
One of ordinary skill in the art would have been motivated because it is also expected that wireless communication services for various purposes such as internet of things and a service requiring high reliability for a specific purpose may be provided (Song: [0009]).
Regarding claim 16, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 15 above.
Dent further discloses:
wherein the read configuration response comprises the requested configuration data (the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0044]-[0046]).
Regarding claim 17, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 16 above.
Dent further discloses:
wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria (DME service then identifies the translation application as the producing rApp for the job and sends the job to the translation application. Once the translation application has performed its translation and received confirmation of the completion of the command, the translation application directly notifies the consuming rApp through the R1 interface, Dent: [0030]).
Regarding claim 18, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 17 above.
Dent further discloses:
wherein the read configuration request further comprises information about managed entities of a service producer (rApp can evaluate when certain cell sites (both NR and LTE cell sites) should be powered off to save energy. rApp uses machine learning to analyze historical cell site usage data to determine when a particular cell site will not be needed for a long enough period that it is useful to power off the cite. The translation module translates the network element (cell site) identifiers, configuration parameter identifiers, and the values into the correct scheme used by the EMS. to power cell sites on or off, one EMS might require a call to change the administrative state to locked (from unlocked) while another EMS instead requires a call to change a power setting to off, Dent: [0039], [0041]-[0042]).
Claims 5-6, 12-13, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dent-Han-
Song and in further view of Subramani Jayavelu et al. (US 2023/0069604 Al, hereinafter “Subramani”).
Regarding claim 5, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 3 above.
Dent further discloses:
wherein determining whether or not the read configuration request is valid comprises (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
Dent does not explicitly disclose:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
However, in the same field of endeavor, Subramani teaches:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data (In order to run a secure and hardened applications (e.g., xApps or rApps) on dRIC platform, some embodiments enforce the following policies on the applications: (1) network/security policies, (2) POD security policies, (3) limiting resource usages on a cluster, (4) controlling privileges to run, (5) K8s API Authorization (e.g., what resources can be created/deleted/updated),Subramani: [0243] ).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dent-Han-Song in view of Subramani in order to further modify determining whether the rApp is authorized to request the configuration data from the teachings of Subramani.
One of ordinary skill in the art would have been motivated because it provides services (such as metric collection, policy provisioning and configuration) to other RIC components (Subramani: [0004]).
Regarding claim 6, Dent-Han-Song-Subramani teaches all the claimed limitations as set forth in the rejection of claim 5 above.
Dent further discloses:
wherein determining whether or not the read configuration request is valid comprises (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria (commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]).
Regarding claim 12, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 10 above.
Dent further discloses:
wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the read configuration request is valid by (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
Dent does not explicitly disclose:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
However, in the same field of endeavor, Subramani teaches:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data (In order to run a secure and hardened applications (e.g., xApps or rApps) on dRIC platform, some embodiments enforce the following policies on the applications: (1) network/security policies, (2) POD security policies, (3) limiting resource usages on a cluster, (4) controlling privileges to run, (5) K8s API Authorization (e.g., what resources can be created/deleted/updated),Subramani: [0243] ).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dent-Han-Song in view of Subramani in order to further modify determining whether the rApp is authorized to request the configuration data from the teachings of Subramani.
One of ordinary skill in the art would have been motivated because it provides services (such as metric collection, policy provisioning and configuration) to other RIC components (Subramani: [0004]).
Regarding claim 13, Dent-Han-Song-Subramani teaches all the claimed limitations as set forth in the rejection of claim 12 above.
Dent further discloses:
wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the read configuration request is valid by (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria (commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]).
Regarding claim 19, Dent-Han-Song teaches all the claimed limitations as set forth in the rejection of claim 17 above.
Dent further discloses:
wherein determining whether or not the read configuration request is valid comprises (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
Dent does not explicitly disclose:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
However, in the same field of endeavor, Subramani teaches:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data (In order to run a secure and hardened applications (e.g., xApps or rApps) on dRIC platform, some embodiments enforce the following policies on the applications: (1) network/security policies, (2) POD security policies, (3) limiting resource usages on a cluster, (4) controlling privileges to run, (5) K8s API Authorization (e.g., what resources can be created/deleted/updated),Subramani: [0243] ).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dent-Han-Song in view of Subramani in order to further modify determining whether the rApp is authorized to request the configuration data from the teachings of Subramani.
One of ordinary skill in the art would have been motivated because it provides services (such as metric collection, policy provisioning and configuration) to other RIC components (Subramani: [0004]).
Regarding claim 20, Dent-Han-Song-Subramani teaches all the claimed limitations as set forth in the rejection of claim 19 above.
Dent further discloses:
wherein determining whether or not the read configuration request is valid comprises (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria (commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]).
Conclusion
In the case of amendments, applicant is respectfully requested to indicate the portion(s) of the
specification which dictate(s) the structure relied on for proper interpretation and support, for ascertaining the metes and bounds of the claimed invention.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANG C LEE whose telephone number is (703)756-1461. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM ET.
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, HASSAN PHILLIPS can be reached on (571)272-3940. 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.
/S.C.L./Examiner, Art Unit 2467
/HASSAN A PHILLIPS/Supervisory Patent Examiner, Art Unit 2467
