TW202207128A - 從數位訊息中獲得資訊的系統及方法 - Google Patents

Abstract

本發明部分地係關於用於使用一訊息中之統一資源定位符(URL)獲得資訊之系統及方法。該資訊可使用機率性方法自該等URL獲得，這可能比確定性方法達成更佳的結果。此外，自一URL獲得之該資訊可使用自與該URL相關聯之一網頁資源獲得之資訊加以補充及/或確認。根據一實施例，自對應於一訊息之數位內容獲得用於一網頁資源之一URL。接著可基於該URL及該網頁資源獲得出貨資訊。該出貨資訊可包括該網頁資源係用於追蹤一出貨之一指示、用於該出貨之一追蹤編號及用於該出貨之一出貨供應商中之至少一者。接著可儲存該出貨資訊以用於稍後獲得用於該出貨之追蹤更新。

Description

從數位訊息中獲得資訊的系統及方法

本申請案係關於自數位訊息獲得資訊，且在特定實施例中，係關於自數位訊息獲得出貨資訊。

當顧客經由線上商店訂購產品時，顧客可接收提供用於追蹤產品之出貨之出貨資訊的電子郵件或其他訊息。此出貨資訊可包括促進出貨之出貨供應商、用於出貨之追蹤編號及對應於用於追蹤出貨之網頁或其他網頁資源的統一資源定位符(URL)。使用網頁資源，顧客可能能夠檢視出貨之狀態及/或出貨之預期遞送日期。網頁資源亦可包括出貨供應商及/或用於出貨之追蹤編號。

在一些情況下，提供出貨資訊之訊息可埋入顧客之收件匣中，從而使得顧客難以稍後定位訊息並獲得出貨資訊。對於頻繁地線上訂購產品且可在任何給定時間具有多個未決產品出貨之顧客，此問題可複雜化。用於此等出貨中之每一者之追蹤資訊常常將提供於不同訊息中，這組織起來可具有挑戰性且耗時。因而，顧客可能難以定位一些產品之出貨資訊且可甚至丟失對彼等產品之追蹤。另外或替代地，為給定出貨提供追蹤資訊之訊息可以顧客可能不太熟悉的語言撰寫且這可能妨礙追蹤資訊之識別、定位及/或理解。

本發明之一些實施例提供用於自使用者之數位訊息，包括電子郵件訊息、文字訊息及其類似者自動地提取出貨資訊的電腦實施系統及方法。出貨資訊接著可新增至用於使用者之出貨資訊之合併清單，這允許使用者避免人工組織及追蹤訊息及/或出貨資訊。換言之，一旦經提取，則出貨資訊等可諸如以經界定及/或一致格式呈現給使用者及/或可用於提供此種呈現。方便地，以此方式，顧客/使用者可一目了然地呈現有關於各種出貨之資訊，諸如基於訊息之集合(例如，使用者之一或多個收件匣中之訊息)識別出貨資訊的所有未完成(例如，尚未交付)出貨之彙總概觀清單。另外或替代地，此類出貨資訊可用以其他目的，諸如為使用者提供關於其各種出貨之更新，可能用於其未完成出貨中之一些或全部。舉例而言，此類更新可以經界定及/或一致格式共同呈現給使用者。在特定實例中，此類更新可藉助於合適的彙總概觀呈現，諸如可列舉或以其他方式提供對用於各種出貨之追蹤資訊/更新之存取。

基於諸如電子郵件訊息之訊息而識別出貨資訊出於各種原因可能並非微不足道。首先，提供出貨資訊之訊息可呈各種格式。舉例而言，提供關於來自特定商家/運送人/承運人之未決出貨之資訊的訊息可呈第一格式(例如，在訊息之內容及/或訊息內之其佈局/配置方面)，而另一商家/運送人/承運人可採用不同格式。此外，甚至對於同一商家/運送人/承運人，此類格式可能不時發生改變或取決於各種因素而變化。另外，在一些情況下，提供出貨之指示之訊息在訊息中可不直接包括出貨資訊但實際上可包括一或多個URL，其可用於存取網頁或其他網頁資源，可藉此獲得關於給定出貨之資訊。舉例而言，此類資訊可包括追蹤資訊、追蹤編號等。此等URL及與其相對應之網頁之格式可在商家/運送人/承運人之間發生變化，類似於如上文針對訊息之格式所論述。此外，不僅URL之格式及/或與其相對應之網頁之內容/佈局/格式可在商家/運送人/承運人之間發生變化，在一些情況下其亦可針對給定商家/運送人/承運人不時地及/或基於各種其他因素發生變化或改變。

本申請案描述基於訊息獲得及提取出貨資訊之各種方式。舉例而言，出貨資訊可基於到達使用者之收件匣，諸如其電子郵件收件匣及/或其文字訊息(SMS)收件匣中之訊息而獲得。在一些實施例中，藉由以下操作自訊息獲得出貨資訊：a)自訊息提取URL；b)分析URL以判定及/或確認出貨資訊；以及c)分析對應於URL之網頁資源以判定及/或確認出貨資訊。提供機率性方法以自URL及/或網頁資源判定出貨資訊。舉例而言，當相較於確定性方法時，此等機率性方法可較佳適合於處置產品之出貨中可採用的大量出貨供應商、履行網路、郵政服務供應商及最後一英里交付服務。因此，機率性方法可供應自訊息判定出貨資訊之較可靠方式。

根據本發明之一態樣，提供一種電腦實施方法。該方法包括識別顧客之複數個訊息及自該複數個訊息提取用於至少一個出貨之出貨資訊。該提取包括獲得對應於該複數個訊息中之給定訊息之數位內容及自數位內容獲得用於網頁資源之URL。該方法亦包括基於該URL及該網頁資源判定用於出貨之出貨資訊。該出貨資訊包括該網頁資源用於追蹤出貨之指示、用於該出貨之追蹤編號及用於該出貨之出貨供應商中之至少一者。該方法進一步包括將用於獲得用於該出貨之追蹤更新之該出貨資訊儲存於記憶體中。

該出貨資訊可用於獲得用於該至少一個出貨之追蹤更新。可提供該等追蹤更新以用於呈現針對該顧客之產品出貨之彙總概觀。

出貨資訊可以數個不同方式中之任一者自URL及網頁資源判定。在一些實施例中，判定出貨資訊包括藉由剖析URL判定追蹤編號及出貨供應商，及藉由剖析網頁資源確認追蹤編號及出貨供應商。在一些實施例中，判定出貨資訊包括藉由剖析URL判定追蹤編號及出貨供應商中之一者，及藉由剖析網頁資源判定追蹤編號及出貨供應商中之另一者。在一些實施例中，判定出貨資訊包括藉由剖析網頁資源判定追蹤編號及出貨供應商。

可實施機器學習(ML)模型以幫助判定出貨資訊。此等ML模型中之任一者、一者、一些或全部可為多任務學習(MTL)模型。在一些實施例中，判定出貨資訊包括將URL輸入至ML模型中，及基於ML模型之輸出自URL獲得對應於追蹤編號之文字串。判定出貨資訊可進一步包括獲得預測，該預測包含對應於URL中追蹤編號之開始的第一索引及對應於URL中追蹤編號之結束的第二索引，及將該第一索引及該第二索引輸入至ML模型中。

在一些實施例中，判定出貨資訊包括將URL輸入至ML模型中，及自ML模型之輸出獲得對應於自預定義出貨供應商之集合選擇的出貨供應商的文字串。

在一些實施例中，多個URL可自訊息之數位內容獲得。舉例而言，該方法可進一步包括自數位內容獲得用於第二網頁資源之第二URL。該方法亦可包括基於第二URL及第二網頁資源判定第二網頁資源用於追蹤出貨、用於出貨之第二追蹤編號及用於出貨之第二出貨供應商。第一URL及第二URL可係關於同一出貨。因此，該方法可進一步包括判定第一追蹤編號與第二追蹤編號匹配且第一出貨供應商與第二出貨供應商匹配。

在一些實施例中，該方法進一步包括基於數位內容判定訊息係關於追蹤出貨之步驟。此步驟可包括將數位內容輸入至ML模型中；自ML模型之輸出獲得自預定義訊息類別之集合選擇的訊息之訊息類別；以及判定訊息類別係關於出貨追蹤。此步驟亦可或替代地包括將URL輸入至ML模型中；自ML模型之輸出獲得自預定義URL類別之集合選擇的URL之URL類別；以及判定URL類別係關於出貨追蹤。

在一些實施例中，訊息對應於特定使用者。該方法可包括將出貨資訊儲存於用於與特定使用者相關聯之複數個出貨之出貨資訊記錄中。此記錄可由使用者檢視。因而，該方法可進一步包括輸出該出貨資訊記錄之至少一部分以用於顯示於與該特定使用者相關聯之裝置上。

根據本發明之另一態樣，提供一種系統，其包括用以儲存出貨資訊之記憶體及用以執行如本文中所揭示之任何方法之一或多個處理器。

根據本發明之另一態樣，提供一種電腦可讀媒體，其儲存指令，該等指令在由電腦系統之處理器執行時使得電腦系統執行本文中所揭示之任何方法。

根據本發明之另一態樣，提供一種電腦程式，其在執行於電腦之處理器上時經組態以進行本文中所揭示之任何方法。

因此，提供一種如以下申請專利範圍中詳述之方法、系統及電腦程式。

出於說明性目的，現將結合圖式在下文更詳細地解釋特定實例實施例。實例電子商務平 台

在一些實施例中，本文中所揭示之方法可以在商務平台上執行或與該商務平台相關聯地執行，該商務平台在本文中將稱為電子商務平台。因此，將描述電子商務平台之實例。

圖1說明根據一個實施例之電子商務平台100。電子商務平台100可用於將商家產品及服務提供給顧客。雖然本發明涵蓋使用設備、系統及程序來購買產品及服務，但為簡單起見，本文中之描述將係指產品。貫穿本發明之產品之所有參考亦應被理解為對產品及/或服務之參考，包括實體產品、數位內容、票券、訂用、待提供服務及其類似者。

雖然本發明通篇涵蓋「商家」及「顧客」可以不僅僅係個體，但為簡單起見，本文中之描述通常可以這樣引用商家及顧客。貫穿本發明之商家及顧客之所有參考亦應被理解為對個體、公司、有限公司、計算實體及其類似者之群組之參考，且可表示產品之營利性或非營利性交換。此外，雖然本發明通篇指代「商家」及「顧客」且因而描述其角色，但電子商務平台100更一般而言應理解為在電子商務環境下支援使用者，且貫穿本發明之商家及顧客之所有參考亦應被理解為參考使用者，諸如其中使用者為商家使用者(例如，產品之賣方、零售商、批發商或供應商)；顧客使用者(例如，產品之買方、購買代理或使用者)；預期使用者(例如，正瀏覽而尚未承諾購買之使用者、評估電子商務平台100在營銷及出售產品方面之可能使用之使用者及其類似者)；服務供應商使用者(例如，出貨供應商112、財務供應商及其類似者)；公司或有限公司使用者(例如，代表產品之購買、銷售或使用之公司，企業使用者，顧客關係或顧客管理代理及其類似者)；資訊技術使用者；計算實體使用者(例如，用於產品之購買、銷售或使用之計算網路執行重複功能程式)；及其類似者。

電子商務平台100可提供集中式系統以用於向商家提供線上資源及設施以管理其業務。本文中所描述之設施可經由機器部分或整體地部署，該機器在可為平台100之部分或在平台外部之一或多個處理器上執行電腦軟體、模組、程式碼及/或指令。商家可諸如藉由經由線上商店138、經由管道110A至110B、經由實體位置中之POS裝置152 (例如，實體店面或其他位置，諸如經由查詢一體機、終端機、讀取器、印表機、3D印表機及其類似者)實施與顧客之電子商務體驗；藉由經由電子商務平台100管理其業務；及藉由經由電子商務平台100之通信設施129與顧客互動或其任何組合而利用電子商務平台100管理與顧客之商務。商家可以利用電子商務平台100作為唯一與顧客進行交易的商務存在，或將之與其他商家商務設施結合，諸如經由實體商店(例如，「傳統實體」零售商店)、商家平台外網站104 (例如，由商家或代表商家獨立於電子商務平台給予支援的商務網際網路網站或其他網際網路或網頁財產或資產)，及其類似者。然而，甚至此等「其他」商家商務設施可以併入至電子商務平台中，諸如商家之實體商店中的POS裝置152連結至電子商務平台100的情況，商家平台外網站104諸如經由將來自商家平台外網站104之內容連結至線上商店138的「購買按鈕」連接至電子商務平台100的情況，及其類似者。

線上商店138可以表示包含複數個虛擬店面的多租戶設施。在實施例中，商家可諸如經由商家裝置102 (例如，電腦、膝上型電腦、行動計算裝置及其類似者)管理線上商店138中之一或多個店面，且經由數個不同管道110A至110B (例如，線上商店138；經由POS裝置152之實體店面；電子市場，經由整合至網站或社交媒體管道中之電子購買按鈕，諸如在社交網路、社交媒體頁面、社交媒體傳訊系統上；及其類似物)將產品供應給顧客。商家可跨越管道110A至110B出售且接著經由電子商務平台100管理其銷售，其中管道110A可提供在電子商務平台100內部或自電子商務管道110B外部提供。商家可在其實體零售商店中、在彈出窗口處、經由批發、經由電話及其類似者出售，且接著經由電子商務平台100管理其銷售。商家可採用此等者之全部或任何組合，諸如經由利用POS裝置152之實體店面維持業務，經由線上商店138維持虛擬店面，及利用通信設施129充分利用顧客互動及分析132以改良銷售之機率。貫穿本發明，術語線上商店138及店面可以同義地用來指經由電子商務平台100供應存在的商家線上電子商務，其中線上商店138可以指由電子商務平台100支援的店面的多租戶系列收藏(例如，用於複數個商家)，抑或指個別商家店面(例如，商家線上商店)。

在一些實施例中，顧客可以經由顧客裝置150 (例如，電腦、膝上型電腦、行動計算裝置及其類似者)、POS裝置152 (例如，零售裝置、查詢一體機、自動化結帳系統及其類似者)或此項技術中已知的任何其他商務介面裝置進行互動。電子商務平台100可以使得商家能夠經由線上商店138、經由實體位置(例如，商家店面或其他地方)中之POS裝置152接觸到顧客，能夠經由經由電子通信設施129之對話促進與顧客之商務及其類似者，以便提供接觸顧客且便於在可供用於接觸顧客並與之互動的真實或虛擬路徑中進行商家服務之系統。

