地址信息处理方法及装置与流程

本申请涉及地址信息处理技术领域，特别是涉及地址信息处理方法及装置。

背景技术：

对于以生鲜、外卖类商品为主的网络销售平台，与传统销售平台的一个不同之处在于，这类平台主要是为了满足用户的即时性需求。例如，用户在需要用餐时，通过该平台点一份外卖，那么平台需要调动各种资源，以最快的速度送达用户指定的收货地址。因此，这类平台在为用户提供可选的商品信息时，与用户的收货地址具有密切的关联。例如，对于新用户而言，当用户打开应用程序(app)时，可以首先要求用户填写收货地址，然后app再根据收货地址，也即门店的配送范围，给出具体门店内可选的商品信息，再由门店为用户执行配送等等。对于老用户而言，由于之前已经通过app进行过下单操作，因此，可以保存用户的收货地址，再次打开app时，可以默认使用保存过的收货地址，并提供周边可选的商品信息。

但是，由于同一个用户在工作单位所在地与家庭所在地不同等原因，会导致同一用户可能曾经使用不同的收货地址进行下单，相应的，系统中也会针对同一用户保存多个收货地址信息。在这种情况下，当用户打开app后，系统通常会将最近使用的收货地址作为默认的收货地址，但是，经常会出现不准确的情况。例如，用户最近使用的收货地址是工作单位所在地，而当前打开app时，需要送货到自己家中，因此，继续为用户提供工作单位所在地附近的商品信息，并使用单位所在地的收货地址进行配送，就会出现错误。在这种情况下，通常需要用户手动对收货地址进行修改或者选择，这成为用户买到合适的商品并且能准确收货的必要条件。但是，如果每次用户使用app时，都需要用户去选择收货地址，是一件很麻烦的事情。

为解决上述问题，现有技术中，可以结合对用户的定位信息，对用户可能使用的收货地址进行选择。例如，系统中为同一用户保存了两个不同的收货地址，则在用户打开app后，可以首先对用户所在的地理位置进行定位，如果该地理位置与其中某个收货地址相匹配，就将该收货地址作为默认选择的收货地址。这种方式能够在一定程度上解决前述问题。但是，实际应用中，仍然存在一些情况，是这种方式无法解决的。例如，某用户在工作单位所在地打开app，但是，是想回到家中用餐，相应的，收货地址也需要设定为家庭地址对应的收货地址。也就是说，用户打开app执行点餐等操作时所在的位置，与实际需要的收货地址可能是不同的。在这种情况下，基于用户当前所在地理位置选择出的收货地址，就又会出现不符合用户要求的情况，用户仍然需要进行手动的修改或选择操作。

因此，如何更智能的为用户选择收货地址，成为需要本领域技术人员解决的技术问题。

技术实现要素：

本申请提供了地址信息处理方法及装置，有利于提高地址预测的准确性。

本申请提供了如下方案：

一种地址信息处理方法，包括：

在接收到操作请求时，确定所述请求关联的用户使用过的多个收货地址信息，以及分别在多种不同时间属性值下的权重；

确定当前时刻的时间属性值；

根据所述收货地址在该时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

一种地址信息处理方法，包括：

确定时间属性值；

获取多个收货地址在多种不同时间属性值下的被使用情况信息；

根据所述被使用的信息确定各收货地址在各种不同时间属性值下的权重，以用于在接收到操作请求时，根据所述请求关联用户的多个收货地址在当前请求时刻的时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

一种地址信息处理装置，包括：

收货地址信息确定单元，用于在接收到操作请求时，确定所述请求关联的用户使用过的多个收货地址信息，以及分别在多种不同时间属性值下的权重；

时间属性值确定单元，用于确定当前时刻的时间属性值；

目标收货地址确定单元，用于根据所述收货地址在该时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

一种地址信息处理装置，包括：

时间属性确定单元，用于确定时间属性值；

使用情况信息获取单元，用于获取多个收货地址在多种不同时间属性值下的被使用情况信息；

权重确定单元，用于根据所述被使用的信息确定各收货地址在各种不同时间属性值下的权重，以用于在接收到操作请求时，根据所述请求关联用户的多个收货地址在当前请求时刻的时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

在接收到操作请求时，确定所述请求关联的用户使用过的多个收货地址信息，以及分别在多种不同时间属性值下的权重；

确定当前时刻的时间属性值；

根据所述收货地址在该时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以从时间属性方面，对用户使用过的收货地址进行评价，确定出各收货地址分别在各种不同时间属性下的权重，这样，在用户打开app需要进行浏览、下单等操作时，就可以使用这种时间属性方面的权重信息，来预测出用户当前时刻可能会使用的收货地址。通过这种方式，有利于提高预测的准确性。

另外，还可以将时间属性上的权重与用户当前所在的地理位置信息相结合，实现更准确更智能的预测。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统架构的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3是本申请实施例提供的实际应用操作流程示意图；

