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 .
Introduction
The claims 1-20 are pending in this application. This is a non-final office action in response to Application Number 18/826,839 filed on 6 September 2024. The applicant of record is Oracle International Corporation and the inventors of record are Virendra Singh, Uri Baniel, and Shashikiran Mahalank.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 13 January 2026 was filed after the initial filing date of the instant application on 6 September 2024 and before the mailing date of the first office action on the merits. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation
The claims have been considered according to the latest Patent Eligibility Guidelines and are considered eligible.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hallenstål (U.S. Patent Publication 2022/0240172).
Regarding claim 1, Hallenstål disclosed a computing apparatus comprising:
a computer-readable storage medium (see Hallenstål Fig. 7 memory);
processor-executable instructions stored on the computer-readable storage medium (see Hallenstål Fig. 7 processor, memory); and
one or more processors coupled to the computer-readable storage medium and configured to execute the processor-executable instructions (see Hallenstål Fig. 7 processor, memory) to operate a first network function (NF) within a first network, wherein the first NF comprises an inter-domain engine, such that the processor- executable instructions, when executed by the one or more processors, direct the computing apparatus, to (see Hallenstål Fig. 4, [0122]: “Fig. 4 discloses an improved solution for inter PLMN discovery”) at least:
determine a first service request from a visitor consumer NF, wherein the first NF is in a first network and the visitor consumer NF is in a second network (see Hallenstål Fig. 4 #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP”);
determine a service response based on the first service request, wherein the service response comprises NF topology information for furnishing the service request within the first network (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query. The address may, e.g., be comprised in an NF profile for the NF service producer 130…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”);
generate, by the inter-domain engine (see Hallenstål Fig. 6: first network node), a mask NF profile based on the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…”);
generate, by the inter-domain engine (see Hallenstål Fig. 6: first network node), a mask service response based on the mask NF profile and the first service request (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”); and
transmit the mask service response to the visitor consumer NF (see Hallenstål [0127]: “…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”; Fig. 4 #406, [0128]: “The first network node 110 sends the response representing the address of the NF service producer node 130 to the second network node 111”).
Regarding claim 2, Hallenstål disclosed the computing apparatus of claim 1, wherein the processor-executable instructions, when executed by the one or more processors, further direct the computing apparatus to:
generate, by the inter-domain engine, a mask mapping of the mask NF profile to the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…In the known solution, the pSEPP further stores a mapping table, in which the changed address forwarded to the cSEPP is mapped to the corresponding actual service address of the NF service producer. The mapping table has to be continuously updated for every requested service. The mapping table are long lived and thus needs to be stored redundantly…);
determine, by the inter-domain engine, a validity period for the service response (see Hallenstål Fig. 4 #405, [0127]: “…In the known solution, the pSEPP further stores a mapping table, in which the changed address forwarded to the cSEPP is mapped to the corresponding actual service address of the NF service producer. The mapping table has to be continuously updated for every requested service. The mapping table are long lived and thus needs to be stored redundantly…”, i.e. the validity period is the duration of the requested service); and
store, by the inter-domain engine, the mask mapping and the service response for the validity period of the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…In the known solution, the pSEPP further stores a mapping table, in which the changed address forwarded to the cSEPP is mapped to the corresponding actual service address of the NF service producer. The mapping table has to be continuously updated for every requested service. The mapping table are long lived and thus needs to be stored redundantly…”).
Regarding claim 3, Hallenstål disclosed the computing apparatus of claim 1, wherein the processor-executable instructions to generate, by the inter-domain engine, the mask NF profile based on the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…”), when executed by the one or more processors, further direct the computing apparatus to:
determine, by the inter-domain engine, one or more NF profile properties of the NF topology information from the service response (see Hallenstål [0013]: “…The hNRF then answers with one or several NF profiles of the NFs that matches the discovery query. This answer is sent to the pSEPP, which may do topology hiding by altering the FQDNs of the NF profile(s). In case of topology hiding, the pSEPP requires a mapping table between the altered FQDN (FQDN.sub.pSEPP) and the actual FQDN (FQDN.sub.NFservice) of the NF service(s).” | Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110…The first network node 110 may e.g. be pSEPP, and the address may thus simply be psepp.sepp1.mnc1.mcc1.3gpp.org. The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”); and
generate, by the inter-domain engine, the mask NF profile based on the one or more NF profile properties and endpoint information of the first NF (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110…The first network node 110 may e.g. be pSEPP, and the address may thus simply be psepp.sepp1.mnc1.mcc1.3gpp.org. The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”).
Regarding claim 4, Hallenstål disclosed the computing apparatus of claim 1, wherein the first service request comprises a discovery request (see Hallenstål Fig. 4 #402, [0124]: “The vNRF may determine that the discovery request is for a NF service producer 130 in the hPLMN and may send the discovery request, such as the Nnrf_NFDiscovery_Request, towards the hNRF…”; #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP”) and the service response comprises a discovery response (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”), and the processor- executable instructions to determine the service response based on the first service request (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query. The address may, e.g., be comprised in an NF profile for the NF service producer 130…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”), when executed by the one or more processors, further direct the computing apparatus to:
forward the discovery request received from the visitor consumer NF to a Home Repository Function (NRF) in the first network (see Hallenstål Fig. 4 #402, [0124]: “The vNRF may determine that the discovery request is for a NF service producer 130 in the hPLMN and may send the discovery request, such as the Nnrf_NFDiscovery_Request, towards the hNRF…”; #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP” | [0013]: “When a service consumer, such as e.g. a UE, in a vPLMN wants to access a service located in the hPLMN, the service consumer sends a discovery request to a visited Network Repository Function (vNRF) in the vPLMN. The vNRF sees that this request is for roaming, and sends the discovery request to a consumer Security Edge Protection Proxy (cSEPP) which is the SEPP located in the vPLMN. The cSEPP sends a message to a producer SEPP (pSEPP) located in the hPLMN of the service consumer and the pSEPP forwards the discovery request to a home Network Repository Function (hNRF) in the hPLMN. The hNRF then answers with one or several NF profiles of the NFs that matches the discovery query. This answer is sent to the pSEPP…”); and
receive, from the NRF, the discovery response from the NRF, wherein the NRF determines the NF topology information for servicing the discovery request (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query. The address may, e.g., be comprised in an NF profile for the NF service producer 130…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130” | Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…”).
Regarding claim 5, Hallenstål disclosed the computing apparatus of claim 1, wherein the processor-executable instructions, when executed by the one or more processors, further direct the computing apparatus to:
receive a second service request from the visitor consumer NF (see Hallenstål Fig. 4 #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP” | Fig. 5 #501, [0132]: “The NF service consumer node 120 may send a request to a service instance of service x in the NF producer 130. Previously, the request would have comprised the individual labels for each service as provided by the first network node 110. According to the embodiments herein however, the NF service consumer 120 constructs a resource URI from the received information, which may e.g. be comprised in the NF profile. The information may e.g. be received according to the scheme, fqdn or ipEndPoints and apiPrefix received in NFService in NFprofile…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
determine, by the inter-domain engine, the mask NF profile based on the second service request (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…”; [0127]: “The first network node 110 may perform topology hiding…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…” | Fig. 5 #504, [0135]: “In the previous solution, the first network node 110 would have retrieved the address of the NF service producer 130 from the mapping table based on the received URI from the second network node 111. According to the embodiments herein however, when the first network node 110 has received the request it translates the part of the URI path to the address of the NF service producer 130, e.g. by removing its own address from the URI…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
determine, by the inter-domain engine, the service response associated with the second service request based on the mask NF profile (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”; [0127]: “The first network node 110 may perform topology hiding…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…” | Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”; #506, [0137]: “When the service request has created a resource in the NF service producer 130, then the NF service producer 130 sends a response to the first network node 110 and indicates the resource URI, e.g. in a location parameter in HTTP…”); and
route the second service request to one or more producer NFs in the first network based on the service response, wherein the one or more producer NFs furnish the second service request responsive to receiving the second service request (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”; #506, [0137]: “When the service request has created a resource in the NF service producer 130, then the NF service producer 130 sends a response to the first network node 110 and indicates the resource URI, e.g. in a location parameter in HTTP…”).
Regarding claim 6, Hallenstål disclosed the computing apparatus of claim 1, wherein the processor-executable instructions, when executed by the one or more processors, further direct the computing apparatus to:
receive a second service request from the visitor consumer NF (see Hallenstål Fig. 4 #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP” | Fig. 5 #501, [0132]: “The NF service consumer node 120 may send a request to a service instance of service x in the NF producer 130. Previously, the request would have comprised the individual labels for each service as provided by the first network node 110. According to the embodiments herein however, the NF service consumer 120 constructs a resource URI from the received information, which may e.g. be comprised in the NF profile. The information may e.g. be received according to the scheme, fqdn or ipEndPoints and apiPrefix received in NFService in NFprofile…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
map, by the inter-domain engine, the second service request to the mask NF profile (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…”; [0127]: “The first network node 110 may perform topology hiding…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…” | Fig. 5 #504, [0135]: “In the previous solution, the first network node 110 would have retrieved the address of the NF service producer 130 from the mapping table based on the received URI from the second network node 111. According to the embodiments herein however, when the first network node 110 has received the request it translates the part of the URI path to the address of the NF service producer 130, e.g. by removing its own address from the URI…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
determine, by the inter-domain engine, the NF topology information of the service response associated with the mask NF profile (see Hallenstål Fig. 5 #504, [0135]: “In the previous solution, the first network node 110 would have retrieved the address of the NF service producer 130 from the mapping table based on the received URI from the second network node 111. According to the embodiments herein however, when the first network node 110 has received the request it translates the part of the URI path to the address of the NF service producer 130, e.g. by removing its own address from the URI…”); and
transmit, by the first NF, the second service request and the NF topology information to a second NF within the first network (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”), wherein the second NF performs one of:
NF selection; or routing of the second service request based on the NF topology information (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”; #506, [0137]: “When the service request has created a resource in the NF service producer 130, then the NF service producer 130 sends a response to the first network node 110 and indicates the resource URI, e.g. in a location parameter in HTTP…”).
Regarding claim 7, Hallenstål disclosed the computing apparatus of claim 1, wherein the first NF comprises a Security Edge Protection Proxy (SEPP) within the first network (see Hallenstål [0013]: “When a service consumer, such as e.g. a UE, in a vPLMN wants to access a service located in the hPLMN, the service consumer sends a discovery request to a visited Network Repository Function (vNRF) in the vPLMN. The vNRF sees that this request is for roaming, and sends the discovery request to a consumer Security Edge Protection Proxy (cSEPP) which is the SEPP located in the vPLMN. The cSEPP sends a message to a producer SEPP (pSEPP) located in the hPLMN of the service consumer and the pSEPP forwards the discovery request to a home Network Repository Function (hNRF) in the hPLMN. The hNRF then answers with one or several NF profiles of the NFs that matches the discovery query. This answer is sent to the pSEPP…” | Fig. 4 “pSEPP”, Fig. 5 #110).
Regarding claim 8, the claim contains the limitations, substantially as claimed, as described in claim 1 above. Examiner notes that claim 1 is directed to a computing apparatus whereas claim 8 is directed to a method. Hallenstål disclosed, as recited in claim 8: A method (see Hallenstål Fig. 4, [0122]: “Fig. 4 discloses an improved solution for inter PLMN discovery”) comprising:
determining, by a first network function (NF), a first service request from a visitor consumer NF, wherein the first NF is in a first network and the visitor consumer NF is in a second network (see Hallenstål Fig. 4 #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP”);
determining, by the first NF, a service response based on the first service request, wherein the service response comprises NF topology information for furnishing the service request within the first network (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query. The address may, e.g., be comprised in an NF profile for the NF service producer 130…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”);
generating, by an inter-domain engine of the first NF (see Hallenstål Fig. 6: first network node), a mask NF profile based on the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…”);
generating, by the inter-domain engine (see Hallenstål Fig. 6: first network node), a mask service response based on the mask NF profile and the first service request (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”); and
transmitting, by the first NF, the mask service response to the visitor consumer NF (see Hallenstål [0127]: “…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”; Fig. 4 #406, [0128]: “The first network node 110 sends the response representing the address of the NF service producer node 130 to the second network node 111”).
Regarding claim 9, the claim contains the limitations, substantially as claimed, as described in claim 5 above. Hallenstål disclosed, as recited in claim 9: The method of claim 8, wherein the method further comprises:
receiving, by the first NF, a second service request from the visitor consumer NF (see Hallenstål Fig. 4 #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP” | Fig. 5 #501, [0132]: “The NF service consumer node 120 may send a request to a service instance of service x in the NF producer 130. Previously, the request would have comprised the individual labels for each service as provided by the first network node 110. According to the embodiments herein however, the NF service consumer 120 constructs a resource URI from the received information, which may e.g. be comprised in the NF profile. The information may e.g. be received according to the scheme, fqdn or ipEndPoints and apiPrefix received in NFService in NFprofile…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
determining, by the inter-domain engine, the mask NF profile based on the second service request (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…”; [0127]: “The first network node 110 may perform topology hiding…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…” | Fig. 5 #504, [0135]: “In the previous solution, the first network node 110 would have retrieved the address of the NF service producer 130 from the mapping table based on the received URI from the second network node 111. According to the embodiments herein however, when the first network node 110 has received the request it translates the part of the URI path to the address of the NF service producer 130, e.g. by removing its own address from the URI…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
determining, by the inter-domain engine, the service response associated with the second service request based on the mask NF profile (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”; [0127]: “The first network node 110 may perform topology hiding…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…” | Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”; #506, [0137]: “When the service request has created a resource in the NF service producer 130, then the NF service producer 130 sends a response to the first network node 110 and indicates the resource URI, e.g. in a location parameter in HTTP…”);
determining, by the inter-domain engine, a producer NF in the first network for furnishing the second service request based on the service response (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”); and
routing, by the first NF, the second service request to the producer NF, wherein the producer NF furnishes the second service request responsive to receiving the second service request (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”; #506, [0137]: “When the service request has created a resource in the NF service producer 130, then the NF service producer 130 sends a response to the first network node 110 and indicates the resource URI, e.g. in a location parameter in HTTP…”).
Regarding claim 10, the claim contains the limitations, substantially as claimed, as described in claim 6 above. Hallenstål disclosed, as recited in claim 10: The method of claim 8, wherein the method further comprises:
receiving, by the first NF, a second service request from the visitor consumer NF (see Hallenstål Fig. 4 #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP” | Fig. 5 #501, [0132]: “The NF service consumer node 120 may send a request to a service instance of service x in the NF producer 130. Previously, the request would have comprised the individual labels for each service as provided by the first network node 110. According to the embodiments herein however, the NF service consumer 120 constructs a resource URI from the received information, which may e.g. be comprised in the NF profile. The information may e.g. be received according to the scheme, fqdn or ipEndPoints and apiPrefix received in NFService in NFprofile…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
mapping, by the inter-domain engine, the second service request to the mask NF profile (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…”; [0127]: “The first network node 110 may perform topology hiding…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…” | Fig. 5 #504, [0135]: “In the previous solution, the first network node 110 would have retrieved the address of the NF service producer 130 from the mapping table based on the received URI from the second network node 111. According to the embodiments herein however, when the first network node 110 has received the request it translates the part of the URI path to the address of the NF service producer 130, e.g. by removing its own address from the URI…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
determining, by the inter-domain engine, the NF topology information of the service response associated with the mask NF profile (see Hallenstål Fig. 5 #504, [0135]: “In the previous solution, the first network node 110 would have retrieved the address of the NF service producer 130 from the mapping table based on the received URI from the second network node 111. According to the embodiments herein however, when the first network node 110 has received the request it translates the part of the URI path to the address of the NF service producer 130, e.g. by removing its own address from the URI…”); and
transmitting, by the first NF, the second service request and the NF topology information to a second NF within the first network (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”), wherein the second NF performs one of:
NF selection; or routing of the second service request based on the NF topology information (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”; #506, [0137]: “When the service request has created a resource in the NF service producer 130, then the NF service producer 130 sends a response to the first network node 110 and indicates the resource URI, e.g. in a location parameter in HTTP…”).
Regarding claim 11, the claim contains the limitations, substantially as claimed, as described in claim 2 above. Examiner notes that claim 11 has a broader scope than that of claim 2. Hallenstål disclosed, as recited in claim 11: The method of claim 8, wherein the method further comprises:
generating, by the inter-domain engine, a mask mapping of the mask NF profile to the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…In the known solution, the pSEPP further stores a mapping table, in which the changed address forwarded to the cSEPP is mapped to the corresponding actual service address of the NF service producer. The mapping table has to be continuously updated for every requested service. The mapping table are long lived and thus needs to be stored redundantly…); and
storing, by the inter-domain engine, the mask mapping and the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…In the known solution, the pSEPP further stores a mapping table, in which the changed address forwarded to the cSEPP is mapped to the corresponding actual service address of the NF service producer. The mapping table has to be continuously updated for every requested service. The mapping table are long lived and thus needs to be stored redundantly…”).
Regarding claim 12, Hallenstål disclosed the method of claim 8, wherein the mask NF profile comprises endpoint information for the first NF corresponding to the respective NF topology information in the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110…The first network node 110 may e.g. be pSEPP, and the address may thus simply be psepp.sepp1.mnc1.mcc1.3gpp.org. The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”).
Regarding claim 13, the claim contains the limitations, substantially as claimed, as described in claim 4 above. Hallenstål disclosed, as recited in claim 13: The method of claim 8, wherein:
the first service request comprises a discovery request (see Hallenstål Fig. 4 #402, [0124]: “The vNRF may determine that the discovery request is for a NF service producer 130 in the hPLMN and may send the discovery request, such as the Nnrf_NFDiscovery_Request, towards the hNRF…”; #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP”);
the service response comprises a discovery response (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”); and
determining, by the first NF, the service response based on the first service request (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query. The address may, e.g., be comprised in an NF profile for the NF service producer 130…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”) further comprises:
forwarding, by the first NF, the discovery request received from the visitor consumer NF to a Home Repository Function (NRF) in the first network (see Hallenstål Fig. 4 #402, [0124]: “The vNRF may determine that the discovery request is for a NF service producer 130 in the hPLMN and may send the discovery request, such as the Nnrf_NFDiscovery_Request, towards the hNRF…”; #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP” | [0013]: “When a service consumer, such as e.g. a UE, in a vPLMN wants to access a service located in the hPLMN, the service consumer sends a discovery request to a visited Network Repository Function (vNRF) in the vPLMN. The vNRF sees that this request is for roaming, and sends the discovery request to a consumer Security Edge Protection Proxy (cSEPP) which is the SEPP located in the vPLMN. The cSEPP sends a message to a producer SEPP (pSEPP) located in the hPLMN of the service consumer and the pSEPP forwards the discovery request to a home Network Repository Function (hNRF) in the hPLMN. The hNRF then answers with one or several NF profiles of the NFs that matches the discovery query. This answer is sent to the pSEPP…”); and
receiving, from the NRF, the discovery response from the NRF, wherein the NRF determines the NF topology information for servicing the discovery request (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query. The address may, e.g., be comprised in an NF profile for the NF service producer 130…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130” | Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…”).
Regarding claim 14, Hallenstål disclosed the method of claim 8, wherein the first network comprises a first Public Land Mobile Network (PLMN) and the second network comprises a second PLMN (see Hallenstål Fig. 4, [0122]: “Fig. 4 discloses an improved solution for inter PLMN discovery” | [0041]: “The communications network may comprise one or more Public Land Mobile Networks (PLMNs). The PLMNs may be run by different operators and when a subscribed user uses his operator's PLMN then this PLMN may be referred to as a Home-PLMN (hPLMN). Roaming however allows users to move outside their home network and to use resources from other operator's network. Such a network operated by a different operator than the subscribed operator may be referred to as a Visited-PLMN (vPLMN).”).
Regarding claim 15, the claim contains the limitations, substantially as claimed, as described in claim 7 above. Hallenstål disclosed, as recited in claim 15: The method of claim 8, wherein the first NF comprises a Security Edge Protection Proxy (SEPP) within the first network (see Hallenstål [0013]: “When a service consumer, such as e.g. a UE, in a vPLMN wants to access a service located in the hPLMN, the service consumer sends a discovery request to a visited Network Repository Function (vNRF) in the vPLMN. The vNRF sees that this request is for roaming, and sends the discovery request to a consumer Security Edge Protection Proxy (cSEPP) which is the SEPP located in the vPLMN. The cSEPP sends a message to a producer SEPP (pSEPP) located in the hPLMN of the service consumer and the pSEPP forwards the discovery request to a home Network Repository Function (hNRF) in the hPLMN. The hNRF then answers with one or several NF profiles of the NFs that matches the discovery query. This answer is sent to the pSEPP…” | Fig. 4 “pSEPP”, Fig. 5 #110).
Regarding claim 16, the claim contains the limitations, substantially as claimed, as described in claim 1 above. Examiner notes that claim 1 is directed to a computing apparatus whereas claim 16 is directed to a computer-readable storage medium. Hallenstål disclosed, as recited in claim 16: A computer-readable storage medium (see Hallenstål Fig. 7 memory) comprising processor-executable instructions (see Hallenstål Fig. 7 processor, memory), wherein the processor-executable instructions, in part, operate a first network function (NF) within a first network such to cause one or more processors to (see Hallenstål Fig. 4, [0122]: “Fig. 4 discloses an improved solution for inter PLMN discovery”):
determine a first service request from a visitor consumer NF, wherein the visitor consumer NF is in a second network that is different than the first network (see Hallenstål Fig. 4 #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP”);
determine a service response based on the first service request, wherein the service response comprises NF topology information for furnishing the service request within the first network (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query. The address may, e.g., be comprised in an NF profile for the NF service producer 130…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”);
generate, by an inter-domain engine (see Hallenstål Fig. 6: first network node), a mask NF profile based on the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…”);
generate, by the inter-domain engine (see Hallenstål Fig. 6: first network node), a mask service response based on the mask NF profile and the first service request (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”); and
transmit the mask service response to the visitor consumer NF (see Hallenstål [0127]: “…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”; Fig. 4 #406, [0128]: “The first network node 110 sends the response representing the address of the NF service producer node 130 to the second network node 111”).
Regarding claim 17, Hallenstål disclosed the computer-readable storage medium of claim 16, wherein the processor- executable instructions to generate, by the inter-domain engine, the mask NF profile based on the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…This may be done by changing the addresses comprised in the NF profile prior to forwarding the response to the cSEPP node…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110. This may be done by encrypting the original address using a symmetric crypto and append the encrypted address to the apiPrefix…”) cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to:
determine, by the inter-domain engine, an NF profile comprising one or more NF profile properties (see Hallenstål [0013]: “…The hNRF then answers with one or several NF profiles of the NFs that matches the discovery query. This answer is sent to the pSEPP, which may do topology hiding by altering the FQDNs of the NF profile(s). In case of topology hiding, the pSEPP requires a mapping table between the altered FQDN (FQDN.sub.pSEPP) and the actual FQDN (FQDN.sub.NFservice) of the NF service(s).” | Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110…The first network node 110 may e.g. be pSEPP, and the address may thus simply be psepp.sepp1.mnc1.mcc1.3gpp.org. The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”); and
generate, by the inter-domain engine, the mask NF profile based on the one or more NF profile properties and endpoint information of the first NF (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110…The first network node 110 may e.g. be pSEPP, and the address may thus simply be psepp.sepp1.mnc1.mcc1.3gpp.org. The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”), wherein the endpoint information of the first NF comprises at least one of:
a scheme associated with the first NF;
a Fully Qualified Domain Name (FQDN) associated with the first NF (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding…According to the embodiments herein however, the topology hiding may be performed by adding the original address, such as the FQDN, of the NF service producer 130 address path of the first network node 110…The first network node 110 may e.g. be pSEPP, and the address may thus simply be psepp.sepp1.mnc1.mcc1.3gpp.org. The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…”);
a port associated with the first NF; or
an Application Programming Interface (API) prefix associated with the first NF.
Regarding claim 18, the claim contains the limitations, substantially as claimed, as described in claim 9 above. Hallenstål disclosed, as recited in claim 18: The computer-readable storage medium of claim 16, wherein the processor- executable instructions cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to:
receive a second service request from the visitor consumer NF (see Hallenstål Fig. 4 #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP” | Fig. 5 #501, [0132]: “The NF service consumer node 120 may send a request to a service instance of service x in the NF producer 130. Previously, the request would have comprised the individual labels for each service as provided by the first network node 110. According to the embodiments herein however, the NF service consumer 120 constructs a resource URI from the received information, which may e.g. be comprised in the NF profile. The information may e.g. be received according to the scheme, fqdn or ipEndPoints and apiPrefix received in NFService in NFprofile…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
map, by the inter-domain engine, the second service request to the mask NF profile (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…”; [0127]: “The first network node 110 may perform topology hiding…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…” | Fig. 5 #504, [0135]: “In the previous solution, the first network node 110 would have retrieved the address of the NF service producer 130 from the mapping table based on the received URI from the second network node 111. According to the embodiments herein however, when the first network node 110 has received the request it translates the part of the URI path to the address of the NF service producer 130, e.g. by removing its own address from the URI…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
determine, by the inter-domain engine, the service response associated with the second service request based on the mask NF profile (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…The first network node 110 may receive a response message from the hNRF, comprising a NF profile of the NF service producer 130”; [0127]: “The first network node 110 may perform topology hiding…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…” | Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”; #506, [0137]: “When the service request has created a resource in the NF service producer 130, then the NF service producer 130 sends a response to the first network node 110 and indicates the resource URI, e.g. in a location parameter in HTTP…”);
determine, by the inter-domain engine, a producer NF in the first network for furnishing the second service request based on the service response (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”); and
route, by the first NF, the second service request to the producer NF, wherein the producer NF furnishes the second service request responsive to receiving the second service request (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”; #506, [0137]: “When the service request has created a resource in the NF service producer 130, then the NF service producer 130 sends a response to the first network node 110 and indicates the resource URI, e.g. in a location parameter in HTTP…”).
Regarding claim 19, the claim contains the limitations, substantially as claimed, as described in claim 6 above. Hallenstål disclosed, as recited in claim 19: The computer-readable storage medium of claim 16, wherein the processor- executable instructions cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to:
receive a second service request from the visitor consumer NF (see Hallenstål Fig. 4 #403, [0125]: “second network node 111 located in the vPLMN, such as the cSEPP, forwards the request to the first network node 110 located in the hPLMN, such as the pSEPP” | Fig. 5 #501, [0132]: “The NF service consumer node 120 may send a request to a service instance of service x in the NF producer 130. Previously, the request would have comprised the individual labels for each service as provided by the first network node 110. According to the embodiments herein however, the NF service consumer 120 constructs a resource URI from the received information, which may e.g. be comprised in the NF profile. The information may e.g. be received according to the scheme, fqdn or ipEndPoints and apiPrefix received in NFService in NFprofile…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
map, by the inter-domain engine, the second service request to the mask NF profile (see Hallenstål Fig. 4 #404, [0126]: “The first network node 110 retrieves an address of one or more NF service producers 130 matching the discovery query…”; [0127]: “The first network node 110 may perform topology hiding…The created information may be comprised in the elements fqdn and apiPrefix in NFService in the NFProfile…” | Fig. 5 #504, [0135]: “In the previous solution, the first network node 110 would have retrieved the address of the NF service producer 130 from the mapping table based on the received URI from the second network node 111. According to the embodiments herein however, when the first network node 110 has received the request it translates the part of the URI path to the address of the NF service producer 130, e.g. by removing its own address from the URI…”; #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”);
determine, by the inter-domain engine, the NF topology information of the service response associated with the mask NF profile (see Hallenstål Fig. 5 #504, [0135]: “In the previous solution, the first network node 110 would have retrieved the address of the NF service producer 130 from the mapping table based on the received URI from the second network node 111. According to the embodiments herein however, when the first network node 110 has received the request it translates the part of the URI path to the address of the NF service producer 130, e.g. by removing its own address from the URI…”); and
transmit the second service request and the NF topology information to a Service Communication Proxy (SCP) within the first network (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”), wherein the SCP performs one of:
NF selection or routing of the second service request based on the NF topology information (see Hallenstål Fig. 5 #505, [0136]: “The first network node 110, such as the pSEPP, sends the request to the indicated address, in this case to the NF service producer node 130.”; #506, [0137]: “When the service request has created a resource in the NF service producer 130, then the NF service producer 130 sends a response to the first network node 110 and indicates the resource URI, e.g. in a location parameter in HTTP…”).
Regarding claim 20, the claim contains the limitations, substantially as claimed, as described in claim 2 above. Hallenstål disclosed, as recited in claim 20: The computer-readable storage medium of claim 16, wherein the processor- executable instructions cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to:
generate, by the inter-domain engine, a mask mapping of the mask NF profile to the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…In the known solution, the pSEPP further stores a mapping table, in which the changed address forwarded to the cSEPP is mapped to the corresponding actual service address of the NF service producer. The mapping table has to be continuously updated for every requested service. The mapping table are long lived and thus needs to be stored redundantly…); and
store, by the inter-domain engine, the mask mapping and the service response for a validity period of the service response (see Hallenstål Fig. 4 #405, [0127]: “The first network node 110 may perform topology hiding. According to the known solution, the topology hiding was performed by altering the FQDNs of the NF profile(s), and creating a mapping table…In the known solution, the pSEPP further stores a mapping table, in which the changed address forwarded to the cSEPP is mapped to the corresponding actual service address of the NF service producer. The mapping table has to be continuously updated for every requested service. The mapping table are long lived and thus needs to be stored redundantly…”, i.e. the validity period is the duration of the requested service).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Angela Widhalm de Rodriguez whose telephone number is (571)272-1035. The examiner can normally be reached M-F: 6am-2:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nicholas Taylor can be reached at (571)272-3889. 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.
/ANGELA WIDHALM DE RODRIGUEZ/ Examiner, Art Unit 2443
Prosecution Insights