Patent Description:
In today's environment, elevator systems can recognize the existence of individual users planning to use the elevator in order to respond to demand or requests for service. Control panels, including but not limited to buttons, keypad devices, and touchscreen devices may be used for entering a request for elevator service. For example, an elevator system may utilize a two-button control panel configuration (e.g., up and down buttons), wherein a direction of travel within the elevator system is requested by pressing one of the two buttons. An elevator system may utilize a keypad and/or touchscreen device with destination dispatching, such that a user may specify a floor or landing that the user would like to be taken to as part of the request for service. In either case/configuration, a user/passenger engages in an affirmative action to request elevator service by using devices available at an elevator landing, i.e., where the elevator is called and entered/exited by passengers.

Currently, remote elevator requests are supported by some elevators systems. As such, occasionally unintended elevator call requests are placed by a user device that is remote from the requested elevator system. This can lead to a delay for users waiting for elevator service due to the unintended requests.

<CIT>, falling under Art. <NUM>(<NUM>) EPC, discloses a method of controlling an elevator system that includes receiving a first request for elevator service from a requestor (<NUM>), receiving a second request for elevator service from the requestor while the first request is still pending (<NUM>), and controlling the elevator system to provide elevator service for only one of the first request or the second request (<NUM>, <NUM>). <CIT> shows a method and system according to the preambles of claims <NUM> and <NUM>, respectively.

According to an aspect of the invention, there is provided a method for operating a receiverless device positioning according to claim <NUM>.

Some embodiments include a first request that is a first elevator call request to a first elevator system at the first location and a second request that is a second elevator call request to a second elevator system at the second location.

Some embodiments include a registered data associated with the first request includes location information of the first location and the second location, and time information for the first request and the second request.

Some embodiments include responsive to allowing the second request, updating the location information of the registered data from the first location to the second location.

Some embodiments include determining the location information without the assistance of GPS data, Bluetooth beacon, or positioning data of a user device.

Some embodiments include a first request that is transmitted from a location remote from the first location.

Some embodiments include comparing the first location and the second location which includes comparing a distance between the first location and the second location to a threshold distance.

Some embodiments include using a threshold distance that is a dynamic radius based on estimated travel time between the first location and the second location.

Some embodiments include comparing the time between the first request and the second request to a threshold time period.

Some embodiments include denying subsequent requests if the subsequent requests are transmitted within an inactivity period.

According to another aspect of the invention, there is provided a system configured to perform receiverless position according to claim <NUM>.

Some embodiments include a first elevator system at a first location; and a second elevator system at a second location, wherein the first elevator system is different than the second elevator system.

Some embodiments include a memory that is configured to store the registered data associated with the first request comprising location information of the first location and the second location, and time information for the first request and the second request.

Some embodiments include a processor that is configured to update the location information of the registered data from the first location to the second location responsive to allowing the second request.

Some embodiments include determining location information without the assistance of GPS data, Bluetooth beacon, or other positioning data from of the user device.

Some embodiments include comparing the first location and the second location comprises comparing a distance between the first location and the second location to a threshold distance.

Some embodiments include a memory that is configured to store the threshold distance, wherein the threshold distance is a dynamic radius based on estimated travel time between the first location and the second location.

Some embodiments include a processor that is configured to compare the time between the first request and the second request to a threshold time period.

Some embodiments include a processor that is configured to deny subsequent requests if the subsequent requests are transmitted within an inactivity period.

The technical effects of embodiments of the present disclosure include enabling remote elevator requests that are not based on the GPS data. In addition, technical effects and benefits include improved nuisance elevator request filtering. Also, the receiverless device positioning can be applied to other systems such as enabling/disabling digital payments at physical stores to prevent fraudulent use.

As shown and described herein, various features of the disclosure will be presented. Various embodiments may have the same or similar features and thus the same or similar features may be labeled with the same reference numeral, but preceded by a different first number indicating the figure to which the feature is shown. Thus, for example, element "a" that is shown in FIG. X may be labeled "Xa" and a similar feature in FIG. Z may be labeled "Za. " Although similar reference numbers may be used in a generic sense, various embodiments will be described and various features may include changes, alterations, modifications, etc. as will be appreciated by those of skill in the art, whether explicitly described or otherwise would be appreciated by those of skill in the art.

