配送系统及存储介质的制作方法

本发明涉及一种配送系统及存储介质。

背景技术：

例如，在引用文献1中，公开了一种汇总配送系统，获取由货物的接收方的用户预先设定的一个配送目的地，当将从一个或多个发送地分别通过互不相同的多个配送公司(deliverycompany)而集中的多个货物，借由与接收方的用户不同的用户的指示而配送至一个配送目的地时，能够设定为将与各货物相关联的第一配送信息，从所述发送地配送至与一个配送目的地不同的规定地点，并且能够设定为一个配送公司将与各货物相关联的第二配送信息，从规定的地点汇总配送至一个配送目的地，判定由不同的用户指示配送的各货物的第一配送信息的配送目的地与接收方的用户所预先设定的一个配送目的地是否一致，当判定为一致时，将第一配送信息的配送目的地从一个配送目的地变更为规定的地点。

[现有技术文献]

[专利文献]

专利文献1：日本专利第6196325号公报

技术实现要素：

[发明所要解决的问题]

在一般的配送系统中，是多个配送公司分别各别地进行配送，所以有时即使是共同的配送目的地，也对每个货物分别进行配送。

本发明的目的在于与多个配送公司分别各别地向配送目的地配送货物的情况相比，将多个货物更有效率地配送至共同的配送目的地。

[解决问题的技术手段]

技术方案1所述的发明是一种配送系统，包括：受理构件，从接收货物的接收人，受理对多个配送公司咨询所述接收人的信息的允许；获取构件，当得到所述允许时，从所述多个配送公司分别获取发往所述接收人的货物的相关信息；以及生成构件，当所述获取构件所获取的信息满足预先规定的条件时，生成使发往所述接收人的多个货物汇总配送的信息。

技术方案2所述的发明根据技术方案1所述的配送系统，其中所述预先规定的条件是指如下的条件：当所述多个货物的配送目的地的住址已指定时，所述住址为共同，当所述多个货物的配送目的地的住址未指定时，所述接收人为共同。

技术方案3所述的发明根据技术方案1所述的配送系统，其中所述生成构件进而生成如下的信息，即，使发往所述接收人的货物的配送、与发往住址与所述接收人为共同的其他接收人的货物汇总配送。

技术方案4所述的发明根据技术方案3所述的配送系统，其中所述生成构件在不允许将发往所述接收人的货物与发往所述其他接收人的货物加以汇总配送时，生成使发往所述接收人的货物与发往所述其他接收人的货物分别配送的信息。

技术方案5所述的发明根据技术方案1所述的配送系统，其中所述受理构件从所述接收人，受理允许或不允许将发往所述接收人的货物与发往住址与所述接收人为共同的其他接收人的货物加以汇总配送的设定。

技术方案6所述的发明根据技术方案5所述的配送系统，其中所述受理构件进而根据发往所述接收人的货物的种类，受理允许或不允许将发往所述接收人的货物与发往所述其他接收人的货物加以汇总配送的设定。

技术方案7所述的发明根据技术方案1所述的配送系统，其中所述受理构件从所述接收人，受理允许或不允许即使是发往与所述接收人共同的住址的货物也向各个人分别进行配送的设定。

技术方案8所述的发明根据技术方案1所述的配送系统，其中还包括指示构件，所述指示构件是当对所述获取构件从一个配送公司获取到的信息中所含的货物，通过并非所述一个配送公司的自身系统的配送构件而进行配送时，对所述一个配送公司指示不配送所述货物。

技术方案9所述的发明根据技术方案1所述的配送系统，其中还包括通知构件，所述通知构件是当对所述获取构件从一个配送公司获取到的信息中所含的货物，通过并非所述一个配送公司的自身系统的配送构件而进行配送时，如果通过所述配送构件而使所述货物的配送完成，就对所述一个配送公司通知所述货物的配送已完成。

技术方案10所述的发明是一种存储介质，其存储用于使计算机实现功能的程序，其中使计算机实现如下的功能：从接收货物的接收人，受理对多个配送公司咨询所述接收人的信息的允许；当得到所述允许时，从所述多个配送公司分别获取发往所述接收人的货物的相关信息；以及当通过所述获取的功能而获取到的信息满足预先规定的条件时，生成使发往所述接收人的多个货物汇总配送的信息。

技术方案11所述的发明是一种存储介质，其存储用于使计算机实现功能的程序，其中使计算机实现如下的功能：从购买了多个商品的用户，受理对在互联网上在多个店铺中购买到的所述多个商品进行汇总配送的指示；以及将所述指示，发送至用于从所述配送公司继续承接经配送公司配送的商品的配送而将所述商品配送至配送目的地的配送系统。

技术方案12所述的发明根据技术方案11所述的存储介质，其中所述指示包括为了汇总配送所述多个商品而使所述商品滞留于所述配送公司的上限的期间的指示。

[发明的效果]

根据技术方案1所述的发明，与多个配送公司分别各别地向配送目的地配送货物的情况相比，能够将多个货物更有效率地配送至共同的配送目的地。

根据技术方案2所述的发明，不论是否已指定多个货物的配送目的地的住址，都能够汇总配送多个货物。

根据技术方案3所述的发明，能够汇总配送发往接收人的货物及发往其他接收人的货物。

根据技术方案4所述的发明，即使是存在发往住址与接收人为共同的其他接收人的货物的情况，也能够不使发往接收人的货物与发往其他接收人的货物汇总配送。

根据技术方案5所述的发明，接收人能够选择是否汇总配送发往接收人的货物与发往其他接收人的货物。

根据技术方案6所述的发明，接收人能够根据发往接收人的货物的种类，选择是否与发往其他接收人的货物汇总配送。

根据技术方案7所述的发明，即使是发往与接收人为共同的住址的货物，接收人也能够选择是否向各个人分别进行配送。

根据技术方案8所述的发明，与关于从一个配送公司获取到的信息中所含的货物，不对一个配送公司指示不配送货物的结构相比，可抑制被一个配送公司错误配送货物。

根据技术方案9所述的发明，在一个配送公司中，货物的配送已完成变得明确。

根据技术方案10所述的发明，与多个配送公司分别各别地向配送目的地配送货物的情况相比，能够通过计算机来实现将多个货物更有效率地配送至共同的配送目的地的功能。

根据技术方案11所述的发明，与多个配送公司分别各别地向配送目的地配送货物的情况相比，能够通过计算机来实现将多个货物更有效率地配送至共同的配送目的地的功能。

根据技术方案12所述的发明，能够以不使商品超过经指示的期间而滞留于配送公司的方式，来配送商品。

附图说明

图1是表示本实施方式的配送系统的整体结构例的图。

图2是表示本实施方式的共同用户管理服务器的硬件结构例的图。

图3是表示本实施方式的共同用户管理服务器的功能结构例的框图。

图4是表示本实施方式的配送任务(task)管理服务器的功能结构例的框图。

图5是表示本实施方式的配送日程(schedule)管理服务器的功能结构例的框图。

图6是表示用户注册的处理顺序的一例的流程图。

