U.S. patent application number 13/462765 was filed with the patent office on 2012-11-08 for systems and methods for controlling a locking mechanism using a portable electronic device.
This patent application is currently assigned to Apigy Inc.. Invention is credited to Paul Michael Gerhardt, Charles Cameron Robertson.
Application Number | 20120280783 13/462765 |
Document ID | / |
Family ID | 46052923 |
Filed Date | 2012-11-08 |
United States Patent
Application |
20120280783 |
Kind Code |
A1 |
Gerhardt; Paul Michael ; et
al. |
November 8, 2012 |
SYSTEMS AND METHODS FOR CONTROLLING A LOCKING MECHANISM USING A
PORTABLE ELECTRONIC DEVICE
Abstract
Systems and methods are provided for operating a remotely
operable lock. In an example embodiment, a method comprises
providing a first web service for receiving credentials or a
command from a portable electronic device having a software
application installed thereon, issuing a command for receipt by the
lock from the web service, and providing an application programming
interface at the first web service for integrating a second web
service or the software application with the first web service to
allow the portable electronic device to communicate with the lock
or web service.
Inventors: |
Gerhardt; Paul Michael;
(Palo Alto, CA) ; Robertson; Charles Cameron;
(Palo Alto, CA) |
Assignee: |
Apigy Inc.
Palo Alto
CA
|
Family ID: |
46052923 |
Appl. No.: |
13/462765 |
Filed: |
May 2, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61481518 |
May 2, 2011 |
|
|
|
Current U.S.
Class: |
340/5.6 |
Current CPC
Class: |
H04W 12/00503 20190101;
G07C 9/00571 20130101; G07C 2209/64 20130101; H04M 1/72533
20130101; H04W 12/00522 20190101; H04L 63/0492 20130101; H04L
63/0428 20130101; H04W 12/003 20190101; H04W 12/08 20130101; G07C
2009/00365 20130101; G07C 2009/00412 20130101; H04L 63/08 20130101;
G07C 9/00309 20130101; H04W 12/06 20130101 |
Class at
Publication: |
340/5.6 |
International
Class: |
G06F 7/04 20060101
G06F007/04 |
Claims
1. A method of operating a remotely operable lock, the method
comprising: providing a first web service for receiving credentials
or a command from a portable electronic device having a software
application installed thereon; issuing a command for receipt by the
lock from the web service; and providing an application programming
interface (API) at the first web service for integrating a second
web service or the software application with the first web service
to allow the portable electronic device to communicate with the
lock or web service.
2. The method of claim 1, wherein the software application is a
third party software application.
3. The method of claim 1, wherein the integration is performed in
response to a request for access to the first web service or lock
from a user.
4. The method of claim 1, further comprising authenticating the
credentials received at the web service, and based on a successful
authentication, issuing the command for receipt by the lock.
5. The method of claim 1, wherein the received credentials relate
to the lock.
6. The method of claim 1, wherein the received credentials relate
to the portable electronic device.
7. The method of claim 1, wherein the received credentials relate
to a third party user or second web service requesting access to
the first web service or the lock.
8. The method of claim 1, wherein the command for receipt by the
lock is received by the lock via the second web service.
9. The method of claim 4, wherein the integration is performed in
response to a request for access to the first web service or lock
from an unauthenticated user.
10. The method of claim 7, wherein the received credentials
relating to a third party user or second web service are
authenticated by an authenticated user of the lock.
11. The method of claim 10, wherein the third party or second web
service may seamlessly issue a command to or receive data from the
lock.
12. The method of claim 2, wherein the third party application
automatically requests access to the lock on behalf of a user based
on the occurrence of an outside event.
13. The method of claim 12, wherein the outside event is an event
selected from the group comprising: booking a room for use at a
certain time; requesting access to secure premises; delivery of a
parcel; inspection of premises; entry into a motor vehicle; and use
of a bicycle.
14. A system for operating a remotely operable lock, the system
comprising: a first web service to receive credentials or a command
from a portable electronic device having a software application
installed thereon, and to issue a command for receipt by the lock
from the web service; and the first web service having an
application programming interface (API) to integrate a second web
service or the software application with the first web service to
allow the portable electronic device to communicate with the lock
or web service.
Description
RELATED APPLICATIONS
[0001] This application claims the benefit under 35 U.S.C. 119(e)
to U.S. Provisional Patent Application Ser. No. 61/481,518,
inventors Gerhardt et al, entitled "System and Methods for
Controlling a Locking Mechanism using a Portable Electronic Device"
filed May 2, 2011, which is incorporated herein by reference in its
entirety and made a part hereof.
BACKGROUND
[0002] 1. Technical Field
[0003] The present disclosure relates to access control for
security purposes, and more specifically to electronic access
control mechanisms which can be locked or unlocked remotely using
commands issued from a website, portable electronic device, or
other computer devices through means of software, Short Message
Service (SMS), Remote Frequency Identification (RFID), Near Field
Communications (NFC), or other means of radio communication.
Non-limiting examples of a computer device may include but are not
limited to a laptop Personal Computer (PC), a desktop PC, a tablet
PC, a smart phone, a mobile phone, or Personal Digital
Assistant.
[0004] 2. Description of Related Art
[0005] There are a number of electronic locks which can be
activated using cut keys, scanning a passive Radio Frequency
Identification (RFID) tag with a hardwired reader, or pressing a
button on an electronic key fob which transmits an encrypted radio
signal to an access control mechanism.
[0006] These devices generally rely on hardware components unique
to each user, and which if lost or compromised require system
reprogramming and material replacement.
SUMMARY
[0007] The present disclosure relates to a network (e.g., Internet)
accessible system and web service to communicate with remotely
operable locks, for example radio frequency controlled deadbolt
locks, doorknob locks, or electrical strikes which can be actuated
remotely by communicating with a nearby server through encrypted
Internet communication protocols. The service can be accessed from
portable electronic devices with Internet connections or that are
equipped with Short Message Service (SMS) functionality as well as
non-portable devices such as Desktop Personal Computers with
network connections. An individual signs up for an account on the
website associated with the service. The website acts as a gateway
service to access, administer, and configure the remotely
accessible electronic lock system. If a user or administrator is
the owner of the lock server unit, they may grant other people
virtual keys to access the associated lock. The keys may be
temporary or permanent. The keys may be valid during certain hours
or days or valid at any time. The keys may grant a guest the
ability to invite others or not. Their function may be suspended or
reinstated by the owner, user or an administrator at any time. In
an example embodiment, the virtual keys may be sent to a phone
number or email address.
[0008] A user may use the web service by executing a software
application on their portable electronic device, which can lock and
unlock the door, invite guests, view access history; the user may
also visit a website which offers the same functionality. The user
can also lock and unlock the door sending a text message with a
corresponding pin code to a purpose specific telephone number. Text
messages are validated with a pin code as well as verifying that
the source telephone number is associated with the lock. The user
may grant others access or change their pin code through text
message as well.
[0009] The system abstracts access control from physical
identifiers such as material keys or unique key-cards to virtual
keys, which may be accessed from physical electronic devices. As
the keys are stored in an electronic format in a secure web server,
a loss of an electronic device; which is used to access the key,
does not represent a lost key. In addition virtual access can be
revoked remotely, or the password used to access the key can be
changed at any time. A lost physical key on the other hand might
require that the owners rekey their locks to maintain a secure
environment.
[0010] In an example embodiment, a web service is a method of
communication between two electronic devices over the web
(internet).
[0011] The W3C defines a "Web service" as "a software system
designed to support interoperable machine-to-machine interaction
over a network". It has an interface described in a
machine-processable format (specifically Web Services Description
Language, known by the acronym WSDL). Other systems interact with
the Web service in a manner prescribed by its description using
SOAP (Simple Object Access Protocol) messages, typically conveyed
using HTTP (Hypertext Transfer Protocol) with an XML (Extensible
Markup Language) serialization in conjunction with other
Web-related standards.
[0012] In this specification, a "user" is anyone interacting with
the locking system or web service, including a person operating a
portable electronic device as described herein. The words "user"
and "device" (or "portable electronic device") are in some cases
used interchangeably, since the device is carried and operated by
the user.
[0013] A "locking system" or "lock system" includes a "lock", and
the terms are sometimes used interchangeably. Configuration,
description, use or claims to a "locking system" or "lock system"
includes configuration, description, use or claims to a "lock"
accordingly.
[0014] In an example embodiment, a system for operating a remotely
operable lock comprises: a web service for receiving credentials
from a portable electronic device; authenticating the received
credentials; and issuing a command for receipt by the lock upon
successful authentication of the credentials. The system may
further comprise a tag located on or adjacent the lock and
associated with the lock, the tag allowing the portable electronic
device to identify or receive credentials from the tag. In an
example embodiment, receiving credentials from a portable
electronic device includes receiving a command input by a user on
the portable electronic device. The web service may further issue a
software application for installation on the portable electronic
device, the application allowing communication of credentials or
commands from the portable electronic device to the web service.
The web service may further to update the application software
periodically.
[0015] In another example embodiment, a system for operating a
remotely operable lock comprises: a web service for detecting the
proximity of a portable electronic device to the lock; receiving
credentials from the portable electronic device; and issuing a
command for receipt by the lock. The web service may further
authenticate the credentials received at the web service, and based
on a successful authentication, issue the command for receipt by
the lock.
[0016] The system may further comprise a tag located on or adjacent
the lock and associated with the lock, the tag allowing the
portable electronic device to identify or receive credentials from
the tag. Receiving credentials from a portable electronic device
may include receiving a command input by a user on the portable
electronic device.
[0017] The web service may further communicate with a software
application installed on the portable electronic device, the
application allowing communication of credentials or commands from
the portable electronic device to the web service. The system may
detect the proximity of the portable electronic device to the lock
and automatically launch the software application.
[0018] In another example embodiment, a system for operating a
remotely operable lock comprises: a first web service for receiving
credentials or a command from a portable electronic device having a
software application installed thereon, and for issuing a command
for receipt by the lock from the web service; the first web service
having an application programming interface (API) for integrating a
second web service or the software application with the first web
service to allow the portable electronic device to communicate with
the lock or web service.
DESCRIPTION OF THE DRAWINGS
[0019] The example embodiments may be better understood, and its
numerous features and advantages made apparent to those skilled in
the art by referencing the accompanying drawings and descriptions
provided in the Detailed Description. For ease of understanding and
simplicity, common numbering of elements within the illustrations
is employed where an element is the same in different drawings. In
the drawings, which are not necessarily drawn to scale, like
numerals may describe similar components in different views. In
some instances, different numerals may describe similar components
in different views. Like numerals having different letter suffixes
may represent different instances of similar components. The
drawings illustrate generally, by way of example, but not by way of
limitation, various embodiments discussed in the present
document.
[0020] FIG. 1 demonstrates an NFC enabled portable electronic
device reading an f tag. The act of reading the tag will trigger an
application to launch and actuate a door lock.
[0021] FIG. 2 demonstrates a camera enabled portable electronic
device reading a Quick Response (QR) code. The act of reading the
code will trigger an application to launch and actuate a door
lock.
[0022] FIG. 3 depicts one type of door lock in unlocked and locked
positions.
[0023] FIG. 4 demonstrates how the user's lock server unit connects
to the cloud based service by tunneling through the user's
firewall. The server is also responsible for transmitting "lock"
and "unlock" codes to the lock.
[0024] FIG. 5 presents an alternate configuration of FIG. 4 where
the server controls a relay box to actuate an electric strike.
[0025] FIG. 6 demonstrates the Portable Electronic Device
communicating through the Internet to the local server
[0026] FIG. 7 is a flow chart depicting the steps of using Near
Field Communication to lock or unlock a door
[0027] FIG. 8 demonstrates the advantages of system by enabling
extensive multi-factor authorization through means of Global
Positioning System (GPS) coordinates, Wi-Fi.TM. network
connectivity, Near Field Communication verification, pin code
entry, QR code recognition, and timed entry.
[0028] FIG. 9 depicts a second portable electronic device
attempting to unlock a door for which it does not have access. In
this case, the owner's device is notified with relevant information
pertinent to the requestor and presented with an option to unlock
the door for the requestor.
[0029] FIG. 10 demonstrates how the system can be used through the
Simple Message Service (SMS).
[0030] FIGS. 11-30 are schematic views of locking systems, web
services with associated components and features in accordance with
various example embodiments.
[0031] FIGS. 31-31G are charts showing methods according to example
method embodiments.
[0032] FIGS. 32-32G are charts showing methods according to example
method embodiments.
[0033] FIGS. 33-33C are charts showing methods according to example
method embodiments.
[0034] FIG. 34 is a block diagram of a machine in the example form
of a computer system within which a set of instructions may be
executed for causing the machine to perform any one or more of the
methodologies herein discussed
DETAILED DESCRIPTION
[0035] The following is a detailed description of illustrative
embodiments of the present invention. As these embodiments of the
present invention are described with reference to the
aforementioned drawings, various modifications or adaptations of
the methods and or specific structures described may become
apparent to those skilled in the art. All such modifications,
adaptations, or variations that rely upon the teachings of the
present inventions, and through which these teachings have advanced
the art, are considered to be within the spirit and scope of the
present invention. For example, the devices set forth herein have
been characterized herein as executing remote instructions on
physical machines described as locks by means of controlling
electrical relays or communicating over serial, USB, or wireless
channels, but it is apparent that other professional or home
automation devices may be accessed through these means as well.
Hence, these descriptions and drawings are not to be considered in
a limiting sense, as it is understood that the present invention is
in no way limited to the embodiments illustrated.
[0036] The present disclosure relates to a system and service for
activating electric devices including operable locks remotely from
a portable electronic device. The system is constructed in a very
modular way in order to provide configurable degrees of
authentication balanced with efficient and appropriate mechanisms
for accessibility. Other systems are not as configurable, not as
secure, or not as accessible.
[0037] FIG. 1 demonstrates an NFC enabled portable electronic
device (100) reading a passive NFC tag (101). The NFC tag may be
encoded in a variety of standards, including but not limited to
ISO/IEC 14443 (both Type A and Type B), various MIFARE
implementations, and FeliCa. The electronic device provides
inductive power (103) to the NFC tag. The NFC tag responds with a
static Universal Resource Indicator (URI) (104) which is encoded in
such a way as to launch a special purpose application on the
electronic device. The URI also contains an identifier string
unique to each tag. The same URI can be encoded in the form of a
Quick Response (QR) code onto the surface of the tag. The act of
reading the tag will trigger the device to launch the application,
passing the unique string as a parameter. The application then
passes the user id, password hash, and unique identifier string to
a cloud service. The cloud service validates the information, and
performs an action associated with the unique tag identifier, or
based on a command issued by a user as input on the portable
electronic device. The action or command is performed on a lock or
lock server associated with the tag identifier to actuate the door
lock in 102. The server sends a confirmation of the action
performed to the electronic device.
[0038] FIG. 2 demonstrates an alternate embodiment of the process
represented in FIG. 1 with camera enabled portable electronic
device reading a Quick Response (QR) code instead of reading the
URI through NFC. In this case the URI mentioned in 104 would be
encoded in QR format instead of an NFC data type. The user launches
a QR code reader application, scans the QR code, the application
parses the code as a URI and the application acts accordingly to
actuate the lock using a unique identifier embedded in the QR
code.
[0039] FIG. 3 depicts one type of door lock 102 in unlocked 302 and
locked (304) positions. 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. This type of door
lock is commercially available and represented here for the purpose
of illumination and to provide context to those skilled in the
art.
[0040] 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.
[0041] The web service (400) securely controls all signals routed
to the end lock. As such, it will accept commands from
authenticated browsers and web services and relay them to the
desired lock assuming all authentication requirements have been
met.
[0042] In order to properly relay commands through various Network
Address Translation (NAT) and firewall mechanisms with minimal
initial configuration on the part of the user, the web service and
lock server (403) engage in Secure Shell (SSH) reverse tunneling.
When the lock server is first connected to an Internet connection
it will attempt to initiate one or multiple Secure Socket Layer
connections with the web service using the SSH implementation. If
the lock server can successfully connect to the web service, the
web service will initiate a reverse tunnel, whereby a forwarding
port on the web service is bound to a second port on the lock
server. In this manner requests received by the web server will be
forwarded to the lock server without having to actively negotiate
in Network Address Translation (NAT). Requests may be further
restricted using firewall rules. The communication protocols
between the two servers are well known to those skilled in the art.
By having the lock server initiate the tunnel to the web service,
the web service can access the lock server at any time without
first having to negotiate NAT, thus enabling a more consistently
reachable service.
[0043] 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.
[0044] The lock server (403) maintains a reverse tunnel (401) with
the web service and receives and executes commands to modify the
state of the lock. It is connected to the router or Internet
service, a wired or wireless Internet connection. Plugged into the
lock server is a remote control unit that communicates wirelessly
with the lock.
[0045] 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.
[0046] 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. Along with this, a
lock with an associated key pad can relay the key pad command
signals to the remote which are in turn passed through the lock
server to web service to authenticate a user without a personal
electronic device.
[0047] FIG. 5 presents an alternate embodiment of the components
presented in FIG. 4. Here the lock server is instead connected to a
relay control circuit (501) through a connector such as USB (500).
Commands can be sent through the connector to direct the opening
and closing of an individual or multiple relays. The relay control
circuit can then be connected to a buildings electrical strike
infrastructure in such a manner that the relay can trigger the
release of an electric strike type lock (3402) remotely for a
brief, specified period. The release of the electronic strike on
the jamb allows for a door to be opened and any necessary alarm or
security systems to be temporarily disabled.
[0048] The relay control circuit can control multiple relays,
addressable individually, so that the lock server can address
multiple electric strikes, or alternatively address other devices,
which can be controlled with an electrical relay in conjunction or
isolation such as an alarm system, security system, or other
electrical appliance.
[0049] FIG. 6 demonstrates an electronic device communicating
through the Internet to the web service, which passes requests to
the local lock server. The device may communicate to the Internet
web service through any data connection (600) which would provide
connectivity, including but not limited to Wi-Fi.TM., 3G, EDGE, SMS
and Ethernet.
[0050] FIG. 7 is a flow chart depicting the steps of using Near
Field Communication to lock or unlock a door.
[0051] In 700, the user reads a Near Field Communication tag with
their portable electronic device. The NFC tag is encoded with an
application URI and unique code. Generally a system level interface
will automatically read any sufficiently near tags with system
level protocols. In some instances the device may first have to be
put into a special purpose mode before being able to read an NFC
tag, in such a case the electronic device would first be placed in
a suitable mode to enable the NFC read functionality.
[0052] In 701 the electronic device recognizes the URI file type
descriptor and launches the appropriate application bound to that
type of descriptor. In this case the system launches a special
purpose lock application and passes the application the unique id
associated with the NFC tag just read.
[0053] In 702 the application will notify a web service that it has
read a tag and pass along the associated unique id of that NFC tag.
The web service will authenticate the application in 703 to verify
that the read request came from a valid, signed in account. If the
request is deemed to be invalid, the application will be notified
in 709. If however the request is valid, the web server will pass a
request corresponding to the NFC tag id to a lock server that
corresponds to the NFC tag id in 704. The request could be a lock
request, a timed unlock request, or a toggle request (issue the
opposite request as previously sent.) The lock server could
correspond to one door lock or many.
[0054] In 705 the lock server will receive the request issued in
704 and will initiate the request. If lock server is unreachable
(if for instance, the server does not have a power connection) the
web server will notify the application that the request could not
be performed in 709. If the lock server is reachable, it will parse
the request. If the request was for instance to lock a certain
door, the lock server will issue a command to the hardware device
associated with that door (404) to initiate a lock or unlock
request 706 with the 102 lock. In 707 the 102 lock would actuate.
If the lock actuated successfully, the lock server would notify the
web server which would notify the lock application in 708.
[0055] FIG. 8 demonstrates the advantages of system by enabling
extensive multi-factor authorization through means of Global
Positioning System (GPS) coordinates, Wi-Fi.TM. network
connectivity, Near Field Communication verification, pin code
entry, QR code recognition, and timed entry.
[0056] A user with a smart phone or portable electronic device
(100) can authenticate through a combination of individual
authentication methods.
[0057] A user must be authenticated on a web service (800) in order
to manipulate the lock, as reflected by a cookie that is stored on
the user's browser. The web service in turn can request the state
of the user's session from the cookie and look up associated
information with that user. This session state can then be relayed
to the user, indicating whether or not they need to present
appropriate credentials through the browser in order to manipulate
the lock.
[0058] If requested by a lock owner or administrator, an additional
form of authentication would be a pin code (801) that would be
entered on the phone before every action to manipulate the lock. If
the pin code matches a pin code pre-designated by the user, then
the user would be authenticated either for a single action or for a
set period of time (i.e. five minutes during which any action
against the lock may be executed).
[0059] Any actions by an authenticated user will be relayed to a
local lock web server (802) near the door (on the secured side)
that will in turn trigger either a remote control that wirelessly
transmits commands to the door lock or an electrical relay that is
directly wired into the door lock or strike of the door.
[0060] A passive NFC or RFID (Radio-frequency identification) tag
(808) can be affixed next to the door as a method to request access
to the door. Such a passive tag would still require the user's NFC
or RFID capable electronic device to be authenticated to the web
service. Alternatively, the NFC or RFID unit noted (808) can in
fact be an active reader or writer module that is wired into a
server behind the secure perimeter of the door. In this case, the
electronic device would transmit an encrypted key via NFC or RFID
which would in turn be relayed to the server and compared against
other noted forms of authentication such as an authenticated
session on the user's electronic device to permit access to the
door.
[0061] An additional form of authentication is through
geo-positioning (804) on the electronic device as established by
GPS or similar satellite triangulation (809) on the electronic
device. Latitude and longitude data would be relayed to the web
service which in turn would compare the data against pre-designated
latitude and longitude points that are assigned to the lock. If
these points match within a pre-designated error (i.e. 50 feet
within pre-established coordinates), then the user is assumed to be
authenticated to the lock, assuming other prerequisite forms of
authentication are confirmed as well.
[0062] If the user's electronic device is connected to or detects
the SSID (Service Set Identifier) of a wireless ("Wi-Fi.TM.")
network (805) in the vicinity of the lock, this can act as an
additional form of authentication by establishing that the user is
within a given distance from the lock. Moreover, the user's
electronic device may connect directly to the server (802),
bypassing any web services in cases where they are unavailable,
thus allowing for authentication in "offline" situations.
[0063] An additional form of authentication would be to request the
user to photograph (806) either a static or dynamic QR code (808)
next to the door through their electronic device. Such a QR code
could be printed on top of a passive or active NFC or RFID tag or
reader, or it could be shown on a display. In the case of a static
QR code, the door lock would be identified and a command would be
carried against the lock assuming that the user is also
authenticated by another method such as a session with the web
service. In the case of a dynamic QR code, the code could rotate to
a unique code at a pre-designated interval, thus confirming the
time at which the user took the photo as well as their presence by
the specific QR code display and as such acting as a form of
authentication.
[0064] Depending on the combination of authentication methods
required by a lock administrator, the door (807) would enable the
end user to carry out manipulations depending on the success of
those authentication attempts. A non-limiting example of this would
be the requirement that the user confirms their location through
geo-location (804), is authenticated by a cookie through a web
service accessed by their phone (800) and successfully enters a pin
code that they have pre-designated (801).
[0065] FIG. 9 demonstrates a scenario where someone who is not
authorized as a user on a lock requests access. The unauthorized
account on the electronic device (900) attempts to read the NFC/QR
code (101) using the methods described previously (103 & 104).
The device will attempt to authenticate with the web service,
however as the device is not authorized the web service will not
unlock the door. The application on the device (901) receives a
response from the web service indicating the user does not have
access to that lock instance and will prompt the unauthorized user
if he or she wishes to request access from the lock's
administrator. If the user of 900 selects "YES", then the lock's
administrator will receive an access request on their electronic
device (100). The administrator may be prompted with the requesting
user's profile information optionally including but not limited to
name, photo, email address, or agency of employment. The
administrator may unlock the door remotely and optionally add the
requester as an authorized user or deny the requestor access.
[0066] FIG. 9 additionally depicts how the service may be used
analogously to a doorbell. Upon a guest scanning a tag (101) the
owner is notified (902) that said guest is requesting access. This
is similar how a guest would normally request entrance to a
property by ringing a doorbell, which would notify the owner that
the guest is at the door. With this service however, the owner
could be notified from anywhere where they have a data connection
to their electronic device. An added benefit is the owner can
unlock the door remotely and log the time which the guest requested
access through the service.
[0067] FIG. 10 demonstrates how the system can be used through the
Simple Message Service (SMS) or text message service.
[0068] An invited user sends a text message with a pin code (1001)
that they have either pre-selected or that has been pre-assigned to
them to a pre-designated phone number. Along with this pin code,
the user sends a command to the web service to change the state of
the lock, such as the command to unlock.
[0069] The cell phone provider receives the text message (1000) and
relays its contents to the web service along with the phone number
of the user's phone (100). The web service verifies the users phone
number along with the given pin code to authenticate the user for
the single action that they wish to carry out against the lock.
[0070] If the web service successfully authenticated the user and
interprets their command, then it relays the signal to the
electronic door lock (102), which carries out the appropriate
command such as locking or unlocking.
[0071] FIG. 11 depicts a wireless key device or fob (1102)
containing a unique, identifying, digital signature that may come
in the form of cryptographic public/private key pair,
private/private key pair, unique serial number, unique Media Access
Control (MAC) address or equivalent permutation. A web service
(1100) stores one or more elements of this unique signature (public
key, one half of a private/private key pair, serial number) along
with data indicating which signatures have access to which locking
systems (1101). The web service (1100) relays authenticated
signatures to the appropriate locking system (1101) either directly
or through indirect means such as a mobile phone, electronic base
station, or other communication methods between web service and
locking system described elsewhere in the patent body.
[0072] When a wireless key device (1102) issues a command to the
locking system (1101), the locking system first checks to see if
the wireless key device's signature is authorized to issue the
corresponding command by looking up the unique signature associated
with the device (1102) in a local memory store, or by attempting to
communicate with the web service before processing the request.
Commands may be restricted to finer levels of granularity such as
date, time, schedule, proximity, wireless signal strength, or other
attributes that are communicated between key device, locking system
and/or web service (1100). All commands issued by the wireless key
device (1102) may be logged and stored on the locking system and/or
relayed to the web service. Commands and devices which have not
been authorized to use the lock system will not be executed but the
issuance of these commands may be relayed to other authorized
electronic devices through the web service so lock system
administrators are aware a wireless key device which has not been
authorized to use the lock system is attempting to use the lock
system. Administrators may respond by granting authorization to the
wireless key device (1102) dynamically.
[0073] In addition to communicating directly with the locking
system, wireless key devices may communicate with intermediary
devices which may communicate directly with the locking system
(1101), web service (1100), or each other to provide equivalent
functionality, to boost range, provide enhanced proximity
detection, provide alternative command issuance, or relay
additional information concerning the locking system state, device
presence, or ambient data.
[0074] FIG. 12 depicts a mobile device (1200) device containing
both low and high powered radios that communicate through cellular,
wired, or wireless internet protocols to securely relay data
between a web service (1201) and a locking system (1202).
[0075] In an example embodiment, the web service (1201) establishes
an encrypted communications system using codes, encryptions or
secrets known only to the web service and locking system (1202) and
chooses to route these communications through a mobile device
(1200). The messages may contain unencrypted routing information,
encrypted routing information which only the mobile device may
decrypt and encrypted data which only the locking system may
decrypt. The mobile device (1200) may not be able to inspect the
data transmitted to the locking system from the web service (1201)
due to its encryption but may still pass along the data to the
appropriate locking system (1202) using additional routing
information transmitted to the mobile device. The encrypted data
transmitted to the locking system (1202) may contain commands to
lock, unlock or otherwise activate the locking system, read the
locking systems status including battery life, authenticate the
mobile device onto the lock, authenticating other devices onto the
locking system, update the locking system firmware, or read access
log data. The data transmitted to the mobile device (1200) may
contain routing information, including but not limited to unique
signature data associated with the locking system (1202) and web
service (1201).
[0076] In an example embodiment, the mobile device (1200) uses its
wired or high-powered radios to communicate to the web service
(1201) while using its low powered radios to communicate with the
locking system (1202). Both high powered and low powered
communication channels may have additional encryption decipherable
by a combination of the initiating, intermediary, and/or terminal
devices.
[0077] In the example embodiment depicted in FIG. 13, when a user
approaches the lock system (1300), they trigger an infrared, sound,
radio or vibration sensor. The sensor consumes significantly less
power that the radio transmission device required to communicate
with a web service (1301) over protocols that may include but are
not limited to TCP(Transmission Control Protocol)/IP (Internet
Protocol)/UDP (User Datagram Protocol), HTTP (Hypertext Transfer
Protocol), HTTPS (Hypertext Transfer Protocol Secure) and SSH
(Secure Shell). This in turn will nearly instantly wake up the
higher power consuming components of the system (1300) not already
in use by the sensor.
[0078] Once the locking system (1300) is awake and in a state where
it may receive commands, it may either request status change
commands from the web service (1301) or process queued commands
from the web service directed at itself, such as Short Message
Service commands sent to the web service to be relayed to the
locking system.
[0079] Higher powered radio devices in a portable electronic device
(1302) requesting status information from the web service (1301)
will receive updated locking system status at this point.
Alternatively, the high powered radio device may search for other
compatible radio devices within range.
[0080] The proximate user may send a lock, unlock or status request
command either directly to the now radio-enabled lock system (1300)
directly, or route requests through the web service (1301) which in
turn relays commands to the lock system. This significantly extends
the battery life of the locking system (1300) as well as preserves
bandwidth.
[0081] In FIG. 14 a mobile device (1400) may include a number of
radios, notably those related for long distance communications such
as cellular or satellite. It may send commands to or request the
status of a locking system (1401) remotely through its cellular or
satellite connection to a web service that in turn relays the
commands or requests through another cellular or satellite
connection (1402) to the locking system.
[0082] The locking system (1401) runs a high-powered radio
connection intermittently so as to extend the life of any
electricity storage devices, potentially several orders of
magnitude depending on energy saving techniques used. The
high-powered radio connection may include but is not limited to
cellular or satellite communications. The method by which the
locking system (1401) activates the high-powered radio connection
to send status and request commands may include detection of
proximity of another powered radio such as those contained in
mobile devices.
[0083] In an example embodiment depicted in FIG. 15, the locking
system (1500) may register a knocking or door closing event through
the addition of a vibration sensor. This data may be used to "wake"
the lock from a low power state to a higher powered state whereby
it would communicate with a web service (1501) or mobile device
(13402) directly in order to indicate the knock or vibration. The
sensor may be tuned so as to distinguish between the types of
repetitive motion that would indicate a knock as opposed to the
door closing or opening.
[0084] The web service (1501) may relay the data through any range
of data interfaces to mobile devices to indicate the presence of
someone at the door, a lock operation or a door close or open
event. The web service may also use the opportunity of a
higher-powered state device to relay information back to the device
such as previous lock or unlock commands issued locally as well as
receive lock status information from the lock system (1500).
[0085] 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. If the person knocking on the door
is known, the notification might also contain data about who is
knocking on the door such as unique signature data like MAC
addresses associated with mobile devices attached to persons
knocking at the door or a unique knock sequence.
[0086] This disclosure includes various ways to detect whether or
not a user is proximate to a locking system. In various example
embodiments, this may include detection of a locking or unlocking
operation, an alarm, or the presence of an internet-connected
device, and may further include granting appropriate access to a
user for that locking system. The broad objectives of the
proximity-based features of the locking system include detecting a
person and/or granting them access to control some resource,
whether an electronic lock, internet connected tea kettle, for
example, or some other device, or taking control of a device, or
identifying the user of a device. Reference to "locking system" is
intended to include such devices.
[0087] FIG. 16 depicts a (locking system) (1601) which detects the
presence of a user through a number of methods. A user may be
granted the ability to issue a range of commands on the locking
system (1601) using a web service issuing remote commands to the
locking system, or for example an internal data store on the
locking system which notes whether or not the user is appropriately
authenticated.
[0088] The authenticated user's commands that they may send while
present may be constrained, including the specific commands that
may be sent, the data that may be requested from the system as well
potential constraints based on time and schedule. The locking
system (1601) may detect the presence of a user or person which
relays the fact of this presence either directly or indirectly
through a locking system web service (1602) to an authenticated
user with appropriate access via a portable electronic device
(1603) on the locking system, such as an administrator.
[0089] Detection of the user may be made through specific radio
technology on a mobile device or electronic credential (1600) that
may communicate directly with the locking system (1601) or may be
detected passively by the locking system (1601) on the user's
approach. Depending on whether or not the user is approaching the
locking system or moving away from it, the system may send
differing notifications to the locking system web service (1602)
and, in an example embodiment, directly or indirectly to interested
authenticated users. The locking system (1601) may also
automatically trigger different commands depending on whether or
not the user is detected to be approaching or moving away from the
locking system such as unlocking or disarming on approach or
locking and arming on moving away. Similarly the concept of
granting access to the user based on their electronic credential or
mobile device (1600) may be extended to any appropriately enabled
device such as but not limited to appliances, vehicles,
electronics, industrial systems, security systems, access control
systems, computers and other devices.
[0090] The approaching user device or credential (1600) may be
notified of any commands for which they have access to on the
device if they are so authenticated. The presence of a person may
also be detected through the use of technology including but not
limited to passive or active infrared sensors, radio signature
detection, motion on cameras, specific sounds on microphones, light
sensors, accelerometers as well as any appropriate form of motion
detection. Depending on the sophistication of any of these sensors
as well as the presence of an electronic credential, authenticated
users may be alerted of a specific person's presence similar to the
fashion described above.
[0091] A mobile device (1600) that enters the proximity of the
presence-detecting locking system (1601) may receive a notification
as to the ability to request access to the system from that that
device so as to send and receive commands to and from the device.
If the user is granted access to the device via the locking system
web service (1602), then they may immediately send and receive
commands to and from the device.
[0092] Depending on the radio communication protocol used to detect
presence by the locking system (1601) of the mobile device (1600),
a "pairing" process may be required to ensure secure, encrypted
communication. While the chosen radio standard may offer a variety
of closed pairing methods, open pairing methods may still securely
be used to pair mobile devices with the locking system despite the
absence of physical contact between the mobile device and the
locking system. An open pairing system may allow for all mobile
devices approaching the system with the appropriate mobile
applications and radios to pair with the system, however, preclude
the ability to send and receive any commands to the system beyond
the initial pairing dependent on a pre-shared signature with the
locking system and the mobile device. A web service (1602) to which
the locking system connects may revoke or issue these keys.
[0093] Alternatively, a knock or series of knocks on a closed
pairing system may trigger a secure pairing between a present
device (1600) and the locking system (1601) despite the fact that
the device may be held by a user outside a secured perimeter and
even if the locking system is engaged. If available on the locking
system, a key pad and pin entry may also be used to complete
pairing between the mobile device (1600) and the locking system
(1601).
[0094] FIG. 17 depicts a motion detection system or radio detection
locking system detecting a person (1701) through their mobile
device (1703), electronic credential or infrared signature (1702)
detecting body heat.
[0095] The detector (1702) in turn relays information of the
detection event, including if available information about the
person as garnered from their mobile device or electronic
credential, to the web service (1704). This information may be used
by the web service for a number of purposes including but not
limited to triggering a locking system, arming or disarming an
alarm system for appropriate users or notifying a third-party
application or service so that it may carry out an action.
[0096] If the detector (1702) picks up the radio signal of an
authenticated electronic credential or mobile device (1703), it may
send a different signal than the signal sent from the detection of
person through their infrared signature. This may allow for
seamlessly disabling alarm systems for authenticated users while
triggering them for unknown infrared signatures.
[0097] Restrictions on authenticated users as well as the
authentication of new users may be dictated by the web service
(1704) that is in communication over the internet with the
detector. Specific motions interpreted by sophisticated detectors
such as passive infrared sensors or cameras may also serve to
authenticate users.
[0098] FIG. 18 depicts the presence of a mobile device (1800) to a
locking system (1802) as detected through global positioning
satellites (1801) or other similar technologies that rely on
triangulating a mobile device through the use of other known radio
signals.
[0099] In turn the mobile device (1800) may automatically select
the closest locking system (1802) available so that the user may
instantly send commands to that locking system upon activating the
mobile device and, potentially, an application dedicated to
controlling the locking system (1802) on the mobile device
(1800).
[0100] The mobile device (1800) may store information as to how it
selects the locking system (1802) based on a variety of methods.
The mobile device may receive the coordinates of the locking system
upon enrollment of the mobile device or the authentication of an
authenticated user of the mobile device. The coordinates may be
determined by the locking device itself through a number of means,
including but not limited to GPS, Wi-Fi.TM., cellular signals or IP
address lookup. Alternatively, the associated locking system (1802)
on the mobile device (1800) may request the user to manually input
a trigger location for the application. This trigger may occur the
first time that a command is sent to the locking system such as
during its initial registration or after a certain number of
commands have been detected to have been sent from a specific
location. Location trigger coordinates may be stored locally on the
mobile device as well as additionally sent to an associated locking
system web service that in turn relays the data to other
authenticated clients so they may avoid any initial set up.
[0101] The authenticated user may be limited in their ability to
send commands to the locking system based on their detected
location for security purposes. Administrators of the locking
system may wish to limit commands to the locking system to a
certain proximity at which a user is determined to be present to
the locking system, incorporating some or no margins of error
depending on the ability to pin-point the mobile device coordinates
and the confidence in those coordinates. Multiple location factors
may be used to achieve more accurate location information.
[0102] Depending on the preferences of locking system
administrators, some locking systems may be public to all users
executing the appropriate mobile application within a certain
proximity range of the locking system. This allows users to request
access through the locking system web service to send or receive
commands from the locking system.
[0103] The locking system may use the ability to establish
bidirectional communications between itself and a mobile device as
another proxy for the presence of a user. A locking system may have
the constraints set dynamically on certain users that their
authenticated mobile device must be connected to a specific
Wi-Fi.TM. network so as to execute locking commands. The connection
through a technology such as Wi-Fi.TM. may be direct to the locking
system, through a shared internal network or through a different
network that has been pre-established on the locking system.
[0104] FIG. 19 depicts a locking system (1901) that is triggered by
a mobile device (1900) which has entered the proximity of the
locking system. Proximity to the locking system of the mobile
device may be determined by a number of methods as described
above.
[0105] On a mobile device (1900) having the ability to execute
applications without the user's explicit intervention, it may be
possible to send notifications from the lower level operating
system to the attention of the user on the approach of a
pre-defined "geo-fence". In an example embodiment, a geo-fence is a
virtual perimeter for a real-world geographic area. A geo-fence
could be dynamically generated, as in a radius around a store or
point location. Or a geo-fence can be a predefined set of
boundaries, like access-restricted zones or property boundaries.
User-defined geo-fences may also be in use. When the location-aware
device of a location-based service (LBS) user enters or exits a
geo-fence, the device may receive a generated notification which
may be used to launch a special purpose application to operate the
lock system or otherwise generate an event. The lower level
operating system may designate the geo-fence or it may relay the
necessary data of the geo-fence to a specified locking system
mobile application. Depending on the lower level operating system,
the locking system mobile application may or may not have the
ability to automatically send a radio request directly to the
locking system or to a web service associated with the locking
system to trigger a command.
[0106] In the case where the lower level operating system hinders
or precludes the ability of the mobile application to send a radio
command, a notification of proximity to the locking system may be
relayed to the user. In turn, acknowledgement of this notification
through a pre-designated action by the system such as a swipe may
be used to launch the locking system mobile application and trigger
a specific command. Depending on the lower level operating system
and user preferences, a pin code or other authentication action may
need to be taken to carry out the command after a gesture or
command is made on the mobile device.
[0107] If the user is appropriately authenticated and has
appropriate access to carry out commands on the lock, then their
command may be immediately carried out upon launch of the mobile
application from a notification-triggered action due to the fact
that the lower level operating system allows access to send radio
commands either directly or indirectly to the locking system.
[0108] The same premise may be used to arm or disarm alarm systems.
Triggers for different commands such as lock or unlock or arm or
disarm may be sent to the locking system depending on whether or
not the user is detected to be moving towards or away from the
locking system. The information as to whether or not the mobile
device leaves or enters the geo-fence may be handled by the lower
level operating system. The message relayed to the user of the
mobile device in the form of a notification may be dynamic
depending on direction of the user towards or away from the locking
system as well as the user's last known authentication and access
states.
[0109] The locking system mobile application may immediately carry
out a command upon being loaded by the user from the notification.
The user may be directed to a dashboard where they may send or
receive other commands to or from the system.
[0110] Proximity to the locking system by appropriately enabled
third-party devices or electronic credentials may also be
registered in the same fashion as described above. These
third-party devices may include but are not limited to
radio-enabled phones, computers, watches, tablets, personal digital
assistants and other electronic credentials. They would convey the
presence of known or unknown users proximate to the locking system
and would potentially be authenticated in the same way as a mobile
device to send commands to the locking system. Authentication of a
third-party device may originate from the locking system web
service.
[0111] Although the primary operation of the locking system may be
in relation to an internet connection so that it may interact with
a web service that authenticates and revokes access to appropriate
users, it may also function in an offline function whereby it
communicates directly with an electronic credential or mobile
device.
[0112] In the case of offline operation, a proximate mobile device
or electronic credential would be authenticated directly on logic
directly within the locking system, not merely on an associated web
service. If disconnected from the web service the locking system
would still be able to authenticate and accept commands from
authenticated users (their mobile devices and electronic
credentials). Schedules, time limits and other restrictions not
reliant on a live connection to the web service would also still be
adhered to by the locking system.
[0113] The present disclosure includes systems and methods for
allowing third party systems to access a locking system, send and
receive commands. The third-party system will typically need to be
authenticated by a user with sufficient powers (i.e. administrator,
owner) to authenticate the third party system. That authentication
may be revoked or restricted at any time. Additionally, access may
be granted directly to third-party devices which may connect
directly to the locking system to control it. This facility extends
to security/alarm systems as well.
[0114] FIG. 20 discloses a third party service which has triggered
a request to access the resources available on the locking (or
security/detection) system (2004). The request from the third party
(or requesting) system (2000) may be sent from third party
software, originating either directly or indirectly from the third
party web service. The request will typically contain information
about the locking system (2004) or an associated user granted
access on that system sufficient to directly or indirectly instruct
the granting web service (2001) of the access the third party
requires. An indirect request from the requesting web service may
originate from web or mobile application (2003) that is hosted by
the third party service, or another application which in turn has
been granted authentication to make such requests.
[0115] In an example embodiment, the request from a third party
system to access the resources and in turn control the locking
system (2004) requires approval from an authenticated user (2002)
who has been granted appropriate permissions on the locking system.
The locking system web service (2001) may enumerate available
commands dependent on the authentication of the requesting user. If
appropriate authentication is met in order to grant the third party
system access to the system then this access may be constrained or
unlimited in scope, not limited to but including constraints such
as time of request, quantity of requests, frequency of requests,
format of request and commands available to be requested.
[0116] Once authentication is established for the third party
system, a user of the third party system who in turn has sufficient
authentication may seamlessly send and receive data from the
locking system such as lock or unlock commands and locking system
requests.
[0117] 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.
[0118] Previously authenticated third-party services may have their
access revoked on a number of factors, namely those relating to
cancellation of their access by an authenticated user or abuse of
the system such as sending an excessive number of commands or
attempting to falsify commands. Third party services may be
identified by a number of factors including but not limited to
application keys, IP addresses, MAC addresses and user agent
strings.
[0119] FIG. 21 demonstrates an alternate example embodiment whereby
an electronic credential or wireless remote (2102) is
pre-authenticated to send and receive commands from a locking
system (2104). The locking system web service and third party web
service (shown together at 2101) communicate with the client
third-party applications (2103) receiving and sending commands to
pre-authenticate the electronic credential. "Pre-authenticate" is
the process of instructing the locking system to execute commands
sent from an offline electronic credential based on a unique
identifier or rolling token that is specific to that offline
electronic credential.
[0120] The third-party client application may automatically request
access on behalf of the electronic credential based on the trigger
of an outside event such as booking a room for use at a certain
time (see screen in 2103). The electronic credential may be
entirely disconnected and offline from the locking and third-party
web services, however, it would still be able to issue
authenticated commands to the locking system (2104) if the system
has been informed of the electronic credential's unique identifier.
The electronic identifier may trigger an action with the locking
system either through direct input by the user or through indirect
input such as coming into proximity with the system, where
proximity is the greatest range at which the electronic credential
may communicate successfully with the locking system.
[0121] An electronic credential may include but is not limited to a
simple key fob style remote control or a mobile phone that carries
on it the same unique radio signature. The same features such as
detection at proximity to carry out commands or direct commands
from the user would apply. In addition, an internet connected
device emulating a simple offline electronic credential may also
relay additional data to or from the locking system.
[0122] FIG. 22 discloses another example embodiment whereby a newly
authenticated user (2201) receives a message confirming their
registration via a communication such as but not limited to a text
message, an email, a push notification or a third-party application
notification informing the user of a pin code that allows the user
access to a locking system (2204). If entered properly on a keypad
(not shown) on the locking system, the pin code may grant access to
a number of functions, including but not limited to locking or
unlocking the locking system (2204). In the case where a third
party application (2202) has already been authorized to send
communications to the locking system (2204), clients to the
third-party system may handle all communication to end users in
order to convey information about the lock system as well as the
ability to send commands through to it. 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.
[0123] Depending on the authentication conveyed to the third party
service, the pin code may be relayed from the locking system
service to the third-party service so that it may be conveyed to
the end user. The pin code may be configured in a number fashions.
The user may be required to enter a user specific pin code along
with by a lock system specific pin code. Alternatively, the user
may be granted a unique pin code for each lock system, where
uniqueness is determined by requirements of the length of the pin
code in terms of the total key space of pin codes.
[0124] Each time a granted user (2201) enters the pin code into a
locking system where they have been granted access (2204), the
entry of the pin code and any commands sent may be relayed by web
service (2202) to the locking system (2204). If the issuing user
(2203) directly or indirectly removes the granted user (2201) from
the locking system or carries out an action that would remove the
granted user from the locking system through the third-party
service, the granted user's pin will be invalidated. An example of
this includes the cancellation of a granted user's booking of a
space for a specified time.
[0125] FIG. 23 depicts a dashboard component that may be shown by a
third-party booking service which is authenticated to act on behalf
of a sufficiently authenticated user on the locking system. In this
scenario, a potential guest (2300) requests to book a space from
the host booking out the space (2301). The third-party system may
allow for internal messaging (2302) between potential guests and
hosts. Upon the agreement of a booking time, the third-party system
may automatically request access from the locking system for the
guest, issuing the guest access to control the locking system for
the time specified by the booking.
[0126] The third-party system may automatically message the guest
the information required to access the locking system. Depending on
the locking system, this may include a pin code (as shown in 2301)
or a link that allows for setting up the locking system on a mobile
application. Alternatively, the third-party system may request the
locking system to authenticate an electronic credential to access
the system similar to the process described above.
[0127] The third-party system may incorporate locking system
controls directly into its dashboard component (2303) which allows
the guest to modify their unique pin code (if granted) or to send
locking system commands during the period of time and on the
schedule which they have permitted.
[0128] Third party devices may interact directly with the locking
system if they have been granted an appropriate unique identifier.
The third-party device communicates directly with the locking
system to send the command. The third-party device will typically
first be pre-authenticated to send commands to the locking system
in the same fashion as described above. This may mean that a unique
identifier in the locking system or locking system web service is
used to enable access to the for the third party device.
[0129] When the unique identifier is either relayed to the locking
system, a derived rolling token is relayed or the device detected
via an encrypted proximity signal from the third-party device, the
locking system is triggered. The ability for the third-party device
to send commands to the locking system may be constrained or
limited by various schedule and timing constraints. The third-party
device's authentication to use the locking system may be revoked or
re-enabled at any time dependent on commands send to the locking
system from the locking system web service or a third-party web
service.
[0130] In using any third-party service or device to communicate
with the locking system and locking system web service (if so
configured), security is of the utmost consideration. The
communication channels between the locking system web service and
third-party web service may be required to be in an encrypted form,
including but not limited to standards such as SSL, SSH, AES or
other public or proprietary encryptions schemes.
[0131] Similarly, direct communications between the locking system
and electronic credentials or third-party devices may be encrypted
through various standards such as those incorporated by
technologies including Bluetooth.TM. Bluetooth.TM. Low Energy, Near
Field Communications, MiFare.TM., Felica.TM. (Felicity Card),
Wi-Fi.TM., WEP (Wired Equivalent Privacy), WPA (Wi-Fi.TM. Protected
Access), WPA PSK (Pre-shared key), and others. MiFare is the NXP
Semiconductors-owned trademark of a series of chips widely used in
contactless smart cards and proximity cards. Custom encryption
standards may optionally be used in place of other encryption
technologies or may be layered upon those technologies for
additional security.
[0132] FIG. 24 depicts a web service dashboard (2400) which conveys
the ability for administrative users to send and receive commands
from a locking system, as well as invite other users to the system
(2403), view any cached or live data about the locking system or
its state and identify current users on the system (2402) as well
as their activities on the locking system. This dashboard may be
available in a variety of formats scaled for different applications
including but not limited to a traditional desktop browser
interface, a mobile phone interface, tablet phone interface or
third-party interface. Depending on the privileges granted to the
user viewing the dashboard, different information may be conveyed
to the user. For instance, certain users may have variations on the
ability to create, modify, manage and revoke access for other users
as well as the ability to view logging information.
[0133] The web service dashboard (2400) may allow for the entry of
additional identifying information for the user that may be used as
an authentication token either in the form of a pin code that is
entered directly in the door, a pin code that is used for text
messaging a pre-designated phone number to send commands to the
door, a pin code that is used for either purpose or any other
serial number or secret token information that relates to an
offline electronic credential such as a key card or key fob.
[0134] Information about other users (where user is a proxy for
person on the system) (2402) may include identifiers such as but
not limited to photos of the person, the person's names, aliases,
email addresses, phone numbers, status on the web service, status
on the locking system, associated privileges. The ability to issue,
modify or revoke a virtual credential to other users may also be
shown and managed through this system.
[0135] New virtual credentials may be issued (2403) by a variety of
communication protocols including but not limited to email, phone
call, text messaging, application interfaces or third party
messaging. These credentials may be granted for various scopes of
time and location, not limited to but including time schedules,
start and expiration times, specific locations as determined by
geo-data, specific locations as determined by proximity through
powered or unpowered radio, single or multiple usages and may
require multiple types of authentication to be used by the person
to whom they are granted. The field in which the virtual credential
is entered may automatically populate with identifiers such as but
not limited to names, emails, photos, aliases and or phone numbers
of users already registered to the system or associated from
another third party system as the inviting user types in the field
and letters are matched with the identifier dynamically. The field
may optionally be extended to enter multiple identifiers for
various people so as to invite multiple users at the same time with
the same type of credential or optionally varying types of
credential depending on a requested algorithm, i.e. incrementing or
decrementing.
[0136] FIG. 25 discloses a logging panel as viewed by an
authenticated user through a web, mobile, tablet or other browser
interface. The web service associated with the locking system may
record a range of information including that relating to
information sent and received to and from the locking system as
well as physical changes to the locking system, non-authenticated
users attempting to access the locking system, events specific to
the web service itself or third-party web services relating to or
authenticated on the web service or locking system.
[0137] Actions carried out by users may be conveyed along with
information (2500) such as but not limited to names, aliases, date
and time of access, whether or not the virtual key was valid at the
time the attempt to access the locking system was made, the desired
action, proximity to the location, network location and type, geo
location information, outcome and the method used whether the
virtual key is from a mobile device, radio token, key pad, web
interface, application interface or 3rd party application.
[0138] Any data relating to the locking system that is recorded by
the locking system or associated web service or both may be
conveyed on a map (2501) which may note the position of the locking
system or the position of any data transmission sent or received
from the locking system or web service. This may indicate whether
or not a user was proximate to a locking system at the time they
sent a command to the locking system. If the authenticated user has
appropriate access to multiple locking systems, their coordinates
may all be indicated on a single map.
[0139] The web service may convey graphs (23402) that indicate the
frequency of locking events over time on a specific locking system.
The user may have the ability to filter these events including but
not limited to individual user actions over time, specific types of
actions over time (i.e. number of unlock events on May 1st, 2011),
comparing to types of log entries over time (i.e. number of lock
events from a mobile device vs. number of lock events from the
locking system key pad from Apr. 1st, 2011 12:00 pm to May 1st 1:00
pm).
[0140] The recorded events may include geo-location coordinate
information about the origin of the command at the time the command
was sent by a user. This information may be inferred either
directly from geo-location coordinate information (2503) encoded
directly in the request or indirectly by IP address lookup
techniques. Mobile clients, web clients, third-party clients, fixed
key pads and readers may be required to send geo-location
information to the web service in order to successfully execute
commands.
[0141] FIG. 26 discloses an example embodiment allowing the initial
set up of a locking system to be simplified so that a new user may
quickly connect the locking system to a corresponding web service
or pair the locking system with their compatible electronic device
(such as a mobile device, tablet device, laptop computer, desktop
computer, personal digital assistant or third-party device)
directly.
[0142] An application corresponding to the locking system is used
on the mobile device (2600) which communicates with both the
associated web service (2602) as well as the locking system (2601)
so that it may confer the initial pairing between the new user and
the locking system. This initial pairing may request certain
identifying information from the new user in order to authenticate
them on the locking system such as but not limited to their names,
aliases, email addresses, phone numbers and photo. Other
identifying information that automatically be sent to the web
service during the initial registration may include but is not
limited to geo-location information, IP address information,
cellular network information if available and information about the
mobile device upon which the application is running.
[0143] The locking system may be connected directly through a wired
connection (2601) to the mobile device (2600) through a common
interface such as an audio or serial bus connection. The locking
system will receive programming commands from the mobile device,
including but not limited to instructions on how to connect to a
web service, as well as any necessary authentication keys to
connect to local or wide array networks or to create a pairing with
the mobile device itself.
[0144] The completion of the pairing process may preclude other
mobile devices from carry out the same pairing process, as either
dictated by logic directly on the locking system or on the
associated web service. The initial user may allow requests by
other mobile devices to pair with the locking system and these
requests may be logged or facilitated by the web service. Physical
interfaces on the locking system such as key pads, buttons and
other sensors may be used to reset the locking system so that it
may be associated freely with mobile devices. These interfaces may
require the entry of a specific code or pattern of binary inputs in
order to reset the device to a new pairing mode. Information about
any reset event may be conveyed to the associated web service first
and may trigger notifications or other events on the web
service.
[0145] FIG. 27 discloses in an example embodiment a direct
connection between a mobile device (2701) and locking system (2702)
which may include both send and receive capabilities so that
applications running on both devices may convey a range of
programming, status and command information. This connection may be
manifested as an audio, sound or microphone jack of varying
dimensions such as those common on mobile devices. The connection
may be used for the purpose of the initial set up and pairing of
the locking system with available mobile devices and networks,
programming the locking system, resetting the locking system,
sending commands to the locking system as well as receiving status
from the locking system. These may include instructions for an
initial secured connection to wireless network, whether WAN (Wide
Area Network), LAN (Local Area Network) or ad-hoc. The data may be
transmitted in an encrypted or unencrypted fashion.
[0146] After the initial connection or programming event with the
locking system it may bind itself to the mobile device via unique
identifiers so that no other device may access the same programming
functionality unless permission is first explicitly granted by an
application either on the original programming mobile device or web
service.
[0147] FIG. 28 discloses a locking system which is limited either
by the amount of current it can draw at any single point in time or
its ability to draw current continuously over time. This may be due
to the fact that the locking system draws energy from batteries and
with the intent of being usable over a long period of time or
because it is partially powered by an energy harvesting or trickle
charge system.
[0148] The energy for the locking system may be stored by any type
of energy storage technology (2800) which meets the physical
constraints of the locking system including but not limited to
capacitive devices, various batteries of varying chemistries or
mechanical energy storage. Appropriate circuitry associated with
the energy storage technology would ensure that potentially
damaging erratic currents and voltages would be brought to safe
levels before being stored or utilized in the rest of the locking
system.
[0149] Power for the locking system may be generated and captured
from the rotation of a thumb-turn (2801) on the interior of the
locking system or a similar locking system leverage point that
rotates around a fixed spindle that may turn through a magnetic
field to generate current (2804). Any number of mechanical
interactions with the locking system may be used to capture energy
which in turn would be used in the locking system or stored in the
energy storage technology (2800). These also include harvesting
energy from vibrations (2802) to the locking system that may result
from shutting or opening a component related to the locking system.
Power for the locking system may also be generated and captured
from a photovoltaic or other light capture energy conversion device
placed either on the interior or exterior of the device (2803).
[0150] FIG. 29 discloses in an example embodiment a number of
methods by which a locking system (2902) may lower its power
consumption so as to extend battery or energy storage lifetime.
These methods include logic inherent to the locking system (2900)
which would activate the most power consuming aspects of the
locking system only at those points in time during the day when the
locking system is likely to be used.
[0151] Such logic may be considered as an algorithm that considers
the most frequent times of day that a locking system (2902) is used
or has been used in the past (2900). When it is calculated that
there is a negligible or nil chance of an event being sent to the
locking system the logic would disable the most power intensive
components such as radios, microcontrollers, power regulators and
other components. The algorithm may shift the schedule as the
locking system logs access data from usage and passes this as a
parameter into the algorithm. 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.
[0152] A mobile device (2901) may generate certain radio signatures
which are detectable by specialized low-power consumption circuitry
on the locking system (2902). Examples of this include
distinguishable signatures from GSM.TM. (Global System for Mobile
Communications), CDMA (Code-Division Multiple Access), Wi-Fi.TM.,
Bluetooth.TM. or other radio technologies which are commonly
available on mobile devices. The low-power consumption circuitry
would not be intended to communicate directly with the radios on
the mobile device, but instead would merely detect their existence
so as to power up additional components such as microcontrollers,
radios and power regulators that would consume far more current
when powered on. The user would then be able to successfully send
or receive data to or from the locking system, either directly or
indirectly through a web service, while the locking system would
only need to consume significant amounts of power when a mobile
device has been detected to be proximate to the locking system.
[0153] Other very low power consumption components in the locking
system (2902) may be used to alert the system of the presence of a
user so that other high power consumption components may be
activated at the proper time. Very low power components may include
vibration sensors, passive infrared sensors, microphones or sensors
external to the locking system which communicate with the locking
system over a very low power radio component while high power radio
components remain in a deep sleep or powered down mode.
[0154] FIG. 30 discloses a locking system which has been modified
to accommodate the use of mobile devices and control through web
services while still maintaining the original structure of access
control. The locking system relies on commonly known and understood
access control technologies that consist of a computer controller
(3003) which regulates whether or not passive radio credentials
(3000) may lock, unlock, arm or disarm the locking or alarm system
(3002) when scanned at a connected electronic credential reader
(3001).
[0155] A traditional access control system may be modified so as to
replace or augment the existing electronic credential reader with a
microcomputer which may communicate directly with a mobile device
or with a web service. The augmenting or replacement reading device
(3001) may detect or read from a data connection the information
from the passive electronic credential. This data signature may be
sent in an encrypted or unencrypted fashion as in the case with
standards such as the commonly used Wiegand technology. If
encrypted, the device may use commonly exposed or known private
keys to decrypt the associated data. The device may act to replay
the data so as to emulate the passive radio credential. The
emulation of the credential would be seamless to the rest of the
locking system and notably the original computer controller
(3003).
[0156] In conjunction with the mobile device (3005) and associated
web service (3004), users who already possess radio tokens for the
original service may present their token at the newly augmented or
replacement reader device (3001) so as to pair their credential
with their user account. Once paired, the user from a mobile device
may send a command such as lock or unlock through an application on
the mobile device which in turn is relayed directly to the
augmented reading device or indirectly through an associated web
service. The augmenting reading device would replay the associated
radio token data to the original locking system controller,
emulating the user holding the original radio token next to the
reader.
[0157] Once paired, the user may send commands through the mobile
interface, web interface, text-message interface or authenticated
third-party applications. All of these commands would be ultimately
executed according to the original access control computer system
(3003), allowing the computer controller to maintain the exactly
same programming, logging and other capabilities present with the
usage of radio tokens. If the computer controller were to reject
the emulated token, this fact could be relayed to the web service
or mobile user through a variety of methods.
[0158] By preserving the existing infrastructure, the new web
service and mobile enabled infrastructure may easily and quickly
installed while maintaining all programming related to the original
computer controller. The web service (3004) may additionally
communicate directly with the computer controller (3003) in order
to bypass the need for augmenting the reader component (3001). The
augmented reader component may feature any range of proximity
detection technology including those radios which communicate
directly with common mobile device radios like Bluetooth.TM.,
Wi-Fi.TM. or Near Field Communication.
Method Embodiments
[0159] Some embodiments of the present inventive subject matter
include methods of operating a remotely operable lock.
[0160] One such embodiment is illustrated in FIGS. 31-31G. In the
example embodiment shown in FIG. 31, a method of operating a
remotely operable lock comprises: at 3100, receiving credentials at
a web service from a portable electronic device; at 3102,
authenticating the credentials; and at 3104 based on a successful
authentication, issuing a command for receipt by the lock from the
web service.
[0161] In FIG. 31, the method may at 3122 further comprise
notifying a user of the closest geographically nearby operable lock
to the device based on receipt and authentication of the
credentials, the geographically nearby operable lock being located
within a determinable distance of the device. The method may
further comprise at 3124 detecting proximity of the device to the
lock.
[0162] In FIG. 31, the method of operating a remotely operable lock
may further comprise, at 3152, controlling the lock in response to
a command issued by the web service or portable electronic device
using a lock server in communication with the web service or
portable electronic device. In FIG. 31, the method may further
comprise at 3166 using a remotely operable lock and notifying the
user of successful actuation of the lock in response to the
command.
[0163] In FIG. 31, the method may further comprise at 3190
providing a camera associated with the lock for taking a picture of
a person seeking to operate the lock. At 3192, the method may
further comprise providing a vibration sensor for detecting
vibration of the lock or a door associated with the lock, and
receiving a signal at least initiated by the vibration sensor.
[0164] In FIG. 31, the method may further comprise at 3102A
providing an online account at the web service for a user. In FIG.
31G, the method may further comprise at 3104A providing a portal on
the web service for entry by a user of credentials or a command for
receipt by the lock.
[0165] In FIG. 31A, the receiving of the credentials at a web
service from the portable electronic device 3100 may include at
3106 receiving device credentials relating to the portable
electronic device. The device credentials may include at 3108 at
least one device credential element selected from a group
comprising: GPS coordinates of the device location; a Wi-Fi.TM. ID;
a Bluetooth.TM. ID; a telephone number; SMS address; and pin code.
The device credentials may at 3110 be cached in the device. The
receiving of the credentials at a web service from the portable
electronic device may include at 3112 receiving lock credentials
relating to the lock. At 3114, the lock credentials may include at
least one lock credential element selected from a group comprising:
GPS coordinates of the lock or an identification tag associated
with the lock; Wi-Fi.TM. ID; Bluetooth.TM. ID; Near Field
Communication verification; pin code entry; Quick Response (QR)
code recognition; and a timed lock operation. At 3116, at least
some of the lock credentials may be cached in the portable
electronic device. The cached lock credentials may at 3118 allow at
least partial authorization of the credentials by the device. In
FIG. 31B, authenticating the credentials 3102 may include at 3120
at least some authentication of the credentials being performed by
the web service.
[0166] In FIG. 31A, the method may further comprise at 3198
receiving the credentials from the portable electronic device as a
text (SMS) message. In FIG. 31C, the method may further comprise at
3100A receiving a command as a text (SMS) message from a user's
portable electronic device and basing the command for receipt by
the lock on the texted command.
[0167] In FIG. 31A, the method may further comprise at 3106A
allowing the web service to communicate with the portable
electronic device using one or more of the connectivity elements in
a group comprising: Wi-Fi.TM.; 3G/4G; EDGE (Enhanced Data rates for
GSM Evolution), SMS (Short Message Service); and Ethernet. In FIG.
1, the method may further comprise at 3108A notifying a user of an
attempt or request to operate the lock. In FIG. 31B, the method may
further comprise at 3110A authenticating credentials received from
the user in response to the notification, and receiving a command
from the user to actuate the lock.
[0168] In FIG. 31B, the credentials may include at 3176 a unique
code associated with a user of the portable electronic device. At
3178, a further unique code may be associated with another user of
the lock. At 3180, authenticating the credentials may include use
of one or more of the following elements in a group comprising: GPS
coordinates; detection of a Wi-Fi.TM. network; Near Field
Communication verification; pin code entry; Quick Response (QR)
code recognition; and a timed entry.
[0169] In FIG. 31C, the command issued by the web service for
receipt by the lock 3104 may be based at 3168 on an input received
at the portable electronic device from a user. At 3170, the command
issued by the web service for receipt by the lock may be based on
input provided by the user using a software application installed
on the portable electronic device. At 3172, the command is one of
the commands selected from a group of commands comprising: lock;
unlock; timed lock request; timed unlock request; and toggle
lock/unlock request. At 3174, the command may be associated with a
customized lock operation scenario.
[0170] In FIG. 31C, the method may further comprise at 3182
providing a Wi-Fi.TM. chip in the remotely operable lock for
connectivity with a Wi-Fi.TM. network, and issuing the command for
receipt by the lock at least via the Wi-Fi.TM. network. At 3184,
Bluetooth.TM. connectivity may be provided for the remotely
operable lock, and the command for receipt by the lock is issued at
least via a Bluetooth.TM. connection. At 3186, the method may
further allow pairing of the lock with a web-enabled portable
electronic device, and issuing the command for receipt by the lock
at least via an internet connection established by the web-enabled
portable electronic device. At 3188, the method may further
comprise receiving the credentials or a user command from the
portable electronic device at least via the internet
connection.
[0171] In FIG. 31D, detecting the proximity of the device to the
lock 3124 may include at 3126 use of one or more of the following
elements in a group comprising: reading a tag located proximately
to and associated with the lock; GPS coordinates of the lock; GPS
coordinates of the device; detection of a Wi-Fi.TM. or
Bluetooth.TM. network; Near Field Communication verification; pin
code entry; Quick Response (QR) code recognition; and, a timed lock
operation. At 3128, detecting of the proximity of the device to the
lock may include comparing at least one credential element cached
in the device to a respective credential identified or received by
the device. At 3130, detecting of the proximity of the device to
the lock launches a software application on the device. At 3132,
the method further comprises providing a lock software application,
associated with the web service, for installation on the portable
electronic device. At 3134, the software application is to launch
automatically in response to detecting proximity of the device to
the lock. At 3136, the software application is further to notify
the web service of the proximity of the device to the lock and the
credentials upon launch.
[0172] In FIG. 31D, detecting the proximity of the device to the
lock 3124 may include at 3138 providing a tag located proximately
to and associated with the lock. At 3140, the method may further
comprise receiving a signal that the tag has been read by the
portable electronic device. At 3142, the tag may be a Near Field
Communication (NFC) tag. At 3144, the tag may be encoded with a
software application Universal Resource Indicator (URI). At 3146,
the automatic launch of the software application includes
recognition by the portable electronic device of the Universal
Resource Indicator (URI) encoded in the tag. At 3148, the tag may
be encoded with a unique code, the unique code forming at least
part of the credentials. At 3150, the credentials may be
authenticated by the web service using at least the unique
code.
[0173] In FIG. 31E, placing the lock server in communication with
the web service may, at 3154, allow bidirectional communication
between the lock server and web service. At 3156, the method may
further comprise sending the command to the lock using a wireless
remote unit in communication with the lock server. At 3158, the
method may further comprise sending the command to the lock using a
relay control circuit in communication with the lock server. At
3160, the method may further comprise placing the door lock server
or lock in communication with the web service using a user's
internet service. At 3162, the method may further comprise
notifying a user that the lock server is not in communication with
the web service. At 3164, notifying of the user that the lock
server is not in communication with the web service may occur in
response to a failed receipt by the lock of the command.
[0174] In FIG. 31F, the method may further comprise at 3194
notifying the user of the received signal initiated by the
vibration sensor detecting vibration of the door or lock. Detecting
vibration may at 3196 include detecting a user's special knock on
the lock or door associated with the lock, the special knock
forming part of the credentials.
[0175] Another example method embodiment is illustrated in FIGS.
32-32G.
[0176] In the example embodiment shown in FIG. 32, a method of
operating a remotely operable lock comprises: at 3200,
authenticating, at a web service, credentials received from a
portable electronic device; at 3202, detecting the proximity of the
portable electronic device to the lock; and at 3204, issuing a
command for receipt by the lock from the web service or portable
electronic device.
[0177] In FIG. 32, the method may further comprise at 3232
notifying a user of a lock to select for operation, or the nearest
operable lock, based on the user's geo-location. The method may
further comprise at 3238 providing an application programming
interface (API) for integrating third party software with the web
service to allow an associated portable electronic device to
operate the lock or communicate with the web service.
[0178] In FIG. 32, the method may further comprise at 3262,
allowing the remotely operable lock to connect to a Wi-Fi.TM.
network, RF or radio network, or Bluetooth.TM. device, and issuing
a command for receipt by the lock at least via the Wi-Fi.TM., RF or
radio network, or Bluetooth.TM. device. At 3264, the method may
further comprise allowing pairing of the lock with a web-enabled
portable electronic device, and issuing the command for receipt by
the lock at least via an internet connection established by the
web-enabled portable electronic device.
[0179] In FIG. 32, the method may further comprise at 3268
providing an accessory component in association with the lock, the
component to integrate or communicate with the lock, the web
service or a user to at least assist in operating the lock. In FIG.
32, the method may further comprise at 3280 using a remotely
operable lock and notifying a user of successful actuation of the
lock in response to the command. The method may further comprise at
3290 notifying a first user of an attempt or request to operate the
lock by a second user. At 3292, the method may further comprise
providing an online account at the web service for a user.
[0180] In FIG. 32A (i) the authenticating of the received
credentials 3200 may include at 3206 an initial authentication of
the portable electronic device which allows the portable electronic
device to communicate directly with the lock and issue a direct
command for receipt by the lock. At 3208, at least some credentials
may be cached in the portable electronic device. At 3210, the
cached credentials may allow at least partial authorization of the
credentials by the device. At 3212, a remaining authentication of
the credentials may be performed by the web service. At 3214, the
credentials may include at least one of the following elements in a
group comprising: GPS coordinates; detection of a Wi-Fi.TM.
network; Near Field Communication verification; pin code entry;
Quick Response (QR) code recognition; and a timed entry. At 3216,
the received credentials may include device credentials relating to
the portable electronic device. At 3218, the received device
credentials may include at least one device credential element
selected from a group comprising: GPS coordinates of the device
location; a Wi-Fi.TM. ID; a Bluetooth.TM. ID; a telephone number;
SMS address; and pin code. At 3220, the received credentials may
include lock credentials relating to the lock. At 3222, the lock
credentials may include at least one lock credential element
selected from a group comprising: GPS coordinates of the lock or an
identification tag associated with the lock; Wi-Fi.TM. ID;
Bluetooth.TM. ID; Near Field Communication verification; pin code
entry; Quick Response (QR) code recognition; and a timed lock
operation.
[0181] In FIG. 32A (ii), the credentials may include at 3284 a
unique code associated with a user of the portable electronic
device. At 3286, the method may further comprise issuing a further
unique code associated with another user of the lock. At 3288, the
method may further comprise receiving the credentials from the
portable electronic device as a text (SMS) message.
[0182] In FIG. 32B (i), detecting the proximity of the device to
the lock 3202 may include at 3224 use of one or more of the
following elements in a group comprising: reading a tag located
proximately to and associated with the lock; GPS coordinates of the
lock or device; detection of a Wi-Fi.TM. or Bluetooth.TM. network;
Near Field Communication verification; pin code entry; Quick
Response (QR) code recognition; and, a timed lock operation. At
3226, detecting the proximity of the device to the lock includes
comparing at least one credential element cached in the device to
at least one respective credential identified by or received by the
device. At 3228, detecting the proximity of the device to the lock
further includes notifying a user of the identity of the lock. At
3230, notifying the user of the identity of the lock is based on
receipt and authentication of the received credentials.
[0183] In FIG. 32B (ii), detecting the proximity of the device to
the lock 3202 automatically launches at 3234 a software application
installed on the device. At 3236, the software application may be a
third party application. At 3240, the command issued by the web
service for receipt by the lock may be based on an input received
at the portable electronic device from a user using the software
application installed on the device. At 3242, the issued command
may be one of the commands selected from a group of commands
comprising: lock; unlock; timed lock request; timed unlock request;
and toggle lock/unlock request. At 3244, the software application
may be a lock software application, associated with the web
service, for installation on the portable electronic device. At
3246, the software application may be further to notify the web
service of the credentials upon launch.
[0184] In FIG. 32B (iii), detecting the proximity of the device to
the lock 3202 may include at 3248 providing a tag located
proximately to and associated with the lock, the tag to be read by
the portable electronic device to launch the application. At 3250,
the method may further comprise receiving a signal that the tag has
been read by the portable electronic device. At 3252, the tag may
be a Near Field Communication (NFC) tag. At 3254, the tag may be
encoded with a software application Universal Resource Indicator
(URI). At 3256, the launch of the software application includes
recognition by the portable electronic device of the Universal
Resource Indicator (URI) encoded in the tag. At 3258, the tag may
be encoded with a unique code, the unique code forming at least
part of the credentials. At 3260, the credentials may be
authenticated by the web service using at least the unique
code.
[0185] In FIG. 32C, issuing a command 3204 may at 3282 include a
command associated with a customized lock operation. The method may
further comprise at 3296 receiving a command as a text (SMS)
message from a user's portable electronic device and basing the
command for receipt by the lock on the texted command.
[0186] In FIG. 32D, allowing pairing 3264, further comprises at
3266 receiving or sending the credentials or a user command from
the portable electronic device at least via the internet
connection.
[0187] In FIG. 32E, the accessory component may be at 3270 a
component selected from the group comprising: lock power component;
lock operation component; lock server; connectivity component; pin
or command entry keypad; presence detector; vibration sensor;
doormat; doorbell; and video or still camera. At 3272, the
connectivity component may be a component selected from the group
of components comprising: Bluetooth.TM.; Radio Frequency (RF);
Wi-Fi.TM.; internet; infrared; and piezo-electric. At 3274, the
accessory component may have a passive and an active state, and
wherein detecting the proximity of the portable electronic device
to the lock triggers the accessory component into its active state,
or causes the component to perform an operation. At 3276, detecting
the proximity of the portable electronic device to the lock may
include notifying a user that the accessory component is not in
integration or communication with the lock or the web service. At
3278, notifying the user that the component is not in integration
or communication with the lock or web service occurs in response to
a failed receipt by the lock of the command.
[0188] In FIG. 32F, the method may further comprise at 3294
authenticating credentials received from the first user in response
to the notification, and receiving a command from the first user to
actuate the lock.
[0189] In FIG. 32G, the method may further comprise at 3298
providing a portal on the web service for entry by a user of
credentials or a command for receipt by the lock.
[0190] Another example method embodiment is illustrated in FIGS.
33-33C.
[0191] In the example embodiment shown in FIG. 33, a method of
operating a remotely operable lock comprises: at 3300, providing a
first web service for receiving credentials or a command from a
portable electronic device having a software application installed
thereon; at 3302, issuing a command for receipt by the lock from
the web service; and at 3204, providing an application programming
interface (API) at the first web service for integrating a second
web service or the software application with the first web service
to allow the portable electronic device to communicate with the
lock or web service.
[0192] In FIG. 33A, the received credentials relating to a third
party user or second web service may at 3322 be authenticated by an
authenticated user of the lock. At 3324, the third party or second
web service may seamlessly issue a command to or receive data from
the lock.
[0193] In FIG. 33A, the method may further comprise at 3310
authenticating the credentials received at the web service, and
based on a successful authentication, issuing the command for
receipt by the lock. At 3312, the received credentials may relate
to the lock. At 3314, the received credentials may relate to the
portable electronic device. At 3316, the received credentials may
relate to a third party user or second web service requesting
access to the first web service or the lock.
[0194] In FIG. 33B, the command for receipt by the lock may at be
received at 3330 by the lock via the second web service.
[0195] In FIG. 33C, the software application may be at 3306 a third
party software application. At 3308, the integration is performed
in response to a request for access to the first web service or
lock from a user.
[0196] In FIG. 33C, the command for receipt by the lock may be
received at 3318 by the lock via the second web service. At 3320,
the integration is performed in response to a request for access to
the first web service or lock from an unauthenticated user.
[0197] In FIG. 33C, the third party application at 3326
automatically requests access to the lock on behalf of a user based
on the occurrence of an outside event. At 3328, the outside event
may be an event selected from the group comprising: booking a room
for use at a certain time; requesting access to secure premises;
delivery of a parcel; inspection of premises; entry into a motor
vehicle; and use of a bicycle.
[0198] These method embodiments are also referred to herein as
"examples." Such examples can include method elements in addition
to those shown or described. However, the present inventors also
contemplate examples in which only those method elements shown or
described are provided. Moreover, the present inventors also
contemplate examples using any combination or permutation of those
method elements shown or described above (or one or more aspects
thereof), either with respect to a particular example (or one or
more aspects thereof), or with respect to other examples (or one or
more aspects thereof) shown or described herein.
Processor Implementation
[0199] The various operations of example methods described herein
may be performed, at least partially, by one or more processors
that are temporarily configured (e.g., by software) or permanently
configured to perform the relevant operations. Whether temporarily
or permanently configured, such processors may constitute
processor-implemented modules that operate to perform one or more
operations or functions. The modules referred to herein may, in
some example embodiments, comprise processor-implemented
modules.
[0200] Similarly, the methods described herein may be at least
partially processor-implemented. For example, at least some of the
operations of a method may be performed by one or more processors
or processor-implemented modules. The performance of certain of the
operations may be distributed among the one or more processors, not
only residing within a single machine, but deployed across a number
of machines. In some example embodiments, the processor or
processors may be located in a single location (e.g., within a home
environment, an office environment, or as a server farm), while in
other embodiments the processors may be distributed across a number
of locations.
[0201] The one or more processors may also operate to support
performance of the relevant operations in a "cloud computing"
environment or as a "software as a service" (SaaS). For example, at
least some of the operations may be performed by a group of
computers (as examples of machines including processors), with
these operations being accessible via a network (e.g., the
Internet) and via one or more appropriate interfaces (e.g.,
APIs).
Electronic Apparatus And System
[0202] Example embodiments may be implemented in digital electronic
circuitry, or in computer hardware, firmware, or software, or in
combinations of them. Example embodiments may be implemented using
a computer program product, e.g., a computer program tangibly
embodied in an information carrier, e.g., in a machine-readable
medium for execution by, or to control the operation of, data
processing apparatus, e.g., a programmable processor, a computer,
or multiple computers.
[0203] A computer program can be written in any form of programming
language, including compiled or interpreted languages, and it can
be deployed in any form, including as a stand-alone program or as a
module, subroutine, or other unit suitable for use in a computing
environment. A computer program can be deployed to be executed on
one computer or on multiple computers at one site or distributed
across multiple sites and interconnected by a communication
network.
[0204] In example embodiments, operations may be performed by one
or more programmable processors executing a computer program to
perform functions by operating on input data and generating output.
Method operations can also be performed by, and apparatus of
example embodiments may be implemented as, special purpose logic
circuitry (e.g., a FPGA or an ASIC).
[0205] The computing system can include clients and servers. A
client and server are generally remote from each other and
typically interact through a communication network. The
relationship of client and server arises by virtue of computer
programs running on the respective computers and having a
client-server relationship to each other. In embodiments deploying
a programmable computing system, it will be appreciated that both
hardware and software architectures usually require consideration.
Specifically, it will be appreciated that the choice of whether to
implement certain functionality in permanently configured hardware
(e.g., an ASIC), in temporarily configured hardware (e.g., a
combination of software and a programmable processor), or a
combination of permanently and temporarily configured hardware may
be a design choice. Below are set out hardware (e.g., machine) and
software architectures that may be deployed, in various example
embodiments.
Example Machine Architecture and Machine-Readable Medium
[0206] FIG. 34 is a block diagram of machine in the example form of
a computer system 3400 within which instructions for causing the
machine to perform any one or more of the methodologies discussed
herein may be executed. In alternative embodiments, the machine
operates as a standalone device or may be connected (e.g.,
networked) to other machines. In a networked deployment, the
machine may operate in the capacity of a server or a client machine
in server-client network environment, or as a peer machine in a
peer-to-peer (or distributed) network environment. The machine may
be a personal computer (PC), a tablet PC, a set-top box (STB), a
PDA, a cellular telephone, a web appliance, a network router,
switch or bridge, or any machine capable of executing instructions
(sequential or otherwise) that specify actions to be taken by that
machine. Further, while only a single machine is illustrated, the
term "machine" shall also be taken to include any collection of
machines that individually or jointly execute a set (or multiple
sets) of instructions to perform any one or more of the
methodologies discussed herein.
[0207] The example computer system 3400 includes a processor 3402
(e.g., a central processing unit (CPU), a graphics processing unit
(GPU) or both), a main memory 3404 and a static memory 3406, which
communicate with each other via a bus 3408. The computer system 500
may further include a video display unit 3410 (e.g., a liquid
crystal display (LCD) or a cathode ray tube (CRT)). The computer
system 500 also includes an alphanumeric input device 3412 (e.g., a
keyboard), a user interface (UI) navigation or cursor control
device 3414 (e.g., a mouse), a disk drive unit 3416, a signal
generation device 3418 (e.g., a speaker) and a network interface
device 3420.
Machine-Readable Medium
[0208] The disk drive unit 3416 includes a machine-readable medium
3422 on which is stored one or more sets of data structures and
instructions 3424 (e.g., software) embodying or utilized by any one
or more of the methodologies or functions described herein. The
instructions 3424 may also reside, completely or at least
partially, within the main memory 3404 and/or within the processor
3402 during execution thereof by the computer system 500, with the
main memory 3404 and the processor 3402 also constituting
machine-readable media.
[0209] While the machine-readable medium 3422 is shown in an
example embodiment to be a single medium, the term
"machine-readable medium" may include a single medium or multiple
media (e.g., a centralized or distributed database, and/or
associated caches and servers) that store the one or more data
structures or instructions 3424. The term "machine-readable medium"
shall also be taken to include any tangible medium that is capable
of storing, encoding, or carrying instructions for execution by the
machine and that cause the machine to perform any one or more of
the methodologies of the embodiments of the present invention, or
that is capable of storing, encoding or carrying data structures
utilized by or associated with such instructions. The term
"machine-readable medium" shall accordingly be taken to include,
but not be limited to, solid-state memories and optical and
magnetic media. Specific examples of machine-readable media include
non-volatile memory, including by way of example semiconductor
memory devices (e.g., Erasable Programmable Read-Only Memory
(EPROM), Electrically Erasable Programmable Read-Only Memory
(EEPROM), and flash memory devices); magnetic disks such as
internal hard disks and removable disks; magneto-optical disks; and
CD-ROM and DVD-ROM disks.
Transmission Medium
[0210] The instructions 3424 may further be transmitted or received
over a communications network 3426 using a transmission medium. The
instructions 3424 may be transmitted using the network interface
device 3420 and any one of a number of well-known transfer
protocols (e.g., HTTP). Examples of communication networks include
a LAN, a WAN, the Internet, mobile telephone networks, Plain Old
Telephone (POTS) networks, and wireless data networks (e.g.,
Wi-Fi.TM. and WiMax.TM. networks). The term "transmission medium"
shall be taken to include any intangible medium that is capable of
storing, encoding or carrying instructions for execution by the
machine, and includes digital or analog communications signals or
other intangible media to facilitate communication of such
software.
Non-Limiting Embodiments
[0211] While the invention has been described with reference to
specific embodiments, it will be understood by those skilled in the
art that various changes may be made and equivalents may be
substituted for the elements thereof without departing from the
true spirit and scope of the invention. In addition, modifications
may be made without departing from the essential teachings of the
invention. Moreover, each of the non-limiting examples described
herein can stand on its own, or can be combined in various
permutations or combinations with one or more of the other
examples.
[0212] The above detailed description includes references to the
accompanying drawings, which form a part of the detailed
description. The drawings show, by way of illustration, specific
embodiments in which the invention can be practiced. These
embodiments are also referred to herein as "examples." Such
examples can include elements in addition to those shown or
described. However, the present inventors also contemplate examples
in which only those elements shown or described are provided.
Moreover, the present inventors also contemplate examples using any
combination or permutation of those elements shown or described (or
one or more aspects thereof), either with respect to a particular
example (or one or more aspects thereof), or with respect to other
examples (or one or more aspects thereof) shown or described
herein.
[0213] In the event of inconsistent usages between this document
and any documents so incorporated by reference, the usage in this
document controls.
[0214] In this document, the terms "a" or "an" are used, as is
common in patent documents, to include one or more than one,
independent of any other instances or usages of "at least one" or
"one or more." In this document, the term "or" is used to refer to
a nonexclusive or, such that "A or B" includes "A but not B," "B
but not A," and "A and B," unless otherwise indicated. In this
document, the terms "including" and "in which" are used as the
plain-English equivalents of the respective terms "comprising" and
"wherein." Also, in the following claims, the terms "including" and
"comprising" are open-ended, that is, a system, device, article,
composition, formulation, or process that includes elements in
addition to those listed after such a term in a claim are still
deemed to fall within the scope of that claim. Moreover, in the
following claims, the terms "first," "second," and "third," etc.
are used merely as labels, and are not intended to impose numerical
requirements on their objects.
[0215] Method examples described herein can be machine or
computer-implemented at least in part. Some examples can include a
computer-readable medium or machine-readable medium encoded with
instructions operable to configure an electronic device to perform
methods as described in the above examples. An implementation of
such methods can include code, such as microcode, assembly language
code, a higher-level language code, or the like. Such code can
include computer readable instructions for performing various
methods. The code may form portions of computer program products.
Further, in an example, the code can be tangibly stored on one or
more volatile, non-transitory, or non-volatile tangible
computer-readable media, such as during execution or at other
times. Examples of these tangible computer-readable media can
include, but are not limited to, hard disks, removable magnetic
disks, removable optical disks (e.g., compact disks and digital
video disks), magnetic cassettes, memory cards or sticks, random
access memories (RAMs), read only memories (ROMs), and the
like.
[0216] The above description is intended to be illustrative, and
not restrictive. For example, the above-described examples (or one
or more aspects thereof) may be used in combination with each
other. Other embodiments can be used, such as by one of ordinary
skill in the art upon reviewing the above description. The Abstract
is provided to comply with 37 C.F.R. .sctn.1.72(b), to allow the
reader to quickly ascertain the nature of the technical disclosure.
It is submitted with the understanding that it will not be used to
interpret or limit the scope or meaning of the claims. Also, in the
above Detailed Description, various features may be grouped
together to streamline the disclosure. This should not be
interpreted as intending that an unclaimed disclosed feature is
essential to any claim. Rather, inventive subject matter may lie in
less than all features of a particular disclosed embodiment. Thus,
the following claims are hereby incorporated into the Detailed
Description as examples or embodiments, with each claim standing on
its own as a separate embodiment, and it is contemplated that such
embodiments can be combined with each other in various combinations
or permutations. The scope of the invention should be determined
with reference to the appended claims, along with the full scope of
equivalents to which such claims are entitled.
* * * * *