图4是本申请实施例提供的第二方法的流程图；

图5是本申请实施例提供的第一装置的示意图；

图6是本申请实施例提供的第二装置的示意图；

图7是本申请实施例提供的计算机系统的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

本申请发明人在实现本申请的过程中发现，对于生鲜、外卖等类别的数据对象(通常可以指商品对象等)，用户在每次下单时使用的收货地址，除了与下单时所在的地理位置相关，通常还在下单时间上呈现出一些特征，而这种特征通常能够体现出用户对这类数据对象的消费习惯。例如，某用户的特征是，在工作日的早餐及午餐时间段，使用的收货地址通常是其工作单位所在的地址，假设为地址a；在工作日的晚餐时间段，使用的收货地址通常是其家庭所在的地址，假设为地址b；而在节假日中，早中晚三餐的收货地址可能都会是家庭所在的地址b，等等。但是，对于工作日的早餐时段，虽然收货地址是地址a，但是其打开app进行点餐时所在的地址，却可能是在家中，或者是在去单位上班的路上；或者，工作日的晚餐时段，虽然收货地址是地址b，但是点餐时所在的地理位置却可能是在单位，或者在从单位回到家中的路上，等等。因此，并不能简单的将用户打开app进行点餐操作时所在的地理位置，与用户所需的收货地址之间划上等号，还可以通过在时间上体现出的消费习惯，为用户进行更智能的收货地址的预测，以降低用户手动修改收货地址的次数。

基于上述分析，在本申请实施例中，可以通过对同一用户在不同时间段对收货地址的使用情况进行记录并统计，通过统计结果来反映出用户在各个时间段的消费习惯，进而，基于这种时间上的消费习惯，为用户进行收货地址的预测。也就是说，为各个使用过的收货地址赋予时间属性，同一收货地址在不同时间属性值上可以具有不同的权重，以此体现出该收货地址被使用的规律性特点。这样，通过不同收货地址在同一时间属性值上对应的权重的横向对比，即可确定出在该时间属性值上更有可能被用户使用的一个。

具体的，在本申请实施例中，可以首先将日期进行属性标注，例如，可以分为工作日或者节假日、休息日等。具体在对日期进行属性标注时，可以是按照每周一至周五为工作日，周六日以及其他法定假日为节假日等进行统一的标注。或者，还可以根据具体用户的情况进行标注，例如，有的用户是每周休一天，具体休息的日期可能是每周的周一，而不是周末，等等。对于这种特殊情况，可以为用户提供配置入口，由用户对自己特殊的日期属性进行标注。

在将日期划分了日期属性的情况下，还可以将每一天内的时间划分成多个时间段，例如，可以分为早餐时间段、午餐时间段、下午茶时间段、晚餐时间段、夜宵时间段，等等。具体每个时间段对应的时间起始点以及结束点，可以是按照经验进行划分，或者，系统还可以按照用户的集中下单情况，对每一天内的时间段进行划分。在上述按照用户集中下单情况进行划分的情况下，具体时间段也可以不必限定于上述几个，甚至每个时间段可以不必具有特定的含义，只是因为在用户的下单时间分布中呈现出集中的特点，即可作为一个时间段。另外，对于不同属性的日期，也可以分别进行下单时间分布的统计，例如，对于工作日和节假日而言，具体划分出的时间段，以及各个时间段的起始点、结束点都可以是有所不同的。并且，都还可以根据最新统计到的情况，对各个时间段进行更新。

在进行了日期属性标记，并对一天内的时间进行了时间段划分后，还可以对用户使用过的收货地址，按照在具体日期属性内的时间段，赋予一定的权重，并且，随着每次下单过程中对收货地址的使用，以及对应的下单时间点所属的时间段，对收货地址在该时间段内的权重进行更新。例如，当用户新建某收货地址时，可以根据各个时间段为该收货地址赋予一个初始权重。用户每使用某该地址作为在某个时间段中的收货地址时，可以为该地址在该时间段中的权重+1。如果用户在下单过程中修改了收货地址，那么将原来推荐的收货地址在该时间段中的权重-1，新选择的地址在该时间段中的权重+1，等等。总之，对于每个地址而言，都可以在不同的时间段对应有不同的权重，并根据各个地址在各时间段内被使用的情况，对地址在对应时间段上的权重进行更新。这样，经过一段时间的沉淀，就可以使得各个时间段上的权重，能够体现出对应的地址在对应时间段上的使用频度，以此来体现用户的消费习惯。

也就是说，在本申请实施例中，对于同一用户的各个地址，都可以维护有对应不同日期属性中不同时间段的权重。例如，在日期属性分为工作日和节假日两种不同属性值的情况下，每个使用过的收货地址，都可以对应有两套权重数据。例如，用表格表示的情况下，某用户的用户地址1在工作日各个时间段对应的权重可以如表1所示：

表1

