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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/19/2024 and 12/23/2025 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Status of the Claims
Claims 1-12 have been examined.
Drawings
The examiner notes that drawings should not contain excessive text; however, reasonable text provided for clarity is permitted. Figure 1-3 provides a flow chart with labeled steps which correspond in the specification to brief text elements that would be appropriate for such figures. While the submitted figures do conform to MPEP § 507, interpretation of the figures could be improved by including the text corresponding to each step. The examiner encourages the applicant to consider adding appropriate text to the stages depicted in Figure 1-3.
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 1-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
101 Analysis - Step 1
Claims 1-12 is/are recite a method/process, therefore claims 1-12 are within at least one of the four statutory categories.
101 Analysis - Step 2A, Prong 1
Regarding Prong 1 of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether they recite subject matter that falls within one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent claim 1 includes limitations that recites mental processes and/or mathematical concepts (emphasized below) and will be used as a representative claim for the remainder of the 101 rejection. Claim 1 recites:
A method for a vacuum pump system, including at least one vacuum pump and at least one cloud server, for
determining a service event of the at least one vacuum pump with the steps:
acquiring one or more pump parameters from the vacuum pump by a control unit of the vacuum pump;
transmitting, by the control unit, the one or more pump parameters to the cloud server; and
determining, by the cloud server, one or more service events for the vacuum pump on the basis of the one or more pump parameters, wherein determining the service event is performed by a look-up table stored in the cloud server comprising a correspondence between the one or more pump parameters and the service event.
These limitations, as drafted, is a system that, under its broadest reasonable interpretation, covers performance of the limitation as a mental process and/or mathematical concept. That is, nothing in the claim elements preclude the steps from practically being performed as mathematical concepts. For example, " determining a service event …" and " acquiring one or more pump parameters from the vacuum...", and “transmitting, by the control unit, the one or more pump parameters …” and “determining, by the cloud server, one or more service events for the vacuum pump …” encompass subject matter that collecting data, transmitting data over a network to cloud server, and querying a standard look-up table to output a classification falls directly into the abstract idea. Thus, the claim recites at least a mathematical concept and/or certain methods of organizing human activity and/or data processing.
101 Analysis - Step 2A, Prong 2
Regarding Prong 2 of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract idea into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a "practical application."
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the "additional limitations" while the bolded portions continue to represent the "abstract idea"):
A method for a vacuum pump system, including at least one vacuum pump and at least one cloud server, for
determining a service event of the at least one vacuum pump with the steps:
acquiring one or more pump parameters from the vacuum pump by a control unit of the vacuum pump;
transmitting, by the control unit, the one or more pump parameters to the cloud server; and
determining, by the cloud server, one or more service events for the vacuum pump on the basis of the one or more pump parameters, wherein determining the service event is performed by a look-up table stored in the cloud server comprising a correspondence between the one or more pump parameters and the service event.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application.
Regarding the additional limitations of "vacuum pump…" and “cloud server…” the components are merely generic components to perform a function using computer code. The generic components are recited at a high level of generality (i.e. a generic processor and memory) such that it amounts to no more than mere instructions to apply the exception using generic computer components. The examiner submits that these limitations are merely applying the above-noted abstract idea by merely using a general controller to perform the process (MPEP §2106.05).
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular process for safety performance evaluation, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
101 Analysis - Step 2B
Regarding Step 2B in the 2019 PEG, representative independent claim 12 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of "vacuum pump…" and “cloud server…” amounts to nothing more than applying the exception using a generic computer component. Mere instructions cannot provide an inventive concept. Hence, the claim is not patent eligible.
Dependent claims 2-12 specify limitations that elaborate on the abstract idea of claims 1, and thus are directed to an abstract idea nor do the claims recite additional limitations that integrate the claims into a practical application or amount to “significantly more” for similar reasons.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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 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.
Claim(s) 1, 3-4, 7-12 is/are rejected under 35 U.S.C. 102(a)(1) as being unpatentable over Pal (US20190154469A1).
Claim.1 Pal discloses a method for a vacuum pump system , including a least one vacuum pump and at least one cloud server (see at least fig.1, abstract, A method and system of a predictive maintenance IoT system comprises receiving a plurality of sensor data over a communications network and determining one or more clusters from the sensor data based on a pre-determined rule set, p31, pneumatic conveying system consists of vacuum pump, vacuum receiver, pickup device and tubings. Vacuum pump may be the most critical equipment of the vacuum conveying system, p34, a predictive maintenance IoT system, according to one or more embodiments. The predictive maintenance IoT system 100 includes a machine 106, machine learning engine 104, computer database 110, communications network 102, and a mobile application 108, p66, applying a multi-class classification to classify a sensor data into various classes (such as bad oil, ovelfill oil etc., for vacuum pump)), for determining a service event of the at least one vacuum pump with the steps: acquiring one or more pump parameters from the vacuum pump by a control unit of the vacuum pump (see at least fig.1-3, p19-20, a machine learning engine and the sensor data is further base-lined through a combination of database architecture, data training architecture, and a base-lining algorithm, a mobile middleware to receive a plurality of sensor data over a communications network; a clustering module to determine one or more clusters from the sensor data based on a pre-determined rule set; a computer database to store the pre-determined rule set; a machine learning engine to classify the sensor data; and a base-lining architecture to base-line the sensor data, p35-38, The baselining architecture may be a combination of database architecture, data training architecture, and a base-lining algorithm. Further, the system may also include a regression module associated with a computer processor to predict a predictive maintenance state, the sensor data may be determined from a machine wearable sensor placed on a motor, a machine wearable sensor placed on the blower and so on, the communications network 102 may be one of a WiFi, 20, 30, 40, GPRS, EDGE, Bluetooth, ZigBee, Piconet of BLE, Zwave, or a combination thereof, p61, temperature, vibration, power factor and magnetic field data may be used for classification of a machine state such as a bad oil level and/or low oil level); transmitting, by the control unit, the one or more pump parameters to the cloud server (see at least fig.1-2, representation of a data processing system capable of processing a set of instructions to perform any one or more of the methodologies, p34, a system diagram of a predictive maintenance IoT system, according to one or more embodiments. The predictive maintenance IoT system 100 includes a machine 106, machine learning engine 104, computer database 110, communications network 102, and a mobile application 108); and determining, by the cloud server, one or more service events for the vacuum pump on the basis of the one or more pump parameters (see at least fig.1-3, p29, a more complex alarm system may be designed wherein an alarm threshold is not a simple sensor value but a complex hyperplane constructed from a cluster of different kinds of sensor values from different types of sensors (Ex: sensors with different physical parameters such as temperature, pressure, vibration, power factor etc.). Besides, sensor cluster data may consist of several sensors, one single cluster may contain multiple alarm information as multiple hyper-planes can be constructed for different kinds of alarms and/or relevant information related to classification of such cluster data, p31, pneumatic conveying system consists of vacuum pump, vacuum receiver, pickup device and tubings. Vacuum pump may be the most critical equipment of the vacuum conveying system, p35-37, A clustering module may determine one or more clusters from the sensor data based on a pre-determined rule set stored in a computer database 110. A machine learning engine 104 may classify the sensor data. Further, a base-lining architecture may base-line the classified sensor data. The baselining architecture may be a combination of database architecture, data training architecture, and a base-lining algorithm), wherein determining the service event is performed by a look-up table stored in the cloud server comprising a correspondence between the one or more pump parameters and the service event (see at least fig.1-4, p18-19, A method of predictive maintenance through an IoT system comprises receiving a plurality of sensor data over a communications network and determining one or more clusters from the sensor data based on a pre-determined rule set. Further, the sensor data is classified through a machine learning engine and the sensor data is further base-lined through a combination of database architecture, data training architecture, and a base-lining algorithm. A predictive maintenance state is predicted through a regression model and the predictive maintenance state is mapped onto a depiction on a user interface, a mobile middleware to receive a plurality of sensor data over a communications network; a clustering module to determine one or more clusters from the sensor data based on a pre-determined rule set; a computer database to store the pre-determined rule set; a machine learning engine to classify the sensor data; and a base-lining architecture to base-line the sensor data, p39-42, physics based model may include extracting physical parameters from sensor data such as total energy of vibration, multiple axes (X, Y, Z axis) of vibration, azimuthal and polar angle of vibration rotation, RMS (Root Mean Square) value of vibration, shape factor of vibration, the depiction on a user interface may be a fuel gauge type representation as shown in FIG. 4 conveying health monitoring system).
Claim.3 Pal discloses wherein pump parameters of a plurality of vacuum pumps are transmitted to the cloud server (see at least fig.1, p31, pneumatic conveying system consists of vacuum pump, vacuum receiver, pickup device and tubings. Vacuum pump may be the most critical equipment of the vacuum conveying system, p34, a predictive maintenance IoT system, according to one or more embodiments. The predictive maintenance IoT system 100 includes a machine 106, machine learning engine 104, computer database 110, communications network 102, and a mobile application 108, p66, applying a multi-class classification to classify a sensor data into various classes (such as bad oil, ovelfill oil etc., for vacuum pump)).
Claim.4 Pal discloses wherein the cloud server stores a look-up table for each pump model (see at least fig.1, abstract, a predictive maintenance IoT system comprises receiving a plurality of sensor data over a communications network and determining one or more clusters from the sensor data based on a pre-determined rule set, the sensor data is classified through a machine learning engine and the sensor data is further base-lined through a combination of database architecture, data training architecture, and a base-lining algorithm, p19, a clustering module to determine one or more clusters from the sensor data based on a pre-determined rule set; a computer database to store the pre-determined rule set; a machine learning engine to classify the sensor data; and a base-lining architecture to base-line the sensor data. The base-lining architecture is a combination of database architecture, data training architecture and a base-lining algorithm).
Claim.7 Pal discloses wherein the determined one or more service events are displayed on a terminal, preferably via a web interface (see at least fig.2, p52, he computer system 200 may further include a video display unit 210 (e.g., a liquid crystal displays (LCD) and/or a cathode ray tube (CRT)). The computer system 200 also includes an alphanumeric input device 212 (e.g., a keyboard), a cursor control device 214 (e.g., a mouse), a disk drive unit 216, a signal generation device 218 (e.g., a speaker) and a network interface device 220).
Claim.8 Pal discloses wherein the determined one or more service events are transmitted to the control unit of the vacuum pump and preferably displayed by the control unit (see at least fig.1-2, p52, he computer system 200 may further include a video display unit 210 (e.g., a liquid crystal displays (LCD) and/or a cathode ray tube (CRT)). The computer system 200 also includes an alphanumeric input device 212 (e.g., a keyboard), a cursor control device 214 (e.g., a mouse), a disk drive unit 216, a signal generation device 218 (e.g., a speaker) and a network interface device 220).
Claim.9 Pal discloses a vacuum pump comprising a control unit being configured to perform the respective steps of the method according to claim 1 (see at least fig.1-3, abstract, a method and system of a predictive maintenance IoT system comprises receiving a plurality of sensor data over a communications network and determining one or more clusters from the sensor data based on a pre-determined rule set).
Claim.10 Pal discloses a cloud server configured to perform the respective steps of the method according to claim 1 (see at least fig.1-3, abstract, a method and system of a predictive maintenance IoT system comprises receiving a plurality of sensor data over a communications network and determining one or more clusters from the sensor data based on a pre-determined rule set).
Claim.11 Pal discloses a system comprising one or more vacuum pumps, wherein each vacuum pump having a control unit, and a cloud server, wherein the control unit and the cloud server are configured to perform the steps of the method according to claim 1 (see at least fig.1, abstract, A method and system of a predictive maintenance IoT system comprises receiving a plurality of sensor data over a communications network and determining one or more clusters from the sensor data based on a pre-determined rule set, p31, pneumatic conveying system consists of vacuum pump, vacuum receiver, pickup device and tubings. Vacuum pump may be the most critical equipment of the vacuum conveying system, p34, a predictive maintenance IoT system, according to one or more embodiments. The predictive maintenance IoT system 100 includes a machine 106, machine learning engine 104, computer database 110, communications network 102, and a mobile application 108, p66, applying a multi-class classification to classify a sensor data into various classes (such as bad oil, ovelfill oil etc., for vacuum pump)).
Claim.12 Pal discloses a computer program storage device storing instructions which when executed by a processor perform the respective steps of the method according to claim 1 (see at least fig.2, p50, a data processing system capable of processing a set of instructions to perform any one or more of the methodologies, p53, The disk drive unit 216 includes a machine-readable medium 222 on which is stored one or more sets of instructions 224 (e.g., software) embodying any one or more of the methodologies).
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) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pal (US20190154469A1) as applied to claim 1 above, and further in view of Cottrell (US20120016607A1).
Claim.2 Pal does not discloses wherein the pump parameter includes one or more of an oil type, process parameter, maintenance contract information, pump model, pump serial number, customer name, location, alarm register, current frequency, running time, number of restarts.
However, Cottrell discloses wherein the pump parameter includes one or more of an oil type, process parameter, maintenance contract information, pump model, pump serial number, customer name, location, alarm register, current frequency, running time, number of restarts (see at least p4, one or more operating parameters of the one or more operating components, such as pressures, temperatures, flow in, flow out, and energy consumed; comparing the one or more operating parameters with a database of known operating parameters at remote monitoring station, p38, The data may include, for example, flow rates, pressures, temperatures, densities, and viscosities of certain pieces of equipment and/or processes of an operation. For example, in one embodiment, the data may include a flow rate or temperature of a fluid flowing though a pump, p46, a parameter of the equipment, such as a pump rate, adjusting a parameter of a system, such as a power signal, or adjusting other aspects of systems and/or equipment that may be monitored according to the embodiments disclosed herein).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to modify Pal to include wherein the pump parameter includes one or more of an oil type, process parameter, maintenance contract information, pump model, pump serial number, customer name, location, alarm register, current frequency, running time, number of restarts by Cottrell in order to for adjusting operating conditions of the operating components when the one or more operating parameters exceed established parameters (see Cottrell’s p4).
Claim(s) 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pal (US20190154469A1) as applied to claim 1 above, and further in view of Novik (US6918124B1).
Claim.5 Pal does not discloses wherein the cloud server a tree-structure is defined, wherein each vacuum pump is assigned to a leaf node of the tree-structure, wherein each level of the tree structure may correspond to one of the pump parameters such that different vacuum pumps comprising the same pump parameter share the same parent node, wherein a look-up table is assigned to one of the nodes of the tree-structure, wherein all sub-nodes of this node use the same look-up table.
However, Novik discloses wherein the cloud server a tree-structure is defined, wherein each vacuum pump is assigned to a leaf node of the tree-structure, wherein each level of the tree structure may correspond to one of the pump parameters such that different vacuum pumps comprising the same pump parameter share the same parent node, wherein a look-up table is assigned to one of the nodes of the tree-structure, wherein all sub-nodes of this node use the same look-up table (see fig.1-4, abstract, the filtering trees have nodes representing event variables that ultimately branch to leaf nodes thereunder, and the leaf nodes identify which of a set of queries are satisfied by an actual event,col.1, ln.60-67, the filtering trees are arranged as hierarchies of nodes, with parent nodes representing parameters, and each parent node capable of having multiple data points corresponding to the values of a parameter to be evaluated. Depending on the result of the evaluation against the actual parameter values for a given event instance, the parent node branches to an appropriate child node representing further parameters to be evaluated, or to a leaf node which specifies whether a query is (or which queries are) satisfied by the event parameters and actual values).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to modify Pal to include wherein the cloud server a tree-structure is defined, wherein each vacuum pump is assigned to a leaf node of the tree-structure, wherein each level of the tree structure may correspond to one of the pump parameters such that different vacuum pumps comprising the same pump parameter share the same parent node, wherein a look-up table is assigned to one of the nodes of the tree-structure, wherein all sub-nodes of this node use the same look-up table by Novik in order to determine whether the original trees should be kept instead of the resulting tree (see Novik’s abstract).
Claim.6 Pal does not discloses wherein different look-up tables are assigned to different nodes of the tree-structure, wherein for a specific vacuum pump the look-up table is used which is assigned to a lowest level node in the tree-structure connected to the specific vacuum pump.
However, Novik discloses wherein different look-up tables are assigned to different nodes of the tree-structure, wherein for a specific vacuum pump the look-up table is used which is assigned to a lowest level node in the tree-structure connected to the specific vacuum pump (see fig.1-4, abstract, the filtering trees have nodes representing event variables that ultimately branch to leaf nodes thereunder, and the leaf nodes identify which of a set of queries are satisfied by an actual event,col.1, ln.60-67, the filtering trees are arranged as hierarchies of nodes, with parent nodes representing parameters, and each parent node capable of having multiple data points corresponding to the values of a parameter to be evaluated. Depending on the result of the evaluation against the actual parameter values for a given event instance, the parent node branches to an appropriate child node representing further parameters to be evaluated, or to a leaf node which specifies whether a query is (or which queries are) satisfied by the event parameters and actual values).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to modify Pal to include wherein different look-up tables are assigned to different nodes of the tree-structure, wherein for a specific vacuum pump the look-up table is used which is assigned to a lowest level node in the tree-structure connected to the specific vacuum pump by Novik in order to determine whether the original trees should be kept instead of the resulting tree (see Novik’s abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHARDUL D PATEL whose telephone number is (571)270-7758. The examiner can normally be reached Monday-Friday 8am-5pm (IFP).
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, KITO ROBINSON can be reached at (571)270-3921. 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.
/SHARDUL D PATEL/Primary Examiner, Art Unit 3664
Prosecution Insights