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 amendment submitted on 08/12/2026 has been received and considered by the Examiner. Claims 13, 18, 23, 28, and 33-36 were amended, and claims 14-17, 19-22, 24-27, and 29-32 were previously canceled. Claims 13, 18, 23, 28, and 33-36 remain pending.
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.
Response to Arguments
Applicant’s arguments with respect to claim(s) 13, 18, 23, 28, and 33-36 have been considered but are moot because the new ground of rejection does not rely on the combination of references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 13, 18, 23, 28, and 33-36 is/are rejected under 35 U.S.C. 103 as being unpatentable over Skubic et al. (US 2022/0247623 A1, hereinafter “Skubic”) in view of Desai et al. (US 2018/0255123 A1, hereinafter “Desai”) and further in view of Li et al. (US 2020/0287975 A1, hereinafter “Li”).
As to Claim 13:
Skubic describes a method for an edge enabler client to request support for an application from an edge configuration server.
Specifically, Skubic teaches:
A user equipment (UE) configured with an edge enabler client (EEC) in a communication system
Fig. 1 in Skubic shows an edge cloud including a “client” hosted on a “particular UE” which corresponds to “a user equipment configured with an edge enabler client (EEC)” (Skubic, 0008).
Transmitting, to an edge configuration server (ECS), a service provisioning request including information related to application clients applicable on the EEC in the UE
Skubic describes a “registry of configured ECSs” stored at a network node that maintains an “application identifier” for every device “that requested client provisioning” (Skubic, 0093, 0101).
Here, the “requested client provisioning” maps to “transmitting ... a service provisioning request”,
one of the “ECS entr[ies]” maps to “an edge configuration server (ECS)”, and
“corresponding application identifier that requested client provisioning” maps to “information related to application clients applicable on the EEC in the UE”.
The ECS
Paragraphs 0093 and 0101 of Skubic describe “a registry of configured ECSs” and its contents (Skubic, 0093, 0101).
The EEC
Paragraphs 0093 and 0101 of Skubic describe “clients” (i.e. “EECs”) registered with each ECS.
Skubic does not explicitly disclose:
Receiving ... a response message including a failure cause
The failure cause indicating a cause of service provisioning failure
Retransmitting, to the [server], the service provisioning request based on the received failure cause
However, Desai does describe a method for a client device to send a request to a cloud server and subsequently adjust and resend the request if it fails.
Specifically, Desai teaches:
Receiving ... a response message including a failure cause
Desai describes a “cloud agent” that “sends a FAIL message to a corresponding last hop cloud agent” wherein “the FAIL message may contain the reason for the failure” (Desai, 0068).
Here, “a FAIL message” that “may contain the reason for the failure” maps to “receiving ... a response message including a failure cause”.
The failure cause indicating a cause of service provisioning failure
Desai describes a “cloud agent” that “receives a user request for cloud computing” and “sends a FAIL message to a corresponding last hop cloud agent” wherein “the FAIL message may contain the reason for the failure” such as “required resources” (Desai, 0066, 0068).
Here, “the reason for the failure” such as “required resources” maps to “[t]he failure cause indicating a cause of service provisioning failure”.
Retransmitting, to the [server], the service provisioning request based on the received failure cause
Desai teaches that “[i]f the response message is not indicative of a success”, i.e. the request failed, “the client device adjusts the request specification” (Desai, 0076). Fig. 5 in Desai further clarifies that this leads to repeating step 506, i.e. resending the “request message”.
Here, step 506 in Fig. 5 maps to “retransmitting, to the [server], the service provisioning request”, and
“if the response message is not indicative of a success” maps to “based on the received failure cause”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Desai’s method for retransmitting an adjusted service request into Skubic’s method for an edge device to send a provisioning request to an edge server. Adjusting and resending a request after failure makes the provisioning process more robust and reliable.
The combination of Skubic and Desai does not explicitly disclose:
The ... request includes an indicator indicating whether service continuity is required for application clients applicable on the [client]
However, Li does describe a method for a network control element to indicate whether service continuity is required.
Specifically, Li teaches:
The ... request includes an indicator indicating whether service continuity is required for application clients applicable on the [client]
Li describes a “policy control function network element” that “receiv[es] ... request information from an application function network element” including “a continuity requirement of an APP [application]” (Li, 0006). Li later clarifies that “based on the requirement, in the request information, that the APP supports upper-layer service continuity, the policy control network element determines ... the third SSC [session and service continuity] mode” (Li, 0011).
Here, “request information from an application function network element” maps to “the ... request”, and
“a continuity requirement of an APP” maps to “an indicator indicating whether service continuity is required for application clients applicable on the [client]”.
Thus, it would have been obvious to one of ordinary skill in the art to incorporate Li’s method if indicating whether service continuity is required into Skubic’s method for provisioning an edge server. As Li notes, this allows “a session path” to “be shortened”, and “transmission efficiency is improved” if service continuity is not necessary (Li, 0010).
As to Claim 18:
Skubic teaches:
A method performed by an edge configuration server (ECS) in a communication system
Skubic describes a “registry of configured ECSs” stored at a network node that maintains an “application identifier” for every device “that requested client provisioning” (Skubic, 0093, 0101).
Here, one of the “ECSs” storing an “application identifier” maps to “a method performed by an edge configuration server (ECS) in a communication system”.
Receiving, from a user equipment, a service provisioning request including information related to application clients applicable on an edge enabler client (EEC) in the UE
Skubic describes a “registry of configured ECSs” stored at a network node that maintains an “application identifier” for every device “that requested client provisioning” (Skubic, 0093, 0101).
Here, the “requested client provisioning” maps to “receiving ... a service provisioning request”,
the device hosting the “client” maps to “a user equipment”, and
“corresponding application identifier that requested client provisioning” maps to “information related to application clients applicable on the EEC in the UE”.
The ECS
Paragraphs 0093 and 0101 of Skubic describe “a registry of configured ECSs” and its contents (Skubic, 0093, 0101).
The EEC
Paragraphs 0093 and 0101 of Skubic describe “clients” (i.e. “EECs”) registered with each ECS.
Skubic does not explicitly disclose:
Determining a failure cause indicating a cause of service provisioning failure
Transmitting ... a response message including the failure cause
Receiving, from the UE, the service provisioning request retransmitted by the UE
However, Desai does describe a method for a client device to send a request to a cloud server and subsequently adjust and resend the request if it fails.
Specifically, Desai teaches:
Determining a failure cause indicating a cause of service provisioning failure
Desai describes a “cloud agent” that “receives a user request for cloud computing” and “sends a FAIL message to a corresponding last hop cloud agent” wherein “the FAIL message may contain the reason for the failure” such as “required resources” (Desai, 0066, 0068).
Here, the “reason for the failure” maps to “determining a failure cause indicating a cause of service provisioning failure”.
Transmitting ... a response message including the failure cause
Desai describes a “cloud agent” that “sends a FAIL message to a corresponding last hop cloud agent” wherein “the FAIL message may contain the reason for the failure” (Desai, 0068).
Here, “a FAIL message” that “may contain the reason for the failure” maps to “transmitting ... a response message including a failure cause”. and
“the reason for the failure” such as “required resources” maps to “[t]he failure cause indicating a cause of service provisioning failure”.
Receiving, from the UE, the service provisioning request retransmitted by the UE
Desai teaches that “[i]f the response message is not indicative of a success”, i.e. the request failed, “the client device adjusts the request specification” (Desai, 0076). Fig. 5 in Desai further clarifies that this leads to repeating step 506, i.e. resending the “request message”.
Here, step 506 in Fig. 5 maps to “receiving, from the UE, the service provisioning request retransmitted by the UE”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Desai’s method for retransmitting an adjusted service request into Skubic’s method for an edge device to send a provisioning request to an edge server. Adjusting and resending a request after failure makes the provisioning process more robust and reliable.
The combination of Skubic and Desai does not explicitly disclose:
The ... request includes an indicator indicating whether service continuity is required for application clients applicable on the [client]
However, Li does describe a method for a network control element to indicate whether service continuity is required.
Specifically, Li teaches:
The ... request includes an indicator indicating whether service continuity is required for application clients applicable on the [client]
Li describes a “policy control function network element” that “receiv[es] ... request information from an application function network element” including “a continuity requirement of an APP [application]” (Li, 0006). Li later clarifies that “based on the requirement, in the request information, that the APP supports upper-layer service continuity, the policy control network element determines ... the third SSC [session and service continuity] mode” (Li, 0011).
Here, “request information from an application function network element” maps to “the ... request”, and
“a continuity requirement of an APP” maps to “an indicator indicating whether service continuity is required for application clients applicable on the [client]”.
Thus, it would have been obvious to one of ordinary skill in the art to incorporate Li’s method if indicating whether service continuity is required into Skubic’s method for provisioning an edge server. As Li notes, this allows “a session path” to “be shortened”, and “transmission efficiency is improved” if service continuity is not necessary (Li, 0010).
As to Claim 23:
Skubic teaches:
A user equipment (UE) configured with an edge enabler client (EEC) in a communication system, the UE comprising: a transceiver; and a processor configured
Fig. 1 in Skubic shows an edge cloud including a “client” hosted on a “particular UE”. (Skubic, 0008). Also, paragraph 0145 of Skubic describes “program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein” (Skubic, 0145).
Here, the “client” hosted on a “particular UE” corresponds to “a user equipment configured with an edge enabler client (EEC)”, and
“program instructions for executing one or more telecommunications and/or data communications protocols” maps to “a transceiver; and a processor configured”.
Transmit, to an edge configuration server (ECS), a service provisioning request including information related to application clients applicable on the EEC in the UE
Skubic describes a “registry of configured ECSs” stored at a network node that maintains an “application identifier” for every device “that requested client provisioning” (Skubic, 0093, 0101).
Here, the “requested client provisioning” maps to “transmit ... a service provisioning request”,
one of the “ECS entr[ies]” maps to “an edge configuration server (ECS)”, and
“corresponding application identifier that requested client provisioning” maps to “information related to application clients applicable on the EEC in the UE”.
The ECS
Paragraphs 0093 and 0101 of Skubic describe “a registry of configured ECSs” and its contents (Skubic, 0093, 0101).
The EEC
Paragraphs 0093 and 0101 of Skubic describe “clients” (i.e. “EECs”) registered with each ECS.
Skubic does not explicitly disclose:
Receive ... a response message including a failure cause
The failure cause indicating a cause of service provisioning failure
Retransmit, to the [server], the service provisioning request based on the received failure cause
However, Desai does describe a method for a client device to send a request to a cloud server and subsequently adjust and resend the request if it fails.
Specifically, Desai teaches:
Receive ... a response message including a failure cause
Desai describes a “cloud agent” that “sends a FAIL message to a corresponding last hop cloud agent” wherein “the FAIL message may contain the reason for the failure” (Desai, 0068).
Here, “a FAIL message” that “may contain the reason for the failure” maps to “receive ... a response message including a failure cause”.
The failure cause indicating a cause of service provisioning failure
Desai describes a “cloud agent” that “receives a user request for cloud computing” and “sends a FAIL message to a corresponding last hop cloud agent” wherein “the FAIL message may contain the reason for the failure” such as “required resources” (Desai, 0066, 0068).
Here, “the reason for the failure” such as “required resources” maps to “[t]he failure cause indicating a cause of service provisioning failure”.
Retransmit, to the [server], the service provisioning request based on the received failure cause
Desai teaches that “[i]f the response message is not indicative of a success”, i.e. the request failed, “the client device adjusts the request specification” (Desai, 0076). Fig. 5 in Desai further clarifies that this leads to repeating step 506, i.e. resending the “request message”.
Here, step 506 in Fig. 5 maps to “retransmit, to the [server], the service provisioning request”, and
“if the response message is not indicative of a success” maps to “based on the received failure cause”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Desai’s method for retransmitting an adjusted service request into Skubic’s method for an edge device to send a provisioning request to an edge server. Adjusting and resending a request after failure makes the provisioning process more robust and reliable.
The combination of Skubic and Desai does not explicitly disclose:
The ... request includes an indicator indicating whether service continuity is required for application clients applicable on the [client]
However, Li does describe a method for a network control element to indicate whether service continuity is required.
Specifically, Li teaches:
The ... request includes an indicator indicating whether service continuity is required for application clients applicable on the [client]
Li describes a “policy control function network element” that “receiv[es] ... request information from an application function network element” including “a continuity requirement of an APP [application]” (Li, 0006). Li later clarifies that “based on the requirement, in the request information, that the APP supports upper-layer service continuity, the policy control network element determines ... the third SSC [session and service continuity] mode” (Li, 0011).
Here, “request information from an application function network element” maps to “the ... request”, and
“a continuity requirement of an APP” maps to “an indicator indicating whether service continuity is required for application clients applicable on the [client]”.
Thus, it would have been obvious to one of ordinary skill in the art to incorporate Li’s method if indicating whether service continuity is required into Skubic’s method for provisioning an edge server. As Li notes, this allows “a session path” to “be shortened”, and “transmission efficiency is improved” if service continuity is not necessary (Li, 0010).
As to Claim 28:
Skubic teaches:
An edge configuration server (ECS) in a communication system, the ECS comprising: a transceiver; and a processor configured
Skubic describes a “registry of configured ECSs” stored at a network node that maintains an “application identifier” for every device “that requested client provisioning” (Skubic, 0093, 0101). Also, paragraph 0145 of Skubic describes “program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein” (Skubic, 0145).
Here, one of the “ECSs” maps to “an edge configuration server (ECS) in a communication system”, and
“program instructions for executing one or more telecommunications and/or data communications protocols” maps to “a transceiver; and a processor configured”.
Receive, from a user equipment, a service provisioning request including information related to application clients applicable on an edge enabler client (EEC) in the UE
Skubic describes a “registry of configured ECSs” stored at a network node that maintains an “application identifier” for every device “that requested client provisioning” (Skubic, 0093, 0101).
Here, the “requested client provisioning” maps to “receive ... a service provisioning request”,
the device hosting the “client” maps to “a user equipment”, and
“corresponding application identifier that requested client provisioning” maps to “information related to application clients applicable on the EEC in the UE”.
The ECS
Paragraphs 0093 and 0101 of Skubic describe “a registry of configured ECSs” and its contents (Skubic, 0093, 0101).
The EEC
Paragraphs 0093 and 0101 of Skubic describe “clients” (i.e. “EECs”) registered with each ECS.
Skubic does not explicitly disclose:
Determine a failure cause indicating a cause of service provisioning failure
Transmit ... a response message including the failure cause
Receive, from the UE, the service provisioning request retransmitted by the UE
However, Desai does describe a method for a client device to send a request to a cloud server and subsequently adjust and resend the request if it fails.
Specifically, Desai teaches:
Determine a failure cause indicating a cause of service provisioning failure
Desai describes a “cloud agent” that “receives a user request for cloud computing” and “sends a FAIL message to a corresponding last hop cloud agent” wherein “the FAIL message may contain the reason for the failure” such as “required resources” (Desai, 0066, 0068).
Here, the “reason for the failure” maps to “determine a failure cause indicating a cause of service provisioning failure”.
Transmit ... a response message including the failure cause
Desai describes a “cloud agent” that “sends a FAIL message to a corresponding last hop cloud agent” wherein “the FAIL message may contain the reason for the failure” (Desai, 0068).
Here, “a FAIL message” that “may contain the reason for the failure” maps to “transmit ... a response message including a failure cause”, and
“the reason for the failure” such as “required resources” maps to “[t]he failure cause indicating a cause of service provisioning failure”.
Receive, from the UE, the service provisioning request retransmitted by the UE
Desai teaches that “[i]f the response message is not indicative of a success”, i.e. the request failed, “the client device adjusts the request specification” (Desai, 0076). Fig. 5 in Desai further clarifies that this leads to repeating step 506, i.e. resending the “request message”.
Here, step 506 in Fig. 5 maps to “receive, from the UE, the service provisioning request retransmitted by the UE”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Desai’s method for retransmitting an adjusted service request into Skubic’s method for an edge device to send a provisioning request to an edge server. Adjusting and resending a request after failure makes the provisioning process more robust and reliable.
The combination of Skubic and Desai does not explicitly disclose:
The ... request includes an indicator indicating whether service continuity is required for application clients applicable on the [client]
However, Li does describe a method for a network control element to indicate whether service continuity is required.
Specifically, Li teaches:
The ... request includes an indicator indicating whether service continuity is required for application clients applicable on the [client]
Li describes a “policy control function network element” that “receiv[es] ... request information from an application function network element” including “a continuity requirement of an APP [application]” (Li, 0006). Li later clarifies that “based on the requirement, in the request information, that the APP supports upper-layer service continuity, the policy control network element determines ... the third SSC [session and service continuity] mode” (Li, 0011).
Here, “request information from an application function network element” maps to “the ... request”, and
“a continuity requirement of an APP” maps to “an indicator indicating whether service continuity is required for application clients applicable on the [client]”.
Thus, it would have been obvious to one of ordinary skill in the art to incorporate Li’s method if indicating whether service continuity is required into Skubic’s method for provisioning an edge server. As Li notes, this allows “a session path” to “be shortened”, and “transmission efficiency is improved” if service continuity is not necessary (Li, 0010).
As to Claims 33, 34, 35, and 36:
Skubic does not explicitly disclose:
The retransmitted service provisioning request further includes information indicating a required key performance indicator (KPI)
However, Desai does teach:
The retransmitted service provisioning request further includes information indicating a required key performance indicator (KPI)
Desai describes a “cloud agent” that “receives a user request for cloud computing” and “sends a FAIL message to a corresponding last hop cloud agent” wherein “the FAIL message may contain the reason for the failure” such as “required resources” (Desai, 0066, 0068). Desai later clarifies that “[i]f the response message is not indicative of a success”, i.e. the request failed, “the client device adjusts the request specification” (Desai, 0076). Fig. 5 in Desai further clarifies that this leads to repeating step 506, i.e. resending the “request message”.
Here, step 506 in Fig. 5 maps to “the retransmitted service request”,
the “adjust[ed] ... request specification” maps to “further includes information”, and
“required resources” map to “a required key performance indicator (KPI)”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Desai’s method for retransmitting an adjusted service request into Skubic’s method for an edge device to send a provisioning request to an edge server. Adjusting and resending a request after failure makes the provisioning process more robust and reliable.
Claim 34 introduces the same new subject matter as Claim 13 from the perspective of the edge server.
Claim 35 describes the same new subject matter as Claim 13 in the form of an apparatus claim.
Claim 36 describes the same new subject matter as Claim 18 in the form of an apparatus claim.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Benjamin Peter Welte whose telephone number is (703)756-5965. The examiner can normally be reached Monday - Friday, EST.
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, Chirag G Shah can be reached at (571) 272-3144. 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.
BENJAMIN PETER WELTE
Examiner
Art Unit 2477
/CHIRAG G SHAH/Supervisory Patent Examiner, Art Unit 2477
