TWI777532B

TWI777532B - 用於集中式狀態監測的系統、電腦實行方法及設備

Info

Publication number: TWI777532B
Application number: TW110115328A
Authority: TW
Inventors: 蘇布拉馬尼亞普拉莫德南杜里; 書云麥克馬斯特; 達林米勒; 石肯尼
Original assignee: 南韓商韓領有限公司
Priority date: 2020-10-14
Filing date: 2021-04-28
Publication date: 2022-09-11
Also published as: KR102549317B1; KR20230101937A; US20220114535A1; TW202248918A; US11681972B2; KR20220051131A; US11062253B1; TW202215319A; WO2022079483A1

Abstract

本發明提供一種用於多領域網路中的集中式狀態監測的系統。系統包含：至少一個處理器；以及至少一個記憶體裝置，儲存指令，所述指令在執行時組態處理器進行操作。操作包含：建立與領域的連接；自第一領域接收起始監測操作的第一請求；以及在儲存於第一資料庫中的狀態表中產生新條目。操作亦可包含自第二領域接收更新監測操作的第二請求，以及回應於接收到第二請求，藉由修改狀態欄位而更新狀態表中的新條目。操作亦可包含回應於自監測引擎接收到第三請求而應用監測操作及產生將其中狀態欄位匹配類別狀態的條目包括於狀態表中的警示。

Description

用於集中式狀態監測的系統、電腦實行方法及設備

本揭露大體上是關於用於在多領域網路中集中式監測的電腦化系統及方法。特定言之，本揭露的實施例是關於用於經由使用分佈式超媒體通信的多領域網路監測訂單或票證的狀態以用於動態地更新集中式資料庫及廣播警示的系統及方法。

具有多個場所、部門及/或商業單元的公司及組織頻繁地利用具有多個領域的網路(亦被稱作多領域網路)來控制、監測以及組織內部及外部通信。公司通常組織具有多個領域的網路以有效地分配資源並指定任務。另外，使用多個領域拓樸允許網路管理器更有效地監測及控制通信。舉例而言，多領域網路使用在傳入及傳出訊務分佈之前過濾、路由以及掃描訊務的領域管理器而實現階層通信控制的使用。

現如今，網路頻繁地經組態有在複雜柵格中彼此耦接且經組態以實行卷積工作流程的多個領域。舉例而言，網路在安全資料中心及面向客戶的領域中頻繁地隔離以組織通信及資源。然而，此等領域緊密地鏈接且即時頻繁地彼此互動。並且領域間互動需要為快速、準確且安全的以提供足夠的使用者體驗。

複雜網路拓樸及高效能需求的組合已產生對開發及管理多領域網路的挑戰。管理大型多領域網路為複雜的，此是因為同一網路內的領域可具有獨立及專用拓樸。另外，網路中的領域可具有不同資源分佈、非均一協定或不一致網路組態。此外，即時領域間互動的要求頻繁地妨礙可能干擾或延遲通信的某些管理操作。缺乏用於管理操作的授權的絕大部分領域組態、拓樸以及協定(甚至在單一網路內)的組合已產生有效管理多領域網路的重要技術挑戰。

用於多領域網路中的集中式狀態監測的所揭露系統及方法解決上文所闡述的一或多個問題及/或先前技術中的其他問題。

本揭露內容的一個態樣是有關於一種用於多領域網路中的集中式狀態監測的系統。系統可包含：至少一個處理器；以及至少一個記憶體裝置，包含指令，所述指令在執行時組態至少一個處理器進行操作。操作可包含建立與第一領域及第二領域的連接，自第一領域接收起始監測操作的第一請求(所述第一請求包括創建請求)，以及在儲存於第一資料庫中的狀態表中產生新條目，所述狀態表包含：(1)ID欄位，(2)預期的結束欄位，以及(3)狀態欄位。操作亦可包含：自第二領域接收更新監測操作的第二請求，所述第二請求包括更新狀態請求；及回應於接收到第二請求，藉由修改狀態欄位而更新狀態表中的新條目。另外，操作可包含：回應於自監測引擎接收到第三請求(所述第三請求包括報告請求及類別狀態)而應用監測操作，其中監測引擎經組態以定期產生第三請求；以及產生將其中狀態欄位匹配類別狀態的條目包括於狀態表中的警示。

本揭露內容的另一態樣是有關於一種用於多領域網路中的集中式狀態監測的電腦實行方法。方法包含建立與第一領域及第二領域的連接，自第一領域接收起始監測操作的第一請求，所述第一請求包括創建請求，以及在儲存於第一資料庫中的狀態表中產生新條目，所述狀態表包含：(1)ID欄位，(2)預期的結束欄位，以及(3)狀態欄位。方法亦可包含：自第二領域接收更新監測操作的第二請求，所述第二請求包括更新狀態請求；及回應於接收到第二請求，藉由修改狀態欄位而更新狀態表中的新條目。方法亦可包含：回應於自監測引擎接收到第三請求(所述第三請求包括報告請求及類別狀態)而應用監測操作，其中監測引擎經組態以定期產生第三請求；以及產生將其中狀態欄位匹配類別狀態的條目包括於狀態表中的警示。

本揭露內容的另一態樣是有關於一種設備。設備包含一或多個處理器及包括指令的一或多個記憶體裝置，所述指令在執行時組態一或多個處理器：藉由進行自動化探索操作而建立與第一領域及第二領域的連接。自動探索包含：自動地探索與第一領域及第二領域相關聯的組態模板；組態第一領域(經由與第一領域相關聯的一或多個網路API)以在接收到新訂單或將訂單發送至履行中心時產生創建請求；以及經由與第二領域相關聯的一或多個網路API組態第二領域以在運送物件時產生更新請求。指令進一步組態至少一個處理器自第一領域接收起始監測操作的第一請求(所述第一請求包括包含訂單鍵的第一REST API呼叫)，訂單鍵編碼物件ID及供應商ID。指令亦可組態至少一個處理器以在儲存於第一資料庫中的狀態表中產生新條目，所述狀態表包含：(1)ID欄位，(2)預期的結束欄位，以及(3)狀態欄位。指令可進一步組態至少一個處理器自第二領域接收更新監測操作的第二請求，所述第二請求包括包含運送資訊的第二REST API呼叫，且回應於接收到第二請求，藉由修改狀態欄位而更新狀態表中的新條目。指令亦可組態至少一個處理器回應於自監測引擎接收到第三請求而應用監測操作(所述第三請求包括報告請求及類別狀態，所述監測引擎經組態以至少一日一次地產生第三請求，所述監測操作是經由自動化伺服器進行)，及在管理員網路中廣播將條目包括於狀態表中的警示電子郵件，在所述條目中狀態欄位的值為空或錯過PDD中的至少一者。

100、300:系統

101:運送授權技術系統

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

102B:電腦/使用者裝置

103:外部前端系統

105:內部前端系統

107:運輸系統

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

109:賣方入口網站

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:汽車

320:MDR系統

322:MDR處理器

324、502:通信裝置

325:MDR資料庫

340:線上資源

350:客戶端裝置

360:本端領域

361:購買領域

361-1:購買服務子領域

361-2:購買接收器子領域

362:庫存領域

362-1:庫存服務子領域

362-2:庫存接收器領域

363:訂單領域

363-1:訂單服務子領域

363-2:訂單接收器子領域

364:管理員領域

365:第三方系統

370:網路

380:資料庫

402:處理器

404:輸入/輸出裝置

410:記憶體

412、512:程式

414:客戶端應用程式

416、514:資料

420:攝影機

430:指紋感測器

504:資料庫處理器

510:資料庫記憶體

642:自動化探索模組

644:PDD計算器

646:機器學習訓練器

648:報告產生器

652:MDR程式

654:MDR快取資料

656:MDR狀態表

700:多領域網路

800、1200、1300、1400、1500、1600:過程

802:訂單發佈商

804:運送更新接收器

806:第一訊息或呼叫

808:第二訊息或呼叫

810:第三訊息或呼叫

812:第四訊息或呼叫

814:階段

816:監測條目

900、1000:過程流程

902、904、906、908、910、912、914、916、918、920、922、924、926、928、930、932、934、1002、1004、1006、1008、1010、1012、1014、1016、1202、1204、1206、1208、1210、1212、1214、1216、1218、1220、1222、1224、1302、1304、1306、1308、1310、1312、1314、1316、1318、1320、1402、1404、1406、1408、1410、1412、1414、1416、1502、1504、1506、1508、1512、1514、1516、1518、1520、1522、1524、1526、1528、1530、1532、1534、1536:步驟

1100:狀態表

1102、1102(a)、1102(b)、1102(c)、1102(d)、1102(e)、1102(f)、1102(z):監測實體

1110:欄位ID

1112:實體類型欄位

1114:實體欄位

1116:當前狀態欄位

1118:預期狀態欄位

1120:開始時間欄位

1122:預期結束時間欄位

1124:結束時間欄位

1126:狀態欄位

1240:週期

1602、1604、1606、1608、1610、1612、1614、1616、1618、1620:狀態

1700:GUI

1702:標頭

1704、1704(a)、1704(b)、1704(z):報告元素

1710:訂單編號

1712:當前狀態

1714:開始日期

1716:預期結束日期

1718:結束時間

1720:動作按鈕

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

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

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

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

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

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

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

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

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

圖6為與所揭露實施例一致的例示性多領域報告(multidomain reporting；MDR)系統的方塊圖。

圖7為與所揭露實施例一致的包含MDR系統的多領域網路的方塊圖。

圖8為與所揭露實施例一致的用於藉由MDR服務監測訂單運送的例示性過程的流程圖。

圖9為與所揭露實施例一致的用於經由自動化探索操作組態與多領域網路中的多個領域通信的例示性過程流程的時序圖。

