JP2019523470A - データを処理するための方法及び装置 - Google Patents

Abstract

コンピュータデバイスはイベントデータのストリームを受信し、そのイベントデータはイベント自体に関するデータとデバイス又はユーザの識別子とを有する。１つ又は複数のイベントが、様々な識別子について記憶され、状態として使用される。２つ以上の異なるスクリプトが実行され、少なくとも１つのイベントに関する情報が少なくとも２つの異なるスクリプトによって共有される。【選択図】 図２

Description

本発明はデータを処理するための方法及び装置に関する。

多くの組織は、大量のデータを継続的に収集しており、これらのデータはその後分析可能である。この分析（analysis）は、リアルタイムアナリティクス（analytics）を伴う場合や履歴データの分析を伴う場合がある。収集されているデータは時間の経過と共に変化し得る。

データがある企業の１つ以上のゲームに関するものである場合の例について検討する。分析は、単一のゲームに関連するか又はいくつかの異なるゲームについて収集されたデータに関連し得る。更に、２つ以上のプラットフォームに様々なゲームが提供される可能性がある。

いくつかのコンピュータで実行されるゲームは非常に多数のプレーヤを有する場合があり、各プレーヤは、アイデンティティ（identity）（ユーザ名）、電子メール、スコア、プレー時間、ユーザによって提供され得る他の関連データであって、例えば、ソーシャルネットワークアカウント及びこれに関連する友人などの関連データを有する。

ゲーム分析は、ゲームに関連するデータを分析するのに使用される。ゲーム分析データは、ユーザの振る舞いを理解すること、ゲームを強化すること、異常検出などのいくつかの異なる目的のために使用することができる。データ分析のために非常に大量のデータを管理することは難しいことである。

一側面によると、複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信すること、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、及び、複数の異なるスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも２つの異なるスクリプトによって使用される、前記複数の異なるスクリプトを実行することを含む方法が提供される。

この方法は、複数の第２のデータセットの第２のストリームを出力することを含んでもよく、少なくとも１つの第２のデータセットが少なくとも２つの異なるイベントに関する情報を含むものであり、上記少なくとも２つの異なるイベントが上記第１のストリームにおける様々な第１のデータセットで受信されたものである。

この方法は、少なくとも１つの更なるスクリプトを、その後、複数の異なるスクリプトが実行されている間に受信して、上記複数の異なるスクリプトに加えて前記少なくとも１つの更なるスクリプトを実行することを含んでもよい。

この方法は、前記少なくとも１つの更なるスクリプトについて、前記複数のスクリプトの少なくとも１つについて記憶されている少なくとも１つのイベントに関する情報を前記少なくとも１つの更なるスクリプトが使用するか否か、又は、前記少なくとも１つの更なるスクリプトについて少なくとも１つの更なるイベントに関する情報を記憶すべきか否かを判定し、前記使用すると判定した場合又は前記記憶すべきと判定した場合に、識別子のそれぞれについて前記少なくとも１つの更なるイベントに関する情報を記憶することを含んでもよい。

複数の第１のデータセットの第１のストリームは第１のエンティティにて受信されてもよく、複数の第２のデータセットの第２のストリームは第２のエンティティに出力されてもよく、前記方法は、複数の第３のデータセットの第３のストリームを第３のエンティティにて受信することであって、第３のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第３のデータセットが様々な識別子に関連付けられるものであると共に様々な第３のデータセットが様々なイベントに関する情報を有するものである、前記複数の第３のデータセットの第３のストリームを第３のエンティティにて受信すること、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、複数の異なるスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも２つの異なるスクリプトによって使用されるものである、前記複数の異なるスクリプトを実行すること、及び、第３のエンティティから第２のエンティティに複数の第４のデータセットの第４のストリームを出力することを更に含んでもよく、少なくとも１つの第４のデータセットが少なくとも２つの異なるイベントに関する情報を含むものであり、前記少なくとも２つの異なるイベントが前記第３のストリームにおける様々なデータセットで受信されたものである。

この方法は、第２のストリーム及び第４のストリームのデータにデータを集約することを含んでもよい。

少なくとも１つのイベントに関する情報を記憶することは、少なくとも１つの他のイベントにとって有効となり得る１つ以上のイベントに関する情報を記憶することであってもよい。

この方法は、前記イベントに関する情報を処理して、当該処理された情報を前記イベントに関する情報としてストアに記憶することを含んでもよい。

この方法は、各識別子に関連する少なくとも１つの記憶されたイベントに関する更新された情報を受信して、前記更新された情報を記憶することを含んでもよく、前記更新された情報が前記複数のスクリプトの１つ以上のスクリプトによって使用される。

この方法は、各識別子に関連する少なくとも１つのイベントに関する更新された情報を受信し、前記更新された情報を使用してイベントに関する更新された情報を決定し、当該更新された情報を記憶することを含んでもよく、前記更新された情報が前記複数のスクリプトの１つ以上のスクリプトによって使用される。

この方法は、各識別子に関連する更新情報を受信し、各識別子に関連する少なくとも１つのイベントに関する記憶された情報を読み出し、記憶された情報及び受信した更新情報を使用して更新された情報を決定し、前記識別子のそれぞれについて、前記複数のスクリプトの１つ以上のスクリプトによる使用のために前記更新された情報を記憶することを含んでもよい。

この方法は、複数の異なるデバイスから前記第１のストリームのデータセットを受信することを含んでもよい。

識別子は、前記第１のストリームにおける各データセットを提供する各デバイスに関連するユーザを識別するものであってもよい。

識別子は、前記第１のストリームにおける各データセットを提供するデバイスを識別するものであってもよい。

第１のストリームにおける複数の第１のデータセットは、コンピュータで実行されるゲームのプレー中に生成されたイベントに関する情報を含むものであってもよい。

他の側面によると、複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信すること、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、少なくとも１つの第１のスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも１つのスクリプトによって使用される、前記少なくとも１つの第１のスクリプトを実行すること、及び、少なくとも１つの第２のスクリプトを、その後、少なくとも１つの第１のスクリプトが実行されている間に受信して、前記少なくとも１つの第１のスクリプトに加えて前記少なくとも１つの第２のスクリプトを実行することを含む方法が提供される。

この方法は、複数の第２のデータセットの第２のストリームを出力することを含んでもよく、少なくとも１つの第２のデータセットが少なくとも２つの異なるイベントに関する情報を含むものであり、前記少なくとも２つの異なるイベントが前記第１のストリームにおける様々な第１のデータセットで受信されたものである。

この方法は、前記少なくとも１つの第２のスクリプトについて、上記第１のスクリプトのうちの少なくとも１つについて記憶されている少なくとも１つのイベントに関する情報を前記少なくとも１つの第２のスクリプトが使用するか否か、又は、前記少なくとも１つの第２のスクリプトについて少なくとも１つの更なるイベントに関する情報を記憶すべきか否かを判定して、前記使用すると判定した場合又は前記記憶すべきと判定した場合に、識別子のそれぞれについて前記少なくとも１つの更なるイベントに関する情報を記憶することを含んでもよい。

他の側面によると、複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信すること、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、及び、前記様々なイベントのうちの所与のイベントを受信したことに応答して、前記イベントの少なくとも１つに関する記憶された情報を含む出力を提供することを含む方法が提供される。

前記出力は前記様々なイベントのうちの所与のイベントに関する情報を更に含むものであってもよい。

一側面の特徴と他の側面による任意の特徴とを組み合わせることができることが認識されるべきである。

この方法は、コンピュータやサーバなどの任意の適切なデバイスにおいて実現することができる。コンピュータ又はサーバなどには、１つ以上のコンピュータ実行可能命令（コンピュータプログラム）を実行するように構成された少なくとも１つのプロセッサが設けられ得る。少なくとも１つのメモリが、データ及びコンピュータプログラムコード又は命令を記憶するために設けられてもよい。

一側面によると、少なくとも１つのプロセッサと、１つ以上のプログラムに関するコンピュータコードを有する少なくとも１つのメモリとを含むコンピュータ装置であって、少なくとも１つのメモリ及びコンピュータコードが少なくとも１つのプロセッサと共に、少なくとも、複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信すること、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、及び、複数の異なるスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも２つの異なるスクリプトによって使用される、前記複数の異なるスクリプトを実行することを前記コンピュータ装置に実行させるように構成される、コンピュータ装置が提供される。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、複数の第２のデータセットの第２のストリームを出力することを実行させるように構成されていてもよく、少なくとも１つの第２のデータセットが少なくとも２つの異なるイベントに関する情報を含むものであり、前記少なくとも２つの異なるイベントが前記第１のストリームにおける様々な第１のデータセットで受信されたものである。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、少なくとも１つの更なるスクリプトを、その後、複数の異なるスクリプトが実行されている間に受信して、前記複数の異なるスクリプトに加えて前記少なくとも１つの更なるスクリプトを実行させるように構成されていてもよい。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、前記少なくとも１つの更なるスクリプトについて、前記複数のスクリプトの少なくとも１つについて記憶されている少なくとも１つのイベントに関する情報を前記少なくとも１つの更なるスクリプトが使用するか否か、又は、前記少なくとも１つの更なるスクリプトについて少なくとも１つの更なるイベントに関する情報を記憶すべきか否かを判定して、前記使用すると判定した場合又は前記記憶すべきと判定した場合に、識別子のそれぞれについて前記少なくとも１つの更なるイベントに関する情報を記憶させるように構成されていてもよい。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、少なくとも１つの他のイベントにとって有効となり得る少なくとも１つのイベントに関する情報を記憶させるように構成されていてもよい。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、前記イベントに関する前記情報を処理し、当該処理された情報を前記イベントに関する情報として記憶させるように構成されていてもよい。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、各識別子に関連する少なくとも１つの記憶されたイベントに関する更新された情報を受信し、当該更新された情報を記憶して、前記更新された情報が前記複数のスクリプトの１つ以上のスクリプトによって使用されるように構成されていてもよい。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、各識別子に関連する少なくとも１つのイベントに関する更新された情報を受信し、当該更新された情報を使用してイベントに関する更新された情報を決定し、当該更新された情報を記憶して、前記更新された情報が前記複数のスクリプトの１つ以上のスクリプトによって使用されるように構成されていてもよい。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、各識別子に関連する更新情報を受信し、各識別子に関連する少なくとも１つのイベントに関する記憶された情報を読み出し、当該記憶された情報及び受信した更新情報を使用して更新された情報を決定し、前記複数のスクリプトの１つ以上のスクリプトによる使用のために前記識別子のそれぞれについて前記更新された情報を記憶するように構成されていてもよい。

この装置は、複数の異なるデバイスから前記第１のストリームのデータセットを受信してもよい。

前記識別子は、前記第１のストリームにおける各データセットを提供する各デバイスに関連するユーザを識別するものであってもよい。

前記識別子は、前記第１のストリームにおける各データセットを提供するデバイスを識別するものであってもよい。

イベントは、イベント識別子と共に識別されたイベントの値又は特性などを定義するデータを含むものであってもよい。

第１のストリームにおける第１のデータセットは、コンピュータで実行されるゲームのプレー中に生成されたイベントに関する情報を含むものであってもよい。

複数の第１のデータセットの第１のストリームは前記コンピュータ装置にて受信されてもよく、前記コンピュータ装置は第１のエンティティであり、複数の第２のデータセットの第２のストリームは第２のエンティティに出力されてもよい。第３のエンティティである更なる装置が設けられてもよい。この第３のエンティティは、少なくとも１つのプロセッサと、１つ以上のプログラムに関するコンピュータコードを有する少なくとも１つのメモリとを含んでもよく、少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、少なくとも、複数の第３のデータセットの第３のストリームを受信することであって、第３のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第３のデータセットが様々な識別子に関連付けられるものであると共に様々な第３のデータセットが様々なイベントに関する情報を有するものである、前記複数の第３のデータセットの第３のストリームを受信すること、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、複数の異なるスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも２つの異なるスクリプトによって使用される、前記複数の異なるスクリプトを実行すること、及び、前記第２のエンティティに複数の第４のデータセットの第４のストリームを出力することを第３のエンティティに実行させるように構成されている。

