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 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 1-2, 4, 6-8 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 20240357469 A1) in view of Serravalle (US 20100142407 A1) D1 (WO2020167186 A) in view of Le (EP 2119140 B1).
For claim 1, Huang discloses a method of wireless communication, comprising:
receiving, by a first node of an integrated access and backhaul (IAB) network, from a third node of the IAB network that is a central unit of an IAB donor, a configuration information that includes source node identifier used for a packet for a data transmission via a tunnel between the first node and a second node (“[0157] In this embodiment, the IAB node 1 may obtain the routing related information from an access side network element through RRC signaling, F1 signaling, X2 signaling, or Xn signaling; where the access side network element is one of: the gNB-CU, the IAB donor, a gNB, an eNB; or the IAB node 1 may obtain the routing related information from a core network element through S1 signaling or NG signaling; or the IAB node 1 may obtain the routing related information from an application server; [0158] 12) general packet radio service tunneling protocol (GTP) tunnel information; [0159] 13) a source node identifier; [0160] 14) a source node add”); and
performing, by the first node of the IAB network, the data transmission with the second node in the IAB network based on the configuration information (“[0055] The first IAB node transmits the data packet to the IAB donor directly; or, the first IAB node forwards the data packet to another IAB node, and transmits the data packet to the IAB donor through the another IAB node directly or indirectly.”).
Huang does not state that source node identifier is a source IP (internet protocol) address. In the field of endeavor of data communication, Serravalle teaches that a source node identifier is equivalent to source IP address (“[0104] … ach eNodeB will have a different IP address and this may be used to derive a source node identifier. It is further noted that, in a typical implementation, the TNL does not inform the application protocol of the source IP address, thus the application protocol is agnostic of the sender ID unless it is indicated in the application message itself.”). OOSA would have been motivated to replace source node identifier of Huang with the source IP address by Serravalle to yield a predictable result of facilitating routing.
Therefore, it would have been motivated before the effective filing date of the application to combine Huang and Serravalle for the benefit of facilitating routing ([0157] of Huang).
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 claims 2 and 18, Huang in view of Serravalle discloses claims 1 and 17, Huang 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, wherein the first node corresponds to an IAB donor and the second node corresponds to another IAB donor (FIGs. 1-6 and the associated text, such as FIG. 6 and “[0004] … An access node that supports the radio access of the UE and performs radio backhaul on data is called an IAB node. An access node that provides a radio backhaul function for the IAB node to connect the UE to the core network is called as an IAB donor. …” and “[0070] The IAB donor adds an adaptor layer header to the data packet, where the adaptor layer header includes at least one of: a source node identifier, a target node identifier, a UE identifier to which the data packet belongs, and a bearer identifier to which the data packet belongs, a channel identifier to which the data packet belongs, routing path information, Quality of Service (QOS) related information, general packet radio service tunneling protocol (GTP) tunnel information, control plane indication information, user plane indication information or protocol type indication information.”; note that though FIG. 6 shows the first node “IAB node 1” and second node “IAB donor node” are configured to access to a same donor CU “CU of the UE”, OOSA would have been motivated to replace “IAB node 1” with another IAB donor node because an IAB donor node is able to interface with UE, and if the directly access the core network is required as a design incentive according to MPEP 2143(F)).
As to claim 4, Huang in view of Serravalle discloses claim 1, Huang further discloses: the first node corresponds to an IAB donor and the second node corresponds to another IAB donor (FIG. 5 or 6, the tunnel F1-U is between an IAB node and an IAB donor node. OOSA would have been motivated to replace “IAB node 1” with another IAB donor node because an IAB donor node is able to interface with UE, and if the directly access the core network is required as a design incentive according to MPEP 2143(F)).
As to claims 6 and 19, Huang in view of Serravalle discloses claims 1 and 17, Huang further discloses: wherein the configuration information further includes at least one of:
a F1-U tunnel identity (FIG. 5 or 6, F1-U), an identity of the second node (FIG. 5 or 6, the identifier of second node of F1-U), an indication about whether a packet is transmitted via a tunnel between the first node and the second node (FIG. 5 or 6, packets are sent via tunnel F1-U between IAB node 1 and IAB donor node), or a destination IP address used for the packet for the data transmission via the tunnel between the first node and the second node (“[0194] … The IAB donor DU transmits the data to the IAB donor CU through the F1-U GTP tunnel.”).
As to claim 7. Huang in view of Serravalle discloses claim 6, Huang 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 (each of FIGs. 2-4 shows a F1-U tunnel between two UEs in view of the associated text, such as “[0190] In an architecture of FIG. 2, there is no adaptor layer on the CU. The IAB donor DU maps each radio bearer of each UE to the F1-U GTP tunnel. The CU may be enabled to identify the UE and the bearer to which the data packet belongs …” or “[0213] … The F1 GTP-U tunnel one-to-one corresponds to a bearer of the UE, which may be used for identifying the UE and the bearer to which the data packet belongs. …”).
As to claims 8 and 20, Huang in view of Serravalle discloses claims 1 and 17, Huang further discloses: wherein a central unit of a second node causes a distributed unit of the second
node to allow a packet transmission to be routable via the distributed unit of the second node by 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 (“[0224] Specifically, the IAB node1 obtains a 5QI or QCI value of a QoS flow or the bearer to which the UE data packet belongs from the received UE data packet. Then according to a mapping relationship between the configured QCI and a differentiated services code point (DSCP), or a mapping relationship between the 5QI and the DSCP, or a mapping relationship between the QCI and type of service (TOS), or a mapping relationship between the 5QI and the TOS, the corresponding DSCP or a TOS value are obtained. Then the IAB node1 maps the UE data packet to the bearer or the QoS flow of the corresponding IAB node1 according to the DSCP or the TOS value and the configured packet mapping rules (such as a packet filter set, or a TFT). Optionally, if the IAB node 1 maps the UE data packet to the corresponding QoS flow according to the DSCP or TOS value and the configured packet mapping rules, then the IAB node 1 maps the QoS flow to the radio bearer, and transmits the UE data packet to the IAB node 2 through the corresponding radio bearer”; or “[0144] The routing related information includes at least one of: [0145] 1) a target node identifier; [0146] 2) a target node address, such as a transport network layer (TNL) address or an IP address; [0147] 3) routing path information, which may include one of: a routing path identifier, a routing path number, a routing path index number, such as a path identifier or a number or index information in a routing table configured in the IAB node 1”).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights