路径搜索系统、路径搜索装置、路径搜索方法和计算机程序与流程

本发明涉及一种向用户提供多模式路径的路径搜索系统、路径搜索装置、路径搜索方法和计算机程序。

本申请要求于2016年12月13日提交的日本专利申请no.2016-240985的优先权，其全部内容通过引用结合于此。

背景技术：

专利文献1公开了一种路径搜索系统，其使用不同行进装置向用户的移动终端提供由多个路线组成的多模式路径(计划行进路径)。

引用列表

专利文献

专利文献1：日本特开专利公开no.2016-177396

技术实现要素：

[技术问题]

(1)根据本公开的一个实施例的路径搜索系统是包括被配置为与移动终端通信的路径搜索装置的路径搜索系统。路径搜索装置包括：通信单元，其被配置为从移动终端接收包括用户的识别信息的搜索请求，并将与搜索请求相对应的搜索结果发送到用户的移动终端；控制单元，其被配置为根据接收的搜索请求，执行包括以下路线中的至少一个的多模式路径的搜索处理，并使通信单元发送多模式路径作为搜索结果。控制单元使至少一个路线的通行计划和用于沿着至少一个路线行进的行进装置的识别信息被包括在多模式路径的数据内容中，该行进装置与用户的识别信息相关联。

徒步路线：用户徒步行进的路线

非公共路线：用户使用非公共车辆行进的路线

公共路线：用户使用公共运输工具行进的路线

(11)根据本公开的一个实施例的路径搜索装置是被配置为与移动终端通信的路径搜索装置。路径搜索装置包括：通信单元，其被配置为从移动终端接收包括用户的识别信息的搜索请求，并将与搜索请求相对应的搜索结果发送到用户的移动终端；控制单元，其被配置为根据接收的搜索请求，执行包括上述路线中的至少一个的多模式路径的搜索处理，并使通信单元发送多模式路径作为搜索结果。控制单元使至少一个路线的通行计划和用于沿着至少一个路线行进的、与用户的识别信息相关联的行进装置的识别信息被包括在多模式路径的数据内容中。

(12)根据本公开的一个实施例的路径搜索方法是由被配置为与移动终端通信的路径搜索装置执行的路径搜索方法。该方法包括以下步骤：从移动终端接收包括用户的识别信息的搜索请求；根据接收的搜索请求，执行包括至少一个上述路线的多模式路径的搜索处理，并将多模式路径作为搜索结果发送给用户的移动终端；使至少一个路线的行进计划和用于至少一个路线的通行的行进装置的识别信息被包括在多模式路径的数据内容中，该行进装置的识别信息是与移动终端的识别信息相关联的用户的识别信息。

(13)根据本公开的一个实施例的计算机程序是用于使计算机用作被配置为与移动终端通信的路径搜索装置的计算机程序。该程序使计算机用作：通信单元，其被配置为从移动终端接收包括用户的识别信息的搜索请求，并将与搜索请求对应的搜索结果发送给用户的移动终端；控制单元，其被配置为根据接收的搜索请求，执行包括至少一个上述路线的多模式路径的搜索处理，并使通信单元发送多模式路径作为搜索结果。控制单元使至少一个路线的通行计划和用于至少一个路线的通行的、与用户的识别信息相关联的行进装置的识别信息被包括在多模式路径的数据内容中。

附图说明

图1示出了根据本公开的实施例的路径搜索系统的整体构成。

图2是示出移动终端和管理装置之间的通信过程的示例的序列图。

图3是示出徒步路线中的改道(reroute)确定处理的示例的流程图。

图4是示出非公共路线中的改道确定处理的示例的流程图。

图5是示出针对每个用户id的改道确定处理的示例的流程图。

图6是示出针对每个公共id的改道确定处理的示例的流程图。

图7是示出路线信息a中包括的路线的图像图。

图8是示出包括在另一路线信息b中的路线的图像图。

具体实施方式

在专利文献1中公开的路径搜索系统中，实现为服务器计算机的路径搜索装置监视移动终端是否能够按计划地通过所计划的行进路径。如果发生阻碍移动终端按照计划通过的事件，则路径搜索装置首先在指定的搜索条件下计算新的计划行进路径，然后将新的计划行进路径发送到移动终端。

<本公开要解决的问题>

在传统的路径搜索系统中，路径搜索装置共同执行关于移动终端是否能够按计划地通过计划行进路径的监视处理。因此，要监视的计划行进路径的数量(用户的数量)越大，对计划行进路径的监视处理所需的处理负荷就越大。

考虑到传统问题，本公开的目的是提供一种能够适当地分散用于多模式路径监视处理的处理负荷的路径搜索系统等。

<本公开的效果>

根据本公开，可以适当地分散用于多模式路径监视处理的处理负荷。

<本公开的实施方式的概要>

在下文中，列出并描述了本公开的实施例的概要。

(1)根据本实施例的路径搜索系统是包括被配置为与移动终端通信的路径搜索装置的路径搜索系统。路径搜索装置包括：通信单元，其被配置为从移动终端接收包括用户的识别信息的搜索请求，并将与搜索请求对应的搜索结果发送给用户的移动终端；控制单元，其被配置为根据接收的搜索请求，执行包括至少一个以下路线的多模式路径的搜索处理，并使通信单元发送多模式路径作为搜索结果。

控制单元使至少一个路线的通行计划和用于沿至少一个路线行进的行进装置的识别信息被包括在多模式路径的数据内容中，该行进装置与用户的识别信息相关联。

徒步路线：用户徒步行进的路线

非公共路线：用户使用非公共车辆行进的路线

公共路线：用户使用公共运输工具行进的路线

根据本实施例的路径搜索系统，控制单元使至少一个路线的通行计划和用于沿至少一个路线行进的行进装置的识别信息被包括在多模式路径的数据内容中，与用户的识别信息相关联，该行进装置与用户的识别信息相关联。

