JP6388583B2 - インターネットサイトのプラットホームへの接続データの処理システム - Google Patents

Description

本発明は、電子商取引のためのユーザデータを解析する分野に関する。
より具体的には、インターネットサイトのプラットホームへの接続データを処理するためのシステムに関し、該処理は、特に、統計処理、データマイニング、意思決定ツールの設計、診断、予測若しくは見積もり、シミュレータ、自動学習若しくは学習支援システムの設計を目的とする方法、並びに、一般に、状況分析システム若しくは状況分析の設計を目的とするものである。

インターネットの発達は、オンライン取引、又は、電子商取引の増加を引きおこした。製品販売、ユーザの接続、銀行または出版を含む多くのサービスがネットワーク上で提案されている。
その結果、電子商取引は、特に電子マーケティングにおいて、電子ビジネスの発生をもたらし、すなわち、取引を行うため、そしてその上、顧客の忠誠を確保するために、上流で実行可能である全てのものをもたらした。

実際には、オンライン販売は、理論的には、顧客との関係で極端には個人向けとすることが可能であるが、広く行き渡ったインターネットの匿名性は、顧客の絞り込みや差別化に基づいた従来のマーケティングのルールの適用を妨げる。
従って、インターネットのユーザを理解することは不可欠である。電子商取引の関係者には、まさに店舗販売者が行うように、彼らの顧客に対し個人向けのアプローチを提供するために顧客をより良く識別するべく、顧客がプロフィールを記入することを提案しているものがいる。しかしこの解決策は、個人情報の公表をしばしば控えるインターネットのユーザには限定的である。

公知の技術は、より良くインターネットユーザを識別し、そして彼が受け取る情報、特に広告を、個人向けにするために、例えばインターネットユーザの履歴の内容により、インターネットユーザの行動データを収集することを提案している。しかしながら、これらの技術は、インターネットユーザの部分的な理解のみを与え、最小の情報のみを引き出す。
本発明は、モデルや、物理的又は論理的な実施構成に依存せずに、新しい構成により、インターネットサイトのプラットホームに接続されたユーザの状況を判定し、そしてその上、データを得て他の状況を予測するべくそれらを解析するために、データの接続を処理するための代替システムを提案する。

本発明は、インターネットサイトのプラットホームへの接続データを処理するためのシステムを提案し、該システムは、
−接続データを処理するための少なくとも２つの別々のモジュールであって、モジュールは少なくとも２つの相補的なグループに分散され、１つのグループのモジュールは、ユーザの状況の識別を含む、装置によりプラットホームへのユーザの接続データを処理するための方法を実行するために要求される作業のサブセットを実行するように構成され、接続データを処理するための方法全体を完了するために各グループの処理モジュールは他のグループの処理モジュールからデータを受け取る、処理モジュールと、
−前記接続データを受け取り、それらを処理モジュールに送信する分配モジュールと、
−処理モジュールからデータを収集し、処理された接続データを前記プラットホーム及び／又はユーザの装置に出力する調整モジュールと、
を備えることを特徴とする。

他の有利な、そして、非限定的な本発明の特徴によれば、
・異なるモジュールは、ＸＭＬフローの形式でデータを交換し、
・一のグループの処理モジュールは、ユーザの状況を識別するように構成された前処理モジュールであり、他のグループの処理モジュールは、接続されているユーザの識別された状況を処理するように構成された後処理モジュールであり、
・前処理モジュールは、状況の識別に影響を与えるために、後処理モジュールから生じたデータを収集し、
・各グループの処理モジュールは、特にインターネットサイトのページを閲覧しているユーザのために、１つ以上の特定のサービスのライン（系列）に関連する処理手順を実行し、
・処理モジュールは、実行可能な状況エンジンのライブラリ、及び／又は、インターネットサイトの特徴的なオントロジーを含むデータベースに接続されている。

本発明の他の特徴及び利点は、以下の好ましい実施形態の説明により明らかになる。この説明は、以下の添付図面を参照しながら与えられる。
本発明が適用されたネットワーク構成の図である。 本発明に係る接続データを処理するための方法のステップを概略的に示す図である。 本発明に係る接続データを処理するためのシステムの実施形態の図である。 本発明に係る接続データを処理するためのシステムの処理モジュールを示している。 本発明に係る接続データを処理するためのシステムの実施形態の中間処理モールの図である。 本発明に係る接続テータを処理するためのシステムの実施形態の繰り延べモジュールの図である。

全ての公知の処理と比べ、データ処理方法は、前述したように完全な状況の解析に基づいており、パラメータの単純なリストに基づいてはいない。
本明細書の全体にわたって、前述した電子商取引の分野への方法の適用（この場合、データはインターネットサイトのプラットホームへの接続データ、すなわちプラットホームへの接続に関するデータである）について特に記述されるが、ワークステーションでの一般的なユーザデータの処理に置き換え可能であることは明確である。実際には、データは、ユーザの電子メールや、彼のシステムのパラメータ等であってもよい。接続データの処理は、そのようなデータの容量及び多様性のために、状況の識別について優れた結果を与える。