图7是表示配送任务制作的处理顺序的一例的流程图。

图8是表示配送任务制作的处理顺序的一例的流程图。

图9(a)是用户信息表中所注册的用户a的信息的一例的图。图9(b)是表示通过配送公司服务器而管理的用户a的信息的一例的图。图9(c)是表示通过配送公司服务器而管理的用户a的信息的一例的图。图9(d)是表示配送公司服务器中所注册的用户a的信息的一例的图。

图10(a)是表示用户信息表中所注册的用户b的信息的一例的图。图10(b)是表示通过配送公司服务器而管理的用户c的信息的一例的图。图10(c)是表示用户管理表中所注册的用户c的信息的一例的图。

图11(a)～图11(c)是表示用户委托给配送公司的货物的配送委托的信息的一例的图。

图12是表示配送任务制作部所制作的配送任务的一例的图。

图13是表示日程制作部所制作的配送日程的一例的图。

[符号的说明]

1：配送系统

100：共同用户管理服务器

111：注册用户信息受理部

112：注册用户信息获取部

113：用户信息注册部

114：显示信息输出部

115：用户信息保存部

200：配送任务管理服务器

211：配送委托信息获取部

212：用户信息获取部

213：配送任务制作部

214：配送任务保存部

300：配送日程管理服务器

311：配送任务获取部

312：日程制作部

313：日程通知部

314：配送状况管理部

315：配送状况通知部

400：配送员终端

500：配送公司服务器

600：委托人终端

具体实施方式

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

＜配送系统的整体结构＞

图1是表示本实施方式的配送系统1的整体结构例的图。本实施方式的配送系统1是如下的系统：与配送公司的配送员另外地准备的配送系统1的配送员从配送公司继续承接经配送公司配送的货物的配送，去接收配送公司所管理的货物，将所接收的货物配送至配送目的地。

如图1所示，本实施方式的配送系统1包括共同用户管理服务器100、配送任务管理服务器200、配送日程管理服务器300、配送员终端400、配送公司服务器500a、配送公司服务器500b、配送公司服务器500c及委托人终端600。所述各装置与网络700连接。

再者，配送公司服务器500a、配送公司服务器500b、配送公司服务器500c是各个配送公司内所管理的服务器装置，当不需要对它们进行区别时，只称为配送公司服务器500。并且，在图1所示的示例中，示出了三个配送公司服务器500，但是配送公司服务器500的台数并不限定于图示的三个。

共同用户管理服务器100是对利用配送系统1的用户的信息进行管理的服务器装置。共同用户管理服务器100针对利用配送系统1的用户，对每个用户分配固有的标识符(identifier，id)(即，用于识别用户的识别信息)，管理用户的姓名、住址、电话号码等信息。并且，共同用户管理服务器100访问各配送公司的配送公司服务器500，获取通过配送公司服务器500而管理的用户的信息。这时，将允许对配送系统1公开信息的用户的信息作为对象。

再者，以下，有时将由共同用户管理服务器100分配的用户的id称为“共同id”。

配送任务管理服务器200是访问各配送公司的配送公司服务器500，获取用户委托各配送公司的货物的配送委托的信息的服务器装置。并且，配送任务管理服务器200从共同用户管理服务器100，获取共同用户管理服务器100所管理的用户的信息。然后，配送任务管理服务器200基于所获取的信息，制作配送任务。配送任务是获得货物的配送作为任务，针对每个货物的配送而制作。在这里，配送任务管理服务器200基于作为货物的配送目的地的地点及人的信息，在可汇总进行多个配送时汇总成一个配送任务。

配送日程管理服务器300是针对每个配送任务，制作用于配送员配送货物的配送日程的服务器装置。在这里，配送日程管理服务器300基于配送中心的住址、货物的配送目的地的住址、配送员的当前所在地等，制作配送日程。所谓配送中心，是指配送公司内的货物的最终据点，是保管配送至配送目的地的货物的地点。配送系统1的配送员按照配送日程，去配送中心接收货物，将接收到的货物配送至配送目的地。

配送员终端400是配送系统1的配送员所使用的终端装置，例如，可例示智能手机、移动手机等移动信息终端。配送员终端400例如通过全球定位系统(globalpositioningsystem，gps)等而获取自身终端的当前所在地的信息，将所获取的当前所在地的信息定期(例如，每分钟)发送至配送日程管理服务器300。并且，配送员终端400从配送日程管理服务器300，接收配送日程的信息。配送员按照所接收到的配送日程，进行货物的配送。

配送公司服务器500是由各个配送公司管理的服务器装置。在各个配送公司中，单独管理成为接收货物的接收人的用户，在配送公司服务器500中，针对每个用户，注册了用户的姓名、住址、电话号码、赋予至用户的固有的id等信息。并且，在各个配送公司中，如果从用户受理到货物的配送委托，就将所受理的配送委托的信息保存于配送公司服务器500。

再者，配送公司是管理至少一个配送公司服务器500，但是也存在一个配送公司管理多个配送公司服务器500的情况。

另外，以下，有时将由配送公司服务器500分配的用户的id称为“个别id”。

委托人终端600是委托货物的配送的用户所使用的终端装置，例如，可例示智能手机、移动手机等移动信息终端。例如，用户利用委托人终端600浏览互联网上的网站(website)，通过网站而购买商品。这时，通过用户委托已购买的商品的配送，委托人终端600受理商品的配送委托。经受理的配送委托的信息例如被发送至销售商品的店铺，由店铺对配送公司服务器500委托货物的配送。并且，用户也可以访问配送公司服务器500，委托货物的配送。

另外，委托人终端600显示用户注册画面，受理注册于配送系统1的用户的信息。配送系统1中所注册的用户(以下称为注册用户)可以利用配送系统1的配送员所提供的配送服务。再者，注册用户的信息是从委托人终端600发送至共同用户管理服务器100，如上所述，通过共同用户管理服务器100而管理。

网络700是共同用户管理服务器100、配送任务管理服务器200、配送日程管理服务器300、配送员终端400、配送公司服务器500、委托人终端600中的信息通信时所使用的通信构件，例如，包括互联网或公共线路、局域网(localareanetwork，lan)。并且，网络700包括利用有线通信的网络及利用无线通信的网络。

＜共同用户管理服务器的硬件结构＞

图2是表示本实施方式的共同用户管理服务器100的硬件结构例的图。

如所述图2所示，本实施方式的共同用户管理服务器100包括运算构件即中央处理器(centralprocessingunit，cpu)101、保存基本输入输出系统(basicinputoutputsystem，bios)等的程序的存储区域即只读存储器(readonlymemory，rom)102、以及程序的执行区域即随机存取存储器(randomaccessmemory，ram)103。并且，共同用户管理服务器100包括存储操作系统(operatingsystem，os)或应用程序等各种程序、针对各种程序的输入数据、及来自各种程序的输出数据等的存储区域即硬盘驱动器(harddiskdrive，hdd)104。

此外，共同用户管理服务器100包括用于进行与外部的通信的通信界面(通信i/f(interface))105、显示器等显示机构106、键盘或鼠标、触摸屏(touchpanel)等输入器件107。

