DETAILED ACTION
1. This action is in response to the amendment and argument field on 3 March 2026
2. Claims 1-20 remain Pending and Rejected.
Responses to the Argument
3. The applicant’s arguments filed on 3 March 2026 are moot in view of new ground of rejection rendered.
Claim Rejections - 35 USC § 103
4. 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-3, 5-17 and 19-21 are rejected under 35 U.S.C §103 as being unpatentable over Shinde et al. (US Publication No. 10248797), hereinafter Shinde and in view of Ziv et al. (US Publication No. 20220075492), hereinafter Ziv.
Regarding claim 1:
A system for preventing upload of a computer source file to an upload destination, comprising (Shinde, Abstract): a computer comprising a processor and a memory (Shinde, col 2, lies 40-44 ), The DLP system may include a processor coupled to memory to execute a DLP agent.
a user application accessed by a user via the computer (Shinde, col 2, lines 51-57), wherein Detection of a file upload occurs when the file choose dialogue is dismissed After performing detection of the file upload, the file is filtered using known files that have been blocked. Accordingly, the application never detects a forbidden file. For a folder upload, detection may begin when a process starts accessing the files under the associated folder.
an agent application hosted by the computer configured to perform the steps of: registering for a notification of a user interface action with an operating system (OS) of the computer (Shinde, col 11, lines 20-43, FIG.1, component 140), wherein, the DLP agent 140 may monitor the network interface 135 or the applications 130 4A pending outbound data transfer. In response to a detected file or folder upload, the DLP agent 140 may capture contextual data associated with the pending file or folder upload (file upload context), in an action 310. Once the DLP agent 140 captures the file upload context, DLP agent 140.
receiving notice from the OS of the user interface action associated with the registering (Shinde, col 11, lines 44-67), capturing file 45upload context of FIG. 3A, DLP agent 140 may detect an associated operation for the potential file transfer. In one embodiment, in an action 320, the DLP agent 140 may determine whether the scheduled file or folder upload corresponds to a single file upload, multi-file upload, folder 50 upload or a drag-and-drop operation. More particularly, as shown in FIG. 3C, which is a representation of a method for detecting an associated operation for the scheduled file or folder upload of FIG. 3B, agent 140 may intercept a shell dialogue API to detect a single file upload or a multi file 55 upload in an action 322. Agent 140 may also intercept a browse folder API to detect a folder upload in an action 324. Further, in an action 326, agent 140 may intercept a drop process interface exposed by the browser during an instance creation to detect the drag-and-drop operation determining the user interface action is indicative of a data file upload operation of a source file to an upload destination comparing a property of the source file and a property of the upload destination to a blocking criteria and preventing the user application from receiving the user interface action indicative of the data file upload operation of a source file to an upload destination .
determining the user interface action is indicative of a data file upload operation of a source file to an upload destination (Shinde, col 10, lines 8-20), wherein, detecting a scheduled file 5 upload, DLP agent 140 may initiate in real-time the capture of file upload context associated with the scheduled file or folder upload and store this context data in the file upload context database 154. As previously noted, the captured file upload context may include the file name, folder name, 10 metadata, active URL, and the like. Further, in an effort to detect an associated operation corresponding to the scheduled file or folder upload, the DLP agent 140 may intercept
the shell dialogue API, the browse folder API, or the drop process interface, to determine whether a single/multi-file upload, a folder upload, or a drag and drop operation is associated with the file scheduled to be uploaded.
comparing a property of the source file and a property of the upload destination to a blocking criteria; and OLP protection method described (Shinde, col 3, lines 17-33), herein. The method may include capturing and sending file upload context ( e.g. folder name, metadata, an active URL, etc.) associated with the scheduled file or folder upload to a OLP file system driver. For example, in an effort to capture FIG. 3C is a flow diagram of a method for detecting an
associated operation for the scheduled file or folder the file upload context, the method may include detecting in accordance with some embodiments. whether a single upload, a multi-file upload, a folder upload, or a drag-and-drop operation exists, through interception of IG. 3E is a flow diagram of a method for processing the file upload based upon a matched prior classification entry of the shell dialogue API, the browse folder API, or the drop FIG. 3D, in accordance with some embodiments. process interface, respectively. Further, the method may include generating a file upload cache including the file upload context, prior classification entries, and a timestamp indicating when the scheduled file or folder upload was last modified; such that, the OLP file system driver may intercept and process the file open call based upon the file upload cache.
preventing the user application from receiving the user interface action indicative of the data file upload operation of a source file to an upload destination (Shinde, abstract).
Shinde does not explicitly suggest, wherein the user interface action comprises detection by the OS of a user interaction with a controller of a graphical user interface pointer and/or a pressing of one or more keys on a keyboard user interface; however, in a same field of endeavor ZIv discloses this limitation (Ziv, ¶7, ¶9), wherein receiving an indication from a computer's operating system that a user has performed a keyboard action at a computer that included one or more key presses on a keyboard that caused the computer to perform a keyboard-initiated paste action, and comparing the one or more key presses against a list of key presses and/or key press combinations (stored in a computer-based data store, that, if pressed, would cause the computer to perform the keyboard-initiated paste action). If the one or more keys pressed match an entry in the list of key presses and/or key press combinations, the method includes concluding that the keyboard action by the user caused the keyboard-initiated paste action to occur; and creating a notification of the keyboard-initiated paste action.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of preventing data upload of Shinde with the method of detecting using point or key press by the user disclosed in Ziv to capture user activity and generate notification, stated by Ziv at para.12.
Regarding claim 2:
wherein the step of the agent determining the user interface action is indicative of a data file upload operation of a source file to an upload destination further comprises detecting a data source file selection action (Shinde, col 11, lines 44-50).
Regarding claim 3:
wherein the agent is further configured to perform the steps of: accessing source file properties of the source file; and comparing the source file properties to the blocking criteria (Shinde, abstract, col 13, lines 9-16).
Regarding claim 5:
further comprising a file picker configured to facilitate the user interface action (Shinde, col 5, lines 17-65).
Regarding claim 6:
A computer based method for preventing upload of a computer source file to an upload destination, comprising the steps of: (Shinde, col 2, lines 1-21), wherein capturing and sending file upload context (e.g. folder name, metadata, an active URL, etc.) associated with the scheduled file or folder upload to a DLP file system driver. For example, in an effort to capture the file upload context, the method may include detecting whether a single upload, a multi-file upload, a folder upload, or a drag-and-drop operation exists, through interception of the shell dialogue API, the browse folder API, or the drop process interface, respectively. Further, the method may include generating a file upload cache including the file upload context, prior classification entries, and a timestamp indicating when the scheduled file or folder upload was last modified; such that, the DLP file system driver may intercept and process the file open call based upon the file upload cache. In some embodiments, the file system driver may detect a match between the file path of the scheduled file or folder upload and a current process, a parent process, or a process that initiates a current X interProcess Communication (XPC) service. In response to the detected file path match, the driver may detect whether the active URL is closed or the browser process is terminated.
registering for a notification of a user interface action with an operating system (OS) of the computer (Shinde, col 2, lines 40-64), wherein processor is operable to capture file upload context (e.g. folder name, metadata, an active URL, etc.) in real-time for an scheduled file or folder upload and send the file upload context to a DLP filesystem driver within the DLP agent. The processor may also be operable to detect whether a single upload, a multi-file upload, a folder upload, or a drag-and-drop operation exists, through interception of the shell dialogue API, the browse folder API, or the drop process interface, respectively. Further, the processor may also be operable to generate a file upload cache including the file upload context, prior classification entries, and a timestamp indicating when the scheduled file or folder upload was last modified; such that, the DLP file system driver may be operable to intercept and process the file open call based upon the file upload cache. For example, the file system driver may be operable to detect a match between the file path of the scheduled file or folder upload and a current process, a parent process, or a process that initiates a current XPC service.
receiving notice from the OS of the user interface action associated with the registering (Shinde, col 11, lines 44-67), capturing file 45upload context of FIG. 3A, DLP agent 140 may detect an associated operation for the potential file transfer. In one embodiment, in an action 320, the DLP agent 140 may determine whether the scheduled file or folder upload corresponds to a single file upload, multi-file upload, folder 50 upload or a drag-and-drop operation. More particularly, as shown in FIG. 3C, which is a representation of a method for detecting an associated operation for the scheduled file or folder upload of FIG. 3B, agent 140 may intercept a shell dialogue API to detect a single file upload or a multi file 55 upload in an action 322. Agent 140 may also intercept a browse folder API to detect a folder upload in an action 324. Further, in an action 326, agent 140 may intercept a drop process interface exposed by the browser during an instance creation to detect the drag-and-drop operation determining the user interface action is indicative of a data file upload operation of a source file to an upload destination comparing a property of the source file and a property of the upload destination to a blocking criteria and preventing the user application from receiving the user interface action indicative of the data file upload operation of a source file to an upload destination .
determining the user interface action is indicative of a data file upload operation of a source file to an upload destination (Shinde, col 10, lines 8-20), wherein, detecting a scheduled file 5 upload, DLP agent 140 may initiate in real-time the capture of file upload context associated with the scheduled file or folder upload and store this context data in the file upload context database 154. As previously noted, the captured file upload context may include the file name, folder name, 10 metadata, active URL, and the like. Further, in an effort to detect an associated operation corresponding to the scheduled file or folder upload, the DLP agent 140 may intercept
the shell dialogue API, the browse folder API, or the drop process interface, to determine whether a single/multi-file upload, a folder upload, or a drag and drop operation is associated with the file scheduled to be uploaded.
comparing a property of the source file and a property of the upload destination to a blocking criteria (Meier, ¶61, 67), wherein A cut/copy and paste action performed by the operating system is monitored and intercepted during a user's session, and the action may be blocked, filtered, logged, archived, suppressed and/or mitigated based on various rules. Session information, user information and system specific-information may be collected to support the cut/copy and paste control decision, according to the rules. Various types of information may be captured and used as a basis for deciding whether to block and/or to report and/or to limit and/or to alter and/or to suppress an attempt to cut/copy and paste data from the clipboard. The cut/copy action or the paste action may be blocked, or a combination of the cut/copy and paste action may be blocked or controlled according to the description herein. The term cut or cut action as used herein may sometimes mean copy or copy action, and vice versa and information may be retrieved to, and analyzed by, application information analyzer 22 illustrated in FIG. 4. [0067] Name or title of the source document and/or of the destination document, for example, the name or title of the source and/or destination document, source and/or destination document purpose, the electronic folder or file of the source and/or the destination document, the document type, document content, or the like (document, as used here may mean, in addition, a source/destination database, webpage, website or server, device, data stream, or the like.
Shinde does not explicitly suggest, wherein the user interface action comprises detection by the OS of a user interaction with a controller of a graphical user interface pointer and/or a pressing of one or more keys on a keyboard user interface; however, in a same field of endeavor ZIv discloses this limitation (Ziv, ¶7, ¶9), wherein receiving an indication from a computer's operating system that a user has performed a keyboard action at a computer that included one or more key presses on a keyboard that caused the computer to perform a keyboard-initiated paste action, and comparing the one or more key presses against a list of key presses and/or key press combinations (stored in a computer-based data store, that, if pressed, would cause the computer to perform the keyboard-initiated paste action). If the one or more keys pressed match an entry in the list of key presses and/or key press combinations, the method includes concluding that the keyboard action by the user caused the keyboard-initiated paste action to occur; and creating a notification of the keyboard-initiated paste action.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of preventing data upload of Shinde with the method of detecting using point or key press by the user disclosed in Ziv to capture user activity and generate notification, stated by Ziv at para.12.
Regarding claim 7:
wherein the file upload operation comprises a data file selection (Shinde, col 4, lines 48-58).
Regarding claim 8:
wherein the file upload operation comprises a data file pick (Shinde, col 5, lines 56-64).
Regarding claim 9:
further comprising the steps of: accessing source file properties of the source file; and comparing the source file properties to the blocking criteria (Shinde, col 13, lines 9-16, abstract).
Regarding claim 10:
Shinde does not explicitly suggest, wherein the user interface action indicative of the file upload operation of the source file comprises a user interaction with a controller of a graphical user interface pointer However in a same filed of endeavor Ziv discloses this limitation (Ziv, claim 9).
Same motivation for combining the respective features of Shinde and Ziv applies herein, as discussed in the rejection of claim 6.
Regarding claim 11:
wherein the user interface action indicative of the file upload operation of the source file comprises user interaction with a file picker configured to facilitate the user interface action (Shinde, col 5, lines 17-65).
Regarding claim 12:
Shinde does not explicitly suggest, wherein the user interaction with the controller of the graphical user interface pointer comprises at least one of the group of a click, a click-and-release, a click-and-hold, a click-and-drag, and a click-and-drag-and-release; However, in a same filed of endeavor Ziv discloses this limitation (Ziv, ¶37-38).
Same motivation for combining the respective features of Shinde and Ziv applies herein, as discussed in the rejection of claim 6.
Regarding claim 13:
Shinde does not explicitly suggest, wherein the controller of the graphical user interface pointer comprises one of the group consisting of a mouse, a trackpad, a track point, a track button, a track knob, and a trackball However, in a same filed of endeavor Ziv discloses this limitation (Ziv, ¶44).
Same motivation for combining the respective features of Shinde and Ziv applies herein, as discussed in the rejection of claim 6.
Regarding claim 14:
wherein determining the user interface action is indicative of a data file upload operation of a source file to a destination file location further comprises detecting a data file pick action (Shinde, col 5, lines 57-65).
Regarding claim 15:
wherein blocking at least a portion of the user interface action indicative of the data file upload operation from reaching the application comprises dropping the data file pick action (Shinde, col 5, lines 57-65).
Regarding claim 16:
further comprising the step of informing the user of the preventing of the user application from receiving the user interface action (Shinde, col 13, lines 5-13).
Regarding claim 17:
Shinde does not explicitly suggest, wherein: the user interface action comprises a sequence of key presses; and determining the user interface action is indicative of a data file upload operation further comprises the step of parsing the sequence of key presses; However, in a same filed of endeavor Ziv discloses this limitation (Ziv, ¶96).
Same motivation for combining the respective features of Shinde and Ziv applies herein, as discussed in the rejection of claim 6.
Regarding claim 19:
further comprising the step of retrieving and analyzing user session data for correlation with the data file upload operation, wherein the user session data may occur before, after, and/or concurrently with the data file upload operation (Shinde, col 8, lines 35-65).
Regarding claim 20:
Shinde does not explicitly suggest wherein the user session data includes at least one of the group consisting of a screenshot from the user computer, a second user interface action, a user session log, and actions on the source file prior to the first user interface action; However, in a same filed of endeavor Ziv discloses this limitation (Ziv, ¶37-39).
Same motivation for combining the respective features of Shinde and Ziv applies herein, as discussed in the rejection of claim 6.
Regarding claim 21:
further comprising the step of transmitting the user interface action and/or the user session data to an external server (Shinde, col 7, lines 31-40).
5. Claims 4 and 18 are rejected under 35 U.S.C §103 as being unpatentable over Shinde in view of Ziv and in view of IDS provided by the applicant, Fairbairn et al. (US Publication No. 20180260534), hereinafter Fairbairn.
Regarding claim 4:
Shinde in view of Ziv does not explicitly suggest, wherein the user interface action further comprises recognition by the OS facial and/or body gesture recognition; however, in a same field of endeavor Fairbairn discloses this limitation (Fairbairn, ¶36, ¶31).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of preventing data upload of Shinde in view of Ziv with the use of facial recognition disclosed in Fairbairn to maintain privacy, stated by Fairbairn at para.7.
Regarding claim 18:
Meier does not explicitly suggest, wherein the user interface action further comprises recognition by the OS facial and/or body gesture recognition; however, in a same field of endeavor Fairbairn discloses this limitation (Fairbairn, ¶36, ¶31).
Same motivation for combining the respective features of Shinde in view of Ziv and Fairbairn applies herein, as discussed in the rejection of claim 4.
Conclusion
6. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Monjour Rahim whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on 571-272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (in USA or CANANDA) or 571-272-1000.
/Monjur Rahim/
Patent Examiner
United States Patent and Trademark Office
Art Unit: 2436; Phone: 571.270.3890
E-mail: monjur.rahim@uspto.gov
Fax: 571.270.4890
Prosecution Insights