ここで、ユーザの状況とは、心理学上、社会学上のユーザの状態及びユーザの状況のシーン（場面（関連する他のユーザの全ての状況））を記述する、多かれ少なかれ複雑で且つ多かれ少なかれ曖昧な情報である。状況は、電子商人にとって意味がある言葉、例えば、先入観無しに昼食後にインターネットサーフィンを行う女性を指すための「午後の探索者（ａｆｔｅｒｎｏｏｎ ｆｏｒａｇｅｒ）」、によって呼称可能である。

状況分析は、解析、予想及びシミュレーションのためにツールを使用することによって、広い観点を多くの経済分野に開放する。状況の解析（例えばフランス特許出願ＦＲ２０６２８３参照）は、入力として１つ以上の状況のフローを受け取り、それから状況を引き出し、重要な要素を識別して処理を連続的に適用し、特に帰納法によって、現象を検出して解決策の発展を提供することが自発的に可能である。

多くの利点があり、以下でわかるように、状況のシステムは、モデルや実施構成によって限定されることはなく、そしてそれ故、永久的に適合する。人間の脳のように、それらは、それらのリソースを管理することによって、本質的要素に集中することができる。最後に、それらの可能性は、特定の分野に限られた現在の専門的なシステムの可能性よりも、はるかに普遍的であるように思われる。

本発明に係るデータ処理方法（処理は、少なくとも１つのデータ処理ユニット及びデータ記憶手段を備えるサーバによって実行され、サーバは、インターネットサイトのプラットホームへの接続データを処理する場合、前記プラットホームとネットワーク接続されている）の原理は、一人以上のユーザの状況を第１機構によって識別することであり、それから、その後収集された状況を第２機構によって処理することである。電子商取引の場合、関連するユーザは、装置により前記プラットホームに接続されているユーザであり、あるいは、サーバのリソースが許すならば全てのインターネット訪問ユーザである（以下参照）。

この処理は、また後で説明するように、数人の受取人及び多くの目的を有することができる。
図１は、発明が実行されるネットワーク構成を示している。装置３（これは、ワークステーションからスマートフォンやタッチタブレットのようなモバイル端末まで、それによってインターネットにアクセス可能なあらゆる種類のコンピュータ装置であり得る）は、インターネットのネットワーク４を通じて、インターネットサイトのプラットホーム２に接続されている。サーバ１は、方法を実行するために、少なくとも１つのデータ処理ユニット及びデータ記憶手段を備え、前記プラットホーム２とネットワーク接続されている。

プラットホームという用語は、インターネットサイトのページを提供している、インターネットサイトの１つ以上の相互に接続されたサーバを指す。インターネットサイトのページは、ユーザが現在探しているものである。処理を指揮するサーバ１は、プラットホーム２を構成するこれらのサーバのうちの１つであり得る。装置ユーザ３は、全てのケースにおいて、方法を実行しているサーバ１に、インターネットネットワークを介して、直接的又は間接的に（プラットホーム２を通じて）接続される。処理サーバ１とプラットホーム２との間の接続はローカルであり得るが、しかし代わりに、それがインターネットネットワーク４を通過することは禁止されていないことに留意すべきである。

第１機構：状況の識別
図２によって示されているように、前記プラットホームに接続されているユーザの状況の識別は、インターネットユーザの行動の観測から事前に定義可能であるか、又は、後述する他の機構によって特に有利には自動的に生成可能である基準状況のリストに基づいて行われる。
これを起こさせるために、本発明に係る方法の状況識別機構はトリガーを利用する。トリガーは、所定のイベントに応じて起動させられて処理を開始する、ソフトウェアモジュールである。

トリガーは多様であり得る。第１タイプでは、イベントは、参照クリック（コンサルテーションクリック：ｃｏｎｓｕｌｔａｔｉｏｎ ｃｌｉｃｋ）や選択クリック（セレクションクリック：ｓｅｌｅｃｔｉｏｎ ｃｌｉｃｋ）等のようなインターネットユーザの行動である。第２タイプでは、イベントは、例えばインターネットユーザの最後の訪問後、又は、トリガーの起動前に対する期限の満了である（後者では、固定された頻度で、例えば１時間毎に、それは起動される）。他にも多くの構成が可能であることは明確である。

特定のトリガーの起動において、サーバ１のデータ処理手段は、少なくとも１つの指標の状態の決定のための試みを始動させる。指標は、状況にとって重要な種々の要素である。幾つかの指標は、状況のシーン、すなわち、同時に起こっている接続されたインターネットユーザの状況の集合又は部分集合、に関連する。これは例えば、時間、天気予報等であり得る。代わりに、幾つかの指標は、状況のスフェア（状況の範囲：ｓｉｔｕａｔｉｏｎａｌ ｓｐｈｅｒｅ）、すなわち、インターネットユーザの特定の状況、に関連する。これは、例えば、インターネットユーザの年齢、種類及び身長、彼のウェブサイト間の移動（速いか、ためらいがちであるか等）、彼の状態（急いでいるか、探しているか等）である。それ故、指標は、プラットホーム２に接続されたユーザの個人データ及び／又は一般的なデータに関連する。これら２つの状況のエリア（領域）の組み合わせは、ユーザの状況の決定に関し良い結果を実際に与える。

