Notice of Pre-AIA or AIA Status
Claims 1-14 are currently presented for Examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
3. The amendment filed on 02/10/2026 has been entered and considered by the examiner. By the amendment, claims 1 and 4 are amended. Following Applicants arguments and amendments made, the previous 112 rejection of the claims is withdrawn. However, the 103 rejection of the claims is still maintained in view of the amendment made. See office action for detail.
Response to Arguments
Applicant 103 arguments
Currently amended independent claim 1 differs from Schubert at least with respect to the limitations wherein the simulation unit is further configured to simulate or virtually model the real first network with the virtual simulation network, and wherein the first real network is formed by a plurality of interconnected devices. Moreover, dependent claim 2 includes the limitations wherein the simulation unit is also configured to simulate the virtual simulation network in accordance with at least three different simulation levels. As discussed above, the cited reference to Schubert does not teach or suggest that the real network is simulated. Further, the reference is silent regarding three different simulation levels. The proffered rejection cites to Schubert's FIG. 7 in which various elements of the virtual network simulation module 612 are depicted; however, no explanation is provided for how these elements could be interpreted as different simulation levels. Instead, Schubert appears to be silent regarding different simulation levels. Accordingly, dependent claim 2 is allowable for separate reasons in addition to its dependency from an allowable independent claim.
Examiner response
Examiner respectfully disagrees. Schubert still discloses “wherein the simulation unit is further configured to simulate or virtually model the real first network with the virtual simulation network”. Schubert discloses a “virtual network simulation module 612” (see fig 7 and [0076]) and also teaches the virtual network manager 726 may be configured to create a virtual network based on the data received from the external network interface circuit integration module 718. The virtual network simulation module 612 may communicate with the non-BMS network 504 via the communication driver 720. (see [0087-0088]) The virtual device 800 is configured to represent a non-BMS device as BMS device. (see [0091])The virtual device manager 848 can receive data point values, device type information, device status information, and other information related to an associated non-BMS device via the virtual network manager 726. In a further embodiment, the virtual device manager 848 emulates multiple network devices based on devices listed the virtual device table 728. Further, the virtual device manager 848 can emulate the devices listed in the virtual device table as BACnet/IP devices. (see [0093]) From the above citation, it is clear that a virtual network composed of multiple virtual devices from real network data constitutes a model or simulation of the underlying network.
Applicant argues that Schubert only performs device-level abstraction. This is not persuasive. Schubert [0088] states that the virtual network manager creates a virtual network. Under the broadest reasonable sense, a network is a collection of interconnected devices. Schubert’s system creates a virtual environment in which multiple virtual devices corresponding to real devices are generated and managed together. This reasonably constitutes a virtual network representation.
Applicant argues that Schubert does not disclose a network formed by a plurality of interconnected devices. Schubert discloses that non-BMS network includes multiple devices and system. See Schubert [0071] In one example, the non-BMS network 504 may provide communications between an external network central controller 512, one or more outdoor units 514, a first third party system sub-system 516, and a second third party sub-system 518. As shown in FIG. 5, the first third-party sub-system 516 includes an outdoor unit 520, and two indoor units 522, 524. The outdoor unit may be an outdoor refrigeration unit. The indoor units 522, 524 may be indoor refrigeration units, such as blowers, fan coils and/or air-conditioning units. Similarly, the second third party system 518 may include an outdoor unit 526 and one or more indoor units 528.
Applicant argues Schubert fails to disclose “wherein the simulation unit is also configured to simulate the virtual simulation network in accordance with at least three different simulation levels” of claim 2. Schubert discloses “wherein the simulation unit is also configured to simulate the virtual simulation network”. See above Examiner response which is part of claim 1. Regarding three different simulation levels, Schubert discloses a multi-layer architecture including a BMS application layer 702, a network layer 704, an IP datalink layer 706 and a virtual datalink layer 708. (see [0083]). These layers perform different levels of abstraction and processing of network data, including parsing device data, mapping data into virtual device objects, translating protocols, and presenting the data to another network. (See [0085]- [0090]). Under the broadest reasonable sense, these distinct layers correspond to different levels at which the network and its behavior are represented and processed. Thus, Schubert teaches the limitations of claims 1-14. The rejection is still maintained.
Claim Objections
Claim 1 is objected to because of the following informalities: Claim 1 recites the limitation "the first real network". This lacks proper antecedent basis because "real" and "first" have been transposed, creating a new, undefined term. This should be “the real first network”. The applicant must amend the claim to consistently use one term throughout (e.g., "real first network") to provide clear boundaries for the invention.
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)(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.
4. Claim(s) 1-6, 8-10 and 13-14 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Schubert et al (PUB NO: US20190356513A1)
Regarding claim 1
Schubert teaches a transmission device for transmitting data between a real first network and a real second network, (see fig 5-6 and para 73- The BMS 500 is further shown to include a smart gateway 530. The smart gateway 530 is configured to provide an interface between the BMS network 502 and the non-BMS network 504. For example, the smart gateway 530 may convert data transmitted over the non-BMS network 504 into a compatible network protocol, such as BACnet, for use with the BMS network. The smart gateway 530 will be described in further detail below. In one embodiment, the smart gateway can read and write data to both the BMS network 502 and the non-BMS network 504. In some examples, the smart gateway 500 may further have a wireless radio for communicating with one or more user devices, such as mobile device 532. In some embodiments, a user accesses the smart gateway 530 via a mobile device 532, allowing the user access to the non-BMS network 504 and/or the BMS network 502.) wherein the transmission device has a first network port for coupling to the real first network and a second network port for coupling to the real second network (See fig 6 and para 74-82- Turning now to FIG. 6, a schematic view illustrating the smart gateway 530 of FIG. 5 is shown, according to some embodiments. The smart gateway 530 includes a BMS interface circuit 600 and an external network interface circuit 602. The BMS interface circuit 600 may further include a BMS network interface 622. The BMS network interface 622 can provide communication to and from the BMS network 502. The BMS interface circuit 600 further includes a communication interface 618. The communication interface 618 is configured to communicate with a second communication interface 620 located on the external network interface circuit 602. In one embodiment, the external network interface circuit 602 is configured to interface with the non-BMS network 504. The external network interface circuit 602 may interface with the non-BMS network 504 via a non-BMS network communication interface 632. and also comprises:
a simulation unit included at least one processor, connected to the first network port, which is configured to receive network-specific data from the real first network via the first network port, to provide a virtual simulation network of the real first network in accordance with the network-specific data received, and to provide the provided virtual simulation network, via the second network port, for access to the provided virtual simulation network from the real second network. (See para 83-89 and fig 5-7 - The virtual network simulation module 612 may communicate with the non-BMS network 504 via the communication driver 720. In one embodiment, the communication driver is a USB driver for communicating with the external network interface circuit 602. In other examples, the communication driver 720 may be other types of serial data drivers, such as RS-232, RS-485, etc. In some examples, the communication driver 720 may be a proprietary serial communication driver such as an H-Link communication driver from Hitachi. In some embodiments, the communication driver 720 can be in communication with the communication interface 618 for communicating with the communication interface 620 of the external network interface circuit 602. The communication driver 720 is further in communication with the external network interface circuit integration module 718. The external network interface circuit integration module 718 is configured to translate the data from the external network interface circuit 602, for use in the virtual network simulation module 612. For example, the external network interface circuit integration module 718 may be configured to parse the data received via the communication driver 720 into individual data points. The external network interface circuit integration module 718 may parse the received data by data type, device type, device address, etc. The external network interface circuit integration module 718 can then provide the parsed data to the virtual BMS application layer 714. In one embodiment, the virtual device table 728 may be populated with data related to one or more of virtual devices 710, 712. In one embodiment, the virtual device table 728 may be configured to represent a list of virtual BACnet objects; however other data object types are contemplated. In one embodiment, the virtual device table 728 is modified for each virtual device 710, 712 created by the virtual network manager 726. The virtual device table 728 may further provide mapping between the virtual devices 710, 712 and the associated non-BMS devices. See also para 104 step 1204 to step 1208)
wherein the simulation unit is further configured to simulate or virtually model the real first network with the virtual simulation network. (see Schubert “virtual network simulation module 612” (see fig 7 and [0076]) and see also 0087-0093-the virtual network manager 726 may be configured to create a virtual network based on the data received from the external network interface circuit integration module 718. The virtual network simulation module 612 may communicate with the non-BMS network 504 via the communication driver 720. The virtual device 800 is configured to represent a non-BMS device as BMS device. The virtual device manager 848 can receive data point values, device type information, device status information, and other information related to an associated non-BMS device via the virtual network manager 726. In a further embodiment, the virtual device manager 848 emulates multiple network devices based on devices listed the virtual device table 728. Further, the virtual device manager 848 can emulate the devices listed in the virtual device table as BACnet/IP devices.)
wherein the first real network is formed by a plurality of interconnected devices. (See para 71- In one example, the non-BMS network 504 may provide communications between an external network central controller 512, one or more outdoor units 514, a first third party system sub-system 516, and a second third party sub-system 518. As shown in FIG. 5, the first third-party sub-system 516 includes an outdoor unit 520, and two indoor units 522, 524. The outdoor unit may be an outdoor refrigeration unit. The indoor units 522, 524 may be indoor refrigeration units, such as blowers, fan coils and/or air-conditioning units. Similarly, the second third party system 518 may include an outdoor unit 526 and one or more indoor units 528.)
Regarding claim 2
Schubert further teaches wherein the simulation unit is also configured to simulate the virtual simulation network in accordance with at least three different simulation levels. (See fig 7 and para 83-Turning now to FIG. 7 an interface diagram showing the interaction between the gateway executable module 610 and the virtual network simulation module 612 of the BMS interface circuit is shown, according to some embodiments. As shown in FIG. 7, the gateway executable module 610 can include a data access component 700, a BMS application layer 702, a network layer 704, an IP datalink layer 706 and a virtual datalink layer 708. The virtual simulation module 612 is shown to include a first virtual device 710 and a second virtual device 712. While only two virtual devices 710, 712 are shown, it is contemplated that multiple virtual devices may be located within the virtual simulation module 612. In one embodiment, the virtual simulation module 612 may include up to two-hundred virtual devices. However, in other embodiments, the virtual network simulation module 612 may include more than two-hundred virtual devices or less than two-hundred virtual devices. The virtual network simulation module 612 may further include a BMS application layer 714, a network layer 716, an external network interface circuit integration module 718, a communication driver 720, and a virtual datalink layer 722.)
Regarding claim 3
Schubert further teaches wherein the simulation unit is configured, depending on the network-specific data received, to simulate the virtual simulation network in a first simulation level of the at least three different simulation levels by at least one network topology of the real first network, (see para 83-89- In a further embodiment, the virtual BMS application layer 714 can be configured to map the received data into a virtual device table 728. In one embodiment, the virtual device table 728 may be populated with data related to one or more of virtual devices 710, 712. In one embodiment, the virtual device table 728 may be configured to represent a list of virtual BACnet objects; however other data object types are contemplated. In one embodiment, the virtual device table 728 is modified for each virtual device 710, 712 created by the virtual network manager 726. The virtual device table 728 may further provide mapping between the virtual devices 710, 712 and the associated non-BMS devices.)
in a second simulation level of the at least three different simulation levels by at least one layer of a network protocol and/or a display of a service based on the real first network, (see para 86- The network layer 704 can modify the data stored in the one or more virtual devices 710, 712 to be presented over a network. In one embodiment, the network layer 704 modifies the data stored in the virtual devices 710, 712 for transmission over a BMS network using a BACnet protocol.)
and in a third simulation level of the at least three different simulation levels by at least one content-plausible web page based on the real first network. (See para 77- The webserver 614 is configured to process and deliver web pages to a user. In one embodiment, the webserver 614 may be an HTTP webserver. The webserver 614 may be configured to deliver images, such as HTML documents to a user via the mobile device 532. The webserver 614 may support server-side scripting, Active Server Pages, or other scripting languages. The webserver 614 may further be configured to provide information or generate web-pages to devices in a local network. For example, the webserver 614 may be configured to provide web-pages to devices which are connected directly to the smart gateway 530, such as via wireless radio 616. In some embodiments, the webserver 614 can provide a web-portal for a user to access the smart gateway 530. In some embodiments, the user can access the smart gateway 530 via mobile device 532 by accessing the web-portal (e.g. website) generated by the webserver 614. In some embodiments, the web-portal provides basic information associated with the smart gateway 530, such as configuration data, network data, status, errors, etc. In further embodiments, the web-portal may allow the user to fully configure the smart gateway 530 via the mobile device 532. For example, the user may be able to connect the smart gateway 530 to both the BMS network 502 and the non-BMS network 504 via the web-portal. In still further embodiments, the user may be able to configure the one or more devices associated with the non-BMS network 504 via the web-portal. This can allow a user to quickly and easily configure the smart gateway 530 such to provide the interface between the BMS network 502 and the non-BMS network 504.)
Regarding claim 4
Schubert further teaches wherein the transmission device further comprises a configuration unit including at least one processor, which is configured to receive network-specific data from the real first network via the first network port, to analyze the data and to use the analyzed network-specific data as configuration data for configuring the virtual simulation network. (See para 94-95-At process block 900, the external network interface circuit 602 is initialized. At process block 904, the external network interface circuit 602 communicates with the non-BMS network 504 to discover all devices and/or subsystems on the non-BMS network 504. In one example, the external network interface circuit 602 communicates with the non-BMS network 504 via the non-BMS communication interface 632. At process block 908, the discovered devices can be polled to obtain values for one or more data points associated with the discovered devices. In one embodiment, the external network interface circuit 602 performs the polling. In one embodiment, the polling may be conducted immediately upon the data structures being set up at process block 906. In other embodiments, the polling may be conducted at regular intervals to ensure that the device data is current. Once the discovered devices have been polled, the device data structures are updated at process block 910. At process block 912, the external network interface circuit 602 can schedule and parse the data to be sent to the BMS interface circuit. See para 100-102-The external network interface circuit 602 then transmits data packet 1110 to the virtual network manager 726. The virtual network manager 726 may then receive the data packet 1110 and update the virtual device at process block 1112. virtual network manager 726 may then receive the data packet 1110 and update the virtual device at process block 1118)
Regarding claim 5
Schubert further teaches wherein the configuration unit is further configured to configure the virtual simulation network automatically using the configuration data at least at a specific point in time, the at least one specific point in time comprising a point in time during the operation of the simulation unit. (See para 100-102- The virtual network manager 726 may then receive the data packet 1110 and update the virtual device at process block 1112. In some embodiments, the virtual network manager 726 may also indicate modify the virtual device to indicate that it is “Online” after receiving updated data if the virtual device was previously indicated as “Offline.” See also para 67- For example, building subsystems 428 can generate temporal (i.e., time-series) data indicating the performance of BMS 400 and the various components thereof.)
Regarding claim 6
Schubert further teaches wherein the transmission device is configured to run the simulation unit and the configuration unit in parallel. (See para 83-84-Turning now to FIG. 7 an interface diagram showing the interaction between the gateway executable module 610 and the virtual network simulation module 612 of the BMS interface circuit is shown, according to some embodiments. See para 93-94-The virtual device 800 may further include a virtual device manager 848. The virtual device manager 848 is configured to interface with the virtual network manager 726. The virtual device manager 848 can receive data point values, device type information, device status information, and other information related to an associated non-BMS device via the virtual network manager 726. See para 108- Also two or more steps may be performed concurrently or with partial concurrence.)
Regarding claim 8
Schubert further teaches wherein the transmission device is configured to carry out data transmission between the real first network and the real second network in a transmission layer, layer 2 according to the OSI/ISO Layer model. (See para 86- The IP datalink layer 706 is configured to access an IP based network. For example, where the BMS network 502 is BACnet IP, the IP datalink layer may package and transmit the data modified by the network layer 704 over the BACnet IP network. In other examples, the IP datalink layer 706 may be used where the BMS network 502 is any type of IP based network. The virtual datalink layer 708 may be configured to receive and transmit data to the virtual network simulation module 612. In one embodiment, the virtual datalink layer 708 communicates with the virtual network simulation module 612 via the virtual data link layer 722.)
Regarding claim 9
Schubert further teaches wherein the real first network comprises a control network, and the real second network comprises a diagnostic network, a local network, or the internet. (see para 69-73- Turning to FIG. 5, an exemplary building management system (“BMS”) 500 is shown having a BMS network 502 and a non-BMS network 504. The BMS network 502 may serve multiple devices and/or systems. For example, the BMS network 502 may provide communication between one or more BMS devices 506, a building automation system (“BAS”) 508 and/or connected services 510. In one embodiment, the BMS network 502 may be a Building Automation Control Network (“BACnet”). In one example, the non-BMS network 504 may provide communications between an external network central controller 512, one or more outdoor units 514, a first third party system sub-system 516, and a second third party sub-system 518.In some embodiments, the non-BMS network 504 may be a proprietary network associated with the thirty-party devices and systems. For example, metering systems, refrigeration systems, fire safety and/or suppression systems, and/or lighting systems may utilize proprietary or restricted protocols to communicate between devices within the systems.)
Regarding claim 10
Schubert further teaches wherein the transmission device is partially or completely configured as a unidirectional data diode, as a firewall, or as a gateway. (See para 73-he BMS 500 is further shown to include a smart gateway 530. The smart gateway 530 is configured to provide an interface between the BMS network 502 and the non-BMS network 504.)
Regarding claim 13
Schubert further teaches wherein the network-specific data comprises measured values, at least a number T of nodes of the real first network, operating states of nodes of the real first network and/or a technical process executed by at least one node of the real first network. The virtual device 800 may further include a number of data points. (See para 92-93-The data points may be binary output data points 804, binary input data points 806, analog output data points 808, analog input data points 810, multi-state outputs 812, and multi-state inputs 814. The binary input data points 806 may include data points such as a run/stop input 822, a filter sign 824, a communication state 826, an alarm signal 828, and a prohibit operation input 830. The analog output data points 808 may include an indoor temperature setpoint output 832. The analog input data points 810 may include an indoor intake temperature input 834 and an indoor temperature setpoint 836. The multi-state output data points 812 may include an operation mode output 838 and a fan speed output 840. The multi-state input data points 814 may include data points such as an operation mode state input 842, an alarm code 844, and a fan speed input 846.)
Regarding claim 14
Schubert further teaches wherein at least the simulation unit, the configuration unit the first network port and the second network port are implemented in a common housing. (see para [0073-0074], [0076-0077] and [0080-0082])
Examiner note: Smart gateway 530 contains all components in one device.
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.
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.
5. Claims 7 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Schubert et al (PUB NO: US20190356513A1) in view of Litichever et al. (PUB NO: US20200389469A1)
Regarding claim 7
Schubert does not teach wherein the transmission device configured to receive the data from the real first network via a network switch arranged between the real first network and the first network port, wherein at least one input of the network switch is connected to the real first network for data transmission and a mirror port implemented as an output of the network switch is connected to the first network port for data transmission.
In the related field of invention, Litichever teaches wherein the transmission device configured to receive the data from the real first network via a network switch arranged between the real first network and the first network port, wherein at least one input of the network switch is connected to the real first network for data transmission and a mirror port implemented as an output of the network switch is connected to the first network port for data transmission. (See para 186-188-A switch is a device in a computer network that connects together other devices. Multiple data cables are plugged into a switch to enable communication between different networked devices. Switches manage the flow of data across a network by transmitting a received network packet only to the one or more devices for which the packet is intended. Each networked device connected to a switch can be identified by its network address, allowing the switch to direct the flow of traffic maximizing the security and efficiency of the network. A switch is more intelligent than an Ethernet hub, which simply retransmits packets out of every port of the hub except the port on which the packet was received, unable to distinguish different recipients, and achieving an overall lower network efficiency. An Ethernet switch operates at the data link layer (layer 2) of the OSI model to create a separate collision domain for each switch port. Each device connected to a switch port can transfer data to any of the other ports at any time and the transmissions will not interfere. Managed switches have one or more methods to modify the operation of the switch. Common management methods include: a Command-Line Interface (CLI) accessed via serial console, telnet or Secure Shell, an embedded Simple Network Management Protocol (SNMP) agent allowing management from a remote console or management station, or a web interface for management from a web browser. Examples of configuration changes that one can do from a managed switch include: enabling features such as Spanning Tree Protocol or port mirroring, setting port bandwidth, creating or modifying virtual LANs (VLANs), etc.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the smart gateway device for providing communications between multiple networks as disclosed by Schubert to include wherein the transmission device configured to receive the data from the real first network via a network switch arranged between the real first network and the first network port, wherein at least one input of the network switch is connected to the real first network for data transmission and a mirror port implemented as an output of the network switch is connected to the first network port for data transmission as taught by Litichever in the system of Schubert in order to for protecting a network (such as a vehicular or automotive network) from malware by performing analysis of received messages not at the point of entry of the messages, and in particular, redirecting (such as by tunneling) the received messages for analysis by an analyzer in the network. Another motivation in order to improve network performance and monitoring. (See para 002 0198, Litichever)
Regarding claim 11
Schubert does not teach wherein the transmission device is configured to provide the real second network with a routing table comprising a plurality A of IP addresses of nodes of the real first network.
In the related field of invention, Litichever teaches wherein the transmission device is configured to provide the real second network with a routing table comprising a plurality A of IP addresses of nodes of the real first network. (See para 190-197-A router is a networking device that forwards data packets between computer networks. Routers perform the traffic directing functions on the Internet. A data packet is typically forwarded from one router to another router through the networks that constitute an internetwork until it reaches its destination node. A router is connected to two or more data lines from different networks. When a data packet comes in on one of the lines, the router reads the network address information in the packet to determine the ultimate destination. Then, using information in its routing table or routing policy, it directs the packet to the next network on its journey. When multiple routers are used in interconnected networks, the routers can exchange information about destination addresses using a routing protocol. Each router builds up a routing table listing the preferred routes between any two systems on the interconnected networks. The main purpose of a router is to connect multiple networks and forward packets destined either for its own networks or other networks. A router is considered a layer-3 device because its primary forwarding decision is based on the information in the layer-3 IP packet, specifically the destination IP address. When a router receives a packet, it searches its routing table to find the best match between the destination IP address of the packet and one of the addresses in the routing table. Once a match is found, the packet is encapsulated in the layer-2 data link frame for the outgoing interface indicated in the table entry. In the network for an enterprise, a computer server acting as a gateway node is often also acting as a proxy server and a firewall server. A gateway is often associated with both a router, which knows where to direct a given packet of data that arrives at the gateway, and a switch, which furnishes the actual path in and out of the gateway for a given packet.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the smart gateway device for providing communications between multiple networks as disclosed by Schubert to include wherein the transmission device is configured to provide the real second network with a routing table comprising a plurality A of IP addresses of nodes of the real first network as taught by Litichever in the system of Schubert in order to for protecting a network (such as a vehicular or automotive network) from malware by performing analysis of received messages not at the point of entry of the messages, and in particular, redirecting (such as by tunneling) the received messages for analysis by an analyzer in the network. (See para 002, Litichever)
Regarding claim 12
Schubert does not teach wherein the transmission device is configured to provide the real second network with at least one specific IP address of a specific node of the real first network.
In the related field of invention, Litichever teaches wherein the transmission device is configured to provide the real second network with at least one specific IP address of a specific node of the real first network. (See para 190-197-A router is a networking device that forwards data packets between computer networks. Routers perform the traffic directing functions on the Internet. A data packet is typically forwarded from one router to another router through the networks that constitute an internetwork until it reaches its destination node. A router is connected to two or more data lines from different networks. When a data packet comes in on one of the lines, the router reads the network address information in the packet to determine the ultimate destination. Then, using information in its routing table or routing policy, it directs the packet to the next network on its journey. When multiple routers are used in interconnected networks, the routers can exchange information about destination addresses using a routing protocol. Each router builds up a routing table listing the preferred routes between any two systems on the interconnected networks. The main purpose of a router is to connect multiple networks and forward packets destined either for its own networks or other networks. A router is considered a layer-3 device because its primary forwarding decision is based on the information in the layer-3 IP packet, specifically the destination IP address. When a router receives a packet, it searches its routing table to find the best match between the destination IP address of the packet and one of the addresses in the routing table. Once a match is found, the packet is encapsulated in the layer-2 data link frame for the outgoing interface indicated in the table entry. In the network for an enterprise, a computer server acting as a gateway node is often also acting as a proxy server and a firewall server. A gateway is often associated with both a router, which knows where to direct a given packet of data that arrives at the gateway, and a switch, which furnishes the actual path in and out of the gateway for a given packet.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the smart gateway device for providing communications between multiple networks as disclosed by Schubert to include wherein the transmission device is configured to provide the real second network with at least one specific IP address of a specific node of the real first network as taught by Litichever in the system of Schubert in order to for protecting a network (such as a vehicular or automotive network) from malware by performing analysis of received messages not at the point of entry of the messages, and in particular, redirecting (such as by tunneling) the received messages for analysis by an analyzer in the network. (See para 002, Litichever)
Conclusion
6. All claims 1-14 are rejected.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 10348767 B1 Lee et al.
Discussing a method for better cloud computing security to protect against attacks and reduce network vulnerability.
US 8010469 B2 Kapoor et al.
Discussing a system for flow processing and switching, security, and other network applications, including a facility that processes a data flow to address patterns relevant to a variety of conditions are directed at internal network security, virtualization, and web connection security.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
17. Any inquiry concerning this communication or earlier communications from the examiner should be directed to PURSOTTAM GIRI whose telephone number is (469)295-9101. The examiner can normally be reached 7:30-5:30 PM, Monday to Friday.
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, RENEE CHAVEZ can be reached at 5712701104. 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.
/PURSOTTAM GIRI/
Examiner, Art Unit 2186
/RENEE D CHAVEZ/Supervisory Patent Examiner, Art Unit 2186
Prosecution Insights