改善投递效率的智能投递系统、手持机及用户终端的制作方法

本公开涉及物流领域，更具体地，涉及能够改善投递效率的智能投递系统、手持机及用户终端。

背景技术：

快递员投递包裹时很容易发生如下这种情况：到达客户指定的收货地址，而客户却由于种种原因而不能及时签收货物。此时，快递员要么放弃本次投递任务，要么电话联系客户，以决定是继续等待还是放弃。上述这种情况的频繁发生，无论采用哪种处理方式都会严重降低投递效率，增加投递员的工作强度。

通常，快递员可以提前电话联系客户，确认是否可以接收包裹。但是，由于客户数量众多，快递员要拨打多个电话。于是，快递员要么需要停在一个地方打电话，但这极大地浪费了时间；要么需要在路上打电话，但这导致了安全隐患。

或者，可以通过短信或手机应用(app)通知客户。但是，短信或app通知很容易被客户忽略。而且，即使客户看到通知，客户往往也不愿意主动联系快递员，而等待快递员主动联系。

技术实现要素：

本公开的目的至少部分地在于提供能够改善投递效率的智能投递系统、手持机及用户终端。

根据本公开的一个方面，提供了一种智能投递系统，包括彼此通信连接的服务端和客户端。服务端被配置为根据订单数据确定每区域的投递信息，并将所确定的投递信息发送至客户端。客户端被配置为基于从服务端接收到的每区域的投递信息，确定投递路线规划，并将所确定的投递路线规划发送至服务端。服务端进一步被配置为根据从客户端接收 到的投递路线规划，向至少一个后继投递区域中的投递人发送投递通知，接收来自于至少一个投递人的确认，并将接收到的确认结果发送至客户端。

根据本公开的另一方面，提供了一种手持机，包括：通信单元，配置为与服务器进行通信，以从服务器接收每区域的投递信息；显示单元，配置为向用户呈现接收到的投递信息；以及输入单元，配置为接收用户的投递路线规划，其中通信单元被配置为将投递路线规划发送至服务器。

根据本公开的再一方面，提供了一种用户终端，包括：通信单元，配置为与服务器进行通信，以从服务器接收投递通知；显示单元，配置为向用户呈现投递通知；以及输入单元，配置为接收用户对是否能够收货的确认，其中通信单元被配置为将该确认发送至服务器。

根据本公开的实施例，不是由投递员(通过其手持机或客户端)来直接与用户进行确认，而是由服务端自动与用户确认是否可收货。此外，服务端可以根据(投递员的)投递路线规划，适当地确定与用户进行确认的时机。投递员可以根据确认结果，安排投递。这样，可以提高投递效率，而不会增加投递员的工作量。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示出了根据本公开实施例的智能投递系统；

图2示出了根据本公开实施例的智能投递系统的操作流程；

图3示出了根据本公开实施例的手持机的框图；

图4示出了根据本公开实施例的用户终端的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公 开。这里使用的词语“一”、“一个(种)”和“该”等也应包括“多个”、“多种”的意思，除非上下文另外明确指出。此外，在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。

因此，本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。在本公开的上下文中，计算机可读介质可以是能够包含、存储、传送、传播或传输指令的任意介质。例如，计算机可读介质可以包括但不限于电、磁、光、电磁、红外或半导体系统、装置、器件或传播介质。计算机可读介质的具体示例包括：磁存储装置，如磁带或硬盘(hdd)；光存储装置，如光盘(cd-rom)；存储器，如随机存取存储器(ram)或闪存；和/或有线/无线通信链路。

图1示出了根据本公开实施例的智能投递系统。

如图1所示，根据该实施例的智能投递系统可以包括彼此通信连接的客户端101和服务端103。

客户端101例如可以是投递员(例如，快递公司的工作人员)1001所携带的智能手持机。此外，手持机可以集成有电话功能。或者，手持机可以是智能手机，其中安装有投递业务管理应用(app)。手持机可以具有输入单元和显示单元等。投递员可以通过输入单元(例如，按键)输入各种信息，例如需要拨打的投递人1007的电话号码、对投递完成的 确认、对投递路线的规划等。显示单元(例如，lcd显示屏)可以向投递员显示各种信息，例如，需要投递的地址和投递人信息、投递人对能否收货的确认等。根据一个实施例，输入单元和显示单元可以集成在一起，例如触摸屏。

服务器103例如可以是服务器，例如，快递公司用于管理投递业务的服务器或云上的云服务器。服务器103可以包括各种计算平台，例如个人计算机(pc)、工作站等。

