共乘预订系统、方法和程序存储介质与流程

本公开涉及一种共乘预订系统、方法和程序存储介质。

背景技术：

日本公开专利申请(jp-a)no.2016-194854描述了与共乘支持系统有关的技术。在该共乘支持系统中，驾驶家用车辆的驾驶员注册旅行计划。当希望在注册的旅行计划上乘坐的乘车人进行预订时，共乘支持系统进行匹配，并且通知驾驶员和乘车人。这使得能够简单地实现车辆中的共乘。

然而，对于jp-ano.2016-194854中描述的共乘支持系统，难以预先判断可用于要装载在所计划的共乘车辆中的行李的装载空间的尺寸。这种了解的缺乏意味着可能会导致装载行李的延误，因为装载空间利用的效率取决于如何装载行李，这可能对共乘时的便利性有害。

技术实现要素：

本公开获得了一种能够增强在共乘时的便利性的共乘预订系统、方法和程序存储介质。

一种根据本公开的第一方面的共乘预订系统包括检测单元、行李信息识别单元、匹配单元、和输出单元。检测单元被配置为检测行李识别数据，该行李识别数据被采用以识别由将乘坐在车辆中的用户携带的行李。行李信息识别单元被配置为基于行李识别数据至少识别行李的尺寸信息。匹配单元被配置为基于行李的尺寸信息判断该行李是否是可装载在车辆中的，如果该行李被认为可装载，则决定该行李在车辆中的装载位置，以及基于该判断结果对用户要在车辆中共乘进行预订或不进行预订。输出单元被配置为输出指示是否已经进行了共乘预订的信息，并且如果已经进行了共乘预订，则指示行李在车辆中的装载位置。

根据如上所述的第一方面，所述共乘预订系统包括检测单元、行李信息识别单元、匹配单元、和输出单元。当用户要在车辆中共乘时，检测单元检测行李识别数据，该行李识别数据被采用以识别用户携带的行李。行李信息识别单元基于所检测到的行李识别数据至少识别行李的尺寸信息。匹配单元然后基于行李的尺寸信息判断行李是否是可装载在共乘候选车辆中的，并且当该行李被认为可装载时判断行李在车辆中的装载位置。匹配单元还基于该判断结果对用户要在车辆中共乘进行预订或不进行预订。因此，通过在行李为不可装载的时不进行预订，能够避免用户不能够将要在共乘车辆时携带的行李装载到共乘车辆中的情况。

然而，当行李被认为可装载时，在已经确定了行李在车辆中的装载位置之后进行预订。从而，用户能够通过参考指示在车辆中进行共乘时在输出单元上显示的装载位置的信息来装载要携带的行李。即，由于匹配单元在考虑到其它行李等的同时确定装载位置，因此能够顺利地装载该行李，并且能够有效地利用行李在车辆中的装载空间。

这里对“用户”的引用包括驾驶车辆的驾驶员、由驾驶员驾驶的车辆或自动驾驶车辆中的共乘(乘坐)的乘车人、以及希望共乘的候选乘车人。

“行李识别数据”包括数据，诸如捕获行李的图像数据、指示行李的名称和尺寸等的语音数据和文本数据、根据行李类型和尺寸对行李进行分类的分类数据。

根据本公开的第二方面的共乘预订系统是第一方面，其中，在判断存在除了所述行李之外的行李被装载在所述行李顶部上的可能性之后，匹配单元通知用户将其它行李放在所述行李上的可能性。

根据如上所述的第二方面，当判断存在其它行李被装载在所述行李顶部上的可能性时，匹配单元向用户通知存在除了所述行李之外的行李被装载在所述行李顶部的可能性。因此，用户能够提前选择另一车辆或采取诸如在其中要携带的行李是易碎的并易于受到其它行李影响的情况下包裹行李的对策。这使得能够防止对行李的损坏等。

根据本公开第三方面的共乘预订系统是第一方面或第二方面，其中，如果行李被认为可装载，则匹配单元考虑用户上车顺序或用户下车顺序中的至少一个来决定车辆中的行李的装载位置。

根据如上所述的第三方面，当行李被认为可装载时，匹配单元考虑用户上车顺序或用户下车顺序中的至少一个来确定行李在车辆中的装载位置。例如，通过将由要提早下车的用户携带的行李放置在其它行李前面，这使得能够顺利地执行下车。即，能够根据上车或下车状态适当地分配行李的装载位置，从而使得能够顺利地执行上车或下车中的至少一个。

根据本公开的第四方面的共乘预订系统是第一方面至第三方面，其中，如果行李被认为可装载，则匹配单元考虑行李的类型来决定行李在车辆中的装载位置。

根据如上所述的第四方面，当行李被认为可装载时，匹配单元考虑行李类型来决定行李在车辆中的装载位置。因此，例如，在行李是硬壳行李箱的情况下，通过将其它行李装载在所述行李的顶部上，可以使得能够装载更多行李。因此，这使得能够更有效地使用用于在车辆中装载行李的装载空间。

根据本公开的第五方面的共乘预订系统是第一方面至第四方面，其中，检测单元是用户持有的用户终端，并且行李识别数据是行李的使用用户终端捕获的图像数据。

根据如上所述的第五方面，检测单元是用户持有的用户终端，并且行李识别数据是行李的使用该用户终端捕获的图像数据。从而，在不需要测量携带行李的尺寸等的情况下，用户无论在何处都能够容易地输入行李的行李识别数据。

根据本公开的第六方面的共乘预订系统是第一方面至第五方面，其中，在其中根据基于行李的尺寸信息判断行李是否在车辆中是可装载的判断结果为不可装载的情况下，匹配单元向用户通知能够是可装载的行李的尺寸信息。

根据如上所述的第六方面，匹配单元向用户通知当要装载的行李已经被判断为在车辆中为不可装载时能够是可装载的行李的尺寸信息。从而，用户能够基于能够是可装载的行李的尺寸信息或是否乘坐在不同的车辆中来考虑是否重新组织行李。即，能够为用户提供有更多选择。