因此，可以使诸如移动终端的本地终端执行关于用户是否正按计划地行进于每个路线的监视处理，从而能够适当地分散用于多模式路径监视处理的处理负荷。因此，能够减少路径搜索设备的处理负荷。

(2)在本实施例的路径搜索系统中，移动终端可以基于所述徒步路线的通行计划来监视移动终端是否正按计划地在所述徒步路线行进。

原因如下。由于与徒步路线中的路径搜索装置通信的通信终端仅是移动终端，因此优选地使移动终端执行徒步路线监视处理。

(3)在本实施例的路径搜索系统中，当监视的结果为否定时，移动终端优选地向路径搜索装置发送使路径搜索装置重新执行搜索处理的改道请求。

在这种情况下，即使当用户不能按照计划行进徒步路线时，移动终端能够接收由路径搜索装置新生成的替选多模式路径，从而为用户提供有效的未来的路径信息。

(4)本实施例的路径搜索系统还包括安装在非公共车辆上的车载终端。在先前已经向车载终端通知非公共车辆通过的非公共路线的通行计划以及非公共车辆的识别信息的情况下，车载终端可以监视非公共车辆是否基于非公共路线的通行计划而正按照计划在非公共路线上行进。

原因如下。当车载终端执行非公共路线监视处理时，移动终端不需要执行监视处理，从而可以抑制移动终端的剩余电量的减少。

(5)在本实施例的路径搜索系统中，当监视结果为否定时，车载终端优选地向路径搜索装置发送使路径搜索装置重新执行搜索处理的改道请求。

在这种情况下，即使当用户不能按照计划行进非公共路线时，移动终端能够接收由路径搜索装置新生成的替选多模式路径，从而为用户提供有效的未来的路径信息。

(6)在本实施例的路径搜索系统中，控制单元优选地根据公共路线的通行计划监视公共运输工具是否正按照计划在公共路线上行进。

原因如下。由于多个用户可以登上公共运输工具，因此监视一个公共路线足以确定为使用公共路线的多个用户改道的必要性。

(7)因此，当监视结果为否定时，控制单元优选地关于与公共运输工具的识别信息对应的所有移动终端的识别信息重新执行搜索处理。

(8)在本实施例的路径搜索系统中，路径搜索装置执行关于用户是否正按照计划行进公共路线的监视，以及非公共车辆的移动终端或车载终端执行用户是否正按照计划行进除公共路线以外的路线的监视。

因此，多模式路径中包括的路线的监视可以由多个主体适当地共享。

(9)在本实施例的路径搜索系统中，当通信单元已经从移动终端或车载终端接收改道请求时，控制单元优选地执行改道，该改道是关于在改道请求中包括的用户的识别信息或者与行进装置的识别信息对应的用户的识别信息，重新执行搜索处理的处理。

因此，即使在阻碍用户按照计划行进的事件发生在徒步路线或路径搜索装置不是检测主体的非公共路线中的情况下，路径搜索装置能够执行改道。

(10)在本实施例的路径搜索系统中，即使当已经经过了非公共路线的终点通过时间，在没有来自车载终端的改道请求并且没有关于来自车载终端的非公共路线的完成通知的情况下，控制单元优选地向移动终端发送关于车载终端是否已按照计划行进非公共路线的确定请求。

在这种情况下，即使在车载终端由于临时通信故障等而不能与路径搜索装置通信的情况下，也可以使移动终端执行关于用户是否已经按照计划行进非公共路线的监视处理。

(11)本实施例的路径搜索装置涉及一种构成根据上述(1)至(10)中任一项所述的路径搜索系统的路径搜索装置。

因此，本实施例的路径搜索装置表现出与根据上述(1)至(10)中任一项所述的路径搜索系统相同的效果。

(12)本实施例的路径搜索方法涉及一种由构成根据上述(1)至(10)中任一项所述的路径搜索系统的路径搜索装置执行的路径搜索方法。

因此，本实施例的路径搜索装置表现出与根据上述(1)至(10)中任一项所述的路径搜索系统相同的效果。

(13)本实施例的计算机程序涉及一种用于使计算机用作构成根据上述(1)至(10)中任一项所述的路径搜索系统的路径搜索装置的计算机程序。

因此，本实施例的计算机程序表现出与根据上述(1)至(10)中任一项所述的路径搜索系统相同的效果。

<本公开的实施例的细节>

在下文中，将参考附图描述本公开的实施例。以下描述的实施例的至少一些部分可以根据需要组合在一起。

[路径搜索系统的整体构成]

图1示出了根据本公开的实施例的路径搜索系统的整体构成。

如图1所示，本实施例的路径搜索系统包括：管理装置(路径搜索装置)1，其具有路径搜索功能并被放置在交通控制中心等中；多个移动终端2；以及多个车载终端3。管理装置1经由诸如因特网的公共通信网络4与移动终端2和车载终端3通信。

本实施例的管理装置1预先在其中存储由注册会员(用户)拥有的移动终端2的用户id。对于用户id，可以使用对硬件唯一的诸如mac地址的物理地址，或者可以使用最初由管理装置1定义的识别值。例如，在从用户接收用于系统利用的注册的应用时，管理装置1能够向用户分配特定id并存储id。

管理装置1能够执行提供服务的路径信息，其中，响应于从移动终端2接收的搜索请求，管理装置1搜索通过组合用于与移动终端2对应的用户id的诸如用户拥有的车辆、公共运输工具等的多个行进装置获得的最佳路径，并将搜索结果返回给移动终端2。

在本说明书中，“车辆”指示汽车、电动辅助自行车、轻型车辆、无轨电车等。“公共车辆”指示假定容纳多个乘客的高度公共车辆，诸如固定路线的公共汽车、列车等。“公共运输工具”除了公共车辆之外，指示除了车辆之外的高度公共的行进装置，诸如飞机、客船等。

