多位置递送

摘要

用于确定电子商务系统或购物车中的产品的产品履行选项的方法和系统。使用来自递送简档数据库的递送简档，其中递送简档特定于产品，并且包含库存位置和递送区。利用对推荐选项的优先级基础确定。

权利要求

1.一种用于确定预期订单的履行选项的方法，包括：从所述预期订单中标识产品和目的地；

检索递送简档，所述递送简档包括：（i）所述产品的库存位置，（ii）在其中可以从所述库存位置运输所述产品的递送区，以及（iii）一个或多个履行选项，其中所述一个或多个履行选项包括将所述产品从所述库存位置运输到所述递送区的一个或多个运输费率；以及基于优先级基础来从所述一个或多个履行选项中确定选项。

2.根据权利要求1所述的方法，其中所述一个或多个运输费率中的每个运输费率包括运输提供商、运输服务和运输成本。

3.根据权利要求1所述的方法，其中所述产品是多个不同的产品，并且所述递送简档是与所述多个不同的产品相对应的多个不同的递送简档。

4.根据权利要求1所述的方法，其中所述库存位置是多个库存位置，并且其中所述选项是基于所述多个库存位置的多个选项。

5.根据权利要求1所述的方法，其中所述递送区是多个递送区。

6.根据权利要求1所述的方法，其中所述一个或多个运输费率是多个运输费率，并且其中所述选项是基于所述多个运输费率的多个选项。

7.根据权利要求1所述的方法，其中所述预期订单的选项不包括到所述目的地的履行选项。

8.根据权利要求1所述的方法，其中所述优先级基础是最低的运输成本。

9.根据权利要求1所述的方法，进一步包括：将所述选项传送给客户设备。

10.根据权利要求1所述的方法，进一步包括：基于所述递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的库存信息请求；

经由所述库存信息请求来请求库存信息；

响应于所述库存信息请求来接收库存信息，以及其中所述优先级基础还考虑所述库存信息以确定选项。

11.根据权利要求1所述的方法，进一步包括：基于所述递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的运输信息请求；

经由所述运输信息请求来请求运输信息；

接收运输信息；以及

其中所述优先级基础还考虑所述运输信息。

12.根据权利要求1所述的方法，进一步包括：基于所述递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的库存信息请求；

经由所述库存信息请求来请求库存信息；

响应于所述库存信息请求来接收库存信息；

从递送简档中的库存位置、递送区和一个或多个履行选项、接收到的库存信息、以及目的地来确定将被请求的运输信息请求；

经由所述运输信息请求来请求运输信息；以及其中所述优先级基础还考虑所述库存信息和所述运输信息。

13.根据权利要求1所述的方法，进一步包括：根据所述递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的库存信息请求；

经由所述库存信息请求来请求库存信息；

响应于与所述库存位置有关的库存信息请求来接收库存信息，所述库存位置具有所述产品的可用库存；

如果所述库存位置没有所述产品的可用库存，则忽略所述库存位置；

根据所述递送简档中的库存位置、递送区和一个或多个履行选项来确定将被请求的运输信息请求；

经由所述运输信息请求来请求运输信息，其中所述运输信息请求是经由电子商务平台外部的API调用做出的；

响应于所述运输信息请求来接收运输信息；

将所述选项传送给客户设备；

其中从简档数据库中检索所述递送简档；

其中所述产品是多个不同的产品；

其中所述递送简档是与所述多个不同的产品相对应的多个递送简档；

其中所述库存位置是多个库存位置；

其中所述递送区是多个递送区；

其中所述一个或多个运输费率中的每个运输费率包括运输提供商、运输服务和运输成本；

其中所述一个或多个运输费率是多个运输费率；

其中所述运输信息包括运输提供商、运输服务和运输成本；

其中所述运输信息请求是多个运输信息请求；

其中所述优先级基础还考虑所述库存信息和所述运输信息；以及其中所述预期订单的履行选项可以是多个选项。

14.一种用于确定电子商务平台中的预期订单的履行选项的方法，包括：标识将一个或多个产品递送到目的地的预期订单；

检索一个或多个递送简档，所述一个或多个递送简档包括：（i）所述一个或多个产品的一个或多个库存位置，（ii）在其中可以从所述一个或多个库存位置运输一个或多个产品的一个或多个递送区，以及（iii）一个或多个履行选项，其中所述一个或多个履行选项包括：将所述一个或多个产品从所述一个或多个库存位置运输到所述一个或多个递送区的一个或多个运输费率；

基于所述一个或多个递送简档中的一个或多个库存位置、一个或多个递送区和一个或多个履行选项、以及目的地来确定将被请求的多个运输信息请求；

经由所述多个运输信息请求来请求运输信息，其中所述多个运输信息请求包括至少一个运输信息请求，所述请求是电子商务平台外部的API调用；

响应于所述多个运输信息请求来接收运输信息；以及基于优先级基础，根据所述一个或多个库存位置、所述一个或多个递送区、所述一个或多个履行选项、以及所述运输信息来确定选项。

15.一种用于执行权利要求1-14中任一项所述的方法的装置。

说明书

多位置递送

技术领域

[0001] 本公开涉及确定用于递送在线购买的产品的产品履行选项的电子商务系统和方法中的进步。

背景技术

[0002] 随着在线销售的增长，现代电子商务平台必须快速且可靠地向客户提供关于预期购买的信息，使得客户可以在他们的耐心经受考验之前完成交易，否则客户或交易可能会丢失。照此，特别是在国际在线交易中，重要的是，电子商务平台必须能够针对库存位置、递送区和运输费率（rate）提供接近即时的结果。因此，所需要的是，在获得和处理与具有预期购买的客户有关的库存信息和运输信息的方式中的改进。

发明内容

[0003] 在一方面，一种方法可以包括确定预期订单的履行选项，包括：从预期订单中标识产品和目的地；检索递送简档，该递送简档包括：（i）产品的库存位置，（ii）在其中可以从库存位置运输产品的递送区，以及（iii）一个或多个履行选项，其中该一个或多个履行选项可以包括将产品从库存位置运输到递送区的一个或多个运输费率；以及，基于优先级基础来从一个或多个履行选项中确定选项。在实施例中，可以从递送简档数据库中检索该方法的递送简档。可以从存储在递送简档数据库中的递送简档记录中检索递送简档。一个或多个运输费率中的每个运输费率可以包括运输提供商、运输服务和运输成本。该产品可以是多个不同的产品，并且递送简档可以是与多个不同的产品相对应的多个不同的递送简档。库存位置可以是多个库存位置。选项可以是基于多个库存位置的多个选项。递送区可以是多个递送区。一个或多个运输费率可以是多个运输费率。该选项可以是基于多个运输费率的多个选项。目的地的国家可以与库存位置不同。预期订单的选项可以不包括到目的地的履行选项。优先级基础可以是最低的运输成本。优先级基础可以是最快的递送时间。优先级基础可以是最短的地理距离。该方法可以进一步包括将选项传送给客户设备。客户设备可以是移动设备。该方法可以进一步包括：基于递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的库存信息请求；经由库存信息请求来请求库存信息；响应于库存信息请求来接收库存信息，以及其中优先级基础还考虑库存信息以确定选项。
库存信息请求可以是API调用。库存信息请求可以是电子商务平台外部的API调用。该方法可以进一步包括：基于递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的运输信息请求；经由运输信息请求来请求运输信息；接收运输信息；以及，其中优先级基础还考虑运输信息。运输信息请求可以是API调用。运输信息请求可以是电子商务平台外部的API调用。递送简档可以是多个递送简档，并且运输信息请求可以是与多个递送简档相对应的多个运输信息请求。多个运输信息请求可以是多个API调用。多个运输信息请求可以是电子商务平台外部的多个API调用。库存位置可以是多个库存位置；递送区可以是多个递送区；以及，运输信息请求可以是多个运输信息请求。多个运输信息请求可以是多个API调用。多个运输信息请求可以是电子商务平台外部的多个API调用。多个运输信息请求中的至少一个可以是对运输提供商的API调用。该方法可以进一步包括：基于递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的库存信息请求；经由库存信息请求来请求库存信息；响应于库存信息请求来接收库存信息；从递送简档中的库存位置、递送区和一个或多个履行选项、接收到的库存信息、以及目的地来确定将被请求的运输信息请求；经由运输信息请求来请求运输信息；以及，其中优先级基础还考虑库存信息和运输信息。运输信息可以包括运输提供商、运输服务和运输成本。可以经由对库存提供商的API调用来请求库存信息。库存位置可以在电子商务平台的外部。可以经由对运输提供商的API调用来请求运输信息。运输提供商可以在电子商务平台的外部。该方法可以进一步包括：根据递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的库存信息请求；经由库存信息请求来请求库存信息；响应于与库存位置有关的库存信息请求来接收库存信息，该库存位置具有产品的可用库存；如果没有产品的可用库存，则忽略该库存位置；根据递送简档中的库存位置、递送区和一个或多个履行选项来确定将被请求的运输信息请求；经由该运输信息请求来请求运输信息，其中可以经由电子商务平台外部的API调用来做出运输信息请求；响应于运输信息请求来接收运输信息；将选项传送给客户设备；其中可以从递送简档数据库中检索递送简档；其中产品可以是多个不同的产品；其中递送简档可以是与多个不同的产品相对应的多个递送简档；其中库存位置可以是多个库存位置；其中递送区可以是多个递送区；其中一个或多个运输费率中的每个运输费率可以包括运输提供商、运输服务和运输成本；其中一个或多个运输费率可以是多个运输费率；其中运输信息可以包括运输提供商、运输服务和运输成本；其中运输信息请求可以是多个运输信息请求；其中优先级基础还考虑库存信息和运输信息；以及其中预期订单的履行选项可以是多个选项。

[0004] 在一个方面，一种方法可以包括确定电子商务平台中的预期订单的履行选项，包括：标识将一个或多个产品递送到目的地的预期订单；检索一个或多个递送简档，该一个或多个递送简档包括：（i）一个或多个产品的一个或多个库存位置，（ii）在其中可以从一个或多个库存位置运输一个或多个产品的一个或多个递送区，以及（iii）一个或多个履行选项，其中该一个或多个履行选项包括：将一个或多个产品从一个或多个库存位置运输到一个或多个递送区的一个或多个运输费率；基于一个或多个递送简档中的一个或多个库存位置、一个或多个递送区和一个或多个履行选项、以及目的地来确定将被请求的多个运输信息请求；经由多个运输信息请求来请求运输信息，其中该多个运输信息请求包括至少一个运输信息请求，该请求可以是电子商务平台外部的API调用；响应于多个运输信息请求来接收运输信息；以及基于优先级基础，根据一个或多个库存位置、一个或多个递送区、一个或多个履行选项、以及运输信息来确定选项。在实施例中，可以从递送简档数据库中检索一个或多个递送简档。可以从存储在递送简档数据库中的一个或多个递送简档记录中检索一个或多个递送简档。目的地的国家可以与一个或多个库存位置中的一个不同。选项可以包括多个履行选项。预期订单的选项可以不包括可用的履行选项。优先级基础可以是最低的运输成本。优先级基础可以是最快的递送时间。优先级基础可以是最短的地理距离。可以在确定多个运输信息请求的效用之后立即做出多个运输信息请求。该方法可以进一步包括将选项传送给客户设备。客户设备可以是移动设备。该方法可以进一步包括：基于一个或多个递送简档中的一个或多个库存位置、一个或多个递送区和一个或多个履行选项、以及目的地来确定将被请求的多个库存信息请求；经由多个库存信息请求来请求库存信息；接收库存信息；其中确定多个运输信息请求的步骤考虑了库存信息以确定运输信息请求；以及，其中优先级基础还考虑库存信息以确定选项。该方法可以进一步包括：基于一个或多个递送简档中的一个或多个库存位置、一个或多个递送区和一个或多个履行选项、以及目的地来确定将被请求的多个库存信息请求；经由多个库存信息请求来请求库存信息；接收库存信息；忽略没有一个或多个产品的可用库存的库存位置；将选项传送给客户设备；其中可以从存储在递送简档数据库中的一个或多个递送简档记录中检索一个或多个递送简档；其中目的地的国家可能与一个或多个库存位置中的至少一个不同；其中一个或多个运输费率中的每个运输费率可以包括运输提供商、运输服务和运输成本；以及，其中优先级基础还考虑库存信息和运输信息。