再者，关于配送任务管理服务器200、配送日程管理服务器300、配送员终端400、配送公司服务器500、委托人终端600，例如，也可以使用与图2所示的硬件结构同样的结构。

＜共同用户管理服务器的功能结构＞

其次，对本实施方式的共同用户管理服务器100的功能结构进行说明。图3是表示本实施方式的共同用户管理服务器100的功能结构例的框图。本实施方式的共同用户管理服务器100包括注册用户信息受理部111、注册用户信息获取部112、用户信息注册部113、显示信息输出部114及用户信息保存部115。

作为受理构件的一例的注册用户信息受理部111受理注册于配送系统1的用户的用户信息。例如，注册用户信息受理部111在委托人终端600的显示器中所显示的用户注册画面中，被输入用户的姓名、住址、电话号码等用户信息时，受理所输入的用户信息。

如果作进一步说明，则是在用户注册画面中，用户也进行作为利用对象的配送公司的选择。用户允许在这里经选择的配送公司将配送公司所管理的自身的信息公开至配送系统1。即，用户允许向在这里经选择的配送公司咨询自身的信息。附带说明一下，在配送公司的选择中，例如，用户既可以从预先规定的多个配送公司之中选择一个或多个配送公司，也可以一次性选择预先规定的多个配送公司。

另外，用户在存在曾经利用过的配送公司时，也可以在用户注册画面中，输入曾经利用时由配送公司赋予的自身的个别id。

当用户在用户注册画面中完成用户信息的输入，执行注册后，将在用户注册画面中所输入的信息(即，注册用户信息受理部111所受理的信息)，如后所述，通过用户信息注册部113而注册至用户信息表中。

注册用户信息获取部112在进行用户的注册后，所述注册用户访问已作为利用对象而选择的配送公司的配送公司服务器500，获取在配送公司服务器500中所管理的注册用户的个别id的信息。例如，当在用户注册画面中已输入个别id时，注册用户信息获取部112基于所输入的个别id进行注册用户的查询，判定所述个别id是否有效。并且，例如，当在用户注册画面中未输入个别id时，注册用户信息获取部112基于注册用户的姓名、住址、电话号码等信息进行注册用户的查询，获取配送公司服务器500中所管理的注册用户的个别id作为有效的id。

如上所述，注册用户信息获取部112从注册用户已作为利用对象而选择的各配送公司服务器500，获取注册用户的个别id的信息。并且，在各配送公司的配送公司服务器500中，可认为针对每个用户注册有各种信息，因此注册用户信息获取部112不但可以获取个别id，也可以获取注册用户的其它信息。

另外，注册用户信息获取部112在用户信息表中，获取注册了与注册用户的住址相同的住址的其他用户的信息。这样的用户是注册用户的家人或家人以外的同居人等，作为与注册用户同居的用户(以下称为同居用户)来处理。

此外，注册用户信息获取部112访问注册用户已作为利用对象而选择的配送公司的配送公司服务器500，获取已允许向配送系统1公开信息的用户之中、注册了与注册用户的住址相同的住址的其他用户的信息。这样的用户也作为与注册用户同居的同居用户来处理。

但是，注册用户信息获取部112并不限于在获取同居用户的信息时，访问注册用户已作为利用对象而选择的配送公司的配送公司服务器500的结构。例如，注册用户信息获取部112也可以访问配送系统1中的所有配送公司服务器500，获取与注册用户同居的同居用户的信息。

用户信息注册部113在进行用户的注册后，对所述注册用户分配共同id。然后，用户信息注册部113使用户信息受理部所受理到的注册用户的信息与共同id相对应，而注册于用户信息表。并且，用户信息注册部113使注册用户信息获取部112从配送公司服务器500获取到的注册用户的个别id等信息，与注册用户的共同id相对应，而注册于用户信息表。此外，用户信息注册部113使与注册用户同居的同居用户的信息也与注册用户的共同id相对应，而注册于用户信息表。

显示信息输出部114输出用于使画面显示于委托人终端600的显示器的数据。例如，显示信息输出部114将用户注册画面的信息输出至委托人终端600，使用户注册画面显示于委托人终端600的显示器。

用户信息保存部115保存用户信息表。用户能够从委托人终端600访问用户信息表，参照所注册的自身的用户信息，或进行用户信息的变更或删除。

而且，构成共同用户管理服务器100的各功能部是通过软件与硬件资源协同工作而实现。具体地说，例如，在通过图2所示的硬件结构而实现共同用户管理服务器100的情况下，通过将存储于hdd104等的各种程序读入至ram103并由cpu101执行，来实现图3所示的注册用户信息受理部111、注册用户信息获取部112、用户信息注册部113、显示信息输出部114等功能部。并且，用户信息保存部115例如是通过hdd104来实现。

＜配送任务管理服务器的功能结构＞

其次，对本实施方式的配送任务管理服务器200的功能结构进行说明。图4是表示本实施方式的配送任务管理服务器200的功能结构例的框图。本实施方式的配送任务管理服务器200包括配送委托信息获取部211、用户信息获取部212、配送任务制作部213及配送任务保存部214。

作为获取构件的一例的配送委托信息获取部211定期地(例如，每个小时)访问各配送公司的配送公司服务器500，获取各配送公司从用户受理到的货物的配送委托的信息。在这里，配送委托信息获取部211从各配送公司的配送公司服务器500，获取发往已允许向配送系统1公开信息的用户的货物的配送委托的信息。例如，当一个用户已允许在配送公司服务器500a及配送公司服务器500b中公开信息时，从配送公司服务器500a及配送公司服务器500b分别获取发往一个用户的货物的配送委托的信息。

用户信息获取部212从共同用户管理服务器100，获取配送委托信息获取部211所获取的配送委托的配送目的地即用户的信息。

作为生成构件的一例的配送任务制作部213基于配送委托信息获取部211所获取的配送委托的信息、及用户信息获取部212所获取的用户的信息，针对每个货物的配送，制作配送任务。在这里，配送任务制作部213例如，既可以在配送委托信息获取部211获取到配送委托的信息的时机制作配送任务，也可以在配送委托信息获取部211获取到配送委托的信息之后，等待获取其它配送委托的信息，而制作配送任务。并且，例如，也可以在累积预先规定数量的配送委托之后，制作配送任务。

如果作进一步说明，则是在配送任务制作部213所制作的配送任务中，包含配送目的地即用户的姓名、住址、电话号码、共同id、表示配送任务的状态的任务状态(status)等信息。并且，当配送委托的委托方的用户指定了希望配送的日期和时间时，经指定的希望配送日期和时间的信息也包含在配送任务中。而且，配送任务制作部213在配送委托中所含的多个货物的相关信息满足预先规定的条件时，将多个货物的配送汇总成一个而制作配送任务。在本实施方式中，将多个货物的配送汇总成一个而制作的配送任务是作为使多个货物汇总配送的信息的一例而使用。