“非公共车辆”指示：非公共车辆，诸如用户拥有的车辆(以下称为“自有车辆”)；以及其目的地可由车辆的乘客指定的较少公共的车辆，诸如出租车、租车、共享出租车等。由用户以外的人拥有并且由所有者允许由第三人使用的车辆是一种非公共车辆。

移动终端2是由用户携带并且与管理装置1可通信的终端设备。移动终端2被实现为其中安装用于利用从管理装置1接收的搜索结果的应用的例如智能电话、平板终端、笔记本电脑等。

车载终端3是安装在与管理装置1可通信的非公共车辆上的终端装置。车载终端3被实现为其中安装用于利用从管理装置1接收的搜索结果的应用的例如车辆导航装置。

管理装置1经由公共通信网络4与运输工具的预订管理服务器5可通信。管理装置1能够通过预订管理服务器5执行用户使用的运输工具的预订(例如，出租车分派预订、电子机票安排等)。

管理装置1经由公共通信网络4与运输工具的操作管理服务器6可通信。管理装置1能够通过与操作管理服务器6的通信来获取诸如出租车和公共运输工具的运输工具的当前操作计划。

管理装置1经由公共通信网络4与提供天气信息的天气服务器7可通信。管理装置1能够通过与天气服务器7的通信来获取关于在预先确定的区域中的当前和未来天气的信息。

管理装置1经由公共通信网络4与提供事件信息的事件服务器8可通信。管理装置1能够通过与事件服务器8的通信来获取关于在预先确定的区域中举行的当前和未来事件的信息。

管理装置1能够从道路交通信息中心(未示出)获取通过fm多路广播分发的vics(注册商标)信息。

管理装置1经由诸如电话线的专用通信线路可通信地连接到包括在预先确定的管理区域中的交通信号控制器9。对于在属于管理区域的交叉点处提供的交通信号单元，管理装置1能够执行例如用于根据交通情况改变信号控制参数(分路、周期长度、偏移等)的交通致动控制。

[管理装置的内部构成]

管理装置1被实现为服务器计算机。如图1所示，管理装置1包括通信单元11、存储单元12和控制单元13。

通信单元11被实现为包括放大电路、频率转换电路、调制和解调电路等的通信设备，并且该通信设备是与公共通信网络4的有线通信所需的。通信单元11也与经由专用通信线路与交通信号控制器9的通信兼容。

存储单元12被实现为磁存储介质或诸如闪存的非易失性存储介质。控制单元13被实现为包括cpu、ram、rom、闪存等的微计算机。

当cpu读出存储在存储单元12中的计算机程序并执行该程序时，控制单元13实现各种类型的处理和功能。由控制单元13执行的处理的示例包括：搜索多模式路径的处理，以及布置出租车或公共运输工具的处理。

存储单元12包括交通信息数据库、地图数据库、操作数据库等。交通信息数据库对每个道路链路包括当前道路链路的拥堵程度的信息。

基于从道路交通信息中心接收的vics信息等，控制单元13连续地更新存储在交通信息数据库中的交通信息(例如，交通拥堵信息)。

地图数据库包含道路数据和设施数据。道路数据包含与道路配置有关的数据诸如链路的位置信息和类型信息、节点的位置信息和类型信息、以及节点和链路之间的连接关系。

设施数据包含每个设施的设施信息。设施信息包含诸如设施的名称、位置信息、设施所在地的地的编号以及设施的类型等数据。设施类型的示例包括：公共办公室、公园、学校、停车场、便利店、餐馆和公共运输工具的乘车/下车地点(例如，车站、公共汽车站、机场、或码头)。

操作数据库包含指示公共运输工具(例如，列车、公共汽车、飞机、轮船等)的固定操作状态的操作计划。对于每个公共运输工具的路线，每个操作计划包括路线的名称数据、在路线中操作的每个服务(航班)的乘车/下车地点处的到达时间和出发时间的数据。

控制单元13每预先确定的时间(例如，1分钟)访问操作管理服务器6，并且连续地更新操作计划的改变、延迟时间等。

多模式路径搜索处理是通过使用存储在存储单元12中包括的数据库中的各种类型的数据来为用户计算最佳多模式路径的至少一个候选的处理。

多模式路径是允许使用不同行进装置的多个路线的组合的路径。在本实施例中，以下路线能够是多模式路径的组成部分。

1)徒步路线：用户步行的路线。在徒步路线中，用户可以通过使用没有车载终端3的诸如自行车的行进装置来行进。

2)非公共路线：用户通过使用非公共车辆(例如，自有车辆、出租车、租车、共享出租车等)行进的路线。

3)公共路线：用户通过使用诸如公共车辆(例如，固定路线的公共汽车、列车、飞机、客船等)的公共运输工具行进的路线。

多模式路径搜索处理采用一种算法，其中，例如，包含在地图数据库中的道路链路(徒步路线或非公共路线的构成单元)和包含在操作数据库中的路线(公共路线的构成单元)用作构成链路，并且通过使用例如dijkstra方法来比较多个候选路径的成本，以采用具有最低预先确定的成本的路径作为最佳路径。

对于预先确定的成本，可以采用区间的长度(行进距离)，所需时间和票价(通过该区间的票价，例如铁路票价)中的任何一个。可以采用基于这三个量计算的预先确定的参数作为成本(例如，k1×长度+k2×所需时间+k3×票价，其中k1至k3是权重)。

通过搜索处理计算的最佳路径可以是仅由非公共路线组成的路径，或者包括徒步路线、非公共路线和公共路线的路径。

[移动终端的内部构成]

如图1所示，移动终端2包括无线通信单元21、位置检测单元22、显示单元23、操作单元24、存储单元25和控制单元26。

无线通信单元21被实现为包括放大电路、频率转换电路、调制和解调电路等，并且是与连接到公共通信网络4的基站(未示出)进行无线通信所需的无线通信设备。

位置检测单元22是指定移动终端2的当前位置并将当前位置输出到控制单元26的设备。位置检测单元22例如被实现为gps接收器。