根据本公开第七方面的共乘预订系统是第一方面至第六方面，其中，基于行李识别数据，行李信息识别单元从存储关于多件行李的信息的行李数据库或从通过通信网络线路可访问的信息来至少识别行李的尺寸信息。

根据如上所述的第七方面，基于检测到的行李识别数据，行李信息识别单元从存储有关于多件行李的信息的行李数据库或从通过通信网络线路可访问的信息至少识别行李的尺寸信息。这使得获得更精确的尺寸信息等变得容易。

本公开的第八方面是一种共乘预订方法，该方法包括：检测行李识别数据，该行李识别数据被采用以识别由将在车辆中乘坐的用户携带的行李；基于该行李识别数据至少识别行李的尺寸信息；基于行李的尺寸信息判断行李是否是可装载车辆中的，如果行李被认为可装载，则决定行李在车辆中的装载位置。所述共乘预订方法还包括：基于判断行李是否是可装载在车辆中的结果，决定对用户要在车辆中共乘进行预订货不进行预定；以及，输出指示已经进行了或未进行了共乘预订的信息，并且如果已经进行了共乘预订，则输出指示行李在车辆中的装载位置的信息。

本公开的第九方面是一种存储有共乘预订程序的非暂时性存储介质。该程序使计算机执行处理，所述处理包括：接收行李识别数据，所述行李识别数据被采用以识别由将乘坐车辆的用户携带的行李；基于行李识别数据至少识别行李的尺寸信息；基于行李的尺寸信息来判断行李是否是可装载车辆中的，如果行李被认为可装载，则决定行李在车辆中的装载位置。该处理还包括：基于判断行李是否是可装载在车辆中的结果，来决定是否对用户以在车辆中共乘进行预订；以及，发送指示已经进行了或未进行了共乘预订的信息，并且如果已经进行了共乘预订，则指示了行李在车辆中的装载位置的信息。

因此，根据第一方面、第八方面、和第九方面的共乘预订系统、方法和程序存储介质使得能够增强在共乘时的便利性。

根据第二方面至第七方面的共乘预订系统使得能够进一步增强在共乘时的便利性。

附图说明

将基于以下附图详细描述本公开的示例性实施例，在附图中：

图1是图示根据第一示例性实施例的共乘预订系统的概要的示意图；

图2是示意性地图示驾驶员使用根据第一示例性实施例的共乘预订系统在旅行计划注册期间处理的流程图；

图3是示意性地图示乘车人使用根据第一示例性实施例的共乘预订系统在预订期间处理的流程图；

图4是图示在根据第一示例性实施例的共乘预订系统中输入的行李识别数据的示例的示意图；

图5是图示在根据第一示例性实施例的共乘预订系统中输入的行李识别数据期间在用户终端上的屏幕显示的示例的示意图；

图6是示意性地图示在根据第一示例性实施例的共乘预订系统中在行李识别数据是分类信息时处理的流程图；

图7是图示在根据第一示例性实施例的其中共乘预订系统中已经决定行李装载位置的情况下的一系列事件的示意图；

图8是图示由根据第一示例性实施例的共乘预订系统的行李装载位置的发送状态的示意图；以及

图9是示意性地图示乘车人使用根据第二示例性实施例的共乘预订系统在预订期间处理的流程图。

具体实施方式

以下参考图1至图8说明关于根据本公开的共乘预订系统的示例性实施例。

总体配置

如图1所示，本示例性实施例的共乘预订系统10包括用户终端18和管理服务器20。用户终端18是驾驶员14和乘车人16、17持有的终端，驾驶员14用作驾驶车辆12的用户，乘车人16、17用作希望乘坐在车辆12中的用户，以及每个用户终端18用作检测单元和输出单元。管理服务器20用作行李信息识别单元和匹配单元。乘车人16、17持有的用户终端18能够通过由诸如3g或lte的移动通信服务或用作通信网络线路的互联网配置的通信网络n来访问管理服务器20。尽管在本示例性实施例中通信网络n由移动通信服务或互联网配置，但是不限于此，并且通信网络n可以是与公共网络隔离的封闭网络。

用户终端18由智能手机、蜂窝电话、平板终端、或个人计算机等来配置，并且各自包括cpu、rom、ram、存储器、通信接口、显示设备、输入设备、成像设备、和语音输入设备等(这些都未被图示)。cpu是执行在存储器中存储的程序并执行各种计算的处理器。rom是非易失性存储设备，其存储在用户终端18的启动时采用的程序和数据。ram是易失性存储设备，其在由cpu执行程序时用作工作区。存储器是存储包括操作系统(os)和应用程序的各种程序和数据的非易失性存储设备。通信接口是与其它设备进行通信的接口。在本示例性实施例中，通信接口具有根据各种通信协议执行无线通信的功能。为了便于说明，在以下说明中，用户终端18中的每个的cpu读取在存储器中存储的预定程序，并使用ram作为工作区执行程序，以便执行用户终端18的各种功能。在这个意义上，cpu控制用户终端18的各种配置。

显示设备是显示信息的设备，并且包括液晶显示器、或有机el显示器等。输入设备是由驾驶员14或乘车人16、17使用的以向其用户终端18输入指令和信息的设备，并且包括例如触摸传感器、小键盘、或按钮中的至少一个。在本示例性实施例中，用户终端18中的每个包括触摸屏，并且用户触摸在显示设备上显示的ui图像(按钮、和图标等)以向用户终端18输入指令。成像设备包括可见光相机，并且是用于捕获至少静止图像的设备。语音输入设备包括麦克风，并且是声音记录设备。

存储器存储程序(以下称为客户端应用程序)，该程序使计算机设备用作共乘预订系统10的客户端。客户端应用程序与硬件元件和其它软件元件(诸如，os)协作地运行，以在用户终端18上实现检测单元。

