移动服务系统以及移动服务提供方法与流程

本发明涉及利用使用者的不满的程度来控制交通服务的车辆运行的技术。

背景技术：

通常，在公共交通服务中，服务提供者预先确定并运用服务内容。即，服务提供者预先决定车辆运行的时间表(时刻表)，按照该时间表来运行车辆。

与此相对，在专利文献1中公开了如下技术：当判定为根据时间表而在运行路线运行的公共汽车于预定的时刻未到达检查点数时，调度临时车辆。

在专利文献2中公开了用于使其他使用者共享提供者的车辆的技术。在积蓄提了供者的车辆的移动路径的过去的实际成绩信息并参照该实际成绩信息制定了移动计划之后，向车辆的提供者接受拼车的委托，在提供者接受委托后，使拼车希望者共享提供者的车辆。

在专利文献3中公开了通过使用了车辆的虚拟的假设对象的计算机仿真来再现并评价交通状况的技术。

在非专利文献1中，公开了针对人的移动(乘用车)和物体的移动(货车)推测交通量，推测包括产生集中交通量、分布交通量以及分配交通量的将来的交通需求的计算式以及参数。

现有技术文献

专利文献

专利文献1：日本特开2006-163738号公报

专利文献2：日本特开2015-191364号公报

专利文献3：日本特开2013-080272号公报

非专利文献

