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 Office Action is in response to the amendment filed on 6/18/2026. This Action is made FINAL.
Claims 1-20 are pending and they are presented for examination.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 (similarly claims 5 and 9) recite: “wherein data for the first distributed application is transmitted in the memory pool through remote direct memory access”. The examiner is unclear of the limitation “transmitted in the memory pool through remote direct memory access”. For example, is the data transmitted into the memory pool, is the data transmitted out from the memory pool, is the data transmitted with a particular location of the memory pool to another location within the memory pool, etc.?
The specification provides two references in PGPub paragraph 8 and 42. Which merely repeats the amended portion of the claim without providing any clarification and/or description as to exactly how the amended portion of the claim should be interpreted in light of the specification.
As shown below:
[Paragraph 8], “In embodiments of this disclosure, a service is provided for an application by constructing a memory pool in a server cluster. Because data may be transmitted in the memory pool through remote direct memory access, workload of a central processing unit (CPU) of a server node is reduced.”
[Paragraph 42], “In embodiments of this disclosure, a service is provided for an application by constructing a memory pool in a server cluster. Because data may be transmitted in the memory pool through remote direct memory access, workload of a central processing unit of a server node is reduced.”
Claims 2-4, 6-8 and 10-20 are rejected based on rejection of its corresponding dependent claim.
Response to Amendment
Applicant's arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection.
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 (i.e., changing from AIA to pre-AIA ) 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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 5, 6, 9, 10, 13-15 and 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Koster et al. (Pat 10009251) (hereafter Koster) in view of Calciu et al. (Pub 20200034200) (hereafter Calciu).
As per claim 1, Koster teaches:
A method comprising:
determining a first memory requirement of a first distributed application, wherein the first memory requirement indicates a memory size; ([Column 14 line 31-67], The set of containers may include an operating-system level virtualization method for deploying and running distributed applications in an isolated environment (e.g., without launching a virtual machine for each application). [Column 21 line 1-48], A stream computing environment may include a set of three containers A, B, and C. A set of threshold parameter values may indicate memory requirements of 2 gigabytes, 4 gigabytes, and 6 gigabytes for containers A, B, and C, respectively. A set of target parameter values may indicate memory requirements of 5, 6, and 10 gigabytes for containers A, B, and C, respectively. A shared pool of configurable computing resources may have a total of 16 gigabytes of memory available for use by the set of containers.)
determining N first server nodes from among second server nodes in a server cluster based on the first memory requirement and available memory resources of the second server nodes, wherein N is an integer greater than or equal to 2; ([Column 15 line 18-36], In embodiments, the collecting, the determining, the processing, and the other steps described herein may be carried-out by an internal tuple traffic management module maintained in a persistent storage device of a local computing device (e.g., network node). In embodiments, the collecting, the determining, the processing, and the other steps described herein may be carried-out by an external tuple traffic management module hosted by a remote computing device or server (e.g., server accessible via a subscription, usage-based, or other service model). In this way, aspects of tuple traffic management in a stream computing environment to process a stream of tuples may be performed using automated computing machinery without manual action. Other methods of performing the steps described herein are also possible. [Column 3 line 33-58], Scalability is achieved by distributing an application across nodes by creating executables (i.e., processing elements), as well as replicating processing elements on multiple nodes and load balancing among them. Stream operators in a stream computing application can be fused together to form a processing element that is executable. Doing so allows processing elements to share a common process space, resulting in much faster communication between stream operators than is available using inter-process communication techniques (e.g., using a TCP/IP socket). Further, processing elements can be inserted or removed dynamically from an operator graph representing the flow of data through the stream computing application. A particular stream operator may not reside within the same operating system process as other stream operators. In addition, stream operators in the same operator graph may be hosted on different nodes, e.g., on different compute nodes or on different cores of a compute node. [Column 9 line 51-55], The computing infrastructure 400 includes a management system 405 and two or more compute nodes 410A-410D—i.e., hosts—which are communicatively coupled to each other using one or more communications networks 420. [Column 13 line 29-43], The example operator graph shown in FIG. 8 includes ten processing elements (labeled as PE1-PE10) running on the compute nodes 410A-410D. [Column 17 line 5-61], For instance, determining may include comparing the set of soft limits and the set of hard limits with respect to the current topology of the stream computing environment as well as a pool of available computing resources to ascertain a tuple flow model that achieves at least the set of soft limits and does not exceed the set of hard limits. )
constructing a memory pool based on the N first server nodes; and
providing a first service for the first distributed application based on the memory pool, wherein data for the first distributed application is transmitted in the memory pool through remote direct memory access. ([Column 5 line 31-67], Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service… Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). [Column 9 line 10-33], Service Level Agreement (SLA) planning and fulfillment provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA. A cloud manager 65 is representative of a cloud manager (or shared pool manager) as described in more detail below. While the cloud manager 65 is shown in FIG. 3 to reside in the management layer 64, cloud manager 65 can span all of the levels shown in FIG. 3, as discussed below.)
Although Koster discloses memory pool.
However, Koster does not explicitly disclose wherein data for the first distributed application is transmitted in the memory pool through remote direct memory access.
Calciu teaches wherein data for the first distributed application is transmitted in the memory pool through remote direct memory access. ([Paragraph 29], FIG. 3 depicts a pool of memories among a plurality of host computer systems. Each of the host computer systems 302.sub.1-302.sub.N includes a memory 308.sub.1-308.sub.N and a remote direct memory access (RDMA) facility 310.sub.1-310.sub.N, respectively, with memories 308.sub.1-308.sub.N thereby forming a memory pool 312. Host computer systems 302.sub.1-302.sub.N are interconnected via network 308. Network 308 has sufficient speed such that an application executing on one host, say 302.sub.1, can obtain memory pages from memories 308.sub.2-308.sub.N of other hosts 302.sub.2-302.sub.N via its RDMA facility as if the memory pages were locally present. [Paragraph 37], It should be noted that these embodiments may also apply to other examples of contexts, such as containers not including a guest operating system, referred to herein as “OS-less containers” (see, e.g., www.docker.com). OS-less containers implement operating system-level virtualization, wherein an abstraction layer is provided on top of the kernel of an operating system on a host computer. The abstraction layer supports multiple OS-less containers each including an application and its dependencies. Each OS-less container runs as an isolated process in user space on the host operating system and shares the kernel with other containers. The OS-less container relies on the kernel's functionality to make use of resource isolation (CPU, memory, block I/O, network, etc.) and separate namespaces and to completely isolate the application's view of the operating environments. By using OS-less containers, resources can be isolated, services restricted, and processes provisioned to have a private view of the operating system with their own process ID space, file system structure, and network interfaces. Multiple containers can share the same kernel, but each container can be constrained to only use a defined amount of resources such as CPU, memory and I/O.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Koster wherein memory requirement of a distributed application is determined, number of server nodes to create a pool of resource(s) (i.e. memory) based on the memory requirements are determined for service provided by the distributed application, into teachings of Calciu wherein an the distributed application data is transmitted in the memory pool through remote direct memory access (RDMA), to access data from the memory pool located on another host, because this would enhance the teachings of Koster wherein by using RMDA to access/transmit the distributed application data, the distributed application can access memory of the memory pool located on another host using RDMA as if the memory/memory pool were locally present. [Calciu paragraph 29]
As per claim 2, rejection of claim 1 is incorporated:
Koster teaches wherein determining the N first server nodes comprises: determining a first type of the first distributed application; and
further determining the N first server nodes based on the first type. ([Column 5 line 58-67 – Column 6 line 1-2], Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service. [Column 22 line 40-67 – Column 23 line 1-25], For instance, the set of tuple traffic indicators may indicate the amount (e.g., 10 gigabytes), rate (e.g., 1000 tuples per second), type (e.g., Internet-of-Things data), workload intensity (e.g., heavy, light), priority level (e.g., high, low), congestion (e.g., 20% backpressure) or other factors that describe the nature of tuple flow with respect to the set of container.)
As per claim 17, rejection of claim 1 is incorporated:
Koster teaches wherein a sum of the available memory resources of the N first server nodes meets the first memory requirement. ([Column 21 line 1-48], A set of threshold parameter values may indicate memory requirements of 2 gigabytes, 4 gigabytes, and 6 gigabytes for containers A, B, and C, respectively. A set of target parameter values may indicate memory requirements of 5, 6, and 10 gigabytes for containers A, B, and C, respectively. A shared pool of configurable computing resources may have a total of 16 gigabytes of memory available for use by the set of containers.)
As per claim 18, rejection of claim 1 is incorporated:
Koster teaches further comprising obtaining a mapping relationship between the first memory requirement and a quantity of first server nodes required for constructing the memory pool before determining the N first server nodes. ([Column 21 line 1-48], In embodiments, the set of threshold parameter values for the set of utilization parameters may be prioritized relative to the set of target parameter values for the set of utilization parameters at block 1044. The prioritizing may be performed when resolving the tuple flow model with respect to the set of containers in the stream computing environment. Generally, prioritizing can include arranging, weighting, organizing, promoting, ranking, or otherwise favoring the set of threshold parameter values relative to the set of target parameter values. In embodiments, prioritizing may include balancing system resources of the stream computing environment with respect to the set of containers to facilitate achieving the set of threshold parameter values (e.g., soft limits, lower thresholds) for one or more containers before achieving the set of target parameter values (e.g., hard limits, upper thresholds) for a container of the set of containers (e.g., to prioritize basic functionality/operation of each container before fulfilling extra performance requirements). For instance, prioritizing may include allocating system resources from the shared pool of configurable resources to the set of containers such that the set of threshold parameter values for each container are fulfilled, and subsequently re-evaluating the set of containers with respect to the remaining available system resources to ascertain how they may be distributed to achieve the set of target parameter values for one or more containers of the set of containers. Consider the following example. A stream computing environment may include a set of three containers A, B, and C. A set of threshold parameter values may indicate memory requirements of 2 gigabytes, 4 gigabytes, and 6 gigabytes for containers A, B, and C, respectively. A set of target parameter values may indicate memory requirements of 5, 6, and 10 gigabytes for containers A, B, and C, respectively. A shared pool of configurable computing resources may have a total of 16 gigabytes of memory available for use by the set of containers. Accordingly, the set of threshold parameter values may be prioritized such that 2 gigabytes are allocated to container A, 4 gigabytes are allocated to container B, and 6 gigabytes are allocated to container C. Subsequent to achievement of the threshold parameter values for the set of containers, remaining resources may be distributed among the set of containers to promote positive performance of stream computing applications (e.g., an additional 4 gigabytes may be allocated to container C; an additional gigabyte may be distributed to each of containers A, B, and C). Other example usage cases (e.g., in which the set of target parameter values are prioritizes with respect to the set of threshold parameter values) are also possible. Other methods of prioritizing the set of threshold parameter values relative to the set of target parameter values are also possible. )
As per claim 19, rejection of claim 2 is incorporated:
Koster teaches wherein the first type is a database application type. ([Column 3 line 20-32], Stream-based computing and stream-based database computing are emerging as a developing technology for database systems.)
As per claims 5-6, these are sever cluster claims, corresponding to the method claims 1 and 2. Therefore, rejected based on similar rationale.
As per claims 9-10 and 13-15, these are non-transitory computer-readable storage medium claims, corresponding to the method claims 1-2 and 17-19. Therefore, rejected based on similar rationale.
Claim(s) 3, 7, 11, 16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Koster in view of Tsirkin et al. (Pub 20220276889) (hereafter Tsirkin).
As per claim 3, rejection of claim 2 is incorporated:
Although Koster discloses dynamic allocation/elasticity of physical and/or virtual resource(s) based on type of application.
Koster does not explicitly disclose wherein determining the N first server nodes further comprises: determining a memory ballooning coefficient corresponding to the first distributed application based on the first type; and
further determining the N first server nodes based on the memory ballooning coefficient.
Tsirkin teaches wherein determining the N first server nodes further comprises: determining a memory ballooning coefficient corresponding to the first distributed application based on the first type; and
further determining the N first server nodes based on the memory ballooning coefficient. ([Paragraph 13], The guest operating system may inflate the memory balloon to reduce the amount of host memory in use by the virtual machine or may deflate the memory balloon to increase the amount of host memory in use by the virtual machine. [Paragraph 42], The content of the request may include data that is associated with the memory balloon. The data may indicate or identify the memory balloon, guest operating system, virtual machine, hypervisor, host, memory, other entity or a combination thereof. The content may also or alternatively indicate whether a size of the memory balloon should change (e.g., increase or decrease) and may include a size value. The size value may correspond to a size of the memory balloon (e.g., past, current, or future total size) or the size of a change to the memory balloon (e.g., increment size, decrement size). In one example, the request may indicate a particular amount of memory to add to the memory balloon (e.g., 1 GB).)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Koster and Calciu wherein memory requirement of a distributed application is determined, number of server nodes to create a pool of resource(s) (i.e. memory) based on the memory requirements are determined for service provided by the distributed application and data for the distributed application is transmitted in the memory pool through remote direct memory access, into teachings of Tsirkin wherein memory ballooning coefficient (i.e. set memory size) is determined, because this would enhance the teachings of Koster and Calciu wherein by providing a resource ballooning, resource(s) such as memory can be inflated/deflated to reduce an amount of host resource(s) (i.e. memory, cpu, network, etc.) used by the distributed application (i.e. container, VM) based on the type.
As per claim 7, this is a sever cluster claim, corresponding to the method claim 3. Therefore, rejected based on similar rationale.
As per claim 11, this is a non-transitory computer-readable storage medium claim, corresponding to the method claim 3. Therefore, rejected based on similar rationale.
As per claim 16, this is a non-transitory computer-readable storage medium claim, corresponding to the method claim 20. Therefore, rejected based on similar rationale.
As per claim 20, rejection of claim 2 is incorporated:
However, Koster in view of Calciu do not explicitly disclose wherein the first type corresponds to a memory ballooning coefficient of 2 for determining the N first server nodes.
Tsirkin teaches wherein the first type corresponds to a memory ballooning coefficient of 2 for determining the N first server nodes. ([Paragraph 13], The guest operating system may inflate the memory balloon to reduce the amount of host memory in use by the virtual machine or may deflate the memory balloon to increase the amount of host memory in use by the virtual machine. [Paragraph 42], The content of the request may include data that is associated with the memory balloon. The data may indicate or identify the memory balloon, guest operating system, virtual machine, hypervisor, host, memory, other entity or a combination thereof. The content may also or alternatively indicate whether a size of the memory balloon should change (e.g., increase or decrease) and may include a size value. The size value may correspond to a size of the memory balloon (e.g., past, current, or future total size) or the size of a change to the memory balloon (e.g., increment size, decrement size). In one example, the request may indicate a particular amount of memory to add to the memory balloon (e.g., 1 GB).)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Koster and Calciu wherein memory requirement of a distributed application is determined, number of server nodes to create a pool of resource(s) (i.e. memory) based on the memory requirements are determined for service provided by the distributed application and data for the distributed application is transmitted in the memory pool through remote direct memory access, into teachings of Tsirkin wherein memory ballooning coefficient (i.e. 2 to set memory size by a fixed amount) is determined, because this would enhance the teachings of Koster and Calciu wherein by providing a resource ballooning coefficient, the coefficient can be used to indicate/identify guest operating system, virtual machine, hypervisor, host, memory, other entity or a combination thereof needed to provide the memory ballooning.
Allowable Subject Matter
Claim(s) 4, 8 and 12 is/are objected to as being dependent upon a rejected base claim and 112 rejection(s) set forth, but would be allowable if rewritten in independent form including all of the limitations of the base claim, any intervening claims and 112 rejections set forth having been addressed.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 5712723338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DONG U KIM/Primary Examiner, Art Unit 2197
Prosecution Insights