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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/18/26 has been entered.
Response to Arguments
Applicant argues no combination of the applied references would have rendered claim 1 prima facie obvious for at least the following reasons.
First, Nair does [neither teaches] nor suggests "determining, by the first SEPP device, that the roaming message cannot be processed is based on a determination that one or more of the roaming message cannot be decrypted, a JavaScript Object Notation (JSON) patch program fails to be applied to a modified block of the roaming message, or a hypertext transfer protocol version 2 (HTTP/2) message fails to be reconstructed based on the roaming message."
Nair describes an error handling framework where the receiving SEPP (rSEPP) detects errors and generates error codes. Nair states that "the received N32 message is first verified through a series of steps before it is accepted for reassembly into a HTTP message. This process of verification may fail (i.e., result in an error condition) for many reasons. The error could be, by way of example only, due to a malicious intermediate node manipulating the N32 message resulting in an integrity check failure, packet loss due to congestion, a malicious man-in-the- middle (MITM) attacker consciously deleting part of the message related to subscription and
identities or service authorization, etc." (see Nair, p. 12, lines 18-24).
However, Nair does not teach or suggest that the determination that the roaming message cannot be processed is based on a determination that "the roaming message cannot be decrypted, a JavaScript Object Notation (JSON) patch program fails to be applied to a modified block of the roaming message, or a hypertext transfer protocol version 2 (HTTP/2) message fails to be reconstructed based on the roaming message."
Nair's error conditions are limited to integrity check failure, packet loss, and MITM attack. Nair does not appear to describe decryption failure, JSON patch failure, or HTTP/2 reconstruction failure. Yua does not address error handling or what happens when a JSON patch program fails to be applied or when an HTTP/2 message fails to be reconstructed. Yua's system is directed to routing messages through an NF Proxy Platform, not to error handling when processing fails.
As a matter of interpretation, the Examiner points the Applicant to the above remarks e.g., “Nair describes an error handling framework where the receiving SEPP (rSEPP) detects errors and generates error codes.” An error by definition is the state or condition of being wrong in conduct or judgment. Error is synonymous with wrongly, mistake, mistakenly, incorrectly, inappropriately, misguidedly, accidentally, by accident, inadvertently, unintentionally, unwittingly, unknowingly, unconsciously or by chance. Based on this understanding a PHOSITA would appreciate “error handling” …that … “detects errors and generates error codes” can occur based on handling something wrongly, a mistake, mistakenly handled, incorrectly handled, inappropriately handling…and generating codes (i.e., a reason). Therefore, the error handling and error codes cited in Nair is a catch-all encompassing a variety of different elements or possibilities of error. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date to try generating error codes based on:
the roaming message cannot be decrypted – this would fit under the umbrella of an error definition or
a JavaScript Object Notation (JSON) patch program fails to be applied to a modified block of the roaming message- error (cause) failures(result) or vice versa.
or a hypertext transfer protocol version 2 (HTTP/2) message fails to be reconstructed based on the roaming message - error (cause) failures(result) or vice versa.
For the sake of completeness, the Examiner has provided references and rationale for the above argument in the rejection below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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, 3-7, 9-14, 16, 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nair et al. WO 2019/220006, hereinafter, ‘Nair’ in view of Yua et al. US Patent No.: 11, 076, 821 B1, hereinafter, ‘Yua’ and further in view of Hollis et al. US Patent Pub. No.: 2003/0202663, hereinafter, ‘Hollis’.
Consider Claims 1, 10, 18 and 20 (See SEPP devices e.g., at least a first and second and Network architecture in at least figure 5 and individual element architecture in at least figure 2 and as described in the context of paragraphs 0091 -0092 ), Nair teaches a communication method, comprising: receiving, by a first security edge protection proxy (SEPP) device, a roaming message from an IP exchange (IPX) operator device, wherein the roaming message is used to implement a roaming service between the first SEPP device and a second SEPP device (e.g., see at least step 2 figure 5); determining, by the first SEPP device, that the roaming message cannot be processed (e.g., see error message in at least figure 5); and in response to determining that the roaming message cannot be processed, sending, by the first SEPP device, a feedback message to the IPX operator device, wherein the feedback message is used to indicate that the first SEPP device cannot process the roaming message (e.g., see at least step 6 of figure 5).
However, Nair does not specifically teach an IP exchange (IPX) operator device comprising at least one of a diameter routing agent (DRA) device, a domain name server (DNS), or a hypertext transfer protocol (HTTP) proxy.
In analogous art, Yua teaches an IP exchange (IPX) operator device comprising at least one of a diameter routing agent (DRA) device, a domain name server (DNS), or a hypertext transfer protocol (HTTP) proxy (e.g., see HTTP proxy in at least figures 6-11 – “the HTTP Proxy is in communication with a VPLMN Security Edge Protection Proxy (V-SEPP) and a HPLMN SEPP (H-SEPP” – Claim 3).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date to modify Nair to include an IP exchange (IPX) operator device comprising at least one of a diameter routing agent (DRA) device, a domain name server (DNS), or a hypertext transfer protocol (HTTP) proxy for the purpose of facilitating network messages and roaming.
However, Nair as modified by Yua does not specifically teach wherein the determining, by the first SEPP device, that the roaming message cannot be processed is based on a determination that one or more of the roaming message cannot be decrypted, a JavaScript Object Notation (JSON) patch program fails to be applied to a modified block of the roaming message, or a hypertext transfer protocol version 2 (HTTP/2) message fails to be reconstructed based on the roaming message.
Nair describes an error handling framework where the receiving SEPP (rSEPP) detects errors and generates error codes.” An error by definition is the state or condition of being wrong in conduct or judgment. Error is synonymous with wrongly, mistake, mistakenly, incorrectly, inappropriately, misguidedly, accidentally, by accident, inadvertently, unintentionally, unwittingly, unknowingly, unconsciously or by chance. Based on this understanding a PHOSITA would appreciate “error handling” …that … “detects errors and generates error codes” can occur based on handling something wrongly, a mistake, mistakenly handled, incorrectly handled, inappropriately handling…and generating codes (i.e., a reason). Therefore, the error handling and error codes cited in Nair is a catch-all encompassing a variety of different elements or possibilities of error.
For the sake of completeness on the record, Hollis is directed towards secure message-oriented network communication. Hollis teaches a network element that reacts to failed decryption attempts by returning an error code that indicates the reason for failure and forwarding the message to another network element – see at least 0058. In other words, it is fairly known in the art that a decryption failure results in an error or an error can result in a decryption failure.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date to try generating error codes based on at least a message that cannot be decrypted for the purpose of secure communications.
Consider Claims 3 and 12, Nair teaches wherein before the receiving, by the first SEPP device, the roaming message from the IPX operator device, the communication method further comprises: sending, by the first SEPP device, a roaming request message to the IPX operator device, wherein the roaming request message is used to request the roaming service from the second SEPP device, the roaming request message comprises an address of the second SEPP device, and the roaming message is a roaming response message generated by the second SEPP device based on the roaming request message (this is met based on the HTTP message in the context of figure 5 as explained on at least page 13).
Consider Claims 4 and 13, Nair teaches the claimed invention further comprising: determining, by the first SEPP device, the address of the second SEPP device based on the roaming message, wherein the feedback message comprises the address of the second SEPP device, and the feedback message is used to indicate that the first SEPP device cannot process the roaming response message (e.g., see error message in at least figure 5).
Consider Claims 5 and 14, Nair teaches wherein the roaming message is a roaming request message used to request the roaming service from the first SEPP device, and the roaming message comprises an address of the first SEPP device(this is met based on the HTTP message in the context of figure 5 as explained on at least page 13).
Consider Claim 6, Nair teaches wherein the determining, by the first SEPP device, that the first SEPP device cannot process the roaming message is further based on a determination that one or more of, an integrity check on the roaming message fails, or an integrity check on the modified block of the roaming message fails (e.g., page 13 lines 10-15 – “It is assumed that one or more errors occur with respect to the N32 message sent by sSEPP 504. The one or more errors could be caused by one or more of the above-mentioned reasons (e.g., an integrity check failure, a packet loss, an MITM attacker, etc.) or some other reason.).
Consider Claims 7, Nair teaches wherein the feedback message is further used to indicate a reason why the first SEPP device cannot process the roaming message (e.g., see at least the error handling noted on pages 14-15).
Consider Claims 9, Nair teaches wherein after the determining, by the first SEPP device, that the roaming message cannot be processed, the communication method further comprises: sending, by the first SEPP device, the feedback message to a network function (NF) device (e.g., see flow in at least figure 5).
Consider Claim 16, Nair teaches wherein the reason is additionally that at least one of an integrity check on the roaming message failed or an integrity check on the modified block of the roaming message failed(e.g., page 13 lines 10-15 – “It is assumed that one or more errors occur with respect to the N32 message sent by sSEPP 504. The one or more errors could be caused by one or more of the above-mentioned reasons (e.g., an integrity check failure, a packet loss, an MITM attacker, etc.) or some other reason.)
Claim(s) 2, 8, 17 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nair et al. WO 2019/220006, hereinafter, ‘Nair’ in view of Yua et al. US Patent No.: 11, 076, 821 B1, hereinafter, ‘Yua’ in view of Hollis et al. US Patent Pub. No.: 2003/0202663, hereinafter, ‘Hollis’ and further in view of 3rd Generation Partnership Project; ‘Technical Specification Group Services and System Aspects; Security Aspects; Study on security aspects of the 5S Service Based Architecture (SBA) (Release 16)", 3GPP DRAFT; 33855-130CL, 3RD GENERATION PARTNERSHIP PROJECT (SGPP}), MOBILE
COMPETENCE CENTRE; 650, ROUTE DES LUCIOLES; F-06921 SOPHIA-ANTIBOLIS CEDEX FRANCE 16 November 2018 (2018-11-14).
Consider Claims 8 and 17, Nair teaches the claimed invention except wherein the feedback message comprises an N32f context identifier, and after the receiving, by the second SEPP device, the feedback message from the IPX operator device, the communication method further comprises: obtaining, by the second SEPP device, a target shared key corresponding to the N32f context identifier; and decrypting, by the second SEPP device, the feedback message by using the target shared key.
In analogous art, 3GPP teaches on pages 13-17 specify matters of security and shared security keys with respect to IPX providers.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing dates to try specifying matters of security and shared security keys with respect to IPX providers to arrive at the predictable result wherein the feedback message comprises an N32f context identifier, and after the receiving, by the second SEPP device, the feedback message from the IPX operator device, the communication method further comprises: obtaining, by the second SEPP device, a target shared key corresponding to the N32f context identifier; and decrypting, by the second SEPP device, the feedback message by using the target shared key for the purpose of integrity protection.
Consider Claims 2 and 19, Nair teaches the claimed invention except further comprising: in response to the first SEPP device and the second SEPP device exchanging a target shared key by using an N32c link, releasing, by the first SEPP device, the N32c link, wherein the target shared key is used to implement secure communication between the first SEPP device and the second SEPP device.
In analogous art, 3GPP teaches on pages 13-17 specify matters of security and shared security keys with respect to IPX providers.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing dates to try specifying matters of security and shared security keys with respect to IPX providers to arrive at the predictable result in response to the first SEPP device and the second SEPP device exchanging a target shared key by using an N32c link, releasing, by the first SEPP device, the N32c link, wherein the target shared key is used to implement secure communication between the first SEPP device and the second SEPP device for the purpose of integrity protection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 5841873 A teaches a data communications system, including an infrastructure arranged to communicate over a data channel with a plurality of data terminals, a method of detecting data decryption errors in a data packet includes receiving an encrypted data packet (213); decrypting the encrypted data packet to provide a decrypted data packet; and comparing a reference value to a portion of the decrypted data packet to determine when a predetermined relationship is satisfied (221).
WO 2020094914 A1 teaches receiving a first message from a service-consuming second network entity in a second mobile network for a service-providing first network entity in a first mobile network, the first message comprising a first callback resource identifier, generating a second callback resource identifier on the basis of the first callback resource identifier, wherein the second callback resource identifier comprises a domain name of a security edge node in the first network, and transferring a callback message from the first network entity to the security edge node, the callback message comprising the second callback resource identifier
PNG
media_image1.png
308
622
media_image1.png
Greyscale
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