TWI752896B - 用於提供多個補貨通知的電腦實施的系統以及方法 - Google Patents

Abstract

一種用於提供補貨通知的系統及方法，包括：接收與第一產品相關聯的補貨通知的第一請求；修改資料庫以將第一狀態分派至第一產品；接收對與第二產品相關聯的補貨通知的第二請求；修改資料庫以將第一狀態分派至第二產品；接收指示第一及第二產品可供購買的訊息；修改資料庫以將第二狀態分派至第一及第二產品；判斷第一請求是否與第二請求相關，其中當第一與第二請求相關時，第一及第二請求與與使用者相關聯的相同辨識符相關聯；確定通知排程；當第一與第二請求相關時，響應於第一及第二請求，基於所確定的通知排程向使用者發送一個補貨通知。

Description

用於提供多個補貨通知的電腦實施的系統以及方法

本揭露大體而言是有關於用於提供電子補貨通知的電腦化系統及方法。具體而言，本揭露的實施例是有關於與使用批次架構來基於通知排程發送補貨通知並避免發送重複通知相關的創新性且非常規的系統。

存在用於當網站上所列缺貨物品被補貨而變得可供購買時以電子方式通知使用者的各種類型的電腦實施的系統及方法。舉例而言，諸多零售網站及應用提供通知服務，藉由通知服務，使用者可訂閱當缺貨物品變得可用時藉由電子郵件、正文訊息及/或推送通知來得到通知。儘管該些通知是幫助的，然而尚不存在一種高效的方法來提供補貨通知，即在使用者活動的時間週期期間發送通知並避免發送重複通知。

現今，諸多零售商為使用者提供各種購買物品的平台，包括但不限於行動應用、網路瀏覽器及行動網路瀏覽器。舉例而言，使用者可在與特定零售商相關聯的行動應用上瀏覽物品，並訂閱當缺貨物品變得可用時藉由電子郵件來得到通知。使用者亦可在與特定零售商相關聯的網路瀏覽器上瀏覽物品，並當缺貨物品變得可用時再次訂閱藉由電子郵件來得到通知。然後，當缺貨物品變得可用時，由於使用者在行動應用及網路瀏覽器上訂閱過電子郵件通知，因此使用者將接收到重複的補貨通知。

另外，儘管存在諸多用於向使用者提供補貨通知的電腦實施的系統及方法，然而常規的系統及方法通常一旦確定缺貨物品可供購買便發送補貨通知。因此，若缺貨物品在上午3點變得可用，常規的系統及方法將在上午3點向使用者發送補貨通知，而此時使用者最有可能正在睡覺。因此，使用者更有可能錯過補貨通知並放棄物品，此可能會減少零售商在其物品上賺取的收入額。

因此，需要用於提供補貨通知的改進的系統及方法。具體而言，需要基於為每一使用者定製的通知排程來提供補貨通知的改進的系統及方法。另外，需要即使使用者多次訂閱對特定產品的補貨通知，亦會避免向使用者發送重複通知的用於提供補貨通知的改進的系統及方法。

本揭露的一個態樣是有關於一種用於提供多個補貨通知的電腦實施的方法。所述方法包括：接收對與第一產品相關聯的補貨通知的第一請求；修改資料庫以將第一狀態分派至所述第一產品；接收對與第二產品相關聯的補貨通知的第二請求；修改所述資料庫以將所述第一狀態分派至所述第二產品；接收指示所述第一產品以及所述第二產品可供購買的訊息；修改所述資料庫以將第二狀態分派至所述第一產品以及所述第二產品；判斷所述第一請求是否與所述第二請求相關，其中當所述第一請求與所述第二請求相關時，所述第一請求以及所述第二請求與與使用者相關聯的相同辨識符相關聯；確定通知排程；以及當所述第一請求與所述第二請求相關時，響應於所述第一請求以及第二請求，基於所確定的所述通知排程向所述使用者發送一個補貨通知。

本揭露的另一態樣是有關於一種用於提供多個補貨通知的電腦實施的系統。所述系統包括：記憶體，儲存指令；以及至少一個處理器，被配置以執行所述指令以執行上述的方法。

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

以下詳細說明參照附圖。在圖式及以下說明中盡可能使用相同的參考編號來指代相同或相似的部件。儘管本文中闡述了若干例示性實施例，然而可具有各種修改、改編及其他實施方式。舉例而言，可對圖中示出的組件及步驟進行替換、添加或修改，且可藉由對所揭露方法的步驟進行替換、重新排序、移除或添加來修改本文中闡述的例示性方法。因此，以下詳細說明並非僅限於所揭露實施例及實例。相反，本發明的正確範圍由隨附的專利申請範圍來界定。

本揭露的實施例是有關於被配置用於使用批次架構提供電子補貨通知的系統及方法。

參照圖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、倉庫管理系統（warehouse management system，WMS）119、行動裝置119A、119B及119C（被繪示為位於履行中心（FC）200內部）、第三方履行（3 ^rdparty fulfillment，3PL）系統121A、121B及121C、履行中心授權系統（fulfillment center authorization system，FC Auth）123及勞資管理系統（labor management system，LMS）125。

在一些實施例中，SAT系統101可實施為監控訂單狀態及遞送狀態的電腦系統。舉例而言，SAT系統101可判斷訂單是否超過其承諾遞送日期（Promised Delivery Date，PDD），且可採取包括發起新訂單、重新運送未遞送訂單中的物品、取消未遞送訂單、發起與訂購顧客的聯繫等在內的適當行動。SAT系統101亦可監控包括輸出（例如在特定時間週期期間運送的包裝的數目）及輸入（例如被接收用於運送的空紙盒的數目）在內的其他資料。SAT系統101亦可充當系統100中不同裝置之間的閘道，使得能夠在例如外部前端系統103及FO系統113等裝置之間達成通訊（例如，使用儲存及轉送（store-and-forward）或其他技術）。

在一些實施例中，外部前端系統103可被實施為使得外部使用者能夠與系統100中的一或多個系統交互的電腦系統。舉例而言，在系統100能夠呈現系統以使使用者能夠對物品下訂單的實施例中，外部前端系統103可被實施為接收搜尋請求、呈現物品頁面及懇求支付資訊的網路伺服器。舉例而言，外部前端系統103可被實施為運行例如阿帕奇超文件傳送協定（Hypertext Transfer Protocol，HTTP）伺服器、微軟網際網路資訊服務（Internet Information Services，IIS）、引擎X（NGINX）等軟體的一或多個電腦。在其他實施例中，外部前端系統103可運行定製網路伺服器軟體，定製網路伺服器軟體被設計成接收及處理來自外部裝置（例如，行動裝置102A或電腦102B）的請求，基於該些請求自資料庫及其他資料儲存器獲取資訊，且基於所獲取的資訊提供對所接收請求的響應。

在一些實施例中，外部前端系統103可包括網路快取系統、資料庫、搜尋系統或支付系統中的一或多者。在一個態樣中，外部前端系統103可包括該些系統中的一或多者，而在另一態樣中，外部前端系統103可包括連接至該些系統中的一或多者的介面（例如，伺服器至伺服器、資料庫至資料庫或其他網路連接）。

由圖1B、圖1C、圖1D及圖1E所示的一組例示性步驟將有助於闡述外部前端系統103的一些操作。外部前端系統103可自系統100中的系統或裝置接收資訊，以供呈現及/或顯示。舉例而言，外部前端系統103可代管（host）或提供一或多個網頁，包括搜尋結果頁面（SRP）（例如，圖1B）、單一細節頁面（Single Detail Page，SDP）（例如，圖1C）、購物車頁面（例如，圖1D）或訂單頁面（例如，圖1E）。使用者裝置（例如，使用行動裝置102A或電腦102B）可導航至外部前端系統103，且藉由在搜尋框中輸入資訊來請求搜尋。外部前端系統103可自系統100中的一或多個系統請求資訊。舉例而言，外部前端系統103可自FO系統113請求滿足搜尋請求的資訊。外部前端系統103亦可請求及接收（自FO系統113）搜尋結果中所包括的每種產品的承諾遞送日期或「PDD」。在一些實施例中，PDD可表示對以下的估計：容納產品的包裝將何時到達使用者所期望的位置，或者若在特定時間週期（例如在一天結束（午後11:59）之前）內訂購則產品被承諾遞送至使用者所期望的位置的日期。（下文參照FO系統113進一步論述PDD。）

外部前端系統103可基於所述資訊準備SRP（例如，圖1B）。SRP可包括滿足搜尋請求的資訊。舉例而言，此可包括滿足搜尋請求的產品的圖片。SRP亦可包括每種產品的相應價格，或者與每種產品的增強遞送選項、PDD、重量、尺寸、優惠、折扣等相關的資訊。外部前端系統103可向發出請求的使用者裝置發送SRP（例如，經由網路）。

使用者裝置然後可例如藉由點擊或輕敲使用者介面（或使用另一輸入裝置）以選擇在SRP上表現的產品而自SRP選擇產品。使用者裝置可製定對所選擇產品的資訊的請求，且將其發送至外部前端系統103。作為響應，外部前端系統103可請求與所選擇產品相關的資訊。舉例而言，所述資訊亦可包括除在相應的SRP上針對產品呈現的資訊之外的額外資訊。此額外資訊可包括例如儲架壽命（shelf life）、原產國、重量、尺寸、包裝中物品的數目、操作說明（handling instructions）或關於產品的其他資訊。所述資訊亦可包括對相似產品的推薦（例如，基於購買此產品及至少一種其他產品的顧客的巨量資料及/或機器學習分析）、對常問問題的回答、來自顧客的評論、製造商資訊、圖片等。

