JP6008558B2 - Program, information processing apparatus, and information processing method - Google Patents

Description

  The present invention relates to a program for performing information processing by a computer, an information processing apparatus, and an information processing method.

  Conventionally, there is a driving assistance device that detects the approach of a pedestrian or another vehicle and outputs an appropriate warning to the driver according to the situation (see, for example, Patent Documents 1 to 3).

JP 2009-282702 A JP 2004-287728 A JP 2009-9446 A

  However, the conventional support device has a problem that accuracy of determining whether or not it is dangerous is low.

  The present invention has been made in view of such circumstances. The purpose is to provide a program or the like that can calculate the degree of risk more accurately.

The program disclosed in the present application is obtained by a computer having a control unit, reading the speed of a bicycle approaching an intersection by the control unit, and reading from the storage unit storing the past average speed of the bicycle and the stop state at the intersection. The average speed and stop state of the bicycle that has been taken out are acquired by the control unit, a first risk is determined by the control unit based on the acquired speed, average speed, and stop state, and the bicycle reaches the intersection The second risk is determined based on a time difference obtained by subtracting the difference between the actual time and the predicted time, and a process of outputting the risk determined based on the determined first risk and second risk is executed by the control unit. .

  According to one aspect of the present application, it is possible to calculate the degree of risk more accurately.

It is explanatory drawing which shows the outline | summary of an information processing system. It is a block diagram which shows the hardware group of a mobile telephone. It is a block diagram which shows the hardware group of a mobile telephone. It is a block diagram which shows the hardware group of a server computer. It is explanatory drawing which shows the record layout of map DB. It is explanatory drawing which shows the record layout of driving | running | working DB. It is explanatory drawing which shows the record layout of stop DB. It is explanatory drawing which shows the record layout of driving | running history DB. It is explanatory drawing which shows the record layout of stop log | history DB. It is explanatory drawing which shows the display image of the danger information displayed on a display part. It is a flowchart which shows the recording processing procedure of the driving | running | working state of a bicycle. It is a flowchart which shows the procedure of a stop event memory | storage process. It is a flowchart which shows the memory | storage process procedure of a driving history. It is a flowchart which shows the memory | storage process procedure of a driving history. It is a flowchart which shows the memory | storage process procedure of the frequency | count of a stop. It is a flowchart which shows the procedure of a risk determination process. It is a flowchart which shows the procedure of a danger output process. It is a flowchart which shows the procedure of a danger output process. It is a flowchart which shows the determination process procedure of a risk level. It is a flowchart which shows the determination process procedure of a risk level. 10 is an explanatory diagram illustrating a hardware group of a server computer according to Embodiment 3. FIG. It is explanatory drawing which shows the record layout of a risk degree table. It is a flowchart which shows the output processing procedure of danger information. It is a flowchart which shows the output processing procedure of danger information. FIG. 10 is a block diagram illustrating a hardware group of a mobile phone according to a fourth embodiment. It is a flowchart which shows the output processing procedure of danger information. It is a flowchart which shows the output processing procedure of danger information. It is a functional block diagram which shows operation | movement of the server computer of the form mentioned above. FIG. 10 is a block diagram illustrating a hardware group of a server computer according to a fifth embodiment. FIG. 10 is a block diagram illustrating a hardware group of a mobile phone according to a fifth embodiment.

