2020-011316

本願は、２０１５年（平成２７年）９月２２日（パリ条約による優先権主張外国庁受理 ２０１４年１０月８日 米国、２０１５年７月１５日 米国、２０１５年７月１５日 米国）を国際出願日とする出願であって、その手続の経緯は以下のとおりである。

原査定の拒絶理由で引用された引用文献１には、図面とともに以下の事項が記載されている。（下線は強調のため当審で付した。引用文献２、３についても同様。）なお、当審訳は、引用文献１のファミリである特表２０１６－５１３３００号公報を参考とした。

ア 「[0002] The disclosed embodiments relate generally to data processing systems,and more specifically to techniques for processing continuous event streams using variable duration windows.

（当審訳：開示されている実施形態は、概してデータ処理システムに関し、より具体的には継続時間可変ウィンドウを用いて連続イベントストリームを処理するための技術に関する。（【０００２】））」

イ 「[0004] A number of modern applications and systems however generate data in the form of continuous data or event streams instead of a finite data set. Examples of such applications include but are not limited to sensor data applications, financial tickers, network performance measuring tools (e.g. network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like. For example, a temperature sensor may be configured to send out temperature readings. Such applications have given rise to a need for a new breed of applications that can process the data streams.

（当審訳：しかしながら、数多くの現代のアプリケーションおよびシステムは、データを、有限のデータ集合ではなく連続データまたはイベントストリームの形態で生成する。このようなアプリケーションの例は、センサデータアプリケーション、財務表示機、ネットワークパフォーマンス測定ツール（たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリング等を含むが、これらに限定されない。たとえば、温度センサを、温度測定値を発信するように構成することができる。このようなアプリケーションから、データストリームを処理することが可能な新たな種類のアプリケーションの必要性が生じた。（【０００４】））」

ウ 「[0039] An event stream has an associated schema "S", the schema comprising time information and a set of one or more named attributes. All events that belong to a particular event stream conform to the schema associated with that particular event stream. Accordingly, for an event stream (s, T), the event stream may have a schema 'S' as (<time_stamp>, <attribute(s)>), where <attributes> represents the data portion of the schema and can comprise one or more attributes. For example, the schema for a stock ticker event stream may comprise attributes <stock symbol>, and <stock price>. Each event received via such a stream will have a time stamp and the two attributes.（以下省略）

（当審訳：イベントストリームには、関連付けられたスキーマ「Ｓ」があり、スキーマは、時間情報と、名前付きの１つ以上の属性からなる一組の属性とを含む。特定のイベントストリームに属するすべてのイベントは、この特定のイベントストリームに関連付けられたスキーマに従う。したがって、イベントストリーム（ｓ，Ｔ）の場合、このイベントストリームは、スキーマ「Ｓ」を、（＜time_stamp＞，＜attribute(s)＞）として有し得る。＜attributes＞は、スキーマのデータ部分を表わし１つ以上の属性を含み得る。たとえば、株式相場表示機のイベントストリームについてのスキーマは、＜株式銘柄＞および＜株価＞という属性を含み得る。このようなストリームを介して受ける各イベントは、１つのタイムスタンプと上記２つの属性とを有する。（【００３１】））」

エ 「[0040] Fig. 1 depicts a simplified high level diagram of an event processing system 100 that may incorporate an embodiment of the present invention. Event processing system 100 may comprise one or more event sources (104, 106, 108), an event processing server (EPS) 102 that is configured to provide an environment for processing event streams, and one or more event sinks (110, 112). The event sources generate event streams that are received by EPS 102. EPS 102 may receive one or more event streams from one or more event sources. For example, as shown in Fig.1, EPS 102 receives an input event stream 114 from event source 104, a second input event stream 116 from event source 106, and a third event stream 118 from event source 108. One or more event processing applications (120, 122, and 124) may be deployed on and be executed by EPS 102. An event processing application executed by EPS 102 may be configured to listen to one or more input event streams, process the events received via the one or more event streams based upon processing logic that selects one or more events from the input event streams as notable events. The notable events may then be sent to one or more event sinks (110, 112) in the form of one or more output event streams. For example, in Fig. 1, EPS 102 outputs an output event stream 126 to event sink 110, and a second output event stream 128 to event sink 112. In certain embodiments, event sources, event processing applications, and event sinks are decoupled from each other such that one can add or remove any of these components without causing changes to the other components.

（当審訳：図１は、本発明の実施形態を組込み得るイベント処理システム１００の簡略化された高レベルの図を示す。イベント処理システム１００は、１つ以上のイベントソース（１０４，１０６，１０８）と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サーバ（event processing server）（ＥＰＳ）１０２と、１つ以上のイベントシンク（１１０，１１２）とを含み得る。イベントソースは、ＥＰＳ１０２が受信するイベントストリームを生成する。ＥＰＳ１０２は、１つ以上のイベントストリームを１つ以上のイベントソースから受信し得る。たとえば、図１に示されるように、ＥＰＳ１０２は、入力イベントストリーム１１４をイベントソース１０４から受信し、第２の入力イベントストリーム１１６をイベントソース１０６から受信し、第３のイベントストリーム１１８をイベントソース１０８から受信する。１つ以上のイベント処理アプリケーション（１２０，１２２，および１２４）をＥＰＳ１０２に導入しＥＰＳ１０２によって実行してもよい。ＥＰＳ１０２によって実行されるイベント処理アプリケーションは、１つ以上の入力イベントストリームをリッスンし、１つ以上のイベントストリームを介して受信したイベントを、入力イベントストリームから１つ以上のイベントを注目すべきイベントとして選択する処理ロジックに基づいて処理するように構成されてもよい。注目すべきイベントは次に、１つ以上の出力イベントストリームの形態で１つ以上のイベントシンク（１１０，１１２）に送信してもよい。たとえば、図１において、ＥＰＳ１０２は、出力イベントストリーム１２６をイベントシンク１１０に出力し、第２の出力イベントストリーム１２８をイベントシンク１１２に出力する。ある実施形態において、イベントソース、イベント処理アプリケーション、およびイベントシンクは、これら構成要素のうちのいずれも、他の構成要素の変更を生じさせることなく追加または除去できるよう、互いに分離されている。（【００３３】））」

オ 「[0042] An event processing application is configured to listen to one or more input event streams, execute logic (e.g., a query) for selecting one or more notable events from the one or more input event streams, and output the selected notable events to one or more event sources via one or more output event streams. Fig.1 provides a drilldown for one such event processing application 120. As shown in Fig.1, event processing application 120 is configured to listen to input event stream 118, execute a query 130 comprising logic for selecting one or more notable events from input event stream 118, and output the selected notable events via output event stream 128 to event sink 112. Examples of event sources include, without limitation, an adapter (e.g., JMS, HTTP, and file), a channel, a processor, a table, a cache, and the like. Examples of event sinks include, without limitation, an adapter (e.g., JMS, HTTP, and file), a channel, a processor, a cache, and the like.

（当審訳：イベント処理アプリケーションは、１つ以上の入力イベントストリームをリッスンし、この１つ以上の入力イベントストリームから注目すべき１つ以上のイベントを選択するためにロジック（たとえばクエリ）を実行し、選択した注目すべきイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントソースに出力するように構成される。図１は、１つのこのようなイベント処理アプリケーション１２０についてのドリルダウンを提供する。図１に示されるように、イベント処理アプリケーション１２０は、入力イベントストリーム１１８をリッスンし、入力イベントストリーム１１８から注目すべき１つ以上のイベントを選択するためにロジックを含むクエリ１３０を実行し、選択した注目すべきイベントを出力イベントストリーム１２８を介してイベントシンク１１２に出力するように構成される。イベントソースの例は、アダプタ（たとえばJMS、HTTP、およびファイル)、チャネル、プロセッサ、テーブル、キャッシュ等を含むがこれらに限定されない。イベントシンクの例は、アダプタ（たとえばJMS、HTTP、およびファイル）、チャネル、プロセッサ、キャッシュなどを含むがこれらに限定されない。（【００３５】））」