[0005] 在一方面，一种系统可以包括确定预期订单的履行选项，包括：包括至少一个处理器和至少一个存储器的电子商务平台，该电子商务平台被适配成：从预期订单中标识产品和目的地；检索递送简档，该递送简档包括：（i）产品的库存位置，（ii）在其中可以从库存位置运输产品的递送区，以及（iii）一个或多个履行选项，其中该一个或多个履行选项可以包括将产品从库存位置运输到递送区的一个或多个运输费率；以及，基于优先级基础来从一个或多个履行选项中确定选项。该系统可以进一步包括递送简档数据库，其中可以从递送简档数据库中检索递送简档。该系统可以进一步包括递送简档数据库，其中可以从存储在递送简档数据库中的递送简档记录中检索递送简档。一个或多个运输费率中的每个运输费率可以包括运输提供商、运输服务和运输成本。该产品可以是多个不同的产品，并且递送简档可以是与多个不同的产品相对应的多个不同的递送简档。库存位置可以是多个库存位置。选项可以是基于多个库存位置的多个选项。递送区可以是多个递送区。一个或多个运输费率可以是多个运输费率。该选项可以是基于多个运输费率的多个选项。目的地的国家可以与库存位置不同。预期订单的选项可以不包括到目的地的履行选项。优先级基础可以是最低的运输成本。优先级基础可以是最快的递送时间。优先级基础可以是最短的地理距离。该系统可以进一步被适配成将选项传送给客户设备。客户设备可以是移动设备。该系统可以进一步被适配成：基于递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的库存信息请求；经由库存信息请求来请求库存信息；响应于库存信息请求来接收库存信息，以及其中优先级基础还考虑库存信息以确定选项。库存信息请求可以是API调用。库存信息请求可以是电子商务平台外部的API调用。该系统可以进一步被适配成：基于递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的运输信息请求；经由运输信息请求来请求运输信息；接收运输信息；以及，其中优先级基础还考虑运输信息。运输信息请求可以是API调用。运输信息请求可以是电子商务平台外部的API调用。递送简档可以是多个递送简档，并且运输信息请求可以是与多个递送简档相对应的多个运输信息请求。多个运输信息请求可以是多个API调用。多个运输信息请求可以是电子商务平台外部的多个API调用。库存位置可以是多个库存位置；递送区可以是多个递送区；以及运输信息请求可以是多个运输信息请求。多个运输信息请求可以是多个API调用。多个运输信息请求可以是电子商务平台外部的多个API调用。多个运输信息请求中的至少一个可以是对运输提供商的API调用。该系统可以进一步被适配成：基于递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的库存信息请求；经由库存信息请求来请求库存信息；响应于库存信息请求来接收库存信息；根据递送简档中的库存位置、递送区和一个或多个履行选项、接收到的库存信息、以及目的地来确定将被请求的运输信息请求；经由运输信息请求来请求运输信息；以及，其中优先级基础还考虑库存信息和运输信息。运输信息可以包括运输提供商、运输服务和运输成本。可以经由对库存提供商的API调用来请求库存信息。库存位置可以在电子商务平台的外部。可以经由对运输提供商的API调用来请求运输信息。运输提供商可以在电子商务平台的外部。该系统可以进一步被适配成：根据递送简档中的库存位置、递送区和一个或多个履行选项、以及目的地来确定将被请求的库存信息请求；经由库存信息请求来请求库存信息；响应于与库存位置有关的库存信息请求来接收库存信息，该库存位置具有产品的可用库存；如果没有产品的可用库存，则忽略该库存位置；根据递送简档中的库存位置、递送区和一个或多个履行选项来确定将被请求的运输信息请求；经由运输信息请求来请求运输信息，其中可以经由电子商务平台外部的API调用来做出运输信息请求；响应于运输信息请求来接收运输信息；将选项传送给客户设备；其中可以从递送简档数据库中检索递送简档；其中产品可以是多个不同的产品；其中递送简档可以是与多个不同产品相对应的多个递送简档；其中库存位置可以是多个库存位置；其中递送区可以是多个递送区；其中一个或多个运输费率中的每个运输费率可以包括运输提供商、运输服务和运输成本；其中一个或多个运输费率可以是多个运输费率；其中运输信息可以包括运输提供商、运输服务和运输成本；其中运输信息请求可以是多个运输信息请求；其中优先级基础还考虑库存信息和运输信息；以及其中预期订单的履行选项可以是多个选项。

[0006] 在一方面，一种系统可以包括确定预期订单的履行选项，包括：包括至少一个处理器和至少一个存储器的电子商务平台，该电子商务平台被适配成：标识将一个或多个产品递送到目的地的预期订单；检索一个或多个递送简档，该一个或多个递送简档包括：（i）一个或多个产品的一个或多个库存位置，（ii）在其中可以从一个或多个库存位置运输一个或多个产品的一个或多个递送区，以及（iii）一个或多个履行选项，其中该一个或多个履行选项包括：将一个或多个产品从一个或多个库存位置运输到一个或多个递送区的一个或多个运输费率；基于一个或多个递送简档中的一个或多个库存位置、一个或多个递送区和一个或多个履行选项、以及目的地来确定将被请求的多个运输信息请求；经由多个运输信息请求来请求运输信息，其中该多个运输信息请求包括至少一个运输信息请求，该请求可以是电子商务平台外部的API调用；响应于多个运输信息请求来接收运输信息；以及，基于优先级基础，根据一个或多个库存位置、一个或多个递送区、一个或多个履行选项以及运输信息来确定选项。可以从递送简档数据库中检索一个或多个递送简档。可以从存储在递送简档数据库中的一个或多个递送简档记录中检索一个或多个递送简档。目的地的国家可以与一个或多个库存位置中的一个不同。选项可以包括多个履行选项。预期订单的选项可能不包括可用的履行选项。优先级基础可以是最低的运输成本。优先级基础可以是最快的递送时间。优先级基础可以是最短的地理距离。可以在确定多个运输信息请求的效用之后立即做出多个运输信息请求。该系统可以进一步被适配成将选项传送给客户设备。客户设备可以是移动设备。该系统可以进一步被适配成：基于一个或多个递送简档中的一个或多个库存位置、一个或多个递送区和一个或多个履行选项、以及目的地来确定将被请求的多个库存信息请求；经由多个库存信息请求来请求库存信息；接收库存信息；其中确定多个运输信息请求的步骤考虑了库存信息以确定运输信息请求；以及，其中优先级基础还考虑库存信息以确定选项。该系统可以进一步被适配成：基于一个或多个递送简档中的一个或多个库存位置、一个或多个递送区和一个或多个履行选项、以及目的地来确定将被请求的多个库存信息请求；经由多个库存信息请求来请求库存信息；接收库存信息；忽略没有一个或多个产品的可用库存的库存位置；将选项传送给客户设备；其中可以从存储在递送简档数据库中的一个或多个递送简档记录中检索一个或多个递送简档；其中目的地的国家可以与一个或多个库存位置中的至少一个不同；其中一个或多个运输费率中的每个运输费率可以包括运输提供商、运输服务和运输成本；以及，其中优先级基础还考虑库存信息和运输信息。

附图说明

[0007] 图1描绘了电子商务平台的实施例。

[0008] 图2描绘了管理员的主页的实施例。

[0009] 图3是描绘了现有技术方法的流程图。

[0010] 图4是描绘了确定履行选项的实施例的流程图。

[0011] 图5描绘了确定履行选项的实施例的逻辑架构。

[0012] 图6描绘了两个递送简档的实施例。

[0013] 图7-10图示了基于图6的递送简档的样本预期订单的实施例。

具体实施方式

[0014] 现在将通过参考附图和展示描述本公开的各种说明性、非限制性实施例来详细描述本公开。然而，本公开可以采用许多不同的形式体现，并且不应该被解释为限于本文中阐述的说明性实施例；而是，提供这些实施例使得本公开将是透彻的，并且将充分地向本领域技术人员传达本公开的概念。

[0015] 参照图1，描绘了用于向客户提供商家产品和服务的实施例电子商务平台100。尽管本公开始终考虑使用所公开的装置、系统和过程来购买产品和服务，但是为简单起见，本文中的描述将指代产品。在整个本公开中，对产品的所有引用也应该被理解为对产品和/或服务的引用，包括物理产品、数字内容、票证、订阅、要提供的服务等等。

[0016] 尽管本公开始终预期“商家”和“客户”可以不仅仅是个体，但是为了简单起见，本文中的描述通常可以如此指代商家和客户。在整个本公开中，对商家和客户的所有引用也应该被理解为对个体、公司、企业、计算实体等等的群组的引用，并且可以表示产品的营利性或非营利性交换。此外，尽管整个本公开提到“商家”和“客户”，并且如此描述他们的角色，但是电子商务平台100应当被理解成更一般地支持电子商务环境中的用户，并且遍及本公开对商家和客户的所有引用也应该被理解为对如下各项的引用：用户（诸如当用户是商家用户（例如，销售商、零售商、批发商或产品提供商）时）、客户用户（例如，买方、购买代理或产品用户）、预期用户（例如，浏览但尚未承诺购买的用户、针对在营销和销售产品时的潜在用途而评估电子商务平台100的用户等等）、服务提供商用户（例如，运输提供商112、金融提供商等等）、公司或企业用户（例如，用于购买、销售或使用产品的公司代表；企业用户；客户关系或客户管理代理等等）、信息技术用户、计算实体用户（例如，用于购买、销售或使用产品的计算机器人）等等。

[0017] 电子商务平台100可以提供用于向商家提供用于管理其业务的在线资源和设施的集中式系统。可以通过在可以是平台100的一部分或在平台100外部的一个或多个处理器上执行计算机软件、模块、程序代码和/或指令的机器来部分地或全部地部署本文中所描述的设施。商家可以利用电子商务平台100来管理与客户的商务，诸如通过经由在线商店138、经由渠道110A-B、经由在物理位置（例如，物理店面，或者诸如经由自助服务终端、终端机、阅读器、打印机、3D打印机之类的其他位置等等）中的POS设备152）来实现与客户的电子商务体验，通过经由电子商务平台100来管理其业务，以及通过经由电子商务平台100的通信设施129来与客户交互，或者其任何组合。商家可以利用电子商务平台100作为与客户的唯一商务存在，或者与其他商家商务设施结合地利用电子商务平台100，诸如通过物理商店（例如，“砖墙加灰泥式的”零售商店）、商家非平台网站104（例如，由商家支持或代表商家的商务互联网网站或其他互联网或web财产或资产，它们与电子商务平台分离）等等。然而，甚至这些“其他”商家商务设施也可以被合并到电子商务平台中，诸如其中商家的物理商店中的POS设备152被链接到电子商务平台100中，其中商家非平台网站104诸如通过“购买按钮”而绑定到电子商务平台100等等，该“购买按钮”将内容从商家非平台网站104链接到在线商店138。

[0018] 在线商店138可以表示包括多个虚拟店面的多租户设施。在实施例中，商家可以诸如通过商家设备102（例如，计算机、膝上型计算机、移动计算设备等等）来管理在线商店138中的一个或多个店面，并且通过许多不同的渠道110A-B（例如，在线商店138；通过POS设备152的物理店面；通过集成到网站或社交媒体渠道（诸如，在社交网络、社交媒体页面、社交媒体消息传递系统上）中的电子购买按钮的电子市场；等等）向客户提供产品。商家可以跨渠道110A-B进行销售，并且然后通过电子商务平台100来管理其销售，其中渠道110A可以被提供在电子商务平台100的内部，也可以从电子商务渠道110B的外面来提供。商家可以以弹出窗口、通过批发、通过电话等等在其物理零售商店中进行销售，并且然后通过电子商务平台100来管理其销售。商家可以采用全部这些或这些的任何组合，诸如利用POS设备152通过物理店面来维持业务，通过在线商店138来维持虚拟店面，以及利用通信设施129以利用客户交互和分析132，从而改进销售的概率。在整个本公开中，术语在线商店138和店面可以同义地用于指代通过电子商务平台100的商家的在线电子商务供应的存在，其中在线商店138可以指代由电子商务平台100（例如，针对多个商家）支持的店面的多租户集合，或者指代个体商家的店面（例如，商家的在线商店）。

[0019] 在实施例中，客户可以通过客户设备150（例如，计算机、膝上型计算机、移动计算设备等等）、POS设备152（例如，零售设备、自助服务终端、自动化结帐系统等），或本领域已知的任何其他商务接口设备进行交互。电子商务平台100可以使得商家能够通过如下方式到达客户：通过在线商店138、通过物理位置（例如，商家的店面或其他地方）中的POS设备152，以便经由电子通讯设施129、通过对话来促进与客户的商务贸易等等，从而提供了一种用于到达客户并且便于商家服务以实现可用于到达客户并与客户交互的真实或虚拟路径的系统。