在一些實施例中，且如本文中進一步描述，電子商務平台100可經由包括處理器及記憶體之處理設施實施，該處理設施儲存指令集，該指令集在執行時使得電子商務平台100執行如本文中所描述之電子商務及支援功能。處理設施可為伺服器、用戶端、網路基礎設施、行動計算平台、雲端計算平台、固定計算平台或其他計算平台之部分，且在電子商務平台100、商家裝置102、付款閘道106、應用程式開發者、管道110A至110B、出貨供應商112、顧客裝置150、銷售點裝置152及其類似者之電子組件之間及當中提供電子連接性及通信。電子商務平台100可實施為雲端計算服務、軟體即服務(SaaS)、基礎設施即服務(IaaS)、平台即服務(PaaS)、桌上型電腦即服務(DaaS)、管理軟體即服務(MSaaS)、行動後端即服務(MBaaS)、資訊技術管理即服務(ITMaaS)及其類似者，諸如在軟體基於訂用授權且集中代管(例如，由使用者使用用戶端(例如，精簡型用戶端)經由網頁瀏覽器或其他應用程式存取、藉由POS裝置存取及其類似者)之軟體及交付模型中。在一些實施例中，電子商務平台100之元件可經實施以在各種平台及操作系統上操作，諸如iOS、安卓、在網頁上及其類似者(例如，針對iOS、安卓及網頁之給定線上商店，管理員114實施於多個例項中，各自具有類似功能性)。

在一些實施例中，線上商店138可經由由電子商務平台100之伺服器提供之網頁為顧客裝置150服務。伺服器可自安裝在顧客裝置150上的瀏覽器或其他應用程式接收對網頁的請求，其中瀏覽器(或其他應用程式)經由IP位址連接至伺服器，該IP位址藉由轉譯網域名稱獲得。反過來，伺服器發送回所請求之網頁。網頁可以超文字標示語言(HTML)、模板語言、JavaScript及其類似者或其任何組合來撰寫或包括超文字標示語言(HTML)、模板語言、JavaScript及其類似者或其任何組合。舉例而言，HTML為描述網頁之靜態資訊(諸如，網頁之佈局、格式及內容)的電腦語言。網站設計者及開發者可使用模板語言來建構組合靜態內容(其在多個頁面上相同)與動態內容(其在頁面之間發生改變)之網頁。模板語言可使得有可能再次使用界定網頁之佈局的靜態元素，同時運用來自線上商店之資料動態地填充頁面。靜態元素可以HTML撰寫，且動態元素以模板語言撰寫。檔案中之模板語言元素可充當定位符號，使得編譯檔案中之程式碼且將其發送至顧客裝置150，且接著諸如在安裝主題時，用來自線上商店138之資料替換模板語言。模板及主題可考慮標籤、物件及篩選器。用戶端裝置網頁瀏覽器(或其他應用程式)接著相應地呈現頁面。

在一些實施例中，線上商店138可藉由電子商務平台100為顧客服務，其中顧客可瀏覽及購買可用之各種產品(例如，將其新增至購物車，立即經由購買按鈕購買及其類似者)。線上商店138可以透明方式為顧客服務，而顧客不必知曉其係經由電子商務平台100 (而非直接自商家)提供。商家可使用商家可組態網域名稱、可自訂HTML主題及其類似者以自訂其線上商店138。商家可經由主題系統自訂其網站之觀感，該主題系統諸如商家可以藉由改變其主題來選擇及改變其線上商店138之觀感，同時在線上商店的產品階層內展示相同的底層產品及業務資料的主題系統。主題可另外經由主題編輯器來自訂，該主題編輯器係能夠讓使用者靈活自訂其網站設計的設計介面。亦可使用改變態樣(諸如特定色彩、字體及預建構之佈局方案)之主題特定設定來自訂主題。線上商店可實施用於網站內容之內容管理系統。商家可編寫部落格文章或靜態頁面且將其發佈至其線上商店138，諸如經由部落格、文章及其類似者，以及組態導覽選單。商家可以上傳影像(例如，產品之影像)、視訊、內容、資料及其類似者至電子商務平台100，以供諸如由系統儲存(例如，儲存成資料134)。在一些實施例中，電子商務平台100可提供用於對影像調整大小、使影像與產品相關聯、使文字與影像相加及相關聯、新增用於新產品變體之影像、保護影像及其類似者的功能。

如本文中所描述，電子商務平台100可經由數個不同管道110A至110B (包括線上商店138)經由電話以及經由如本文中所描述之實體POS裝置152向商家提供用於產品之交易設施。電子商務平台100可包括與執行線上業務相關聯之業務支援服務116、管理員114及其類似者，諸如提供與其線上商店相關聯之網域服務118、用於促進與顧客之交易的付款服務120、用於為所購買產品提供顧客出貨選項之出貨服務122、與產品保護及可靠性相關聯之風險及保險服務124、商家發票資訊及其類似者。服務116可以經由電子商務平台100提供或與外部設施相關聯地提供，諸如經由用於付款處理之付款閘道106、用於催查產品之出貨的出貨供應商112及其類似者。

在一些實施例中，電子商務平台100可提供整合式出貨服務122 (例如，經由電子商務平台出貨設施或經由第三方出貨運營商)，諸如為商家提供即時更新、追蹤、自動速率計算、大宗訂單準備、標籤列印及其類似者。

圖2描繪管理員114之首頁的非限制性實施例，其可展示關於每日任務、商店之近期活動及商家可採取以建構其業務之隨後步驟的資訊。在一些實施例中，商家可經由商家裝置102 (諸如，自桌上型電腦或行動裝置)登錄至管理員114，且管理其線上商店138之態樣(諸如，檢視線上商店138之近期活動，更新線上商店138之目錄，管理訂單、近期造訪活動、全部訂單活動及其類似者)。在一些實施例中，商家可能夠藉由使用側邊欄(諸如圖2上所示之側邊欄)來存取管理員114之不同區段。管理員114之區段可以包括用於存取及管理商家業務之核心態樣(包括訂單、產品、顧客、可行性報告及折扣)的各種介面。管理員114亦可包括用於管理商店(包括線上商店)之銷售管道、可讓顧客存取商店的行動應用程式(Mobile App)、POS裝置及/或購買按鈕的介面。管理員114亦可包括用於管理安裝於商家帳戶上之應用程式(App)；應用於商家線上商店138及帳戶之設定的介面。商家可使用搜尋列以尋找產品、頁面或其他資訊。取決於商家正使用之裝置102或軟體應用程式，其可經由管理員114針對不同功能性而啟用。舉例而言，若商家自瀏覽器登錄至管理員114，則其可能夠管理其線上商店138之所有態樣。若商家自其行動裝置登錄(例如，經由行動應用程式)，則其可能夠檢視其線上商店138之態樣的全部或子集，諸如檢視線上商店138之近期活動、更新線上商店138之目錄、管理訂單及其類似者。

可經由收購報告或指標檢視關於商家線上商店138之商務及訪客之更詳細資訊，諸如顯示針對商家完整業務之銷售概觀、針對主動銷售管道之特定銷售及預約資料及其類似者。報告可包括收購報告、行為報告、顧客報告、財務報告、營銷報告、銷售報告、自訂報告及類似者。商家可能夠諸如藉由使用下拉選單檢視不同時間段(例如，天、週、月及其類似者)的不同管道110A至110B之銷售資料。可為希望獲得商店之銷售及預約資料的更詳細視圖的商家提供概觀儀錶盤。可以提供首頁指標區段中之活動提要以說明商家帳戶上之活動的概觀。舉例而言，藉由點擊「檢視所有近期活動」儀錶盤按鈕，商家可能夠看見其帳戶上近期活動的較長提要。首頁可以展示關於商家線上商店138的通知，諸如基於帳戶狀態、成長、近期顧客活動及其類似者。通知可經提供以輔助商家經由程序導覽，諸如捕捉付款、將訂單標記為已完成、存檔完成之訂單及其類似者。

電子商務平台100可以提供通信設施129及相關聯的商家介面，以用於提供電子通信及營銷，諸如利用電子傳訊聚合設施來收集及分析商家、顧客、商家裝置102、顧客裝置150、POS裝置152及其類似者之間的通信互動，以聚合及分析通信，諸如用於提高用於提供產品之出售之可能性，及其類似者。舉例而言，顧客可具有與產品相關之問題，這可在顧客與商家(或表示商家之自動化基於處理器之代理)之間產生對話，其中通信設施129分析互動且向商家提供關於如何改良銷售機率之分析。

電子商務平台100可以提供用於諸如經由安全的卡伺服器環境與顧客進行安全財務交易的財務設施120。電子商務平台100可儲存信用卡資訊，諸如在付款卡行業資料(payment card industry，PCI)環境(例如，卡伺服器)中，以核對財務、為商家計費、在電子商務平台100財務機構帳戶與商家銀行帳戶之間執行自動票據交換所(automated clearing house，ACH)轉帳(例如，當使用資金時)，及其類似者。此等系統可符合薩班斯-奧克斯利法案(Sarbanes-Oxley Act，SOX)且在開發及操作中需要高度的努力。財務設施120亦可為商家提供財務支援，諸如經由資金借貸(例如，借貸資金、現金預付款及其類似者)及保險的提供。另外，電子商務平台100可提供營銷與合作夥伴服務之集合且控制電子商務平台100與合作夥伴之間的關係。其亦可藉由電子商務平台100連接並內建新商家。此等服務可藉由使商家更易於在電子商務平台100上工作而實現商家成長。經由此等服務，商家可經由電子商務平台100提供幫助設施。

在一些實施例中，線上商店138可以支援大量獨立管理的店面且每天處理多種產品的大量交易資料。交易資料可包括顧客聯繫資訊、發票資訊、出貨資訊、關於所購買產品之資訊、關於所呈現服務之資訊及經由電子商務平台100與業務相關聯之任何其他資訊。在一些實施例中，電子商務平台100可以將此資料儲存於資料設施134中。交易資料可經處理以產生分析132，該分析又可提供至商家或第三方商務實體，諸如提供消費者趨勢、營銷及銷售洞察、用於改良銷售之推薦、顧客行為之評估、營銷及銷售模型化、詐騙趨勢及其類似者，與線上商務相關；且經由儀錶盤介面、經由報告及類似者提供。電子商務平台100可儲存關於業務及商家交易之資訊，且資料設施134可具有增強、促成、細化及提取資料之許多方式，其中隨時間推移，所收集資料可實現對電子商務平台100之態樣的改良。

再次參考圖1，在一些實施例中，電子商務平台100可組態有商務管理引擎136以用於內容管理、任務自動化及資料管理以實現對複數個線上商店138之支援及服務(例如，與產品、庫存、顧客、訂單、協作、供應商、報告、財務、風險與詐騙及其類似者相關)，但可經由實現用於適應不斷成長之各種商家線上商店、POS裝置、產品及服務所需的較高靈活性及自訂程序的應用程式142A至142B擴展，其中應用程式142A可提供在電子商務平台100內部或應用程式142B來自電子商務平台100外部。在一些實施例中，應用程式142A可由提供平台100之同一方或由不同方提供。在一些實施例中，應用程式142B可由提供平台100之同一方或由不同方提供。商務管理引擎136可經組態以用於經由諸如藉由顧客識別符、訂單識別符、線上商店識別符及其類似者劃分(例如，分片)功能及資料之靈活性及可擴展性。商務管理引擎136可以適應商店特定業務邏輯，且在一些實施例中，可以併有管理員114及/或線上商店138。

商務管理引擎136包括電子商務平台100之基礎或「核心」功能，且因而，如本文中所描述，並非可適合於包括支援線上商店138之所有功能。舉例而言，用於包括至商務管理引擎136中之功能可能需要超過核心功能性臨限值，由此可判定功能對於商務體驗(例如，大部分線上商店活動共同的，諸如跨越管道、管理員介面、商家位置、行業、產品類型及其類似者)為核心的；可跨越線上商店138重複使用(例如，可跨越核心功能重複使用/修改之功能)，每次限於單一線上商店138之上下文(例如，實施線上商店「隔離原則」，其中程式碼每次不應能夠與多個線上商店138互動，從而確保線上商店138無法存取彼此之資料)；提供交易工作量；及其類似者。維持實施何功能之控制可使得商務管理引擎136能夠保持回應性，此係因為許多所需特徵直接由商務管理引擎136服務或經由介面140A至140B (諸如藉由其經由連接至應用程式142A至142B及管道110A至110B之應用程式設計介面(API)的擴展)而實現，其中介面140A可提供至電子商務平台100內部之應用程式142A及/或管道110A或經由介面140B提供至電子商務平台100外部之應用程式142B及/或管道110B。一般而言，平台100可包括促進至其他平台、系統、軟體、資料源、程式碼及其類似者之連接及與其他平台、系統、軟體、資料源、程式碼及其類似者之通信的介面140A至140B (其可為擴展、連接器、API及其類似者)。更一般而言，此等介面140A至140B可為商務管理引擎136之介面140A或平台100之介面140B。若不注意限制商務管理引擎136中之功能性，則回應性可受損，諸如經由緩慢資料庫或非關鍵後端故障之基礎設施劣化、經由災難性基礎設施故障(諸如，在資料中心離線的情況下)、經由經部署以比預期花費更長時間執行的新程式碼及其類似者。為防止或減少此等情形，商務管理引擎136可經組態以維持回應性，諸如經由利用逾時、佇列、用於防止劣化之背壓及其類似者的組態。

儘管隔離線上商店資料對於維持線上商店138與商家之間的資料私密性很重要，但收集及使用跨商店資料仍有其原因，諸如對於訂單風險評估系統或平台付款設施而言，它們皆需要多個線上商店138中之資訊才能很好地執行。在一些實施例中，將此等組件移出商務管理引擎136且移至電子商務平台100內之其自身基礎設施中可為較佳的，而非違反隔離原理。

