JP2022027520A - デジタルメッセージから情報を取得するためのシステムおよび方法 - Google Patents

Abstract

【課題】デジタルメッセージから情報を取得するためのシステムおよび方法の提供。【解決手段】本開示は、部分的に、メッセージ内のｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ）を用いて応報を取得するためのシステムおよび方法に関している。情報は、確率的方法を用いてＵＲＬから取得され得、確率的方法は、決定論的方法より良い結果を達成し得る。さらに、ＵＲＬから取得された情報は、ＵＲＬに関連付けられたウェブリソースから取得された情報を用いて補足され、および／または確認され得る。ある実施形態によると、ウェブリソースについてのＵＲＬは、メッセージに対応するデジタルコンテンツから取得される。そして、配送情報は、ＵＲＬおよびウェブリソースに基づいて取得され得る。【選択図】図４

Description

本願は、デジタルメッセージから情報を取得することに関しており、特定の実施形態では、デジタルメッセージから配送情報を取得することに関している。

顧客がオンラインストアを通して製品を注文すると、顧客は、製品の配送を追跡するための配送情報を提供するｅメールまたは他のメッセージを受信し得る。この配送情報は、配送を促進している配送プロバイダと、配送についての追跡番号と、配送を追跡するためのウェブページまたは他のウェブリソースに対応するｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ）とを含み得る。ウェブリソースを用いて、顧客は、配送の状況および／または配送についての予想される送達日を視認することが可能であり得る。ウェブリソースは、配送プロバイダおよび／または配送についての追跡番号も含み得る。

いくつかの場合、配送情報を提供するメッセージが、顧客の受信トレイ内に埋もれるようになり、顧客が後にメッセージを見つけて配送情報を取得することを困難にし得る。この問題は、オンラインで頻繁に製品を注文し、任意の所与の時に複数の係属中の製品配送を有し得る顧客についてひどくなり得る。これらの配送の各々についての追跡情報が、しばしば異なるメッセージ中に提供され、それは、まとめることが難題であり、時間がかかり得る。したがって、顧客は、いくつかの製品についての配送情報を見つけることが困難であり得、それらの製品を追跡し損なうことさえあり得る。加えて、または、あるいは、所与の配送についての追跡情報を提供するメッセージは、顧客が良く慣れ親しんでいないこともある言語で記述され得、追跡情報の識別、発見、および／または理解を妨げ得る。

本開示のいくつかの実施形態は、ｅメールメッセージ、テキストメッセージ等を含むユーザのデジタルメッセージから配送情報を自動で抽出するためのコンピュータ実装システムおよびコンピュータ実装方法を提供する。そして、配送情報は、ユーザのための配送情報の一元管理されたリストに追加され得、ユーザがメッセージおよび／または配送情報を手動でまとめ、追跡し続けることを避けることを可能にする。つまり、抽出されると、配送情報等は、例えば、画定されおよび／もしくは一貫したフォーマット等でユーザに提示され得、ならびに／または、そのような提示を提供することにおいて採用され得る。便利なことに、このようにして、顧客／ユーザは、例えば未解決の配送（例えば、まだ送達されていない配送）の全てをリストアップする集約された概要等の各種の配送に関する一見しただけで分かる情報を提示され得、配送情報は、メッセージの組（例えば、ユーザの１つ以上の受信トレイ）に基づいて識別される。加えて、または、あるいは、そのような配送情報は、例えば、潜在的に彼らの目立った配送のうちのいくつかまたはそれら全てについての彼らの種々の配送に関する最新情報をユーザに提供するため等、他の目標のために採用され得る。例えば、そのような最新情報は、画定されおよび／または一貫したフォーマットでユーザに一緒に提示され得る。特定の例では、そのような最新情報は、種々の配送についての追跡情報／最新情報をリストアップし、またはそれらへのアクセスを提供するもの等、好適な集約された概要によって提示され得る。

例えばｅメールメッセージ等のメッセージに基づく配送情報の識別は、各種の理由のために、些細ではないことがある。第１に、配送情報を提供するメッセージは、各種のフォーマットであり得る。例えば、特定の商人／配送業者／キャリアからの係属中の配送に関する情報を提供するメッセージは、（例えば、メッセージの内容および／またはメッセージ内のそのレイアウト／配置の点で）第１のフォーマットであり得る一方、別の商人／配送業者／キャリアは、異なるフォーマットを採用し得る。さらに、そのようなフォーマットは、経時的に変化し得、または同一の商人／配送業者／キャリアについてすら、種々の要因に依存して変動し得る。加えて、いくつかの場合、配送の指示を提供するメッセージは、メッセージ内に直接配送情報を含まないこともあり、むしろ、ウェブページまたは他のウェブリソースにアクセスするために用いられ得る１つ以上のＵＲＬを含み得、それによって、所与の配送に関する情報が取得され得る。例えば、そのような情報は、追跡情報、追跡番号等を含み得る。これらのＵＲＬおよびそれらが対応するウェブページのフォーマットは、メッセージのフォーマットに関して上で議論されたものと同様に、商人／配送業者／キャリア間で変動し得る。さらに、ＵＲＬのフォーマットおよび／またはそれらが対応するウェブページのコンテンツ／レイアウト／フォーマットが商人／配送業者／キャリア間で変動し得るのみならず、いくつかの場合、それらは、所与の商人／配送業者／キャリアについても、経時的におよび／または種々の他の要因に基づいて、変動し、または変化し得る。

本願は、メッセージに基づいて配送情報を取得し抽出する種々の態様を説明している。例えば、配送情報は、例えばユーザのｅメール受信トレイおよび／またはユーザのテキストメッセージ（ＳＭＳ）受信トレイ等のユーザの受信トレイ（単数または複数）内に到達するメッセージに基づいて取得され得る。いくつかの実施形態では、配送情報は、ａ）メッセージからＵＲＬを抽出すること、ｂ）ＵＲＬを分析して、配送情報を決定し、および／またはそれらを確認すること、ｃ）ＵＲＬに対応するウェブリソースを分析して、配送情報を決定し、および／またはそれらを確認することによって、メッセージから取得される。確率的方法が、ＵＲＬおよび／またはウェブリソースから配送情報を決定するために提供される。例えば決定論的方法と比較して、これらの確率的方法は、製品の配送において採用され得る莫大な数の配送プロバイダ、履行ネットワーク、郵便サービスプロバイダ、およびラストマイル送達サービスを取り扱うのにより好適であり得る。したがって、確率的方法は、メッセージから配送情報を決定するためのより信頼性の高い手法を提供し得る。

本開示のある側面によると、コンピュータ実装方法が提供される。方法は、顧客のための複数のメッセージを識別することと、複数のメッセージから少なくとも１つの配送についての配送情報を抽出することとを含む。抽出することは、複数のメッセージのうちの所与のメッセージに対応するデジタルコンテンツを取得することと、デジタルコンテンツからウェブリソースについてのＵＲＬを取得することとを含む。方法は、ＵＲＬとウェブリソースとに基づいて、配送についての配送情報を決定することも含む。配送情報は、ウェブリソースが配送を追跡するためものであることの指示と、配送についての追跡番号と、配送についての配送プロバイダとのうちの少なくとも１つを含む。方法は、配送についての追跡最新情報を取得するために、配送情報をメモリ内に記憶することをさらに含む。

配送情報は、少なくとも１つの配送についての追跡最新情報を取得するために用いられ得る。追跡最新情報は、顧客についての製品配送の集約された概要を提示することにおける使用のために提供され得る。

配送情報は、数多くの異なる手法のうちのいずれかで、ＵＲＬおよびウェブリソースから決定され得る。いくつかの実施形態では、配送情報を決定することは、ＵＲＬを構文解析することによって、追跡番号と配送プロバイダとを決定することと、ウェブリソースを構文解析することによって、追跡番号と配送プロバイダとを確認することとを含む。いくつかの実施形態では、配送情報を決定することは、ＵＲＬを構文解析することによって、追跡番号と配送プロバイダとのうちの一方を決定することと、ウェブリソースを構文解析することによって、追跡番号と配送プロバイダとのうちの他方を決定することとを含む。いくつかの実施形態では、配送情報を決定することは、ウェブリソースを構文解析することによって、追跡番号と配送プロバイダとを決定することを含む。

機械学習（ＭＬ）モデルは、配送情報を決定することに役立つように実施され得る。これらのＭＬモデルのうちのいずれか、それらのうちの１つ、それらのうちのいくつか、またはそれら全てが、マルチタスク学習（ＭＴＬ）モデルであり得る。いくつかの実施形態では、配送情報を決定することは、ＭＬモデルにＵＲＬを入力することと、ＭＬモデルの出力に基づいて、ＵＲＬから追跡番号に対応する文字列を取得することとを含む。配送情報を決定することは、予測を取得することであって、予測は、ＵＲＬ中の追跡番号の始まりに対応する第１のインデックスと、ＵＲＬ中の追跡番号の終わりに対応する第２のインデックスとを備えている、ことと、ＭＬモデルに第１のインデックスと第２のインデックスとを入力することとをさらに含み得る。

いくつかの実施形態では、配送情報を決定することは、ＭＬモデルにＵＲＬを入力することと、ＭＬモデルの出力から、所定の配送情報の組から選択される配送プロバイダに対応する文字列を取得することとを含む。

いくつかの実施形態では、複数のＵＲＬは、メッセージのデジタルコンテンツから取得され得る。例えば、方法は、デジタルコンテンツから第２のウェブリソースについての第２のＵＲＬを取得することさらに含み得る。方法は、第２のＵＲＬと第２のウェブリソースとに基づいて、第２のウェブリソースが配送を追跡するためのものであることと、配送についての第２の追跡番号と、配送についての第２の配送プロバイダとを決定することも含み得る。第１のＵＲＬおよび第２のＵＲＬは、同一の配送に関していることもある。したがって、方法は、第１の追跡番号が第２の追跡番号に合致することと、第１の配送プロバイダが第２の配送プロバイダに合致することとを決定することをさらに含み得る。

いくつかの実施形態では、方法は、デジタルコンテンツに基づいて、メッセージが配送を追跡することに関していることを決定するステップをさらに含み得る。このステップは、ＭＬモデルにデジタルコンテンツを入力することと；ＭＬモデルの出力から、所定のメッセージカテゴリの組から選択されるメッセージについてのメッセージカテゴリを取得することと；メッセージカテゴリが配送追跡に関していることを決定することとを含み得る。同様に、または、代わりに、このステップは、ＭＬモデルにＵＲＬを入力することと；ＭＬモデルの出力から、所定のＵＲＬカテゴリの組から選択されるＵＲＬについてのＵＲＬカテゴリを取得することと；ＵＲＬカテゴリが配送追跡に関していることを決定することとを含む。

いくつかの実施形態では、メッセージは、特定のユーザに対応している。方法は、特定のユーザに関連付けられた複数の配送についての配送情報レコード内に配送情報を記憶することを含み得る。このレコードは、ユーザによって視認可能である。したがって、方法は、特定のユーザに関連付けられたデバイス上での表示のために配送情報レコードの少なくとも一部を出力することをさらに含み得る。

本開示の別の側面によると、システムが提供され、システムは、配送情報を記憶するためのメモリと、本明細書中で開示される任意の方法を実施するための１つ以上のプロセッサとを含む。

本開示のさらなる側面によると、命令を記憶しているコンピュータ読み取り可能な媒体が提供され、命令は、コンピュータシステムのプロセッサによって実行されると、コンピュータシステムに本明細書中で開示される任意の方法を実施させる。

本開示のさらなる側面によると、コンピュータプログラムが提供され、コンピュータプログラムは、コンピュータのプロセッサ上で実行されると、本明細書中で開示される任意の方法を実行するように構成されている。

よって、後に続く請求項において詳説される方法、システム、およびコンピュータプログラムが、提供される。
本発明は、例えば以下を提供する。
（項目１）
コンピュータ実装方法であって、前記コンピュータ実装方法は、
顧客についての複数のメッセージを識別することと、
前記複数のメッセージのうちのメッセージから、少なくとも１つの配送についての配送情報を抽出することであって、抽出することは、
前記複数のメッセージの所与のメッセージに対応するデジタルコンテンツを取得することと、
前記デジタルコンテンツからウェブリソースについてのｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ）を取得することと、
１つ以上の機械学習（ＭＬ）モデルに前記ＵＲＬを入力し、前記１つ以上のＭＬモデルの出力に基づいて、前記ＵＲＬから追跡番号に対応する文字列を取得することによって、前記ＵＲＬおよび前記ウェブリソースに基づいて、特定の配送についての配送情報を決定することと
を含み、
前記配送情報は、
前記ウェブリソースが前記特定の配送を追跡するためのものであることの指示と、
前記特定の配送についての追跡番号と、
前記特定の配送についての配送プロバイダと
のうちの少なくとも１つを備えている、ことと
前記特定の配送についての追跡最新情報を取得するために前記配送情報をメモリ内に記憶することと
を含む、コンピュータ実装方法。
（項目２）
前記配送情報に基づいて、前記少なくとも１つの配送についての追跡最新情報を取得することと、
前記顧客についての製品配送の集約された概要を提示することにおける使用のために前記追跡最新情報を提供することと
をさらに含む、上記項目に記載のコンピュータ実装方法。
（項目３）
前記配送情報を決定することは、
予測を取得することであって、前記予測は、前記ＵＲＬ中の前記追跡番号の始まりに対応する第１のインデックスと、前記ＵＲＬ中の前記追跡番号の終わりに対応する第２のインデックスとを備えている、ことと、
前記第１のインデックスと前記第２のインデックスとを前記１つ以上のＭＬモデルに入力することと
をさらに含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目４）
前記配送情報を決定することは、
前記１つ以上のＭＬモデルに前記ＵＲＬを入力することと、
前記１つ以上のＭＬモデルの出力から、所定の配送プロバイダの組から選択される前記配送プロバイダに対応する文字列を取得することと
を含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目５）
前記配送情報を決定することは、
前記ＵＲＬを構文解析することによって、前記追跡番号と前記配送プロバイダとを決定することと、
前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとを確認することと
を含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目６）
前記配送情報を決定することは、
前記ＵＲＬを構文解析することによって、前記追跡番号と前記配送プロバイダとのうちの一方を決定することと、
前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとのうちの他方を決定することと
を含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目７）
前記配送情報を決定することは、前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとを決定することを含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目８）
前記１つ以上のＭＬモデルのうちの少なくとも１つは、マルチタスク学習モデルを備えている、上記項目のいずれかに記載のコンピュータ実装方法。
（項目９）
前記ＵＲＬは、第１のＵＲＬであり、前記ウェブリソースは、第１のウェブリソースであり、前記追跡番号は、第１の追跡番号であり、前記配送プロバイダは、第１の配送プロバイダであり、前記方法は、
前記デジタルコンテンツから、第２のウェブリソースについての第２のＵＲＬを取得することと、
前記第２のＵＲＬと前記第２のウェブリソースとに基づいて、
前記第２のウェブリソースが前記配送を追跡するためのものであることと、
前記配送についての第２の追跡番号と、
前記配送についての第２の配送プロバイダと
を決定することと、
前記第１の追跡番号が前記第２の追跡番号に合致することと、前記第１の配送プロバイダが前記第２の配送プロバイダに合致することとを決定することと
をさらに含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目１０）
前記デジタルコンテンツに基づいて、前記メッセージが前記配送を追跡することに関していることを決定することをさらに含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目１１）
前記メッセージが前記配送を追跡することに関していることを決定することは、
前記１つ以上のＭＬモデルに前記デジタルコンテンツを入力することと、
前記１つ以上のＭＬモデルの出力から、所定のメッセージカテゴリの組から選択される前記メッセージについてのメッセージカテゴリを取得することと、
前記メッセージカテゴリが配送追跡に関していることを決定することと
を含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目１２）
前記メッセージが前記配送を追跡することに関していることを決定することは、
前記１つ以上のＭＬモデルに前記ＵＲＬを入力することと、
前記１つ以上のＭＬモデルの出力から、所定のＵＲＬカテゴリの組から選択される前記ＵＲＬについてのＵＲＬカテゴリを取得することと、
前記ＵＲＬカテゴリが配送追跡に関していることを決定することと
を含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目１３）
前記メッセージは、特定のユーザに対応しており、
前記配送情報を記憶することは、前記特定のユーザに関連付けられた複数の配送についての配送情報レコード内に前記配送情報を記憶することを含み、
前記方法は、前記特定のユーザに関連付けられたデバイス上での表示のために、前記配送情報レコードのうちの少なくとも一部を出力することをさらに含む、上記項目のいずれかに記載のコンピュータ実装方法。
（項目１４）
システムであって、前記システムは、
上記項目のいずれかに記載の方法を実行するように構成されている少なくとも１つのプロセッサと、
前記配送情報を記憶するためのメモリと
を備えている、システム。
（項目１５）
コンピュータプログラムであって、前記コンピュータプログラムは、コンピュータのプロセッサ上で実行されると、上記項目のいずれかに記載の方法を実行するように構成されている、コンピュータプログラム。
（摘要）
本開示は、部分的に、メッセージ内のｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ）を用いて応報を取得するためのシステムおよび方法に関している。情報は、確率的方法を用いてＵＲＬから取得され得、確率的方法は、決定論的方法より良い結果を達成し得る。さらに、ＵＲＬから取得された情報は、ＵＲＬに関連付けられたウェブリソースから取得された情報を用いて補足され、および／または確認され得る。ある実施形態によると、ウェブリソースについてのＵＲＬは、メッセージに対応するデジタルコンテンツから取得される。そして、配送情報は、ＵＲＬおよびウェブリソースに基づいて取得され得る。

実施形態が、添付の図を参照して単に例として説明される。

図１は、一実施形態によるｅコマースプラットフォームのブロック図である。

図２は、一実施形態によるアドミニストレータのホームページの例である。

図３は、図１のｅコマースプラットフォームであるが、メッセージ分析エンジンを含むｅコマースプラットフォームを例証している。

図４は、ある実施形態によるデジタルメッセージから情報を取得するためのシステムを例証しているブロック図である。

図５は、ある実施形態によるメッセージを分析して配送情報を取得するための方法を例証しているフロー図である。

図６は、ある実施形態による配送を追跡することに関しているｅメールメッセージを例証している。

図７は、図６のｅメールメッセージ内の追跡ＵＲＬに対応するウェブページを例証している。

図８は、別の実施形態による配送を追跡することに関しているｅメールメッセージを例証している。

図９は、図８のｅメールメッセージ内の追跡ＵＲＬに対応するウェブページを例証している。

図１０は、ある実施形態による一元管理された配送情報のレコードを例証している。

例証の目的のために、ここで、特定の例示的実施形態が、図面と共に以下でより詳細に説明される。
例示的ｅコマースプラットフォーム

いくつかの実施形態では、本明細書中で開示される方法は、コマースプラットフォームにおいて、またはそれに関連付けられて実装され得、コマースプラットフォームは、本明細書中で、ｅコマースプラットフォームと称される。したがって、ｅコマースプラットフォームの例が説明される。

図１は、一実施形態によるｅコマースプラットフォーム１００を例証している。ｅコマースプラットフォーム１００は、商人の製品およびサービスを顧客に提供するために用いられ得る。本開示は、製品およびサービスを購入するための装置、システムおよびプロセスを用いることを想定しているが、本明細書中の説明は、単純化のため、製品に言及する。この開示全体にわたる製品への全ての言及は、物理的製品、デジタルコンテンツ、チケット、サブスクリプション、提供されるサービス等を含む製品および／またはサービスにも言及していることを理解されるべきである。

本開示は、全体にわたって、「商人」および「顧客」は、個人より多いこともあることを構想しているが、単純化のため、本明細書中の説明は、概してそのように商人および顧客に言及する。商人および顧客への全ての言及が、この開示全体にわたって、個人、会社、企業、コンピューティングエンティティ等の群に言及し、製品の営利または非営利の交換を表し得ることも理解されるべきである。さらに、本開示は、全体にわたって、「商人」および「顧客」に言及し、そのように彼らの役割を説明するが、ｅコマースプラットフォーム１００は、ｅコマース環境においてユーザをより一般的にサポートすることを理解されるべきであり、この開示全体にわたる商人および顧客への全ての言及は、ユーザが、商人ユーザ（例えば、製品の売り手、小売業者、卸売業者、またはプロバイダ）、顧客ユーザ（例えば、製品の買い手、購入エージェント、または製品のユーザ）、潜在的ユーザ（例えば、閲覧しているユーザおよびまだ購入を確約していないユーザ、製品をマーケティングし販売することにおける潜在的な使用についてｅコマースプラットフォーム１００を評価するユーザ等）、サービスプロバイダユーザ（例えば、配送プロバイダ１１２、金融プロバイダ等）、会社ユーザまたは企業ユーザ（例えば、製品の購入、販売、または使用を代表する会社、事業者ユーザ、顧客関連または顧客管理の代理人等）、情報テクノロジーユーザ、コンピューティングエンティティユーザ（例えば、製品の購入、販売、または使用のためのコンピューティングボット）である場合等のユーザに言及していることも理解されるべきである。

