Itinerary generation device, itinerary generation system, itinerary generation method, and computer program product

Abstract

To provide a device and a system for improving reliability of generation / return of an itinerary by which a moving body, especially a person using a mobile computing device, has moved.SOLUTION: A device 1100 for generating an itinerary by which a moving body has moved includes: an input unit for receiving a plurality of position information data from a mobile computer 1200 of the moving body; an itinerary generation unit for generating itinerary history data including a plurality of itinerary subsection information data; and an output unit for outputting at least one itinerary of the mobile body based on the itinerary subsection information data or a weight value relative to the mobile computer 1200.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The subject matter of the present invention relates in particular to an apparatus and a system for improving the reliability of generating / reversing the journey traveled by a person using a moving body, in particular a mobile computing device. Corresponding methods and computer program products are also provided. The reliability is improved in particular by an improved architecture of the apparatus and system which can reduce data traffic, improve configuration flexibility, provide weighted selection output, and in particular enable fail-safe determination of the journey by hardware. Further aspects contributing to a synergistic improvement in reliability will become apparent from the following.

Background Art

[0002] Prior art such as US9996831B2 describes a journey generation system that also enables automatic calculation of journey fares. The system uses wireless transceivers installed at the entrances and exits of vehicles such as trains and buses. The entrance transceiver wirelessly receives data indicating that a particular person has entered from the passenger's mobile computing device when the passenger boards the vehicle. The exit transceiver receives data from the mobile computing device when the passenger leaves the vehicle in which they are traveling. The entrance and exit transceivers transmit the data to a server, which uses the transmitted data to determine the passenger's journey based on the entrance and exit data from the vehicle's transceivers. The reliability of such a system can be affected, for example, if the transceiver fails or the communication between the mobile computing device, the transceiver, and / or the server is interrupted.

Summary of the Invention

[0003] The technical objective is to provide a more reliable apparatus and system configured to determine the journey traveled by a moving body, as well as corresponding methods and computer program products.

[0004] According to the subject matter described in the attached claims, a device is proposed for generating a travel history of a moving object, such as a person or a user of a mobile computing device. The device is preferably located in or may be a remote server, where “remote” may mean that the server is located away from the moving object or mobile computing device (mobile computer). The mobile computing device or mobile computer may be a smartphone, tablet, laptop, smartwatch, etc.

[0005] The device may include an input unit configured to receive location information, particularly location data, which may include data relating to the location of a mobile computer and the time spent at each location. In other words, location data may include timestamps. Multiple location data received during the journey of the mobile object may be recorded in a database, preferably stored in the device. The database may have data structures such as arrays or tables, where location information may be recorded as data entries. The entirety of location data may hereafter be referred to as "location history data."

[0006] The device may further include a journey network database. The database preferably includes a data structure, such as a table, array, or any equivalent data structure into which data values ​​are entered. The database may also include weight information, such as weight values ​​or data relating to weights. Preferably, weight values ​​are preset for each of a plurality of predetermined journey subsections stored in the journey network database. As described above, depending on the number of subsections, for example, the subsections may, when combined, result in a journey, or a single subsection may constitute a journey.

[0007] Furthermore, the itinerary generation unit of the device may be configured to generate itinerary history data that includes multiple itinerary subsection information data. The above data may also preferably be stored in a data structure such as an array or a table, and each itinerary subsection information data includes the start and end positions of the itinerary subsection determined based on the location history data, as well as estimates determined based on weight values ​​from the itinerary network database. The itinerary subsection information data may be divided into entities of itinerary subsection information data as a whole, thereby specifying one particular entity when referring to a “single” or “each” itinerary subsection information data. In other words, each itinerary subsection information data comprises a (predefined) set of values, or, to put it another way, a list of values ​​of a predefined type, such as the “start position,” “end position,” etc., of the type described above.

[0008] Furthermore, the device may include an output unit configured to output at least one itinerary based on itinerary subsection information of itinerary history data and based on weight values ​​for a mobile computer. The expression "based on..." shall in particular include "selected for output based on...". The input unit may be combined with the output unit or may be a separate unit.

[0009] Furthermore, the term "itinerary" may be understood to encompass "travel route" or "transportation route." Also, the term "subsection" may be understood to mean "link," as is also used below. As mentioned above, an itinerary may include one or more subsections. In particular, and for example, if an itinerary has exactly one subsection, a single subsection may be an itinerary. In other words, each subsection may be an itinerary, or may be output as an itinerary. Similarly, multiple itineraries may be output. Particularly preferably, the output of an output unit may include one or more subsections of an itinerary, which may be combined to produce a complete / whole itinerary / travel / route of a movement.

[0010] The aforementioned device is designed to generate, or in other words, reconstruct / replay / reverse the journey of a moving object. The moving object may preferably be a person. Technically beneficial, and particularly in terms of reliability, the device may communicate wirelessly directly with the mobile computer of the moving object, from which the data used to generate the journey is received. There is no need to have inlet and outlet transceivers in the communication path, which may malfunction. Furthermore, this improves the security of data transmission.

[0011] In addition, weight values ​​are used to determine the itinerary(s) output to the mobile computing device, making the output to the mobile computing device user more reliable. This also helps avoid outputting unrealistic or inappropriate itineraries, which reduces data traffic. Regarding the latter, in other words, only the most realistic and reliably determined itineraries are sent from the device to the mobile computer, thus reducing data traffic.