Embodiment 1
Hereinafter, embodiments will be described with reference to the drawings. FIG. 1 is an explanatory diagram showing an outline of an information processing system. The information processing system includes an information processing device 1, an information processing device 2, an information processing device 3, and the like connected to each other via a communication network N such as the Internet, a LAN (Local Area Network), and a public telephone network. The information processing device 3 is a portable information processing device possessed by a user riding a bicycle or mounted on a bicycle, and is a mobile phone, a PDA (Personal Digital Assistance), a dedicated device installed on the bicycle, or a game machine Etc. Hereinafter, the information processing apparatus 3 will be described as being the mobile phone 3. The information processing device 2 is a car navigation device mounted on a car or a portable information processing device owned by a driver, and is a mobile phone, a PDA, a game machine, or the like. Below, the information processing apparatus 2 is demonstrated as what is the mobile telephone 2. FIG.

  The information processing apparatus 1 is, for example, a server computer or a personal computer, and transmits / receives information to / from the mobile phone 2 and the mobile phone 3. In the following description, the information processing apparatus 1 is assumed to be the server computer 1. The server computer 1 collects information transmitted from the mobile phone 3 of the bicycle user, thereby storing a bicycle running history. In addition, the server computer 1 collects the stop status as to whether or not the bicycle has stopped at the intersection and stores the bicycle stop history. The server computer 1 calculates the degree of danger based on the average speed of the bicycle based on the running history and the stop state. The server computer 1 outputs the calculated risk level to the automobile heading for the intersection. Details will be described below.

  FIG. 2 is a block diagram showing a hardware group of the mobile phone 3. The mobile phone 3 includes a CPU (Central Processing Unit) 31, a RAM (Random Access Memory) 32, an input unit 33, a display unit 34, a storage unit 35, a clock unit 38, a GPS (Global Positioning System) module 39, and a communication unit. 36 etc. are included. The mobile phone 3 includes a microphone 310, a speaker 311 and an acceleration sensor 312. The CPU 31 is connected to each part of the hardware via the bus 37. The CPU 31 controls each part of the hardware according to the control program 35P stored in the storage unit 35. The RAM 32 is, for example, SRAM (Static RAM), DRAM (Dynamic RAM), flash memory, or the like. The RAM 32 also functions as a storage unit, and temporarily stores various data generated when the CPU 31 executes various programs.

  The input unit 33 is an input device such as a mouse, a keyboard, or a touch panel, and outputs received operation information to the CPU 31. The display unit 34 is a liquid crystal display, an organic EL (electroluminescence) display, or the like, and displays various information according to instructions from the CPU 31. The communication unit 36 is a wireless LAN card, a communication antenna, or the like, and transmits / receives information to / from the server computer 1 or the like via the communication network N. The storage unit 35 is, for example, a hard disk or a large-capacity flash memory, and stores a control program 35P and the like.

  The GPS module 39 receives longitude and latitude transmitted from a GPS satellite as position information. The GPS module 39 outputs the received position information to the CPU 31. The microphone 310 AD converts the collected audio signal and outputs the converted audio information to the CPU 31. The speaker 311 outputs a DA-converted audio signal in accordance with an instruction from the CPU 31. The clock unit 38 outputs date / time information to the CPU 31. The acceleration sensor 312 is, for example, a triaxial acceleration sensor, and outputs the detected acceleration in the triaxial direction to the CPU 31.

  FIG. 3 is a block diagram showing a hardware group of the mobile phone 2. The cellular phone 2 includes a CPU 21, a RAM 22, an input unit 23, a display unit 24, a storage unit 25, a clock unit 28, a GPS module 29, a communication unit 26, and the like as control units. The mobile phone 2 includes a microphone 210, a speaker 211, an acceleration sensor 212, and the like. The CPU 21 is connected to each part of the hardware via the bus 27. CPU21 controls each part of hardware according to control program 25P memorized by storage part 25. The RAM 22 is, for example, SRAM, DRAM, flash memory or the like. The RAM 22 also functions as a storage unit, and temporarily stores various data generated when the CPU 21 executes various programs.

  The input unit 23 is an input device such as a mouse, a keyboard, or a touch panel, and outputs received operation information to the CPU 21. The display unit 24 is a liquid crystal display, an organic EL display, or the like, and displays various information according to instructions from the CPU 21. The communication unit 26 is a wireless LAN card, a communication antenna, or the like, and transmits / receives information to / from the server computer 1 through the communication network N. The storage unit 25 is, for example, a hard disk or a large-capacity flash memory, and stores a control program 25P and the like.

  The GPS module 29 receives longitude and latitude transmitted from a GPS satellite as position information. The GPS module 29 outputs the received position information to the CPU 21. The microphone 210 AD-converts the collected audio signal and outputs the converted audio information to the CPU 21. The speaker 211 outputs an audio signal that has been D / A converted in accordance with an instruction from the CPU 21. The clock unit 28 outputs date / time information to the CPU 21. The acceleration sensor 212 is, for example, a triaxial acceleration sensor, and outputs the detected acceleration in the triaxial direction to the CPU 21.

  FIG. 4 is a block diagram showing a hardware group of the server computer 1. The server computer 1 includes a CPU 11 as a control unit, a RAM 12, an input unit 13, a display unit 14, a storage unit 15, a clock unit 18, a communication unit 16, and the like. The CPU 11 is connected to each part of the hardware via the bus 17. The CPU 11 controls each part of the hardware according to the control program 15P stored in the storage unit 15. The RAM 12 is, for example, SRAM, DRAM, flash memory or the like. The RAM 12 also functions as a storage unit, and temporarily stores various data generated when the CPU 11 executes various programs.

  The input unit 13 is an input device such as a mouse or a keyboard, and outputs received operation information to the CPU 11. The display unit 14 is a liquid crystal display, an organic EL display, or the like, and displays various information according to instructions from the CPU 11. The clock unit 18 outputs date information to the CPU 11. The communication unit 16 is a wired or wireless LAN card and transmits / receives information to / from the mobile phone 2 and the mobile phone 3 through the communication network N.

  The storage unit 15 is, for example, a hard disk or a large-capacity flash memory, and stores the control program 15P. In addition, the storage unit 15 stores a map database (hereinafter referred to as DB) 151, a travel DB 152, a stop DB 153, a travel history DB 154, a stop history DB 155, and the like.

  FIG. 5 is an explanatory diagram showing a record layout of the map DB 151. The map DB 151 includes a route ID field, a route length field, a start point field, an end point field, a point field, and the like. A road on which a bicycle and a car travel is formed by a collection of routes (links) and intersections (nodes). In the route ID field, identification information for specifying a route (hereinafter referred to as a route ID) is stored. The route length field stores the length of the route in association with the route ID. In the starting point field, the longitude and latitude of the starting point of the route and the intersection ID of the starting point are stored in association with the route ID. The intersection ID is identification information for specifying an intersection connecting the route.

  In the end point field, the longitude and latitude of the end point of the route and the intersection ID of the end point are stored in association with the route ID. In the following, an intersection is in principle an intersection at the end point. The point field stores the latitude and longitude of a point obtained by dividing the route into ten parts. In the example of FIG. 5, the latitude and longitude at 1/10 point and the latitude and longitude at 9/10 point are shown. Further, it may be divided finely. In the present embodiment, the example of dividing into 10 has been described, but the present invention is not limited to this. In addition, the record layout such as the DB and the table described in the embodiment is merely an example, and the present invention is not limited to this. Other storage formats may be used as long as the relationship between data is maintained. Further, an example in which the DB and the table described in the embodiment are stored in the storage unit 15 will be described. However, the present invention is not limited to this. In addition to being stored in the RAM 12, it may be described in a program, or data may be stored in another DB server (not shown).

  FIG. 6 is an explanatory diagram showing a record layout of the travel DB 152. The travel DB 152 includes a bicycle user ID field, a time field, a latitude field, a longitude field, a moving speed field, a route ID field, an intersection ID field, an estimated arrival time field, and the like. In the bicycle user ID field, identification information (hereinafter referred to as a bicycle user ID) for specifying the bicycle user who is the owner of the mobile phone 3 is stored. The CPU 31 of the mobile phone 3 transmits the latitude and longitude output from the GPS module 39 to the server computer 1 periodically (for example, every few seconds) together with the bicycle user ID.

  The CPU 11 receives the car user ID, latitude, and longitude from the mobile phone 3. The CPU 11 refers to the map DB 151 and identifies the route ID along which the mobile phone 3 is moving based on the latitude and longitude. Further, the CPU 11 specifies the traveling direction from the latitude and longitude transmitted in different time zones. CPU11 reads intersection ID of the intersection used as an end point from map DB151 based on route ID and a running direction.

  In the time field of FIG. 6, the time when the latitude and longitude are received from the mobile phone 3 is stored. The year and date are omitted. When the CPU 11 receives the latitude and longitude from the mobile phone 3, the CPU 11 stores the time output from the clock unit 18 in association with the bicycle user ID. When the time information is transmitted from the mobile phone 3 together with the latitude and longitude, the CPU 11 may store the time in the time field. In the latitude field and the longitude field, the latitude and longitude transmitted from the mobile phone 3 in association with the bicycle user ID are stored.

  The moving speed field stores the moving speed of the mobile phone 3 (bicycle) in association with the bicycle user ID. The CPU 11 calculates the moving speed based on the latitude and longitude of the two locations and the time. The CPU 11 stores the calculated moving speed in the travel DB 152. The moving speed obtained by the CPU 31 of the mobile phone 3 from the GPS module 39 may be used as the moving speed. In this case, the CPU 21 outputs the moving speed together with the latitude and longitude to the server computer 1. In the route ID field, a route ID on which the bicycle travels is stored in association with the bicycle user ID. The CPU 11 stores the route ID extracted from the map DB 151 corresponding to the latitude and longitude in the travel DB 152. In the intersection ID field, an intersection ID is stored in association with the bicycle user ID. The CPU 11 calculates the traveling direction based on the latitude and longitude of different time zones. The traveling direction calculated by the CPU 31 of the mobile phone 3 using the acceleration sensor 312 may be used. CPU11 extracts intersection ID which exists ahead of a running direction based on route ID, and memorizes it in running DB152.

  The CPU 11 reads out the latitude and longitude corresponding to the intersection ID from the map DB 151. The CPU 11 calculates the distance to the intersection based on the current latitude and longitude and the longitude and latitude corresponding to the intersection ID. The CPU 11 calculates the predicted arrival time based on the calculated distance, moving speed, and time. In the example of FIG. 6, the user with the bicycle user ID “CY001” is traveling on the route ID “K001” at the stage of 12:20:35 and reaches the intersection at 12:20:45. It is predicted. Note that the method for calculating the predicted arrival time is merely an example, and is not limited thereto. For example, the calculation may be performed in consideration of the gradient of the route, the number of other bicycles, the width of the route, and the like. A record of each bicycle user ID is sequentially stored in the travel DB 152. Further, the CPU 31 of the mobile phone 3 may calculate the predicted arrival time. Specifically, the CPU 31 executes bicycle navigation software installed in advance, and outputs the predicted arrival time calculated by the software to the server computer 1.

  FIG. 7 is an explanatory diagram showing a record layout of the stop DB 153. The CPU 11 determines whether the moving speed is equal to or less than a predetermined speed (for example, 1 km / h) at the latitude and longitude of the intersection ID. It is not necessary for the latitude and longitude of the intersection ID to completely match, and the speed of a point within a predetermined range (for example, within a radius of 3 m) from the point specified by the latitude and longitude of the intersection ID is equal to or lower than a predetermined speed (for example, , 0.3 km / h or less). When the CPU 11 determines that the moving speed is equal to or lower than the predetermined speed, the CPU 11 determines that the mobile phone 3 (bicycle) has stopped as an event. When the CPU 11 determines that the vehicle is stopped, the CPU 11 associates the bicycle user ID, time, latitude, longitude, route ID, and intersection ID with each other, and stores a stop state indicating that the vehicle has temporarily stopped at the intersection and then passed the intersection.

  The time field in the stop DB 153 stores the time when the bicycle is stopped in association with the bicycle user ID field. In the latitude and longitude fields, the latitude and longitude at the intersection where the bicycle user ID is stopped are stored. In the event field, information indicating that the bicycle user ID is stopped is stored. In the route ID field and the intersection ID field, the route ID of the stopped intersection and the stopped intersection ID are stored in association with the bicycle user ID. Thus, CPU11 memorize | stores the stop condition of each bicycle in sequential stop DB153.

  FIG. 8 is an explanatory diagram showing a record layout of the travel history DB 154. For example, the CPU 11 stores a travel history in the travel history DB 154 for each route and for each bicycle user ID at the end of the day. The example of FIG. 8 shows the travel history of one user's specific route and end point intersection. The travel history DB 154 includes a day of the week field, a time zone field, a total travel number field, an average speed field, a reference speed field, and the like. The day of the week is stored in the day of the week field. In the time zone field, a time zone is stored for each day of the week. Holidays may be included. Moreover, you may memorize | store driving | running history, without providing a day of the week or a time slot | zone.

  In the time zone field, a time zone is stored in association with the day of the week. For example, the time zone is stored every three hours. The total number of traveling fields stores the total number of traveling on the route in association with the day of the week and the time zone. The CPU 11 refers to the day of the week and the time in the travel DB 152 and increments the total number of travels when there is travel on the route. Note that when the traveling time spans two time zones, the later time zone may be selected. The average speed field stores the average speed of the route in the time zone. CPU11 extracts the moving speed of traveling DB152. The CPU 11 calculates the average speed by dividing the moving speed by the number of records of the route in the travel DB 152. The CPU 11 adds the calculated average speed to a value obtained by multiplying the total number of travels stored in the travel history DB 154 and the average speed. The CPU 11 calculates the average speed by dividing the added value by the value obtained by incrementing the total number of runs. The CPU 11 stores the calculated average speed in the travel history DB 154.

  The reference speed field stores a reference speed used when determining the degree of danger. The reference speed is a value based on the past average speed stored in the travel history DB 154. For example, in addition to the average speed, the average speed is a value obtained by adding or multiplying the coefficient stored in the storage unit 15. The other reference speed may be a value obtained by adding a standard deviation to the average speed. In the present embodiment, a value obtained by adding a value twice the standard deviation to the average speed will be described as the reference speed. CPU11 reads the past moving speed which makes the day and time zone memorize | stored in driving | running | working DB152 the same. The CPU 11 calculates an average value of the read movement speeds. CPU11 calculates | requires a standard deviation from the square root of the sum total of the square of the difference of a moving speed and an average value. The CPU 11 adds a value obtained by doubling the standard deviation to the average speed, and stores it in the travel history DB 154 as a reference speed.

  FIG. 9 is an explanatory diagram showing a record layout of the stop history DB 155. The stop history DB 155 includes a total travel number field, a stop number field, and a ratio field. In the total number of travel fields, the total number of times the user has traveled toward the intersection as the end point is stored in association with the day of the week and the time zone. In the stop count field, the total number of stops at the intersection is stored in association with the day of the week and the time zone. The CPU 11 refers to the day of the week and the time in the stop DB 153 and determines whether or not at least one stop is stored in the event field. If the CPU 11 determines that it is stored, the CPU 11 increments the number of stops. If the vehicle is always stopped at an intersection, the number of trips and the number of stops coincide. However, when the vehicle is not stopped at the intersection, the number of stops is less than the number of travels.

  In the rate field, the rate at which the vehicle passes through the intersection after stopping at the intersection is stored in association with the day of the week and the time zone. The CPU 11 calculates the ratio by dividing the number of stops by the total number of runs. The CPU 11 stores the calculated ratio in the stop history DB 155. In this embodiment, the ratio is a value obtained by dividing the number of stops by the total number of travels, but is not limited to this. It is good also as the ratio which passed without stopping at the intersection. In this case, the CPU 11 may divide the value obtained by subtracting the number of stops from the total number of travels by the total number of travels, and use the divided value as a ratio.

  The CPU 11 determines whether the current movement speed of the bicycle acquired from the travel DB 152 exceeds the reference speed stored in the travel history DB 154 and the ratio stored in the stop history DB 155 is not 100. When the CPU 11 determines that both conditions are satisfied, the CPU 11 determines that the degree of risk is 1. The CPU 11 determines that the risk is 0 when both conditions are not satisfied. When the degree of risk is 1, the CPU 11 outputs information indicating that there is a danger (hereinafter referred to as danger information) to the mobile phone 2 of the automobile heading for the intersection. When the degree of risk is 1, the CPU 11 refers to the travel DB 152 and outputs the position and moving direction of the mobile phone 3 (bicycle) to the mobile phone 2. The CPU 21 of the mobile phone 2 receives the danger information, the position, and the moving direction. The CPU 21 of the mobile phone 2 displays danger information and a bicycle image on the display unit 24.

  FIG. 10 is an explanatory view showing a display image of danger information displayed on the display unit 24. The CPU 21 displays an image of the bicycle and an arrow indicating the moving direction near the intersection of the display unit 24 based on the received position and moving direction. In the example of FIG. 10, an image of a bicycle heading from the left side to the right side of the intersection is shown. The CPU 21 displays danger information on the display unit 24. As the danger information, for example, a text sentence such as “Warning! A car is approaching an intersection” may be displayed. In addition, the CPU 21 may output the danger information from the speaker 211 by voice.

  In addition, the determination process of a risk level is an example and is not restricted to this. The CPU 11 may determine whether the moving speed exceeds the reference speed or the average speed and the ratio stored in the stop history DB 155 is equal to or less than the threshold value stored in the storage unit 15. The threshold is 0.8, for example. The CPU 11 may set the risk level 1 when both of these conditions are satisfied. Further, the CPU 11 may output the degree of danger to the mobile phone 2. The CPU 21 of the mobile phone 2 outputs danger information to the display unit 24 when the danger level is 1. In the following embodiment, an example in which the degree of risk is output to the mobile phone 2 will be described.

  Software processing in the above hardware group will be described using a flowchart. FIG. 11 is a flowchart showing a procedure for recording the running state of the bicycle. The CPU 31 of the mobile phone 3 owned by the bicycle user transmits the latitude and longitude output from the GPS module 39 and the bicycle user ID read from the storage unit 35 to the server computer 1 via the communication unit 36. CPU31 transmits such information regularly (for example, every 5 seconds). The CPU 11 of the server computer 1 receives the user ID, latitude, and longitude (step S111). The CPU 11 stores the bicycle user ID, latitude, and longitude in the travel DB 152 (step S112).

  The CPU 11 stores the time output from the clock unit 18 in association with the bicycle user ID (step S113). Note that the time output from the mobile phone 3 may be stored. The CPU 11 reads the previous latitude, longitude, and time in a time series corresponding to the user ID. The CPU 11 calculates the difference between the stored time and the read time. The CPU 11 calculates the distance based on the stored latitude and longitude and the read latitude and longitude. The CPU 11 calculates a moving speed from the calculated distance and time difference (step S114). This process may be executed when there are two or more combinations of latitude and longitude.

  The CPU 11 calculates a moving direction based on the stored latitude and longitude and the read latitude and longitude (step S115). The CPU 11 specifies the route ID by referring to the map DB 151 based on the stored latitude and longitude and the moving direction (step S116). The CPU 11 stores the identified route ID in the travel DB 152 (step S117). The CPU 11 reads the intersection ID corresponding to the route ID from the map DB 151, and stores the intersection ID read in association with the bicycle user ID in the travel DB 152 (step S118).

  The CPU 11 reads out the latitude and longitude corresponding to the intersection ID from the map DB 151. The CPU 11 calculates the distance to the intersection from the latitude and longitude of the read intersection and the stored current latitude and longitude (step S119). The CPU 11 calculates a predicted arrival time based on the calculated distance and moving speed (step S1110). The CPU 11 stores the calculated predicted arrival time in the travel DB 152 in association with the bicycle user ID (step S1111).

  FIG. 12 is a flowchart showing the procedure of the stop event storage process. The CPU 11 performs the following processing in parallel with the processing described in FIG. The CPU 11 stores the time, latitude, longitude, route ID, and intersection ID in the stop DB 153 in association with the bicycle user ID. CPU11 judges whether the distance to an intersection is below the threshold memorized by storage part 15 (Step S121). This threshold value may be 2 m, for example. Specifically, the CPU 11 calculates the distance based on the latitude and longitude corresponding to the intersection ID and the stored current latitude and longitude. The CPU 11 determines whether the calculated distance is equal to or less than a threshold value.

  If the CPU 11 determines that it is not less than the threshold value (NO in step S121), the process ends. If the CPU 11 determines that the value is equal to or less than the threshold value (YES in step S121), the CPU 11 determines that the vehicle is approaching an intersection and shifts the process to step S122. The CPU 11 determines whether or not the moving speed is equal to or lower than a predetermined speed (step S122). The predetermined speed is stored in advance in the storage unit 15 and may be set to 0 or 1 km / h, for example.

  If the CPU 11 determines that the speed is equal to or less than the predetermined speed (YES in step S122), the process proceeds to step S123. The CPU 11 stores information indicating the stop in the stop DB 153 in association with the bicycle user ID (step S123). If the CPU 11 determines that the speed is not less than the predetermined speed (NO in step S122), the CPU 11 assumes that the vehicle has not stopped at the intersection, skips the process in step S123, and ends the process.

  FIG. 13 and FIG. 14 are flowcharts showing the travel history storage processing procedure. CPU11 performs the process which memorize | stores the log | history of driving | running | working DB152 for every predetermined time (for example, every 2 hours) or for every predetermined day (for example, every day). In the present embodiment, for ease of explanation, an example will be described in which the history of each time zone is stored at the end of the day without considering the day of the week. The CPU 11 refers to the travel DB 152 and determines whether or not the bicycle user ID and the route are stored in the same time zone (step S131). If the CPU 11 determines that it is not stored (NO in step S131), it shifts the process to step S143 because there is no travel history.

  If the CPU 11 determines that it is stored (YES in step S131), the CPU 11 increments the total number of travels corresponding to the time zone, the bicycle user ID, and the route ID in the travel history DB 154 (step S132). The CPU 11 refers to the travel DB 152 and reads the movement speed in the same time zone (step S133). Based on the read moving speed and the number of moving speeds, the CPU 11 calculates today's average speed for the time period (step S134). CPU11 memorize | stores today's average speed of the said time slot | zone in the memory | storage part 15 (step S135). Specifically, the CPU 11 sequentially stores the calculated average speed, date, and time zone in the storage unit 15 as a history. Similarly, the CPU 11 reads the past average speed stored in the storage unit 15 in the same time period (step S136). CPU11 calculates the average speed of the whole time slot | zone based on the number and average speed of the read average speed (step S137).

  The CPU 11 stores the calculated average speed in the travel history DB 154 in association with the total number of travels (step S138). The CPU 11 calculates a standard deviation based on today's average speed calculated in step S134 and the past average speed read in step S136 (step S139). The CPU 11 calculates the reference speed by doubling the standard deviation and adding the doubled value to the average speed calculated in step S137 (step S141). The CPU 11 stores the calculated reference speed in the travel history DB 154 in association with the total number of travels (step S142).

  CPU11 judges whether the process was complete | finished about all the time slots (step S143). If the CPU 11 determines that the process has not been completed for all the time zones (NO in step S143), the process proceeds to step S144. The CPU 11 changes the time zone (step S144). Thereafter, the CPU 11 returns the process to step S131. For example, when the processing of the time zone from 6 o'clock to 8 o'clock is finished, the processing of the time zone from 9 o'clock to 11 o'clock is performed. If the CPU 11 determines that the processing has been completed for all the time zones (YES in step S143), the series of processing ends.

  FIG. 15 is a flowchart showing a stop count storage processing procedure. The CPU 11 performs the following processing in parallel with the processing in FIGS. 13 and 14. The CPU 11 determines whether or not the total number of travels has been incremented in step S132 (step S151). If the CPU 11 determines that it has not been incremented (NO in step S151), the process proceeds to step S154. If the CPU 11 determines that the increment has been made (YES in step S151), the process proceeds to step S152. The CPU 11 stores the total number of travels after the increment in the stop history DB 155 in association with the time zone, the route ID, and the bicycle user ID. The CPU 11 refers to the stop DB 153 to determine whether or not a stop is stored in the same time zone on the same route (step S152).

  If the CPU 11 determines that the stop is not stored (NO in step S152), the process proceeds to step S154. If the CPU 11 determines that the stop is stored (YES in step S152), the process proceeds to step S153. The CPU 11 increments the number of stops corresponding to the total number of runs in the stop history DB 155 (step S153). After step S153, if NO in S151 or NO in S152, the CPU 11 calculates the ratio by dividing the number of stops by the total number of travels (step S154). The CPU 11 stores (updates) the ratio of the stop history DB 155 by associating the calculated ratio with the total number of runs.

  FIG. 16 is a flowchart showing the procedure of risk determination processing. The CPU 11 acquires the actual time (hereinafter referred to as the current time) from the clock unit 18. The CPU 11 acquires, from the travel DB 152, the bicycle user ID, the route ID, and the moving speed whose time difference obtained by subtracting the current time from the predicted arrival time at the intersection stored in the travel DB 152 is a predetermined time or less (step S161). The predetermined time may be 5 seconds, for example. The CPU 11 refers to the route ID and the bicycle user ID from the travel history DB 154, and acquires a reference speed in the same time zone as the current time (step S162). The CPU 11 refers to the route ID and the bicycle user ID from the stop history DB 155, and acquires the ratio of the same time zone as the current time (step S163).

  The CPU 11 determines whether or not the moving speed exceeds the reference speed (step S164). If the CPU 11 determines that the reference speed is not exceeded (NO in step S164), the process proceeds to step S168. If the CPU 11 determines that the reference speed is exceeded (YES in step S164), the process proceeds to step S165. CPU11 reads a threshold value from the memory | storage part 15 (step S165). This threshold value is stored as, for example, 0.99. The CPU 11 determines whether or not the acquired ratio exceeds a threshold value (less than 0.99) (step S166). If the CPU 11 determines that the threshold value is exceeded (YES in step S166), the process proceeds to step S167.

  If the CPU 11 determines that the threshold value is not exceeded (NO in step S166), the process proceeds to step S168. If YES in step S166, the CPU 11 determines the degree of risk as 1 (step S167). On the other hand, if NO in step S166 and NO in step S164, CPU 11 determines the degree of risk as 0 (step S168). The CPU 11 outputs the determined risk level to the RAM 12 (step S169). The CPU 11 stores it in the RAM 12 in association with the risk level, the intersection ID, the bicycle user ID, the route ID, and the moving direction. Note that the CPU 11 may output the degree of risk to the display unit 14 or the communication unit 16. In the present embodiment, the determination process in step S164 is performed first. However, the process in step S166 may be performed first, and the order thereof does not matter.

  17 and 18 are flowcharts showing the procedure of the danger level output process. The CPU 21 of the mobile phone 2 present in the automobile acquires the current time from the clock unit 28. It is assumed that the CPU 21 of the portable electric machine 2 has activated car navigation software. The CPU 21 determines whether or not the time difference obtained by subtracting the current time from the predicted arrival time at the intersection of the automobile itself is within a predetermined time (step S171). Note that the predicted arrival time may be calculated by the car navigation software of the mobile phone 2. If the CPU 21 determines that it is not within the predetermined time (NO in step S171), the process is terminated. The predetermined time is stored in the storage unit 25 and is, for example, 5 seconds. If the CPU 21 determines that the time is within the predetermined time (YES in step S171), the process proceeds to step S172.

  The CPU 21 outputs the risk level acquisition request and the intersection ID to the server computer 1 via the communication unit 26 (step S172). The CPU 11 of the server computer 1 receives the risk degree acquisition request and the intersection ID via the communication unit 16 (step S173). The CPU 11 performs the risk determination process by performing the process described with reference to FIG. 16 for the received intersection ID. After the processing, the CPU 11 determines whether or not the degree of risk, the route ID, and the moving direction are stored in the RAM 12 (step S174). When the CPU 11 determines that the degree of danger or the like is not stored (NO in step S174), the CPU 11 ends the process assuming that there is no bicycle heading to the intersection.

  If the CPU 11 determines that the degree of danger or the like is stored (YES in step S174), the process proceeds to step S175. The CPU 11 outputs the risk level, the route ID, and the moving direction stored in the RAM 12 to the mobile phone 2 via the communication unit 16 (step S175). The CPU 21 of the mobile phone 2 receives the degree of risk, the route ID, and the moving direction via the communication unit 26 (step S176). The CPU 21 of the mobile phone 2 can recognize the existence of a bicycle heading to the same intersection soon.

  The CPU 21 determines whether or not the risk level is 1 (step S177). If the CPU 21 determines that the degree of risk is not 1 (NO in step S177), the CPU 21 ends the process because it is not necessary to output the danger information. If the CPU 21 determines that the degree of risk is 1 (YES in step S177), the process proceeds to step S178. CPU21 reads a bicycle icon from the memory | storage part 25 (step S178). The CPU 21 displays a bicycle icon on the display unit 24 near the intersection on the road corresponding to the route ID (step S179).

  CPU21 displays the arrow which shows a moving direction on the display part 24 in the bicycle icon vicinity on a road (step S181). CPU21 reads the danger information which is an audio | voice file from the memory | storage part 25 (step S182). The CPU 21 outputs the read danger information from the speaker 211 (step S183). Accordingly, it is possible to provide information on the actual situation to the user of the car according to not only the current speed of the bicycle but also the past traveling speed and the stop state at the intersection.

