Patent Description:
The claimed subject matter relates to the field of network communications, and more particularly to systems and methods that enable the remote operation of a switch.

Systems for remotely operating switches typically put a fixed, static set of features on the switching device, itself. The typical method of operation exposes the switching device to a local Wi-Fi network, or to Bluetooth. Once a mobile device also connects to the local network or is within Bluetooth range, the mobile device can "see" the switching device and operate it. If one is not on the local network, the user may log in using a DNS method to operate the switching device remotely. DNS access methods often lead to security issues (e.g., IoT devices have been used for DDoS attacks) because it is difficult to maintain the devices from a security perspective. It is also inconvenient due to the limitations of reaching the device easily, particularly if there is no ability to access the device from, e.g., a central server for things such as global device software updates.

Problems associated with existing systems include: the inability to communicate device status to the user after the device fails; the lack of a convenient way to update software; the inability to share access codes (also known as "keys"); the inability to modify the access granted to shared keys (e.g., the inability to limit a shared key to providing access only during a particular window of time); the inability to individually modify the privileges of shared keys; and the inability to restrict a shared key to being used by a particular user device. <CIT> describes an apparatus and a method for remotely managing access to an area. <CIT> describes a computer system for maintaining and delegating permissions.

In an embodiment, the problems associated with existing systems are addressed and alleviated using a switching device with a fully-functioning operating system that may connect with a network server and may be activated through the server using a network-enabled user device.

<FIG> shows a simplified block diagram of an embodiment of a distributed computer system <NUM> for remotely operating a switch. Computer network <NUM> includes a number of client systems <NUM>, <NUM>, and <NUM>, and a server system <NUM> coupled to a communication network <NUM> via a plurality of communication links <NUM>. Communication network <NUM> provides a mechanism for allowing the various components of distributed network <NUM> to communicate and exchange information with each other.

Communication network <NUM> may itself be comprised of many interconnected computer systems and communication links. Communication links <NUM> may be hardwire links, optical links, satellite or other wireless communications links, wave propagation links, or any other mechanisms for communication of information. Various communication protocols may be used to facilitate communication between the various systems shown in <FIG>. These communication protocols may include TCP/IP, HTTP protocols, wireless application protocol (WAP), vendor-specific protocols, customized protocols, and others. While in one embodiment, communication network <NUM> is the Internet, in other embodiments, communication network <NUM> may be any suitable communication network including a local area network (LAN), a wide area network (WAN), a wireless network, a intranet, a private network, a public network, a switched network, Internet telephony, IP telephony, digital voice, voice over broadband (VoBB), broadband telephony, Voice over IP (VoIP), public switched telephone network (PSTN), and combinations of these, and the like.

System <NUM> in <FIG> is merely illustrative of an embodiment and does not limit the scope of the systems and methods as recited in the claims. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, more than one server system <NUM> may be connected to communication network <NUM>. As another example, a number of client systems <NUM>, <NUM>, and <NUM> may be coupled to communication network <NUM> via an access provider (not shown) or via some other server system. An instance of a server system <NUM> and a computing device <NUM> may be part of the same or a different hardware system. An instance of a server system <NUM> may be operated by a provider different from an organization operating an embodiment of a system for specifying an object in a design, or may be operated by the same organization operating an embodiment of a system for specifying an object in a design.

Client systems <NUM>, <NUM>, and <NUM> typically request information from a server system which provides the information. Server systems by definition typically have more computing and storage capacity than client systems. However, a particular computer system may act as both a client and a server depending on whether the computer system is requesting or providing information. Aspects of the system may be embodied using a client-server environment or a cloud-cloud computing environment.

Server <NUM> is responsible for receiving information requests from client systems <NUM>, <NUM>, and <NUM>, performing processing required to satisfy the requests, and for forwarding the results corresponding to the requests back to the requesting client system. The processing required to satisfy the request may be performed by server system <NUM> or may alternatively be delegated to other servers connected to communication network <NUM>.

Client systems <NUM>, <NUM>, and <NUM> enable users to access and query information or applications stored by server system <NUM>. Some example client systems include portable electronic devices (e.g., mobile communication devices) such as the Apple iPhone®, the Apple iPad®, the Palm Pre™, or any device running the Apple iOS™, Android™ OS, Google Chrome OS, Symbian OS®, Windows Mobile® OS, Palm OS@ or Palm Web OS™. In a specific embodiment, a "web browser" application executing on a client system enables users to select, access, retrieve, or query information and/or applications stored by server system <NUM>. Examples of web browsers include the Android browser provided by Google, the Safari® browser provided by Apple, the Opera Web browser provided by Opera Software, the BlackBerry® browser provided by Research In Motion, the Internet Explorer® and Internet Explorer Mobile browsers provided by Microsoft Corporation, the Firefox® and Firefox for Mobile browsers provided by Mozilla®, and others. Client systems <NUM>, <NUM>, and <NUM> may run applications to enable users remotely operate switches according to various embodiments.

<FIG> shows a more detailed diagram of an example of a computing device from a system for remotely operating a switch. In an embodiment, a user interfaces with the system through a client system, such as shown in <FIG>. Mobile client communication device or portable electronic device <NUM> includes a display, screen, or monitor <NUM>, housing <NUM>, and input device <NUM>. Housing <NUM> houses familiar computer components, some of which are not shown, such as a processor <NUM>, memory <NUM>, battery <NUM>, speaker, transceiver, network interface <NUM>, microphone, ports, jacks, connectors, camera, input/output (I/O) controller, display adapter, network interface, mass storage devices <NUM>, and the like. Computer system <NUM> may include a bus or other communication mechanism for communicating information between components. Mass storage device (or devices) <NUM> may store a user application and system software components. Memory <NUM> may store information and instructions to be executed by processor <NUM>.

Input device <NUM> may also include a touchscreen (e.g., resistive, surface acoustic wave, capacitive sensing, infrared, optical imaging, dispersive signal, or acoustic pulse recognition), keyboard (e.g., electronic keyboard or physical keyboard), buttons, switches, stylus, gestural interface (contact or non-contact gestures), biometric input sensors, or combinations of these.

Mass storage device <NUM> may include flash and other nonvolatile solid-state storage or solid-state drive (SSD), such as a flash drive, flash memory, or USB flash drive. Other examples of mass storage include mass disk drives, floppy disks, magnetic disks, optical disks, magneto-optical disks, fixed disks, hard disks, CD-ROMs, recordable CDs, DVDs, recordable DVDs (e.g., DVD-R, DVD+R, DVD-RW, DVD+RW, HD-DVD, or Blu-ray Disc), battery-backed-up volatile memory, tape storage, reader, and other similar media, and combinations of these.

System <NUM> may also be used with computer systems having different configurations, e.g., with additional or fewer subsystems. For example, a computer system could include more than one processor (i.e., a multiprocessor system, which may permit parallel processing of information) or a system may include a cache memory. The computer system shown in <FIG> is but an example of a computer system suitable for use. Other configurations of subsystems suitable for use will be readily apparent to one of ordinary skill in the art. For example, in a specific implementation, the computing device is mobile communication device such as a smartphone or tablet computer. Some specific examples of smartphones include the Droid Incredible and Google Nexus One®, provided by HTC Corporation, the iPhone® or iPad®, both provided by Apple, BlackBerry Z10 provided by BlackBerry (formerly Research In Motion), and many others. The computing device may be a laptop or a netbook. In another specific implementation, the computing device is a non-portable computing device such as a desktop computer or workstation.

