Apparatus for determining passenger status, system for determining passenger status, method for determining passenger status, and computer program product

Abstract

An apparatus for determining a passenger status comprising: a data storage unit 1150; a beacon ID conversion module 1111 configured to read a location ID and attributes of a received beacon signal; 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, where the beacon signal strength is the sum of the number of beacon IDs stored in the beacon signal management table 1102; and a passenger status estimation module 1113 configured to determine a current status of a passenger based on the moving object beacon signal strength, the stationary object beacon signal strength, and / or a previous passenger status.

Description

Technical Field

[0003] , , , ,

[0001] The present subject matter relates particularly, preferably, to an apparatus and a system for enhancing the reliability of determining passenger status in a public transportation system. Corresponding systems, methods, and computer program products are also provided. In particular, since beacons are installed directly in public transportation facilities, the reliability is improved by an architecture of an apparatus and a system that can be used independently of an external positioning system such as a Global Navigation Satellite System (GNSS). Further aspects that help to synergistically improve the reliability may become apparent from the following as well as additional technical advantages.

Background Art

[0002] Prior art such as Patent Document 1 describes a transportation management system that allocates resources by monitoring the geospatial and topological positions of passengers in response to receiving trip requests. The travel management module matches passengers with available drivers, based in part on a comparison of the estimated time of arrival (ETA) of passengers and drivers at pick-up locations. The client positioning module monitors the progress of a passenger through nodes and edges in a topological graph associated with a starting position, based on a wireless signature received at a passenger client device. The client ETA module calculates a passenger ETA based on the speed of movement of a passenger through a starting position represented by a node in a topological graph. In response to determining that the passenger ETA and the driver ETA change beyond a threshold time, the travel management module matches the passenger with a second available driver.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the system described in Patent Document 1, the passenger's current location is determined by a global positioning system and / or a wireless network system. The actual state of the passenger using the transport service is not determined. However, simply determining the passenger's location using the above means does not allow for determining the passenger's location throughout the entire passenger journey, and thus the advantage of improved traceability of the passenger's interaction with the transport service provided by determining the passenger's state is not retained. [Means for solving the problem]

[0005] In view of the foregoing, the technical objective of this disclosure is to provide an apparatus, system, method, and computer program product capable of providing a reliable and computationally efficient determination of passenger status. This objective is achieved by the subject matter of the appended claims.

[0006] According to the subject matter described in the attached claims, an apparatus for determining passenger status is proposed. The apparatus is preferably a fixed server. The server may more preferably be connected to the passenger's mobile device via a wireless data connection. The mobile device may be a smartphone, tablet, laptop, smartwatch, etc. The mobile device may more preferably have a graphical user interface for displaying relevant information to the user of the mobile device. The mobile device may more preferably be able to interact with a beacon that transmits a beacon signal via a wireless signal which can be received wirelessly by the mobile device when it is located within range of the beacon signal.

[0007] The beacon may preferably be installed on / inside / on a stationary object. Particularly preferably, the beacon may be installed on / inside / on an object of a public transport system such as a train station or bus station. Furthermore, the beacon may be installed on / inside / on a moving object. Particularly preferably, the beacon may be installed on / inside / on a moving object of a public transport system such as a bus or train. The beacon may be implemented using any suitable hardware and / or software configured for wireless communication with passengers' mobile devices. In particular, the beacon can function as a standalone device including a processor, communication module, and / or network interface components configured to communicate with passengers' mobile devices and / or a service provider server. Preferably, the beacon periodically and / or continuously emits a signal within a predetermined range around the beacon.

[0008] According to one embodiment, the present invention may include a data storage unit capable of storing information that can be stored in a beacon definition table, a beacon signal management table, and / or a passenger state definition table. The data storage unit may preferably be an internal storage unit for storing the information described below in a database, preferably structured as a table or other suitable data format. The data storage may be located in the user's mobile device, apparatus, or other remote location. The data storage may also 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 beacon's location, and an attribute indicating whether the beacon is installed on a moving object or a stationary object. The attribute may preferably be a quality corresponding to the beacon ID that facilitates the identification of signals received from a beacon installed on a stationary object or a beacon installed on a moving object. The attribute may also be text or characters (strings) indicating whether the signal originated from a moving object beacon or a stationary object beacon.

[0010] The beacon signal management table may preferably be configured to store the beacon ID of each beacon signal received from a mobile device and a timestamp indicating the time the beacon signal was received.

[0011] The passenger status definition table may preferably be configured to store information regarding previous or current passenger status and beacon signal strength.

[0012] The term "passenger status" can be understood as the state of passengers using public transport facilities such as train stations or bus stations, and their corresponding means of transport, such as trains or buses. This can include activities such as waiting for transport at a station, being on transport, entering a station, or being outside a station.

[0013] The term beacon signal strength can preferably be understood as a value that can be represented by a discrete number, which can be achieved according to the following description.

[0014] Furthermore, the device may include a beacon ID conversion module configured to read the location ID and attributes of a beacon signal received from a beacon definition table, and to write the beacon ID and timestamp to a beacon signal management table.

[0015] The writing of beacon IDs to the signal management table may preferably be performed such that the received beacon ID is written to a column in the signal management table according to the attribute corresponding to that beacon ID.

[0016] In other words, beacon IDs may be stored in the signal management table in different ways or in different parts of the database depending on whether they originated from a moving object or a stationary object / beacon. That is, if beacon IDs are stored so well, beacon IDs received from beacons installed on stationary objects or beacons installed on moving objects, respectively, will be stored in the signal management table in different ways. Such “pre-sorted storage” of beacon IDs in the signal management table is optional, but improves responsiveness and data return rate / time if the 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 a given “place,” or so that IDs can be tagged so that they can be quickly distinguished / processed with respect to corresponding attributes.

[0017] The device may further include a beacon signal recognition module configured to determine the mobile object beacon signal strength of a beacon signal received from a beacon installed on a moving object and the stationary object beacon signal strength of a beacon signal received from a beacon installed on a stationary object, wherein the beacon signal strength is preferably the sum of the number of beacon IDs stored in the beacon signal management table at a specific time or over a specific 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. The beacon signal strength may be defined as a discrete number representing the sum of the number of beacon IDs received from each beacon.

[0019] The device may further include a passenger state estimation module configured to determine the current state of a passenger based on the strength of a moving object beacon signal, the strength of a stationary object beacon signal, and / or previous passenger states.

[0020] The above device ensures reliable determination of passenger status. Passenger status may, for example, be the state of a passenger being in a station while waiting for a train. Technically beneficial, particularly considering reliability and low computational effort, the device can calculate the total number of beacon IDs received from beacons installed on stationary objects and / or moving objects, which can be done without significant computational cost, in order to determine the beacon signal strength and subsequently determine the passenger status using public transport facilities based on the beacon signal strength and / or previous passenger status. In other words, passenger status, and therefore location, can be continuously determined throughout the passenger journey based on a relatively simple hardware architecture and computationally uncomplicated operation requiring only beacons and user mobile devices. Furthermore, the number of parameters required to reliably determine the status is minimal, so that the amount of data transmitted, stored, and / or processed is relatively small, which also leads to a reduction in computational effort.

[0021] Furthermore, because the device can operate as a quasi-standalone system dependent on beacon signal strength and passenger status information, it does not require additional infrastructure such as satellite-based navigation systems. However, to provide greater flexibility, satellite-based navigation systems can be added to the system as needed.

[0022] Furthermore, preferably, the passenger state estimation module may be configured to determine the passenger's current state 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 previous passenger states.

[0023] The term "change over time" of the beacon signal strength can be understood as the change over time of the total number of beacon IDs received from either a beacon installed on a stationary object or a beacon installed on a moving object. In other words, the passenger state can be determined by using the increase or decrease of the beacon signal strength in each beacon. The total number of beacon IDs received from a moving beacon or a stationary beacon is respectively associated with the increase or decrease in the number of received moving beacon signals or stationary beacon signals. Therefore, the value representing the beacon signal strength can be an absolute value that increases with the number of beacon IDs received from a moving or stationary beacon (during a specific period of observation / sum construction).

[0024] Particularly, from the perspective of enhancing the reliability of passenger state determination, the above determination based on the change over time of the moving object beacon signal strength and the stationary object beacon signal strength is technically advantageous because it can better avoid an incorrect determination of the passenger state. The parameters used in the determination can be determined / calculated without high labor, and at the same time, provide a reliable "image" regarding the determined state.

[0025] The state estimation module is enabled to accurately determine the passenger state by using the dynamic change of the relative position. Therefore, when 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 a reliable determination of the passenger state in a dynamically changing scenario including a passenger, a moving object such as a train or a bus, and a stationary object such as a bus station or a train station.

[0026] In this regard, the use of beacons provides a reliable method for tracking the movement of the object in a highly time - and space - resolved manner.

[0027] More 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 the passenger state definition table.

[0028] In other words, the passenger state definition table may include a plurality of preset / predefined states that can be directly selected by the state estimation module. This helps reduce the computational effort during the determination of the passenger state because the predefined states can be selected without additional complex calculation operations. Also, by directly selecting the predefined passenger state from the passenger state definition table, the responsiveness and data return rate / time during the determination of the passenger state are improved. Most preferably, the table includes a set of predetermined combinations for different parameters and each state to be output. Alternatively, it can also be realized that the combination of parameters is processed by a machine learning algorithm that is learned and learns to output a state based on the combination of parameters.

[0029] Furthermore, preferably, the plurality of predefined passenger states may be defined in the passenger state definition table. In this case, 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 over time of the moving object beacon signal strength, the stationary object beacon strength, and / or the previous passenger state. The change over time of the signal strength may be monitored, particularly considering the direction of the change, i.e., whether the signal strength increases or decreases.

[0030] The above synergistically increases the improved reliability and reduced computational effort of the device by using a set of predefined passenger states, each associated with a combination of beacon signal strength, changes in beacon signal strength over time, and / or previous passenger states. In other words, determining a passenger state can be facilitated by referring to predefined scenarios corresponding to the above information regarding beacon signal strength and previous passenger states. This is particularly beneficial for selecting the current passenger state, for example, because the possible candidates for determining the current passenger state can be narrowed down accordingly by selecting only from a set of predefined passenger states associated with the above combinations.

[0031] As described above, previously determined passenger states can be used to narrow down the number of predefined possible passenger states that should be selected by the passenger state estimation module, thus enabling the determination of the current passenger state to be performed with less computational effort. This also reduces the risk of incorrect determination of the current passenger state and therefore increases the reliability of the device.

[0032] More preferably, the multiple predefined passenger states stored in the passenger state definition table may include predefined passenger states such as "external," "waiting," "ready to board," and "on board," in which case the term "external" may represent a state in which the passenger is outside a public transport station or vehicle; the term "waiting" may represent a state in which the passenger is waiting for a public transport vehicle at a station; the term "ready to board" may represent a state in which the passenger is ready to board at any time at a station; and the term "on board" may represent a state in which the passenger is on a public transport vehicle. Further states may be defined.