Embodiments provided herein are directed to methods and systems for performing a receiverless positioning technique for processing requests, such as a request for elevator service. In some embodiments, a request for elevator service may be communicated over one or more lines, connections, or networks, such as one or more cellular networks, e.g. a request made by a user device such as a smart phone. The request for service may be initiated by a mobile device controlled by and/or associated with a user, in a passive or active manner. In some embodiments, the mobile device may be operative in conjunction with a Transmission Control Protocol (TCP) and/or a User Datagram Protocol (UDP). In some embodiments, a request for service may be authenticated or validated based on a location of the mobile device.

In elevator systems that allow for remote elevator requests, issues may arise with nuisance calls where a user unintentionally places an elevator call request. Some conventional techniques use GPS data associated with a user device to place an elevator call to assist in managing nuisance calls. Other conventional systems may implement Bluetooth beacons to obtain positioning information for a user device. However, these techniques may be unreliable and can have high power consumption or energy costs. The techniques described herein provide a receiverless positioning method that does not rely on GPS data, Bluetooth beacons, or other positioning type data to process service requests for an elevator system.

Referring now to <FIG>, an example computing system <NUM> is shown. The computing system <NUM> may be configured as part of and/or in communication with an elevator controller, e.g., controller <NUM> shown in <FIG>. The system includes a memory <NUM> which may store executable instructions and/or data. The executable instructions may be stored or organized in any manner and at any level of abstraction, such as in connection with one or more applications, processes, routines, procedures, methods, etc. As an example, at least a portion of the instructions are shown in <FIG> as being associated with a program <NUM>.

Further, as noted, the memory <NUM> may store data <NUM>. The data <NUM> may include profile or registration data, elevator car data, a device identifier, or any other type(s) of data. The instructions stored in the memory <NUM> may be executed by one or more processors, such as a processor <NUM>. The processor <NUM> may be operative on the data <NUM>.

The processor <NUM> may be coupled to one or more input/output (I/O) devices <NUM>. In some embodiments, the I/O device(s) <NUM> may include one or more of a keyboard or keypad, a touchscreen or touch panel, a display screen, a microphone, a speaker, a mouse, a button, a remote control, a joystick, a printer, a telephone or mobile device (e.g., a smartphone), a sensor, etc. The I/O device(s) <NUM> may be configured to provide an interface to allow a user to interact with the computing system <NUM>. For example, the I/O device(s) may support a graphical user interface (GUI) and/or voice-to-text capabilities.

The components of the computing system <NUM> may be operably and/or communicably connected by one or more buses. The computing system <NUM> may further include other features or components as known in the art. For example, the computing system <NUM> may include one or more transceivers and/or devices configured to receive information or data from sources external to the computing system <NUM>. For example, in some embodiments, the computing system <NUM> may be configured to receive information over a network (wired or wireless). The information received over a network may be stored in the memory <NUM> (e.g. as data <NUM>) and/or may be processed and/or employed by one or more programs or applications (e.g., program <NUM>).

The computing system <NUM> may be used to execute or perform embodiments and/or processes described herein. For example, the computing system <NUM>, when configured as part of an elevator control system, may be used to receive commands and/or instructions, and may further be configured to control operation of and/or reservation of elevator cars within one or more elevator shafts.

Referring to <FIG>, a block diagram of an elevator control system <NUM> for enabling control of an elevator system pertaining to a discussion in accordance with an embodiment is shown. The system <NUM> includes an elevator reservation and control program or application for performing the processing described herein that is executed by one or more computer programs located on a computing system <NUM> and/or one or more user systems <NUM>, <NUM>. The computing system <NUM> of <FIG> may be configured as a computing system similar to computing system <NUM> shown in <FIG>.