在一些實施例中，電子商務平台100可提供平台付款設施120，該平台付款設施為利用來自商務管理引擎136之資料但可位於外部以免違反隔離原理的組件之另一實例。平台付款設施120可以允許顧客與線上商店138互動，以使其付款資訊由商務管理引擎136安全地儲存，這樣顧客便僅需輸入付款資訊一次。當顧客造訪不同的線上商店138時，即使顧客之前從未去過此處，平台付款設施120仍可重新呼叫其資訊以實現更迅速且正確的結帳。此舉可以提供跨平台網路效應，其中隨著更多商家的加入，電子商務平台100變得對其商家更有用，諸如因為有更多的顧客由於顧客購買時的易用性而更頻繁地結帳。為了最大化此網路之效應，給定顧客之付款資訊可自線上商店之結帳擷取，從而允許跨越線上商店138全域地得到資訊。每一線上商店138能夠連接至任何其他線上商店138以擷取儲存於此處之付款資訊將係困難的且容易出錯。因此，平台付款設施可實施於商務管理引擎136外部。

對於不包括於商務管理引擎136內之彼等功能，應用程式142A至142B提供將特徵新增至電子商務平台100的方式。應用程式142A至142B可能夠存取及修改商家線上商店138上之資料，經由管理員114執行任務，經由使用者介面(例如，以擴展方式呈現/API)建立商家的新流程，及其類似者。可以使得商家能夠經由應用程式搜尋、推薦及支援128發現及安裝應用程式142A至142B。在一些實施例中，可開發核心產品、核心擴展點、應用程式及管理員114以共同工作。舉例而言，應用程式擴展點可在管理員114內部建構，使得核心特徵可藉助於應用程式擴展，這可經由擴展將功能性遞送至商家。

在一些實施例中，應用程式142A至142B可以經由介面140A至140B向商家遞送功能性，諸如應用程式142A至142B能夠將交易資料呈現給商家(例如，App：「引擎，使用嵌入式app SDK在行動及網頁管理員中呈現我的app資料」)的情形，及/或商務管理引擎136能夠要求應用程式按照需求執行工作(引擎：「App，將此結帳的地方稅計算值給我」)的情形。

應用程式142A至142B可支援線上商店138及管道110A至110B，供應商家支援、與其他服務整合及其類似者。在商務管理引擎136可將服務基礎提供至線上商店138之情況下，應用程式142A至142B可為商家提供滿足特定及有時獨特需要之方式。不同商家將具有不同需求，且因此可得益於不同應用程式142A至142B。應用程式142A至142B可經由電子商務平台100經由開發應用程式分類(類別)，該應用程式分類(類別)使應用程式能夠根據其針對商家執行之功能的類型而標記；經由支援搜尋、排名及推薦模型之應用程式資料服務；經由諸如應用程式商店、家庭資訊卡、應用程式設定頁面之應用程式發現介面；及其類似者而較佳地發現。

應用程式142A至142B可經由介面140A至140B連接至商務管理引擎136，諸如利用API以將經由商務管理引擎136及在商務管理引擎136內可用的功能性及資料曝露於應用程式之功能性(例如，經由REST、GraphQL及其類似者)。舉例而言，電子商務平台100可將API介面140A至140B提供至商家及面向合作夥伴之產品及服務，諸如包括應用程式擴展、程序流程服務、面向開發者之資源及其類似者。隨著顧客較頻繁地使用行動裝置購物，與行動用途相關之應用程式142A至142B可得益於更廣泛地使用API來支援相關的不斷成長之商務流量。經由使用應用程式及API供應之靈活性(例如，如針對應用程式開發所供應)使得電子商務平台100能夠較佳地適應商家(及經由內部API之內部開發者)之新的及獨特的需求，而無需對商務管理引擎136作出持續改變，因此當顧客需要時提供其需要之商家。舉例而言，出貨服務122可經由出貨或承運人服務API與商務管理引擎136整合，因此使得電子商務平台100能夠提供出貨服務功能性而不會直接影響在商務管理引擎136中執行之程式碼。

許多商家問題可藉由使合作夥伴經由應用程式開發改良及擴展商家工作流程來解決，諸如與後台辦公室操作(面向商家之應用程式142A至142B)及線上商店138 (面向顧客之應用程式142A至142B)相關聯之問題。作為進行中業務之一部分，許多商家將每天使用行動及網頁相關應用程式用於後台辦公室任務(例如，商品銷售、庫存、折扣、倉儲物流及其類似者)及線上商店任務(例如，與其網上商店、限時搶購、新產品供應及其類似者相關之應用程式)，其中應用程式142A至142B經由擴展/API 140A至140B有助於使得產品在快速成長之市場中易於檢視及購買。在一些實施例中，合作夥伴、應用程式開發者、內部應用程式設施及其類似者可具備軟體開發套組(SDK)，諸如經由在管理員114內建立使應用程式介面產生沙盒效應之圖框。在一些實施例中，管理員114可不控制亦不知曉圖框內發生之情形。SDK可結合使用者介面套組使用以產生模擬電子商務平台100之外觀及感覺的介面，諸如充當商務管理引擎136之擴展。

利用API之應用程式142A至142B可按需提取資料，但當更新出現時其常常亦需要推送資料。更新事件可實施於訂用模型中，諸如顧客建立、產品改變或訂單取消。更新事件可向商家提供關於商務管理引擎136之已改變狀態的所需更新，諸如用於同步本端資料庫、通知外部整合合作夥伴及其類似者。更新事件可實現此功能性而不必始終輪詢商務管理引擎136以檢查更新，諸如經由更新事件訂用。在一些實施例中，當發生與更新事件訂用相關之改變時，商務管理引擎136可發佈請求，諸如發佈至預定義回呼URL。此請求之本體可含有物件之新狀態及動作或事件之描述。更新事件訂用可在管理員設施114中人工地或自動地(例如，經由API 140A志140B)建立。在一些實施例中，可自觸發事件之狀態改變非同步地將更新事件排入佇列並處理，此可產生未即時分配之更新事件通知。

在一些實施例中，電子商務平台100可提供應用程式搜尋、推薦及支援128。應用程式搜尋、推薦及支援128可包括用以輔助應用程式開發之開發者產品及工具；應用程式儀錶盤(例如，以向開發者提供開發介面，使管理員管理應用程式、使商家自訂應用程式及其類似者)；用於安裝及提供關於提供對應用程式142A至142B之存取的權限的設施(例如，用於公共存取，諸如在安裝之前必須滿足標準的情況；或用於藉由商家進行之私用用途)；應用程式搜尋，其使得商家容易搜尋滿足其線上商店138之需求的應用程式142A至142B；應用程式推薦，其向商家提供其可如何經由其線上商店138改良用戶體驗之建議；商務管理引擎136內之核心應用程式能力之描述及其類似者。此等支援設施可藉由任何實體執行之應用程式開發利用，包括使商家開發其自身應用程式142A至142B、使第三方開發者開發應用程式142A至142B (例如，由商家簽約，自行開發以供應給大眾，經簽約以供與電子商務平台100結合及其類似者)或由與電子商務平台100相關聯之內部個人資源開發應用程式142A或142B。在一些實施例中，應用程式142A至142B可經指派應用程式識別符(ID)，諸如用於鏈接至應用程式(例如，經由API)、搜尋應用程式、進行應用程式推薦及其類似者。

商務管理引擎136可包括電子商務平台100之基礎功能，且經由API 140A至140B將此等功能曝露於應用程式142A至142B。API 140A至140B可實現經由應用程式開發而建構的不同類型之應用程式。應用程式142A至142B可能夠滿足對商家之大量需求，但可粗略地分組為三個類別：面向顧客之應用程式、面向商家之應用程式、整合應用程式及其類似者。面向顧客之應用程式142A至142B可包括為商家可列出產品且購買產品之地方的線上商店138或管道110A至110B (例如，線上商店、用於限時搶購之應用程式(例如，商家產品或來自第三方來源之機會性銷售機會)、行動商店應用程式、社交媒體管道、用於提供批發購買之應用程式及其類似者)。面向商家之應用程式142A至142B可包括允許商家管理其線上商店138 (例如，經由與網頁或網站相關或與行動裝置相關之應用程式)、執行其業務(例如，經由與POS裝置相關之應用程式)、成長其業務(例如，經由與出貨(例如，直運)、自動代理之使用、程序流程開發及改良之使用相關之應用程式)及其類似者的應用程式。整合應用程式可包括提供參與執行諸如出貨供應商112及付款閘道之業務的有用整合的應用程式。

在一些實施例中，應用程式開發者可使用應用程式代理自外部位置提取資料且在線上商店138之頁面上顯示資料。此等代理頁面上之內容可為動態的、能夠被更新，及其類似者。應用程式代理可能適用於顯示影像圖庫、統計資料、自訂形式及其他類型之動態內容。電子商務平台100之核心應用程式結構可允許在應用程式142A至142B中建構逐漸增加數目個商家體驗，使得商務管理引擎136可保持集中於商務之較常用業務邏輯。

電子商務平台100經由策展系統架構提供線上購物體驗，該策展系統架構使得商家能夠以靈活且透明的方式與顧客連接。可經由實施例實例購買工作流程較佳地理解典型顧客體驗，在該工作流程中顧客瀏覽管道110A至110B上之商家產品、將其意欲購買之物品新增至其購物車、進行結帳，且支付其購物車之內容，從而使得建立商家之訂單。商家可接著審查並履行(或取消)訂單。產品接著被遞送至顧客。若顧客不滿意，則顧客可將產品退回至商家。

在實例實施例中，顧客可瀏覽管道110A至110B上之商家產品。管道110A至110B為顧客可檢視及購買產品之場所。在一些實施例中，管道110A至110B可模型化為應用程式142A至142B (可能的例外為線上商店138，其整合於商務管理引擎136內)。商品銷售組件可允許商家描述他們想要出售什麼以及在哪裡出售。產品與管道之間的相關性可經模型化為產品出版物且由管道應用程式，諸如經由產品清單API存取。產品可具有許多選項，如尺寸及顏色，及將可用選項擴展為所有選項之特定組合的許多變體，如特小且綠色之變體，或大尺寸且藍色之變體。產品可具有至少一個變體(例如，對無任何選項之一產品建立一「預設變體」)。為了協助瀏覽及管理，產品可分組為系列收藏、提供產品識別符(例如，庫存計量單位(SKU))及其類似者。可藉由將產品人工分類成一個系列收藏(例如，自訂系列收藏)、藉由建構用於自動分類(例如，智慧型系列收藏)之規則集及其類似者來建構產品之系列收藏。產品可被視為2D影像、3D影像、旋轉視圖影像、透過虛擬或擴增實境介面檢視等等。

在一些實施例中，顧客可將其意欲購買之物品新增至其購物車(在替代實施例中，產品可直接購買，諸如經由如本文中所描述之購買按鈕)。顧客可將產品變體新增至其購物車。購物車模型可為管道特定的。線上商店138購物車可由多個購物車行式項目(line item)構成，其中每一購物車行式項目追蹤產品變體之數量。商家可使用購物車腳本來基於其購物車之內容向顧客供應特殊促銷。由於將產品新增至購物車並不暗示來自顧客或商家之任何承諾，且購物車之預期壽命可為約數分鐘(而非數日)之等級，所以購物車可存留至暫時資料儲存區。

顧客接著進行結帳。結帳組件可實施網頁結帳以作為面向顧客之訂單建立程序。結帳API可提供為由一些管道應用程式使用以代表顧客建立訂單(例如，用於銷售點)的面向電腦之訂單建立程序。結帳單可自購物車建立且記錄顧客之資訊，諸如電子郵件位址、發票資訊及出貨細節。在結帳時，商家承諾定價。若顧客輸入其連絡資訊但並不進行付款，則電子商務平台100可向顧客提供重新預約機會(例如，在一丟棄結帳特徵中)。出於彼等原因，結帳單可具有比購物車長得多的壽命(數小時或甚至數天)且因此存留。結帳單可基於顧客之出貨位址而計算稅及出貨成本。結帳可將稅之計算委託至計稅組件且將出貨成本之計算委託至交付組件。定價組件可使得商家能夠建立折扣碼(例如，在鍵入於結帳上時將新價格應用至結帳中之項目的「秘密」字符串)。折扣可由商家使用以吸引顧客且評估營銷活動之效能。折扣及其他自訂價格系統可諸如經由價格規則實施於同一平台件之頂部上(例如，在滿足時暗示一組權利的先決條件之集合)。舉例而言，先決條件可為諸如「訂單小計大於$100」或「出貨成本低於$10」等項目，且權利可為諸如「整個訂單之20%折扣」或「產品X、Y及Z優惠$10」等項目。

顧客接著支付其購物車之內容，從而使得建立對於商家之訂單。管道110A至110B可使用商務管理引擎136將金錢、貨幣或價值貯藏(諸如美元或密碼貨幣)移動至顧客及商家及自顧客及商家移動。與各種付款供應商(例如，線上付款系統、行動付款系統、數位電子錢包、信用卡閘道器及其類似者)之通信可實施於付款處理組件內。可經由卡片伺服器環境提供與付款閘道106之實際互動。在一些實施例中，付款閘道106可接受國際付款，諸如與主要的國際信用卡處理器整合。卡伺服器環境可包括卡伺服器應用程式、卡槽、代管欄位及其類似者。此環境可充當敏感信用卡資訊之安全網守。在一些實施例中，大部分程序可藉由付款處理作業編排。商務管理引擎136可諸如經由廠外付款閘道106 (例如，其中顧客經重新引導至另一網站)、人工地(例如，現金)、線上付款方法(例如，線上付款系統、行動付款系統、數位電子錢包、信用卡閘道器及其類似者)、禮品卡及其類似者支援許多其他付款方法。在結帳程序結束時，建立訂單。訂單為商家與顧客之間的銷售合約，其中商家同意提供訂單上列出之商品及服務(例如，訂單行式項目、出貨行式項目及其類似者)，且顧客同意提供付款(包括稅)。此程序可在銷售組件中模型化。不依賴於商務管理引擎136結帳之管道110A至110B可使用訂單API來建立訂單。一旦建立訂單，則可將訂單確認通知發送至顧客且經由通知組件將訂單已下通知發送至商家。在付款處理作業開始時，可預訂庫存以避免過度出售(例如，商家可自每一變體之庫存策略控制此行為)。庫存預訂可具有短時間間隔(分鐘)且可能需要非常快速且可縮放以支援限時搶購(例如，短時間內供應的折扣或促銷，諸如針對衝動性購買)。若付款失敗，則釋放預訂。當付款成功且建立訂單時，預訂轉換成分配至特定位置之長期庫存承諾。庫存組件可記錄變體存放之處，且追蹤啟用庫存追蹤之變體的數量。其可將產品變體(表示產品清單之模板的面向顧客之概念)與庫存項目(表示數量及位置受管理之項目的面向商家之概念)解耦。庫存等級組件可追蹤可供用於銷售、承諾給訂單或自庫存轉移組件(例如，自供應商)傳入之數量。

