Patent Description:
Existing elevator systems allow a user to submit a mobile elevator call request (e.g., a hall call or a destination call) using a mobile device (e.g., a smartphone, smart watch, tablet, etc.). There is a potential risk for both intentional and unintentional overuse of the system that may flood the elevator system with too many mobile elevator call requests, which would make efficiently operating the elevator system difficult. A system to prevent abusive use of the mobile elevator call requests is greatly desired.

<CIT> discloses a method and device for managing elevators. In particular, D1 discloses that a number of malicious calls from a terminal is compared with a threshold and if the number of malicious calls is greater than or equal to the threshold, the calling function of the terminal is limited so that its calling function can no longer be used within a predetermined period.

<CIT> discloses a service request using a wireless programmable device, wherein the number of times a service request for a user/device has been approved and/or disapproved is checked and if the number of disapprovals or the ratio of disapprovals to approvals exceeds a threshold, future requests for service from the user/device may be denied.

Various embodiments are disclosed in the dependent claims, the description, and the drawings.

Technical effects of embodiments of the present disclosure include the ability to manage mobile elevator call requests through a user interface.

The embodiments and/or examples of the following description, which are not covered by the claims, are provided for illustrative purpose only and are only intended to assist the reader in understanding the invention. Such embodiments and/or examples, which are not covered by the claims, do not form part of the invention.

<FIG> depicts a building elevator system <NUM> in an example embodiment. The building elevator system <NUM> includes an elevator system <NUM> installed at a building <NUM>. In some embodiments, the building <NUM> may be an office building or a collection of office buildings that may or may not be physically located near each other. The building <NUM> may include any number of floors. Persons entering the building <NUM> may enter at a lobby floor, and may go to a destination floor via one or more conveyance devices, such as an elevator system <NUM>.

The elevator system <NUM> may include one or more computing devices, such as a controller <NUM>. The controller <NUM> may be configured to control dispatching operations for one or more elevator cars (e.g., elevator cars <NUM>-<NUM>, <NUM>-<NUM>) associated with the elevator system <NUM>. It is understood that the elevator system <NUM> may utilize more than one controller <NUM>, and that each controller may control a group of elevators cars <NUM>-<NUM> and <NUM>-<NUM>. Although two elevator cars <NUM>-<NUM> and <NUM>-<NUM> are shown in <FIG>, it is understood that any number of elevators cars may be used in the elevator system <NUM>. The elevator cars <NUM>-<NUM> and <NUM>-<NUM> may be located in the same hoistway or in different hoistways so as to allow coordination amongst elevator cars <NUM>-<NUM> and <NUM>-<NUM> in different elevator banks serving different floors. It is understood that other components of the elevator system <NUM> (e.g., drive, counterweight, safeties, etc.) are not depicted for ease of illustration.

The controller <NUM> may include a processor <NUM>, memory <NUM> and communication module <NUM> as shown in <FIG>. The processor <NUM> can be any type or combination of computer processors, such as a microprocessor, microcontroller, digital signal processor, application specific integrated circuit, programmable logic device, and/or field programmable gate array. The memory <NUM> is an example of a non-transitory computer readable storage medium tangibly embodied in the controller <NUM> including executable instructions stored therein, for instance, as firmware. The communication module <NUM> may implement one or more communication protocols as described in further detail herein.

Also shown in <FIG> is a mobile device <NUM>. The mobile device <NUM> may include a device that is typically carried by a person, such as a phone, PDA, smart watch, tablet, laptop, etc. The mobile device <NUM> may include a processor <NUM>, memory <NUM> and communication module <NUM> as shown in <FIG>. The processor <NUM> can be any type or combination of computer processors, such as a microprocessor, microcontroller, digital signal processor, application specific integrated circuit, programmable logic device, and/or field programmable gate array. The memory <NUM> is an example of a non-transitory computer readable storage medium tangibly embodied in the mobile device <NUM> including executable instructions stored therein, for instance, as firmware. The communication module <NUM> may implement one or more communication protocols as described in further detail herein.

The mobile device <NUM> and the controller <NUM> communicate with one another. For example, the mobile device <NUM> and the controller <NUM> may communicate with one another when proximate to one another (e.g., within a threshold distance). The mobile device <NUM> and the controller <NUM> may communicate over a wireless network, such as <NUM>. 11x (WiFi), short-range radio (Bluetooth), etc. In some embodiments, the controller <NUM> may include, or be associated with (e.g., communicatively coupled to) a networked element, such as kiosk, beacon, hall call fixture, lantern, bridge, router, network node, etc. The networked element may communicate with the mobile device <NUM> using one or more communication protocols or standards. For example, the networked element may communicate with the mobile device <NUM> using near field communications (NFC). In other embodiments, the controller <NUM> may establish communication with a mobile device <NUM> that is outside of the building <NUM>. This connection may be established with various technologies including GPS, triangulation, or signal strength detection, by way of non-limiting example. Such technologies that allow early communication will provide users and the systems more time to establish the most efficient passenger flow, and may eliminate the need for a user to stop moving to interact with the system. In example embodiments, the mobile device <NUM> communicates with the controller <NUM> over multiple independent wired and/or wireless networks. Embodiments are intended to cover a wide variety of types of communication between the mobile device <NUM> and controller <NUM>, and embodiments are not limited to the examples provided in this disclosure.