[0012] Furthermore, preferably, each location data may include an identifier for the mobile computer, the location of the mobile computer, and information / data regarding the time the mobile computer is at the above location. The information / data regarding the location of the mobile computer and the time it is at that location may be generated based on a signal transmitted wirelessly to the mobile computer from a transmitting node located at the above location. The transmitting node may hereafter be referred to as a "beacon" or "transmitting node." The transmitting node preferably transmits data unidirectionally to the mobile computer. Furthermore, the transmitting node may have an encryption function and encrypt at least a portion of the data transmitted to the mobile computer by such function. Here, the decryption function can be managed both locally on the mobile computer and in a database, and the device enables the mobile computer to transmit the data provided by the transmitting node, but with the possibility of tampering dramatically reduced.

[0013] Since location data requires only a minimal data size to be transmitted from a mobile computer in a moving object to the device, the reliability of the device is further improved. This reduces data traffic and / or data transmission time, and therefore improves the reliability that data can be received at the device at any time. Furthermore, in addition to the aforementioned technical advantages of the mobile computing device communicating with each of the claimed devices or their input units (especially when wireless / wired network transmission and its subcomponents are not taken into consideration), it should be noted that the beacon communicates unidirectionally with the mobile computing device in a moving object. Therefore, preferably, only one unidirectional communication path is required, which is the path between the mobile computing device and the device.

[0014] Furthermore, preferably, the itinerary generation unit may be configured to select the first location information (data) with the shortest time from the location history data (which may be a structure such as a table), select the location of the first location information (data) as the start location ("start point"), then select a second location information (data) with a short time and a different location from the assumed (set) start location from the location history data, set the location of the second location information (data) as the end location, and store the start location and the end location as part of the itinerary subsection information data of the itinerary history data. "Part of" information / data means that the itinerary history data may include additional information or data which may be added as different routines / units. The above may be carried out in a loop until all entries / records of the location history data have been processed, which may mean that after the start and end locations have been determined, a "new" first location is selected as the "new" start location, and so on thereafter. Each itinerary subsection information data is preferably generated by one loop. In other words, preferably, one entry containing a set of itinerary subsection information data is generated by one loop, and the next entry is generated by the next loop.

[0015] The above synergistically increases the improved reliability of the device, and the loop may be performed until a “different” location, i.e., one different from the starting location, is detected in the location history data. Most preferably, the location history data includes data that begins at the earliest recorded time and is ordered according to the time indicated by the timestamp. Thus, the end location can be determined efficiently in terms of computational complexity and reliably in terms of avoiding improperly chosen start or end locations. Such combined journey history data is preferably stored in the form of a table, array structure, or the like.

[0016] Furthermore, preferably, the device may include a travel estimation unit configured to generate additional travel history data, which includes one or more alternative travel subsection information data (or sets / entries thereof) that are alternative information to the travel subsection information generated by the travel generation unit, based on information from a travel network database. Preferably, the alternative travel subsection information data is generated for travel subsection information data (or entries / sets thereof) in the travel history data generated by the travel generation unit that have estimates lower than a predetermined threshold. In other words, the device may check the travel subsection information data created by the travel generation unit against their estimates, and the travel estimation unit may provide only alternative entries, i.e., alternative travel subsection information data, preferably those with estimates lower than a preset threshold. The threshold may be stored in the device's storage and may be set when the device is started up.

[0017] The above synergistically increases the improved reliability of the device by adding an additional unit that allows for the addition of further subsections to the mobile object's journey, making the device fail-safe, particularly against communication malfunctions, mobile device malfunctions, or beacon malfunctions. More specifically, the journey generation unit determines information about subsections based on actually transmitted location information, i.e., data actually transmitted from the mobile computing device, while the journey estimation unit may determine further / alternative subsections that are not (not) (directly) based on transmitted location information. For example, travel from the start to the end position may be possible by different vehicles or through different / additional subsections, and if, for example, some location information is not properly transmitted to the device while traveling through a subsection, an incorrect journey may be determined if only the actually received location information is considered by the journey generation unit. However, the journey estimation unit can take into account further possible alternative subsections and / or journeys between the start and end positions, which may be properly determined without malfunctions such as those of the sender node. Therefore, among multiple options, it is possible to select the most appropriate or most likely appropriate subsection based on the weight values ​​assigned to each itinerary subsection information data. The computational complexity may be further reduced by using estimates and comparing them to predefined thresholds, so that the itinerary estimation unit only begins working when the estimate of a particular itinerary subsection information data is below the threshold.

[0018] Furthermore, preferably, the itinerary network database may comprise a plurality of predetermined itinerary subsections, each containing a start position, an end position, and weight information / values. The itinerary generation unit may also be configured to select weight information from the itinerary network database for itinerary subsection information data whose start and end positions coincide with the start and end positions of predetermined itinerary subsections in the itinerary network database. Preferably, the estimated values ​​of the itinerary subsection information data may be set to be the same as the selected weight information. This enables efficient and reliable determination of weight information and estimates.

[0019] Furthermore, preferably, the itinerary estimation unit may be configured to add alternative itinerary subsection information data to the itinerary history data by selecting one or more predetermined itinerary subsections from the itinerary network database that have estimates lower than a predetermined threshold for the itinerary network database, and whose at least start or end positions coincide with each other, and if the weight of the alternative itinerary subsection is greater than or equal to the threshold. The threshold may preferably be the same as the threshold described above.

[0020] As described above, the reliability of the device in terms of failure-safety, such as preventing malfunctions, can be improved by providing a travel estimation unit that can add alternative travel subsection information data to travel history data selected specifically based on the threshold comparison described, in accordance with the preferred embodiment described immediately prior to this. The strategy using threshold comparison reduces the number of alternative selections, thus reducing computational complexity in addition to improving reliability. Furthermore, by adding additional possible subsections / travels, it becomes possible to offset malfunctions related to inappropriate / incomplete / non-existent data transmission to the device.