１つのシステムには第１、第２及び第３のエンティティが設けられてもよい。第２のエンティティは、少なくとも１つのプロセッサと、１つ以上のプログラムに関するコンピュータコードを有する少なくとも１つのメモリとを含んでもよく、少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、少なくとも、前記第２のストリーム及び前記第４のストリームのデータにデータを集約することを第２のエンティティに実行させるように構成されている。

一側面によると、少なくとも１つのプロセッサと、１つ以上のプログラムに関するコンピュータコードを有する少なくとも１つのメモリとを含むコンピュータ装置であって、少なくとも１つのメモリ及びコンピュータコードが少なくとも１つのプロセッサと共に、少なくとも、複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信すること、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、少なくとも１つの第１のスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも１つのスクリプトによって使用される、前記少なくとも１つの第１のスクリプトを実行すること、及び、少なくとも１つの第２のスクリプトを、その後、少なくとも１つの第１のスクリプトが実行されている間に受信して、前記少なくとも１つの第１のスクリプトに加えて前記少なくとも１つの第２のスクリプトを実行することを前記コンピュータ装置に実行させるように構成されている、コンピュータ装置が提供される。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、複数の第２のデータセットの第２のストリームを出力することを実行させるように構成されてもよく、少なくとも１つの第２のデータセットが少なくとも２つの異なるイベントに関する情報を含むものであり、前記少なくとも２つの異なるイベントが前記第１のストリームにおける様々な第１のデータセットで受信されたものである。

少なくとも１つのメモリ及びコンピュータコードは少なくとも１つのプロセッサと共に、前記少なくとも１つの第２のスクリプトについて、前記第１のスクリプトの少なくとも１つについて記憶されている少なくとも１つのイベントに関する情報を前記少なくとも１つの第２のスクリプトが使用するか否か、又は、前記少なくとも１つの第２のスクリプトについて少なくとも１つの更なるイベントに関する情報を記憶すべきか否かを判定して、前記使用すると判定した場合又は前記記憶すべきと判定した場合に、識別子のそれぞれについて前記少なくとも１つの更なるイベントに関する情報を記憶するように構成されていてもよい。

一側面によると、少なくとも１つのプロセッサと、１つ以上のプログラムに関するコンピュータコードを有する少なくとも１つのメモリとを含むコンピュータ装置であって、少なくとも１つのメモリ及びコンピュータコードが少なくとも１つのプロセッサと共に、少なくとも、複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記第１のデータセットの第１のストリームを受信すること、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、及び、前記様々なイベントのうちの所与のイベントを受信したことに応答して、前記イベントの少なくとも１つに関する記憶された情報を含む出力を提供することを前記コンピュータ装置に実行させるように構成されている、コンピュータ装置が提供される。

前記出力は前記様々なイベントのうちの所与のイベントに関する情報を更に含むものであってもよい。

一側面の特徴と他の側面による任意の特徴とを組み合わせることができることが認識されるべきである。

他の側面によると、コンピュータ装置を制御するための命令をコード化した非一過性（non-transitory）のコンピュータ可読媒体であって、命令がプロセッサ上で実行されたとき、複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信するステップと、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶するステップと、複数の異なるスクリプトを実行するステップであって、前記少なくとも１つのイベントに関する情報が少なくとも２つの異なるスクリプトによって使用される、前記複数の異なるスクリプトを実行するステップと、をプロセッサに実行させる、非一過性のコンピュータ可読媒体が提供される。

他の側面によると、コンピュータ装置を制御するための命令をコード化した非一過性のコンピュータ可読媒体であって、前記命令がプロセッサ上で実行されたとき、複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信するステップと、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶するステップと、少なくとも１つの第１のスクリプトを実行するステップであって、前記少なくとも１つのイベントに関する情報が少なくとも１つのスクリプトによって使用される、前記少なくとも１つの第１のスクリプトを実行するステップと、少なくとも１つの第２のスクリプトを、その後、少なくとも１つの第１のスクリプトが実行されている間に受信して、前記少なくとも１つの第１のスクリプトに加えて前記少なくとも１つの第２のスクリプトを実行するステップと、をプロセッサに実行させる、非一過性のコンピュータ可読媒体が提供される。

他の側面によると、コンピュータ装置を制御するための命令をコード化した非一過性のコンピュータ可読媒体であって、前記命令がプロセッサ上で実行されたとき、複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信するステップと、識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶するステップと、前記様々なイベントのうちの所与のイベントを受信したことに応答して、前記イベントの少なくとも１つに関する記憶された情報を含む出力を提供するステップと、をプロセッサに実行させる、非一過性のコンピュータ可読媒体が提供される。

前記出力は、前記様々なイベントのうちの所与のイベントに関する情報を更に含むものであってもよい。

一側面によると、１つ以上のイベントストリームを受信することを含む、コンピュータで実行される方法が提供される。

イベントストリームは、１人以上のユーザからのゲームデータを含むものであってもよい。

この方法は、前記１つ以上のイベントストリームに応じて少なくとも１つの出力を計算するための少なくとも１つのスクリプト又はメソッド（method）を実行することを含んでもよい。

前記出力は、少なくとも１つのウィンドウ集計（windowed aggregate）を含むものであってもよい。

少なくとも１つの出力又は少なくとも１つのウィンドウ集計の前記計算において状態情報（state information）が使用されてもよい。

この方法は、１つ以上の様々なフォーマットで出力を提供することを含んでもよい。

この方法は、状態情報を更新することを含んでもよい。この状態情報は、前記イベントストリームにおける情報に応じて更新されるものであってもよい。

ウィンドウ集計は、定義された時間ウィンドウにおいてイベントストリームに関連する値を集計するものであってもよい。

ある実施形態では、出力は、複数の異なるフォーマットに提供されてもよいし、並列に提供されてもよい。

ある実施形態は抽象化（abstraction）を提供する。抽象化はフィールドであってもよい。抽象化はユーザが定義した抽象化であってもよい。抽象化は前記状態情報を定義するものであってもよい。これは、システムにとってトランスペアレントな手法で実行され得る。

抽象化は１つ以上の属性（attributes）を有することができる。属性は、フィールド名、更新機能、イニシャライザ（initializer）という属性の１つ以上を含んでもよい。フィールド名は、例えば、前記状態情報としての関連する値にアクセスするためのストリング参照などの参照であってもよい。更新機能は、前記イベントストリームにおける１つ以上のイベントに応答して前記抽象化がどのように更新されるかを定義するものであってもよい。イニシャライザは、デフォルト値、初期値又はイニシャライザ機能を定義するものであってもよい。

ある実施形態では、前記イベントストリームにおけるイベントを受信したことに応答して、前記イベントに関連するユーザに関連する状態が前記抽象化からアクセスされる。状態情報はイベントストリームの処理に使用される。

新たな抽象化を、スクリプトのイニシャライズメソッドにおいてレジスタスクリプトに渡すことによって登録することができる。

更なる実施形態では、受信したイベントストリームは実質的にライブデータのストリームを含むものであってもよく、上述した処理は実質的にリアルタイムアナリティクスを提供する。

他の側面では、コンピュータプログラムプロダクトは、実行されたときに上述した方法のいずれかを提供するように構成されたコンピュータ実行可能コードを含む。

また、上述した方法を実行するように適合されたプログラムコード手段を含むコンピュータプログラムが提供され得る。コンピュータプログラムは、キャリア媒体を用いることによって、記憶すること及び／又は具体化することができる。

以上では、多くの異なる実施形態が記載されている。以上説明した実施形態のうちの任意の２つ以上の組み合わせにより更なる実施形態を提供できることが認識されるべきである。

また、以下の詳細な説明及び添付の特許請求の範囲には、様々なその他の側面及び更なる実施形態が記載されている。

ここで、添付した図面を単なる例示として参照する。

ある実施形態を提供するシステムを示す概略図である。 データパイプラインを示す概略図である。 バックエンドアーキテクチャの一例を示す概略図である。 一実施形態において表示される画像の一例を示す図である。 表示されたデータベースデータの一例を示す図である。 アプリケーションがデプロイされたときに表示される画像及び関連するデータの一例を示す図である。 ある実施形態におけるスクリプトのデプロイメント／実行の概要を示す概略図である。 ある実施形態において使用されるデータ処理パイプラインを示す概略図である。 ある実施形態において使用されるデータ処理パイプラインを示す概略図である。 ある実施形態の処理構成を示す概略図である。

ここで、ビッグデータの取り扱いに関して、ある実施形態について説明する。ある実施形態を、ゲームデータの取り扱いというコンテキストで説明する。この実施形態は任意のタイプのビッグデータを取り扱うのに用いられるが、本発明はゲームデータの取り扱いに限定されるものではないことを認識されたい。例えば、ある実施形態は、１つ以上のウェブサイト又はソーシャルメディアプラットフォームとのユーザインタラクションがトラッキングされるシナリオに適用されてもよい。他の実施形態は、多数のトランザクション又はイベントが発生する環境で適用されてもよい。例えば、ある実施形態はトランザクションを共有するのに適用されてもよい。ある実施形態は車両交通シナリオ又は気象監視アプリケーションに適用されてもよい。

図１は、ある実施形態のシステム３００を示す概略図である。システム３００は、ゲームプレーヤの詳細、プロファイル及びハイスコアなどのデータベースを記憶可能なサーバ３２０を含む。実際には、１つ以上のデータベースが提供され得る。２つ以上のサーバが提供される場合、データベースは、１つのデータベースとして提供される場合もあれば、２つ以上のサーバ３２０にわたって提供される場合もある。２つ以上のサーバが提供される場合、異なるサーバを他のサーバに対して異なる位置に提供することができる。

サーバ３２０は、また、ゲームデータ機能を有することができる。サーバ３２０は、コンピュータゲームプログラムを記憶するためのメモリと、このゲームプログラムを実行するためのプロセッサと、を含むことができる。

ある実施形態では、データベース機能は、ゲーム又は他のサポートされた機能を提供するものに対して様々なエンティティによって提供されてもよい。

サーバは、例えばインターネット３１０を介して１つ以上のユーザデバイス３０５と通信することができ、Ｆａｃｅｂｏｏｋ（登録商標）などのソーシャルネットワーク３３０への接続を更に提供することができる。任意の他のネットワークが、代替的に又は追加的に、インターネットの代わりに又はインターネットに加えて他のネットワークによって使用可能であることを認識されたい。

実施形態は様々なゲームシステムアーキテクチャにデプロイできることを認識されたい。例えば、コンピュータゲームは、ユーザデバイス２００のメモリ内に記憶されると共にユーザデバイス２００のプロセッサ上で実行されるコンピュータゲームとして実現することができる。但し、ある実施形態では、サーバ３２０はゲームのいくつかの要素を取り扱うことができる。単なる例示として、ゲームアプレットはユーザデバイス２００に提供されてもよく、ローカルで実行中のアプレットは、例えば、ユーザデバイス２００上でそのゲームプレーに関するグラフィックス、サウンド及びユーザインタラクションを生成することになる。サーバ３２０にフィードバックされるデータが存在する場合があり、これにより、他のユーザデバイス３０５とのインタラクションが可能になる。データがフィードバックされることは、スコアリング及び／又はクロスプラットフォーム同期も可能にし得る。