外部前端系統103可基於所接收的產品資訊來準備單一細節頁面（SDP）（例如，圖1C）。SDP亦可包括例如「立即購買（Buy Now）」按鈕、「添加至購物車（Add to Cart）」按鈕、數量欄、物品圖片等其他交互式元素。SDP可更包括提供所述產品的賣方的列表。所述列表可基於每一賣方提供的價格來排序，使得提出以最低價格售賣產品的賣方可被列於頂部。所述列表亦可基於賣方排名來排序，使得排名最高的賣方可被列於頂部。賣方排名可基於包括例如賣方滿足所承諾PDD的過往追蹤記錄在內的多種因素來製定。外部前端系統103可將SDP遞送至發出請求的使用者裝置（例如，經由網路）。

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

外部前端系統103可產生購物車頁面（例如，圖1D）。在一些實施例中，購物車頁面列出已被使用者添加至虛擬「購物車」的產品。使用者裝置可藉由點擊SRP、SDP或其他頁面上的圖標或以其他方式與SRP、SDP或其他頁面上的圖標交互來請求購物車頁面。在一些實施例中，購物車頁面可列出已被使用者添加至購物車的所有產品，以及關於購物車中的產品的資訊，例如每種產品的數量、每種產品的單價、每種產品的基於相關數量的價格、關於PDD的資訊、遞送方法、運送成本、用於修改購物車中的產品的使用者介面元素（例如，數量的刪除或修改）、用於訂購其他產品或設置產品的定期遞送的選項、用於設置利息支付的選項、用於繼續購買的使用者介面元素等。使用者裝置處的使用者可點擊使用者介面元素（例如，讀為「立即購買」的按鈕）或以其他方式與使用者介面元素（例如，讀為「立即購買」的按鈕）交互，以發起對購物車中的產品的購買。在這樣做時，使用者裝置可向外部前端系統103傳輸此種發起購買的請求。

外部前端系統103可因應於接收到發起購買的請求而產生訂單頁面（例如，圖1E）。在一些實施例中，訂單頁面重新列出來自購物車的物品，且請求輸入支付及運送資訊。舉例而言，訂單頁面可包括請求關於購物車中物品的購買者的資訊（例如，姓名、位址、電子郵件位址、電話號碼）、關於接收者的資訊（例如，姓名、位址、電話號碼、遞送資訊）、運送資訊（例如，遞送及/或收取的速度/方法）、支付資訊（例如，信用卡、銀行轉帳、支票、賒帳（stored credit））、請求現金收據（例如，出於稅務目的）的使用者介面元素等的部分。外部前端系統103可向使用者裝置發送訂單頁面。

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

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

在一些實施例中，內部前端系統105可被實施為使得內部使用者（例如，擁有、營運或租賃系統100的組織的員工）能夠與系統100中的一或多個系統交互的電腦系統。舉例而言，在網路101能夠呈現系統以使使用者能夠對物品下訂單的實施例中，內部前端系統105可被實施為網路伺服器，網路伺服器使得內部使用者能夠查看關於訂單的診斷及統計資訊、修改物品資訊或者查核與訂單相關的統計量。舉例而言，內部前端系統105可被實施為運行例如阿帕奇HTTP伺服器、微軟網際網路資訊服務（IIS）、NGINX等軟體的一或多個電腦。在其他實施例中，內部前端系統105可運行定製網路伺服器軟體，定製網路伺服器軟體被設計成接收及處理來自繪示於系統100中的系統或裝置（以及未繪示的其他裝置）的請求，基於該些請求自資料庫及其他資料儲存器獲取資訊，且基於所獲取的資訊提供對所接收請求的響應。

在一些實施例中，內部前端系統105可包括網路快取系統、資料庫、搜尋系統、支付系統、分析系統、訂單監控系統等中的一或多者。在一個態樣中，內部前端系統105可包括該些系統中的一或多者，而在另一態樣中，內部前端系統105可包括連接至該些系統中的一或多者的介面（例如，伺服器至伺服器、資料庫至資料庫或其他網路連接）。

在一些實施例中，運輸系統107可被實施為電腦系統，所述電腦系統使得能夠在系統100中的系統或裝置與行動裝置107A-107C之間達成通訊。在一些實施例中，運輸系統107可自一或多個行動裝置107A-107C（例如，行動電話、智慧型電話、個人數位助理（personal digital assistant，PDA）等）接收資訊。舉例而言，在一些實施例中，行動裝置107A-107C可包括由遞送工人操作的裝置。遞送工人（其可為永久的、臨時的或輪班的員工）可利用行動裝置107A-107C來達成對容納由使用者訂購的產品的包裝的遞送。舉例而言，為遞送包裝，遞送工人可在行動裝置上接收指示遞送哪一包裝以及在何處遞送的通知。在到達遞送位置時，遞送工人可使用行動裝置來定位包裝（例如，在卡車的後部或包裝的板條箱中）、掃描或以其他方式捕獲與包裝上的辨識符（例如，條形碼、影像、正文字串（text string）、射頻辨識（radio frequency identification，RFID）標籤等）相關聯的資料以及遞送包裝（例如，藉由將包裝留在前門、將其留給保全警衛、將其交給接收者等）。在一些實施例中，遞送工人可使用行動裝置捕獲包裝的照片及/或可使用行動裝置獲得簽名。行動裝置可向運輸系統107發送包括關於遞送的資訊在內的資訊，所述關於遞送的資訊包括例如時間、日期、全球定位系統（Global Positioning System，GPS）位置、照片、與遞送工人相關聯的辨識符、與行動裝置相關聯的辨識符等。運輸系統107可將此資訊儲存於資料庫（未畫出）中，以供系統100中的其他系統存取。在一些實施例中，運輸系統107可使用此資訊來準備追蹤資料並將追蹤資料發送至指示特定包裝位置的其他系統。

在一些實施例中，某些使用者可使用一種種類的行動裝置（例如，永久工人可使用具有例如條形碼掃描器、觸控筆（stylus）及其他裝置等定製硬體的專用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亦可自倉庫管理系統（WMS）119請求資訊，以確定各別產品在履行中心（例如，履行中心200）內部的位置。運送及訂單追蹤系統111可自運輸系統107或WMS 119中的一或多者請求資料，對其進行處理，且根據請求將其呈現至裝置（例如，使用者裝置102A及102B）。

在一些實施例中，履行最佳化（FO）系統113可被實施為電腦系統，所述電腦系統儲存來自其他系統（例如，外部前端系統103及/或運送及訂單追蹤系統111）的顧客訂單的資訊。FO系統113亦可儲存闡述特定物品被保存或儲存於何處的資訊。舉例而言，某些物品可能僅儲存於一個履行中心中，而某些其他物品可能儲存於多個履行中心中。在又一些其他實施例中，某些履行中心可被設計成僅儲存特定的一組物品（例如，新鮮農產品或冷凍產品）。FO系統113儲存此種資訊以及相關資訊（例如，數量、尺寸、接收日期、過期日期等）。

FO系統113亦可為每種產品計算對應的承諾遞送日期（PDD）。在一些實施例中，PDD可基於一或多種因素。舉例而言，FO系統113可基於產品的過往需求（例如，在一段時間週期期間此產品被訂購過多少次）、產品的預期需求（例如，預測在即將到來的一段時間週期期間有多少顧客會訂購所述產品）、指示在一段時間週期期間訂購過多少產品的全網路過往需求、指示在即將到來的時間週期期間預期會訂購多少產品的全網路預期需求、儲存於每一履行中心200中的產品的一或多個計數、每種產品由哪一履行中心儲存、此產品的預期或當前訂單等來為產品計算PDD。

在一些實施例中，FO系統113可週期性地（例如，每小時）確定每種產品的PDD，且將其儲存於資料庫中，以供擷取或發送至其他系統（例如，外部前端系統103、SAT系統101、運送及訂單追蹤系統111）。在其他實施例中，FO系統113可自一或多個系統（例如，外部前端系統103、SAT系統101、運送及訂單追蹤系統111）接收電子請求，且按需計算PDD。

在一些實施例中，履行訊息傳遞閘道（FMG）115可被實施為電腦系統，所述電腦系統自系統100中的一或多個系統（例如FO系統113）接收呈一種格式或協定的請求或響應，將其轉換成另一種格式或協定，且以所轉換的格式或協定將其轉送至例如WMS 119或第三方履行系統121A、121B或121C等其他系統，反之亦然。

在一些實施例中，供應鏈管理（SCM）系統117可實施為實行預測功能的電腦系統。舉例而言，SCM系統117可基於，例如基於產品的過往需求、產品的預期需求、全網路過往需求、全網路預期需求、儲存於每一履行中心200中的產品計數、每種產品的預期或當前訂單等來預測特定產品的需求水準。因應於此種所預測水準及所有履行中心的每種產品的數量，SCM系統117可產生一或多個購買訂單，以購買及貯存足夠的數量來滿足特定產品的預測需求。