管理服务器20例如是通用计算机设备，并且包括cpu、rom、ram、存储器、和通信接口(这些都未示出)。cpu是执行在存储器中存储的程序的处理器，并执行各种计算。rom是非易失性存储设备，其存储在服务器启动时采用的程序和数据。ram是易失性存储设备，其当由cpu执行程序时用作工作区。存储器是非易失性存储设备，其存储诸如os和应用程序的各种程序和数据。通信接口是与诸如用户终端18的其它设备以及与通信网络n通信的接口。为了便于说明，在以下说明中，管理服务器20的cpu读取在存储器中存储的预定程序，并且使用ram作为工作区执行程序，以便执行管理服务器20的各种功能。在这种意义上，cpu控制管理服务器20的各种配置。

存储器存储服务器程序，该服务器程序使计算机设备用作共乘预订系统10的服务器。cpu执行服务器程序以在管理服务器20上实现行李信息识别单元、匹配单元、和信息输出部分。存储器还存储数据库，其中记录了由共乘预订系统10采用的数据。由共乘预订系统10使用的数据库包括用户数据库、预订数据库、和行李数据库。

操作

关于共乘预订系统10的操作的说明如下。共乘预订系统10由提供共乘预订系统10的组织管理。希望利用共乘预订系统10的驾驶员14和乘车人16、17各自提前执行用户注册。在用户注册期间，驾驶员14或乘车人16、17输入他们自己的简档信息(唯一信息)。简档信息包括例如用户名、密码、性别、年龄、居住地、电子邮件地址、和简档图片。注意的是，尽管在共乘预订系统10中不存在以在用于驾驶员14和乘车人16、17的用户注册中使用的单独的类别，但是为了便于说明，这里使用术语“驾驶员”和“乘车人”。用作驾驶员14的用户的简档信息还包括例如与他们的车辆有关的信息，诸如型号、年份、颜色、外观的照片、和配置行李的装载空间的行李箱34的行李装载容量(参见图8)。在管理服务器20的用户数据库中记录简档信息。具体地，使用从车辆12的制造商获取的信息或由驾驶员14实际测量的信息等记录车辆12的在用户数据库中记录的行李装载容量。

驾驶员注册

图2是图示由驾驶员14使用共乘预订系统10在旅行计划注册期间处理的详细示例的流程图。在本示例性实施例中的共乘预订中，首先，用作驾驶员14的用户向用户通告(乘车人16、17)在特定的旅行计划上共乘。希望共乘的乘车人16、17然后响应通告。

使用他们自己的用户终端18，驾驶员14输入旅行计划以向希望共乘的用户做通告。在驾驶员14的用户终端18的cpu接收到输入的行驶计划之后，cpu开始图2中图示的处理。行驶计划包括例如出发时间、出发地点、目的地点、和一些可能的乘车人。

在步骤s100处，驾驶员14的用户终端18的cpu将输入的旅行计划发送到管理服务器20。在管理服务器20从用户终端18接收到旅行计划之后，管理服务器20的cpu开始图2中图示的处理。

在步骤s102处，管理服务器20的cpu将从驾驶员14的用户终端18接收的旅行计划数据记录在预订数据库中。接下来，在步骤s104处，管理服务器20向驾驶员14的用户终端18发送对于输入与驾驶员14打算携带的行李14a有关的行李识别数据的请求。

在从管理服务器20接收到用于输入行李识别数据的通知时，在步骤s106处，如图5所示，驾驶员14的用户终端18的cpu在用户终端18的显示设备上显示行李注册屏幕。驾驶员14从行李注册屏幕上的多个行李识别数据项目中选择并输入他们想要的行李识别数据。

使用图像数据的行李识别数据

用于行李的行李识别数据由行李图像数据、语音数据、文本数据和根据行李类型预先分类的分类数据等中的至少一个进行配置。由用户终端18检测行李识别数据。在其中采用图像数据作为行李识别数据的情况下，例如，驾驶员14按下在用户终端18的行李注册屏幕上显示的“图像捕获”按钮26，以启动用户终端18的成像装置以便输入行李识别数据。然后，如图4所示，使用用户终端18对驾驶员14打算携带的行李14a进行成像，并且在步骤s108处，将捕获的图像数据从用户终端18发送到管理服务器20，如图2所示。

在步骤s110处，管理服务器20的cpu将从用户终端18接收的图像数据记录在预订数据库中，并将图像数据中描绘的行李14a与在行李数据库中记录的行李信息进行匹配。例如，深度学习方法被采用用于该匹配。深度学习是指采用由分层结构中连接在一起的多个处理层构成的多层神经网络的机器学习方法。

在深度学习中，在多层神经网络的每一层中，对由前一层获得的多个不同计算结果数据的输入数据，即对特征量的提取结果数据执行计算处理。然后，因此获得的特征量数据在后续处理层中进行进一步的计算处理，以便提高特征量的识别率，并使得能够将输入数据分类成多个类。

可以想到，这种深度学习方法可以应用于上述图像数据，以将图像数据中的每个像素分类成多个类。例如，当对在图像数据中包括的行李14a进行分类时，采用图像数据作为输入，并且对要在图像数据中处理的行李14a执行神经网络深度学习，以便对行李14a相对于行李数据库中记录的多种类型的行李识别进行分类(匹配)。采用已经以这种方式通过深度学习训练的神经网络使得输入图像数据中的行李14a能够针对多种类型的行李信息进行分类(匹配)。注意的是，行李信息至少包括来自行李的尺寸信息(例如长度尺寸、宽度尺寸、和高度尺寸)、体积、外部轮廓、重量和属性信息(例如“易碎”或“必须保持直立”)中的尺寸信息。

如果能够发现行李数据库中记录的行李信息与来自用户终端18的图像数据不匹配，则管理服务器20的cpu搜索可通过通信网络n访问的信息(参见图1)。如果在步骤s114处找到匹配图像数据的行李，则管理服务器20的cpu获取与该行李相对应的行李信息。在步骤s116处，该行李信息被预测为是在图像数据中描绘的、用于行李14a的行李信息，并且预测结果被发送到驾驶员14的用户终端18。

