DETAILED ACTION
This office action is in response to claims filed 8 October 2025
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to the claims rejected under 35 U.S.C. 103 have been considered but are moot because the argument does not specifically challenge the new reference (LEONELLI) used in the rejection.
Claim Objections
Claims 1, and 11 are objected to because of the following informalities (line numbers correspond to claim 1): In line 11, “the one or the one or more hardware components” should read “the one or more hardware components.” Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a virtual platform stratus (VPS)” in claims 1, 4, 7, 11, and 18, “telemetry database” in claims 3, and 17, “virtual network interface (VNI)“ in claims 8, and 9, “secure virtual fabric (SVF)” in claims 11, and 14, “coarsely grained programmable elements” in claim 13, “programmable signal connectivity element” in claim 13, “secure logic elements” in claim 15.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof, recited in [0055], and [00139].
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over RIMMER Patent No.: US 7,328,284 B2 (hereafter RIMMER), in view of LEONELLI et al. Pub. No.: US 2018/0054850 A1 (hereafter LEONELLI).
RIMMER was cited previously.
Regarding claim 1, RIMMER teaches:
A system for virtualizing communication channels between one or more hardware components and a controller, the system comprising:
a first controller implemented in a reconfigurable hardware device (RHD) ([Column 15, Lines 60-67] There are multiple layers of protocol stacked on the top of HCA 215 (i.e., either host channel adapter 215, or the host server on which is runs, represents a “reconfigurable hardware device” because it can be configured, and reconfigured to suit the needs of the system). Right above the HCA 215, virtual NIC 222 (i.e., “first controller” implemented on hardware server 255) exists. In accordance with the present invention, as described further below, virtual NIC 222 is a protocol that appears logically as a physical NIC to a server 255. That is, virtual NIC 222 does not reside physically like NIC 40 does in a traditional server; rather virtual NIC 222 only appears to exist logically); and
a virtual platform stratus (VPS) having a plurality of input/output (I/O) ports for electrically coupling with the first controller and with the one or more hardware components and receiving one or more electrical signals therefrom ([Column 16, Lines 1-5] Using virtual NIC 222, server 255 communicates via virtual I/O bus 240, which connects to virtual port 242 (i.e., “plural input/output ports” as illustrated in FIG. 7a). Virtual port 242 exists within I/O interface unit 62 (i.e., “virtual platform stratus”) and cooperates with virtual NIC 222 to perform typical functions of physical NICs 40). [Column 17, Lines 9-13] Based on the destination address of the packet, forwarding table 245 is used to determine whether the packet will be delivered to another virtual port 242 or NIC 40, which is coupled to network systems 105 (i.e., destination virtual ports 242 associated with other hardware servers, and other hardware NICs represent “one or more hardware components” that are coupled to the I/O interface unit 62 via network systems 105)), and wherein the VPS is configured to generate one or more data frames from the one or more first electrical signals ([Column 18, Lines 1-2] A virtual port 242 arranges (or writes) (i.e., “generates”) data (i.e., “signals”) into virtual port frame 380);
While RIMMER discusses communication of signals to either the controller or hardware components, RIMMER does not explicitly teach:
convert the data frames into one or more second electrical signals to send to the first controller, the one or the one or more hardware components, or combinations thereof, in an electrical form that is native to the first controller or the one or more hardware components.
However, in analogous art that similarly teaches communication of signals to either a controller or hardware components, LEONELLI teaches:
convert the data frames into one or more second electrical signals to send to the first controller, the one or the one or more hardware components, or combinations thereof, in an electrical form that is native to the first controller or the one or more hardware components ([0035] The resultant data is sent in a format native to the controller device type, enabling the controller device to process such data further…The code virtualization server either generates the resultant data in the native format of the controller device type, or converts the resultant data to the native format of the controller device type, using known techniques).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LEONELLI’s teaching of converting resultant data from a non-native format into a native format to send to a controller, with RIMMER’s teaching of sending data to a virtual NIC acting as a controller, to realize, with a reasonable expectation of success, a system that sends data to a controller, as in RIMMER, that has been converted into a format native to the controller, as in LEONELLI. A person having ordinary skill would have been motivated to make this combination to ensure that the container receiving the data is able to perform further processing due to it being in a native format (LEONELLI [0035])
Regarding claim 2, RIMMER further teaches:
the first controller is implemented as a virtual System-on- Chip (vSoC) instance ([Column 16, Lines 1-5] Using virtual NIC 222, server 255 communicates via virtual I/O bus 240, which connects to virtual port 242. Virtual port 242 exists within I/O interface unit 62 and cooperates with virtual NIC 222 to perform typical functions of physical NICs 40 (i.e., virtual NIC is a virtualized network interface card, or “chip”, thus representing a virtualized system-on-chip instance)).
Regarding claim 3, RIMMER further teaches:
a telemetry database that includes a table for mapping each of the plurality of I/O ports with an identifier (The present invention is also directed to a shared I/O subsystem having a forwarding table and a plurality of I/O interfaces. The forwarding table has a plurality of entries that correspond to each of the I/O interfaces.) of a hardware component type (Column 20, Lines 5-25, Table 2 below shows an exemplary forwarding table that can be used in shared I/O subsystem configuration (i.e., forwarding table identifies types of hardware components, such as “shared I/O Unit CPU” or that a particular hardware component is of a type associated with a host virtual port or ethernet port)).
Claims 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over RIMMER, in view of LEONELLI, as applied to claim 1 above, and in further view of SHELLHAMMER et al. Pub. No.: US 2019/0247618 A1 (hereafter SHELLHAMMER)
SHELLHAMMER was cited previously
Regarding claim 4, while RIMMER and LEONELLI discusses input and output of signals, RIMMER and LEONELLI does not explicitly teach:
the one or more hardware components are configured to output one or more signals, and wherein the VPS is configured to convert an analog signal to a digital signal and generate the data frames from the digital signal.
However, in analogous art, SHELLHAMMER teaches:
the one or more hardware components are configured to output one or more signals, and wherein the VPS is configured to convert an analog signal to a digital signal and generate the data frames from the digital signal ([0062] AFE 502 may include circuitries configured to receive sensor signals transmitted by sensor 208 (i.e., “hardware components”) and to perform analog signal conditioning operations on the receive signals. The signal conditioning operations may include, for example, amplification, filtering, etc. Signal processing circuit 504 may generate a digital representation of the sensor signals processed by AFE 502. For example, signal processing circuit 504 may include an analog-to-digital converter (ADC) to sample and quantize the sensor signals into a series of digital values (i.e., converting analog signals into digital signals). Signal processing circuit 504 may also perform additional processing such as generating data frames including the digital values and other information).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined SHELLHAMMER’s teaching of receiving signals from hardware, converting those signals from analog to digital, and generating the data frame from the digital signal, with RIMMER and LEONELLI’s teaching of receiving signals from hardware and generating data frames, to realize with a reasonable expectation of success, a system that receives an incoming signal from a hardware device, and in order to generate a data frame, as in RIMMER and LEONELLI, it converts the signal from analog to digital. As in SHELLHAMMER. A person having ordinary skill would have been motivated to make this combination to enable reception of data from more types of hardware.
Regarding claim 5, SHELLHAMMER further teaches:
any of the one or more hardware components is configured to convert the analog signal to the digital signal and convert the digital signal into any supported standard ([0058] Monitoring system 302 may transmit wireless signals including control data (e.g., to initiate the wireless transmission of sensor data, to set the wireless transmission frequency, etc. at wireless guidewire 200) using a frequency of 915 MHz, which can be a frequency within the Industrial, Scientific, and Medical (ISM) radio frequency band (i.e., this is a transmission “standard”). Monitoring system 302, or a standalone wireless power transmitter (not shown in FIG. 3) may also transmit the 915 MHz wireless signals with a high signal power to deliver electric power to wireless guidewire 200. On the other hand, monitoring system 302 may receive the sensor data from wireless guidewire 200 at a frequency of 403 MHz, which can be a frequency within the Medical Implant Communication Service (MICS) 402-405 MHz frequency band, to avoid interference by the much stronger 915 MHz wireless signals).
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over RIMMER, in view of LEONELLI, as applied to claim 1 above, and in further view of DEVILBISS et al. Patent No.: US 9,473,400 B1 (hereafter DEVILBISS).
DEVILBISS was cited previously.
Regarding claim 6, while RIMMER, and LEONELLI discusses use of a controller VNIC, RIMMER and LEONELLI does not explicitly teach:
a second controller, the second controller being configured as a same type as the first controller for redundancy.
However, in analogous art, DEVILBISS teaches:
a second controller, the second controller being configured as a same type as the first controller for redundancy ([Column 7, Lines 26-33] A method 600 is preferably performed by the VNIC server failover mechanism, which could include 125 in FIG. 1, 470 in FIG. 4, and 510 in FIG. 5. The prioritized VNIC server list is defined (step 610). This list may include any suitable number of VNIC servers (i.e., at least a “second controller”), but most preferably includes two or more to provide the redundancy of having a backup VNIC server in case the currently-selected VNIC server stops working (i.e., the configurations of backup VNICs are the same so as to provide the same service when switched to upon failover)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined DEVILBISS’s teaching of redundant VNIC controllers, with RIMMER, and LEONELLI’s teaching of a VNIC controller that sends and receives data frames, to realize, with a reasonable expectation of success, a system that sends and receives data frame via a VNIC controller, as in RIMMER, and has at least a second VNIC controller redundant to the first VNIC controller, as in DEVILBISS and LEONELLI. A person having ordinary skill would have been motivated to make this combination to provide continuous data transmission during a failover event of a first VNIC controller.
Regarding claim 7, DEVILBISS further teaches:
the VPS is configured to send the one or more data frames to the second controller based on a fault occurring with the first controller ([Column 7, Lines 52-57] When the hypervisor detects a problem in a VNIC server (step 810=YES), the VNIC server is marked as inactive (step 860). When the inactive VNIC server is the currently-selected VNIC server (step 870=YES), a switch is made to the next VNIC server on the prioritized VNIC server list (step 872) (i.e., switching to the redundant VNIC server routes data frames to the redundant VNIC server)).
Claims 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over RIMMER, in view of LEONELLI as applied to claim 1 above, and in further view of THOTA et al. Pub. No.: US 2015/0381578 A1 (hereafter THOTA), in view of MEHROTRA et al. Pub. No.: US 9,940,241 B1 (hereafter MEHROTRA).
THOTA and MEHROTRA was cited previously.
Regarding claim 8, while RIMMER and LEONELLI discusses a virtual network interface card, RIMMER and LEONELLI does not explicitly teach:
a virtual network interface (VNI) using a point- to-point messaging between authorized endpoints, wherein:
the VNI ensures that the system can only process messages to and from other components that are authorized by the system, and
the VNI converts arbitrary communications from a plurality of protocols into the point-to- point messaging.
However, in analogous art, THOTA teaches:
a virtual network interface (VNI) using a point- to-point messaging between authorized endpoints, wherein: the VNI ensures that the system can only process messages to and from other components that are authorized by the system ([0183] When a GVM is booted-up or is migrated to this host, the encryptor is added to the chain of I/O operations for appropriate VNICs. The encryptor gathers the details from the VNIC (i.e., implementing a “virtual network interface”) and logical switch and send the LinkUP message to the encryption agent. The encryptor set 215 then asks the encryption agent 360 for key information when it receives a GVM message that is sent from the booted-up GVM to another GVM (i.e., communications between VNIC endpoints of two GVMs represent “point-to-point” messaging). In response, the encryption agent 360 asks the LPN controller to authenticate the endpoint (i.e., to authenticate the VNIC of the GVM), and provide key manager credentials and the lookup tables. Upon receiving key manager credentials and the lookup tables, the encryption agent 360 contacts the key manager specified by the LPN controller and obtains the needed key. The encryption agent then passes the requested key(s) to the encryptor set 215 (e.g., in a lookup table that includes the key(s))),
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined THOTA’s teaching of a VNIC that ensures messages are transmitted between authorized endpoints using point to point messaging, with RIMMER and LEONELLI’s teaching of a VNIC that facilitates communication between endpoints, to realize, with a reasonable expectation of success, a system having a VNIC, as in RIMMER and LEONELLI, that ensures messages are transmitted between authorized endpoints using point to point messaging as in THOTA. A person having ordinary skill would have been motivated to make this combination so to improve security when transmitting between endpoints.
While RIMMER, LEONELLI and THOTA discuss operations of a VNIC in facilitating secure point-to-point communications, RIMMER, LEONELLI and THOTA does not explicitly teach:
the VNI converts arbitrary communications from a plurality of protocols into the point-to- point messaging.
However, in analogous art that similarly discusses operations of a NIC, MEHROTRA teaches:
the [NIC] converts arbitrary communications from a plurality of protocols ([Column 5, Lines 40-53] The I/O interface circuits 112-1 to 112-4 provide high-speed connections between the external network 104 (e.g., InfiniBand, Fibre Channel, and/or Ethernet) and the first switch network circuitry 102-1, 102-2. The I/O circuitry provides protocol conversion, including packet format conversion, during high-speed data communication between the external network 104 and the first switch network circuitry 102-1, 102-2. In some embodiments, the external network I/O interface circuits 112-1 to 112-4 are implemented as network interface cards commonly referred to as NICs (i.e., implemented as the virtual NICs of RIMMER), which include circuits that are configured to transform packets to suitable formats as they pass between the external network 104 and the routing networks 102-1, 102-2) into the point-to- point messaging ([Column 4, Lines 58-61] the first management processor 116-1 is used to configure the first packet routing network circuit 102-1 to provide point-to-point communication between components operably coupled to it (i.e., communications from InfiniBand, Fibre Channel, or Ethernet protocols are “converted” into point-to-point communications between the components)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined MEHROTRA’s teaching of NICs that convert communications from a plurality of protocols into point-to-point messaging protocols, with the combination of RIMMER, LEONELLI and THOTA’s teaching of VNICs performing authenticated point-to-point communications, to realize, with a reasonable expectation of success, a system having VNICs that perform authenticated point-to-point communications, as in RIMMER, LEONELLI and THOTA, by converting communications from multiple protocols into a point-to-point protocol, as in MEHROTRA. A person having ordinary skill would have been motivated to make this combination to enable the system to receive and correctly process communications from a wide variety of devices using a plurality of different protocols.
Regarding claim 9, RIMMER further teaches:
the VNI implements bus-based technologies using the point-to-point messaging (Column 16, Lines 1-2: Using virtual NIC 222, server 255 communicates via virtual I/O bus 240, which connects to virtual port 242 (i.e., virtual I/O bus 240 enables the endpoint to endpoint communication described in RIMMER)).
Regarding claim 10, THOTA further teaches:
the point-to-point messaging is encrypted ([0181] Once GVM is moved to a security group, the security policies, including the encryption policy, associated with that group are automatically applied to the traffic sent from and received for the GVM).
Claims 11, 13-14, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over RIMMER, in view of LEONELLI, in view of NEVE DE MEVERGNIES et al. Pub. No.: US 2015/0033338 A1 (hereafter NEVEDEMEVERGNIES).
NEVEDEMEVERGNIES was cited previously.
Regarding claim 11, RIMMER teaches the invention substantially as claimed, including:
A system for virtualizing communication channels between one or more hardware components and a controller, the system comprising:
a first controller implemented in a reconfigurable hardware device (RHD) ([Column 15, Lines 60-67] There are multiple layers of protocol stacked on the top of HCA 215 (i.e., either host channel adapter 215, or the host server on which is runs, represents a “reconfigurable hardware device” because it can be configured, and reconfigured to suit the needs of the system). Right above the HCA 215, virtual NIC 222 (i.e., “first controller” implemented on hardware server 255) exists. In accordance with the present invention, as described further below, virtual NIC 222 is a protocol that appears logically as a physical NIC to a server 255. That is, virtual NIC 222 does not reside physically like NIC 40 does in a traditional server; rather virtual NIC 222 only appears to exist logically);
a virtual platform stratus (VPS) having a plurality of input/output (I/O) ports for electrically coupling with the first controller and one or more hardware components and receiving one or more electrical signals therefrom ([Column 16, Lines 1-5] Using virtual NIC 222, server 255 communicates via virtual I/O bus 240, which connects to virtual port 242 (i.e., “plural input/output ports” as illustrated in FIG. 7a). Virtual port 242 exists within I/O interface unit 62 (i.e., “virtual platform stratus”) and cooperates with virtual NIC 222 to perform typical functions of physical NICs 40). [Column 17, Lines 9-13] Based on the destination address of the packet, forwarding table 245 is used to determine whether the packet will be delivered to another virtual port 242 or NIC 40, which is coupled to network systems 105 (i.e., destination virtual ports 242 associated with other hardware servers, and other hardware NICs represent “one or more hardware components” that are coupled to the I/O interface unit 62 via network systems 105)), and wherein the VPS is configured to generate data frames from the one or more electrical signals ([Column 18, Lines 1-2] A virtual port 242 arranges (or writes) (i.e., “generates”) data (i.e., “signals”) into virtual port frame 380); and
a secure virtual fabric (SVF), wherein the SVF comprises one or more virtual fabric elements ([Column 8, Lines 23-39] As shown, using a low latency, high bandwidth fabric (i.e., “secure virtual fabric” because it enables communication using virtual NICs and virtual ports) such as InfiniBand fabric 160, multiple servers 255 share I/O subsystem 60, which obviates the need for having a plurality of dedicated I/O subsystems. Rather than having a dedicated I/O subsystem, server 255 has an adapter such as Host Channel Adapter (HCA) 215 (i.e., fabric “element”) that interfaces between server 255 and shared I/O subsystem 60. Note that for brevity and clarity purposes, certain components of servers 255, such as CPU 10 or memory 22 are not shown in FIG. 2B. HCA 215 acts as a common controller used in a traditional server system. In one aspect of the present invention, HCA 215 has a specialized chip that processes the InfiniBand link protocol at wire speed and without incurring any host overhead. HCA 215 performs all the functions required to send/receive complete I/O requests. HCA 215 communicates to shared I/O subsystem 60 by sending I/O requests through a fabric, such as InfiniBand fabric 160)...
While RIMMER discusses communication of signals to either the controller or hardware components, RIMMER does not explicitly teach:
convert the data frames into one or more second electrical signals to send to the first controller, the one or the one or more hardware components, or combinations thereof, in an electrical form that is native to the first controller or the one or more hardware components.
However, in analogous art that similarly teaches communication of signals to either a controller or hardware components, LEONELLI teaches:
convert the data frames into one or more second electrical signals to send to the first controller, the one or the one or more hardware components, or combinations thereof, in an electrical form that is native to the first controller or the one or more hardware components ([0035] The resultant data is sent in a format native to the controller device type, enabling the controller device to process such data further…The code virtualization server either generates the resultant data in the native format of the controller device type, or converts the resultant data to the native format of the controller device type, using known techniques).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LEONELLI’s teaching of converting resultant data from a non-native format into a native format to send to a controller, with RIMMER’s teaching of sending data to a virtual NIC acting as a controller, to realize, with a reasonable expectation of success, a system that sends data to a controller, as in RIMMER, that has been converted into a format native to the controller, as in LEONELLI. A person having ordinary skill would have been motivated to make this combination to ensure that the container receiving the data is able to perform further processing due to it being in a native format (LEONELLI [0035])
While RIMMER and LEONELLI discusses a high bandwidth virtual fabric, RIMMER and LEONELLI does not explicitly teach:
the SVF comprises one or more virtual fabric elements to prevent side-channel attacks.
However, in analogous art that similarly discusses data transmission via fabrics, NEVEDEMEVERGNIES teaches:
the SVF comprises one or more virtual fabric elements to prevent side-channel attacks ([0019] Interface 130 may be any type of internal bus, a link in an interconnect fabric such as an Intel.RTM. On-Chip System Fabric, or any other type of connection according to any other communication architecture. In embodiments in which encoding agent 110 and decoding agent 120 (i.e., “virtual fabric elements”) are on different chips, dice, substrates or in different packages, interface 130 may represent…any other type of connection according to any other communication architecture…encoding the data to be transmitted on interface 130 may reduce the effectiveness of power side channel attacks, and dedicating interface 130 to such transmissions may reduce the effectiveness of other side channel attacks, such as template attacks (i.e., reducing an attack’s effectiveness to zero essentially “prevents” the attack)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined NEVEDEMEVERGNIES’s teaching of virtual fabric elements that reduce or mitigate the effectiveness of side channel attacks, with RIMMER and LEONELLI’s teaching of a virtual fabric comprising various elements, to realize, with a reasonable expectation of success, a system that uses elements of a virtual fabric, as in RIMMER and LEONELLI, to reduce or mitigate the effectiveness of side channel attacks, as in NEVEDEMEVERGNIES. A person having ordinary skill would have been motivated to make this combination to reduce or mitigate the effectiveness of side channel attacks (NEVEDEMEVERGNIES [0019]).
Regarding claim 13, NEVEDEMEVERGNIES further teaches:
the one or more virtual fabric elements are provided by an array of coarsely grained programmable elements, and the array of coarsely grained programmable elements includes a programmable signal connectivity element that is configured to implement complex logic manipulation and transformation functions ([0019] Interface 130 may be any type of internal bus, a link in an interconnect fabric such as an Intel.RTM. On-Chip System Fabric, or any other type of connection according to any other communication architecture. In embodiments in which encoding agent 110 and decoding agent 120 (i.e., “virtual fabric elements” which are “coarsely grained programmable elements” because they are monolithic encryption/decryption applications) are on different chips, dice, substrates or in different packages, interface 130 may represent…any other type of connection according to any other communication architecture (i.e., encryption/decryption agents perform complex encryption/decryption logic to manipulate and transform data)).
Regarding claim 14, NEVEDEMEVERGNIES further teaches:
the SVF implements one or more secure logic elements to prevent the side-channel attacks ([0019] Interface 130 may be any type of internal bus, a link in an interconnect fabric such as an Intel.RTM. On-Chip System Fabric, or any other type of connection according to any other communication architecture. In embodiments in which encoding agent 110 and decoding agent 120 (i.e., “secure virtual fabric elements”) are on different chips, dice, substrates or in different packages, interface 130 may represent…any other type of connection according to any other communication architecture…encoding the data to be transmitted on interface 130 may reduce the effectiveness of power side channel attacks, and dedicating interface 130 to such transmissions may reduce the effectiveness of other side channel attacks, such as template attacks).
Regarding claims 16-17, they comprise limitations similar to those of claims 2-3, and are therefore rejected for similar rationale.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over RIMMER, in view of LEONELLI, in view of NEVEDEMEVERGNIES, as applied to claim 11 above, and in further view of BARENGHI, ALESSANDRO et al. “Fault Injection Attacks on Cryptographic Devices: Theory, Practice, and Countermeasures.” January 21, 2011 (hereafter BARENGHI).
BARENGHI was cited previously.
Regarding claim 12, NEVEDEMEVERGNIES further teaches:
the side-channel attacks are selected from the group consisting of…side-channel leakage analysis, power supply monitoring, and electromagnetic emissions monitoring ([0004] Side channel attacks [make] analyses of power consumption (i.e., “power supply monitoring”), electromagnetic radiation (i.e., “electromagnetic emissions monitoring), or other characteristics of a data processing system to infer information about the system or the data it is processing. [0013] Information might be leaked from a system through a side channel. For example, power consumption during data transmission might vary might vary depending on the Hamming weight of the data being transmitted and/or the Hamming distance between the old data and the new data when the value of the data changes. Therefore, an attacker might be able to use power side channel analysis to reduce the search space required to discover the value of the data through trial and error (i.e., side-channel leakage analysis)).
While NEVEDEMEVERGNIES discusses examples of side channel attacks, RIMMER, LEONELLI, and NEVEDEMEVERGNIES does not explicitly teach:
the side-channel attacks are selected from the group consisting of fault-injection,
However, in analogous art, BARENGHI teaches:
the side-channel attacks are selected from the group consisting of fault-injection ([Page 1, Abstract] Hardware and software implementations have exhibited vulnerabilities to side channel attacks, e.g., power analysis and fault injection attacks).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have simply substituted BARENGHI’s teaching of side channel attacks including fault injection attacks, with NEVEDEMEVERGNIES teaching of examples of side channel attacks, because 1) NEVEDEMEVERGNIES discloses a system which differs from the claimed system because it does not explicitly disclose that a side channel attack may be a fault injection attack, 2) BARENGHI teaches a side channel attack may be a fault injection attack, and 3) one of ordinary skill could have substituted BARENGHI’s description of a fault injection attack as being a type of side channel attack into the examples of side channel attacks as discussed in NEVEDEMEVERGNIES, predictably resulting in a more complete and comprehensive list of examples of side channel attacks.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over RIMMER, in view of LEONELLI, in view of NEVEDEMEVERGNIES, as applied to claim 14 above, and in further view of KUNEMUND Pub. No.: US 2005/0213757 A1 (hereafter KUNEMUND).
KUNEMUND was cited previously.
Regarding claim 15, while NEVEDEMEVERGNIES discusses using logic elements to encrypt data, RIMMER, LEONELLI, and NEVEDEMEVERGNIES does not explicitly teach:
the one or more secure logic elements use dual-rail logic.
However, in analogous art that similarly performs encryption and decryption, KUNEMUND teaches:
the one or more secure logic elements use dual-rail logic ([0003] The present invention relates to a decryption circuit, an encryption circuit, a logic cell as well as a method of performing a dual-rail logic operation. [0104] The encryption circuit 820 comprises a dual-rail technology interface).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined KUNEMUND’s teaching of implementing an encryption/decryption circuit using dual-rail logic, with the combination of RIMMER, LEONELLI, and NEVEDEMEVERGNIES’s teaching of implementing encryption/decryption circuits to encrypt/decrypt data, to realize, with a reasonable expectation of success, a system that implements encryption/decryption circuits to encrypt/decrypt data, as in RIMMER, LEONELLI, and NEVEDEMEVERGNIES, using dual-rail logic, as in KUNEMUND. A person having ordinary skill would have been motivated to make this combination reduce the expenditure in terms of circuitry and area over single-rail circuit technology ([0014]).
Claims 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over RIMMER, in view of LEONELLI, in view of NEVEDEMEVERGNIES, as applied to claim 11 above, and in further view of SHELLHAMMER.
Regarding claims 18-19, they comprise limitations similar to those of claims 4-5, and are therefore rejected for similar rationale.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over RIMMER, in view of LEONELLI, in view of NEVEDEMEVERGNIES, as applied to claim 11 above, and in further view of DEVILBISS.
Regarding claim 20, it comprises limitations similar to those of claim 6, and is therefore rejected for similar rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195