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 .
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-9 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 fails to comply with the written description requirement due to limitation “wherein the data plane is not compressed” in line 22 of claim 1. The closest description in specification [0008] “payload communicated over the data plane connection that is compressed or not compressed”. These are not the same thing.
Claims 2-9 are rejected for being dependent on claim 1.
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 1-13 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.
Claim 1 recites the limitation "a data plane" in 22. There is insufficient antecedent basis for this limitation in the claim.
Claim 2-9 are rejected for being dependent on claim 1.
Claim 1 is unclear thus indefinite. The claim states “the payload remains unprocessed while being communicated via the plurality of internet protocol exchanges”
The next limitation states “the payload communicated over the data plane connection is compressed while traversing the at least one intermediate internet protocol exchange…”.
This is unclear because the claim states the payload is unprocessed over ALL IPX and then claim the payload is compressed over at least one IPX? The payload being compressed would be something getting “acted upon”, thus the payload does NOT remain unprocessed over all IPX as claimed.
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.
Claim(s) 1, 4, 6, 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rajput et al. (US20220104112) in view of Panasyuk et al.(WO2007/040521) further in view of Jensen et al. (US20150319269A1).
Regarding claim 1, Rajput teaches an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core ([0020] “ The system includes a security edge protection proxy (SEPP) including at least one processor and a memory”), cause the apparatus at least to:
initiate a handshake process configured to establish a control plane connection prior to establishing an associated data plane connection from the apparatus to a gateway node in a second network ([0041] “SEPP 126A and SEPP 126B communicate over the N32 interface. The N32 interface includes two different interfaces, the N32-c interface and the N32-f interface. The N32-c interface is a control plane interface between SEPPs for performing an initial handshake and negotiating the parameters to be applied during N32 message forwarding. The N32-f interface is a forwarding interface between SEPPs which is used for forwarding communications between NF service consumers and NF service producers after applying application level security protection”, (Examiner’s Note:N32-f interface ==data plane),
the apparatus being in a first network distinct from the second network (Fig. 2 “SEPP1”, “SEPP2”, [0041] “ Referring to FIG. 2, SEPP 126A and SEPP 126B communicate over the N32 interface. The N32 interface includes two different interfaces, the N32-c interface and the N32-f interface. The N32-c interface is a control plane interface between SEPPs for performing an initial handshake and negotiating the parameters to be applied during N32 message forwarding”));
wherein the data plane connection to the gateway node traverses a plurality of intermediate internet protocol exchanges (Fig 2 “N32-f(TLS) “, “IPX1”, “IPX2”, [0041] “The N32-f interface is a forwarding interface between SEPPs which is used for forwarding communications between NF service consumers and NF service producers after applying application level security protection”)),
Rajput does not teach and indicate during the establishing of the control plane connection that compression of a payload communicated over the data plane connection is requested, the payload is communicated over the data plane connection via the plurality of intermediate internet protocol exchanges,
the payload remains unprocessed while being communicated via the plurality of intermediate internet protocol exchanges,
wherein the payload communicated over the data plane connection is compressed while traversing at least one intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges,
and wherein the data plane is not compressed while traversing at least one other intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges.
Panasyuk teaches and indicate during the establishing of the control plane connection that compression of a payload communicated over the data plane connection is requested (page 3 par. 1, 2 “The handshake request packet comprises one or more data blocks. The method includes the step of initiating, by the second proxy, a change to the handshake request packet. The change comprises one of modifying, adding and deleting a data block of the one or more data blocks … the one or more data blocks may represent a capability of one of the first proxy, the second proxy and the third proxy. In one embodiment, at least one of the one or more data block comprises information describing one or more of the following capabilities: compression”, page 30 lines 29- page 31 lines 5 “the client 208 and destination server 210 of system 500 may establish a connection via a single connection handshake 505 as depicted by the illustrative method of FIG. 6. At step 610, the client 208 generates a connection request 502 to request a connection between the client 208 and the destination server 220. The client 208 may further define in the connection request 502 via the data blocks 320a-320c one or more operational characteristics of the connection with regards to compression, encryption and security”, (Examiner’s Note: the control plane receiving information to set up data plane such as compression, encryption and security for use when sending the data blocks later)),
the payload is communicated over the data plane connection via the plurality of intermediate internet protocol exchanges (page 2 para. 3 “The present invention relates to systems and methods for establishing and controlling a connection from a client to a destination server via multiple proxies using a network protocol”, page 15 par. 1 “Also, the proxy 120a-120n may be as part of or otherwise implemented in any type of network device, such as a router, firewall or switch … For example, the proxy 120a-120n may be a component of an application providing internet based security … corporate internal network 104, page 34 lines 20-30”),
the payload remains unprocessed while being communicated via the plurality of intermediate internet protocol exchanges (page 2 para. 3 “The present invention relates to systems and methods for establishing and controlling a connection from a client to a destination server via multiple proxies using a network protocol”, page 15 par. 1 “Also, the proxy 120a-120n may be as part of or otherwise implemented in any type of network device, such as a router, firewall or switch … For example, the proxy 120a-120n may be a component of an application providing internet based security … corporate internal network 104, page 34 lines 20-30 “ At step 640, the client 208 may initiate a communication to the destination server 220 … In other cases, the first proxy 120a may not perform any computation and forward the network packet on the connection 202a”),
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rajput to incorporate the teachings of Panasyuk. One of ordinary skill in the art would have been motivated to make this modification in order to allow for compression.
Panasyuk does not teach wherein the payload communicated over the data plane connection is compressed while traversing at least one intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges,
and wherein the data plane is not compressed while traversing at least one other intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges.
Jensen teaches wherein the payload communicated over the data plane connection is compressed while traversing at least one intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges, and wherein the data plane is not compressed while traversing at least one other intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges ([0009] “In these embodiments, the intermediaries perform the compression. The first intermediary may perform compress data communicated by the server to the client via the remote display protocol and forwarding the compressed data to the second intermediary. The second intermediary may uncompress the compressed data and forwarding the uncompressed data to the client via the remote display protocol”, [0056] “the appliance 205 determines the server 106 to distribute the network packet by application information and data carried as payload of the transport layer packet”, (Examiner’s Note: data == data carried as payload, first and second intermediary == plurality of intermediate internet protocol exchanges).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rajput, Panasyuk to incorporate the teachings of Jensen. One of ordinary skill in the art would have been motivated to make this modification in order to improve effectiveness of compression of intermediaries to compress data.
Regarding claim 4, Rajput teaches teach wherein the end-to-end control plane connection is supported over a transport layer security, TLS, connection ([0051] “To protect against this type of attack, responding SEPP 126B may store the identity of an initiating SEPP received on the N32-c interface and use that identity to cross-validate the identity of an initiating SEPP in a TLS connection for N32-f communications. FIG. 6 illustrates the cross-validation that may be performed by a responding SEPP. Referring to FIG. 6, in line 1, initiating SEPP 126A and responding SEPP 126B exchange TLS messages for establishing a TLS connection for N32-c communications. In lines 2 and 3, initiating SEPP 126A and responding SEPP 126B exchange N32-c, securities capability exchange messages”)
Regarding claim 6, Rajput does not teach wherein the apparatus is further configured to negotiate with the gateway concerning which compression mechanism to use in the compression of the payload communicated over the data plane connection, to agree on a specific compression mechanism supported by the apparatus, the gateway and the at least one intermediate internet protocol exchange.
Panasyuk teaches wherein the apparatus is further configured to negotiate with the gateway concerning which compression mechanism to use in the compression of the payload communicated over the data plane connection, to agree on a specific compression mechanism supported by the apparatus, the gateway and the at least one intermediate internet protocol exchange (page 25, par. 2 “As illustrated in FIG. 3B, the handshake request 302 may comprise three data blocks of 320a, 320b and 320c. At step 412, the first proxy 120a processes the handshake request 302 and forwards the handshake request 302 to the second proxy 120b. The first proxy 120a may read the data blocks 320a, 32On and 320c, and configured itself based on the data, or read the data to apply the functionality for an established connection”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rajput to incorporate the teachings of Panasyuk. One of ordinary skill in the art would have been motivated to make this modification in order to allow for compression.
Regarding claim 9, Rajput does not teach wherein the apparatus is further configured to provide a service request or a service response directed to a network function of the second network as compressed payload data on the data plane connection.
Panasyuk teaches wherein the apparatus is further configured to provide a service request or a service response directed to a network function of the second network as compressed payload data on the data plane connection (page 14 par. 3 “The proxies 120a-120n running on the servers 210-210" provide computer network services which allows the client 208 to make indirect network connections to other network services, such as services provided by the destination server 220. The client 208 connects to the proxy 120a, then requests a connection, file, or other resource available on a different server, such as the server 210' of proxy 120b, or the desination server 220”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rajput to incorporate the teachings of Panasyuk. One of ordinary skill in the art would have been motivated to make this modification in order to allow for compression.
Claim(s) 2, 3, 5, 7, 8, 10-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rajput in view of Panasyuk in view of Jensen, further in view of Bykampadi et al. (WO2020012065).
Regarding claim 2, Rajput, Panasyuk, Jensen does not explicitly teach wherein the apparatus is configured to perform the indicating that compression of the payload communicated over the data plane connection is requested during a security capability negotiation procedure of the handshake process or a parameter exchange procedure of the handshake process.
Bykampadi teaches wherein the apparatus is configured to perform the indicating that compression of the payload communicated over the data plane connection is requested during a security capability negotiation procedure of the handshake process or a parameter exchange procedure of the handshake process (page 17 lines 4-24 “Here are the structures of the ClientHello and ServerHello messages in TLS 1.3 (see draft RFC entitled“The Transport Layer Security (TLS) Protocol Version 1.3” draft-ietf-tls- tlsl 3-28, the disclosure of which is incorporated by reference herein in its entirety):struct {ProtocolVersion legacy_version = 0x0303; /* TLS vl.2 */ Random random; opaque legacy_session_id<0..32>; CipherSuite cipher_suites<2..2A16-2>; opaque legacy_compression_methods<1..2A8-l>; Extension extensions<8..2A16-l>;} ClientHello; struct {ProtocolVersion legacy_version = 0x0303; /* TLS vl.2 */ Random random; opaque legacy_session_id_echo<0..32>; CipherSuite cipher_suite; uint8 legacy_compression_method = 0; Extension extensions<6..2A16-l>;} ServerHello;”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rajput, Panasyuk, Jensen to incorporate the teachings of Bykumpadi. One of ordinary skill in the art would have been motivated to make this modification in order to increase security.
Regarding claim 3, Rajput, Panasyuk, Jensen does not explicitly teach wherein the apparatus is configured to provide in the indication that compression of the payload communicated over the data plane connection is requested an ordered list of compression mechanisms.
Bykampadi teaches wherein the apparatus is configured to provide in the indication that compression of the payload communicated over the data plane connection is requested an ordered list of compression mechanisms (page 12, lines 19-25 “However, before two participating SEPPs (e.g., vSEPP 312 and hSEPP 322 in FIG. 3, or sSEPP 430-1 and rSEPP 430-2) can exchange protected HTTP messages, it is realized herein that it is important that the SEPPs first mutually authenticate each other and then exchange a set of parameters over a secure connection between the two entities. For example, the set of parameters that the two SEPPs agree on includes capability exchange, cipher suites to use for protection of HTTP message payload, protection policies that indicate which parameters to encrypt in each HTTP message, and so on. Such parameters therefore comprise one or more configuration parameters and/or one or more security parameters”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rajput, Panasyuk, Jensen to incorporate the teachings of Bykumpadi. One of ordinary skill in the art would have been motivated to make this modification in order to increase security.
Regarding claim 5, Rajput, Panasyuk, Jensen does not explicitly teach wherein the apparatus is further configured to store information defining which compression mechanisms are supported by at least one of the at least one intermediate internet protocol exchange.
Bykampadi teaches wherein the apparatus is further configured to store information defining which compression mechanisms are supported by at least one of the at least one intermediate internet protocol exchange (page 12 lines 19-25 “For example, the set of parameters that the two SEPPs agree on includes capability exchange, cipher suites to use for protection of HTTP message payload, protection policies that indicate which parameters to encrypt in each HTTP message, and so on. Such parameters therefore comprise one or more configuration parameters and/or one or more security parameters”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rajput, Panasyuk, Jensen to incorporate the teachings of Bykumpadi. One of ordinary skill in the art would have been motivated to make this modification in order to increase security.
Regarding claim 7, Rajput, Panasyuk, Jensen does not explicitly teach wherein the apparatus is configured to provide the compressed the payload to the data plane connection as compressed javascript object notation data compressed using the specific compression mechanism.
Bykampadi teaches wherein the apparatus is configured to provide the compressed the payload to the data plane connection as compressed javascript object notation data compressed using the specific compression mechanism (page 12 lines 10-15 “An optional payload body, for instance formatted as JavaScript Object Notation (JSON)”), page 12 lines 19-25 “For example, the set of parameters that the two SEPPs agree on includes capability exchange, cipher suites to use for protection of HTTP message payload, protection policies that indicate which parameters to encrypt in each HTTP message, and so on. Such parameters therefore comprise one or more configuration parameters and/or one or more security parameters”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rajput, Panasyuk, Jensen to incorporate the teachings of Bykumpadi. One of ordinary skill in the art would have been motivated to make this modification in order to increase security.
Regarding claim 8, Rajput, Panasyuk, Jensen does not explicitly teaches wherein the apparatus and the gateway both are security edge protection proxies, SEPPs, configured as specified by third generation partnership project, 3GPP, standards.
Bykampadi teaches wherein the apparatus and the gateway both are security edge protection proxies, SEPPs, configured as specified by third generation partnership project, 3GPP, standards (page 18 lines 19-23“That is, the two endpoints may also exchange the two endpoints through a separate SEPP to SEPP N32 messaging“after” TLS connection is setup. This may occur as part of the Initial Handshake procedure that is specified by 3GPP between two SEPPs”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rajput, Panasyuk, Jensen to incorporate the teachings of Bykumpadi. One of ordinary skill in the art would have been motivated to make this modification in order to increase security.
Regarding claim 10, 12 Rajput, An apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core ([0020] “ The system includes a security edge protection proxy (SEPP) including at least one processor and a memory”), cause the apparatus at least to:
participate in a handshake process configured to establish a control plane connection prior to establishing an associated data plane connection from the apparatus to a gateway node in a first network ([0041] “SEPP 126A and SEPP 126B communicate over the N32 interface. The N32 interface includes two different interfaces, the N32-c interface and the N32-f interface. The N32-c interface is a control plane interface between SEPPs for performing an initial handshake and negotiating the parameters to be applied during N32 message forwarding. The N32-f interface is a forwarding interface between SEPPs which is used for forwarding communications between NF service consumers and NF service producers after applying application level security protection”, (Examiner’s Note:N32-f interface ==data plane),
the apparatus being in a second network distinct from the first network (Fig. 2 “SEPP1”, “SEPP2”, [0041] “ Referring to FIG. 2, SEPP 126A and SEPP 126B communicate over the N32 interface. The N32 interface includes two different interfaces, the N32-c interface and the N32-f interface. The N32-c interface is a control plane interface between SEPPs for performing an initial handshake and negotiating the parameters to be applied during N32 message forwarding”)),
wherein the data plane connection to the gateway node traverses a plurality of intermediate internet protocol exchanges (Fig 2 “N32-f(TLS) “, “IPX1”, “IPX2”, [0041] “The N32-f interface is a forwarding interface between SEPPs which is used for forwarding communications between NF service consumers and NF service producers after applying application level security protection”);
Rajput does not teach receive a hypertext transfer protocol, HTTP, payload communicated over the data plane connection that is compressed or not compressed, wherein the HTTP payload is communicated over the data plane connection via the plurality of intermediate internet protocol exchanges, the HTTP payload remains unprocessed while being communicated via the plurality of intermediate internet protocol exchanges,the HTTP payload communicated over the data plane connection is compressed while traversing at least one intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges, and the HTTP payload communicated over the data plane connection is not compressed while traversing at least one other intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges; and - determine whether to compress a reconstructed hypertext transfer protocol, HTTP, payload received over the data plane connection before forwarding it onward to a network function in the second network.
Panasyuk teaches receive a (page 2 para. 3 “The present invention relates to systems and methods for establishing and controlling a connection from a client to a destination server via multiple proxies using a network protocol”, page 15 par. 1 “Also, the proxy 120a-120n may be as part of or otherwise implemented in any type of network device, such as a router, firewall or switch … For example, the proxy 120a-120n may be a component of an application providing internet based security … corporate internal network 104, page 34 lines 20-30”, page 30 lines 29-page 31 lines 5” The client 208 may further define in the connection request 502 via the data blocks 320a-320c one or more operational characteristics of the connection with regards to compression, encryption and security”),
wherein the (page 2 para. 3 “The present invention relates to systems and methods for establishing and controlling a connection from a client to a destination server via multiple proxies using a network protocol”, page 15 par. 1 “Also, the proxy 120a-120n may be as part of or otherwise implemented in any type of network device, such as a router, firewall or switch … For example, the proxy 120a-120n may be a component of an application providing internet based security … corporate internal network 104, page 34 lines 20-30”),
the (page 2 para. 3 “The present invention relates to systems and methods for establishing and controlling a connection from a client to a destination server via multiple proxies using a network protocol”, page 15 par. 1 “Also, the proxy 120a-120n may be as part of or otherwise implemented in any type of network device, such as a router, firewall or switch … For example, the proxy 120a-120n may be a component of an application providing internet based security … corporate internal network 104, page 34 lines 20-30 “ At step 640, the client 208 may initiate a communication to the destination server 220 … In other cases, the first proxy 120a may not perform any computation and forward the network packet on the connection 202a”),
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rajput to incorporate the teachings of Panasyuk. One of ordinary skill in the art would have been motivated to make this modification in order to allow for compression.
Panasyuk does not teach hypertext transfer protocol, HTTP ,the HTTP payload communicated over the data plane connection is compressed while traversing at least one intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges, and the HTTP payload communicated over the data plane connection is not compressed while traversing at least one other intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges;
and - determine whether to compress a reconstructed hypertext transfer protocol, HTTP, payload received over the data plane connection before forwarding it onward to a network function in the second network.
Jensen teaches least one intermediate internet protocol exchange of the plurality of intermediate internet protocol exchanges, and the [0009] “In these embodiments, the intermediaries perform the compression. The first intermediary may perform compress data communicated by the server to the client via the remote display protocol and forwarding the compressed data to the second intermediary. The second intermediary may uncompress the compressed data and forwarding the uncompressed data to the client via the remote display protocol”, [0056] “the appliance 205 determines the server 106 to distribute the network packet by application information and data carried as payload of the transport layer packet”, (Examiner’s Note: data == data carried as payload, first and second intermediary == plurality of intermediate internet protocol exchanges).
[0009] “In these embodiments, the intermediaries perform the compression. The first intermediary may perform compress data communicated by the server to the client via the remote display protocol and forwarding the compressed data to the second intermediary. The second intermediary may uncompress the compressed data and forwarding the uncompressed data to the client via the remote display protocol”).
Jensen does not explicitly teach receive a hypertext transfer protocol, HTTP, HTTP payload, and - determine whether to compress a reconstructed hypertext transfer protocol, HTTP.
Bykumpadi teaches - receive a hypertext transfer protocol, HTTP (page 12, lines 19-25 “However, before two participating SEPPs (e.g., vSEPP 312 and hSEPP 322 in FIG. 3, or sSEPP 430-1 and rSEPP 430-2) can exchange protected HTTP messages, it is realized herein that it is important that the SEPPs first mutually authenticate each other and then exchange a set of parameters over a secure connection between the two entities. For example, the set of parameters that the two SEPPs agree on includes capability exchange, cipher suites to use for protection of HTTP message payload, protection policies that indicate which parameters to encrypt in each HTTP message, and so on. Such parameters therefore comprise one or more configuration parameters and/or one or more security parameters”);
HTTP payload (page 12 lines 19-25 For example, the set of parameters that the two SEPPs agree on includes capability exchange, cipher suites to use for protection of HTTP message payload),
and - determine whether to compress a reconstructed hypertext transfer protocol, HTTP (page 13, lines 15-23 “As mentioned above, there are intermediaries (IPX providers) between SEPPs that need to view and manipulate information in the RESTful API message (HTTP message). The cIPX is the IPX provider trusted by cSEPP, while the pIPX is the IPX provider trusted by pSEPP. However, there is no secure end-to-end (e2e) connection between cSEPP and pSEPP. There is only hop by hop security between two SEPPs. The SEPPs therefore implement ALS to protect the N32 interface. SEPPs ensure integrity and confidentiality protection for those elements on the application layer that are to be protected while allowing authorized IPX providers to view and modify elements in the HTTP message”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rajput, Panasyuk, Jensen to incorporate the teachings of Bykumpadi. One of ordinary skill in the art would have been motivated to make this modification in order to increase security.
Regarding claim 11,13 Rajput, Panasyuk, Jensen does not teach wherein the apparatus is configured to perform the determining based on a Content-Encoding header of the reconstructed HTTP payload that is received in the HTTP payload communicated over the data plane connection.
Bykampadi teaches wherein the apparatus is configured to perform the determining based on a Content-Encoding header of the reconstructed HTTP payload that is received in the HTTP payload communicated over the data plane connection (page 12 lines 15-25 “protection policies that indicate which parameters to encrypt in each HTTP message, and so on. Such parameters therefore comprise one or more configuration parameters and/or one or more security parameters”, page 13, lines 15-23 “As mentioned above, there are intermediaries (IPX providers) between SEPPs that need to view and manipulate information in the RESTful API message (HTTP message). The cIPX is the IPX provider trusted by cSEPP, while the pIPX is the IPX provider trusted by pSEPP. However, there is no secure end-to-end (e2e) connection between cSEPP and pSEPP. There is only hop by hop security between two SEPPs. The SEPPs therefore implement ALS to protect the N32 interface. SEPPs ensure integrity and confidentiality protection for those elements on the application layer that are to be protected while allowing authorized IPX providers to view and modify elements in the HTTP message”, ).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rajput, Panasyuk, Mui to incorporate the teachings of Bykumpadi. One of ordinary skill in the art would have been motivated to make this modification in order to increase security.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rajput, in view of Panasyuk, further in view of Jensen further in view of 3GPP (TS 33.501 V16.3.0 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system”, herein after 3GPP).
Response to Arguments
Applicant's arguments filed 10/24/2025 have been fully considered but they are not persuasive.
Applicant’s Argument 1
Applicant argues “Clear Error 1: Compressing or uncompressing a portion of a payload does not correspond to compressing or uncompressing an entire payload”.
Examiner’s Response 1
Examiner disagrees. The claims does not specify the whole payload must be compressed/uncompressed which I stated in response to applicant’s argument in advisory action 10/16/2025. More specifically, reference Jensen shows compressed and uncompressed payloads [0009] “The first intermediary may perform compress data communicated by the server to the client via the remote display protocol and forwarding the compressed data to the second intermediary. The second intermediary may uncompress the compressed data”.
Applicant’s Argument 2
Applicant argues “Clear Error 2: Acting on data does not correspond to not acting data”.
Applicant argues that reference Mui encapsulates the ID and data in [0073] and that is processing the payload.
Examiner’s Response 2
Claim 1 state “the payload remains unprocessed while being communicated via the plurality of intermediate internet protocol exchanges”. Address 112b issues regarding how the data remains not acted upon while also switching from compression and not. See updated rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEITH TRAN-DANH FOLLANSBEE whose telephone number is (571)272-3071. The examiner can normally be reached 10am -6 pm M-Th.
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, Derrick Ferris can be reached on 571-272-3123. 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.
/K.T.F./Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411