[0033] Furthermore, preferably, the beacon signal recognition module may be configured to determine the strength of a moving object beacon signal by counting the number of beacon IDs of beacon signals received from a moving object stored in a beacon signal management table, and to determine the strength of a stationary object beacon signal by counting the number of beacon IDs of beacon signals received from a stationary object stored in a beacon signal management table.

[0034] In other words, the device can determine the beacon signal strength by counting all beacon IDs received from beacons installed on stationary or moving objects written in the beacon signal management table, and by continuously forming a total number of all received beacon signals.

[0035] This is particularly technically beneficial for reliable determination of passenger status based on beacon signal strength, as it allows the beacon signal strength to be determined after the expiration of any given interval. This enables continuous and more flexible determination of beacon signal strength for beacons installed on stationary or moving objects that are less susceptible to signal reception errors, thus helping to improve the reliability of the device.

[0036] Furthermore, preferably, the beacon signal management table may be configured to store each beacon ID in such a way as to distinguish between the beacon IDs of stationary objects and moving objects, respectively.

[0037] In other words, the beacon signal recognition module may store the received beacon ID in a predetermined location, such as a column in the beacon signal management table, according to the attribute corresponding to the beacon ID. This means that the beacon signal management table has multiple predetermined storage locations capable of storing multiple beacon IDs according to the corresponding attribute. This makes it possible to distinguish between beacon IDs received from beacons installed on stationary objects and beacon IDs received from beacons installed on moving objects. For example, beacon IDs received from beacons installed on stationary objects may be stored in a first column of the beacon management table, and beacon IDs received from beacons installed on moving objects 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 the identification of IDs received from beacons installed on stationary or moving objects. It also helps reduce the computational effort involved in determining the beacon signal strength for each beacon, as information about the type of beacon received is already integrated into the beacon signal management table.

[0039] Furthermore, preferably, the beacon ID conversion module may be configured to periodically sample the received beacon signal and write the beacon ID and reception timestamp to the beacon signal management table at a first predetermined time interval.

[0040] The expression "periodically sampling" means that when a beacon signal containing a beacon ID is received from a stationary or mobile beacon, the beacon ID conversion module can check the repetition time interval. The term "first predetermined time interval" is understood to mean the time interval between two sampling processes of the beacon signal and the corresponding processes that store the received beacon IDs in the beacon signal management table. The first predetermined time interval may preferably be in the range of 1 to 10 seconds, but it may be longer or shorter.

[0041] This is particularly beneficial in reducing the computational effort required to determine passenger status while keeping storage usage and processor load low. Furthermore, the reliability of the device can be improved by sampling the received beacon signals at predetermined intervals 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 to store the received beacon ID in the beacon signal management table along with a timestamp.

[0043] Furthermore, preferably, the beacon signal recognition module may be configured to determine the beacon signal strength after the expiration of a second predetermined time interval which is at least the same as the first predetermined time interval.

[0044] The term "second predetermined time interval" should be understood as the time interval between two beacon signal intensity determination processes performed by the beacon signal recognition module. The second predetermined time interval 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 by enabling reliable determination of passenger status according to application-specific intervals, as the determination of beacon signal strength after a predetermined, reproducible interval allows for reliable determination of passenger status. This also helps reduce 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 the expiration of a second predetermined time interval.

[0047] In other words, the beacon signal management table may be reset after the total number of detected beacon IDs has been used to determine the beacon signal strength of beacons installed on stationary objects and beacons installed on moving objects, according to a second predetermined time interval.

[0048] Preferably, the beacon signal strength may be further determined before the expiration of the second predetermined time interval in order to determine the change in beacon signal strength over time within the second predetermined time interval according to the prior interval. Thus, the achieved intermediate value of the beacon signal strength helps to increase the resolution for determining the change in beacon signal strength over time.

[0049] The above synergistically improves the reliability of the device by ensuring that the received beacon signal is always sampled over a predetermined number of first time intervals. This results in a reproducible and more reliable determination of beacon signal strength. Furthermore, it helps keep storage usage low by resetting the beacon signal management table, thus 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 previously stored in the beacon signal management table.

[0051] In other words, resetting the beacon signal management table may be performed by overwriting the beacon IDs and timestamps stored in the beacon signal management table in accordance with 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 beacon IDs stored in the beacon management table may be performed after a second predetermined time interval has elapsed.

[0052] Furthermore, preferably, the beacon signal intensity may be represented by discrete values ​​ranging from a minimum value of 0 to a maximum value corresponding to the number of first predetermined time intervals within a second predetermined time interval.

[0053] In other words, the maximum value of the beacon signal intensity, and therefore the maximum number of successful ID samples, can correspond to the number of first predetermined intervals included in the second predetermined time interval, ranging up to a minimum value of 0, if sampling is unsuccessful 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 storage location in the signal management table according to the attribute corresponding to the beacon ID.

[0055] Furthermore, 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 the passenger state estimation module first determines the passenger's current state, and an end time as the time the passenger state estimation module determines the passenger's current state for the last time during the passenger journey.

[0056] Furthermore, preferably, the device may further include a route confirmation module configured to store in a route history table included in the data storage unit a starting station as an assignment for a passenger to begin a route, and an ending station as the place where a passenger will end their route. This makes it possible to provide the user / passenger with route data that helps, for example, the user to move smoothly from one place to another.

[0057] Furthermore, the claims describe a system comprising a server, a passenger mobile device equipped with a beacon signal detector, at least one beacon installed on a stationary object configured to transmit a beacon signal including a beacon ID, and / or at least one beacon installed on a moving object configured to transmit a beacon signal including a beacon ID. The system offers the aforementioned technical advantages, particularly considering a less complex architecture that reliably detects the status of passengers / users of mobile devices in a transport system without requiring a high computational load.

