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 responsive to a response filed on April 10th, 2026. In this office action:
Claims 1-18, 32, and 34 are pending.
Claims 1-18, 32, and 34 are rejected.
Summary of Previous Office Action
In the Non-Final Office Action mailed on January 30th, 2026,
Claims 2, 7, 13-14, and 17 were objected to because of informalities.
Claim 6 was rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1-6, 9-18, 32, and 34 were rejected under 35 U.S.C. 101 because the claimed invention was directed to an abstract idea without significantly more.
Claims 1-7, 9-18, 32, and 34 were rejected under 35 U.S.C. 102 (a)(2) as being anticipated by Teyeb et al. (Pub. No. US 2023/0239755), hereinafter Teyeb.
Claim 8 was rejected under 35 U.S.C. 103 as being unpatentable over Teyeb et al. (Pub. No. US 2023/0239755), hereinafter Teyeb; in view of Xu et al. (Pub. No. US 2023/0189089), hereinafter Xu.
Response to Amendment
The Amendments filed on April 10th, 2026 have been entered.
Claims 1-2, 6-8, 11, 13-14, 17, 32, and 34 have been amended.
The previously raised claim objections for Claims 2, 7, 13-14, and 17 are withdrawn in light of the amendments.
The previously raised 35 U.S.C. 112(b) rejection for claim 6 is withdrawn in light of the amendments.
The previously raised 35 U.S.C. 101 rejection for claims 1-6, 9-18, 32, and 34.
Response to Arguments
Applicant’s arguments/remarks filed on April 10th, 2026 have been considered but are not persuasive.
The Examiner respectfully disagrees regarding Applicant’s argument that Teyeb doesn’t disclose during a migration of the node, sending by the first network node as a source IAB donor network node to a target donor network node an indication to the target IAB donor network node whether there is a localized UP at the node and a number of UP function modules localized at the node, as recited in the amended independent claim.
Teyeb discloses during a migration of the node, sending by the first network node as a source IAB donor network node to a target donor network node an indication to the target IAB donor network node whether there is a localized UP at the node and a number of UP function modules localized at the node (See Parag. [0095]; the source donor CU (the first network node) provides the target donor CU with information about the distributed unit (DU) of the migrating IAB node (e.g., served cells, transport layer addresses, etc.), and the target donor CU uses the information to respond with the F1-setup response message to the DU of the IAB node, after the IAB-MT is handed over to it. See Parag. [0008]; The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. See Parag. [0148]; “transport layer information” could refer to control plane and/or user plane (e.g., CU-CP addresses, CU-UP addresses, etc.). See also Parag. [0096-0105] [0236]).
The Examiner notes that the CU-UP addresses stand for Centralized Unit - User Plane addresses which are interpreted to refer to the transport layer addresses provided by the source donor CU (the first network node) to the target donor CU (target donor network node).
Regarding the dependent claims, the Examiner notes that the claim language doesn’t require all the optional elements of the claims as the claim recites “at least one of” the elements.
In addition, in response to applicant's argument that the references fail to show certain features of applicant’s invention, it is noted that the features upon which applicant relies are not recited in the rejected claim. 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).
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-7, 9-18, 32, and 34 are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by Teyeb et al. (Pub. No. US 2023/0239755), hereinafter Teyeb.
Claim 1. Teyeb discloses [a] method, comprising:
sending, by a first network node to a second network node, configuration information, the first network node being an Integrated Access and Backhaul (IAB) donor network node (See Parag. [0097-0098]; a network node is capable of operating as an IAB node (a second network node) comprising a DU and a MT. The IAB node performs a method comprising: obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU ... obtaining configuration information comprises receiving the configuration information from a source IAB donor CU (a first network node)),
wherein the configuration information is associated with a node capable of providing at least one user plane (UP) function (See Parag. [0097]; obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU (a node). See Parag. [0008]; The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. Examiner’s note: According to claim 2 below, the at least one UP function includes a gNB centralized unit UP (gNB-CU-UP) function); and
during a migration of the node, sending by the first network node as a source IAB donor network node to a target donor network node an indication to the target IAB donor network node whether there is a localized UP at the node and a number of UP function modules localized at the node (See Parag. [0095]; the source donor CU (the first network node) provides the target donor CU with information about the distributed unit (DU) of the migrating IAB node (e.g., served cells, transport layer addresses, etc.), and the target donor CU uses the information to respond with the F1-setup response message to the DU of the IAB node, after the IAB-MT is handed over to it. See Parag. [0008]; The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. See Parag. [0148]; “transport layer information” could refer to control plane and/or user plane (e.g., CU-CP addresses, CU-UP addresses, etc.). See also Parag. [0096-0105] [0236]).
Claim 2. Teyeb discloses [t]he method of claim 1,
Teyeb further discloses wherein: the at least one UP function includes a next generation Node B (gNB) centralized unit UP (gNB-CU-UP) function (See Parag. [0008]; The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions).
Claim 3. Teyeb discloses [t]he method of claim 1,
Teyeb further discloses wherein the second network node includes at least one of: the node, a mobile termination (MT) function of the node, a distributed unit (DU) function of the node, or a UP function of the node (See Parag. [0097-0098]; a network node is capable of operating as an IAB node (the second network node) comprising a DU and a MT. See also Parag. [0094-0095]; “IAB-mobile termination (IAB-MT),” “distributed unit (DU).” See also Parag. [0152]; the distributed unit (DU) of the IAB node).
Claim 4. Teyeb discloses [t]he method of claim 1,
Teyeb discloses the method further comprising: receiving, by the first network node from the second network node, first information comprising at least one of: an indication of the second network node which is a mobile node, an indication or a capability of the second network node to provide the at least one UP function, or a number of UP function modules localized in the second network node (See Parag. [0095]; the source donor CU (the first network node) provides the target donor CU with information about the distributed unit (DU) of the migrating IAB node (the second network node) (e.g., served cells, transport layer addresses, etc.). See Parag. [0163]; in the handover request, the source donor CU provides to the target donor CU the latest information about the IAB node's end of the F1 connection (i.e., the information received from the IAB node when the F1 connection with the source donor CU is set up, as well as any update of the F1 connection afterwards until the handover, e.g. additional info received via gNB-DU configuration update). Examiner’s interpretation: The Information about the distributed unit (DU) of the migrating IAB node are sent to the source donor CU from the IAB node).
Claim 5. Teyeb discloses [t]he method of claim 1,
Teyeb further discloses wherein a parent node of the second network node broadcasts information on the first network node’s capability of supporting communication with the node capable of providing the at least one UP function, or information on allowing access of the node capable of providing the at least one UP function (See Parag. [0005]; The IAB nodes also have a mobile termination (MT) part used to communicate with their parent nodes. See Parag. [0010] and Fig. 1; The IAB nodes and IAB donor include the Backhaul Adaptation Protocol (BAP), which is used for routing of packets to the appropriate downstream/upstream node and also mapping the user equipment (UE) bearer data to the proper backhaul radio link control (RLC) channel (and also between ingress and egress backhaul RLC channels in intermediate IAB nodes) to satisfy the end to end QoS requirements of bearers. See also Parag. [0153]).
Claim 6. Teyeb discloses [t]he method of claim 1
Teyeb further discloses comprising at least one of:
sending, by the first network node to the second network node, the first network node’s capability of supporting communication with the node capable of providing the at least one UP function, or info on allowing access of the node capable of providing the at least one UP function;
sending, by the first network node to a third network node, the second network node’s capabilities which include whether the at least one UP function is supported (See Parag. [0095]; the source donor CU (the first network node) provides the target donor CU (third network node) with information about the distributed unit (DU) of the migrating IAB node (the second network node) (e.g., served cells, transport layer addresses, etc.), and the target donor CU uses the information to respond with the F1-setup response message to the DU of the IAB node, after the IAB-MT is handed over to it. See Parag. [0008]; The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. Examiner’s interpretation: The Examiner notes that the claim requires only one limitation (at least one of));
receiving, by the first network node from the third network node, an indication of whether the second network node is authorized to provide or support the at least one UP function;
exchanging, by the first network node with the third network node before, after or during integration of the second network node, capabilities that include whether the first or third network node can serve the node capable of providing the at least one UP function; or
exchanging, by the third network node with a fourth network node before, after or during the integration of the second network node, capabilities that include whether the third or fourth network node can serve the node capable of providing the at least one UP function.
Claim 7. Teyeb discloses [t]he method of claim 1,
Teyeb further discloses wherein at least one of:
the first network node establishes or modifies a backhaul (BH) radio link control (RLC) for carrying traffic between the first network node and a UP function of the second network node (See Parag. [0010]; The IAB nodes and IAB donor include the Backhaul Adaptation Protocol (BAP), which is used for routing of packets to the appropriate downstream/upstream node and also mapping the user equipment (UE) bearer data to the proper backhaul radio link control (RLC) channel (and also between ingress and egress backhaul RLC channels in intermediate IAB nodes) to satisfy the end to end QoS requirements of bearers. Examiner’s interpretation: The Examiner notes that the claim requires only one limitation (at least one of));
the first network node configures a backhaul adaptation protocol (BAP) routing identifier (ID) for traffic between the first network node and the UP function of the second network node;
traffic between the first network node and the UP function of the second network node is transferred using the BH RLC channel and the BAP routing ID used for non-UP traffic or uplink non-UP traffic; or a traffic type of the non-UP traffic includes at least one of: UE-associated F1 application protocol (F1AP), non- UE-associated F1AP, non-F1, BAP control protocol data unit (PDU), UE-associated E1 application protocol (E1AP), non-UE-associated E1AP, or non-E1.
Claim 9. Teyeb discloses [t]he method of claim 1,
Teyeb discloses the method further comprising:
receiving, by the first network node from the second network node, a request for at least one IP address, wherein the request is for each of a plurality of usages comprising at least one of: all traffic, F1 user plane interface (F1-U) traffic, F1 control plane interface (F1-C) traffic, non-F1 traffic, non-E1 traffic, E1 traffic, or user plane traffic via an NG-U interface (See Parag. [0240]; after a handover of the IAB node to the target donor, the network node establishes the interface between the IAB node DU and the target IAB donor CU based on the obtained configuration information. For example, the network node may send an F1 Setup request to the IP address of the target IAB donor. See Parag. [0046]; The IP layer of F1-C only supports point-to-point transmission for delivering F1AP message. See also Parag. [0152-0153]); and
sending, by the first network node to the second network node, at least one of: one or more IPv6 addresses or one 64-bit IPv6 prefix for each of the usages, or one or more IPv4 addresses for each of the usages (See Parag. [0097-0098]; The IAB node performs a method comprising: obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU ... obtaining configuration information comprises receiving the configuration information from a source IAB donor CU (the first network node). See Parag. [0100]; the configuration information comprises a transport layer address of the target IAB donor CU. See Parag. [0046]; The gNB-CU and gNB-DU shall support IPv6 (IETF RFC 8200) and/or IPv4 (IETF RFC 791)).
Claim 10. Teyeb discloses [t]he method of claim 1,
Teyeb discloses the method further comprising: receiving, by the first network node from the second network node, at least one of: a number of IP addresses requested, or a number of IP addresses used for each of a plurality of usages (See Parag. [0154]; he IAB node initiates the F1 setup procedure with the target CU, using the information acquired about the target CU from the previous step (e.g., the IP address provided as part of the target CU information provided in the previous step is used as the destination address on the IP packet that is carrying the F1 setup request message)).
Claim 11. Teyeb discloses [t]he method of claim 1,
Teyeb discloses the method further comprising at least one of:
receiving, by the first network node, a backhaul adaptation protocol (BAP) address via a message from a UP function of the second network node; or
sending, by the first network node to the second network node, an IP address of the first network node; or sending, by the first network node to the second network node, a backhaul (BH) configuration for traffic between the first network node and the UP function of the second network node (See Parag. [0097-0098]; a network node is capable of operating as an IAB (integrated access and backhaul) node (the second network node) comprising a DU and a MT. The IAB node performs a method comprising: obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU ... obtaining configuration information comprises receiving the configuration information from a source IAB donor CU (the first network node). Examiner’s interpretation: The Examiner notes that the claim requires only one limitation (at least one of)).
Claim 12. Teyeb discloses [t]he method of claim 1,
Teyeb discloses the method further comprising: receiving, by the first network node from the second network node, a first message comprising at least one of: an F1 user plane interface (F1-U) uplink (UL) tunnel endpoint identifier (TEID) or a transport layer address (See Parag. [0095]; the source donor CU (the first network node) provides the target donor CU with information about the distributed unit (DU) of the migrating IAB node (the second network node) (e.g., served cells, transport layer addresses, etc.). See Parag. [0163]; in the handover request, the source donor CU provides to the target donor CU the latest information about the IAB node's end of the F1 connection (i.e., the information received from the IAB node when the F1 connection with the source donor CU is set up, as well as any update of the F1 connection afterwards until the handover, e.g. additional info received via gNB-DU configuration update). Examiner’s interpretation: The Information about the distributed unit (DU) of the migrating IAB node are sent to the source donor CU from the IAB node).
Claim 13. Teyeb discloses [t]he method of claim 12,
Teyeb discloses the method further comprising: sending, by the first network node to the UP function of the second network node, a second message comprising at least one of: a F1-U downlink (DL) TEID or a transport layer address (See Parag. [0097-0098]; a network node is capable of operating as an IAB node (the second network node) comprising a DU and a MT. The IAB node performs a method comprising: obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU ... obtaining configuration information comprises receiving the configuration information from a source IAB donor CU (the first network node). See Parag. [0100]; the configuration information comprises a transport layer address of the target IAB donor CU).
Claim 14. Teyeb discloses [t]he method of claim 1,
Teyeb discloses the method further comprising: sending, by the first network node, quality-of-service (QoS) flow level QoS parameters of a backhaul (BH) radio link control (RLC) channel (See Parag. [0010]; The IAB nodes and IAB donor include the Backhaul Adaptation Protocol (BAP), which is used for routing of packets to the appropriate downstream/upstream node and also mapping the user equipment (UE) bearer data to the proper backhaul radio link control (RLC) channel (and also between ingress and egress backhaul RLC channels in intermediate IAB nodes) to satisfy the end to end QoS requirements of bearers).
Claim 15. Teyeb discloses [t]he method of claim 14,
Teyeb further discloses wherein a protocol data unit (PDU) session and a BH RLC channel has a one-to-one mapping or a many-to-one mapping (See Parag. [0012-0014]; FIG. 4 illustrates an example functional view of the BAP sublayer ... In FIG. 4, the receiving part on the BAP entity delivers BAP protocol data units (PDUs) to the transmitting part on the collocated BAP entity ... The BAP sublayer provides data transfer services to upper layers. The BAP sublayer expects the following services from lower layers per RLC entity ... The BAP sublayer supports the following functions: data transfer; determination of BAP destination and path for packets from upper layers; determination of egress backhaul RLC channels for packets routed to next hop; routing of packets to next hop; differentiating traffic to be delivered to upper layers from traffic to be delivered to egress link; and flow control feedback and polling signaling).
Claim 16. Teyeb discloses [t]he method of claim 1,
Teyeb discloses the method further comprising: sending, by the first network node to the second network node, uplink backhaul (BH) information, wherein the uplink BH information includes at least one of a backhaul adaptation protocol (BAP) routing identifier (ID), a next-hop BAP address, or an ID of an egress BH RLC channel (See Parag. [0010]; The IAB nodes and IAB donor include the Backhaul Adaptation Protocol (BAP), which is used for routing of packets to the appropriate downstream/upstream node and also mapping the user equipment (UE) bearer data to the proper backhaul radio link control (RLC) channel (and also between ingress and egress backhaul RLC channels in intermediate IAB nodes) to satisfy the end to end QoS requirements of bearers).
Claim 17. Teyeb discloses [t]he method of claim 1,
Teyeb discloses the method further comprising:
sending, by the first network node to a third network node, a message with information comprising at least one of: a mapping between an IP security (IPsec) transport layer address and a list of an uplink or downlink General Packet Radio Service (GPRS) tunneling protocol (GTP) transport layer address, or at least one of an IP address, a differentiated services code point (DSCP) or a flow label configuration, on each protocol data unit (PDU) session or GTP tunnel between an UP function of the second network node and a core network (See Parag. [0097-0098]; The IAB node performs a method comprising: obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU ... obtaining configuration information comprises receiving the configuration information from a source IAB donor CU. Receiving the configuration information from a source IAB donor CU may comprise receiving a F1 message at the IAB node DU or receiving the configuration information from a source IAB donor CU comprises receiving a radio resource control (RRC) message at the IAB node MT. See Parag. [0100]; the configuration information comprises a transport layer address (at least one of an IP address) of the target IAB donor CU).
Claim 18. Teyeb discloses [t]he method of claim 17,
Teyeb further discloses wherein the information is sent from a third network node to a fourth network node, wherein the third network node and the fourth network node each is a network function or an entity of the core network (See Parag. [0097-0098]; ... obtaining configuration information comprises receiving the configuration information from a source IAB donor CU. Receiving the configuration information from a source IAB donor CU may comprise receiving a F1 message at the IAB node DU or receiving the configuration information from a source IAB donor CU comprises receiving a radio resource control (RRC) message at the IAB node MT).
Claim 32. Teyeb discloses [a] non-transitory computer-readable medium storing instructions that, when executed by a processor of a wireless communication apparatus (See Parag. [0109-0110]), cause the processor to:
send, by a first network node to a second network node, configuration information, the first network node being an Integrated Access and Backhaul, IAB, donor network node (See Parag. [0097-0098]; a network node is capable of operating as an IAB node (a second network node) comprising a DU and a MT. The IAB node performs a method comprising: obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU ... obtaining configuration information comprises receiving the configuration information from a source IAB donor CU (a first network node)), wherein the configuration information is associated with a node capable of providing at least one user plane (UP) function (See Parag. [0097]; obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU (a node). See Parag. [0008]; The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. Examiner’s note: According to claim 2 below, the at least one UP function includes a gNB centralized unit UP (gNB-CU-UP) function); and
during a migration of the node, send by the first network node as a source IAB donor network node to a target donor network node an indication to the target IAB donor network node whether there is a localized UP at the node and a number of UP function modules localized at the node (See Parag. [0095]; the source donor CU (the first network node) provides the target donor CU with information about the distributed unit (DU) of the migrating IAB node (e.g., served cells, transport layer addresses, etc.), and the target donor CU uses the information to respond with the F1-setup response message to the DU of the IAB node, after the IAB-MT is handed over to it. See Parag. [0008]; The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. See Parag. [0148]; “transport layer information” could refer to control plane and/or user plane (e.g., CU-CP addresses, CU-UP addresses, etc.). See also Parag. [0096-0105] [0236]).
Claim 34. Teyeb discloses [a] wireless communication device comprising a memory for storing instructions and at least one processor configured to execute the instructions (Parag. [0186] [0189]) to:
send, by a first network node to a second network node, configuration information, the first network node being an Integrated Access and Backhaul, IAB, donor network node (See Parag. [0097-0098]; a network node is capable of operating as an IAB node (a second network node) comprising a DU and a MT. The IAB node performs a method comprising: obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU ... obtaining configuration information comprises receiving the configuration information from a source IAB donor CU (a first network node)), wherein the configuration information is associated with a node capable of providing at least one user plane (UP) function (See Parag. [0097]; obtaining configuration information for establishing an interface between the IAB node DU and a target IAB donor CU (a node). See Parag. [0008]; The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. Examiner’s note: According to the specification, the at least one UP function includes a gNB centralized unit UP (gNB-CU-UP) function); and
during a migration of the node, send by the first network node as a source IAB donor network node to a target donor network node an indication to the target IAB donor network node whether there is a localized UP at the node and a number of UP function modules localized at the node (See Parag. [0095]; the source donor CU (the first network node) provides the target donor CU with information about the distributed unit (DU) of the migrating IAB node (e.g., served cells, transport layer addresses, etc.), and the target donor CU uses the information to respond with the F1-setup response message to the DU of the IAB node, after the IAB-MT is handed over to it. See Parag. [0008]; The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. See Parag. [0148]; “transport layer information” could refer to control plane and/or user plane (e.g., CU-CP addresses, CU-UP addresses, etc.). See also Parag. [0096-0105] [0236]).
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, 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 nonobviousness.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Teyeb et al. (Pub. No. US 2023/0239755), hereinafter Teyeb; in view of Xu et al. (Pub. No. US 2023/0189089), hereinafter Xu.
Claim 8. Teyeb discloses [t]he method of claim 7,
Teyeb doesn’t explicitly disclose wherein the traffic between the first network node and the UP function of the second network node includes at least one of: non-UP traffic, E1 traffic, or non-E1 traffic.
However, Xu discloses wherein the traffic between the first network node and the UP function of the second network node includes at least one of: non-UP traffic, E1 traffic, or non-E1 traffic (See Parag. [0056]; the CU-UP may send its own core network connection capability information to the CU-CP via a GNB-CU-UP E1 SETUP REQUEST message or a GNB-CU-CP E1 SETUP RESPONSE message. See also Parag. [0173]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify Teyeb, to include wherein the traffic between the first network node and the UP function of the second network node includes E1 traffic, as taught by Xu. This would be convenient such that the CU-CP can determine a corresponding network access mode for the user equipment according to the core network connection capability of the CU-UP (Xu, Parag. [0066]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Young et al. (US 2023/0239201) – Related art in the area of automating network slice configuration, (Abstract; In some implementations, a first device may receive, from a second device, network function (NF) configuration information indicating that an NF instance is to be provisioned to support a combination of network slices. The NF configuration information may include first network slice information regarding the first network slice and second network slice information regarding the second network slice. The first device may obtain, from a data structure, first slice configuration information associated with the NF instance supporting the first network slice and second slice configuration information associated with the NF instance supporting the second network slice. The first device may generate configuration parameters to provision the NF instance to support the combination of network slices and provide the configuration parameters to cause the NF instance to be provisioned to support the combination of network slices).
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5: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, Oscar Louie can be reached on 571-270-1684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights