DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The application of King for a “smart lock and method of transmitting a status of smart lock” filed on November 25, 2024 has been examined.
This application claims priority to a 371 of PCT/EP2022/064363, which is filed on May 26, 2022.
A preliminary amendment to the claims 3, 4, 6, 7, 9, 12-14, 16 and 17 has been entered and made of record.
Claims 1-17 are pending.
Claim Objections
Claim 3 is objected to because of the following informalities: “a digital operation or a manual operation” in line 5 should be “the digital operation or the manual operation”.
Claim 15 is objected to because of the following informalities: “the remote device” in line 4 should be “the remote device.”.
An appropriate correction is required.
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.
Claims 1, 2, 4-11 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Gerhardt et al. (Pub. No. 2020/0329136) in view of Giles et al. (US# 11,182,989).
Referring to claim 1, Gerhardt et al. disclose a smart lock (102) (page 1 paragraphs 0005-0012; see Figures 1 to 3) comprising:
a drive train for actuating a lock mechanism between an unlocked position and a locked position (i.e. the thumbturn (300) is rotated clockwise or counterclockwise to drive a spindle which will insert or retract the bolt (301) from the door frame. The thumbturn can be actuated remotely using encrypted radio transmissions, which are deciphered by a special purpose onboard circuit. If the code has been deciphered successfully the circuit will enable a motor which will drive a gearing system which rotates the spindle) (paragraph 0037; see Figure 3);
an electric actuator (i.e. the motor) arranged to drive the drive train to actuate the lock mechanism (paragraph 0037; see Figure 3);
a manual actuator (303) (i.e. the thumbturn) arranged to drive the drive train to actuate the lock mechanism (i.e. the thumbturn (300) is rotated clockwise or counterclockwise to drive a spindle which will insert or retract the bolt (301) from the door frame) (paragraph 0037; see Figure 3);
a sensor (not shown) arranged to output a signal indicative of a status of the lock mechanism, the status representing whether the lock mechanism is in the unlocked position or the locked position (i.e. a push notification may be context dependent, but in an example embodiment the web service sends a push notification to the portable electronic device informing the device that the status of the locking system has changed. It is also conceivable that the locking system sends a push notification when the status of the locking system has changed (for instance someone manually unlocked the door with a key). In an example embodiment, the portable electronic device sends the web service a push notification when a user is added as an authorized user to a lock) (page 9 paragraph 0120; see Figure 22); and
a processor (i.e. one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations) (page 15 paragraph 0197; see Figures 3 and 12-13) configured to:
receive the signal (i.e. a push notification may be context dependent, but in an example embodiment the web service sends a push notification to the portable electronic device informing the device that the status of the locking system has changed) (page 9 paragraph 0120; see Figure 22);
encode the status into an information packet (i.e. it is also conceivable that the locking system sends a push notification when the status of the locking system has changed (for instance someone manually unlocked the door with a key). In an example embodiment, the portable electronic device sends the web service a push notification when a user is added as an authorized user to a lock) (page 9 paragraph 0120; see Figure 22); and
transmit the information packet independent of the presence of a receiver device (100) (i.e. when the system periodically wakes up as determined by the algorithm it may check for lock, unlock or status commands send from the web service, and, potentially, from a mobile device proximate to the door or not, another third-party web service, an application interface, web interface or text message interface) (page 9 paragraph 0120; page 12 paragraph 0149; see Figures 22 and 27-30).
However, Gerhardt et al. did not explicitly disclose the processor configured to: encode the status and a timestamp into an information packet.
In the same field of endeavor of an access control smart door lock, Giles et al. teach that the processor (112) (i.e. the control unit) configured to: encode the status and a timestamp into an information packet (i.e. the status indicators may be used to identify which of the unlocked door knobs were opened. The managing application may allow the user to acquire time logs for each opening of the one or more door knobs) (column 7 lines 5 to 18; see Figures 1 to 4) in order to monitor the activity of the door for the homes.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for the control unit allows the user of the mobile device to receive the status notifications of the door knobs and also the time logs for each opening of the one or more door knobs taught by Giles et al. in the remotely operable lock controllable by the mobile device of Gerhardt et al. because having the control unit allows the user of the mobile device to receive the status notifications of the door knobs and also the time logs for each opening of the one or more door knobs would provide increased security in the monitoring system for their homes and business.
Referring to claim 2, Gerhardt et al. in view of Giles disclose the smart lock of claim 1, Gerhardt et al. disclose wherein the information packet is a Bluetooth Low Energy advertising packet (page 10 paragraph 0129).
Referring to claim 4, Gerhardt et al. in view of Giles disclose the smart lock of claim 1, Gerhardt et al. disclose wherein the processor is further configured to encode a control object into the information packet (i.e. In the case of bidirectional radio frequency communications between the remote unit and the lock, it is possible for the lock to confirm reception of the signal by sending a signal back to the remote. It is also possible that the lock may signal other information back to the remote including current battery status as well as any malfunction that occurs on the lock) (page 3 paragraph 0044).
Referring to claim 5, Gerhardt et al. in view of Giles disclose the smart lock of claim 4, Gerhardt et al. disclose wherein the control object represents one or more of: a state of charge of a battery of the smart lock (i.e. a battery level) (i.e. the lock may signal other information back to the remote including current battery status as well as any malfunction that occurs on the lock) (page 3 paragraph 0044; page 9 paragraph 0115).
Referring to claim 6, Gerhardt et al. in view of Giles disclose the smart lock of claim 1, Gerhardt et al. disclose wherein the processor is configured to transmit the information packet periodically (i.e. when the system periodically wakes up as determined by the algorithm it may check for lock, unlock or status commands send from the web service, and, potentially, from a mobile device proximate to the door or not, another third-party web service, an application interface, web interface or text message interface.) (page 12 paragraph 0149).
Referring to claim 7, Gerhardt et al. in view of Giles disclose a system comprising the smart lock of claim 1 and a receiver device (400) (i.e. a Web server) (page 3 paragraph 0038; see Figures 4-6) configured to:
receive the information packet (i.e. FIG. 4 demonstrates how the user's lock server (403) connects to the web service (400) by tunneling through the user's firewall (401). The server is also responsible for transmitting lock and unlock commands (also termed “requests” in this disclosure) or codes to the lock) (page 3 paragraph 0044; see Figure 4 to 6);
decode the status from the information packet (i.e. The remote unit (404) is either built directly into the lock server or plugged into the lock server through a connector such as, but not limited to, USB. Depending on the type of wireless lock, the remote unit will take a signal and convert it into the appropriate format for the wireless lock. The signal will then be relayed over radio frequency to the lock and be executed) (page 3 paragraphs 0041-0044); and
transmit the status to a remote device (100) (i.e. a NFC enabled portable electronic device) (i.e. A mobile device (13402) or web service (1501) may receive data about the knock sequence, lock operation or door close or door open event notifying the user) (page 6 paragraphs 0079-0083; see Figures 6-8 and 14).
Referring to claim 8, Gerhardt et al. in view of Giles disclose the smart lock of claim 7, Gerhardt et al. disclose wherein the receiver device is further configured to:
determine whether the status has changed compared to a previous status; and
if the status has changed, transmit the status to the remote device (100) (i.e. a push notification may be context dependent, but in an example embodiment the web service sends a push notification to the portable electronic device informing the device that the status of the locking system has changed. It is also conceivable that the locking system sends a push notification when the status of the locking system has changed (for instance someone manually unlocked the door with a key). The portable electronic device sends the web service a push notification when a user is added as an authorized user to a lock) (page 9 paragraph 0120; see Figure 22).
Referring to claim 9, Gerhardt et al. in view of Giles disclose the smart lock of claim 7, Gerhardt et al. disclose wherein the receiver device transmits the status to the remote device via a platform (i.e. the web service sends a push notification to the portable electronic device informing the device that the status of the locking system has changed. It is also conceivable that the locking system sends a push notification when the status of the locking system has changed. the. The lock server (403) can either be connected directly to a user's Internet service or more likely through a router or switch that employs NAT and firewall technologies (402). Regardless of whether or not this component is present in the system, the reverse tunneling (401) will allow for bidirectional communications between the lock server and the web service) (page 3 paragraphs 0041-0044; page 9 paragraph 0120; see Figures 4-8 and 22).
Referring to claims 10, 11 and 13-15, Gerhardt et al. in view of Giles disclose a computer-implemented method of transmitting a status of a lock mechanism of a smart lock representing whether the lock mechanism is in an unlocked position or a locked position, although different in scope from the claims 1, 2 and 6-8, the claims 10, 11 and 13-15 contains similar limitations in that the claims 1, 2 and 6-8 already addressed above therefore claims 10, 11 and 13-15 are also rejected for the same obvious reasons given with respect to 10, 11 and 13-15, respectively.
Referring to claim 16, Gerhardt et al. in view of Giles disclose the computer-implemented method of claim 10, Gerhardt et al. disclose wherein: a control object (i.e. a battery) is further encoded into the information packet; the control object is decoded from the information packet (i.e. the lock may signal other information back to the remote including current battery status as well as any malfunction that occurs on the lock) (page 3 paragraph 0044), wherein the method further comprises: if the control object indicates that the status may be unreliable then sending a request to the smart lock to confirm the status (i.e. The locking system web service may interact through a standardized set of commands with the third party system to additionally notify it, and in turn, the user's third-party clients, with information about the status of the locking system not limited to but including such information as revocations in access, offline alerts, door status and battery levels) (page 9 paragraph 0115).
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Gerhardt et al. (Pub. No. 2020/0329136) in view of Giles et al. (US# 11,182,989) as applied to claims 1 and 10, and further in view of King et al. (GB 259007).
Referring to claims 3 and 12, Gerhardt et al. in view of Giles disclose the smart lock and the method of claims 1 and 10, however, Gerhardt et al. in view of Giles did not explicitly disclose wherein the processor is further configured to: determine whether a most recent operation of the smart lock was a digital operation or a manual operation, wherein the status further represents whether the most recent operation was a digital operation or a manual operation.
In the same field of endeavor of an access control smart door lock, King et al. teach that determine whether a most recent operation of the smart lock was a digital operation or a manual operation, wherein the status further represents whether the most recent operation was a digital operation or a manual operation (i.e. the smart lock 1 may further include a movement sensor arranged to output a movement signal in response to movement of the manual actuator. That is, the movement sensor outputs a signal to indicate that the manual actuator has been moved) (page 12 lines 4 to 14) in order to monitor the activity of the smart lock.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for detecting the status of operation of the smart lock was manual or digital operation taught by King et al. in the remotely operable lock controllable by the mobile device of Gerhardt et al. in view of Giles because detecting the status of operation of the smart lock was manual or digital operation would provide useful information about the operation of the smart lock in the monitoring system.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Gerhardt et al. (Pub. No. 2020/0329136) in view of Giles et al. (US# 11,182,989) as applied to claim 10, and further in view of Dumas et al. (Pub. No. 2014/0292481).
Referring to claim 17, Gerhardt et al. in view of Giles disclose the computer-implemented method of claim 10, however, Gerhardt et al. in view of Giles did not explicitly disclose further comprising the steps of: receiving confirmation from a receiver device that the receiver device has received the information packet; and transmitting the information packet until the confirmation has been received.
In the same field of endeavor of a smart door lock system, Dumas et al. teach that receiving confirmation from a receiver device that the receiver device has received the information packet; and transmitting the information packet until the confirmation has been received (i.e. if the user chooses to change the state of the lock 11 in the mobile application 17' as determined in step 2405, the system proceeds to a step 2407 at which point the remote access device again determines if the lock 11 is in direct communication range with respect to the remote access device 15'. To reiterate, this is accomplished by remote access device 15' listening for a lock's broadcasting signal. If the remote access device 15' does not receive a broadcast from lock 11 as determined in step 2407, the process advances to a step 2408 where remote access device 15' sends a lock/unlock command to the server 34 to instruct the RPU 30 to change the state of the lock 11. The RPU 30 then sends a lock/unlock command to lock 11. The lock 11 performs the action of locking or unlocking the lock, depending on the state of the lock, and the lock 11 sends a confirmation to the RPU 30. Thereafter, the RPU 30 sends a confirmation signal to the server 34, the server 34 sends a signal to the remote access device 15' that the lock/unlock has been performed, and the remote access device 15' displays the new lock state. The process then returns to step 2405 where the system waits for the user to either initiate a lock/unlock command in the mobile application 17' or exit the mobile application 17') (page 12 paragraph 0143; see Figure 24).
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for the remote access device receives the signal that the lock/unlock has been performed and indicated that the new lock state on the display until the user exit the mobile application or initiate control command again taught by Dumas et al. in the remotely operable lock controllable by the mobile device of Gerhardt et al. in view of Giles because having the remote access device receives the signal that the lock/unlock has been performed and indicated that the new lock state on the display until the user exit the mobile application or initiate control command again would increase security in the monitoring system for their homes and business.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to the enclosed PTO-892 for details.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NAM V NGUYEN whose telephone number is 571-272-3061. Fax number is (571) 273-3061. The examiner can normally be reached on 8:00AM-5:00PM Monday to Friday.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Quan-Zhen Wang can be reached on 571-272-3114. The fax phone numbers for the organization where this application or proceeding is assigned are 571-273-8300 for regular communications.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/NAM V NGUYEN/
Primary Examiner, Art Unit 2685