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 .
Response to Arguments
Applicant’s arguments, see REM (11/26/2025) and EXIN (11/25/2025), with respect to the rejection(s) of claim(s) 1 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Gummadi et al. (US 20230228834 A1).
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.
Claims 1, 4 - 8, 12 - 15, 18 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gummadi et al. (US 20230228834 A1).
Regarding claim 1, Gummadi discloses a method comprising:
receiving, by an access and mobility management function (AMF) from a core network node, a request message (Fig. 1, AMF 115 communicates with external client 130 via GMLC 125; wherein the core network node interpreted as GMLC 125;
[0036], last sentence discloses “The core network 140 may communicate with the external client 130 (e.g., a computer system), e.g., to allow the external client 130 to request and/or receive location information regarding the UE 105 (e.g., via the GMLC 125)”;
[0039] discloses “An estimate of a location of the UE 105 may be referred to as a location, location estimate, location fix, fix, position, position estimate, or position fix, and may be geographic, thus providing location coordinates for the UE 105 (e.g., latitude and longitude) which may or may not include an altitude component (e.g., height above sea level, height above or depth below ground level, floor level, or basement level).”; hence altitude component can be part of the request message;
[0046] discloses “The GMLC 125 may support a location request for the UE 105 received from the external client 130 and may forward such a location request to the AMF 115 for forwarding by the AMF 115 to the LMF 120.”;
[0117] discloses “Referring again to FIG. 7, at stage 760, the network entity 1000 sends an LPP request location information message 762. …. The message 762 may include an indication of a frequency of RSTD, UE Rx-Tx, RSRP, AOD, RTT and/or other measurements to be taken and/or reported by the UE 500….”) indicating:
a request for a notification of an altitude of a wireless device ([0039] as stated above);
sending, by the AMF to a base station, a location reporting request associated with altitude of the wireless device ([0045] discloses “The gNBs 110a, 110b and the ng-eNB 114 may communicate with the AMF 115, which, for positioning functionality, communicates with the LMF 120………. The LMF 120 may communicate with the UE 105 via the AMF 115 and a gNB 110 or ng-eNB 114, e.g., through wireless communications, or directly with the BSs 110a, 110b, 114.”; wherein the location reporting request would have to be inherently sent to the UE via the base station since the base station communicates with the UE, as shown in Fig. 1);
and receiving, by the AMF, a location report associated with the altitude of the wireless device ([0046] discloses “A location response from the LMF 120 (e.g., containing a location estimate for the UE 105) may be returned to the GMLC 125 either directly or via the AMF 115 and the GMLC 125 may then return the location response (e.g., containing the location estimate) to the external client 130.”; Fig. 7, steps 770, 782;
[0118] discloses “At stage 770, the UE 500 may determine which cell(s) to measure and may determine location information. For example, the processor 510 may be configured to use the information regarding positions of the TRPs 300 and topographic information in the provide assistance data message 752, along with information regarding location (present and/or future), including height, of the UE 500 …..”);
and sending, by the AMF to the core network node, a report message notifying the altitude of the wireless device ([0046] discloses “A location response from the LMF 120 (e.g., containing a location estimate for the UE 105) may be returned to the GMLC 125 either directly or via the AMF 115 and the GMLC 125 may then return the location response (e.g., containing the location estimate) to the external client 130.”).
Gummadi discloses the request message indicates a request for a notification of an altitude but does not disclose that the request message indicates a request for a notification of an altitude change and a threshold for determining the altitude change.
However, Gummadi discloses:
the network entity tracks altitude change ([0109] discloses “The network entity 1000 may be configured to track the dynamically-changing height of the UE 500…”)
and that the network entity uses a threshold for determining the altitude change ([0109] discloses “... For example, the processor 1010 may configure ….. events H1, H2 regarding height thresholds. The processor 1010 may be configured to respond to determining that the UE 500 passes through (e.g., exceeds or drops below) a height corresponding to the event H1 and/or passes through a height corresponding to the event H2 by taking an appropriate action…… For example, the processor 1010 may affect a determination of the cell(s) to measure, e.g., to make a particular cell more likely to be measured in response to the UE 500 exceeding the height corresponding to the event H2, or less likely to be measured in response to the UE 500 dropping below the height corresponding to the event H1).
In Gummadi, the network entity tracks the altitude change and uses a threshold. However, under Rationales for Obviousness (MPEP 2143, Rationale F) and MAKING PORTABLE, INTEGRAL, SEPARABLE, ADJUSTABLE, OR CONTINUOUS (MPEP 2144.04, section V), having the UE perform the above functions is an obvious variation and can be considered a separable operation i.e. having different entities in the system perform the same function is not considered patentable.
As stated earlier, Gummadi discloses the request message may request location information which could include an altitude component and “other information” (see 1st limitation [0039] and [0117]). Hence, one of ordinary skill in the art could also send thresholds (“other information”) as part of the request message to the UE. In this scenario, the UE could perform what the network entity does above.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the invention, to have the UE itself perform the altitude change detection, as opposed to the network entity, because this would allow the UE to respond more quickly e.g. to altitude changes in the terrain.
Regarding claim 4, Gummadi discloses the AMF receives the location report from the base station (Fig. 1, gNB 110a communicates with AMF 115; [0045] discloses “The gNBs 110a, 110b and the ng-eNB 114 may communicate with the AMF 115, which, for positioning functionality, communicates with the LMF 120………. The LMF 120 may communicate with the UE 105 via the AMF 115 and a gNB 110 or ng-eNB 114, e.g., through wireless communications, or directly with the BSs 110a, 110b, 114.”).
Regarding claim 5, Gummadi discloses the AMF receives the location report from a second base station (Fig. 1, gNB 110a communicates with AMF 115; [0045] discloses “The gNBs 110a, 110b and the ng-eNB 114 may communicate with the AMF 115, which, for positioning functionality, communicates with the LMF 120………. The LMF 120 may communicate with the UE 105 via the AMF 115 and a gNB 110 or ng-eNB 114, e.g., through wireless communications, or directly with the BSs 110a, 110b, 114.”; wherein the 2nd base station could be the 2nd of 110a or 110b or 114).
Regarding claim 6, Gummadi discloses the wireless device moves from the base station to the second base station ([0041], last sentence discloses “In FIG. 1, the serving gNB for the UE 105 is assumed to be the gNB 110a, although another gNB (e.g., the gNB 110b) may act as a serving gNB if the UE 105 moves to another location ….”).
Claim 7 is similarly analyzed as the last two limitations in claim 1. Gummadi’s Fig. 1, AMF 115 also acts as MMF ([0033] discloses “As shown in FIG. 1, the NG-RAN 135 includes NR NodeBs (gNBs) 110a, 110b, and a next generation eNodeB (ng-eNB) 114, and the 5GC 140 includes an Access and Mobility Management Function (AMF) 115, …”).
Regarding claim 8, Gummadi discloses the mobility management function comprises an access and mobility management function (AMF) ([0033] discloses “As shown in FIG. 1, the NG-RAN 135 includes NR NodeBs (gNBs) 110a, 110b, and a next generation eNodeB (ng-eNB) 114, and the 5GC 140 includes an Access and Mobility Management Function (AMF) 115, …”).
Claim 12 is similarly analyzed as in claim 1.
Regarding claim 13, Gummadi discloses the threshold is associated with an upper height level for the altitude change; and wherein the message notifying the altitude change indicates that the wireless device is above the upper height level ([0109] discloses “... For example, the processor 1010 may configure ….. events H1, H2 regarding height thresholds. The processor 1010 may be configured to respond to determining that the UE 500 passes through (e.g., exceeds or drops below) a height corresponding to the event H1 and/or passes through a height corresponding to the event H2 by taking an appropriate action…… For example, the processor 1010 may affect a determination of the cell(s) to measure, e.g., to make a particular cell more likely to be measured in response to the UE 500 exceeding the height corresponding to the event H2, or less likely to be measured in response to the UE 500 dropping below the height corresponding to the event H1; wherein the upper height level is H2).
Claim 14 is similarly analyzed as in claims 1, 7 (MMF disclosed in claim 7).
Claim 15 is similarly analyzed as in claim 8.
Regarding claim 18, Gummadi discloses the threshold comprises at least one of: an upper height level; or a lower height level ([0109] discloses “... For example, the processor 1010 may configure ….. events H1, H2 regarding height thresholds. The processor 1010 may be configured to respond to determining that the UE 500 passes through (e.g., exceeds or drops below) a height corresponding to the event H1 and/or passes through a height corresponding to the event H2 by taking an appropriate action…… For example, the processor 1010 may affect a determination of the cell(s) to measure, e.g., to make a particular cell more likely to be measured in response to the UE 500 exceeding the height corresponding to the event H2, or less likely to be measured in response to the UE 500 dropping below the height corresponding to the event H1; wherein the upper height level is H2 and the lower height level is H1).
Claim 19 is similarly analyzed as in claim 13 (above upper level) and claim 1 (argument regarding UE performing the measurement and sending the report instead if network entity).
Claim 20 is similarly analyzed as in claim 18 (below lower level) and claim 1 (argument regarding UE performing the measurement and sending the report instead if network entity).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Gummadi et al. (US 20230228834 A1) in view of 3GPP TS 23.273 V16.5.0 (2020-12) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 5G System (SGS) Location Services (LCS); Stage 2 (Release 16) (hereafter 3GPP).
Regarding claim 2, Gummadi does not disclose the core network node comprises a network exposure function.
In the same field of endeavor, however, 3GPP discloses the core network node comprises a network exposure function (Fig. 6.1.2-1, NEF at top right corner).
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the invention, to use the NEF, as disclosed by 3GPP, in the system of Gummadi because a NEF can be used as a secure gateway that connects a 5G core to applications, as is well known in the art.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Gummadi et al. (US 20230228834 A1) in view of DiCosola (US 20200349852 A1).
Regarding claim 3, Gummadi does not disclose the request message is received from an unmanned aerial system (UAS) application server (AS) via the core network node, wherein the UAS AS comprises at least one of:
a UAS traffic manager (UTM)or a UAS service supplier (USS).
In the same field of endeavor, however, DiCosola discloses use of a UTM and USS ([0174]; [0187]; [0225]; [0246]; [0375]; [0430]).
Therefore, it would have been obvious to one having ordinary skill in the art, at the time the invention was filed, to use the method, as taught by DiCosola in the system of 3GPP because this would allow the drone to know where the UE is located. This would useful if the drone were to be making a delivery to the user of the UE.
Claims 9 – 11 are rejected under 35 U.S.C. 103 as being unpatentable over Gummadi et al. (US 20230228834 A1) in view of 3GPP TS 23.273 V16.5.0 (2020-12) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 5G System (SGS) Location Services (LCS); Stage 2 (Release 16) (hereafter 3GPP) and further in view of DiCosola (US 20200349852 A1).
Regarding claim 9, Gummadi does not disclose NEF and UAS/AS.
In the same field of endeavor, however, 3GPP discloses the core network node comprises a network exposure function (Fig. 6.1.2-1, NEF at top right corner).
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the invention, to use the NEF, as disclosed by 3GPP, in the system of Gummadi because a NEF can be used as a secure gateway that connects a 5G core to applications, as is well known in the art.
In the same field of endeavor, however, DiCosola discloses use of a UAS ([0187]; [0225]).
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the invention, to use the NEF, as disclosed by DiCosola in the system of Gummadi because this would allow the drone to know where the UE is located. This would useful if the drone were to be making a delivery to the user of the UE.
Claim 9 additionally recites “ … the message notifying the altitude change is sent via the NEF to an unmanned aerial system UAS ..AS”.
Though this is not disclosed by Gummadi, it is obvious to try by one of ordinary skill in the art (Rationales for Obviousness (MPEP 2143, Rationale E)), since the NEF is merely another network element and transmitting messages between different network elements is well known.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the invention, to send messages via the NEF, as this would be useful when other network elements are overloaded, as is well known and obvious to one of ordinary skill in the art.
Regarding claim 10, Gummadi discloses receiving, by the AMF from the core network node, a request message (Fig. 1, AMF 115 communicates with external client 130 via GMLC 125; wherein the core network node interpreted as GMLC 125;
[0036], last sentence discloses “The core network 140 may communicate with the external client 130 (e.g., a computer system), e.g., to allow the external client 130 to request and/or receive location information regarding the UE 105 (e.g., via the GMLC 125)”;
[0039] discloses “An estimate of a location of the UE 105 may be referred to as a location, location estimate, location fix, fix, position, position estimate, or position fix, and may be geographic, thus providing location coordinates for the UE 105 (e.g., latitude and longitude) which may or may not include an altitude component (e.g., height above sea level, height above or depth below ground level, floor level, or basement level).”; hence altitude component can be part of the request message;
[0046] discloses “The GMLC 125 may support a location request for the UE 105 received from the external client 130 and may forward such a location request to the AMF 115 for forwarding by the AMF 115 to the LMF 120.”;
[0117] discloses “Referring again to FIG. 7, at stage 760, the network entity 1000 sends an LPP request location information message 762. …. The message 762 may include an indication of a frequency of RSTD, UE Rx-Tx, RSRP, AOD, RTT and/or other measurements to be taken and/or reported by the UE 500….”) indicating:
a request for a notification of the altitude of the wireless device ([0039] as stated above).
Gummadi discloses the request message indicates a request for a notification of an altitude but does not disclose that the request message indicates a request for a notification of an altitude change and a threshold for determining the altitude change.
However, Gummadi discloses:
the network entity tracks altitude change ([0109] discloses “The network entity 1000 may be configured to track the dynamically-changing height of the UE 500…”)
and that the network entity uses a threshold for determining the altitude change ([0109] discloses “... For example, the processor 1010 may configure ….. events H1, H2 regarding height thresholds. The processor 1010 may be configured to respond to determining that the UE 500 passes through (e.g., exceeds or drops below) a height corresponding to the event H1 and/or passes through a height corresponding to the event H2 by taking an appropriate action…… For example, the processor 1010 may affect a determination of the cell(s) to measure, e.g., to make a particular cell more likely to be measured in response to the UE 500 exceeding the height corresponding to the event H2, or less likely to be measured in response to the UE 500 dropping below the height corresponding to the event H1).
In Gummadi, the network entity tracks the altitude change and uses a threshold. However, under Rationales for Obviousness (MPEP 2143, Rationale F) and MAKING PORTABLE, INTEGRAL, SEPARABLE, ADJUSTABLE, OR CONTINUOUS (MPEP 2144.04, section V), having the UE perform the above functions is an obvious variation and can be considered a separable operation i.e. having different entities in the system perform the same function is not considered patentable.
As stated earlier, Gummadi discloses the request message may request location information which could include an altitude component and “other information” (see 1st limitation [0039] and [0117]). Hence, one of ordinary skill in the art could also send thresholds (“other information”) as part of the request message to the UE. In this scenario, the UE could perform what the network entity does above.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the invention, to have the UE itself perform the altitude change detection, as opposed to the network entity, because this would allow the UE to respond more quickly e.g. to altitude changes in the terrain.
Gummadi also does not disclose receiving, by the AMF from the UAS AS via the NEF.
Though this is not explicitly disclosed by Gummadi, it is obvious to try by one of ordinary skill in the art (Rationales for Obviousness (MPEP 2143, Rationale E)), since the NEF is merely another network element and transmitting messages between different network elements is well known. For example, if the external client 130 in Gummadi (Fig. 1; [0036] discloses “…external client 130. For example, such other devices may include internet of thing (IoT) devices, medical devices, home entertainment and/or automation devices, etc.”) were the UAS and the GMLC were the NEF (i.e. both gateways), then one of ordinary skill in the art could use Gummadi method as described above.
Therefore, it would have been obvious to one having ordinary skill in the art, at the time the invention was filed, to send messages from the UAS/external client via the NEF, as this would be useful when other network elements are overloaded, as is well known and obvious to one of ordinary skill in the art.
Claim 11 is similarly analyzed as in claims 9 and 10. The "event exposure subscribe request message" is interpreted as the "request for a notification of an altitude change", with the event being the altitude change.
Claims 16 - 17 are rejected under 35 U.S.C. 103 as being unpatentable over Gummadi et al. (US 20230228834 A1) in view of Kim et al. (US 20190254105 A1).
Regarding claim 16, Gummadi discloses sending, by the base station to the wireless device, a message indicating a measurement report for a height of the wireless device ([0045] discloses “The gNBs 110a, 110b and the ng-eNB 114 may communicate with the AMF 115, which, for positioning functionality, communicates with the LMF 120………. The LMF 120 may communicate with the UE 105 via the AMF 115 and a gNB 110 or ng-eNB 114, e.g., through wireless communications, or directly with the BSs 110a, 110b, 114.”; wherein the location reporting request would have to be inherently sent to the UE via the base station since the base station communicates with the UE, as shown in Fig. 1);
and receiving, by the base station from the wireless device, a response message notifying the height of the wireless device (Fig. 1, e.g. UE 105 communicates with AMF 115 via gNB 110a; [0046] discloses “A location response from the LMF 120 (e.g., containing a location estimate for the UE 105) may be returned to the GMLC 125 either directly or via the AMF 115 and the GMLC 125 may then return the location response (e.g., containing the location estimate) to the external client 130.”; Fig. 7, steps 770, 782).
Gummadi discloses the request message indicates a request for a notification of an altitude but does not disclose that the request message indicates a request for a notification of an altitude change and a threshold for determining the altitude change.
However, Gummadi discloses:
the network entity tracks altitude change ([0109] discloses “The network entity 1000 may be configured to track the dynamically-changing height of the UE 500…”)
and that the network entity uses a threshold for determining the altitude change ([0109] discloses “... For example, the processor 1010 may configure ….. events H1, H2 regarding height thresholds. The processor 1010 may be configured to respond to determining that the UE 500 passes through (e.g., exceeds or drops below) a height corresponding to the event H1 and/or passes through a height corresponding to the event H2 by taking an appropriate action…… For example, the processor 1010 may affect a determination of the cell(s) to measure, e.g., to make a particular cell more likely to be measured in response to the UE 500 exceeding the height corresponding to the event H2, or less likely to be measured in response to the UE 500 dropping below the height corresponding to the event H1).
In Gummadi, the network entity tracks the altitude change and uses a threshold. However, under Rationales for Obviousness (MPEP 2143, Rationale F) and MAKING PORTABLE, INTEGRAL, SEPARABLE, ADJUSTABLE, OR CONTINUOUS (MPEP 2144.04, section V), having the UE perform the above functions is an obvious variation and can be considered a separable operation i.e. having different entities in the system perform the same function is not considered patentable.
Gummadi discloses the request message may request location information which could include an altitude component and “other information” (see 1st limitation [0039] and [0117]). Hence, one of ordinary skill in the art could also send thresholds (“other information”) as part of the request message to the UE. In this scenario, the UE could perform what the network entity does above.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the invention, to have the UE itself perform the altitude change detection, as opposed to the network entity, because this would allow the UE to respond more quickly e.g. to altitude changes in the terrain.
Gummadi also does not disclose a radio resource control (RRC) message and RRC response message.
In the same field of endeavor, however, Kim discloses using RRC messages (Abstract; [0007]; [0013] – [0014]; [0048] – [0050]).
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the invention, to use RRC messages, as disclosed by Kim, in the system of Gummadi as the RRC protocol is well known in the art and has advantages of faster connection, lower latency etc.
Regarding claim 17, Gummadi does not disclose the RRC message comprises an RRC connection reconfiguration message or an RRC resume message.
In the same field of endeavor, however, Kim discloses the RRC message comprises an RRC connection reconfiguration message or an RRC resume message ([0014]; [0114], 2nd last sentence).
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the invention, to use RRC messages, as disclosed by Kim, in the system of Gummadi as the RRC protocol is well known in the art and has advantages of faster connection, lower latency etc.
Other Prior Art Cited
The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure.
The following patents/publications are cited to further show the state of the art with respect to tracking position/height/events related to a UE:
Di Cosola (US 20220169401 A1) discloses Smart City Smart Drone UASS/UAV/VTOL Smart Mailbox Landing Pad.
Kotecha (US 20160371985 A1) discloses Dynamic Navigation of UAVS Using Three-Dimensional Network Coverage Information.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADOLF DSOUZA whose telephone number is (571)272-1043. The examiner can normally be reached Mon - Fri 9 AM - 5 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, Chieh M Fan can be reached at 571-272-3042. 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.
/ADOLF DSOUZA/Primary Examiner, Art Unit 2632