另外，该用户地址1在节假日也可以具有另一套权重数据，例如，可以如表2所示：

表2

总之，每个被使用过的收货地址，都可以存在两套数据，分别对应与工作日的各个时间段上的权重，以及节假日的各个时间段上的权重，并且，具体的权重值还会随着新的订单的生成而发生变化。当然，在日期属性具有更多种属性值的情况下，也还可以分别为各个地址维护多套数据，等等。另外，在实际应用中，关于各个地址在各个时间段对应的权重，还可以有其他的确定方式，例如，还可以是为各个地址分别在各个不同的时间段指定不同的权重，等等。另外，由于在后续使用上述表格对用户可能会使用的收货地址进行预测的过程中，还可能会需要将用户所在的地理位置与各收货地址的地理位置进行比对，判断用户是否位于某收货地址附近。为了支持这种判断，还可以在上述表格中保存各个收货地址的地理位置信息，这种地理位置信息通常可以由经纬度等信息来表示，具体的经纬度信息可以通过电子地图等系统获得。

在为每个地址具有时间属性下(例如，在具体日期属性下具体时间段)的权重的情况下，就可以利用这种权重，对用户可能需要使用的收货地址进行预测。例如，一种实现方式下，可以是在某用户打开app时，确定当前日期的日期属性，是工作日还是节假日，并确定当前时间点所属的时间段，然后，就可以将该用户使用过的各个收货地址在该日期属性、该时间段上对应的权重值，然后，可以将其中权重值最高的一个，作为预测出的收货地址，并默认按照该收货地址提供可选的数据对象的信息。例如，某用户曾经使用过两个收货地址，分别为地址1和地址2，用户打开app时，所在的日期是一个工作日，时间是11：30，因此，可以确定出所属的时间段是8:30:00-13:59:59，这样，就可以分别确定出地址1和地址2，在工作日的该时间段对应的权重值，例如，地址1的权重值是10，地址2的权重值是3，也即，地址1在该日期属性的该时间段上的权重值比较高，因此，可以将该地址1作为预测出的用户可能会使用的收货地址。

前述方式下，是将当前用户使用过的全部收货地址，都进行对应的时间属性下的权重的比对，选择出用户最可能使用的一个作为当前收货地址。而在另一种实现方式下，为了缩小比对的范围，同时进一步提高预测的准确度，还可以在确定候选地址时，还可以按照一定的条件进行选择。例如，可以将当前时刻前后一段时间作为参考时间范围，并将该时间范围内被用户使用过的地址，作为候选地址。如，假设当前时刻是11：00，可以根据该用户的历史交易记录，将该用户在9：00到13：00这一时间范围内使用过的地址，作为候选收货地址。如果这种候选收货地址为多个，则可以基于这些候选地址在当前时刻所属时间属性值下的权重，确定出当前请求时刻最可能被使用的目标收货地址。当然，在通过这种时间范围选择候选收货地址时，也可以考虑到日期属性的因素，例如，可以将相同日期属性的日期中，该参考时间范围内使用过的收货地址，作为候选收货地址，等等。例如，当前日期是一个工作日，则可以将该用户在工作日的该参考时间范围内使用过的收货地址，作为候选收货地址。

或者，还可以根据用户当前所在的地理位置信息，从各个使用过的收货地址中，选择候选收货地址。这样，可以实现将收货地址的时间属性，与用户使用app时所在的地理位置信息相结合，进行综合性的预测，从而可以进一步提高预测出的收货地址的准确率。

具体的，在用户打开app时，可以首先获取用户当前所在的地理位置信息，然后，可以判断是否为该用户保存有使用过的收货地址，如果有，则可以判断该当前所在地理位置是否命中其中一收货地址，如果命中其中的地址a，则还可以以当前时刻的时间点为中心，取前后一段时间(例如前后两小时等)作为参考时间范围，并确定出该用户的历史订单记录中，在该参考时间范围内使用过的收货地址，假设为收货地址b。然后，还可以确定出当前日期的日期属性，以及当前时间点所属的时间段，并可以将该收货地址b与之前确定出的命中当前地理位置的收货地址a，在该日期属性下该时间段上的权重进行比较，将其中较高者作为预测出的用户更有可能使用的收货地址。也就是说，如果收货地址a在该日期属性下该时间段上的权重更高，则可以预测出，用户当前下单的话，则使用该收货地址a作为此次下单的收货地址的可能性更高。

上述方式恰好可以解决在其中一个地方下单，指定送到另一个地方的情况。例如，某用户习惯于在工作日下班之前进行点餐，并指定送到自己的家中，这样，等到下班到家后，所点的餐品也能够送达或者即将送达，因此，该用户在该日期属性下该时间段中，其家庭地址对应的收货地址就会具有较高的权重。这样，假设该用户在某工作日即将下班的时间，又打开了app，由于该用户目前还在工作单位，因此，根据用户当前所在的地理位置，命中的地址将会是与该工作单位对应的地址。也即，用户工作单位所在地对应的地址，就对应与当前地理位置命中的收货地址a。而该用户在历史交易订单记录中，在该时间段曾经以家庭地址作为收货地址，因此，该家庭地址就对应于收货地址b。此时，就可以将工作单位地址与家庭地址，在当前日期属性下该时间段的权重进行比对，比对结果是家庭地址的权重更高，因此，就可以将该家庭地址作为预测出的用户在此次下单时更有可能会使用的收货地址。