[0021] Furthermore, preferably, in addition to improving reliability, the itinerary generation unit and / or itinerary estimation unit may be configured to add property information to the itinerary subsection information data, in particular the itinerary generation unit may set "actual" as the property data, while the itinerary estimation unit may set "assumption" as the property data. This helps to identify / separate the itinerary subsection information with high reliability based on directly transmitted information / data and on the addition of alternatives provided by the itinerary estimation unit. Furthermore, the output unit may therefore be configured to output the itinerary subsection information from the itinerary history data as "confirmed itinerary" or "alternative itinerary". The alternative itinerary output may be itinerary subsection information (or multiple itinerary subsection information) including alternatives to the itinerary subsection information of itinerary history data having the same start and / or end positions.

[0022] Furthermore, preferably, the output unit may be configured to output at least one itinerary subsection information data from the itinerary history data as a proposed itinerary to the mobile computer, and the input unit may be configured to receive feedback information / data from the mobile computer regarding (mobile) agreement on the proposed itinerary. If the feedback includes agreement, the weights in the itinerary network data may be increased for certain itinerary subsections that match the proposed itinerary, and decreased otherwise. The feedback improves the reliability and accuracy of the device's output over time, i.e., allows it to learn optimal weight values ​​over time, since the weight values ​​stored in the device's database or at any other location can become more accurate over time. The device may preferably further include a database with individual weight values ​​for different users so that learning can be personalized.

[0023] Furthermore, preferably, the alarm unit may be configured to verify feedback information for proposed itineraries for which agreement has not been received, and to increase the weight of a given itinerary subsection that matches the proposed itinerary if the verification determines that the agreement is appropriate. This helps to reliably identify and ignore false feedback.

[0024] Furthermore, preferably, the weight values ​​may be modified / updated / changed based on different factors, parameters, or circumstances. For example, they may be based on the distance between the start and end positions, for instance, longer distances may result in a lower weight for direct connections between the two positions on foot or by bicycle if commuting between the two positions is by bus or train. Additionally, the weights may take into account other circumstances such as the number and types of travel options between the start and end positions, weather, and technical malfunctions of the public transport system reported to the device. For example, even if a bus connection exists, a bicycle may be more likely to be used for shorter distances between the two positions. This would mean that the weight for a bus connection would be lower than that for a direct connection by bicycle. However, on rainy or cold days, a bus may be more likely to be chosen instead of a bicycle. Therefore, the weight for bus connections would be updated to be higher. The weights may be stored in a database of the device, a mobile computing device connected to the device, or any other device. Updates may be performed at regular intervals or triggered by external circumstances, such as changes in weather.

[0025] Furthermore, the device may also include a fare database and a fare calculation unit configured to calculate fares for each itinerary subsection in the itinerary history data based on the information in the fare database. The device may then output the itinerary and fare for each itinerary output.

[0026] In addition, a system may be provided that includes an apparatus according to at least one of the above-described aspects, a mobile computer, and a plurality of transmitter nodes disposed along a travel route and / or within a vehicle, the transmitter nodes having a predefined transmission range for transmitting data, such as position and time information, to the mobile computer of the mobile object within its range. The transmitter nodes preferably transmit data only unidirectionally to the mobile computing device / mobile computer, which may communicate bidirectionally with the apparatus. This system architecture is particularly fail-safe, and thus highly reliable, data-protective, and generally reduces data traffic.

[0027] Furthermore, a method for generating a travel history of a mobile object that has moved is claimed. The method includes receiving position information data including information on the position of the mobile computer and the time at the above position from the mobile computer of the mobile object, and storing the plurality of position information data as position history data, and generating travel history data including a plurality of travel sub-section information data, each travel sub-section information data including a start position and an end position of a sub-section of the travel determined based on the position history data and an estimated value determined based on weight information from a travel network database, and outputting at least one travel based on the travel sub-section information data of the travel history data and also based on weight information for the mobile computer.

[0028] In addition, the above method may further include additional steps based on the configuration of the preferred embodiments described above in relation to the claimed apparatus. For example, steps of adding journey sub-section information by using location information, adding alternative journey sub-section information and / or properties thereof, and steps of proposing a journey, adapting weight information based on feedback from the user or based on external conditions such as weather, etc. Also, the claimed method may further include a fare calculation step. In other words, each configuration of the claimed apparatus shall also be included as a method that may itself be claimed, and / or as a computer program product claim.

[0029] Generally, solutions are provided that offer technical benefits, particularly with regard to the reliability of automatic journey generation.

[0030] Hereinafter, the claimed subject matter will be further described based on at least one preferred embodiment with reference to the accompanying drawings.

Brief Description of the Drawings

[0031] [Figure 1] FIG. 1 is a schematic diagram showing an example of a system for using an apparatus to generate a journey. [Figure 2] FIG. 2 is a diagram showing an example of a setup of an apparatus and a mobile computer communicating with each other via a data connection. [Figure 3] FIG. 3 is a diagram showing an example of a table containing position conversion data. [Figure 4] FIG. 4 is a diagram showing an example of a table containing location information data. [Figure 5] FIG. 5 is a schematic example showing a mobile route including links / sub-sections and nodes. [Figure 6] FIG. 6 shows an example of a table containing a predetermined journey sub-section (FIG. 6aa) and an example of a table containing journey history data (FIG. 6a). [Figure 7] This figure shows an example of a table containing fare values ​​(Figure 67a) and an example of the output of an output unit displayed on a mobile computer (Figure 7b). [Figure 8] This flowchart shows an example of steps that can be performed by the itinerary estimation unit. [Figure 9] This flowchart shows an example of steps that can be performed by the itinerary generation unit. [Figure 10] A flowchart shows an example of steps that can be performed by the output unit. [Figure 11] A flowchart shows an example of steps that can be performed by the itinerary network update unit. [Figure 12] A flowchart shows an example of steps that can be performed by the alarm unit. [Modes for carrying out the invention]