A computer-implemented or computer-executable version of the program instructions useful to practice the present subject matter may be embodied using, stored on, or associated with computer-readable medium. A computer-readable medium may include any medium that participates in providing instructions to one or more processors for execution. Such a medium may take many forms including, but not limited to, nonvolatile, volatile, and transmission media. Nonvolatile media includes, for example, flash memory, or optical or magnetic disks. Volatile media includes static or dynamic memory, such as cache memory or RAM. Transmission media includes coaxial cables, copper wire, fiber optic lines, and wires arranged in a bus. Transmission media can also take the form of electromagnetic, radio frequency, acoustic, or light waves, such as those generated during radio wave and infrared data communications.

For example, a binary, machine-executable version, of the software useful to practice the present subject matter may be stored or reside in RAM or cache memory, or on mass storage device <NUM>. The source code of this software may also be stored or reside on mass storage device <NUM> (e.g., flash drive, hard disk, magnetic disk, tape, or CD-ROM). As a further example, code useful for practicing the subject matter may be transmitted via wires, radio waves, or through a network such as the Internet. In another specific embodiment, a computer program product including a variety of software program code to implement features of the subject matter is provided.

Computer software products may be written in any of various suitable programming languages, such as C, C++, C#, Pascal, Fortran, Perl, Matlab (from MathWorks, www. com), SAS, SPSS, JavaScript, CoffeeScript, Objective-C, Objective-J, Ruby, Python, Erlang, Lisp, Scala, Clojure, and Java. The computer software product may be an independent application with data input and data display modules. Alternatively, the computer software products may be classes that may be instantiated as distributed objects. The computer software products may also be component software such as Java Beans (from Oracle) or Enterprise Java Beans (EJB from Oracle).

An operating system for the system may be the Android operating system, iPhone OS (i.e., iOS), Symbian, BlackBerry OS, Palm web OS, bada, MeeGo, Maemo, Limo, or Brew OS. Other examples of operating systems include one of the Microsoft Windows family of operating systems (e.g., Windows <NUM>, <NUM>, Me, Windows NT, Windows <NUM>, Windows XP, Windows XP x64 Edition, Windows Vista, Windows <NUM>, Windows CE, Windows Mobile, Windows Phone <NUM>), Linux, HP-UX, UNIX, Sun OS, Solaris, Mac OS X, Alpha OS, AIX, IRIX32, or IRIX64. Other operating systems may be used.

Furthermore, the computer may be connected to a network and may interface to other computers using this network. The network may be an intranet, internet, or the Internet, among others. The network may be a wired network (e.g., using copper), telephone network, packet network, an optical network (e.g., using optical fiber), or a wireless network, or any combination of these. For example, data and other information may be passed between the computer and components (or steps) of a system useful in practicing the subject matter using a wireless network employing a protocol such as Wi-Fi (IEEE standards <NUM>, <NUM>. 11a, <NUM>. 11b, <NUM>. 11e, <NUM>, <NUM>. 11i, and <NUM>. 11n, just to name a few examples). For example, signals from a computer may be transferred, at least in part, wirelessly to components or other computers.

<FIG> is a simplified block diagram of an embodiment of a system <NUM> for remotely operating a switch for use by a user <NUM>. System <NUM> includes one or more user computing devices <NUM>, and a server <NUM>, coupled to a communication network <NUM> via a plurality of communication links <NUM>. Computing device <NUM> may be used to run a user application <NUM> for remotely operating a switch. User application <NUM> may use computing device <NUM> and network <NUM> to access server <NUM>. Communication network <NUM> (or "network <NUM>") provides a mechanism for allowing the various components of system <NUM> to communicate and exchange information with each other via communication links <NUM>. Server <NUM> may run a switching control component <NUM>, which itself may be comprised of sub-components, e.g., 342a, 342b, 342c,. Sub-components 342a. 342n may include one or more databases. And computing device <NUM> may itself run an organizational managing component <NUM>, which may perform as switching control component <NUM>, or as one of sub-components 342a, 342b, 342c,. , 342n in communication with server <NUM> through network <NUM>. Typically, disclosure directed to "communicating with, accessing, or interacting with" the server should be interpreted as "communicating with, accessing, or interacting with" the switching control component running on the server.

Network <NUM> may be any suitable communications network. Communication network <NUM> may itself be comprised of many interconnected computer systems and communication links. As an example, and not by way of limitation, one or more portions of network <NUM> may include an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, another suitable network, or a combination of two or more of these. Network <NUM> may include one or more networks <NUM>.

Connections <NUM> may connect computing device <NUM> and server <NUM> to communication network <NUM> or to each other. Communication links <NUM> may be hardwire links, optical links, satellite or other wireless communications links, wave propagation links, or any other mechanisms for communication of information. This disclosure contemplates any suitable connections <NUM>. In particular embodiments, one or more connections <NUM> include one or more wireline (such as for example Digital Subscriber Line (DSL) or Data Over Cable Service Interface Specification (DOCSIS)), wireless (such as for example Wi-Fi or Worldwide Interoperability for Microwave Access (WiMAX)) or optical (such as for example Synchronous Optical Network (SONET) or Synchronous Digital Hierarchy (SDH)) connections. In particular embodiments, one or more connections <NUM> each include an ad hoc network, an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a WWAN, a MAN, a portion of the Internet, a portion of the PSTN, a cellular telephone network, another suitable connection <NUM>, or a combination of two or more such connections <NUM>. Connections <NUM> need not necessarily be the same throughout system <NUM>. One or more first connections <NUM> may differ in one or more respects from one or more second connections <NUM>.

Server <NUM> may be a network-addressable computing system that can host one or more switching control components <NUM>. Server <NUM> may be responsible for receiving information requests from computing device <NUM> via user application <NUM>, for performing the processing required to satisfy the requests, for generating responses to received inquiries, and for forwarding the results corresponding to the requests back to requesting computing device <NUM>. Server <NUM> may store, receive, or transmit data and software, and information associated with the data and software (including user data). The processing required to satisfy the requests may be performed by server <NUM> or may alternatively be delegated to other servers connected to communication network <NUM>. For example, other servers may host switching control component <NUM>, or sub-components 342a. Server <NUM> may be an intermediary in communications between a computing device <NUM> and another server system, or a computing device <NUM> may communicate directly with another server system. Server <NUM> may be accessed by the other components of system <NUM>, for example, directly or via network <NUM>. In particular embodiments, one or more users <NUM> may use one or more computer devices <NUM> to access, send data to, and receive data from server <NUM>.

