Patent Description:
Existing elevator systems allow passengers unlimited access to all floors of a building. Other elevator systems may use keycards or other user identifiers to control access to floors of a building. Such systems require interaction with an access control entity, such as building management and/or building security. When a user is granted access to floors of a building, each user typically meets with the access control entity to receive a key card, encode the key card, update privileges in an access system, etc. When the user loses access to floors of the building, the key card must be deactivated and the access system updated, again involving resources of the access control entity.

<CIT> discloses a method of controlling access to a building by receiving a visitor access request and having this granted by a mobile device of a residential group assigned to the visitor. <CIT> discloses a method for controlling access to a building via an invite. <CIT> discloses a system whereby an elevator call is executed based on the calendar invites of a user's mobile device. <CIT> discloses an elevator system whereby a host may grant a visitor access to a building by use of cameras.

According to a first aspect, there is provided a method as claimed in claim <NUM>.

In some embodiments the elevator access privileges associated with the secondary user include floors of the building that the secondary user cannot access via the elevator system.

Some embodiments include associating an identifier with the secondary user.

Some embodiments include receiving a request for elevator service from the secondary user; providing the floors of the building that the secondary user can access via the elevator system to a mobile device associated with the secondary user.

Some embodiments include receiving a selection of a destination floor from the mobile device associated with the secondary user; initiating elevator service to the destination floor for the secondary user.

Some embodiments include receiving a selection of a starting floor and a destination floor from the mobile device associated with the secondary user; initiating elevator service from the starting floor to the destination floor for the secondary user.

Some embodiments include associating monitored elevator services with the secondary user.

Some embodiments include receiving a request for elevator service from the secondary user; assigning an elevator car to the secondary user; enabling a camera within the elevator car assigned to the secondary user.

In some embodiments the assigning the elevator car to the secondary user comprises disabling further elevator calls for the elevator car.

In some embodiments the assigning the elevator car to the secondary user comprises confirming that the elevator car is empty.

Some embodiments include enabling further elevator calls for the elevator car upon the secondary user exiting the elevator car.

Some embodiments include providing video from the camera to a first device.

In some embodiments the first device is associated with the primary user.

In some embodiments the account includes an address of the first device.

Some embodiments include terminating providing the video from the camera to the first device upon the secondary user exiting the elevator car.

In some embodiments associating the monitored elevator services with the secondary user comprises accessing the account and verifying that a monitored elevator services field associated with the secondary user is enabled.

Some embodiments include deleting the secondary user from the account.

According to a further aspect, there is provided an elevator system as claimed in claim <NUM>.

According to third aspect, there is provided a computer program product as claimed in claim <NUM>.

Technical effects of embodiments of the present disclosure include the ability to assign elevator access privileges to users and to provide monitored elevator service to users.

The counterweight <NUM> is configured to balance a load of the elevator car <NUM> and is configured to facilitate movement of the elevator car <NUM> concurrently and in an opposite direction with respect to the counterweight <NUM> within an elevator hoistway <NUM> and along the guide rail <NUM>.

The controller <NUM> is located, as shown, in a controller room <NUM> of the elevator hoistway <NUM> and is configured to control the operation of the elevator system <NUM>, and particularly the elevator car <NUM>. When moving up or down within the elevator hoistway <NUM> along guide rail <NUM>, the elevator car <NUM> may stop at one or more landings <NUM> as controlled by the controller <NUM>.

Although shown and described with a roping system including tension member <NUM>, elevator systems that employ other methods and mechanisms of moving an elevator car within an elevator hoistway may employ embodiments of the present disclosure.

Turning now to <FIG>, an exemplary elevator system <NUM> in accordance with one or more embodiments is shown. The elevator system <NUM> may include one or more mobile devices <NUM>, such as a phone, a laptop, a tablet, smartwatch, etc. One or more of the mobile devices <NUM> may be associated with a particular user <NUM>. The user <NUM> may use his/her mobile device(s) <NUM> to request a service, such as an elevator service at a building <NUM>. The mobile device <NUM> may request service in an affirmative or active manner. For example, the user <NUM> may enter an explicit request for elevator service using an I/O interface of the mobile device <NUM>.

The request for service may be conveyed or transmitted from the mobile device <NUM> over one or more networks. A request for service may be sent from mobile a device <NUM> to an elevator controller <NUM> over a local network. In other example embodiments, the request for service may be transmitted via the Internet <NUM> and/or a cellular network <NUM>. The service request may then be routed through a device <NUM>, such as a gateway or modem at the building <NUM>. The device <NUM> may be configured to monitor for service requests. The device <NUM> may be coupled to an access server <NUM> and/or the networks <NUM>, <NUM> via one or more mediums, such as a phone line, a cable, a fiber optic line, etc..