[0032] Figure 1 shows a very schematic overview of the claimed system 1000, with three locations indicated as “Stop A,” “Stop B,” and “Stop C.” A vehicle such as a bus traveling between the stops is shown, and the distances between stops A and B, and between stops B and C are indicated. Here, the first mentioned distance is 0.5 miles (0.8 km), and the second mentioned distance is 2.5 miles (4.0 km). The distance values ​​are merely examples and can be quite different. Each stop and bus has at least one originating node N, for which the terms “originating node” or “beacon” may also be used below. The mobile computing device / mobile computer 1200 is moving with the mobile body. The term “mobile body” refers, for example, to a person in motion, or the user of the mobile computer 1200 in motion. It is assumed that the user of the mobile computer 1200 carries the mobile computer 1200 while traveling along stop A to stop C. The stops do not necessarily have to be linked to actual bus stops. While traveling, the mobile computer 1200, in particular the mobile computer program (or “application program,” or simply “app” or “mobile app”), is configured to receive data transmitted to the mobile computer 1200 from a caller node N. The received data originates from a node that is within the transmission range of the caller node N. The preferred transmission range of the caller node N may be a few meters or less than one meter. The relatively short transmission range ensures that overlap between different caller nodes N can be avoided or reduced. Because the transmission range is preferably relatively short, it may be necessary to provide more than one caller node N in a space larger than the transmission range, such as the bus shown in Figure 1, in order to ensure complete coverage. As soon as the mobile computer 1200 of the moving object enters the transmission range, timestamped location data, referred to as location information data 3001~300n, is transmitted from the sender node N to the mobile computer 1200.Location data 3001-300n may include information about the location of the mobile computer / sender node N and the time the data was transmitted to the mobile computer 1200. The received location data 3001-300n may be temporarily stored in the mobile computer 1200, or it may be sent directly to a remote server, which is or includes the server / device 1100. A combination of both options, i.e., transmitted immediately or stored and transmitted after a set time, can also be provided. In this example, the mobile body and mobile computer 1200 travel along a route from stop A to stop C, but the mobile computer 1200 sends different sender nodes N and therefore (consequently) receives location data 3001-300n from them. This continues until the (hypothetical) final stop is reached. If the data is not transmitted directly as described above, a more preferred option is to transmit the data from the mobile computer 1200 to the device 1100 on a remote server after the completion of the travel / journey. The completion of the journey may be indicated, for example, by the mobile unit entering a specific command into the mobile computer 1200 or into a related computer program running on the mobile computer 1200. The final destination of the journey may also be made known to the mobile computer 1200, for example, by being entered by the user, and therefore a command indicating the completion of the journey is unnecessary.

[0033] The following diagrams will provide a more detailed examination of the specific processing of the location information data 3001-300n received by the device 1100.

[0034] Figure 2 shows a schematic configuration of the device 1100 and the mobile computer 1200. The device 1100 may be a (remote) computing device, for example, a server, or a computing device on a server. Figure 2 shows several different subunits and data storage units (one or more) (including databases, etc.) of the mobile computer 1200 and the device 1100, but note that some of these discussed below in further description of the drawings may be optional.

[0035] Figure 2 shows that the mobile computer 1200 and the device 1100 are connected via a data connection (indicated in Figure 2 by a zigzag line between the two devices), which is preferably bidirectional and wireless. Preferred options for configuring the wireless data connection between the two entities / devices can include all relevant wireless data transmission protocols. One particular preferred option is a connection via the Internet. The mobile computer 1200 includes a graphical user interface 1221 for displaying relevant information to a mobile entity, e.g., a user of the mobile computer 1200. Furthermore, it includes one or more internal and / or external storage units 1201 for storing location translation data in a database, preferably structured as a table or array, etc. Furthermore, the mobile computer 1200 may include a location sensing unit 1211 and a location translation unit 1212. The mobile computer 1200 is preferably a smartphone, tablet, smartwatch, laptop, or any other portable computing device. Some of the above-described units of the mobile computer 1200, such as the position conversion unit 1212, may be implemented as computer program products and / or as a combination of hardware and software. The position sensing unit 1211 may include, for example, a hardware sensor and a software program for processing data from the sensor.

[0036] Furthermore, with respect to Figure 1, it was explained that the caller node N transmits location data 3001-300n to the mobile computer 1200. In the preferred embodiment described above, as considered with respect to Figure 1, the location sensing unit, as well as the location transformation units 1211 and 1212 and the location transformation data 1201, are not essential, as the data can be provided by the caller node N after being calculated internally. However, in a different preferred embodiment, the above units reside within the mobile computer 1200, in which case the caller node N simply transmits caller-specific call signs such as A1, A2, X1, ..., C1, C2, etc., to the mobile computer 1200. The mobile computer 1200 then uses the location transformation unit 1212 to link the call signs submitted by the caller node N to locations such as Station A, boarding a bus, Station C, etc. Furthermore, the location sensing unit 1211 may identify coordinates as needed, and the mobile computer 1200 may add a timestamp at the moment it receives data from the caller node N. Regardless of the preferred embodiments described above, location data 3001-300n are transmitted to an input unit of the device 1100 (the input unit is combined with an output unit in this example), and the received location data 3001-300n are stored in the respective storage areas of the device 1100 as location history data 1102. In particular, they may be stored in a database or the like, which may be structured as a table or any other type of data format. Preferably, the transmission from the mobile computer 1200 to the device 1100 further includes an identifier ID of the mobile computer 1200 and / or the user of the mobile computer 1200. The identifier may be added to the location data 3001-300n.

