DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/11/2026 has been entered.
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 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 of this title, 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-6 and 8-25 are rejected under 35 U.S.C. 103 as being unpatentable over Lakshman et al. (U.S. Publication 2020/0320017), hereinafter Lakshman in view of Wash (U.S. 2019/0037406), hereinafter Wash further in view of Atamli et al. (U.S. Publication 2023/0297666), hereinafter Atamli.
Referring to claim 1, Lakshman teaches, as claimed, an apparatus comprising:
a processor (see Fig. 1, Processor 125(1)) to execute one or more software clients (see Fig. 1, APP 120(1)); and
a hardware (see Fig. 1, Network Interface Card 118) accelerator (network interface card 118 could be... a specialized interface which performs and accelerates a specific protocol, see Paragraph 21) coupled to the processor, the hardware accelerator comprising an assignable interface (initializing the network interface at the PCI-E level… with assignable interfaces, see Paragraph 17) to receive a work (Work Queues, see Paragraph 13) request with a tag (PASIDs, see Paragraphs 13 and 17; and A PASID is a unique identifier … are tagged with a PASID, see Paragraph 27) from the one or more software clients;
wherein the hardware accelerator is to, in response to receiving the work request, process the work request based at least in part on a configuration (configured to run, see Paragraph 21) of the assignable interface and a value of the tag (tagged with a PASID value, see Paragraph 27).
Lakshman does not expressly disclose a single bit tag from the one or more software, wherein the tag is to indicate whether the work request originated from a trusted software logic or an untrusted software logic.
Wash does disclose a single bit tag (see Fig. 1, Is it Safe?; Note, yes or no is a binary determination, hence ‘a single bit’) from the one or more software, wherein the tag is to indicate whether the work request originated from a trusted software logic (see Fig. 1, Yes – Display Web Content) or an untrusted software logic (see Fig. 1, No – HTTP redirect to warning page).
At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate a single bit tag into Lakshman’s reserved or unused flag in PASID_info_table (see Lakshman, Paragraph 67; Note, any of the reserved unit or flag position could be at least 1 bit and value would be ‘one’ or ‘zero’ that could added to most significant bit of 20+1 wide PASID).
The suggestion/motivation for doing so would have been to provide very concise (i.e. just using one bit to answer yes or no question) safe environment for data processing.
Lakshman/Wash does not expressly disclose a trusted software entity or an untrusted software entity.
Atamli does disclose a Trusted Execution Environment (TEE) mode (see Fig. 1, Trusted Execution Environment 132A) that determines a trusted software entity (trusted memory area, see Paragraph 78) or an untrusted software entity (untrusted area, see Paragraph 78).
At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate Atamli into Lakshman/Wash.
The suggestion/motivation for doing so would have been to provide data security priority where data sharing and resource partitioning would implicitly trigger resource sharing conflict.
Referring to claim 2, Lakshman teaches, as claimed, the apparatus of claim 1, wherein the configuration of the assignable interface is to include an environment.
Lakshman does not disclose expressly to include a Trusted Execution Environment (TEE) mode.
Atamli does disclose to include a Trusted Execution Environment (TEE) mode (see Fig. 1, Trusted Execution Environment 132A).
At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate Atamli into Lakshman.
The suggestion/motivation for doing so would have been to provide data security priority where data sharing and resource partitioning would implicitly trigger resource sharing conflict.
As to claim 3, the modification teaches the apparatus of claim 2, wherein the tag value (tagged with a PASID value, see Lakshman Paragraph 27) of the work request is to indicate whether the work request originated from a trusted software entity (see Atamli Fig. 1, Trusted Execution Environment 132A), wherein the trusted software entity corresponds to one of: a TEE application (see Atamli Fig. 1, App), a TEE driver, a TEE operating system, a TEE container, a TEE virtual machine (see Atamli Fig. 1, VM), or a TEE security manager (see Atamli Fig. 1, Security App 135Z).
As to claim 4, the modification teaches the apparatus of claim 3, wherein the hardware accelerator is to reject the work request (see Wash, Fig. 1, HTTP Redirect to Warning Page; Note, identified content has been labelled and flagged unsafe therefore it is rejected) based at least in part on a determination that the TEE mode is disabled (see Wash, Fig. 1, Is it Safe? No) for the assignable interface.
As to claim 5, the modification teaches the apparatus of claim 1, wherein the hardware accelerator is to support a state machine (see Lakshman Fig. 3; Note, a computer is a state machine and Fig. 3 show various states going from one to another) for management of the assignable interface.
As to claim 6, the modification teaches the apparatus of claim 5, wherein the state machine is to transition between one or more states selected from a group comprising: interface disabled, interface configured (see Lakshman Fig. 3, Configure PASID for a given queue), interface enabled, and interface halted.
As to claim 8, the modification teaches the apparatus of claim 6, wherein the hardware accelerator is to reject the work request in response to a determination that a state of the assignable interface is different from the interface enabled state (see Wash, Fig. 1, Is it Safe? No; Note, No is different from Yes).
As to claim 9, the modification teaches the apparatus of claim 6, wherein the state machine is to transition to interface halted (blocked, see Wash Paragraph 27) state based on an event from a group comprising: configuration change, interface reset, and interface error (warning, see Wash, Paragraph 27) .
As to claim 10, the modification teaches the apparatus of claim 5, wherein the state machine is to transition between one or more states based on a command from a group comprising: lock interface, enable interface (see Wash, Fig. 1, Is it Safe? Yes), disable interface (see Wash, Fig. 1, Is it Safe? No), and reset interface.
As to claim 11, Lakshman teaches the apparatus of claim 1, wherein a configuration interface of the accelerator is to receive a command (see Lakshman Fig. 3, Request PASID) from the one or more software entities with the tag.
As to claim 12, the modification teaches the apparatus of claim 11 wherein the trusted software entity comprises one of: a TEE application, a TEE driver, a TEE operating system, a TEE container, a TEE virtual machine, and a TEE security manager, and wherein the untrusted software entity comprises one of: an application, a driver, an operating system, a container, a virtual machine, or a virtual machine monitor.
As to claim 13, the modification teaches the apparatus of claim 11, wherein the hardware accelerator is to reject the command in response to a determination that a TEE mode is enabled and the software entity is an untrusted software entity.
As to claim 14, the modification teaches the apparatus of claim 1, wherein the one or more software entities comprise one of: an application, a driver, an operating system (see Atamli Fig. 1, Operating System 126A to Z), a container, a virtual machine, a virtual machine monitor, a TEE application (see Atamli Fig. 1, App 133A), a TEE driver, a TEE operating system, a TEE container (see Atamli Fig. 1, Container 133A), a TEE virtual machine (see Atamli Fig. 1, VM 133A), and a TEE security manager (see Atamli Fig. 1, Security App 135Z).
As to claim 15, the modification teaches the apparatus of claim 1, wherein the assignable interface comprises one of: a dedicated work queue (see Lakshman Fig. 2, Work Queue), a shared work queue, a transmission/reception (Tx/Rx) queue, or a command queue.
As to claim 16, the modification teaches the apparatus of claim 1, wherein the assignable interface comprises one of: a Peripheral Component Interconnect express (PCIe) (PCI-E, see Lakshman Paragraph 21) or a Compute Express Link (CXL) physical function, a PCIe/CXL Single Root Input/Output Virtualization (SR-IOV) virtual function, and a Scalable Input/Output (I/O) Virtualization Assignable Device Interface (Scalable IOV ADI).
As to claim 17, the modification teaches the apparatus of claim 1, wherein the hardware accelerator is to tag a Direct Memory Access (DMA) (see Lakshman Fig. 1, DMA Remapping Hardware 130) request based at least in part on the tag value of the work request.
As to claim 18, the modification teaches the apparatus of claim 1, wherein the tag comprises a single bit (PASID is 20-bit identifier, see Lakshman Paragraph 27; Note, 20-bit comprises at least a single bit).
As to claim 19, the modification teaches the apparatus of claim 1, wherein the hardware accelerator is to support one or more: data movement (to move the data back and forth, see Lakshman Paragraph 14) or data transformation operations.
As to claim 20, the modification teaches the apparatus of claim 19, wherein the one or more data movement or data transformation operations comprise one or more of: a memory move operation (DMA transaction, see Lakshman Paragraph 27), a Cyclic Redundancy Code (CRC) operation, a Data Integrity Field (DIF) operation, a dual-cast operation, a memory fill operation, a memory compare operation, a delta record create or merge operation, a pattern detect operation, a cache flush operation, a scatter-gather operation, a data reduction operation, a memory compression or decompression operation, a scan operation, a filter operation, a select operation, a data compression or decompression operation, one or more cryptographic operations, and one or more public-key exchange operations.
Referring to claim 21, Lakshman teaches, as claimed, an apparatus comprising:
circuitry to provide an interface (initializing the network interface at the PCI-E level… with assignable interfaces, see Paragraph 17) to a host entity (see Fig. 1, Processor 125(1)) to cause assignment of a resource (see Fig. 1, Network Interface Card 118) to an entity (see Fig. 1, APP 120(1)) based at least in part on a value (PASIDs, see Paragraphs 13 and 17; and A PASID is a unique identifier … are tagged with a PASID, see Paragraph 27) of a tag (tagged with a PASID value, see Paragraph 27); and
work queue (Work Queues, see Paragraph 13) configuration circuitry (configured to run, see Paragraph 21) to configure one or more work queues of a hardware accelerator (network interface card 118 could be .. a specialized interface which performs and accelerates a specific protocol, see Paragraph 21).
Lakshman does not expressly disclose a single bit tag from the one or more software, wherein the tag is to indicate whether the work request originated from a trusted software logic or an untrusted software logic.
Wash does disclose a single bit tag (see Fig. 1, Is it Safe?; Note, yes or no is a binary determination, hence ‘a single bit’) from the one or more software, wherein the tag is to indicate whether the work request originated from a trusted software logic (see Fig. 1, Yes – Display Web Content) or an untrusted software logic (see Fig. 1, No – HTTP redirect to warning page).
At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate a single bit tag into Lakshman’s reserved or unused flag in PASID_info_table (see Lakshman, Paragraph 67; Note, any of the reserved unit or flag position could be at least 1 bit and value would be ‘one’ or ‘zero’ that could added to most significant bit of 20+1 wide PASID).
The suggestion/motivation for doing so would have been to provide very concise (i.e. just using one bit to answer yes or no question) safe environment for data processing.
Lakshman/Wash does not disclose expressly a security manager and an assignment of resource to a trusted entity.
Atamli does disclose a security manager (see Fig. 1, Security App 135Z) and an assignment of resource to a trusted entity (see Fig. 1, Trusted Execution Environment 132A).
At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate Atamli into Lakshman/Wash.
The suggestion/motivation for doing so would have been to provide data security priority where data sharing and resource partitioning would implicitly trigger resource sharing conflict.
As to claim 22, the modification teaches the apparatus of claim 21, wherein the work queue (Work Queues, see Lakshman Paragraph 10) configuration (see Lakshman Fig. 3, Configure PASID for a given queue) logic circuitry is to support a state machine (see Fig. 3; Note, a computer is a state machine and Fig. 3 show various states going from one to another) for management of the one or more work queues.
As to claim 23, the modification teaches the apparatus of claim 22, wherein the state machine is to transition between one or more states selected from a group comprising: work queue disabled, work queue configured (see Lakshman Fig. 3, Configure PASID for a given queue), work queue enabled, and work queue halted.
As to claim 24, the modification teaches the apparatus of claim 21, wherein the host entity is untrusted (see Atamli, Fig. 1; Note, any area outside of the dotted box are untrusted entity).
As to claim 25, the modification teaches the apparatus of claim 21, wherein the trusted entity comprises a Trusted Execution Environment (TEE) Virtual Machine (TVM) (see Atamli Fig. 1, VM 133A).
Allowable Subject Matter
Claim 7 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed 5/11/2026 have been fully considered but they are not deemed to be persuasive.
Applicant argues, Because Wash is from a disparate field of endeavor and is not reasonably pertinent to the problem of hardware accelerator queue management, it constitutes non-analogous art and should be excluded from the combination.
Examiner disagrees with applicant. In response to applicant's argument that Wash is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, Wash used a single bit to test for safe or unsafe state which is pertinent to testing for trusted or untrusted state of Instant Invention.
Applicant argues, The Examiner proposes to "incorporate a single bit tag into Lakshman PASID identification" to provide a "concise... safe environment." However, Lakshman explicitly relies on its 20-bit PASID to isolate the process address space for Direct Memory Access (DMA) translation across potentially thousands of virtual machines or containers (Lakshman, paragraphs [0027]-[0028]). Modifying Lakshman's 20-bit architecture to utilize a single-bit tag (such as Wash's Yes/No URL safety flag) would critically restrict the system to only two address spaces. Such a modification would completely destroy Lakshman's explicitly stated goal of scaling network interface cards to support thousands of hosts. Under MPEP 2143.01(V), a proposed modification cannot support an obviousness rejection if it would render the prior art reference unsatisfactory for its intended purpose.
Examiner disagrees with applicant. The modification of Laskshman with Wash requires adding 1 more bit to 20 bits unique identification. The modification does not require replacing 20 bits with 1 bit. For example, 1 reserved bit could be used as an extra flag to determine trusted or untrusted environment.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hyun Nam whose telephone number is (571) 270-1725 and fax number is (571) 270-2725. The examiner can normally be reached on Monday through Friday 8:30 AM to 5:00 PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jyoti Mehta can be reached on (571) 270-3995. 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.
/HYUN NAM/Primary Examiner, Art Unit 2183
Prosecution Insights