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 .
DETAILED ACTION
1. This action is responsive to communication filed on: 18 November 2025 with acknowledgement of an original application filed on 21 July 22 April 2023 and that this application has a provisional application filed on 22 April 2022.
2. 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 18 November 2025 has been entered.
3. Claims 1-20 are currently pending. Claim 1 is an independent claim. Claim 1 has been amended.
Affidavit
4. The Affidavit under 37 CFR 1.132 filed 18 November 2025 is insufficient to overcome the rejection of claim 15 based upon 35 U.S.C. 112 (a), first paragraph; lack of utility and/or inoperativeness as set forth in the Office action below, because: claim 15 states “The cross-domain solution architecture of claim 1, the microkernel employing a protection model that (i) includes a grant rule, a remove rule, create rule and (ii) does not include a take rule.” Based upon Applicant’s affidavit filed 18 November 2025, the take rule:
PNG
media_image1.png
184
808
media_image1.png
Greyscale
PNG
media_image2.png
328
866
media_image2.png
Greyscale
The Examiner notes, this definition is vague, in addition the use of the term “take rule” in claim 15 is a negative limitation. It is strongly recommended this claim be deleted. Based on the Applicant’s own affidavit, the Applicants are attempting to claim a negative limitation of elements of a programing model.
5. The Affidavit under 37 CFR 1.132 filed 18 November 2025 is sufficient to overcome the rejection of claims 1-14 and 16-20 based upon the affidavit’s explanation of “formally verified” and “MapReduce”.
Response to Arguments
6. Applicant's arguments filed 18 November 2025 have been fully considered however they are not persuasive when noted below. The Examiner has removed the 112 rejections of claim 1-14 and 16-20 due to amendments, arguments, and affidavit.
I) In response to Applicant’s argument beginning on page 6, “claim 15 The rejection of claim …states that the term take rule is not clearly defined in the specification…The meaning of the term is unclear and indefinite…Applicant respectfully disagrees at least because take rule is a term of art, as explained in the Inventor Declaration under 37 CFR 1.132 filed with this response. Accordingly, the term take rule as recited by claim 15 is well understood by one of…”
The Examiner disagrees with argument. As explained above the use of the term “take rule” is vague. According to the affidavit the "take rule is used with its ordinary meaning in the context of the Take-Grant protection model used in computer security…Take Subject s that take right to entity e underscores the fact that s can assume any right that e has to other entities such as protected objects”. In addition, the use of the term is a negative limitation, claim 15 states: “and does not include a take rule”. Independent Claim 1, from which claim 15 depends is directed to “A cross-domain solution architecture, comprising a software layer including a higher-security domain that processes data …”. Nowhere in independent claim 1, or claim 15 references an “entity” or “protected objects”. It is strongly recommended the claim be deleted.
II) In response to applicant’s argument beginning on page 7, “Claims 1,2, 10, and 18-20 stand rejected under 35 U.S.C. 103 as allegedly being unpatentable over U.S. Patent Application Publication No. 2017/0048259 to Dodge et al (hereinafter “Dodge”) in view of U.S. Patent Application Publication No. 2020/0099658 to Graham et al. (hereinafter “Graham”) in further view of U.S. Patent Application Publication No. 2020/0099658 to Couillard et al. (hereinafter “Couillard”). Applicant respectfully traverses these rejections for at least the following reasons.
Claim 1 The rejection alleges that It would have been obvious to …to include a means to utilize a first and second diode to transfer data between security domains. (Office Action, p. 7.) Applicant respectfully disagrees because Dodge already discloses “means to utilize a first and second diode to transfer data between security domains.” For example, Dodge’s system 100…(Dodge, ¶ [0008]) Since the rejection’s motivation to modify Dodge in view of the alleged teachings of Couillard is to “include a means to utilize a first and second diode to transfer data between security domains,” which Dodge already does, the motivation cited by the examiner is insufficient to establish an obvious reason to modify Dodge”
The Examiner disagrees with argument. As indicated in the previous Office Action as well as below: Although ‘259 clearly teaches a first and second data diode that transfer data in one direction in paragraphs 23-25, since it has been argued (by the Applicant’s Representative on 23 May 2025, see pages 7-8 of arguments) that the data diode claimed are not located in the higher-security domain, and the art does not teach a trusted computing base (TCB) that contains data diodes it could be stated the following is not explicitly taught in ‘259 and ‘849:
“a trusted computing base (TCB) that includes …and (ii) includes a first data diode, and a second data diode, and (ii) passes data from the lower-security domain to the higher-security domain through a first data diode, and to pass data from the higher-security domain to the lower-security domain through a second data diode” however ‘658 teaches passing data between security domains using separate diodes that are used in a trusted computing base, note SPA, security processing appliance as well as TCF, Trusted Comparator Function, as well as trusted network, in paragraphs 149, 151, 154, and 157.
It would have been obvious to one of ordinary skill in the art before the effective filing date of a secure cross domain solution systems and methods taught in ‘259 and ‘849 to include a means to utilize a first and second diode to transfer data between security domains. One of ordinary skill in the art would have been motivated to perform such a modification because a need exists for an integrated multi-level or cross-domain network security appliance …that overcomes the drawbacks of known techniques see ‘658 paragraphs 2-7. Therefore Applicant’s argument is not persuasive.
III) In response to applicant’s argument beginning on page 9, “Claim 15 benefits from additional arguments of patentability. Claim 15 requires the microkernel employ “a protection model that (i) includes a grant rule, a remove rule, a create rule and (ii) does not include a take rule”. The rejection of claim 15 alleges that Ghose paragraph 124 discloses claim 15. Applicant respectfully disagrees. The cited part of Ghose concerns a tag processing unit that “enforces specific restrictions with respect of at least execution of instructions, access to resources, and manipulation of data by an instruction execution.” Ghose does state that this tag processing unit is part of a microkernel. Even if Ghose did disclose this, Ghose does not disclose that the tag processing unit employs “a protection mode that (i) includes a grant rule, a remove rule, a create rule,” as required by claim `. Rather, paragraph 124 states that the tag processing unit “may ensure compliance” with several rules listed in paragraph 124. None of these rules qualify as the rules of claim 15.
The Examiner disagrees with argument for multiple reasons. First in the above argument the Applicant’s representative has argued that Ghose/’888 the tag processing unit is not a microkernel. The Examiner notes a microkernel, is known in the art to mean the minimum amount of software that can execute the mechanisms needed to implement an operating system. In addition, the microkernel may be the only software executing at the most privilege level, i.e. supervisor or kernel mode. To specifically teach the term “microkernel”, the below rejection relies on Graham/’849, see the Abstract, paragraphs 19 and 80. However, the Ghose/’888 reference clearly teaches/suggests that the tagging is associated with kernel, see paragraphs 9, 27, 102, and 113. Claim 15 states “the microkernel employing a protection model that (i) includes a grant rule, a remove rule, a create rule and (ii) does not include a take rule”. The Examiner interprets this limitation to the specific restriction and rules described in paragraph 124, which include “access to resources” (i.e. protected objects) as well as restrictions on the use of data or context-specific data usage; source-dependent data usage rules, as well as rule transfer instruction rules. Therefore, the Applicant’s argument is not persuasive.
Claim Rejections - 35 USC § 112
7. The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
8. Claim 15 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention. The claim uses the phrase “and (ii) does not include a take rule”, according to Applicant’s affidavit a take rule is used in the context of the Take-Grant protection model…which can be summarized as…Take Subject s that has take right entity e underscores the fact that s can assume any right that e has to other entities such as protected objects”. As explained above this definition is vague in addition the independent claim as well as claim 15 itself does not make any reference to an “entity” or “protected objects”. Appropriate Correction is required.
9. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
10. Claim 15 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. As explained above claim 15 uses the phrase “does not include a take rule”. The specification as well as the claims do not provide an understanding of the phrase and what is meant by its use in terms of the claimed invention. Therefore, the claim is also indefinite. Appropriate Correction is required.
11. To expedite a complete examination of the instant application the claims rejected under 35 U.S.C. 101 (nonstatutory) as well as 35 U.S.C. 112 above are further rejected as set forth below in anticipation of applicant amending these claims to overcome the above rejections.
Claim Rejections – 35 USC § 103
12. 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.
13. Claims 1-2, and 18-20, are rejected under 35 U.S.C. 103 as being unpatentable over Dodge et al. U.S. Patent Application Publication No. 2017/0048259 (hereinafter ‘259) in view of Graham et al. U.S. Patent Application Publication No. 2013/0151849 (hereinafter ‘849) in further view of Couillard et al. U.S. Patent Application Publication No. 2020/0099658 (hereinafter ‘658).
As to independent claim 1, “A cross-domain solution architecture, comprising: a software layer including (i) a higher-security domain that (i) processes data on a higher-security level and (ii) a lower-security domain that processes data on a lower-security level having lower security than the higher-security level” is taught in ‘259 paragraphs 9 and 35;
the following is not explicitly taught in ‘259:
“a trusted computing base (TCB) that (i) includes a formally verified microkernel” however ‘849 teaches using a verified microkernel and microkernel-based security architectures as well as a trusted computing base in the Abstract, paragraphs 19 and 80;
It would have been obvious to one of ordinary skill in the art before the effective filing date of a secure cross domain solution systems and methods taught in ‘259 to include a means to utilize a verified microkernel. One of ordinary skill in the art would have been motivated to perform such a modification to protect devices from cyberattacks see ‘849 paragraphs 9-19.
Although ‘259 clearly teaches a first and second data diode that transfer data in one direction in paragraphs 23-25, since it has been argued since it has been argued (by the Applicant’s Representative on 23 May 2025, see pages 7-8 of arguments) that the data diode claimed are not located in the higher-security domain, and the art does not teach a trusted computing base (TCB) that contains data diodes it could be stated the following is not explicitly taught in ‘259 and ‘849:
“a trusted computing base (TCB) that includes …and (ii) includes a first data diode, and a second data diode, and (ii) passes data from the lower-security domain to the higher-security domain through a first data diode, and to pass data from the higher-security domain to the lower-security domain through a second data diode” however ‘658 teaches passing data between security domains using separate diodes that are used in a trusted computing base, note SPA, security processing appliance as well as TCF, Trusted Comparator Function, as well as trusted network, in paragraphs 149, 151, 154, and 157.
It would have been obvious to one of ordinary skill in the art before the effective filing date of a secure cross domain solution systems and methods taught in ‘259 and ‘849 to include a means to utilize a first and second diode to transfer data between security domains. One of ordinary skill in the art would have been motivated to perform such a modification because a need exists for an integrated multi-level or cross-domain network security appliance …that overcomes the drawbacks of known techniques see ‘658 paragraphs 2-7.
As to dependent claim 2, “The cross-domain solution architecture of claim 1, the higher-security domain further including a guard that analyzes content of the data and determines whether the data are in accordance with a system security policy” is taught in ‘259 paragraphs 13 and 24.
As to dependent claim 18, “A coprocessor implemented as a cross-domain solution (CDS) comprising: the cross-domain solution architecture of claim 1; a host processor operating at the lower-security level and including an additional TCB; and a bidirectional bus architecture that communicatively couples the cross-domain solution architecture to the host processor” is shown in ‘259 paragraph 35, note the method can be implemented on compute device or server (which are. host processors).
As to dependent claim 19, “The cross-domain solution architecture of claim 1, comprising: a hardware-layer comprising (i) hardware that executes the lower-security domain, (ii) a CPU that processes data for both the lower-security domain and the higher-security domain, and (iii) a trusted execution environment (TEE) that enables secure memory computations for the higher-security domain” is disclosed in ‘849 the Abstract, paragraphs 19, and 80.
As to dependent claim 20, “The cross-domain solution architecture of claim 1, each of the first data diode and the second data diode being formally verified” is taught in ‘658 paragraphs 84-86 and 141, note “trusted data guard functionality”.
14. Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Dodge et al. U.S. Patent Application Publication No. 2017/0048259 (hereinafter ‘259) in view of Graham et al. U.S. Patent Application Publication No. 2013/0151849 (hereinafter ‘849) in further view ow Couillard et al. U.S. Patent Application Publication No. 2020/0099658 (hereinafter ‘658) in further view of Clarke et al. U.S. Patent Application Publication No. 2014/0139737 (hereinafter ‘737).
As to dependent claim 3, the following is not explicitly taught in ‘259, ‘658, and ‘849: “The cross-domain solution architecture of claim 1, the lower-security domain further including a network interface card, and electrically coupled thereto, a packet bridge that receives the data via the network interface card” however ‘737 teaches data transfer using network interface cards (NICs) to transfer packets in paragraphs 4 and 24-26.
It would have been obvious to one of ordinary skill in the art before the effective filing date of a secure cross domain solution systems and methods taught in ‘259, ‘658, and ‘849 to include a means to utilize network interface card and a packet bridge. One of ordinary skill in the art would have been motivated to perform such a modification to enhance the ability to filter packets and content transferred between domains and ensure the security policies are violated with the content transfer see ‘737 paragraphs 2-6.
15. Claims 4-9 are rejected under 35 U.S.C. 103 as being unpatentable over Dodge et al. U.S. Patent Application Publication No. 2017/0048259 (hereinafter ‘259) in view of Graham et al. U.S. Patent Application Publication No. 2013/0151849 (hereinafter ‘849) in further view of Couillard et al. U.S. Patent Application Publication No. 2020/0099658 (hereinafter ‘658) in further view of Clarke et al. U.S. Patent Application Publication No. 2014/0139737 (hereinafter ‘737) in further view of Ghose U.S. Patent Application Publication No. 2020/0159888 (hereinafter ‘888).
As to dependent claim 4, the following is not explicitly taught in ‘259, ‘658, ‘737 and ‘849: “The cross-domain solution architecture of claim 3, the lower-security domain further including an integrity tagger that (i) is electrically connected to the packet bridge and (ii) calculates a tag to securely and accurately identify the data and ensure that the data have not been modified” however ‘888 teaches a tag processing unit that enforces specific restrictions with respect to data manipulation and memory access rules in paragraph 124.
It would have been obvious to one of ordinary skill in the art before the effective filing date of a secure cross domain solution systems and methods taught in ‘259, ‘658, ‘737, and ‘849 to include a means to utilize an integrity tagger to ensure data has not been modified. One of ordinary skill in the art would have been motivated to perform such a modification to improve upon the existing security-tagged architecture to enforce data type compliance but to also context-specific legal uses of both data and instructions and detect software vulnerabilities and weaknesses that lead to security violations see ‘888 paragraphs 19-22.
As to dependent claim 5, “The cross-domain solution architecture of claim 4, the higher-security domain including an intrusion detection system communicatively coupled to the integrity tagger via a unidirectional communication channel that traverses the TCB” is taught in ‘888 paragraphs 19-21.
As to dependent claim 6, “The cross-domain solution architecture of claim 5, the unidirectional communication channel including a data diode” is shown in ‘259 paragraph 23.
As to dependent claim 7, “The cross-domain solution architecture of claim 5, the higher-security domain further including a guard that analyzes content of the data and determines whether the data are in accordance with a system security policy” is disclosed in ‘259 paragraphs 13 and 24.
As to dependent claim 8, “The cross-domain solution architecture of claim 7, the guard including an integrity checker that audits the tag computed by the integrity tagger” is taught in ‘259 paragraphs 24-27.
As to dependent claim 9, “The cross-domain solution architecture of claim 8, further comprising an additional unidirectional channel between the integrity checker and the lower-security domain, the guard further including, on the additional unidirectional channel, a disposition guard that filters packets received from the integrity checker” is shown in ‘259 paragraphs 24-27.
16. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Dodge et al. U.S. Patent Application Publication No. 2017/0048259 (hereinafter ‘259) in view of Graham et al. U.S. Patent Application Publication No. 2013/0151849 (hereinafter ‘849) in further view ow Couillard et al. U.S. Patent Application Publication No. 2020/0099658 (hereinafter ‘658) in further view of Lee et al. U.S. Patent Application Publication No. 2019/0114200 (hereinafter ‘200).
As to dependent claim 10, the following is not explicitly taught in ‘259, 849, and ‘658: “A cross-domain solution architecture of claim 1, wherein the first data diode communicates with the lower-security domain through a MapReduce file system, and the higher-security domain receives data from the first data diode using a MapReduce process” however ‘200 teaches another embodiments of engines, (i.e. cross-domain workflow engines) running may be linked or include various software programs or processing frameworks such as MapReduce in paragraphs 13 and 83.
It would have been obvious to one of ordinary skill in the art before the effective filing date of a secure cross domain solution systems and methods taught in ‘259, ‘658, and ‘849 to include a means to utilize a MapReduce process. One of ordinary skill in the art would have been motivated to perform such a modification because there is a need to design a workflow for the emerging big data analysis to integrate domains for insightful analysis and create a unified system capable of being easily adapted to be applied to another domain see ‘200 paragraphs 3-7.
17. Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Dodge et al. U.S. Patent Application Publication No. 2017/0048259 (hereinafter ‘259) in view of Graham et al. U.S. Patent Application Publication No. 2013/0151849 (hereinafter ‘849) in further view of Couillard et al. U.S. Patent Application Publication No. 2020/0099658 (hereinafter ‘658) in further view of Agrawal et al. U.S. Patent Application Publication No. 20006/0248592 (hereinafter ‘592).
As to dependent claim 11, the following is not explicitly taught in ‘259, ‘658, and ‘849: “The cross-domain solution architecture of claim 10, wherein the higher-security domain further comprises a guard configured for a TCB process containing an obfuscation function” however ‘592 teaches masking data at the individual cell level to enforce privacy semantics in the Abstract and paragraph 12.
It would have been obvious to one of ordinary skill in the art before the effective filing date of a secure cross domain solution systems and methods taught in ‘259, ‘658, and ‘849 to include an obfuscation function. One of ordinary skill in the art would have been motivated to perform such a modification to preserve data privacy see ‘592 paragraphs 2-7.
As to dependent claim 12, “The cross-domain solution architecture of claim 11 in which the obfuscation function polyinstantiates the data” is taught in ‘592 Abstract, paragraphs 7, 9, and 12.
18. Claims 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over Dodge et al. U.S. Patent Application Publication No. 2017/0048259 (hereinafter ‘259) in view of Graham et al. U.S. Patent Application Publication No. 2013/0151849 (hereinafter ‘849) in further view of Couillard et al. U.S. Patent Application Publication No. 2020/0099658 (hereinafter ‘658) in further view of Ghose U.S. Patent Application Publication No. 2020/0159888 (hereinafter ‘888).
As to dependent claim 13, the following is not explicitly taught in ‘259, ‘658, and ‘849: “The cross-domain solution architecture of claim 1, the lower-security domain including a first domain component, the higher-security domain including a second domain component that is isolated from the first domain component” however ‘888 teaches isolating domains from each other in paragraphs 85-90.
It would have been obvious to one of ordinary skill in the art before the effective filing date of a secure cross domain solution systems and methods taught in ‘259, ‘658, and ‘849 to include a means to isolate domain components. One of ordinary skill in the art would have been motivated to perform such a modification to improve upon the existing security-tagged architecture to enforce data type compliance but to also context-specific legal uses of both data and instructions and detect software vulnerabilities and weaknesses that lead to security violations see ‘888 paragraphs 19-22.
As to dependent claim 14, “The cross-domain solution architecture of claim 1, the microkernel being configured to operate with memory encryption” is taught in ‘888 paragraph 24.
As to dependent claim 15, “The cross-domain solution architecture of claim 1, the microkernel employing a protection model that (i) includes a grant rule, a remove rule, a create rule and (ii) does not include a take rule” is shown in ‘888 paragraph 124.
As to dependent claim 16, “The cross-domain solution architecture of claim 1, wherein an access control model component of the microkernel is an immutable object reference” is disclosed in ‘888 paragraphs 62.
As to dependent claim 17, “The cross-domain solution architecture of claim 1, wherein an access control model component of the microkernel enforces the principle of least privilege” is taught in ‘888 paragraph 23.
Conclusion
19. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELLEN C TRAN whose telephone number is (571) 272-3842. The examiner can normally be reached Monday-Friday.
Examiner interviews are available via telephone 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, Jeff Pwu can be reached at 571-272-6798. 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.
/ELLEN TRAN/Primary Examiner, Art Unit 2433 12 January 2026