[0058] Furthermore, a method for determining a passenger's status is described in the claims. The method may include the steps of: receiving a beacon signal from a mobile device, the mobile device including a beacon ID received from a beacon; reading a location ID and an attribute corresponding to the beacon ID indicating whether the beacon is installed on a moving object or a stationary object from a storage unit; determining the beacon signal strength by constructing a sum of beacon IDs received from beacons installed on a moving object or a stationary object; storing the beacon signal strength in the storage unit for each beacon signal received from a beacon installed on a moving object or a stationary object; and determining the passenger's current status based on the beacon signal strength and / or previous passenger status.

[0059] In other words, each component of the apparatus described in the claims is also encompassed by method, which may be described in the claims by itself and / or by a claim for a computer program product.

[0060] In summary, the solution provides technical advantages, particularly in terms of reliability, reduced computational effort, and reduced data transfer / processing in determining passenger status.

[0061] The subject matter described in the claims will be further described below, based on at least one preferred example with reference to the attached drawings. [Brief explanation of the drawing]

[0062] [Figure 1] A schematic diagram of an example of a device for determining passenger status is shown. [Figure 2] A schematic example is shown of determining passenger status using beacon signals, including beacon IDs. [Figure 3] An example of a beacon definition table is shown below. [Figure 4] An example of a beacon signal management table is shown. [Figure 5] An example of a passenger status definition table is shown below. [Figure 6] An example of a passenger status history table is shown below. [Figure 7] An example of a travel history table is shown below. [Figure 8] An example of a transportation fare table is shown below. [Modes for carrying out the invention]

[0063] Figure 1 shows a schematic diagram of a typical device described in this application. Figure 1 shows that the device 1000 may include a server 1100, which is configured to receive beacon signals from a passenger's mobile device 1200, including beacon IDs received by the mobile device 1200 from a plurality of beacons 1300 installed on stationary objects and beacons 1400 installed on moving objects. The mobile device 1200 is preferably a smartphone, tablet, smartwatch, laptop, or any other computing device. One or more beacons 1300 installed on stationary objects and one or more beacons 1400 installed on 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 range of the beacon signals. This is indicated by zigzag lines between a typical beacon 1300 installed on a stationary object and a typical beacon 1400 installed on a moving object, 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 operating range of at least 1 meter to a maximum of about 50 meters, such as Bluetooth, Bluetooth 4.0, and Bluetooth Low Energy (BLE). The radio signals described herein may be any suitable type of signal, such as a broadcast signal that indicates the presence of a device to nearby devices, a pairing signal that requests automatic pairing with a nearby device, or a connection signal that transmits data to a connected nearby device.