[0037] Figures 3 and 4 show an example of the data structure of the location transformation data 1201, from which it is clear that each line identifies a different sensor / transmitter node N listed in the first column, and the corresponding location is listed in the second column. Each line indicated by reference numerals 2001-2008 represents a single location transformation information (data), or in other words, a set thereof. The same applies to an example of a table containing location history data 1102, as shown in Figure 4. Each location information data 3001-3007 shown contains the identified user ID, location, and a value for the time at that location. For example, location information data 3002 indicates that the user with identifier "ID1" was at station A at 10:00:30 AM. As shown in location information 3006, the same user was at station C at 10:13:00 AM.

[0038] Returning to Figure 2, a data storage area for account data 1101 is also shown, which contains data about each user and associates user IDs with specific users. The data for each use may include information such as home address, credit card information, and banking information. Transmissions coming into device 1100 from different mobile computers 1200 can be assigned to the appropriate person by using identifier / user ID information. Furthermore, the storage area of ​​device 1100 may also include a database of itinerary network data, which may also be ordered in the form of arrays, tables, or any other preferred data format.

[0039] Figure 5 schematically visualizes an example of data stored in the itinerary network database, as described below. However, it should be noted that this is merely an example, and the itinerary network database may include more complex route data, predefined and stored in the device 1100. Furthermore, it should be noted that the device 1100 may include pre-stored data. However, the data can be updated / corrected at any time as needed. To make it clear, Figure 5 represents the data using nodes and links. Nodes correspond to the aforementioned stations / stops, or other points along the travel route of a moving object. In this example, specifically, the nodes include those for stations A-C and the transport vehicles connecting stops A-C. Furthermore, the example shows subsections / links between nodes. Nodes corresponding to transport vehicles are indicated as "boarding". Nodes may, in particular, indicate the location where a passenger boards and / or alights from a transport vehicle, as well as the location where a passenger is currently on board a vehicle / transport vehicle. Links preferably represent transport routes connecting locations, sometimes referred to as "subsections of the itinerary". Each subsection / link has a direction and a weight value. The direction is an arbitrary value that specifies the direction of movement from one route to another node, and the weight value indicates the likelihood that a passenger / moving entity will select a particular link / subsection. From the example in Figure 5, we can see that there are links between the nodes "Station A", "Boarding", and "Station B", indicated by reference numerals 4011 and 4012. Furthermore, there are links from "Station B" to "Boarding", and from "Boarding" to "Station C", indicated by reference numerals 4013 and 4014. These links have a weight value of "100". The value does not have units. Preferably, the value represents a percentage value. The station and "Boarding" nodes have reference numerals 4001-4005 in this example in Figure 5. Additional links / subsections between nodes are available. One of the additional subsections connects node "Station A" to node "Station C" and has reference numeral 4015 and a weight value of "20".Furthermore, the direct connection between station A node and station B node, which has reference code 4016, has a weight value of "70", and the direct connection / link / subsection between station B and station C has reference code 4017 and a weight value of "40". Looking at the example in Figure 5, the highest probability of a moving object traveling from station A to station C is while riding in a transport vehicle such as a bus, which connects station A to station B and station B to station C. This is because all the links / subsections between the stations mentioned above have a weight value of "100". In other words, for example, the probability of a moving object traveling from station A to station C on foot or by bicycle, which has a weight value of "20", is lower than the probability of a moving object traveling from station A to station C on foot or by bicycle, which has a weight value of "20". The same applies to any other arbitrary connection from station A to station C, meaning that the moving object is likely to choose the bus route mentioned above.

[0040] Furthermore, it should be noted that the assigned weight values ​​can be modified / updated over time and / or in relation to specific circumstances. For example, if the system is informed that the transport vehicle between stations A and B is experiencing technical difficulties, the weight values ​​for subsections 4011 and 4012 may be reduced to less than the weight value for subsection / link 4016. Moreover, if the weather is very good and the distance between the two nodes is relatively short, the weight value for taking this link / subsection on foot or by bicycle may be increased, and may be greater than the value for public transport vehicles such as buses or subways. Further possibilities for correction / update will be discussed in the following explanation.

[0041] The network shown in Figure 5 may be stored in the device 1100 as a data table, for example, as shown in Figure 6. Specifically, the itinerary network database 1103 shown in Figure 6a contains predetermined itinerary subsections for each line. 5011 ~ 501nA particular example in Figure 6a uses reference numerals 5011-5017, where the first column indicates the start node of a given journey subsection, the second column indicates its end node, and the third column indicates the assigned weight value. The weight values ​​shown in Figure 6a may be initially predefined values ​​that may be adapted over time. A more preferred option in this connection is shown in Figure 2, which includes a database having individual data 1104 of the mobiles. Each registered mobile may have its own individual data 1104. The individual data 1104 may preferably include updated / modified weight values ​​learned by the device 1100. For example, if a mobile previously preferred link 4016 in Figure 5 over the bus corresponding to links 4011 and 4012, the device 1100 may learn that this particular mobile, identified by ID, prefers link 4016, and therefore the predefined (general) weight values ​​for links 4011 and 4012 may be reduced to be lower than the weight value for link 4016. Naturally, for the same effect, the weight value of link 4016 may be increased in the opposite direction. As a result, by learning individual preferences, the accuracy of itinerary generation can be further improved, and a personalized output can be ensured.

[0042] Furthermore, the device 1100 includes a travel itinerary generation unit 1113, and an example of the operation / method steps that can be performed by the unit 1113 is shown in Figure 8. Specifically, the travel itinerary generation unit 1113 is configured to generate travel history data 1105, which is stored in each database of the device 1100, which also preferably has a data structure such as a table or array. Figure 6b shows an example of travel history data generation generated by the travel itinerary generation unit 1113. Specifically, Figure 6b shows a table of travel history data 1105, which includes multiple travel subsection information data 6001 to 600n. In the example of Figure 6b, five different travel subsection information data (in other words, travel subsection information data sets) are shown with reference numerals 6002 to 6005. In the example of Figure 6b, the travel subsection information data 6001 to 600n each include a user ID and optionally a path ID, respectively. Furthermore, each of the itinerary subsection information data 6001 to 600n includes a start position, an end position, an estimated value, and, in a preferred embodiment, a property value. Each line in the table shown in Figure 6b preferably represents one (one set) of itinerary subsection information data 6001 to 600n, which is generated by a loop-like processing of the steps shown in Figure 8.