ｅコマースプラットフォーム１００は、商人に彼らのビジネスを管理するためのオンラインリソースおよびオンラインファシリティを提供する集中型システムを提供し得る。本明細書中で説明されるファシリティは、プラットフォーム１００の一部または外部であり得る１つ以上のプロセッサにおいてコンピュータソフトウェア、モジュール、プログラムコード、および／または命令を実行する機械を通じて部分的または全体的に展開され得る。商人は、例えば、オンラインストア１３８を通じて、チャンネル１１０Ａ－Ｂを通じて、物理的場所にあるＰＯＳデバイス１５２（例えば、キオスク、端末、リーダ、プリンタ、３Ｄプリンタ等を通じて物理的な店頭または他の場所）を通じて、顧客におけるｅコマース体験を実装することによって、ｅコマースプラットフォーム１００を通じて彼らのビジネスを管理することによって、ｅコマースプラットフォーム１００の通信ファシリティ１２９を通じて顧客と相互作用することによって、またはこれらの任意の組み合わせによって、顧客とのコマースを管理するために、ｅコマースプラットフォーム１００を活用し得る。商人は、顧客との唯一のコマースプレゼンスとして、または物理的店舗（例えば、「ブリックアンドモルタル」小売店）、プラットフォーム外の商人のウェブサイト１０４（例えば、コマースインターネットウェブサイト、またはｅコマースプラットフォームとは別個で商人によって、またはその代理でサポートされた他のインターネットもしくはウェブプロパティまたはアセット）を通じて等、他の商人コマースファシリティと共にｅコマースプラットフォーム１００を活用し得る。しかしながら、これらの「他の」商人コマースファシリティも、ｅコマースプラットフォーム内に統合され得る（例えば、商人の物理的店舗内のＰＯＳデバイス１５２がｅコマースプラットフォーム１００につながれる場合、プラットフォーム外の商人のウェブサイト１０４からオンラインストア１３８にコンテンツをつなぐ「買うボタン」を通じて、プラットフォーム外の商人のウェブサイト１０４がｅコマースプラットフォーム１００内に結び付けられている場合等）。

オンラインストア１３８は、複数の仮想的店頭を備えているマルチテナントファシリティを表し得る。実施形態では、商人は、例えば商人デバイス１０２（例えば、コンピュータ、ラップトップコンピュータ、モバイルコンピューティングデバイス等）を通じて、オンラインストア１３８内の１つ以上の店頭を管理し、数多くの異なるチャンネル１１０Ａ－Ｂ（例えば、オンラインストア１３８、ＰＯＳデバイス１５２を通じた物理的店頭、（ソーシャルネットワーク、ソーシャルメディアページ、ソーシャルメディアメッセージシステム等のウェブサイトまたはソーシャルメディアチャンネルに統合された電子的買うボタンを通じた電子的市場等）を通じて製品を顧客に提供し得る。商人は、チャンネル１１０Ａ－Ｂを横断して販売し、そして、ｅコマースプラットフォーム１００を通じて彼らの販売を管理し得、チャンネル１１０Ａは、ｅコマースプラットフォーム１００の内部に、またはｅコマースチャンネル１１０Ｂの外部から提供され得る。商人は、例えば彼らの物理的小売店で販売し、ポップアップで販売し、卸売りを通して販売し、電話で販売し、そして、ｅコマースプラットフォーム１００を通じて彼らの販売を管理し得る。商人は、これらの全てまたは任意の組み合わせを使用し、ＰＯＳデバイス１５２を活用している物理的店頭を通してビジネスを維持し、オンラインストア１３８を通じて仮想的店頭を維持し、顧客相互作用に影響を与えるために通信ファシリティ１２９を活用し、販売の利益を向上させるために分析１３２を活用し得る。この開示全体にわたって、オンラインストア１３８および店頭という語は、同義的に、ｅコマースプラットフォーム１００を通じた商人のオンラインｅコマース提供主体を指すために用いられ得、オンラインストア１３８は、（例えば、複数の商人のための）ｅコマースプラットフォーム１００によってサポートされた店頭のマルチテナント集合体、または個々の商人の店頭（例えば、商人のオンラインストア）を指し得る。

いくつかの実施形態では、顧客は、顧客デバイス１５０（例えば、コンピュータ、ラップトップコンピュータ、モバイルコンピューティングデバイス等）、ＰＯＳデバイス１５２（例えば、小売りデバイス、キオスク、自動勘定システム等）、または業界で知られている任意の他のコマースインタフェースデバイスを通じて相互作用し得る。ｅコマースプラットフォーム１００は、オンラインストア１３８を通じて、物理的場所（例えば、商人の店頭または他の場所）にあるＰＯＳデバイス１５２を通じて、顧客に到達すること、電気通信ファシリティ１２９を介した顧客との対話を通じて顧客とのコマースを促進すること等を可能にし得、顧客に到達し顧客と相互作用するために利用可能な実通路または仮想通路に関して、顧客に到達し商人サービスを促進するためのシステムを提供する。

いくつかの実施形態では、本明細書中でさらに説明されるように、ｅコマースプラットフォーム１００は、プロセッサおよびメモリを含む処理ファシリティを通じて実装され得、処理ファシリティは、一連の命令を記憶しており、命令が実行されたとき、ｅコマースプラットフォーム１００は、本明細書で説明されるようにｅコマースを実施し、機能をサポートする。処理ファシリティは、サーバ、クライアント、ネットワークインフラストラクチャ、モバイルコンピューティングプラットフォーム、クラウドコンピューティングプラットフォーム、固定コンピューティングプラットフォーム、または他のコンピューティングプラットフォームの一部であり、ｅコマースプラットフォーム１００の電子コンポーネント、商人デバイス１０２、支払いゲートウェイ１０６、アプリケーション開発者、チャンネル１１０Ａ－Ｂ、配送プロバイダ１１２、顧客デバイス１５０、販売時点管理デバイス１５２等の間の電子的接続および通信を提供し得る。ｅコマースプラットフォーム１００は、ソフトウェアがサブスクリプションベースでライセンスを与えられ、一元的にホストされた（たとえば、Ｗｅｂブラウザまたは他のアプリケーションを介してクライアント（例えば、シンクライアント）を用いてユーザによってアクセスされる、ＰＯＳデバイスによってアクセスされる等）ソフトウェアおよび送達モデル等における、クラウドコンピューティングサービス、ソフトウェア・アズ・ア・サービス（ＳａａＳ）、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）、プラットフォーム・アズ・ア・サービス（ＰａａＳ）、デスクトップ・アズ・ア・サービス（ＤａａＳ）、管理型ソフトウェア・アズ・ア・サービス（ＭＳａａＳ）、モバイル・バックエンド・アズ・ア・サービス（ＭＢａａＳ）、情報テクノロジ管理・アズ・ア・サービス（ＩＴＭａａＳ）等として実装され得る。いくつかの実施形態では、ｅコマースプラットフォーム１００の要素は、種々のプラットフォーム、およびｉＯＳ、Ａｎｄｒｏｉｄ等のオペレーティングシステムにおいて、ならびにＷｅｂ上等で動作するように実装され得る（例えば、アドミニストレータ１１４は、多くの場合、ｉＯＳ、Ａｎｄｒｏｉｄ用の所与のオンラインストア、およびＷｅｂにおいて実装され、各々は同様の機能を有する）。

いくつかの実施形態では、オンラインストア１３８は、ｅコマースプラットフォーム１００のサーバによって提供されるウェブページを通じて顧客デバイス１５０にサービス提供され得る。サーバは、ブラウザまたは顧客デバイス１５０にインストールされた他のアプリケーションからウェブページの要求を受信し得、ブラウザ（または他のアプリケーション）は、ＩＰアドレスを通じてサーバに接続し、ＩＰアドレスは、ドメイン名を翻訳することによって取得される。これに対し、サーバは、要求されたウェブページを送り返す。ウェブページは、Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＨＴＭＬ）、テンプレート言語、ＪａｖａＳｃｒｉｐｔ（登録商標）またはこれらの任意の組み合わせで記述されているか、またはそれらを含み得る。例えば、ＨＴＭＬは、ウェブページのレイアウト、フォーマット、およびコンテンツ等のウェブページに関する静的情報を記述するコンピュータ言語である。ウェブサイトの設計者および開発者は、テンプレート言語を用いて、複数のページで同一である静的コンテンツと、１つのページから次のページへと変化する動的コンテンツとを組み合わせるウェブページを構築し得る。テンプレート言語は、オンラインストアからのデータでページを動的に追加する一方で、ウェブページのレイアウトを画定する静的要素を再利用することを可能にし得る。静的要素は、ＨＴＭＬで書かれ得、動的要素は、テンプレート言語で書かれ得る。ファイル内のテンプレート言語要素は、プレースホルダーとして機能し、それによって、ファイル内のコードは、コンパイルされて顧客デバイス１５０に送られ、その後、テンプレート言語は、テーマがインストールされるとき等に、オンラインストア１３８からのデータによって置き換えられる。テンプレートおよびテーマは、タグ、オブジェクト、およびフィルタを考慮し得る。そして、クライアントデバイスウェブブラウザ（または他のアプリケーション）は、それに応じて、ページをレンダリングする。

いくつかの実施形態では、オンラインストア１３８は、ｅコマースプラットフォーム１００によって顧客に提供され得、顧客は、種々の取り扱い製品を閲覧および購入し得る（例えば、製品をカートに追加する、買うボタンを通じて即購入する等）。オンラインストア１３８は、製品が（直接商人から購入するのではなく）ｅコマースプラットフォーム１００を通じて提供されていることを顧客が必ずしも気付かない透明な手法で顧客に提供され得る。商人は、商人が構成可能なドメイン名、カスタマイズ可能なＨＴＭＬテーマ等を用いて、彼らのオンラインストア１３８をカスタマイズし得る。商人は、テーマシステムを通じて彼らのウェブサイトの見た目および雰囲気をカスタマイズし得、例えば、商人は、オンラインストア１３８の製品のヒエラルキー内に示される同一の下位の製品およびビジネスデータを示しながらオンラインストアのテーマを変更することによって、彼らのオンラインストアの見た目および雰囲気を選択および変更し得る。テーマは、テーマエディタおよびデザインインタフェースを通じてさらにカスタマイズされ得、デザインインタフェースは、ユーザが彼らのウェブサイトのデザインを柔軟にカスタマイズすることを可能にする。テーマは、特有の色、フォント、および予め構築されているレイアウトスキーム等の側面を変更するテーマ特有の設定を用いることによってもカスタマイズされ得る。オンラインストアは、ウェブサイトコンテンツのためのコンテンツ管理システムを実装し得る。商人は、ブログ投稿または静的ページを作り、ブログ、記事等を通じて彼らのオンラインストア１３８にそれらを発信するのみならず、ナビゲーションメニューも構成し得る。商人は、システムによる格納（例えば、データ１３４）等のために、画像（例えば、製品の画像）、ビデオ、コンテンツ、データ等をｅコマースプラットフォーム１００にアップロードし得る。いくつかの実施形態では、ｅコマースプラットフォーム１００は、画像をサイズ変更し、画像を製品に関連付け、画像にテキストを追加し関連付け、新たな製品バリエーションの画像を追加し、画像を保護するため等の機能を提供し得る。

本明細書中で説明されるように、ｅコマースプラットフォーム１００は、オンラインストア１３８、電話を介してのみならず、本明細書中で説明されるような物理的ＰＯＳデバイス１５２も含む多くの異なるチャンネル１１０Ａ－Ｂを通じて、製品の取引ファシリティを商人に提供し得る。ｅコマースプラットフォーム１００は、ビジネスサポートサービス１１６、アドミニストレータ１１４等を含み、それらは、彼らのオンラインストアに関連付けられたドメインサービス１１８、顧客との取引を促進するための支払いサービス１２０、購入された製品の配送オプションを顧客に提供するための配送サービス１２２、製品の保護および信頼性に関連付けられたリスクおよび保証サービス１２４、商人の請求等を提供する等、オンラインビジネスを営業することに関連付けられ得る。サービス１１６は、支払処理のための支払いゲートウェイ１０６、製品の配送を捗らせるための配送プロバイダ１１２等を通じて、ｅコマースプラットフォーム１００を介してまたは外部ファシリティに関連付けられて提供され得る。

いくつかの実施形態では、ｅコマースプラットフォーム１００は、リアルタイムの最新情報、追跡、自動的レート計算、バルクオーダ―準備、ラベル印刷等を商人に提供する等、統合型配送サービス１２２を（例えば、ｅコマースプラットフォーム配送ファシリティを通じて、または第三の配送キャリアを通じて）提供し得る。

図２は、アドミニストレータ１１４のホームページに関する非限定的な実施形態を描写し、日ごとのタスク、店舗の現在の活動、および商人が彼らのビジネスを構築するために取るべき次のステップについての情報を示し得る。いくつかの実施形態では、商人は、商人デバイス１０２を介して（デスクトップコンピュータまたはモバイルデバイスから等）アドミニストレータ１１４にログインし、商人のオンラインストア１３８の局面（オンラインストア１３８の現在の活動を視認すること、オンラインストア１３８のカタログを更新すること、注文、現在の訪問者の活動、および全体の注文活動等を管理すること等）を管理し得る。いくつかの実施形態では、商人は、例えば図２に示されるようなサイドバーを用いることによって、アドミニストレータ１１４の異なるセクションにアクセスすることが可能であり得る。アドミニストレータ１１４のセクションは、注文、製品、顧客、取り扱い報告および割引を含む商人のビジネスの核となる局面にアクセスし、それを管理するための種々のインタフェースを含み得る。アドミニストレータ１１４は、店舗のための販売チャンネルを管理するためのインタフェースも含み得、インタフェースは、オンラインストア、店舗にアクセスするために顧客に利用可能にされたモバイルアプリケーション（単数または複数）（モバイルアプリ）、ＰＯＳデバイス、および／または買うボタンを含む。アドミニストレータ１１４は、商人のアカウントにインストールされたアプリケーション（アプリ）を管理するためのインタフェース（商人のオンラインストア１３８およびアカウントに適用される設定）も含み得る。商人は、製品、ページ、または他の情報を見つけるために検索バーを用い得る。商人が使用しているデバイス１０２またはソフトウェアアプリケーションに依存して、商人は、アドミニストレータ１１４を通じて異なる機能を可能にされ得る。例えば、商人がブラウザからアドミニストレータ１１４にログインする場合、彼らは、彼らのオンラインストア１３８の全ての局面を管理することが可能であり得る。商人が彼らのモバイルデバイスから（例えばモバイルアプリケーションを介して）ログインする場合、彼らは、オンラインストア１３８の現在の活動を眺める、オンラインストア１３８のカタログを更新する、注文を管理する等、彼らのオンラインストア１３８の側面の全てまたは一部を視認することが可能であり得る。

コマースおよびオンラインストア１３８への訪問者に関するより詳細な情報は、商人のビジネス全体に関する売上概要、活動している販売チャンネルに関する特定の売上および従業員データ等を表示する等、獲得レポートまたはメトリクスを通じて見られ得る。レポートは、獲得レポート、行動レポート、顧客レポート、金融レポート、マーケティングレポート、売上レポート、カスタムレポート等を含み得る。商人は、ドロップダウンメニュー等を用いることによって、様々な期間（例えば、日、週、月等）から様々なチャンネル１１０Ａ－Ｂに関する売上データを見ることが可能であり得る。概観ダッシュボードも、店舗の売上および契約データのより詳細な図を望む商人に提供され得る。ホームメトリクスセクションにおける活動フィードは、商人のアカウントにおける活動の概観を例証するために提供され得る。例えば、「全ての現在の活動を見る」ダッシュボードボタンをクリックすることによって、商人は、彼らのアカウントにおける現在の活動のより長いフィードを見ることが可能であり得る。ホームページは、例えばアカウントステータス、成長、現在の顧客の活動等に基づいて、商人のオンラインストア１３８についての通知を示し得る。通知は、支払いを取り込む、履行された注文をマーキングする、完了した注文をアーカイブする等のプロセスを通じたナビゲーションで商人を支援するために提供され得る。

ｅコマースプラットフォーム１００は、商人、顧客、商人デバイス１０２、顧客デバイス１５０、ＰＯＳデバイス１５２等の間の通信相互作用を収集し分析するための電子メッセージ集約ファシリティを活用する等、電子通信を提供しマーケティングをするための通信ファシリティ１２９および関連付けられた商人インタフェースを提供し、製品の販売を提供するポテンシャルを増加させる等のために通信を集約し分析し得る。例えば、顧客は、製品に関連する質問を有し得、質問は、顧客と商人（または商人を代理する自動化されたプロセッサベースの代理人）との間の対話を生み出し得、通信ファシリティ１２９は、相互作用を分析し、販売に関する利益をどのように向上するかについて商人に分析を提供する。

ｅコマースプラットフォーム１００は、例えばセキュアカードサーバ環境を通じて、顧客との安全な金融取引のための金融ファシリティ１２０を提供し得る。ｅコマースプラットフォーム１００は、例えば、支払いカードインダストリーデータ（ＰＣＩ）環境（例えば、カードサーバ）等にクレジットカード情報を記憶し得、金融情報を照合し、商人に請求書を送り、（例えば、現金を用いているとき）ｅコマースプラットフォーム１００金融機関口座と商人の銀行口座との間の自動決済（ＡＣＨ）振替を実施する。これらのシステムは、Ｓａｒｂａｎｅｓ―Ｏｘｌｅｙ Ａｃｔ（ＳＯＸ）コンプライアンス、および、それらの開発および動作において要求される高いレベルの注意を有し得る。金融ファシリティ１２０は、例えば資金の貸し出し（例えば、貸出ファンド、現金前貸し等）および保険の付保を通して、商人に金融サポートも提供し得る。加えて、ｅコマースプラットフォーム１００は、マーケティングおよびパートナーサービスのセットを提供し、ｅコマースプラットフォーム１００とパートナーとの間の関係を制御し得る。それらは、新たな商人をｅコマースプラットフォーム１００に接続し、搭載し得る。これらのサービスは、商人がｅコマースプラットフォーム１００を横断して作業することを容易にすることによって商人の成長を可能にし得る。これらのサービスを通じて、商人は、ｅコマースプラットフォーム１００を介したヘルプファシリティを提供され得る。

いくつかの実施形態では、オンラインストア１３８は、数多くの独立して運営される店頭をサポートし、毎日の各種の製品に関する大量の取引データを処理し得る。取引データは、顧客連絡先情報、請求情報、配送情報、購入された製品の情報、与えられたサービスの情報、およびｅコマースプラットフォーム１００を通したビジネスに関連付けられた任意の他の情報を含み得る。いくつかの実施形態では、ｅコマースプラットフォーム１００は、データファシリティ１３４内にこのデータを記憶し得る。取引データは、分析１３２を生み出すために処理され得、ひいては、商人または第三のコマースエンティティに提供されて、顧客の傾向、マーケティングおよび売上の洞察、売上を向上するための推薦、顧客行動の評価、マーケティングおよび売上のモデル化、詐欺の傾向等を提供し、オンラインコマースに関連付けられ、レポートを通してダッシュボードインタフェースで提供され得る。ｅコマースプラットフォーム１００は、ビジネスおよび商人の取引についての情報を記憶し得、データファシリティ１３４は、データを強化し、データに貢献し、データを精錬し、データを抽出する多くの手段を有し得、収集されたデータは、経時的にｅコマースプラットフォーム１００の局面の改善を可能にし得る。

