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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 5, 7, 9-11, 15, 17 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Khare US Patent No.: 11,533,358 in view of 3GPP TS 29.500 V18.3.0 (2023-09), hereinafter, ‘3GPP’.
Consider Claim 11 and as applied to claim 1, and claim 20, Khare teaches a system for detecting and processing egress inter-public land mobile network (inter-PLMN) service-based interface (SBI) request messages without 3gpp-Sbi-Originating-Network-Id headers, the system comprising: a proxy NF (“a roaming hub is a type of intermediate proxy” – col. 1 lines 48-49) configured to serve a plurality of PLMNs and including at least one processor and a memory (e.g., see the roaming hub 810 of figures 8 and 9 including memory 932 and processor 930);
and an egress SBI request message manager implemented by the at least one processor for receiving an egress inter-PLMN SBI request message (e.g., see at least col. 12 lines 46-51 “message forwarding controller 904 is configured to relay a message from a SEPP of one PLMN to a SEPP of another PLMN. As will be described in more detail below, message forwarding controller 904 is configured to add or modify one or more HTTP custom headers (e.g., headers 952 and 954) of the message 950.”), determining that the egress inter-PLMN SBI request message does not include a HTTP custom header e.g., see ‘1004’ figure 10 – “Roaming hub 810 (through message forwarding controller 904) determines whether the message 950 includes an HTTP custom header that indicates a PLMN (or multiple PLMNs)”) determining whether the egress inter-PLMN SBI request message includes an originating network identifier (consider the citation above in context with col.12 lines 5-7, “An HTTP custom header as defined herein may indicate a PLMN of a sending entity”), when the egress inter-PLMN SBI request message does not include the originating network identifier, obtaining, by the proxy NF and using a domain name system (DNS) or a database record including a mapping between a dynamically assigned SBI message identifier and the originating network identifier, the originating network identifier (i.e., see col. 13 lines 50-57, “When the message 950 as received does not include a validated PLMN custom header 952, roaming hub 810 adds or appends a validated PLMN custom header 952 to the message 950 that indicates the PLMN of the sending entity (step 1008) (i.e., the PLMN from which the roaming hub 810 received the message 950. For example, due to the roaming agreement 840 between roaming hub 810 and PLMN 804 in FIG. 8”– The database record reads on the roaming agreement – a dynamically assigned message identifier would read on an index that tracks with the incoming messages)) , when the egress inter-PLMN SBI request message includes the originating network identifier, obtaining, by the proxy NF and from the message, the originating network identifier, adding, by the proxy NF, e.g., see flowchart figure 10).
However, in analogous art, 3GPP teaches hypertext transfer protocol (HTTP) messages communicated between 3GPP-compliant networks, message attributes or parameters are carried in headers that are appended to the messages. Clause 5.2.3.2.151 of 3GPP TS 29.500 states that the 3GPP-Sbi-Originating-Network-Id header contains the PLMN identity (mobile country code (MCC) and mobile network code (MNC)) of the source PLMN or the standalone non-public network (SNPN) ID (MCC-MNC-NID) of the source SNPN of received HTTP messages.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effect filing date that the HTTP message of Khare includes the 3gpp-Sbi-Originating-Network-Id or the equivalent thereof for the purpose of securing and validating interconnections.
Consider Claims 5 and 15, Khare teaches wherein the egress SBI request message manager is configured to obtain the originating network identifier using the database record (i.e., based on the roaming agreements which is the equivalent of a database record - see col. 13 lines 50-57).
Consider Claims 7 and 17, Khare teaches wherein the egress SBI request message manager is configured to create the database record including the mapping prior to receiving the egress inter-PLMN SBI request message (i.e., this is made based on “Roaming agreement” - see col. 13 lines 50-57).
Consider Claims 9 and 19, Khare teaches wherein the proxy NF comprises a security edge protection proxy (SEPP), a service communication proxy (SCP), or a roaming hub (e.g., see roaming hub figure 9).
Consider Claim 10 The method of claim 9 wherein the proxy NF comprises an originating SEPP and forwarding the egress inter-PLMN SBI request message to or towards the target PLMN includes forwarding the egress inter-PLMN SBI request message to an SEPP associated with the target PLMN (e.g., see FIGURE 8 – “a SEPP is a non-transparent proxy that supports message filtering and policing on inter-PLMN control plane interfaces, and topology hiding. Thus, the SEPP protects the connection between NF service consumers and NF service producers from a security perspective. A SEPP applies message filtering and policing to every CP message in inter-PLMN signaling, acting as a service relay between the actual NF service producer and the actual NF service consumer”).
Claim(s) 2-4 and 12-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Khare US Patent No.: 11,533,358 in view of 3GPP TS 29.500 V18.3.0 (2023-09), hereinafter, ‘3GPP’ and further in view of Sharma US Patent Pub. No.: 2023/0007536 A1.
Consider claims 2 and 12, Khari teaches the claimed invention except wherein: the egress inter-PLMN SBI request message includes an egress inter-PLMN NF discovery request message; the egress SBI request message manager determines that the egress inter-PLMN NF discovery request message does not include an originating network identifier; and the egress SBI request message manager obtains the originating network identifier using the DNS.
Khare teaches “The 5G architecture is based on a Service-Based Architecture (SBA), which is delivered by a set of interconnected Network Functions (NFs), with authorization to access each other's services. The roles of NFs with the 5GC may be defined as a service consumer and a service producer. An NF service producer is an NF that exposes a service, and an NF service consumer is an NF that requests a service. The NRF 226 stores the NF profiles of the NF service producers, and the NF service consumers are able to query the NRF 226 with a discovery function to obtain the NF profiles of the NF service producers.” – col. 6 lines 18-28.
Sharma teaches in 0014 and 0037 –“the NF device may include means for transmitting a network address query to a domain name search (DNS) server related to a network repository function (NRF) cluster located in a public land mobile network (PLMN), the NRF cluster including a plurality of NRF devices, the plurality of NRF devices including a primary NRF device and at least one secondary NRF device; receiving a DNS response from the DNS server, the DNS response including a list of network address information for each NRF device”.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date to try wherein: the egress inter-PLMN SBI request message includes an egress inter-PLMN NF discovery request message; the egress SBI request message manager determines that the egress inter-PLMN NF discovery request message does not include an originating network identifier; and the egress SBI request message manager obtains the originating network identifier using the DNS based on the teachings, suggestion, and motivations of Khare and Sharma for the purpose of providing redundancy and/or failover support for NRF device(s) and/or NF device(s), as well as load-balancing functionality for NF requests, on the wireless communication network.
Consider Claims 3 and 13, Khare as modified by 3GPP teaches the claimed invention except wherein, in obtaining the originating network identifier using the DNS, the egress SBI request message manager is configured to: send a plurality of different DNS queries to a DNS server, where each of the DNS queries includes a network identifier of the PLMNs served by the proxy NF and an NF identifier; and receive a success response to one of the queries and obtaining the originating network identifier includes treating the network identifier included the query that resulted in the success response as the originating network identifier.
In analogous art, Sharma teaches in 0014 and 0037 –“the NF device may include means for transmitting a network address query to a domain name search (DNS) server related to a network repository function (NRF) cluster located in a public land mobile network (PLMN), the NRF cluster including a plurality of NRF devices, the plurality of NRF devices including a primary NRF device and at least one secondary NRF device; receiving a DNS response from the DNS server, the DNS response including a list of network address information for each NRF device”.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date to try wherein, in obtaining the originating network identifier using the DNS, the egress SBI request message manager is configured to: send a plurality of different DNS queries to a DNS server, where each of the DNS queries includes a network identifier of the PLMNs served by the proxy NF and an NF identifier; and receive a success response to one of the queries and obtaining the originating network identifier includes treating the network identifier included the query that resulted in the success response as the originating network identifier based on the teachings, suggestion, and motivations of Khare and Sharma for the purpose of providing redundancy and/or failover support for NRF device(s) and/or NF device(s), as well as load-balancing functionality for NF requests, on the wireless communication network
Consider Claims 4 and 14, Khari as modified by 3GPP teaches the claimed invention except wherein the identifier for the NF included in the DNS queries includes an identifier for an NF repository function (NRF).
In analogous art, Sharma teaches including a unique identifier for a NRF device (see at least 0096).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date to try wherein the identifier for the NF included in the DNS queries includes an identifier for an NF repository function (NRF) based on the teachings, suggestion, and motivations of Khare and Sharma for the purpose of providing redundancy and/or failover support for NRF device(s) and/or NF device(s), as well as load-balancing functionality for NF requests, on the wireless communication network.
Claim(s) 6, 8, 16 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Khare US Patent No.: 11,533,358 in view of 3GPP TS 29.500 V18.3.0 (2023-09), hereinafter, ‘3GPP’ and further in view of Singh et al. US Patent Pub. No.: 2022/0287089 A1, hereinafter, ‘Singh’.
Consider Claims 6 and 16, Khare as modified by 3GPP teaches the claimed invention except wherein, in obtaining the originating network identifier using the database record, the egress SBI request message manager is configured to obtain the dynamically assigned SBI message identifier from the egress inter-PLMN SBI request message; and perform a lookup in a database maintained by the proxy NF using the dynamically assigned SBI message identifier.
In analogous art, Singh teaches in 0013 - dynamically populating the resource object owner database includes receiving, from consumer NFs, SBI resource object creation requests, extracting, from the SBI resource object creation requests, NF instance identifiers of the consumer NFs that originated the SBI resource object creation requests, receiving, from producer NFs, responses to the SBI resource object creation requests confirming successful creation of the resource objects, and, in response to receiving the responses, storing the NF instance identifiers of the consumer NFs and corresponding resource object identifiers in the resource object owner database- 0015 - accessing the resource object access authorization policy database includes extracting a resource object identifier from the first SBI resource object access request, performing a lookup in the resource object access authorization policy database using the resource object identifier, and locating a record in the resource object access authorization policy database having a resource object identifier that matches the resource object identifier extracted from the first SBI resource object access request.
Therefore, it would have been obvious to a person of ordinary skill in the art the art to modify Khare as modified by 3GPP to achieve the results wherein, in obtaining the originating network identifier using the database record, the egress SBI request message manager is configured to obtain the dynamically assigned SBI message identifier from the egress inter-PLMN SBI request message; and perform a lookup in a database maintained by the proxy NF using the dynamically assigned SBI message identifier for the purpose of resource object level authorization at a network function.
Consider Claims 8 and 18, Khare as modified by 3GPP teaches the claimed invention except wherein, in creating the database record, the egress SBI request message manager is configured to: receive a response message from a producer NF, obtaining the dynamically assigned SBI message identifier from the response message; and store the SBI message identifier and the originating network identifier in the database maintained by the proxy NF.
In analogous art, Singh teaches in 0013 - dynamically populating the resource object owner database includes receiving, from consumer NFs, SBI resource object creation requests, extracting, from the SBI resource object creation requests, NF instance identifiers of the consumer NFs that originated the SBI resource object creation requests, receiving, from producer NFs, responses to the SBI resource object creation requests confirming successful creation of the resource objects, and, in response to receiving the responses, storing the NF instance identifiers of the consumer NFs and corresponding resource object identifiers in the resource object owner database- 0015 - accessing the resource object access authorization policy database includes extracting a resource object identifier from the first SBI resource object access request, performing a lookup in the resource object access authorization policy database using the resource object identifier, and locating a record in the resource object access authorization policy database having a resource object identifier that matches the resource object identifier extracted from the first SBI resource object access request.
Therefore, it would have been obvious to a person of ordinary skill in the art the art to modify Khare as modified by 3GPP to achieve the results wherein, in creating the database record, the egress SBI request message manager is configured to: receive a response message from a producer NF, obtaining the dynamically assigned SBI message identifier from the response message; and store the SBI message identifier and the originating network identifier in the database maintained by the proxy NF for the purpose of resource object level authorization at a network function.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES TERRELL SHEDRICK whose telephone number is (571)272-8621. The examiner can normally be reached 8A-5P.
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, Matthew D Anderson can be reached at 571 272 4177. 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.
/CHARLES T SHEDRICK/Primary Examiner, Art Unit 2646
1 This header shall be inserted by an NF service consumer or an NF service producer originating an HTTP request message towards a different PLMN or SNPN. It should be inserted by the sending SCP in SBI HTTP request messages towards the SEPP, only if the header is not present in the SBI HTTP request message and the SCP can determine which PLMN-ID value should be included in the header. It shall be inserted by the sending SEPP or the receiving SEPP in SBI HTTP request messages towards the target PLMN or SNPN, only if the header is not present in the SBI HTTP request message and the sending SEPP or the receiving SEPP (respectively) can determine the PLMN ID or SNPN ID of the source PLMN or SNPN. If the SEPP cannot uniquely determine the PLMN-ID or SNPN- ID, it is a configuration/deployment aspect to determine which PLMN-ID or SNPN-ID value should be included in the header by these entities. In such case, the message should either be dropped, or the SEPP shall indicate to the peer that the header is derived based on configuration It shall indicate the PLMN-ID or the SNPN-ID of the source PLMN or SNPN of the HTTP request message (i.e., the PLMN ID or the SNPN ID of the NF Service Consumer or NF Service Producer