The elevator control system <NUM> depicted in <FIG> includes one or more user systems <NUM>, <NUM> through which users, e.g., users and passengers of an elevator system, communicate with the elevator control system <NUM>. The user systems <NUM>, <NUM> are coupled to the computing system <NUM> via a network <NUM>. Each user system <NUM> may be implemented using a general-purpose computer executing a computer program for carrying out the processes described herein. The user systems <NUM>, <NUM> may be user devices such as personal computers (e.g., a laptop, a tablet computer, a cellular telephone, etc.) or host attached terminals. If the user systems <NUM>, <NUM> are personal computers, in some embodiments, the processing described herein may be shared by a user system <NUM>, <NUM> and the host system <NUM>. The user systems <NUM>, <NUM> may also include game consoles, smartphones, tablets, wearable electronic devices, network management devices, and field-programmable gate arrays.

The network <NUM> may be any type of known network including, but not limited to, a wide area network (WAN), a local area network (LAN), a global network (e.g. Internet), a virtual private network (VPN), a cloud network, and an intranet. The network <NUM> may be implemented using a wireless network or any kind of physical network implementation known in the art. A user system <NUM>, <NUM> may be coupled to the computing system <NUM> through multiple networks <NUM> (e.g., cellular and Internet) so that not all user systems <NUM>, <NUM> are coupled to the computing system <NUM> through the same network <NUM>. One or more of the user systems <NUM> and the computing system <NUM> may be connected to the network <NUM> in a wireless fashion. In one non-limiting embodiment, the network is the Internet and one or more user systems <NUM> execute a user interface application (e.g. a web browser) to contact the computing system <NUM> through the network <NUM>. In another non-limiting example embodiment, a user system <NUM> may be connected directly (i.e., not through the network <NUM>) to the computing system <NUM>.

As noted, the computing system <NUM> may be associated with an elevator system (e.g., elevator system <NUM> and in communication with or part of controller <NUM> of <FIG>). The computing system <NUM> may be used to process or fulfill requests for elevator service.

The requests for elevator service may be received through the network <NUM> from one or more user systems <NUM>, <NUM>, which may be mobile devices, including, but not limited to phones, laptops, tablets, smartwatches, etc. One or more of the user systems <NUM> may be associated with (e.g., owned by) a particular user. The user may use his/her user device(s) <NUM>, <NUM> to request a service, such as an elevator service.

For example, a user of a user system <NUM> may request service in an affirmative or active manner. For example, the user may enter an explicit request for elevator service using an I/O interface of the user system <NUM>. That is, in some embodiments, an app or other program may be installed and operated on a user system <NUM> wherein the user may interact with the application or other program to request elevator service.

In other embodiments, or in combination therewith, the user may request elevator service in a passive manner. For example, a profile may be established for the user or the particular user system <NUM>, <NUM>, optionally as part of a registration process with, e.g., a service provider. The profile may contain a log of the user's history and/or activities, such as where the user has gone or traveled to, the user's preferences, or any other data that may be applicable to the user. The profile may be accessed or analyzed to determine the likelihood or probability that the user will request elevator service at a particular moment in time (e.g., a particular day or time of day).

The request for service may be conveyed or transmitted from the user system <NUM>, <NUM> through the network <NUM>. For example, the request for service may be transmitted to and/or over the Internet and/or a cellular network. The network(s) may include infrastructure that may be organized to facilitate cloud computing. For example, one or more servers, such as a primary message server, a backup message server, and a device commissioning message server may be employed as part of the network <NUM>.

In some embodiments, the request for service may specify a type of service requested, at any level of detail or abstraction. For example, a first request for service may specify that elevator service is requested, a second request for service may specify one or more of a departure floor and/or a destination floor, and a third request for service may specify that elevator service is desired to accommodate a heavy load (e.g., freight or cargo) with a number of other users or passengers in an amount less than a threshold. In some embodiments, the request for service transmitted from the user system <NUM>, <NUM> may include an identifier associated with the user or the particular user system <NUM>, <NUM> in order to allow, e.g., the computing system <NUM> to distinguish between users and/or user systems <NUM>, <NUM>.

