Apparatus for determining passenger status, systems for determining passenger status, method for determining passenger status and computer program product
By using beacons to analyze signal strength and previous passenger states, the system effectively tracks passenger status throughout their journey, enhancing reliability and reducing computational and data processing burdens.
Patent Information
- Application Number
- JP2025017777
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2021-01-25
- Filing Date
- 2025-02-05
- Publication Date
- 2025-05-09
AI Technical Summary
Existing transportation management systems rely on global positioning systems and wireless networks to determine passenger location, which does not accurately track passenger status throughout their journey and lacks the ability to improve trackability of passenger interaction with traffic services.
The system employs beacons installed in public transport facilities that transmit signals to passenger mobile devices, allowing for the determination of passenger condition by analyzing beacon signal strength and previous passenger states, without relying on external positioning systems.
This approach provides reliable and continuous tracking of passenger status throughout their journey, reducing computational effort and data processing requirements, while avoiding errors associated with external positioning systems.
Smart Images

Figure 2025072525000001_ABST
Abstract
Description
[Technical field]
[0001] The present subject matter particularly relates to an apparatus and system for increasing the reliability of passenger status determination, preferably in a public transport system. Corresponding systems, methods and computer program products are also provided. In particular, the reliability is increased by the architecture of the apparatus and system, which may be used independently of external positioning systems, such as Global Navigation Satellite Systems (GNSS), since the beacons are installed directly on the public transport facilities. Further aspects that serve to synergistically increase the reliability may become apparent from the following as well as additional technical advantages. [Background technology]
[0002] Prior art such as US Pat. No. 6,399,933 describes a transportation management system that allocates resources by monitoring geospatial and topological locations of passengers in response to receiving trip requests. A travel management module matches a passenger with an available driver based in part on a comparison of the passenger and driver's estimated time of arrival (ETA) at a pickup location. A client positioning module monitors the passenger's progress through nodes and edges in a topological graph associated with an origin location based on radio signatures received at the passenger client device. A client ETA module calculates a rider ETA based on the passenger's speed of travel through the origin location represented by a node in the topological graph. In response to determining that the passenger ETA and driver ETA change by more than a threshold time, the travel management module matches the passenger with a second available driver. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] International Publication No. 2018 / 215958A1 Summary of the Invention [Problem to be solved by the invention]
[0004] In the system shown in the patent document 1, the current location of the passenger is determined by a global positioning system and / or a wireless network system. The actual status of the passenger using the transport service is not determined. However, simply determining the passenger location using the above means creates the problem that the passenger location cannot be determined throughout the passenger journey and the advantage of improving the traceability of the passenger's interaction with the transport service provided by the determination of the passenger status cannot be retained. [Means for solving the problem]
[0005] In view of the above, a technical objective of the present disclosure is to provide an apparatus, a system, a method and a computer program product capable of providing reliable and low computational effort occupant status determination. This objective is achieved by the subject matter of the appended claims.
[0006] According to the subject matter of the appended claims, an apparatus for determining passenger status is proposed. The apparatus is preferably a fixed server. The server may further preferably be connected to a passenger's mobile device via a wireless data connection. The mobile device may be a smartphone, a tablet, a laptop, a smartwatch, etc. The mobile device may further preferably have a graphic user interface for displaying relevant information to a user of the mobile device. The mobile device may further preferably interact with a beacon transmitting a beacon signal via a radio signal that may be wirelessly received by the mobile device when located within range of the beacon signal.
[0007] The beacon may preferably be installed on / in / at a stationary object. Particularly preferably, the beacon is installed on / in / at an object of a public transport system, such as a train station or a bus station. Furthermore, the beacon may be installed on / in / at a moving object. Particularly preferably, the beacon is installed on / in / at a moving object of a public transport system, such as a bus or a train. The beacon may be implemented using any suitable hardware and / or software configured for wireless communication with a passenger's mobile device. In particular, the beacon may act as a standalone device including a processor, a communication module, and / or a network interface component configured to communicate with the passenger's mobile device and / or a service provider server. Preferably, the beacon periodically and / or constantly emits a signal in a predefined range around the beacon.
[0008] According to one aspect, the invention may include a data storage unit capable of storing information that may be stored in a beacon definition table, a beacon signal management table, and / or a passenger status definition table. The data storage unit may preferably be an internal storage unit for storing, among other things, the information described below, preferably in a database structured as a table or other suitable data format or the like. The data storage may be provided in the user's mobile device, the apparatus, or in other remote locations. Also, the data storage may be distributed across different storage locations.
[0009] The beacon definition table may preferably be configured to store a beacon ID, a location ID indicating the location of the beacon, and an attribute indicating whether the beacon is installed on a moving or stationary object. The attribute may preferably be a quality corresponding to the beacon ID that facilitates identification of a beacon installed on a stationary object or a signal received from a beacon installed on a moving object. The attribute may be a text or character (string of characters) indicating whether the signal is emitted from a moving object beacon or a stationary object beacon.
[0010] The beacon signal management table may preferably be configured to store a beacon ID for each beacon signal received from a mobile device and a timestamp indicating the time of receipt of the beacon signal.
[0011] The passenger state definition table may preferably be configured to store information regarding previous or current passenger states and beacon signal strengths.
[0012] The term passenger state can be understood as the state of a passenger using a public transport facility, such as a train station or a bus station, and its corresponding transport means, such as a train or a bus, which can include activities such as waiting for the transport means at the respective station, being on the transport means, or entering or being outside the station.
[0013] The term beacon signal strength may be understood as a value that may be represented by a discrete number, which may be preferably achieved according to the following description.
[0014] Furthermore, the apparatus may include a beacon ID conversion module configured to read the location ID and attributes of a received beacon signal from the beacon definition table and write the beacon ID and a timestamp to the beacon signal management table.
[0015] Writing of the beacon ID into the signal management table may preferably be performed such that the received beacon ID is written into a column of the signal management table according to the attributes corresponding to that beacon ID.
[0016] In other words, beacon IDs may be stored in the signal management table in a different way or in different parts of the database depending on whether they originate from a moving or stationary object / beacon. That is, beacon IDs received from beacons installed on stationary objects or beacons installed on moving objects, respectively, are stored in the signal management table in a different way, provided that the beacon IDs are well stored as such. Such "pre-sorted storage" of beacon IDs in the signal management table is optional, but improves responsiveness and data return rate / time when information is to be read from the beacon signal management table. If the "table" is not a table, other pre-sorting methods may be applied so that IDs can be stored in predefined "locations" or tagged so that IDs can be quickly differentiated / processed with respect to corresponding attributes.
[0017] The device may further comprise a beacon signal recognition module configured to determine a moving object beacon signal strength of a beacon signal received from a beacon installed on a moving object and a stationary object beacon signal strength of a beacon signal received from a beacon installed on a stationary object, the beacon signal strength being preferably the sum of the number of beacon IDs stored in the beacon signal management table at a particular time or during a particular period of time.
[0018] In other words, the device can determine the beacon signal strength in beacon signals received from beacons installed on stationary objects and beacons installed on moving objects, which may be defined as a discrete number representing the sum of the number of beacon IDs received from each beacon.
[0019] The apparatus may further comprise a passenger state estimation module configured to determine a current state of a passenger based on the moving object beacon signal strength, the stationary object beacon strength, and / or a previous passenger state.
[0020] The above device allows passenger status to be reliably determined. The passenger status may be, for example, a status where the passenger is in a station while waiting for a train. Technically, and particularly considering the reliability and low computational effort, the device can determine the beacon signal strength and subsequently calculate the sum of the number of beacon IDs received from beacons installed on stationary objects and / or beacons installed on moving objects to determine the passenger status using the public transport facility based on the beacon signal strength and / or previous passenger status, which can be performed without significant computational cost. In other words, the passenger status, and therefore also the location, can be determined continuously throughout the passenger journey based on a relatively simple hardware architecture and computationally uncomplex operations that only require the beacons and the user mobile device. Furthermore, only a few parameters are required to reliably determine the status so that the amount of data to be transferred, stored, and / or processed is relatively small, which also leads to a reduction in computational processing effort.
[0021] Also, since the device can operate as a quasi-standalone system relying on beacon signal strength and passenger status information, there is no need for additional infrastructure such as a satellite-based navigation system, etc. However, to provide greater flexibility, a satellite-based navigation system can be added to the system as needed.
[0022] Further, preferably, the passenger state estimation module may be configured to determine a current state of a passenger based on the moving object beacon signal strength, the stationary object beacon signal strength, the change in the moving object beacon signal strength over time, the change in the stationary object beacon strength over time, and / or a previous passenger state.
[0023] The term "change over time" of beacon signal strength can be understood as the change over time of the sum of the number of beacon IDs received from either beacons installed on stationary objects or beacons installed on moving objects. In other words, the increase or decrease of the beacon signal strength at each beacon can be used to determine the occupant status. The sum of the number of beacon IDs received from moving or stationary beacons is associated with the increase or decrease in the number of received moving or stationary beacon signals, respectively. Thus, the value representing the beacon signal strength can be an absolute value that increases with the number of beacon IDs received from moving or stationary beacons (during a certain period of observation / sum construction).
[0024] In particular, from the perspective of increasing the reliability of the occupant state determination, the above determination based on the time-dependent changes in moving object beacon signal strengths and stationary object beacon signal strengths is technically advantageous since it can better avoid erroneous determination of the occupant state, and the parameters used for the determination can be determined / calculated without high effort while at the same time providing a reliable "picture" regarding the determined state.
[0025] The state estimation module is enabled to accurately determine the passenger state by using the dynamic changes in the relative positions. Thus, if the determined beacon signal strength changes, it can be assumed that the current passenger state changes due to the change in the relative distance between the passenger and the object on which the beacon is installed. This is particularly technically beneficial for reliable determination of passenger state in dynamically changing scenarios involving passengers, moving objects such as trains or buses, and stationary objects such as bus stations or train stations.
[0026] In this regard, the use of beacons provides a reliable method of tracking the movement of the object in a highly resolved manner both temporally and spatially.
[0027] Further preferably, the passenger state estimation module may be configured to determine the current passenger state by selecting one passenger state from a plurality of predefined passenger states stored in a passenger state definition table.
[0028] In other words, the passenger state definition table may include multiple preset / predefined states that can be directly selected by the state estimation module. This helps to reduce the computational effort during passenger state determination, since the predefined states can be selected without additional complex computational operations. Also, by directly selecting the predefined passenger states from the passenger state definition table, the responsiveness and data return rate / time during passenger state determination is improved. Most preferably, the table includes a set of predefined combinations for different parameters and their respective states to be output. Alternatively, it may also be realized that the parameter combinations are processed by, for example, a machine learning algorithm that is trained and learns to output states based on the parameter combinations.
[0029] Further, preferably, a plurality of predefined passenger states may be defined in a passenger state definition table, where each passenger state may be based on at least one combination of the absolute value of the moving object beacon signal strength, the absolute value of the stationary object beacon strength, the change in the moving object beacon signal strength over time, the stationary object beacon strength, and / or a previous passenger state. The change in the signal strength over time may be monitored, in particular taking into account the direction of the change, i.e. whether the signal strength is increasing or decreasing.
[0030] The above synergistically increases the improved reliability / reduced computational effort of the device by using a plurality of predefined passenger states, where a particular passenger state is associated with at least one combination of beacon signal strength, beacon signal strength change over time, and / or previous passenger states. In other words, the determination of the passenger state can be facilitated by referring to predefined scenarios corresponding to the above information on beacon signal strength and previous passenger states. This is particularly beneficial for the selection of the current passenger state, for example, since possible candidates for determining the current passenger state can be narrowed down accordingly by selecting only from the set of predefined passenger states associated with the above combination.
[0031] According to the above, the determination of the current passenger state can be performed with less computational effort since previously determined passenger states can be used to narrow down the number of possible predefined passenger states to be selected by the passenger state estimation module, which also reduces the risk of erroneous determination of the current passenger state and therefore also increases the reliability of the device.
[0032] More preferably, the plurality of predefined passenger states stored in the passenger state definition table may include predefined passenger states such as "outside", "waiting", "ready to board" and "boarding", where the term "outside" may represent a state in which the passenger is outside a public transportation station or vehicle, the term "waiting" may represent a state in which the passenger is waiting for a public transportation vehicle at a station, the term "ready to board" may represent a state in which the passenger is ready to board at a station, and the term "boarding" may represent a state in which the passenger is boarding the public transportation vehicle. Further states may be defined.
[0033] Further, preferably, the beacon signal recognition module may be configured to determine a moving object beacon signal strength by counting the number of beacon IDs of beacon signals received from moving objects stored in the beacon signal management table, and to determine a stationary object beacon signal strength by counting the number of beacon IDs of beacon signals received from stationary objects stored in the beacon signal management table.
[0034] In other words, the device can determine its beacon signal strength by counting all beacon IDs received from beacons installed on stationary or moving objects written into the beacon signal management table and forming a sum (continuously) of the number of all beacon signals received.
[0035] This is particularly technically beneficial for reliable determination of occupant status based on beacon signal strength, since the beacon signal strength can be determined after the expiration of any given interval, which allows for a continuous and more flexible determination of beacon signal strength for beacons installed on stationary or moving objects that is less susceptible to errors in signal reception, thus helping to increase the reliability of the device.
[0036] Furthermore, preferably, the beacon signal management table may be configured to store each beacon ID so as to distinguish between the beacon IDs of stationary objects and moving objects, for example.
[0037] That is, the beacon signal recognition module may store the received beacon ID in a predetermined position such as a column of the beacon signal management table according to the attribute corresponding to the beacon ID. This means that the beacon signal management table has a plurality of predetermined storage positions capable of storing a plurality of beacon IDs according to the corresponding attribute. This makes it possible to distinguish between the beacon ID received from the beacon installed on the stationary object and the beacon ID received from the beacon installed on the moving object. For example, the beacon ID received from the beacon installed on the stationary object may be stored in a first column of the beacon management table, and the beacon ID received from the beacon installed on the moving object may be stored in a second column of the beacon management table.
[0038] This synergistically enhances the reliability of the device by providing the advantage of facilitating identification of the IDs received from beacons installed on stationary or moving objects, and also helps to reduce the computational effort during the determination of the beacon signal strength of each beacon, since the information about the type of the received beacon is already integrated in the beacon signal management table.
[0039] Further, preferably, the beacon ID conversion module may be configured to periodically sample the received beacon signal and write the beacon ID and a timestamp of reception into the beacon signal management table at a first predetermined time interval.
[0040] The expression sampling periodically shall mean that the beacon ID conversion module can check the recurring time interval when a beacon signal containing a beacon ID is received from a stationary or moving beacon. The term first predetermined time interval shall be understood as the time interval between two sampling processes of the beacon signal and the corresponding process of storing the respectively received beacon ID in the beacon signal management table. The first predetermined time interval may preferably be a time ranging from 1 second to 10 seconds. However, it may be longer or shorter.
[0041] This is particularly beneficial in reducing the computational effort for determining occupant status while keeping storage usage and processor load low. Also, the reliability of the device can be increased by sampling the received beacon signals according to predetermined intervals in order to efficiently track changes in beacon signal strength over time.
[0042] Alternatively, the beacon ID conversion module may be configured to continuously update the beacon signal management table each time a beacon ID is received, and store the received beacon ID in the beacon signal management table together with a timestamp.
[0043] Furthermore, preferably, the beacon signal recognition module may be configured to determine the beacon signal strength after expiration of a second predetermined time interval that is greater than or equal to the first predetermined time interval.
[0044] The term second predetermined time interval should be understood as the time interval between two determination processes of the beacon signal strength performed by the beacon signal recognition module, which may be longer, but is preferably in the range of a few seconds to a few minutes.
[0045] The above synergistically enhances the reliability of the device in that the determination of the beacon signal strength after a predefined repeatable interval allows for reliable determination of passenger status according to application specific intervals, which also helps to reduce the computational effort by keeping storage usage and processor load low.
[0046] Furthermore, preferably, the beacon signal recognition module may be configured to reset the beacon signal management table after expiration of a second predetermined time interval.
[0047] In other words, a reset of the beacon signal management table may be performed after the sum of the number of detected beacon IDs is used to determine the beacon signal strength of the beacons installed on stationary objects and the beacons installed on moving objects according to a second predetermined time interval.
[0048] Also, preferably, the beacon signal strength may be further determined before the expiration of the second predetermined time interval to determine the time variation of the beacon signal strength within the second predetermined time interval according to the prior interval. Thus, the achieved intermediate value of the beacon signal strength serves to increase the resolution of determining the time variation of the beacon signal strength.
[0049] The above synergistically improves the reliability of the device by ensuring that sampling of received beacon signals is always done over an equal number of first predetermined time intervals. This results in a reproducible and more reliable determination of beacon signal strength. Furthermore, resetting the beacon signal management table helps keep storage usage low, thereby reducing computational effort.
[0050] Furthermore, preferably, the beacon signal recognition module may be configured to reset the beacon signal management table by overwriting the beacon ID and timestamp pre-stored in the beacon signal management table.
[0051] In other words, the resetting of the beacon signal management table may be performed by overwriting the beacon ID and timestamp stored in the beacon signal management table according to a "first in, first out" policy. This helps reduce storage usage and reduces computational effort by storing new information in a less complex storage system. In one aspect of the present invention, the overwriting of the beacon ID stored in the beacon management table may be performed after a second predetermined time interval has elapsed.
[0052] Furthermore, preferably, the beacon signal strength may be represented by a discrete value ranging from a minimum value of zero to a maximum value corresponding to the number of first predefined time intervals within a second predefined time interval.
[0053] In other words, the maximum value of the beacon signal strength, and therefore the maximum number of successful ID samples, can correspond to the number of first predetermined intervals that fall within the second predetermined time interval, ranging down to a minimum value of 0 if no sampling was successful during the second predetermined time interval.
[0054] Furthermore, preferably, the beacon recognition module may be configured to store the beacon ID of each beacon signal received from the mobile device in a predetermined memory location of the signal management table according to an attribute corresponding to the beacon ID.
[0055] Further, preferably, the passenger state estimation module may be further configured to store in a passenger state history table included in the data storage unit a start time as the first time when the passenger state estimation module first determines a current state of the passenger, and an end time as the time when the passenger state estimation module determines a current state of the passenger with respect to the last time during the passenger journey.
[0056] Moreover, preferably, the device may further comprise a journey confirmation module configured to store in a journey history table comprised in the data storage unit a journey start station as an assignment where the passenger starts the journey and a journey end station as a location where the passenger ends the journey, thereby making it possible to provide the user / passenger with journey data that can, for example, assist the user in smoothly traveling from one location to another.
[0057] Further claimed is a system comprising a server, a passenger mobile device comprising a beacon signal detector, at least one beacon installed on a stationary object configured to transmit a beacon signal comprising a beacon ID, and / or at least one beacon installed on a moving object configured to transmit a beacon signal comprising a beacon ID. The system provides the technical advantages as mentioned above, especially in view of a less complex architecture allowing reliable detection of the state of a passenger / user of a mobile device in a transportation system without requiring a high computational load.
[0058] Further, a method for determining a passenger status is claimed, which includes the steps of receiving from a mobile device a beacon signal including a beacon ID received by the mobile device from a beacon, retrieving from a storage unit a location ID and an attribute corresponding to the beacon ID indicating whether the beacon is installed on a moving or stationary object, determining a beacon signal strength by constructing a sum of the beacon IDs received from the beacons installed on the moving or stationary object, storing the beacon signal strength for each beacon signal received from the beacon installed on the moving or stationary object in the storage unit, and determining a current status of a passenger based on the beacon signal strength and / or a previous passenger status.
[0059] In other words, each feature of the claimed apparatus is also intended to be encompassed by the method, which may be claimed by itself and / or by a computer program product claim.
[0060] In summary, a solution is provided that offers technical advantages, especially with regard to reliability, reduced computational effort, and reduced data transfer / processing in determining passenger status.
[0061] The claimed subject matter will now be further described on the basis of at least one preferred embodiment with reference to the accompanying drawings. [Brief description of the drawings]
[0062] [Figure 1] 1 shows a schematic diagram of an example of an apparatus for determining passenger status. [Diagram 2] 1 shows a schematic example of determining passenger status using a beacon signal including a beacon ID. [Diagram 3] 1 shows an example of a beacon definition table. [Figure 4] 1 shows an example of a beacon signal management table. [Diagram 5] 13 shows an example of a passenger state definition table. [Figure 6] 13 shows an example of a passenger status history table. [Figure 7] 13 shows an example of a journey history table. [Figure 8] 1 shows an example of a transportation fare table. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0063] FIG. 1 shows a schematic diagram of an exemplary device described in this application. FIG. 1 shows that the device 1000 may include a server 1100 configured to receive beacon signals from a passenger's mobile device 1200, including beacon IDs received by the mobile device 1200 from beacons 1300 installed on a number of stationary objects and beacons 1400 installed on a moving object. The mobile device 1200 is preferably a smartphone, tablet, smartwatch, laptop, or any other computing device. The one or more beacons 1300 installed on the stationary objects and the one or more beacons 1400 installed on the moving objects transmit beacon signals including beacon IDs detectable by a beacon signal detection module 1211 included in the passenger's mobile device 1200 when the passenger's mobile device 1200 is within the range of the beacon signals. This is indicated by the zigzag lines between the exemplary beacons 1300 installed on the stationary objects and the exemplary beacons 1400 installed on the moving objects, respectively.
[0064] A beacon may be a device that continuously or repeatedly emits a medium to short range radio signal that can wirelessly communicate information to other devices. The radio signal emitted by a radio beacon may be part of any suitable standard for medium to short range wireless communication having an operational range of at least 1 meter up to about 50 meters, such as, for example, Bluetooth, Bluetooth 4.0, and Bluetooth Low Energy (BLE). The radio signal described herein may be any suitable type of signal, such as, for example, a broadcast signal that indicates the presence of the device to nearby devices, a pairing signal that requests automatic pairing with nearby devices, or a connection signal that transmits data to connected nearby devices.
[0065] The passenger's mobile device 1200 transmits the received beacon signal including the beacon ID to the server 1100. This is indicated by a zigzag line between the mobile device 1200 and the server 1100. The server 1100 may include a storage unit 1150 including a beacon definition table 1101, a beacon signal management table 1102, a passenger state definition table 1103, a passenger state history table 1104, a journey history table 1105, and / or a transportation fare table 1106. Further, the server 1100 may include a beacon ID conversion module 1111, a beacon signal recognition module 1112, and a passenger state estimation module 1113. Optionally, as shown, the server 1100 may further include a journey confirmation module 1114 and / or a transportation fare confirmation module 1115.
[0066] Fig. 2 shows a schematic example of determining passenger status using beacon signals including beacon IDs. In a first step S1, the beacon ID conversion module 1111 receives a beacon ID transmitted by the passenger's mobile device 1200, which the mobile device 1200 received from a beacon previously emitting a beacon signal. The beacon ID conversion module 1111 determines a location ID and an attribute indicating whether the beacon ID was received from a beacon installed on a stationary object or a beacon installed on a moving object corresponding to the received location ID. This may be performed, for example, by a lookup operation, in which a table such as that shown in Fig. 3 is used.
[0067] The received beacon ID and the determined attribute are then stored in the beacon signal management table 1102 by the beacon ID conversion module 1111 together with a timestamp corresponding to the time when the beacon ID was received. In the next step S2, the beacon signal recognition module 1112 determines the signal strength of the received beacon signal based on the total number of the received beacon IDs and the attribute. Then, the determined beacon signal strength of the beacon signal received from the beacon installed on the stationary object and the beacon signal received from the beacon installed on the moving object are stored in the passenger state definition table 1103. In the next step S3, the passenger state estimation module 1113 determines the current state of the passenger based on the moving object beacon signal strength, the stationary object beacon signal strength, and / or the previous passenger state. Then, the determined current passenger state determined based on the moving object beacon signal strength, the stationary object beacon signal strength, and / or the previous passenger state is stored in the passenger state definition table 1113.
[0068] Subsequently, in step S4, the determined passenger current state is also stored in the passenger state history table 1104, which is added to the set of passenger states taken by the passenger during the journey. In a next step S5, the journey confirmation module 1114 can determine the passenger's journey according to the set of previously determined passenger current states. Further, in optional step S6, the transportation fare confirmation module 1115 can determine the fare to be charged for the determined journey.
[0069] FIG. 3 illustrates an example of a beacon definition table 1101 that may be stored in the apparatus 1100, the mobile device 1200, and / or any other suitable location. For each beacon ID stored in the beacon definition table 1101, a location ID and attributes corresponding to the beacon ID are also stored. The location ID includes information about the location where the beacon is installed. For example, a beacon with beacon ID A1 is installed in station A, which may be a train station or a bus station that is frequently used by public transportation such as trains and buses. As a second example, a beacon with beacon ID X1 is installed in train A, which may be part of a public transportation system. The attributes indicate whether the beacon is installed on a moving object or a stationary object. According to this embodiment, station A has the attribute stationary object, and train A has the attribute moving object. That is, the beacon definition table 1101 can associate a beacon ID included in a beacon signal received from a beacon with a location (where the beacon is installed) and an attribute (whether the beacon is installed on a moving object or a stationary object). This allows the beacon signal itself to carry less information, reducing the data size, but still allowing passenger locations and beacon attributes to be reliably determined. The table can be updated centrally so that new / modified information can be provided simply and uncomplicated.
[0070] FIG. 4 shows an example of the beacon signal management table 1102. In this example, timestamps created according to a predetermined time interval may be stored in a first vertical column of the beacon signal management table 1102. However, the format is merely one possible example, and the "table" may be arranged in a different structure. In a predetermined position of the beacon signal management table 1102, a beacon ID received from a passenger's mobile device 1200 is stored for each stored timestamp. For example, as shown in FIG. 4, the predetermined position for storing the received beacon ID may be a vertical column of the beacon signal management table 1102. In this example, the column in which the received beacon ID is stored is determined by an attribute corresponding to the beacon ID. Thus, the beacon ID received from a stationary object may be stored in a first vertical column of the beacon signal management table 1102, and the beacon ID received from a moving object may be stored in a second vertical column of the beacon signal management table 1102.
[0071] In this example, the timestamps are created according to a first predefined time interval of 1 second. After expiration of a second predefined time interval, which may be 10 seconds, the first created timestamp may be overwritten by the second created timestamp when a new latest timestamp is created after expiration of the second predefined time interval. In this way, the beacon signal management table 1102 is recursively overwritten according to the second predefined time interval according to a first-in-first-out policy. This reduces data storage space, among other things. The beacon signal recognition module 1112 may also alternatively be configured to resume storing beacon IDs and corresponding timestamps in the beacon signal management table 1102 when the contents of the beacon signal management table 1102 are completely reset after expiration of the second predefined time interval.
[0072] After the second predetermined time interval expires, the beacon signal strength of each beacon ID stored in the beacon signal management table 1102 is determined by the beacon signal recognition module 1112 by constructing the sum of the number of beacon IDs stored in the beacon signal management table 1102. In the example shown in FIG. 4, the beacon signal strength of the beacon with beacon ID A1 is determined to have an absolute value of 5 because A1 was received five times during the illustrated process of beacon signal sampling. Thus, the beacon signal strength of the beacon with beacon ID X1 is determined to have an absolute value of 3 because X1 was received three times during the illustrated process of beacon signal sampling. Alternatively, the beacon signal recognition module 1112 may determine the beacon signal strength by determining a moving average value resulting from the process of successive sampling. The strength values may be stored in another table (not shown) for tracking the change in values over time.
[0073] 5 illustrates an example of passenger state determination performed by the passenger state estimation module 1113. According to the illustrated example, the passenger state determination is performed based on a scenario table.
[0074] The beacon signal window for determining the beacon signal strength of the beacons installed on the stationary object and the beacons installed on the moving object may be the second predetermined time interval in this example. Thus, the possible values of each beacon signal strength range from a minimum value of 0 to a maximum value corresponding to the number of the first predetermined time interval within the second predetermined time interval. The predefined passenger states include, but are not limited to, "outside", "waiting", "ready to board", "boarding" and / or "alighting", where the term "outside" refers to a state where the passenger is outside the station and the public transportation vehicle, the term "waiting" refers to a state where the passenger is waiting for the public transportation vehicle at the station, the term "ready to board" refers to a state where the passenger is ready to board at the station, the term "boarding" refers to a state where the passenger is boarding the public transportation vehicle, and the term "alighting" refers to a state where the passenger is alighting at the station.
[0075] In the passenger state definition table 1103, the current passenger determined by the passenger state estimation module 1113 is stored at the intersection of the predefined passenger state and the determination result of the mobile beacon signal strength and the stationary beacon signal strength performed by the beacon signal recognition module 1112. In this example, the predefined passenger state is the previous passenger state determined in a previous process of passenger state determination. If a previous determination of the current passenger state has not been performed by the device, the previous passenger state can be assumed to be "outside". Furthermore, in this example, the result of the determination of the beacon signal strength can be classified into a set of predefined possible results. The possible results can include combinations of the beacon signal strength of the mobile beacon and the stationary beacon represented by values such as 0, 1~max and half~max. As mentioned above, max represents a maximum value corresponding to the number of first predetermined time intervals within a second predetermined time interval, and 0 represents a minimum value of 0.
[0076] The determination of the current passenger state is explained using the exemplary case shown in Figure 5. In this case, the previous passenger state has been determined to be "outside" in the previous determination of the current passenger state, and the combination of beacon signal strengths of the moving and stationary beacons has been determined by the beacon signal recognition module 1112 after the expiration of the second predetermined time interval. In particular, the signal strength of the beacons installed on the moving object has been determined to be 0, and the signal strength of the beacons installed on the stationary object has been determined to be greater than 1.
[0077] If the previous passenger state is determined to be "outside", a condition should apply that the passenger's mobile device 1200 did not receive a beacon signal. Correspondingly, the signal strength of the beacon installed on the stationary object and the beacon signal strength of the beacon installed on the moving object should be determined to be 0 in the previous determination of the passenger state. To determine the current passenger state following the previously determined passenger state, the beacon signal strength of each beacon should be determined again by the beacon signal recognition module 1112 as shown in FIG. 4. Then, the passenger state estimation module 1113 determines the current passenger state by selecting a passenger state from a plurality of predefined passenger states stored in the passenger state definition table 1103 according to the determination result of the beacon signal strength.
[0078] In this example, the current passenger state is determined by the passenger state estimation module 1113 to be "waiting". This result is based on the previous passenger state determined to be "outside" and the change over time of the beacon signal strength of both the moving and stationary beacons obtained in the passenger state determination step S10. When the beacon signal strength of both beacon types changes from 0 to 0 for the moving beacons and from 1 to max for the stationary beacons, the passenger state estimation module 1113 determines in the passenger state determination step S11 that the condition of the scenario is met in which the passenger has entered the signal range of at least one beacon installed in a stationary object such as a bus station or a train station. In other words, in the passenger state determination step S12, the state estimation module 1113 determines that the current state of the passenger is "waiting", which means that the increase over time of the beacon signal strength received from the beacons installed in the stationary object means that the passenger has entered the station from outside to wait for the public transport means.
[0079] Depending on the change in beacon signal strength over time as determined by the beacon signal recognition module 1112, a number of current occupant states may be determined depending on previous occupant states.
[0080] FIG. 6 shows an example of the passenger state history table 1104. For each passenger state determined by the passenger state estimation module 1113, a start time and an end time are also stored. The start time is the first time that the passenger state estimation module 1113 determines the passenger's current state for the first time, and the end time is the last time that the passenger state estimation module 1113 determines the passenger's current state during the passenger journey. By storing the start time and the end time of each state determined by the passenger state estimation module 1113 as the current passenger state, the passenger's journey can be efficiently tracked and the respective information can be provided to the passenger to assist / guide him / her during the passenger journey. Thus, the device 1000 provides the possibility to continuously record the passenger state during the passenger journey. Thus, the passenger's state can be reproduced at each point of the user journey. Furthermore, the beacon ID received during the passenger journey allows the device 1000 to determine the location where the passenger took the recorded state during the passenger journey. The information about the passenger location associated with the received passenger ID of the moving or stationary beacon can be used to compile the contents of the journey history table as described below.
[0081] FIG. 7 shows an example of a journey history table 1105. The journey history table 1105 stores a start station and an end station for a user journey. The start station is a public transport station, such as a bus station or a train station, where a passenger starts a passenger journey, and correspondingly, the end station is a public transport station where a passenger finishes a passenger journey. The journey confirmation module 1114 stores the start station and the end station for each passenger journey in the journey history table. By storing the start station and the end station, the total distance traveled by the passenger during the passenger journey can be determined. This can be used in any subsequent steps of transportation fare determination.
[0082] FIG. 8 shows an example of a transportation fare table 1106. The transportation fare table stores a travel start station of a passenger journey, a travel end station of the passenger journey, and a corresponding fare that a passenger must pay to use public transportation to reach the travel end station from the travel start station. Depending on the distance between the travel start station and the travel end station, the transportation fare confirmation module 1115 can determine the transportation fare of each passenger journey and store it in the transportation fare table 1106. In the illustrated example, the transportation fare of the passenger journey from station A to station B can be 120 units or subunits of any country's currency.
[0083] In summary, the present disclosure provides a reliable apparatus 1000, as well as systems, methods, and computer program products for determining passenger status. Thus, the passenger status is determined by receiving beacon signals including beacon IDs from beacons installed on stationary objects and beacons installed on moving objects, storing the received beacon IDs with corresponding attributes and timestamps in a beacon signal management table, determining moving object beacon signal strengths of the beacon signals received from the beacons installed on the moving objects and stationary object beacon signal strengths of the beacon signals received from the beacons installed on the stationary objects by building a sum of the number of beacon IDs received from the moving objects and stationary objects stored in the beacon signal management table, and determining a current status of the passenger based on the moving object beacon signal strengths, the stationary object beacon signal strengths, and / or the previous passenger status.
[0084] This provides the advantage, among others, of a particularly reliable determination of the passenger state, since the use of beacons to determine the passenger state provides an architecture independent of external systems for positioning that makes it less susceptible to external detection errors. Furthermore, the described constant sampling of beacon signals results in a more efficient and reliable tracking of the passenger state based on a combination of different types of beacon signals. In addition, the described storage of beacon signal IDs and predefined passenger states allows for the provision of a less complex data storage structure and a reduction in storage usage. Also, storing predefined passenger states in the passenger state definition table leads to a reduction in the computational effort in passenger state determination due to the preselection of possible current passenger states according to the aforementioned scenarios.
[0085] As will be appreciated by one skilled in the art, the present disclosure may be embodied as a method, an apparatus (including a device, machine, system, computer program product, and / or any other apparatus), or a combination of the above, as described above and in the accompanying drawings.
[0086] Accordingly, embodiments of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects which may be referred to herein generally as a "system."Furthermore, embodiments of the present disclosure may take the form of a computer program product on a computer-readable medium having computer-executable program code embodied in the medium.
[0087] It should be noted that arrows may be used in the drawings to represent communications, transfers, or other activities involving two or more entities. A bidirectional arrow generally indicates that activity can occur in both directions (e.g., a command / request in one direction and a corresponding response in the other direction, or peer-to-peer communication initiated by either entity), although in some circumstances activity may not necessarily occur in both directions.
[0088] It should be noted that while unidirectional arrows may generally indicate exclusively or primarily one-way activity, in certain circumstances such directional activity may actually include bidirectional activity (e.g., a message from sender to receiver and an acknowledgment from receiver to sender, or the establishment of a connection before a transfer and the termination of a connection after a transfer.) Thus, the types of arrows used in particular drawings to represent particular activities are exemplary and should not be considered limiting.
[0089] The aspects are described above with reference to flowchart illustrations and / or block diagrams of the methods and apparatus, and with reference to some sample views of graphical user interfaces generated by the methods and / or apparatus. It can be understood that each block of the flowchart illustrations and / or block diagrams, and / or combinations of blocks in the flowchart illustrations and / or block diagrams, and the graphical user interfaces can be implemented by computer-executable program code.
[0090] Computer-executable program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a particular machine, such that the program code, executed via the processor of the computer or other programmable data processing apparatus, creates means for implementing the functions / acts / output specified in the flowchart, block diagram block or blocks, diagrams, and / or written description.
[0091] These computer executable program codes may also be stored in a computer readable memory that can instruct a computer or other programmable data processing apparatus to function in a particular manner, such that the program code stored in the computer readable memory produces an article of manufacture including instruction means that implement the functions / operations / output specified in the flowcharts, block diagram blocks, illustrations, and / or descriptions.
[0092] The computer executable program code may also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps executed on the computer or other programmable apparatus to generate a computer implemented process such that the program code executing on the computer or other programmable apparatus provides steps for implementing the functions / operations / outputs specified in the flowcharts, block diagram blocks, illustrations, and / or specification. Alternatively, the computer program implemented steps or operations may be combined with operator or human performed steps or operations to carry out the embodiments.
[0093] It should be noted that terms such as "server" and "processor" may be used herein to describe devices that may be used in certain embodiments and should not be construed as limiting to any particular device type unless the context otherwise requires. Thus, a device may include, but is not limited to, a bridge, a router, a bridge-router (router), a switch, a node, a server, a computer, an appliance, or other types of devices. Such devices generally include one or more network interfaces for communicating over a communications network and a processor (e.g., a microprocessor with memory and other peripherals and / or application-specific hardware) configured to perform the device functions accordingly.
[0094] Communications networks generally may include public and / or private networks and may include local area, wide area, metropolitan area, storage, and / or other types of networks and may use communications technologies including, but not limited to, analog, digital, optical, wireless (e.g., Bluetooth), networking, and internetworking technologies.
[0095] It should also be noted that devices may use communication protocols and messages (e.g., messages that are created, sent, received, stored, and / or processed by the devices) and that such messages may be conveyed over a communication network or medium.
[0096] Unless the context requires otherwise, this disclosure should not be construed as limited to any particular communication message type, communication message format, or communication protocol. Thus, a communication message may generally include, but is not limited to, a frame, a packet, a data crumb, a user data crumb, a cell, or other type of communication message.
[0097] Unless the context requires otherwise, it should be understood that references to particular communications protocols are exemplary and that alternative embodiments may use variations on such communications protocols (e.g., modifications or extensions of the protocols as may be made from time to time) or other protocols known or developed in the future, as appropriate.
[0098] It should also be noted that logic flows may be described herein to demonstrate various aspects and should not be construed as limiting the present disclosure to any particular logic flow or implementation. The described logic can be divided into different logic blocks (e.g., programs, modules, functions, or subroutines) without changing the overall result.
[0099] In many cases, logic elements can be added, modified, omitted, executed in a different order, or implemented using different logic structures (e.g., logic gates, looping primitives, conditional logic, and other logic structures) without changing the overall result.
[0100] The present disclosure may be embodied in many different forms, including, but not limited to, computer program logic for use with a processor (e.g., a microprocessor, microcontroller, digital signal processor, or general purpose computer), programmable logic for use with a programmable logic device (e.g., a field programmable gate array (FPGA) or other PLD), discrete components, integrated circuits (e.g., application specific integrated circuits (ASICs)), or any other means including any combination thereof; computer program logic implementing some or all of the described functionality is typically implemented as a set of computer program instructions that are converted into a computer executable form, stored as such on a computer readable medium, and executed by a microprocessor under the control of an operating system. Hardware-based logic implementing some or all of the described functionality may be implemented using one or more appropriately configured FPGAs.
[0101] Computer program logic implementing all or a portion of the functionality previously described herein may be embodied in various forms, including, but not limited to, source code form, computer executable form, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator).
[0102] Source code may include a series of computer program instructions implemented in any of a variety of programming languages (e.g., object code, assembly language, or high level languages such as Fortran, C, C++, JAVA, or HTML) for use with a variety of operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in a computer executable form (e.g., via an interpreter) or the source code may be converted into a computer executable form (e.g., via a translator, assembler, or compiler).
[0103] Computer executable program code for carrying out operations of the embodiments of the present disclosure may be written in an object-oriented, scripted or non-scripted programming language, such as Java, Perl, Smalltalk, C++, etc. However, computer program code for carrying out operations of the embodiments may also be written in conventional procedural programming languages, such as the "C" programming language or a similar programming language.
[0104] Computer program logic implementing all or part of the functionality previously described herein may execute at different times on a single processor (e.g., simultaneously), or may execute at the same or different times on multiple processors, and may execute under a single operating system process / thread or under different operating system processes / threads.
[0105] Thus, the term "computer process" may generally refer to the execution of a set of computer program instructions, regardless of whether the different computer processes run on the same or different processors, and regardless of whether the different computer processes run under the same operating system process / thread or different operating system processes / threads.
[0106] A computer program may be in any form (e.g., in source code form, computer executable form, or intermediate form) permanently or temporarily fixed on a tangible storage medium, such as a semiconductor memory device (e.g., RAM, ROM, PROM, EEPROM, or flash programmable RAM), a magnetic memory device (e.g., diskette or fixed disk), an optical memory device (e.g., CD-ROM), a PC card (e.g., PCMCIA card), or other memory device.
[0107] A computer program may be fixed in any form of signal that can be transmitted to a computer using any of a variety of communication technologies, including, but not limited to, analog, digital, optical, wireless (e.g., Bluetooth), networking, and internetworking technologies.
[0108] The computer program may be distributed in any form, such as on a removable storage medium with accompanying printed or electronic documentation (e.g., shrink-wrap software), may be preloaded into a computer system (e.g., in system ROM or on a fixed disk), or may be distributed from a server or electronic bulletin board via a communications system (e.g., the Internet or World Wide Web).
[0109] Hardware logic (including programmable logic for use in a programmable logic device) implementing all or a portion of the functionality previously described herein may be designed using conventional manual methods, or may be electronically designed, captured, simulated, or documented using a variety of tools, such as computer-aided design (CAD), hardware description languages (e.g., VHDL or AHDL), or PLD programming languages (e.g., PALASM, ABEL, or CUPL).
[0110] Any suitable computer readable medium may be utilized, including, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or medium.
[0111] More specific examples of computer-readable media include, but are not limited to, an electrical connection having one or more wires, or other tangible storage media, such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a compact disc read-only memory (CD-ROM), or other optical or magnetic storage devices.
[0112] The programmable logic may be fixed permanently or temporarily in a tangible storage medium, such as a semiconductor memory device (e.g., RAM, ROM, PROM, EEPROM, or flash programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., a CD-ROM), or other memory device.
[0113] The programmable logic may be fixed to signals that can be transmitted to a computer using any of a variety of communication technologies, including, but not limited to, analog, digital, optical, wireless (e.g., Bluetooth), networking, and internetworking technologies.
[0114] The programmable logic may be distributed on a removable storage medium with accompanying printed or electronic documentation (e.g., shrink-wrapped software), may be preloaded into a computer system (e.g., in system ROM or on a fixed disk), or may be distributed from a server or bulletin board via a communications system (e.g., the Internet or World Wide Web). Of course, some aspects may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments may be implemented entirely as hardware, or entirely as software.
[0115] While certain exemplary aspects have been described and illustrated in the accompanying drawings, it is to be understood that such aspects are illustrative and that the embodiments are not limited to the specific constructions and arrangements shown and described, as various other changes, combinations, omissions, modifications, and substitutions are possible, in addition to those described in the preceding paragraphs.
[0116] As will be appreciated by those skilled in the art, various adaptations, modifications, and / or combinations of the foregoing embodiments may be made. It is therefore to be understood that within the scope of the appended claims, the present disclosure may be practiced in ways other than as specifically described herein. For example, unless otherwise specified, the steps of the processes described herein may be performed in an order different from that described herein, and one or more steps may be combined, divided, or performed simultaneously.
[0117] Additionally, one of ordinary skill in the art will recognize in light of this disclosure that different embodiments or aspects described herein can be combined to form other embodiments.
Claims
1. An apparatus (1000) for determining a passenger status, configured to receive a beacon signal from a passenger's mobile device (1200), the beacon signal including a beacon ID received by the mobile device (1200) from a beacon, a data storage unit (1150) configured to store information in a beacon definition table (1101), a beacon signal management table (1102) and a passenger status definition table (1103); The beacon definition table (1101) is configured to store a beacon ID, a location ID indicating a location of the beacon, and an attribute indicating whether the beacon is installed on a moving object or a stationary object, The beacon signal management table (1102) is configured to store a beacon ID and a timestamp of each beacon signal received from the mobile device; The passenger status definition table (1103) is configured to store information regarding a previous or current passenger status and a beacon signal strength, and the device (1000) a beacon ID conversion module (1111) configured to read the location ID and the attributes of the received beacon signal from the beacon definition table (1101) and to write the beacon ID and the timestamp of the reception of the beacon signal to the beacon signal management table (1102); a beacon signal recognition module (1112) configured to determine a moving object beacon signal strength of a beacon signal received from a beacon installed on a moving object and a stationary object beacon signal strength of a beacon signal received from a beacon installed on a stationary object, the beacon signal strength being the sum of the number of beacon IDs stored in the beacon signal management table (1102); a passenger state estimation module (1113) configured to determine a current state of a passenger based on the moving object beacon signal strength, the stationary object beacon signal strength, and / or a previous passenger state; The apparatus (1000) further comprises:
2. The apparatus of claim 1 , wherein the passenger state estimation module (1113) is configured to determine a current state of the passenger based on the moving object beacon signal strength, the stationary object beacon signal strength, a change in the moving object beacon signal strength over time, the stationary object beacon strength, and / or the previous passenger state.
3. the passenger state estimation module (1113) is configured to determine the current passenger state by selecting a passenger state from a plurality of predefined passenger states stored in the passenger state definition table (1103); 3. Apparatus according to claim 1 or 2.
4. the plurality of predefined passenger states are defined in the passenger state definition table (1103) based on at least one combination of the absolute value of the moving object beacon signal strength, the absolute value of the stationary object beacon strength, the time-varying value of the moving object beacon signal strength, the stationary object beacon strength, and / or the previous passenger state, respectively; 4. The apparatus of claim 3.
5. The plurality of predefined passenger states stored in the passenger state definition table (1103) include "outside", "waiting", "ready to board", and "boarding", 5. Apparatus according to claim 3 or 4.
6. The beacon signal recognition module (1112) is configured to determine the moving object beacon signal strength by counting the number of beacon IDs of beacon signals received from moving objects stored in the beacon signal management table (1102), and to determine the stationary object beacon signal strength by counting the number of beacon IDs of beacon signals received from stationary objects stored in the beacon signal management table (1102).
6. Apparatus according to any one of claims 1 to 5.
7. The beacon signal management table (1102) stores each beacon ID so as to distinguish between a beacon ID from a stationary object and a beacon ID from a moving object.
7. Apparatus according to any one of claims 1 to 6.
8. the beacon ID conversion module (1111) is configured to periodically sample received beacon signals and to write the beacon ID and the timestamp of reception into the beacon signal management table (1102) at a first predetermined time interval; 8. Apparatus according to any one of claims 1 to 7.
9. the beacon signal recognition module (1112) is configured to determine the beacon signal strength after expiration of a second predetermined time interval that is greater than or equal to the first predetermined time interval.
9. Apparatus according to any one of claims 1 to 8.
10. the beacon signal recognition module (1112) is configured to reset the beacon signal management table (1102) after expiration of a second predetermined time interval; 10. Apparatus according to any one of claims 1 to 9.
11. the beacon signal recognition module (1112) is configured to reset the beacon signal management table (1102) by overwriting the beacon ID and the timestamp previously stored in the beacon signal management table (1102); 11. Apparatus according to any one of claims 1 to 10.
12. the beacon signal strength is represented by a discrete value ranging from a minimum value of 0 to a maximum value corresponding to a number of the first predetermined time intervals within the second predetermined time interval; 12. Apparatus according to any one of claims 1 to 11.
13. 8. The apparatus of claim 7, wherein the beacon signal recognition module (1112) is configured to store the beacon ID of each beacon signal received from the mobile device in a predetermined memory location of the signal management table (1102) according to the attribute corresponding to the beacon ID.
14. the passenger state estimation module (1113) is further configured to store in a passenger state history table included in the data storage unit (1150) a start time as the first time when the passenger state estimation module (1113) determines a passenger's current state for the first time, and an end time as the time when the passenger state estimation module (1113) determines a passenger's current state for the last time during a passenger journey; 14. Apparatus according to any one of claims 1 to 13.
15. a journey confirmation module (1114) configured to store, in a journey history table (1105) included in said data storage unit (1150), a journey start station as the location where the passenger begins the journey and a journey end station as the location where the passenger ends the journey; The apparatus of claim 1 , further comprising:
16. A system comprising an apparatus (1000) according to any one of claims 1 to 15, a passenger mobile device (1200) equipped with a beacon signal detector (1211), a beacon (1300) installed on a stationary object configured to transmit a beacon signal including a beacon ID, and a beacon (1400) installed on a moving object configured to transmit a beacon signal including a beacon ID.
17. 1. A method for determining an occupant status, comprising: receiving a beacon signal from a mobile device, the beacon signal including a beacon ID received by the mobile device from the beacon; reading from a storage unit a location ID and an attribute corresponding to said beacon ID, the attribute indicating whether the beacon is installed on a moving object or a stationary object; determining a beacon signal strength by constructing a sum of beacon IDs received from beacons installed on moving or stationary objects during a predetermined time interval; storing in said storage unit a beacon signal strength for each beacon signal received from a beacon located on a moving or stationary object during said predetermined time interval; determining a current state of a passenger based on the beacon signal strength and / or a previous passenger state; The method includes:
18. A computer program product storable in a memory comprising instructions which, when executed by a computer, cause the computer to carry out the method of claim 17.
Citation Information
Patent Citations
Portable terminal application system, method for settling fare of the system, portable terminal, and server
JP2001307149A
Operation management system, position information providing system, operation management server, operation management method, and position information providing method
JP2016157273A
Fare adjustment device, fare adjustment program and fare adjustment method
JP2017016559A
Portable electronic device, ticket gates, information processing device, system, payment method and program
JP2019053611A
Determining a topological location of a client device using received radio signatures
WO2018215958A1