在一些實施例中，倉庫管理系統（WMS）119可實施為監控工作流的電腦系統。舉例而言，WMS 119可自指示離散事件的各別裝置（例如，裝置107A-107C或119A-119C）接收事件資料。舉例而言，WMS 119可接收指示使用該些裝置中的一者來掃描包裝的事件資料。如下文參照履行中心200及圖2所論述，在履行過程期間，包裝辨識符（例如，條形碼或RFID標籤資料）可在特定階段由機器（例如，自動或手持條形碼掃描器、RFID讀取器、高速照相機、例如平板電腦（tablet）119A、行動裝置/PDA 119B、電腦119C等裝置或者類似裝置）掃描或讀取。WMS 119可將指示包裝辨識符的掃描或讀取的每一事件連同包裝辨識符、時間、日期、位置、使用者辨識符或其他資訊一起儲存於對應的資料庫（未畫出）中，且可將此資訊提供至其他系統（例如，運送及訂單追蹤系統111）。

在一些實施例中，WMS 119可儲存將一或多個裝置（例如，裝置107A-107C或119A-119C）與和系統100相關聯的一或多個使用者相關聯的資訊。舉例而言，在一些情況下，使用者（例如兼職或全職員工）與行動裝置的關聯可在於使用者擁有行動裝置（例如，行動裝置是智慧型電話）。在其他情況下，使用者與行動裝置的關聯可在於使用者臨時保管行動裝置（例如，使用者在一天開始時登記借出行動裝置，將在一天中使用行動裝置，且將在一天結束時歸還行動裝置）。

在一些實施例中，WMS 119可為與系統100相關聯的每一使用者維護工作日誌。舉例而言，WMS 119可儲存與每一員工相關聯的資訊，包括任何所分派的過程（例如，卸載卡車、自揀選區揀選物品、分撥牆工作（rebin wall work）、包裝物品）、使用者辨識符、位置（例如，履行中心200中的樓層或區）、員工在系統中移動的單元的數目（例如，所揀選的物品的數目、所包裝的物品的數目）、與裝置（例如，裝置119A-119C）相關聯的辨識符等。在一些實施例中，WMS 119可自例如在裝置119A-119C上操作的計時系統等計時系統接收簽入（check-in）及簽出（check-out）資訊。

在一些實施例中，第三方履行（3PL）系統121A-121C表示與物流及產品的第三方提供商相關聯的電腦系統。舉例而言，儘管一些產品被儲存於履行中心200中（如下文針對圖2所論述），然而其他產品可被儲存於場外、可按需生產或者可在其他情況下不可儲存於履行中心200中。3PL系統121A-121C可被配置以自FO系統113（例如，藉由FMG 115）接收訂單，且可直接向顧客提供產品及/或服務（例如，遞送或安裝）。在一些實施例中，3PL系統121A-121C中的一或多者可為系統100的一部分，而在其他實施例中，3PL系統121A-121C中的一或多者可在系統100之外（例如，由第三方提供商擁有或操作）。

在一些實施例中，履行中心授權系統（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、WMS 119、裝置119A-119C、運輸系統107及/或裝置107A-107C接收資訊。

圖1A中繪示的特定配置僅為實例。舉例而言，儘管圖1A繪示FC Auth系統123連接至FO系統113，然而並非所有實施例均需要此種特定配置。實際上，在一些實施例中，系統100中的系統可藉由包括網際網路、內部網路（Intranet）、廣域網路（Wide-Area Network，WAN）、都會區域網路（Metropolitan-Area Network，MAN）、符合電機電子工程師學會（Institute of Electrical and Electronic Engineers，IEEE）802.11a/b/g/n標準的無線網路、租用線路（leased line）等的一或多種公共或私有網路彼此連接。在一些實施例中，系統100中的系統中的一或多者可被實施為在資料中心、伺服器場（server farm）等處實施的一或多個虛擬伺服器。

圖2繪示履行中心200。履行中心200是儲存訂購時運送至顧客的物品的物理位置的實例。履行中心（FC）200可被劃分成多個區，所述多個區中的每一者繪示於圖2中。在一些實施例中，該些「區」可被視為接收物品、儲存物品、擷取物品及運送物品的過程的不同階段之間的虛擬劃分。因此，儘管在圖2中繪示「區」，然而亦可存在區的其他劃分，且在一些實施例中，圖2中的區可被省略、複製或修改。

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

工人將在入站區203中接收物品，且可使用電腦系統（未畫出）可選地檢查物品的損壞及正確性。舉例而言，工人可使用電腦系統將物品202A及202B的數量與訂購的物品數量進行比較。若數量不匹配，則此工人可拒絕物品202A或202B中的一或多者。若數量匹配，則工人可將該些物品（使用例如推車、手推車、堆高機，或者手動地）移動至緩衝區（buffer zone）205。緩衝區205可為當前在揀選區中所不需要的物品（例如，由於在揀選區中存在足夠高數量的此物品來滿足預測需求）的臨時儲存區域。在一些實施例中，堆高機206進行操作以在緩衝區205中四處移動物品以及在入站區203與卸貨區207之間移動物品。若在揀選區中需要物品202A或202B（例如，由於預測需求），堆高機可將物品202A或202B移動至卸貨區207。

卸貨區207可為FC 200的在物品被移動至揀選區209之前儲存所述物品的區域。被分派揀選任務的工人（「揀選者」）可接近揀選區中的物品202A及202B，使用行動裝置（例如，裝置119B）掃描揀選區的條形碼，且掃描與物品202A及202B相關聯的條形碼。揀選者然後可將物品帶至揀選區209（例如，藉由將物品放入搬運車（cart）上或者搬運物品）。

揀選區209可為FC 200的其中在儲存單元210上儲存物品208的區域。在一些實施例中，儲存單元210可包括物理排架（physical shelving）、書架、盒、運送箱、冰箱、冰櫃、冷藏庫等中的一或多者。在一些實施例中，揀選區209可被組織成多個樓層。在一些實施例中，工人或機器可以包括例如堆高機、升降機、傳送帶、搬運車、手推車、推車、自動機器人或裝置或者手動方式在內的多種方式將物品移動至揀選區209中。舉例而言，揀選者可將物品202A及202B放入卸貨區207中的手推車或搬運車上，且步行將物品202A及202B送至揀選區209。

揀選者可接收將物品放入（或「堆置（stow）」於）揀選區209中的特定地點（例如儲存單元210上的特定空間）的指令。舉例而言，揀選者可使用行動裝置（例如，裝置119B）掃描物品202A。所述裝置可例如使用指示過道、儲架及位置的系統來指示揀選者應將物品202A堆置於何處。然後，在將物品202A堆置於此位置之前，所述裝置可提示揀選者掃描此位置處的條形碼。所述裝置可向電腦系統（例如圖1A中的WMS 119）發送（例如，經由無線網路）資料來指示物品202A已由使用裝置119B的使用者堆置於所述位置處。

一旦使用者下訂單，揀選者便可在裝置119B上接收指令，以自儲存單元210擷取一或多個物品208。揀選者可擷取物品208，掃描物品208上的條形碼，且將其放入運輸機構214上。儘管運輸機構214被表示為滑動件，然而在一些實施例中，運輸機構可被實施為傳送帶、升降機、搬運車、堆高機、手推車、推車等中的一或多者。物品208然後可到達包裝區211。

包裝區211可為FC 200的自揀選區209接收物品且將物品包裝至盒或袋中以便最終運送至顧客的區域。在包裝區211中，被分派接收物品的工人（「分撥工人（rebin worker）」）將自揀選區209接收物品208，且確定物品208對應於什麼訂單。舉例而言，分撥工人可使用例如電腦119C等裝置來掃描物品208上的條形碼。電腦119C可以可視方式指示物品208與哪一訂單相關聯。舉例而言，此可包括牆216上的對應於訂單的空間或「單元格（cell）」。一旦訂單完成（例如，由於單元格容納訂單的所有物品），分撥工人可向包裝工人（或「包裝者（packer）」）指示訂單完成。包裝者可自單元格擷取物品，且將其放入盒或袋中進行運送。然後，包裝者可例如藉由堆高機、搬運車、推車、手推車、傳送帶、手動方式或其他方式將盒或袋發送至中樞區（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中的物品相關聯的PDD等來確定包裝220應與哪一路線及/或子路線相關聯。在一些實施例中，工人或機器可掃描包裝（例如，使用裝置119A-119C中的一者）以確定其最終目的地。一旦包裝220被分派至特定路線及/或子路線，工人及/或機器可移動待運送的包裝220。在示例性圖2中，營地區215包括卡車222、汽車226以及遞送工人224A及224B。在一些實施例中，卡車222可由遞送工人224A駕駛，其中遞送工人224A是為FC 200遞送包裝的全職員工，且卡車222由擁有、租賃或營運FC 200的同一公司擁有、租賃或營運。在一些實施例中，汽車226可由遞送工人224B駕駛，其中遞送工人224B是根據需要（例如，季節性地）進行遞送的「彈性（flex）」或不定期工人（occasional worker）。汽車226可由遞送工人224B擁有、租賃或營運。

參照圖3，示意性方塊圖300示出包括用於提供補貨通知的補貨通知系統301的系統的示例性實施例。補貨通知系統301可與圖1A所示系統100中的一或多個系統相關聯。舉例而言，補貨通知系統301可實施為SCM系統117的一部分。在一些實施例中，補貨通知系統301可實施為電腦系統，其接收並儲存庫存資訊，控制補貨通知，並向一或多個使用者（例如，外部前端系統103、運送及訂單追蹤系統111及/或FO系統113）發送補貨通知。舉例而言，補貨通知系統301可包括一或多個處理器305，所述一或多個處理器305可接收對與缺貨產品相關聯的補貨通知的請求。在一些實施例中，一或多個處理器305可經由網路302自使用者介面306接收對補貨通知的請求。一或多個處理器305可被配置以修改資料庫（例如資料庫304）以將狀態分派至產品，所述狀態指示存在對與產品相關聯的補貨通知的未決請求。舉例而言，資料庫304可儲存可供圖1A所示系統100購買的每種產品的庫存。資料庫304可進一步儲存與每種產品相關聯的資訊，包括但不限於與每種產品相關聯的產品辨識符及每種產品的可用性。舉例而言，若特定產品缺貨，則資料庫304可將缺貨狀態分派至所述特定產品並儲存狀態資訊。