[0020] 在实施例中，并且如本文中进一步描述的，可以通过包括处理器和存储器的处理设施来实现电子商务平台100，该处理设施存储一组指令，该组指令当被执行时使电子商务平台100实行如本文中所描述的电子商务和支持功能。处理设施可以是服务器、客户端、网络基础设施、移动计算平台、云计算平台、固定计算平台或其他计算平台的一部分，并且在电子商务平台100、商家设备102、支付网关106、应用开发者、渠道110A-B、运输提供商112、客户设备150、销售点设备152等等的电子组件之间以及在它们当中提供电子连接和通信。电子商务平台100可以被实现为云计算服务、软件即服务（SaaS）、基础设施即服务（IaaS）、平台即服务（PaaS）、桌面即服务（DaaS）、管理软件即服务（MSaaS）、移动后端即服务（MBaaS）、信息技术管理即服务（ITMaaS）等等，它们诸如在软件和递送模型中实现，在该模型中，软件是在订阅基础上被许可并且集中托管的（例如，由用户使用客户端（例如，瘦客户端）经由Web浏览器或其他应用来访问，通过POS设备来访问等等）。在实施例中，电子商务平台100的元素可以被实现为在各种平台和操作系统上进行操作，这些平台和操作系统诸如是iOS、Android、在Web上等等（例如，管理员114在针对iOS、Android和针对Web的给定在线商店的多个实例中实现，每个实例具有相似的功能）。

[0021] 在实施例中，在线商店138可以通过由电子商务平台100的服务器提供的网页而服务于客户设备150。服务器可以从安装在客户设备150上的浏览器或其他应用接收对该网页的请求，其中浏览器（或其他应用）通过IP地址连接到服务器，该IP地址是通过转换域名获得的。作为回报，服务器往回发送所请求的网页。可以用超文本标记语言（HTML）、模板语言、JavaScript等等或其任何组合来编写网页，或者该网页包括上述语言。例如，HTML是一种计算机语言，其描述网页的静态信息，诸如网页的布局、格式和内容。网站设计者和开发者可以使用模板语言来构建网页，这些网页将静态内容（其在多个页面上相同）和动态内容（从一个页面到下一个页面有变化）进行组合。模板语言可以使重新使用定义网页布局的静态元素成为可能，同时利用来自在线商店的数据来动态填充页面。静态元素可以用HTML来编写，并且动态元素可以用模板语言来编写。文件中的模板语言元素可以充当占位符，以使得文件中的代码被编译并且发送到客户设备150，并且然后模板语言诸如在安装主题时被来自在线商店138的数据替换。模板和主题可以考虑标签、对象和过滤器。客户端设备Web浏览器（或其他应用）然后相应地呈现页面。

[0022] 在实施例中，电子商务平台100可以向客户提供在线商店138，在这里，客户可以浏览和购买各种可用的产品（例如，将它们添加到购物车中，通过购买按钮来立即购买等等）。可以以透明的方式向客户提供在线商店138，而客户不一定意识到它是通过电子商务平台
100提供的（而不是直接从商家提供的）。商家可以使用商家可配置的域名、可定制的HTML主题等等来定制其在线商店138。商家可以通过主题系统来定制其网站的外观和感觉，诸如商家可以在其中通过改变其主题来选择和改变其在线商店138的外观和感觉，同时使相同的基础产品和业务数据被示出在在线商店的产品层次结构内。可以通过主题编辑器来进一步定制主题，主题编辑器是一种设计界面，其使得用户能够灵活地定制其网站的设计。还可以使用主题特定的设置来定制主题，这些设置可以改变诸如具体颜色、字体和预构建的布局方案之类的方面。在线商店可以实现针对网站内容的内容管理系统。商家可以撰写博客帖子或静态页面，并且将它们发布到其在线商店138，诸如通过博客、文章等等发布，以及配置导航菜单。商家可以将图像（例如，产品的图像）、视频、内容、数据等等上传到电子商务平台
100，诸如以供系统来存储（例如，作为数据134来存储）。在实施例中，电子商务平台100可以提供用于调整图像大小、将图像与产品相关联、添加文本并将文本与图像相关联、为新产品变型添加图像、保护图像等等的功能。

[0023] 如本文中所描述的，电子商务平台100可以通过电话以及通过本文中所描述的物理POS设备152、通过包括在线商店138的多个不同渠道110A-B来向商家提供产品的交易设施。电子商务平台100可以包括与运行在线业务相关联的业务支持服务116、管理员114等等，该运行在线业务诸如是提供与其在线商店相关联的域服务118、用于便于与客户的交易的支付服务120、用于为所购买的产品提供客户运输选项的运输服务122、与产品保护和责任、商家账单相关联的风险和保险服务124等等。可以经由电子商务平台100或与外部设施相关联地提供服务116，诸如通过用于支付处理的支付网关106、用于加快产品运输的运输提供商112等等来提供服务。

[0024] 在实施例中，电子商务平台100可以提供集成的运输服务122（例如，通过电子商务平台运输设施或通过第三方运输承运者），诸如向商家提供实时更新、跟踪、自动费率计算、批量订单准备、标签打印等等。

[0025] 图2描绘了管理员114的主页的非限制性实施例，该主页可以示出关于日常任务、商店的最近活动，以及商家可以采取以构建其业务的下一步的信息。在实施例中，商家可以经由商家设备102（诸如，从台式计算机或移动设备）登录到管理员114，并且管理其在线商店138的各方面，诸如查看在线商店138的最近活动、更新在线商店138的目录、管理订单、最近访问活动、总订单活动等等。在实施例中，商家可以能够通过使用侧边栏来访问管理员114的不同部分，诸如图2上所示。管理员114的部分可以包括用于访问和管理商家业务的核心方面（包括订单、产品、客户、可用的报告和折扣）的各种界面。管理员114还可以包括用于管理商店的销售渠道的界面，该渠道包括在线商店、使客户可以访问该商店的（一个或多个）移动应用（移动App）、POS设备和/或购买按钮。管理员114还可以包括用于管理安装在商家账户上的应用（App）的界面；被应用于商家的在线商店138和帐户的设置。商家可以使用搜索栏来查找产品、页面或其他信息。取决于商家正在使用的设备102或软件应用，可以通过管理员114来针对不同的功能启用它们。例如，如果商家从浏览器登录到管理员114，则他们可能能够管理其在线商店138的所有方面。如果商家从其移动设备（例如，经由移动应用）登录，则他们可能能够查看其在线商店138的所有方面或方面的子集，诸如查看在线商店
138的最近活动、更新在线商店138的目录、管理订单等等。

[0026] 可以通过获取报告或指标来查看关于去往商家的在线商店138的商务贸易和访问者的更详细信息，诸如显示针对商家的总体业务的销售概要、针对有效销售渠道的特定销售和参与数据等等。报告可以包括获取报告、行为报告、客户报告、财务报告、市场营销报告、销售报告、自定义报告等等。商家可以能够诸如通过使用下拉菜单来根据不同时间段（例如，天、周、月等等）查看不同渠道110A-B的销售数据。可以为想要商店的销售和参与数据的更详细查看的商家提供概述仪表板。可以提供“家庭指标”部分中的活动提要（activity feed），以说明商家帐户上的活动的概述。例如，通过点击“查看所有最近活动”仪表板按钮，商家可以能够在其帐户上看到更长的最近活动提要。主页可以诸如基于帐户状态、增长、最近的客户活动等等来示出关于商家的在线商店138的通知。可以提供通知以协助商家导航通过如下过程：该过程诸如是捕获支付、将订单标记为已履行、将已完成的订单存档等等。

[0027] 电子商务平台100可以提供通信设施129和相关联的商家接口，以用于提供电子通信和市场营销，诸如利用电子消息传递聚合设施来收集和分析商家、客户、商家设备102、客户设备150、POS设备152等等之间的通信交互，以便聚合并分析该通信，诸如以用于增加提供产品销售的可能性等等。例如，客户可能具有与产品有关的问题，这可能会在客户与商家（或代表该商家的基于自动化处理器的代理）之间产生对话，其中通信设施129分析该交互，并且将关于如何改进销售概率的分析提供给商家。

[0028] 电子商务平台100可以提供金融设施120，以用于诸如通过安全卡服务器环境与客户进行安全金融交易。电子商务平台100可以诸如在支付卡行业数据（PCI）环境（例如，卡服务器）中存储信用卡信息，以协调金融、向商家开账单、在电子商务平台100的金融机构帐户与商家的后备帐户之间实行自动清算所（ACH）转移（例如，在使用资金时）等等。这些系统可能符合萨班斯-奥克斯利法案（SOX），并且具有在其开发和操作中需要的高度勤奋。金融设施120还可以诸如通过资金借贷（例如，借贷资金、现金垫款等等）和提供保险来向商家提供金融支持。另外，电子商务平台100可以提供一组市场营销和合作伙伴服务，并且控制电子商务平台100与合作伙伴之间的关系。它们还可以将新的商家与电子商务平台100连接起来，并且使该新的商家登上电子商务平台100。这些服务可以通过使商家更容易跨电子商务平台100进行工作来实现商家的增长。通过这些服务，可以经由电子商务平台100向商家提供帮助设施。

[0029] 在实施例中，在线商店138可以支持大量独立管理的店面，并且在每天的基础上针对各种产品处理大量的交易数据。交易数据可以包括客户联系信息、账单信息、运输信息、关于所购买的产品的信息、关于所呈现的服务的信息，以及通过电子商务平台100与业务相关联的任何其他信息。在实施例中，电子商务平台100可以将该数据存储在数据设施134中。可以处理交易数据以产生分析132，该分析进而可以被提供给商家或第三方商务实体，该分析诸如提供消费者趋势、市场营销和销售洞察、用于改进销售的建议、客户行为的评估、市场营销和销售建模、欺诈趋势等等，这些信息与在线商务有关，并且通过仪表板界面、通过报告等等来提供。电子商务平台100可以存储关于业务和商家交易的信息，并且数据设施
134可以具有用于增强、贡献、完善和提取数据的许多方式，其中随着时间的推移，收集到的数据可以使得能够改进电子商务平台100的各方面。

[0030] 再次参考图1，在实施例中，电子商务平台100可以被配置有：用于内容管理、任务自动化和数据管理的商务管理引擎136，以使得能够实现对多个在线商店138的支持和服务（例如，与产品、库存、客户、订单、协作、供应方、报告、金融、风险和欺诈等等有关），但是电子商务平台100可以通过应用142A-B来扩展，这些应用使得能够实现对于适应不断增长的各种商家在线商店、POS设备、产品和服务所需的更大灵活性和自定义过程，其中可以在电子商务平台100内部提供应用142A，或从电子商务平台100外面提供应用142B。在实施例中，应用142A可以由提供平台100的同一方或由不同的一方提供。在实施例中，应用142B可以由提供平台100的同一方或由不同的一方提供。商务管理引擎136可以被配置成用于通过诸如通过客户标识符、订单标识符、在线商店标识符等等对功能和数据进行分区（例如，分片）来实现灵活性和可扩缩性。商务管理引擎136可以适应商店特定的业务逻辑，并且在一些实施例中，可以并入管理员114和/或在线商店138。

[0031] 商务管理引擎136包括电子商务平台100的基本或“核心”功能，并且照此，如本文中所描述的，并非支持在线商店138的所有功能都可以适合于被包括在内。例如，用于包括在商务管理引擎136中的功能可能需要超过核心功能阈值，通过该阈值，可以确定该功能是对于商务体验的核心（例如，对于大多数在线商店活动是公共的，诸如跨渠道、管理员界面、商家位置、行业、产品类型等等是共同的）、可跨在线商店138重新使用（例如，可跨核心功能重新使用/修改的功能）、一次仅限于单个在线商店138的情境（例如，实现在线商店“隔离原则”，其中代码应当不能够一次与多个在线商店138进行交互，从而确保了在线商店138不能访问彼此的数据）、提供交易工作量等等。维持对实现哪些功能的控制可以使得商务管理引擎136保持响应，这是由于许多所需的功能要么由商务管理引擎136直接服务，要么通过接口140A-B（诸如，通过其经由至应用142A-B和渠道110A-B的应用编程接口（API）连接的扩展）来启用，其中可以将接口140A提供给电子商务平台100内部的应用142A和/或渠道110A，或者通过接口140B提供给电子商务平台100外面的应用142B和/或渠道110B。通常，平台100可以包括接口140A-B（其可以是扩展、连接器，API等等），该接口140A-B便于与其他平台、系统、软件、数据源、代码等等的连接，以及与它们的通信。这样的接口140A-B可以是商务管理引擎136的接口140A，或更一般地是平台100的接口140B。如果没有给予注意以限制商务管理引擎136中的功能，则响应性可能会通过以下方式受到损害，这些方式诸如是通过基础设施降级、通过慢的数据库或非关键后端故障、通过灾难性基础设施故障（诸如，在数据中心离线的情况下）、通过部署了需要比预期的时间更长的时间来执行的新代码等等。为了防止或减轻这些情况，商务管理引擎136可以被配置成维持响应性，诸如通过利用超时、队列、反压来防止降级等等的配置。

[0032] 尽管对在线商店数据进行隔离对于维持在线商店138与商家之间的数据隐私是重要的，但是可能存在针对收集和使用跨商店数据的原因，诸如例如利用订单风险评估系统或平台支付设施，其两者都需要来自多个在线商店138的信息以良好地实行。在实施例中，可能优选的是将这些组件移出电子商务管理引擎136并且移入电子商务平台100内的它们自己的基础设施中，而不是违反隔离原则。