[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 containing a beacon definition table 1101, a beacon signal management table 1102, a passenger status definition table 1103, a passenger status history table 1104, a journey history table 1105, and / or a toll fare table 1106. Furthermore, the server 1100 may include a beacon ID conversion module 1111, a beacon signal recognition module 1112, and a passenger status estimation module 1113. Optionally, as shown in the figure, the server 1100 may further include a journey confirmation module 1114 and / or a toll fare confirmation module 1115.

[0066] Figure 2 shows a schematic example of determining passenger status using a beacon signal including a beacon ID. In the first step S1, the beacon ID conversion module 1111 receives the beacon ID transmitted by the passenger's mobile device 1200, which the mobile device 1200 has previously received from a beacon that emits a beacon signal. The beacon ID conversion module 1111 determines the 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 using a table as shown in Figure 3.

[0067] Subsequently, the received beacon ID and determined attributes are stored in the beacon signal management table 1102 by the beacon ID conversion module 1111, along with a timestamp corresponding to the time the beacon ID was received. In the next step S2, the beacon signal recognition module 1112 determines the signal strength of the received beacon signals based on the total number of received beacon IDs and their attributes. Subsequently, the determined beacon signal strengths of the beacon signals received from beacons installed on stationary objects and beacons received from beacons installed on moving objects are stored in the passenger state definition table 1103. In the next step S3, the passenger state estimation module 1113 determines the passenger's current state based on the moving object beacon signal strength, the stationary object beacon signal strength, and / or 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 previous passenger state, is stored in the passenger state definition table 1103 It will be stored in memory.

[0068] Next, in step S4, the determined passenger's current status is also stored in the passenger status history table 1104, which is added to the series of passenger statuses the passenger has taken during the journey. In the next step S5, the journey confirmation module 1114 can determine the passenger's journey according to the series of previously determined passenger current statuses. Furthermore, in the optional step S6, the fare confirmation module 1115 can determine the fare to be charged for the determined journey.

[0069] Figure 3 shows an example of a beacon definition table 1101 that can be stored in the device 1100, the mobile device 1200, and / or any other suitable location. The beacon definition table 1101 also stores a location ID and attributes corresponding to each beacon ID. The location ID contains information about the location where the beacon is installed. For example, a beacon with beacon ID A1 is installed at station A, which may be a train station or bus station frequently used by public transport such as trains and buses. As a second example, a beacon with beacon ID X1 is installed at train A, which may be part of a public transport system. The attributes indicate whether the beacon is installed on a moving object or a stationary object. In 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 link the beacon ID contained in the beacon signal received from the beacon with the location (where the beacon is installed) and attributes (whether the beacon is installed on a moving object or a stationary object). This allows the beacon signal itself to carry less information, reducing data size while still reliably determining the passenger's location and beacon attributes. The table can be centrally updated so that new / corrected information can be provided simply and without complexity.

[0070] Figure 4 shows an example of a beacon signal management table 1102. In this example, timestamps created according to predetermined time intervals may be stored in the first vertical column of the beacon signal management table 1102. However, the format is only one possible example, and the “table” may be arranged in a different structure. In a predetermined location in the beacon signal management table 1102, a beacon ID received from the passenger’s mobile device 1200 is stored for each stored timestamp. For example, as shown in Figure 4, the predetermined location for storing the received beacon ID may be a vertical column in the beacon signal management table 1102. In this example, the column in which the received beacon ID is stored is determined by the attribute corresponding to the beacon ID. Thus, beacon IDs received from stationary objects may be stored in the first vertical column of the beacon signal management table 1102, and beacon IDs received from moving objects may be stored in the second vertical column of the beacon signal management table 1102.

[0071] In this example, timestamps are created according to a first predetermined time interval of 1 second. After a second predetermined time interval, which may be 10 seconds, has expired, the first timestamp created may be overwritten by a second timestamp created when a new, more recent timestamp is created after the expiration of the second predetermined time interval. In this way, the beacon signal management table 1102 is recursively overwritten according to the second predetermined time interval in accordance with a first-in, first-out policy. This reduces data storage space, among other things. Alternatively, the beacon signal recognition module 1112 may be configured to resume storing the beacon ID and corresponding timestamp in the beacon signal management table 1102 when the contents of the beacon signal management table 1102 have been completely reset after the expiration of the second predetermined time interval.

[0072] After a second predetermined time interval has elapsed, the beacon signal recognition module 1112 determines the beacon signal strength for each beacon ID stored in the beacon signal management table 1102 by constructing the total number of beacon IDs stored in the beacon signal management table 1102. In the example shown in Figure 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 5 times during the illustrated process of beacon signal sampling. Similarly, the beacon signal strength of the beacon with beacon ID X1 is determined to have an absolute value of 3 because X1 was received 3 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 continuous sampling process. The strength values ​​may be stored in other tables (not shown) for tracking changes in the value over time.

[0073] Figure 5 shows an example of passenger state determination performed by the passenger state estimation module 1113. In the illustrated example, passenger state determination is performed based on a scenario table.

[0074] The beacon signal window for determining the beacon signal strength of beacons installed on stationary objects and beacons installed on moving objects may be a 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 first predetermined time intervals within the second predetermined time interval. Predefined passenger states include, but are not limited to, “External,” “Waiting,” “Ready to Board,” “Boarding,” and / or “Disembarking.” The term “External” describes a state in which a passenger is outside a station and a public transport vehicle; the term “Waiting” describes a state in which a passenger is waiting for a public transport vehicle at a station; the term “Ready to Board” describes a state in which a passenger is ready to board at a station; the term “Boarding” describes a state in which a passenger is on a public transport vehicle; and the term “Disembarking” describes a state in which a passenger is disembarking at a station.

[0075] The passenger state definition table 1103 stores the current passenger, determined by the passenger state estimation module 1113, at the intersection of a predefined passenger state and the determination results of mobile beacon signal strength and 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 process prior to passenger state determination. If the device has not performed a previous determination of the current passenger state, the previous passenger state can be assumed to be "external". Furthermore, in this example, the results of the beacon signal strength determination can be classified into a predetermined set of possible results. Possible results may include combinations of mobile and stationary beacon signal strengths represented by values ​​such as 0, 1~max, and half~max. As mentioned above, max represents the maximum value corresponding to the number of first predetermined time intervals within a second predetermined time interval, and 0 represents the minimum value of 0.

[0076] The determination of the current passenger state is explained using a typical case shown in Figure 5. In this case, the previous passenger state was determined to be "external" in the previous determination of the current passenger state, and the combination of beacon signal strengths of moving and stationary beacons is determined by the beacon signal recognition module 1112 after the end of a second predetermined time interval. In particular, the signal strength of beacons installed on moving objects is determined to be 0, and the signal strength of beacons installed on stationary objects is determined to be greater than 1.

[0077] If the previous passenger state was determined to be "external," the condition must be applied that the passenger's mobile device 1200 did not receive a beacon signal. Correspondingly, the signal strength of beacons installed on stationary objects and beacons installed on moving objects must have been determined to be 0 in the previous determination of the passenger state. In order to determine the current passenger state following the previously determined passenger state, the beacon signal strength of each beacon must be determined again by the beacon signal recognition module 1112, as shown in Figure 4. The passenger state estimation module 1113 then 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 result of determining the beacon signal strength.

[0078] In this example, the current passenger state is determined to be "waiting" by the passenger state estimation module 1113. This result is based on the previous passenger state, which was determined to be "outside," and the time-dependent changes in the beacon signal strength of both mobile and stationary beacons acquired in step S10 of passenger state determination. When the beacon signal strength of both beacon types changes from 0 to 0 for mobile beacons and from 1 to max for stationary beacons, the passenger state estimation module 1113 determines in step S11 of passenger state determination that the conditions for the scenario in which the passenger has entered the signal range of at least one beacon installed on a stationary object, such as a bus station or train station, have been met. In other words, in step S12 of passenger state determination, the state estimation module 1113 determines that the passenger's current state is "waiting," which means that the time-dependent increase in the beacon signal strength received from a beacon installed on a stationary object indicates that the passenger has entered a station from the outside to wait for public transport.

[0079] Based on the time-dependent changes in beacon signal strength determined by the beacon signal recognition module 1112, multiple current passenger states can be determined according to previous passenger states.

[0080] Figure 6 shows an example of the passenger state history table 1104. For each passenger state determined by the passenger state estimation module 1113, the start time and end time are also stored. The start time is the first time the passenger state estimation module 1113 determines the passenger's current state, and the end time is the last time the passenger state estimation module 1113 determines the passenger's current state during the passenger journey. By storing the start and end times for each state determined as the current passenger state by the passenger state estimation module 1113, the passenger's journey can be efficiently tracked, and the information can be provided to the passenger to assist / guide them during the journey. Thus, the device 1000 provides the possibility of continuously recording passenger states during the passenger journey. Therefore, the passenger's state can be reproduced at each point in the user's journey. Furthermore, the beacon ID received during the passenger journey allows the device 1000 to determine where the passenger took the recorded state during the journey. Information regarding the passenger's location associated with the passenger ID received by a mobile or stationary beacon can be used to edit the contents of the journey history table, as described later.

[0081] Figure 7 shows an example of a journey history table 1105. The journey history table 1105 stores the start and end stations of a user's journey. The start station is a public transport station, such as a bus station or train station, where the passenger began their journey, and correspondingly, the end station is a public transport station where the passenger ended their journey. The journey confirmation module 1114 stores the start and end stations for each passenger journey in the journey history table. By storing the start and end stations, the total distance traveled by the passenger during their journey can be determined. This can be used in any subsequent step of determining the fare.

[0082] Figure 8 shows an example of a fare table 1106. The fare table stores the starting station of a passenger's journey, the ending station of a passenger's journey, and the corresponding fare that the passenger must pay to use public transport to reach the ending station from the starting station. Depending on the distance between the starting station and the ending station, the fare confirmation module 1115 can determine the fare for each passenger's journey and store it in the fare table 1106. In the illustrated example, the fare for a passenger's journey from station A to station B could be 120 units or subunits of any country's currency.

[0083] In summary, this disclosure provides a reliable device 1000 for determining passenger status, as well as a system, method, and computer program product. Thus, 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 along with corresponding attributes and timestamps in a beacon signal management table, constructing the sum of the number of beacon IDs received from moving objects and stationary objects stored in the beacon signal management table, determining the moving object beacon signal strength of the beacon signals received from beacons installed on moving objects and the stationary object beacon signal strength of the beacon signals received from beacons installed on stationary objects, and determining the passenger's current status based on the moving object beacon signal strength, the stationary object beacon signal strength, and / or previous passenger status.

[0084] This offers the advantage of particularly reliable determination of passenger states, as using beacons to determine passenger states provides an architecture independent of external systems for positioning, making it less susceptible to external detection errors. Furthermore, the continuous sampling of the described beacon signals results in more efficient and reliable tracking of passenger states based on combinations of different types of beacon signals. In addition, the recorded storage of beacon signal IDs and predetermined passenger states enables the provision of a less complex data storage structure and reduces memory usage. Moreover, storing predefined passenger states in a passenger state definition table leads to a reduction in computational effort in passenger state determination, as it results from pre-selecting possible current passenger states according to the aforementioned scenarios.

[0085] As those skilled in the art will understand, this disclosure can be embodied as methods, apparatus (including devices, machines, systems, computer program products, and / or any other apparatus), or combinations thereof, as described above and in the accompanying drawings.

[0086] Accordingly, embodiments of the present disclosure may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects that may be commonly referred to herein as “systems.” Furthermore, embodiments of the present disclosure may take the form of computer program products on computer-readable media having computer executable program code embedded in the medium.

[0087] It should be noted that arrows may be used in drawings to represent communication, transfer, or other activities involving two or more entities. A double-headed 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, or peer-to-peer communication initiated by either entity), although in some situations, activity may not necessarily occur in both directions.