Embodiments generate a user interface on the mobile device <NUM>. <FIG> and <FIG> depict an example user interface <NUM> on mobile device <NUM>. Referring to <FIG>, when the mobile device <NUM> launches an elevator interface application, a mobile elevator call request entry screen may be presented as shown in <FIG>. The mobile elevator call request entry screen allows a user to enter a mobile elevator call request, such as a hall call or a destination call. A user interface <NUM> includes a plurality of floor icons <NUM>, each floor icon <NUM> corresponding to a single floor of the building <NUM>. The user can enter a destination call by selecting a starting floor and ending floor, as shown in <FIG>. As shown in <FIG>, the user has selected floor <NUM> as a starting floor and floor <NUM> as a destination floor. The particular user interface depicted in <FIG> and <FIG> is an example. Any other desired user interface enabling a user to select a start and destination floor pairing, destination floor, preset mobile elevator call request, or any other manner of indicating the desired travel path may be used. The mobile elevator call request is communicated from the mobile device <NUM> to the controller <NUM>. The controller <NUM> may use existing elevator dispatch techniques to determine which elevator car <NUM> (e.g., one of <NUM>-<NUM> or <NUM>-<NUM>) will serve the mobile elevator call request. Once the user has placed an elevator call, the user interface <NUM> may display a graphic cancel icon <NUM>, upon selection of which the mobile elevator call request may be canceled.

Also shown in <FIG> is a management interface <NUM> in operative communication with the controller <NUM>. The management interface may be a website and/or computer application. The management interface <NUM> may be implemented using known input/output devices which may include one or more of a keyboard or keypad, a key switch, a touchscreen or touch panel, a display screen, a microphone, a speaker, a mouse, a button, a computer, a tablet, a smartwatch, a remote control, a joystick, a printer, a telephone or mobile device (e.g., a smartphone), etc. In one embodiment, the management interface <NUM> may be in wired connection to the controller <NUM>. In a second embodiment, the management interface <NUM> may be remote from the controller <NUM> and in operative communication with the controller <NUM> through a network connection (e.g., wired and/or wireless).

<FIG> depicts an example management interface <NUM>, in accordance with an embodiment of the disclosure. As shown in <FIG>, the management interface <NUM> includes elevator call parameters <NUM> that may be adjusted by a user, such as for example a building manager. In one embodiment, the call parameters <NUM> may be adjusted at the factory, in the field by an elevator service technician, or any other authorized user. The building manager (or other authorized user) may input their desired elevator call parameters <NUM> for the building elevator system <NUM>. The elevator call parameters <NUM> are input into the management interface <NUM> and received by the controller <NUM>. The elevator call parameters <NUM> place limits on the number of elevators call requests that may be sent from a mobile device <NUM>. In an embodiment, each mobile device <NUM> must first register with the management interface <NUM> to send a mobile elevator call request. The elevator call parameters <NUM> may comprise building usage limits <NUM> and individual usage limits <NUM>. The building usage limits <NUM> comprise elevator call parameters <NUM> that are general mobile device applicability, meaning that they apply to each mobile device <NUM> equally. For example, under general mobile device applicability each mobile device <NUM> may be limited to three mobile elevator call requests within ten minutes. In one embodiment, the limit and time interval may apply to the whole elevator system <NUM>, rather than phones. For example, the system could limit to a total of <NUM> mobile elevator call requests from all mobile devices in any <NUM> minute period. The individual usage limits <NUM> comprise elevator call parameters <NUM> that are specific mobile device applicability, meaning that they can be applied to a specific user's mobile device. For instance, the CEO of a company may have unlimited mobile elevator call requests from their mobile device, whereas a regular employee may be limited to three mobile elevator call requests within ten minutes. It should be understood that any number of calls and any duration may be used.

As seen in <FIG>, the building usage limits <NUM> may include a selected time of day <NUM> for the elevator call parameters <NUM> to apply. For instance, the building manager may desire to place increased limits on mobile elevator call requests during high elevator use times and then ease the limits during low elevator use times, or vice versa. For example, in one exemplary embodiment, during the morning rush hour, the elevator call parameter <NUM> may be set to only two mobile elevator call requests per ten minutes, whereas in the middle of the night the elevator call parameters <NUM> may be set to unlimited mobile elevator call requests. Under the building usage limits <NUM>, the building manager could input a selected number of mobile elevator call requests <NUM> per a selected period of time <NUM>, which would apply to each mobile device <NUM> registered. For instance, each mobile device <NUM> may be limited to three mobile elevator call requests per ten minutes. Further, the building manager could also input a selected number of active mobile elevator call requests <NUM>, which would limit how many mobile elevator call requests in total the controller <NUM> can be active at any given time. The distinction between active calls and total calls is that total calls reflects the total calls during a predetermined time period whereas active calls refers to the total number of outstanding calls at a particular instant in time. Advantageously, this limit on the total mobile elevator call request will help ensure that the controller <NUM> does not get overloaded and continues to operate efficiently. The controller <NUM> may limit active calls and/or total calls as described above.