図１を再度参照すると、いくつかの実施形態では、ｅコマースプラットフォーム１００は、コンテンツ管理、タスク自動化、およびデータ管理のためのコマース管理エンジン１３６で構成され、（例えば、製品、在庫、顧客、注文、提携、供給者、レポート、金融、リスクおよび詐欺等に関連付けられた）複数のオンラインストア１３８のサポートおよびサービスを可能にし得るが、ｅコマースプラットフォーム１００は、アプリケーション１４２Ａ－Ｂを通して拡張可能であり得、アプリケーション１４２Ａ－Ｂは、多種多様な商人オンラインストア、ＰＯＳデバイス、製品、およびサービスに適応するために要求されるより高い柔軟性およびカスタム処理を可能にし、アプリケーション１４２Ａが、ｅコマースプラットフォーム１００の内部に提供され得、または、アプリケーション１４２Ｂが、ｅコマースプラットフォーム１００の外部に提供され得る。いくつかの実施形態では、アプリケーション１４２Ａは、プラットフォーム１００を提供する同じパーティによって、または異なるパーティによって提供され得る。いくつかの実施形態では、アプリケーション１４２Ｂは、プラットフォーム１００を提供する同じパーティによって、または異なるパーティによって提供され得る。コマース管理エンジン１３６は、例えば顧客識別子、注文識別子、オンラインストア識別子等による機能およびデータの分配（例えば、分割）を通じた柔軟性およびスケーラビリティのために構成され得る。コマース管理エンジン１３６は、店舗特有のビジネスロジックに適応し得、いくつかの実施形態では、アドミニストレータ１１４および／またはオンラインストア１３８を統合し得る。

コマース管理エンジン１３６は、ｅコマースプラットフォーム１００のベースまたは「核となる」機能を含み、そのため、本明細書中で説明されるように、オンラインストア１３８をサポートする全ての機能が、含めるのに適切であるわけではないこともある。例えば、コマース管理エンジン１３６内に含まれる機能は、「核となる」機能性のしきい値を超える必要があり得、「核となる」機能性のしきい値を通して、機能がコマース体験にとっての核であること（例えば、横断チャンネル、アドミニストレータインタフェース、商人の場所、産業、製品タイプ等のオンラインストア活動の大部分の共通性）、機能がオンラインストア１３８を横断して再利用可能であること（例えば核となる機能を横断して再利用／修正され得る機能）、同時に単一のオンラインストア１３８のコンテキストに限定されること（例えば、オンラインストア「分離原理」を実装し、この原理において、コードは、同時に複数のオンラインストア１３８と相互作用することが可能であるべきではなく、分離原理は、オンラインストア１３８が互いのデータにアクセスできないことを保証する）、取引仕事量を提供すること等が決定され得る。多くの要求される特徴が、コマース管理エンジン１３６によって直接提供されるか、または、アプリケーション１４２Ａ－Ｂおよびチャンネル１１０Ａ－Ｂへのアプリケーションプログラミングインタフェース（ＡＰＩ）接続を通じたその拡張等によってインタフェース１４０Ａ－Ｂを通して可能にされる（インタフェース１４０Ａは、ｅコマースプラットフォーム１００内のアプリケーション１４２Ａおよび／またはチャンネル１１０Ａに提供され、または、インタフェース１４０Ｂは、ｅコマースプラットフォーム１００の外部のアプリケーション１４２Ｂおよび／またはチャンネル１１０Ｂに提供され得る）かのいずれかである場合、どの機能が実装されるかということの制御をメンテナンスすることが、コマース管理エンジン１３６が応答可能であり続けることを可能にし得る。概して、プラットフォーム１００は、（拡張機能、コネクタ、ＡＰＩ等であり得る）インタフェース１４０Ａ－Ｂを含み得、インタフェース１４０Ａ－Ｂは、他のプラットフォーム、システム、ソフトウェア、データソース、コード等への接続およびそれらとの通信を促進する。そのようなインタフェース１４０Ａ－Ｂは、さらに概略的に、コマース管理エンジン１３６のインタフェース１４０Ａ、またはプラットフォーム１００のインタフェース１４０Ｂであり得る。ケアがコマース管理エンジン１３６内の規制機能に与えられない場合、低速データベースまたは致命的ではないバックエンドの破壊を通じたインフラストラクチャの劣化を通して、オフラインになっているデータセンター等による致命的なインフラストラクチャの破壊を通して、新たなコードが展開され、それが予期されるより実行するために長い時間を要することを通して、応答性が損なわれ得る。これらの状況を防ぐためにまたは軽減させるために、コマース管理エンジン１３６は、例えばタイムアウト、クエリ、劣化を防ぐバックプレッシャー等を活用する構成を通じて応答性を維持するように構成され得る。

オンラインストアデータを分離することは、オンラインストア１３８間および商人間のデータプライバシーを維持するために重要であるが、例えば注文リスク査定システムまたはプラットフォーム支払いファシリティ（注文リスク査定システムおよびプラットフォーム支払いファシリティの両方は、うまく実施するために複数のオンラインストア１３８からの情報を要求する）において相互店舗データを収集し使用する理由が存在し得る。いくつかの実施形態では、分離原理に違反することなく、これらのコンポーネントをコマース管理エンジン１３６の外部に移動させること、およびｅコマースプラットフォーム１００内のそれら自身のインフラストラクチャ内に移動させることが好まれ得る。

いくつかの実施形態では、ｅコマースプラットフォーム１００は、プラットフォーム支払いファシリティ１２０を提供し得、プラットフォーム支払いファシリティ１２０は、コマース管理エンジン１３６からのデータを活用するが分離原理に違反しないように外部に配置され得るコンポーネントの別の例である。プラットフォーム支払いファシリティ１２０は、オンラインストア１３８と相互作用する顧客が、コマース管理エンジン１３６によって安全に記憶された彼らの支払い情報を有することを可能にし、それによって、彼らは一度しか支払い情報を入力する必要がない。顧客が異なるオンラインストア１３８を訪問するとき、彼らが以前にその店舗に行ったことがない場合であっても、プラットフォーム支払いファシリティ１２０は、彼らの情報を回収し、より迅速で正確な勘定を可能にする。これは、クロスプラットフォームネットワーク効果を提供し得、例えば顧客の購入に関する使用の容易さのおかげでより頻繁に勘定をするより多くの顧客が存在するので、ｅコマースプラットフォーム１００は、より多くの商人が参加するにつれてその商人により有用となる。このネットワークの効果を最大化するために、所与の顧客に関する支払い情報は、オンラインストアの勘定から回収可能であり得、情報がオンラインストア１３８にわたって全体的に利用可能になることを可能にする。各オンラインストア１３８が任意の他のオンラインストア１３８に接続してそこに記憶された支払い情報を回収することが可能であることは、困難であり、誤りを起こしやすい。結果的に、プラットフォーム支払いファシリティは、コマース管理エンジン１３６の外部で実装され得る。

コマース管理エンジン１３６内に含まれていない機能に関して、アプリケーション１４２Ａ－Ｂは、ｅコマースプラットフォーム１００に特徴を追加する手段を提供する。アプリケーション１４２Ａ－Ｂは、例えば、商人のオンラインストア１３８にあるデータにアクセスし、これを修正し、アドミニストレータ１１４を通じてタスクを実施し、ユーザインタフェースを通じて商人のための新たなフローを創出し得る（例えば、それは、拡張機能／ＡＰＩを通じて示される）。商人は、アプリケーション検索、推薦およびサポート１２８を通じてアプリケーション１４２Ａ－Ｂを発見しインストールすることが可能にされ得る。いくつかの実施形態では、核となる製品、核となる拡張ポイント、アプリケーション、およびアドミニストレータ１１４が、共に作業するように開発され得る。例えば、アプリケーション拡張ポイントは、アドミニストレータ１１４の内部に構築され得、それによって、核となる特徴が、アプリケーションによって拡張され得、アプリケーションは、拡張機能を通じて機能を商人に送達し得る。

いくつかの実施形態では、アプリケーション１４２Ａ－Ｂは、インタフェース１４０Ａ－Ｂを通じて機能を商人に送達し得、例えば、アプリケーション１４２Ａ－Ｂは、取引データを商人に示すことが可能であり（例えば、アプリ：「エンジン、内臓アプリＳＤＫを用いてモバイル管理およびウェブ管理内の私のアプリデータを示して」）、および／またはコマース管理エンジン１３６は、要求された作業を実施することをアプリケーションに依頼することが可能である（エンジン：「アプリ、この勘定に関する地方税計算を私に提示して」）。

アプリケーション１４２Ａ－Ｂは、例えば、オンラインストア１３８およびチャンネル１１０Ａ－Ｂをサポートし、商人サポートを提供し、他のサービスと統合し得る。コマース管理エンジン１３６がオンラインストア１３８にサービスの基盤を提供し得る場合、アプリケーション１４２Ａ－Ｂは、商人が特定のニーズおよび時には独自のニーズを満足させるための手段を提供し得る。異なる商人は、異なるニーズを有するため、異なるアプリケーション１４２Ａ－Ｂから恩恵を受け得る。アプリケーション１４２Ａ－Ｂは、アプリケーション分類（カテゴリ）の開発を通じてｅコマースプラットフォーム１００を通してより見出され得、アプリケーション分類は、例えば、検索、ランキング、および推薦モデルをサポートするアプリケーションデータサービスを通じて、およびアプリケーションストア、ホーム情報カード、アプリケーション設定ページ等のアプリケーション発見インタフェースを通じて、アプリケーションが商人のために実施する機能のタイプによってアプリケーションがタグ付けされることを可能にする。

アプリケーション１４２Ａ－Ｂは、インタフェース１４０Ａ－Ｂを通じてコマース管理エンジン１３６に接続され得、例えば、ＡＰＩを活用して、（ＲＥＳＴ、ＧｒａｐｈＱＬ等を通じて）コマース管理エンジン１３６を通じてまたはその中で利用可能な機能およびデータをアプリケーションの機能に公開する。例えば、ｅコマースプラットフォーム１００は、アプリケーション拡張機能、プロセスフローサービス、開発者向けリソース等を含む商人およびパートナー向けの製品およびサービスにＡＰＩインタフェース１４０Ａ－Ｂを提供し得る。顧客がより頻繁にモバイルデバイスをショッピングのために用いることによって、モバイル使用に関連しているアプリケーション１４２Ａ－Ｂは、関連する増大するコマーストラフィックをサポートするためのＡＰＩのより拡張的な使用からの恩恵を受け得る。（例えばアプリケーション開発のために提供されるような）アプリケーションおよびＡＰＩの使用を通じて提供される柔軟性は、ｅコマースプラットフォーム１００が、コマース管理エンジン１３６に継続的な変更を要求することなく商人（および内部ＡＰＩを通じた内部開発者）の新しい独自のニーズにより良く適応することを可能にし、従って、商人が必要とするものを商人が必要とするときに商人に提供する。例えば、配送サービス１２２は、配送またはキャリアサービスＡＰＩを通じてコマース管理エンジン１３６と統合され得、従って、ｅコマースプラットフォーム１００がコマース管理エンジン１３６で実行しているコードに直接的に影響を及ぼすことなく、配送サービス機能を提供することを可能にする。

バックオフィス動作に関連する問題（商人向けのアプリケーション１４２Ａ－Ｂ）およびオンラインストア１３８における問題（顧客向けのアプリケーション１４２Ａ－Ｂ）等、多くの商人の問題は、パートナーがアプリケーション開発を通じて商人ワークフローを改善および拡張することによって解決され得る。ビジネスをする一部として、多くの商人は、バックオフィスタスク（例えば、販促、在庫、割引、履行等）およびオンラインストアタスク（例えば、彼らのオンラインストアショップに関連したアプリケーション、フラッシュセール、新製品の注文等）のために毎日モバイルおよびウェブ関連のアプリケーションを用い、アプリケーション１４２Ａ－Ｂは、拡張機能／ＡＰＩ１４０Ａ－Ｂを通じて、急速に成長する市場において製品を容易に見て購入することを助ける。いくつかの実施形態では、パートナー、アプリケーション開発者、内部アプリケーションファシリティ等は、例えばアプリケーションインタフェースをサンドボックスするアドミニストレータ１１４内のフレームを創出することを通じて、ソフトウェア開発キット（ＳＤＫ）を提供され得る。いくつかの実施形態では、アドミニストレータ１１４は、フレーム内で発生することを制御せず、発生したことに気付かないこともある。ＳＤＫは、ユーザインタフェースキットと共に用いられ、例えばコマース管理エンジン１３６の拡張機能として機能するｅコマースプラットフォーム１００のルックアンドフィールを模したインタフェースを生成し得る。

ＡＰＩを活用するアプリケーション１４２Ａ－Ｂは、要求されたデータをプルし得るが、それらは、更新が発生するときにデータがプッシュされる必要もある。例えば顧客創出、製品変更、または注文取消等の更新イベントは、サブスクリプションモデルにおいて実装され得る。更新イベントは、ローカルデータベースを同期させること、外部統合パートナーに通知すること等のためにコマース管理エンジン１３６の変更された状態に関して必要とされる更新を商人に提供し得る。更新イベントは、例えば更新イベントサブスクリプションを通じて更新を確認するためにコマース管理エンジン１３６を常にポーリングする必要なく、この機能を可能にし得る。いくつかの実施形態では、更新イベントサブスクリプションに関連する変更が発生すると、コマース管理エンジン１３６は、予め定義されたコールバックＵＲＬ等に要求を送り得る。この要求の本体は、オブジェクトの新たな状態と、アクションまたはイベントの記述とを含み得る。更新イベントサブスクリプションは、アドミニストレータファシリティ１１４において手動で、または（例えばＡＰＩ１４０Ａ－Ｂを介して）自動で創出され得る。いくつかの実施形態では、更新イベントは、待ち行列に入れられ、それらをトリガした状態変更から非同期で処理され得、それは、リアルタイムで分配されない更新イベント通知を生み出し得る。

いくつかの実施形態では、ｅコマースプラットフォーム１００は、アプリケーション検索、推薦およびサポート１２８を提供し得る。アプリケーション検索、推薦およびサポート１２８は、アプリケーションの開発において支援するための開発者製品およびツールと、（例えば、開発インタフェースを開発者に提供するため、アドミニストレータのアプリケーションの管理のため、商人のアプリケーションのカスタマイズのため等の）アプリケーションダッシュボードと、（例えば、インストールされる前に基準が満たされなければならない公衆アクセスのため、または商人による私的な使用のため等の公共アクセスのための）アプリケーション１４２Ａ－Ｂへのアクセスを提供することに関する許可をインストールおよび提供するためのファシリティと、商人のオンラインストア１３８のニーズを満足させるアプリケーション１４２Ａ－Ｂを商人が検索することを容易にするためのアプリケーション検索と、商人がどのようにして彼らのオンラインストア１３８を通じたユーザ体験を改善し得るかについての提案を商人に提供するためのアプリケーション推薦と、コマース管理エンジン１３６内の核となるアプリケーション能力の記述と等を含み得る。これらのサポートファシリティは、任意のエンティティによって実施されるアプリケーション開発によって活用され得、任意のエンティティは、彼ら自身のアプリケーション１４２Ａ－Ｂを開発する商人、アプリケーション１４２Ａ－Ｂを開発する第三開発者（例えば、アプリケーション１４２Ａ－Ｂは、商人によって契約され、公衆に提供するために独自で開発され、ｅコマースプラットフォーム１００に関連付けられた使用のために契約される）、またはｅコマースプラットフォーム１００に関連付けられた内部パーソナルリソースによって開発されるアプリケーション１４２Ａもしくは１４２Ｂを含む。いくつかの実施形態では、アプリケーション１４２Ａ－Ｂは、例えば、アプリケーションに（例えばＡＰＩを通して）リンクするために、アプリケーションを検索するために、アプリケーション推薦を作成するために、アプリケーション識別子（ＩＤ）を割り当てられ得る。

コマース管理エンジン１３６は、ｅコマースプラットフォーム１００のベース機能を含み、これらの機能をＡＰＩ１４０Ａ－Ｂを通じてアプリケーション１４２Ａ－Ｂに公開し得る。ＡＰＩ１４０Ａ－Ｂは、アプリケーション開発を通じて構築されたアプリケーションの異なるタイプを可能にし得る。アプリケーション１４２Ａ－Ｂは、商人の多様なニーズを満足させることを可能にし得るが、大まかに３つのカテゴリにグループに分けられ得る：顧客向けアプリケーション、商人向けアプリケーション、統合アプリケーション等。顧客向けアプリケーション１４２Ａ－Ｂは、オンラインストア１３８またはチャンネル１１０Ａ－Ｂを含み得、オンラインストア１３８またはチャンネル１１０Ａ－Ｂは、商人が製品をリストアップしそれらを購入してもらうことが可能な場所（例えば、オンラインストア、フラッシュセールのためのアプリケーション（例えば、商人製品または第三者リソースによる突発的なセールス機会からのもの）、モバイルストアアプリケーション、ソーシャルメディアチャンネル、卸売り購入を提供するためのアプリケーション等）である。商人向けアプリケーション１４２Ａ－Ｂは、商人が、（例えば、ウェブもしくはウェブサイト、またはモバイルデバイスに関連するアプリケーションを通じて）彼らのオンラインストア１３８を管理すること、彼らのビジネスを（例えばＰＯＳデバイスに関連するアプリケーションを通じて）営業すること、（例えば配送（例えば置き配）に関連するアプリケーション、自動化されたエージェントの使用、プロセスフロー開発および改善の使用を通じて）彼らのビジネスを成長させること等を可能にするアプリケーションを含む。統合アプリケーションは、配送プロバイダ１１２および支払いゲートウェイ等のビジネスの営業に関する有用な統合を提供するアプリケーションを含み得る。

いくつかの実施形態では、アプリケーション開発者は、アプリケーションプロキシを用いて、外部の場所からデータをフェッチし、それをオンラインストア１３８のページに表示し得る。これらのプロキシページにおけるコンテンツは、例えば動的であり、更新されることが可能であり得る。アプリケーションプロキシは、画像ギャラリ、統計、カスタムフォーム、および他の種類の動的コンテンツを表示するために有用であり得る。ｅコマースプラットフォーム１００の核となるアプリケーション構造は、アプリケーション１４２Ａ－Ｂで構築される増加した数の商人体験を可能にし、それによって、コマース管理エンジン１３６は、より一般的に活用されるコマースのビジネスロジックに焦点を当て続けることができる。

ｅコマースプラットフォーム１００は、商人が柔軟で透明性のある態様で顧客に接触することを可能にする洗練されたシステムアーキテクチャを通じてオンラインショッピング体験を提供する。典型的な顧客体験は、例示的な購入ワークフローの実施形態を通じてより理解され得、ワークフローにおいて、顧客は、チャンネル１１０Ａ－Ｂにある商人の製品を閲覧し、彼らが買いたい物を彼らのカートに追加し、勘定に進み、彼らのカートのコンテンツの支払いをし、商人への注文の創出をもたらす。そして、商人は、注文をレビューおよび履行（または取消）し得る。そして、製品は、顧客に送達される。顧客が満足しない場合、彼らは製品を商人に返却し得る。

例示的な実施形態では、顧客は、チャンネル１１０Ａ－Ｂにある商人の製品を閲覧し得る。チャンネル１１０Ａ－Ｂは、顧客が製品を見て買い得る場所である。いくつかの実施形態では、チャンネル１１０Ａ－Ｂは、アプリケーション１４２Ａ－Ｂ（可能な例外は、コマース管理エンジン１３６内に統合されるオンラインストア１３８である）としてモデル化され得る。販促コンポーネントは、商人が、彼らが販売したい物および彼らがそれを販売する場所を説明することを可能にし得る。製品とチャンネルとの間の関連付けは、製品出版物としてモデル化され、例えば製品リストアップＡＰＩを介してチャンネルアプリケーションによってアクセスされ得る。製品は、サイズおよび色、ならびに、極小かつ緑であるバリエーション、または大きいサイズかつ青であるバリエーション等、利用可能なオプションを全てのオプションの特定の組み合わせに拡大する多くのバリエーション等の多くのオプションを有し得る。製品は、少なくとも１つのバリエーション（例えば、「デフォルトバリエーション」は、どのオプションもない製品として創出される）を有し得る。閲覧および管理を促進するために、製品は、例えば、コレクションにグルーピングされ、製品識別子（例えば、在庫品維持ユニット（ＳＫＵ））等を提供され得る。製品のコレクションは、例えば手動で製品を１つのコレクションに分類すること（例えば、カスタムコレクション）か、または自動的な分類（例えばスマートコレクション）のためのルールセット等を構築することのいずれかによって構築され得る。製品は、例えば仮想現実または拡張現実インタフェースを通じて、２Ｄ画像、３Ｄ画像、回転図画像として閲覧され得る。