Embodiment 2
The second embodiment relates to a mode in which the degree of risk is determined on the mobile phone 2 side of the automobile. 19 and 20 are flowcharts showing the procedure for determining the degree of risk. The CPU 21 of the mobile phone 2 activates the car navigation software and executes the control program 25P to perform the following processing. The CPU 21 of the mobile phone 2 present in the automobile acquires the current time from the clock unit 28. The CPU 21 determines whether or not the time difference obtained by subtracting the current time from the predicted arrival time at the intersection of the automobile itself is within a predetermined time or less (step S191). Note that the predicted arrival time may be calculated by the car navigation software of the mobile phone 2. If the CPU 21 determines that it is not within the predetermined time (NO in step S191), it ends the process. The predetermined time is stored in the storage unit 25 and is, for example, 5 seconds. When the CPU 21 determines that the time is within the predetermined time (YES in step S191), the CPU 21 proceeds to step S192.

  CPU21 reads intersection ID from map DB (not shown) in car navigation software. The CPU 21 outputs the information acquisition request and the intersection ID to the server computer 1 via the communication unit 26 (step S192). The CPU 11 of the server computer 1 receives the information acquisition request and the intersection ID (step S193). The CPU 11 acquires, from the travel DB 152, the bicycle user ID, the route ID, and the moving speed whose time difference obtained by subtracting the current time from the predicted arrival time at the intersection stored in the travel DB 152 is equal to or less than a predetermined time (step S194). The predetermined time may be 5 seconds, for example.

  The CPU 11 refers to the route ID and the bicycle user ID from the travel history DB 154 and acquires a reference speed in the same time zone as the current time (step S195). The CPU 11 refers to the route ID and the bicycle user ID from the stop history DB 155, and acquires the ratio of the same time zone as the current time (step S196). Thereby, the moving speed, reference speed, and ratio of the bicycle approaching the same intersection as the automobile can be acquired.

  The CPU 11 outputs the route ID, the moving direction, and the time difference acquired in step S194 to the mobile phone 2 (step S197). The moving direction can be acquired by referring to the map DB 151 based on the route ID. The CPU 11 outputs the moving speed and the reference speed to the mobile phone 2 (Step S198). CPU11 outputs a ratio to the mobile telephone 2 (step S199).

  The CPU 21 of the mobile phone 2 acquires the route ID, the moving direction, and the time difference via the communication unit 26 (step S201). CPU21 acquires a moving speed and a reference speed via the communication part 26 (step S202). CPU21 acquires a ratio via the communication part 26 (step S203).

  The CPU 21 determines whether or not the moving speed exceeds the reference speed (step S204). If the CPU 21 determines that the reference speed is not exceeded (NO in step S204), the process proceeds to step S208. If the CPU 21 determines that the reference speed is exceeded (YES in step S204), the process proceeds to step S205. CPU21 reads a threshold value from the memory | storage part 25 (step S205). This threshold value is stored as, for example, 0.99. The CPU 21 determines whether or not the acquired ratio exceeds the threshold (less than 0.99) (step S206). If the CPU 21 determines that the threshold value is exceeded (YES in step S206), the process proceeds to step S207.

  If the CPU 21 determines that the threshold value is not exceeded (NO in step S206), the process proceeds to step S208. If YES in step S206, the CPU 21 determines the risk level as 1 and stores the risk level 1 in the RAM 12 (step S207). On the other hand, if NO in step S206 and NO in step S204, CPU 21 determines the risk level as 0 and stores the risk level 0 in RAM 12 (step S208).

  The CPU 21 outputs the degree of risk stored in the RAM 12 (step S2080). The CPU 21 determines whether or not the output risk level is 1 (step S209). If the CPU 21 determines that the degree of risk is not 1 (NO in step S209), the CPU 21 ends the process because it is not necessary to output the danger information. If the CPU 21 determines that the degree of risk is 1 (YES in step S209), the process proceeds to step S2010. CPU21 reads a bicycle icon from the memory | storage part 25 (step S2010). The CPU 21 displays a bicycle icon on the display unit 24 near the intersection on the road corresponding to the route ID (step S2011).

  CPU21 displays the arrow which shows a moving direction on the display part 24 in the bicycle icon vicinity on a road (step S2012). CPU21 reads the danger information which is an audio | voice file from the memory | storage part 25 (step S2013). The CPU 21 outputs the read danger information from the speaker 211 (step S2014). Thereby, it is possible to provide information corresponding to the actual traveling condition of the bicycle to the driver of the automobile even by performing many processes on the automobile side.

  The second embodiment is as described above, and the other parts are the same as those of the first embodiment. Therefore, the corresponding parts are denoted by the same reference numerals, and detailed description thereof is omitted.