更具体地说，作为配送的汇总方法，存在将货物的配送目的地即地点作为关键而汇总的方法、以及将货物的配送目的地即人作为关键而汇总的方法。当货物的配送目的地的住址已指定时，使用将地点作为关键而汇总的方法。另一方面，当货物的配送目的地的住址未指定时，使用将人作为关键而汇总的方法。

例如，当发往同一用户的货物中配送目的地的住址相同时，配送任务制作部213利用将地点作为关键而汇总的方法，汇总为一个配送任务。并且，例如，即使是发往不同用户的货物，当所述用户彼此是家人或同居人的关系而配送目的地的住址为相同时，配送任务制作部213也汇总为一个配送任务。但是，即使用户彼此是家人或同居人的关系，当不允许向同居用户进行配送时，也制作各别的配送任务，而不汇总为一个配送任务。

另一方面，在货物之中，例如，即使配送目的地的用户经指定，也存在配送目的地的住址不固定的情况。在这种情况下，配送任务制作部213利用将人作为关键而汇总的方法，将发往同一用户的货物汇总为一个配送任务。配送目的地的地点是通过配送任务管理服务器200或配送日程管理服务器300等利用邮件等通知配送目的地的用户，而从用户受理配送目的地的地点的指定。

配送任务保存部214保存配送任务制作部213所制作的配送任务的信息。

另外，与共同用户管理服务器100同样地，例如，通过将存储于hdd等的各种程序读入至ram并由cpu执行，来实现图4所示的配送委托信息获取部211、用户信息获取部212、配送任务制作部213等功能部。并且，配送任务保存部214例如通过hdd而实现。

＜配送日程管理服务器的功能结构＞

其次，对本实施方式的配送日程管理服务器300的功能结构进行说明。图5是表示本实施方式的配送日程管理服务器300的功能结构例的框图。本实施方式的配送日程管理服务器300包括配送任务获取部311、日程制作部312、日程通知部313、配送状况管理部314及配送状况通知部315。

配送任务获取部311获取通过配送任务管理服务器而制作的配送任务的信息。

日程制作部312针对配送任务获取部311所获取的每个配送任务，制作用于配送系统1的配送员配送货物的配送日程。在这里，日程制作部312是针对各配送任务，基于货物所到达的配送中心的住址、货物到达配送中心的预定时刻、货物的配送目的地的住址、配送员的当前所在地等，制作配送日程。例如，日程制作部312在多个货物的配送经汇总的配送任务中，多个货物到达相同的配送中心的情况下，以配合到达预定时刻较晚的货物，配送员抵达配送中心的方式，制作配送日程。

日程通知部313将日程制作部312所制作的配送日程通知给配送员终端400。在这里，在存在多个配送员的情况下，对各个配送员的配送员终端400通知配送日程。

配送状况管理部314针对每个配送任务，管理货物的配送状况。在这里，配送状况管理部314结合货物的配送状况，更新配送日程的信息。例如，当配送员在配送中心接收到货物时，通过配送员对配送员终端400进行操作，而将配送员已接收到货物的情况通知给配送日程管理服务器300。通过所述通知，配送状况管理部314将配送任务保存部214中所保存的配送任务的任务状态，从“集配中”变更为“配送中”。

作为指示构件、通知构件的一例的配送状况通知部315对货物的配送目的地即用户，通知货物的配送状况、货物的当前位置的信息、货物的到达预定时刻等。并且，配送状况通知部315在配送系统1的配送员配送货物的情况下，对管理所述货物的配送公司的配送公司服务器500，指示不配送货物。然后，配送状况通知部315在货物的配送完成时，对管理所述货物的配送公司的配送公司服务器500，通知货物的配送已完成。

再者，针对配送公司的指示或通知并不限于对配送公司服务器500进行的结构。只要对配送公司进行指示或通知即可，例如，也可以通过邮件来指示或通知配送公司服务器500的管理员，或通过邮件来指示或通知配送公司中负责货物的配送的负责人。

接着，与共同用户管理服务器100同样地，例如，通过将存储于hdd等的各种程序读入至ram并由cpu执行，来实现图5所示的配送任务获取部311、日程制作部312、日程通知部313、配送状况管理部314、配送状况通知部315等功能部。

＜用户注册的处理顺序＞

其次，对共同用户管理服务器100进行用户注册的处理的顺序进行说明。图6是表示用户注册的处理顺序的一例的流程图。

再者，以下，有时将处理的步骤记作记号“s”。

首先，当用户为了注册于配送系统1，而从委托人终端600访问共同用户管理服务器100时，显示信息输出部114将用户注册画面的信息输出至委托人终端600。接着，使用户注册画面显示于委托人终端600的显示器(s101)。其次，注册用户信息受理部111从委托人终端600受理用户信息(s102)。

其次，当基于所受理的用户信息执行用户注册时，用户信息注册部113对注册用户分配共同id。接着，使注册用户的用户信息与共同id相对应，而注册于用户信息表(s103)。其次，注册用户信息获取部112访问注册用户已作为利用对象而选择的配送公司的配送公司服务器500，判定在配送公司服务器500中，是否存在注册用户的有效的个别id(s104)。

当在s104中进行了肯定的判断(是)时，注册用户信息获取部112从配送公司服务器500，获取注册用户的个别id(s105)。另一方面，当在s104中进行了否定的判断(否)时，注册用户信息获取部112对配送公司服务器500发送注册用户的用户信息，通知为新注册注册用户(s106)。接着，注册用户信息获取部112获取由配送公司服务器500赋予的注册用户的个别id(s107)。

再者，s104～s107的处理是针对注册用户已作为利用对象而选择的配送公司的每个配送公司服务器500而执行。

在s105之后或s107之后，用户信息注册部113使s105中所获取的个别id及s107中所获取的个别id，与注册用户的共同id相对应而注册于用户信息表(s108)。其次，注册用户信息获取部112在用户信息表中，判定是否存在注册了与注册用户的住址相同的住址的其他用户(s109)。

当在s109中进行了肯定的判断(是)时，注册用户信息获取部112获取其他用户的共同id(s110)。其次，用户信息注册部113将在s110中所获取的共同id，作为注册用户的同居用户的共同id，而注册于用户信息表(s111)。

在s111之后，或在s109中进行了否定的判断(否)时，注册用户信息获取部112访问注册用户已作为利用对象而选择的配送公司的配送公司服务器500。接着，在配送公司服务器500中，判定已允许向配送系统1公开信息的用户之中，是否存在注册了与注册用户的住址相同的住址的其他用户(s112)。

当在s112中进行了否定的判断(否)时，本处理流程结束。

另一方面，当在s112中进行了肯定的判断(是)时，注册用户信息获取部112从配送公司服务器500，获取其他用户的信息(s113)。在这里所获取的其他用户的信息是作为注册用户的同居用户的信息而处理。其次，用户信息注册部113为了针对所述其他用户注册于配送系统1，将在s113中所获取的用户的信息注册于用户信息表(s114)。这时，用户信息注册部113对其他用户新分配共同id(s115)。并且，用户信息注册部113将s115中所分配的共同id，作为注册用户的同居用户的共同id，而注册于用户信息表(s116)。接着，本处理流程结束。