当然ながら、特に状況の分析を考慮して、好ましい結果（例えば、取引の結論か否か）に関連する幾つかの指標が特に含まれる。
サーバ１の処理ユニットは、観測可能な指標の所定のコレクションを有する。観測可能というのは、決定可能であるということを必ずしも意味しないことに留意すべきである。指標の状態を決定することは無益である。例えば、インターネットユーザの年齢は、必ずしも入手可能とは限らない。その場合、指標は識別できないと考えられる。しかしながら、後の試み（同じトリガー又は他のトリガーによる）で今回成功することは、不可能ではない。

決定しようとする指標のリストは、各トリガーと関連付けられている。もしこのトリガーが作動させられると、観測される状態の指標は、これら指標及びこれら指標のみである。例えば、周期的なトリガーは、天気予報、又は、ユーザの１秒毎のクリック数を決定しようとすることができる。代わりに、フォームの終わりに送信ボタンをクリックすることに関連付けられたトリガーは、入力した文書に応じてユーザの年齢やジャンルを決定しようとすることができる。

少なくとも１つの指標の状態を決定する前記試みの結果に応じて、処理ユニットはユーザの状況のシグネチャー（状況の特徴：ｓｉｔｕａｔｉｏｎａｌ ｓｉｇｎａｔｕｒｅ）を生成し、サーバ１の記憶手段に格納する（もし、状況の状況がすでに存在すれば、それはアップデートされるのみである）。
ユーザの状況のシグネチャーは、ユーザの状況を特徴付ける指標に関連する全てのデータに対応する。

有利には、状況のシグネチャーは、複数の情報ユニットを特に有し、それぞれ指標と関連付けられ（状況のシグネチャーには２つの部分が存在し、ユニットはそれぞれ、関連する指標が状況のシーンに関連する場合には「スレッショルド」と呼ばれ、もし関連する指標が状況のスフェアに関連する場合には「トラッカー」と呼ばれる。）、各情報ユニットは、関連する指標の決定された状態が基準状態に対応する場合の第１の値（値が１）、関連する指標の決定された状態が基準状態に対応しない場合の第２の値（値が０）、及び、関連する指標の状態を決定できない場合（関連する指標のために決定において試みが行われなかったか、又は、トリガーの設定後の試みが失敗した）の第３の値（値がＸ）を含む、少なくとも３つの値をとることができる。

０，１及びＸという表記は、単に例示にすぎず、当業者であれば、その選択によりデータの表現を選択可能であることは明らかである。特に、決定された値の数を有さない情報ユニットを使用可能であり、例えば特徴のチェーン（ｃｈａｒａｃｔｅｒ ｃｈａｉｎ）等、数を記憶することが可能である。しかしながら、ｎ個の状態を有する情報ユニットを有することの利益が後に説明される。以前定義された表記の使用として、１Ｘ１０ ０１ＸＸは、８つの情報ユニットを有する状況のシグネチャーの例である。

また、決定が試みられなかったことと、決定が試みられたが不成功であったこととは、ここでは区別されず（同一の値Ｘ）、代わりに、決定が試みられたことに対応する情報が考慮されることにも留意すべきである。実際、指標の状態を構成する情報が得られなかったけれども、試みが失敗したという事実は重要であり得る。例えば、これはユーザが自発的（あるいは非自発的であっても）に、彼のプロフィールの一部を隠したことを意味し、そしてそれ故、それは誰かが彼のインターネットの秘密性を増大しようとしている可能性を意味している。

幾つかのトラッカー又はスレッショルドは、後者に長続きする特性を与えるために、例えばガウスやポアソンの分布法則の積分器に基づいている。言い換えれば、積分器は、短時間前に先行する観測が発生したときの決定における試みを再度始動する必要を短期的に避けながら、先行する観測に応じて指標が有していなければならない状態を提供する。

