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 .
Claim Objections
Claims 14 is objected to because of the following informalities:
Claim 14 recites “a ingress or egress backhaul radio link control (RLC) channel information”, wherein “a ingress” should have been “an ingress”.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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 person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 6-7 and 9-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by D1 (WO 2020167186 A1).
For claim 1, D1 discloses a method of wireless communication, comprising:
performing, by a first node of an integrated access and backhaul (IAB) network, a data transmission with a second node in the IAB network (FIGs. 1-17 and associated text, such as p7, 1st para “… Based on topology information for the IAB communications network, the CU determines routes, between one or more IAB nodes and/or one or more Distributed Units …”; note that routes between IAB nodes suggests data transmission between IAB nodes),
wherein the data transmission allows data originally scheduled to be transferred via the first node to be transferred via the second node (FIGs. 1-17 and associated text, such as p7, 1st para “… Based on topology information for the IAB communications network, the CU determines routes, between one or more IAB nodes and/or one or more Distributed Units …The route information comprises information of all possible routes in the IAB communications network. Each respective route information comprises a route identity and a respective node identity of one or more IAB nodes and/or one or more DUs comprised in the respective route. The first network node forwards the data packet to the second network node.” and p8; note the last sentence cited reads on “the data transmission allows data originally scheduled to be transferred via the first node to be transferred via the second node”).
For claim 9, D1 discloses a method of wireless communication, comprising:
configuring, by a first node of an integrated access and backhaul (IAB) network connected to a second node of the IAB network (FIGs. 1-17 and associated text, such as p7, last para extended to p8 “…The first network node is configured to: - receive a data packet intended for the UE; … operating in the IAB communications network …”), a packet transmission that is routable to a third node of the IAB network (p7, 1st para “… Based on topology information for the IAB communications network, the CU determines routes, between one or more IAB nodes …The route information comprises information of all possible routes in the IAB communications network. …”), wherein the configuring the packet transmission includes adding or removing of an additional packet header to or from a packet having a packet header, the additional packet header including an address of a destination (p6, 1st para, “… The routing information may comprise: … - The destination address is carried in the packet header. For downlink data transmissions, this destination address is added ... -For each packet, an intermediate IAB-node selects the next hop node for data transmission according to the routing table and the destination address carried in the packet’s adaptation info. …”; note that selecting the “next hop node” suggests removing the old destination address and adding a new destination address).
Claim 17 is rejected because it is a claim of a generic apparatus that performs the method of claim 1 and has the same subject matter of claim 1.
As to claim 2, D1 discloses claim 1, D1 further discloses: wherein the first node and the second node are configured to access to a same donor CU (central unit)-CP (control plane) or different donor CU-CPs (FIGs. 1-17 and associated text, such as FIGs. 7 and 12 in view of p28, last para, “The centralized entity (Donor CU-CP), e.g. the CU 134, may compute one and/or a common set of routes for all the IAB nodes 110 under different Donor DUs, such as shown in Figure 12. …”).
As to claim 3, D1 discloses claim 1, D1 further discloses: wherein the first node and the second node correspond to distributed units of a same or different IAB donors (FIGs. 1-17 and associated text, such as FIG. 7 shows IAB nodes 110 correspond to DUs 132 controlled by IAB donors 134 CU-CP or CU-UP; or FIG. 12 shows IAB1-IAB7, DonDU1, DonDU2 and DonCU).
As to claim 4, D1 discloses claim 1, D1 further discloses: the first node corresponds to a user plane of a central unit of an IAB donor and the second node corresponds to a distributed unit of a same or different IAB donors (FIGs. 1-17 and associated text, such as such as FIG. 7 shows IAB nodes 110 correspond to DUs 132 controlled by IAB donors 134 CU-CP or CU-UP, wherein CU-UP is a user plane of a central unit of an IAB donor, with UP being User Plane).
As to claim 6, D1 discloses claim 1, D1 further discloses: receiving, by the first node, from a third node of the IAB network that is a control plane of a central unit of an IAB donor (FIG. 7 shows IAB nodes 110 correspond to DUs 132 controlled by IAB donors 134 CU-CP or CU-UP), a configuration information that includes a F1-U tunnel identity, an identity of the second node (FIGs. 1-17 and associated text, such as p5, 3rd para “The U E-bearer-specific Id may be used by the IAB-node and the IAB-donor to identify the PDU’s UE-bearer. … The IAB-donor DU may also need to map Adapt information into the F1-U GTP-U TEID used between Donor DU and Donor CU. … IAB-node/IAB-donor address may be used …”; note that IAB-node address is considered as a node ID), an indication about whether a packet is transmitted via a tunnel between the first node and the second node, a destination IP address used for the packet for the data transmission via the tunnel between the first node and the second node, a source IP address used for the packet for the data transmission via the tunnel between the first node and the second node (p7, 1st para “… Based on topology information for the IAB communications network, the CU determines routes, between one or more IAB nodes …The route information comprises information of all possible routes in the IAB communications network. …”), wherein the configuring the packet transmission includes adding or removing of an additional packet header to or from a packet having a packet header, the additional packet header including an address of a destination (p6, 1st para, “… The routing information may comprise: … - The destination address is carried in the packet header. For downlink data transmissions, this destination address is added ... -For each packet, an intermediate IAB-node selects the next hop node for data transmission according to the routing table and the destination address carried in the packet’s adaptation info. …”; note that selecting the “next hop node” suggests removing and adding packet header.).
As to claim 7, D1 discloses claim 6, D1 further discloses: wherein the F1-U tunnel identity is indicated by i) a UE identity and DRB (dedicated radio bearer) identity or ii) a transport layer address and a GTP tunnel endpoint identifier (FIGs. 1-17 and associated text, such as p5, 3rd para “The U E-bearer-specific Id may be used by the IAB-node and the IAB-donor to identify the PDU’s UE-bearer. … The IAB-donor DU may also need to map Adapt information into the F1-U GTP-U TEID used between Donor DU and Donor CU. … IAB-node/IAB-donor address may be used …” and p10, 1st para “In destination-address-based routing each node may only select the next node along the path (not the whole path) since the whole path is not conveyed in the destination address. Thus, the end nodes cannot select alternative paths to the same target IAB node. Unable to support and/or provide differentiated routing for packets belong to different DRBs or backhaul RLC channels for the same UE or IAB node. Additional identification (i.e. UE-specific ID or UE-bearer specific ID) will be needed to carry in the Adaptation layer header for differentiated QoS treatment” and p4, item “SCTP:”, “… the full F1-U (GPRS Tunnelling Protocol User Plane (GTP-U)/UDP/IP) is terminated at the IAB node (like a normal DU) and the full F1-C (F1-AP/SCTP/IP) is also terminated at the IAB node (like a normal DU)”).
As to claim 10, D1 discloses claim 9, D1 further discloses: wherein the first node corresponds to a control plane of a central unit of a first IAB donor, the second node corresponds to a user plane of the central unit of the first IAB donor, and the third node is a distributed unit of a first IAB donor or a second IAB donor (FIG. 7, CU-CP, CU-UP 134 and DU 132).
As to claim 11, D1 discloses claim 10, D1 further discloses: transmitting an indication informing the second node that the packet requires the adding or the removing of the additional packet header (p6, 1st para, “… The routing information may comprise: … - The destination address is carried in the packet header. For downlink data transmissions, this destination address is added ... -For each packet, an intermediate IAB-node selects the next hop node for data transmission according to the routing table and the destination address carried in the packet’s adaptation info. …”; note that selecting the “next hop node” suggests removing the old destination address and adding a new destination address).
As to claim 12, D1 discloses claim 10, D1 further discloses: transmitting an indication informing the second node that the address is a destination IP address of the additional packet header (p4, p6, 1st para, “… The routing information may comprise: … - The destination address is carried in the packet header. For downlink data transmissions, this destination address is added ... -For each packet, an intermediate IAB-node selects the next hop node for data transmission according to the routing table and the destination address carried in the packet’s adaptation info. …” and p4, item “SCTP:”, “… the full F1-U (GPRS Tunnelling Protocol User Plane (GTP-U)/UDP/IP) is terminated at the IAB node ..”; note that selecting the “next hop node” suggests adding a new destination address and the address is an IP protocol one).
As to claim 13, D1 discloses claim 10, D1 further discloses: wherein the first node corresponds to a control plane of a central unit of a first IAB donor, the second node corresponds to an IAB-node, and the third node corresponds to a distributed unit of the first IAB donor or the second IAB donor (FIG. 7, CU-CP 134, IAB-node 110, and DU 132, which is corresponds to IAB-node 110).
As to claim 14, D1 discloses claim 13, D1 further discloses: sending, by the first node, configuring information that includes at least one of a backhaul adaptation protocol (BAP) address of a child node of the second node (FIG. 7 in view of p18, 2nd para “The information in the header of the data packet, i.e., in a Backhaul Adaptation Protocol (BAP) header is useful for the routing decision. This is since the header such as the BAP header contains the intended destination node identity and the route identity for the data packet.”), an ingress or egress backhaul radio link control (RLC) channel information (p27, 2nd para “… Using this information, the IAB1 may map packets containing route ID 19 to a high priority Backhaul RLC channel compared to packets containing route ID 13. The IAB nodes 110 may overrule (when needed) the default mapping for traffic/packets carried by all the ingress backhaul RLC channels or only for some specific channels …”), or a routing identification (p10, 1st para “In destination-address-based routing each node may only select the next node along the path …”; note that destination address is considered as a routing identification);
As to claim 15, D1 discloses claim 13, D1 further discloses: sending, by the first node, configuration information that includes at least one of an identify of a UE bearer (p4, 6th line from the bottom “Identification of the UE-bearer …”), or an indication indicating that the packet from the UE bearer needs the adding or the removing of the additional packet header (p6, 1st para, “… The routing information may comprise: … - The destination address is carried in the packet header. For downlink data transmissions, this destination address is added ... -For each packet, an intermediate IAB-node selects the next hop node for data transmission according to the routing table and the destination address carried in the packet’s adaptation info. …”; note that selecting the “next hop node” suggests removing and adding packet header.).
As to claim 16, D1 discloses claim 13, D1 further discloses: receiving, by the first node, from the second node, a report as to whether the second node supports the adding or the removing of the additional packet header (p6, 1st para, “… The routing information may comprise: … - The destination address is carried in the packet header. For downlink data transmissions, this destination address is added ... -For each packet, an intermediate IAB-node selects the next hop node for data transmission according to the routing table and the destination address carried in the packet’s adaptation info. …”; note that routing information is interpreted as a report), wherein the report is received via a F1 application protocol (F1AP) message (p26 “Note that by IAB node ID we could mean any identifier that may uniquely identify the IAB node (e.g. the gNB-DU/CU UE F1AP context ID that was used for identifying the MT part of the IAB-node when the IAB node gets attached, a new L2 IAB-node-address/IAB-node DU-address defined in TR 38.874 for L2 routing, etc.)”) or a radio resource control (RRC) message (p6, 1st para “This routing table may be configured by the CU-CP (e.g. via F1-AP or RRC). …”).
As to claim 18, D1 discloses claim 17, D1 further discloses: wherein the first node and the second node are configured to access to a same donor CU (central unit)-CP (control plane) or different donor CU-CPs (FIG. 7 shows CU-CP 134 associated with the first node), or wherein the first node and the second node correspond to distributed units of a same or different IAB donors (FIG. 7 shows DUs 132 that is associated with CUs 134), or wherein the first node corresponds to a user plane of a central unit of an IAB donor and the second node corresponds to a distributed unit of a same or different IAB donors (FIG. 7, CU-CP 134 for first and second IAB-node 110 and DU 132).
Claim Rejections - 35 USC § 103
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 5, 8 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over D1 (WO2020167186 A) in view of Le (EP 2119140 B1).
As to claim 5, D1 discloses claim 1, D1 further discloses: receiving, by the first node, from a third node of the IAB network that is a central unit of an IAB donor (FIG. 7 shows a IAB network having a plurality of different types of nodes),
D1 is silent but Le, in the same field of endeavor of data communication, discloses: a configuration information that includes at least one of a first destination internet protocol (IP) address, an IPv6 flow label, a differentiated services code point (DSCP) (FIGs. 1-17 and associated text, such as p9, 6th para “… the required level of security can be deduced by a direct reading of a field of the TCP/IP, UDP/IP headers of an IP packet: the IPv6 Flow Label field, the TOS field for Type Of Service, which includes DSCP information and undefined bits.”), an indication about whether a packet is transmitted via a tunnel between the first node and the second node, a second destination IP address used for the packet for the data transmission via the tunnel between the first node and the second node, a source IP address used for the packet for the data transmission via the tunnel between the first node and the second node, or an identity of the second node (p11, 3rd para from the bottom, “LSP (Label Switched Path) tunnels, consisting of a succession of routers, are created virtually in the network to route packets from an input router to an output or destination router (final destination or simply transit) , via transit routers. These tunnels are pre-established according to quality of service criteria. A tunnel is a label path. The explicit path is indicated in the MPLS header and allows end-to-end routing in the MPLS network. …”). OOSA would have been motivated to apply the teaching of Le to the routing by D1 to yield a predictable result of providing desired network QoS.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine D1 and Le for the benefit of providing desired network QoS (p11 of Le).
As to claim 8, D1 discloses claim 1, D1 further discloses: configuring a distributed unit of an IAB donor to allow a packet transmission to be routable via the distributed unit of the IAB donor (FIGs. 1-17 and associated text, such as FIG. 7 and p7, 1st para “… Based on topology information for the IAB communications network, the CU determines routes, between one or more IAB nodes and/or one or more Distributed Units …The route information comprises information of all possible routes in the IAB communications network. …”).
D1 is silent but Le, in the same field of endeavor of data communication, discloses: wherein the first node of the IAB network is a central unit of the IAB donor and the configuring of the distributed unit of the IAB donor includes sending configuring mapping information that includes at least one of a destination internet protocol (IP) address, an IPv6 flow label, a differentiated services code point (DSCP), or an IP address to be rewritten for the packet transmission (FIGs. 1-17 and associated text, such as p9, 6th para “… the required level of security can be deduced by a direct reading of a field of the TCP / IP, UDP / IP headers of an IP packet: the IPv6 Flow Label field, the TOS field for Type Of Service, which includes DSCP information and undefined bits.”), an indication about whether a packet is transmitted via a tunnel between the first node and the second node, a second destination IP address used for the packet for the data transmission via the tunnel between the first node and the second node, a source IP address used for the packet for the data transmission via the tunnel between the first node and the second node, or an identity of the second node (p11, 3rd para from the bottom, “LSP (Label Switched Path) tunnels, consisting of a succession of routers, are created virtually in the network to route packets from an input router to an output or destination router (final destination or simply transit) , via transit routers. These tunnels are pre-established according to quality of service criteria. A tunnel is a label path. The explicit path is indicated in the MPLS header and allows end-to-end routing in the MPLS network. …”). OOSA would have been motivated to apply the teaching of Le to the routing by D1 to yield a predictable result of providing desired network QoS.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine D1 and Le for the benefit of providing desired network QoS (p11 of Le).
As to claim 19, D1 discloses claim 17, D1 further discloses:
receiving, by the first node, from a third node of the IAB network that is a central unit of an IAB donor (FIGs. 1-17 and associated text, such as FIG. 7 shows a IAB network having a plurality of different types of nodes, including CU-CP, CU-UP in view of p5, last para “… routing in the RAN part is an important issue that enables a packet to be forwarded via multiple intermediate IAB-nodes between the IAB-donor and a specific UE. …”), an indication about whether a packet is transmitted via a tunnel between the first node and the second node, a second destination IP address used for the packet for the data transmission via the tunnel between the first node and the second node, a source IP address used for the packet for the data transmission via the tunnel between the first node and the second node, or an identity of the second node (p4, p6, 1st para, “… The routing information may comprise: … - The destination address is carried in the packet header. For downlink data transmissions, this destination address is added ... -For each packet, an intermediate IAB-node selects the next hop node for data transmission according to the routing table and the destination address carried in the packet’s adaptation info. …” and p4, item “SCTP:”, “… the full F1-U (GPRS Tunnelling Protocol User Plane (GTP-U)/UDP/IP) is terminated at the IAB node ..”), or
receiving, by the first node, from a third node of the IAB network that is a control plane of a central unit of an IAB donor, a configuration information that includes a F1-U tunnel identity, an identity of the second node, an indication about whether a packet is transmitted via a tunnel between the first node and the second node, a destination IP address used for the packet for the data transmission via the tunnel between the first node and the second node, a source IP address used for the packet for the data transmission via the tunnel between the first node and the second node (FIGs. 1-17 and associated text, such as FIG. 7 in view of p4, p6, 1st para, “… The routing information may comprise: … - The destination address is carried in the packet header. For downlink data transmissions, this destination address is added ... -For each packet, an intermediate IAB-node selects the next hop node for data transmission according to the routing table and the destination address carried in the packet’s adaptation info. …” and p4, item “SCTP:”, “… the full F1-U (GPRS Tunnelling Protocol User Plane (GTP-U)/UDP/IP) is terminated at the IAB node ...”).
D1 is silent but Le, in the same field of endeavor of data communication, discloses: a configuration information that includes at least one of a first destination internet protocol (IP) address, an IPv6 flow label, a differentiated services code point (DSCP) (FIGs. 1-17 and associated text, such as p9, 6th para “… the required level of security can be deduced by a direct reading of a field of the TCP/IP, UDP/IP headers of an IP packet: the IPv6 Flow Label field, the TOS field for Type Of Service, which includes DSCP information and undefined bits. …”). OOSA would have been motivated to apply the teaching of Le to the routing by D1 to yield a predictable result of providing desired network QoS.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine D1 and Le for the benefit of providing desired network QoS (p11 of Le).
As to claim 20, D1 discloses claim 17, D1 further discloses: configuring a distributed unit of an IAB donor to allow a packet transmission to be routable via the distributed unit of the IAB donor (FIGs. 1-17 and associated text, such as FIG. 7 in view of p4, p6, 1st para, “… The routing information may comprise: … - The destination address is carried in the packet header. For downlink data transmissions, this destination address is added ... -For each packet, an intermediate IAB-node selects the next hop node for data transmission according to the routing table and the destination address carried in the packet’s adaptation info. …” and p4, item “SCTP:”, “… the full F1-U (GPRS Tunnelling Protocol User Plane (GTP-U)/UDP/IP) is terminated at the IAB node ..”).
D1 is silent but Le, in the same field of endeavor of data communication, discloses: wherein the first node of the IAB network is a central unit of the IAB donor and the configuring of the distributed unit of the IAB donor includes sending configuring mapping information that includes at least one of a destination internet protocol (IP) address, an IPv6 flow label, a differentiated services code point (DSCP), or an IP address to be rewritten for the packet transmission (FIGs. 1-17 and associated text, such as p9, 6th para “… the required level of security can be deduced by a direct reading of a field of the TCP/IP, UDP/IP headers of an IP packet: the IPv6 Flow Label field, the TOS field for Type Of Service, which includes DSCP information and undefined bits. …”). OOSA would have been motivated to apply the teaching of Le to the routing by D1 to yield a predictable result of providing desired network QoS.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine D1 and Le for the benefit of providing desired network QoS (p11 of Le).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIANYE WU whose telephone number is (571)270-1665. The examiner can normally be reached M-TH 8am-6pm.
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, Yemane Mesfin can be reached at (571) 272-3927. 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.
/JIANYE WU/Primary Examiner, Art Unit 2462