DETAILED ACTION
This office action is in reply to applicant communication filed on March 09, 2026.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 09, 2026.
Claims 1-30 have been amended.
Claims 1-30 are pending.
Response to Argument
Applicant’s arguments filed on March 09, 2026 with respect to the 35 U.S.C. 102/103 rejections have been fully considered but are moot in view of new ground(s) of rejection.
Applicant’s argues that the prior arts on record fails to teach the amended limitation of independent claims. However, upon further consideration, a new ground(s) of rejection is made using the newly find prior arts to Xie (US 9,325,735).
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 5-11, 14, 18-24, 26 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Rados (US Pub. 2015/0067816) in view of Troyansky (2009/0241196) and further in view of Xie (US 9,325,735).
.
As per claim 1 Rados discloses:
A gateway device, comprising: a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to cause the gateway to: monitor network traffic of a network on the gateway; (paragraph 10 of Rados, user devices 105 may be associated with a network (e.g., connected to a router), and may be in communication with automated security gateway 110. Automated security gateway 110 may analyze traffic outputted by user devices 105 in order to identify potential security threats to the network).
Initiate a security response associated with a security policy; (paragraph 26 of Rados, ASGW 220, according to some implementations. As shown, example ASGW 220 may include gateway configuration component 305, device behavior component 310, traffic security policy component 315, device security policy component 320, traffic analysis component 325, remedial action component 330, and reporting component 335) and (paragraph 43 of Rados, Traffic analysis component 325 may receive and/or analyze traffic, outputted by user devices 210, and may determine whether the traffic should be allowed to be forwarded to its intended destination, or whether remedial action (such as blocking the traffic, reporting the potential security threat, etc.) should be taken. Traffic analysis component 325 may make such a determination based on information received from, for example, device behavior component 310, traffic security policy component 315, and/or device security policy component 320)
Output the notification associated with the security response to a device. (Paragraph 42 of Rados, ASGW 220 may send alerts to user device 210, indicating that traffic sent to and/or from user device 210 has been blocked).
Rados teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
Receive a notification that the network traffic indicates a security threat to the network.
However, in the same field of endeavor, Troyansky teaches this limitation as, (paragraph 63 of Troyansky, a traffic analyzer 750 on a gateway 760 monitors incoming and outgoing traffic from at least one computerized device 720 to a site 780 and analyzes the sensitivity and the risk involved in the scenario. The results are sent for analysis to the decision system 770, which decides about the required action and sends instructions accordingly (such as "block", "quarantine" or "alert") to the gateway 760).
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 teaching of Rados to include the above limitation using the teaching of Troyansky in order to establish a secure data communication by analyzing the communication using the decision system and receive the required action to mitigate risk associated with the communication (see paragraph 63 of Troyansky).
The combination of Rados and Troyansky teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
The notification identifying an IP address associated with the security threat and the security response being scoped to traffic associated with the identified IP address by applying the security policy to network traffic having the identified IP address as a source address or destination address.
However, in the same field of endeavor, Xie teaches this limitation as, (column 8, line 5-12 of Xie, in one embodiment, selective sinkholing of malware domains by a security device via DNS poisoning further includes generating an alert if a packet is sent to the designated sinkholed IP address. For example, the alert can indicate an identifier of the local host that sent the packet to the designated sinkholed IP address) and (column 13, line 1-8, a policy check engine 306 determines whether any policies can be applied based on the IP address and port number. For example, if a packet has a destination IP address that matches a designated sinkholed IP address, then this can be used to apply a sinkholing policy, such as to drop the packet and to log data associated with the session (e.g., in a session log so that the host associated with the packet is identified in the session log, which can be used to identify the host as an infected host)) and (column 9, line 29-35 of Xie, security device 102 is implemented using a data appliance (e.g., a security appliance), a gateway (e.g., a security server), a server (e.g., a server that executes security software including firewall 118), and/or some other security device, which, for example, can be implemented using computing hardware, software, or various combinations thereof).
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 teaching of Rados and Troyansky to include the above limitation using the teaching of Xie in order to enhance the security of the computing system by facilitating identification of an infected host by the security device (see abstract of Xie).
Claim 14 is rejected under the same reason set forth in rejection of claim 1.
As per claim 5 Rados in view of Troyansky and further in view of Xie discloses:
The gateway device of claim 1, wherein the security response includes an additional notification to a node associated with the gateway device and the network causing the node to emit a visual indication. (Paragraph 46 of Rados, reporting component 335 may generate and/or output reports based on information received from device behavior component 310, traffic security policy component 315, device security policy component 320, traffic analysis component 325, and/or remedial action component 330. For instance, reporting component 335 may generate a report (e.g., a graphical and/or a textual report) that includes information regarding potential security threats that are identified by traffic analysis component 325).
Claim 18 is rejected under the same reason set forth in rejection of claim 5.
As per claim 6 Rados in view of Troyansky and further in view of Xie discloses:
The gateway device of claim 1, wherein the security response includes a push notification transmitted to an endpoint on the network, wherein the endpoint is associated with the device. (Paragraph 47 of Rados, which may correspond to a report provided by reporting component 335. In some implementations, user interface 400 may be presented by user device 210. For instance, depending on configuration information stored by gateway configuration component 305, reporting component 335 may provide user interface 400 to a particular user device 210 that corresponds to an administrator associated with ASGW 220. In some implementations, reporting component 335 may provide user interface 400 to one or more other user devices 210).
Claim 19 is rejected under the same reason set forth in rejection of claim 6.
As per claim 7 Rados in view of Troyansky and further in view of Xie discloses:
The gateway device of claim 6, wherein the push notification includes a description of the security threat and a mitigation procedure associated with the security threat. (Paragraph 16 of Rados, the example security procedures described above with respect to automated security gateway 110 may be performed based on analyzing behavior of one or more user devices 105, and identifying potential security threats when traffic outputted by user devices 105 deviates significantly from the usual behavior. Further, in some implementations, automated security gateway 110 may generate reports regarding traffic analyzed by automated security gateway 110 and/or security threats identified by automated security gateway 110).
Claim 20 is rejected under the same reason set forth in rejection of claim 7.
As per claim 8 Rados in view of Troyansky and further in view of Xie discloses:
The gateway device of claim 1, wherein the security response includes a notification transmitted to an endpoint on the network and associated with the device, wherein the notification causes the endpoint to emit a visual indication. (Paragraph 46 of Rados, reporting component 335 may generate and/or output reports based on information received from device behavior component 310, traffic security policy component 315, device security policy component 320, traffic analysis component 325, and/or remedial action component 330. For instance, reporting component 335 may generate a report (e.g., a graphical and/or a textual report) that includes information regarding potential security threats that are identified by traffic analysis component 325).
Claim 21 is rejected under the same reason set forth in rejection of claim 8.
As per claim 9 Rados in view of Troyansky and further in view of Xie discloses:
The gateway device of claim 1, wherein the security response includes transmitting a generated Short Message Service (SMS) message to a mobile device associated with the device. (Paragraph 46 of Rados, reporting component 335 may generate and/or output reports based on information received from device behavior component 310, traffic security policy component 315, device security policy component 320, traffic analysis component 325, and/or remedial action component 330. For instance, reporting component 335 may generate a report (e.g., a graphical and/or a textual report) that includes information regarding potential security threats that are identified by traffic analysis component 325).
Claim 22 is rejected under the same reason set forth in rejection of claim 9.
As per claim 10 Rados in view of Troyansky and further in view of Xie discloses:
The gateway device of claim 1, wherein the security response transmits notifications to devices in a device group associated with the device, wherein each device in the device group includes notification preferences. (Paragraph 46 of Rados, reporting component 335 may generate and/or output reports based on information received from device behavior component 310, traffic security policy component 315, device security policy component 320, traffic analysis component 325, and/or remedial action component 330. For instance, reporting component 335 may generate a report (e.g., a graphical and/or a textual report) that includes information regarding potential security threats that are identified by traffic analysis component 325).
Claim 23 is rejected under the same reason set forth in rejection of claim 10.
As per claim 11 Rados in view of Troyansky and further in view of Xie discloses:
The gateway device of claim 1, wherein the device is part of a group of predefined devices defined within the gateway device selected to receive the notification. (Paragraph 10 of Rados, user devices 105 may be associated with a network (e.g., connected to a router), and may be in communication with automated security gateway 110. Automated security gateway 110 may analyze traffic outputted by user devices 105 in order to identify potential security threats to the network).
Claim 24 is rejected under the same reason set forth in rejection of claim 11.
As per claim 26 Rados discloses:
A gateway device, comprising: a processing system that includes processor circuitry and memory circuitry that stores code, the processing system configured to cause the gateway device to: monitor network traffic of a network on the gateway device; (paragraph 10 of Rados, user devices 105 may be associated with a network (e.g., connected to a router), and may be in communication with automated security gateway 110. Automated security gateway 110 may analyze traffic outputted by user devices 105 in order to identify potential security threats to the network).
Initiate a security response associated with a security policy; (paragraph 26 of Rados, ASGW 220, according to some implementations. As shown, example ASGW 220 may include gateway configuration component 305, device behavior component 310, traffic security policy component 315, device security policy component 320, traffic analysis component 325, remedial action component 330, and reporting component 335) and (paragraph 43 of Rados, Traffic analysis component 325 may receive and/or analyze traffic, outputted by user devices 210, and may determine whether the traffic should be allowed to be forwarded to its intended destination, or whether remedial action (such as blocking the traffic, reporting the potential security threat, etc.) should be taken. Traffic analysis component 325 may make such a determination based on information received from, for example, device behavior component 310, traffic security policy component 315, and/or device security policy component 320).
Output the notification associated with the security response to a device; Paragraph 42 of Rados, ASGW 220 may send alerts to user device 210, indicating that traffic sent to and/or from user device 210 has been blocked).
Wherein the notification includes a description of the security threat and a mitigation procedure associated with the security threat. (Paragraph 16 of Rados, the example security procedures described above with respect to automated security gateway 110 may be performed based on analyzing behavior of one or more user devices 105, and identifying potential security threats when traffic outputted by user devices 105 deviates significantly from the usual behavior. Further, in some implementations, automated security gateway 110 may generate reports regarding traffic analyzed by automated security gateway 110 and/or security threats identified by automated security gateway 110).
Rados teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
Receive a notification that the network traffic indicates a security threat to the network.
However, in the same field of endeavor, Troyansky teaches this limitation as, (paragraph 63 of Troyansky, a traffic analyzer 750 on a gateway 760 monitors incoming and outgoing traffic from at least one computerized device 720 to a site 780 and analyzes the sensitivity and the risk involved in the scenario. The results are sent for analysis to the decision system 770, which decides about the required action and sends instructions accordingly (such as "block", "quarantine" or "alert") to the gateway 760).
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 teaching of Rados to include the above limitation using the teaching of Troyansky in order to establish a secure data communication by analyzing the communication using the decision system and receive the required action to mitigate risk associated with the communication (see paragraph 63 of Troyansky).
The combination of Rados and Troyansky teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
The notification identifying an IP address associated with the security threat and the security response being scoped to traffic associated with the identified IP address by applying the security policy to network traffic having the identified IP address as a source address or destination address.
However, in the same field of endeavor, Xie teaches this limitation as, (column 8, line 5-12 of Xie, in one embodiment, selective sinkholing of malware domains by a security device via DNS poisoning further includes generating an alert if a packet is sent to the designated sinkholed IP address. For example, the alert can indicate an identifier of the local host that sent the packet to the designated sinkholed IP address) and (column 13, line 1-8, a policy check engine 306 determines whether any policies can be applied based on the IP address and port number. For example, if a packet has a destination IP address that matches a designated sinkholed IP address, then this can be used to apply a sinkholing policy, such as to drop the packet and to log data associated with the session (e.g., in a session log so that the host associated with the packet is identified in the session log, which can be used to identify the host as an infected host)) and (column 9, line 29-35 of Xie, security device 102 is implemented using a data appliance (e.g., a security appliance), a gateway (e.g., a security server), a server (e.g., a server that executes security software including firewall 118), and/or some other security device, which, for example, can be implemented using computing hardware, software, or various combinations thereof).
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 teaching of Rados and Troyansky to include the above limitation using the teaching of Xie in order to enhance the security of the computing system by facilitating identification of an infected host by the security device (see abstract of Xie).
As per claim 30 Rados in view of Troyansky and further in view of Xie discloses:
The gateway device of claim 26, wherein the security response includes a notification transmitted to an endpoint on the network and associated with the device, wherein the notification causes the endpoint to emit a visual indication. (Paragraph 46 of Rados, reporting component 335 may generate and/or output reports based on information received from device behavior component 310, traffic security policy component 315, device security policy component 320, traffic analysis component 325, and/or remedial action component 330. For instance, reporting component 335 may generate a report (e.g., a graphical and/or a textual report) that includes information regarding potential security threats that are identified by traffic analysis component 325).
Claims 2, 12-13, 15, 25 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Rados (US Pub. 2015/0067816) in view of Troyansky (2009/0241196) and further in view of Xie (US 9,325,735) and further in view of Jones (US Pub. No. 2023/0336573).
As per claim 2 Rados in view of Troyansky and further in view of Xie discloses:
The gateway device of claim 1, wherein the processing system is further configured to cause the gateway device to: analyze the security threat; select a mitigation procedure for the security threat; and include the mitigation procedure with the security response, wherein the mitigation procedure prevents further activity by the security threat. (Paragraph 10 of Rados, automated security gateway 110 may analyze traffic outputted by user devices 105 in order to identify potential security threats to the network. Automated security gateway 110 may allow or deny traffic, outputted by user devices 105, to be transmitted to network 115 (e.g., the Internet). Automated security gateway 110 may, in some implementations, be configured by a service provider (e.g., an Internet service provider), an administrator associated with the network, a user of user device 105, and/or another user or device. By allowing service provider configuration of automated security gateway 110, service provider may gain enhanced levels of control over preventing potential security threats from affecting the service provider's network).
The combination of Rados, Troyansky and Xie teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
The method of having a threat intelligence platform containing a collection of information related to known security threats.
However, in the same field of endeavor, Jones teaches this limitation as, (paragraph 51 of Jones, the security management facility 122 may provide protection from a variety of threats by providing, as non-limiting examples, endpoint security and control, email security and control, web security and control, reputation-based filtering, machine learning classification, control of unauthorized users, control of guest and non-compliant computers, and more) and (paragraph 52 of Jones, the security management facility 122 may provide malicious code protection to a compute instance. The security management facility 122 may include functionality to scan applications, files, and data for malicious code, remove or quarantine applications and files, prevent certain actions, perform remedial actions, as well as other security measures. Scanning may use any of a variety of techniques, including without limitation signatures, identities, classifiers, and other suitable scanning techniques).
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 teaching of Rados, Troyansky and Xie to include the above limitation using the teaching of Jones in order to protect the computing system from variety of threats using a machine learning/threat intelligence platform (see paragraph 51 of Jones).
Claims 15 and 27 are rejected under the same reason set forth in rejection of claim 2.
As per claim 12:
The gateway device of claim 1, wherein the processing system is further configured to cause the gateway device to select a mitigation procedure for one or more security threats. (Paragraph 45 of Rados, in cases where traffic analysis component 325 determines that remedial action should be taken on traffic, remedial action component 330 may determine the type of remedial action to take, and/or may take the remedial action. In some implementations, remedial action component 330 may determine the type of remedial action based on the type of potential security threat identified by traffic analysis component 325).
The combination of Rados, Troyansky and Xie teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
The method of having a threat intelligence platform.
However, in the same field of endeavor, Jones teaches this limitation as, (paragraph 88 of Jones, the threat detection tools 314 may include any of the threat detection tools, algorithms, or techniques described herein, or any other tools for detecting threats or potential threats within an enterprise network. This may, for example, include network behavioral tools, machine learning models, and so forth).
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 teaching of Rados, Troyansky and Xie to include the above limitation using the teaching of Jones in order to protect the computing system from variety of threats using a machine learning/threat intelligence platform (see paragraph 51 of Jones).
As per claim 13:
The combination of Rados, Troyansky and Xie teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
The gateway device of claim 12, wherein the threat intelligence platform is trained and updated using attacking signatures associated with the one or more security threats.
However, in the same field of endeavor, Jones teaches this limitation as, (paragraph 67 of Jones, as threats are identified and characterized, the definition facility 114 of the threat management facility 100 may manage definitions used to detect and remediate threats. For example, identity definitions may be used for recognizing features of known or potentially malicious code and/or known or potentially malicious network activity. Definitions also may include, for example, code or data to be used in a classifier, such as a neural network or other classifier that may be trained using machine learning. Updated code or data may be used by the classifier to classify threats. In some implementations, the threat management facility 100 and the compute instances 10-26 may be provided with new definitions periodically to include most recent threats. Updating of definitions may be managed by the update facility 120, and may be performed upon request from one of the compute instances 10-26, upon a push, or some combination. Updates may be performed upon a time period, on demand from a device 10-26, upon determination of an important new definition or a number of definitions, and so on).
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 teaching of Rados, Troyansky and Xie to include the above limitation using the teaching of Jones in order to protect the computing system from variety of threats using an updated definition/signature (see paragraph 67 of Jones).
As per claim 25:
The combination of Rados, Troyansky and Xie teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
The method of claim 14, further comprising: inputting network packets associated with the network into a machine learning (ML) model trained to detect attack signatures from contents contained in the network packets; outputting, by the machine learning model, an attack signature indicating a second security threat; selecting a mitigation procedure for the second security threat according to a threat intelligence platform; and in response to outputting the attack signature by the machine learning model, performing a second security response based on the security policy, wherein the security response includes the mitigation procedure and a second notification.
However, in the same field of endeavor, Jones teaches this limitation as, (paragraph 88 of Jones, The threat detection tools 314 may include any of the threat detection tools, algorithms, or techniques described herein, or any other tools for detecting threats or potential threats within an enterprise network. This may, for example, include network behavioral tools, machine learning models, and so forth. In general, the threat detection tools 314 may use network traffic data caused by endpoints within the enterprise network, as well as any other available context such as heartbeats, to detect malicious software or potentially unsafe conditions for a network or endpoints connected to the network. In one aspect, the threat detection tools 314 may usefully monitor network activity data from a number of endpoints (including, e.g., network components such as gateways, routers and firewalls) for improved threat detection in the context of complex or distributed threats).
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 teaching of Rados, Troyansky and Xie to include the above limitation using the teaching of Jones in order to protect the computing system from variety of threats using an threat detection tools (see paragraph 88 of Jones).
Claims 3-4, 16-17 and 28-29 are rejected under 35 U.S.C. 103 as being unpatentable over Rados (US Pub. 2015/0067816) in view of Troyansky (2009/0241196) and further in view of Xie (US 9,325,735) and further in view of Istomin (US Pub. No. 2017/0264636).
As per claim 3:
The combination of Rados, Troyansky and Xie teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
The gateway device of claim 1, wherein the security response causes the gateway device to emit a visual indication.
However, in the same field of endeavor, Istomin teaches this limitation as, (Paragraph 40 of Istomin, the security buffer device 100 can comprise an audio or visual alert means to provide an indication that a network's security has been breached. An audio alert can be communicated via a speaker or the like and the visual alert can comprise a light emitting diode (LED), a display shown on a display screen, or the like) and (paragraph 32 of Istomin, In one embodiment, one side of the security buffer device communicates with the end-user device and acts as a gateway to an external network, and the other side of the security buffer device communicates with the external network).
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 teaching of Rados, Troyansky and Xie to include the above limitation using the teaching of Istomin in order to alert the user/device about the security issue and protect the computing system (see paragraph 40 of Istomin).
Claims 16 and 28 are rejected under the same reason set forth in rejection of claim 3.
As per claim 4:
The combination of Rados, Troyansky and Xie teaches the method of monitoring the network traffic using a gateway (see paragraphs 10 of Rodas) but fails to disclose:
The gateway device of claim 1, wherein the security response causes the gateway device to emit a audio indication.
However, in the same field of endeavor, Istomin teaches this limitation as, (Paragraph 40 of Istomin, the security buffer device 100 can comprise an audio or visual alert means to provide an indication that a network's security has been breached. An audio alert can be communicated via a speaker or the like and the visual alert can comprise a light emitting diode (LED), a display shown on a display screen, or the like) and (paragraph 32 of Istomin, In one embodiment, one side of the security buffer device communicates with the end-user device and acts as a gateway to an external network, and the other side of the security buffer device communicates with the external network).
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 teaching of Rados, Troyansky and Xie to include the above limitation using the teaching of Istomin in order to alert the user/device about the security issue and protect the computing system (see paragraph 40 of Istomin).
Claims 17 and 29 are rejected under the same reason set forth in rejection of claim 4.
Conclusion
The prior art made or record and not relied upon is considered pertinent to applicant’s disclosure is Shulman (US Pub. No. 2015/0013006). Shulman’s reference discloses:
According to one embodiment, a method for setting a trap to detect that an intruder has compromised a client end station (CES) in an attempt to gain unauthorized access to enterprise data provided by a server is described. The method includes causing a honey token to be placed on the CES secluded within a configuration repository, wherein the honey token is metadata and/or instructions indicating how applications can seemingly access the enterprise data but that is actually invalid, and the honey token is placed on the CES and not on the server. The method also includes causing attribute values to be installed on a security gateway for a security rule causing the security gateway to monitor network traffic for attempted use of the honey token, and to generate an alert when a set of one or more packets that include the honey token are received.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TESHOME HAILU whose telephone number is (571)270-3159. The examiner can normally be reached M-F 8 a.m. - 5 p.m..
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, Ali Shayanfar can be reached at (571) 270-1050. 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.
/TESHOME HAILU/Primary Examiner, Art Unit 2434