ある実施形態では、ゲームは、例えば、サーバ３２０などのシステムのメモリに記憶されるコンピュータプログラムであって、ゲームサーバのプロセッサ上で実行されるコンピュータプログラムとして実現することができる。データストリーム又は更新がユーザデバイス２００に供給されて、ユーザデバイス２００がユーザデバイス２００のブラウザ内にグラフィックス及びサウンドを提供し表示することが可能となる。このようなアプローチは、ウェブサービスアプローチと呼ばれることがある。しかしながら、このようなアプローチは必ずしもインターネットの使用を必要とするものではないことを認識されたい。

他の実施形態では、サーバは、システムによってサポートされるアプリケーション次第で、様々なノンゲーム（non-game）機能を有することができることを認識されたい。

データパイプラインを示す概略図である図２を参照する。この図には、例えば、データウェアハウスにゲームイベントを記憶できる構成が示されている。データウェアハウスに記憶されているデータを分析することができる。パイプラインは、ゲームサーバ５１０、ＴＳＶ（タブ分離値）ログファイル５２０、ログサーバ５３０及びデータウェアハウス５４０を含む。データウェアハウスでは、データはローデータから次元モデルに処理され、その次元モデルはレポートを提供するのに使用され得る（又はデータ科学者に直接提供され得る）。抽出、変換、挿入というＥＴＬプロセスを、ローデータを次元モデルに変換するのに使用することができる。レポートはローデータ及び／又は次元モデルから提供され得る。

ここで、バックエンドアーキテクチャを示す図３を参照する。このアーキテクチャも、例えば、データウェアハウスにゲームイベントを記憶できる構成を有する。データウェアハウスに記憶されているデータを、分析ツール３５０を使用して分析することができる。図１に関連して説明したものなどのユーザデバイス２００が提供されている。ユーザデバイス２００は、インターネット３１０又は他の適切なネットワークを介してゲームサーバ３４０と通信する。ゲームサーバ３４０は任意の適切なサーバであってもよい。ゲームサーバはゲームサービスを提供する。ゲームサーバは、ユーザデバイス上のクライアントからの要求又はトラッキングコール（tracking call）を聴取することができる。

１つ以上のゲームデータサーバ３４２は、プレーヤの現在の進捗状況及び他の関連する状態を記憶するように構成されている。サーバを、共有データベースサーバ又は１つ以上の任意の他の適切なサーバにすることができる。ある実施形態では、これらの１つ以上のサーバは、リレーショナルデータベース管理システムであってもよい。ある実施形態では、ゲームデータサーバ内のデータは、実際のゲームで使用されるだけのデータを含んでもよい。ゲームデータフォーマットは、ある実施形態では、関連するゲームに依存するものであってもよい。他の実施形態では、データフォーマットは２つ以上のゲームにわたって同じものであってもよい。

着信イベント（incoming events）は、データベースクラスタ３４４に記憶され、また、着信イベントを、データウェアハウス及びビジネスインフラストラクチャ３４６内のファイルに書き込むことができる。データウェアハウス及びビジネスインフラストラクチャを分散ファイルシステムにすることができる。各イベント又は少なくともいくつかのイベントはテーブルにマッピングされる。テーブルを、データキューブ３４８で提供することができる。テーブルの使用により、データに関する集計（aggregates）の計算及び／又はより複雑なバッチ分析の実行をより単純化することを可能にする。

ある実施形態はルールベースのイベントアグリゲータＲＢＥＡに関する。ある実施形態では、ＲＢＥＡはスケーラブルリアルタイムアナリティクスプラットフォームを提供する。このプラットフォームはストリームアナリティクスに使用することができる。このプラットフォームは、１つ以上のプロセッサ上で実行されるコンピュータ実行可能コードによって実現することができる。１つ以上のプロセッサは、１つ以上のサーバ及び／又は１つ以上のコンピューティングデバイスに設けることができる。これは、例えば、ゲームサーバによって生成されるデータについて実行することができる。当然、他の実施形態では、生成又は提供されるデータは、サポートされる機能に依存することになる。この分析は、データハウスに記憶されているデータについて分析が実行される図２又は図３に関連して述べた例とは異なり、「リアルタイム」のものである。

ストリームアナリティクスは、代替的にデータレコード又はデータと呼ばれるイベントを使用することができる。

これらのイベントは、リアルタイムに又はこれらが受信された後に分析することができる。イベントは１つ以上のストリームで提供することができる。単一のストリームからのデータ又は２つ以上のストリームからのデータを使用することができる。

ある実施形態では、このアナリティクスは、２つ以上のストリーム同士を比較するものであってもよいし、１つ以上のストリームと履歴値及び／又はモデルとを比較するものであってもよい。

このアナリティクス次第で、特定の状況が発生した場合に、異常を検出することができるか又はアラートを発動することができる。この状況はエラー状況又は任意の他の適切な状況であってもよい。ある実施形態では、アナリティクスを異常検出に用いてもよいことを認識されたい。但し、これは例示であり、例えば、データの収集及び集計、トレンドの識別及び／又は任意のその他の解析のサポートを可能にする他のタイプの機能を代替的に又は追加的にサポートすることができる。

ある実施形態は、出力として集計データを提供することができる。

出力をユーザに提供することができる。

この出力は、例えば、ダッシュボード上に表示されてもよい。

この出力は、１つ以上のプロセッサによってサポートされる更なる計算プロセスへの入力として提供されてもよい。プロセッサは、例えば、１つ以上のコンピュータ又はサーバ内にあってもよい。

ある実施形態は、分散型ビッグデータアナリティクスのためのフレームワークを使用することができる。このフレームワークは、分散型ストリーミングデータフローエンジンを使用することができる。このフレームワークは、データ並列のパイプライン化方式でデータフロープログラムを実行することができる。このフレームワークは、パイプライン化ランタイムシステムを有することができ、このパイプライン化ランタイムシステムは、バルク／バッチ及び／又はストリーム処理プログラムの実行を可能にし得る。反復アルゴリズムの実行はネイティブサポートされ得る。プログラムは、データベースクラスタ環境で実行可能なデータフロープログラムにコンパイルすることができる。中央データ記憶システム又は分散型データ記憶システムを使用することができる。データは待ち行列から又は任意の他の適切な手法で提供することができる。

ビッグデータの問題に対して何らかのコンテキストを提供するために、本出願人は、３億９千万を超える月極固有ユーザと、種々のゲーム及びシステムから毎日受信した３００億を超えるイベントを有する。これらの数字は、例示であり、実施形態では、これらの数字例よりも多いか又はこれらの数字例未満のイベントを使用できることを認識されたい。実施形態は、かなり小さいデータセットに適用可能であると共にビッグデータのコンテキストにおいて適用可能であることを認識されたい。

ビッグデータを用いることで、あらゆるストリームアナリティクスユースケースが現実の技術的難題になる。データアナリストのためのコンピュータで実行されるツールであって、これらの適用のためのフレキシビリティを維持しながらこれら大量のデータストリームを扱うことができる、前記データアナリストのためのコンピュータで実行されるツールを有することは望ましいことである。一般に、複雑なデータストリームアナリティクスは専門家の知識を必要としていた。ある実施形態で提供されるアプローチは複雑なデータストリームアナリティクスを単純化して専門家の知識の必要性が少なくなる。

ある実施形態は、代替的に比較的小さいデータストリームで使用できることを認識されたい。

ある実施形態では、分析及び／又はコアゲームの外部の他のデータニーズのためにイベントデータが使用される。ある実施形態の例について説明するために、イベントデータの一例はゲームデータである。しかしながら、サポートされる機能次第では、そのデータが任意の他の適切なデータであってもよいことを認識されたい。

ある実施形態では、イベントデータは、ゲーム内で何が起きたかを定義する固定スキーマ（タブ区切りテキスト）を備えた簡単なテキストログにすることができる。サポートされる機能次第では、そのデータが任意の他の適切なフォーマットであってもよいことを認識されたい。

ゲームスタートを記述するイベントの一例は以下の通りである。

第１のフィールドはイベント番号を提供する。第２のフィールドは発生したイベントを記述する。第３のフィールドはユーザアイデンティティを規定する。第４のフィールドはエピソードを記述し、このエピソードにおいてイベントが発生している。第５のフィールドはレベルを記述し、このレベルにおいてイベントが発生している。第６のフィールドはゲームラウンドを記述し、このゲームラウンドにおいてゲームイベントが発生している。あるゲームは、１つ以上のエピソード又はチャプタを有してもよく、１つ以上のエピソード又はチャプタのそれぞれが１つ以上のレベルを含む。あるゲームはレベルのみを有してもよい。

受信したローイベントデータの一例は以下の通りである。
20131017T113040.393+0200 17 10005 1006627249 7 12 1382002240393

他の実施形態では任意の他の適切なフォーマットがイベントデータに使用されてもよいことを認識されたい。

データのサブセットをデータベースクラスタにロードすることができる。これにより、より高速のアドホッククエリをサポートすること及び／又は複雑なデータベースクエリをより良好にサポートすることができる。

ある実施形態では、全てのストリームからのデータをデータベース／データベースクラスタに集約することにより、リアルタイム集計をイベントについて計算することができ、リリース監視及び／又はリアルタイムダッシュボードのためのデータソースを提供する。

データウェアハウスエンジニア及びデータ科学者は、通常、リレーショナルデータ及びこれに関連するツールを用いて作業する。イベントストリームデータは、複雑な分析になると、比較的異なる性質を有する。基本的な集計及び／又は何らかの単純化を使用して数ある難題に対処することができる。典型的には、問い合わせ言語を使用することができる。但し、少なくともいくつかのイベントは、例えば発生した時間及び／又はコンテキストによって他のイベントに関係付けられてもよい。

しかしながら、ゲームスタート前にユーザが何を行ったか又はゲーム内をどのように移動したか（ファネル、セッションなど）などの問い合わせの場合、基本的なデータベース問い合わせ言語は限定される。

これらの問題に対処して異なるイベント同士を関係付けるために現在提案されているオプションは以下の通りである。
１．置換（replacement）及びリレーショナルキーなど、ゲーム内で求められるコンテキストを追加することをゲーム開発者に要求すること。しかしながら、これは、開発作業を複雑にし得る。また、これは、どのデータが必要になり得るかを前もって理解することをゲーム開発者に要求するものである。
２．関心があるものをイベントテーブルから選択し、プレーヤ／時間についてイベントをソートし、カスタムレジューサなど、データを関連付けるコードであって、コンピュータで実行されるコードによってそれを実行すること。これは、毎日（daily）の処理において比較的非効率的となり得る。イベントは、イベントあたり１つのテーブルを用いて記憶され、異なるイベント配列とともに発生した順序に戻す複数の異なるクエリで直ちにフォローアップされる。そのデータは日常のバッチが実行されたときにのみ見ることができる。
３．例えば、基本的なデータベース言語で実行可能な単純化されたモデルを作成すること。これは常に可能であるわけではない。

従って、ある実施形態は、リアルタイムに分析を実行することが可能になるようなＲＢＥＡを提供することを目的とする。従って、ＲＢＥＡは、ライブストリームから直接的に結果を提供しながら、イベント又はデータを時間で接続すること及び／又はイベント又はデータに関するコンテキスト情報をスケーラブルな手法で記憶することをサポートすることができる。ＲＢＥＡは、使いやすいウェブインターフェースを用いて幅広くアクセス可能にすることができる。