如果在步骤s114不存在与图像数据匹配的行李，则管理服务器20返回到步骤s104，并且向驾驶员14的用户终端18通知对于重复输入驾驶员14打算携带的行李14a的行李识别数据的请求。注意的是，尽管未在附图中示出，但是当通知请求重复输入行李14a的行李识别数据时，可以请求与先前输入的行李识别数据不同的行李识别数据，或者可以请求驾驶员14测量行李14a的尺寸，并且使用在行李注册屏幕上的“直接输入”按钮27(见图5)输入测量结果。注意的是，当测量行李14a的尺寸以用于“直接输入”按钮27时，当然可以采用通用卷尺测量等进行测量，或者驾驶员14可以输入例如他们正在使用的用户终端18的特定模型等，并且根据用户终端18的“长度数”输入长度尺寸(或宽度尺寸或高度尺寸)，使得由管理服务器20基于输入结果计算实际尺寸，并且其结果被预测为行李14a的行李信息。

使用语音数据的行李识别数据

在采用语音数据作为行李的行李识别数据的情况下，驾驶员14按下在用户终端18上的行李注册屏幕上显示的“说话”按钮28(见图5)以启动用户终端18的语音输入设备以便输入行李识别数据。驾驶员14然后说出要携带的行李的类型和名称(例如，“samsonite(新秀丽)(注册商标)行李箱”)。当驾驶员12已经完成说话时，在步骤s108处，用户终端18的cpu向管理服务器20发送所获得的口述语音数据。管理服务器20的cpu分析从用户终端18接收到的语音数据，并且基于该语音数据生成文本信息。在步骤110处，将语音数据和文本信息一起记录在预订数据库中。管理服务器20的cpu然后将所生成的文本信息与行李数据库(或通过通信网络n可访问的信息)进行匹配，并且在步骤s114处，如果存在匹配文本信息的行李，则获取与该行李相对应的行李信息。在步骤s116处，该行李信息被预测为是由语音数据指示的、用于行李14a的行李信息，并且预测结果被发送到驾驶员14的用户终端18。

如果在步骤s114处不存在匹配语音数据的行李，则与上述图像数据的情况类似，管理服务器20返回到步骤s104并且向驾驶员14的用户终端18通知对于重复输入驾驶员14打算携带的行李14a的行李识别数据的请求。

使用文本数据的行李识别数据

在采用文本数据作为行李的行李识别数据的情况下，驾驶员14在显示在用户终端18的行李注册屏幕上的“搜索栏”29(见图5)中输入要携带的行李的类型和名称(例如“samsonite(注册商标)行李箱”)作为文本，以便输入行李识别数据。然后，驾驶员14按下未图示的“搜索”按钮，并且用户终端18的cpu将输入的文本数据发送到管理服务器20。在步骤s110处，管理服务器20的cpu在预订数据库中记录从用户终端18接收的文本数据，并将文本数据与行李数据库(或通过通信网络n可访问的信息)进行匹配，并且如果存在匹配文本数据的行李，则在步骤s114处获取与该行李相对应的行李信息。在步骤s116处，该行李信息被预测为是由文本数据指示的、用于行李箱14a的行李信息，并且该预测结果被发送到驾驶员14的用户终端18。

如果在步骤s114处不存在匹配文本数据的行李，则与上述图像数据的情况类似，管理服务器20返回到步骤s104并且向驾驶员14的用户终端18通知对于重复输入驾驶员14打算携带的行李14a的行李识别数据的请求。

使用分类数据的行李识别数据

在采用分类数据作为行李的行李识别数据的情况下，驾驶员14按下在用户终端18上的行李注册屏幕上显示的“类别”按钮30(见图5)以便输入行李识别数据。当按下“类别”按钮30时，如图6所示，在步骤s200处，用户终端18的cpu通知管理服务器20已经按下“类别”按钮30。在从用户终端18接收到已经按下“类别”按钮30的通知时，在步骤s202处，管理服务器20的cpu利用按类型(诸如，行李箱或波士顿包、尺寸等)分类的分类信息来响应用户终端18。在步骤s204处，用户终端18的cpu在显示设备上显示从管理服务器20接收的分类信息，并提示驾驶员14选择与要携带的行李14a相对应的分类信息。在步骤s206处，用户终端18然后将所选择的数据发送到管理服务器20。在图2所示的步骤s110处，管理服务器20的cpu将从用户终端18接收的分类信息记录在预订数据库中，并且将分类信息与行李数据库(或通过通信网络n可访问的信息)相匹配，并且在步骤s114处，如果存在匹配分类信息的行李，则获取与该行李相对应的行李信息。在步骤s116处，该行李信息被预测为是由分类信息指示的、用于行李箱14a的行李信息，并且预测结果被发送到驾驶员14的用户终端18。

如果在步骤s114处不存在匹配分类信息的行李，则与上述图像数据的情况类似，管理服务器20返回到步骤s104并且向驾驶员14的用户终端18通知重复输入驾驶员14打算携带的行李14a的行李识别数据的请求。

行李信息注册

如图2所示，在步骤s118处，驾驶员14的用户终端18的cpu在显示设备上显示从管理服务器20接收的、关于行李14a的预测结果的“接受”按钮和“拒绝”按钮(均未被图示)。如果行李14a的预测结果基本上是正确的，则驾驶员14按下操作“接受”按钮。如果在步骤s120处按下“接受”按钮，则在步骤s122处，驾驶员14的用户终端18的cpu将接受通知发送到管理服务器20。在步骤s124处，管理服务器20的cpu将至少包括行李14a的尺寸信息的行李信息记录在预订数据库和用户数据库中，并且在步骤s126处，管理服务器20的cpu通过从车辆12的在用户数据库中记录的行李装载容量中减去行李14a的尺寸或体积等来计算剩余装载容量，并将该计算的结果记录在预订数据库中。注意的是，根据驾驶员14下一次输入行李14a的行李识别数据，显示驾驶员14的在用户数据库中已经记录的行李14a的行李信息，以便可在行李注册屏幕上的“先前注册的行李”栏32(见图5)中选择。当执行该操作时，还可以在输入图像数据旁边显示乘坐的日期和乘坐路段等。