Embodiment 3
The third embodiment relates to a mode in which the degree of risk is determined in consideration of the time difference. FIG. 21 is an explanatory diagram showing a hardware group of the server computer 1 according to the third embodiment. The storage unit 15 is provided with a risk level table 156. FIG. 22 is an explanatory diagram showing a record layout of the risk level table 156. The risk level table 156 has a first risk level field and a second risk level field. The first risk field indicates the risk determined in the first and second embodiments. That is, the first risk level is a risk level determined based on whether the moving speed exceeds the reference speed (or average speed) and whether the ratio exceeds the threshold value.

  The second risk level is a risk level determined by the time difference between the predicted arrival time of the mobile phone 3 (bicycle) and the predicted arrival time of the automobile itself. The second risk level may be a risk level determined by the time difference obtained by subtracting the current time from the predicted arrival time of the mobile phone 3 (bicycle). The second risk is a value that increases as the time difference is smaller. For example, when the time difference is 5 seconds or more, the second risk is set to zero. When the time difference is 3 seconds or more and less than 5 seconds, the second risk is set to 1. If the time difference is less than 3 seconds, the risk is 2. The CPU 11 reads out the risk type determined by the matrix of the first risk level and the second risk level. The risk level table 156 normally stores three risk types: caution and warning.

  There are three types of danger information indicating that there is a danger corresponding to the danger type, for example, warning information, caution information, and normal information. When the first risk level and the second risk level are high, for example, when the first risk level is 1 and the second risk level is 2, a warning is selected. When the warning is selected, the danger information described in the first and second embodiments (hereinafter referred to as warning information) is output. For example, voice information such as “Warning! A bicycle is approaching the intersection” is output. When the first risk level and the second risk level are slightly high, for example, when the first risk level is 0 and the second risk level is 2, attention is selected.

  When attention is selected, information that is less urgent than warning information (hereinafter referred to as attention information) is output. For example, voice information such as “Caution. A bicycle is approaching the intersection” is output. When the first risk level and the second risk level are low, for example, when the first risk level is 0 and the second risk level is also 0, normal is selected. When normal is selected, information that is less urgent than attention information (hereinafter referred to as normal information) is output. For example, voice information such as “A bicycle is approaching the intersection” is output. The example of the risk level table 156 is an example, and the present invention is not limited to this. The risk level and risk type may be further classified. In this embodiment, an example using a table is given, but it goes without saying that the same processing may be performed by a program.

  23 and 24 are flowcharts showing the danger information output processing procedure. The CPU 21 of the mobile phone 2 present in the automobile acquires the current time from the clock unit 28. The CPU 21 determines whether or not the time difference obtained by subtracting the current time from the predicted arrival time at the intersection of the automobile itself is within a predetermined time (step S231). If the CPU 21 determines that it is not within the predetermined time (NO in step S231), it ends the process. The predetermined time is stored in the storage unit 25. If the CPU 21 determines that it is within the predetermined time (YES in step S231), the CPU 21 proceeds to step S232.

  CPU21 reads intersection ID from map DB (not shown) in car navigation software. The CPU 21 outputs the information acquisition request and the intersection ID to the server computer 1 via the communication unit 26 (step S232). The CPU 11 of the server computer 1 receives the information acquisition request and the intersection ID (step S233). The CPU 11 acquires, from the travel DB 152, the bicycle user ID, the route ID, and the moving speed that are obtained by subtracting the current time from the predicted arrival time at the intersection stored in the travel DB 152 for a predetermined time or less (for example, 7 seconds or less) (step S234). ). The CPU 11 stores the calculated time difference in the RAM 12.

  The CPU 11 refers to the route ID and the bicycle user ID from the travel history DB 154, and acquires a reference speed in the same time zone as the current time (step S235). The CPU 11 refers to the route ID and the bicycle user ID from the stop history DB 155, and acquires the ratio of the same time zone as the current time (step S236). The CPU 11 determines whether or not the moving speed exceeds the reference speed (step S237). If the CPU 11 determines that the reference speed is not exceeded (NO in step S237), the process proceeds to step S242. If the CPU 11 determines that the reference speed is exceeded (YES in step S237), the process proceeds to step S238. CPU11 reads a threshold value from the memory | storage part 25 (step S238). This threshold value is stored as, for example, 0.99. The CPU 11 determines whether or not the acquired ratio exceeds the threshold (less than 0.99) (step S239). If the CPU 11 determines that the threshold value is exceeded (YES in step S239), the process proceeds to step S241.

  If the CPU 11 determines that the threshold is not exceeded (NO in step S239), the process proceeds to step S242. If YES in step S239, the CPU 11 determines the first risk level as 1, and stores the first risk level 1 in the RAM 12 (step S241). On the other hand, if NO in step S239 and NO in step S237, the CPU 11 determines the first risk level as 0 and stores the first risk level 0 in the RAM 12 (step S242).

  The CPU 11 reads the time difference stored in the RAM 12. The CPU 11 determines the second risk level based on the time difference, and stores the second risk level in the RAM 12 (step S243). The relationship between the time difference and the second risk level is as described above. The CPU 11 outputs the first risk level and the second risk level determined from the RAM 12, and reads the risk type from the risk level table 156 based on the output first risk level and second risk level (step S244).

  CPU11 outputs danger classification, route ID, and a moving direction to the mobile telephone 2 (step S245). CPU11 acquires danger classification, route ID, and a moving direction (step S246). CPU21 reads a bicycle icon from the memory | storage part 25 (step S247). The CPU 21 displays a bicycle icon on the display unit 24 near the intersection on the road corresponding to the route ID (step S248).

  CPU21 displays the arrow which shows a moving direction on the display part 24 in the bicycle icon vicinity on a road (step S249). The CPU 21 outputs warning information, caution information, or normal information stored in the storage unit 25 in accordance with the risk type from the speaker 211 (step S2411). Instead of outputting from the speaker 211, the danger type or danger information may be displayed on the display unit 24. Moreover, although the example which acquires a danger classification was shown in step S246, it is not restricted to this. The CPU 11 may output the first risk level and the second risk level to the mobile phone 2. The CPU 21 may output the acquired first risk level and second risk level from the display unit 24 or the speaker 211. As a result, it is possible to provide more detailed risk information according to the situation.

  The third embodiment is as described above, and the others are the same as in the first and second embodiments. Therefore, the corresponding parts are denoted by the same reference numerals, and detailed description thereof is omitted.

