DETAILED ACTION
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 .
Claims 1-20 of this US application are presented for examination.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114 was filed in this application after appeal to the Patent Trial and Appeal Board, but prior to a decision on the appeal. 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 appeal has been withdrawn pursuant to 37 CFR 1.114 and prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant’s submission filed on 8/20/2025 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 8/20/2025 and 10/22/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 7-8, 14-16 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Fitzer et al. (US 2020/0320041, hereinafter “Fitzer”) in view of Goyal et al. (US 2018/0239921, hereinafter “Goyal”).
Regarding claim 1, Fitzer teaches A method for securely loading and executing user-defined content on a remote terminal unit (RTU), the RTU comprising an embedded controller and a memory storing a factory default image for the RTU, the factory default image including a default secured read only filesystem, the default secured read only filesystem defining predetermined functionality of the RTU ([0031]: In some example embodiments, the application layers 130A-130D store read-only files for applications. Thus, each of the strategies 530A-530B provides a logical file system that contains read-only application files. [0089] and Fig. 10: discussing about a machine 1000 includes a processor 1002 and a main memory 1004), the method comprising:
creating user-defined content in a development environment for the RTU, the user- defined content comprising extended application content defining extended functionality of the RTU different than the predetermined functionality ([0033]: Each of the user views 560A, 560B, 560C, 560D, and 560E includes a reference to one of the user layers 510A-510E and one of the tenant views 540A-540C. One user view is created for each user of the application server 110. Using a user view, the overlay file system provides a logical file system in which a user layer 510 is overlaid on the logical file system for the underlying tenant.);
executing a development tool to access a developer image for the RTU, the developer image including a read/write filesystem, the read/write filesystem being a developer equivalent of the read only filesystem, the read/write filesystem including the user-defined content ([0034] In some example embodiments, each user has read-write access to the corresponding user layer 510, configurable access to the corresponding tenant layer 520 (e.g., using the permissions field of the user table 310 of FIG. 3), and read-only access to the corresponding strategy. [0055]: Example 4. The method of any of examples 1to 3, wherein the first user identifier has read-write access to the first layer and read-only access to a third layer of the overlay file system.).
Fitzer does not explicitly teach executing, by the embedded controller, an overlay process to overlay the read/write filesystem on top of the read only filesystem to create a merged filesystem, the merged filesystem defining both the predetermined functionality of the RTU and the extended functionality of the RTU based on the user-defined content, the merged filesystem further being writeable; and deploying the merged filesystem to the embedded controller for execution.
Goyal teaches executing, by the embedded controller, an overlay process to overlay the read/write filesystem on top of the read only filesystem to create a merged filesystem, the merged filesystem defining both the predetermined functionality of the RTU and the extended functionality of the RTU based on the user-defined content, the merged filesystem further being writeable; and deploying the merged filesystem to the embedded controller for execution ([0024]: In some implementations, the layers at the overlayfs mount 175 may include more than two layers of overlay files system. Each layer may include one or more directories. Each directory may include files and/or other directories. When the upper and lower layers of the overlay filesystem are merged together at the overlayfs mount 175, the files and directories of the upper and lower layers are present to the applications 160 as belonging to the same filesystem. [0025]: The lower layer, in implementations, is included into the single merged overlayfs mount 175 as read-only, while the upper layer is mounted read-write into overlayfs mount 175 as an overlay on top of the lower layer. [0029]: For example, when the mounter executes a kernel command to mount an overlayfs filesystem, they are permitted to specify a label that will be applied to all files therein.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer with the teaching about the merging filesystem of Goyal because the mounter can add security context labels to the overlay filesystem that makes it accessible to another user or application process (Goyal, [0029]).
Regarding claim 7, Fitzer in view of Goyal teaches executing the overlay process includes hiding an object of the default secured read only filesystem when a corresponding object is present in the read/write filesystem (Goyal [0025]: An overlay directory shows the set union of all corresponding directories in the stack that aren't blocked. New files and directories get stored in the upper layer while read-only access is provided to files in the lower layers. Modifications to files that are otherwise only in the lower layers, cause that file to be copied up to the upper layer and then the changes are applied to the upper layer copy. This then blocks off access to the file in the lower layer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer with the teaching about the merging filesystem of Goyal because the mounter can add security context labels to the overlay filesystem that makes it accessible to another user or application process (Goyal, [0029]).
Regarding claim 8, Fitzer teaches A method for securely loading and executing user-defined content on a remote terminal unit (RTU), the RTU comprising an embedded controller and a memory storing a factory default image for the RTU, the factory default image including a default secured read only filesystem, the default secured read only filesystem defining predetermined functionality of the RTU ([0031]: In some example embodiments, the application layers 130A-130D store read-only files for applications. Thus, each of the strategies 530A-530B provides a logical file system that contains read-only application files. [0089] and Fig. 10: discussing about a machine 1000 includes a processor 1002 and a main memory 1004), the method comprising:
creating user-defined content in a development environment for the RTU, the user- defined content comprising extended application content defining extended functionality of the RTU different than the predetermined functionality ([0033]: Each of the user views 560A, 560B, 560C, 560D, and 560E includes a reference to one of the user layers 510A-510E and one of the tenant views 540A-540C. One user view is created for each user of the application server 110. Using a user view, the overlay file system provides a logical file system in which a user layer 510 is overlaid on the logical file system for the underlying tenant.);
executing a development tool to access a developer image for the RTU, the developer image including a read/write filesystem, the read/write filesystem being a developer equivalent of the read only filesystem, the read/write filesystem including the user-defined content ([0034] In some example embodiments, each user has read-write access to the corresponding user layer 510, configurable access to the corresponding tenant layer 520 (e.g., using the permissions field of the user table 310 of FIG. 3), and read-only access to the corresponding strategy. [0055]: Example 4. The method of any of examples 1to 3, wherein the first user identifier has read-write access to the first layer and read-only access to a third layer of the overlay file system.).
Fitzer does not explicitly teach executing, by the embedded controller, an overlay process to overlay the read/write filesystem on top of the read only filesystem to create a merged filesystem, the merged filesystem defining both the predetermined functionality of the RTU and the extended functionality of the RTU based on the user-defined content, the merged filesystem further being writeable; and deploying the merged filesystem to the embedded controller for execution when authenticity of the created user-defined content is validated and deploying the default secured read only filesystem to the embedded controller for execution when authenticity of the created user-defined content is not validated.
Goyal teaches executing, by the embedded controller, an overlay process to overlay the read/write filesystem on top of the read only filesystem to create a merged filesystem, the merged filesystem defining both the predetermined functionality of the RTU and the extended functionality of the RTU based on the user-defined content, the merged filesystem further being writeable ([0024]: In some implementations, the layers at the overlayfs mount 175 may include more than two layers of overlay files system. Each layer may include one or more directories. Each directory may include files and/or other directories. When the upper and lower layers of the overlay filesystem are merged together at the overlayfs mount 175, the files and directories of the upper and lower layers are present to the applications 160 as belonging to the same filesystem. [0029]: For example, when the mounter executes a kernel command to mount an overlayfs filesystem, they are permitted to specify a label that will be applied to all files therein.); and
deploying the merged filesystem to the embedded controller for execution when authenticity of the created user-defined content is validated and deploying the default secured read only filesystem to the embedded controller for execution when authenticity of the created user-defined content is not validated ([0025]: The lower layer, in implementations, is included into the single merged overlayfs mount 175 as read-only, while the upper layer is mounted read-write into overlayfs mount 175 as an overlay on top of the lower layer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer with the teaching about the merging filesystem of Goyal because the mounter can add security context labels to the overlay filesystem that makes it accessible to another user or application process (Goyal, [0029]).
Claim 14 is rejected under the same rationale as claim 7.
Regarding claim 15, Fitzer teaches A remote terminal unit (RTU) comprising:
a memory storing a factory default image for the RTU, the factory default image including a default secured read only filesystem, the default secured read only filesystem defining predetermined functionality of the RTU; and an embedded controller configured to execute the factory default image for performing the predetermined functionality of the RTU ([0031]: In some example embodiments, the application layers 130A-130D store read-only files for applications. Thus, each of the strategies 530A-530B provides a logical file system that contains read-only application files. [0089] and Fig. 10: discussing about a machine 1000 includes a processor 1002 and a main memory 1004);
wherein the memory further stores a developer image for the RTU, the developer image including a read/write filesystem, the read/write filesystem being a developer equivalent of the read only filesystem, the read/write filesystem including user-defined content created in a development environment for the RTU, the user-defined content comprising extended application content defining extended functionality of the RTU different than the predetermined functionality ([0033]: Each of the user views 560A, 560B, 560C, 560D, and 560E includes a reference to one of the user layers 510A-510E and one of the tenant views 540A-540C. One user view is created for each user of the application server 110. Using a user view, the overlay file system provides a logical file system in which a user layer 510 is overlaid on the logical file system for the underlying tenant. [0034]: In some example embodiments, each user has read-write access to the corresponding user layer 510, configurable access to the corresponding tenant layer 520 (e.g., using the permissions field of the user table 310 of FIG. 3), and read-only access to the corresponding strategy. [0055]: Example 4. The method of any of examples 1to 3, wherein the first user identifier has read-write access to the first layer and read-only access to a third layer of the overlay file system.).
Fitzer does not explicitly teach wherein the read/write filesystem overlays the read only filesystem to create a merged filesystem, the merged filesystem defining both the predetermined functionality of the RTU and the extended functionality of the RTU based on the user-defined content, the merged filesystem further being writeable, and wherein the embedded controller is further configured to execute the merged filesystem in response to validation of the created user-defined content.
Goyal teaches wherein the read/write filesystem overlays the read only filesystem to create a merged filesystem, the merged filesystem defining both the predetermined functionality of the RTU and the extended functionality of the RTU based on the user-defined content, the merged filesystem further being writeable, and wherein the embedded controller is further configured to execute the merged filesystem in response to validation of the created user-defined content ([0024]: In some implementations, the layers at the overlayfs mount 175 may include more than two layers of overlay files system. Each layer may include one or more directories. Each directory may include files and/or other directories. When the upper and lower layers of the overlay filesystem are merged together at the overlayfs mount 175, the files and directories of the upper and lower layers are present to the applications 160 as belonging to the same filesystem. [0025]: The lower layer, in implementations, is included into the single merged overlayfs mount 175 as read-only, while the upper layer is mounted read-write into overlayfs mount 175 as an overlay on top of the lower layer. [0029]: For example, when the mounter executes a kernel command to mount an overlayfs filesystem, they are permitted to specify a label that will be applied to all files therein.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer with the teaching about the merging filesystem of Goyal because the mounter can add security context labels to the overlay filesystem that makes it accessible to another user or application process (Goyal, [0029]).
Regarding claim 16, Fitzer in view of Goyal teaches wherein the embedded controller is further configured to execute the default secured read only filesystem instead of the merged filesystem when the created user-defined content is not validated (Goyal, ([0025]: The lower layer, in implementations, is included into the single merged overlayfs mount 175 as read-only, while the upper layer is mounted read-write into overlayfs mount 175 as an overlay on top of the lower layer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer with the teaching about the merging filesystem of Goyal because the mounter can add security context labels to the overlay filesystem that makes it accessible to another user or application process (Goyal, [0029]).
Regarding claim 19, Fitzer in view of Goyal teaches the embedded controller is further configured to execute the default secured read only filesystem when the created user-defined content is not validated (Goyal, ([0025]: The lower layer, in implementations, is included into the single merged overlayfs mount 175 as read-only, while the upper layer is mounted read-write into overlayfs mount 175 as an overlay on top of the lower layer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer with the teaching about the merging filesystem of Goyal because the mounter can add security context labels to the overlay filesystem that makes it accessible to another user or application process (Goyal, [0029]).
Regarding claim 20, Fitzer in view of Goyal teaches the merged filesystem includes a hidden object of the default secured read only filesystem when a corresponding object is present in the read/write filesystem (Goyal [0025]: An overlay directory shows the set union of all corresponding directories in the stack that aren't blocked. New files and directories get stored in the upper layer while read-only access is provided to files in the lower layers. Modifications to files that are otherwise only in the lower layers, cause that file to be copied up to the upper layer and then the changes are applied to the upper layer copy. This then blocks off access to the file in the lower layer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer with the teaching about the merging filesystem of Goyal because the mounter can add security context labels to the overlay filesystem that makes it accessible to another user or application process (Goyal, [0029]).
Claims 2, 4-6, 10-13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Fitzer in view of Goyal and further in view of Okuyama et al. (US 2014/0101727, hereinafter “Okuyama”).
Regarding claim 2, Fitzer in view of Goyal teaches the method of claim 1 as discussed above. Fitzer in view of Goyal does not explicitly teach executing an authentication process to validate authenticity of the created user-defined content before deploying the merged filesystem to the embedded controller for execution.
Okuyama teaches executing an authentication process to validate authenticity of the created user-defined content before deploying the merged filesystem to the embedded controller for execution ([0015]: discussing about a first reception unit configured to receive a log-in request including the identification information and the authentication information of the computer or the user from the computer; an authentication unit configured to perform authentication of the computer or the user based on the identification information and the authentication information of the computer or the user included in the log-in request; [0101]: discussing about when the user who uses the terminal 10 inputs the authentication information to the authentication reception I/F 118 and receives the contact list information from the management system 50 according to the user the contact list creation unit 20 creates the contact list about the user from the contact list information of the user).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer and Goyal with the teaching about the authentication of Okuyama because it would significantly reduce data breaches, prevent unauthorized access, and secure remote work environments.
Regarding claim 4, Fitzer in view of Goyal teaches the method of claim 1 as discussed above. Fitzer in view of Goyal does not explicitly teach generating a bootable script file, and wherein deploying the merged filesystem to the embedded controller for execution is responsive to execution of the bootable script file.
Okuyama teaches generating a bootable script file, and wherein deploying the merged filesystem to the embedded controller for execution is responsive to execution of the bootable script file ([0155]: However, it may be configured such that a screen that prompts the user authentication is displayed immediately after start-up of the terminal 10aa, and the contact terminal candidate associated with the user ID of the user is extracted in accordance with an authentication result at step S27.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer and Goyal with the teaching about the authentication of Okuyama because it would significantly reduce data breaches, prevent unauthorized access, and secure remote work environments.
Regarding claim 5, Fitzer in view of Goyal and Okuyama teaches validating authenticity of the generated bootable script file before deploying the merged filesystem to the embedded controller for execution (Okuyama, [0006]: discussing about contact information unique to a telephone call terminal is obtained from the transmission management system in accordance with an authentication result after start-up of the telephone call terminal, and the contact information is displayed as a contact list; [0155]: However, it may be configured such that a screen that prompts the user authentication is displayed immediately after start-up of the terminal 10aa, and the contact terminal candidate associated with the user ID of the user is extracted in accordance with an authentication result at step S27.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer and Goyal with the teaching about the authentication of Okuyama because it would significantly reduce data breaches, prevent unauthorized access, and secure remote work environments.
Regarding claim 6, Fitzer in view of Goyal and Okuyama teaches storing the bootable script file in a non-volatile memory (Okuyama, [0076]: Note that the recording medium 106 is freely detachable to the terminal 10. In addition, not only the flash memory 104, but also electrically erasable and programmable ROM (EEPROM) or the like can be used as long as it is non-volatile memory that reads/writes data according to control of the CPU 101.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer and Goyal with the teaching about the authentication of Okuyama because it would significantly reduce data breaches, prevent unauthorized access, and secure remote work environments.
Claim 10 is rejected under the same rationale as claim 4.
Claim 11 is rejected under the same rationale as claim 5.
Regarding claim 12, Fitzer in view of Goyal and Okuyama teaches wherein deploying the default secured read only filesystem to the embedded controller for execution comprises executing the factory default image in response to determining the generated bootable script file is not authentic (Goyal, ([0025]: The lower layer, in implementations, is included into the single merged overlayfs mount 175 as read-only, while the upper layer is mounted read-write into overlayfs mount 175 as an overlay on top of the lower layer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer with the teaching about the merging filesystem of Goyal because the mounter can add security context labels to the overlay filesystem that makes it accessible to another user or application process (Goyal, [0029]).
Claim 13 is rejected under the same rationale as claim 6.
Regarding claim 18, Fitzer in view of Goyal teaches the method of claim 15 as discussed above. Fitzer in view of Goyal does not explicitly teach wherein the read/write filesystem includes a bootable script file for deploying the created user-defined content, and wherein the embedded controller is further configured to execute the bootable script file to execute the merged filesystem.
Okuyama teaches wherein the read/write filesystem includes a bootable script file for deploying the created user-defined content, and wherein the embedded controller is further configured to execute the bootable script file to execute the merged filesystem ([0155]: However, it may be configured such that a screen that prompts the user authentication is displayed immediately after start-up of the terminal 10aa, and the contact terminal candidate associated with the user ID of the user is extracted in accordance with an authentication result at step S27.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer and Goyal with the teaching about the authentication of Okuyama because it would significantly reduce data breaches, prevent unauthorized access, and secure remote work environments.
Claims 3 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Fitzer in view of Goyal, in view of Okuyama, and further in view of Jorden et al. (US 2015/0039872, hereinafter “Jorden”).
Regarding claim 3, Fitzer in view of Goyal and Okuyama teaches the method of claim 2 as discussed above. Fitzer in view of Goyal and Okuyama does not explicitly teach wherein the authentication process includes signature verification of a certificate associated with the read/write filesystem.
Jorden teaches wherein the authentication process includes signature verification of a certificate associated with the read/write filesystem ([0037]: At the beginning of the validity checking or verification process, the processor 101 may cryptographically verify the filesystem image 220. In one aspect, cryptographically processing data may include feeding, to a cryptographic process, values including the data an key, and carrying out the process in order to form cryptographically processed data. The cryptographic verification process may include detecting security vulnerabilities in a file, a directory, a file system, and combinations thereof. In one aspect, the cryptographic verification process may include validating cryptographically processed data, having an entry generated in a signature log for the data, where the entry includes cryptographic information associated with the data.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer, Goyal and Okuyama with the teaching about the verification process of Jorden because it would detect security vulnerabilities in a file, a directory, a file system, and combinations thereof (Jorden, [0037]).
Claim 9 is rejected under the same rationale as claim 3.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Fitzer in view of Goyal, and further in view of Jorden.
Regarding claim 17, Fitzer in view of Goyal teaches the method of claim 15 as discussed above. Fitzer in view of Goyal does not explicitly teach wherein the read/write filesystem includes a self-signed certificate associated therewith for use in determining validation of the created user-defined content.
Jorden teaches wherein the read/write filesystem includes a self-signed certificate associated therewith for use in determining validation of the created user-defined content ([0037]: At the beginning of the validity checking or verification process, the processor 101 may cryptographically verify the filesystem image 220. In one aspect, cryptographically processing data may include feeding, to a cryptographic process, values including the data an key, and carrying out the process in order to form cryptographically processed data. The cryptographic verification process may include detecting security vulnerabilities in a file, a directory, a file system, and combinations thereof. In one aspect, the cryptographic verification process may include validating cryptographically processed data, having an entry generated in a signature log for the data, where the entry includes cryptographic information associated with the data.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the overlay file system of Fitzer and Goyal with the teaching about the verification process of Jorden because it would detect security vulnerabilities in a file, a directory, a file system, and combinations thereof (Jorden, [0037]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jacobson et al. (US 20210318988) discloses that cluster management environment 410 may be implemented to perform an overlay process to provide a read only NFS root filesystem with read-write NFS image as an overlay. An overlay comprises a writable area (e.g., the filesystem on a top of a single file) that is combined with the read-only filesystem to form a copy-on-write union.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHONG H NGUYEN whose telephone number is (571)270-1766. The examiner can normally be reached Monday-Friday, 8:30am-5pm EST.
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, Ajay Bhatia can be reached at (571) 272-3906. 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.
/PHONG H NGUYEN/ Primary Examiner, Art Unit 2156
March 3, 2026