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 .
This Office action is in response to the amendment filed on 03/17/2026. Claim 24 has been canceled and claims 40-42 have been withdrawn.
Claims 23, and 25-39 are presented for examination.
The objection to claim 26 is withdrawn in view of the amendment.
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 (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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 23, and 25-39 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP; TSG SA; Charging management; Study on charging aspects of edge computing (Release 17), 3GPP TR 28.815 V0.4.0, in view of Yang et al. (US 2021/0105191 A1).
As to claim 23, 3GPP discloses the invention as claimed, including an apparatus comprising:
memory to store virtualized resource (VR) usage measurement report information (i.e., performance data or charging information) (Figure 7.3.4.2-1; Figure 7.3.4.2-2; Section 7.1.2.1 Potential requirements for subscriber based charging: “The 5G system should support collecting charging information per UE on usage of 5GS capabilities based on edge application”; Section 7.1.2.2; Section 7.3.2 Potential charging requirements: “The charging mechanism for ECSP should support collecting charging information related to usage of infrastructure resource supporting each EAS”; Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “Performance data report: When the performance data (measurements or KPI) about usage of edge enabling infrastructure resource supporting the EAS is ready, the MnS producer reports the performance data to the CEF. The performance data about edge enabling infrastructure resource could be related to data volume transferred for the EAS, virtual CPU usage of the EAS, virtual memory usage of the EAS, virtual disk usage of the EAS, or the virtual storage of the EAS…the CHF stores received information and creates a CDR related to the event”); and
retrieve the VR usage measurement report information (i.e., performance data or charging information) from the memory (i.e., performance data report...to the CEF/CHF), the VR usage measurement report information associated with a virtualized instance (i.e., edge enabling infrastructure resource supporting the EAS) for an edge application server (EAS) (Figure 7.3.4.2-1; Figure 7.3.4.2-2; Section 7.3.2 Potential charging requirements: “The charging mechanism for ECSP should support collecting charging information related to usage of infrastructure resource supporting each EAS”; Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “Performance data report: When the performance data (measurements or KPI) about usage of edge enabling infrastructure resource supporting the EAS is ready, the MnS producer reports the performance data to the CEF. The performance data about edge enabling infrastructure resource could be related to data volume transferred for the EAS, virtual CPU usage of the EAS, virtual memory usage of the EAS, virtual disk usage of the EAS, or the virtual storage of the EAS…the CHF stores received information and creates a CDR related to the event”);
processing circuitry, coupled with the memory (Figure 7.3.4.2-1; Figure 7.3.4.2-2), to:
generate performance data associated with EAS resource usage based on the VR usage measurement report information (Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “The MnS Producer generates charging data related to the collected performance data and sends the charging data request for the CHF to process the related charging data for CDR generation purpose…The CEF generates charging data related to the collected performance data and sends the charging data request for the CHF to process the related charging data for CDR generation purpose”).
Although 3GPP discloses the VR usage measurement report information associated with a virtualized instance for an edge application server (EAS) (i.e., edge enabling infrastructure resource supporting the EAS), 3GPP does not specifically disclose the VR usage measurement report information is received from a network functions virtualization (NFV) management and orchestration (MANO) system, and a virtualized network function (VNF) or VNF component (VNFC) instance.
However, Yang discloses the VR usage measurement report information (i.e., “network resource information”, "network resource utilization data", "resource utilization parameters and values”) is received from a network functions virtualization (NFV) management and orchestration (MANO) system (Fig. 3B; ¶0027, “MEC devices 117 may include other types of network devices, such as an orchestrator (e.g., a network function virtualization orchestrator (NFVO), a mobile edge (ME) orchestrator, etc.), a virtualized infrastructure manager (VIM), a virtual network function manager (VNFM)…”; (¶0035, “monitor 205 may obtain the network resource information from an edge server (e.g., e.g., a virtualized network functions (VNFs), server, a host device, a virtual machine, etc. that provides an application service for an end device 180), an edge server controller (e.g., virtualized infrastructure manager (VIM), a virtual network function manager (VNFM), an ME platform manager, a Generic Virtual Network Function Manager (GVNFM), a Specialized Virtual Network Function Manager (SVNFM), etc.), and/or another type of MEC device 117”; ¶0036, “The network allocation service may calculate or obtain a resource usage value (e.g., used resources/available, a percentage (e.g., 50%, etc.), etc.) pertaining to the network resource based on the monitoring. The logical resources may be a partition of a physical resource dedicated to or allocated to, for example, a MEC device 117 or shared between MEC devices 117. The virtual resources may be an abstraction of physical and/or logical resources”; ¶0038, “network resource availability data may include parameters and values pertaining to various types of physical, logical and/or virtual resources that are available for use (e.g., capacity minus load)”; ¶0042, “the network resource information may include the network resource capability information. For example, the network resource capability information may indicate a maximum number of host devices and/or virtual entities (e.g., virtual machines, containers, etc.) that may run an application service or a category of an application service”; ¶0063, “monitor 205 of network device 130 receives network resource information 307 from MEC networks 115. For example, network resource information 307 may indicate current utilization of MEC resources”), and associated with a virtualized network function (VNF) or VNF component (VNFC) instance for an edge application server (EAS) (¶0034; ¶0035, “monitor 205 may obtain the network resource information from an edge server (e.g., e.g., a virtualized network functions (VNFs), server, a host device, a virtual machine, etc. that provides an application service for an end device 180), an edge server controller (e.g., virtualized infrastructure manager (VIM), a virtual network function manager (VNFM), an ME platform manager, a Generic Virtual Network Function Manager (GVNFM), a Specialized Virtual Network Function Manager (SVNFM), etc.), and/or another type of MEC device 117”; ¶0036, “The network resource utilization data may include resource utilization parameters and values pertaining to various types of physical resources (e.g., a processor, a storage device, a communication interface, a memory, a buffer, a communication link (e.g., wired, wireless, etc.), logical resources, and/or virtual resources”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of 3GPP to include the VR usage measurement report information is received from a network functions virtualization (NFV) management and orchestration (MANO) system, and a virtualized network function (VNF) or VNF component (VNFC) instance, as taught by Yang because it would enable automated scaling, precise cost allocation, and proactive performance optimization across virtualized environments (Yang; ¶0001; ¶0027; ¶0035).
As to claim 25, 3GPP discloses the apparatus of claim 23, wherein the performance data is associated with usage of an edge-enabling infrastructure resource supporting the EAS (Figure 7.3.4.2-1; Figure 7.3.4.2-2; Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “Performance data report: When the performance data (measurements or KPI) about usage of edge enabling infrastructure resource supporting the EAS is ready, the MnS producer reports the performance data to the CEF. The performance data about edge enabling infrastructure resource could be related to data volume transferred for the EAS, virtual CPU usage of the EAS, virtual memory usage of the EAS, virtual disk usage of the EAS, or the virtual storage of the EAS”).
As to claim 26, 3GPP discloses the apparatus of claim 25, wherein the performance data associated with usage of the edge-enabling infrastructure resource includes an indication of: a data volume transferred for the EAS, a virtual CPU usage of the EAS, a virtual memory usage of the EAS, a virtual disk usage of the EAS, a the virtual storage of the EAS (Figure 7.3.4.2-1; Figure 7.3.4.2-2; Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “The performance data about edge enabling infrastructure resource could be related to data volume transferred for the EAS, virtual CPU usage of the EAS, virtual memory usage of the EAS, virtual disk usage of the EAS, or the virtual storage of the EAS”).
As to claim 27, 3GPP discloses the apparatus of claim 25, wherein the processing circuitry is further to: determine that a quota associated with the edge-enabling infrastructure resource has been met; in response to the determination that the quota associated with the edge-enabling infrastructure resource has been met, send a request to a provisioning management services (MnS) producer to disable an operational state of the EAS; and receive, from the provisioning MnS producer, a response indicating a result of disabling the operational state of the EAS (Figure 7.3.4.2-2; Section 7.1.4.2 Possible solutions for inter-provider based charging: “The CHF of MNO is configured with quota and reporting threshold for 5GS inter-provider charging…(8) Quota management Trigger: A Trigger associated to Quota management is met. Units determination is performed when applicable. (9) Charging Data Request [Update, Quota Requested]: the SMF sends the request to the CHF, to be granted with more unit for the service to continue, and also for reporting the used units”; Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “The charging for edge enabling infrastructure resources could be supported with CTF embedded in the MnS producer or with CEF to enable the charging for MnS producer”; Section 7.3.4.3 Possible solutions for EAS deployment charging: “The charging for EAS deployment could be supported with CTF embedded in the MnS producer or with CEF to enable the charging for MnS producer”).
As to claim 28, 3GPP discloses the apparatus of claim 23, wherein the processing
circuitry is further to send a performance data report to a charging enablement function (CEF) that includes an indication of the generated performance data (Figure 7.3.4.1-3, “CEF”; Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “The charging for edge enabling infrastructure resources could be supported with CTF embedded in the MnS producer or with CEF to enable the charging for MnS producer…The MnS producer reports the performance data to the CEF according the reporting method selected by the CEF for the measurement job”).
As to claim 29, 3GPP discloses the apparatus of claim 28, wherein: the performance data report is sent to the CEF via a notifyFileReady file data reporting notification in response to an indication from the CEF that file data reporting is to be used; or wherein the performance data report is sent to the CEF via a reportStreamData operation in response to an indication from the CEF that streaming data reporting is to be used
(Figure 7.3.4.1-3, “CEF”; Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “The MnS producer reports the performance data to the CEF according the reporting method selected by the CEF for the measurement job. The performance data could be reported by a notifyFileReady notification (see 3GPPRelease 17 25 3GPP TR 28.815 V0.4.0 (2021-02) TS 28.532 [17]) if the file data reporting method is selected, or by the reportStreamData operation following the successful streaming connection establishment with the CEF (see TS 28.532 [17]) if the streaming data reporting method is selected”).
As to claim 30, 3GPP discloses the apparatus of claim 23, wherein the processing circuitry is further to: generate charging data related to the performance data; send a charging data request to a charging function (CHF) that includes an indication of the charging data; and receive a charging data response from the CHF that indicates a result of the charging data request (Figure 7.3.4.2-1, “CHF”; Figure 7.3.4.2-2, “charging data response from CHF”; Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “1ch-a) Charging Data Request [Event]: The MnS Producer generates charging data related to the collected performance data and sends the charging data request for the CHF to process the related charging data for CDR generation purpose. 1ch-b) Create CDR: the CHF stores received information and creates a CDR related to the event. 1ch—c) Charging Data Response [Event]: The CHF informs the MnS Producer on the result of the request”).
As to claim 31, 3GPP discloses the apparatus of claim 23, wherein the apparatus comprises a performance assurance MnS producer supporting a charging trigger function (CTF) (Figure 7.3.4.1-2: Converged charging architecture for edge enabling infrastructure resources and services with MnS producer supporting CTF; Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “The charging for edge enabling infrastructure resources could be supported with CTF embedded in the MnS producer or with CEF to enable the charging for MnS producer”).
As to claim 32, it is rejected for the same reasons set forth in claims 23-24 above. In addition, 3GPP discloses one or more computer-readable media storing instructions that, when executed by one or more processors, a performance assurance management services (MnS) producer (Figure 7.3.4.2-1: Charging for usage of edge enabling infrastructure resources (with MnS producer supporting CTF); Figure 7.3.4.2-2: Charging for usage of edge enabling infrastructure resources (with CEF enabling charging for MnS producer); Section 7.3.4.1 Potential charging architectures: “The possible solutions for charging for edge enabling infrastructure resources and services are based on the following potential converged charging architectures. In these architectures, it is assumed that the EES, MnS producer, CHF, CEF and Billing Domain are owned by the same ECSP”).
As to claims 33-36, they are rejected for the same reasons set forth in claims 25-28 respectively.
As to claims 37-38, they are rejected for the same reasons set forth in claim 29 above.
As to claim 39, it is rejected for the same reasons set forth in claim 30 above.
Applicant's arguments filed on 03/17/2026 have been fully considered but they are not persuasive:
Applicant asserts on page 8 of Remarks that “3GPP TR 28.815 generally teaches
solutions for edge enabling infrastructure resources charging, including reporting performance data to a Charging Function (CHF). However, it fails to disclose the specific generation of performance data based on usage reports received specifically from an NFV MANO system for an EAS.”
Examiner respectfully disagrees. Instant application’s PGPUB (US 2024/0007314 A1), paragraph [0026] states that:
[0026] 1) VR measurement report for VNF/VNFC: performance assurance MnS producer receives on or more VR usage measurement reports for VNF/VNFC instances related to the EAS from an ETSI NFV MANO system (see ETSI GS NFV-IFA 027) (emphasis added).
The NFV MANO (Network Functions Virtualization Management and Orchestration) system is a foundational architectural framework defined by ETSI that provides automation, orchestration, and manages virtual network resources.
In addition, 3GPP TR 28.815, section 2. References: [13] 3GPP TS 28.552: "Management and orchestration; 5G performance measurements"; section 7.3.2, and Section 7.3.4.2 disclose management and orchestration, 5G performance measurements, collecting measurement reports, KPIs, and performance data related to the virtual resources powering an Edge Application Server (EAS).
7.3.2 Potential charging requirements
REQ-CH_EC_EE-01: The charging mechanism for ECSP should support converged charging based on the usage of infrastructure resources supporting the EAS(s).
REQ-CH_EC_EE-02: The charging mechanism for ECSP should support collecting charging information related to usage of infrastructure resource supporting each EAS.
REQ-CH_EC_EE-03: The charging mechanism for ECSP should support converged charging for the following EAS deployment related procedures:
- EAS instantiation;
- EAS upgrade;
- EAS termination;
REQ-CH_EC_EE-04: The charging mechanism for ECSP should support converged charging for the following EAS signalling procedures:
- EAS registration;
- EAS discovery;
- Support to Service Continuity;
- Obtaining UE location;
- User plane path management events subscription/notification;
- Application Client information subscription/notification;
- Session with QoS.
REQ-CH_EC_EE-05: The charging mechanism for ECSP should support collecting usage of EES capabilities supporting the EAS(s).
Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: Figure 7.3.4.2-1: Charging for usage of edge enabling infrastructure resources (with MnS producer supporting CTF).
This solution uses performance data to report the usage of edge enabling infrastructure resources.
1) Performance data is ready: The performance data (measurements or KPI) about usage of edge enabling infrastructure resource supporting the EAS is ready. The performance data about edge enabling infrastructure resource could be related to data volume transferred for the EAS, virtual CPU usage of the EAS, virtual memory usage of the EAS, virtual disk usage of the EAS, or the virtual storage of the EAS.
1ch-a) Charging Data Request [Event]: The MnS Producer generates charging data related to the collected performance data and sends the charging data request for the CHF to process the related charging data for CDR generation purpose.
1ch-b) Create CDR: the CHF stores received information and creates a CDR related to the event.
1ch-c) Charging Data Response [Event]: The CHF informs the MnS Producer on the result of the request.
3GPP TR 28.815 does not explicitly disclose NFV MANO, however, it considers edge computing environments in which virtualized network functions and edge resources are managed using automation and orchestration mechanism, including dynamic allocation and management of virtualization resources.
Yang, on the other hand, discloses NFV MANO (¶0025; ¶0026; ¶0027; ¶0035; ¶0077). According to ETSI GS NFV-IFA 027, VR measurement report for VNF/VNFC: performance assurance MnS producer receives on or more VR usage measurement reports for VNF/VNFC instances related to the EAS from an ETSI NFV MANO system. The NFV MANO (Network Functions Virtualization Management and Orchestration) system is a foundational architectural framework defined by ETSI that provides automation, orchestration, and manages virtual network resources.
Yang discloses at paragraphs [0036], [0038] and [0042] and Figure 3B receiving virtual network resource measurement information (¶0035, “monitor 205 may obtain the network resource information from an edge server (e.g., e.g., a virtualized network functions (VNFs), server, a host device, a virtual machine, etc. that provides an application service for an end device 180), an edge server controller (e.g., virtualized infrastructure manager (VIM), a virtual network function manager (VNFM), an ME platform manager, a Generic Virtual Network Function Manager (GVNFM), a Specialized Virtual Network Function Manager (SVNFM), etc.), and/or another type of MEC device 117”; ¶0036, “The network allocation service may calculate or obtain a resource usage value (e.g., used resources/available, a percentage (e.g., 50%, etc.), etc.) pertaining to the network resource based on the monitoring. The logical resources may be a partition of a physical resource dedicated to or allocated to, for example, a MEC device 117 or shared between MEC devices 117. The virtual resources may be an abstraction of physical and/or logical resources”; ¶0038, “network resource availability data may include parameters and values pertaining to various types of physical, logical and/or virtual resources that are available for use (e.g., capacity minus load)”; ¶0042, “the network resource information may include the network resource capability information. For example, the network resource capability information may indicate a maximum number of host devices and/or virtual entities (e.g., virtual machines, containers, etc.) that may run an application service or a category of an application service”; ¶0063, “monitor 205 of network device 130 receives network resource information 307 from MEC networks 115. For example, network resource information 307 may indicate current utilization of MEC resources”).
Applicant asserts on page 8 of Remarks that “Yang generally teaches monitoring
network resource utilization associated with virtualized network functions. While Yang discusses MEC devices and orchestrators generally, it does not disclose the specific integration and generation of EAS-specific performance data based on measurements received from an NFV MANO system as claimed. There is no motivation to combine these references to arrive at the specific architectural integration of NFV MANO-sourced usage measurements for EAS charging.”
Examiner respectfully disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., the specific integration and generation of EAS-specific performance data based on measurements received from an NFV MANO system as claimed) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
In addition, Yang does not rely on to teach generate performance data associated with EAS resource usage based on the VR usage measurement report information. 3GPP TR 28.815 discloses generate performance data associated with EAS resource usage based on the VR usage measurement report information (Section 7.3.4.2 Possible solutions for edge enabling infrastructure resources charging: “The MnS Producer generates charging data related to the collected performance data and sends the charging data request for the CHF to process the related charging data for CDR generation purpose…The CEF generates charging data related to the collected performance data and sends the charging data request for the CHF to process the related charging data for CDR generation purpose”).
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 JUNGWON CHANG whose telephone number is (571)272-3960. The examiner can normally be reached 9AM-5:30PM.
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, GLENTON BURGESS can be reached at (571)272-3949. 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.
/JUNGWON CHANG/Primary Examiner, Art Unit 2454 May 30, 2026
Prosecution Insights