Embodiment 4
The fourth embodiment relates to a mode in which part of the processing described in the third embodiment is executed on the mobile phone 2 side of the automobile. FIG. 25 is a block diagram illustrating a hardware group of the mobile phone 2 according to the fourth embodiment. The storage unit 25 stores a risk level table 256.

  26 and 27 are flowcharts showing the danger information output processing procedure. The CPU 21 of the mobile phone 2 present in the automobile acquires the current time from the clock unit 28. The CPU 21 determines whether or not the time difference obtained by subtracting the current time from the predicted arrival time at the intersection of the automobile itself is within a predetermined time (step S261). If the CPU 21 determines that it is not within the predetermined time (NO in step S261), it ends the process. The predetermined time is stored in the storage unit 25. If the CPU 21 determines that it is within the predetermined time (YES in step S261), the process proceeds to step S262.

  CPU21 reads intersection ID from map DB (not shown) in car navigation software. The CPU 21 outputs the information acquisition request and the intersection ID to the server computer 1 via the communication unit 26 (step S262). The CPU 11 of the server computer 1 receives the information acquisition request and the intersection ID (step S263). The CPU 11 acquires, from the travel DB 152, the bicycle user ID, the route ID, and the moving speed when the time difference obtained by subtracting the current time from the predicted arrival time at the intersection stored in the travel DB 152 is a predetermined time or less (eg, 7 seconds or less) (step S264) ). The CPU 11 stores the calculated time difference in the RAM 12.

  The CPU 11 refers to the route ID and the bicycle user ID from the travel history DB 154, and acquires a reference speed in the same time zone as the current time (step S265). The CPU 11 refers to the route ID and the bicycle user ID from the stop history DB 155, and acquires the ratio of the same time zone as the current time (step S266). CPU11 outputs path | route ID, a moving direction, and a time difference to the mobile telephone 2 (step S267). The CPU 11 outputs the moving speed, the reference speed, and the ratio to the mobile phone 2 (Step S268).

  CPU21 acquires route ID, a moving direction, and a time difference (step S269). CPU21 acquires a moving speed, a reference speed, and a ratio (step S271). The CPU 21 determines whether or not the moving speed exceeds the reference speed (step S272). If the CPU 21 determines that the reference speed is not exceeded (NO in step S272), the process proceeds to step S276. If the CPU 21 determines that the reference speed is exceeded (YES in step S272), the process proceeds to step S273. CPU11 reads a threshold value from the memory | storage part 25 (step S273). This threshold value is stored as, for example, 0.99. CPU21 judges whether the acquired ratio exceeds a threshold value (less than 0.99) (step S274). When CPU 21 determines that the threshold value is exceeded (YES in step S274), the process proceeds to step S275.

  If the CPU 21 determines that the threshold value is not exceeded (NO in step S274), the process proceeds to step S276. If YES in step S274, the CPU 21 determines the first risk level as 1, and stores the first risk level 1 in the RAM 22 (step S275). On the other hand, if NO in step S274 and NO in step S272, CPU 21 determines the first risk level as 0 and stores the first risk level 0 in RAM 22 (step S276).

  The CPU 21 determines the second risk level based on the acquired time difference, and stores the second risk level in the RAM 22 (step S277). The CPU 21 outputs the first risk level and the second risk level determined from the RAM 22, and reads the risk type from the risk level table 256 based on the output first risk level and second risk level (step S278).

  CPU21 reads a bicycle icon from the memory | storage part 25 (step S279). The CPU 21 displays a bicycle icon on the display unit 24 in the vicinity of the intersection on the road corresponding to the route ID (step S2711).

  CPU21 displays the arrow which shows a moving direction on the display part 24 in the bicycle icon vicinity on a road (step S2712). The CPU 21 outputs warning information, caution information, or normal information stored in the storage unit 25 according to the risk type from the speaker 211 (step S2713). Instead of outputting from the speaker 211, the danger type or danger information may be displayed on the display unit 24. As a result, even when the control is performed on the mobile phone 2 side, it is possible to provide more detailed danger information depending on the situation.

  The fourth embodiment is as described above, and the others are the same as those of the first embodiment. Therefore, the corresponding parts are denoted by the same reference numerals, and detailed description thereof is omitted.