いくつかの実施形態では、顧客は、彼らが買いたい物を彼らのカートに追加し得る（代替となる実施形態では、製品は、本明細書中で説明されるように、例えば買うボタンを通じて直接購入され得る）。顧客は、彼らのショッピングカートに製品バリエーションを追加し得る。ショッピングカートモデルは、チャンネル特有であり得る。オンラインストア１３８カートは、複数のカートラインアイテムから構成され得、各カートラインアイテムは、製品バリエーションに関する量を追跡する。商人は、カートスクリプトを用いて、顧客のカートのコンテンツに基づいて顧客に特別なプロモーションを提供し得る。製品をカートに追加することは、顧客または商人からの何らかの約束を意味せず、カートの予測される寿命は数分の単位（日ではない）であり得るので、カートは、短期データ記憶装置に持続させられ得る。

そして、顧客は、勘定に進む。勘定コンポーネントは、顧客向けの注文創出プロセスとしてウェブ勘定を実装し得る。勘定ＡＰＩは、いくつかのチャンネルアプリケーションによって用いられるコンピュータ向けの注文創出プロセスとして提供され、（例えば、販売時点情報管理として）顧客に代わって注文を創出し得る。勘定は、カートから創出され、ｅメールアドレス、請求書、および配送詳細等の顧客の情報を記録し得る。勘定の時、商人は、価格設定を確約する。顧客が彼らの連絡先情報入力したが、勘定に進まない場合、ｅコマースプラットフォーム１００は、顧客に再び係合するための機会（例えば破棄された勘定の特徴）を提供し得る。それらの理由のため、勘定は、カートより遥かに長い寿命（時間またはさらに日）を有し得、したがって持続される。勘定は、顧客の配送先住所に基づいて税および配送費用を計算し得る。勘定は、税コンポーネントに税の計算を委任し、送達コンポーネントに配送費用の計算を委任し得る。価格設定コンポーネントは、商人が割引コード（例えば、勘定において入力されると、勘定されるアイテムに新たな価格を適用する「秘密の」文字列）を創出することを可能にし得る。割引は、顧客を引き付け、マーケティングキャンペーンの成果を評価するために、商人によって用いられ得る。割引および他のカスタム価格システムは、例えば価格ルール（例えば、満たされたときに一連の資格を示す一連の必須条件）を通じて、同一のプラットフォームピースの上部に実装され得る。例えば、必須条件は、「注文の小計が＄１００より高い」または「配送費用が＄１０を下回る」等のアイテムであり得、資格は、「注文全体の２０％割引」または「＄１０引き製品Ｘ、ＹおよびＺ」等のアイテムであり得る。

そして、顧客は、彼らのカートのコンテンツの支払いをし、これは、商人への注文の創出をもたらす。チャンネル１１０Ａ－Ｂは、コマース管理エンジン１３６を用いて、お金、通貨または店舗の価値の蓄え（ドルまたは暗号通貨等）を顧客と商人との間で移動させ得る。種々の支払いプロバイダ（例えば、オンライン支払いシステム、モバイル支払いシステム、デジタルウォレット、クレジットカードケートウェイ等）との通信は、支払い処理コンポーネント内で実装され得る。支払いゲートウェイ１０６との実際の相互作用は、カードサーバ環境を通じて提供され得る。いくつかの実施形態では、支払いゲートウェイ１０６は、例えば主要な国際クレジットカードプロセッサを組み込んだ国際支払いを承認し得る。カードサーバ環境は、カードサーバアプリケーション、カードシンク、ホステッドフィールド等を含み得る。この環境は、機密クレジットカード情報のセキュアゲートキーパーとして機能し得る。いくつかの実施形態では、ほとんどのプロセスは、支払い処理ジョブによって組織化され得る。コマース管理エンジン１３６は、サイト外支払いゲートウェイ１０６を通じたもの（例えば、顧客が別のウェブサイトに向け直される）、手動によるもの（例えば、現金）、オンライン支払方法（例えば、オンライン支払システム、モバイル支払いシステム、デジタルウォレット、クレジットカードゲートウェイ等）、ギフトカード等、多くの他の支払い方法をサポートし得る。勘定プロセスの最後に、注文が創出される。注文は、商人と顧客との間の販売契約であり、商人は、注文にリストアップされた商品およびサービス（例えば、注文ラインアイテム、配送ラインアイテム等）を提供することに同意し、顧客は、（税を含む）支払いを提供することに同意する。このプロセスは、販売コンポーネントでモデル化され得る。コマース管理エンジン１３６勘定によらないチャンネル１１０Ａ－Ｂは、注文ＡＰＩを用いて注文を創出し得る。注文が創出されると、通知コンポーネントを介して、注文確認通知が、顧客に送られ得、注文完了通知が商人に送られ得る。売り過ぎを回避するために、注文処理ジョブが始動するとき、在庫が予約され得る（例えば、商人は、各バリエーションの在庫方針からこの行動を制御し得る）。在庫予約は、短い時間スパン（数分）を有し得、フラッシュセール（例えば、ターゲットインパルス購入等の短時間提供される割引またはプロモーション）をサポートするために、非常に高速かつスケーラブルである必要があり得る。支払いが失敗した場合、予約が解除される。支払いが成功し、注文が創出されたとき、予約が、特定の場所に割り当てられた長期在庫確約に変換される。在庫コンポーネントは、バリエーションが保管される場所を記録し得、在庫追跡が可能であるバリエーションに関して、量を追跡する。在庫は、在庫アイテム（量および場所が管理されるアイテムを表す商人向けコンセプト）から製品バリエーション（製品リストのテンプレートを表す顧客向けコンセプト）を切り離し得る。在庫レベルコンポーネントは、販売取り扱い量、注文が確約された量、または在庫転送コンポーネントから（例えば、ベンダーから）の仕入れ量を追跡し得る。

そして、商人は、注文をレビューし、履行（または取消）し得る。レビューコンポーネントは、ビジネスプロセス商人の使用を実装し、実際にそれらを履行する前に注文が履行に適していることを保証し得る。注文は、詐欺であり得、確認（例えばＩＤチェック）を要求し、彼らの資金を受領することを確実するために待つことを商人に要求する支払い方法を有し得る。リスクおよび推薦は、注文リスクモデルで永続化され得る。注文リスクは、例えば、詐欺検出ツールから生成され、注文リスクＡＰＩを通じて第三者によって提出され得る。履行に進む前、商人は、支払い情報（例えば、クレジットカード情報）を捕捉するか、または（例えば、銀行送金、小切手等を介して）それを受領することを待って注文が支払われたことをマークする必要があり得る。それから、商人は、送達のために製品を準備し得る。いくつかの実施形態では、このビジネスプロセスは、履行コンポーネントによって実装され得る。履行コンポーネントは、在庫場所および履行サービスに基づいて作業の論理的履行単位に注文のラインアイテムをグルーピングし得る。商人は、作業の単位をレビューし、これを調節し、商人が箱から製品を取り出して梱包するときに用いられる（例えば、商人に管理された場所における）手動履行サービスを通じて、関連する履行サービスをトリガし、配送ラベルを購入してその追跡番号を入力するか、または、単に履行されたことをアイテムにマークし得る。カスタム履行サービスは、ｅメールを（例えば、ＡＰＩ接続を提供しない場所に）送り得る。ＡＰＩ履行サービスは、第三者をトリガし得、第三者が、履行記録を作成する。レガシー履行サービスは、コマース管理エンジン１３６から第三者へのカスタムＡＰＩコールをトリガし得る（例えば、Ａｍａｚｏｎによる履行）。ギフトカード履行サービスは、ギフトカードをプロビジョニングし（例えば、番号を生成する）、アクティブにし得る。商人は、注文プリンタアプリケーションを用い、梱包票を印刷し得る。履行プロセスは、アイテムが箱に梱包され、配送の準備がされるとき、配送されるとき、追跡されるとき、送達されるとき、顧客によって受領されたことが確認されるとき等に実行され得る。

顧客が満足しない場合、彼らは、製品（単数または複数）を商人に返却し得る。商人が、アイテムを「販売できない」ことを経験し得るビジネスプロセスは、返却コンポーネントによって実装され得る。返却は、各種の異なるアクションから成り得、各種の異なるアクションは、例えば、再入庫（販売された製品が実際にビジネスに復帰し、再び販売可能である場合）、払い戻し（顧客から集めたお金が部分的または全額返却される場合）、どのくらいのお金が払い戻されたかを通知する会計調節（例えば、何らかの再入庫料金が存在する場合、または商品が返却されておらず、顧客の手元に残っている場合を含む）等である。返却は、販売契約（例えば注文）の変更を表し得、ｅコマースプラットフォーム１００は、（例えば、税に関する）法規違反に関するコンプライアンスの問題を商人に知らせ得る。いくつかの実施形態では、ｅコマースプラットフォーム１００は、商人が経時的に販売契約の変更を追跡することを可能にし、これは、販売モデルコンポーネント（例えば、アイテムに発生した販売関連のイベントを記録する追加専用の日にちベースの台帳）を通じて実装される。
ｅコマースプラットフォームにおけるメッセージの分析

上で概説されるように、顧客によってなされた製品の注文を履行することは、顧客への製品の配送を促進することを含み得る。商人は、例えば配送プロバイダ１１２を通して配送ラベルを購入することによってこの配送を調整し得る。あるいは、第三者が、製品の配送を促進し得る。顧客は、配送についての配送情報を提供され得、配送情報は、特に、配送プロバイダ、追跡番号、追跡ＵＲＬ、配送状況、および／または予想される送達日を含み得る。この配送情報は、例えば、ｅメールメッセージ、テキストもしくはショートメッセージングサービス（ＳＭＳ）メッセージ、またはインスタントメッセージ等のメッセージを通してユーザに提供され得る。加えて、または、あるいは、いくつかの実装では、製品情報（すなわち、配送に含まれる製品に関する情報）が、（例えば、買い手が特定の配送を識別することを可能にするために）配送情報内に含まれ得る。メッセージを送達するために用いられるメッセージングサービスは、ｅコマースプラットフォーム１００によってサポートされ得る。例えば、ｅコマースプラットフォーム１００は、顧客および／または商人と通信するように、および、顧客への配送情報の送達を促進するように、ｅメールメッセージングサービスをサポートし得る。同様に、または、代わりに、メッセージングサービスは、第三者によってサポートされ得る。

顧客に配送情報を提供するメッセージは、顧客がまとめるには困難であり、および／または時間が掛かり得る。特に、配送情報を提供するメッセージは、複数のメッセージにわたって格納され得る。例えば、配送情報を提供するｅメールメッセージは、顧客の受信トレイ内に埋め込まれるようになり得、配送情報が必要とされるときに顧客が後でメッセージを見つけることを困難にする。別の例では、異なるタイプのメッセージ（例えば、ＳＭＳ、ｅメール、チャット／ＩＭ等）のための統合された受信トレイがないことに起因して、および／または所与のタイプの複数の受信トレイに起因して（例えば、ＳＭＳのための複数の電話番号、またはｅメールのための複数のｅメールアカウント／アドレスに起因して）、そのようなメッセージは、１つ以上のタイプの１つ以上の受信トレイにわたって広げられ得、従って、見つけることは困難であり得る。よって、顧客の（ユーザの）メッセージから配送情報を取得し一元管理するためのコンピュータ実装システムに対するニーズが存在している。

図３は、図１のｅコマースプラットフォーム１００であるが、メッセージ分析エンジン３００を含むｅコマースプラットフォームを例証している。メッセージ分析エンジン３００は、メッセージから配送情報を取得し配送情報を記憶するためのコンピュータ実装システムの例である。例として、顧客が配送を追跡することに関するｅメールメッセージを受信すると、メッセージ分析エンジン３００は、ｅメールメッセージから配送情報を抽出し、その配送情報を顧客についての全ての製品配送の集約された概要に追加し得る。そして、この概要は、ｅコマースプラットフォーム１００における顧客のアカウントを通して顧客によってアクセスされ、顧客が彼らの配送の各々についての配送プロバイダ、追跡番号、追跡ＵＲＬ、配送状況、および／または予想される送達日を迅速かつ容易にレビューすることを可能にし得る。顧客は、配送情報を取得するために各ｅメールメッセージを個々に視認することを避けることが可能であり得る。したがって、配送情報の集約された概要は、顧客の時間および顧客を節約し、多数のオンラインストアから買い物をして同時に係属中の多くの製品配送を有する顧客のために特に有用である。

メッセージ分析エンジン３００がメッセージから配送情報を取得することに限定されないことが留意されるべきである。同様に、または、代わりに、他のタイプの情報が、メッセージから取得され得る。例えば、メッセージ分析エンジン３００は、取引データ、請求情報、購入された製品に関する情報、実行されたサービスに関する情報、およびｅコマースプラットフォーム１００を通したビジネスに関連付けられた任意の他の情報を取得し格納し得る（および、潜在的に集約し得る）。

メッセージ分析エンジン３００は、図３においてｅコマースプラットフォーム１００の別個のコンポーネントとして例証されているが、これは単なる例である。同様に、または、代わりに、メッセージ分析エンジンは、ｅコマースプラットフォーム１００の別のコンポーネントによって提供され、または、プラットフォーム１００の外部のスタンドアロン型コンポーネントまたはサービスとして提供され得る。いくつかの実施形態では、コマース管理エンジン１３６および／またはアプリケーション１４２Ａは、メッセージ分析エンジンを提供する。ｅコマースプラットフォーム１００は、１つ以上のパーティによって提供される複数のメッセージ分析エンジンを含み得る。複数のメッセージ分析エンジンは、同一の手法で、同様の手法で、および／または別個の手法で実装され得る。加えて、メッセージ分析エンジンの少なくとも一部は、顧客デバイス１５０上で実装され得る。例えば、顧客デバイス１５０は、ソフトウェアアプリケーションとしてメッセージ分析エンジンを記憶し、それをローカルで実行し得る。

メッセージ分析エンジン３００は、本明細書中で説明される機能のうちの少なくともいくつかを実装し得る。以下で説明される実施形態は、ｅコマースプラットフォーム１００等（しかし、これに限定されない）のｅコマースプラットフォームに関連付けて実装され得るが、以下で説明される実施形態は、図１～図３の特定のｅコマースプラットフォーム１００に限定されない。さらに、本明細書中で説明される実施形態は、ｅコマースプラットフォームに関連して実装されることを必ずしも必要としないか、または、ｅコマースプラットフォームを全く伴わない。他のコンピューティングプラットフォームおよびデバイスが、本明細書中で開示されるシステムおよび方法のうちの少なくともいくつかを実装し得る。
メッセージから配送情報を取得すること

メッセージから配送情報を正確かつ一貫して取得することは、困難であり得る。顧客に製品を配送するために採用され得る膨大な数の配送プロバイダ、履行ネットワーク、郵便サービスプロバイダ、ラストマイル送達サービス等が存在している。各商人および／または配送プロバイダは、典型的に、自身のメッセージフォーマットおよび追跡番号システムを有する。さらに、デジタル通知は、例えば、ｅメールメッセージ、テキストメッセージ、インスタントメッセージ等の各種の形式をとり得／各種のタイプであり得る。さらに、メッセージの組は、同一のタイプかまたは異なるタイプかに関わらず、全て異なるフォーマットを有し得る。その結果、配送情報を含み得る潜在的メッセージフォーマットの数は、計り知れない。

メッセージから配送情報を取得するための決定論的方法を実装することは、この潜在的メッセージフォーマットの数のために実行可能ではないこともある。決定論的方法は、メッセージから配送情報を抽出するために一定の規則の組をしばしば用いる。しかしながら、正確であること、および一貫していることの両方のために、メッセージから配送情報を取得するための決定論的方法は、各可能なメッセージフォーマットを扱うように、能動的に構成されるべきである。例えば、決定論的方法は、あらゆる個々のメッセージフォーマットをパターンマッチングさせるために、別個の規則またはテンプレートの組が生成されることを必要とし得る。可能なメッセージフォーマットの数は、これを過度に時間のかかるものにし得る。加えて、種々のタイプのメッセージを追跡するための一貫して採用されるフォーマットが存在していない。さらに、そのような標準化の試みは、限定された採用しか見られず、そのような限定された採用では、そのような標準は、しばしば一貫性なく／正しくなく実装される。さらに、配送プロバイダは、彼らのｅメールメッセージフォーマットを継続的に更新し、およびそれを変更しており、新たな配送プロバイダ、および送達サービス等も、頻繁にオンライオンストアに参入している（すなわち、彼らのビジネスを立ち上げている）。したがって、メッセージから配送情報を取得するための決定論的方法も、それに従って、能動的に更新される必要があり得る。

メッセージの内容全体からでなく、メッセージ中の追跡ＵＲＬから配送情報を取得することは、上で概説される決定論的方法の少なくとも一部の使用を避けることに役立ち得る。追跡ＵＲＬは、特定の配送についての配送情報を含むウェブリソースへの案内であり得る。ＵＲＬは、メッセージの全内容のうちの一部のみを表し得るが、ＵＲＬ自体は、さらに、メッセージ中に含まれる配送情報のほとんど、またはその全てさえ提供し得る。したがって、追跡ＵＲＬは、メッセージの内容全体を構文解析することなく配送情報を取得するために用いられ得る。ＵＲＬは、配送情報を取得するための分析を簡略化し得る所定の構造も有する。ＵＲＬの構造は、スキーム、随意のオーソリティ、パス、随意のクエリ、および随意のフラグメントを含む。

スキームは、後にコロン（：）が続く文字列を含み、ウェブプロトコルが用いられていることを示す。スキームの非限定的な例は、ｈｔｔｐ、ｈｔｔｐｓ、ｆｔｐ、ｍａｉｌｔｏ、ｆｉｌｅ、ｄａｔａ、およびｉｒｃを含む。

ＵＲＬ中のオーソリティは、２つのスラッシュ（／／）に先行される。オーソリティは、随意のｕｓｅｒｉｎｆｏサブコンポーネントを含み、ｕｓｅｒｉｎｆｏサブコンポーネントは、ユーザ名と、随意にパスワードと、ｈｏｓｔサブコンポーネントと、随意のｐｏｒｔサブコンポーネントとを提供する。

パスは、サーバ上の特定のウェブリソース、ファイル、またはディレクトリへのマップを提供し得る。パスは、１つ以上のパスセグメントを含み得、各パスセグメントは、スラッシュ（／）によって分離される。しかしながら、代わりに、パスは、スペースであり得る。

クエリは、ＵＲＬ中のクエスチョンマーク（？）に先行され、１つ以上のパラメータを含む。各パラメータは、アンパサンド（＆）によって分離される。クエリは、ウェブリソースによって提供されるコンテンツを示し得る。例えば、クエリは、ウェブページ上に表示されるコンテンツを選択するために用いられ得る。

フラグメントは、ハッシュ（＃）に先行され、二次的ウェブリソースへの案内を提供し得る。

よって、ＵＲＬの構造は、ｓｃｈｅｍｅ：［／／ａｕｔｈｏｒｉｔｙ］ｐａｔｈ［？ｑｕｅｒｙ］［＃ｆｒａｇｍｅｎｔ］として定義され得る。例えば、以下のＵＲＬ：ｈｔｔｐｓ：／／ｓｏｕｐ．ｍｙｓｈｏｐｉｆｙ．ｃｏｍ／ｐａｇｅｓ／ｒｅｃｉｐｅｓ？ｐａｒａｍ１＝ｘ＆ｐａｒａｍ２＝ｙ＃ｂｏｒｓｃｈｔを考慮されたい。ここで、スキームは、ｈｔｔｐｓであり、オーソリティは、ｓｏｕｐ．ｍｙｓｈｏｐｉｆｙ．ｃｏｍであり、パスは、ｐａｇｅｓ／ｒｅｃｉｐｅｓであり、クエリは、ｐａｒａｍ１＝ｘ＆ｐａｒａｍ２＝ｙであり、フラグメントは、ｂｏｒｓｃｈｔである。

少なくともメッセージの内容全体と比較して、ＵＲＬの構造化された性質および比較的短い長さは、確率的方法の使用が配送情報を取得することを可能にする。確率的方法は、確率分布に基づいて決定を下し、多数の固有の入力および対応する具体的な出力を伴う問題に概して好適であり、それは、メッセージから配送情報を取得することについて当てはまり得る。確率的方法は、多くの異なるメッセージフォーマットおよびメッセージへの変更に適応するためのある程度の柔軟性を提供し得る。