再者，s112～s116的处理是针对注册用户已作为利用对象而选择的配送公司的每个配送公司服务器500而执行。

＜配送任务制作的处理顺序＞

其次，对配送任务管理服务器200制作配送任务的处理的顺序进行说明。图7及图8是表示配送任务制作的处理顺序的一例的流程图。

首先，配送委托信息获取部211访问各配送公司的配送公司服务器500，获取用户委托给配送公司的货物的配送委托的信息(s201)。在这里，配送委托信息获取部211获取发往已允许向配送系统1公开信息的用户的货物的配送委托的信息。其次，配送任务制作部213参照所获取的配送委托的信息，选择已委托配送的所有货物之中的一个货物(s202)。

其次，配送任务制作部213提取处于如下的期间内的货物，所述期间是作为用于对已委托配送的所有货物之中在s202中所选择的货物进行汇总的期间而预先规定的期间(s203)。在这里，所谓用于对货物进行汇总的期间，是指用于是否对多个货物的配送进行汇总的判断的期间，例如，是在s202中所选择的货物滞留于配送中心的上限的期间。在这种情况下，以在s202中所选择的货物到达配送中心的预定时刻为基准，提取从所述基准的时刻在预先规定的期间内到达配送中心的预定的货物。

其次，配送任务制作部213针对在s202中所选择的货物，判定是否将货物的配送目的地即地点作为关键而汇总(s204)。

在s204的判定中，例如，在明确指定为配送至配送目的地的用户的住址的情况、配送目的地的用户的住址已注册于用户信息表而没有配送至除此以外的地点的指示的情况下，进行肯定的判断(是)。另一方面，例如，在配送目的地的用户的住址未固定的情况、配送目的地的用户的住址已注册于用户信息表却指定了不配送至所述住址的情况下，进行否定的判断(否)。在这种情况下，使用将货物的配送目的地即人作为关键而汇总的方法。

当在s204中进行了肯定的判断(是)时，配送任务制作部213判定s203中所提取的货物之中，是否存在发往与s202中所选择的货物相同的用户，而配送目的地的住址相同的货物(s205)。

当在s205中进行了否定的判断(否)时，配送任务制作部213制作只包含s202中所选择的货物的配送任务(s206)。

另一方面，当在s205中进行了肯定的判断(是)时，配送任务制作部213将发往同一用户而配送目的地的住址相同的多个货物加以汇总(s207)。

在s206之后或s207之后，配送任务制作部213参照用户信息表，确定在s202中所选择的货物的配送目的地即用户的同居用户(s208)。其次，配送任务制作部213判定s203中所提取的货物之中，是否存在发往s208中所确定的同居用户的货物(s209)。当在s209中进行了否定的判断(否)时，配送任务制作部213针对在s207中经汇总的货物，制作一个配送任务(s210)。

另一方面，当在s209中进行了肯定的判断(是)时，配送任务制作部213针对在s207中经汇总的多个货物及发往在s208中经确认的同居用户的货物，全部判定是否允许与发往其他人的货物一起配送(s211)。当针对所有货物，允许与发往其他人的货物一起配送时(s211中为是)，配送任务制作部213将所有货物加以汇总而制作一个配送任务(s212)。另一方面，当针对至少一个货物，不允许与发往其他人的货物一起配送时(s211中为否)，配送任务制作部213以将不允许与发往其他人的货物一起配送的货物不与发往其他人的货物一起配送的方式，制作配送任务(s213)。

在s213中，例如，只将允许与发往其他人的货物一起配送的货物加以汇总而制作一个配送任务。另一方面，关于不允许与发往其他人的货物一起配送的货物，针对每个配送目的地的用户制作配送任务。或者，例如，也可以针对所有货物，针对每个配送目的地的用户制作配送任务。

另外，当在s204中进行了否定的判断(否)时，进行将作为货物的配送目的地的人作为关键而汇总的处理。在这种情况下，配送任务制作部213判定s203中所提取的货物之中，是否存在发往与s202中所选择的货物相同的用户的货物(s214)。当在s214中进行了肯定的判断(是)时，配送任务制作部213将发往同一用户的多个货物加以汇总而制作一个配送任务(s215)。另一方面，当在s214中进行了否定的判断时，配送任务制作部213制作只包含s202中所选择的货物的配送任务(s216)。在s215或s216之后，配送任务制作部213通过邮件等而通知配送目的地的用户，从用户受理配送目的地的地点，作为配送任务的信息而追加(s217)。

在s210、s212、s213或s217之后，配送任务制作部213判定已通过s201中所获取的配送委托的信息而委托配送的所有货物之中，是否存在尚未进行配送任务的制作的货物(s218)。当在s218中进行了肯定的判定(是)时，转移至s202。另一方面，当在s218中进行了否定的判断(否)时，本处理流程结束。

＜共同用户管理服务器的处理的说明＞

其次，举出具体例，对共同用户管理服务器100的处理进行说明。

例如，当用户a从委托人终端600访问共同用户管理服务器100时，使用户注册画面显示于委托人终端600的显示器。当用户a在所述用户注册画面中，输入自身的姓名、住址、电话号码等用户信息时，进行用户注册。并且，在用户注册画面中，用户a也进行作为利用对象的配送公司的选择。在这里，用户a也可以在用户注册画面中，输入由曾经利用过的配送公司赋予的自身的个别id。

在所述示例中，用户a选择管理配送公司服务器500a的配送公司a、管理配送公司服务器500b的配送公司b、管理配送公司服务器500c的配送公司c三个。并且，用户a曾经利用过配送公司a的服务，作为当时所赋予的个别id，输入个别id“333”。

当进行用户a的注册后，用户信息注册部113对用户a分配共同id。接着，用户信息注册部113使输入至用户注册画面的用户a的信息与共同id相对应，而注册于用户信息表。

图9(a)是表示用户信息表中所注册的用户a的信息的一例的图。在图示的示例中，共同id是“c-8797”，用户a的姓名是“山田太郎”，电话号码是“xx-xxxx-xxxx”，住址是“xx县yy市zz1-1”。

另外，指定“一天”，作为将货物加以汇总的期间。例如，为了将货物加以汇总，而将用户a的货物滞留于配送中心的上限的期间设为一天。换言之，关于一个货物及其他货物，只要一个货物到达配送中心的预定时刻与其他货物到达配送中心的预定时刻在一天以内，就作为汇总的对象而处理。但是，作为将货物加以汇总的期间，并不限于货物滞留于配送中心的上限的期间。例如，也可以是将进行了货物的配送委托的时刻作为基准的期间。在这种情况下，例如，关于一个货物及其他货物，只要委托了一个货物的配送的时刻与委托了其他货物的配送的时刻是在一天以内，就作为汇总的对象而处理。

此外，可以/不可以同居用户配送是如下的设定：是否允许将发往用户a的货物，与发往与用户a同居的同居用户的货物加以汇总配送。在“可以”的情况下，允许将发往用户a的货物与发往同居用户的货物加以汇总配送。另一方面，在“不可以”的情况下，不允许将发往用户a的货物与发往同居用户的货物加以汇总配送，而分配至各别的配送任务。