显示单元23被实现为显示用户的文本、图像等的显示器。操作单元24被实现为接收由用户执行的操作输入(例如，诸如目的地的设置的操作输入)的输入设备，并且根据接收的操作将信号输出到控制单元26。

存储单元25被实现为磁存储介质或诸如闪存的非易失性存储介质。控制单元26被实现为具有cpu、ram、rom、闪存等的微计算机。

当cpu读出存储在存储单元25中的计算机程序并执行该程序时，控制单元26实现各种类型的处理和功能。由控制单元26执行的处理的示例包括：发送搜索请求和改道请求的处理；以及监视徒步路线的处理。

[车载终端的内部构成]

如图1所示，车载终端3包括无线通信单元31、位置检测单元32、显示单元33、操作单元34、存储单元35和控制单元36。

无线通信单元31被实现为包括放大电路、频率转换电路、调制和解调电路等，并且是与连接到公共通信网络4的基站(未示出)进行无线通信所需的无线通信设备。

位置检测单元32是指定移动终端2的当前位置并将当前位置输出到控制单元36的设备。位置检测单元32被实现为通过组合gps接收器、车速传感器和陀螺仪传感器而获得的设备。

显示单元33被实现为显示用户的文本、图像等的显示设备。操作单元34被实现为接收由用户执行的操作输入(例如，诸如目的地的设置的操作输入)的输入设备，并且根据接收的操作将信号输出到控制单元36。

存储单元35被实现为磁存储介质或诸如闪存的非易失性存储介质。控制单元36被实现为具有cpu、ram、rom、闪存等的微计算机。

当cpu读出存储在存储单元35中的计算机程序并执行该程序时，控制单元36实现各种类型的处理和功能。由控制单元36执行的处理的示例包括：发送改道请求的处理；以及监视徒步路线的处理。

[出发前的通信序列]

图2是示出在用户出发之前执行的移动终端和管理装置之间的通信过程的示例的序列图。

尽管下面将“管理装置1”和“移动终端2”描述为操作主体，但是实际执行处理的操作主体是管理装置1的控制单元13和移动终端2的控制单元26。

如图2所示，当用户的移动终端2向管理装置1发送搜索请求时，管理装置1接收搜索请求(步骤st1)。

作为第一请求的搜索请求包括用户id、位置信息(出发地和目的地)、时间信息(出发时间和到达时间)等。搜索请求还可以包括用户的偏好信息。偏好信息包括表示用户优先关注什么的信息，例如旅行时间、转机次数、票价、舒适性以及他/她自有车辆或公共运输工具的优先使用。管理装置1能够根据用户的偏好信息设置搜索处理的成本。

接下来，管理装置1通过使用搜索请求中包括的位置信息、时间信息和偏好信息作为输入信息来执行多模式路径搜索处理(步骤st2)。

在这种情况下，管理装置1生成至少一个多模式路径作为搜索结果，并将所生成的多模式路径发送到移动终端2(步骤st3)。

在图2的右侧，路线信息a的数据内容被示出为通过管理装置1的搜索处理生成的多模式路径的一个示例。

如图2所示，路线信息a与已发送搜索请求的移动终端2的用户id(这里，用户id＝x)的值相关联。路线信息a包括多个路线a1至a5。尽管未在图2中示出，路线a1至a5中的每一个包括在位置上指定路线的起点和终点的信息。路线a1至a5中的每一个可以包括诸如道路链路、节点和服务路线的数据。

路线信息a包括：用于及时通过路线a1至a5中的计划通过点(在图2的示例中，每个路线的起点和终点)的通行计划；以及用于沿路线a1至a5行进的行进装置的识别信息(以下也称为“交通id”)。

也就是说，管理装置1的控制单元13将路线a1至a5的通行计划和与用户id(＝x)相关联的用于沿路线a1至a5行进的交通id添加为路线信息a的数据内容。

在图2的示例中，路线a1至a5的通行计划由路线a1至a5的起点通过时间点和终点通过时间点组成。当然，可以包括在路线a1至a5中的中间点(例如，诸如在路线a2中提供的交叉点的预先确定的点)处的计划通过时间。

在本实施例中，由管理装置1的控制单元13添加的交通id被分类为非公共id和公共id。非公共id包括出租车id、自有车辆id等。公共id包括列车id、公共汽车id、飞机id、船舶id等。但是，如果id对于各个旅行方式是唯一的，则没有必要通过id分配系统将id分类为非公共id和公共id。在这种情况下，可以通过使用除了旅行方式唯一的id之外的信息来区分各个旅行方式是“非公共”还是“公共”和/或各个旅行方式的类型。

在图2中所示的路线信息a中，对于路线a1的通行计划，起点通过时间为12:20，终点通过时间为12:30。

路线a1的交通id为null(无)。在这种情况下，由于没有定义交通id，因此路线a1是徒步路线。

对于路线a2的通行计划，起点通过时间是12:30，终点通过时间是12:50。

路线a2的交通id是预先确定的出租车id的识别值(＝t2)。在这种情况下，由于交通id是出租车id，因此路线a2是非公共路线。

对于路径a3的通行计划(固定操作计划)，起点通过时间是12:56，并且终点通过时间是13:42。

路线a3的交通id是预先确定的列车id的识别值(＝d3)。在这种情况下，由于交通id是列车id，因此路线a3是公共路线。

对于路线a4的通行时间表，起点通过时间是13:50，终点通过时间是14:05。

路线a4的交通id是预先确定的出租车id的识别值(＝t4)。在这种情况下，由于交通id是出租车id，因此路线a4是非公共路线。

对于路线a5的通行计划(固定操作时间表)，起点通过时间是15:20，并且终点通过时间是19:20。

路线a4的交通id是预先确定的飞机id的识别值(＝p5)。在这种情况下，由于交通id是飞机id，因此路线a5是公共路线。

从以上描述中显而易见的是，图2中所示的路线信息a以从出发地到目的地的顺序由以下路线a1至a5的组合组成。

1)路线a1，其是徒步路线