当然，在前述判断逻辑中，如果用户使用过的所有收货地址都没有命中当前所在的地理位置，则证明该用户当前所在的位置与其曾经使用过的收货地址可能都没有直接的关系。此时，还可以将用户最近使用过的地址，以及当前时刻前后一段时间范围内曾经使用过的地址，作为候选的收货地址，并将各个候选收货地址在当前日期属性下当前时间点所在的时间段内的权重进行比较，将其中较高者作为预测出的可能使用的收货地址。

需要说明的是，本申请实施例可以适用于多种具体的销售平台。其中一种具体的应用场景下，某些销售平台可能会采用特殊的销售平台模式，在该模式下，平台方可以部署线下门店，门店内主要经营生鲜、外卖类商品，其中，每个门店具有各自的配送范围。用户在安装关联的应用程序后，在打开应用程序时，可以按照用户的收货地址，选择配送范围能够覆盖该收货地址的门店，并在应用程序界面中展示该门店中销售的商品，用户可以进行下单购买，然后，由该门店为用户完成拣货及配送服务，以此实现以最快的速度送达。另外，用户还可以进入到线下门店中，对门店中的上品进行购买操作，在门店内，用户可以直接线下购买，或者，也可以利用app进行线上购买。

在上述销售平台模式下，由于每次为用户展示的只有其中一家门店内销售的数据对象，也就是说，每次根据用户的收货地址进行选择时，主要是选择能够为该收货地址提供配送服务的其中一个门店，最终也是有该门店为该收货地址进行配送，另外，用户还可能直接到该门店内，使用app进行下单，等等。因此，在发现用户使用过的各个收货地址均未当前所在的地理位置时，还可以判断用于当前所在位置是否命中其中一门店所在的位置，如果命中，则可以进入店内模式，用户可以执行线下的交易或者线上的购买等等。而如果用户当前所在位置既没有命中其使用过的收货地址，也没有命中任何一家门店，则可以利用前述逻辑，也即，将用户最近使用过的地址，以及当前时刻前后一段时间范围内曾经使用过的地址，作为候选的收货地址，然后，根据这些候选地址在当前时刻所属日期属性、时间段内的权重，预测出用户最有可能会使用的收货地址。

当然，在实际应用中，在从用户使用过的收货地址中确定候选收货地址时，也可以使用不同于上述方式的其他方式，例如，如果当前时刻前后一段时间范围内曾经使用过的地址已经有两个或者多个，则可以直接将这些地址作为候选地址，等等。

另外，还存在一种可能性是，系统中不存在用户的收货地址时，证明当前用户可能是一个新用户，或者将之前保存的收货地址清除，此时，可以根据用户当前所在的地理位置确定预测的收货地址，虽然，具体的地址可能不够详细，但是，可以为显示哪些数据对象提供依据。或者，在前述特殊的销售平台模式下，还可以首先判断当前地理位置是否在某门店的配送覆盖范围内，如果在，还可以继续判断是否位于某门店内，如果门店内，则可以进入店内模式，否则，再将当前所在的地理位置确定预测的收货地址。当然，如果当前地理位置不在任何一家门店的配送覆盖范围内，则可以直接提示用户，其当前所在位置不在配送范围内，等等。

需要说明的是，从产品的系统架构角度而言，参见图1，本申请实施例提供的技术方案可以由应用程序的客户端以及服务端来完成。其中，应用程序就是指具体提供数据对象浏览、购买等服务的应用程序，例如，“盒马”等。客户端主要是安装于用户的终端设备中，而服务端则通过是位于云端服务器中。具体的，关于各个用户的各收货地址在具体时间属性值下对应的权重等信息，可以是由服务端进行统计及维护。客户端则主要用于与用户进行交互，当然，也可以承担一部分计算工作。例如，在一种具体的实现方式下，在应用程序被打开时，可以由客户端从服务端获取关联用户对应各个收货地址在时间属性下的权重信息，将该信息保存在终端设备本地缓存中，然后再基于这种权重信息进行一系列的判断等操作，并最终预测出当前时刻用户可能使用的收货地址。或者，在另一种实现方式下，具体对可能使用的收货地址进行预测的操作可以由服务端来完成，并且可以直接根据预测出的收货地址，确定能够为该地址提供配送服务的门店或者商家，并提供出这种门店或商家发布的数据对象信息，客户端只要将预测的结果，以及对应的数据对象信息在前端界面中进行展示即可。