ある実施形態では、ＲＢＥＡは、大規模で複雑なストリーミングアナリティクスをユーザのためにアクセス可能とするように設計されたプラットフォームである。ＲＢＥＡは、オブジェクト指向プログラミング言語のスクリプトを簡単にデプロイできるようなものであってもよい。このオブジェクト指向プログラミング言語は任意の適切なオブジェクト指向プログラミング言語にすることができる。表示されるインターフェースは、ウェブインターフェース又は任意のその他の適切なインターフェースにすることができる。スクリプトは、いくつかの「クリック」又はユーザインターフェースとの任意の他の適切なユーザ対話を用いてデプロイすることができる。ある実施形態では、スクリプトは、１つ以上の他のスクリプトを実行しながらデプロイされてもよい。ＲＢＥＡは、ユーザがデプロイメントの詳細を有する必要なしに瞬時に結果を提供するように構成することができる。このアーキテクチャにより、大型のストリーミングクラスタ及びデプロイメントを管理する負担からデータアナリスト又は他のユーザを解放することができる。

ＲＢＥＡスクリプトは、ハードウェアクラスタ上で実行することができ、ライブイベントストリームから実質的にリアルタイムに結果を生み出すことができる。ある実施形態では、このスクリプトは、代替的に又は追加的に、記憶されているデータを用いて実行され得る。ＲＢＥＡを使用すると、ユーザ状態を定義して更新するために、１つ又は複数の異なる出力フォーマットに出力を書き込むために、及び／又は、すべてのユーザ又はユーザのサブセットにわたるグローバルアグリゲータを作成するために１つ以上のストリームアナリティクスツールに対して容易にアクセスすることが可能になる。

ＲＢＥＡのＡＰＩ（アプリケーションプログラムインターフェース）は、スケールにおいて依然として良好なパフォーマンスを達成しながら、基礎となるストリーミングエンジンの知識を必要とせずにストリームアナリティクスタスクが容易に作成可能となるように構成される。

次に、簡単なＲＢＥＡスクリプトの一例を提供する。スクリプトは、ＲＢＥＡによって実行されるユーザ定義のプログラムである。

以下のスクリプトは、理解しやすくするために注釈が付けられており、テキストファイルにゲームエンドイベントを書き込みながら、１分間（1-minute windows）の終了ゲームの全てをカウントするものである。
//所与の時間でゲームを終了させた人の数をカウント。
//ライブイベントを受信するメソッドを定義。
def processEvent(event, context){
//"context"から出力データを収集しメモリ内の変数に割り当てる。"output"
def output = context.getOutput()
//"context"からアグリゲータ変数（aggregator variables）を収集しメモリ内の変数に割り当てる。//"agg"
def agg = context.getAggregators()
//６０秒までカウントするエンプティカウンタ（empty counter）を作成。
//ウィンドウサイズが１分のカウンタを作成。
def gameEndCounter = agg.getCounter("GameEnds", 60000)
//この関数に渡されたイベントがゲームエンドイベントであるか否かを判定。
if(isGameEnd(event)){
//ゲームエンドであればカウンタの値を１増やす。
gameEndCounter.increment()
//イベント／結果をストレージに書き込む。
output.writeToFile("GameEndEvents", event)
}
}

ライブイベント（live events）を１つずつ受信するプロセスイベント（processEvent）メソッドが定義される。出力オブジェクトはコンテキスト（context）から得られる。ウィンドウサイズが１分（即ち、６０，０００ミリ秒）のGameEndsと呼ばれるカウンタが作成される。すべての着信イベントについて、これがゲームエンドであるか否かがチェックされ、ゲームエンドである場合、カウンタの値を１増やし（incremented）、GameEndEventsという名前のテキストファイルにイベントが書き込まれる。このスクリプトはFinishedGamesとして保存することができる。

ウェブインターフェースを示す図４を参照する。スクリプトをデプロイ（deploy）するため、スクリプトを編集（edit）するため、又は、スクリプトを削除（delete）するためのオプションとともに、保存スクリプト（saved scripts）のリストが示されている。デプロイオプションが選択された場合、インターフェースはどのスクリプトが実行されているかを示すことになる。スクリプトの出力は、表示オプションを使用して表示することができる。

この例では、ＲＢＥＡは、表示ボタンを選択して即時のデータ探索を提供することにより簡単にアクセス可能なアグリゲータ出力に関するテーブルを作成した。この点に関しては、データを表示可能な２つのフォーマットを示す概略図である図５を参照する。テキストファイルに書き込まれたゲームエンドイベントは、また、予定通りにアクセスされ、サーバからの要求でダウンロードされてもよい。特に、図５に示す例では、５つの１分周期で記録されたイベントは、テーブル形式で示され、また、グラフを使用して表現される。データが収集されると、そのデータは任意の適切なフォーマットで提示又は出力できることを認識されたい。ある実施形態では、当然、データは更に操作され得る。

いくつかのリアルワールドアプリケーションでは、アナリストは、現行セッション又は現行ゲームなど、ユーザに関して計算している状態を用いて作業し得る。数百万人のユーザのうちの数百人についての状態を計算することはアナリティクスアプリケーションにおける難題である。従来の解決策は、リアルタイムアプリケーションが、アプリケーションの要件に適合しなくなることの多い古いユーザ状態（例えば、バッチジョブによって予め計算されたもの）にアクセスだけができるようなものであった。

ＲＢＥＡでは、開発者はユーザ状態をリアルタイムに作成及び更新することができる。これには、状態処理機能をサポートするハードウェア及び／又はコンピュータソフトウェアが使用される。ＲＢＥＡは、システムにとってトランスペアレントな手法でユーザが任意のユーザ状態を定義可能にするフィールドと呼ばれる簡単な抽象化を提供する。

新たなフィールドを、スクリプトのイニシャライズメソッドにおけるレジストリのregisterField（フィールド）メソッドに渡すことによって登録することができる。

フィールドは、以下の属性の１つ以上を指定することによって定義される。
１．フィールド名：これは状態データStateDataからの値にアクセスするためのストリング参照である。
２．更新機能：着信イベントのそれぞれについてフィールドがどのように更新されるかを定義する。更新機能は、(State, Event)→Stateと、(Context, Event)→Stateという２つのタイプで現れる。
３．イニシャライザ：デフォルトでは、状態はヌル（null）に初期設定されるが、イニシャライザ機能（UserID→State）又は初期状態値を定義することが可能である。

フィールドの可用性は、ステートフルストリーミングプログラムに関するクリーンパターンに適している。
１．アプリケーションによってイニシャライズメソッドにおけるフィールドとして使用される任意の状態を定義すること。
２．受信したイベント又はデータのそれぞれについて、状態データから現行ユーザ、現行ユーザデバイス又は他の識別子に関する状態にアクセスすること。
３．現行入力を拡充し、処理を実行すること。

ある実施形態は、レベルあたりの全トランザクションの計算を可能にする。換言すれば、ある実施形態は、特定の状態に関連する多数のイベントの決定を可能にする。３０分ごとに、ゲームにおけるレベルあたりの全収益を計算することが望ましい場合の例について検討する。プロセスイベントメソッドの観点から、トランザクションが発生するたびに、現行レベルに関するアグリゲータにその金額を追加することが望ましいであろう。問題は、トランザクションイベントが現行レベルに関する情報を含まないことである。プレーヤが新たなゲームをスタートするときは、レベル情報を含むゲームスタートイベントが発生し、その後のトランザクションはそのレベルに属するべきである。ある実施形態のフレームワークにおいてこのユースケースを解決するために、プレーヤのそれぞれに関する現行レベルを状態としてトラッキングし続けることが望ましい。これは、フィールドを使用できるタイプのステートフルアプリケーションである。
//所与のゲームにおいて３０分ごとにレベルあたりの全収益を計算。
//メソッドを定義。
def processEvent(event,ctx){
//"ctx-context"からアグリゲータ変数を収集しメモリ内の変数に割り当てる。//"agg"
def agg = ctx.getAggregators()
//"ctx"から状態データ（state data）を収集しメモリ内の変数に割り当てる。"state"
def state = ctx.getStateData()
//３０分のウィンドウサイズで合計アグリゲータ（sum aggregator）を定義。
def amountPerLevel = agg.getSumAggregator("Amount", 30^*60^*1000)
//集計値（aggregated values）（レベルあたりの量（amountPerLevel））をリレーショナルデータベース管理システムの代わりにテキストファイルに書き込む。
amountPerLevel.writeTo(OutputType.FILE)
//この関数に渡されたイベントがトランザクションであるか否かを判定。
if(isTransaction(event)){
//状態データから現行レベルを読み出す。
Integer currentLevel = state.get("CURRENT_LEVEL")
//現行レベルについてカウンタの値を１増やす、各レベルは固有のカウンタを有する。
amountPerLevel.setDimensions(currentLevel).add(getAmount(event))
}
}
//ユーザがプレーしている現行レベルを登録する新たなメソッド。
def initialize(registry){
//現行レベル状態を定義し、ヌル値（−１）に初期設定する。
def currentLevel = Field.create("CURRENT_LEVEL", {
//新たなゲームスタートのそれぞれについてレベルを更新。
Integer prevLevel, Event e -> isGameStart(e) ? getLevel(e):prevLevel
}).initializedTo(-1)
//このジョブについて状態が登録され（現行レベル）、自動的に計算される。
registry.registerField(currentLevel)
}

現行レベルフィールドは、ユーザのそれぞれが現在どのレベルでプレーしているかを自動的にトラッキングし続ける。この情報は、プロセスイベントメソッドで見られる状態データから（イベントに基づいて）現行プレーヤが容易にアクセス可能なものである。この状態データを１つ以上の様々なスクリプトで使用することができる

この例では、状態はレベルであることを認識されたい。状態を、任意の他の適切なパラメータにすることができる。ある実施形態では、パラメータは１つのイベントデータセットで提供されてもよいが、そのパラメータを含まない異なるイベントデータとともに要求される。

ある実施形態は、２つ以上の状態条件を要求してスクリプト又はメソッドの一部とすることができる。

ある実施形態では、状態情報として使用される情報は、単に、受信したイベントによって提供されてもよい。

ある実施形態では、状態情報を更新することはいくつかの処理を必要とする場合がある。例えば、現在記憶されている状態情報を、受信した情報によって変更することができる。例えば、ストリーム内の受信した情報は増分量又は減分量を示すことができる。当然、任意の他の処理を実行することもできる。

ある実施形態では、状態情報は受信した情報から決定される必要がある場合がある。この決定は、１つ以上の他のデータ及び／又は以前のデータを任意選択的に用いて、受信したデータの処理を必要とする可能性がある。

ある実施形態では、記憶されている状態を、新たなイベントに関する情報と、以前記憶した情報であって、あるイベントに関する情報とを用いて更新して、記憶される新たな状態値を作成することができる。

例えば、レベル完了イベントを受信したことに応答して、レベルを変更することができる。従って、現行レベルは現行状態であり、新たなイベントはレベル完了になり、新たな現行レベルはそれから決定され得る。

他の例は、成功したゲームエンドイベントをトラッキングすることにより、ユーザが１００個の赤いキャンディをクラッシュしたか否かをトラッキングすることができる。例えば、２０個の赤いキャンディがクラッシュされたという情報を含む成功したゲームエンドに関するイベントが受信される。これに続いて、１０個の赤いキャンディがクラッシュされたことを示すイベントを受信すると、合計３０個の赤いキャンディ、即ち、現在記憶されている２０個のキャンディと新しい１０個のキャンディが記憶されることになる。

ゲームイベントは単なる例示であり、問題となるイベントは実施形態がデプロイされるコンテキストに依存することになる。