[0043] Figure 8 specifically shows that in the first step S1, the itinerary generation unit 1113 reads the first record from the location history data 1102 in Figure 4. In the example in Figure 4, the first value read in the first processing loop of the step in Figure 8 would be the location information data 3001, which indicates the user with ID 1 who was at station A at 10 AM. Temporary values ​​(referred to as "checkpoints" in the diagram) are stored with this first record as the starting point (step S2), and the next record is read from the location history data 1102 (step S3). In the example in Figure 4, this is the location information data 3002. Subsequently, it is checked whether the temporarily stored starting points are the same (step S4), that is, the locations of data 3001 and 3002 are compared with each other, and if they are identical, the next record is read by following the "yes" path in Figure 8. For example, the comparison in Figure 8 will return "yes" because the two first entries in Figure 4, namely location information 3001 and 3002, contain the same entry. However, the next record, location information 3003, which contains the entry "boarding", is different from the starting point ("Station A"), so the next comparison will return "no" as a result. If "no" is returned, the ending point is set (step S5). In this example, this would be because the location entry for location information 3003 is "boarding". Subsequently, the start and end positions of the first generated itinerary subsection information data 6001~600n (in the above example, this would be itinerary subsection information data 6001 in Figure 6b) are determined and entered into the itinerary history data 1105. Furthermore, the user ID must be known and an estimated value added. The estimated value is determined by step S6 in Figure 8, which includes reading the weight values ​​for the same predetermined journey subsection, where "same" means that the start and end positions of the journey subsection information data 6001-600n are the same as the predetermined journey subsection. 5011 ~ 501nThis means that the start and end nodes of the itinerary network database are equal to the start and end nodes of the itinerary network database. In this example, the itinerary generation unit 1113 will determine the weight value from the itinerary network database 1103, using the fact that the first entry in the itinerary database 1103 is a given itinerary subsection 5011, which includes a weight value of "100" for the start at station A and the end at "boarding". This weight value of "100" is recorded as an estimated value of "100" in the itinerary subsection information data 6001-600n. The first loop of the steps, as shown in Figure 8, is completed as soon as the new record, i.e., one (one set) of itinerary subsection information data 6001-600n, is entered into the itinerary history data 1105 (step S7). In the next loop, if the location history data 1102 has the following record (steps S8, S9), an additional record is generated for the itinerary history data 1105. Therefore, the next unread / unprocessed entry in the location history data 1102 is selected. In the example above, the next entry would be location information 3004, which includes the location "boarding" at 10:07:00 AM. The user ID and location are stored, and the location is stored as the starting point, and the procedure described above with respect to Figure 8 is repeated, so in this example, the next ending point would be found to be location information 3005, which has the location "station B" reached at 10:08:00 AM. The weight for each itinerary subsection information data 6002 will again be selected from the table, as shown in Figure 6a, in relation to a given itinerary subsection 5012 which also has a weight value of "100". Thus, the estimated value "100" is set, and entry 6002, i.e., the second itinerary subsection information data, is entered into the itinerary history data 1105, as shown in Figure 6b. The above is carried out in a loop until there is no more available location history data 1102. In the example considered, the last itinerary subsection information data 6001-600n would likely be the data (set) with reference numeral 6003 in Figure 6b.

[0044] Assuming that all data is transmitted with high reliability and stored in location history data 1102, the three itinerary subsection information data 6001-6003, as shown in Figure 6b, would be output by output unit 1115 as an aggregated itinerary, multiple itineraries, or subsections of a single itinerary. Furthermore, a fare calculation unit 1112 may be added to device 1100, which can utilize a fare database as shown in Figure 2, having reference numeral 1106, an example of which is shown in Figure 7. a As shown in the figure, the fare database can assign a price to each subsection / link that is shown and / or charged to a traveler. In this example, the price for a ride in a transport vehicle from station A to station B is 120, and the price for a ride from station B to station C is 150. That is, in the embodiments considered above and in the examples of the claimed subject matter, based on the itinerary subsection information data 6001-6003, as shown in Figure 6b, also generated by the itinerary generation unit 1113, the price 120 may be output for a ride in a transport vehicle from station A to station B, as is evident from the itinerary subsection information data 6001-6002, and according to the information from the itinerary subsection information data 6003, there would be no need to pay a price for the connection between station B and station C, as no transport vehicle was used in this subsection. This result may be displayed to the traveler by the output unit 1115.

