DETAILED ACTION
Notice of Pre-AIA or AIA Status
In the present application, filed on or after March 16, 2013, claims 15-29 have been considered and examined under the first inventor to file provisions of the AIA .
Respond to Applicant’s Arguments/Remarks
Applicant’s arguments, see Remarks, filed 06/01/2026, with respect to the rejection(s) of claims 15-29 has been fully considered and the results as followings:
On pages 8-9 of Applicant’s remarks, Applicant argues that the combination of Ho, Klapman, and Kamkar does not teach the claimed invention because none of the cited references discloses a second time-based code series instance and/or or a configuration code instance.
Examiner respectfully disagrees with Applicant because
i) the claimed invention does not recite any limitations of a second time-based code series instance and/or or a configuration code instance, and
ii) as discussed in the Non-Final rejection mailed on 12/31/2025, the rejection relied upon the combination of Ho and Klapman to clearly disclose a code-check algorithm comprising at least one of the following: a second time-based code series instance; and a configuration code instance (Ho: [0045]-[0046], [0052]-[0055], [0063], [0066]-[0071], and FIG. 4-5: Upon receipt of the first factor authentication data by the electronic lock 210, the electronic lock 210 which is arranged in wireless communication with the application server will transmit the first factor authentication data, or its equivalent in a hash format, to the application server 160. At step 412, the application server 160 will validate the first factor authentication data with the first factor authentication data associated with the user and permission levels stored in the lock user database 161. The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits…The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits. The limits may be based on the specific roles and permission levels registered by the administrator or the access right owner on the role management module 110, user management module 112, lock management module 114 and grant access module 116. At step 424, if the second factor authentication data received by the user does not match the second factor authentication data generated by the server, the application server 160 may return an error message in response to the failed authentication, and the user will be requested to input the second factor authentication data again and Klapman: [0038], [0044]-[0045], [0050]-[0052], [0072]-[0073], [0092]-[0093], FIG. 1, and FIG. 4-6: Processor 111 receives a clocking signal from clock 112, which is processed to produce timestamp values representing instants in real-time. Processor 111 is configured to repeatedly and automatically generate a dynamically changing passcode (the “unlock passcode”), which is a time-varying code used for unlocking the data storage device 100, by processing the stored passcode generation key and reference time value. The reference time value is determined based on a time value obtained periodically from the clock 112 (i.e., to calculate a time differential, as described herein below). Processor 111 repeats the generation of a new passcode in response to a predefined time period value having expired, such as every 5 minutes, 30 minutes, 1 hour, 12 hours or any other time value. User device 120 is synchronized and therefore also generates new passcode at the same times).
As in the combination of Ho and Klapman, a controller access performs certain validate steps to determine whether to provide an access to a user (see above bolded citations of Ho and Klapman for details). Therefore, the combination of Ho and Klapman explicitly disclose a second time-based code series instance and/or or a configuration code instance.
On pages 9-10 of Applicant’s remarks, Applicant argues that the combination of Ho, Klapman, and Kamkar does not teach the limitations of wherein granting access to a resource comprises granting access to the resource for a period of time.
Examiner respectfully disagrees with Applicant because as in discussed in the Non-Final rejection mailed on 12/31/2025, the rejection relied upon the combination of Ho and Kamkar to clearly disclose wherein granting access to a resource comprises granting access to the resource for a period of time (Ho: [0057]: a grant access module 116 is used to manage, provision and grant access to specific access right grantees with assigned roles (by the role management module 110) to a specific electronic lock or a to a group of electronic locks. The access granted may be one-time or over a specific duration or interval, [0066], [0071], and FIG. 4: The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits. The limits may be based on the specific roles and permission levels registered by the administrator or the access right owner on the role management module 110, user management module 112, lock management module 114 and grant access module 116. At step 424, if the second factor authentication data received by the user does not match the second factor authentication data generated by the server, the application server 160 may return an error message in response to the failed authentication, and the user will be requested to input the second factor authentication data again and Kamkar: Abstract, [0061], [0073], [0079]-[0080], [0082], [0098], FIG. 1-3, and FIG. 6: As shown in FIG. 6, the simplified dynamic interface may include virtual button 601 for requesting access to secured resource 105. The simplified dynamic interface, and more specifically, the current access identifier used to access the simplified dynamic interface may remain valid for a specified period of time (e.g., 5 seconds). After the specified period of time, the URI or current access identifier of the simplified dynamic interface for accessing secured resource 105 may be changed, and the simplified dynamic interface that is accessed prior to the access identifier changing may no longer be used to request and/or gain access to secured resource 105).
On pages 10-11 of Applicant’s remarks, Applicant argues that the combination of Ho, Klapman, and Kamkar does not teach the limitations of claim 19 because it would not have been obvious to combine these references to have two instances of a time-based code wherein an action is taken if the input code does not match the first instance but does match the second instance.
Examiner respectfully disagrees with Applicant because i) the claimed invention does not recite any limitations of the relationship between the first instance and the second instance, and ii) as discussed in the Non-Final rejection mailed on 12/31/2025, the rejection relied upon the combination of Ho and Klapman to disclose a comparison of an input code from a user to a time-based code, if the input code matches the time-based code as unlock passcode to provide access to user (Ho: [0017], [0048], [0052], [0060]-[0071], [0073]-[0078], and FIG. 4-5 the electronic lock 210: If the second factor authentication data received from the user matches the second factor authentication data stored on the lock user database 161, the application server 160 will send a positive signal to the electronic lock which will cause the electronic lock to release its locking mechanism at step 426 to allow entry to the entry point and Klapman: Abstract, [0005], [0054], [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: In response to the first passcode matching with a second passcode, the second passcode being generated by the access controller 110 and including at least the unlock passcode, the access controller 110 provides access to the user content data 109 via the data port 106. That is, in this case the user providing the input passcode is considered as an authorized user of the DSD 100), otherwise returns corrupted data/error message (Ho: [0017], [0048], [0052], [0060]-[0071], [0073]-[0078], and FIG. 4-5 Klapman: Abstract, [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: The access controller 110 is configured to provide access to the user content data 109 in response to a match between the (first) received passcode entered into, or otherwise electronically provided to, the DSD 100 and the (second) passcode generated by the DSD 100, which are the input and unlock passcodes respectively in the described embodiments (i.e., as indicated in step 408). In some examples, a verification operation is performed by the access controller 110 to processes the unlock passcode and the input passcode. Processor 111 performs a comparison operation on the data representations of each code to check whether the input passcode matches with the unlock passcode). Thus, the combination of Ho, Klapman, and Kamkar reads on the limitations of claim 19.
On pages 11-12 of Applicant’s remarks, Applicant argues that the combination of Ho, Klapman, and Kamkar does not teach the limitations of “based on a determination that the input code matches the configuration code, perform a configuration action” as recited in claim 23.
Examiner respectfully disagrees with Applicant because as discussed in the Non-Final rejection mailed on 12/31/2025, the rejection relied upon the combination of Ho, Klapman, and Kamkar to clearly disclose based on a determination that the input code matches the configuration code, perform a configuration action (e.g. Ho: [0017], [0048], [0052], [0060]-[0071]: The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits. The limits may be based on the specific roles and permission levels registered by the administrator or the access right owner on the role management module 110, user management module 112, lock management module 114 and grant access module 116. If the first factor authentication data does not match the first factor authentication data registered by the user in the database at step 414, the application server 160 may return an error message in response to the failed authentication, failed permission level or other limits imposed by the various modules, and the user will be requested to input the first factor authentication data again at step 408. After a predetermined number of attempts, the application server may decline to provide a second factor authentication data, and the user will be denied entry, [0073]-[0078], and FIG. 4-5 the electronic lock 210: If the second factor authentication data received from the user matches the second factor authentication data stored on the lock user database 161, the application server 160 will send a positive signal to the electronic lock which will cause the electronic lock to release its locking mechanism at step 426 to allow entry to the entry point and Klapman: Abstract, [0005], [0054], [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: In response to the first passcode matching with a second passcode, the second passcode being generated by the access controller 110 and including at least the unlock passcode, the access controller 110 provides access to the user content data 109 via the data port 106. That is, in this case the user providing the input passcode is considered as an authorized user of the DSD 100). Thus, the combination of Ho, Klapman, and Kamkar reads on the limitations of based on a determination that the input code matches the configuration code, perform a configuration action.
On page 12 of Applicant’s remarks, Applicant argues that the combination of Ho, Klapman, and Kamkar does not teach the limitations of “wherein the configuration action comprises…grant privileged access” as recited in claim 24. Examiner respectfully disagrees with Applicant because Ho clearly discloses grant privileged access (e.g. Ho: [0017], [0048], [0052], [0060]-[0071]: The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits. The limits may be based on the specific roles and permission levels registered by the administrator or the access right owner on the role management module 110, user management module 112, lock management module 114 and grant access module 116. If the first factor authentication data does not match the first factor authentication data registered by the user in the database at step 414, the application server 160 may return an error message in response to the failed authentication, failed permission level or other limits imposed by the various modules, and the user will be requested to input the first factor authentication data again at step 408. After a predetermined number of attempts, the application server may decline to provide a second factor authentication data, and the user will be denied entry, [0073]-[0078], and FIG. 4-5 the electronic lock 210: If the second factor authentication data received from the user matches the second factor authentication data stored on the lock user database 161, the application server 160 will send a positive signal to the electronic lock which will cause the electronic lock to release its locking mechanism at step 426 to allow entry to the entry point).
On page 13 of Applicant’s remarks, Applicant argues that the combination of Ho, Klapman, Kamkar, and Davis does not teach the limitations of “wherein performing a second action comprises granting access to a resource for a second period of time that is different from the first period of time” as recited in claim 21 because Davis are about “a time period when the candidate access code is valid.”
Examiner respectfully disagrees with Applicant because as discussed in the Non-Final ejection mailed on 12/31/2025, the rejection relied upon Davis to clearly disclose wherein performing a second action comprises granting access to a resource for a second period of time that is different from the first period of time (Davis: Abstract: The access codes may each be valid from predefined start times for varying time intervals. In a further operation, a candidate access code can be generated at a control server, using the same pre-configured symmetric key. The candidate access code from the control server can be provided to the security locking device. The security locking device can unlock when the candidate access code corresponds to at least one of a valid security access codes on the security locking device, [0018], [0024], [0042]-[0048], [0053]-[0054], FIG. 2-3 and FIG. 7: The security locking device may generate multiple security access codes and the control server may generate multiple candidate access codes. A user who desires to open a security locking device may be assigned a candidate access code that is valid for a specific period of time. When the candidate access code is provided to the security access device by the user or delivery agent during a time period when the candidate access code is valid, then the security locking device may open… the security locking device may generate a new code for the 1 hour time interval 10 every hour at a specific time hourly epoch defined in advance. A time the new security access code may be generated is, for instance, on the hour every hour or at fifteen minutes after the hour, every hour. Similarly, for a 24 hour code 320, a new code may be generated each day at 12:00 midnight or at another selected time during each 24 hour period).
On pages 13-14 of Applicant’s remarks, Applicant argues that the combination of Ho, Klapman, Kamkar, and Davis does not teach the limitations of “wherein the configuration action comprises performing clock synchronization” as recited in claim 27 because Davis are about using already synchronized clock signals to generated and compare security access codes.
Examiner respectfully disagrees with Applicant because as discussed in the Non-Final ejection mailed on 12/31/2025, the rejection relied upon Davis to clearly disclose wherein the configuration action comprises performing clock synchronization (Davis: Abstract, [0041]: In one configuration, an initial clocking signal may be sent from the clock sync module 254 of the master server 250 to the clock sync module 208 of the control server. This initial clock signal may be sent over a network such as the internet. Further, the delivery agent 260 may obtain the clock sync signal from the control server when obtaining the candidate access code. Then, the delivery agent 260 may transfer a candidate access code to the security locking device 220, and the clock sync signal of the control server 202 may be sent to the clock sync signal module 232 of the security locking device 220. The synchronized clock signals may allow the security access code and the candidate access code to be compared during the time the generated security access codes are valid, [0048]-[0051], and FIG. 2-3: the synchronized clock signals may allow the security access code and the candidate access code to be compared during the time the generated security access codes are valid. If the candidate access code has been submitted during a valid time interval and the candidate access code matches with the security access code, then a successful candidate access code has been submitted and the locking hardware may be opened).
Therefore, in view of teachings by Ho, Klapman, Kamkar, and Davis, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the security system of Ho, Klapman, and Kamkar to include wherein the configuration action comprises performing clock synchronization, as suggested by Davis. The motivation for this is to selectively control a security access device based on setting periods using a clock synchronization between a server and a security locking device.
As a result, Applicant arguments are not deemed persuasive, and the previous rejections pertaining to the previous set of claims are sustained. Therefore, due to the claimed amendments, upon further consideration, a new ground of rejections necessitated by amendments is made in view of following reference/combinations.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 15-20 and 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over Ho et al. (Ho – US 2021/0319639 A1) in view of Klapman et al. (Klapman – US 2022/0414205 A1) and Kamkar et al. (Kamkar – US 2021/0360403 A1).
As to claim 15, Ho discloses an access control system, comprising:
an access management server (Ho: [0017], [0048], [0052], [0060]-[0071], and FIG. 1 the application server 160: the application server 160 will validate the first factor authentication data with the first factor authentication data associated with the user and permission levels stored in the lock user database 161… the application server 160 will validate the second factor authentication data with the second factor authentication data associated with the user and permission levels stored in the lock user database 161. The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits);
an access control device (Ho: [0073]-[0078] and FIG. 5 the electronic lock 210) that is physically remote from the access management server (Ho: [0017], [0048], [0052], [0060]-[0071], [0073]-[0078], and FIG. 5 the electronic lock 210: Upon receipt of the second factor authentication data by the electronic lock 210, the electronic lock, which is arranged in wireless communication with the application server, will transmit the second factor authentication data to the application server 160);
a first time-based code series instance (Ho: [0044]-[0045], [0052], [0068]-[0071], and FIG. 4-5), and
non-transitory computer executable instructions that are stored at the access control device and that, when executed (Ho: [0037], [0048], [0079]-[0080], and FIG. 5), cause the access control device to:
receive an input time-based code ([0044]-[0045], [0052], [0054]-[0055], [0068]-[0072], and FIG. 4-5: Upon receipt of the second factor authentication data by the electronic lock 210, the electronic lock, which is arranged in wireless communication with the application server, will transmit the second factor authentication data to the application server 160. At step 422, the application server 160 will validate the second factor authentication data with the second factor authentication data associated with the user and permission levels stored in the lock user database 161); and
based on the match between the generated time-based code and the input time- based code, perform an action (Ho: [0017], [0048], [0052], [0060]-[0071], [0073]-[0078], and FIG. 4-5 the electronic lock 210: If the second factor authentication data received from the user matches the second factor authentication data stored on the lock user database 161, the application server 160 will send a positive signal to the electronic lock which will cause the electronic lock to release its locking mechanism at step 426 to allow entry to the entry point ); and
a code-check algorithm comprising at least one of the following: a second time-based code series instance; and a configuration code instance (Ho: [0045]-[0046], [0052]-[0055], [0063], [0066]-[0071], and FIG. 4-5: Upon receipt of the first factor authentication data by the electronic lock 210, the electronic lock 210 which is arranged in wireless communication with the application server will transmit the first factor authentication data, or its equivalent in a hash format, to the application server 160. At step 412, the application server 160 will validate the first factor authentication data with the first factor authentication data associated with the user and permission levels stored in the lock user database 161. The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits…The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits. The limits may be based on the specific roles and permission levels registered by the administrator or the access right owner on the role management module 110, user management module 112, lock management module 114 and grant access module 116. At step 424, if the second factor authentication data received by the user does not match the second factor authentication data generated by the server, the application server 160 may return an error message in response to the failed authentication, and the user will be requested to input the second factor authentication data again).
Ho does not explicitly disclose a first time-based code series instance , comprising:
a shared seed code that is known to both the access management server and to the access control device;
a time-based code generation algorithm that is known to both the access management server and to the access control device;
an access control device clock that is synchronized to an access management server clock; and
a time-based code generation schedule that is known to both the access management server and to the access control device, wherein (i) the time-based code generation schedule comprises a set of time periods wherein each time period is associated with a clock begin value and a clock end value (where the lock begin value and the clock end value could be the same); and (ii) the set of time periods may be based on an algorithm for generating time periods based on an input clock value; and
non-transitory computer executable instructions that are stored at the access control device and that, when executed, cause the access control device to:
receive an input time-based code;
generate a generated time-based code from the time-based code series instance using (i) a current clock value from the access control device clock and (ii) the time-based code generation schedule;
compare the input time-based code with the generated time-based code;
determine that the input time-based code matches the generated time-based code; and
based on the match between the generated time-based code and the input time- based code, perform an action; and
a code-check algorithm comprising at least one of the following: a second time-based code series instance; and a configuration code instance.
However, it has been known in the art of security systems to implement the first time-based code series instance as claimed, as suggested by Klapman, which discloses
a first time-based code series instance (Klapman: [0037], [0051], [0072]-[0073], [0076], [0078]-[0079], and FIG. 4-5), comprising:
a shared seed code (Klapman: [0037], [0051], [0077]-[0078], and FIG. 4-5: the TOTP passcodes produced by generation routine 500 produces are a form of hash-based message authentication code (HMAC), where the source of uniqueness is typically a value generated from the current time and a unique seed number);
a time-based code generation algorithm that is known to both the access management server and to the access control device (Klapman: Abstract, [0023]: wherein the input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the data storage device; and provide access to the user content data via a data port of the data storage device in response to the first passcode matching with a second passcode generated by the data storage device, wherein the second passcode includes at least the unlock passcode, [0034]: the second passcode generated by the DSD 100 includes only the dynamically changing unlock passcode that is matched to a corresponding “input” passcode constituting the received first passcode. The input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the access controller, [0037]-[0038]: the user device 120 determines the input passcode, to be entered by the user into the DSD, by retrieving the input passcode or a seed value to generate the input passcode from a remote location, such as a passcode server, [0075]);
an access control device clock that is synchronized to an access management server clock (Klapman: Abstract, [0023]: wherein the input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the data storage device; and provide access to the user content data via a data port of the data storage device in response to the first passcode matching with a second passcode generated by the data storage device, wherein the second passcode includes at least the unlock passcode, [0034]: the second passcode generated by the DSD 100 includes only the dynamically changing unlock passcode that is matched to a corresponding “input” passcode constituting the received first passcode. The input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the access controller, [0037]-[0038]: the user device 120 determines the input passcode, to be entered by the user into the DSD, by retrieving the input passcode or a seed value to generate the input passcode from a remote location, such as a passcode server, [0048], [0052], [0055], [0073], [0075], [0120], and FIG. 1: a synchronization data message enabling synchronization of the reference time value T.sub.ref for the device 100 and the other user's DSDMA; and any other parameter data required for the other user's DSDMA to compute unlock codes for the device 100. The synchronization data message can include a reference time relative to a common clock, and established via a distributed time synchronization protocol (e.g., the Network Time Protocol (NTP))); and
a time-based code generation schedule that is known to both the access management server and to the access control device (Klapman: [0038], [0050]-[0052], [0072]-[0073], [0092]-[0093], FIG. 1, and FIG. 6: Processor 111 repeats the generation of a new passcode in response to a predefined time period value having expired, such as every 5 minutes, 30 minutes, 1 hour, 12 hours or any other time value. User device 120 is synchronized and therefore also generates new passcode at the same times),
wherein (i) the time-based code generation schedule comprises a set of time periods wherein each time period is associated with a clock begin value and a clock end value (where the lock begin value and the clock end value could be the same); and (ii) the set of time periods may be based on an algorithm for generating time periods based on an input clock value (Klapman: [0037], [0051]-[0052], [0072]-[0073], [0076], [0078]-[0079], and FIG. 4-5: Processor 111 receives a clocking signal from clock 112, which is processed to produce timestamp values representing instants in real-time. Processor 111 is configured to repeatedly and automatically generate a dynamically changing passcode (the “unlock passcode”), which is a time-varying code used for unlocking the data storage device 100, by processing the stored passcode generation key and reference time value. The reference time value is determined based on a time value obtained periodically from the clock 112 (i.e., to calculate a time differential, as described herein below). Processor 111 repeats the generation of a new passcode in response to a predefined time period value having expired, such as every 5 minutes, 30 minutes, 1 hour, 12 hours or any other time value. User device 120 is synchronized and therefore also generates new passcode at the same times); and
non-transitory computer executable instructions that are stored at the access control device and that, when executed, cause the access control device (Klapman: FIG. 1 the access controller 110 of the data storage device (DSD) 100) to:
receive an input time-based code (Klapman: [0048]-[0051], [0053]-[0055], [071]-[0075], [0088], and FIG. 1 the input passcode at input component 102: The DSD 100 receives a passcode from user 101 (either by manual input via the input components 102, or electronically), including at least the input passcode provided by user device 120. In this embodiment, as shown in step 406, the received passcode is the input passcode generated synchronously by the DSDMA 300 of the user device 120 with the generation of the unlock passcode by the access controller 110 of the DSD 100. FIG. 6 illustrates a flow diagram for an input passcode generation routine 600 performed by the DSDMA 300 and invoked by user 101. At step 602, the user 101 configures the application 300 to manage the DSD 100, thereby enabling the generation of input passcode values for the device 100);
generate a generated time-based code from the time-based code series instance using (i) a current clock value from the access control device clock and (ii) the time-based code generation schedule (Klapman: [0037], [0051]-[0052], [0072]-[0073], [0076], [0078]-[0079], and FIG. 4-5: Processor 111 receives a clocking signal from clock 112, which is processed to produce timestamp values representing instants in real-time. Processor 111 is configured to repeatedly and automatically generate a dynamically changing passcode (the “unlock passcode”), which is a time-varying code used for unlocking the data storage device 100, by processing the stored passcode generation key and reference time value. The reference time value is determined based on a time value obtained periodically from the clock 112 (i.e., to calculate a time differential, as described herein below). Processor 111 repeats the generation of a new passcode in response to a predefined time period value having expired, such as every 5 minutes, 30 minutes, 1 hour, 12 hours or any other time value. User device 120 is synchronized and therefore also generates new passcode at the same times);
compare the input time-based code with the generated time-based code (Klapman: Abstract, [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: The access controller 110 is configured to provide access to the user content data 109 in response to a match between the (first) received passcode entered into, or otherwise electronically provided to, the DSD 100 and the (second) passcode generated by the DSD 100, which are the input and unlock passcodes respectively in the described embodiments (i.e., as indicated in step 408). In some examples, a verification operation is performed by the access controller 110 to processes the unlock passcode and the input passcode. Processor 111 performs a comparison operation on the data representations of each code to check whether the input passcode matches with the unlock passcode);
determine that the input time-based code matches the generated time-based code (Klapman: Abstract, [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: The access controller 110 is configured to provide access to the user content data 109 in response to a match between the (first) received passcode entered into, or otherwise electronically provided to, the DSD 100 and the (second) passcode generated by the DSD 100, which are the input and unlock passcodes respectively in the described embodiments (i.e., as indicated in step 408). In some examples, a verification operation is performed by the access controller 110 to processes the unlock passcode and the input passcode. Processor 111 performs a comparison operation on the data representations of each code to check whether the input passcode matches with the unlock passcode); and
based on the match between the generated time-based code and the input time- based code, perform an action (Klapman: Abstract, [0005], [0054], [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: In response to the first passcode matching with a second passcode, the second passcode being generated by the access controller 110 and including at least the unlock passcode, the access controller 110 provides access to the user content data 109 via the data port 106. That is, in this case the user providing the input passcode is considered as an authorized user of the DSD 100); and
a code-check algorithm comprising at least one of the following: a second time-based code series instance; and a configuration code instance (Klapman: [0038], [0044]-[0045], [0050]-[0052], [0072]-[0073], [0092]-[0093], FIG. 1, and FIG. 4-6: Processor 111 receives a clocking signal from clock 112, which is processed to produce timestamp values representing instants in real-time. Processor 111 is configured to repeatedly and automatically generate a dynamically changing passcode (the “unlock passcode”), which is a time-varying code used for unlocking the data storage device 100, by processing the stored passcode generation key and reference time value. The reference time value is determined based on a time value obtained periodically from the clock 112 (i.e., to calculate a time differential, as described herein below). Processor 111 repeats the generation of a new passcode in response to a predefined time period value having expired, such as every 5 minutes, 30 minutes, 1 hour, 12 hours or any other time value. User device 120 is synchronized and therefore also generates new passcode at the same times).
Therefore, in view of teachings by Ho and Klapman, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the security system of Ho to include the first time-based code series instance, as suggested by Klapman. The motivation for this is to implement a known alternative time-based code for authentication a user before providing access to the user.
While the combination of Ho and Klapman discloses a method/system for generating a time-based code series instance using seed value (Klapman: [0037], [0051], [0077]-[0078], and FIG. 4-5: the TOTP passcodes produced by generation routine 500 produces are a form of hash-based message authentication code (HMAC), where the source of uniqueness is typically a value generated from the current time and a unique seed number), the combination of Ho and Klapman does not explicitly disclose a shared seed code that is known to both the access management server and to the access control device.
However, it has been known in the art of security system to implement a shared seed code that is known to both the access management server and to the access control device, as suggested by Kamkar, which discloses a shared seed code that is known to both the access management server and to the access control device (Kamkar: Abstract, [0017], [0020]-[0022], [0036], and FIG. 1: In embodiments based on a random or pseudo-random number generator, the number generator of each resource access device 103 may be seeded with a different value. Based on the seed value and the current time, the number generator generates different rolling codes that form a dynamic part of the access identifiers (e.g., “˜/43234” or “˜/678asd”). … In some such embodiments, access control unit 107 may be configured with the same seed value as each resource access device 103. Access control unit 107 may use the seed values to synchronously generate the same rolling code and/or access identifier at the same time as each resource access device 103. In this manner, the generation (at 212 and 214) of access identifiers at each resource access device 103 and access control unit 107 may be synchronized without the devices having to exchange access identifier data with one another).
Therefore, in view of teachings by Ho, Klapman, and Kamkar, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the security system of Ho and Klapman to include a shared seed code that is known to both the access management server and to the access control device, as suggested by Kamkar. The motivation for this is to implement a known alternative time-based code for authentication a user before providing access to the user.
As to claim 16, Ho, Klapman, and Kamkar discloses the limitations of claim 15 further comprising the access control system of claim 15, wherein performing an action comprises granting access to a resource (Ho: [0017], [0048], [0052], [0060]-[0071], [0073]-[0078], and FIG. 4-5 the electronic lock 210: If the second factor authentication data received from the user matches the second factor authentication data stored on the lock user database 161, the application server 160 will send a positive signal to the electronic lock which will cause the electronic lock to release its locking mechanism at step 426 to allow entry to the entry point, Klapman: Abstract, [0005], [0054], [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: In response to the first passcode matching with a second passcode, the second passcode being generated by the access controller 110 and including at least the unlock passcode, the access controller 110 provides access to the user content data 109 via the data port 106. That is, in this case the user providing the input passcode is considered as an authorized user of the DSD 100, and Kamkar: Abstract, [0024]-[0025], [0061], [0073], and FIG. 1-3: Access control unit 107 may determine if visitor UE 101 is authorized to access secured resource 105 based on the received visitor access code and/or the access identifier used by visitor UE 101 to access the dynamic interface. In response to successfully authorizing visitor UE 101 to access secured resource 105, access control unit 107 may issue (at 422) a command or signaling to secured resource 105. In response to the issued (at 422) command or signaling, secured resource 105 may provide (at 424) access or otherwise change state).
As to claim 17, Ho, Klapman, and Kamkar discloses the limitations of claim 16 further comprising the access control system of claim 16, wherein granting access to a resource comprises granting access to the resource for a period of time (Ho: [0066], [0071], and FIG. 4: The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits. The limits may be based on the specific roles and permission levels registered by the administrator or the access right owner on the role management module 110, user management module 112, lock management module 114 and grant access module 116. At step 424, if the second factor authentication data received by the user does not match the second factor authentication data generated by the server, the application server 160 may return an error message in response to the failed authentication, and the user will be requested to input the second factor authentication data again and Kamkar: Abstract, [0061], [0073], [0079]-[0080], [0082], [0098], FIG. 1-3, and FIG. 6: As shown in FIG. 6, the simplified dynamic interface may include virtual button 601 for requesting access to secured resource 105. The simplified dynamic interface, and more specifically, the current access identifier used to access the simplified dynamic interface may remain valid for a specified period of time (e.g., 5 seconds). After the specified period of time, the URI or current access identifier of the simplified dynamic interface for accessing secured resource 105 may be changed, and the simplified dynamic interface that is accessed prior to the access identifier changing may no longer be used to request and/or gain access to secured resource 105).
As to claim 18, Ho, Klapman, and Kamkar discloses the limitations of claim 15 further comprising the access control system of claim 15, wherein the first time-based code series instance is associated with a first user (Ho: Abstract, [0010], [0046], [0052]-[0055], [0068]-[0071], and FIG. 4-5: When the access right owner or the access right grantee is provisioned for right of entry and exit via the associated electronic lock identified by an associated lock ID, the administrator will capture the personal details of the access right owner and the access right grantees, which may include names, addresses, contact numbers, user device numbers, user device serial number or identification numbers, and/or biometric signatures that can be used for authentication of the first factor authentication or second factor authentication, Klapman: [0070], and FIG. 1: the data store 304 is implemented as a series of data tables forming a relational database accessible via a database management system (DBMS) submodule of the store 304. A user table is defined to store the user information including, in relation to user 101: a user ID key (UID) uniquely identifying the user 101 among all users of the DSDMA 300; a user account identifier (UAC) of an application account of user 101 for operation of the DSDMA 300; and personal details of the user 101 including a name, address, and phone number. The account identifier maps to a corresponding entry in a user account table containing information for the user 101 to authenticate themselves with the DSDMA 300, such as for example, user password data and recovery information (e.g., a secret question and answer combination). The data store 304 may store particular data in a secure form, such as for example by applying a cryptographic primitive (e.g., the SHA-1 hash function) to the values prior to their entry into the database, and Kamkar: [0014], [0027], [0073], [0088]-[0089], [0099], and FIG. 1-3: Access control unit 107 may authorize (at 122) visitor UE 101 access to secured resource 105 based on the data transmitted (at 120) by visitor UE 101 and/or the access identifier of the dynamic interface. In some embodiments, access control unit 107 may authorize (at 122) access by determining that access is requested for secured resource 105 based on the access identifier (e.g., the fixed first portion or the changing second portion of the URI) used to access the dynamic interface, determining that the dynamic interface is valid or was valid when accessed by visitor UE 101 (e.g., the authorization occurs within an expiration time of providing the dynamic interface to visitor UE 101), and comparing the transmitted visitor access code or login credentials against a list of valid visitor access codes or authorized users. Authorizing (at 122) may further include validating access according to any restrictions that are defined for the valid visitor code or authorized user).
As to claim 19, Ho, Klapman, and Kamkar discloses the limitations of claim 15 further comprising the access control system of claim 15, wherein: the code-check algorithm comprises a second time-based code series instance (Ho: [0045]-[0046], [0052]-[0055], [0063], [0066]-[0071], and FIG. 4-5: Upon receipt of the first factor authentication data by the electronic lock 210, the electronic lock 210 which is arranged in wireless communication with the application server will transmit the first factor authentication data, or its equivalent in a hash format, to the application server 160. At step 412, the application server 160 will validate the first factor authentication data with the first factor authentication data associated with the user and permission levels stored in the lock user database 161. The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits…The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits. The limits may be based on the specific roles and permission levels registered by the administrator or the access right owner on the role management module 110, user management module 112, lock management module 114 and grant access module 116. At step 424, if the second factor authentication data received by the user does not match the second factor authentication data generated by the server, the application server 160 may return an error message in response to the failed authentication, and the user will be requested to input the second factor authentication data again);
the second time-based code series instance (Ho: [0044]-[0045], [0052], [0068]-[0071], and FIG. 4-5, Klapman: [0037], [0051], [0072]-[0073], [0076], [0078]-[0079], and FIG. 4-5) comprises:
a second shared seed code (Klapman: [0037], [0051], [0077]-[0078], and FIG. 4-5: the TOTP passcodes produced by generation routine 500 produces are a form of hash-based message authentication code (HMAC), where the source of uniqueness is typically a value generated from the current time and a unique seed number) that is known to both the access management server and to the access control device (Kamkar: Abstract, [0017], [0020]-[0022], [0036], and FIG. 1: In embodiments based on a random or pseudo-random number generator, the number generator of each resource access device 103 may be seeded with a different value. Based on the seed value and the current time, the number generator generates different rolling codes that form a dynamic part of the access identifiers (e.g., “˜/43234” or “˜/678asd”). … In some such embodiments, access control unit 107 may be configured with the same seed value as each resource access device 103. Access control unit 107 may use the seed values to synchronously generate the same rolling code and/or access identifier at the same time as each resource access device 103. In this manner, the generation (at 212 and 214) of access identifiers at each resource access device 103 and access control unit 107 may be synchronized without the devices having to exchange access identifier data with one another);
a second time-based code generation algorithm that is known to both the access management server and to the access control device (Klapman: Abstract, [0023]: wherein the input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the data storage device; and provide access to the user content data via a data port of the data storage device in response to the first passcode matching with a second passcode generated by the data storage device, wherein the second passcode includes at least the unlock passcode, [0034]: the second passcode generated by the DSD 100 includes only the dynamically changing unlock passcode that is matched to a corresponding “input” passcode constituting the received first passcode. The input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the access controller, [0037]-[0038]: the user device 120 determines the input passcode, to be entered by the user into the DSD, by retrieving the input passcode or a seed value to generate the input passcode from a remote location, such as a passcode server, [0075]);
a second access control device clock that is synchronized to a second access management server clock (Klapman: Abstract, [0023]: wherein the input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the data storage device; and provide access to the user content data via a data port of the data storage device in response to the first passcode matching with a second passcode generated by the data storage device, wherein the second passcode includes at least the unlock passcode, [0034]: the second passcode generated by the DSD 100 includes only the dynamically changing unlock passcode that is matched to a corresponding “input” passcode constituting the received first passcode. The input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the access controller, [0037]-[0038]: the user device 120 determines the input passcode, to be entered by the user into the DSD, by retrieving the input passcode or a seed value to generate the input passcode from a remote location, such as a passcode server, [0048], [0052], [0055], [0073], [0075], [0120], and FIG. 1: a synchronization data message enabling synchronization of the reference time value T.sub.ref for the device 100 and the other user's DSDMA; and any other parameter data required for the other user's DSDMA to compute unlock codes for the device 100. The synchronization data message can include a reference time relative to a common clock, and established via a distributed time synchronization protocol (e.g., the Network Time Protocol (NTP))); and
a second time-based code generation schedule that is known to both the access management server and to the access control device (Klapman: [0038], [0050]-[0052], [0072]-[0073], [0092]-[0093], FIG. 1, and FIG. 6: Processor 111 repeats the generation of a new passcode in response to a predefined time period value having expired, such as every 5 minutes, 30 minutes, 1 hour, 12 hours or any other time value. User device 120 is synchronized and therefore also generates new passcode at the same times),
wherein (i) the second time-based code generation schedule comprises a set of time periods wherein each time period is associated with a clock begin value and a clock end value (where the lock begin value and the clock end value could be the same); and (ii) the set of time periods may be based on an algorithm for generating time periods based on an input clock value (Klapman: [0037], [0051]-[0052], [0072]-[0073], [0076], [0078]-[0079], and FIG. 4-5: Processor 111 receives a clocking signal from clock 112, which is processed to produce timestamp values representing instants in real-time. Processor 111 is configured to repeatedly and automatically generate a dynamically changing passcode (the “unlock passcode”), which is a time-varying code used for unlocking the data storage device 100, by processing the stored passcode generation key and reference time value. The reference time value is determined based on a time value obtained periodically from the clock 112 (i.e., to calculate a time differential, as described herein below). Processor 111 repeats the generation of a new passcode in response to a predefined time period value having expired, such as every 5 minutes, 30 minutes, 1 hour, 12 hours or any other time value. User device 120 is synchronized and therefore also generates new passcode at the same times); and
the non-transitory computer executable instructions stored at the access control device further comprise instructions that, when executed, cause the access control device (Klapman: FIG. 1 the access controller 110 of the data storage device (DSD) 100) to:
receive an input time-based code (Ho: [0044]-[0045], [0052], [0054]-[0055], [0068]-[0072], and FIG. 4-5: Upon receipt of the second factor authentication data by the electronic lock 210, the electronic lock, which is arranged in wireless communication with the application server, will transmit the second factor authentication data to the application server 160. At step 422, the application server 160 will validate the second factor authentication data with the second factor authentication data associated with the user and permission levels stored in the lock user database 161 and Klapman: [0048]-[0051], [0053]-[0055], [071]-[0075], [0088], and FIG. 1 the input passcode at input component 102: The DSD 100 receives a passcode from user 101 (either by manual input via the input components 102, or electronically), including at least the input passcode provided by user device 120. In this embodiment, as shown in step 406, the received passcode is the input passcode generated synchronously by the DSDMA 300 of the user device 120 with the generation of the unlock passcode by the access controller 110 of the DSD 100. FIG. 6 illustrates a flow diagram for an input passcode generation routine 600 performed by the DSDMA 300 and invoked by user 101. At step 602, the user 101 configures the application 300 to manage the DSD 100, thereby enabling the generation of input passcode values for the device 100);
generate a generated time-based code from the time-based code series instance using (i) a current clock value from the access control device clock and (ii) the time-based code generation schedule (Klapman: [0037], [0051]-[0052], [0072]-[0073], [0076], [0078]-[0079], and FIG. 4-5: Processor 111 receives a clocking signal from clock 112, which is processed to produce timestamp values representing instants in real-time. Processor 111 is configured to repeatedly and automatically generate a dynamically changing passcode (the “unlock passcode”), which is a time-varying code used for unlocking the data storage device 100, by processing the stored passcode generation key and reference time value. The reference time value is determined based on a time value obtained periodically from the clock 112 (i.e., to calculate a time differential, as described herein below). Processor 111 repeats the generation of a new passcode in response to a predefined time period value having expired, such as every 5 minutes, 30 minutes, 1 hour, 12 hours or any other time value. User device 120 is synchronized and therefore also generates new passcode at the same times);
compare the input time-based code with the generated time-based code (Klapman: Abstract, [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: The access controller 110 is configured to provide access to the user content data 109 in response to a match between the (first) received passcode entered into, or otherwise electronically provided to, the DSD 100 and the (second) passcode generated by the DSD 100, which are the input and unlock passcodes respectively in the described embodiments (i.e., as indicated in step 408). In some examples, a verification operation is performed by the access controller 110 to processes the unlock passcode and the input passcode. Processor 111 performs a comparison operation on the data representations of each code to check whether the input passcode matches with the unlock passcode);
determine that the input time-based code does not match the generated time-based code (Klapman: Abstract, [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: The access controller 110 is configured to provide access to the user content data 109 in response to a match between the (first) received passcode entered into, or otherwise electronically provided to, the DSD 100 and the (second) passcode generated by the DSD 100, which are the input and unlock passcodes respectively in the described embodiments (i.e., as indicated in step 408). In some examples, a verification operation is performed by the access controller 110 to processes the unlock passcode and the input passcode. Processor 111 performs a comparison operation on the data representations of each code to check whether the input passcode matches with the unlock passcode);
compare the input time-based code with a second generated time-based code generated from the second time-based code series instance (Klapman: Abstract, [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: The access controller 110 is configured to provide access to the user content data 109 in response to a match between the (first) received passcode entered into, or otherwise electronically provided to, the DSD 100 and the (second) passcode generated by the DSD 100, which are the input and unlock passcodes respectively in the described embodiments (i.e., as indicated in step 408). In some examples, a verification operation is performed by the access controller 110 to processes the unlock passcode and the input passcode. Processor 111 performs a comparison operation on the data representations of each code to check whether the input passcode matches with the unlock passcode) using (i) a current clock value from the second access control device clock and (ii) the second time-based code generation schedule (Klapman: [0037], [0051]-[0052], [0072]-[0073], [0076], [0078]-[0079], and FIG. 4-5: Processor 111 receives a clocking signal from clock 112, which is processed to produce timestamp values representing instants in real-time. Processor 111 is configured to repeatedly and automatically generate a dynamically changing passcode (the “unlock passcode”), which is a time-varying code used for unlocking the data storage device 100, by processing the stored passcode generation key and reference time value. The reference time value is determined based on a time value obtained periodically from the clock 112 (i.e., to calculate a time differential, as described herein below). Processor 111 repeats the generation of a new passcode in response to a predefined time period value having expired, such as every 5 minutes, 30 minutes, 1 hour, 12 hours or any other time value. User device 120 is synchronized and therefore also generates new passcode at the same times); and
based on the match between the second generated time-based code and the input time-based code, perform a second action (Ho: [0017], [0048], [0052], [0060]-[0071], [0073]-[0078], and FIG. 4-5 the electronic lock 210: If the second factor authentication data received from the user matches the second factor authentication data stored on the lock user database 161, the application server 160 will send a positive signal to the electronic lock which will cause the electronic lock to release its locking mechanism at step 426 to allow entry to the entry point and Klapman: Abstract, [0005], [0054], [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: In response to the first passcode matching with a second passcode, the second passcode being generated by the access controller 110 and including at least the unlock passcode, the access controller 110 provides access to the user content data 109 via the data port 106. That is, in this case the user providing the input passcode is considered as an authorized user of the DSD 100 ).
As to claim 20, Ho, Klapman, and Kamkar discloses the limitations of claim 19 further comprising the access control system of claim 19, wherein performing a second action comprises granting access to a resource (Ho: [0017], [0048], [0052], [0060]-[0071], [0073]-[0078], and FIG. 4-5 the electronic lock 210: If the second factor authentication data received from the user matches the second factor authentication data stored on the lock user database 161, the application server 160 will send a positive signal to the electronic lock which will cause the electronic lock to release its locking mechanism at step 426 to allow entry to the entry point ).
As to claim 22, Ho, Klapman, and Kamkar discloses the limitations of claim 19 further comprising the access control system of claim 19, wherein the second time-based code series instance is associated with a second user (Ho: Abstract, [0010], [0046], [0052]-[0055], [0068]-[0071], and FIG. 4-5: When the access right owner or the access right grantee is provisioned for right of entry and exit via the associated electronic lock identified by an associated lock ID, the administrator will capture the personal details of the access right owner and the access right grantees, which may include names, addresses, contact numbers, user device numbers, user device serial number or identification numbers, and/or biometric signatures that can be used for authentication of the first factor authentication or second factor authentication).
As to claim 23, Ho, Klapman, and Kamkar disclose the limitations of claim 15 further comprising the access control system of claim 15, wherein:
the code-check algorithm comprises a configuration code instance (Ho: [0044]-[0045], [0052], [0068]-[0071], and FIG. 4-5 and Klapman: [0037], [0051], [0072]-[0073], [0076], [0078]-[0079], and FIG. 4-5);
the configuration code instance comprises:
a configuration code known by the access control device (Ho: [0017], [0048], [0052], [0060]-[0071], [0073]-[0078], and FIG. 4-5 the electronic lock 210: If the second factor authentication data received from the user matches the second factor authentication data stored on the lock user database 161, the application server 160 will send a positive signal to the electronic lock which will cause the electronic lock to release its locking mechanism at step 426 to allow entry to the entry point and Klapman: Abstract, [0023]: wherein the input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the data storage device; and provide access to the user content data via a data port of the data storage device in response to the first passcode matching with a second passcode generated by the data storage device, wherein the second passcode includes at least the unlock passcode, [0034]: the second passcode generated by the DSD 100 includes only the dynamically changing unlock passcode that is matched to a corresponding “input” passcode constituting the received first passcode. The input passcode is generated externally to the data storage device and synchronously with the generation of the unlock passcode by the access controller, [0037]-[0038]: the user device 120 determines the input passcode, to be entered by the user into the DSD, by retrieving the input passcode or a seed value to generate the input passcode from a remote location, such as a passcode server, [0075]);
non-transitory computer executable instructions that are stored at the access control device and that, when executed, cause the access control device (Ho: [0037], [0048], [0079]-[0080], and FIG. 5) to:
receive an input code ([0044]-[0045], [0052], [0054]-[0055], [0068]-[0072], and FIG. 4-5: Upon receipt of the second factor authentication data by the electronic lock 210, the electronic lock, which is arranged in wireless communication with the application server, will transmit the second factor authentication data to the application server 160. At step 422, the application server 160 will validate the second factor authentication data with the second factor authentication data associated with the user and permission levels stored in the lock user database 161 and Klapman: [0048]-[0051], [0053]-[0055], [071]-[0075], [0088], and FIG. 1 the input passcode at input component 102: The DSD 100 receives a passcode from user 101 (either by manual input via the input components 102, or electronically), including at least the input passcode provided by user device 120. In this embodiment, as shown in step 406, the received passcode is the input passcode generated synchronously by the DSDMA 300 of the user device 120 with the generation of the unlock passcode by the access controller 110 of the DSD 100. FIG. 6 illustrates a flow diagram for an input passcode generation routine 600 performed by the DSDMA 300 and invoked by user 101. At step 602, the user 101 configures the application 300 to manage the DSD 100, thereby enabling the generation of input passcode values for the device 100);
compare the input code to the configuration code (Klapman: Abstract, [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: The access controller 110 is configured to provide access to the user content data 109 in response to a match between the (first) received passcode entered into, or otherwise electronically provided to, the DSD 100 and the (second) passcode generated by the DSD 100, which are the input and unlock passcodes respectively in the described embodiments (i.e., as indicated in step 408). In some examples, a verification operation is performed by the access controller 110 to processes the unlock passcode and the input passcode. Processor 111 performs a comparison operation on the data representations of each code to check whether the input passcode matches with the unlock passcode);
based on a determination that the input code matches the configuration code, perform a configuration action (Ho: [0017], [0048], [0052], [0060]-[0071], [0073]-[0078], and FIG. 4-5 the electronic lock 210: If the second factor authentication data received from the user matches the second factor authentication data stored on the lock user database 161, the application server 160 will send a positive signal to the electronic lock which will cause the electronic lock to release its locking mechanism at step 426 to allow entry to the entry point and Klapman: Abstract, [0005], [0054], [0125]-[0126], [0128], [0131], FIG. 1, and FIG. 4-5: In response to the first passcode matching with a second passcode, the second passcode being generated by the access controller 110 and including at least the unlock passcode, the access controller 110 provides access to the user content data 109 via the data port 106. That is, in this case the user providing the input passcode is considered as an authorized user of the DSD 100).
As to claim 24, Ho, Klapman, and Kamkar discloses the limitations of claim 23 further comprising the access control system of claim 23, wherein the configuration action comprises
at least one from the following list: modify configuration information; modify shared seed code information;
modify the time-based code generation schedule; perform clock synchronization;
grant privileged access (Ho: [0066], [0071], and FIG. 4: The application server 160 will also check the permission levels associated with the user, for example, available date and times, unavailable dates and times, or other limits. The limits may be based on the specific roles and permission levels registered by the administrator or the access right owner on the role management module 110, user management module 112, lock management module 114 and grant access module 116. At step 424, if the second factor authentication data received by the user does not match the second factor authentication data generated by the server, the application server 160 may return an error message in response to the failed authentication, and the user will be requested to input the second factor authentication data again); and
enter an administrative mode.
Claims 21, 27, and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Ho et al. (Ho – US 2021/0319639 A1) in view of Klapman et al. (Klapman – US 2022/0414205 A1) and Kamkar et al. (Kamkar – US 2021/0360403 A1) and further in view of Davis et al. (Davis – US 2014/0068247 A1).
As to claim 21, Ho, Klapman, and Kamkar disclose the limitations of claim 19 except for the claimed limitations of the access control system of claim 19, wherein performing a second action comprises granting access to a resource for a second period of time that is different from the first period of time.
However, it has been known in the art of security locks to implement wherein performing a second action comprises granting access to a resource for a second period of time that is different from the first period of time, as suggested by Davis, which discloses wherein performing a second action comprises granting access to a resource for a second period of time that is different from the first period of time (Davis: Abstract, [0018], [0024], [0042]-[0048], [0053]-[0054], FIG. 2-3 and FIG. 7: The security locking device may generate multiple security access codes and the control server may generate multiple candidate access codes. A user who desires to open a security locking device may be assigned a candidate access code that is valid for a specific period of time. When the candidate access code is provided to the security access device by the user or delivery agent during a time period when the candidate access code is valid, then the security locking device may open… the security locking device may generate a new code for the 1 hour time interval 10 every hour at a specific time hourly epoch defined in advance. A time the new security access code may be generated is, for instance, on the hour every hour or at fifteen minutes after the hour, every hour. Similarly, for a 24 hour code 320, a new code may be generated each day at 12:00 midnight or at another selected time during each 24 hour period).
Therefore, in view of teachings by Ho, Klapman, Kamkar, and Davis, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the security system of Ho, Klapman, and Kamkar to include wherein performing a second action comprises granting access to a resource for a second period of time that is different from the first period of time, as suggested by Davis. The motivation for this is to selectively control a security access device based on setting periods.
As to claim 27, Ho, Klapman, and Kamkar disclose the limitations of claim 24 except for the claimed limitations of the access control system of claim 24, wherein the configuration action comprises performing clock synchronization.
However, it has been known in the art of security locks to implement wherein the configuration action comprises performing clock synchronization, as suggested by Davis, which discloses wherein the configuration action comprises performing clock synchronization (Davis: Abstract, [0041], [0048]-[0051], and FIG. 2-3: the synchronized clock signals may allow the security access code and the candidate access code to be compared during the time the generated security access codes are valid. If the candidate access code has been submitted during a valid time interval and the candidate access code matches with the security access code, then a successful candidate access code has been submitted and the locking hardware may be opened).
Therefore, in view of teachings by Ho, Klapman, Kamkar, and Davis, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the security system of Ho, Klapman, and Kamkar to include wherein the configuration action comprises performing clock synchronization, as suggested by Davis. The motivation for this is to selectively control a security access device based on setting periods using a clock synchronization between a server and a security locking device.
As to claim 29, Ho, Klapman, and Kamkar disclose the limitations of claim 24 except for the claimed limitations of the access control system of claim 24, wherein the configuration action comprises changing the length of time for which access to a resource will be granted upon receipt of a matching input time-based code.
However, it has been known in the art of security locks to implement wherein the configuration action comprises changing the length of time for which access to a resource will be granted upon receipt of a matching input time-based code, as suggested by Davis, which discloses wherein the configuration action comprises changing the length of time for which access to a resource will be granted upon receipt of a matching input time-based code (Davis: Abstract, [0018], [0024], [0042]-[0048], [0053]-[0054], FIG. 2-3 and FIG. 7: The security access codes may be valid from a predefined start time and for a predefined time interval. For example, the security locking device 620 may include a locking device (e.g., a deadbolt lock) on a door and the lock may have a doorknob and a keyhole for a mechanical key to also open the locking device).
Therefore, in view of teachings by Ho, Klapman, Kamkar, and Davis, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the security system of Ho, Klapman, and Kamkar to include wherein the configuration action comprises changing the length of time for which access to a resource will be granted upon receipt of a matching input time-based code, as suggested by Davis. The motivation for this is to selectively control a security access device based on setting periods.
Claims 25-26 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Ho et al. (Ho – US 2021/0319639 A1) in view of Klapman et al. (Klapman – US 2022/0414205 A1) and Kamkar et al. (Kamkar – US 2021/0360403 A1) and further in view of MacRumors (MacRumors – How to Create a More Secure Passcode on Your iPhone or iPad).
As to claim 25, Ho, Klapman, and Kamkar disclose the limitations of claim 24 except for the claimed limitations of the access control system of claim 24, wherein the configuration action comprises changing the length of the configuration code.
However, it has been known in the art of security to implement wherein the configuration action comprises changing the length of the configuration code, as suggested by MacRumors, which discloses wherein the configuration action comprises changing the length of the configuration code (MacRumors: For a long time, passcodes were four-digit numeric codes by default, but with iOS 9, Apple began using a six-digit passcode as the default option. Six-digit passcodes offer 1 million possible combinations instead of 10,000, making a passcode harder to crack… the iOS operating system offers an option to make your passcode even more secure through the use of an alphanumeric passcodes or custom length numeric passcodes. Alphanumeric passcodes contain letters and numbers. Both alphanumeric and custom numeric passcodes can be much longer than four or six digits).
Therefore, in view of teachings by Ho, Klapman, Kamkar, and MacRumors it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the security system of Ho, Klapman, and Kamkar, to include wherein the configuration action comprises changing the length of the configuration code, as suggested by MacRumors. The motivation for this is to facilitate users to customize their passcode for security purposes.
As to claim 26, Ho, Klapman, and Kamkar disclose the limitations of claim 24 except for the claimed limitations of the access control system of claim 24, wherein the configuration action comprises changing the configuration code.
However, it has been known in the art of security to implement wherein the configuration action comprises changing the configuration code, as suggested by MacRumors, which discloses wherein the configuration action comprises changing the configuration code (MacRumors: For a long time, passcodes were four-digit numeric codes by default, but with iOS 9, Apple began using a six-digit passcode as the default option. Six-digit passcodes offer 1 million possible combinations instead of 10,000, making a passcode harder to crack… the iOS operating system offers an option to make your passcode even more secure through the use of an alphanumeric passcodes or custom length numeric passcodes. Alphanumeric passcodes contain letters and numbers. Both alphanumeric and custom numeric passcodes can be much longer than four or six digits).
Therefore, in view of teachings by Ho, Klapman, Kamkar, and MacRumors, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the security system of Ho, Klapman, and Kamkar, to include wherein the configuration action comprises changing the configuration code, as suggested by MacRumors. The motivation for this is to facilitate users to customize their passcode for security purposes.
As to claim 28, Ho, Klapman, and Kamkar disclose the limitations of claim 24 except for the claimed limitations of the access control system of claim 24, wherein the configuration action comprises changing the length of the input time-based code.
However, it has been known in the art of security to implement wherein the configuration action comprises changing the length of the input time-based code, as suggested by MacRumors, which discloses wherein the configuration action comprises changing the length of the input time-based code (MacRumors: For a long time, passcodes were four-digit numeric codes by default, but with iOS 9, Apple began using a six-digit passcode as the default option. Six-digit passcodes offer 1 million possible combinations instead of 10,000, making a passcode harder to crack… the iOS operating system offers an option to make your passcode even more secure through the use of an alphanumeric passcodes or custom length numeric passcodes. Alphanumeric passcodes contain letters and numbers. Both alphanumeric and custom numeric passcodes can be much longer than four or six digits).
Therefore, in view of teachings by Ho, Klapman, Kamkar, and MacRumors it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the security system of Ho, Klapman, and Kamkar, to include wherein the configuration action comprises changing the length of the input time-based code, as suggested by MacRumors. The motivation for this is to facilitate users to customize their passcode for security purposes.
Citation of Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Kim et al., US 11,643,853 B2, discloses vehicle and controlling method thereof.
Wu et al., US 2018/0262891 A1, discloses electronic access controls systems and methods using near-field communications, mobile devices, and cloud computing.
Yeap et al., US 2006/0123463 A1, discloses security access device and method.
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 extension fee 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 QUANG PHAM whose telephone number is (571)-270-3668. The examiner can normally be reached 09:00 AM - 05:00 PM.
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, QUAN-ZHEN WANG can be reached at (571)-272-3114. 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.
/QUANG PHAM/Primary Examiner, Art Unit 2685
