专利名称：用于向商家提供库存执行服务的计算机实现的登记的制作方法
技术领域：
本发明涉及用于库存管理服务的计算机实现的登记，更具体地说，涉及用于向商家提供库存执行服务的计算机实现的技术。
相关技术描述
为了向买家提供准备好用于交付的各种物品，许多商家(无论是从事电子商务还是传统的"砖块和泥浆"交易)在库存设施内保持不同数量的这种物品。把物品保持在库存中可以用来緩冲买家要求的变化或制造商或分销商的供应各种物品的能力的变化。例如，由商家提供销售的不同的物品可以有不同的制造商领先时间。保持一定的数量的这样的物品作为库存可以使得商家能够向买家提供这些物品的持续的可用性，而不考虑不同的领先时间。
然而，在某些情况下，保持库存可能给商家带来各种花费或缺点。例如，库存存储设施进行供应和维护可能是昂贵的，特别是对于不能把这样的设施的固定花费有效地和有利地分布到库存数量有限的较小的商家。此外，如果需求量上升，则把库存系统扩大到容纳增加的要求或体积可能是在技术、设施和/或人员方面需要很大投资的昂贵的事情。
商家保持它自己的库存也给买家带来不利。随着电子商务越来越流行，许多商家越来越多地连同其它商家一起经由电子市场列出他们的供应物，电子市场提供共同的接口，通过它买家可以搜索物品和进行预订。然而，如果不同的商家最终通过这样的市场负责执行它们自己的各个订单，作为买家的预订经验可能会随从其预订物品的不同的商家很大地变化。例如，对于订单执行没有技艺或只有很差的处理能力的商家可能很慢地发货物品，可能发货错误的物品，可能交付损坏的货物，或者可能造成不好的买家体验。这样的负面体验不仅反映在买家从其预订的商家上，而且也反映在电子市场的其它商家上，并会降低买家对于市场本身的信任。
发明内容
公开了用于向商家提供库存执行服务的方法和系统的各种实现例。根据一个实现例，系统可包括被配置成存储指令的存储器，以及被耦合到存储器的一个或多个处理器。指令可以是由至少一个处理器
执行的，用来实现库存管理系统，它可被配置成实现登记接口；经由登记接口从商家接收来自对于库存物品的执行服务供应商的库存执行服务的请求；确定该请求是否有效的；以及响应于确定该请求是有效的，经由登记接口向商家提供有关用于输送库存物品的单位到执行服务供应商的信息。
在另一个实现例中，系统可包括被配置成存储指令的存储器，以及被耦合到存储器的一个或多个处理器。指令可以是由至少一个处理器可执行的，用来实现库存管理系统，库存管理系统可被配置成从多个商家接收对于从库存物品的执行服务供应商接收库存执行服务的请求，其中来自给定的商家的给定的请求是经由不需要人为干预的登记接口接收的，以及其中库存物品由多个商家提供交易。库存管理系统还可以被配置成接收由买家做出的对于分别由多个商家中的两个或更多个不同的商家提供的两个或更多个库存物品的一个或多个订单，以及响应于接收该一个或多个订单，指令该两个或更多个库存物品在一个或多个发货中被发货到买家，其中该一个或多个发货的至少一个发货包括由两个或更多个不同的商家提供的库存物品，以及其中两个或更多个不同的商家中的每个商家是用于它的各自提供的库存物品的记录的商家。
图l是示出了执行中心的一个实现例的框图。图2A是示出了执行服务登记接口的一个实现例的框图。 图2B是示出了执行服务管理接口的一个实现例的框图。 图3是示出了执行服务供应商可以藉以接收和处理来自商家对
于库存执行服务的请求的方法的一个实现例的流程图。
图4是示出了以多个商家的名义执行物品的预订的方法的一个
实现例的流程图。
图5显示可被包括在从图4的订单执行方法得到的包裹中的包装
标签的一个实现例。
图6显示网页的一个实现例。
图7是示出了计算机系统的示例性实现例的框图。
虽然本发明易于做出各种不同的修改方案和替换形式，但本发明
的具体的实现例在图中作为例子被示出，并在这里详细描述。然而应
当理解，附图和详细说明不打算把本发明限制在所公开的具体形式，
相反，本发明将覆盖属于本发明的主旨和保护范围的所有修改方案、
等价物和替换例。
具体实施方式
执行中心概述
被配置成存储用于买家订单执行的库存物品的执行中心的一个 实现例在图1中示出。在所图示的实现例中，企业5包括执行中心10， 它又包括库存存储设施20以及库存管理系统30。存储设施20可被配 置成存储任意数目的库存物品35a-n。正如下面更详细地描述的，系 统30可被配置成经由任意数目的不同的商家40a-d中的一个或多个商 家接收来自一个或多个买家50的对各种物品35的买家订单。此外， 系统30可被配置成发起和/或协调导致预订的物品35发货到相应的买
家50的4亍动。
总的说来，执行中心10可被配置成接收和存储来自如批发商、 分销商或商家40的各种来源的不同种类的物品35。物品35通常可包 括任何类型的、可被接收用于存储的有形的物体或物质。例如，但不限于，物品35可包括媒体物品(例如，书、光盘、录像带和/或DVD)、电子设备、计算机和相关的外围和设备、消费品或商用器具、服装、药剂和/或上根的成药、化妆品、食品或其它适当的物品。应当指出，物品35可以按离散的可计数的单位或多个单位，诸如包裹、紙盒、条板箱、集装箱或其它适当的聚集体被储藏、管理或分发。作为替代，某些物品35，诸如大宗产品、商品等等，可以以连续的或任意分割的、没有被固有地组织成可计数的单位的量被存储。这样的物品35可以按可度量的量，诸如长度、面积、重量、持续时间、或由测量的单位表征的其它尺度特性，来进行管理。总的说来，如果适当的话，物品35的量可以是指可计数的数目的物品35的单独的或积累的单位或物品35的可度量的量。
在用于存储的执行中心10处接收的物品35可被存储在库存存储设施20内，它可包括物品存储结构的任何适当的组合或安排。例如，设施20可包括支架、储藏仓、集装箱或以栅格或其它方式安排的其它的类型的存储设备。在某些实现例中，设施20可包括适用于具有专门的存储要求的物品35的不同类型的存储装置。例如，某些类型的物品35可能是易腐败的、易碎的、或易挥发的，以及可能需要在受到控制的温度、气氛或其它条件下存储。相应地，设施20可包括冷冻的或其它类型的存储区域，被配置来满足某些物品35的专门的环境要求。在某些实现例中，预期物品35可以以与它们被接收的不同的配置被存储在设施20内。例如，许多单位的物品35可以以盒子、集装箱或其它积聚装置被接收，以及可以被拆包或分解，作为各个单元被存储在设施20内的仓、支架、或其它存储结构内。
库存管理系统30通常可被配置成通过执行中心10跟踪和控制库存物品35的状态和运动。在一个实现例中，正如下面结合图6的说明更详细地描述的，系统30可包括计算机可访问的媒体，其被配置来存储例如可由处理器或计算机系统执行的指令，以便检测与物品35有关的事件，并响应于这样的事件生成或发起行动，例如，系统30可以检测涉及到来自供应商或商家的库存物品35的到达的事件，以及可以响应地指令代理(例如，机器代理或人工代理)处理所接收的物
品35，和把它们适当地存储在存储设施20内。类似地，系统30可被 配置成检测对于以买家50的名义从商家40到达的各种物品35的订 单。相应地，系统30可被配置成指令代理从存储设施20选择对于接 收的订单的适当的物品35，以及准备所选择的物品35，用于发货或 以其它方式输送到相应的买家50。在某些实现例中，无论何时给定的 物品35的单位被存储在存储设施20中或是从存储设施20被选择时， 系统30可以更新相应于给定的物品35的指示，反映它的库存状态。 例如，这样的指示可以反映当前被存储在设施20内的单位数、已从 设施20被选择但还没有离开执行中心10的单位数、在订单上的给定 的物品35的单位数、和/或任何其它适当的物品状态信息。系统30 也可被配置成处理涉及到损坏的或有缺陷的物品35的处理的事件， 从买家50处接收的退货，或其它异常事件。
商家40可以向买家50安排提供各种物品35的交易。总的说来， 物品35可以由商家根据任何适当的商业模式提供交易。例如，物品 35可以根据销售、租借、拍卖、易货交易、证书、许可证、版税、或 其它任何类型的事务被提供交易。商家40可以通过任何各种各样的 通道提供物品进行交易。例如，给定的商家40可以经由由买家50可 访问的电子商务(e商务)入口给出物品35的提供。这样的电子商务提 供可以分别不同地包括经由由给定的商家40接纳的和作为不同于企 业5的提供实体给出的、基于web的实体(例如，网址或网页)的列出 物品35，或通过由企业5代表给定的商家40接纳的基于web的实体 的列出物品35。
在某些实现例中，商家40可以经由由诸如市场的企业5主管的 通常的基于web的实体或其中许多商家40可以列出提供品的论坛列 出物品35。总的说来，市场电子商务通道通常可以是指基于web的 实体，通过该实体多个商家40可以经由一个或多个网页向买家提供 物品50，例如，市场可被组织成向买家50呈现一个或多个网页根据 各种不同的项目(例如，价格、可获得性、条件等等)列出在商务中提供具体的物品35的各个商家40。作为替代，市场可被组织成向买家50呈现对应于商家40的各个虛拟沿街铺面的一个或多个网页，其中每个沿街铺面表示相应的商家40的各种不同的提供。在某些实现例中，市场可以经由下面描述的web服务应用编程接口(API)、而不是一个或多个网页被实现。例如，市场的目录信息、预订功能和其它方面可以作为web服务的功能被实现，它可被各方调用，把交易的物品35呈现给买家50。电子商务市场的其它配置也是可能的和预期的。
商家的电子商务提供还可包括经由与企业5和商家40不同的第三方web实体，诸如第三方拍卖web实体，列出物品35。还预期商家40可以通过除了基于web的实体以外的实体给出电子商务提供。例如，商家40可以通过电子邮件、电子布告板或其它电子通道给出这样的提供品。
在某些实现例中，商家还可以通过非电子通道，例如目录、电话或物理的沿街铺面通道，向买家50提供交易的物品。作为替代，某些商家40可以通过不同的通道的组合提供交易的物品35。还应当指出，某些商家，诸如商家40d，可以附属于通常向商家提供执行服务的企业5，虽然在其它实现例中，企业5可以不用作为对于那些物品的商家运行，提供对于物品35的执行服务。
总的说来，买家50可包括任何实体，它可以经由一个或多个商家40做出对于一个或多个物品35的订单。例如，买家50可包括个人、机关、公司、商店、组织或其它实体。买家50可以经由任何适当的通道，诸如上述的电子商务通道之一，或经由非电子预订通道做出与商家40的订单。买家50可以是最终在法律上和/或财政上负责订单的实体，但不一定非要是这样的实体。类似地，买家50可以或不一定是与给定的订单有关的物品的有目的的接收者。例如，买家50可以代表可以承担付费责任的或可以是有目的的接收者的另一个实体做出对于物品35的订单。在某些实现例中，买家50可包括许可把他们预订的物品35—起发货的多个个人或实体。例如，买家50可以对应于在同一个住宅或办公室的一群人。在给定的买家50做出对于一个或多个物品35的订单后，订单是 可以被执行。总的说来，执行过程可包括从存储装置选择在订单中规 定的物品35，针对它们将被输送到买家50或其它有目的的接收者的 模式适当地包装所选择的物品35，并把包裹输送到接收者。例如，所 选择的物品可以连同保护材料、促销材料(例如，广告传单或小册子)、 包装条或发票一起被包装在一个或多个盒子、信封或其它类型的容器 中。包装容器然后可被密封，适当地加标签，和提供到公共的承运方 (例如，美国邮政服务或另外的承运方)或其它类型的承运方或交付服 务，用于交付到有目的的接收者。
执行服务请求处理
如图l的实现例所示，执行中心10可被配置成为各种不同的商 家40提供执行服务，这些商家可以是在与执行中心IO有关的企业的 内部或外部。通常，执行服务可包括与在执行中心10内的物品35的 存储和处理有关的任何行动，以及对于各种物品35的特定的买家订 单的执行。例如，执行服务可包括在把物品35接纳到库存时牵涉到 的那些任务，诸如进行物理接收物品35的单位或量，检查和/或评估 接收的物品35的状况，如果需要的话拆包或重新打包物品35，以及 把物品35存储在存储设施20内。执行服务还可包括响应于买家订单 从存储设施20选择或收集物品35，以及上述的打包和发货任务。在 某些实现例中，执行服务可包括代表商家40担负的其它任务，诸如 在物品被存储在存储设施20的同时检查或监控物品35的质量和/或状 况，接收和处理从买家50退还的物品35，处理和除去由于各种原因 未加标记的物品35(例如，过剩的、损坏的、过时的、腐败的物品35)， 对于买家50从事买家服务活动(例如，响应申诉、询问等等)、或其它 类型的任务。被配置成为商家40提供执行服务的执行中心19的实现 例也可以称为执行服务供应商。
在某些实现例中，执行中心10可以以比起如果商家40要执行他 们自己的执行服务时更大尺度的经济性来为商家40提供执行服务。 例如，在大型执行中心IO(例如，包括成百上千个平方英尺的存储面
18积的执行中心)提供一平方英尺的存储面积的增加的花费大大地低于由可能只有有限的存储空间或可能受本地市场条件强迫保持比起对
于该商家的库存所需要的更多空间的小的商家40承担的花费。同才羊地，执行中心10可以实现对于单个的商家40的规模的实现来说花费很大和麻烦的、精巧的库存跟踪和管理技术，诸如物品的RFID(射频标识)、在多个订单上物品选择的动态调度和优化、相对于订单的实时库存跟踪、接收和发货活动、或其它库存管理技术。正如下面更详细地描述的，在某些实现例中，执行中心10可被配置成协调来自几个商家40的单个买家的订单，它可以例如通过减小打包、物品操控和
发货花费而实现规模的附加经济性。
然而，安排执行服务向各种不同商家40的提供可能存在挑战。例如，商家40可以作为具有互相不同的以及与企业5不同的用于库存管理和记帐的方法和系统的企业操作。结果，商家40和企业5可能缺乏识别库存物品35的一致途径。例如，给定的商家40可以通过该物品的通用产品代码(UPC)识别和管理特定的项目35，而同一个物品35可以在执行中心10内通过专用的唯一识别号被识别。而且，商家40可能希望动态地改变他们对于各种物品35接收的执行服务。例如，特定的商家40可能希望从对于物品35执行他自己的执行迅速地转移到从执行中心10接收对于该物品的执行服务，或反之亦然。如杲这样的转移需要人工批准(例如，对于执行服务的商家的适当性或物品的适用性)和/或特定的商家库存和订单管理系统的相关方面与执行中心10的那些方面的人工合并，则用于执行服务的安排的附加开销可以大大地影响由这样的服务提供的节省或效率。例如，如果企业5是对于由商家40提供的人工查找表和数据项的执行服务请求的条件处理，则可能要经过几天或几星期。
在一个实现例中，执行中心10可被配置成提供登记接口，通过该接口商家可以登记接收对于一个或多个物品35的执行服务35，其中登记接口处理对于执行服务的请求的操作不需要人工干预。例如，接口可以提供自动处理，通过它商家可以完成发起对于各种物品35的执行服务所必需的任务。正如下面更详细地描述的，在各种实现例
中，这样的自动处理可包括评估商家40的证书(例如，商家对于企业 5是否为已知的，是否处在良好的财务状态等等)，评估对于其请求执 行服务的物品35(例如，物品35对于请求的服务是否合格)，以及给 请求的商家40提供对于完成执行服务请求所需要的信息(例如，提供 要加到物品35的用于执行中心库存控制的标签、用于把物品发货到 执行中心10的发货标签、指令、状态报告、或其它信息)。每个这些 任务的执行中心部分可以不用人干预而自动地执行，正如下面描述 的。
执行服务登记接口的一个实现例显示于图2A。在所图示的实现 例中，执行中心10的库存管理系统30 4皮显示为包括登i己接口 200, 被配置成与数据库210进行交互。在一个实现例中，登记接口 200可 被配置成呈现一种接口，通过它给定的商家40可以规定对于执行服 务的请求，输入与所请求的服务有关的数据，以及进行由企业5认为 对于给定的商家40接收所请求的服务所必需的那些处理活动。例如， 在一个实现例中，接口 200可被配置成把经由公共互联网或专用内部 网(例如，由需要某个认证级别或用于访问的保密连接的企业5或以其 名义维护的专用网)可访问的一个或多个网页呈现给商家40。这样的 网页可包括可填写的表格、菜单、可执行的应用(例如，以JavaTM或 Javascript或适用于基于web的执行的其它语言被编码的应用)或其它 基于web的接口单元。
在另 一个实现例中，接口 200可被配置成把专用的或非基于web 的登记接口呈现给商家40。例如，接口 200是可以通过拨号或非基于 web的互联网连接，诸如经由诸如telnet那样的终端仿真程序，或经 由适用于在商家40与库存管理系统30之间传送信息的另一种类型的 标准或专用应用可访问的。在另一个实现例中，接口 200可包括用于 商家执行服务登记的web服务接口，正如下面更详细地描述的。在某 些实现例中，接口 200可包括其它类型或模式的接口实现方案，包括 上述技术的各种组合，被配置成与商家40通信，执行与执行服务的登记或管理应用有关的活动。
在所图示的实现例中，接口 200可被配置成存储从商家40接收 的执行服务登记数据，或在数据库210内从商家的执行服务登记活动 得到的或由于该登记活动的结果或者与该登记活动相关产生的其它 数据。总的说来，数据库210可包括任何适当类型的应用或数据结构， 其可被配置为永久的数据仓库。例如，数据库210可被配置为关系数 据库，它包括一个或多个具有列和行的表格，以及它可以根据诸如结 构化询问语言(SQL)的版本那样的询问语言被搜索或询问。作为替代， 数据库210可被配置为结构化的数据存储库，它包括根据诸如可扩展 的标记语言(XML)的版本那样的标记语言被格式化的数据记录。在其 它实现例中，数据库210可以通过^f吏用通过任何适当类型的应用^L管 理和可访问的一个或多个任意地或最小地构建的数据文件被实现。
数据库210通常可被配置成存储与商家40、物品35和/或在处理 的各个阶段对于执行服务的请求有关的任何类型的数据。例如，数据 库210可被配置成存储有关商家40的识别信息，诸如商家个人或部 门的名字和地址、商家记帐和发货地址信息、商家银行或其它金融信
息、或其它识别信息。数据库210还可被配置成存储有关商家40的 库存或销售事务的当前的和/或历史的状态信息，诸如商家的预订历 史、付费历史、在执行中心10内商家的库存物品35的状态、任何待 决的对于商家的执行服务请求的状态、或其它类型的状态信息。在某 些实现例中，数据库210还可被配置成存储对于物品35的识别号映 射信息。例如，数据库210可存储把给定商家40的、用于特定的物 品36的识别号(例如商家的库存物保持单元(SKU)识别号)与对于企业 5或对于执行中心IO特定的识别号相联系的记录。这样的映射信息例 如可^L用来联系商家的执行服务请求。
应当指出，数据库210不需要合并到库存管理系统30内，甚至 也不需要合并到执行中心10内。在某些实现例中，商家和/或库存数 据可被存储在企业5中分布的多个不同的数据存储库。例如，商家金 融数据可被存储在与可能与诸如执行中心10那样的实现部门不同的、企业5的会计部门有关的财务数据库。同样地，在某些实现例中，接 口 200可被配置成与各种系统、应用、或除了数据库210以外或代替 数据210在库存管理系统30内或外部的数据库进行交互。
诸如执行中心10那样的执行服务供应商(或简称为供应商)可以 通过其接收和处理来自商家40的对于库存执行服务的请求的方法的 一个实现例被显示于图3。预期在各种实现例中，所显示的方法或它 的适当的变体可以经由被存储在计算机可访问的媒体上的计算机可 执行的指令，正如下面结合图6的说明更详细地描述的，或经由可能 是依赖于状态的(例如状态机)但本身不执行具体的指令的专用计算机 硬件设备来实现。还可预期，在某些实现例中，某些或所有的所说明 的方法可以通过被包括在接口 200内的判决逻辑来实现，而在其它实 现例中，接口 200可被配置成把商家状态信息中继到和来自其它可执 行的部件、系统或库存管理系统30或执行中心10内的设备。在这样 的其它实现例中，某些或所有的所显示的方法可通过不同于接口 200 的部件被实现。应当指出，在各种实现例中，商家可以提交可应用于 多种不同的物品35的单个执行服务请求，或可以提交对于几种物品 35中的每种物品的各个请求。虽然此后讨论的例子可能涉及到单个物 品35的处理，但应当看到，该方法可应用于多种不同的物品35的同 时发生的执行服务请求处理。
在所图示的实现例中，操作在方块300开始，其中对于库存执行 服务的请求由执行服务供应商从商家40接收。例如，这样的请求可 以作为商家40通过使用商家识别号和适当的证书(例如登录名称和密 码，或任何其它适当的类型的证书)和随后选择经由安全网页显示的请 求执行服务的选项(例如，链路、按钮等等)的结果，经由登记接口 200 的一个实现例被接收。在其它实现例中，这样的请求可以经由web服 务呼叫或经由不采用基于web的协议的通信模式被接收。
在接收到来自商家40的执行服务请求后，供应商可以确定请求 的商家是否有资格接收执行服务(方块302)。在某些实现例中，商家 的对于执行服务的合格性可以依赖于商家的历史行为。例如，商家与供应商或其它企业的现前交易的当前状态或历史可被检查，以确定商 家是否从事了与买家、零售商、供应商、或其它方的欺诈交易或成问 题的交易。在某些实现例中，当考虑商家的对于执行服务的合格性时， 可以考虑商家的信用度、买家服务历史、或涉及到商家的任何其它数 据(或在某些情况下，涉及到与商家有关的负责财务的实体或个人，诸 如担保人、委托人、执行官等等)，以及这样的数据可包括从诸如信用 报告代理、商业证明人、买家等等那样的第三方得到的数据。
在各种实现例中，供应商可以通过考虑任何的上述商家数据类型 或没有具体地提到的其它类型，以便呈现有关请求的商家是否有资格 接收执行服务的决定而实现变化的复杂性的判决模型。例如，在一个 实现例中，欺诈行为的任何历史可以使得商家失去资格，而在其它实 现例中，更精巧的风险分析模型可以在其它数据点方面考虑这样的行 为。预期在某些实现例中，对于执行服务的合格性可以取决于所请求 的服务的类型或服务量。例如，几乎没有历史或具有成问题的历史的
商家40可被允许按尝试或可能性原则访问执行服务，这样的访问限 于物品35的某些类型、数量或价值，或按某些其它原则被限制。
如果请求的商家40被确定为没有资格进行执行服务，则可以阻 止商家进行自动执行服务请求处理(方块304)。在某些实现例中，商 家可被引导以联系执行服务代理(例如，买家服务代表)，以便得到在 处理执行服务请求时的其它信息或帮助，例如接收对于失去资格的原 因的说明和为了补救这种情况可以采取的行动的说明。
如果请求的商家40被确定为有资格进行执行服务，则供应商可 以确定商家是否已被登记，以接收执行服务(方块306)。在一个实现 例中，确定商家的登记状态可包括确定商家是否已提供了供应商认为 对于代表商家执行执行服务所必需的数据。例如，登记可以是随商家 40(例如电子地或书写地)同意详细阐述与执行服务有关的供应商和商 家的权利和期望的、执行服务参加约定(诸如商家通过各种财务的、过 程的、买家服务或其它策略遵守的约定)而定的。登记也可以是随商家 40提供足够的识别信息而定的，正如下面阐述的。在某些实现例中，确定商家是否登记可包括确定商家以前是否登记执行服务，以及如果 是的话，则假设商家是登记的而不用检验商家对于登记所需要的每个 数据项。另外，在某些实现例中，如果以商家的名义的先前的登记或 任何先前的执行服务活动是在当前的执行服务请求以前的大于阈值 的时间段发生的，则可能要求商家再次提供某些或所有的登记数据。 应当指出，在某些实现例中，确定商家的登记状态可以在确定商家的 执行服务的资格之前进行。
如果请求的商家40被确定为没有登记，则供应商可以从商家40 请求登记数据(方块308)。例如，可填写的web表或对于商家输入的 其它请求可以经由接口 20提供到或显示给商家40。所请求的输入可 包括诸如商家的名字、电话号码、地址、银行名称、银行路由号和帐 号、交税人识别信息、和/或任何其它适当的信息那样的信息。另外， 如果必要或适当的话，参加约定可以经由接口 200，连同对于商家直 接接受或拒绝约定的要求一起，被输送到商家40。商家40然后可以 以适合于例如通过填写基于web的表格而交付请求的模式的方式输 入或提供请求的数据。
供应商然后可以试图验证由商家40提供的登记数据(方块310)。 例如，供应商可以检验，以查明已提供所有的需要的数据，以及例如 可以通过分别检验联系或银行信息对公共地址数据库或规定的银行 而证实与第三方的某些数据项。如果可应用的话，供应商还可以检验，
以查明商家是否表示接受参加约定。如果所提供的数据的任何部分无 法证实，则供应商可以请求商家重新输入数据，或可以结束自动执行 服务请求处理，以及请求商家联系代理，以便得到进一步帮助(方块 304)。
如果所提供的数据是有效的或商家40被确定为已经登记，则供 应商可以请求与由商家40对于其请求执行服务的物品35有关的识别 信息(方块312)。例如，接口 200可以显示商家通过其提供物品识别 信息的另一基于web的表格。在某些实现例中，物品识别信息可以连 同对于执行服务的初始请求一起被提供，以及对于这个信息的分开的
24请求可能不是由供应商做出的。另外，在某些实现例中，商家40可 以规定对于其除了请求物品识别信息以外还请求执行服务的物品35 的数量。
供应商然后可以确定它是否具有足够的、关于如由请求的商家 40识别的物品35的信息，来处理对于该物品的执行服务请求(方块 314)。在一个实现例中，供应商可以通过首先确定物品35对于供应商 是否为已知的(例如，供应商是否具有与物品35有关的信息的某些记 录)，而4故出这个决定。例如，正如前面指出的，物品35可以由商家 40以与由执4亍中心10识别的不同的方式4皮识别。在一个实现例中， 商家可提供商家自己的唯一的识别号，诸如商家规定的SKU识别号， 作为对于物品35的识别信息。作为响应，供应商可以确定是否存在 从商家的唯一的识别号到对于供应商是已知的识别号的映射，例如， 通过使用商家的识别号询问数据库210,以确定相应的记录是否包括 供应商的识别号。在另一个实现例中，当供应对于物品35的识别信 息时，请求的商家40可以除了提供商家特定的识别号以外，或代替 该商家特定的识别号，提供对于供应商是已知的识别号。
如果供应商具有足够的信息来处理对于所识别的物品的执行服 务请求，则供应商可以从商家征求附加信息(方块316)。例如，如果 供应商不能根据商家特定的识别号，诸如商家的SKU，来定位对于物 品35的记录，则供应商可以向请求的商家40征求供应商特定的识别 号，或通用识别号，诸如通用产品码识别号，如果可用的话。在某些 实现例中，供应商可以提供经由接口 200的物品搜索能力，以便允许 请求的商家40确定对于其请求执行服务的物品35对于供应商是否为 已知的。例如，供应商可以提供关键字搜索特征，允许请求的商家40 输入与物品35相关的关键字。作为替代，供应商可允许请求的商家 40导航分级结构的物品目录，以查明由商家40识别的物品35是否被 包括在分级结构中，以及在某些实现例中，如果物品35没有包括在 内，则确定在分级结构中最类似的物品。
在某些环境下，供应商可能没有对应于对于其请求执行服务的物品35的信息。例如，供应商可能从不在之前对于请求的商家40或对 于任何其它商家提供对于物品35的执行服务。例如，供应商可以请 求，所请求的商家40提供诸如物品尺寸、重量、物品类型或类别的 信息(例如，根据由供应商规定的分类或分级结构)、物品特殊的特性 (例如，物品是液体、易腐败的、还是有害材料；需要专门处理或存储 条件等等)、或由供应商认为对于识别物品35所必需的任何其它信息 那样的信息，以确定物品35对于执行服务是否合格，和/或便于执行 服务的提供。
一旦供应商具有足够的、关于所识别的物品35的信息，供应商 就可以确定物品35对于所请求的执行服务是否合格(方块318)。例如， 在一个实现例中，供应商可以不允许对于诸如有害的物品那样的某些 类型的物品35的执行服务。在另一个实现例中，商家40可以根据参 加约定或费用结构、与供应商的当前商业关系、商家的其它库存相对 于供应商的当前状态、或任何其它适当的准则，被限制请求对于某些 物品35执行服务。例如，商家40可以与供应商联系，在给定的时间 间隔内接收对于一定数量的物品35的执行服务，这样，可以不允许 对于附加数量的该物品35的执行请求。
如果由于物品35合格而不能处理执行服务请求，则供应商可以 经由接口 200通知请求的商家40，以及自动执行服务请求处理可以结 束(方块320)。否则，供应商可以指令所请求的商家40输送某个规定 的数量的物品35到供应商，诸如可能是由所请求的商家在对于执行 服务的请求时或以后规定的数量(方块322)。
在一个实现例中，在指令商家输送物品35时，供应商可以把由 商家40被使用来识别各个单位的物品35的数据提供给所请求的商家 40。例如，供应商可以经由接口 200输送文档文件到商家，诸如〗更携 式文档格式(PDF)文件或其它类型的文档文件，它包括字母数字、条 形码或表示识别可被用来管理在执行中心10内的物品35的多个单位 的信息的其它信息。在各种不同的实现例中，这样的识别信息可以唯 一地识别每个单独的单位的物品35，通常可以把单位识别为物品35的类别或类型的相同的实例，或者可以組合对于物品35通用的信息 与对于特定的单位的物品35的特定的信息。例如，所提供的识别信 息可包括对于特定的单位的物品35特定的序列号，UPC或对于所有 的单位的物品35通用的类似的产品码、或标识物品35的产品类型的 代码以及特定单位的状况(例如，新的、用过的、损坏的等等)。可以 利用任何适当的类型或组合的识别信息。所提供的文档可被用来生成 标签，被分别附着到各个单位的物品35上。例如，如果适当的话， 请求的商家40可以在接收到文档后把它的内容打印在标签本上并把 标签附着到多个单位的物品35上。
供应商还可给商家40提供要被商家用来输送物品35到供应商的 数据。在一个实现例中，供应商可以经由接口 200把诸如PDF文档 或其它类型的文档文件那样的、包括表示发货信息的数据的文档文件 输送到商家。例如，文档文件可包括地址信息、条形码数据和/或可被 用来生成发货标签的其它数据。这样的发货标签可以是适合于把包裹 提供到任何类型的承运方的通用发货标签。作为替代，发货标签数据 可以对于具体的承运方被定制，例如，通过包括条形码、地理码、或 对于具体的承运方特定的其它路由或操控信息。在某些实现例中，发 货信息数据可被包括在被用来如上所述地输送单位识别信息的相同 的文档中，而在其它实现例中，发货信息数据可以在分开的文档中被 输送。应当指出，在各种不同的实现例中，供应商可以把单位-识别信 息、发货信息、或二者输送到请求的商家40，或这二者都不输送到请 求的商家。
在某些实现例中，被提供给请求的商家40的与发货有关的数据 可以反映从请求的商家40预期的、分离的发货或包裹的数目。例如， 商家可以表明规定数量的对其请求执行服务的物品35可以被划分到 一定数目的包裹中间。作为替代，供应商可以指令请求的商家40以 特定的方式在发货中间划分规定的数量。在某些实现例中，在具体的 物品35的多个发货或包裹的情况下，被提供给请求的商家40的发货 数据例如可以通过包括条形码或被包括在从发货数据生成的发货标
27签上的其它信息，唯一地标识每个发货或包裹。预期在某些实现例中，
供应商可以指令请求的商家40发货不同数量的物品35到不同的执行 中心10,以及被输送到请求的商家40的发货数据可以反映这种分布。 例如，供应商可以根据在各种不同的执行中心10中可得到的存储资 源规定分布。作为替代，供应商或请求的商家40可能希望保证在不 同的执行中心10中间物品35的特定的地理分布，例如满足预期的要 求的模式。
在许多情况下，在接收到把特定数量的物品35输送到供应商的 指令后，请求的商家40可以根据接收的指令适当地打包和发货物品 35到供应商。例如，请求的商家40可以打印物品标签，把它们附着 到这些单位的物品35上，并把这些单位打包成一个或多个包裹用于 发货，打印发货标签并把它们附着到包裹上，并把包裹提供到船方或 承运方，用于发货到供应商。然而，请求的商家40不需要实际拥有 物品35。在某些实现例中，请求的商家40可以同诸如制造商、分销 商、零售商、或其它类型的供应商那样的第三方商定把规定数量的物 品35输送到供应商。例如，请求的商家40可以把识别和/或发货信息 的物品转发到第三方，第三方可以以请求的商家40的名义安排输送 物品35到供应商。
在指令请求的商家40输送规定数量的物品35后，供应商可以接 收物品35(方块324)并把物品35存储到库存中(方块326)。例如，包 括多个单位的物品35的一个或多个包裹可以安排在执行中心10。在 各种不同的实现例中，包裹可被扫描、拆卸、检查和/或其它处理，以 及多个单位的物品35可被存储在存储设施20内。库存管理系统30 还可以适当地更新，以反映接收到的单位的物品35的状态，以及在 某些实现例中，请求的商家40可被告知物品35对于执行是可用的。
在某些实现例中，供应商可以在物品35到达之前接收来自请求 的商家40的发货的通知。在某些这样的实现例中，供应商或请求的 商家40可以响应于这样的通知更新物品35的可用性的指示。例如， 请求的商家40可以经由由诸如基于web的铺面或市场的企业5维护
28的电子商务通道提供交易的物品35。响应于从请求的商家40接收的 发货的通知，企业5可以考虑到诸如在从请求的商家40转移到供应 商时的预期的时间、在供应商处接收和存储物品35的处理时间、和/ 或影响物品35的可用性的其它因素那样的因素，更新物品的提供的 显示或列表，以表明预期的领先时间或可用性的其它指示。
应当指出，在某些实现例中，诸如执行中心10的执行服务供应 商可以用来允许商家40请求对于物品35的执行服务，进行对于验证 对于所请求的服务的物品和商家的合格性所必需的那些行动，以及把 对于商家准备对于所请求的服务的物品35所必需的数据输送到商家 和把物品35输送到供应商。具体地，应当指出，执行中心10可以以 完全自动的方式执行这些任务，这样，如果请求的商家40和物品35 满足供应商的合格性要求，则执行服务请求可以不用人的千预而被处 理。例如，通过经由登记接口 200与执行中心10进行交互，商家40 可以完成对于物品35的执行服务请求，把物品355发货到执行中心 10，以及开始把对于物品35的买家订单中继到执行中心IO用于如下 所述地执行，而不依赖于在登记接口 200外部的执行中心10的代理 的行动。这种自动执行服务请求处理系统也可以称为"自助"系统，其 中商家40可以主动地与系统进行交互。
在一个实现例中，除了提供通过其商家40可以请求对于各种物 品35的库存执行服务的自助登记接口 200以外，执行服务供应商可 以提供商家40能够通过其管理可应用于它们的物品35的执行服务的 各个方面的管理接口 。图2B显示类似于图2A的库存管理系统30的 实现例，其中加上可被配置成与数据库210以及商家40进行交互的 管理接口 220。
管理接口 220可被配置成给出一种接口，通过它给定的商家40 可以对于先前已由给定的商家40对于其请求执行服务(例如，经由登 记接口 200)的物品执行下面描述的各种功能的任何功能。像登记接口 200 —样，在一个实现例中，管理接口 220可被配置成为商家40呈现 经由乂>共互联网或专用内部网可访问的一个或多个网页(例如，由企业5或代表企业5维护的专用网需要用于访问的某个级别的认证或保密 连接)。这样的网页可包括可填写的表格、菜单、可执行的应用(例如 通过Java , Javascript或其它适用于基于web执行的语言编码的应 用)或其它基于web的接口单元。在其它实现例中，管理接口 220可 被配置成以类似于以上对于登记接口 200描述的那种方式给商家40 呈现非基于web的管理接口或基于web服务的管理接口 。
在某些实现例中，预期登记接口 200和管理接口 220均可被实现 为基于web的执行服务端口的不同的或合并的部分。例如，与预期登 记接口 200和管理接口 220二者有关的功能可以经由被呈现给商家40 的各个网页或网页组来实现，作为集中的执行服务网址的方面。作为 替代，这样的功能可以通过被呈现给商家40的各个组的web服务调 用被呈现为通用web服务API,用于登记和执行服务的管理。
正如以上所述，在一个实现例中，在商家40处登记物品35用于 执行服务后，物品35可以置于执行中心10的物理监视和管理下。在 这样的实现例中，在从商家40转移到执行中心10以及从执行中心10 转移到买家50时，除了在执行中心10内的物品35的状态以外，用 于物品35的供应链还可被扩展成包括物品35。(在某些情况下，用于 物品35的通用供应链也可以考虑到相反的供应链，反映从买家50返 还的单位的流程和/或从执行中心10去除的和净皮输送回商家40的单 位。)在某些实现例中，管理接口 220可被配置成使得给定的商家40 可以看到通用供应链相对于它的登记的物品35的状态。例如，管理 接口 20可以提供在任何给定的时间在给定的商家40、执行中心10和 /或买家之间转移的给定物品35的单位的数量的指示或显示(例如，包 括跟踪对于在转移中的单位的信息，如果可得到或可应用的话)。
在一个实现例中，管理接口 220也可以提供被保存在执行中心 10内的库存中的给定物品35的单位的状态的指示，诸如标识被提交 到订单的、但还没有打包或发货的单位，识别腐败的或损坏的单位， 或识别任何其它相关的库存状态信息。在某些实现例中，管理接口 220 可以把关于在对于物品35的供应链中出现的问题或例外事件的说明性信息提供给商家40。例如，如果多个单位的物品35在从商家40到 达执行中心10时被损坏或处在与由商家40预期的或由商家40指示 的不同的状态或状况，当执行服务对于单位被请求时(例如，是用过的 而不是新的状况)，管理接口 220可被配置成显示这样的信息给商家 40，允许商家40规定解决问题的行动。例如，管理接口 220可以允 许商家40指令损坏的物品被清除掉或返还给商家40，允许商家40安 排输送附加的单位到执行中心IO(例如，覆盖当前的订单)，或采取其 它适当的4亍动。更一般地，管理接口 220可以允许商家40主动地请 求多个单位的物品35从库存取出(例如，返还到商家40),重新放置 在不同的执行中心10中间，或被清除掉。
总的说来，管理接口 220可被配置成提供任何类型的、适用于监 视或改变在包括商家40、执行中心10和买家50的扩展供应链内的给 定物品35的状态的功能。在某些实现例中，供应链和管理接口功能 可以扩展到其它第三方，诸如制造商、分销商、批发商、或在有关给 定物品35的事务中牵涉到的其它方。
在其它实现例中，管理接口 220可被配置成提供不直接涉及到供 应链监视或管理的功能。在一个实现例中，管理接口2M可被配置成 提供一种商家可通过其接收以买家50的名义引起的买家服务问题的 通知的接口，以及参加它们的解决方案。例如，库存管理系统30可 被配置成接收对于特定的订单引起的买家服务问题的报告和识别与 这些订单有关的商家40(或包括在订单中的特定物品35)。系统30然 后可以把与给定的商家40有关的这样的买家服务报告引导到进入邮 箱、论坛或由给定的商家40经由管理接口 220可访问的其它储存库。 作为替代，管理接口 220例如可以经由电子邮件把这样的报告直接转 发到给定的商家40。响应于给定的报告，给定的商家40可以经由管 理接口 220例如通过安排要被返还或替代的物品35，安排要发到买家 50的返款或信用值，或表明其它适当的行动，而参与解决该问题。
订单执行处理过程
如前所述，诸如企业5的执行中心10的执行服务供应商可以执行对于由多个不同的商家40提供交易的各种各样的物品35的执行服 务。商家40可以经由自助登记接口请求这样的服务，正如以上参照 图3描述的。
一旦商家40被安排来从供应商接收对于物品35的执行服务，供 应商就可以进行完成买家订单。在一个实现例中，买家可以经由通道 直接与商家40签订对于物品35的订单，通过该通道，商家40提供 交易的物品(例如，通过电子商务或如上所述的其它类型的通道)。在 一个这样的实现例中，买家订单可以从商家40经由库存管理系统30, 或经由接口 200或经由被配置成用于订单处理的不同的接口被输送到 执行中心。在其它实现例中，买家订单可以通过第三方被输送到执行 中心IO。例如，商家40可以把它自己的订单输入接口呈现给买家50 和假设用于输送订单到执行中心10进行实现的责任。作为替代，商 家40可以安排企业5代表商家接管包括订单输入接口的交易通道， 这样，商家40不能直接介入接收和处理订单，但可以在财务上和/或 法律上负责该订单。
在某些环境下，给定的买家50可以做出对于由不同的各个商家 40提供交易的两个或更多个不同的物品35的订单。例如，给定的买 家50可以与每个商家40签订单独的订单，以任何适当的组合预订来 自第一商家40的第一物品35或物品35的组、来自第二商家40的第 二物品35或物品35的组等等。作为替代，给定的买家50可以经由 电子通道签订一个或多个订单，其允许给定的买家50同时观看一个 以上的商家40的提供物。例如，给定的买家50可以使用虚拟的"购 物车"，由不同的商家40提供的物品35可被放置在该购物车内，用 于订单处理。这样的购物车可以允许给定买家的对于特定订单的物品 选择，以便在不同的电子商务通道上持续进行。例如，买家的购物车 的内容可以在买家从一个商家的网址或列表页到与另一个商家40有 关的通道浏览时持续出现。在某些实现例中，虛拟购物车可以例如通 过允许买家50对于在车中的所有物品35提交一个付费事务，而不是 对于与那些物品35有关的每个商家40提交单独的付费事务，而简化
32买家的预订体验。虚拟购物车也可以促进识别协调由给定的买家50 从多个不同的商家40预订的物品35的机会，如下面还要详细描述的 那样。
在订单执行的传统模型中，从不同的商家40预订的物品35分开 地执行，这增加了执行的总的花费。例如，分开地打包和发货一组物 品35比起一起打包和发货这些物品开销更大。然而，在某些实现例 中，执行服务供应商，诸如执行中心IO，可被配置成协调由单个买家 50从多个商家40预订的物品35,以使得至少某些物品35作为单件 发货被打包和发货，而同时每个商家40仍旧是对于它的各个物品35 的记录的商家。在一起发货某些物品35时，执行的花费可以减小， 并且最终得到的节省一起交付给买家50，或由商家40和/或企业5保 留作为利润。同时，每个商家40可以仍旧是对于它提供交易的物品 35的记录的商家，保留与此有关的在财政上、法律上和/或其它的责 任和利益。也就是说，虽然执行服务供应商可以物理地监视由它代表 商家40对于其提供执行服务的物品35，但供应商可以把功能简化为 在商家40与买家50之间的事务中的中间人而不是负责人。在各种实 现例中，供应商在实现订单时的角色对于买家可以是或不一定是可见 的。
以多个不同的商家40的名义实现对于物品35的订单的方法的一 个实现例在图4示出。共同参考图1-4，操作在方块400开始，其中 诸如执行中心10的执行服务供应商接收由买家50对于由不同的各个 商家40提供交易的至少两个不同的物品35签订的一个或多个订单。 在某些实现例中， 一个或多个商家40可以经由自助执行服务接口 ， 诸如以上对于图3描述的接口 200，请求对于它的相应的预订的物品 35的执行服务。如前所述，订单可以从商家40、直接从买家50或者 经由第三方被接收。在其中采用虛拟购物车的实现例中，在不同的物 品35、不同的商家40和预订的买家50之间的关系可以是在作为虚拟 购物车内容的处理结果生成的数据记录上明显的或隐含的。例如，虛 拟购物车可以把公共订单识别号指定给形成买家的订单的部件的每个物品35，这可以便于供应商把物品35组合到发货，正如下面描述 的。
在某些实现例中，如杲从单个买家50接收到多个不同的订单， 从同一个或不同的商家40进行预订，则订单可以由供应商例如才艮据 可以在商家40与供应商之间协调的公共买家识别号或^^共订单识别 号被链接。 一旦被识别为链接的或相关的，多个订单就可以在可能的 程度上作为单个订单被处理，用于下面描述的执行处理。在某些这样 的实现例中，供应商可以仅仅链接在给定的时间间隔内签订的或接收 的订单，诸如在一-j、时、 一天等等内签订的订单。时间间隔可以取决 于由买家规定的交付模式，例如，如果买家50请求对于给定的订单 的加速发货，则用于把给定的订单链接到其它订单的时间间隔可以是 相当短的，避免在发货给定的订单时的延时。
在接收订单后，规定的物品35可以从存储装置中被取回(方块 402)。例如，在一个实现例中，买家订单可以由库存管理系统30进行 处理，生成指令，以命令人或机械选取器从库存存储设施20内选择 规定的物品35。预期在某些实现例中，规定的物品35可以连同为非 相关的订单指定的其它物品35—起被取回。例如，系统SO可以在多 个选取器之间划分多个订单，以优化选取器效率，特别是在其中在给 定的订单中规定的物品35广泛地分布在执行中心10的情况下。
对应于两个不同的商家40的至少两个取回的物品35然后可^皮打 包(方块404)。例如，取回的物品35可被交付到执行中心10内的打 包区域，以便被适当地打包用于发货，它可包括选择适当的盒子或其 它箱子，插入保护性包装材料，和/或包括包裹票签、发票、装货清单、 促销材料或其它材料。在某些实现例中，如果在执行中心10中存在 对应于买家的订单的所有物品35，则可以把它们打包为单个包裹用于 发货，或可以分成多个包裹，如果规定了花费、物品特性或发货要求 的话。在某些情况下，预订的物品35的执行可以分布在不同的执行 中心IO,例如取决于物品可用性。
随后，包括对应于两个不同的商家40的至少两个物品35的包裹
34可被发货到买家50(方块406)。例如，包裹可被提供到公共承运方用 于发货。
可被包括在根据图4的方法执行的包裹中的包裹票签的一个实 现例显示于图5。在图示的实现例中，包袠票签500向识别的买家表 明在发货内包括四种物品35。物品A和B被表示为由商家A提供的。 物品C被表示为由商家B提供的。物品D被表示为由商家C提供的。 因此，商家A-C被表示为对于它们的相应的物品A-D的记录的商家， 而识别的买家可以作为单个发货接收物品A-D。牵涉到不同数目的物 品和商家的其它情况也是可能的和预期的。应当指出，在各种不同的 实现例中，包裹标签500可以对应于买家发票、记帐文档、提货单、 或被格式化以概述订单信息的其它文档。
还应当指出，在某些实现例中，包裹标签500可包括以各种方式 被格式化的多个页或组元。例如，相应于记录的不同的商家的物品35 可被表示在包裹标签500的不同的页或部分。在某些情况下，包裹标 签500还可包括除了标识记录的商家的信息以外的信息或数据。例如， 这样的信息可包括可以应用到给定物品35的项目和状况，或对于记 录的商家的、牵涉到给定的物品35的事务、担保信息、买家服务信 息(例如，用于投诉、返还、交换等等的联系信息)、市场或促销信息(例 如，将来的打折、优惠券等等的提供)，或其它类型的信息。在某些实 现例中，包裹标签500所包括的信息可被定制或被格式化，以适合于 关于买家的位置的要求或买家。例如，不同的文档要求可应用于牵涉 到处在不同的法律管辖下(例如，地区、国家等等)的买家的事务。包 裹标签500可以适当地被格式化，以便考虑这样的要求或其它因素。
把从多个商家预订的物品35合并成较少的发货可以导致较低的 执行花费，正如以上指出的。例如，藉助于体积，执行中心10可以 具有相对于对于各个商家40可得到的那些更优选的访问的打折的发 货率。因此，通过允许它的物品35与来自另一个商家40的物品35 进行组合用于发货，给定的商家40可以享用发货和打包的较低的花 费。而且，买家的信誉可以通过更多及时的和/或方便的发货体验而增加。例如，买家的订单可以通过来自执行中心10的执行，比起如果 每个商家40牵涉到分开地实现它的部分的订单更快速地完成，而且， 除了减小买家50的发货花费的可能性以外，较少的发货可以减小在 进行物品35交付时买家的不方便性，例如，如果买家或买家代理必 须在交付时出席。
应当指出，虽然如上所述的订单合并可以足以减小实现花费，但 这样的合并可能不一定必须这样做。在某些环境下，通过执行中心IO 实现单个物品35的花费可能低于商家40要执行它自己的执行服务。 例如，执行中心10可以从较大规模的经济、较好的用于库存和供应 链管理的基础结构、或导致相对于商家40在较小的规模下执行它自 己的执行服务的较小的实现花费的其它优点而获益。
在某些情况下，经由登记接口 200的、对于执行服务的商家的给 定物品35的登记可以使得该物品35对于由执4亍中心10执行的对物 品35可得到的各种服务或促销机会，诸如其中买家可以接受免费标 准发货、免费加快发货、减小花费的标准或加快发货等等的减小花费 的或加快的发货促销，是合格的。其它促销机会可包括对当前的订单 打折、对将来的订单的信用、忠诚程序分、对于合伙商家的打折或信 用、或其它类型的促销。这样的合格性甚至可应用于其中买家50预 订单个单位的物品35而在订单中没有组合给定的物品35与其它物品 35的情况。例如，在一个实现例中，对于促销发货安排或由执行中心 10执行的物品35的其它促销机会的合格性可以取决于买家的订单的 总的价格。在这样的实现例中，如果给定的物品35具有足以满足合 格性准则的价格，则买家50在单独地或与由执行中心IO执行的其它 物品组合地预订单个单位的给定的物品35时可以接受促销考虑。
在某些实现例中，从如上所述的、商家的对于执行服务的自助登 记得到的花费节省和/或从执行中心10的效率得到的花费节省可被用 来积累被提供给买家的促销机会，诸如接受花费减小的或加快的发 货、物品打折、或其它类型的促销的机会。在其它情况下，这样的花 费节省可以作为对于执行服务的打折或信用、作为利益共享或合作市场基金、或以其它适当的方式被提供给商家40。这样的节省也可以由 企业5保留，或以上述方式的任何组合被分布在企业5、商家40和/ 或买家50之间。
如前所述，上述的方法和4支术的各种不同的方面(例如，登记接 口 200和/或管理接口 220的各种方面)可以通过使用网页呈现给商家 40或买家50。总的说来，网页可包括数据内容以及元数据内容，该 元数据内容可被配置成控制数据内容的呈现。例如，网页可包括文本、 静止图像、视频内容、导航链接、或其它类型的数据内容、以及可用 来控制数据内容的放置、外观、交互行为、或其它呈现方面的元数据 或指令。
通常，网页的数据和元数据内容可以以诸如超级文本标记语言 (HTML)的版本或用于基于web的内容实现方案的任何其它适用的语 言那样的语言被编码。网页内容可以从诸如由执行中心10或企业5 或以执行中心10或企业5的名义实现的web主4几那样的内容源通过 使用诸如，例如超级文本输送协议(HTTP)的版本那样的适当的输 送协议的网络(例如，互联网或专用网)被输送到诸如商家40或买 家50那样的客户。内容然后可以由诸如web浏览器那样的适当客户 应用程序被解译或处理，正如由编码语言和元数据内容表示的。web 浏览器的某些示例性类型包括但不限于Microsoft Internet Explorer , Mozilla Firefox，和OperaTM。除了把网页呈现给客户以 外，web浏览器还可以收集和处理来自客户的输入数据。例如，浏览 器可以检测导航链接、菜单项目、按钮、或可被呈现给客户的其它类 型的输入设备的选择或激活，以及可以响应于这样的选择或激活，通 过把数据输送回内容源或其它实体或系统，导航到不同的内容源，或 执行其它适当的行动而操作。
通用的网页的一个实现例显示于图6。在所图示的实现例中，浏 览器窗口 600被显示为包括网页610。在被包括在网页610中的各种 类型的内容中有文本内容620、图像内容630、输入特性640和可导 航的链接650，虽然在其它实现例中，网页610可包括在各种組合中
37的或多或少类型的内容，包括以上没有具体地枚举的类型。虽然各种 内容类型被显示为分离的特性，但它们可以根据浏览器的能力和被用
来实现网页610的语言以任何适当的方式被散布或组合在一个实现例 中，浏览器窗口 600可以由诸如以上提到的那样的web浏览器被生成 和管理。
在一个实现例中，网页610的各种内容特性的内容和放置可以由 接口 200或以接口 200的名义被生成，以《更实现商家40可以通过其 调用以上参照图3描述的自助执行服务登记过程的网页。例如，文本 内容620、图像内容630和输入特性640可被配置成把执行服务供应 商的对于输入数据的请求呈现给商家40,和提供一种用于允许商家 40响应于此输入和输送这样的数据，诸如通过呈现具有其中可以由商 家40插入数据的字段的表格。
在另一个实现例中，网页610可被配置成实现适合于呈现物品 35的交易订单给买家50，以及呈现买家50潜在地感兴趣的其它数据 的电子商务通道。例如，商家40可以操作它自己的电子商务主机设 施，生成它自己的内容，并把它经由网页610输送到买家50。作为替 代，商家40可以同诸如企业5那样的另一方商定，以它的名义呈现 这样的网页610。在另一个实现例中，企业5或另一方可以经由一个 或多个网页610实现诸如上述那样的电子商务市场。例如，来自各个 商家40的、用于具体的物品35或用于多个物品35的多个订单表格 可以经由网页61(M皮显示给买家50。
示例性计算机系统实现例
预期在某些实现例中，上述的任何方法或技术可被实现为能够被 存储或经由计算机可访问的媒体被输送的程序指令和数据。这样的方 法或技术例如可包括但不限于库存管理系统30、接口 200和/或数据 库210的功能，以及图3和4所示的方法或它们的任何适当的变体或 部分。这样的程序指令也可以被执行，以〗更执行在支持上述的方法和 技术中的计算功能，例如用具体的例子来说明操作系统功能、应用功 能、和/或任何其它适当的功能。包括计算机可访问的媒体的计算机系统的一个示例性实现例显
示于图7。在所图示的实现例中，计算机系统900包括经由输入/输出 (1/0)接口 930被耦合到系统存储器920的一个或多个处理器910。计 算机系统900还包括被耦合到I/O接口 930的网络接口 940。在某些 实现例中，预期库存管理系统50可以通过使用计算机系统900的单 个实例来实现，而在其它实现例中，多个这样的系统可被配置成接纳 库存管理系统50的不同的部分或实例。例如，在一个实现例中，某 些数据源或服务(例如，购买管理服务)可以经由与实现其它数据源或 服务(例如，订单输入/执行服务)的那些实例不同的计算机系统900的 实例来实现。应当指出，在某些实现例中，如以上各个不同地描述的 库存管理系统50的功能可以以任何适当的方式被划分成多个不同的 模块、程序过程、或其它功能部分。库存管理系统50的最终得到的 部分然后可被实现为在计算机系统900的一个或几个实例之间的统一 的或分布式的系统，例如作为由一个或多个处理器910可执行的指令。
在各种实现例中，计算机系统900可以是包括一个处理器910 的单处理器系统，或包括几个处理器910(例如，两个、四个、八个或 另外的适当数目)的多处理器系统。处理器910可以是通用或嵌入式处 理器，实现任何的各种各样的指令组结构(ISA)，诸如x86， PowerPC, SPARC, MIPS ISA,或任何其它适当的ISA。在多处理器系统中，每 个处理器910可以共同，但不一定必须，实现同一个ISA。
系统存储器920可被配置成存储由处理器910可访问的指令和数 据。在各种实现例中，系统存储器920可以通过使用任何适当的存储 器技术来实现，诸如静态随机存取存储器(SRAM)、同步动态 RAM(SDRAM)、非易失性/快闪型存储器、或任何其它类型的存储器。 在所图示的实现例中，实现诸如以上描述的那些想要的功能的程序指 令和数据，如图所示作为代码925被存储在系统存储器920内。
在一个实现例中，1/0接口 930可被配置成协调在处理器910、 系统存储器920和在设备中的任何外设，包括网络接口 940或其它外 设接口之间的I/0业务。在某些实现例中，1/0接口 930可以执行任何必需的协议、定时或其它数据转换，以便把来自一个部件(例如，系
统存储器920)的数据信号转换成适合于由另一个部件(例如，处理器 910)使用的格式。在某些实现例中，1/0接口 930可包括对于通过各 种类型的外围总线附着的设备的支持，诸如外围部件互联(PCI)总线标 准或通用串行总线(USB)标准。在某些实现例中，1/0接口 930的功能 可被分割成两个或更多个分开的部件，例如北桥和南桥。另外，在某 些实现例中，1/0接口 930的某些或所有的功能，诸如到系统存储器 920的接口，可以直接合并到处理器910。
网络接口 940可净皮配置成允许数据在计算机系统卯0与4皮附着到 网络的其它设备，诸如其它计算机系统之间交换。在各种实现例中， 网络接口 940可以经由诸如任何适当类型的以太网那样的有线或无线 通用数据网；经由诸如模拟语音网或数字光纤通信网那样的电信/电话 网；经由诸如光纤信道SAN那样的存储域网；或经由任何其它适当 类型的网络和/或协议而支持通信。
在某些实现例中，系统存储器920可以是被配置成存储如上所述 的程序指令和数据的计算机可访问的媒体的一个实现例。然而，在其 它实现例中，程序指令和/或数据可以被接收、发送或存储在不同类型 的计算机可访问的媒体上。总的说来，计算机可访问的媒体可包括存 储媒体或存储器媒体，诸如磁或光媒体，例如经由1/0接口 930被耦 合到计算机系统900的磁盘或CD/DVD-ROM。计算机可访问的媒体 还可包括任何易失性或非易失性媒体，诸如RAM(例如SDRAM ， DDR SDRAM， RDRAM， SRAM等等)，ROM等等，它们可被包括在计算 机系统900的某些实现例中，作为系统存储器920或另一种类型的存 储器。经由计算机可访问的媒体被存储的程序指令和数据可以通过传 输媒体或信号，诸如电的、电磁的或数字信号被传送，这些信号可以 经由诸如网络和/或诸如可以经由网络接口 940实现的无线链路那样 的通信媒体被输送。
另外，预期以上描述的和例如在图3和4上显示的任何方法或技 术可以作为以请求这样的服务的客户的名义执行的web服务来实现。总的说来，提供功能或服务作为web服务可包括提供任何的各种标准 化的API,被配置为允许不同的软件程序以自主的、基于web和典型 地与平台无关的方式通信(例如，请求服务和应答这样的请求)。例如， 企业可以选择经由web服务接口把某些企业数据(例如，目录数据、 库存数据、买家数据或其它类型的数据)和/或某些企业功能(例如，执 行服务请求处理功能、询问功能、电子商务功能、通用数据存储或计 算功能等等)暴露到外部客户(例如，商家40或买家50)。应用然后可 以经由web服务接口访问暴露的数据和/或功能，即使访问应用可被 配置成在与接纳暴露的数据或功能的平台完全不同的平台(例如，不同 的操作系统或系统结构)上执行。例如，商家40可以执行用于执行服 务的物品35的自助登记，或可以通过由接口 200暴露的web月良务调 用通知执行中心10要执行的预订。
在某些实现例中，提供web服务可包括使用特定的协议，它是 可执行的(例如，作为代码925的一部分)，把可得到的web服务公布 给潜在的用户，充分描述web服务的接口，以允许用户适当地调用 web服务，允许用户选择和区分用于特定事务的web服务，以及以灵 活的和平台无关的方式提供用于交换web服务数据的格式。具体地， 在一个实现例中，web服务的供应商可以通过使用通用发现描述和综 合(UDDI)协议的版本来登记服务，该协议可以起到通用目录的作用， 通过它潜在的资源用户可以定位感兴趣的web服务。Web服务供应 商也可以公布关于来自用户的合适的web服务请求应当如何被格式 化的具体的细节(例如，需要或允许哪种具体的参数，对于给定的参 数要使用的数据类型或格式等等)。例如，这样的接口细节可以通过 使用Web服务描述语言(WSDL)的版本而被公布(例如，在UDDI 目录项内)。
在许多实现例中，web服务请求和应答数据通过^f吏用4皮格式化为 平台无关构建的数据的消息或文档，诸如遵循可扩展标记语言(XML) 的版本被格式化的文档，而在客户与服务供应商之间交换。例如，在 一个实现例中，提供对于给定的库存物品的库存健康信息的web服务请求可以在包括标识感兴趣的物品的字段、所需要的数据的类型(例
如，库存健康数据)和可能其它的字段的XML文档中体现，其中每个 字段由描迷该字段表示的数据的类型的XML标签进行界定。对于来 自web服务供应商的对于这样的请求的应答可包括XML文档，它包 含所请求的数据。在某些实现例中，与web服务有关的文档可以通过 使用基于web的数据传输协议，诸如超级文本传输协议(HTTP)在进 行请求的应用与目标web服务之间传送。
不同类型的web服务请求和应答可以产生通常只承载很少的内 容的XML文档，这会使得这样的文档的处理和解译复杂化。例如， 在规定web服务请求的自由形式XML文档的不同版本中，所请求的 实际的web服务可能出现在不同的文档版本内的不同位置，它们可能 需要文档的接收者在理解该文档是干什么用之前緩存或解析大量文 档数据。因此，在某些实现例中，包含web服务请求/应答数据的文 档可以被封装在被用来规定消息传送框架的附加XML数据内，例如 用于交换具有任意内容的文档或消息的通用格式。例如，在一个实现 例中，web服务请求或应答可以是根据简单目标访问协议(SOAP)的版 本被格式化的XML文档，它在各种版本中可以规定不同的文档部分， 诸如"封套"(例如，它可包括文档类型、有目的的接收者web服务等 等的技术规范)以及可包括任意XML消息数据(例如，web服务请 求的具体的细节)的消息体。然而，在某些实现例中，web服务可以 通过使用用于公布服务和格式化与交换消息的不同的协议和标准而 被实现。
另外，在某些实现例中，web服务系统可以不使用诸如SOAP 型协议那样的基于文档的技术而实现。例如，作为对于基于文档的方 法的替代，web服务可以通过使用表示状态传输(REST)型结构而实 现。总的说来，在REST型结构中，web月良务请求可被形成为经由输 送协议被输送的命令，诸如经由HTTP协议的版本输送的PUT或GET 命令。可被嵌入到基于文档的web服务结构的文档内的该请求的那些 参数可以替代地被包括作为REST型结构中的命令参数。Web服务结构的其它适当的配置也是可能的和预期的。
虽然以上的实现例以相当的细节被描述，但本领域技术人员 一旦 充分理解以上的公开内容就将明白许多变化和修改方案。以下的权利 要求将被解译为包括所有这样的变化和修改方案。
权利要求
1.一种系统，包括被配置成存储指令的存储器；以及被耦合到所述存储器的一个或多个处理器，其中所述指令可由所述一个或多个处理器中的至少一个处理器执行，用来实现库存管理系统，其中所述库存管理系统被配置成实现登记接口；经由所述登记接口从商家处接收对于接收来自执行服务供应商的对于库存物品的库存执行服务的请求；确定所述请求是否有效；以及响应于确定所述请求是有效的，经由所述登记接口向所述商家提供有关用于输送多个单位的所述库存物品到所述执行服务供应商的信息。
2. 如在权利要求1中所迷的系统，其中所述商家是所述执行服 务供应商从其接收对于由所述多个商家提供交易的各个库存物品接 收库存执行服务的请求的多个商家之一，以及其中所述库存管理系统 还4皮配置成接收由买家做出的对于由所述多个商家中的两个或更多个不同的商家分别提供的两个或更多个所述库存物品中的一个或多个订单；响应于接收到所述一个或多个订单，指令所述两个或更多个库存 物品在一个或多个发货中被发货到所述买家，其中所述一个或多个发 货中的至少一个发货包括由所述两个或更多个不同的商家提供的库 存物品，以及其中所述两个或更多个不同的商家中的每个是对于它的分别提供的库存物品的记录的商家。
3. 如在权利要求1中所述的系统，其中所述库存管理系统还被 配置成接收由买家做出的对于由所述商家提供交易的一个或多个单位 的所述库存物品的订单；确定所述订单对于促销机会是否合格；以及 如果所述订单是合格的，则指令所述一个或多个单位在所迷促销 机会的名义下被发货到所述买家。
4. 如在权利要求3中所述的系统，其中为了确定所述订单对于 所述促销机会是否合格，所述库存管理系统还被配置成确定所迷订单 的总的价格是否超过阈值。
5. 如在权利要求3中所述的系统，其中所述促销机会包括减小 花费的发货机会。
6. 如在权利要求1中所述的系统，其中为了确定所述请求是否 有效，.所述库存管理系统还被配置成确定所述商家对于接收库存执行 服务是否合格。
7. 如在权利要求1中所述的系统，其中为了确定所述请求是否 有效，所述库存管理系统还被配置成确定所述库存物品对于接收库存 执行服务是否合格。
8. 如在权利要求1中所述的系统，其中为了经由所述登记接口向所述商家提供有关用于输送多个单位的所述库存物品的信息，所述 库存管理系统还被配置成经由所述登记接口把包括适合于识别所述多个单位的所述库存物品的识别数据的文档输送到所述商家。
9. 如在权利要求8中所述的系统，其中所述文档被格式化，以 使得所述商家能够生成适合于应用到所述多个单位的所述库存物品 的一个或多个标签，其中所述一个或多个标签表示至少某些所述识别 数据。
10. 如在权利要求l中所述的系统，其中为了经由所述登记接口 向所述商家提供有关用于输送多个单位的所述库存物品的信息，所述 库存管理系统还被配置成经由所述登记接口把包括适合于识别包括 用于发货的所述多个单位的所述库存物品的一个或多个包裹的发货 数据的文档输送到所述商家。
11. 如在权利要求10中所述的系统，其中所述文档被格式化， 以使得所述商家能够生成适合于应用到包括所述多个单位的所述库存物品的所述一个或多个包裹的一个或多个标签，其中所述一个或多 个标签表示至少某些所述发货数据。
12. 如在权利要求l中所述的系统，其中所述库存管理系统还,皮 配置成确定所述多个单位的所述库存物品已被所述执行服务供应商 接收。
13. 如在权利要求l中所述的系统，其中所述库存管理系统还被 配置成响应于接收到所述请求，确定所述商家是否被登记以接收库存执 行服务；响应于确定所述商家没有被登记，从所述商家请求登记数据和试 图验证至少某些所述登记数据。
14. 如在权利要求l中所述的系统，其中为了经由所述登记接口 接收所述请求，所述库存管理系统还被配置成经由由所述登记接口呈 现给所述商家的一个或多个网页接收所述请求。
15. 如在权利要求l中所述的系统，其中为了经由所述登记接口 接收所述请求，所述库存管理系统还被配置成经由由所迷登记接口呈 现给所述商家的web服务接口接收所述请求。
16. —种方法，包括执行服务供应商从商家处接收对于接收来自所迷执行服务供应 商的对于库存物品的库存执行服务的请求，其中所述请求经由计算机实现的登记接口被接收；所述执行服务供应商确定所述请求是否有效；以及响应于确定所述请求是有效的，所述执行服务供应商经由所述登记接口向所述商家提供有关用于输送多个单位的所述库存物品到所述执行服务供应商的信息。
17. 如在权利要求16中所述的方法，其中所述商家是所述执行服务供应商从其接收对于由所述多个商家提供交易的各个库存物品接收库存执行服务的请求的多个商家之一，以及其中该方法还包括 所述执行服务供应商接收由买家做出的对于由所述多个商家中的两个或更多个不同的商家分别提供的两个或更多个所述库存物品的一个或多个订单；响应于接收到所述一个或多个订单，所述执行服务供应商把所述 两个或更多个库存物品在一个或多个发货中发货到所述买家，其中所 述一个或多个发货中的至少一个发货包括由所述两个或更多个不同 的商家提供的库存物品，以及其中所述两个或更多个不同的商家中的 每个是对于它的分别提供的库存物品的记录的商家。
18. 如在权利要求16中所述的方法，还包括 接收由买家做出的对于由所述商家提供交易的一个或多个单位的所述库存物品的订单；确定所述订单对于促销机会是否合格；以及如果所述订单是合格的，则指令所述一个或多个单位在所述促销 机会的名义下被发货到所述买家。
19. 如在权利要求16中所述的方法，其中所述执行服务供应商 确定所述请求是否有效包括所述执行服务供应商确定所述商家对于 接收库存执行服务是否合格的。
20. 如在权利要求16中所述的方法，其中所述执行服务供应商 确定所述请求是否有效包括所述执行服务供应商确定所述库存物品 对于接收库存执行服务是否合格。
21. 如在权利要求16中所述的方法，其中所述执行服务供应商 经由所述登记接口向所述商家提供有关用于输送多个单位的所述库 存物品的信息包括所述执行服务供应商经由所述登记接口把包括适 合于识别到所述执行服务供应商的所述多个单位的所述库存物品的 识别数据的文档输送到所述商家。
22. 如在权利要求16中所述的方法，其中所述执行服务供应商 经由所述登记接口向所述商家提供有关用于输送多个单位的所述库 存物品的信息包括所述执行服务供应商经由所述登记接口把包括适 合于识别包括用于发货到所述执行服务供应商的所述多个单位的所 述库存物品的一个或多个包裹的发货数据的文档输送到所述商家。
23. 如在权利要求16中所述的方法，还包括所述执行服务供应 商接收和存储所述多个单位的所述库存物品。
24. 如在权利要求23中所述的方法，其中所述执行服务供应商 接收所述多个单位的所述库存物品包括所述执行服务供应商接收代 表所述商家的、来自不同于所述商家的一方的至少某些所述多个单位 的所述给定的物品。
25. 如在权利要求16中所述的方法，还包括响应于接收到所述请求，所述执行服务供应商确定所述商家是否 被登记用来接收库存执行服务；响应于确定所述商家没有被登记，所述执行服务供应商从所述商 家请求登记数据和试图验证至少某些所述登记数据。
26. 如在权利要求16中所述的方法，其中所述执行服务供应商 经由所述计算机实现的登记接口接收所述请求包括所述执行服务供 应商经由由所述登记接口呈现给所述商家的一个或多个网页接收所 述请求。
27. 如在权利要求16中所述的方法，其中所述执行服务供应商 经由所述计算机实现的登记接口接收所述请求包括所述执行服务供 应商经由由所述登记接口呈现给所述商家的web服务接口接收所述 请求。
28. —种计算机可访问的媒体，包括指令，其中指令是可执行的， 用来实现如在权利要求16-27的任一项中所述的方法。
29. —种系统，包括 被配置来存储指令的存储器；以及 被耦合到所述存储器的 一个或多个处理器； 其中所述指令是由所述一个或多个理器中的至少一个处理器可执行的，用来实现库存管理系统；其中所述库存管理系统被配置成从多个商家接收对于从库存物品的执行服务供应商接收库存执 行服务的请求，其中来自所述多个商家中的一个给定的商家的所述请求中给定的 一个请求是经由不需要人为千预的登记接口接收的，以及其中所述库存物品由所述多个商家提供交易；接收由买家做出的对于分别由所述多个商家中的两个或更多个不同的商家提供的两个或更多个所述库存物品的一个或多个订单；响应于接收所述一个或多个订单，指令所述两个或更多个库存物 品在一个或多个发货中被发货到所述买家，其中所述一个或多个发货 中的至少一个发货包括由所述两个或更多个不同的商家提供的库存 物品，以及其中所述两个或更多个不同的商家中的每个商家是对于它 的分别提供的库存物品的记录的商家。
30. 如在权利要求29中所述的系统，其中所述库存管理系统还 被配置成指令包裹标签被提供到所述买家，其中所述包裹标签被格式 化，把所述两个或更多个不同的商家中的每个商家表示为对于它的分 别提供的库存物品的记录的所述商家。
31. 如在权利要求29中所述的系统，其中所述库存管理系统还 被配置成通过由所述登记接口呈现给所述给定的商家的一个或多个 网页接收所述给定的请求。
32. 如在权利要求29中所述的系统，其中所述库存管理系统还 被配置成通过由所述登记接口呈现给所述给定的商家的web服务接 口接收所述给定的请求。
33. 如在权利要求29中所述的系统，其中所述指令还是可执行 的，用来把电子商务市场呈现给所述买家，通过所述市场所述两个或 更多个所述库存物品分别由所述多个商家中的所述两个或更多个不 同的商家提供。
34. 如在权利要求33中所述的系统，其中所述电子商务市场包 括一个或多个网页。
35. 如在权利要求33中所述的系统，其中所述电子商务市场包 括web服务接口 。
36. 如在权利要求29中所述的系统，其中所述两个或更多个所 述库存物品通过分别与所述多个商家中的所述两个或更多个不同的商家有关的电子商务通道被提供。
37. 如在权利要求36中所述的系统，其中至少一个所述电子商 务通道包括一个或多个网页。
38. 如在权利要求37中所述的系统，其中至少一个所述电子商 务通道包括web服务接口 。
39. 如在权利要求29中所述的系统，其中所述买家对应于多个 个人，每个个人许可把他的订单发货到公共目的地。
40. —种方法，包括执行服务供应商从多个商家接收对于来自库存物品的所述执行 服务供应商的接收库存执行服务的请求，其中来自所述多个商家中的 一个给定的商家的所述请求中的一个给定的请求是经由不需要人为 干预的登记接口接收的，以及其中所述库存物品由所述多个商家提供交易；所述执行服务供应商接收由买家做出的对于分别由所述多个商 家中的两个或更多个不同的商家提供的两个或更多个所述库存物品 的一个或多个订单；响应于接收所述一个或多个订单，所述执行服务供应商把所述两 个或更多个库存物品在一个或多个发货中发货到所述买家，其中所述 一个或多个发货中的至少一个发货包括由所述两个或更多个不同的 商家提供的库存物品，以及其中所述两个或更多个不同的商家中的每 个商家是对于它的分别提供的库存物品的记录的商家。
41. 如在权利要求40中所述的方法，还包括所述执行服务供应 商把包衷标签提供到所述买家，所述包裹标签被格式化成把所述两个 或更多个不同的商家中的每个商家表示为对于它的分别提供的库存 物品的记录的所述商家。
42. 如在权利要求40中所述的方法，还包括所述执行服务供应 商通过由所述登记接口呈现给所述给定的商家的一个或多个网页接 收所述给定的请求。
43. 如在权利要求40中所述的方法，还包括所述执行服务供应商通过由所述登记接口呈现给所述给定的商家的web服务接口接收 所述给定的请求。
44. 如在权利要求40中所述的系统，还包括所述执行服务供应 商把电子商务市场呈现给所述买家，通过所述市场所述两个或更多个 所述库存物品分别由所述多个商家中的所述两个或更多个不同的商 家提供。
45. 如在权利要求40中所述的方法，其中所述两个或更多个所 述库存物品通过分别与所述多个商家中的所述两个或更多个不同的 商家有关的电子商务通道被提供。
46. 如在权利要求40中所述的方法，其中所述买家对应于多个 个人，每个个人许可把他的订单发货到公共目的地。
47. —种计算机可访问的媒体，包括指令，其中指令是可执行的， 用来实现如在权利要求40-46的任一项中所述的方法。
48. —种执行中心，包括 净皮配置来存储库存物品的库存存储设施；以及 库存管理系统，被配置成从商家处接收对于接收来自执行服务供应商的对于所述库存物 品中给定的一个的库存执行服务的请求，其中所述请求是经由计算机 实现的登记接口接收的；确定所述请求是否有效；响应于确定所述请求是有效的，经由所述登记接口向所述商家提 供有关用于输送多个单位的所述给定的库存物品到所述执行中心的信息；以及在检测到所述多个单位的所述库存物品已在所述执行中心处被 接收后，指令把所述多个单位的所述给定的库存物品存储在所述库存 存储设施内。
49. 如在权利要求48中所述的系统，其中所述商家是所述库存 管理系统从其接收对于由所述多个商家提供交易的各个库存物品接 收库存执行服务的请求的多个商家之一，以及其中所述库存管理系统还被配置成接收由买家做出的对于由所述多个商家中的两个或更多个不同 的商家分别提供的两个或更多个所述库存物品的一个或多个订单；响应于接收到所述一个或多个订单，指令所述两个或更多个库存 物品在一个或多个发货中被发货到所述买家，其中所述一个或多个发 货中的至少一个发货包括由所述两个或更多个不同的商家提供的库 存物品，以及其中所述两个或更多个不同的商家中的每个是对于它的 分别提供的库存物品的记录的商家。
50. —种系统，包括 被配置成存储指令的存储器；以及被耦合到所述存储器的一个或多个处理器，其中所述指令是由所 述一个或多个处理器中的至少一个处理器可执行的，用来实现执行服 务管理接口，其中所述执行服务管理接口被配置成从商家接收对应于库存物品的状态请求，其中所述商家经由计算 机实现的登记接口登记所述库存物品，以便从执行服务供应商接收库 存执行服务；以及响应于接收到所述状态请求，把对应于所述库存物品的库存状态 的指示提供给所述商家。
51. 如在权利要求50中所述的系统，其中为了提供库存状态的 所述指示，所述执行服务管理接口还被配置成对于一个或多个以下的 库存状态从所述商家转移到所述执行服务供应商、存储在所述执行 服务供应商处、和从所述执行服务供应商转移到买家，向所述商家表 示相应于所述一个或多个库存状态的、各个数量单位的所述库存物 品。
52. 如在权利要求50中所述的系统，其中所述执行服务管理接 口还被配置成从所述商家接收对于修改所述库存物品的库存状态的请求；以及 响应于接收到所述对于修改的请求，指令采取一个或多个行动， 相应地{资改所述库存物品的库存状态。
53. 如在权利要求52中所述的系统，其中对于修改库存状态的 所述请求规定把给定数量的所述库存物品返还到所述商家，以及其中 为了指令采取所述一个或多个行动，所述执行服务管理接口还被配置 成指令从所述执行服务供应商支取所述给定数量的所述库存物品， 把它们返还到所述商家。
54. 如在权利要求50中所迷的系统，其中所述执行服务管理接 口还被配置成把对应于所述库存物品的买家服务询问呈现给所述商 家。
55. —种方法，包括从商家接收对应于库存物品的状态请求，其中所述商家经由计算 机实现的登记接口登记所述库存物品，以便从执行服务供应商接收库 存执行服务；以及响应于接收到所述状态请求，把对应于所述库存物品的库存状态 的指示提供到所迷商家。
56. 如在权利要求55中所述的方法，其中提供库存状态的所述 指示还包括对于一个或多个以下的库存状态从所述商家转移到所 述执行服务供应商、存储在所述执行服务供应商处、和从所述执行服 务供应商转移到买家，向所述商家表示对应于所迷一个或多个库存状 态的、各个数量单位的所述库存物品。
57. 如在权利要求'55中所述的方法，还包括 从所述商家接收对于修改所述库存物品的库存状态的请求；以及 响应于接收到所述对于修改的请求，指令釆取一个或多个行动，相应地修改所述库存物品的库存状态。
58. 如在权利要求57中所述的方法，其中对于修改库存状态的 所述请求规定把给定数量的所述库存物品返还到所述商家，以及指令 从所述执行服务供应商支取所述给定数量的所述库存物品，把它们返 还到所述商家。
59. 如在权利要求55中所述的方法，还包括把对应于所述库存 物品的买家服务询问呈现给所述商家。
全文摘要
用于提供库存执行服务给商家的方法和系统。根据一个实现例，系统可包括被配置成存储指令的存储器以及被耦合到存储器的一个或多个处理器。指令可由至少一个处理器执行，用来实现库存管理系统，所述库存管理系统可被配置以实现登记接口；经由登记接口从商家处接收对于接收来自执行服务供应商的对于库存物品的库存执行服务的请求；确定所述请求是否有效；以及响应于确定该请求是有效的，经由登记接口向商家提供有关用于输送多个单位的所述库存物品到执行服务供应商的信息。
文档编号G06Q10/00GK101496041SQ200780012660
公开日2009年7月29日 申请日期2007年2月5日 优先权日2006年2月10日
发明者D·L·巴伦杰, J·B·桑德布尔特, M·佩雷拉, R·D·特勒, T·B·泰勒 申请人:亚马逊科技公司