[0033] 在实施例中，电子商务平台100可以提供平台支付设施120，其是利用来自商务管理引擎136的数据但是可以位于外面以便不违反隔离原则的组件的另一示例。平台支付设施120可以允许与在线商店138交互的客户通过商务管理引擎136而使他们的支付信息被安全地存储，使得他们仅需要输入一次即可。当客户访问不同的在线商店138时，即使他们之前从未去过那里，平台支付设施120也可以回想起他们的信息以使得能够实现更快速和正确的结账。这可以提供跨平台的网络效果，其中随着更多商家加入，电子商务平台100对于其商家变得更加有用，诸如因为有更多的客户由于相对于客户购买的易用性而更频繁地结账。为了最大化该网络的效果，给定客户的支付信息可以是可从在线商店的结帐中检索，从而允许使信息跨在线商店138是全局可获得的。对于每个在线商店138，能够连接到任何其他在线商店138来检索在那里存储的支付信息将是困难的并且容易出错。结果，可以在商务管理引擎136外部实现平台支付设施。

[0034] 对于商务管理引擎136中未包括的那些功能，应用142A-B提供了一种向电子商务平台100添加功能的方式。应用142A-B能够访问和修改商家的在线商店138上的数据，通过管理员114实行任务，通过用户界面（例如，其通过扩展/API而露出）为商家创建新的流程等等。可以使得商家能够通过应用搜索、推荐和支持128来发现并安装应用142A-B。在实施例中，核心产品、核心扩展点、应用和管理员114可以被开发成一起工作。例如，可以在管理员114内部构建应用扩展点，使得可以借助于应用来扩充核心功能，这些应用可以通过扩展来向商家递送功能。

[0035] 在实施例中，应用142A-B可以通过接口140A-B向商家递送功能，诸如其中应用142A-B能够向商家露出交易数据（例如，App：“引擎，使用嵌入式app SDK来在移动和Web管理员中露出我的app数据”），和/或其中商务管理引擎136能够要求该应用按需求实行工作（引擎：“App，给我针对该结账的本地税费计算”）。

[0036] 应用142A-B可以支持在线商店138和渠道110A-B，提供商家支持，与其他服务集成等等。在商务管理引擎136可以向在线商店138提供服务的基础的情况下，应用142A-B可以为商家提供一种用以满足特定且有时是独特的需要的方式。不同的商家将具有不同的需要，因此可以受益于不同的应用142A-B。可以通过如下方式来经由电子商务平台100更好地发现应用142A-B：通过应用分类法（类别）的开发，该应用分类法使得能够根据其针对商家实行的功能的类型来标记应用；通过支持搜索、排名和推荐模型的应用数据服务；通过应用发现界面，诸如应用商店、家庭信息卡、应用设置页面；等等。

[0037] 应用142A-B可以通过接口140A-B连接到商务管理引擎136，诸如利用API以将通过商务管理引擎136以及在商务管理引擎136内可用的功能和数据暴露给应用的功能（例如，通过REST、GraphQL等等）。例如，电子商务平台100可以向面向商家和合作伙伴的产品和服务提供API接口140A-B，诸如包括应用扩展、过程流服务、面向开发者的资源等等。随着客户更频繁地使用移动设备来进行购物，与移动使用相关的应用142A-B可能会受益于API的更广泛使用，以支持相关的不断增长的商务流量。通过使用应用和API提供的灵活性（例如，如针对应用开发提供的灵活性）使得电子商务平台100能够更好地适应商家（以及通过内部API的内部开发者）的新的和独特的需要，而无需不断更改商务管理引擎136，因此在商家需要的时候向商家提供他们需要的东西。例如，运输服务122可以通过运输或承运者服务API与商务管理引擎136集成，因此使得电子商务平台100能够提供运输服务功能，而不直接影响在商务管理引擎136中运行的代码。

[0038] 可以通过让合作伙伴通过应用开发来改进和扩展商家工作流程来解决许多商家问题，诸如与后台操作（面向商家的应用142A-B）相关联的问题和在线商店138（面向客户的应用142A-B）中的问题。作为开展业务的一部分，许多商家将在每天的基础上使用与移动和Web相关的应用以用于后台任务（例如，推销、库存、折扣、履行等等）和在线商店任务（例如，与他们的在线商店有关的应用，以用于快速销售、新产品提供等等），其中通过扩展/API 140A-B，应用142A-B有助于商品在快速增长的市场中易于查看和购买。在实施例中，合作伙伴、应用开发者、内部应用设施等等可以被提供有软件开发工具包（SDK），诸如通过在管理员114内创建将应用接口沙盒化的框架。在实施例中，管理员114可能没有控制权，也可能不知道该框架内发生了什么。SDK可以与用户界面工具包结合使用，以产生模仿电子商务平台
100的外观和感觉的界面，诸如充当电子商务管理引擎136的扩展。

[0039] 利用API的应用142A-B可以按需求拉取数据，但是它们也经常需要在更新发生时推送数据。更新事件可以在订阅模型中实现，该订阅模型诸如例如是客户创建、产品更改或订单取消。更新事件可以向商家提供关于商务管理引擎136的改变的状态的所需更新，诸如用于同步本地数据库，通知外部集成合作伙伴等等。更新事件可以启用该功能，而不必一直轮询商务管理引擎136以针对更新进行检查，诸如通过更新事件订阅进行检查。在实施例中，当发生与更新事件订阅有关的改变时，商务管理引擎136可以发布请求，诸如发布到预定义的回调URL。该请求的主体可以包含对象的新状态以及动作或事件的描述。可以在管理员设施114中手动创建、或者（例如，经由API 140A-B）自动地创建更新事件订阅。在实施例中，更新事件可以根据触发它们的状态改变而被排队和异步处理，这可能产生未实时分发的更新事件通知。

[0040] 在实施例中，电子商务平台100可以提供应用搜索、推荐和支持128。应用搜索、推荐和支持128可以包括：开发者产品和工具，以帮助应用、应用仪表板的开发（例如，以便向开发者提供开发界面，向管理员提供以用于管理应用，向商家提供以用于定制应用等等）；用于安装和提供关于提供对应用142A-B的访问的许可（例如，用于公共访问，诸如在安装之前必须满足准则的情况下，或供商家私人使用）；应用搜索，以便使商家易于针对满足其在线商店138需要的应用142A-B进行搜索；应用建议，以向商家提供关于他们可以如何通过其在线商店138来改进用户体验的建议；商务管理引擎136内的核心应用能力的描述等等。这些支持设施可以被由任何实体实行的应用开发利用，该实体包括开发他们自己的应用
142A-B的商家，开发应用142A-B的第三方开发者（例如，由商家签约，他们自行开发以向公众提供，签约以便与电子商务平台100相联系地使用等等）、或由与电子商务平台100相关联的内部个人资源开发的应用142A或142B。在实施例中，可以向应用142A-B指派应用标识符（ID），诸如用于链接到应用（例如，通过API）、针对应用进行搜索、做出应用推荐等等。

[0041] 商务管理引擎136可以包括电子商务平台100的基础功能，并且通过API 140A-B向应用142A-B暴露这些功能。API 140A-B可以启用通过应用开发构建的不同类型的应用。应用142A-B可以能够满足商家的很多种需求，但是可以大致被分组成三个类别：面向客户的应用、面向商家的应用、集成应用等等。面向客户的应用142A-B可以包括在线商店138或渠道110A-B，它们是其中商家可以列出产品并且使这些产品被购买的地方（例如，在线商店、用于快速销售的应用（例如，商家产品或来自第三方来源的机会性销售机会）、移动商店应用、社交媒体渠道、用于提供批发购买的应用等等）。面向商家的应用142A-B可以包括如下应用：该应用允许商家管理其在线商店138（例如，通过与web或网站有关的应用或者与移动设备有关的应用）、运行其业务（例如，通过与POS设备有关的应用）、使其业务增长（例如，通过与运输（例如，直接运输）有关的应用、使用自动化代理、使用过程流开发和改进）等等。集成应用可以包括提供参与业务运行的有用集成的应用，诸如运输提供商112和支付网关。

[0042] 在实施例中，应用开发者可以使用应用代理，以便从外面的位置获取数据并且将其显示于在线商店138的页面上。这些代理页面上的内容可以是动态的，是能够被更新的等等。应用代理对于显示图像库、统计信息、自定义表单和其他种类的动态内容可能是有用的。电子商务平台100的核心应用结构可以允许在应用142A-B中构建增加数量的商家体验，以使得商务管理引擎136可以保持专注于更加常用的商务贸易的业务逻辑。

[0043] 电子商务平台100通过策划的系统架构提供在线购物体验，该架构使得商家能够以灵活且透明的方式与客户连接。通过实施例示例购买工作流程可以更好地理解典型的客户体验，其中客户在渠道110A-B上浏览商家的产品，将他们打算购买的商品添加到他们的购物车，进行结账，并且针对他们购物车的内容进行支付，从而为商家创建了订单。商家然后可以回顾并且履行（或取消）该订单。然后将产品递送给客户。如果客户不满意，他们可能会将产品退还给商家。

[0044] 在示例实施例中，客户可以在渠道110A-B上浏览商家的产品。渠道110A-B是客户可以查看和购买产品的地方。在实施例中，渠道110A-B可以被建模为应用142A-B（可能的例外是在线商店138，其被集成在商务管理引擎136内）。推销组件可以允许商家描述他们想要销售什么以及在哪里销售它们。产品与渠道之间的关联可以被建模为产品公布，并且由渠道应用（诸如，经由产品清单API）来访问。产品可以具有许多选项（比如大小和颜色），并且具有许多变型，这些变型将可用的选项扩展成所有选项的特定组合，比如超小和绿色的变型，或大尺寸和蓝色的变型。产品可以具有至少一个变型（例如，针对没有任何选项的产品创建了“默认变型”）。为了便于浏览和管理，可以将产品分组成集合、所提供的产品标识符（例如，库存单位（SKU））等等。可以通过要么将产品手动分类成一个集合（例如，自定义集合）、要么通过构建用于自动分类的规则集（例如，智能集合）等等来构建产品的集合。产品可以通过虚拟或增强现实界面等等而被视为2D图像、3D图像、旋转视图图像。

[0045] 在实施例中，客户可以将他们打算购买的东西添加到他们的购物车（在替换的实施例中，可以直接购买产品，诸如通过本文中所描述的购买按钮）。客户可以将产品变型添加到他们的购物车中。购物车模型可能是渠道特定的。在线商店138购物车可以由多个购物车行项目组成，其中每个购物车行项目跟踪产品变型的量。商家可以使用购物车脚本来基于其购物车的内容向客户提供特殊促销。由于将产品添加到购物车并不意味着来自客户或商家的任何承诺，并且购物车的预期寿命可能是大约几分钟（不是几天），因此购物车可以存留到临时数据存储中。

[0046] 然后，客户进行结帐。结帐组件可以将Web结帐实现为面向客户的订单创建过程。可以提供结帐API作为某些渠道应用所使用的面向计算机的订单创建过程，以代表客户（例如，针对销售点）创建订单。结帐可以从购物车中创建，并且记录客户的信息，诸如电子邮件地址、账单和运输详细信息。在结帐时，商家承诺进行定价。如果客户输入了他们的联系信息但是没有进行支付，则电子商务平台100可以提供与客户重新接合的机会（例如，在被抛弃的结账特征中）。由于这些原因，结帐具有的寿命可能比购物车更长（数小时或甚至数天），并且因此是持续的。结帐可以基于客户的运输地址来计算税费和运输成本。结帐可以将税费的计算委托给税费组件，而将运输成本的计算委托给递送组件。定价组件可以使得商家能够创建折扣代码（例如，“秘密”字符串，当其被录入在结帐栏上时，会将新价格应用于结帐栏中的项目）。商家可以使用折扣来吸引客户，并且评估市场营销活动的表现。折扣和其他自定义价格系统可以在同一平台块的顶部上实现，诸如通过价格规则（例如，被满足就意味着一组应享权利的一组先决条件）。例如，该先决条件可以是诸如“订单小计大于100美元”或“运输成本低于10美元”之类的项目，并且该应享权利可以是诸如“对整个订单的
20％折扣”或“产品X、Y和Z减10美元”之类的项目。