The service request, once received at the device <NUM> is forwarded to an elevator controller <NUM>. The elevator controller(s) <NUM> may be configured to communicate with the device <NUM> and/or one another to fulfill service requests. In this respect, it should be noted that service requests might not only originate from mobile devices <NUM> but may also originate locally (e.g., within a building <NUM> in which the controllers <NUM> may be located or in which the requested service(s) may be provided). The controllers <NUM> may select a resource (e.g., an elevator system or elevator car) that is suited to fulfill a service request, potentially based on one or more considerations, such as power consumption/efficiency, quality of service (e.g., reduction in waiting time until a user or passenger arrives at a destination floor or landing), etc..

The access server <NUM> may be implemented using known computing equipment (processor, memory, I/O devices, network communications, etc.). The access server <NUM> stores a user profile for users. The user profile contains elevator access privileges such as floor permissions and floor restrictions for each user. A method of configuring a user profile is depicted in <FIG>.

Referring to <FIG>, a process for configuring a user profile begins at <NUM> where a user is designated as a primary user. This may be achieved by the user interacting with the access server <NUM> to create an account, provide identifying data, login identifier, password, etc. A mobile device identifier (e.g., phone number, MIN) may be stored in the account to identify the user by the mobile device <NUM> being used. The access server <NUM> stores the account information and the name of the primary user associated with the account. The primary user has the right to assign elevator access privileges to other users. The primary user may be, for example, a parent who wants to control which floors in the building <NUM> their child may access. In other embodiments, the primary user may be a supervisor of a team (e.g., cleaning crew, maintenance, etc.) who wants to control which floors in the building <NUM> their team may access. The primary user may register with a security system used in the building <NUM>. There may be more than one primary user (e.g., a husband and wife).

Once the primary user is designated, the access server <NUM> stores the account information along with the identity of the primary user. The method flow proceeds to <NUM> where one or more secondary users are designated by the primary user. In other embodiments, secondary users may be designated through a building security system or staff. In the example where the primary user is a parent, the secondary users may be the children of the parent residing in the building <NUM>. The primary user interacts with the access server <NUM> to identify secondary users for the account. One or more identifiers is associated with each secondary user, such as account number, name, relationship to primary user, mobile device identifier (e.g., phone number), etc. The secondary users associated with the account are stored in the access server <NUM>. A primary user, and/or building security system or staff, may also delete a secondary user from the account.

Once the secondary users are designated at <NUM>, flow proceeds to <NUM> where the primary user assigns elevator access privileges to each secondary user. The elevator access privileges may include floors of the building <NUM> and include floor permissions (e.g., floors that the secondary user can access via the elevator system) and floor restrictions (floors the secondary user cannot access via the elevator system). The elevator access privileges for each secondary user are stored on the access server <NUM>, along with the associated secondary user identifiers. Once the primary user has finished identifying each secondary user and assigning elevator access privileges, the process ends at <NUM>.

<FIG> depicts a user interface for managing elevator access privileges in an example embodiment. When the primary user logs into their account on the access server <NUM>, the primary user can view all the secondary users associated with that account, as shown at graphical user interface <NUM> in <FIG>. Upon selection of a secondary user (Reiner S. in this example), the graphical user interface <NUM> is presented. The graphical user interface <NUM> depicts all the possible floors in the building <NUM> with floor indicators <NUM>. In the example shown in <FIG>, no elevator access privileges have been associated with the secondary user. The graphical user interface <NUM> indicates default settings in which the secondary user, Reiner S. in this example, has access to all floors of the building <NUM>. A home floor indicator <NUM> may also be used to indicate a home floor associated with the secondary user. This home floor may be assigned by the primary user. The home floor is stored on the access server <NUM>, along with the associated secondary user identifiers.

Through the graphical user interface <NUM>, the primary user can select floors that the secondary user is permitted to visit (e.g., floor permissions) and floors that the secondary user is prohibited from visiting (e.g., floor restrictions). The primary user may toggle a floor indicator <NUM> on and off to change state from permitted to restricted. In the example of <FIG>, the primary user has selected floors L, <NUM>, <NUM> and <NUM> as floors that the secondary user is permitted to visit. The remaining floors are greyed-out as being corresponding to floors the secondary user is prohibited from visiting. The resultant floor listing is shown in the user interface <NUM>. The primary user may also select the home floor indicator <NUM> and edit the floor associated with the home floor for this secondary user. The graphical user interfaces <NUM>, <NUM> and <NUM> are simply examples of how a primary user may assign elevator access privileges for a secondary user. The floors that the secondary user is permitted to visit (e.g., floor permissions) and the floors that the secondary user is prohibited from visiting (e.g., floor restrictions) may be stored on the access server <NUM>, along with the associated secondary user identifiers. It is understood that a variety of other graphical user interfaces may be used and embodiments are not limited to those shown in <FIG>.