在图1的示例中，示出了客户端101和服务端103通过网络100彼此通信连接的示例。网络100可以包括各种有线(例如，电话网络、互internet等)和/或无线网络(例如，wifi网络、3g无线通信网络、4g无线通信网络等)，并且可以包括多种不同网络的组合(例如，在某一区域具有一种网络，在另一区域具有另一种网络，各网络之间通过各种连接方式如交换机、网关等彼此连通)。客户端101和服务端103可以通过各种形式的有线和/或无线连接而接入网络100。

此外，图1中还示出了外呼系统105。外呼系统105用于管理呼叫，例如与投递人1007的电话呼叫。在图1中，另外示出了外呼系统105与投递人1007的终端设备107(例如，智能手机)之间的电话网络200。这里需要指出的是，尽管图1中以老式电话的形式来示意网络200为电话网络，但是电话网络200可以是有线电话网络或者无线移动通信网络等。此外，尽管分别示出，但是电话网络200可以是网络100的一部分。

外呼系统105可以与服务端103通信连接。在图1所示的示例中，将外呼系统105示出为连接到网络100并因此与服务端103通信连接。外呼系统105可以通过各种有线和/或无线形式连接到网络100。根据实施例，服务端103和外呼系统105可以集成在一起。

根据实施例，外呼系统105可以是自动通话系统，例如互动式语音应答(ivr)系统。当然，外呼系统105也可以包括使用话务员的人工通话系统。

图2示出了根据本公开实施例的智能投递系统的操作流程。以下，将结合图1和图2，更具体地描述智能投递系统的操作。

参照图2，在操作2001，服务端103可以根据订单数据确定每区域 的投递信息。例如，服务端103可以从业务系统获取订单数据。业务系统是用于对产生投递需求的业务进行管理的系统。例如，业务系统可以是电商企业的订单(每一订单可能需要相应的投递服务，从而对应于一个投递需求)管理系统。当用户在电商企业的网页上确定购买某一或某些商品并支付相关款项(或者在支持后付款的情况下，先不支付货款)之后，可以生成订单，该订单具有相应的订单数据，包括订单信息(例如，购买的商品名称、数量等)、订单的投递地址(例如，用户的收件地址)、投递人信息(用户的真实姓名、联系电话等)等。业务系统可以对这些订单及相应的订单数据进行管理。例如，业务系统可以将这些信息转发到相关部门，以便进行出货、投递，从而将用户订购的商品送到用户手中。业务系统可以包括各种计算平台，例如个人计算机(pc)、工作站等。业务系统可以通信连接到服务端103，从而服务端103可以从业务系统获取订单数据。例如，业务系统可以连接到网络100并因此与服务端103通信连接。业务系统可以通过各种有线和/或无线形式连接到网络100。根据实施例，服务端103和业务系统可以集成在一起。

在此，“区域”可以是指地理区域。可以根据城市布局和/或地理位置，来确定区域。例如，可以将彼此之间距离小于一定阈值的地点视为处于同一区域，或者可以将处于同一街区、同一小区、同一建筑、同一单元或同一楼层等的地点视为处于同一区域。或者，可以通过简单地对地图进行区块划分，并将划分的各区块视为相应区域。可以按多种方式来划分区域，这并不影响本技术的实施。区域的划分可以由服务端103按照一定的算法自动进行，或者由管理员预先指定。此外，还可以更新区域的划分，例如在地图发生变化时。

服务端103可以根据接收到的订单数据，特别是投递地址，来确定各投递地址所属的相应区域，并因此确定各区域需要投递的数量(可以按需要投递的地址数来计算，或者可以按需要投递的包裹数来计算)，即计划投递数量。服务端103可以将各区域的计划投递数量确定为相应区域的投递信息。此外，投递信息还可以包括与相应区域相关联的投递人信息(例如，投递人姓名和电话)、投递地址、相关订单信息等中的一项或多项。下表1示出了投递信息的一个示例形式。

表1投递信息

在此需要指出的是，一个投递人不限于一个订单，而是可能有多个订单。例如，在表1的示例中，投递人a2-u1具有相应的两个订单yyyyyy01和yyyyyy02。一个订单可以对应于一个包裹或多个包裹，或者同一投递人的若干个订单可以对应于一个包裹。因此，投递信息还可以包括相应的包裹信息。

还需要指出的是，尽管在表1中以表格形式示出了投递信息，但是本公开不限于此。可以各种合适的数据结构来生成和管理投递信息。