The computing system <NUM> (and program <NUM> stored thereon) may be configured to process requests for service received from one or more mobile systems <NUM>, <NUM>. As part of the processing, the computing system <NUM> may validate or authenticate a user system <NUM>, <NUM> and/or a user, potentially based on an identifier associated with the user and/or the user system <NUM>, <NUM>. The validation may be based on or include a location of the user and/or the user system <NUM>, <NUM>. In one or more embodiments, the location may be determined based on the initial request for service without the assistance of one or more location-based services or techniques, such as triangulation, global positioning system (GPS), network connection, Wi-Fi connection, etc. In one or more embodiments of the disclosure, the location of the initial elevator request is assumed to be the location of the elevator receiving the request.

If a service request is validated or approved by, e.g., the computing system <NUM>, the service request may be transmitted from the computing system <NUM> to one or more controllers, such as one or more elevator controllers (e.g., controller <NUM>). The controllers may be configured to communicate with the computing system <NUM> and/or one another to fulfill service requests. In this respect, it should be noted that service requests might not only originate from user system <NUM>, <NUM> but may also originate locally (e.g., within a building in which the controllers may be located or in which the requested service(s) may be provided). The controllers 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. In some embodiments, the computing system <NUM> may select the resource to fulfill a service request, and such a selection may be transmitted by the computing system <NUM> to one or more of the controllers.

In some embodiments, one or more of the controllers and/or the computing system <NUM> may be registered with a service provider. The service provider may be responsible for accepting and processing (e.g., validating or approving/disapproving) service requests and routing (approved) service requests to an appropriate entity (e.g., one or more elevator controllers).

<FIG> depicts a method <NUM> for performing a receiverless device position approximation in accordance with one or more embodiments. The method <NUM> begins at block <NUM> and proceeds to block <NUM> which provides for receiving, by a processor, a first request corresponding to a first location. In a non-limiting example, the first request can include an elevator call request for an elevator in a first location. The request can be placed locally at the elevator system or remotely transmitted to the elevator system from a user device. Block <NUM> registers data associated with the first request. In one or more embodiments of the disclosure, the registered data includes location information, a timestamp for the request, and other information. The location for the first request is determined without the assistance of the GPS data of a user device, Bluetooth beacon information, IP data, cellular triangulation data, etc. The initial location is determined based on the location where the request is placed, for example, the initial location is assumed to be the location of the elevator where the request is placed. Also, the initial request is considered to be a valid request. In one or more embodiments of the disclosure, the user location is collocated with the first elevator request. That is, the location of the user is initialized to the location of the elevator where the first elevator request is received. Therefore, the system can assume the user is at the location of the first request without the assistance of the GPS data, Bluetooth beacons, IP addresses, positioning data, etc..

Block <NUM> receives a second request at a second location, the first location is different than the second location. A second request is an elevator call request for a second location that is a distance away from the first location. In a non-limiting example, the first elevator system is in a first building and the second elevator system is a second building that is a distance away from the first building. The second request is remotely placed using the user device. For example, a user that is not at the location of the second elevator system or may be in route to the second elevator system, can place an elevator request using a user device for the second elevator system. Block <NUM> compares the first location and the second location. The distance between the first building and the second building can be determined by a number of known techniques by using the coordinates of the first and second building. In a non-limiting example, mapping software can be used to calculate the travel distance and estimated travel time between the first building and the second building. Also, timing information can be compared between the time the first request and the second request are placed. The timing information can assist in determining whether the user can reach the location of the second request based on the elapsed time between the first request and the second request. For example, if <NUM> minutes have passed between the requests and the second building is located a <NUM> minute walk away, this may be deemed a reasonable requests. However, if the second building is a <NUM> hour walk away, the request may be deemed an unreasonable request.

