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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9 and 18 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 9 recites the limitation “user U’s browser” in line 3. There is insufficient antecedent basis for this limitation in the claim. Claim 7, depends upon, does not recite user U’s browser. For the purpose of examination, Examiner is interpreting as “user’s browser”.
Claim 18 recites the limitation “user U’s browser” in line 8. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination, Examiner is interpreting as “user’s browser”.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Lerner et al (US PG-PUB No. 20140282978 A1).
Regarding claim 1, claim 7 and claim 18, Lerner teaches a system, method and computer program product for enhancing security for users engaged in browsing activity via respective browsers installed on users' respective devices, the system comprising: a. an HTTP communication analyzer, e.g., hardware processor which analyzes HTTP responses incoming to a user's device from webapp/s servers and/or HTTP requests outgoing from the browser on a user's device to web apps servers, including identifying incoming cookie values (aka real values) being sent, e.g., in HTTP responses, from web app/s servers to the browser and outgoing cookie values being sent, e.g., in HTTP requests, from the browser toward web app/s servers; and b. a controller e.g. hardware processor which, responsive to at least one incoming cookie having been identified by the HTTP communication analyzer, stores the incoming cookie value in a location other than the user device's browser's cookie store, and deletes at least the incoming cookie value from the user device's browser's cookie store, thereby to store at least one real value only outside the cookie store; wherein the controller at least once adds at least one real value outside the cookie store to at least one service message request outgoing from the user device's browser toward at least one web app (Paragraph [0052]: “The invention can also be used in Single-Sign-On systems, such as Kerberos, where an authentication server provides an authentication token (real cookie values) that must be temporarily stored in the client computer (The real cookie value is supposed to be stored in the user device’s browser’s cookie store for future requests), to be sent to a second server that provide service and that are configured to accept these tokens as proof of granted permission for the service, at a later time. In this case, the independent secure platform (The solution system which comprises analyzer, controller and generator) stores the authentication token (The solution system’s analyzer first analyzes the incoming communication response from the webserver and identifies the real cookie value from the response, then the solution system’s controller stores the real cookie value in the independent secure platform, which is a location other than user device's browser's cookie store) and provides the client PC a fake token (The solution system’s generator generates a fake cookie and the solution system’s controller provides the fake cookie to the user device’s browser’s cookie store, thereby deletes the real cookie value from the user device’s browser’s cookie store). When the token (real cookie value) is required to authenticate with the second server, the secure platform retrieve the authentic token and replace the fake token with the authentic token (The solution system’s analyzer identifies the second requests outgoing from the user device’s browser toward at least one web app, then the solution system’s controller replaces the fake cookie with adding the real cookie value to the second requests), in a way that the PC is unable to access the authentic tokens though-all the mentioned process, and in a way that is transparent to the Kerberos client software module.”; Lerner further teaches in paragraph [0115]: “the server typically being in the Internet and serving a website by means of HTTP/HTTPS/TCP/TLS/WS/WSS (Secure WebSockets)/FTP/FTPS (FTP over TLS)/WAP/SSH protocols (HTTP communication)”; Paragraph [0381]: “(The Dock, which is the secure platform) Detect the presence of Session-Authenticators in responses and replace them by Locators (The solution system’s analyzer identifies the real values in the HTTP responses from the web server to the browser, the generator generates locators as fake values corresponding to the real values, the controller replaces the real values by the corresponding locators)”; Paragraph [0382]: “Detect locators in new Requests coming from the browser and replace them by Session-authenticators (The solution system’s analyzer subsequently identifies the locators in the new HTTP requests from the browser to a web server, the controller replaces the locators by the corresponding real values).”).
Regarding claim 2, Lerner teaches all of the features with respect to claim 1, as outlined above.
Lerner further teaches wherein the controller adds the at least one real value outside the cookie store to the at least one service message, responsive to a relevant service request having been identified by the HTTP communication monitor (Paragraph [0052]: “When the token (real cookie value) is required to authenticate with the second server (responsive to a relevant service request), the secure platform retrieve the authentic token and replace the fake token with the authentic token (The solution system’s analyzer identifies the second requests outgoing from the user device’s browser toward at least one web app, then the solution system’s controller replaces the fake cookie with adding the real cookie value to the second requests), in a way that the PC is unable to access the authentic tokens though-all the mentioned process, and in a way that is transparent to the Kerberos client software module.”).
Regarding claim 3, Lerner teaches all of the features with respect to claim 1, as outlined above.
Lerner further teaches wherein the system also comprises a cookie generator and wherein the controller also stores an alternative value in the user device's cookie store (Paragraph [0052]: “In this case, the independent secure platform (The solution system which comprises analyzer, controller and cookie generator) stores the authentication token and provides the client PC a fake token (The cookie generator generates a fake cookie as an alternative value and provides it to the user device’s browser’s cookie store).”).
Regarding claim 4, Lerner teaches all of the features with respect to claim 3, as outlined above.
Lerner further teaches wherein the alternative value comprises a fake cookie value, generated by the cookie generator, thereby to store at least one real value outside the cookie store corresponding to at least one fake value in the cookie store (Paragraph [0134]: “In this embodiment the dock (the solution system, comprises analyzer, controller and cookie generator, see Fig. 27 for hardware architecture for an implementation of the “Dock” module. ) doesn't reveal the SAs in plain text to the PC, instead, SAs are transformed in the dock to Locators (Locators are the alternative value which comprises a fake cookie value, generated by the cookie generator in the Dock.) (in other embodiments the SAs can be revealed as plain text to the PC). Locators can be used to obtain the corresponding SAs in several ways. The result of this process is that each Session Authenticator is a function of a Locator, since each locator unequivocally maps to a Session authenticator (store at least one real value outside the cookie store (in the Dock) corresponding to at least one fake value in the cookie store (in the UI).).”; Paragraph [0191]: “Scripts may also generate new random or pseudo-random passwords (a fake cookie value, generated by the cookie generator) and update the secrets stored in the UI. The UI may be configured to require confirmation if secrets are to be updated (FIG. 28 shows a hardware architecture for an implementation of the "UI" module. UI contains the cookie store. As UI connects to Dock as disclosed in paragraph [0477], therefore, the real cookie value is stored in the Dock which is outside of the cookie store that is in the UI.).”).
Regarding claim 5, Lerner teaches all of the features with respect to claim 1, as outlined above.
Lerner further teaches wherein the controller deletes the entire incoming cookie value from the user device's browser's cookie store (Paragraph [0300]: “Data 2154 is the Delete Account Action associated with this website. The user may command the Dock (the controller) to automatically delete the account of a subset of the websites the user has previously registered with (deletes the entire incoming cookie value from the user device's browser's cookie store).”).
Regarding claim 6, Lerner teaches all of the features with respect to claim 1, as outlined above.
Lerner further teaches wherein the location at which the incoming cookie value is stored, is on the user's device outside of the browser's cookie store (Paragraph [0134]: “In this embodiment the dock (the solution system) doesn't reveal the SAs in plain text to the PC, instead, SAs are transformed in the dock to Locators (Locators are the alternative value which are stored in the Dock - location.) (in other embodiments the SAs can be revealed as plain text to the PC). Locators can be used to obtain the corresponding SAs in several ways. The result of this process is that each Session Authenticator is a function of a Locator, since each locator unequivocally maps to a Session authenticator (store at least one real value outside the cookie store (in the Dock) corresponding to at least one fake value in the cookie store (in the UI). See Fig. 27 and Fig. 28 for hardware architectures for an implementation of the “Dock” and “UI” modules).”).
Regarding claim 8, Lerner teaches all of the features with respect to claim 7, as outlined above.
Lerner further teaches wherein a fake cookie is stored in the user device's browser program's cookie store, and wherein subsequently, the request is modified by replacing a cookie value within the request, which, having been retrieved by the browser program from the cookie store, is fake, with the real cookie value (Paragraph [0382]: “(The browser program) Detect locators (fake cookie value) in new Requests (subsequent request) coming from the browser and replace them by Session-authenticators (the subsequent request is modified by replacing the fake cookie value with the real cookie value).”).
Regarding claim 9, Lerner teaches all of the features with respect to claim 7, as outlined above.
Lerner further teaches wherein said removing comprises: replacing at least one real cookie which was sent to the user's browser by the webapp server and has been stored by user U's browser in a cookie store in the user's device, with a fake cookie value; removing said cookie from the cookie store; and/or storing a blank value in said cookie's value, instead of the real value that was removed (Paragraph [0381]: “Detect the presence of Session-Authenticators in responses and replace them by Locators (replacing at least one real cookie which was sent to the user's browser by the webapp server and has been stored by user’s browser in a cookie store in the user's device, with a fake cookie value; By the replacement, the real cookie is removed from the cookie store)”; Paragraph [0382]: “Detect locators in new Requests coming from the browser and replace them by Session-authenticators.”; Paragraph [0428]: “In step 0315B Session-Authenticators associated with the found Locators are inserted in the header, and the said Locators are removed (removing the fake cookie).”).
Regarding claim 10, Lerner teaches all of the features with respect to claim 9, as outlined above.
Lerner further teaches wherein the method includes removing the fake cookie each time the session is revoked by the user or the service itself (Paragraph [0433]: “In step 0340B the procedure of Manual Logout Attempt is executed (the session is revoked by the user or the service itself). This procedure ensures that the request is sent to the remote website in a secure way, checks for a positive response and destroy all Locators/Session-Authenticators associated with the Login Record (removing the fake cookies).”).
Regarding claim 11, Lerner teaches all of the features with respect to claim 1, as outlined above.
Lerner further teaches wherein the system is implemented in solution code and wherein the real value is stored in a secured location such as the solution code's sandboxed memory (Paragraph [0130]: “SAs (real cookie value) can be sent to the browser by means of JavaScript code (solution code) executed from a file provided by the Dock (a secured location which provides the solution code and memory to store the real value) or stored on the file system.”).
Regarding claim 12, Lerner teaches all of the features with respect to claim 1, as outlined above.
Lerner further teaches wherein the real value is stored encrypted on the user device's file system (Paragraph [0570]: “The Locator has the information of a Session-Authenticator in authenticated and encrypted way by private keys of the Dock (the solution system).”; Paragraph [0130]: “SAs can be sent to the browser by means of JavaScript code executed from a file provided by the Dock or stored on the file system”;).
Regarding claim 13, Lerner teaches all of the features with respect to claim 1, as outlined above.
Lerner further teaches wherein the real values are stored in plain text, i.e., un- encrypted on process memory managed by the operating system of the user's device (Paragraph [0125]: “To send information such as SAs (Secure-authenticators, real values) or Locators to the Browser, several options are considered: [0126] a) The Dock is configured as an HTTP gateway. The user first connects to the website using HTTP and this connection is trapped by the Dock. The Dock forwards this requirement by HTTPS to the website. Then the Dock received an HTTP response from the website and forwards this response to the Browser over the unencrypted connection, including the SAs (the real values are stored in plain text, i.e., un- encrypted on process memory which the Dock memory), but adds a redirection to the HTTPS webpage, so that the Browser automatically continues the connection by connecting directly to the website over HTTPS.”).
Regarding claim 14, Lerner teaches all of the features with respect to claim 1, as outlined above.
Lerner further teaches wherein at least one incoming cookie value, which needs to be stored on the user's device for persistence, is stored encrypted on the device's file system (Paragraph [0131]: “f) SAs (Session-Authenticators which are the incoming cookie values) can be inserted to the browser (stored on the user's device) by using an API provided by the browser or by the operating system, for example, for persistent cookies.”; Paragraph [0570]: “The Locator has the information of a Session-Authenticator in authenticated and encrypted way by private keys of the Dock (the solution system).”).
Regarding claim 15, Lerner teaches all of the features with respect to claim 4, as outlined above.
Lerner further teaches wherein the controller adds the at least one real value outside the cookie store by replacing the outgoing cookie value, which, having been retrieved by the browser from the cookie store, is fake, with at least one real value outside the cookie store corresponding to the fake outgoing cookie value (Paragraph [0052]: “In this case, the independent secure platform (the controller) stores the authentication token (adds the real value outside the cookie store on the client PC) and provides the client PC a fake token. When the token is required to authenticate with the second server, the secure platform retrieve the authentic token and replace the fake token with the authentic token (the controller replace the outgoing cookie value with the fake value), in a way that the PC is unable to access the authentic tokens though-all the mentioned process, and in a way that is transparent to the Kerberos client software module.”).
Regarding claim 16, Lerner teaches all of the features with respect to claim 3, as outlined above.
Lerner further teaches wherein the alternative value comprises a null string comprising zero characters (Paragraph [0231]: “In step 1030 the Dock checks if a predefined maximum number of Logins/Logouts have been reached, and if so a password recycle is triggered. The password recycle process consist of the generation in the Dock of a new password as a random or pseudo-random string, the request of a change of password in the remote website from the old password to the newly generated one (the newly generated alternative value is a random string, which can comprise a null string comprising zero characters), and the storage of the new password encrypted by the Master secret in the table of auxiliary secrets. The password recycle process is carried out by the Dock without intervention of the browser. After the password recycle process is done, an informational message may be displayed on the UI or on the PC.”).
Regarding claim 17, Lerner teaches all of the features with respect to claim 1, as outlined above.
Lerner further teaches wherein the location at which the incoming cookie value is stored, is in device memory (Paragraph [0196]: “In the case it is desired to protects the SAs, then SAs are privately stored in the Dock (the incoming cookie value is stored in the location in the Dock) and so the HTTP response cannot be handled entirely by the browser, and that's why the Dock is the first to receive the HTTP response.”; Paragraph [0115]: “The dock can act as an USB flash drive by using the connected SD memory as flash drive storage (device memory of Dock), and the user can conveniently store there an specially adapted web browser software and/or the M/R module.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-892 form for details).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASMINE DAY whose telephone number is (571)272-0204. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip Chea can be reached at 571-272-3951. 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.
/J.M.D./Examiner, Art Unit 2499
/PHILIP J CHEA/ Supervisory Patent Examiner, Art Unit 2499