然后，在操作2003，服务端103可以将所确定的投递信息发送至客户端101。投递员1001可以通过查看客户端101，获知投递信息。客户端101可以根据接收到的投递信息，确定投递路线规划。投递路线规划的确定可以根据预定策略来进行。例如，客户端101可以根据需要投递的各区域在地图上的位置(以及客户端101所在的位置，为此，客户端 101可以包括定位装置如gps定位装置)，利用自动路径搜索技术，来确定投递路线规划，例如，各区域的投递顺序。路径搜索的策略例如可以是由近及远进行投递。通常，投递员负责同一片地区，投递员可以针对其负责的地区预先设定各区域的划分以及各区域的先后顺序。之后，客户端101可以遵循这种预先设定来确定投递路线规划。当然，可以由投递员1001来向客户端101手动输入投递路线规划。例如，客户端101可以在显示单元例如触摸屏上显示投递员1001所负责地区的地图，并在地图上显示各区域的位置以及相应区域需要投递的数量。投递员1001可以通过触摸屏依次划过各区域，由此输入投递路线规划。

根据实施例，投递路线规划除了各区域的投递顺序之外，还可以包括各区域之间的估计投递间隔时间。例如，对于投递路线上的两个相邻区域，它们之间的估计投递间隔时间可以包括前一区域的估计投递时间以及投递员从该区域到下一区域所需的时间。一区域的估计投递时间可以根据该区域所需的投递数量以及针对该区域所统计的每一投递所需的平均时间(可以根据累积的以前的投递统计数据来确定)来估计。从一区域到下一区域所需的时间可以根据投递员的平均速度(可以利用gps数据来确定)以及两区域之间的距离来估计。当然，可以由投递员1001(根据自己的经验)来向客户端101手动输入估计投递间隔时间。

根据本公开的另一实施例，客户端101还可以指定向投递人发送投递通知的形式。例如，发送投递通知的形式可以包括以下至少之一：通过app进行通知；通过电话进行通知；当投递人app不在线时，通过电话进行通知；以及先通过app进行通知，再通过电话进行通知，等等。可以由投递员1001通过输入装置来向客户端101进行这种指定。

在此，app可以是快递公司自身的快递业务app，或者也可以是电商企业的购物app。当然，可以通过这两种app之一或者两者进行通知。例如，可以在投递人1007的终端设备107如智能手机上运行的app(例如，快递查询app，或网上购物app如京东商城)上显示诸如“您的订单xxxxxx01预计将于xx小时yy分钟后送达，请确认能否接收”之类的消息。

根据本公开的另一实施例，客户端101还可以指定向投递人发送投 递通知的策略。例如，发送投递通知的策略可以包括以下至少之一：提前指定时间发送投递通知(例如，在预计到达某一区域的时刻之前的指定时间发送投递通知)；自动通知下一区域(例如，在到达一区域之后即自动通知该区域的下一区域)；手动启动通知(例如，由投递员手动启动通知的发送)；以及禁用通知，等等。可以由投递员1001通过输入装置来向客户端101进行这种指定。

随后，在操作2007，客户端101可以将所确定的投递路线规划以及可选地所指定的通知形式和通知策略发送至服务端103。

接着，在操作2009，服务端103可以根据从客户端接收到的投递路线规划，向至少一个后继投递区域中的投递人发送投递通知。这种投递通知可以根据客户端101处所指定的形式和策略来发送。在客户端101并没有指定通知形式和策略的情况下，服务端103可以根据缺省设置(例如，通过app提前预定时间通知)来发送投递通知。在此，所谓“后继”投递区域，是指按照投递路线规划，在投递员1001当前所在位置之后的区域。例如，当投递员刚从快递站出发时，“后继”投递区域可以是所有需要投递的区域；而当投递员到达某一区域之后，“后继”投递区域可以是投递路线上该投递区域之后的其他区域，例如，紧接在当前投递区域之后的投递区域。

在此，“2009”示出了由服务端103直接向投递人1007的终端设备107发送投递通知1。例如，如上所述，服务端103可以通过终端设备107上运行的快递查询app来向投递人1007呈现投递通知1。

在终端设备107上，响应于投递通知，可以显示用于由投递人1007确认能否收货的用户界面(ui)，以便投递人1007进行确认，如2011所示。例如，可以与该投递通知一起显示用于由投递人1007确认能否收货的按钮。投递人1007可以通过按动“确认”按钮来向服务端103确认能够收货。这样，就避免了投递人1007通过短信或电话方式与投递员1001进行确认，这是繁复的，而且投递员1001也可能记不住所有投递人1007的确认结果。于是，可以避免投递员与投递人之间由于确认而占用过多的通信资源。