ユーザの状況のシグネチャーは、複数のマスクと比較される。各マスクは、基準状況と関連付けられ、状況のスフェアの広さと対応している。このため、各マスクは、情報ユニットがどれでもあり得るならば、シグネチャーとして、０，１，Ｘの値、また第４の値（Ａと示される）、をとり得る複数の情報ユニットを備えている。
例えば、１０Ａ０ ＡＡＸ１は、８つの情報ユニットを有するマスクであり、以下のシグネチャー： １０００ ００Ｘ１， １０００ ０１Ｘ１， １０００ ０ＸＸ１， １０００ １０Ｘ１， １０００ １１Ｘ１， １０００ １ＸＸ１， １０００ Ｘ０Ｘ１， １０００ Ｘ１Ｘ１， １０００ ＸＸＸ１， １０１０ ００Ｘ１， １０１０ ０１Ｘ１， １０００ ０ＸＸ１， １０１０ １０Ｘ１， １０１０ １１Ｘ１， １０１０ １ＸＸ１， １０１０ Ｘ０Ｘ１， １０１０ Ｘ１Ｘ１， １０１０ ＸＸＸ１， １０Ｘ０ ００Ｘ１， １０Ｘ０ ０１Ｘ１， １０Ｘ０ ０ＸＸ１， １０Ｘ０ １０Ｘ１， １０Ｘ０ １１Ｘ１， １０Ｘ０ １ＸＸ１， １０Ｘ０ Ｘ０Ｘ１， １０Ｘ０ Ｘ１Ｘ１， １０Ｘ０ ＸＸＸ１を組み合わせている。

シグネチャーとマスクの比較は、論理ゲートによって容易に行われる（Ａという値を有さないマスクの各ユニットは、シグネチャーの対応するユニットと、ＸＯＲ（排他的論理和）によって比較され、そして、ＡＮＤ（論理積）がこれらの結果に適用される）。マスクが対応するとき、プラットホーム２に接続されたユーザの状況が、前記状況のシグネチャーを含む少なくとも１つのマスクと関連付けられた基準状況であると同定される。

有利には、複数のマスクは、サーバ１の記憶手段に格納され、幾つかのマスクでは、重なり合う範囲を有することは不可能ではなく、換言すれば、特定の状況に対応するマスクの一意性は無いことに留意すべきである。この困難を解決するために、有利には、マスクは、回転に応じて繰り返しテストされる。テストが肯定的であれば、マスクに関連付けられた基準状況は保持され、肯定的でなければ、次のマスクがテストされる。新しいトリガーが作動させられると、可能であれば、現在の状況の安定性を維持するために、同じ状況のマスクが最初に再テストされる。
従って、この方法の第１段階が完了すると、ユーザの状況として同定された状況が存在する。

第２機構：状況の処理
本発明に係る方法の第２機構は、ユーザや、インターネットサイトの管理者等にとって重要な処理されたデータを得るために、サーバ１の物理的又は論理的な状況分析手段による、ユーザの同定された状況の分析からなる。状況分析手段は、サーバ１のデータ処理手段（これは、以下に述べるように、コアがこの状況分析用であるマルチコアプロセッサであり得る）によって実行されるアプリケーションからなることができる。

このために、各基準状況は、少なくとも１つのストラテジー（有利には１〜３）、すなわち、セットと関連付けられ、セットは、１つ以上の状況エンジン（及びこれらエンジンの任意のパラメータ）、並びに、メッセージの内容、すなわち、文章、グラフィックコンテンツ（画像やビデオ等を含む）、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｅｒ）のリンク、フォーム要素（形式、フォントパラメータ等）、及び、メッセージを個人向けにするために有用な他のデータ、を備えている。メッセージ（推奨とも称される）は、接続データの処理から生じる任意の形式のコミュニケーションを意味し、状況に対し予想される効果を有する。

通常の表現では、これらは、サイトの管理者への報告メッセージ（例えば電子メールの形式）であり得るが、特に、状況が処理されたユーザに向けられたメッセージであり得る。例えば、これは、調べられているインターネットのページ、電子メール、ＳＭＳ等で表示されるバナーであり得る。

状況エンジンは、状況エンジンのライブラリから選択されたソフトウェア要素である。各状況エンジンは、状況に対し予想される効果を有する１つ以上のメッセージを得るために、ユーザの状況について特定の処理を実行可能である（エンジンは、シーン及び状況のスフェアの全体のパラメータを考慮し、実際に、ユーザの状況のシグネチャーが一意であれば、同定された状況はそうではない。情報ユニット、すなわち観測された指標の状態、を考慮することは、処理を個人向けにする）。

エンジンの第１の例は、訪問者に対する１つ以上の製品の推奨を採用可能である（店舗の状況に向けられている）。エンジンの第２の例は、（個人レベルで）ユーザの同定された状況に類似した状況で、インターネットユーザによって購入された製品の推奨を採用可能である。エンジンの第３の例では、流行製品（グループ社会学のレベルでの売り上げの有意な増加の検出）が単純に推奨され得る。

同じストラテジーは幾つかの状況に関連付け可能であり、各ストラテジーは、不可欠性のレベル、すなわち、多くのユーザが殺到した場合の優先度の基準、を取り扱うことが可能であることに留意すべきである。
上記同定された状況（不可欠性の順序によって分析可能である）に関連付けられた少なくとも１つのストラテジーとして、サーバ１の処理手段は、少なくとも一群のメッセージを得るために、関連付けられた状況エンジンを作動させる。有利には、少なくとも２つの群（有利には３つ）が生成され、それぞれ秘密性のレベルが関連付けられる。秘密性のレベルとは、メッセージの周知性である。例えば、２つの秘密性のレベルを伴う方法の実行では、レベル１は個人的なメッセージに対応し、レベル２は世界的なメッセージ（例えばサイト上のバナー）に対応する。前述したエンジンの３つの例は、３つの異なる秘密性のレベルに対応しており、任意のユーザ向けであるために、第１は秘密性の低レベルを示し、推奨は個人向けであってそのユーザだけのためであるため、第２は秘密性の高レベルを示す。第３は、グループのレベルで見せられるので、秘密性の平均レベルを示している。従って、これら３つのエンジンによって生成された３つの推奨は、３つの異なる群の中に見出される。