Embodiment 5
FIG. 28 is a functional block diagram showing the operation of the server computer 1 of the above-described form. When the CPU 11 executes the control program 15P, the server computer 1 operates as follows. The first acquisition unit 101 acquires the speed of the bicycle approaching the intersection. The second acquisition unit 102 acquires the average speed and stop state of the bicycle read from the storage unit 15 that stores the past average speed of the bicycle and the stop state at the intersection. The determination unit 103 determines the degree of risk based on the acquired speed, average speed, and stop status. The output unit 104 outputs the determined risk level. Since the mobile phone 2 also performs the above-described function, detailed description is omitted.

  FIG. 29 is a block diagram illustrating a hardware group of the server computer 1 according to the fifth embodiment. A program for operating the server computer 1 reads a portable recording medium 1A such as a CD-ROM, a DVD (Digital Versatile Disc) disk, a memory card, or a USB (Universal Serial Bus) memory into a reading unit 10A such as a disk drive. It may be stored in the storage unit 15. Further, a semiconductor memory 1B such as a flash memory storing the program may be mounted in the personal computer 1. Further, the program can be downloaded from another server computer (not shown) connected via a communication network N such as the Internet. The contents will be described below.

  The server computer 1 shown in FIG. 29 reads a program for executing the above-described various software processes from the portable recording medium 1A or the semiconductor memory 1B, or from another server computer (not shown) via the communication network N. to download. The program is installed as the control program 15P, loaded into the RAM 12, and executed. Thereby, it functions as the server computer 1 described above.

  FIG. 30 is a block diagram illustrating a hardware group of the mobile phone 2 according to the fifth embodiment. A program for operating the cellular phone 2 is stored in the storage unit 25 by causing the reading unit 20A such as a disk drive to read the portable recording medium 2A such as a CD-ROM, a DVD disk, a memory card, or a USB memory. Also good. Further, a semiconductor memory 2B such as a flash memory storing the program may be mounted in the mobile phone 2. Further, the program can be downloaded from another server computer (not shown) connected via a communication network N such as the Internet. The contents will be described below.

  The cellular phone 2 shown in FIG. 30 reads a program for executing the above-described various software processes from the portable recording medium 2A or the semiconductor memory 2B or from another server computer (not shown) via the communication network N. to download. The program is installed as the control program 25P, loaded into the RAM 22, and executed. Thus, the mobile phone 2 functions as described above.

  The fifth embodiment is as described above, and the other parts are the same as those of the first to fourth embodiments. Therefore, the corresponding parts are denoted by the same reference numerals and detailed description thereof is omitted.

  With respect to the embodiments including the first to fifth embodiments, the following additional notes are disclosed.