当然，投递人1007的确认不限于简单的“是”与“否”，还可以包 括例如30分钟后能够收货、1小时后能够收货、晚上6点后可以收货这样的确认。相应地，app可以呈现相应的确认选项，或者用于输入确认信息的文本框等。

根据另一实施例，这种通知-确认还可以经由电商的业务系统进行。具体地，在操作2009′，服务端103可以向业务系统指示发送投递通知，业务系统根据服务端103的指示，向投递人1007发送投递通知2。发送投递通知2的形式和策略以及投递通知2的内容等可以与投递通知1相同，在此不再赘述。例如，业务系统可以通过终端设备107上运行的网络购物app来向投递人1007呈现投递通知2。同样地，在操作2011′，投递人1007可以通过终端设备107向业务系统确认是否能够收货，业务系统可以将确认结果反馈给服务端103。

根据另一实施例，这种通知-确认还可以经由外呼系统进行。具体地，在操作2009″，服务端103可以向外呼系统105指示——发送投递通知例如给某个电话号码，外呼系统105根据服务端103的指示，向投递人1007发送投递通知3。例如，服务端103可以向外呼系统105发送包括待呼叫投递人及其相关信息在内的呼叫列表，外呼系统105可以根据该呼叫列表逐一呼叫待呼叫投递人。发送投递通知3的形式和策略以及投递通知3的内容等可以与投递通知1相同，在此不再赘述。例如，外呼系统可以通过ivr系统依次拨打需要通知的投递人，以确认是否可以收货。投递人可以通过双音多频(dtmf)输入来在操作2011″向外呼系统105确认是否能够收货。外呼系统105可以将确认结果反馈给服务端103。当然，也可以通过人工接线员与投递人进行电话确认，并由其向系统输入确认结果。

在通知之前，服务端103可以根据订单数据，来获得需要通知的投递人的相关信息，例如其联系方式(app账户、电话号码等)、订单信息和预计到达时间(例如，根据从客户端101接收到的投递路线规划来确定)。这样，服务端103自身或者经由第三方(例如，上述业务系统或外呼系统)可以根据投递人的联系方式，向投递人发送通知，且通知可以包括相关订单信息、预计到达时间等中的一项或多项。

另外，如果在预定时间内未从投递人1007接收到任何确认，则可以 认为投递人1007不能收货。或者，如果在预定时间内未从投递人1007接收到任何确认，则可以再次发送投递通知，并等待投递人1007确认。当重复预定次数而未能从投递人1007接收到确认时，则可以认为投递人1007不能收货。

上述的这些通知-确认方式可以择一进行，或者可以组合进行，这可以取决于所指定的通知形式。

在接收到来自各投递人的确认之后，在操作2013，服务端103可以向客户端101发送确认结果。确认结果例如可以包括各区域的计划投递数量、确认能够在预计到达时间时收货的数量、确认不能在预计到达时间时收货的数量等中的一项或多项。下表2示出了确认结果的一个示例形式。表2中“√”表示能够在预计到达时间时收货，“×”表示不能在预计到达时间时收货。

表2确认结果

这里需要指出的是，由于表2中的一项或多项信息已经在之前的操作(例如，上述操作2003)中已经发送至客户端101，因此表2中可以省略某些信息。在一种最简单的实施方式中，确认结果可以只包括每区域不能在预计到达时间时收货的数量。

还需要指出的是，尽管在表2中以表格形式示出了确认结果，但是本公开不限于此。可以各种合适的数据结构来生成和管理确认结果。

客户端101在收到确认结果之后，可以通过显示单元向投递员1001呈现确认结果。于是，投递员1001可以根据确认结果，调整其行程。例如，在区域a1中，投递员可以不去地址a1-add4来向投递人a1-u4进行投递，以节省时间。

根据本公开的实施例，客户端101还可以基于从接收到的确认结果，更新投递路线规划，如2015所示。例如，如果某一区域中的所有投递人或超过预定比例的投递人不能在预计到达时间时收货，则可以确定不去该区域进行投递，即，从当前投递路线规划中去除该区域，或者将该区域重排到投递路线规划中较后的顺序。在这种情况下，还可以向该区域的投递人另外进行通知，例如通知当天不再投递(例如改为明天投递)或者通知更新的预计到达时间。根据实施例，投递路线规划的更新可以由投递员1001通过客户端101的输入单元来指定。