いくつかの実施形態では、確率的方法は、ＵＲＬ中の特定のパラメータまたは構文を認識することによって、ＵＲＬから配送情報を抽出する。例えば、ＵＲＬ中のクエリパラメータは、ｃｏｕｎｔｒｙ＝ＣＡ＆ｔｒａｃｋｉｎｇＩｄ＝３６８９２７４７３８３５であり、配送の目的地がカナダにあり、追跡番号が３６８９２７４７３８３５であることを示し得る。

機械学習（ＭＬ）モデルは、確率的方法を実装するための１つの潜在的手法である。しかしながら、ＭＬモデルは、演算集約的であり得、訓練のために大量のデータを要求し得る。したがって、ＭＬモデルを用いて数多くの入力データセットを分析することは、コストがかかり、時間がかかり得る。有利なことに、ＵＲＬは、しばしば、比較的少数の文字（典型的に、５０～２００）を有し、十分に構造化されており、典型的に、メッセージフォーマットより頻繁には変化しない傾向があり得（例えば、少なくともいくつかの場合、ＵＲＬフォーマットへの変更は、ＵＲＬフォーマットにおける過去との互換性を維持するための必要性に起因して、限定され得る一方で、ｅメールの本文のフォーマット等のメッセージフォーマットは、例えば形式の理由等のためにより頻繁に変化し得る）、したがって、ＵＲＬは、ＭＬモデルを用いた分析に十分好適である。

ＵＲＬから配送情報を取得することに加え、配送情報は、ＵＲＬによってリンクされ、またはＵＲＬに関連付けられたウェブリソースからも取得され得る。例えば、ＵＲＬは、配送の配送プロバイダ、追跡番号、配送状況、および／または予想される送達日を提供する配送プロバイダのウェブページにリンクし得る。配送情報は、決定論的方法および／または確率的方法を用いてウェブリソースを構文解析することによって取得され得る。

ＵＲＬとＵＲＬに関連付けられたウェブリソースとの両方を分析することは、メッセージから取得される配送情報の量を潜在的に増加させ、配送情報を取得することにおけるある程度の冗長性を提供し得る。例えば、ＵＲＬから取得された配送情報は、ＵＲＬに関連付けられたウェブリソースから取得された配送情報によって確認され、および／または補足され得、その逆も然りである。一例では、メッセージから抽出されたＵＲＬは、ＵＲＬが配送を追跡するためのものであるか否かを決定し、配送についての配送プロバイダを決定し、および／または配送についての追跡番号を決定するために分析される。そして、ＵＲＬから取得された配送情報は、ＵＲＬに関連付けられたウェブリソースから取得された配送情報で捕捉され、および／または確認され得る。別の例では、配送情報は、ＵＲＬに関連付けられたウェブリソースから決定され、配送情報は、ＵＲＬの分析を通して随意に確認される。

ユーザのメッセージのうちの１つ以上から配送情報を取得した後、一元管理された配送情報のリストが、顧客のために編集され得る。このリストは、ユーザが一度に彼らの係属中の配送のうちのいずれか、それらのうちのいくつか、またはそれら全てに関する情報に迅速かつ容易にアクセスすることを可能にする。配送情報のリストは、例えば、ユーザが配送情報を有する新たなメッセージを受信するとき、および配送がユーザに上手く送達されたとき、能動的に更新され得る。さらに、ユーザは、リストを変更するための能力を与えられ得る。例えば、ユーザは、リスト中の配送情報をまとめ、追加し、削除し、および／または修正することが可能であり得る。

配送情報は、本明細書中で開示されるシステムおよび方法を用いてユーザのメッセージから取得され得る情報のうちの１つのタイプに過ぎない。本開示は、ユーザのメッセージから他のタイプの情報を取得することにも関している。例えば、ユーザによってオンラインで購入された製品に関する情報が、ユーザのメッセージから取得され得る。これらのメッセージ中のＵＲＬおよび随意にそれらのＵＲＬに関連付けられたウェブリソースを分析することは、ユーザがオンラインで注文した製品についての製品情報を取得するために実装されることができる。この製品情報を編集することは、例えば、１つのコマースプラットフォームからの製品推薦が他のコマースプラットフォームからのユーザの購入を組み込むことを可能にし得る。別の例では、例えば将来の配送に関して取得され得る情報等の他の潜在的に関連性のあるデータが、ユーザのメッセージ中のＵＲＬの分析に基づいて取得され得る。特に、そのような潜在的に関連性のあるデータは、今後の配送に関する製品データ／情報を含み得る。加えて、または、あるいは、少なくともいくつかの場合、そのような潜在的に関連性のある情報は、ユーザのメッセージ中で利用可能ではない情報を含み得／それは、メッセージを介してユーザに通信されない。加えて、または、あるいは、少なくともいくつかの場合、潜在的に関連性のある情報は、メッセージ中に存在するがメッセージがレンダリングされるときに示されない情報を含み得る。例えば、潜在的に関連性のある情報は、メッセージ中に含まれるメタデータ／マークアップに見出され得る。別の例では、潜在的に関連性のある情報は、メッセージが特定のカテゴリのデバイス／クライアントによってレンダリングされるときに見えないこともある（例えば、メッセージがデスクトップコンピュータ上でレンダリングされるときのみ見え、メッセージがモバイルデバイス上での提示のために実行されるときには見えない情報）。
メッセージから配送情報を取得するための例示的システムおよび方法

図４は、デジタルメッセージから情報を取得するための例示的システム４００を例証するブロック図である。システム４００は、メッセージ分析エンジン４０２と、ネットワーク４２０と、ユーザデバイス４３０とを含む。

メッセージ分析エンジン４０２は、メッセージを記憶し、およびそれを分析し、メッセージから情報を取得する。そして、取得された情報は、メッセージ分析エンジン４０２によって編集され、および記憶され、随意に、ユーザデバイス４３０に伝送され得る。メッセージ分析エンジン４０２によって取得された情報は、配送情報であるか、またはそれを含み得るが、他のタイプの情報も想定される。例えば、ユーザによってオンラインで購入された製品に関する情報が、メッセージ分析エンジン４０２によって取得され得る。

メッセージ分析エンジン４０２の場所は、実装特有である。いくつかの実装では、メッセージ分析エンジン４０２は、ｅコマースプラットフォームのコア機能として、またはｅコマースプラットフォームによってサポートされたアプリケーションとして、ｅコマースプラットフォームによって少なくとも部分的に提供される。例えば、メッセージ分析エンジン４０２は、図３のメッセージ分析エンジン３００であり得る。いくつかの実装では、メッセージ分析エンジン４０２は、ｅコマースプラットフォームの外部またはユーザデバイスによって少なくとも部分的に実装されるスタンドアロン型のコンポーネント、アプリケーション、またはサービスとして実装される。メッセージ分析エンジン４０２の他の実装も想定される。メッセージ分析エンジン４０２が単一のコンポーネントとして示されるが、代わりに、メッセージ分析エンジン４０２は、例えばネットワーク４２０を介して通信する複数の異なるコンポーネントによって提供され得る。

メッセージ分析エンジン４０２は、プロセッサ４０４と、メモリ４０６と、ネットワークインタフェース４０８とを含む。プロセッサ４０４は、メモリ４０６内または別の非一過性のコンピュータ読み取り可能な媒体内に記憶されている命令を実行する１つ以上のプロセッサによって実装され得る。これらの命令は、本明細書中で説明されるいずれかの方法を実装し得る。あるいは、プロセッサ４０４のうちのいくつかまたは全てが、特定用途向け集積回路（ＡＳＩＣ）、グラフィックス処理ユニット（ＧＰＵ）、またはプログラムされたフィールドプログラマブルゲートアレイ（ＦＰＧＡ）等の専用回路を用いて実装され得る。

ネットワークインタフェース４０８は、ネットワーク４２０上での通信のために提供される。ネットワークインタフェース４０８の構造は、実装特有である。例えば、ネットワークインタフェース４０８は、ネットワークインタフェースカード（ＮＩＣ）、コンピュータポート（例えば、プラグまたはケーブルが接続する物理的アウトレット）、および／またはネットワークソケットを含み得る。

メモリ４０６は、メッセージレコード４１０と、配送プロバイダレコード４１２と、メッセージカテゴリレコード４１３と、ＵＲＬカテゴリレコード４１４と、１つ以上のＭＬモデル（単数または複数）４１６と、配送情報レコード４１８とを記憶している。

メッセージレコード４１０は、メッセージ分析エンジン４０２による分析のために記憶されているメッセージを含む。これらのメッセージは、ｅメールメッセージ、テキストメッセージ、インスタントメッセージ等を含み得る。例えばボイスメールメッセージおよびデジタルアシスタントからのメッセージ等の音響メッセージも、メッセージレコード４１０内に含まれ得る。いくつかの場合、シリアル化されたバージョンのメッセージが、メッセージレコード４１０内に記憶されている。シリアル化されたバージョンのメッセージの例は、ｅメールメッセージのためのＥＭＬファイルである。

メッセージは、メッセージ分析エンジン４０２による分析の前および／または分析中に、メッセージレコード４１０内に一時的にのみ記憶され得る。しかしながら、メッセージレコード４１０は、メッセージの永続的なレコードまたは半永久的なレコードも提供し得る。

メッセージレコード４１０内に記憶されているメッセージは、数多くの異なる手法のうちのいずれかで取得され得る。いくつかの実装では、メッセージ分析エンジン４０２は、メッセージングサービスにおける１つ以上のユーザアカウントへのアクセスを許可されている。このアクセスは、メッセージ分析エンジン４０２がメッセージングサービスからユーザメッセージを取得することを可能にし得る。メッセージングサービスの非限定的な例は、ｅメールサービス、テキストメッセージングサービス、およびインスタントメッセージングサービスを含む。さらに、ユーザは、メッセージ分析エンジン４０２に複数のメッセージングサービスにおける彼らのアカウントへのアクセスを許可し得る。したがって、メッセージ分析エンジン４０２は、１つ以上のｅメールアカウント、１つ以上のテキストメッセージングアカウント、および／または１つ以上のインスタントメッセージングアカウントから、ユーザのメッセージを取得し得る。

メッセージ分析エンジン４０２がメッセージングサービスにおけるユーザアカウントへアクセスすると、そのメッセージングサービスにおけるユーザのメッセージのうちのいずれか、それらのうちのいくつか、またはそれら全てが、メッセージレコード４１０内に記憶され得る。メッセージは、メッセージングサービスをサポートしているサーバから、および／またはユーザデバイス（例えば、ユーザデバイス４３０）から受信され得る。いくつかの場合、ユーザがメッセージングサービスにおいて新たなメッセージを受信すると、メッセージレコード４１０も、新たなメッセージを取得し、それを記憶し得る。したがって、メッセージレコード４１０は、１つ以上のメッセージングプラットフォームにおいてユーザが受信するメッセージの一元管理されたリストを含み得る。いくつかの場合、ユーザは、メッセージレコード４１０内に記憶されるメッセージを能動的に選択し、および／または、メッセージレコード４１０内に記憶されるメッセージを決定する規則の組を定義する。例えば、ユーザは、特定の送信者からのメッセージのみがメッセージレコード４１０内に記憶されるように、メッセージ分析エンジン４０２のアクセスを構成し得る。

配送プロバイダレコード４１２は、既知の配送プロバイダのリストまたは組を含む。いくつかの場合、このリストは、例えば１つ以上のデータソースから取得された情報に基づく等して、自動的に構築され、または維持され得る。例えば配送プロバイダによって用いられる配送メッセージフォーマット、配送プロバイダによって用いられる追跡ＵＲＬフォーマット、および／または配送プロバイダによって用いられるウェブリソースフォーマットを含むこれらの配送プロバイダの各々に関する情報も、配送プロバイダレコード４１２内に記憶され得る。本明細書中の別の場所でさらに詳細に議論されるように、配送プロバイダレコード４１２は、メッセージから配送情報を取得しおよび／またはそれを確認することに役立つように用いられ得る。

メッセージカテゴリレコード４１３は、所定のメッセージカテゴリのリストまたは組を含む。これらの所定のメッセージカテゴリのうちの少なくとも一部は、例えば、異なるメッセージフォーマット、テンプレート、または構造に対応し得る。

いくつかの実装では、メッセージカテゴリレコード４１３内の所定のメッセージカテゴリが、メッセージの潜在的機能に（少なくとも部分的に）基づいて定義される。よって、メッセージのメッセージカテゴリを決定することは、メッセージの機能を決定することに役立ち得る。そのようなメッセージカテゴリの非限定的な例は：
・例えば商人の広告、ニュースレター、および他の販促コンテンツを含むコマースメッセージ；
・配送追跡および／または確認メッセージ；
・送達状況更新メッセージ；
・注文確認メッセージ：
・個人的なメッセージ；
・仕事のメッセージ；
・請求書；および
・スパムメッセージ
を含む。

同様に、または、代わりに、メッセージカテゴリレコード４１３内の所定のメッセージカテゴリは、メッセージの送信者に（少なくとも部分的に）基づいて定義され得る。異なる商人、配送プロバイダ、および他の送信者は、彼らの送信アドレスおよび／または彼ら特有のメッセージフォーマットを有し得、それらの各々または両方が、単独で、または組み合わされて、メッセージカテゴリ４１３内のそれぞれのメッセージカテゴリに対応し得る。ある例では、複数の配送追跡メッセージカテゴリが定義され、各カテゴリが、配送プロバイダレコード４１２内に定義された異なる配送プロバイダに対応する。

いくつかの実装では、メッセージカテゴリレコード４１３は、配送情報を潜在的に含み得るメッセージを識別することに役立ち得、メッセージ中の配送情報の少なくとも一部を決定することにすら役立ち得る。例えば、特定のメッセージが特定の所定のメッセージカテゴリに対応することが決定され得る。この所定のメッセージカテゴリが配送追跡に関連付けられる場合、メッセージが配送追跡にも関連付けられることが決定され得る。さらに、メッセージカテゴリが特定の配送プロバイダに関連付けられる場合、配送がその配送プロバイダによって促進されていることが決定され得る。

ＵＲＬカテゴリレコード４１４は、所定のＵＲＬカテゴリのリストまたは組を含む。これらの所定のＵＲＬカテゴリの各々は、例えば、異なるＵＲＬフォーマット、テンプレート、または構造に対応し得る。これらの所定のＵＲＬカテゴリは、ＵＲＬの機能および／またはＵＲＬによってリンクされるウェブリソースの機能を決定することに役立つように用いられ得る。つまり、特定のＵＲＬをＵＲＬカテゴリレコード４１４内に記憶されている所定のＵＲＬカテゴリのうちの１つに合致させることによって、ＵＲＬによってリンクされたウェブリソースの目的が、決定され得る。

いくつかの実装では、ＵＲＬカテゴリレコード４１４内に記憶されている所定のＵＲＬカテゴリのうちの少なくとも１つは、追跡ＵＲＬカテゴリであるか、または配送を追跡することに関連している。ＵＲＬカテゴリレコード４１４は、複数の追跡ＵＲＬカテゴリを含み得、追跡ＵＲＬカテゴリの各々は、それぞれの配送プロバイダに特有であり得る。例えば、特定の配送プロバイダによって用いられるＵＲＬフォーマットは、その配送プロバイダ特有の１つ以上の追跡ＵＲＬカテゴリに分類され得る。いくつかの場合、ＵＲＬカテゴリレコード４１４は、配送プロバイダレコード４１２と互いに関係づけられており、それによって、配送プロバイダレコード４１２内の各々の配送プロバイダは、ＵＲＬカテゴリレコード４１４内で定義された１つ以上の対応するＵＲＬカテゴリを有する。しかしながら、複数の異なる配送プロバイダは、同様のフォーマットを有するＵＲＬを用い得る。加えて、いくつかの場合、ＵＲＬは、配送情報アグリゲータに対応し得、配送情報は、そのアグリゲータが実際の配送／配送の送達の取り扱いの責任を有しない場合であっても、配送情報アグリゲータから取得され得る。したがって、追跡ＵＲＬカテゴリは、複数の異なる配送プロバイダに関連付けられ得る。配送追跡に関連しないＵＲＬカテゴリレコード４１４内の１つ以上の所定のＵＲＬカテゴリも存在し得る。

本明細書中の別の場所でさらに詳細に議論されるように、ＵＲＬカテゴリレコード４１４内に所定のＵＲＬカテゴリを記憶していることは、ＵＲＬから配送情報を決定することに役立ち得る。ＵＲＬが特定の配送プロバイダに関連付けられた追跡ＵＲＬカテゴリに対応することが決定される場合、ＵＲＬがその配送プロバイダによって促進される配送を追跡することに関していることが示唆され得る。追跡ＵＲＬカテゴリの知識を有することは、追跡番号がＵＲＬから抽出されることも可能にし得る。ある例では、特定の追跡ＵＲＬカテゴリは、追跡番号を含むＵＲＬフォーマットに対応している。追跡番号は、概して、ＵＲＬフォーマット中の同一の位置に含まれる。したがって、始まりのインデックスと終わりのインデックスとが、追跡ＵＲＬカテゴリの追跡番号について画定され、ＵＲＬカテゴリレコード４１４内に記憶され得る。始まりのインデックスは、追跡番号の最初の桁の位置に対応しており、終わりのインデックスは、追跡番号の最終桁の位置に対応している。始まりのインデックスと終わりのインデックスとを用いて、追跡番号が、この追跡ＵＲＬカテゴリのＵＲＬから抽出され得る。始まりのインデックスおよび／または終わりのインデックスは、ＵＲＬの始めから、またはＵＲＬの終わりから定義され得る。つまり、ＵＲＬ中の追跡番号の始まりおよび／または終わりを見つけることは、ＵＲＬの始めから順方向にカウントすること、またはＵＲＬの終わりから逆方向にカウントすることを伴い得る。

ＭＬモデル（単数または複数）４１６は、メッセージを分析し、メッセージから情報（例えば、配送情報等）を取得するために、プロセッサ４０４によって実行可能である。いくつかの場合、ＭＬモデル（単数または複数）４１６は、メッセージから情報を取得するための確率的方法を実装する。

ＭＬモデル（単数または複数）４１６は、当技術分野において公知な任意の形式または構造を用いて実装され得る。ＭＬモデル（単数または複数）４１６のための例示的構造は：
・１つ以上の人工ニューラルネットワーク（単数または複数）；
・１つ以上の決定木（単数または複数）；
・１つ以上のサポートベクターマシン（単数または複数）
・１つ以上のベイジアンネットワーク（単数または複数）；および／または
・１つ以上の遺伝的アルゴリズム（単数または複数）
を含むが、これらに限定されない。

ＭＬモデル（単数または複数）４１６を訓練するために用いられる方法も、実装特有であり、本明細書中で限定されない。訓練方法の非限定的な例は：
・教師有り学習；
・教師無し学習；
・強化学習；
・自己学習；
・特徴学習；および
・スパース辞書学習
を含む。

いくつかの実施形態によると、ＭＬモデル（単数または複数）４１６のうちの１つ以上は、教師有り学習を用いて訓練される。教師有り学習において、訓練は、訓練データの組において入力データを分析し、定量的比較を行い、および訓練データの組における既知の結果に結論を相互参照させることによって、実施される。これらの分析および比較の繰り返しの洗練は、ＭＬモデルがＭＬモデルによって予測される結果と既知の結果との間のより高い確実性を達成することを可能にする。このプロセスは、解が収束し、または所望の確度に達するまで繰り返し継続される。

いくつかの実施形態によると、ＭＬモデル（単数または複数）４１６のうちの１つ以上が、教師無し学習を用いて訓練される。教師無し学習において、ＭＬモデルは、訓練データの組からそれ自体の連関を決定し、およびそれを引き出す。これは、訓練データの組において自然に発生するデータの関係またはパターンを探索することによって行われ得る。教師無し学習を実装するための１つの方法は、クラスタ分析であり、クラスタ分析において、目標は、訓練データの組内グループまたはクラスタを発見することである。クラスタは、ＭＬモデルによって同様に扱われる変数の組である。クラスタ分析において、ＭＬモデルは、高いグループ内類似度と低いグループ間類似度とを有するクラスタを決定するために、訓練データの組をさらに分割する。クラスタ分析において用いられるクラスタの数は、ＭＬモデルにおいて構成可能であり得る。