总之，通过本申请实施例，可以从时间属性方面，对用户使用过的收货地址进行评价，确定出各收货地址分别在各种不同时间属性下的权重，这样，在用户打开app需要进行浏览、下单等操作时，就可以使用这种时间属性方面的权重信息，来预测出用户当前时刻可能会使用的收货地址。通过这种方式，有利于提高预测的准确性。

另外，还可以将时间属性上的权重与用户当前所在的地理位置信息相结合，实现更准确更智能的预测。

基于以上所述，下面通过不同角度，对具体实施方式进行介绍。

实施例一

该实施例首先提供了一种地址信息处理方法，参见图2，该方法具体可以包括：

s201：在接收到操作请求时，确定所述请求关联的用户使用过的多个收货地址信息，以及分别在多种不同时间属性值下的权重；

关于该实施例一，各步骤的执行主体可以是客户端也可以是服务端。对于客户端而言，在收到用户的操作请求(打开客户端的操作等)时，可以通过从服务端拉取的方式，获得关联的用户使用过的各收货地址信息，以及分别在多种不同时间属性值下的权重，也即，服务端可以将前述表1、表2等数据提供给客户端，由客户端在终端设备本地进行具体的判断等操作。而在由服务端执行的情况下，接收到的操作请求可以是由客户端转发的用户操作请求，服务端可以根据客户端标识确定出关联的用户，然后，从数据库中获取出该用户使用过的各收货地址信息，以及分别在多种不同时间属性值下的权重即可。

s202：确定当前时刻的时间属性值；

关于具体的时间属性值，可以是预先进行定义的，例如，如前文所述，可以首先定义出日期属性值，在日期内，还可以划分出多种不同的时间段，因此，确定当前时刻的时间属性值的过程，就是可以首先确定出当前日期的日期属性值，然后再根据该日期属性值下对时间段的划分方式，确定出当前时刻所属的时间段。这样，当前时刻就会对应两个属性值，一个是日期属性值，一个是时间段，通过这两个属性值可以描述当前时刻的特征。

s203：根据所述收货地址在该时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

在确定出当前时刻的时间属性值后，就可以确定出各收货地址在该时间属性值下对应的权重，并且，可以进一步根据这种权重，确定出当前请求时刻可能被使用的目标收货地址。具体实现时，所述权重根据各收货地址分别在对应时间属性值被当前用户使用的情况而确定，也即，可以是通过统计、记录等方式确定出的各个收货地址在各个时间属性值下对应的权重，这种使用情况信息，是根据当前用户的历史交易记录等获得的，用以反映当前用户在时间属性上体现出的消费习惯。当然，在另一种方式下，也可以通过手动指定等多种方式来确定所述权重。

具体实现时，所述时间属性值包括：多种日期属性值以及日期内多种不同时间段，其中，不同日期属性值对应的时间段划分方式也可以有所不同，例如，可以将每个工作日的时间段划分成7段，而每个节假日的时间段可以划分为6段，每个时间段的起始点结束点都可以有所不同。具体的划分方式，可以是根据用户下单的时间分布等统计信息来确定，也即，将用户集中下单的时间段，确定为一个时间段，等等。在上述时间属性值的定义方式下，对于同一收货地址，在各种不同日期属性值下可以分别具有多个权重，其中，每种日期属性值下的多个权重分别与各个不同的时间段相对应。此时，具体在确定当前时刻的时间属性值时，可以是首先确定所述当前请求时刻所在日期的目标日期属性值，然后，确定出所述当前请求时刻在该目标日期属性值下所属的目标时间段。后续在根据所述收货地址在该时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址时，就可以确定各收货地址在所述目标日期属性值下所述目标时间段对应的目标权重，然后通过比较各收货地址对应的所述目标权重的大小，确定在当前请求时刻可能被使用的目标收货地址。

其中，所述权重可以根据各收货地址分别在各种不同日期属性值的日期中在各种不同的时间段被使用的情况而确定。

在实际应用中，为了进一步提高预测的准确性，还可以首先根据所述当前用户使用过的收货地址，确定候选收货地址；然后，再根据所述候选收货地址在该时间属性值下对应的权重，确定在当前请求时刻最可能被使用的目标收货地址。

具体在确定候选收货地址时，可以有多种方式，例如，其中一种方式下，可以以所述当前请求时刻为中心，选取前后预置时间长度作为参考时间范围；然后，通过查询所述当前用户的历史交易记录，将所述当前用户在所述参考时间范围内使用过的收货地址，确定为所述候选收货地址。

更优选的方式下，还可以首先确定当前请求时刻所在日期的日期属性，然后将所述当前用户在相同日期属性的日期，所述参考时间范围内使用过的收货地址，确定为所述候选收货地址。