另外，关于可以/不可以同居用户配送的设定，也可以根据货物的种类或货物的性质，进行“可以”或“不可以”的设定。例如，关于酒类或酒精饮料，未成年人的饮酒是被禁止的，而例如，如果与孩子用的货物进行汇总配送，则孩子有可能接收酒类或酒精饮料的货物。因此，针对酒类或酒精饮料，进行“不可以”的设定。并且，例如，关于昂贵物品，以所述货物的地址的用户直接接收为宜，因此进行“不可以”的设定。

此外，也可以指定允许将货物加以汇总配送的同居用户。例如，关于酒类或酒精饮料，进行如下的设定：只要是发往成人的同居用户的货物，就可以进行汇总配送。并且，例如，关于昂贵物品，进行如下的设定：只要是发往能够信赖的同居用户的货物，就可以进行汇总配送。

再者，如后所述，也可以针对每个配送的货物，进行可以/不可以同居用户配送的设定。

另外，可以/不可以同居用户配送的设定也可以作为如下的设定来处理：即使是发往与配送目的地的用户相同的住址的货物，是否也允许向各个人分别进行配送。在这种情况下，在“可以”的情况下，允许向各个人分别进行配送，例如，将发往用户a的货物与发往同居用户的货物分配至各别的配送任务。另一方面，在“不可以”的情况下，不允许向各个人分别进行配送，例如，将发往用户a的货物与发往同居用户的货物加以汇总而制作配送任务。

此外，在用户信息表中，注册由配送公司服务器500赋予至用户a的个别id或用户a的同居用户的信息。

更具体地说，当进行用户a的注册时，注册用户信息获取部112访问用户a已作为利用对象而选择的各配送公司的配送公司服务器500a～配送公司服务器500c，获取由配送公司服务器500a～配送公司服务器500c管理的用户a的个别id。

例如，注册用户信息获取部112访问配送公司服务器500a，基于输入至用户a的个别id“333”进行用户a的查询，判定个别id“333”是否有效。图9(b)是表示由配送公司服务器500a管理的用户a的信息的一例的图。注册用户信息获取部112例如，对输入至用户注册画面的用户a的姓名、住址、电话号码，与作为个别id“333”而注册的用户的姓名、住址、电话号码进行比较。并且，当两者全部一致时，判定为用户a与个别id“333”的用户相同，个别id“333”为用户a的有效的个别id。

另外，例如，注册用户信息获取部112访问配送公司服务器500b，基于用户a的姓名、住址、电话号码的信息进行用户a的查询，获取由配送公司服务器500b管理的用户a的个别id。图9(c)是表示由配送公司服务器500b管理的用户a的信息的一例的图。在这里，个别id“x-222”的用户的姓名、住址、电话号码与输入至用户注册画面的用户a的姓名、住址、电话号码相一致。因此，注册用户信息获取部112作为用户a的有效的个别id，获取“x-222”。

此外，例如，注册用户信息获取部112访问配送公司服务器500c，基于用户a的姓名、住址、电话号码等信息进行用户a的查询，获取由配送公司服务器500c管理的用户a的个别id。在所述示例中，在配送公司服务器500c中，用户a尚未注册。因此，注册用户信息获取部112对配送公司服务器500c通知新注册用户a。这时，还结合在用户注册画面中所输入的用户a的信息，通知给配送公司服务器500c。图9(d)是表示配送公司服务器500c中所注册的用户a的信息的一例的图。如图9(d)所示，在配送公司服务器500c中，注册输入至用户注册画面的用户a的姓名、住址、电话号码。并且，在配送公司服务器500c中，作为用户a的个别id而新赋予“a3849”。并且，注册用户信息获取部112获取“a3849”作为用户a的有效的个别id。

另外，注册用户信息获取部112在用户信息表中，获取注册了与用户a的住址相同的住址的其他用户的信息。在所述示例中，作为注册了与用户a的住址相同的住址的用户，存在用户b。图10(a)是表示用户信息表中所注册的用户b的信息的一例的图。在图示的示例中，共同id“c-6547”的用户b的住址与用户a的住址相同。因此，用户b的共同id“c-6547”是作为用户a的同居用户的共同id而注册。并且，用户a的共同id“c-8797”是作为用户b的同居用户的共同id而注册。

然后，注册用户信息获取部112访问用户a已作为利用对象而选择的各配送公司的配送公司服务器500a～配送公司服务器500c，获取已允许向配送系统1公开信息的用户之中、注册了与用户a的住址相同的住址的其他用户的信息。在所述示例中，在配送公司服务器500b中，作为注册了与用户a的住址相同的住址的用户，存在用户c。图10(b)是表示由配送公司服务器500b管理的用户c的信息的一例的图。在图示的示例中，个别id“x-333”的用户c的住址与用户a的住址相同。因此，用户c作为用户a的同居用户而处理。

在这里，用户c也注册于配送系统1。图10(c)是表示注册于用户管理表的用户c的信息的一例的图。如所述图10(c)所示，将由配送公司服务器500b管理的用户c的信息注册于用户信息表中。这时，对用户c新赋予共同id“c-9987”。并且，用户c的共同id“c-9987”是作为用户a的同居用户的共同id而注册。此外，还作为用户b的同居用户的共同id而注册。另一方面，用户a的共同id“c-8797”是作为用户c的同居用户的共同id而注册。并且，用户b的共同id“c-6547”也作为用户c的同居用户的共同id而注册。

再者，也可以通过手动而注册用户a的同居用户的信息。例如，当用户a在用户注册画面中，输入自身的信息及同居用户的信息时，对同居用户赋予共同id而将同居用户的信息注册于用户信息表。并且，例如，当用户a在自身的用户注册时，也可以输入已注册的同居用户的共同id。在这种情况下，只要基于共同id而确定的用户的住址与用户a的住址相同，则判定为有效的共同id，作为用户a的同居用户的共同id而注册。

＜配送任务管理服务器的处理的说明＞

其次，举出具体例，对配送任务管理服务器200的处理进行说明。

首先，配送委托信息获取部211定期地(例如，每个小时)访问各配送公司的配送公司服务器500，获取用户委托给各配送公司的货物的配送委托的信息。在这里，获取发往已允许向配送系统1公开信息的用户的货物的配送委托的信息。图11(a)～图11(c)是表示用户委托给配送公司的货物的配送委托的信息的一例的图。

在这里，图11(a)、图11(b)表示用户委托给配送公司b的配送委托的信息。图11(c)表示用户委托给配送公司c的配送委托的信息。分配至各配送委托的配送id是配送公司单独赋予的id。

再者，在图11(a)～图11(c)所示的示例中虽未指定，但是也可以在配送委托中，指定货物的接收人。当指定了接收人时，对所指定的接收人进行货物的交接。当所指定的接收人不在时，进行再次配送。并且，当关于经汇总配送的多个货物，针对每个货物指定了接收人时，对与货物相对应的接收人进行货物的交接。

