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 .
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 15-29 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 pre-AIA the applicant regards as the invention.
Claim 15 lacks antecedent basis for “the time-based code series instance” in the limitations of “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.”
Claim 15 recites the limitations of “wherein each time period is associated with a clock begin value and a clock end value (which could be the same)” which is not clear whether the limitations of (which could be the same) refers to the time period, the clock begin value or the clock end value, etc.
Claims 16-29 are rejected because of being dependent on a rejected claim 15.
Claim 19 further lacks antecedent basis for “the time-based code series instance” in the limitations of “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.”
Claim 19 recites the limitations of “wherein each time period is associated with a clock begin value and a clock end value (which could be the same)” which is further not clear whether the limitations of (which could be the same) refers to the time period, the clock begin value or the clock end value, etc.
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),
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);
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 (which 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 (which 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 (which 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 ([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 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:
Chin et al., US 12,489,746 B2, discloses app free authentication across channels.
Bedi et al., US 12,481,994 B2, discloses integration for performing actions without additional authorization requests.
Kumar et al., US 12,475,459 B1, discloses authorization flow management system.
Conclusion
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