Computing device <NUM>, connections <NUM>, and network <NUM>, enable user <NUM> to access and query information stored and applications run by server <NUM>, such as switching control component <NUM>. Some example computer devices <NUM> include desktop computers, portable electronic devices (e.g., mobile communication devices, smartphones, tablet computers, laptops) such as the Samsung Galaxy Tab®, Google Nexus devices, Amazon Kindle®, Kindle Fire®, Apple iPhone®, the Apple iPad®, Microsoft Surface®, the Palm Pre™, or any device running the Apple iOS®, Android® OS, Google Chrome® OS, Symbian OS@, Windows Mobile® OS, Windows Phone, BlackBerry® OS, Embedded Linux, Tizen, Sailfish, webOS, Palm OS@ or Palm Web OS@.

In an embodiment, user application <NUM> may be run or executed by a different system. For example, computing device <NUM>, or server <NUM>, or both, may run user application <NUM>. That is, user application <NUM> may be run by computing device <NUM>, or the application may be run on server <NUM> and accessed by computing device <NUM> through a browser and network <NUM>. For example, computing device <NUM> could be operated as a terminal, with user application <NUM> being run on a server, e.g., server <NUM>. In an embodiment, aspects or functionalities of user application <NUM> are run by server <NUM>, or another computing system or server. In an embodiment, the steps of the methods described herein may be performed, at least in part, in cloud-computing environment.

<FIG> illustrates a particular arrangement of user <NUM>, computing device <NUM>, and server <NUM>, but this is an example arrangement. Any other suitable arrangement of user <NUM>, computing device <NUM>, server <NUM>, and network <NUM> may be used. For example, computing device <NUM> may be connected directly to server <NUM>. Also, computing device <NUM> and server <NUM> may appear to be distinct yet operate on the same hardware. In addition, any number of users <NUM>, clients <NUM>, and server <NUM> may be used in embodiments.

illustrates an embodiment of a system <NUM> for remotely operating a switch. In the embodiment of <FIG>, a switch-operated device, such as a gate <NUM>, is connected to a switching device <NUM> by a connection <NUM>, which may be, e.g., wired or wireless. In the embodiment, the exemplary device, gate <NUM>, is an electrically operated gate that opens or closes depending on the state dictated by the switching device <NUM>. In the embodiment, switching device <NUM> includes a network-enabled device that may close a switching circuit based on commands received over a network <NUM>. For example, switching device <NUM> may include a network-enabled device that is enabled to connect to network <NUM>, as described with reference to the devices and networks of <FIG>. Switching device <NUM> is connected by network <NUM> to a server <NUM>. Server <NUM> may run a switching control component such as component <NUM> (<FIG>) and may send commands to switching device <NUM> over network <NUM>. Server <NUM> may receive information, such as switching commands, set-up information, guest user information, user privilege level information, from a user device <NUM>. User device <NUM> (e.g., computing devices <NUM>, <NUM>, and client devices <NUM>, <NUM>, <NUM>, <NUM> (<FIG>)) may communicate with server <NUM> over a network <NUM>, which may be the same network as network <NUM>, or another network, as described with reference to <FIG>.

Additional user devices <NUM> (not shown) may also communicate with server <NUM> over network <NUM>. Additional user devices <NUM> may all have the same access privileges, or additional user devices <NUM> may have different access privileges. For example, two user devices <NUM> may have the same privileges (e.g., one user device <NUM> may be a "spare" of a second user device <NUM>). Also, for example, one user device <NUM> may be a primary, or owner, user device with unlimited, primary, or "owner" privileges and a second user device <NUM> may be a secondary, or "guest," user device with limited or "guest" privileges.

In an embodiment, a user may interface with server <NUM> using user device <NUM> running a user interface (not shown). The user interface may reflect whether the user has primary or "owner" privileges or the user has secondary or "guest" privileges. For example, where the user has primary privileges, a list of primary features may be available and the primary user may be able to use (e.g., view, access, customize, etc.) each of the primary features. On the other hand, where the user has secondary privileges, the secondary user may be able to use a subset (or modified subset) of the primary features.

Gate <NUM> is just an example of the devices that may be controlled by embodiments. Embodiments are envisioned that may control other electronically activated systems, such as an apartment door buzzer, or a manned access point (e.g., a manned gate at the entrance to a gated community). In an embodiment, gate <NUM> may be swung open or closed depending on the state of switching device conveyed to gate <NUM> over connection <NUM>. In an embodiment, gate <NUM> may be driven sideways to open or close d by sideways depending on the state of switching device conveyed to gate <NUM> over connection <NUM>. In an embodiment, gate <NUM> may be replaced by another type of barrier, such as, e.g., a garage door that is raised or lowered, or a standard door. In an embodiment, gate <NUM> may be opened and closed in another fashion, e.g., by being raised and lowered. In embodiments, user device <NUM> may be, e.g., a mobile device, or other network-enabled client device <NUM>, <NUM>, <NUM> (<FIG>). Networks <NUM>, <NUM> may use standard internet protocols that can be wired, Wi-Fi, cellular, or other networks referenced in regard to <FIG>, or combinations of these.

In an embodiment, switching device <NUM> incorporates a computing device with an operating system. The incorporated computing device may itself be a network-enabled device or may be in addition to a network-enabled device included in switching device <NUM>. The inclusion of the operating system is one feature that enables using a decentralized server between the gate <NUM> and the user device <NUM>.

In embodiments, control of the switching device has been decentralized by using a server and one or more networks. The server may then be used to communicate commands to the switching device. This enables continuously monitoring the switching device's availability to the server. It also enables updating of server and switching device software, e.g., updating to enhance features or provide additional features, updating to patch security holes, etc. Embodiments allow the server to be exposed to users through online browsers or other network access. With such access, embodiment features and services may be implemented and enhanced to address the user needs. It is anticipated that updates to the switching device would mainly involve security patches and drivers (new or updated) for peripherals, and that updates related to other system features would be made to the server software and application. However, such anticipated updates should not be understood to limit the potential of embodiments to update all aspects of the software of switching devices, server, and user devices.

In an embodiment, one or more cameras may be connected to the switching device. The ability to update the software on both the server, user device, and the switching device allows for updating camera support as new options become available.

One or more embodiments provide the following features, which are enabled or enhanced by networking the switching device and user devices with the server: the ability to constantly monitor the device function and connection; the ability to have a centralized logging function; the ability to share an access point with many users; a reduced need for firmware updates, since all connected devices may be monitored, their software determined, and then updated when and as needed; the ability to update the user interface and other software when and as needed; support for peripheral devices, such as lights, cameras, motion sensors, etc.; the ability to remotely use the system over a cellular connection; a reduced need for bandwidth over all connection types; the ability to decouple the user interface from the switching device to support things such as time zones and languages; a reduced code base in the "wild," which makes the system more secure; the ability to schedule switching times; and the ability to integrate with external services (e.g., UPS, Lyft, Uber, Postmates).

Regarding a reduced code base in the "wild" making the system more secure, in an embodiment, though there is considerable code running on the switching control device, the amount of code that is under the control of the system is much reduced - to approximately <NUM>% of the code estimated to be controlled by a known competitor. In the embodiment, the operating system may be an industry standard such as Debian GNU/Linux or Ubuntu. With such operating systems the patching and maintenance is provided by the community. This reduces dramatically the code that is unique to the switching control device itself. The communities involved in maintaining the industry standard operating systems are constantly patching security holes and adding peripheral drivers. Thus, embodiments benefit from this activity and unique system updates can be focused primarily on ensuring the server is secure (which itself may be facilitated by having the server in a secure environment).

