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 .
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 1 – 10, 12, 13 and 15 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Narayanaswamy (US Pub. No. 2014/0259093) in view of Gupta (US Pub. No. 20180295134)
Per claim 1, Narayanaswamy is relied upon to teach during a user authentication (reads on "login provide user credentials to hosted service to authenticate the user," see
Narayanaswamy para [0076]) to a web service (reads on "passing the login to the hosted service," see Narayanaswamy para [0019]) at a web browser (reads on "the login form email address is used to update the user field," see Narayanaswamy para [0075]), determine (reads on "the URL is directly received and subject to analysis," see Narayanaswamy para [0041]) one or more updates (reads on "the login form email address is used to update the user field," see Narayanaswamy para [0075] to a state of the web browser (reads on "the application session is identified by a session cookie in the HTTP header," see Narayanaswamy para [0076]); report (reads on "the request is signed using the user identity and routed to the network security system 120," see Narayanaswamy para [0046]) the one or more updates to the state of the web browser (reads on "the user identity embedded in the data or within the secure tunnel headers," see Narayanaswamy para [0025]) to an assessment entity (reads on "the user identity 156 is a certificate that is used to sign the packets routed to the network security system 120," see Narayanaswamy para [0037]); and at the assessment entity (reads on "the policy is applied based on the user identity 156," see Narayanaswamy para [0047]), identify a context of the user authentication (reads on "the crawling process identifies a list of URLs corresponding to login events for various hosted services," see Narayanaswamy para [0044]) based on the one or more updates to the state of the web browser (reads on "Deep packet inspection logic can identify these events and link policy evaluations to each transaction boundary," see Narayanaswamy para [0076]). The prior art of record is silent on explicitly stating state-information update at the browser.
Gupta is relied upon to teach
state-information update at the browser (reads on "generate a session cookie corresponding to an authenticated session between the client 102 a-n and the server 106 a-n to keep track of state information of the authenticated session," see Gupta para [0374]).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the prior art’s cloud mediated user-context-discovery architecture in which a browser add-on observes the login event and the HTTP session cookie and reports those observations to a network security policy engine by integrating the post-authentication session-cookie state-tracking technique of Gupta et al, (Gupta), which itself states: "the authentication 1206 may generate a session cookie corresponding to an authenticated session between the client 102 a-n and the server 106 a-n to keep track of state information of the authenticated session" (see Gupta para [0374] to realize the instant limitations directed to determining browser-state updates during a user authentication and identifying the authentication context therefrom. One or more of the underpinning rationales discussed in KSR MPEP 2143 {A, C, F, G}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have augmented Narayanaswamy’s browser add-on reporting pipeline which already routes the URL, user identity, and session cookie to the network security system 120 with Gupta's session-cookie generation/cookie-jar state-tracking, so that the combined system captures the resulting session-cookie state update during authentication and reports it to the assessment entity for context identification, as recited in the instant claims, by applying HTTP-native session state-cookie pattern to the existing browser-add-on monitoring channel of Narayanaswamy. One of ordinary skill in the art in enterprise browser-security would have recognized that Narayanaswamy, while disclosing URL-heuristic and login form email observation, does not enumerate a dedicated post-authentication session-cookie generation step, and that Gupta's session-cookie state tracking was a known, predictable solution to exactly that gap, requiring no change to Narayanaswamy's underlying principle of routing authenticated traffic through the network security system 120 for policy enforcement. The combination is further supported by MPEP 2143 Rationale A (combining prior-art elements according to known methods to yield predictable results) and Rationale C (use of a known technique to improve similar devices in the same way), and is additionally consistent with Rationale F (obvious to try among a finite set of identified session-tracking solutions) and Rationale G (teaching, suggestion, or motivation in the prior art — Narayanaswamy para [0076] identifies the session cookie as the mechanism connecting login events to subsequent session activity). The motivation to combine these references applies to all claims under this heading and is also therefore grounded in the references’ shared field, the predictable result of the combination, and Narayanaswamy's own expressed need for robust login-event identification and session tracking.
Per claim 2, the prior art of record further suggests the assessment entity (reads on "routed to the network security system 120," see Narayanaswamy para [0046]) is external to the web browser (reads on "redirect the browsers to an explicit proxy," see Narayanaswamy para [0025]).
Per claim 3, the prior art of record further suggests the one or more updates to the state of the web browser (reads on "the application session is identified by a session cookie in the HTTP header," see Narayanaswamy para [0076]) are made in dependence on (reads on "the response from the hosted service is received...this response is typically inspected and subjected to policy," see Narayanaswamy para [0049]) one or more responses received from the web service (reads on "the response from the hosted service is received using the client identity," see Narayanaswamy para [0049]).
Per claim 4, the prior art of record further suggests the context comprises (reads on "the login form email address is used to update the user field," see Narayanaswamy para [00751) a username (reads on "the login form email address," see Narayanaswamy para [0075]) of a user that is a subject of the user authentication (reads on "used to update the user field if later the login is successful," see Narayanaswamy para [0075]).
PNG
media_image1.png
5
3
media_image1.png
Greyscale
Per claim 5 the prior art of record further suggests the one or more updates to the state of the web browser comprise (reads on "the application session is identified by a session cookie in the HTTP header," see Narayanaswamy para [0076]) one or more of an addition to (reads on "the authentication 1206 may generate a session cookie corresponding to an authenticated session between the client 102 a-n and the server 106 a-n to keep track of state information of the authenticated session," see Gupta para [0374]) or modification of (reads on "the login form email address is used to update the user field if later the login is successful," see Narayanaswamy para [0075]) one or more cookies stored by the web browser (reads on "the application session is identified by a session cookie in the HTTP header," see Narayanaswamy para [0076]).
Per claim 6, the prior art of record further suggests the instructions further cause the assessment entity to filter cookies (reads on "the cookie proxy may remove cookies from the header of the response that are not configured or otherwise identified as client consumed cookies and store them in a cookie jar used for the current session," see Gupta para [0271]) reported by the web browser (reads on "the application session is identified by a session cookie in the HITP header," see Narayanaswamy para [0076]) to determine one or more cookies related to the user authentication (reads on "the authentication 1206 may generate a session cookie corresponding to an authenticated session between the client 102 a-n and the server 106 a-n to keep track of state information of the authenticated session," see Gupta para [0374]) based on one or more properties of the cookie (reads on "the cookie proxy may remove cookies from the header of the response that are not configured or otherwise identified as client consumed cookies and store them in a cookie jar used for the current session," see Gupta para [0271]).
Per claim 7, the prior art of record further suggests the assessment entity (reads on "The landing page is a specific URL hosted, or controlled, by the network security system 120," see Narayanaswamy para [0099]) is dynamically updatable (reads on "The identifier is typically unique for each visit to the landing page to prevent replay attacks," see Narayanaswamy para [0099]. The Examiner further asserts "the policy 159 can also be periodically updated from the network security system 120 by the client 155" (see Narayanaswamy para [0037]) and "the add-on regularly updates the proxy auto-config (PAC) file for the browser" (see Narayanaswamy para [0036])).
Per claim 8, the prior art of record further suggests the instructions further cause the assessment entity to assess (reads on "the policy is applied based on the user identity 156," see Narayanaswamy para [0047]) the one or more updates to the state of the web browser against one or more criteria (reads on "the policy is applied based on the user identity 156," see Narayanaswamy para [0047]); and after a determination that the assessment meets one or more of the criteria (reads on "If multiple policies match, different rules can be used by the system to pick the priority," see Narayanaswamy para [0064]) perform a security action (reads on "The most common actions are permit, block (or deny), redirect...log, reset...and encrypt," see Narayanaswamy para [0064]).
Per claim 9, the prior art of record further suggests the instructions further cause the assessment entity to assess (reads on "the policy is applied based on the user identity 156," see Narayanaswamy para [0047]) the updates to the state of the web browser (reads on "the policy is applied based on the user identity 156," see Narayanaswamy para [0047]) against one or more security policies (reads on "The most common actions are permit, block (or deny), redirect...log, reset...and encrypt," see Narayanaswamy para [0064]).
Per claim 10, the prior art of record further suggests the security action comprises storing a log of an event (reads on "The most common actions are permit, block (or deny), redirect...log," see Narayanaswamy para [0064]), reporting the activity to an entity external to the computer device (reads on "redirect (asks client to go to another site, might prompt user to request permissions from the administrator)," see Narayanaswamy para [0064]) causing operation of the web browser to be altered or blocked (reads on "block (or deny)...reset (drops the TCP connection)," see Narayanaswamy para [0064]).
Per claim 12, the prior art of record further suggests the web browser is capable of invoking one or more web browser extensions (reads on "the browser add-on, or extension—the terms will be used interchangeably—functions in an analogous fashion to existing web browser PAC files," see Narayanaswamy para [0036]) to monitor web activity (reads on "the traffic needed to apply the policy to is rerouted and it is done so within the application," see Narayanaswamy para [0025]) and extract web page content from the web browser (reads on "the user identity embedded in the data or within the secure tunnel headers," see Narayanaswamy para [0025]).
Per claim 13, the prior art of record further suggests the assessment entity comprises a scripting engine (reads on "Embedded javascript in the landing page can determine the validity of the response," see Narayanaswamy para [0099]) to perform one or more of: controlling functionality of the one or more web browser extensions (reads on "the add-on will detect the HTML element with the identifier and generated a response...Embedded javascript in the landing page can determine the validity of the response," see Narayanaswamy para [0099]), correlating reported information to detect a successful user authentication (reads on "the login form email address is used to update the user field if later the login is successful," see Narayanaswamy para [0075]) and tracking subsequent activity of the web browser (reads on "Deep packet inspection logic can identify these events and link policy evaluations to each transaction boundary," see Narayanaswamy para [0076]).
Per claim 15, the prior art of record further suggests the instructions further cause the assessment entity to track (reads on "the policy is applied based on the user identity 156" and "the request is signed using the user identity and routed to the network security system 120," see Narayanaswamy para [0046]) subsequent activity by a user that is a subject of the user authentication (reads on "the user identity 156 is a certificate that is used to sign the packets routed to the network security system 120," see Narayanaswamy para [0037]) the web browser is configured to annotate web activity by the user (reads on "the user identity embedded in the data or within the secure tunnel headers," see Narayanaswamy para [0025]) with a tracking token (reads on "generate a session cookie corresponding to an authenticated session...to keep track of state information of the authenticated session," see Gupta para [0374]).
Per claim 16, the prior art of record further suggests the tracking token comprises a tracking cookie (reads on "the authentication 1206 may generate a session cookie corresponding to an authenticated session between the client 102 a-n and the server 106 a-n," see Gupta para [0374]) the tracking cookie is scoped to a same domain (reads on "a session cookie corresponding to an authenticated session between the client 102 a-n and the server 106 a-n”, see Gupta para [0374]) and cookie store as used by the web browser for the user authentication (reads on "store them in a cookie jar used for the current session," see Gupta para [0271]).
Per claim 17, the prior art of record further suggests the instructions further cause the assessment entity to analyze (reads on "the policy is applied based on the user identity 156," see Narayanaswamy para [0047]) subsequent web activity annotated with the information indicative of a user (reads on "the request is signed using the user identity and routed to the network security system 120," see Narayanaswamy para [0046]) that is the subject of the user authentication (reads on "Deep packet inspection logic can identify these events and link policy evaluations to each transaction boundary," see Narayanaswamy para [0076]) to obtain user state information corresponding to the web activity (reads on "the application session is identified by a session cookie in the HTTP header," see Narayanaswamy para [0076]).
Per claim 18, the prior art of record further suggests the instructions further cause the web browser to send (reads on "the request is signed using the user identity and routed to the network security system 120," see Narayanaswamy para [0046]) content from one or more web pages visited using the web browser (reads on "the login form email address is used to update the user field," see Narayanaswamy para [0075]) to the assessment entity (reads on "the response from the hosted service is received...this response is typically inspected and subjected to policy," see Narayanaswamy para [0049]).
Claim 19 is analyzed with respect to claim 1.
Claim 20 is analyzed with respect to claim 1.
Claims 11 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Narayanaswamy in view of Gupta in view of Sokolov (US Patent No. 9117061)
Per claim 11, the prior art of record further suggests the computer device is associated with a corporate network (reads on "a corporate administrator may be able to tell if a particular enterprise user is using more than one accounts to access the same hosted service," see Narayanaswamy para [0099]) the instructions further cause the assessment entity to perform a security action (reads on "The most common actions are permit, block (or deny), redirect, log, reset, and encrypt," see Narayanaswamy para [0064]) based on a determination that non-corporate credentials have been used (reads on "This can differentiate between a user logged into an application as jsmith@example.com and the same application as jsmith@myisp.com," see Narayanaswamy para [0099]). The prior art of record is silent on explicitly stating for the user authentication. Sokolov is relied upon to teach (reads on "display of an authentication form in a browser window associated with a first flow to a target server," see Sokolov, Claim 1).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the session-cookie-based browser-state tracking architecture of the prior art of record by integrating the authenticated-session cookie generation teaching of Gupta and the authentication-result cookie teaching of Sokolov, as Gupta itself states: "the authentication 1206 may generate a session cookie corresponding to an authenticated session between the client 102 a-n and the server 106 a-n to keep track of state information of the authenticated session" (see Gupta para [0374] ), to realize the instant limitation that the browser-state updates comprise an addition to or modification of one or more cookies. One or more of the underpinning rationales discussed in KSR MPEP 2143 {A, C, F, G}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have configured the prior art’s network security system to treat the addition or modification of a session cookie as the monitored browser-state update, as recited in the instant claims, by applying the authenticated-session cookie-generation technique of Gupta to Narayanaswam’s existing session-cookie identification structure. One of ordinary skill in the art in enterprise browser-security would have recognized that Narayanaswamy already anchors its session model on the session cookie in the HTTP header but does not exhaustively enumerate that the monitored update is a cookie addition or modification, and that Gupta's and Sokolov's cookie-generation teachings were a known, predictable solution to exactly that gap, requiring no change to Narayanaswam’s underlying principle of routing authenticated sessions through the network security system. The combination is further supported by MPEP 2143 Rationale A (combining prior-art elements according to known methods to yield predictable results) and Rationale C (use of a known technique to improve similar devices in the same way), and is additionally supported by Rationale F (obvious to try among a finite number of identified, predictable solutions) and Rationale G (teaching, suggestion, or motivation in the prior art, where Narayanaswamy para [0076] itself identifies the session cookie as the session identifier). The motivation to combine is applied to all references under this heading and also arises directly from the shared objective of all three references — reliably tracking authenticated browser sessions by their cookie state making the combination an obvious and predictable application of known cookie-handling techniques to Narayanaswamy's existing architecture.
Claim 14 is analyzed with respect to claim 11. The prior art of record further suggests user authentication is performed using a form-based login (reads on "display of an authentication form in a browser window associated with a first flow to a target server," see Sokolov, Claim 1) providing credentials directly to the web service (reads on "the client may encrypt the sign on credentials before passing the login to the hosted service," see Narayanaswamy para [0019]) or to a third party authentication server using an authentication protocol (reads on "login—provide user credentials to hosted service to authenticate the user," see Narayanaswamy para [0076]).
Conclusion
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