[0088] While one-way arrows can generally indicate exclusively or primarily one-way activity, it should be noted that in certain situations, 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 forwarding and the termination of a connection after forwarding). Therefore, the type of arrow used in a particular drawing to represent a specific activity is illustrative and should not be considered limiting.

[0089] The embodiments have been described above in relation to flowcharts and / or block diagrams of the method and apparatus, and in relation to several sample views of the graphical user interface generated by the method and / or apparatus. It can be understood that each block in the flowchart and / or block diagram, and / or combinations of blocks in the flowchart and / or block diagram, and the graphical user interface can be implemented by computer executable program code.

[0090] Computer executable program code may be provided to a processor of a general-purpose computer, a dedicated computer, or other programmable data processing device for manufacturing a particular machine, and as a result, program code executed via the processor of the computer or other programmable data processing device creates means for performing functions / operations / outputs specified in flowcharts, block diagrams, or a series of blocks, diagrams, and / or described descriptions.

[0091] These computer-executable program codes may also be stored in computer-readable memory that can instruct a computer or other programmable data processing device to function in a particular way, and as a result, the program code stored in computer-readable memory may produce a product that includes instruction means to perform functions / operations / outputs specified in flowcharts, block diagram blocks, figures, and / or descriptions.

[0092] Computer-executable program code can also be loaded into a computer or other programmable data processing device to trigger a series of operational steps executed on the computer or other programmable device, generating a computer implementation process such that the program code executed on the computer or other programmable device provides steps for implementing functions / operations / outputs specified in the flowchart, block diagram blocks, figures, and / or specification. Alternatively, the computer program implementation steps or operations may be combined with steps or operations performed by an operator or human to execute the embodiment.

[0093] Terms such as “server” and “processor” may be used herein to describe devices that may be used in particular embodiments, and should not be construed as limiting to any particular type of device unless otherwise required in the context. Thus, a device may include, but is not limited to, a bridge, router, bridge router (router), switch, node, server, computer, equipment, or other types of devices. Such a device generally includes one or more network interfaces for communicating over a communication network and a processor configured accordingly to perform device functions (e.g., a microprocessor with memory and other peripherals and / or application-specific hardware).

