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
Response to Arguments
Applicant’s arguments filed February 26, 2026 have been fully considered. After further consideration, the prior art of record still reads on Applicant’s claim language.
Applicant asserts Pohl does not teach this limitation because the original file in Pohl’s file system remains intact and unchanged - the write result goes to a copy-on-write storage area, not back to the existing file. (See Applicant’s remarks, pages 7-8, citing Pohl para 0029, 0039-0042, Fig. 3.).
In response, The Examiner respectfully disagrees and this argument is not persuasive. Applicant’s characterization of Pohl is limited to the high entropy (ransomware-suspected) branch of Pohl’s architecture and ignores Pohl’s express teachings regarding the low-entropy (non-ransomware) branch- which is the operative branch for the instant claim limitation. Specifically, Pohl para 0039 expressly discloses: “upon determining that the entropy value is below the threshold value performing a write operation of the file in the file system, and thereby modifying the original file.” Pohl, Claim 4, recites this same limitation: “upon determining that the entropy value is below the threshold value, performing a write operation of the file in the file system, modifying the original file.” FIG. 3, step 310 of Pohl confirms this branch: when entropy is determined (step 306) to be below threshold (not malware), the file is written (step 310) to the host file system - the protected storage - thereby modifying the pre-existing original file. The amended claim limitation recites “wherein the changes associated with the file change event are propagated to the protected storage if the file change event is determined to not be malware, and wherein the changes include a modification to an existing file previously stored in the protected storage.” This limitation is directed to the non-malware scenario - the identical scenario governed by the combination of Pohl’s low-entropy branch coupled with Natanzon’s Figure 5 disclosure. In the combination branch, the combined art performs a write operation directly to the host file system modifying the original file (see Pohl para. 0039, Claim 4, FIG. 3 step 302 and step 310 and Natanzon col. 7 lines 37 – 49; Claim 2; Claim 6 and Figure 5 blocks 504 and 520), which reads directly on “modification to an existing file previously stored in the protected storage.” Applicant’s reliance on paras 0029 and 0041 is misplaced because those paragraphs only concern Pohl’s high-entropy/ ransomware-suspected path - the scenario where the system has determined the event is potentially malware. The amended claim limitation at issue governs the opposite scenario: when the event is determined NOT to be malware. The Examiner asserts a reference must be considered in its entirety, including all embodiments disclosed therein. See Merck & Co. v. Biocraft Labs., Inc., 874 F.2d 804, 807 (Fed. Cir. 1989) (“A prior art reference must be considered in its entirety, i.e., as a whole.”). The full disclosure of the combination – including the difference-threshold embodiment of Pohl para. 0038 and Claim 3, and the explicit process I/O request of Natanzon Figure 5 block 520 expressly presupposes “modifications of the original file” - confirms that the combination teaches modifications to existing files. The rejection is therefore maintained.
Applicant asserts Pohl’s restoration of files to the file system requires a manual user/operator request (para 0041), not automatic propagation.
In response, The Examiner respectfully disagrees and relies on the combination of prior art to teach the commit operation can be initiated by a user or initiated automatically or semi-automatically after appropriate scanning and analysis of the contents of secondary mass storage 311 is completed (see Lok para 0030). This is a disjunctive disclosure - the automatic branch is expressly on the face of the reference. Under BRI of a disjunctive disclosure, the express automatic branch alone teaches the claim element. In addition, even if Lok were read to teach only a user-initiated commit, MPEP 2144.04(III) citing In re Venner, 262 F.2d 91, 95, 120 USPQ 193, 194 (CCPA 1958) establishes as a matter of law that “providing an automatic means to replace a manual activity which accomplishes the same result is not sufficient to distinguish over the prior art.” This legal backstop independently defeats any “automatic vs. manual” argument.
Applicant asserts the combination of references teaches away.
In response, The Examiner respectfully disagrees because Lok para [0030]’s disjunctive automatic/manual/semi-automatic disclosure does not teach away from automatic operation - it expressly discloses it as an option. Both Lok and Natanzon target the same field (protecting filesystem data against malicious modification) and the combination is additive, not contradictory.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 21 – 34 of the instant application are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1 – 12 of U.S. Patent No. 12061693, by the same assignee, known henceforth as Patent in view of Pohl (US Pub. No. 2019/0228148) in view of Natanzon (US Patent No. 10078459) in view of Lok (US Pub. No. 2006/0137013 A1).
Although the conflicting claims are not identical, the instant application’s claims are within the scope of those of Patent.
Moreover, the doctrine of double patenting seeks to prevent the unjustified extension of patent exclusivity beyond the term of a patent.
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, 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.
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.
Claims 21 – 24, 26 and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Pohl (US Pub. No. 2019/0228148) in view of Natanzon (US Patent No. 10078459) in view of Lok (US Pub. No. 2006/0137013 A1).
Per claim 21/34, Pohl (US Pub. No. 2019/0228148) teaches a method for detecting and mitigating attacks by malware, the method comprising: receiving a notification of a file change event (reads on determining that a process is attempting a file write, see Pohl Figure 3 block 302 and para 0054) to a file system (see Pohl para 0025); diverting storage of the file change event from (reads on when it is determined the entropy value is above or equal to the threshold value, then the manipulated file is not written to a persistent storage area but is written to the copy-on-write storage area, see Pohl para 0025 and 0055 and Figure 3 blocks 306 and 308. The Examiner notes Pohl contrasts the copy-on-write storage area with persistent storage) a protected storage area (reads on a persistent storage area, see Pohl para 0025 and Figure 3 blocks 306, 308 and 310) to a temporary storage area (reads on the copy-on-write storage area, see Pohl para 0025 and 0055 and Figure 3 block 308) in response to the malware probability exceeding a threshold (reads on when it is determined the entropy value is above or equal to the threshold value, then the manipulated file is written to the copy-on-write storage area, see Pohl Figure 3 block 306, para 0025 and 0055. The Examiner notes Pohl contrasts the copy-on-write storage area with persistent storage), wherein the temporary storage area (reads on the copy-on-write storage area, see Pohl para 0025 and 0055) is non-local (The Examiner construes this to be an obvious limitation based on the prior art’s teaching of the copy-on-write storage area is a dedicated part of a file system, an independent file system, a completely different storage organization, a dedicated area on a remote storage device only used for files being created by a copy-on-write process or any other data storage structure suitable for storing the described data, see Pohl para 0025, 0042, 0052 and 0060. The Examiner construes this to be obvious because it is within the realm of conventional computer science for a dedicated area on a remote storage device to be implemented via a physically distinct/remote structure based on the needs of the business) with respect to (reads on the copy-on-write storage area is a dedicated part of a file system, an independent file system or a completely different storage organization, see Pohl para 0025, 0042) the protected storage area (reads on the normal host file system in a persistent storage area, see Pohl para 0025, 0054 and Figure 3 blocks 306 and 310); and
executing changes associated with (reads on the file modification is written to the copy-on-write storage area then written to the original file system replacing the original file when it is determined no attack happened, see Pohl Figure 3 block 308 – 310 and para 0029) the file change event (reads on the write file instruction, see Pohl Figure 3 block 302) in the temporary storage area (reads on the copy-on-write storage area, see Pohl Figure 3 block 308), wherein the changes associated with the file change event are propagated to the protected storage if the file change event is determined to not be malware (reads on after copying files to the copy-on-write storage area determining the file has not been infected and copying to the actual file system and replacing/changing the unmodified file, see Pohl para 0029 and 0041), and wherein the changes associated with the file change event include a modification to an existing file previously stored in the protected storage (reads on the file modification is written to the copy-on-write storage area then written to the original file system replacing the original file when it is determined no attack happened, see Pohl Figure 3 block 308 – 310 and para 0029 and 0041). The prior art of record is silent on explicitly stating a malware probability exceeding a threshold; and executing changes associated with the file change event.
[0023] The term “entropy value” may denote a degree of chaos in a file. In computing, entropy can be considered as the randomness collected by an operating system or application for use in cryptography, or other uses that require random data. Randomness may be collected or generated from either software or hardware sources, including specially provided hardware randomness generators, or specialized software programs. A computing of the entropy of a file may relate to a determinable structure of the data within the file. A completely encrypted file may have a comparably high entropy value in contrast to a highly structured file with a lot of redundancies which may have a comparably low entropy value. An ideal encrypted file may be comparable to “white noise”, i.e., no structure may be detectable.
[0024] The term “copy-on-write” may denote a resource-management technique used in computer programming to efficiently implement a “duplicate” or “copy” operation on modifiable resources. A copy-on-write process may create a copy of an original file that can be modified, instead of modifying the original file and overwriting it.
[0025] The term “copy-on-write storage area” may denote a dedicated area on a storage device—also possibly in main memory—only used for files being created by a copy-on-write process. The copy-on-write storage area may be a dedicated part of a file system, an independent file system or may have a completely different storage organization. If a main memory area is used as copy-on-write storage area, the data may be copied later to a persistent storage area.
[0027] The proposed method for a protection against unauthorized file encryption in a file system may offer multiple advantages and technical effects.
[0028] The proposed method and system can differentiate between a regular and a compromised file, i.e., a file encrypted by ransomware. The mechanism to make this differentiation comprises the determination of the entropy value for a portion or for the complete data file. If a file is encrypted, an additional compression may deliver a different compression value if compared to an unencrypted file. Additionally, the method may also reflect different compression percentages for different types of files. For example, a compression value for an image may be different to a compression value of text records in an address database.
[0029] In embodiments of the present invention, if a file modification by a ransomware attack is assumed or identified, the modified file may not overwrite the original file. Thus, the original file may continue to be intact, i.e., continue to be unmodified. Additionally, the related modified file may be written to a special dedicated storage area using a copy-on-write process. Thus, the original file continues to be in existence, even if its content was modified by the ransomware attack. Further investigations and determinations may be made in order to identify a ransomware attack. In case no attack may have happened, the files may easily be copied to the original place in the file system, thereby replacing the unmodified files. Thus, an elegant method and/or system may be provided to fight ransomware attacks.
[0041] According to an additional embodiment, the method may also comprise copying files from the copy-on-write storage area to the file system. This may be performed on a user or operator request. It may happen after it may have been determined that the related file may have not been infected/encrypted in light of a ransomware attack. This may happen if the threshold value or the threshold difference value may be predefined in a non-appropriate way.
[0042] According to a further embodiment of the method, the copy-on-write storage area may be outside of the file system. Thus, the area to which the file may be copied in case of ransomware detection may not be part of the file system. This may represent a higher degree of freedom and data security. Some ransomware attacks may encrypt a complete file system and not only parts thereof. Thus, storing the potentially modified/encrypted file outside of the file system may allow isolating the compromised files in a special storage container.
[0054] FIG. 3 shows an embodiment of a flowchart 300 of a write operation to a file. A process manipulates data of a file and intends to write to a file, 302. The ransomware file indicator, for example, an entropy value, is determined 304. If the entropy value is determined, 306, to be smaller than a predefined threshold value, then the file is written, 310, to the normal host file system.
[0055] In case it is determined, 306, that the entropy value is above or equal to the predetermined threshold value, then the file is written, 308, to the copy-on-write storage area. Thus, the original file in the file system continues to be in existence.
[0056] FIG. 4 shows an embodiment of a flowchart 400 of a read operation to a file. It is assumed that in general the monitoring for ransomware is active. The process “read file” is activated, 402. Firstly, it is determined whether an entry exists in an index of the copy-on-write storage area, 404. If it is determined, 406, that such an entry in the index does not exist, then a file handle to the location in the regular host file system is returned, 410.
[0057] If, on the other side, an index in the copy-on-write storage area exists, then a mapping exists in the copy-on-write storage area. The file is read, 408, via a file handle returned from the copy-on-write layer from the copy-on-write storage area.
PNG
media_image1.png
838
805
media_image1.png
Greyscale
Natanzon (US Patent No. 10078459) suggests
receiving a notification of a file change event to a file system (reads on receiving an I/O write request, see Natanzon col. 10 lines 23 – 42, col. 10 lines 42 – 60 and Figure 5 block 504); diverting storage of the file change event to a temporary storage area (reads on commencing copy-on-write for the I/O write request, see Natanzon col. 10 lines 42 – 60 and Figure 5 block 512) in response to the malware probability estimate exceeding a threshold (reads on when the ransomware probability is greater than a threshold, commencing a copy-on-write operation, see Natanzon Figure 5 blocks 510 and 512 and col. 10 lines 42 – 60. The Examiner asserts Natanzon expressly conditions the diversion of writes (commencing COW) on the ransomware probability exceeding a first threshold value (Claim 1; FIG. 5 blocks 508/510/512), which is a verbatim functional match to “in response to the malware probability exceeding a threshold.” The Examiner asserts ransomware is a species of malware (see spec para [0009]-[0013] describing the inventive context as protection against malware including ransomware) and Natanzon’s threshold-gated COW falls squarely within the broadest reasonable interpretation of “malware probability exceeding a threshold”), and wherein the changes associated with the file change event include a modification to an existing file previously stored in the protected storage (reads on Natanzon discloses that the I/O behaviors being intercepted and routed through COW operate on files already resident in the host’s filesystem - including in-place encryption that overwrites the data of files already stored in the protected store while preserving their location and name (col. 7 lines 37 – 49) - which reads on “modification to an existing file previously stored in the protected storage” because the modification at issue is the overwrite of an existing file’s data, and Claim 6 confirms that COW operates by making a copy of “any data that will be overwritten by subsequent I/O requests.” The Examiner asserts the claim language “modification to an existing file” plainly encompasses overwrites of resident files - exactly the in-place modification Natanzon intercepts (col. 7 lines 37 – 49; Claim 2; Claim 6)).
[Col. 9 lines 43 – 58]
FIG. 5 is a flow diagram showing illustrative processing that can be implemented within data protection system (e.g., data protection system 100 of FIG. 1). In some embodiments, at least a portion of the processing described herein may be implemented within a data protection appliance (e.g., DPA 300 of FIG. 3). In one embodiment, at least a portion of the processing described herein may be implemented within a ransomware detection processor (e.g., ransomware detection processor 304 of FIG. 3). Rectangular elements (typified by element 502), herein denoted “processing blocks,” represent computer software instructions or groups of instructions. Diamond shaped elements (typified by element 510), herein denoted “decision blocks,” represent computer software instructions, or groups of instructions, which affect the execution of the computer software instructions represented by the processing blocks.
[col. 9 line 59 – col. 10 line 10]
Alternatively, the processing and decision blocks may represent steps performed by functionally equivalent circuits such as a digital signal processor (DSP) circuit or an application specific integrated circuit (ASIC). The flow diagrams do not depict the syntax of any particular programming language but rather illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required of the particular apparatus. It should be noted that many routine program elements, such as initialization of loops and variables and the use of temporary variables may be omitted for clarity. The particular sequence of blocks described is illustrative only and can be varied without departing from the spirit of the concepts, structures, and techniques sought to be protected herein. Thus, unless otherwise stated, the blocks described below are unordered meaning that, when possible, the functions represented by the blocks can be performed in any convenient or desirable order.
[col. 10 lines 11 – 22]
Referring to FIG. 5, a method 500 can be used to detect and mitigate the effects of ransomware within a host. At block 502, one or more data structures for historical I/O activity and one or more data structures for recent I/O activity are initialized. In some embodiments, this includes allocating data structures in memory. In certain embodiments, initializing one or more historical I/O activity data structures includes fetching previously collected historical I/O data (e.g., from storage or memory). In various embodiments, the recent and historical I/O activity structures may be the same as or similar to those described above in conjunction with FIG. 3.
[col. 10 lines 23 – 42]
Referring back to FIG. 5, at block 504, an I/O request is received from a host. The I/O request may include a LUN identifying a LU, an offset within the LU, and a data length. The offset and data length can be used to determine one or more storage locations (e.g., chunk numbers) within the LU where the requested data should be read from or written to.
At block 506, metadata about the I/O request may be added to the recent I/O activity data structures. In some embodiments, such metadata includes an offset, data length, and/or storage locations associated with the I/O request. In particular embodiments, metadata about the I/O request may also be added to the historical I/O activity data structures.
Referring again to FIG. 5, at block 508, a probability of ransomware is generated by comparing recent I/O activity to historical I/O activity (i.e., information within the respective data structures initialized at block 502). In various embodiments, generating the ransomware probability includes using one or more of the heuristics described above in conjunction with FIG. 3.
[col. 10 lines 42 – 60]
Referring back to FIG. 5, at block 510, if the ransomware probability exceeds a first threshold value (e.g., a first predetermined value), then the storage system may begin using copy-on-write (COW) for the LU (block 512). In some embodiments, if the system is in COW mode, an I/O write causes a copy to be made of any data that will be overwritten by the write. In other embodiments, COW may be implemented by creating a point in time snapshot of the LU. Referring again to FIG. 5, in the event that the host is infected with ransomware, the user may recover data by requesting a rollback from the storage system. If the ransomware probability subsequently falls below the certain threshold value, then COW may be ended for the LU and any COW data copies may be erased from storage (block 518). In some embodiments, COW ends when the ransomware probability subsequently falls below the first threshold value. In other embodiments, COW ends when the ransomware probability subsequently falls below the third threshold value less than the first threshold value.
PNG
media_image2.png
1263
839
media_image2.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the determining the malware probability estimate teachings of the prior art of record by integrating the malware probability estimate of Natanzon to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Natanzon would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the determining the malware probability estimate teachings of Natanzon to the malware probability estimate teachings of Pohl would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such malware probability estimate features into similar systems, resulting in an improved system that would allow more detailed malware determination by using all available known in the art techniques to make the determination. The motivation to combine the references is applied to all claims below this heading.
Lok (US Pub. No. 2006/0137013 A1) is relied upon to teach
receiving a notification of a file change event to a file system (reads on Lok’s quarantine filesystem driver receives “mass storage transactions” through its operating-system-library interface (para [0014]) and routes them to filesystem drivers via the secondary filesystem interface (Claim 1), which reads on “receiving a notification of a file change event to a file system” because each operating-system-level mass-storage I/O transaction delivered to a filesystem driver is a notification to the filesystem layer of an attempted file change. The Examiner asserts Lok expressly conducts mass-storage transactions (which include file creates, writes, and modifications) through the driver layer with the secondary filesystem as the routing target (para [0015])); diverting storage (reads on Lok diverts file-change transactions from the primary filesystem (the “protected” store) to the secondary filesystem (the “temporary” store) by executing them “first against the secondary filesystem” (para [0015]) and only later committing them to the primary store, which reads directly on “diverting storage ... from a protected storage area to a temporary storage area” because the file change is structurally redirected away from the primary store at the moment the transaction is initiated. The Examiner asserts Lok’s quarantine architecture diverts every mass-storage transaction to the secondary filesystem by default (see para [0015] and Claim 14) of the file change event from (reads on write operations are only passed to the primary filesystem after the input output transaction has passed security analysis, see Lok claim 5) a protected storage area (reads on the primary filesystem, see Lok claim 5) to a temporary storage area (reads on the secondary filesystem, see Lok claim 5)
wherein the temporary storage area is non-local with respect to the protected storage (reads on the secondary filesystem is independent of the primary filesystem, see Lok Abstract. The Examiner asserts Lok expressly implements the secondary (temporary) mass storage externally to the system that hosts the primary (protected) filesystem and as physically and/or logically separable from it (para [0014], [0025], [0028] and Claim 3), which reads on “the temporary storage area is non-local with respect to the protected storage” because external and physically-separable storage is non-local to the host system under any reasonable construction. The Examiner asserts Lok’s preferred embodiment (para [0014]) and Claim 3 expressly require the secondary mass storage to be external and physically separable from the system implementing the quarantine filesystem); and
executing changes associated with the file change event in the temporary storage area (reads on input output transactions are conducted in the secondary filesystem before occurring in the primary filesystem, see Lok claim 5. The Examiner asserts Lok’s delta filesystem driver actually performs (executes) the requested write changes against the secondary mass storage - storing the delta of each change on the secondary store rather than against the primary store - which reads directly on “executing changes associated with the file change event in the temporary storage area” because the secondary mass storage is the locus where each transaction is executed while the primary filesystem remains unchanged (para [0015] and [0027]). The Examiner further asserts Lok’s delta filesystem expressly “stores differences or changes that are made to files” (para [0027]) and the subsequent commit operation presumes the changes have already been executed against the secondary store), wherein the changes associated with the file change event are automatically propagated to the protected storage if the file change event is determined to not be malware (reads on only using the primary file system for input output transactions after the transactions have passed security analysis in the secondary filesystem, see Lok claim 5. The Examiner further asserts Lok expressly teaches automatic propagation of safe (non-malware) changes from the secondary filesystem to the primary (protected) filesystem because (i) the commit operation propagates the secondary-store changes to the primary store only after the data “is determined to be safe” para [0015] and Claim 14 makes that determination (“will not adversely impact the primary filesystem”) the gating condition, and (ii) Lok para [0030] expressly states that this commit operation “can be initiated by a user or initiated automatically or semi-automatically after appropriate scanning and analysis of the contents of secondary mass storage 311 is completed” – disclosing the automatic, no-user-intervention branch on its face. The Examiner further asserts Lok para [0030] expressly recites the automatic and semi-automatic alternatives, and even if Lok were read to teach only a user-initiated commit, MPEP 2144.04(III) (citing In re Venner, 262 F.2d 91, 95, 120 USPQ 193 (CCPA 1958)) establishes as a matter of law that “providing an automatic means to replace a manual activity which accomplishes the same result is not sufficient to distinguish over the prior art” - so the “automatically without user intervention” recitation is unpatentable over Lok’s manual commit branch even on the narrowest reading).
[0003] The present invention relates generally to data storage and filesystems, and more particularly, to a quarantine filesystem and associated method for effectively addressing the effects of malicious software and applications, such as viruses, backdoor trojans, and the like, in a data storage system or other computer system and/or network.
[0030] After a user determines that a particular download is not causing problems and passes all antivirus checks, the user is able to “commit” a particular set of changes stored on the delta filesystem implemented by driver 309 and secondary storage 311 to the primary mass storage 310. The commit operation can be initiated by a user or initiated automatically or semi-automatically after appropriate scanning and analysis of the contents of secondary mass storage 311 is completed. Because the scanning and analysis of secondary mass storage 311 can occur asynchronously with respect to the normal usage of the computing system, the user does not experience long delays while file downloads are scanned or during delays before startup of applications.
1. A quarantine filesystem driver comprising: an operating system interface configured to communicate mass storage input/output transactions; a primary filesystem interface configured to communicate with a primary filesystem driver; and a secondary filesystem interface configured to communicate with a secondary filesystem driver.
5. The quarantine filesystem driver of claim 1 wherein the primary filesystem interface is not used for write operations until mass storage input output transactions that have been conducted through the secondary filesystem interface have passed security analysis.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the file event processing teachings of the prior art of record by integrating the file event processing teachings of Lok (see claim 5) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Lok would have yielded predictable results and resulted in an improved system. It would have been recognized that applying write operations only in the secondary filesystem and data is only passed to the primary filesystem after the transactions are determined to be safe to the write the file to the host file system after the entropy value is determined to be less than a threshold value teachings of Pohl would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such conditional writing features into similar systems, resulting in an improved system that would allow more detailed conditional i/o operations to the host/primary filesystem by using all available known in the art techniques to make the determination. Neither Lok nor Natanzon teaches away from the claimed combination. Lok para [0030]’s express disclosure of an automatic commit branch demonstrates that Lok contemplates and endorses the very mode of operation recited in the claims. The combination of references operate in the same technical field of protecting primary filesystems against malicious data modification, and their combination is additive and predictable. The motivation to combine the references is applied to all claims below this heading.
Per claim 22, the prior art of record further suggests wherein the temporary storage area (reads on the copy-on-write storage area, see Pohl para 0025 and 0055) is physically distinct from (The Examiner construes this to be an obvious limitation based on the prior art’s teaching of the copy-on-write storage area is a dedicated part of a file system, an independent file system, a completely different storage organization, a dedicated area on a remote storage device only used for files being created by a copy-on-write process or any other data storage structure suitable for storing the described data, see Pohl para 0025, 0042, 0052 and 0060. The Examiner construes this to be obvious because it is within the realm of conventional computer science for a dedicated area on a remote storage device to be implemented via a physically distinct/remote structure based on the needs of the business) the protected storage (reads on the normal host file system in a persistent storage area, see Pohl para 0025, 0054 and Figure 3 blocks 306 and 310).
Per claim 23, the prior art of record further suggests wherein the temporary storage area (reads on the copy-on-write storage area, see Pohl para 0025 and 0055) is physically remote from (reads on the copy-on-write storage area is a dedicated part of a file system, an independent file system, a completely different storage organization, a dedicated area on a remote storage device only used for files being created by a copy-on-write process or any other data storage structure suitable for storing the described data, see Pohl para 0025, 0042, 0052 and 0060) the protected storage (reads on the normal host file system in a persistent storage area, see Pohl para 0025, 0054 and Figure 3 blocks 306 and 310).
Per claim 24, the prior art of record further suggests further comprising moderating access to (reads on the function of the host file system, see Pohl para 0025, 0042, 0052, 0060 and Figure 3) a first plurality of files organized in a first file system (reads on files of the host file system, see Pohl para 0025, 0042, 0052, 0060 and Figure 3), wherein the first plurality of files are stored in (reads on the files written to the host file system are stored in a persistent storage area, see Pohl para 0025 and Figure 3 blocks 306, 308 and 310) the protected storage (reads on the normal host file system in a persistent storage area, see Pohl para 0025, 0054 and Figure 3 blocks 306 and 310).
Per claim 26, the prior art of record further suggests characterizing the file change event, the characterization including at least two or more of a group selected from file entropy change (reads on determine a compromised file by determining an entropy value to compare its relation to a threshold value, see Pohl Figure 3 block 304, 306 and para 0023, 0028, 0054), and file content change (reads on data length, see Natanzon col. 10 lines 23 – 42).
Claims 27 – 28 are rejected under 35 U.S.C. 103 as being unpatentable over Pohl in view of Natanzon in view of Lok in view of Hartrell (US Pub No. 2007/0150957 A1).
Per claim 27, the prior art of record suggests the method of claim 21. The prior art of record is silent on explicitly stating generating the snapshot includes generating a plurality of different consistent snapshots of a file system tree of the file system.
Hartrell suggests
generating a snapshot of (reads on creating a snapshot within a time frame prior to the monitored activity and creating a snapshot within a specified time frame after the monitored activity, see Hartrell para 0004 and 0015) the file system (reads on the file system or any other operating system object, see Hartrell para 0019) in response to (reads on upon being informed of a suspected malware infection, see Hartrell para 0004 and 0015) the file change event (reads on the monitored activity such as changes to the file system or any other operating system object, see Hartrell para 0019); generating the snapshot includes generating a plurality of different consistent snapshots (reads on creating a snapshot within a time frame prior to the monitored activity and creating a snapshot within a specified time frame after the monitored activity, see Hartrell para 0004 and 0015) of a file system tree of the file system (reads on local system activity of any part of the entire file system, see Hartrell para 0015 and 0016).
[0004] A malware analysis system for automating cause and effect analysis of malware infections is provided. The malware analysis system monitors and records computer system activities. Upon being informed of a suspected malware infection, the malware analysis system creates a time-bounded snapshot of the monitored activities that were conducted within a time frame prior to the notification of the suspected malware infection. The malware analysis system may also create a time-bounded snapshot of the monitored activities that are conducted within a time frame subsequent to the notification of the suspected malware infection. The malware analysis system provides the created snapshot or snapshots for further analysis. For example, the snapshots of the monitored activities may be analyzed to determine the cause and effect of the malware infection.
[0015] In some embodiments, the malware analysis system can provide a snapshot of the activities that were conducted within a specified time frame after the detected or suspected infection for analysis. This snapshot may be referred to as a “post-infection snapshot.” For example, the malware analysis system can provide a snapshot of the monitored activities (e.g., local system activity, network activity, etc.) for the subsequent ten minutes after the detection of the infection. The snapshot of the activities can then be analyzed to assess the damage and/or characterize any additional threats or damage to the infected computer system. For example, the snapshot of the subsequent activities can be analyzed to determine the activities that occurred subsequent to the infection, including identifying the operating system objects that were manipulated, additional communications that occurred with other computer systems, and the like. When applied across multiple computer systems and/or networks, a knowledgeable administrator, such as a security or system administrator, can analyze the snapshots (i.e., the snapshot of the activities prior to the detected/suspected infection and/or the snapshot of the activities subsequent to the detected/suspected infection) and use the result of the analysis to manually or automatically re-configure security policies in the environment to prevent future infections.
[0016] In some embodiments, the malware analysis system may monitor additional activities subsequent to the detection of an infection or suspected infection. For example, the malware analysis system may be configured to monitor a specific directory or directories in the file system when there are no infections or suspected infections on the computer system, and configured to monitor the entire file system when informed of an infection or suspected infection.
[0018] In some embodiments, the malware analysis system may perform commonality analysis on the normalized activities in the pre-infection snapshot and/or the post-infection snapshot to find any recurring activities. Once the malware analysis system discovers what the commonality is between the snapshots, the malware analysis system can tailor and provide a recommendation for responding to the detected infection. The malware analysis system can utilize an expert system to tailor and provide a recommendation based on the commonality analysis. For example, the commonality analysis process may indicate that each of four infected machines visited the same web site prior to being infected. Here, the malware analysis system may determine that this web site most likely served the malware to each of the infected machines. Using the expert system, the malware analysis system may recommend that this web site be “blocked.”
[0019] FIG. 1 is a high-level block diagram that illustrates selected components of a malware analysis system 100, according to some embodiments. The malware analysis system comprises a system activity monitor component 102, a categorization component 104, a commonality analysis component 106, and a response recommendation generator 108. The system activity monitor component provides runtime monitoring of the operating system resources for changes to the file system, common file formats, configurations (registry), network activities, use of common application program interfaces (APIs), or any other operating system object. The system activity monitor component may run on and monitor the activity of a computer system, such as, by way of example, a local desktop operating system, a server or network device. While executing, the system activity monitor component records the monitored activities in a data store, which may be in memory, on physical media, or other logical data store. The system activity monitor component may be configured to record information regarding the monitored activity, such as, by way of example: the identified operating system object or network object involved in the monitored activity (e.g., file name, socket, IP address, logical paths, etc.); the details of the change (e.g., create file, listen on network socket, etc.); if applicable, the details of the object prior to the change; the source(s) of the change (e.g., process id, user security context, logical storage identity from which data originated, logical storage identity where the change occurred, network sources such as uniform resource locator (URL) or internet protocol (IP) address, the API call used to make the change, etc.); a date and time stamp in which the event occurred. The system activity monitor component can be notified of a malware infection. For example, the system activity monitor component may provide an API through which an anti-malware system, or other well-known intrusion detection systems, can pass a notification of a confirmed or suspected malware infection. Upon receiving the notification, the system activity monitor component creates and provides a time-bounded snapshot of activities that occurred before and/or after the notification of infection to the other components of the malware analysis system. For example, the system activity monitor component may provide the snapshot of activities to a centralized data store that is accessible by the other components of the malware analysis system.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the collecting historical I/O activity to mitigate the effects of ransomware teachings of the prior art of record (see Natanzon col. 10 lines 11 – 22) by integrating the explicit generating pre and post activity filesystem activity snapshot teachings of Hartrell (see Hartrell para 0004, 0015 and 0018 – 0019) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, it would have been obvious to one of ordinary skill in the art to include in the notification of a file change event system of the prior art of record the ability to take filesystem snapshots pre and post the file change event as taught by Hartrell since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized the results of the combination were predictable. The motivation to combine the references applies to all claims under this heading.
Per claim 28, the prior art of record further suggests detecting patterns of change based on changes between (reads on performing a commonality analysis on the monitored activities of the pre-infection snapshot and the post-infection snapshot in order to reconfigure security policies to prevent future malware infections, see Hartrell para 0015 and 0018 – 0019) a first snapshot in the plurality of snapshots and a second snapshot in the plurality of snapshots (reads on creating a snapshot within a time frame prior to the monitored activity and creating a snapshot within a specified time frame after the monitored activity, see Hartrell para 0004 and 0015).
Claims 29 – 33 are rejected under 35 U.S.C. 103 as being unpatentable over Pohl in view of Natanzon in view of Lok in view of Scaife (WO 2017053745 A1).
Per claim 29, the prior art of record suggests claim 21. The prior art of record is silent on explicitly stating a locality-based hashing algorithm is used to process the original file and the changed file and to place them into a similar vector space.
Scaife (WO 2017053745 A1) suggests
wherein a locality-based hashing algorithm is used to process the original file and the changed file and to place them into a similar vector space (The Examiner construes this to be an obvious limitation of the prior art of record because one of ordinary skill in the art would know that a locality-based hashing algorithm is reasonably scoped as a similarity-preserving hash algorithm and Scaife teaches using similarity-preserving hash functions, see Scaife page 7 lines 20 – 29).
[page 5 lines 14 – 25]
]Initially, a file operation directed at a file by a process is detected (100), for example, by a malware detector as described in Figure 4. Detection of the file operation is, in some embodiments, performed by a file system “filter” or “driver,” a software component that often runs with higher privilege levels in an operating system (OS). Higher privilege levels may allow the driver to detect or intercept basic “disk” (or other storage media) access function calls (“file operations”). File operations can include, for example, “reads” and “writes” to the file data in files, as well as creating, moving, renaming, and deleting the files themselves. In some cases, the driver may have similar privilege levels to other OS or kernel components. In at least some implementations, the file operation may be directed at a user document file, e.g., a word processing document located in a user document directory (such as the “My Documents” directory on Microsoft Windows®).
[page 6 lines 1 - 26]
When a file operation has been detected emanating from a process by, e.g., the driver, it can be determined whether the process triggers a “transformation indicator” (110). Several kinds of transformation indicator may provide clues that the process is a malware process. Transformation indicators may be pertinent to the file and/or to the process performing the file operation, depending on the nature of the indicator. “Primary” transformation indicators (e.g., 115) are those that may be considered highly indicative of a malware process, whereas “secondary” transformation indicators may be indicative, but less so, or only indicative in the presence of one or more primary indicators. In some cases, the presence of a particular combination of indicators may itself be an indicator of malware (e.g., a “union” indicator). A detailed discussion of several types of data transformation indicators, and how they are measured, follows below.
The specific activities that ransomware performs can be refined into the following classes: Class A ransomware overwrites the contents of the original file by opening the file, reading its contents, writing the encrypted contents in-place, then closing the file. It may optionally rename the file. Class B ransomware extends class A, with the addition that the malware moves the file out of the user’s documents directory, for example, into a temporary directory. It then reads the contents, writes the encrypted contents, and moves the file back to the user’s directory. The file name at the end of the process may be different than the original file name. Class C ransomware reads the original file, creates a new, independent file containing the encrypted contents, and deletes the original file. This class of malware may use two independent file access streams to read and write the data.
Some types of transformation indicators may be more effective against some kinds of malware. For example, transformation indicators that compare differences between versions of a file before and after a file modification may be less effective against class C malware (i.e., malware that copies and encrypts files to a different directory and deletes the original file) than class A and class B malware.
[page 7 lines 20 - 29]
Another type of transformation indicator applicable to some embodiments is a similarity measurement of the file. A similarity measurement indicates the similarity of data in the file after modification to the data that was in the file before modification. Such meaningful changes to file data can be captured through the use of similarity-preserving hash functions [9, 14]. Similarity-preserving hash functions differ from traditional cryptographic hash functions because the hash (or “digest”) produced by the similarity- preserving hash function retains information about the source data. By comparing two “similarity digests,” one created before the file data was modified and one created after the file data was modified, it is possible to determine a similarity measurement that gauges the level of relatedness of the file data across versions of the file.
[page 9 line 16 – page 10 line 3]
In some cases, an entropy measurement of file data taken before and after a file modification operation may be compared; a significant positive delta (e.g., in excess of an entropy threshold) between the before and after measurements may indicate that the process performing the modification operation is malware. In certain cases a single entropy measurement taken after the modification operation may be used as a transformation indicator.
Sometimes, the type of file data stored in the file may affect the entropy measurement. Many modern file formats, e.g., newer Microsoft Office® documents, implement compression of file contents in the file format itself. Thus, an entropy measurement of the pre-change compressed file data may be as high as the entropy measurement of the post-change encrypted file data. Figure 3 shows average entropy measurements on a set of over 6,500 files from the Govdocsl corpus. The measurements were taken before and after a ransomware sample encrypted them. Every file type experienced some entropy increase, though low-entropy original files experienced greater increases. In every case, the encrypted files’ entropy approached the maximum possible entropy of eight.
In certain embodiments of the subject invention, entropy measurement may refer to a delta between read and write entropy for the process as a whole. In some cases, the entropy of atomic read and atomic write operations are captured as separate metrics. The delta, or difference, between the read and write entropy metrics may then be computed and, when the delta exceeds an entropy measurement threshold, the process may trigger the transformation indicator.
[page 13 line 28 – page 14 line 9] It should be noted that any examples herein of a malware score, detection threshold, and indicator adjustment are not intended to be limiting. For example, the process malware score can start as some number, e.g., 500; the indicator adjustment may be a subtraction from the process malware score, and the malware detection threshold is reached when the process malware score reaches zero. As another example, the process malware score can have an initial value of zero, the indicator adjustment may be additive to the score, and the malware detection threshold is reached at some positive number. Furthermore, indicator triggering thresholds or ranges (such as the entropy measurement threshold, similarity measurement range, file deletion measurement threshold, and file- type change measurement threshold) are dependent on the particular implementation environment, may be experimentally derived, and may also be configurable. Certain effective thresholds and ranges for some environments were experimentally derived and are shown below in the Examples section.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the file change notification teachings of the prior art of record (reads on the combination of creating a snapshot within a time frame prior to the monitored activity, creating a snapshot within a specified time frame after the monitored activity and determining metadata/characteristics about the I/O request, see Natanzon col. 10 lines 23 – 42 and Figure 5 block 502 and 504 and see Hartrell para 0004 and 0015) by integrating the notification of a file change event to a file system (reads on detecting a file operation directed at a file, see Scaife page 5 lines 14 – 25) teachings of Scaife to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, it would have been obvious to one of ordinary skill in the art to include in the notification of a file change event system of the prior art of record the ability to not only detect a file change event but also determine the level of similarity between the pre and post modified file as taught by Scaife since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized the results of the combination were predictable. The motivation to combine the references applies to all claims under this heading.
Per claim 30, the prior art of record further suggests detecting malware based on an alignment of vectors in the similar vector space (reads on determining a similarity measurement that gauges the level of relatedness, see Scaife page 7 lines 20 – 29).
Claim 31 is analyzed with respect to claim 30. The prior art of record further suggests determining characteristics associated with the file change event (reads on determining it is a write event and the entropy value of the file, see Pohl Figure 3 block 302, 304 and para 0054), including determining a similarity of a changed file resulting from the file change event with respect to an original file (reads on comparing the determined entropy value to a threshold value to determine whether the file has an entropy value consistent with a compromised file, see Pohl Figure 3 block 302, 304, 306 and para 0023, 0028, 0054), wherein the original file is an original version of the changed file (reads on before the file data was modified, see Scaife page 7 lines 20 – 29), prior to the file change event (reads on before the file data was modified, see Scaife page 7 lines 20 – 29).
Per claim 32, the prior art of record further suggests compressing the original file and (reads on implementing compression of file contents to determine an entropy measurement of the pre-change compressed file, see Scaife page 9 line 22 – page 10 line 3) the changed file to increase an information content of the information (reads on determining an entropy measurement of the post-change encrypted/compressed file, see Scaife page 9 lines 8 – 11 and page 9 line 22 – page 10 line 3); and detecting malware based on a similarity between the compressed original file and the compressed changed file (reads on determining the presence of malware by comparing the entropy measurement between the pre-change compressed file and the post-change encrypted/compressed file, see Scaife page 9 lines 8 – 11 and page 9 line 22 – page 10 line 3).
Per claim 33, the prior art of record further suggests detecting malware based on a similarity difference of more than 20 percent (reads on determining the presence of malware based on the similarity/entropy measurement being configurable, see Scaife page 14 lines 1 – 9. The Examiner asserts one of ordinary skill in the art would consider the prior art’s teaching of configuring the threshold/range to be within the scope of Applicant’s of more than 20 percent recitation).
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over Pohl in view of Natanzon in view of Lok in view of Liao (US Patent No. 7962956 B1).
Per claim 25, the prior art of record suggests the method of claim 24. The prior art of record is silent on explicitly stating creating a substantially identical copy of the first plurality of files with a second plurality of files stored in the temporary storage.
Liao (US Patent No. 7962956 B1) suggests
creating a substantially identical copy of the first plurality of files with a second plurality of files stored (reads on a full backup/clone of the entirety of data in data storage, see Liao col. 4 lines 47 – 52) in the temporary storage (reads on any suitable storage backup storage device including the storage associated with the exemplary Microsoft Volume Shadow Copy backup service, see Liao col. 4 lines 28 – 52).
[Col. 4 lines 47 – 52]
The full backup 431 may be a complete copy (i.e., a clone) of the entirety of the data 430 in the data storage 106. The full backup 431 may be used by itself or together with one or more snapshots 401 to restore the data 430 in the event of an irrecoverable data storage device error, such as when the data storage device 106 crashes and cannot be accessed.
[col. 4 line 53 – col. 5 line 16]
A snapshot 401 may comprise an incremental backup of the data 430 at a particular point in time. For example, the full backup 431 may be created at time T0, the snapshot 401-1 may be taken at a time T1 (i.e., after time T0), the snapshot 401-2 may be taken at time T2 (i.e., after time T1), and so on. In one embodiment, a snapshot 401 comprises differential data created using a COW backup procedure. For example, a snapshot 401 may have differential data for sectors of the data storage device 106 that have been changed due to changes in the data 430. Each of the differential data may comprise original data stored in a sector prior to that sector being overwritten with new data. Referring to FIG. 6, a snapshot 401 may have several sections 30 (i.e., 30-1, 30-2, . . . , 30-n), with each section 30 including a sector address 31 (i.e., 31-1, 31-2, . . . , 31-n) and differential data 32 (i.e., 32-1, 32-2, . . . , 32-n). A sector address 31 identifies a physical storage location in the data storage device 106, and a differential data 32 is the original data in that physical storage location and which has been overwritten with new data. In one embodiment, a sector address 31 is the address of the smallest addressable physical storage location in the data storage device 106, which in this example is a hard disk sector. The modified sectors noted in a snapshot 401 may be occupied by different files. For example, the modified sector indicated by the section 30-1 may contain a portion of a first file, the modified sector indicated by the section 30-2 may contain a portion of a second file that is different from the first file, and so on. The snapshots 401 may be created using the Microsoft Volume Shadow Copy Service.TM. backup service, for example. The full backup 431 may be created using a backup tool of the operating system or a third-party full backup software.
One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, it would have been obvious to one of ordinary skill in the art to include in the snapshot system of the prior art of record the ability to create a substantially identical copy of files by performing a full backup/clone of the entirety of data in any suitable storage device as taught by Liao since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized the results of the combination were predictable.
Conclusion
The prior art of record still reads on Applicant’s claim language. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
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.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights