Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/27/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d).
Drawings
The drawings were received on 11/27/2024. These drawings are accepted.
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-9, and 11 are rejected 35 U.S.C. 103 as being unpatentable over HUILGOL et al. (USPGPUB No. 2022/0091872 A1, hereinafter referred to as Huilgol) in view of Guim Bernat et al. (US Pat No. 12254337 A1, hereinafter referred to as Guim Bernat).
Referring to claim 1, HUILGOL discloses a filter device for communication between first and second domains {“data plane 103 includes a programmable packet processing pipeline 104 that is programmable using a domain-specific language such as P4”, see Fig. 1 [0047], 1st sentence}, comprising:
a central processing unit, CPU {“control plane … control planes often include multiple CPU cores and other elements”, see Fig. 1, [0047], last two sentences}, and
a hardware programmable device {“network appliance 101, such as a NIC, … and a data plane 103”, see Fig. 1, [0042], 2nd sentence} connected to the CPU, the hardware programmable device comprising:
a first input/output, I/O, interface {“include I/O traffic flows with a NAS [interface]”, see Fig. 1 [0040], 1st sentence};
and a second I/O interface connected to the trusted domain {“interconnect may distribute memory transactions across a plurality of memory interfaces using a programmable hash algorithm” and the appropriate “P4” domain associated with hash, see Fig. 1 [0068, last three sentences};
a first filter channel {“filtering… and policing”, see Fig. 1 [0042], last two sentences} configured to filter a first data frame {“parsers, tables, actions, match-action units” (see Fig. 1 [0044]) further expanding upon “match-action pipeline 107 and to construct outgoing packets” ([0049], 1st sentence)} received from the first I/O interface {“[first interface] each port can send and receive packets [for example over the NAS Network Attached System].”, see Figs. 1 and 11a [0091]} and provide a first filtered data frame to the second I/O interface {“[second interface] each port can send and receive packets. As such, a port of a network appliance can be configured with a RX MAC 111 and a TX MAC 110”, see Figs. 1 and 11a [0091]}, and
a second filter channel {“filtering… and policing”, see Fig. 1 [0042], last two sentences also expanded Figure 3 “match-action pipeline 300” such as “match-action units 301, 302, 303 of the match-action pipeline 300 are programmed to perform “match-action” operations” ([0057], 3rd sentence} configured to filter a second data frame {“Frame Check Sequence (FCS), interframe gap enforcement, discarding malformed frames”, see Fig. 1 [0045], 3rd sentence} received from the second I/O interface {“[second interface] each port can send and receive packets.”, see Figs. 1 and 11a [0091]} and provide a second filtered data frame to the first I/O interface {“packet buffer 409 can act as a central on-chip packet switch that delivers packets from the network interfaces 410 to packet processing elements of the data plane”, see Fig. [0066], 1st sentence};
wherein each of the first and second filter channels comprises:
at least two filter chains {“network traffic flows 1100”, see Fig. 11A-11H [0089], 1st sentence} selected from a hardware filter chain {“transport layer protocol units (such as TCP or UDP messages)”, see Fig. 11A [0095], last sentence}, a software filter chain {“software defined NVMe SR-IOV host side data 1221”, see Fig. 12 [0103], 1st sentence}, and a combination thereof {“Data coded according to application layer protocols can be encapsulated into transport layer protocol units (such as TCP or UDP messages)”, see Fig. 11a [0095], last sentence}, wherein the hardware filter chain and the software filter chain {“SR-IOV host side data 1221 can include [hardware filter] PF data 1222 and [software filter] VF data 1223”, see Fig. 12 [0103], 4th sentences} comprise hardware filter circuitry {“[hardware filtering] PF data 1222 can contain PF NVMe PCIe registers 1201, a PF NVMe PCIe header 1202, PF NVMe-oF registers 1203, PF NVMe SR-IOV registers 1204, a PF admin SQ 1205, a PF admin CQ 1206, a PF IO SQ 1207, and a PF IO CQ 1208”, see Fig. 12 [0103], last two sentences} and the software filter chain comprises software circuitry connected to the CPU {“VF data 1223 can contain VF NVMe PCIe registers”, see Fig. 12 [0103], last sentence},
a demultiplexer {see Fig. 1, demultiplexer “demux/queue 109 can act as an egress unit and can also be configured to send packets to a drop port”, [0047]} configured to receive the respective first {“configured to implement operations related to, for example, receiving frames”, see Fig. 1 [0045, 3rd sentence} and second data frames {“Frame Check Sequence (FCS), interframe gap enforcement, discarding malformed frames”, see Fig. 1 [0045], 3rd sentence} from the respective first and second I/O interfaces {“[first interface] each port can send and receive packets. As such, a port of a network appliance can be configured with a RX MAC 111 and a TX MAC 110”, see Figs. 1 and 11a [0091]}, classify data streams of the respective first {“[second interface] each port can send and receive packets. As such, a port of a network appliance can be configured with a RX MAC 111 and a TX MAC 110”, see Figs. 1 and 11a [0091]} and second data frames according to at least one attribute into a classification {“[at least one] TCP FIN flag can indicate the final transmission on a TCP connection, packets transmitted before the FIN packet may be processed.”, see Fig. 1 [0094]}, and input the data streams into the hardware filter chain {“[input data] stream of bytes between applications running on hosts communicating via an IP network”, see Figs. 11a-11h, [0093]} and the software filter chain according to the classification to provide filtered data streams {“packets can be received by a RX MAC 111 as a raw bit stream or transmitted by TX MAC 110 as a raw bit stream”, two streams, one per RX/TX direction, see Figs. 11a-11h [0090]},
a multiplexer configured to combine {“The arbiter 105 can act as an ingress unit receiving packets from RX-MACs 111 and can also receive packets from the control plane via a control plane packet input 112” (see Fig. 1, [0047]) as a MUX “control plane 102” injects other filter streams to parts of the “data plane 103” (see Fig. [0047])} the filtered data streams from the hardware filter chain and the software filter chain {“PF BAR map 115 can be used by the host machine to communicate with the PF of the PCIe card”, see Fig. 1 [0050]} to provide respective first and second filtered data frames {“PF BAR maps and VF BAR maps 412 can map PCIe register locations to specific locations within the NIC's memory”, see Fig. 4, [0069], 2nd sentence} and transmit the first and second filtered data frames to the respective second and first I/O interfaces {“VF BAR map 116 can be used by a VM running on the host to communicate with a VF of the PCIe card”, see Fig. 1 [0050]};
Huilgol does not appear to explicitly disclose a first input/output, I/O, interface connected to the untrusted domain and a second I/O interface connected to the trusted domain, wherein the first I/O interface and the second I/O interface are each configured to receive and transmit data frames from and to the respective untrusted and trusted domains;
wherein the first and second domains are communication between a trusted domain and an untrusted domain.
However, Guim Bernat discloses a first input/output, I/O, interface {“Interconnect module 518 is configured to manage communications over an interconnect, such as a [first interface] CXL or PCIe interconnect”, see Fig. 8 Col 11, lines 11-13} connected to the untrusted domain {“The interconnect module 518 may be embodied as or otherwise include the port 126 of the [untrusted] offload device 125.”, see Fig. 8, Col 11, lines 13-15} and a second I/O interface connected {“Interconnect module 518 is configured to manage communications over an interconnect, such as a CXL or [second interface] PCIe interconnect”, see Fig. 8 Col 11, lines 11-13} to the trusted domain {“The interconnect module 518 may be embodied as or otherwise include the port 126 of the [trusted] offload device 125.”, see Fig. 8, Col 11, lines 13-15}, wherein the first I/O interface and the second I/O interface are each configured to receive and transmit data frames {“transmitted packets flow through the other layers, they are extended with additional information necessary to handle packets at those layers”, see Fig. 2, Col 5, lines 8-10; as well as “receiving side the reverse process occurs”, Col 5, lines 10-15} from and to the respective untrusted and trusted domains {“XPU attestation 408 may store entries for resources” table that distinguishes “trusted domain” versus “hardware registers of the processor 105 that cannot be modified by untrusted components” (both citations in Col 8, lines 15-21);
wherein the first and second domains are in communication between a trusted domain and an untrusted domain {“ any combination thereof. The method 900 begins in block 902, in which the system 100 performs attestation between the [trusted domain] processor 105 and one or more [untrusted domain] offload devices 15” (Col 11, lines 19-22) later determination whether or not the “offload devices 15” part of trusted domain (see Fig. 9, Col 11, lines 19-22)}.
HUILGOL and Guim Bernat are analogous because they are from the same field of endeavor, routing packet stream(s).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of HUILGOL and Guim Bernat before him or her, to modify HUILGOL’s “network appliance having a control plane 102” incorporating Guim Bernat’s “fabric composed of point-to-point links that interconnect a set of components” (see Fig. 1, Col 2, lines 54-56).
The suggestion/motivation for doing so would have been to implement/leveraging CXL.cache, CXL.memory, and CXL.IO, it is possible to add an accelerator, smart network interface controller (NIC), graphics processing unit (GPU), or field-programmable gate array (FPHA) to enhance the compute capabilities of a platform including trusted computing environments allows end-users to ensure security and privacy when operating in a cloud or shared environment (Guim Bernat Col 1, lines 8-16).
Therefore, it would have been obvious to combine Guim Bernat with HUILGOL to obtain the invention as specified in the instant claim(s).
As per claim 2, the rejection of claim 1 is incorporated and Huilgol discloses wherein each of the hardware circuitry comprises a stream filter {“packet quality of service parameters 216”, see Fig. 2, [0052]} and a rate limiter {“The multi-protocol label switching (MPLS) data 218, such as an MPLS label, may be obtained from the packet's layer 2 header”, see Fig. 2, [0052]} configured to limit a data rate {“packet quality of service parameters 216” typical that depending on the QoS priority/classification the rate increase/decreases accordingly, see Fig. 2, [0052]} of the respective data stream {see Fig. 2, “other layer 4 data 219 can be obtained from the packet's layer 4 header. The NVMe-oF (NVMe over fiber) PDU (protocol data unit) data 220 can be obtained from the packet's layer 7 header and layer 7 payload” ([0052], last two sentence) respective streams over NVMe/NVMeoF/RDMA ([0098]), Ethernet (see Figs. 11B and 11C, [0097], 1st sentence), or Internet (protocol) suite ([0090], 2nd sentence)}.
As per claim 3, the rejection of claim 1 is incorporated and Huilgol discloses wherein the hardware filter circuitry of the software filter chains and the hardware filter chains of the first and second filter channels are identical {see Fig. 3, “[hardware filter] key generation and [software filter] lookup functions constitute the [identical] ‘match’ portion of the operation and produce an action that is provided to the action unit via the selector logic” [0058]}.
As per claim 4, the rejection of claim 1 is incorporated and Huilgol discloses wherein the software circuitry is arranged downstream {“downstream] lookup table 310 is populated with key-action pairs, where a key-action pair”, see Fig. 3 [0058]} of the hardware circuitry in the software filter chains {see Fig. 3, “The PHV and/or table entries may be updated in each stage of match-action processing according to the actions specified by the P4 programming [software filter chain(s)]” [0057]}.
As per claim 5, the rejection of claim 1 is incorporated and Huilgol discloses wherein the first filter channel {“filtering… and policing”, see Fig. 1 [0042], last two sentences}, or the second filter channel {“filtering… and policing”, see Fig. 1 [0042], last two sentences also expanded Figure 3 “match-action pipeline 300” such as “match-action units 301, 302, 303 of the match-action pipeline 300 are programmed to perform “match-action” operations” ([0057], 3rd sentence}, or both comprise a plurality of hardware filter chains {“transport layer protocol units (such as TCP or UDP messages)”, see Fig. 11A [0095], last sentence}, or a plurality of software filter chains {“software defined NVMe SR-IOV host side data 1221”, see Fig. 12 [0103], 1st sentence} coupled between the respective demultiplexer and multiplexer {see Fig. 1, demultiplexer “demux/queue 109 can act as an egress unit and can also be configured to send packets to a drop port”, [0047]}, or both {Examiner’s interpretation: the “or” in this claim interpreted as a Markush group, thus the reference needs only disclose at least one group member to address the claim.},
wherein the respective demultiplexers and multiplexers are configured {“The arbiter 105 can act as an ingress unit receiving packets from RX-MACs 111 and can also receive packets from the control plane via a control plane packet input 112” (see Fig. 1, [0047]) as a MUX “control plane 102” injects other filter streams to parts of the “data plane 103” (see Fig. [0047]); demultiplexer “demux/queue 109 can act as an egress unit and can also be configured to send packets to a drop port”, [0047]} to classify the received data frames {“[second interface] each port can send and receive packets. As such, a port of a network appliance can be configured with a RX MAC 111 and a TX MAC 110”, see Figs. 1 and 11a [0091]} according to at least one attribute into classifications {“[at least one] TCP FIN flag can indicate the final transmission on a TCP connection, packets transmitted before the FIN packet may be processed.”, see Fig. 1 [0094]}, input the data streams of the data frames to one of the respective plurality of hardware filter chains {“[input data] stream of bytes between applications running on hosts communicating via an IP network”, see Figs. 11a-11h, [0093]}, or the plurality of software filter chains according to the classifications, or both, and combine the filtered data streams to provide the first and second filtered frames {Examiner’s interpretation: the “or” in this claim interpreted as a Markush group, thus the reference needs only disclose at least one group member to address the claim.}.
As per claim 6, the rejection of claim 1 is incorporated and Huilgol discloses wherein the first and the second I/O interfaces are each configured as a Media Access Control, MAC, interface {see Fig. 1, “data plane 103 includes multiple receive media access controllers (MACs) (RX MAC) 111 and multiple transmit MACs (TX MAC) 110”, [0045], 1st sentence}.
As per claim 7, the rejection of claim 1 is incorporated and Huilgol discloses wherein the CPU comprises a translator and inspector software block connected to the software circuitry {see Fig. 4, “deep packet inspection” [0061], 1st sentence} and configured to inspect a state of data {“receive packets from the control plane via a control plane packet input 112” ([0047]) including data state “PCIe state data can include memory mapping data” (see Fig. 14b, [0110], 3rd sentence)} received from the software circuitry and receive pre-filtered data from the software filter chain {see Fig. 3, “If no match is found in the lookup table, then a [pre-filtered] default action 311 may be implemented.” [0058], last three sentences} and translate between different protocols of the data received {see Fig. 5, “A configurable NIC, such as a NIC with a programmable packet processing pipeline can easily translate”, [0080]}.
As per claim 8, the rejection of claim 1 is incorporated and Huilgol discloses wherein the CPU comprises a control and monitoring software block {“hypervisor acting as an [control and monitoring] intermediary can be a bottleneck slowing down the communications”, [0036]} configured to communicate only with the second I/O interface of the programmable hardware device {“VMs can access the network using a VF that is [communication only] uniquely associated with the VM”, [0036], last two sentences} connected to the trusted domain {see Fig. 1, “data plane” acting as trusted domain performing “packet processing operations related to [security] encryption, decryption, compression, decompression, firewalling, and telemetry” [0040], last sentence}.
As per claim 9, the rejection of claim 1 is incorporated and Huilgol discloses wherein the software circuitry is configured as a buffer memory frames {“packet processed by the parser may be placed in a packet buffer/traffic manager for scheduling and possible replication”, see Fig. 1 [0049]} to perform an exchange of data with the CPU {see Fig. 1, “also receive packets from the control plane via a control plane packet input 112” [0047]}.
Referring to claim 11 is a method claim reciting claim functionality corresponding to the apparatus claim of claims 1-9, respectively, thereby rejected under the same rationale as claims 1-9 recited above.
Claims 10 is rejected 35 U.S.C. 103 as being unpatentable over HUILGOL in view of Guim Bernat and further in view of Wiegman (USPGPUB No. 2023/0084918 A1).
As per claim 10, the rejection of claim 1 is incorporated and Huilgol discloses a filter device {“filtering… and policing”, see Fig. 1 [0042], last two sentences} according to claim 1 connected to the trusted domain of the system {“interconnect may distribute memory transactions across a plurality of memory interfaces using a programmable hash algorithm” and the appropriate “P4” domain and system associated with hash, see Fig. 1 [0068, last three sentences};
However neither Huilgol or Guim Bernat appears to explicitly disclose a computer system for an aircraft, comprising:
a trusted domain,
an untrusted domain, and
a filter device according to claim 1 connected to the trusted domain and untrusted domain of the aircraft.
However, Wiegman discloses a computer system for an aircraft, comprising:
a trusted domain {see Fig. 10, “Trusted Platform Module (TPM)”, [0131]},
an untrusted domain {see Fig. 7, outside of “use of hashing algorithms for ‘tamper-proofing’ data” (see Fig. 7, [0089], 2nd sentence) such as those outside “recorder database 128 may include a black box .” (see Fig. 1, [0054])}, and
a filter device connected {“vehicle data may be uploaded from recorder database 128 to an online network such as network 116 or another device via Bluetooth connection” (see Fig. 1, [0054]) that later filtered “vehicle data is [filtered] processed on the network. For example and without limitation, [filtered] processed flight data from the online network is received. The device may display [filtered] processed vehicle data via an application installed on second device 144 such as a user device”, see Fig. 1, [0054]} to the trusted domain and untrusted domain of the aircraft {“[trusted domain] recorder database 128 may include a black box or flight data recording (FDR) device.” see Fig. 1, [0054]}.
HUILGOL/Guim Bernat and Wiegman are analogous because they are from the same field of endeavor, routing packet stream(s).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of HUILGOL/Guim Bernat and Weigman before him or her, to modify HUILGOL/Guim Bernat’s system incorporating Weigman’s “computing device 112” and respective “recorder database 128” (see Fig. 1, [0052]).
The suggestion/motivation for doing so would have been to implement can be stored in an encrypted database and/or black box that may contain valuable data regarding the aircraft and its operating status (Wiegman [0023], last two sentences) in an environment volatility of reliable connection may pose greater risk to the safe transfer of valuable information through a volatile network (Wiegman [0002] paraphrased).
Therefore, it would have been obvious to combine Weigman with HUILGOL/Guim Bernat to obtain the invention as specified in the instant claim(s).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following references are indicative the current state of the art regarding claim 1’s “hardware programmable device”, “filter device”, or “first I/O interface”: US 20210042254 A1, US 20220045945 A1, US 20230084918 A1, US 20230206329 A1, and US 20230419277.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER A. BARTELS whose telephone number is (571)270-3182. The examiner can normally be reached on Monday-Friday 9:00a-5:30pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Dr. Henry Tsai can be reached on 571-272-4176. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C. B./
Examiner, Art Unit 2184
/STEVEN G SNYDER/ Primary Examiner, Art Unit 2184
Prosecution Insights