それから、これらメッセージの群は、メッセージを見せるために、すなわち、それらをそれらの受取人に送るために崩される。より正確には、これは、少なくとも一群のメッセージの部分集合を、ユーザの装置３及び／又はプラットホーム２（ページ要素であるとき）に送ること（適切に）からなる。
これは、ＬＩＦＯ（後入れ先出し）の単純な方針によって行われ得るが、有利にはいわゆるトークンストラテジーが使用される。このストラテジーでは、現在のページは、特定の形式で特定のパラメータを有するメッセージを受け取り可能な表示領域を有する。該領域は、利用可能であるとき、領域の異なるパラメータを有するトークンを送る。状況エンジンはトークンを受け取り、これらのパラメータに応じて命令で１つ以上のメッセージを構成する。トークンを有するメッセージは、他よりも前に群から取り出される。

メッセージを見せることは状況に影響を与え（例えば、それがユーザに対し予想された影響を有していれば取引を引き起こすことにより）、これは、新しいトリガーを作動させ、そして、ユーザがいる状況に変化を生じさせる機会を有するものである。方法は、再スタートされ、メッセージの効果は次の分析サイクルにおいて観測される。

処理容量の最適化
インターネットユーザの活動は、一日を通して一定ではなく、そして特にピーク時には、サーバ１のデータ処理手段は、情報の流入量（言い換えれば、処理すべき流れの量）に直面して困難に遭遇し得る。
有利には、システムは、これらトラフィックの変化量を考慮して方法を規制する。特に、方法は、有利には接続された全てのユーザの状況を同定するために必要なリソースを結集するが（方法の第１の部分は、第２よりも少ないリソースを消費する）、利用可能な容量に応じて、先に述べたように特に不可欠性のレベルに応じて分類された、一部のみを分析する。

このために、低級のモードにシフトする動作（スレッショルドを超える幾つかの状況が中止される）や、延期される動作（興味を引き起こしているとみなされる幾つかの状況は、混雑のためにすぐには扱われないが、活動が低下したときに後で扱われる）をともなう、３つの漸進的な活動のレベル（ここでは、α段階、β段階、及びγ段階と呼ばれる）が規定される。また状況分析の指定は、活動のレベルの関数として変化可能であり、もしリソースが不十分であれば、不可欠なものが処理され（不可欠性演繹的モード）、そしてそうでなければ、より多くの反射がある、正確な分析が行われる（不可欠性帰納的演算モード）。半監視モード又は非監視モード（以下参照）では、利用可能であれば学習するリソースが好ましい。

３つの上記レベルは、秒当たりの動作の数での、サイトでの活動の代表的なレベルの関数として定義される。
α段階は、活動の高レベルに対応する。例えば、これは１０００までの同時接続を有するサイトであり、１人のユーザが平均で１０秒毎に１回クリック（又は入力のような他の動作）をしたと仮定したときに、α段階は１００Ｈｚである。
β段階は、活動の平均レベルに対応する。例えば、同一のサイトに１日当たり１００００００の接続があり、インターネットユーザが平均で１分３０秒滞在するときに、β段階は１０．４Ｈｚである。
γ段階は、活動の低レベルに対応する。例えば、１日の最大の同時接続と最小の同時接続との間で、サイトが１から１００の比率を有するときに（または最低限、１クリック毎に９秒で１０の同時接続）、γ段階は１．１１Ｈｚである。
逆の場合（必要とするよりも利用可能な処理容量が多い）、方法は、影を使用可能であり、すなわち、学習の基礎を増やすために前のユーザの存在する状況を保持可能である。

半監視及び非監視モード
方法は、機能を果たすために基準状況のセットを必要とするが、このセットは固定されず発展可能である。特に、ストラテジーは、特に新しい状況の出現をサイトの管理者に指摘するために、メッセージを送ることができるように構成された状況エンジンを含むことができる。
半監視モードでは、システムは、（状況エンジンによって予め決定されたマスクに関連付けられた）新しい基準状況を管理者に示唆し、後者は、これら提案を有効又は無効にすることができる。代わりに、（図２に示されたような）非監視モードでは、システムは完全に自動であり、新しい基準状況を取り入れる。

