DETAILED ACTION
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 .
This action is responsive to Applicant’s Amendment filed on 2/4/2026.
Claims 1-20 are presented for examination. Claims 2-3, 10 and 12-13 have been amended.
Applicant’s responses and amendments to the claims have overcome claim objections and 112(b) rejections set forth in the non-Final Office Action mailed 12/17/2025.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 6, 12 and 17 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by Rehman (US 20210055959 A1).
Regarding to claim 1, Rehman discloses: A computing system (see Fig. 12 and [0107]) comprising:
a communications module; a processor coupled with the communications module; and a memory coupled to the processor and storing processor-executable instructions which, when executed by the processor, configure the computing system to (see Fig. 12 and [0107]-[0108]):
obtain resource availability data indicating current resource availability for a resource associated with the computing system (see [0050] and [0057], “receive and process the first, second, and third sets of inputs 410, 420, and 430 in order to maintain a real-time status of resource availability at each PoP” and “identify changing resource availability across distributed platform 100”);
detect an excess availability of a resource of a particular type based on the resource availability data (see [0029], [0074] and claim 1; “permitting lower priority tasks to benefit from the improved performance provided by those tiers or PoPs when excess resources are available”, “resources at closest first-tier PoP 110 exceed a threshold” and “the availability of the first set of resources being greater than the threshold”. Also see [0070]; “compute different scores for different tasks or requests. For instance, controller 105 may compute a first PoP score for a compute task based on the available compute resources of first-tier PoP 110, may compute a second PoP score for a streaming task based on the available bandwidth of first-tier PoP 110, and may compute a third PoP score for a content delivery and caching task based on the available memory of first-tier PoP 110”. The execution of particular type of task would require using particular type of resource, and thus the detection of excess availability of resource discussed at [0029], [0074] and claim 1 above would be reasonable to be performed as detection of excess availability of resource of a particular type; in this way, the system is able to achieve feature of using appropriate type of excess available resource to perform appropriate type of lower priority task);
in response to detecting the excess availability of the resource of the particular type, identify a flexibly-scheduled computing process requiring use of the resource of the particular type; and initiate the flexibly-scheduled computing process to consume at least a portion of the excess availability of the resource (see [0029] and claim 1; “permitting lower priority tasks to benefit from the improved performance provided by those tiers or PoPs when excess resources are available” and “performing the second task at the first network location using the first set of resources in response to classifying the second task as the nonprioritized task and the availability of the first set of resources being greater than the threshold”. Also see [0070]. The execution of particular type of task would require using particular type of resource, and thus executing lower priority task on resources that whose availability are excess would be reasonable to include a step of identifying the lower priority task that requires using the particular type of excess available resource).
Regarding to Claim 6, the rejection of Claim 1 is incorporated and further Rehman discloses: wherein the flexibly-scheduled computing process includes a transfer of at least a portion of the resource (see [0029] and claim 1; “permitting lower priority tasks to benefit from the improved performance provided by those tiers or PoPs when excess resources are available” and “performing the second task at the first network location using the first set of resources in response to classifying the second task as the nonprioritized task and the availability of the first set of resources being greater than the threshold”. The task or operation to consume the portion of the resources for execution is known to include transferring the portion of the resource into used state).
Note: for limitation “a transfer of at least a portion of resource” from claim 6, if Applicant’s intention is about transferring resources from one location/system to another location/system, then this kind of “resources” is the object for the transfer process to be performed on instead of resource to be consumed by the transfer process. For example, a transfer process of transferring data from a source location to a target location, the data here is not considered as resource to be consumed by the transfer process. The resource to be consumed by a transfer process in generally is bandwidth resource while the data transferred is considered as object for the transfer process to be performed on. Another example is transferring CPU resource from one location to another location, the transfer process does not consume CPU resource in order to perform the transfer operation instead it consumes bandwidth resource; the CPU resource here is the object for the transfer process performed on.
Regarding to Claim 12, Claim 12 is a method claim corresponds to system Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above.
Regarding to Claim 17, Claim 17 is a method claim corresponds to system Claim 6 and is rejected for the same reason set forth in the rejection of Claim 6 above.
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 of this title, 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.
Claims 2 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Rehman (US 20210055959 A1) in view of Moore et al. (US 20070130387 A1, hereafter Moore).
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further Rehman discloses: wherein identifying the flexibly-scheduled computing process includes identifying computing processes that are designated as having a low priority while ignoring computing processes that are identified as having a high priority (see [0029] and claim 1; “high priority tasks … by permitting lower priority tasks to benefit from the improved performance provided by those tiers or PoPs when excess resources are available” and “in response to classifying the second task as the nonprioritized task”. It is understood that selecting or identifying a nonprioritized or low priority task would be performed via ignoring the tasks/operations identified as high priority).
Rehman does not disclose: the flexibility-scheduled computing process is a type of computing processes that are designated as having a variable time parameter instead of computing processes that are identified as having a rigid time parameter.
However, Moore discloses: a low priority computing process is a type of computing processes that are designated as having a variable time parameter while a high priority computing process is a type of computing processes that are identified as having a rigid time parameter (see [0030]; “The deadline (122) may correspond to an actual deadline … the deadline (122) may correspond to priority such as: high priority (i.e., complete as soon as possible … low priority (i.e., complete eventually”. The lower priority task or process to be completed eventually has deadline time parameter that is variable while the high priority task or process to be completed as soon as possible has a deadline time parameter that is rigid).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the classification of high and low priority tasks from Rehman by including classifying high and low priority tasks based on different deadline requirement of the tasks from Moore, and thus the combination of Rehman and Moore would disclose the missing limitations from Rehman, since it would provide an mechanism of prioritizing tasks or operations based on urgency levels of deadlines associated with the tasks or operations (see [0030] from Moore).
Regarding to Claim 13, Claim 13 is a method claim corresponds to system Claim 2 and is rejected for the same reason set forth in the rejection of Claim 2 above.
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Rehman (US 20210055959 A1) in view of Moore et al. (US 20070130387 A1, hereafter Moore) and further in view of Yeung et al. (US 20190258528 A1, hereafter Yeung).
Regarding to Claim 3, the rejection of Claim 1 is incorporated and further Rehman discloses: wherein the flexibility-scheduled computing process is associated with a [time] parameter identifying [a last time at which] the flexibility-scheduled computing process is to be performed and wherein a computing process that is identified as having a [rigid time] parameter (see [0029] and claim 1; “high priority tasks … by permitting lower priority tasks to benefit from the improved performance provided by those tiers or PoPs when excess resources are available” and “in response to classifying the second task as the nonprioritized task”. It is understood that lower priority tasks or nonprioritized task is associated with a parameter identifying the priority of the lower priority task or nonprioritized task is to be performed, and the higher priority tasks that are identified as having a parameter indicating or identifying higher priority).
Rehman does not disclose: the parameter associated with the flexibility-scheduled computing process is a time parameter identifying a last time at which the flexibility-scheduled computing process is to be performed and a computing process that is identified as having a rigid time parameter is a computing process that is to be completed at a defined time.
However, Moore discloses: wherein the flexibility-scheduled computing process is associated with a time parameter identifying [a last time at which] the flexibility-scheduled computing process is to be performed and wherein a computing process that is identified as having a rigid time parameter is a computing process that is to be completed at a defined time (see [0030]; “The deadline (122) may correspond to an actual deadline … the deadline (122) may correspond to priority such as: high priority (i.e., complete as soon as possible … low priority (i.e., complete eventually”. The lower priority task or process to be completed eventually has deadline time parameter while the high priority task or process to be completed as soon as possible has a deadline time parameter that is rigid that to be completed at a defined time, i.e., as soon as possible).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the classification of high and low priority tasks from Rehman by including classifying high and low priority tasks based on different deadline requirement of the tasks from Moore, since it would provide a mechanism of prioritizing tasks or operations based on urgency levels of deadlines associated with the tasks or operations (see [0030] from Moore).
In addition, Yeung discloses: wherein the computing process that can be completed eventually is associated with a time parameter identifying a last time at which the computing process is to be performed and wherein a computing process that is identified as having a rigid time parameter is a computing process that is to be completed at a defined time (see [0032]; “a “start deadline” may be used as an alternative or an addition to a “completion deadline.” For example, an application may specify a “start deadline””. A task or operation provided with start deadline would be completed eventually and the deadline time parameter identifying last time that the task or operation to be performed; a task or operation is provided with defined completion deadline would be completed at a defined time and such defined completion deadline is a rigid time parameter).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the deadline for low priority tasks or operations that indicating such tasks or operations are completed eventually from the combination of Rehman and Moore by including assigning a start deadline without a completion deadline for a job to be performed from Yeung, and thus the combination of Rehman, Moore and Yeung would disclose the missing limitations from Rehman, since it would provide a mechanism of utilizing various types of deadlines to determine whether the resource performance is great enough to satisfy certain performance objectives for the workload (see [0032] from Yeung; “Various such deadlines can be used to determine whether the processor performance is great enough to satisfy certain performance objectives for the workload”).
Regarding to Claim 14, Claim 14 is a method claim corresponds to system Claim 3 and is rejected for the same reason set forth in the rejection of Claim 3 above.
Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Rehman (US 20210055959 A1) in view of Moore et al. (US 20070130387 A1, hereafter Moore) and in view of Yeung et al. (US 20190258528 A1, hereafter Yeung) and further in view of Zhang et al. (US 6879561 B1, hereafter Zhang).
Regarding to Claim 4, the rejection of Claim 3 is incorporated, the combination of Rehman, Moore and Yeung does not disclose: wherein the defined time is a current time.
However, Zhang disclose: wherein a computing process that is identified as having a rigid time parameter is a computing process that is to be completed at a defined time, wherein the defined time is a current time (see lines 1-8 of col. 5; “The packets that must be sent in the current frame include, for example, those where the finish time is equal to the current system time, and those where the deadline is zero”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the deadline for high priority tasks or operations that indicating such tasks or operations are completed as soon as possible from the combination of Rehman, Moore and Yeung by including assigning the completion time or completion deadline for a job to be performed as current system time from Zhang, and thus the combination of Rehman, Moore, Yeung and Zhang would disclose the missing limitations from the combination of Rehman, Moore and Yeung, since it would provide a mechanism to ensuring a related process or operation should be completed as soon as possible (see lines 1-8 of col. 5 from Zhang; “The packets that must be sent in the current frame include, for example, those where the finish time is equal to the current system time”).
Regarding to Claim 15, Claim 15 is a method claim corresponds to system Claim 4 and is rejected for the same reason set forth in the rejection of Claim 4 above.
Claims 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Rehman (US 20210055959 A1) in view of Martin et al. (US 20020156786 A1, hereafter Martin).
Regarding to Claim 5, the rejection of Claim 1 is incorporated, Rehman does not disclose: wherein the flexibly-scheduled computing process includes a database management operation.
However, Martin discloses: wherein the flexibly-scheduled computing process includes a database management operation (see [0048]; “The database thread 706 is issued … used to retrieve the transactions issued from the database engine 801 … This thread of the application 702 is given a fairly low priority as it is not time-critical”. Such database thread is a computing process to perform database management operation. Note: without further amendment and clarification, “management operation” is a very broad term that can include many different types of operations related to management at the computing fields, the operation of the database thread described at [0048] is reasonable to be considered as one type of management operations).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the low priority task or operation performed from Rehman by including database management operation that is identified as low priority as it is not time-critical from Martin, and thus the combination of Rehman and Martin would disclose the missing limitations from Rehman, since it is understood to assigning low priority to a process that is not time-critical (see [0048] from Martin; “This thread of the application 702 is given a fairly low priority as it is not time-critical”).
Regarding to Claim 16, Claim 16 is a method claim corresponds to system Claim 5 and is rejected for the same reason set forth in the rejection of Claim 5 above.
Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Rehman (US 20210055959 A1) in view of Madisetti et al. (US 20110320747 A1, hereafter Madisetti) and Gupta (US 20130203399 A1).
Regarding to Claim 7, the rejection of Claim 1 is incorporated and further Rehman discloses: wherein the instructions further configure the computing system: identify [recurring] computing processes associated with a particular logical storage area, the [recurring] computing processes utilizing a particular non-native resource, in response to identifying the [recurring] computing processes utilizing the particular non-native resource, cause future computing processes involving the non-native resource and associated with the particular logical storage area to be designed as flexibly-scheduled by default (see [0002], [0023], [0051]; “low priority tasks (e.g., infrequently requested content”, “UE 140 may issue requests for content, services, code execution (e.g., remote computing), and/or other tasks that are hosted, performed, and/or provided by distributed platform 100 from one or more of first-tier PoP 110, second-tier PoP 120, and third-tier PoP 130”, “controller 105 may prioritize frequently requested tasks (e.g., assign a higher priority) over less frequently requested tasks (e.g., assign a lower priority)”. The request or job related to or involves infrequently requested content that is remoted from UE that issues the request or job, i.e., claimed the non-native resource and associated with the particular logical storage area, is low priority tasks by default).
Rehman does not disclose: the computing processes are recurring computing processes associated with a particular logical storage area,
send a data package to an endpoint associated with the particular logical storage area, the data package including data to enable the endpoint to cause future computing processes involving the non-native resource and associated with the particular logical storage area to be designed as flexibly-scheduled by default.
However, Madisetti discloses: computing processes associated with a particular logical storage area to be designed as low priority are recurring computing processes associated with a particular logical storage area (see [0041]; “a heuristic routine that scans the read ahead page list for pages that were speculatively prefetched, but not needed after a specified time interval. The heuristic routine may be executed periodically at a relatively low priority, and may be executed relatively infrequently”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the infrequently requested content that is performed at low priority from Rehman by including a low priority task is performed infrequently but periodically from Madisetti, since it would provide a mechanism to configure a proper periodic operation based on different memory space conditions (see [0041]-[0042] from Madisetti; “if the number of page records in inactive page list is low, the heuristic routine may be executed more frequently at a higher priority to move more page records from read ahead page list 44 to inactive page list 42. Conversely, if there are sufficient page records in inactive page list 42 to service page replacement requests, the heuristic routine may be executed less frequently and read ahead pages may remain in the read ahead page list longer”).
In addition, Gupta discloses:
Gupta discloses: send a data package to an endpoint, the data package including data to enable the endpoint to cause future requests to be designed as low priority by default (see [0037]; “if the network is congested above a certain determined level that allows establishing a connection with the device the network controller may respond with a rejection message (e.g., the network controller may send the RRC Connection Reject message described above) along with a wait time value … a priority value (e.g., default (low) priority or normal priority) associated with the device's request may be stored by the device for future use”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the communications between the network controller 105 and UEs sending task requests from the combination of Rehman and Madisetti by including setting a default low priority value to request from UE sent requests during congested network from Gupta, and thus the combination of Rehman, Madisetti and Gupta would disclose the missing limitations from Rehman, since it would provide a mechanism to avoid more resource competition to accept low priority tasks when network is congested (see [0024] from Gupta; “the UE and/or communications initiated by the UE (e.g., requests initiated by the applications hosted by the UE) may be assigned a default (e.g., low) priority level …the network may be congested and may not immediately accept a request or other communication from the UE that is associated with a default priority (or lower level of priority), but may accept and process a request or other communications from the UE that is associated with a higher (normal) level that may be assigned to the communication by the UE”).
Regarding to Claim 18, Claim 18 is a method claim corresponds to system Claim 7 and is rejected for the same reason set forth in the rejection of Claim 7 above.
Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Rehman (US 20210055959 A1) in view of Madisetti et al. (US 20110320747 A1, hereafter Madisetti) and Gupta (US 20130203399 A1) and further in view of Moore et al. (US 20070130387 A1, hereafter Moore).
Regarding to Claim 8, the rejection of Claim 7 is incorporated and further the combination of Rehman, Madisetti and Gupta discloses: wherein the data package indicates a modifier to be used for flexibly-scheduled computing processes that is not used for computing processes having high priority, and wherein initiating the flexibly-scheduled computing process includes using the modifier (see [0037]-[0038] from Gupta; “if the network is congested above a certain determined level that allows establishing a connection with the device the network controller may respond with a rejection message (e.g., the network controller may send the RRC Connection Reject message described above) along with a wait time value … a priority value (e.g., default (low) priority or normal priority) associated with the device's request may be stored by the device for future use” and “where a UE may receive a configuration providing an ability to override a default (e.g., low) priority associated with the UE and/or applications residing on the UE”. The response from controller to the UE includes a default low priority level to be stored at the UE device for the UE to set low priority requests or tasks but at the same time such UE is able to override the default low priority value for some other requests as high priority requests. Also see “performing the second task at the first network location using the first set of resources in response to classifying the second task as the nonprioritized task and the availability of the first set of resources being greater than the threshold as a result of the change in the availability” from claim 1 of Rehman for the claimed limitation of “wherein initiating the flexibly-scheduled computing process includes using the modifier”, i.e. the initiating the low priority task includes using such default low priority level).
The combination of Rehman, Madisetti and Gupta does not disclose: computing processes having high priority are computing processes having a rigid time parameter.
However, Moore discloses: computing processes having high priority are computing processes having a rigid time parameter (see [0030]; “The deadline (122) may correspond to an actual deadline … the deadline (122) may correspond to priority such as: high priority (i.e., complete as soon as possible … low priority (i.e., complete eventually”. The lower priority task or process to be completed eventually has deadline time parameter that is variable while the high priority task or process to be completed as soon as possible has a deadline time parameter that is rigid).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the classification of high and low priority tasks from the combination of Rehman, Madisetti and Gupta by including classifying high and low priority tasks based on different deadline requirement of the tasks from Moore, and thus the combination of Rehman, Madisetti, Gupta, Moore would disclose the missing limitations from the combination of Rehman, Madisetti and Gupta, since it would provide an mechanism of prioritizing tasks or operations based on urgency levels of deadlines associated with the tasks or operations (see [0030] from Moore).
Regarding to Claim 19, Claim 19 is a method claim corresponds to system Claim 8 and is rejected for the same reason set forth in the rejection of Claim 8 above.
Claims 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rehman (US 20210055959 A1) in view of Matsuoka et al. (US 20230063334 A1, hereafter Matsuoka) and Imai (JP 6741129 B2).
Regarding to Claim 9, the rejection of Claim 1 is incorporated, Rehman does not disclose: wherein identifying the flexibly-scheduled computing process includes:
identifying a set of flexibly-scheduled computing processes requiring the use of the resource of the particular type; and
selecting one of the flexibly-scheduled computing processes from the identified set as the identified flexibly-scheduled computing process based on a proximity of a time parameter identifying a last time at which the flexibly-scheduled computing process is to be performed to a current time.
However, Matsuoka discloses: identifying a set of same priority computing processes; and selecting one of the same priority computing processes from the identified set as the identified computing process to be performed based on a proximity of deadline at which the computing process (see [0210]; “multiple tasks may be given the same priority … may perform a secondary evaluation or otherwise apply additional criteria … a task with a closer deadline over a task with a more remote deadline even though the two tasks may be determined to have the same or similar priority” ).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the execution of low priority tasks or flexible-scheduled computing processes from Rehman by including re-prioritizing tasks when there are multiple tasks are given by same priority level from Matsuoka, since it would provide a dynamic priority assignment mechanism among tasks having same original priority level to further selecting a task having closer deadline (see [0210] from Matsuoka).
In addition, Imai discloses: selecting one of the computing processes based on a proximity of a time parameter identifying a last time at which the flexibly-scheduled computing process is to be performed to a current time (see [0052] and [0064]; “ calculates the difference time obtained by subtracting the current time information acquired in step S11 from the start deadline calculated in step S12, and acquires the start deadline point of each task according to the calculated time … Start deadline point=3: current time information to start deadline (start deadline-current time information) is within one hour, or current time information is past the start deadline … Start deadline point = 1: current time information-start deadline is longer than 2 hours and within 3 hours” and “The first task is start deadline point=2, importance point=1, and place point=1. The second task has start deadline points=0, importance point=1, and place point=2. In this case, it is considered that the first task has a high priority and should be executed earlier”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the determination of which task has closer deadline among multiple tasks having same priority from the combination of Rehman and Matsuoka by including calculating deadline is approaching or not based the difference between current time and start deadline of each task from Imai, and thus the combination of Rehman, Matsuoka and Imai would disclose the missing limitations from Rehman, since it would providing a specific calculation on which task’s start deadline is approaching in order to prioritizing such task (see [0052] and [0064] from Imai).
Regarding to Claim 20, Claim 20 is a method claim corresponds to system Claim 9 and is rejected for the same reason set forth in the rejection of Claim 9 above.
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Rehman (US 20210055959 A1) in view of Certain et al. (US 8533103 B1, hereafter Certain).
Regarding to Claim 10, the rejection of Claim 1 is incorporated, Rehman does not disclose: wherein detecting the excess availability of the resource of the particular type based on the resource availability data includes: detecting another computing process whose execution causes the excess availability of the resource of the particular type.
However, Certain discloses: wherein detecting the excess availability of the resource of the particular type based on the resource availability data includes: detecting another computing process whose execution causes the excess availability of the resource of the particular type (see lines 55-33 of col. 23-24; “After the selected amount of resources is no longer needed for the dedicated user (e.g., after termination and/or completion of the request), those resource instances may be returned to the dedicated resource group for use by other dedicated capacity users, and in some embodiments may further be tracked as being available for use as part of a private pool of excess resource capacity for that dedicated user, as discussed below … the one or more resource instances allocated for use by that user may similarly be released for use by others, such as by, for example, making the resource instances available to be allocated for use by one or more other (e.g., new) dedicated resource capacity users. Detecting a returning or releasing process that execution of the such process would cause the resource of particular type become excess variability based on availability tracked).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify process of detecting resource availability change from Rehman by including detecting resource releasing process to release or return allocated or occupied resources and then further tracking availability of such released resources from Certain, and thus the combination of Rehman and Certain would disclose the missing limitations from Rehman, since it is understood that releasing allocated resources to make such allocated resources available for usage when such allocated resources are no longer needed (see lines 55-33 of col. 23-24 from Certain).
Regarding to Claim 11, the rejection of Claim 10 is incorporated and further the combination of Rehman and Certain discloses: wherein the another computing process is a transfer providing an excess supply of a non-native resource (see claim 1 of Rehman; “wherein the first network location comprises a first set of resources, and wherein the first network location is a network location of the distributed platform that is closest to one or more user equipment (“UEs”) submitting the first request and the second request” and “performing the second task at the first network location using the first set of resources in response to classifying the second task as the nonprioritized task and the availability of the first set of resources being greater than the threshold as a result of the change in the availability”. The excess availability resources to be allocated to the flexible-scheduled or nonprioritized task is external resources from the location initiating such flexible-scheduled or nonprioritized task, and thus it is non-native resource to such flexible-scheduled or nonprioritized task. Also see lines 55-33 of cols. 23-24 from Certain; “those resource instances may be returned to the dedicated resource group for use by other dedicated capacity users, and in some embodiments may further be tracked as being available for use as part of a private pool of excess resource capacity for that dedicated user”. The returning or releasing process, i.e., claimed another computing process transferring such allocated resource into available state from allocated state to supply such extra resource).
Response to Arguments
Applicant’s arguments, filed 2/4/2026, with respect to rejections of claims 1-20 under 35 U.S.C. 102 or 35 U.S.C. 103 have been full considered but they are not persuasive.
Applicant’s arguments at pages 7-10 are summarized as the following:
For the independent claim 1, “the Examiner points to paragraphs [0029] and [0070] of Rehman as disclosing these features” related to identify flexibly-scheduled computing process in response to detecting excess availability of the resource and initiate the flexibly-scheduled computing process to consume at least a portion of the excess availability of resource from claim 1. However, the disclosures of [0029] are related to “excess resources are described as a condition under which an existing task may be handled differently” (see third paragraph of page 8 from the Remarks). To be more specific, “The Examiner asserts that executing a lower-priority task on excess resources would make it ‘reasonable to include’ a step of identifying a task that requires use of the particular type of excess available resource. This reasoning relies on interference rather than disclosure”. Actually, “Rehman’s disclosure is limited to evaluating suitability of resources for processing an existing task or request does not disclose a control step in which excess availability itself triggers identification or initiation of a computing process” (see 1st paragraph of page 9 from the Remarks). Furthermore, based on [0058]-[0059], [0060]-[0065] from Rehman, “Rehman discloses execution of computing tasks only in response to received requests, and does not describe initiating a computing process in the absence of such a request” (see 2nd paragraph of page 9 from the Remarks). For the claimed invention, it requires “[I]n response to detecting the excess availability of the resource of the particular type, a flexibly-scheduled computing process requiring use of the resource of the particular type is identified and initiated”. “In Rehman, detection of excess resources does not initiate execution but affects whether an already-requested task may be routed to a higher-tier PoP or processed with improved performance” (see 3rd paragraph of page 9 from the Remarks). “Rehman characterizes tasks in terms of priority rather than their ability to be scheduled and explains that priority determine routing behavior, such as routing high-priority tasks to first-tier PoPs and low priority tasks to lower tiers when resources are constrained (see Rehman, paragraph [0024]). Rehman does not disclose computing processes that are flexibly schedule in the sense that they are deferred until excess capacity exists, nor does it describe tasks that remain dormant until triggered by resource abundance. Low-priority tasks in Rehman are still executed in response to requests but priority affects where and how they are executed, not whether execution is initiated” (see last paragraph of page 9 and first paragraph of page 10 from the Remarks).
The examiner respectively disagrees.
All of Applicant’s arguments or attacks on reference Rehman against the claimed invention are based on features that are not claimed. Such as, Applicant kept arguing or stating that the task(s) or process(es) from Rehman is/are existing task(s) or process(es). However, it does not matter that whether the task/process from Rehman is existing or not since the claimed invention now does not have any requirement on whether the claimed flexibly-scheduled computing process is existed before the identify step/limitation or not, i.e., the claimed flexibly-scheduled computing process can be either one of pre-existed or not pre-existed before the claimed obtaining, detecting, identifying steps/limitations. Actually, Applicant’s specification does show an embodiment of the claimed flexibly-scheduled computing process is actually existed before the claimed identifying step/limitation. Such as, the steps 502-504 of Fig. 5 related to configure processes as flexibly-scheduled processes or non-flexibly-scheduled processes (note: such steps 502-504 would result or require at least the existence/receiving of claimed flexibly-scheduled processes) can be performed before step 510 related to claimed identifying step/limitation. The claimed identifying step/limitation can be selecting or identifying the claimed flexibly-scheduled process from a plurality of pre-existed or pre-requested or pre-received processes. The claimed initiating step/limitation is actually “initiate the flexibly-scheduled computing process to consume at least a portion of the excess availability of the resource” instead of initiating the flexibly-scheduled computing process itself (emphasis added by Examiner). Such claimed initiating step/limitation does not exclude the possibility of the claimed flexibly-scheduled computing process is existing before the claimed obtaining, detecting, identifying or initiating steps/limitations.
For Applicant’s argument regarding to “This reasoning relies on interference rather than disclosure” about reference Rehman to disclose identifying a flexibly-scheduled task/process in response to detect excess resource, Applicant admitted that reference Rehman teaches features of “excess resources are described as a condition under which an existing task may be handled differently” (see third paragraph of page 8 from the Remarks) and there are different types/instances of tasks (i.e., at least “high-priority tasks” and “low priority tasks”, see last paragraph of page 9 from the Remarks). According to these two features, then one with ordinary skill in the art would understand that the processes of “an existing task may be handled differently” in a condition of excess resources would require at least a sub-process of identifying particular task/process in response detecting the condition of excess resources is reached, i.e., claimed identifying step/limitation. Otherwise, the system of Rehman cannot handle the different tasks differently as described. Such as, for feature of “permitting lower priority tasks to benefit from the improved performance provided by those tiers or PoPs when excess resources are available” described by [0029] of Rehman, without identifying lower priority tasks when excess resources are available, the system of Rehman may execute higher priority tasks without executing lower priority tasks when excess resources are available.
For the argument of “Rehman discloses execution of computing tasks only in response to received requests, and does not describe initiating a computing process in the absence of such a request” (emphasis added by Examiner), again, Applicant is suggested to point out which limitation from the claimed invention would require the feature of “initiating a computing process” (actually, it is initiating a computing process to consume resources instead of initiating a computing process itself) “in the absence of such a request”. The current claimed invention is silent on whether there is a request received or not, and thus there is nothing wrong on “Rehman discloses execution of computing tasks only in response to received requests”. In addition, [0029] of Rehman describes feature of “permitting lower priority tasks to benefit from the improved performance provided by those tiers or PoPs when excess resources are available”, and thus “execution of computing tasks” from Rehman is not only in response to received requests, but also in response to detecting an excess availability of a resource.
For the argument of “detection of excess resources does not initiate execution but affects whether an already-requested task may be routed to a higher-tier PoP or processed with improved performance”, one with ordinary skill in the art cannot see any logic on this argument. The claimed initiating step/limitation is “initiate the flexibly-scheduled computing process to consume at least a portion of the excess availability of the resource”. Such claimed initiating step/limitation does not specify what kind of initiating to be performed. Routing to a higher-tier PoP from reference Rehman is about routing the task to higher-tier PoP for execution, i.e., consuming the resources of the higher-tier PoP, and thus routing to a higher-tier PoP is reasonable to be considered as initiating the task to consume the resource.
Applicant admitted that “such as routing high-priority tasks to first-tier PoPs and low priority tasks to lower tiers when resources are constrained” (see last paragraph of page 9 from the Remarks). In addition, reference Rehman also discloses: “permitting lower priority tasks to benefit from the improved performance provided by those tiers or PoPs when excess resources are available” (see [0029] from Rehman). According to these two features, the lower priority tasks from Rehman can be either executed or scheduled “when resources are constrained” or “when excess resources are available”. In this way, such lower priority tasks are a kind of flexibly-scheduled computing processes. Applicant is reminded that the independent claim 1 does not actually require the definition of claimed “flexibly-scheduled computing processes”, and thus a lower priority task from Rehman that can be executed or scheduled either of “when resources are constrained” or “when excess resources are available” is reasonable to be considered as claimed flexibly-scheduled computing process.
Once again, Applicant continued arguing some features that are not actually required by the current claim 1. Such as, Applicant argued that “Rehman does not disclose computing processes that are flexibly schedule in the sense that they are deferred until excess capacity exists, nor does it describe tasks that remain dormant until triggered by resource abundance” (see first paragraph of page 10 from the Remarks). However, none of the current claimed limitations from claim 1 requires the claimed flexibly-scheduled computing processes “are deferred until excess capacity exists” or “remain dormant until triggered by resource abundance”. Current claim 1 only requires identifying claimed flexibly-scheduled computing process in response detecting there is excess resource and initiating such claimed flexibly-scheduled computing process to consume the excess resource. However, such identifying or initiating does not require feature of the claimed flexibly-scheduled computing processes have to be deferred until excess capacity exists or is remain dormant until triggered by resource abundance. The claimed flexibly-scheduled computing process can be scheduled or even is consuming some other resource before or during “detecting the excess availability of resource” and then scheduling or initiating such flexibly-scheduled computing process to consume the excess resource in response “detecting the excess availability of resource”. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., the claimed flexibly-scheduled computing processes “are deferred until excess capacity exists” or “remain dormant until triggered by resource abundance”) 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).
Therefore, Claims 1-20 are rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rajkumar (US 20030061260 A1) discloses: soft background tasks are then assigned a lower priority than either the reserved task or the fixed priority tasks such that they may run only when additional excess resource capacity is available (see [0026]).
Shazly et al. (US 20150149636 A1) discloses: determining whether excess capacity is available on the computing platform based on the resource availability and the execution statistics; and in response to determining that excess capacity exists on the computing platform, initiating processing of the workload on the computing platform (see [0010]).
THIS ACTION IS MADE FINAL. 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 extension fee 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196