Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
2. NO restrictions warranted at initial time of filing for patent.
Priority
3. Applicant claims domestic priority under 35 USC 119e to provisional application filed on 11/08/2013.
Information Disclosure Statement
4. The information disclosure statement (IDS) submitted on 11/22/2024, the submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Oath/Declaration
5. Applicant’s Oath was filed on 11/22/2024.
Drawings
6. Applicant’s drawings filed on 11/22/2024 has been inspected and is in compliance with MPEP 608.01.
Specification
7. Applicant’s specification filed on 11/22/2024 has been inspected and is in compliance with MPEP 608.02.
Claim Objections
8. NO objections warranted at initial time of filing for patent.
Remarks
9. Examiner request Applicant review relevant prior art under the conclusion of this office action.
Claim Rejections - 35 USC § 103
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
10. Claims 1, 2, 5-9, 12-16, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. hereinafter Raman in view of U.S. Publication No. 20230300114 hereinafter Bhallamudi.
As per claim 1, Raman discloses:
A method for data loss prevention (DLP) scanning in a network environment (Col. 3 Lines 30-37 “As described above, protected information can leave an organization through web operations, using web requests (e.g., HTTP, HTTPS, as well as other protocols), for example, sending webmail messages, and publishing information on blogs, discussion groups, or the like. In order to prevent data loss occurrence, one or more DLP engines (e.g., DMS 104 of FIG. 1) are coupled with a proxy in an organization's network.”), comprising:
receiving a request from a proxy in the network environment (Col. 15 Lines 28-29 “ Referring to FIG. 3, processing logic begins with receiving a rerouted web request from the proxy (block 302).”),
wherein the request is to ask permission from a server to send content associated with the request for DLP scanning (Col. 8 Lines 2-9 “The webmail message may contain sensitive information, which is protected by a DLP policy. The client device 106 generates a web request to send the webmail message to the interactive website. The client device 106 passes the HTTP Post request through the corporate web proxy (e.g., proxy 116). The web proxy redirects the POST request to the DMS 108 for DLP inspection. ”)
the request includes HTTP headers and the content for DLP scanning that are transmitted in a body of the request that are associated with a communication (Col. 8 Lines 54-62 “Upon receiving the original web request 101, the data inductor 204 decomposes the web request in different components, such as, for example, the HTTP Universal Resource Identifier (URI), HTTP headers, HTTP Body (which may be the webmail message body). Alternatively, the data inductor 204 can decompose the web request in different ways, such as by creating key value pairs for headers, creating an XML graph representation, or the like.”);
performing a policy evaluation at a DLP scanner using information extracted from the HTTP headers included in the request to determine whether the content matches a DLP policy and should undergo scanning (Col. 8 Line 64- Col. 9 line 9 “The content extractor 206 is responsible for extracting different data content within the component that can be further analyzed by the content matching engine 208. For example, the content extractor 206 can be used to extract data content of a web request that is not in plain text so that the text of the web request can be evaluated by the content matching engine 208. For example, the content extractor 206 can be used to extract text from an attachment file of the web request, such as during a file upload operation. Also, in the case of attached archive files (e.g., zip, tar, etc), the content extractor 206 can extract content from each of the files in the archive. The content extractor 206 can extract data content from various file types, and create different components of the web request to be evaluated by the content matching engine 208.”);
upon determining the content is to undergo scanning in accordance with the DLP policy, sending an response from the DLP scanner (Col. 15 Lines 28-38 “Referring to FIG. 3, processing logic begins with receiving a rerouted web request from the proxy (block 302), and evaluating the web request to determine whether the web request includes at least one data element that triggers a violation of a policy (block 304). Before block 304, processing logic may identify the policy for protecting source data having one or more data elements. The policy may specify the source data and include one or more rules (e.g., rules concerning data loss prevention) for triggering a violation, as well as policy parameters for excusing detected violations. The data elements may be in tabular or non-tabular format.” A policy violation invokes a request to initiate DLP scanning),
after sending the response, receiving the content associated with the request from the proxy for the DLP scanning processing the content scanned at the DLP scanner to identify policy violations and forwarding the content scanned to an intended destination within the network environment when the content is not in violation of the DLP policy (Col. 15 Lines 38-49 “If at block 304, the processing logic determines that the web request violates the policy, processing logic determines data boundaries of the web request (block 306), selectively removes data content within the data boundaries containing the at least one data element that triggered the violation (block 308), and sends the modified web request to the interactive website (block 310). By sending a modified web request without the selectively-removed data elements, the interactive website can process the modified web request as if it were the original web request containing the at least one data element that triggered the violation.”).
Raman does not disclose:
sending an HTTP response "100 continue" to a proxy
after sending the HTTP response, receiving the content
Bhallamudi discloses:
sending an HTTP response "100 continue" to a proxy, after sending the HTTP response, receiving the content (para 0170 “With the cloud-based system 100 and the DLP service 500, when upload traffic (PUT/POST requests) are scanned by any enforcement node 150, the enforcement node 150, in turn, can forward the request via ICAP to a DLP enforcement node 150B associated with this tenant.” Para 0087 “The process 600 includes a user 102 attempting to send data, with the cloud-based system 100 providing monitoring (step 602). An enforcement node 150 finds a DLP violation and forwards the transaction information to a second enforcement node 150 tasked with sending communications using ICAP to the ICAP server 502 (step 604). The second enforcement node 150 sends the transaction information to the ICAP server 502 using secure ICAP (step 606).” Para 0088 “An organization's firewall 608 must be configured to allow communications from the second enforcement node 150. Further, to protect the organization's data, the second enforcement node 150 can send the above information in an encrypted form via secure ICAP. However, because most DLP servers (ICAP servers 502) can only read unencrypted information, another option is to utilize a tunnel on the ICAP server 502, such as an open-source application called the tunnel application for a TLS/SSL tunnel.” A POST request should include an Expect: 100 continue header when the client anticipates that the server will accept the
request content.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Raman to include the method of sending an HTTP response "100 continue" to a proxy, after sending the HTTP response, receiving the content, as taught by Bhallamudi.
The motivation would have been to properly request for receiving Data Loss Prevention (DLP) configurations.
As per claim 2, Raman in view of Bhallamudi discloses:
The method of claim 1, further comprising: upon determining the content does not necessitate scanning, replying with an HTTP response "200 OK" from the DLP scanner to the proxy, indicating that no scan of the content is required (Raman Col. 15 Lines 49-52 “If at block 304, the processing logic determines that the web request does not violate the policy, processing logic sends the web request unmodified to the interactive website (block 310).” (para 0170 “With the cloud-based system 100 and the DLP service 500, when upload traffic (PUT/POST requests) are scanned by any enforcement node 150, the enforcement node 150, in turn, can forward the request via ICAP to a DLP enforcement node 150B associated with this tenant.” Para 0087 “The process 600 includes a user 102 attempting to send data, with the cloud-based system 100 providing monitoring (step 602). An enforcement node 150 finds a DLP violation and forwards the transaction information to a second enforcement node 150 tasked with sending communications using ICAP to the ICAP server 502 (step 604). The second enforcement node 150 sends the transaction information to the ICAP server 502 using secure ICAP (step 606).” Para 0088 “An organization's firewall 608 must be configured to allow communications from the second enforcement node 150. Further, to protect the organization's data, the second enforcement node 150 can send the above information in an encrypted form via secure ICAP. However, because most DLP servers (ICAP servers 502) can only read unencrypted information, another option is to utilize a tunnel on the ICAP server 502, such as an open-source application called the tunnel application for a TLS/SSL tunnel.” The HTTP 200 OK status code signifies that a request has been successfully processed by the server. Though Raman discloses request and response, Bhallamudi discloses HTTP RESPONSE /200 OK. The motivation would have been properly request for receiving Data Loss Prevention (DLP) configurations.”).
As per claim 5, Raman in view of Bhallamudi discloses:
The method of claim 1, wherein the HTTP headers in the body of the request includes: metadata specifying an identity of a sender and a destination of the content (Bhallamudi para 0084 “In an embodiment, the second enforcement node 150 sends the following information about the transaction to the ICAP server 502: [0085] Client IP and username via ICAP X-headers; and [0086] a copy of the HTTP POST request that contains the file that violated the DLP policy, or if the content is from HTTP Forms data, a copy of the content that violated the DLP policy. The host URL to which the user was attempting to send content would also be included here.” para 0103 “The message format for the DLP incident forwarding can be a multipart/mixed Multipurpose Internet Mail Extensions (MIME) message that includes DLP triggering content+DLP scan metadata. Though Raman discloses headers in the body of the request, Bhallamudi discloses metadata specifying an identity of a sender and a destination of the content. The motivation would have been to properly request for receiving Data Loss Prevention (DLP) configurations.” ).
As per claim 6, Raman in view of Bhallamudi discloses:
The method of claim 1, wherein processing the content scanned at the DLP scanner to identify policy violations comprises: identifying one or more data leak policies in the DLP policy, the one or more data leak policies configured to assist the DLP scanner with determining whether the content matches the DLP policy, wherein determining comprises: identifying a sender of the content scanned as a member of a specific department based on the information extracted from the HTTP headers; determining a destination of the content from the information extracted from the HTTP headers, wherein the destination of the content includes a network application; matching the information associated with the sender and destination against the one or more data leak policies to identify whether the content requires scanning; and in response to determining that an identification of the sender and the destination matches the network application specified in the one or more data leak policies, performing a scan of the content to check for personal identifying information (PII) or restricted information in violation of the DLP policy (Raman Col. 5 Line 55- Col. 6 Line 20 “ The policy 112 may include a set of rules that specify which information should be present in a web request to trigger a violation. In other embodiments, the action policy may contain exception clauses that identify exceptions to this policy's rules, such as specific web addresses of an interactive website, or a specific web domain. The rules in the policy may be combined using logical connectives of first-order logic (e.g., AND, OR, NAND, NOR, NOT, equivalent, nonequivalent, or the like).” Also see Col. 8 Lines 6-19) and Bhallamudi discloses on para 0064 “The DLP functionality via the cloud-based system 100 can include content matching, Exact Data Match (EDM), granular policies, and flexible remediation. The content matching can utilize preconfigured and/or custom DLP dictionaries supporting Regular Expressions (Regex), keywords, etc. Content detection can include numeric detection, trained dictionaries/fuzzy search, and Boolean logic. The numeric detection can detect Social Security Numbers (SSNs), medical numbers (CCNs, insurance numbers, etc.), pattern matching, etc. The trained dictionaries/fuzzy search can match financial data, source code, medical data, names, adult content, CRM data, gambling, weapons, etc. The Boolean logic can combine context and detection with logical operators, keywords, and phrases. The DLP functionality can also support context detection based on people (users, groups, departments, etc.), location (country, branch office, etc.), and reporting.” Also see paragraph 0067-0074. Though Raman discloses identify policy violations, Bhallamudi discloses the method of identify policy violations of claim 6. The motivation would have been to properly request for receiving Data Loss Prevention (DLP) configurations.”) .
As per claim 7, Raman in view of Bhallamudi discloses:
The method of claim 1, wherein the HTTP headers are populated by the proxy the proxy configured to: populate the HTTP headers with identification information of a sender of the request (Bhallamudi para 0067 discloses “The DLP service 6500 can send data to the ICAP server 502, including the client IP address and username of the user 102 (via ICAP X-headers)”),
including location, department, or role, based on information imported from an active directory; and populate the HTTP headers with destination information related to a destination to which the sender intends to transmit the content (Bhallamudi para 0064 “The DLP functionality can also support context detection based on people (users, groups, departments, etc.), location (country, branch office, etc.), and reporting.” Para 0067 discloses “The DLP service 6500 can send data to the ICAP server 502, including the client IP address and username of the user 102 (via ICAP X-headers)” Also see paragraph 0075-0079 Though Raman discloses http headers, Bhallamudi discloses the method of http headers including information as described in claim 7. The motivation would have been to properly request for receiving Data Loss Prevention (DLP) configurations.”).
As per claim 8, the implementation of the method of claim 1 will execute the network device of claim 8. The claim is analyzed with respect to claim 1.
As per claim 9, the claim is analyzed with respect to claim 2.
As per claim 12, the claim is analyzed with respect to claim 5.
As per claim 13, the claim is analyzed with respect to claim 6.
As per claim 14, the claim is analyzed with respect to claim .
As per claim 15, the implementation of the method of claim 1 will execute the non-transitory computer readable medium (Bhallamudi paragraph 0189) of claim 15. The claim is analyzed with respect to claim 1.
As per claim 16, the claim is analyzed with respect to claim 2.
As per claim 19, the claim is analyzed with respect to claim 5.
As per claim 20, the claim is analyzed with respect to claim 6.
11. Claims 3, 4, 10, 11, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. hereinafter Raman in view of Bhallamudi, and further in view of U.S. Publication No. 20250278354 hereinafter Wolkiser.
As per claim 3, Raman in view of Bhallamudi discloses:
The method of claim 1, further comprising receiving the DLP policy (Col. 8 Line 64- Col. 9 line 9)
Raman in view of Bhallamudi does not disclose:
DLP policy at the DLP scanner from an S3 bucket
Wolkiser discloses:
DLP policy at the DLP scanner from an S3 bucket (para 0022 “ When the one or more test channels include the cloud channel (i.e., such as an Amazon Web Service or AWS or a similar cloud infrastructure), the DLP effectiveness evaluation system 320 may execute the one or more transfers to a S3 bucket with at least a portion of the DLP sample test data. The DLP effectiveness evaluation system 320 may then scan the S3 bucket using an S3 tool.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Raman to include DLP policy at the DLP scanner from an S3 bucket, as taught by Wolkiser.
The motivation would have been to properly automated, dynamic, and generative data loss prevention testing.
As per claim 4, Raman in view of Bhallamudi and Wolkiser discloses:
The method of claim 3, wherein receiving the DLP policy at the DLP scanner includes: configuring the DLP policy via a secure access dashboard associated with the network environment by a network administrator, wherein the DLP policy is stored in a database; and pushing the DLP policy to the DLP scanner from the database (Bhallamudi para 0045 “The cloud-based system 100 can also include a management system 120 for tenant access to provide global policy and configuration as well as real-time analytics. This enables IT administrators to have a unified view of user activity, threat intelligence, application usage, etc. For example, IT administrators can drill-down to a per-user level to understand events and correlate threats, to identify compromised devices, to have application visibility, and the like. The cloud-based system 100 can further include connectivity to an Identity Provider (IDP) 122 for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 for event logging. The system 124 can provide alert and activity logs on a per-user 102 basis.” Para 0091 “In the indexing tool 402, data records are identifier (step 660), and defined data is submitted (step 662), and fingerprints are uploaded to the enforcement nodes 150 (step 664). Again, importantly, the data itself is not uploaded, but hash signatures. In the admin portal (management system 120), an IT administrator can define an EDM rule for the DLP service (step 666), load the EDM rule on the enforcement nodes 150 (step 668), enable the EDM rule (step 670), etc. The enforcement nodes 150 can monitor outbound traffic for EDM rule violations (step 672), and responsive to an EDM rule violation check (step 674), either allow the outbound traffic (step 676) or block the outbound traffic and report (step 678).” Though Raman discloses receiving the DLP policy, Bhallamudi discloses configuring the DLP policy. The motivation would have been to properly request for receiving Data Loss Prevention (DLP) configurations.”).
As per claim 10, the claim is analyzed with respect to claim 3.
As per claim 11, the claim is analyzed with respect to claim 4.
As per claim 17, the claim is analyzed with respect to claim 3.
As per claim 18, the claim is analyzed with respect to claim 4.
Conclusion
12. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A. U.S. Publication No. 20250219996 hereinafter Dalla.
As per claim 1, Dalla discloses:
A method for data loss prevention (DLP) scanning in a network environment (para 0013 “The disclosed solution utilizes a service worker to intercept and modify outbound requests with user information and/or DLP scanning results.”), comprising:
receiving a request from a proxy in the network environment (para 0048 “At block 501, the service worker intercepts and modifies a response to a request sent by the web browser during a SaaS application session to add one or more event listeners for a web page. During a session with a SaaS application established for a user, when the web browser sends a request, the service worker obtains a response (e.g., an HTTP request and response, respectively).”),
wherein the request is to ask permission from a server to send content associated with the request for DLP scanning (para 0025 “The service worker 105 communicates the data 206 to the DLP scanning service 211, such as via an API of the DLP scanning service 211. The DLP scanning service 211 performs a DLP scan to determine if the data 206 is sensitive and returns to the service worker 105 a verdict 205.” Para 0026 “At stage D, the service worker 105 intercepts an HTTP request 204 issued by the web browser 103 and modifies the HTTP request 204 with the verdict 205 and the account name 207. The service worker 105 intercepts the HTTP request 204 based on the web browser 103 issuing a network request (e.g., via the fetch method) that the service worker 105 is configured to intercept. The service worker 105 can modify the HTTP request 204 by adding request headers 209 that include the account name 207 and the verdict 205. The service worker 105 may modify the HTTP request 204 to include additional data and/or metadata of the verdict 205 that was communicated by the DLP scanning service 211.”)
the request includes HTTP headers and the content for DLP scanning that are transmitted in a body of the request that are associated with a communication (para 0026 “In this example, the request headers 209 are X-headers, though in implementations, other custom header types that can be appended/attached to HTTP requests may be used.” Para 0027 “At stage E, the cybersecurity appliance 111 evaluates the modified HTTP request 202, including the user account name and DLP verdict identified from the request headers 209, for policy enforcement.”);
performing a policy evaluation at a DLP scanner using information extracted from the HTTP headers included in the request to determine whether the content matches a DLP policy and should undergo scanning (para 0027 “ At stage E, the cybersecurity appliance 111 evaluates the modified HTTP request 202, including the user account name and DLP verdict identified from the request headers 209, for policy enforcement. The cybersecurity appliance 111 has been configured with policies per SaaS application (“policies”) 203.” Para 0027 “For the rule(s) of the policies 203 that specify user/tenant information, the cybersecurity appliance 111 can determine the user or account associated with the modified HTTP request 202, or the user associated with the account name 207, from the corresponding one of the request headers 209 so that the rule(s) can be enforced accordingly. In this example, since the HTTP request 202 comprises sensitive data (i.e., the data 206), the cybersecurity appliance 111 can be assumed to block the HTTP request 202 in accordance with the policies 203..”);
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GARY S GRACIA whose telephone number is (571)270-5192. The examiner can normally be reached Monday-Friday 9am-6pm.
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, Philip Chea can be reached at 5712723951. 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.
/GARY S GRACIA/Primary Examiner, Art Unit 2499
Prosecution Insights