DETAILED ACTION
This action is in response to the application filed on September 24, 2024. Claims 1-28 have been canceled and Claims 29-40 are pending. Of such, claims 29-34 represent a device, claims 35-39 represent a method, and claim 40 represents a non-transitory computer program product directed to network function messaging.
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 .
Specification
The abstract of the disclosure is objected to because
The abstract contains acronyms that must be expanded upon (i.e. SEPP and TLS).
The abstract contains a label for “Fig. 1” and should be removed.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Drawings
The drawings are objected to because:
The label “Fig. 3” represents two different figures on separate pages.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claim 32 is objected to because of the following informalities:
Claim 32 discloses the term “wherein:” should be corrected to “wherein”
Claim 32 discloses the term “the-application” should be corrected to “the application”
Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 29-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-12 of U.S. Patent No. 12206774.
Presently Presented 18894179 - Claim 29
US 12206774 - Claim 1
A first security edge proxy serving a first network function, comprising: at least one processor; and at least one memory storing instructions, that when executed by the at least one processor, cause the first security edge proxy at least to:
An apparatus, comprising: at least one processor; and at least one non-transitory memory storing instructions, that when executed by the at least one processor, cause the apparatus at least to:
form a transport layer security protected first control plane connection between a first security edge proxy and a second security edge proxy so that the first security edge proxy is a transport layer security client and the second security edge proxy is a transport layer security server for the first control plane connection;
form a transport layer security protected first control plane connection between a first security edge proxy and a second security edge proxy so that the first security edge proxy is a transport layer security client and the second security edge proxy is a transport layer security server for the first control plane connection;
and form a transport layer security protected second control plane connection between the first security edge proxy and the second security edge proxy so that the first security edge proxy is a transport layer security server and the second security edge proxy is a transport layer security client for the second control plane connection;
and form a transport layer security protected second control plane connection between the first security edge proxy and the second security edge proxy so that the first security edge proxy is a transport layer security server and the second security edge proxy is a transport layer security client for the second control plane connection;
derive an N32-f context identification for each of the first control plane connection and the second control plane connection, wherein the context identification for each of the first control plane connection and the second control plane connection identifies a different security context;
form a first unique identifier representing a logical connection context information for message protection on a first logical connection that is associated with the first control plane connection; and form a second unique identifier representing a logical connection context information for message protection on a second logical connection that is associated with the second control plane connection, derive an N32-f context identification for each of the first control plane connection and the second control plane connection, wherein the context identification for each of the first control plane connection and the second control plane connection
derive a pair of session keys and an initialization vector randomizer for each first of the first security edge proxy and the second security edge proxy to use to set up the first logical connection and the second logical connection to send protected API messages across an N32 interface,
identifies a different security context derive a pair of session keys and an initialization vector randomizer for each first of the first security edge proxy and the second security edge proxy to use to set up the first logical connection and the second logical connection to send protected API messages across an N32 interface,
wherein the pair of session keys and the initialization vector are derived using one N32- f Master key and the N32-f context identification derived for each of the first control plane connection and the second control plane connection;
wherein the pair of session keys and the initialization vector are derived using one N32- f Master key and the N32-f context identification derived for each of the first control plane connection and the second control plane connection;
wherein the first control plane connection is an N32-c connection;
wherein the first control plane connection is an N32-c connection;
wherein the second control plane connection is an N32-c connection;
wherein the second control plane connection is an N32-c connection;
wherein the first logical connection is an N32-f connection;
wherein the first logical connection is an N32-f connection;
wherein the second logical connection is an N32-f connection;
wherein the second logical connection is an N32-f connection;
wherein the first logical connection is protected by application layer security
wherein the first logical connection is protected by application layer security;
wherein the second logical connection is protected by application layer security
wherein the second logical connection is protected by application layer security;
and wherein the first and second logical connections are for inter-network data exchange between a first network function of a first network and a second network function of a second network.
and wherein the first and second logical connections are for inter-network data exchange between a first network function of a first network and a second network function of a second network.
Independent Claims 35 and 40 would follow the same mapping as Claim 29.
Dependent Claim Mapping:
Claims 30, 37
Claim 2
Claim 31, 38
Claim 3
Claim 32, 36
Claim 4
Claim 33
Claim 5
Claim 34
Claim 6
Claim 39
Claim 11
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 29-34 and 40 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 29 and 40 recites the limitation "a first network function" in line 30 of the claim and it is unclear if it is the same as “a network function” on line 1 of the claim.
Claim 32 recites the limitation “cause the apparatus”. There is insufficient antecedent basis for this limitation in the claim.
Claims 30-31 and 33-34 are rejected due to their dependency on Claim 29.
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 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.
Claim(s) 35-37 and 39 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated over ETSI (NPL ETSI TS 133 501 V15.1.0 – Change Request 33.501), hereinafter referred to as ETSI.
Regarding Claim 35, ETSI discloses:
A method, comprising: performing by a security edge proxy (on page 7, section 13.2.x, ETSI discloses “secure communication between service-consuming and a service-producing NFs in different PLMNs. Security is enabled by the Security Edge Protection Proxies of both networks, henceforth called cSEPP and pSEPP respectively. The SEPPs enforce protection policies regarding application layer security thereby ensuring integrity and confidentiality protection for those elements to be protected.” See figure 13.2.x-1): forming a transport layer security, protected first control plane connection between a first security edge proxy and a second security edge proxy so that the first security edge proxy is a transport layer security client and the second security edge proxy is a transport layer security server for the first control plane connection (In section 13.2.y.1, ETSI further discloses “When the SEPPs have mutually authenticated each other and when the negotiated the security mechanism to use over N32 is Application Layer Security, the SEPPs use the established TLS connection (N32-c connection) to negotiate the N32 specific associated security configuration parameters.” And in section 13.2.y.2, ETSI further discloses “The SEPP which initiated the TLS connection sends a Parameter Exchange Request message to the responding SEPP including the initiating SEPP’s supported cipher suites.”); and forming a transport layer security protected second control plane connection between the first security edge proxy and the second security edge proxy so that the first security edge proxy is a transport layer security server and the second security edge proxy is a transport layer security client server for the second control plane connection (In section 13.2.y.1, ETSI further discloses “When the SEPPs have mutually authenticated each other and when the negotiated the security mechanism to use over N32 is Application Layer Security, the SEPPs use the established TLS connection (N32-c connection) to negotiate the N32 specific associated security configuration parameters.” And in section 13.2.a.4.1, ETSI further discloses “The keys derived with labels starting parallel are to be used for request/responses in an HTTP session with the N32-c initiating SEPP acting as the client (i.e. in parallel to the N32-c connection).”); derive a context identification for each of the first control plane connection and the second control plane connection, wherein the context identification for each of the first control plane connection and the second control plane connection identifies a different security context (In section 13.2.y.2, ETSI discloses “The SEPP which initiated the TLS connection sends a Parameter Exchange Request message to the responding SEPP including the initiating SEPP’s supported cipher suites. The cipher suites are ordered in initiating SEPP’s priority order. The SEPP provides a N32-f precontext ID for the responding SEPP. The precontext IDs are 32-bit random integers, represented as 0-left padded strings of hexadecimal digits” and further discloses “The SEPPs create the N32-f context Id as follows: Initiater's N32-f precontext ID | responder's N32-f precontext ID”), derive a pair of session keys and an initialization vector randomizer for each first of the first security edge proxy and the second security edge proxy to use to set up the first logical connection and the second logical connection to send protected API messages across an N32 interface (In section 13.2.y.4.3, ETSI discloses “The N32-c initial handshake establishes session keys, IVs and negotiated cipher suites.”), wherein the pair of session keys and the initialization vector are derived using one N32- f Master key and the N32-f context identification derived for each of the first control plane connection and the second control plane connection (In section 13.2.a.4.1, ETSI discloses “The N32-f key hierarchy is based on the N32-f master key generated during the N32-c initial handshake by TLS key export. Each run of the N32-f key derivation creates two pairs of session keys and IV salts. The two pairs are used in two different HTTP/2 sessions. In one Session the N32-c initiatior acts as the HTTP client and in the second the N32-c responder acts as the client. ”) wherein the first control plane connection is an N32-c connection (In section 13.2.y.1, ETSI further discloses “When the SEPPs have mutually authenticated each other and when the negotiated the security mechanism to use over N32 is Application Layer Security, the SEPPs use the established TLS connection (N32-c connection) to negotiate the N32 specific associated security configuration parameters.” And in section 13.2.y.2, ETSI further discloses “The SEPP which initiated the TLS connection sends a Parameter Exchange Request message to the responding SEPP including the initiating SEPP’s supported cipher suites.”); wherein the second control plane connection is an N32-c connection (In section 13.2.a.4.1, ETSI discloses “The keys derived with labels starting parallel are to be used for request/responses in an HTTP session with the N32-c initiating SEPP acting as the client (i.e. in parallel to the N32-c connection).”) wherein the first logical connection is an N32-f connection (In section 13.2.a.1, ETSI discloses “The SEPP receives the HTTP/2 request/response messages from the Network Function. It performs the following actions on these messages before they are sent on the N32-f interface to the SEPP in the other PLMN:” Note: the request is considered the first logical connection); wherein the second logical connection is an N32-f connection (In section 13.2.a.1, ETSI discloses “The SEPP receives the HTTP/2 request/response messages from the Network Function. It performs the following actions on these messages before they are sent on the N32-f interface to the SEPP in the other PLMN:” Note: the response is considered the first logical connection); protecting the first logical connection by application layer security (In section 13.2.y.2, ETSI discloses “any further N32-c communication that may occur over time while application layer security is applied to N32-f”); and protecting the second logical connection by application layer security (In section 13.2.y.2, ETSI discloses “any further N32-c communication that may occur over time while application layer security is applied to N32-f”).
Regarding Claim 36, ETSI discloses::
The method of claim 35, wherein the application layer security employs JSON Web Encryption, JWE. (In section 13.2.a.4, ETSI discloses “Protection of reformatted HTTP messages between SEPPs shall use JSON Web Encryption (JWE) as specified in IETF RFC 7516 [xx].”).
Regarding Claim 37, ETSI discloses::
The method of claim 35, wherein the first network function is an access and mobility function. (In section 13.2.z.3, ETSI discloses “Larger networks can contain multiple NFs with the same API, e.g. three AMFs. The NF API policy applies to all NFs with the same API.”)
Regarding Claim 39, ETSI discloses::
The method of claim 36, further comprising: encrypting, using a first shared secret, first control data for transmission over the first control plane connection (In section 13.2.a.1, ETSI discloses “Encryption of IEs take place end to end between cSEPP and pSEPP.”); and decrypting, using a second shared secret, second control data received over the second control plane connection (in section 13.2.a.7, ETSI discloses “The receiving SEPP shall decrypt the JWE ciphertext using the shared session key and the following parameters obtained from the JWE object – Initialization Vector, Additional Authenticated Data value (clearTextEncapsulatedMessage in “aad”) and JWE Authentication Tag (“tag”).”).
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.
Claim(s) 29-34, 38, and 40 are rejected under 35 U.S.C. 103 as being unpatentable over ETSI (NPL ETSI TS 133 501 V15.1.0 – Change Request 33.501), hereinafter referred to as ETSI, in view of He et al. (US 20230007475), hereinafter referred to as He.
Regarding Claim 29, ETSI discloses:
A first security edge proxy serving a first network function, comprising: at least one processor; and at least one memory storing instructions, that when executed by the at least one processor, cause the first security edge proxy at least to (on page 7, section 13.2.x, ETSI discloses “secure communication between service-consuming and a service-producing NFs in different PLMNs. Security is enabled by the Security Edge Protection Proxies of both networks, henceforth called cSEPP and pSEPP respectively. The SEPPs enforce protection policies regarding application layer security thereby ensuring integrity and confidentiality protection for those elements to be protected.” See figure 13.2.x-1): form a transport layer security protected first control plane connection between a first security edge proxy and a second security edge proxy so that the first security edge proxy is a transport layer security client and the second security edge proxy is a transport layer security server for the first control plane connection (In section 13.2.y.1, ETSI further discloses “When the SEPPs have mutually authenticated each other and when the negotiated the security mechanism to use over N32 is Application Layer Security, the SEPPs use the established TLS connection (N32-c connection) to negotiate the N32 specific associated security configuration parameters.” And in section 13.2.y.2, ETSI further discloses “The SEPP which initiated the TLS connection sends a Parameter Exchange Request message to the responding SEPP including the initiating SEPP’s supported cipher suites.”); and form a transport layer security protected second control plane connection between the first security edge proxy and the second security edge proxy so that the first security edge proxy is a transport layer security server and the second security edge proxy is a transport layer security client for the second control plane connection (In section 13.2.y.1, ETSI further discloses “When the SEPPs have mutually authenticated each other and when the negotiated the security mechanism to use over N32 is Application Layer Security, the SEPPs use the established TLS connection (N32-c connection) to negotiate the N32 specific associated security configuration parameters.” And in section 13.2.a.4.1, ETSI further discloses “The keys derived with labels starting parallel are to be used for request/responses in an HTTP session with the N32-c initiating SEPP acting as the client (i.e. in parallel to the N32-c connection).”); derive an N32-f context identification for each of the first control plane connection and the second control plane connection, wherein the context identification for each of the first control plane connection and the second control plane connection identifies a different security context (In section 13.2.y.2, ETSI discloses “The SEPP which initiated the TLS connection sends a Parameter Exchange Request message to the responding SEPP including the initiating SEPP’s supported cipher suites. The cipher suites are ordered in initiating SEPP’s priority order. The SEPP provides a N32-f precontext ID for the responding SEPP. The precontext IDs are 32-bit random integers, represented as 0-left padded strings of hexadecimal digits” and further discloses “The SEPPs create the N32-f context Id as follows: Initiater's N32-f precontext ID | responder's N32-f precontext ID”); derive a pair of session keys and an initialization vector randomizer for each first of the first security edge proxy and the second security edge proxy to use to set up the first logical connection and the second logical connection to send protected API messages across an N32 interface (In section 13.2.y.4.3, ETSI discloses “The N32-c initial handshake establishes session keys, IVs and negotiated cipher suites.”), wherein the pair of session keys and the initialization vector are derived using one N32- f Master key and the N32-f context identification derived for each of the first control plane connection and the second control plane connection (In section 13.2.a.4.1, ETSI discloses “The N32-f key hierarchy is based on the N32-f master key generated during the N32-c initial handshake by TLS key export. Each run of the N32-f key derivation creates two pairs of session keys and IV salts. The two pairs are used in two different HTTP/2 sessions. In one Session the N32-c initiatior acts as the HTTP client and in the second the N32-c responder acts as the client. ”); wherein the first control plane connection is an N32-c connection (In section 13.2.y.1, ETSI further discloses “When the SEPPs have mutually authenticated each other and when the negotiated the security mechanism to use over N32 is Application Layer Security, the SEPPs use the established TLS connection (N32-c connection) to negotiate the N32 specific associated security configuration parameters.” And in section 13.2.y.2, ETSI further discloses “The SEPP which initiated the TLS connection sends a Parameter Exchange Request message to the responding SEPP including the initiating SEPP’s supported cipher suites.”); wherein the second control plane connection is an N32-c connection (In section 13.2.a.4.1, ETSI discloses “The keys derived with labels starting parallel are to be used for request/responses in an HTTP session with the N32-c initiating SEPP acting as the client (i.e. in parallel to the N32-c connection).”); wherein the first logical connection is an N32-f connection (In section 13.2.a.1, ETSI discloses “The SEPP receives the HTTP/2 request/response messages from the Network Function. It performs the following actions on these messages before they are sent on the N32-f interface to the SEPP in the other PLMN:” Note: the request is considered the first logical connection); wherein the second logical connection is an N32-f connection (In section 13.2.a.1, ETSI discloses “The SEPP receives the HTTP/2 request/response messages from the Network Function. It performs the following actions on these messages before they are sent on the N32-f interface to the SEPP in the other PLMN:” Note: the response is considered the first logical connection); wherein the first logical connection is protected by application layer security (In section 13.2.y.2, ETSI discloses “any further N32-c communication that may occur over time while application layer security is applied to N32-f”); wherein the second logical connection is protected by application layer security (In section 13.2.y.2, ETSI discloses “any further N32-c communication that may occur over time while application layer security is applied to N32-f”);
However, ETSI does not explicitly disclose multiple network functions. He discloses:
and wherein the first and second logical connections are for inter-network data exchange between a first network function of a first network and a second network function of a second network. (In ¶ 604, He discloses “Step 1905. If the PLMN ID stored in the N32 interface context corresponding to the SEPP in the first network is the same as the PLMN ID in the N32 interface message, the SEPP in the second network performs other security processing on the N32 interface message to obtain a second message, and sends the second message to a network function entity in the second network, where the second message and the first message include same content.”)
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify ETSI’s approach by utilizing He’s approach of using multiple network functions when communicating over n32 as the motivation would have been obvious to allow the expansion of communication between network elements and functions (See He, ¶ 608).
Regarding Claim 30, the combination of ETSI and He disclose:
The first security edge proxy of claim 29, wherein the first network function is an access and mobility function. (In section 13.2.z.3, ETSI discloses “Larger networks can contain multiple NFs with the same API, e.g. three AMFs. The NF API policy applies to all NFs with the same API.”)
Regarding Claim 31, the combination of ETSI and He disclose the limitations of Claim 29.
However, ETSI does not explicitly disclose the access and mobility function.
He discloses:
The first security edge proxy of claim 29, wherein the first network function is an authentication server function. (In ¶ 158, He discloses “The UE, the AMF, and the AUSF complete a bidirectional authentication process based on a process defined in 3GPP 33.501.”)
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify ETSI’s approach by utilizing He’s approach of utilize an authentication server function as the motivation would have been obvious to allow the edge device to perform authentication to the home network to establish a secure connection path between the home network and the devices requesting communication (See He, ¶ 592).
Regarding Claim 32, the combination of ETSI and He discloses:
The first security edge proxy of claim 29, wherein the application layer security employs same cipher suites for the first and second logical connections (In section 13.2.y.2, ETSI discloses “The two SEPPs perform a cipher suite negotiation to agree on a cipher suite to use for protecting NF service related signaling over N32-f.”).
Regarding Claim 33, the combination of ETSI and He discloses:
The first security edge proxy of claim 29, wherein the application layer security employs JSON Web Encryption, JWE. (In section 13.2.a.4, ETSI discloses “Protection of reformatted HTTP messages between SEPPs shall use JSON Web Encryption (JWE) as specified in IETF RFC 7516 [xx].”).
Regarding Claim 34, the combination of ETSI and He discloses:
The first security edge proxy of claim 29, wherein the at least one memory is storing instructions executed by the at least one processor, to cause the apparatus to: exchange a different pre-context identification on each of the first control plane connection and the second control plane connection (In section 13.2.y.2, ETSI discloses “The SEPP provides a N32-f precontext ID for the responding SEPP.” And further discloses “The responding SEPP provides a N32-f precontext ID for the initiating SEPP.”), and combine the different pre-context identifications to derive the context identification for each of the first control plane connection and the second control plane connection (In section 13.2.y.2, ETSI discloses “The SEPPs create the N32-f context Id as follows: Initiater's N32-f precontext ID | responder's N32-f precontext ID”).
Regarding Claim 38, ETSI the limitations of Claim 35.
However, ETSI does not explicitly disclose the access and mobility function.
He discloses:
The method of claim 35, wherein the first network function is an authentication server function. (In ¶ 158, He discloses “The UE, the AMF, and the AUSF complete a bidirectional authentication process based on a process defined in 3GPP 33.501.”)
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify ETSI’s approach by utilizing He’s approach of utilize an authentication server function as the motivation would have been obvious to allow the edge device to perform authentication to the home network to establish a secure connection path between the home network and the devices requesting communication (See He, ¶ 592).
Claim 40 is directed to a non-transitory computer program product having functionality corresponding to the apparatus of Claim 29, and is rejected by a similar rationale, mutatis mutandis.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yau et al. (US 10834571) discloses a package exchange protocol in a 5G network utilizing N32 interfaces.
Hallenstal, Magnus (US 20220240172) discloses a method performed by a first network node for handling network function service requests.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHADI H KOBROSLI whose telephone number is (571)272-1952. The examiner can normally be reached M-F 9am-5pm ET.
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, Rupal Dharia can be reached at 571-272-3880. 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.
/SHADI H KOBROSLI/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492