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 .
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.
Claims 8 and 12 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.
Claims 8 and 12 recite the limitation "the user device is one of the third-party computer systems connected to the local network through the access control device". There is insufficient antecedent basis for this limitation in the claim. In particular there is no prior mention of “third-party computer systems connected to the local network through the access control device”. The claim merely recites that the access control device limits access to the local network, which does not necessarily mean third-party devices are present within the system.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 12-20 rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claims 12-20 recite a system that depends on the method of claim 1. To promote compact prosecution the Examiner will interpret claims 12-20 to depend on the system of claim 11. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-7, 9-11, and 13-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Montoya et al. (Design and Implementation of Virtual Instruments for Monitoring and Controlling Physical Variables Using Different Communication Protocols. 2007), hereinafter “Montoya”.
Regarding Claim 1, Montoya teaches a method within a computer system connected within a local network for aggregating diverse telemetry data received from one or more devices or sensors located within a premises and connected to the local network (Montoya p. 10, Fig. 4), the method comprising
instantiating a virtual measuring instrument within the computer system, the virtual measuring instrument including one or more communication protocol interfaces (Montoya p. 7 Col. 2, para. 2, This article describes a way to design and implement the necessary software to create virtual instruments with the property of being capable to communicate in a transparent way with the outside (to acquire data) through different communication protocols, such as: RS232, 1-Wire, TCP/IP, WiFi, WiMax, among others. A communication protocol is assigned to each virtual instrument) and
one or more predefined data acquisition tools provisioned for interaction with telemetry data generated by the one or more devices or sensors (Montoya p. 7, Col. 1, Section I. para. 2, A virtual instrument is a hardware-software combination through a PC that fulfils the same functions of a traditional instrument [2]. Besides the VI are very flexible and their functions may be changed by modifying software. );
associating the virtual measuring instrument with a first subnetwork of the local network to which the one or more devices or sensors are collectively connected (Montoya p. 10, Col. 1, A) The TINI embedded system is in charge of the sensor/control devices network (this network uses 1-Wire communication protocol which is a communication protocol specialized on sensor networks), the sending of data to a central server and the reception of different kinds of requests from the server. The central server saves data into a database and allows it visualization. Fig. 4 shows a general scheme of the entire system. Also see p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5). Also see Fig. 4. There is communication from either the database to the server that runs the virtual instrument or direct communication from the TINI to the server.),
wherein the first subnetwork operates using a first communication protocol that is different from a second communication protocol used on the local network (Montoya p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5): two of them connected directly to the DB, another one acquired its data directly from the TCP/IP port (1414 port) and the last one connected directly to the serial port (ttyS0). Each VI has its own communication protocol); and
the one or more communication protocol interfaces of the virtual measuring instrument include a first communication protocol interface that decodes data according to the first communication protocol (Montoya p. 10 Col. 2, Section B) On the development of the project, there was made a board set up by a PIC 16F877 microcontroller, a LM35 temperature sensor and a MAX-232 device (this one was used to transform PIC TTL voltages to RS232 communication protocol required voltages), which is in charge of acquiring the temperature sensor data and sending the acquired data, by way of RS232 protocol, to a server in which they are directly captured by a VI element. The information is communicated such that it can be used by the selected virtual instrument);
receiving the telemetry data within the virtual measuring instrument from the one or more devices or sensors on the first subnetwork using the first communication protocol interface as received telemetry data (Montoya p. 10, Col. 1, A) para. 3, The joint between the system and the VI may be made in two ways: The first one consist in that the data arriving from the sensor/control devices network are saved on database, therefore the VI directly communicate with the DB for acquiring their respective data and showing it on the screen. The second way consist in the direct data acquisition made by the VI, in this way each VI handles a connexion with the TCP/IP port, only receives the data of concern (data sent specially to the VI to a specific virtual port) and shows the receive data on the screen. In this way, there’s not necessary a DB.);
translating, using the one or more predefined data acquisition tools within the virtual measuring instrument, a format of the received telemetry data conforming to the first communication protocol to a normalized format resulting in normalized telemetry data (Montoya p. 8, Col. 1, Section III, para. 4, For the acquisition of data that will be shown on the screen, each protocol has its own capture method, nevertheless all these methods have the same name (setLectura), in other words, the method is recharged. The setLectura() method is responsible of creating the object that makes possible the communication. […] Each communication protocol is encapsulated in a class responsible of the configuration of all the parameters for an adequate communication. Also see Montoya p. 8, Cole. 2, para. 3 The implementation of a particular class for circular geometry objects is due to the complexity on the measurement scale transformation, the animation on data visualization and the transformation of the data acquired by the instrument to be correctly drawn on circular geometry); and
configuring a presentation of the normalized telemetry data for output to a user device connected to the local network (Montoya p. 8, Cole. 2, para. 3 The implementation of a particular class for circular geometry objects is due to the complexity on the measurement scale transformation, the animation on data visualization and the transformation of the data acquired by the instrument to be correctly drawn on circular geometry).
Regarding Claim 2, Montoya further teaches applying an algorithm within the virtual measuring instrument to the received operational data to generate a calculated value derived from the received operational data (Montoya p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5): two of them connected directly to the DB, another one acquired its data directly from the TCP/IP port (1414 port) and the last one connected directly to the serial port (ttyS0). Each one of these VI presented the acquired data on screen in a very satisfactory way. The data must be processed in order to be formatted for display as shown in fig. 5).
Regarding Claim 3, Montoya further teaches wherein a subset of the one or more devices are collectively connected to a second subnetwork of the local network that operates using a third communication protocol that is different from the first communication protocol and the second communication protocol (Montoya p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5): two of them connected directly to the DB, another one acquired its data directly from the TCP/IP port (1414 port) and the last one connected directly to the serial port (ttyS0). Each VI has its own communication protocol); and
the one or more communication protocol interfaces of the virtual measuring instrument include a second communication protocol interface that decodes data according to the third communication protocol (Montoya p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5): two of them connected directly to the DB, another one acquired its data directly from the TCP/IP port (1414 port) and the last one connected directly to the serial port (ttyS0). Each VI has its own communication protocol); and
the method further comprises
receiving the telemetry data within the virtual measuring instrument from the one or more devices or sensors on the second subnetwork using the second communication protocol interface as the received telemetry data (Montoya p. 10, Col. 1, A) para. 3, The joint between the system and the VI may be made in two ways: The first one consist in that the data arriving from the sensor/control devices network are saved on database, therefore the VI directly communicate with the DB for acquiring their respective data and showing it on the screen. The second way consist in the direct data acquisition made by the VI, in this way each VI handles a connexion with the TCP/IP port, only receives the data of concern (data sent specially to the VI to a specific virtual port) and shows the receive data on the screen. In this way, there’s not necessary a DB.); and
translating, using the one or more predefined data acquisition tools within the virtual measuring instrument, a format of the received telemetry data conforming to the third communication protocol to the normalized format resulting in the normalized telemetry data (Montoya p. 8, Col. 1, Section III, para. 4, For the acquisition of data that will be shown on the screen, each protocol has its own capture method, nevertheless all these methods have the same name (setLectura), in other words, the method is recharged. The setLectura() method is responsible of creating the object that makes possible the communication. […] Each communication protocol is encapsulated in a class responsible of the configuration of all the parameters for an adequate communication. Also see Montoya p. 8, Cole. 2, para. 3 The implementation of a particular class for circular geometry objects is due to the complexity on the measurement scale transformation, the animation on data visualization and the transformation of the data acquired by the instrument to be correctly drawn on circular geometry).
Regarding Claim 4, Montoya further teaches receiving a template as a basis of the virtual measuring instrument from a template library connected within the local network (Montoya p. 8, Col. 1, Section III. para. 1, The project establishes a main mother class which is the base of the virtual instruments. This class has all the fundamental methods that each virtual instrument should have like the method in charge of the instrument’s thread and the data acquisition method, besides it defines the basic variables required to draw the object in an adequate and standard way for all the child instruments. The designed mother class is denominated InstrumentoVirtual, it extends JComponent and it’s abstract.); and
receiving parameter values to populate the template before instantiating as the virtual measuring instrument (Montoya p. 8, Col. 1, Section III, para. 3, By having the Java Beans as the main idea of the project, all variables that directly affect the performance of the final element like variables in which are defined the colors of the final object, the measurement scales or the specific communication protocol that the particular Java Bean will use, should have its methods set and get to modify the variable and to give the actual value of it. ).
Regarding Claim 5, Montoya further teaches receiving a template as a basis of the virtual measuring instrument from a template library connected within the local network; and receiving instructions from the user device for customization of the template before instantiating as the virtual measuring instrument (Montoya p. 8, Col. 1, Section III. para. 2, The methods responsible of the alarm and to adjust the measurement scale are abstracts and should be defined by the child classes (this depend whether the instrument handles or not alarms or measurement scales, like the particular case of an on/off switch). The method in charge of repainting the objects on the screen is defined, but has to be rewritten by each child class due to the different characteristics of each instrument. ).
Regarding Claim 6, Montoya further teaches transmitting the normalized telemetry data to a database connected to the local network for storage and collective data analysis (Montoya p. 10, Col. 1, A) para. 3, The joint between the system and the VI may be made in two ways: The first one consist in that the data arriving from the sensor/control devices network are saved on database, therefore the VI directly communicate with the DB for acquiring their respective data and showing it on the screen. See Fig. 4, Database).
Regarding Claim 7, Montoya further teaches transmitting the normalized telemetry data to the user device connected to the local network in real time (Montoya p. 10 Col. 2, para. 1, The second way consist in the direct data acquisition made by the VI, in this way each VI handles a connexion with the TCP/IP port, only receives the data of concern (data sent specially to the VI to a specific virtual port) and shows the receive data on the screen.).
Regarding Claim 9, Montoya further teaches wherein the computer system is a control system connected to the first subnetwork that coordinates operations of the one or more devices or sensors connected to the first subnetwork (Montoya p. 10, Col. 1, A) para. 1, The TINI embedded system is in charge of the sensor/control devices network (this network uses 1-Wire communication protocol which is a communication protocol specialized on sensor networks), the sending of data to a central server and the reception of different kinds of requests from the server. The central server saves data into a database and allows it visualization. Fig. 4 shows a general scheme of the entire system.).
Regarding Claim 10, Montoya further teaches wherein the computer system is a gateway device that routes data traffic between the one or more devices or sensors on the first subnetwork (Montoya p. 10, Col. 1, A) para. 1, The TINI embedded system is in charge of the sensor/control devices network (this network uses 1-Wire communication protocol which is a communication protocol specialized on sensor networks), the sending of data to a central server and the reception of different kinds of requests from the server. The central server saves data into a database and allows it visualization. Fig. 4 shows a general scheme of the entire system.).
Regarding Claim 11, Montoya teaches a system for aggregating diverse telemetry data within a premises communication network, the system comprising the premises communication network including one or more subnetworks;
one or more devices or sensors connected to one of the one or more subnetworks;
a computing device including one or more hardware processors; and
a memory storage device configured with instructions for directing the one or more hardware computing processors to execute application programs and related programing units including a virtual measuring instrument application, when executed by the hardware processors, causes the hardware processors to
instantiate a virtual measuring instrument within the computing device, the virtual measuring instrument including one or more communication protocol interfaces (Montoya p. 7 Col. 2, para. 2, This article describes a way to design and implement the necessary software to create virtual instruments with the property of being capable to communicate in a transparent way with the outside (to acquire data) through different communication protocols, such as: RS232, 1-Wire, TCP/IP, WiFi, WiMax, among others. A communication protocol is assigned to each virtual instrument) and
one or more predefined data acquisition tools provisioned for interaction with telemetry data generated by the one or more devices or sensors (Montoya p. 7, Col. 1, Section I. para. 2, A virtual instrument is a hardware-software combination through a PC that fulfils the same functions of a traditional instrument [2]. Besides the VI are very flexible and their functions may be changed by modifying software. );
associate the virtual measuring instrument with a first subnetwork of the premises communication network to which the one or more devices or sensors are collectively connected (Montoya p. 10, Col. 1, A) The TINI embedded system is in charge of the sensor/control devices network (this network uses 1-Wire communication protocol which is a communication protocol specialized on sensor networks), the sending of data to a central server and the reception of different kinds of requests from the server. The central server saves data into a database and allows it visualization. Fig. 4 shows a general scheme of the entire system. Also see p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5). Also see Fig. 4. There is communication from either the database to the server that runs the virtual instrument or direct communication from the TINI to the server.),
wherein the first subnetwork operates using a first communication protocol that is different from a second communication protocol used on the premises communication network (Montoya p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5): two of them connected directly to the DB, another one acquired its data directly from the TCP/IP port (1414 port) and the last one connected directly to the serial port (ttyS0). Each VI has its own communication protocol); and
the one or more communication protocol interfaces include a first communication protocol interface that decodes data according to the first communication protocol (Montoya p. 10 Col. 2, Section B) On the development of the project, there was made a board set up by a PIC 16F877 microcontroller, a LM35 temperature sensor and a MAX-232 device (this one was used to transform PIC TTL voltages to RS232 communication protocol required voltages), which is in charge of acquiring the temperature sensor data and sending the acquired data, by way of RS232 protocol, to a server in which they are directly captured by a VI element. The information is communicated such that it can be used by the selected virtual instrument);
receive the telemetry data within the virtual measuring instrument from the one or more devices or sensors on the first subnetwork using the first communication protocol interface as received telemetry data (Montoya p. 10, Col. 1, A) para. 3, The joint between the system and the VI may be made in two ways: The first one consist in that the data arriving from the sensor/control devices network are saved on database, therefore the VI directly communicate with the DB for acquiring their respective data and showing it on the screen. The second way consist in the direct data acquisition made by the VI, in this way each VI handles a connexion with the TCP/IP port, only receives the data of concern (data sent specially to the VI to a specific virtual port) and shows the receive data on the screen. In this way, there’s not necessary a DB.);
translate, using the one or more predefined data acquisition tools, a format of the received telemetry data conforming to the first communication protocol to a normalized format resulting in normalized telemetry data (Montoya p. 8, Col. 1, Section III, para. 4, For the acquisition of data that will be shown on the screen, each protocol has its own capture method, nevertheless all these methods have the same name (setLectura), in other words, the method is recharged. The setLectura() method is responsible of creating the object that makes possible the communication. […] Each communication protocol is encapsulated in a class responsible of the configuration of all the parameters for an adequate communication. Also see Montoya p. 8, Cole. 2, para. 3 The implementation of a particular class for circular geometry objects is due to the complexity on the measurement scale transformation, the animation on data visualization and the transformation of the data acquired by the instrument to be correctly drawn on circular geometry); and
configure a presentation of the normalized telemetry data for output to a user device connected to the local network (Montoya p. 8, Cole. 2, para. 3 The implementation of a particular class for circular geometry objects is due to the complexity on the measurement scale transformation, the animation on data visualization and the transformation of the data acquired by the instrument to be correctly drawn on circular geometry).
Regarding Claim 13, Montoya further teaches wherein the computing device is a control system connected to the first subnetwork that coordinates operations of the one or more devices or sensors connected to the first subnetwork (Montoya p. 10, Col. 1, A) para. 1, The TINI embedded system is in charge of the sensor/control devices network (this network uses 1-Wire communication protocol which is a communication protocol specialized on sensor networks), the sending of data to a central server and the reception of different kinds of requests from the server. The central server saves data into a database and allows it visualization. Fig. 4 shows a general scheme of the entire system.).
Regarding Claim 14, Montoya further teaches wherein the computing device is a gateway device that routes data traffic between the one or more devices or sensors on the first subnetwork (Montoya p. 10, Col. 1, A) para. 1, The TINI embedded system is in charge of the sensor/control devices network (this network uses 1-Wire communication protocol which is a communication protocol specialized on sensor networks), the sending of data to a central server and the reception of different kinds of requests from the server. The central server saves data into a database and allows it visualization. Fig. 4 shows a general scheme of the entire system.).
Regarding Claim 15, Montoya further teaches wherein the virtual measuring instrument application, when executed by the hardware processors, causes the hardware processors to further apply an algorithm to the received operational data to generate a calculated value derived from the received operational data (Montoya p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5): two of them connected directly to the DB, another one acquired its data directly from the TCP/IP port (1414 port) and the last one connected directly to the serial port (ttyS0). Each one of these VI presented the acquired data on screen in a very satisfactory way. The data must be processed in order to be formatted for display as shown in fig. 5).
Regarding Claim 16, Montoya further teaches wherein a subset of the one or more devices are collectively connected to a second subnetwork of the local network that operates using a third communication protocol that is different from the first communication protocol and the second communication protocol (Montoya p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5): two of them connected directly to the DB, another one acquired its data directly from the TCP/IP port (1414 port) and the last one connected directly to the serial port (ttyS0). Each VI has its own communication protocol); and
the one or more communication protocol interfaces of the virtual measuring instrument include a second communication protocol interface that decodes data according to the third communication protocol (Montoya p. 11, Col. 1, para. 1, The complete system was proved using four VI acquiring data from different communication protocols (Fig 5): two of them connected directly to the DB, another one acquired its data directly from the TCP/IP port (1414 port) and the last one connected directly to the serial port (ttyS0). Each VI has its own communication protocol); and
the virtual measuring instrument application, when executed by the hardware processors, causes the hardware processors to further receive the telemetry data from the one or more devices or sensors on the second subnetwork using the second communication protocol interface as the received telemetry data (Montoya p. 10, Col. 1, A) para. 3, The joint between the system and the VI may be made in two ways: The first one consist in that the data arriving from the sensor/control devices network are saved on database, therefore the VI directly communicate with the DB for acquiring their respective data and showing it on the screen. The second way consist in the direct data acquisition made by the VI, in this way each VI handles a connexion with the TCP/IP port, only receives the data of concern (data sent specially to the VI to a specific virtual port) and shows the receive data on the screen. In this way, there’s not necessary a DB.); and
translate, using the one or more predefined data acquisition tools, a format of the received telemetry data conforming to the third communication protocol to the normalized format resulting in the normalized telemetry data (Montoya p. 8, Col. 1, Section III, para. 4, For the acquisition of data that will be shown on the screen, each protocol has its own capture method, nevertheless all these methods have the same name (setLectura), in other words, the method is recharged. The setLectura() method is responsible of creating the object that makes possible the communication. […] Each communication protocol is encapsulated in a class responsible of the configuration of all the parameters for an adequate communication. Also see Montoya p. 8, Cole. 2, para. 3 The implementation of a particular class for circular geometry objects is due to the complexity on the measurement scale transformation, the animation on data visualization and the transformation of the data acquired by the instrument to be correctly drawn on circular geometry).
Regarding Claim 17, Montoya further teaches wherein the virtual measuring instrument application, when executed by the hardware processors, causes the hardware processors to further receive a template as a basis of the virtual measuring instrument from a template library connected within the local network (Montoya p. 8, Col. 1, Section III. para. 1, The project establishes a main mother class which is the base of the virtual instruments. This class has all the fundamental methods that each virtual instrument should have like the method in charge of the instrument’s thread and the data acquisition method, besides it defines the basic variables required to draw the object in an adequate and standard way for all the child instruments. The designed mother class is denominated InstrumentoVirtual, it extends JComponent and it’s abstract.); and
receive parameter values to populate the template before instantiating as the virtual measuring instrument (Montoya p. 8, Col. 1, Section III, para. 3, By having the Java Beans as the main idea of the project, all variables that directly affect the performance of the final element like variables in which are defined the colors of the final object, the measurement scales or the specific communication protocol that the particular Java Bean will use, should have its methods set and get to modify the variable and to give the actual value of it. ).
Regarding Claim 18, Montoya further teaches wherein the one or more communication protocol interfaces each include a data decoder corresponding to a respective one of the one or more predefined data acquisition tools; and
when the data decoder is executed by the hardware processors, the data decoder causes the hardware processors to further perform one or more of the following actions with respect to receiving a transmission of the telemetry data:
authenticate the computing device to receive the transmission of the telemetry data (Montoya p. 8, Col. 2, para. 1, This method has a switch/case block that decides the kind of connexion that has been defined for the child instrument. If for any reason it hasn’t been defined the kind of connexion, the program assigns the connexion option to database. A connection protocol is verified to determine if it has been defined, and what the definition is);
decode a proprietary encoding of the telemetry data (Montoya p. 8, Col. 1, Section III. para. 3, By having the Java Beans as the main idea of the project, all variables that directly affect the performance of the final element like variables in which are defined the colors of the final object, the measurement scales or the specific communication protocol that the particular Java Bean will use, should have its methods set and get to modify the variable and to give the actual value of it. Also see Fig. 2. The virtual instrument code is made up of classes and subclasses that require the received data to be properly parsed so that the virtual instrument and data can be properly implemented and displayed);
decode a payload of the received transmission of the telemetry data (Montoya p. 8, Col. 1, Section III. para. 4, For the acquisition of data that will be shown on the screen, each protocol has its own capture method, nevertheless all these methods have the same name (setLectura), in other words, the method is recharged. The setLectura() method is responsible of creating the object that makes possible the communication.);
discover objects within the transmission of the telemetry data (Montoya p. 8, Col. 1, Section III. para. 3, By having the Java Beans as the main idea of the project, all variables that directly affect the performance of the final element like variables in which are defined the colors of the final object, the measurement scales or the specific communication protocol that the particular Java Bean will use, should have its methods set and get to modify the variable and to give the actual value of it. Also see Fig. 2. The virtual instrument code is made up of classes and subclasses that require the received data to be properly parsed so that the virtual instrument and data can be properly implemented and displayed); or
discover groups of data within the transmission of the telemetry data (Montoya p. 8, Col. 1, Section III. para. 3, By having the Java Beans as the main idea of the project, all variables that directly affect the performance of the final element like variables in which are defined the colors of the final object, the measurement scales or the specific communication protocol that the particular Java Bean will use, should have its methods set and get to modify the variable and to give the actual value of it. Also see Fig. 2. The virtual instrument code is made up of classes and subclasses that require the received data to be properly parsed so that the virtual instrument and data can be properly implemented and displayed).
Regarding Claim 19, Montoya further teaches wherein the virtual measuring instrument application, when executed by the hardware processors, causes the hardware processors to further receive a template as a basis of the virtual measuring instrument from a template library connected within the local network; and receive instructions from the user device for customization of the template before instantiating as the virtual measuring instrument (Montoya p. 8, Col. 1, Section III. para. 2, The methods responsible of the alarm and to adjust the measurement scale are abstracts and should be defined by the child classes (this depend whether the instrument handles or not alarms or measurement scales, like the particular case of an on/off switch). The method in charge of repainting the objects on the screen is defined, but has to be rewritten by each child class due to the different characteristics of each instrument. ).
Regarding Claim 20, Montoya further teaches a database connected to the premises communication network; and wherein the virtual measuring instrument application, when executed by the hardware processors, causes the hardware processors to further transmit the normalized telemetry data to the database for storage and collective data analysis (Montoya p. 10, Col. 1, A) para. 3, The joint between the system and the VI may be made in two ways: The first one consist in that the data arriving from the sensor/control devices network are saved on database, therefore the VI directly communicate with the DB for acquiring their respective data and showing it on the screen. See Fig. 4, Database).
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 8 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Montoya (as stated above) in view of He et al. (CN 103399777 A), hereinafter “He”.
Regarding Claim 8, Montoya (as stated above) further teaches wherein the computer system is an access control device connected within the local network that limits access to the devices or sensors on the local network from third-party computer systems outside the local network for security of the local network (Montoya p. 11 Col. 1, Section IV. para. 2, The virtual instruments designed and implemented as described in this article, bring all those advantages through the integration of characteristics such as alerts, security and network management. The great adaptability of this technology allows its incorporation in different kinds of environment like a house, a laboratory, a forest, a greenhouse or an industry. Also see Fig. 4. The system of Montoya is described as monitoring and displaying data of a closed environment of interest).
Montoya (as stated above) does not explicitly teach the user device is one of the third-party computer systems connected to the local network through the access control device.
However Montoya teaches both a database and server that runs the virtual instrument (see Montoya Fig. 4. Also see p. 10, Col.1 , A) para. 1, The greenhouse remote monitoring and controlling system used in this project is a hardware-software platform whose principal idea is the monitoring and control of the physical variables of a greenhouse through Internet. […] The central server saves data into a database and allows it visualization.), and states that the system is used in and provides the advantage of security in listed closed environments (Montoya p. 11, Col. 1, Section IV, para. 2, The virtual instruments designed and implemented as described in this article, bring all those advantages through the integration of characteristics such as alerts, security and network management. The great adaptability of this technology allows its incorporation in different kinds of environment like a house, a laboratory, a forest, a greenhouse or an industry.).
And He teaches allowing use of an intelligent terminal using a browser software to access data control measuring and interpret and display data (He [0028] the intelligent terminal user such as mobile phone user need not follow the download a mounting the mobile phone program flow, but directly using virtual instrument browser of the mobile phone to use the associated measuring application program).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application to modify Montoya (as stated above) in view of He to explicitly teach the user device is one of the third-party computer systems connected to the local network through the access control device, because the system is designed to only communicate within itself to devices connected to the local network and share that information through the internet when performing remote monitoring and controlling (Montoya p. 10, Col. 1, A) The greenhouse remote monitoring and controlling system used in this project is a hardware-software platform whose principal idea is the monitoring and control of the physical variables of a greenhouse through Internet.), and combining that with the mobile platform of He provides the advantage that any user with the intelligent terminal and access to the particular server or database, such as a lab server or the greenhouse monitoring remote server, will be able to run the virtual instrument with that data.
Regarding Claim 12, Montoya further teaches wherein the computing device is an access control device connected within the premises communication network that limits access to the devices or sensors on the premises communication network from third-party computer systems outside the premises communication network for security of the premises communication network (Montoya p. 11 Col. 1, Section IV. para. 2, The virtual instruments designed and implemented as described in this article, bring all those advantages through the integration of characteristics such as alerts, security and network management. The great adaptability of this technology allows its incorporation in different kinds of environment like a house, a laboratory, a forest, a greenhouse or an industry. Also see Fig. 4. The system of Montoya is described as monitoring and displaying data of a closed environment of interest).
Montoya (as stated above) does not explicitly teach the user device is one of the third-party computer systems connected to the local network through the access control device.
However Montoya teaches both a database and server that runs the virtual instrument (see Montoya Fig. 4. Also see p. 10, Col.1 , A) para. 1, The greenhouse remote monitoring and controlling system used in this project is a hardware-software platform whose principal idea is the monitoring and control of the physical variables of a greenhouse through Internet. […] The central server saves data into a database and allows it visualization.), and states that the system is used in and provides the advantage of security in listed closed environments (Montoya p. 11, Col. 1, Section IV, para. 2, The virtual instruments designed and implemented as described in this article, bring all those advantages through the integration of characteristics such as alerts, security and network management. The great adaptability of this technology allows its incorporation in different kinds of environment like a house, a laboratory, a forest, a greenhouse or an industry.).
And He teaches allowing use of an intelligent terminal using a browser software to access data control measuring and interpret and display data (He [0028] the intelligent terminal user such as mobile phone user need not follow the download a mounting the mobile phone program flow, but directly using virtual instrument browser of the mobile phone to use the associated measuring application program).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application to modify Montoya (as stated above) in view of He to explicitly teach the user device is one of the third-party computer systems connected to the local network through the access control device, because the system is designed to only communicate within itself to devices connected to the local network and share that information through the internet when performing remote monitoring and controlling (Montoya p. 10, Col. 1, A) The greenhouse remote monitoring and controlling system used in this project is a hardware-software platform whose principal idea is the monitoring and control of the physical variables of a greenhouse through Internet.), and combining that with the mobile platform of He provides the advantage that any user with the intelligent terminal and access to the particular server or database, such as a lab server or the greenhouse monitoring remote server, will be able to run the virtual instrument with that data.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kaur et al. ("An implementation of virtual instruments for industries for the standardization," 2023 International Conference on Artificial Intelligence and Smart Communication (AISC), Greater Noida, India, 2023, pp. 1110-1113, doi: 10.1109/AISC56616.2023.10085547.) discloses the advancements and advantages of virtual instrumentation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTIAN T BRYANT whose telephone number is (571)272-4194. The examiner can normally be reached Monday-Thursday and Alternate Fridays 7:00-4:30.
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, CATHERINE RASTOVSKI can be reached at 571-270-0349. 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.
/CHRISTIAN T BRYANT/Examiner, Art Unit 2863 01/15/2026