As seen in <FIG>, the individual usage limits <NUM> include the opportunity to select an individual user to limit <NUM>. As mentioned above, this allows the building manager through the management interface <NUM> to tailor the elevator call parameters <NUM> to the needs of each individual user. The individual usage limits <NUM> may also include a selected time of day <NUM> for the elevator call parameters <NUM> to apply. For instance, the building manager may desire to place decreased limits on mobile elevator call requests during a specific employee's work schedule and then increase the mobile elevator call request limits when the employee is not scheduled to work. Under the individual usage limits <NUM>, the building manager could input a selected number of mobile elevator call requests <NUM> per a selected period of time <NUM> for each employee. For instance, the select number of mobile elevator call requests <NUM> may be high for an employee who uses the elevator a lot during the day.

As shown in <FIG>, if a mobile elevator calls request conflicts with an elevator call parameter <NUM>, an overuse alarm <NUM> is activated on the mobile device <NUM>. The overuse alarm <NUM> may also be transmitted to the mobile device from the controller <NUM>. The overuse alarm <NUM> may be audible, visual, and/or vibratory. The overuse alarm may include explanatory text <NUM> explaining what caused the overuse alarm <NUM> and directing the user of the mobile device <NUM> to now use the hall buttons to call the elevator. In one example, the explanatory text <NUM> may state, "You have exceeded the current request limit of <NUM> calls per <NUM> minutes. Please Use Hall buttons to call the elevator". Further, the mobile device <NUM> is restricted from sending additional mobile elevator call requests when the elevator call conflicts with the elevator call parameters <NUM>. The mobile device <NUM> is restricted by the controller <NUM>.

Further, the mobile device <NUM> may be restricted from sending additional mobile elevator call requests for a selected timeout period <NUM>, <NUM> (see <FIG>) when the elevator call conflicts with the elevator call parameters <NUM>. The selected timeout period <NUM>, <NUM> may be a period of time where the mobile device <NUM> would not be able to send mobile elevator call requests, such as, for example, one hour. As may be appreciated by one of skill in the art, the selected timeout period <NUM>, <NUM> may be less than or greater than one hour. The selected timeout period <NUM>, <NUM> may be entered into the management interface <NUM>. Additionally, the selected timeout period <NUM> may be building specific and entered under the building usage limits <NUM> or the selected time out period <NUM> may be user specific and entered under the individual usage limits <NUM>, as seen in <FIG>.

Referring now to <FIG>, while referencing components of <FIG>. <FIG> shows a flow chart of method <NUM> of managing mobile elevator call requests from a mobile device <NUM>, in accordance with an embodiment of the disclosure. At block <NUM>, an elevator call parameter <NUM> is received from a management interface <NUM>. At block <NUM>, a mobile elevator call request is received from a mobile device <NUM>. At block <NUM>, the mobile elevator call request is compared to the elevator call parameter <NUM>. At block <NUM>, it is checked whether the mobile elevator call request conflicts with the elevator call parameter <NUM>, which is done by the controller <NUM>. At block <NUM>, <NUM>, if the mobile elevator call request conflicts with the elevator call parameter <NUM> then an overuse alarm <NUM> is activated on the mobile device <NUM>, at block <NUM>. At block <NUM>, the mobile device <NUM> is restricted from sending additional mobile elevator call requests when the elevator call conflicts with the elevator call parameters <NUM>. As mentioned above, the mobile device <NUM> is restricted by the controller <NUM>. Further, the mobile device <NUM> may be restricted from sending additional mobile elevator call requests for a selected timeout period <NUM>, <NUM> (see <FIG>) when the elevator call conflicts with the elevator call parameters <NUM>. At block <NUM>, if the mobile elevator call request does not conflict with the elevator call parameter <NUM> then an elevator car is moved in accordance with the mobile elevator call request at block <NUM>. The method may further include registering the mobile device <NUM> with the management interface <NUM>, which will ensure that the management interface <NUM> could regulate the mobile elevator call requests from each mobile device <NUM>.

As described above, embodiments can be in the form of processor-implemented processes and devices for practicing those processes, such as processor. Embodiments can also be in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes a device for practicing the embodiments.

Claim 1:
A method of managing mobile elevator call requests received from a mobile device (<NUM>), the method comprising:
receiving (<NUM>), by an elevator system controller (<NUM>), an elevator call parameter from a management interface (<NUM>), the elevator call parameter being a selected number of mobile elevator call requests per a selected period of time for the mobile device;
receiving (<NUM>), by the controller (<NUM>), at least one mobile elevator call request from the mobile device (<NUM>);
comparing (<NUM>), by the controller (<NUM>), a number of the at least one mobile elevator call request to the elevator call parameter; and
restricting (<NUM>), by the controller (<NUM>), the mobile device (<NUM>) from sending additional mobile elevator call requests when the at least one mobile elevator call request conflicts with the elevator call parameter, wherein the at least one mobile elevator call request conflicts with the elevator call parameter when the number of the at least one mobile elevator call request exceeds the selected number of mobile elevator call requests.