Regarding a reduced need for bandwidth, in an embodiment the reduced need results from transmitting simple commands over the network rather than transmitting an entire user interface. This reduces the overhead of data usage. In an embodiment, for a gate with hundreds of users and hundreds of gate opens a day, including an update ping every few seconds to the server to make sure the connectivity is still active, the embodiment is estimated to use approximately 50MB of data a month.

Regarding the ability to integrate with external services, in an embodiment, the external service may be given an access code that allows the service to access a place, such as a house, a gated community, a room, etc. Limitations may be placed on the access privileges in the sense that the access code may be conditionally valid. For example, access privileges may be permanent until surrendered by the service, permanent until revoked by the user, limited in duration, limited to specific time windows, or limited in usage, such as being limited to be used (e.g., allowing access) a pre-determined number of times. Access privileges may be limited by combinations of limitations or conditions, as well. For example, in an embodiment an access code may be valid: for a one-time use (e.g., for a delivery); during a particular time of the day (e.g., for a regular delivery); for a duration (e.g., for a visiting guest).

In embodiments, an access may be accepted when the access code is "valid" and not accepted when the access code is "invalid," with the validity or invalidity being determined by limitations or conditions placed on access privileges. In other embodiments, an access code may be valid but accepted or not accepted depending on limitations or conditions placed on access privileges. For example, an access code may be valid to open a particular gate provided no other access code has been used for that particular gate on that particular day. Such a feature would allow first-come, first-served privileges.

<FIG> is a flow chart of an embodiment of a method <NUM> for remotely operating a switch. In <FIG>, method <NUM> involves a guest side <NUM>, a server side <NUM>, a device side <NUM> and an owner side <NUM>. Guest side <NUM> generally involves steps performed by a guest or that affect the guest, where a guest (or guest user) is a guest user of a switching device and associated switch-operable device (e.g., switching device <NUM> (<FIG>) and gate <NUM> (<FIG>), respectively). The guest may interface with the system using a user device (such as user device <NUM> (<FIG>)). Server side <NUM> generally involves steps performed by a server (e.g., server <NUM> (<FIG>)). Device side <NUM> generally involves steps performed by a switching device (e.g., switching device <NUM> (<FIG>). And owner side <NUM> generally involves steps performed by an owner or that affect the owner, where an owner (or owner-user) is the owner (or is otherwise in control of) the switching device and associated switch-operable device (e.g., switching device <NUM> (<FIG>) and switch-operated device <NUM> (<FIG>), respectively).

In the embodiment, the method is applied to an exemplary system controlling a door (similar to gate <NUM> (<FIG>)).

In step <NUM> of method <NUM>, a guest presses "open door" on a user interface of a user device in an attempt to open the door. The attempt also provides information regarding the particular door and a key. The key may be, e.g., a code input by the guest, but may not be a code, per se. Rather, a key may be information that identifies the "presser" (guest) or the key or both. Such information may include a universally unique identifier (UUID). Such information may include a photo identification. Such information may include biometric data, e.g., a fingerprint or facial scan. The guest may be known or unknown. If the guest is known then the method may determine the guest's identity as described within. However, with certain special use keys, such as a party key, any possessor of the key may use the key (e.g., open the relevant gate or door) as long as the use is within the time limits or other conditions controlling use of the key. In step <NUM>, the server logs the attempt. In step <NUM>, the server determines whether a valid key was presented. For example, the server may use the provided code and door information and determine whether that particular code is valid for that particular door. The server may determine such validity using a database to which the server has access. If the key is not valid, in step <NUM> the server logs the invalid attempt and in step <NUM>, the guest is denied access.

Returning to step <NUM>, if the key is valid then in step <NUM> the server determines whether the key is a root key. A root key is a master key in the chain of trust (or a chain of "priority"). This compares to a "parent key," which refers to a key directly "above" a key in question in the chain of trust. For example, a homeowner may issue a gate key to the landscaper. The homeowner may give the landscaper the ability to issue keys to his crew. If a crew member tries to open the gate, the landscaper is the parent key and the homeowner is the root key. If the presented key is not a root key, then in step <NUM> (an optional step) the server determines whether the attempt is an attempt at emergency access. If not an emergency access (or if optional step <NUM> is not included), then in step <NUM> the server determines whether the key is valid for the date and time the key was presented. If the key is not valid for the time and date, in step <NUM> the server determines whether the attempt is "doorbell-able" (i.e., the particular door may also be opened by the owner). If the door is not doorbell-able, then in step <NUM> access is denied and in step <NUM> the denial is displayed to the guest.

Returning to step <NUM>, if the presented key is a root key, then in step <NUM> a command is sent to the device to open the door and a "door-open" timer is started. In step <NUM>, the switching device receives the command and triggers the door circuit, causing the door to open (or to be unlocked and "open-able," depending on the mechanical configuration). In step <NUM>, the switching device replies to the server that the command was received and the door is being opened. In step <NUM>, which may occur if the timer has not run out, the server receives the "door is opening" status and communicates that status to the guest device. In step <NUM>, the guest device displays a message that the door is opening.

In step <NUM>, the server receives the "door is opening" status and also, in step <NUM>, stops the timer. In step <NUM>, the server determines that the timer ran out or receives the information that the timer was stopped, proceeding on the "yes" path to step <NUM> only if the timer ran out (see step <NUM>). In step <NUM>, after the timer ran out, the server determines whether the presented key was a one-time use key. If not, then in step <NUM>, a message is displayed showing the guest that the door is "not connected," which means that the time has expired during which the door could open. If in step <NUM> the presented key was a one-time use key, then in step <NUM> the one-time use key is "reset," which means that the presented key, having been presented once, but not used because the timer ran out, is reset so it may be presented again. In step <NUM>, the message is displayed showing the guest that the door is "not connected.

Returning to step <NUM>, if the server determines that the attempt is an attempt at emergency access, then in step <NUM> the server sends emergency alerts and proceeds to step <NUM>. Emergency alerts may include, for example, messages to: the owner, the fire-department, and the police department.

Returning to step <NUM>, if the presented key is determined to be valid for the date and time presented, then in step <NUM> the server determines whether a location is required. If not, then in step <NUM>, the server determines whether the presented key was a one-time use key. If not, then in step <NUM>, the server "goes to the parent key" and returns to step <NUM>.

Regarding "goes to the parent key," since keys are hierarchical, at a certain point the method returns to the root key to determine whether to trigger the door circuit. For example, take A as the root key, B as the gardener's key, and C as the gardener's worker's key. If the gardener's worker tries to gain access the method would first check key C, then if it passes, the method 'goes to the parent key' and checks the B key. If the B key passes the method checks the A key. The A key, being a root key, would eventually trigger the door circuit. This part of the method allows for access in which, if you revoke the gardener's key (a parent key), you don't have to revoke all the gardener's worker's keys ("sub-parent" keys , or "child" keys), since they are a level down in the chain of trust. The method also benefits an HOA - if someone were to move out of their house, that property's root keys may be revoked which would then revoke all access those root keys gave to anyone else.

Returning to step <NUM>, if the server determines a location is required, then in step <NUM> the server sends a request for location information to the guest. In step <NUM>, the guest sends location information to the server. In an embodiment, the information in step <NUM> may be entered by the guest user. In an embodiment, the information in step <NUM> may be determined by the guest user's device. In step <NUM>, the server determines whether the received location information is in a particular zone. If not, then in step <NUM> the server determines whether the attempt is "doorbell-able. " If not, the server proceeds as discussed earlier regarding step <NUM>. If the attempt is "doorbell-able," then in step <NUM> the server requests entry from the root key, sending information regarding the request to guest side <NUM> and owner side <NUM>. In the guest side, in step <NUM>, the request for entry from the root key is displayed to the guest by the guest device. In the owner side, in step <NUM>, the request to grant access is displayed to the owner-user. If the owner-user refuses to grant access, the refusal is communicated to the server and in step <NUM>, the server denies access as discussed previously.

Regarding the "zone" of step <NUM>, a zone may be set by the user in a "door configuration" step or interface. For example, the user could set the zone so that certain other users must be within a block (geographic area), or a half mile (distance from the door), or another arbitrary, user-defined area. In an embodiment, a user with appropriate privileges may set the zone as an area on a map. The zone may be modified or configured at any time by the user.

Returning to step <NUM>, if the owner-user grants access, then in step <NUM> the grant is sent to the server, which processes the grant of access in step <NUM> as discussed previously. After step <NUM>, in step <NUM> the owner-user is asked whether to extend key access. If so, the owner-user's choice to extend key access is communicated to the server. In step <NUM>, the server extends the presented key in the chain.

In an embodiment, a key may be "extended" by making the key valid for the next X amount of time. The X amount may be measured by the hour, day, week, etc. Such "extending" essentially converts the key into a family key for that X amount of time. For example, if a guest is staying at a user's home for the next two days. The first time the guest "doorbells" the user, the user may open the door. The user may then "extend" the guest (or the guest's device), granting the guest access for the next two days, during which time the guest may use their device to trigger the door circuit directly, without having to "doorbell" the user. This gives the guest family access without having to go through a lot of steps.