圖10為與所揭露實施例一致的用於處理領域請求及產生警示的例示性過程流程的時序圖。

圖11為與所揭露實施例一致的用於多領域監測的儲存於資料庫中的例示性狀態表。

圖12為與所揭露實施例一致的用於多領域狀態監測的例示性過程的流程圖。

圖13為與所揭露實施例一致的用於經由自動探索連接建立多領域通信的例示性過程的流程圖。

圖14為與所揭露實施例一致的用於管理多領域狀態表中的監測實體的例示性過程的流程圖。

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

圖16為與所揭露實施例一致的描述用於多領域網路中的訂單的例示性狀態判定過程的狀態機圖。

圖17為與所揭露實施例一致的繪示經由管理員網路傳輸的警示的圖形使用者介面。

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

本揭露內容的實施例是關於用於進行斷開工作流程的多領域網路中的訂單或票證狀態監測的系統及方法。所揭露系統及方法可藉由創建追蹤整個多領域網路中的操作進程的自動化及集中式報告系統而經由多領域網路改良監測操作的技術領域。所揭露的系統可另外允許在多領域網路中程式化裝置以自動地傳輸藉由事件及/或其他領域間通信觸發的更新訊息。因此，用於集中式監測的所揭露系統及方法可藉由產生集中式資料庫來改良管理多領域網路的技術領域，所述集中式資料庫儲存事件以跨越整個網路監測斷開工作流程且提供允許管理員識別狀態並提供報告的均勻狀態變數。

所揭露的系統及方法的一些實施例解決監測電子商務網路中的訂單的問題。舉例而言，所揭露系統使得能夠即時地監測客戶訂單的狀態，而不管當前處理領域如何。所揭露系統的此類實施例可允許網路管理器或管理員藉由識別錯過的承諾遞送日期(PDD)、出錯的預計遞送日期或延遲而容易地識別訂單或票證的狀態。因此，所揭露的系統及方法可藉由使監測操作自動化且實現中斷工作流程的快速識別及解決而改良多領域網路管理的技術領域。

所揭露的系統及方法的一些實施例可尤其改良基於多領域網路的自動化運送系統。多個斷開連接工作流程參與訂單履行過程，包含購買、下訂單以及運送工作流程。此等工作流程可彼此連接但可按其自身步調且在不同領域中執行。舉例而言，訂單處理可在獨立於訂單運送的領域中處理。所揭露的系統及方法可提供用以監測整個多個領域中的訂單的狀態且基於機器學習模型進行預測的工具。舉例而言，在集中式資料庫中收集且標準化的資料可用於訓練允許管理器預測訂單或票證延遲的預測性機器學習(ML)模型。因此，所揭露系統及方法亦可藉由提供預測性及分析工具來改良多領域網路的管理。

此外，所揭露的系統及方法的一些實施例可應用於解決在多領域網路中監測客戶訂單以識別錯過(或將錯過)預計遞送日期或承諾遞送日期(PDD)的訂單的問題。然而，除監測訂單遞送以外，所揭示的系統及方法的實施例可監測多領域網路中的訂單購買或庫存。

此外，所揭露的系統及方法亦可藉由提供用以進行自動地組態領域間通信的自動化探索操作的工具來改良組態多領域網路的技術領域。舉例而言，在一些實施例中，所揭示系統及方法可提供用於藉由使用基於標準化網站的通信途徑(諸如代表性狀態傳送(REST)呼叫)將多個領域連接至集中式報告系統，且對領域進行組態以傳輸由里程碑或特定事件觸發的自動化通信的工具。所揭露的系統及方法的此類實施例可解決缺乏均勻性及/或多領域網路中的管理授權的問題。

所揭露的系統及方法的實施例亦可藉由創建經由自動化探索無縫地擴展經監測領域群組的工具而解決在多領域網路中組態監測系統的技術問題。舉例而言，所揭露的系統及方法可提供工具以自動地識別多領域網路中的新領域，或識別網路的新操作，以產生額外監測實體或組態領域以用於額外報告通信。所揭露的系統及方法的此類實施例可包含應用ML演算法以識別網路中的通信模式且相應地調整監測資料庫。

另外，所揭露的系統及方法的實施例可藉由自動地監測異常情境及/或延遲來改良多領域系統的管理。舉例而言，所揭露的系統及方法可提供類似於均勻報告系統起作用的整合及集中式狀態監測資料庫，其提供對狀態請求的回應及/或產生警示、任務及/或訂單。此類實施例可藉由產生可即時及/或定期地查詢的報告服務而促進多領域系統的管理，從而實現訂單或票證狀態的密切監測。所揭露的系統及方法的此類實施例可允許自動地協調斷開工作流程以識別及解決延遲。另外，此類實施例亦可藉由針對狀態監測的按需查詢提供REST服務來改良多領域網路的管理。

所揭露的系統及方法的實施例亦可藉由減少用於監測多領域網路中的事件的訊務而改良多領域網路中的頻寬利用率。所揭露的系統及方法的一些實施例可允許在減少的開銷下使用與集中式系統的簡單及標準化通信來監測不同斷開工作流程，所述集中式系統將斷開工作流程會聚成幾個參數。此類實施例可藉由使網路擁擠最小化來改良多領域網路的效能。舉例而言，所揭露的系統及方法可藉由減少、標準化以及簡化用於狀態監測的通信而改良網路通信。

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

圖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的裝置之間的通信。

在一些實施例中，外部前端系統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 Display Page；SDP)(例如，圖1C)、購物車頁(例如，圖1D)，或訂單頁(例如，圖1E)。(例如，使用行動裝置102A或電腦102B的)使用者裝置可導航至外部前端系統103且藉由將資訊輸入至檢索盒中來請求檢索。外部前端系統103可向系統100中的一或多個系統請求資訊。舉例而言，外部前端系統103可向FO系統113請求滿足檢索請求的資訊。外部前端系統103亦可(自FO系統113) 請求及接收包含於檢索結果中的每一產品的承諾遞送日期或「PDD」。在一些實施例中，PDD可表示在特定時間段內(例如，在一天結束(下午11：59)前)訂購的情況下對含有產品的包裹將何時抵達使用者的所要位置或承諾將產品遞送至使用者的所要位置處的日期的估計。(PDD在下文相對於FO系統113進一步論述。)

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

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

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

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

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

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

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

在一些實施例中，外部前端系統103可進一步經組態以使得賣方能夠傳輸及接收與訂單相關的資訊。

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

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

在一些實施例中，運輸系統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中的產品的一或多個計數、哪一履行中心儲存每一產品、產品的預期或當前訂單，或類似者。