ＭＬモデル（単数または複数）４１６のうちのいずれか、それらのうちの１つ、それらのうちのいくつか、またはそれら全てが、マルチタスク学習（ＭＴＬ）モデルであり得るか、またはそれらを含み得る。ＭＴＬモデルは、同時に複数のタスクを実施することによって、より正確に、および／またはより効率的に、メッセージから情報を抽出することに役立ち得る。例えば、メッセージ中のＵＲＬが配送を追跡することに関しているか否かを決定すること、配送についての配送プロバイダを決定すること、配送についての追跡番号を決定すること、および配送を開始した商人を決定することが全て、単一のＭＴＬモデルによって解かれ得る「タスク」とみなされ得る。これらのタスク間の共通性および差異は、各タスクを別で解くように実装される複数のＭＬモデルと比較してＭＴＬモデルの全体の確度を向上させることに役立ち得る。ＭＴＬモデルは、各タスクの結果を個々に向上させる（それは、正しくないことも一貫していないこともある向上された個々の解答を集合的に与える）のではなく、向上させられた集合的解答を提供するように、全てのタスクにわたる結果を向上させるように同時に訓練され得る。さらに、複数のＭＬモデルの代わりに単一のＭＴＬモデルを実装することは、訓練され維持される必要があるＭＬモデルの全体数を低減させ得る。

配送情報レコード４１８は、１人以上のユーザのために取得された配送情報を含む。この配送情報は、ＭＬモデル（単数または複数）４１６および／または本明細書中の別の場所で開示される方法を用いて、メッセージレコード４１０内に記憶されているメッセージから決定され得る。しかしながら、配送情報は、例えばユーザデバイス４３０での直接的なユーザ入力を介して等、他のソースからも取得され得る。いくつかの実装では、配送情報レコード４１８は１人以上のユーザのための一元管理された配送情報のリストを編集し、またはそれを提供する。配送情報のリストは、能動的に更新され得る。一例では、配送がユーザによって受け取られると、この配送に対応する配送情報は、配送情報レコード４１８から除去され得る。別の例では、新たなメッセージがメッセージレコード４１０によって取得され、配送情報がこのメッセージから取得されると、配送情報が、配送情報レコード４１８に追加され得る。

メッセージレコード４１０、配送プロバイダレコード４１２、メッセージカテゴリレコード４１３、ＵＲＬカテゴリレコード４１４および配送情報レコード４１８が図４において別々に示されているが、その代わり、いくつかの実施形態では、これらのレコードのうちの２つ以上が単一のレコードに組み合わせられ得ることが留意されるべきである。一例では、メッセージレコード４１０と配送情報レコード４１８とが、単一のレコードに組み合わせられ得る。別の例では、配送プロバイダレコード４１２と、メッセージカテゴリレコード４１３と、ＵＲＬカテゴリレコード４１４とが、単一のレコードに組み合わせられ得る。

ユーザデバイス４３０は、プロセッサ４３２と、メモリ４３４と、ユーザインタフェース４３６と、ネットワークインタフェース４３８とを含む。ユーザインタフェース４３６は、例えば、ディスプレイスクリーン（タッチスクリーンであり得る）、ジェスチャ認識システム、スピーカ、ヘッドフォン、マイクロフォン、ハプティクス、キーボード、および／またはマウスを含み得る。ネットワークインタフェース４３８は、ネットワーク４２０上での通信のために提供される。ネットワークインタフェース４３８の構造は、ユーザデバイス４３０がネットワーク４２０とどのようにインタフェース接続するかに依存する。例えば、ユーザデバイス４３０がモバイルフォン、ヘッドセット、またはタブレットである場合、ネットワークインタフェース４３８は、ネットワーク４２０へ／から無線伝送を送信し、および受信するためのアンテナを有するトランスミッタ／レシーバを含み得る。ユーザデバイスが、ネットワークケーブルでネットワークに接続されたパーソナルコンピュータである場合、ネットワークインタフェース４３８は、例えば、ＮＩＣ、コンピュータポート、および／またはネットワークソケットを含み得る。プロセッサ４３２は、ユーザデバイス４３０によって実施される動作の全てを直接実施し、または命令する。これらの動作の例は、ユーザインタフェース４３６から受信されたユーザ入力を処理することと、ネットワーク４２０上での伝送のための情報を準備することと、ネットワーク４２０上で受信されたデータを処理することと、ディスプレイスクリーンに情報を表示するように命令することとを含む。プロセッサ４３２は、メモリ４３４内に記憶されている命令を実行する１つ以上のプロセッサによって実装され得る。あるいは、プロセッサ４３２のうちのいくつか、またはそれら全てが、ＡＳＩＣ、ＧＰＵ、またはプログラムされたＦＰＧＡ等の専用回路を用いて実装され得る。

図４では、１つのユーザデバイスが例として示されている。複数のユーザデバイスが、メッセージ分析エンジン４０２と通信し得る。

図５は、ある実施形態によるメッセージを分析して配送情報を取得するための方法５００を例証しているフロー図である。方法５００は、図４のメッセージ分析エンジン４０２によって実施されているように説明される。しかしながら、他の実装も構想される。例えば、方法５００は、ユーザデバイス４３０によって全体的に、または部分的に実施され得る。

方法は、顧客に関連付けられた複数のメッセージを識別することを含み得る。少なくとも１つの配送についての配送情報が、複数のメッセージから抽出され得る。ステップ５０２は、プロセッサ４０４が所与のメッセージに対応するデジタルコンテンツを取得することを含む。メッセージは、複数の識別されたメッセージのうちの１つであり得る。このデジタルコンテンツは、例えば、メッセージ中のコンテンツ（例えば、メッセージの見出し、テキスト、および／または添付物）、メッセージの送信者および／またはメッセージの受信者（単数または複数）のうちのいずれか、それらのうちのいくつか、またはそれら全てを含み得る。いくつかの場合、シリアル化されたバージョンのメッセージが、ステップ５０２において取得される。デジタルコンテンツは、例えば、メッセージレコード４１０から、ユーザデバイス４３０から、および／またはメッセージングサービスをホストしているサーバから取得され得る。

ステップ５０４は、プロセッサ４０４がステップ５０２において取得されたデジタルコンテンツから１つ以上のＵＲＬを取得することを含む。各ＵＲＬは、ウェブリソースに関連付けられている。ＵＲＬは、メッセージを読み、またはメッセージに関わるユーザに見える（例えば、テキスト中に示されるハイパーリンクである）ことも、ユーザに見えない（例えば、メタデータ、または不可視のｈｙｐｅｒｔｅｘｔ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ（ＨＴＭＬ）要素である）こともある。概して、デジタルコンテンツ中のＵＲＬのうちのいずれか、それらのうちの１つ、それらのうちのいくつか、またはそれらの全てが、ステップ５０４で取得され得る。ＵＲＬがデジタルコンテンツ中に見つけられない場合、方法５００は終了し得る。

ステップ５０４は、各種の技術のうちのいずれかを用いて実施され得る。いくつかの場合、ステップ５０４は、文字列マッチングアルゴリズム等の決定論的方法を実装してＵＲＬを抽出し得る。例えば、プロセッサ４０４は、デジタルコンテンツを構文解析し、ＵＲＬ特有の構文を含む任意の文字列を除去し得る。ＵＲＬ特有の構文の非限定的な例は、ｈｔｔｐ：、．ｈｔｍｌ、．ｃｏｍ、．ｏｒｇ、および．ｃａを含む。同様に、または、代わりに、確率的方法が、ステップ５０４において実装され得る。例えば、ＭＬモデル（単数または複数）４１６のうちの１つ以上が、デジタルコンテンツからＵＲＬを抽出するように訓練され得る。

ステップ５０４においてメッセージから抽出されたＵＲＬは、メモリ４０６内、または別の非一過性のコンピュータ読み取り可能な媒体内に記憶され得る。例えば、抽出されたＵＲＬは、メッセージと共にメッセージレコード４１０内に記憶され得る。

ステップ５０６は、プロセッサ４０４がステップ５０２において取得されたデジタルコンテンツに基づいて、メッセージが配送を追跡することに関している（または、おそらくそれに関している）ことを決定することを含む随意のステップである。このステップは、メッセージ分析エンジン４０２に配送情報を取得するために方法５００を用いてメッセージがさらに処理されるべきであることを知らせる。一方、ステップ５０６が、メッセージが配送を追跡することに関連しないことを決定した場合、方法５００は終了し得る。したがって、ステップ５０６は、方法５００によって処理されるメッセージの数をフィルタリングすることに役立ち得る。

いくつかの実装では、ステップ５０６は、メッセージを分類し、メッセ―カテゴリが配送追跡に関連付けられることを決定することを含む。例えば、ステップ５０６は、メッセージのデジタルコンテンツからメッセージカテゴリを識別するように訓練されたＭＬモデル（ＭＬモデル（単数または複数）４１６のうちの１つであり得る）にデジタルコンテンツを入力することを含み得る。そして、このＭＬモデルは、メッセージのためのメッセージカテゴリ、または少なくともメッセージカテゴリの指示を出力し得る。いくつかの場合、ＭＬモデルは、メッセージカテゴリレコード４１３内に記憶されている所定のメッセージカテゴリの組からメッセージカテゴリを選択し得る。ＭＬモデルによって決定されたメッセージカテゴリに基づいて、メッセージが配送に関しているか否かが決定され得る。例えば、配送追跡メッセージおよび注文確認メッセージが、製品の配送に関し得るメッセージカテゴリとして定義され得る。

メッセージのデジタルコンテンツからメッセージカテゴリを識別するために用いられるＭＬモデルは、数多くの異なる手法のうちのいずれかで訓練され得る。いくつかの実装では、このＭＬモデルのための訓練データの組は、メッセージの組を含み得、メッセージの各々は、既知のメッセージカテゴリでラベル付けされている。この訓練データの組は、コンピューティングプラットフォームにおけるユーザフィードバックから取得され得る。例えば、ユーザがコンピューティングプラットフォームにおけるメッセージに関する問題に遭遇したとき、彼らは、問題を報告し得る。報告において、ユーザは、メッセージを提出するように、およびメッセージについてのカテゴリを示すように求められ得る。メッセージについてのカテゴリは、メッセージカテゴリレコード４１３内に記憶されている所定のカテゴリのうちの１つから選択され得る。よって、これらの報告は、ユーザによって分類されたメッセージの大規模な組を提供し得、したがって、ＭＬモデルのための好適な訓練データの組を提供し得る。

いくつかの実装では、ステップ５０６は、メッセージが配送追跡に関していることを決定するために、メッセージのデジタルコンテンツ全体に加えて、またはその代わりに、ステップ５０４において取得されたＵＲＬを用いる。これらの実装では、ステップ５０６は、ＵＲＬカテゴリを識別するように訓練されたＭＬモデルにＵＲＬの少なくとも一部を入力することを含み得る。このＭＬモデルは、ＭＬモデル（単数または複数）４１６のうちの１つであり得る。ＵＲＬカテゴリが配送追跡に対応している場合、メッセージ自体も配送追跡に関していることが決定され得る。いくつかの場合、ＭＬモデルは、ＵＲＬカテゴリレコード４１４内に記憶されている所定のＵＲＬカテゴリの組からＵＲＬカテゴリを選択し得る。

ＵＲＬからＵＲＬカテゴリを識別するために用いられるＭＬモデルは、コンピューティングプラットフォームにおけるユーザフィードバックを通して獲得された訓練データの組を用いて訓練され得る。例えば、商人がｅコマースプラットフォームにおける顧客注文を履行しているとき、商人は、注文の配送を追跡するためのＵＲＬを提供し得る。したがって、これらの状況において商人によって提供されたＵＲＬは、配送追跡に関しているとして分類され得る。これらのＵＲＬのみならず、配送追跡に関していない他のＵＲＬも、配送追跡に関しているＵＲＬを分類するようにＭＬモデルを訓練するために用いられる訓練データの組の基礎を形成し得る。

ステップ５０８は、プロセッサ４０４がステップ５０４において取得されたＵＲＬおよび／またはこのＵＲＬに関連付けられたウェブリソースに基づいて配送情報を決定することを含む。配送情報は、ウェブリソースが配送を追跡するためのものであることの指示、配送についての追跡番号、および配送についての配送プロバイダのうちの少なくとも１つを含む。ウェブリソースが配送を追跡するためのものであることを決定することは、ＵＲＬが追跡ＵＲＬであることを示し得る。したがって、ＵＲＬ自体が、ステップ５０８において決定された配送情報に追加され得る。配送情報は、配送される製品（単数または複数）、配送についての注文番号、配送状況、予想される送達日、および／または配送を開始した商人をさらに含み得る。いくつかの場合、配送は、複数の配送プロバイダによって促進され、および／または複数の関連付けられた追跡番号を有し得る。複数の関連付けられた追跡番号のうちのいずれか、それらのうちの１つ、それらのうちのいくつか、またはそれら全てが、ステップ５０８において決定され得る。

ステップ５０８のいくつかの実装では、配送情報のうちの少なくとも一部が、少なくとも１つのＭＬモデルを用いてＵＲＬから取得され、少なくとも１つのＭＬモデルは、ＭＬモデル（単数または複数）４１６のうちの１つであり得る。ＭＬモデルへの入力は、ＵＲＬを含み得る。しかしながら、ＵＲＬ全体が、常にＭＬモデルに入力されるわけではないこともある。ＵＲＬは構造化された性質を有するので、ＵＲＬの特定のコンポーネントが、抽出されてＭＬモデルに入力され、ＭＬモデルによって分析される文字の総数を低減させ得る。例えば、決定論的方法は、ＵＲＬのオーソリティコンポーネント、パスコンポーネント、および／またはクエリコンポーネントを抽出し、ＭＬモデルにそれらのコンポーネントを入力するように実装され得る。ＭＬモデルの出力は、ＵＲＬが配送を追跡することに関しているか否かの指示、配送についての追跡番号に対応する文字列、配送についての配送プロバイダに対応する文字列、および／または他の配送情報を含み得る。いくつかの実装では、配送プロバイダに対応する文字列は、配送プロバイダレコード４１２内の配送プロバイダのリストと比較される。これは、配送を促進している的確な配送プロバイダを決定することに役立ち得る。

ステップ５０８においてＵＲＬから配送情報を取得するために用いられるＭＬモデルは、コンピューティングプラットフォームのユーザから取得されたデータを用いて訓練され得る。例えば、商人がｅコマースプラットフォームにおける顧客注文を履行しているとき、商人は、注文の配送についての追跡ＵＲＬと、注文についての配送プロバイダと、注文のついての追跡番号とを提供し得る。この情報は、複数の製品注文にわたって収集され、ＭＬモデルのための訓練データの組の基礎を形成し得る。例えば、ＭＬモデルは、各ＵＲＬから正しい配送プロバイダおよび／または追跡番号を予測するように訓練され得る。

いくつかの実装では、ステップ５０８においてＵＲＬから配送情報を取得するために用いられるＭＬモデルへの入力は、ＵＲＬ中の追跡番号の始まりに対応する第１のインデックスの予測、および／またはＵＲＬ中の追跡番号の終わりに対応する第２のインデックスの予測をさらに含み得る。これらの予測は、追跡番号のＭＬモデルの決定の確度および／または信頼性を向上させ得る。例えば、予測は、ＭＬモデルが分析中にＵＲＬ中のいくつかの文字を無視することを可能にし得る。第１のインデックおよび第２のインデックスの予測は、確率分布の形式で提供され得る。ＭＬモデルに入力されるＵＲＬの各々の文字のために、ＭＬモデルは、文字が第１のインデックスである確率、および／または文字が第２のインデックスである確率を提供され得る。

ＵＲＬ中の追跡番号についての第１のインデックスの予測および第２のインデックスの予測は、各種の異なる手法のうちのいずれかで取得され得る。いくつかの実装では、第１のＭＬモデルが、第１のインデックスおよび／または第２のインデックスの予測を生成するように実装される。そして、この第１のインデックスおよび／または第２のインデックスは、上で説明されるように、追跡番号に対応する文字列を取得するために、第２のＭＬモデルに入力され得る。さらに、いくつかの実装では、第１のＭＬモデルおよび第２のＭＬモデルは、単一のＭＴＬモデルを用いて一緒に実装され得る。

いくつかの実装では、第１のＭＬモデルは、ＵＲＬが最も良く適合する所定のＵＲＬカテゴリの組のうちのＵＲＬカテゴリ（随意に、ＵＲＬカテゴリレコード４１４内に記憶されている）を決定することによって、ＵＲＬを分類する。所定のＵＲＬカテゴリは、追跡番号について概して定位置を有するフォーマットを有し得る。したがって、第１のインデックスの予測および／または第２のインデックスの予測は、決定されたＵＲＬカテゴリに基づいて、ＵＲＬカテゴリレコード４１４から取得され得る。ＵＲＬカテゴリは、特定の配送プロバイダにも関連付けられ得、したがって、配送についての配送プロバイダは、決定されたＵＲＬカテゴリに基づいてＵＲＬカテゴリレコード４１４からさらに取得され得る。

いくつかの実装では、ステップ５０６、５０８の両方が、第１のＭＬモデルを用いて少なくとも部分的に実装され得る。例えば、第１のＭＬモデルは、ＵＲＬを分類し得、決定されたカテゴリは、ＵＲＬが配送追跡に関していることを示し、追跡番号および／または配送プロバイダがＵＲＬから取得されることも可能にし得る。

第２のＭＬモデルと同様に、第１のＭＬモデルは、ｅコマースプラットフォームから取得された訓練データを用いて訓練され得る。例えば、商人が注文を完了させるためにｅコマースプラットフォームに追跡ＵＲＬを入力しているとき、商人は、ＵＲＬを分類し、ＵＲＬに関連付けられた配送番号および／または配送プロバイダを提供するように求められ得る。そして、文字列マッチングアルゴリズムが、ＵＲＬ中の追跡番号の第１のインデックスと第２のインデックスとを決定するために用いられ得、それは、第１のＭＬモデルのための訓練データの組の基礎を形成し得る。

いくつかの実装では第１のＭＬモデルのみがＵＲＬから配送情報を取得するために用いられることが留意されるべきである。例えば、第１のＭＬモデルは、追跡番号の第１のインデックス、追跡番号の第２のインデックス、および／または配送プロバイダを提供するＵＲＬについてのカテゴリを決定し得る。そして、この情報は、ＵＲＬ中の第１のインデックスと第２のインデックスとの間から追跡番号を抽出することによって追跡番号を取得するために用いられ得る。したがって、第１のＭＬモデルは、常に配送情報を決定するために第２のＭＬモデルと組み合わせて用いられるわけではないこともある。

ステップ５０８において、ＵＲＬから取得された配送情報は、ＵＲＬに関連付けられたウェブリソースから取得された配送情報を用いて補足され、および／または確認され得る。あるいは、配送情報は、ウェブリソースから全体的に取得され得る。ウェブリソースから配送情報を取得することは、ＵＲＬを用いてウェブリソースにアクセスすること、ウェブリソースからコンテンツを取得すること、および／またはコンテンツを構文解析して配送情報を決定することを含み得る。コンテンツを構文解析することは、例えばテキストおよび／または画像分析動作を含み得、ＭＬモデル（単数または複数）４１６のうちの１つを用いて少なくとも部分的に実施され得る。

ＵＲＬに関連付けられたウェブリソースを構文解析することの潜在的な利点は、ウェブリソースが詐欺的であるかどうかをプロセッサ４０４が決定することが可能であり得ることである。例えば、ＭＬモデル（ＭＬモデル（単数または複数）４１６のうちの１つであり得る）が、詐欺的ウェブページを認識するように訓練され得る。ウェブページが詐欺的であることを決定した後、そのウェブページについてのＵＲＬを含むメッセージは、フィッシングまたはスパムｅメールとしてフラグ付けされ得る。

いくつかの実装では、追跡番号および配送プロバイダは、ＵＲＬとウェブリソースとの両方から取得され得る。例えば、追跡番号および配送プロバイダは、まずＵＲＬを構文解析することによって取得され得、そして、追跡番号および配送プロバイダは、ウェブリソースを構文解析することによって確認され得る。これは、正しい追跡番号および配送プロバイダがステップ５０８において取得されていることを確実にすることに役立つようなある程度の冗長性を提供する。いくつかの場合、プロセッサ４０４は、ＵＲＬから取得された追跡番号および／または配送プロバイダに合致する文字列についてのウェブリソースを検索し得る。そのような文字列がウェブリソース中に見つけられた場合、追跡番号および／または配送プロバイダがウェブリソースによって確認されることが決定され得る。同様に、または、代わりに、他の決定論的方法および／または確率的方法が、ウェブリソース中の追跡番号および／または配送プロバイダを確認するために用いられ得る。

