Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
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 – 3, 8 – 10, 15 – 16 and 19 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Grajek (US Pub. No. 2015/0237038 A1) in view of Jackson (US Pub. No. 2018/0288060 A1).
Per claim 1, Grajek (US Pub. No. 2015/0237038 A1) is relied upon to teach a system comprising (see Grajek Figure 1): a web server configured to send (reads on web server 103a communicates via HTTP/HTTPS and serves web-based content to users who browse to the enterprises’ s web resources, see Grajek para 0024 and 0035 – 0036) a webpage document (reads on a web resource provided by the web server, see Grajek para 0024); a validation server (reads on an authentication server/service/system, that performs validation functions that validates user authentication attempts and communicates with user devices over the network, see Grajek para 0032 – 0033 and Figure 1 and 6); and a user device comprising (see Grajek Figure 1 blocks 110a/b): at least one first processor (see Grajek Figure 1 block 110a); and memory storing first computer-readable instructions that (see Grajek Figure 1 block 110a), when executed by the at least one first processor, cause the user device to (see Grajek para 0030 – 0031 and Figure 1 block 110a): receive (reads on the user device’s browser receives webpage documents from the web server when the user browses to enterprise resources and the web server sends information to the device’s browser to server web applications and content, see Grajek para 0024 and 0036), from the web server (reads on web server 103a communicates via HTTP/HTTPS and serves web-based content to users who browse to the enterprises’ s web resources, see Grajek para 0024 and 0035 – 0036), the webpage document (reads on a web resource provided by the web server, see Grajek para 0024); send (reads on the user device sends user credentials/username/password to the web server for authentication and the user initially authenticates to the web server using username and password credentials, see Grajek para 0024 – 0025 and 0078 and 0085 – 0086), to the web server (reads on web server 103a communicates via HTTP/HTTPS and serves web-based content to users who browse to the enterprises’ s web resources, see Grajek para 0024 and 0035 – 0036), an indication of user credentials associated with (reads on exemplary user ID and password, see Grajek para 0024 – 0025 and 0078 and 0085 – 0086) the webpage document (reads on a web resource provided by the web server, see Grajek para 0024); determine (reads on collecting device characteristics such as device screen resolution, user’s time zone, OS/browser language, see Grajek 0041 – 0044 and 0050 – 0051), a first user profile (reads on a fingerprint/device ID associated with a user ID that links a user ID with particular device characteristics, see Grajek para 0041 – 0044 and 0050 – 0051) comprising at least one of a screen resolution setting associated with the user device (reads on display resolution/device screen resolution, see Grajek para 0050 – 0051), a language setting associated with the user device (reads on OS/browser language, see Grajek para 0042 and 0051), or a time zone setting associated with the user device (reads on a user’s time zone, see Grajek para 0051); and send (reads on Grajek Figure 6 blocks 610 and 612), to the validation server (reads on an authentication server/service/system, that validates user authentication attempts and communicates with user devices over the network, see Grajek para 0032 – 0033 and Figure 1 and 6), an indication of the first user profile (reads on a fingerprint/device ID associated with a user ID that links a user ID with particular device characteristics, see Grajek para 0041 – 0044 and 0050 – 0051), wherein the sending the indication of the first user profile comprises sending the indication of the first user profile when (reads on the transmitting of the user credentials and the user profile/device ID can be transmitted in any order or in parallel, see Grajek para 0024 – 0025 and 0173) the user credentials are being input (reads on the username and password/first authentication factor, see Grajek para 0024 – 0025) at the user device (see Grajek Figure 1 blocks 110a/b); wherein the validation server comprises (reads on an authentication server/service/system that validates user authentication attempts and communicates with user devices over the network, see Grajek para 0032 – 0033 and Figures 1, 6 and 12): at least one second processor (see Grajek para 0159 – 0162 and Figure 12 block 1204); and memory storing second computer-readable instructions that (see Grajek para 0159 – 0162 and Figure 12 blocks 1206 and 128), when executed by the at least one second processor, cause the validation server to (reads on modules configured to perform the authentication processes, see Grajek para 0159 – 0162): receive (reads on receive from user device additional factors such as a one-time password, see Grajek para 0037 – 0038 and Figure 6 block 616), from a computing device (see user device 110, see Grajek Figure 6), an indication of a one-time passcode (OTP) (reads on additional factors such as a one-time password, see Grajek para 0037 – 0038 and Figure 6 block 616), wherein the receiving the indication of the OTP further comprises receiving (reads on the authentication system receives a user ID and new device fingerprint, see Grajek para 0027 – 0028) an indication of second user profile (reads on a user ID and new device fingerprint, see Grajek para 0028. The Examiner construes the second user profile to be the same as the userID and new device fingerprint combination), wherein the second user profile comprises at least one of a screen resolution setting associated with the computing device (reads on device fingerprint comprises device characteristics such as Grajek para 0027 – 0028), a language setting associated with the computing device (reads on OS/browser language, see Grajek para 0042 and 0051), or a time zone setting associated with the computing device (reads on a user’s time zone, see Grajek para 0051); and based on determining that the second user profile is different from the first user profile (reads on determine the received fingerprint is different from the stored fingerprint, see Grajek Figure 6 block 614). The prior art of record is silent on explicitly stating send one or more notifications to one or more other computing devices.
[0024] For example, in some embodiments, a user may initially browse to an enterprise's web resource, app resource, or other network resource. For instance, the user may point his web browser to an enterprise's web-based portal to access a web-based email system on an enterprise's web server. The enterprise's web server may authenticate the user, using a username and password, and check the username and password credentials against the enterprise's directory.
[0025] After the user initially authenticates to the enterprise's web server with a username and password (i.e. a first authentication factor), the web server may redirect the user's browser running on the user computing device to a cloud based or other system that will require an additional authentication factor. Successful authentication with this additional authentication factor may be required prior to the user accessing the web-based email service. This redirect may be performed using standard W3C methods, and may include, in the redirect, user ID and other contact information such as an email address or mobile phone number.
[0027] If they match, the system may send a device characteristic capture script to the user's device to capture information about the device, such as HTTP header information, identifiers of browser plug-ins, networking addresses, screen size and/or resolution, HTML5 session storage information, Internet Explorer User Data Support information, Browser Cookie enable/disable settings, a time zone, and/or other information. After gathering this information, the capture script may instruct the user's device to send this information back to the authentication system. The authentication system may then create a hash (such as by using MD5, SHA-1, SHA-256, SHA-3, HAVAL, and/or another hash algorithm) over all of the received device characteristics. This fingerprint of the device is then stored in the authentication system's storage in association with the user ID, along with the device's characteristic values. The user device may then receive an authentication token provided by the authentication system, such as a cookie or redirect URL parameter (in plain text or encrypted), that may be returned to the enterprise's web service indicating that the user device performed the additional authentication factor.
[0028] In the future, when the user and his/her user device attempt to access the same enterprise web server (or a different enterprise web/app server), the web server may then again redirect the user's device, after the user has authenticated with a username/password, to the authentication system, again, transferring in the redirect a user ID and other contact information. The authentication system may then gather device characteristics using the capture script in the same manner, and calculate a new device fingerprint. The authentication system may then look up the user's associated stored device fingerprints by the received user ID. If that fingerprint matches any of the stored fingerprints, the device is considered to have authenticated with an additional factor of authentication without any input required from the user (e.g. no one-time password interaction required, etc.). The user device may then again receive an authentication token, such as a cookie or redirect URL parameter (in plain text or encrypted), that may be returned to the enterprise's web service indicating that the user device performed the additional authentication factor.
[0029] In this way, the fingerprint created on the fly for each device may be compared to past stored fingerprints on a per user basis. This "fingerprint" comparison may be considered an additional factor of authentication going forward, and may be used in lieu of (or in addition to) a user-interaction based, or certificate based, additional factor of authentication.
[0035] Enterprise network 120 may comprise a gateway router 115, authentication system 102, web server 103a, app server 103n, and enterprise directory 104. Enterprise network 120 may also comprise enterprise directory 104. This enterprise directory may comprise, for example, an LDAP, SQL or active directory server that stores information about users associated with enterprise network 120, which in some examples may belongs to a business or organization. The enterprise directory 104 may store information such as user IDs, user passwords, device IDs affiliated with user IDs, addressing information such as city, state, and street address, phone numbers such as mobile and textable (SMS) phone numbers or landline phone numbers, company IDs or email addresses or any other information, characteristic, or attribute associated with the users of the user devices. Enterprise directory 104 may also be used to store authentication or authorization information of the users of the user devices 110s.
[0036] Web server 103a may be a network or web service that may be desired to be accessed by of user devices 110. The web server, like normal web servers, may communicate via HTTP over the World Wide Web with user devices and may communicate over, for example, secure HTTP/TLS/SSL, such as HTTPS. Similarly, authentication system 102 may also communicate via HTTP or via HTTPS with user devices 110. For example, if a user of user device 110 desires to access the Salesforce application provided by the organization affiliated with network 120, web server 103a may send information to the device's browser in order to serve that Salesforce application to user device 110. In one example, the Salesforce application may be running on app server 103n, which may be configured to communicate over FTP, Telnet, or any other specific type of communication protocol or application service that is outside of HTTP or other World Wide Web protocols. In this way, app server 103n or web server 103a might provide a variety of network services. When a specific network service is required, such as Salesforce.TM. provided by web server 103a, authentication of the user and/or the user device 110a may be required before providing that network service or upon access of specific resources where authentication is required. Such authentication may be provided by authentication system 102.
[0041] The system described in FIG. 1 may also have the ability to extract distinct device information from a device utilizing web browser and web-based mechanisms such as Javascript. Other mechanisms may be used to extract distinct device information such as flash programs, cookies, custom downloaded and installed programs (hat is downloaded and installed through the web from the authentication system for example), or any other mechanism or instructions that may be transmitted from the authentication system to the user device 110 for collection of characteristic information about the user device, its browser, its software (e.g. OS or other applications), or its user. This characteristic information may be transferred to and stored on the authentication system or any external remote data storage, for example on enterprise directory 104 or any cloud storage.
[0042] In addition, this characteristic information may be used to calculate a fingerprint such as a hash of the combined collected characteristics in order to determine a string value that is dependent on all the characteristic information collected. For example, the authentication system 102 may send to the user computing device Javascript that collects device characteristics such as a browser language, HTTP headers, or fonts that are installed in the browser or on the computer, and receive these characteristics back from the user computing device through the Javascript mechanism sending the characteristics back to the authentication system typically through the use of the HTTP protocol, although other protocols may be used.
[0043] The authentication system will then use this information and store this information in the enterprise directory 104 or in its local storage or in the cloud. As referenced above, this characteristic information may be used to calculate a fingerprint for future comparison to other fingerprints. Similarly, for example, a one-time native mobile app such as an iPhone app, if deployed through the web to an iPhone device, may be utilized to collect and send the identification information from a device. This may be advantageous to use a program outside of a standard web browser to obtain additional fingerprinting information such as characteristics of an iPhone device that are inaccessible by the browser. This characteristic information may then be associated in enterprise directory 104, in the authentication system 102, or in the cloud, with user information such as a user ID. This creates a mapping of the user to his/her fingerprints, and a mapping of a fingerprint to a particular user that may be referenced by the authentication system 102. In some embodiments, the characteristic information of the device may be stored as collected in association with the user ID/user information and used to calculate fingerprint hash to assist in additional analysis.
[0044] The fingerprint and fingerprint characteristic information, and the user ID may then be used to validate the association of the user to a specific user device such as user computing device 110 during a subsequent authentication. In this way, the authentication system 102 may use the fingerprint as the additional factor in authentication (or in lieu of other additional factors described herein). Once the association is stored, the user's device may be considered a registered device. Once a user has registered one or more devices, the user interface on the authentication system may be used to manage the user devices and their fingerprints and characteristics that are associated with a specific user. For example, a user could delete one specific device and its characteristics/fingerprint to remove that device as registered in association with the user ID. Such a deletion may prevent the device from being used in association with that user unless the user once again registers the device and the characteristics are re-transmitted from the user device 110 to the authentication system 102. Thus, by removing a fingerprint associated with the user which is stored on the authentication system or other data storage, the association of the device to the user may be revoked, which may affect the additional authentication factors available to that user. Such deletion may be performed, either by an administrator or by the user, after successful authentication or login.
[0050] In some embodiments, instead of a device ID, a fingerprint may be created using a hashing algorithm. To create the fingerprint hash the authentication system may send a script to be run by the user computing device to pull device distinguishing characteristics from the device, its browser, its operating system, and/or from the user. These device distinguishing specifics could include, for example, browser plugin names or versions, browser flash font list, browser font lists, a display resolution, HTML5 storage support (either local storage, session storage or remote storage, and data located within these storage areas), and other device characteristics. These device distinguishing specifics could then be stored in a manner that can be retrieved and compared on subsequent authentications. In addition, these device distinguishing characteristics can be used to create a hash value that can be considered a device fingerprint (i.e. a fingerprint hash for the device).
[0051] Among other characteristics, the script or executable may pull device distinguishing characteristics from the device browser, operating system, or user, may include characteristics such as HTTP header information, including, but not limited to, one or more of any of an HTTP user-agent(s) header, the HTTP accept header, the HTTP accept-charset header, the HTTP accept-encoding header, the HTTP accept-language header, etc. The characteristics may also include a browser plugin list this may include both the names of each plugin, the versions of each plugin, and/or how they are installed. The characteristics may also include a list of fonts that the browser has installed such as browser flash fonts. The characteristics may also include device IP address and/or network card address (such as MAC address). Other operating system settings such as device screen resolution on one or more display screens or any data stored in HTML5 local storage, or HTML5 session storage. It may also include Internet explorer user data support information, or values stored therein, or browser cookie data such as enabling or disabling the browser cookie setting, or any cookie stored by the browser. It may also include the user's time zone or OS language that is installed on the operating system, among other characteristics.
[0072] Each time the network service requires the additional factor of authentication and redirects the user computing device to the authentication system, the authentication system may request the user computing device 110 to run the script/instructions and provide the characteristics unique to the authentication system 102. The authentication system 102 may then, each time the additional factor authentication is required, compute the device's fingerprint and compare it to the known fingerprint for the computing devices associated with the user authenticating. This comparison may be implemented via the tables and associations described above.
[0078] For example, FIG. 4 illustrates the interactions between the user computing device and the authentication system during validation. Once the device is registered to the device subsequent authentications appear seamless and low-friction for the user. In FIG. 4 the user computing device in communication (1) may be redirected to the authentication system for an additional factor of authentication. For example, the user may attempt to access the network service or the web service on web server 103a from a desktop or a mobile device represented by user computing device 110, and is redirected to authentication system 102 for authentication or for an additional factor of authentication.
[0085] FIG. 5 illustrates one embodiment of a cloud-based system for persistent authentication of an additional factor, in this case device fingerprint. This embodiment's configuration has the authentication system 102 directly connected to the Internet, and not deployed within the enterprise's network.
[0086] In communication (1), the user attempts to access the target application. For example, the target may be a web application, a network resource, or a software-as-a-service (SaaS) cloud application, or a native mobile application. The application may then conduct a standard authentication of user ID and password using its preexisting client server dialogue. For example, it may utilize existing data connectors to its on premise data stores such as enterprise directory 104 that may run active directory LDAT, SQL, or other data storage and user information repositories. If the target is configured to require an additional factor of authentication such as a second factor, the web server may redirect the user's user device 110 to the authentication system 102 (2), which in this scenario may be located in a cloud service.
PNG
media_image1.png
836
942
media_image1.png
Greyscale
PNG
media_image2.png
708
1056
media_image2.png
Greyscale
Jackson (US Pub. No. 2018/0288060 A1) suggests based on determining that the second user profile (reads on the observed profile, see Jackson Figure 1 block 34) is different from (reads on determine the observed profile and the known profile are different, see Jackson Figure 1 block 34 and associated text) the first user profile (reads on the known profile, see Jackson Figure 1 block 34) send one or more notifications to one or more other computing devices (reads on send message indicating the computing device is untrusted, see Jackson Figure 1 block 35 and associated text).
[0025] Upon determining that the first authentication credential is not correct, some embodiments may send a message indicating that the user is not authenticated, as indicated by block 18. In some cases, the message may be sent to the first computing device. In some cases, the message may be sent to other computing devices, such as one of the third-party software-as-a-service (SaaS) application servers described below with reference to FIG. 2. In some embodiments, a record in a user profile may include a value indicating an amount of failed authentication attempts, for instance, a log, and some embodiments may determine whether more than a threshold amount of failed authentication attempts have occurred within a threshold duration of trailing time before performing the determination of block 16, e.g., to rate limit authentication attempts and defeat or impair brute force attacks. In some cases, failed authentication attempts may also be associated with a network address or other attributes of the first computing device, regardless of the user identifier for which authentication is sought, and some embodiments may also block authentication attempts in which sufficiently similar, for example, having the same network address, computing devices have submitted authentication attempts exceeding a threshold amount in a threshold duration of time, like more than 10 in one second to detect scripted authentication brute force attacks, and more than 10 in one hour where human submissions are also of concern.
[0030] In some embodiments, the message indicating that the user is authenticated may be sent to the first computing device or one of the third-party SaaS application servers described below. In some embodiments, the message may be a computer-readable message (e.g., in the form of computer instructions or structured data) sent to one of the third-party SaaS applications via the first computing device. For example, a uniform resource identifier (URI) associated with the third-party SaaS application for which authentication is sought may be retrieved from memory, an access token may be generated based on a cryptographic key associated with the third-party SaaS application of the account, and the access token may be appended as a parameter to the URI, which may be sent to the first computing device as a redirect instruction. The redirect instruction may cause the receiving first computing device to attempt to retrieve resources from the URI with the request including the access token, and the corresponding third-party SaaS application server may receive the URI, parse the access token, and determine that the access token is valid, for instance, based on a public key of the system authenticating the user corresponding to a private key used by that system to generate the access token. In response, the third-party SaaS application server may grant access to the first computing device. Similar techniques may be implemented with on premises applications.
[0044] Next, some embodiments may determine whether the known profile corresponds to the observed profile, as indicated by block 34. This determination may be performed with a variety of different techniques, depending upon trade-offs between ease-of-use and security. Some embodiments may determine whether every attribute in the known profile that is most recent exactly matches every attribute in the observe profile, favoring security over ease-of-use to some extent. Some embodiments may determine whether more than a threshold amount (e.g., number, frequency, or percentage) of attributes match exactly between the known and observe profiles.
[0045] In some cases, certain attributes are expected to be more indicative of attacks than others, as some attributes are expected to change relatively frequently and are less indicative of the second computing device being impersonated. Accordingly, some embodiments may determine a score for each pair of attributes compared between the known profile and the observe profile and that score may be weighted based on the likelihood of differences indicating an attack. In some cases, the score is a binary value of zero or one indicating whether to values match exactly, like a device maker name, or a binary value of zero or one indicating whether a given operating system version has decremented or incremented between capturing the known profile and the observed profile. In some cases, the score is a cardinal value indicating differences between known and observed attributes, like a number of increments between application versions, or an edit distance between strings.
[0046] In some cases, the scores may be combined in a weighted combination, such as a weighted sum, by multiplying each score by a corresponding weight and summing the weighted values to determine an aggregate correspondence score. The weights may be determined with a variety of different techniques. In some cases, the weights may be hand tuned manually, for instance, by a system administrator or developer. In some cases, the weights may be changed dynamically based on feedback, such as feedback indicative of false positives or false negatives in the determination of block 34. In some cases, weights may be changed dynamically based on such feedback periodically, for instance, nightly or weekly, in advance of receiving the authentication request in block 12 (like more than an hour in advance). In some cases, the feedback may be based on records indicative of false positives and false negatives across an entire user base or a subset thereof, such as users associated with the same employer having an account with the system providing authentication. False positive records may be obtained by penetration testing exercises or helpdesk reports indicative of false positives. False negative records may be obtained through helpdesk reports, and in some cases, an agent executing on the second computing device may provide an input by which the user may report what they believe to be a false negative, producing a signal which may be logged, investigated, categorized, and used for training.
[0047] In some embodiments, weights may be trained with a supervised machine learning model, using this feedback as a training set. In some cases, a subset of the training set may be withheld for cross validation. In some cases, the training set may be subdivided for multiple instances of training (e.g., with randomized initial weights), and the results of the training instances may be compared and, for example, averaged, with bootstrap aggregation. In some embodiments, the model may be trained by executing a gradient descent that attempts to minimize an error function indicative of false positives and false negatives (which also encompasses a fitness function being maximized). In some cases, the training set includes a plurality of logged authentication sessions, each including the known profile, the observed profile, and a value indicating whether the determination of block 34 was correct. Some embodiments may tune the weights, for instance, with the gradient descent algorithm in an incremental process, such that increasing amounts of the inputs available from previous determinations result in correct determinations when the current weights are applied. For example, some embodiments may iteratively, until a termination condition occurs (like a threshold amount of iterations, or less than a threshold change in an error function result between iterations), determine partial derivatives of the weights relative to the error function, adjust the weights in a direction that the partial derivatives indicate will reduce the error function, and then repeat.
[0048] Some embodiments may perform the determination of block 34 with a rules engine. For example, some embodiments may include a plurality of rules that make determinations based on correspondence between various attributes in the known and observed profiles. Examples include a rule that determines the absence of correspondence in response to determining that an operating system version is lower in the observed profile than in the known profile. In some cases, the rules may be arranged hierarchically, for instance, with a rule that specifies the absence of correspondence in response to failing to determine correspondence in more than five of seven rules that pertain to particular respective attributes. In some cases, rules are evaluated conditionally upon other rules reaching a particular result, such as a rule that specifies an amount of central processing unit (CPU) cache (e.g., L2 or L3 cache) is to be matched exactly upon another rule indicating that the CPU manufacture name has greater than a threshold edit distance difference between the known and observe profiles in order to determine correspondence. In some cases, the number of rules may be relatively large, for instance, exceeding 10, and in many expected commercially relevant use cases exceeding 50. In some cases, some of the rules express necessary, but not sufficient conditions for determining that a known profile corresponds to an observed profile, and in some cases, some of the rules may express necessary and sufficient conditions.
[0049] Upon determining that the known profile does not correspond to the observed profile, some embodiments may log the session for purposes of subsequent model training, and send a message indicating that the second computing device is untrusted, as indicated by block 35. In some cases, the message may be sent to an agent executing on the second computing device via network, and the agent may present a user interface by which the user may input an indication that they believe the determination is incorrect, which may be routed to a helpdesk. In some cases, the message may be sent to another computing device, such as to a server hosting an application to which the user is attempting to secure access with the authentication request of block 12. In some cases, the message may be sent to the first computing device, with a user input by which the user may indicate that they believe the determination is incorrect.
PNG
media_image3.png
1036
778
media_image3.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the authentication system architecture involving web server redirects and client-side script execution teachings of the prior art of record (see Grajek para 0024 and 0027) by integrating the method of calculating a risk/certainty score using weighted attribute comparison and sending an untrusted notification upon failure technique of Jackson to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Jackson would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the known scoring technique of Jackson to the known authentication system of Grajek would have yielded predictable results. Grajek collects a set of device characteristics (see Grajek para 0027) but does not limit how they are processed. Jackson teaches that when processing such characteristics/observed profile, one can use strict matching or preferably, weighted combinations of scores (see Jackson para 0046). One of ordinary skill in the art, faced with the task of implementing the device certainty score mentioned in Grajek (para 0007) would look to Jackson as a known in the art option for implementing that scoring logic robustly. Selecting Jackson’s weighted scoring method from a finite number of identified, predictable solutions is obvious. The motivation to combine the references is applied to all claims below this heading.
Per claim 2, the prior art of record further suggests wherein the webpage document comprises a script element indicating a client-side script (reads on sending Javascript/client-side script to the user device, see Grajek para 0042. The Examiner asserts for a browser to execute this JavaScript the webpage document must comprise a script element indicating or containing that script), and wherein the first computer-readable instructions, when executed by the at least one first processor, cause the user device to: retrieve, based on the script element and from a validation server, the client-side script (reads on the script element in the page causes the user device to retrieve/execute this script from the server, see Grajek para 0027); and determine the first user profile by causing determining the first user profile based on executing the client-side script (reads on the script executes to pull device distinguishing characteristics/device fingerprint which is reasonably construed with the stored user ID as the user profile, see Grajek para 0027, 0028, 0051).
Per claim 3, the prior art of record further suggests wherein the script element comprises a uniform resource locator (URL) corresponding to the client-side script (reads on the combination of the redirection and script loading of Grajek with the standard use of URL for accessing web resources of Jackson, see Grajek para 0025 and Jackson para 0022. The Examiner further asserts one of ordinary skill in the art would consider it within the realm of conventional computer science for the necessary HTML script element to use a src attribute containing a URL to point to the external script file), and wherein the first computer-readable instructions, when executed by the at least one first processor, cause the user device to retrieve the client-side script based on the URL (The Examiner asserts one of ordinary skill in the art would know in standard web architecture, which is at least implied by Grajek’s web server, browser and sending script recitations, sending a script typically involves the browser parsing a URL in a script tag and making an HTTP GET request to that URL to retrieve the script content, see Grajek par 0027).
Per claim 8, the prior art of record further suggests wherein the one or more other computing devices comprise the web server (reads on the web server 103a, see Grajek Figure 1 and para 0035 – 0036).
Per claim 9, the prior art of record further suggests wherein based on receiving a notification, of the one or more notifications, the web server terminates a web session with to the user device (reads on the combination of Jackson sending untrusted notification and Grajek denying access, see Grajek para 0037 – 0038 and Jackson para 0034. The Examiner asserts it is within the realm of conventional computer science that a web server terminates a session when the underlying authentication system indicates the device is untrusted.).
Claim 10 is analyzed with respect to claim 1.
Claim 15 is analyzed with respect to claim 1.
Claim 16 is analyzed with respect to claim 1.
Claim 19 is analyzed with respect to claim 1.
Claim 20 is analyzed with respect to claim 9.
Claims 4 – 7, 11 – 14 and 17 – 18 are rejected under 35 U.S.C. 103 as being unpatentable over Grajek in view of Jackson in view of Chen (US Pub. No. 2023/0102116 A1).
Per claim 4, the prior art of record suggests the system of claim 2 and the client-side script (see Grajek par 0027). The prior art of record is silent on explicitly stating cause the user device to: generate, by the client-side script, for each element of a plurality of hypertext markup language (HTML) elements of the webpage document, a corresponding hash value; and send, to the validation server, hash values corresponding to the plurality of HTML elements.
Chen (US Pub. No. 2023/0102116 A1) is relied upon to teach cause the user device to: generate, by the client-side script (reads on the browser generating individual hashes for each HTML code element, see Chen para 0034 and 0035), for each element of a plurality of hypertext markup language (HTML) elements of the webpage document (reads on for each HTML code element, see Chen para 0034 and 0035), a corresponding hash value (reads on a integrity element in the form of a cryptographic hash, see Chen para 0033); and send (reads on the browser can generate and send the cryptographic hashes to the web server, see Chen para 0040, 0042, 0057 and 0071 – 0072), to the validation server (reads on the web server, see Chen para 0040, 0042, 0057 and 0071 – 0072), hash values corresponding to the plurality of HTML elements (reads on individual hashes for each HTML code element, see Chen para 0034 and 0035).
[0033] The electronic resource 122 can include a respective integrity element 126 for each of one or more code elements. For example, if the web application includes multiple scripts, the electronic resource 122 can include a respective integrity element 126 for each individual script.
[0034] Although the techniques described in this document are described largely in terms of integrity elements for code of a web application, the same or similar techniques can be used to verify that other assets of the web application have not been modified and therefore the web application is trustworthy. For example, the electronic resource 122 can include a respective integrity element for each asset, e.g., each code element, each image, each logo, etc. By verifying that code elements (e.g., HTML, CSS, scripts), images and/or logos have not been modified, the web server 130 can verify that the look and feel of the web application has not been modified.
[0035] The integrity element 126 can take one of various forms described in this document. In one example, the integrity element can include, or be in the form of, an integrity attribute that specifies a cryptographic hash function and a trusted cryptographic hash calculated using the cryptographic hash function and trusted code of the web application. This trusted cryptographic hash is an expected hash value that should result from the browser 111 and/or the web server 130 calculating a hash value using the cryptographic hash function and the actual code 124 received with the electronic resource 122. The cryptographic hash for a code element can be referred to as the identity of the code element. The cryptographic hash function can be one or various hash functions of choice, such as, for example, SHA256.
[0040] In stage C, the browser 111 generates the request 112 and transmits the request 112 to the web server 130 corresponding to the web application. Generating the request 112 can include modifying the request 112 to include the integrity element 126 or at least a portion of the integrity element 126 for the code 124, e.g., the individual code element that initiated the request. For example, the browser 111 can modify the request 112 to include the cryptographic hash of the code 124 of the web application that initiated the request 112, to include the signed approval element for the code 124 that initiated the request, or to include the digital signature of the web package, depending on the form of the integrity element 126. In implementations in which the integrity element includes a cryptographic hash of the code 124, the browser 111 can send this cryptographic hash even when the electronic resource 122 does not include an integrity attribute that includes the trusted cryptographic hash. Instead, the browser can generate and send a cryptographic hash of the code 124 using the appropriate cryptographic hash function, e.g., a pre-specified hash function or a hash function identified by the electronic resource 111 or the code 124. In this way, the web server can still know the identity of the code 124 that generated the request 112 and use the cryptographic hash of the code 124 to determine whether the code 124 is trustworthy.
[0042] During stage D, the web server 130 processes the request 112. Processing the request 112 can include verifying the trustworthiness of the web application that initiated the request. The techniques in which the web server 130 verifies the request 112 can vary based on the form of the integrity element 126 and/or the additional integrity information included in the request 112. Example techniques for verifying the trustworthiness of a web application are described in more detail below.
[0043] During stage E, the web server 130 can respond, or not respond, to the request 112 based on whether the trustworthiness of the web application is verified successfully. If the trustworthiness of the web application is verified successfully, the web server 130 can process the request 112 and respond to the request 112 in a normal manner, e.g., by providing content for display at the browser 111. If the trustworthiness of the web application is not verified successfully, the web server 130 can ignore the request 112 or respond to the browser 111 with a response indicating that the web application 111 is not trustworthy. If the browser 111 receives a response, the browser 111 can display content at the display of the client device 110 based on the response.
[0057] FIG. 4 is a swim lane diagram that illustrates an example process 400 for verifying the trustworthiness of a web application. Operations of the process 400 can be implemented, for example, by a browser 111 of a client device 110, a content management system (CMS) 120, code 124 of a web application and a web server 130. Operations of the process 400 can also be implemented as instructions stored on one or more computer readable media which may be non-transitory, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process 400.
[0058] Although the process 400 is described in terms of verifying the trustworthiness of a web application based on code of the application, the process 400 can be used to verify the trustworthiness of the web application based on other assets, e.g., images and/or logos, of the web application. For example, the process 400 can be used to determine whether any of these assets have been modified since an integrity element was generated for the asset. Thus, in the description that follows, the term code can be replaced with asset to refer to other assets of the web application.
[0059] The browser 111 obtains an electronic resource (402). The browser 111 can obtain the electronic resource from a content management system 120 that hosts websites. For example, the browser 111 can request a web page from the content management system 120 in response to a user interacting with a link to the web page or the user entering a Universal Resource Locator (URL) for the web page into the browser 111. The electronic resource can include a web application.
[0071] The web server 130 verifies the trustworthiness of the web application (418). The web server 130 can verify the trustworthiness of the web application using the integrity element (or portion thereof) included in the request and, if included in the request, the additional integrity information, e.g., the context information and/or the origin of the web application. The techniques for verifying the trustworthiness of the web application can vary based on the form of the integrity element and the additional integrity information included in the request.
[0072] If the integrity element is an integrity attribute specifying a cryptographic hash function and a cryptographic hash, the web server 130 can query a database, e.g., the database 230 of FIG. 2, to determine whether the cryptographic hash matches a trusted cryptographic hash for the web application stored in the database. If the cryptographic hash included in the request matches a trusted cryptographic hash for the web application stored in the database, the web server 130 can determine that the web application is trustworthy. If the cryptographic hash included in the request does not match a trusted cryptographic hash for the web application stored in the database, the web server 130 can determine that the web application is not trustworthy. This signature comparison enables the web server 130 to determine whether the code of the web application has been modified from a trusted version of the code. That is, if the signature verification fails, then the code does not match the trusted code for the application. As described in more detail below, the web server 130 can also consider any additional integrity information in addition to the cryptographic hash in determining whether the web application is trustworthy.
[0082] In some implementations, the web server 130 can determine a trustworthiness score based on one or more of the verifications. For example, the web server 130 can determine an individual score for each verification and combine the scores, optionally by weighting each score based on the importance of that verification. In this example, the score can vary based on the trustworthiness of the origin and/or the frequency at which a request is received for the web application from a context that matches the context of the request relative to the frequency at which requests are received for the web application from different contexts. For a web application, each of multiple origins can have a corresponding score based on their trustworthiness as assigned by the publisher of the web application or another entity. The web server 130 can compare the trustworthiness score to a threshold trustworthiness to determine whether the web application is trustworthy. For example, if the trustworthiness score satisfies the trustworthiness threshold, e.g., by meeting or exceeding the trustworthiness threshold, the web server 130 can determine that the web application is trustworthy.
PNG
media_image4.png
786
988
media_image4.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the authentication of the user’s identity and device characteristics of the prior art of record by integrating the integrity of the HTML web code itself teachings of Chen to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the ensuring the HTML code is trustworthy and has not been modified teachings of Chen (see Chen para 0034) to the authentication teachings of the prior art of record would have yielded predictable results and resulted in an improved system. It would have been recognized that combining the authenticating the user teachings of the prior art of record with the authenticating the HTML code teachings of Chen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such verifying trustworthiness features into similar systems, resulting in an improved secure system that prevents unauthorized users and unauthorized code modifications. In addition, integrating the hash generation teachings of Chen into the existing capture script of the prior art of record, which already executes on the client to collect data, is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized the results of the combination were predictable. This combination is a simple application of a known hashing code for integrity technique to a known client-side authentication script to achieve the predictable result of a tamper-resistant authentication process. The motivation to combine the references is applied to all claims below this heading.
Per claim 5, the prior art of record further suggests cause the validation server (reads on the combination of the web server and authentication server/service/system that validates user authentication attempts and communicates with user devices over the network, see Grajek para 0032 – 0033 and Figures 1, 6 and 12 and Chen Figure 1 and para 0042 – 0043) to send the one or more notifications based on the hash values (reads on the web server verifies the trustworthiness and can respond to the browser with a response indicating the web application is not trustworthy, see Chen para 0043).
Claim 6 is analyzed with respect to claim 4. The prior art of record further suggests cause the user device to send (reads on send to the authentication system, see Grajek Figure 6 block 610 and associated text), to the validation server (reads on the combination of the web server and authentication server/service/system that validates user authentication attempts and communicates with user devices over the network, see Grajek para 0032 – 0033 and Figures 1, 6 and 12 and Chen Figure 1 and para 0042 – 0043), additional information, wherein the additional information comprises one of: a session indicator (ID) associated with a web session between the user device and the web server (reads on a cookie or redirect URL parameter which one of ordinary skill in the art would consider a session indicator, see Grajek para 0027 – 0028); a uniform resource locator (URL) associated with a webpage corresponding to the webpage document (reads on the url/origin of the web application, see Chen para 0023 and 0067 and Jackson para 0022); an internet protocol (IP) address associated with the user device (reads on a device IP address, see Grajek para 0030 and 0049); a username, associated with the webpage, of a user of the user device (reads on a user ID, see Grajek para 0025 – 0026); text included in the webpage (reads on scripts/HTML, see Chen para 0032, 0039 – 0040).
Per claim 7, the prior art of record further suggests cause the validation server to determine, based on the additional information, a risk score associated with the webpage (reads on the combination of the device certainty score based on comparison of received information/device characteristics/additional information against known/trusted values and trustworthiness score of the web application, see Chen para 0082 and Jackson para 0007 and 0047).
Claim 11 is analyzed with respect to claim 4.
Claim 12 is analyzed with respect to claim 5.
Claim 13 is analyzed with respect to claim 6.
Claim 14 is analyzed with respect to claim 7.
Claim 17 is analyzed with respect to claim 6.
Per Claim 18, the prior art of record further suggests sending the one or more notifications based on the hash values (reads on the web server verifies the trustworthiness and can respond to the browser with a response indicating the web application is not trustworthy, see Chen para 0043).
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