DETAILED ACTION
This action is responsive to the Applicant’s amendment filed on October 6, 2025 and the Request for Continued Examination filed on November 5, 2025. As set forth in the response, claims 1, 9, 10, 11, 20, and 21 are amended. Claims 3 and 14 is canceled. Claims 1-2, 4-13, and 15-21 are pending.
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on October 6, 2025 has been entered.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Reissue Applications
For reissue applications filed before September 16, 2012, all references to 35 U.S.C. 251 and 37 CFR 1.172, 1.175, and 3.73 are to the law and rules in effect on September 15, 2012. Where specifically designated, these are “pre-AIA ” provisions.
For reissue applications filed on or after September 16, 2012, all references to 35 U.S.C. 251 and 37 CFR 1.172, 1.175, and 3.73 are to the current provisions.
Applicant is reminded of the continuing obligation under 37 CFR 1.178(b), to timely apprise the Office of any prior or concurrent proceed-ing in which Patent No. 11,270,536 is or was involved. These proceedings would include interferences, reissues, reexaminations, and litigation.
Applicant is further reminded of the continuing obligation under 37 CFR 1.56, to timely apprise the Office of any information which is mate-rial to patentability of the claims under consideration in this reissue appli-cation.
These obligations rest with each individual associated with the filing and prosecution of this application for reissue. See also MPEP §§ 1404, 1442.01 and 1442.04.
Response to Arguments
112(a) Rejection
As set forth in the Advisory Action, the Applicant has resolved the 112(a) issue based on the removal of the limitation directed to “the user authentication information is used by the access controller to identify the specific electronic lock to emit the alert”.
103 Rejections
The Applicant states that each independent claim is amended to recite that the user device will acquire the lock identifier associated with and provided in the vicinity of the specific electronic lock. In addition, the Applicant states that each independent claim is also amended to recite that the specific electronic lock is triggered to emit a lock identifier and the alert or alert signal.
The Applicant states that the rejection of original claims 3 and 14 appears to have relied on a combination Huber with Gullicksen and Robinson. The Applicant states that Huber describes techniques to obtain a lock identifier from a QR code to identifier a specific lock device as its first step of identifying which lock to attempt to unlock, without involving user authentication information, and without any type of a control message. The Applicant explains that if Gullicksen has already identified the lock, there is no need to emit a lock identifier or acquire the emitted lock identifier. The Applicant also states that the “lock identifier” in Huber is not emitted from the lock but is read as a result of visually reading a machine-readable optical code and the lock identifier must be acquired before a server even knows which lock device will be unlocked. The Applicant has noted that the teachings directed to Bluetooth, NFC, light, or audio communications refer to Bluetooth paring and that this is not the same as a broadcast for emitting a lock identifier as claimed.
The Examiner acknowledges that Huber discloses that in one embodiment a lock identifier is a machine-readable optical identifier. In addition, the Examiner finds that Huber in paragraph [0075] discloses that lock identifiers may be communicated wirelessly between the electronic lock and the mobile device via e.g. NFC. Therefore, the Examiner finds that the Huber does disclose of emitting a lock identifier from the lock.
As to the Applicant’s further comment that Huber does not teach causing the access controller to trigger the specific electronic lock to emit a lock identifier and the alert or alert signal, and acquiring this lock identifier associated with and provided in the vicinity of the specific electronic lock as claimed, the Examiner finds that Gullicksen discloses of sending an unlock message as well as teaching the identification of a specific lock which is based on a set of criteria. As disclosed by Gullicksen, its method may cause multiple locks to be identified as set forth in paragraphs [0055-0058]. Since the goal of Gullicksen is to unlock a specific lock, the Examiner finds that it would have been obvious to a person of ordinary skill in the art to provide a specific lock identifier since Gullicksen already discloses of the importance of the identification of a lock and proposes several different methods for identifying the lock.
The teachings of Huber discloses of an alternative method to acquire a lock identifier as compared to Gullicksen and since Gullicksen discloses of using different methods for identifying a specific lock, a person of ordinary skill in the art would have considered alternative methods for identification including sending a specific lock identifier.
Therefore, the Examiner continues to maintain that it would have been obvious to transmit the identification of a lock in the system of Gullicksen.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 2, 4-13, and 15-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, because the specification, while being enabling for broadcasting a lock identifier, does not reasonably provide enablement for emit[ing] a lock identifier. The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the invention commensurate in scope with these claims.
The Examiner finds that the ‘536 patent discloses throughout its disclosure that the lock identifier “may be broadcast from the electronic lock” or “may be broadcast using a Bluetooth beacon”. See e.g. col. 4, lines 28-30. The Examiner finds that the ’536 patent also discloses that the electronic lock can emit a signal with respect to the alert signal. See e.g. col. 2, lines 29-30. The Examiner finds that the ‘536 patent never specifically uses the term “emit” when describing broadcast and thus the specification does not disclose the broader genus of “emit” in view of the narrower species of “broadcast” as it pertains to the lock identifier. The Examiner notes that “emit a lock identifier” is set forth in claims 1, 9, 11, 20 and 21. The dependent claims under each corresponding base claim is likewise rejected for being based on a rejected claim.
Claims 6-8 and 17-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “the control message causing the access controller to trigger the specific electronic lock to emit a lock identifier and the alert signal, in order for the user to identify the specific electronic lock as a correct electronic lock”.
As set forth on col. 2, lines 8 – 21 of the underlying ‘536 patent, the lock identifier is described as being broadcast from the electronic device or broadcast using a Bluetooth beacon. In addition, the lock identifier is alternatively described as being “acquired” from an optical, machine readable code or from a two dimensional bar code”.
As to claims 6-8 and 17-19, the ‘536 patent does not disclose both emitting/broadcasting the lock identifier in the same embodiment as acquiring the lock identifier optically or based on a digital image. Rather the ‘536 patent discloses the broadcast and acquiring to be performed in the alternative.
Claims 6-8 and 17-19 are rejected under 35 U.S.C. 251 as being based upon new matter added to the patent for which reissue is sought. The added material which is not supported by the prior patent is as follows is set forth immediately above.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 4, 6-8, 15 and 17-19 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 1 recites “the specific electronic lock to emit a lock identifier”. Dependent claim 4 recites “wherein the lock identifier is broadcast from the specific electronic lock”.
Both claim 1 and claim 4 recite a specific electronic lock and a lock identifier. The only difference is claim 1 recites “emit” and claim 4 recites “broadcast”. The Examiner finds that it is not clear how “broadcast” further narrows “emit” in accordance with 112(d).
The Examiner notes that this same issue applies to dependent claim 15 (dependent on claim 11).
With respect to claim 6-8, claim 6 recites “wherein the lock identifier is acquired from an optical, machine-readable code” and claim 8 recites “wherein the lock identifier is acquired based on a digital image”.
The Examiner notes that claim 1 recites that the specific electronic lock emits a lock identifier. The Examiner finds tht is not clear how a lock identifier acquired from an optical machine-readable code” or acquired based on a digital image further narrows emitting the lock identifier from the specific electronic lock.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 2, 4-13, and 15-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gullicksen US Pub. 2018/0114385 in view of Robinson US Patent Pub. 2017/0018130 and further in view of Huber et al. US Patent Pub. 2014/0375422.
Regarding claim 1:
A method for requesting remote unlocking of an electronic lock controlling access to a physical space, the method being performed in a user device and comprising:
Gullicksen is directed to a method for enabling a remote key device (e.g. a smart phone, tablet computer or other computing device (paragraph [0009]) to be used with any number of lockable devices in a physical space. See paragraph [0008]. As set forth in paragraphs [0005-0007], electronic locks are used for controlling access to homes, offices, rooms, and safes (physical space 110). See Figure 1.
receiving user input from a user to transmit a control message to an access controller to trigger an alert signal by a specific electronic lock,
Gullicksen discloses that a user, using the key device 120 sends a first request 124 (control message – e.g. wifi packet) to the server apparatus 150 (access controller) which will be used to trigger an alert by a specific electronic lock. See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the particular lock. See also paragraphs [0089-0090]
wherein the access controller is located remotely from the specific electronic lock;
Gullicksen discloses that the Server Apparatus 150 is located remotely from the specific electronic lock (any of 130a, 130b, 130c, etc). See Figure 1. See also paragraphs [0046-007]
sending the control message to the access controller,
Gullicksen discloses that a user, using the key device 120 a first request 124 (control message) to the server apparatus 150 (access controller) is sent. See paragraphs [0053, 0061 and 0089].
the control message comprising user authentication information,
The Examiner notes that Gullicksen discloses different methods for user authentication. In one method, the first request is performed in response to authenticating the user using e.g., a biometric sensor on the key device (see paragraphs [0016] and [0061]). In another method, after using the biometric sensor, the key device sends a user identifier to the server apparatus. See paragraph [0086] which discloses that pressing the Select button causes a user identifier to be sent to the server. In other examples, the key device can login to the system. See also paragraphs [0017 and 0087]. See also paragraph [0069] which discloses storing a list of authorized users.
To the extent it is considered that the control message doesn’t comprise user authentication information, the Examiner finds that in view of the above teachings it would have been obvious to a person of ordinary skill in the art to transmit user authentication information to the server for authenticating the user along with the control message.
Nonetheless, Robinson discloses in paragraph [0065] a permission database which is a repository of information to “who may go where”. The verification manager is used to verify a particular user against the permission database to determine whether or not they are an authorized user. In one example, Robinson explains that a user can approach the front gate (as is determined by the location manager) and user information may be utilized by the verification manager to authorize them according the rules stored in the permission database and the gate may be unlocked. Thus, user information (authentication information) is used by the verification manager to authorized them according to the permission database. This permission database includes the specific electronic lock that the user is authorize to control. In another example the same user can approach a fitness club outside normal ours and the verification operation may instead deny access and the door will remain locked. Robinson uses a location manager to determine the location of the user and when a user is near an entry point. See paragraph [0064]. As explained in paragraph [0082], a request along with an associated identifier is sent in order to access the locked area. See also paragraph [0012-0013] which shows that the user can make an access request and the remote server receives the request from the user (paragraph [0053]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to send a authentication information to the server along with the first request. As explained above, Gullicksen already discloses of multiple methods to authenticate a user including sending ID information to the server. Thus, for the purpose of unlocking a lock, it would have been obvious to a person of ordinary skill in the art to transmit identification information along with the request in order to authenticate the user to ensure that they are authorized to have access to the physical space. As set forth above, both Gullicksen and Robinson disclose the importance of user authentication before being granted access to the system. Gullicksen discloses of multiple methods of sending user identification information as well as storing a list of authorized users in the server (see paragraph [0069]) in order to determine who can operate a lock. Since the server stores this information, it would have been predictable to a person of ordinary skill in the art to have the server receive user identification information along with the first request so that further verification of the user can be determined by the server in order to determine whether the user is in the list of authorized users for the electronic lock. Robinson discloses that each user would be identified in a permission database along with information detailing which “locks” (access points) that user can access. Thus, sending authorization information would have obvious to a person of ordinary skill in the art since it is used to verify that the correct person is authorized to access the controlled area.
the control message causing the access controller to trigger the specific electronic lock to emit a lock identifier and the alert signal, in order for the user to identify the specific electronic lock as a correct electronic lock, wherein the alert signal is a light signal; and
See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
Gullicksen states “a particular lock” is identified based on a set of criteria and it directs the identified lock to issue a human-detectable indication. See also paragraph [0090] which discloses of selecting the top-ranking lock as the identified lock.
As set forth above, the Examiner finds that Gullicksen selects a lock using a ‘set of criteria’ which then causes the lock to issue an alert. Therefore a user can “confirm the identification of a lock 1340a via user input to the key device 120.” (See paragraph [0053]) Thus, Gullicksen suggests the identification of the lock prior to sending a second request to the server after the emitting the triggering of an alert signal or a sound.
The Examiner finds that Gullicksen does not specifically also cause the lock to emit a lock identifier; however, since Gullicksen discloses of a need to specifically identify a lock after the control message triggers the lock to emit an alert signal, then it would have been obvious to a person of ordinary skill in the art to also include a specific identifier of the lock since Gullicksen discloses “confirmation” for the lock.
Nonetheless, the Examiner notes that Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to also emit a lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock. As explained by Gullicksen in paragraph [0053], this may serve as confirmation that the lock is the correct lock. (i.e. lock 130a).
acquiring the lock identifier associated with and provided in the vicinity of the specific electronic lock; and
As explained in paragraph [0042],Gullicksen discloses of identifying a controllable lock whose location is based relative to the key device. As further stated in paragraph [0053] a locks is identified “based on a set of criteria” as well as based on performing a discovery operation as explained in paragraph [0054]. As further set forth in paragraph [0055], a lock can be identified based on having the key device point towards the lock. In addition, it is disclosed that the key device may sending this information to the server via a packet. See also paragraph [0065].
The Examiner notes however, that although the user device may point towards the lock, Gullicksen does not specifically disclose of acquiring a lock identifier from the vicinity of the specific electronic lock” and where the unlock message further comprises the lock identifier.
Nonetheless, as explained above, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (eg. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to acquiring a lock identifier from the vicinity of the specific electronic lock and to have the unlock message further comprise the lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used included acquiring an identifier from the vicinity of the lock itself using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock.
sending an unlock message to the access controller comprising the user authentication information and the lock identifier after receiving an unlock user input from the user to unlock the specific electronic lock, in order to unlock the specific electronic lock.
As explained in paragraph [0053], a user can send a second request (unlock message) to the server apparatus which then proceeds to direct the lock 130a (specific electronic lock) to unlock. The information includes a predetermined code to the lock for unlocking. As explained above, it would have been obvious to a person of ordinary skill in the art to send authentication information from the user device to the server. As explained in paragraph [0069], the codes for operating the lock as well as a list of authorized users are stored in the vault appliance and each lock has established settings and limitations. See also paragraph [0019]
The Examiner notes that as disclosed by Huber, it would have been obvious to emit a lock identifier to the device 120 of Gullicksen and furthermore, it would have been obvious to transmit that identifier to the server since Gullicksen already discloses of sending a second request back to the server which will serve as a confirmation that the lock is the correct lock.
Regarding claim 2:
The method according to claim 1, wherein the alert signal is transmitted from the specific electronic lock.
See paragraph [0053], which discloses that in response to the first request, the lock 130a (specific lock in which the user desires to open) would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
Regarding claim 4:
The method according to claim 1, wherein the lock identifier is broadcast from the specific electronic lock.
As set forth above in claim 1, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (eg. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142].
Regarding claim 5:
The method according to claim 4, wherein the lock identifier is broadcast using a Bluetooth beacon.
As set forth above in claim 1, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142].
Regarding claim 6:
The method according to claim 1, wherein the lock identifier is acquired from an optical, machine-readable code.
As set forth above in claim 1, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As set forth paragraphs [0052 and 0058] and in Fig. 1 and 7 a QR code is used for the lock identifier.
Regarding claim 7:
The method according to claim 6, wherein the lock identifier is acquired from a two-dimensional bar code.
As set forth above in claim 1, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As set forth paragraphs [0052 and 0058] and in Fig. 1 and 7 a QR code is used for the lock identifier.
Regarding claim 8:
The method according to claim 1, wherein the lock identifier is acquired based on a digital image.
As set forth above in claim 1, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As set forth paragraphs [0052 and 0058] and in Fig. 1 and 7 a QR code is used for the lock identifier.
Regarding claim 9:
A user device for requesting remote unlocking of a physical space controlled by an electronic lock, the user device comprising:
Gullicksen is directed to a method for enabling a remote key device (e.g. a smart phone, tablet computer or other computing device (paragraph [0009]) to be used with any number of lockable devices in a physical space. See paragraph [0008]. As set forth in paragraphs [0005-0007], electronic locks are used for controlling access to homes, offices, rooms, and safes (physical space 110). See Figure 1.
a processor; and a memory storing instructions that, when executed by the processor cause the user device to:
See paragraph [0027] which discloses that the key device (user device) includes control circuitry including a set of processor and memory.
receive user input from a user to transmit a control message to an access controller to trigger an alert signal by a specific electronic lock,
Gullicksen discloses that a user, using the key device 120 sends a first request 124 (control message) to the server apparatus 150 (access controller) which will be used to trigger an alert by a specific electronic lock. See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the particular lock. See also paragraphs [0089-0090]
wherein the access controller is located remotely from the specific electronic lock,
Gullicksen discloses that the Server Apparatus 150 is located remotely from the specific electronic lock (any of 130a, 130b, 130c, etc). See Figure 1. See also paragraphs [0046-0007]
wherein the alert signal is a light signal;
See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
send the control message to the access controller,
Gullicksen discloses that a user, using the key device 120 a first request 124 (control message) to the server apparatus 150 (access controller) is sent. See paragraphs [0053, 0061 and 0089].
the control message comprising user authentication information,
The Examiner notes that Gullicksen discloses different methods for user authentication. In one method, the first request is performed in response to authenticating the user using e.g., a biometric sensor on the key device (see paragraphs [0016] and [0061]). In another method, after using the biometric sensor, the key device sends a user identifier to the server apparatus. See paragraph [0086] which discloses that pressing the Select button causes a user identifier to be sent to the server. In other examples, the key device can login to the system. See also paragraphs [0017 and 0087]. See also paragraph [0069] which discloses storing a list of authorized users.
To the extent it is considered that the control message doesn’t comprise user authentication information, the Examiner finds that in view of the above teachings it would have been obvious to a person of ordinary skill in the art to transmit user authentication information to the server for authenticating the user along with the control message.
Nonetheless, Robinson discloses in paragraph [0065] a permission database which is a repository of information to “who may go where”. The verification manager is used to verify a particular user against the permission database to determine whether or not they are an authorized user. In one example, Robinson explains that a user can approach the front gate (as is determined by the location manager) and user information may be utilized by the verification manager to authorize them according the rules stored in the permission database and the gate may be unlocked. Thus, user information (authentication information) is used by the verification manager to authorized them according to the permission database. This permission database includes the specific electronic lock that the user is authorize to control. In another example the same user can approach a fitness club outside normal ours and the verification operation may instead deny access and the door will remain locked. Robinson uses a location manager to determine the location of the user and when a user is near an entry point. See paragraph [0064]. As explained in paragraph [0082], a request along with an associated identifier is sent in order to access the locked area. See also paragraph [0012-0013] which shows that the user can make an access request and the remote server receives the request from the user (paragraph [0053]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to send a authentication information to the server along with the first request. As explained above, Gullicksen already discloses of multiple methods to authenticate a user including sending ID information to the server. Thus, for the purpose of unlocking a lock, it would have been obvious to a person of ordinary skill in the art to transmit identification information along with the request in order to authenticate the user to ensure that they are authorized to have access to the physical space. As set forth above, both Gullicksen and Robinson disclose the importance of user authentication before being granted access to the system. Gullicksen discloses of multiple methods of sending user identification information as well as storing a list of authorized users in the server (see paragraph [0069]) in order to determine who can operate a lock. Since the server stores this information, it would have been predictable to a person of ordinary skill in the art to have the server receive user identification information along with the first request so that further verification of the user can be determined by the server in order to determine whether the user is in the list of authorized users for the electronic lock. Robinson discloses that each user would be identified in a permission database along with information detailing which “locks” (access points) that user can access. Thus, sending authorization information would have obvious to a person of ordinary skill in the art since it is used to verify that the correct person is authorized to access the controlled area.
the control message causing the access controller to trigger the specific electronic lock to emit a lock identifier and the alert signal, in order for the user to identify the specific electronic lock as a correct electronic lock; and
See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
Gullicksen states “a particular lock” is identified based on a set of criteria and it directs the identified lock to issue a human-detectable indication. See also paragraph [0090] which discloses of selecting the top-ranking lock as the identified lock.
As set forth above, the Examiner finds that Gullicksen selects a lock using a ‘set of criteria’ which then causes the lock to issue an alert. Therefore a user can “confirm the identification of a lock 1340a via user input to the key device 120.” (See paragraph [0053]) Thus, Gullicksen suggests the identification of the lock prior to sending a second request to the server after the emitting the triggering of an alert signal or a sound.
The Examiner finds that Gullicksen does not specifically also cause the lock to emit a lock identifier; however, since Gullicksen discloses of a need to specifically identify a lock after the control message triggers the lock to emit an alert signal, then it would have been obvious to also include a specific identifier of the lock since Gullicksen discloses “confirmation” for the lock.
Nonetheless, the Examiner notes that Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to also emit a lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock. As explained by Gullicksen in paragraph [0053], this may serve as confirmation that the lock is the correct lock. (i.e. lock 130a).
acquire the lock identifier associated with and provided in the vicinity of the specific electronic lock; and
As explained in paragraph [0042],Gullicksen discloses of identifying a controllable lock whose location is based relative to the key device. As further stated in paragraph [0053] a locks is identified “based on a set of criteria” as well as based on performing a discovery operation as explained in paragraph [0054]. As further set forth in paragraph [0055], a lock can be identified based on having the key device point towards the lock. In addition, it is disclosed that the key device may sending this information to the server via a packet. See also paragraph [0065].
The Examiner notes however, that although the user device may point towards the lock, Gullicksen does not specifically disclose of acquiring a lock identifier from the vicinity of the specific electronic lock” and where the unlock message further comprises the lock identifier.
Nonetheless, as explained above, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (eg. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to acquiring a lock identifier from the vicinity of the specific electronic lock and to have the unlock message further comprise the lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used included acquiring an identifier from the vicinity of the lock itself using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock.
send an unlock message to the access controller comprising the user authentication information and the lock identifier after receiving an unlock user input from the user to unlock the specific electronic lock, in order to unlock the specific electronic lock.
As explained in paragraph [0053], a user can send a second request (unlock message) to the server apparatus which then proceeds to direct the lock 130a (specific electronic lock) to unlock. The information includes a predetermined code to the lock for unlocking. As explained above, it would have been obvious to a person of ordinary skill in the art to send authentication information from the user device to the server. As explained in paragraph [0069], the codes for operating the lock as well as a list of authorized users are stored in the vault appliance and each lock has established settings and limitations. See also paragraph [0019]
The Examiner notes that as disclosed by Huber, it would have been obvious to emit a lock identifier to the device 120 of Gullicksen and furthermore, it would have been obvious to transmit that identifier to the server since Gullicksen already discloses of sending a second request back to the server which will serve as a confirmation that the lock is the correct lock.
Regarding claim 10:
A non-transitory computer-readable medium comprising a computer program stored thereon for requesting remote unlocking of a physical space controlled by an electronic lock, the computer program comprising computer program code which, when run on [an]a user device, causes the user device to:
Gullicksen is directed to a method for enabling a remote key device (e.g. a smart phone, tablet computer or other computing device (paragraph [0009]) to be used with any number of lockable devices in a physical space. See paragraph [0008]. As set forth in paragraphs [0005-0007], electronic locks are used for controlling access to homes, offices, rooms, and safes (physical space 110). See Figure 1.
In addition, Gullicksen discloses a computer program product with instructions which when executed on one or more computers or processor to perform the disclosed process or processes. See paragraph [0097]
receive user input from a user to transmit a control message to an access controller to trigger an alert signal by a specific electronic lock,
Gullicksen discloses that a user, using the key device 120 sends a first request 124 (control message) to the server apparatus 150 (access controller) which will be used to trigger an alert by a specific electronic lock. See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the particular lock. See also paragraphs [0089-0090]
wherein the access controller is located remotely from the specific electronic lock;
Gullicksen discloses that the Server Apparatus 150 is located remotely from the specific electronic lock (any of 130a, 130b, 130c, etc). See Figure 1. See also paragraphs [0046-007]
send the control message to the access controller,
Gullicksen discloses that a user, using the key device 120 a first request 124 (control message) to the server apparatus 150 (access controller) is sent. See paragraphs [0053, 0061 and 0089].
the control message comprising user authentication information,
The Examiner notes that Gullicksen discloses different methods for user authentication. In one method, the first request is performed in response to authenticating the user using e.g., a biometric sensor on the key device (see paragraphs [0016] and [0061]). In another method, after using the biometric sensor, the key device sends a user identifier to the server apparatus. See paragraph [0086] which discloses that pressing the Select button causes a user identifier to be sent to the server. In other examples, the key device can login to the system. See also paragraphs [0017 and 0087]. See also paragraph [0069] which discloses storing a list of authorized users.
To the extent it is considered that the control message doesn’t comprise user authentication information, the Examiner finds that in view of the above teachings it would have been obvious to a person of ordinary skill in the art to transmit user authentication information to the server for authenticating the user along with the control message.
Nonetheless, Robinson discloses in paragraph [0065] a permission database which is a repository of information to “who may go where”. The verification manager is used to verify a particular user against the permission database to determine whether or not they are an authorized user. In one example, Robinson explains that a user can approach the front gate (as is determined by the location manager) and user information may be utilized by the verification manager to authorize them according the rules stored in the permission database and the gate may be unlocked. Thus, user information (authentication information) is used by the verification manager to authorized them according to the permission database. This permission database includes the specific electronic lock that the user is authorize to control. In another example the same user can approach a fitness club outside normal ours and the verification operation may instead deny access and the door will remain locked. Robinson uses a location manager to determine the location of the user and when a user is near an entry point. See paragraph [0064]. As explained in paragraph [0082], a request along with an associated identifier is sent in order to access the locked area. See also paragraph [0012-0013] which shows that the user can make an access request and the remote server receives the request from the user (paragraph [0053]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to send a authentication information to the server along with the first request. As explained above, Gullicksen already discloses of multiple methods to authenticate a user including sending ID information to the server. Thus, for the purpose of unlocking a lock, it would have been obvious to a person of ordinary skill in the art to transmit identification information along with the request in order to authenticate the user to ensure that they are authorized to have access to the physical space. As set forth above, both Gullicksen and Robinson disclose the importance of user authentication before being granted access to the system. Gullicksen discloses of multiple methods of sending user identification information as well as storing a list of authorized users in the server (see paragraph [0069]) in order to determine who can operate a lock. Since the server stores this information, it would have been predictable to a person of ordinary skill in the art to have the server receive user identification information along with the first request so that further verification of the user can be determined by the server in order to determine whether the user is in the list of authorized users for the electronic lock. Robinson discloses that each user would be identified in a permission database along with information detailing which “locks” (access points) that user can access. Thus, sending authorization information would have obvious to a person of ordinary skill in the art since it is used to verify that the correct person is authorized to access the controlled area.
the control message causing the access controller to trigger the specific electronic lock to emit a lock identifier and the alert signal, in order for the user to identify the specific electronic lock as a correct electronic lock, wherein the alert signal is a light signal; and
See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
Gullicksen states “a particular lock” is identified based on a set of criteria and it directs the identified lock to issue a human-detectable indication. See also paragraph [0090] which discloses of selecting the top-ranking lock as the identified lock.
As set forth above, the Examiner finds that Gullicksen selects a lock using a ‘set of criteria’ which then causes the lock to issue an alert. Therefore a user can “confirm the identification of a lock 1340a via user input to the key device 120.” (See paragraph [0053]) Thus, Gullicksen suggests the identification of the lock prior to sending a second request to the server after the emitting the triggering of an alert signal or a sound.
The Examiner finds that Gullicksen does not specifically also cause the lock to emit a lock identifier; however, since Gullicksen discloses of a need to specifically identify a lock after the control message triggers the lock to emit an alert signal, then it would have been obvious to also include a specific identifier of the lock since Gullicksen discloses “confirmation” for the lock.
Nonetheless, the Examiner notes that Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to also emit a lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock. As explained by Gullicksen in paragraph [0053], this may serve as confirmation that the lock is the correct lock. (i.e. lock 130a).
acquire the lock identifier associated with and provided in the vicinity of the specific electronic lock; and
As explained in paragraph [0042],Gullicksen discloses of identifying a controllable lock whose location is based relative to the key device. As further stated in paragraph [0053] a locks is identified “based on a set of criteria” as well as based on performing a discovery operation as explained in paragraph [0054]. As further set forth in paragraph [0055], a lock can be identified based on having the key device point towards the lock. In addition, it is disclosed that the key device may sending this information to the server via a packet. See also paragraph [0065].
The Examiner notes however, that although the user device may point towards the lock, Gullicksen does not specifically disclose of acquiring a lock identifier from the vicinity of the specific electronic lock” and where the unlock message further comprises the lock identifier.
Nonetheless, as explained above, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (eg. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to acquiring a lock identifier from the vicinity of the specific electronic lock and to have the unlock message further comprise the lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used included acquiring an identifier from the vicinity of the lock itself using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock.
send an unlock message to the access controller comprising the user authentication information and the lock identifier after receiving an unlock user input from the user to unlock the specific electronic lock, in order to unlock the specific electronic lock.
As explained in paragraph [0053], a user can send a second request (unlock message) to the server apparatus which then proceeds to direct the lock 130a (specific electronic lock) to unlock. The information includes a predetermined code to the lock for unlocking. As explained above, it would have been obvious to a person of ordinary skill in the art to send authentication information from the user device to the server. As explained in paragraph [0069], the codes for operating the lock as well as a list of authorized users are stored in the vault appliance and each lock has established settings and limitations. See also paragraph [0019]
The Examiner notes that as disclosed by Huber, it would have been obvious to emit a lock identifier to the device 120 of Gullicksen and furthermore, it would have been obvious to transmit that identifier to the server since Gullicksen already discloses of sending a second request back to the server which will serve as a confirmation that the lock is the correct lock.
Regarding claim 11:
A method for requesting remote unlocking of an electronic lock controlling access to a physical space, the method being performed in a user device and comprising:
Gullicksen is directed to a method for enabling a remote key device (e.g. a smart phone, tablet computer or other computing device (paragraph [0009]) to be used with any number of lockable devices in a physical space. See paragraph [0008]. As set forth in paragraphs [0005-0007], electronic locks are used for controlling access to homes, offices, rooms, and safes (physical space 110). See Figure 1.
receiving user input from a user to transmit a control message to an access controller to trigger an alert by a specific electronic lock,
Gullicksen discloses that a user, using the key device 120 sends a first request 124 (control message) to the server apparatus 150 (access controller) which will be used to trigger an alert by a specific electronic lock. See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the particular lock. See also paragraphs [0089-0090]
wherein the access controller is separate from the specific electronic lock;
Gullicksen discloses that the Server Apparatus 150 is located remotely from the specific electronic lock (any of 130a, 130b, 130c, etc). See Figure 1. See also paragraphs [0046-007]
sending the control message to the access controller,
Gullicksen discloses that a user, using the key device 120 a first request 124 (control message) to the server apparatus 150 (access controller) is sent. See paragraphs [0053, 0061 and 0089].
the control message comprising user authentication information,
The Examiner notes that Gullicksen discloses different methods for user authentication. In one method, the first request is performed in response to authenticating the user using e.g., a biometric sensor on the key device (see paragraphs [0016] and [0061]). In another method, after using the biometric sensor, the key device sends a user identifier to the server apparatus. See paragraph [0086] which discloses that pressing the Select button causes a user identifier to be sent to the server. In other examples, the key device can login to the system. See also paragraphs [0017 and 0087]. See also paragraph [0069] which discloses storing a list of authorized users.
To the extent it is considered that the control message doesn’t comprise user authentication information, the Examiner finds that in view of the above teachings it would have been obvious to a person of ordinary skill in the art to transmit user authentication information to the server for authenticating the user along with the control message.
Nonetheless, Robinson discloses in paragraph [0065] a permission database which is a repository of information to “who may go where”. The verification manager is used to verify a particular user against the permission database to determine whether or not they are an authorized user. In one example, Robinson explains that a user can approach the front gate (as is determined by the location manager) and user information may be utilized by the verification manager to authorize them according the rules stored in the permission database and the gate may be unlocked. Thus, user information (authentication information) is used by the verification manager to authorized them according to the permission database. This permission database includes the specific electronic lock that the user is authorize to control. In another example the same user can approach a fitness club outside normal ours and the verification operation may instead deny access and the door will remain locked. Robinson uses a location manager to determine the location of the user and when a user is near an entry point. See paragraph [0064]. As explained in paragraph [0082], a request along with an associated identifier is sent in order to access the locked area. See also paragraph [0012-0013] which shows that the user can make an access request and the remote server receives the request from the user (paragraph [0053]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to send a authentication information to the server along with the first request. As explained above, Gullicksen already discloses of multiple methods to authenticate a user including sending ID information to the server. Thus, for the purpose of unlocking a lock, it would have been obvious to a person of ordinary skill in the art to transmit identification information along with the request in order to authenticate the user to ensure that they are authorized to have access to the physical space. As set forth above, both Gullicksen and Robinson disclose the importance of user authentication before being granted access to the system. Gullicksen discloses of multiple methods of sending user identification information as well as storing a list of authorized users in the server (see paragraph [0069]) in order to determine who can operate a lock. Since the server stores this information, it would have been predictable to a person of ordinary skill in the art to have the server receive user identification information along with the first request so that further verification of the user can be determined by the server in order to determine whether the user is in the list of authorized users for the electronic lock. Robinson discloses that each user would be identified in a permission database along with information detailing which “locks” (access points) that user can access. Thus, sending authorization information would have obvious to a person of ordinary skill in the art since it is used to verify that the correct person is authorized to access the controlled area.
wherein the control message causes the access controller to trigger the specific electronic lock to emit a lock identifier and the alert in order for the user to identify the specific electronic lock as a correct electronic lock; and
See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
Gullicksen states “a particular lock” is identified based on a set of criteria and it directs the identified lock to issue a human-detectable indication. See also paragraph [0090] which discloses of selecting the top-ranking lock as the identified lock.
As set forth above, the Examiner finds that Gullicksen selects a lock using a ‘set of criteria’ which then causes the lock to issue an alert. Therefore a user can “confirm the identification of a lock 1340a via user input to the key device 120.” (See paragraph [0053]) Thus, Gullicksen suggests the identification of the lock prior to sending a second request to the server after the emitting the triggering of an alert signal or a sound.
The Examiner finds that Gullicksen does not specifically also cause the lock to emit a lock identifier; however, since Gullicksen discloses of a need to specifically identify a lock after the control message triggers the lock to emit an alert signal, then it would have been obvious to also include a specific identifier of the lock since Gullicksen discloses “confirmation” for the lock.
Nonetheless, the Examiner notes that Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to also emit a lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock. As explained by Gullicksen in paragraph [0053], this may serve as confirmation that the lock is the correct lock. (i.e. lock 130a).
acquiring the lock identifier associated with and provided in the vicinity of the specific electronic lock; and
As explained in paragraph [0042],Gullicksen discloses of identifying a controllable lock whose location is based relative to the key device. As further stated in paragraph [0053] a locks is identified “based on a set of criteria” as well as based on performing a discovery operation as explained in paragraph [0054]. As further set forth in paragraph [0055], a lock can be identified based on having the key device point towards the lock. In addition, it is disclosed that the key device may sending this information to the server via a packet. See also paragraph [0065].
The Examiner notes however, that although the user device may point towards the lock, Gullicksen does not specifically disclose of acquiring a lock identifier from the vicinity of the specific electronic lock” and where the unlock message further comprises the lock identifier.
Nonetheless, as explained above, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (eg. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to acquiring a lock identifier from the vicinity of the specific electronic lock and to have the unlock message further comprise the lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used included acquiring an identifier from the vicinity of the lock itself using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock.
sending an unlock message to the access controller after receiving an unlock user input from the user to unlock the specific electronic lock, wherein the unlock message comprises the user authentication information and the lock identifier, and wherein the unlock message causes the access controller to unlock the specific electronic lock.
As explained in paragraph [0053], a user can send a second request (unlock message) to the server apparatus which then proceeds to direct the lock 130a (specific electronic lock) to unlock. The information includes a predetermined code to the lock for unlocking. As explained above, it would have been obvious to a person of ordinary skill in the art to send authentication information from the user device to the server. As explained in paragraph [0069], the codes for operating the lock as well as a list of authorized users are stored in the vault appliance and each lock has established settings and limitations. See also paragraph [0019]
The Examiner notes that as disclosed by Huber, it would have been obvious to emit a lock identifier to the device 120 of Gullicksen and furthermore, it would have been obvious to transmit that identifier to the server since Gullicksen already discloses of sending a second request back to the server which will serve as a confirmation that the lock is the correct lock.
Regarding claim 12:
The method according to claim 11, wherein the alert is an alert signal transmitted from the specific electronic lock.
See paragraph [0053], which discloses that in response to the first request, the lock 130a (specific lock in which the user desires to open) would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
Regarding claim 13:
The method according to claim 12, wherein the alert signal is at least one of a sound signal or a light signal.
See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
Regarding claim 15:
The method according to claim 11, wherein the lock identifier is broadcast from the specific electronic lock.
As set forth above in claim 11, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (eg. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142].
Regarding claim 16:
The method according to claim 15, wherein the lock identifier is broadcast using a Bluetooth beacon.
As set forth above in claim 11, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142].
Regarding claim 17:
The method according to claim 11, wherein the lock identifier is acquired from an optical, machine-readable code.
As set forth above in claim 11, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As set forth paragraphs [0052 and 0058] and in Fig. 1 and 7 a QR code is used for the lock identifier.
Regarding claim 18:
The method according to claim 17, wherein the lock identifier is acquired from a two-dimensional bar code.
As set forth above in claim 11, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As set forth paragraphs [0052 and 0058] and in Fig. 1 and 7 a QR code is used for the lock identifier.
Regarding claim 19:
The method according to claim 11, wherein the lock identifier is acquired based on a digital image.
As set forth above in claim 11, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As set forth paragraphs [0052 and 0058] and in Fig. 1 and 7 a QR code is used for the lock identifier.
Regarding claim 20:
A user device for requesting remote unlocking of a physical space controlled by an electronic lock, the user device comprising:
Gullicksen is directed to enabling a remote key device (e.g. a smart phone, tablet computer or other computing device (paragraph [0009]) to be used with any number of lockable devices in a physical space. See paragraph [0008]. As set forth in paragraphs [0005-0007], electronic locks are used for controlling access to homes, offices, rooms, and safes (physical space 110). See Figure 1.
a processor; and a memory storing instructions that, when executed by the processor cause the user device to:
See paragraph [0027] which discloses that the key device (user device) includes control circuitry including a set of processor and memory.
receive user input from a user to transmit a control message to an access controller to trigger an alert by a specific electronic lock,
Gullicksen discloses that a user, using the key device 120 sends a first request 124 (control message) to the server apparatus 150 (access controller) which will be used to trigger an alert by a specific electronic lock. See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the particular lock. See also paragraphs [0089-0090]
wherein the access controller is separate from the specific electronic lock;
Gullicksen discloses that the Server Apparatus 150 is located remotely from the specific electronic lock (any of 130a, 130b, 130c, etc). See Figure 1. See also paragraphs [0046-0007]
send the control message to the access controller,
Gullicksen discloses that a user, using the key device 120 a first request 124 (control message) to the server apparatus 150 (access controller) is sent. See paragraphs [0053, 0061 and 0089].
the control message comprising user authentication information,
The Examiner notes that Gullicksen discloses different methods for user authentication. In one method, the first request is performed in response to authenticating the user using e.g., a biometric sensor on the key device (see paragraphs [0016] and [0061]). In another method, after using the biometric sensor, the key device sends a user identifier to the server apparatus. See paragraph [0086] which discloses that pressing the Select button causes a user identifier to be sent to the server. In other examples, the key device can login to the system. See also paragraphs [0017 and 0087]. See also paragraph [0069] which discloses storing a list of authorized users.
To the extent it is considered that the control message doesn’t comprise user authentication information, the Examiner finds that in view of the above teachings it would have been obvious to a person of ordinary skill in the art to transmit user authentication information to the server for authenticating the user along with the control message.
Nonetheless, Robinson discloses in paragraph [0065] a permission database which is a repository of information to “who may go where”. The verification manager is used to verify a particular user against the permission database to determine whether or not they are an authorized user. In one example, Robinson explains that a user can approach the front gate (as is determined by the location manager) and user information may be utilized by the verification manager to authorize them according the rules stored in the permission database and the gate may be unlocked. Thus, user information (authentication information) is used by the verification manager to authorized them according to the permission database. This permission database includes the specific electronic lock that the user is authorize to control. In another example the same user can approach a fitness club outside normal ours and the verification operation may instead deny access and the door will remain locked. Robinson uses a location manager to determine the location of the user and when a user is near an entry point. See paragraph [0064]. As explained in paragraph [0082], a request along with an associated identifier is sent in order to access the locked area. See also paragraph [0012-0013] which shows that the user can make an access request and the remote server receives the request from the user (paragraph [0053]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to send a authentication information to the server along with the first request. As explained above, Gullicksen already discloses of multiple methods to authenticate a user including sending ID information to the server. Thus, for the purpose of unlocking a lock, it would have been obvious to a person of ordinary skill in the art to transmit identification information along with the request in order to authenticate the user to ensure that they are authorized to have access to the physical space. As set forth above, both Gullicksen and Robinson disclose the importance of user authentication before being granted access to the system. Gullicksen discloses of multiple methods of sending user identification information as well as storing a list of authorized users in the server (see paragraph [0069]) in order to determine who can operate a lock. Since the server stores this information, it would have been predictable to a person of ordinary skill in the art to have the server receive user identification information along with the first request so that further verification of the user can be determined by the server in order to determine whether the user is in the list of authorized users for the electronic lock. Robinson discloses that each user would be identified in a permission database along with information detailing which “locks” (access points) that user can access. Thus, sending authorization information would have obvious to a person of ordinary skill in the art since it is used to verify that the correct person is authorized to access the controlled area.
wherein the control message causes the access controller to trigger the specific electronic lock to emit a lock identifier and the alert, in order for the user to identify the specific electronic lock as a correct electronic lock; and
See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
Gullicksen states “a particular lock” is identified based on a set of criteria and it directs the identified lock to issue a human-detectable indication. See also paragraph [0090] which discloses of selecting the top-ranking lock as the identified lock.
As set forth above, the Examiner finds that Gullicksen selects a lock using a ‘set of criteria’ which then causes the lock to issue an alert. Therefore a user can “confirm the identification of a lock 1340a via user input to the key device 120.” (See paragraph [0053]) Thus, Gullicksen suggests the identification of the lock prior to sending a second request to the server after the emitting the triggering of an alert signal or a sound.
The Examiner finds that Gullicksen does not specifically also cause the lock to emit a lock identifier; however, since Gullicksen discloses of a need to specifically identify a lock after the control message triggers the lock to emit an alert signal, then it would have been obvious to also include a specific identifier of the lock since Gullicksen discloses “confirmation” for the lock.
Nonetheless, the Examiner notes that Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to also emit a lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock. As explained by Gullicksen in paragraph [0053], this may serve as confirmation that the lock is the correct lock. (i.e. lock 130a).
acquire the lock identifier associated with and provided in the vicinity of the specific electronic lock; and
As explained in paragraph [0042],Gullicksen discloses of identifying a controllable lock whose location is based relative to the key device. As further stated in paragraph [0053] a locks is identified “based on a set of criteria” as well as based on performing a discovery operation as explained in paragraph [0054]. As further set forth in paragraph [0055], a lock can be identified based on having the key device point towards the lock. In addition, it is disclosed that the key device may sending this information to the server via a packet. See also paragraph [0065].
The Examiner notes however, that although the user device may point towards the lock, Gullicksen does not specifically disclose of acquiring a lock identifier from the vicinity of the specific electronic lock” and where the unlock message further comprises the lock identifier.
Nonetheless, as explained above, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (eg. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to acquiring a lock identifier from the vicinity of the specific electronic lock and to have the unlock message further comprise the lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used included acquiring an identifier from the vicinity of the lock itself using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock.
send an unlock message to the access controller after receiving an unlock user input from the user to unlock the specific electronic lock, wherein the unlock message comprises the user authentication information and the lock identifier, and wherein the unlock message causes the access controller to unlock the specific electronic lock.
As explained in paragraph [0053], a user can send a second request (unlock message) to the server apparatus which then proceeds to direct the lock 130a (specific electronic lock) to unlock. The information includes a predetermined code to the lock for unlocking. As explained above, it would have been obvious to a person of ordinary skill in the art to send authentication information from the user device to the server. As explained in paragraph [0069], the codes for operating the lock as well as a list of authorized users are stored in the vault appliance and each lock has established settings and limitations. See also paragraph [0019]
The Examiner notes that as disclosed by Huber, it would have been obvious to emit a lock identifier to the device 120 of Gullicksen and furthermore, it would have been obvious to transmit that identifier to the server since Gullicksen already discloses of sending a second request back to the server which will serve as a confirmation that the lock is the correct lock.
Regarding claim 21:
A non-transitory computer-readable medium comprising a computer program stored thereon for requesting remote unlocking of a physical space controlled by an electronic lock, the computer program comprising computer program code which, when run on a user device, causes the user device to:
Gullicksen is directed to a method for enabling a remote key device (e.g. a smart phone, tablet computer or other computing device (paragraph [0009]) to be used with any number of lockable devices in a physical space. See paragraph [0008]. As set forth in paragraphs [0005-0007], electronic locks are used for controlling access to homes, offices, rooms, and safes (physical space 110). See Figure 1.
In addition, Gullicksen discloses a computer program product with instructions which when executed on one or more computers or processor to perform the disclosed process or processes. See paragraph [0097]
receive user input from a user to transmit a control message to an access controller to trigger an alert by a specific electronic lock,
Gullicksen discloses that a user, using the key device 120 sends a first request 124 (control message) to the server apparatus 150 (access controller) which will be used to trigger an alert by a specific electronic lock. See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the particular lock. See also paragraphs [0089-0090]
wherein the access controller is separate from the specific electronic lock;
Gullicksen discloses that the Server Apparatus 150 is located remotely from the specific electronic lock (any of 130a, 130b, 130c, etc). See Figure 1. See also paragraphs [0046-007]
send the control message to the access controller,
Gullicksen discloses that a user, using the key device 120 a first request 124 (control message) to the server apparatus 150 (access controller) is sent. See paragraphs [0053, 0061 and 0089].
the control message comprising user authentication information,
The Examiner notes that Gullicksen discloses different methods for user authentication. In one method, the first request is performed in response to authenticating the user using e.g., a biometric sensor on the key device (see paragraphs [0016] and [0061]). In another method, after using the biometric sensor, the key device sends a user identifier to the server apparatus. See paragraph [0086] which discloses that pressing the Select button causes a user identifier to be sent to the server. In other examples, the key device can login to the system. See also paragraphs [0017 and 0087]. See also paragraph [0069] which discloses storing a list of authorized users.
To the extent it is considered that the control message doesn’t comprise user authentication information, the Examiner finds that in view of the above teachings it would have been obvious to a person of ordinary skill in the art to transmit user authentication information to the server for authenticating the user along with the control message.
Nonetheless, Robinson discloses in paragraph [0065] a permission database which is a repository of information to “who may go where”. The verification manager is used to verify a particular user against the permission database to determine whether or not they are an authorized user. In one example, Robinson explains that a user can approach the front gate (as is determined by the location manager) and user information may be utilized by the verification manager to authorize them according the rules stored in the permission database and the gate may be unlocked. Thus, user information (authentication information) is used by the verification manager to authorized them according to the permission database. This permission database includes the specific electronic lock that the user is authorize to control. In another example the same user can approach a fitness club outside normal ours and the verification operation may instead deny access and the door will remain locked. Robinson uses a location manager to determine the location of the user and when a user is near an entry point. See paragraph [0064]. As explained in paragraph [0082], a request along with an associated identifier is sent in order to access the locked area. See also paragraph [0012-0013] which shows that the user can make an access request and the remote server receives the request from the user (paragraph [0053]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to send a authentication information to the server along with the first request. As explained above, Gullicksen already discloses of multiple methods to authenticate a user including sending ID information to the server. Thus, for the purpose of unlocking a lock, it would have been obvious to a person of ordinary skill in the art to transmit identification information along with the request in order to authenticate the user to ensure that they are authorized to have access to the physical space. As set forth above, both Gullicksen and Robinson disclose the importance of user authentication before being granted access to the system. Gullicksen discloses of multiple methods of sending user identification information as well as storing a list of authorized users in the server (see paragraph [0069]) in order to determine who can operate a lock. Since the server stores this information, it would have been predictable to a person of ordinary skill in the art to have the server receive user identification information along with the first request so that further verification of the user can be determined by the server in order to determine whether the user is in the list of authorized users for the electronic lock. Robinson discloses that each user would be identified in a permission database along with information detailing which “locks” (access points) that user can access. Thus, sending authorization information would have obvious to a person of ordinary skill in the art since it is used to verify that the correct person is authorized to access the controlled area.
wherein the control message causes the access controller to trigger the specific electronic lock to emit a lock identifier and the alert in order for the user to identify the specific electronic lock as a correct electronic lock; and
See paragraph [0053], which discloses that in response to the first request, the lock 130 would either output a blinking light or a sound in order to confirm the identification of the lock via a user input to the key device.
Gullicksen states “a particular lock” is identified based on a set of criteria and it directs the identified lock to issue a human-detectable indication. See also paragraph [0090] which discloses of selecting the top-ranking lock as the identified lock.
As set forth above, the Examiner finds that Gullicksen selects a lock using a ‘set of criteria’ which then causes the lock to issue an alert. Therefore a user can “confirm the identification of a lock 1340a via user input to the key device 120.” (See paragraph [0053]) Thus, Gullicksen suggests the identification of the lock prior to sending a second request to the server after the emitting the triggering of an alert signal or a sound.
The Examiner finds that Gullicksen does not specifically also cause the lock to emit a lock identifier; however, since Gullicksen discloses of a need to specifically identify a lock after the control message triggers the lock to emit an alert signal, then it would have been obvious to also include a specific identifier of the lock since Gullicksen discloses “confirmation” for the lock.
Nonetheless, the Examiner notes that Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (e.g. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to also emit a lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock. As explained by Gullicksen in paragraph [0053], this may serve as confirmation that the lock is the correct lock. (i.e. lock 130a).
acquire the lock identifier associated with and provided in the vicinity of the specific electronic lock; and
As explained in paragraph [0042],Gullicksen discloses of identifying a controllable lock whose location is based relative to the key device. As further stated in paragraph [0053] a locks is identified “based on a set of criteria” as well as based on performing a discovery operation as explained in paragraph [0054]. As further set forth in paragraph [0055], a lock can be identified based on having the key device point towards the lock. In addition, it is disclosed that the key device may sending this information to the server via a packet. See also paragraph [0065].
The Examiner notes however, that although the user device may point towards the lock, Gullicksen does not specifically disclose of acquiring a lock identifier from the vicinity of the specific electronic lock” and where the unlock message further comprises the lock identifier.
Nonetheless, as explained above, Huber discloses of accessing a remote lock in which a lock 100 (Fig. 1), 701 (Figs. 7) includes a lock identifier, e.g. 103, 701a, which may be sent to a mobile device 702 (Fig. 7) via method 2200 (Fig. 22). As set forth therein, “[t]he lock identifier can be received in any manners described herein, such as through scanning of a machine-readable identifier (eg. 701a), through manually entry at the mobile device 702, through Bluetooth, NFC, light, or audio communications, etc.” See paragraph [0138]. See also paragraphs [0040, 0137-0142]. As further set forth in paragraph [0096] , in addition to the lock identifier, user identification information may also be sent to the server.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to acquiring a lock identifier from the vicinity of the specific electronic lock and to have the unlock message further comprise the lock identifier. As explained by Gullicksen, the identification of a lock is part of its method for being able to command the lock to either lock or unlock. As explained in paragraph [0007] of Gullicksen, the server seeks to identify the lock. These method includes a location positioning service (see paragraph [0026]), based on a set of criteria (paragraph [0053]), performing a discovery operation (paragraph [0054]) or via an orientation sensor(paragraph [0055]). In addition, to these various methods, Huber shows that other methods for identifying a lock can be used included acquiring an identifier from the vicinity of the lock itself using several different methods including Bluetooth, light, NFC etc. The Examiner finds that using any of the above different methods by substituting the method described by Gullicksen with obtaining a lock identifier as disclosed by Huber. The Examiner finds that the since Gullicksen already discloses of obtaining information pertaining to the specific lock the user want to interact with and discloses of methods such as pointing the key device towards the lock, it would have been predictable to a person of ordinary skill in the art to use other methods as disclosed by Gullicksen and Huber for obtaining a lock identifier that is within the vicinity of the lock.
send an unlock message to the access controller after receiving an unlock user input from the user to unlock the specific electronic lock, wherein the unlock message comprises the user authentication information and the lock identifier, and wherein the unlock message causes the access controller to unlock the specific electronic lock.
As explained in paragraph [0053], a user can send a second request (unlock message) to the server apparatus which then proceeds to direct the lock 130a (specific electronic lock) to unlock. The information includes a predetermined code to the lock for unlocking. As explained above, it would have been obvious to a person of ordinary skill in the art to send authentication information from the user device to the server. As explained in paragraph [0069], the codes for operating the lock as well as a list of authorized users are stored in the vault appliance and each lock has established settings and limitations. See also paragraph [0019]
The Examiner notes that as disclosed by Huber, it would have been obvious to emit a lock identifier to the device 120 of Gullicksen and furthermore, it would have been obvious to transmit that identifier to the server since Gullicksen already discloses of sending a second request back to the server which will serve as a confirmation that the lock is the correct lock.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ovidio Escalante whose telephone number is (571)272-7537. The examiner can normally be reached on Monday to Friday - 6:00 AM to 2:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Michael Fuelling, can be reached at telephone number (571)272-7537. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/Ovidio Escalante/
Primary Examiner, Art Unit 3992
Conferees:
/MATTHEW E HENEGHAN/Primary Examiner, Art Unit 3992 /M.F/Supervisory Patent Examiner, Art Unit 3992