新しい状況の出現は、芽を出すことによって観測されることに留意すべきである。換言すれば、エンジンが検出するのは、より大きな状況のサブカテゴリーである（例えば、１つの基準状況に対応するかなりの数の状況のスフェアが、Ａとして分類される指標、すなわちマスクで説明されない指標、のための同一の状態を表していれば）。代わりに、特定の基準状況のために、試みにおいて、有効なメッセージを検出するために取引において完了したそれらの状況を選択可能である。

反射処理装置
第２態様によれば、発明はシステム１、特に少なくとも１つのデータ処理ユニットとデータ記憶手段を備えるサーバ１、に関する。前記少なくとも１つの演算処理ユニットは、装置３を通じてサイトのプラットホーム２にユーザが接続している間に第１態様に係る方法を実行するように構成されている。
説明したように、方法は、プラットホーム２を構成するサーバ（すなわち、サーバはサイトのページを運営し、サイトの動作を管理する）とは異なる、サイトのサーバによって最も頻繁に実行され、ユーザの装置３は、プラットホーム２を介して方法を実行するために前記サーバに接続される。

特に好ましくは、発明の第２態様は、インターネットサイトのプラットホーム２への接続データを処理するためのサーバ１に関し、その特に好ましい実施形態は図３に示されている。このシステムは、
−接続データを処理するための少なくとも２つの独立した接続データ処理モジュール２１，２２（ＳＡＬＩ２モジュール、ＳＡＬＩＸ及びＳＡＬＩＣはそれの２つのバージョン）であって、処理モジュール２１，２２は少なくとも２つの相補的なグループに分散され、１つのグループのモジュール２１，２２は、ユーザの状況の識別を含む、プラットホーム２へのユーザの接続データを処理するための方法を実行するために要求される作業のサブセットを実行するように構成され、接続データを処理するための方法全体を完了するために各グループの処理モジュール２１は他のグループの処理モジュール２２からデータを受け取る、接続データ処理モジュールと、
−前記接続データを受け取り、それらを処理モジュール２１，２２に送信する分配モジュール１０（ＲＥＮＺＯ）と、
−処理モジュール２１，２２から来るデータを収集し、処理された接続データを前記プラットホーム２に送る調整モジュール３０（ＲＥＮＡＬＤＯ）と、
を備える。

これらモジュール１０，２１，２２，３０は、入力データを先験無しで処理する能力のために、反射処理装置と称される。
従って、原理は、ｎ個のモジュール２１，２２の２つ（又はそれ以上）のグループを有することであり、１つのグループのモジュール２１，２２は同一の作業を並行して実行し、各グループの作業は接続データを処理するために相補的である。異なるモジュール２１，２２は、それぞれその処理手段及びその記憶スペースを有する、物理的に独立した（そしてバスによって接続された）処理装置であるか、又は、代わりに、モジュールが同一の処理装置（任意にはマルチコア）及び同一の記憶スペースを共有しながら、特定の装置で実行されるソフトウェアである。システム１は、幾つかのサーバに分配可能であり、又は、仮想マシンのクラウドコンピューティングにさえもインストール可能である。モジュール２１，２２は、有利には、抽象言語、例えば、ＸＭＬ（拡張可能なマーク付け言語）、ＪＳＯＮ（ジャバスクリプトオブジェクト表記）、ＳＯＡＰ（シンプルオブジェクトアクセスプロトコル）、シルビアまたはマーベリックプロトコル、のフローの形式でデータを交換していることに留意すべきである。

図４を参照すると、これは、ＳＡＬＩ２型の（グループから独立している）処理モジュール２１，２２を概略的に示している。明らかなように、それは、７つの入力／出力ポートを有する。先に説明したように、実際には、処理モジュール２１，２２は、実行可能な状況エンジンのライブラリ、及び／又は、インターネットサイトの特徴的なオントロジーを含むデータベースに接続されているのが好ましい。
特に、
−ＯＢＳポート（オブザーバ）は、プラットホーム２から生じたデータをＸＭＬフローの形式で受け取り、
−ＣＯＬポート（コレクタ）は、他の処理モジュール２１，２２、ＳＡＬＩ２から来るデータをＸＭＬフローの形式で受け取り、
−ＯＮＴポート（オントロジー）は、ＸＭＬファイルの形式でオントロジーを受け取り、
−ＬＩＢポート（ライブラリ）は、トラッカー、スレッショルド、及び状況エンジン（実行可能）のライブラリを含み、
−ＥＤＩポート（エディタ）は、ＸＭＬフローの形式でデータを出力し、
−ＤＩＦポート（ディフューザ）は、ＸＭＬフローの形式で他のグループの処理モジュール２１，２２にデータを送り、
−ＭＯＮポート（モニタリング）は統計値を送る。

モジュール２１，２２のグループの間でのタスクの分配は、モジュール２１，２２の専門化によって、より大きな処理効率を可能にし、そして、図３から明らかなように、各グループにデータが供給されるという事実はフィードバックを保証している。処理の一部の結果は、処理の他の部分を改良する。処理モジュール２１，２２のグループ間での可能な分配の幾つかのキーについては後述する。システム１が、第１の法則に従って分散された、モジュール２１，２２の２つのグループを有することができ、１つのグループのモジュール２１，２２が、第２の法則に従って２つのサブグループに分散される、これらのアプローチを組み合わせ可能であることに留意すべきである。