配送任务制作部213基于配送委托信息获取部211所获取的图11(a)～图11(c)的货物配送的信息及用户信息获取部212所获取的用户的信息，针对每个货物的配送制作配送任务。

更具体地说，在图11(a)所示的货物1(配送id：2222)中，配送目的地的用户的个别id是“x-222”，通过搜索用户信息表，而确认显示了共同id“c-8797”的用户a(参照图9(a))。同样地，在图11(b)所示的货物2(配送id：2223)中，配送目的地的用户的个别id是“x-333”，通过搜索用户信息表，而确认显示了共同id“c-9987”的用户c(参照图10(c))。并且，在图11(c)所示的货物3(配送id：123)中，配送目的地的用户的个别id是“a3849”，通过搜索用户信息表，而确认显示了共同id“c-8797”的用户a(参照图9(a))。

即，货物1的配送目的地，货物3的配送目的地是用户a的住址，货物2的配送目的地是用户a的同居人即用户c的住址，是完全相同的地点。因此，配送任务制作部213将货物的配送目的地即地点作为关键，而对所述三个货物进行汇总而制作一个配送任务。图12是表示配送任务制作部213所制作的配送任务的一例的图。如所述图12所示，在配送任务中，注册对配送任务进行汇总时所使用的关键的信息(在图示的示例为地点)、配送目的地的用户的共同id、配送目的地的住址、配送目的地的电话号码、任务状态、希望配送日期和时间的信息。

如果作进一步说明，则是在所述示例中，针对货物1～货物3，将对货物进行汇总的期间设定为“一天”(参照图11(a)～图11(c))。而且，关于三个货物，配送中心到达预定时刻处于一天以内，因此汇总为一个配送任务。

另外，在所述示例中，针对三个货物分别进行了“可以/不可以同居用户配送”的设定，针对三个货物均设定了“可以”。因此，三个货物是汇总为一个配送任务。在这里，例如，当货物1的设定为“不可以”时，不将货物1与货物2加以汇总。在这种情况下，例如，只对货物1制作一个配送任务，将货物2与货物3汇总为一个配送任务。或者，也可以将发往相同用户a的货物即货物1及货物3汇总为一个配送任务，只对货物2制作一个配送任务。

再者，当针对货物尚未进行“可以/不可以同居用户配送”的设定时，可参照用户信息表中所注册的每个用户的“可以/不可以同居用户配送”的设定。换言之，关于“可以/不可以同居用户配送”的设定，每个货物的设定优先于每个用户的设定。

另外，在所述示例中，设定货物1的“2018年5月4日18点”，作为配送任务的希望配送日期和时间。但是，当将多个货物汇总为一个配送任务时，在针对多个货物指定了希望配送日期和时间的情况下，将最早的希望配送日期和时间设定为所述配送任务的希望配送日期和时间。

＜配送日程管理服务器的处理的说明＞

其次，举出具体例，对配送日程管理服务器300的处理进行说明。

配送任务获取部311获取通过配送任务管理服务器而制作的配送任务的信息。然后，日程制作部312针对配送任务获取部311所获取的每个配送任务，制作用于配送员配送的配送日程。在所述示例中，日程制作部312制作图12所示的配送任务的配送日程。

图13是表示日程制作部312所制作的配送日程的一例的图。在配送日程中，包含配送任务中所含的货物的信息、货物到达的配送中心的信息、及集配路线的信息。在图示的示例中，作为配送中心的住址，包含管理货物1及货物2的配送公司b的配送中心b的住址、管理货物3的配送公司c的配送中心c的住址。这些配送中心的住址是从各配送公司的配送公司服务器500获取。并且，针对货物1～货物3，分别规定了到达配送中心的预定时刻。所述到达预定时刻是由各配送公司计算，从配送公司服务器500获取。并且，基于配送中心的住址、到达配送中心的到达预定时刻，对集配路线进行计划。

更具体地说，货物1到达配送中心b的预定时刻是2018年5月4日11点。并且，货物2到达配送中心b的预定时刻是2018年5月4日16点。此外，货物3到达配送中心c的预定时刻是2018年5月4日12点。在这里，货物1与货物2到达相同的配送中心b，货物2的到达预定时刻较晚。因此，以货物2到达之后(即，2018年5月4日16点以后)配送员抵达配送中心b的方式，确定集配路线。并且，货物3到达配送中心c的预定时刻是2018年5月4日12点，因此以配送员在去配送中心b之前先去配送中心c，货物3到达之后(即，2018年5月4日12点以降)抵达配送中心c的方式，确定集配路线。

此外，也考虑到由用户指定的希望配送日期和时间。在图示的示例中，针对货物1将希望配送日期和时间指定为2018年5月4日18点。因此，基于集配路线、各配送中心的住址、配送目的地的住址等，进行是否能够在2018年5月4日18点之前配送的确认。在这里，当判断为货物1的配送在希望配送日期和时间之前来不及时，制作用于货物1的其它配送任务。

日程通知部313将以如上所述而制作的配送任务的配送日程，通知给配送员终端400。在这里，当存在多个配送员时，日程通知部313基于配送日程及配送员的当前所在地，按照配送日程选择能够配送的配送员，将配送日程通知给所选择的配送员的配送员终端400。并且，日程通知部313在配送员处于其它配送任务的作业中或者作业预定时，判定是否在所述作业完成后能够进行配送，或者是否能够在所述作业中插入而配送等，并通知配送日程。

再者，也可以不由日程通知部313选择配送员，而由配送系统1的管理员等选择配送员。并且，配送员自身也可以选择能够配送的配送任务。

另外，配送状况管理部314针对每个配送任务，更新配送任务的任务状态，或更新货物的货物状态。

在配送任务的任务状态中，有“新建”、“集配中”、“配送中”、“完成”、“等待中”。“新建”是制作配送任务，尚未分配至配送员的状态。“集配中”是配送员处于货物的集配作业中的状态。“配送中”是配送员完成货物的集配，去往配送目的地的状态。“完成”是货物的配送已完成的状态。“等待中”是货物的配送完成而经过了固定时间的状态。

另外，在货物的货物状态中，有“等待到达配送中心”，“已到达配送中心”、“集配完”、“完成”。“等待到达配送中心”是货物尚未到达配送中心的状态。“已到达配送中心”是货物已到达配送中心，但是尚未集配的状态。“集配完”是由配送员集配好货物的状态。“完成”是货物的配送已完成的状态。

另外，配送状况通知部315对货物1～货物3的配送目的地即用户a及用户c，通知货物状态、货物的当前位置的信息、货物的到达预定时刻等。然后，配送状况通知部315对配送公司服务器500b，指示不配送货物1及货物2。然后，配送状况通知部315对配送公司服务器500c，指示不配送货物3。并且，配送状况通知部315在货物1～货物3的配送完成后，对配送公司服务器500b，通知货物1及货物2的配送已完成。并且，对配送公司服务器500c，通知货物3的配送已完成。