在一些實施例中，履行通信報閘道(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、行動裝置/PDA 119B、電腦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中，多領域報告(MDR)系統320可包含經組態以處理來自即時客戶端裝置或領域的資料串流的資訊請求的伺服器、電腦模組及/或資料處理中心。舉例而言，MDR系統320可基於客戶端或領域資料收集及/或提供關於訂單或票證的資訊。另外，MDR系統320可追蹤及提供關於正由領域處理的訂單或票證的資訊，以解決狀態請求，所述領域諸如本端領域360及第三方領域365。MDR系統320亦可產生顯示具有狀態資訊及/或暴露服務的網頁以用於即時監測由系統300處理的訂單的指令。此外，MDR系統320可編碼資訊的封包，產生用於客戶端裝置中的GUI顯示的指令，以及分類並儲存資訊。

MDR系統320可包含可分析系統300中的通信的MDR處理器322。另外，MDR系統320可包含儲存並管理實行分佈式記憶體內鍵值資料庫的記憶體內資料結構的MDR資料庫325。在此類實施例中，MDR系統320及MDR資料庫325可支援不同種類的抽象資料結構，諸如字串、清單、映射、集合、分類集、HyperLogLogs、位元映像、串流，以及空間索引。此外，在一些實施例中，MDR系統320可包含用於流式處理軟體的模組，軟體提供用於處置即時資料饋入(例如即時資訊探求)的通用、高通量、低延遲模組。在此類實施例中，MDR系統320可將基於TCP的協定用於資訊及訊息集的交換。

在一些實施例中，MDR系統320可藉由系統100(圖1A)的組件中的一或多者實行。舉例而言，MDR系統320可藉由SAT系統101、外部前端系統103、FO系統113、SCM系統117及/或WMS 119(圖1A)實行。在其他實施例中，MDR系統320可藉由一或多個獨立伺服器實行，所述獨立伺服器經組態以進行用於將內容提供至客戶端裝置及/或產生用於客戶端裝置350及/或用於在本端領域360中顯示的網頁的操作。結合圖6進一步論述MDR系統320以及MDR處理器322及MDR資料庫325。

除MDR系統320以外，系統300亦可包含線上資源340、客戶端裝置350、第三方領域365、本端領域360以及資料庫380。在一些實施例中，如圖3中所繪示，系統300的組件可連接至網路370。然而，在其他實施例中，系統300的組件可直接彼此連接而無需網路370。舉例而言，資料庫380可直接耦接至MDR系統320。

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

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

在一些實施例中，如下文結合圖4進一步描述，客戶端裝置350可運行特定地經組態以與MDR系統320互動的應用程式。此外，客戶端裝置350可儲存一或多個帳戶。舉例而言，客戶端裝置350可儲存關於客戶帳戶的特權的資訊以修改PDD及/或重新路由包裹。

所揭露實施例不限於客戶端裝置350的任何特定組態。舉例而言，客戶端裝置350可為儲存及執行行動應用程式以進行操作的行動裝置，所述操作提供由MDR系統320及/或線上資源340提供的功能。在某些實施例中，客戶端裝置350可經組態以執行與位置服務(諸如GPS位置)相關的軟體指令。舉例而言，客戶端裝置350可經組態以判定地理位置，以及提供位置資料及對應於所述位置資料的時戳資料。結合圖4進一步描述客戶端裝置350。

資料庫380可包含一或多個計算裝置，其經組態有適當軟體以進行與提供用於追蹤系統300中的訂單或票證的MDR系統320資料一致的操作。資料庫380可包含例如甲骨文^TM(Oracle^TM)資料庫、賽貝斯^TM(Sybase^TM)資料庫或其他關連式資料庫或非關連式資料庫，諸如海杜普^TM(Hadoop^TM)順序檔案、海貝斯^TM(HBase^TM)或卡珊德拉^TM(Cassandra^TM)。資料庫380可包含計算組件(例如，資料庫管理系統、資料庫伺服器等)，所述計算組件經組態以接收及處理對儲存於資料庫的記憶體裝置中的資料的請求及自資料庫提供資料。

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

資料庫380可經組態以收集及/或維護與使用者帳戶或產品相關聯的資料以促進可用遞送選項的判定。舉例而言，資料庫380可儲存關於系統300的使用者的使用者設定檔的資訊。另外，資料庫380可儲存關於地址的資訊，包含可用於所述地址的遞送選項。資料庫380可自各種來源收集資料，所述來源包含例如線上資源340或第三方領域365。另外，資料庫380可包含關於客戶端裝置350作業系統的資訊。下文結合圖5進一步描述資料庫380。

本端領域360可包含系統100的一或多個元件。舉例而言，本端領域360可包含SAT系統101、賣方入口109、FO系統113及/或SCM系統117。替代地或另外，本端領域360可包含至系統300中的本端網路的伺服器及/或存取點。舉例而言，本端領域360可包含訂單處理領域、購買領域、庫存領域、安全領域以及面向客戶端的領域。此等領域可包含區域網路及網路連接資源以支援客戶端訂單的履行。此外，在一些實施例中，本端領域360可包含監測引擎領域或管理員領域，所述管理員領域可允許多領域網路的管理器或管理員查詢MDR系統320關於在整個系統300中正處理的訂單或票證的狀態。舉例而言，本端領域360可包含定期請求關於具有預測或實際延遲的訂單或票證的狀態更新的監測引擎。在此類實施例中，本端領域360可包含管理器領域，諸如領域管理器。

在一些實施例中，第三方領域365可包含系統100的一或多個元件。舉例而言，第三方領域365可包含3PL系統121A至3PL系統121C(圖1)。另外或替代地，第三方領域365可包含藉由與MDR系統320有關的實體提供的一或多個伺服器或儲存服務，所述實體諸如服務的提供商或履行中心。第三方領域365亦可經由網路370連接至系統300，但在其他實施例中，第三方領域365可包含與系統300的一些元件的直接連接。舉例而言，為了最小化延遲或網路擁擠，第三方領域365可在專用網路中與MDR系統320連接。此外，第三方領域365可經組態以提供及/或請求來自MDR系統320或系統300的其他元件的資訊。在一些實施例中，雖然第三方領域365亦可耦接至網路370，但其可能不為MDR系統320的客戶端。實情為，第三方領域365可包含系統，所述系統包含MDR系統320的使用者或客戶端的資訊。舉例而言，第三方領域365可包含遞送承包者的伺服器，其可由MDR系統320在產品遞送涉及第三方承包商時使用。

網路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可指明與MDR系統320通信及/或產生訂單資訊請求的指令。此外，客戶端應用程式414可解譯用於在客戶端裝置350中產生圖形使用者介面(graphical user interface；GUI)或修改所顯示的GUI的指令。此外，客戶端應用程式414可允許使用者與MDR資料庫325互動以進行如讀取、寫入及/或收集用於訓練機器學習模型的資訊的操作。記憶體410亦可儲存可由MDR系統320使用以產生及維持具有關於訂單或產品的狀態的資訊的狀態表的資料416。

在某些實施例中，記憶體410可儲存用於存取MDR系統320或將請求發送至MDR系統320的指令。舉例而言，記憶體410可包含經由TCP/IP與MDR系統320通信的應用程式。替代地或另外，記憶體410可包含用於經由應用程式設計介面(API)方法與MDR系統320通信的資訊。舉例而言，在一些實施例中。MDR系統320可暴露REST API以用於服務，諸如(1)創建監測事件實體，(2)更新監測實體，以及(3)報告錯過的狀態事件。在此類實施例中，記憶體410可儲存發出GET、PUT、DELETE或POST指令的指令，以使用暴露的API服務請求來自MDR系統320的資訊或將資訊發送至MDR系統320。

此外，其他軟體組件可經組態以請求來自MDR系統320的資訊或判定客戶端裝置350的位置。舉例而言，程式412中的軟體指令在由處理器402執行時可處理資訊以在網頁中顯示物件的清單。軟體指令亦可實行腳本以修改在客戶端裝置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亦可包含所屬技術領域中已知的用於與MDR系統320互動的其他組件。

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

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

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

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

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

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

通信裝置502可經組態以與系統300或系統100中的一或多個組件通信，諸如線上資源340、MDR系統320或SCM系統117。通信裝置502可經組態以提供MDR系統320訂單資訊及使用者偏好或特權。

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

資料庫記憶體510可包含程式512，程式512可包含接收並處理來自本端領域360及第三方領域365的狀態訊息及/或對來自客戶端裝置350的資訊請求作出回應的指令。另外，資料庫記憶體510可包含用於系統300的元件之間的通信的指令。舉例而言，資料庫記憶體510可包含用於客戶端裝置350與MDR系統320之間的通信的指令。另外，程式512可包含在由MDR系統320處理資訊時即時儲存所述資訊的指令。在此類實施例中，且如結合圖11進一步揭露，資料庫380可儲存狀態表，其包括：ID欄位、預期的結束欄位以及狀態欄位。

資料514亦可為與訂單狀態、預期遞送以及目標PDD相關聯的資料。舉例而言，資料514可包含與系統中的先前待處理訂單、所選履行中心或庫存狀態相關的資訊。在一些實施例中，資料514亦可為狀態表及資料庫條目記錄。

圖6為與所揭露實施例一致的例示性多領域報告(MDR)系統320(圖3)的方塊圖。MDR系統320可包含通信裝置324、MDR資料庫325以及一或多個MDR處理器322。MDR資料庫325可包含MDR程式652、MDR快取資料654以及MDR狀態表656。MDR處理器322可包含自動化探索模組642、PDD計算器644、機器學習(ML)訓練器646以及報告產生器648。

通信裝置324可包含用於經由網際網路通信的網路控制器及/或無線配接器。通信裝置324可經組態以直接或經由網路170與一或多個資料庫(諸如資料庫380(圖3))通信。此外，在一些實施例中，通信裝置324可能可組態以對REST API呼叫及/或基於佇列的輸入作出回應。舉例而言，通信裝置310可暴露MDR系統320的資源以經由REST API方法自本端領域360及第三方領域365請求。

MDR資料庫325包含一或多個儲存裝置，所述一或多個儲存裝置經組態以儲存由MDR處理器322用以進行與所揭露實施例相關的功能的指令。舉例而言，MDR資料庫325可儲存可在由MDR處理器322執行時進行操作的軟體指令。所揭露實施例不限於經組態以進行專用任務的個別程式或電腦。此外，MDR資料庫325可儲存允許藉由系統300處理的訂單及/或票證的狀態的集中式監測的資料結構。舉例而言，MDR資料庫325可儲存MDR狀態表656，所述MDR狀態表656儲存詳述訂單狀態的訂單條目(亦被稱作監測實體)。MDR狀態表656可包含用於訂單條目的唯一ID(其可基於物件、供應商以及客戶資訊經編碼)及訂單或票證的狀態(其可包含「錯過PDD」、「發送至倉庫」以及其他狀態)。如結合圖11進一步描述，MDR狀態表656可包含用於訂單ID、實體類型、當前狀態、預期狀態以及一致狀態的欄位。在一些實施例中，MDR狀態表656可經組態為可經由查詢或REST API呼叫存取。

此外，MDR資料庫325可另外包含MDR快取資料654。MDR快取資料654可包含MDR狀態表656中的某些條目的複本及/或正由MDR處理器322處理的請求。MDR快取資料654亦可快取針對監測引擎產生的經處理報告的複本，且在監測引擎請求所述複本時傳輸彼複本。在此類實施例中，若報告較大或被頻繁存取，則MDR快取資料654可縮短自狀態表656擷取報告所需的時間。

在某些實施例中，MDR資料庫325，且特定言之MDR程式652，可儲存用於進行程序以產生狀態變數、計算其PDD及/ 或判定警示何時應傳輸至管理員領域的指令。其他指令亦是可能的。一般而言，指令可藉由MDR處理器322執行以進行與所揭露實施例一致的程序。

MDR處理器322可包含一或多個已知處理裝置，諸如但不限於微處理器、CPU及/或多核心處理器。在其他實施例中，MDR處理器322可為耦接且經組態以進行與本揭露內容一致的功能的多個裝置。在一些實施例中，MDR處理器322可執行軟體以進行與MDR處理器322的每一組件相關聯的功能。在其他實施例中，MDR處理器322的每一組件可為獨立裝置。

自動化探索模組642可經組態以對網路進行爬行以識別新裝置及/或領域，且進行將新裝置及/或領域耦接至網路並程式化所述裝置或領域以用於自動化操作的自動化探索操作。自動化探索模組642允許某些領域及裝置使辨識及與同一網路上的其他裝置或與MDR處理器322通信所需的步驟自動化。在一些實施例中，自動化探索模組642可經組態以自動辨識領域或裝置，識別通信方法，以及組態某些任務，諸如傳輸更新訊息。舉例而言，自動化探索模組642可使新領域與MDR系統320互動及通信以傳輸填充MDR狀態表656的通信所需的步驟自動化。在此類實施例中，自動化探索模組642可將位址指定給領域的裝置且將其廣播以向系統300的其他裝置告知其識別及特性。

此外，自動化探索模組642可程式化領域裝置程式以自動地將通信(諸如API呼叫)發佈至諸如MDR系統320的集中式報告系統。舉例而言，自動化探索模組642可使將位址指定給領域(或領域的元素)的操作自動化，指定用於網路互動的名稱，以及程式化藉由事件的頂點或起始觸發的API通信。在此類實施例中，自動化探索模組642可組態本端領域360或第三方領域365的裝置以產生API呼叫或特定訊息。

PDD計算器644可經組態以判定正處理的訂單或票證的承諾遞送日期(PDD)以填充MDR狀態表656中的條目。舉例而言，一旦自客戶端裝置350中的一者接收到訂單，則PDD計算器644可識別及指定履行中心或第三方。基於所述指定，PDD計算器644接著可估計可包含於MDR狀態表656的欄位中的PDD或預期遞送。雖然訂單履行經由不同領域中的中斷工作流程處理，但MDR處理器322可將當前時間與估計PDD(藉由PDD計算器644產生)進行比較以判定系統是否應產生警示或將某些API服務暴露於延遲的資訊管理員領域。在一些實施例中，如結合圖15進一步論述，PDD計算器644可使用一系列規則來將訂單或票證指定給特定履行中心以接著判定所估計PDD且監測訂單狀態。

在一些實施例中，PDD計算器644可為外部MDR系統320及/或可由系統100的一或多個元件實行。舉例而言，在一些實施例中，PDD計算器644可實行為FO系統113或SAR系統101(圖1)且將PDD或預期的遞送資訊傳輸至MDR系統320。

ML訓練器646可經組態以使用MDR資料庫325中的資料來產生預測訂單狀態及/或產生警示的機器學習(ML)模型。實行MDR系統320的一個優勢為能夠收集多領域網路的一致且經恰當標記的資料。雖然在標準多域網路中資料可經隔離且難以標準化，但用於集中式狀態監測的所揭露系統及方法允許收集及保管來自網路的資料。此類資料可由ML訓練器646利用以產生預測模型來管理多領域網路。舉例而言，ML訓練器646可使用MDR資料庫325中的資料來訓練ML模型，所述ML模型預測將錯過PDD或將具有延遲的訂單。在此類實施例中，ML訓練器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)模型、自然語言模型及/或另一機器學習模型。另外，模型可包含總體模型(亦即，由多個模型構成的模型)。

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

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

報告產生器648可包含用於使用來自MDR狀態表656的資料產生報告的硬體或軟體。舉例而言，回應於來自本端領域360(圖3)的某些API呼叫，報告產生器648可經組態以識別MDR狀態表656中與特定狀態相關聯的條目且產生可廣播至管理員領域的報告。舉例而言，經由通信裝置324 MDR系統320可在本端領域360中自監測引擎接收API呼叫以產生具有錯過PDD的訂單的報告。在此類情境下，報告產生器648可識別MDR狀態表656具有錯過PDD狀態的條目且產生詳述具有錯過PDD的訂單的報告。如結合圖17進一步論述，在一些實施例中，報告可為包含匹配由監測引擎請求的類別狀態的訂單或票證的電子郵件或文字訊息。

圖7為與所揭露實施例一致的包含MDR系統320的多領域網路700的方塊圖。除了MDR系統320以外，網路700亦包含訂單領域363、庫存領域362以及購買領域361。領域361至領域363中的每一者可為本端領域360(圖3)的部分且包含專用於在訂單履行過程期間進行某些任務的系統。舉例而言，訂單領域363可接收並處理來自客戶端裝置350(圖3)的訂單。庫存領域362可維持外部前端系統103(圖1A)的庫存可用性且指定履行中心。並且購買領域361可處理支付並結算與訂單相關聯的交易。此等僅為例示性本端領域360且替代或額外領域可為網路700的部分。舉例而言，網路700中的領域可包含安全領域、廣告領域及/或客戶領域。

如先前結合圖6所論述，MDR系統320可與MDR資料庫325通信且與網路700的領域通信。如圖7中所示，MDR系統320可直接與訂單領域363、庫存領域362以及購買領域361中的每一者連接，以產生在中斷工作流程期間監測訂單或票證的狀態的集中式監測系統。舉例而言，使用REST API方法及自動呼叫MDR系統320可監測網路700中的訂單或票證。在此類實施例中，訂單領域363可經組態以產生API呼叫或查詢請求以創建用於自客戶裝置接收到的新訂單的監測事件實體。在一些實施例中，此第一API呼叫或請求可包含可基於物件類型、供應商以及指定FC編碼的訂單ID。另外，庫存領域362可經組態以與MDR系統320傳達更新。舉例而言，庫存領域362可經組態以產生更新由訂單領域363產生的監測實體的訊息或請求。此第二更新請求可由正自倉庫運送的訂單觸發。此外，在運送訂單後，購買領域361可產生檢查訂單的狀態以開具發票的請求。以此方式，MDR系統320使通信集中且允許所述領域中的每一者以減少網路擁擠的簡單請求判定訂單狀態。此等實施例藉由消除跨程序傳達整個上下文以識別狀態的必要性來改良多領域管理的技術領域。實情為，網路700的所揭露組態允許以最小必要資料使單一源中的斷開工作流程會聚。

如圖7中所示，在一些實施例中，網路700亦可包含管理員領域364。管理員領域364可與相比於網路700的其他領域具有某些特權的系統相關聯。舉例而言，管理員領域364中的系統可能夠重路由、取消或更新訂單的定價。在一些實施例中，管理員領域364可包含針對MDR系統320產生查詢以產生狀態報告的監測引擎。舉例而言，管理員領域364中的監測引擎可針對MDR系統320發出API呼叫以請求關於以下訂單的狀態報告：(1)錯過PDD(2)已完成，或(3)已自倉庫運送。在一些實施例中，監測引擎可指明狀態類別作為API請求的部分。舉例而言，監測引擎可將指明應被返回的狀態的類型的屬性包含於REST API GET中。替代地或另外，管理員領域364可協調預定義工作以用於在MDR資料庫325中報告及查詢狀態表。

在某些實施例中，MDR系統320可僅可經由管理員領域364獲得，以將安全性風險降至最低且對網路700中的資訊具有較緊密控制。舉例而言，來自MDR系統320的REST API可僅暴露於來自管理員領域364的通信。

此外，如圖7中所示，在某些實施例中，本端領域360中的每一者可在子領域中細分。舉例而言，購買領域361可在購買服務子領域361-1及購買接收器子領域361-2中劃分。在此類實施例中，MDR系統320可組態以使來自子領域的訊息自動地與特定狀態相關聯。舉例而言，不管酬載而來自購買服務子領域361-1的任何訊息可與「狀態A」相關聯，而來自購買接收器子領域361-2的訊息可與「狀態B」相關聯。在此類實施例中，來自具有減少酬載的領域的訊息可仍然觸發MDR系統320中的訂單或監測實體的狀態的更新。類似地，訂單領域363可在訂單服務子領域363-1 及訂單接收器子領域363-2中劃分，所述子領域各自與用於MDR系統320的更新的不同觸發事件相關聯。另外，庫存領域362亦可在庫存服務子領域362-1及庫存接收器領域362-2中劃分，其中每一子領域與特定觸發更新相關聯。觸發更新可包含使用API呼叫經由MDR系統320將更新傳輸至MDR資料庫325。

圖8為與所揭露實施例一致的用於藉由MDR系統320(圖3)監測訂單運送的例示性過程800的流程圖。

過程800可在藉由客戶端裝置350中的一或多者在網路370上下訂單時起始。舉例而言，客戶端裝置350可在網路中下訂單以購買物件。在一些實施例中，訂單可經由系統100的元件接收。舉例而言，可自外部前端系統103(圖1)接收訂單。訂單可包含類似於運送位置及/或客戶偏好的資訊。

訂單可轉送至可接收並處理客戶訂單的本端領域360，諸如訂單領域363(圖6)。在一些實施例中，如圖8中所示，本端領域360可包含訂單發佈商802，其可為本端領域360中負責處理客戶端訂單的伺服器。舉例而言，訂單發佈商802可實行為FO系統113、SAT系統101及/或履行傳訊閘道器115中的任一者。在某些實施例中，訂單發佈商802可由SAT系統101(圖1)實行以藉由識別FC處理訂單，如結合圖15進一步論述。訂單發佈商802可與諸如庫存領域362及購買領域361的額外本端領域360通信。

如圖8中所示，在一些實施例中，訂單發佈商802可經組態以針對MDR系統320產生第一訊息或呼叫806以創建監測事件實體。在一些實施例中，第一訊息或呼叫806可包含訂單的初始狀態。舉例而言，第一訊息或呼叫806可將訂單的狀態指明為發送至倉庫。訂單發佈商802可經組態以一旦接收到訂單及/或訂單發送至倉庫便自動地發送第一訊息或呼叫806。在一些實施例中，如結合圖6所揭露，本端領域360(例如訂單領域363)可經組態以在自動化探索操作中產生訊息或呼叫806。

除發送第一訊息或呼叫806外，訂單發佈商802可將第二訊息或呼叫808傳輸至倉庫，倉庫可在本端領域360中的不同者中，諸如履行中心領域(例如，第二訊息或呼叫808可傳輸至FO系統113)。

