JP2004094444A - Information processing method for preventing traffic accident - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an information processing technology to issue proper warning suitable for the characteristics of each driver for preventing a traffic accident. <P>SOLUTION: User attributes being the characteristics of each system user are extracted, and the current or passage scheduled location information of the system user is acquired. The information of a traffic accident information data base including the location information of the accident site and the attribute information of the person concerned associated with the location information is retrieved by using the current or passage scheduled location information of the system user and the acquired user attribute. When the traffic accident information is extracted by retrieval, the extracted traffic information is narrowed down, and stored in an information storing part. Thus, it is possible to extract accident information suitable for the characteristics of each driver. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a technology for processing information for preventing traffic accidents.
[0002]
[Prior art]
For example, Japanese Patent Application Laid-Open No. H11-120478 discloses the following technology. In other words, the prediction of traffic accidents is based on the fact that past history information is stored in the database of the traffic accident management center, and vehicle information (location, topography, traveling speed, traffic volume, season, time, weather, temperature, Humidity, etc.), calculate the probability of a traffic accident occurring, and notify the warning information (= traffic accident prediction information) according to the situation by voice or image to prevent the occurrence of a traffic accident. prevent.
[0003]
When a traffic accident is encountered, it is possible to grasp the accident situation by reading the history information of the running vehicle from the contents of the IC card at the time of the on-site inspection by a police officer. By linking with the license information at that time, it is possible to calculate the deduction of license points, collect fines and fines, and manage driving qualifications such as license points.
[0004]
[Problems to be solved by the invention]
On the other hand, the causes of traffic accidents are also closely related to driver attributes such as the driver's gender, age, and driver's license holding days, and it is necessary to consider driver attributes in order to provide appropriate warning information. There is. However, in the related art, a viewpoint of providing traffic accident danger information according to a driver attribute in addition to a situation of a vehicle is not disclosed.
[0005]
Therefore, an object of the present invention is to provide an information processing technique for giving an appropriate warning according to the characteristics of each driver to prevent a traffic accident.
[0006]
[Means for Solving the Problems]
According to a first aspect of the present invention, there is provided an information processing method for preventing traffic accidents, wherein a user attribute which is a characteristic of a system user is acquired and stored in a storage device. Information of a traffic accident information database including the position information obtaining step of obtaining current or scheduled position information of the vehicle and storing it in the storage device, and the position information of the accident site and the attribute information of the accident party associated with the position information A search step for searching using the current or planned location information of the system user and the acquired user attributes, and, if the traffic accident information is extracted by the search, narrows down the extracted traffic accident information. Storing in the information storage unit. As a result, it becomes possible to obtain and provide information relating to a traffic accident suitable for the system user for each system user.
[0007]
Further, in the first aspect of the present invention, the method further includes a step of acquiring at least one of the vehicle type information, the traffic congestion information, the weather information, and the date and time, and storing the acquired information in a storage device. The configuration may be such that the search is performed by further using at least one of the vehicle type information, the traffic congestion information, the weather information, and the date and time information. By performing a search in consideration of the situation and environment of the vehicle in addition to the user attributes, it is possible to obtain and provide more accurate information indicating the possibility of an accident.
[0008]
Further, in the first aspect of the present invention, the configuration may further include a step of generating a warning message using the information stored in the above-described narrowed-down information storage unit and storing the generated warning message in the storage device. . More clear and concise messages will help you avoid accidents.
[0009]
Further, the configuration may include a step of transmitting the above-mentioned warning message stored in the storage device to the terminal of the system user. In addition to the configuration in which the search process is performed in the server remote from the system user, the search process may be performed in a device held by the system user or in a device provided in the vehicle of the system user.
[0010]
In the first aspect of the present invention, when the user attribute obtaining step described above receives a user ID from a system user terminal, a database in which the user attribute is registered is stored using the user ID. A configuration that includes a step of searching and extracting a user attribute of the system user may be included. It is not necessary to transmit all user attributes every time, and the communication process becomes more efficient. On the other hand, the configuration may be such that all user attributes are transmitted each time. In this case, the user attribute extraction processing can be omitted.
[0011]
Further, in the first aspect of the present invention, the method further includes a step of determining whether the system user is a guest user. If it is determined that the system user is a guest user, the above-described user attribute obtaining step , At least one of gender, age, and license years may be acquired as a user attribute and stored in a storage device. For example, when a guest user who has a low usage frequency uses the service, processing can be performed with less user attribute information.
[0012]
In the first aspect of the present invention, when the position information at a predetermined interval on the route to the destination generated by the navigation system is obtained in the above-described position information obtaining step, the search described above is performed. The configuration may be such that the step is executed for each of the acquired position information at the predetermined intervals. The danger position on the generated route can be specified.
[0013]
Further, the configuration may include a step of generating a route to a destination so as to avoid a dangerous position specified by the traffic accident information stored in the narrowed-down information storage unit described above. By following the regenerated route, the system user can travel to the destination on a road that is less likely to encounter a traffic accident.
[0014]
The vehicle-mounted device according to the second aspect of the present invention includes a traffic accident information database including location information of an accident site and attribute information of an accident party associated with the location information, and a user attribute which is a characteristic of each user. A user interface from a memory card storing the information, and a memory interface means for storing the information in a storage device, a means for acquiring at least current position information and storing the information in a storage device, Search means for searching using position information and user attributes, and means for, when traffic accident information is extracted by the search means, generating a warning message using the extracted traffic accident information and storing it in a storage device And a means for outputting a warning message stored in the storage device to the user. By using such an in-vehicle device, the system user can receive appropriate information according to the situation where the user is located, so that the vehicle can be operated more safely. become.
[0015]
It is also possible to create a program for causing a computer to execute the information processing method according to the present invention, and the program includes, for example, a storage medium such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, and a hard disk. Alternatively, it is stored in a storage device. Also, it may be distributed via a network. The data being processed is temporarily stored in the memory of the computer.
[0016]
BEST MODE FOR CARRYING OUT THE INVENTION
[Embodiment 1]
FIG. 1 shows a system configuration diagram according to the first embodiment of the present invention. The vehicle 1300 is provided with a vehicle-mounted device 13 having, for example, a car navigation function, a communication function with the network 11, and a Web (Web) browser function. Note that the in-vehicle device 13 does not necessarily need to be mounted on a car, and may be of a type that a pedestrian carries and uses like a portable information terminal. The in-vehicle device 13 includes a display device 134, an in-vehicle device hard disk drive (HDD) 131, a GPS antenna 135 for receiving a signal from a GPS (Global Positioning System) satellite 17, and an IC that is an interface with the IC card 1330. The card reader / writer 133 is connected. In addition, a traffic information reception antenna 137 for receiving traffic information such as VICS (Veice Information and Communication System) or a weather information reception antenna 139 for receiving weather information may be connected.
[0017]
Further, the in-vehicle device HDD 131 stores map information, voice information, and other data for realizing a car navigation function. The IC card reader / writer 133 has a function of reading data from a contact type or non-contact type IC card 1330 and writing data. Further, a recording medium of another standard may be used instead of the IC card. In the present application, an IC card is used as a generic term for a recording medium. The IC card 1330 stores data on the attribute of the holder (user attribute). The contents of the user attributes include, for example, user ID, gender, age, address, night vision, years of license holding, number of weekly driving days, weekly driving distance, past accident history, past traffic violation (hereinafter, violation) history, and the like. It is.
[0018]
Note that a configuration may be employed in which data on the user attribute is stored in the vehicle-mounted device HDD 131 or another communicable server, and only the identification information such as the user ID is stored in the IC card 1330. When driving a car, the user sets his or her IC card 1330 in the IC card reader / writer 133 connected to the vehicle-mounted device 13. When the driver changes, the IC card 1330 is replaced, and the IC card reader / writer 133 reads the next user attribute data from the IC card 1330.
[0019]
For example, one or a plurality of weather information company servers 111, one or a plurality of traffic congestion information servers 19, and one or a plurality of insurance company servers 15 are connected to the network 11, which is the Internet, for example. In addition, one or a plurality of in-vehicle devices 13 are also connected to the network 11 wirelessly or by wire. The in-vehicle device 13 has a communication function, but may be connected to another communication device such as a mobile phone to realize the communication function. Further, the weather information company server 111 and the traffic congestion information server 19 are configured to be able to communicate with at least one of the insurance company server 15 and the vehicle-mounted device 13. An accident information database (DB) 155 is connected to the insurance company server 15, and the accident information DB 155 stores past positional information of the accident site and attribute information of the parties in association with each other. Note that the accident information DB 155 does not necessarily need to be connected to the insurance company server 15, and may be configured to be connected to a specialized center server or the like capable of holding accident information and providing services. Further, not all past accident information is registered, but only accident information such as frequently occurring accident information that can be linked to prevention of later accidents is registered.
[0020]
Although not shown, the car 1300 is provided with a function of grasping the weather condition from the values of sensors such as the outside air temperature and humidity, and does not require a signal from the weather information company server 111, There may be a case where a signal from the GPS satellite 17 is not required, for example, the current position can be grasped from the travel distance or the like. Further, there may be a case where a combination of magnetism or the like and a signal from the GPS satellite 17 is used.
[0021]
Hereinafter, a table configuration and a flag attribute of the accident information DB 155 will be described with reference to FIGS.
[0022]
In the example of the accident information table shown in FIG. 2, the column 20 of the accident information number (NO.), The location NO. Column 2050, address attribute column 2060, gender column 2070, age column 2080, vehicle type column 2090, night vision column 2100, license years column 2110, week days column 2120, week distance column 2130, accident History column 2140, violation history column 2150, season column 2160, day column 2170, weather column 2180, time slot column 2190, traffic jam column 2200, traveling direction column 2210, scheduled traveling column 2220, A message column 2040 is included. This table stores the primary key NO. Column 20 and foreign keys and flags of each table described later. If the consistency at the time of updating can be maintained, it may be combined with another table and denormalized in order to speed up the search process. The content of the table has a configuration in which a message for an accident pattern specified by a position, a user attribute, a vehicle type, weather, a traffic congestion state, and a progress state is associated.
[0023]
The example of the user attribute table shown in FIG. 3 includes a column 30 of a user ID (NO.), A column 310 of a gender, a column 320 of an age, a column 325 of an address, a column 330 of a vehicle type, a column 340 of night vision, a license year. Column 350, week days column 360, week distance column 370, accident history column 380, and violation history column 390. In this table, the NO. Column 30 except for the address column 325, which is composed of a foreign key and a flag of each table described later. The content of the table includes, among the information unique to the user, an attribute that is likely to be related to the accident.
[0024]
Note that the vehicle type information registered in the vehicle type column 330 is not the user's own attribute information, but is attribute information related to the user, and is therefore managed in the user attribute table (FIG. 3) in the present application.
[0025]
In the address column 325, an area where the user is used and is used is registered. In the example of the user attribute table (FIG. 3), the municipal name where the user's address is registered is registered as it is. However, any configuration may be used as long as an area such as a municipal code or an area code can be specified. The address data registered here is used for confirming whether or not the user is a nearby resident, when there is a tendency that there is little accident by nearby resident in certain accident information. This is to prevent an extra warning message from being output to a user who passes through a familiar place. In addition, there are cases where there are areas other than an address, such as an area where a car is used for work or a place where you have lived in the past. Configuration may be used.
[0026]
The example of the message table shown in FIG. 4 includes a message number (NO.) Column 40 and a message column 470. In the message column 470, messages that can be commonly used under various conditions are registered, and each record is associated with the message column 2040 of the accident information table (FIG. 2).
[0027]
The example of the accident occurrence place table shown in FIG. 5 includes a place number (NO.) Column 50, a place name column 52, and a position column 54, in which information about places where accidents frequently occur is registered. I have. The place name column 52 can also be used at the time of generating a warning message, and is used, for example, in the “XX intersection” portion of the message “At the XX intersection 100 m ahead ...”. The position column 54 is used for comparison with position information acquired from the GPS satellite 17 or the like.
[0028]
In the example of the address attribute flag table shown in FIG. 6, a flag indicating whether or not the relationship between the accident site and the address of the party is found in the past accident information is defined as an address attribute flag. The address attribute flag is used in the column 2060 of the address attribute of the accident information table (FIG. 2). For example, as a tendency of occurrence of an accident at a certain place, there are many accidents of people who are not local residents, that is, people who are not used to the place. For example, a flag is set to 1 to indicate that the address attribute should be considered. On the other hand, if an accident has occurred regardless of the familiarity of the parties, the flag is set to 0 because there is no need to consider the address attribute.
[0029]
In the example of the gender flag table shown in FIG. 7, a flag indicating gender is defined. The gender flag is used in the user attribute table (FIG. 3) and the accident information table (FIG. 2). This gender flag is used in the gender column 310 in the user attribute table (FIG. 3). If the user is male, the flag is set to 1; if the user is female, the flag is registered as 2 in the table. The gender column 2070 is used in the accident information table (FIG. 2). For example, a flag is set to 1 if there are many male accidents as a tendency of accident occurrence at a certain place. Similarly, if there are many women, set the flag to 2, and if an accident occurs regardless of the gender of the parties, set the flag to 0 to indicate that there is no relationship between gender and the occurrence of the accident. Keep it.
[0030]
The example of the age table shown in FIG. 8 includes an age number (NO.) Column 80 and an age column 82, and the age numbers are registered by age. Each record is associated with a user attribute table (FIG. 3) and an accident information table (FIG. 2). In the user attribute table (FIG. 3), when a record is registered, an age number according to the age of the user is registered in an age column 320. For example, if you are 25, you are in your 20s, so it is registered as "02". Further, in the accident information table (FIG. 2), for example, if the age of the accident party is many teens as the tendency of a traffic accident at a certain place, "01" is registered in the age column 2080. If an accident occurs regardless of the age of the party, "00" is registered in the record of the accident information table (FIG. 2) to indicate that there is no relationship between age and occurrence of the accident. deep.
[0031]
The example of the vehicle type table shown in FIG. 9 includes a column 90 of a vehicle type number (NO.) And a column 92 of a vehicle type, and a vehicle type number previously associated with the size and type of the vehicle is registered. Each record is associated with a user attribute table (FIG. 3) and an accident information table (FIG. 2). In the user attribute table (FIG. 3), when a record is registered, a vehicle type number corresponding to the vehicle type used by the user is registered in the vehicle type column 330. For example, "02" is registered for an RV vehicle. Further, in the accident information table (FIG. 2), for example, if there are many trucks as a type of a car that has caused an accident as a tendency of a traffic accident at a certain place, “01” is registered in the car type column 2090. When an accident occurs regardless of the type of vehicle, "00" is registered in the record of the accident information table (FIG. 2) to indicate that there is no relationship between the type of vehicle and the occurrence of the accident. This attribute associates the characteristics of the vehicle, such as a different view from the driver and a different minimum turning radius, with the type of the vehicle and the occurrence of a traffic accident.
[0032]
In the example of the night vision flag table shown in FIG. 10, a flag representing night vision is defined. The night vision flag is used in the user attribute table (FIG. 3) and the accident information table (FIG. 2). This night vision flag is used in the night vision column 340 in the user attribute table (FIG. 3), and the flag is set to 1 if the user has low vision at night and the surroundings are difficult to see, and the flag is set to 0 if the user is OK. Keep it. In the accident information table (FIG. 2), the column is used in the night vision column 2100. For example, if there is a large number of accidents of people whose night vision deteriorates as a tendency of accident occurrence in a certain place, the flag is set to 1 and the night vision of the party is set. Regardless of the occurrence of an accident, a flag is set to 0 to indicate that there is no relationship between night vision and the occurrence of the accident.
[0033]
The example of the license year table shown in FIG. 11 includes a column 110 of the year number after license acquisition (NO.) And a column 112 of the year number, and registers the year number after license acquisition corresponding to each range of years. Have been. Each record is associated with a user attribute table (FIG. 3) and an accident information table (FIG. 2). In the user attribute table (FIG. 3), when registering a record, a license acquisition year number according to the user's license acquisition year is registered in a license year column 350. For example, if it is 2 years, it is 1 to 5 years, so it is registered as "02". Further, in the accident information table (FIG. 2), for example, if there are many beginners who have less than one year in the number of years after acquiring the license of the accident party as a tendency of traffic accidents at a certain place, "01" is registered in the license year column 2110. Is done. When an accident has occurred regardless of the number of years since the license acquisition of the party, "00" is set in the accident information table (FIG. 2) to indicate that there is no relationship between the number of years after obtaining the license and the occurrence of the accident. Register in the record.
[0034]
The example of the weekly operation days table shown in FIG. 12 includes a weekly operation day number (NO.) Column 120 and an operation days column 122, and the weekly operation day numbers associated with the predetermined days are registered. Have been. The number of days is an average number of days for driving in one week, and represents the frequency of driving. Each record is associated with a user attribute table (FIG. 3) and an accident information table (FIG. 2). In the user attribute table (FIG. 3), when a record is registered, a weekly operation day number according to the user's weekly operation day number is registered in the weekly day number column 360. For example, if driving only on weekends, it is within two days a week, so "01" is registered. In the accident information table (FIG. 2), for example, if there is a large number of accident participants whose weekly operation days are daily as a tendency of a traffic accident at a certain place, “03” is registered in the weekday column 2120. Further, when an accident occurs regardless of the number of weekly operation days of the parties, "00" is set in the record of the accident information table (FIG. 2) to indicate that there is no relation between the number of weekly operation days and the occurrence of the accident. Register in.
[0035]
In the example of the weekly operation distance flag table shown in FIG. 13, a flag indicating an average distance of operation in one week is defined. The weekly operation distance flag is used in the user attribute table (FIG. 3) and the accident information table (FIG. 2). This weekly operation distance flag is used in the weekly distance column 370 in the user attribute table (FIG. 3). If the user operates 50 km or more per week on average, the flag is set to 2, and if the user operates less than 50 km, the flag is set to 2. 1 is registered in the table. In the accident information table (FIG. 2), the column is used in the column 2130 of the week distance. For example, when the weekly operation distance of the party is less than 50 km as a tendency of occurrence of an accident at a certain place, the flag is set to 1 if there are many accidents. . Similarly, if the number of accidents is large when the weekly operation distance of the party is 50 km or more, the flag is set to 2, and if the accident occurs regardless of the weekly operation distance of the party, the weekly operation processing and the accident The flag is set to 0 to indicate that the occurrence is not related.
[0036]
In the example of the accident history flag table shown in FIG. 14, a flag indicating an accident history for the past three years is defined. The accident history flag is used in the user attribute table (FIG. 3) and the accident information table (FIG. 2). This accident history flag is used in the accident history column 380 in the user attribute table (FIG. 3). The flag is set to 0 if no accident has occurred in the past three years, and the flag is set if the user has experienced an accident once in the past three years. The flag is registered in the table as 2 if the accident has been experienced a plurality of times in the past three years. In the accident information table (FIG. 2), this is used in the column of accident history 2140. For example, when the accident history of the party for the past three years is plural times as the tendency of accident occurrence at a certain place, the flag is set to 2 if there are many accidents. Keep it. Similarly, if the accident history of the party for the past three years is one, set the flag to 1 if there are many accidents, and if the accident has occurred regardless of the accident history of the parties for the past three years. The flag is set to 0 to indicate that there is no relationship between the accident history and the occurrence of the accident.
[0037]
As described above, the accident history flag 0 means no accident for the past three years in the user attribute table (FIG. 3), and means no designation in the accident information table (FIG. 2). This is because it is generally not considered that an accident by a party who has been accident-free for the past three years is likely to occur, and a flag may be added if it can actually occur.
[0038]
In the example of the violation history flag table shown in FIG. 15, a flag indicating a violation history for the past three years is defined. The violation history flag is used in the user attribute table (FIG. 3) and the accident information table (FIG. 2). This violation history flag is used in the violation history column 390 in the user attribute table (FIG. 3). If the user has not violated in the last three years, the flag is set to 0, and if the user has experienced a speeding violation in the last three years. The flag is set to 1, and if a violation other than the speed excess has been experienced in the past three years, the flag is registered as 2 in the table. In the accident information table (FIG. 2), this is used in the column 2150 of the history of violations. For example, a flag is set to 1 if there is a large number of accidents in a party who has violated speeding over the past three years as a tendency of accident occurrence at a certain place. Keep it. Similarly, if there is a large number of accidents in which the party's past three-year history of violations is other than speeding, set the flag to 2 and the accident has occurred regardless of the party's past three years' history of violations. In this case, the flag is set to 0 to indicate that there is no relationship between the history of the violation and the occurrence of the accident.
[0039]
As described above, the violation history flag 0 means no violation for the past three years in the user attribute table (FIG. 3), and means no designation in the accident information table (FIG. 2). This is because it is not generally considered that an accident by a non-violating party is likely to occur in the past three years, and a flag may be added if it can actually occur.
[0040]
The example of the season table shown in FIG. 16 includes a column 160 of the season number (NO.), A column 162 at the beginning of the period, a column 164 at the end of the period, and a column 166 of the season. A season number corresponding to each period is registered. Each record is associated with the accident information table (FIG. 2). The start date of the period is registered in the column 162 at the beginning of the period, and the end date of the period is registered in the column 164 at the end of the period. In the season column 166, a season name of a period is registered. In the accident information table (FIG. 2), for example, if the number of accidents occurring during the summer vacation period from July 21 to August 31 is large as a tendency of traffic accidents at a certain place, “05” is displayed in the season column 2160. Register. When an accident occurs on average throughout the year regardless of the season, "00" is added to the record of the accident information table (FIG. 2) to indicate that there is no relationship between the season and the occurrence of the accident. Register.
[0041]
The example of the day of the week table shown in FIG. 17 includes a column 170 of the day number (NO.) And a column 172 of the day, and the day number corresponding to the day is registered. Each record is associated with the accident information table (FIG. 2). In the accident information table (FIG. 2), for example, if there are many accidents on holidays or holidays as a tendency of traffic accidents at a certain place, “04” is registered in the column 2170 of the day of the week. When an accident occurs regardless of the day of the week, "00" is registered in the record of the accident information table (FIG. 2) to indicate that there is no relationship between the day of the week and the occurrence of the accident.
[0042]
The example of the weather table shown in FIG. 18 includes a weather number (NO.) Column 180 and a weather column 182, and a weather number corresponding to the weather is registered. Each record is associated with the accident information table (FIG. 2). In the accident information table (FIG. 2), for example, if the tendency of a traffic accident at a certain place is many on a rainy day, “03” is registered in the weather column 2180. If an accident has occurred regardless of the weather, "00" is registered in the record of the accident information table (FIG. 2) to indicate that there is no relationship between the weather and the occurrence of the accident.
[0043]
The example of the time zone table shown in FIG. 19 includes a time zone number (NO.) Column 190, a start column 192, an end column 194, and a time zone column 196. The time zones are divided into zones, and time zone numbers associated with each time zone are registered. Each record is associated with the accident information table (FIG. 2). In the first column 192, the start time of the time zone is registered, and similarly, in the last column 194, the end time of the time zone is registered. In the time zone column 196, the name of the time zone is registered. In the accident information table (FIG. 2), for example, as a tendency of traffic accidents at a certain place, if the number of accident occurrences is large during school commuting / commuting hours from 7:30 to 8:30 in the morning, the time zone column 2190 contains “ 02 ". If an accident occurs on average throughout the day regardless of the time zone, "00" is set in the accident information table (FIG. 2) to indicate that there is no relationship between the time zone and the occurrence of the accident. Register in the record.
[0044]
In the example of the congestion status flag table shown in FIG. 20, a flag indicating a congestion status is defined. The traffic jam flag is used in the traffic jam column 2200 of the accident information table (FIG. 2). For example, the flag is set to 1 if there are many traffic jams as a tendency of accident occurrence at a certain place, and if an accident occurs without traffic jam, there is no relationship between the traffic jam and the accident occurrence. The flag is set to 0 to indicate this. This is a configuration when it is determined that an accident is more likely to occur in a traffic jam than in a traffic jam. If there is a tendency to occur, a flag may be added.
[0045]
The example of the traveling direction table illustrated in FIG. 21 includes a traveling direction number (NO.) Column 210 and a traveling direction column 212, and a traveling direction number is registered for each direction. Each record is associated with the accident information table (FIG. 2). In the accident information table (FIG. 2), for example, as a tendency of traffic accidents at a certain place, if there are many accidents of vehicles heading north, “04” is registered in the traveling direction column 2210. When an accident occurs regardless of the traveling direction, "00" is registered in the record of the accident information table (FIG. 2) to indicate that there is no relationship between the traveling direction and the occurrence of the accident. deep.
[0046]
The example of the progress schedule table shown in FIG. 22 includes a schedule progress number (NO.) Column 220 and a progress schedule column 222, and the progress schedule number is registered for each route such as right / left turn. Each record is associated with the accident information table (FIG. 2). In the accident information table (FIG. 2), for example, if there is a large number of accidents of vehicles turning right as a tendency of a traffic accident at a certain place, “02” is registered in the column 2220 to be advanced. If an accident has occurred regardless of the schedule, "00" is registered in the record of the accident information table (FIG. 2) to indicate that there is no relationship between the schedule and the occurrence of the accident. deep.
[0047]
Hereinafter, the processing contents of the system shown in FIG. 1 will be described with reference to FIGS.
[0048]
The processing shown in FIG. 23 is an outline of processing common to the first embodiment and a second embodiment described later. In the first embodiment, the insurance company server 15 executes main processing, and the second embodiment In the in-vehicle device 13, the main processing is executed.
[0049]
Here, an overall processing outline in the first embodiment will be described with reference to FIG.
[0050]
First, the insurance company server 15 acquires the user attribute and the vehicle type information acquired by the in-vehicle device 13 by input by the user or by reading from the IC card 1330 through communication with the in-vehicle device 13 (step S1).
[0051]
Next, the insurance company server 15 acquires the current position information of the vehicle 1300 acquired by the in-vehicle device 13 from the GPS satellite 17 via the GPS antenna 135 through communication with the in-vehicle device 13 (step S3). The position history information may be obtained through communication with the vehicle-mounted device 13.
[0052]
Subsequently, the insurance company server 15 acquires the traffic congestion information and the weather information from the traffic congestion information server 19 and the weather information company server 111 via the network 11 or by other communication means (steps S5 and S7). ). Further, when the on-vehicle device 13 has the congestion information receiving antenna 137 and the weather information receiving antenna 139, the configuration may be such that the information is obtained by communication with the on-vehicle device 13. In some cases, either the congestion information or the weather information is acquired from the vehicle-mounted device 13.
[0053]
The insurance company server 15 searches the accident information DB 155 in which accident pattern data is registered in advance, using the user attributes, vehicle type information, position information, traffic congestion information, weather information, and the like acquired by the above-described processing as search conditions. (Step S9).
[0054]
It is determined whether or not the corresponding data (accident pattern) exists as a search result of the accident information DB 155 (step S11). If not, the process returns to the position information acquisition step (step S3). If the corresponding data exists, message generation / output processing is performed (step S13). The message is generated by combining the location information with the value of the message column 470 of the message table (FIG. 4). The insurance company server 15 transmits the message to the in-vehicle device 13, and the in-vehicle device 13 receives the message and outputs it to the user as warning information by text, image, voice, or the like.
[0055]
After the above-described processing is completed, while the system is operating, the process returns to the position information obtaining step (step S3) and the processing is repeated (step S15).
[0056]
Next, the detailed processing contents of the system including the communication between the insurance company server 15 and the vehicle-mounted device 13 will be described with reference to FIG.
[0057]
First, the user sets his / her IC card 1330 in the IC card reader / writer 133 connected to the vehicle-mounted device 13. Then, the IC card reader / writer 133 reads data from the IC card 1330, and the in-vehicle device 13 stores the read data as a user attribute in the storage device (step S17). If the read data does not include the vehicle type information, the processing device of the vehicle-mounted device 13 acquires the vehicle type information from the internal system (not shown) of the vehicle 1300 or the vehicle-mounted device HDD 131 and stores the information in the storage device.
[0058]
Subsequently, the on-vehicle device 13 acquires the current vehicle position information based on the signal from the GPS satellite 17 received via the GPS antenna 135 connected to the on-vehicle device 13, and stores the information in the storage device (Step S19). . Then, the user attribute, vehicle type information, and position information acquired so far are transmitted to the insurance company server 15 (step S21). The user attribute transmitted here is a user ID when the user is a registered user. If the user is a guest user, the information includes, for example, gender, age, vehicle type, and license years.
[0059]
Note that the position information transmitted by the in-vehicle device 13 described above may include history information of the current position and the latest position. However, it is also possible to adopt a configuration in which the position history information is stored in the insurance company server 15. Also, although not shown, when the route is set using the navigation function, information indicating the state of the route setting such as a route setting flag and information on the schedule of progress such as turning right or left up to 100 m ahead are provided. Is transmitted in step S21.
[0060]
In addition, the congestion information receiving antenna 137 and the weather information receiving antenna 139 are connected to the on-vehicle device 13, and the congestion information and weather information provided from the congestion information server 19 and the weather information company server 111 are transmitted to the on-vehicle device via each antenna. 13 and may be transmitted to the insurance company server 15 together with the user attributes, vehicle type information and location information.
[0061]
On the other hand, the insurance company server 15 receives the user attribute, the vehicle type information, and the position information from the in-vehicle device 13 and stores the received information in the storage device (Step S23). When the position history information is not received, the past position information is read by the user ID. When the traffic information and the weather information are not included in the information from the in-vehicle device 13, the information is provided from the traffic information server 19 and the weather information company server 111 via the network 11 or by other communication means. The congestion information and the weather information are acquired and stored in the storage device (Step S25 and Step S27).
[0062]
The insurance company server 15 searches the accident information DB 155 registered in advance using the user attributes, vehicle type information, position information, traffic congestion information, and weather information acquired by the above-described processing as search conditions (step S29). This processing will be described later in detail. It is determined whether or not there is data that satisfies the condition as a search result (step S31). If there is, a warning message is generated and stored in the storage device (step S33). If there is no corresponding data, an empty warning message is generated and stored (step S35). Then, the stored warning message or the empty warning message is transmitted to the vehicle-mounted device 13 (step S37). The empty warning message is information indicating, for example, no warning.
[0063]
The in-vehicle device 13 receives the warning message or the empty warning message from the insurance company server 15 and outputs a warning message as characters, images, sounds, or the like to the user as warning information (step S39). If an empty warning message is received, nothing is output.
[0064]
After outputting the message, the vehicle-mounted device 13 returns to the position information acquisition step (step S19) after a lapse of a predetermined time and repeats the processing (step S41).
[0065]
In this way, the accident information can be managed collectively in the accident information DB 155, and even if data is added or updated, the latest data is always used to keep the user's attributes and users current. Information that is relevant to the situation at hand. Further, the storage capacity and the processing capacity of the vehicle-mounted device 13 may be relatively small.
[0066]
Next, details of the above-described search processing (step S29) of the accident information DB 155 and details of the warning message generation / storage processing will be described with reference to FIGS.
[0067]
Note that two processes, a search process of the accident information DB 155 and a warning message generation / storage process, are common subroutine processes of the first embodiment and a later-described second embodiment. In the first embodiment, the insurance company server 15 and executed by the in-vehicle device 13 in the second embodiment.
[0068]
First, the data of the position column 54 of the accident-prone location table (FIG. 5) is searched using the GPS position information received in advance and stored in the storage device in advance processing (step S69). By comparing the GPS position information with the data in the position column 54 of the accident occurrence location table (FIG. 5), it is determined whether there is data within, for example, 100 m from the GPS position information (step S71). If so, the process ends. If the corresponding data exists, the record is specified (step S73). Next, the location No. of the accident information table (FIG. 2) is set using the value of column 50 of the location number (NO.) Of the specified record as a search condition. Is searched (step S75). If there is at least one matching record (step S77), the corresponding record in the accident information table (FIG. 2) is specified and stored in the narrowing-down information storage unit (step S79). At this time, if data remains in the narrowed-down information storage unit, it is overwritten or temporarily cleared, and then newly stored. Hereinafter, unless otherwise specified, data storage in the narrowing-down information storage unit is an overwriting process. If there is no matching record, the process ends. At this time, if data remains in the narrowed-down information storage unit, the data is cleared and the process is terminated. Hereinafter, unless otherwise specified, when the process ends without the corresponding data, the data in the narrowing-down information storage unit is also cleared.
[0069]
If the current position of the user is, for example, within 100 m from the registered accident occurrence location, the process up to this point is to extract accident information at the accident occurrence location within the 100 m range.
[0070]
Next, the corresponding record of the traveling direction table (FIG. 21) is identified from the GPS history information of the user stored in the storage device in advance by a preliminary process (step S81). From the information on the current position and the history information of the GPS, the direction to which the user is heading is specified, and the record including the column 212 of the matching traveling direction is specified. When the record of the traveling direction table (FIG. 21) is specified, the record stored in the narrowing-down information storage unit by the process of step S79 is further processed using the value of the column 210 of the traveling direction number (NO.) As a search condition. A narrow search is performed (step S83). That is, a record including the same value as the specified traveling direction number in the traveling direction column 2210 is extracted. If the value of the traveling direction column 2210 of the record stored in the narrowing-down information storage unit is “00”, it is a case where there is no relationship between the occurrence of the accident and the traveling direction, and therefore, it is included in the extraction target as it is. . The existence of the corresponding record is determined (step S85), and if there is one or more, the extracted record is stored in the narrow-down information storage unit (step S87). If there is no corresponding record, the process ends.
[0071]
The processing shifts to a processing of FIG. Next, it is determined whether a route by the navigation function has been set (step S89). In the first embodiment, when it is determined that the route is set based on the information indicating the presence or absence of the route setting received from the vehicle-mounted device 13, or in the second embodiment, the route is set based on the setting of the vehicle-mounted device 13. If it is determined that there is a user, progress schedule information such as turning left or right within 100 m of the user is acquired, and the corresponding record in the progress schedule table (FIG. 22) is specified (step S91). The user determines how to proceed from the information on the scheduled progress, and specifies a record containing the matched information on the scheduled progress in the scheduled progress table (FIG. 22). In the first embodiment, the information on the scheduled progress is received from the on-vehicle device 13, and in the second embodiment, the information is acquired from its own navigation processing unit. When the record of the progress schedule table (FIG. 22) is specified, the record stored in the narrowing-down information storage unit by the process of step S87 is further processed using the value of the column 220 of the progress schedule number (NO.) As a search condition. A narrow search is performed (step S93). That is, the record in which the same value as the scheduled progress number of the specified record is stored in the scheduled progress column 2220 is extracted. If the value of the scheduled column 2220 of the record stored in the narrowed-down information storage unit is “00”, it is a case where there is no relationship between the occurrence of the accident and the direction of travel, so that it is included in the extraction target as it is. . The existence of the corresponding record is determined (step S95), and if there is one or more, the extracted record is stored in the narrow-down information storage unit (step S97). If there is no corresponding record, the process ends. On the other hand, when the route by the navigation function is not set (when the information indicating no route setting is received or when it is determined that the route is not set in the navigation processing unit), the steps from step S91 described above are performed. The processing up to S97 is skipped.
[0072]
Next, a date, a day of the week, and a time are obtained from the system date, and the corresponding records in the season table (FIG. 16), the day of the week table (FIG. 17), and the time zone table (FIG. 19) are specified using the information. (Step S99). First, in the season table (FIG. 16), it is determined which season corresponds to the date information, and a record in which the value of the column 160 of the season number (NO.) Is other than “00” is specified. In the day of the week table (FIG. 17), it is determined from the date information to which day of the week category the record belongs, and a record in which the value of the day number (NO.) Column 170 is other than "00" is specified. Further, the time zone table (FIG. 19) is used to determine to which time zone the system time information applies, and a record whose value in the time zone number (NO.) Column 190 is other than "00" is specified.
[0073]
When the records of the season table (FIG. 16), the day of the week table (FIG. 17) and the time zone table (FIG. 19) are specified, the season number (NO.) Column 160 and the day number (NO. ) And the time zone number (NO.) Column 190 are used as search conditions to further narrow down the records stored in the narrow-down information storage unit by the processing of step S97 or step S87 (step S101). . That is, the same value as the value of the column 160 of the season number (NO.) Of the specified record is stored in the column 2160 of the season, and the same value as the value of the column 170 of the day number (NO.) Of the specified record is stored. The record stored in the time zone column 2190 having the same value as the value of the time zone number (NO.) Column 190 of the specified record stored in the day of the week column 2170 is extracted. When the value of the season column 2160 of the record stored in the narrowing-down information storage unit is “00”, it is a case where there is no relation between the occurrence of the accident and the season, and the season number (NO.) No narrowing by column 160 is performed. Similarly, if the value of the record is “00” for the column 2170 of the day of the week and the column 2190 of the time zone, the values in the column 170 of the day number (NO.) And the column 190 of the time zone number (NO.) Are used. No refinement is performed. The existence of the corresponding record is determined (step S103), and if there is one or more, the extracted record is stored in the narrow-down information storage unit (step S105). If there is no corresponding record, the process ends.
[0074]
The processing shifts to a processing of FIG. Next, a traffic congestion flag is specified using traffic congestion information acquired in advance and stored in the storage device (step S107). A temporary table (not shown) such as a list of traffic congestion status may be created to associate the position with the congestion flag so that it can be immediately determined whether or not a certain position is congested. Good. The congestion information includes at least information on the position and information on the presence or absence of congestion at the position. The congestion information obtained from VICS or the like may be held as it is, or the position information of GPS may be used. For example, traffic congestion information within a range of, for example, 100 m from the current position of the user may be extracted and stored.
[0075]
When the traffic jam flag is specified, the records stored in the narrowing-down information storage unit are further narrowed down and searched by the processing of step S105 (step S109). That is, the value of the traffic jam column 2200 of the record stored in the narrow-down information storage unit is “0”, the value of the traffic jam column 2200 is “1”, and the location number of the record is “0”. The record in which the traffic congestion information (temporary table or the like) at the same position as the position derived from the value of the column 2050 indicates that the traffic is congested is extracted. Here, if there is information on an accident that is likely to occur during traffic congestion, processing is performed to exclude the accident information from the extraction target unless traffic congestion actually occurs. The existence of the corresponding record is determined (step S111), and if there is one or more, the extracted record is stored in the narrow-down information storage unit (step S113). If there is no corresponding record, the process ends.
[0076]
Next, the corresponding record of the weather table (FIG. 18) is specified from the weather information previously obtained by the pre-processing and stored in the storage device (step S115). The weather within the range of, for example, 10 km from the user's current position is determined from the weather information, and a record including the weather column 182 in which a matching value is stored is specified. The weather information includes at least information on the position and information on the weather at the position. The weather information obtained from the weather information company server 111 or the like may be held as it is, or the GPS location information may be used. For example, weather information within a range of, for example, 10 km from the current position of the user may be extracted and stored. When the record of the weather table (FIG. 18) is specified, the record stored in the narrow-down information storage unit by the process of step S113 is further narrowed down using the value of the column 180 of the weather number (NO.) As a search condition. (Step S117). That is, a record including the same value as the specified weather number in the weather column 2180 is extracted. If the value of the weather column 2180 of the record stored in the narrowing-down information storage unit is “00”, it is a case where there is no relationship between the occurrence of the accident and the weather, so that it is directly included in the extraction target. The existence of the corresponding record is determined (step S119), and if there is one or more, the extracted record is stored in the narrow-down information storage unit (step S121). If there is no corresponding record, the process ends.
[0077]
The processing shifts to a processing of FIG. Next, it is determined whether the user is a registered user (registered user) or a guest user from the information of the user obtained in advance and stored in the storage device (step S123). A selection screen for prompting selection of a registered user or a guest user is displayed on the display device 134 of the vehicle-mounted device 13 at the start of use of the system, and information input by the user is received and held as identification information. The configuration may be such that the user ID stored in the IC card 1330 is acquired, and whether or not the user ID is registered is searched and determined. If the user is a registered user, the user attribute table (FIG. 3) is searched from the user ID to specify a corresponding record. That is, a record in which the value of the column 30 of the user ID (NO.) Is the same as the user ID of the user is extracted. When the record is specified, the values of all columns (310 to 390) of the record are read (step S127). If the user is a guest user, the minimum user attributes such as, for example, gender, age, vehicle type, and license years have been acquired in advance by prior processing. Step S129). Since the user attribute does not change every moment, it can be used repeatedly in a series of processes, and it is not always necessary to perform the search process every time. For example, once a user attribute is acquired, such as when a user drives a car to a destination, the same data can be used until the user arrives at the destination and ends driving. Therefore, when the processing in step S123 is the second or subsequent processing, a configuration in which the processing in steps S125 to S129 is skipped may be adopted.
[0078]
Next, the corresponding record is extracted based on the user attribute. First, a gender flag is specified from the acquired user attributes (step S131). In the case of a registered user, this is a flag in the gender column 310 of the corresponding record in the user attribute table (FIG. 3), and in the case of a guest user, the corresponding flag value is specified from the gender flag table (FIG. 7). When the gender flag is specified, the records stored in the narrowing-down information storage unit are further narrowed down and searched by the processing of step S121 (step S133). That is, a record in which the flag in the gender column 2070 includes the same flag as the flag specified in step S131 is extracted. If the value of the gender column 2070 of the record stored in the narrow-down information storage unit is “0”, it is a case where there is no relationship between the occurrence of the accident and the gender, so that it is directly included in the extraction target. The existence of the corresponding record is determined (step S135), and if there is one or more, the extracted record is stored in the narrow-down information storage unit (step S137). If there is no corresponding record, the process ends.
[0079]
Next, an age number (corresponding record of the age table) is specified from the acquired user attributes (step S139). In the case of a registered user, it is the value of the age column 320 of the corresponding record in the user attribute table (FIG. 3), and in the case of a guest user, the corresponding age number is specified from the age table (FIG. 8). When the age number is specified, the records stored in the narrowing-down information storage unit are further narrowed down and searched by the processing of step S137 (step S141). That is, a record in which the value in the age column 2080 includes the same value as the age number specified in step S139 is extracted. If the value of the age column 2080 of the record stored in the narrowed-down information storage unit is “00”, it is a case where there is no relationship between the occurrence of the accident and the age, so that it is included in the extraction target as it is. The existence of the corresponding record is determined (step S143), and if there is one or more, the extracted record is stored in the narrow-down information storage unit (step S145). If there is no corresponding record, the process ends.
[0080]
The processing shifts to a processing of FIG. Next, in the case of a registered user, the value (vehicle type number) of the vehicle type column 330 of the corresponding record in the user attribute table (FIG. 3) is specified, and in the case of a guest user, the relevant vehicle type number is specified from the vehicle type table (FIG. 9). (Step S147). When the vehicle type number is specified, the records stored in the narrowing-down information storage unit are further narrowed down and searched by the processing of step S145 (step S149). That is, a record in which the value of the vehicle type column 2090 includes the same one as the vehicle type number specified in step S147 is extracted. When the value of the vehicle type column 2090 of the record stored in the narrowed-down information storage unit is “00”, it is included in the extraction target as it is because there is no relationship between the occurrence of the accident and the vehicle type. The existence of the corresponding record is determined (step S151), and if there is one or more, the extracted record is stored in the narrow-down information storage unit (step S153). If there is no corresponding record, the process ends.
[0081]
Next, the number of years after license acquisition (the corresponding record in the license years table) is specified from the acquired user attributes (step S155). In the case of a registered user, it is the value of the column 350 of the license year of the corresponding record in the user attribute table (FIG. 3). In the case of a guest user, the corresponding year number after obtaining the license is specified from the license year table (FIG. 11). When the number of years after obtaining the license is specified, the records stored in the narrowing-down information storage unit are further narrowed down and searched by the processing of step S153 (step S157). In other words, a record in which the value of the license year column 2110 includes the same number as the license acquisition year number specified in step S155 is extracted. If the value of the license year column 2110 of the record stored in the narrowed-down information storage unit is “00”, it is a case where there is no relationship between the occurrence of the accident and the number of years after obtaining the license, and thus the extraction target is directly extracted. Include in. The existence of the corresponding record is determined (step S159), and if there is one or more, the extracted record is stored in the narrow-down information storage unit (step S161). If there is no corresponding record, the process ends.
[0082]
The processing shifts to a processing of FIG. Then, it is again determined whether or not the user is a guest user (step S163). If the user is a guest user, steps S165 to S171 described below are skipped and the subroutine ends. At this time, the data stored in the narrow-down information storage unit is not cleared. If the user is a registered user, the value of each column of the record in the user attribute table is specified (step S165). In the address column 325, for example, a municipal name is registered, and the municipal name is specified. A number or a flag is registered in each of the other columns. Next, using the value specified in step S165, the records stored in the narrowing-down information storage unit by the process in step S161 are further narrowed down and searched (step S167). For attributes other than the address, the same processing as the above-described processing of step S133 for the gender flag and the processing of step S149 for the vehicle type number, for example, is performed. If the value of each column of the record stored in the narrowing-down information storage unit is “00” or “0”, it is a case where there is no relation between the occurrence of the accident and the user attribute in the column, and therefore, it is not changed. Include in extraction target. Regarding the address, among the records stored in the filtering information storage unit, when the value of the address attribute column 2060 is “0”, or when the value of the address attribute column 2060 is “1” and the location NO. The record in the case where the value of the column 2050 of the column and the value of the column 54 of the position derived from the accident occurrence place table (FIG. 5) are other than the municipalities of the column 325 of the address is extracted. Here, a case where the address attribute need not be taken into consideration and a case where the address attribute needs to be taken into account and the user is not the municipal (or is unfamiliar with the area) are extracted. The determination as to whether or not a local resident may be configured to include nearby municipalities in addition to municipalities. Note that the process of determining the municipalities in which the value of the position column 54 is a municipalities is not an important element of the present invention and will not be described in detail here. For example, a municipal code, an address DB (not shown), etc. , The range of the position value may be associated with the area, and the search may be performed using the value of the position column 54.
[0083]
When all of the refined search processes in step S167 are completed, the existence of the corresponding record is determined (step S169). If there is one or more, the extracted record is stored in the refined information storage unit (step S171). This subroutine ends. If there is no corresponding record, the process ends.
[0084]
With the above processing, it is possible to extract records corresponding to the user attributes and the current operating environment from the accident information table (FIG. 2).
[0085]
Subsequently, details of the warning message generation / storage processing will be described with reference to FIG.
[0086]
First, the location number of the record stored in the narrow-down information storage unit by the prior processing. Is searched using the value of the column 2050 as a search condition, and the corresponding record is extracted and stored in the storage device (step S173). Similarly, the message table (FIG. 4) is searched using the value of the message column 2040 of the record of the record stored in the narrow-down information storage unit as a search condition, and the relevant record is extracted and stored in the storage device (step S175). ). Here, the value of the column 52 of the place name of the record of the accident occurrence place table (FIG. 5) specified by the processing of step S173 and the message of the record of the message table (FIG. 4) specified by the processing of step S175 A warning message is generated from the value of the column 470 of (a) and stored in the storage device (step S179). At this time, a configuration may be used in which a message such as “100 m ahead” is added using the position information. The above processing is performed for all records stored in the narrow-down information storage unit (step S179), and the subroutine ends.
[0087]
In this way, a warning message is generated and stored. The warning message finally provided to the user has a form such as, for example, "At the intersection XX, be careful when turning to the right because there are many accidents." In this case, the information is generated using the values of the two tables. However, a configuration may be employed in which a warning message is directly registered in the accident information table (FIG. 2).
[0088]
As described above, the communication between the in-vehicle device 13 and the insurance company server 15 ensures that even if data is added or updated in the accident information DB 155, the latest data is always used and the attributes of the user and the user It will be able to provide information that is appropriate for the situation in which it is located. In addition, since the insurance company server performs the main processing, the in-vehicle device 13 does not perform the search processing and management of the accident information, and the storage capacity and the processing ability can be relatively small. .
[0089]
[Embodiment 2]
FIG. 32 shows a system configuration diagram according to the second embodiment of the present invention. The vehicle 2300 is provided with an in-vehicle device 23 having, for example, a car navigation function, a communication function with the network 21, and a Web browser function. The in-vehicle device 23 does not necessarily need to be mounted on an automobile, and may be of a type used by pedestrians, such as a portable information terminal. The in-vehicle device 23 is connected with a display device 234, an in-vehicle device HDD 231, a GPS antenna 235 for receiving a signal from the GPS satellite 27, and an IC card reader / writer 233 which is an interface for the IC card 2330. I have. Furthermore, a traffic jam information receiving antenna 237 for receiving traffic jam information such as VICS and a weather information receiving antenna 239 for receiving weather information are connected.
[0090]
Further, the on-vehicle device HDD 231 stores all or part of accident information in an accident information DB 255 described later, and also stores map information, voice information, and other data for implementing a car navigation function. . The IC card reader / writer 233 has a function of reading data from a contact type or non-contact type IC card 2330 and writing data. Further, a recording medium of another standard may be used instead of the IC card. The IC card 2330 stores data on the attribute of the holder (user attribute). The contents of the user attribute include, for example, a user ID, gender, age, address, night vision, license holding years, weekly driving days, weekly driving distance, past accident history, past violation history, and the like.
[0091]
It should be noted that the configuration may be such that data on the user attribute is stored in the in-vehicle device HDD 231 or another communicable server, and only the identification information such as the user ID is stored in the IC card 2330. When driving a car, the user sets his / her IC card 2330 in the IC card reader / writer 233 connected to the vehicle-mounted device 23.
[0092]
For example, one or a plurality of insurance company servers 25 are connected to the network 21 which is the Internet. The one or more weather information company servers 211 and the one or more traffic congestion information servers 29 are connected to a communication tower 213 or the like managed by a broadcaster or the like. Broadcast from the tower 213. In addition, one or a plurality of in-vehicle devices 23 are also connected to the network 21 wirelessly or by wire. The in-vehicle device 23 has a communication function, but may be connected to another communication device such as a mobile phone to realize the communication function. The on-vehicle device 23 is configured to be able to receive information from the weather information company server 21, the traffic congestion information server 29, and the GPS satellites via the connected antennas. An accident information DB 255 is connected to the insurance company server 25. The accident information DB 255 stores past positional information of the accident site and attribute information of the parties in association with each other. The accident information DB 255 does not necessarily need to be connected to the insurance company server 25, and may be configured to be connected to a specialized center server or the like capable of holding accident information and providing a service. Further, not all past accident information is registered, but only accident information such as frequently occurring accident information that can be linked to prevention of later accidents is registered. Further, as described above, all or a part of the accident information is duplicated in the in-vehicle device HDD 231, and for example, only the accident information in the operation range of the automobile 2300 may be stored.
[0093]
Although not shown, the vehicle 2300 does not need information from the weather information company server 211, for example, has a function of grasping the weather condition from the values of sensors such as the outside temperature and humidity. There may be a case where a signal from the GPS satellite 27 is not required, for example, the current position can be grasped from the travel distance or the like. Further, there may be a case where a combination of magnetism or the like and a signal from the GPS satellite 27 is used.
[0094]
The difference between the second embodiment and the first embodiment is that the in-vehicle device 23 has a configuration in which traffic information and weather information can be directly received from each information providing server, and the in-vehicle device HDD 231 also records accident information. That is being done.
[0095]
Hereinafter, processing contents of the system shown in FIG. 32 will be described with reference to FIG. Note that the overall processing outline, such as the information to be obtained and the output of the processing result, is the same as the processing in the first embodiment described above. In addition, a detailed subroutine process of searching the accident information DB and a process of generating and storing a warning message are the same as the processes in the first embodiment. The major difference is that in the first embodiment, the insurance company server 15 performs the main processing, whereas in the second embodiment, the in-vehicle device 23 performs the main processing. That is, in the first embodiment, the insurance company server 15 and the in-vehicle device 13 always perform online processing to communicate and provide the latest information, whereas in the second embodiment, a batch type in which the number of communication times is reduced. It is configured to perform processing.
[0096]
First, the in-vehicle device 23 sends an accident information DB difference information acquisition request to the insurance company at an arbitrary timing (for example, periodically or according to a user's instruction) to update the accident information held in the in-vehicle device HDD 231 to the latest one. The data is transmitted to the server 23 (step S42). This request includes information such as the last update date and time, which can determine the version of the accident information currently stored in the vehicle-mounted device HDD 231.
[0097]
The insurance company server receives the accident information DB difference information acquisition request from the in-vehicle device 23, detects difference information from the accident information DB 255 (Step S45), and transmits the detected difference information to the in-vehicle device 23 (Step S47). If there is no difference information, a code indicating the fact is transmitted.
[0098]
The in-vehicle device 23 receives the accident information DB difference information from the insurance company server 23, adds the difference information to the accident information currently stored in the in-vehicle device HDD 231 and updates the latest state (step S49).
[0099]
Note that the above processing does not always need to be performed every time. When this system is used for the first time, the latest accident information at that time is stored in advance in the in-vehicle device HDD 231, or a medium such as a DVD-ROM in which the accident information is recorded is distributed to the user and mounted on the vehicle. The configuration may be such that accident information is stored in the machine HDD 231. In addition, there is a possibility that the capacity of the in-vehicle device HDD 231 may be insufficient to copy all the information stored in the accident information DB 255. In such a case, not only the national version but also the local version is set. Alternatively, information that is not usually used may not be recorded in the on-vehicle device HDD 231. Further, in the case of such a configuration, a reduction in the amount of communication can be expected in the processing of steps S42 to S49 described above.
[0100]
Next, the user sets his / her IC card 2330 in the IC card reader / writer 233 connected to the vehicle-mounted device 23. Then, the IC card reader / writer 233 reads the data from the IC card 2330, and the in-vehicle device 23 stores the read data as a user attribute in the storage device (step S51). If the read data does not include the vehicle type information, the processing device of the vehicle-mounted device 23 acquires the vehicle type information from the internal system (not shown) of the vehicle 2300 or the vehicle-mounted device HDD 231 and stores it in the storage device. When the user is a registered user, the user attribute stored here is obtained by combining the vehicle type information with the data read from the IC card 2330 or the data read from the in-vehicle device HDD 231 using the user ID. That is, it is information for one record of the user attribute table (FIG. 3). If the user is a guest user, for example, the user is prompted to enter gender, age, vehicle type, and license years, and the input is stored.
[0101]
Subsequently, the on-vehicle device 23 acquires the current vehicle position information based on the signal from the GPS satellite 27 received via the GPS antenna 235 connected to the on-vehicle device 23, and stores it in the storage device (step S53). . Here, as the position information, information on the current position is accumulated, and therefore, position history information can be obtained. Although not shown, when a route has been set using the navigation function, information on the schedule of travel such as turning right or left up to 100 m ahead is stored in step S53.
[0102]
Next, the in-vehicle device 23 receives the congestion information and the weather information broadcast from the communication tower 213 by the congestion information server 211 and the weather information company server 29 via the congestion information receiving antenna 237 and the weather information receiving antenna 139, and stores the storage device. (Step S55 and Step S57).
[0103]
The in-vehicle device 23 searches for accident information registered in the in-vehicle device HDD 231 using the user attribute, vehicle type information, position information, traffic congestion information, and weather information acquired by the above-described processing as search conditions (step S59). This processing is similar to the accident information DB search processing shown in FIGS. Next, it is determined whether or not there is data that satisfies the condition as a search result (step S61). If there is, a warning message is generated and stored in the storage device (step S63). This process is the same as the process shown in FIG. 31, and the description is omitted here. If there is no corresponding data, step S63 and the next step S65 are skipped.
[0104]
The in-vehicle device 23 that has generated the warning message outputs the message as warning information to the user in characters, images, sounds, or the like (step S65).
[0105]
After outputting the message, the in-vehicle device 23 returns to the position information acquisition step (step S53) after a lapse of a predetermined time and repeats the processing (step S67).
[0106]
This eliminates the need to constantly communicate with the insurance company server 25, reduces the number of times of communication, and converts information related to traffic accidents into a form suitable for the attributes of the user and the situation where the user is currently located. Can be provided.
[0107]
[Embodiment 3]
Next, processing contents according to the third embodiment of the present invention will be described with reference to FIGS. The configuration of the system may be the same as the configuration of any one of the first embodiment and the second embodiment. However, since the communication processing between the server and the terminal is not required, the configuration of the second embodiment is assumed. explain. In the case where the details of each process are the same as those described above, detailed descriptions and annotations are omitted.
[0108]
First, the in-vehicle device 23 acquires user attributes and vehicle type information from the IC card 2330 or an input from the user (step S181), and further acquires system date (step S183), traffic congestion information and weather information (step S185). , Stored in a storage device. Further, the destination is acquired based on the current vehicle position information and the user's designation, and stored in the storage device (step S187). When the user is a registered user, the user attribute stored here is obtained by combining the vehicle type information with the data read from the IC card 2330 or the data read from the in-vehicle device HDD 231 using the user ID. That is, it is information for one record of the user attribute table (FIG. 3). If the user is a guest user, for example, the user is prompted to enter gender, age, vehicle type, and license years, and the input is stored.
[0109]
Next, it is determined whether it is the first navigation route generation process (step S189), and if it is the first time, a navigation route is generated using the standard function (step S191). If it is the second time or later (n-th time), information on the position to be detoured is read from the detour location storage unit stored in the processing up to the (n-1) th time (step S193), and a navigation route that bypasses the position is generated. (Step S195). Specifically, the position indicated by the value of the position column 54 is specified from the data of the detour location storage unit storing the result of extracting the record of the accident occurrence location table (FIG. 5), and the location is detoured. This is processing for generating a route.
[0110]
Next, position information at given intervals on the route generated in step S191 or step S195 is acquired, and is compared with the value in the position column 54 of the accident occurrence place table (FIG. 5) (step S197). It is determined whether or not the corresponding data exists (step S199). If there is no corresponding data, the process proceeds to the process of FIG. If there is applicable data, the applicable record of the accident occurrence place table is specified (step S201), and the value of the column 50 of the accident occurrence place number (NO.) Of the record is used as a search condition in the accident information table (FIG. 2). Location No. Column 2050 (step S203). If there is one or more matching records (step S205), the corresponding record in the accident information table (FIG. 2) is specified and stored in the narrow-down information storage unit (step S207). At this time, if data remains in the narrowed-down information storage unit, it is overwritten or temporarily cleared, and then newly stored. Hereinafter, unless otherwise specified, data storage in the narrowing-down information storage unit is an overwriting process. If there is no matching record, the processing proceeds to the processing in FIG. At this time, if data remains in the narrowed-down information storage unit, the data is cleared, and then the processing proceeds to the processing in FIG. In the following, unless otherwise specified, when there is no corresponding data and the process proceeds to the processing in FIG. 37 via the terminal O, the data in the narrowing-down information storage unit is also cleared.
[0111]
Hereinafter, records in the narrowing-down information storage unit are searched and narrowed down using the obtained conditions. The details of the search key and the table to be used are the same as those in the accident information DB search processing described above. In each search step, when the value of the column of the accident information table (FIG. 2) is “0” or “00”, Include it in the extraction target as is.
[0112]
First, a progress schedule is specified from the navigation route information generated in step S191 or S195, and search / refinement is performed based on the specified progress schedule information (step S209), and the existence of the corresponding record is determined (step S209). S211). If no record exists, the process proceeds to the process of FIG. 37 via the terminal O. If a record exists, the extracted record is stored in the narrowing-down information storage unit (step S213).
[0113]
Next, using the information acquired in step S183, search / refinement is performed by date and time (season, day of week, and time zone) (step S215), and the existence of the corresponding record is determined (step S217). If no record exists, the process proceeds to the process of FIG. 37 via the terminal O. If a record exists, the extracted record is stored in the narrowing-down information storage unit (step S219).
[0114]
Next, using the information acquired in step S185, search / refinement based on traffic congestion information and weather information is performed (step S221), and the existence of the corresponding record is determined (step S223). If the record does not exist, the process proceeds to the process of FIG. 37 via the terminal O. If the record exists, the extracted record is stored in the narrowing-down information storage unit (step S225).
[0115]
Next, using the information acquired in step S181, search / refinement by user attribute and vehicle type is performed (step S227), and the existence of the corresponding record is determined (step S229). If the record does not exist, the process proceeds to the process of FIG. 37 via the terminal O. If the record exists, the extracted record is stored in the narrow-down information storage unit (step S231).
[0116]
Next, it is determined whether or not the process up to this is the first route setting process (step S233). If the process is the first time, for example, "Since there is a place where accidents frequently occur on the route, should a bypass route be set?" Is output to the user (step S235), and for the second and subsequent times, for example, a message such as "Since there is a place where accidents frequently occur on the route, should a detour route be set again?" Step S237), prompt the user to make a decision.
[0117]
It is determined whether the user has selected the detour route generation (step S239). If the user has not selected the detour route generation, the process proceeds to the processing in FIG. When the detour route generation is selected, the location number of the record in the narrowing-down information storage unit is determined. The table of FIG. 5 is searched using the value of the column 2050 in (1), the record is additionally stored in the detour place storage unit (step S241), and the processing from step S189 is repeated.
[0118]
Further, the process that has transited through the terminal O is a case where the dangerous place has disappeared due to the generation of the detour route, or the user has determined that the dangerous place may exist. First, the generated navigation route is displayed (step S243), and navigation according to the generated route is started (step S245). The data in the bypass location storage unit is cleared at this point.
[0119]
After the start of the navigation, the information of the position, the traffic congestion and the weather is acquired at regular time intervals, the accident information is searched together with the user attribute and the vehicle type information, and a warning message is output if necessary (step S247). That is, the processing described in the second embodiment is executed.
[0120]
In this way, when a user sets a destination and requests generation of a navigation route, if there is a place on the route generated by the standard function to output a warning message to the user, , It is possible to notify the user. In addition, it is possible to regenerate a route that bypasses a dangerous place for the user.
[0121]
Although the embodiment of the present invention has been described above, the present invention is not limited to this. For example, the system configuration shown in FIGS. 1 and 32 is an example, and other configurations may be used as long as each of the implementation patterns shown in FIGS. 1 and 32 can be realized. For example, a mechanism using satellite broadcasting or the like may be used as a mechanism for receiving weather information and traffic congestion information. Further, the DB configuration is also an example, and another configuration such as non-normalization may be adopted if similar data is stored.
[0122]
The data stored in each DB table is also an example, and may be changed or added. For example, in the example of the weekly operation distance table shown in FIG. 13, the stored data is subdivided into “less than 20 km”, “20 km to 50 km”, “50 km to 100 km”, and “100 km or more”. It may be. Further, the examples of the accident history flag table and the violation history flag table shown in FIGS. 14 and 15 include the judgment conditions for the accident history or the violation history in the past three years. This is merely an example, and may be set for any number of years. In the example of the violation history flag table shown in FIG. 15, the stored data is subdivided into "no violation", "excess speed", "ignore signal", "exceeding violation", "path" It may be configured such that "change prohibition violation exists" and "other violations exist".
[0123]
Further, in the example of the message table shown in FIG. 4, the message column 470 includes data for voice output, but a column for storing the message as character data or another table is used. A configuration may be provided in which a screen is displayed when a warning is issued. In this case, if a simple message such as "Caution for falling wheel" is stored, the driver can understand the message only by momentarily referring to the display device. Note that a configuration may be employed in which a message is displayed on a part of the windshield for a short time to call attention.
[0124]
Further, in the example of the season table shown in FIG. 16, “Golden Week (around April 29 to around May 6)”, “At the time of the Obon homecoming rush (around August 12 and around August 15) ) "And" the time of the New Year's homecoming rush (around December 30 and around January 3) "may be included. Since these dates vary depending on the year, a configuration may be adopted in which date data is re-registered at least once a year by an administrator or the like. Similarly, in the example of the time zone table shown in FIG. 19, a configuration that includes “dusk” may be included. Since this time zone varies depending on the region and the season, the table may be divided into regions, for example, and the time zone data may be registered again, for example, once every three months by an administrator or the like.
[0125]
In addition, the user attribute and other accident information search conditions are also examples, and if there is another element related to the accident, it may be added to the search conditions. For example, a configuration may be adopted in which information on the traveling speed and the orientation of the vehicle body at the time of stopping is acquired, and when a condition that is likely to be collided at the time of stopping or deceleration is met, a message to that effect is output. Similarly, a configuration may be adopted in which information on the traveling lane is acquired, and if a condition that is likely to cause an accident is met, a message to that effect is output.
[0126]
Further, the embodiment of the in-vehicle device has been described. However, the present invention is not limited to the in-vehicle device, and may be a portable information terminal that can be used on foot or by bicycle. In this case, a record of walking or cycling is added to the vehicle type table (FIG. 9). The number of servers that provide information is not limited to one, and may be a configuration including a plurality of servers. For example, there may be several insurance company servers 15 (or 25) or a configuration in which there are several traffic information servers 19 (or 29).
[0127]
【The invention's effect】
As described above, according to the present invention, an information processing technique for preventing a traffic accident can be provided.
[Brief description of the drawings]
FIG. 1 is a schematic diagram of a system according to an embodiment of the present invention.
FIG. 2 is a diagram showing an example of the configuration of an accident information table and stored data.
FIG. 3 is a diagram illustrating an example of a configuration of a user attribute table and stored data.
FIG. 4 is a diagram showing an example of a configuration of a message table and stored data.
FIG. 5 is a diagram illustrating an example of a configuration of an accident occurrence place table and stored data.
FIG. 6 is a diagram illustrating an example of a configuration of an address attribute flag table and data stored therein.
FIG. 7 is a diagram illustrating an example of the configuration of a gender flag table and stored data.
FIG. 8 is a diagram illustrating an example of a configuration of an age table and stored data.
FIG. 9 is a diagram illustrating an example of a configuration of a vehicle type table and stored data.
FIG. 10 is a diagram illustrating an example of a configuration of a night vision table and data stored therein.
FIG. 11 is a diagram showing an example of the structure of a license year table and stored data.
FIG. 12 is a diagram showing an example of the configuration of a weekly operation days table and data stored therein.
FIG. 13 is a diagram illustrating an example of a configuration of a weekly operation distance table and data stored therein.
FIG. 14 is a diagram showing an example of the configuration of an accident history flag table and stored data.
FIG. 15 is a diagram illustrating an example of a configuration of a violation history flag table and stored data.
FIG. 16 is a diagram showing an example of the structure of a season table and stored data.
FIG. 17 is a diagram illustrating an example of the configuration of a day of the week table and stored data.
FIG. 18 is a diagram illustrating an example of a configuration of a weather table and stored data.
FIG. 19 is a diagram showing an example of the configuration of a time zone table and stored data.
FIG. 20 is a diagram showing an example of the configuration of a traffic jam status flag table and data to be stored.
FIG. 21 is a diagram illustrating an example of a configuration of a traveling direction table and stored data.
FIG. 22 is a diagram showing an example of the configuration of a progress schedule table and stored data.
FIG. 23 is a diagram showing an outline processing flow in the first embodiment of the present invention.
FIG. 24 is a diagram showing a processing flow in the first embodiment of the present invention.
FIG. 25 is a diagram showing a processing flow (No. 1) in an accident information DB search.
FIG. 26 is a diagram showing a processing flow (part 2) in the accident information DB search.
FIG. 27 is a diagram depicting a processing flow (No. 3) in the accident information DB search;
FIG. 28 is a diagram depicting a processing flow (No. 4) in the accident information DB search;
FIG. 29 is a diagram depicting a processing flow (No. 5) in the accident information DB search;
FIG. 30 is a diagram showing a process flow (part 6) in the accident information DB search.
FIG. 31 is a diagram depicting a processing flow in a warning message generation / storage processing;
FIG. 32 is a system schematic diagram according to Embodiment 2 of the present invention.
FIG. 33 is a diagram showing a processing flow in the second embodiment of the present invention.
FIG. 34 is a diagram showing a processing flow (part 1) in the third embodiment of the present invention.
FIG. 35 is a diagram showing a processing flow (part 2) in the third embodiment of the present invention.
FIG. 36 is a diagram showing a processing flow (part 3) in the third embodiment of the present invention.
FIG. 37 is a diagram showing a processing flow (part 4) in the third embodiment of the present invention.
[Explanation of symbols]
11,21 Network 13,23 In-vehicle device
15,25 Insurance company server 17,27 GPS satellite
19, 29 Traffic information server 20 Column of accident information number
30 User ID column 40 Message number column
50 Column of place numbers where accidents frequently occur 52 Column of place names
54 Position column 80 Age number column 82 Age column
90 Vehicle number column 92 Vehicle type column
110 License year number column 111, 211 Meteorological information company server
112 year column 120 week operation day number column
122 Operating days 131,231 In-vehicle device HDD
133 IC card reader / writer 134,234 Display device
135,235 GPS antenna 137,237 Congestion information receiving antenna
139,239 Weather information receiving antenna 155,255 Accident information DB
160 Season number column 162 Period start column 164 Period end column
166 Season column 170 Day number column 172 Day column
180 Weather column 182 Weather column 190 Time zone column
192 first row 194 last row 196 time zone
210 Row of heading number 212 Row of heading
220 Scheduled column number 222 Scheduled column
310 Gender column 320 Age column 325 Address column
330 Row of cars 340 Row of night vision 350 Row of license years
360 days column 370 weeks distance column 380 accident history column
390 Violation history column 470 Message column
1300, 2300 Car 1330, 2330 IC card
2050 Place No. Column 2060 Address attribute column
2070 Gender column 2080 Age column 2090 Car column
2100 Column of night vision 2110 Column of license years
2120 Week days column 2130 Week distance column
2140 Accident history column 2150 Violation history column 2160 Seasonal column
2170 Day column 2180 Weather column 2190 Time column
2200 Traffic jam row 2210 Traveling row
2220 Scheduled column 2040 message column