2)路线a2，其是使用出租车的非公共路线

3)路线a3，其是使用列车的公共路线

4)路线a4，其是使用出租车的非公共路线

5)路线a5，其是使用飞机的公共路线

移动终端2在其显示单元23上显示已经从管理装置1接收并且由至少一个多模式路径组成的路线信息(步骤st4)，并且接收由用户执行的路线信息选择输入。

当用户用操作单元24选择路线信息时，移动终端2将输入的选择结果发送到管理装置1(步骤st5)。在接收到选择结果时，管理装置1向移动终端2发送选择响应(步骤st6)。

在接收选择响应时，移动终端2基于选择的路线信息(这里，图2中所示的路线信息a)开始路线引导(步骤st7)。

具体地，移动终端2使显示单元23显示包括路线信息a中包括的路线a1至a5的地图信息。路线引导可以伴随语音。

已发送选择响应的管理装置1执行当用户使用构成路线信息a的路线a1至a5时所需的各种布置(步骤st8)。

具体地，管理装置1将订单消息发送到出租车公司的预订管理服务器5，使得将出租车分派到路线a2的起点通过时间之前的起点。

该订单消息包括：路线信息a的用户id(＝x)；路线a2的通行计划(例如，起点、终点、起点出发时间和终点到达时间)；和分配给路线a2的出租车id(＝t2)。预订管理服务器5将从管理装置1提供的这些信息提供给要分派的出租车的车载终端3。除了上述信息之外，订单消息可以包括路线a2的从起点到终点的车辆行进路径以及行进计划。车辆行进路径和行进计划可以不包括在订单消息中，而是可以设置在出租车侧(车载终端3等)上。

管理装置1将订单消息发送到出租车公司的预订管理服务器5，使得将出租车分派到路线a4的起点通过时间之前的起点。

该订单消息包括：路线信息a的用户id(＝x)；路线a4的通行计划；和分配给路线a4的出租车id(＝t4)。预订管理服务器5将从管理装置1提供的这些信息提供给要分派的出租车的车载终端3。除了上述信息之外，订单消息可以包括路线a4的从起点到终点的车辆行进路径以及行进计划。车辆行进路径和行进计划可以不包括在订单消息中，而是可以设置在出租车侧(车载终端3等)上。

管理装置1将用于将在路线a5的起点通过时间出发的航班的机票的预订消息发送到能够提供使用位于路线a5的起点的机场的航班的航空公司的预订管理服务器5。

当路线a2的行进装置的交通id是自有车辆id时，管理装置1将路线信息a的用户id(＝x)、路线a2的通行计划和分配给路线a2的自有车辆id发送到自有车辆的车载终端3。这同样适用于路线a4的情况。

[徒步路线中的改道确定处理]

图3是示出徒步路线中的改道确定处理的示例的流程图。

尽管下面将“移动终端2”描述为操作主体，但是实际执行该处理的操作主体是移动终端2的控制单元26。这里，术语“改道”意味着关于正在行进于已经获取的多模式路径(这可以是第一多模式路径或第二多模式路径)的预先确定的用户id(＝x)的移动终端2的多模式路径搜索处理的重新执行。

如图3所示，移动终端2确定当前保持的路线信息a是否包括徒步路线a1(步骤st11)。

当确定结果为否定时，移动终端2结束处理。当确定结果为肯定时，移动终端2执行徒步路线监视处理(步骤st12)。

“监视处理”是基于包含在路线信息a中的通行计划，计算和评估计划通过点与相应的计划通过时间(计划值)和实际通过点和通过时间(实际值)之间的差异的处理。

因此，在徒步路线监视处理中，移动终端2计算作为徒步路线的路线a1的计划通过点和计划通过时间(计划值)和实际通过点和通过时间(实际值)之间的差异。另外，移动终端2确定计划值与实际值之间计算的偏差是否大(步骤st13)。

例如，当当前时间是12:30并且当前位置与路线a1的终点(计划通过点)之间的距离不小于预先确定的距离(例如，300m)时，移动终端2确定计划值与实际值之间的差异大。

同样，当当前位置是路线a1的终点(计划通过点)并且当前时间与路线a1的终点处的计划通过时间(＝12:30)之间的时间差不小于预先确定的时间(例如，5分钟)时，移动终端2确定计划值与实际值之间的偏差大。

当确定结果为肯定时，由于确定移动终端2没有按照计划行进徒步路线，所以移动终端2将改道请求发送到管理装置1(步骤st14)。移动终端2使用户id(＝x)和移动终端2的当前位置包括在改道请求中。当前位置是管理装置1执行改道时的离开位置。

当确定结果为否定时，移动终端2不向管理装置1发送改道请求，并维持当前路线信息a(步骤st15)。

[非公共路线中的改道确定处理]

图4是示出非公共路线中的改道确定处理的示例的流程图。

尽管下面将“车载终端3”描述为操作主体，但是实际执行该处理的操作主体是车载终端3的控制单元36。

当由管理装置1指定车辆行进路径和时间时，车载终端3通过引导驾驶员或通过沿指定路径和时间的自动驾驶来使车辆行进。当车载终端3仅从管理装置1接收通行计划时，车载终端3自己设定车辆行进路径和时间，并且通过引导驾驶员或通过沿设定路径和时间的自动驾驶使车辆行进。

在由于发生意外交通拥堵或者驾驶员的驾驶偏离路径的情况导致车辆不能在计划时间到达目标路线中指定的终点的情况下，执行改道。在车辆不能在计划时间到达指定起点的情况下，该信息从车载装置3发送到管理装置1等，这使得管理装置1、移动终端2等能够执行改道。

如图4所示，车载终端3确定已经从管理装置1通知的预先确定的用户id(＝x)的用户是否已经进入车辆(步骤st21)。

基于例如是否存在由非公共车辆的驾驶员对车载终端3的用于乘车确认的操作输入来执行该确定。当从管理装置1通知的用户id(＝x)与用户的移动终端2呈现的用户id一致时，非公共车辆的驾驶员(例如，出租车的驾驶员)应该执行用于乘车确认的操作输入。

