Patent Description:
Alarm systems, such as security (intrusion) and fire alarm systems, typically include one or more alarm panels (as alarm system controllers) to receive information from various sensors and to control various appliances distributed through a structured (or monitored) area such as a premises. For example, a security system may include a plurality of initiating devices (e.g., door and window contact switches, motion detectors, video motion detectors, glass breakage detectors, smoke/fire detectors, etc.), notification appliances (e.g., strobes, sirens, public announcement systems, etc.), and capture appliances (e.g., video cameras), all operably connected to one or more alarm panels. A fire alarm system may have somewhat differing initiating devices (e.g., smoke detectors, manually-actuated pull stations, carbon-monoxide detectors, etc.),.

During operation of the alarm system, the alarm panel may monitor electrical signals associated with the initiating (e.g., "point") devices for variations that may signal the occurrence of an alarm condition. For example, a variation in a particular electrical signal may represent the detection of smoke by a smoke detector in a corresponding area, or "zone," of a structure in which the smoke detector is located, and may cause the alarm panel to enter an alarm mode and issue an alarm notification as an alarm event. The alarm panel may be configured to respond to such a condition by initiating certain predefined actions, such as activating one or more of the notification appliances within the monitored structure.

The alarm panel may also be configured to forward alarm data to a central monitoring station (CMS) of an alarm monitoring company or service. Data outputted by the alarm panel toward the central monitoring station may include alarm data (e.g., concerning fire, smoke, intrusion, chemical, biohazard, panic and medical incidents).

While alarm systems and alarm panels are good at monitoring premises and providing alarm notifications, there has arisen a need to allow authorized personnel to obtain temporary (transient) access into monitored premises without triggering an alarm event (i.e., notification). As one example, there has arisen a need to allow authorized delivery personnel brief access into monitored premises for the purpose of placing delivery item(s) within the premises to secure against theft or to protect the item(s) against weather elements (e.g., rain). Given the increasing consumer trend toward utilizing on-line purchasing and at-home delivery, and the increasing criminal trend toward intercepting and stealing at-home delivery items, there is an ever increasing need to allow authorized personnel (e.g., delivery persons) temporary access to the premises.

Such need is not limited only to delivery. As another example, a shipping or courier company may have a need to pick up a shipping item secured within a premises. As another example, it may be convenient to allow authorized service personnel (e.g., repairmen) into a monitored business place for the purpose of servicing a malfunctioning apparatus. For example, allow a heating/ventilation/air-conditioning (HVAC) technician into a mechanical room to service a malfunctioning AC apparatus.

For convenience of discussion, a home delivery example will be used to provide a description of one example embodiment of the invention. However, the above home delivery and above other access examples are non-exhaustive and non-limiting, in that there are hundreds if not thousands of other situations where it might be convenient to allow authorized personnel temporary access to monitored premises without triggering an alarm event.

<CIT> discloses an apparatus for receiving a parcel through a door, the apparatus including a processor communicatively connected to a network interface connection, a passcode entry station, an interior camera, a non-transitory storage medium. The non-transitory storage medium includes a receive module, an obtain module, an unlock module, an alarm module, and a lock module. The receive module receives, over the network interface connection, a number of access configuration parameters. The number of access configuration parameters comprising an access code and an access time. The obtain module obtains, from an access code input device, an input access code. The input access code indicates that a user has requested limited access to an area for parcel delivery according to the access configuration parameters. The unlock module unlocks a door to allow parcel delivery. The monitor module monitors that the parcel delivery person remains in the field of vision of the interior camera. The alarm module issues, using the network interface connection, an alarm when the parcel delivery person leaves the field of vision of the interior camera. The lock module locks the door after the parcel is delivered.

<CIT> discloses a method and system for remotely monitoring deliveries, the method and system including detecting an arrival of a delivery at an access point and notifying a monitoring center of the arrival of the delivery at the access point. The method and system include verifying at least one verification detail, which correlates to the delivery, and sending a configuration signal from the monitoring center to the access point, which has instructions for controlling an entrance at the access point. The method and system can further include sending a second configuration signal from the monitoring center to the access point, which has instructions for controlling an entrance at the access point upon completion of the delivery. The method and system can further include sending an indication signal from the monitoring center to the access point, which has instructions for controlling an indicator at the access point.

<CIT> discloses apparatus, systems, methods, and related computer program products for providing home security/smart home objectives. More particularly, it relates to a plurality of devices, including intelligent, multi-sensing, network-connected devices, that communicate with each other and/or with a central server or a cloud-computing system to provide any of a variety of useful home security/smart home objectives.

In view of the forgoing, disclosed are arrangements (methods, apparatus, etc.) which provide the ability to allow authorized personnel temporary (transient) access into monitored premises without triggering an alarm event.

In one aspect, there is provided an alarm system controller as set out in claim <NUM>. In another aspect, there is provided a method as set out in claim <NUM>.

By way of example, specific embodiments of the disclosed arrangements will now be described, with reference to the accompanying drawings, in which:.

As discussed above, there is a greatly increasing need or desire to allow authorized personnel temporary (transient) access into monitored premises without triggering an alarm event. To this end, arrangements allowing authorized personnel temporary access into monitored premises without triggering an alarm event in accordance with the present disclosure, will now be described more fully hereinafter with reference to the accompanying drawings. In some examples, an alarm panel as an alarm system controller is configured with abilities to accept information and requests related to the temporary access, and to facilitate the temporary access. With some examples, another entity (e.g., alarm company server; integrator server) may substitute as an intermediary for brokering requests and notifications between an alarm panel and an access-gaining entity (e.g., delivery company).

Furthermore, these disclosed arrangements may be embodied in many different forms and are not to be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. In the drawings, like numbers refer to like elements throughout.

It will be appreciated by those of ordinary skill in the art that the temporary access arrangements described herein may be implemented for virtually any type of alarm, monitoring, or control system, including, but not limited to, fire alarm systems, burglar alarm systems, surveillance systems, air quality monitoring systems, inventory monitoring systems, etc., or any combination thereof, such as may be provided for detecting an alarm event (e.g., a security breach) or a warning condition (e.g., an elevated temperature) in a building, structure, enclosure, or area (collectively referred to herein as "premises" or "sites"). Many other applications are contemplated and may be implemented without departing from the scope of the present disclosure. All such applications are collectively referred to herein as "alarm systems" for convenience.

An exemplary alarm system in accordance with the present disclosure is depicted in <FIG>. The disclosed system <NUM> may include an alarm system <NUM> installed at a monitored site or premises P. The alarm system <NUM> may include an alarm panel <NUM> (as an alarm system controller) operably connected to a number of points <NUM> (e.g., initiating devices and/or notification appliances). Furthermore, the alarm system <NUM> may be communicatively coupled to a central monitoring station (CMS) <NUM> via connection <NUM>. In general, the central monitoring station <NUM> may be a server at a location remote from the monitored site. It is to be appreciated that the central monitoring station <NUM> may be a single computing device or may be multiple computing devices. The computing devices may be provided at a single location, or distributed at differing locations. For convenience of discussions within this disclosure, however, the central monitoring station <NUM> is referred to as a single device at a single location.

During operation of the alarm system <NUM>, various maintenance needs (such as repair and updating) may arise. Additionally, the central monitoring station <NUM> may be configured to validate the installation (or configuration) of the alarm system <NUM> to reduce the probability of future maintenance needs of the system. As may be appreciated, during installation of the alarm system <NUM>, a technician may place the points <NUM> throughout the site to be monitored by the alarm system <NUM>. Furthermore, the technician may configure the alarm panel <NUM> to recognize the points <NUM>. This may include organizing the points <NUM> into different zones, configuring the behavior of the alarm panel <NUM> in response to signals received from the points <NUM>, and configuring a connection <NUM> between the alarm panel <NUM> and the central monitoring station <NUM>.

In order to aid in the installation or aid in later maintenance, the technician may utilize a computing device <NUM>. The computing device <NUM> may be a portable computing device (e.g., a laptop computer, a tablet computer, a smart phone, or the like) that may be communicatively coupled to the alarm panel <NUM> via connection <NUM> and coupled to the central monitoring station <NUM> via connection <NUM>.

In general, the connections (or paths) <NUM>, <NUM> and <NUM> may be any type of data communication connection configured to allow signals to be transmitted between ones ofthe alarm panel <NUM>, the central monitoring station <NUM>, and the computing device <NUM>. It is noted that although the connections <NUM>, <NUM> and <NUM> are depicted in <FIG> as wireless connections, the connections may be wireless or may be wired. Furthermore, with some examples, the connections <NUM>, <NUM>, and/or <NUM> may be routed through a network (e.g., a TCP/IP network, a cellular network, a packet switched network, the Internet, or the like). Additionally, the connections <NUM>, <NUM> and <NUM> may not be a same (common) type of connection. For example, the connection <NUM> may be a cellular telephone connection, the connection <NUM> may be a universal serial bus connection, and the connection <NUM> may be a connection routed through the Internet. Still further, the connections <NUM>, <NUM> and <NUM> may each vary in type along a connection path thereof. For example, a connection may be partly routed through the Internet, partly routed through a cellular network, etc..

The disclosed system <NUM> may further include a communicator <NUM> installed as part of the alarm system <NUM> at the monitored site. The communicator <NUM> may contain cellular or some other type of communication capability, and may be provided integrated as part of the alarm panel electronics, or may be provided as a separate apparatus installed: within the alarm panel <NUM>; adjacent to the alarm panel <NUM>; or somewhere within the monitored site. For example, the communicator <NUM> may be installed within the alarm panel <NUM> or adjacent to the alarm panel <NUM>, if acceptable cellular reception is available at such installation locations. As another example, the communicator <NUM> may be installed elsewhere in the monitored site (i.e., remote from the alarm panel <NUM>) to achieve better cellular reception, better accessibility, etc..

Such communicator <NUM> may be a universal (i.e., generic) communicator which is capable of working properly with many differing types of alarm systems and/or alarm panels <NUM>. Alternatively, the communicator <NUM> may be proprietary in construction, and designed to work with a particular brand/model of alarm system and/or alarm panel <NUM>.