另一种实现方式下，在确定候选收货地址信息时，还可以与用户当前所在的地理位置信息相关，具体的，可以首先确定所述当前用户当前所在的地理位置信息，然后将所述当前所在的地理位置信息与各个收货地址对应的地理位置信息进行比对；如果某收货地址命中所述当前所在的地理位置，则将该收货地址，以及当前用户在参考时间范围内使用过的收货地址，确定为所述候选收货地址；其中，所述参考时间范围为：以所述当前请求时刻前后预置时间长度的时间范围。也就是说，在前述第一种确定候选收货地址的基础上，还可以将命中当前所在地理位置的收货地址，加入到候选收货地址中。

另外，如果无收货地址命中所述当前所在的地理位置，则可以将当前用户在参考时间范围内使用过的收货地址，以及最近使用的收货地址，确定为所述候选收货地址；其中，所述参考时间范围为：以所述当前请求时刻前后预置时间长度的时间范围。也即，在前述第一种确定候选收货地址的基础上，还可以将最近使用的收货地址，例如，最近一次使用的收货地址，加入到候选收货地址中，等等。

在具体实现时，还可以根据所述当前所在的地理位置信息，确定所述当前用户是否位于某门店附近，如果不是，则触发所述将当前用户在参考时间范围内使用过的收货地址，以及最近使用的收货地址，确定为所述候选收货地址的步骤。

为了更直观的理解本申请实施例提供的技术方案，下面结合“盒马”系统应用场景下的一个具体实例，对具体实现方式进行详细介绍。其中，在“盒马”系统下，在线下部署多家门店，每家门店有各自的配送范围，用户在安装“盒马”客户端后，可以根据用户所在地理位置，或者用户指定的收货地址，确定出目标门店，然后提供该门店内发布的各种数据对象，用户下单后，由该门店为该用户进行配送。另外，在该例子中，可以将收货地址的时间属性值的权重，与用户所在地理位置相结合进行用户可能使用的收货地址的预测。

具体的，参见图3，对用户可能使用的收货地址进行预测的过程可以包括：

s301：客户端启动；

s302：获取用户当前所在地理位置；

s303：判断该用户是否有收货地址；如果有，进入s304，否则，进入s314；

s304：判断所述地理位置是否命中某收货地址a；如果是，进入s305，否则，进入s309；

s305：从用户收货地址库中取出当前时刻前后两小时内使用过的收货地址b；

s306：将收货地址a与收货地址b在当前所刻所属时间属性值的权重进行比对；如果a>b，进入s307，否则，进入s308；

s307：将a作为预测出的可能会使用的收货地址；

s308：将b作为预测出的可能会使用的收货地址；

s309：判断所述地理位置是否位于某门店附近；如果是，则进入店内模式，否则，进入s310；

s310：从用户收货地址库中取出当前时刻前后两小时内使用过的收货地址b，以及最近使用的收货地址c；

s311：将收货地址b与收货地址c在当前所刻所属时间属性值的权重进行比对；如果b>c，进入s312，否则，进入s313；

s312：将b作为预测出的可能会使用的收货地址；

s313：将c作为预测出的可能会使用的收货地址；

s314：(如果用户没有对应的收货地址记录)判断所述地理位置是否在某门店配送范围内；如果在，则进入s315，否则，进入s317；

s315：判断所述地理位置是否位于该门店附近；如果是，则进入店内模式，否则，进入s316；

s316：将当前所在地理位置作为预测的收货地址；

s317：进入不在配送范围提示页面。此时，用户还可以通过在页面上点击门店图片等方式进入到门店页面，等等。

需要说明的是，上述例子仅是本申请实施例中提供的众多实现方案中的其中之一，仅用于举例说明，不应看作是对本申请保护范围的限制。

实施例二

前述实施例一是在获得了收货地址在时间属性值下的权重信息之后，对用户可能使用的收货地址进行预测的过程进行了介绍，而本申请实施例二则主要从如何确定上述权重信息的角度，提供了一种地址信息处理方法，参见图4，该方法具体可以包括：

s401：确定时间属性值；

s402：获取多个收货地址在多种不同时间属性值下的被使用情况信息；

s403：根据所述被使用的信息确定各收货地址在各种不同时间属性值下的权重，以用于在接收到操作请求时，根据所述请求关联用户的多个收货地址在当前请求时刻的时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

在本申请实施例二中，各步骤的执行主体可以是服务端。其中，时间属性值可以是预先进行定义的，具体实现时，所述确定时间属性值，具体可以包括：确定日期属性值(例如，包括工作日、休息日、节假日等)，并在相同日期属性值的日期内划分多个不同的时间段。这样，具体在获取各收货地址在各种不同时间属性值下的被使用情况信息时，可以是确定各收货地址被使用日期的目标日期属性值，以及被使用时刻在该日期内所属的目标时间段，然后，就可以根据所述日期属性值以及所述目标时间段，确定各收货地址在对应的目标属性值、目标时间段下的权重。例如，可以根据同一收货地址在同一目标属性值、同一目标时间段内被当前用户使用的次数，确定该用户的该收货地址，在该目标属性值目标时间段内的权重，等等。