Block <NUM> allows the second request based at least in part on the comparison. In one or more embodiments, the second request is either allowed to be requested to the second elevator system or denied based on one or more factors. If the distance between the first building and the second building exceeds a distance threshold, the second request is not placed. The distance can be a threshold radius. In one or more embodiments of the disclosure, the distance threshold can be a configurable threshold, or the distance threshold can be determined based on the walking speed or speed limits traveled by a vehicle. In some embodiments, the traffic information or modes of transportation can be used to estimate the travel time between the buildings. In addition, the time between placing the first call and the second call can be used. On the other hand, if the second building is within a distance threshold, the second request is transmitted to the elevator system. It may be unreasonable to assume the user can reach the second location. For example, if a user places a subsequent request to an elevator in a building that is <NUM> miles away, the request may be determined to be unreasonable based on the distance and estimated travel time. Therefore, the second calls may be ignored in such an event and the elevator call is not dispatched. In some embodiments an inactivity period can be used to prevent nuisance calls. If the inactivity period has expired between the time the first request was placed and the second request was placed, the second request is allowed. In a non-limiting example, the inactivity period can be in the range of <NUM>-<NUM> minutes in duration and any calls that are placed after the expiration of the inactivity period can be allowed. It should be understood that the inactivity period can be increased or decreased based on the application. Otherwise, the second request is denied.

In one or more embodiments of the disclosure, upon allowing the second request, the location information associated with the user is updated to the second location where the second request was placed. The second location is also determined without using the location or positioning data previously described. For example, if an elevator of a second building is requested, the second location is set to the location of the second building receiving the request. The updated location is now used for placing any subsequent requests and the method <NUM> is repeated to determine whether the request should be allowed or denied.

In one or more embodiments of the disclosure, the interactive distance threshold or threshold radius is configurable and can be increased or decreased based on the application. In one or more embodiments of the disclosure, the threshold radius can be increased as a function of time from the initial request. For example, the threshold radius may be increased by an average distance a person can walk over a period of time. In another example, the threshold radius can be a dynamic or variable threshold and may be increased by a default value such as a number of feet per second or some other value. The method <NUM> ends at block <NUM>.

In a different application, the techniques described herein can be applied to credit card transactions. For example, if a credit card is used at a first location and subsequently used in another location outside of a distance radius or timeout period from the first use, the second transaction can be declined. This scenario may indicate a fraudulent use and provide protections to credit card users.

<FIG> illustrates non-limiting examples for the system <NUM> in accordance with one or more embodiments of the disclosure. In a first scenario, a user places an elevator request to a first building <NUM> using a user device <NUM>. The user's location is initialized to be the location at the first building <NUM> and a request radius <NUM> is established. Next, the user takes a <NUM> minute walk to a second building <NUM> where a second elevator request is placed. The system accepts the second request to the second building <NUM> because the accepted elevator request radius increased over the elapsed time to include the second building <NUM> as shown by the radius <NUM>.

In another scenario, a user places an elevator request to the first building <NUM> and immediately tries to place a second elevator request in the second building <NUM>. The request placed to the second building <NUM> is denied because the second building <NUM> is located at a <NUM> minute walk away, and would not be within the accepted elevator request radius <NUM> at the time of the second elevator request.

In a different scenario, a user places a first elevator request to the first building <NUM> and does not place another elevator request for an extended period of time (such as <NUM> minutes). Subsequently, the user places a second elevator request for a different building <NUM> located <NUM> miles away (approximately <NUM> hours walking). The second elevator request is accepted because the inactive period has elapsed, and the device location is updated to the other building <NUM>.

In one or more embodiments, the first location is determined without the assistance of any location information such as a GPS system or indoor positioning system. The first request for a particular elevator is used as a proxy for the first location. The technical effects and benefits include reducing the number of nuisance calls or potentially fraudulent requests for a transaction.

Claim 1:
A method for operating a receiverless device positioning, the method comprising:
receiving, by a processor (<NUM>), a first request corresponding to a first location (<NUM>);
registering data (<NUM>) associated with the first request;
receiving a second request at a second location (<NUM>), the first location is different than the second location;
characterised by:
comparing the first and second location, and time between the first request and the second request; and
allowing the second request based at least in part on the comparison.