商家可接著審查並履行(或取消)訂單。審查組件可實施業務程序商家之使用以確保訂單在實際上履行之前適合於履行。訂單可為詐騙性的，需要驗證(例如，ID檢查)，具有需要商家等待確保其將接收其資金之付款方法，及其類似者。風險及推薦可存留在訂單風險模型中。訂單風險可由詐騙偵測工具產生，藉由第三方經由訂單風險API提交，及其類似者。在進行履行之前，商家可能需要捕捉付款資訊(例如，信用卡資訊)或等待接收付款資訊(例如，經由銀行轉帳、檢查及其類似者)及將訂單標記為已支付。商家現可準備用於交付之產品。在一些實施例中，此業務程序可藉由履行組件實施。履行組件可基於庫存位置及履行服務而將訂單之行式項目分組成工作之邏輯履行單元。商家可審查，調整工作單元，且諸如經由當商家選取且將產品包裝於盒中時使用之人工履行服務(例如，在商家管理之位置處)觸發相關履行服務，購買出貨標籤且輸入其追蹤編號，或僅將項目標記為已履行。自訂履行服務可發送電子郵件(例如，不提供API連接之位置)。API履行服務可觸發第三方，其中第三方應用程式建立履行記錄。舊式履行服務可觸發自商務管理引擎136至第三方之自訂API呼叫(例如，藉由Amazon之履行)。禮品卡履行服務可提供(例如，產生編號)及激活禮品卡。商家可使用訂單印表機應用程式來列印裝箱單。可在物品包裝於盒中且準備好出貨、運送、追蹤、交付、在由顧客接收到時驗證及其類似者時執行履行程序。

若顧客不滿意，則顧客可能夠將產品退回至商家。業務程序商家可「取消出售」，項目可藉由退回組件實施。退回可由各種不同的動作組成，例如補貨，其中實際上出售之產品返回至業務中並可再次出售；退款，部分或全部退還自顧客處收取之金額；註明退款金額的會計調整(例如，包括是否存在任何補貨費用，或未退還且仍在顧客手中的貨物)；及其類似者。退回可表示銷售合約(例如，訂單)之改變，且其中電子商務平台100可使商家瞭解關於合法義務(例如，關於稅)之遵從性問題。在一些實施例中，電子商務平台100可使得商家能夠追蹤銷售合約隨時間推移的改變，諸如經由銷售模型組件(例如，記錄項目發生之銷售相關事件的僅附加的基於日期之分類帳)實施。分析電子商務平台中之訊息

如上文所概述，履行顧客所下之產品之訂單可包括促進產品至顧客之出貨。舉例而言，商家可藉由經由出貨供應商112購買出貨標籤而配置此出貨。替代地，第三方可促進產品之出貨。顧客可具備用於出貨之出貨資訊，其尤其可包括出貨供應商、追蹤編號、追蹤URL、出貨狀態及/或預期交付日期。舉例而言，此出貨資訊可經由訊息，諸如電子郵件訊息、文字或短訊息服務(SMS)訊息或即時訊息提供至使用者。在一些實施中，產品資訊-亦即關於出貨中包括之產品之資訊可另外或替代地包括於出貨資訊中(例如，以允許買方識別特定出貨)。用於交付訊息之傳訊服務可由電子商務平台100支援。舉例而言，電子商務平台100可支援電子郵件傳訊服務以與顧客及/或商家通信並促進出貨資訊至顧客之交付。傳訊服務亦可或替代地由第三方支援。

將出貨資訊提供至顧客之訊息對於顧客而言可能難以組織及/或耗時的。值得注意地，提供出貨資訊之訊息可儲存於複數個訊息當中。舉例而言，提供出貨資訊之電子郵件訊息可埋入顧客之收件匣中，從而使得顧客難以在需要出貨資訊時稍後定位訊息。在另一實例中，由於缺乏用於不同類型之訊息(例如，SMS、電子郵件、聊天/IM等)之統一收件匣及/或給定類型(例如，由於用於SMS之多個電話號碼或用於電子郵件之多個電子郵件帳戶/位址)之多個收件匣，此類訊息可跨越一或多種類型之一或多個收件匣散佈且可因此難以定位。因此，需要用於自顧客(使用者)之訊息獲得及合併出貨資訊之電腦實施系統。

圖3說明圖1之電子商務平台100，但包括訊息分析引擎300。訊息分析引擎300為用於自訊息獲得出貨資訊並儲存出貨資訊之電腦實施系統之實例。藉助於實例，當顧客接收與追蹤出貨相關之電子郵件訊息時，訊息分析引擎300可自電子郵件訊息提取出貨資訊並將該出貨資訊新增至用於顧客之所有產品出貨之彙總概觀。此概觀接著可由顧客經由電子商務平台100上之其帳戶存取，從而允許顧客迅速且易於審查其出貨中之每一者的出貨供應商、追蹤編號、追蹤URL、出貨狀態及/或預期交付日期。顧客可能夠避免個別地檢視每一電子郵件訊息以獲得出貨資訊。因此，出貨資訊之彙總概觀為顧客節約時間及工作量，且尤其適用於自多個線上商店購物且同時具有許多未決產品出貨之顧客。

應注意，訊息分析引擎300不限於自訊息獲得出貨資訊。其他類型之資訊亦可或替代地自訊息獲得。舉例而言，訊息分析引擎300可經由電子商務平台100獲得及儲存(且有可能聚合)交易資料、發票資訊、關於所購買產品之資訊、關於所呈現服務之資訊，及與業務相關聯之任何其他資訊。

儘管訊息分析引擎300說明為圖3中之電子商務平台100之獨特組件，但此僅為實例。訊息分析引擎亦可或替代地由電子商務平台100之另一組件提供或作為平台100外部之獨立組件或服務供應。在一些實施例中，商務管理引擎136及/或應用程式142A提供訊息分析引擎。電子商務平台100可包括由一或多方提供之多個訊息分析引擎。多個訊息分析引擎可以相同方式、以類似方式及/或以獨特方式實施。另外，訊息分析引擎之至少一部分可實施於顧客裝置150上。舉例而言，顧客裝置150可儲存訊息分析引擎且在本端將訊息分析引擎作為軟體應用程式執行。

訊息分析引擎300可實施本文中所描述之功能性中之至少一些。儘管下文所描述的實施例可與電子商務平台(諸如但不限於電子商務平台100)相關聯地實施，但下文所描述的實施例不限於圖1至圖3之特定電子商務平台100。此外，本文中所描述之實施例未必需要與電子商務平台相關聯地實施或涉及電子商務平台。其他計算平台及裝置可實施本文中所揭示之系統及方法中之至少一些。自訊息獲得出貨資訊

自訊息準確且持續地獲得出貨資訊可為困難的。存在可用於將產品運送至顧客之大量出貨供應商、履行網路、郵政服務供應商、最後一英里交付服務及其類似者。每一商家及/或出貨供應商通常具有其自身訊息格式及追蹤編號系統。此外，數位通知可呈各種形式/屬於各種類型，諸如電子郵件訊息、文字訊息、即時訊息或其類似者。此外，無論屬於相同或不同類型，訊息之集合可均具有不同格式。因此，可含有出貨資訊之可能訊息格式之數目為巨大的。

實施用於自訊息獲得出貨資訊之確定性方法對於此數目之可能訊息格式可能並不可行。確定性方法常常使用規則之固定集合以自訊息提取出貨資訊。然而，為了準確且一致，用於自訊息獲得出貨資訊之確定性方法應主動地經組態以處置每一可能訊息格式。舉例而言，確定性方法可需要產生規則或模板之相異集合以用於使每一個別訊息格式模式匹配。可能訊息格式之數目將使此過程過度耗時。另外，不存在用於各種類型之追蹤訊息之一致採用格式。此外，此類標準化的嘗試只能看到受限制採用，在此類受限制採用中，此類標準之實施常常不一致/不正確。此外，出貨供應商正連續更新及更改其電子郵件訊息格式，且新出貨供應商、交付服務及其類似者亦頻繁地變為線上(亦即，啟動其業務)。因此，將亦需要主動地相應地更新用於自訊息獲得出貨資訊之確定性方法。

自訊息中之追蹤URL而非自訊息之全部內容獲得出貨資訊可幫助避免上述概述之確定性方法之至少一些使用。追蹤URL可引導至包括用於特定出貨之出貨資訊之網頁資源。儘管URL可僅表示訊息之全部內容之一部分，但URL自身仍可提供含於訊息中之大部分或甚至所有出貨資訊。因此，追蹤URL可用於獲得出貨資訊而無需剖析訊息之全部內容。URL亦具有可簡化用於獲得出貨資訊之分析之預定義結構。URL之結構包括方案、視情況選用之權限、路徑、視情況選用之查詢及視情況選用之片段。

方案包括後接冒號(:)的指示正使用之網頁協定的字元之字符串。方案之非限制性實例包括http 、 https 、 ftp 、 mailto 、 file 、 data 及irc 。