在一些實施例中，一或多個處理器305可經由網路302自圖1A所示系統100中的一或多個系統或者自伺服器303接收訊息，所述訊息指示缺貨產品現在重新有貨且可供購買。一或多個處理器305可修改資料庫（例如資料庫304）以將不同的狀態分派至產品，所述不同的狀態指示產品現在可供購買。資料庫304可將新的狀態分派至產品並儲存此資訊。

在一些實施例中，一或多個處理器305可實施批次架構。批次架構可被配置以分析資料庫304，以辨識已被分派指示產品重新有貨的狀態的產品。批次架構可被配置以週期性地或按照預先確定的排程來分析資料庫304。有利的是，批次架構亦可被配置以確定向使用者發送補貨通知的通知排程，使得使用者在產品一重新有貨時便接收補貨通知，而且在使用者活動時亦接收補貨通知。一或多個處理器305可被配置以基於由批次架構確定的通知排程向使用者發送補貨通知。

系統300亦可包括網路302及伺服器303。補貨通知系統301、伺服器303及資料庫304可被連接，且能夠經由網路302彼此進行通訊。網路302可為無線網路、有線網路或無線網路與有線網路的任意組合中的一或多者。舉例而言，網路302可包括光纖網路、被動光學網路、纜線網路、網際網路網路（Internet network）、衛星網路、無線區域網路（wireless local area network，wirelss LAN）、全球行動通訊系統（「Global System for Mobile Communication，GSM」）、個人通訊服務（「Personal Communication Service，PCS」）、個人區域網路（「Personal Area Network，PAN」）、數位先進行動電話服務（digital advanced mobile phone service，D-AMPS）、無線保真（Wireless Fidelity，Wi-Fi）、固定無線資料（Fixed Wireless Data）、電氣及電子工程師學會（Institute of Electrical and Electronic Engineers，IEEE）802.11b、802.15.1、802.11n及802.11g或用於傳輸及接收資料的任何其他有線或無線網路中的一或多者。

另外，網路302可包括但不限於電話線、光纖、IEEE乙太網路902.3、廣域網路（「wide area network，WAN」）、區域網路（「LAN」）或例如網際網路等全球網路。此外，網路302可支援網際網路網路、無線通訊網路、蜂巢網路等或其任意組合。網路302可更包括一個網路或者作為獨立網路而運作或彼此協同運作的任何數目的上述示例性類型的網路。網路302可利用與其通訊耦合的一或多個網路元件的一或多種協定。網路302可轉化成其他協定，或者自其他協定轉化成網路裝置的一或多種協定。儘管網路302被繪示為單一網路，然而應理解，根據一或多個實施例，網路302可包括多個互連的網路，例如（舉例而言）網際網路、服務提供商網路、纜線電視網路、公司網路及家庭網路。

伺服器303可為網路伺服器。舉例而言，伺服器303可包括遞送可由例如使用者經由例如網際網路等網路（例如，網路302）存取的網路內容的硬體（例如，包括處理器、儲存體及輸入/輸出裝置的一或多個電腦）及/或軟體（例如，一或多個應用）。伺服器303可使用例如超文件傳送協定（HTTP或安全超文件傳送協定（secure HTTP， sHTTP））來與使用者進行通訊。遞送至使用者的網頁可包括例如超文件標記語言（Hypertext Markup Language，HTML）文件，HTML文件可除正文內容以外亦包括影像、式樣單（style sheet）及腳本。

例如（舉例而言）網路瀏覽器、網路爬蟲或本地行動應用等使用者程式可藉由使用HTTP對特定資源進行請求來發起通訊，且若無法這樣做，則伺服器303可用此資源的內容或錯誤訊息來進行響應。伺服器303亦可使得能夠或便於自使用者接收內容，因而使用者可能夠例如提交網路表單（web form），包括上載檔案。伺服器303亦可使用例如主動伺服器頁面（Active Server Pages，ASP）、個人主頁（personal home page，PHP）或其他腳本處理語言來支援伺服器側腳本處理。因此，伺服器303的行為可在單獨的檔案中進行腳本處理，而實際的伺服器軟體保持不變。

在其他實施例中，伺服器303可為應用伺服器，其可包括專用於高效執行用於支援其所應用的應用的程序（例如，程式、常式、腳本）的硬體及/或軟體。伺服器303可包括一或多個應用伺服器架構，包括例如爪哇（Java）應用伺服器（例如，Java平台企業版（Java platform, Enterprise Edition，Java EE））、來自微軟®的.NET架構、PHP應用伺服器等）。各種應用伺服器架構可包含全面服務層模型。伺服器303可充當例如實施系統100的實體可經由平台本身定義的應用程式介面（application program interface，API）存取的一組組件。對於網路應用，該些組件可在例如與網路伺服器相同的運行環境中實行，且應用伺服器可支援動態頁面的構建。應用伺服器亦可實施服務，例如（舉例而言）叢聚（clustering）、失效切換及負載平衡（load-balancing）。在各種實施例中，在應用伺服器是Java應用伺服器的情況下，網路伺服器可表現得像運行應用的擴展虛擬機，透明地在一側處置與和後端相關聯的資料庫的連接，且在另一側處置與網路客戶端的連接。

圖4示出示意性方塊圖400，其示出用於向使用者401提供補貨通知的示例性補貨通知系統402。補貨通知系統402可與圖3中的補貨通知系統301相同。如在圖4中看出，補貨通知系統402可包括一或多個處理器412，所述一或多個處理器412可被配置以藉由行動應用程式化介面（API）403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者與使用者401交換資料。舉例而言，使用者401可存取行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者來搜尋產品及購買產品。使用者401亦可存取行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者，以訂閱補貨通知，使得使用者401可當缺貨產品重新有貨時得到通知。在一些實施例中，使用者401可生成使用者賬戶，以便在行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者上訂閱補貨通知。因此，使用者401可能被要求藉由提供與賬戶相關聯的使用者ID及密碼來登錄使用者401的賬戶，以便訂閱補貨通知。

當使用者401藉由行動API 403、網路瀏覽器404及/或行動網路瀏覽器405訂閱並請求補貨通知時，一或多個處理器412可藉由一或多個購物車API 407a至407c接收對補貨通知的請求。一或多個處理器412可針對使用者401的每一進入點（entry point）維持單獨的購物車API 407a至407c。舉例而言，購物車API 407a可與行動API 403相關聯，使得一或多個處理器412可被配置以藉由購物車API 407a接收自行動API 403作出的對補貨通知的請求。購物車API 407b可與網路瀏覽器404相關聯，使得一或多個處理器412可被配置以藉由購物車API 407b接收自網路瀏覽器404作出的對補貨通知的請求。相似地，購物車API 407c可與行動網路瀏覽器405相關聯，使得一或多個處理器412可被配置以藉由購物車API 407c接收自行動網路瀏覽器405作出的對補貨通知的請求。在一些實施例中，一或多個處理器412可被配置以直接接收自購物車網路瀏覽器406作出的對補貨通知的請求。

如以上所論述，一或多個處理器412可被配置以將與每種產品相關聯的資訊儲存於資料庫408中。資料庫408可相似於圖3中的資料庫304。儘管圖4示出補貨通知系統402內部的資料庫408，然而在一些實施例中，資料庫408可位於補貨通知系統402外部，且可被配置以經由網路302與補貨通知系統402進行通訊。在一些實施例中，一或多個處理器412可被配置以修改資料庫408，以向每種產品分派狀態。舉例而言，當一或多個處理器412藉由購物車網路瀏覽器406、購物車API 407a、購物車API 407b及/或購物車API 407c接收到對與產品相關聯的補貨通知的請求時，一或多個處理器412可確定產品當前缺貨。然後，一或多個處理器412可修改資料庫408，以向產品分派指示產品缺貨的第一狀態。因此，資料庫408可儲存產品列表及與每種產品相關聯的資訊，包括產品的產品辨識符（例如，貯存計量單位（stock keeping unit，SKU））、可用產品的數量、指示產品可用性的狀態及/或對與產品相關聯的補貨通知的請求的數目。資料庫408亦可儲存與請求補貨通知的使用者相關聯的資訊，例如與使用者對每種產品的補貨通知的請求相關聯的使用者ID的列表。舉例而言，在使用者401請求特定產品的補貨通知之後，資料庫408可儲存與使用者401相關聯的使用者ID。補貨通知系統402可防止除批准資料之外的資料被儲存於資料庫408中。舉例而言，補貨通知系統402可僅支援將使用者ID、使用者辨識資訊及/或使用者電子郵件位址儲存於資料庫408中。在其他實施例中，當使用者401發送對特定產品的補貨通知的請求時，一或多個處理器412可修改資料庫408以分派與特定產品相關聯的補貨物品ID。補貨物品ID可包括與特定產品相關聯的資訊，例如與特定產品相關聯的產品ID、物品ID、供應商物品ID或供應商物品包裝ID。