一旦在階段814處倉庫或履行中心領域(諸如FO系統113)自倉庫進行運送，則履行中心領域可產生通知本端領域360中的一者訂單已經運送的第三訊息或呼叫810。舉例而言，履行中心(FC)領域可將第三訊息或呼叫810傳輸至可包含運送更新接收器804的運送領域。運送更新接收器804接著可將第四訊息或呼叫812傳輸至MDR系統320。第四訊息或呼叫812可指明已運送正被監測(經由第一訊息或呼叫806)的訂單。在一些實施例中，可經由更新監測實體的MDR系統320的暴露的REST API通信傳輸第四訊息或呼叫812，所述監測實體可實行為MDR狀態表656中的物件中的一者。當MDR系統320接收第一訊息或呼叫806及第四訊息或呼叫812時，MDR處理器322可在資料庫MDR資料庫325中創建條目且更新訂單狀態。

在過程800中來自不同領域的訊息或呼叫的以上組態允許MDR系統320藉由將事件會聚至集中式來源中來監測中斷工作流程。此類組態允許管理員領域364產生正由系統300處理的一個或多個訂單的即時、定期及/或按需狀態請求。此外，所揭露組態允許管理員領域364監測購買訂單及/或監測庫存。因此，過程800可包含可組態的經排程監測工作以產生請求已在MDR資料庫325中監測的訂單的狀態的訊息或呼叫。舉例而言，定期(或按需)管理員領域364可針對MDR系統320產生報告請求。舉例而言，MDR系統320可產生關於錯過的監測條目816的報告，所述監測條目816接著在管理員網路364中作為廣播電子郵件傳達。

如圖8中所示，在一些實施例中，管理員網路364可包含監測工作的可組態排程。舉例而言，管理員網路364可代管可組態以按使用者組態的週期性產生狀態請求的伺服器及/或程序。在一些實施例中，管理員網路364中的可組態的經排程監測工作可基於可在可組態的經排程監測工作中程式化的使用者偏好定期產生請求。在一些實施例中，可組態的經排程監測工作可包含自動化軟體、腳本處理及/或管線程式設計以在可組態週期或間隔(例如，每天或每小時)下查詢狀態表。舉例而言，可組態的排程監測可程式化來自MDR狀態表656(圖6)中的訂單的狀態請求。另外，可組態的經排程監測工作可自狀態表請求資料且向所要接收者產生報告。在此類實施例中，自動化軟體可組態管理網路364中的元件以基於回應於工作請求而接收到的資訊分析及產生報告。舉例而言，在MDR狀態表656具有訂單及相關的承諾遞送日期時，管理網路364可經組態以自狀態表收集資料且接著將報告發送至倉庫。替代地或另外，可組態的經排程監測工作可基於訂單的狀態、報告週期性及/或警示而程式化報告的產生及遞送。

在一些實施例中，管理員網路364可使用詹金斯(Jenkins)工作(例如，管線化為程式碼或自動化軟體)組態排程工作，除非存在中斷，否則所述詹金斯工作在每一間隔查詢狀態表。舉例而言，管理員網路364可組態每24小時、12小時、6小時或3小時等執行的詹金斯工作。在此類實施例中，詹金斯工作可進行請求來自狀態表的資料及週期性或條件的操作，以用於產生報告。

過程800描述MDR系統320監測訂單請求及運送以供稍後向管理員領域364報告的例示性使用。然而，過程800可適用於不同操作或斷開工作流程。舉例而言，過程800可適用於監測購買訂單及/或監測庫存。

圖9為與所揭露實施例一致的用於經由自動化探索操作組態與多領域網路中的多個域通信的例示性過程流程900的時序圖。

在一些實施例中，如圖9中所示，系統300(圖3)中的不同元件及不同本端領域360可進行過程流程900的特定步驟。舉例而言，MDR系統320的組件可進行過程流程900的一或多個步驟，且本端領域360(如購買領域361、庫存領域362、訂單領域363以及管理員領域364)可進行過程流程900的額外步驟。然而，在其他實施例中，系統300的替代性元件可進行所描述的步驟(例如，資料庫380可進行某些步驟)或系統300的單一元件可進行所描述的步驟。

在步驟902中，MDR系統320可廣播探索信號。舉例而言，MDR系統320可產生探索信號以識別網路中的領域及對應網路連接裝置。在一些實施例中，步驟902的探索信號可為將資料封包廣播至網路中所含有的所有IP位址的UDP廣播信號。替代地或另外，步驟902的探索信號可包含TCP探索信號。在一些實施例中，探索信號可包含產生用於多領域網路中的領域中的每一者的變數的操作。舉例而言，MDR系統320可包含諸如new IPEndPoint(IPAddress.Any,0)、Server.Receive(ref ClientEp)以及Encoding.ASCII.GetString(ClientRequestData)的操作。

在步驟904至步驟910中，本端領域360可對具有組態模板的廣播探索請求作出回應。在步驟904處，購買領域361可對具有第一組態模板的探索請求作出回應。第一組態模板與購買領域361相關聯。在步驟906處，庫存領域362可對具有第二組態模板的探索請求作出回應。第二組態模板與庫存領域362相關聯。類似地，在步驟908處，訂單領域363可對具有第三組態模板的探索請求作出回應。第三組態模板與訂單領域363相關聯。並且在步驟910處，管理員領域364可對具有第四組態模板的探索請求作出回應。第四組態模板與管理員領域364相關聯。

組態模板可提供本端領域360及/或第三方領域365中的網路連接裝置的資訊。另外，組態模板可指示本端領域360中的網路拓樸及可用資源。組態模板亦可包含用於網路內的某些裝置的程式化指令。指令可提供用以程式化領域的系統以產生領域間通信的方法。

在步驟912中，MDR系統320可將領域添加至報告服務。舉例而言，在步驟912處，MDR系統320可包含用於與本端領域360相關聯的狀態的狀態且可在步驟902中將自身暴露於來自探索領域的REST API請求。另外在步驟914處，MDR系統320可將應答廣播至所添加領域。

在步驟916及步驟918中，MDR系統320可將組態傳輸至本端領域360以程式化允許對斷開工作流程的集中式監測的自動化領域間通信。舉例而言，在步驟916中，MDR系統320可將創建請求組態傳輸至購買領域361且開放埠以用於自動化通信。類似地，在步驟918中，MDR系統320可將更新請求組態傳輸至庫存領域362且開放埠以用於訂單監測的自動化通信。之後，本端領域可用網路連接元件已經組態用於訂單監測的自動化通信的領域確認作出回應。舉例而言，在步驟920中，購買領域361可用第一領域確認作出回應，且在步驟922中，庫存領域362可用第二領域確認作出回應。經由步驟916至步驟922，MDR系統320可能夠設置自動化傳訊系統以在MDR資料庫325中創建狀態及條目，且在資料交換最少及對頻寬可用性的影響低的情況下產生多領域網路的集中式監測系統。在步驟924中，MDR系統320可產生產生具有用於第一至第二領域事件的狀態欄位的狀態表。

在一些實施例中，MDR系統320可針對額外領域進行相似組態作為過程流程900的部分。舉例而言，在步驟926中，MDR系統320可將購買請求組態傳輸至訂單領域363且開放埠以用於自動化通信。另外，在步驟928中，MDR系統320可將庫存請求組態傳輸至管理員領域364且開放埠以用於通信。訂單領域363及管理員領域364可分別在步驟930及步驟932中用領域確認對MDR系統320作出回應。

在步驟934中，MDR系統320可產生具有用於多領域網路的已探索領域與已連接領域之間的事件的組合的狀態欄位的狀態表，諸如MDR狀態表656。舉例而言，MDR系統320可產生狀態表，所述狀態表使用狀態變數及自動化通信經由中斷工作流程監測訂單的進程以提供集中式監測服務。

在一些實施例中，過程流程900可允許MDR系統320組態網路的多個領域以用於產生報告系統的自動化通信。舉例而言，過程流程900可允許MDR系統320與領域耦接且暴露REST API服務以用於經由斷開工作流程追蹤訂單。

圖10為與所揭露實施例一致的用於處理領域請求及產生警示的例示性過程流程1000的時序圖。

在一些實施例中，如圖10中所示，系統300(圖3)中的不同元件及本端領域360中的不同者可進行過程流程1000的特定步驟。舉例而言，MDR系統320的組件可進行過程流程1000的一或多個步驟，且本端領域360(如訂單領域363、庫存領域362以及管理員領域364)可進行過程流程1000的額外步驟。然而，在其他實施例中，系統300的替代性元件可進行所描述的步驟(例如，資料庫380可進行某些步驟)或系統300的單一元件可進行所描述的步驟。

在某些實施例中，過程流程1000可在過程流程900之後進行。舉例而言，MDR系統320可使用過程流程900組態多領域網路，且在過程流程900組態之後，MDR系統320可經由過程流程1000監測訂單的狀態。

在步驟1002中，訂單領域363可產生包括訂單鍵的REST API呼叫。訂單鍵可基於供應商及/或物件而編碼。舉例而言，取決於訂單的類型，訂單可路由至各種供應商以使其實現。訂單中的每一物件可基於供應商而指定唯一訂單鍵(例如，訂購：12345)。訂單內的此物件可指定至供應商JIKGU、供應商Ingram、供應商EU_JIKGU或其他供應商。因此，物件訂單的訂單鍵可為12345、12345_JIT_ING或12345_EU_JIKGU，從而編碼訂單、物件以及供應商。如圖10中所示，所產生的REST API呼叫可發送至MDR系統320。

在步驟1004中，MDR系統320可估計PDD。舉例而言，MDR系統320可識別特定供應商履行中心、倉庫及/或第三方以使位置及/或先前遞送相關以產生PDD。如結合圖15進一步描述，判定PDD可包含選擇履行中心以──基於選擇規則──估計可用於監測訂單的狀態的PDD。在一些實施例中，PDD可基於指定供應商。舉例而言，由本端領域360中的供應商處理的訂單具有2天的PDD，而由第三方領域365處理的訂單可具有7天的PDD。

在步驟1006中，MDR系統320可在狀態表中產生條目或監測實體。舉例而言，MDR系統320可回應於步驟1002的REST API呼叫在MDR狀態表656中產生條目。在一些實施例中，MDR系統320可暴露REST API服務以用於自正由訂單領域363處理的新訂單創建監測事件。

在步驟1008中，MDR系統320可自庫存領域362接收包含運送資訊的REST API呼叫。舉例而言，一旦訂單自倉庫運送至快遞員，則庫存領域362可將訊息傳輸至MDR系統320以更新與訂單相關聯的監測實體的狀態。舉例而言，MDR系統320可在自倉庫運送訂單時接收運送的更新狀態，如結合圖8所描述。在一些實施例中，在過程流程900(圖9)中交換的組態模板可允許REST API呼叫自庫存領域362至MDR系統320的自動化傳輸。在一些實施例中，步驟1008可包含呼叫暴露的REST API服務以用於自MDR系統320更新監測實體。

在一些實施例中，來自庫存領域362的REST API呼叫可觸發MDR系統320中的狀態改變。舉例而言，訂單的狀態可自「SENT TO WAREHOUSE」修改至「SHIPPED」或自「MISSED PDD」修改至「COMPLETED」。

在步驟1010中，管理員領域364可與MDR系統320通信以請求報告。舉例而言，管理員領域364中的監測引擎可產生對其中訂單具有「MISSED PDD」狀態的報告的請求。替代地或另外，管理員領域364可產生針對具有經編碼狀態的訂單的請求。舉例而言，MDR系統320可將訂單的狀態編碼為(1)起始，(2)失敗以及(3)完成。在步驟1010中，當經授權使用者請求來自MDR系統320的報告時，管理員領域364可定期(例如，在工作日結束時)或按需傳輸報告指令。

在步驟1012中，MDR系統320可進行遵守步驟1010的報告指令的監測操作。舉例而言，MDR處理器322(圖6)中的報告產生器648剖析MDR狀態表656以識別匹配步驟1010的報告指令的訂單或票證。在一些實施例中，在步驟1012處，報告產生器648可識別具有「MISSED PDD」狀態或未能在管理員領域364中為使用者準備報告的訂單。

在步驟1014中，MDR系統320可產生警示。舉例而言，MDR系統320可產生包含具有匹配報告指令的狀態的訂單的電子郵件或文字訊息。在步驟1016中，MDR系統320可將警示傳輸至管理員領域364。

過程流程1000繪示MDR系統320可如何在多領域網路中創建集中式監測系統的實例。儘管訂單領域363及庫存領域362在無標準化通信的情況下進行中斷工作流程，但MDR系統320允許多領域網路的管理器運用簡化及自動化通信監測訂單或票證的狀態。因此，MDR系統320的實施改良管理器協調多領域網路中的事件的能力。

圖11是與所揭露實施例一致的用於多領域監測的儲存於諸如MDR資料庫325的資料庫中的例示性狀態表1100。狀態表1100包含多個條目或監測實體1102(a)至1102(z)，統稱為監測實體1102。狀態表1100可使監測實體1102中的每一者與可用於訂單或票證狀態的集中式監測的多個欄位相關聯。

用於參考圖11中的個別元件的文字(例如(a)、(b)或(z))並不指明元件的數目或狀態表1100中的元件的總數目。實情為，其為指示可變元件數目及總元件的可變數目的可變參考物。舉例而言，用於參考監測實體(z)的文字(z)並不指示監測實體(z)為第26記憶體單元。實情為，(z)為可指示任何整數的可變參考物。因此，監測實體(z)為監測實體1102或條目中的任一者。

狀態表1100的欄位可包含欄位ID 1110、實體類型欄位1112、實體欄位1114以及當前狀態欄位1116。欄位ID 1110可儲存每一列的唯一主鍵。替代地或另外，欄位ID 1100可基於儲存供應商及/或物件編碼的訂單鍵，如結合圖10進一步描述。實體類型欄位1112可儲存正被監測的一種類型的實體/使用情況(例如，JIKGU_ORDER_MONITOR、INVENTORY_MONITOR、PURCHASE_MONITOR)。實體欄位1114可儲存正被監測的實際實體值(例如，實際orderID或12345_JIT_ING)。另外，當前狀態欄位1116可儲存實體監測的狀態(例如，ORDER_SENT_TO_WAREHOUSE)。另外或替代地，當前狀態欄位1116的值可選自包含下述者的群組：空值、訂單發送至倉庫的值、訂單運送值、錯過的PDD值或完成值。

狀態表1100亦可包含預期的狀態欄位1118，其可儲存實體需要達到以使其完成的預期最終狀態(例如，ORDER_SHIPPED)。在一些實施例中，預期狀態欄位1118可基於來自藉由ML訓練器646訓練的機器學習演算法的結果而進行填充。舉例而言，預期狀態欄位1118可儲存基於ML模型輸出的訂單的預測狀態。狀態表1100亦可包含預期結束時間欄位1122，其亦可充分利用ML模型以填充狀態表1100中的欄位。替代地或另外，預期結束時間欄位1122可儲存預期結束時間，在所述預期結束時間處儲存於預期狀態欄位1118中的預期狀態應為到達。

狀態表1100可另外包含在多領域網路中的不同階段處監測時間的欄位。舉例而言，狀態表1100可包含：開始時間欄位1120，其儲存當前狀態欄位1116經更新的實際開始時間；及結束時間欄位1124，其可儲存預期狀態欄位1116中儲存的狀態應為到達的實際結束時間。

狀態表1100亦可包含用於監測實體1102的經編碼狀態。舉例而言，MDR系統320可基於狀態表1100中的欄位的組合而產生用於監測實體1102中的每一者的程式碼。狀態表1100可包含狀態欄位1126，其儲存編碼與監測實體1102相關聯的訂單或票證的狀態的經編碼變數。舉例而言，狀態欄位1126可儲存整數變數，其中「1」編碼為起始訂單(1608)，「2」編碼未能滿足 PDD(1620)，且「3」編碼完成訂單(1616)。此外，在某些實施例中，狀態欄位1126可儲存來自包含下述者的群組的值：空值、訂單發送至倉庫的值、訂單運送值、錯過的PDD值或完成值。

圖12為與所揭露實施例一致的用於多領域狀態監測的例示性過程1200的流程圖。在一些實施例中，系統300的元件可進行過程1200。舉例而言，如以下步驟描述中所揭露，MDR系統320可進行過程1200。替代地或另外，本端領域360可進行過程1200或過程1200的部分。另外，在其他實施例中，系統100或系統100的部分可進行過程1200。舉例而言，SAT系統101及/或FMG 115可進行過程1200。

在步驟1202中，MDR系統320可建立與第一領域及第二領域的連接。舉例而言，MDR系統320可使用MDR處理器322或通信裝置324經由自動化探索操作建立與本端領域360及/或第三方領域365的連接。在一些實施例中，第一領域包含訂單接收領域，且第二領域是訂單運送領域。在此類實施例中，MDR系統320可藉由在步驟1202中開放運送更新接收器中的一或多個埠建立與第二領域的連接。

在步驟1204中，MDR系統320可判定領域是否已經組態用於自動化請求。舉例而言，MDR系統320可審查來自系統的確認(如結合圖9所論述)以判定探索領域是否已經組態用於藉由與訂單或票證相關聯的服務或接收事件觸發的自動化通信或API呼叫。若MDR系統320判定領域尚未經組態用於自動化請求(步驟1204：否)，則MDR系統320可在步驟1206中通知管理員網路。舉例而言，在步驟1206中，MDR系統320可將指示網路中的一或多個領域未經組態的訊息廣播至管理員網路364。

然而，若MDR系統320判定領域已經組態用於自動化請求(步驟1204：是)，則MDR系統320可繼續至步驟1208。在步驟1208中，MDR系統可暴露REST API或基於佇列的服務以用於創建訂單狀態事件，更新訂單狀態事件，及/或報告訂單狀態事件。舉例而言，當領域已經組態用於自動化請求時，MDR系統320可暴露REST API以用於創建監測實體1102中的一者，更新監測實體(例如，經由REST API呼叫)，以及接收及處置報告請求。

在步驟1210中，MDR系統320可自第一領域接收創建請求以起始與交易相關聯的監測操作。舉例而言，如結合圖10進一步論述，本端領域360中的一者可產生與自客戶端裝置350中的一者接收到的訂單相關聯的創建請求。在一些實施例中，第一請求包括包含訂單鍵的第一REST API呼叫，其中訂單鍵編碼物件ID及供應商ID。

在一些實施例中，MDR系統320可回應於在步驟1210中自第一領域接收到創建請求而在狀態表1100中自動地產生條目在此類實施例中，MDR系統320可藉由基於供應商ID、當前時間以及開始時間估計預期結束欄位的值而在狀態表1100中產生新條目。

在步驟1212中，MDR系統320可基於供應商ID、當前時間以及履行中心來估計PDD。舉例而言，MDR系統320可自與創建請求相關聯的訂單鍵識別訂單的所選履行中心及供應商且判定PDD。在一些實施例中，如結合圖15進一步論述，PDD的判定可基於履行中心選擇的規則、物件的類型及/或本端或第三方領域是否處置履行請求。

在步驟1214中，MDR系統320可在儲存於資料庫中的狀態表中產生新條目或監測實體。舉例而言，MDR系統320可在儲存於MDR資料庫325中的狀態表1100中產生監測實體1102中的一者。在一些實施例中，在步驟1214中，MDR系統320可填充狀態表1100的欄位。舉例而言，MDR系統320可採用ML模型來判定預期狀態及預期結束時間以填充狀態表1100的欄位。

在步驟1216中，MDR系統320可自第二領域接收更新請求以更新狀態表中的條目。舉例而言，如結合圖10所論述，MDR系統320可經由API呼叫自與第一領域不同的第二領域接收更新請求。第二領域可為運送領域，而第一領域可為訂單領域。第二請求可指明訂單的狀態或傳輸諸如「SHIPPED」狀態的特定訊息，如圖9中所論述。此外，在一些實施例中，第二請求可包含包括運送資訊的第二REST API呼叫。

在步驟1218中，MDR系統320可在狀態表中識別與步驟1216的更新狀態請求相關聯的一或多個條目。舉例而言，MDR系統320可使更新請求與狀態表1100中的監測實體1102中的一者相關聯。在一些實施例中，MDR系統320中的MDR處理器322可使監測實體1102的欄位ID 1110與更新請求的ID相關以識別狀態表1100中的哪一條目應被更新。

在一些實施例中，在新訂單經接收且由多領域網路的系統處理時，步驟1210至步驟1218可按週期1240重複。舉例而言，每當藉由網路的面向客戶的元件接收到新訂單或票證時，可重複步驟1210。以此方式，有可能產生藉由MDR系統320管理的自動化集中式監測系統，所述集中式監測系統允許網路管理器監測訂單的狀態而不必跨越領域傳遞全部內容資訊。使用週期120的監測訂單使得MDR系統320能夠運用最少必要資料將狀態會聚至單一源中。此類組態藉由以減少的頻寬消耗創建監測系統來改良多領域網路的技術領域。

過程1200在週期1240中的監測階段可準備狀態表，諸如狀態表1100，所述狀態表可由管理器查詢以在多領域網路中識別訂單或票證的狀態。在步驟1220中，MDR系統320可自監測引擎接收報告請求及類別狀態。舉例而言，如結合圖10所論述，管理員領域364中的監測引擎可定期產生對關於具有「MISSED PDD」的類別狀態的訂單的報告的請求。在一些實施例中，在步驟1220中接收到的類別狀態可指明應報告的監測實體1102的類別。舉例而言，網路的管理器可指明在步驟1220的請求中應報告哪些欄位。在一些實施例中，狀態請求可包含錯過PDD或空結束時間中的至少一者。另外，管理員領域364中的監測引擎可經組態以至少一日一次地及/或以可組態頻率產生報告請求。

在步驟1222中，MDR系統320可判定狀態表中的至少一個條目是否匹配步驟1220的請求狀態中的類別狀態。舉例而言，當報告請求包含『MISSED PDD』的狀態類別時，MDR系統320可判定監測實體1102中的至少一者是否具有『MISSED PDD』的當前狀態欄位。若MDR系統320判定條目中無一者匹配類別狀態(步驟1222：否)，則MDR系統320可繼續至步驟1206且藉由例如發佈廣播訊息來通知管理員網路。然而，若MDR系統320判定條目中的至少一者匹配類別狀態(步驟1222：是)，則MDR 系統320可繼續至步驟1224。

在步驟1224中，MDR系統320可產生將其中狀態欄位匹配類別狀態的條目包括於狀態表中的警示。舉例而言，MDR處理器322可採用報告產生器648來產生包含具有與類別狀態匹配的欄位的監測實體1102的報告。如結合圖17進一步論述，警示可作為自動化電子郵件或文字訊息而廣播，其可部署至管理員領域364。在一些實施例中，在步驟1224中產生警示可包含將電子郵件訊息廣播至管理員網路。

圖13為與所揭露實施例一致的用於經由自動探索連接建立多領域通信的例示性過程1300的流程圖。

在一些實施例中，系統300的元件可進行過程1300。舉例而言，如以下步驟描述中所揭露，MDR系統320可進行過程1300。替代地或另外，資料庫380、本端領域360或第三方領域365可進行過程1300或過程1300的部分。另外，在其他實施例中，系統100或系統100的部分可進行過程1300。舉例而言，外部前端系統103及/或FMG 115可進行過程1300。

在步驟中1302，MDR系統320可起始與網路領域的自動化探索連接。舉例而言，MDR系統320可起始自動化探索模組642以建立允許訂單或票證狀態的集中式監測的自動化領域間通信。在步驟1304中，MDR系統320可自動地探索與已探索領域相關聯的組態模板。如結合圖9所論述，MDR系統320可廣播探索且自多領域網路中的領域接收組態模板。

在步驟1306中，MDR系統320可將領域添加至監測服務。舉例而言，MDR系統320可將欄位添加至狀態表1100(圖 11)以反映編號及已探索領域之間的關係。另外，在步驟1306中，MDR系統320可產生查詢與已探索領域相關聯的狀態的方法。在步驟1308中，MDR系統320可開放領域的通信埠以用於基於訂單事件的自動化訊息及用於領域組態。舉例而言，在一些實施例中，MDR系統320可開放本端領域360的TCP埠或UDP埠以用於報告串流饋送，所述串流饋送實現多領域系統中的訂單或票證狀態的即時監測。

在步驟1310中，MDR系統320可經由一或多個網路API組態第一領域以在接收訂單或將訂單發送至履行中心時產生創建請求。舉例而言，MDR系統320可組態訂單領域363以在每當自客戶端裝置350接收到新訂單時發送創建請求。在步驟1312中，MDR系統320可經由一或多個網路API組態第二領域以在運送物件時產生更新請求。舉例而言，MDR系統320可組態庫存領域362以在每當自倉庫運送訂單時發送更新請求。替代地或另外，步驟1310至步驟1312可包含經由與第一領域相關聯的一或多個網路API組態第一領域在接收到新訂單或將訂單發送至履行中心時產生創建請求，及經由與第二領域相關聯的一或多個網路API組態第二領域以在運送物件時產生更新請求。

在步驟1314中，MDR系統320可判定是否已在網路中探索額外領域。若MDR系統320判定已在網路中探索額外領域(步驟1314：是)，則MDR系統320可繼續至步驟1316且建立與額外領域的連接。舉例而言，在步驟1316中，MDR系統320可建立與管理員領域364或第三方領域365的連接。替代地或另外，在步驟1316中，MDR系統320可藉由進行自動化探索操作(如結合圖9所描述的操作)建立與第三領域及第四領域的連接，其中第三領域為庫存領域且第四領域為第三方領域。

然而，若MDR系統320判定尚未在網路中探索額外領域(步驟1314：否)，則MDR系統320可繼續至步驟1318且產生監測表及狀態變數。舉例而言，在步驟1318中，MDR系統320可選擇MDR狀態表656中的欄位中的哪一者及數目。另外，MDR系統320可編碼MDR狀態表656的欄位中的可能變數及變數的序列。舉例而言，MDR系統320可判定哪些變數將編碼狀態欄位1126或可預期的當前狀態1116的序列，所述序列可包含「ORDER_SENT_TO_WAREHOUSE」、「ORDER_SHIPPED」、「ORDERS_MISSED_PDD」以及「COMPLETED_ORDER」的序列。

在步驟1320中，MDR系統320可基於監測引擎請求而起始監測操作。舉例而言，如結合圖10及圖12所論述，管理員領域364中的監測引擎可將報告指令發送至MDR系統320。作為回應，MDR系統320可藉由剖析狀態表1100中的監測實體1102而進行監測操作，且準備關於匹配報告指令的訂單或票證的報告。在一些實施例中，監測操作可包含基於將預期結束欄位與當前時間進行比較而將錯過的PDD值指定至狀態表中的條目，且識別狀態表中狀態欄位的值為空值或錯過的PDD值中的至少一者的條目。另外或替代地，所揭露系統的某些實施例可具有經由自動化伺服器進行的監測操作。自動化伺服器可實現網路連接物件的程式化操縱或暴露網路連接物件，因此可操縱所述物件。舉例而言，自動化伺服器可執行將可程式化物件(被稱作自動化物件)暴露於其他應用程式(被稱作自動化客戶端)的應用程式。在一些實施例中，暴露自動化物件可使得客戶端能夠藉由直接存取物件及伺服器提供的功能性來使某些程序自動化。當應用程式提供適用於其他應用程式的功能性時，以此方式暴露物件可為有益的。此外，自動化物件可具有作為其外部介面的特性及方法。特性被命名為自動化物件的屬性。

圖14為與所揭露實施例一致的用於管理多領域狀態表中的條目的例示性過程1400的流程圖。舉例而言，過程1400可用於填充MDR狀態表656。

在一些實施例中，系統300的元件可進行過程1400。舉例而言，如以下步驟描述中所揭露，MDR系統320可進行過程1400。替代地或另外，本端領域360的元件或資料庫380可進行過程1400，過程1400的部分。另外，在其他實施例中，系統100或系統100的部分可進行過程1400。

在步驟1402中，MDR系統320可基於供應商、履行中心以及客戶產生用於訂單的唯一ID。舉例而言，MDR系統320可基於供應商、物件及客戶來編碼訂單鍵，如結合圖10進一步論述。

在步驟1404中，MDR系統320可判定用於監測使用情況的實體類型。舉例而言，MDR系統320可判定訂單或票證是否與將產品運送至客戶相關聯，或其是否為用於自第三方供應產品的實體類型。

在步驟1406中，MDR系統320可判定實際實體識別符或鍵。舉例而言，MDR系統320可判定用於狀態表的訂單ID，其允許MDR系統320使更新請求與訂單相關聯。