Graphical user interface <NUM> in <FIG> depicts the user interface on the secondary user's mobile device <NUM> when requesting elevator service. The secondary user's mobile device communicates with the access server <NUM> to retrieve the floors that the secondary user is permitted to visit. The graphical user interface <NUM> only lists floors L, <NUM>, <NUM> and <NUM>, as these floors are the floors that the secondary user is permitted to visit. In the example graphical user interface <NUM>, the user can select a starting floor and a destination floor from the list of floors that the secondary user is permitted to visit. Upon selecting a starting floor and a destination floor, the request for elevator service is sent to the elevator controller <NUM> to initiate elevator service. The secondary user may also select the home indicator <NUM> to initiate a request for elevator service to the home floor.

<FIG> depicts an elevator system <NUM> for providing monitored elevator services in an example embodiment. Monitored elevator services allow a first user to view live video of a second user as the second user travels in an elevator car <NUM>. In the example in <FIG>, a second user <NUM> has requested elevator service using a device <NUM>, such as a phone, a laptop, a tablet, smartwatch, destination entry terminal, kiosk, etc. The second user may request monitored elevator service through a user interface on the device <NUM>. Alternately, the second user may be a secondary user having a user profile that designates monitored elevator services. As described above, a primary user may create a user profile for a secondary user. The user profile of the secondary user may include a monitored elevator service option so that when the monitored elevator service option is enabled, elevator service for the second user is monitored.

A monitoring server <NUM> is connected to a network <NUM>. The monitoring server <NUM> may be implemented using known computing equipment (processor, memory, I/O devices, network communications, etc.). The monitoring server <NUM> may be implemented using the same equipment the access server <NUM> or may be a separate component. The network <NUM> may be a local network (e.g., <NUM>. xx) or a wide range network (e.g., cellular) and may be implemented using known wired and/or wireless network protocols. An elevator controller <NUM> is in communication with the network <NUM> and a camera <NUM> installed in the elevator car <NUM>. In other embodiments, the camera <NUM> operates separately from the elevator controller <NUM>. The elevator controller <NUM> may control operation of the elevator car <NUM> including travel up and down, door open/close, etc. The elevator controller <NUM> may be the same as controller <NUM> of <FIG>. The camera <NUM> is mounted in the elevator car <NUM> and is in communication with the monitoring server <NUM> over network <NUM>.

A first device <NUM> is also in communication with the network <NUM>. The first device <NUM> may be a mobile device, such as a phone, a laptop, a tablet, smartwatch, etc. or may be a stationary device, such as a network enabled television, desktop computer, etc. The first device <NUM> may be associated with a first user, for example, a primary user that has created the user profile for the second user <NUM>, a secondary user. In one example, the first user is a parent of the second user, and has configured the user profile of the second user so that the second user is provided with monitored elevator service. In another example, the first user is a caregiver of the second user, and has configured the user profile of the second user so that the second user is provided with monitored elevator service. The system may include multiple first devices <NUM>, each of which can receive video from the interior of the elevator car <NUM>.

<FIG> depicts a process for providing monitored elevator services in an example embodiment. At <NUM>, the second user <NUM> requests elevator service. At <NUM>, the monitoring server <NUM> determines if the elevator service should be monitored elevator service. This may be accomplished by accessing the user profile of the second user and determining if the monitored elevator services option is enabled. Monitored elevator services may also be requested by the second user <NUM>, through the device <NUM> or some other input (e.g., a kiosk for entering elevator calls).

If monitored elevator service is not indicated, then flow proceeds to <NUM> where standard elevator service is provided to the second user. If monitored elevator service is indicated, then flow proceeds to <NUM> where the monitoring server <NUM> sends a command to the elevator controller <NUM> to initiate monitored elevator service for the second user <NUM>. At <NUM>, the elevator controller <NUM> assigns a monitored elevator car <NUM> to the second user <NUM>. The monitored elevator car <NUM> may, optionally, be required to be empty, so no other passengers are assigned to the monitored elevator car <NUM> during travel by the second user <NUM>. The camera <NUM> (or other occupancy detectors) may be used to detect if other passengers are in the monitored elevator car <NUM>. The monitored elevator car <NUM> may also be selected as one having high reliability and/or low noise. One or more sensors (e.g., accelerometers, gyroscope, vibration sensor, microphone, etc.) may be mounted on the elevator cars <NUM> to record noise and/or overall ride quality of the elevator cars <NUM>. The elevator controller <NUM> may also disable any further elevator calls for the monitored elevator car <NUM> so that the second user <NUM> travel alone (or with companions, if applicable).