One purpose of the communicator <NUM> may be to monitor (see <FIG> dashed line <NUM>) for failures in communications between the alarm panel <NUM> and the central monitoring station <NUM> along the connection <NUM>. As long as the connection between the alarm panel <NUM> and the central monitoring station <NUM> remains viable (i.e., working properly), the communicator device <NUM> would do nothing with any data available from the connection <NUM>. In the event of a detected failure of the connection <NUM>, the communicator <NUM> would then utilize (e.g., activate, establish) the communicative coupling connection <NUM> to provide an alternative (e.g., emergency; fail-over) communications path or channel between the alarm panel <NUM> and the central monitoring station <NUM>. The communicator <NUM> then would access and route the data through the connection <NUM>, to the central monitoring station.

As one non-exhaustive, non-limiting connection failure example, the connection <NUM> may be provided via a Plain Old Telephone Service (POTS) hardwire line or may be provided via the Internet, and failure thereof may result because of a physical line cut (e.g., by an intruder) or loss of Internet connection (e.g., by storm-induced outages). In contrast, the connection <NUM> may be a cellular connection. That is, the connections <NUM> and <NUM> can be of differing types from one another such that a type of failure affecting connection <NUM> will hopefully not also affect connection <NUM>. Such allows the alarm panel <NUM> a redundant ability to communicate with the central monitoring station <NUM>, even upon failure of the primary connection <NUM>.

While the above example represents a combined mode where the communicator <NUM> partially operates in a passive mode and partially operates in an active mode, in some alarm system installations, the connection <NUM> may be non-existent, and may be purposefully replaced by connection <NUM> and with the communicator <NUM> only operating in the active mode. As one situation where this might happen, consumers have trended toward eliminating residential POTS hardwire lines to save costs. In such situations where there is an absence of the connection <NUM>, the connection <NUM> might be used as a primary connection between the alarm panel <NUM> and the central monitoring station <NUM>.

Sometimes connection <NUM> failures may even result in data being unavailable along such failed connection <NUM>. In such situations or in situations where the connection <NUM> is non-existent, the communicator <NUM> would not be able to obtain alarm panel data via the connection <NUM>. Accordingly, a connection <NUM> (e.g., a wired USB connection) may be used to provide alternative (direct) communications between the alarm panel <NUM> and the communicator <NUM>. Such connection <NUM> would serve to get data from the alarm panel <NUM> to the communicator <NUM> in view of no information being delivered from the alarm panel <NUM> to the communicator <NUM> via the connection <NUM>.

Another purpose of the communicator <NUM> may be to facilitate communications between outside entities (e.g., an alarm company server; an alarm equipment manufacturer server; an integrator company) and the alarm panel <NUM>. Accordingly, the communicator <NUM> together with the connection <NUM> may also be utilized to allow such communications between the outside entities and the alarm panel <NUM>. For security, some type of authentication capabilities may be configured into the alarm panel <NUM> and/or communicator <NUM> to require authentication between any outside entity (e.g., CMS, alarm company server; alarm equipment manufacturer server; integrator company) and the alarm panel <NUM> and/or communicator <NUM>, before further communications are allowed between the outside entities and the alarm panel <NUM> and/or communicator <NUM>.

For convenience of discussions and for a sake of brevity, authentication capabilities and success of authentication between all electronic entities discussed as communicating within this disclosure, will be presumed and will not be substantially discussed further.

To assist in a better understanding of the invention, a disadvantaged temporary access example concerning delivery of an item to a home premises will now be described using <FIG>, <FIG>. More particularly, the alarm system <NUM> of the home premises P may have a number of points <NUM>, including points 14A, 14B monitoring an entry ZoneE, and a point 14C monitoring a secondary ZoneS. Other remaining points <NUM> are provided within a remainder ZoneR.

Further shown in <FIG> are a delivery company server <NUM> connected (via a connection <NUM>) to a delivery company cloud <NUM>, which in turn is connected (via a connection <NUM>) to a delivery person device DPD carried by a delivery person DP. The delivery company cloud is further connectable (via a connection <NUM>) to a door lock DL securing a door of the premises P. The door lock DL may have wireless (e.g., cellular or Internet) connection capabilities, and may be remotely controllable, for example, by a remote entity issuing some type of lock and/or unlock commands over an established connection. Non-exhaustive example wireless protocols may include Bluetooth, GPS, GSM/CDMA, WiFi/WiMax and ZigBee. In one example, the door lock DL may be sourced from, and proprietary to, a delivery company. In another example, the door lock DL may be a commercially available lockset. In either example, the delivery company server <NUM> may be privy to access information for authenticating, connecting to and controlling such door lock DL. A premises' resident may have provided such access information to the delivery company (e.g., in advance of an expected delivery).

Next, in general, the delivery company server <NUM> may be a server at a location remote from the monitored site or premises P. It is to be appreciated that the delivery company server <NUM> may be a single computing device or may be multiple computing devices. The computing devices may be provided at a single location, or distributed at differing locations. For convenience of discussions within this disclosure, however, the delivery company server <NUM> is referred to as a single device at a single location.

Further, although <FIG> illustrates delivery company resources (e.g., delivery company server <NUM>, delivery company cloud <NUM>, etc.) of only a single delivery company for sake of brevity and simplicity, it is to be understood that a real-world environment would involve multiple (e.g., independent) delivery companies. A non-limiting, non-exhaustive listing of delivery companies might include: ABC Package Delivery Company (ABC-PDCo); DEF Package Delivery Company (DEF-PDCo); XYZ Package Delivery Company (XYZ-PDCo); etc. It will be assumed throughout this disclosure that the <FIG> delivery company resources (e.g., delivery company server <NUM>, delivery company cloud <NUM>, etc.) illustrated belong to ABC-PDCo.

In general, the connections <NUM>, <NUM> and <NUM> may be any type of data communication connection configured to allow signals to be transmitted between ones of the delivery company server <NUM>, the delivery cloud <NUM>, the delivery person device DPD and the door lock DL. It is noted that although the connections <NUM>, <NUM> and <NUM> are depicted as <FIG> wireless connections, the connections may be wireless or may be wired. As examples, the connections <NUM>, <NUM> and <NUM> may be routed through a network (e.g., a TCP/IP network, a cellular network, a packet switched network, the Internet, or the like). Additionally, the connections <NUM>, <NUM> and <NUM> may not be a same (common) type of connection. For example, the connection <NUM> may be routed through the internet, while the connections <NUM> and <NUM> may be cellular telephone connections. Still further, the connections <NUM>, <NUM> and <NUM> may each vary in type along a connection path thereof. For example, a connection may be partly routed through the Internet, and partly routed through a cellular network.

The delivery person device DPD may be, for example, a cell phone, smart phone, personal digital assistant (PDA), tablet, notebook, proprietary computing unit, etc. If the delivery person device DPD is an easily-carried mobile device such as a cell phone, smart phone, PDA, tablet, notebook, etc., then the delivery person device DPD may be advantageously carried by the delivery person DP wherever he/she might go, e.g., carried by the delivery person DP as he/she exits a delivery vehicle and approaches a premises door to make delivery.

<FIG> show example flow operations <NUM> and <NUM> performed by the delivery company server <NUM> and delivery person device DPD, respectively, for the delivery person DP to gain temporary access to the premises P to place a delivery item therein. More particularly, after <FIG>'s start <NUM>, the delivery company server <NUM> determines (operation <NUM>) estimated delivery data for a subject delivery, with the data including, for example: an expected delivery date and time-of-day delivery window. Such data items are non-limiting and non-exhaustive of differing data items which may be determined, and are simply given as examples.