在移动终端2和车载终端3能够通过wifi通信等彼此直接通信的情况下，可以通过终端2和终端3之间的直接通信来执行通过检查用户id的乘车确认。

当确定结果为否定时，车载终端3结束处理。当确定结果为肯定时，车载终端3将乘车确认发送到管理装置1(步骤st22)，然后执行非公共路线监视处理(步骤st23)。

如上所述，“监视处理”是基于包括在路线信息a中的通行计划计算和评估计划通过点与相应的计划通过时间(计划值)和实际通过点和通过时间(实际值)之间的偏差的处理。

因此，在非公共路线监视处理中，车载终端3计算是非公共路线的路线a2(a4)的计划通过点和计划通过时间(计划值)与实际通过点和通过时间(实际值)之间的偏差。另外，车载终端3确定计划值与实际值之间计算的偏差是否大(步骤st24)。

例如，假设路线a2包括：是中间计划通过点的预先确定的交叉点j2的位置信息；以及对应于计划通过点的计划通过时间(＝12:40)。

在这种情况下，当当前时间是12:40并且当前位置和交叉点j2的位置之间的距离不小于预先确定的距离(例如，1000m)时，车载终端3确定计划值和实际值之间的偏差大。

同样，当当前位置是交叉点j2的位置并且当前时间与在交叉点j2处的计划通过时间(＝12:40)之间的时间差不小于预定时间(例如，5分钟)时，移动终端2确定计划值和实际值之间的偏差大。

当确定结果为肯定时，由于确定车载终端3没有按照计划行进非公共路线，因此车载终端3将改道请求发送到管理装置1(步骤st25)。车载终端3使非公共id(＝t2或t4)和车载终端3的当前位置包括在改道请求中。当管理装置1执行改道时，当前位置是出发位置。

当确定结果为否定时，车载终端3不向管理装置1发送改道请求，并维持当前路线信息a(步骤st26)。

即使在确定结果为肯定并且车辆不能在计划时间到达某个计划通过点的情况下，如果因为例如前方的交通状况的恢复，或者车载终端3的行进路线设定的变化，能够确定车辆将最终在计划时间到达终点，车载终端3不需要向管理装置1发送改道请求。

当确定车辆不能根据管理装置1指定的通行计划行进时，可以执行对管理装置1的改道请求。

[公共运输工具的乘车等的确认]

在根据本实施例的路径搜索系统中，诸如固定线路的公共汽车、列车和飞机的公共运输工具的行进装置没有提供有与管理装置1可通信的通信终端。

因此，当移动终端2及时到达使用公共运输工具的路线a3(a4)的起点时，移动终端2的控制单元13优选地向管理装置1发送包括移动终端2的用户id(＝x)的乘车确认。

因此，即使当公共运输工具的行进装置不能与管理装置1通信时，已经接收到包括预先确定的用户id(＝x)的乘车确认的管理装置1能够检测具有用户id的移动终端2的用户已安全登上由多模式路径指定的公共运输工具。

对于移动终端2发送乘车(和/或下车)确认的触发，认为满足以下条件中的至少一个,例如:

条件1：移动终端2的当前位置与通行计划的起点一致，并且移动终端2的当前时间与通行计划的起点通过时间一致(一致的确定允许错误的预先确定的空间)。

条件2：移动终端2的操作单元34已经接收到用户执行的用于乘车/下车确认的操作输入。

条件3：已经检测到移动终端2通过预先确定的门(例如，列车站的验票口)。

[管理装置为每个用户id的改道确定处理]

图5是示出由管理装置1为每个用户id的改道确定处理的示例的流程图。

尽管下面将“管理装置1”描述为操作主体，但是实际执行该处理的操作主体是管理装置1的控制单元13。

如图5所示，管理装置1确定是否已从预先确定的用户id(＝x)的移动终端2接收改道请求(步骤st31)。

当步骤s31中的确定结果为肯定时，管理装置1为用户id(＝x)执行改道，并将搜索结果发送到相同用户id(＝x)的移动终端2(步骤st35)。在这种情况下的改道是多模式路径搜索处理，其在是出发位置的包括在改道请求中的移动终端2的当前位置执行。

当步骤s31中的确定结果为否定时，管理装置1还确定是否已经从与预先确定用户id(＝x)对应的非公共id(＝t2或t4)的车载终端3接收到改道请求(步骤st32)。

当步骤s32中的确定结果为肯定时，管理装置1为用户id(＝x)执行改道，并将搜索结果发送到相同用户id(＝x)的移动终端2(步骤st35)。在这种情况下的改道是多模式路径搜索处理，其在是出发位置的包括在改道请求中的车载终端3的当前位置执行

当步骤s32中的确定结果为否定时，管理装置1还确定用户id(＝x)的路线信息a是否具有当前时间点上和之后的路线的环境改变(步骤st33)。

“环境改变”指示由于严重的交通拥堵、显著的天气波动、正在举行的事件等导致道路突然堵塞或公共运输工具的计划服务停止的情况。

当步骤s33中的确定结果为肯定时，管理装置1为用户id(＝x)执行改道，并将搜索结果发送到相同用户id(＝x)的移动终端2(步骤st35)。

当步骤s33中的确定结果为否定时，管理装置1不为用户id(＝x)执行改道，并且维持用户id(＝x)的路线信息a(步骤st34)。

[管理装置为每个公共id的改道确定处理]

图6是示出管理装置1为每个公共id的改道确定处理的示例的流程图。

尽管下面将“管理装置1”描述为操作主体，但是实际执行该处理的操作主体是管理装置1的控制单元13。

如图6所示，管理装置1确定多个用户id(＝xi(i＝1、2、...))是否与一个公共id(假设为图2中所示的列车id＝d3)相关联(步骤st41)。