Returning to step <NUM>, if the server determines that the received location is in a particular zone, then in step <NUM>, the server determines whether the presented key is a one-time use key. If not, the server processes the request as discussed previously regarding step <NUM>. If the server determines that the presented key is a one-time use key, then in step <NUM>, the server determines whether the presented one-time use key has already been used. If not, then in step <NUM> the server asks the guest whether to use the presented one-time use key at this time. If the guest responds that the presented one-time use key should not be used at this time, then in step <NUM> the process is exited.

Returning to step <NUM>, if the server determines that the presented one-time use key has already been used, then in step <NUM> the server determines whether the attempted access is "doorbell-able" as discussed previously.

Returning to step <NUM>, if the guest responds that the presented one-time use key should be used at this time, then in step <NUM> the server marks the presented key as being used and, in step <NUM> the server "goes to the parent key" as discussed previously.

<FIG> shows a simplified block diagram of an embodiment of a system <NUM> for remotely directing the operation of a switch <NUM>. In the embodiment, a gate <NUM> may be operated by an operator (e.g., a guard (not shown)) who has control of a switch <NUM>, which opens or closes gate <NUM> via a wired or wireless connection. In the embodiment, a network enabled directing device <NUM> is programmed to provide information directing the actions of the operator as to whether gate <NUM> should be opened, remain closed, or be closed. In the embodiment, the provided information is determined by one or more software components running on a server <NUM> based on the potential guest presenting information, such as a code or key, to server <NUM> using a client device <NUM>. For example, the provided information could indicate whether the potential guest (who just pushed a button on their device <NUM>) has been granted access. Directing device <NUM> may include a user interface for a client device (e.g., client devices <NUM>, <NUM>, or <NUM> (<FIG>)), or something more basic, such as a light system that indicates the appropriate state for gate <NUM>.

In an embodiment, a user interface may include an application that informs the gate operator whether to open the gate, or not, i.e., whether the potential guest has been granted access. The application may be web-based, or dedicated, and the client device displaying the application may be the operator's own mobile device. In an embodiment, the user interface may direct the gate operator to follow a procedure in addition to, or instead of, simply opening, not opening, or closing the gate. In an embodiment, the procedure may include an emergency procedure that includes, e.g., alerting a specific user, such as an owner, or the authorities. In an embodiment, the application may store information regarding the guest and may provide that information to the gate operator. In an embodiment, the stored guest information may include, e.g., a scan of the guest's government-issued ID, a photo of their license plate and/or make, model and color of their vehicle. Embodiments contemplate the system being employed in both suburban and urban settings. For example, an urban setting may include the system providing information directing a doorman whether to admit a potential guest.

In the embodiment of <FIG>, gate <NUM> is connected to a switch <NUM>, which is under the control of an operator (not shown). In the embodiment, the exemplary device, gate <NUM>, is an electrically operated gate that opens or closes depending on the state of switching device <NUM>. In the embodiment, network enabled directing device <NUM> includes a display that indicates to the operator whether allow a potential guest access. Network enabled directing device <NUM> receives the information for display to the operator based on commands received over a network <NUM>. For example, directing device <NUM> may include a network-enabled device that is enabled to connect to network <NUM>, as described with reference to the devices and networks of <FIG>. Directing device <NUM> is connected by network <NUM> to a server <NUM>. Server <NUM> may run a switching control component such as component <NUM> (<FIG>) and may send commands to directing device <NUM> over network <NUM>. Server <NUM> may receive information, such as switching commands, set-up information, guest user information, user privilege level information, from a user device <NUM>. User device <NUM> (e.g., computing devices <NUM>, <NUM>, and client devices <NUM>, <NUM>, <NUM>, <NUM> (<FIG>)) may communicate with server <NUM> over a network <NUM>, which may be the same network as network <NUM>, or another network, as described with reference to <FIG>.

In an embodiment, an operator (not shown) may interface with server <NUM> using user directing device <NUM> running a user interface (not shown). The user interface may reflect whether the potential guest or user has primary or "owner" privileges or the user has secondary or "guest" privileges. For example, where the user has primary privileges, a list of primary features may be available and interface may indicate to the operator that the primary user may be able to use each of the primary features. Such primary features may include, e.g., special access privileges regarding times and dates, special privileges regarding the type of vehicle that may enter, and special privileges regarding how many vehicles may enter with one key or code. On the other hand, where the user has secondary privileges, server <NUM> may indicate to the operator through directing device <NUM> that the secondary user may be able to use a subset (or modified subset) of the primary features.