[0045] In a further preferred embodiment, the itinerary estimation unit 1114 is included in the device 1100, which adds an additional layer of fail-safety and reliability, particularly in ensuring that appropriate itineraries / itinerary subsections are generated and, if applicable, output by the output unit 1115. Specifically, a proposed configuration of processing by the itinerary estimation unit 1114 is shown in Figure 9, in which a first step (step A1) is taken, in which a first record is read from the itinerary history data 1105. In this example, the first record to be read would be itinerary subsection information data 6001, as shown in Figure 6b. Next, a decision is made (step A2) as to whether the estimated value of the history subsection information read above, here having reference numeral 6001, is less than a predefined threshold. The threshold may be stored in the data storage area of ​​the device 1100 or elsewhere of its choice. In this example, assuming that the threshold is less than "100", the result of the decision would be "yes" for the record 6001 of the itinerary history data 1105. Therefore, the following record will be read (step A6), which has reference numeral 6002 in Figure 6b. The estimate for this record is also above the threshold, so the following record, which has reference numeral 6002 in the example of Figure 6b, is read from the itinerary history data 1105. However, the itinerary subsection information data 6003 has an estimate of "40", where, for example, it is assumed to be below a predefined threshold, so the decision (in step A2) is "no". Thus, alternative itinerary subsection information data 6001-600n are generated (step A3). The step of generating or finding alternatives may include further substeps (not shown) which may be repeated in a loop. The substeps may include generating / finding all possible alternatives for other subsections which end or start at the start or end position of the actual itinerary subsection information data (the "actual" in the loop being processed, e.g., which has reference numeral 6003 in the example of Figure 6b) which has an estimate below the threshold.In the example of Figure 6b, this would involve the itinerary estimation unit 1114 searching for predetermined itinerary subsections 5000-500n as shown in the example of Figure 6a, and generating the alternative itinerary subsection information data 6004 and 6005 (sets) in Figure 6b. This is done by finding that the predetermined subsections 5000-500n include one predetermined subsection having the same starting position as the dataset 6003 in Figure 6b, which is predetermined subsection information 5013 having the same starting position as the end node "boarding" and a weight value of "100". Furthermore, since the alternative itinerary subsection information data 6005 is found at the same ending position as the itinerary subsection information data 6003, i.e., station C, it can use the predetermined subsection information 5014 in the network database 1103 that connects the starting node "boarding" to the ending node station C, as shown in Figure 6a. Since both have a weight value of "100", the estimated value "100" is input for both of the two further alternative journey subsection information data 6004 and 6005 (sets) in the example of Figure 6b. It should be noted that the alternative subsection information data added by the journey estimation unit 1114 is not directly based on transmissions / data from originating node N received by the mobile computer 1200. However, these alternatives have a higher weight value, i.e., a higher probability of being selected by the mobile, even though the signal / data has not been received by the device 1100 for these links / subsections. The reason for not receiving the data may be equipment failure or interruption of the transmission path. As an additional safety option, the journey estimation unit 1114 may have an additional check step (step A4). This step may determine whether the weight value of the generated alternatives exceeds a threshold. The threshold may be the same as the threshold described above. If this optional step A4 is included, whether step A5 is performed depends on the result of the check. Step A5 involves generating a new entry / record for the itinerary history data 1105.

[0046] In particular, in preferred embodiments including the itinerary generation unit 1113 and the itinerary estimation unit 1114, the output unit 1115 may proceed according to the configuration / method shown in the example of Figure 10. In this example, the generated itinerary history data 1105 is read for each record, i.e., in the first step (step B1), the first record is read, and in the next step (step B2), it is determined whether the estimate stored for the record is greater than a threshold, and if this is true, the record is indicated as a "confirmed itinerary" (step B3). This indication may be made by adding a temporary variable having, for example, this label. However, if the estimate is less than the threshold, an optionally provided property of the itinerary subsection information is checked (step B5), the itinerary generation unit 1113 sets the property "actual", and the itinerary estimation unit 1114 sets the property "assumption". If these properties are set, the itinerary history data 1105 may now be checked for whether there is data connecting the same start and end positions indicated by the property "assumption" (step B5). If this is not the case, the determination is "No" and the record is indicated as "Confirmed Itinerary" (Step B3). However, if there is an entry indicated as "Assumption", this entry is selected and indicated as "Alternative Itinerary" (Step B7). Next, the information is updated (Step B4) and the next record is read (Step B8). By looping through all records of the itinerary history data 1105, the entire itinerary from station A to station C in the example provided here can be determined, along with all the subsections / itineraries in between. In the very specific example of Figure 6b, the entries with reference numerals 6001 and 6002 have an estimated value of "100" which is assumed to be greater than a predefined threshold, so they are indicated as "Confirmed Itinerary", and by the update information step (see Step B4 in Figure 9), these two subsections may be aggregated / combined into a single itinerary connecting station A to station B by taking a transport vehicle such as a bus or train. This is illustrated by the example output displayed on the mobile computer 1200. See Figure 7b.Furthermore, this is indicated as a "confirmed itinerary." Regarding the connection from station B to station C, the specific flow of steps as shown in Figure 10 indicates that the record with an estimated value of "40" is indicated as an "alternative itinerary," but this is not clearly definable as a "confirmed itinerary" because it is assumed that the estimated value of "40" in the entry with reference code 6003 is below a preset threshold, which in this example may be "70" or "80." Furthermore, two "assumed" entries with reference codes 6004 and 6005 connect station B to "boarding" and "boarding" to station C, and have estimated values ​​exceeding the threshold, so they are provided to the itinerary history data 1105 in Figure 6b and output as an aggregated "confirmed itinerary." See Figure 7b. This is shown in the lower center box of Figure 7b, indicating that the device 1100 assumes that travel from station B to station C was by rail or other transport vehicle such as bus. However, it is also indicated that users of the mobile computer 1200 may travel from station B to station C by alternative means of transportation, such as by vehicle, on foot, or in their own car.

[0047] Furthermore, as described above, a further preferred option is to display to the user of the mobile computer 1200 the price / fare of the itinerary, calculated by a fare calculation unit 1112 that compares subsections of the itinerary, such as those provided by the itinerary history data 1105, with a fare table that includes the start and end stations and their prices, based on data from the fare database 1106. In addition, the account management unit 1111, shown in Figure 2, can charge the fare from the bank account, credit card, or any other payment option of the user having their respective ID, based on the account data 1101.