具体实现时，可以根据相同日期属性值的日期内用户的交易时间分布情况，进行时间段的划分。这种时间分布情况是通过对众多用户的交易情况进行统计确定的，例如，将用户集中下单的时间起始点及结束点确定为一个时间段，等等。

另外，统计出的各种权重信息可以并不是一成不变的，而是可以随着新的下单等行为的发生，根据收货地址实际被使用的情况，对对应时间属性上的权重进行更新。例如，在完成一次预测后，如果所预测的可能被使用的目标收货地址，最终成为实际被使用的收货地址，也即，用户没有对该预测出的目标收货地址进行修改操作，直接在此基础上完成了下单等操作，则将该目标收货地址在对应时间属性上的权重进行增加处理(例如，加1，等等)。

否则，如果所确定的可能被使用的目标收货地址，被替换为另一收货地址，也即，预测出的目标收货地址与用户实际所需使用的收货地址并不相同，此时，代表预测错误，因此，还可以将该目标收货地址在对应时间属性上的权重进行降低处理(例如，减1，等等)，同时，还可以将所述另一收货地址在对应时间属性上的权重进行增加处理。

与实施例一相对应，本申请实施例还提供了一种地址信息处理装置，参见图5，该装置可以包括：

收货地址信息确定单元501，用于在接收到操作请求时，确定所述请求关联的用户使用过的多个收货地址信息，以及分别在多种不同时间属性值下的权重；

时间属性值确定单元502，用于确定当前时刻的时间属性值；

目标收货地址确定单元503，用于根据所述收货地址在该时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

其中，所述权重根据各收货地址分别在对应时间属性值被使用的情况而确定。

其中，所述时间属性值包括：多种日期属性值以及日期内多种不同时间段；对于同一收货地址，在各种不同日期属性值下分别具有多个权重，其中，每种日期属性值下的多个权重分别与各个不同的时间段相对应；

此时，所述时间属性值确定单元具体用于：

确定所述当前请求时刻所在日期的目标日期属性值，以及所述当前请求时刻在该目标日期属性值下所属的目标时间段；

所述目标收货地址确定单元具体用于：

确定各收货地址在所述目标日期属性值下所述目标时间段对应的目标权重；通过比较各收货地址对应的所述目标权重的大小，确定在当前请求时刻可能被使用的目标收货地址。

其中，所述权重根据各收货地址分别在各种不同日期属性值的日期中在各种不同的时间段被使用的情况而确定。

在一种可选的实现方式下，该装置还可以包括：

候选地址确定单元，用于根据所述当前用户使用过的收货地址，确定候选收货地址；

所述目标收货地址确定单元具体用于：

根据所述候选收货地址在该时间属性值下对应的权重，确定在当前请求时刻最可能被使用的目标收货地址。

其中，所述候选地址确定单元具体可以包括：

参考时间范围确定子单元，用于以所述当前请求时刻为中心，选取前后预置时间长度作为参考时间范围；

查询子单元，用于通过查询所述当前用户的历史交易记录，将所述当前用户在所述参考时间范围内使用过的收货地址，确定为所述候选收货地址。

另外，该装置还可以包括：

日期属性确定单元，用于确定当前请求时刻所在日期的日期属性；

所述查询子单元具体可以用于：

将所述当前用户在相同日期属性的日期，所述参考时间范围内使用过的收货地址，确定为所述候选收货地址。

另一种实现方式下，候选地址确定单元具体可以包括：

地理位置信息确定子单元，用于确定所述当前用户当前所在的地理位置信息；

比对子单元，用于将所述当前所在的地理位置信息与各个收货地址对应的地理位置信息进行比对；

确定子单元，用于如果某收货地址命中所述当前所在的地理位置，则将该收货地址，以及当前用户在参考时间范围内使用过的收货地址，确定为所述候选收货地址；其中，所述参考时间范围为：以所述当前请求时刻前后预置时间长度的时间范围。

在上述方式下，具体实现时，确定子单元还可以用于：

如果无收货地址命中所述当前所在的地理位置，则将当前用户在参考时间范围内使用过的收货地址，以及最近使用的收货地址，确定为所述候选收货地址；其中，所述参考时间范围为：以所述当前请求时刻前后预置时间长度的时间范围。

另外，该装置还可以包括：

位置判断单元，用于在将当前用户在参考时间范围内使用过的收货地址，以及最近使用的收货地址，确定为所述候选收货地址之前，根据所述当前所在的地理位置信息，确定所述当前用户是否位于某门店附近，如果不是，则触发所述将当前用户在参考时间范围内使用过的收货地址，以及最近使用的收货地址，确定为所述候选收货地址的步骤。

与实施例二相对应，本申请实施例还提供了一种地址信息处理装置，参见图6，该装置可以包括：

时间属性确定单元601，用于确定时间属性值；