(Appendix 1)
To a computer having a control unit,
The speed of the bicycle approaching the intersection is acquired by the control unit,
The average speed and stop state of the bicycle read from the storage unit storing the past average speed of the bicycle and the stop state at the intersection are acquired by the control unit,
Based on the acquired speed, average speed and stop situation, the control unit determines the risk,
A program for executing a process of outputting the determined risk level by the control unit.

(Appendix 2)
The stop situation is
The rate at which the bicycle once stopped and passed at the intersection,
The program according to claim 1, wherein the risk is determined based on the acquired speed, average speed, and the ratio.

(Appendix 3)
The risk is
The program according to claim 2, wherein the risk is determined based on the acquired speed, the reference speed obtained by multiplying the average speed by a coefficient stored in the storage unit, and the ratio.

(Appendix 4)
The risk is
The program according to attachment 3, wherein the program is determined based on whether or not the acquired speed exceeds a reference speed and whether or not the ratio exceeds a threshold value.

(Appendix 5)
The program according to any one of supplementary notes 1 to 4, wherein information indicating that there is a risk is output to the display unit based on the determined risk level.

(Appendix 6)
The program according to any one of appendices 1 to 4, wherein information indicating that a danger exists based on the determined degree of danger is output to a device existing in a vehicle approaching the intersection.