URL中之權限之前為兩個斜線(//)。權限可包括提供使用者名稱之視情況選用之userinfo 子組分且視需要可包括密碼、host 子組分及視情況選用之port 子組分。

路徑可將映射提供至伺服器上之特定網頁資源、檔案或目錄。路徑可包括一或多個路徑區段，其中每一路徑區段藉由斜線(/)分離。然而，路徑可替代地為空。

查詢之前為URL中之問題標記(?)且包括一或多個參數。每一參數藉由符號(&)分離。查詢可規定由網頁資源提供之內容。舉例而言，查詢可用於選擇顯示於網頁上之內容。

片段之前為散列(#)且可將方向提供至次要網頁資源。

因此，URL之結構可界定為方案 :[//權限 ]路徑 [?查詢 ][#片段 ]。舉例而言，考慮以下URL：https :// soup . myshopify . com / pages/ recipes ? param1 = x & param2 = y # borscht 。此處，方案為https ，權限為soup . myshopify . com ，路徑為pages / recipes ，查詢為param1 = x & param2 = y ，且片段為borscht 。

至少相較於訊息之全部內容，URL之結構化性質及相對短長度允許使用機率性方法以獲得出貨資訊。機率性方法基於機率分佈進行決策且通常較佳適合於涉及大量獨特輸入及對應具體輸出之問題，這可為用於自訊息獲得出貨資訊之情況。機率性方法可提供一定程度之靈活性以適應許多不同訊息格式及訊息格式的改變。

在一些實施例中，機率性方法藉由識別URL中之特定參數或語法而自URL提取出貨資訊。舉例而言，URL中之查詢參數可為country = CA & trackingId = 368927473835 ，指示出貨之目的地為加拿大且追蹤編號為368927473835。

機器學習(ML)模型為實施機率性方法之一種可能方式。然而，ML模型在運算上可為密集型且可需要大量資料來訓練。因此，使用ML模型分析較大輸入資料集合可為昂貴且耗時的。有利地，URL常常具有相對較小數目之字元(通常介於50與200之間)，較佳經結構化，且可通常相較於訊息格式以較低頻率改變(例如，在至少一些情況下至URL格式之改變可由於反向維持URL格式中之相容性之需要而受限制，而訊息之格式，諸如電子郵件本體之格式可諸如出於文體原因以較高頻率改變)，且因此較佳適合於使用ML模型分析。

除自URL獲得出貨資訊之外，出貨資訊亦可自藉由URL鏈接至或以其他方式與URL相關聯之網頁資源獲得。舉例而言，URL可鏈接至出貨供應商之網頁，其提供出貨之出貨供應商、追蹤編號、出貨狀態及/或預期交付日期。出貨資訊可藉由使用確定性方法及/或機率性方法剖析網頁資源而獲得。

分析URL及與URL相關聯之網頁資源兩者有可能增大自訊息獲得之出貨資訊之量及/或在獲得出貨資訊時提供一定程度之冗餘。舉例而言，自URL獲得之出貨資訊可藉由自與URL相關聯之網頁資源獲得之出貨資訊而確認及/或補充，且反之亦然。在一個實例中，自訊息提取之URL經分析以判定URL是否用於追蹤出貨、判定用於出貨之出貨供應商，及/或判定用於出貨之追蹤編號。自URL獲得之出貨資訊接著可藉由自與URL相關聯之網頁資源獲得之出貨資訊補充及/或確認。在另一實例中，出貨資訊自與URL相關聯之網頁資源而判定，且出貨資訊視需要經由對URL之分析而確認。

在自使用者之訊息中之一或多者獲得出貨資訊之後，出貨資訊之合併清單可針對顧客經編譯。此清單允許使用者立即迅速且容易地存取關於其未決出貨中之任一者、一些或全部之資訊。舉例而言，當使用者藉由出貨資訊接收新訊息且當出貨成功地交付給使用者時，可主動地更新出貨資訊之清單。此外，可向使用者給定更改清單之能力。舉例而言，使用者可能夠組織、新增、刪除及/或修改清單中之出貨資訊。

出貨資訊僅為可使用本文中所揭示之系統及方法自使用者之訊息獲得的一種類型之資訊。本發明亦係關於自使用者之訊息獲得其他類型之資訊。舉例而言，關於使用者線上購買之產品之資訊可自使用者之訊息獲得。可實施分析此等訊息中之URL及視需要分析與彼等URL相關聯之網頁資源以獲得使用者已線上訂購之產品之產品資訊。舉例而言，編譯此產品資訊可允許來自一個商務平台之產品推薦併入來自其他商務平台之使用者之購買。在另一實例中，其他潛在相關資料，諸如資訊可圍繞未來出貨獲得，可基於對使用者之訊息中之URL之分析而獲得。值得注意地，此類潛在相關資料可包括與即將進行的出貨相關之產品資料/資訊。另外或替代地，在至少一些情況下，此類潛在相關資訊可包括使用者之訊息中不可用之資訊/將不經由訊息傳達至使用者。另外或替代地，在至少一些情況下，潛在相關資訊可包括存在於訊息中但在呈現訊息時未展示之資訊。舉例而言，潛在相關資訊可發現於後設資料中/標記包括於訊息中。在另一實例中，潛在相關資訊在藉由某些類別之裝置/用戶端呈現訊息時可能不可見(例如，資訊僅在桌上型電腦上呈現訊息時而非在呈現訊息以用於呈現於行動裝置上時可見)。用於自訊息獲得出貨資訊之實例系統及方法

圖4為說明用於自數位訊息獲得資訊之實例系統400之方塊圖。系統400包括訊息分析引擎402、網路420及使用者裝置430。

訊息分析引擎402儲存並分析訊息以自訊息獲得資訊。所獲得資訊接著可藉由訊息分析引擎402編譯及儲存，且視需要傳輸至使用者裝置430。儘管藉由訊息分析引擎402獲得之資訊可為或包括出貨資訊，但亦涵蓋其他類型之資訊。舉例而言，關於由使用者線上購買之產品之資訊可藉由訊息分析引擎402獲得。

訊息分析引擎402之位置為實施特定的。在一些實施中，訊息分析引擎402至少部分地藉由電子商務平台提供為電子商務平台之核心功能或藉由電子商務平台支援之應用程式。舉例而言，訊息分析引擎402可為圖3之訊息分析引擎300。在一些實施中，訊息分析引擎402實施為在電子商務平台外部或至少部分地藉由使用者裝置實施之獨立組件、應用程式或服務。亦涵蓋訊息分析引擎402之其他實施。儘管訊息分析引擎402展示為單個組件，但訊息分析引擎402可替代地由例如經由網路420通信之多個不同組件提供。

訊息分析引擎402包括處理器404、記憶體406及網路介面408。處理器404可由一或多個處理器實施，該一或多個處理器執行儲存於記憶體406中或另一非暫時性電腦可讀媒體中之指令。此等指令可實施本文中所描述之任何方法。替代地，處理器404中之一些或全部可使用專用電路系統(諸如特殊應用積體電路(ASIC)、圖形處理單元(GPU)或經程式化場可程式化閘陣列(FPGA))來實施。

提供網路介面408以用於經由網路420通信。網路介面408之結構為實施特定的。舉例而言，網路介面408可包括網路介面卡(network interface card，NIC)、電腦埠(例如，插頭或電纜連接至之實體插座)及/或網路通訊端。

記憶體406儲存訊息記錄410、出貨供應商記錄412、訊息類別記錄413、URL類別記錄414、一或多個ML模型416及出貨資訊記錄418。

訊息記錄410包括經儲存以供訊息分析引擎402分析之訊息。此等訊息可包括電子郵件訊息、文字訊息、即時訊息及其類似者。音訊訊息，諸如話音郵件訊息及來自數位助理之訊息亦可包括於訊息記錄410中。在一些情況下，訊息之串列化版本儲存於訊息記錄410中。訊息之串列化版本之實例為電子郵件訊息之EML檔案。

訊息僅可在藉由訊息分析引擎402分析之前及/或期間暫時儲存於訊息記錄410中。然而，訊息記錄410亦可提供訊息之永久性或半永久性記錄。

儲存於訊息記錄410中之訊息可以數個不同方式中之任一者獲得。在一些實施中，准許訊息分析引擎402對傳訊服務上之一或多個使用者帳戶之存取。此存取可允許訊息分析引擎402自傳訊服務獲得使用者訊息。傳訊服務之非限制性實例包括電子郵件服務、文字傳訊服務及即時傳訊服務。此外，使用者可准許訊息分析引擎402對多個傳訊服務上之其帳戶之存取。因此，訊息分析引擎402可自一或多個電子郵件帳戶、一或多個文字傳訊帳戶及/或一或多個即時傳訊帳戶獲得使用者之訊息。

一旦訊息分析引擎402可存取傳訊服務上之使用者帳戶，則彼傳訊服務上使用者訊息中之任一者、一些或全部可儲存於訊息記錄410中。可自支援傳訊服務之伺服器及/或自使用者裝置(例如，使用者裝置430)接收訊息。在一些情況下，當使用者接收傳訊服務上之新訊息時，訊息記錄410亦可獲得及儲存新訊息。因此，訊息記錄410可包括使用者在一或多個傳訊平台上接收之訊息之合併清單。在一些情況下，使用者主動地選擇哪些訊息儲存於訊息記錄410中及/或界定判定哪些訊息儲存於訊息記錄410中的規則集。舉例而言，使用者可組態訊息分析引擎402之存取使得僅來自某些發送方之訊息儲存於訊息記錄410中。

出貨供應商記錄412包括已知出貨供應商之清單或集合。在一些情況下，此清單可諸如基於自一或多個資料源獲得之資訊自動地建構或維持。關於此等出貨供應商中之每一者之資訊亦可儲存於出貨供應商記錄412中，包括例如由出貨供應商使用之出貨訊息格式、由出貨供應商使用之追蹤URL格式及/或由出貨供應商使用之網頁資源格式。如本文中其他處更詳細地所論述，出貨供應商記錄412可用於幫助自訊息獲得出貨資訊及/或確認出貨資訊。

訊息類別記錄413包括預定義訊息類別之清單或集合。此等預定義訊息類別中之至少一些可對應於例如不同訊息格式、模板或結構。

在一些實施中，訊息類別記錄413中之預定義訊息類別(至少部分地)基於訊息之潛在功能而界定。因此，判定訊息之訊息類別可幫助判定訊息之功能。此類預定義訊息類別之非限制性實例包括： ●          商務訊息，包括例如商家廣告、簡訊及其他促銷內容； ●          出貨追蹤及/或確認訊息； ●          交付狀態更新訊息； ●          訂單確認訊息； ●          個人訊息； ●          工作訊息； ●          帳單；以及 ●          垃圾郵件訊息。

訊息類別記錄413中之預定義訊息類別亦可或替代地(至少部分地)基於訊息之發送方而界定。不同商家、出貨供應商及其他發送方可具有其發送位址及/或其自身訊息格式，其中之每一者或這兩者可單獨或呈組合形式對應於訊息類別記錄413中之各別訊息類別。在實例中，可界定多個出貨追蹤訊息類別，其中每一類別對應於出貨供應商記錄412中經界定之不同出貨供應商。

在一些實施中，訊息類別記錄413可幫助識別可潛在包括出貨資訊之訊息且可甚至幫助判定訊息中之出貨資訊中之至少一些。舉例而言，可判定特定訊息對應於特定預定義訊息類別。若此預定義訊息類別與出貨追蹤相關聯，則可判定訊息亦與出貨追蹤相關聯。此外，若訊息類別與特定出貨供應商相關聯，則可判定藉由彼出貨供應商促進出貨。

URL類別記錄414包括預定義URL類別之清單或集合。舉例而言，此等預定義URL類別中之每一者可對應於不同URL格式、模板或結構。此等預定義URL類別可用於幫助判定URL之功能及/或藉由URL鏈接至之網頁資源之功能。換言之，藉由將特定URL與儲存於URL類別記錄414中之預定義URL類別中之一者匹配，可判定藉由URL鏈接至之網頁資源之目標。

在一些實施中，儲存於URL類別記錄414中之預定義URL類別中之至少一者為追蹤URL類別或另外與追蹤出貨相關。URL類別記錄414可包括多個追蹤URL類別，其中追蹤URL類別中之每一者可特定針對於各別出貨供應商。舉例而言，由特定出貨供應商使用之URL格式可屬於特定針對於出貨供應商之一或多個追蹤URL類別。在一些情況下，URL類別記錄414與出貨供應商記錄412相關使得出貨供應商記錄412中之每一出貨供應商具有URL類別記錄414中經界定之一或多個對應URL類別。然而，多個不同出貨供應商可使用具有類似格式之URL。另外，在一些情況下，URL可對應於出貨資訊聚合器，可自其中獲得出貨資訊，即使聚合器可不負責處置出貨之實際出貨/交付。因而，追蹤URL類別可與多個不同出貨供應商相關聯。URL類別記錄414中亦可存在並不與出貨追蹤相關之一或多個預定義URL類別。

如本文中其他處更詳細地所論述，在URL類別記錄414中儲存預定義URL類別可幫助判定來自URL之出貨資訊。若判定URL對應於與特定出貨供應商相關聯之追蹤URL類別，則可推斷URL係關於追蹤藉由彼出貨供應商促進之出貨。瞭解追蹤URL類別之知識亦可允許自URL提取追蹤編號。在實例中，特定追蹤URL類別對應於包括追蹤編號之URL格式。通常在同一位置處以URL格式包括追蹤編號。因而，開始索引及結束索引可經界定用於彼追蹤URL類別之追蹤數目且儲存於URL類別記錄414中。開始索引對應於追蹤編號之第一數字之位置，且結束索引對應於追蹤編號之最末數字之位置。使用開始索引及結束索引，追蹤編號可自此追蹤URL類別之URL提取。開始索引及/或結束索引可自URL之開始或自URL之結束界定。換言之，發現URL中追蹤編號之開始及/或結束可涉及自URL之開始向前計數或自URL之結束向後計數。

ML模型416可由處理器404執行以分析訊息且自訊息獲得資訊(諸如出貨資訊)。在一些情況下，ML模型416實施用於自訊息獲得資訊之機率性方法。

ML模型416可使用此項技術中已知之任何形式或結構來實施。ML模型416之實例結構包括但不限於： ●      一或多個人工神經網路； ●      一或多個決策樹； ●      一或多個支援向量機； ●      一或多個貝氏網路；及/或 ●      一或多個基因演算法。

用於訓練ML模型416之方法亦為實施特定的且在本文中不受限制。訓練方法之非限制性實例包括： ●      監督式學習； ●      無監督學習； ●      增強式學習； ●      自學習； ●      特徵學習；以及 ●      稀疏字典學習。

根據一些實施例，使用監督式學習訓練ML模型416中之一或多者。在監督式學習中，藉由分析訓練資料集中之輸入資料、與訓練資料集中之已知結果進行定量比較及交叉參考結論來執行訓練。此等分析及比較之反覆優化允許ML模型達成藉由ML模型預測之結果與已知結果之間的較高確定性。此程序反覆地繼續直至解決方案收斂或達到所要準確性為止。

根據一些實施例，使用無監督學習訓練ML模型416中之一或多者。在無監督學習中，ML模型自訓練資料集判定及繪製其自身連接。此可藉由查看訓練資料集中自然發生之資料關係或模式來進行。用於實施無監督學習之一種方法為叢集分析，其中目標為發現訓練資料集內之群組或叢集。叢集為類似地藉由ML模型處理之變數集。在叢集分析中，ML模型將細分訓練資料集以判定具有高群組內類似性及低群組間類似性之叢集。叢集分析中使用之叢集之數目可在ML模型中組態。

ML模型416中之任一者、一者、一些或全部可為或包括多任務學習(MTL)模型。MTL模型可藉由同時執行多個任務幫助較準確及/或高效地自訊息提取資訊。舉例而言，判定訊息中之URL是否係關於追蹤出貨、判定用於出貨之出貨供應商、判定用於出貨之追蹤編號及判定發起出貨之商家均可被視為可藉由單個MTL模型解決之「任務」。此等任務之間的通用性及差異可幫助改良MTL模型之整體準確性，相較於經實施以單獨地解決每一任務之多個ML模型。MTL模型可經訓練以同時跨越所有任務改良結果以提供改良之集體應答，而非個別地改良每一任務之結果，這會產生作為集體可能並不正確或相干的改良之個別應答。此外，替代多個ML模型實施單個MTL模型可減小需要訓練及維持之ML模型之總數目。

出貨資訊記錄418包括已經針對一或多個使用者獲得之出貨資訊。此出貨資訊可使用本文中其他處所揭示之ML模型416及/或方法自儲存於訊息記錄410中之訊息判定。然而，舉例而言，出貨資訊亦可自其他來源獲得，諸如經由使用者裝置430上之直接使用者輸入。在一些實施中，出貨資訊記錄418編譯或以其他方式為一或多個使用者提供出貨資訊之合併清單。可主動地更新出貨資訊之清單。在一個實例中，當出貨由使用者接收時，對應於此出貨之出貨資訊可自出貨資訊記錄418移除。在另一實例中，當新訊息藉由訊息記錄410獲得且出貨資訊自此訊息獲得時，接著出貨資訊可新增至出貨資訊記錄418。

儘管在圖4中單獨地展示訊息記錄410、出貨供應商記錄412、訊息類別記錄413、URL類別記錄414及出貨資訊記錄418，但應注意，在一些實施例中，此等記錄中之兩者或更多者可替代地組合成單個記錄。在一個實例中，訊息記錄410及出貨資訊記錄418可組合成單個記錄。在另一實例中，出貨供應商記錄412、訊息類別記錄413及URL類別記錄414可組合成單個記錄。

使用者裝置430包括處理器432、記憶體434、使用者介面436及網路介面438。使用者介面436可包括例如顯示螢幕(其可為觸控螢幕)、手勢辨識系統、揚聲器、頭戴式耳機、麥克風、觸覺裝置、鍵盤及/或滑鼠。提供網路介面438以用於經由網路420通信。網路介面438之結構將取決於使用者裝置430如何與網路420介接。舉例而言，若使用者裝置430為行動電話、耳機或平板電腦，則網路介面438可包括具有天線以將無線傳輸發送至網路420/自網路接收無線傳輸之傳輸器/接收器。若使用者裝置為藉由網路電纜連接至網路之個人電腦，則網路介面438可包括例如NIC、電腦埠及/或網路通訊端。處理器432直接執行或指示由使用者裝置430執行之所有操作。此等操作之實例包括處理自使用者介面436接收之使用者輸入，準備用於經由網路420傳輸之資訊，處理經由網路420接收之資料，及指示顯示螢幕以顯示資訊。處理器432可藉由執行儲存於記憶體434中之指令之一或多個處理器實施。替代地，處理器432中之一些或全部可使用專用電路系統(諸如ASIC、GPU或經程式化FPGA)來實施。

在圖4中，藉助於實例展示一個使用者裝置。多於一個使用者裝置可與訊息分析引擎402通信。

圖5為說明根據一實施例的用於分析訊息以獲得出貨資訊之方法500的流程圖。方法500將描述為由圖4之訊息分析引擎402執行。然而，亦涵蓋其他實施。舉例而言，方法500可完全或部分地藉由使用者裝置430執行。

該方法可包括識別與顧客相關聯之複數個訊息。用於至少一個出貨之出貨資訊可自該複數個訊息提取。步驟502包括處理器404獲得對應於給定訊息之數位內容。訊息可為該複數個經識別訊息中之一者。舉例而言，此數位內容可包括訊息中之內容(例如，訊息之標題、文字及/或附件)、訊息之發送方及/或訊息之接收方中之任一者、一些或全部。在一些情況下，在步驟502中獲得訊息之串列化版本。舉例而言，數位內容可自訊息記錄410、自使用者裝置430及/或自託管傳訊服務之伺服器獲得。

步驟504包括處理器404自在步驟502中獲得之數位內容獲得一或多個URL。每一URL與網頁資源相關聯。URL對於使用者讀取或以其他方式與訊息接合可見(例如，為以文字所示之超鏈接)或對於使用者不可見(例如，為後設資料或不可見的超文字標示語言(HTML)元素)。一般而言，可在步驟504中獲得數位內容中之任何、一個、一些或所有URL。若數位內容中未發現URL，則方法500可結束。

步驟504可使用各種技術中之任一者執行。在一些情況下，步驟504可實施確定性方法，諸如字符串匹配演算法以提取URL。舉例而言，處理器404可剖析數位內容且移除包括URL特定語法之任何字符串。URL特定語法之非限制性實例包括http : 、 . html 、 . com 、 . org 及. ca 。 機率性方法亦可或替代地在步驟504中實施。舉例而言，ML模型416中之一或多者可經訓練以自數位內容提取URL。

在步驟504中自訊息提取之URL可儲存於記憶體406或另一非暫時性電腦可讀媒體中。舉例而言，經提取URL可連同訊息記錄410中之訊息一起儲存。

步驟506為視情況選用之步驟，其包括處理器404基於在步驟502中獲得之數位內容判定訊息係關於(或有可能係關於)追蹤出貨。此步驟通知訊息分析引擎402訊息應進一步使用方法500處理以獲得出貨資訊。若另一方面，步驟506判定訊息並不係關於追蹤出貨，則方法500可結束。因而，步驟506可幫助篩選由方法500處理之訊息之數目。

在一些實施中，步驟506包括將訊息分類及判定訊息類別與出貨追蹤相關聯。舉例而言，步驟506可包括將數位內容輸入至ML模型(其可為ML模型416中之一者)中，該模型已經訓練以自訊息之數位內容識別訊息類別。此ML模型接著可針對訊息輸出訊息類別或至少訊息類別之指示。在一些情況下，ML模型可自儲存於訊息類別記錄413中之預定義訊息類別之集合選擇訊息類別。基於藉由ML模型判定之訊息類別，可判定訊息是否係關於出貨。舉例而言，出貨追蹤訊息及訂單確認訊息可界定為可係關於產品之出貨之訊息類別。

用於自訊息之數位內容識別訊息類別的ML模型可以數個不同方式中之任一者訓練。在一些實施中，用於此ML模型之訓練資料集可包括訊息之集合，其各自以已知訊息類別標記。此訓練資料集可在計算平台上自使用者回饋獲得。舉例而言，當使用者遇到關於計算平台上之訊息之問題時，其可報告該問題。在報告中，可要求使用者提交訊息且指示訊息之類別。訊息之類別可選自儲存於訊息類別記錄413中之預定義類別中之一者。因此，此等報告可提供已經由使用者分類之訊息之較大集合且可因此為ML模型提供合適的訓練資料集。

在一些實施中，步驟506使用在步驟504中獲得之URL，除訊息之完整數位內容之外或替代該完整數位內容，以判定訊息係關於出貨追蹤。在此等實施中，步驟506可包括將URL之至少一部分輸入至已經訓練以識別URL類別之ML模型中。此ML模型可為ML模型416中之一者。若URL類別對應於出貨追蹤，則可判定訊息自身亦係關於出貨追蹤。在一些情況下，ML模型可自儲存於URL類別記錄414中之預定義URL類別之集合選擇URL類別。

用於自URL識別URL類別之ML模型可使用經由計算平台上之使用者回饋所獲取之訓練資料集來訓練。舉例而言，當商家正在電子商務平台上履行顧客訂單時，商家可提供URL以用於追蹤訂單之出貨。因而，在此等情形下由商家提供之URL可分類為與出貨追蹤相關。此等URL以及並不與出貨追蹤相關之其他URL可形成用於訓練ML模型以將與出貨追蹤相關之URL分類的訓練資料集之基礎。

步驟508包括處理器404基於在步驟504中獲得之URL及/或與此URL相關聯之網頁資源判定出貨資訊。該出貨資訊包括該網頁資源用於追蹤出貨之指示、用於該出貨之追蹤編號，及用於該出貨之出貨供應商中之至少一者。判定網頁資源用於追蹤出貨可指示URL為追蹤URL。因而，URL自身可新增至在步驟508中判定之出貨資訊。出貨資訊可進一步包括經運送產品、用於出貨之訂單編號、出貨狀態、預期交付日期及/或發起出貨之商家。在一些情況下，出貨可藉由多個出貨供應商促進及/或具有多個相關聯追蹤編號。多個相關聯追蹤編號中之任一者、一者、一些或全部可在步驟508中判定。

在步驟508之一些實施中，出貨資訊中之至少一些使用至少一個ML模型自URL獲得，該模型可為ML模型416中之一者。至ML模型之輸入可包括URL。然而，完整URL可能未必總是輸入至ML模型中。因為URL具有結構化性質，因此URL之某些組件可經提取且輸入至ML模型中以減小藉由ML模型分析之字元之總數目。舉例而言，可實施確定性方法以提取URL之權限、路徑及/或查詢組件並將彼等組件輸入至ML模型中。ML模型之輸出可包括URL是否係關於追蹤出貨之指示、對應於用於出貨之追蹤編號之文字串、對應於用於出貨之出貨供應商之文字串，及/或其他出貨資訊。在一些實施中，將對應於出貨供應商之文字串與出貨供應商記錄412中出貨供應商之清單進行比較。此可幫助判定促進出貨之確切出貨供應商。

用於在步驟508中自URL獲得出貨資訊之ML模型可使用自計算平台之使用者獲得之資料來訓練。舉例而言，當商家正在電子商務平台上履行顧客訂單時，商家可提供用於訂單之出貨之追蹤URL、用於訂單之出貨供應商及用於訂單之追蹤編號。此資訊可跨越多個產品訂單收集以形成用於ML模型之訓練資料集之基礎。舉例而言，ML模型可經訓練以自每一URL預測正確出貨供應商及/或追蹤編號。

在一些實施中，至用於在步驟508中自URL獲得出貨資訊之ML模型之輸入可進一步包括對應於URL中追蹤編號之開始之第一索引之預測及/或對應於URL中追蹤編號之結束之第二索引之預測。此等預測可提高ML模型對追蹤編號之判定之準確性及/或可靠性。舉例而言，預測可在分析期間允許ML模型略過URL中之一些字元。第一索引及第二索引之預測可以機率分佈形式提供。對於輸入至ML模型中之URL之每一字元，ML模型可獲得字元為第一索引之機率及/或字元為第二索引之機率。

針對URL中之追蹤編號的第一索引之預測及第二索引之預測可以各種不同方式中之任一者獲得。在一些實施中，實施第一ML模型以產生第一索引及/或第二索引之預測。此第一索引及/或第二索引接著可輸入至第二ML模型中，如上文所描述，以獲得對應於追蹤編號之文字串。此外，在一些實施中，第一ML模型及第二ML模型可使用單個MTL模型共同實施。

在一些實施中，第一ML模型藉由判定預定義URL類別之集合中之哪些URL類別(視需要儲存於URL類別記錄414中)與URL最佳擬合來將URL分類。經判定URL類別可具有追蹤編號之通常固定位置之格式。因而，第一索引之預測及/或第二索引之預測可基於經判定URL類別自URL類別記錄414獲得。 URL類別亦可與特定出貨供應商相關聯，且因此用於出貨之出貨供應商可另外基於經判定URL類別自URL類別記錄414獲得。

在一些實施中，步驟506、508兩者可至少使用第一ML模型部分地實施。舉例而言，第一ML模型可將URL分類，其中經判定類別指示URL係關於出貨追蹤且亦允許自URL獲得追蹤編號及/或出貨供應商。

類似於第二ML模型，第一ML模型可使用自電子商務平台獲得之訓練資料來訓練。舉例而言，當商家正將追蹤URL輸入至電子商務平台中以完成訂單時，可要求商家將URL分類並提供與URL相關聯之追蹤編號及/或出貨供應商。字符串匹配演算法可接著用於判定URL中追蹤編號之第一索引及第二索引，這可形成用於第一ML模型之訓練資料集之基礎。

應注意，在一些實施中，僅第一ML模型用於自URL獲得出貨資訊。舉例而言，第一ML模型可判定提供追蹤編號之第一索引、追蹤編號之第二索引及/或出貨供應商的URL之類別。此資訊接著可用於藉由自URL中之第一索引與第二索引之間提取追蹤編號而獲得追蹤編號。因此，第一ML模型可未必總是與第二ML模型組合使用以判定出貨資訊。

在步驟508中，自URL獲得之出貨資訊可使用自與URL相關聯之網頁資源獲得之出貨資訊來補充及/或確認。替代地，出貨資訊可完全自網頁資源獲得。自網頁資源獲得出貨資訊可包括使用URL存取網頁資源、自網頁資源獲得內容，及/或剖析內容以判定出貨資訊。剖析內容可包括例如文字及/或影像分析操作且可至少部分地使用ML模型416中之一者執行。

剖析與URL相關聯之網頁資源之潛在益處為處理器404可能夠判定網頁資源是否為詐騙性的。舉例而言，ML模型(其可為ML模型416中之一者)可經訓練以辨識詐騙網頁。在判定網頁為詐騙性的之後，含有用於彼網頁之URL之訊息可標記為網路釣魚或垃圾電子郵件。

在一些實施中，自URL及網頁資源兩者獲得追蹤編號及出貨供應商。舉例而言，追蹤編號及出貨供應商首先可藉由剖析URL獲得，且追蹤編號及出貨供應商接著可藉由剖析網頁資源確認。此提供一定程度之冗餘以幫助確保在步驟508中獲得正確的追蹤編號及出貨供應商。在一些情況下，處理器404可搜尋網頁資源以搜尋與自URL獲得之追蹤編號及/或出貨供應商匹配之文字串。若此類文字串發現於網頁資源中，則可判定藉由網頁資源確認追蹤編號及/或出貨供應商。其他確定性及/或機率性方法亦可或替代地用於確認網頁資源中之追蹤編號及/或出貨供應商。

在自URL獲得之追蹤編號及/或出貨供應商與自網頁資源獲得之內容並不匹配的情況下，接著可執行進一步處理以解決偏差。舉例而言，若針對URL判定URL類別，則URL類別可用以判定自URL獲得之出貨資訊或來自網頁資源之出貨資訊是否被視為最準確的。 URL類別記錄414可儲存可如何準確地自每一URL類別及/或自針對每一URL類別之相關聯網頁資源獲得出貨資訊的指示。接著可捨棄較不準確的出貨資訊。替代地，藉由使用者之人工干預可用於解決URL與網頁資源之間的偏差。

舉例而言，考慮追蹤編號自URL提取且追蹤編號亦自相關聯網頁提取的情況。若此等兩個追蹤編號匹配，則追蹤編號經確認且可能不會採取進一步動作。替代地，若兩個追蹤編號不同，則可捨棄較不準確的追蹤編號。在一些情況下，訊息分析引擎可經組態以將自URL提取之追蹤編號視為較不準確的追蹤編號。在其他情況下，訊息分析引擎可經組態以將自網頁提取之追蹤編號視為較不準確的追蹤編號。

在一些情況下，藉由剖析URL來判定追蹤編號及出貨供應商中之一者，且藉由剖析網頁資源來判定追蹤編號及出貨供應商中之另一者。因此，自網頁資源判定之出貨資訊可新增至針對訊息獲得之出貨資訊之累積記錄。此可在追蹤編號或出貨供應商無法藉由剖析URL判定時進行，且因此執行剖析網頁資源以補充自URL獲得之出貨資訊。舉例而言，URL可不包括追蹤編號，或追蹤編號可經編碼或散列於URL中。此外，多個不同出貨供應商可使用類似URL格式。因而，特定出貨供應商可能無法自URL之格式或判定類別推斷。

在一些情況下，追蹤編號及出貨供應商均不可自URL獲得。因此，在此等情況下，步驟508可包括藉由剖析網頁資源判定追蹤編號及出貨供應商兩者。URL用於存取網頁資源，其接著經剖析以獲得出貨資訊。

在一些情況下，僅剖析URL以在步驟508中獲得出貨資訊。此可在網頁資源並不包括必要的出貨資訊時進行，訊息分析引擎402不具有分析網頁資源之能力，及/或在足夠信賴度下自URL獲得出貨資訊。

在一些情況下，給定URL可對應於影像，其包括出貨資訊，諸如估計到達時間。機器學習模型可經訓練(例如，使用由此類影像之實例組成之一或多個訓練集)以分析此類影像且可用於自此類影像提取資訊。另外或替代地，諸如光學字元辨識之技術可用於自此類影像提取資訊。

可在步驟508中實施之ML模型為用於判定出貨資訊之機率性方法之實例。在一些情況下，後處理步驟可對使用ML模型獲得之出貨資訊執行。後處理之實例為實施確定性方法以確認及/或補充使用ML模型獲得之出貨資訊。

如上文所提及，多於一個URL可在步驟504中自數位內容獲得。可在步驟508中分析此等URL中之每一者。在一些情況下，數位內容中之兩個或更多個URL可包括出貨資訊。可比較自兩個或更多個URL獲得之出貨資訊以判定URL是否係關於同一出貨或不同出貨。亦可比較出貨資訊以判定URL是否係關於以多個階段交付同一出貨之多個出貨供應商。

若兩個URL係關於同一出貨，則可出於確認的目的比較自兩個不同URL獲得之出貨資訊。此外，訊息中自兩個URL獲得之出貨資訊可用於解決自URL中之一者獲得之出貨資訊與自相關聯網頁資源獲得之出貨資訊之間的偏差。舉例而言，若自第一URL提取之追蹤編號亦經由訊息中之第二URL之分析來判定，則可略過自與第一URL相關聯之網頁資源提取之不同追蹤編號。

根據實例，第一URL及第二URL可在步驟504中自數位內容獲得。第一URL及第二URL分別與第一網頁資源及第二網頁資源相關聯。此處，步驟508可包括判定第一URL及第二URL對應於同一出貨；自第一URL、第二URL、第一網頁資源及/或第二網頁資源獲得同一追蹤編號；及/或自第一URL、第二URL、第一網頁資源及/或第二網頁資源獲得同一出貨供應商。

在一些情況下，在步驟504中自訊息提取之URL中之一或多者可不係關於出貨追蹤。若處理器404判定URL並不係關於出貨追蹤，則對URL之分析結束且步驟508可進行分析下一URL或進行至步驟510。

步驟510包括將在步驟508中判定之出貨資訊儲存於記憶體406或另一電腦可讀媒體中。在一些實施中，出貨資訊可儲存於出貨資訊記錄418中。出貨資訊稍後可用於獲得用於出貨之追蹤更新。舉例而言，訊息分析引擎402或使用者裝置430可存取出貨資訊以自促進出貨之出貨供應商獲得經更新出貨資訊。此可為出貨提供經更新交付日期，其可新增至儲存於記憶體406中之出貨資訊。

如使用自步驟510至步驟502之箭頭所說明，可針對各別訊息重複步驟502、504、506、508、510多次。此可建構關於出貨資訊記錄418中之多個出貨的出貨資訊之累積記錄。此等多個出貨可均針對同一使用者。藉助於實例，步驟502之多個例項可獲得對應於與使用者相關聯之多個訊息之數位內容。此等訊息可立即或在多個不同時間獲得。此等訊息中之每一者可對應於針對顧客之不同產品出貨。步驟504之多個例項可自用於訊息中之每一者之數位內容獲得URL，且步驟508之多個例項可自URL及/或其相關聯網頁資源獲得出貨資訊。步驟510之多個例項接著可將此出貨資訊儲存於記憶體406中。此可將關於使用者之多個出貨之出貨資訊新增至出貨資訊記錄418。

出貨資訊可用於獲得顧客之一或多個產品出貨之追蹤更新。可提供一或多個產品出貨之所獲得追蹤更新以用於呈現顧客之所有產品出貨之彙總概觀。

步驟512為視情況選用之步驟，其包括處理器輸出出貨資訊記錄418中出貨資訊之至少一部分以用於顯示於使用者裝置430或另一裝置上。舉例而言，使用方法500分析之訊息可對應於使用者裝置430之使用者，且因此使用者裝置430可經給定對儲存於出貨資訊記錄418中之出貨資訊中之至少一些之存取。此出貨資訊中之任一者、一些或全部可藉由訊息分析引擎402輸出以用於顯示於使用者裝置430上。

可准許使用者裝置430之使用者更改儲存於出貨資訊記錄418中之出貨資訊中之至少一些。舉例而言，使用使用者裝置430，使用者可產生指令以更改出貨資訊記錄418。更改出貨資訊記錄418之非限制性實例包括： ●      新增可用於新出貨或現有出貨之出貨資訊； ●      當接收出貨時或當一些出貨資訊不正確時移除出貨資訊；以及 ●      基於使用者偏好重組出貨資訊。

另外或替代地，更改出貨資訊可包括不正確出貨資訊之校正。舉例而言，此種校正可包括經校正出貨資訊之輸入。在一些情況下，可向使用者呈現用於替代出貨資訊之一或多個選項。出貨資訊之校正之輸入可回應於此類選項接收且可對應於所呈現選項中之一者之選擇。值得注意地，在機器學習用於諸如以上文所論述之方式獲得出貨資訊的情況下，在替代方案之此清單中所呈現之選項可包括用於藉由應用機器學習模型而識別之出貨資訊的其他候選者，諸如機器學習模型識別為可能出貨資訊但具有較低可信度之候選出貨資訊。另外，在一些實施中，在接收到對出貨資訊之校正的情況下，可稍後在更新/重新訓練機器學習模型(例如，藉由將經校正資訊新增至訓練集)時採用彼等校正(無論藉助於經校正出貨資訊之輸入接收、基於替代出貨資訊之選擇接收，抑或以其他方式接收)以用於識別出貨資訊以便改良準確性。

僅藉助於實例展示步驟502、504、506、508、510、512之次序。亦涵蓋步驟502、504、506、508、510、512之其他次序。舉例而言，步驟506可判定在執行步驟504之前訊息係關於追蹤出貨以自對應於訊息之數位內容獲得URL。自訊息獲得出貨資訊之實例

圖6及圖7說明獲得至顧客(「Meredith Zhao」)之第一產品(「冬季仙境1000塊拼圖(Winter Wonderland 1000 Piece Puzzle)」)之出貨之出貨資訊的實例。首先參考圖6，展示顧客自出售第一產品之商家(「Pierce拼圖店(Pierce's Puzzles)」)所接收之電子郵件訊息600。電子郵件訊息600包括對應於出貨之訂單編號602、經運送第一產品之指示604、顧客之出貨位址606、用於出貨之追蹤編號608、促進出貨之出貨供應商(「完善郵政服務(Perfect Postal Service)」)之指示610及用於出貨之追蹤URL 612。追蹤URL 612包括對應於追蹤編號608之文字串614及對應於出貨供應商之另一文字串616。

圖7說明對應於追蹤URL 612之網頁700。舉例而言，若顧客選擇電子郵件訊息600中之追蹤URL 612，則顧客可被引導至網頁700。網頁700包括訂單編號602、追蹤編號608、出貨供應商之指示610及預期交付日期之指示702。

方法500可用於獲得用於第一產品至顧客之出貨之出貨資訊。在步驟502中，舉例而言，對應於電子郵件訊息600之數位內容可自傳訊服務上之顧客帳戶獲得。此數位內容可包括圖6中所展示之視需要呈串列化格式之內容中之任一者、一些或全部。在步驟504中，舉例而言，使用字符串匹配演算法自數位內容提取追蹤URL 612。步驟506可判定訊息600係關於追蹤出貨。此可藉由將電子郵件訊息600之數位內容輸入至ML模型中以將電子郵件訊息600分類為係關於出貨追蹤之訊息而執行。替代地或另外，追蹤URL 612之至少一部分可輸入至ML模型中以將追蹤URL 612分類為係關於出貨追蹤。

在步驟508中，用於第一產品之出貨之出貨資訊可自追蹤URL 612及網頁700兩者獲得。追蹤URL 612可經剖析以判定網頁700用於追蹤第一產品之出貨。追蹤URL 612亦可經剖析以獲得對應於追蹤編號608之文字串614及對應於出貨供應商之文字串616。文字串616可對照儲存於記憶體中之出貨供應商之清單比較以判定文字串616對應於出貨供應商。出售及運送產品之商家在追蹤URL 612中經識別且因此亦可藉由剖析追蹤URL 612而獲得。

剖析追蹤URL 612可涉及將追蹤URL 612之至少一部分輸入至一或多個ML模型中。舉例而言，查詢組件(「Id=11111000&shippingprovider=PPS」)可使用確定性方法自追蹤URL 612提取且輸入至ML模型中。

在一些情況下，將追蹤URL 612輸入至第一ML模型中以將追蹤URL 612分類。追蹤URL 612之經判定類別可預測追蹤URL 612對應於商家及/或出貨供應商。追蹤URL 612之經判定類別亦可或替代地提供對應於文字串614之開始之第一索引之預測及/或對應於文字串614之結束之第二索引之預測。在所說明實例中，第一索引為42且第二索引為49 (自追蹤URL 612之開始計數)。第一索引及第二索引可用以自追蹤URL 612提取追蹤編號608。追蹤URL 612、經預測出貨供應商、經預測第一索引及/或經預測第二索引可接著輸入至第二ML模型中。第二ML模型之輸出可包括出貨供應商及/或追蹤編號608之經優化預測。在此多步驟方法中判定出貨供應商及/或追蹤編號608可提供較準確結果，此係因為第二ML模型可得益於第一ML模型之結果。替代地，第一ML模型或第二ML模型可用於隔離中以判定出貨供應商及/或追蹤編號608。

亦可在步驟508中剖析網頁700以確認自追蹤URL 612獲得之出貨供應商、商家及/或追蹤編號608。此外，剖析網頁700可自指示702判定預期交付日期及/或判定訂單編號602。舉例而言，使用ML模型實施之機率性方法可用以剖析網頁700並獲得此出貨資訊。

圖8及圖9說明獲得至顧客(「Meredith Zhao」)之第二產品(「關於樹木的書(Book on Trees)」)之出貨之出貨資訊的實例。首先參考圖8，展示顧客自出售產品之商家(「圖書專營店(Book Outlet)」)所接收之電子郵件訊息800。電子郵件訊息800包括對應於出貨之訂單編號802、經運送產品之指示804、用於出貨之追蹤編號806、促進出貨之出貨供應商(「快速交付(Rapid Delivery)」)之指示808及超鏈接810。超鏈接810對應於圖9中所展示之追蹤URL 902。

圖9說明對應於追蹤URL 902之網頁900。網頁900包括訂單編號802、追蹤編號806、出貨供應商之指示808、顧客之出貨位址904及預期交付日期之指示906。

方法500亦可用以獲得用於第二產品至顧客之出貨之出貨資訊。在步驟502中，對應於電子郵件訊息800之數位內容可自傳訊服務上之顧客帳戶獲得。此可為自其獲得電子郵件訊息600之同一傳訊服務，或不同傳訊服務。在步驟504、506中，追蹤URL 902自超鏈接810提取且電子郵件訊息800經判定與追蹤出貨相關。

接著可執行步驟508以自追蹤URL 902及自網頁900獲得出貨資訊。剖析追蹤URL 902可判定用於第二產品之出貨之商家及/或訂單編號，這在追蹤URL 902中經識別。然而，追蹤URL 902並不包括對應於追蹤編號806之任何字符串，且因此可能無法自追蹤URL 902判定追蹤編號806。然而，可藉由剖析網頁900判定追蹤編號806。

在一些情況下，出貨供應商(「快速交付」)可自追蹤URL 902判定。舉例而言，追蹤URL 902可經分類以判定追蹤URL 902對應於商家。若商家通常僅使用一個出貨供應商，則追蹤URL 902之此分類亦可指示用於出貨之出貨供應商。亦可藉由剖析網頁900而獲得或確認出貨供應商。

亦可藉由剖析網頁900獲得進一步出貨資訊，包括訂單編號802及在906處指示之預期交付日期。

用於第一產品至顧客之出貨及用於第二產品至顧客之出貨所獲得的出貨資訊可新增至出貨資訊之合併清單或記錄。圖10說明用於顧客(「Meredith Zhao」)之出貨資訊之合併記錄1000之實例。記錄1000包括出貨資訊之三個列1002、1004、1006，其中列1002、1004、1006中之每一者係關於不同出貨。列1002對應於第一產品(「冬季仙境1000塊拼圖」)之出貨，列1004對應於第二產品(「關於樹木的書」)之出貨，且列1006對應於另一產品之出貨。記錄1000進一步包括用於每一出貨之出貨資訊之多個行1008、1010、1012、1014、1016、1018。行1008指示用於每一出貨之商家，行1010指示用於每一出貨之訂單編號，行1012指示用於每一出貨之追蹤編號，行1014指示用於每一出貨之出貨供應商，行1016指示用於每一出貨之估計或確認交付日期，且行1018包括具有用於每一出貨之追蹤URL之超鏈接。

在所說明實例中，經由追蹤URL 612及網頁700之分析獲得列1002中之出貨資訊，如上文所論述。因而，列1002包括訂單編號602、追蹤編號608、出貨供應商之指示610及估計交付日期之指示702。位於列1002及行1018中之超鏈接對應於追蹤URL 612，其允許顧客自記錄1000存取網頁700。類似地，經由追蹤URL 902及網頁900之分析獲得列1004中之出貨資訊，如上文所論述。因而，列1004包括訂單編號802、追蹤編號806、出貨供應商之指示808及估計交付日期之指示906。列1004及行1018中之超鏈接對應於追蹤URL 902，從而允許顧客自記錄1000存取網頁900。

記錄1000可在顧客下新的產品訂單時連續及/或間歇性地更新，且用於彼等訂單之出貨資訊經由顧客之訊息變得可用。此外，顧客可人工更改記錄1000。結論

儘管已參考本發明之特定特徵及實施例描述本發明，但可在不脫離本發明之情況下對本發明進行各種修改及組合。因此，描述及圖式僅僅被視為如藉由所附申請專利範圍所界定之本發明之一些實施例的說明，且涵蓋描述及圖式以涵蓋屬於本發明之範疇內之任何及所有修改、變化、組合或等效物。因此，儘管已詳細描述本發明及其優勢，但在不脫離如由所附申請專利範圍所界定之本發明的情況下，可在本文中進行各種改變、取代及更改。此外，並不意欲將本申請案之範疇限於說明書中所描述之程序、機器、製品、物質組成、手段、方法及步驟之特定實施例。如一般熟習此項技術者將易於自本發明之揭示內容瞭解，根據本發明，可利用目前存在或日後將發展之程序、機器、製品、物質組成、手段、方法或步驟，其執行與本文中所描述之對應實施例實質上相同的功能或達成與本文中所描述之對應實施例實質上相同的結果。因此，所附申請專利範圍意欲在其範疇內包括該等程序、機器、製品、物質組成、手段、方法或步驟。

此外，本文中所例示的執行指令之任何模組、組件或裝置可包括或以其他方式存取一或多個用於儲存資訊之非暫時性電腦/處理器可讀儲存媒體，該資訊諸如電腦/處理器可讀指令、資料結構、程式模組及/或其他資料。非暫時性電腦/處理器可讀儲存媒體之實例的非詳盡清單包括匣式磁帶、磁帶、磁碟儲存器或其他磁性儲存裝置、諸如緊密光碟唯讀記憶體(CD-ROM)之光碟、數位視訊光碟或數位多功能光碟(DVD)、Blu-ray Disc™或其他光學儲存器、以任何方法或技術實施之揮發性及非揮發性可移除及不可移除媒體、隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可抹除可程式化唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術。任何此類非暫時性電腦/處理器儲存媒體可為裝置之一部分或可存取或可連接至該裝置。本文中所描述之任何應用程式或模組可使用電腦/處理器可讀/可執行指令來實施，該等指令可由此類非暫時性電腦/處理器可讀儲存媒體儲存或以其他方式保持。

本教示亦可擴展至以下經編號條項中之一或多者之特徵： 條項 1.   一種電腦實施方法，其包含： 獲得對應於一訊息之數位內容； 自該數位內容獲得用於一網頁資源之一統一資源定位符(URL)； 基於該URL及該網頁資源判定包含以下中之至少一者之出貨資訊： 該網頁資源用於追蹤一出貨之一指示， 用於該出貨之一追蹤編號，及 用於該出貨之一出貨供應商；以及 將用於獲得用於該出貨之追蹤更新之該出貨資訊儲存於記憶體中。 2.   如條項1之電腦實施方法，其中判定該出貨資訊包含： 藉由剖析該URL判定該追蹤編號及該出貨供應商；及 藉由剖析該網頁資源確認該追蹤編號及該出貨供應商。 3.   如條項1之電腦實施方法，其中判定該出貨資訊包含： 藉由剖析該URL判定該追蹤編號及該出貨供應商中之一者；及 藉由剖析該網頁資源判定該追蹤編號及該出貨供應商中之另一者。 4.   如條項1之電腦實施方法，其中判定該出貨資訊包含： 藉由剖析該網頁資源判定該追蹤編號及該出貨供應商。 5.    如條項1之電腦實施方法，其中判定該出貨資訊包含： 將該URL輸入至一機器學習(ML)模型中；及 基於該ML模型之一輸出自該URL獲得對應於該追蹤編號之一文字串。 6.   如條項5之電腦實施方法，其中判定該出貨資訊進一步包含： 獲得一預測，該預測包含對應於該URL中該追蹤編號之一開始的一第一索引及對應於該URL中該追蹤編號之一結束的一第二索引；及 將該第一索引及該第二索引輸入至該ML模型中。 7.   如條項5之電腦實施方法，其中該ML模型包含一多任務學習模型。 8.    如條項1之電腦實施方法，其中判定該出貨資訊包含： 將該URL輸入至一機器學習(ML)模型中；及 自該ML模型之一輸出獲得對應於自預定義出貨供應商之一集合選擇之該出貨供應商的一文字串。 9.   如條項1之電腦實施方法，其中該URL為一第一URL，該網頁資源為一第一網頁資源，該追蹤編號為一第一追蹤編號且該出貨供應商為一第一出貨供應商，該方法進一步包含： 自該數位內容獲得用於一第二網頁資源之一第二URL； 基於該第二URL及該第二網頁資源判定： 該第二網頁資源用於追蹤該出貨， 用於該出貨之一第二追蹤編號，及 用於該出貨之一第二出貨供應商；以及 判定該第一追蹤編號與該第二追蹤編號匹配且該第一出貨供應商與該第二出貨供應商匹配。 10.  如條項1之電腦實施方法，其進一步包含： 基於該數位內容判定該訊息係關於追蹤該出貨。 11.  如條項10之電腦實施方法，其中判定該訊息係關於追蹤該出貨包含： 將該數位內容輸入至一機器學習(ML)模型中； 自該ML模型之一輸出獲得自預定義訊息類別之一集合選擇的該訊息之一訊息類別；以及 判定該訊息類別係關於出貨追蹤。 12.  如條項10之電腦實施方法，其中判定該訊息係關於追蹤該出貨包含： 將該URL輸入至一機器學習(ML)模型中； 自該ML模型之一輸出獲得自預定義URL類別之一集合選擇的該URL之一URL類別；以及 判定該URL類別係關於出貨追蹤。 13.  如條項1之電腦實施方法，其中： 該訊息對應於一特定使用者；且 儲存該出貨資訊包含將該出貨資訊儲存於用於與該特定使用者相關聯之複數個出貨之一出貨資訊記錄中， 該方法進一步包含輸出該出貨資訊記錄之至少一部分以用於顯示於與該特定使用者相關聯之一裝置上。 14.  一種系統，其包含： 至少一個處理器，其用以： 獲得對應於一訊息之數位內容； 自該數位內容獲得用於一網頁資源之一統一資源定位符(URL)；以及 基於該URL及該網頁資源判定包含以下中之至少一者之出貨資訊： 該網頁資源用於追蹤一出貨之一指示， 用於該出貨之一追蹤編號，及 用於該出貨之一出貨供應商；以及 記憶體，其用以儲存該出貨資訊以用於獲得用於該出貨之追蹤更新。 15.  如條項14之系統，其中該至少一個處理器進一步用以： 藉由剖析該URL判定該追蹤編號及該出貨供應商；及 藉由剖析該網頁資源確認該追蹤編號及該出貨供應商。 16.  如條項14之系統，其中該至少一個處理器進一步用以： 藉由剖析該URL判定該追蹤編號及該出貨供應商中之一者；及 藉由剖析該網頁資源判定該追蹤編號及該出貨供應商中之另一者。 17.  如條項14之系統，其中該至少一個處理器進一步用以： 藉由剖析該網頁資源判定該追蹤編號及該出貨供應商。 18. 如條項14之系統，其中該至少一個處理器進一步用以： 將該URL輸入至一機器學習(ML)模型中；及 基於該ML模型之一輸出自該URL獲得對應於該追蹤編號之一文字串。 19.  如條項18之系統，其中該至少一個處理器進一步用以： 獲得一預測，該預測包含對應於該URL中該追蹤編號之一開始的一第一索引及對應於該URL中該追蹤編號之一結束的一第二索引；及 將該第一索引及該第二索引輸入至該ML模型中。 20.  如條項18之系統，其中該ML模型包含一多任務學習模型。 21. 如條項14之系統，其中該至少一個處理器進一步用以： 將該URL輸入至一機器學習(ML)模型中；及 自該ML模型之一輸出獲得對應於自預定義出貨供應商之一集合選擇之該出貨供應商的一文字串。 22.  如條項14之系統，其中該URL為一第一URL，該網頁資源為一第一網頁資源，該追蹤編號為一第一追蹤編號且該出貨供應商為一第一出貨供應商，其中該至少一個處理器進一步用以： 自該數位內容獲得用於一第二網頁資源之一第二URL； 基於該第二URL及該第二網頁資源判定： 該第二網頁資源用於追蹤該出貨， 用於該出貨之一第二追蹤編號，及 用於該出貨之一第二出貨供應商；以及 判定該第一追蹤編號與該第二追蹤編號匹配且該第一出貨供應商與該第二出貨供應商匹配。 23.  如條項14之系統，其中該至少一個處理器進一步用以： 將該URL輸入至一機器學習(ML)模型中； 自該ML模型之一輸出獲得自預定義URL類別之一集合選擇的該URL之一URL類別；以及 判定該URL類別係關於出貨追蹤。 24.  如條項14之系統，其中： 該訊息對應於一特定使用者； 該記憶體進一步用以將該出貨資訊儲存於用於與該特定使用者相關聯之複數個出貨之一出貨資訊記錄中；且 該至少一個處理器進一步用以輸出該出貨資訊記錄之至少一部分以用於顯示於與該特定使用者相關聯之一裝置上。 25.  一種非暫時性電腦可讀儲存媒體，其儲存指令，該等指令在由一電腦系統之一處理器執行時使得該電腦系統以： 獲得對應於一訊息之數位內容； 自該數位內容獲得用於一網頁資源之一統一資源定位符(URL)； 基於該URL及該網頁資源判定包含以下中之至少一者之出貨資訊： 該網頁資源用於追蹤一出貨之一指示， 用於該出貨之一追蹤編號，及 用於該出貨之一出貨供應商；以及 將用於獲得用於該出貨之追蹤更新之該出貨資訊儲存於記憶體中。

100:電子商務平台 102:商家裝置 104:商家平台外網站 106:付款閘道 110A:管道 110B:管道 112:出貨供應商 114:管理員 116:業務支援服務 118:網域服務 120:付款服務 122:出貨服務 124:風險及保險服務 128:應用程式搜尋、推薦及支援平台 129:通信設施 132:顧客互動及分析 134:資料 136:商務管理引擎 138:線上商店 140A:介面 140B:介面 142A:應用程式 142B:應用程式 150:顧客裝置 152:POS裝置/銷售點裝置 300:訊息分析引擎 400:系統 402:訊息分析引擎 404:處理器 406:記憶體 408:網路介面 410:訊息記錄 412:出貨供應商記錄 413:訊息類別記錄 414:URL類別記錄 416:ML模型 418:出貨資訊記錄 420:網路 430:使用者裝置 432:處理器 434:記憶體 436:使用者介面 438:網路介面 500:方法 502,504,506,508,510,512:步驟 600:電子郵件訊息 602:訂單編號 604:指示 606:出貨位址 608:追蹤編號 610:指示 612:追蹤URL 614:文字串 616:文字串 700:網頁 702:指示 800:電子郵件訊息 802:訂單編號 804:指示 806:追蹤編號 808:指示 810:超鏈接 900:網頁 902:追蹤URL 904:出貨位址 906:指示 1000:記錄 1002,1004,1006:列 1008,1010,1012,1014,1016,1018:行

將參考附圖僅藉助於實例描述實施例，其中：

圖1為根據一個實施例之電子商務平台之方塊圖；

圖2為根據一個實施例之管理員之首頁的實例；

圖3說明圖1之電子商務平台，但包括訊息分析引擎；

圖4說明根據一實施例的用於自數位訊息獲得資訊之系統之方塊圖；

圖5為說明根據一實施例的用於分析訊息以獲得出貨資訊之方法的流程圖；

圖6說明根據一實施例的與追蹤出貨相關之電子郵件訊息；

圖7說明對應於圖6之電子郵件訊息中之追蹤URL的網頁；

圖8說明根據另一實施例的與追蹤出貨相關之電子郵件訊息；

圖9說明對應於圖8之電子郵件訊息中之追蹤URL的網頁；且

圖10說明根據一實施例的出貨資訊之合併記錄。

400:系統

402:訊息分析引擎

404:處理器

406:記憶體

408:網路介面

410:訊息記錄

412:出貨供應商記錄

413:訊息類別記錄

414:URL類別記錄

416:ML模型

418:出貨資訊記錄

420:網路

430:使用者裝置

432:處理器

434:記憶體

436:使用者介面

438:網路介面

Claims (15)

1. 一種電腦實施方法，其包含： 識別一顧客之複數個訊息； 自該複數個訊息中之訊息提取用於至少一個出貨之出貨資訊，該提取包括： 獲得對應於該複數個訊息中之一給定訊息之數位內容； 自該數位內容獲得用於一網頁資源之一統一資源定位符URL； 基於該URL及該網頁資源，藉由將該URL輸入至一或多個機器學習ML模型中並基於該一或多個ML模型之一輸出自該URL獲得對應於追蹤編號之一文字串而判定用於一特定出貨之出貨資訊，該出貨資訊包含以下中之至少一者： 該網頁資源係用於追蹤該特定出貨之一指示， 用於該特定出貨之一追蹤編號，及 用於該特定出貨之一出貨供應商；以及 將用於獲得用於該特定出貨之追蹤更新之該出貨資訊儲存於記憶體中。
2. 如請求項1之電腦實施方法，其進一步包含： 基於該出貨資訊獲得用於該至少一個出貨之追蹤更新；及 提供該等追蹤更新以用於呈現針對該顧客之產品出貨之一彙總概觀。
3. 如請求項1或2之電腦實施方法，其中判定該出貨資訊進一步包含： 獲得一預測，該預測包含對應於該URL中該追蹤編號之一開始的一第一索引及對應於該URL中該追蹤編號之一結束的一第二索引；及 將該第一索引及該第二索引輸入至該一或多個ML模型中。
4. 如請求項1或2之電腦實施方法，其中判定該出貨資訊包含： 將該URL輸入至該一或多個ML模型中；及 自該一或多個ML模型之一輸出獲得對應於自預定義出貨供應商之一集合選擇之該出貨供應商的一文字串。
5. 如請求項1或2之電腦實施方法，其中判定該出貨資訊包含： 藉由剖析該URL判定該追蹤編號及該出貨供應商；及 藉由剖析該網頁資源確認該追蹤編號及該出貨供應商。
6. 如請求項1或2之電腦實施方法，其中判定該出貨資訊包含： 藉由剖析該URL判定該追蹤編號及該出貨供應商中之一者；及 藉由剖析該網頁資源判定該追蹤編號及該出貨供應商中之另一者。
7. 如請求項1或2之電腦實施方法，其中判定該出貨資訊包含： 藉由剖析該網頁資源判定該追蹤編號及該出貨供應商。
8. 如請求項1或2之電腦實施方法，其中該一或多個ML模型中之至少一者包含一多任務學習模型。
9. 如請求項1或2之電腦實施方法，其中該URL為一第一URL，該網頁資源為一第一網頁資源，該追蹤編號為一第一追蹤編號且該出貨供應商為一第一出貨供應商，該方法進一步包含： 自該數位內容獲得用於一第二網頁資源之一第二URL； 基於該第二URL及該第二網頁資源判定： 該第二網頁資源係用於追蹤該出貨， 用於該出貨之一第二追蹤編號，及 用於該出貨之一第二出貨供應商；以及 判定該第一追蹤編號與該第二追蹤編號匹配且該第一出貨供應商與該第二出貨供應商匹配。
10. 如請求項1或2之電腦實施方法，其進一步包含： 基於該數位內容判定該訊息係關於追蹤該出貨。
11. 如請求項10之電腦實施方法，其中判定該訊息係關於追蹤該出貨包含： 將該數位內容輸入至該一或多個ML模型中； 自該一或多個ML模型之一輸出獲得自預定義訊息類別之一集合選擇的該訊息之一訊息類別；以及 判定該訊息類別係關於出貨追蹤。
12. 如請求項10之電腦實施方法，其中判定該訊息係關於追蹤該出貨包含： 將該URL輸入至該一或多個ML模型中； 自該一或多個ML模型之一輸出獲得自預定義URL類別之一集合選擇的該URL之一URL類別；以及 判定該URL類別係關於出貨追蹤。
13. 如請求項1或2之電腦實施方法，其中： 該訊息對應於一特定使用者；且 儲存該出貨資訊包含將該出貨資訊儲存於用於與該特定使用者相關聯之複數個出貨之一出貨資訊記錄中， 該方法進一步包含輸出該出貨資訊記錄之至少一部分以用於顯示於與該特定使用者相關聯之一裝置上。
14. 一種系統，其包含： 至少一個處理器，其經組態以進行如前述請求項中任一項之方法；及 記憶體，其用以儲存該出貨資訊。
15. 一種電腦程式，其在執行於一電腦之一處理器上時經組態以進行如請求項1至13中任一項之方法。

Images