カ 「[0043] Although event processing application 120 in Fig.1 is shown as listening to one input stream and outputting selected events via one output stream, this is not intended to be limiting. In alternative embodiments, an event processing application may be configured to listen to multiple input streams received from one or more event sources, select events from the monitored streams, and output the selected events via one or more output event streams to one or more event sinks. The same query can be associated with more than one event sink and with different types of event sinks.

（当審訳：図１のイベント処理アプリケーション１２０は、１つの入力ストリームをリッスンし選択したイベントを１つの出力ストリームを介して出力するものとして示されているが、これは限定を意図したものでない。これに代わる実施形態では、イベント処理アプリケーションは、１つ以上のイベントソースから受信した複数の入力ストリームをリッスンし、モニタリングされたストリームからイベントを選択し、選択したイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントシンクに出力するように構成されてもよい。同一のクエリを２つ以上のイベントシンクに関連付け異なる種類のイベントシンクに関連付けてもよい。（【００３６】））」

キ 「[0045] Event-driven applications are rule-driven and these rules may be expressed in the form of continuous queries that are used to process input streams. A continuous query may comprise instructions (e.g., business logic) that identify the processing to be performed for received events including what events are to be selected as notable events and output as results of the query processing. Continuous queries may be persisted to a data store and used for processing input streams of events and generating output streams of events. Continuous queries may specify filtering and aggregation functions to discover and extract notable events from the input event streams. As a result, the number of outbound events in an output event stream is generally much lower than the number of events in the input event stream from which the events are selected.