然而，在步骤s118处显示的行李14a的预测结果是不正确的的情况下，在步骤s120处，驾驶员14按下操作“拒绝”按钮。如果按下“拒绝”按钮，则在步骤s128处，驾驶员14的用户终端18的cpu将拒绝通知发送到管理服务器20。在步骤s130处，管理服务器20的cpu重复搜索行李数据库或通过通信网络n可访问的信息，以找到与行李14a的行李识别数据匹配的行李。如果存在匹配行李识别数据的行李，则在步骤s114处，获取与该行李相对应的行李信息，并且在步骤s116处，该行李信息被预测为是行李14a的行李信息，并且将预测结果发送给作为第二候选者的驾驶员14的用户终端18。如果在步骤s114处没有匹配行李识别数据的行李，则管理服务器20返回到步骤s104，并且向驾驶员14的用户终端18通知重复输入驾驶员14打算携带的行李14a的行李识别数据的请求。重复上述处理，直到已经接收到已经按下“接受”按钮的通知。注意的是，尽管图中未被图示，但是当已经按下“拒绝”按钮时，管理服务器20可以通知驾驶员14的用户终端18输入不同的行李识别数据(例如，驾驶员直接地测量行李尺寸的结果)。

乘车人注册

希望在预订数据库上注册的多个旅行计划中的一个上共乘的乘车人16(17)使用其用户终端18上的未图示的显示屏输入该期望。在接收到输入旅行计划时，乘车人16(17)的用户终端18的cpu开始图3中图示的处理。如图3所示，在步骤s132处，乘车人16(17)的用户终端18的cpu响应于来自乘车人16(17)的指令向管理服务器20发送旅行计划列表传输请求。该传输请求包括选择缩小条件，以缩小在预订数据库上注册的多个旅行计划以供显示。注意的是，作为本示例性实施例中的示例，乘车人16、17(参见图1)用作两个共乘用户。以下说明主要集中于乘车人16，但其基本上适用于乘车人17。

在步骤s134处，管理服务器20的cpu从适合于从乘车人16(17)的用户终端18接收的传输请求中包括的选择缩小条件的预订数据库计划中提取旅行计划。管理服务器20的cpu将表示所提取的旅行计划的列表的数据发送到发送传输请求的乘车人16(17)的用户终端18。

在步骤s136处，乘车人16(17)的用户终端18的cpu在显示设备上显示从管理服务器20接收的旅行计划列表数据以及“申请共乘”按钮和输入列，在该输入列中输入所期望的上车位置和下车位置(这些都未被图示)。如果驾驶员16(17)希望预订正在显示的特定旅行计划上的共乘，则按下操作“申请共乘”按钮。当按下“申请共乘”按钮时，在步骤s138处，乘车人16(17)的用户终端18的cpu将其通知发送到管理服务器20。在步骤s140处，管理服务器20向乘车人16(17)的用户终端18发送输入要由乘车人16(17)携带的行李16a(17a)的行李识别数据的请求(参见图4)。

在步骤s142处，在从管理服务器20接收到输入行李16a(17a)的行李识别数据的通知时，如图5所示，乘车人16(17)的用户终端18的cpu在显示设备上显示行李注册屏幕。与上述驾驶员14的情况类似，乘车人16(17)输入一个类型的行李识别数据。在本示例性实施例中，如图4所示，乘车人16(17)使用用户终端18来捕获要携带的行李16a(17a)的图像，并且在图3中的步骤s144处，将通过该图像捕获而获得的图像数据从用户终端18发送到管理服务器20。注意的是，在本示例性实施例中，乘车人16(17)输入图像数据作为行李识别数据。然而，不限于此，并且当然，可以应用语音数据、文本数据、分类信息、和直接测量的尺寸等作为如上所述的行李识别数据。

在步骤s146处，管理服务器20的cpu使用与上述驾驶员14的情况类似的方法将从用户终端18接收的图像数据记录在预订数据库中。管理服务器20的cpu将图像数据与行李数据库(或通过通信网络n可访问的信息)相匹配，并且在步骤s148处，如果存在匹配图像数据的行李，则获取该行李的行李信息。在步骤s150处，该行李信息被预测为是由图像数据指示的、用于行李16a(17a)的行李信息，并且预测结果被发送到乘车人16(17)的用户终端18。

注意的是，在步骤s146处执行的匹配可以采用上面参考步骤s110描述的深度学习方法。

在步骤s152处，乘车人16(17)的用户终端18的cpu一起在显示设备上显示从管理服务器20接收的乘车人16(17)的行李16a(17a)的预测结果以及“接受”按钮和“拒绝”按钮(这两个按钮都未被图示)。在步骤s154处，如果行李16a(17a)的预测结果是不正确的，则乘车人16(17)按下操作“拒绝”按钮。如果按下“拒绝”按钮，则在步骤s155处，乘车人16(17)的用户终端18的cpu向管理服务器20发送拒绝通知。在步骤s157处，管理服务器20的cpu执行图像数据与行李数据库(或通过通信网络n可访问的信息)的匹配，并且处理如上述步骤s148处那样的过程。

在步骤s154处，如果行李16a(17a)的预测结果基本上是正确的，则乘车人16(17)按下操作“接受”按钮。如果按下“接受”按钮，则在步骤s156处，乘车人16(17)的用户终端18的cpu将接受通知发送到管理服务器20。在步骤s158处，管理服务器20的cpu将诸如行李16a(17a)的尺寸信息的行李信息记录在预订数据库中。以这种方式，行李信息被累积在行李数据库中。在步骤s160处，管理服务器20的cpu判断行李16a是否可在预订数据库中注册的剩余装载容量中装载。在步骤s161处，当乘车人16a被认为可装载时，决定驾驶员14的行李14a和行李16(17)的行李16a(17a)在行李箱34中的装载位置(参见图7)。通过计算使得行李箱34中的空间能够有效地被使用的装载位置，从行李14a和行李16a(17a)的行李信息决定装载位置。

