DETAILED ACTION
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 02/20/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.
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 because 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).
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; because the EAS discovery request is rejected by the EES based on an EAS load state, 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” 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; because the EAS discovery request is rejected by the EES based on an EAS load state, 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” 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) because the EAS discovery request is rejected based on an EAS load state (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; because the EAS discovery request is rejected by the EES based on an EAS load state, 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” 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 because 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).
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; because the EAS discovery request is rejected by the EES based on an EAS load state, wherein the response further includes information indicating a time that the radio terminal has to wait before performing a new EAS discovery request” 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; because the EAS discovery request is rejected by the EES based on an EAS load state, wherein the response further includes information indicating a time that the radio terminal has to wait before performing a new EAS discovery request” 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/511 as memory) because the EAS discovery request is rejected by the EES based on an EAS load state (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 response further includes information indicating a time 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’47, 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; because the EAS discovery request is rejected by the EES based on an EAS load state, wherein the response further includes information indicating a time that the radio terminal has to wait before performing a new EAS discovery request” as taught by Kim’47, since Kim’47 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
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. 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