DETAILED ACTION
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 08/07/2026 has been entered.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The instant first office action is in response to communication filed on 08/07/2026.
Claims 26, 28, 31-34, 36, 39-42, 46-48 and 52-53 are pending of which claims 26, 34, 42 and 48 are the base independent claims.
Response to Arguments
Applicant’s arguments with respect to claim(s) 26, 28, 31-34, 36, 39-42, 46-48 and 52-53 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.
Further, the amended limitations are in fact taught by the previously cited prior art along with new cited prior art. For a detailed explanation on how the prior art reads on the claims as amended, please see the rejection below.
Response to Arguments
Applicant's arguments filed 08/07/2026 have been fully considered but they are not persuasive.
With respect to the time period, the examiner further map the limitation with respect to lifetime including in the EAS discovery response based on further update that indicate lifetime/back-off timer is used to indicate how long/waiting before making a new request.
Regarding claim 1, the applicant alleged that the combined system of “3GPP’558 and Kim’473 and Svennebring’331”fails to show or merely suggest “receive, from the EES, an EAS discovery response including a Hypertext Transfer Protocol (HTTP) status code indicating that the EAS discovery request has failed in a case in which because the EAS discovery request is rejected by the EES due to an overload state of based on an EAS load state” as recited by applicant on page “10-11 of 13 ”.
In response, the examiner respectfully disagrees because in this case, the combined system of “3GPP’558 and Kim’473 and Svennebring’331” explicitly teaches the above limitation.
3GPP’558 teaches receive, from the EES, an EAS discovery response (including a hypertext transfer Protocol (HTTP) status code) indicating that the EAS discovery request is failed in a case in which the EAS request is rejected by the EES (see fig.8.5.2.2-1, which shows Edge Application server discovery response & see page 60, 2., if the EES is unable to determine the EAS information using the inputs in the EAS discovery request…, the EES shall reject the service provision request and respond an appropriate failure cause, see table 8.5.3.2-1, which shows Edge Application server discovery response includes failure response indicates that the EAS discovery request failed and cause indicates the cause of the EAS discovery request failure).
Kim’473 teaches in a case in the EAS discovery request is rejected due to an overload state of an EAS (see para.0 179, which discusses with a rejection cause meaning congestion, overload, insufficient resources, and the like and may be provided to the UE).
Svennebring’331 teaches the use of response including a hypertext transfer Protocol (HTTP) status code(see para.0402, which discusses the HTTP response message may include other HTTP status codes, such as a bad request status code (400) (e.g., when incorrect parameters are passed in the request), a not found status code (404) (e.g., when a Universal Resource Indicator (URI) provided in the request cannot be mapped to a valid resource URI), a forbidden status code (403) (e.g., when the operation is not allowed given the current status of the resource), and/or other like HTTP status codes. In the aforementioned examples, the response body may include a ProblemDetails data type indicating/including information about the particular error, thus a forbidden status code (403) (e.g., when the operation is not allowed/rejected given the current status of the resource), see fig.28, which shows edge enabler client and Edge Enabler Server).
Thus, the claimed limitation is met.
Regarding claims 34, 42 and 48, the same argument as claim 26 is also applied to claims 34, 42 and 48 since claims 34, 42 and 48 recited similar features as claim 26.
Regarding claims 28, 31-33, 36, 39-41, 46-47 and 52-53, the same argument as independent claim 26 is also applied to claims 28, 31-33, 36, 39-41, 46-47 and 52-53 since claims 28, 31-33, 36, 39-41, 46-47 and 52-53 are each depend either directly or indirectly from independent claims 26 as discussed above.
In response to applicant's arguments against the references individually (see pages 10-13), one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, the rejection is based on the combined system of 3GPP’558 and Kim’473 and Svennebring’331, and thus obviousness analysis should be performed on the combined system of 3GPP’558 and Kim’473 and Svennebring’331, rather than argued by the applicant based on the individual references and its claimed invention. Clearly, as set forth in response above and rejection set forth below, it is clear that the combined system of 3GPP’558 and Kim’473 and Svennebring’331 discloses the claimed invention.
In response to applicant's argument that there is no suggestion to combine the references(see page 10-13), the examiner recognizes that obviousness can only be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, the suggestion to combined the references was shown in the background of the secondary reference(s).
In response to applicant's argument that the secondary references are nonanalogous art(see page 10-13), it has been held that a prior art reference must either be in the field of applicant’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the applicant was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, all references are communication system and therefore analogous.
In response to applicant's argument that the references are not combinable(see page 10-13), the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
In the case, the combined teaching of 3GPP’558 and Kim’473 and Svennebring’331 would show “receive, from the EES, an EAS discovery response including a Hypertext Transfer Protocol (HTTP) status code indicating that the EAS discovery request has failed in a case in which because the EAS discovery request is rejected by the EES due to an overload state of based on an EAS load state”
In view of the above, it is clear the previously cited prior arts still disclose the applicant claim invention as set detailed 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.
Claim(s) 26, 28, 31-34, 36, 39-42, 46-48 and 52-53 is/are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP (3GPP TS.23.558 V1.2.0 (2020-11), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspect; Architecture for enabling Edge Applications; (Release 17), in view of Kim et al (US 2019/0313473) and further in view of Svennebring et al (US 2022/0303331).
Regarding claim 26, 34, 3GPP’558 discloses a radio terminal comprising:
send an Edge Application Server (EAS) discovery request toward an edge server(ESS)(see fig.8.5.2.2-1 & see page 60, 1. The edge enable client as radio terminal sends an edge application server discovery request towards Edge enable server(EES), see fig.8.4.3.2.2-1); and
receive, from the EES, an EAS discovery response (including a hypertext transfer Protocol (HTTP) status code) indicating that the EAS discovery request is failed in a case in which the EAS request is rejected by the EES (see fig.8.5.2.2-1, which shows Edge Application server discovery response & see page 60, 2., if the EES is unable to determine the EAS information using the inputs in the EAS discovery request…, the EES shall reject the service provision request and respond an appropriate failure cause, see table 8.5.3.2-1, which shows Edge Application server discovery response includes failure response indicates that the EAS discovery request failed and cause indicates the cause of the EAS discovery request failure);
wherein the EAS discovery response(see 8.5.3.2, which discusses Edge Application server discovery response) further includes information indicating a time period that the radio terminal has to wait before performing a new EAS discovery request(see 8.5.3.2, which discusses Edge Application server discovery response including at least lifetime that indicate time interval or duration during which the information elements in the EAS profile and supposed to be cached in the EEC (e.g. time to live value for an EAS endpoint), see page 60, which discusses if the lifetime IE is included in the response, the Edge enabler client may cache the Edge application information only for the duration specified by the lifetime IE…, see page 61, which discusses if the EAS discovery request fails, the edge enable client can resend the EAS discovery request again, thus lifetime as validity/time period for how long/waiting the radio terminal/ Edge enabler client can use the use information before it must perform a new EAS discovery request).
As discussed above, although 3GPP’558 discloses receive a response including information that the EAS discovery request is failed(see fig.8.5.2.2-1, which shows Edge Application server discovery response & see page 60, 2., if the EES is unable to determine the EAS information using the inputs in the EAS discovery request…, the EES shall reject the service provision request and respond an appropriate failure cause, see table 8.5.3.2-1, which shows Edge Application server discovery response includes failure response indicates that the EAS discovery request failed and cause indicates the cause of the EAS discovery request failure), 3GPP’558 does not explicitly show the use of “at least one memory; and at least one processor coupled to the at least one memory and configured to; in a case in which the EAS discovery request is rejected by the EES due to an overload state of an EAS” as required by present claimed invention. However, including “at least one memory; and at least one processor coupled to the at least one memory and configured to; in a case in which the EAS discovery request is rejected by the EES due to an overload state of an EAS” would have been obvious to one having ordinary skill in the art as evidenced by Kim’473.
In particular, in the same field of endeavor, Kim’473 teaches the use of at least one memory; and at least one processor coupled to the at least one memory and configured to(see para.0078, processor, see fig.9, storage 101 as memory) in a case in the EAS discovery request is rejected due to an overload state of an EAS (see para.0 179, which discusses with a rejection cause meaning congestion, overload, insufficient resources, and the like and may be provided to the UE), wherein the EAS discovery response further includes information indicating a time period that the radio terminal has to wait before performing a new EAS discovery request(see para.0179, which discusses the network may transmit a reject message to the request from the UE. The rejection message may include a back-off/wait timer for mobility management congestion control together with a rejection cause meaning congestion, overload, insufficient resources, and the like and may be provided to the UE. In this case, the back-off timer may operate according to information such as the corresponding UE type, service type, communication type, and specific group. That is, the back-off timer is bound with information such as the corresponding UE type, service type, communication type, and specific group and operates, see also para.0182, see para.0020, which discusses network transmits a back-off timer value via an NAS Reject message to a UE in idle mode or connected mode, and the UE does not request an EMM/GMM/(E)SM signal from the network until the back-off timer expires, see para.0027, 0031, see para.0020, which discusses back-off timer value via an NAS Reject message to a UE in idle mode or connected mode, and the UE does not request an EMM/GMM/(E)SM signal from the network until the back-off timer expires).
In view of the above, having the system of 3GPP’558 and then given the well-established teaching of Kim’473, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of 3GPP’558 to include “at least one memory; and at least one processor coupled to the at least one memory and configured to; in a case in which the EAS discovery request is rejected by the EES due to an overload state of an EAS” as taught by Kim’473, since Kim’473 stated in para.0070+ that such a modification would provide a congestion control method for next generation mobile communication.
As discussed above, although the combined system of 3GPP’558 and Kim’473 discloses receive a response including information that the EAS discovery request is failed(3GPP’558, see fig.8.5.2.2-1, which shows Edge Application server discovery response & see page 60, 2., if the EES is unable to determine the EAS information using the inputs in the EAS discovery request…, the EES shall reject the service provision request and respond an appropriate failure cause, see table 8.5.3.2-1, which shows Edge Application server discovery response includes failure response indicates that the EAS discovery request failed and cause indicates the cause of the EAS discovery request failure), the combined system of 3GPP’558 and Kim’473 does not explicitly show the use of “response including a hypertext transfer Protocol (HTTP) status code” as required by present claimed invention. However, including “response including a hypertext transfer Protocol (HTTP) status code” would have been obvious to one having ordinary skill in the art as evidenced by Svennebring’331.
In particular, in the same field of endeavor, Svennebring’331 teaches the use of response including a hypertext transfer Protocol (HTTP) status code(see para.0402, which discusses the HTTP response message may include other HTTP status codes, such as a bad request status code (400) (e.g., when incorrect parameters are passed in the request), a not found status code (404) (e.g., when a Universal Resource Indicator (URI) provided in the request cannot be mapped to a valid resource URI), a forbidden status code (403) (e.g., when the operation is not allowed given the current status of the resource), and/or other like HTTP status codes. In the aforementioned examples, the response body may include a ProblemDetails data type indicating/including information about the particular error, thus a forbidden status code (403) (e.g., when the operation is not allowed/rejected given the current status of the resource), see fig.28, which shows edge enabler client and Edge Enabler Server).
In view of the above, having the combined system of 3GPP’558 and Kim’473 and then given the well-established teaching of Svennebring’331 it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the combined system of 3GPP’558 and Kim’473 to include “response including a hypertext transfer Protocol (HTTP) status code” as taught by Svennebring’331, since Svennebring’331 stated in para.0052+ that such a modification would optimize the performance of media streaming applications and services by proactively adapting to variations in link quality before they occur. In this manner, the media streaming experience can be proactively tuned to accommodate predicted variations in link performance while also prioritizing the performance metrics that are most important to the particular streaming service.
Regarding claim 28, 36, 43, 3GPP’558 discloses wherein the radio terminal comprises an Edge Enabler Client (EEC)(see fig.8.5.2.2-1 & see page 60, 1. The edge enable client(EEC) as radio terminal sends an edge application server discovery request towards Edge enable server(EES)).
Regarding claim 31, 39, 46, 52, 3GPP’558 discloses wherein the EES is located in an Edge Data Network (EDN)(see figure 6.2-1, which shows EES is located in an Edge Data Network (EDN)).
Regarding claim 32, 40, 47, 53, 3GPP’558 discloses wherein the EDN comprises an EAS((see figure 6.2-1, which shows the EDN comprises an Edge Application server(EAS).
Regarding claim 33, 41, 3GPP’558 discloses wherein the radio terminal includes any one(due to one language, only one of them is being considered) of: a User Equipment (UE); a mobile station; a mobile terminal; a cellular phone; a smart phone; a tablet; a cellular Internet of Things (IoT) terminal; or an IoT device (see figure 6.2-1, which shows wherein the radio terminal includes any one of: a User Equipment (UE)).
Regarding claim 42, 48, 3GPP’558 discloses an Edge Enabler server(EES) comprising: receive an Edge Application Server (EAS) discovery request sent from a radio terminal(see fig.8.5.2.2-1 & see page 60, 1. The edge enable client as radio terminal sends an edge application server discovery request towards Edge enable server(EES), thus receive); and send to the radio terminal an EAS discovery response (including a hypertext transfer Protocol (HTTP) status code) indicating that the EAS discovery request is failed in a case in which the EAS request is rejected by the EES (see fig.8.5.2.2-1, which shows Edge Application server discovery response & see page 60, 2., if the EES is unable to determine the EAS information using the inputs in the EAS discovery request…, the EES shall reject the service provision request and respond an appropriate failure cause, see table 8.5.3.2-1, which shows Edge Application server discovery response includes failure response indicates that the EAS discovery request failed and cause indicates the cause of the EAS discovery request failure).
wherein the EAS discovery response(see 8.5.3.2, which discusses Edge Application server discovery response) further includes information indicating a time period that the radio terminal has to wait before performing a new EAS discovery request(see 8.5.3.2, which discusses Edge Application server discovery response including at least lifetime that indicate time interval or duration during which the information elements in the EAS profile and supposed to be cached in the EEC (e.g. time to live value for an EAS endpoint), see page 60, which discusses if the lifetime IE is included in the response, the Edge enabler client may cache the Edge application information only for the duration specified by the lifetime IE…, see page 61, which discusses if the EAS discovery request fails, the edge enable client can resend the EAS discovery request again, thus lifetime as validity/time period for how long/waiting the radio terminal/ Edge enabler client can use the use information before it must perform a new EAS discovery request).
As discussed above, although 3GPP’558 discloses receive a response including information that the EAS discovery request is failed(see fig.8.5.2.2-1, which shows Edge Application server discovery response & see page 60, 2., if the EES is unable to determine the EAS information using the inputs in the EAS discovery request…, the EES shall reject the service provision request and respond an appropriate failure cause, see table 8.5.3.2-1, which shows Edge Application server discovery response includes failure response indicates that the EAS discovery request failed and cause indicates the cause of the EAS discovery request failure), 3GPP’558 does not explicitly show the use of “at least one memory; and at least one processor coupled to the at least one memory and configured to; in a case in which the EAS discovery request is rejected by the EES due to an overload state of an EAS” as required by present claimed invention. However, including “at least one memory; and at least one processor coupled to the at least one memory and configured to; in a case in which the EAS discovery request is rejected by the EES due to an overload state of an EAS” would have been obvious to one having ordinary skill in the art as evidenced by Kim’473.
In particular, in the same field of endeavor, Kim’473 teaches the use of at least one memory; and at least one processor coupled to the at least one memory and configured to(see para.0078, processor, see fig.9, storage 101 as memory) in a case in the EAS discovery request is rejected due to an overload state of an EAS (see para.0 179, which discusses with a rejection cause meaning congestion, overload, insufficient resources, and the like and may be provided to the UE), wherein the EAS discovery response further includes information indicating a time period that the radio terminal has to wait before performing a new EAS discovery request(see para.0179, which discusses the network may transmit a reject message to the request from the UE. The rejection message may include a back-off/wait timer for mobility management congestion control together with a rejection cause meaning congestion, overload, insufficient resources, and the like and may be provided to the UE. In this case, the back-off timer may operate according to information such as the corresponding UE type, service type, communication type, and specific group. That is, the back-off timer is bound with information such as the corresponding UE type, service type, communication type, and specific group and operates, see also para.0182, see para.0020, which discusses network transmits a back-off timer value via an NAS Reject message to a UE in idle mode or connected mode, and the UE does not request an EMM/GMM/(E)SM signal from the network until the back-off timer expires, see para.0027, 0031, see para.0020, which discusses back-off timer value via an NAS Reject message to a UE in idle mode or connected mode, and the UE does not request an EMM/GMM/(E)SM signal from the network until the back-off timer expires).
In view of the above, having the system of 3GPP’558 and then given the well-established teaching of Kim’473, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of 3GPP’558 to include “at least one memory; and at least one processor coupled to the at least one memory and configured to; in a case in which the EAS discovery request is rejected by the EES due to an overload state of an EAS” as taught by Kim’473, since Kim’473 stated in para.0070+ that such a modification would provide a congestion control method for next generation mobile communication.
As discussed above, although the combined system of 3GPP’558 and Kim’473 discloses receive a response including information that the EAS discovery request is failed(3GPP’558, see fig.8.5.2.2-1, which shows Edge Application server discovery response & see page 60, 2., if the EES is unable to determine the EAS information using the inputs in the EAS discovery request…, the EES shall reject the service provision request and respond an appropriate failure cause, see table 8.5.3.2-1, which shows Edge Application server discovery response includes failure response indicates that the EAS discovery request failed and cause indicates the cause of the EAS discovery request failure), the combined system of 3GPP’558 and Kim’473 does not explicitly show the use of “response including a hypertext transfer Protocol (HTTP) status code” as required by present claimed invention. However, including “response including a hypertext transfer Protocol (HTTP) status code” would have been obvious to one having ordinary skill in the art as evidenced by Svennebring’331.
In particular, in the same field of endeavor, Svennebring’331 teaches the use of response including a hypertext transfer Protocol (HTTP) status code(see para.0402, which discusses the HTTP response message may include other HTTP status codes, such as a bad request status code (400) (e.g., when incorrect parameters are passed in the request), a not found status code (404) (e.g., when a Universal Resource Indicator (URI) provided in the request cannot be mapped to a valid resource URI), a forbidden status code (403) (e.g., when the operation is not allowed given the current status of the resource), and/or other like HTTP status codes. In the aforementioned examples, the response body may include a ProblemDetails data type indicating/including information about the particular error, thus a forbidden status code (403) (e.g., when the operation is not allowed/rejected given the current status of the resource), see fig.28, which shows edge enabler client and Edge Enabler Server).
In view of the above, having the combined system of 3GPP’558 and Kim’473 and then given the well-established teaching of Svennebring’331 it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the combined system of 3GPP’558 and Kim’473 to include “response including a hypertext transfer Protocol (HTTP) status code” as taught by Svennebring’331, since Svennebring’331 stated in para.0052+ that such a modification would optimize the performance of media streaming applications and services by proactively adapting to variations in link quality before they occur. In this manner, the media streaming experience can be proactively tuned to accommodate predicted variations in link performance while also prioritizing the performance metrics that are most important to the particular streaming service.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Following prior arts are related to the present claimed invention:
JANSSON et al (US 20160337384) teaches, see para.0047, teaches an HTTP status code is the status code returned to the client when requests are rejected by WSC filters (e.g., with a default value of “403” indicating “Forbidden”).
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINNCELAS LOUIS whose telephone number is (571)270-5138. The examiner can normally be reached 8:30-5:00 PM.
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, Michael Thier can be reached at 571-272-2832. 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.
/VINNCELAS LOUIS/Primary Examiner, Art Unit 2474
Prosecution Insights