DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Final Office Action is in response to the Applicant Amendment Request/REMARKS correspondence filed 12/30/2025.
Claim 7, & 9-11 are pending and rejected.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/17/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s arguments with respect to claims 7, & 9-11 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 7, & 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 37.340 (Rel 15) Secondary Node procedures (EN-DC/MR-DC) V15.9.0 (Jul 2020) (hereinafter "3GPP-1") in further view of 3GPP TS 38.331 v.16.1.0 Rel 16 (2020-07) (hereinafter "3GPP-2").
Regarding claim 7, 3GPP-1 teaches a terminal comprising:
a receiver that receives a first message including a radio resource reconfiguration message regarding addition or change of a secondary node from a master node (10.5, 10.5.1-10.5.2 step 4/5 The MN sends the RRCConnection Reconfiguration message including a NR RRC configuration message (i.e. the new SCG radio resource configuration) to the UE including the new SCH radio resource configuration—discloses that the MN sends to the UE an RRC reconfiguration message, which contains the SCG/SN radio resource configuration); and
a transmitter that transmits a second message including a radio resource reconfiguration complete message regarding the addition or change of the secondary node to the master node (10.5, 10.5.1 step 4/5 & step 6, the UE applies the new configuration and sends the RRCConnectionReconfigurationComplete message, including the encoded NR RRC response message for the target SN, if needed; also the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN, if received from the UE—shows the UE transmits an RRCConnectionReconfigurationComplete back to MN, containing a response associated with the SN),
wherein—
the first message includes identification information on the secondary node as a candidate for addition or change, for each radio resource reconfiguration (10.5.1-10.5.2, the flows refer to “SgNB change required message which contsins target SN ID information and may include measurement results related to the target SN and SCG configuration; The SgNB Change Required messages include target SN ID, which is passed along in subsequent configuration messages to the UE—thus the first message (eventually forwarded by MN as RRCConnectionReconfiguration) carries candidate SN identification).
the second message includes: the identification information on the secondary node to which radio resource reconfiguration has been applied; and the radio resource reconfiguration complete message corresponding to the identification information (10.5, 10.5.1 steps 1/2-step 6 if the RRC connection reconfiguration procedure was successful, the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN, if received from the UE; the MN sends the RRCConnectionReconfiguration message including a NR RRC configuration message…which is tied to a particular target SN/SCG—the encoded NR RRC response message for the target SN is the reconfiguration complete response associated with that SN, and the target SN identity is conveyed in the MN/SN signaling; thus the second message includes both identification of the SN and the reconfiguration complete message tied to that SN).
But 3GPP-1 fails to teach the structure of RRC messages.
However, 3GPP-2 teaches the structure of RRC messages (TS 38.331, 5.3.5, 5.3.13, 6.3.2.2 pg. 365-366 in Section CellGroupConfig[Wingdings font/0xE0] SN or SCG configuration that has been prepared by the SN and forwarded transparently by the MN[Wingdings font/0xE0]CellGroupConfig contains spCellConfig and cellToAddModList which in turn include Physical Cell ID (PCI) and Serving cell ID for each configured cell; furthermore definitions of RRCConnectionReconfiguration/RRCConnectionReconfigurationComplete, and that an RRCConnectionReconfigurationComplete may carry encoded response content; confirms that the RRC message definitions support embedding, encoding, and relaying of response message (for SN) inside the reconfiguration complete message structure).
A POSITA would have been motivated to combine 3GPP-1 which describes the MR-DC/EN-DC control plane procedures for addition and change of secondary nodes, with 3GPP-2 which specifies the detailed structure and semantics of the NR RRC messages (e.g. RRCConnectionReconfiguration, RRCConnectionReconfigurationComplete). 3GPP-1 defines when and why the MN and SN exchange certain configuration messages, including the call flows for SN addition/change and the relay of an encoded NR RRC response message. 3GPP-2 defines how the RRC messages are structured, encoded and decoded. A POSITA would naturally read both specifications together because 3GPP-1 explicitly refers to the RRC messages defined in 3GPP-2. Combining them merely provides the full picture of procedures (3GPP-1) and message formats (3GPP-2). By combining 3GPP-1 and 3GPP-2 a POSITA obtains a complete picture of both the procedure and the exact message structure necessary to execute it, and the interoperability between nodes.
Regarding claim 9, 3GPP-1 teaches a radio communication method for a terminal, comprising:
a step of receiving a first message including a radio resource reconfiguration message regarding addition or change of a secondary node from a master node (10.5, 10.5.1-10.5.2 step 4/5 The MN sends the RRCConnection Reconfiguration message including a NR RRC configuration message (i.e. the new SCG radio resource configuration) to the UE including the new SCH radio resource configuration—discloses that the MN sends to the UE an RRC reconfiguration message, which contains the SCG/SN radio resource configuration); and
a step of transmitting a second message including a radio resource reconfiguration complete message regarding the addition or change of the secondary node to the master node (10.5, 10.5.1 step 4/5 & step 6, the UE applies the new configuration and sends the RRCConnectionReconfigurationComplete message, including the encoded NR RRC response message for the target SN, if needed; also the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN, if received from the UE—shows the UE transmits an RRCConnectionReconfigurationComplete back to MN, containing a response associated with the SN),
wherein—
the first message includes identification information on the secondary node as a candidate for addition or change, for each radio resource reconfiguration (10.5.1-10.5.2, the flows refer to “SgNB change required message which contsins target SN ID information and may include measurement results related to the target SN and SCG configuration; The SgNB Change Required messages include target SN ID, which is passed along in subsequent configuration messages to the UE—thus the first message (eventually forwarded by MN as RRCConnectionReconfiguration) carries candidate SN identification).
the second message includes: the identification information on the secondary node to which radio resource reconfiguration has been applied; and the radio resource reconfiguration complete message corresponding to the identification information (10.5, 10.5.1 steps 1/2-step 6 if the RRC connection reconfiguration procedure was successful, the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN, if received from the UE; the MN sends the RRCConnectionReconfiguration message including a NR RRC configuration message…which is tied to a particular target SN/SCG—the encoded NR RRC response message for the target SN is the reconfiguration complete response associated with that SN, and the target SN identity is conveyed in the MN/SN signaling; thus the second message includes both identification of the SN and the reconfiguration complete message tied to that SN).
But 3GPP-1 fails to teach the structure of RRC messages.
However, 3GPP-2 teaches the structure of RRC messages (TS 38.331, 5.3.5, 5.3.13, 6.3.2.2, definitions of RRCConnectionReconfiguration/RRCConnectionReconfigurationComplete, and that an RRCConnectionReconfigurationComplete may carry encoded response content; confirms that the RRC message definitions support embedding, encoding, and relaying of response message (for SN) inside the reconfiguration complete message structure).
A POSITA would have been motivated to combine 3GPP-1 which describes the MR-DC/EN-DC control plane procedures for addition and change of secondary nodes, with 3GPP-2 which specifies the detailed structure and semantics of the NR RRC messages (e.g. RRCConnectionReconfiguration, RRCConnectionReconfigurationComplete). 3GPP-1 defines when and why the MN and SN exchange certain configuration messages, including the call flows for SN addition/change and the relay of an encoded NR RRC response message. 3GPP-2 defines how the RRC messages are structured, encoded and decoded. A POSITA would naturally read both specifications together because 3GPP-1 explicitly refers to the RRC messages defined in 3GPP-2. Combining them merely provides the full picture of procedures (3GPP-1) and message formats (3GPP-2). By combining 3GPP-1 and 3GPP-2 a POSITA obtains a complete picture of both the procedure and the exact message structure necessary to execute it, and the interoperability between nodes.
Regarding claim 10, 3GPP-1 teaches a radio base station, comprising:
a transmitter that transmits a first message including a radio resource reconfiguration message regarding addition or change of a secondary node to a terminal (10.5, 10.5.1-10.5.2 step 4/5 The MN sends the RRCConnection Reconfiguration message including a NR RRC configuration message (i.e. the new SCG radio resource configuration) to the UE including the new SCH radio resource configuration—discloses that the MN sends to the UE an RRC reconfiguration message, which contains the SCG/SN radio resource configuration); and
a receiver that receives a second message including a radio resource reconfiguration complete message regarding the addition or change of the secondary node from the terminal (10.5, 10.5.1 step 4/5 & step 6, the UE applies the new configuration and sends the RRCConnectionReconfigurationComplete message, including the encoded NR RRC response message for the target SN, if needed; also the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN, if received from the UE—shows the UE transmits an RRCConnectionReconfigurationComplete back to MN, containing a response associated with the SN),
wherein—
the first message includes identification information on the secondary node as a candidate for addition or change, for each radio resource reconfiguration (10.5.1-10.5.2, the flows refer to “SgNB change required message which contsins target SN ID information and may include measurement results related to the target SN and SCG configuration; The SgNB Change Required messages include target SN ID, which is passed along in subsequent configuration messages to the UE—thus the first message (eventually forwarded by MN as RRCConnectionReconfiguration) carries candidate SN identification).
the second message includes: the identification information on the secondary node to which the terminal has applied radio resource reconfiguration; and the radio resource reconfiguration complete message corresponding to the identification information (10.5, 10.5.1 steps 1/2-step 6 if the RRC connection reconfiguration procedure was successful, the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN, if received from the UE; the MN sends the RRCConnectionReconfiguration message including a NR RRC configuration message…which is tied to a particular target SN/SCG—the encoded NR RRC response message for the target SN is the reconfiguration complete response associated with that SN, and the target SN identity is conveyed in the MN/SN signaling; thus the second message includes both identification of the SN and the reconfiguration complete message tied to that SN).
But 3GPP-1 fails to teach the structure of RRC messages.
However, 3GPP-2 teaches the structure of RRC messages (TS 38.331, 5.3.5, 5.3.13, 6.3.2.2, definitions of RRCConnectionReconfiguration/RRCConnectionReconfigurationComplete, and that an RRCConnectionReconfigurationComplete may carry encoded response content; confirms that the RRC message definitions support embedding, encoding, and relaying of response message (for SN) inside the reconfiguration complete message structure).
A POSITA would have been motivated to combine 3GPP-1 which describes the MR-DC/EN-DC control plane procedures for addition and change of secondary nodes, with 3GPP-2 which specifies the detailed structure and semantics of the NR RRC messages (e.g. RRCConnectionReconfiguration, RRCConnectionReconfigurationComplete). 3GPP-1 defines when and why the MN and SN exchange certain configuration messages, including the call flows for SN addition/change and the relay of an encoded NR RRC response message. 3GPP-2 defines how the RRC messages are structured, encoded and decoded. A POSITA would naturally read both specifications together because 3GPP-1 explicitly refers to the RRC messages defined in 3GPP-2. Combining them merely provides the full picture of procedures (3GPP-1) and message formats (3GPP-2). By combining 3GPP-1 and 3GPP-2 a POSITA obtains a complete picture of both the procedure and the exact message structure necessary to execute it, and the interoperability between nodes.
Regarding claim 11, 3GPP-1 teaches a radio communication system including a radio base station and a terminal, wherein the radio base station comprises:
a transmitter that transmits a first message including a radio resource reconfiguration message regarding addition or change of a secondary node to the terminal (10.5, 10.5.1-10.5.2 step 4/5 The MN sends the RRCConnection Reconfiguration message including a NR RRC configuration message (i.e. the new SCG radio resource configuration) to the UE including the new SCH radio resource configuration—discloses that the MN sends to the UE an RRC reconfiguration message, which contains the SCG/SN radio resource configuration); and
a receiver that receives a second message including a radio resource reconfiguration complete message regarding the addition or change of the secondary node from the terminal (10.5, 10.5.1 step 4/5 & step 6, the UE applies the new configuration and sends the RRCConnectionReconfigurationComplete message, including the encoded NR RRC response message for the target SN, if needed; also the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN, if received from the UE—shows the UE transmits an RRCConnectionReconfigurationComplete back to MN, containing a response associated with the SN),
and the terminal comprises:
a receiver that receives the first message from the radio base station (10.5, 10.5.1 step 4/5 & step 6, the UE applies the new configuration and sends the RRCConnectionReconfigurationComplete message, including the encoded NR RRC response message for the target SN, if needed; also the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN, if received from the UE—shows the UE transmits an RRCConnectionReconfigurationComplete back to MN, containing a response associated with the SN); and
a transmitter that transmits the second message to the radio base station (10.5, 10.5.1-10.5.2 step 4/5 The MN sends the RRCConnection Reconfiguration message including a NR RRC configuration message (i.e. the new SCG radio resource configuration) to the UE including the new SCH radio resource configuration—discloses that the MN sends to the UE an RRC reconfiguration message, which contains the SCG/SN radio resource configuration),
wherein
the first message includes identification information on the secondary node as a candidate for addition or change, for each radio resource reconfiguration (10.5.1-10.5.2, the flows refer to “SgNB change required message which contsins target SN ID information and may include measurement results related to the target SN and SCG configuration; The SgNB Change Required messages include target SN ID, which is passed along in subsequent configuration messages to the UE—thus the first message (eventually forwarded by MN as RRCConnectionReconfiguration) carries candidate SN identification).
the second message includes: the identification information on the secondary node to which the terminal has applied radio resource reconfiguration; and the radio resource reconfiguration complete message corresponding to the identification information (10.5, 10.5.1 steps 1/2-step 6 if the RRC connection reconfiguration procedure was successful, the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN, if received from the UE; the MN sends the RRCConnectionReconfiguration message including a NR RRC configuration message…which is tied to a particular target SN/SCG—the encoded NR RRC response message for the target SN is the reconfiguration complete response associated with that SN, and the target SN identity is conveyed in the MN/SN signaling; thus the second message includes both identification of the SN and the reconfiguration complete message tied to that SN).
But 3GPP-1 fails to teach the structure of RRC messages.
However, 3GPP-2 teaches the structure of RRC messages (TS 38.331, 5.3.5, 5.3.13, 6.3.2.2, definitions of RRCConnectionReconfiguration/RRCConnectionReconfigurationComplete, and that an RRCConnectionReconfigurationComplete may carry encoded response content; confirms that the RRC message definitions support embedding, encoding, and relaying of response message (for SN) inside the reconfiguration complete message structure).
A POSITA would have been motivated to combine 3GPP-1 which describes the MR-DC/EN-DC control plane procedures for addition and change of secondary nodes, with 3GPP-2 which specifies the detailed structure and semantics of the NR RRC messages (e.g. RRCConnectionReconfiguration, RRCConnectionReconfigurationComplete). 3GPP-1 defines when and why the MN and SN exchange certain configuration messages, including the call flows for SN addition/change and the relay of an encoded NR RRC response message. 3GPP-2 defines how the RRC messages are structured, encoded and decoded. A POSITA would naturally read both specifications together because 3GPP-1 explicitly refers to the RRC messages defined in 3GPP-2. Combining them merely provides the full picture of procedures (3GPP-1) and message formats (3GPP-2). By combining 3GPP-1 and 3GPP-2 a POSITA obtains a complete picture of both the procedure and the exact message structure necessary to execute it, and the interoperability between nodes.
Conclusion
THIS ACTION IS MADE FINAL. 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 MICHAEL WILLIAM ABBATINE whose telephone number is (571)272-0192. The examiner can normally be reached Monday-Friday 0830-1700 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.
/MICHAEL WILLIAM ABBATINE JR./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419