At <NUM>, the camera <NUM> is activated to provides a live stream video of the interior of the elevator car <NUM> to the monitoring server <NUM>. The elevator controller <NUM> or the monitoring server <NUM> may send a command to the camera <NUM> to begin capturing video. At <NUM>, the monitoring server <NUM> directs the video to the first device <NUM>. The monitoring server <NUM> can access the user profile of the second user <NUM> and/or the user profile of the first user to retrieve an address of the first device <NUM> (e.g., an IP address, MAC address, phone number, email address, etc.). The monitoring server <NUM> can direct the video to multiple first devices <NUM>. The monitoring server <NUM> may also direct the video to security personnel for monitoring of the second user <NUM>.

At <NUM>, it is determined if the second user <NUM> has exited the elevator car <NUM>. This may be performed by the elevator controller <NUM> detecting a door open condition at the destination floor of the second user <NUM>. The elevator controller <NUM> may also use sensor data from the elevator car <NUM> to detect the second user exiting the elevator car <NUM> (e.g., people counter, weight sensor, occupancy sensor, etc.). Alternatively, or in addition, the monitoring server <NUM> may use video analytics to detect when the second user <NUM> has exited the elevator car <NUM>. The elevator controller <NUM> may keep the elevator cars doors open until it is confirmed the second user has exited the elevator car <NUM>.

The monitoring server <NUM> continues providing the video of the interior of the elevator car <NUM> to the first device <NUM> until the second user exits the elevator car as determined at <NUM>. Upon the second user <NUM> exiting the elevator car <NUM>, the process ends at <NUM> and the elevator controller <NUM> terminates the monitored elevator services for the elevator car <NUM>.

<FIG> depicts user profiles for secondary users associated with an account in an example embodiment. A primary user identification field <NUM> includes a primary user identifier associated with the primary user of the elevator services account. The primary user identifier may be a user-generated identifier and/or an identifier of a mobile device associated with the primary user. A secondary user identification field <NUM> includes a secondary user identifier associated with the secondary user of the elevator services account. The secondary user identifier may be a user-generated identifier and/or an identifier of a mobile device associated with the secondary user. A home floor field <NUM> identifies a floor to which a user can automatically travel upon selection of the home floor indicator <NUM> (<FIG>). A floor permissions field <NUM> indicates the floors that the secondary user is permitted to visit. A monitored elevator services field <NUM> indicates whether monitored elevator services are enabled for a secondary user. The monitored elevator services field <NUM> may toggled between enabled and disabled, so that the monitored elevator services can be turned on and off. A video destination field <NUM> indicates an address of the first device <NUM> (e.g., an IP address, MAC address, phone number, email address, etc.) to which video from the interior of the elevator car is directed. The video destination field <NUM> may include multiple addresses.

Embodiments allow a primary user, such as a parent, to establish elevator access privileges, such as floor permissions and floor restrictions, for one or more secondary users. Embodiments also allow a primary user to receive live video from an elevator car when a secondary user is traveling in the elevator system.

As described above, embodiments can be in the form of processor-implemented processes and devices for practicing those processes, such as the elevator controller, the access server and/or the monitoring server. Embodiments can also be in the form of computer program code containing instructions embodied in tangible media, such as network cloud storage, SD cards, flash drives, floppy diskettes, CD ROMs, hard drives, or any other computer-readable storage medium. Embodiments can also be in the form of computer program code transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation. When implemented on a general-purpose microprocessor, the computer program code configures the microprocessor to create specific logic circuits.

Claim 1:
A method comprising:
creating an account with an elevator system (<NUM>);
assigning a primary user (<NUM>) to the account;
assigning a secondary user (<NUM>) to the account;
associating elevator access privileges to the secondary user (<NUM>), the elevator access privileges including floors of a building (<NUM>) that the secondary user can access via the elevator system (<NUM>);
associating a home floor with the secondary user;
receiving a selection of the home floor from a mobile device (<NUM>) associated with the secondary user; and
initiating elevator service to the home floor for the secondary user.