[0047] 然后，客户为他们购物车的内容进行支付，从而为商家创建了订单。渠道110A-B可以使用商务管理引擎136来使钱、货币或价值贮藏（诸如，美元或加密货币）在客户和商家之间往返移动。与各种支付提供商（例如，在线支付系统、移动支付系统、数字钱包、信用卡网关等等）的通信可以在支付处理组件内实现。可以通过卡服务器环境来提供与支付网关106的实际交互。在实施例中，支付网关106可以接受国际支付，诸如与领先的国际信用卡处理器集成。卡服务器环境可以包括卡服务器应用、卡接收器、托管字段等等。该环境可以充当敏感信用卡信息的安全网守。在实施例中，大多数过程可以由支付处理工作来编排（orchestrate）。商务管理引擎136可以支持许多其他支付方法，诸如通过异地支付网关106（例如，其中将客户重定向到另一网站）、手动地（例如，现金）、在线支付方法（例如，在线支付系统、移动支付系统、数字钱包、信用卡网关等等）、礼品卡等等。在结帐过程结束时，创建了订单。订单是商家与客户之间的销售合同，其中商家同意提供订单上列出的商品和服务（例如，订单行项目、运输行项目等等），并且客户同意提供支付（包括税费）。该过程可以在销售组件中建模。不依赖于商务管理引擎136结帐的渠道110A-B可以使用订单API来创建订单。一旦创建了订单，就可以经由通知组件将订单确认通知发送给客户，并且将已下订单的通知发送给商家。可以在支付处理工作开始时预定库存以避免过度销售（例如，商家可以通过每个变型的库存策略来控制该行为）。库存预定可以具有短的时间跨度（数分钟），并且可能需要是非常快速且可扩缩的，以支持闪速销售（例如，在短时间内提供的折扣或促销，诸如针对冲动性购买）。如果支付失败，则释放预订。当支付成功并创建了订单时，预订将被转换成被分配给具体地点的长期库存承诺。库存组件可以记录变型被存放在何处，并且跟踪启用了库存跟踪的变体的量。它可以将产品变型（表示产品清单模板的面向客户的概念）与库存项目（表示其量和位置受管理的项目的面向商家的概念）分离。库存级别组件可以跟踪可用于销售的已承诺给订单或从库存转移组件（例如，从供应商）传入的量。

[0048] 商家然后可以回顾并且履行（或取消）该订单。回顾组件可以实现业务过程商家的使用，以确保在实际履行订单之前这些订单是适合于履行的。订单可能是欺骗性的、需要验证（例如，ID检查）、具有要求商家等待以确保他们将接收到其资金的支付方法等等。风险和推荐可以存留在订单风险模型中。订单风险可能是由欺诈检测工具生成的、由第三方通过订单风险API提交的等等。在继续履行之前，商家可能需要捕获支付信息（例如，信用卡信息）或等待以接收到支付信息（例如，经由银行转账、支票等等）并且将订单标记为已支付。商家现在可以准备用于递送的产品。在实施例中，该业务过程可以由履行组件来实现。履行组件可以基于库存位置和履行服务将订单的行项目分组成工作的逻辑履行单元。商家可以回顾、调整工作单元并且触发相关的履行服务（诸如当商家将商品拣选并包装在盒子中时所使用的手动履行服务（例如，在商家管理的位置处））、购买运输标签并且输入其跟踪号码，或仅将该项目标记为已履行。自定义履行服务可以发送电子邮件（例如，不提供API连接的位置）。API履行服务可能会触发第三方，其中该第三方应用创建履行记录。传统的履行服务可能会触发从商务管理引擎136到第三方的自定义API调用（例如，由亚马逊进行的履行）。礼品卡履行服务可以提供（例如，生成号码）和激活礼品卡。商家可以使用订单打印机应用来打印装箱单（packing slip）。当该项目被包装在盒子中并且准备好运输、已运输、已跟踪、已递送、被验证为由客户接收到等等时，可以执行履行过程。

[0049] 如果客户不满意，他们可能能够将（一个或多个）产品退还给商家。可以由退还组件来实现商家可能会经历“退售”一个项目的业务过程。退还可以由各种不同的动作组成，诸如：再储存，在这种情况下，已销售的产品实际上又重新回到了该业务并且可再次销售；退款，在这种情况下，从客户收集的钱被部分或全部退还；会计调整，其注明已退还多少钱（例如，包括是否有任何再储存费用，或未退还并留在客户手中的商品）；等等。退还可以表示对销售合同（例如，订单）的改变，并且其中电子商务平台100可以使商家意识到与法律义务（例如，关于税费）有关的合规性问题。在实施例中，电子商务平台100可以使得商家能够跟踪销售合同随时间的改变，诸如通过销售模型组件（例如，仅允许附加的基于日期的分类账，其记录发生在某项目上的与销售有关的事件）来实现。

[0050] 由于已经讨论了电子商务平台100的各方面，因此本公开现在将聚焦于对现有技术方法的简要回顾，随后是用于确定履行选项的方法和系统的实施例的更详细的讨论，随后是在实施例下处理预期订单的示例。

[0051] 在实施例中，预期订单可以是尚未完成的任何潜在交易，并且可以是一个或多个产品的预期购买或预期交易。预期订单可以包括但不限于在如下各项中存在的产品：（i）在线商店138购物车中（诸如，在客户设备150或商家设备102上）；（ii）在实体零售店面处（诸如，在POS设备152上）；（iii）在广告、导言或任何渠道中；或（iv）在其中可以开始交易的其他任何零售、在线、销售或交易位置、渠道或媒介处或在其之中；（v）与浏览或查看产品（诸如，在产品页面上）的预期客户或与查看广告的客户有关；（vi）与客户的历史购买或浏览活动有关；（vii）与社交媒体通信有关；或（vii）与其他非传统交易机会有关。

[0052] 在实施例中，库存位置通常是但不限于可以使或使得产品库存可用或者制作或制造产品库存的供应商、卖方或来源。库存位置可以是实际的砖墙加灰泥式位置（例如，零售商店或仓库），它可以由商家操作或控制，或者可以是对商家的第三方，诸如第三方物流或产品提供商，或者它可以是可以从中获得产品的逻辑来源（例如，另一在线来源），其具有将产品运输到目的地的能力。在实施例中，库存位置可以能够制作或制造产品（诸如，鞋、计算机和橱柜），可选地利用现场的产品组件和劳力，或者替换地，库存位置还可以具有内部或外部产品来源（例如，外包、直接运输等等），并且针对这种位置的库存评估可以考虑可以制作或制造的产品（诸如，通过考虑可用的组件、部分和劳力），而不仅仅考虑该位置处存在的产品。

[0053] 在实施例中，库存信息可以包括但不限于：在一个或多个库存位置处的（一个或多个）产品的可得性、量和状况（例如，新的、翻新的、用过的（可能利用比如新的、一般的（fair）和差的状况的描述）等等）。库存信息可以在电子商务平台100的内部或外部获得，并且可以通过数据库查找、应用编程接口（API）调用或其他计算操作来获取。库存信息可能会考虑针对特定应用或产品实时地或在即时（just-in-time）实践或其他时间框架下为预期交易或完成的交易来创建、制造或以其他方式获得的产品。

[0054] 在实施例中，运输提供商可以是提供运输服务的运输承运者（例如，UPS、FedEx、平台100的运输能力等等），但是它也可以是能够将产品运送、递送或呈现给指定目的地的任何一方。

[0055] 在实施例中，运输信息可以包括但不限于：可用的运输提供商、可用的运输服务（例如，一天、两天、空运、陆运等等）。它还可能包括重量、尺寸、尺寸重量、超尺寸考虑因素、处理时间、运输时间、运输成本、约束、处理说明、保险、递送/验收证明考虑因素、海关考虑因素、统一商品说明和编码系统或HTS考虑因素、税费考虑因素、起点和目的地考虑因素，以及与产品到目的地的履行、运送、呈现或递送有关的其他信息。运输信息还可以包括关于下载（诸如，针对数字或电子产品）、货运、拾取、安装或自定义或用于履行或递送产品的其他布置的信息。运输信息可以在电子商务平台100内部或外部获得，并且可以通过数据库查找、API调用或其他计算操作来获取。

[0056] 在实施例中，API可以是在本领域已知的约定定义下的应用编程接口，或者是可以允许两个计算设备或系统交换诸如库存信息或运输信息之类的信息的任何软件、平台或通信部件。例如，运输提供商可以具有API，以允许其客户和其他方检索运输费率以及与其产品和服务提供有关的其他信息。因此，电子商务平台100可以经由运输提供商的API从运输提供商请求针对给定预期运输的信息，并且从电子商务平台100到运输提供商的这种请求可以是API调用。在这样的示例中，当运输提供商响应所做出的电子商务平台100 API调用时，则回复可以是API响应。类似地，库存位置可以具有用于证明库存信息（诸如，产品的可得性和状况）的API。

[0057] 在实施例中，履行选项通常可以包括但不限于包含库存信息、运输信息，以及用以描述向目的地或客户递送或提供产品而必要的其他信息。履行选项可以是一组运输费率，其范围从无运输费率到单个运输费率、到多个运输费率。履行选项还可以包括数字下载、许可证转让、货运、在商店或给定地点中的拾取或本地递送，以及针对产品的任何其他履行选项。一个或多个推荐的履行选项或推荐的选项可以从对针对可用履行选项的优先级基础的确定中得出。如果一组履行选项中没有运输费率，则推荐的选项可以被视为没有可用的履行选项。

[0058] 在实施例中，优先级基础可以基于各种因素来确定一个或多个推荐的履行选项，该各种因素诸如是：最低的运输成本、最快的递送时间、最短的地理距离（例如，库存起点与目的地之间）、与用户有关的考虑因素、用户指定的偏好、与客户有关的考虑因素、客户指定的偏好、与商家有关的考虑因素、商家指定的偏好、与对于交易的附加方和相关偏好有关的信息、履行成本（诸如，包括库存位置处的劳力成本）、电子商务平台100考虑因素（例如，内部运输或最低处理成本、处理考虑因素等等）或其他履行考虑因素。

[0059] 在实施例中，递送简档可以包括关于产品的信息，诸如库存可以位于其中的库存位置（例如，中国、日本、巴黎等等）、产品的可得性（例如，库存数量）、库存状况（例如，新的、翻新的、用过的等等）、用以递送该产品的地理递送区（例如，美国、法国、南非、国家的子集、区域等等）、可以将产品递送到递送区中的位置的运输提供商（例如，UPS、FedEx等等）、通过相应运输提供商可用的运输服务（例如，通宵、两天、空运、陆运等）、针对这些服务的运输费率（可能地考虑到要运输的给定产品的详细信息），以及相关产品、重量、尺寸、尺寸重量、库存、运输、跨境、海关、与关税或税费有关的信息（例如，HTS代码）或其他信息。递送简档可以存储在电子商务平台100中的递送简档数据库中的递送简档记录中，尽管递送简档也可以以其他形式、结构、数据库或经由网络通信等等而可获得。

[0060] 在实施例中，当存在预期订单时，可以在电子商务平台100呈现履行选项之前完成若干个步骤。可以确认产品的可用库存是否满足预期订单的分配（例如，量）。可以确认可用的运输服务、时间和费率，以确保可以将产品及时递送到目的地。如果可以以响应迅速、清晰的方式向客户呈现这种履行选项，则会改进客户体验，由此导致使客户满意度更高，增加预期订单到已完成的交易的转换，以及最终增加电子商务平台100的市场份额和收入。

[0061] 传统上，在现有技术的在线零售商提供针对购物车中的项目的可用库存和估计的运输成本之前，在线零售商会通过众多供应商/供应方进行迭代，以便：（1）标识（一个或多个）产品的一个或多个供应商；（2）确认可用库存；（3）标识可以将产品从（一个或多个）供应商递送到目的地的一个或多个运输提供商；以及（4）确定各种运输时间和对应的运输成本。

[0062] 这些标识可用库存来源的第一步通常是：通过以供应商为中心的数据库迭代地检查供应商来确定在哪里有足够的产品库存可用。作为示例，这是一个串行过程，在该过程中，一个接一个地进行数据库查找、通信或API调用，直到已经穷尽了供应商列表为止。

[0063] 类似地，还基于所标识的具有可用库存的供应商来迭代地实行用于标识运输提供商以及检查选项和费率的随后步骤。获得运输选项（类似于标识可用库存）通常是通过串行过程来实行的，在该过程中，一个接一个地进行对信息或API调用的请求，直到穷尽了可能性的列表为止。

[0064] 因此，鉴于在将这样的信息传送给客户之前必须进行的迭代过程，许多在线购物经验中的现有技术证明了对填充履行详细信息（例如，运输时间和成本）的缓慢反应时间。该时间流逝可能导致交易的丧失，或者更糟地可能导致客户的丧失。在选择多个产品时、在这样的产品属于不同类别（例如，标准、易腐、易碎、禁止航空等等）时、或者在这样的产品源自于不同区域或国家时，无响应的体验可能会变得甚至是更加混合的。

[0065] 参照图3，示出了用于确定预期订单的履行详细信息的现有技术方法。更具体地说，该过程开始于在步骤300中标识预期订单。