[0094] Communication networks may generally include public and / or private networks, and may include, but are not limited to, local area, wide area, metropolitan area, storage, and / or other types of networks, and may utilize communication technologies including analog technology, digital technology, optical technology, wireless technology (e.g., Bluetooth), networking technology, and internetworking technology.

[0095] It should also be noted that the device may use communication protocols and messages (e.g., messages created, transmitted, received, stored, and / or processed by the device), and such messages may be transmitted by communication networks or media.

[0096] Unless the context requires otherwise, this disclosure should not be construed as being limited to any particular communication message type, communication message format, or communication protocol. Therefore, communication messages may, in general, include, but are not limited to, frames, packets, data crams, user data crams, cells, or other types of communication messages.

[0097] Unless the context requires otherwise, references to specific communication protocols are illustrative, and it should be understood that alternative embodiments may, if necessary, use variations of such communication protocols (e.g., modifications or extensions to protocols that may be made from time to time) or other protocols that may be known or developed in the future.

[0098] Logical flows may be described herein to demonstrate various aspects, and it should be noted that this disclosure should not be construed as limiting it to any particular logical flow or logical implementation. The described logic may be divided into different logical blocks (e.g., programs, modules, functions, or subroutines) without altering the overall result.

[0099] In many cases, logical elements can be added, modified, omitted, executed in a different order, or implemented using different logical structures (e.g., logic gates, looping primitives, conditional logic, and other logical structures) without changing the overall result.

[0100] This disclosure is not limited to, but may be implemented in many different forms, including 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), individual components, integrated circuits (e.g., application-specific integrated circuits (ASICs)), or any other means including any combination thereof. Computer program logic that implements some or all of the described functions is typically translated into a computer-executable form, stored in a computer-readable medium, and implemented as a set of computer program instructions executed by a microprocessor under the control of an operating system. Hardware-based logic that implements some or all of the described functions may be implemented using one or more appropriately configured FPGAs.

[0101] Computer program logic that implements all or part of the functions described herein may be embodied in a variety of forms, including but not limited to source code, computer executable, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator).

[0102] The source code may include a set of computer program instructions implemented in one of several programming languages ​​(e.g., object code, assembly language, or high-level languages ​​such as Fortran, C, C++, Java, or HTML) for use in various operating systems or environments. The source code may define and use various data structures and communication messages. The source code may be in computer executable format (e.g., via an interpreter), or the source code may be converted into computer executable format (e.g., via a translator, assembler, or compiler).

[0103] Computer executable program code for performing the operations of the embodiments of this disclosure may be written in an object-oriented, scripting, or non-scripting programming language such as Java, Perl, Smalltalk, or C++. However, computer executable program code for performing the operations of the embodiments may also be written in a conventional procedural programming language such as the C programming language or a similar programming language.

[0104] Computer program logic that implements all or part of the functions described herein may run on a single processor (e.g., simultaneously) at different times, or on multiple processors at the same or different times, under a single operating system process / thread, or under different operating system processes / threads.

[0105] Therefore, the term "computer process" can generally refer to the execution of a set of computer program instructions, regardless of whether different computer processes run on the same or different processors, and regardless of whether different computer processes run under the same operating system process / thread or different operating system processes / threads.

[0106] Computer programs may be permanently or temporarily fixed in any form (e.g., source code, computer executable, or intermediate) to tangible storage media such as semiconductor memory devices (e.g., RAM, ROM, PROM, EEPROM, or flash programmable RAM), magnetic memory devices (e.g., diskettes or fixed disks), optical memory devices (e.g., CD-ROMs), PC cards (e.g., PCMCIA cards), or other memory devices.

[0107] A computer program may be fixed in any form of a signal that can be transmitted to a computer using any of a variety of communication technologies, including but not limited to analog technology, digital technology, optical technology, wireless technology (e.g., Bluetooth), networking technology, and internetworking technology.

[0108] Computer programs may be distributed in any form as removable storage media with accompanying printed or electronic documentation (e.g., shrink-wrapped software), pre-loaded onto a computer system (e.g., on a system ROM or fixed disk), or distributed from a server or electronic bulletin board via a communication system (e.g., the Internet or the World Wide Web).

[0109] Hardware logic (including programmable logic for use in programmable logic devices) that implements all or part of the functions described herein may be designed using conventional manual methods, or may be designed, captured, simulated, or documented electronically using various 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 can be used. This computer-readable medium may, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or media.

[0111] More specific examples of computer-readable media include, but are not limited to, electrical connections having one or more wires, or other tangible storage media such as portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), compact disk read-only memory (CD-ROM), or other optical or magnetic storage devices.

[0112] The programmable logic may be permanently or temporarily fixed to 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] Programmable logic may be fixed to a signal that can be transmitted to a computer using any of a variety of communication technologies, including but not limited to analog technology, digital technology, optical technology, wireless technology (e.g., Bluetooth), networking technology, and internetworking technology.

[0114] The programmable logic may be distributed as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink-wrapped software), pre-loaded onto a computer system (e.g., on a system ROM or fixed disk), or distributed from a server or electronic bulletin board via a communication system (e.g., the Internet or the World Wide Web). Of course, some embodiments 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 specific exemplary embodiments have been described and illustrated in the accompanying drawings, it should be understood that such embodiments are illustrative and not limited to the specific structures and arrangements shown and described, as various other modifications, combinations, omissions, alterations, and substitutions are possible in addition to those described in the paragraphs above.

[0116] As those skilled in the art will see, various adaptations, modifications, and / or combinations of the embodiments described above can be made. Therefore, it should be understood that within the scope of the appended claims, this disclosure may be implemented in ways other than those 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, separated, or performed simultaneously.

[0117] Furthermore, as those skilled in the art will see, other embodiments can be formed by combining different embodiments or aspects described herein, taking into consideration this disclosure.