分類作業は、情報の各パケットを解釈し、そして、それを適当なモジュール２１，２２に差し向ける、分配モジュール１０によって実行される。
調整モジュール３０は、完了した処理に応じて送信されるべきメッセージに関するフローを受け取り、これらメッセージの発表を取り扱う。それは、サイトのプラットホーム２及び／又はユーザの装置３への全てのフローを組み立て直す。

第１の変形によれば、処理モジュール２１は、プラットホーム２に接続されたユーザの状況を識別するように構成された前処理モジュールであり、他のグループの処理モジュール２２は、接続されたユーザの識別された状況を処理するように構成された後処理モジュールである。結果としての状況の処理及びメッセージの送信は、方法のリソースの大きな消費部分であるため、この特に有利な構成では、１つの前処理モジュール２１、及び、Ｎ個の後処理モジュール２２（特に４又は８、しかしこの数に限定されることはなく、他の数であり得ることが理解される）が有利には存在する。

図２に見られるように、フィードバックの接続は、状況の識別に影響を与えるために、前処理モジュール２１が１つ又は複数の後処理モジュール２２から来るデータを収集することを許可する。これは、先に述べた非監視モードを可能にする。

第２の変形では、１つのグループの処理モジュール２１は、リアルタイム動作を実行し（即時処理のモジュール）、そして、他のグループの処理モジュール２２は、延期された処理を実行する（繰り延べ処理のモジュール）。換言すれば、幾つかのモジュール２１は、即時の動作（例えばユーザの移動に接続されたトリガー、即時の表示をともなうメッセージの送信）を必要とする作業を実行し、その一方、他のモジュール２２は、その実行が時間を渡ってオフセットされる作業を実行する。データは、それらが処理され得るまで記憶手段に記憶される。この構成は、情報の持続性を促進するとともに、リアルタイムモジュール２１が、延期された処理に関するデータ（それ故、より古い接続データの利益）を受け取った時点の範囲で、過去について考慮すること（それ故、より古い接続データの利益）を促進する。フィードバックループは、繰り延べ処理モジュール２２を、処理グリッドの即時処理モジュール２１と通信させ、処理グリッドを介して即時処理が適応させられる。また、この構成は、即時処理から繰り延べ処理への転送データの流入のピーク時にも、よく適応する。

これは、図３に示されたシステムに関し、「ＳＡＬＩＸ」は、繰り延べ処理モジュール２２であり、そして、「ＳＡＬＩＣ」は、即時処理モジュール２１である。この特に有利な構成では、有利には、１つの繰り延べ処理モジュール２２、及び、Ｎ個の即時処理モジュール２１が存在する（即時処理は優先され、そして、いくつかの処理は延期することができないので大きな消費をするものである）。４個の即時処理モジュール２１を有する構成では、合計で７つのモジュール１０，２１，２２，３０があり、それゆえオクタコアプロセッサが好ましい（８つのコアがシステム動作の残りを管理する）。

図５及び図６は、ＳＡＬＩＣ型の即時処理モジュール２１及びＳＡＬＩＸ型の繰り延べ処理モジュール２２をより詳細にそれぞれ示している。これらの構成は、ＯＢＳ、ＣＯＬＬ、ＥＤＩ及びＤＩＦポートを示している（ＯＮＴ、ＬＩＢ及びＭＯＮポートは、２つのモジュールの型の間で同様に結線される。
即時処理モジュール２１であるＳＡＬＩＣは、オブザーバポートによって受け取った、コンサルテーション、セレクション及びコンサンプションベクトル（指標の状態を決定するために観測されたデータを有する）によって、全てのユーザの状況の識別を取り扱う。
ディフューザポートは、繰り延べ処理モジュール２２であるＳＡＬＩＸにベクトルを送信する。コレクタポートは、延期されるように処理された情報ベクトル、及び、繰り延べ処理モジュール２２であるＳＡＬＩＸからきたグリッドを受け取る。

トラッカー（及びスレッショルド）は、ベクトル及びグリッドから状況のシグネチャーを生成する。識別された状況に関連付けられたリアルタイム状況エンジンが実行され、そして、エディタポートからエンジンの実行によって生成されたメッセージが送られる。
繰り延べ処理モジュール２２であるＳＡＬＩＸは、即座に行われる必要がない処理を取り扱う。オブザーバポートは、サービス及び管理ユーザに関するデータを専ら受け取る。コレクタポートは、即時処理モジュール２１であるＳＡＬＩＣから来るベクトルを受け取る。状況エンジンは、タイマー（Ｔｉｍｅｒ）によって実行させられ、且つ、制御され、タイマーは処理が延期される時点を規定する。

