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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 6/8/2026 has been entered.
Claims 1-3 and 5-20 are presented for examination. Claims 1 and 19-20 have been amended. Claims 4 have been cancelled.
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 Objections
Claims 1-3 and 5-20 are objected to because of the following informalities:
“the video processing application program” at line 6 of claim 1 should be: the real-time or near-real-time video processing application program (note: some other locations of claims 1, some dependent claims and claims 19-20 contains similar objection issue, such as “the application program” at line 8 of claim 1, “the application program” at line 2 of claim 5, “the video processing application program” at line 7 of claim 19, “the video processing application program” at line 8 of claim 20 and etc., and thus all of these claims/limitations are also objected due to same reason).
Claims 2-3 and 5-18 are objected for failing to cure the deficiency from their respective parent claim by dependency
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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 1-3, 5-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lin et al. (CN 112199194 A-IDS recorded, hereafter Lin) in view of Chen et al. (US 20180109464 A1, hereafter Chen) and Maurya et al. (US 20220035651 A1, hereafter Maurya).
Note: again, Applicant also provided/attached the English translation version of Lin with the IDS submitted. However, the paragraph numbers used by the provided/attached English translation version do not match with original publication version. Such as, paragraph indicated as [0002] from the English translation version is actually indicated as [0001] at the original publication version; the last paragraph of the English translation version is indicated as [0267] while the last paragraph of the original publication version is indicated as [0262]. For this issue, all paragraphs used/cited at this Office Action for reference Lin are based on the paragraph numbers from the original publication version instead of the provided/attached English translation version.
Regarding to claim 1, Lin discloses: A computer-implemented resource allocation method (see [0111]; “a resource scheduling method based on a container cluster provided by Embodiment 2 of the present invention. This embodiment uses the foregoing embodiment as a basis to further refine the operation of the scheduling component to allocate CPU resources”), comprising, in a computing environment comprising a resource management unit and a cluster comprising a cluster management node and a cluster node running an application program (see Fig. 2, [0035]-[0046] and [0097]; the dynamic-hybrid-controller discussed at [0044]-[0046] is mapped to claimed resource management unit; the worker node having pod online discussed at [0037], [0041]-[0042] is mapped to claimed cluster, such worker node comprising vscaled discussed at [0097], i.e., claimed cluster management node, and pod discussed [0041], i.e., claimed cluster node running an application program. Also see [0033] and [0041] for pod is reasonable to considered as a cluster node running containerized software application):
receiving a request specifying allocating one or more system resources to be allocated to the application program (see [0112]-[0113]; “Receive an update event of the instance … The resource declared by requests is the basis of the container cluster Kubernetes during scheduling”. Also see [0097]-[0103]; “dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration, … Cgroup is a resource restriction mechanism provided by Linux. It can be configured and modified in the form of editing files ,,, determine the resources (such as CPU, memory, etc.) allocated to the instance pod, and obtain resource allocation information … write the resource allocation information into the configuration file … Changes in the annotations”. In this way, the update event of the instance discussed at [0112]-[0113] in one of the reasonable embodiments being an event or request to allocate or update system resources allocate to the application program running on pod);
retrieving from the cluster management node, an identifier of the cluster node running the application program (see Fig. 2, [0102]-[0108], [0116]-[0122]. Fig. 2 shows at least one node or cluster are running multiple pods, and thus it is required for the vscaled to know which pod of the given node is associated with the received update event/request. In addition, “$pod_id” from [0105] and [0106] also provide evidence to show it is required to retrieve identifier of the pod or claimed cluster node running the application program for received update event/request in order to modify correct configuration file for correct pod to complete the expansion and shrinking operations discussed at [0103]); and
dynamically updating system physical resources allocated to the cluster node, while the cluster node continues running the application program without restarting or creating the cluster node, by updating a resource allocation file managed by an operating system of a computing machine on which the cluster is running, based on the identifier of the cluster node and the received request (see [0097]-[0108]; “dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration, so that they can Modify the configuration file cgroup under the premise of restarting the pod node to achieve the effect of resource scaling … Cgroup is a resource restriction mechanism provided by Linux” (note: although the English translation provided by Applicant submitted IDS here saying “under the premise of restarting the node pod”, the original publication is about: under the premise of without restarting the node pod. It is a translation issue from Applicant provided version instead of reference teach away. Examiner also attached several different versions of translation at the Conclusion session to support examiner’s explanation. If Applicant disagrees examiner’s explanation, Applicant is suggested to make a request to obtain a human language translation under the policy described by MPEP, see section II. RELIANCE UPON ABSTRACTS AND FOREIGN LANGUAGE DOCUMENTS IN SUPPORT OF A REJECTION from MPEP § 2120 Rejection on Prior Art) and “modifies the configuration file cgroup of the corresponding container to complete the expansion and shrinking operations”. Also see [0116] and [0145]; “the request/limit of the container will be converted to the configuration file linux cgroup, and the purpose of limiting the use of container resources is achieved through the configuration file cgroup” and “The configuration file cgroup is a resource restriction mechanism provided by the Linux operating system”).
Note: the claimed feature of “dynamically updating system physical resources allocated to the cluster node” under BRI is performed by claimed “updating a resource allocation file managed by an operating system of a computing machine on which the cluster is running, based on the identifier of the cluster node and the received request”, and thus achieving the feature of “updating a resource allocation file … and the received request” would achieve feature of “dynamically updating system physical resource allocated to the cluster node” (no matter updating resource allocation file is updating system physical resource on the resource allocation file or updating virtual resource information associated with the system physical resource on the resource allocation file). If Applicant intends to interpret the claimed updating a resource allocation file would involve with feature of updating system physical resources in the resource allocation file, then Applicant is suggested to amend the claims to further specify the claimed updating a resource allocation file would include updating the actual allocated system physical resources mapped to the virtual resource allocated to the cluster node on the resource allocation file.
Lin does not disclose: the application program running at the cluster node is a real-time or near-real-time video processing application program; the request is received by the source management unit and the identifier of cluster node is retrieved by the resource management unit.
However, Chen discloses: a cluster node running a real-time or near-real-time video processing application; a system resource allocation operation caused by the video processing application program (see [0046]; “detect the adjusted CPU resource usage (block 428), the adjusted I/O resource usage (block 429) and the adjusted network traffic resource usage (block 430) … The frequency of adjustment and detection may be high frequency for real-time applications such as video streaming, trading, and paid or enterprise containers (e.g., every one hundred ms, or every fifty ms, or every forty ms)”. Also see [0002], [0016], [0018], [0034]; “dynamically adjusting control group resource allocation to a container. A central processing unit (“CPU”) resource usage of a container in a first host may be detected in a directed acyclic graph (“DAG”). The container may be in a first host. The CPU resource may be associated with a first control group (“cgroup”)” and “incrementally adjust the CPU resource of cgroup 155A such that the container 197A is allocated an additional percentage of the CPU resources of cgroup 155A for a total of 24% of the CPU resources in cgroup 155A”).
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 generic software program running at container to cause dynamic resource allocation operation via cgroup from Lin by including real-time video software program running at container to cause dynamic resource allocation operation via cgroup from Chen, since it well-known and understood to running a specific type of application program instead of a generic application program at a computing environment.
In addition, Maurya discloses:
receiving, by the resource management unit, a request for modifying the cluster node running the application program (see claims 5-6; “the compute deployment agent is a master worker node of a Kubernetes worker node cluster that receives requests to modify a set of machines in the Kubernetes worker node cluster … a request to modify a deployed machine, the set of machines comprising at least one of a container, and a pod that requires a connection to the VPC”. Also see [0068]; “if the request … (2) relates to a pod on the host computer of the DNPA instance to be created, removed, or modified”);
retrieving, by the resource management unit, from the cluster management node, an identifier of the cluster node running the application program (see [0071]-[0072]; “retrieves (at 910) metadata associated with the selected request. In some embodiments, retrieving the metadata includes retrieving at least a portion of the metadata from the request queue. Additional metadata, in some embodiments, is retrieved from a worker or master node of a cluster related to the request”, “identifying, at a cluster manager plugin, network elements that are affected by the cluster-level request. For example, a request to implement a load balancer or firewall requires a generation of data identifying Pods, containers, and/or machines for which to provide the load balancing … the generated data includes at least one port identifier for a requested Pod-level construct”).
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 resource reallocation or modification operations for a requesting pod executing on a worker node from the combination of Lin and Chen by including a manager component of a master node receives requests for associated worker nodes and identifies associated pods or containers for the received requests from Maurya, and thus the combination of Lin, Chen and Maurya would disclose the missing limitations from Lin, since it would provide a central management mechanism to manage requests from all of associated worker nodes.
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the cluster node is comprised in a cluster computing node of the cluster (see Fig. 2, [0037]-[0041] from Lin; “A node is a physical machine … The node can run the following components: … Pod (instance)”).
Regarding to Claim 3, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the system physical resources allocated to the cluster node were allocated by the cluster management node to the cluster node (see [0097] from Lin; “vscaled (scheduling component … dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration)”).
Regarding to Claim 5, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the request comprises system resources of the computing machine to be allocated to the application program (see [0097], [0121] and [0137] from Lin; “dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration”, “If the two instance pods declare the bound processors in turn, 4 logical cores and 2 logical cores are required, respectively”).
Regarding to Claim 6, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the resource allocation file is used by the operating system to allocate resources of the computing machine to the cluster node (see [0097]-[0099], [0145]; “dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration, so that they can Modify the configuration file cgroup … Cgroup is a resource restriction mechanism provided by Linux”, “modifies the configuration file cgroup of the corresponding container to complete the expansion and shrinking operations” and “The configuration file cgroup is a resource restriction mechanism provided by the Linux operating system”).
Regarding to Claim 7, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the cluster node comprises one or more container nodes, wherein the method further comprises: retrieving, by the resource management unit, from the cluster management node, respective identifiers of the one or more container nodes, and wherein the resource allocation file is updated based on the identifiers of the one or more container nodes (see Fig. 2, [0102]-[0108], [0116]-[0122] from Lin. Fig. 2 shows at least one node or cluster are running multiple pods, and thus it is required for the vscaled to know which pod of the given node is associated with the received update event/request. In addition, “$pod_id” and “$container_id” from [0105] and [0106] also provide evidence to show it is required to retrieve identifier of the pod and claimed identifiers of the one or more container nodes for received update event/request in order to modify correct configuration file for correct pod/container to complete the expansion and shrinking operations discussed at [0103].Also see [0141]-[0145] from Lin; “the first configuration file cgroup of the instance pod … the second configuration file cgroup of the container in the instance pod”).
Regarding to Claim 8, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses:
creating, by the resource management unit, a resource allocation process running on the operating system in a cluster computing node of the cluster (see [0069], [0074] from Maurya and [0097] from Lin; “If the selected request is determined (at 815) to be related to the DNPA instance that received the notification, the DNPA instance stores (at 820) the request to a request queue 486 of the DNPA”, “the request, the retrieved metadata, and any generated data are sent (at 930) to the network manager (e.g., by the CMP 484 or PMP 483 using communication agent 482)”, “vscaled (scheduling component … dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration)”. At the combination system, after the dynamic-hybrid-controller as claimed resource management unit OR central management component of the Kubernetes system receives resource allocation or update request for a particular pod running on a particular worker node and retrieves corresponding pod or container identifiers, such dynamic-hybrid-controller would forward such resource allocation or update request to the corresponding worker node for actual execution, i.e., vscaled of the particular worker node is started to perform the resource allocation or update. Note: vscaled was already existed at the worker node, however the actual execution of the resource allocation or update operation/process is started after the dynamic-hybrid-controller forwards the request to the corresponding worker node, and thus it is reasonable to conclude that the dynamic-hybrid-controller forward, i.e., claimed resource management unit creates/commences the resource allocation or update operation, i.e., claimed resource allocation process, at the particular worker node associated with the request);
receiving, from the resource allocation process, a first resource allocation status of system resources currently allocated to the cluster node (see [0127]-[0128] from Lin; “the scheduling component vscaled can read the topology of the processor …. and maintain the state of the processor in the memory, where the state includes an idle state, Bound state, idle state means unbound, and bound state means bound”); and
determining a system resource allocation update based on the first resource allocation status and the received request; and wherein the resource allocation file is updated based on the system resource allocation update (see [0097], [0139]-[0145] from Lin; “vscaled (scheduling component … dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration” and “if the scheduling component vscaled finds an idle state (that is, unbound) and a logical core that satisfies the configuration information as the target core, the instance pod can be bound to the target core … the sequence number of the target core can be set to the bind mode cpuset in the first configuration file cgroup of the instance pod … to update the serial number of the target core to the binding mode cpuset in the second configuration file cgroup of the container in the pod of this instance”).
Regarding to Claim 9, the rejection of Claim 8 is incorporated and further the combination of Lin, Chen and Maurya discloses: transmitting to the resource allocation process a request for the first resource allocation status, wherein the first resource allocation status is received in response to the request for the first resource allocation status (see [0124], [0128] from Lin; “list is the list API that calls resources to list resource” and “the scheduling component vscaled can read the topology of the processor …. and maintain the state of the processor in the memory, where the state includes an idle state, Bound state, idle state means unbound, and bound state means bound”. Requesting to perform list API and then receiving resources’ allocation states).
Regarding to Claim 10, the rejection of Claim 8 is incorporated and further the combination of Lin, Chen and Maurya discloses: receiving, from the resource allocation process, a second resource allocation status of system resources that are not currently allocated to the cluster node, wherein the system resource allocation update is further determined based on the second resource allocation status (see [0127]-[0128] and [0139]-[0145] from Lin; “the scheduling component vscaled can read the topology of the processor …. and maintain the state of the processor in the memory, where the state includes an idle state, Bound state, idle state means unbound, and bound state means bound” and “if the scheduling component vscaled finds an idle state (that is, unbound) and a logical core that satisfies the configuration information as the target core, the instance pod can be bound to the target core … the sequence number of the target core can be set to the bind mode cpuset in the first configuration file cgroup of the instance pod … to update the serial number of the target core to the binding mode cpuset in the second configuration file cgroup of the container in the pod of this instance”).
Regarding to Claim 11, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein dynamically updating resource allocation files managed by the operating system comprises: updating respective values of one or more resource allocation parameters configured in the resource allocation file for the cluster node (see [0097], [0141]-[0145] from Lin; “dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration”, “the sequence number of the target core can be set to the binding mode cpuset in the fist configuration file cgroup of the instance pod … to update the serial number of the target core to the binding mode cpuset in the second configuration file cgroup of the container in the pod of this instance”).
Regarding to Claim 12, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the one or more system resources comprise CPU resources which comprise a CPU quota parameter defining a number of CPU cores, wherein the updating the resource allocation file comprises setting a value of the CPU quota parameter to a value representing a number of CPU cores allocated to the cluster node (see [0105], [0117]-[0119] from Lin; “cpuset.huya.com:4”).
Regarding to Claim 13, the rejection of Claim 12 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the value represents an integer number of CPU cores (see [0105], [0117]-[0119] from Lin; “cpuset.huya.com:4”).
Regarding to Claim 14, the rejection of Claim 12 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the cluster node is comprised in a cluster computing node of the cluster, wherein the cluster computing node is executed on a physical machine (see [0037]-[0041] from Lin; “A node is a physical machine … The node can run the following components: … Pod (instance)”), and wherein the value is determined such that a cumulative number of CPU cores allocated to cluster nodes of the cluster computing node does not exceed CPU resources that are available on the physical machine (see [0127]-[0128] and [0137] from Lin; “search for a logical core that is in an idle state and meets the configuration information as a target core”, “it maintains a list of logical cores … If the two instance pods declare the bound processors in turn, 4 logical cores and 2 logical cores are required, respectively … and other instance pods are bound to the logical cores with the sequence number [0, 25]”).
Regarding to Claim 15, the rejection of Claim 12 is incorporated and further the combination of Lin, Chen and Maurya discloses: in case a cumulative number of CPU cores allocated to cluster nodes of the cluster computing node exceeds CPU resources that are available on a physical machine, responding to the request for allocating one or more system resources with a message informing that the request cannot be served (see [0138] from Lin; “in the case of many logical cores that have been bound, the logical cores in the idle state … a binding failure event can be generated, Bind the binding failure event to the current instance pod, and notify the upper application of the container cluster Kubernetes”).
Regarding to Claim 16, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the one or more system resources comprise CPU resources which comprise CPU cores (see [0097] and [0131] from Lin; “dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration”),
wherein the updating the resource allocation file comprises assigning all software threads of the cluster node to one or more CPU cores among the CPU cores (see [0132]-[0138] from Lin; “search the processor in the current node node to find the logic that is in the ideal state (that is, not bound) and meets the configuration information Nuclear, as the target core”, “in the case of many logical cores that have been bound, the logical cores in the idle state … a binding failure event can be generated”. All of the logical cores assigned/bound to the pod, i.e., claimed software threads, are found among the physical CPU cores of the node, and thus the logical cores or the software threads are assigned to the one or more physical CPU cores).
Regarding to Claim 17, the rejection of Claim 16 is incorporated and further the combination of Lin, Chen and Maurya discloses: assigning a maximum execution priority to the execution of the cluster node on the one or more CPU cores (see [0143]-[1044] from Lin; “the state of the target core is changed from the idle state to the bound state to prevent subsequent calls by other instance pods”).
Regarding to Claim 19, Claim 19 is a system claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above.
Regarding to Claim 20, Claim 20 is a product claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Lin et al. (CN 112199194 A-IDS recorded, hereafter Lin) in view of Chen et al. (US 20180109464 A1, hereafter Chen), Maurya et al. (US 20220035651 A1, hereafter Maurya) and further in view of Dong et al. (US 20130167146 A1, hereafter Dong).
Regarding to Claim 18, the rejection of Claim 1 is incorporated and further the combination of Lin, Chen and Maurya discloses: wherein the one or more system resources comprise CPU resources which comprise CPU cores (see [0097] and [0131] from Lin; “dynamically adjust the CPU bound to the instance pods according to their declared binding core configuration”),
wherein the updating the resource allocation file comprises assigning all software threads of the cluster node to CPU cores of [a same] physical CPU node of the cluster computing node (see [0132]-[0138] from Lin; “search the processor in the current node node to find the logic that is in the ideal state (that is, not bound) and meets the configuration information Nuclear, as the target core”, “in the case of many logical cores that have been bound, the logical cores in the idle state … a binding failure event can be generated”. All of the logical cores assigned/bound to the pod, i.e., claimed software threads, are found among the physical CPU cores of the node, and thus the logical cores or the software threads are assigned to the one or more physical CPU cores).
The combination of Lin, Chen and Maurya does not disclose: assigning all software threads of the cluster node to CPU cores of a same physical CPU node of the cluster computing node.
However, Dong discloses: assigning all software threads of the cluster node to CPU cores of a same physical CPU node of the physical computing node (see [0025], [0037]; “if virtual central processing units of virtual machine A and virtual machine B are scheduled on the same physical processing unit, due to the cache contents loaded by the virtual central processing unit of virtual machine A at execution time being reusable by the virtual central processing unit of virtual machine B” and “schedule virtual central processing units of virtual machines of a group on the same physical processing unit”. Note: although Dong only used terms/objects like “virtual central processing units” instead of claimed “software threads”, it is reasonable to consider the threads of such virtual central processing units as claimed software threads due to it is understood that threads are the smallest execution components at computing fields and the threads of such virtual central processing units are software implemented due to the virtualization technology).
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 allocations of virtual processors of a requesting pod or container from the combination of Lin, Chen and Maurya by including allocating or assigning all of virtual processors of a group of virtual machines on same physical processor from Dong, and thus the combination of Lin, Chen Maurya and Dong would discloses the missing limitations from the combination of Lin, Chen and Maurya, since it would provide a mechanism of allocating processor resources efficiently via allocating related processes within same processor (see [0025] from Dong; “the cache contents loaded by the virtual central processing unit of virtual machine A at execution time being reusable by the virtual central processing unit of virtual machine B”).
Response to Arguments
Applicant’s arguments, filed 5/13/2025, with respect to rejections of claims 1-3 and 5-20 under 35 U.S.C. 103 have been full considered. New grounds of rejections are made based on the amended limitations from the independent claims. In addition, some of Applicant’s arguments are not persuasive.
Applicant’s arguments at pages 7-12 are summarized as the following:
“claim 1 has been amended to be limited to a real-time or near real-time video processing context. In contrast, Lin is directed to Kubernetes resource scheduling for mixed deployment of online and offline services, in particular dynamically adjusting resources occupied by offline services based on scheduling policies and resource utilization”. “This limitation is material because real-time video processing is technically sensitive to interrupt: restarting a Pod may cause loss of encoder state, loss of buffered frames, interruption of the encoded stream, and loss of real-time operation. The offline workload scheduling taught in Lin is not concerned with preserving encoder state, buffered video frames, live output continuity, or real-time/near-real-time video constraints. Thus, even though Lin may teach Kubernetes cgroup/cpuset manipulation, Lin does not teach or even suggest applying such manipulation to solve the particular technical program addressed by the amended claim: dynamically changing physical resources for alive video encoder/decoder without interrupting the running video application” (see 2nd to 5th paragraphs of page 8 from the Remarks). “The offline/online colocation strategy taught by Lin would not provide a reason to target a real-time video encoder/decoder, where interruption and state loss are the central technical concerns” (see 1st paragraph of page 9 from the Remarks).
“the proposed combination of Lin and Maurya would be based on impermissible hindsight” (see last paragraph of page 9 from the Remarks). “A person of ordinary skill in the art starting from the teachings of Lin would understand Lin’s controller as a resource-utilization and mixed-deployment mechanism, not as a solution for preserving real-time video encoder/decoder execution continuity. Further, Maurya would not motivate the skilled person to modify Lin in this direction because Maurya is concerned with network-manager request handling and distributed network plugin agents, not with OS-level physical resource reallocation for live video processing. Thus, any assertion that would have been obvious to adapt Lin’s offline-business resource scheduling to a real-time video encoder/decoder would require using Applicant’s disclosure as a roadmap” (see 1st to 3rd paragraph of page 10 from the Remarks).
The examiner respectively disagrees.
First of all, Applicant is suggested to review the disclosure from Lin carefully since Lin not only discusses “dynamically adjusting resources occupied by offline services based on scheduling policies and resource utilization”, but also discusses feature of dynamically adjusting resource occupied by online services based on scheduling policies and resource utilization. See “They can monitor the status changes of all instance pods on the machine, and dynamically adjust the CPU bound to the instance pod according to their declared binding core configuration” from [0097] (emphasis added. Note: it is “all instance pods” instead of offline pods/instances or online pods/instances); “users can modify the metadata … where the online business or offline business is located according to the needs of the online business or offline business, and declare the processor to be bound” from [0119] (emphasis added. Note: the processor resource bind request or declaration is available to both of online business or offline business instead of offline business only), “in the low hours of online services in the morning and early morning, more resources can be dispatched of offline services, During the daytime, the online services are busy. Dispatch mor resources to online services … scheduling strategy for different periods, flexible now height, and adaptable to different periods of online business” from [0053]-[0054]. Thereby, it is not clear Applicant’s purpose on arguing the offline services features from Lin against claimed invention only.
Secondly, the online and offline from Lin only represent network connection status of the services or Kubernetes/pods without limiting the possibility of further real-time or near real-time application on the services or Kubernetes/pods. It is understood to one with ordinary skill in the art that real-time or near real-time software application (no matter it is video processing application or not) can be implemented in either one of online or offline (note: examiner attached several references discuss implementing real-time feature with offline service at the Conclusion session). Such as, a rea-time video monitoring or surveillance via camera can be implemented as either one of online service or offline service. In addition, Applicant’s specification does not limit Applicant’s real-time video processing application is implemented at online Kubernetes/pods only or offline Kubernetes/pods only. Thereby, it is not clear Applicant’s logic on keeping arguing the offline service features against with real-time video application from the amended claims.
See response a) above. Once again, the dynamically resources adjustment via cgroup feature from Lin can also apply to the online Kubernetes/pods/services; and it is still possible and reasonable to implement a real-time video application at offline Kubernetes/pods or services/environment.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Aleti et al. (US 10942774 B1) discloses: For security applications that rely on events being received, stored, and processed in real time, the isolation between the processing of search query requests and data ingest requests means that the amount of resource allocation can be maintained to achieve the real time requirements (see lines 39-44 of col. 32), to enforce the resource allocation, the data intake and query system may use operating system processes that enforce according to Cgroups (see lines 14-16 of col. 34), the in-memory state of the system changes and future requests will use the new workload management configuration that has been dispatched without requiring any system restarts or causing interruption (see lines 25-28 of col. 37).
Stetter, JR. et al. (US 20210064429 A1) discloses: Once a workload with real-time execution signature has been identified, the workload will be assigned to the “Dedicated” class. This causes the workload to be scheduled to execute on a CPU core that is isolated from all other workloads, perhaps by utilizing Linux cgroups and CPUsets (see [0148]).
Peteva et al. (US 20170199770 A1) discloses: When performing the scaling task, the autoscale worker 616 may update the cgroup values for the respective container 112 in real-time. The update may include redefining the new resource requirement within in the kernel. To this end, the resource is increased without an interruption to the hosting service being provided by the container (see [0137]-[0138]).
Tamir et al. (US 20120013711 A1) discloses: The invention is in the field of three dimensional (3D) real time and offline video production (see [0002]).
Tan et al. (CN 111610989 A-translated by Google Patents, publication date: 9/1/2020) discloses: improves the real-time automatic processing capability of offline container cloud environment application release/update (see abstract).
Song et al. (CN 112130994 A-translated by Google Patents, publication date: 12/25/2020) discloses: the first preset resource upper limit corresponding to the offline service in the form of the real-time video stream can be preset (see [0088]).
Xia (CN 112261438 A-translated by Google Patents, publication date: 1/22/2021) discloses: For the offline video, the terminal can also generate a brightness information file in real time in the process of playing the offline video (see [0099]).
Dong et al. (CN 110572617 A-translated by Google Patents, publication date: 12/13/2019) discloses: packaging all the quasi-real-time offline videos of the live devices one by one into tasks (see [0326]).
Wu et al. (CN 110414381 A-translated by Google Patents, publication date: 11/5/2019) discloses: it can be achieved that offline in real time to pair of video flowing or static images (see [0028]).
Lin et al. (CN 112199194A-IDS recorded, translated by IP.com) discloses: to modify a configuration file cgroup without restarting the nodes pod (see 4th paragraph of page 11).
Lin et al. (CN112199194A-IDS recorded, translated by Google Patents) discloses: to modify a configuration file cgroup without restarting the nodes pod (see 17th paragraph of page 37 at PDF file)
[0097] of Lin et al. (CN 112199194 A-IDS recorded) translated by Google Translate discloses: the cgroup configuration file can be modified without restating the pods.
[0097] of Lin (CN 112199194A-IDS record) translated by WIPO discloses: the fixed CPU modifies the configuration file cgroup without restarting the node pod.
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
Prosecution Insights