Claims

1. A device for determining passenger status, configured to receive a beacon signal from a passenger's mobile device, the mobile device including a beacon ID received from a beacon, It includes a data storage unit configured to store information in a beacon definition table, a beacon signal management table, and a passenger status definition table. The beacon definition table is configured to store a beacon ID, a location ID indicating the beacon's location, and an attribute indicating whether the beacon is installed on a moving object or a stationary object. The beacon signal management table is configured to store the beacon ID and timestamp of each beacon signal received from the mobile device. The passenger status definition table is configured to store information about previous or current passenger status and beacon signal strength, and the device is configured to store information about previous or current passenger status and beacon signal strength. A beacon ID conversion module is configured to read the location ID and attributes of the received beacon signal from the beacon definition table and to write the beacon ID and the timestamp of the reception of the beacon signal to the beacon signal management table. A beacon signal recognition module configured to determine the mobile object beacon signal strength of a beacon signal received from a beacon installed on a moving object and the stationary object beacon signal strength of a beacon signal received from a beacon installed on a stationary object, wherein the beacon signal strength is the sum of the number of beacon IDs stored in the beacon signal management table. A passenger state estimation module configured to determine the current passenger state based on the moving object beacon signal strength, the stationary object beacon signal strength, and previous passenger states, Furthermore, The passenger state estimation module is further configured to store in the passenger state history table included in the data storage unit a start time, which is the first time the passenger state estimation module first determines the current passenger state, and an end time, which is the time the passenger state estimation module determines the current passenger state for the last time during the passenger journey, in association with the current passenger state. A journey confirmation module is configured to store the starting station as the place where the passenger begins their journey and the ending station as the place where the passenger ends their journey, based on the passenger status stored in the passenger status history table, within the journey history table included in the data storage unit. An apparatus comprising a transportation fare table included in the data storage unit, and a transportation fare confirmation module that determines the fare to be charged for a journey based on the journey of a passenger stored in the journey history table.

2. The apparatus according to claim 1, wherein the passenger state estimation module is configured to determine the current state of the 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 signal strength over time, and / or the previous passenger state.

3. The passenger state estimation module 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. The apparatus according to claim 1 or 2.

4. The plurality of predefined passenger states are defined in the passenger state definition table 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 signal strength, the change in the moving object beacon signal strength over time, the change in the stationary object beacon signal strength over time, and / or the previous passenger states. The apparatus according to claim 3.

5. The multiple predefined passenger states stored in the passenger state definition table include "outside", "waiting", "ready to board", and "on board". The apparatus according to claim 3 or 4.

6. The beacon signal recognition module is configured to determine the strength of a moving object beacon signal by counting the number of beacon IDs of beacon signals received from a moving object stored in the beacon signal management table, and to determine the strength of a stationary object beacon signal by counting the number of beacon IDs of beacon signals received from a stationary object stored in the beacon signal management table. The apparatus according to any one of claims 1 to 5.

7. The beacon signal management table stores each beacon ID in a manner that distinguishes between beacon IDs from stationary objects and beacon IDs from moving objects. The apparatus according to any one of claims 1 to 6.

8. The beacon ID conversion module is configured to periodically sample the received beacon signal and to write the beacon ID and the reception timestamp to the beacon signal management table at a first predetermined time interval. The apparatus according to any one of claims 1 to 7.

9. The beacon signal recognition module is configured to determine the beacon signal strength after the expiration of a second predetermined time interval which is equal to or greater than the first predetermined time interval. The apparatus according to claim 8.

10. The beacon signal recognition module is configured to reset the beacon signal management table after the expiration of the second predetermined time interval. The apparatus according to claim 9.

11. The beacon signal recognition module is configured to reset the beacon signal management table by overwriting the beacon ID and timestamp previously stored in the beacon signal management table. The 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 the number of first predetermined time intervals within the second predetermined time interval. The apparatus according to claim 9.

13. The apparatus according to claim 7, wherein the beacon signal recognition module is configured to store the beacon ID of each beacon signal received from the mobile device in a predetermined storage location in the beacon signal management table according to the attribute corresponding to the beacon ID.

14. A system comprising the apparatus according to any one of claims 1 to 13, a passenger mobile device equipped with a beacon signal detector, a beacon installed on a stationary object configured to transmit a beacon signal including a beacon ID, and a beacon installed on a moving object configured to transmit a beacon signal including a beacon ID.

15. A method for determining the status of a passenger, The steps include receiving a beacon signal from a mobile device, which includes a beacon ID received by the mobile device from a beacon, The steps include reading a location ID and an attribute corresponding to the beacon ID that indicates whether the beacon is installed on a moving object or a stationary object from a storage unit, The steps include determining the beacon signal strength by constructing the sum of beacon IDs received from beacons installed on moving or stationary objects during a predetermined time interval, The steps include storing the beacon signal strength in the storage unit for each beacon signal received from a beacon installed on a moving or stationary object during the predetermined time interval, The steps include determining the current passenger status based on the beacon signal strength and previous passenger status, Includes, The determination includes the step of storing in the passenger state history table included in the storage unit the start time, which is the first time when the current passenger state is determined for the first time, and the end time, which is the time when the current passenger state is determined for the last time during the passenger journey, in association with the current passenger state. Based on the current passenger status, the steps include: storing the starting station as the place where the passenger begins their journey, and storing the ending station as the place where the passenger ends their journey; A step of determining the fare to be charged for the passenger's journey based on the stored starting station and ending station of the journey, A method that includes this.

16. A computer program that can be stored in memory, which includes instructions that cause the computer to perform the method described in claim 15 when executed by the computer.

Images