ＵＲＬから取得された追跡番号および／または配送プロバイダがウェブリソースから取得されたものと合致しない場合、さらなる処理が、不一致を解消するために実施され得る。例えば、ＵＲＬカテゴリがＵＲＬについて決定される場合、ＵＲＬカテゴリは、ＵＲＬから取得された配送情報か、またはウェブリソースからの配送情報のどちらが最も正確であるとみなされるかを決定するために用いられ得る。ＵＲＬカテゴリレコード４１４は、各ＵＲＬカテゴリについて、各ＵＲＬカテゴリからおよび／または関連付けられたウェブリソースから、配送情報がどのくらい正確に取得され得るかの指示を記憶し得る。そして、より正確でない配送情報が破棄され得る。あるいは、ユーザによる手動の介入が、ＵＲＬとウェブリソースとの間の不一致を解消するために用いられ得る。

例えば、追跡番号がＵＲＬから抽出され、関連付けられたウェブページからも追跡番号が抽出される場合を考慮されたい。これらの２つの追跡番号が合致する場合、追跡番号は確認され、さらなるアクションは取られない。あるいは、２つの追跡番号が異なる場合、より正確でない追跡番号が破棄され得る。いくつかの場合、メッセージ分析エンジンは、ＵＲＬから抽出された追跡番号をより正確でない追跡番号のＵＲＬとして扱うように構成され得る。他の場合、メッセージ分析エンジンは、ウェブページから抽出された追跡番号をより正確でない追跡番号として扱うように構成され得る。

いくつかの場合、追跡番号および配送プロバイダのうちの一方が、ＵＲＬを構文解析することによって決定され、追跡番号および配送プロバイダのうちの他方が、ウェブリソースを構文解析することによって決定される。したがって、ウェブリソースから決定された配送情報が、メッセージについて取得された配送情報の累積レコードに追加され得る。これは、追跡番号または配送プロバイダがＵＲＬを構文解析することによって決定されることができないときにときに起こり得、したがって、ウェブリソースを構文解析することは、ＵＲＬから取得された配送情報を補足するために実施される。例えば、ＵＲＬは、追跡番号を含まないこともあり、または、追跡番号は、ＵＲＬ中で符号化され、またはハッシュ化され得る。さらに、複数の異なる配送プロバイダが、同様のＵＲＬフォーマットを用い得る。したがって、特定の配送プロバイダが、ＵＲＬのフォーマットまたは決定されたカテゴリから推断可能でないこともある。

いくつかの場合、追跡番号および配送プロバイダのいずれもＵＲＬから取得されないこともある。よって、これらの場合、ステップ５０８は、ウェブリソースを構文解析することによって追跡番号と配送プロバイダとの両方を決定することを含み得る。ＵＲＬは、ウェブリソースにアクセスするために用いられ、そして、ウェブリソースは、配送情報を取得するために構文解析される。

いくつかの場合、ＵＲＬのみが、ステップ５０８において配送情報を取得するために構文解析される。これは、ウェブリソースが必要な配送情報を含まない場合、メッセージ分析エンジン４０２がウェブリソースを分析する性能を有しない場合、および／または配送情報が十分な程度の信頼性を有するＵＲＬから取得される場合に起こり得る。

いくつかの場合、所与のＵＲＬは、例えば推定される到達時間等の配送情報を含む画像に対応し得る。機械学習モデルが、そのような画像を分析するために（例えば、そのような画像の例から成る１つ以上の訓練データの組を用いて）訓練され得、そのような画像から情報を抽出することにおいて採用され得る。加えて、またはあるいは、例えば光学的文字認識等の技術が、そのような画像から情報を抽出することにおいて適用され得る。

ステップ５０８において実装され得るＭＬモデルは、配送情報を決定するための確率的方法の例である。いくつかの場合、後処理ステップが、ＭＬモデルを用いて取得された配送情報について実施され得る。後処理のある例は、ＭＬモデルを用いて取得された配送情報を確認しおよび／または補足するために決定論的方法を実装することである。

上で留意されるように、複数のＵＲＬが、ステップ５０４においてデジタルコンテンツから取得され得る。これらのＵＲＬの各々が、ステップ５０８において分析され得る。いくつかの場合、デジタルコンテンツ中の２つ以上のＵＲＬが、配送情報を含み得る。２つ以上のＵＲＬから取得された配送情報は、ＵＲＬが同一の配送に関しているか、または異なる配送に関しているかを決定するために比較され得る。配送情報は、ＵＲＬが複数の段階にある同一の配送を送達している複数の配送プロバイダに関しているかどうかを決定するためにも比較され得る。

２つのＵＲＬが同一の配送に関している場合、２つの異なるＵＲＬから取得された配送情報は、確認の目的のために比較され得る。さらに、メッセージ中の２つのＵＲＬから取得された配送情報は、ＵＲＬのうちの１つから取得された配送情報と、関連付けられたウェブリソースから取得された配送情報との間の不一致を解消するために用いられ得る。例えば、第１のＵＲＬから抽出された追跡番号が、メッセージ中の第２のＵＲＬの分析を通して同様に決定された場合、第１のＵＲＬに関連付けられたウェブリソースから抽出された異なる追跡番号は、無視され得る。

ある例によると、第１のＵＲＬと第２のＵＲＬとが、ステップ５０４においてデジタルコンテンツから取得され得る。第１のＵＲＬは、第１のウェブリソースに関連付けられており、第２のＵＲＬは、第２のウェブリソースに関連付けられている。ここで、ステップ５０８は、第１のＵＲＬと第２のＵＲＬとが同一の配送に対応することを決定すること、第１のＵＲＬ、第２のＵＲＬ、第１のウェブリソース、および／もしくは第２のウェブリソースから同一の追跡番号を取得すること、ならびに／または、第１のＵＲＬ、第２のＵＲＬ、第１のウェブリソース、および／もしくは第２のウェブリソースから同一の配送プロバイダを取得することを含み得る。

いくつかの場合、ステップ５０４においてメッセージから抽出されたＵＲＬのうちの１つ以上は、配送追跡に関していないこともある。プロセッサ４０４が、ＵＲＬが配送追跡に関していないことを決定する場合、そのＵＲＬの分析は終了し、ステップ５０８は、次のＵＲＬを分析することに進むか、またはステップ５１０に進み得る。

ステップ５１０は、ステップ５０８において決定された配送情報をメモリ４０６内または別のコンピュータ読み取り可能な媒体内に記憶することを含む。いくつかの実装では、配送情報は、配送情報レコード４１８内に記憶され得る。配送情報は、後に、配送についての追跡最新情報を取得するために用いられ得る。例えば、メッセージ分析エンジン４０２またはユーザデバイス４３０は、配送情報にアクセスし、配送を促進している配送プロバイダから更新された配送情報を取得し得る。これは、配送についての更新された送達日を提供し得、更新された送達日は、メモリ４０６内に記憶されている配送情報に追加され得る。

ステップ５１０からステップ５０２への矢印を用いて例証されるように、ステップ５０２、５０４、５０６、５０８、５１０は、それぞれにメッセージについて複数回繰り返され得る。これは、配送情報レコード４１８内の複数の配送に関係する配送情報の累積レコードを構築し得る。これらの複数の配送は、全て、同一のユーザに関するものであり得る。例として、ステップ５０２の複数のインスタンスが、ユーザに関連付けられた複数のメッセージに対応するデジタルコンテンツを取得し得る。これらのメッセージは、一度に、または複数の異なる回数で取得され得る。これらのメッセージの各々は、顧客についての異なる製品配送に対応し得る。ステップ５０４の複数のインスタンスは、メッセージの各々についてのデジタルコンテンツからＵＲＬを取得し得、ステップ５０８の複数のインスタンスは、ＵＲＬおよび／またはそれらの関連付けられたウェブリソースから配送情報を取得し得る。そして、ステップ５１０の複数のインスタンスは、メモリ４０６内にこの配送情報を記憶し得る。これは、ユーザのための複数の配送に関係する配送情報を配送情報レコード４１８に追加し得る。

配送情報は、顧客についての１つ以上の製品配送の追跡最新情報を取得するために用いられ得る。１つ以上の製品配送の取得された追跡最新情報は、顧客についての全ての製品配送（単数または複数）の集約された概要を提示することにおける使用のために提供され得る。

ステップ５１２は、プロセッサがユーザデバイス４３０または別のデバイス上での表示のために配送情報レコード４１８内の配送情報のうちの少なくとも一部を出力することを含む随意のステップである。例えば、方法５００を用いて分析されたメッセージ（単数または複数）は、ユーザデバイス４３０のユーザに対応し得、したがって、ユーザデバイス４３０は、配送情報レコード４１８内に記憶されている配送情報のうちの少なくとも一部へのアクセスを与えられ得る。この配送情報のうちのいずれか、それらのうちのいくつか、またはそれら全てが、ユーザデバイス４３０上での表示のために、メッセージ分析エンジン４０２によって出力され得る。

ユーザデバイス４３０のユーザは、配送情報レコード４１８内に記憶されている配送情報のうちの少なくとも一部を変更することを可能にされ得る。例えば、ユーザデバイス４３０を用いて、ユーザは、配送情報レコード４１８を変更するための命令を生成し得る。配送情報レコード４１８を変更する非限定的な例は：
・新たな配送または既存の配送についてのものであり得る配送情報を追加すること；
・配送が受け取られたとき、またはいくつかの配送情報が正しくないとき、配送情報を除去すること；および
・ユーザの好みに基づいて配送情報をまとめ直すこと
を含む。

加えて、または、あるいは、配送情報を変更することは、正しくない配送情報の訂正を含み得る。例えば、そのような訂正は、訂正された配送情報の入力を含み得る。いくつかの場合、ユーザは、代替の配送情報のための１つ以上のオプションを提示され得る。配送情報の訂正の入力は、そのようなオプションに応答して受信され得、提示されたオプションのうちの１つの選択に対応し得る。特に、機械学習が、例えば上で議論された態様等で配送情報を取得することにおいて採用される場合、そのような代替物のリスト中に提示されるオプションは、例えば、おそらく配送情報であるがより低い信頼性を有する情報として機械学習モデルが識別した配送情報の候補等、機械学習モデルの適用によって識別された配送情報についての他の候補を含み得る。あるいは、いくつかの実装では、配送情報への訂正が受信された場合、それらの訂正（訂正された配送情報の入力によって受信されたか、代替の配送情報の選択に基づいて受信されたか、または別様かに関係ない）は、後に、確度を向上させることを目的とする配送情報の識別のために、（例えば、訂正された情報を訓練の組に追加することによって）機械学習モデルを更新し／再び訓練することにおいて採用され得る。

ステップ５０２、５０４、５０６、５０８、５１０、５１２の順序は、例としてのみ示される。ステップ５０２、５０４、５０６、５０８、５１０、５１２の他の順序も構想される。例えば、ステップ５０６は、ステップ５０４がメッセージに対応するデジタルコンテンツからＵＲＬを取得するために実施される前に、メッセージが配送を追跡することに関していることを決定し得る。
メッセージから配送情報を取得する例

図６および図７は、顧客（「Ｍｅｒｅｄｉｔｈ Ｚｈａｏ」）への第１の製品（「Ｗｉｎｔｅｒ Ｗｏｎｄｅｒｌａｎｄ １０００ Ｐｉｅｃｅ Ｐｕｚｚｌｅ」）の配送についての配送情報を取得する例を例証している。まず図６を参照すると、第１の製品を販売した商人（「Ｐｉｅｒｃｅ’ｓ Ｐｕｚｚｌｅｓ」）から顧客によって受信されたｅメールメッセージ６００が示されている。ｅメールメッセージ６００は、配送に対応する注文番号６０２と、第１の製品が配送されていることの指示６０４と、顧客の配送住所６０６と、配送についての追跡番号６０８と、配送を促進している配送プロバイダ（「Ｐｅｒｆｅｃｔ Ｐｏｓｔａｌ Ｓｅｒｖｉｃｅ」）の指示６１０と、配送についての追跡ＵＲＬ６１２とを含む。追跡ＵＲＬ６１２は、追跡番号６０８に対応する文字列６１４と、配送プロバイダに対応する別の文字列６１６とを含む。

図７は、追跡ＵＲＬ６１２に対応するウェブページ７００を例証している。例えば、顧客がｅメールメッセージ６００中の追跡ＵＲＬ６１２を選択した場合、顧客は、ウェブページ７００に案内され得る。ウェブページ７００は、注文番号６０２と、追跡番号６０８と、配送プロバイダの指示６１０と、予想される送達日の指示７０２とを含む。

方法５００は、顧客への第１の製品の配送についての配送情報を取得するために用いられ得る。ステップ５０２において、ｅメールメッセージ６００に対応するデジタルコンテンツは、例えばメッセージングサービスにおける顧客のアカウントから取得され得る。このデジタルコンテンツは、随意にシリアル化されたフォーマットで、図６に示されるコンテンツのうちのいずれか、それらのうちのいくつか、またはそれら全てを含み得る。ステップ５０４において、追跡ＵＲＬ６１２は、例えば文字列マッチングアルゴリズムを用いてデジタルコンテンツから抽出される。ステップ５０６は、メッセージ６００が配送を追跡することに関していることを決定し得る。これは、ｅメールメッセージ６００を配送追跡に関しているメッセージとして分類するために、ＭＬモデルにｅメールメッセージ６００のデジタルコンテンツを入力することによって実施され得る。あるいは、または、加えて、追跡ＵＲＬ６１２の少なくとも一部が、追跡ＵＲＬ６１２を配送追跡に関しているとして分類するために、ＭＬモデルに入力され得る。

ステップ５０８において、第１の製品の配送についての配送情報が、追跡ＵＲＬ６１２およびウェブページ７００の両方から取得され得る。追跡ＵＲＬ６１２は、ウェブページ７００が第１の製品の配送を追跡するためのものであることを決定するために構文解析され得る。追跡ＵＲＬ６１２は、追跡番号６０８に対応する文字列６１４と、配送プロバイダに対応する文字列６１６とを取得するためにも構文解析され得る。文字列６１６は、文字列６１６が配送プロバイダに対応することを決定するために、メモリ内に記憶されている配送プロバイダのリストに対して比較され得る。製品を販売し配送した商人は、追跡ＵＲＬ６１２において識別され、したがって、商人も、追跡ＵＲＬ６１２を構文解析することによって取得され得る。

追跡ＵＲＬ６１２を構文解析することは、１つ以上のＭＬモデルに追跡ＵＲＬ６１２の少なくとも一部を入力することを伴い得る。例えば、クエリコンポーネント（「Ｉｄ＝１１１１１０００＆ｓｈｉｐｐｉｎｇｐｒｏｖｉｄｅｒ＝ＰＰＳ」）は、決定論的方法を用いて追跡ＵＲＬ６１２から抽出され、ＭＬモデルに入力され得る。

いくつかの場合、追跡ＵＲＬ６１２は、追跡ＵＲＬ６１２を分類するために第１のＭＬモデルに入力される。追跡ＵＲＬ６１２の決定されたカテゴリは、追跡ＵＲＬ６１２が商人および／または配送プロバイダに対応することを予測し得る。あるいは、または、代わりに、決定された追跡ＵＲＬ６１２のカテゴリは、文字列６１４の始まりに対応する第１のインデックスの予測、および／または文字列６１４の終わりに対応する第２のインデックスの予測を提供し得る。例証される例では、第１のインデックスは、４２であり、第２のインデックスは、４９である（追跡ＵＲＬ６１２の始まりからカウントされる）。第１のインデックスおよび第２のインデックスは、追跡ＵＲＬ６１２から追跡番号６０８を抽出するために用いられ得る。そして、追跡ＵＲＬ６１２、予測された配送プロバイダ、予測された第１のインデックス、および／または予測された第２のインデックスが、第２のＭＬモデルに入力され得る。第２のＭＬモデルの出力は、配送プロバイダおよび／または追跡番号６０８の洗練された予測を含み得る。第２のＭＬモデルが第１のＭＬモデルの結果から恩恵を受け得るので、このマルチステップアプローチで配送プロバイダおよび／または追跡番号６０８を決定することは、より正確な結果を提供し得る。あるいは、第１のＭＬモデルまたは第２のＭＬモデルは、配送プロバイダおよび／または追跡番号６０８を決定するために別々に用いられ得る。

ウェブページ７００も、追跡ＵＲＬ６１２から取得された配送プロバイダ、商人、および／または追跡番号６０８を確認するために、ステップ５０８において構文解析され得る。さらに、ウェブページ７００を構文解析することは、指示７０２から予想される送達日を決定し、および／または注文番号６０２を決定し得る。例えばＭＬモデルを用いて実装される確率的方法は、ウェブページ７００を構文解析し、この配送情報を取得するために用いられ得る。

図８および図９は、顧客（「Ｍｅｒｅｄｉｔｈ Ｚｈａｏ」）への第２の製品（「Ｂｏｏｋ ｏｎ Ｔｒｅｅｓ」）の配送についての配送情報を取得する例を例証している。まず図８を参照すると、製品を販売した商人（「Ｂｏｏｋ Ｏｕｔｌｅｔ」）から顧客によって受信されたｅメールメッセージ８００が示されている。ｅメールメッセージ８００は、配送に対応する注文番号８０２と、製品が配送されていることの指示８０４と、配送についての追跡番号８０６と、配送を促進している配送プロバイダ（「Ｒａｐｉｄ Ｄｅｌｉｖｅｒｙ」）の指示８０８と、ハイパーリンク８１０とを含む。ハイパーリンク８１０は、図９に示される追跡ＵＲＬ９０２に対応する。

図９は、追跡ＵＲＬ９０２に対応するウェブページ９００を例証している。ウェブページ９００は、注文番号８０２と、追跡番号８０６と、配送プロバイダの指示８０８と、顧客の配送住所９０４と、予期される送達日の指示９０６とを含む。

方法５００は、顧客に第２の製品の配送のための配送情報を取得するためにも用いられ得る。ステップ５０２において、ｅメールメッセージ８００に対応するデジタルコンテンツが、メッセージングサービスにおける顧客のアカウントから取得され得る。これは、ｅメールメッセージ６００が取得されたものと同一のメッセージングサービスであることも、異なるメッセージングサービスであることもある。ステップ５０４、５０６において、追跡ＵＲＬ９０２は、ハイパーリンク８１０から抽出され、ｅメールメッセージ８００は、配送を追跡することに関していることを決定される。

そして、ステップ５０８は、追跡ＵＲＬ９０２から、およびウェブページ９００から配送情報を取得するために実施され得る。追跡ＵＲＬ９０２を構文解析することは、第２の製品の配送についての商人および／または注文番号を決定し得、それらは、追跡ＵＲＬ９０２において識別される。しかしながら、追跡ＵＲＬ９０２は、追跡番号８０６に対応する文字列をいずれも含まず、したがって、追跡ＵＲＬ９０２から追跡番号８０６を決定することが可能ではないことがある。しかしながら、追跡番号８０６は、ウェブページ９００を構文解析することによって決定され得る。

いくつかの場合、配送プロバイダ（「Ｒａｐｉｄ Ｄｅｌｉｖｅｒｙ」）は、追跡ＵＲＬ９０２から決定され得る。例えば、追跡ＵＲＬ９０２は、追跡ＵＲＬ９０２が商人に対応していることを決定するために分類され得る。商人が典型的に１つの配送プロバイダのみを用いる場合、この追跡ＵＲＬ９０２の分類は、配送についての配送プロバイダも示し得る。配送プロバイダは、ウェブページ９００を構文解析することによっても取得されまたは確認され得る。

注文番号８０２、および９０６で示される予期される送達日を含むさらなる配送情報も、ウェブページ９００を構文解析することによって取得され得る。

