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 § 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.
Claim(s) 1, 8 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210280325 A1 (hereinafter referred to as Jepperson) in view of US 12587408 B2 (hereinafter referred to a Beitlich)
As per claim 1 – Jepperson teaches a method, comprising:
receiving, by a processor in communication with a network, an indication of a first controller connecting to the network (IoT device 120 and IoT device 130 may include a network module (not shown) configured to establish a network connection with the network 110. Via this network connection with the network 110, IoT device – [0018]; configured to establish a network connection with the network corresponds to the Applicant’s “first controller connecting to the network”), the indication including a first unique identifier for the first controller (A device profile includes, but is not limited to, an IoT device identifier (ID) – [0025]; the IoT device identifier corresponds to the Applicant’s “first unique identifier”); querying, by the processor, a data model for information about the first controller based at least in part on the first unique identifier for the first controller, wherein the information includes a first data type that is processed by the first controller (Database 124 may operate as a repository for IoT data and other data (e.g., device type profiles, device profiles, data usage patterns, and data usage models) that may be associated with IoT device data – [0023]; Data usage patterns may include data type, data use frequency, and IoT device data use history – [0025]; In another embodiment, database 124 may be accessed by local IoT device 120 – [0023]; The Database corresponds to the Applicant’s “data model” and the data usage patterns including a data type correspond to the “information included a first data type that is processed by the first controller”); identifying, by the processor, in response to the query of the data model, a second controller that is connected to the network that processes a second data type that is compatible with the first data type (The example embodiment of the present invention may also include querying 208 the plurality of IoT devices to determine if the command is associated with at least one of the plurality of IoT devices. Further, method 200 of the example embodiment may determine 210 that the command may be associated with a second IoT device of the plurality of IoT devices, wherein the second IoT device may be compatible with the first command type – [0039]; querying the network for a second IoT device that is compatible with the first command type corresponds to this limitation) the second controller having a second unique identifier (A device profile includes, but is not limited to, an IoT device identifier (ID) – [0025]; Applies to the Applicant’s “second controller” as well).
Jepperson does not teach the following limitations. However, Beitlich, in the same field of network communications, teaches them as can be seen in the in-line citations below:
and integrating, by the processor, the first controller into the network by transmitting the first unique identifier to the second controller and transmitting the second unique identifier to the first controller (The data communication interface 112 includes various communication protocols including, but not limited to, the Aeronautical Radio, Incorporated (ARINC) protocol, controller area network (CAN), and time-triggered protocol (TTP). The data communication interface 112 facilitates the exchange of the ID data 104 from the aircraft communication bus 102 and the LRU 110 – [col. 4; lines 41-47]; The exchange of ID data from the aircraft commination bus to the LRU corresponds to the Applicant’s “transmitting” of “identifiers” between “controllers”).
Therefore, all of the claimed elements are taught through prior art references Jepperson and Beitlich. The sole difference between the references and the claimed invention is the combination of the technique of transmitting unique identifiers between controllers of Beitlich with the technique of identifying a data type compatible device on a network through a query of a data model evident in Jepperson. This combination would have been obvious to one of ordinary skill in the art because the identifier exchange is not dependent on the functions of the other elements of the claim and yields a predictable method of controller initialization on a network.
Claim(s) 2-4, 9-11, and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210280325 A1 (hereinafter referred to as Jepperson) in view of US 12587408 B2 (hereinafter referred to as Beitlich), further in view of US 20240160193 A1 (hereinafter referred to as Shah)
As per claim 2 – Jepperson in view of Beitlich teaches the method of claim 1, but does not teach the following limitations. However, Shah, in the same field of network communications, specifically industrial networks, teaches further comprising:
determining, by the processor, a data transformation to convert the second data type to the first data type based at least in part on the response to the query of the data model; and transmitting, by the processor, the data transformation to the first controller (According to an embodiment, a device interface component 206 can determine a data path to be traversed to obtain industrial data. The device interface component 206 can then establish a data connection along the data path from the industrial data to an industrial asset model 418. After the data connection has been established by the device interface component 206, a data transformation component 240 can then (e.g., in response to a determination that the industrial data comprises a first data format 1602) convert the industrial data from the first data format 1602 (e.g., a data format determined not to be compatible with the industrial asset model 418) to a second data format 1604 (e.g., a data format that is compatible with the industrial asset model 418 – [0110]; Establishing a data connection along the path from the industrial data to the industrial asset model corresponds to the Applicant’s “query of the data model”. The connection of the interface component to the data transformation component, which determines and performs the transformation, corresponds to the Applicant’s “transmitting … the data transformation to the fist controller”).
Therefore, all of the claimed elements are taught through prior art references Jepperson, Beitlich, and Shah. The sole difference between the references and the claimed invention is the combination of the established combination of Jepperson and Beitlich with the data transformation, determined through the query of a data model, of Shah. This combination would have been obvious to one of ordinary skill in the art because the data transformation is not dependent on the other claimed elements and yields a predictable technique for transmitting data between two heterogenous controllers.
As per claim 3 - Jepperson in view of Beitlich, further in view of Shah teaches the method of claim 2, Jepperson further teaches further comprising:
determining, by the processor, based at least in part on the response to the query of the data model, a first set of capabilities of the first controller and a second set of capabilities of the second controller; and determining, by the processor, that the first controller performs the data transformation based at least in part on the first set of capabilities and the second set of capabilities (For example, a second IoT device 130 may transmit a response to the query request with information about IoT device 130. IoT device 130 may be remotely located from IoT device 120. In other words, IoT device 130 may be a remote IoT device 130. The information may include a MAC address, device capabilities, list of commands and other information pertinent to the specific IoT device 130 – [0021]; The IoT device capabilities corresponds to the Applicant’s “set of capabilities”)
As per claim 4 - Jepperson in view of Beitlich, further in view of Shah teaches the method of claim 3, Shah further teaches:
wherein the first set of capabilities and the second set of capabilities include at least one of a processing power, a storage size, a memory size, a connection type or a location (The industrial asset model 418 can comprise data on an industrial device's design, construction, and operating conditions, as well as performance data such as energy consumption, output, and downtime – [0055]; The device interface component 206 can then establish a data connection along the data path from the industrial data to an industrial asset model 418. After the data connection has been established by the device interface component 206, a data transformation component 240 can then (e.g., in response to a determination that the industrial data comprises a first data format 1602) convert the industrial data from the first data format 1602 (e.g., a data format determined not to be compatible with the industrial asset model 418) to a second data format 1604 – [0110]; The industrial asset model defining an industrial devices’ performance data corresponds to the Applicant’s “capabilities include at least one of a processing power …”).
Claim(s) 5-7, 12-14, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210280325 A1 (hereinafter referred to as Jepperson) in view of US 12587408 B2 (hereinafter referred to as Beitlich), further in view of US 20240160193 A1 (hereinafter referred to as Shah) and the Face Technical Standard, Edition 3.1 (hereinafter referred to as The Open Group)
As per claim 5 - Jepperson in view of Beitlich, further in view of Shah teaches the method of claim 1, but does not teach the following limitations. However, The Open Group, in the same field of network communications, specifically avionics networks, teaches further:
wherein the second data type being compatible with the first data type includes the first data type being syntactically the same as the second data type (The Platform Data Model adds physical data type information to the logical measurement characterization – [97]; An Integration Model consists of elements that provide the means to model the exchange of information between UoPs. An Integration Model captures data exchanges, view transformations, and integration of UoPs for documentation of integration efforts – [98]; The Platform data model of FACE Technical Specification 3.1 allows distinct controllers to model data through data types, which corresponds to the Applicant’s “syntactically the same”. The Integration Model of FACE Technical Standard 3.1 allows for modeled exchanges of data between controllers, which corresponds to the Applicant’s claim of determining compatibility between data types).
Therefore, all of the claimed elements are taught through prior art references Jepperson, Beitlich. Shah, and The Open Group. The sole difference between the references and the claimed invention is the combination of the established combination of Jepperson, Beitlich, and Shah with the technique of determining compatibility syntactically, semantically, or logically of The Open Group. This combination would have been obvious to one of ordinary skill in the art because the technique of determining compatibility in this specific manner between controllers “enforces a multi-level approach to modeling entities and their associations at the conceptual, logical, and platform levels, enabling gradual and varying degrees of abstraction” [The Open Group, 15].
As per claim 6 - Jepperson in view of Beitlich, further in view of Shah and The Open Group teaches the method of claim 1, The Open Group further teaches:
wherein the second data type being compatible with the first data type includes the first data type being logically the same as the second data type (The Logical Data Model adds measurement information to each characterization by defining value type, units, measurement, and frame of reference (through the measurement system) – [97]; An Integration Model consists of elements that provide the means to model the exchange of information between UoPs. An Integration Model captures data exchanges, view transformations, and integration of UoPs for documentation of integration efforts – [98]; The Logical Data Model allows distinct controllers to be modeled through units, measurements, etc., corresponding to the Applicant’s “logically the same”. The Integration Model of FACE Technical Standard 3.1 allows for modeled exchanges of data between controllers, which corresponds to the Applicant’s claim of determining compatibility between data types).
As per claim 7 - Jepperson in view of Beitlich, further in view of Shah and The Open Group teaches the method of claim 1, The Open Group further teaches:
wherein the second data type being compatible with the first data type includes the first data type being semantically the same as the second data type (The Conceptual Data Model provides the semantic definition of the entities and their relationships characterized by Observables – [97]; An Integration Model consists of elements that provide the means to model the exchange of information between UoPs. An Integration Model captures data exchanges, view transformations, and integration of UoPs for documentation of integration efforts – [98]; The Conceptual Data Model allows distinct controllers to be modeled through semantic definition, corresponding to the Applicant’s “semantically the same”. The Integration Model of FACE Technical Standard 3.1 allows for modeled exchanges of data between controllers, which corresponds to the Applicant’s claim of determining compatibility between data types).
As per claim 8 – The limitations of claim 1 are identical to those of claim 8, except for a non-transitory machine-readable medium. Jepperson further teaches:
A non-transitory machine-readable medium having stored thereon instructions for performing a method of mediating a connection between a first controller connected to a network and a second controller connected to the network, comprising machine executable code which when executed by a processor, causes the processor to (The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention – [0061]; A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire – [0062]):
The remaining limitations are identical to those of claim 1. Therefore, the remaining limitations are rejected in the same manner.
As per claim 9 - The limitations are identical to those of claim 2. Therefore, the limitations are rejected in the same manner.
As per claim 10 - The limitations are identical to those of claim 3. Therefore, the limitations are rejected in the same manner.
As per claim 11 - The limitations are identical to those of claim 4. Therefore, the limitations are rejected in the same manner.
As per claim 12 - The limitations are identical to those of claim 5. Therefore, the limitations are rejected in the same manner.
As per claim 13 - The limitations are identical to those of claim 6. Therefore, the limitations are rejected in the same manner.
As per claim 14 - The limitations are identical to those of claim 7. Therefore, the limitations are rejected in the same manner.
As per claim 15 - The limitations are identical to those of claim 1. Therefore, the remaining limitations are rejected in the same manner.
As per claim 16 - The limitations are identical to those of claim 2. Therefore, the limitations are rejected in the same manner.
As per claim 17 - The limitations are identical to those of claim 3. Therefore, the limitations are rejected in the same manner.
As per claim 18 - The limitations are identical to those of claim 5. Therefore, the limitations are rejected in the same manner.
As per claim 19 - The limitations are identical to those of claim 6. Therefore, the limitations are rejected in the same manner.
As per claim 20 - The limitations are identical to those of claim 7. Therefore, the limitations are rejected in the same manner.
Conclusion
Prior art made of record and not relied upon is considered pertinent to the Applicant’s disclosure.
Wouhaybi (US 20200310394 A1) discussed an industrial software system and protocol of managing data in the system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSEPH MAXEN LANE whose telephone number is (571)272-8027. The examiner can normally be reached M-F from 7:30 A.M. - 5 P.M..
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, April Y. Blair can be reached at (571) 270-1014. 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.
/JOSEPH MAXEN LANE/Examiner, Art Unit 2196
/HIREN P PATEL/Primary Examiner, Art Unit 2196