在一些實施例中，一或多個處理器412可被配置以例如自伺服器303接收一或多條補貨訊息409。一或多條補貨訊息409可指示特定產品重新有貨且可供使用者購買。一或多條補貨訊息409可辨識與每種重新有貨的產品相關聯的產品辨識符，且亦可辨識每種可用產品的數量。在一些實施例中，一或多條補貨訊息409可包括與每種重新有貨的產品相關聯的物品ID及供應商物品ID。一或多個處理器412可基於與產品相關聯的供應商物品ID（例如產品ID或供應商物品包裝ID）自資料庫408擷取其他辨識資訊。另外或作為另一選擇，一或多條補貨訊息409可包括與每種重新有貨的產品相關聯的產品ID、物品ID、供應商物品ID或供應商物品包裝ID中的至少一者。產品ID可包括與產品分類相關聯的產品辨識符。物品ID可包括與產品相關聯的產品辨識符，所述產品辨識符指示產品的一或多種屬性，例如顏色、尺寸、製造商、材料或品牌。供應商物品ID可包括與產品相關聯的產品辨識符，所述產品辨識符亦辨識產品的供應商。供應商物品包裝ID可包括與供應商售賣的可供購買的產品集合（如行動電話及相關聯的電話殼（phone case））相關聯的產品辨識符。供應商物品包裝ID亦可辨識產品集合的供應商。然後，一或多個處理器412可被配置以在資料庫408中查找產品辨識符，並修改資料庫408以將第二狀態分派至與產品辨識符相關聯的產品。第二狀態可表示產品重新有貨且可供購買。一或多個處理器412亦可被配置以修改資料庫408，以改變在補貨後可供購買的每種產品的數量。

在一些實施例中，補貨通知系統402可包括批次架構410。一或多個處理器412可將批次架構410配置以分析資料庫408，以辨識已被分派指示產品重新有貨的狀態的產品。在一些實施例中，一或多個處理器412亦可將批次架構410配置以分析資料庫408，以確定每種可用產品的數量。批次架構410可被配置以週期性地或按照預先確定的排程來分析資料庫408。舉例而言，批次架構410可被配置以每2小時、每5小時、每10小時、每24小時或一周兩次地分析資料庫408。在其他實施例中，批次架構410可被配置以在由一或多個處理器412接收到每條補貨訊息409之後分析資料庫408。在一些實施例中，批次架構410可包括阿帕奇卡夫卡（Apache Kafka）、斯普林批次（Spring Batch）或能夠進行批次處理的任何開源軟體平台或開源架構。

在一些實施例中，批次架構410可週期性地分析資料庫408，以檢查對補貨通知的重複請求。舉例而言，使用者401可藉由行動API 403請求特定產品的補貨通知。使用者401亦可藉由行動網路瀏覽器405請求相同的特定產品的補貨通知。如以上所論述，即使使用者401請求相同的產品的補貨通知（由於使用者401使用兩個不同的進入點（即行動API 403及行動網路瀏覽器405）請求補貨通知），一或多個處理器412仍可分別藉由購物車API 407a及購物車API 407c單獨地接收所述兩個請求。因此，一或多個處理器412可將與使用者401相關聯的所述兩個請求單獨地儲存於資料庫408中。當一或多個處理器412接收到指示產品重新有貨的補貨訊息409時，一或多個處理器412可確定存在兩個對產品的補貨通知的未決請求。批次架構410可分析資料庫408並確定所述兩個對產品的補貨通知的未決請求與相同的使用者（即，使用者401）相關聯，而不是向使用者401發送兩個重複的補貨通知。批次架構410可藉由辨識例如與請求相關聯的使用者ID來確定所述兩個對補貨通知的未決請求與相同的使用者相關聯。當批次架構410確定所述兩個對補貨通知的未決請求均與使用者401相關聯時，批次架構410可生成通知排程，使得一或多個處理器412僅向使用者401發送相同的產品的一個補貨通知，藉此防止向使用者發送重複訊息。

有利的是，批次架構410亦可被配置以確定向使用者發送補貨通知的通知排程，使得使用者在產品一重新有貨時便接收補貨通知，而且在使用者活動時亦接收補貨通知。舉例而言，一或多個處理器412可在行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者上確定使用者的活動趨勢。在一些實施例中，一或多個處理器412可基於接收到的對補貨通知的請求的數目來確定使用者的活動趨勢。一或多個處理器412可監控例如每天每分鐘接收到的對補貨通知的請求的數目。基於接收到的對補貨通知的請求的數目，一或多個處理器412可確定其間一或多個處理器412最不可能接收到對補貨通知的請求的時段（timeframe），例如在上午2點至上午7點之間。另外，基於所確定的使用者的活動趨勢，一或多個處理器412可確定其間使用者最有可能在行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者上活動的時段。

一或多個處理器412可將使用者的活動趨勢資訊及時段資訊儲存於資料庫408中。基於儲存於資料庫408中的使用者的資訊，批次架構410可確定向使用者發送補貨通知的通知排程。因此，批次架構410可使得一或多個處理器412能夠在其間使用者將最有可能檢查補貨通知的時段內向使用者發送補貨通知。因此，批次架構410可基於每一使用者在行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者上的活動趨勢來確定為每一使用者定製的通知排程。

在一些實施例中，批次架構410亦可確定通知排程，使得一或多個處理器412不會在其間使用者將最有可能檢查補貨通知的時段之外向使用者發送補貨通知。在一些實施例中，批次架構410可產生通知排程，使得一或多個處理器412在某一時間（例如午夜）之後不向使用者發送補貨通知。在其他實施例中，確定通知排程可包括確定補貨通知的警報類型。批次架構410可確定通知排程，使得一或多個處理器412可被配置以基於通知排程來調整補貨通知的警報類型。舉例而言，批次架構410可產生通知排程，使得一或多個處理器412可被配置以使在某一時間（例如午夜）之後發送至使用者的任何補貨通知靜音。調整補貨通知的警報類型可包括調整通知的音量、調整通知的頻率、調整通知的顯示或其任意組合。

在一些實施例中，一或多個處理器412可基於每一使用者的活動狀態來確定通知排程。舉例而言，一或多個處理器412可實施批次架構410，以基於每一使用者對話（session）來獲得每一使用者的活動狀態的實時狀態。舉例而言，批次架構410可判斷使用者在使用者對話期間是否為「在線上（online）」或活動的，或者使用者在行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者上的使用者對話期間是否為「空閒（idle）」、「離線（offline）」或不活動的（inactive）。基於使用者的活動狀態，批次架構410可確定發送補貨通知的通知排程。舉例而言，批次架構410可確定通知排程，使得僅當使用者「在線上」時才向使用者發送補貨通知。

在其他實施例中，一或多個處理器412可在發送補貨通知之前確定補貨後的產品的數量。舉例而言，在接收到特定產品的補貨訊息409之後，一或多個處理器412可確定補貨後的產品的數量。一或多個處理器412可將補貨後的產品的數量與預先確定的臨限值進行比較，且基於所述比較，判斷是否向使用者發送補貨通知。舉例而言，若補貨後的產品的數量小於預先確定的臨限值，則一或多個處理器412可不發送補貨通知，直至產品的數量超過預先確定的臨限值為止。相似地，若補貨後的產品的數量超過預先確定的臨限值，則一或多個處理器412可向使用者發送補貨通知。視消費者對每種產品的需求而定，每種產品的預先確定的臨限值可有所變化。舉例而言，每種產品的預先確定的臨限值可與消費者對每種產品的需求成正比，以便防止每種產品快速缺貨。

在一些實施例中，一或多個處理器412可被配置以基於由批次架構410確定的通知排程向使用者發送補貨通知。一或多個處理器412可被配置以使用訊息傳遞平台411向使用者發送補貨通知。訊息傳遞平台411可包括能夠向使用者交換訊息的任何網際網路基礎設施。舉例而言，訊息傳遞平台411可包括電子郵件、短訊息服務（short message service，SMS）、軟體應用、API、即時訊息傳遞或其任意組合。在一些實施例中，使用者可能夠例如藉由登錄到其設定檔來選擇其偏好的訊息傳遞平台411。舉例而言，使用者可能夠選擇藉由電子郵件或藉由透過行動應用（例如行動API 403）達成的推送通知來接收補貨通知。

在一些實施例中，一或多個處理器412可被配置以修改資料庫408以更新補貨通知的狀態。舉例而言，資料庫408可包括產品列表及與每種產品相關聯的資訊，包括是否已針對每種產品向使用者發送了任何補貨通知。舉例而言，當一或多個處理器412接收到特定產品的補貨訊息409，並基於由批次架構410產生的通知排程藉由訊息傳遞平台411向使用者401發送補貨通知時，一或多個處理器412可修改資料庫408以將另一狀態分派至特定產品。所述狀態可指示特定產品的補貨通知已被發送至使用者。若補貨通知未能發送至使用者，一或多個處理器412可修改資料庫408以將又一狀態分派至特定產品。所述狀態可指示補貨通知未能發送至使用者。批次架構410可週期性地分析資料庫408以辨識被分派指示未能發送補貨通知的狀態的產品。當批次架構410辨識出具有指示未能發送補貨通知的所分派狀態的特定產品時，批次架構410可應用失效切換邏輯，以基於所確定的通知排程重新發送補貨通知。