[0066] 在步骤304和306中，传统的网站引擎分别迭代地请求和接收与可用库存有关的库存详细信息。如所指出的，该过程可能会花费大量的时间，其中要进行数百或数千次迭代或循环。一旦利用库存迭代最终完成了传统的在线零售引擎，网站引擎就移动到下一个步骤。

[0067] 类似地，在步骤308和310中，传统的网站引擎针对所标识的库存详细信息分别迭代地请求和接收关于可能的运输布置的运输详细信息。由于运输信息可以并且确实会经常改变，因此对于在线零售商而言，具有准确的运输信息来确定预期订单的履行细节仍然是重要的。再一次，在这种现有技术解决方案中，由于在线零售引擎以串行、顺序的方式迭代地检查（经由请求和接收）运输详细信息，因此该过程是缓慢且低效的。

[0068] 在线零售引擎可能会经由API调用来请求并接收这种运输详细信息。不幸的是，对运输提供商的过多API调用可能会变得昂贵，这是因为运输提供商可能会针对每个API调用而收费，或者在合同上或在技术上，可能仅提供有限数量的API调用，并且向其他API调用收费或禁止其他API调用。过多的API调用也是耗时的，并且会消耗计算资源。可以意识到的是，将对运输提供商的API调用最小化是个合期望的目标。另外，在竞争激烈的在线市场中，很容易由于无响应或不及时的结帐过程而失去交易和客户，而该过程没有迅速地提供具有对应成本的履行选项。

[0069] 一旦迭代步骤304、306、308和310完成，在线零售网站通常就分别在步骤312和314中确定该选项并将其传送给客户。

[0070] 现有技术方法的基本问题之一是：传统的在线零售引擎和数据库是围绕供应商而非产品来构造的。照此，无论是在数据库、信息系统中还是在网络上等等，检索关于由多个供应商销售或多个位置中容纳的产品的信息都成为跨许多供应商来进行搜索的复杂且迭代性的努力，如上所述。

[0071] 在包括多个产品时、在需要多个位置来履行一定量的一个或多个产品时、或者在国际交易引入了海关、国际费用、约束和应当考虑的其他关切时，这些现有技术方法可能变得更加复杂。总之，现有技术的以供应商为中心的数据库不能很好地被配备成以快速或有效的方式确定产品的履行选项，尤其是在产品在多个库存位置中可用的情况下。

[0072] 通过以产品为中心的递送简档数据结构和数据库（诸如，本文中公开的那些），可以实现实质性的改进和效率。在最高级别处，不是如现有技术方法中所证明的那样通过以供应商为中心的方法的迭代和解析，本文中公开的实施例利用以产品为中心的递送简档，该简档可以存储在递送简档数据库中以便检索关于产品及其履行选项的信息。

[0073] 图4图示了利用递送简档来确定履行选项的实施例。该过程开始于在步骤400中标识预期订单。该预期订单可以标识一个或多个产品以及一个或多个产品的目的地。替换地，该预期订单可以标识多个产品的不同目的地。

[0074] 步骤402可以从递送简档数据库中的递送简档记录中检索递送简档。递送简档是以产品为中心的并且特定于产品，并且可以提供关于库存位置、递送区、运输服务和运输费率的初步信息。在某些情况下，这样的初步信息对于确定履行选项的目的而言可以是足够的。

[0075] 在其他情况下，与现有技术的迭代步骤304和306相比，这样的初步信息可以优化并加速步骤404和406。不是迭代地逐句通过供应商数据库或供应商网络来针对产品的可用库存进行逐供应商的搜索（如现有技术中说明的那样），实施例受益于初步信息以优化对于针对库存信息的请求或针对运输信息的请求的确定。因此，步骤404和406通常仅需要请求关于在递送简档中找到的库存位置的库存信息，与现有技术逐供应商的迭代方法相比，这导致仅花费了一小部分时间和资源。

[0076] 在实施例中，为了进一步优化步骤404和406，一旦该需要被确定，即库存信息请求变得必要或有用，就可以优选地发起、执行或做出库存信息请求。照此，取决于何时做出关于这种库存信息请求的必要性或实用性的确定，可以尽可能快地、或者在没有延迟的情况下、或者并行地而不是以串行顺序的次序做出多个库存信息请求。作为示例，如果产品最初被预计（例如，经由递送简档中的信息）在电子商务平台100中的四个库存位置处可获得，则可以针对所有四个库存信息请求（而不是其他无关请求）来立即执行用于请求库存信息的步骤404。可以对电子商务平台100内部和外部两者的库存位置都做出库存信息请求。

[0077] 在步骤406中，响应于步骤404，可以在单个迭代/循环（而不是现有技术示例的数百、数千或更多个迭代/循环）的过程中，从库存位置接收对应的库存信息。

[0078] 可以类似地经由递送简档所提供的初步信息以及从步骤406接收到的库存信息（如果这样被请求和接收的）来类似地优化和加速步骤408和410。例如，在实施例中，如果从步骤406接收到的库存信息指示产品的库存从递送简档中的一个或多个库存位置不可获得，则可以从另外的处理或考虑因素中省略或忽略这样的库存位置。更特别地，针对基于库存信息响应而被确定为没有可用库存的库存位置，不需要发起运输信息请求。

[0079] 与库存信息请求类似，在实施例中，为了进一步优化步骤408和410，一旦该需要被确定，即运输信息请求变得必要或有用，就可以优选地发起、执行或做出运输信息请求。预期订单可以具有实际的目的地地址（例如，客户已登录并且地址被指定，或者目的地地址是以其他方式已知的），或者预期订单可能具有预测的或推断的目的地地址。例如，如果实际的目的地地址是未知的，则可能有必要基于历史购买或与预期订单有关的活动的位置（例如，具有购物车结帐屏幕的客户设备150的IP地址，或客户设备150提供的GPS信息等等）来预测目的地地址。如果存在多个预测的目的地地址，则可以对多个预测的目的地地址中的全部或选集做出运输信息请求。

[0080] 照此，取决于何时做出关于这种运输信息请求的必要性或实用性的确定，可以尽快地、或者在没有延迟的情况下、或者并行地而不是以串行顺序的次序做出多个运输信息请求。作为示例，如果履行选项最初被预计（例如，经由递送简档中的信息）为从三个运输提供商可获得，则可以针对所有三个运输信息请求（而不是其他无关请求）来立即执行用于请求运输信息的步骤408。在步骤410中，响应于步骤408，可以在单个迭代/周期（而不是现有技术示例的众多迭代/周期）的过程中，从运输提供商接收对应的运输信息。

[0081] 在步骤412中，倘若存在至少一个履行选项，则可以基于优先级基础（例如，最低的运输成本）做出确定，以基于可用的履行选项来确定一个或多个推荐选项。如所指出的，推荐选项可以是单个推荐选项或多个推荐选项。在其他情况下，在没有可用的履行选项或运输费率适用于与目的地相对应的递送区的情况下，就没有推荐选项是可用的。

[0082] 在步骤414中，可以将在步骤412中确定的推荐选项传送给客户。与客户的通信可以经由客户设备150（例如，在网页的屏幕上（诸如，在产品页面上，可能地与支付按钮相关，或与购物车相关）、在智能电话上、经由文本消息或电子邮件，或电子商务平台100与客户之间的几乎任何通信手段）。在实施例中，步骤414中的通信可以作为完成的交易被传送到客户设备150，其中预期订单被转换为完成的交易。

[0083] 在实施例中，在产品被更新（例如，新产品被放置在购物车中）或在接收到新的、最新的或更新的信息（例如，来自API调用的最新的API响应）时，可以重新访问步骤412和414以重复对推荐选项的确定，并且将推荐选项传送给客户。

[0084] 参考图5，逻辑图图示了用于利用递送简档来确定履行选项的实施例架构。如所图示的，可以在电子商务平台100内部实现递送简档数据库510和递送简档分析器520。替换地，递送简档数据库510或递送简档分析器520可以位于或被配置在电子商务平台100的外部。

[0085] 在实施例中，库存位置530可以在电子商务平台100的内部或外部，如在电子商务平台100内部和外部的图上的库存API调用的替代放置所图示的那样。作为示例，但不限于：对于针对预期订单的来源库存的库存位置可以在电子商务平台100的内部或外部，包括零售位置、仓库、制造位置（例如，即时或按需制造）、其他物理产品位置或其他逻辑产品来源（例如，外包、直接运输等等）。更特别地，库存位置530被示出为具有在电子商务平台100外面的库存API 532和库存API 534，而库存API 536被图示为在电子商务平台100内部。

[0086] 在实施例中，运输提供商540也可以在电子商务平台100内部或外部，如在电子商务平台100内部和外面的图中的API调用的替代放置所图示的那样。更特别地，运输提供商530被示出为具有在电子商务平台100外部的运输API 542和运输API 544，而运输API 546被图示为在电子商务平台100内部。

[0087] 在实施例中，递送简档数据库510可以包括多个递送简档记录，诸如递送简档512、递送简档514、递送简档516和递送简档518。作为示例，这些递送简档中的每一个都可以对应于可用于在电子商务平台100上购买的具体产品。

[0088] 当电子商务平台100要确定产品的履行选项（例如，要确定可用库存和运输选项）时，可以从递送简档数据库510中检索对应的递送简档。在本图所图示的示例中，递送简档分析器520检索并分析递送简档514。

[0089] 在实施例中，递送简档分析器520实行步骤402，以从递送简档数据库510中检索递送简档514。递送简档514可以包含用以确定履行选项的以产品为中心的有关信息，诸如初步库存位置、递送区、运输服务、运输费率以及为预期订单取得履行选项所需的其他信息。

[0090] 在实施例中，递送简档分析器520可以被并入电子商务平台100中（如图示的）或者在电子商务平台的外部。递送简档分析器520可以被并入现有的硬件或软件中，或者可以包括专用的硬件或软件以实行本文中描述的步骤和动作中的全部或子集。递送简档分析器520可以负责API调用（例如，对运输提供商的运输信息请求）或将该任务委托给位于电子商务平台100的内部或外部的其他软件或硬件。递送简档分析器520可以被配置成使用特定的算法或公式来从履行选项中确定推荐选项；或者，它可以替换地被配置成使用数据来学习和实现优先级基础（诸如，通过机器学习技术）。

[0091] 在检索步骤402之后，在实施例中，递送分析器520利用来自递送简档514的信息，来从指定的库存位置530请求库存信息，如步骤404所指出的。这些库存信息请求被图示为库存API 532、库存API 534和库存API 536。响应于库存API 532-536请求，库存信息响应可以由递送简档分析器520接收，如由双箭头图示的（返回到请求者）。

[0092] 一旦递送简档分析器520已经经由库存API 532-536确认了产品的可得性，则它可以省略或忽略其中没有库存可用的另外的处理库存位置。此后，递送简档分析器520可以利用库存信息来确定将被请求的运输信息请求。

[0093] 这些运输信息请求被图示为运输API 542、运输API 544和运输API 546。响应于运输API 542-546请求，运输信息响应可以由递送简档分析器520接收，如由双箭头图示（返回到请求者）。

[0094] 在实施例中，预期订单可以具有源自于多个库存来源的多个运输，由此需要考虑履行选项的多个组合。例如，预期订单：（i）可以具有多个产品（并且因此可以具有多个递送简档），或者（ii）可以具有多个量的相同产品，但是来自不同的库存起点（例如，来自不同库存位置的不同颜色/子产品单位，在任何一个位置处库存不足等等）。在这些情况下，由于多次运输对于该预期订单是必要的，因此递送简档分析器520可以创建运输费率的不同组合以创建履行选项。

[0095] 例如，假设性预期订单可以是针对第一产品A和第二产品B的，而这两种产品都是从不同的库存位置运输的。产品A可以具有若干个可用运输费率（例如，30美元的隔夜服务，以及10美元的陆运服务），并且产品B可以具有若干个运输费率（例如，12美元的优先服务，以及5美元的陆运服务）。从计算的角度来看，许多不同的组合都是可能的，并且可以将这些组合创建为履行选项，而无论这些履行选项是否最终被传送给客户。例如，可以从可能的最快递送（例如，隔夜服务和优先服务）、到类似命名/指定的服务（例如，陆运服务等等）、到最低成本的服务来创建组合，或者基于可以用作用于创建履行选项的组合的方式的其他因素来创建组合。在上面的示例中，运输费率的可能组合可以是：（i）经由隔夜服务来运输产品A、以及通过优先服务来运输产品B的最快递送时间，总运输成本达42美元；（ii）经由陆运服务来运输产品A和产品B的最低成本（或类似命名的服务），总运输成本达15美元；（iii）经由隔夜服务来运输产品A但是为了成本节省而经由陆运服务来运输产品B的混合费率/服务，成本总计为35美元；或者（iv）通过陆运服务来运输产品A、以及通过优先服务来运输产品B的混合费率/服务，成本总计为22美元。

[0096] 在其中可以组合多个运输费率以创建预期订单的履行选项的情况下，可以通过使用优先级基础将这些多个履行选项简化为一个或多个推荐选项，以用于传送给客户（例如，经由客户设备）。

[0097] 在实施例中，步骤412可以由递送简档分析器520实行，其中优先级基础被用来确定推荐选项（或多个推荐选项）。在履行选项中不存在运输费率的情况下，可以确定没有可用履行选项的推荐选项。优先级基础可以被配置成用于各种不同的算法或因素，诸如最低的运输成本、最快的递送时间、最低的订单执行成本、用户指定的偏好，或最短的地理距离，或者可以将递送简档分析器520配置成基于所提供的历史数据进行学习。

[0098] 步骤414还可以由递送简档分析器520实行，其中可以将推荐选项或（或多个推荐选项）提供给客户设备150或其他指向客户的通信。

[0099] 转到图6，图示了用于标准产品的递送简档——简档#1和用于易碎产品的递送简档——简档#2，其中每个递送简档分别具有库存位置——位置群组#1和位置群组#2。针对每个相应递送简档的位置群组#1和位置群组#2初步地反映出针对对应产品的库存在这些位置处可能是可获得的。

[0100] 对于每个递送简档——简档#1和简档#2，它们相应的库存位置——位置群组#1和位置群组#2也具有各种递送区，分别被图示为区#1、区#2、区#3、区#4、区#5、区#6、区#7和区#8。区#1至#8标明了可以依照递送简档下的（一个或多个）对应库存位置，可以递送对应产品的位置。出于说明目的，国家已在各个递送区内部列出，但是可以将任何形式的地理、购物、时间、人口统计、逻辑、交易或其他指定实现为递送区，包括但不限于国家的部分、州、城市或其他地理指定，包括具有例外的地理指定（例如，中国但不包括香港）。因此，作为示例，尽管如图示的区#1标明中国、印度尼西亚和日本，但是在替代的假设性实施例中，这样的递送区可以反映排除香港的中国南部，包括印度尼西亚和日本。或者替换地，这样的区在本质上可以关于购物程序（例如，高级订阅或奖励计划）中的成员资格、一年中的时间（例如，非假日季节、每个星期二或类似的）、人口统计（例如，军人折扣）或其他非地理指定而是非地理的。

[0101] 此外，区#1至#8中的每个递送区还具有对应的履行选项，被图示为选项#1、选项#2、选项#3、选项#4、选项#5、选项#6、选项#7和选项#8。。如图示的，选项#1至#8的每个组可以具有多个运输费率，其中每个运输费率可以表示运输提供商（例如，UPS、FedEx等等）、运输服务（例如，隔夜、两天、空运、陆运等等）、运输时间和运输费率。

[0102] 递送简档——简档#1和简档#2的数据结构和数据方案向递送简档分析器520给予了对产品的初步库存位置（例如，位置#1至#2）的快速分析，以及对初步递送区（例如，针对由简档#1表示的产品的区#1至#5、针对由简档#2表示的产品的区#6至#8）的快速分析。递送简档进一步提供了与初步库存位置和递送区相对应的初步运输费率（例如，在选项#1至#8中）。

[0103] 在一些实施例中，由递送简档提供的初步信息可能足以确定履行选项并将其传送给客户设备，而无需针对库存信息或运输信息的另外的请求。例如，基于初步信息，可能不需要库存信息请求和运输信息请求，其中，通常购买的项目始终在某个位置有存货，其具有的履行选项由所确立的至任何目的地的运输费率组成。在这样的示例中，可以仅通过在对应的递送简档中存储的数据来确定履行选项。然而，在其他实施例中，存储在递送简档中的信息用作早期信息或初步信息来源，以通过有针对性的、有效的和快速的库存位置请求和运输信息请求来指导和有效地确认预期订单，这在本文中进一步详细描述。

[0104] 图6中引入的递送简档现在将在实施例中被用于确定图7-10中图示的预期订单的履行选项的特定示例。

[0105] 图7是处理具有两个不同递送简档的两个不同产品的预期订单的实施例的图示。更特别地，标准产品递送简档被图示为简档#1，而易碎产品递送简档被图示为简档#2。作为示例，两种产品都存在于目的地为法国的在线购物车中。法国的一位客户正在查看购物车，并准备好对履行选项的确定。

[0106] 在实施例中，递送简档分析器520可以分析表示标准产品的递送简档——简档#1，并且可以标识两个初步库存位置，位置群组#1和位置群组#2。然而，由于位置群组#1没有到法国的下游递送区，因此递送简档分析器520省略了位置群组#1，并且继续处理表示伦敦POS（销售点）和巴黎仓库的位置群组#2。

[0107] 如描绘的，位置群组2能够运输到覆盖荷兰、法国和比利时的递送区——区#3。递送区#4和区#5与目的地不对应，并且照此从进一步的处理中省略或忽略它们。

[0108] 选项#3反映出费率#4和费率#5作为针对该预期订单的履行选项是可用的。

[0109] 在实施例中，利用从递送简档中检索到的并且被确定为针对第一标准产品的初步履行选项的位置群组#2、区#3和选项#3，可以针对位置群组#2执行库存信息请求，以确认可用库存。如果执行了这样的请求，则可以接收库存信息响应，从而确认针对该标准产品的库存可用或不可用。出于示例的目的，假定库存在位置群组#2处可用，如来自递送简档——简档1的初步信息建议的那样。

[0110] 在已经初步地（经由递送简档）或在确认的基础上（经由库存信息响应）知道库存在位置群组#2处可用的情况下，可以立即执行运输信息请求。如果执行了这样的请求，则可以接收运输信息响应，从而确认运输费率——费率#4和费率#5针对该标准产品是可用的（例如，每个运输费率由以一定运输成本提供运输服务的运输提供商组成）。出于示例的目的，假定这样的运输费率在履行选项#3下是可用的。

[0111] 关于由递送简档——简档#2表示的易碎产品，重复以上示例过程（或者，在实施例中，针对每个产品并行进行该过程）。位置群组#1和位置群组#2可以初步地示出库存，但是只有一个库存位置——位置群组#2会导致至法国的下游递送。照此，递送简档分析器520省略位置群组#1，并且继续处理表示伦敦POS和巴黎仓库的位置群组#2。位置群组#2能够运输到覆盖荷兰、法国、比利时和英国的递送区——区#7。选项#7反映出，在从递送简档中检索到的初步信息中，费率#10和费率#11被标识为履行选项。

[0112] 此后，在简档#2中，类似于针对简档#1的对库存信息请求/响应和运输信息请求/响应的处理，经由费率——费率#10和费率#11来确认履行选项——选项#7。在实施例中，仅当信息未知时才可能需要请求和响应。例如，如果运输费率（例如，某重量下的产品的统一运输费率）是已知的，则不需要任何请求（诸如API请求）。

[0113] 因此，通过递送简档，标准产品初步地被标识为既是可用的也是可递送的，并且此后通过目标库存信息响应和目标运输信息响应而被确认。指出的是，与现有技术方法强加的要求形成对照，迭代的请求和响应不是必需的，并且不会花费大量的时间和资源。

[0114] 在本示例中，仅将一个可能的库存位置（位置群组2）和针对每个产品的一个递送区（区#3和区#7）图示为可用于每个相应产品。然而，递送简档分析器520还可以基于优先级基础来考虑用于运输每个相应产品的哪个库存来源（例如，伦敦POS或巴黎仓库）。由于运输费率——费率#4和费率#5从任一库存来源（伦敦POS或巴黎仓库）到客户是相同的，因此，如果该优先级基础：（i）优先考虑产品是否从同一国家运输；（ii）优先考虑距目的地的较短地理距离；（iii）优先考虑从仓库而不是零售店运输；（iv）优先考虑如商家确立的列表；或（v）类似的其他考虑因素，所配置的优先级基础可以选择巴黎仓库。

[0115] 图8是类似于图7的预期订单的处理的实施例的图示。然而，在该示例中，简档#1图示了单个标准产品，其目的地为美利坚合众国（USA）。

[0116] 类似于图7中的处理细节，递送简档分析器520分析表示标准产品的递送简档——简档#1，并且标识了两个初步库存位置，位置群组#1和位置群组#2。在这种情况下，两个位置都具有至目的地美国的下游递送区。递送简档分析器520继续处理这两个位置。

[0117] 位置群组#1表示印度POS以及在中国和日本的仓库，其中位置群组#2表示伦敦POS和巴黎仓库。位置群组#1图示了具有至加拿大、美国和墨西哥的目的地的下游递送区#2，并且进一步具有在运输费率——费率#2和费率#3的情况下可用的履行选项——选项#2。附加地，位置群组#2图示了具有至加拿大和美国的目的地的下游递送区#4，并且进一步具有在运输费率——费率#6和费率#7的情况下可用的履行选项——选项#4。

[0118] 给定从递送简档——简档#1得出的该初步信息，类似于图7的处理，可以实现库存信息请求/响应和运输信息请求/响应以根据需要来确认库存信息和运输信息。出于本示例的目的，将假定递送简档中的初步信息是准确的，并且通过库存信息响应和运输信息响应进行确认。

[0119] 因此，针对相同产品存在两个履行选项——选项#2和选项#4。在这种情况下，递送简档分析器520现在可以根据两个履行选项——选项#2和选项#4来确定推荐选项，即，基于优先级基础（例如，最低的运输成本）来处理四个运输费率——费率#2、费率#3、费率#6和费率#7。递送简档分析器520可以确定单个推荐选项或多个推荐选项，并且此后（例如，经由客户设备）将一个或多个推荐选项传送给客户。在实施例中，递送简档分析器520可以确定在所选择的库存位置群组中的那些库存位置当中哪个库存位置被推荐。

[0120] 图9是类似于图8的预期订单的处理的实施例的图示。然而，在该示例中，所请求的单个标准产品分配具有很大的量。简档#1类似地图示了该产品，其目的地是美国。

[0121] 图9的处理最初遵循图8的处理，除了如下内容：在接收到库存信息请求和库存信息响应的情况下，确认了在位置群组#2处没有足够的库存。照此，所有预期订单的处理都必须通过位置群组#1进行处理。

[0122] 还指示的库存信息响应（未示出）确认了印度POS不具有库存，并且中国仓库和日本仓库也分别都没有足够的量来履行该预期订单。照此，该产品将需要从中国和日本两者的仓库运输到目的地区#2（如围绕位置群组#1、区#2和选项#2周围的分析的双线图示的）。

[0123] 在该示例中，从递送简档——简档#1得出的初步信息不准确，这是因为递送简档表明位置群组#2可能具有库存，而它实际上没有库存（如由库存信息响应所确认的那样）。因此，可以执行库存信息请求/响应和运输信息请求/响应，以实时确认库存信息和运输信息是准确的。

[0124] 在这种情况下，递送简档分析器520现在将基于优先级基础从两个运输费率——费率#2和费率#3中确定推荐选项，或者替换地，可以被配置成作为多个推荐选项来确定并传送这两个运输费率。

[0125] 图10是处理具有两个不同递送简档的两个不同产品的预期订单的实施例的图示。作为示例，两个产品都存在于目的地为南非的在线购物车中。

[0126] 递送简档分析器520对表示标准产品的递送简档——简档#1进行分析，并且标识了两个初步库存位置——位置群组#1和位置群组#2。然而，由于位置群组#1没有至南非的下游递送区，所以递送简档分析器520省略或忽略了位置群组#1，并且继续处理表示伦敦POS和巴黎仓库的位置群组#2。

[0127] 如所描绘的，位置群组#2能够运输到表示世界其他地方（其他递送区没有表示）的递送区——区#5，因此，在初步地，该标准产品至南非的履行可能地具有运输费率——费率#8。

[0128] 对于简档#2下的易碎产品，可以在相应的位置群组#2下找到库存，但是没有至南非的可用递送区。照此，针对该易碎产品没有可用的履行选项（如虚线图示的，该虚线仅围绕简档#2和位置群组#2）。

[0129] 利用从递送简档中检索到的并且被确定为第一标准产品的初步履行选项的位置群组#2、区#5和选项#5，可以针对位置群组#2执行库存信息请求，以确认可用库存。如果执行了这样的请求，则可以接收到库存信息响应，从而确认库存针对该标准产品可用或不可用。出于示例目的，假定库存在位置群组#2处可用。

[0130] 在已经初步地（经由递送简档）或在确认的基础上（经由库存信息响应）知道库存在位置群组#2处针对该标准产品可用的情况下，可以立即执行运输信息请求。如果执行了这样的请求，则可以接收到运输信息响应，从而确认运输费率——费率#8针对该标准产品可用。出于示例的目的，假定这样的运输费率在履行选项#5内可用。因此，通过递送简档，该标准产品都初步地被标识为可用和可递送，并且此后通过库存信息响应和运输信息响应进行确认。

