CTNF 18/762,175 CTNF 88479 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This action is in response to the application filed on 7/2/2024. The IDS filed on 8/12/2024 is considered. Claims 1-20 are examined and rejected. Claim Objections 07-29-01 AIA Claim s 13-20 are objected to because of the following informalities: these claims are method claims, but recite “apparatus” i.e., they recite in part: “the apparatus of claim 12…”. However, the independent claim they depend on is a method claim . Appropriate correction is required. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1 and 11 are rejected under 35 U.S.C. 101 because these claims are directed to a computer program code stored in memory. The specification states that “memory” is equated to a “computer readable storage medium”. Hence claims 1 and 11 are non-statutory since they cover transitory signals. This rejection can be overcome by amending the claims to include “non-transitory” preceding “memory”. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim (s) 1 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karaki (WO 2022229260 A1, from IDS, hereinafter “Karaki”) . Regarding Claim 1, Karaki teaches an apparatus for a network node (see FIG. 4C, source node) comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: sending a message to a target network node (see FIG. 4C, sending offloading request 401 to the Target node), the message comprising: a request for measurement information of a measurement on an energy cost of the target network node ( see FIG. 4C, para 77, step 401, a source RAN node sends a request (401) to a target RAN node to acquire information about its willingness to accept taking over certain amount of load from the source node. The source node requests an indication if the reported requirements and amount of load can be served by the target node. The source RAN node before initiating a load transfer, sends a message to a target node indicating an amount of load that the source RAN node wishes to offload to the neighbor node due to energy saving reasons … the request includes a value that represents Energy savings/Consumption of target node/i.e., measurement information of energy cost of target node, … This information would allow the target RAN to take a decision on whether to admit the traffic source RAN needs to offload and to maintain the conditions needed to make such admission possible for the whole time duration signaled by the source) and the message comprising a message field requesting impact information of an impact of at least one other network node on the measurement ( Examiners Note : Using BRI consistent with the specification, this limitation has been interpreted as – source request message including the reporting requirement for the target node to report to the source id the target node can accept the offloading from the source, while a third/other node has also requested offloading to the target node. Based on this interpretation, see paras 78-80, if the target node cannot fulfill the offloading request from the source, i.e., a case of failure/reject, the target node may have received requests related to offload from the source RAN node while also receiving requests to offload traffic from a third RAN node, and at least one of the two requests cannot be fulfilled; para 77-78 This decision is sent by the target node to the source based on the following report requirements from the source node to the target node: total Radio resource usage (GBR and non-GBR), data volume, total/average throughput, number of RRC connections, number of active UEs, radio conditions of the UEs to be offloaded and/or geographical location, served QoS flows, total amount of GBR and non GBR resources to be offloaded, load information such as those listed above, specified on a per network slice basis, e.g. on a per S-NSSA, information about the UE types to be offloaded (defined as, for example, UE categories, UE capabilities), a value that represent Energy savings/Consumption of source and/or target node within which the source is planning to offload traffic to the target RAN/i.e., collectively representing criteria for impact information in the Source request message for reporting to it from the Target; also see para 73, The Mobility Change Request (sent by a source RAN node to a target RAN node) includes, an overall level of energy efficiency improvement achievable by the sending node if the mobility change request is successful. Accordingly, the target cell can accept/reject the request by taking into account the impact of this action on its own energy consumption , considering the balance between the cost of serving UEs in potentially sub-optimal radio conditions and the gain in terms of energy saving (as per the indication received in the cause and purpose of the mobility)); receiving from the target network node the measurement information (see para 79, the target node sends rejection criteria including: if the estimated energy increase in target with the offloaded traffic is larger than Esource; or if the estimated energy increase in target is above a certain threshold; or if the estimated energy increase in target does not match the estimated one E target by the source node; if there are not enough radio resources to accommodate for the offloaded load/i.e., collectively representing measurement information for energy cost/increase ) and the impact information (see para 73, The Mobility Change Request (sent by a source RAN node to a target RAN node) includes, an overall level of energy efficiency improvement achievable by the sending node if the mobility change request is successful. Accordingly, the target cell can accept/reject the request by taking into account the impact of this action on its own energy consumption , considering the balance between the cost of serving UEs in potentially sub-optimal radio conditions and the gain in terms of energy saving (as per the indication received in the cause and purpose of the mobility); also see para 80, In one case of failure/reject, the target node may have received requests related to offload from the source RAN node while also receiving requests to offload traffic from a third RAN node, and at least one of the two requests cannot be fulfilled) ; and performing, based on the measurement information and the impact information, at least one action related to traffic offloading (see FIGs. 4A, 4B and 4C, para 78, The target RAN node receives the request and performs one of the following actions: the target node sends a failure message (403B) with an appropriate cause value, if the requested action cannot be initiated (FIG. 4B), the target node sends a rejection message with an appropriate cause value if the requested load cannot be accepted, the target node sends an acknowledgment message (403A) to indicate that the proposed request can be accepted (FIG. 4A), or the target node may respond with a message with assistance information (403C) that includes alternative proposal if the request from the source node cannot be fulfilled (FIG. 4C). Such alternative proposal may consist of an acceptable amount of traffic that can be offloaded towards the target RAN node, such as a maximum or a minimum amount of traffic). Karaki does not specify the underlined limitation “ the message comprising a message field requesting impact information of an impact of at least one other network node on the measurement”. However, Karaki teaches that the request message from the source node comprises both 1) energy cost of the target and 2) impact information of an impact of at least one other network node on the measurement. Therefore it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to specify that the source request message to the target comprises a message field including impact information along with the energy cost of the target, the motivation being, to improve the network level energy consumption by enabling coordination between RAN nodes to consider the energy consumption implication of RAN actions on other RAN nodes (see Karaki, Technical field). Regarding Claims 2, 13, Karaki teaches: the network node is a node in a radio access network; and wherein the measurement on the energy cost relates to at least one handover from the network node to the target network node (see para 72, the source RAN node sends a HANDOVER REQUEST message to the target RAN node to request the preparation of resources for a handover, and the message includes a cause field which indicates that the HO request is due to Energy saving reasons, e.g. "handover desirable for Energy saving reasons”. Accordingly, the source node distinguishes a HO caused by energy saving decision from another HO request). Regarding Claims 3, 14, Karaki teaches: the impact is the impact on the measurement of at least one traffic offloading action between the target network node and the at least one other network node (see para 78, FIG. 4C., step 403C, … if the target node is in the process to request to a third RAN node an offload of traffic, the incoming request from the first RAN node cannot be fulfilled, due to a change in the load at the target RAN node which will make not possible for the target RAN node to serve the potential load transferred from the source RAN node with the desired level of QoS or QoE/i.e., representing impact information of the offloading of third node) . Regarding Claims 4, 15, Karaki teaches: the impact information comprises an impact level, wherein the impact level is the energy cost due to the impact of the at least one other network node on the measurement (see para 27, new signaling information between the RAN nodes that allows the said RAN nodes and their neighbors to gain a better understanding of the impact on the energy efficiency measured or predicted for one or more RAN nodes, due to planned/performed action/request where at least one the RAN nodes is involved. Improvement in the network energy efficiency may have a direct impact on the operational cost of the network). Regarding Claims 5, 16, Karaki teaches: the impact information comprises an impact indicator which indicates whether the impact level includes any impact from ongoing offloading traffic ( Examiners Note: Using BRI consistent with the specification, the limitation “impact level” is interpreted as “impact metric”. Based on this interpretation, see para 202-205, the energy savings action requested by the first network node (source node) to the second network node (target node) with the information included in the first coordination message includes, … an indication of at least one energy metrics related to the second network node and an associated impact (actual or predicted) due to acknowledging the requests/indications received in the first coordination message; para 203, the first coordination message further includes an energy metric indicating how much energy consumption/efficiency is expected to improve at the first network node by means of applying the configuration at the first network node comprised in the first coordination message. In this way, the second node can compare the improvements in energy savings at the first node with the possible deterioration of its own energy savings when applying a second node configuration that compensates for the first node configuration. Such evaluation may lead to a decision at the second node to either send a reply message stating that the second node configuration is feasible or stating that such configuration is not feasible, due to energy savings reasons). Regarding Claim 6, Karaki teaches the apparatus of claim 1, wherein the impact information comprises a duration of the impact (see FIG. 4., para 77, step 401, a source RAN node initiates the procedure by sending a request (401) to a target RAN node to acquire information about its willingness to accept taking over certain amount of load from the source node/i.e., representing impact of offloading. The source node requests an indication if the reported requirements and amount of load can be served by the target node. The source RAN node before initiating a load transfer, sends a message to a target node indicating an amount of load that the source RAN node wishes to offload to the neighbor node due to energy saving reasons. The report may include at least one of the following information: a value that represent Energy savings/Consumption of source and/or target node. Example, estimated energy savings Esourc/Etarget if offloaded the requested traffic is signaled and/or the time window starting from a predefined point in time (e.g. the reception at target RAN of the signaling containing information on the offload) within which the source is planning to offload traffic to the target RAN ). Regarding Claims 7, 17, Karaki teaches: the message further comprises configuration information, wherein the configuration information is for configuring sending the measurement information and the impact information from the target network node (see para 77, a source RAN node initiates the procedure by sending a request (401) to a target RAN node to acquire information about its willingness to accept taking over certain amount of load from the source node. The source node requests an indication if the reported requirements and amount of load can be served by the target node/i.e., representing configuration information. The source RAN node before initiating a load transfer, sends a message to a target node indicating an amount of load that the source RAN node wishes to offload to the neighbor node due to energy saving reasons/i.e., representing measurement information and the impact information). Regarding Claims 8, 18, Karaki teaches: the configuration information comprises instructions to send the impact information in response to: an offloading action between the target network node and at least one other network node; the impact level exceeding a threshold (see para 73, the message from source to target may include an overall level of energy efficiency improvement achievable by the sending node if the mobility change request is successful. Accordingly, the target cell can accept/reject the request by taking into account the impact of this action on its own energy consumption, considering the balance between the cost of serving UEs in potentially sub-optimal radio conditions and the gain in terms of energy saving (as per the indication received in the cause and purpose of the mobility)) ; and/ or a ratio of the impact level to the energy cost exceeding a threshold . Karaki teaches that the target node can send an accept or reject message by calculating its energy consumption. Karaki does not specify a “threshold” to assess the energy impact. It would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention to use a threshold value by a target node in determining its own energy consumption, the motivation being using threshold as a design choice will enable the target node to have a definitive metric to compare its energy consumption. Regarding Claims 9, 19, Karaki teaches: the configuration information comprises instructions to send the impact information substantially immediately after the impact information is acquired and/ or to send the impact information concurrent with the measurement information (Examiners Note: Using BRI consistent with the specification, this limitation is interpreted as “target sends a reject response to the offload request from the source node, while it also receives the request to offload request from a third node. Based on this interpretation, see para 80, In one case of failure/reject, the target node may have received requests related to offload from the source RAN node while also receiving requests to offload traffic from a third RAN node, and at least one of the two requests cannot be fulfilled/i.e., because of impact in energy cost at the target to accept multiple offloading requests) . Regarding Claim 11, Karaki teaches an apparatus for a network node (see FIG. 4C, Target node) comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: receiving a message from a requesting network node (see FIG. 4C, receiving offloading request 401 by the Target node), the message comprising a request for measurement information of a measurement on an energy cost of the network node ( see FIG. 4C, para 77, step 401, a source RAN node sends a request (401) to a target RAN node to acquire information about its willingness to accept taking over certain amount of load from the source node. The source node requests an indication if the reported requirements and amount of load can be served by the target node. The source RAN node before initiating a load transfer, sends a message to a target node indicating an amount of load that the source RAN node wishes to offload to the neighbor node due to energy saving reasons … the request includes a value that represents Energy savings/Consumption of target node/i.e., measurement information of energy cost of target node, … This information would allow the target RAN to take a decision on whether to admit the traffic source RAN needs to offload and to maintain the conditions needed to make such admission possible for the whole time duration signaled by the source) , and the message comprising a message field requesting impact information of an impact of at least one other network node on the measurement ( Examiners Note : Using BRI consistent with the specification, this limitation has been interpreted as – source request message including the reporting requirement for the target node to report to the source id the target node can accept the offloading from the source, while a third/other node has also requested offloading to the target node. Based on this interpretation, see paras 78-80, if the target node cannot fulfill the offloading request from the source, i.e., a case of failure/reject, the target node may have received requests related to offload from the source RAN node while also receiving requests to offload traffic from a third RAN node, and at least one of the two requests cannot be fulfilled; para 77-78 This decision is sent by the target node to the source based on the following report requirements from the source node to the target node: total Radio resource usage (GBR and non-GBR), data volume, total/average throughput, number of RRC connections, number of active UEs, radio conditions of the UEs to be offloaded and/or geographical location, served QoS flows, total amount of GBR and non GBR resources to be offloaded, load information such as those listed above, specified on a per network slice basis, e.g. on a per S-NSSA, information about the UE types to be offloaded (defined as, for example, UE categories, UE capabilities), a value that represent Energy savings/Consumption of source and/or target node within which the source is planning to offload traffic to the target RAN/i.e., collectively representing criteria for impact information in the Source request message for reporting to it from the Target; also see para 73, The Mobility Change Request (sent by a source RAN node to a target RAN node) includes, an overall level of energy efficiency improvement achievable by the sending node if the mobility change request is successful. Accordingly, the target cell can accept/reject the request by taking into account the impact of this action on its own energy consumption , considering the balance between the cost of serving UEs in potentially sub-optimal radio conditions and the gain in terms of energy saving (as per the indication received in the cause and purpose of the mobility)); acquiring the measurement information (see para 77, the request includes a value that represents Energy savings/Consumption of target node/i.e., measurement information of energy cost of target node, … This information would allow the target RAN to take a decision on whether to admit the traffic source RAN needs to offload and to maintain the conditions needed to make such admission possible for the whole time duration signaled by the source) ; acquiring the impact information (see para 73, the target cell can accept/reject the request by taking into account the impact of this action on its own energy consumption, considering the balance between the cost of serving UEs in potentially sub-optimal radio conditions and the gain in terms of energy saving (as per the indication received in the cause and purpose of the mobility) ; sending to the requesting network node the measurement information and the impact information (see FIG. 4C, para 78, the target node responds with a message with assistance information (403C) that includes alternative proposal if the request from the source node cannot be fulfilled. Such alternative proposal may consist of an acceptable amount of traffic that can be offloaded towards the target RAN node, such as a maximum or a minimum amount of traffic) ; and performing, based on the sent measurement information and the sent impact information, at least one action related to traffic offloading (see FIGs. 4A, 4B and 4C, para 78, The target RAN node receives the request and performs one of the following actions: the target node sends a failure message (403B) with an appropriate cause value, if the requested action cannot be initiated (FIG. 4B), the target node sends a rejection message with an appropriate cause value if the requested load cannot be accepted, the target node sends an acknowledgment message (403A) to indicate that the proposed request can be accepted (FIG. 4A), or the target node may respond with a message with assistance information (403C) that includes alternative proposal if the request from the source node cannot be fulfilled (FIG. 4C). Such alternative proposal may consist of an acceptable amount of traffic that can be offloaded towards the target RAN node, such as a maximum or a minimum amount of traffic). Karaki does not specify the underlined limitation “ the message comprising a message field requesting impact information of an impact of at least one other network node on the measurement”. However, Karaki teaches that the request message from the source node comprises both 1) energy cost of the target and 2) impact information of an impact of at least one other network node on the measurement. Therefore it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to specify that the source request message to the target comprises a message field including impact information along with the energy cost of the target, the motivation being, to improve the network level energy consumption by enabling coordination between RAN nodes to consider the energy consumption implication of RAN actions on other RAN nodes (see Karaki, Technical field). Regarding Claim 12, Karaki teaches a method (see FIG. 4C) comprising: sending, by a requesting network node, a message to a target network node (see FIG. 4C, sending offloading request 401 to the Target node), the message comprising a request for measurement information of a measurement on an energy cost of the target network node ( see FIG. 4C, para 77, step 401, a source RAN node sends a request (401) to a target RAN node to acquire information about its willingness to accept taking over certain amount of load from the source node. The source node requests an indication if the reported requirements and amount of load can be served by the target node. The source RAN node before initiating a load transfer, sends a message to a target node indicating an amount of load that the source RAN node wishes to offload to the neighbor node due to energy saving reasons … the request includes a value that represents Energy savings/Consumption of target node/i.e., measurement information of energy cost of target node, … This information would allow the target RAN to take a decision on whether to admit the traffic source RAN needs to offload and to maintain the conditions needed to make such admission possible for the whole time duration signaled by the source) , and the message comprising a message field requesting impact information of an impact of at least one other network node on the measurement ( Examiners Note : Using BRI consistent with the specification, this limitation has been interpreted as – source request message including the reporting requirement for the target node to report to the source id the target node can accept the offloading from the source, while a third/other node has also requested offloading to the target node. Based on this interpretation, see paras 78-80, if the target node cannot fulfill the offloading request from the source, i.e., a case of failure/reject, the target node may have received requests related to offload from the source RAN node while also receiving requests to offload traffic from a third RAN node, and at least one of the two requests cannot be fulfilled; para 77-78 This decision is sent by the target node to the source based on the following report requirements from the source node to the target node: total Radio resource usage (GBR and non-GBR), data volume, total/average throughput, number of RRC connections, number of active UEs, radio conditions of the UEs to be offloaded and/or geographical location, served QoS flows, total amount of GBR and non GBR resources to be offloaded, load information such as those listed above, specified on a per network slice basis, e.g. on a per S-NSSA, information about the UE types to be offloaded (defined as, for example, UE categories, UE capabilities), a value that represent Energy savings/Consumption of source and/or target node within which the source is planning to offload traffic to the target RAN/i.e., collectively representing criteria for impact information in the Source request message for reporting to it from the Target; also see para 73, The Mobility Change Request (sent by a source RAN node to a target RAN node) includes, an overall level of energy efficiency improvement achievable by the sending node if the mobility change request is successful. Accordingly, the target cell can accept/reject the request by taking into account the impact of this action on its own energy consumption , considering the balance between the cost of serving UEs in potentially sub-optimal radio conditions and the gain in terms of energy saving (as per the indication received in the cause and purpose of the mobility)); receiving, by the requesting network node, from the target network node the measurement information (see para 79, the target node sends rejection criteria including: if the estimated energy increase in target with the offloaded traffic is larger than Esource; or if the estimated energy increase in target is above a certain threshold; or if the estimated energy increase in target does not match the estimated one E target by the source node; if there are not enough radio resources to accommodate for the offloaded load/i.e., collectively representing measurement information for energy cost/increase ) and the impact information (see para 73, The Mobility Change Request (sent by a source RAN node to a target RAN node) includes, an overall level of energy efficiency improvement achievable by the sending node if the mobility change request is successful. Accordingly, the target cell can accept/reject the request by taking into account the impact of this action on its own energy consumption , considering the balance between the cost of serving UEs in potentially sub-optimal radio conditions and the gain in terms of energy saving (as per the indication received in the cause and purpose of the mobility); also see para 80, In one case of failure/reject, the target node may have received requests related to offload from the source RAN node while also receiving requests to offload traffic from a third RAN node, and at least one of the two requests cannot be fulfilled) ; and performing, by the requesting network node and based on the measurement information and the impact information, at least one action related to traffic offloading (see FIGs. 4A, 4B and 4C, para 78, The target RAN node receives the request and performs one of the following actions: the target node sends a failure message (403B) with an appropriate cause value, if the requested action cannot be initiated (FIG. 4B), the target node sends a rejection message with an appropriate cause value if the requested load cannot be accepted, the target node sends an acknowledgment message (403A) to indicate that the proposed request can be accepted (FIG. 4A), or the target node may respond with a message with assistance information (403C) that includes alternative proposal if the request from the source node cannot be fulfilled (FIG. 4C). Such alternative proposal may consist of an acceptable amount of traffic that can be offloaded towards the target RAN node, such as a maximum or a minimum amount of traffic). Karaki does not specify the underlined limitation “ the message comprising a message field requesting impact information of an impact of at least one other network node on the measurement”. However, Karaki teaches that the request message from the source node comprises both 1) energy cost of the target and 2) impact information of an impact of at least one other network node on the measurement. Therefore it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to specify that the source request message to the target comprises a message field including impact information along with the energy cost of the target, the motivation being, to improve the network level energy consumption by enabling coordination between RAN nodes to consider the energy consumption implication of RAN actions on other RAN nodes (see Karaki, Technical field) . 07-21-aia AIA Claim (s) 10, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karaki in view of Soldati (WO 2024094868 A1, hereinafter “Soldati”) . Regarding Claims 10, 20, Karaki does not teach details regarding: send a further message to the target network node, the further message comprising an indication that the offloading traffic is complete; and wherein the configuration information comprises instructions to send the impact information in response to the target network node receiving the indication that the offloading traffic is complete. Soldati teaches this limitation: see page 66, lines 10-12, an event reporting configuration can indicate to report the energy efficiency of the target network node after the handover is completed for at least 5 UEs. Therefore it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the process of offloading for energy cost of the target, and specifying an event reporting configuration for handover completion and report the energy efficiency of the target, as taught by Soldati, the motivation being, determining an event reporting configuration using a set of parameters and conditions signaled from first network node to a second node to assemble and send the reports to for AL/ML in RAN (see Soldati, page 63, Event Reporting Configuration section). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEEPA BELUR whose telephone number is (571)270-3722. The examiner can normally be reached M-F 8 am - 4:30 pm. 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, Kevin Bates can be reached at 571-272-3980. 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. /DEEPA BELUR/Primary Examiner, Art Unit 2472 Application/Control Number: 18/762,175 Page 2 Art Unit: 2472
Prosecution Insights