注意的是，在步骤s161处，例如在其中例如驾驶员14的行李14a基于行李信息被注册为由具有不容易损坏的特性的硬质材料(诸如，硬壳行李箱)制成的情况下，管理服务器20的cpu决定装载位置(图中未图示)，其可以包括在行李14a的顶部上装载其它行李(在本示例性实施例中为行李16a、17a)。当执行该操作时，在要将其它行李16a、17a装载在行李14a的顶部上的情况下，在稍后描述的步骤s162处，可以通知行李14a的所有者(即，驾驶员14)其它行李16a、17a将被装载在上面。

在步骤s161处，在其中存在多个共乘用户(乘车人16、17)并且各个乘车人16、17之间的上车位置或下车位置中的至少一个不同的情况下，管理服务器20的cpu考虑到上车顺序或下车顺序中的至少一个而决定行李14a、16a、17a的装载位置。作为示例，在其中一个乘车人17要比另一个乘车人16更早地下车的情况下，决定装载位置，使得由要较早下车的乘车人17携带的行李17a装在行李箱34的开口38侧(接近侧，参见图8)上。这有利于在要提早下车的乘车人17下车时卸载行李17a。对此没有限制，并且可以仅考虑上车顺序来决定行李14a、16a、17a的装载位置，或者可以考虑上车顺序和下车顺序两者来决定行李14a、16a、17a的装载位置。

在决定驾驶员14的行李14a和乘车人16、17的行李16a、17a在行李箱34中的装载位置之后，在步骤s162处，管理服务器20的cpu向驾驶员14的用户终端18发送申请通知、关于乘车人16(17)的信息、关于要由乘车人16(17)携带的行李16a(17a)的信息、以及行李14a、16a(17a)的装载位置等。当发送行李14a、16a(17a)的装载位置时，管理服务器20的cpu使用行李信息来创建与行李14a、16a(17a)相对应的简单3d模型，并发送由线框配置的3d模型和表示箱子的图形，该线框示意性地表示在各个装载位置处装载到行李箱34中的状态下分配给相应行李14a、16a(17a)的空间(见图7)。如果乘车人16(17)的行李16a(17a)被认为是不可装载的，则在步骤s174处，通知乘车人16(17)的用户终端18行李16a是不可装载的，并且在显示设备上显示未进行预订的事实(步骤s175)。

在从管理服务器20接收到申请通知等时，驾驶员14的用户终端18的cpu在显示设备上显示关于乘车人16(17)的信息、关于要由乘车人16(17)携带的行李16a(17a)的信息、行李14a、16a(17a)的装载位置的图形、“接受”按钮和“拒绝”按钮(这些均未被图示)。如果驾驶员14按下“接受”按钮，则在步骤s164，驾驶员14的用户终端18的cpu将接受通知发送到管理服务器20。

在接收到来自驾驶员14的用户终端18的接受通知时，在步骤s166处，管理服务器20的cpu将乘车人16(17)、要由乘车人16(17)携带的行李16a(17a)、以及行李14a、16a(17a)的装载位置在数据库中注册为相对于相对应的旅行计划的乘车人注册。此外，管理服务器20的cpu将该旅行计划上的可用座位减少一个。如果该旅行计划上的可用座位的数目变为零，则管理服务器20的cpu为该旅行计划切换打开(on)“满”标志。当“满”标志已经被切换打开时，旅行计划不再有资格用于响应于列表传输请求的提取。

在步骤s168处，管理服务器20的cpu向驾驶员14的用户终端18和乘车人16(17)的用户终端18通知已经进行了匹配(预订)。在接收到已经进行了匹配的通知时，驾驶员14的用户终端18的cpu和乘车人16(17)的用户终端18的cpu各自在相应的显示设备上显示已经进行了预订(步骤s169)。在步骤s170处，管理服务器20的cpu将行李14a、16a(17a)的装载位置发送到驾驶员14的用户终端18和乘车人16(17)的用户终端18。为了发送装载位置，类似于步骤s162，管理服务器20的cpu创建由对应于行李14a、16a(17a)的线框配置的简单的3d模型和箱子，并发送图示3d模型和装载到行李箱34的装载位置中的箱子的装载状态的图形。当执行该操作时，如图8所示，强调行李14a的装载位置的图形被发送到持有行李14a的驾驶员14的用户终端18，并且强调行李16a(17a)的装载位置的图形被传送到持有行李16a(17a)的乘车人16(17)的用户终端18。在接收到装载位置的图形时，驾驶员14的用户终端18的cpu和乘车人16(17)的用户终端18的cpu在其相对应的显示设备上显示从管理服务器20发送的图形(步骤s171)。由上述处理完成共乘预订。

本示例性实施例的操作

以下是关于本示例性实施例的操作的说明。

在本示例性实施例中，共乘预订系统10包括图1图示的管理服务器20和用户终端18、检测单元、行李信息识别单元、匹配单元、和输出单元。当乘车人16(17)希望在车辆12中共乘时，乘车人16(17)向用户终端18输入有被采用以识别由乘车人16(17)携带的行李16a(17a)的行李识别数据。基于输入的行李识别数据，管理服务器20从存储有关于多件行李的信息的行李数据库中或者从通过通信网络n可访问的信息中至少识别用于行李16a的尺寸信息。然后基于行李16a(17a)的尺寸信息，管理服务器20判断行李16a(17a)是否可装载到共乘候选车辆12中。被认为可装载的行李16a(17a)被视为是对于车辆中的共乘进行预订的一个条件。相反，被认为不可装载的行李16a(17a)被视为是不对车辆中的共乘进行预订的一个条件。即，乘车人16(17)能够预订其中要携带的行李16a(17a)是可装载的可共乘的车辆12。这使得能够避免这样的情况，在该情况中乘车人16(17)在对车辆12进行共乘时然后并不能够将携带的行李16a(17a)装载到共乘车辆12中。从而，这就使得能够增强共乘时的便利性。