在步驟1408中，MDR系統320可判定訂單的當前狀態及預期狀態。舉例而言，MDR系統320可判定實體開始的初始狀態(例如，ORDER_SENT_TO_WAREHOUSE)及在接收後續更新時的預期狀態(例如，ORDER_SHIPPED)。

在步驟1410中，MDR系統320可填充開始時間及預期結束時間，所述時間可基於所估計PDD。在步驟1412中，MDR系統320可產生指示訂單已經起始、完成或失敗的事件的狀態。在一些實施例中，事件的狀態可經編碼以最小化通信交換的酬載或在監測操作期間促進檢索或濾波演算法。在步驟1414中，MDR系統320可初始化計時器以起始訂單狀態的集中式報告。

在步驟1416中，MDR系統320可在請求藉由MDR系統320追蹤的訂單或票證的狀態時將REST API或基於佇列的輸入暴露於服務領域。步驟1416可包含識別將由API模組暴露的MDR系統320的資源，識別將與所暴露資源介接的實體，以及判定與API的互動以產生必要使用情況。

步驟1416亦可包含識別將經由REST API暴露的資源的各別位置，且指定URI及可存取其暴露的資源的各別方法。在一些實施例中，URI本質上為路徑，且可與情境內容相關。此外，暴露的REST API輸入，MDR系統320可使特定HTTP方法與此等路徑中的每一者相關聯，其中每一方法具有特定含義。HTTP方法可包含：GET、POST、PUT及/或DELETE。

在一些實施例中，步驟1416的暴露REST API或基於佇列的輸入可包含基於JavaScript實行客戶端側前端技術以創建及剖析呈此JSON格式的資料。舉例而言，MDR系統320可實行諸如JsonViewer、JsonCreator、JsonUpdater以及JsonAdapter的介面。另外或替代地，MDR系統320可經組態以識別所暴露資源中的端點且產生對彼等端點的調用的JSON回應。MDR系統320(諸如MDR資料庫325)的此等組態及暴露允許本端領域360及第三方領域365產生填充用於集中式監測的狀態表的訊息且亦允許領域查詢MDR系統320的資源。

圖15為與所揭露實施例一致的用於指定履行中心及判定承諾遞送日期(PDD)的例示性過程的流程圖。在一些實施例中，系統300的元件可進行過程1500。舉例而言，如以下步驟描述中所揭露，MDR系統320可進行過程1500。替代地或另外，本端領域360及/或第三方領域365可進行過程1500或過程1500的部分。另外，在其他實施例中，系統100或系統100的部分可進行過程1500。舉例而言，SAT系統101、FC Auth 123及/或FMG 115(圖1A)可進行過程1500。

在步驟1502中，MDR系統320可接收對於遞送估計資訊及/或PDD的請求。請求可包含產品、時間以及郵遞碼資訊。基於請求中的資訊，MDR系統320可在步驟1504中識別相關地理區域。舉例而言，MDR系統320可基於客戶的郵遞碼來識別可履行產品的潛在訂單的區域。

在步驟1506中，MDR系統320可識別可完成產品的潛在訂單的履行中心。在一些實施例中，在步驟1504中識別出的區域可包含多個履行中心。在此類實施例中，MDR系統320可基於滿足PDD或所請求產品的可用性的能力而過濾履行中心。在一些實施例中，識別哪些履行中心可完成潛在訂單可基於產品的類型及/或與產品相關聯的訂單。在步驟1506中，MDR系統320可判定產品識別是與特定產品類型還是特定遞送時間產品相關聯，且基於特定產品類型或關於目的地地址的履行中心位置的可用性而識別履行中心。舉例而言，當產品識別與特定產品類型相關聯時，MDR系統320可進行以下操作：識別服務與遠端裝置相關聯的區域的履行中心，自履行中心請求可用的特定產品類型庫存，以及選擇履行中心中的一者。替代地或另外，在步驟1506中，當產品識別包括特定遞送時間產品時，MDR系統320可進行以下操作：識別最接近遠端裝置的履行中心，基於區域及遠端裝置與最接近履行中心之間的距離判定截止，以及當截止尚未過去時選擇最接近履行中心。

在步驟1508中，MDR系統320可執行用於履行中心的訂單分配優先級規則。在一些實施例中，分配優先級規則可儲存於MDR系統320內的記憶體裝置中，所述記憶體裝置可在步驟1504中擷取特定針對所識別區域的分配規則。替代地或另外，分配優先級規則可儲存於資料庫380中，且MDR系統320可在已在步驟1506中識別出履行中心後查詢資料庫。在又其他實施例中，分配規則可儲存於系統100的元件中。舉例而言，分配規則可儲存於FO系統113中。

訂單分配規則可為區域中的每一履行中心產生優先級分數。優先級分配規則可包含具有不同偏好的若干規則。舉例而言，訂單分配規則可包含用於遞送運輸工具的規則，所述規則具有針對員工運輸工具的偏好，諸如員工遞送工作者而非合同遞送人員。亦即，區域中的對於員工具有運輸工具的履行中心優於不具有員工運輸工具且將需要與第三方運輸工具聯繫的履行中心。另外，訂單分配規則可包含所估計遞送。基於歷史趨勢及產品與每一履行中心的關聯，分配規則可估計試驗性遞送且給出對具有較短遞送日期的履行中心的偏好。規則亦可包含員工指定規則，其給出對於其中員工具有高員工可用性或能力的履行中心的偏好。此外，規則亦可包含考慮包裹至履行中心的入站日期。藉由此規則，系統可給出對將首先接收小件包裹以增加遞送確定性的履行中心的偏好。最後，規則亦可包含基於包裹重量的偏好。一些履行中心可更佳地裝備以處置沉重或較大包裹且可能偏好較重包裹。

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

在步驟1514中，MDR系統320可判定前面的履行中心是否具有類似優先級。舉例而言，MDR系統320可判定履行中心的優先級分數是否在臨限值內。若前面的履行中心不具有類似優先級(步驟1514：否)，則MDR系統320可繼續至步驟1516且識別具有最高優先級的履行中心。然而，若前面的履行中心具有類似優先級(步驟1514：是)，則MDR系統320可繼續至步驟1518並應用隨機產生器函數以選擇最前面的履行中心。隨機產生器函數可在不需要許多計算的情況下促進負載在整個履行中心中的均勻分佈。

在步驟1520中，MDR系統320可進行盒整合(box consolidation)分配估計。藉由選定履行中心，MDR系統320可判定自履行中心運送的成本，包含將用於運送的盒的數目。為了最小化成本且改良效率，在步驟1520中，MDR系統320可執行盒整合以試圖減少用於在步驟1502中接收的產品的試驗性訂單的盒或包裹的數目。

在步驟1522中，MDR系統320可判定包裹或盒的數目在盒整合的情況下是否減少。若包裹的數目未減少(步驟1522：否)，則MDR系統320可繼續至步驟1524且維持先前分配。然而，若包裹的數目在盒整合之後減少(步驟1522：是)，則MDR系統320可繼續至步驟1526且將分配更新至整合分配。

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

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

在步驟1534中，MDR系統320可將選定履行中心及對應估計時間傳輸至步驟1502的請求者及/或資料庫(諸如MDR資料庫325)以填充狀態表。在一些實施例中，對於選定履行中心，可預先產生PDD或估計遞送時間。舉例而言，可基於與履行中心相關聯的遞送日期估計、訂單優先級、產品的入站日期、用於遞送的郵遞碼或與產品相關聯的數量而預先選擇PDD。

圖16為與所揭露實施例一致的描述用於多領域網路中的訂單的例示性狀態判定過程1600的狀態機圖。在一些實施例中，系統300的元件可進行過程1600。舉例而言，如以下步驟描述中所揭露，MDR系統320可進行過程1600。替代地或另外，本端領域360及/或第三方領域365可進行過程1600或過程1600的部分。另外，在其他實施例中，系統100或系統100的部分可進行過程1600。舉例而言，SAT系統101、FC Auth 123及/或FMG 115(圖1A)可進行過程1600。

圖16繪示正由MDR系統320監測的訂單的潛在狀態。一旦在狀態1602中接收到訂單，則MDR系統320可將訂單路由至產生用於訂單的ID的供應商(例如，在第三方領域365中)。在一些實施例中，第三方領域365中的供應商可在狀態1604中針對變成order_numberkey創建訂單鍵及新狀態。藉由訂單鍵，可在狀態1606中產生狀態變數並指定Order_Sent_To_Warehouse的狀態。同時，MDR系統320、指定供應商或指定履行中心可請求在狀態1610中添加至訂單狀態的PDD。

如圖16中所示，一旦針對訂單判定PDD(例如，根據過程1500)，則訂單狀態可遵循兩個不同路徑。若訂單被運送且接收到更新請求，則訂單狀態可更新至shipped_event狀態1612，且訂單的狀態可被修改為order_shipped狀態1614。但當未接收到更新請求時，結束時間欄位為空或系統判定錯過PDD(例如，當前時間較大於預期結束時間)，訂單狀態可修改為order_missed狀態1618。

圖17為與所揭露實施例一致的繪示經由管理員網路傳輸的警示的圖形使用者介面(GUI)1700。GUI 1700可由MDR系統320代管且顯示於客戶端裝置350(圖3)中。GUI 1700繪示標頭1702，其可對應於由監測引擎指示的狀態類別。GUI 1700亦可包含報告元素1704(a)至報告元素1704(z)的表。所述表使報告元素1704中的每一者與訂單編號1710、當前狀態1712、開始日期1714、預期結束日期1716以及結束時間1718相關聯。在一些實施例中，圖17中的表可允許使用者過濾、分類或檢索特定物件。GUI 1700亦可包含動作按鈕1720，其可允許使用者回復或轉發在GUI 1700中顯示的警示。

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

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

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

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

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

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

113:履行中心