これらエンジンは、延期されたメッセージ（例えばサイトを再度訪問することを勧めるための販促用電子メールのかたちで、訪問から数時間で送られる、ユーザに行くメッセージ）、及び、十分な支援のためにエディタポートを通じて送られるサイトの管理者のためのメッセージ、及び、説明したように、ディフューザポートを通じて即時処理モジュール２１であるＳＡＬＩＣに（幾つかのベクトルとともに）送り戻される処理グリッドも、生成する。

第３の変形によれば、モジュール２１，２２の各グループは、サービスのラインに対応する。これは、ライン／サービス／オプションのためのＬＳＯと呼ばれる、システム内におけるインターネットサイト内の製品分類基礎ユニットである。サービスのラインは、幾つかのサービスを組み合わせる。例えば、サロンというカテゴリーは、テーブル、ＴＶ家具、カウチ等を組み合わせる。同様に、男性、又は、ＸＬサイズというカテゴリーは、衣類のカタログのサービスのラインである。商業サイトのようなインターネットサイトでは、異なるサービスのラインが存在するいくつかの分類モードの下で、同じ製品を紹介可能である。各サービスはオプションを有している。先の例では、男性というラインのパンツというサービスは、パンツの同じ型のオプションのリストを含んでいるであろう。各オプションは、幾つかの変形（サイズ、色等）を伴う製品を示し、各製品は、オプションとは対照的に、実際には唯一のものである（特定のカタログを参照）。従って、同じ製品が、幾つかのＬＳＯの組み合わせで紹介可能である。この例を再び参照すると、同じパンツは、ＸＬというラインの男性用パンツというサービスに見出すことができる。

特に、ユーザの状況が大きく異なるであろう広い範囲の商品を有するサイトのために、サービスのラインによって、処理モジュール２１，２２を分離することは実行可能である。彼が移動しているサービスのラインに従って、プラットホーム２の１つ又は他のサーバにリダイレクトされる大きなサイトに適していることに留意すべきである。

また、有利には、これらの変形の幾つかは組み合わせられる。特に、第２の変形の即時処理モジュール２１であるＳＡＬＩＣは、それぞれ１つ以上のサービスのラインに専念することができる。この場合、分配モジュール１０であるＲＥＮＺＯは、それが位置しているサービスのラインに応じて、管理データがあれば繰り延べ処理モジュール２２であるＳＡＬＩＸに、又は、ユーザからの移動データがあれば即時処理モジュール２１であるＳＡＬＩＣに、流入するフローを向かわせることによって、流入するフローを分配する。

Claims (5)

1. インターネットのサイトのプラットホーム（２）への接続データを処理するためのシステム（１）において、
   −接続データを処理するための少なくとも２つの別々の接続データ処理モジュール（２１，２２）であって、処理モジュール（２１，２２）は少なくとも２つの相補的なグループに分散され、１つのグループのモジュール（２１，２２）は、ユーザの状況の識別を含む、装置（３）を通じたプラットホーム（２）へのユーザの接続データを処理するための方法を実行するために要求される作業のサブセットを実行するように構成され、接続データを処理するための方法全体を完了するために各グループの処理モジュール（２１，２２）は他のグループの処理モジュール（２１，２２）からデータを受け取る、接続データ処理モジュール（２１，２２）と、
   −前記接続データを受け取り、それを処理モジュール（２１，２２）に送信する分配モジュール（１０）と、
   −処理モジュール（２１，２２）から来るデータを収集し、処理された接続データを前記プラットホーム（２）及び／又は前記装置（３）に出力する調整モジュール（３０）と、
   を備え、
   一のグループの処理モジュール（２１）は、前記プラットホーム（２）に接続されたユーザの状況を識別するように構成された前処理モジュールであり、そして、
   他のグループの処理モジュール（２２）は、接続されたユーザの識別された状況を処理するように構成された後処理モジュールであり、
   前処理モジュール（２１）は、状況の識別に影響を及ぼすために後処理モジュール（２）から生じたデータを収集することを特徴とするシステム。
2. ＸＭＬ（拡張可能なマーク付け言語）、ＪＳＯＮ（ジャバスクリプトオブジェクト表記）又はシルビアのフローの形式で、異なるモジュール（２１，２２）がデータを交換する
   ことを特徴とする請求項１に記載のシステム。
3. 一のグループの処理モジュール（２１）はリアルタイムで作業を行い、そして、他のグループのモジュール（２２）は延期された作業を行う
   ことを特徴とする請求項１又は２に記載のシステム。
4. 各グループの処理モジュール（２１，２２）は、特に、１つ以上の特定のサービスのラインに関連するインターネットのサイトのページを閲覧しているユーザのために、処理方法を実行する
   ことを特徴とする請求項１乃至３の何れか１項に記載のシステム。
5. 処理モジュール（２１，２２）は、実行可能な状況エンジンのライブラリ、及び／又は、前記インターネットのサイトの特徴的なオントロジーを含むデータベースに接続されている
   ことを特徴とする請求項１乃至４の何れか１項に記載のシステム。