DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/12/26 has been entered.
Response to Argument
Applicant's arguments, filed 01/26/26, with respect to claims have been considered but are moot in view of the new ground(s) of rejection.
Claims 11, 20-22, 24 and 26-28 have been canceled.
Claims 1-10, 12-19 and 25 are pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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-3, 6-10, 13-15, 18-19, 23 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Patel et al. (U.S. 20170118592) in view of Edge (U.S. 20200196101).
For claim 1, Patel et al. disclose a method at a location management server, comprising:
receiving a location reporting trigger for activating a location reporting procedure for obtaining location information of a first location management client from a second location management client or a Vertical Application Layer, VAL, server, wherein the location reporting trigger comprises endpoint information of the second location management client or the VAL server (at least Fig. 4, [0005] and [0054]-[0056]. The group supervisor 202A requests the location data of the group member 202B by creating a location data collection criteria and sends the location data collection criteria to the location management server 204. The location management server 204 sends the location data collection criteria and the location data reporting criteria to the group member 202B.);
initiating a location reporting procedure for the location information of the first location management client (at least Fig. 4, [0005] and [0054]-[0056]. The group supervisor 202A requests the location data of the group member 202B by creating a location data collection criteria and sends the location data collection criteria to the location management server 204. The location management server 204 sends the location data collection criteria and the location data reporting criteria to the group member 202B.); and
when location information of the first location management client is available in the location management server, sending a location information report comprising the location information of the first location management client to the second location management client or the VAL server based on the endpoint information of the second location management client or the Val server (at least Fig. 4, [0005] and [0054]-[0060]. The group member 202B records its location and storing the location data in its local DB. The group member 202B sends the stored location data to the location management server 204 (step 408). The data is sent according to the reporting criteria. The location management server 204 notifies the group supervisor 202A and the group member 202B in response to determining the location-state of the group member 202B.) However, Patel et al. do not disclose the endpoint information comprising at least one of: a Uniform Resource Identifier, URI; or an Internet Protocol, IP, address and port number.
In the same field of endeavor, Edge discloses the endpoint information comprising at least one of: a Uniform Resource Identifier, URI; or an Internet Protocol, IP, address and port number (at least Fig. 5 and [0103]. The external client 130 may send a location request for the target UE 105 to either an NEF 159 (Request via NEF) or a GMLC 155 (Request via GMLC) in the SGCN. For a request via an NEF 159, a location request sent to the NEF 159 at stage 1 may include: (i) an identity of the target UE 105 (e.g. a GPSI or SUPI); (ii) criteria for sending back location reports at stage 21 (e.g. location report trigger events such as an area event trigger or a UE motion trigger or parameters for periodic sending of location reports); (iii) Quality of Service (QoS) parameters such as a required location accuracy, location reporting latency and location reporting reliability; (iv) a minimum and/or a maximum location reporting interval; (v) criteria for starting and stopping location reporting (e.g. a start time, stop time, maximum number of reports, maximum duration of reporting); (vi) location reporting content (e.g. supported Geographic Area Description (GAD) shapes and whether UE velocity and/or UE orientation should be reported); (vii) an identification of the external client (e.g. a client name, Fully Qualified Domain Name (FQDN) or IP address); and/or (viii) a location session reference (e.g. a number or an alphanumeric sequence) to be used later to identify location reports at stage 21. The location request at stage 1 may also include a request to send location reports (e.g. at stage 21) via a user plane and an address to which location reports should be sent via the user plane (e.g. an IP address, Uniform Resource Identifier (URI) or FQDN) and security information.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the invention of Patel et al. as taught by Edge for purpose of sending location data directly to a specific server.
For claim 2, the combination of Patel et al. and Edge disclose the method according to claim 1. Patel et al. disclose receiving a location reporting configuration request from the first location management client; and sending a location reporting configuration response to the first location management client, wherein the location reporting configuration response comprises at least one location reporting trigger configuration identified by a corresponding configuration identity (at least [0046]. The collection criteria specifies how the location-aware clients 202 should collect and persist location data in their local DB. The reporting criteria specifies how frequently the location-aware clients 202 should report the collected location data to the location management server 204. The location data collection and reporting criteria may include a variety of elements. Examples of criteria include: time elapsed (frequency); distance travelled; altitude changes. Criteria may also include access network related events such as cell changes, public land mobile network (PLMN) changes, Wi-Fi access point changes, Wi-Fi service set identifier (SSID) changes, multimedia broadcast multicast services (MBMS) service area changes, multicast-broadcast single-frequency network (MBSFN) area changes, tracking area changes, and the like. Criteria may also include events detected by an environmental sensor, such as motion detection, changes to temperature, velocity, acceleration, humidity, direction, and the like.)
For claim 3, the combination of Patel et al. and Edge disclose the method according to claim 1. Patel et al. disclose each of the at least one location reporting trigger configuration comprises at least one of: requested location information; triggering criteria; and a minimum time between consecutive reports identity (at least [0046]. The collection criteria specifies how the location-aware clients 202 should collect and persist location data in their local DB. The reporting criteria specifies how frequently the location-aware clients 202 should report the collected location data to the location management server 204. The location data collection and reporting criteria may include a variety of elements. Examples of criteria include: time elapsed (frequency); distance travelled; altitude changes. Criteria may also include access network related events such as cell changes, public land mobile network (PLMN) changes, Wi-Fi access point changes, Wi-Fi service set identifier (SSID) changes, multimedia broadcast multicast services (MBMS) service area changes, multicast-broadcast single-frequency network (MBSFN) area changes, tracking area changes, and the like. Criteria may also include events detected by an environmental sensor, such as motion detection, changes to temperature, velocity, acceleration, humidity, direction, and the like.)
For claim 6, the combination of Patel et al. and Edge disclose the method according to claim 1. Patel et al. disclose sending a location reporting configuration update request to the first location management client; and receiving a location reporting configuration update response from the first location management client, wherein the location reporting configuration update request comprises update information regarding at least one location reporting trigger configuration identified by a corresponding configuration identity (at least [0062]. The group supervisor 202A may request an on-demand location update from the group member 202B. Such a request may be made out-of-band, e.g., between the normal location data collection intervals specified by the collection and/or reporting criteria. In such embodiments, the group supervisor 202A sends an on-demand location update request to the location management server 204, which forwards the request to the group member 202B. The group member 202B then responds to the request by updating its location in the local DB and synchronizing the update to the DB cluster 206. In some embodiments, the on-demand location update request may also include a request to report location data at a different frequency for a defined period of time.)
For claim 7, the combination of Patel et al. and Edge disclose the method according to claim 1. Patel et al. disclose receiving a location information report from the first location management client, wherein the location information report includes location information and one or more configuration identities; and updating the location information related to the one or more configuration identities based on the received location information (at least [0062]. The group supervisor 202A may request an on-demand location update from the group member 202B. Such a request may be made out-of-band, e.g., between the normal location data collection intervals specified by the collection and/or reporting criteria. In such embodiments, the group supervisor 202A sends an on-demand location update request to the location management server 204, which forwards the request to the group member 202B. The group member 202B then responds to the request by updating its location in the local DB and synchronizing the update to the DB cluster 206. In some embodiments, the on-demand location update request may also include a request to report location data at a different frequency for a defined period of time. The request may be in the form of new temporary collection and/or reporting criteria. The group member 202B then uses the new criteria when reporting location data to the location management server 204. The location management server 204 forwards the location data back to the group supervisor 202A.)
For claim 8, the combination of Patel et al. and Edge disclose the method according to claim 1. Patel et al. disclose the location reporting procedure comprises: sending a location information request to the first location management client; receiving a location information report from the first location management client; and updating the location information of the first location management client based on the location information report (at least [0062]. The group supervisor 202A may request an on-demand location update from the group member 202B. Such a request may be made out-of-band, e.g., between the normal location data collection intervals specified by the collection and/or reporting criteria. In such embodiments, the group supervisor 202A sends an on-demand location update request to the location management server 204, which forwards the request to the group member 202B. The group member 202B then responds to the request by updating its location in the local DB and synchronizing the update to the DB cluster 206. In some embodiments, the on-demand location update request may also include a request to report location data at a different frequency for a defined period of time. The request may be in the form of new temporary collection and/or reporting criteria. The group member 202B then uses the new criteria when reporting location data to the location management server 204. The location management server 204 forwards the location data back to the group supervisor 202A.)
For claim 9, the combination of Patel et al. and Edge disclose the method according to claim 1. Patel et al. disclose when the location reporting trigger comprises an indicator for indicating that an immediate location report is required, the location information of the first location management client is sent to the client or the server immediately (at least [0049]. The location-aware clients 202 publish their location data to the location management server 204 continuously, e.g., after each new location data point is collected.)
For claim 10, the combination of Patel et al. and Edge disclose the method according to claim 1. Patel et al. disclose the client is a second location management client and the server is a VAL server; and/or wherein a communication between a location management client and the location management server is implemented through a third Generation Partnership Project network system (at least [0028]. The client devices 102 may communicate with the telecommunications services platform 106 over the communications network 104, which may be accessed by the client devices 102 through a cellular network deployed by a carrier, a WiFi network, a RAN, other wireless networks, a wired internet protocol (IP) network, combinations thereof, or the like. The communications network 104 may include one or more components configured to provide wireless or wired network access, such as an enhanced Node B (eNB), a macro-cell, a femtocell, a Wi-Fi access point (AP), combinations thereof, or the like. Furthermore, the communications network 104 may operate in accordance with one or more wireless communication protocols, e.g., open mobile alliance (OMA), LTE, LTE advanced (LTE-A), High Speed Packet Access (HSPA), Wi-Fi 802.11a/b/g/n/ac, etc. In some embodiments, the communications network 104 may comprise various other devices, such as relays, low power nodes, etc.)
For claims 13-15, the claims have features similar to claims 1-3. Therefore, the claims are also rejected for the same reasons in claims 1-3.
For claims 18-19, the claims have features similar to claims 6-7. Therefore, the claims are also rejected for the same reasons in claims 6-7.
For claims 23 and 25, the claims have features similar to claim 1. Therefore, the claims are also rejected for the same reasons in claim 1.
Claims 4 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Patel et al. (U.S. 20170118592) in view of Edge (U.S. 20200196101) and further in view of Pattan et al. (U.S. 11792884).
For claim 4, the combination of Patel et al. and Edge do not disclose the method according to claim 2, wherein the location reporting configuration response further comprises an identity of a VAL user or an identity of a VAL group to which the location reporting configuration is targeted or an identity of the VAL user equipment.
In the same field of endeavor, Pattan et al. disclose the announcing comprises an identity of a VAL user or an identity of a VAL group to which the location reporting configuration is targeted or an identity of the VAL user equipment (at least col. 10, lines 49-63. The method includes, announcing by the group management server 130, the group creation information to the at least one group management client 150a-150n. The group announcement comprises at least one IE. The at least one IE comprises the VAL group ID indicating the group ID used for the VAL group and a VAL group description providing information related to the VAL group such as group ID, group definition including group policy, group size and group leader. The IE may optionally include VAL service ID list indicating a list of VAL services for which service communications are to be enabled on the group. The IE may also include a Geo ID list indicating a list of geographical areas to be addressed by the group. The IE may also include the identity list indicating a list of VAL UE Ids who are invited to be member of the group.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the invention of Patel et al. as taught by Pattan et al. for purpose of sending, by the group management server, the VAL group's member information to a VAL client.
For claim 16, the claim has features similar to claim 4. Therefore, the claim has also rejected for the same reasons in claim 4.
Claims 5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Patel et al. (U.S. 20170118592) in view of Edge (U.S. 20200196101) and further in view of Ferdi et al. (U.S. 20230199863).
For claim 5, the combination of Patel et al. and Edge do not disclose the method according to claim 1, further comprising: sending a location reporting configuration cancel request to the first location management client; and receiving a location reporting configuration cancel response from the first location management client, wherein the location reporting configuration cancel request comprises at least one configuration identity for invalidating at least one location reporting event trigger configuration identified by the at least one configuration identity, or wherein when the location reporting configuration cancel request does not comprise any configuration identity, all the location reporting event trigger configurations are invalidated.
In the same field of endeavor, Ferdi et al. disclose sending a location reporting configuration cancel request to the first location management client; and receiving a location reporting configuration cancel response from the first location management client, wherein the location reporting configuration cancel request comprises at least one configuration identity for invalidating at least one location reporting event trigger configuration identified by the at least one configuration identity, or wherein when the location reporting configuration cancel request does not comprise any configuration identity, all the location reporting event trigger configurations are invalidated (at least [0151]. An EF may forward a UAV location request to a (e.g., the appropriate) location tracking function (e.g., an AMF, a GMLC, etc.) in a case where the USS/UTM identifiers match. Further, in such a case, an EF may discard or reject the location request if the IDs do not match. According to embodiments, an EF may forward a UAV location request to the AMF, for example, including information indicating any of a 3GPP UAV ID and an ID of a requesting USS/UTM. According to embodiments, an AMF may check (e.g., verify, determine, compute, etc.) that the ID of the USS/UTM associated with the UAV (e.g., locally stored, obtained from a UDM) matches the one received from an EF (e.g., the USS/UTM making the location request). According to embodiments, an AMF may obtain UAV location request information and may send such information to the requesting EF, for example, in a case where the USS/UTM identifiers match. Further, in such a case, an AMF may discard or reject the location request if the USS/UTM identifiers do not match.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the invention of Patel et al. as taught by Ferdi et al. for purpose of providing the location of the target UAV.
For claim 17, the claim has features similar to claim 5. Therefore, the claim has also rejected for the same reasons in claim 5.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Patel et al. (U.S. 20170118592) in view of Edge (U.S. 20200196101) and further in view of Pattan et al. (U.S. 20200178052).
For claim 12, the combination of Patel et al. and Edge do not disclose the method according to claim 1, wherein the location management server is a Service Enabler Architecture Layer for Verticals (SEAL) server and the location management client is a VAL client.
In the same field of endeavor, Pattan et al. disclose the location management server is a Service Enabler Architecture Layer for Verticals (SEAL) server and the location management client is a VAL client (at least [0082]. In a vertical application layer (i.e., the service application system 300), a VAL client communicates with a VAL server over a VAL-UU reference point. The service application system 300 includes an application server for each vertical such as for example Public Safety, Automotive, Health, Logistics etc. The SEAL system 1000 functional entities on a user equipment (UE) and the SEAL system 1000 are grouped into SEAL client(s) and SEAL server(s) respectively. The SEAL system 1000 offers the requested services to the vertical application layer (VAL). The SEAL client(s) communicates with at least one SEAL service server of the plurality of SEAL service servers 180 over a SEAL-UU reference points (as shown in FIG. 19). The SEAL client(s) provides the service enabler layer support functions to the VAL client(s) over SEAL-C reference points (as shown in FIG. 19). The VAL server(s) communicate with the at least one SEAL service server of the plurality of SEAL service servers 180 over a SEAL-S reference points (as shown in FIG. 19).)
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the invention of Patel et al. as taught by Pattan et al. for purpose of provisioning inter-services communication in a service enabler architecture layer (SEAL) system of a wireless communication network.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAI PHUONG whose telephone number is 571-272-7896. The examiner can normally be reached on Monday-Friday, 8am-5pm.
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, Kathy Wang-Hurst can be reached on 571-270-5371. The fax phone number for the organization where this application or proceeding is assigned is 571-273-7687.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/DAI PHUONG/Primary Examiner, Art Unit 2644