顧客への第１の製品の配送について取得された配送情報、および顧客への第２の製品の配送について取得された配送情報は、一元管理された配送情報のリストまたはレコードに追加され得る。図１０は、顧客（「Ｍｅｒｅｄｉｔｈ Ｚｈａｏ」）についての一元管理された配送情報のレコード１０００の例を例証している。レコード１０００は、配送情報の３つの行１００２、１００４、１００６を含み、行１００２、１００４、１００６の各々は、異なる配送に関係している。行１００２は、第１の製品（「Ｗｉｎｔｅｒ Ｗｏｎｄｅｒｌａｎｄ １０００ Ｐｉｅｃｅ Ｐｕｚｚｌｅ」）の配送に対応しており、行１００４は、第２の製品（「Ｂｏｏｋ ｏｎ Ｔｒｅｅｓ」）の配送に対応しており、行１００６は、さらなる製品の配送に対応している。レコード１０００は、各配送についての配送情報の複数の列１００８、１０１０、１０１２、１０１４、１０１６、１０１８をさらに含む。列１００８は、各配送についての商人を示し、列１０１０は、各配送についての注文番号を示し、列１０１２は、各配送についての追跡番号を示し、列１０１４は、各配送についての配送プロバイダを示し、列１０１６は、各配送について推定されまたは確認された送達日を示し、列１０１８は、各配送についての追跡ＵＲＬを有するハイパーリンクを含む。

例証される例において、行１００２における配送情報は、上で議論されるように、追跡ＵＲＬ６１２およびウェブページ７００の分析を通して取得される。したがって、行１００２は、注文番号６０２と、追跡番号６０８と、配送プロバイダの指示６１０と、推定される送達日の指示７０２とを含む。行１００２列１０１８に位置しているハイパーリンクは、追跡ＵＲＬ６１２に対応しており、それは、顧客がレコード１０００からウェブページ７００にアクセスすることを可能にする。同様に、行１００４内の配送情報は、上で議論されるように、追跡ＵＲＬ９０２およびウェブページ９００の分析を通して取得される。したがって、行１００４は、注文番号８０２と、追跡番号８０６と、配送プロバイダの指示８０８と、推定される送達日の指示９０６とを含む。行１００４列１０１８にあるハイパーリンクは、追跡ＵＲＬ９０２に対応しており、ユーザがレコード１０００からウェブページ９００にアクセスすることを可能にする。

レコード１０００は、顧客が製品についての新たな注文をし、それらの注文についての配送情報が顧客のメッセージを通して利用可能になったときに、継続的におよび／または断続的に更新され得る。さらに、顧客は、レコード１０００を手動で変更し得る。
結論

本発明はその特定の特徴および実施形態を参照して説明されたが、本発明から逸脱せず、種々の修正物および組み合わせ物が作製され得る。よって、説明および図面は、単に、添付の請求項によって定義される本発明のいくつかの実施形態の例証とみなされるべきであり、本発明の範囲内に属する任意のおよび全ての修正物、変更物、組み合わせ物、または同等物を網羅するように想定される。したがって、本発明およびその利点が詳細に説明されたが、種々の変化、代用、および変更が、添付の請求項によって定義される本発明から逸脱せず、本明細書においてなされ得る。そのうえ、本願の範囲は、本明細書中で説明されるプロセス、機械、製造、化合物、手段、方法、およびステップの特定の実施形態に限定されるように意図されていない。当業者は、本発明の開示から、本明細書中で説明される対応する実施形態と実質的に同一の機能を実施し、または同一の結果を達成する、既存または今後開発されるプロセス、機械、製造、化合物、手段、方法、またはステップが、本発明によって活用され得ることを、容易に認識するだろう。よって、添付の請求項は、そのようなプロセス、機械、製造、化合物、手段、方法、またはステップ等のそれらの範囲内に含まれるように意図される。

そのうえ、命令を実行する本明細書中で例示される任意のモジュール、コンポーネント、またはデバイスは、非一過性のコンピュータ／プロセッサ読み取り可能なストレージ媒体（単数または複数）を含むか、さもなければそれらへのアクセスを有し得、非一過性のコンピュータ／プロセッサ読み取り可能なストレージ媒体（単数または複数）は、コンピュータ／プロセッサ読み取り可能な命令、データ構造、プログラムモジュール、および／または他のデータ等の情報のストレージのためである。非一過性のコンピュータ／プロセッサ読み取り可能なストレージ媒体の例の非網羅的なリストは、磁気カスケット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、光学ディスク（コンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、デジタルビデオディスクもしくはデジタルバーサタイルディスク（ＤＶＤ）、Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ、または任意の光学ストレージ等）、任意の方法またはテクノロジで実装される揮発性および不揮発性の除去可能および除去不可能媒体、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリテクノロジを含む。任意のそのような非一過性コンピュータ／プロセッサストレージ媒体は、デバイスの一部であるか、またはデバイスにアクセス可能もしくは接続可能であり得る。本明細書中で説明される任意のアプリケーションまたはモジュールは、そのような非一過性のコンピュータ／プロセッサ読み取り可能なストレージ媒体によって記憶されているか、さもなければ保持され得るコンピュータ／プロセッサ読み取り可能／実行可能な命令を用いて実装され得る。

本教示は、以下の番号受けされる項目のうちの１つ以上の特徴にも拡張される。
（項目１）
コンピュータ実装方法であって、前記コンピュータ実装方法は、
メッセージに対応するデジタルコンテンツを取得することと、
前記デジタルコンテンツから、ウェブリソースについてのｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ）を取得することと、
前記ＵＲＬおよび前記ウェブリソースに基づいて、配送情報を決定することであって、前記配送情報は、
前記ウェブリソースが配送を追跡するためのものであることの指示と、
前記配送についての追跡番号と、
前記配送についての配送プロバイダと
のうちの少なくとも１つを備えている、ことと
前記配送についての追跡最新情報を取得するために前記配送情報をメモリ内に記憶することと
を含む、コンピュータ実装方法。
（項目２）
前記配送情報を決定することは、
前記ＵＲＬを構文解析することによって、前記追跡番号と前記配送プロバイダとを決定することと、
前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとを確認することと
を含む、項目１に記載のコンピュータ実装方法。
（項目３）
前記配送情報を決定することは、
前記ＵＲＬを構文解析することによって、前記追跡番号と前記配送プロバイダとのうちの一方を決定することと、
前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとのうちの他方を決定することと
を含む、項目１に記載のコンピュータ実装方法。
（項目４）
前記配送情報を決定することは、前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとを決定することを含む、項目１に記載のコンピュータ実装方法。
（項目５）
前記配送情報を決定することは、
機械学習（ＭＬ）モデルに前記ＵＲＬを入力することと、
前記ＭＬモデルの出力に基づいて、前記ＵＲＬから前記追跡番号に対応する文字列を取得することと
を含む、項目１に記載のコンピュータ実装方法。
（項目６）
前記配送情報を決定することは、
予測を取得することであって、前記予測は、前記ＵＲＬ中の前記追跡番号の始まりに対応する第１のインデックスと、前記ＵＲＬ中の前記追跡番号の終わりに対応する第２のインデックスとを備えている、ことと
前記第１のインデックスと前記第２のインデックスとを前記ＭＬモデルに入力することと
をさらに含む、項目５に記載のコンピュータ実装方法。
（項目７）
前記ＭＬモデルは、マルチタスク学習モデルを備えている、項目５に記載のコンピュータ実装方法。
（項目８）
前記配送情報を決定することは、
機械学習（ＭＬ）モデルに前記ＵＲＬを入力することと、
前記ＭＬモデルの出力から、所定の配送プロバイダの組から選択される前記配送プロバイダに対応する文字列を取得することと
を含む、項目１に記載のコンピュータ実装方法。
（項目９）
前記ＵＲＬは、第１のＵＲＬであり、前記ウェブリソースは、第１のウェブリソースであり、前記追跡番号は、第１の追跡番号であり、前記配送プロバイダは、第１の配送プロバイダであり、前記方法は、
前記デジタルコンテンツから、第２のウェブリソースについての第２のＵＲＬを取得することと、
前記第２のＵＲＬと前記第２のウェブリソースとに基づいて、
前記第２のウェブリソースが前記配送を追跡するためのものであることと、
前記配送についての第２の追跡番号と、
前記配送についての第２の配送プロバイダと
を決定することと、
前記第１の追跡番号が前記第２の追跡番号に合致することと、前記第１の配送プロバイダが前記第２の配送プロバイダに合致することとを決定することと
をさらに含む、項目１に記載のコンピュータ実装方法。
（項目１０）
前記デジタルコンテンツに基づいて、前記メッセージが前記配送を追跡することに関していることを決定することをさらに含む、項目１に記載のコンピュータ実装方法。
（項目１１）
前記メッセージが前記配送を追跡することに関していることを決定することは、
機械学習（ＭＬ）モデルに前記デジタルコンテンツを入力することと、
前記ＭＬモデルの出力から、所定のメッセージカテゴリの組から選択される前記メッセージについてのメッセージカテゴリを取得することと、
前記メッセージカテゴリが配送追跡に関していることを決定することと
を含む、項目１０に記載のコンピュータ実装方法。
（項目１２）
前記メッセージが前記配送を追跡することに関していることを決定することは、
機械学習（ＭＬ）モデルに前記ＵＲＬを入力することと、
前記ＭＬモデルの出力から、所定のＵＲＬカテゴリの組から選択される前記ＵＲＬについてのＵＲＬカテゴリを取得することと、
前記ＵＲＬカテゴリが配送追跡に関していることを決定することと
を含む、項目１０に記載のコンピュータ実装方法。
（項目１３）
前記メッセージは、特定のユーザに対応しており、
前記配送情報を記憶することは、前記特定のユーザに関連付けられた複数の配送についての配送情報レコード内に前記配送情報を記憶することを含み、
前記方法は、前記特定のユーザに関連付けられたデバイス上での表示のために、前記配送情報レコードのうちの少なくとも一部を出力することをさらに含む、項目１に記載のコンピュータ実装方法。
（項目１４）
システムであって、前記システムは、
少なくとも１つのプロセッサであって、前記少なくとも１つのプロセッサは、
メッセージに対応するデジタルコンテンツを取得することと、
前記デジタルコンテンツから、ウェブリソースについてのｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ （ＵＲＬ）を取得することと、
前記ＵＲＬおよび前記ウェブリソースに基づいて、配送情報を決定することと
を行い、前記配送情報は、
前記ウェブリソースが配送を追跡するためのものでることの指示と、
前記配送についての追跡番号と、
前記配送についての配送プロバイダと
のうちの少なくとも１つを備えている、少なくとも１つのプロセッサと、
前記配送についての追跡最新情報を取得するために前記配送情報を記憶するためのメモリと
を備えている、システム。
（項目１５）
前記少なくとも１つのプロセッサは、
前記ＵＲＬを構文解析することによって、前記追跡番号と前記配送プロバイダとを決定することと、
前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとを確認することと
をさらに行う、項目１４に記載のシステム。
（項目１６）
前記少なくとも１つのプロセッサは、
前記ＵＲＬを構文解析することによって、前記追跡番号と前記配送プロバイダとのうちの一方を決定することと、
前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとのうちの他方を決定することと
をさらに行う、項目１４に記載のシステム。
（項目１７）
前記少なくとも１つのプロセッサは、前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとを決定することをさらに行う、項目１４に記載のシステム。
（項目１８）
前記少なくとも１つのプロセッサは、
機械学習（ＭＬ）モデルに前記ＵＲＬを入力することと、
前記ＭＬモデルの出力に基づいて、前記ＵＲＬから前記追跡番号に対応する文字列を取得することと
をさらに行う、項目１４に記載のシステム。
（項目１９）
前記少なくとも１つのプロセッサは、
予測を取得することであって、前記予測は、前記ＵＲＬ中の前記追跡番号の始まりに対応する第１のインデックスと、前記ＵＲＬ中の前記追跡番号の終わりに対応する第２のインデックスとを備えている、ことと
前記第１のインデックスと前記第２のインデックスとを前記ＭＬモデルに入力することと
をさらに行う、項目１８に記載のシステム。
（項目２０）
前記ＭＬモデルは、マルチタスク学習モデルを備えている、項目１８に記載のシステム。
（項目２１）
前記少なくとも１つのプロセッサは、
機械学習（ＭＬ）モデルに前記ＵＲＬを入力することと、
前記ＭＬモデルの出力から、所定の配送プロバイダの組から選択される前記配送プロバイダに対応する文字列を取得することと
をさらに行う、項目１４に記載のシステム。
（項目２２）
前記ＵＲＬは、第１のＵＲＬであり、前記ウェブリソースは、第１のウェブリソースであり、前記追跡番号は、第１の追跡番号であり、前記配送プロバイダは、第１の配送プロバイダであり、前記少なくとも１つのプロセッサは、
前記デジタルコンテンツから、第２のウェブリソースについての第２のＵＲＬを取得することと、
前記第２のＵＲＬと前記第２のウェブリソースとに基づいて、
前記第２のウェブリソースが前記配送を追跡するためのものであることと、
前記配送についての第２の追跡番号と、
前記配送についての第２の配送プロバイダと
を決定することと、
前記第１の追跡番号が前記第２の追跡番号に合致することと、前記第１の配送プロバイダが前記第２の配送プロバイダに合致することとを決定することと
をさらに行う、項目１４に記載のシステム。
（項目２３）
前記少なくとも１つのプロセッサは、
機械学習（ＭＬ）モデルに前記ＵＲＬを入力することと、
前記ＭＬモデルの出力から、所定のＵＲＬカテゴリの組から選択される前記ＵＲＬについてのＵＲＬカテゴリを取得することと、
前記ＵＲＬカテゴリが配送追跡に関していることを決定することと
をさらに行う、項目１４に記載のシステム。
（項目２４）
前記メッセージは、特定のユーザに対応しており、
前記メモリは、さらに、前記特定のユーザに関連付けられた複数の配送についての配送情報レコード内に前記配送情報を記憶し、
前記少なくとも１つのプロセッサは、さらに、前記特定のユーザに関連付けられたデバイス上での表示のために、前記配送情報の少なくとも一部を出力する、項目１４に記載のシステム。
（項目２５）
命令を記憶している非一過性のコンピュータ読み取り可能なストレージ媒体であって、前記命令は、コンピュータシステムのプロセッサによって実行されると、
メッセージに対応するデジタルコンテンツを取得することと、
前記デジタルコンテンツから、ウェブリソースについてのｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ （ＵＲＬ）を取得することと、
前記ＵＲＬおよび前記ウェブリソースに基づいて、配送情報を決定することであって、前記配送情報は、
前記ウェブリソースが配送を追跡するためのものでることの指示と、
前記配送についての追跡番号と、
前記配送についての配送プロバイダと
のうちの少なくとも１つを備えている、ことと、
前記配送についての追跡最新情報を取得するに、前記配送情報をメモリ内に記憶することと
を前記コンピュータシステムに行わせる、非一過性のコンピュータ読み取り可能なストレージ媒体。

Claims (15)

1. コンピュータ実装方法であって、前記コンピュータ実装方法は、
   顧客についての複数のメッセージを識別することと、
   前記複数のメッセージのうちのメッセージから、少なくとも１つの配送についての配送情報を抽出することであって、抽出することは、
   前記複数のメッセージの所与のメッセージに対応するデジタルコンテンツを取得することと、
   前記デジタルコンテンツからウェブリソースについてのｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ）を取得することと、
   １つ以上の機械学習（ＭＬ）モデルに前記ＵＲＬを入力し、前記１つ以上のＭＬモデルの出力に基づいて、前記ＵＲＬから追跡番号に対応する文字列を取得することによって、前記ＵＲＬおよび前記ウェブリソースに基づいて、特定の配送についての配送情報を決定することと
   を含み、
   前記配送情報は、
   前記ウェブリソースが前記特定の配送を追跡するためのものであることの指示と、
   前記特定の配送についての追跡番号と、
   前記特定の配送についての配送プロバイダと
   のうちの少なくとも１つを備えている、ことと
   前記特定の配送についての追跡最新情報を取得するために前記配送情報をメモリ内に記憶することと
   を含む、コンピュータ実装方法。
2. 前記配送情報に基づいて、前記少なくとも１つの配送についての追跡最新情報を取得することと、
   前記顧客についての製品配送の集約された概要を提示することにおける使用のために前記追跡最新情報を提供することと
   をさらに含む、請求項１に記載のコンピュータ実装方法。
3. 前記配送情報を決定することは、
   予測を取得することであって、前記予測は、前記ＵＲＬ中の前記追跡番号の始まりに対応する第１のインデックスと、前記ＵＲＬ中の前記追跡番号の終わりに対応する第２のインデックスとを備えている、ことと、
   前記第１のインデックスと前記第２のインデックスとを前記１つ以上のＭＬモデルに入力することと
   をさらに含む、請求項１または２に記載のコンピュータ実装方法。
4. 前記配送情報を決定することは、
   前記１つ以上のＭＬモデルに前記ＵＲＬを入力することと、
   前記１つ以上のＭＬモデルの出力から、所定の配送プロバイダの組から選択される前記配送プロバイダに対応する文字列を取得することと
   を含む、請求項１または２に記載のコンピュータ実装方法。
5. 前記配送情報を決定することは、
   前記ＵＲＬを構文解析することによって、前記追跡番号と前記配送プロバイダとを決定することと、
   前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとを確認することと
   を含む、請求項１～４のうちのいずれか一項に記載のコンピュータ実装方法。
6. 前記配送情報を決定することは、
   前記ＵＲＬを構文解析することによって、前記追跡番号と前記配送プロバイダとのうちの一方を決定することと、
   前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとのうちの他方を決定することと
   を含む、請求項１～４のうちのいずれか一項に記載のコンピュータ実装方法。
7. 前記配送情報を決定することは、前記ウェブリソースを構文解析することによって、前記追跡番号と前記配送プロバイダとを決定することを含む、請求項１～４のうちのいずれか一項に記載のコンピュータ実装方法。
8. 前記１つ以上のＭＬモデルのうちの少なくとも１つは、マルチタスク学習モデルを備えている、請求項１～７のうちのいずれか一項に記載のコンピュータ実装方法。
9. 前記ＵＲＬは、第１のＵＲＬであり、前記ウェブリソースは、第１のウェブリソースであり、前記追跡番号は、第１の追跡番号であり、前記配送プロバイダは、第１の配送プロバイダであり、前記方法は、
   前記デジタルコンテンツから、第２のウェブリソースについての第２のＵＲＬを取得することと、
   前記第２のＵＲＬと前記第２のウェブリソースとに基づいて、
   前記第２のウェブリソースが前記配送を追跡するためのものであることと、
   前記配送についての第２の追跡番号と、
   前記配送についての第２の配送プロバイダと
   を決定することと、
   前記第１の追跡番号が前記第２の追跡番号に合致することと、前記第１の配送プロバイダが前記第２の配送プロバイダに合致することとを決定することと
   をさらに含む、請求項１～８のうちのいずれか一項に記載のコンピュータ実装方法。
10. 前記デジタルコンテンツに基づいて、前記メッセージが前記配送を追跡することに関していることを決定することをさらに含む、請求項１～９のうちのいずれか一項に記載のコンピュータ実装方法。
11. 前記メッセージが前記配送を追跡することに関していることを決定することは、
    前記１つ以上のＭＬモデルに前記デジタルコンテンツを入力することと、
    前記１つ以上のＭＬモデルの出力から、所定のメッセージカテゴリの組から選択される前記メッセージについてのメッセージカテゴリを取得することと、
    前記メッセージカテゴリが配送追跡に関していることを決定することと
    を含む、請求項１０に記載のコンピュータ実装方法。
12. 前記メッセージが前記配送を追跡することに関していることを決定することは、
    前記１つ以上のＭＬモデルに前記ＵＲＬを入力することと、
    前記１つ以上のＭＬモデルの出力から、所定のＵＲＬカテゴリの組から選択される前記ＵＲＬについてのＵＲＬカテゴリを取得することと、
    前記ＵＲＬカテゴリが配送追跡に関していることを決定することと
    を含む、請求項１０に記載のコンピュータ実装方法。
13. 前記メッセージは、特定のユーザに対応しており、
    前記配送情報を記憶することは、前記特定のユーザに関連付けられた複数の配送についての配送情報レコード内に前記配送情報を記憶することを含み、
    前記方法は、前記特定のユーザに関連付けられたデバイス上での表示のために、前記配送情報レコードのうちの少なくとも一部を出力することをさらに含む、請求項１～１２のうちのいずれか一項に記載のコンピュータ実装方法。
14. システムであって、前記システムは、
    請求項１～１３のうちのいずれか一項に記載の方法を実行するように構成されている少なくとも１つのプロセッサと、
    前記配送情報を記憶するためのメモリと
    を備えている、システム。
15. コンピュータプログラムであって、前記コンピュータプログラムは、コンピュータのプロセッサ上で実行されると、請求項１～１３のうちのいずれか一項に記載の方法を実行するように構成されている、コンピュータプログラム。

Images