Gate <NUM> is just an example of the devices that may be controlled by embodiments. Embodiments are envisioned that may control other operator-manned activities or stations, such as an apartment door, a ticket-requiring entrance (e.g., movie, toll road, amusement park ride, and concert). User device <NUM> may be, e.g., a mobile device, or other network-enabled client device <NUM>, <NUM>, <NUM> (<FIG>). Networks <NUM>, <NUM> may use standard internet protocols that can be wired, Wi-Fi, cellular, or other networks referenced in regard to <FIG>, or combinations of these.

In an embodiment, directing device <NUM> incorporates a computing device with an operating system. The incorporated computing device may itself be a network-enabled device or may be in addition to a network-enabled device included in directing device <NUM>. The inclusion of the operating system is one feature that enables using a decentralized server between gate <NUM> and the user device <NUM>.

In the embodiment, control of directing device <NUM> has been decentralized by using a server and one or more networks. The server may then be used to communicate commands to the directing device. This enables continuously monitoring the directing device's availability to the server. It also enables updating of server and directing device software, e.g., updating to enhance features or provide additional features, updating to patch security holes, etc. Embodiments allow the server to be exposed to users through online browsers or other network access. With such access, embodiment features and services may be implemented and enhanced to address the user needs. It is anticipated that updates to the directing device would mainly involve security patches and drivers (new or updated) for peripherals, and that updates related to other system features would be made to the server software and application. However, such anticipated updates should not be understood to limit the potential of embodiments to update all aspects of the software of directing devices, server, and user devices.

In an embodiment, one or more cameras may be connected to the directing device. The ability to update the software on both the server and the directing device allows for updating camera support as new options become available.

One or more embodiments provide the following features, which are enabled or enhanced by networking the directing device with the server: the ability to constantly monitor the device function and connection; the ability to have a centralized logging function; the ability to share an access point with many users; a reduced need for firmware updates, since all connected devices may be monitored, their software determined, and then updated when and as needed; the ability to update the user interfaces and other software when and as needed; support for peripheral devices, such as lights, cameras, motion sensors, etc.; the ability to remotely use the system over a cellular connection; a reduced need for bandwidth over all connection types; the ability to decouple the user interface from the directing device to support things such as time zones and languages; a reduced code base in the "wild," which makes the system more secure; the ability to schedule switching times; and the ability to integrate with external services (e.g., UPS, Lyft, Uber, Postmates).

<FIG> is a flow chart of an embodiment of a method <NUM> for remotely directing the operation of a switch (e.g., switch <NUM>). In <FIG>, method <NUM> involves a guest side <NUM>, a server side <NUM>, a device side <NUM>, and an owner side <NUM>. Method <NUM> is similar to method <NUM> (<FIG>), differing primarily in the steps attributed to device side <NUM>. In method <NUM>, guest side <NUM> generally involves steps performed by a guest or that affect the guest, where whether to admit a potential guest (or guest user) is determined by the operator in possession of a directing device and in control of a switched device (e.g., directing device <NUM> (<FIG>) and gate <NUM> (<FIG>), respectively). The guest may interface with the system using a user device (such as user device <NUM> (<FIG>)). Server side <NUM> generally involves steps performed by one or more software components running on a server (e.g., server <NUM> (<FIG>)). Device side <NUM> generally involves steps performed by a directing device (e.g., directing device <NUM> (<FIG>). And owner side <NUM> generally involves steps performed by an owner or that affect the owner, where an owner (or owner-user) is the owner (or is otherwise in ultimate control of) the directing device and associated switch-operable device (e.g., directing device <NUM> (<FIG>) and switch-operated device (gate <NUM>, <FIG>), respectively).

In the embodiment, the method is applied to an exemplary system for directing the control of a door (e.g., gate <NUM> (<FIG>)).

In step <NUM> of method <NUM>, a guest presses "open door" on a user interface of a user device in an attempt to open the door. The attempt also provides information regarding the particular door and a key. The guest may be known or unknown. If the guest is known the method may determine the guest's identity as described within. However, with certain special use keys, such as a party key, any possessor of the key may use the key (e.g., direct the operator to open the relevant gate or door) as long as the use is within the time limits or other conditions controlling use of the key. In step <NUM>, the server logs the attempt. In step <NUM>, the server determines whether a valid key was presented. For example, the server may use the provided code and door information and determine whether that particular code is valid for that particular door. The server may determine such validity using a database to which the server has access. If the key is not valid, in step <NUM> the server logs the invalid attempt and in step <NUM>, the operator is directed to deny the guest access.

Returning to step <NUM>, if the key is valid then in step <NUM> the server determines whether the key is a root key. A root key is a master key in the chain of trust (or a chain of "priority"). This compares to a "parent key," which refers to a key directly "above" a key in question in the chain of trust. If the presented key is not a root key, then in step <NUM> (an optional step) the server determines whether the attempt is an attempt at emergency access. If not an emergency access (or if optional step <NUM> is not included), then in step <NUM> the server determines whether the key is valid for the date and time the key was presented. If the key is not valid for the time and date, in step <NUM> the server determines whether the attempt is "doorbell-able" (i.e., the operator of the particular door may also be directed by the owner to open the door). If the door is not doorbell-able, then in step <NUM> access is denied and in step <NUM> the denial is displayed to the both the guest and the operator on the respective devices.

Returning to step <NUM>, if the presented key is a root key, then in step <NUM> a command is sent to the directing device informing the operator of the request to open the door and a "door-open" timer is started. In step <NUM>, the directing device receives the command and indicates to the operator whether additional information is needed. In an optional step <NUM>, the directing device indicates to the operator that a scan of an identification card is required. If a scan is required, in an optional step <NUM>, the directing device indicates that the scan of the identification card is to be performed using the directing device. In step <NUM>, based on the request to open the door from step <NUM> and also based on the results of any optional scan or identification verification step, the operator allows or disallows access, and indicates to the server using the directing device whether access was granted. In an optional step (not shown), the server receives an indication from the operator that access was disallowed and displays the denial of access to the guest user (as in step <NUM>). In step <NUM>, which may occur if the timer has not run out, the server receives a "door was allowed to open" status and communicates that status to the guest device. In step <NUM>, the guest device displays a message that the door will be opened (or is "open-able" depending on the mechanical configuration).

In step <NUM>, the server receives the "door will be opened" status and also, in step <NUM>, stops the timer. In step <NUM>, the server determines that the timer ran out or receives the information that the timer was stopped, proceeding on the "yes" path to step <NUM> only if the timer ran out (see step <NUM>). In step <NUM>, after the timer ran out, the server determines whether the presented key was a one-time use key. If not, then in step <NUM>, a message is displayed showing the guest that the door is "not connected," which means that the time has expired during which the door could open. If in step <NUM> the presented key was a one-time use key, then in step <NUM> the one-time use key is "reset," which means that the presented key, having been presented once, but not used because the timer ran out, is reset so it may be presented again. In step <NUM>, the message is displayed showing the guest that the door is "not connected.

Returning to optional step <NUM>, if the server determines that the attempt is an attempt at emergency access, then in step <NUM> the server sends emergency alerts and proceeds to step <NUM>. Emergency alerts may include, for example, messages to: the owner, the fire-department, and the police department.

Returning to step <NUM>, if the presented key is determined to be valid for the date and time presented, then in step <NUM> the server determines whether a location is required. If not, then in step <NUM>, the server determines whether the presented key was a one-time use key. If not, then in step <NUM>, the server "goes to the parent key" (as discussed previously with respect to <FIG>) and returns to step <NUM>.

Returning to step <NUM>, if the server determines a location is required, then in step <NUM> the server sends a request for location information to the guest. In step <NUM>, the guest sends location information to the server. In an embodiment, the guest may enter the location information into the guest user's device. In an embodiment, the guest may send location information to the server in response to a request from the server. In an embodiment, the information in step <NUM> may be entered by the guest user. In an embodiment, the information in step <NUM> may be determined by the guest user's device. In an embodiment, the operator may enter the location information into the directing device in response to a request from the server.

In step <NUM>, the server determines whether the received location information is in a particular zone. If not, then in step <NUM> the server determines whether the attempt is "doorbell-able. " If not, the server proceeds as discussed earlier regarding step <NUM>. If the attempt is "doorbell-able," then in step <NUM> the server requests entry from the root key, sending information regarding the request to guest side <NUM> and owner side <NUM>. In the guest side, in step <NUM>, the request for entry from the root key is displayed to the guest by the guest device. In the owner side, in step <NUM>, the request to grant access is displayed to the owner-user. If the owner-user refuses to grant access, the refusal is communicated to the server and in step <NUM>, the server denies access as discussed previously and the denial is communicated to the operator and the guest user.

In an embodiment, the systems of <FIG> and <FIG> may be combined. For example, a community with both automated gates (according to <FIG>) and manned gates (according to <FIG>) may provide a single key or code and respond to the presented key or code according to whether it is presented to an automated gate (according to, e.g., method <NUM>) or presented at a manned gate (according to, e.g., method <NUM>).

An embodiment provides for automated entry. With this feature, a gate may be opened by another computing device, rather than a person. In the embodiment, a keyholder may grant access to the device. For example, access could be granted to a self-driving vehicle or self-driving delivery vehicle. In an embodiment, an owner-user or other keyholder may grant access to a service rather than an individual or device. Such services could include self-driving car services and self-driving delivery services. With such self-driving service, the car would determine using positioning and mapping functions when it neared the gate. As it approached the gate, the car would then trigger the gate by accessing the automated entry feature over an available network - just as a human user might trigger the gate with a mobile device. In another automated entry embodiment, a service, like UPS, might be sent a key that allows for the delivery of a specific package. When the key is issued to UPS for that package the owner-user would have no way of knowing which driver would attempt to access the gate. But, once the key is used for the package, the key would be rendered invalide - UPS would no longer be able to use the key. In an embodiment, the key could be conveyed to the service using an automated Application Programming Interface (API). Other services, such as voice-controlled devices like Google Home, Amazon Alexa, or Apple Siri could activate a gate open. That is, such devices may be used to interface with servers <NUM>, <NUM> as client devices <NUM>, <NUM>, <NUM> (<FIG>). For example, such devices may be used to send keys to guest users, or be the device that is "doorbelled" when the system performs such an action. In these embodiments, restrictions on the key or code may be maintained as before and may prevent access as before.

In an embodiment, the systems and methods described may be integrated with other smart devices, e.g., Internet-of-things devices, to activate peripheral devices based on access to a gate being allowed or denied. For example, If This, Then That (IFTTT) integration would allow users to create macros that activate peripheral smart devices, such as external lights or recording devices, based on the allowance or denial of access.

The following paragraphs describe features of one or more embodiments.

Master key - Master key holders may access logs of all entries made or attempted that used keys issued in the master key holder's chain of trust. Master key holders may easily revoke any key "under" them (in the sense that the key is in the Master key holder's chain of trust). This is a particularly beneficial feature for home owner associations (HOAs), commercial office buildings and parks, and more. In an embodiment, a master key holder would not be able to issue another master key.