アプリケーションがデプロイされたときに表示される画像を示す図６を参照する。アプリケーションはＲＢＥＡバックエンドジョブによって実行される。バックエンドはＲＢＥＡシステムのインスタンシエーションである。ストリーム処理ジョブは、ＲＢＥＡ用のバックエンドとして機能する適切なフレームワーク上で実行される。テキストファイルは、ＧＵＩ（グラフィカルユーザインターフェース）を介してアクセスできる、レベルあたりの総額（aggregated amount）を含む。表示オプションを選択することにより、レベルあたりの総額が示される。ある実施形態では、任意の他の適切なユーザインターフェースを、代替的に又は追加的に提供できることを認識されたい。ある実施形態では、総額の情報は、他のコンピュータで実現されるプロセスの代替として又はこれに加えて提供することができる。

ＲＢＥＡインターフェースを、ユーザからのストリーム処理内容の少なくとも一部又は全てを抽象化するように構成することができる。例えば、以下の１つ以上をユーザから抽象化することができる。
イベントストリームを読み込み。
スクリプトの実行を並列化。
グローバルウィンドウアグリゲータの作成。
ユーザ状態の作成及び更新。
１つ以上のターゲットフォーマットへの出力の書き込み。
フォールトトレランス及び一貫性。

数十億のイベント及び数百万のユーザについて、多くの並列ＲＢＥＡジョブをスケーリングする手法でこれらの抽象化を実行すると、以下の特性の１つ以上を備えたストリーミングデータフローエンジンが必要になる場合がある。
非常にスケーラブルな状態抽象化。
カスタムウィンドウイングロジックのサポート。
巡回データフローのサポート。
正確に１回の処理する保証。

イベント及び／又はユーザのスケールが異なると、異なる基準が適切なデータフローエンジン又はプラットフォームを選択するのに使用され得ることを認識されたい。

デプロイされ連続的に実行されている１つのジョブのみが全ての実行されているＲＢＥＡスクリプトのためのバックエンドとして機能することができる。但し、他の実施形態では、この機能を２つ以上のスクリプトによって提供することができる。スクリプトは、効率的な手法でクラスタリソースを共有するオペレータ（後述する）において実行されている場合がある。ウェブフロントエンド上にデプロイされたスクリプトは既に実行されているジョブに送られ、ＲＢＥＡスクリプトのライフサイクル管理（スクリプトの追加／除去、障害への対処など）はオペレータ自体によって扱われる。

様々なＲＢＥＡオペレーション（アグリゲータの増分、出力の書き込み）はオペレータのために様々な出力に変換される。

次に、図９を参照する。単なる例示として、ユースケースについて検討する。このユースケースの例では、特定のレベルに関連する収益の金額が監視される。これを監視可能とするために、現行レベルに関する情報及びそのレベルでプレーしている間に行われた購入に関する情報が必要となる。この例では、クライアントデバイスから提供されるイベントは、購入情報及び同じイベントにおけるゲームレベルを有していない。むしろ、ゲームレベルは、１つのタイプのイベントにおいてユーザアイデンティティとともに提供される。購入に関する情報は、ユーザアイデンティティを有する様々なイベントにおいて提供される。

図９では、９０４は第１のユーザからのイベントストリームを表し、９０６は第２のユーザからのイベントストリームを表している。

例えば、イベント９００は、第１のユーザに関するゲームスタートイベントを表すことができ、第１のユーザのユーザアイデンティティ、ゲームがスタートされたという指標及びゲームレベルを有することになる。イベント９０２は、第１のユーザに関するゲーム購入イベントを表すことができ、第１のユーザのユーザアイデンティティ、ゲームアイテムが購入されたという指標及び購入価格を有することになる。

イベント９０８は、第２のユーザに関するゲームスタートイベントを表すことができ、第２のユーザのユーザアイデンティティ、ゲームがスタートされたという指標及びゲームレベルを有することになる。イベント９１０は、第２のユーザに関するゲーム購入イベントを表すことができ、第２のユーザのユーザアイデンティティ、ゲームアイテムが購入されたという指標及び購入価格を有することになる。

ある実施形態は、このようなクエリをデータストリームについて実行可能とするアプローチを提供するものである。特に、実施形態はクエリについて必要なイベントを作成させる。クエリは、状態の読み込み及び／又は変更、データの集計、出力の作成、ＲＢＥＡによってサポートされる他の機能の１つ以上を実行可能なＲＢＥＡ ＡＰＩを使用して作成される。クエリが特定のレベルに関連する収益の金額である場合、作成されるイベントは現行ゲームレベル及び購入価格を有することになる。

図９では、各ユーザについて区分９１５が設けられる。区分は同じキーに属する全てのイベントとして定義される（この例ではキーはユーザＩＤである）。図９に示す例では、第１の区分９１５ａは第１のユーザのそれぞれに関連付けられており、第２の区分９１５ｂは第２のユーザのそれぞれに関連付けられている。従って、実施形態は、イベントをユーザアイデンティティごとに区分することができる。他の実施形態では、様々な基準を用いてイベントを区分できることを認識されたい。

クエリのそれぞれについて実行されているスクリプトは、各ユーザに関する区分にデプロイされる。示されている例では、第１のユーザのデータに関連してデプロイされるスクリプトＳ１〜Ｓ４は参照符号９２２ａである。第２のユーザのデータに関連してデプロイされるスクリプトＳ１〜Ｓ４は参照符号９２２ｂである。現実では、例えば、１台の物理的マシンは数百万のユーザ区分を含むことができる。ある実施形態では、すべての物理的マシン上に複数のスクリプトが１回記憶されて、複数の区分がスクリプトを共有するようになる。但し、他の実施形態では、所与の物理的マシン上に１つのスクリプトの２つ以上のコピーが提供されてもよい。

スクリプトがデプロイされると、どの状態がクエリに必要であるかが決定される。例えば、このクエリの例の場合、状態は現行ゲームレベルとなり得る。この状態は、そのユーザについてのデータストア９２０に記憶される。第１のユーザに関する状態データストアは参照符号９２０ａであり、第２のユーザに関するデータストアは参照符号９２０ｂである。この状態はどのクエリでも使用可能である。例えば、他のクエリは特定のレベルを完了するための試行回数にすることができる。レベル状態は、その後者のクエリと同様に状態あたりの収益の金額を伴うクエリにおいて使用することができる。

ある状態に関する特定の値が変化すると、その状態データストア内の値が更新されることを認識されたい。

スクリプトは、デプロイされると、関連するクエリについての必要なイベント９３０を出力することになる。これらのイベントは、そのイベントの適切なコンシューマに通知される。ある実施形態では、全てのイベントは所与のコンシューマに渡され、そのコンシューマは不要なイベント、即ち、そのイベントのコンシューマに関連しないイベントを廃棄し得る。他の実施形態では、イベントのコンシューマが必要とするイベントのみがそのコンシューマに提供され得る。

図９では、イベントのコンシューマのいくつかの例は、アグリゲータ９３４、出力９３２及び／又は任意の他の適切な機能を含む。イベントのコンシューマは、その後、必要な出力を提供するためにスクリプトを実行することになる。例えば、アグリゲータの場合、受信したイベントからのデータを合計することができる。

更なるクエリをサポートするスクリプト９２５は、ユーザ区分９１５のそれぞれによってブロードキャスト及び受信され、それによりデプロイされ得る。これらのスクリプトは、既存の状態情報を使用することができるか又は受信した情報から必要な状態情報を記憶させることができる。

このようにして、実施形態によりアナリティクススクリプトがライブストリーム上で実行可能となる。従来のアプローチでは、所与の時間間隔でデータが記憶され、その後、いくつかのスクリプトが、記憶されているデータに対して実行されて単一のクエリが達成されるというウィンドウアプローチが必要となる場合がある。これは、特に、多くの異なるクエリが実行されている場合、リソース集中型になるおそれがある。

ある実施形態の利点の１つは、イベントが１回だけ読み込まれ、様々なスクリプトがユーザ区分に送られることである。従って、イベントは、１回読み込まれるが、２つ以上のスクリプトによって使用される。これは、デプロイされたアプリケーション（スクリプト）のそれぞれについて独立にデータを読み込むことができる他のリアルタイプ手法とは異なるものである。

実行され得るクエリの他の例はテストモードに関する。テストモードにはテストモード識別子を割り振ることができる。そのテストモード識別子を状態情報として記憶することができ、１つ以上の様々なタイプのイベントをそのテストモード識別子とともに出力することができる。

従って、ある実施形態により、実行されている様々なクエリ又はスクリプト間で状態を共有することが可能となる。

着信イベントはタイムスタンプを含むことができる。代替的に又は追加的に、出力イベントがタイムスタンプを含んでもよい。ＲＢＥＡスクリプトがエンジン上でどのようにデプロイ／実行されるかについての詳細を示す概略図である図７を参照する。ユーザ状態は、状態更新部７００により定義された更新機能及び新たに受信したイベントに基づいて更新される。ユーザ状態が変化した場合、（ユーザスクリプトがこのような状態変化に対するリスナとして登録されている場合は）コールバックトリガ部７０２によって１回以上のコールバックをトリガすることができる。状態を更新して可能なコールバックをトリガした後、プロセスイベントメソッドは実行プロセッサ７０４によって実行される。フィールド更新部、コールバックトリガ部及び実行プロセッサは、図９の区分９１５の機能に対応している。ウェブフロントエンド部７１０は、スクリプトを作成してデプロイすることを可能にするように構成される。集計計算部７０６は、結果の集計を提供するように構成され、図９の集計機能９３４に対応している。

ある実施形態では、状態更新部は、定義された更新機能に応じて、集計計算部７０６への入力を提供することができる。状態更新部７００、コールバックトリガ部７０２、集計計算部７０６及び実行プロセッサ部７０４の１つ以上は、出力書き込み部への出力を提供するように構成される。出力書き込み部７０８は、ウェブインターフェース部（web interface part）７１０の出力部への出力、及び／又は、例えば、メッセージブローカ出力、リレーショナルデータベース管理システム出力及び／又はファイル出力などの１つ以上の出力を提供するように構成される。この出力書き込み部及び集計計算部は、図９の出力９３２、アグリゲータ９３４及び他の機能９３６に対応するものであってもよい。

ある実施形態では、以下の４つの主な計算段階が存在し得る。
１．イベントストリームを読み込み新たにデプロイされたスクリプトを受信すること。
２．ユーザ状態を更新し、ユーザ定義のコールバックをトリガして、デプロイされたスクリプトのプロセスイベントメソッド（processEvent methods）を実行すること。
３．スクリプトによって生成されたウィンドウ集計を計算すること。
４．選択された１つ以上のフォーマットに出力を書き込むこと。

次に、これらの段階のそれぞれについてより詳細に述べる。

イベント及びスクリプトを読み込むこと。ライブイベントストリームは、イベントに当該イベントが発生したカテゴリ又はフィード名をタグ付けするコンシューマによって読み取られる。これにより、ユーザは、そのスクリプトを実行しているときにどのカテゴリ又はフィード名を聴取したいかを自由に決定することが可能となる。ユーザアイデンティティによってキーが付けられたイベントストリームからキー付きストリームを作成することができる。

スクリプトを、ウェブフロントエンドから、単純なイベントとして、メッセージブローカを介してテキストフォーマットで受信することができ、スクリプトは適切なEventoProcessorインターフェースに構文解析される。新たなスクリプトを、すでに実行中のジョブ内でホットデプロイすることができる。特に、スクリプトは、システムが他のスクリプトを実行している間に、ユーザ区分によって受信され、デプロイされ得る。スクリプトが受信されると、スクリプトが既存の記憶された状態のいずれかを使用するか否か又はスクリプトが何らかの他の状態を必要とするか否かを確認するためのチェックが実行される。新たなスクリプトが記憶されていない状態を必要とする場合、システムは、この新たな状態が、受信したイベントから決定され、上記データストアに記憶されるように構成される。新たなスクリプトをスクリプトストリームで受信することができる。これは、一般に、イベントストリームとは異なるものである。但し、ある実施形態では、イベントがスクリプトと同じストリーム内にある可能性がある。

