DETAILED ACTION
This office action is in response to claims filed 5 April 2024.
Claims 1-15 are cancelled. Claims 16-34 are pending.
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 .
Claim Objections
Claim 19 is objected to because of the following informalities: “the calculator includes a calculator…subsequent stage of the calculator” should read “the calculator includes a first calculator…subsequent stage of the first calculator”. Appropriate correction is required.
Claim 21 is objected to because of the following informalities: “configured to measures” should read “configured to measure”. Appropriate correction is required.
Claim 22 is objected to because of the following informalities: “configured to measures” should read “configured to measure”. Appropriate correction is required.
Claim 28 is objected to because of the following informalities: “the data flow rate” should read “a data flow rate”. Appropriate correction is required.
Claim 28 is objected to because of the following informalities: “the trouble” should read “the event”. Appropriate correction is required.
Claim 29 is objected to because of the following informalities: “the data flow rate” should read “a data flow rate”. Appropriate correction is required.
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 21 is 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.
Regarding claim 21,
In line 2: The claim fails to particularly point out and distinctly claim what is meant by “the events”. There is a lack of antecedent basis for this term. For examination purposes, the examiner will interpret this as a first event.
Claim Rejections - 35 USC § 101
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 18-22, and 24-27, and 29-34 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (mental process) without significantly more.
Examiner notes that claim 16 was not rejected under 35 U.S.C. 101, because it does not recite a judicial exception. However, there are claims that are dependent upon claim 16 which do recite judicial exceptions, and therefore, these dependent claims stand rejected under 35 U.S.C. 101.
Regarding claim 18, in step 1 of the 101 analysis set forth in MPEP 2106, the claim recites a system that records trace data when an event is detected. A system is one of the four statutory categories of invention.
In step 2A, prong 1 of the 101 analysis set forth in the MPEP 2106, the examiner has determined that the following limitations recite a process that, under the broadest reasonable interpretation, covers a mental process but for recitation of generic computer components:
i. In claim 18, “counts time based on an operating frequency of the calculator” (a person can mentally count time by simply evaluating a calculator operating frequency and making a determination or judgement of the time (MPEP 2106.04(a))).
ii. In claim 18, “detect the event” (a person can mentally detect an event by simply making an observation that a given event has occurred (MPEP 2106.04(a))).
If claim limitations, under their broadest reasonable interpretation, covers performance of the limitations as a mental process 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.
In step 2A, prong 2 of the 101 analysis set forth in MPEP 2106, the examiner has determined that the following additional elements do not integrate this judicial exception into a practical application:
iii. In claim 16, “a plurality of calculators;” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
iv. In claim 16, “a host connected to the plurality of calculators, the host configured to control the plurality of calculators” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
v. In claim 16, “processed data is transferred between the plurality of calculators” (insignificant extra-solution activity of mere data input/output (MPEP 2106.05(g))).
vi. In claim 16, “the calculator includes a tracer configured to record trace data upon detection of a predetermined event from input data” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
vii. In claim 16, “the trace data has a timestamp value that is a detection time of the event” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
viii. In claim 18, “the tracer includes: a timestamper that includes at least one clock counter” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
ix. In claim 18, “an event generator that is inserted into an arbitrary location of the calculator” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
x. In claim 18, “acquire the timestamp value when the event is detected” (insignificant extra-solution activity of mere data gathering (MPEP 2106.05(g))).
xi. In claim 18, “at least one trace buffer that records the trace data when the event is detected” (insignificant extra-solution activity of mere data storage (MPEP 2106.05(g))).
Since the claim does not contain any other additional elements that are indicative of integration into a practical application, the claim is “directed” to an abstract idea.
In step 2B of the 101 analysis set forth in the 2019 PEG, the examiner has determined through reanalysis of the following limitations considered in step 2A prong 2, that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
iii. In claim 16, “a plurality of calculators;” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
iv. In claim 16, “a host connected to the plurality of calculators, the host configured to control the plurality of calculators” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
v. In claim 16, “processed data is transferred between the plurality of calculators” (well-understood, routine, and conventional activity of receiving/transmitting data over a network, (MPEP 2106.05(d)(II)) (MPEP 2106.05(g))).
vi. In claim 16, “the calculator includes a tracer configured to record trace data upon detection of a predetermined event from input data” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
vii. In claim 16, “the trace data has a timestamp value that is a detection time of the event” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
viii. In claim 18, “the tracer includes: a timestamper that includes at least one clock counter” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
ix. In claim 18, “an event generator that is inserted into an arbitrary location of the calculator” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
x. In claim 18, “acquire the timestamp value when the event is detected” (well-understood, routine, and conventional activity of receiving data over a network, (MPEP 2106.05(d)(II)) (MPEP 2106.05(g))).
xi. In claim 18, “at least one trace buffer that records the trace data when the event is detected” (well-understood, routine, and conventional activity of storing information in memory, (MPEP 2106.05(d)(II))).
Considering the additional elements individually and in combination, and the claim as a whole, the additional elements do not provide significantly more than the abstract idea. Therefore, the claim is not patent eligible.
Regarding claim 19, the additional element “the calculator includes a calculator, and the event generator is inserted to a preceding stage or a subsequent stage of the calculator” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 20, the additional element “the calculator includes a plurality of calculators” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)). Further, the additional element “the event generator at a preceding stage or a subsequent stage of one of the plurality of calculators is deleted, and the one calculator is deleted” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally create or delete calculators by simply making a judgement that calculators should be added or removed (MPEP 2106.04(a)))
Regarding claim 21, the additional element “one event generator configured to…acquires one of the timestamp values when the one of the events is detected; and another event generator configured to…acquires the other timestamp value when the other event is detected” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra solution activity of mere data gathering (MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of receiving data over a network (MPEP 2106.05(d)(II))). Further, the additional element “one event generator configured to detect one of the events…and another event generator configured to detect another event…wherein the host or the calculator is configured to measures a difference between the one timestamp value and the other timestamp value” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally detect events and determine a difference between timestamps by simply observing for events, evaluating the timestamps and making a judgement of a difference (MPEP 2106.04(a))).
Regarding claim 22, the additional element “the event generator is configured to detect a beginning and an end of the input data” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally detect a beginning or end of input data by simply observing the input data and making a determination or judgement of a beginning or end (MPEP 2106.04(a))). Further, the additional element “acquire the timestamp value of the beginning and the timestamp value of the end” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra solution activity of mere data gathering (MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of receiving data over a network (MPEP 2106.05(d)(II))). Further, the additional element “the host or the calculator is configured to measures a data flow rate by dividing an amount of the input data by a difference between the timestamp value of the beginning and the timestamp value of the end” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally determine a data flow rate by simply evaluating input data amount and duration of input, and making a judgement of a rate (MPEP 2106.04(a)). This may also fall under the mathematical algorithm grouping of judicial exceptions for reciting a specific mathematical formula for the calculation of data flow rate).
Regarding claim 24, the additional element “a plurality of the hosts are provided” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 25, it comprises limitations similar to those of the combination of claims 16 and 18, and is therefore rejected for similar rationale.
Regarding claim 26, it comprises limitations similar to claim 21, and is therefore rejected for similar rationale.
Regarding claim 27, it comprises limitations similar to claim 22 and is therefore rejected for similar rationale.
Regarding claim 29, the additional element “comparing, by the host or the calculator, the measured value of either the processing time or the data flow rate with a predetermined threshold” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally compare values by simply evaluating the values and making a judgement based on a threshold (MPEP 2106.04(a))). Further, the additional element “notifying, by the host or the calculator, detection of an abnormality in the computer system when the measured value exceeds the predetermined threshold” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra solution activity of mere data output (MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of transmitting data over a network (MPEP 2106.05(d)(II))).
Regarding claim 30, the additional element “recording, by trace buffer, information indicating a location where the event is detected” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra solution activity of mere data storage (MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of storing data in memory (MPEP 2106.05(d)(II))). Further, the additional element “comparing, by the host or the calculator, the data flow rate with a predetermined threshold; and setting, by the host or the calculator, a path through which the data passes so as to avoid concentration of the data when the data flow rate exceeds the threshold” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally compare values and set paths by simply evaluating the values and making a judgement based on a threshold and making another judgement as to a particular path (MPEP 2106.04(a))).
Regarding claim 31, it comprises limitations similar to those of the combination of claims 16 and 18, and is therefore rejected for similar rationale.
Regarding claim 32, the additional element “detect the event based on the passing of the beginning or end of a data stream” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally detect events by simply observing for them (MPEP 2106.04(a))).
Regarding claim 33, the additional element “managing operation parameters including information for specifying an algorithm when switching between a plurality of algorithms in data processing” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 34, it comprises limitations similar to those of claim 20, and is therefore rejected for similar rationale.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 16, and 17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by WILLIAMS et al. Pub. No.: US 2011/0219376 A1 (hereafter WILLIAMS).
Regarding claim 16, WILLIAMS teaches:
A computer system, comprising:
a plurality of calculators; and a host connected to the plurality of calculators ([0063] FIG. 1 schematically illustrates a data processing apparatus 1 (i.e., “host”). The data processing apparatus 1 comprises processing circuitry including at least one processor 4 (i.e., “plural calculators”). In the example of FIG. 1, there are two processors: a first processor 4-1, and a second processor 4-2), the host configured to control the plurality of calculators ([0064] The data processing apparatus 1 also comprises a register bank 6 for storing values used during processing and a memory 8 for storing data and instructions for use by the processor 4. The processor 4, the register bank 6 and the memory 8 are connected via a bus 10 (i.e., data processing apparatus controls processors using instructions stored in memory)), wherein
processed data is transferred between the plurality of calculators ([0075] In a symmetric multi-processor (SMP) system, threads can migrate between processors in order to improve thread throughput of the multi-processor system (i.e., threads, representing “processed data” are transferred between processors during migration)),
the calculator includes a tracer ([0066] Where more than one trace module 12 (i.e., “tracer”) is provided, each trace module may have a different function. For example, in the arrangement shown in FIG. 1, the trace module 12-1 could monitor threads executed by the processor 4-1, while the trace module 12-2 monitors threads executed by the processor 4-2 (i.e., each processor has, included with it, a separate trace module)) configured to record trace data upon detection of a predetermined event from input data ([0070] While tracing, at step 24 the trace module 12 determines whether a predetermined event has occurred. A predetermined event is any of one or more types of event whose occurrence triggers a request for generation of a timestamp), and
the trace data has a timestamp value that is a detection time of the event ([0072] When it is determined at step 30 that the next trace packet is to be generated, the method proceeds to step 32 where the trace module determines whether the timestamp request flag 18 has been set to indicate a pending timestamp request. If the timestamp request flag indicates a pending timestamp request, then at step 34 a timestamp is generated (i.e., timestamp is generated to indicate the time that the predetermined event has occurred)).
Regarding claim 17, WILLIAMS further teaches:
the trace data further includes a type of the input data, information indicating a location where the event is detected, information distinguishing the content of the event, or arbitrary data ([0070] While tracing, at step 24 the trace module 12 determines whether a predetermined event has occurred. A predetermined event is any of one or more types of event whose occurrence triggers a request for generation of a timestamp (i.e., tracing input indicates a “type” of event)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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 18, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS as applied to claim 16 above, and in further view of AGARDH WO 2017/108469 A1 (hereafter AGARDH).
Regarding claim 18, while WILLIAMS further teaches:
the tracer includes:
a timestamper that includes at least one clock counter ([0095] One or more trace modules within a single processor cluster may use a local timing scheme generated by a local clock)…
an event generator that is inserted into an arbitrary location of the calculator to detect the event ([0070] While tracing, at step 24 the trace module 12 determines whether a predetermined event has occurred. A predetermined event is any of one or more types of event whose occurrence triggers a request for generation of a timestamp. The trace module 12 may determine whether the predetermined event has occurred in various different ways. If the trace module 12 has visibility of the instructions processed by the processor 4, then the trace module 12 can itself determine the points at which a predetermined event has occurred by monitoring the executed instructions For example, a program flow trace module has such capability (i.e., the program flow trace monitor inserts triggers, or “event generators” into the instructions of the processor)) and acquire the timestamp value when the event is detected ([0072] The method proceeds to step 32 where the trace module determines whether the timestamp request flag 18 has been set to indicate a pending timestamp request. If the timestamp request flag indicates a pending timestamp request, then at step 34 a timestamp is generated)); and
at least one trace buffer that records the trace data when the event is detected ([0065] The trace module 12 generates trace data and outputs the trace data to a trace buffer 14, where the data may be stored on-chip or output off-chip).
While WILLIAMS discusses a clock used to generate timestamps for events, WILLIAMS does not explicitly teach that the clock:
counts time based on an operating frequency of the calculator;
However, in analogous art that similarly discloses a clock to generate timestamps of events, AGARDH teaches that the clock:
counts time based on an operating frequency of the calculator ([Page 5, Lines 17-22] Events of the event log may be associated with timestamps of a local timing reference; such associations may be achieved by tagging the events with timestamps of a local timing reference and / or using a communication protocol for providing the event log which is time calibrated. E.g., the timestamps may be derived from CPU clock cycles based on e.g., a CPU clock frequency of the processor 1 1 1);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined AGARDH’s teaching of deriving timestamps for events based on CPU clock frequency, with WILLIAMS’s teaching of deriving timestamps for events, to realize, with a reasonable expectation of success, a system that derives timestamps for events, as in WILLIAM, based on CPU clock frequency, as in AGARDH. A person having ordinary skill would have been motivated to make this combination to ensure timestamps are synchronized with a local timing reference, thereby improving accuracy and consistency of timestamps.
Regarding claims 25, and 31, they comprise limitations similar to those of claims 16 and 18, and are therefore rejected for similar rationale.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS in view of AGARDH, as applied to claim 18 above, and in further view of CROSETTO et al. Pub. No.: US 2013/0159977 A1 (hereafter CROSETTO).
Regarding claim 19, while WILLIAMS and AGARDH discuss inserting event generators within instructions of a calculator, they do not explicitly teach:
the calculator includes a calculator, and the event generator is inserted to a preceding stage or a subsequent stage of the calculator.
However, in analogous art that similarly discusses event detection, CROSETTO teaches:
the calculator includes a calculator, and the event generator is inserted to a preceding stage or a subsequent stage of the calculator ([Claim 15] A probe injection component that injects one or more software probes dynamically at run time into the operating system kernel (i.e., executing on a processor, or “calculator”) to add new trace code that will execute upon execution of software code at an injection point; an event detection component that detects execution of software at a probe injection point where a software probe has been inserted to collect trace information (i.e., injection point represents a future, or “subsequent stage” during which an event will be detected)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined CROSETTO’s teaching of inserting tracing probes at subsequent injection points during execution of an operating system calculator, with the combination of WILLIAMS and AGARDH’s teaching of tracing execution of instructions by a calculator to identify events, to realize, with a reasonable expectation of success, a system that traces execution of instructions, as in WILLIAMS and AGARDH, by inserting tracing probes at subsequent injection points during execution of the instructions, as in CROSETTO. A person having ordinary skill would have been motivated to make this combination to extract more trace information to gain a better understanding of software behavior (CROSETTO [0005]).
Claims 20, and 34 is rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS in view of AGARDH, as applied to claim 18 and 31 above, and in further view of FERRIS Pub. No.: US 2009/0293056 A1 (hereafter FERRIS).
Regarding claim 20, while WILLIAMS and AGARDH discusses performing event monitoring, they do not explicitly teach:
the calculator includes a plurality of calculators, and the event generator at a preceding stage or a subsequent stage of one of the plurality of calculators is deleted, and the one calculator is deleted.
However, in analogous art that similarly discusses event monitoring, FERRIS teaches:
the calculator includes a plurality of calculators, and the event generator at a preceding stage or a subsequent stage of one of the plurality of calculators is deleted, and the one calculator is deleted ([0043] In embodiments, the self-management module 118 can be configured to suspend or terminate the particular virtual machine 116 (i.e., “calculator”) with which it is associated. The self-management module 118 can be configured to suspend or terminate the virtual machine 116 upon the occurrence of a particular event or based on the monitoring of the virtual machine 116, such as a error in the virtual machine 116 (i.e., self-management module monitors for events, and therefore represents an “event generator”). [0051] In 508, the cloud management system 104 can instantiate virtual machines (i.e., “plural calculators”) as requested by the user. Once instantiated, in 510, the self-management module can begin performing the management process of the virtual machine. The management functions can include activation, suspension, or termination of the virtual machine 116, monitoring of the status and usage of the virtual machine 116, and messaging regarding the status and usage of the virtual machine 116. In 512, the self management module can continue the management functions until the virtual machine is terminated (i.e., terminating, or “deleting” the virtual machine “calculator” terminates, or “deletes” the self-management module)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined FERRIS’s teaching of deleting self-management event generators when virtual machine calculators are deleted, with the combination of WILLIAMS and AGARDH’s teaching of monitoring events of calculators, to realize, with a reasonable expectation of success, a system that monitors events of calculators, as in WILLIAMS and AGARDH, and deletes the event monitor when the calculator is deleted, as in FERRIS. A person having ordinary skill would have been motivated to make this combination to better manage consumption of resources allocated to virtual machines (FERRIS [0003]).
Regarding claim 34, it comprises similar limitations to claim 20, and is therefore rejected for similar rationale.
Claims 21, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS in view of AGARDH, as applied to claims 18, and 25 above, and in further view of KRAFT Pub. No.: US 2020/0012791 A1 (hereafter KRAFT).
Regarding claim 21, while WILLIAMS and AGARDH discuss event monitoring, they do not explicitly teach:
one event generator configured to detect one of the events and acquires one of the timestamp values when the one of the events is detected; and
another event generator configured to detect another event and acquires the other timestamp value when the other event is detected, wherein
the host or the calculator is configured to measures a difference between the one timestamp value and the other timestamp value.
However, in analogous art that similarly discusses event monitoring, KRAFT teaches:
one event generator configured to detect one of the events and acquires one of the timestamp values when the one of the events is detected; and another event generator configured to detect another event and acquires the other timestamp value when the other event is detected, wherein the host or the calculator is configured to measures a difference between the one timestamp value and the other timestamp value ([0047] Obtaining 200 comprises a step 202 of detecting and/or recording a first set of events. The first set of events are detected and/or recorded during a defined period of time, which may e.g. be a predefined test period where the program behavior is verified using existing test procedures. The purpose of the step 202 is to create a list or log of all events that occurred during the defined time period. It may be possible that events that are detected during the detecting step 202 are undesired events, such as failed memory allocations. [0048] After the detecting step 202 has been performed for a sufficient amount of time, a number of different events will have been detected. [0065] in some embodiments, the events detected during the detecting step 202 may comprise timestamp information which identifies a time when the event occurred. In embodiments wherein detected events comprise timestamp information, such information may also be used for determining which events are to be considered as anomalies. By using the timestamp information of events, the time elapsed between events may be determined, and used as a basis for determining whether an event is to be considered an anomaly).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined KRAFT’s teaching of detecting multiple events and measuring a difference between timestamps, with WILLIAMS and AGARDH’s teaching of measuring timestamps of detected events, to realize, with a reasonable expectation of success, a system that measures timestamps of detected events, as in WILLIAMS and AGARDH, and determines a difference between the events, as in KRAFT. A person having ordinary skill would have been motivated to make this combination to use timestamps to better detect and correct anomalous event behavior (KRAFT [0002]-[0004]).
Regarding claim 26, it comprises similar limitations to claim 21, and is therefore rejected for similar rationale.
Claims 22, and 27 are rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS in view of AGARDH, as applied to claims 18, and 25 above, and in further view of OHUCHI Pub. No.: US 2020/0036635 A1 (hereafter OHUCHI).
Regarding claim 22, while WILLIAMS and AGARDH discuss calculation of time stamps, they do not explicitly teach:
the event generator is configured to detect a beginning and an end of the input data and acquire the timestamp value of the beginning and the timestamp value of the end, and
the host or the calculator is configured to measures a data flow rate by dividing an amount of the input data by a difference between the timestamp value of the beginning and the timestamp value of the end.
However, in analogous art that similarly discusses calculation of time stamps, OHUCHI teaches:
the event generator is configured to detect a beginning and an end of the input data and acquire the timestamp value of the beginning and the timestamp value of the end, and
the host or the calculator is configured to measures a data flow rate by dividing an amount of the input data by a difference between the timestamp value of the beginning and the timestamp value of the end ([0090] The communication data amount difference calculation unit 403 calculates a period of time taken for the communication and the transmission rate, on the basis of the transferred sensor data (i.e., “input data”), the time stamp of the transmission time, and the time stamp of the reception time (step S137). The communication data amount difference calculation unit 403 calculates the difference between the time stamp of the reception time and the time stamp of the transmission time as a period of time taken for the communication. The communication data amount difference calculation unit 403 also calculates the transmission rate from the size of the received data and the calculated communication period (i.e., transmission rate is of the received input data is calculated as the size, or “amount” of data divided by the period between timestamps)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined OHUCHI’s teaching of determining a transmission rate of input data, with the combination of WILLIAMS and AGARDH’s teaching of determining timestamps of input data, to realize, with a reasonable expectation of success, a system that determines timestamps of input data, as in WILLIAMS and AGARDH, and determines a transmission rate from those timestamps, as in OHUCHI. A person having ordinary skill would have been motivated to make this combination to use the determined transmission rate to prevent congestion and improve throughput in a network (OHUCHI [0004]).
Regarding claim 27, it comprises similar limitations to claim 22, and is therefore rejected for similar rationale.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS in view of AGARDH, as applied to claim 18 above, and in further view of WALLACE et al. Patent No.: US 8,589,019 B2 (hereafter WALLACE).
Regarding claim 23, while WILLIAMS and AGARDH discuss recording timestamps for events, they do not explicitly teach:
the trace buffer is configured to record at least the timestamp value and information indicating a location where the event was detected among the trace data, and
when a fault occurs, either the host or the calculator is configured to resume processing using the trace data in any location preceding the location where the fault occurred in the calculator based on the trace data.
However, in analogous art that similarly records timestamps for events, WALLACE teaches:
the trace buffer is configured to record at least the timestamp value and information indicating a location where the event was detected among the trace data, and when a fault occurs, either the host or the calculator is configured to resume processing using the trace data in any location preceding the location where the fault occurred in the calculator based on the trace data ([Column 18, Line 50-Column 19, Line 2] Responding to a fault condition in the processing of the one or more data streams in the primary data processing system; determining a timestamp of a last-processed data element in the one or more data streams that was processed by the primary data processing system prior to the fault condition; and recovering lost data in the one or more data streams caused by the fault condition based on the at least one selected subset of the one or more data streams and the timestamps stored in the secondary data processing system, wherein recovering the lost data comprises: comparing the timestamp of the last-processed data element to the timestamps associated with the at least one selected subset of the one or more data streams, and restarting the processing of the at least one selected subset by the primary data processing system at a timestamp which next follows the timestamp of the last-processed data element (i.e., restarting, or “resuming” processing after an error, or “fault” is determined based on a timestamp of the last-processed data element, indicating a “location” of the fault event)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention, to have combined WALLACE’s teaching of resuming processing at a location of a fault event indicated by a timestamp, with WILLIAMS and AGARDH’s teaching of recording timestamps of events, to realize, with a reasonable expectation of success, a system that records timestamps of events, as in WILLIAMS and AGARDH, and resumes processing based on those timestamps after a fault, as in WALLACE. A person having ordinary skill would have been motivated to make this combination to fully and sufficiently reconstruct gaps in a set of data streams after faults (WALLACE Column 1, Line 66-Column 67, Line 3).
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS, as applied to claim 16 above, and in further view of FERRIS.
Regarding claim 24, while WILLIAMS discusses recording timestamps of events, it does not explicitly teach:
a plurality of the hosts are provided.
However, in analogous art that similarly records timestamps of events, FERRIS teaches:
a plurality of the hosts are provided ([0016] As shown for example in FIG. 1, the collection of resources supporting a cloud 102 can comprise a set of resource servers 108 (i.e., plural “hosts”) configured to deliver computing components needed to instantiate a virtual machine (i.e., “calculators”, of which multiple virtual machines can be hosted by one or more servers, as discussed in [0030]), process, or other resource. For example, one group of resource servers can host and serve an operating system or components thereof to deliver to and instantiate a virtual machine).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined FERRIS’s teaching of providing multiple hosts of multiple calculators, with WILLIAMS’s teaching of a host hosting multiple calculators, to realize, with a reasonable expectation of success, a system that monitors events of calculators, as in WILLIAMS, and hosted by plural hosts, as in FERRIS. A person having ordinary skill would have been motivated to make this combination to better manage consumption of resources allocated to virtual machines from multiple hosts (FERRIS [0003]).
Claims 28 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS in view of AGARDH, in view of KRAFT, as applied to claim 26 above, and in further view of WALLACE.
Regarding claim 28, while WILLIAMS, AGARDH, and KRAFT discuss recording timestamps for events, they do not explicitly teach:
recording, by the trace buffer, arbitrary data;
comparing, by the host or the calculator, a measured value of either the processing time or the data flow rate with a predetermined threshold;
determining, by the host or the calculator, that a fault has occurred when the measured value exceeds the predetermined threshold;
determining, by the host or the calculator, a location where the fault is detected based on information indicating the location where the event is detected; and
resuming processing, by the host or the calculator, using the arbitrary data recorded in the trace buffer of the calculator preceding the location where the trouble was detected.
However, in analogous art that similarly records timestamps for events, WALLACE teaches:
recording, by the trace buffer, arbitrary data ([Column 14, Lines 46-51] In 612, the one or more data streams 110 and/or the sampled subset 114 (i.e., applicant’s specification defines arbitrary data in [0054] as “data that is usually processed by a computer system, such as image data, numerical data, and text data”. Therefore, WALLACE’s data streams, which comprise at least “images” processed by the computing system (see Column 15, Line 65]), represent “arbitrary data”) can be stored, encoded, and/or recorded in the secondary data buffer 106 of the secondary data processing system 126, for example, by storage to electronic random access memory (RAM) and/or other storage or media);
comparing, by the host or the calculator, a measured value of either the processing time or the data flow rate with a predetermined threshold; determining, by the host or the calculator, that a fault has occurred when the measured value exceeds the predetermined threshold; ([Column 14, Lines 58-66] In 618, primary data processing system 108, and/or other device, logic, application, and/or service can experience, register, and/or detect a fault state, fault condition, exception, and/or interruption in the processing of the one or more data streams 110 by the primary data processing system 108. For example, the primary data processing system 108 can experience a system crash or hung state, and after a period of non-responsiveness, the primary data processing system 108 can automatically initiate a reboot process (i.e., a hung state represents a fault where a period of processing inactivity that exceeds a “predetermined threshold” period of time defining the hung state. Alternatively, the period of non-responsiveness may also represent a threshold period of processing time inactivity after which a “fault state” is determined to have occurred, requiring a reboot process))
determining, by the host or the calculator, a location where the fault is detected based on information indicating the location where the event is detected; and resuming processing, by the host or the calculator, using the arbitrary data recorded in the trace buffer of the calculator preceding the location where the trouble was detected ([Column 18, Line 50-Column 19, Line 2] Responding to a fault condition in the processing of the one or more data streams in the primary data processing system; determining a timestamp of a last-processed data element in the one or more data streams that was processed by the primary data processing system prior to the fault condition; and recovering lost data in the one or more data streams caused by the fault condition based on the at least one selected subset of the one or more data streams and the timestamps stored in the secondary data processing system, wherein recovering the lost data comprises: comparing the timestamp of the last-processed data element to the timestamps associated with the at least one selected subset of the one or more data streams, and restarting the processing of the at least one selected subset by the primary data processing system at a timestamp which next follows the timestamp of the last-processed data element (i.e., restarting, or “resuming” processing after an error, or “fault” is determined based on a timestamp of the last-processed data element, indicating a “location” of the fault event)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined WALLACE’s teaching of resuming processing of data at a location of detected processor fault based on event timestamps, with WILLIAMS, AGARDH, and KRAFT’s teaching of recording event timestamps, to realize, with a reasonable expectation of success, a system that records event timestamps, as in WILLIAMS, AGARDH, and KRAFT, and uses those timestamps to resume processing of data at a location of a detected processor fault, as in WALLACE. A person having ordinary skill would have been motivated to make this combination to fully and sufficiently reconstruct gaps in a set of data streams after faults (WALLACE Column 1, Line 66-Column 67, Line 3).
Regarding claim 29, KRAFT further teaches:
notifying, by the host or the calculator, detection of an abnormality in the computer system ([0006] Detecting a first event from the computer application, and comparing the event code of the first event with the event codes of the event profile. If, or when, the first event does not match any event stored in the event profile (i.e., indicating an “abnormal” event), the method further comprises creating a notification)…
While WILLIAMS, AGARDH, and KRAFT discuss detecting abnormal events, they do not explicitly teach:
comparing, by the host or the calculator, the measured value of either the processing time or the data flow rate with a predetermined threshold; and…[detecting] an abnormality in the computer system when the measured value exceeds the predetermined threshold
However, in analogous art that similarly discusses detection of abnormal events, WALLACE teaches:
comparing, by the host or the calculator, the measured value of either the processing time or the data flow rate with a predetermined threshold; and…[detecting] an abnormality in the computer system when the measured value exceeds the predetermined threshold ([Column 14, Lines 58-66] In 618, primary data processing system 108, and/or other device, logic, application, and/or service can experience, register, and/or detect a fault state, fault condition, exception, and/or interruption in the processing of the one or more data streams 110 by the primary data processing system 108. For example, the primary data processing system 108 can experience a system crash or hung state, and after a period of non-responsiveness, the primary data processing system 108 can automatically initiate a reboot process (i.e., a hung state represents a fault where a period of processing inactivity that exceeds a “predetermined threshold” period of time defining the hung state. Alternatively, the period of non-responsiveness may also represent a threshold period of processing time inactivity after which a “fault state” is determined to have occurred, requiring a reboot process))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined WALLACE’s teaching of resuming processing of data at a location of detected processor fault based on event timestamps, with WILLIAMS, AGARDH, and KRAFT’s teaching of recording abnormal event timestamps, to realize, with a reasonable expectation of success, a system that records event timestamps, as in WILLIAMS, AGARDH, and KRAFT, and uses those timestamps to resume processing of data at a location of a detected processor fault, as in WALLACE. A person having ordinary skill would have been motivated to make this combination to fully and sufficiently reconstruct gaps in a set of data streams after faults (WALLACE Column 1, Line 66-Column 67, Line 3).
Claim 30 is rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS in view of AGARDH, in view of OHICHI, as applied to claim 27 above, and in further view of WALLACE, in view of KURITA Pub. No.: US 2015/0281100 A1 (hereafter KURITA).
Regarding claim 30, while WILLIAMS, AGARDH, and OHICHI discuss event detection, they do not explicitly teach:
recording, by trace buffer, information indicating a location where the event is detected;
However, in analogous art that similarly discusses event detection, WALLACE teaches:
recording, by trace buffer, information indicating a location where the event is detected ([Column 18, Line 50-Column 19, Line 2] Responding to a fault condition in the processing of the one or more data streams in the primary data processing system; determining a timestamp of a last-processed data element in the one or more data streams that was processed by the primary data processing system prior to the fault condition; and recovering lost data in the one or more data streams caused by the fault condition based on the at least one selected subset of the one or more data streams and the timestamps stored in the secondary data processing system, wherein recovering the lost data comprises: comparing the timestamp of the last-processed data element to the timestamps associated with the at least one selected subset of the one or more data streams, and restarting the processing of the at least one selected subset by the primary data processing system at a timestamp which next follows the timestamp of the last-processed data element (i.e., restarting, or “resuming” processing after an error, or “fault” is determined based on a timestamp of the last-processed data element, indicating a “location” of the fault event));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined WALLACE’s teaching of resuming processing of data at a location of detected processor fault based on event timestamps, with WILLIAMS, AGARDH, and OHUCHI’s teaching of recording event timestamps, to realize, with a reasonable expectation of success, a system that records event timestamps, as in WILLIAMS, AGARDH, and OHUCHI, and uses those timestamps to resume processing of data at a location of a detected processor fault, as in WALLACE. A person having ordinary skill would have been motivated to make this combination to fully and sufficiently reconstruct gaps in a set of data streams after faults (WALLACE Column 1, Line 66-Column 67, Line 3).
While WILLIAMS, AGARDH, OHUCHI, and WALLACE discuss detection of events in a data flow, they do not explicitly teach:
comparing, by the host or the calculator, the data flow rate with a predetermined threshold; and
setting, by the host or the calculator, a path through which the data passes so as to avoid concentration of the data when the data flow rate exceeds the threshold.
However, in analogous art that similarly discusses detection of events, KURITA teaches:
comparing, by the host or the calculator, the data flow rate with a predetermined threshold; and setting, by the host or the calculator, a path through which the data passes so as to avoid concentration of the data when the data flow rate exceeds the threshold ([0159] The calculating unit 73 uses the reporting packets to calculate the transfer rates of the flows (step S22). Moreover, the calculating unit 73 uses the calculation results of the transferred flows and the topology information 91 to calculate utilization rates of the links (step S23). The calculating unit 73 determines whether a link having a link utilization rate equal to or greater than the threshold Th3 exists (step S24). When a link in which the link utilization rate exceeds the threshold Th3 exists (step S24: Yes), the selecting unit 82 specifies a flow that is transferred using that link (step S25). The selecting unit 82 determines a path that is to be changed to avoid congestion (step S26) (i.e., avoiding congestion avoids the “concentration of data” that causes the utilization rate to exceed the threshold)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined KURITA’s teaching of avoiding determined data congestion links, with the combination of WILLIAMS, AGARDH, OHUCHI, and WALLACE’s teaching of detecting events, to realize, with a reasonable expectation of success, a system that detects events, as in WILLIAMS, AGARDH, OHUCHI, and WALLACE, and avoids detected network congestion, as in KURITA. A person having ordinary skill would have been motivated to make this combination to avoid network congestion and improve network throughput.
Claim 32 is rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS in view of AGARDH, as applied to claim 31 above, and in further view of MEHTA et al. Pub. No.: US 2019/0312921 A1 (hereafter MEHTA).
Regarding claim 32, while WILLIAMS and AGARDH discuss detection of data stream events, they do not explicitly teach:
detect the event based on the passing of the beginning or end of a data stream.
However, in analogous art that similarly discusses detection of data stream events, MEHTA teaches:
detect the event based on the passing of the beginning or end of a data stream ([0128] Determining a clip beginning timestamp can include detecting a beginning condition in the communication stream (e.g., received from a user, triggered by a sensor measurement, etc). [0129] Determining a clip end timestamp can include detecting an ending condition in the communication stream (e.g., received from a user, triggered by a sensor measurement, etc) (i.e., events indicating beginning and ending of a communication stream are detected and associated with timestamps)).
It would have been obvious to a person having ordinary skill to have combined MEHTA’s teaching of detecting an event associated with the beginning or ending of a data stream with the combination of WILLIAMS and AGARDH’s teaching of detecting events associated with data streams, to realize, with a reasonable exception of success, a system that detects events associated with a data stream, as in WILLIAMS and AGARDH, which indicate beginning or ending of the data stream, as in MEHTA. A person having ordinary skill would have been motivated to make this combination to better derive intelligence from data (MEHTA [0003]).
Claim 33 is rejected under 35 U.S.C. 103 as being unpatentable over WILLIAMS in view of AGARDH, as applied to claim 31 above, and in further view of THAPAR Patent No.: US 11,062,046 B1 (hereafter THAPAR).
Regarding claim 33, while WILLIAMS and AGARDH discuss processing of data streams, they do not explicitly teach:
managing operation parameters including information for specifying an algorithm when switching between a plurality of algorithms in data processing.
However, in analogous art that similarly discusses processing a data stream, THAPAR teaches:
managing operation parameters including information for specifying an algorithm when switching between a plurality of algorithms in data processing ([Column 7, Lines 8-22] The first cryptography algorithm is determined. In some examples, an application that is storing the data will indicate or be configured to indicate the cryptography algorithm and key to use to encrypt the data. In another example, the data interface may also determine the cryptography algorithm and key to use via configuration data. As another example, the cryptography algorithm may be selected based on available resources. For example, if the load on a system is high a cheaper to compute cryptography algorithm may be selected. The load on a system may be determined using processor usage, memory usage, I/O latency, network latency, etc. In some embodiments, when the data encrypted for a cheaper to compute cryptography algorithm is written back to a data store, a new cryptography algorithm may be selected based on currently available resources (i.e., different cryptography algorithms are dynamically switched between based on available resources)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined THAPAR’s teaching of dynamically switching between different specified cryptography algorithms to process data of a stream, with the combination of WILLIAMS and AGARDH’s teaching of processing data in a data stream, to realize, with a reasonable expectation of success, a system that processes streams of data, as in WILLIAMS and AGARDH, by dynamically switching between different cryptography algorithms, as in THAPAR. A person having ordinary skill would have been motivated to make this combination to adaptively and optimally utilize resources.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
OZEL et al. Pub. No.: US 2022/0138077 A1 discusses an event circuit that differentiates between different types of events and triggers different actions based on the type of event.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195
Prosecution Insights