Administrator key - An embodiment defines an administrator key as the switching device owner, e.g., a landlord or HOA. The administrator key holder has sole authority to issue master keys to, e.g., tenants or homeowners. The administrator may revoke master keys. However, in an embodiment, the administrator would not typically issue regular keys (e.g., doorbell keys, party keys, etc.) and would not be able to revoke those keys that were issued by the master keys. If a master (which had a long chain of issued and valid keys underneath it) were to lose privileges, then revoking the master would also revoke all the child keys below it. Also, the administrator would not be able to see key logs of master keys or their children. In an embodiment, a master key holder would need to ask a holder of an administrator key to issue a second master key.

Multiple master keys-with this feature the server allows the owner-user of the switching device to issue keys that have master-key privileges. This is different from "standard" or "non-multiple" master keys, which may issue all key types except administrator keys and other master keys. In an embodiment, a master key that is issued from a multiple master key is considered to be a child of the multiple master key - it may be revoked by the multiple master key and it would be revoked if the multiple master key was revoked.

Doorbell Keys-with this feature, after a key expires, the recipient of that key may still click a link that would read "doorbell" instead of "open. " In an embodiment, all keys that expire automatically become doorbell keys. As would be expected after a key expires, the switching device (e.g., gate, garage, lock, etc.) will not open. However, the server will send a notification to the lowest key on the chain of trust that still has access. The user of that key will get a notification and, depending on the permissions or privileges granted to that user, may either allow access, deny access, or modify the key to allow further access. In an embodiment, all keys that expire automatically become doorbell keys after they expire.

Extended Doorbell key - with this feature, when the master key is "doorbelled" (i.e., notified by the server that access is being requested by the holder of an expired key), the holder of the master key has the option to extend the "doorbelling" key (e.g., for a day, week, etc.) so that the doorbell key returns to the key status it had before it expired to become a doorbell key. In an embodiment, the master key may also provide the extended doorbell key with additional meta-info at that time the key is extended.

Service Keys-a key holder who has permission for key creation may create a key that has access restricted by any combination of conditions, such as location, time of day, day of week, number of hours/days/months going forward, and number of uses.

Family Keys-a master key holder may create a family key. A family key may have an expiration date, or may be non-expiring. In addition, the key may have special features. For example, a family key may have the feature that when the family key is used after a child's curfew, the gate opens and the server notifies the master key.

Friend Keys-A friend key may be valid for a given time and then expire to become a doorbell key. For example, a friend key may be given access for a day and then revert to a doorbell key. This may happen many times. In an embodiment, a friend key (and a doorbell key) may provide extra information that is configurable before and after accepted entry. For example, people in a user's "friends" list may see the user's address and extra pre-entry meta-information. Pre-entry meta-information may include things such as the best place for an Uber or Lyft dropoff, a picture or description of the building, etc. The meta-information may also provide post-entry information such as a Wi-Fi name and password, or instructions (e.g., not to let the dog out when the gate opens or other such information). In an embodiment, when a friend key reverts to a doorbell key, the extra information of the friend key is deleted from the doorbell key.

Single-use Keys-a single-use key grants the user access only once. It is the type of key one might issue to an unknown entity, for example, a plumber who needs access for an emergency. A single-use key may expire after one use and revert to being a doorbell key.