非专利文献1：“技术调查未来交通需求推测的重新评估”，国土交通部、(http://www.mlit.go.jp/tec/tec_mn_000003.html(2018年12月11日))

技术实现要素：

发明所要解决的课题

如上所述，在现有的公共交通服务中，没有将使用者怀有的不满定量地反映到车辆的运行中。

本公开的一个目的在于提供一种技术，通过将使用者的不满的程度反映到车辆的运行中，能够改善对使用者的交通服务。

用于解决课题的手段

本公开的一个移动服务系统提供使移动资源运行而使使用者移动的服务，该移动服务系统具有：第一管理装置，其存储与所述使用者相关的第一数据库，对所述使用者的请求进行管理；第二管理装置，其存储与所述移动资源相关的第二数据库，对所述移动资源的运行的状态进行管理；以及第三管理装置，其与所述第一管理装置以及所述第二管理装置协作来变更所述移动资源的运行，所述第三管理装置以数值获取所述使用者产生的不满，所述第一管理装置根据所述不满，赋予为了实施针对所述移动资源的运用的请求而能够利用的点数，将每个使用者的点数记录于所述第一数据库，所述第三管理装置从所述使用者接受请求，作为与所述第一数据库中管理的对该使用者赋予的点数的交换，基于所述请求和在所述第二数据库中管理的所述移动资源的运行的状态，变更所述移动资源的运行的计划。

发明效果

根据本公开，通过将使用者的不满的程度反映到车辆的运行中，能够提高对使用者的交通服务。

附图说明

图1是表示本实施方式所涉及的需求管理型交通服务系统的硬件结构的框图。

图2是用于说明本实施方式的需求管理型交通服务系统的各服务器装置的硬件结构的框图。

图3是用于说明本实施方式的需求管理型交通服务系统的各终端装置的硬件结构的框图。

图4是乘客信息管理服务器具备的居民数据库的er图。

图5是表示居民参数的模式的表。

图6是公共汽车运行管理服务器具备的公共汽车数据库的er图。

图7是表示公共汽车行驶日志13-45的模式的表。

图8是运行计划服务器具备的统计数据库的er图。

图9是表示按区域统计结果的模式的表。

图10是表示应用本实施方式的需求管理型交通服务系统的整体服务区域的一例的图。

图11是表示本实施方式的需求管理型交通服务系统的在线的运行计划的变更的情况的路线概念图。

图12是表示变更运行计划时的乘客信息终端的画面例的图。

图13是表示本实施方式的需求管理型交通服务系统的请求的处理的时序图。

图14是需求管理型交通服务系统从乘客获取对问卷调查的回答的处理的时序图。

图15是表示显示了对不满进行统计后的结果的gui的画面例的图。

图16是表示将统计各区域的不满后的结果按每个区域显示的gui的画面例的图。

图17是表示制定公共汽车运行计划的处理的时序图。

具体实施方式

在本实施方式中，作为为了使乘客移动而运行的移动资源而例示公共汽车。本实施方式的系统是提供运行公共汽车而使乘客移动的服务的系统。本服务是能够成为乘客的使用者能够请求公共汽车的运行的变更的服务。公共汽车是移动资源的一例，并不限定于此。既可以是本例的其他陆地交通工具，也可以是水上交通工具、空中交通工具等。

以下，参照附图对本实施方式进行说明。

此外，以下说明的实施方式并不是用于限定发明的实施方式。另外，在实施方式中说明的各要素及其组合的全部并不是发明所必须的。

图1是表示本实施方式所涉及的需求管理型交通服务系统的硬件结构的框图。

在图1中，需求管理型交通服务系统包括运行计划服务器11、乘客信息管理服务器12、公共汽车运行管理服务器13以及公共汽车运行指示终端14。公共汽车运行指示终端14是能够供乘务员操作而搭载于公共汽车车辆、或者公共汽车的乘务员携带的信息处理终端。在公共汽车运行指示终端14中显示对乘务员指示公共汽车的运行的信息。

乘客信息终端15是利用公共汽车的乘客所携带的终端，可以是乘客所持有的智能手机等移动终端。

运行计划服务器11通过网络16与乘客信息管理服务器12、公共汽车运行管理服务器13、公共汽车运行指示终端14以及乘客信息终端15相互连接。

网络16的形态例如有在乘客信息管理服务器12以及公共汽车运行管理服务器13通过有线网络连接，公共汽车运行指示终端14以及乘客信息终端15通过无线网络连接的情况。但是，对于网络16的哪个部分为有线网络或者无线网络没有特别限定。

图2是用于说明本实施方式的需求管理型交通服务系统的各服务器装置的硬件结构的框图。运行计划服务器11、乘客信息管理服务器12和公共汽车运行管理服务器13是基本的硬件结构通用的信息处理装置，该硬件结构如图2所示。

参照图2，信息处理装置具有cpu1-01、存储器1-02、通信nic(networkinterfacecard：网络接口卡)1-03、硬盘驱动器(以下，称为hdd)1-04、输入输出控制器1-05、监视器控制器1-06、公共汽车1-07、显示器1-13、键盘1-11和鼠标1-12。cpu1-01、存储器1-02、通信nic1-03、hdd1-04、输入输出控制器1-05和监视器控制器1-06与公共汽车1-07连接。输入输出控制器1-05连接到键盘1-11和鼠标1-12。在监视器控制器1-06上连接有显示器1-13。

cpu1-01通过执行存储器1-02上的软件程序来实现各服务器的功能。

存储器1-02是存储用于实现服务器的功能的软件程序以及用于该软件的处理的各种数据的装置。

通信nic1-03是用于服务器与网络16连接并收发数据等的装置。

hdd1-04存储有用于服务器的处理的数据库。例如，在乘客信息管理服务器12的hdd1-04中存储有蓄积了与居民相关的信息的数据库。另外，在公共汽车运行管理服务器13的hdd1-04中存储有蓄积了与公共汽车相关的信息的数据库。

输入输出控制器1-05是控制键盘1-11以及鼠标1-12向服务器的数据的输入输出的装置。

监视器控制器1-06是控制向显示器1-13的画面的显示的装置。

显示器1-13是对操作者显示包含图像或文本的画面的显示装置。

键盘1-11以及鼠标1-12是接受操作者的操作，并将操作的数据输出到输入输出控制器1-05的装置。

图3是用于说明本实施方式的需求管理型交通服务系统的各终端装置的硬件结构的框图。公共汽车运行指示终端14和乘客信息终端15是基本的硬件结构类似的信息处理装置，用于说明的硬件结构如图3所示。

图3的终端装置具有触摸面板1-15来代替图2的服务器装置中的键盘1-11、鼠标1-12以及显示器1-13。另外，终端装置中的乘客信息终端15具有gps(globalpositioningsystem：全球定位系统)模块1-08和ic读取模块1-14。

触摸面板1-15是对乘客显示画面且受理乘客对画面的操作的装置。

gps模块1-08是接收来自gps卫星的电波并输出自身的位置信息的装置。位置信息作为表示乘客的位置的信息而用于处理。

ic读取模块1-14是读取并输出记录在ic卡中的数据的装置。从ic卡读出的数据也可以用于处理。

图4是乘客信息管理服务器具备的居民数据库的er(entityrelationship：实体关系)图。居民数据库12-40是本需求管理型交通服务系统提供服务的服务区域的居民。假定该居民成为公共汽车的乘客。居民数据库12-40包括居民参数12-41、请求发出信息12-42和请求消化日志12-43。在居民参数21-41中设定有与能够成为本系统的公共汽车的乘客的地域的各居民相关的各种信息。在请求发出信息12-42中设定有与居民发出的请求相关的信息。在由居民参数12-41管理的1名居民中，能够应对0个以上的请求。

请求中包含关于乘客(想要乘坐公共汽车的居民)对公共汽车的乘车进行请求的要求事项。也存在请求中包含需要变更公共汽车的运行这样的请求的情况。当采用请求并实施时，该请求被消化。

请求消化日志12-43是与居民所发出的请求的消化相关的信息。当发出请求时，在请求发出信息表12-42中登记该请求的索引(未图示)。索引包括发出了请求的乘客、该乘客乘坐的公共汽车、乘客乘坐公共汽车的乘车场所、乘客下车的下车场所的信息。

之后，当执行该请求时，将该请求被消化的情况作为日志信息记录在请求消化日志表12-43中。请求是通过乘客乘坐公共汽车和从公共汽车下车而执行的。在采用需要公共汽车运行的变更的请求的情况下，请求的执行伴随公共汽车的运行的变更。

对需求管理型交通服务系统提供的服务产生的居民不满被作为点数而积累。当居民作为乘客而使用公共汽车时，需求管理型交通服务系统通过在该乘客从公共汽车下车时，求出对调查问卷的回答，来得知该居民与公共汽车的运行相关联的不满。点数是用于请求将公共汽车的运行变更为适合自身的情况的虚拟债券。当采用作为公共汽车的乘客的某个居民发出的请求时，伴随着请求的采用，能够期待发出了请求的居民的不满度降低。而且，该居民所持有的点数中，因采用该请求而消化仅抵消推定发生的其他居民(乘坐在同一公共汽车上的其他乘客)的不满的点数。另一方面，根据另外进行的不满的表明，对乘坐在相同的公共汽车上的其他乘客赋予点数。

居民参数12-41中包含居民id、不满度(时间/拥挤/就座/噪音/场所)、不满度相关的系数(时间/拥挤/就座/噪音/场所)、所有点数、居民的住址坐标(经度、纬度)、徒步速度[km/h]、表示噪音的产生水平的参数、请求时刻决定用的随机数生成参数(去程μ、去程σ、回程μ、回程σ)、居民的属性(性别、年龄、职业、其他)这样的项目。图5是表示居民参数的模式的表。在居民参数12-41的各项目中，按照图5所示的模式设定信息。

居民id是分别识别各居民的识别信息。

不满度是用数值表示该居民的不满的程度的信息。不满包括与时间相关的不满、与拥挤相关的不满、与就座相关的不满、与噪音相关的不满、与场所相关的不满。与时间相关的不满是指由于公共汽车的到达的延迟而导致该居民对在公共汽车的车站(公共汽车站)等待的时间的不满。与拥挤相关的不满是针对该居民所搭乘的公共汽车内的拥挤的不满。与就座相关的不满是指对在该居民搭乘的公共汽车上不能坐在座位上的不满。与噪音相关的不满是针对该居民搭乘的公共汽车内的噪音的不满。与场所相关的不满是指对公共汽车的搭乘之前或者之后该居民步行的距离的不满。例如如果出发场所和乘车场所不同，则居民需要在其间步行。另外，如果下车场所和到达场所不同，则居民需要在其间步行。

与不满度相关的系数是表示该居民分别对时间、拥挤、就座、噪音、或场所的不满的重视程度的值。

所有点数是表示该居民所拥有的点数的信息。

居民的住址坐标是表示该居民的住址的信息，由经度和纬度表示。

徒步速度是表示该居民的步行速度的信息，以km/h这一单位表示。

表示噪音的产生水平的参数是表示由于该居民搭乘而导致公共汽车内的噪音增大的程度的参数。

请求时刻决定用的随机数生成参数是用于决定发出请求的时刻的参数。作为请求时刻决定用的随机数生成参数，设定去程的出发时刻的平均值μ及标准偏差σ、回程的出发时刻的平均值μ及标准偏差σ。

居民的属性是表示该居民的各种属性的信息。居民的属性包括性别、年龄、职业等。

图6是公共汽车运行管理服务器具备的公共汽车数据库的er图。在公共汽车数据库13-40中包含公共汽车车体参数13-41、公共汽车折返发车预定时刻13-42、公共汽车基本路径的移动顺序-车站对应表13-43、基本路径上的车站13-44以及公共汽车行驶日志13-45。

公共汽车车体参数13-41是与作为本系统的移动资源而使乘客移动的各公共汽车车体相关的信息。在公共汽车车体参数表13-41中有公共汽车车体id、公共汽车识别名、公共汽车基本路径id、运费收入[日元]、行驶距离[km]、运费计算用的系数的索引，在各索引中记载有信息。

公共汽车折返发车预定时刻13-42是与从各公共汽车车体的始发场所的运行相关的信息。通常，1台公共汽车车体被用于1次以上的运行，因此在公共汽车折返发车预定时刻表13-42中，对于1台公共汽车车体记录有与1个以上的运行相关的信息。在公共汽车折返发车预定时刻表13-42中有公共汽车车体id、公共汽车的出发方向(例如是否为相反方向)、发车时刻的索引(未图示)，在各索引中记载有信息。

公共汽车基本路径的移动顺序-车站对应表13-43是与各公共汽车车体的运行中的基本路径相关的信息。基本路径是如果没有变更请求则公共汽车运行的预定路径。通常，多个公共汽车车体运行一个基本路径。另外，通常，1台公共汽车车体运行多个基本路径。在公共汽车基本路径的移动顺序-车站对应表13-43中，有公共汽车基本路径id、车站顺序编号、车站id的索引(未图示)，在各索引中记载有信息。

基本路径上的车站13-44是与位于基本路径上的各车站相关的表信息。在基本路径上的车站13-44的表中，有各车站的车站id、车站名称、gis节点id、车站类别的索引(未图示)，在各索引中记载有信息。

gis节点id是对地理信息系统(gis(geographicinformationsystem：地理信息系统)的节点分别进行识别的识别信息。gis节点例如是十字路口。gis节点例如由节点编号、经度、纬度、几何学信息表示。

公共汽车行驶日志13-45是与各公共汽车车体的运行相关的历史记录信息的表。在公共汽车行驶日志13-45的表中，存在车体id、日期编号(哪天)、始发时刻、始发站、终点时刻、终点站、方向(是否为相反方向)、总乘车人数、行驶1次的运费收入[日元]、行驶1次的行驶距离[km]的索引(未图示)，在各索引中记载有信息。图7是表示公共汽车行驶日志13-45的模式的表。在公共汽车行驶日志13-45的各索引中，按照图5所示的模式来设定信息。

图8是运行计划服务器具备的统计数据库的er图。在统计数据库11-40中包含统计结果11-41、按区域统计结果11-42以及区域定义11-43。

统计结果11-41是对公共汽车运行的结果进行统计后的信息。在统计结果11-41的表中，有日期编号(哪天)、公共汽车的总运费收入(日计)[日元]、公共汽车的总行驶距离(日计)[km]的索引，在各索引中记载有信息。

按区域统计结果11-42是按每个区域对公共汽车运行的结果进行统计而得到的信息。区域是将整体服务区域划分为预定尺寸的矩形的区域。图9是表示按区域统计结果的模式的表。在按区域合计结果11-42的表中，有日期编号(哪天)、区域id、按区域满意度平均(终值)的索引(未图示)，在各索引中记载有按照图9所示的模式的信息。按区域满意度平均是按每个区域将时间、拥挤、就座、噪音以及场所的所有项目的不满的合计值设为负数的值。进而，也可以按时间、拥挤、就座、噪音以及场所的每个项目求出按区域满意度平均，并包含在统计结果11-42中进行记录。

区域定义11-43是整体服务区域中包含的各区域的定义信息。在区域定义11-43的表中，存在区域id、矩形坐标(左上坐标、右下坐标)的索引(未图示)，在各索引中记载有信息。

图10是表示应用本实施方式的需求管理型交通服务系统的整体服务区域的一例的图。作为一例，整体服务区域为面积约30平方公里、人口约12万人，公共汽车的使用者人数为约4500人/天。

在该整体服务区域中存在5个公共汽车定期运行的路线。它们分别是被称为绿线(gl)、红线(rl)、水色线(al：aqualine)、蓝线(bl)、黄线(yl)的路线。

图11是表示基于本实施方式的需求管理型交通服务系统的在线的运行计划的变更的情况的路线概念图。图12是表示变更运行计划时的乘客信息终端的画面例的图。

图11所示的公共汽车8-10是其信息在公共汽车车体参数表13-41中记载的公共汽车。公共汽车8-10从公交基本路径的移动顺序-车站对应表表13-43中记载的出发站8-01向到达站8-04运行。基本路径是经由出发车站8-01、固定站8-02、固定站8-03、到达站8-04的路径。固定站8-02、8-03是在变更运行计划时也必然需要通过的车站。

在此，在居民参数表12-41中记载的某乘客8-05使用乘客信息终端15发出请求向公共汽车乘车的请求。该请求由乘客信息管理服务器12登记在请求发出信息12-42表中。

乘客8-05在请求中能够任意指定乘客自身的出发场所8-06和到达场所8-07。例如，能够将自己家作为出发场所，将最终想要去的场所指定为到达场所。在图12所示的乘客信息终端15的画面例8-0501中，示出了指定出发场所和到达场所的例子。在画面例8-0501中，示出了指定自家作为出发场所、指定a医院作为到达场所的例子。另外，乘客8-05也可以提示在请求中想要使公共汽车停车到靠近出发场所的场所8-08的希望和/或想要使公共汽车停车到靠近到达场所的场所8-09的希望。

另外，乘客8-05也能够在请求中对其他各种希望指定优先。例如，能够指定使向希望的场所的停车比其他项目优先(场所优先)。另外，能够指定缩短在公交站等待的时间比其他项目优先(时间优先)。另外，能够指定车内空闲且空间上有富余的公共汽车比其他项目优先(间隙优先)。另外，能够指定能够坐在座位上比其他项目优先(座位优先)。另外，能够指定车内的噪音水平低比其他项目优先(安静优先)。在图12的画面例8-0502中，示出了与希望到达时刻一起指定时间优先时的画面例。图12的画面例8-0502是将画面例8-0501向下方滚动的一系列画面。

来自乘客8-05的请求在需求管理型交通服务系统中进行处理。后述请求的处理的详细内容。处理的结果，公共汽车8-10有时会从预先设定的基本路线偏离，在一定程度上停在靠近出发场所或到达场所的场所(例如，图11的场所8-11)，也存在停车在预先确定的基本路线上的场所8-12的情况。当进行与请求对应的公共汽车的运行时，公共汽车的运行的结果被记录在请求消化日志12-43中。

而且，当公共汽车8-10到达乘客8-05下车的场所(例如图11的场所8-09)时，需求管理型交通服务系统向乘客8-05的乘客信息终端15提示调查问卷，获取乘客8-05的回答。乘客8-05在公共汽车的利用中有不满的情况下能够通过该回答来表明不满。在图12的画面例8-0503中，示出了显示问卷调查并促使乘客回答的画面的例子。需求管理型交通服务系统从乘客获取对问卷调查的回答的处理的详细内容后述。

图13是表示本实施方式的需求管理型交通服务系统的请求的处理的时序图。

乘客信息终端15将与公共汽车的乘车相关的请求发送至运行计划服务器11(15-911)。接收到请求的运行计划服务器11向公共汽车运行管理服务器13提示出发场所和到达场所，询问乘客能够利用的公共汽车(11-911)。接收到询问的公共汽车运行管理服务器13基于所提示的出发场所以及到达场所，选择能够利用的公共汽车(13-911)，并通知运行计划服务器11。此时，通知1个以上的公共汽车。

接收到乘客能够利用的公共汽车的通知的运行计划服务器11在被通知的公共汽车中调查是否存在满足乘客希望的公共汽车(11-912)。

在存在满足乘客希望的公共汽车的情况下，运行计划服务器11选择该公共汽车(13-913)。

接着，运行计划服务器11调查请求中是否包含变更向靠近出发场所或到达场所的场所的公共汽车的路线的请求(以下，称为附近接载(pickup)请求)(11-914)。在附近接载请求的情况下，运行计划服务器11将靠近出发场所的车站作为乘客应乘坐的车站，将靠近到达场所的车站作为乘客应下车的车站，将这些车站作为停车点(11-915)，将乘客能够利用的1个以上的公共汽车的候补与停车点数一起通知给乘客信息终端15。乘客信息终端15将所通知的公共汽车信息显示为乘客要利用的候补(15-912)。

在步骤11-914中，在存在附近接载请求的情况下，即，在有路径变更的请求的情况下，公共汽车运行管理服务器13向公共汽车运行管理服务器13请求预测为已经向发出了请求的乘客能够利用的公共汽车上的乘客产生的不满的信息和通过变更公共汽车的运行而产生的成本的信息。在公共汽车的运行被变更时，如果公共汽车到达自身的下车场所的到达时刻延迟，则认为乘坐在该公共汽车上的乘客会存在不满。而且，公共汽车运行管理服务器13向乘客信息管理服务器123请求发出了请求的乘客所持有的点数的信息。

公共汽车运行管理服务器13掌握搭乘于该公共汽车的乘客，乘客信息管理服务器12掌握所有居民的不满度系数。公共汽车运行管理服务器13与乘客信息管理服务器12协作地获取搭乘于该公共汽车的全部乘客的不满度系数的信息，基于该不满度系数，计算在全部乘客中产生的不满的合计值。例如，公共汽车运行管理服务器13计算在变更了该公共汽车的运行时该公共汽车的全部乘客表明不满的情况下产生的不满的合计值即可。另外，公共汽车运行管理服务器13计算通过变更该公共汽车的运行而产生的成本。然后，公共汽车运行管理服务器13将计算出的不满的合计值的信息和计算出的成本的信息通知给运行计划服务器11(13-912)。

另外，乘客信息管理服务器12掌握全部居民所持有的点数，因此从其中向运行计划服务器11通知发出了请求的乘客所持有的点数的信息(12-911)。

在此，暂时中断使用图13的请求处理的说明，对本系统中的“不满”和“点数”进行说明。

本实施方式中的“不满”是对公共汽车的运行或者乘车的不满。如上所述，不满包括与时间相关的不满、与拥挤相关的不满、与就座相关的不满、与噪音相关的不满、与场所相关的不满这5个项目的不满。对公共汽车的运行或者乘车的不满是这5个项目的不满的合计。在本实施方式中，对于时间、拥挤、就座、噪音、场所的不满和作为它们的合计的对公共汽车的运行或者乘车的不满，能够通过数值表现或运算。

“不满”是过去30天的“不满变量”和“不满度系数”这2个要素的积的总和。“不满度系数”是针对“不满变量”的系数，值根据乘客的偏好而变动。但是，在“不满度系数”在30天内没有变动的情况下，乘客信息管理服务器12将“不满度系数”初始化为预先确定的固定值。

在行为心理学上，已知“不满”长时间不维持，但通过在短期内反复多次而持续蓄积”。另外，在作为类似事项的铁路的运行的例子中，根据经验推定乘客的不满在2周左右被遗忘。作为一个例子，上述30天是包括余量在内而设定了2周的约2倍的期间的情况。

另一方面，本实施方式中的“点数”是作为针对“不满”的代价而由公共汽车公司提供的虚拟的债券。“点数”与上述的“不满”不同，不会随着时间的经过而减失。

需求管理型交通服务系统将发出了请求的乘客所持有的“点数”作为判断是否实现通过该请求而提示的希望的材料来使用。并且，当实现该希望时，需求管理型交通服务系统消除或回收与所实现的希望对应的“点数”。

这样，“点数”被用作调整乘客彼此利益冲突的媒介。作为“点数”的使用结果，也存在乘客的“不满”被消除的情况。

接着，对本实施方式中的不满的计算进行说明。

本实施方式中的不满通过以下的式(1)算出。

dis＝pt·t+pi·i+ps·s+pa·a+pl·l…(1)

在式(1)中，dis表示乘客的不满。不满dis是最近的过去30日的不满度系数和不满变量的积的合计。上述30天是基于作为类似事项的铁路的运行的例子中乘客的不满在2周左右被遗忘这样的经验规则，包含余量在内设定了2周的约2倍的期间的例子。

pt是priorityoftime(时间优先)的缩写，是对于与时间相关的不满的系数(不满度系数)。当指定时间优先时，系数pt的值增大。t是表示乘客在车站等等待公共汽车的时间的不满变量。pi是priorityofinterval(间隙优先)l的缩写，是对与拥挤相关的不满的系数。i是表示实际上乘坐公共汽车的的乘客的人数相对于公共汽车的定员的比例即乘坐率的不满变量。如果乘坐率较低，则在公共汽车内的乘客彼此的间隙变大。当指定间隙优先时，系数pi的值增大。ps是priorityofseat(座位优先)的缩写，是对于与就座相关的不满的系数。s是表示乘客在乘坐公共汽车的期间是否能够就坐的不满变量。当指定了就座优先时，系数ps的值变大。pa是priorityofatmosphere(氛围优先)的缩写，是对与噪音相关的不满的系数。a是表示公共汽车内的噪音水平的不满变量。当指定安静优先时，系数pa的值增大。pl是priorityofplace的缩写，是对与乘车场所相关的不满的系数。l是表示从出发场所到乘车场所的步行距离的不满变量。当指定地点数优先时，系数pl的值增加。

以下，对时间、拥挤、就座、噪音以及场所的不满度系数的更具体的例子进行说明。此外，作为不满以及不满度系数的项目的拥挤，与赋予优先的间隙对应。即，间隙优先是使拥挤较低优先。同样地，作为不满以及不满度系数的项目的噪音与优先的安静对应。

在初始状态下，时间、拥挤、就座、噪音以及场所的各项目的不满度系数全部为0.1。然后，在图12的画面例8-0502中进行勾选，当指定为优先的项目时，对所指定的项目的不满度系数加上0.1。乘客优先该项目是考虑到感觉与该项目相关的不满大于与其他项目相关的不满，将该项目强烈地反映在乘客所感受到的不满的数值上。但是，不满度系数的上限为1.0。

另外，在图12的画面例8-0502中优先的项目的复选框可以仅是仅有1个选中的复选框，也可以是多个选中的复选框。

然后，如果在图12的画面例8-0502中不进行针对任意项目的勾选的期间持续30天，则将所有项目的不满度系数初始化为0.1。在从在任一个项目中进行了勾选起经过30日前在任一个项目中进行了勾选的情况下，所有项目的不满度系数不被初始化。

另外，在此所示的30天这样的期间是例示，并不限定于此。在不满度系数的初始化处理中使用的期间可以任意设定。

接着，对时间、拥挤、就座、噪音以及场所的各项目的不满变量的具体例进行说明。

如上所述，不满dis是最近的过去30天的不满度系数和不满变量的积的合计值。不满变量t、i、s、a、l在乘客每次利用公共汽车时被获取。

不满变量t的单位是时间。关于时间的不满，作为一个例子，表示公共汽车到达乘客乘坐的车站的延迟而乘客等待的时间，但在此作为具体例，使用在该时间进一步加上乘客乘坐的公共汽车到达乘客下车的车站延迟的时间和在乘客发出利用公共汽车的请求后到作为针对该请求的应答提示乘客能够乘坐的公共汽车的候补为止的响应时间后的合计时间。

不满变量i是乘坐率，使用将百分比标准化后的单位。在乘坐率为100％时，将不满变量i设为0，将乘坐率为150％时的不满变量i设为1。将乘坐率小于100％时的不满变量i设为0。将乘坐率为150％以上时的不满变量i设为1。在乘坐率从100％到150％的期间，不满变量i是相对于乘坐率的变化以一定程度变化的线性的值。

不满变量s是表示是否就座的值，如果能够就座则将值设为0，如果不能就座则将值设为1。

不满变量a是公共汽车内的噪音水平。例如，也可以在公共汽车内设置音量测量传感器，将其测量值归一化而设为不满变量a。或者，也可以用数值表示公共汽车内的噪音水平为何种程度变高的状况，将该数值标准化而设为不满变量a。例如，也可以使用对象的乘客乘坐的公共汽车的同乘者中的10岁年龄段的乘客的人数。假设当10岁年龄段的同乘者为5人时，将不满变量a设为0，将10岁年龄段的同乘者为10人时的不满变量a设为1，若10岁年龄段的同乘者为5人～10人之间，则是相对于人数的变化以一定的程度变化的线性的值。并且，若10岁年龄段的同乘者不足5人，则将不满变量a设为0，若10岁年龄段的同乘者为10人以上，则将不满变量设为1。

不满变量l是表示是否采用了附近接载请求的值，如果采用了附近接载请求，则将不满变量l设为0，如果不采用指定了某个场所的附近接载请求，而是指示了在基本路径上的车站的乘车，则将不满变量l设为1。如果指示了在附近接载请求中指定的场所与基本路线上的车站之间的场所的乘车，则不满变量l根据被指示了乘车的场所与由附近接载请求指定的场所的距离、和被指示了乘车的场所与基本路线上的车站之间的距离的比例而设为0和1之间的值。

接着，对本实施方式中的“点数”进行说明。

本实施方式的点数能够通过以下所示的式(2)以及式(3)来计算。式(2)是需求管理型交通服务系统的运营者(公共汽车公司)对公共汽车的乘客赋予点数时的计算式，式(3)是公共汽车公司回收点数时的计算式。

point+＝dis(下车时)…(2)

point-＝σ(公共汽车的乘客的dis的预测值)(路线确定时)…(3)

发出了请求的乘客的点数，如式(3)所示那样由公共汽车公司基于该请求在公共汽车的运行路径确定了的时刻回收。另外，通过请求变更公共汽车的运行路径，在其他乘客产生不满的情况下对该乘客赋予的点数通过式(2)计算。

点数取0以上的数值，另外，与上述的不满不同，不会因预定期间的经过而烧毁。

总结以上说明的“不满”和“点数”，可以为如下。

＜1＞不满和点数不成为相同量。

<2>点数虽然参照不满而生成，但基本上两者是独立的值。

＜3＞不满通过在短时间内反复多次而增大，但随着时间而减失。

在此，返回图13的说明。

运行计划服务器11提取满足在从出发场所到基本路径上的车站之间能够进行附近接载的条件的公共汽车和乘车场所，选出发出请求的乘客所乘坐的公共汽车的候补(11-916)。

运行计划服务器11在步骤11-915或者步骤11-916中，选出发出了请求的乘客所乘坐的公共汽车的候补。此时，运行计划服务器11对发出了希望乘车的请求的乘客所持有的点数与在该时间点数基于请求而变更了公共汽车的运行的情况下产生的公共汽车的所有乘客的不满(σ(公共汽车的乘客的dis的预测值))进行比较。如果发出了请求的乘客所持有的点数比公共汽车的所有乘客的预测容易的不满大，则判断为能够基于请求变更公共汽车的运行，经由发出了请求的乘客的选择来决定执行。如果决定了公共汽车的运行的变更，则从发出了请求的乘客回收点数。在该情况下，也与公共汽车的运行是否被变更无关地计算公共汽车的乘客中的不满，通过上述的方法对乘客赋予点数。

相反，在所有乘客的预测的不满的合计值比发出了请求的乘客所持有的点数大的情况下，不实现基于请求的公共汽车的运行的变更，不从发出了请求的乘客回收点数。但是，在该情况下，与公共汽车的运行未被变更的情况无关地计算搭乘于公共汽车的乘客的不满，根据需要对乘客赋予点数。

此外，运行计划服务器11在选出发出了请求的乘客所乘坐的公共汽车和乘车场所的候补时，也可以基于过去的请求的发出以及消化的历史记录，使用随机数来模拟地产生今后预想的请求，在选出候补时考虑预想的请求。

另外，运行计划服务器11不仅可以比较发出了希望乘车的请求的乘客所持有的点数与预测的公共汽车的所有乘客的不满的比较，还可以以在基于请求变更了公共汽车的运行的情况下产生的追加成本成为预定的阈值以下的方式选出候补。运行计划服务器11只要满足基于点数以及不满的条件或者进一步满足追加成本的条件，则也可以选出多个候补。

发出了请求的乘客的乘客信息终端15显示由运行计划服务器11选出的候补，催促乘客选择(15-912)。在发出了希望乘车的请求的乘客例如从显示于乘客信息终端15的候补中选择任意1个的情况下，乘客信息终端15将表示所选择的候补的信息通知给运行计划服务器11(15-913)。

运行计划服务器11基于从乘客信息终端15通知的候补的公共汽车和乘车场所来变更公共汽车的运行，随之更新公共汽车的运行时刻表(11-917)。然后，运行计划服务器11将新的运行时刻表通知给公共汽车运行管理服务器13和公共汽车运行指示终端14。公共汽车运行管理服务器13将从运行计划服务器11通知的新的时刻表记录在数据库中(13-913)。另外，公共汽车运行指示终端14显示从运行计划服务器11通知的新的时刻表(14-911)。

图14是需求管理型交通服务系统从乘客获取对问卷调查的回答的处理的时序图。需求管理型交通服务系统在乘客下车时获取对问卷调查的回答。

各公共汽车的公共汽车运行指示终端14在该公共汽车运行并停车于停留场所时，将停车于该停留场所的主旨报告给公共汽车运行管理服务器13和运行计划服务器11(14-1011)。停留场所既可以是预先确定的车站，也可以是通过来自乘客的请求而停车的车站或者不是车站的场所。

如果接收到停车的报告，则公共汽车运行管理服务器13也可以将该报告作为附随于行驶日志表13-45的信息进行记录(13-1011)。

运行计划服务器11在接收到停车的报告时，基于该报告来确认停车的公共汽车和停留场所(11-1011)，从请求发出信息12-42中提取从该公共汽车在该停留场所下车的乘客(11-1012)。而且，运行计划服务器11向提取出的乘客的乘客信息终端15发送问卷调查(11-1013)。

乘客信息终端15接收问卷调查并显示在画面上(15-1011)。本实施方式中的调查问卷如图12的画面例8-0503那样显示。在本实施方式中，使用了询问是否满足公共汽车的利用的简单的问卷调查。作为对问卷调查的回答，乘客能够回答满意或者不满，或者不回答。乘客信息终端15将表示乘客对问卷调查输入的回答的问卷调查信息发送给乘客信息管理服务器12(15-1012)。

乘客信息管理服务器12在接收到问卷调查信息时(12-1011)，基于该问卷调查信息，更新该乘客的不满的值和点数(12-1012)。如果回答不满，则乘客信息管理服务器12根据上述的式(1)计算不满的值，通过上述的式(2)，将该不满的值与点数相加。然后，乘客信息管理服务器12将其更新结果反映到居民参数表12-41中(12-1013)。

当公共汽车到达终点站时，该公共汽车的公共汽车运行指示终端14向公共汽车运行管理服务器13和运行计划服务器11报告停车在终点站的主旨(14-1012)。在此，终点站不是乘客下车的车站。

公共汽车运行管理服务器13在接收到停车的报告时，基于该报告更新行驶日志表13-45(13-1011)。运行计划服务器11在接收到停车的报告时，基于该报告来确认停车的公共汽车和停留场所(11-1014)。

本实施方式的运行计划服务器11能够在各种条件下对居民的不满进行统计并显示。作为一个例子，运行计划服务器11针对每个区域，按时间、拥挤、就座以及噪声的每个项目计算每个区域的不满的合计值，并以图表进行显示。由此，公共汽车公司能够容易地知道包含乘客的居民对何种情况怀有不满，能够有助于公共汽车的运行、服务的改善。

运行计划服务器11例如通过以下所示的式(4)，计算按区域满意度平均，并且还计算各项目的不满的合计值或者不满的每一人的平均值。

[数学式1]

在式(4)中，a是区域。p是不满度系数。v是不满变量。z是不满的项目，包括时间、拥挤、就座、噪音、场所的各项目。u是属于区域的居民。总居民数为区域居民的总数。

另外，作为变形例，运行计划服务器11不仅在下车时获取公共汽车的乘客的不满，而且还可以在乘车时获取与公共汽车的乘客在车站的等待时间相关的不满，无论有无乘坐公共汽车都可以从居民适时地获取不满。而且，运行计划服务器11也可以将公共汽车等待乘客的不满、与有无公共汽车乘车无关的居民的不满、公共汽车的乘客的不满以图表来进行显示。

图15是表示显示对不满进行统计后的结果的gui(graphicaluserinterface：图形用户接口)的画面例的图。图15示出了包括多个图表11-1101、11-1102、11-1103的画面例11-110。图15的图表11-1101、1102、1103将中央部分从中心上下左右划分为4个领域，分别分配时间、噪音、就座、拥挤这样的项目。在各项目的区域中，中心附近欠缺为扇形的扇形区域以通过其半径表示不满的程度来进行描绘。

在图表11-1102中，示出了与某个区域相关的(包含有无乘坐公共汽车的双方)居民的各项目的不满的合计值。在图表11-1101中，示出了利用公共汽车的乘客的公共汽车等待时的各项目的不满的合计值。在图表11-1103中，示出了利用了公共汽车的乘客的各项目的不满的合计值。在此，示出了将不满的合计值图表化的例子，但也可以将每一人的不满的平均值图表化。

另外，本实施方式的运行计划服务器11能够按每个区域显示利用了整体服务区域所包含的各区域中的公共汽车的乘客的不满。

图16是表示按每个区域显示对各区域的不满进行统计后的结果的gui的画面例的图。在此，在图10所示的整体服务区域中，如图16所示，存在9个区域。

在图16中，示出了在整体服务区域的地图上划出划分各区域的边界线，根据各区域的区域的浓淡来表示不满的程度的画面例。在此，浓淡越浓意味着不满越高。

另外，作为决定乘客的不满是哪个区域中的不满的方法，例如，可以将在该区域内乘车的乘客的不满设为该区域中的不满。或者，也可以将在该区域内下车的乘客的不满设为该区域中的不满。

另外，在图16中，示出了9个区域属于整体服务区域的例子，但属于整体服务区域的区域数量没有上限。

另外，在图16中，示出了属于整体服务区域的各区域的形状为矩形的例子，但区域的形状没有特别限定。区域既可以是矩形、正六边形等相等的形状，也可以是按每个区域而不同的形状。

另外，本实施方式的需求管理型交通服务系统能够基于从居民收集到的不满的信息来制定新的公共汽车的运行计划。

图17是表示制定公共汽车运行计划的处理的时序图。本处理也可以在运行公共汽车的营业时间结束后作为批处理实施。

乘客信息管理服务器12计算各区域的各项目的不满(12-1311)。此时，乘客信息管理服务器12根据图4所示的从请求消化日志12-43向乘客的公共汽车的乘车的信息，将各区域与乘客建立对应，将与各区域对应的乘客的不满设为该区域中的不满。如果乘客乘车的场所在某个区域内，则将该乘客下车时获取的不满作为该区域中的不满来处理。

然后，乘客信息管理服务器12参照居民参数12-41获取居民的不满的值(不满度)和不满度系数，计算每个区域的乘客的不满的值的总和。而且，乘客信息管理服务器12通过将针对区域计算出的不满的值的总和除以该区域的全部居民数，计算出与该区域相关的乘客的不满的值的总和的平均值。

另外，在此，将乘客乘坐公共汽车的场所所属的区域作为统计该乘客的不满的区域，但并不限定于此。作为其他例子，也可以将乘客下车的场所所属的区域作为统计该乘客的不满的区域。另外，也可以将乘客的地址所属的区域作为统计该乘客的不满的区域。

另外，在此，基于从居民收集到的不满的值来制定公共汽车的运行计划，但也可以不一定基于不满的值。作为另一例，也可以使用点数来代替不满的值，基于居民所持有的点数来制定公共汽车的运行计划。

再次参照图17，乘客信息管理服务器12分析各区域的不满的性质(12-1312)。具体而言，乘客信息管理服务器12分别计算各区域的时间、拥挤、就座、噪音以及场所这样的各项目(不满的种类)的不满，并与区域的居民的数量以及属性建立关联。各区域的各项目的不满和各区域的居民的数量以及属性的关联方法没有特别限定，例如也可以利用多元回归分析或者贝叶斯估计法等计算相关性。

接着，乘客信息管理服务器12分析各区域间的不满的性质(12-1313)。具体而言，乘客信息管理服务器12计算2个区域的不满的相关性。在图16所示的整体服务区域以及区域的例子中，存在9个区域，因此区域的组合成为36个，针对该36个组合的每一个计算区域间的相关性。

推定在不满具有强的相关性的2个区域中存在共同的不满的要素。

接着，乘客信息管理服务器12基于区域间的不满的相关性，生成新设置的公共汽车路线的方案(12-1314)。具体而言，乘客信息管理服务器12确定在相关性强的区域之间的乘客的公共汽车的利用中增强了该相关性的公共汽车的利用。此外，乘客信息管理服务器12提取增强了该相关性的公共汽车的利用中的乘车时刻以及乘车场所、下车时刻以及下车场所。进而，提出了乘客信息管理服务器12推定包含该乘车时刻以及下车时刻在内的时间段中的、从该乘车场所向下车场所的公共汽车不足或者缺少为不满原因，并在该时间段新设置运行该路径的公共汽车线路。例如，如果将15:00～16:00的时间段中的、从某个区域向购物中心的公共汽车推测为不满因素，则乘客信息管理服务器12只要将从该区域的代表地点数运行到购物中心的直通公共汽车作为新路线来提出即可。

乘客信息管理服务器12将提出的新路线的信息通知给公共汽车运行管理服务器13。

公共汽车运行管理服务器13计算提出的新路线的运行所需的成本(13-1311)。例如，也可以根据新路线中的公共汽车的行驶距离来计算成本。

进而，公共汽车运行管理服务器13基于计算出的成本，判断可否采用新路线(13-1312)。例如，如果成本为预定的阈值以下，则也可以判断为能够采用。

如果无法采用新路线，则公共汽车运行管理服务器13将该主旨通知给乘客信息管理服务器12，乘客信息管理服务器12接受该通知而结束处理(12-1315)。

另一方面，如果能够采用新路线，则公共汽车运行管理服务器13将该主旨通知给乘客信息管理服务器12，并且生成包含新路线的公共汽车的运行时刻表。接收到能够采用新路线的主旨的通知的乘客信息管理服务器12生成向居民告知新路线的导入的信息，并向乘客信息终端15发送(12-1316)。接收到告知的信息的乘客信息终端15基于该信息，显示告知新路线的导入的广告(15-1311)。

另外，公共汽车运行管理服务器13将新路线的运行计划与生成的运行时刻表一起通知给公共汽车运行指示终端14(13-1313)。接收到通知的公共汽车运行指示终端14受理运行计划(14-1311)，开始基于新的运行时刻表的公共汽车的运行的指示。

上述的实施方式的一部分或全部包含以下的事项。但是，本实施方式的公开并不限定于以下的事项。

提供使移动资源(公共汽车)运行而使使用者(居民、乘客)移动的服务的移动服务系统具有：第一管理装置(乘客信息管理服务器)，其存储与使用者相关的第一数据库(居民数据库)，对使用者的请求进行管理；第二管理装置(公共汽车运行管理服务器)，其存储与移动资源相关的第二数据库(公共汽车数据库)，对移动资源的运行的状态进行管理；以及第三管理装置(运行计划服务器)，其与第一管理装置以及第二管理装置协作来变更移动资源的运行。第三管理装置以数值获取使用者产生的不满，第一管理装置根据不满，赋予为实施对于移动资源的运用的请求而能够利用的点数，将每个使用者的点数记录于第一数据库，第三管理装置从使用者接受请求，作为与第一数据库中管理的对该使用者赋予的点数的交换，基于请求和在第二数据库中管理的移动资源的运行的状态，变更移动资源的运行的计划。

由此，对使用者的不满的程度进行定量化，根据该不满而对使用者赋予点数，利用点数来实现移动资源的运用的变更的请求，因此能够将各使用者的不满的程度反映到移动资源的运用中。其结果是，能够使多个使用者的不满平衡，以提高使用者整体的满意度的方式运用移动资源。

另外，第三管理装置若变更了移动资源的运行计划，则推定移动资源的其他使用者产生的不满，基于其他使用者的不满和发出了请求的使用者的点数，判定是否能够变更移动资源的运行计划。由此，在利用使用者根据不满而被赋予的点数来变更移动资源的运行时，基于该使用者持有的点数和由于该变更而其他使用者可能会怀有的不满，来判定是否能够实施该请求，因此能够使使用者间的不满平衡。

另外，第三管理装置在变更了移动资源的运行计划时，从发出了请求的使用者的点数减去与其他使用者的不满相当的量。由此，若通过使用者的请求变更移动资源的运行计划，则从发出该请求的使用者的点数减去与其他使用者的不满的程度相当的量，因此能够使使用者的不满平衡，同时调整与使用者的请求相应的移动资源的运行。

另外，第三管理装置针对成为不满的对象的多个服务质量项目，将使用者重视的程度设为系数，将针对服务质量项目的事件的计测值设为变量，针对多个服务质量项目，将每个服务质量项目的系数与变量的积进行合计，将合计值设为使用者的不满的值。由此，由于划分多个服务质量项目来考虑重视的程度来计算出使用者的不满的值，因此能够多方面地捕捉服务并准确地将使用者的每个项目的不满反映到移动资源的运用中。

另外，第三管理装置根据来自使用者的请求获取针对服务质量项目的嗜好信息并更新系数。由此，由于按照使用者进行的请求来获取使用者的与服务质量项目相关的嗜好，所以为了反映使用者重视的程度，能够减少使用者另外输入嗜好的麻烦。

另外，第三管理装置在使用者利用移动资源进行了移动时，从使用者得知是否存在不满，如果有不满，则基于事件的计测值，使第一管理装置更新使用者的不满的值。由此，由于在使用者移动时获取不满的发生，所以能够准确地掌握由使用者产生的不满，作为不满的程度进行计算。

另外，第三管理装置基于其他使用者的不满和发出了请求的使用者的点数，提取移动资源的运行计划的可能的变更，提示给发出了请求的使用者，实施使用者选择的变更。由此，将多个变更的方案提示给使用者，并实施所选择的变更，因此，使用者能够在满足要求的同时，选择更优选的变更方式，进一步提高了使用者的便利性。

另外，第三管理装置对划分提供服务的服务区域后的多个区域的每一个统计不满的值，显示统计结果。由此，由于按每个区域统计并显示不满，所以能够视觉确认每个区域的不满的情况，确认是否适当地提供了移动资源。

另外，第一管理装置基于统计结果，对区域中的不满的原因进行解析，以减少原因的方式，提出区域中的移动资源的运行的计划。由此，基于每个区域的不满的统计结果解析不满的原因，提出减少原因这样的计划，因此能够重新规划每个区域的与使用者的不满的状况相应的移动资源的运行计划。

另外，在服务质量项目中，包含向移动资源出场的场所、为了利用移动资源所需的时间、移动资源内的拥挤、移动资源中能否就座和移动资源内的噪音中的至少1个。由此，由于利用向移动资源出场的场所、为了利用移动资源所需的时间、移动资源内的拥挤、移动资源中能否就座、或者移动资源内的噪音这样的参数来计测在利用移动单元时感到的不满，所以能够将使用者的不满适当地反映到不满的值。

另外，第一管理装置在第一数据库中管理每个使用者的不满的值，将持续预定时间而没有发生新的不满的使用者的不满的值设为预定的初始值。由此，通过符合行为心理学上的不满的持续性的运算，能够以数值适当地表现使用者所感受到的不满。

附图标记说明

11…运行计划服务器、12…乘客信息管理服务器、13…公共汽车运行管理服务器、14…公共汽车运行指示终端、15…乘客信息终端、1-01…cpu、1-02…存储器、1-03…通信nic、1-04…硬盘驱动器、1-05…输入输出控制器、1-06…监视器控制器、1-07…公共汽车、1-08…gps模块、1-11…键盘、1-12…鼠标、1-13…显示器、1-14…ic卡读取模块、1-15…触摸面板、11-40…统计数据库、11-41…统计结果表、11-42…按区域统计结果表、11-43…区域定义表、11-44…gis节点信息表、11-45…gis节点信息、12-40…居民数据库、12-41…居民参数表、12-42…请求发出信息表、12-43…请求消化日志表、13-40…公共汽车数据库、13-41…公共汽车车体参数表、13-42…公共汽车折返发车预定时刻表、13-43…公共汽车基本路径的移动顺序-车站对应表表、13-44…基本路径上的车站表、13-45…公共汽车行驶日志表。