Claims (11)

An information processing method for preventing traffic accidents,
A user attribute acquisition step of acquiring a user attribute, which is an individual characteristic of the system user, and storing the attribute in a storage device;
Position information acquisition step of acquiring the current or scheduled position information of the system user and storing the information in a storage device,
Searching the information of the traffic accident information database including the location information of the accident site and the attribute information of the accident party associated with the location information using the current or scheduled location information of the system user and the user attributes Search step to perform,
When the traffic accident information is extracted by the search, storing the extracted traffic accident information in the narrowed-down information storage unit;
Information processing method for preventing traffic accidents. Acquiring at least one of vehicle type information, traffic congestion information, weather information, and date and time information, and storing the acquired information in a storage device;
2. The information for preventing a traffic accident according to claim 1, wherein the search step further performs a search using at least one of the vehicle type information, the congestion information, the weather information, and the date and time information. Processing method. The information processing method for preventing a traffic accident according to claim 1 or 2, further comprising a step of generating a warning message using information stored in the narrowed-down information storage unit and storing the generated warning message in a storage device. 4. The method according to claim 3, further comprising transmitting a warning message stored in the storage device to a terminal of the system user. When the user attribute obtaining step receives a user ID from the terminal of the system user, a database in which the user attribute is registered is searched using the user ID to extract the user attribute of the system user. The information processing method for preventing a traffic accident according to any one of claims 1 to 4, comprising a step. The method further includes a step of determining whether the system user is a guest user. If the system user is determined to be a guest user, in the user attribute obtaining step, gender, age, and license years are used as the user attributes. The information processing method for preventing a traffic accident according to any one of claims 1 to 4, wherein at least one piece of the information is obtained and stored in a storage device. When the position information at a predetermined interval on the route to the destination generated by the navigation system is obtained in the position information obtaining step, the searching step is executed for each of the obtained position information at the predetermined interval. 3. The information processing method for preventing traffic accidents according to claim 1 or 2. 8. The information processing method for preventing a traffic accident according to claim 7, further comprising a step of generating a route to a destination so as to avoid a dangerous position specified by the traffic accident information stored in said narrowing-down information storage unit. . A program for causing a computer to execute the information processing method for preventing a traffic accident according to any one of claims 1 to 8. An information processing device for preventing traffic accidents,
Means for acquiring a user attribute, which is an individual characteristic of the system user, and storing it in a storage device;
Means for acquiring current or scheduled location information of the system user, and storing the information in a storage device;
Searching the information of the traffic accident information database including the location information of the accident site and the attribute information of the accident party associated with the location information using the current or scheduled location information of the system user and the user attributes Means to
Means for storing the extracted traffic accident information in the narrowed-down information storage unit, when the traffic accident information is extracted by the search,
Information processing device for preventing traffic accidents. A traffic accident information database including location information of the accident site and attribute information of the accident party associated with the location information;
Memory interface means for reading the user attributes from a memory card storing user attributes which are individual characteristics of the user and storing the user attributes in a storage device;
Means for acquiring at least current position information and storing it in a storage device;
Search means for searching the information of the traffic accident information database using the position information of the user and the user attribute,
When the traffic accident information is extracted by the search means, a means for generating a warning message using the extracted traffic accident information and storing the warning message in a storage device;
Means for outputting a warning message stored in the storage device to the user,
An in-vehicle device having a.

Images