CTNF 18/418,710 CTNF 90981 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 Claims 4, 14, and 18 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 4 recites the limitation “the user” in line 4. There is insufficient antecedent basis for this limitation in the claim. Only “a user-defined scaling policy” has been defined. Claims 14 and 18 are indefinite for the same reason. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 requires: monitoring, by an orchestrator, data stream ingestion of a streaming storage system (SSS) to obtain data stream metrics; analyzing, by the orchestrator, the data stream metrics based on a user-defined scaling policy; making, based on the analyzing and by the orchestrator, a first determination that task manager scaling is required, wherein a stream processing system (SPS) comprises a plurality of task managers, wherein the SSS and the SPS communicate over a network and form the data stream processing pipeline; in response to the first determination and by the orchestrator, making a second determination that the data stream ingestion is increased, wherein the second determination indicates an increase in a number of parallel stream segments associated with a data stream, wherein a segment store hosted by the SSS manages the parallel stream segments. The limitation of monitoring to obtain data metrics, analyzing , making a first determination, and making a second determination , as drafted, is a method that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting an “orchestrator,” nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the “orchestrator” language, monitoring to obtain data metrics, analyzing , making a first determination, and making a second determination in the context of this claim encompasses the user manually analyzing and making determinations. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Process” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. This judicial exception is not integrated into a practical application. In particular, the claim additionally recites “in response to the second determination and to increase the SPS’ compute capability, initiating, by the orchestrator, scaling of a number of the plurality of task managers to support the increase in the number of the parallel stream segments.” The initiating and scaling are recited at a high-level of generality (i.e., as a generic computer hardware) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of “in response to the second determination and to increase the SPS’ compute capability, initiating, by the orchestrator, scaling of a number of the plurality of task managers to support the increase in the number of the parallel stream segments” amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claim is not patent eligible. Regarding claim 2, it further refines the obtained data stream metrics based on the monitoring, which can be performed in the human mind (mentally) by viewing data on a terminal and mentally determining different metrics. Accordingly, claim 2 is ineligible. Regarding claim 3, it further recites generic computing components, which amounts to mere instruction to apply an exception. See MPEP § 2106.05(f). Regarding claim 4, it further defines the scaling policy; however, the scaling is still recited at a high level of generality and amounts to mere instructions to apply an exception. Regarding claim 5, it further defines the data stream; however, a human operator is still capable of viewing the data on a terminal to perform the mental determinations. Accordingly, claim 5 is ineligible. Regarding claim 6, it further requires a durable log, which amounts to insignificant extra solution activity of mere data gathering. See MPEP § 2106.05(g). Regarding claim 7, it further requires a storing data in long term storage, which amounts to insignificant extra solution activity of mere data gathering. See MPEP § 2106.05(g). Regarding claim 8, it further defines the scaling policy; however, the scaling is still recited at a high level of generality and amounts to mere instructions to apply an exception. Regarding claim 9, it further defines the scaling policy; however, the scaling is still recited at a high level of generality and amounts to mere instructions to apply an exception. Regarding claims 10-20, they correspond to claims 1-9. Therefore, they are ineligible for the same reasons. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-21-aia AIA Claim(s) 1-17 and 19 is/ are rejected under 35 U.S.C. 103 as being unpatentable over Kai tchuck (US 2018/0332367) and further in view of Calder (US 9,372,735). Reg arding claim 1, Kaitchuck teaches: A method for managing a data stream processing pipeline, the method comprising: monitoring, by an orchestrator, data stream ingestion of a streaming storage system (SSS) to obtain data stream metrics (¶ 43, “the current disclosure may enable monitoring a rate of data input to the Stream and uses the SLO to add or remove Stream Segments from a Stream” and ¶ 75, “a set of Controller instances may make up a control plane, which may provide functionality to . . . monitor the health of a Pravega cluster, gather metrics etc”) ; analyzing, by the orchestrator, the data stream metrics based on a user-defined scaling policy (¶ 104, “there may be one or more of the following Scaling Policies. (1) Fixed—The number of Stream Segments may not vary with load. (2) Size-based—As the number of bytes of data per second written to the Stream increases past a certain target rate, the number of Stream Segments may be increased”) ; making, based on the analyzing and by the orchestrator, a first determination that task manager scaling is required (¶ 28, “the amount of stream segments can be scaled up and down depending on the amount of data ingested from writers”) , wherein a stream processing system (SPS) comprises a plurality of task managers (¶ 112, “this may enable a Flink application to increase or decrease the number of task instances that are processing a Stream in parallel, as scale events occur over time”) , wherein the SSS and the SPS communicate over a network and form the data stream processing pipeline (¶ 27, “the stream can be combined with stream processing engines such as Apache Flink to build streaming applications”) ; in response to the first determination and by the orchestrator, making a second determination that the data stream ingestion is increased (¶ 104, “As the number of bytes of data per second written to the Stream increases past a certain target rate”) , wherein the second determination indicates an increase in a number of parallel stream segments associated with a data stream (¶ 104, “the number of Stream Segments may be increased”) , wherein a segment store hosted by the SSS manages the parallel stream segments (¶ 131, “The Pravega Server or Pravega Node is a server-side component that implements read, write and other data plane operations”) ; and in response to the second determination and to increase the SPS’ compute capability, initiating, by the orchestrator, scaling of a number of the plurality of task managers to support the increase in the number of the parallel stream segments (¶ 44, “it may be possible to coordinate the auto scaling of Streams in Pravega with application scale out” and “scaling may drive the number of instances of a Flink job”) . Kaitchuck does not teach as clearly as Calder teaches: data stream ingestion of a streaming storage system (SSS) to obtain data stream metrics (col. 11:27-32, “This allows for the system as a whole to dynamically adjust the amount of compute resources that are utilized based on a number of metrics, such as a current load of the system and a timely release of unused virtual machines back to the system for other allocations”) . It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of data stream ingestion of a streaming storage system (SSS) to obtain data stream metrics , as taught by Calder, in the same way to the orchestrator, as taught by Kaitchuck. Both inventions are in the field of autoscaling a pool of resources, and combining them would have predictably resulted in “effective provisioning of resources in a distributed computing environment,” as indicated by Calder (col. 24:64-65). Regarding claim 2, Kaitchuck teaches: The method of claim 1, wherein the data stream metrics specify at least one selected from a group consisting of a number of elastic data streams, the number of the parallel stream segments (¶ 100, “a number of Stream Segments in a Stream may grow and shrink over time as I/O load on the Stream increases and decreases, which may be referred to herein as AutoScalin”) , a type of data that is part of the data stream (¶ 88, “an Event may be as simple as a small number of bytes containing a temperature reading from an IoT sensor composed of a timestamp, a metric identifier and a value”) , a number of each type of the data, a size of each type of the data (¶ 104, “Size-based—As the number of bytes of data per second written to the Stream increases past a certain target rate”) , a cost of executing the parallel stream segments (¶ 140, “Tier 2 Storage may provide a highly-scalable, high-throughput cost-effective storage”) , a type of an operating system used by the SSS, and a resource utilization value of a resource associated with the segment store. Regarding claim 3, Kaitchuck teaches: The method of claim 2, wherein the resource is a central processing unit (CPU), a graphics processing unit (GPU), a data processing unit (DPU), memory (¶ 139, “Tier 1 Storage may be implemented on faster SSDs or even non-volatile RAM”) , a network resource (¶ 51, “writes may be optimized so that I/O throughput may be limited by network bandwidth rather than a persistence mechanism being the bottle neck”) , storage space (¶ 134, “Each Stream Segment is stored in a combination of Tier1 and Tier2 storage”) , or storage input/output (I/O) (¶ 135, “events may be persisted in low latency/high IOPS storage”) . Regarding claim 4, Kaitchuck teaches: The method of claim 1, wherein the user-defined scaling policy specifies a one-to-one relationship between the number of the parallel stream segments and the number of the plurality of task managers (¶ 42, “In certain implementations, if a Stream has N Stream Segments, then a ReaderGroup with N Readers may consume from the Stream in parallel. In most implementations, increasing the number of Stream Segments may increase a number of Readers in a ReaderGroup to increase the scale of processing the data from that Stream”) , wherein a task manager of the plurality of task managers provides a computer-implemented service to the user by processing at least a portion of the data stream ingested by the SSS (¶ 95, “a collection of Flink tasks processing Stream data in parallel may be an example use of a ReaderGrou”) . Regarding claim 5, Kaitchuck teaches: The method of claim 4, wherein the data stream is a continuous, unbounded, append-only, and durable sequence of bytes (¶ 27, “A stream is ideally suited to the continuous processing of unbounded data. In many implementations, a stream may be a name, durable, append-only and unbounded sequence of bytes”) , and wherein a controller of the SSS manages the data stream (¶ 75, “a set of Controller instances may make up a control plane”) . Regarding claim 6, Kaitchuck teaches: The method of claim 5, wherein the SSS comprises a durable log (¶ 51, “Apache BookKeeper may be used to persist all write operations. In some implementations, BookKeeper may persist and protect the data very efficiently”) , wherein the durable log is a distributed write-ahead log providing short-term, durable, and low-latency data protection of the portion of the data stream (¶ 139, “Tier 1 Storage may be used to make writing to Streams fast and durable and to make sure reading from the tail of a Stream is as fast as possible. In certain embodiments, Tier 1 Storage may be implemented on faster SSDs or even non-volatile RAM”) . Regarding claim 7, Kaitchuck teaches: The method of claim 6, wherein the SSS stores the portion of the data stream to a long-term storage (¶ 76, “Tier 2 Storage providing longer term storage of Stream data”) , wherein the long-term storage is a pluggable object storage providing long-term and durable data protection of the portion of the data stream (¶ 140, “In some embodiments, Tier 2 may be deployed on spinning disks”) . Regarding claim 8, Kaitchuck teaches: The method of claim 1, wherein the data stream metrics are analyzed by applying a reactive auto-scaling model (¶ 100, “AutoScaling may refer to a number of Stream Segments that vary over time. In some implementations, a number of Stream Segments in a Stream may grow and shrink over time as I/O load on the Stream increases and decreases”) or a proactive auto-scaling model to the data stream processing pipeline. Regarding claim 9, Kaitchuck teaches: The method of claim 1, wherein the user-defined scaling policy specifies generation of an additional task manager in the SPS when a number of events per second written in a stream segment managed by the segment store exceeds a predetermined threshold value (¶ 104, “As the number of bytes of data per second written to the Stream increases past a certain target rate, the number of Stream Segments may be increased”) . Claims 10-17 and 19 recite commensurate subject matter as claims 1-5 and 9. Therefore, they are rejected for the same reasons . 07-21-aia AIA Claim (s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kaitchuck and Calder, as applied above, and further in view of Shi (US 10,097,595) . Regarding claim 18, Kaitchuck and Calder teaches: a task manager of the plurality of task managers provides a computer-implemented service to the user by processing at least a portion of the data stream ingested by the SSS (¶ 95, “a collection of Flink tasks processing Stream data in parallel may be an example use of a ReaderGroup”) . Kaitchuck and Calder do not teach; however, Shi discloses: a one-to-four relationship between the number of the parallel stream segments and the number of the plurality of task managers (col. 12:37-42, “A parallelism degree of n1 is 1, and n1 is executed by one PE, that is, n1 is executed by pe1; a parallelism degree of n2 is 2, and n2 is executed by two PEs, that is, n2 is executed by pe2 and pe3; a parallelism degree of n3 is 3, and n3 is executed by three PEs, that is, n3 is executed by pe4, pe5, and pe6”) . It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the first user-defined scaling policy is specifies a one-to-four relationship between the number of the parallel stream segments and the number of the plurality of task managers , as taught by Shi, in the same way to the first user-defined scaling policy, as taught by Kaitchuck and Calder. Both inventions are in the field of stream processing, and combining them would have predictably resulted in “adjusting a parallelism degree of the working node according to the optimized parallelism degree of the working node,” as indicated by Shi (abstract) . 07-21-aia AIA Claim (s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kaitchuck and Calder, as applied above, and further in view of Das (US 2016/0321588) . Regarding claim 20, Kaitchuck and Calder do not teach; however, Das discloses: generation of an additional segment store in the SSS when a percentile of the end-to-end write latency exceeds the predetermined write latency threshold (¶ 40, “The latency goals enable the auto-scaling logic to provide resources sufficient to achieve the latency goals, thus reducing costs when resource demands require a larger container size but the latency goals can be achieved using a smaller container size. For instance, an application involving interactive user activity may specify a 95.sup.th percentile latency of one hundred milliseconds (ms)”) . It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of generation of an additional segment store in the SSS when a percentile of the end-to-end write latency exceeds the predetermined write latency threshold , as taught by Das, in the same way to the first user-defined scaling policy, as taught by Kaitchuck and Calder. Both inventions are in the field of stream processing, and combining them would have predictably resulted in “improv[ing] accuracy of resource demand estimation,” as indicated by Das (¶ 7) . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Mitkar (US 12,032,855) teaches “an approach that scales data protection resources to the corresponding needs of data that is present in an application orchestrator computing environment” (col. 1:58-61), which relates to the disclosed task manager scaling. Gracia-Tinedo (US 2026/0111272) teaches a “method for managing a data stream processing pipeline includes: monitoring data stream ingestion of a system and a computing resource utilization value (CRUV) of each of a first serverless function (SF), a second SF, and a third SF to obtain a set of metrics; analyzing the set of metrics based on a policy” (abstract), which relates to the disclosed task manager scaling. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00. 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, Pierre Vital can be reached at (571) 272-4215. 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. /JACOB D DASCOMB/ Primary Examiner, Art Unit 2198 Application/Control Number: 18/418,710 Page 2 Art Unit: 2198 Application/Control Number: 18/418,710 Page 3 Art Unit: 2198 Application/Control Number: 18/418,710 Page 4 Art Unit: 2198 Application/Control Number: 18/418,710 Page 5 Art Unit: 2198 Application/Control Number: 18/418,710 Page 6 Art Unit: 2198 Application/Control Number: 18/418,710 Page 7 Art Unit: 2198 Application/Control Number: 18/418,710 Page 8 Art Unit: 2198 Application/Control Number: 18/418,710 Page 9 Art Unit: 2198 Application/Control Number: 18/418,710 Page 10 Art Unit: 2198 Application/Control Number: 18/418,710 Page 11 Art Unit: 2198 Application/Control Number: 18/418,710 Page 12 Art Unit: 2198 Application/Control Number: 18/418,710 Page 13 Art Unit: 2198
Prosecution Insights