Party Keys-master keys with this feature may create a party key, which is tied to an event rather than to a particular person. A party key may be shared freely by anyone who has the key and will expire after the event. In an embodiment, a master key may share this feature with child keys created by the master.

Sub-key Creation-with this feature, when permitted by the issuer of the key, a key holder may create a sub-key for others, creating a parent/sub-key relationship. Sub-keys are limited by any restrictions of the parent key holder. The parent key holder may add further restrictions to the sub-key, so that sub-keys may be more restricted, but never less restricted, than the parent key.

Remote Key Creation- with this feature, when permitted by the issuer of the key, a key holder may create and share a key with anyone connected by network to the key holder. The network over which the key is shared need not be the same network the switching device is connected to. For example, a key holder could share a key to a key receiver over a first network. The key receiver could accept the key over the first network, then connect to the relevant switching device and use the shared key on a second network.

In an embodiment, sharing a key also shares encapsulated metadata for the gate(s) that key controls. This removes the need for an extra or parallel step where such information is shared with the recipient of the key.

Key Revocation- with this feature, a master key has the right to revoke any keys in its chain of trust. This feature is available where the master key holder may access the internet. Also with this feature, a parent key may revoke any or all sub-keys (children keys) in the parent key's chain of trust.

Remote Open- this feature allows the gate to be operated from anywhere the user has an internet or other network connection with the server. This feature may be associated with a key (and subject to the key's privileges and limitations) and it may also be a stand-alone feature accessed by a user though a user device communicating with the server. In such situations, access to the server may be password-protected.

Bonding a Key to a Mobile Device-this feature provides the ability to limit key sharing by linking a particular key to a particular user device, for example, the first user device the key is used on. For example, a guest user may be sent a key and the key is bonded to the guest user's mobile phone, either with or without the user's permission. When a key is bonded to a particular device, if the device user wants to share access, the user must either have the right to create a new key, or must go up the chain of trust and request that a new key be created. With a bonded key, before the system grants access the system will check if the bonded key has been used before and if so, whether the present user of the key is using the key on the previously bonded device. If a user were to share a bonded key with someone else (after the key had bonded to the user's device), then the shared, bonded key would not be granted access and the parent would be notified. In an embodiment, the feature will warn the user before the first use of the key that the key will be bonded to the particular device being used. In an embodiment, the feature will allow the first user to specify that the bonded key may only be bonded to the guest device to which the bonded key was sent, e.g., the guest mobile phone with the telephone number to which the bonded key was sent.

Textable Web Link Key-this feature provides the ability to send a web link that grants access by the receiving user opening the link and clicking the open button on the page. With this feature there is no need for the recipient to download an application or log in to an account.

Emergency Access-this feature is optional and allows a particular key holder (e.g., a friend or neighbor) to be granted access even after a "doorbell" attempt fails. When this feature is used, notifications to related master and parent keys may be made more robust or emphatic. Also, the granted access may be logged as an emergency, which itself may prompt the logging of additional details and information regarding the access (e.g., audio files created by a microphone associated with the switching device). The feature provides for circumstances in which the owner-user might want to grant access to a trusted person without advance notice.

Smartphone System Notifications on Open-with the installation of an application on a smartphone, this feature provides a system notification on your smartphone of a switch being activated (e.g., a gate being opened) or a doorbell request being made by an expired key holder. This may be in addition to or instead of the user device receiving a text or email regarding the event.

Linking Multiple Devices to One Key-this feature allows for multiple switching devices to be linked to one key (e.g., a master key) and for multiple switching devices to be linked to one key for a particular use case. For example, a user may want to link a property gate and a garage together so that a single key may allow access to both the gate and garage. In an embodiment, the single key would be displayed on the user device with a button for each of the switching devices that were accessible using the single key (e.g., a "gate" button and a "garage" button).

Logging of Entries-with this feature a user with viewing privileges is provided with remote access to detailed logs of entries and entry attempts.

Friends List-with this feature the user application will allow the user to access a locally stored contacts list for easier sharing a key created by the user.

WiFi Connection-with this feature the switching device may connect to the internet through a local WiFi connection.

Ethernet Connection-with this feature the switching device may connect to the internet through a wired Ethernet connection.

Cellular Connection-with this feature the switching device may connect to the internet through a cellular connection.

Centralized control - with this feature some or all of the features will reside with the server and application, allowing such features to be easily updated.

Easy Security Patching-this feature is beneficial given the present potential for IoT hacking. With switching devices connected to the server, software updates such as security patches may be pushed as needed. In comparison, if a switching device is connected to an adhoc or local network (and not connected to the system server), the switching device would be difficult to update, particularly en masse with other switching devices.

Fail-over Connection-with this feature, if the switching device may connect to the internet through more than one connection method (e.g., a primary connection and a secondary connection), it may fail-over - it may switch to the secondary connection in the event the primary connection is lost.

Geo-fenced Notifications-this feature would allow the mobile device to notify a user that when a switching device (e.g., a gate) that the user may access comes into range. This feature allows for <NUM>-step access. With <NUM>-step access, when an accessible gate comes in range, the user application on the user device is activated. The user then only needs to press the "open" button for access, instead of having to find the application on the user device, open the user application, and then press "open.

Geo-fenced Access Control-this feature prevents a switching device (e.g., a gate) from activating unless the user (e.g., the user device) is within a certain distance from the switching device. This feature is active when the key holder does not have remote open privileges.

Continuous Connection Monitoring-with this feature, because a networked server is used to facilitate communication between a user and the switching device, that server may constantly monitor its connection with the switching device and monitor the switching device and notify the user if the connection or switching device fails. In comparison, if a switching device performs the function of allowing access (opening a gate) and also communicates directly with the user (e.g., directly to the user device using Bluetooth), then when the switching device fails the potential exists that the user may not be notified.

Claim 1:
A method for authorizing the control of a barrier (<NUM>; <NUM>), the method comprising:
receiving over a first network (<NUM>; <NUM>; <NUM>; <NUM>) from a first user device (<NUM>; <NUM>; <NUM>), by a barrier control component on a server (<NUM>; <NUM>; <NUM>; <NUM>), a first key and a first request to provide a second key to a second user device (<NUM>; <NUM>; <NUM>), the first key including a universally unique identifier access code being associated by the server with a first set of abilities pertaining to the opening of the barrier and pertaining to the providing of keys to additional user devices (<NUM>; <NUM>; <NUM>), the first request asking that the second key be associated with a second set of abilities pertaining to the control of the barrier and pertaining to the providing of keys to additional user devices;
retrieving, by the barrier control component from a storage device, first information associated with the first key and pertaining to the first set of abilities;
determining, by the barrier control component from the first information, whether the first set of abilities includes:
an ability to provide the second key to the second user device, and
an ability to associate each of the second set of abilities with the second key; and
when the determination indicates the first set of abilities includes the ability to provide the second key to the second user device and when the determination indicates the first set of abilities includes the ability to associate each of the second set of abilities with the second key:
storing, by the barrier control component in the storage device and associated with the second key, second information pertaining to the second set of abilities, and
providing, by the barrier control component to the second user device over a second network, the second key.