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 .
Information Disclosure Statement
The Information Disclosure Statement (IDS) filed on November 26, 2024 has been considered by the examiner. Claims 1-20 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, 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, 8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Thyni et al. (US 20160330576 A1, hereinafter “Thyni”), in view of Jansen et al. (US 20100306410 A1, hereinafter “Jansen”).
Regarding Claim 1, Thyni teaches a computer-implemented method for exposing a location associated with an emergency call, the method comprising: “The end users typically use their wired or wireless communication devices to communicate, and are communicatively connected via a communication network to an OTT service providing node of an OTT service provider. Typically, communication networks consist of a plurality of operator controlled networks of different operators.” [0003], and “ the term “operator” will be used to denote a network service provider of the communication network, and not the OTT service provider.” [0006]
receiving, at a first network, a request to initiate an emergency session from a user device associated with a second network, wherein the request triggers the first network to determine location information of the user device and wherein data associated with the location information of the user device is maintained by the second network in one or more databases shared between the first network, the second network, and a Domain Name System (DNS), “when an end-user utilises an OTT service to perform an emergency call, the OTT service providing node will retrieve the geographic location information of the host from the OLS node within sub-seconds and present to an emergency operator.” [0034], and “when connecting a host 208 to a communication network, the geographic location of the host 208 is uploaded to an LCS (Location Server) 210 of the communication network operator.” [0038], and “store and update the geographic location of hosts 208 m in a location server of the communication network when connecting the hosts 208 m.” [0048], and “ the host 208 sends an OTT request to the OTT service providing node 200.” [0053], and “the OTT service providing node 200 determines the Global-host-ID and performs a reverse DNS look-up of the IP-address Global-host-ID to determine which operator the host 208 or the CG-NAT node 206 is operated by.” [0053], and “the OTT service providing node 200 queries the DNS server 204 for the IP-address of an OLS (Operator Location Service) node 202 of the present operator.” [0054], and “This is performed by, in an action 3:4, performing a DNS lookup for an SRV (service) record of the operator, and receiving the IP-address and service port number of the operator's OLS in response in following action 3:5.” [0054].
querying, by the first network, the DNS for the location information associated with the user device, wherein the one or more databases are updated by the second network, “the OTT service providing node 200 determines the Global-host-ID and performs a reverse DNS look-up of the IP-address Global-host-ID to determine which operator the host 208 or the CG-NAT node 206 is operated by. “ [0053], and “the OTT service providing node 200 queries the DNS server 204 for the IP-address of an OLS (Operator Location Service) node 202 of the present operator.” [0054], and “store and update the geographic location of hosts 208 m in a location server of the communication network when connecting the hosts 208 m” [0048].
receiving, at the first network and from the DNS via the one or more databases, the location information associated with the user device, “The LCS 210 then sends stored location information regarding the host 208 to the OLS node 202” [0056], and “the OLS node 202 sends the received location information to the OTT service providing node 200” [0057].
updating the emergency session based on the location information, “if the OTT service is an emergency call, the OTT service providing node will automatically retrieve appropriate location information of the host and present to an emergency authority operator substantially simultaneously as he/she answers the emergency call.” [0073]
However, Thyni does not explicitly teach:
wherein data associated with the location information of the user device is maintained by the second network in one or more databases shared between the first network, the second network, and a Domain Name System (DNS);
querying the DNS for the location information itself, wherein the one or more databases containing the location information are updated by the second network; or
receiving the location information from the DNS via the one or more databases.
Jansen teaches wherein data associated with the location information of the user device is maintained by the second network in one or more databases shared between the first network, the second network, and a Domain Name System (DNS), “Embodiments of the present invention may use DNS servers to allow clients to discover their locations. A DNS server may be configured to store information that indicates the location of client 130 based on an IP address associated with the client 130.” [0041], and “such information is stored within location containers implemented via Text (TXT) records in accordance with existing DNS protocols” [0041], and “The modified B+ tree structure or searchable tree structure 401 may be stored in any type of a data store 470, including databases” [0069], and “Data stores 470 may be distributed throughout a network topology or may be centrally located inside or outside of the network topology” [0071].
querying the DNS for the location information itself, wherein the one or more databases containing the location information are updated by the second network, “A DNS server may be configured to store information that indicates the location of client 130 based on an IP address associated with the client 130.” [0041], and “ the client 130 queries a DNS server using its selected IP address 150 (or its only IP address as the case may be) to solicit information useful in determining its location within a network topology, or its general geographic location which is associated with a particular network location or sub-network within the network topology.” [0042], and “When the client queries the DNS server for information, it is specifically querying the DNS server for a TXT record associated with a particular input, such as the IP address 150 or domain name of the client 130.” [0043], and “Tree builder/creator 406 may automatically rebuild or update the B+ tree on a recurring basis” [0074], and “the DNS records that make up the tree are stored in a distributed database D.” [0098], and “Updates to the tree are implemented by making updates (includes addition/removal) to the DNS records that make up the tree” [0098].
receiving the location information from the DNS via the one or more databases, “The client 130 query results in the DNS server returning a location container 145, implemented via the DNS TXT record, which contains a list of sub-locations 155 and a location IP address space 160 encompassing the sub-locations.” [0045], and “At block 510, processing logic queries a DNS server for location information associated with the IP address of the client.” [0101], and “The location information received by the client responsive to the DNS query contains a list of sub-locations and a location IP address space which encompasses the sub-locations listed.” [0101].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Thyni’s location retrieval arrangement by incorporating Jansen’s DNS-based location discovery mechanism to provide more efficient access to location information.
Regarding Claim 8, Thyni teaches a system comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, configure the system to: “Optionally, the OTT service providing node 700 of the above described embodiments may comprise further components or units arranged to provide appropriate functionality. For instance, suitable processors 706 or storage units 708 may by arranged to provide improved calculation capacity, or storing geographic location information of frequent hosts, etc.” [0112], and “The computer readable medium may have stored thereon a computer program comprising program instructions. The computer program may be loadable into a data-processing unit 830, which may, for example, be comprised in a communication network node 810. When loaded into the data-processing unit 830, the computer program may be stored in a memory 820 associated with or integral to the data-processing unit 830. According to some embodiments, the computer program may, when loaded into and run by the data-processing unit 830, cause the data-processing unit 830 to execute method steps according to, for example, the methods shown in the FIGS. 4 or 5.” [0114]
receive, at a first network, a request to initiate an emergency session from a user device associated with a second network, wherein the request triggers the first network to determine location information of the user device and wherein data associated with the location information of the user device is maintained by the second network in one or more databases shared between the first network, the second network, and a Domain Name System (DNS), “when an end-user utilises an OTT service to perform an emergency call, the OTT service providing node will retrieve the geographic location information of the host from the OLS node within sub-seconds and present to an emergency operator.” [0034], and “when connecting a host 208 to a communication network, the geographic location of the host 208 is uploaded to an LCS (Location Server) 210 of the communication network operator.” [0038], and “store and update the geographic location of hosts 208 m in a location server of the communication network when connecting the hosts 208 m.” [0048], and “ the host 208 sends an OTT request to the OTT service providing node 200.” [0053], and “the OTT service providing node 200 determines the Global-host-ID and performs a reverse DNS look-up of the IP-address Global-host-ID to determine which operator the host 208 or the CG-NAT node 206 is operated by.” [0053], and “the OTT service providing node 200 queries the DNS server 204 for the IP-address of an OLS (Operator Location Service) node 202 of the present operator.” [0054], and “This is performed by, in an action 3:4, performing a DNS lookup for an SRV (service) record of the operator, and receiving the IP-address and service port number of the operator's OLS in response in following action 3:5.” [0054].
query, by the first network, the DNS for the location information associated with the user device, wherein the one or more databases are updated by the second network, “the OTT service providing node 200 determines the Global-host-ID and performs a reverse DNS look-up of the IP-address Global-host-ID to determine which operator the host 208 or the CG-NAT node 206 is operated by. “ [0053], and “the OTT service providing node 200 queries the DNS server 204 for the IP-address of an OLS (Operator Location Service) node 202 of the present operator.” [0054], and “store and update the geographic location of hosts 208 m in a location server of the communication network when connecting the hosts 208 m” [0048].
receive, at the first network and from the DNS via the one or more databases, the location information associated with the user device, “The LCS 210 then sends stored location information regarding the host 208 to the OLS node 202” [0056], and “the OLS node 202 sends the received location information to the OTT service providing node 200” [0057].
update the emergency session based on the location information, “if the OTT service is an emergency call, the OTT service providing node will automatically retrieve appropriate location information of the host and present to an emergency authority operator substantially simultaneously as he/she answers the emergency call.” [0073]
However, Thyni does not explicitly teach:
wherein data associated with the location information of the user device is maintained by the second network in one or more databases shared between the first network, the second network, and a Domain Name System (DNS);
query the DNS for the location information itself, wherein the one or more databases containing the location information are updated by the second network; or
receive the location information from the DNS via the one or more databases.
Jansen teaches wherein data associated with the location information of the user device is maintained by the second network in one or more databases shared between the first network, the second network, and a Domain Name System (DNS), “Embodiments of the present invention may use DNS servers to allow clients to discover their locations. A DNS server may be configured to store information that indicates the location of client 130 based on an IP address associated with the client 130.” [0041], and “such information is stored within location containers implemented via Text (TXT) records in accordance with existing DNS protocols” [0041], and “The modified B+ tree structure or searchable tree structure 401 may be stored in any type of a data store 470, including databases” [0069], and “Data stores 470 may be distributed throughout a network topology or may be centrally located inside or outside of the network topology” [0071].
query the DNS for the location information itself, wherein the one or more databases containing the location information are updated by the second network, “A DNS server may be configured to store information that indicates the location of client 130 based on an IP address associated with the client 130.” [0041], and “ the client 130 queries a DNS server using its selected IP address 150 (or its only IP address as the case may be) to solicit information useful in determining its location within a network topology, or its general geographic location which is associated with a particular network location or sub-network within the network topology.” [0042], and “When the client queries the DNS server for information, it is specifically querying the DNS server for a TXT record associated with a particular input, such as the IP address 150 or domain name of the client 130.” [0043], and “Tree builder/creator 406 may automatically rebuild or update the B+ tree on a recurring basis” [0074], and “the DNS records that make up the tree are stored in a distributed database D.” [0098], and “Updates to the tree are implemented by making updates (includes addition/removal) to the DNS records that make up the tree” [0098].
receive the location information from the DNS via the one or more databases, “The client 130 query results in the DNS server returning a location container 145, implemented via the DNS TXT record, which contains a list of sub-locations 155 and a location IP address space 160 encompassing the sub-locations.” [0045], and “At block 510, processing logic queries a DNS server for location information associated with the IP address of the client.” [0101], and “The location information received by the client responsive to the DNS query contains a list of sub-locations and a location IP address space which encompasses the sub-locations listed.” [0101].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Thyni’s location retrieval arrangement by incorporating Jansen’s DNS-based location discovery mechanism to provide more efficient access to location information.
Regarding Claim 15, Thyni teaches a non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium including instructions that when executed by a computer, cause the computer to: “According to some exemplifying embodiments, a computer program product comprises a computer readable medium such as, for example, a diskette or a CD-ROM (Compact Disc Read Only Memory) as illustrated by 800 in FIG. 8. The computer readable medium may have stored thereon a computer program comprising program instructions.” [0114], and “The computer program may be loadable into a data-processing unit 830, which may, for example, be comprised in a communication network node 810. When loaded into the data-processing unit 830, the computer program may be stored in a memory 820 associated with or integral to the data-processing unit 830.” [0114], and “According to some embodiments, the computer program may, when loaded into and run by the data-processing unit 830, cause the data-processing unit 830 to execute method steps according to, for example, the methods shown in the FIGS. 4 or 5.” [0114]
receive, at a first network, a request to initiate an emergency session from a user device associated with a second network, wherein the request triggers the first network to determine location information of the user device and wherein data associated with the location information of the user device is maintained by the second network in one or more databases shared between the first network, the second network, and a Domain Name System (DNS), “when an end-user utilises an OTT service to perform an emergency call, the OTT service providing node will retrieve the geographic location information of the host from the OLS node within sub-seconds and present to an emergency operator.” [0034], and “when connecting a host 208 to a communication network, the geographic location of the host 208 is uploaded to an LCS (Location Server) 210 of the communication network operator.” [0038], and “store and update the geographic location of hosts 208 m in a location server of the communication network when connecting the hosts 208 m.” [0048], and “ the host 208 sends an OTT request to the OTT service providing node 200.” [0053], and “the OTT service providing node 200 determines the Global-host-ID and performs a reverse DNS look-up of the IP-address Global-host-ID to determine which operator the host 208 or the CG-NAT node 206 is operated by.” [0053], and “the OTT service providing node 200 queries the DNS server 204 for the IP-address of an OLS (Operator Location Service) node 202 of the present operator.” [0054], and “This is performed by, in an action 3:4, performing a DNS lookup for an SRV (service) record of the operator, and receiving the IP-address and service port number of the operator's OLS in response in following action 3:5.” [0054].
query, by the first network, the DNS for the location information associated with the user device, wherein the one or more databases are updated by the second network, “the OTT service providing node 200 determines the Global-host-ID and performs a reverse DNS look-up of the IP-address Global-host-ID to determine which operator the host 208 or the CG-NAT node 206 is operated by. “ [0053], and “the OTT service providing node 200 queries the DNS server 204 for the IP-address of an OLS (Operator Location Service) node 202 of the present operator.” [0054], and “store and update the geographic location of hosts 208 m in a location server of the communication network when connecting the hosts 208 m” [0048].
receive, at the first network and from the DNS via the one or more databases, the location information associated with the user device, “The LCS 210 then sends stored location information regarding the host 208 to the OLS node 202” [0056], and “the OLS node 202 sends the received location information to the OTT service providing node 200” [0057].
update the emergency session based on the location information, “if the OTT service is an emergency call, the OTT service providing node will automatically retrieve appropriate location information of the host and present to an emergency authority operator substantially simultaneously as he/she answers the emergency call.” [0073]
However, Thyni does not explicitly teach:
wherein data associated with the location information of the user device is maintained by the second network in one or more databases shared between the first network, the second network, and a Domain Name System (DNS);
query the DNS for the location information itself, wherein the one or more databases containing the location information are updated by the second network; or
receive the location information from the DNS via the one or more databases.
Jansen teaches wherein data associated with the location information of the user device is maintained by the second network in one or more databases shared between the first network, the second network, and a Domain Name System (DNS), “Embodiments of the present invention may use DNS servers to allow clients to discover their locations. A DNS server may be configured to store information that indicates the location of client 130 based on an IP address associated with the client 130.” [0041], and “such information is stored within location containers implemented via Text (TXT) records in accordance with existing DNS protocols” [0041], and “The modified B+ tree structure or searchable tree structure 401 may be stored in any type of a data store 470, including databases” [0069], and “Data stores 470 may be distributed throughout a network topology or may be centrally located inside or outside of the network topology” [0071].
query the DNS for the location information itself, wherein the one or more databases containing the location information are updated by the second network, “A DNS server may be configured to store information that indicates the location of client 130 based on an IP address associated with the client 130.” [0041], and “ the client 130 queries a DNS server using its selected IP address 150 (or its only IP address as the case may be) to solicit information useful in determining its location within a network topology, or its general geographic location which is associated with a particular network location or sub-network within the network topology.” [0042], and “When the client queries the DNS server for information, it is specifically querying the DNS server for a TXT record associated with a particular input, such as the IP address 150 or domain name of the client 130.” [0043], and “Tree builder/creator 406 may automatically rebuild or update the B+ tree on a recurring basis” [0074], and “the DNS records that make up the tree are stored in a distributed database D.” [0098], and “Updates to the tree are implemented by making updates (includes addition/removal) to the DNS records that make up the tree” [0098].
receive the location information from the DNS via the one or more databases, “The client 130 query results in the DNS server returning a location container 145, implemented via the DNS TXT record, which contains a list of sub-locations 155 and a location IP address space 160 encompassing the sub-locations.” [0045], and “At block 510, processing logic queries a DNS server for location information associated with the IP address of the client.” [0101], and “The location information received by the client responsive to the DNS query contains a list of sub-locations and a location IP address space which encompasses the sub-locations listed.” [0101].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Thyni’s location retrieval arrangement by incorporating Jansen’s DNS-based location discovery mechanism to provide more efficient access to location information.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Thyni, in view of Jansen, and further in view of Mufti et al. (US 20200162946 A1, hereinafter “Mufti”).
Regarding Claim 2, Thyni and Jansen disclose the limitations of claim 2 as recited above in the rejection of claim 1. However, Thyni and Jansen do not explicitly teach establishing a transmission route for subsequent communications associated with the emergency session between an emergency call session control function (E-CSCF) of the first network and the location information of the second network, wherein the transmission route bypasses the DNS.
Mufti teaches establishing a transmission route for subsequent communications associated with the emergency session between an emergency call session control function (E-CSCF) of the first network and the location information of the second network, wherein the transmission route bypasses the DNS, “When the call request is an emergency call request, the P-CSCF 110 classifies or flags the call request as an emergency call request and selects an E-CSCF 112 in the same network to handle the emergency call request. The E-CSCF 112 communicates with a Location Retrieval Function (“LRF”) 126, which retrieves location information for the UE 102, and obtains routing information (e.g., address of the PSAP) for the emergency call from one or more entities supporting location services as the Gateway Mobile Location Center (“GMLC”) (not shown).” [0018], and further “The E-CSCF 112 may thus send a request 222 to the LRF 126 to retrieve location and/or routing information based on which E-CSCF 112 can redirect the emergency call to the next hop (i.e., BGCF/MGCF or IBCF). “ [0027], and “The LRF 126 may send the location information (UE location) and/or the routing information (PSAP address) 226 to the E-CSCF 112” [0028].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni and Jansen to Mufti by establishing a direct transmission route between the E-CSCF and the location function for subsequent communications to reduce signaling and delay associated with repeated DNS queries.
Regarding Claim 9, Thyni and Jansen disclose the limitations of claim 9 as recited above in the rejection of claim 8. However, Thyni and Jansen do not explicitly teach establish a transmission route for subsequent communications associated with the emergency session between an emergency call session control function (E-CSCF) of the first network and the location information of the second network, wherein the transmission route bypasses the DNS.
Mufti teaches establish a transmission route for subsequent communications associated with the emergency session between an emergency call session control function (E-CSCF) of the first network and the location information of the second network, wherein the transmission route bypasses the DNS, “When the call request is an emergency call request, the P-CSCF 110 classifies or flags the call request as an emergency call request and selects an E-CSCF 112 in the same network to handle the emergency call request. The E-CSCF 112 communicates with a Location Retrieval Function (“LRF”) 126, which retrieves location information for the UE 102, and obtains routing information (e.g., address of the PSAP) for the emergency call from one or more entities supporting location services as the Gateway Mobile Location Center (“GMLC”) (not shown).” [0018], and further “The E-CSCF 112 may thus send a request 222 to the LRF 126 to retrieve location and/or routing information based on which E-CSCF 112 can redirect the emergency call to the next hop (i.e., BGCF/MGCF or IBCF). “ [0027], and “The LRF 126 may send the location information (UE location) and/or the routing information (PSAP address) 226 to the E-CSCF 112” [0028].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni and Jansen to Mufti by establishing a direct transmission route between the E-CSCF and the location function for subsequent communications to reduce signaling and delay associated with repeated DNS queries.
Regarding Claim 16, Thyni and Jansen disclose the limitations of claim 16 as recited above in the rejection of claim 15. However, Thyni and Jansen do not explicitly teach establish a transmission route for subsequent communications associated with the emergency session between an emergency call session control function (E-CSCF) of the first network and the location information of the second network, wherein the transmission route bypasses the DNS.
Mufti teaches establish a transmission route for subsequent communications associated with the emergency session between an emergency call session control function (E-CSCF) of the first network and the location information of the second network, wherein the transmission route bypasses the DNS, “When the call request is an emergency call request, the P-CSCF 110 classifies or flags the call request as an emergency call request and selects an E-CSCF 112 in the same network to handle the emergency call request. The E-CSCF 112 communicates with a Location Retrieval Function (“LRF”) 126, which retrieves location information for the UE 102, and obtains routing information (e.g., address of the PSAP) for the emergency call from one or more entities supporting location services as the Gateway Mobile Location Center (“GMLC”) (not shown).” [0018], and further “The E-CSCF 112 may thus send a request 222 to the LRF 126 to retrieve location and/or routing information based on which E-CSCF 112 can redirect the emergency call to the next hop (i.e., BGCF/MGCF or IBCF). “ [0027], and “The LRF 126 may send the location information (UE location) and/or the routing information (PSAP address) 226 to the E-CSCF 112” [0028].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni and Jansen to Mufti by establishing a direct transmission route between the E-CSCF and the location function for subsequent communications to reduce signaling and delay associated with repeated DNS queries.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Thyni, in view of Jansen, and further in view of Eisner et al. (US 20200187150 A1, hereinafter “Eisner”).
Regarding Claim 3, Thyni and Jansen disclose the limitation of claim 3 as recited above in the rejection of claim 1. However, Thyni and Jansen do not explicitly teach wherein the one or more databases include at least a private database and a public database.
Eisner teaches wherein the one or more databases include at least a private database and a public database, “The location information key data structure includes a database key to a relational database and is usable only by the emergency location application on the emergency location information server.” [0292], and further “The location information key data structure 76 also includes a database key for a relational database 22′ and is usable only by the emergency location application 26′ on the emergency location information server 22 and cannot be decrypted by, the target network device 12, any other target network devices or server network devices.” [0312], and “In FIG. 9C at Step 150, the emergency location application on the emergency location information server network device determines additional location information the target network device from one or more other public location information sources via the communications network using the current physical location of the target network device from the emergency message as a search key for searching the one or more other public location information sources.” [0292], and “In one embodiment, Step 140, further includes the functionality of Step 152 to store the additional location information 155 obtained from public location information data sources 24 about the current physical location 34, 34′, 34″ for the target network device 12 in the created location information key data structure 76.” [0313]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the location-database arrangement of Thyni and Jansen with Eisner by incorporating a private database in addition to a public database to restrict access to sensitive location information.
Regarding Claim 10, Thyni and Jansen disclose the limitation of claim 10 as recited above in the rejection of claim 8. However, Thyni and Jansen do not explicitly teach wherein the one or more databases include at least a private database and a public database.
Eisner teaches wherein the one or more databases include at least a private database and a public database, “The location information key data structure includes a database key to a relational database and is usable only by the emergency location application on the emergency location information server.” [0292], and further “The location information key data structure 76 also includes a database key for a relational database 22′ and is usable only by the emergency location application 26′ on the emergency location information server 22 and cannot be decrypted by, the target network device 12, any other target network devices or server network devices.” [0312], and “In FIG. 9C at Step 150, the emergency location application on the emergency location information server network device determines additional location information the target network device from one or more other public location information sources via the communications network using the current physical location of the target network device from the emergency message as a search key for searching the one or more other public location information sources.” [0292], and “In one embodiment, Step 140, further includes the functionality of Step 152 to store the additional location information 155 obtained from public location information data sources 24 about the current physical location 34, 34′, 34″ for the target network device 12 in the created location information key data structure 76.” [0313]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the location-database arrangement of Thyni and Jansen with Eisner by incorporating a private database in addition to a public database to restrict access to sensitive location information.
Regarding Claim 17, Thyni and Jansen disclose the limitation of claim 17 as recited above in the rejection of claim 15. However, Thyni and Jansen do not explicitly teach wherein the one or more databases include at least a private database and a public database.
Eisner teaches wherein the one or more databases include at least a private database and a public database, “The location information key data structure includes a database key to a relational database and is usable only by the emergency location application on the emergency location information server.” [0292], and further “The location information key data structure 76 also includes a database key for a relational database 22′ and is usable only by the emergency location application 26′ on the emergency location information server 22 and cannot be decrypted by, the target network device 12, any other target network devices or server network devices.” [0312], and “In FIG. 9C at Step 150, the emergency location application on the emergency location information server network device determines additional location information the target network device from one or more other public location information sources via the communications network using the current physical location of the target network device from the emergency message as a search key for searching the one or more other public location information sources.” [0292], and “In one embodiment, Step 140, further includes the functionality of Step 152 to store the additional location information 155 obtained from public location information data sources 24 about the current physical location 34, 34′, 34″ for the target network device 12 in the created location information key data structure 76.” [0313]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the location-database arrangement of Thyni and Jansen with Eisner by incorporating a private database in addition to a public database to restrict access to sensitive location information.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Thyni, in view of Jansen, further in view of Eisner, and further in view of Oracle, Oracle Communication Unified Session Manager Essential Guide, S-CZ8.2.5, April 2021 (hereinafter “Oracle”).
Regarding Claim 4, Thyni, Jansen, and Eisner disclose the limitations of claim 4 as recited above in the rejection of claim 3. However Thyni, Jansen, and Eisner do not explicitly teach wherein the second network updates the private database with the location information of the user device using at least one of a Naming Authority Pointer (NAPTR) record and a Service (SRV) record.
Oracle teaches wherein the second network updates the private database with the location information of the user device using at least one of a Naming Authority Pointer (NAPTR) record and a Service (SRV) record, “When a user initially registers to the Oracle Communications Unified Session Manager, the DDNS update sent to the user database will include a NAPTR record and a TXT record. The NAPTR record contains the Contact: header’s SIP URI as a regexp replacement.” [Chapter 6, page 29-30]”, and further “In some cases, when a user registers a contact from a UA, the Contact: header’s contents are too long to be inserted into the DNS-based user database as presented in the NAPTR record.” [Chapter 6, page 30], and “The Oracle Communications Unified Session Manager provides the encoded string to the DNS server, which then creates the applicable record(s).” [Chapter 6, page 32].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni, Jansen, and Eisner with Oracle by incorporating a NAPTR-based database update mechanism to provide a standardized mechanism for updating the private database.
Regarding Claim 11, Thyni, Jansen, and Eisner disclose the limitations of claim 11 as recited above in the rejection of claim 10. However Thyni, Jansen, and Eisner do not explicitly teach wherein the second network updates the private database with the location information of the user device using at least one of a Naming Authority Pointer (NAPTR) record and a Service (SRV) record.
Oracle teaches wherein the second network updates the private database with the location information of the user device using at least one of a Naming Authority Pointer (NAPTR) record and a Service (SRV) record, “When a user initially registers to the Oracle Communications Unified Session Manager, the DDNS update sent to the user database will include a NAPTR record and a TXT record. The NAPTR record contains the Contact: header’s SIP URI as a regexp replacement.” [Chapter 6, page 29-30]”, and further “In some cases, when a user registers a contact from a UA, the Contact: header’s contents are too long to be inserted into the DNS-based user database as presented in the NAPTR record.” [Chapter 6, page 30], and “The Oracle Communications Unified Session Manager provides the encoded string to the DNS server, which then creates the applicable record(s).” [Chapter 6, page 32].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni, Jansen, and Eisner with Oracle by incorporating a NAPTR-based database update mechanism to provide a standardized mechanism for updating the private database.
Regarding Claim 18, Thyni, Jansen, and Eisner disclose the limitations of claim 18 as recited above in the rejection of claim 17. However Thyni, Jansen, and Eisner do not explicitly teach wherein the second network updates the private database with the location information of the user device using at least one of a Naming Authority Pointer (NAPTR) record and a Service (SRV) record.
Oracle teaches wherein the second network updates the private database with the location information of the user device using at least one of a Naming Authority Pointer (NAPTR) record and a Service (SRV) record, “When a user initially registers to the Oracle Communications Unified Session Manager, the DDNS update sent to the user database will include a NAPTR record and a TXT record. The NAPTR record contains the Contact: header’s SIP URI as a regexp replacement.” [Chapter 6, page 29-30]”, and further “In some cases, when a user registers a contact from a UA, the Contact: header’s contents are too long to be inserted into the DNS-based user database as presented in the NAPTR record.” [Chapter 6, page 30], and “The Oracle Communications Unified Session Manager provides the encoded string to the DNS server, which then creates the applicable record(s).” [Chapter 6, page 32].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni, Jansen, and Eisner with Oracle by incorporating a NAPTR-based database update mechanism to provide a standardized mechanism for updating the private database.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Thyni, in view of Jansen, further in view of Eisner, and further in view of Richardson et al. (US 20110252142 A1, hereinafter “Richardson”).
Regarding Claim 5, Thyni, Jansen, and Eisner disclose the limitations of claim 5 as recited above in the rejection of claim 3. However, Thyni, Jansen, and Eisner do not explicitly teach wherein the second network updates the public database with the location information of the user device using at least a Canonical Name Record (CNAME record).
Richardson teaches wherein the second network updates the public database with the location information of the user device using at least a Canonical Name Record (CNAME record), “In accordance with an illustrative embodiment, the DNS server maintains a data store that defines CNAME records for various original URLs. If a DNS query corresponding to a particular original URL matches an entry in the data store, the DNS server returns a CNAME record as defined in the data store. In an illustrative embodiment, the data store can include multiple CNAME records corresponding to a particular original URL.” [0050], and further “In an illustrative embodiment, each DNS server component 118, 124, 130 maintains the same data stores that define CNAME records, which can be managed centrally by the CDN service provider 106.” [0050], and “the CDN service provider 106 will utilize client location information associated with the client computing device 102 or its local DNS resolver, at least in part, to identify the more appropriate DNS server” [0046].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni, Jansen, and Eisner with Richardson by incorporating a CNAME-based database mechanism to facilitate location-based DNS routing.
Regarding Claim 12, Thyni, Jansen, and Eisner disclose the limitations of claim 12 as recited above in the rejection of claim 10. However, Thyni, Jansen, and Eisner do not explicitly teach wherein the second network updates the public database with the location information of the user device using at least a Canonical Name Record (CNAME record).
Richardson teaches wherein the second network updates the public database with the location information of the user device using at least a Canonical Name Record (CNAME record), “In accordance with an illustrative embodiment, the DNS server maintains a data store that defines CNAME records for various original URLs. If a DNS query corresponding to a particular original URL matches an entry in the data store, the DNS server returns a CNAME record as defined in the data store. In an illustrative embodiment, the data store can include multiple CNAME records corresponding to a particular original URL.” [0050], and further “In an illustrative embodiment, each DNS server component 118, 124, 130 maintains the same data stores that define CNAME records, which can be managed centrally by the CDN service provider 106.” [0050], and “the CDN service provider 106 will utilize client location information associated with the client computing device 102 or its local DNS resolver, at least in part, to identify the more appropriate DNS server” [0046].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni, Jansen, and Eisner with Richardson by incorporating a CNAME-based database mechanism to facilitate location-based DNS routing.
Regarding Claim 19, Thyni, Jansen, and Eisner disclose the limitations of claim 19 as recited above in the rejection of claim 17. However, Thyni, Jansen, and Eisner do not explicitly teach wherein the second network updates the public database with the location information of the user device using at least a Canonical Name Record (CNAME record).
Richardson teaches wherein the second network updates the public database with the location information of the user device using at least a Canonical Name Record (CNAME record), “In accordance with an illustrative embodiment, the DNS server maintains a data store that defines CNAME records for various original URLs. If a DNS query corresponding to a particular original URL matches an entry in the data store, the DNS server returns a CNAME record as defined in the data store. In an illustrative embodiment, the data store can include multiple CNAME records corresponding to a particular original URL.” [0050], and further “In an illustrative embodiment, each DNS server component 118, 124, 130 maintains the same data stores that define CNAME records, which can be managed centrally by the CDN service provider 106.” [0050], and “the CDN service provider 106 will utilize client location information associated with the client computing device 102 or its local DNS resolver, at least in part, to identify the more appropriate DNS server” [0046].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni, Jansen, and Eisner with Richardson by incorporating a CNAME-based database mechanism to facilitate location-based DNS routing.
Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Thyni, in view of Jansen, and further in view of Faccin et al. (US 20060252408 A1, hereinafter ”Faccin”).
Regarding Claim 6, Thyni and Jansen disclose the limitations of claim 6 as recited above in the rejection of claim 1. However, Thyni and Jansen do not explicitly teach wherein the one or more databases includes a MAC address of an access point associated with the user device, the MAC address being indicative of the location information.
Faccin teaches wherein the one or more databases includes a MAC address of an access point associated with the user device, the MAC address being indicative of the location information, “In detail, the WLAN terminal provides the network server (e.g. a 3GPP IMS server) with information identifying the specific Access Point the terminal is associated with, and the network maintains a map/database mapping the information on the AP to a specific location.” [0018], and “In detail, one possible implementation of the first embodiment is based on the WLAN terminal using the MAC address of the WLAN Access Point (AP) to identify the AP and send this MAC address to the network.” [0019], and “There is a need for the network operator to maintain a database in the network containing the identity of the AP, that is the MAC address, and the corresponding location of all specific WLAN APs. In this way, the network can determine the location of the AP.” [0021].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni and Jansen with Faccin by using an access-point MAC address to identify the location associated with the user device.
Regarding Claim 13, Thyni and Jansen disclose the limitations of claim 13 as recited above in the rejection of claim 8. However, Thyni and Jansen do not explicitly teach wherein the one or more databases includes a MAC address of an access point associated with the user device, the MAC address being indicative of the location information.
Faccin teaches wherein the one or more databases includes a MAC address of an access point associated with the user device, the MAC address being indicative of the location information, “In detail, the WLAN terminal provides the network server (e.g. a 3GPP IMS server) with information identifying the specific Access Point the terminal is associated with, and the network maintains a map/database mapping the information on the AP to a specific location.” [0018], and “In detail, one possible implementation of the first embodiment is based on the WLAN terminal using the MAC address of the WLAN Access Point (AP) to identify the AP and send this MAC address to the network.” [0019], and “There is a need for the network operator to maintain a database in the network containing the identity of the AP, that is the MAC address, and the corresponding location of all specific WLAN APs. In this way, the network can determine the location of the AP.” [0021].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni and Jansen with Faccin by using an access-point MAC address to identify the location associated with the user device.
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Thyni, in view of Jansen, and further in view of Garskof (US 20110092185 A1, hereinafter “Garskof”).
Regarding Claim 7, Thyni and Jansen disclose the limitations of claim 7 as recited above in the rejection of claim 1. However, Thyni and Jansen do not explicitly teach wherein the one or more databases includes a short-lived device-specific location tag that is indicative of the location information of the user device.
Garskof teaches wherein the one or more databases includes a short-lived device-specific location tag that is indicative of the location information of the user device, “At login time, the mobile device provides to the LTS server, by way of the LTS client application, the UUID, TN, and the initial location information of the mobile device, in addition to the user ID and password. The LTS server records this authentication data as a session for the mobile device. The mobile device then uses the UUID, TN, and present location information as a secure token to provide the identity of the user.” [0010], and “In some embodiments, the threshold distance is supplemented with a temporal threshold such that the mobile device 100 is required to re-authenticate if the mobile device 100 travels a certain distance within a certain time.” [0052], and “In some embodiments, the LTS keys are static and have no expiration time. In other embodiments, the LTS keys are static and valid only for a specified time. In still other embodiments, the LTS keys are dynamic and periodically generated by the LTS server 200.” [0045].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni and Jansen with Garskof by using a short-lived device-specific location tag to provide current device-location information.
Regarding Claim 14, Thyni and Jansen disclose the limitations of claim 14 as recited above in the rejection of claim 8. However, Thyni and Jansen do not explicitly teach wherein the one or more databases includes a short-lived device-specific location tag that is indicative of the location information of the user device.
Garskof teaches wherein the one or more databases includes a short-lived device-specific location tag that is indicative of the location information of the user device, “At login time, the mobile device provides to the LTS server, by way of the LTS client application, the UUID, TN, and the initial location information of the mobile device, in addition to the user ID and password. The LTS server records this authentication data as a session for the mobile device. The mobile device then uses the UUID, TN, and present location information as a secure token to provide the identity of the user.” [0010], and “In some embodiments, the threshold distance is supplemented with a temporal threshold such that the mobile device 100 is required to re-authenticate if the mobile device 100 travels a certain distance within a certain time.” [0052], and “In some embodiments, the LTS keys are static and have no expiration time. In other embodiments, the LTS keys are static and valid only for a specified time. In still other embodiments, the LTS keys are dynamic and periodically generated by the LTS server 200.” [0045].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni and Jansen with Garskof by using a short-lived device-specific location tag to provide current device-location information.
Regarding Claim 20, Thyni and Jansen disclose the limitations of claim 20 as recited above in the rejection of claim 15. However, Thyni and Jansen do not explicitly teach wherein the one or more databases includes a short-lived device-specific location tag that is indicative of the location information of the user device.
Garskof teaches wherein the one or more databases includes a short-lived device-specific location tag that is indicative of the location information of the user device, “At login time, the mobile device provides to the LTS server, by way of the LTS client application, the UUID, TN, and the initial location information of the mobile device, in addition to the user ID and password. The LTS server records this authentication data as a session for the mobile device. The mobile device then uses the UUID, TN, and present location information as a secure token to provide the identity of the user.” [0010], and “In some embodiments, the threshold distance is supplemented with a temporal threshold such that the mobile device 100 is required to re-authenticate if the mobile device 100 travels a certain distance within a certain time.” [0052], and “In some embodiments, the LTS keys are static and have no expiration time. In other embodiments, the LTS keys are static and valid only for a specified time. In still other embodiments, the LTS keys are dynamic and periodically generated by the LTS server 200.” [0045].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Thyni and Jansen with Garskof by using a short-lived device-specific location tag to provide current device-location information.
Conclusion
The prior art made of record not relied upon and considered pertinent to Applicant’s disclosure:
Annamalai et al. (US 20170325192 A1) - Determining device location in an ip-based wireless telecommunications network, discloses system and method determines a geographic position of a mobile device in communication with an IP-based wireless telecommunications network. A wireless connection between the mobile device and the IP-based wireless telecommunications network is established when the mobile device registers with a network controller (NC) through an access point (AP). When a geographical position is needed for the mobile device (e.g., a 911 call), messages are exchanged between the NC and the SMLC where the SMLC retrieves information from a database that is used to identify the geographic position of the mobile device. The database can store a variety of information related to mobile devices such as: last known position, IP address, MAC address, device or subscriber identifier, last CGI, etc. The geographical position is communicated back to the NC, which can then forward the position information to a switch for processing such as for 911 calls.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GOLAM SOROWAR whose telephone number is (571)270-3761. The examiner can normally be reached Mon-Fri: 8:30AM-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, Charles Appiah can be reached at (571) 272-7904. 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.
/GOLAM SOROWAR/ Primary Examiner, Art Unit 2641
Prosecution Insights