圖5是用於向使用者501提供補貨通知的示例性補貨通知系統502的示意性方塊圖500。補貨通知系統502可相似於圖4中的補貨通知系統402。如在圖5中看出，補貨通知系統502可包括一或多個處理器512，所述一或多個處理器512可被配置以與第一使用者介面503及第二使用者介面504交換資料。第一使用者介面503及第二使用者介面504可包括行動API（例如行動API 403）、網路瀏覽器（例如網路瀏覽器404）、行動網路瀏覽器（例如網路瀏覽器405）或購物車網路瀏覽器（例如購物車網路瀏覽器406）中的至少一者。儘管圖5示出兩個使用者介面503、504，然而補貨通知系統502可被配置以與多於兩個使用者介面（例如，數千個使用者介面）交換資料。

相似於圖4中的一或多個處理器412，一或多個處理器512可被配置以自第一使用者介面503及第二使用者介面504接收對補貨通知的請求。在接收到補貨通知的請求之後，一或多個處理器512可確定與請求相關聯的產品缺貨，並修改資料庫508以將狀態分派至每種產品。所述狀態可指示產品缺貨。一或多個處理器512亦可將與請求補貨通知的使用者相關聯的資訊（例如與請求每種產品的補貨通知的使用者相關聯的使用者ID的列表）儲存於資料庫508中。

在一些實施例中，一或多個處理器512可被配置以例如自伺服器303接收一或多條補貨訊息509。相似於圖4中的補貨訊息409，一或多條補貨訊息509可指示特定產品重新有貨且可供使用者購買。一或多條補貨訊息509可辨識與每種重新有貨的產品相關聯的產品辨識符，且亦可辨識每種可用產品的數量。另外或作為另一選擇，一或多條補貨訊息509可包括與每種重新有貨的產品相關聯的產品ID、物品ID、供應商物品ID或供應商物品包裝ID中的至少一者。產品ID可包括與產品分類相關聯的產品辨識符。物品ID可包括與產品相關聯的產品辨識符，所述產品辨識符指示產品的一或多種屬性，例如顏色、尺寸、製造商、材料或品牌。供應商物品ID可包括與產品相關聯的產品辨識符，所述產品辨識符亦辨識產品的供應商。供應商物品包裝ID可包括與供應商售賣的可供購買的產品集合相關聯的產品辨識符。供應商物品包裝ID亦可辨識產品集合的供應商。然後，一或多個處理器512可被配置以在資料庫508中查找產品辨識符，並修改資料庫508以將第二狀態分派至與產品辨識符相關聯的產品。第二狀態可指示產品重新有貨且可供購買。一或多個處理器512亦可被配置以修改資料庫508，以改變在補貨後可供購買的每種產品的數量。

相似於圖4中的補貨通知系統402，補貨通知系統502可包括批次架構510。一或多個處理器512可將批次架構510配置以分析資料庫508，以辨識已被分派指示產品重新有貨的狀態的產品。在一些實施例中，一或多個處理器512亦可將批次架構510配置以分析資料庫508，以確定每種可用產品的數量。批次架構510可被配置以週期性地或按照預先確定的排程來分析資料庫408。舉例而言，批次架構510可被配置以每2小時、每5小時、每10小時、每24小時或一周兩次地分析資料庫508。在其他實施例中，批次架構510可被配置以在由一或多個處理器512接收到每條補貨訊息509之後分析資料庫508。

在一些實施例中，批次架構510可週期性地分析資料庫508，以檢查對補貨通知的重複請求。舉例而言，使用者501可藉由第一使用者介面503發送對產品的補貨通知的第一請求。使用者501亦可藉由第二使用者介面504發送對產品的補貨通知的第二請求。批次架構510可藉由例如辨識與每一請求相關聯的使用者ID來確定第一請求及第二請求均來自使用者501。批次架構510然後可判斷第一請求是否與第二請求相關。舉例而言，批次架構510可判斷與對補貨通知的第一請求相關聯的產品是否與對補貨通知的第二請求相關聯的產品相同。若與第一請求及第二請求相關聯的所述兩個產品相同，則批次架構510可確定第一請求與第二請求相關。當批次架構510確定對補貨通知的所述兩個請求相關時，批次架構510可產生通知排程，使得一或多個處理器512僅向使用者501發送產品的一個補貨通知，藉此防止向使用者發送重複訊息。

在其他實施例中，批次架構510可確定第一使用者介面503與使用者501相關聯，且第二使用者介面504與不同的使用者相關聯。一或多個處理器512可藉由第一使用者介面503接收對第一產品的補貨通知的第一請求，且藉由第二使用者介面504接收對第二產品的補貨通知的第二請求。即使第一產品與第二產品相同，當批次架構510確定第一使用者介面503與第二使用者介面504不相關時，批次架構510可向與第一使用者介面503相關聯的使用者501發送第一補貨通知，且向與第二使用者介面504相關聯的不同使用者發送第二補貨通知。

有利的是，批次架構510亦可被配置以確定向使用者發送補貨通知的通知排程，使得使用者在產品一重新有貨時便接收補貨通知，而且在使用者活動時亦接收補貨通知。舉例而言，一或多個處理器512可在第一使用者介面503或第二使用者介面504中的至少一者上確定使用者的活動趨勢。基於所確定的使用者的活動趨勢，一或多個處理器512可確定其間使用者最有可能在第一使用者介面503或第二使用者介面504中的至少一者上活動的時段。一或多個處理器512可將使用者的活動趨勢資訊及時段資訊儲存於資料庫508中。基於儲存於資料庫508中的使用者的資訊，批次架構510可確定向使用者發送補貨通知的通知排程。因此，批次架構510可使得一或多個處理器512能夠在其間使用者將最有可能檢查補貨通知的時段內向使用者發送補貨通知。因此，批次架構510可基於每一使用者與第一使用者介面503或第二使用者介面504中的至少一者的交互來確定為每一使用者定製的通知排程。

在一些實施例中，批次架構510亦可確定通知排程，使得一或多個處理器512不會在其間使用者將最有可能檢查補貨通知的時段之外向使用者發送補貨通知。在一些實施例中，批次架構510可產生通知排程，使得一或多個處理器512在某一時間（例如午夜）之後不向使用者發送補貨通知。在其他實施例中，確定通知排程可包括確定補貨通知的警報類型。批次架構510可確定通知排程，使得一或多個處理器512可被配置以基於通知排程來調整補貨通知的警報類型。舉例而言，批次架構510可產生通知排程，使得一或多個處理器512可被配置以使在某一時間（例如午夜）之後發送至使用者的任何補貨通知靜音。

在一些實施例中，一或多個處理器512可被配置以基於由批次架構510確定的通知排程向使用者發送補貨通知。一或多個處理器512可被配置以使用訊息傳遞平台511向使用者發送補貨通知。訊息傳遞平台511可包括能夠向使用者交換訊息的任何網際網路基礎設施。舉例而言，訊息傳遞平台511可包括電子郵件、短訊息服務（SMS）、社群網路服務（social network service，SNS）、軟體應用、API、即時訊息傳遞服務或其任意組合。在一些實施例中，使用者可能夠例如藉由登錄到其設定檔來選擇其偏好的訊息傳遞平台511。舉例而言，使用者可能夠選擇藉由電子郵件或藉由透過行動應用達成的推送通知來接收補貨通知。

如參照圖4所論述，若補貨通知未能發送至使用者，則一或多個處理器512可修改資料庫508以將可指示補貨通知未能發送至使用者的狀態分派至特定產品。批次架構510可週期性地分析資料庫508，以辨識被分派指示未能發送補貨通知的狀態的產品。當批次架構510辨識出具有指示未能發送補貨通知的所分派狀態的特定產品時，批次架構510可應用失效切換邏輯，以基於所確定的通知排程重新發送補貨通知。

圖6是示出用於提供補貨通知的示例性方法600的流程圖。此示例性方法是以舉例的方式提供。圖6中所示的方法600可由各種系統的一或多種組合來執行或以其他方式實行。舉例而言，如下所述的方法600可由如圖3中所示的補貨通知系統301來施行，且在闡釋圖6所示方法時參照補貨通知系統301的各種元件。圖6中所示的每一方塊表示示例性方法600中的一或多個過程、方法或子常式。參照圖6，示例性方法600可在方塊601處開始。

在方塊601處，一或多個處理器305可接收對與產品相關聯的補貨通知的請求。在一些實施例中，使用者可藉由行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者發送對補貨通知的請求。然後，一或多個處理器305可藉由購物車API 407a至407c中的至少一者或者直接藉由購物車網路瀏覽器406接收對補貨通知的請求。

一旦一或多個處理器305接收到對補貨通知的請求，方法600可前進至方塊602。在方塊602處，一或多個處理器305可修改資料庫（例如資料庫408）以將第一狀態分派至產品。如以上參照圖4所論述，資料庫408可儲存被提供用於購買的每種產品的庫存以及與每種產品相關聯的資訊，包括產品的產品辨識符（例如，貯存計量單位（SKU））、可用產品的數量、指示產品可用性的狀態及/或對與產品相關聯的補貨通知的請求的數目。因此，在方塊602處，一或多個處理器305可修改資料庫408，例如，將可指示產品缺貨的第一狀態分派至產品。

在方塊603處，一或多個處理器305可接收補貨訊息，例如圖4中的補貨訊息409。補貨訊息可指示缺貨產品重新有貨且可供使用者購買。補貨訊息可辨識與產品相關聯的產品辨識符，且亦可辨識補貨後可用的產品數量。另外或作為另一選擇，補貨訊息可包括與產品相關聯的產品ID、物品ID、供應商物品ID或供應商物品包裝ID中的至少一者。產品ID可包括與產品分類相關聯的產品辨識符。物品ID可包括與產品相關聯的產品辨識符，所述產品辨識符指示產品的一或多種屬性，例如顏色、尺寸、製造商、材料或品牌。供應商物品ID可包括與產品相關聯的產品辨識符，所述產品辨識符亦辨識產品的供應商。供應商物品包裝ID可包括與供應商售賣的可供購買的產品集合相關聯的產品辨識符。供應商物品包裝ID亦可辨識產品集合的供應商。