(Appendix 7)
Obtain the time difference obtained by subtracting the difference in real time from the predicted arrival time of the bicycle to the intersection,
The risk is
The program according to appendix 3 or 4, wherein the degree of danger is determined based on the acquired speed, average speed or reference speed, stop status and time difference.

(Appendix 8)
The risk is
The program according to claim 7, wherein the program is determined based on whether or not the acquired speed exceeds an average speed or a reference speed, whether or not the ratio exceeds a threshold, and the time difference.

(Appendix 9)
A first acquisition unit for acquiring the speed of the bicycle approaching the intersection;
A second acquisition unit that acquires the average speed and stop state of the bicycle read from a storage unit that stores the past average speed of the bicycle and the stop state at the intersection;
A determination unit that determines the degree of risk based on the acquired speed, average speed, and stop condition;
An information processing apparatus comprising: an output unit that outputs the determined risk level.

(Appendix 10)
In an information processing method using a computer having a control unit,
The speed of the bicycle approaching the intersection is acquired by the control unit,
The average speed and stop state of the bicycle read from the storage unit storing the past average speed of the bicycle and the stop state at the intersection are acquired by the control unit,
Based on the acquired speed, average speed and stop situation, the control unit determines the risk,
An information processing method including a process of outputting the determined risk level by the control unit.

DESCRIPTION OF SYMBOLS 1 Server computer 1A Portable recording medium 1B Semiconductor memory 2 Mobile phone 2A Portable recording medium 2B Semiconductor memory 3 Mobile phone 10A Reading part 20A Reading part 11 CPU
12 RAM
13 Input unit 14 Display unit 15 Storage unit 15P Control program 16 Communication unit 18 Clock unit 21 CPU
22 RAM
23 Input unit 24 Display unit 25 Storage unit 25P Control program 26 Communication unit 28 Clock unit 29 GPS module 31 CPU
32 RAM
33 Input unit 34 Display unit 35 Storage unit 35P Control program 36 Communication unit 38 Clock unit 39 GPS module 101 First acquisition unit 102 Second acquisition unit 103 Determination unit 104 Output unit 151 Map DB
152 Travel DB
153 Stop DB
154 Travel history DB
155 Stop history DB
156 Risk level table 212 Acceleration sensor 210 Microphone 211 Speaker 256 Risk level table 312 Acceleration sensor 310 Microphone 311 Speaker N Communication network

Claims (6)

To a computer having a control unit,
The speed of the bicycle approaching the intersection is acquired by the control unit,
The average speed and stop state of the bicycle read from the storage unit storing the past average speed of the bicycle and the stop state at the intersection are acquired by the control unit,
Based on the acquired speed, average speed and stop situation, the control unit determines the first risk,
A second risk is determined based on a time difference obtained by subtracting a difference in real time from the predicted arrival time of the bicycle at the intersection;
A program for executing a process of outputting, by the control unit, a risk determined based on the determined first risk and second risk. The stop situation is
The rate at which the bicycle once stopped and passed at the intersection,
The first risk is acquired speed, average speed, and program according to claim 1 for determining a first risk based on the ratio. The first risk is
The program according to claim 2, wherein the first risk is determined based on the acquired speed, the reference speed obtained by multiplying the average speed by a coefficient stored in a storage unit, and the ratio. The first risk is
The program according to claim 3, wherein the program is determined based on whether or not the acquired speed exceeds a reference speed, and whether or not the ratio exceeds a threshold value. A first acquisition unit for acquiring the speed of the bicycle approaching the intersection;
A second acquisition unit that acquires the average speed and stop state of the bicycle read from a storage unit that stores the past average speed of the bicycle and the stop state at the intersection;
A first determination unit that determines a first risk based on the acquired speed, average speed, and stop state;
A second determination unit that determines a second risk based on a time difference obtained by subtracting a difference in real time from the predicted arrival time of the bicycle to the intersection;
An information processing apparatus comprising: an output unit that outputs a risk determined based on the determined first risk and second risk. In an information processing method using a computer having a control unit,
The speed of the bicycle approaching the intersection is acquired by the control unit,
The average speed and stop state of the bicycle read from the storage unit storing the past average speed of the bicycle and the stop state at the intersection are acquired by the control unit,
Based on the acquired speed, average speed and stop situation, the control unit determines the first risk,
A second risk is determined based on a time difference obtained by subtracting a difference in real time from the predicted arrival time of the bicycle at the intersection;
An information processing method including a process of outputting, by the control unit, a risk determined based on the determined first risk and second risk.

Images