（当審訳：イベント駆動型のアプリケーションはルール駆動型であり、これらルールは、入力ストリームを処理するのに使用される連続クエリの形態で表わしてもよい。連続クエリは、クエリ処理の結果としてどのイベントを注目すべきイベントとして選択し出力すべきかということを含む、受信したイベントに対して実行すべき処理を特定する命令（たとえばビジネスロジック）を含み得る。連続クエリは、データ記憶装置まで持続させて、イベントの入力ストリームの処理およびイベントの出力ストリームの生成のために使用してもよい。連続クエリは、発見すべきフィルタリングおよび集約関数を指定し入力イベントストリームから注目すべきイベントを抽出してもよい。結果として、出力イベントストリームにおけるアウトバウンドのイベントの数は通常、イベントを選択する元になる入力イベントストリームにおけるイベントの数よりも遥かに少ない。（【００３８】））」

ク 「[0046] Unlike a SQL query that is run once on a finite data set, a continuous query that has been registered by an application with EPS 102 for a particular event stream may be executed each time that an event is received in that event stream. As part of the continuous query execution, EPS 102 evaluates the received event based upon instructions specified by the continuous query to determine whether one or more events are to be selected as notable events, and output as a result of the continuous query execution.

（当審訳：有限データ集合に対して一度実行されるＳＱＬクエリと異なり、特定のイベントストリームに対してアプリケーションによりＥＰＳ１０２に登録された連続クエリは、このイベントストリーム内のイベントが受信される度に実行されてもよい。連続クエリ実行の一部として、ＥＰＳ１０２は、受信したイベントを、連続クエリが指定する命令に基づいて評価することにより、１つ以上のイベントを注目すべきイベントとして選択すべきか否か決定し、連続クエリ実行の結果として出力する。（【００３９】））」

ケ 「WINDOW-BASED PROCESSING

[0057] As another example, an event processing application may be configured to collate and process data or events for a certain time range. For example, EPS 102 may receive a temperature event stream of events comprising a "temp" attribute and an associated time. The "temp" data may indicate the temperature at the associated time. A CQL query may be formulated for such an event stream to obtain the average temperature for the previous ten seconds. The query may be specified as follows:

Select avg (temp) from temp [range 10]

The above query finds the average of the "temp" data over a range of "10", where, in this example, a range of "10" indicates 10 seconds. In other embodiments, the range may be specified using other time units such as minutes, days, or any other specified time unit. The CQL query, when executed by EPS 102, evaluates tuples received in the previous ten seconds and finds the average temperature. "Expired" tuples, or those tuples that are received previous to the indicated range (i.e., outside the 10 second window) are disregarded by the query. The CQL query thus does not need to account for and store all the received events but only process events within the last 10 second window.

（当審訳：ウィンドウベースの処理

別の例として、イベント処理アプリケーションは、ある時間範囲のデータまたはイベントを照合し処理するように構成されてもよい。たとえば、ＥＰＳ１０２は、「温度（ｔｅｍｐ）」属性および関連付けられた時間を含むイベントからなる温度イベントストリームを受信してもよい。「温度」データは、関連付けられた時間における温度を示してもよい。前の１０秒の平均温度を得るために、ＣＱＬクエリをこのようなイベントストリーム用に構築してもよい。クエリは次のように指定してもよい。

Select avg (temp) from temp [range 10]