実施形態は、第１のユーザセット用のマシン、第２のユーザセット用の更なるマシンなどを設けることができるという点で、スケーラブルであってもよい。実施形態では、同じマシンの区分のそれぞれに同じスクリプトがデプロイされる。ある実施形態では、様々なマシンに同じスクリプトがデプロイされる。

スクリプトは、様々なマシンにブロードキャストされ、そのマシン上でローカルにコンパイルされてもよい。

ある実施形態では、１つ以上のステートレススクリプトは１つ以上の状態ベースのスクリプトと並行して実行可能である。これらのスクリプトは同じマシン及び／又は区分上で並行して実行可能である。他の実施形態では、ステートレススクリプトは状態スクリプトとは別個に実行可能である。

ある実施形態では、同じスクリプトをリアルタイムデータだけでなく記憶済みデータについても実行することができる。これらのスクリプトは同時に実行することができ、リアルタイム処理とデータの処理の結果同士を比較することができる。

ある実施形態では、１つ以上のスクリプトの実行に関連する複数のランタイムメトリクスを決定することができる。これらのメトリクスは、スクリプトを実行するのに要する時間、どの状態がアクセスされているか、いずれかの状態がアクセスされているか否か、及び、任意の他の適切なメトリクスの１つ以上を含むことができる。これらのランタイムメトリクスを、スクリプトがどのようにデプロイされるか及び／又はそのスクリプトをデプロイしているマシンによってサポートされるユーザの数を制御するのに使用することができる。ランタイムメトリクスは、特定のスクリプト及び／又はあるスクリプトセットに関するものであってもよい。

状態を計算してスクリプトを実行すること。ユーザ状態は、スクリプトが実行される同じオペレータ内で計算されて、キー値状態抽象化とともにデータ局所性が活用される。このため、イベントストリーム及びユーザスクリプトの両方をイベントとして受信するオペレータが使用される。ユーザスクリプトはブロードキャストされてもよい。

新たなイベントの場合、すでにデプロイされているＲＢＥＡスクリプトのprocessEventメソッドが呼び出される。新たなスクリプトの場合、これらは、オペレータの内部でホットデプロイすることができ、その後のイベントについて実行されることになる。

