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 .
Claims 1-3, 12, and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Google LLC, WO 2021/206929 A1 (Google), in view of 3rd Generation Partnership Project (3GPP) , NR; Radio Resource Control Protocol Specification , 3GPP TS 38.331 V17.0.0, Release 17 (TS 38.331”), dated March 2022 and publicly available through the 3GPP archive on April 19, 2022.
Regarding claim 1, Claim 1 recites a method for configuring reference signal measurements at a user equipment (UE), the method implemented in a central unit (CU) of a distributed base station that also includes a distributed unit (DU), the method comprising: transmitting, to the DU, a first message including a request to configure a measurement gap for a UE; receiving, from the DU, a second message including (i) a measurement gap configuration and (ii) a gap identifier (ID) for the measurement gap; providing the measurement gap configuration to the UE, for use with the reference signal measurements; receiving, from the DU, a third message including gap release information for releasing the measurement gap configuration, the gap release information including the gap ID; and transmitting, to the UE, the gap release information, to release the measurement gap configuration.
Google discloses "a method for configuring reference signal measurements at a user equipment (UE), the method implemented in a central unit (CU) of a distributed base station that also includes a distributed unit (DU)." Specifically, ¶0317 introduces the reciprocal measurement-gap-management method; ¶0329 identifies the first network node performing that method as a CU; and ¶0338 identifies the second network node as a DU. Paragraph 0307 identifies reference-signal measurements, and ¶¶0343-0344 apply the measurement-gap operation to UE positioning/reference-signal measurement. Thus, the cited passages map the claimed CU, DU, UE, and reference-signal-measurement environment.
Google discloses "transmitting, to the DU, a first message including a request to configure a measurement gap for a UE." Specifically, ¶0321 states that the first network node sends the second network node an indication requesting generation of measurement-gap information; ¶0329 identifies the sender as the CU; ¶0338 identifies the recipient as the DU; and ¶¶0333-0334 explain that the request concerns generation of a UE measurement-gap configuration. Paragraph 0300 independently confirms that the signaling may request generation of the configuration. These passages therefore map the CU-to-DU first request message.
Google discloses "receiving, from the DU, a second message including (i) a measurement gap configuration." Specifically, ¶¶0295-0297 state that a network node determines/generates a UE measurement-gap configuration and transmits a message containing that configuration; ¶¶0311-0312 describe receipt of the corresponding information; and ¶0315 identifies the generating/transmitting node as the DU and the receiving node as the CU. These passages map the DU-to-CU second message and its claimed content.
Google discloses "providing the measurement gap configuration to the UE, for use with the reference signal measurements." Specifically, ¶0351 states that the UE is configured with measurement-gap information; ¶¶0354-0355 explain that the CU provides the configuration to the UE through the DU and that the UE performs measurements according to it; and ¶0307 and ¶¶0343-0344 identify the relevant measurements as reference-signal/positioning measurements. The cited passages therefore map both delivery and claimed use.
Google discloses "receiving, from the DU, a third message including gap release information for releasing the measurement gap configuration." Specifically, ¶¶0294-0297 describe DU-side determination and transmission of measurement-gap information; ¶0298 states that the information may indicate release of a previous measurement-gap configuration; and ¶0315 identifies the transmitting node as the DU and the receiving node as the CU. Together, these passages map a DU-to-CU message carrying the claimed release instruction.
Google discloses "transmitting, to the UE, the gap release information, to release the measurement gap configuration." Specifically, ¶0298 supplies the release instruction by stating that the measurement-gap information may indicate release of a previous configuration, while ¶¶0354-0355 supply the delivery path by stating that the CU sends measurement-gap configuration information to the UE through the DU for execution by the UE. Read together, those passages map transmission of the release information to the UE and the resulting release function.
Google does not expressly disclose "(ii) a gap identifier (ID) for the measurement gap," "the gap release information including the gap ID," or that the same identifier accompanies both the configuration and the release information.
3GPP TS 38.331 V17.0.0 discloses the limitations not expressly disclosed by Google. Section 6.3.2, MeasGapConfig, pages 587-590, states that MeasGapConfig specifies the measurement-gap configuration and controls setup and release; defines GapConfig as including measGapId-r17; defines gapFR1ToReleaseList-r17, gapFR2ToReleaseList-r17, and gapUEToReleaseList-r17 as lists of MeasGapId-r17 values; and states that MeasGapId identifies a per-UE or per-frequency-range measurement-gap configuration. Section 5.5.2, pages 170-172, directs the UE, for each measGapId received in the applicable release list, to release the measurement-gap configuration associated with that measGapId. Thus, TS 38.331 maps a gap ID in the configuration and the same identifier in release information selecting the particular gap for release.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to modify Google's CU/DU measurement-gap configuration and release signaling to use the identifier-based MeasGapConfig structure of TS 38.331 because an explicit identifier predictably identifies the particular one of multiple gap configurations to be released, prevents ambiguity when concurrent gaps are supported, and applies the standardized identifier-based release mechanism according to its established function.
Regarding claim 12, Claim 12 recites a method for configuring reference signal measurements at a user equipment (UE), the method implemented in a distributed unit (DU) of a distributed base station that also includes a central unit (CU), the method comprising: receiving, from the CU, a first message including a request to configure a measurement gap for a UE; transmitting, to the CU, a second message including (i) a measurement gap configuration and (ii) a gap identifier (ID) for the measurement gap; and transmitting, to the CU, a third message including gap release information for releasing the measurement gap configuration, the gap release information including the gap ID.
Google discloses "a method for configuring reference signal measurements at a user equipment (UE), the method implemented in a distributed unit (DU) of a distributed base station that also includes a central unit (CU)." Specifically, paragraphs 0294-0297 introduce the measurement-gap-management method, paragraph 0315 identifies the first network node performing that method as a DU and the second network node as a CU, paragraph 0307 identifies reference-signal measurements, and paragraphs 0343-0344 apply the measurement-gap operation to UE positioning/reference-signal measurement.
Google discloses "receiving, from the CU, a first message including a request to configure a measurement gap for a UE." Specifically, paragraph 0300 characterizes the incoming signaling as a request to generate a UE measurement-gap configuration; paragraphs 0294-0297 describe receipt and processing of that request; and paragraph 0315 identifies the receiving/configuring node as the DU and the requesting node as the CU.
Google discloses "transmitting, to the CU, a second message including (i) a measurement gap configuration." Specifically, paragraphs 0295-0297 state that the network node determines/generates a UE measurement-gap configuration and transmits a message containing that configuration, and paragraph 0315 identifies the transmitting node as the DU and the receiving node as the CU.
Google discloses "transmitting, to the CU, a third message including gap release information for releasing the measurement gap configuration." Specifically, paragraphs 0294-0297 describe DU-side determination and transmission of measurement-gap information, paragraph 0298 states that the information may indicate release of a previous measurement-gap configuration, and paragraph 0315 identifies the transmitting node as the DU and the receiving node as the CU.
Google does not expressly disclose "(ii) a gap identifier (ID) for the measurement gap," "the gap release information including the gap ID," or that the same identifier accompanies both the configuration and the release information.
3GPP TS 38.331 V17.0.0 discloses the limitations not expressly disclosed by Google. Section 6.3.2, MeasGapConfig, pages 587-590, places measGapId-r17 in GapConfig, defines the applicable gap-to-release lists as lists of MeasGapId-r17 values, and states that MeasGapId identifies a measurement-gap configuration. Section 5.5.2, pages 170-172, directs release of the configuration associated with each received measGapId. These provisions map the gap ID included with the configuration and the same gap ID included in the release information.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to modify Google's DU-to-CU measurement-gap configuration and release signaling to use the identifier-based MeasGapConfig structure of TS 38.331 because the identifier predictably distinguishes the applicable configuration and permits the corresponding release instruction to select that same configuration.
Regarding claim 15, Claim 15 recites a central unit (CU) of a distributed base station that also includes a distributed unit (DU), the CU comprising processing hardware and configured to: transmit, to the DU, a first message including a request to configure a measurement gap for a UE; receive, from the DU, a second message including (i) a measurement gap configuration and (ii) a gap identifier (ID) for the measurement gap; provide the measurement gap configuration to the UE, for use with the reference signal measurements; receive, from the DU, a third message including gap release information for releasing the measurement gap configuration, the gap release information including the gap ID; and transmit, to the UE, the gap release information, to release the measurement gap configuration.
Google discloses "a central unit (CU) of a distributed base station that also includes a distributed unit (DU), the CU comprising processing hardware and configured to" perform the recited functions. Paragraphs 0317, 0329, and 0338 identify the CU and DU roles, and paragraph 0345 discloses network-node processing circuitry configured to perform the measurement-gap method.
Google discloses "transmitting, to the DU, a first message including a request to configure a measurement gap for a UE." Specifically, ¶0321 states that the first network node sends the second network node an indication requesting generation of measurement-gap information; ¶0329 identifies the sender as the CU; ¶0338 identifies the recipient as the DU; and ¶¶0333-0334 explain that the request concerns generation of a UE measurement-gap configuration. Paragraph 0300 independently confirms that the signaling may request generation of the configuration. These passages therefore map the CU-to-DU first request message.
Google discloses "receiving, from the DU, a second message including (i) a measurement gap configuration." Specifically, ¶¶0295-0297 state that a network node determines/generates a UE measurement-gap configuration and transmits a message containing that configuration; ¶¶0311-0312 describe receipt of the corresponding information; and ¶0315 identifies the generating/transmitting node as the DU and the receiving node as the CU. These passages map the DU-to-CU second message and its claimed content.
Google discloses "providing the measurement gap configuration to the UE, for use with the reference signal measurements." Specifically, ¶0351 states that the UE is configured with measurement-gap information; ¶¶0354-0355 explain that the CU provides the configuration to the UE through the DU and that the UE performs measurements according to it; and ¶0307 and ¶¶0343-0344 identify the relevant measurements as reference-signal/positioning measurements. The cited passages therefore map both delivery and claimed use.
Google discloses "receiving, from the DU, a third message including gap release information for releasing the measurement gap configuration." Specifically, ¶¶0294-0297 describe DU-side determination and transmission of measurement-gap information; ¶0298 states that the information may indicate release of a previous measurement-gap configuration; and ¶0315 identifies the transmitting node as the DU and the receiving node as the CU. Together, these passages map a DU-to-CU message carrying the claimed release instruction.
Google discloses "transmitting, to the UE, the gap release information, to release the measurement gap configuration." Specifically, ¶0298 supplies the release instruction by stating that the measurement-gap information may indicate release of a previous configuration, while ¶¶0354-0355 supply the delivery path by stating that the CU sends measurement-gap configuration information to the UE through the DU for execution by the UE. Read together, those passages map transmission of the release information to the UE and the resulting release function.
Google does not expressly disclose "(ii) a gap identifier (ID) for the measurement gap," "the gap release information including the gap ID," or that the same identifier accompanies both the configuration and the release information.
3GPP TS 38.331 V17.0.0 discloses the limitations not expressly disclosed by Google. Section 6.3.2, MeasGapConfig, pages 587-590, places measGapId-r17 in GapConfig, defines gap-to-release lists containing MeasGapId-r17 values, and states that MeasGapId identifies a measurement-gap configuration. Section 5.5.2, pages 170-172, directs release of the configuration associated with each received measGapId. These provisions map a gap ID in the configuration and the same identifier in the release information.
Google discloses the claimed CU processing hardware. Specifically, paragraph 0345 describes the network node as including processing circuitry configured to perform the disclosed measurement-gap method. This citation maps the structural processing-hardware limitation and its claimed functional configuration.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to configure Google's CU processing hardware to use the identifier-based MeasGapConfig structure of TS 38.331 because the standardized structure predictably identifies the particular configuration to be released and applies that structure according to its established function.
Regarding claim 2, Claim 2 recites, wherein the measurement gap configuration includes: a preconfiguration indicator to indicate that the gap configuration is a preconfigured gap configuration.
The combination discloses every limitation of claim 1 as set forth above.
3GPP TS 38.331 V17.0.0 discloses the claimed preconfiguration indicator. Section 6.3.2, MeasGapConfig, pages 587-589, defines preConfigInd-r17 in GapConfig. Section 5.5.2, page 172, states that when preConfigInd-r17 is present, the UE determines whether the corresponding measurement gap is activated; otherwise, the UE considers the gap activated. These provisions map both the indicator and its indication that the configuration is preconfigured.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to include the preConfigInd-r17 indicator of TS 38.331 in Google's measurement-gap configuration to distinguish a preconfigured gap from an immediately active gap and thereby enable the standardized preconfigured-gap procedure.
Regarding claim 3, Claim 3 recites wherein the measurement gap configuration includes: a MeasGapConfig information element (IE).
The combination discloses every limitation of claim 1 as set forth above.
3GPP TS 38.331 V17.0.0 discloses the claimed MeasGapConfig information element. Section 6.3.2, pages 587-590, expressly defines MeasGapConfig and states that the IE specifies the measurement-gap configuration and controls setup and release of measurement gaps.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to carry Google's measurement-gap configuration in the standardized MeasGapConfig IE of TS 38.331 because that IE was designed for the same setup-and-release purpose and predictably provides standards-compatible signaling to the UE.
Regarding claim 14, Claim 14 recites wherein: the measurement gap configuration includes a gap identifier (ID).
The combination discloses every limitation of claim 12 as set forth above.
3GPP TS 38.331 V17.0.0 discloses that the measurement-gap configuration includes a gap ID. Section 6.3.2, pages 587-590, places measGapId-r17 inside GapConfig and states that MeasGapId identifies a per-UE or per-frequency-range measurement-gap configuration.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to include the measGapId of TS 38.331 in Google's DU-generated measurement-gap configuration to distinguish the applicable gap when multiple configurations are maintained.
Regarding claim 16, Claim 16 recites, wherein the measurement gap configuration includes: a preconfiguration indicator to indicate that the gap configuration is a preconfigured gap configuration.
The combination discloses every limitation of claim 15 as set forth above.
3GPP TS 38.331 V17.0.0 discloses the claimed preconfiguration indicator. Section 6.3.2, pages 587-589, defines preConfigInd-r17 in GapConfig, and section 5.5.2, page 172, explains that its presence controls whether the corresponding gap is treated as preconfigured rather than immediately active.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to include the known preConfigInd-r17 indicator for the same reasons stated for claim 2.
Regarding claim 17, Claim 17 recites wherein the measurement gap configuration includes: a MeasGapConfig information element (IE).
The combination discloses every limitation of claim 15 as set forth above.
3GPP TS 38.331 V17.0.0 discloses the claimed MeasGapConfig information element. Section 6.3.2, pages 587-590, expressly defines MeasGapConfig and states that it specifies the measurement-gap configuration and controls setup and release.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to use the standardized MeasGapConfig IE for the same reasons stated for claim 3.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Google in view of 3GPP TS 38.331 V17.0.0, and further in view of 3rd Generation Partnership Project (3GPP) , F1 Application Protocol (F1AP), 3GPP TS 38.473 V17.0.0, Release 17 (TS 38.473), dated March 2022 and publicly available through the 3GPP archive on April 6, 2022.
Regarding claim 4, Claim 4 recites wherein: the first message includes a Measurement Preconfiguration Required message. Google and TS 38.331 disclose every limitation of claim 1 as set forth above. 3GPP TS 38.473 V17.0.0 discloses the claimed first-message type. Section 8.13.18 identifies Measurement Preconfiguration as an F1AP procedure exchanged between the gNB-CU and gNB-DU, and section 9.2.12.30 defines the MEASUREMENT PRECONFIGURATION REQUIRED message as a gNB-CU-to-gNB-DU message requesting configuration of a measurement gap or PRS processing window for the UE.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to implement the first CU/DU message using the standardized MEASUREMENT PRECONFIGURATION REQUIRED message because TS 38.473 designates that message for measurement-preconfiguration signaling across the F1 interface, yielding interoperable CU/DU operation with no change in the underlying request/confirmation function.
Regarding claim 18, Claim 18 recites, wherein: the first message includes a Measurement Preconfiguration Required message. Google and TS 38.331 disclose every limitation of claim 15 as set forth above. 3GPP TS 38.473 V17.0.0 discloses the claimed first-message type. Section 8.13.18 identifies Measurement Preconfiguration as an F1AP procedure exchanged between the gNB-CU and gNB-DU, and section 9.2.12.30 defines the MEASUREMENT PRECONFIGURATION REQUIRED message as a gNB-CU-to-gNB-DU message requesting configuration of a measurement gap or PRS processing window for the UE.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to implement the first CU/DU message using the standardized MEASUREMENT PRECONFIGURATION REQUIRED message because TS 38.473 designates that message for measurement-preconfiguration signaling across the F1 interface, yielding interoperable CU/DU operation with no change in the underlying request/confirmation function.
Regarding claim 11, Claim 11 recites, wherein: transmitting the first message includes transmitting one of a CU-to-DU message or an F1 Application Protocol (F1AP) message.
Google and TS 38.331 disclose every limitation of claim 1 as set forth above.
Google maps the claimed CU/DU endpoints. Specifically, ¶0315 identifies the DU as the network node that provides measurement-gap information to the CU, while ¶¶0329 and 0338 identify the reciprocal first node as the CU and second node as the DU. The citations therefore place the relevant messages on the distributed-base-station CU/DU interface.
3GPP TS 38.473 maps the claimed CU-to-DU/F1AP message alternative. Specifically, §1 defines the specification as the F1 radio-network-layer signaling protocol interconnecting a gNB-CU and gNB-DU; §8.13.18 defines Measurement Preconfiguration as an F1AP procedure; and §§9.2.12.30-9.2.12.33 define the individual F1AP messages. Thus, these sections show that the claimed first CU-to-DU message is implemented as an F1AP message.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to transmit Google's CU-to-DU request as an F1AP message because F1AP is the standardized protocol for the disclosed CU/DU interface and using it predictably supplies interoperability.
Claims 6-10, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Google in view of 3GPP TS 38.331 V17.0.0, and further in view of 3rd Generation Partnership Project (3GPP) , NR Positioning Protocol A (NRPPa) , 3GPP TS 38.455V17.0.0, Release 17 (TS 38.455), dated March 2022 and publicly available through the 3GPP archive on April 6, 2022 and 3rd Generation Partnership Project (3GPP) , Stage 2 Functional Specification of User Equipment (UE), Positioning in NG-RAN, 3GPP TS 38.305 V17.0.0, Release 17 (TS 38.305), dated March 2022 and publicly available through the 3GPP archive on April 14, 2022.
Regarding claim 6, Claim 6 recites, further comprising: receiving, from a Location Management Function (LMF) and prior to the transmitting of the first message, a Measurement Preconfiguration Required message.
Google and TS 38.331 disclose every limitation of claim 1 as set forth above.
3GPP TS 38.455 V17.0.0 discloses the LMF initiating Measurement Preconfiguration by sending a MEASUREMENT PRECONFIGURATION REQUIRED message to the NG-RAN node before the node configures the measurement gap and returns confirmation. See sections 8.2.12.2 and 9.1.1.24, pages 24 and 41-42.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention for Google's CU to receive the standardized Measurement Preconfiguration Required message from the LMF before requesting the DU to configure the gap, because the LMF message is the known trigger for the same positioning-measurement preconfiguration procedure and the DU performs the gap configuration in the split base station.
Regarding claim 7, Claim 7 recites wherein: the Measurement Preconfiguration Required message includes a Transmission-Reception Point (TRP) positioning reference signal (PRS) information; and the transmitting of the first message to the DU includes transmitting the TRP PRS information to the DU.
The combination discloses every limitation of claim 6 as set forth above.
3GPP TS 38.455 V17.0.0, section 9.1.1.24, pages 41-42, includes the TRP PRS Information List in MEASUREMENT PRECONFIGURATION REQUIRED. 3GPP TS 38.305 V17.0.0, section 7.7.2, pages 47-48, explains that the LMF provides PRS information of neighboring TRPs to the serving gNB and requests preconfiguration of a measurement gap for the positioning measurements.
Google maps transmission of that information from the CU side to the DU for use in generating the gap. Specifically, ¶¶0320-0322 describe the first node's request and accompanying measurement-related information; ¶0329 identifies that first node as the CU; and ¶0338 identifies the receiving/configuring node as the DU. Accordingly, the cited paragraphs are applied to the claimed CU-to-DU transmission of TRP PRS information, not merely to measurement gaps generally.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to include the LMF-provided TRP PRS information in the CU-to-DU request so that the DU has the target-signal information needed to generate a gap suited to the requested PRS measurements, thereby applying known positioning data to its ordinary configuration function.
Regarding claim 8, Claim 8 recites further comprising, subsequently to the providing of the measurement gap configuration to the UE: transmitting, to the DU, a request to activate the measurement gap configuration.
Google and TS 38.331 disclose every limitation of claim 1 as set forth above.
3GPP TS 38.455 V17.0.0 defines Measurement Activation after Measurement Preconfiguration in sections 8.2.12-8.2.13, pages 24-25. 3GPP TS 38.305 V17.0.0, section 7.7.2, pages 47-48, describes activation of a preconfigured measurement gap after the gap is provided to the UE.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention for the CU, after providing the preconfigured gap to the UE, to request the DU to activate it, because the standards expressly separate preconfiguration from later activation and the DU controls lower-layer scheduling of the measurement gap.
Regarding claim 9, Claim 9 recites, wherein: the request includes a positioning reference signal (PRS) measurement information.
The combination discloses every limitation of claim 8 as set forth above.
3GPP TS 38.455 V17.0.0, section 9.1.1.27, page 42, includes a PRS Measurement Info List in MEASUREMENT ACTIVATION. 3GPP TS 38.305 V17.0.0, section 7.7.2, pages 47-48, applies activation to a preconfigured measurement gap for PRS positioning measurements.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to include PRS measurement information in the activation request to identify the positioning measurement for which the already-preconfigured gap is being activated, enabling the DU to activate the proper resource.
Regarding claim 10, Claim 10 recites wherein: the request to activate the measurement gap configuration is a Measurement Activation message.
The combination discloses every limitation of claim 8 as set forth above.
3GPP TS 38.455 V17.0.0 expressly names the post-preconfiguration request the MEASUREMENT ACTIVATION message in section 8.2.13, pages 24-25, and section 9.1.1.27, page 42.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to use the standardized Measurement Activation message for the claimed activation request because that message was defined to perform the identical activation function.
Regarding claim 13, Claim 13 recites wherein: the request to configure the measurement gap includes a Transmission-Reception Point (TRP) positioning reference signal (PRS) information, the method further comprising: generating the measurement gap configuration using the TRP PRS information.
Google and TS 38.331 disclose every limitation of claim 12 as set forth above.
Google maps the DU's generation step. Specifically, ¶¶0294-0297 state that a network node receives the request/information, determines the UE measurement-gap configuration, and returns it; ¶0300 characterizes the incoming signaling as a request to generate the configuration; and ¶0315 identifies the generating node as the DU. Thus, those paragraphs are applied to "generating the measurement gap configuration" at the DU using received request information.
3GPP TS 38.305 V17.0.0, section 7.7.2, pages 47-48, maps the claimed use of TRP PRS information by describing the LMF providing neighboring-TRP PRS information to the serving gNB for measurement-gap preconfiguration and the serving gNB configuring the corresponding gap for the UE.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to include TRP PRS information in Google's CU request and to use that information at the DU when generating the measurement-gap configuration, because the requested PRS occasions determine when the UE must tune away and therefore predictably determine a suitable gap configuration.
Regarding claim 20, Claim 20 recites further configured to: receive, from a Location Management Function (LMF) and prior to the transmitting of the first message, a Measurement Preconfiguration Required message.
Google and TS 38.331 disclose every limitation of claim 15 as set forth above.
3GPP TS 38.455 V17.0.0 discloses the LMF sending MEASUREMENT PRECONFIGURATION REQUIRED to the NG-RAN node before configuration of the gap. See sections 8.2.12.2 and 9.1.1.24, pages 24 and 41-42.
Thus, it would have been obvious to one of ordinary skill in the art prior to the time of the invention to configure Google's CU processing hardware to receive the LMF's standardized prerequisite message before sending its request to the DU, because the LMF message is the recognized trigger for the same procedure and the CU terminates the positioning signaling toward the LMF.
Allowable Subject Matter
Claims 5 and 9 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANGEL T BROCKMAN whose telephone number is (571)270-5664. The examiner can normally be reached Monday-Thursday 6:00 AM-4:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Charles Jiang can be reached at 571-270-7191. 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.
/ANGEL T BROCKMAN/Examiner, Art Unit 2412
Prosecution Insights