上記クエリは、「１０」という範囲（ｒａｎｇｅ）における「温度（ｔｅｍｐ）」の平均（ａｖｇ）を発見する。この例における範囲「１０」は１０秒を表わす。他の実施形態において、この範囲を、分、日、またはそれ以外の指定された時間単位等、他の時間単位を用いて指定してもよい。このＣＱＬクエリは、ＥＰＳ１０２によって実行されると、前の１０秒で受信したタプルを評価し平均温度を見出す。「満了」タプル、すなわち示されている範囲よりも前に（すなわち１０秒ウィンドウ外で）受信したタプルは、クエリによって無視される。したがって、ＣＱＬクエリは、受信したイベントすべてを捕えて格納する必要はなく、最新の１０秒ウィンドウ内のイベントを処理するだけでよい。（【００５４】、【００５５】））」

原査定の拒絶理由で引用された引用文献２には、以下の事項が記載されている。

ア 「[0001] 本発明は、ストリームデータの処理方法及び装置に関する。」

イ 「[0017] ＜第一実施形態＞

図１は本発明の第一の実施形態における計算機システムの一構成を示すブロック図である。送信サーバ１０１～１０３はネットワーク１０４を介して、ストリームデータ処理システムを実行するストリームデータ処理サーバ１０８に接続されている。登録サーバ１０５はネットワーク１０７を介して、ストリームデータ処理サーバ１０８に接続されている。受信サーバ１１７はネットワーク１１６を介して、ストリームデータ処理サーバ１０８に接続されている。ネットワーク１０４、１０７、１１６は、イーサネット（登録商標）、光ファイバなどで接続されるローカルエリアネットワーク（ＬＡＮ）、もしくはＬＡＮよりも低速なインターネットを含んだワイドエリアネットワーク（ＷＡＮ）でも差し支えない。また、ストリームデータ処理サーバ１０８、送信サーバ１０１～１０３、登録サーバ１０５、受信サーバ１１７はパーソナルコンピュータ（ＰＣ）や、ブレード型の計算機システムなどの任意のコンピュータシステムで構成することができる。」

ウ 「[0022] まずユーザ２０４によって記述された、ストリーム及びクエリ定義２０６及び、データセットキー２０５を含む設定データは、登録サーバ１０５に格納され、登録サーバ１０５から、ストリームデータ処理サーバ１０８に送信される。そして、ストリームデータ処理サーバ１０８では、上記設定データを受信した後、クエリ登録部１１１のデータセットキー読込み部２１１において、データセットキー２０５からデータセット変換テーブル２１０及び、実行領域名参照テーブル２１５を生成する。またコンパイル部２１２において、ストリーム及びクエリ定義２０６をコンパイルし、実行木２２８を生成する。」

エ 「[0029] 図３Ａ～図３Ｃは、ストリーム及びクエリ定義２０６に含まれるストリーム定義３０１、クエリ定義３０２と、データセットキー２０５の一例を示す。図３Ａに示す３０１は、電力の「メータ」、「使用電力」、メータの「設置場所」をカラム（またはデータ項目）とする電気メータストリームの定義である。このストリーム定義３０１は、ストリームデータを構成する入力データ２０１～２０３に含まれる複数の項目を、ストリームデータ処理サーバ１０８で識別するための定義である。なお、入力データ２０１～２０３には時刻（またはタイムスタンプ）が含まれるが、本実施形態では、入力データ２０１～２０３に時刻情報が付与されていることが前提であるため、ストリーム定義３０１では定義を省略した。」

オ 「

［図：0001380409000001.jpg］

」（図２Ａ）

カ 「

［図：0001380409000002.jpg］

」（図３Ａ）

原査定の拒絶理由で引用された引用文献３には、以下の事項が記載されている。

「【００６９】

（更新後の抽象化温度）

＝｛直前の抽象化温度×（総数－１）／総数＋入力センサ値／総数｝…（１）

また、データ変換部１０３は、センサデータＤＢ１０５に格納される抽象化センサデータを用いて、別の抽象化ルールの抽象化センサデータを求めるようにしてもよい。例えば、「○県」の抽象化センサデータを求めるようにしてもよい。この場合の計算は、例えば、「○県」内の市町村単位の抽象化センサデータを計算するというように、階層的に広範囲の抽象化センサ値を計算するようにしてもよい。これは、例えば、市町村単位、県単位のセンサデータが欲しい等の統計的なアプリケーションがある場合に特に有効である。」