(57)【要約】      （修正有）【課題】インターネットサイトのプラットフォームに接続したユーザの状況を分析し、他の状況を予測するデータマイニングのための代替システムを提供する。【解決手段】サーバによるインターネットサイトのプラットフォームへの接続データを処理する方法は、機器を介してプラットフォームに接続されたユーザの状況を、参照状況のリストの中から特定する。参照状況は戦略と関連付けられており、戦略は状況モータのライブラリから選択される状況モータを含み、状況モータは、ユーザの状況に応じて、所期の効果を有するメッセージを取得する。特定された状況に関連付けられた戦略は、状況における戦略の状況モータがサーバのデータ処理手段によってメッセージを取得し、メッセージのスタックのサブセットをユーザの機器及び／又はプラットフォームに送信する。【選択図】図２
2019036344.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのデータ処理装置及びデータ保存手段を含むサーバ（１）によってインターネットサイトのプラットフォーム（２）への接続データを処理する方法であって、
（ａ）機器（３）を介して前記プラットフォーム（２）に接続されたユーザの状況を、参照状況のリストの中から特定するステップであって、
前記参照状況の各々は、少なくとも１つの戦略と関連付けられており、
前記戦略の各々は、状況モータのライブラリから選択される１以上の状況モータを含み、
前記状況モータの各々は、ユーザの状況に応じて、その状況において所期の効果を有するメッセージを取得するように所定の処理を実行可能である
ステップと、
（ｂ）特定された前記状況に関連付けられた前記戦略の少なくとも１つについて、前記状況における前記戦略の前記状況モータが前記サーバ（１）の前記データ処理装置によって少なくとも１つのメッセージのスタックを取得するように前記処理を実行するステップと、
（ｃ）前記少なくとも１つのメッセージのスタックの前記メッセージのサブセットを前記ユーザの前記機器（３）及び／又は前記プラットフォーム（２）に送るステップと、
を備えることを特徴とするインターネットサイトのプラットフォームの接続データの処理方法。
【請求項２】
前記戦略の各々は重要性のレベルと関連付けられており、
前記戦略と関連付けられた前記状況モータの実行の順序は、前記戦略の前記重要性のレベルによって決まる
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ステップ（ｂ）では少なくとも２つのメッセージのスタックが取得され、
前記スタックの各々は機密性のレベルと関連付けられている
ことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記戦略の各々は、さらにテキスト及び／又はＵＲＬリンク及び／又は画像のリストと関連づけられており、
前記戦略の前記状況モータによって生成される前記メッセージは、前記戦略の前記リストのテキスト及び／又はＵＲＬリンク及び／又は画像から構成される
ことを特徴とする請求項１乃至３の何れか一項に記載の方法。
【請求項５】
前記メッセージのスタックの少なくとも１つは、固定サイズの後入れ先出し（ＬＩＦＯ）スタックであり、最も古いメッセージは最新のメッセージに置換される
ことを特徴とする請求項１乃至４の何れか一項に記載の方法。
【請求項６】
前記メッセージのスタックの少なくとも１つは、トークンタイプのスタックであり、
前記プラットフォーム（２）は、メッセージが要求されたときに前記スタックのトークンを発信し、
トークンを受け取る前記メッセージは、最も古いメッセージに置換される
ことを特徴とする請求項１乃至４の何れか一項に記載の方法。
【請求項７】
前記インターネットサイトのページは、
所定のフォーマットにて所定のパラメータを有するメッセージを受け取ることが可能な少なくとも１つの公開領域を含み、
スタックのメッセージは、前記スタックから抽出される前記公開領域と互換性のあるパラメータ及びフォーマットを有し、前記公開領域が空いているときに前記プラットフォーム（２）に送信される
ことを特徴とする請求項５又は６に記載の方法。
【請求項８】
前記ステップ（ａ）では、ユーザの前記状況が、前記ユーザの状況シグネチャと複数のマスクとの比較により特定され、
前記マスクの各々は、前記参照状況の１つと関連付けられているとともに、状況シグネチャの空間と対応しており、
ユーザの前記状況シグネチャは、監視可能な指標であって、前記プラットフォーム（２）に接続された前記ユーザの個人データに対する及び／又は一般データに対する指標のセットを監視することにより取得される
ことを特徴とする請求項１乃至７の何れか一項に記載の方法。
【請求項９】
異なるマスクに対応する前記状況シグネチャの空間の幾つかは、前記ステップ（ｃ）において送られる幾つかのメッセージに応じて変更される
ことを特徴とする請求項８に記載の方法。
【請求項１０】
少なくとも１つのデータ処理装置及びデータ保存手段を備えるサーバ（１）であって、
前記少なくとも１つの処理装置は、ユーザが機器（３）を介してインターネットサイトのプラットフォーム（２）に接続されている間、請求項１乃至９の何れか一項に記載の方法を実行するように構成されており、
前記サーバ（１）は、前記プラットフォーム（２）と接続されている
ことを特徴とするサーバ（１）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ｅコマースに使用されるデータの分析の分野に関する。
より具体的には、本発明は、インターネットサイトのプラットフォームへの接続データを処理するためのシステムに関する。本発明に係る方法は、特に、データマイニング、意思決定ツールの設計、診断、予測又は概算、シミュレータの設計、自動学習又は学習支援システムに向けられたものであり、概して、状況分析システムの設計又は状況分析のための方法である。
【背景技術】
【０００２】
インターネットの発展により、オンラインコマースすなわちｅコマースが増加している。商品販売、ユーザ同士の結びつけ、銀行、又は出版等を含む多くのサービスがネットワーク上で提供されている。
特定の電子マーケティングにおいては、ｅコマースに続き、ｅビジネスが出現している。すなわち、上流側ですべてを実行して、取引を成立させて、顧客の忠誠を確かなものとするためのものである。
【０００３】
オンライン販売によって、顧客関係の究極の個別化が論理的には可能となるが、実際には、インターネットで広まっている匿名性によって、顧客のターゲティングや差別化に基づく従来のマーケティングルールを活用することが妨げられている。
したがって、インターネットユーザを理解することは重要である。ｅコマース業者の中には、顧客をより良く特定してその顧客に合った個別のアプローチを提供するために、店舗の販売員がそうしていたように、顧客に対してプロフィールを入力することを提案する業者もある。しかし、このような解決策は、個人情報を外部に提供することについて消極的なインターネットユーザにとっては制約となる場合がある。
【０００４】
既知の技術においては、インターネットユーザをより良く特定し、そのインターネットユーザが受け取るもの、特に広告を個別化するために、例えば、そのインターネットユーザの履歴の内容を介して、そのインターネットユーザに関する“行動データ”を収集することが提案されている。しかし、このような技術は、そのインターネットユーザの部分的な理解に役立つに過ぎず、最小限の情報しか引き出すことができない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、新規のアーキテクチャによって、モデル、又は、物理的若しくは論理的に実装された構造に依存せずに、インターネットサイトのプラットフォームに接続したユーザの状況を分析してデータを取得し、他の状況を予測するデータマイニングのためのデータ接続を処理するための代替のシステムを提供する。
【課題を解決するための手段】
【０００６】
本発明は、少なくとも１つのデータ処理装置及びデータ保存手段を含むサーバによってインターネットサイトのプラットフォームへの接続データを処理する方法であって、
（ａ）機器を介して前記プラットフォームに接続されたユーザの状況を、参照状況のリストの中から特定するステップであって、
前記参照状況の各々は、少なくとも１つの戦略と関連付けられており、
前記戦略の各々は、状況モータのライブラリから選択される１以上の状況モータを含み、
前記状況モータの各々は、ユーザの状況に応じて、その状況において所期の効果を有するメッセージを取得するように所定の処理を実行可能である
ステップと、
（ｂ）特定された前記状況に関連付けられた前記戦略の少なくとも１つについて、前記状況における前記戦略の前記状況モータが前記サーバ（１）の前記データ処理手段によって少なくとも１つのメッセージのスタックを取得するように前記処理を実行するステップと、
（ｃ）前記少なくとも１つのメッセージのスタックの前記メッセージのサブセットを前記ユーザの前記機器及び／又は前記プラットフォームに送るステップと、
を備えることを特徴とするインターネットサイトのプラットフォームの接続データの処理方法を提供する。
【０００７】
本発明の他の利点及び限定されない特徴によれば：
−  前記戦略の各々は重要性のレベルと関連付けられており、前記戦略と関連付けられた前記モータの実行の順序は、前記戦略の前記重要性のレベルによって決まる；
−  前記ステップ（ｂ）では少なくとも２つのメッセージのスタックが取得され、前記スタックの各々は機密性のレベルと関連付けられている；
−  前記戦略の各々は、さらにテキスト及び／又はＵＲＬリンク及び／又は画像のリストと関連づけられており、前記戦略の前記モータによって生成される前記メッセージは、前記戦略の前記リストのテキスト及び／又はＵＲＬリンク及び／又は画像から構成される；
−  前記メッセージのスタックの少なくとも１つは、固定サイズの後入れ先出し（ＬＩＦＯ）スタックであり、最も古いメッセージは最新のメッセージに置換される；
−  前記メッセージのスタックの少なくとも１つは、トークンタイプのスタックであり、  前記プラットフォーム（２）は、メッセージが要求されたときに前記スタックのトークンを発信し、トークンを受け取る前記メッセージは、最も古いメッセージに置換される；
−  前記インターネットサイトのページは、所定のフォーマットにて所定のパラメータを有するメッセージを受け取ることが可能な少なくとも１つの公開領域を含み、スタックのメッセージは、前記スタックから抽出される前記領域と互換性のあるパラメータ及びフォーマットを有し、前記公開領域が空いているときに前記プラットフォームに送信される；
−  前記ステップ（ａ）では、ユーザの前記状況が、前記ユーザの状況シグネチャと複数のマスクとの比較により特定され、前記マスクの各々は、前記参照状況の１つと関連付けられているとともに、状況シグネチャの空間と対応しており、ユーザの前記状況シグネチャは、監視可能な指標であって、前記プラットフォームに接続された前記ユーザの個人データに対する及び／又は一般データに対する指標のセットを監視することにより取得される；
−  異なるマスクに対応する前記状況シグネチャの空間の幾つかは、前記ステップ（ｃ）において送られる幾つかのメッセージに応じて変更される。
【０００８】
本発明の第２の態様は、少なくとも１つのデータ処理装置及びデータ保存手段を備えるサーバに関し、前記少なくとも１つの処理装置は、ユーザが機器を介してインターネットサイトのプラットフォームに接続されている間、上記した第１の態様に係る方法を実行するように構成されており、前記サーバは、前記プラットフォームと接続されている。
【図面の簡単な説明】
【０００９】
本発明の他の特徴及び利点は、以下の好ましい態様の説明により明らかになるだろう。好ましい態様は、以下の図を参照して説明される。
【００１０】
【図１】本発明が適用されるネットワーク構成図である。
【図２】本発明に係る接続データ処理方法のステップを概略的に示す図である。
【図３】本発明の一実施形態に係る接続データ処理システムの略図である。
【図４】本発明に係る接続データ処理システムの処理モジュールを示す図である。
【図５】本発明の一実施形態に係る接続データ処理システムの即時処理モジュールを示す図である。
【図６】本発明の一実施形態に係る接続データ処理システムの遅延処理モジュールを示す図である。
【発明を実施するための形態】
【００１１】
（状況）
既に述べたように、本発明に係るデータ処理方法は、全ての既知の処理とは異なり、単純なパラメータのリストではなく、全面的な“状況”の分析に基づく。
本明細書を通して、本方法の前述したｅコマースの分野への適用（この場合、処理対象のデータは、インターネットサイトのプラットフォームへの接続データ、すなわち、プラットフォームへの接続に関するデータである）についてより具体的に説明するが、ワークステーションにおける一般的なユーザデータの処理にも適用できることは明らかである。実際には、処理対象のデータは、ユーザの電子メールや、ユーザのシステムパラメータ等であってもよい。接続データを処理することで、データのボリューム及び多様性のおかげで、状況の特定の観点において優れた結果を得ることができる。
【００１２】
ここで、ユーザの“状況”とは、ユーザの心理的及び社会的状態及びユーザの状況場面（他の接続ユーザのすべての状況）を特徴づける、多かれ少なかれ複雑で、多かれ少なかれ曖昧な情報のことを意味する。ある状況は、電子商業において意味のある表現で称されることがある。例えば、“afternoon forager”とは、ランチの後に特にこれといった考えを持たずにインターネットサーフをする女性を指す用語である。
【００１３】
分析、予測及びシミュレーションのためのツールを用いることによって、状況分析は多くの経済分野に広がっている。状況分析（例えば、フランス特許出願ＦＲ２９６２８２３を参照）は、１以上の状況フローを入力において受け取り、そこから状況を抽出し、重要な要素を識別し、継続的に処理を適用し、現象を検知し、特に帰納法を用いて解決策の展開を提供することが、自律的にできる。
【００１４】
これには多くの利点があり、後で述べるように、状況システムは、モデル又は実装アーキテクチャによって制限されず、よって、恒久的に順応する。状況システムは、ちょうど人間の脳のように、その資源を管理することによって重要な点に集中することができる。また、その適用可能性は、特定の分野に区分された現在のエキスパートシステムに比べて、遥かに普遍的である。
【００１５】
本発明に係るデータ処理方法（処理は、少なくとも１つのデータ処理装置及びデータ保存手段を有するサーバによって実行され、そのサーバは、インターネットサイトのプラットフォームへの接続データを処理する場合には、そのプラットフォームとネットワーク接続している）の基本は、第１の機構により１以上のユーザの状況を特定し、その後、収集された状況を第２の機構により処理することである。ｅコマースの場合には、関連のあるユーザは、前述のプラットフォームに機器を介して接続されたユーザであるか、又は、サーバの資源が許容するのであれば（下記を参照）、全ての訪問者であるインターネットユーザであってもよい。
【００１６】
この処理は、複数の受容者（recipient）及び多くの目的を有していてもよく、このことは後で説明する。
【００１７】
図１は、本発明が実行されるネットワークアーキテクチャを示す図である。機器３（これは、ワークステーションからスマートフォンやタッチタブレット等の携帯端末まで含めて、ユーザがこれを介してインターネットにアクセスできるコンピュータ機器のいずれであってもよい）は、インターネット４を介してインターネットサイトのプラットフォーム２に接続されている。サーバ１は、前記方法を実行するための少なくとも１つのデータ処理装置及びデータ保存手段を備え、プラットフォーム２とネットワーク接続されている。
【００１８】
“プラットフォーム”との用語は、１以上の相互接続されたサーバであって、ユーザが現在サーチしているインターネットサイトのページをホストするインターネットサイトのサーバを指すことを理解するのは重要である。処理を行うサーバ１は、プラットフォーム２を構成するこれらのサーバのうちの１つであってもよい。すべてのケースにおける機器ユーザ３は、直接的又は間接的に（プラットフォーム２を介して）インターネットを経由して前記方法を実行するサーバ１に接続される。処理サーバ１とプラットフォーム２との間の接続は、ローカル接続であってもよく、しかし、インターネット４を経由した接続であってもよいことに留意すべきである。
【００１９】
（第１の機構：状況の特定）
図２に示すように、前記プラットフォームに接続されたユーザの状況の特定は、参照状況のリストから行われる。参照状況のリストは、インターネットユーザの行動の監視から予め定義されていてもよいし、あるいは、特に有利には、後で説明する他の機構によって自動的に生成されてもよい。
【００２０】
これが生じるために、
本発明に係る方法の状況特定メカニズムは、“トリガー”を利用する。トリガーは、予め定義されたイベントに応じて、有効化されて特定の処理を開始させることが可能なソフトウェアモジュールである。
【００２１】
トリガーには多くのタイプのものがあってもよい。１つ目のタイプでは、イベントは、
参照（consultation）のクリックや、選択のクリック等のインターネットユーザのアクションである。２つ目のタイプでは、イベントは期間の終了であり、例えば、インターネットユーザの最後の訪問からの期間や、あるいは、トリガーの前回の有効化に対する期間等の、期間の終了である（後者の場合、トリガーは固定の頻度で（例えば１時間ごとに）有効化される）。他にも多くの構成が可能であることは明らかである。
【００２２】
既定のトリガーが有効化されると、サーバ１のデータ処理手段は、少なくとも１つの“指標”の状態を特定するための試みを開始させる。指標は、状況を示す様々な要素である。幾つかの指標は、“状況の場面（scene）”に関するものであり、すなわち、接続されたインターネットユーザに同時に生じる状況のセット又はサブセットである。これは、例えば、時間や天気予報等である。また、幾つかの指標は、“状況の範囲（sphere）”に関するものであり、すなわち、あるインターネットユーザに特有の状況である。これは、例えば、そのインターネットユーザの年齢、性別、身長や、そのユーザのナビゲーション（迅速である、または、躊躇しがちである、など）や、そのユーザの状態（急いでいる、何かを探している、等）等である。したがって、指標は、プラットフォーム２に接続されたユーザの個人データ及び／又は一般データと関連している。実際、これらの２つの状況の“領域”の組み合わせは、信頼性のあるユーザの状況の特定のために良好な結果を提供する。
【００２３】
当然、特に状況分析を考慮すると、好ましい結果（例えば、取引又はその他の結果）に関連する幾つかの指標が含まれる。
【００２４】
サーバ１の処理装置は、予め定義された監視可能な指標の集合を有する。ここで、「監視可能」とは、必ずしも特定可能であることを意味するものではないことに留意すべきである。ある指標のステータスを特定しようという試みは、無益である場合がある。例えば、インターネットユーザの年齢は、必ずしもアクセス可能であるとは限らない。そのような指標は、“識別不可”であるとみなされる。しかしながら、その後の試み（同一のトリガー又は他のトリガーによる）により識別に成功することは、不可能ではない。
【００２５】
特定を試みる指標のリストは、各トリガーと関連付けられている。このトリガーが有効化されれば、これらの指標及びこれらの指標のステータスが監視される。例として、周期的なトリガーは、天気予報又はユーザの１秒あたりクリック数を特定しようと試みることができる。また、フォーム末尾の“send”ボタンのクリックと結びつけられたトリガーは、入力された文字列に応じて、ユーザの年齢及び性別を特定しようと試みることができる。
【００２６】
少なくとも１つの指標のステータスを特定しようとする上述の試みの結果に応じて、サーバ１の処理装置は、ユーザの状況シグネチャを生成し保存手段に格納する（状況シグネチャが既に存在する場合には、この状況シグネチャを更新するのみである）。
ユーザの状況シグネチャは、指標に関連する全てのデータに対応し、そのユーザの状況の特徴を示す。
【００２７】
有利なことに、状況シグネチャは、特に、複数の情報ユニットを含み、各情報ユニットは、１つの指標と関連付けられている（有利なことに、１つの状況シグネチャには２つの部分があり、それぞれ、状況の場面に関連する“閾値（threshold）”と称されるユニットと、状況の範囲に関連する“トラッカー（tracker）”と称されるユニットである）。各情報ユニットは、少なくとも以下の３つの値をとることができる：関連する指標について特定されたステータスが参照ステータスと一致する場合の第１の値（値“１”）と、関連する指標について特定されたステータスが参照ステータスと一致しない場合の第２の値（値“０”）と、関連する指標のステータスが特定できない場合（該当する指標について特定の試みがなされなかったり、トリガーの設定に続くその試みが失敗したりすることによる）の第３の値（値“Ｘ”）である。各情報ユニットは、３つの値を有する“ビット”である。
【００２８】
０、１、Ｘとの表記は、単に説明のための表記であり、当業者はデータの表現を任意に選択できることは明らかである。特に、例えば、既定の数値を持たず、数値や文字列等を格納可能な情報ユニットを使用することができる。しかしながら、ｎ個のステータスを有する情報ユニットの利益を後述する。前述において定義した表記を用いると、1X00 01XXは、８個の情報ユニットを有する状況シグネチャの一例である。
【００２９】
“特定が試みられなかった”場合と“特定が試みられたが失敗した”場合（いずれの場合も値“Ｘ”である）とをここでは区別しないとしても、その代わりに、どの特定を試みたかによる情報を考慮に入れることができることにも留意すべきである。実際、指標のステータスを構成する情報は取得できないが、その試みは失敗したという事実は重要となりうる。例えば、これは、ユーザが意図的に（もしくは意図的ではなく）自分のプロフィールを隠しており、そのために誰かがインターネットにおける機密性を高めようとする可能性があることを意味する。
【００３０】
いくつかのトラッカー又は閾値は、長く続く文字列を後者に与えるために、例えばガウス分布やポアソン分布などの分布法則のインテグレータに基づくものであってもよいことに留意すべきである。言い換えると、インテグレータは、少し前の時間に、先行する１つが起きたとき、特定する試みのための再度のトリガーの必要を回避するための短い期間に、指標が先行する監視に応じて有するべきステータスを提供する。
【００３１】
ユーザの状況シグネチャは、複数の“マスク”と比較される。各マスクは、１つの参照状況と関連付けられており、１つの状況シグネチャ空間と対応する。このため、各マスクは、シグナチャとして、上述した０，１又はＸの値のほかに、情報ユニットが何れでもよい場合の第４の値（“Ａ”と記述される）をとり得る複数の情報ユニットを含む。実際には、いくつかの指標のステータスは特定の状況の特徴を示すものではない。
【００３２】
例えば、10A0 AAX1は、以下のシグナチャを組み合わせた、８個の情報ユニットを有するマスクである：1000 00X1，1000 01X1，1000 0XX1，1000 10X1，1000 11X1，1000 1XX1，1000 X0X1，1000 X1X1，1000 XXX1，1010 00X1，1010 01X1，1000 0XX1，1010 10X1，1010 11X1，1010 1XX1，1010 X0X1，1010 X1X1，1010 XXX1，10X0 00X1，10X0 01X1，10X0 0XX1，10X0 10X1，10X0 11X1，10X0 1XX1，10X0 X0X1，10X0 X1X1，10X0 XXX1。
【００３３】
前述のシグナチャとマスクとの比較は、論理ゲートを用いて容易に行われる（マスクが値“Ａ”を有さない各ユニットは、ＸＯＲによってシグネチャの対応するユニットと比較され、これらの比較の結果にＡＮＤが適用される）。マスクが一致する場合、プラットフォーム２に接続されたユーザの状況は、前述の状況シグネチャを含む少なくとも１つのマスクと関連付けられた参照状況であると特定される。
【００３４】
複数のマスクは、有利には、サーバ１の保存手段に格納されていること、及び、マスクのうちのいくつかは重複する範囲を有することは不可能ではない、すなわち、与えられた状況に対応するマスクの一意性はないことに留意すべきである。この困難さを解決するために、有利には、マスクはローテーションにしたがって繰り返しテストされる。テストの結果が肯定的なものであれば、そのマスクに関連付けられた参照状況は維持され、テストの結果が肯定的でなければ、次のマスクがテストされる。新たなトリガーが有効化されるときには、現在の状況の安定性を維持するために、可能であれば、まず、同一の状況マスクが再度テストされる。
【００３５】
上述した本発明に係る方法の第１のフェーズが完了すると、ユーザの状況であるとして特定された状況が存在する。
【００３６】
（第２の機構：状況の処理）
本発明に係る方法の第２の機構は、ユーザやインターネットサイトの管理者等にとって重要な、処理されたデータを取得するために、上述のように特定されたユーザの状況を、サーバ１の物理的又は論理的な状況分析手段によって分析することを含む。状況分析手段は、サーバ１のデータ処理手段（これは、後述するような、状況分析専用のマルチコアプロセッサであってもよい）によって実行されるアプリケーションであってもよい。
【００３７】
このため、参照状況の各々は、少なくとも１つ（有利には１〜３）の“戦略”、すなわち、１以上の状況モータ（及びこれらのモータのパラメータ）と、メッセージの内容と、を含むセットと関連付けられている。メッセージとは、すなわち、テキスト、グラフィックコンテント（画像又は動画を含む）、ＵＲＬリンク（Uniform Resource Locator）、フォーム要素（フォーマット又はフォントパラメータ等）、又は、メッセージを個別化するために役立つ他のデータを含む。メッセージ（レコメンデーションとも呼ばれる）は、接続データの処理により生じ、その状況において期待される効果を有するあらゆる形態の伝達情報を意味する。
【００３８】
従来の用語を用いれば、これらは、サイトの管理者に（例えば、電子メールの形態で）宛てられるレポートメッセージであってもよいが、特に、そのシチュエーションが処理されたユーザに向けられたメッセージであってもよい。例えば、これはインターネットのページにおいて表示されるバナーや、電子メールや、ＳＭＳ等であってもよい。
【００３９】
状況モータは、状況モータのライブラリから選択されるソフトウェアエレメントである。状況モータの各々は、ユーザの状況に応じて、そのユーザの状況において所期の効果を有する１以上のメッセージを取得するように規定の処理を実行することができる（モータは、
全ての状況の場面及び範囲に関するパラメータを考慮に入れる。実際には、ユーザの状況シグネチャが一意的であっても、特定される状況はそうではない。情報ユニット、すなわち、監視される指標のステータスを考慮に入れることにより、処理が個別化される）。
【００４０】
第１の例のモータは、訪問したユーザと関連する１以上の製品のレコメンデーションを実行することができる（商店向けの例である）。第２の例のモータは、特定されたインターネットユーザの状況と類似の状況において、そのインターネットユーザにより購入された製品のレコメンデーションを実行することができる（個人レベルにおける例である）。第３の例のモータにおいては、（販売の顕著な上昇の検知により、社会的なグループのレベルにおいて）流行の製品が単純にレコメンドされる。
【００４１】
同一の戦略が複数の状況に関連付けられてもよいこと、及び、戦略の各々は、重要性のレベル、すなわち、接続ユーザ数が多くなった場合に重要となり得る優先度を考慮に入れてもよいことに留意すべきである。
【００４２】
前述の特定された状況（重要度の順に分析されてもよい）と関連付けられた戦略の少なくとも１つに対して、サーバ１の処理手段は、関連づけられた状況モータを実行して、メッセージのスタックを少なくとも１つ取得する。有利には、メッセージのスタックが少なくとも２つ（有利には３つ）生成され、メッセージのスタックの各々は、機密性のレベルと関連づけられる。機密性のレベルとは、メッセージの公開度のレベルを意味する。例えば、本方法を２つの機密性レベルで実行する場合、レベル１は個別のメッセージに対応し、レベル２はグローバルなメッセージに対応する（例えばサイト上のバナー）。先に示したモータの３つの例は、異なる３つの機密性レベルに対応する。１つ目の例は、あらゆるユーザに向けられたものであるため、機密性の“低い”レベルに該当し、２つめの例は、レコメンデーションは個人的なものであり、そのユーザのみに向けられたものであるため、機密性の“高い”レベルに該当する。３つ目の例は、グループのレベルでの公開であるため、“平均的な”機密性のレベルに対応する。したがって、３つのモータにより生成されるこれら３つのレコメンデーションは、異なる３つのスタックに見つけられる。
【００４３】
これらのメッセージのスタックは、アンスタック（unstack）されてメッセージを“公開（expose）”する、すなわち、受領者にメッセージが送られる。より詳細には、これは、（必要に応じて）ユーザの機器３及び／又はプラットフォーム２（ページ要素の場合）に前述の少なくとも１つのメッセージスタックのメッセージのサブセットを送ることを含む。
【００４４】
これは、単純なＬＩＦＯ（後入れ先出し；Last In First Out）のポリシーによって行うことができるが、有利には、いわゆるトークン方式が用いられる。この方式では、現在のページは、所定のフォーマット及び所定のパラメータを有するメッセージを受け取ることができる公開領域を含む。このような領域は、利用可能な場合には、その領域のパラメータを含むトークンを送る。状況モータはそのトークンを受け取り、“コマンドで”これらのパラメータに応じた１以上のメッセージを構成する。トークンをもつメッセージは、他のものよりも先にスタックから抽出される。
【００４５】
メッセージの公開は、状況に影響を及ぼすものであり（例えば、そのメッセージがユーザにとって期待される効果を有していた場合に取引が生じることによって）、新たなトリガーを有効化し、そのユーザが置かれた状況に変化をもたらす可能性を有する。本方法は、再度開始され、メッセージの効果は、次の分析サイクルにおいて監視される。
【００４６】
（処理能力の最適化）
インターネットユーザの行動は、一日を通して一定であるわけではなく、特にピーク時には、サーバ１のデータ処理手段は、情報の流入（言い換えれば、処理すべきフローのボリューム）という困難に直面する。
【００４７】
有利には、このシステムはこれらのトラフィックの変化を考慮し、本方法を管理する。特に、本方法は、有利には、全ての接続ユーザの状況を特定するのに必要な資源を使用するが（本方法の第１の部分は、第２の部分よりも少ない資源を消費する）、使用可能な容量に見合った部分のみ、特に、前述した戦略の“重要性のレベル”にしたがって分類（ソート）された部分のみを分析する。
【００４８】
このため、３つの段階的なアクティビティレベルが定義され（ここでは“αフロア”、“βフロア”及び“γフロア”と称する）、各レベルではオペレーションが低下モードに移行したり（閾値を超えたいくつかの状況が省略（drop）される）、又は延期されたりする（興味深いと判断された幾つかの状況は、混雑により直ちには処理されず、後でアクティビティが低くなったときに処理される）。状況の分析の指定は、アクティビティのレベルによっても変化する。資源が十分でない場合には重要性が考慮され（“主として演繹的な”モード）、そうでない場合には、詳細な分析が実行され（“主として帰納的な”モード）、その分析のためにより多くの反射（reflex）が存在する。半監視モード又は非監視モード（下記参照）の場合には、利用可能な資源の学習が好ましい。
【００４９】
前述した３つのレベルは、１秒あたりのアクション数において、サイトにおける典型的なアクティビティのレベルに応じて定義される。
【００５０】
αフロアはアクティビティの“高い”レベルに該当する。例えば、これは、１０００以下の同時接続数を有するサイトであり、平均して一人のユーザが１０秒ごとに１回クリックすることを想定すれば、αフロアは１００Ｈｚでの接続である。
【００５１】
βフロアはアクティビティの“平均的な”レベルに該当する。例えば、同一のサイトにおいて、１日あたり１０００００の接続がり、平均して一人のインターネットユーザは１分３０秒滞在するとすれば、βフロアは１０．４Ｈｚでの接続である。
【００５２】
γフロアはアクティビティの“低い”レベルに該当する。例えば、同一のサイトにおいて、１日における同時接続数の割合が最大値と最小値との間で１〜１００である（又は、１クリックあたり９秒において最大接続数が最低値の１０である）とすれば、γフロアは１．１１Ｈｚでの接続である。
【００５３】
逆のケースでは（必要とするよりも多くの処理能力が利用可能である場合）、本方法は、“シャドー（shadows）”を利用することができる。すなわち、学習ベースを増加させるために以前のユーザに関する既存の状況を維持することができる。
【００５４】
（半監視モード及び非監視モード）
本方法は機能する参照状況のセットを必要とするが、このセットは不変のものではなく変化するものであってもよい。特に、戦略は、新規の状況の出現を知らせるメッセージが、特にサイトの管理者に送られるように構成された状況モータを含んでいてもよい。その管理者は、その新規の参照状況を作成することを決定することができる。
【００５５】
半監視モードでは、システムは新たな参照状況を管理者に提案し（状況モータによってあらかじめ定義されたマスクと関連付けられる）、管理者はこれらの提案を有効化するかどうかを決定できる。また、非監視モードでは（例えば図２に示される）、システムは完全に自動であり、新たな参照状況を含む。
【００５６】
“出芽（budding）”による新規の状況の出現は監視されることに留意すべきである。言い換えると、モータが検知するのは、より大きな状況（例えば、ある参照状況に対応する多数の状況シグネチャが、“Ａ”に分類される（すなわち、マスクにおいて考慮されない）指標について同一のステータスを示す場合）のサブカテゴリの出現である。
【００５７】
（反射プロセッサ）
本発明の第２の態様に係るシステム１、特にサーバ１は、少なくとも１つのデータ処理装置及びデータ保存手段を備え、該少なくとも１つのデータ処理ユニットは、ユーザが機器３を介してサイトのプラットフォーム２に接続している間、第１に態様に係る方法を実行するように構成される。
上述したように、本方法は、プラットフォーム２を含むサーバ群（すなわち、サイトのページをホストしサイトの運営を管理するサーバ群）とは異なるサイトのサーバによって最も頻繁に実行され、ユーザの機器３は、プラットフォーム２を介して、本方法を実行するそのサーバに接続される。
【００５８】
本発明の第２の態様は、インターネットサイトのプラットフォーム２への接続データを処理するためのシステム１に関するものであり、その特に好ましい態様が図３に示される。このシステムは、下記のものを備える：
・少なくとも２つの独立した接続データ処理モジュール（２１，２２）（“SALI2”モジュール；SALIX及びSALICは２つのバージョンである）。処理モジュール（２１，２２）は、少なくとも２つの補完グループに分けられ、１つのグループのモジュール（２１，２２）は、ユーザの状況の特定を含む、ユーザの前記プラットフォーム２への接続データを処理する方法の実行に必要なオペレーションのサブセットを実行するように構成される。各グループの処理モジュール２１は、全てのデータ処理接続プロセスを完了するために他のグループの処理モジュール２２からのデータを受け取る；
・接続データを受け取り、該接続データを処理モジュール（２１，２２）に送るための分配モジュール１０（“RENZO”）；
・処理モジュール（２１，２２）からのデータを収集し、処理された接続データをプラットフォーム２へ送るための調停モジュール３０（“RENALDO”）。
これらのモジュール１０，２１，２２，３０は、入力データを“先験的な推測（priori）をせずに”処理するという性質を有するため、反射プロセッサと称する。
【００５９】
したがって、原則として、ｎ個のモジュール（２１，２２）のグループを２つ（またはそれ以上）有し、１つのグループのモジュール（２１，２２）は同一のタスクを並列して実行する。各グループのタスクは、接続データの処理を補完して実行する。異なるモジュール（２１，２２）は、物理的に独立した（そしてバスを介して接続された）プロセッサであってもよく、この場合、モジュールの各々は各自処理手段及び格納領域を有する。あるいは、異なるモジュール（２１，２２）は、与えられた機器において使用されるソフトウェアの塊（brick）であってもよく、この場合、複数のモジュールは、同一のプロセッサ資源（マルチコアであってもよい）及び同一の格納領域を共有する。システム１は、複数のサーバに分散されていてもよく、あるいは、仮想マシン上のクラウドコンピューティングにインストールされていてもよいことに留意すべきである。モジュール（２１，２２）は、有利には、例えば、XML（eXtensible Markup Language）、JSON（JavaScript Object Notation）、SOAP（Simple Object Access Protocol）、Silvia又はMawerickプロトコル等の抽象化言語のフローの形式のデータを交換する。
【００６０】
図４は、SALI2タイプの処理モジュール（２１，２２）（グループとは独立したもの）を概略的に示す図である。明らかなように、このモジュールは、有利には７つの入力／出力ポートを有する。モジュール（２１，２２）は、前述した方法のステップを実行できるように、実行可能な状況モータのライブラリ及び／又はインターネットサイトのオントロジーの特徴を含むデータベースに接続されることが好ましい。具体的には、
−  ＯＢＳポート（observer）は、プラットフォーム２からのＸＭＬフロー形式のデータを受け取る；
−  ＣＯＬポート（collector）は、他のＳＡＬＩ２処理モジュール（２１，２２）からのＸＭＬフロー形式のデータを受け取る；
−  ＯＮＴポート（ontology）は、ＸＭＬファイル形式のオントロジーを受け取る；
−  ＬＩＢポート（library）は、トラッカー、閾値及び（実行可能な）状況モータのライブラリを含む；
−  ＥＤＩポート（editor）は、ＸＭＬフロー形式のデータ出力データを発信する；
−  ＤＩＦポート（diffuser）は、他グループの処理モジュール（２１，２２）へＸＭＬフロー形式のデータを発信する；
−  ＭＯＮポート（monitoring）は、統計データを発信する。
【００６１】
モジュール（２１，２２）のグループ間でタスクを分散させると、モジュール（２１，２２）の専門化により処理効率を向上させることができ、また、図３から明らかなように、各グループに対して“フィードバック”されるデータを与えることができる。処理の一部の結果は、処理の他の部分を向上させる。処理モジュール（２１，２２）のグループ間における実行可能な分散のいくつかの手段について後述する。これらのアプローチを組み合わせてもよいことに留意すべきである。すなわち、システム１は、第１の法則に従って分散されたモジュール（２１，２２）の２つのグループを有し、１つのグループのモジュール（２１，２２）は、第２の法則に従って２つのサブグループに分散さるようにしてもよい。
【００６２】
分類（ソート）の作業は、情報のパケットのそれぞれを解釈し、各パケットを適切な処理モジュール（２１，２２）に宛てて送る分配モジュール１０によって行われる。調停モジュール３０は、完了した処理に応じて送られようとするメッセージに関するフローを受け取り、これらのメッセージの公開に取り組む。それは、サイトのプラットフォーム２及び／又はユーザの機器３へのフローの全体を組み立て直す。
【００６３】
第１の変形例では、あるグループの処理モジュール２１は、前述のプラットフォーム２へ接続されたユーザの状況を特定するように構成された前処理モジュールであり、別のグループの処理モジュール２２は、特定された接続ユーザの状況を処理するように構成された後処理モジュールである。この有利な構成において、有利には、１つの前処理モジュール２１と、Ｎ個の後処理モジュール２２（特に４個又は８個が好ましいが、このような数には限定されず、何個でもよい。）が存在する。これは、得られた状況の処理及びメッセージの送信は、本方法のうち、最も多くの資源を消費する部分であるためである。
【００６４】
図２に見られるようなフィードバックリンクにより、前処理モジュール２１は、１つ又は複数の後処理モジュール２２からのデータを収集して、状況の特定に影響を与えるようにすることができる。これにより、前述した非監視モードが実行可能となる。
【００６５】
第２の変形例では、あるグループの処理モジュール２１はリアルタイム動作を実行し（“即時処理”のモジュール）、別のグループのモジュール２２は延期された動作を実行する（“遅延処理”のモジュール）。言い換えると、幾つかのモジュール２１は、即時のアクションが必要なタスク（例えば、ユーザのナビゲーションと結びついたトリガーや、即時の公開を伴うメッセージを送ること等）を実行し、それに対し、他のモジュール２２は、時間をずらして実行されてもよいタスクを実行する。データは、処理が可能となるまで保存手段に保存される。この構成は、“リアルタイム”モジュール２１が遅延処理に関するデータ（より古い接続データの処理結果）を受け取る範囲において、情報の耐久性及び過去の考慮を容易にする。フィードバックループにより、遅延処理モジュール２２と“処理グリッド”（これを介して即時処理が行われる）の即時処理モジュール２１との通信が可能となる。また、この構成は、即時処理から遅延処理へのデータの転送が混雑する期間によく適応する。
【００６６】
これは、図３に示すシステムに関係する。図３において、“SALIX”は遅延処理モジュール２２であり、“SALIC”は即時処理モジュール２１である。この有利な構成において、
有利には、１つの遅延処理モジュール２２と、Ｎ個の即時処理モジュール２１とが存在する（即時処理は優先度を有し、遅延することができない処理もあるため、より多くの資源を消費する）。４つの即時処理モジュール２１を有する構成においては、合計７つのモジュール１０，２１、２２，３０が存在し、そのため、８コアプロセッサを用いることが特に好ましい（８つ目のコアは残りのシステムオペレーションを管理する）。
【００６７】
図５及び図６は、それぞれ、SALICタイプの即時処理モジュール２１及びSALIXタイプの遅延処理モジュール２２をより詳細に示す図である。これらの図には、ＯＢＳ、ＣＯＳＳ、ＥＤＩ及びＤＩＦの各ポートが示される（ＯＮＴ、ＬＩＢ及びＭＯＮの各ポートは、２種類のモジュールの間で同様に接続される）。
【００６８】
即時処理モジュール２１（SALIC）は、監視（observer）ポートによって受け取られる参照、選択及び消費のベクタ（指標のステータスを特定するために監視されるデータを含む）を通して、全てのユーザ状況を特定する処理（即時に行われるべきもの）を行う。
【００６９】
拡散（diffuse）ポートは、上述のベクタを遅延処理モジュール２２（SALIX）に伝送する。収集（collector）ポートは、遅延して処理された前記情報ベクタ及びグリッドを遅延処理モジュール２２（SALIX）から受け取る。
【００７０】
トラッカー（及び閾値）は、ベクタ及びグリッドから状況シグネチャを生成する。特定された状況の戦略と関連づけられたリアルタイム状況モータが実行され、モータの実行により生成されたメッセージがエディタ（editor）ポートを介して送信される。
【００７１】
遅延処理モジュール２２（SALIX）は、即時に実行する必要がない処理を取り扱う。監視（observer）ポートは、即時処理モジュール２１（SALIC）からのベクタを受け取る。状況モータは、処理が遅延されたポイントを定義するタイマーによって実行及び制御される。
【００７２】
これらのモータは、遅延メッセージ（例えばサイトを再訪するように促す販売促進の電子メール等、訪問の数時間後に送られるユーザ宛てのメッセージ）、及び、サイト管理者向けのメッセージ（メッセージはエディタ（editor）ポートを介して適切なサポートに送信される）を生成するとともに、説明したように、拡散（diffuser）ポートを介して即時処理モジュール２１（SALIC）に（いくつかのベクタとともに）返送されたグリッドを処理する。
【００７３】
第３の変形例では、モジュール（２１，２２）の各グループは、“サービスのライン”に対応する。これは、“ＬＳＯ（Lines/Services/Options）”と称するシステムの内部のインターネットサイト内の商品分類に基づくユニットである。サービスのラインは、いくつかのサービスをまとめたものである。例えば、“テーブル”、“テレビ台”、“カウチ”等の家具のカタログに含まれるサービスをまとめる“サロン”カテゴリは、一つのサービスのラインである。同様に、“男性”カテゴリ又は“ＸＬサイズ”カテゴリは、衣服のカタログのサービスのラインの１つである。商業サイト等のインターネットサイトでは、同一の商品を幾つかの分類モードに属させることが可能であり、その場合これらは異なるサービスラインである。各サービスはオプションを有する。先に挙げた例では、“男性”ラインの“ズボン”サービスは、ズボンの型のオプションのリストを含むであろう。各オプションは、ある商品を幾つかのバリエーション（サイズ、色、等）とともに表現する。一方、各商品は、オプションとは異なり、実際にはただ１つのユニークなもの（与えられたカタログのリファレンス）である。したがって、同一の商品は幾つかのＬＳＯコンテキストに存在する。再度この例を採りあげると、同一のズボンは“ＸＬ”ラインの“男性用ズボ”サービスに見つけられる。
【００７４】
処理モジュール（２１，２２）は、サービスラインによって分けることができる。特に、サイトが広範囲の商品を扱うものであり、ユーザの状況が多様になるであろうという場合にはそうすることが適する。規模の大きなサイトでは、ユーザがナビゲートしているサービスのラインにしたがって、プラットフォーム２を構成する複数のサーバのうちの何れかのサーバにユーザがリダイレクトされることは適切であることに留意すべきである。
【００７５】
有利には、これらの変形例のうちのいくつかが組み合わせて用いられる。特に、第２の変形例の即時処理モジュール２１（SALIC）は、それぞれ、特定の１以上のサービスのライン専用のものとしてもよい。この場合、分配モジュール１０（RENZO）は、その特定のサービスラインに応じて、管理データが存在する場合には、入力のフローを遅延処理モジュール２２（SALIX）に送り、ユーザからのナビゲーションデータが存在する場合には、入力のフローを即時処理モジュール２１（SALIC）に送ることによって、入力のフローを分配する。
【図１】
2019036344.tif 000003
【図２】
2019036344.tif 000004
【図３】
2019036344.tif 000005
【図４】
2019036344.tif 000006
【図５】
2019036344.tif 000007
【図６】
2019036344.tif 000008
【手続補正書】
【提出日】平成30年11月21日(2018.11.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも１つのデータ処理装置及びデータ保存手段を含むサーバ（１）によってインターネットサイトのプラットフォーム（２）への接続データを処理する方法であって、
（ａ）機器（３）を介して前記プラットフォーム（２）に接続されたユーザの状況を、参照状況のリストの中から特定するステップであって、
前記参照状況の各々は、少なくとも１つの戦略と関連付けられており、
前記戦略の各々は、状況モータのライブラリから選択される１以上の状況モータを含み、
前記状況モータの各々は、ユーザの状況に応じて実行された際に、その状況において所期の効果を有するメッセージを取得するように所定の処理を実行可能なソフトウェアエレメントである
ステップと、
（ｂ）特定された前記状況に関連付けられた前記戦略の少なくとも１つについて、前記戦略の前記状況モータが少なくとも１つのメッセージのスタックを取得するように前記処理を、前記サーバ（１）の前記データ処理装置によって、前記状況について実行するステップと、
（ｃ）前記少なくとも１つのメッセージのスタックの前記メッセージのサブセットを前記ユーザの前記機器（３）及び／又は前記プラットフォーム（２）に送るステップと、
を備えることを特徴とするインターネットサイトのプラットフォームの接続データの処理方法。
【請求項２】
前記戦略の各々は重要性のレベルと関連付けられており、
前記戦略と関連付けられた前記状況モータの実行の順序は、前記戦略の前記重要性のレベルによって決まる
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ステップ（ｂ）では少なくとも２つのメッセージのスタックが取得され、
前記スタックの各々は機密性のレベルと関連付けられている
ことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記戦略の各々は、さらにテキスト及び／又はＵＲＬリンク及び／又は画像のリストと関連づけられており、
前記戦略の前記状況モータによって生成される前記メッセージは、前記戦略の前記リストのテキスト及び／又はＵＲＬリンク及び／又は画像から構成される
ことを特徴とする請求項１乃至３の何れか一項に記載の方法。
【請求項５】
前記メッセージのスタックの少なくとも１つは、固定サイズの後入れ先出し（ＬＩＦＯ）スタックであり、最も古いメッセージは最新のメッセージに置換される
ことを特徴とする請求項１乃至４の何れか一項に記載の方法。
【請求項６】
前記メッセージのスタックの少なくとも１つは、トークンタイプのスタックであり、
前記プラットフォーム（２）は、メッセージが要求されたときに前記スタックのトークンを発信し、
トークンを受け取る前記メッセージは、最も古いメッセージに置換される
ことを特徴とする請求項１乃至４の何れか一項に記載の方法。
【請求項７】
前記インターネットサイトのページは、
所定のフォーマットにて所定のパラメータを有するメッセージを受け取ることが可能な少なくとも１つの公開領域を含み、
スタックのメッセージは、前記スタックから抽出される前記公開領域と互換性のあるパラメータ及びフォーマットを有し、前記公開領域が空いているときに前記プラットフォーム（２）に送信される
ことを特徴とする請求項５又は６に記載の方法。
【請求項８】
前記ステップ（ａ）では、ユーザの前記状況が、前記ユーザの状況シグネチャと複数のマスクとの比較により特定され、
前記マスクの各々は、前記参照状況の１つと関連付けられているとともに、状況シグネチャの空間と対応しており、
ユーザの前記状況シグネチャは、監視可能な指標であって、前記プラットフォーム（２）に接続された前記ユーザの個人データに対する及び／又は一般データに対する指標のセットを監視することにより取得される
ことを特徴とする請求項１乃至７の何れか一項に記載の方法。
【請求項９】
異なるマスクに対応する前記状況シグネチャの空間の幾つかは、前記ステップ（ｃ）において送られる幾つかのメッセージに応じて変更される
ことを特徴とする請求項８に記載の方法。
【請求項１０】
少なくとも１つのデータ処理装置及びデータ保存手段を備えるサーバ（１）であって、
前記少なくとも１つの処理装置は、ユーザが機器（３）を介してインターネットサイトのプラットフォーム（２）に接続されている間、請求項１乃至９の何れか一項に記載の方法を実行するように構成されており、
前記サーバ（１）は、前記プラットフォーム（２）と接続されている
ことを特徴とするサーバ（１）。