At operation <NUM>, an optional operation of informing a designated recipient (e.g., a homeowner who ordered the delivery item) of the estimated delivery date and time-of-day delivery window for the subject delivery, may be performed. Next, at operation <NUM>, the delivery person device DPD may be loaded with a (e.g., daily; work shift; etc.) delivery schedule which may include delivery data (e.g., delivery map/directions; delivery address; recipient's name; number of delivery items; etc.) for the subject delivery. That is, loading from the delivery company server <NUM> into the delivery person device DPD may be accomplished via the delivery company cloud <NUM> and connections <NUM>, <NUM>.

Next, after <FIG>'s start <NUM> operation, the delivery person device DPD may receive, store and display the (e.g., daily; work shift; etc.) delivery schedule (operation <NUM>). Included within the displayed delivery schedule is the information regarding the subject delivery. At some point during the day, the delivery person DP arrives at a door of the delivery premises P. Through use of an input device (e.g., hard button, soft button, touch screen, keyboard, etc.), the delivery person inputs, and the delivery person device DPD accepts, an access request to request access to the premises for the subject delivery (operation <NUM>). At operation <NUM>, the delivery person device DPD sends the access request to the delivery company server <NUM>. Sending from the delivery person device DPD to the delivery company server <NUM> again may be accomplished via the delivery company cloud <NUM> and connections <NUM>, <NUM>.

Next, at <FIG>'s operation <NUM>, the delivery company server <NUM> receives and stores (e.g., caches) the access request from the delivery person device DPD, requesting access to the delivery premises for the subject delivery. The delivery company server <NUM> may then connect and send an unlock command to the door lock DL (operation <NUM>). A delivery person DP may become aware of the unlock via any number of ways, e.g., by hearing the door lock unlock, by an indicator display or (e.g., green) light on the lock, by a "Door unlocked. " message sent from the delivery company server <NUM> and displayed on the delivery person device DPD, etc. The delivery person DP then opens the unlocked door to gain access to an inside of the premises P, theoretically just long enough and far enough into the premises to deposit the delivery item inside the premises. The delivery person DP then theoretically exits the premises and manually closes and locks the door behind him/her.

After delivery and exiting, and again using the input device (e.g., hard button, soft button, touch screen, keyboard, etc.), the delivery person inputs, and the delivery person device DPD accepts, a "subject delivery complete" indication (operation <NUM>). At operation <NUM>, the delivery person device DPD sends the indication to the delivery company server <NUM>. Sending from the delivery person device DPD to the delivery company server <NUM> again may be accomplished via the delivery company cloud <NUM> and connections <NUM>, <NUM>. At operation <NUM>, operations of the delivery person device DPD (with respect to this subject delivery) end.

At <FIG>'s operation <NUM>, the delivery company server <NUM> receives and stores (e.g., caches) the "subject delivery complete" indication from the delivery person device DPD. Responsive thereto, the delivery company server <NUM> sends a lock command to the door lock DL (operation <NUM>). At operation <NUM>, an optional operation of informing a designated recipient (e.g., a homeowner who ordered the delivery item) of the completed subject delivery, may be performed. At operation <NUM>, operations of the delivery person device DPD (with respect to this subject delivery) end.

The above-described example access operations may be less-than-desirable in a number of regards. First, as premises access is being gained by an entity (e.g., delivery company and/or delivery person DP) which is not the premises' resident or any alarm company (e.g., CMS) agent, there is no coordination with deactivating/reactivating the alarm system in conjunction with the temporary access. Accordingly, it is highly likely that the delivery person DP's entry will result in an alarm event if the alarm system is left activated. That is, at least alarm points 14a (e.g., a motion detector) and 14B (e.g., a (door) contact switch (CS)) monitoring in the entry ZoneE near the door will detect and signal the delivery person DP's entry to the alarm panel <NUM>, which in turn would generate the alarm event (e.g., alarm notification). As non-exhaustive examples, contact switches (CS) may be mounted on a door or window, and may be triggered by an opening, closing or movement of the door or window. Alarm point 14c may be, for example, a video motion detector.

As one solution, the premises' resident could deactivate (turn-off) the alarm system <NUM> for the entire day or for the entire time-of-day delivery window period for when the delivery was expected. As a differing option, the delivery company might contact the premises' resident (e.g., via text message) at a time immediately preceding (e.g., minutes before) an imminent access, so as to have the premises' resident turn the alarm system off for the access. Another resident contact would be needed at a time immediately after the access, to turn the alarm system back on. However, such multiple calls require difficult cooperation and coordination among a number of entities, and thus is highly likely to experience failure. Further, contacting represents a significant burden on the premises' resident to remain available for a significant time window within which the subject delivery might occur.

In any event, deactivating the alarm for an entire day or for many hours is not an attractive option in that it leaves the premises vulnerable. That is, if an entirety of the alarm system is deactivated, the delivery person DP may freely wander throughout the premise, to steal, violate privacy, etc., or perform other undesirable activities (e.g., check medicine cabinets for prescription drugs; scope out valuables throughout the premises for later criminal activities, etc.). Additionally, irrespective of any delivery access, deactivating leaves the premises vulnerable to criminals in general.

Next, there may be no guarantee that the delivery person DP and/or the delivery company will actually lock the door after the delivery has been completed. As one example, it is highly likely that the delivery person DP might be under a tight delivery schedule, and that rushing onward to a next delivery might easily make him/her forget to lock the door and/or notify the delivery company <NUM> that the delivery is complete. If the delivery person DP forgets to notify the delivery company <NUM>, the door may remain unlocked until the homeowner returns home.

Discussion turns next to a more desirable (example) approach, i.e., one wherein an alarm controller such as an alarm panel (not some outside entity) is configured to provide temporary access operations, control alarm system behavior and provide a guarantee that the door gets locked. To enable such approach, further shown within <FIG> are an alarm panel company server <NUM> connected (via a connection <NUM>) to an alarm panel company cloud <NUM>, which in turn is connected (via a connection <NUM>) to the communicator <NUM> connected (via the connection <NUM>) to the alarm panel <NUM>. Thus, the combination of the communicator <NUM> together with the connections <NUM>, <NUM>, <NUM> and cloud <NUM>, may be utilized to also allow communications between the alarm panel company server <NUM> and the alarm panel <NUM>.

In general, the alarm panel company server <NUM> may be a server at a location remote from the premises P or monitored site. It is to be appreciated that the alarm panel company server <NUM> may be a single computing device or may be multiple computing devices. The computing devices may be provided at a single location, or distributed at differing locations. For convenience of discussions within this disclosure, however, the alarm panel company server <NUM> is referred to as a single device at a single location.

The alarm panel company server <NUM> may belong to, and be maintained by, the alarm panel <NUM>'s manufacturer or supplier. The alarm panel manufacturer or supplier may be a logical choice for configuring temporary access abilities to the alarm panel, in that the manufacturer or supplier may be the entity which is most privy to understanding the construction and inner workings (e.g., firmware, software, command set, modes, limitations, etc.) of the alarm panel and system. Plus, the alarm panel manufacturer or supplier may strongly discourage other entities from modifying the alarm panel and system, out of an abundance of caution that outside modification might negatively affect the operations and/or security provided by the alarm panel and/or alarm system.

Further shown in <FIG> is the alarm panel company cloud <NUM> also being connected (via the connection <NUM>) to the delivery company cloud <NUM>. Thus, the alarm panel company server <NUM> and the delivery company server <NUM> may communicate with each over via the combination of the connections <NUM>, <NUM>, <NUM> and clouds <NUM>, <NUM>, to allow, for example, communication and cooperation between the alarm panel company server <NUM> and the delivery company server <NUM>, to accomplish a temporary access to the house premises P.

The alarm panel company server <NUM> may be further connected to the CMS <NUM> via connection <NUM>. Such connection <NUM> may allow the direct exchange of data therebetween. For example, a zone or points list or other system configuration data may be forwarded from the central monitoring station <NUM> to the alarm panel company server <NUM>. The alarm panel company server <NUM> may need such information when configuring the alarm panel with temporary access operations/abilities, and/or when setting up a new account for a new temporary access subscriber.

As another example, the central monitoring station <NUM> may be configured to send a copy of alarm notifications to the alarm panel company server <NUM> in real-time, in addition to any reporting of the alarm notifications to the premises' resident. That is, the alarm panel company server <NUM> may need to be aware of any alarm events which might be associated with any temporary access which it might oversee. As one example, upon an alarm event occurring in connection with (i.e., at as same time as) a given temporary access, the alarm panel company server <NUM> may immediately contact the delivery company involved with the given temporary access, and request explanation of the cause of the alarm event from the delivery company (e.g., did the delivery person DP stray into the house too far, attempting to use a bathroom?). The alarm panel company server <NUM> may then convey that explanation back to the CMS <NUM> and/or the premises' resident subscriber (e.g., with an apology).

In short, the alarm panel manufacturer or supplier may have a strong interest in overseeing that temporary accesses are conducted without any alarm events. That is, alarm notifications resultant from problems with temporary accesses may irritate the premises' resident subscriber, and the alarm events may even cost the subscriber a fine issued by a local safety authority (e.g., the police) for a false alarm and/or too many alarms. If any particular delivery company incurs an unacceptable number of alarm events (e.g., by repeated delivery company and/or delivery person errors), the alarm panel company may choose to sever a business relationship with that delivery company and prohibit them from further temporary accesses.

The <FIG> alarm panel is further connectable (via a connection <NUM>) to the door lock DL securing the door of the premise, and is connectable (via a connection <NUM>) to a video camera VC positioned to record a real-time image of an inside of the premises within at least the entry ZoneE, when instructed to do so. With the present example, the alarm panel <NUM> would control the residence's door lock DL, and the delivery company server <NUM> would not have any ability to communicate with or lock/unlock the door lock DL. By having the alarm panel <NUM> control the door lock DL, the locking/unlocking of the door lock DL can be advantageously timed properly in conjunction with deactivating/reactivating portions (i.e., zones) of the alarm system as discussed later.

In general, the connections <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may be any type of data communication connection configured to allow signals to be transmitted between ones ofthe alarm panel <NUM>, the CMS <NUM>, the communicator <NUM>, the alarm panel company server <NUM>, the alarm panel company cloud <NUM>, the delivery company cloud <NUM>, the door lock DL and the video camera VC. It is noted that although the connections <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> are depicted as <FIG> wireless connections, the connections may be wireless or may be wired. As examples, the connections <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may be routed through a network (e.g., a TCP/IP network, a cellular network, a packet switched network, the Internet, or the like). Additionally, the connections <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may not be a same (common) type of connection. For example, the connection <NUM> may be routed through the internet, while the connections <NUM> and <NUM> may be cellular telephone connections. Still further, the connections <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may each vary in type along a connection path thereof. For example, a connection may be partly routed through the Internet, and partly routed through a cellular network.

<FIG> show example flow operations <NUM>-<NUM> performed by the delivery company server <NUM>, alarm panel company server <NUM> and alarm panel <NUM>, as an improved approach for the delivery person DP to gain temporary access to the premises P to place a delivery item therein. In addition, previously-discussed <FIG> pertaining to operations performed by the delivery person device DPD, is also applicable to explanation of this approach.

In beginning discussions, after <FIG>'s start <NUM>, the delivery company server <NUM> determines estimated delivery data (operation <NUM>) for a subject delivery, with the data including at least: a delivery (e.g., invoice or tracking) number associated with the delivery; expected delivery date; time-of-day delivery window; and estimated length of access for the subject delivery. The delivery (e.g., invoice or tracking) number assigned to the subject delivery, may serve as an identifier useable across time and across entities (e.g., delivery company server <NUM>; alarm panel company server <NUM>; alarm panel <NUM>) to identify instances of data and communications which are connected with (i.e., pertain to) a same subject delivery. The above data items are non-limiting and non-exhaustive of differing data items which may be determined, and are simply given as examples.

<FIG> illustrates an example database <NUM> which may be maintained by a delivery company server <NUM> in connection with deliveries it is overseeing. Such database may (for example) contain the data items stored within the following example columns: <NUM> (Delivery#) storing a delivery (e.g., invoice or tracking) number associated with each delivery; <NUM> (ShipCo) storing a company name from which the delivery item originated; <NUM> (DeliveryAddr) storing an address where each delivery should be delivered; <NUM> (DeliveryCity) storing a city associated with the address; <NUM> (DeliveryState) storing a state associated with the address; <NUM> (RecipeintName) storing a recipient's name for each delivery; <NUM> (RecipientEmail) storing a recipient's email address; <NUM> (RecipientCell) storing a recipient's cell phone number; <NUM> (DelivStatus) storing a (e.g., Pending, Complete, etc.) status of each delivery; <NUM> (EstDelivDate) storing an estimated delivery date (e.g., <NUM>) determined for each delivery; <NUM> (EstDelivWindow) storing an estimated time-of-day delivery window (e.g., <NUM>-<NUM> am) for each delivery; <NUM> (ActDelivDate) storing an actual date (e.g., <NUM>) when delivery was completed; <NUM> (#DelivItems) storing a number of items (e.g., <NUM>; <NUM>) to be delivered at each delivery; <NUM> (EstLengthAcc) storing an estimated (e.g., number of minutes) length of access (e.g., <NUM>) into a premises for each delivery; etc. Item <NUM> may represent additional data columns. Such data items are non-limiting and non-exhaustive of differing data items which may be databased, and are simply given as examples. Row <NUM> contains column headings, while rows <NUM>-<NUM> each pertain to a different delivery, respectively. It should be understood that such database may actually contain significantly more rows than the few example rows illustrated, i.e., only a limited number of rows are illustrated and described for sake of brevity and simplicity of this disclosure.

In turning back to <FIG>, operation <NUM>, the designated recipient (RecipeintName)(e.g., a homeowner who ordered the delivery item) may optionally be sent the: delivery number (Delivery#); company from which the delivery item originated (ShipCo); estimated delivery date (EstDelivDate); and time-of-day delivery window (EstDelivWindow), for the subject delivery. Such data items are non-limiting and non-exhaustive of differing data items which may be sent, and are simply given as examples. Sending of such information to the designated recipient may be accomplished, for example, via email (to RecipientEmail) and/or text messaging (to RecipientCell).

Next, at operation <NUM>, the delivery person device (DPD) may be loaded with a (e.g., daily; work-shift; etc.) delivery schedule which may include select ones of the delivery data from the database <NUM> for each delivery (including the subject delivery) that a delivery person DP is tasked to make. For example, the delivery person device DPD may be loaded with the: delivery (e.g., invoice or tracking) number (Delivery#); recipient's name (RecipientName); delivery address (DeliveryAddr); delivery city (DeliveryCity); delivery state (DeliveryState); estimated time-of-day delivery window (EstDelivWindow); number of delivery items (#DelivItems); estimated time length of access (EstLengthAcc); etc., for the subject delivery. Such data items are non-limiting and non-exhaustive of differing data items which may be loaded, and are simply given as examples. Loading from the delivery company server <NUM> into the delivery person device DPD may be accomplished via the combination of the delivery company cloud <NUM> and connections <NUM>, <NUM>.

Next, at operation <NUM>, the delivery company server <NUM> informs the alarm panel company server <NUM> of select ones of the delivery data (e.g., delivery (e.g., invoice or tracking) number (Delivery#); shipping company (ShipCo); recipient's name (RecipientName); delivery address (DeliveryAddr); delivery city (DeliveryCity); delivery state (DeliveryState); estimated time-of-day delivery window (EstDelivWindow); number of delivery items (#DelivItems); estimated time length of access (EstLengthAcc); etc.) for the subject delivery. Such data items are non-limiting and non-exhaustive of differing data items which may be sent, and are simply given as examples. The Sending from the delivery company server <NUM> to the alarm panel company server <NUM> may be accomplished via the combination of the alarm panel company cloud <NUM>, delivery company cloud <NUM>, and connections <NUM>, <NUM> and <NUM>.

The delivery (e.g., invoice or tracking) number (Delivery#) assigned to the subject delivery, may allow the alarm panel company server <NUM> to identify and relate other data and communications over time, which correspond to the subject delivery. Further, the delivery address (DeliveryAddr), delivery city (DeliveryCity) and delivery state (DeliveryState) may help the alarm panel company server <NUM> determine which alarm panel that the subject delivery corresponds to, i.e., out of the thousands of alarm panels which the server <NUM> might oversee temporary access services for.

That is, <FIG> illustrates an example database <NUM> which may be maintained by the alarm panel company server <NUM> for overseeing the alarm panels of its subscribers. Such database may (for example) contain data items detailed by the following example columns: <NUM> (PanelSN) storing a serial number (e.g., <NUM>; <NUM>; etc.) associated with the subscriber's alarm panel; <NUM> (PanelIPAddr) storing an Internet Protocol (IP) address (e.g., <NUM>. <NUM>; <NUM>. <NUM>; etc.) associated with the subscriber's alarm panel; <NUM> (PanelAddr) storing a street address where the subscriber's alarm panel is located; <NUM> (PanelCity) storing a city associated with the street address; <NUM> (PanelState) storing a state associated with the street address; <NUM> (PanelCustomer) storing a customer's name associated with the subscriber's alarm panel; <NUM> (PanelCustEmail) storing the customer's email address; <NUM> (PanelCustomerCell) storing the customer's cell phone number; <NUM> (ZoneAccess?) storing an indication of whether a temporary zoned access is "Allowed" or "Not Allowed" with respect to the customer's alarm panel. Item <NUM> may represent additional data columns. Such data items are non-limiting and non-exhaustive of differing data items which may be databased, and are simply given as examples. Row <NUM> contains column headings, while rows <NUM>-<NUM> pertain to each alarm panel subscriber, respectively.

It should be understood that such database may actually contain significantly more rows, and each row would pertain to a differing alarm panel. Only a limited number of rows are illustrated and described for sake of brevity and simplicity of this disclosure.

Further, while <FIG> illustrates only an alarm system <NUM> and alarm panel <NUM> installed in a single premises P (e.g., house) for sake of brevity and simplicity, it is to be understood that a real-world environment would involve many other alarm systems and alarm panels installed in many premises. Further, a given premises may have multiple alarm panels. A non-exhaustive, non-limiting listing of differing types of premises may include: houses; apartments; buildings; businesses; restaurants; stores; churches; etc..

The alarm panel company server <NUM>, after <FIG>'s start operation <NUM>, receives (operation <NUM>) and stores (e.g., caches) the select ones of the delivery data (e.g., delivery (e.g., invoice or tracking) number (Delivery#); shipping company (ShipCo); recipient's name (RecipientName); delivery address (DeliveryAddr); delivery city (DeliveryCity); delivery state (DeliveryState); estimated time-of-day delivery window (EstDelivWindow); number of delivery items (#DelivItems); estimated time length of access (EstLengthAcc); etc.. ) for the subject delivery. In addition, it will be assumed that the alarm panel company server <NUM> can determine the identification of the package delivery company (e.g., ABC-PDCo) which sent the delivery data (e.g., from information within the communication), and that the alarm panel company server <NUM> stores (e.g., caches) a delivery company identifier (DelivCoId) in association with the delivery data of the subject delivery.

By matching ones of the received recipient's name (RecipientName), delivery address (DeliveryAddr), delivery city (DeliveryCity) and/or delivery state (DeliveryState) data received from the package delivery company server <NUM> (see, e.g., <FIG>'s row <NUM> data as an example), against ones of the <NUM> (PanelCustomer) customer's name, <NUM> (PanelAddr) street address, <NUM> (PanelCity) city and/or <NUM> (PanelState) state data stored in the database <NUM>, the alarm panel company server <NUM> may determine that the received data for the subject delivery, pertains to particular subscriber panel. In this example, it is assumed that it is determined that the subject delivery pertains to the subscriber panel associated with Row <NUM>.

It is noted that matching may not be achieved across all items which are compared. For example, while the compared address, city and state data of the above-mentioned rows <NUM> and <NUM> may be found to match, a received recipient's name (RecipientName) originating from the delivery company server's database <NUM> (see row <NUM>, column <NUM>), and a (PanelCustomer) customer's name stored in the alarm panel company server's database <NUM> (see row <NUM>, column <NUM>), do not match. Accordingly, the alarm panel company server <NUM> may make its determination based upon a partial match (e.g., three out of four data item matches). In the present example, it will be assumed that the alarm panel company server <NUM> has determined that the received data corresponds to the <FIG> row <NUM> having the PanelSN of <NUM>, and having the PanellPAddr of <NUM>.

Next, the alarm panel company server <NUM> may then check further data stored within row <NUM> at column <NUM> (ZoneAccess?) to confirm that a temporary zoned access is "Allowed" with respect to the subscriber's alarm panel having the PanelSN of <NUM>. Whether or not temporary zoned access is "Allowed" may be based upon many criteria, such as: decision made by preference of the premises' resident; home-owners association (HOA) rules; existing equipment (e.g., points) capabilities/limitations; etc. That is, not all alarm panels or subscribers will permit temporary access to be allowed.

If a temporary zoned access is allowed (such as assumed in the present example), the alarm panel company server <NUM> then utilizes the obtained PanellPAddr (e.g. <NUM>. <NUM>) to inform the alarm panel <NUM> (<FIG> operation <NUM>) of at least a subset of the select ones of the stored (e.g., cached) delivery data. As one example, the alarm panel company server <NUM> may inform the alarm panel <NUM> of the: delivery company identifier (DelivCold); delivery (e.g., invoice or tracking) number (Delivery#); shipping company (ShipCo); estimated delivery date (EstDelivDate); time-of-day delivery window (EstDelivWindow); number of delivery items (#Delivltems); and estimated time length of access (EstLengthAcc); etc.. ), for the subject delivery. Such data items are non-limiting and non-exhaustive of differing data items which may be sent, and are simply given as examples. Sending from the alarm panel company server <NUM> to the alarm panel <NUM> may be accomplished via combination of the alarm panel company cloud <NUM> and connections <NUM>, <NUM> and <NUM>.

Next, after start operation <NUM> in <FIG>, the alarm panel <NUM> receives (operation <NUM>) and stores (e.g., caches) the delivery data from the alarm panel company server <NUM>, including at least the: delivery company identifier (DelivCold); shipping company (ShipCo); delivery (e.g., invoice or tracking) number (Delivery#); estimated delivery date (EstDelivDate); time-of-day delivery window (EstDelivWindow); number of delivery items (#Delivltems); and estimated time length of access (EstLengthAcc); etc.. ), for the subject delivery.

Next, at operation <NUM>, the alarm panel considers some of the delivery data (e.g., the estimated length of access; number of delivery items) to determine whether to set its own maximum length of access time for the subject delivery. The determination of a maximum length of access time may be important to provide an extra buffer of access time to avoid a situation where an inadvertent alarm event is triggered by the access time running out before the access is complete. More particularly, there may be instances where a delivery person (DP) needs extra access time, for example, in a situation where the DP has difficulties fitting a bulky delivery item through the premises' door. Accordingly, as one example, if the delivery company server <NUM> had indicated (e.g., via the estimated delivery data) that the estimated length of access for the subject delivery was <NUM> minutes, the alarm panel may be configured to set <NUM> minutes as the maximum length of access time for the subject delivery, i.e., to provide that extra access time buffer in an attempt to better guarantee that an inadvertent alarm event is not incurred.

As another example being not in accordance with the invention, the determination of a maximum length of access time may also be important to avoid a situation where an incoming estimated time length of access (EstLengthAcc) data attempts (e.g., through mistake or through mischievous intent) to set an unacceptably long access time. As one example, if incoming data had indicated that the estimated length of access for the subject delivery was an unreasonably long <NUM> minutes, the alarm panel may be configured to set an overriding <NUM> minutes as the maximum length of access time for the subject delivery. A maximum allowable access time limitation which would be applicable across all deliveries and delivery companies, may be preprogrammed into, and stored within, the alarm panel for use when needed.

<FIG> illustrates an example database <NUM> which may be maintained by the alarm panel <NUM> for overseeing and effecting temporary accesses to the premises P. Such database may (for example) contain data items detailed by the following example columns: <NUM> (DelivCoID); <NUM> delivery tracking number (Delivery#); <NUM> shipping company (ShipCo); <NUM> delivery status (DelivStatus); <NUM> estimated delivery date (EstDelivDate); <NUM> estimated time-of-day delivery window (EstDelivWindow); <NUM> number of delivery items (#DelivItems); <NUM> estimated time length of access (EstLengthAcc); <NUM> maximum time length of access (MaxLengthAcc), for each delivery to the premises P. Item <NUM> may represent additional data columns. Such data items are non-limiting and non-exhaustive of differing data items which may be databased, and are simply given as examples. Row <NUM> contains column headings, while rows <NUM>-<NUM> pertain to each delivery, respectively.

In continuing discussion of alarm panel <NUM>, at <FIG>'s operation <NUM>, the alarm panel <NUM> determines and/or presets an access plan for the subject delivery, using ones of the stored delivery data within the database <NUM>. In one example, the alarm panel <NUM> would use various data (e.g., MaxLengthAcc; EstDelivDate; EstDelivWindow) for the subject delivery, to fill-in (i.e., complete) a predefined flow such as flow <NUM> of <FIG>. In the event that the alarm panel has data stored for several outstanding deliveries, then the alarm panel may set-up a corresponding number of access plans. Each access plan may be associated with a particular delivery via use of the delivery tracking number (Delivery#), so that the alarm panel <NUM> can utilize the delivery tracking number (Delivery#) of an incoming access request to know which prepared access plan to apply (e.g., implement).

Execution of the flow <NUM> would, in one example, be triggered via receipt of the incoming access request originating from the delivery person device DPD. That is, the access plan may be set up in advance of the DP arriving at the premises' door, and the access request may be generated by the DP when he/she arrives at the door with delivery item in hand. Triggering execution of the temporary access flow <NUM> via receipt of the incoming access request is advantageous, in that the alarm system remains fully armed right up until the temporary access. In discussion of the present example, it will be assumed that there is a separation in time (e.g., minutes; hours; days; etc.) between when the alarm panel sets up the access plan for the subject delivery and when the access request for the subject delivery is incoming. Implementation, however, is not limited to having a separation time, and the access plan set up and access request receipt may occur concurrently, simultaneously, in parallel, etc., in some implementations.

One example of the originating and sending of the access request, may be explained as follows. At some point during the day, the DP arrives at a door of the delivery premises P. Through use of an input device (e.g., hard button, soft button, touch screen, keyboard, etc.), the delivery person inputs, and the delivery person device DPD accepts, an access request to request access to the premises P for the subject delivery (<FIG> operation <NUM>). At operation <NUM>, the delivery person device DPD sends the access request (e.g., together with the delivery tracking number (Delivery#)) to the delivery company server <NUM>. Again, sending of the delivery tracking number (Delivery#) together with the access request, allows the various entities (e.g., delivery company server <NUM>; alarm panel company server <NUM>; alarm panel <NUM>) to know to which scheduled delivery and delivery data the access request pertains.

At Operation <NUM> of <FIG>, the delivery company server <NUM> receives the access request (e.g., together with the delivery tracking number (Delivery#)) from the delivery person device DPD, and forwards the same (operation <NUM>) to the alarm panel company server <NUM>. Likewise, at <FIG>'s operation <NUM>, the alarm panel company server <NUM> receives the access request (e.g., together with the delivery tracking number (Delivery#)) from the delivery company server <NUM>, and forwards the same (operation <NUM>) to the alarm panel <NUM>.

At <FIG>'s operation <NUM>, the alarm panel <NUM> receives the access request (e.g., together with the delivery tracking number (Delivery#)) from the alarm panel company server, and at operation <NUM>, the alarm panel <NUM> implements the access plan. After the access plan is implemented (described ahead), operations of the alarm panel <NUM> (with respect to this subject delivery) end (operation <NUM>).

As an example, it is assumed that the <FIG> flow <NUM>, is a preset access plan which the alarm panel <NUM> set up using data items (e.g., MaxLengthAcc; EstDelivDate; EstDelivWindow) for the subject delivery. After start <NUM>, a countdown (operation <NUM>) starting from the maximum time length of access (MaxLengthAcc) is started. <FIG>'s row <NUM> (corresponding to <FIG>'s row <NUM>) pertaining to Delivery# <NUM> will be assumed as the delivery data for the subject delivery. Accordingly, given that <FIG>'s row <NUM> has a stored data value of "<NUM>" minutes within the MaxLengthAcc column <NUM>, the countdown will start with seven (<NUM>) minutes and begin counting down towards zero (<NUM>).

In operation <NUM>, the alarm panel <NUM> compares a current date (e.g., retrieved from a reliable date/time source on the Internet, or from an alarm panel internal calendar/clock) with the estimated delivery date (EstDelivDate) of the subject delivery to see if the dates are equal (i.e., match). Given that <FIG>'s row <NUM> has a stored data date value of "<NUM>" (in YYYYMIVIDD format) within the EstDelivDate column <NUM>, the current date will be compared against <NUM>. In the event that the current date was <NUM> (i.e., one day early), then answering the operation <NUM> query of "Is Current Date = EstDelivDate?", would result in the "Before Date" flow branch being followed. At operation <NUM>, an error message such as "Early Access Not Allowed" could be fed back to the delivery company server <NUM> and/or delivery person device DPD to inform that the temporary access is not yet permitted and the operation ends at <NUM>. The delivery person DP can attempt access again at a later more appropriate date.

As another example, in the event that the current date was <NUM> (i.e., one day late), then answering the operation <NUM> query of "Is Current Date = EstDelivDate?", would result in the "After Date" flow branch being followed. At operation <NUM>, a database <NUM>'s DelivStatus data (row <NUM>, column <NUM>) would be changed to "Expired", and an error message such as "Delivery Window Expired" (operation <NUM>) could be fed back to the delivery company server <NUM> and/or delivery person device DPD to inform that the temporary access is no longer permitted. Flow then ends at operation <NUM>. The delivery company server <NUM> can then submit revised delivery data to attempt to gain a new estimated delivery date, and the delivery person DP can attempt access again on that new date.

In another example, in the event that the current date was <NUM> (i.e., a correctly matching date), then answering the operation <NUM> query of "Is Current Date = EstDelivDate?", would result in the "Yes" flow branch being followed.

In operation <NUM>, the alarm panel <NUM> compares a current time (e.g., retrieved from a reliable date/time source on the Internet, or from an alarm panel internal calendar/clock) with the estimated time-of-day delivery window (EstDelivWindow) of the subject delivery. Given that <FIG>'s row <NUM> has a stored data window value of "<NUM>-<NUM>" (in starting HEIMM to ending HEIMM format) within the EstDelivWindow column <NUM>, the current HEIMM time will be compared against <NUM>-<NUM> to see whether the current time is within that range. In the event that the current time was <NUM> (i.e., one hour early), then answering the operation <NUM> query of "Is Current Time Within EstDelivWindow?", would result in the "Before Window" flow branch being followed. At operation <NUM>, an error message such as "Early Access Not Allowed" could be fed back to the delivery company server <NUM> and/or delivery person device DPD to inform that the temporary access is not yet permitted. Flow then ends at operation <NUM>. The delivery person DP can attempt access again at a later more appropriate time.

As another example, in the event that the current time was <NUM> (i.e., three hours late), then answering the operation <NUM> query of "Is Current Time Within EstDelivWindow?", would result in the "After Window" flow branch being followed. At operation <NUM>, a database <NUM>'s DelivStatus data (row <NUM>, column <NUM>) would be changed to "Expired", and an error message such as "Delivery Window Expired" (operation <NUM>) could be fed back to the delivery company server <NUM> and/or delivery person device DPD to inform that the temporary access is no longer permitted. Flow then ends at operation <NUM>. The delivery company server <NUM> can then submit revised delivery data to attempt to effect a new estimated delivery estimated time-of-day delivery window (EstDelivWindow), and the delivery person DP can attempt access again within that new window.

In another example, in the event that the current time was <NUM> (i.e., a time occurring within the <NUM>-<NUM> window), then answering the operation <NUM> query of "Is Current Time Within EstDelivWindow?", would result in the "Yes" flow branch being followed.

At operation <NUM>, the alarm panel <NUM> could control the video camera VC (e.g., via the connection <NUM>) to record the scene of the premises' internal entry area, i.e., at least <FIG>'s entry ZoneE. Depending on video camera VC positioning, angling, ranging, etc., the recorded scene may also include <FIG>'s secondary ZoneS, and perhaps a portion of the remainder ZoneR. While video camera VC capabilities/recording may be optional within the alarm system, resultant recordings may prove useful in situations where there is a dispute with the delivery company and/or delivery person DP concerning damage, theft, non-delivery, trespassing, etc. Regarding usage of the recording, a video camera VC real-time feed or a recording may be provided (e.g., via streaming or emailing) to the resident subscriber, so that the subscriber can review the delivery person's actions and gain peace of mind that the delivery has arrived and was conducted properly (e.g., with respect for the subscriber's property and privacy).

Next, at operation <NUM>, the alarm panel <NUM> may control the alarm system <NUM> to temporarily disable the alarm system's ability to recognize an alarm event, i.e., with respect to activities occurring with respect to a predefined ZoneE sub-area of the premises during the temporary access into the predefined sub-area. As one example, the alarm system may control the alarm system to start ignoring any signals coming from any alarm point(s) (e.g., sensors such as a door trigger switch, motion detector, etc.) within the predetermined access area (i.e., ZoneE) within the premises. Such effectively allows the delivery person DP to enter the entry ZoneE without resulting in an alarm event, while a remainder of the alarm system remains armed. Accordingly, signals coming from the <FIG> alarm points 14A, 14B within the entry ZoneE would be ignored. Ignoring may be accomplished by a simple discarding of signals, masking of the signals, turning off the alarm points such that they do not generate signals, etc. Such ignoring examples are non-limiting and non-exhaustive.

As a further example, the alarm panel may similarly control one or more additional zones. For example, <FIG> illustrates a secondary ZoneS. Such secondary ZoneS may be a mud room or coat room, for example, and the resident may wish to have the delivery item(s) left in the mud room or coat room rather than in the entry ZoneE. The alarm panel <NUM> would be configured to control the alarm system <NUM> to also start ignoring any signals coming from any alarm point(s) (e.g., sensors such as a door trigger switch, motion detector, etc.) in the secondary ZoneS. Such effectively allows the delivery person DP to enter the secondary ZoneS in addition to the entry ZoneE, without resulting in an alarm event. Accordingly, with the <FIG> example, the alarm panel <NUM> would control the alarm <NUM> to also start ignoring the signals coming from the alarm point 14C (as well as the points 14A, 14B). Ignoring may be accomplished by a simple discarding of signals, masking of the signals, turning off the alarm points such that they do not generate signals, etc. Such ignoring examples are non-limiting and non-exhaustive.

While the point(s) ignoring effectively allows the delivery person DP to enter the entry ZoneE and/or secondary ZoneS, without resulting in an alarm event, a remainder of the points <NUM> in the remainder ZoneR of the premises P are not ignored by the alarm system <NUM>. Accordingly, if the delivery person DP travels (i.e., trespasses) beyond the entry ZoneE and/or secondary ZoneS, the alarm system will detect signals from one or more of the remainder points <NUM>, and an alarm event will be generated and reported (e.g., to the premises' resident, to the police, to the alarm panel company server <NUM>, etc.).

Next, at operation <NUM>, the alarm panel will control the door lock DL (e.g., via the connection <NUM>) to unlock, to allow the delivery person DP to enter the premises. A delivery person DP may become aware of the unlock via any number of ways, e.g., by hearing the door lock unlock, by an indicator display or (e.g., green) light on the lock, by a "opened" message fed back from the alarm panel <NUM> and displayed on the delivery person device DPD, etc. The delivery person DP then gains access to an inside of the premises P, theoretically just long enough and far enough into the premises to deposit the delivery item inside the premises. The delivery person DP then theoretically exits the premises closing and locking the door behind him/her.

There may be some delivery instances where it is necessary for a delivery person DP to exit and gain entry to the premises P several times. As one example, assume that the subject delivery is to an apartment within an apartment building, and assume that there are too many delivery items (e.g., packages) for the delivery person DP to transport from the delivery vehicle (e.g., truck) to the apartment in one trip. In such case, the delivery person DP may deposit a first load of items into the apartment, then exit and lock the door to travel back down to the truck for a second load. Upon returning to the apartment door with the second load, the delivery person DP again needs access to the apartment to deposit the second load of items.

The <FIG> flow accommodates such situation. More particularly, as long as the conditions are met that the delivery person DP has not provided an indication (e.g., via the delivery person device DPD) that the subject delivery is complete (see No branch of operation <NUM>) and the countdown from the maximum time length of access (MaxLengthAcc) has not reached zero (<NUM>) (see No branch of operation <NUM>), the <FIG> flow will continue looping. To facilitate reentry, the loop includes an operation <NUM> periodically asking whether there has been another access request from the delivery person device DPD. That is, if the answer to the block <NUM> query "Recv Reg Access For Subject Delivery?" is No, and if the above-mentioned conditions still remain met, the flow continues looping while the countdown continues. If the answer to the block <NUM> query "Recv Reg Access For Subject Delivery?" becomes Yes (e.g., the delivery person DP returns with the second load and issues a new access request from his delivery person device DPD at the apartment door), then flow along the Yes branch leads back to operation <NUM> which again unlocks the door.

At some point, the delivery person DP should finish the subject delivery. The delivery person DP would then theoretically lock and close the door manually upon exiting the premise, and would use his/her input device (e.g., hard button, soft button, touch screen, keyboard, etc.) to input a "subject delivery complete" indication (<FIG>'s operation <NUM>). At operation <NUM>, the delivery person device DPD sends the indication to the delivery company server <NUM>. At operation <NUM>, operations of the delivery person device DPD (with respect to this subject delivery) end. Sending from the delivery person device DPD to the delivery company server <NUM> again may be accomplished via the delivery company cloud <NUM> and connections <NUM>, <NUM>.

At <FIG>'s operation <NUM>, the delivery company server <NUM> receives and stores (e.g., caches) the "subject delivery complete" (e.g., together with the delivery tracking number (Delivery#)) from the delivery person device DPD, and forwards the same (<FIG> operation <NUM>) to the alarm panel company server <NUM>. At operation <NUM>, an optional operation of informing a designated recipient (e.g., a homeowner who ordered the delivery item) of the completed subject delivery, may be performed by the delivery company server <NUM>. At operation <NUM>, operations of the delivery person device DPD (with respect to this subject delivery) end.

Continuing, at <FIG>'s operation <NUM>, the alarm panel company server <NUM> receives the subject delivery complete indication (e.g., together with the delivery tracking number (Delivery#)) from the delivery company server <NUM>, and forwards the same (operation <NUM>) to the alarm panel <NUM>. At operation <NUM>, operations of the alarm panel company server <NUM> (with respect to this subject delivery) end.

Upon receipt of the subject delivery complete indication at the alarm panel <NUM> (e.g., together with the delivery tracking number (Delivery#)), the <FIG> operation <NUM> "Recv Indication Subject Delivery Complete?" query would result in the Yes branch being followed. At operation <NUM>, the alarm panel will control the door lock DL (e.g., via the connection <NUM>) to lock, irrespective of any prior manual locking by the delivery person DP. Redundant locking advantageously guarantees that the premises gets locked quickly after completion of the subject delivery, even if the delivery person DP forgets to perform manual locking.

In the event that the delivery person DP never sends the "subject delivery complete" indication and then the countdown from the maximum time length of access (MaxLengthAcc) reaches zero (<NUM>), the <FIG> operation <NUM> "MaxLengthAcc Countdown = <NUM>?" query would result in the Yes branch being followed. Again, at operation <NUM>, the alarm panel will control the door lock DL (e.g., via the connection <NUM>) to lock, irrespective of the "subject delivery complete" indication never having been received. In the event that the delivery person DP simply forgot to send the indication, no harm is created in that the premises gets locked anyways after completion of the subject delivery. In the event that the delivery person DP purposefully did not send the indication with the intent to remain as an unauthorized trespasser within the premises for mischievous purposes, the alarm system will soon address the same.

More particularly, at operation <NUM>, the alarm panel <NUM> may control the alarm system <NUM> to now reenable the alarm system's ability to recognize an alarm event, i.e., with respect to activities occurring in the predefined ZoneE sub-area. As one example, the alarm system may control the alarm system to stop ignoring any signals coming from any alarm point(s) (e.g., sensors such as a door trigger switch, motion detector, etc.) within the entry ZoneE and/or the secondary ZoneS. Such effectively re-alarms entry ZoneE and/or the secondary ZoneS. Stopping of ignoring may be accomplished by no longer discarding signals, masking signals, turning alarm points back on, etc. In the event that the delivery person DP remains within the premise, the alarm system will generate and output an alarm event as soon as the delivery person DP triggers one of the alarm points such as a motion detector.

In operation <NUM>, the database <NUM>'s DelivStatus data (row <NUM>, column <NUM>) would be changed to "Complete".

At operation <NUM>, the alarm panel <NUM> could control the video camera VC (e.g., via the connection <NUM>) to stop recording the scene of the premises' internal entry area, i.e., at least <FIG>'s entry ZoneE. Such stoppage may be configured to occur about the same time as the door locking. As another example, the stoppage may be configured to occur at a predetermined delay after the door locking. As another example, stoppage may be hinged to some other type of occurrence. For example, stoppage may be configured to occur after a predetermined amount of time (e.g., <NUM> minutes) has passed without the reactivated alarm points being triggered. Such delayed stoppage may be advantageous in capturing the scene of a trespassing delivery person DP if he/she triggers an alarm event. Stoppage of video camera VC recording may, in turn, provoke sending of a copy (e.g., via emailing) to the resident subscriber, so that the subscriber can review the recording.

At operation <NUM>, operations of the alarm panel <NUM> (with respect to this subject delivery) end and/or operations flow back to the <FIG> operation <NUM> which likewise ends operations of the alarm panel <NUM> (with respect to this subject delivery).

The temporary access flow may further contain operations for informing a resident of an impending temporary access, and offering the resident the ability to suddenly block the delivery person's temporary access. For example, assume that the resident arrives back at the residence in time where he/she could actually answer the door manually and physically accept the delivery item from the delivery person.

As one example to allow the resident such option, the display panel may be configured to detect the resident's arrival by the resident keying in to the alarm's keypad to disarm the alarm. The display panel may be further configured to display a message and option choices on a display associated with the keypad. For example, display "Vendor access scheduled. Would you like to block access? Y N. " Upon entering a yes response, the temporary access scheduled for that subject delivery would be disabled. Further, when the delivery person DP arrived at the door and entered his/her access request, the display panel may be configured to send a message back to the delivery person device DPD that, "Resident at residence to accept delivery.

In contrast, if the resident had entered a no response, the scheduled temporary access would be conducted as discussed with respect to <FIG>'s flow <NUM>, with the exception that the alarm would initially be in a disarmed state, and would remain in a disarmed state. Unlocking and locking of the door, for example, would still occur as planned, so as not to burden the resident with locking and unlocking the door.

While the above example description describes the alarm panel company server <NUM> serving as an intermediary for, and handling some temporary access operation responsibilities, practice of the invention is not limited therethrough. For example, a main business of the alarm panel company may be in the manufacturing, sale and distribution of alarm panels. Accordingly, the alarm panel company may have little interest in serving as an intermediary for and handling responsibilities for temporary access operations. Instead, the alarm panel company may be happy to delegate such function and responsibilities out to a differing entity which might have monitoring servicing as a main business. As one example, the CMS <NUM> which already provides alarm monitoring servicing, may also be agreeable to provide the temporary access servicing (e.g., to increase its revenue). With the CMS example, various ones of the above-described alarm panel company server <NUM> components and operations would simply be shifted over to the CMS server.

As another example, an alarm integrator company (e.g., alarm. com; SecureNet) which already provides various applications (e.g., cell phone apps) and servicing with respect to alarms, may also be agreeable to provide the temporary access servicing. To describe an integrator company example, further shown within <FIG> are an integrator company server <NUM> connected (via a connection <NUM>) to an integrator company cloud <NUM>, which in turn is connected (via a connection <NUM>) to the communicator <NUM> connected (via the connection <NUM>) to the alarm panel <NUM>. Thus, the combination of the communicator <NUM> together with the connections <NUM>, <NUM>, <NUM> and cloud <NUM>, may be utilized to also allow communications between the integrator company server <NUM> and the alarm panel <NUM>. With the integrator company example, any alarm panel company server <NUM> components and operations related to the temporary access implementing, would simply be shifted over to the integrator company server <NUM>, and the temporary access responsibilities would be handled by the server <NUM>. That is, the integrator company server <NUM> would be configured to also offer the subscription service of temporary access handling, in addition to the subscription service of monitoring for alarm applications, etc..

In general, the integrator company server <NUM> may be a server at a location remote from the premises P or monitored site. It is to be appreciated that the integrator company server <NUM> may be a single computing device or may be multiple computing devices. The computing devices may be provided at a single location, or distributed at differing locations. For convenience of discussions within this disclosure, however, the integrator company server <NUM> is referred to as a single device at a single location. The integrator company server <NUM> may belong to, and be maintained by, an alarm integrator company (e.g., alarm. com; SecureNet).

Further shown in <FIG> is the integrator company cloud <NUM> also being connected (via the connection <NUM>) to the delivery company cloud <NUM>. Thus, the integrator company server <NUM> and the delivery company server <NUM> may communicate with each over via the combination of the connections <NUM>, <NUM>, <NUM> and clouds <NUM>, <NUM>, to allow, for example, communication and cooperation between the integrator company server <NUM> and the delivery company server <NUM>, to accomplish a temporary access to the premises P. The integrator company server <NUM> may be further connected to the CMS <NUM> via connection <NUM>.

Example constructions of the alarm panel <NUM>, computing device <NUM>, central monitoring station <NUM>, communicator device <NUM>, alarm panel company server <NUM>, delivery company server <NUM> and delivery person device DPD, will now be described more fully with reference to <FIG>.

Turning now to <FIG>, the alarm panel <NUM> may include a processor <NUM>, a communication component <NUM>, a memory <NUM> and a temporary access module <NUM>. The processor <NUM> can be any microprocessor configured to execute a set of instructions, which when executed, cause the alarm panel <NUM> to perform a set of actions defined by the instructions. The memory <NUM> may be any type of computer-readable medium, including non-transient computer-readable medium, such as, for example, EPROM, EEPROM, ROM, FLASH, magnetic storage media, or the like. The communication component <NUM> may be any device and/or module configured to establish connection to and communication with the points <NUM>, central monitoring station <NUM>, the computing device <NUM>, the communicator <NUM>, alarm panel company server <NUM>, integrator company server <NUM>, door lock DL and video camera VC.

In some examples, the communication component <NUM> may be a network interface component (e.g., an Ethernet port, a WIFI radio, a Cellular data radio, or the like). In some examples, the connection component <NUM> may be a packet switched network component (e.g., a telephone modem, a DSL modem, or the like). Such are non-limiting, non-exhaustive examples. Further, the communication component <NUM> may have plural ports and differing ones of the plural ports may be differing types of ports. For example, there may be two ports, with a first port being an Ethernet port, and a second port being a cellular port. Having plural differing types of ports enables the communication component to facilitate communications with plural apparatus having differing communication capability types, and makes the communications component more versatile.

The memory <NUM> of the alarm panel <NUM> may store a configuration file <NUM> which may be used by the alarm panel <NUM> during operation. In general, the configuration file <NUM> indicates the points <NUM> that are connected to the alarm panel, their type, their status (e.g., active, inactive, or the like), their function, alarm conditions, actions to take if alarm conditions are detected, etc. The configuration file <NUM> is encoded into a format readable by the alarm panel <NUM>, and is therefore not necessarily human-readable. The format may differ depending upon the type of alarm panel, the manufacturer of the alarm panel, the model of the alarm panel, etc. The memory <NUM> may also store a zone or points list <NUM>. The zone or points list <NUM> may include a listing of the points <NUM> installed in the alarm system <NUM>, and include data related to each point <NUM>. In some examples, the zone or points list <NUM> may include a model identification corresponding to the points <NUM> represented in the points list <NUM>.

During operation of the alarm system <NUM>, the alarm panel <NUM> records various quantitative measurements and stores them in the memory <NUM> as operational measurements <NUM>. As an example, the operational measurements <NUM> may include measurements of the wireless connectivity level of one or more of the points <NUM>. As another example, the operational alert may include a measurement of the cellular connectivity level of the alarm panel <NUM>. The above example measurements are provided for clarity of presentation, but are not intended to be limiting or exhaustive.

The alarm panel <NUM> may communicate the operational measurements <NUM> (e.g., in real time, periodically, in groups, or the like) to the central monitoring station <NUM> for purposes of keeping the central monitoring station informed regarding a status of, and instances occurring on, the alarm system <NUM>. As a brief non-limiting, non-exhaustive example, the system <NUM> may be configured to monitor pressure in, for example, a tire, a vessel, a tank, a storage container, or the like. During operation, the panel <NUM> may record various quantitate measurements of the pressure inside the monitored vessel. Such measurements may be periodically transmitted to the central monitoring station <NUM>. The central monitoring station <NUM> may use the operational measurements to "predict" future pressure conditions. For example, if the pressure is continually declining, the central station <NUM> may determine that a leak exists even if the pressure has not fallen below a critical level, and institute some type of alarm procedure.

Next, a database module <NUM> stores, for example, a database (discussed elsewhere in this disclosure) having data related to temporary access requests and operations. A multi-zone access module <NUM> stores, for example, data defining plural temporary access zones and any temporary access routines related thereto (e.g., turning off select points, or ignoring signals from select points). Door lock/unlock module <NUM> stores, for example, data and routines related to communicating with and controlling a door and/or door lock used in connection with temporary access operations. Finally, alarm panel company interface module <NUM> and integrator company interface module <NUM> store, for example, data, routines, etc., used in connection with interfacing with the alarm panel company server <NUM> and/or integrator company server <NUM> in connection with temporary access requests and operations.

In finishing up <FIG>, temporary access module <NUM> may contain, for example, set of instructions, which when executed, cause the alarm panel <NUM> to perform a set of temporary access actions defined by the instructions. The temporary access module <NUM> may access various data and routines stored within the various aforementioned memory <NUM> items, for helping perform temporary access actions.

Turning now to <FIG>, the computing device <NUM> may include a processor <NUM>, a communication (e.g., connection) component <NUM>, and a memory <NUM>. The processor <NUM> can be any microprocessor configured to execute a set of instructions, which when executed, cause the computing device <NUM> to perform a set of actions defined by the instructions. The memory <NUM> may be any type of computer-readable medium, including non-transient computer-readable medium, such as, for example, EPROM, EEPROM, ROM, FLASH, magnetic storage media, or the like.

The communication component <NUM> may be any device and/or module configured to establish communication with the alarm panel <NUM> and/or the central monitoring station <NUM>. In general, the communication component <NUM> may be configured to establish a wireless or a wired communication link with the alarm panel <NUM> for purposes of configuring the alarm panel, updating the configuration of the alarm panel, or performing maintenance on the alarm panel. Additionally, the communication component <NUM> may be configured to establish a wireless or a wired communication link with the central monitoring station <NUM> for purposes of transmitting data (e.g., points, status updates, or the like) from the computing device <NUM> to the central monitoring station <NUM>.

In some examples, the communication component <NUM> may be a network interface component (e.g., an Ethernet port, a WIFI radio, a Cellular radio, or the like). Further, the communication component <NUM> may have plural ports and differing ones of the plural ports may be differing types of ports. For example, there may be two ports, with a first port being an Ethernet port, and a second port being a cellular port. Having plural differing types of ports enables the communication component to facilitate communications with plural apparatus having differing communication capability types, and makes the communication component more versatile.

The memory <NUM> of the computing device <NUM> may store zone or points list <NUM>, configuration file <NUM> and status updates <NUM>. The zone or points list <NUM> may be a copy of the zone or points list stored in the alarm panel <NUM>. The configuration file <NUM> may include various characteristics of the points <NUM> represented in the points list <NUM>. In general, the status updates may include any quantitative data regarding the measurements from a device in the system, as well as the detailed information (e.g., the firmware, software, hardware, or the like) about the device. Additionally, the status updates <NUM> may include status updates corresponding to the points <NUM> or updated coding (e.g., firmware, software) for controlling an operation of the alarm system. For example, the status updates <NUM> may include measurements of the battery level of one or more points <NUM>.

The zone or points list <NUM> and the status updates <NUM> may be communicated to the central monitoring station <NUM> during an initial installation, configuration, or maintenance operation of the alarm system <NUM> for purposes of the central monitoring station <NUM> determining maintenance needs, validating installation and/or updating of the alarm system <NUM>.

Turning next to <FIG>, the central monitoring station <NUM> may include a processor <NUM>, a communication component <NUM>, a memory <NUM>, a maintenance needs determination module <NUM>, and an installation validation module <NUM>. The processor <NUM> can be any microprocessor configured to execute a set of instructions, which when executed, cause the central monitoring station <NUM> to perform a set of actions defined by the instructions. Furthermore, the memory <NUM> may be any type of computer-readable medium, including non-transient computer-readable medium, such as, for example, EPROM, EEPROM, ROM, FLASH, magnetic storage media, or the like.

The communication component <NUM> enables the central monitoring station <NUM> to connect to the alarm panel <NUM>, communicator <NUM>, computing device <NUM>, alarm panel company server <NUM> and/or integrator company server <NUM>. As an example, the communication component <NUM> may enable the central monitoring station <NUM> to connect to the alarm panel company server <NUM> for purposes of transmitting data (e.g., zone or points list <NUM>, status updates, alarm events or the like) from the central monitoring station <NUM> to the alarm panel company server <NUM>, and for receiving requests from the alarm panel company server <NUM>.

In some examples, the communication component may be an Ethernet port, or the like, thus enabling the central monitoring station <NUM> to be accessible via the Internet. In other non-exhaustive, non-limiting examples, the communication component may be universal serial bus (USB), wireless and/or cellular communication ports. Further, the communication component may have plural ports and differing ones of the plural ports may be differing types of ports. For example, there may be two ports, with a first port being an Ethernet port, and a second port being a cellular port. Having plural differing types of ports enables the communication component to facilitate communications with plural apparatus having differing communication capability types, and makes the communication component more versatile.

The memory <NUM> of the central monitoring station <NUM> may store the zone or points list <NUM>, the operational measurements <NUM>, status updates <NUM>, maintenance history <NUM>, approved pints list <NUM> and maintenance/installation rules <NUM>. As described above, the zone or points list <NUM>, the operational measurements <NUM> and status updates <NUM> may be received from the alarm panel <NUM> and/or the computing device <NUM> during operation of the alarm system <NUM> and/or during installation, configuration, maintenance and/or updating of the alarm system <NUM>.

The maintenance history <NUM> may include maintenance operations performed thus far on the alarm system <NUM>. The approved points list <NUM> may include a listing of commercially-available points (e.g., type, manufacturer, model number, or the like) that are approved for installation in the alarm system <NUM>. With some examples, a monitoring company responsible for maintenance of the alarm system <NUM> may provide the approved points list to ensure that the alarm system <NUM> is installed according to desired standards. The maintenance and installation rules <NUM> may include a variety of rules related to making determinations about maintenance needs and installation of the alarm system <NUM>.

In continuing the <FIG> discussions, the maintenance needs operation module <NUM> may determine a maintenance need of the alarm system based at least in part on the plurality of operational measurements <NUM>, the maintenance history <NUM>, and the maintenance and installation rules <NUM>. In general, the installation validation module <NUM> may validate the installation of the alarm system <NUM> based at least in part on the zone or points list <NUM>, the status updates <NUM>, the approved points list <NUM>, and the maintenance and installation rules <NUM>.

Referring now to <FIG>, the communicator device <NUM> may include a processor <NUM>, a communication (e.g., connection) component <NUM> and a memory <NUM>. The processor <NUM> can be any microprocessor configured to execute a set of instructions, which when executed, cause the communicator device <NUM> to perform a set of actions defined by the instructions. The memory <NUM> may be any type of computer-readable medium, including non-transient computer-readable medium, such as, for example, EPROM, EEPROM, ROM, FLASH, magnetic storage media, or the like.

The communication component <NUM> may be any device and/or module configured to establish communications with the alarm panel <NUM>, the central monitoring station <NUM>, the alarm panel company server <NUM> and/or the integrator company server <NUM>. In general, the communication component <NUM> may be configured to establish a wireless or a wired communication link with any of such components for purposes of exchanging data, requests, commands, etc..

In some examples, the communication component <NUM> may be a network interface component (e.g., an Ethernet port, a WIFI radio, a Cellular radio, or the like). In other non-exhaustive, non-limiting examples, the communication component may have universal serial bus (USB), wireless and/or cellular communication ports. Further, the communication component may have plural ports and differing ones of the plural ports may be differing types of ports. For example, there may be three ports, with a first port being an USB port, and second and third ports each being a cellular port. Having plural ports of differing types enables the communication component to facilitate communications with plural apparatus having differing communication capability types, and makes the communication component more versatile.

The memory <NUM> of the communicator device <NUM> may store a data/connection monitoring module <NUM>, a protocol converter module <NUM>, and an authorized connection pass-through module <NUM>. The data/connection monitoring module <NUM> is configured to monitor (see <FIG> dashed line <NUM>) for failures in communications between the alarm panel <NUM> and the central monitoring station <NUM> along the connection <NUM>. That is, the module may encompass coding (e.g., firmware, software, etc.) configured to provide a set of instructions, which when executed by the processor (and together with other hardware), cause the communicator device <NUM> to perform a set of data/connection monitoring actions defined by the instructions.

At times, the communicator device <NUM> may pass data between the components to which it connects. Data may be received via a first type of protocol, whereas data output by (e.g., passed through) the communicator device <NUM> may be via a second (differing) type of protocol. For example, data received via monitoring of the connection <NUM> (e. g,, a POTS line) may be analog data, whereas data outputted on the connection <NUM> (e.g., an Ethernet line) to the central monitoring station <NUM> may be digital data, or output on the connection <NUM> (e.g., a cellular channel) may be cellular data. The protocol converter module <NUM> is configured to provide conversion of data from one protocol to another as needed. That is, the module may encompass coding (e.g., firmware, software, etc.) configured to provide a set of instructions, which when executed by the processor (and together with other hardware), cause the communicator device <NUM> to perform a set of protocol conversion actions defined by the instructions.

The authorized connection/pass-through module <NUM> may include data defining which entities are authorized to use the communicator device <NUM> for communications, and which types of data, requests, etc. should be passed therethrough. For example, control if/when to forward data received via monitoring of the connection <NUM> or received via connection <NUM> from the alarm panel <NUM>, onward to the central monitoring station <NUM>. For example, control to not forward such data to the central monitoring station <NUM> when the communicator device <NUM> is operating in a passive mode, and control to forward such data to the central monitoring station <NUM> when the communicator device <NUM> is operating in an active mode. That is, the module may encompass coding (e.g., firmware, software, etc.) configured to provide a set of instructions, which when executed by the processor (and together with other hardware), cause the communicator device <NUM> to perform a set of authorization monitoring, data pass-through control, etc. actions defined by the instructions.

Referring now to <FIG>, the alarm panel company server <NUM> includes a processor <NUM>, a communication (e.g., connection) component <NUM>, a memory <NUM>, an integrated partner verification module <NUM> and a temporary access intermediary module <NUM>. The processor <NUM> can be any microprocessor configured to execute a set of instructions, which when executed, cause the alarm panel company server <NUM> to perform a set of actions defined by the instructions. The memory <NUM> may be any type of computer-readable medium, including non-transient computer-readable medium, such as, for example, EPROM, EEPROM, ROM, FLASH, magnetic storage media, or the like.

The communication component <NUM> may be any device and/or module configured to establish communications with the communicator <NUM>, the central monitoring station <NUM>, the delivery company server <NUM> and/or the integrator company <NUM>. In general, the communication component <NUM> may be configured to establish a wireless or a wired communication link with any of such components for purposes of exchanging data, requests, commands, etc..

In some examples, the communication component <NUM> may be a network interface component (e.g., an Ethernet port, a WIFI radio, a Cellular radio, or the like). In other non-exhaustive, non-limiting examples, the communication component may have universal serial bus (USB), wireless and/or cellular communication ports. Further, the communication component may have plural ports and differing ones of the plural ports may be differing types of ports. For example, there may be two ports, with a first port being an Ethernet port, and a second port being a cellular port. Having plural ports of differing types enables the communication component to facilitate communications with plural apparatus having differing communication capability types, and makes the communication component more versatile.

The memory <NUM> of the alarm panel company server <NUM> may store an integrated partner/delivery database module <NUM>, a historical access archive module <NUM>, an alarm panel interface module <NUM>, a communicator interface module <NUM>, a delivery company interface module <NUM> and an integrator company interface module <NUM>.

The integrated partner/delivery database module <NUM> stores, for example, information detailing integrated partners (e.g., integrator companies; delivery companies; etc.) having a business, contractual or other relationship with the alarm company for the temporary access services. Further, the module <NUM> stores the subscriber and/or delivery data database (discussed elsewhere in this disclosure). The historical access archive module <NUM> may store a historical record of each delivery and/or temporary access communication handled by the alarm panel company server <NUM>.

The alarm panel interface module <NUM>, communicator interface module <NUM>, delivery company interface module <NUM> and integrator company interface module <NUM> may store, for example, data, routines, etc., used in connection with interfacing with the alarm panel <NUM>, communicator <NUM>, delivery company server <NUM> and/or integrator company server <NUM> in connection with temporary access requests and operations.

In continuing <FIG> discussions, the integrated partner verification module <NUM> may contain, for example, set of instructions, which when executed, cause the alarm panel company server <NUM> to perform a set of integrated partner verification actions defined by the instructions. For example, verifying that a delivery company communicating with the alarm panel company server <NUM> is a subscriber to its temporary access services. The integrated partner verification module <NUM> may access various data and routines stored within the various aforementioned memory <NUM> items, for helping perform the integrated partner verification actions.

Likewise, the temporary access intermediary module <NUM> may contain, for example, set of instructions, which when executed, cause the alarm panel company server <NUM> to perform a set of temporary access intermediary actions defined by the instructions. For example, allowing the alarm panel company server <NUM> to act as an intermediary for handling communications between the delivery company server <NUM> and the alarm panel <NUM>. The temporary access intermediary module <NUM> may access various data and routines stored within the various aforementioned memory <NUM> items, for helping perform the temporary access intermediary actions.

The foregoing illustrative examples are given for purposes of completeness and clarity, but are not intended to be limiting. It is to be appreciated, that a variety of different example implementations of the above described systems and methods may exist. These various examples may depend upon the particular alarm system, the monitoring service, the operator, the alarm system, or other conditions and standards. As such, other implementations and examples not disclosed herein are possible without departing from the sprit and scope of the claimed subject matter.

The various embodiments or components described above, for example, the alarm panel, the central monitoring station, the computing device, the communicator, the alarm panel company server, the delivery company server, the integrator company server, and the components or processors therein, may be implemented as part of one or more computer systems. Such a computer system may include a computer, an input device, a display unit and an interface, for example, for accessing the Internet. The computer may include a microprocessor. The microprocessor may be connected to a communication bus. The computer may also include memories. The memories may include Random Access Memory (RAM) and Read Only Memory (ROM). The computer system further may include a storage device, which may be a hard disk drive or a removable storage drive such as a floppy disk drive, optical disk drive, and the like. The storage device may also be other similar means for loading computer programs or other instructions into the computer system. As used herein, the term "software" includes any computer program stored in memory for execution by a computer, such memory including RAM memory, ROM memory, EPROM memory, EEPROM memory, and non-volatile RAM (NVRAM) memory. The above memory types are exemplary only, and are thus not limiting as to the types of memory usable for storage of a computer program.

Claim 1:
An alarm system controller, comprising:
an interface (<NUM>) connectable to receive data originating from an entity located outside of a monitored premises (P), the data providing information detailing an impending request for temporary access of the monitored premises; and
an access module configured to use the data from the interface to determine a predefined access plan to allow the temporary access to a predefined sub-area of the premises without triggering an alarm event, and to implement the predefined access plan at a time of receipt of an actual request for the temporary access, wherein the alarm system controller is an alarm panel (<NUM>), wherein the alarm panel (<NUM>) receives and stores delivery data from an alarm panel company server (<NUM>), including at least: delivery company identifier, shipping company, delivery number, estimated delivery date, time-of-day delivery window, number of delivery items, and estimated time length of access for the subject delivery, wherein the alarm panel considers some of the delivery data to determine whether to set its own maximum length of access time for the subject delivery to provide an extra buffer of access time to avoid a situation where an inadvertent alarm event is triggered by the access time running out before the access is complete.