[0048] In a further preferred embodiment of the claimed subject matter, the interaction of the mobile computer 1200 with the mobile / user may be further enhanced by adding a mobile route network update unit 1116 to the device 1100, configured to receive user input / feedback data after the itinerary has been output by the output unit 1115, as shown in Figure 7b as an example. A flow of the method / steps is shown with an example included in Figure 11. The feedback data may include information about the selected itinerary if an alternative is displayed. The feedback may be input by the user to the mobile computer 1200, for example, a selection between a confirmed itinerary and an alternative itinerary from station B to station C in the example of Figure 7b. If the user selects the displayed "confirmed itinerary," which would be using a transport vehicle from station B to station C in the example of Figure 7b, and sends it as feedback (step C1), the check step (step C2) will be affirmative, and the weight value of this selected itinerary will be increased in the individual passenger's itinerary network data 1104 (step C3). Therefore, a specific user's preferred choices can be saved and promoted over time. However, if the check step returns "no," i.e., if the user has not confirmed / selected a "confirmed itinerary" but has selected an "alternative itinerary," the weight of the individual passenger in the database 1104 is reduced (step C4). In addition, an alarm may be optionally triggered (step C5), which will be discussed later. Furthermore, the weight value in the general itinerary network database 1103 is increased (step C6). This feedback function / itinerary network update unit 1116 allows the device 1100 to learn to output more accurate itinerary suggestions to the mobile computer 1200.The function / method for modifying weight values, as described in this connection, may preferably be combined with other possibilities for modifying weights, which are not expressly suggested or illustrated by the drawings, but include providing the device 1100 with a further modification unit that changes the weight of a given journey subsection 5000-500n depending on conditions such as weather, strikes, or technical problems with public transport.

[0049] As described above, preferably, the device 1100 may include an alarm unit 1117 that processes steps as shown in Figure 12. This means that a record in the itinerary network data 1103 is read in correspondence with the “alternative itinerary / trip” output (step C51). Next, each weight value is temporarily stored in a variable, which may be called the average, etc. (step C52). Then, the record corresponding to the “alternative itinerary” is read from the individual database 1104 of the mobile entity (step C53), and this weight value is set / stored in a variable, which may be called “individual,” etc. (step C54). Then, the two temporarily stored variables / values ​​are compared with each other (step C55), and if the difference between these two values ​​exceeds a preset alarm threshold (step C56), it indicates that user fraud may have occurred, which may mean that the user has selected the “alternative itinerary” output, for example, shown in Figure 7b, even though it was not an itinerary that was actually traveled. Thus, safety and reliability are further increased.

[0050] It should also be noted that the above description and drawings illustrate simpler examples than actual application scenarios, so as to allow for a quick understanding of the overall technical concept of the claimed subject matter. It is assumed that the number of databases, datasets, users, etc., as well as the number of nodes and subsections, which may represent actual city, country, or global travel options, are much larger. The preferred embodiments and examples described above may be combined with each other where a person skilled in the art would not need to apply inventive step.

[0051] In general, more reliable devices and systems can be generated for generating the itinerary of a mobile object and notifying the user of the mobile computer 1200. Corresponding methods and computer program products are also provided.

Claims

1. An input unit receives data from a mobile computer regarding the location of the mobile computer or boarding a vehicle, and the time of boarding the vehicle. A database that records multiple nodes indicating location, a node indicating boarding a vehicle, multiple links connecting any two of the nodes indicating location and the nodes indicating the vehicle, and the weight values ​​of the multiple links. A travel itinerary generation unit generates a travel itinerary for the mobile computer based on the data input to the input unit and the data recorded in the database. It has an output unit that outputs the itinerary generated by the itinerary generation unit, The aforementioned weight value is a value that indicates the likelihood that the mobile computer will select a particular link from among the multiple links. The itinerary generation unit reads the weight value of the first link connecting the location of the first mobile computer or boarding a vehicle to the location of the second mobile computer or boarding a vehicle from the database. If the weight value of the first link is smaller than a predetermined threshold, it outputs an alternative itinerary different from the first link. Itinerary generator.

2. The weight values ​​recorded in the aforementioned database are updated over time and / or in relation to specific circumstances. The itinerary generation device according to claim 1.

3. The input unit receives the identification information of the mobile computer. The weight values ​​recorded in the aforementioned database are updated for each identification information of the mobile computer. A travel itinerary generation device according to any one of claims 1 to 2.

4. In a travel itinerary generation method performed in a travel itinerary generation device, The steps include inputting data from a mobile computer, including the location of the mobile computer or boarding a vehicle, and the time of boarding the vehicle; A step of reading the weight values ​​from the input data, based on the weight values ​​of the multiple links, which include multiple nodes indicating locations recorded in the database, a node indicating boarding a transport vehicle, multiple links connecting any two of the multiple nodes indicating locations and the nodes indicating transport vehicles, and the weight values ​​of the multiple links. The steps include generating a travel itinerary for the mobile computer based on the input data and the read weight values, The step of outputting the generated itinerary, The aforementioned weight value is a value that indicates the likelihood that the mobile computer will select a particular link from among the multiple links. In the step of generating the itinerary, based on the input data, the system reads the weight value of the first link connecting the location of the first mobile computer or boarding a vehicle and the location of the second mobile computer or boarding a vehicle from the database, and if the weight value of the first link is smaller than a predetermined threshold, it outputs an alternative itinerary different from the first link. How to generate itinerary.

5. The weight values ​​recorded in the aforementioned database are updated over time and / or in relation to specific circumstances. The itinerary generation method according to claim 4.

6. In the itinerary generation method performed in the itinerary generation device, The process includes a step in which the mobile computer's identification information is input from the mobile computer, The weight values ​​recorded in the aforementioned database are updated for each identification information of the mobile computer. A method for generating a travel itinerary according to any one of claims 4 to 5.

Images