DETAILED ACTION
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 .
The finality mailed on 12/09/2025 has been withdrawn.
Response to Arguments
Applicant's arguments filed on 03/05/2026 have been fully considered but they are not persuasive.
Applicant argued in the remark that Jakob does not teach “defining a future date and time to implement an automated executable.
Examiner respectfully disagrees, Jakob discloses fig.4, 0084 TOTP generation 415 , i.e. AITAT utilizes current time 414. Wherein the TOTP is based on the current time but the current time includes date inherently. However, the newly found prior art ,Widdows, discloses defining a future date and time to a FTOTP ( fig.2, col 2, lines 7-11 The request from the application may include the future time, and the application server may thus use the future time as the time to generate the input passcode. And col 4, lines 4-7 a user may request a passcode for a future date and time (e.g., 2:00 pm on Jan. 17, 2020) and the passcode generated based on the future time will be valid at the identified lock at that future time).
Applicant argued in the remark that Jakob does not teach a future time-based one-time password.
Examiner respectfully disagrees, the newly found prior art ,Widdows, discloses defining a future date and time to a FTOTP ( fig.2, col 2, lines 7-11 The request from the application may include the future time, and the application server may thus use the future time as the time to generate the input passcode. And col 4, lines 4-7 a user may request a passcode for a future date and time (e.g., 2:00 pm on Jan. 17, 2020) and the passcode generated based on the future time will be valid at the identified lock at that future time).
Applicant argued in the remark that prior arts do not teach “comparing the hash of the FTOTP to generated hash of the automated executable.
Examiner respectfully disagrees. Widdows col 4, lines 3-21 a user may request a passcode for a future date and time (e.g., 2:00 pm on Jan. 17, 2020) and the passcode generated based on the future time will be valid at the identified lock at that future time. A user present at the lock when requesting the passcode may use the current time as the requested time so that the current time is used in algorithm 116 and the passcode works immediately, but not in the future. In order to further facilitate transmission and/or entry of the passcode, the time may be rounded to the next 10 minute mark by both application server 102 and lock 110A.
(12) As an example, algorithm 116A may include applying an MD5 hash function to the current POSIX time plus the number 104936. Algorithm 116B may include multiplying the time by 3 and applying a SHA1 algorithm, performing a string conversion, and appending the lock serial number to the end of the resulting string. Algorithm 116C may include taking the first 6 digits of the serial number of lock 110C and adding it to the first six digits of the current POSIX time
Applicant argued in the remark that prior arts do not teach outputting, from the trained machine learning model, that future date and time.
Examiner respectfully disagrees. Mezei discloses wherein the agentless IT automation tool is configured to validate the automated executable by comparing the hash of the TOTP to a generated hash of the automated executable prior to implementing the automated executable ( col 1, lines 51-67 col 2, lines 1-20A TOTP-based 2FA scheme works across web sites without requiring the end user to manually enter codes, or to have a dedicated mobile app for each particular site. In this approach, an end user leverages a cloud-based service as a repository for maintaining and securing the TOTP secrets (i.e., a TOTP shared secret per user per site) that are generated as the end user interacts with various TOTP setup pages i.e. the agentless IT automation tool is configured via a mobile device authenticator app. The cloud service is accessed when the end user subsequently attempts a TOTP-based login from a client browser to one of the sites (whose TOTP shared secret is already maintained in the repository). The client browser executes in a computing machine (e.g., a laptop) distinct from the end user's mobile device. To effect login, the end user opens the browser to a TOTP authentication page. The TOTP-based login attempt from the client browser is detected by a browser plug-in, and this detection initiates a push notification mechanism. In particular, the browser plug-in issues a request to the cloud service, which responds by sending a push notification to the end user mobile device authenticator app. If the end user responds to the push notification (e.g., within a given timeout), the cloud service uses the TOTP secret stored in the repository to generate the TOTP code, which code is then sent back to the browser plug-in. The browser plug-in then injects that code into an HTML login form of the TOTP authentication page, and then automatically submits the form. Thus, the user does not have to manually enter the TOTP code. The user is then logged in automatically to complete the process. This approach works for any site for which the cloud service maintains the TOTP shared secret for the end user. Thus, the cloud service enables the end user to access secure resources without requiring manual entry of TOTP codes, and by using just a single authenticator app instead of having to configure and use multiple different mobile apps across different web sites that implement this form of authentication. a TOTP-based 2FA scheme works across sites 114a-n without requiring the end user to manually enter TOTP codes, or to have a dedicated mobile app for each particular site. In this approach, an end user leverages the cloud-based service 108 as a repository for maintaining and securing the TOTP secrets (i.e., a TOTP shared secret per user per site) that are generated as the end user interacts with various TOTP setup pages via the generic mobile device authenticator app 102. The notion of “generic” here is not intended to be limiting; it just refers to the fact that the end user need use a distinct mobile app for each site that is enabled for access using TOTP-based authentication. A TOTP code typically is based on the TOTP secret and other factors, such as current date and time).
Applicant argued in the remark that prior arts do not teach a variable offset.
Examiner respectfully disagrees. Nair discloses wherein the FTOTP is further based on an offset ( col 13, lines 25-57 a Time-based One-time Password (TOTP) code is used as one or more of the factors comprising a multi-factor derived key 320,and deriving key material from a TOTP code is as follows: during a setup process, a fixed TOTP value such as “777777” is determined for an account. During a later key derivation process, in step 1, a user 110 computes the TOTP code during the normal multi-factor authentication process. In step 2, the difference between the current valid TOTP code and the fixed TOTP value (modulo maximum TOTP code value plus one) is also determined and returned to the user 110; for example, if the next TOTP value is “123456,” then the offset “654321” is stored because 123456+654321 (mod 1000000)=777777. In step 3a, the fixed TOTP value is retrieved by combining the TOTP code with the TOTP offset (modulo maximum TOTP code value plus one). This value can be used directly as the TOTP key material, or, in one embodiment, a KDF, PBKDF, or cryptographic hash function is used to convert the fixed TOTP value into key material. In step 4, any other factors are converted into key material, and in step 5, the key material from the various factors is used to derive a multi-factor derived key 320. In one embodiment, multiple TOTP offsets corresponding to the next several valid TOTP codes are returned by the authentication service 240 in step 2, allowing for a “window” of valid TOTP responses.),
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 5-9 and 15-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As per clams 5-9 and 15-19, this claim recite the phase “ f is a function.” , specification disclose0022 f/g is a function used to determine the FTOTP, 0023 inputting to function ƒ an additional function g enables fine-tuning of computational efficiency and cyber-resiliency to the FTOTP., Specification does not define the functions f/g which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor.
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 5-9 and 15-19 are 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.
As per clams 5-9 and 15-19, this claim recite the phase “ f is a function.” , specification disclose0022 f/g is a function used to determine the FTOTP, 0023 inputting to function ƒ an additional function g enables fine-tuning of computational efficiency and cyber-resiliency to the FTOTP., It is not clear the boundary of the above recited function, thus, claims are indefinite. Examiner is considering the limitations based on the teaching of the prior arts teaching.
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,11, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Jakob et al US 2024/0338308 in view of Widdows US 9,912,659.
As per claim 1, Jakob discloses a computer-implemented method comprising:
defining time to implement an automated executable on a server using an agentless Information Technology (IT) automation tool ( AITAT)( based on the specification, AITAT is a OTP provider ) (fig.4, 0084 TOTP generation 415 , i.e. AITAT utilizes current time 414 0023the UI automation tool communicates with the OTP generator module and requests a new OTP based on the secret. Once an OTP has been received, the UI automation tool will continue the execution flow and enter the OTP in the relevant element. Wherein the UI tool is executing the TOTP generation by providing the secret with the current time to generate the token code and the token code corresponding to a time-based one-time password (TOTP), par 0075 a shared secret is used to generate a token that is valid for a limited time, commonly thirty seconds to one minute. Wherein the thirty seconds to one minute is defined for the TOTP);
generating a Time-based One-Time Passwords (TOTP) for the automated executable based on the time ( 0084 TOTP generation 415 utilizes current time 414 and the TOTP shared key 416 obtained from UI automation tool 204 to cause TOTP generator 418 to generate a TOTP token code); and
providing the TOTP to the agentless IT automation tool to establish communication with the server for purposes of implementing the automated executable (0076 AUT 202 requests a TOTP login token in step 508, which is detected by UI automation tool 204 and 0086 UI automation tool 204 then provides the TOTP token to AUT 202, i.e. the agentless IT automation tool, in step 518).
Jakob does not disclose defining a future date and time to a FTOTP.
However, Widdows discloses defining a future date and time to a FTOTP ( fig.2, col 2, lines 7-11 The request from the application may include the future time, and the application server may thus use the future time as the time to generate the input passcode. And col 4, lines 4-7 a user may request a passcode for a future date and time (e.g., 2:00 pm on Jan. 17, 2020) and the passcode generated based on the future time will be valid at the identified lock at that future time).
Jakob and Widdows are both considered to be analogous to the claimed invention because they are in the same field of deriving the password by the server.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jakob to incorporate the teachings of Widdows and generate a password based on the future time that will be valid at that future time. Doing so would provide longer valid for the password, thereby gaining control of a still-functioning passcode (col 1, lines 30-31).
As per claim 11. Jakob discloses a system comprising: one or more processors (0026 separate processor service); and one or more computer-readable storage media storing program instructions which, when executed by the one or more processors,(0035 a processor coupled to a computer memory and having instructions to cause the processor to perform: executing the AUT) are configured to cause the one or more processors to perform a method comprising:
defining time to implement an automated executable on a server using an agentless Information Technology (IT) automation tool (fig.4, 0084 TOTP generation 415 utilizes current time 414 0023the UI automation tool communicates with the OTP generator module and requests a new OTP based on the secret. Once an OTP has been received, the UI automation tool will continue the execution flow and enter the OTP in the relevant element. Wherein the UI tool is executing the TOTP generation by providing the secret with the current time to generate the token code and the token code corresponding to a time-based one-time password (TOTP), par 0075 a shared secret is used to generate a token that is valid for a limited time, commonly thirty seconds to one minute. Wherein the thirty seconds to one minute is defined for the TOTP);
generating a Time-based One-Time Passwords (TOTP) for the automated executable based on the time ( 0084 TOTP generation 415 utilizes current time 414 and the TOTP shared key 416 obtained from UI automation tool 204 to cause TOTP generator 418 to generate a TOTP token code); and
providing the TOTP to the agentless IT automation tool to establish communication with the server for purposes of implementing the automated executable (0076 AUT 202 requests a TOTP login token in step 508, which is detected by UI automation tool 204 and 0086 UI automation tool 204 then provides the TOTP token to AUT 202, i.e. the agentless IT automation tool, in step 518).
Jakob does not disclose defining a future date and time to a FTOTP.
However, Widdows discloses defining a future date and time to a FTOTP ( fig.2, col 2, lines 7-11 The request from the application may include the future time, and the application server may thus use the future time as the time to generate the input passcode. And col 4, lines 4-7 a user may request a passcode for a future date and time (e.g., 2:00 pm on Jan. 17, 2020) and the passcode generated based on the future time will be valid at the identified lock at that future time).
Jakob and Widdows are both considered to be analogous to the claimed invention because they are in the same field of deriving the password by the server.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jakob to incorporate the teachings of Widdows and generate a password based on the future time that will be valid at that future time. Doing so would provide longer valid for the password, thereby gaining control of a still-functioning passcode (col 1, lines 30-31).
As per claim 20, Jakob discloses a computer program product comprising one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media (0035 a processor coupled to a computer memory and having instructions to cause the processor to perform: executing the AUT ), the program instructions comprising instructions configured to cause one or more processors to perform a method comprising:
defining time to implement an automated executable on a server using an agentless Information Technology (IT) automation tool (fig.4, 0084 TOTP generation 415 utilizes current time 414 0023the UI automation tool communicates with the OTP generator module and requests a new OTP based on the secret. Once an OTP has been received, the UI automation tool will continue the execution flow and enter the OTP in the relevant element. Wherein the UI tool is executing the TOTP generation by providing the secret with the current time to generate the token code and the token code corresponding to a time-based one-time password (TOTP), par 0075 a shared secret is used to generate a token that is valid for a limited time, commonly thirty seconds to one minute. Wherein the thirty seconds to one minute is defined for the TOTP);
generating a Time-based One-Time Passwords (TOTP) for the automated executable based on the time ( 0084 TOTP generation 415 utilizes current time 414 and the TOTP shared key 416 obtained from UI automation tool 204 to cause TOTP generator 418 to generate a TOTP token code); and
providing the TOTP to the agentless IT automation tool to establish communication with the server for purposes of implementing the automated executable (0076 AUT 202 requests a TOTP login token in step 508, which is detected by UI automation tool 204 and 0086 UI automation tool 204 then provides the TOTP token to AUT 202, i.e. the agentless IT automation tool, in step 518).
Jakob does not disclose defining a future date and time to a FTOTP.
However, Widdows discloses defining a future date and time to a FTOTP ( fig.2, col 2, lines 7-11 The request from the application may include the future time, and the application server may thus use the future time as the time to generate the input passcode. And col 4, lines 4-7 a user may request a passcode for a future date and time (e.g., 2:00 pm on Jan. 17, 2020) and the passcode generated based on the future time will be valid at the identified lock at that future time).
Jakob and Widdows are both considered to be analogous to the claimed invention because they are in the same field of deriving the password by the server.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jakob to incorporate the teachings of Widdows and generate a password based on the future time that will be valid at that future time. Doing so would provide longer valid for the password, thereby gaining control of a still-functioning passcode (col 1, lines 30-31).
As per claim 21. Jakob and Widdows discloses The computer-implemented method of claim 1, Widdows discloses further comprising: determining that the FTOTP matches an OTP generated by the server based on a current date and time that is the future date and time (col 4, lines 38-42 The locks 110 may use internal processors to compare a passcode input by a user at passcode interface 112 with a local passcode calculated locally by lock 110 using algorithm 116. And col 6, lines 40-50 Thus for each code input at passcode interface 112A, lock 110A may generate multiple passcodes over a range of times for comparison to the input code. The range of times may accommodate for the variation between times as read at lock 110A and application server 102 over time. Lock 110A may also monitor the time at which passcodes generated from the time match and use the time that generated the matching passcode to update its own time. and col 7, lines 25-40 application server 102 may also check access parameters for lock 110A. Access parameters may be submitted to application server 102 by lock owners using a computing device 104 in communication with application server 102. Lock owners may thus set access parameters such as, for example, available dates and times, unavailable dates and times, groups of individuals authorized for access, unauthorized groups, individual authorizations, or other suitable limits. The limits may be based on the user characteristics associated with user accounts registered with application server 102. The limits may also be based on unrelated criteria. For example, access to the locks may be restricted for dates ranging from Dec. 24, 2017 to Jan. 1, 2018. Application server 102 may return an error message or otherwise decline to provide a passcode in response to the user authentication failing, the access parameters restricting the requested use, or an invalid lock ID.); and implementing the automated executable in response to determining that the FTOTP matches the OTP(col 7, lines 55-60 The application server 102 may transmit the passcode to the application running on computing device 104. and col 8, lines 1-11 lock 110A may generate a local passcode using algorithm 116A stored in lock 110A (Block 212). The local passcode may be calculated by lock 110A independently from the input passcode, which was calculated by application server 102 and/or computing device 104. The algorithm 116A used by lock 110A to generate the local passcode may be deterministic such that the same local passcode results from the same input used by application server 102. The lock 110A may thus use the time to generate the local passcode. Multiple times within a range may be used as inputs to generate local passcodes for comparison to the input passcode and determine whether the input passcode is valid then the application server 102 may transmit the passcode to the application running on computing device 104).
Claim(s) 2, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Jakob et al US 2024/0338308 in view of Widdows US 9,912,659 in view of Mezei et al US 9,596,223.
As per claim 2, Jakob and Widdows disclose the computer-implemented method of claim 1, Jakob discloses wherein the FTOTP is further based on a hash of the automated executable ( Widdows col 4, lines 3-21 a user may request a passcode for a future date and time (e.g., 2:00 pm on Jan. 17, 2020) and the passcode generated based on the future time will be valid at the identified lock at that future time. A user present at the lock when requesting the passcode may use the current time as the requested time so that the current time is used in algorithm 116 and the passcode works immediately, but not in the future. In order to further facilitate transmission and/or entry of the passcode, the time may be rounded to the next 10 minute mark by both application server 102 and lock 110A.
(12) As an example, algorithm 116A may include applying an MD5 hash function to the current POSIX time plus the number 104936. Algorithm 116B may include multiplying the time by 3 and applying a SHA1 algorithm, performing a string conversion, and appending the lock serial number to the end of the resulting string. Algorithm 116C may include taking the first 6 digits of the serial number of lock 110C and adding it to the first six digits of the current POSIX time ).
The combination does not disclose wherein the agentless IT automation tool is configured to validate the automated executable by comparing the hash of the TOTP to a generated hash of the automated executable prior to implementing the automated executable(emphasis added).
However, Mezei discloses wherein the agentless IT automation tool is configured to validate the automated executable by comparing the hash of the TOTP to a generated hash of the automated executable prior to implementing the automated executable ( col 1, lines 51-67 col 2, lines 1-20A TOTP-based 2FA scheme works across web sites without requiring the end user to manually enter codes, or to have a dedicated mobile app for each particular site. In this approach, an end user leverages a cloud-based service as a repository for maintaining and securing the TOTP secrets (i.e., a TOTP shared secret per user per site) that are generated as the end user interacts with various TOTP setup pages i.e. the agentless IT automation tool is configured via a mobile device authenticator app. The cloud service is accessed when the end user subsequently attempts a TOTP-based login from a client browser to one of the sites (whose TOTP shared secret is already maintained in the repository). The client browser executes in a computing machine (e.g., a laptop) distinct from the end user's mobile device. To effect login, the end user opens the browser to a TOTP authentication page. The TOTP-based login attempt from the client browser is detected by a browser plug-in, and this detection initiates a push notification mechanism. In particular, the browser plug-in issues a request to the cloud service, which responds by sending a push notification to the end user mobile device authenticator app. If the end user responds to the push notification (e.g., within a given timeout), the cloud service uses the TOTP secret stored in the repository to generate the TOTP code, which code is then sent back to the browser plug-in. The browser plug-in then injects that code into an HTML login form of the TOTP authentication page, and then automatically submits the form. Thus, the user does not have to manually enter the TOTP code. The user is then logged in automatically to complete the process. This approach works for any site for which the cloud service maintains the TOTP shared secret for the end user. Thus, the cloud service enables the end user to access secure resources without requiring manual entry of TOTP codes, and by using just a single authenticator app instead of having to configure and use multiple different mobile apps across different web sites that implement this form of authentication. a TOTP-based 2FA scheme works across sites 114a-n without requiring the end user to manually enter TOTP codes, or to have a dedicated mobile app for each particular site. In this approach, an end user leverages the cloud-based service 108 as a repository for maintaining and securing the TOTP secrets (i.e., a TOTP shared secret per user per site) that are generated as the end user interacts with various TOTP setup pages via the generic mobile device authenticator app 102. The notion of “generic” here is not intended to be limiting; it just refers to the fact that the end user need use a distinct mobile app for each site that is enabled for access using TOTP-based authentication. A TOTP code typically is based on the TOTP secret and other factors, such as current date and time).
Jakob and Widdows and Mezei are both considered to be analogous to the claimed invention because they are in the same field of token accessing control.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jakob to incorporate the teachings of Widdows, including teaching of Mezei and provide a TOTP setup page. Doing so would setup flow by which a TOTP shared secret per user per site is generated and maintained in the cloud service; thereby the a site protected by TOTP-authentication.
As per claim 12, this claim is rejected based on the same rational set forth in the claim 2.
Claim(s) 3 and 13, are rejected under 35 U.S.C. 103 as being unpatentable over Jakob et al US 2024/0338308 in view of Widdows US 9,912,659 in view of Kras US 10,540,493.
As per claim 3. Jakob and Widdows disclose the computer-implemented method of claim 1, the combination fails to disclose
wherein defining the future data and time to implement the automated executable ( Widdows discloses fig.2, col 2, lines 7-11 The request from the application may include the future time, and the application server may thus use the future time as the time to generate the input passcode. And col 4, lines 4-7 a user may request a passcode for a future date and time (e.g., 2:00 pm on Jan. 17, 2020) and the passcode generated based on the future time will be valid at the identified lock at that future time ) further comprises: inputting information related to the automated executable, the server (col 1, lines 55-62 The application may request an input passcode from the application server based on a lock identifier (“ID”) associated with a lock. The application server retrieves an algorithm from a database using the lock ID and generates the input passcode using the algorithm with a time as the input. ), and outputting, from the server, the future date and time(col 4, lines 34-37 The passcodes output from algorithms 116 may be numeric, alphanumeric, or may include special characters as desired. Algorithm 116 selected for each lock is repeatable by application server 102 given an input time.);
the combination fails to disclose the agentless IT automation tool to a trained machine learning model of OTP; and outputting, from the trained machine learning model of the OTP.
However, Kras discloses the agentless IT automation tool to a trained machine learning model of OTP (col 1, lines 60-67 determining one or more users associated with a type of data breach and generating an electronic training campaign for the one or more users passed on the type of data breach, and communicating the electronic training campaign to the one or more users and col 14, lines 64-67 and col 15, lines 1-32 password electronic training campaign manager 210 includes customized training generator 214, which may be implemented as or contain virtual machine 216. In examples, customized training generator 214 is operable to integrate information from one or more of password IT policy manager 222, external breached password database 240, client 102, and risk score manager 234, to generate training campaigns related to password usage. In some examples, customized training generator 214 may generated training campaigns that are specific to a single user. In examples, customized training manager generates training campaigns that are applicable to multiple users, groups of users, or users associated with an entity. Password electronic training campaign manager 210 may include user interface manager 212. In some examples, responsive to a user input, password electronic training campaign manager 210 generates a training campaign, including one or more password training modules from password training modules storage 218. In some examples, password electronic training campaign manager 210 generates a training campaign, including one or more password training modules from password training modules storage 218, responsive to one or more inputs from risk score manager 234, password IT policy manager 222, and/or client 102. For example, password electronic training campaign manager 210 may generate a training campaign for a user responsive to a change in a user risk score from risk score manager 234. In examples, password electronic training campaign manager 210 may generate a training campaign for users associated with an entity responsive to a change in an entity risk score from risk score manager 234. In examples, password electronic training campaign manager 210 may generate a training campaign for users and/or for an entity responsive to a user or a user's password appearing in external breached password database 240. a change in an entity risk score from risk score manager 234. ); and outputting, from the trained machine learning model of the OTP(fig.3, col 1, lines 60-67 electronic training is provided, outputting, to users with passwords associated with a data breach, determining one or more users associated with a type of data breach and generating an electronic training campaign for the one or more users passed on the type of data breach, and communicating the electronic training campaign to the one or more users. In some examples, users selected for an electronic training campaign may include selecting one or more users based on a number of times the one or more users or a domain of the one or more users have been subject to one or more data breaches.).
Jakob and Widdows and Kras are both considered to be analogous to the claimed invention because they are in the same field of password deriving policy.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jakob to incorporate the teachings of Widdows, including the teaching of Kras and provide a remedial training or queue on or more users to take remedial training at a future time. Doing so would mitigate the risk of using password, thereby would reduce the risk.
As per claim 13, this claim is rejected based on the same rational set forth in the claim 3.
Claim(s) 4-9 and 15-19, are rejected under 35 U.S.C. 103 as being unpatentable over Jakob et al US 2024/0338308 in view of Widdows US 9,912,659 in view of Nair US 12,580,738.
As per claim 4. Jakob and Widdows disclose the computer-implemented method of claim 1, Widdows discloses wherein the FTOTP ( col 4, lines 10-16 In order to further facilitate transmission and/or entry of the passcode, the time may be rounded to the next 10 , i.e. offset value, minute mark by both application server 102 and lock 110A and algorithm 116A may include applying an MD5 hash function to the current POSIX time plus the number 104936). the combination fails to disclose wherein the FTOTP is further based on an offset (emphasis added).
However, Nair discloses wherein the FTOTP is further based on an offset ( col 13, lines 25-57 a Time-based One-time Password (TOTP) code is used as one or more of the factors comprising a multi-factor derived key 320,and deriving key material from a TOTP code is as follows: during a setup process, a fixed TOTP value such as “777777” is determined for an account. During a later key derivation process, in step 1, a user 110 computes the TOTP code during the normal multi-factor authentication process. In step 2, the difference between the current valid TOTP code and the fixed TOTP value (modulo maximum TOTP code value plus one) is also determined and returned to the user 110; for example, if the next TOTP value is “123456,” then the offset “654321” is stored because 123456+654321 (mod 1000000)=777777. In step 3a, the fixed TOTP value is retrieved by combining the TOTP code with the TOTP offset (modulo maximum TOTP code value plus one). This value can be used directly as the TOTP key material, or, in one embodiment, a KDF, PBKDF, or cryptographic hash function is used to convert the fixed TOTP value into key material. In step 4, any other factors are converted into key material, and in step 5, the key material from the various factors is used to derive a multi-factor derived key 320. In one embodiment, multiple TOTP offsets corresponding to the next several valid TOTP codes are returned by the authentication service 240 in step 2, allowing for a “window” of valid TOTP responses.),
Jakob and Widdows and Nair are both considered to be analogous to the claimed invention because they are in the same field of password deriving policy.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jakob to incorporate the teachings of Widdows, including the teaching of Nair and allowing for a “window” of valid TOTP responses. Doing so would allow to user the valid TOTP, thereby would reduce the risk.
As per claim 5. Jakob and Widdows and Nair discloses The computer-implemented method of claim 4, Nair discloses wherein the offset is a static offset, and wherein the FTOTP is characterized by f(t+o) where t is time, o is the static offset, and f is a function used to determine the FTOTP(col 2, lines 35-40 a password-based key derivation function is used to derive the user key from the user's password when it is needed. And col 13, lines 25-55 a Time-based One-time Password (TOTP) code is used as one or more of the factors comprising a multi-factor derived key 320, as shown in FIG. 37. As with HOTP, the commonality of TOTP makes it a desirable factor in a multi-factor derived key 320, but its constantly-changing nature complicates the deterministic derivation of TOTP-based key material. Furthermore, unlike HOTP, the next TOTP code cannot be determined upon successful key-derivation because it is time-dependent. One recommended way of deriving key material from a TOTP code is as follows: during a setup process, a fixed TOTP value such as “777777” is determined for an account. During a later key derivation process, in step 1, a user 110 computes the TOTP code during the normal multi-factor authentication process. In step 2, the difference between the current valid TOTP code and the fixed TOTP value (modulo maximum TOTP code value plus one) is also determined and returned to the user 110; for example, if the next TOTP value is “123456,” then the offset “654321” is stored because 123456+654321 (mod 1000000)=777777. In step 3a, the fixed TOTP value is retrieved by combining the TOTP code with the TOTP offset (modulo maximum TOTP code value plus one). This value can be used directly as the TOTP key material, or, in one embodiment, a KDF, PBKDF, or cryptographic hash function is used to convert the fixed TOTP value into key material. In step 4, any other factors are converted into key material, and in step 5, the key material from the various factors is used to derive a multi-factor derived key 320. In one embodiment, multiple TOTP offsets corresponding to the next several valid TOTP codes are returned by the authentication service 240 in step 2, allowing for a “window” of valid TOTP responses).
As per claim 6. Jakob and Widdows and Nair discloses the computer-implemented method of claim 4, Nair discloses wherein the offset is a variable offset, and wherein the FTOTP is characterized by f(t) + g(t) where t is time, f is a function used to determine the FTOTP, and g is the function used to determine the variable offset( col 14, lines 35-67 n SMS-based OTP is a desirable component of a multi-factor derived key 320. One recommended way of deriving key material from a One-Time Password (OTP) code sent via SMS or phone call is as follows: during a setup process, a fixed OTP value such as “777777” is determined for an account. During a later key derivation process, in step 1, a user 110 initiates a login process using other authentication factors. In step 2, the authentication service 240 confirms the login request and prompts the user 110 for a telephone OTP code. In step 3, the authentication service 240 sends a telephone OTP code to a telephone service (eg. via one or more telephone communication APIs), which is delivered to the user 110 via SMS or voice call in step 4. In step 5, the user 110 sends the received telephone OTP to the service; the multi-factor authentication process is now complete. In step 6, the OTP is validated and the difference between the current telephone OTP code and the fixed OTP value (modulo maximum OTP value plus one) is also determined and returned to the user 110; for example, if the telephone OTP value is “123456,” then the offset “654321” is returned because 123456+654321 (mod 1000000)=777777. In step 7a, the fixed OTP value is retrieved by combining the telephone OTP code with the telephone OTP offset (modulo maximum OTP value plus one). This value can be used directly as the telephone key material, or, in one embodiment, a KDF, PBKDF, or cryptographic hash function is used to convert the fixed OTP value into key material. In step 8, any other factors are converted into key material, and in step 9, the key material from the various factors is used to derive a multi-factor derived key 320.).
As per claim 7. Jakob and Widdows and Nair discloses the computer-implemented method of claim 4, Nair discloses wherein the offset is multiple functions, and wherein the FTOTP is characterized by g(f(t)) where t is time, f is a function used to determine the FTOTP, and g is another function(col 12, lines 40-67 an HMAC-based One-Time Password (HOTP) code is used as one or more of the factors comprising a multi-factor derived key 320, as shown in FIG. 36. An HOTP code is often one of the primary factors comprising a multi-factor authentication system and thus is a desirable factor to include in deriving a multi-factor derived key 320. However, unlike the previously described factors, the constantly-changing nature of an HOTP code makes deterministically deriving key material from HOTP difficult. One recommended way of deriving key material from an HOTP code is as follows: during a setup process, a fixed HOTP value such as “777777” is determined for an account. The HOTP key is determined, is encrypted with the derived key, and is then stored with the authentication service 240. The difference between the next valid HOTP code and the fixed HOTP value (modulo maximum HOTP code value plus one) is also determined and stored; for example, if the next HOTP value is “123456,” then the offset “654321” is stored because 123456+654321 (mod 1000000)=777777. During a later key derivation process, in step 1, a user 110 computes the HOTP code during the normal multi-factor authentication process. In step 2, the authentication service 240 returns the HOTP offset and encrypted HOTP key established during the setup process. In step 3a, the fixed HOTP value is retrieved by combining the HOTP code with the HOTP offset (modulo maximum HOTP code value plus one). This value can be used directly as the HOTP key material, or, in one embodiment, a KDF, PBKDF, or cryptographic hash function is used to convert the fixed HOTP value into key material. In step 4, any other factors are converted into key material, and in step 5, the key material from the various factors is used to derive a multi-factor derived key 320. In step 6, the HOTP key is retrieved by decrypting the encrypted HOTP key using the multi-factor derived key 320. In step 7, the next valid HOTP code is computed using the HOTP key and HOTP counter value (which may be included in the authentication service 240 response in plaintext or encrypted form). In step 8, the next HOTP offset is computed using the fixed HOTP value and the next HOTP code. The new HOTP offset is then stored in the authentication service 240 to be used for the next key derivation. Updating the HOTP offset upon each key derivation ensures that even while the HOTP code changes upon each login, constant key material (and thus a fixed multi-factor derived key 320) is obtained. In one embodiment, multiple HOTP offsets corresponding to the next several valid HOTP codes are stored in the authentication service 240 (and updated upon each successful key derivation), allowing for a “window” of valid HOTP responses and thereby enabling a few failed attempts to be made before the HOTP factor can no longer be used. ).
As per claim 8. Jakob and Widdows and Nair discloses the computer-implemented method of claim 4, Nair discloses wherein the offset is multiple functions, and wherein the FTOTP is characterized by f(g(t)) where t is time, f is a function used to determine the FTOTP, and g is another function( col 13, lines 25-57 an HMAC-based One-Time Password (HOTP) code is used as one or more of the factors comprising a multi-factor derived key 320, as shown in FIG. 36. An HOTP code is often one of the primary factors comprising a multi-factor authentication system and thus is a desirable factor to include in deriving a multi-factor derived key 320. However, unlike the previously described factors, the constantly-changing nature of an HOTP code makes deterministically deriving key material from HOTP difficult. One recommended way of deriving key material from an HOTP code is as follows: during a setup process, a fixed HOTP value such as “777777” is determined for an account. The HOTP key is determined, is encrypted with the derived key, and is then stored with the authentication service 240. The difference between the next valid HOTP code and the fixed HOTP value (modulo maximum HOTP code value plus one) is also determined and stored; for example, if the next HOTP value is “123456,” then the offset “654321” is stored because 123456+654321 (mod 1000000)=777777. During a later key derivation process, in step 1, a user 110 computes the HOTP code during the normal multi-factor authentication process. In step 2, the authentication service 240 returns the HOTP offset and encrypted HOTP key established during the setup process. In step 3a, the fixed HOTP value is retrieved by combining the HOTP code with the HOTP offset (modulo maximum HOTP code value plus one). This value can be used directly as the HOTP key material, or, in one embodiment, a KDF, PBKDF, or cryptographic hash function is used to convert the fixed HOTP value into key material. In step 4, any other factors are converted into key material, and in step 5, the key material from the various factors is used to derive a multi-factor derived key 320. In step 6, the HOTP key is retrieved by decrypting the encrypted HOTP key using the multi-factor derived key 320. In step 7, the next valid HOTP code is computed using the HOTP key and HOTP counter value (which may be included in the authentication service 240 response in plaintext or encrypted form). In step 8, the next HOTP offset is computed using the fixed HOTP value and the next HOTP code. The new HOTP offset is then stored in the authentication service 240 to be used for the next key derivation. Updating the HOTP offset upon each key derivation ensures that even while the HOTP code changes upon each login, constant key material (and thus a fixed multi-factor derived key 320) is obtained. In one embodiment, multiple HOTP offsets corresponding to the next several valid HOTP codes are stored in the authentication service 240 (and updated upon each successful key derivation), allowing for a “window” of valid HOTP responses and thereby enabling a few failed attempts to be made before the HOTP factor can no longer be used. ).
As per claim 9. Jakob and Widdows and Nair discloses the computer-implemented method of claim 4, Nair discloses wherein the offset is an external value obtained from an external data source, and wherein the FTOTP is characterized by f(t+o) where t is time, o is the external value obtained from the external data source, and f is a function used to determine the FTOTP(col 14, lines 35-67 mobile phone-based authentication (namely, SMS or voice call based authentication) is used as one or more of the factors comprising a multi-factor derived key 320, as shown in FIG. 40. SMS remains one of the most popular 2FA methods in the world, and thus an SMS-based OTP is a desirable component of a multi-factor derived key 320. One recommended way of deriving key material from a One-Time Password (OTP) code sent via SMS or phone call is as follows: during a setup process, a fixed OTP value such as “777777” is determined for an account. During a later key derivation process, in step 1, a user 110 initiates a login process using other authentication factors. In step 2, the authentication service 240 confirms the login request and prompts the user 110 for a telephone OTP code. In step 3, the authentication service 240 sends a telephone OTP code to a telephone service (eg. via one or more telephone communication APIs), which is delivered to the user 110 via SMS or voice call in step 4. In step 5, the user 110 sends the received telephone OTP to the service; the multi-factor authentication process is now complete. In step 6, the OTP is validated and the difference between the current telephone OTP code and the fixed OTP value (modulo maximum OTP value plus one) is also determined and returned to the user 110; for example, if the telephone OTP value is “123456,” then the offset “654321” is returned because 123456+654321 (mod 1000000)=777777. In step 7a, the fixed OTP value is retrieved by combining the telephone OTP code with the telephone OTP offset (modulo maximum OTP value plus one). This value can be used directly as the telephone key material, or, in one embodiment, a KDF, PBKDF, or cryptographic hash function is used to convert the fixed OTP value into key material. In step 8, any other factors are converted into key material, and in step 9, the key material from the various factors is used to derive a multi-factor derived key 320. ).
As per claims 15-19, those claims are rejected based on the same rational set forth in the claims 5-9 respectively.
Claim(s) 10 is rejected under 35 U.S.C. 103 as being unpatentable over Jakob in view of Widdows in view of Zait US 9,826,380.
As per claim 10. Jakob and Widdows disclose the computer-implemented method of claim 1, the Widdows discloses FTOTP code (col 4, lines 1-10 The time used as an input to algorithm 116 may be the current time or a future time. In that regard, a user may request a passcode for a future date and time (e.g., 2:00 pm on Jan. 17, 2020) and the passcode generated based on the future time will be valid at the identified lock at that future time), but the combination does not disclose
wherein the method is implemented by code downloaded from a remote data processing system , and wherein the computer-implemented method further comprises:
metering usage of the code; and generating an invoice based on metering the usage of the code.
However, Zait discloses wherein the method is implemented by code downloaded from a remote data processing system (col 7, lines 25-30 the policy engine 114 may send a metering request 136 to the gateway 118. For example, the metering request may be in the form of an Online AVP code (e.g., AVP code 100 indicating that a charging rule is to be enabled), or another equivalent code. ), and wherein the computer-implemented method further comprises: metering usage of the code (col 2, lines 38-50 metering Video over LTE (ViLTE) data usage by subscribers of a mobile telecommunication network. The metering of ViLTE data usage may be performed for ViLTE calls that are made by the subscribers. Such metering of ViLTE data usage may ensure that the data used by a subscriber during a ViLTE call is counted against a total amount of data that is allocated to the subscriber according to a periodic plan, e.g., a monthly service plan. Further, additional management capabilities for the metering of ViLTE data usage may block a subscriber that has exhausted the allocated data in a periodic billing cycle from making ViLTE calls until the next periodic cycle); and
generating an invoice based on metering the usage of the code (col 7, lines 4-20 the policy engine 114 is configured to meter ViLTE calls that are made by the user device 104 over the LTE connection. The metering of a ViLTE call means that data used by the user device 104 for the ViLTE call over the LTE connection is tracked and counted against the amount of allocated data for the user device 104 in each periodic billing cycle. For example, if the user device 104 is on a service plan that provides 5 GB of data per month for use by the user device 104, the amount of data used by the user device 104 for ViLTE calls is counted against this 5 GB allocation. The 5 GB of data may belong to a common data bucket that is shared by all data usages, e.g., web browsing, e-mail, web application usage, and/or so forth, as well as ViLTE calls. In other words, the service subscription plans provided to user devices by the mobile telecommunication network 102 may not provide separate categories of data usage, such as a separate category just for data used by ViLTE calls ).
Jakob and Widdows and Zait are both considered to be analogous to the claimed invention because they are in the same field of token accessing control.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jakob to incorporate the teachings of Widdows, including the Zait and provide a token based on the date and time. Doing so would provide a second factor authentication, thereby increasing the token strength.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights