TWI784499B

TWI784499B - 用於動態庫存平衡的系統、電腦實行方法及設備

Info

Publication number: TWI784499B
Application number: TW110115304A
Authority: TW
Inventors: 書云麥克馬斯特; 蘇布拉馬尼亞普拉莫德南杜里; 達林米勒; 肯尼石
Original assignee: 南韓商韓領有限公司
Priority date: 2020-10-08
Filing date: 2021-04-28
Publication date: 2022-11-21
Also published as: KR20230068359A; US10997554B1; TW202215318A; KR102451184B1; KR102618008B1; KR20220048968A; KR20240001285A; WO2022074441A1; TW202307753A; US20220114548A1; US11334847B2

Abstract

本發明提供一種用於動態庫存平衡的電腦實行系統，包含：處理器；以及記憶體裝置，包括指令，指令在執行時組態處理器進行操作。操作包含：自至少一個履行中心接收庫存資料饋入；(在資料庫中)儲存具有相關聯分組數目及數量的多個虛擬配套--多個虛擬配套具有對庫存資料中的相同物件中的兩者或大於兩者進行分組的物件配套。操作亦包含：經由RESTful服務、基於佇列的系統、索引或目標表中的至少一者將資料庫暴露於來自賣方入口網站的查詢；以及接收客戶端訂單，客戶端訂單包括來自多個虛擬配套的配套選擇；以及藉由基於配套選擇再平衡多個虛擬配套及對應相關聯數量而更新多個虛擬配套。

Description

用於動態庫存平衡的系統、電腦實行方法及設備

本揭露內容大體上是關於用於動態庫存管理的電腦化系統及方法。特定而言，本揭露內容的實施例是關於庫存管理系統，所述庫存管理系統使用虛擬配套對物件的群組進行分類且動態地調適虛擬配套以使庫存多樣性及可用供應的範圍最大化。

即時庫存管理系統自動記錄訂單及購買以更新資料庫，且向公司及/或賣方給出需求、可用庫存以及所需回購的完整圖像。即時庫存管理系統對於線上賣方尤其重要，此是由於庫存管理系統提供用以預報客戶端需求及識別供應鏈需要的關鍵資訊。實際上，為達成更高精度，即時庫存管理系統頻繁使用射頻識別(radio frequency identification；RFID)技術(或條碼系統)以便在幾乎無人工干預的情況下更快速地記錄新收據及銷售。此等系統的部署允許即時自動化記錄每一交易(新存貨的購買以及出站訂單及所有相關聯成本兩者)以提供準確庫存狀態。

然而，即時庫存管理難以在使用較寬倉庫網路、多個供應商及/或客製化產品清單(其可取決於區域、季節或客戶偏好)的複雜線上零售操作中達成。另外，組態及維護庫存管理系統已因履行中心(fulfillment center；FC)網路的複雜度增大、第三方供應商的使用以及營銷活動的個人化增加而變得繁瑣。舉例而言，提供於網站中的產品可保存在不同FC中及/或來源於第三方供應商。因此，庫存管理系統需要協調多個系統以創建網路庫存的準確表示。另外，FC可儲存來自具有獨立庫存系統、不同物件識別及/或客製化產品分類的多個供應商的產品。因此，庫存管理系統可能必須使庫存資料相符。

FC網路、多個供應商、客製化產品清單以及各種庫存系統的此複雜度導致庫存更新延遲，此防礙即時庫存管理。舉例而言，為了協調多個FC之間的庫存，庫存系統通常週期性地更新庫存(例如，一天一次)。但在此類較長週期下的庫存更新導致線上零售操作的前段及後段兩者處的問題。舉例而言，缺乏即時庫存資料導致將不可用產品提供給客戶的問題。另外，缺乏準確庫存資料可能導致供應鏈不連續性。

所揭露的動態平衡虛擬配套位址的電腦化系統及方法解決上文所闡述的問題及/或先前技術中的其他問題中的一或多者。

本揭露內容的一個態樣是針對一種用於動態庫存平衡的系統。所述系統可包含：至少一個處理器；以及至少一個記憶體裝置，包括指令，所述指令在執行時組態所述至少一個處理器進行操作。所述操作可包含：自至少一個履行中心接收庫存資料饋入；(在資料庫中)儲存具有相關聯分組數目及數量的多個虛擬配套--其中所述多個虛擬配套包含對所述庫存資料中的相同物件中的兩者或大於兩者進行分組的物件配套。所述操作亦可包含：經由類表現層狀態轉換(RESTful)服務、基於佇列的系統、索引或目標表中的至少一者將所述資料庫暴露於來自賣方入口網站的查詢；以及(自所述賣方入口網站)接收客戶端訂單，所述客戶端訂單包括來自所述多個虛擬配套的配套選擇。所述操作亦可包含回應於接收到所述客戶端訂單，藉由基於所述配套選擇再平衡所述多個虛擬配套及對應相關聯數量而更新所述多個虛擬配套。

本揭露內容的另一態樣是針對一種用於動態庫存平衡的電腦實行方法。所述方法可包含：自至少一個履行中心接收庫存資料饋入；(在資料庫中)儲存具有相關聯分組數目及數量的多個虛擬配套--其中所述多個虛擬配套包含對所述庫存資料中的相同物件中的兩者或大於兩者進行分組的物件配套。所述方法亦可包含：經由RESTful服務、基於佇列的系統、索引或目標表中的至少一者將所述資料庫暴露於來自賣方入口網站的查詢；以及(自所述賣方入口網站)接收客戶端訂單，所述客戶端訂單包括來自所述多個虛擬配套的配套選擇。所述方法亦可包含回應於接收到所述客戶端訂單，藉由基於所述配套選擇再平衡所述多個虛擬配套及對應相關聯數量而更新所述多個虛擬配套。

本揭露內容的又一態樣是針對一種設備，包含：一或多個處理器；以及一或多個記憶體裝置，具有指令，所述指令在執行時組態所述一或多個處理器以進行下述操作：自至少一個履行中心接收庫存資料饋入；(在資料庫中)儲存具有相關聯分組數目及數量的多個虛擬配套。所述多個虛擬配套包含藉由下述操作對所述庫存資料中的相同物件中的兩者或大於兩者進行分組的物件配套：產生多個經編碼標籤，所述經編碼標籤中的每一者對物件識別碼(ID)及配套群組進行編碼，以及在所述資料庫中針對所述庫存資料中的每一物件及所述多個配套中的每一者產生記錄--每一資料記錄包括經編碼標籤欄位及數量欄位。所述指令亦可組態所述處理器以進行下述操作：經由RESTful服務將所述資料庫暴露於來自賣方入口網站的查詢；(自所述賣方入口網站)接收客戶端訂單，所述客戶端訂單包括來自所述多個虛擬配套的配套選擇；以及回應於接收到所述客戶端訂單，藉由下述操作更新所述多個虛擬配套：基於所述配套選擇來判定更新後的物件庫存，經由依序指定物件來再平衡所述多個虛擬配套從而使配套多樣性最大化，以及更新所述資料庫以修改物件庫存。此外，所述指令亦可組態所述處理器以進行下述操作：自所述至少一個履行中心接收更新後的庫存資料；以及基於所述更新後的庫存資料來再平衡所述資料庫中的所述多個配套。

本文中亦論述其他系統、方法以及電腦可讀媒體。

100、300:系統

101:運送授權技術系統

102A:行動裝置/使用者裝置

102B:電腦/使用者裝置

103:外部前端系統

105:內部前端系統

107:運輸系統

107A、107B、107C:行動裝置

109、702、702-1、702-2、702-3、702-4:賣方入口網站

111:運送及訂單追蹤系統

113:履行最佳化系統

115:履行通信報閘道

117:供應鏈管理系統

119:勞動力管理系統

119A:行動裝置/平板電腦

119B:行動裝置/PDA

119C:行動裝置/電腦

121A、121B、121C:第3方履行系統

123:履行中心授權系統

125:勞動管理系統

200:履行中心

201、222:卡車

202A、202B、208:物件

203:入站區

205:緩衝區

206:叉車

207:卸貨區

209:揀貨區

210:儲存單元

211:包裝區

213:樞紐區

214:運輸機構

215:營地區

216:牆

217:定位系統

217A、217B、217C:感測器

218、220:包裹

224A、224B:遞送工作者

226:汽車

310、310-1、310-2、310-3、310-4:FC/倉庫系統

320:平衡系統

322:平衡處理器

324:平衡資料庫

340:線上資源

350、350-1、350-2、350-3、350-4、350-5、350-6:客戶端裝置

360:第三方系統

370:網路

380:資料庫

402:處理器

404:輸入/輸出裝置

410:記憶體

412、512、602:程式

414:客戶端應用程式

416、514:資料

420:攝影機

430:指紋感測器

502、660:通信裝置

504:資料庫處理器

510:資料庫記憶體

604:快取資料

606:配套記錄

642:即時饋入模組

644:FC識別器

646:平衡模組

648:編碼器

700:庫存網路

704、802、902、902-1、902-2:訂單系統

708、804、904、906:全域庫存系統

800:不平衡庫存系統

806、918:倉庫-物件管理系統

808、808-1、808-2、908:配套系統

820、954:第一物件記錄

821、952:第二物件記錄

822、924:FC庫存饋入

900:平衡庫存系統

908-1:先前配套系統

908-2:更新後的平衡系統/更新後的配套系統

926:即時庫存饋入

928:庫存估計器

930、932、936、1102、1104、1106、1108、1110、1112、1114、1116、1118、1120、1122、1124、1126、1128、1130、1302、1304、1306、1308、1310、1312、1314、1316、1318、1320、1322、1324、1330、1402、1404、1406、1408、1410、1412、1414、1416、1418、 1420、1502、1504、1506、1508、1512、1514、1516、1518、1520、1522、1524、1526、1528、1530、1532、1534、1536、1602、1604、1606、1608、1610、1612、1614、1616、1702、1704、1706、1708、1710、1712、1714、1716、1718、1720、1802、1804、1806、1808、1810、1812、1814、1820、1822、1824:步驟

940:全域零售訂單履行系統

956:第二訂單

958:第一訂單

1000:虛擬配套再平衡操作

1010:第一虛擬配套

1012:兩個物件A配套

1014:三個物件A配套

1016:四個物件A配套

1018:五個物件A配套

1020:一個物件B配套

1022:三個物件B配套

1024:五個物件B配套

1050:第二虛擬配套

1100:過程流程

1200、1922:表

1202:物件ID欄位/配套識別欄位

1204:虛擬配套欄位/配套識別欄位

1206:配套類別欄位/配套識別欄位

1208:SKU欄位/配套識別欄位

1210:價格比率欄位/配套識別欄位

1212:配套數量欄位/配套識別欄位

1214:配套狀態欄位/配套識別欄位

1216:配套合併器欄位

1218:賣方產品ID欄位

1220:上載ID欄位

1222:營銷活動欄位

1230:虛擬配套

1300、1400、1500、1600、1700、1800:過程

1920:第一GUI

1930:第二GUI

1932:更新後的表

圖1A為與所揭露實施例一致的示出包含用於實現運送、運輸以及物流操作的通信的電腦化系統的網路的例示性實施例的示意性方塊圖。

圖1B描繪與所揭露實施例一致的包含滿足檢索請求的一或多個檢索結果以及交互式使用者介面元素的樣本檢索結果頁(Search Result Page；SRP)。

圖1C描繪與所揭露實施例一致的包含產品及關於所述產品的資訊以及交互式使用者介面元素的樣本單一顯示頁(Single Display Page；SDP)。

圖1D描繪與所揭露實施例一致的包含虛擬購物車中的物件以及交互式使用者介面元素的樣本購物車頁。

圖1E描繪與所揭露實施例一致的包含來自虛擬購物車的物件以及關於購買及運送的資訊以及交互式使用者介面元素的樣本訂單頁。

圖2為與所揭露實施例一致的經組態以利用所揭露電腦化系統的例示性履行中心的圖解圖示。

圖3為與所揭露實施例一致的例示性系統的示意性方塊圖。

圖4為與所揭露實施例一致的例示性客戶端裝置的方塊圖。

圖5為與所揭露實施例一致的例示性資料庫的方塊圖。

圖6為與所揭露實施例一致的例示性平衡系統的方塊圖。

圖7為與所揭露實施例一致的例示性庫存網路的方塊圖。

圖8A為與所揭露實施例一致的例示性不平衡庫存系統的方塊圖的第一部分。

圖8B為與所揭露實施例一致的例示性不平衡庫存系統的方塊圖的第二部分。

圖9A為與所揭露實施例一致的例示性平衡庫存系統的方塊圖的第一部分。

圖9B為與所揭露實施例一致的例示性平衡庫存系統的方塊圖的第二部分。

圖9C為與所揭露實施例一致的例示性平衡庫存系統的方塊圖的第三部分。

圖10為與所揭露實施例一致的虛擬配套再平衡操作的示意性表示。

圖11為與所揭露實施例一致的用於虛擬配套平衡的過程的時序圖。

圖12為與所揭露實施例一致的在儲存虛擬配套資訊的資料庫中的例示性表。

圖13為與所揭露實施例一致的用於基於可用庫存來管理虛擬配套的例示性過程的流程圖。

圖14為與所揭露實施例一致的用於用配套資訊填充及暴露資料庫的例示性過程的流程圖。

圖15為與所揭露實施例一致的用於指定履行中心及判定承諾遞送日期(promised delivery date；PDD)的例示性過程的流程圖。

圖16為與所揭露實施例一致的用於動態地再平衡虛擬配套庫存的例示性過程的流程圖。

圖17為與所揭露實施例一致的用於回應於客戶端訂單而動態地再平衡虛擬配套的例示性過程的流程圖。

圖18為示出根據所揭露實施例的用於產生機器學習預測模型的例示性過程的流程圖。

圖19為與所揭露實施例一致的在行動裝置中的一系列單一顯示頁例示性圖形使用者介面的正視圖。

以下詳細描述參考隨附圖式。只要可能，即在圖式及以下描述中使用相同附圖標號來指代相同或類似部分。儘管本文中描述若干示出性實施例，但修改、調適以及其他實施方案是可能的。舉例而言，可對圖式中所示出的組件及步驟進行替代、添加或修改，且可藉由取代、重新排序、移除步驟或將步驟添加至所揭露方法來修改本文中所描述的示出性方法。因此，以下詳細描述不限於所揭露實施例及實例。實情為，本發明的正確範圍由隨附申請專利範圍界定。

本揭露內容的實施例是針對用於動態庫存平衡及虛擬配套的自動化管理/再平衡的系統及方法。在一些實施例中，虛擬配套可為按配套組織以提供客製化定價的物件的虛擬或數位群組。一或多個物件可按對物件中的2個、3個、4個以及5個進行分組或對多個相關物件進行分組的不同虛擬配套來配套。舉例而言，可將香蕉按2個、3個、4個、5個......10個香蕉的配套分組。替代地，麵包可與花生醬一起配套。2個物件的虛擬配套可具有1美元(每物件0.50美元)的價格，而4個物件的虛擬配套可具有1.6美元(每物件0.40美元)的價格。另外，配套物件可具有比個別物件更低的價格。因此，虛擬配套具有相關聯分組數目或配套數量(亦即，配套中的物件的數目)、相關聯配套價格(亦即，配套物件的價格)以及相關聯每物件價格(亦即，配套中的每一物件的價格)。庫存的此組織允許零售商基於配套數量或組合來客製化或定製定價。舉例而言，在一些實施例中，隨著虛擬配套中的分組數目增加，每物件價格可減小，以激勵批量購買。所揭露系統及方法可藉由基於庫存資料饋入、客戶訂單及/或機器學習(machine-learning；ML)模型實現虛擬配套上的動態平衡以用於即時庫存更新及客製化清單來改良即時庫存管理的技術領域。

所揭露系統及方法的一些實施例可藉由採用介接客戶端及FC的平衡系統/服務即時維護平衡配套庫存來改良自動化庫存管理的領域。所揭露系統及方法可使用客戶訂單及預報ML模型來管理庫存資訊且改良庫存準確度，而非依賴於倉庫或FC庫存資料饋入以產生虛擬配套。舉例而言，所揭露系統及方法的一些實施例可允許基於(基於客戶訂單)所估計的庫存阻止網站中的錯誤缺貨(out-of-stock；OOS)清單來自動修改網站。在一些實施例中，一旦履行系統接收客戶端訂單，所揭露系統及方法即可藉由再平衡物件至不同配套的分配來不斷地更新物件配套。此類實施例藉由允許虛擬配套的再平衡而無需來自庫存資料饋入的通信或來自倉庫及FC的更新週期來改良自動化庫存管理的技術領域。此類實施例亦可藉由向資料庫提供用於促進網站中的客製化物件清單的產生的配套產品的聚合物件的即時資訊來改良零售商網站的產生。

此外，所揭露系統及方法亦可在更新庫存或再新網站時減少線上賣方的網路中的網路擁擠。舉例而言，所揭露系統及方法中的一些可藉由基於客戶訂單(而無需偵查(ping)或查詢FC處的庫存系統)即時計算可用庫存來使倉庫(或SC)與全域庫存系統之間的通信最小化。估計庫存(例如，經由虛擬配套的再平衡)允許在本端且即時地計算網路中的可用庫存，同時避免頻繁及大量地與網路中的多個FC進行通信交換。因此，所揭露系統及方法可藉由基於藉由客戶訂單觸發的再平衡而不必查詢FC以控制庫存更新來減少線上零售商的網路中的擁擠。

所揭露系統及方法亦可藉由提供快速及可程式化服務(其提供更新後的庫存資訊)來改良賣方網站或入口網站的產生。舉例而言，所揭露系統及方法中的一些可允許組態將更新後的庫存提供給賣方入口網站及履行系統兩者的集中式表現層狀態轉換(Representational State Transfer；REST)及/或佇列服務。此等服務可允許賣方入口網站及/或庫存系統按需求查詢庫存資料庫而無需等待FC或倉庫管理庫存更新。因此，所揭露系統及方法可使得能夠更快且更準確地產生零售商網站中的配套產品清單。此類實施例藉由提供允許產生客製化產品清單的更準確資訊來改良產生電子商務網站的領域。

此外，所揭露系統及方法亦可藉由允許庫存系統基於預報需求調適配套產品清單而基於客戶需求上之改良客製化網站的領域。舉例而言，所揭露系統及方法的某些實施例允許藉由監視購買及客戶行為而以高需求即時識別產品及配套。在一些實施例中，所揭露系統及方法可包含採用ML演算法基於先前訂單來預測對配套物件的需求。所揭露系統及方法可採用再平衡操作及ML模型對對於特定產品及配套的客戶端需求作出回應且使客戶保留最大化。舉例而言，所揭露系統及方法可用特定配套數量識別及/或預報對配套產品的增加的需求，且即時自動再平衡可用庫存以使客戶端的亂序錯誤最小化且使客戶端保留最大化。

現將詳細參考所揭露實施例，其實例示出於隨附圖式中。

圖1A繪示示出包含用於實現運送、運輸以及物流操作的通信的電腦化系統的系統的例示性實施例的系統100的示意性方塊圖。如圖1A中所示出，系統100可包含各種系統，所述系統中的每一者可經由一或多個網路彼此連接。所述系統亦可經由直接連接(例如，使用電纜)彼此連接。所描繪系統包含運送授權技術(shipment authority technology；SAT)系統101、外部前端系統103、內部前端系統105、運輸系統107、行動裝置107A、行動裝置107B以及行動裝置107C、賣方入口網站109、運送及訂單追蹤(shipment and order tracking；SOT)系統111、履行最佳化(fulfillment optimization；FO)系統113、履行通信報閘道(fulfillment messaging gateway；FMG)115、供應鏈管理(supply chain management；SCM)系統117、勞動力管理系統119、行動裝置119A、行動裝置119B以及行動裝置119C(描繪為在履行中心(FC)200內部)、第3方履行系統121A、第3方履行系統121B以及第3方履行系統121C、履行中心授權系統(fulfillment center authorization；FC Auth)123以及勞動管理系統(labor management system；LMS)125。

在一些實施例中，SAT系統101可實行為監視訂單狀態及遞送狀態的電腦系統。舉例而言，SAT系統101可判定訂單是否超過其承諾遞送日期(PDD)且可採取適當的動作，包含發起新訂單、對未遞送訂單中的物件進行重新運送、取消未遞送訂單、發起與訂購客戶的連絡，或類似者。SAT系統101亦可監視其他資料，包含輸出(諸如在特定時間段期間運送的包裹的數目)及輸入(諸如接收到的用於運送的空紙板盒的數目)。SAT系統101 亦可充當系統100中的不同裝置之間的閘道，從而(例如，使用儲存及轉發或其他技術)實現諸如外部前端系統103及FO系統113的裝置之間的通信。

另外，在一些實施例中，SAT系統101可處於通信中且控制追蹤及/或儲存倉儲於FC中的產品的物件定位系統。舉例而言，SAT系統101可控制追蹤FC的多個虛擬位置的產品的位置的系統，如關於圖14進一步描述。

在一些實施例中，外部前端系統103可實行為使得外部使用者能夠與系統100中的一或多個系統交互的電腦系統。舉例而言，在系統100使得系統的呈現能夠允許使用者針對物件下訂單的實施例中，外部前端系統103可實行為接收檢索請求、呈現物件頁以及索求支付資訊的網頁伺服器。舉例而言，外部前端系統103可實行為電腦或電腦運行軟體，諸如阿帕奇(Apache)HTTP伺服器、微軟網際網路資訊服務(Internet Information Service；IIS)、NGINX，或類似者。在其他實施例中，外部前端系統103可運行經設計以接收及處理來自外部裝置(例如，行動裝置102A或電腦102B)的請求、基於彼等請求自資料庫及其他資料儲存庫獲取資訊，以及基於所獲取的資訊將回應提供至接收到的請求的定製網頁伺服器軟體。

在一些實施例中，外部前端系統103可包含網頁快取系統、資料庫、檢索系統或支付系統中的一或多者。在一個態樣中，外部前端系統103可包含此等系統中的一或多者，而在另一態樣中，外部前端系統103可包含連接至此等系統中的一或多者的介面(例如，伺服器至伺服器、資料庫至資料庫，或其他網路連接)。

藉由圖1B、圖1C、圖1D以及圖1E所示出的例示性步驟集合將有助於描述外部前端系統103的一些操作。外部前端系統103可自系統100中的系統或裝置接收資訊以供呈現及/或顯示。舉例而言，外部前端系統103可代管或提供一或多個網頁，包含檢索結果頁(SRP)(例如，圖1B)、單一詳情頁(Single Detail Page；SDP)(例如，圖1C)、購物車頁(例如，圖1D)，或訂單頁(例如，圖1E)。(例如，使用行動裝置102A或電腦102B的)使用者裝置可導航至外部前端系統103且藉由將資訊輸入至檢索盒中來請求檢索。外部前端系統103可向系統100中的一或多個系統請求資訊。舉例而言，外部前端系統103可向FO系統113請求滿足檢索請求的資訊。外部前端系統103亦可(自FO系統113)請求及接收包含於檢索結果中的每一產品的承諾遞送日期或「PDD」。在一些實施例中，PDD可表示在特定時間段內(例如，在一天結束(下午11：59)前)訂購的情況下對含有產品的包裹將何時抵達使用者的所要位置或承諾將產品遞送至使用者的所要位置處的日期的估計。(PDD在下文相對於FO系統113進一步論述。)在一些實施例中，FO系統113亦可與FC的產品定位系統通信。在此類實施例中，FO系統113可具有產品的精確資訊、假定的遞送日期、可用遞送選項以及遞送選項中的每一者的截止時間。

外部前端系統103可基於資訊來準備SRP(例如，圖1B)。SRP可包含滿足檢索請求的資訊。舉例而言，此可包含滿足檢索請求的產品的圖像。SRP亦可包含每一產品的各別價格，或與每一產品的增強遞送選項、PDD、重量、大小、報價、折扣或類似者相關的資訊。外部前端系統103可(例如，經由網路)將SRP發送至請求使用者裝置。

使用者裝置可接著例如藉由點選或輕觸使用者介面或使用另一輸入裝置自SRP選擇產品，以選擇表示於SRP上的產品。使用者裝置可製訂對關於所選產品的資訊的請求且將其發送至外部前端系統103。作為回應，外部前端系統103可請求與所選產品相關的資訊。舉例而言，資訊可包含除針對各別SRP上的產品呈現的資訊以外的額外資訊。另外，資訊可包含產品在FC內的位置及用於運送及遞送的所估計所需時間。此可包含例如貨架或托板位置、保存期限、原產國、重量、大小、包裹中的物件的數目、處置說明，或關於產品的其他資訊。資訊亦可包含類似產品的推薦(基於例如巨量資料及/或對購買此產品及至少一個其他產品的客戶的機器學習分析)、頻繁詢問的問題的答案、來自客戶的評論、製造商資訊、圖像，或類似者。

外部前端系統103可基於接收到的產品資訊來準備SDP(單一詳情頁)(例如，圖1C)。SDP亦可包含其他交互式元素，諸如「現在購買」按鈕、「添加至購物車」按鈕、數量欄位、物件的圖像，或類似者。SDP可更包含提供產品的賣方的清單。可基於每一賣方提供的價格來對清單進行排序，使得可在頂部處列出提供以最低價格出售產品的賣方。亦可基於賣方排名來對清單進行排序，使得可在頂部處列出排名最高的賣方。可基於多個因素來製訂賣方排名，所述因素包含例如賣方的符合承諾PDD的過去的追蹤記錄。外部前端系統103可(例如，經由網路)將SDP遞送至請求使用者裝置。

請求使用者裝置可接收列出產品資訊的SDP。在接收到SDP後，使用者裝置可接著與SDP交互。舉例而言，請求使用者裝置的使用者可點選或以其他方式與SDP上的「放在購物車中」按鈕交互。此將產品添加至與使用者相關聯的購物車。使用者裝置可將把產品添加至購物車的此請求傳輸至外部前端系統103。

外部前端系統103可產生購物車頁(例如，圖1D)。在一些實施例中，購物車頁列出使用者已添加至虛擬「購物車」的產品。使用者裝置可藉由在SRP、SDP或其他頁上的圖標上點選或以其他方式與所述圖標交互來請求購物車頁。在一些實施例中，購物車頁可列出使用者已添加至購物車的所有產品，以及關於購物車中的產品的資訊(諸如每一產品的數量、每一產品每物件的價格、每一產品基於相關聯數量的價格)、關於PDD的資訊、遞送方法、運送成本、用於修改購物車中的產品(例如，刪除或修改數量)的使用者介面元素、用於訂購其他產品或設置產品的定期遞送的選項、用於設置利息支付的選項、用於前進至購買的使用者介面元素，或類似者。使用者裝置處的使用者可在使用者介面元素(例如，寫著「現在購買」的按鈕)上點選或以其他方式與所述使用者介面元素交互，以發起對購物車中的產品的購買。在如此做後，使用者裝置可將發起購買的此請求傳輸至外部前端系統103。

外部前端系統103可回應於接收到發起購買的請求而產生訂單頁(例如，圖1E)。在一些實施例中，訂單頁重新列出來自購物車的物件且請求支付及運送資訊的輸入。舉例而言，訂單頁可包含請求關於購物車中的物件的購買者的資訊(例如，姓名、地址、電子郵件地址、電話號碼)、關於接收者的資訊(例如，姓名、地址、電話號碼、遞送資訊)、運送資訊(例如，遞送及/或揀貨的速度/方法)、支付資訊(例如，信用卡、銀行轉賬、支票、儲存的積分)的部分、請求現金收據(例如，出於稅務目的)的使用者介面元素，或類似者。外部前端系統103可將訂單頁發送至使用者裝置。

使用者裝置可輸入關於訂單頁的資訊，且點選或以其他方式與將資訊發送至外部前端系統103的使用者介面元素交互。自此處，外部前端系統103可將資訊發送至系統100中的不同系統，以使得能夠創建及處理具有購物車中的產品的新訂單。

在一些實施例中，外部前端系統103可進一步經組態以使得賣方能夠傳輸及接收與訂單相關的資訊。舉例而言，外部前端系統103可允許賣方傳輸特定產品的所估計包裝時間及/或可用遞送選項。

在一些實施例中，內部前端系統105可實行為使得內部使用者(例如，擁有、操作或租用系統100的組織的雇員)能夠與系統100中的一或多個系統交互的電腦系統。舉例而言，在SAT系統101使得系統的呈現能夠允許使用者針對物件下訂單的實施例中，內部前端系統105可實行為使得內部使用者能夠查看關於訂單的診斷及統計資訊、修改物件資訊或審查與訂單相關的統計的網頁伺服器。舉例而言，內部前端系統105可實行為電腦或電腦運行軟體，諸如阿帕奇HTTP伺服器、微軟網際網路資訊服務(IIS)、NGINX，或類似者。在其他實施例中，內部前端系統105可運行經設計以接收及處理來自系統100中所描繪的系統或裝置 (以及未描繪的其他裝置)的請求、基於彼等請求自資料庫及其他資料儲存庫獲取資訊，以及基於所獲取的資訊來將回應提供至接收到的請求的定製網頁伺服器軟體。

在一些實施例中，內部前端系統105可包含網頁快取系統、資料庫、檢索系統、支付系統、分析系統、訂單監視系統或類似者中的一或多者。在一個態樣中，內部前端系統105可包含此等系統中的一或多者，而在另一態樣中，內部前端系統105可包含連接至此等系統中的一或多者的介面(例如，伺服器至伺服器、資料庫至資料庫，或其他網路連接)。在一些實施例中，內部前端系統105可經組態以引導FC的工作者將物件置放於特定位置中。舉例來說，在一些實施例中，SAT系統101可經組態以進行預測演算法以識別具有用特殊遞送選項請求的更大似然的產品。舉例而言，SAT系統101可經組態以識別最可能請求黎明遞送或第一時間遞送的產品。在此類實施例中，內部前端系統105可與SAT系統101通信且為工作者產生網站及/或使用者介面，所述網站及/或使用者介面導引FC內的產品置放，目的為改良遞送時間且使可用於黎明、新鮮或第一時間遞送的產品的數目最大化。

在一些實施例中，運輸系統107可實行為實現系統100中的系統或裝置與行動裝置107A至行動裝置107C之間的通信的電腦系統。在一些實施例中，運輸系統107可自一或多個行動裝置107A至行動裝置107C(例如，行動電話、智慧型電話、PDA，或類似者)接收資訊。舉例而言，在一些實施例中，行動裝置107A至行動裝置107C可包含由遞送工作者操作的裝置。遞送工作者(其可為永久雇員、暫時雇員或輪班雇員)可利用行動裝置107A 至行動裝置107C來實現對含有由使用者訂購的產品的包裹的遞送。舉例而言，為遞送包裹，遞送工作者可在行動裝置上接收指示遞送哪一包裹及將所述包裹遞送到何處的通知。在抵達遞送位置後，遞送工作者可(例如，在卡車的後部中或在包裹的條板箱中)定位包裹、使用行動裝置掃描或以其他方式擷取與包裹上的識別符(例如，條碼、影像、文字字串、RFID標籤，或類似者)相關聯的資料，且遞送包裹(例如，藉由將其留在前門處、將其留給警衛、將其交給接收者，或類似者)。在一些實施例中，遞送工作者可使用行動裝置擷取包裹的相片及/或可獲得簽名。行動裝置可將資訊發送至運輸系統107，所述資訊包含關於遞送的資訊，包含例如時間、日期、GPS位置、相片、與遞送工作者相關聯的識別符、與行動裝置相關聯的識別符，或類似者。運輸系統107可在資料庫(未描繪)中儲存此資訊以用於由系統100中的其他系統存取。在一些實施例中，運輸系統107可使用此資訊來準備追蹤資料且將所述追蹤資料發送至其他系統，從而指示特定包裹的位置。

在一些實施例中，某些使用者可使用一個種類的行動裝置(例如，永久工作者可使用具有定製硬體(諸如條碼掃描器、尖筆以及其他裝置)的專用PDA)，而其他使用者可使用其他類型的行動裝置(例如，暫時工作者或輪班工作者可利用現成的行動電話及/或智慧型電話)。

在一些實施例中，運輸系統107可使使用者與每一裝置相關聯。舉例而言，運輸系統107可儲存使用者(由例如使用者識別符、雇員識別符或電話號碼表示)與行動裝置(由例如國際行動設備身分(International Mobile Equipment Identity；IMEI)、國際行動訂用識別符(International Mobile Subscription Identifier；IMSI)、電話號碼、通用唯一識別符(Universal Unique Identifier；UUID)或全球唯一識別符(Globally Unique Identifier；GUID)表示)之間的關聯。運輸系統107可結合在遞送時接收到的資料使用此關聯來分析儲存於資料庫中的資料，以便尤其判定工作者的位置、工作者的效率，或工作者的速度。

在一些實施例中，賣方入口網站109可實行為使得賣方或其他外部實體能夠與系統100中的一或多個系統電子地通信的電腦系統。舉例而言，賣方可利用電腦系統(未描繪)來上載或提供賣方希望經由使用賣方入口網站109的系統100來出售的產品的產品資訊、訂單資訊、連絡資訊或類似者。

在一些實施例中，運送及訂單追蹤系統111可實行為接收、儲存以及轉送關於含有由客戶(例如，由使用裝置102A至裝置102B的使用者)訂購的產品的包裹的位置的資訊的電腦系統。在一些實施例中，運送及訂單追蹤系統111可請求或儲存來自由遞送含有由客戶訂購的產品的包裹的運送公司操作的網頁伺服器(未描繪)的資訊。

在一些實施例中，運送及訂單追蹤系統111可請求及儲存來自在系統100中描繪的系統的資訊。舉例而言，運送及訂單追蹤系統111可請求來自運輸系統107的資訊。如上文所論述，運輸系統107可自與一或多個使用者(例如，遞送工作者)或車輛(例如，遞送卡車)相關聯的一或多個行動裝置107A至行動裝置107C(例如，行動電話、智慧型電話、PDA或類似者)接收資訊。在一些實施例中，運送及訂單追蹤系統111亦可請求來自勞動力管理系統(workforce management system；WMS)119的資訊以判定個別產品在履行中心(例如，履行中心200)的內部的位置。運送及訂單追蹤系統111可向運輸系統107或WMS 119中的一或多者請求資料，在請求後處理所述資料，且將所述資料呈現給裝置(例如，使用者裝置102A及使用者裝置102B)。

在一些實施例中，履行最佳化(FO)系統113可實行為儲存來自其他系統(例如，外部前端系統103及/或運送及訂單追蹤系統111)的客戶訂單的資訊的電腦系統。FO系統113亦可儲存描述特定物件保存或儲存於何處的資訊。舉例而言，某些物件可能僅儲存於一個履行中心中，而某些其他物件可能儲存於多個履行中心中。在再其他實施例中，某些履行中心可經設計以僅儲存特定物件集合(例如，新鮮生產或冷凍的產品)。FO系統113儲存此資訊以及相關聯資訊(例如，數量、大小、接收日期、過期日期等)。

FO系統113亦可計算每一產品的對應截止時間(特定遞送時間的最大時間)及/或PDD(承諾遞送日期)。在一些實施例中，截止時間及PDD可以基於一或多個因素。舉例而言，FO系統113可基於下述者來計算產品的PDD：對產品的過去需求(例如，在一段時間期間訂購了多少次所述產品)、對產品的預期需求(例如，預報在即將到來的一段時間期間多少客戶將訂購所述產品)、指示在一段時間期間訂購了多少產品的全網路過去需求、指示預期在即將到來的一段時間期間將訂購多少產品的全網路預期需求、儲存於每一履行中心200中的產品的一或多個計數、哪一履行中心儲存每一產品、產品的預期或當前訂單，或類似者。另外，FO系統113可基於過去遞送、產品位置與運送中心之間的實體距離以及FC的位置處的可用人員以及其他來計算截止時間。

在一些實施例中，FO系統113可定期(例如，每小時)判定每一產品的截止時間及PDD且將其儲存於資料庫中以供取回或發送至其他系統(例如，外部前端系統103、SAT系統101、運送及訂單追蹤系統111)。在其他實施例中，FO系統113可自一或多個系統(例如，外部前端系統103、SAT系統101、運送及訂單追蹤系統111)接收電子請求且按需求計算PDD或截止時間。在另外其他實施例中，FO系統113可在使用者瀏覽網站中的一者時判定PDD及截止時間。關於圖7進一步描述由FO系統113計算及傳輸PDD或截止時間的過程。

在一些實施例中，履行通信報閘道(FMG)115可實行為自系統100中的一或多個系統(諸如FO系統113)接收呈一種格式或協定的請求或回應、將其轉換為另一格式或協定且將其以轉換後的格式或協定轉發至其他系統(諸如WMS 119或第3方履行系統121A、第3方履行系統121B或第3方履行系統121C)且反之亦然的電腦系統。

在一些實施例中，供應鏈管理(SCM)系統117可實行為進行預報功能的電腦系統。舉例而言，SCM系統117可基於例如下述者來預報對特定產品的需求水平：對產品的過去需求、對產品的預期需求、全網路過去需求、全網路預期需求、儲存於每一履行中心200中的計數產品、每一產品的預期或當前訂單，或類似者。回應於此預報水平及所有履行中心中的每一產品的量， SCM系統117可產生一或多個購買訂單以購買及儲備足夠數量，以滿足對特定產品的預報需求。

在一些實施例中，勞動力管理系統(WMS)119可實行為監視工作流程的電腦系統。舉例而言，WMS 119可自個別裝置(例如，裝置107A至裝置107C或裝置119A至裝置119C)接收指示離散事件的事件資料。舉例而言，WMS 119可接收指示使用此等裝置中的一者來掃描包裹或已觸發定位系統的感測器的事件資料。如下文相對於履行中心200及圖2所論述，在履行過程期間，可藉由特定階段處的機器(例如，自動式或手持式條碼掃描器、RFID讀取器、高速攝影機、諸如平板電腦119A、行動裝置/PDA119B、電腦119C的裝置或類似者)掃描或讀取包裹識別符(例如，條碼或RFID標籤資料)。替代地，無線感測器可判定已將產品置入貨架或取出貨架。WMS 119可將指示掃描、包裹標識符的讀取或感測器事件的每一事件以及包裹識別符、時間、日期、位置、使用者識別符或其他資訊儲存於對應資料庫(未描繪)中，且可將此資訊提供至其他系統(例如，運送及訂單追蹤系統111)。

在一些實施例中，WMS 119可儲存使一或多個裝置(例如，裝置107A至裝置107C或裝置119A至裝置119C)與一或多個使用者(所述一或多個使用者與系統100相關聯)相關聯的資訊。舉例而言，在一些情形下，使用者(諸如兼職雇員或全職雇員)可與行動裝置相關聯，此是由於使用者擁有行動裝置(例如，行動裝置為智慧型電話)。在其他情形下，使用者可與行動裝置相關聯，此是由於使用者暫時保管行動裝置(例如，使用者在一天開始時拿到行動裝置，將在一天期間使用所述行動裝置，且將在一天結束時退還所述行動裝置)。

在一些實施例中，WMS 119可維護與系統100相關聯的每一使用者的工作日志。舉例而言，WMS 119可儲存與每一雇員相關聯的資訊，包含任何指定的過程(例如，自卡車卸載、自揀貨區揀取物件、合流牆(rebin wall)工作、包裝物件)、使用者識別符、位置(例如，履行中心200中的樓層或區)、藉由雇員經由系統移動的單位數目(例如，所揀取物件的數目、所包裝物件的數目)、與裝置(例如，裝置119A至裝置119C)相關聯的識別符，或類似者。在一些實施例中，WMS 119可自計時系統接收登記及登出資訊，所述計時系統諸如在裝置119A至裝置119C上操作的計時系統。

在一些實施例中，第3方履行(3rd party fulfillment；3PL)系統121A至第3方履行系統121C表示與物流及產品的第三方提供商相關聯的電腦系統。舉例而言，儘管一些產品儲存於履行中心200中(如下文相對於圖2所論述)，但其他產品可儲存於場外、可按需求生產，或可以其他方式不可供用於儲存於履行中心200中。3PL系統121A至3PL系統121C可經組態以(例如，經由FMG 115)自FO系統113接收訂單，且可直接為客戶提供產品及/或服務(例如，遞送或安裝)。在一些實施例中，3PL系統121A至3PL系統121C中的一或多者可為系統100的部分，而在其他實施例中，3PL系統121A至3PL系統121C中的一或多者可在系統100外部(例如，由第三方提供商擁有或操作)。

在一些實施例中，履行中心Auth系統(FC Auth)123可實行為具有各種功能的電腦系統。舉例而言，在一些實施例中， FC Auth 123可充當系統100中的一或多個其他系統的單一簽入(single-sign on；SSO)服務。另外，FC Auth 123可使得使用者能夠經由內部前端系統105登入、判定使用者具有存取運送及訂單追蹤系統111處的資源的類似特權，且使得使用者能夠在不需要第二登入過程的情況下取得彼等特權。在其他實施例中，FC Auth 123可使得使用者(例如，雇員)能夠使自身與特定任務相關聯。舉例而言，一些雇員可能不具有電子裝置(諸如裝置119A至裝置119C)，且實際上可能在一天的過程期間在履行中心200內自任務至任務以及自區至區移動。FC Auth 123可經組態以使得彼等雇員能夠在一天的不同時間指示其正進行何任務以及其位於何區。

在一些實施例中，勞動管理系統(LMS)125可實行為儲存雇員(包含全職雇員及兼職雇員)的出勤及超時資訊的電腦系統。舉例而言，LMS 125可自FC Auth 123、WMA 119、裝置119A至裝置119C、運輸系統107及/或裝置107A至裝置107C接收資訊。

圖1A中所描繪的特定組態僅為實例。舉例而言，儘管圖1A描繪連接至FO系統113的FC Auth系統123，但並非所有實施例均要求此特定組態。實際上，在一些實施例中，系統100中的系統可經由一或多個公用或私用網路彼此連接，所述網路包含網際網路、企業內部網路、廣域網路(Wide-Area Network；WAN)、都會區域網路(Metropolitan-Area Network；MAN)、順應IEEE 802.11a/b/g/n標準的無線網路、租用線，或類似者。在一些實施例中，系統100中的系統中的一或多者可實行為在資料中心、伺服器群或類似者處實行的一或多個虛擬伺服器。

圖2描繪履行中心200。履行中心(FC)200為儲存用於在訂購時運送至客戶的物件的實體位置的實例。可將履行中心(FC)200劃分成多個區，所述區中的每一者描繪於圖2中。在一些實施例中，可認為此等「區」為接收物件、儲存物件、取回物件以及運送物件的過程的不同階段之間的虛擬劃分。因此，儘管在圖2中描繪「區」，但其他區劃分為可能的，且在一些實施例中可省略、複製及/或修改圖2中的區。

入站區203表示FC 200的自希望使用系統100(圖1A)出售產品的賣方接收到物件的區域。舉例而言，賣方可使用卡車201來遞送物件202A及物件202B。物件202A可表示足夠大以佔據其自身運送托板的單一物件，而物件202B可表示在同一托板上堆疊在一起以節省空間的物件集合。

工作者將在入站區203中接收物件，且可使用電腦系統(未描繪)來視情況檢查物件的損壞及正確性。舉例而言，工作者可使用電腦系統來比較物件202A及物件202B的數量與物件的所訂購數量。若數量不匹配，則工作者可拒絕物件202A或物件202B中的一或多者。若數量的確匹配，則工作者可(使用例如台車、手推平車、叉車或手動地)將彼等物件移動至緩衝區205。緩衝區205可為當前(例如由於揀貨區中存在足夠高數量的物件以滿足預報需求而)無需處於揀貨區中的所述物件的暫時儲存區域。在一些實施例中，叉車206操作以圍繞緩衝區205及在入站區203與卸貨區207之間移動物件。若(例如，由於預報需求而)需要揀貨區中的物件202A或物件202B，則叉車可將物件202A或物件202B移動至卸貨區207。

卸貨區207可為FC 200的在將物件移動至揀貨區209之前儲存所述物件的區域。指定給揀貨任務的工作者(「揀貨員」)可靠近揀貨區中的物件202A及物件202B，使用行動裝置(例如，裝置119B)來掃描揀貨區的條碼，且掃描與物件202A及物件202B相關聯的條碼。此事件可更新即時位置系統，所述即時位置系統更新資料庫以指明物件已移動至FC中。揀貨員可接著(例如，藉由將物件置放於推車上或攜帶所述物件)將所述物件取至揀貨區209，且即時位置系統可請求用於新物件的儲存位置。

揀貨區209可為FC 200的將物件208儲存於儲存單元210上的區域。在一些實施例中，儲存單元210可包含實體擱架、書架、盒、手提包、冰箱、冷凍機、冷儲存區或類似者中的一或多者。在一些實施例中，揀貨區209可組織成多個樓層。在一些實施例中，工作者或機器可以多種方式將物件移動至揀貨區209中，包含例如叉車、電梯、傳送帶、推車、手推平車、台車、自動化機器人或裝置，或手動地移動。舉例而言，揀貨員可在卸貨區207中將物件202A及物件202B置放於手推平車或推車上，且將物件202A及物件202B步移至揀貨區209。

揀貨員可接收將物件置放(或「堆裝」)於揀貨區209中的特定點(諸如儲存單元210上的特定空間)的指令。舉例而言，揀貨員可使用行動裝置(例如，裝置119B)來掃描物件202A。裝置可例如使用指示走道、貨架以及位置的系統來指示揀貨員應將物件202A堆裝於何處。在一些實施例中，可基於嘗試使特殊遞送選項(諸如黎明遞送)的可用性最大化的預測演算法來判定堆裝物件202A的位置。裝置可接著提示揀貨員在將物件202A堆裝於所述位置之前掃描所述位置處的條碼。替代地，與影像辨識耦接的無線感測器或攝影機可儲存時間的位置。在一些實施例中，裝置可(例如，經由無線網路)將資料發送至圖1A中的諸如WMS 119的電腦系統，從而指示已由使用裝置119B的使用者將物件202A堆裝於所述位置處。

一旦使用者下訂單，揀貨員即可在裝置119B上接收自儲存單元210取回一或多個物件208的指令。在一些實施例中，如結合圖11進一步描述，揀貨員可經由置放或儲存導引接收堆裝產品的指令。揀貨員可取回物件208、掃描物件208上的條碼，且將所述物件208置放於運輸機構214上。儘管將運輸機構214表示為滑動件，但在一些實施例中，運輸機構可實行為傳送帶、電梯、推車、叉車、手推平車、台車或類似者中的一或多者。物件208可接著抵達包裝區211。

包裝區211可為FC 200的自揀貨區209接收到物件且將所述物件包裝至盒或包中以用於最終運送至客戶的區域。在包裝區211中，指定給接收物件的工作者(「合流工作者」)將自揀貨區209接收物件208且判定所述物件208對應於哪一訂單。舉例而言，合流工作者可使用諸如電腦119C的裝置來掃描物件208上的條碼。電腦119C可在視覺上指示物件208與哪一訂單相關聯。此可包含例如對應於訂單的牆216上的空間或「單元格」。一旦訂單完成(例如，由於單元格含有所述訂單的所有物件)，合流工作者即可指示包裝工作者(或「包裝員」)訂單完成。包裝員可自單元格取回物件且將所述物件置放於盒或包中以用於運送。包裝員可接著例如經由叉車、推車、台車、手推平車、傳送帶、手動地或以其他方式將盒或包發送至樞紐區(hub zone)213。

樞紐區213可為FC 200的自包裝區211接收所有盒或包(「包裹」)的區域。樞紐區213中的工作者及/或機器可取回包裹218且判定每一包裹預期去至遞送區域的哪一部分，且將包裹投送至適當的營地區(camp zone)215。舉例而言，若遞送區域具有兩個更小子區域，則包裹將去至兩個營地區215中的一者。在一些實施例中，工作者或機器可(例如，使用裝置119A至裝置119C中的一者)掃描包裹以判定其最終目的地。將包裹投送至營地區215可包含例如(例如，基於郵遞碼)判定包裹去往的地理區域的一部分，以及判定與地理區域的所述部分相關聯的營地區215。

在一些實施例中，營地區215可包含一或多個建築物、一或多個實體空間或一或多個區域，其中自樞紐區213接收包裹以用於分揀至路線及/或子路線中。在一些實施例中，營地區215與FC 200實體地分開，而在其他實施例中，營地區215可形成FC 200的一部分。

營地區215中的工作者及/或機器可例如基於下述者來判定包裹220應與哪一路線及/或子路線相關聯：目的地與現有路線及/或子路線的比較、對每一路線及/或子路線的工作負荷的計算、時刻、運送方法、運送包裹220的成本、與包裹220中的物件相關聯的PDD、遞送選項，或類似者。在一些實施例中，工作者或機器可(例如，使用裝置119A至裝置119C中的一者)掃描包裹以判定其最終目的地。一旦將包裹220指定給特定路線及/或子路線，工作者及/或機器即可移動待運送的包裹220。在例示性圖2中，營地區215包含卡車222、汽車226以及遞送工作者224A及遞送工作者224B。在一些實施例中，卡車222可由遞送工作者224A駕駛，其中遞送工作者224A為遞送FC 200的包裹的全職雇員，且卡車222由擁有、租用或操作FC 200的同一公司擁有、租用或操作。在一些實施例中，汽車226可由遞送工作者224B駕駛，其中遞送工作者224B為在視需要基礎上(例如，季節性地)遞送的「靈活」或臨時工作者。汽車226可由遞送工作者224B擁有、租用或操作。

在一些實施例中，如圖2中所繪示，FC 200的部分中的一或多者可包含定位系統217。定位系統217可包含多個感測器，所述多個感測器可用於判定產品在FC內的位置且追蹤所述產品經由FC的移動。在此類實施例中，定位系統217的感測器可用於下述兩者：追蹤產品在FC中的位置以及亦估計不同部分之間的移動。舉例而言，定位系統217的感測器可用於儲存在FC 200的不同區之間經過的時間的歷史資料。此資訊可接著用於判定儲存區與包裝區之間的距離或所估計時間。

如圖2中所繪示，定位系統217可包含包裝區211中的感測器217A、揀貨區209中的感測器217B，以及卸貨區205中的感測器217C。然而，可將更多感測器置放於FC 200的不同區中，其目的為追蹤及擷取物件FC 200的位置，以及改良所估計遞送的準確度或使遞送選項的可用性最大化。

圖3為與所揭露實施例一致的例示性系統300的方塊圖。在系統300中，平衡系統320可即時處理庫存資料饋入及客戶端購買，以例如判定可用庫存且平衡虛擬配套。系統300可包含平衡系統320、線上資源340、客戶端裝置350、第三方系統360、 FC/倉庫系統310以及資料庫380。在一些實施例中，如圖3中所繪示，系統300的組件可連接至網路370。然而，在其他實施例中，系統300的組件可直接彼此連接而無需網路370。舉例而言，資料庫380可直接耦接至平衡系統320。

在一些實施例中，平衡系統320可用系統100(圖1A)的組件中的一或多者實行。舉例而言，平衡系統320可包含SAT系統101、外部前端系統103、FO系統113、SCM系統117及/或WMS 119(圖1A)。在其他實施例中，平衡系統320可用一或多個獨立伺服器實行，所述一或多個獨立伺服器經組態以進行用於自倉庫(諸如FC/倉庫系統310)、客戶端訂單(例如，來自客戶端裝置350)以及第三方訂單(例如，來自第三方系統360)收集庫存資料且估計可用庫存以平衡虛擬配套，且為外部系統提供資訊以產生可顯示於客戶端裝置350中的賣方入口網站的操作。

平衡系統320可包含平衡資料庫324及平衡處理器322。平衡資料庫324可用任何儲存系統或裝置實行，所述儲存系統或裝置經組態以儲存可用物件且管理虛擬配套的物件的分組。平衡處理器322可包含任何處理裝置，諸如CPU、GPU及/或FPGA，所述處理裝置經組態以處理來自系統300中的其他元件的資訊及更新平衡資料庫324中的庫存資料及/或虛擬配套的配置。此外，在一些實施例中，平衡處理器322可經組態以產生用於在客戶端裝置中產生或修改網站的指令碼或指令。舉例而言，在一些實施例中，平衡處理器322可經組態以在平衡資料庫324中的虛擬配套或總庫存中存在更新的任何時候產生網站更新或再新。結合圖6進一步論述平衡系統320、平衡資料庫324以及平衡處理器322。

線上資源340可包含藉由實體提供的一或多個伺服器或儲存服務，所述實體諸如網站託管、網路連接、雲端或備份服務的提供商。在一些實施例中，線上資源340可與儲存用於鑑認服務、網域名稱系統(Domain Name System；DNS)或登陸頁的網頁的託管服務或伺服器相關聯。在其他實施例中，線上資源340可與雲端計算服務相關聯。在另外其他實施例中，線上資源340可與通信報服務相關聯，諸如(例如)蘋果推播通知服務(Apple Push Notification Service)、天藍行動服務(Azure Mobile Services)或谷歌雲端通信報(Google Cloud Messaging)。在此類實施例中，線上資源340可處置與所揭露實施例的功能相關的訊息及通知的遞送，諸如處置數位權利的管理。

客戶端裝置350可包含經組態以進行與所揭露實施例一致的一或多個操作的一或多個計算裝置。舉例而言，客戶端裝置350可包含桌上型電腦、膝上型電腦、伺服器、行動裝置(例如，平板電腦、智慧型電話等)、機上盒、遊戲裝置、隨身計算裝置或其他類型的計算裝置。在一些實施例中，客戶端裝置350可包含使用者裝置102(圖1A)且作為系統100的部分操作。然而，在其他實施例中，客戶端裝置350可獨立於系統100。客戶端裝置350可包含經組態以執行儲存於記憶體(諸如包含於客戶端裝置350中的記憶體)中的軟體指令以進行操作以實行下文所描述功能的一或多個處理器。舉例而言，客戶端裝置350可經組態以基於平衡系統320的資訊在網站中顯示圖形使用者介面，所述圖形使用者介面包含按一或多個配套配置且描述配套數量、配套價格及/或每單價的產品清單。舉例而言，在一些實施例中，客戶端裝置 350可基於自平衡系統320接收到的資訊來產生類似於關於圖19所描述的圖形使用者介面的圖形使用者介面。另外，客戶端裝置350可經組態以用於有線及/或無線通信，且可包含在由處理器執行時進行網際網路相關通信(例如，TCP/IP)及內容顯示過程的軟體。舉例而言，客戶端裝置350可執行產生及顯示具有產品資訊的介面的瀏覽器軟體。因此，客戶端裝置350可執行允許客戶端裝置350經由網路370與組件通信且經由包含於客戶端裝置350中的顯示裝置在介面中顯示內容的應用程式。

在一些實施例中，如關於圖4進一步揭露，客戶端裝置350可運行具體而言經組態以與平衡系統320交互的應用程式。此外，客戶端裝置350可儲存一或多個帳戶。舉例而言，客戶端裝置350可儲存關於客戶的遞送偏好、客戶的位置、客戶帳戶以及客戶識別的資訊。

所揭露實施例不限於客戶端裝置350的任何特定組態。舉例而言，客戶端裝置350可為儲存及執行行動應用程式以進行操作的行動裝置，所述操作提供由平衡系統320及/或線上資源340提供的功能。結合圖4進一步描述客戶端裝置350。

資料庫380可包含一或多個計算裝置，所述一或多個計算裝置經組態有適當軟體以進行與提供用於判定可用庫存的平衡系統320資料一致的操作且產生虛擬配套。資料庫380可包含例如甲骨文^TM(Oracle^TM)資料庫、賽貝斯^TM(Sybase^TM)資料庫或其他關連式資料庫或非關連式資料庫，諸如Hadoop^TM序列檔案、HBase^TM或Cassandra^TM。資料庫380可包含計算組件(例如，資料庫管理系統、資料庫伺服器等)，所述計算組件經組態以接收及處理對儲存於資料庫的記憶體裝置中的資料的請求及自資料庫提供資料。

儘管單獨繪示資料庫380，但在一些實施例中，資料庫380可包含於平衡系統320或線上資源340中，或以其他方式與平衡系統320或線上資源340相關。

資料庫380可經組態以收集及/或維護與使用者帳戶或產品相關聯的資料以促進可用庫存的判定及虛擬配套的判定。舉例而言，資料庫380可儲存關於來自FC的庫存、聚合庫存的資訊及/或虛擬配套的即時資訊。資料庫380亦可儲存指明虛擬配套的定價、預報的需求以及價格調整的資料結構。資料庫380亦可儲存關於物件的位置及配套不同位置中的物件的規則的其他資訊。此外，資料庫380可儲存資訊以正規化來自多個系統的庫存資料。舉例而言，資料庫380可自包含例如線上資源340或第三方系統360的各種來源收集資料，且正規化資訊以聚合隨後按虛擬配套配置的庫存資料。另外，資料庫380可包含關於客戶端裝置350作業系統的資訊。下文結合圖5進一步描述資料庫380。

在一些實施例中，第三方系統360可包含系統100的一或多個元件。舉例而言，第三方系統360可包含3PL系統121A至3PL系統121C(圖1)。另外或替代地，第三方系統360可包含由與平衡系統320相關的實體(諸如服務的提供商或履行中心)提供的一或多個伺服器或儲存服務。第三方系統360亦可經由網路370連接至系統300，但在其他實施例中，第三方系統360可包含與系統300的一些元件的直接連接。舉例而言，為了使延遲或網路擁擠最小化，第三方系統360可在專用網路中與平衡系統320 連接。另外，第三方系統360可經組態以提供及/或請求來自平衡系統320或系統300的其他元件的資訊。在一些實施例中，儘管第三方系統360亦可耦接至網路370，但所述第三方系統360可能不為平衡系統320的客戶端。實情為，第三方系統360可包含系統，所述系統包含平衡系統320的使用者或客戶端的資訊。另外，若產品在系統100(圖1A)中的履行中心內不可用，則第三方系統360可進行其自身計算且告知平衡系統320可用庫存及假定的配套規則以創建具有客製化定價的虛擬配套。

FC/倉庫系統310可包含用於判定及/或儲存產品在FC或倉庫內的位置的感測器及處理器。舉例而言，FC/倉庫系統310可包含感測器217A至感測器217C(圖2)。替代地或另外，FC/倉庫系統310可包含擷取貨架的影像且使用影像辨識方法來識別產品及判定產品在FC中的位置的攝影機。另外，FC/倉庫系統310可耦接至掃描裝置且藉由監視產品的掃描事件來追蹤產品在FC中的定位。此外，FC/倉庫系統310可與平衡系統320通信以提供促進估計可用庫存及平衡虛擬配套以獲得更準確清單及需求預報的資訊。在一些實施例中，FC/倉庫系統310可經組態以將可用庫存的週期性更新提供至平衡系統320。舉例而言，FC/倉庫系統310可經組態以在每天結束時將可用庫存發送至平衡系統320。替代地或另外，平衡系統320可經由資料饋入耦接至FC/倉庫系統310，所述資料饋入基於可用庫存實現即時庫存更新及即時虛擬配套再平衡。

網路370可為經組態以提供系統300的組件之間的通信的任何類型的網路。舉例而言，網路370可為提供通信、交換資訊及/或促進資訊交換的任何類型的網路(包含基礎設施)，諸如網際網路、區域網路、近場通信(near field communication；NFC)、光碼掃描器或使得能夠在系統300的組件之間發送及接收資訊的其他合適的連接。在其他實施例中，系統300的一或多個組件可經由專用通信鏈路直接通信。在另外其他實施例中，網路370可包含多個網路，從而組織例如一或多個網路。

應理解，出於描述的便利性，本文中已界定系統300的功能建置區塊的組態及邊界。只要適當地進行指明的功能及其關係，即可界定替代性邊界。替代方案(包含本文中所描述的替代方案的等效物、擴展、變化、偏差等)將是顯而易見的。此類替代方案落入所揭露實施例的範圍內。

現參考圖4，繪示與所揭露實施例一致的例示性客戶端裝置350(圖3)的方塊圖。在一些實施例中，客戶端裝置350可實行使用者裝置102(圖1A)。

在一個實施例中，客戶端裝置350可包含一或多個處理器402、一或多個輸入/輸出(input/output；I/O)裝置404以及一或多個記憶體410。在一些實施例中，客戶端裝置350可呈行動計算裝置形式，諸如智慧型電話或平板電腦、通用電腦或此等組件的任何組合。替代地，客戶端裝置350(或包含客戶端裝置350的系統)可基於進行與所揭露實施例一致的一或多個操作的軟體指令的儲存、執行及/或實行而經組態為特定設備、嵌入式系統、專用電路以及類似者。根據一些實施例，客戶端裝置350可包含與所揭露實施例一致的存取網站的網路瀏覽器或類似計算裝置。

處理器402可包含一或多個已知處理裝置，諸如由英特爾(Intel)^TM製造的行動裝置微處理器、NVIDIA^TM，或來自其他製造商的各種處理器。所揭露實施例不限於組態於客戶端裝置350中的任何特定類型的處理器。

記憶體410可包含一或多個儲存裝置，所述儲存裝置經組態以儲存由處理器402使用以進行與所揭露實施例相關的功能的指令。舉例而言，記憶體410可經組態有一或多個軟體指令，諸如可在由處理器402執行時進行操作的程式412。所揭露實施例不限於經組態以進行專用任務的個別程式或電腦。舉例而言，記憶體410可包含進行客戶端裝置350的功能的單一程式412，或程式412可包含多個程式。記憶體410亦可包含可將客戶端裝置350組態以通信或執行操作以與系統300的其他元件交互的客戶端應用程式414。舉例而言，客戶端應用程式414可指明與平衡系統320通信及/或產生產品資訊請求的指令。此外，客戶端應用程式414可解譯用於在客戶端裝置350中產生圖形使用者介面(graphical user interface；GUI)或修改所顯示的GUI的指令。記憶體410亦可儲存可由平衡系統320用以再平衡虛擬配套及/或預報客戶需求的資料416。

在某些實施例中，記憶體410可儲存用於存取平衡系統320或將請求發送至平衡系統320的指令。舉例而言，記憶體410可包含經由TCP/IP與平衡系統320通信的應用程式。此外，其他軟體組件可經組態以請求來自平衡系統320的資訊或判定客戶端裝置350的位置。舉例而言，此等軟體指令在由處理器402執行時可處理資訊以顯示配套選擇、可用定價以及網站的剩餘庫存，如結合圖19所論述。軟體指令亦可實行指令碼以修改在客戶端裝置350中所顯示的網站。

I/O裝置404可包含一或多個裝置，所述一或多個裝置經組態以允許藉由客戶端裝置350接收到及/或傳輸資料，以及允許客戶端裝置350與其他機器及裝置(諸如系統300的其他組件)通信。舉例而言，I/O裝置404可包含用於確認包裹的遞送或向使用者提供資訊的螢幕。I/O裝置404亦可包含用於NFC通信的組件。I/O裝置404亦可包含允許使用者與客戶端裝置350交互的一或多個數位及/或類比裝置，諸如觸敏區域、按鈕或麥克風。I/O裝置404亦可包含一或多個加速計以偵測客戶端裝置350的定向及慣性。I/O裝置404亦可包含所屬技術領域中已知的用於與平衡系統320交互的其他組件。

在一些實施例中，客戶端裝置350亦可包含擷取影像且可用於識別使用者想要的產品的攝影機420。此識別可觸發對資料庫380或平衡系統320的查詢以取回可用虛擬配套資訊以供在客戶端裝置350中顯示。另外或替代地，客戶端裝置350可包含允許使用者解鎖客戶端裝置350以訪問其帳戶、發送資訊請求以及購買物件的指紋感測器430。攝影機420及指紋感測器430兩者可由處理器402操作且使用加密保全以使使用者不可能外部地存取指紋或攝影機資訊。

客戶端裝置350的組件可以硬體、軟體或硬體及軟體兩者的組合實行，如將對所屬技術領域中具有通常知識者顯而易見。

現參考圖5，繪示與所揭露實施例一致的例示性資料庫380(圖3)的方塊圖。在一些實施例中，資料庫380可包含於系統100的元件中。舉例而言，資料庫380可為FO系統113或WMS 119(圖1A)的部分。

資料庫380可包含通信裝置502、一或多個資料庫處理器504，以及包含一或多個資料庫程式512及資料514的資料庫記憶體510。資料庫380可包含NoSQL資料庫，諸如HBase、MongoDB^TM或Cassandra^TM。替代地，資料庫380可包含諸如甲骨文、MySQL以及微軟SQL伺服器的關連式資料庫。

在一些實施例中，資料庫380可呈伺服器、通用電腦、大型主機電腦或此等組件的任何組合的形式。在一些實施例中，資料庫380包含於系統300的其他元件(諸如平衡系統320)內。與所揭露實施例一致的其他實施方案亦為可能的。

在一些實施例中，資料庫380可包含非關連式資料庫及嵌入式資料庫兩者。舉例而言，資料庫380可包含諸如Hbase的非關連式資料庫，以及諸如RocksDB的嵌入式資料庫(例如，鍵值儲存資料庫)。

通信裝置502可經組態以與系統300或系統100的一或多個組件(諸如線上資源340、平衡系統320或SCM系統117)通信。特定而言，通信裝置502可經組態以提供平衡系統320訂單資訊、使用者偏好及特權、產品在FC內的位置，及/或針對類似郵遞碼及產品詢問的歷史先前估計。

資料庫380的組件可以硬體、軟體或硬體及軟體兩者的組合實行。舉例而言，儘管資料庫380的一或多個組件可實行為電腦處理指令模組，但資料庫380的功能性的所有或一部分可改為以專用電子硬體實行。

資料庫記憶體510可包含程式512，所述程式512可包含基於如藉由平衡系統320判定的可用庫存、再平衡的虛擬配套及/或價格改變來更新網站的指令。另外，資料庫記憶體510可包含用於系統300的元件之間的通信的指令。舉例而言，資料庫記憶體510可包含用於客戶端裝置350與平衡系統320之間的通信的指令。另外程式512可包含在由平衡系統320處理資訊時即時儲存所述資訊的指令。

資料514亦可為與網站相關聯的資料，諸如線上資源340，或來自客戶端裝置350的使用者帳戶。資料514可包含例如與先前遞送估計計算、FC中的產品的可用遞送選項或與物件相關聯的先前虛擬配套相關的資訊。資料314亦可包含用以評估履行中心的容量及訂單可用性的內容檔案及累積變數。

圖6為與所揭露實施例一致的例示性平衡系統320的方塊圖。平衡系統320可包含通信裝置660、平衡資料庫324以及一或多個平衡處理器322。平衡資料庫324可包含平衡程式602、快取資料604以及配套記錄606。平衡處理器322包含即時(real-time；RT)饋入模組642、FC識別器644、平衡模組646以及編碼器648。

在一些實施例中，平衡系統320可呈伺服器、通用電腦、大型主機電腦或此等組件的任何組合的形式。在其他實施例中，平衡系統320可為虛擬機。在另外其他實施例中，針對平衡系統320所描述的操作及功能可由一或多個客戶端裝置350及客戶端裝置350中的處理單元實行。與所揭露實施例一致的其他實施方案亦為可能的。

通信裝置660經組態以直接或經由網路170與一或多個資料庫(諸如資料庫380(圖3))通信。特定而言，通信裝置660可經組態以經由網路170接收客戶端訂單及/或庫存資料饋入。平衡系統320可使用此資訊判定可用庫存且產生及分佈用於客製化物件清單的虛擬配套資訊。此外，通信裝置660亦可經組態以與其他組件通信，包含例如線上資源340。

通信裝置660可包含例如允許通信裝置660與其他組件通信及/或偵測其他組件(諸如用於經由網際網路通信的網路控制器及/或無線轉接器)的一或多個數位及/或類比裝置。與所揭露實施例一致的其他實施方案亦為可能的。

平衡資料庫324可用一或多個儲存裝置實行，所述一或多個儲存裝置經組態以儲存由平衡處理器322用以進行與所揭露實施例相關的功能的指令。舉例而言，平衡資料庫324可儲存軟體指令以在由平衡處理器322執行時進行操作。所揭露實施例不限於經組態以進行專用任務的個別程式或電腦。舉例而言，儘管在一些實施例中，平衡資料庫324可包含進行平衡系統320的功能的單一程式，但在其他實施例中，平衡資料庫324可包含多個程式。平衡資料庫324亦可儲存程式602。程式602可包含用於訓練ML模型以預測對於配套產品的客戶需求且配置配套平衡以使客戶保留最大化的指令。舉例而言，程式602可包含使用配套記錄606來訓練預測對配套產品的客戶需求的演算法的指令。另外程式602可包含用於組態FC/倉庫系統310及線上資源340以提供幫助保持準確庫存記錄的週期性庫存更新的指令。另外，平衡資料庫324可包含快取資料604，其中平衡資料庫324可儲存將經過處理或傳輸至系統300的其他元件的虛擬配套資訊。

在某些實施例中，平衡資料庫324可儲存用於實施虛擬配套的同時及即時再平衡的過程的指令集。所述指令可採用最佳化演算法以增加虛擬配套的多樣性(增加各種所提供配套分組)及/或使滿足預報需求最大化(例如，增加具有高需求配套數量的配套的可用數目)。舉例而言，平衡資料庫324可經組態以持續收集及更新庫存資料以更新虛擬配套資訊且產生訓練資料集以預報對配套產品的需求。

在一些實施例中，平衡處理器322可包含一或多個已知處理裝置，諸如但不限於來自由英特爾^TM製造的奔騰^TM(Pentium^TM)或至強^TM(Xeon^TM)系列、由AMD^TM製造的炫龍^TM(Turion^TM)系列的微處理器，或來自其他製造商的各種處理器中的任一者。然而，在其他實施例中，平衡處理器322可為耦接且經組態以進行與本揭露內容一致的功能的多個裝置。

在一些實施例中，平衡處理器322可執行軟體或韌體以進行與平衡處理器322的每一組件相關聯的功能。在其他實施例中，平衡處理器322的每一組件可為獨立裝置。在此類實施例中，每一組件可為經組態以特定處理資料或進行與使訊務行為模型化、產生識別模型及/或處置大資料集相關聯的操作的硬體裝置。舉例而言，平衡模組646可為場可程式化閘陣列(field-programmable gate array；FPGA)，FC識別器644可為圖形處理單元(graphics processing unit；GPU)，且編碼器648可為中央處理單元(central processing unit；CPU)。其他硬體組合亦為可能的。在另外其他實施例中，硬體與軟體的組合可用於實行平衡處理器322。

RT饋入模組642可包含串流處理軟體。舉例而言，在一些實施例中，RT饋入模組642可實行諸如阿帕奇卡夫卡®(Apache Kafka®)的處理平台。在此類實施例中，RT饋入模組642可包含在處理平台上運行的一或多個伺服器。RT饋入模組642可處理資料串流且將資料發佈至主題中以供處理客戶端訂單及庫存資料饋入。在此類實施例中，RT饋入模組642可以可組態以擷取及儲存來自客戶端裝置350的資料串流中的事件的鍵值訊息。RT饋入模組642可將資料劃分成不同「主題」內的不同「分區」。在分區內，RT饋入模組642可按鍵值訊息的偏移(訊息在分區內的位置)對所述鍵值訊息進行排序，且將所述鍵值訊息與可由計時器判定的時戳一起索引化及儲存。

在一些實施例中，RT饋入模組642可用允許寫入消耗來自串流的資料的Java應用程式的串流應用程式介面(Application Programming Interface；API)操作。在一些實施例中，串流API可由通信裝置660提供。在此類實施例中，串流API可使得能夠使用RT饋入模組642將資料串流自輸入主題變換為輸出主題。另外RT饋入模組642可以可組態以與外部串流處理系統(諸如阿帕奇頂點(Apex)、阿帕奇Flink、阿帕奇火花(Spark)以及阿帕奇風暴(Storm))一起工作。舉例而言，RT饋入模組642可以可組態以使用執行實行實際邏輯以自其他系統讀取/寫入資料的連接器的連接API自其他系統導入資料/將資料導出至其他系統。

RT饋入模組642可支援有規律主題及緊密主題兩者以處理事件。有規律主題可經組態有保留時間或空間邊界。若存在比指明的保留時間更久的記錄或若超過空間邊界以用於分區，則可允許RT饋入模組642刪除舊資料以釋放儲存空間。在此類實施例中，藉由RT饋入模組642開發的主題可經組態有7天的保留時間。然而，其他時間窗口可為可能的。

此外，系統300的不同元件可使用藉由平衡系統320支援的API與RT饋入模組642交互。舉例而言，客戶端裝置350及/或線上資源340可用下述者與RT饋入模組642交互：(1)產生器API，其允許發佈記錄的串流；(2)消費者API，其允許訂閱主題及處理記錄的串流；(3)連接器API，執行可將主題連結至現有應用程式的可再用產生器及消費者API，及/或(4)串流API，其將輸入串流轉換為輸出且產生結果。

在一些實施例中，RT饋入模組642可包含經組態以擷取來自資料串流的事件中的密鑰的軟體及/或硬體。舉例而言，RT饋入模組642可基於藉由鍵擷取器擷取的鍵對不同主題中的事件進行分類及處理。RT饋入模組642可藉由產生鍵/值對的訊息來處理資料串流中的事件。出於查詢或匯合目的，鍵可用於分割及模型化表及主題(例如，KSQL或K表(Ktable))。鍵可包含事件的特性。舉例而言，鍵可包含IP位址、客戶端ID、帳號、地理位置或事件的其他識別資訊。

FC識別器644可包含經組態以識別可服務客戶端請求的履行中心的軟體或硬體。舉例而言，FC識別器644可包含基於客戶端裝置350(圖3)中的一或多者的位置來識別FC的軟體。FC識別器644可採用操作以使客戶端請求與FC相關以判定可將庫存提供至特定請求。舉例而言，當RT饋入模組642處理客戶端請求的資料串流時，FC識別器644可選擇FC以產生具有用於正請求客戶端的可用庫存的客製化網站。FC識別器可採用結合圖15進一步描述的FC選擇演算法。

平衡模組646可包含用於基於下述者來產生且即時平衡虛擬配套的軟體及/或硬體：(1)可用庫存(如自FC報告)；(2)客戶端訂單的串流；以及(3)ML預報模型。平衡模組646可採用使用優先級規則的庫存平衡技術，如結合圖13進一步描述。另外，平衡模組646可暴露用於即時庫存管理的服務。舉例而言，如結合圖14進一步描述，平衡模組646可判定配套分組、產生虛擬配套，且將定價指定給配套(例如，基於市場需求及庫存估計)，且將REST服務暴露於可在產生客製化網站時存取此資訊的賣方入口網站(諸如圖1A中的外部前端系統103)。

在一些實施例中，平衡模組646可訓練ML模型以便基於預報需求來平衡虛擬配套及/或改良庫存估計的準確度。在此類實施例中，平衡模組646可包含計算組件，所述計算組件經組態以使用平衡資料庫324中的資料以產生預報需求或基於歷史資料來產生庫存及配套估計的機器學習(ML)模型。舉例而言，平衡模組646可使用配套記錄606來產生預測對配套物件的需求及/或定價需求的預報模型。在此類實施例中，平衡模組646可包含程式(例如，指令碼、函數、演算法)以訓練、實行、儲存、接收、取回及/或傳輸一或多個ML模型。ML模型可包含：神經網路模型、注意力網路模型、生成對抗模型(generative adversarial model；GAN)、遞回神經網路(recurrent neural network；RNN)模型、深度學習模型(例如，長短期記憶體(long short-term memory；LSTM)模型)、隨機森林模型、卷積神經網路(convolutional neural network；CNN)模型、RNN-CNN模型、LSTM-CNN模型、時間CNN模型、支援向量機(support vector machine；SVM)模型、具有雜訊的應用程式的基於密度的空間叢集(Density-based spatial clustering of applications with noise；DBSCAN)模型、k均值叢集模型、基於分佈的叢集模型、k中心點(k-medoids)模型、自然語言模型及/或另一機器學習模型。另外，模型可包含總體模型(亦即，具有多個模型的模型)。

在一些實施例中，平衡模組646可經組態以在滿足訓練準則時終止訓練。訓練準則可包含若干時期、訓練時間、效能度量(例如，對再現測試資料的準確度的估計)，或類似者。平衡模組646可經組態以在訓練期間調整模型參數。模型參數可包含權重、係數、偏移或類似者。訓練可為受監督或不受監督的。

與所揭露實施例一致，平衡模組646可經組態以使用最佳化技術藉由使模型參數及/或超參數最佳化(亦即，超參數調諧)來訓練ML模型。超參數可包含訓練超參數(其可影響模型的訓練如何發生)或架構超參數(其可影響模型的結構)。最佳化技術可包含格點檢索、隨機檢索、高斯(gaussian)過程、貝氏(Bayesian)過程、共變異數矩陣調適演進策略(Covariance Matrix Adaptation Evolution Strategy；CMA-ES)、基於導數的檢索、隨機爬山(stochastic hill-climb)、鄰域檢索、自適應隨機檢索或類似者。平衡模組646可經組態以使用已知最佳化技術來使統計模型最佳化。

編碼器648可為經組態以編碼物件及相關聯配套以填充配套記錄606的軟體及/或硬體。舉例而言，當平衡系統320自FC/倉庫系統310接收庫存資料時，編碼器648可產生在FC處可用的物件的物件ID。物件ID可在多個FC及第三方供應商當中經正規化以促進物件聚合以用於平衡虛擬配套。另外或替代地，編碼器648亦可編碼虛擬配套群組碼以創建包含物件的資訊、配套數量或分組以及相關聯價格的標籤。另外，編碼器648可創建具有用於(1)實體物件、(2)虛擬數量、(3)配套價格以及(4)每物件價格的至少四個欄位的產品ID清單。舉例而言，編碼器648可為產品清單創建ID，諸如「ITEM123-VB2-10-5」，其具有物件ID「ITEM123」的第一欄位、虛擬配套2「VB2」、配套價格「10」以及每物件價格「5」。在一些實施例中，編碼器648可標籤或標記配套記錄606以產生由平衡模組646用於訓練ML模型的訓練資料集。

平衡系統320的組件可以硬體、軟體或硬體及軟體兩者的組合實行，如將對所屬技術領域中具有通常知識者顯而易見。舉例而言，儘管平衡系統320的一或多個組件可實行為體現於平衡資料庫324中的電腦軟體中的電腦處理指令，但平衡系統320的功能性中的一些或全部可實行於專用硬體中。舉例而言，GPU及/或FPGA的群組可用於快速分析平衡處理器322中的資料。

圖7為與所揭露實施例一致的例示性庫存網路700的方塊圖。網路700繪示連接客戶端裝置350與FC/倉庫系統310及第三方系統360的平衡系統320(圖3)。如先前結合圖3及圖6所論述，網路700的組態允許平衡系統320管理即時庫存系統，此避免依賴於用於估計可用庫存及物件的配套群組的FC/倉庫系統310。因此，網路700中所繪示的組態藉由減少網路擁擠、促進自動化更新以及將準確庫存資料提供給賣方入口網站來改良即時庫存系統。

如圖7中所繪示，網路700中的客戶端裝置350(包括客戶端裝置350-1、350-2、350-3、350-4、350-5、350-6，但不限於此)可經由賣方入口網站702連接至網路。在一些實施例中，賣方入口網站702可藉由外部前端系統103或賣方入口網站109中的一或多者程式化及代管。替代地或另外，賣方入口網站702可為基於平衡系統320藉由線上資源340組態的網站。在此類實施例中，當創建網站以供在客戶端裝置350中顯示時，賣方入口網站702可查詢平衡系統320(例如，藉由查詢平衡資料庫324)以判定可顯示至客戶端裝置350的可用庫存及可用虛擬配套。舉例而言，賣方入口網站702可產生GUI及網站，如結合圖19所描述。

如圖7中所繪示，賣方入口網站702可包含具有賣方入口網站702-1、賣方入口網站702-2、賣方入口網站702-3以及賣方入口網站702-4的多個賣方入口網站。賣方入口網站中的每一者可經組態以向客戶端裝置350顯示客製化網站。舉例而言，取決於客戶端裝置350的位置，賣方入口網站702中的每一者可產生展示不同庫存及/或虛擬配套的可用性的客製化網站。在此類實施例中，平衡系統320可將不同FC指定給賣方入口網站702中的每一者(例如，使用FC識別器644(圖6))，且每一賣方入口網站可取決於FC/倉庫系統310中的所指定者來存取客製化庫存及虛擬配套資訊。類似地，賣方入口網站702亦可藉由自第三方系統360放出資訊來產生及代管具有客製化產品清單的網站。

賣方入口網站702中的一些可經由訂單系統704連接至平衡系統320。訂單系統704可經組態以處理客戶訂單且將經過處理的資訊傳輸至平衡系統320。舉例而言，訂單系統704可在其將資訊傳輸至平衡系統320以更新庫存資料及/或發起履行過程之前處理及驗證支付。另外訂單系統704可不斷地進行操作以管理購買訂單處理。舉例而言，訂單系統704可產生購買訂單、追蹤以及管理相關聯文書。在此類實施例中，訂單系統704亦可處理退貨及退款，且將所述資訊傳輸至平衡系統320以產生準確的即時庫存帳戶，所述準確的即時庫存帳戶不僅考慮庫存資料饋入及購買，且亦返回以具有對可用庫存及配套物件的平衡的準確表示。儘管一些賣方入口網站702可經由訂單系統704連接，但其他賣方入口網站可直接存取平衡系統320。舉例而言，賣方入口網站702-3及賣方入口網站702-4可直接連接至平衡系統320，此是由於其可具有訂單處理能力及/或其可伺服不需要訂單系統704的客戶端裝置350的不同區段。

此外，在一些實施例中，訂單系統704可包含進行客製化標記及包裝清單的操作、專用及共用操作、包含消費者返回管理的逆物流、電子資料交換(Electronic Data Interchange；EDI)順應性、交叉對接以及電子商務服務(訂單、存貨水平以及運送資訊的可見度)的全域零售訂單履行系統。

在網路700中，平衡系統320亦可耦接至FC網路的多個FC/倉庫系統310。即使在一個物件及/或虛擬配套中的一者具有大量需求時，平衡系統320亦可使得多個FC庫存的集中化能夠使產品清單多樣性最大化且擷取客戶端需求。此外，平衡系統320亦可聚合來自第三方系統360的庫存資訊以創建庫存的聚合資料集，其可用於平衡虛擬配套且使產品清單的種類及可用性最大化。在一些實施例中，FC/倉庫系統310中的一些可經由收集及處理資訊的全域庫存系統708連接至平衡系統320。舉例而言，全域庫存系統708可包含經組態以自購買訂購過程消除冗餘的自動化基於雲端的購買訂單。在此類實施例中，全域庫存系統708亦可經程式化以創建反映總體庫存的狀態及預報需求的度量。舉例而言，全域庫存系統708可採用如關於圖6所論述的ML模型來進行預報任務。由於全域庫存系統708具有來自FC/倉庫系統310中的多個的資訊，故全域庫存系統708可處於開發針對FC的網路的預測的預報的位置。

儘管FC/倉庫系統310中的一些可經由庫存系統708連接，但其他FC/倉庫系統310可直接連接至平衡系統320。舉例而言，FC/倉庫系統310-1及FC/倉庫系統310-2可直接連接至全域庫存系統708，此是由於其為同一賣方的部分或具有共用庫存協議。相比之下，FC/倉庫系統310-3及FC/倉庫系統310-4可直接連接至平衡系統320。類似地，第三方系統360可直接連接至平衡系統320以提供關於其庫存的資訊。在一些實施例中，平衡系統320可創建自第三方系統360分離庫存的虛擬配套以避免產品混雜。然而，在其他實施例中，平衡系統320可以可組態以接受產品混雜且使用網路700中可用的任何庫存，以產生虛擬配套且將資訊(例如，經由REST API方法)提供至賣方入口網站702以在客戶端裝置350中顯示。

圖8A為與所揭露實施例一致的例示性不平衡庫存系統800的方塊圖的第一部分。在不平衡庫存系統800中，倉庫-物件管理系統806可將庫存資訊提供至全域庫存系統804。舉例而言，中心200中的庫存系統(包含感測器217A至感測器217C(圖2))可提供在FC或倉庫處可用的庫存資料。如圖8A中所繪示，倉庫-物件管理系統806可藉由指明在倉庫中可用的物件的數目及類型來提供庫存資訊。

全域庫存系統804可產生多個虛擬配套。舉例而言，基於自倉庫-物件管理系統806接收到的資訊。如圖8A中所繪示，全域庫存系統804可針對自倉庫-物件管理系統806接收到的物件產生虛擬配套，從而用不同配套數量(VB)及不同配套ID劃分不同配套中的物件的數目及類型。在一些實施例中，全域庫存系統804可將虛擬配套資訊傳達至配套系統808，所述配套系統808可將資訊提供至賣方入口網站以創建用於產生具有包含具有客製化定價的配套的產品清單的網站的入口網站。在此類實施例中，全域庫存系統804及配套系統808可經由在系統之間交換資料的FC庫存饋入822連接。舉例而言，FC庫存饋入822可將第一物件記錄820及第二物件記錄821傳輸至配套系統808。

圖8B為與所揭露實施例一致的例示性不平衡庫存系統800的方塊圖的第二部分。圖8B繪示藉由自訂單系統802接收到的訂單觸發的庫存系統上的改變。如圖8B中所繪示，訂單系統802可將針對物件1及物件2的訂單請求的資訊發送至配套系統808。訂單可包含客戶端所請求的配套及/或客戶端所請求的物件。配套系統808可接著接收請求且修改虛擬配套以反映庫存數目的減小。因此，配套系統808-1(反映配套系統808的訂購前狀態)改變為更新後的配套系統808-2(反映庫存系統的訂購後狀態)。在一些實施例中，如圖8B中所繪示，全域零售庫存系統804可將資訊提供至配套系統808(如結合圖8A所論述)且基於配套系統808的改變來更新總體可用庫存。

不平衡庫存系統800展示配套物件中的一些可變得不可用，而同一類別中的其他物件繼續在不同配套中可用。此意謂在不平衡庫存系統800中，客戶可能不能夠在特定配套處於高需求時購買所述特定配套，直至存在來自倉庫-物件管理系統806的庫存饋入為止。此可能在存在來自訂單系統802的快速一連串訂單時產生錯誤缺貨問題。然而，不平衡庫存系統800可藉由具有來自倉庫-物件管理系統806及全域庫存系統804及/或配套系統808的經同步資料饋入而使網路擁擠最小化及/或實現即時庫存更新。

圖9A為與所揭露實施例一致的例示性平衡庫存系統900的方塊圖的第一部分。如同在不平衡庫存系統800中，在平衡庫存系統900中，倉庫-物件管理系統918可耦接至全域庫存系統904。倉庫-物件管理系統918經組態以將訂單傳輸至全域庫存系統904。舉例而言，全域庫存系統904可自倉庫-物件管理系統918接收庫存資料，且產生具有不同分組、定價以及可用性的多個虛擬配套。

類似於不平衡庫存系統800，在平衡庫存系統900中，全域庫存系統904可經由FC庫存饋入924與配套系統908連接，所述FC庫存饋入924將第一物件記錄954及第二物件記錄952傳輸至配套系統908。然而，不同於不平衡庫存系統800，在平衡庫存系統900中，庫存估計器928可經組態以自平台讀取庫存，所述平台藉由進行自庫存估計器928讀取庫存的操作而再平衡庫存及/或處置對來自全域庫存系統904的庫存的實況的請求，所述庫存估計器928可估計可用庫存而不必與倉庫-物件管理系統918通信。舉例而言，全域庫存系統904可在步驟936中請求庫存的實況的來源，且庫存估計器928可在步驟930中用再平衡庫存對所述請求作出回應。此外，全域庫存系統904亦可經組態以在步驟932中將再平衡庫存傳輸至配套系統。舉例而言，全域庫存系統904可基於補充來自FC庫存饋入924的資訊的客戶端訂單來傳達再平衡庫存。因此，採用平衡庫存系統900的實施例可對庫存改變具有更快回應且提供更準確且多樣化的產品清單。

此外，在一些實施例中，全域庫存系統904可自全域零售訂單履行系統940接收訂單。舉例而言，在FC網路包含本端及第三方供應商兩者或賣方的實施例中，全域零售訂單履行系統940可聚合及處理來自不同客戶端及供應商網路的資訊，以將正規化訂單提供至全域庫存系統904。

圖9B為例示性平衡庫存系統900的方塊圖的第二部分。圖9B詳述配套系統回應於可例如自客戶端裝置350(圖3)出現的訂單的改變。如圖9B中所繪示，訂單系統902可將訂單發送至庫存系統。舉例而言，訂單系統902-1可發送針對第一物件的第一訂單958，且訂單系統902-2可發送針對第二物件的第二訂單956。訂單可指明訂單類型及配套數量。訂單亦可指明應自其處理訂單的庫存ID。舉例而言，由於客戶端裝置350可基於其位置顯示客製化網站，故來自訂單系統902的訂單可指明應自其減去庫存的FC或倉庫。圖9B繪示具有先前虛擬配套群組的配套系統908-1(在處理來自訂單系統902的訂單之前)，以及更新後的平衡系統908-2(在處理訂單之後)。如圖9B中所繪示，不同於不平衡庫存系統800，在平衡庫存系統900中，虛擬配套中無一者最終出現零數量。此是由於配套系統908基於訂單而無需來自倉庫-物件管理系統906的通信來再平衡虛擬配套。

此外，配套系統908可將先前及更新後的配套資訊傳輸至庫存估計器928，所述庫存估計器928又可與全域庫存系統906連接以再新或更新網站中的產品清單。另外，在一些實施例中，庫存估計器928可收集配套系統908的改變以產生可用於產生預報對特定配套物件的需求的ML模型的訓練資料集。舉例而言，庫存估計器928可填充配套記錄606以將資料集提供至平衡模組646，以產生告知配套指定的發展的ML模型。

此外，如圖9B中所繪示，全域庫存系統906可與配套系統908通信以提供用於再平衡虛擬配套的資訊。舉例而言，如結合圖9A進一步論述，全域庫存系統906可在步驟932中藉由與配套系統908通信而傳輸再平衡庫存。

圖9C為例示性平衡庫存系統900的方塊圖的第三部分。圖9C繪示產生配套系統908的改變的訂購過程的額外細節。圖9C繪示訂單系統902產生第一訂單958及第二訂單956。如圖9B中所描述，此等訂單可傳輸至配套系統908，從而在先前配套系統908-1與更新後的配套系統908-2之間產生改變。在一些實施例中，可經由全域零售訂單履行系統940引導來自訂單系統902的訂單，所述全域零售訂單履行系統940可與全域庫存系統904通信。舉例而言，全域零售訂單履行系統940可基於來自訂單系統902的訂單來創建觸發庫存再平衡的即時庫存饋入926。

平衡庫存系統900允許進行動態庫存平衡，其藉由使錯誤OOS最小化來改良即時庫存管理，且提供組合FC/倉庫資料(例如，經由倉庫-物件管理系統906)、客戶資料(例如，經由訂單系統902)以及所預報配套需求的動態庫存管理過程，以持續地平衡全域庫存系統904中的虛擬配套，以具有更準確庫存資訊且提供產品清單的更大多樣性以使客戶保留最大化。

圖10為與所揭露實施例一致的虛擬配套再平衡操作1000的示意性表示。操作1000繪示在再平衡之前(例如，在接收客戶端訂單之前)組織庫存的第一虛擬配套1010及在再平衡之後(例如，在接收及處理客戶端訂單之後)的第二虛擬配套1050的群組。如圖10中所繪示，對於完整配套，虛擬配套中的每一者包含物件類型、分組數目、可用配套的數量以及配套價格。在一些實施例中，平衡系統320可在其自FC/倉庫系統310(圖3)接收庫存資料時產生第一虛擬配套1010。

第一虛擬配套1010包含兩個物件A配套1012、三個物件A配套1014、四個物件A配套1016以及五個物件A配套1018。配套1012至配套1018中的每一者具有相同物件(物件A)，但配套1012至配套1018中的每一者具有不同分組數目(亦即，每一配套具有配套物件的不同數目)、配套的不同可用數量(亦即，庫存中可用的配套的數目)以及不同配套價格。以此方式，平衡系統320可控制配套物件的可用性，且亦定製配套的定價以激勵某一類型的購買及/或滿足對某一特定配套的需求。

第一虛擬配套1010亦可包含不同物件B的虛擬配套。舉例而言，第一虛擬配套1010可包含一個物件B配套1020、三個物件B配套1022以及五個物件B配套1024。配套1020至配套1024 中的每一者具有相同物件(物件B)，但配套1020至配套1024中的每一者具有不同分組數目、配套的不同可用數量以及不同配套價格。

額外虛擬配套可經組態以用於第一虛擬配套1010。舉例而言，虛擬配套可經組態以用於物件C(未繪示)或用於合併不同類型的物件的組合配套。舉例而言，虛擬配套1010可包含在單一配套中具有物件A及物件B兩者的合併配套(未繪示)。以此方式，第一虛擬配套1010可提供多個物件及/或物件的組合的可客製化及定製的產品清單。在此類實施例中，物件的選定組合或配套的選定物件可以是基於預報需求或營銷資料。舉例而言，平衡模組646(圖6)可基於預報產品需求及/或判定購買配套物件的似然來產生第一虛擬配套1010中的多個配套。替代地或另外，平衡系統320可根據過量庫存或營銷活動作為虛擬配套的群組的基礎。

第一虛擬配套1010可回應於觸發平衡系統320(圖3)中的再平衡操作的客戶端訂單而更新。舉例而言，如圖10中所繪示，客戶端訂單可請求六個四個物件A配套1016(亦即，六個配套1016的訂單，總共24個物件)及十個三個物件A配套1022(亦即，十個配套1022的訂單，總共30個物件)。此訂單將減小可用庫存，但為了維持可用配套的最大多樣性且使錯誤OOS通知最小化，平衡系統320可進行再平衡操作。在再平衡操作中，庫存系統不僅自配套1022及配套1016減去物件的所訂購數目。實情為，平衡系統320進行平衡操作以產生具有減少數目的物件但維持可用配套的多樣性的第二虛擬配套1050。

因此，如同第一虛擬配套1010，第二虛擬配套1050可包含兩個物件A配套1012、三個物件A配套1014、四個物件A配套1016以及五個物件A配套1018。配套1012至配套1018的分組數目可與第一虛擬配套1010中相同。然而，虛擬配套的其他參數可改變。舉例而言，每一配套的數量可改變以反映可用於配套的物件的總數目已減少。如圖10中所繪示，配套1012至配套1018中的每一者的數量可能已歸因於平衡系統320的再平衡過程而減少。另外，與配套1012至配套1018中的每一者相關聯的配套價格亦可在平衡系統320根據需求預報及/或ML模型調整價格時更新，所述ML模型幫助判定購買訂單的似然及/或對特定配套的關注。舉例而言，平衡系統320可判定某些虛擬配套的折扣價格。但無論是否存在配套數量及價格的改變，平衡系統320均可以可組態以再平衡虛擬配套以使可用配套的多樣性最大化。因此，平衡系統320可在第二虛擬配套1050中再分佈物件以在第二虛擬配套1050中具有最均勻數目個虛擬配套。

第二虛擬配套1050亦可包含已再平衡以使配套多樣性最大化的物件B配套。第二虛擬配套1050可包含一個物件B配套1020、三個物件B配套1022以及五個物件B配套1024。虛擬配套的分組可與之前相同，但與配套1020至配套1024中的每一者相關聯的數量及價格可基於預報需求、營銷活動及/或回購價格(例如，來自第三方系統360)來更新以反映總物件的更低數目及價格調整。

操作1000繪示平衡系統320可如何估計可用庫存且再平衡虛擬配套而不必查詢FC/倉庫系統310。因此，採用操作1000可促進即時庫存系統的管理，所述即時庫存系統更新允許用使產品清單的可用性最大化且避免錯誤OOS狀態的更新後的資訊來組態線上零售網站。如結合圖13進一步論述，操作1000可基於下述過程：基於預報需求來判定虛擬配套的平衡以產生優先級，及/或對維持可用配套的最大多樣性的一般規則破例。

圖11為與所揭露實施例一致的用於虛擬配套平衡的過程流程1100的時序圖。在一些實施例中，如圖11中所繪示，系統300(圖3)的不同元件可進行過程流程1100的特定步驟。舉例而言，平衡系統320的組件可進行過程流程1100的一或多個步驟，且客戶端裝置350可進行過程流程1100的額外步驟。如圖11中所繪示，其他元件亦可參與過程流程1100。舉例而言，網路700的元件(諸如賣方入口網站702)可進行過程流程1100中的某些操作。然而，在其他實施例中，系統300及網路700的替代性元件可進行所描述的步驟(例如，資料庫380可進行某些步驟)，或系統300或網路700的單一元件可進行所描述的步驟。

在步驟1102中，FC/倉庫系統310可將週期性庫存資料發送至平衡系統320。舉例而言，如結合圖8及圖9所論述，FC/倉庫系統310可發送倉庫中的可用物件的數目的資訊。在一些實施例中，在步驟1102中傳輸的資訊可與FC的感測器及庫存系統同步。舉例而言，週期性庫存資料可經組態以基於所掃描碼、感測器(如圖2中的感測器217)以及影像分析來自動產生。此外，在一些實施例中，在步驟1102中傳輸的資訊可經由藉由RT饋入模組642剖析及分析的資料饋入發送。替代地或另外，FC/倉庫系統310可經組態以一天至少傳輸庫存資料一次，以觸發平衡系統320處的庫存的動態再平衡。

在步驟1104中，平衡系統320可產生虛擬配套且暴露API或佇列服務。舉例而言，平衡系統320可產生多個虛擬配套且將其傳達至全域庫存系統。如結合圖8及圖9所描述，全域庫存系統可對來自賣方入口網站的庫存查詢作出回應以產生客製化或更新後的零售網站。在一些實施例中，在步驟1104中，平衡系統320可在不同虛擬配套中分佈庫存(如結合圖10所描述)，基於ML模型、營銷活動及/或預報需求來指定定價。此資訊可接著可用於系統300或網路700的其他元件，以例如產生網站及/或處置客戶端請求。

在步驟1106中，平衡系統320可將通知及API組態傳輸至賣方入口網站702。舉例而言，平衡系統320可將更新後的庫存的通知發送至賣方入口網站，且提供用以存取更新後的庫存的資訊及虛擬配套資訊。在一些實施例中，平衡系統320可提供為賣方入口網站702專用市場定製的資訊。舉例而言，平衡系統320可進行操作以識別FC(例如，使用FC識別器644)，且在步驟1106中將庫存資訊提供至賣方入口網站702。

在步驟1108中，平衡系統320可產生具有發佈的庫存的網頁介面。舉例而言，如結合圖19進一步論述，賣方入口網站702可產生展示物件的可用庫存及配套選項(具有其相關聯價格)的GUI及網站。在步驟1110中，賣方入口網站702可將庫存資料傳輸至客戶端裝置350。舉例而言，回應於對零售商網站的客戶端請求，賣方入口網站702可在步驟1110中提供庫存資料以產生具有庫存資訊的網站。另外，在步驟1110中，賣方入口網站702可經組態以藉由經由一或多個API調用查詢資料庫將多個配套的可用性及價格傳輸至客戶端裝置。

在步驟1112中，客戶端裝置350可將配套選擇傳輸至賣方入口網站702(圖11)。舉例而言，客戶端裝置350的使用者可與在步驟1108中產生且在步驟1110中傳輸的網站交互，以對一或多個物件及/或一或多個配套進行排序。

在步驟1114中，賣方入口網站702可將客戶端訂單發送至平衡系統320。如結合圖7所論述，為具有監視庫存的能力且即時再平衡虛擬配套物件，平衡系統320可經組態以在客戶端裝置350與FC/倉庫系統310之間介接。因此，可首先將訂單路由至可如結合圖10所描述基於客戶端訂單來調整虛擬配套的平衡系統320。此外，在步驟1116中，平衡系統320可識別用於履行客戶端訂單及配套選擇的FC。舉例而言，採用結合圖15描述的過程，平衡系統320可選擇具有履行客戶端訂單的能力的FC。然而，在一些實施例中，平衡系統320可經由全域庫存系統708(圖7)處理訂單以聚合來自可履行客戶端訂單的多個FC或倉庫的庫存。

在步驟1118中，平衡系統320可請求訂單履行。舉例而言，平衡系統320可將訊息發送至選定FC以履行在步驟1114中接收到的訂單。舉例而言，平衡系統320可回應於接收到客戶端訂單，自至少一個履行中心識別用於客戶端訂單的選定履行中心且將客戶端訂單傳達至選定履行中心。在步驟1120中，平衡系統320可平衡資料庫及虛擬配套。基於客戶端訂單且不必與FC/倉庫系統310通信，平衡系統320可如結合圖9及圖10所描述而平衡虛擬配套，以使虛擬配套的多樣性最大化、調整價格，且基於預報需求來創建額外配套或修改配套數量。舉例而言，在某些實施例中，平衡系統320經組態以每當客戶端購買配套物件時均動態地平衡庫存。

在步驟1122中，平衡系統320可產生更新後的庫存的通知且將所述通知傳輸至賣方入口網站702。舉例而言，平衡系統320可通知賣方入口網站702已經由API方法修改庫存資料庫。替代地或另外，平衡系統320可採用編碼器648來產生新物件及配套碼，且再新或更新在客戶端裝置350中顯示及/或在賣方入口網站702中代管的網站。在步驟1124中，賣方入口網站702可產生具有更新後的庫存的網頁介面。舉例而言，如結合圖19所論述，賣方入口網站702可更新展示於客戶端裝置350中的網站以反映庫存、定價及/或虛擬配套可用性的改變。

在步驟1126中，FC/倉庫系統310可產生具有週期性庫存資料的更新訊息。舉例而言，在每天或每15分鐘結束時，FC/倉庫系統310可向平衡系統320報告可用庫存。在此類實施例中，FC/倉庫系統310可經組態以一天至少產生庫存資料饋入一次，以觸發藉由平衡系統320進行的庫存的動態平衡。替代地或另外，在一些實施例中，FC/倉庫系統310可使用FC資料饋入與平衡系統320連接，如結合圖8及圖9所論述。在步驟1128中，平衡系統320可覆寫所估計庫存(例如，若所估計庫存與接收到的庫存之間存在偏差，則平衡系統320可有利於自FC/倉庫系統310接收到的庫存資料)。另外，在步驟1128中，平衡系統320可基於藉由FC/倉庫系統310在步驟1126中提供的資訊來再平衡虛擬配套及/或創建新虛擬配套。

在步驟1130中，如在步驟1122中，平衡系統320可將更新後的庫存的通知傳輸至賣方入口網站702以反映可用庫存的改變。因此，在步驟1130中，平衡系統320可自至少一個履行中心接收更新後的庫存資料，基於更新後的庫存資料來再平衡資料庫中的多個配套；以及回應於更新多個虛擬配套，向賣方入口網站通知資料庫的改變。

圖12為與所揭露實施例一致的在儲存虛擬配套資訊的資料庫中的例示性表1200。表1200包含多個虛擬配套1230。虛擬配套1230中的每一者可與物件ID欄位1202、虛擬配套欄位1204、配套類別欄位1206、SKU欄位1208、價格比率欄位1210、配套數量欄位1212以及配套狀態欄位1214相關聯。表1200可儲存於平衡系統320中。舉例而言，表1200可儲存於平衡資料庫324中作為配套記錄606(圖6)的部分。替代地或另外，表1200可為資料庫380或系統300中的其他記憶體裝置的部分。

除配套識別欄位1202至配套識別欄位1214之外，表1200亦可包含用於識別供應商的欄位及/或將物件與額外物件一起配套的能力。舉例而言，表1200亦可包含配套合併器欄位1216、賣方產品ID欄位1218以及上載ID欄位1220，以及營銷活動欄位1222。欄位1216至欄位1222可由平衡系統320用以產生虛擬配套及/或判定配套或價格規則。

表1200可為賣方入口網站702及/或客戶端裝置350可存取的以用於產生網站及管理庫存。舉例而言，表1200及含有表1200的資料庫經由RESTful服務、基於佇列的系統、索引或目標表中的至少一者。在一些實施例中，表1200可支援來自賣方入口網站702的GET方法。在此類實施例中，表1200可經組態以在平衡系統320接收及處理訂單時動態且即時地更新。

圖13為與所揭露實施例一致的用於基於可用庫存來管理虛擬配套的例示性過程1300的流程圖。在一些實施例中，系統300的元件可進行過程1300。舉例而言，如以下步驟描述中所揭露，平衡系統320可進行過程1300。特定而言，平衡模組646可進行過程1300的步驟。替代地或另外，系統300的其他元件可進行過程1300的一或多個步驟。舉例而言，資料庫380、客戶端裝置350或線上資源340可進行過程1300或過程1300的部分。另外，在一些實施例中，系統800及系統900，或所述系統800及系統900的部分可進行過程1300。舉例而言，配套系統908可進行過程1300。

在步驟1302中，平衡系統320可接收客戶端訂單。舉例而言，平衡系統320可自客戶端裝置350及/或訂單系統704(圖7)中的一者接收訂單。在步驟1304中，平衡系統320可判定在履行客戶端訂單之後庫存中可用的物件的聚合數目。舉例而言，平衡系統320可聚合剩餘虛擬配套以判定未配套物件的總數目。在一些實施例中，例如，平衡系統320可計算第一虛擬配套1010(圖10)中的物件以計算物件的所估計總數。

在步驟1306中，平衡系統320可判定一或多個配套是否低於臨限值。舉例而言，基於虛擬配套規則，平衡系統320可判定每一虛擬配套應具有例如兩個配套的最小數量。若虛擬配套中無一者降至低於臨限值的數量(步驟1306：否)，則平衡系統320可決定不進行再平衡操作以節省電腦資源，且繼續至步驟1330。在步驟1330中，平衡系統320可通知賣方入口網站庫存中不存在改變(亦即，不存在再平衡)。然而，若虛擬配套中的一者降至低於臨限值的數量(步驟1306：是)，則平衡系統320可繼續至步驟1308。在步驟1308中，平衡系統320可獲得虛擬配套的當前數量狀態。舉例而言，平衡系統320可判定已識別或創建虛擬配套中的每一者的數量。在步驟1310中，平衡系統320可計算物件的平衡分佈，其針對每一分組數目產生至少一個可用虛擬配套。亦即，在步驟1310中，平衡系統320可依序分佈可用物件以提供具有可用庫存的虛擬配套的最大多樣性。

在步驟1312中，平衡系統320可判定每一配套是否存在不足庫存。舉例而言，平衡系統320可判定物件的數目是否過低而無法創建每一類型的配套中的一者。若平衡系統320判定每一配套存在不足庫存(步驟1312：是)，則平衡系統320可繼續至步驟1314且應用預測演算法以對頻繁請求的配套進行優先排序，即使一些配套最終為OOS亦是如此。在此類實施例中，優先排序的配套可在非優先排序的配套之前首先獲得指定的物件，以保證優先排序的配套具有足夠庫存以達成目標數目個配套。舉例而言，優先排序的配套可首先經填充或完成，且將僅剩餘物件(其未指定給優先排序的配套)指定給非優先排序的配套。另外或替代地，在步驟1314中，平衡系統320可採用ML模型來預報需求且將可用物件分配給具有更高需求的虛擬配套。然而，若平衡系統320判定每一配套存在足夠庫存(步驟1312：否)，則平衡系統320可繼續至步驟1316且將庫存指定給虛擬配套，且用虛擬配套的更新後的分佈更新資料庫，諸如平衡資料庫324。

在步驟1318中，平衡系統320可判定在步驟1316的指定之後是否存在過量庫存。舉例而言，平衡系統320可判定在保證所有配套具有至少臨限數量之後是否存在寬鬆物件單元。若平衡系統320判定在指定之後不存在過量庫存(步驟1318：否)，則依序再平衡過程終止，且平衡系統320可繼續至步驟1330且向賣方入口網站通知改變。然而，若平衡系統320判定在指定之後存在過量庫存(步驟1318：是)，則平衡系統320可繼續至步驟1320。

在步驟1320中，平衡系統320可判定用於虛擬配套指定的優先級模型是否可用。舉例而言，平衡系統320可判定ML模型是否可用於預報需求且對某些虛擬配套給出優先級。若平衡系統320判定存在可用優先級模型(步驟1320：是)，則平衡系統320可繼續至步驟1322且基於優先級規則來指定過量庫存。然而，若平衡系統320判定不存在可用優先級模型(步驟1320：否)，則平衡系統320可繼續至步驟1324，且依序指定來自最高至最低分組數目的物件以將額外物件提供至儘可能多的虛擬配套。在步驟1322或步驟1324之後，平衡系統320可繼續至步驟1330且向賣方入口網站通知改變。

圖14為與所揭露實施例一致的用於用虛擬配套資訊填充及暴露資料庫的例示性過程1400的流程圖。在一些實施例中，系統300的元件可進行過程1400。舉例而言，如以下步驟描述中所揭露，平衡系統320可進行過程1400。替代地或另外，系統300的其他元件可進行過程1400的一或多個步驟。舉例而言，資料庫380、客戶端裝置350或線上資源340可進行過程1400或過程1400的部分。另外，在一些實施例中，系統800及系統900，或所述系統800及系統900的部分可進行過程1400。舉例而言，配套系統 908可進行過程1400。

在步驟1402中，平衡系統320可接收庫存資料饋入及/或FC訊息。舉例而言，平衡系統320可自FC/倉庫系統310接收庫存資料饋入。在一些實施例中，如結合圖8及圖9所論述，平衡系統320可接收指示在FC處可用的物件的FC庫存饋入，諸如FC庫存饋入822(圖8)。舉例而言，在一些實施例中，平衡系統320可在步驟1402中與FC的庫存系統連接以接收庫存資訊。在一些實施例中，步驟1402可經組態為週期性的，且平衡系統320可每分鐘一次、每15分鐘一次、每小時一次、每天一次及/或另一預定頻率接收庫存資料饋入。在一些實施例中，庫存資料饋入為耦接至至少一個履行中心的庫存系統的即時資料饋入，且所述庫存系統包含掃描碼系統、成像庫存系統或無線標籤系統中的至少一者，如結合圖2進一步論述。

在一些實施例中，平衡系統320可接收庫存饋入作為快照庫存、調整庫存，或快照與調整庫存的組合。快照庫存可指明截至特定時間的庫存水平。舉例而言，快照庫存可反映截至系統時間亦在其中的特定時間的庫存計數。FC/倉庫系統310可基於在先前時間段期間登記的交易及/或根據庫存管理系統(諸如包含感測器217(圖2)的庫存管理系統)一次提供庫存計數。因此，快照庫存可提供FC中的庫存的即時狀態。在一些實施例中，FC/倉庫系統310可經組態以在某一週期性下(例如，每天、每小時、每15分鐘或每分鐘)傳輸快照庫存。調整庫存可基於訂單、購買及/或預測演算法來指明庫存的差。調整庫存可調整FC/倉庫系統310中可用的數量。調整可在進行計劃外的實體庫存計數且在事實之後報告所述計數時更新庫存，以便確保庫存為最新的。調整庫存可在每日業務期間進行且在某一週期性下進行。然而，調整庫存亦可為不可預測的且基於中斷或其他操作(例如，購買訂單)。因此，不同於快照庫存，可在一天當中不可預測地將調整庫存提供至自FC/倉庫系統310至平衡系統320的資料饋入。因此，在步驟1402中，平衡系統320可經由資料饋入及通信接收快照庫存、調整庫存，或兩者的組合。此等更新在平衡系統320與FC/倉庫系統310之間可為週期性或偶發性的。

在步驟1404中，平衡系統320可識別庫存資料中的物件。舉例而言，平衡系統320可解譯如在步驟1402中接收到的與物件相關聯的碼。在步驟1406中，平衡系統320可為庫存資料中的物件指定物件ID。舉例而言，平衡系統320可產生物件ID且產生識別物件、物件類別以及其他資料欄位的表1200(圖12)中的列。另外，在步驟1406中，平衡系統320可採用編碼器648(圖6)來產生物件碼，諸如「ITEM123」。

在步驟1408中，平衡系統320可判定在步驟1404中接收到且在步驟1406中識別出的物件中的一或多者是否適合用於配套。一些物件不適合用於配套，此是由於客戶並未以配套購買所述物件，或由於以配套銷售所述物件並不表示任何差異性定價。在步驟1408中，平衡系統320可判定FC中可用的物件中的至少一些是否可配套。若平衡系統320判定物件中無一者可配套(步驟1408：否)，則平衡系統320可繼續至步驟1410，且更新庫存資料庫(例如，更新平衡資料庫324)且通知賣方入口網站，故賣方入口網站不提供配套產品。然而，若平衡系統320判定物件中的一或多者可配套(步驟1408：是)，則平衡系統320可繼續至步驟1412。

在步驟1412中，平衡系統320可判定配套分組產生配套標籤。舉例而言，平衡系統320可判定可針對在庫存中接收到的物件及其相關聯分組數目或配套數量創建多少虛擬配套。另外，在步驟1412中，平衡系統320可判定配套標籤，諸如如結合圖10所描述的「VB-2」。在步驟1414中，平衡系統320可判定配套定價。舉例而言，平衡系統320可使用預報需求資料及/或營銷活動來指定在步驟1412中判定的虛擬配套的配套及物件定價。

在步驟1416中，平衡系統320可序連物件ID(在步驟1406中判定)與經編碼標籤(在步驟1412中判定)以產生識別虛擬配套物件、分組數量以及定價的完整物件及配套標識。舉例而言，編碼器648(圖6)可使用指定的ID及虛擬配套分組或定價來產生序連物件ID，所述序連物件ID提供資訊以識別平衡資料庫324中的虛擬配套。因此，在步驟1416中，平衡系統320可產生多個經編碼標籤，經編碼標籤中的每一者對物件ID及配套群組進行編碼，且在資料庫中針對庫存資料中的每一物件及多個配套中的每一者產生記錄，每一資料記錄包括經編碼標籤欄位及數量欄位。

在步驟1418中，平衡系統320可針對資料庫中的每一物件及每一配套產生具有經編碼標籤、數量、分組、價格比率及/或FC的欄位的記錄。舉例而言，平衡系統320可針對虛擬配套中的每一者產生記錄，如結合圖10所描述。舉例而言，在步驟1418中，平衡系統320可產生多個配套的記錄，其中更高分組的相關聯配套與比更低分組的虛擬配套更低的每物件價格相關聯。在步驟1420中，平衡系統320可將資料庫暴露於查詢及/或API調用。舉例而言，平衡系統320可將在步驟1418中產生的記錄暴露於來自賣方入口網站的REST API調用，以提供產生具有虛擬配套及多個變化的清單及可用物件的定價的網站所需的資訊。

圖15為與所揭露實施例一致的用於指定履行中心的例示性過程1500的流程圖。在一些實施例中，系統300的元件可進行過程1500。舉例而言，如以下步驟描述中所揭露，平衡系統320可進行過程1500。特定而言，FC識別器644(圖6)可進行過程1500。替代地或另外，系統300的其他元件可進行過程1500的一或多個步驟。舉例而言，資料庫380、客戶端裝置350或線上資源340可進行過程1500或過程1500的部分。另外，在一些實施例中，系統800及系統900，或所述系統800及系統900的部分可進行過程1500。舉例而言，配套系統908可進行過程1500。

在步驟1502中，平衡系統320可接收對履行客戶端訂單的請求。請求可包含產品、時間以及郵遞碼資訊。基於請求中的資訊，平衡系統320可在步驟1504中識別相關地理區域。舉例而言，平衡系統320可基於客戶的郵遞碼來識別可履行產品的潛在訂單的區域。在步驟1506中，平衡系統320可識別可完成產品或選定配套的潛在訂單的FC。

在步驟1508中，平衡系統320可運行用於FC的訂單分配優先級規則。在一些實施例中，分配優先級規則可儲存於平衡系統320內的記憶體裝置中，所述記憶體裝置可在步驟1504中取回特定針對識別出的區域的分配規則。替代地或另外，分配優先級規則可儲存於資料庫380中，且平衡系統320可在已在步驟1506中識別出FC後查詢資料庫。

訂單分配規則可為區域中的每一FC產生優先級分數。優先級分配規則可包含具有不同偏好的若干規則。舉例而言，訂單分配規則可包含對特定承運商具有偏好的用於遞送承運商的規則。另外，訂單分配規則可包含虛擬配套的所估計遞送及多樣性。另外，基於歷史趨勢及產品與每一FC的關聯，分配規則可估計假定的需求且給出對具有較低需求的FC的偏好。

考慮到分配規則，平衡系統320可在步驟1512中基於計算出的優先級對FC進行排名。舉例而言，可為區域中的所有FC指定優先級分數且可基於優先級分數對FC進行排名。

在步驟1514中，平衡系統320可判定前面的FC是否具有類似優先級。舉例而言，平衡系統320可判定FC的優先級分數是否在臨限值內。若前面的FC不具有類似優先級(步驟1514：否)，則平衡系統320可繼續至步驟1516且識別具有最高優先級的FC。然而，若前面的FC具有類似優先級(步驟1514：是)，則平衡系統320可繼續至步驟1518且應用隨機產生器函數以選擇最前面的FC。

在步驟1520中，平衡系統320可進行盒整合(box consolidation)分配估計。藉由選定FC，平衡系統320可判定自FC運送的成本，包含將用於運送的盒的數目。在步驟1522中，平衡系統320可判定包裹或盒的數目在盒整合的情況下是否減小。若包裹的數目未減小(步驟1522：否)，則平衡系統320可繼續至步驟1524且維持先前分配。然而，若包裹的數目在盒整合之後減小(步驟1522：是)，則平衡系統320可繼續至步驟1526且將分配更新至整合分配。

在步驟1528中，平衡系統320可進行自動平衡整合。自動平衡考量可嘗試平衡在步驟1504中識別出的區域的不同FC中的負載。以避免使特定中心過度負擔為目標，平衡系統320可進行嘗試改良不同FC中的資源利用率的自動平衡。

在步驟1530中，基於自動平衡整合，平衡系統320可判定在步驟1516或步驟1518中指定的FC是否高於目標利用率。若平衡系統320判定FC未高於目標利用率(步驟1530：否)，則平衡系統320可繼續至步驟1532且維持先前分配。然而，若平衡系統320判定FC高於目標利用率(步驟1530：是)，則平衡系統320可繼續至步驟1536，且改變選定FC以避免使選定FC過度負擔。在過程1500的一些實施例中，平衡系統320可在步驟1536之後返回至步驟1520以重運行盒且自動平衡新選定FC的整合。

在步驟1534中，平衡系統320可將選定FC及對應所估計時間傳輸至步驟1502的請求者及/或傳輸至諸如平衡資料庫324的資料庫，以請求訂單履行且更新所估計庫存。

圖16為與所揭露實施例一致的用於動態地再平衡虛擬配套庫存的例示性過程1600的流程圖。在一些實施例中，系統300的元件可進行過程1600。舉例而言，如以下步驟描述中所揭露，平衡系統320可進行過程1600。替代地或另外，系統300的其他元件可進行過程1600的一或多個步驟。舉例而言，資料庫380、客戶端裝置350或線上資源340可進行過程1600或過程1600的部分。另外，在一些實施例中，系統800及系統900，或所述系統 800及系統900的部分可進行過程1600。舉例而言，配套系統908可進行過程1600。

在步驟1602中，平衡系統320可自至少一個履行中心接收庫存資料。舉例而言，平衡系統320可自FC/倉庫系統310接收庫存資料。在一些實施例中，庫存資料反映至少一個履行中心中的物件的實體數量。在步驟1604中，平衡系統320可在資料庫中儲存與分組數目及數量相關聯的多個虛擬配套。舉例而言，如結合圖10進一步描述，平衡系統320可針對不同物件產生多個虛擬配套，從而指明分組數目、配套的可用數量(亦即，可用配套的數目)以及配套價格。虛擬配套可儲存於諸如資料庫380的資料庫中，及/或諸如表1200(圖12)的資料結構中。在一些實施例中，在步驟1604中，平衡系統320可針對庫存資料中的每一物件創建至少兩個配套。

在步驟1606中，平衡系統320可將資料庫作為RESTful服務、基於佇列的系統、索引或目標表中的至少一者暴露於賣方入口網站查詢。舉例而言，平衡系統320可暴露REST API以用於諸如(1)監視事件虛擬配套、(2)更新虛擬配套以及(3)提供包含可用配套的庫存資料的服務。在此類實施例中，平衡資料庫324可儲存發出GET、PUT、DELETE或POST指令的指令，以使用暴露的API服務請求來自平衡系統320的資訊或將資訊發送至平衡系統320。替代地或另外，在步驟1606中，平衡系統320可向儲存即時庫存及配套資訊的資料庫及/或記憶體裝置開放查詢。

在步驟1608中，平衡系統320可自賣方入口網站接收客戶端訂單。客戶端訂單可包含來自多個虛擬配套的配套選擇。舉例而言，賣方入口網站702(圖7)或外部前端系統103(圖1A)中的一者可接收轉送至平衡系統320的客戶端訂單，如結合圖7及圖11所論述。在一些實施例中，訂單可包含第一訂單958或第二訂單956(圖9)中的一或多者。

在步驟1610中，平衡系統320可經由依序指定物件來再平衡多個虛擬配套，從而使配套多樣性最大化。舉例而言，如結合圖10及圖13進一步論述，平衡系統320可基於使配套多樣性最大化(亦即，具有用於配套清單的最大數目個選項)的規則或基於預報資料來再平衡多個虛擬配套中的可用庫存。在一些實施例中，步驟1610可包含藉由聚合與多個虛擬配套相關聯的庫存且基於聚合的庫存再平衡多個虛擬配套而更新多個虛擬配套。

在步驟1612中，平衡系統320可更新資料庫以修改物件庫存。舉例而言，如結合圖10所論述，平衡系統320可修改虛擬配套中的分組數目以反映更低庫存。另外，在步驟1612中，平衡系統320亦可基於預報資料或營銷活動來修改虛擬配套的定價。

在步驟1614中，平衡系統320可自至少一個FC接收週期性庫存資料。舉例而言，如結合圖11所論述，平衡系統320可自FC/倉庫系統310週期性地接收庫存更新，包含關於FC或倉庫處的可用庫存的更新。在步驟1616中，平衡系統320可基於自FC接收到的資訊來再平衡多個虛擬配套。如結合圖11所論述，在一些實施例中，更新資料可覆寫所估計資訊。

圖17為與所揭露實施例一致的用於回應於客戶端訂單而動態地再平衡虛擬配套的例示性過程1700的流程圖。在一些實施例中，系統300的元件可進行過程1700。舉例而言，如以下步驟描述中所揭露，平衡系統320可進行過程1700。替代地或另外，系統300的其他元件可進行過程1700的一或多個步驟。舉例而言，資料庫380、客戶端裝置350或線上資源340可進行過程1700或過程1700的部分。另外，在一些實施例中，系統800及系統900，或所述系統800及系統900的部分可進行過程1700。舉例而言，配套系統908可進行過程1700。

在步驟1702中，平衡系統320可接收庫存資料。舉例而言，平衡系統320可自系統300中的FC或倉庫接收庫存資料。在步驟1704中，平衡系統320可判定接收到的庫存是否包含或分組於虛擬配套中。若平衡系統320判定接收到的庫存未組織於配套中(步驟1704：否)，則平衡系統320可繼續至步驟1706且更新庫存或配套系統，諸如配套系統908(圖9)。然而，若平衡系統320判定接收到的庫存可組織於配套中(步驟1704：是)，則平衡系統320可繼續至步驟1708。

在步驟1708中，平衡系統320可產生經編碼標籤。舉例而言，如結合圖14進一步描述，編碼器648可藉由編碼物件識別符、配套識別符以及分組數目而產生標籤。在步驟1710中，平衡系統320可在配套資料庫中產生具有經編碼標籤的記錄。舉例而言，平衡系統320可基於經編碼標籤用用於虛擬配套的識別符填充資料庫或資料結構，如表1200(圖12)。在步驟1712中，平衡系統320可將配套資料庫的虛擬配套資訊暴露於賣方入口網站API調用。舉例而言，平衡系統320可將平衡資料庫324暴露於來自賣方入口網站109(圖1A)的調用。

在步驟1714中，平衡系統320可判定其是否已接收到具有所請求配套的客戶端訂單。舉例而言，經由全域庫存系統，平衡系統320可接收客戶端請求。在步驟1714中，平衡系統320可判定是否存在對在步驟1712中暴露的配套中的一或多者的客戶端請求。若平衡系統320判定其尚未接收到具有所請求配套的客戶端訂單(步驟1714：否)，則平衡系統320可繼續至步驟1706且更新庫存系統。但，若平衡系統320判定其已接收到具有所請求配套的客戶端訂單(步驟1714：是)，則平衡系統320可繼續至步驟1716且基於配套選擇來更新配套數量。舉例而言，平衡系統320可進行操作1000(圖10)以基於客戶端請求來再平衡虛擬配套。

在步驟1718中，平衡系統320可判定一個配套數量是否低於臨限值。舉例而言，平衡系統320可評估再平衡過程是否留下具有低於臨限值的低數量的一或多個虛擬配套。此低數量配套可能為非所要的，此是由於其可導致錯誤OOS通知。若在步驟1718中平衡系統320判定一個配套數量低於臨限值(步驟1718：是)，則平衡系統320可繼續至步驟1720，且經由依序指定來再平衡多個配套以重新配置可用庫存從而使配套多樣性最大化。然而，若在步驟1718中平衡系統320判定配套數量中無一者低於臨限值(步驟1718：否)，則平衡系統320可繼續至步驟1706且更新庫存系統。

圖18為示出根據所揭露實施例的用於產生機器學習預測模型的例示性過程1800的流程圖。在一些實施例中，系統300的元件可進行過程1800。舉例而言，如以下步驟描述中所揭露，平衡系統320可進行過程1800。特定而言，平衡模組646(圖6)可進行過程1800。替代地或另外，系統300的其他元件可進行過程 1800的一或多個步驟。舉例而言，資料庫380、客戶端裝置350或線上資源340可進行過程1800或過程1800的部分。另外，在一些實施例中，系統800及系統900，或所述系統800及系統900的部分可進行過程1800。舉例而言，配套系統908可進行過程1800。

在步驟1802中，平衡系統320可判定訓練資料集及驗證資料集。舉例而言，平衡系統320可在訓練及驗證部分中分割虛擬配套購買所收集的配套記錄606(圖6)。平衡系統320可接收過去購買的資料、過去庫存可用性及/或虛擬配套定價。在一些實施例中，虛擬配套資訊可包含描述記錄的屬性及相關聯性質的元資料。平衡系統320可劃分記錄且產生兩個群組，一個用以訓練機器學習模型且第二個用以驗證模型。

在步驟1804中，平衡系統320可基於訓練資料集的特徵來產生輸入陣列。舉例而言，平衡系統320可產生變數，包含虛擬配套的所估計需求、需求的週期性以及定價彈性。

在步驟1806中，平衡系統320可基於訓練資料集的元資料來產生輸出向量。舉例而言，基於訓練資料集中的虛擬配套購買的所記錄資料，平衡系統320可產生所要輸出向量，從而對例如配套物件的預報需求作出預測。

在步驟1808中，平衡系統320可判定樣本超參數及激活函數以初始化待創建的模型。舉例而言，平衡系統320可選擇諸如數個層及節點的初始超參數，且判定網路將完全抑或部分連接。此外，在步驟1808中，平衡系統320可判定網路的維數及/或判定接受域網路的堆疊。此外，在步驟1808中，平衡系統320 亦可使模型與一或多個激活函數相關聯。舉例而言，平衡系統320可使模型與一或多個S形函數相關聯。在步驟1810中，平衡系統320可使網路中的突觸(synapsis)的權重初始化。

在步驟1812中，平衡系統320可在模型中輸入驗證資料集。舉例而言，平衡系統320可基於步驟1804的訓練資料集的特徵來應用輸入陣列，以在步驟1814中計算所估計輸出及成本函數。在步驟1820中，平衡系統320可判定成本函數是否低於所需準確度的臨限值，所述臨限值可由平衡系統320的管理員指明。若平衡系統320判定成本函數不低於臨限值且尚未達成所需準確度，則平衡系統320可繼續至步驟1822且修改模型參數。舉例而言，當產生神經網路時，在步驟1822中，平衡系統320可判定修改突觸中的權重或修改不同節點中的激活函數的梯度。然而，若成本函數低於臨限值(步驟1820：是)，則平衡系統320可在步驟1824中接受及傳達模型。

圖19為與所揭露實施例一致的在行動裝置中的一系列單一顯示頁例示性圖形使用者介面的正視圖。圖19繪示可在再平衡操作之前顯示於客戶端裝置350(圖3)中的第一GUI 1920。舉例而言，當客戶端裝置瀏覽賣方入口網站從而尋找產品時，GUI 1920可顯示於客戶端裝置中。如圖19中所繪示，GUI 1920包含繪示展示於單一顯示頁中的物件的不同配套的表1922。舉例而言，單一顯示頁可展示物件A。賣方入口網站可提供物件A的多個配套，包含物件A的配套分組1、配套分組3以及配套分組5(例如，經編碼的VB1、VB3以及VB5)。表1922亦可指明可用配套的數量及配套價格。

圖19亦繪示第二GUI 1930。GUI 1930可顯示與GUI 1920相同的單一顯示頁。然而，GUI 1930可具有更新後的表1932。舉例而言，當客戶產生配套物件的訂單時的GUI 1930。如上文結合圖11所描述，客戶端訂單觸發FC、賣方入口網站以及平衡系統之間的一系列通信，所述一系列通信引起用於更新可用庫存及可用配套的再平衡過程。因此，表1932可顯示虛擬配套的經修改數量。在一些實施例中，GUI 1930亦可顯示經修改定價以反映需求預報及/或營銷活動。

本揭露內容的另一態樣是針對一種儲存指令的非暫時性電腦可讀媒體，所述指令在執行時使得一或多個處理器進行方法，如上文所論述。電腦可讀媒體可包含揮發性或非揮發性、磁性、半導體、磁帶、光學、可移除、非可移除或其他類型的電腦可讀媒體或電腦可讀儲存裝置。舉例而言，電腦可讀媒體可為在其上具有儲存的電腦指令的儲存單元或記憶體模組，如所揭露。在一些實施例中，電腦可讀媒體可為在其上具有儲存的電腦指令的磁碟或快閃驅動器。

對所屬技術領域中具有通常知識者將顯而易見的是，可對所揭露系統及相關方法作出各種修改及變化。其他實施例對所屬技術領域中具有通常知識者將自本說明書的考量及所揭露系統及相關方法的實踐顯而易見。意欲僅將本說明書及實例視為例示性的，其中真實範圍由以下申請專利範圍及其等效物指示。

儘管已參考本揭露內容的特定實施例繪示及描述本揭露內容，但應理解，可在不修改的情況下在其他環境中實踐本揭露內容。已出於示出的目的呈現前述描述。前述描述並不詳盡且不限於所揭露的精確形式或實施例。修改及調適對所屬技術領域中具有通常知識者將自本說明書的考量及所揭露實施例的實踐顯而易見。另外，儘管將所揭露實施例的態樣描述為儲存於記憶體中，但所屬技術領域中具有通常知識者應瞭解，此等態樣亦可儲存於其他類型的電腦可讀媒體上，諸如次級儲存裝置，例如硬碟或CD ROM，或其他形式的RAM或ROM、USB媒體、DVD、藍光，或其他光碟機媒體。

基於書面描述及所揭露方法的電腦程式在有經驗開發者的技能內。各種程式或程式模組可使用所屬技術領域中具有通常知識者已知的技術中的任一者來創建或可結合現有軟體來設計。舉例而言，程式區段或程式模組可以或藉助於.Net框架(.Net Framework)、.Net緊密框架(.Net Compact Framework)(及相關語言，諸如視覺培基(Visual Basic)、C等)、爪哇(Java)、C++、目標-C(Objective-C)、HTML、HTML/AJAX組合、XML或包含爪哇小程式的HTML來設計。

此外，儘管本文中已描述示出性實施例，但所屬技術領域中具有通常知識者將基於本揭露內容瞭解具有等效元件、修改、省略、(例如，各種實施例中的態樣的)組合、調適及/或更改的任何及所有實施例的範圍。申請專利範圍中的限制應基於申請專利範圍中所採用的語言來廣泛地解釋，且不限於本說明書中所描述或在本申請案的審查期間的實例。實例應視為非排他性的。另外，所揭露方法的步驟可以包含藉由對步驟重新排序及/或插入或刪除步驟的任何方式修改。因此，希望僅將本說明書及實例視為示出性的，其中藉由以下申請專利範圍及其等效物的完整範圍指示真實範圍及精神。

因此，已僅出於示出的目的而呈現前述描述。前述描述並不為窮盡性的且不限於所揭露的精確形式或實施例。修改及調適對所屬技術領域中具有通常知識者將自本說明書的考量及所揭露實施例的實踐顯而易見。

申請專利範圍應基於申請專利範圍中所採用的語言來廣泛地解釋，且不限於本說明書中所描述的實例，所述實例應視為非排他性的。另外，所揭露方法的步驟可以包含藉由對步驟重新排序及/或插入或刪除步驟的任何方式修改。

1300:過程

1302、1304、1306、1308、1310、1312、1314、1316、1318、1320、1322、1324、1330:步驟

Claims

一種用於動態庫存平衡的系統，包括：至少一個處理器；以及至少一個記憶體裝置，包括指令，所述指令在執行時組態所述至少一個處理器進行包括下述者的操作：自至少一個履行中心接收庫存資料饋入；在資料庫中儲存具有相關聯分組數目及數量的多個虛擬配套，所述多個虛擬配套包括對所述庫存資料中的相同物件中的兩者或大於兩者進行分組的物件配套；經由類表現層狀態轉換服務、基於佇列的系統、索引或目標表中的至少一者將所述資料庫暴露於來自賣方入口網站的查詢；自所述賣方入口網站接收客戶端訂單，所述客戶端訂單包括來自所述多個虛擬配套的配套選擇；回應於接收到所述客戶端訂單，藉由基於所述配套選擇再平衡所述多個虛擬配套及對應相關聯數量而更新所述多個虛擬配套；自所述至少一個履行中心接收更新後的庫存資料；基於所述更新後的庫存資料來再平衡所述資料庫中的所述多個虛擬配套；以及回應於更新所述多個虛擬配套，向所述賣方入口網站告知所述資料庫中的改變其中：所述更新後的庫存資料覆蓋與儲存於所述資料庫中的所述多個虛擬配套相關聯的數量；且暴露所述資料庫包括將所述資料庫作為類表現層狀態轉換服務暴露於所述賣方入口網站。
如請求項1所述的系統，其中更新所述多個虛擬配套包括：基於所述配套選擇來判定更新後的物件庫存；經由依序指定物件來再平衡所述多個虛擬配套從而使配套多樣性最大化；以及更新所述資料庫以修改物件庫存。
如請求項1所述的系統，其中儲存所述多個虛擬配套包括：產生多個經編碼標籤，所述多個經編碼標籤中的每一者對物件識別碼及配套群組進行編碼，以及在所述資料庫中針對所述庫存資料中的每一物件及所述多個虛擬配套中的每一者產生記錄，每一資料記錄包括經編碼標籤欄位及數量欄位。
如請求項1所述的系統，其中：在一天至少一次的週期性下週期性地接收所述更新後的庫存資料作為快照庫存；且所述多個虛擬配套與折扣價格相關聯，更高分組的所述多個虛擬配套與比更低分組的虛擬配套更低的每物件價格相關聯。
如請求項1所述的系統，其中：所述庫存資料饋入為耦接至所述至少一個履行中心的庫存系統的即時資料饋入，所述庫存系統包括掃描碼系統、成像庫存系統或無線標籤系統中的至少一者；且所述賣方入口網站經組態以藉由經由一或多個應用程式介面調用查詢所述資料庫將所述多個虛擬配套的可用性及價格傳輸至客戶端裝置。
如請求項1所述的系統，其中：所述庫存資料反映所述至少一個履行中心中的物件的實體數量；且更新所述多個虛擬配套包括：聚合與所述多個虛擬配套相關聯的庫存；以及基於聚合的庫存來再平衡所述多個虛擬配套。
如請求項1所述的系統，其中：為所述庫存資料中的每一物件創建至少兩個配套；且再平衡所述多個虛擬配套包括藉由減少可用配套的數目而更新所述資料庫。
如請求項1所述的系統，其中所述操作更包括：回應於接收到所述客戶端訂單，自所述至少一個履行中心識別用於所述客戶端訂單的選定履行中心且將所述客戶端訂單傳達至所述選定履行中心。
一種用於動態庫存平衡的電腦實行方法，包括：自至少一個履行中心接收庫存資料饋入；在資料庫中儲存具有相關聯分組數目及數量的多個虛擬配套，所述多個虛擬配套包括對所述庫存資料中的相同物件中的兩者或大於兩者進行分組的物件配套；經由類表現層狀態轉換服務、基於佇列的系統、索引或目標表中的至少一者將所述資料庫暴露於來自賣方入口網站的查詢；自所述賣方入口網站接收客戶端訂單，所述客戶端訂單包括來自所述多個虛擬配套的配套選擇；回應於接收到所述客戶端訂單，藉由基於所述配套選擇再平衡所述多個虛擬配套及對應相關聯數量而更新所述多個虛擬配套；自所述至少一個履行中心接收更新後的庫存資料；基於所述更新後的庫存資料來再平衡所述資料庫中的所述多個虛擬配套；以及回應於更新所述多個虛擬配套，向所述賣方入口網站告知所述資料庫中的改變，其中：所述更新後的庫存資料覆蓋與儲存於所述資料庫中的所述多個虛擬配套相關聯的數量；以及暴露所述資料庫包括將所述資料庫作為類表現層狀態轉換服務暴露於所述賣方入口網站。
如請求項9所述的方法，其中更新所述多個虛擬配套包括：基於所述配套選擇來判定更新後的物件庫存；經由依序指定物件來再平衡所述多個虛擬配套從而使配套多樣性最大化；以及更新所述資料庫以修改物件庫存。
如請求項9所述的方法，其中儲存所述多個虛擬配套包括：產生多個經編碼標籤，所述多個經編碼標籤中的每一者對物件識別碼及配套群組進行編碼，以及在所述資料庫中針對所述庫存資料中的每一物件及所述多個虛擬配套中的每一者產生記錄，每一資料記錄包括經編碼標籤欄位及數量欄位。
如請求項9所述的方法，其中：在一天至少一次之間的週期性下週期性地接收所述更新後的庫存資料作為快照庫存；且所述多個虛擬配套與折扣價格相關聯，更高分組的所述多個虛擬配套與比更低分組的虛擬配套更低的每物件價格相關聯。
如請求項9所述的方法，其中：所述庫存資料饋入為耦接至所述至少一個履行中心的庫存系統的即時資料饋入，所述庫存系統包括掃描碼系統、成像庫存系統或無線標籤系統中的至少一者；且所述賣方入口網站經組態以藉由經由一或多個應用程式介面調用查詢所述資料庫將所述多個虛擬配套的可用性及價格傳輸至客戶端裝置。
如請求項9所述的方法，其中：所述庫存資料反映所述至少一個履行中心中的物件的實體數量；且更新所述多個虛擬配套包括：聚合與所述多個虛擬配套相關聯的庫存；以及基於聚合的庫存來再平衡所述多個虛擬配套。
如請求項9所述的方法，其中：為所述庫存資料中的每一物件創建至少兩個配套；且再平衡所述多個虛擬配套包括藉由減少可用配套的數目而更新所述資料庫。
如請求項9所述的方法，更包括：回應於接收到所述客戶端訂單，自所述至少一個履行中心識別用於所述客戶端訂單的選定履行中心且將所述客戶端訂單傳達至所述選定履行中心。
一種用於動態庫存平衡的設備，包括：一或多個處理器；以及一或多個記憶體裝置，包括指令，所述指令在執行時組態所述一或多個處理器以進行下述操作：自至少一個履行中心接收庫存資料饋入；在資料庫中儲存具有相關聯分組數目及數量的多個虛擬配套，所述多個虛擬配套包括藉由下述操作對所述庫存資料中的相同物件中的兩者或大於兩者進行分組的物件配套：產生多個經編碼標籤，所述多個經編碼標籤中的每一者對物件識別碼及配套群組進行編碼，以及在所述資料庫中針對所述庫存資料中的每一物件及所述多個虛擬配套中的每一者產生記錄，每一資料記錄包括經編碼標籤欄位及數量欄位；將所述資料庫作為類表現層狀態轉換服務暴露於來自賣方入口網站的查詢；自所述賣方入口網站接收客戶端訂單，所述客戶端訂單包括來自所述多個虛擬配套的配套選擇；回應於接收到所述客戶端訂單，藉由下述操作更新所述多個虛擬配套：經由依序指定物件來再平衡所述多個虛擬配套從而使配套多樣性最大化；自所述至少一個履行中心接收更新後的庫存資料；基於所述更新後的庫存資料來再平衡所述資料庫中的所述多個虛擬配套；以及回應於更新所述多個虛擬配套，向所述賣方入口網站告知所述資料庫中的改變，其中所述更新後的庫存資料覆蓋與儲存於所述資料庫中的所述多個虛擬配套相關聯的數量。