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 .
Claims 1, 11, and 16 are amended.
Claims 1-19 are pending.
Response to Amendment
Applicant’s arguments filed on May 11, 2026 have been considered
With respect to arguments regarding 35 U.S.C. 112(b), this is persuasive in view of the claim amendments and therefore this rejection is withdrawn.
With respect to arguments regarding claims 1, 11, and 16, Examiner respectfully disagrees.
With respect to the argument that the office action provided no basis for the fact that a virtual container is usually stored in volatile memory, a virtual container runs in volatile memory and there is no indication in Dekel that the state of the container including inputs/outputs are saved, therefore, at least while the inputs/outputs are in volatile memory, it is a reasonable teaching of “unsaved” input/output. Additionally, the system does not know what the user’s input is going to be, and therefore it is not possible for the system to save an input before knowing what it is. And since the output comprises the input, it is also not possible for the system to save an output before the input is determined.
With respect to the argument that a virtual container stored in volatile memory cannot be used to show or suggest “look and feel”, this argument is moot in view of the new ground of rejection necessitated by the claim amendment.
With respect to the argument that Dekel does not disclose that any time a session is timed out due to inactivity, the unsaved information is not stored, and that the unsaved “look and feel” of a GUI is stored, this argument is not persuasive as these features are not stated in the claims. The claims merely recite “look and feel” and not unsaved “look and feel.”
With respect to the argument that the inputs are only input into the GUI upon successful MFA authentication and as such, the Dekel MFA cannot be used to show/suggest two temporally distinct elements, this argument is not persuasive because any interaction a user has with a GUI is considered an unsaved input. This includes the process of inputting username and password information. The unfinished username and password are not actually “saved” until the user confirms that the unsaved input is correct.
With respect to arguments regarding claims 2-10, 12-15, and 17-19, this argument is not persuasive as these claims depend on claims 1, 11, and 16, respectively which are all rejected under 35 U.S.C. 103.
Claim Objections
Claims 1 and 16 are objected to because the terms “the lack of activity” do not have antecedent basis. For the purpose of examination, they are being interpreted as "the lack of input."
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, 6, 11, and 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dekel (US 20230291726 A1, hereinafter referred to as Dekel) in view of Kaewka (US 10574768 B1, hereinafter referred to as Kaewka) in further view of Matthew (US 20170134471 A1, hereniafter referred to as Matthew).
Regarding claim 1, Dekel discloses: A method for re-authenticating a client user on a configurable authentication system (Dekel: Paragraph [0023] states, "The XRDP container 128 may be used to reauthenticate (or authenticate, if authentication failed for other reasons) the user credentials."), the method comprising: receiving, at a web-based graphical user interface operating on a first hardware processor and a first hardware memory, an authentication request from a client user, said client user operating on a second hardware processor and a second hardware memory (Dekel: Paragraph [0054] states that "a request is received to connect to a zero-trust cloud environment. The request may be received through an access portal server from a client device." Examiner’s Note: Fig.1 of Dekel shows the server and the client device are separate entities and therefore this teaches first and second memory and first and second processor.); communicating the authentication request from the web-based graphical user interface to a dynamic authentication system operating on the first hardware processor and the first hardware memory (Dekel: Paragraph [0054] states that "a request is received to connect to a zero-trust cloud environment. The request may be received through an access portal server from a client device."); receiving the authentication request at the dynamic authentication system (Dekel: Paragraph [0054] states that "a request is received to connect to a zero-trust cloud environment. The request may be received through an access portal server from a client device."); upon receipt of the authentication request, generating an authentication attempt, said authentication attempt comprising requesting verification of two or more authentication factors from the client user, wherein verification of at least one of the two or more authentication factors are via an authentication channel that bypasses the web-based graphical user interface (Dekel: Paragraphs [0020] and [0057]. Paragraph [0020] states that "the third party application may request a second form of identification, such as sending a code to a mobile phone associated with the user account." Paragraph [0057] states that "a multifactor authentication (MFA) challenge is generated. The MFA challenge may be generated by sending a request to an IAM service provider."); successfully verifying the two or more authentication factors (Dekel: Paragraph [0062] states, "The RDP session is initiated in response to successfully completing the MFA challenge."); authenticating the client user based on the successful verification of the two or more authentication factors (Dekel: Paragraphs [0062] and [0047]. Paragraph [0062] states, "The RDP session is initiated in response to successfully completing the MFA challenge." Paragraph [0047] states, "The frontend RDP server is thus configured to provide the client device with an RDP session to the target server, with the frontend RDP acting as a proxy. Providing an RDP session in this manner allows the frontend RDP server to authenticate the user of the client device."); instantiating an authenticated session between the client user and the web-based graphical user interface based on the authenticating (Dekel: Paragraph [0021] states, "After verifying the identity of the user account, the access portal server 122 may provide the client device 110 with an RDP file (.rdp) which includes therein an address or server name to connect to, a port, token, token version, token type, and the like. A token may be a unique ID which is associated with a user account, tenant, or combination thereof. In certain embodiments a token expiry time may be specified. A token type may be a file token, or session token."); receiving, at the web-based graphical user interface, one or more unsaved inputs from the client user (Dekel: Paragraph [0058] states, "The user interface may be rendered using a virtual workload, such as the XRDP container, having a web browser which displays a web page rendered by an access portal server into which a user may provide input (i.e., the MFA response)." Examiner's note: since "The user interface may be rendered using a virtual workload" and a virtual container is usually in volatile memory, then it is interpreted that the input/output on the interface is unsaved.); displaying one or more unsaved outputs on the web-based graphical user interface (Dekel: Paragraph [0058] states, "The user interface may be rendered using a virtual workload, such as the XRDP container, having a web browser which displays a web page rendered by an access portal server into which a user may provide input (i.e., the MFA response)." Examiner's note: since "The user interface may be rendered using a virtual workload" and a virtual container is usually in volatile memory, then it is interpreted that the input/output on the interface is unsaved.); following the receiving of the input, detecting a period of inactivity comprising lack of input from the client user for a predetermined time period (Dekel: Paragraph [0026] states, "In an embodiment, a policy may be configured to periodically generate requests for authentication. For example, after 15 minutes of inactivity, the policy requires that the user reauthenticate with a username and password."); initiating a grace period on the web-based graphical user interface, the grace period bridging a gap between an active period and a dormant period (Dekel: Paragraph [0026] states, "In an embodiment, a policy may be configured to periodically generate requests for authentication. For example, after 15 minutes of inactivity, the policy requires that the user reauthenticate with a username and password."), but fails to explicitly disclose, upon detection of the lack of activity, storing a look and feel format of the web-based graphical user interface, the one or more unsaved inputs and the one or more unsaved outputs in a memory location within the first hardware memory.
However, in the same field of endeavor, Kaewka discloses: upon detection of the lack of activity, storing a [look and feel] format of the web-based graphical user interface, the one or more [unsaved] inputs and the one or more [unsaved] outputs in a memory location within the first hardware memory (Kaewka: [Column 1 lines 40-42], [Column 10 lines 39-41], [Column 23 lines 30-32], [Column 24 lines 27-30], and [Column 24 lines 62-63]. [Column 1 lines 40-42] states, "An external program can be initiated by the browser application in connection with any web document executed by the browser application to render a display." [Column 10 lines 39-41] states that "the external program initiated by a browser application might be a media player (with user interface controls for controlling playback)." [Column 23 lines 30-32] states, "Element 706 is considered to be an external program. Element 902 of FIG. 9 is a reproduction of the element 706." [Column 24 lines 27-30] states, "At step 608, inactivity is detected in connection with an external program. At step 610, which is performed by program suspension module 506, each external program associated with the detected inactivity is suspended." [Column 24 lines 62-63] states, "The program suspension module 506 can store a copy of element 902 (e.g., in data store 510)." Examiner's note: Since an external program is being initiated by a browser application, it is interpreted as a component of a web-based graphical user interface, and interaction with a browser application is via input/output, and all of that is getting suspended and saved into memory. Unsaved inputs and unsaved outputs are taught by Dekel.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teaching of Dekel and include the above limitation with the teaching of Kaewka so that the saved web-based graphical user interface "can be retrieved from storage" and replace the placeholder to "restore element 902 if activity is detected" (Kaewka: Column 24 line 67 and Column 25 lines 1-4).
This motivation applies to the remainder of the claim.
Kaewka fails to explicitly disclose: storing a look and feel format…unsaved inputs and unsaved outputs.
However, Dekel discloses: unsaved inputs and unsaved outputs. (Dekel: Paragraph [0058] states, "The user interface may be rendered using a virtual workload, such as the XRDP container, having a web browser which displays a web page rendered by an access portal server into which a user may provide input (i.e., the MFA response)." Examiner's note: since "The user interface may be rendered using a virtual workload" and a virtual container is usually in volatile memory, then it is interpreted that the input/output on the interface is unsaved.), but fails to explicitly disclose: storing a look and feel format.
However, in the same field of endeavor, Matthew discloses: storing a look and feel format (Matthew: Paragraph [0048] states, "a user profile may indicate that a particular look and feel is preferred by a user. In such embodiments, the retrieved softphone graphical interface will conform to a layout and style previously identified by the user." Paragraph [0059] states, "As a component of a web browser running in a communication application container, each of the described softphone graphical interfaces may be configured in some embodiments as a borderless containers that occupy an entire browser window." Paragraph [0080] states, "As shown in FIG. 8, memory 820 may include program instructions 825, configured to implement certain embodiments described herein, and data storage 835, comprising various data may be accessible by program instructions 825…Data storage 835 may include data that may be used in these embodiments (e.g., user profiles, call logs, recorded communications, address book information, contact lists, user preferences, profiles for different modes of operations, etc.).").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teaching of Dekel as modified by Kaewka and include the above limitation with the teaching of Matthew in order to ensure an application continues to operate based on user preferences (Matthew: Paragraph [0048]).
Dekel further discloses: prior to completion of the grace period, receiving a request for re-instantiation of the authenticated session by the client user, said request for re-instantiation transmitted from the second processor (Dekel: Paragraph [0026] states, "In an embodiment, a policy may be configured to periodically generate requests for authentication. For example, after 15 minutes of inactivity, the policy requires that the user reauthenticate with a username and password."); requesting one factor of authentication from the client user at the web-based graphical user interface (Paragraph [0026] states, "In an embodiment, a policy may be configured to periodically generate requests for authentication. For example, after 15 minutes of inactivity, the policy requires that the user reauthenticate with a username and password."); authenticating the client user directly via the web-based graphical user interface (Paragraph [0026] states, "For example, after 15 minutes of inactivity, the policy requires that the user reauthenticate with a username and password, and after 60 minutes of inactivity the policy requires that the user reauthenticate with MFA." Examiner's note: this statement indicates that when a user is active before the 60 minute mark and reauthenticates with a username and password, the user is directly authenticated without requiring a second authentication method.); re-instantiating the authenticated session (Dekel: Paragraph [0034] states, "The reconnect packet configures the user device 110 to end the current RDP session between the client device and the XRDP container, and reconnect with a new session token to the frontend server 124."), but fails to explicitly disclose: and formatting the web-based graphical user interface with the format including the one or more unsaved inputs and the one or more unsaved outputs.
However, Kaewka further discloses: and formatting the web-based graphical user interface with the format including the one or more [unsaved] inputs and the one or more [unsaved] outputs (Kaewka: [Column 24 line 67 and column 25 lines 1-6] and [Column 26 lines 31-34]. [Column 24 line 67 and column 25 lines 1-6] states, "Element 902 can be retrieved from storage using the value of the id attribute in element 904 in the modified document definition, so that the placeholder (element 904) can be replaced by the retrieved element 902 to restore element 902 if activity is detected in connection with tab 702 (or corresponding tab 802), thereby rendering element 902 operable in generating a content component for display." [Column 26 lines 31-34] states that "the element definition of the external program is modified to pause playback to suspend the external program and to initiate playback to restore the external program." Examiner's note: Since an external program is being initiated by a browser application, it is interpreted as a component of a web-based graphical user interface, and interaction with a browser application is via input/output, and playback gets reinitiated when activity is detected.), but fails to explicitly disclose: unsaved inputs and unsaved outputs.
However, Dekel discloses: unsaved inputs and unsaved outputs (Dekel: Paragraph [0058] states, "The user interface may be rendered using a virtual workload, such as the XRDP container, having a web browser which displays a web page rendered by an access portal server into which a user may provide input (i.e., the MFA response)." Examiner's note: since "The user interface may be rendered using a virtual workload" and a virtual container is usually in volatile memory, then it is interpreted that the input/output on the interface is unsaved.).
Regarding claim 2, Dekel discloses: The configurable authentication system of claim 1 wherein one of the two or more authentication factors includes an alphanumerical character set input by the client user (Dekel: Paragraph [0020] states, "The client device 110 may provide the access portal server 122 with login credentials, such as username and password." Examiner's note: usernames or passwords can be an alphanumeric set.).
Regarding claim 3, Dekel discloses: The configurable authentication system of claim 1 wherein one of the two or more authentication factors include verification of possession of a device (Dekel: Paragraph [0020] states that "the third party application may request a second form of identification, such as sending a code to a mobile phone associated with the user account.").
Regarding claim 4, Dekel discloses: The configurable authentication system of claim 3 wherein the device is a mobile device (Dekel: Paragraph [0020] states that "the third party application may request a second form of identification, such as sending a code to a mobile phone associated with the user account.").
Regarding claim 6, Dekel discloses: The configurable authentication system of claim 1 wherein one of the two or more authentication factors includes a biometric identifier (Dekel: Paragraph [0058] states, "An MFA challenge may be generated based on a physical object such as a security token, bank card, key card, and the like; knowledge the user possesses, such as a password, PIN, and the like; a biometric such as fingerprints, voice prints, and the like; and a location of the user device, for example by geolocating an IP address used by the user device.").
Claim 11 recites features similar to those in claim 1, therefore the similar features are rejected in a similar manner.
Kaewka further discloses: terminate the display of the web-based graphical user interface (Kaewka: Column 12 lines 30-33 states that “the disclosed systems and methods cause the execution of the external program to either be paused or terminated in response to detected inactivity in connection with the external program.” Examiner's note: Since an external program is being initiated by a browser application, it is interpreted as a component of a web-based graphical user interface, and it is being terminated after detecting inactivity.).
The same motivation to modify with Kaewka, as in claim 1, applies.
Claim 16 recites features similar to those in claim 1, therefore the similar features are rejected in a similar manner.
Dekel further discloses: completing the grace period on the web-based user interface (Dekel: Paragraph [0026] states that after 15 minutes of inactivity, the policy requires that the user reauthenticate with a username and password."), but fails to explicitly disclose: and permanently deleting the format of the web-based graphical user interface, the one or more unsaved inputs and the one or more unsaved outputs from the memory location within the first hardware memory.
Kaewka further discloses: and permanently deleting the format of the web-based graphical user interface, [the one or more unsaved inputs and the one or more unsaved outputs from the memory location within the first hardware memory] (Kaewka: Column 12 lines 30-33 states that “the disclosed systems and methods cause the execution of the external program to either be paused or terminated in response to detected inactivity in connection with the external program.” Examiner's note: Since an external program is being initiated by a browser application, it is interpreted as a component of a web-based graphical user interface, and interaction with a browser application is via input/output, and it is being terminated after detecting inactivity.).
Dekel and Kaewka do not explicitly disclose: and permanently deleting… the one or more unsaved inputs and the one or more unsaved outputs from the memory location within the first hardware memory.
However, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Dekel in view of Kaweka to include the above limitation because when a session is terminated and is no longer going to be re-instantiated, it is expected to permanently delete data associated with the session in order to free memory space from stale data.
The same motivation to modify with Kaewka, as in claim 1, applies.
Claims 17, 18, and 19 recite features similar to those in claims 2, 3, and 6 respectively, therefore they are rejected in a similar manner.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dekel (US 20230291726 A1, hereinafter referred to as Dekel) in view of Kaewka (US 10574768 B1, hereinafter referred to as Kaewka) in further view of Matthew (US 20170134471 A1, hereniafter referred to as Matthew) in further view of Anemikos (US 8176323 B2, hereinafter referred to as Anemikos).
Regarding claim 5, the combination of Dekel as modified by Kaewka and Matthew discloses: The configurable authentication system of claim 3, but fails to disclose: wherein the device is a radio frequency identification (“RFID”) device.
However, in the same field of endeavor, Anemikos discloses: wherein the device is a radio frequency identification (“RFID”) device (Anemikos: Column 3 lines 40-41 states, "Some ID badges (or cards) use radio frequency identification (RFID) tags (i.e., RFID transponders) for user authentication.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teaching of Dekel as modified by Kaewka and Matthew and include the above limitation with the teaching of Anemikos since RFID devices, "when activated, transmits an identifier (e.g., a passphrase, passcode, password, etc.) encrypted using a public key" (Column 1 lines 61-63).
Claim(s) 7-9 and 12-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dekel (US 20230291726 A1, hereinafter referred to as Dekel) in view of Kaewka (US 10574768 B1, hereinafter referred to as Kaewka) in further view of Matthew (US 20170134471 A1, hereniafter referred to as Matthew) in further view of Sokolov (US 10284556 B1, hereinafter referred to as Solokov).
Regarding claim 7, the combination of Dekel as modified by Kaewka and Matthew discloses: The configurable authentication system of claim 1, but fails to explicitly disclose: further comprising, upon receiving the request for the re-instantiation of the authenticated session by the client user, verifying that a device transmitting the request for re-instantiation is the same device as a device that initiated the authenticated session.
However, in the same field of endeavor, Sokolov discloses: further comprising, upon receiving the request for the re-instantiation of the authenticated session by the client user, verifying that a device transmitting the request for re-instantiation is the same device as a device that initiated the authenticated session (Sokolov: Column 3 lines 57-60 state, "by correlating authentication requests with IP address changes in client devices, the disclosed systems and methods may detect potentially unauthorized authentication attempts in real time.").
Therefore, it would have been obvious to one of ordinary skill in the art to modify the teaching of Dekel as modified by Kaewka and Matthew and include the above limitation with the teaching of Sokolov since "correlating authentication requests with IP address changes in client devices" allow the detection of "potentially unauthorized authentication attempts in real time" (Sokolov: Column 3 lines 57-60).
Regarding claim 8, the combination of Dekel as modified by Kaewka, Matthew and Sokolov discloses: The configurable authentication system of claim 7 wherein the verifying the device transmitting the request for re-instantiation includes verifying that an internet protocol (“IP”) address associated with the device transmitting the request for re-instantiation is the same IP address as an IP address of the device that initiated the authenticated session (Sokolov: Column 3 lines 57-60 state, "by correlating authentication requests with IP address changes in client devices, the disclosed systems and methods may detect potentially unauthorized authentication attempts in real time.").
The same motivation to modify with Sokolov, as in claim 7, applies.
Regarding claim 9, the combination Dekel as modified by Kaewka, Matthew and Sokolov discloses: The configurable authentication system of claim 7 wherein the verifying the device transmitting the request for re-instantiation includes verifying that a device identifier associated with the device transmitting the request for re-instantiation is the same device identifier as a device identifier of the device that initiated the authenticated session (Solokov: Column 3 lines 57-60 state, "by correlating authentication requests with IP address changes in client devices, the disclosed systems and methods may detect potentially unauthorized authentication attempts in real time." Examiner's note: an IP address is a device identifier.).
The same motivation to modify with Sokolov, as in claim 7, applies.
Claims 12, 13, and 14 recite features similar to those in claims 7, 8, and 9 respectively, therefore they are rejected in a similar manner.
Claim(s) 10 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dekel (US 20230291726 A1, hereinafter referred to as Dekel) in view of Kaewka (US 10574768 B1, hereinafter referred to as Kaewka) in further view of Matthew (US 20170134471 A1, hereniafter referred to as Matthew) in further view of Sokolov (US 10284556 B1, hereinafter referred to as Solokov) in further view of Chahine (US 20230023944 A1, hereinafter referred to as Chahine).
Regarding claim 10, the combination of Dekel as modified by Kaewka, Matthew, and Sokolov discloses: The configurable authentication system of claim 7, but fails to explicitly disclose: wherein the verifying the device transmitting the request for re-instantiation includes verifying that a detected geolocation of the device transmitting the request for re-instantiation is the same detected geolocation as a detected geolocation of the device that initiated the authenticated session.
However, in the same field of endeavor, Chahine discloses: wherein the verifying the device transmitting the request for re-instantiation includes verifying that a detected geolocation of the device transmitting the request for re-instantiation is the same detected geolocation as a detected geolocation of the device that initiated the authenticated session (Chahine: paragraph [0046] states that "geolocation of a user's mobile communication device, or whether a user's mobile device is connected to a particular network. For example, if a user is requesting authentication, the location of the user's mobile communication device being located in the same workspace 100, 400 as the user requesting authentication may indicate that the user is present and not an imposter.").
Therefore, it would have been obvious to one of ordinary skill in the art to modify the teaching of Dekel as modified by Kaewka, Matthew, and Sokolov and include the above limitation with the teaching of Chahine since "the location of the user's mobile communication device being located in the same workspace 100, 400 as the user requesting authentication may indicate that the user is present and not an imposter" (Chahine: Paragraph [0046]).
Claim 15 recites similar features to those in claim 10, therefore it is rejected in a similar manner.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHREYAJ RAM BHANDARI whose telephone number is (571)272-0727. The examiner can normally be reached 7:30-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, Ali Shayanfar can be reached at (571) 270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHREYAJ RAM BHANDARI/ Examiner, Art Unit 2434
/NOURA ZOUBAIR/ Primary Examiner, Art Unit 2434
Prosecution Insights