使用情况信息获取单元602，用于获取多个收货地址在多种不同时间属性值下的被使用情况信息；

权重确定单元603，用于根据所述被使用的信息确定各收货地址在各种不同时间属性值下的权重，以用于在接收到操作请求时，根据所述请求关联用户的多个收货地址在当前请求时刻的时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

具体实现时，时间属性确定单元可以用于：

确定日期属性值，并在相同日期属性值的日期内划分多个不同的时间段；

所述使用情况信息获取单元具体可以用于：

确定多个收货地址被使用日期的目标日期属性值，以及被使用时刻在该日期内所属的目标时间段；

所述权重确定单元具体可以用于：

根据所述日期属性值以及所述目标时间段，确定各收货地址在对应的目标属性值、目标时间段下的权重。

具体的，所述使用情况信息获取单元具体可以用于：

根据相同日期属性值的日期内用户的交易时间分布情况，进行时间段的划分。

在具体实现时，该装置还可以包括：

第一权重更新单元，用于如果所确定的可能被使用的目标收货地址，为实际被使用的收货地址，则将该目标收货地址在对应时间属性上的权重进行增加处理。

或者，第二权重更新单元，用于如果所确定的可能被使用的目标收货地址，被替换为另一收货地址，则将该目标收货地址在对应时间属性上的权重进行降低处理，并将所述另一收货地址在对应时间属性上的权重进行增加处理。

与前述实施例一相对应，本申请实施例还提供了一种计算机系统，该系统可以包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

在接收到操作请求时，确定所述请求关联的用户使用过的多个收货地址信息，以及分别在多种不同时间属性值下的权重；

确定当前时刻的时间属性值；

根据所述收货地址在该时间属性值下对应的权重，确定在当前请求时刻可能被使用的目标收货地址。

其中，图7示例性的展示出了电子设备的架构，例如，设备700可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。

参照图7，设备700可以包括以下一个或多个组件：处理组件702，存储器704，电源组件706，多媒体组件708，音频组件710，输入/输出(i/o)的接口712，传感器组件714，以及通信组件716。

处理组件702通常控制设备700的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件702可以包括一个或多个处理器720来执行指令，以完成本公开技术方案提供的视频播放方法中的当满足预设条件时，生成流量压缩请求，并发送给服务器，其中所述流量压缩请求中记录有用于触发服务器获取目标关注区域的信息，所述流量压缩请求用于请求服务器优先保证目标关注区域内视频内容的码率；根据服务器返回的码流文件播放所述码流文件对应的视频内容，其中所述码流文件为服务器根据所述流量压缩请求对所述目标关注区域之外的视频内容进行码率压缩处理得到的视频文件的全部或部分步骤。此外，处理组件702可以包括一个或多个模块，便于处理组件702和其他组件之间的交互。例如，处理部件702可以包括多媒体模块，以方便多媒体组件708和处理组件702之间的交互。

存储器704被配置为存储各种类型的数据以支持在设备700的操作。这些数据的示例包括用于在设备700上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器704可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。

电源组件706为设备700的各种组件提供电力。电源组件706可以包括电源管理系统，一个或多个电源，及其他与为设备700生成、管理和分配电力相关联的组件。

多媒体组件708包括在设备700和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件708包括一个前置摄像头和/或后置摄像头。当设备700处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件710被配置为输出和/或输入音频信号。例如，音频组件710包括一个麦克风(mic)，当设备700处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器704或经由通信组件716发送。在一些实施例中，音频组件710还包括一个扬声器，用于输出音频信号。

i/o接口712为处理组件702和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件714包括一个或多个传感器，用于为设备700提供各个方面的状态评估。例如，传感器组件714可以检测到设备700的打开/关闭状态，组件的相对定位，例如所述组件为设备700的显示器和小键盘，传感器组件714还可以检测设备700或设备700一个组件的位置改变，用户与设备700接触的存在或不存在，设备700方位或加速/减速和设备700的温度变化。传感器组件714可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件714还可以包括光传感器，如cmos或ccd图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件714还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件716被配置为便于设备700和其他设备之间有线或无线方式的通信。设备700可以接入基于通信标准的无线网络，如wifi，2g或3g，或它们的组合。在一个示例性实施例中，通信部件716经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信部件716还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。

在示例性实施例中，设备700可以被一个或多个应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器704，上述指令可由设备700的处理器720执行以完成本公开技术方案提供的视频播放方法中的当满足预设条件时，生成流量压缩请求，并发送给服务器，其中所述流量压缩请求中记录有用于触发服务器获取目标关注区域的信息，所述流量压缩请求用于请求服务器优先保证目标关注区域内视频内容的码率；根据服务器返回的码流文件播放所述码流文件对应的视频内容，其中所述码流文件为服务器根据所述流量压缩请求对所述目标关注区域之外的视频内容进行码率压缩处理得到的视频文件。例如，所述非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。