在更新投递路线规划之后，可以重复操作2007、2009(2009′、2009″)、2011(2011′、2011″)、2013。这样，可以即时更新投递信息。

图3示出了根据本公开实施例的手持机的框图。

如图3所示，根据该实施例的手持机300可以包括通信单元301、显示单元303和输入单元305。这种手持机300可以供投递员使用，并且例如可以实现为智能手机。

通信单元301可以与其他设备(例如，服务端103)进行通信连接。例如，在图1所示的示例中，通信单元301可以连接到网络100，并通过网络与其他设备连接。通信单元301可以包括各种有线通信接口(例如，lan网卡接口)和/或无线通信模块(例如，wifi通信模块、无线通信如3g或4g通信模块)。通信单元301不限于遵循单一通信协议， 而是可以遵循多种通信协议。例如，通信单元301可以与一种设备以一种通信协议通信，而与另一设备以另一通信协议通信。

显示单元303可以向手持机300的用户(例如，投递员1001)呈现各种信息，例如从服务端接收到的投递信息以及确认结果等。显示单元303可以通过各种显示技术如液晶显示器(lcd)、发光二极管(led)显示器、有机发光二极管(oled)显示器、电子纸显示器等来实现。

输入单元305可以接收手持机300的用户的各种输入，例如用户对投递路线规划的指定、对通知形式和/或通知策略的指定等。输入单元305可以实现为各种形式，例如键区、触摸输入装置、电磁感应输入装置、语音输入装置等。

根据一个实施例，输入单元305和显示单元303可以集成在一起，例如实现为触摸屏。

此外，手持机300还可以包括存储器307。存储器307可以存储手持机300的操作相关的信息(例如，各种数据和程序)。存储器307可以实现为各种易失性和/或非易失性存储技术，并可以包括存储装置如硬盘、存储卡等，存储器如静态随机存取存储器(sram)、动态随机存取存储器(dram)、闪存等。

另外，手持机300还可以包括控制器(未示出)，用于控制手持机300的整体操作。控制器可以实现为处理器或微处理器，例如移动处理器。

这里需要指出的是，在图3中，为了方便起见，并未示出各部件之间的连接。但是，各个部件之间可以相互连接。例如，它们可以连接到公共的总线，从而彼此互连。以下各框图中同样如此。

关于手持机300的详细操作，可以参见以上结合图1和2的说明，在此不再赘述。

图4示出了根据本公开实施例的用户终端的框图。

如图4所示，根据该实施例的用户终端400可以包括通信单元401、显示单元403和输入单元405。这种用户终端400例如是上述投递人1007使用的终端设备107，并且例如可以实现为智能手机。

通信单元401可以与其他设备(例如，服务端103、外呼系统105、 业务系统)进行通信连接。例如，在图1所示的示例中，通信单元401可以连接到网络100，并通过网络与其他设备连接。通信单元401可以包括各种有线通信接口(例如，lan网卡接口)和/或无线通信模块(例如，wifi通信模块、无线通信如3g或4g通信模块)。通信单元401不限于遵循单一通信协议，而是可以遵循多种通信协议。例如，通信单元401可以与一种设备以一种通信协议通信，而与另一设备以另一通信协议通信。

显示单元403可以向用户终端400的用户(例如，投递人1007)呈现各种信息，例如各种形式的投递通知。显示单元403可以通过各种显示技术如液晶显示器(lcd)、发光二极管(led)显示器、有机发光二极管(oled)显示器、电子纸显示器等来实现。

输入单元405可以接收用户终端400的用户的各种输入，例如用户对能够收货的确认等。输入单元405可以实现为各种形式，例如键区、触摸输入装置、电磁感应输入装置、语音输入装置等。

根据一个实施例，输入单元405和显示单元403可以集成在一起，例如实现为触摸屏。

此外，用户终端400还可以包括存储器407。存储器407可以存储用户终端400的操作相关的信息(例如，各种数据和程序)。存储器407可以实现为各种易失性和/或非易失性存储技术，并可以包括存储装置如硬盘、存储卡等，存储器如静态随机存取存储器(sram)、动态随机存取存储器(dram)、闪存等。

另外，用户终端400还可以包括控制器(未示出)，用于控制用户终端400的整体操作。控制器可以实现为处理器或微处理器，例如移动处理器。

关于用户终端400的详细操作，可以参见以上结合图1和2的说明，在此不再赘述。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等价物限定。不脱离本公开的范围， 本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。