[0131] 因此，在该示例中，递送简档分析器520可以确定如下内容并将该内容传送到客户或客户设备150：该内容为电子商务平台100可以完成标准产品的履行，但是可能没有完成易碎产品的履行。

[0132] 在本示例中，仅将一个可能的库存位置（位置群组#2）和针对该产品的一个递送区（区#5）图示为可用于标准产品。然而，递送简档分析器520还可以基于优先级基础来考虑用于运输每个相应产品的哪个库存来源（例如，伦敦POS或巴黎仓库）。由于从任一库存来源（伦敦POS或巴黎仓库）到客户的运输费率（费率#8）是相同的，因此，如果所配置的优先级基础：（i）优先考虑距目的地较短的地理距离，或（ii）优先考虑从仓库而不是零售商店运输，或类似的其他考虑因素，该所配置的优先级基础可以选择巴黎仓库。

[0133] 在图7-10中图示的所有上述示例中，从递送简档中检索到的信息或数据可能从未经验证的初步信息到不断更新的近实时数据而变化。因此，如果合期望，则递送简档分析器520可以立即确定并传送履行选项，而没有针对库存信息或运输信息的请求。然而，在遍及本公开所描述的其他实施例中，递送简档分析器520可以选择性地请求库存信息以确认反映在递送简档中的可用库存。同样地，如果认为有必要，递送简档分析器520就可以选择性地请求运输信息，以确认递送简档中反映的运输提供商、运输时间和运输费率。可以取决于特定应用的需要而选择性地、单独地、以批处理格式、以串行顺序、同时并行地或以其他替代时序来实行这样的各样请求。

[0134] 如可以领会的是，实行关于是否在递送简档的检索之后做出信息请求的这种选项，以平衡速度、准确性和对计算资源的利用。在任何预期订单或购物车结帐、或从任何渠道产生的任何预期订单上，无论是实行了针对库存信息的请求还是针对运输信息的请求，本领域技术人员都可以领会到通过利用以产品为中心的数据结构和包含递送简档的递送简档数据库来改进对履行选项的确定所带来的许多好处。

[0135] 可以通过在处理器上执行计算机软件、程序代码和/或指令的机器来部分或全部地部署本文中描述的方法和系统。处理器可以是服务器、云服务器、客户端、网络基础设施、移动计算平台、固定计算平台或其他计算平台的一部分。处理器可以是能够执行程序指令、代码、二进制指令等等的任何种类的计算或处理设备。处理器可以是或可以包括信号处理器、数字处理器、嵌入式处理器、微处理器，或诸如协处理器（数学协处理器、图形协处理器、通信协处理器等等）之类的任何变型等等，它们直接或间接地便于执行存储在其上的程序代码或程序指令。另外，处理器可以使得能够实现多个程序、线程和代码的执行。可以同时执行线程，以增强处理器的性能以及便于应用的同时操作。作为实现方式，可以在一个或多个线程中实现本文中描述的方法、程序代码、程序指令等等。该线程可以产生可能已经被指派了与其相关联的优先级的其他线程；处理器可以基于优先级或基于程序代码中提供的指令的任何其他次序来执行这些线程。处理器可以包括存储器，该存储器存储如本文中以及其他地方所描述的方法、代码、指令和程序。处理器可以通过接口访问存储介质，该存储介质可以存储如本文中以及其他地方所描述的方法、代码和指令。与处理器相关联的、用于存储能够由计算或处理设备执行的方法、程序、代码、程序指令或其他类型的指令的存储介质可以包括但不限于：CD-ROM、DVD、存储器、硬盘、闪存驱动器、RAM、ROM、高速缓存等等中的一个或多个。

[0136] 处理器可以包括可以增强多处理器的速度和性能的一个或多个核。在实施例中，该过程可以是双核处理器、四核处理器、组合了两个或更多个独立的核（叫做管芯）的其他芯片级多处理器等等。

[0137] 可以通过在服务器、云服务器、客户端、防火墙、网关、中枢、路由器或其他这种计算机和/或联网硬件上执行计算机软件的机器来部分或全部地部署本文中描述的方法和系统。该软件程序可以与服务器相关联，该服务器可以包括文件服务器、打印服务器、域服务器、互联网服务器、内联网服务器以及其他变型，诸如辅助服务器、主机服务器、分布式服务器等等。服务器可以包括以下各项中的一个或多个：存储器、处理器、计算机可读介质、存储介质、端口（物理的和虚拟的）、通信设备以及能够通过有线或无线介质访问其他服务器、客户端、机器和设备的接口等等。如本文中以及其他地方所描述的方法、程序或代码可以由服务器执行。另外，执行如本申请中所描述的方法所需的其他设备可以被认为是与服务器相关联的基础设施的一部分。

[0138] 服务器可以向其他设备提供接口，该其他设备包括但不限于：客户端、其他服务器、打印机、数据库服务器、打印服务器、文件服务器、通信服务器、分布式服务器等等。附加地，这种耦合和/或连接可以便于跨网络远程执行程序。这些设备中的一些或全部的联网可以便于在一个或多个位置处对程序或方法的并行处理，而不背离本公开的范围。另外，通过接口附接到服务器的任何设备可以包括能够存储方法、程序、代码和/或指令的至少一个存储介质。中央储库可以提供要在不同设备上执行的程序指令。在该实现方式中，远程储库可以充当用于程序代码、指令和程序的存储介质。

[0139] 该软件程序可以与客户端相关联，该客户端可以包括文件客户端、打印客户端、域客户端、互联网客户端、内联网客户端以及其他变型，诸如辅助客户端、主机客户端、分布式客户端等等。客户端可以包括以下各项中的一个或多个：存储器、处理器、计算机可读介质、存储介质、端口（物理的和虚拟的）、通信设备以及能够通过有线或无线介质访问其他客户端、服务器、机器和设备的接口等等。如本文中以及其他地方所述的方法、程序或代码可以由客户端执行。另外，执行本申请中描述的方法所需的其他设备可以被认为是与客户端相关联的基础设施的一部分。

[0140] 客户端可以提供到其他设备的接口，包括但不限于服务器、其他客户端、打印机、数据库服务器、打印服务器、文件服务器、通信服务器、分布式服务器等等。附加地，这种耦合和/或连接可以便于跨网络远程执行程序。这些设备中的一些或全部的联网可以便于在一个或多个位置处对程序或方法的并行处理，而不背离本公开的范围。另外，通过接口附接到客户端的任何设备可以包括能够存储方法、程序、应用、代码和/或指令的至少一个存储介质。中央储库可以提供要在不同设备上执行的程序指令。在该实现方式中，远程储库可以充当用于程序代码、指令和程序的存储介质。

[0141] 可以通过网络基础设施来部分或全部地部署本文中描述的方法和系统。网络基础设施可以包括如下元件：该元件诸如是计算设备、服务器、路由器、中枢、防火墙、客户端、个人计算机、通信设备、路由设备，以及如本领域已知的其他有源和无源设备、模块和/或组件。与网络基础设施相关联的（一个或多个）计算和/或非计算设备可以除其他组件之外还包括存储介质，诸如闪速存储器、缓冲区、堆栈、RAM、ROM等等。本文中和其他地方描述的过程、方法、程序代码、指令可以由一个或多个网络基础设施元件来执行。

[0142] 本文中和其他地方描述的方法、程序代码和指令可以在可在有线或无线网络中操作的不同设备中实现。无线网络的示例包括第4代（4G）网络（例如，长期演进（LTE））或第5代（5G）网络，以及非蜂窝网络，诸如无线局域网（WLAN）。然而，其中描述的原则可以等同地应用于其他类型的网络。

[0143] 在本文中和其他地方描述的操作、方法、程序代码和指令可以在移动设备上或通过移动设备实现。移动设备可以包括导航设备、蜂窝电话、移动电话、移动个人数字助理、膝上型计算机、掌上计算机、上网本、传呼机、电子书阅读器、音乐播放器等等。这些设备除其他组件之外还可以包括存储介质，诸如闪速存储器、缓冲区、RAM、ROM和一个或多个计算设备。与移动设备相关联的计算设备可以被启用以执行存储在其上的程序代码、方法和指令。替换地，移动设备可以被配置成与其他设备协作地执行指令。移动设备可以与基站进行通信，该基站与服务器对接并被配置成执行程序代码。移动设备可以在对等网络、网状网络或其他通信网络上进行通信。程序代码可以存储在与服务器相关联的存储介质上，并且可以由嵌入在服务器内的计算设备执行。基站可以包括计算设备和存储介质。存储设备可以存储由与基站相关联的计算设备执行的程序代码和指令。

[0144] 可以在机器可读介质上存储和/或访问计算机软件、程序代码和/或指令，该计算机可读介质可以包括：计算机组件、设备和记录介质，其将用于计算的数字数据保留长达某个时间间隔；半导体存储装置，其被称为随机存取存储器（RAM）；大容量存储装置，其通常用于更持久的存储，诸如是光盘、磁存储装置的形式，比如硬盘、磁带、鼓状物、卡和其他类型；处理器寄存器、高速缓冲存储器、易失性存储器、非易失性存储器；光学存储装置，诸如CD、DVD；可移动介质，诸如闪速存储器（例如，USB棒或钥匙）、软盘、磁带、纸带、打孔卡、独立RAM磁盘、Zip驱动器、可移动大容量存储、离线等等；其他计算机存储器，诸如动态存储器、静态存储器、读/写存储装置、可变存储装置、只读、随机访问、顺序访问、位置可寻址、文件可寻址、内容可寻址、网络附接存储装置、存储区域网络、条形码、磁性墨水等等。

[0145] 本文中描述的方法和系统可以将物理和/或无形项目从一种状态变换为另一种状态。本文中描述的方法和系统还可以将表示物理和/或无形物品的数据从一种状态变换为另一种状态，诸如从使用数据变换为标准化的使用数据集。

[0146] 本文中描述和描绘的元素（包括在遍及附图的流程图和框图中）暗示了元素之间的逻辑边界。然而，根据软件或硬件工程实践，所描绘的元素及其功能可以通过计算机可执行介质在机器上实现，该计算机可执行介质具有如下处理器：该处理器能够作为单片软件结构、作为独立软件模块、或作为采用外部例程、代码、服务等等的模块或这些的任何组合来执行存储在其上的程序指令，并且所有这样的实现方式都可以在本公开的范围内。这种机器的示例可以包括但可以不限于：个人数字助理、膝上型计算机、个人计算机、移动电话、其他手持式计算设备、医疗设备、有线或无线通信设备、换能器、芯片、计算器、卫星、平板PC、电子书、小工具、电子设备、具有人工智能的设备、计算设备、联网设备、服务器、路由器等等。此外，流程图和框图中描绘的元素或任何其他逻辑组件可以在能够执行程序指令的机器上实现。因此，尽管前述附图和描述阐述了所公开的系统的功能方面，但是除非明确陈述或以其他方式从上下文中清楚的，否则不应从这些描述中推断出用于实现这些功能方面的软件的特定布置。类似地，将领会的是，上面标识和描述的各个步骤可以变化，并且步骤的次序可以适合于本文中公开的技术的特定应用。所有这样的变型和修改意图落入本公开的范围内。照此，除非特定应用所要求的、或者明确陈述或以其他方式从上下文中清楚的，否则不应将对各个步骤的次序的描绘和/或描述理解成要求这些步骤的特定执行次序。

[0147] 上述方法和/或过程及其步骤可以以适合于特定应用的硬件、软件或硬件和软件的任何组合来实现。硬件可以包括通用计算机和/或专用计算设备或特定计算设备或特定计算设备的特定方面或组件。可以在一个或多个微处理器、微控制器、嵌入式微控制器、可编程数字信号处理器或其他可编程设备，连同内部和/或外部存储器中实现这些过程。这些过程还可以或者代替地体现在专用集成电路、可编程门阵列、可编程阵列逻辑或可以被配置成处理电子信号的任何其他设备或设备的组合中。将进一步领会到，可以将一个或多个过程实现为能够在机器可读介质上执行的计算机可执行代码。

[0148] 可以使用如下各项来创建计算机可执行代码：诸如C之类的结构化编程语言、诸如C++之类的面向对象的编程语言、或任何其他高级或低级编程语言（包括汇编语言、硬件描述语言以及数据库编程语言和技术），它们可以被存储、编译或解释，以在上述设备、以及处理器、处理器架构的异类组合、或不同硬件和软件的组合、或能够执行程序指令的任何其他机器中的一个上运行。

[0149] 因此，在一方面，上述每个方法及其组合可以体现在计算机可执行代码中，该计算机可执行代码在一个或多个计算设备上执行时实行其步骤。在另一方面，这些方法可以体现在实行其步骤的系统中，并且可以以多种方式跨设备而分布，或者所有的功能都可以集成到专用的独立设备或其他硬件中。在另一方面，用于实行与上述过程相关联的步骤的部件可以包括上述任何硬件和/或软件。所有这样的排列和组合意图落入本公开的范围内。