当行李16a(17a)被认为可装载时，一旦已经判断了行李16a(17a)在车辆12中的装载位置，就进行预订。当在车辆12中进行共乘时，乘车人16(17)能够通过参考图示在输出单元上指示的装载位置的信息来装载要携带的行李16a(17a)(参见图7)。即，能够顺利地装载行李16a(17a)，并且由于管理服务器20还通过考虑其它行李14a等来确定装载位置，因此还能够有效地利用车辆12的行李箱34(参见图7)。

管理服务器20通过与将携带行李14a、16a(17a)的驾驶员14或乘车人16(17)相关联地存储而存储已经识别出其尺寸信息的行李14a、16a(17a)。在下一次驾驶员14或乘车人16(17)向检测单元输入有要携带的行李14a、16a(17a)的行李识别数据时，使得进行可选择在管理服务器20中与驾驶员14或乘车人16(17)相关联地存储的行李14a、16a(17a)。因此，驾驶员14或乘车人16(17)在下一次他们携带与先前在乘坐时携带的行李14a、16a(17a)相同的行李14a、16a(17a)的任何行李而乘坐时能够容易地输入行李14a、16a(17a)的行李识别数据。

在输入行李识别数据时采用驾驶员14或乘车人16(17)持有的用户终端18，并且通过使用用户终端18捕获的行李14a、16a(17a)的图像数据来配置行李识别数据。因此，在不需要测量要携带的行李14a、16a(17a)的尺寸等的情况下，驾驶员14或乘车人16(17)能够不论他们在哪里都容易地输入行李14a、16a(17a)的行李识别数据。这使得能够进一步增强共乘时的便利性。

在管理服务器20已经判断有可能在至少一件行李14a、16a、17a的顶部上装载至少一件其它行李14a、16a、17a的情况下，管理服务器20向携带行李14a、16a、17a的用户(驾驶员14，乘车人16、17)通知可能在顶部上装载另一件行李14a、16a、17a的可能性。因此，用户(驾驶员14、乘车人16、17)能够预先选择另一车辆12或采取诸如在要携带的行李14a、16a、17a是易碎的等并且容易受到另一件行李14a、16a、17a的影响的情况下包裹行李14a、16a、17a的对策。这使得能够防止对行李14a、16a、17a的损坏等。

在已经预先从车辆的装载容量中减去由驾驶员14携带的行李14a的行李信息的状态下确定乘车人16(17)的行李16a(17a)的装载能力。即，采用更精确的装载容量作为参数使得能够在共乘时顺利地执行行李16a(17a)的装载。因此，这从而使得能够进一步增强在共乘时的便利性。

当行李16a、17a被认为可装载时，管理服务器20考虑到乘车人16、17的上车顺序或下车顺序中的至少一个来确定行李14a、16a、17a在车辆12中的装载位置。因此，能够通过例如将由提早下车的乘车人17携带的行李17a放置在另一个行李前面来顺利地执行下车。即，能够根据上车或下车状态适当地分配行李14a、16a、17a的装载位置，从而使得能够顺利地执行上车或下车中的至少一个。

此外，管理服务器20考虑到行李14a当被认为可装载时的类型来确定行李14a在车辆12的行李箱34中的装载位置。因此，当行李14a是硬壳行李箱时，通过例如将其它行李16a、17a装载在行李14a的顶部上，能够装载更多的行李。这从而使得能够更有效地利用车辆12的行李箱34。

第二示例性实施例

下面参考图9说明根据本公开的第二示例性实施例的共乘预订系统。在配置上与上述第一示例性实施例类似的部分被分配相同的附图标记，并且省略其说明。

根据第二示例性实施例的共乘预订系统100具有与第一示例性实施例中的其对应方相同的基本配置，并且包括下述特征：在通知乘车人16(17)的行李16a(17a)在车辆12中是不可装载的时，通知关于将是可装载的行李的信息。

即，如图9所示，在步骤s158处，管理服务器20的cpu将诸如行李16a(17a)的尺寸信息的行李信息记录在预订数据库中，并且在步骤s160处，管理服务器20的cpu判断行李16a(17a)是否对于在预订数据库中注册的剩余装载容量是可装载的。当驾驶员16(17)的行李16a(17a)被认为是不可装载的时，在步骤s300处，管理服务器20的cpu通知乘车人16(17)的用户终端18行李16a(17a)是不可装载的。当这样做时，管理服务器20的cpu还通知：关于对于在预订数据库中记录的剩余装载容量能够是可在车辆12中装载的行李的形状和尺寸的信息；以及，关于能够是可装载的行李的装载位置的信息。

在步骤s302处，乘车人16(17)的用户终端18在显示设备上显示行李16a(17a)是不可装载的以及能够是可装载的行李的尺寸、形状和装载位置(都未被图示)。如果乘车人16(17)能够通过基于所指示的装载位置重新组织或更换行李16a(17a)等来使行李16a(17a)成为可装载的尺寸、形状等，则乘车人16(17)按下操作“能够符合”按钮(图中未被图示)。当已经在步骤s303处按下“能够符合”按钮时，乘车人16(17)的用户终端18的cpu在步骤s304处向管理服务器20发送能够符合的通知。

在步骤s306处，管理服务器20的cpu在预订数据库中记录乘车人16(17)将改变行李16a(17a)以便实现在车辆12中可装载的行李的事实。接下来，管理服务器20的cpu在步骤s162处向驾驶员14的用户终端18发送以共乘的申请的通知、关于乘车人16(17)的信息、乘车人16(17)将要携带的行李16a(17a)改变为可装载在车辆12中的行李的事实、和关于装载位置的信息等。如果驾驶员14接受用于共乘的该申请，则执行类似于第一示例性实施例的处理的处理，并且使得驾驶员14的用户终端18的cpu和乘车人16(17)的用户终端18的cpu显示已经在它们相应的显示设备上进行了预订(步骤s169)。