对应于该一个列车id(＝d3)的多个用户id(＝xi)意味着正在经过包括列车id(＝d3)的公共路线的多模式路径的多个用户在对应的列车上。

当确定结果为否定时，管理装置1结束处理。当确定结果为肯定时，管理装置1执行公共路线监视处理(步骤st42)。

如上所述，“监视处理”是基于包括在路线信息a中的通行计划来计算和评估计划通过点和对应的计划通过时间(计划值)与实际通过点和通过时间(实际值)之间的偏差的处理。

然而，对于使用公共运输工具的公共路线，由于已经建立了固定操作计划，因此能够通过确定当前时间的操作计划是否是固定来评估计划值和实际值之间的偏差。

因此，在公共路线监视处理中，管理装置1向操作管理服务器6询问与路线a3对应的列车id(＝d3)的操作计划的状态，并确定操作状态中的变化是否大(步骤st43)。

在本实施例中，在由于例如事故的发生而使列车id(＝d3)的操作计划的延迟不小于预先确定的时间(例如，15分钟)的情况下，管理装置1确定操作状态中的变化大。

当确定结果为肯定的时，管理装置1对与列车id(＝d3)对应的多个用户id(＝xi)执行改道，并将搜索结果发送到各个用户id(＝xi)的移动终端2(步骤st44)。

在这种情况下，管理装置1执行改道，当执行上述确定时，该改道使用户在最近的车站下车，并且转移到包括另一路线中的列车的另一行进装置。例如，能够将出租车分派到最近的车站。在因为存在许多目标用户以及让他们赶去该站的出租车而预测交通拥堵的发生的情况下，管理装置1能够执行交通信号控制的指令以减少交通拥堵。

即使当确定结果为肯定的，如果管理装置1已经确定用户将在计划时间到达目的地，则管理装置1不需要执行改道。对每个用户id进行该确定。在登上相同列车的用户中，在列车之后的路线中有空闲时间的用户可能不需要改道。

当确定结果为否定时，管理装置1不对与列车id(＝d3)对应的多个用户id(＝xi)执行改道，并维持用户id(＝xi)的当前路线信息(步骤st45)。

[路线信息的图像图]

图7是示出路线信息a中包括的路线a1至a5的图像图。

路线信息a是由管理装置1计算的多模式路径的示例，其中，例如用户的家是出发地且另一州的机场是目的地。图7中所示的路线信息a与图2中所示的路线信息a相同，并且以从出发地的次序依次包括五个路线a1至a5。

具体地，路线a1是徒步路线，路线a2是使用出租车的非公共路线，路线a3是使用列车的公共路线。

路线a4是使用共享出租车的非公共路线，且路线a5是使用飞机的公共路线。路线a5的终点是机场，该机场是目的地。

图8是示出包括在另一路线信息b中的路线b1至b5的图像图。

路线信息b是由管理装置1计算的多模式路径的示例，其中作为商务旅行的位置的客户的公司是出发地并且另一州中用户的家是目的地。图8中所示的路线信息b以从出发地的次序依次包括五个路线b1至b5。

具体地，路线b1是徒步路线，路线b2是使用公共汽车的公共路线，路线a3是使用列车的公共路线。

路线b4是使用共享出租车的非公共路线，路线b5是徒步路线。

在图8中所示的路线信息b中，由于如上所述在路线b3中的列车的操作中发生了显著延迟，管理装置1对已经登上列车id的列车的多个用户id执行改道。

因此，路线b3之后的路线b4和路线b5对应于通过管理装置1的改道计算出的多模式路径。

如上所述，根据本实施例的管理装置1能够对在属于其管理区域的交叉点处提供的交通信号单元执行交通致动控制。

因此，优选地，使用例如允许在路线b4中使用的共享出租车很可能在绿灯中通过路线b4中的交叉点的信号控制参数来执行交通信号控制。因此，可以尽可能地弥补在使用列车的路线b3中发生的延迟。

[本实施例的效果]

根据本实施例的路径搜索系统，管理装置(路径搜索装置)1的控制单元13使路线a1至a5的通行计划和用于沿与用户id相关联的路线a1至a5行进的行进装置的识别信息(＝交通id)包括在多模式路径的数据内容中(参见图2)。

因此，能够使诸如移动终端2的本地终端执行关于用户是否正按计划地行进路线a1至a5的监视处理，从而可以适当地分散用于多模式路径监视处理的处理负荷。

例如，在本实施例的路径搜索系统中，移动终端2基于徒步路线a1的通行计划监视移动终端2是否正按照计划行进徒步路线a1(图3中的步骤st12、st13)。当监视结果为否定时，移动终端2向管理装置1发送使管理装置1重新执行搜索处理的改道请求(图3中的步骤st14)。

因此，即使当用户不能按照计划行进徒步路线a1时，移动终端2能够接收由管理装置1新生成的替选多模式路径，从而为用户提供未来的有效的未来的路线信息。

在本实施例的路径搜索系统中，车载终端3基于非公共路线的通通行计划监视自有车辆是否正按照计划行进非公共路线a2(a4)(图4中的步骤st23，st24)。当监视结果为否定时，车载终端3向管理装置1发送使管理装置1重新执行搜索处理的改道请求。

因此，即使当用户不能按照计划行进非公共路线a2(a4)时，车载终端3能够接收由管理装置1新生成的替选多模式路径，从而为用户提供未来的有效的未来的路线信息。

在本实施例的路径搜索系统中，管理装置1的控制单元13基于公共路线a3的通行计划监视公共运输工具是否正按照计划行进公共路线a3(a5)(图6中的st42、st43)。当监视结果为否定时，控制单元13为与公共运输工具的交通id对应的所有用户id重新执行搜索处理(图6中的st44)。

因此，能够基于一个公共路线的监视结果来执行多个用户id的移动终端2的改道。

因此，与使用相同公共路线的多个用户id中的每个移动终端2执行公共路线监视处理的情况相比，能够减少整个系统的处理负荷。