在方塊603處接收到補貨訊息之後，方法600可前進至方塊604。在方塊604處，一或多個處理器305可被配置以在資料庫408中查找產品辨識符，並修改資料庫408以將第二狀態分派至與產品辨識符相關聯的產品。第二狀態可指示產品重新有貨且可供購買。一或多個處理器305亦可被配置以修改資料庫408，以改變在補貨後可供購買的產品的數量。

方法600可前進至方塊605，在方塊605處，一或多個處理器305可基於由批次架構（例如批次架構410）確定的通知排程向使用者發送補貨通知。在一些實施例中，針對特定產品發送至使用者的補貨通知可包括接收者姓名（例如，使用者姓名）、產品名稱（例如，重新有貨的特定產品的名稱）、特定產品的影像或與特定產品相關聯的鏈接中的至少一者。與特定產品相關聯的鏈接可為單一細節頁面（SDP）鏈接，藉由單一細節頁面（SDP）鏈接，使用者可存取示出與特定產品相關聯的詳細資訊的SDP。如以上參照圖4所論述，一或多個處理器305可將批次架構配置以分析資料庫508，以辨識已被分派第二狀態的產品，所述第二狀態指示產品重新有貨。在一些實施例中，一或多個處理器305亦可將批次架構配置以分析資料庫508，以確定每種可用產品的數量。批次架構可辨識已被分派第二狀態的產品及存在對補貨通知的未決請求的產品。對於具有對補貨通知的未決請求的產品，批次架構可確定向使用者發送補貨通知的通知排程。

舉例而言，批次架構可被配置以確定向使用者發送補貨通知的通知排程，使得使用者在產品一重新有貨時便接收補貨通知，而且在使用者活動時亦接收補貨通知。舉例而言，一或多個處理器305可在行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者上確定使用者的活動趨勢。基於所確定的使用者的活動趨勢，一或多個處理器305可確定其間使用者最有可能在行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者上活動的時段。一或多個處理器305可將使用者的活動趨勢資訊及時段資訊儲存於資料庫408中。基於儲存於資料庫408中的使用者的資訊，批次架構可確定向使用者發送補貨通知的通知排程。因此，批次架構可使得一或多個處理器305能夠在其間使用者將最有可能檢查補貨通知的時段內向使用者發送補貨通知。因此，批次架構可基於每一使用者在行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者上的活動趨勢來確定為每一使用者定製的通知排程。

在一些實施例中，批次架構亦可確定通知排程，使得一或多個處理器305不會在其間使用者將最有可能檢查補貨通知的時段之外向使用者發送補貨通知。在其他實施例中，批次架構可確定通知排程，使得一或多個處理器305可被配置以基於通知排程來調整補貨通知的警報類型。舉例而言，批次架構可產生通知排程，使得一或多個處理器305可被配置以使在某一時間（例如午夜）之後發送至使用者的任何補貨通知靜音。

基於由批次架構確定的通知排程，一或多個處理器305可藉由一或多個訊息傳遞平台（例如訊息傳遞平台411）向使用者發送補貨通知。訊息傳遞平台411可包括能夠向使用者交換訊息的任何網際網路基礎設施。舉例而言，訊息傳遞平台411可包括電子郵件、短訊息服務（SMS）、軟體應用、API、即時訊息傳遞或其任意組合。在一些實施例中，使用者可能夠例如藉由登錄到其設定檔來選擇其偏好的訊息傳遞平台411。舉例而言，使用者可能夠選擇藉由電子郵件或藉由透過行動應用（例如行動API 403）達成的推送通知來接收補貨通知。

圖7是示出用於提供補貨通知的方法700的流程圖。此示例性方法是以舉例的方式提供。圖7中所示的方法700可由各種系統的一或多種組合來執行或以其他方式實行。舉例而言，如下所述的方法700可由如圖3中所示的補貨通知系統301來施行，且在闡釋圖7所示方法時參照補貨通知系統301的一或多個元件。圖7中所示的每一方塊表示示例性方法700中的一或多個過程、方法或子常式。參照圖7，示例性方法700可在方塊701處開始。

在方塊701處，一或多個處理器305可接收對與第一產品相關聯的補貨通知的第一請求。在方塊702處，一或多個處理器305可接收對與第二產品相關聯的補貨通知的第二請求。在一些實施例中，第一請求與第二請求可來自相同的使用者。在其他實施例中，第一請求可來自第一使用者，且第二請求可來自第二使用者。使用者可藉由行動API 403、網路瀏覽器404、行動網路瀏覽器405或購物車網路瀏覽器406中的至少一者發送對補貨通知的請求。然後，一或多個處理器305可藉由購物車API 407a至407c中的至少一者或者直接藉由購物車網路瀏覽器406接收對補貨通知的第一請求及第二請求。

在接收到對補貨通知的第一請求及第二請求之後，方法700可前進至方塊703。在方塊703處，一或多個處理器305可修改資料庫（例如資料庫408）以將第一狀態分派至第一產品及第二產品。第一狀態可指示第一產品及第二產品缺貨。如以上參照圖4所論述，資料庫408可儲存與第一產品及第二產品相關聯的資訊，包括但不限於與第一產品及第二產品相關聯的產品辨識符（例如，貯存計量單位（SKU））、可用的第一產品及第二產品的數量、指示第一產品及第二產品的可用性的狀態、對第一產品及第二產品的未決補貨通知請求的數目及/或指示第一產品及第二產品的補貨通知是否已被發送的狀態。

在方塊704處，一或多個處理器305可接收補貨訊息，例如圖4中的一或多條補貨訊息409。補貨訊息可指示第一產品及第二產品重新有貨且可供購買。補貨訊息可辨識與第一產品及第二產品相關聯的產品辨識符，且亦可辨識補貨後可用的第一產品及第二產品的數量。另外或作為另一選擇，補貨訊息可包括與第一產品及第二產品中的每一者相關聯的產品ID、物品ID、供應商物品ID或供應商物品包裝ID中的至少一者。產品ID可包括與產品分類相關聯的產品辨識符。物品ID可包括與產品相關聯的產品辨識符，所述產品辨識符指示產品的一或多種屬性，例如顏色、尺寸、製造商、材料或品牌。供應商物品ID可包括與產品相關聯的產品辨識符，所述產品辨識符亦辨識產品的供應商。供應商物品包裝ID可包括與由供應商售賣的可供購買的產品集合相關聯的產品辨識符。供應商物品包裝ID亦可辨識產品集合的供應商。

在方塊704處接收到補貨訊息之後，方法700可前進至方塊705。在方塊705處，一或多個處理器305可被配置以在資料庫408中查找產品辨識符，並修改資料庫408以將第二狀態分派至與產品辨識符相關聯的第一產品及第二產品。第二狀態可指示第一產品及第二產品重新有貨且可供購買。一或多個處理器305亦可被配置以修改資料庫408，以改變在補貨後可供購買的第一產品及第二產品的數量。

在將第二狀態分派至第一產品及第二產品之後，方法700可前進至方塊706。在方塊706處，一或多個處理器305可判斷第一產品及第二產品的數量是否超過預先確定的臨限值。舉例而言，在方塊704處接收到第一產品及第二產品的補貨訊息之後，一或多個處理器305可確定可用的第一產品及第二產品的數量。一或多個處理器305可將補貨後的第一產品及第二產品的數量與預先確定的臨限值進行比較，並基於所述比較判斷是否向使用者發送補貨通知。舉例而言，若補貨後的第一產品及第二產品中的每一者的數量小於預先確定的臨限值，則一或多個處理器305可不發送補貨通知，直至每種產品的數量超過預先確定的臨限值為止。相似地，若補貨後的第一產品及第二產品中的每一者的數量超過預先確定的臨限值，則一或多個處理器305可繼續操作以向使用者發送補貨通知。視消費者對每種產品的需求而定，每種產品的預先確定的臨限值可有所變化。舉例而言，每種產品的預先確定的臨限值可與消費者對每種產品的需求成正比，以便防止每種產品快速缺貨。

若一或多個處理器305確定第一產品及/或第二產品的數量小於預先確定的臨限值，則方法700可在方塊707處終止，且將不向使用者發送補貨通知。相反，若一或多個處理器305確定第一產品及/或第二產品的數量超過預先確定的臨限值，則方法700可前進至方塊708。在方塊708處，一或多個處理器305可判斷對和第一產品相關聯的補貨通知的第一請求（方塊701）是否與對和第二產品相關聯的補貨通知的第二請求（方塊702）相關。

如以上參照圖5所論述，舉例而言，批次架構可藉由例如在資料庫408中辨識與每一請求相關聯的使用者ID來確定第一請求與第二請求均來自相同的使用者。若和第一請求相關聯的使用者ID與和第二請求相關聯的使用者ID相同，則批次架構可確定第一請求與第二請求來自相同的使用者。然後，批次架構可藉由例如將與每個請求相關聯的產品進行比較來判斷第一請求是否與第二請求相關。舉例而言，批次架構可判斷和對補貨通知的第一請求相關聯的第一產品是否與和對補貨通知的第二請求相關聯的第二產品相同。若分別和第一請求及第二請求相關聯的第一產品與第二產品相同，則批次架構可確定第一請求與第二請求相關。