このオペレータはマップオペレータであってもよい。以下のクラスは、実行ロジックを単純化した実施を示している。
//新たなクラス"RBEAProcessor"（メソッド及び変数）を定義。
class RBEAProcessor
//このクラスは標準メソッド"RichCoFlatMapFunction"を拡張する。
//Flatmapフラットマップは、１つの入力を受信し、０又は１以上の出力を生成可能なオペレータである。コフラットマップ（CoFlatMap）は、２つのストリームからのイベントを処理し、様々なメソッド（フラットマップ1/2）をイベントがどのストリームから来たかに基づいてトリガすることを意味する。
//フラット化により複数のリストのリストをリストに変換する。
//例えば、リスト(リスト(1,2,3), リスト(2,6,8))は１回のフラット化でリスト(1,2,3,2,6,8)になる。
extends RichCoFlatMapFunction<Event, Deploymentinfo, BEA>{
//現行ユーザについて計算されたフィールド（情報）。
ValueState<Map<String, Object>> = userStates;
//詳細については省略。
//タプルは順序付けられたリストであり、フラットマップ1はイベントデータを取得し、現行ユーザに関する情報を更新。
public void flatMap1(Event event, Collector<BEA> out){
//現行ユーザについて状態を更新。
Map<String, Tuple2<?, ?>>updatedFields = updateFields(event, out);
//ユーザ状態が変化した場合、情報を送り、チェーン（chain）にバックアップ（back up）。
//どのフィールドが変化した場合でもそれに基づいて更新コールバックをトリガ。
triggerUpdateCallbacks(updatedFields, out);
//ユーザスクリプトを実行。
//ユーザスクリプトのprocessEventメソッドを呼び出す。
executeScripts(event, out);
}
//フラットマップ2と名付けられた新たなメソッド。
public void flatMap2(DeploymentInfo info, Collector<BEA>out){
//"proc"と名付けられたイベントプロセッサをメモリ内に作成（イベントプロセッサのインスタンスを生成）。
EventProcessor proc = info.createProcessor();
//プロセッサをプロセッサのリストに追加。
addProcessor(proc);
//プロセッサを開始（プロセッサの初期化メソッドを呼び出し）。
initializeProcessor(proc);
｝
｝

オペレータは、新たなイベントを受信すると、状態バックエンドから現行ユーザ状態を読み出し、状態を更新し、その後、現行カテゴリなどを聴取する全てのスクリプトを実行する。状態バックエンドは状態を維持（persist）するのに使用され、好ましくはスケーラブルである。バックエンドは埋め込み可能なパーシステント（persistent）キー値ストアであってもよい。

スクリプトの実行中、ＡＰＩメソッドに対するコールの多くは、出力コレクタ上に収集される出力エレメントに直接変換される。例えば、ユーザがそのスクリプトにおいてoutput.writeToFile(fileName, myData)を呼び出すと、オペレータは、シンクがユーザデータを適切な出力フォーマットに書き込む必要があり得るという必要な情報をコード化する出力を提供する。

様々なタイプのＡＰＩコール（アグリゲータ、リレーショナルデータベース管理システム出力、メッセージブローカ出力など）は、当然、結果的に様々な出力情報をもたらすことになるが、一般に、ダウンストリームオペレータがそれらの取り扱い方を知るのに十分な情報を含んでいる。

オペレータは、障害に関する通知など、現在デプロイされているプロセッサに関する何らかの情報を生成することができる。これは、すべてのサブタスクから障害のあるスクリプトを除去するのに使用される。これは、代替的に又は追加的に、ユーザが自分のスクリプトを修正できるようにフロントエンドにエラーを報告するのに使用されてもよい。

コフラット（co-flat）マップオペレータは、終了時に、データ出力、集計及びジョブ情報という主な３つのタイプの出力を生成する。このフラットマップオペレータは、チャネルによって放出された各項目に１つの機能を適用し、そのように入手した項目を新しいチャネルとして返す。マッピング機能が項目のリストを返す場合はいつでも、このリストは、単一の項目のそれぞれが自動的に放出されるようにフラット化される。コオペレータ（cooperator）により、ユーザは異なるタイプの２つのデータストリームを共同で変換することができ、共有状態を有するストリームを共同で操作するための簡単な手法が提供される。これは、データタイプが異なるためにユニオンが適切ではない場合又はユーザが個々のエレメントの起点の明示的なトラッキングを必要とする場合に、共同ストリームの変換をサポートするように設計されている。

ウィンドウ集計を計算すること。ウィンドウイング機能は、メイン処理オペレータから出てくるアグリゲータ出力について実際の集計を実行するのに使用される。

受信した情報は、（job_id, aggregator_name, output_format, window_size, value）という形式となる。これは単なる例示であり、ある実施形態では、情報内の１つ以上のデータを省略可能であることを認識されたい。ある実施形態では、代替的に又は追加的に、１つ以上の他のデータが提供されてもよい。

ＲＢＥＡは、合計アグリゲータ、カウンタ及び／又はカスタムアグリゲータをサポートすることができる。

ある実施形態では、ウィンドウ集計の計算が提供される。このウィンドウは、イベントから抽出されたイベント時間に基づいて処理され得る。ある実施形態では、キーあたりの様々なウィドウサイズがデータフローで提供される。他の実施形態では、固定されたサイズのウィンドウを使用することができる。

ある実施形態では、適切な振る舞いのために消費されたデータに対して直接作用する着信イベントストリームについて、タイムスタンプエクストラクタ（timestamp extractor）が定義される。

様々なウィンドウサイズをオンザフライ（on the fly）で作成するために、フレキシブルなウィンドウメカニズムを、ウィンドウアサイナ（window assigner）を定義するのに使用することができる。ウィンドウアサイナは、ユーザ定義のアグリゲータウィンドウに基づいて、各要素を適切なバケットに置くものである。

これを実行するために、タンブリングイベント時間ウィンドウアサイナが拡張される。
//"TumblingEventTimeWindows"を拡張する"AggregtionWindowAssigner"と名付けられた新たなクラスを作成。
class AggregtionWindowAssigner extends TumblingEventTimeWindows{
//（他のクラスによって容易にアクセス可能な）公用メソッド"AggregtionWindowAssigner"が関数"super"を呼び出す。
public AggregtionWindowAssigner(){
super(0);
}
//標準的な振る舞いを修正。
＠Override
//公用メソッド"assignWindows"が"Collection<TimeWindow>"を返す。
public Collection<TimeWindow>assignWindows(Object in, long timestamp){
//BEAデータフォーマットにおいてアグリゲート入力オブジェクト"in"を取得。
BEA aggregateInput = (BEA) in;
//アグリゲート入力のウィンドウサイズを取得。
long size = aggregateInput.getWindowSize();
//タイムウィンドウの開始時間及び終了時間を計算。
long start = timestamp - (timestamp % size);
long end = start + size;
//ウィンドウの開始時間及び終了時間を返す。
return Collections.singletonList(new TimeWindow(start, end));
}
}

これが実行されると、ウィンドウ低減動作が実行され、各ウィンドウ内のアグリゲータ値を合計し、それを適切な出力に送ることができる。

出力を書き込むこと。ユーザは、１つの出力フォーマット又は複数の異なる出力フォーマットへの出力を、それらの処理スクリプトにおいて行うことができる。出力ＡＰＩメソッドの１つを呼び出すことによって生成された出力レコードのそれぞれは、選択された出力フォーマットに関するいくつかのメタデータを保持することになる。例えば、以下のものがある。
ファイル出力：ファイル名
テーブル出力：テーブル名
メッセージブローカ：カテゴリ名

受信したイベントをこれらに付加されたメタデータを使用して書き込むことになる各出力フォーマットについて１つのオペレータが存在し得る。

これらのオペレータは、生成された出力をユーザに対して示すことが可能となるように、ウェブフロントエンドに関する何らかの情報を生成することができる。例えば、新たな出力ファイルに対して第１のレコードが受信されると、実行中のスクリプトに関してそのユーザにこのファイルを表示できるように、ウェブフロントエンドに関する何らかのメタ情報を出力する。

データ処理パイプラインを示す図８Ａ、図８Ｂを参照する。データ処理パイプラインの特徴のうちのいくつかは、ウェブフロントエンドと通信可能なように及び／又はスクリプト障害をロバスト方式で取り扱うように構成される。

図８Ａ、図８Ｂはデータ処理パイプラインを記述している。データ処理パイプラインは、いくつかのデータソース及び機能オペレータを含むことができる。データ処理パイプラインを通って遷移するデータは、イベント情報、ユーザ情報、アグリゲータ情報、及び反復子情報の少なくとも１つを含むことができる。

以下のものは一般に図９のイベント及びスクリプトストリームに対応させることができる。データソースＩＤ＝３は、ジョブデプロイメントに基づくソースを備え、オペレータＩＤ＝４にデータを提供することができる。オペレータＩＤ＝４はタイムスタンプ及びウォーターマークの少なくとも１つを取り扱う。オペレータＩＤ＝４はオペレータＩＤ＝５にデータを出力することができる。オペレータＩＤ＝５はオペレータＩＤ＝４からデータを受信することができる。オペレータＩＤ＝５は読み込みプロセッサを取り扱う。データソースＩＤ＝１は、イベントデータに基づくソースを備え、オペレータＩＤ＝２にデータを出力することができる。オペレータＩＤ＝２はイベントをラップする。データソースＩＤ＝−１は、例えば、カウント目的に使用可能な反復ソースを提供する。

オペレータＩＤ＝９はイベントプロセッサを実行する。これは図９のブロック９１５に対応させることができる。オペレータＩＤ＝９は、オペレータＩＤ＝２、オペレータＩＤ＝５及びデータソースＩＤ＝−１の少なくとも１つからデータを受信することができる。オペレータＩＤ＝９は、データソースＩＤ＝１、データソースＩＤ＝３及びデータソースＩＤ＝−１の少なくとも１つから生じたデータとのインターフェースをとることができる。オペレータＩＤ＝９はデータ出力を提供することができる。オペレータＩＤ＝９は、オペレータＩＤ＝１０及びオペレータＩＤ＝１１の少なくとも一方にデータを渡すことができる。

オペレータＩＤ＝１０はプロセッサ情報をフィルタリングすることができる。即ち、オペレータＩＤ＝１０は、フィルタ条件に基づいて選択的に、データ処理パイプラインにおいて順方向に情報を送ることができる。オペレータＩＤ＝１０のフィルタ条件は予め定められた機能であってもよい。オペレータＩＤ＝１０はオペレータＩＤ＝３４及びオペレータＩＤ＝４３の少なくとも一方にデータを提供することができる。オペレータＩＤ＝３４は障害をフィルタリングすることができる。より詳細には、オペレータＩＤ＝３４は、データ処理パイプラインにおけるデータの処理中にエラーが発生したか否かを判定するのに使用され得る。オペレータＩＤ＝３４はデータ出力を提供することができる。オペレータＩＤ＝３９はオペレータＩＤ＝３４及びオペレータＩＤ＝３７の少なくとも一方からデータを受信することができる。オペレータＩＤ＝３９はデプロイメント情報について操作することができる。オペレータＩＤ＝３９は出力を提供することができる。データシンクＩＤ＝−２は反復シンクを提供することができる。データシンクＩＤ＝−２はオペレータＩＤ＝３９からデータを受信することができる。オペレータＩＤ＝１１はオペレータＩＤ＝９からデータを受信することができる。オペレータＩＤ＝１１は、データをフィルタリングすることができ、例えば、ＢＥＡデータをフィルタリングすることができる。オペレータＩＤ＝１１は、オペレータＩＤ＝１５、オペレータＩＤ＝２８、オペレータＩＤ＝３２及びデータシンクＩＤ＝２６の少なくとも１つにデータを提供することができる。オペレータＩＤ＝１５は集計を提供することができる。より詳細には、オペレータＩＤ＝１５はバケットアグリゲータを提供することができる。オペレータＩＤ＝２８はファイル出力を提供することができる。オペレータＩＤ＝２８はオペレータＩＤ＝４３にファイル出力を提供することができ、ファイル出力データは、トランザクションデータなどのイベントデータを少なくとも含むことができる。オペレータＩＤ＝３２は出力を提供することができる。データシンクＩＤ＝２６は出力を提供することができる。オペレータＩＤ＝１５はオペレータＩＤ＝３６にデータを提供することができる。オペレータＩＤ＝３６は１秒あたりの集計を提供することができる。オペレータＩＤ＝１５はオペレータＩＤ＝３１にデータを提供することができる。オペレータＩＤ＝３１はアグリゲータ出力を提供することができる。オペレータＩＤ＝１５はオペレータＩＤ＝２８にデータを提供することができる。オペレータＩＤ＝１５はオペレータＩＤ＝３２にデータを提供することができる。オペレータＩＤ＝１５はデータシンクＩＤ＝２６にデータを提供することができる。オペレータＩＤ＝３６はオペレータＩＤ＝３７にデータを提供することができる。オペレータＩＤ＝３７は、１秒あたりの集計（AggregatesPerSec）の値が大きすぎる場合にインジケータを提供することができる。オペレータＩＤ＝３７は、１秒あたりの集計の数が大きすぎる場合に障害を起こし得る。オペレータＩＤ＝４３は、オペレータＩＤ＝３７、オペレータＩＤ＝３１、オペレータＩＤ＝２８及びオペレータＩＤ＝３２の少なくとも１つからデータを受信することができる。オペレータＩＤ＝４３はジョブ情報を作成することができる。データシンクＩＤ＝４４はフロントエンドにプッシュすることができる。より詳細には、データシンクＩＤ＝４４は、シンク：フロントエンドへのプッシュを提供することができる。データシンクＩＤ＝４４はオペレータＩＤ＝４３からデータを受信することができる。メイン処理オペレータ（EventProcessorの実行）は、スクリプトによって生成された実際の処理イベントと、デプロイメント／障害などに関するジョブ情報という２つのタイプのイベントを出力するように構成されている。

スクリプト内のエラーに関する情報を、より容易なデバッグ用にウェブフロントエンド上に示すことができる。

出力ハンドリングは、新たに作成されたファイル／テーブル／情報をウェブフロントエンドに転送するフラットマップオペレータで行われ得る。

反復ストリームを、あるサブタスクから他のサブタスクにジョブ障害を伝搬するのに使用することができる。

各スクリプトが出力に送るイベントの数が監視される。生成するイベントが多すぎるスクリプトは、システムのクラッシュを回避するのに役に立たない。

ウェブインターフェースとジョブとの間で通信プロトコルを使用して、２つのシステムを切り離すことができる。この通信プロトコルは、任意の適切な通信プロトコル又はメッセージブローカ通信プロトコルであってもよい。

ＲＢＥＡは、動作の詳細に関する知識を持つ必要なしにライブストリームについて複雑なイベント処理を容易に実行するのに使用可能なツールを提供する。

ＲＢＥＡスクリプトは、ランタイムアプローチで管理され実行されてもよい。ランタイムアプローチでは、処理（スクリプト実行）とデプロイされたスクリプトのライフサイクル管理との両方を担当する単一のストリーム処理ジョブによってイベント及びスクリプトデプロイメントが扱われる。

ある実施形態では、ユーザデバイス上でプレーされているゲームであって、コンピュータで実行されるゲームについてイベントデータを収集することができる。イベントデータは、レベルがクリアされたこと、プレーヤがゲームのプレーを開始したこと、特定のブースタが使用されたことなどの発生した何か（イベント）に関するデータを含むことができる。イベントデータは、また、ユーザアイデンティティ、デバイスエンティティ、ユーザの位置、プレーされているゲーム及び／又は同様のものなどの関連情報を含むことができる。イベントデータは、イベントが発生したときにプレーヤがどのくらいのライフを残しているかなどのイベント発生時点におけるゲームに関するコンテキスト情報を含むことができる。収集したイベントデータは、上記のデータ及び／又は他のあらゆる適切なデータの任意の１つ以上を含むことができる。

ある実施形態は結合機能（join function）を実行可能なようにすることができる。一般に、結合機能は、データベース内の２つのエントリが共通結合（common join）又はキー値を共有する場合にそれら２つのエントリを「結合」することを可能にする。典型的に、各イベントはデータベースに記憶され得る。これは、また、そのイベントに関連するタイムスタンプを含むことができる。

例えば、データベースエントリの１行目がユーザの国とともにユーザＩＤを有する簡単な例について検討する。これは１つのイベントで提供された可能性がある。データベースの他の行（同じテーブル内又は異なるテーブル内）はユーザＩＤ及びデバイス情報を含むエントリを有する可能性がある。特定のユーザについての国及びデバイスを知ることが望ましい場合、結合機能を、ユーザＩＤ値という共通キーを使用して２つのエントリを結合するのに使用することができる。

与えられたこの例は、国及びデバイスという属性（次元と呼ばれることもある）の値が変化するのが遅いという点で比較的簡単な例である。従って、これらのイベントは次元又は属性であるとみなすことができる。上記の例はゆっくり変化する次元である。しかしながら、次元又は属性が急速に変化する場合、これはより複雑なものになる。これは、次元又は属性値が変更されるたびに余分なエントリがデータベースに追加されるからである。

結合クエリは、従来のデータベース上で実行される場合、時間的な考慮事項を考慮に入れる必要があるときに非常に複雑なものになる。例えば、ユーザがいつインゲームアイテムを購入したか、ゲーム内で前に何が起きていたか、即ち、その購入を行う前に１つ以上の属性の値が何であるかを判断する必要がある場合がある。従来のデータベースアプローチを使用することは、各エントリに関連するタイムスタンプの使用及び現行エントリのタイムスタンプとの比較を必要とするであろう。このようなアプローチはデータベースのサイズに依存してより複雑なものになる。特に、１つ以上の属性が頻繁に変化する場合、データベースのサイズは比較的大きなものとなり得る。

上述したＲＢＥＡの構成の少なくともいくつかを使用すると、結合機能を使用してデータベースを問い合わせる（querying）ことよりも簡単に結合コンセプトを実現することが可能になる。結合タイプのクエリはライブデータについて実行できることを認識されたい。代替的に、データベースに記憶されているデータは、ＲＢＥＡ装置に入力可能なイベントの１つ以上のストリームに変換することができる。

従って、ある実施形態では、以上で説明したものなどのイベントストリームがＲＢＥＡ装置で受信される。このストリームは、イベントのライブストリームになるか又はデータベース内の記憶済みデータから再現されたイベントのストリームとなり得る。

受信したイベントは、属性の値とともに共通キー又は結合キーを含むことができる。この共通キーは、例えば、ユーザＩＤであってもよい。但し、これは例示であり、イベントを結合するための任意の他の適切な共通キーが使用可能であることが認識される。

あるタイプのイベントは、「事実」ストリームとみなされてもよく、１つ以上の他のタイプのイベントは、変化し得る属性又は次元のストリームである。「事実」ストリームとみなされるイベントを、実行されているスクリプトのそれぞれによって決定することができる。１つのイベントは、１つのスクリプトによって事実とみなされ、他のスクリプトによって変化する属性又は次元とみなされる場合がある。

受信した各イベントは記憶される。この点に関しては、各イベント属性は上述した状態に類似しているとみなすことができる。各属性又は各次元の現行値が記憶される。受信したイベントの全てを記憶することができる。例えば、ゲームレベルが変化するたびに、そのゲームレベルの次元又は属性が記憶され得る。これにより、そのユーザについて記憶されている前のゲームレベル値が上書きされ得る。同様に、ゲームスタートイベント、ゲーム完了イベント又は任意の他の適切なイベントが発生した場合、関連データが記憶される。事実イベントを受信すると、１つ以上の他の属性又は次元の値がキャプチャされる。キャプチャされたイベントは集計された出力として出力され得る。これは、ユーザＩＤ（又は他の共通キー）及び／又は事実イベントを更に含むことができる。属性及び／又は事実イベントの現行値の１つ以上をリセットすることができる。他の実施形態では、属性及び／又は事実イベントの現行値は、更新された現行の属性値の受信に応答して更新されるだけであってもよい。

ある実施形態では、使用可能な属性の全てが出力される。

「事実」が、例えば、特定のインゲームアイテムの購入であってもよい例について検討する。１つ以上の他のイベントの値が、キャプチャされ、上述した機能のいずれかによって使用可能な出力を提供するのに使用される。キャプチャされた出力は共通キー値及び／又は「事実」の値を含むことができる。他のイベントは、ゲームレベル、ゲームスタート、使用したゲームブースタなどの任意の他の適切なゲームイベントにすることができる。

図９に関して記載した構成のコンテキストでは、１つ以上の属性からなる１つのセットに関する属性値がデータベースに記憶される（これらの属性値の１つ以上を１つ以上の他のスクリプトに関する状態とみなすことができる。）。ある実施形態では、単一のスクリプトを実行して、この結合機能を提供することができる。

従って、ＲＢＥＡ機能を、アグリゲータ又は任意の他の適切な出力に出力される豊富なイベントを作成するのに使用可能であることが分かる。

ある実施形態では、状態を維持することに加えて又はその代替として、イベントタイプ／次元のそれぞれ又は少なくとも１つに関する最新データが記憶される。

ある実施形態は、効率的な方式でストリーム結合の作成を可能にする。

一例では、購入、ゲームスタート及びデバイス情報イベントを含むストリームの場合、購入をゲームスタート及びデバイス情報と組み合わせて、レベル及びデバイスモデルごとの購入を含む集計出力を得ること、及び／又は、様々なイベントからの属性を有する「より豊富な／幅広い」イベントを提供する出力を得ることができる。それから、同じセマンティクスを、例えば、購入と為替レートとを結合するのに使用することができる。

コードは、実行されると、入力データに基づいて必要なクエリのための出力を提供することになる。コードを、１つ以上のメモリと協働する１つ以上のプロセッサ上で実行することができる。コードは、その処理を提供する同じ少なくとも１つの装置上で及び／又は少なくとも１つの様々な装置上で実行することができる。装置は少なくとも１つのサーバなどであってもよい。

以上では、方法及びデバイスの様々な実施形態が記載されている。このような実施形態は、任意の適切な回路で実現されている装置において実現可能であることを認識されたい。ある実施形態は、少なくとも１つのメモリと少なくとも１つのプロセッサによって実現することができる。メモリはメモリ回路によって提供することができ、プロセッサはプロセッサ回路によって提供することができる。ある実施形態は、少なくとも１つのプロセッサ上で実行されるコンピュータプログラムによって提供され得る。コンピュータプログラムは、少なくとも１つのメモリに記憶されると共に少なくとも１つのプロセッサ上で実行可能な、コンピュータで実行される命令を含むことができる。

一般に、様々な実施形態は、ハードウェア若しくは専用回路、ソフトウェア、ロジック、又は、これらの任意の組み合わせによって実現することができる。本発明のいくつかの態様はハードウェアで実現することができ、他の態様は、コントローラ、マイクロプロセッサ、又は、その他のコンピューティングデバイスによって実行可能なファームウェア又はソフトウェアで実現することができるが、本発明はこれらに限定されるものではない。本発明の様々な態様はブロック図、フローチャートとして又は何らかのその他の図表現を使用して例示され記載されてもよいが、本明細書に記載されているこれらのブロック、装置、システム、技法又は方法は、限定されない例として、ハードウェア、ソフトウェア、ファームウェア、専用回路若しくはロジック、汎用ハードウェア若しくはコントローラ、その他のコンピューティングデバイス、又は、これらの何らかの組み合わせで実現できることは十分理解される。ソフトウェアは、メモリチップ又はプロセッサ内に実現されるメモリブロックなどの物理的媒体上、ハードディスク又はフロッピーディスクなどの磁気媒体上、並びに、例えば、ＤＶＤ及びそのデータ変形例及び／又はＣＤなどの光学媒体上に記憶することができる。

上記の説明は、模範的かつ限定されない例として、本発明の模範的な実施形態の完全かつ有益な説明を提供している。しかしながら、様々な変更例及び適応例は、添付図面及び特許請求の範囲とともに読んだ時に上記の説明を考慮すれば当業者には明らかとなり得る。しかしながら、本発明の教示のこのような変更例及び同様の変更例はいずれも、依然として特許請求の範囲に定義されている本発明の範囲内に入るであろう。実際に、前述の他の実施形態のいずれかのうちの１つ以上の組み合わせを含む更なる実施形態が存在する。

Claims (21)

1. 複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信すること、
   識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、及び、
   複数の異なるスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも２つの異なるスクリプトによって使用される、前記複数の異なるスクリプトを実行すること、を含む方法。
2. 複数の第２のデータセットの第２のストリームを出力することを含み、少なくとも１つの第２のデータセットが少なくとも２つの異なるイベントに関する情報を含むものであり、前記少なくとも２つの異なるイベントが前記第１のストリームにおける様々な第１のデータセットで受信されたものである、請求項１に記載の方法。
3. 少なくとも１つの更なるスクリプトを、その後、前記複数の異なるスクリプトが実行されている間に受信して、前記複数の異なるスクリプトに加えて前記少なくとも１つの更なるスクリプトを実行することを含む、請求項１又は請求項２に記載の方法。
4. 前記少なくとも１つの更なるスクリプトについて、前記複数のスクリプトの少なくとも１つについて記憶されている少なくとも１つのイベントに関する情報を前記少なくとも１つの更なるスクリプトが使用するか否か、又は、前記少なくとも１つの更なるスクリプトについて少なくとも１つの更なるイベントに関する情報を記憶すべきか否かを判定し、前記使用すると判定した場合又は前記記憶すべきと判定した場合に、識別子のそれぞれについて前記少なくとも１つの更なるイベントに関する情報を記憶することを含む、請求項３に記載の方法。
5. 前記複数の第１のデータセットの第１のストリームが第１のエンティティにて受信されるものであり、複数の第２のデータセットの第２のストリームが第２のエンティティに出力されるものである場合に、前記方法が、
   複数の第３のデータセットの第３のストリームを第３のエンティティにて受信することであって、第３のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第３のデータセットが様々な識別子に関連付けられるものであると共に様々な第３のデータセットが様々なイベントに関する情報を有するものである、前記複数の第３のデータセットの第３のストリームを第３のエンティティにて受信すること、
   識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、
   複数の異なるスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも２つの異なるスクリプトによって使用される、前記複数の異なるスクリプトを実行すること、及び、
   前記第３のエンティティから前記第２のエンティティに複数の第４のデータセットの第４のストリームを出力すること、を更に含み、
   少なくとも１つの第４のデータセットが少なくとも２つの異なるイベントに関する情報を含むものであり、前記少なくとも２つの異なるイベントが前記第３のストリームにおける様々なデータセットで受信されたものである、請求項２に記載の、請求項３が請求項２を引用する場合の請求項３に記載の、又は、請求項４が、請求項３が請求項２を引用する場合の請求項３を引用する場合の請求項４に記載の方法。
6. 前記第２のストリーム及び前記第４のストリームのデータにデータを集約することを含む、請求項５に記載の方法。
7. 前記少なくとも１つのイベントに関する情報を記憶することが、少なくとも１つの他のイベントにとって有効となり得る１つ以上のイベントに関する情報を記憶するものである、請求項１〜請求項６のいずれか１つに記載の方法。
8. 前記イベントに関する前記情報を処理して、当該処理された情報を前記イベントに関する前記情報としてストアに記憶することを含む、請求項１〜請求項７のいずれか１つに記載の方法。
9. 各識別子に関連する少なくとも１つの記憶されたイベントに関する更新された情報を受信して、前記更新された情報を記憶することを含み、前記更新された情報が前記複数のスクリプトの１つ以上のスクリプトによって使用される、請求項１〜請求項８のいずれか１つに記載の方法。
10. 各識別子に関連する更新情報を受信し、前記各識別子に関連する前記少なくとも１つのイベントに関する前記記憶された情報を読み出し、前記記憶された情報及び前記受信した更新情報を使用して更新された情報を決定し、前記識別子のそれぞれについて、前記複数のスクリプトの１つ以上のスクリプトによる使用のために前記更新された情報を記憶すること、を含む、請求項１〜請求項９のいずれか１つに記載の方法。
11. 複数の異なるデバイスから前記第１のストリームのデータセットを受信することを含む、請求項１〜請求項１０のいずれか１つに記載の方法。
12. 前記識別子が、前記第１のストリームにおける前記各データセットを提供する各デバイスに関連するユーザ、及び前記第１のストリームにおける前記各データセットを提供するデバイスの少なくとも一方を識別するものである、請求項１〜請求項１１のいずれか１つに記載の方法。
13. 前記第１のストリームにおける前記複数の第１のデータセットが、コンピュータで実行されるゲームのプレー中に生成されたイベントに関する情報を含むものである、請求項１〜請求項１２のいずれか１つに記載の方法。
14. 複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信すること、
    識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、
    少なくとも１つの第１のスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも１つのスクリプトによって使用される、前記少なくとも１つの第１のスクリプトを実行すること、及び、
    少なくとも１つの第２のスクリプトを、その後、前記少なくとも１つの第１のスクリプトが実行されている間に受信して、前記少なくとも１つの第１のスクリプトに加えて前記少なくとも１つの第２のスクリプトを実行すること、を含む方法。
15. 複数の第２のデータセットの第２のストリームを出力することを含み、少なくとも１つの第２のデータセットが少なくとも２つの異なるイベントに関する情報を含むものであり、前記少なくとも２つの異なるイベントが前記第１のストリームにおける様々な第１のデータセットで受信されたものである、請求項１４に記載の方法。
16. 前記少なくとも１つの第２のスクリプトについて、前記第１のスクリプトの少なくとも１つについて記憶されている少なくとも１つのイベントに関する情報を前記少なくとも１つの第２のスクリプトが使用するか否か、又は、前記少なくとも１つの第２のスクリプトについて少なくとも１つの更なるイベントに関する情報を記憶すべきか否かを判定し、前記使用すると判定した場合又は前記記憶すべきと判定した場合に、識別子のそれぞれについて前記少なくとも１つの更なるイベントに関する情報を記憶することを含む、請求項１４又は請求項１５に記載の方法。
17. 複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記第１のデータセットの第１のストリームを受信すること、
    識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、及び、
    前記様々なイベントのうちの所与のイベントを受信したことに応答して、それ以前に受信したイベントに関連する記憶された情報を含む出力を提供すること、
    を含む方法。
18. 前記出力が、前記所与のイベントに関する情報を更に含むものである、請求項１７に記載の方法。
19. 少なくとも１つのプロセッサと、１つ以上のプログラムに関するコンピュータコードを有する少なくとも１つのメモリと、を含むコンピュータ装置であって、前記少なくとも１つのメモリ及び前記コンピュータコードが前記少なくとも１つのプロセッサと共に、少なくとも、
    複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信すること、
    識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、及び、
    複数の異なるスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも２つの異なるスクリプトによって使用される、前記複数の異なるスクリプトを実行すること、を前記コンピュータ装置に実行させるように構成されている、コンピュータ装置。
20. 少なくとも１つのプロセッサと、１つ以上のプログラムに関するコンピュータコードを有する少なくとも１つのメモリとを含むコンピュータ装置であって、前記少なくとも１つのメモリ及び前記コンピュータコードが前記少なくとも１つのプロセッサと共に、少なくとも、
    複数の第１のデータセットの第１のストリームを受信することであって、第１のデータセットのそれぞれが識別子と少なくとも１つのイベントに関する情報とを含むものであり、様々な第１のデータセットが様々な識別子に関連付けられるものであると共に様々な第１のデータセットが様々なイベントに関する情報を有するものである、前記複数の第１のデータセットの第１のストリームを受信すること、
    識別子のそれぞれについて少なくとも１つのイベントに関する情報を記憶すること、
    少なくとも１つの第１のスクリプトを実行することであって、前記少なくとも１つのイベントに関する情報が少なくとも１つのスクリプトによって使用される、前記少なくとも１つの第１のスクリプトを実行すること、及び、
    少なくとも１つの第２のスクリプトを、その後、前記少なくとも１つの第１のスクリプトが実行されている間に受信して、前記少なくとも１つの第１のスクリプトに加えて前記少なくとも１つの第２のスクリプトを実行すること、を前記コンピュータ装置に実行させるように構成されている、コンピュータ装置。
21. 実行されたときに請求項１〜請求項１８のいずれか１つに記載の方法を実行させるコンピュータ実行可能コードを含むコンピュータプログラム。