根据本实施例的路径搜索系统，管理装置1响应于来自移动终端2的搜索请求搜索多模式路径，并且移动终端2在接收搜索结果时，显示用于该用户的多模式路径。

因此，在充分利用多模式路径的同时，用户能够沿最适合他/她需求的路线前往目的地。

根据本实施例的路径搜索系统，当为了用户方便需要改变路线或者改变公共运输工具的操作状态时，通过管理装置1的改道生成新的多模式路径，并且为用户提供生成的多模式路径。因此，用户能够灵活地应对行进期间的环境改变。

根据本实施例的路径搜索系统，管理装置1聚合为大量用户生成的多模式路径，从而优化运输资源，并优化社会中的能量消耗。

当将多模式路径的跟踪(监视)委托给本地电子设备时，能够减少管理装置1的处理负荷。

具体地，当用户使用公共运输工具时，管理装置1可以使用公共运输工具共同管理用户id，并跟踪公共运输工具的操作状态。因此，能够实现管理装置1的处理量的减少和信息通信资源的减少。

[第一变型]

在上述实施例中，移动终端2的识别信息(以下称为“移动id”)被用作用户id，使得用户id和移动id彼此不区分。然而，管理装置1可以管理唯一用户id和与用户id相关的移动id。

具体地，管理装置1可以将通过用户在管理装置1的网站中输入而已经指定的唯一用户id(＝xi(i＝1,2，...))与在输入时确定的唯一移动id(＝yj(j＝1,2，...))相关联，并且可以管理这些id。

在这种情况下，当接收包括移动id＝y1的搜索请求时，管理装置1可以认为该搜索请求来自与移动id＝y1对应的用户id＝x1，并且可以执行用于用户id＝x1的用户的多模式路径搜索处理。

此外，在徒步路线中，仅移动id(＝y1)的移动终端2与用户id(＝x1)的用户一起行进。因此，管理装置1可以将移动终端2认为徒步路线a1中的行进装置，并且可以将移动id(＝y1)结合在交通id中。

在使用移动id作为用户id的上述实施例中，路线a1至a5的监视处理的主体如下。

1)公共路线a3和a5的监视处理由管理装置1执行。

2)除了公共路线a3和a5之外的路线a1、a2和a4的监视处理由用户id(＝x1)移动终端2执行或由与用户id(＝x1)相关联的交通id(＝t2)或出租车id(＝t4))的车载终端3执行。

在其中与用户id相关联地定义移动id的本变型中，路线监视处理的主体如下。

1)公共路线a3和a5的监视处理由管理装置1执行。

2)除了公共路线a3和a5之外的路线a1、a2和a4的监视处理由移动终端2执行或由具有与用户id(＝x1)相关联的交通id(移动id(＝y1)、出租车id(＝t2)或出租车id(＝t4)的车载终端3执行。

如上所述，在任何情况下，公共路线a3和a5的监视处理由管理装置1执行，而路线a1、a2和a4的监视处理由诸如移动终端2的本地终端执行，并且作为行驶方式的车载终端3由路线a1、a2和a4的交通id定义。

在从任何上述本地终端接收改道请求时，管理装置1为改道请求中包括的用户id或者对应于改道请求中包括的交通id(移动id(＝y1或出租车id(＝t4))的用户id执行改道。

[第二变型]

在上述实施例(包括第一变型)中，当车载终端3已经按照计划行进其分配的路线时，车载终端3可以向管理装置1发送路线完成通知。

在这种情况下，即使当已经通过分配给交通id的路线的终点通过时间时，如果既没有来自车载终端3的预先确定的交通id的改道请求也没有来自车载终端3的预先确定的交通id的路线完成通知，则管理装置1优选地向移动终端2发送关于车载终端3是否已经按照计划行进的确认请求。

在接收确认请求时，移动终端2可以基于移动终端2的当前位置和当前时间，确定移动终端2是否已经按照计划行进了分配给车载终端3的路线，并且可以将确定结果发送给管理装置1。

因此，即使当车载终端3由于临时通信故障等而不能与管理装置1通信时，可以使移动终端2执行关于用户是否已经按照计划行进的监视处理。

[其他变型]

这里公开的实施例(包括变型)在所有方面都是说明性的，并且应该被认为不是限制性的。本发明的范围不受上述实施例的配置的限制，而是由权利要求限定，并且旨在包括与权利要求的范围等同的含义以及在范围内的所有变型。

在上述实施例中，可以不对路线a1至a5中的所有而是对路线a1至a5中的至少一个进行通行计划与行进装置的识别信息(＝交通id)的关联。

在上述实施例中，管理装置1可以聚合包括在来自大量用户id的搜索请求中的od信息，并且可以将聚合的od信息用于诸如交通信号控制的交通控制。

在上述实施例中，管理装置1可以通过使用来自大量用户id的搜索请求中包括的od信息来预测预先确定的公共运输工具的拥堵状态。此外，管理装置1可以在接收来自用户的搜索请求时向用户提供拥堵状态。

例如，基于与相同列车id相关联的用户id的数量和列车上预先确定的乘客的数量计算“占用率”，并且当显示行进路线时显示占用率。参考占用率，即使到达目的地的到达时间被延迟，用户也可以避开拥挤的列车，或者如果他/她希望在计划时间到达目的地，则可以按照计划乘坐拥堵的列车。

在上述实施例中，路线被分类为徒步路线、公共路线和非公共路线。非公共路线可以进一步被分类为多种类型，并且诸如优先级和路线计算的条件可以根据路线类型而变化。

参考符号列表

1管理装置(路径搜索装置)

2移动终端

3车载终端

4公共通信网络

5预约管理服务器

6操作管理服务器

7天气服务器

8事件服务器

9交通信号控制器

11通信单元

12存储单元

13控制单元

21无线通信单元

22位置检测单元

23显示单元

24操作单元

25存储单元

26控制单元

31无线通信单元

32位置检测单元

33显示单元

34操作单元

35存储单元

36控制单元