再者，也可考虑到如下情况：配送员去了配送中心，但是在到达预定时刻之前货物未到达配送中心。在这种情况下，当在配送日程中，有去其它配送中心的预定计划时，将日程变更为去那边的配送中心。这时，配送员变更日程而将去其它配送中心的内容通知给配送日程管理服务器300。并且，当即使配送员再次返回到配送中心，货物还未到达配送中心时，取消所述货物的配送。这时，配送员将取消货物的配送的内容通知给配送日程管理服务器300。配送日程管理服务器300对管理取消配送的货物的配送公司服务器500、委托了所述货物的配送的用户的委托人终端600，通知取消货物的配送。当货物的配送被取消后，委托了配送的用户例如，只要关于是否日后配送，或是否撤销所述配送自身等，与配送公司进行协商即可。

另外，配送员在配送中心接收货物时，为了表示是可信赖的人，出示从配送公司服务器500事先发送的认证信息(例如密码等)。当认证通过时，进行从配送中心向配送员的货物的交接。

此外，也可以不是配送系统1的配送员配送由配送任务管理服务器200制作的所有配送任务，而是配送公司进行一部分配送任务的配送。在这种情况下，日程制作部312关于配送公司进行配送的货物的配送任务，不制作日程，而从配送任务保存部214加以删除。并且，日程制作部312将关于各配送任务，确定是由配送公司方进行配送，还是由配送系统1方进行配送的结果，通知给配送公司服务器500。

例如，日程制作部312在配送任务内的货物只有一个时，对管理所述货物的配送公司服务器500，询问是由配送公司方进行配送，还是由配送系统1方进行配送。在询问后，在固定时间内(例如，一个小时以内)从配送公司没有回答时，对配送公司服务器500通知委派配送。

另外，例如，日程制作部312在指定了货物的希望配送日期和时间时，在货物是加急配送的情况下，对配送公司服务器500通知委派配送。更具体地说，例如，在被用户指定为从借由配送任务管理服务器200而确认了配送的时刻(即，配送委托信息获取部211获取到配送委托的信息的时刻)起固定时间内(例如，一个小时以内)完成配送的情况下，对配送公司服务器500通知委派配送。

此外，例如，日程制作部312在管理货物的配送中心是配送系统1的对象区域外的情况下，对配送公司服务器500通知委派配送。

另外，在本实施方式中，配送任务管理服务器200的配送委托信息获取部211并不限于从配送公司服务器500获取配送委托的信息的结构。配送委托信息获取部211例如，在用户利用委托人终端600在互联网上的网站上购买了商品的情况下，也可以从构成购买了所述商品的网站的系统，直接获取配送委托的信息。在这种情况下，配送委托信息获取部211例如，定期地(例如，每个小时)访问网站的系统，探测用户已进行货物的配送委托，或从店铺发送了商品，而获取配送委托的信息。然后，配送任务制作部213基于所获取的配送委托的信息而制作配送任务。再者，在从网站的系统获取到配送委托的信息的时点，尚未确定由哪个配送公司管理货物的情况下，稍后，例如通过访问配送公司服务器500，而确定管理货物的配送公司。

然后，当用户利用委托人终端600而在互联网上购买多个商品时，也可以进行将多个商品加以汇总配送的指示。更具体地说，例如，用户通过委托人终端600，而在互联网上在多个店铺分别购买商品。然后，用户在委托人终端600，进行将所购买的多个商品加以汇总配送的指示。委托人终端600在受理到将多个商品加以汇总配送的指示时，将所受理的指示的信息发送至共同用户管理服务器100、配送任务管理服务器200、配送日程管理服务器300等。然后，配送任务管理服务器200的配送任务制作部213基于所发送的信息而制作配送任务。在这里，用户也可以指示用于将多个商品加以汇总配送的期间、例如，各个商品滞留于配送中心的上限的期间。

如上所述，通过从网站的系统直接获取配送委托的信息，例如，可与从配送公司服务器500获取配送委托的信息的结构相比，提前获取配送委托的信息。因此，例如，可提前进行配送任务的制作，而确保配送员。

另外，在本实施方式中，作为配送系统1的用户注册的处理，是设为共同用户管理服务器100的注册用户信息受理部111从委托人终端600受理用户信息，但是并不限于如上所述的结构。

例如，在配送公司服务器500中，也可以受理配送系统1的用户注册。在这种情况下，例如，在配送公司服务器500的用户注册画面中，受理是否利用配送系统1的选择。在这里，对已选择利用配送系统1的用户，进行是否允许向配送系统1公开信息的确认。然后，配送任务管理服务器200的用户信息获取部212定期地(例如，每个小时)访问各配送公司服务器500，判定已允许向配送系统1公开信息的用户之中，是否存在尚未注册于用户信息表的用户。当存在尚未注册的用户时，从配送公司服务器500获取所述用户的信息。接着，基于所获取的信息而进行用户注册。并且，将新注册的用户的住址与已注册完毕的用户的住址进行比较，也进行是否属于同居用户的判定。在属于同居用户的情况下，针对各个用户，注册同居用户的信息。

另外，即使是用户注册完的用户，也可考虑到从配送公司服务器500的用户注册画面，新追加配送公司作为利用对象的情况。因此，用户信息获取部212针对已允许向配送系统1公开信息的用户之中、即使是在用户信息表中已注册完也追加作为利用对象的配送公司的用户，从配送公司服务器500获取所述用户的个别id等信息。并且，将所获取的信息追加至用户信息表。

另外，在本实施方式中，并不限于配送员配送货物的结构。例如，自行式的配送装置也可以配送货物。在这种情况下，自行式配送装置是在被日程通知部313通知配送日程时，按照所通知的配送日程，去配送中心接收货物，而配送至配送目的地。并且，自行式配送装置与配送员终端400同样地，经由网络700，与共同用户管理服务器100、配送任务管理服务器200、配送日程管理服务器300、配送公司服务器500、委托人终端600等进行信息的交换。

此外，在本实施方式中，是将共同用户管理服务器100、配送任务管理服务器200、配送日程管理服务器300分别作为其他装置而设置有三台服务器装置，但是也可以通过一台服务器装置或两台服务器装置来实现这些功能。附带说一句，也可以使用实现共同用户管理服务器100的功能、配送任务管理服务器200的功能、配送日程管理服务器300的功能之中的全部功能的程序，或使用实现一部分功能的程序。

另外，在本实施方式中，与共同用户管理服务器100的功能、配送任务管理服务器200的功能、配送日程管理服务器300的功能同样地，关于配送员终端400的功能或委托人终端600的功能，例如，也可通过将存储于hdd等的各种程序读入至ram并由cpu执行来实现。

另外，实现本发明的实施方式的程序当然是通过通信构件而提供，也可以保存于只读光盘(compactdisk-readonlymemory，cd-rom)等记录媒体中而提供。

再者，以上已说明各种实施方式及变形例，但是当然也可以将这些实施方式或变形例彼此加以组合而构成。

另外，本公开丝毫不限定于所述实施方式，可以在不脱离本公开的主旨的范围内通过各种方式而实施。