DETAILED ACTION
The objection to the specification is withdrawn based on the amendments filed 12/03/2025.
The objection to the claim is withdrawn based on the amendments filed 12/03/2025.
Some 112(b) rejections are withdrawn based on the amendments filed 12/03/2025.
The 101 rejection is withdrawn based on the amendments filed 12/03/2025.
Claim 6 is canceled.
Claims 1-5 and 7-20 are rejected.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 and 13 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In response to applicant's argument that “certain embodiments of the claimed invention provide distinct advantages that are not provided by any of the references cited in the present Office Action” on page 9 of the Remarks, it is noted that the features upon which applicant relies (i.e., “it is possible to provide a roaming intermediary (RI) that is capable of rejecting service-based request messages and provide appropriate information about the reason for the rejection to enable the originating SEPP to decide on a proper handling for the request and its rejection. In other embodiments, it is possible to provide error messages originating from roaming intermediaries for 5GC interconnections”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
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.
Claims 3 and 4 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.
Regarding claim 3, the amended claim language recites “terminating said message when said roaming service related request is modified and resent…” and “modifying said message as a modified message when said roaming service related request is not modified or resent…”. This claim limitation itself is contradictory because how can a message be terminated if the request is modified and resent/rerouted. Similarly, how can a message be modified if the request is not modified or resent/rerouted. Claim 4 inherits this rejection.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-5 and 7-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210248025 A1 to Nair et al. (Nair) in view of US 20210243165 A1 to Bykampadi et al. (Bykampadi), and in further view of US 20040192195 A1 to Soga et al. (Soga).
Regarding claim 1, Nair teaches an apparatus of a first network entity associated with a first network roaming interconnected with a second network, the apparatus comprising at least one processor (Nair [0012], e.g., executable program code that when executed by a processor causes the processor to perform the above steps), and at least one memory storing instructions (Nair [0012], e.g., non-transitory computer-readable storage medium having embodied therein executable program code) that, when executed by the at least one processor, cause the apparatus at least to perform: receiving a message indicative of a roaming service related error (Nair [0076], e.g., The existing N32 based interconnect interface is used by rSEPP 506 to send an N32 signaling message to sSEPP 504. This is denoted as step 6 in FIG. 5), wherein said message includes first error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions) related to said roaming service related error (Nair [0050-0051], e.g., In the scenario where the two communicating NFs are in two different PLMNs communication happens over a roaming inter-network interface (N32) between the two participating PLMNs…… To protect NF specific content in the messages that are sent over the roaming inter-network interface, 5G introduces the SEPP as the entity residing at the perimeter of the PLMN network) and addressed to said first network entity (Nair [0076], e.g., rSEPP 506 to send an N32 signaling message to sSEPP 504), and deciding on further handling of said message based on said first error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions), [wherein said first error cause information is encrypted with a first encryption key, wherein said roaming service related error comprises a network interface connection setup failure due to contractual reasons].
Nair does not explicitly teach, but Bykampadi teaches wherein said first [error cause] information is encrypted with a first encryption key (Bykampadi [0077-0078], e.g., The vSEPP encapsulates the header of the request into a JSON array called HTTP_Header, with each value in the array being a JWS object for the header in the original request…… For those JSON objects that require e2e confidentiality protection between the vSEPP and the hSEPP, the vSEPP executes JWE to encrypt the object; Note JWE (Java Web Encryption) uses keys for encryption).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Nair with the teachings of Bykampadi with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit preventing unauthorized access to private information (Bykampadi [0078], e.g., e2e confidentiality protection between the vSEPP and the hSEPP, the vSEPP) and ensure that messages are unaltered during transit (Bykampadi [0087], e.g., e2e protection from modification by the intermediaries).
Bykampadi does not explicitly teach, but Nair teaches the information being error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions).
Nair and Bykampadi do not explicitly teach, but Soga teaches wherein said roaming service related error comprises a network interface connection setup failure due to contractual reasons (Soga [0002]-[0008], e.g., A roaming service provides a user who has a contractual agreement with a communication provider, several communication services from another communication provider…… such contents are often protected by copyright…… in the case of contents that can be used (transmitted) only in Japan according to the contract, the transmission of contents is allowed in Japan, but the transmission of contents abroad is not allowed, Fig. 11 and [0083], e.g., When contents server CP1 receives the above-mentioned HTTP request (Step S107), detects roaming identification information by referring to the header of the request (Step S108). Then, contents server CP1 extracts the file name "photo.gif" in the HTTP request, and determines whether the file name "photo.gif" is allowed to be transmitted abroad by referring to the transmission table (Step S109). In this case, as shown in FIG. 8, since contents denoted by the file name "photo.gif" are not allowed to be transmitted abroad, contents server CP1 transmits an error message denoting that transmission is not allowed to mobile unit MS).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the combined teachings of Nair and Bykampadi with the teachings of Soga with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit preventing the transmission of inappropriate content (Soga [0095], e.g., According to the embodiment explained above, transmission of inappropriate contents can be prevented. In this case, inappropriate contents are contents which are protected by the copyright and are allowed to be used only in Japan, or contents determined not transmittable taking into account cultural restrictions).
Regarding claim 2, most of the limitations of this claim have been noted in the rejection of claim 1. Nair further teaches wherein said error is related to a roaming service related request (Nair [0047], e.g., the SEPP performs security management functions on information elements (IE) in HyperText Transport Protocol (HTTP) messages before the messages are sent externally over the roaming N32 interface), and the instructions, when executed by the at least one processor, cause the apparatus at least to perform: deciding on further handling of said roaming service related request based on said first error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions).
Regarding claim 3, most of the limitations of this claim have been noted in the rejection of claim 2. Nair further teaches wherein in relation to said deciding on further handling of said roaming service related request, the instructions, when executed by the at least one processor, cause the apparatus at least to perform: determining whether to modify and resend said roaming service related request (Nair [0080], e.g., b) Request end-to-end TLS to communicate directly to rSEPP 506 avoiding the IPX network) or whether to send said roaming service related request via a different route (Nair [0078-0079], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions. The following are some non-limiting examples of indicator flags used and the actions they represent: a) Use a different IPX route, for example, to bypass any detected malicious nodes), and in relation to said deciding on further handling of said message, the instructions, when executed by the at least one processor, cause the apparatus at least to perform: terminating, said message when said roaming service related request is modified and resent, or when said roaming service related request is sent via said different route (Nair [0090], e.g., c) Update the source network function (step 10). Send a “Failure” HTTP Response message to the source NF 502 after appropriate repackaging (with the N32 error code appropriately mapped to a corresponding HTTP error code)), and modifying, said message as a modified message when said roaming service related request is not modified or resent, or when said roaming service related request is not sent via said different route, and forwarding said modified message (Nair [0086-0089], e.g., i) If directed by rSEPP 506, sSEPP 504 determines whether there are one or more alternate sending routes available to rSEPP 506, and if available, resends the message over at least one of the one or more alternate routes; ii) Re-check or re-negotiate the security profile (e.g., cipher suites, etc.) which had been initially agreed upon in a preceding handshake procedure between sSEPP 504 and rSEPP 506; iii) If directed by rSEPP 506 or if deemed necessary by sSEPP 504, sSEPP 504 establishes an alternate security mechanism (such as, for example, e2e TLS) directly with rSEPP 506).
Regarding claim 4, most of the limitations of this claim have been noted in the rejection of claim 3. Nair further teaches wherein in relation to said modifying said message, the instructions, when executed by the at least one processor, cause the apparatus at least to perform: removing said first error cause information, or generalizing said first error cause information (Nair [0090], e.g., c) Update the source network function (step 10). Send a “Failure” HTTP Response message to the source NF 502 after appropriate repackaging (with the N32 error code appropriately mapped to a corresponding HTTP error code). In one illustrative embodiment, NF 502 is unaware of security error codes and receives a generic HTTP failure message with the HTTP error code closely mapped to the N32 error code).
Regarding claim 5, most of the limitations of this claim have been noted in the rejection of claim 2. Nair further teaches wherein said message is a roaming service related response in response to said roaming service related request (Nair [0086] b) Change the interactions of sSEPP 504 with rSEPP 506…… If directed by rSEPP 506, sSEPP 504 determines whether there are one or more alternate sending routes available to rSEPP 506, and if available, resends the message over at least one of the one or more alternate routes).
Regarding claim 7, most of the limitations of this claim have been noted in the rejection of claim 1. Nair does not explicitly teach, but Bykampadi teaches wherein said message includes second [error cause] information related to said roaming service [related error] and addressed to a second network entity (Bykampadi [0082], e.g., In step 625, the home IPX provider repeats the processing described above with respect to step 615 for any further modifications. In step 630, the home IPX provider sends the encapsulated request (e.g., the twice modified second message) to the hSEPP similar to step 610; Also see Fig. 6, e.g., modifications made by each entity is encapsulated), and said second [error cause] information is encrypted with a second encryption key (Bykampadi [0078], e.g., For those JSON objects that require e2e confidentiality protection between the vSEPP and the hSEPP, the vSEPP executes JWE to encrypt the object).
The motivation to combine is the same as that of claim 1.
Bykampadi does not explicitly teach, but Nair teaches the information being error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions) related to roaming service related error (Nair [0050-0051], e.g., In the scenario where the two communicating NFs are in two different PLMNs communication happens over a roaming inter-network interface (N32) between the two participating PLMNs…… To protect NF specific content in the messages that are sent over the roaming inter-network interface, 5G introduces the SEPP as the entity residing at the perimeter of the PLMN network).
Regarding claim 8, most of the limitations of this claim have been noted in the rejection of claim 7. Nair does not explicitly teach, but Bykampadi teaches wherein said first [error cause] information is combined with said second [error cause] information (Bykampadi [0082], e.g., In step 620, the visited IPX provider sends the encapsulated request (e.g., the once modified second message) to a second intermediary (e.g., the home network's IPX provider) similar to step 610. In step 625, the home IPX provider repeats the processing described above with respect to step 615 for any further modifications. In step 630, the home IPX provider sends the encapsulated request (e.g., the twice modified second message) to the hSEPP similar to step 610; Also see Fig. 6, e.g., each modification encapsulated).
The motivation to combine is the same as that of claim 1.
Bykampadi does not explicitly teach, but Nair teaches the information being error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions).
Regarding claim 9, most of the limitations of this claim have been noted in the rejection of claim 6. Nair does not explicitly teach, but Bykampadi teaches wherein said message includes third [error cause] information related to said roaming service [related error] and addressed to a third network entity (Bykampadi Fig. 6, e.g., steps 650-675 depicts at least 3 encapsulated responses).
The motivation to combine is the same as that of claim 1.
Bykampadi does not explicitly teach, but Nair teaches the information being error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions) related to roaming service related error (Nair [0050-0051], e.g., In the scenario where the two communicating NFs are in two different PLMNs communication happens over a roaming inter-network interface (N32) between the two participating PLMNs…… To protect NF specific content in the messages that are sent over the roaming inter-network interface, 5G introduces the SEPP as the entity residing at the perimeter of the PLMN network).
Regarding claim 10, most of the limitations of this claim have been noted in the rejection of claim 9. Nair does not explicitly teach, but Bykampadi teaches wherein said third [error cause] information is encrypted with said first encryption key, or said third [error cause] information is encrypted with a third encryption key (Bykampadi Fig. 6, e.g., steps 650-675 depicts at least 3 encapsulated responses; Also [0086], e.g., The part(s) of the intermediate data structure that require(s) end-to-end (e2e) confidentiality protection is/are encrypted (e.g., using JWE); Note each JWE block is encrypted using a newly generated key; Also Note each modification could comprise JSON objects that require e2e confidentiality protection).
The motivation to combine is the same as that of claim 1.
Bykampadi does not explicitly teach, but Nair teaches the information being error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions).
Regarding claim 11, most of the limitations of this claim have been noted in the rejection of claim 9. Nair does not explicitly teach, but Bykampadi teaches wherein at least one of the following: said first [error cause] information is signed utilizing a message initiating entity’s signing key, or said second [error cause] information is signed utilizing the message initiating entity’s signing key, or said third [error cause] information is signed utilizing the message initiating entity’s signing key (Bykampadi [0089], e.g., In some embodiments, each modification chain entry is integrity protected with the signature of the intermediary that has performed the modification. This way, the rSEPP 430-2 can subsequently determine separately for each change whether it was performed by an authorized intermediary 440 and whether it complies with the modification policy for that intermediary).
The motivation to combine is the same as that of claim 1.
Bykampadi does not explicitly teach, but Nair teaches the information being error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions).
Regarding claim 12, most of the limitations of this claim have been noted in the rejection of claim 1. Nair further teaches wherein said message is a multipart message having a multipart body (Nair [0055], e.g., various parts of the HTTP message including, but not limited to, HTTP Request/Response Line, HTTP header and HTTP Payload), and said first error cause information is included in one part of said multipart body (Nair [0077], e.g., the new message comprises the error code(s) generated in part one of the framework, with an additional set of elements or indicator flags that direct sSEPP 504 to initiate and/or perform a certain set of recovery actions on its end).
Regarding claim 13, Nair teaches an apparatus of a second network entity involved in roaming related communication between a first network roaming interconnected with a second network and the second network, the apparatus comprising at least one processor (Nair [0012], e.g., executable program code that when executed by a processor causes the processor to perform the above steps), and at least one memory storing instructions that (Nair [0012], e.g., non-transitory computer-readable storage medium having embodied therein executable program code), when executed by the at least one processor, cause the apparatus at least to perform: generating a message indicative of a roaming service related error (Nair [0062], e.g., rSEPP 506 detects the one or more errors and generates one or more appropriate error codes), wherein said message includes first error cause information related to said roaming service related error and addressed to a first network entity (Nair [0076-0077] The existing N32 based interconnect interface is used by rSEPP 506 to send an N32 signaling message to sSEPP 504…… the new message comprises the error code(s) generated in part one of the framework, with an additional set of elements or indicator flags that direct sSEPP 504 to initiate and/or perform a certain set of recovery actions on its end), [and second error cause information related to said roaming service related error and addressed to a second network entity,] and transmitting said message towards said first network entity (Nair [0076] The existing N32 based interconnect interface is used by rSEPP 506 to send an N32 signaling message to sSEPP 504. Note first entity = sSEPP, second entity = rSEPP), [wherein in relation to said generating, the instructions, when executed by the at least one processor, cause the apparatus at least to perform: encrypting said first error cause information with a first encryption key, wherein said roaming service related error comprises a network interface connection setup failure due to contractual reasons].
Nair does not explicitly teach, but Bykampadi teaches wherein said message includes second [error cause] information related to said roaming service [related error] and addressed to a second network entity (Bykampadi [0082], e.g., In step 625, the home IPX provider repeats the processing described above with respect to step 615 for any further modifications. In step 630, the home IPX provider sends the encapsulated request (e.g., the twice modified second message) to the hSEPP similar to step 610; Also see Fig. 6, e.g., modifications made by each entity is encapsulated), and wherein in relation to said generating, the instructions, when executed by the at least one processor, cause the apparatus at least to perform: encrypting said first [error cause] information with a first encryption key (Bykampadi [0077-0078], e.g., The vSEPP encapsulates the header of the request into a JSON array called HTTP_Header, with each value in the array being a JWS object for the header in the original request…… For those JSON objects that require e2e confidentiality protection between the vSEPP and the hSEPP, the vSEPP executes JWE to encrypt the object; Note JWE (Java Web Encryption) uses keys for encryption).
The motivation to combine is the same as that of claim 1.
Bykampadi does not explicitly teach, but Nair teaches the information being error cause information (Nair [0078], [0084], e.g., The indicator flags, when set by rSEPP 506, are checked (step 7) and used in sSEPP 504 to execute a specific set of actions…… The sSEPP reviews the obtained error code(s) (step 8) and takes appropriate actions).
Nair and Bykampadi do not explicitly teach, but Soga teaches wherein said roaming service related error comprises a network interface connection setup failure due to contractual reasons (Soga [0002]-[0008], e.g., A roaming service provides a user who has a contractual agreement with a communication provider, several communication services from another communication provider…… such contents are often protected by copyright…… in the case of contents that can be used (transmitted) only in Japan according to the contract, the transmission of contents is allowed in Japan, but the transmission of contents abroad is not allowed, Fig. 11 and [0083], e.g., When contents server CP1 receives the above-mentioned HTTP request (Step S107), detects roaming identification information by referring to the header of the request (Step S108). Then, contents server CP1 extracts the file name "photo.gif" in the HTTP request, and determines whether the file name "photo.gif" is allowed to be transmitted abroad by referring to the transmission table (Step S109). In this case, as shown in FIG. 8, since contents denoted by the file name "photo.gif" are not allowed to be transmitted abroad, contents server CP1 transmits an error message denoting that transmission is not allowed to mobile unit MS).
The motivation to combine is the same as that of claim 1.
Regarding claim 14, the claim recites a second network entity performing operations of the first network entity of claim 7, and is similarly analyzed. It should also be noted that the roles of the hSEPP and sSEPP can be reversed (Bykampadi [0076], e.g., FIG. 6 shows an example message flow 600 across N32 based on integrity protection with modification tracking based on forward delta. In steps 602 to 640, the visited SEPP (vSEPP) acts as the sending SEPP (e.g., sSEPP 430-1) and the home SEPP (hSEPP) acts as the receiving SEPP (e.g., sSEPP 430-2). In steps 645 to 685, the roles are reversed).
Regarding claim 15, the claim recites a second network entity performing operations of the first network entity of claim 8, and is similarly analyzed. Also see Bykampadi para.[0076] which explains the roles of the network entities being reversable.
Regarding claim 16, the claim recites a second network entity performing similar operations of the first network entity of claim 9, and is similarly analyzed. Also see Bykampadi para.[0076] which explains the roles of the network entities being reversable.
Regarding claim 17, the claim recites a second network entity performing similar operations of the first network entity of claim 10, and is similarly analyzed. Also see Bykampadi para.[0076] which explains the roles of the network entities being reversable.
Regarding claim 18, the claim recites a second network entity performing similar operations of the first network entity of claim 11, and is similarly analyzed. Also see Bykampadi para.[0076] which explains the roles of the network entities being reversable.
Regarding claim 19, most of the limitations of this claim have been noted in the rejection of claim 13. Nair further teaches wherein said error is related to a roaming service related request (Nair [0047], e.g., the SEPP performs security management functions on information elements (IE) in HyperText Transport Protocol (HTTP) messages before the messages are sent externally over the roaming N32 interface), and said message is a roaming service related response in response to said roaming service related request (Nair [0086] b) Change the interactions of sSEPP 504 with rSEPP 506…… If directed by rSEPP 506, sSEPP 504 determines whether there are one or more alternate sending routes available to rSEPP 506, and if available, resends the message over at least one of the one or more alternate routes). Note that Nair also teaches the roles of the network entities being interchangeable (Nair [0054], e.g., Note that in one scenario, vSEPP 414 is the sSEPP and hSEPP 434 is the rSEPP, while in another scenario, hSEPP 434 is the sSEPP and vSEPP 414 is the rSEPP).
Regarding claim 20, the claim recites a second network entity performing similar operations of the first network entity of claim 12, and is similarly analyzed. Also see Bykampadi para.[0076] which explains the roles of the network entities being reversable.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20230136425 A1 to Kim et al. discloses [0321], e.g., For example, when a UE that has been provided with a service through a source network (PLMN or SNPN) moves toward a target network (SNPN or PLMN), the NG-RAN of the source network may attempt handover of the UE to the NG-RAN of the target network. However, if the N14 interface does not exist between the AMF of the source network and the AMF of the target network because a service level agreement (SLA) is not established between the source network and the target network, this handover attempt may fail.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE Q TRUONG whose telephone number is (571)272-6973. The examiner can normally be reached Monday - Friday, 7:30 am - 5 pm 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, Kambiz Zand can be reached at (571) 272-3811. 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.
/LAWRENCE Q TRUONG/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434