Prosecution Insights
Last updated: August 17, 2026
Application No. 18/292,136

NODE IN WIRELESS COMMUNICATION SYSTEM AND METHOD PERFORMED BY THE SAME

Final Rejection §103
Filed
Jan 25, 2024
Priority
Jul 26, 2021 — CN 202110845470.8 +1 more
Examiner
SEYMOUR, JAMES PAUL
Art Unit
2419
Tech Center
2400 — Computer Networks
Assignee
Samsung Electronics Co., Ltd.
OA Round
2 (Final)
38%
Grant Probability
At Risk
3-4
OA Rounds
0m
Est. Remaining
31%
With Interview

Examiner Intelligence

Grants only 38% of cases
38%
Career Allowance Rate
3 granted / 8 resolved
-20.5% vs TC avg
Minimal -7% lift
Without
With
+-6.7%
Interview Lift
resolved cases with interview
Typical timeline
2y 5m
Avg Prosecution
37 currently pending
Career history
65
Total Applications
across all art units

Statute-Specific Performance

§101
1.1%
-38.9% vs TC avg
§103
63.1%
+23.1% vs TC avg
§102
12.1%
-27.9% vs TC avg
§112
22.0%
-18.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 8 resolved cases

Office Action

§103
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This Office Action is in response to communications filed on 6/5/2026. Claims 16, 18-21, 23-26, 28-31 & 33-39 are pending and presented for examination. Response to Amendment Claims 17, 22, 27 & 32 have been cancelled. Rejections to claims 22 & 32 under 35 USC 112(b) are thus moot. Claims 16, 18-21, 23-26, 28-31 & 33-35 have been amended. Rejection to claims 16, 18-21, 23-26, 28-31 & 33-35 under 35 USC 103 made in the prior record Non-Final Rejection dated 3/6/2026 have been withdrawn, but new grounds of rejections under 35 USC 103 have been made to these claims based on new reference Wang et al. (US 2012/0224525)(herein after “Wang”) New claims 36-39 have been added and are presented for examination. Response to Arguments Applicant's arguments filed 6/5/2026 have been fully considered but they are not persuasive. Regarding claims 16, 21, 26 & 31, applicant argues that Hsieh fails to disclose or suggest "transmitting, to a second node, a first message including a request for a first packet data convergence protocol (PDCP) sequence number for data transmission" and "receiving, from the second node in response to the request included in the first message, a second message including the PDCP sequence number" as disclosed in these claims. Examiner respectfully disagrees noting that Fig 6A & col 24, lines 27-42 of Hsieh disclose a n S-MN 104A that transmits in 618 an SgNB Release Request message to S-SN 106A (i.e. a second node) that in response leads to S-SN 106A transmitting at 633A an SN-to-MN SN Status Transfer message back to S-MN 104A that includes a current count value. Col 2, lines 53-55 disclose that a count value conveys a Sequence Number (SN), and to someone having ordinary skill in the art, a count value contains a PDCP sequence number. The process disclosed in Fig 6A & col 24, lines 27-42 is part of an MN to SN context transfer procedure, and thus by S-MN 104A sending the SgNB Release Request message 618, S-MN 104A is expecting to receive an SN Status Transfer message 633A from S-SN 106A, and certainly if there was no SgNB Release Request message 618 sent from S-MN 104A to S-SN 106A, then S-SN 106A would not have sent the SN Status Transfer message 633A. Further, there is no other communication with S-SN 106A in fig 6A to S-SN 106A after the SgNB Release Request message 618 and before S-SN 106a transmits the SN Status Transfer message 633A, so clearly the SN Status Transfer message 633A is a response to the SgNB Release Request message 618 sent by S-MN 104A. Since the S-SN Status Transfer message 633A includes a count value for a PDCP sequence number, the SgNB Release Request message 618 transmitted by S-MN 104A can be interpreted as a first message, transmitted to a second node, including a request for a first PDCP sequence number, and the SN Status Transfer message 633A from S-SN 106A interpreted as a first node receiving, from the second node in response to the request included in the first message, a second message including the PDCP sequence number, as required by the citied limitations above. Applicant argues that Hsieh does not disclose receiving the second message in response to the request included in the first message because the amended claims limit that the second message is received "in response to the request included in the first message", while Hsieh discloses a random access procedure or other intermediate operations are involved between the SgNB Release Request (618) and the SN Status Transfer (633A), and thus the SN Status Transfer in Hsieh is not a direct response to the request in the SgNB Release Request, presenting a clear structural distinction. Examiner respectfully disagrees noting that, as discussed above, there is there is no other communication with S-SN 106A in fig 6A to S-SN 106A after the SgNB Release Request message 618 and before S-SN 106a transmits the SN Status Transfer message 633A, so clearly the SN Status Transfer message 633A is a response to the SgNB Release Request message 618 sent by S-MN 104A. Even though the amended claim language of claim 1 does not require a “direct response”, since S-SN 106A sends the SN Status Transfer message 633A directly to S-MN 104A, the SN Status Transfer message may be interpreted as a direct response to S-MN 104A sending the SgNB Release Request message 618. Applicant argues that the SgNB Release Request Acknowledge message transmitted in operation 619 is in response to the SgNB Release Request message but does not include “first information about the PDCP sequence number for the data transmission”. Examiner agrees, but this argument is moot because examiner uses the SN Status Transfer message 633A which may be interpreted, as discussed in the previous paragraph above, as a response to the SgNB Release Request message 618 that includes a PDCP sequence number for data transmission, and not the SgNB Release Request Ack message. Applicant argues that Hsieh fails to disclose or suggest “predicting a second PDCP sequence number for data transmission based on the first information” in claims 16, 21, 26 and 31 because Hsieh merely discloses that the S-MN determines whether a first SN-to-MN Status Transfer message should include a current count, a default value (e.g. 0) or not value. Examiner respectfully disagrees noting that the S-MN determining a count value that may be default count value, which could be any value, or a current count value when constructing the second SN Status Transfer message 650C in fig 6C may be interpreted as predicting a PDCP sequence number. Per the current application specification (see [00254]), the “prediction of the PDCP sequence number” is a PDCP sequence number to be used for data transmission by a UE. Similarly, the determination of a current count value or a default count value that is sent as part of the second SN Status Transfer message 650C can be interpreted as the S-MN “predicting” a PCDP sequence number that will be used for data transmission between the T-eNB 104B and UE 102. Applicant argues that Kim fails to remedy the deficiencies discussed above, but this argument is moot as examiner has shown how Hsieh discloses the limitations cited above. Based on the above discussion, examiner maintains that Hsieh discloses the limitations of claims 16, 21, 26 & 31 cited and discussed above. Applicant’s arguments, see “Remarks”, filed 6/5/2026, with respect to the rejections of claims 16, 18-21, 23-26, 28-31 & 33-35 under 35 USC 103 have been fully considered and are persuasive. Therefore, these rejections have been withdrawn. However, upon further consideration, new grounds of rejections to these claims have been made in view of ne reference Wang et al. (US 2012/0224525)(herein after “Wang”). Regarding claims 16, 21, 26 & 31, applicant submits that amendments to these claim traverse the rejections of these claims under 35 USC 103 made in the Non-final Rejection dated 3/6/2026. Examiner agrees and withdraws rejections of claims 16, 21, 26 & 31 under 35 USC 103 made in the Non-final Rejection dated 3/6/2026. However, after further consideration, examiner introduces new grounds of rejections of claim 16, 21, 26 & 31 under 35 USC 103 based on new reference Wang. Applicant’s arguments with respect to claims 16, 21, 26 & 31, beyond those discussed in section 8 above, have been considered but are moot because the news grounds of rejections do not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Regarding claims 18-20, 23-25, 28-30 & 33-35, applicant submits that these claims traverse the rejections of these claims under 35 USC 103 made in the Non-final Rejection dated 3/6/2026 due to amendments and arguments made for claims 16, 21, 26 & 31 and due to their dependency on claims 16, 21, 26 & 31. Examiner agrees and withdraws rejections of claims 18-20, 23-25, 28-30 & 33-35 under 35 USC 103 made in the Non-final Rejection dated 3/6/2026. However, for the same reasons as discussed above, examiner introduces new grounds of rejections of claims 18-20, 23-25, 28-30 & 33-35 under 35 USC 103 based on new reference Wang. Applicant arguments, see “Remarks”, filed 6/5/2026, with respect to new claims 36-39 have been considered. However, for the same reasons as discussed above, examiner rejects claims 36-39 under 35 USC 103 based on Hsieh in view of Wang and Kim. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claims 16, 20, 21, 25, 26, 30, 31 & 35-39 are rejected under 35 U.S.C. 103 as being unpatentable over Hsieh et al. (US 11765627)(herein after “Hsieh) in view of Wang et al. (US 2012/0224525)(herein after “Wang”) and further in view of Kim et al. (US 2020/0068639)(herein after “Kim”). Regarding claims 16 & 26, Hsieh discloses a first node in a wireless communication system, the first node comprising: a transceiver (Fig 1A, col 6, lines 41-47 & col 7, lines 15-23 disclose an eNB 104A in a wireless communication system that may operate as a master node MN 104A (i.e. a first node). Col 10, lines 8-21 disclose the eNB 104A can transmit, at 311, a SgNB Addition Request message and can receive, at 312, an SgNB Addition Request Acknowledgement message (i.e. comprises a transceiver).); and at least one processor coupled to the transceiver (Col 7, lines 15-23 discloses processing hardware 130 including one or more general purpose processors coupled to a controller 132 that manages SN status transfer messaging (i.e. coupled to the transceiver that transmits and receives SN Status Transfer messages).) and a method of a first node (Col 31, lines 40-43 disclose a method for eNB 104A (i.e. a first node).), wherein the method is comprised, and the first node is configured, to: transmit, to a second node, a first message including a request for a first packet data convergence protocol (PDCP) sequence number for data transmission (Fig 6A & col 24, lines 27-42 disclose S-MN 104A transmits in 618 an SgNB Release Request message to S-SN 106A (i.e. a second node) that in response leads to S-SN 106A transmitting at 633A an SN-to-MN SN Status Transfer message back to S-MN 104A that includes a current count value. Col 2, lines 53-55 disclose that a count value conveys a Sequence Number (SN), and to someone having ordinary skill in the art, a count value contains a PDCP sequence number. Thus, the SgNB Release message transmitted by S-MN 104A can be interpreted as a first message of a request for a first PDCP sequence number.); receive, from the second node in response to the request included in the first message, a second message including the first PDCP sequence number (Fig 6A & col 24, lines 39-42 disclose the S-MN 104A receiving in 633A, from S-SN 106A, an SN-to-MN SN Status Transfer message (i.e. a second message), in response to S-MN 104A sending the SgNB Release Request message and the completion of an of a random access procedure between UE 102 and T-eNB 104B, that includes the current count value for DRB D (i.e. a first PDCP sequence number for a data transmission).); predict a second PDCP sequence number for data transmission based on the first PDCP sequence number (Fig 6C, col 24, lines 57-67 & col 25, lines 1-32 disclose that S-MN 104A, based on receiving the SN-to-MN SN Status Transfer message from S-SN 106A including the current count value (i.e. the first PDCP sequence number), may use the current count value to construct a second SN Status Transfer message to TeNB 104B about a PDCP sequence number (i.e. predict a second PDCP sequence number) for data transmission by TeNB 104B.). Hsieh fails to disclose but Wang teaches to transmit, to the second node, the second PDCP sequence number (Fig 13 & [0097] discloses a Donor eNB (i.e. a first node) transmitting to a Relay (i.e. a second node) a PDCP Status Report containing uplink and downlink PDCP SN status information (i.e. a PDCP sequence number).); and perform data forwarding to a third node through the second node based on the second PDCP sequence number (Fig 13 & [0099]-[0100] discloses the Relay transmitting an SN Status Transfer message to a target eNB (i.e. a third node) with SN status information (i.e. based on the PDCP sequence number) and forwards buffered data (i.e. from the Donor eNB) to the target eNB.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have a first node, or a method for a first node to, transmit, to a second node, a first message including a request for a first packet data convergence protocol (PDCP) sequence number for data transmission; receive, from the second node in response to the request included in the first message, a second message including the first PDCP sequence number; predict a second PDCP sequence number for data transmission based on the first PDCP sequence number, as disclosed by Hsieh, and transmit, to the second node, the second PDCP sequence number; and perform data forwarding to a third node through the second node based on the second PDCP sequence number, as taught by Wang. The motivation to do so would have been to have a master eNB, or a method for a master eNB, request from a secondary eNB a current PDCP sequence number, receive from the secondary eNB the current PDCP sequence number, predict a second PDCP sequence number for transmission by a target eNB, send the second PDCP sequence number to the secondary eNB, and forward data to the target eNB through the secondary eNB based on the second PDCP number, in order to prepare for, and prevent loss of data during, a handover of a UE, receiving data from the master eNB through the secondary eNB, to the Target eNB. Hsieh fails to disclose but Kim further teaches wherein the performing of data forwarding is to a plurality of third nodes (Fig 13, [0231] & [0234-237] discloses forwarding of PDCP packets from an S-GW to a source eNB 1310 and a target eNB 1330 based on a first PDCP sequence number of 4 for packet 1340, a second PDCP sequence number of 5 for packet 1341 and third through ninth PDCP sequence numbers 6-12 for packets 1342-1348.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have a first node, or a method for a first node to, transmit, to a second node, a first message including a request for a first packet data convergence protocol (PDCP) sequence number for data transmission; receive, from the second node in response to the request included in the first message, a second message including the first PDCP sequence number; predict a second PDCP sequence number for data transmission based on the first PDCP sequence number, and transmit, to the second node, the second PDCP sequence number; and perform data forwarding to a third node through the second node based on the second PDCP sequence number, as disclosed by Hsieh and Wang, wherein the performing of data forwarding is to a plurality of third nodes, as further taught by Kim. The motivation to do so would have been to have a master eNB, or a method for a master eNB, request from a secondary eNB a current PDCP sequence number, receive from the secondary eNB the current PDCP sequence number, predict a second PDCP sequence number for use in determining PDCP sequence numbers for transmissions by a plurality of target eNBs, send the second PDCP sequence number to the secondary eNB, and forward data to the plurality of target eNBs through the secondary eNB using PDCP sequence numbers based on the second PDCP sequence number, in order to prepare for, and prevent loss of data during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the plurality of Target eNBs. Regarding claims 20 & 30, Hsieh in view of Wang and Kim disclose the first node of claim 26 and the method of claim 16. Hsieh discloses wherein the first node comprises a master node, wherein the second node comprises a source secondary node, and wherein the third node comprises a target node (Fig 6A & col 24, lines 1-26 disclose a master node MN 104A (i.e. first node), a source secondary node 106A (second node) and a target eNB 106B (i.e. third node).). Hsieh fails to disclose wherein the target node is a secondary node. However, a second embodiment of Hsieh discloses wherein the target node is a secondary node (Fig 7A and col 25, lines 63-67, col 26, lines 1-67 and col 27, lines 1-19 discloses the same MN-to-eNB change in the scenario where there is a target secondary eNB to maintain dual connectivity during the change. In this scenario, the second information about the second PDCP sequence number is used to determine a third PDCP sequence number for data transmission of the target secondary eNB (i.e. the target secondary eNB is the third node in this scenario).). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the first node of claim 26, or the method of claim 16, wherein the first node comprises a master node, wherein the second node comprises a source secondary node, and wherein the third node comprises a target node, as disclosed by Hsieh in view of Wang and Kim, wherein the target eNB is a target secondary eNB, as taught by Hsieh. The motivation to do so would have been to have a master eNB, or a method for a master eNB, request from source secondary eNB a current PDCP sequence number, receive from the source secondary eNB the current PDCP sequence number, predict a second PDCP sequence number for use in determining PDCP sequence numbers for transmission by a plurality of target eNBs, send the second PDCP sequence number to the source secondary eNB, and forward data to a plurality of target eNBs through the source secondary eNB using PDCP sequence numbers based on the second PDCP sequence number, in order to prepare for, and prevent loss of data during, a conditional handover of a UE from the source secondary eNB to one of the Target eNBs. Regarding claims 21 & 31, Hsieh discloses a second node in a wireless communication system, the second node comprising: a transceiver (Fig 1A, col 6, lines 41-47 & col 7, lines 23-32 disclose a gNB 106A in a wireless communication system that may operate as a secondary node SN 106A (i.e. a second node). Col 10, lines 8-21 disclose the gNB 106A can receive, at 311, a SgNB Addition Request message and can transmit, at 312, an SgNB Addition Request Acknowledgement message (i.e. comprises a transceiver).); and at least one processor coupled to the transceiver (Col 7, lines 23-32 discloses processing hardware 140 including one or more general purpose processors coupled to a controller 142 that manages SN status transfer messaging (i.e. coupled to the transceiver that transmits and receives SN Status Transfer messages).) and a method of a second node (Col 31, lines 40-43 disclose a method for gNB 106A (i.e. a second node).), wherein the method is comprised, and the first node is configured, to: receive, from a first node, a first message including a request for a first packet data convergence protocol (PDCP) sequence number for data transmission (Fig 6A & col 24, lines 27-42 disclose S-SN 106A receives in 618 an SgNB Release Request message from S-MN 104A (i.e. a second node) that in response leads to S-SN 106A transmitting at 633A an SN-to-MN SN Status Transfer message back to S-MN 104A that includes a current count value. Col 2, lines 53-55 disclose that a count value conveys a Sequence Number (SN). Thus, the SgNB Release message received by S-SN 106A can be interpreted as a first message including a request for a first PDCP sequence number.), transmit, to the first node in response to the request in the first message, a second message including the first PDCP sequence number (Fig 6A & col 24, lines 39-42 disclose the S-SN 106A transmitting in 633A, to S-MN 104A, an SN-to-MN SN Status Transfer message (i.e. a second message), in response to S-MN 104A sending the SgNB Release Request message and the completion of an of a random access procedure between UE 102 and T-eNB 104B, that includes the current count value for DRB D (i.e. first information about a PDCP sequence number for a data transmission).); wherein a second PDCP sequence number for data transmission is predicted, the second PDCP sequence number being predicted based on the first PDCP sequence number (Fig 6C, col 24, lines 57-67 & col 25, lines 1-32 disclose that S-MN 104A, based on receiving the SN-to-MN SN Status Transfer message from S-SN 106A including the current count value (i.e. the first PDCP sequence number), may use the current count value to construct a second SN Status Transfer message to TeNB 104B about a PDCP sequence number (i.e. predict a second PDCP sequence number) for data transmission by TeNB 104B.). Hsieh fails to disclose but Wang teaches wherein the predicted second PDCP sequence number is received from the first node (Fig 13 & [0097] discloses a Donor eNB (i.e. a first node) transmitting to a Relay (i.e. a second node) a PDCP Status Report containing uplink and downlink PDCP SN status information (i.e. a PDCP sequence number).); and performing data transmission through the first node to a third node based on the second PDCP sequence number (Fig 13 & [0099]-[0100] discloses the Relay transmitting an SN Status Transfer message to a target eNB (i.e. a third node) with SN status information (i.e. based on the PDCP sequence number) and forwards buffered data (i.e. from the Donor eNB) to the target eNB.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have a second node, or a method for a second node to, receive, from a first node, a first message including a request for a first packet data convergence protocol (PDCP) sequence number for data transmission, transmit, to the first node in response to the request in the first message, a second message including the first PDCP sequence number; wherein a second PDCP sequence number for data transmission is predicted, the second PDCP sequence number being predicted based on the first PDCP sequence number, as disclosed by Hsieh, and wherein the predicted second PDCP sequence number is received from the first node; and performing data transmission through the first node to a plurality of third nodes based on the second PDCP sequence number, as taught by Wang. The motivation to do so would have been to have a secondary eNB, or a method for a secondary eNB to, receive a request from a master eNB of a current PDCP sequence number, transmit to the master eNB, in response to receiving the request, the current PDCP sequence number, receive from the master eNB a predicted second PDCP sequence number for transmission by a target eNB, and perform forwarding of data from the master eNB to the target eNB based on the second PDCP sequence number, in order to prepare for, and prevent loss of data during, handover of a UE, receiving data from the master eNB through the secondary eNB, to the Target eNB. Hsieh fails to disclose but Kim further teaches wherein the performing of data transmission is to a plurality of third nodes (Fig 13, [0231] & [0234-237] discloses forwarding of PDCP packets from an S-GW to a source eNB 1310 and a target eNB 1330 based on a first PDCP sequence number of 4 for packet 1340, a second PDCP sequence number of 5 for packet 1341 and third through ninth PDCP sequence numbers 6-12 for packets 1342-1348.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have a second node, or a method for a second node to, receive, from a first node, a first message including a request for a first packet data convergence protocol (PDCP) sequence number for data transmission, transmit, to the first node in response to the request in the first message, a second message including the first PDCP sequence number; wherein a second PDCP sequence number for data transmission is predicted, the second PDCP sequence number being predicted based on the first PDCP sequence number, wherein the predicted second PDCP sequence number is received from the first node; and performing data transmission through the first node to a plurality of third nodes based on the second PDCP sequence number, as disclosed by Hsieh and Wang, wherein the performing of data transmission is to a plurality of third nodes, as further taught by Kim. The motivation to do so would have been to have a secondary eNB, or a method for a secondary eNB to, receive a request from a master eNB of a current PDCP sequence number, transmit to the master eNB, in response to receiving the request, the current PDCP sequence number, receive from the master eNB a predicted second PDCP sequence number for use in determining PDCP sequence numbers for transmission by a plurality of target eNBs, and perform forwarding of data from the master eNB to the plurality of target eNBs using the PDCP sequence numbers based on the second PDCP sequence number, in order to prepare for, and prevent loss of data during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the Target eNBs. Regarding claims 25 & 35, Hsieh in view of Wang and Kim disclose the second node of claim 31 and the method of claim 21. Hsieh discloses wherein the first node comprises a master node, wherein the second node comprises a source secondary node, and wherein the third node comprises a target node (Fig 6A & col 24, lines 1-26 disclose a master node MN 104A (i.e. first node), a source secondary node 106A (second node) and a target eNB 106B (i.e. third node).). Hsieh fails to disclose wherein the target node is a secondary node. However, a second embodiment of Hsieh discloses wherein the target node is a secondary node (Fig 7A and col 25, lines 63-67, col 26, lines 1-67 and col 27, lines 1-19 discloses the same MN-to-eNB change in the scenario where there is a target secondary eNB to maintain dual connectivity during the change. In this scenario, the second information about the second PDCP sequence number is used to determine a third PDCP sequence number for data transmission of the target secondary eNB (i.e. the target secondary eNB is the third node in this scenario).). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the second node of claim 31, or the method of claim 21, wherein the first node comprises a master node, wherein the second node comprises a source secondary node, and wherein and the third node comprises a target node, as disclosed by Hsieh in view of Wang and Kim, wherein the target eNB is a target secondary eNB, as taught by Hsieh. The motivation to do so would have been to have a secondary eNB, or a method for a secondary eNB, receive a request from a master eNB of a current PDCP sequence number, transmit to the master eNB the current PDCP sequence number, receive from the master eNB a prediction of a second PDCP sequence number for use in determining PDCP sequence numbers for transmission by a plurality of target eNBs, and forward data to the plurality of target eNBs from the master eNB using PDCP sequence numbers based on the second PDCP number, in order to prepare for, and prevent loss of data during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the Target eNBs. Regarding claims 36 & 38, Hsieh in view of Wang and Kim disclose the first node of claim 26, and the method of claim 16. Kim further teaches wherein the data forwarding is performed with different PDCP sequence numbers as starting points for the plurality of third nodes, the different PDCP sequence numbers being determined based on the second PDCP sequence number (Fig 13, [0231] & [0234-237] discloses forwarding of PDCP packets from an S-GW to a source eNB 1310 and a target eNB 1330 based on a first PDCP sequence number of 4 for packet 1340, a second PDCP sequence number of 5 for packet 1341 and third through ninth PDCP sequence numbers 6-12 for packets 1342-1348, wherein different PDCP sequence numbers (i.e. PDCP sequence numbers 4-9) for PDCP packets transmitted to source eNB 1310 are used than PDCP sequence numbers (i.e. PDCP sequence numbers 10-12.) for PDCP packets transmitted to target eNB 1330. The source eNB 1310 using PDCP sequence number 4 as a starting point for transmitting PDCP packets 1340-1345 and target eNB 1330 uses PDCP sequence number 10 as a starting point for transmitting packets 1346-1348.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have the first node of claim 26, or the method of claim 16, as disclosed by Hsieh and Wang and Kim, wherein the data forwarding is performed with different PDCP sequence numbers as starting points for the plurality of third nodes, the different PDCP sequence numbers being determined based on the second PDCP sequence number, as further taught by Kim. The motivation to do so would have been to have a master eNB, or a method for a master eNB, request from a secondary eNB a current PDCP sequence number, receive from the secondary eNB the current PDCP sequence number, predict a second PDCP sequence number for use in determining different PDCP sequence numbers for transmissions by a plurality of target eNBs, send the second PDCP sequence number to the secondary eNB, and forward data to the plurality of target eNBs through the secondary eNB using different PDCP sequence numbers based on the second PDCP sequence number, in order to prepare for, prevent loss of data during, and perform correct re-ordering of PDCP packet transmissions at the UE during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the plurality of Target eNBs. Regarding claims 37 & 39, Hsieh in view of Wang and Kim disclose the second node of claim 31, and the method of claim 21. Kim further teaches further comprising: determining a plurality of third PDCP sequence numbers for data transmission to the plurality of third nodes, wherein the data transmission is performed with the plurality of third PDCP sequence numbers as starting points for the plurality of third nodes (Fig 13, [0231] & [0234-237] discloses forwarding of PDCP packets from an S-GW to a source eNB 1310 and a target eNB 1330 based on a first PDCP sequence number of 4 for packet 1340, a second PDCP sequence number of 5 for packet 1341 and third through ninth PDCP sequence numbers 6-12 for packets 1342-1348, wherein different PDCP sequence numbers (i.e. PDCP sequence numbers 4-9) for PDCP packets transmitted to source eNB 1310 are used than PDCP sequence numbers (i.e. PDCP sequence numbers 10-12.) for PDCP packets transmitted to target eNB 1330. The source eNB 1310 using PDCP sequence number 4 as a starting point for transmitting PDCP packets 1340-1345 and target eNB 1330 uses PDCP sequence number 10 as a starting point for transmitting packets 1346-1348.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have the second node of claim 31, or the method of claim 21, as disclosed by Hsieh and Wang and Kim, wherein the data transmission is performed with different PDCP sequence numbers as starting points for the plurality of third nodes, the different PDCP sequence numbers being determined based on the second PDCP sequence number, as further taught by Kim. The motivation to do so would have been to have a secondary eNB, or a method for a secondary eNB, receive a request from a master eNB for a current PDCP sequence number, transmit to the master eNB the current PDCP sequence number, receive from the master eNB a prediction of a second PDCP sequence number for use in determining different PDCP sequence numbers for transmissions by a plurality of target eNBs, receive the second PDCP sequence number from the master eNB, and transmit data to the plurality of target eNBs from the master eNB using different PDCP sequence numbers based on the second PDCP sequence number, in order to prepare for, prevent loss of data during, and perform correct re-ordering of PDCP packet transmissions at the UE during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the plurality of Target eNBs. Claims 18, 23, 28 & 33 are rejected under 35 U.S.C. 103 as being unpatentable over Hsieh et al. (US 11765627)(herein after “Hsieh) in view of Wang et al. (US 2012/0224525)(herein after “Wang”) and Kim et al. (US 2020/0068639)(herein after “Kim”), as applied to claims 16, 21, 26 & 31, and further in view of Park et al. (US 20210385703)(herein after “Park”). Regarding claims 18 & 28, Hsieh in view of Wang and Kim discloses the method of claim 16 and the first node of claim 26. Hsieh fails to disclose wherein the second PDCP sequence number is used to determine a fourth PDCP sequence number for data transmission of the third node. However, Kim further teaches wherein the second PDCP sequence number is used to determine a fourth PDCP sequence number for data transmission of the third node (Fig 13 & [0231] and [0236]-[0237] discloses a source MN eNB where a PDCP sequence number 5 is the highest PDCP sequence number transmitted to the UE (i.e. a first PDCP sequence number) which is used to determine a PDCP sequence number 6 (i.e. a second PDCP sequence number) that is transmitted in a SN status Transfer Message to a target SN eNB that is then used to determine a PDCP sequence number between 6 and 12 (i.e. a third PDCP sequence number) for transmission of packet 1342 and a different PDCP sequence number (i.e. a fourth PDCP sequence number) between 6 and 12 for transmission of packet 1343 by the target SN eNB.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have the first node of claim 26, or the method of claim 16, as disclosed by Hsieh and Wang and Kim, wherein the second PDCP sequence number is used to determine a fourth PDCP sequence number for data transmission of the third node, as further taught by Kim. The motivation to do so would be to have a master eNB, or a method for a master eNB, request from a secondary eNB a current PDCP sequence number, receive from the secondary eNB the current PDCP sequence number, predict a second PDCP sequence number for use in determining PDCP sequence numbers for transmission by a plurality of target eNBs, send the second PDCP sequence number to the secondary eNB, wherein the secondary eNB uses PDCP sequence numbers based on the second PDCP sequence number to determine a fourth PDCP sequence number, and forward data to the plurality of target eNBs through the secondary eNB based on the second and fourth PDCP sequence numbers, in order to prepare for, and prevent loss or out of sequence ordering of data during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the Target eNBs. Hsieh fails to disclose wherein the fourth PDCP sequence number for data transmission is through the first node. However, Park further teaches wherein the fourth PDCP sequence number for data transmission is through the first node (Fig 7 & [0112] discloses a source master gNB forwarding data to a target master eNB for transmission by the target master eNB.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have a first node of claim 26, or the method of claim 16, wherein the second PDCP sequence number is used to determine a fourth PDCP sequence number for data transmission of the third node, as disclosed by Hsieh and Wang and Kim, wherein the fourth PDCP sequence number for data transmission is through the first node, as further taught by Park. The motivation to do so would be to have a master eNB, or a method for a master eNB, request from a secondary eNB a current PDCP sequence number, receive from the secondary eNB the current PDCP sequence number, predict a second PDCP sequence number for use in determining PDCP sequence numbers for transmission by a plurality of target eNBs, send the second PDCP sequence number to the secondary eNB, wherein the secondary eNB uses PDCP sequence numbers based on the second PDCP sequence number to determine a fourth PDCP sequence number, and forward data to the plurality of target eNBs through the secondary eNB based on the second and fourth PDCP sequence numbers, in order to prepare for, and prevent loss or out of sequence ordering of data during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the Target eNBs. Regarding claims 23 & 33, Hsieh in view of Wang and Kim disclose the second node of claim 31 and the method of claim 21. Hsieh fails to disclose wherein the second PDCP sequence number is used to determine a fourth PDCP sequence number for data transmission of the third node. However, Kim further teaches wherein the second information about the second PDCP sequence number is used to determine a fourth PDCP sequence number for data transmission of the third node (Fig 13 & [0231] and [0236]-[0237] discloses a source MN eNB where a PDCP sequence number 5 is the highest PDCP sequence number transmitted to the UE (i.e. first information about a first PDCP sequence number) which is used to determine a PDCP sequence number 6 (i.e. second information about a second PDCP sequence number) that is transmitted in a SN status Transfer Message to a target SN eNB that is then used to determine a PDCP sequence number between 6 and 12 (i.e. a third PDCP sequence number) for transmission of packet 1342 and a different PDCP sequence number (i.e. a fourth PDCP sequence number) between 6 and 12 for transmission of packet 1343 by the target SN eNB.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have the first node of claim 31, or the method of claim 21, as disclosed by Hsieh and Wang and Kim, wherein the second PDCP sequence number is used to determine a fourth PDCP sequence number for data transmission of the third node, as further taught by Kim. The motivation to do so would be to have a secondary eNB, or a method for a secondary eNB to, receive a request from a master eNB of a current PDCP sequence number, transmit to the master eNB, in response to receiving the request, the current PDCP sequence number, receive from the master eNB a predicted second PDCP sequence number for use in determining PDCP sequence numbers for transmission by a plurality of target eNBs, use the second PDCP sequence number to determine a fourth PDCP sequence number, and perform forwarding of data from the master eNB to the plurality of target eNBs through the secondary eNB using PDCP sequence numbers based on the second and fourth PDCP sequence numbers, in order to prepare for, and prevent loss or out of sequence ordering of data during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the Target eNBs. Hsieh fails to disclose wherein the fourth PDCP sequence number for data transmission is through the first node. However, Park further teaches wherein the fourth PDCP sequence number for data transmission is through the first node (Fig 7 & [0112] discloses a source master gNB forwarding data to a target master eNB for transmission by the target master eNB.). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effectively filing date of the claimed invention to have the first node of claim 31, or the method of claim 21, wherein the second PDCP sequence number is used to determine a fourth PDCP sequence number for data transmission of the third node, as disclosed by Hsieh and Wang and Kim, wherein the fourth PDCP sequence number for data transmission is through the first node, as further taught by Park. The motivation to do so would be to have a secondary eNB, or a method for a secondary eNB to, receive a request from a master eNB of a current PDCP sequence number, transmit to the master eNB, in response to receiving the request, the current PDCP sequence number, receive from the master eNB a predicted second PDCP sequence number for use in determining PDCP sequence numbers for transmission by a plurality of target eNBs, use the second PDCP sequence number to determine a fourth PDCP sequence number, and perform forwarding of data from the master eNB to the plurality of target eNBs through the secondary eNB using PDCP sequence numbers based on the second and fourth PDCP sequence numbers, in order to prepare for, and prevent loss or out of sequence ordering of data during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the Target eNBs. Claims 19, 24, 29 & 34 are rejected under 35 U.S.C. 103 as being unpatentable over Hsieh et al. (US 11765627)(herein after “Hsieh) in view of Wang et al. (US 2012/0224525)(herein after “Wang”) and Kim et al. (US 2020/0068639)(herein after “Kim”), as applied to claims 16, 21, 26 & 31 respectively, and further in view of Veijalainen et al. (US 20230043492)(herein after “Veijalainen”). Regarding claims 19 & 29, Hsieh in view of Wang and Kim disclose the first node of claim 26 and the method of claim 16. Hsieh fails to disclose wherein the second information about the second PDCP sequence number is predicted based on an artificial intelligence (AI) model. However, Veijalainen further teaches wherein the second PDCP sequence number is predicted based on an artificial intelligence (AI) model ([0045]-[0046] discloses the use of machine learning (i.e. AI) to predict whether the use of PDCP-PDU duplication is beneficial, and if so on which leg, or harmful based on a reward outcome. Predicting a reward outcome information related to whether PDCP-PDU duplication is beneficial or not may be interpreted as predicting information about a PDCP sequence number (i.e. about whether a PDCP sequence number should be repeated or not).). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the first node of claim 26, or the method of claim 16, as disclosed by Hsieh and Wang and Kim, wherein the second information about the second PDCP sequence number is predicted based on an artificial intelligence (AI) model, as further taught by Veijalainen. The motivation to do so would have been to have a master eNB, or a method for a master eNB, request from a secondary eNB a current PDCP sequence number, receive from the secondary eNB the current PDCP sequence number, predict, based on an AI model, a second PDCP sequence number for use in determining PDCP sequence numbers for transmission by a plurality of target eNBs, send the second PDCP sequence number to the secondary eNB, and forward data to the plurality of target eNBs through the secondary eNB using the PDCP sequence numbers based on the second PDCP sequence number, in order to optimally prepare for, and optimally prevent loss of data during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the Target eNBs, by using AI for the prediction of the second PDCP sequence number. Regarding claims 24 & 34, Hsieh in view of Wang and Kim disclose the second node of claim 31 and the method of claim 21. Hsieh fails to disclose wherein the second information about the second PDCP sequence number is predicted based on an artificial intelligence (AI) model. However, Veijalainen further teaches wherein the second information about the second PDCP sequence number is predicted based on an artificial intelligence (AI) model ([0045]-[0046] discloses the use of machine learning (i.e. AI) to predict whether the use of PDCP-PDU duplication is beneficial, and if so on which leg, or harmful based on a reward outcome. Predicting a reward outcome information related to whether PDCP-PDU duplication is beneficial or not may be interpreted as predicting information about a PDCP sequence number (i.e. about whether a PDCP sequence number should be repeated or not).). Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the second node of claim 31, or the method of claim 21, as disclosed by Hsieh in view of Wang and Kim, wherein the second information about the second PDCP sequence number is predicted based on an artificial intelligence (AI) model, as further taught by Veijalainen. The motivation to do so would be to have a secondary eNB, or a method for a secondary eNB, receive a request from a master eNB of a current PDCP sequence number, transmit to the master eNB, in response to receiving the request, the current PDCP sequence number, receive from the master eNB a predicted second PDCP sequence number use in determining PDCP sequence numbers for transmission by a plurality of target eNBs, use the second PDCP number to determine a fourth PDCP number, and perform forwarding of data from the master eNB to the target eNB through the secondary eNB using PDCP numbers based on the second and fourth PDCP numbers, in order to optimally prepare for, and optimally prevent loss or out of sequence ordering of data during, a conditional handover of a UE, receiving data from the master eNB through the secondary eNB, to one of the target eNBs, by using AI for the prediction of the second PDCP sequence number. Conclusion The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Centenaro et al. (Marco Centenaro, Daniela Laselva, Jens Steiner, Klaus Pedersen & Preben Mogensen, “System-Level Study of Data Duplication Enhancement for 5G Downlink URLLC”, IEEE Access Journal, Volume 8, Jan 2, 2020) discloses a System-Level Study of Data Duplication Enhancement for 5G Downlink URLLC. 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 JAMES P SEYMOUR whose telephone number is (571)272-7654. The examiner can normally be reached M-F 8-5 EST. 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, Nishant Divecha can be reached at 571-270-3125. 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. /JAMES P SEYMOUR/Examiner, Art Unit 2419 /Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Read full office action

Prosecution Timeline

Jan 25, 2024
Application Filed
Mar 06, 2026
Non-Final Rejection mailed — §103
Jun 05, 2026
Response Filed
Jul 22, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12574448
Data Compression Engine
2y 9m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 1 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
38%
Grant Probability
31%
With Interview (-6.7%)
2y 5m (~0m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 8 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month