當批次架構確定對補貨通知的第一請求與第二請求相關時，方法700可前進至方塊710。在方塊710處，一或多個處理器305可將批次架構配置以產生通知排程，使得一或多個處理器305僅向使用者發送第一產品及第二產品二者的一個補貨通知，藉此防止向使用者發送重複訊息。另一方面，批次架構可確定對補貨通知的第一請求與第二請求不相關。舉例而言，批次架構可確定和對補貨通知的第一請求相關聯的第一產品與和對補貨通知的第二請求相關聯的第二產品不相同。舉例而言，使用者可已發送對兩種不同的產品的補貨通知的兩個不同的請求。當批次架構確定對補貨通知的第一請求與第二請求不相關時，方法700可前進至方塊709。在方塊709處，一或多個處理器305可向使用者發送第一產品的第一補貨通知，且向使用者發送第二產品的單獨的第二補貨通知。

儘管已參照本揭露的具體實施例示出並闡述了本揭露，然而應理解，本揭露可不加修改地實踐於其他環境中。上述說明是出於例示目的而呈現。以上說明並非詳盡性的且並非僅限於所揭露的精確形式或實施例。藉由考量對所揭露的實施例的說明及實踐，各種修改及改編對於熟習此項技術者而言將顯而易見。另外，儘管所揭露的實施例的態樣被闡述為儲存於記憶體中，然而熟習此項技術者應理解，該些態樣亦可儲存於其他類型的電腦可讀取媒體上，例如輔助儲存裝置（例如硬碟或光碟唯讀記憶體（compact disc ROM，CD ROM））或者其他形式的隨機存取記憶體（random access memory，RAM）或唯讀記憶體（read-only memory，ROM）、通用序列匯流排（universal serial bus，USB）媒體、數位影音光碟（digital versatile disc，DVD）、藍光（Blu-ray）或其他光驅動媒體上。

基於書面說明及所揭露的方法的電腦程式處於有經驗的開發者的技能範圍內。可使用熟習此項技術者已知的任何技術來創建各種程式或程式模組，或者可結合既有的軟體來設計各種程式或程式模組。舉例而言，可採用或借助.Net Framework、.Net Compact Framework（以及相關語言，如Visual Basic、C等）、Java、C++、Objective-C、HTML、HTML/AJAX組合、XML或包括Java小程式的HTML來設計程式區段或程式模組。

另外，儘管本文中已闡述了例示性實施例，然而熟習此項技術者基於本揭露將理解具有等效元素、修改、省略、組合（例如，各種實施例之間的態樣的組合）、改編及/或變更的任何及所有實施例的範圍。申請專利範圍中的限制應基於申請專利範圍中採用的語言進行廣義解釋，而並非僅限於本說明書中闡述的實例或在申請的過程期間闡述的實例。所述實例應被視為非排他性的。此外，所揭露的方法的步驟可以任何方式進行修改，包括藉由對步驟進行重新排序及/或插入或刪除步驟。因此，旨在使本說明書及實例僅被認為是例示性的，真正的範圍及精神由以下申請專利範圍及其等效內容的全部範圍來指示。

100、300:示意性方塊圖/系統 101:網路/運送授權技術（SAT）系統 102A:裝置/使用者裝置/行動裝置 102B:裝置/使用者裝置/電腦 103:外部前端系統 105:內部前端系統 107:運輸系統 107A、107B、107C:裝置/行動裝置 109:賣方入口 111:運送及訂單追蹤（SOT）系統 113:履行最佳化（FO）系統 115:履行訊息傳遞閘道（FMG） 117:供應鏈管理（SCM）系統 119:倉庫管理系統（WMS） 119A:裝置/行動裝置/計算裝置/平板電腦 119B:裝置/行動裝置/計算裝置/PDA 119C:裝置/行動裝置/計算裝置/電腦 121A、121B、121C:第三方履行（3PL）系統 123:履行中心授權系統（FC Auth） 125:勞資管理系統（LMS） 200:履行中心（FC） 201、222:卡車 202A、202B、208:物品 203:入站區 205:緩衝區 206:堆高機 207:卸貨區 209:揀選區 210:儲存單元 211:包裝區 213:中樞區 214:運輸機構 215:營地區 216:牆 218、220:包裝 224A、224B:遞送工人 226:汽車 301、402、502:補貨通知系統 302:網路 303:伺服器 304、408、508:資料庫 305、412、512:處理器 306:使用者介面 400、500:示意性方塊圖 401、501:使用者 403:行動應用程式化介面（API） 404:網路瀏覽器 405:網路瀏覽器/行動網路瀏覽器 406:購物車網路瀏覽器 407a、407b、407c:購物車API 409、509:補貨訊息 410、510:批次架構 411、511:訊息傳遞平台 503:使用者介面/第一使用者介面 504:使用者介面/第二使用者介面 600、700:方法 601、602、603、604、605、701、702、703、704、705、706、707、708、709、710:步驟

圖1A是示出符合所揭露實施例的網路的示例性實施例的示意性方塊圖，所述網路包括用於能夠進行通訊的運送（shipping）、運輸（transportation）及物流操作的電腦化系統。

圖1B繪示符合所揭露實施例的樣本搜尋結果頁面（Search Result Page，SRP），其包括滿足搜尋請求的一或多個搜尋結果以及交互式使用者介面元素。

圖1C繪示符合所揭露實施例的樣本單一細節頁面（Single Detail Page，SDP），其包括產品及關於產品的資訊以及交互式使用者介面元素。

圖1D繪示符合所揭露實施例的樣本購物車頁面（Cart page），其包括虛擬購物車中的物品以及交互式使用者介面元素。

圖1E繪示符合所揭露實施例的樣本訂單頁面（Order page），其包括來自虛擬購物車的物品以及關於購買及運送的資訊以及交互式使用者介面元素。

圖2是符合所揭露實施例的被配置以利用所揭露電腦化系統的示例性履行中心（fulfillment center，FC）的圖例。

圖3是示出包括用於提供補貨通知的補貨通知系統的系統的示例性實施例的示意性方塊圖。

圖4是用於提供補貨通知的示例性補貨通知系統的示意性方塊圖。

圖5是用於提供補貨通知的示例性補貨通知系統的另一示意性方塊圖。

圖6是示出用於提供補貨通知的方法的示例性實施例的流程圖。

圖7是示出用於提供補貨通知的方法的另一示例性實施例的流程圖。

300:示意性方塊圖/系統 301:補貨通知系統 302:網路 303:伺服器 304:資料庫 305:處理器 306:使用者介面

Claims (10)

1. 一種用於提供多個補貨通知的電腦實施的方法，所述方法包括： 接收對與第一產品相關聯的補貨通知的第一請求； 修改資料庫以將第一狀態分派至所述第一產品； 接收對與第二產品相關聯的補貨通知的第二請求； 修改所述資料庫以將所述第一狀態分派至所述第二產品； 接收指示所述第一產品以及所述第二產品可供購買的訊息； 修改所述資料庫以將第二狀態分派至所述第一產品以及所述第二產品； 判斷所述第一請求是否與所述第二請求相關，其中當所述第一請求與所述第二請求相關時，所述第一請求以及所述第二請求與與使用者相關聯的相同辨識符相關聯； 確定通知排程；以及 當所述第一請求與所述第二請求相關時，響應於所述第一請求以及第二請求，基於所確定的所述通知排程向所述使用者發送一個補貨通知。
2. 如請求項1所述的方法，其中所述第一請求是自與所述使用者相關聯的第一使用者介面接收的，並且所述第二請求是自與所述使用者相關聯的第二使用者介面接收的。
3. 如請求項2所述的方法，其中所述第一使用者介面或所述第二使用者介面中的至少一者包括行動應用程式化介面、網路瀏覽器、行動網路瀏覽器或購物車網路瀏覽器中的至少一者。
4. 如請求項1所述的方法，其中： 所述第一狀態指示對缺貨產品的補貨通知的未決請求；並且 所述第二狀態指示所述缺貨產品有貨，且所述補貨通知已準備好發送至所述使用者。
5. 如請求項1所述的方法，其中所述補貨通知包括針對行動應用的推送通知或者電子郵件通知中的至少一者。
6. 如請求項1所述的方法，更包括： 修改所述資料庫以將第三狀態分派至所述第一產品或所述第二產品中的至少一者，其中所述第三狀態指示未能向所述使用者發送所述補貨通知；以及 將批次架構配置以應用失效切換邏輯，以基於所確定的所述通知排程向所述使用者重新發送所述補貨通知。
7. 如請求項1所述的方法，更包括： 確定補貨後所述第一產品或所述第二產品中的至少一者的數量；以及 當所述數量超過預先確定的臨限值時，向所述使用者發送所述補貨通知。
8. 如請求項2所述的方法，更包括將批次架構配置以基於所述使用者與所述第一使用者介面或所述第二使用者介面中的至少一者進行交互的時間來確定所述通知排程。
9. 如請求項1所述的方法，其中： 所述通知排程包括警報類型，並且 所述方法更包括基於發送所述補貨通知的排程時間來調整所述警報類型。
10. 一種用於提供多個補貨通知的電腦實施的系統，所述系統包括： 記憶體，儲存指令；以及 至少一個處理器，被配置以執行所述指令以執行請求項1-9中的至少一者的操作。

Images