然而，如果乘车人16(17)不能够使行李16a(17a)成为可装载的尺寸、形状等，则乘车人16(17)按压操作“不能符合”按钮(图中未被图示)。当已经在步骤s303处按下“不能符合”按钮时，在步骤s308处使显示设备显示尚未进行预订。

第二示例性实施例的操作

以下是关于第二示例性实施例的操作的说明。

与第一示例性实施例的共乘预订系统10类似地配置上述配置，其中除了在通知乘车人16(17)的行李16a(17a)在车辆12中是不可装载的时还通知可装载的行李的信息。因此，获得了与第一示例性实施例类似的操作。此外，管理服务器20向乘车人16(17)通知当要装载的行李16a(17a)被判断为在车辆12中是不可装载的时能够是可装载的行李的尺寸信息和装载位置。这使得乘车人16(17)基于考虑到装载位置或是否乘坐不同的车辆能够是可装载的行李的尺寸信息来考虑是否重新组织或更换行李16a(17a)。即，乘车人16(17)能够被提供有更多选择。因此，这从而使得当共乘时能够进一步增强便利性。

注意的是，上述第一和第二示例性实施例被配置为使得通过输入到用户终端18的行李识别数据由用户终端18来检测行李识别数据。然而，不限于此，并且可以进行配置，使得通过以下方式来检测行李识别数据：使用在建筑物、电动车辆充电站、或车辆等中安装的成像装置、使用配备有语音输入设备或文本输入设备等的行李检测设备、或使用另一种专用终端来输入行李识别数据；使用用作接收部分的用户终端18、行李检测设备、或另一专用终端的至少一个接收行李识别数据；以及驾驶员14或乘车人16(17)确认所接收到的行李识别数据。可替选地，可以预先提供不同尺寸的多个容器，检查行李适合到其中的尺寸容器，以及将行李适合到其中的容器的尺寸信息检测为行李识别数据。还可以使用另一种配置来检测行李识别数据。

不存在对根据用户终端18或根据被采用用于图像数据、语音数据、或文本输入的传感器来配置检测单元的限制。例如，这样的传感器或用户终端18可以被采用为外部终端，并且可以由从那里接收行李识别数据的信号接收器设备(例如，在用户终端18或管理服务器20内提供的信号接收器设备)来配置检测单元。

通过管理服务器20从行李数据库或通信网络n获取匹配检测到的行李识别数据的行李信息。然而，不限于此，可以应用其它配置。例如，可以由用户终端18的cpu等配置行李信息识别单元。如果记录有多条行李信息的行李数据库被保存在用户终端18中，则可以采用其中在不需要通过通信网络n进行通信的情况下而获取行李信息的配置。

此外，不存在对其中从行李数据库或通过通信网络n获取行李信息以与检测到的行李识别数据匹配的配置的限制。可以通过直接地检测尺寸信息来识别行李信息。例如，可以根据关于由用户终端18的成像装置获取的图像数据的图像处理结果来预测行李的尺寸信息(该处理可以采用已知的图像处理技术)。

尽管采用了其中来自管理服务器20的通知和信息被显示在用户终端18的显示设备上的配置，但是不限于此，并且可以将这样的通知和信息作为来自扬声器的音频输出到驾驶员14或者乘车人16(17)。可替选地，可以采用这样的配置：其中从除了用户终端18之外的终端或设备(例如，在车辆12中作为车辆导航设备、在电动车辆充电站、或在建筑物中安装的设备的显示设备或扬声器)输出通知和信息。

输出单元不限于是显示设备或扬声器，并且可以是传输设备(例如，在用户终端18或管理服务器20内部设置的信号传输设备)，以传输导致在显示设备或扬声器等上输出图像、或音频等的输出信号。

此外，尽管共乘预订系统10、100被图示为出于允许乘车人16(17)在由驾驶员14驱动的车辆12中共乘的目的而操作的配置，但是不限于此。出于允许乘车人16(17)在不存在驾驶员14的自控车辆中共乘的目的可以操作共乘预订系统10、100。在这种情况下，在上面的说明中对应于驾驶员14的用户也变成乘车人16。

尽管作为驾驶员14的用户通告招募乘车人16(17)以在特定的旅行计划上共乘，并且通过希望在特定旅行计划共乘的乘车人16(17)响应来做出预订，对此没有限制。可以采用这样的配置：其中，乘车人16(17)首先注册期望的共乘日期和时间、期望的共乘路段、和行李识别数据。然后，管理服务器20向乘车人16(17)通知关于适用车辆的信息，并且乘车人16(17)接受该信息来进行预订。

此外，尽管管理服务器20使用尺寸信息来基于车辆12的剩余负载能力判断是否能够装载行李14a、16a(17a)，但是不限于此。例如，可以采用行李的属性信息、形状、或重量作为参数，以便确定可装载能力，诸如“当行李易碎时不能够将其它行李放置在行李的顶部上，因此不能够装载另外的行李”。

此外，尽管由用作匹配单元的管理服务器20执行共乘预订，但是不限于此。可以采用包括多个服务器和终端等的配置，并且通过区块链展示的分布式分类帐技术来在多个服务器和终端等中的每一个上保持行程计划信息和行李识别数据等，其中用户根据区块链上的、确保完整性的数据进行预订。还可以采用其它配置。

尽管管理服务器20的cpu采用深度学习方法来将从用户终端18接收的图像数据中描绘的行李14a与在行李数据库中记录的行李信息进行匹配，但是不限于此。可以采用这样的配置：其中使用诸如采用支持向量机(svm)或模板匹配等地的另一种已知方法在捕获的图像中识别和匹配行李。

尽管已经关于本公开的示例性实施例给出了说明，但是本公开不限于以上，并且显然可以在不脱离本公开的精神的范围内实现各种其它修改。