JP2015534683A - データ配信システム - Google Patents

Abstract

【課題】サーバ（１２０）に接続された複数のサービスプロバイダ（１１１から１１４）と、サーバ（１２０）に接続された複数のクライアント装置（１４１から１４４）とを含むデータ配信システムが提供される。【解決手段】サーバ（１２０）は、サービスプロバイダからのデータインスタンス（１２５）を保存するデータレポジトリ（１２１）と、クライアント装置ごとに状態属性の各集合（１３１から１３４）を保存するクライアントレポジトリ（１２２）とを含み、状態属性の各集合は、各クライアント装置に対するデータインスタンス（１２５）の状態を示す。【選択図】図１

Description

本発明は、データ配信システム、特に、多数のデータプロバイダからクライアント装置にデータを供給するデータ配信システムに関する。

クライアント装置は、多数の様々なデータソースにデータを要求することが多く、また、データソースは様々な形式及び品質のデータを供給する。供給されるデータの形式及び品質は、クライアントの要件に合うこともあれば、合わないこともある。

既知のデータ配信システムとして、国際公開公報第２０１２／０７３１７５号は、サービスプロバイダ側、サービスプロバイダ側に接続されたホスト側、及び、ホスト側に接続された顧客側を含むデータ配信システムを開示している。ホスト側のサーバは、サービスプロバイダ側の様々なサービスプロバイダからデータを収集し、顧客側のクライアントにデータを供給する。データは、各クライアントに関連付けられたユーザプロファイルに従って各クライアントに供給され、ユーザプロファイルは、ユーザが興味を持っているデータの種類を特定するものである。

クライアント装置の要件に合わせて様々なデータソースからデータを取り出し、クライアント装置に提示することができる、より高度なデータ配信システムが求められている。特に、データソースが、そういったデータの最新版を供給すること、クライアント装置が、データ要件を変更すること、前のバージョンのデータに対して、クライアントがどの時点でどのデータを有していたかなどを確認する必要がある監査を行うことがある。

様々なクライアント装置が様々な通信プロトコルを用いて、様々な方法でデータを列挙することがあるため、クライアント装置が、リストを保持して、サーバからの特定のデータの読み込みを要求することは、特に、クライアント装置がサーバにどんな新しいデータが存在するかわからない場合、困難である。

従って、本発明の目的は、既知の従来技術を改善することである。

本発明の第１の態様によれば、サーバに接続された複数のサービスプロバイダと、前記サーバに接続された複数のクライアント装置と、を備えるデータ配信システムが提供される。前記サーバは、前記サービスプロバイダからのデータインスタンスを保存するデータレポジトリと、クライアント装置ごとに、状態属性の各集合を保存するクライアントレポジトリであって、状態属性の各集合は、各クライアント装置に対する前記データインスタンスの状態を示す、クライアントレポジトリとを備える。

クライアントごとの状態属性の集合を用いるということは、クライアントが追跡ジョブを行うことなく、あるいは、クライアントが新しいデータインスタンスが来る予定であると考えた時に要求を送信することなく、サーバがクライアントに対して各データインスタンスの状態を追跡することができるということである。

サーバが、状態属性を用いて、データインスタンスに対してクライアント装置の動作の状態を追跡するということは、サーバは、クライアント装置が異なるデータインスタンスを識別するのにどの制御プロトコルを使用するかを把握する必要がなく、単に、状態属性が示すデータインスタンスであって、クライアント装置への読み込みがまだ成功していないデータインスタンスであればどんなデータインスタンスでもクライアント装置に送信することができる、ということである。

さらに、１つのデータレポジトリが各データインスタンスのコピーをたった１つ保存するだけで、データインスタンスを別のクライアントに複製する必要がなく、全てのクライアント装置をカバーするように維持できる。各クライアントは、状態属性の集合を介して、データレポジトリのデータインスタンスを個別に見ることができる。各データインスタンスに対して、別の状態属性をクライアントごとに保存してもよい。

好ましくは、各状態属性は、特定のデータインスタンスに関連付けられていてもよい。その後、状態属性には、クライアント装置に対するデータインスタンスの様々な状態を示す様々な値を割り当てられてもよい。

クライアント装置のうち第１クライアント装置に関連付けられた状態属性の集合内の各状態属性は、状態属性に関連付けられたデータインスタンスがクライアント装置のうち第１クライアント装置にまだ読み込まれていないことを示す値；及び、状態属性に関連付けられたデータインスタンスがクライアント装置のうち第１クライアント装置に読み込まれたことを示す値を含む、値をとってもよい。

従って、サーバ装置がどのデータインスタンスがクライアント装置にまだ読み込まれていないかをクライアント装置に知らせる場合、及び／または、クライアント装置が、新しいデータインスタンスを読み込む準備ができていることを示す場合、クライアント装置に関連付けられた状態属性の集合を用いて、クライアント装置がまだ読み込んでいないデータインスタンスをプッシュ配信してもよい。例えば、状態属性の値は、クライアントが対応するデータインスタンスをまだ読み込んでいない場合、「新規」でもよく、クライアントが対応するデータインスタンスを読み込んだ場合、「読み込み済み」でもよい。

好ましくは、状態属性の値は、サーバとクライアント装置の両方によって設定されてもよい。例えば、状態属性が「新規」に設定される場合はサーバによって設定され、状態属性が「未読み込み」に設定される場合はクライアントによって設定されてもよい。そのため、状態属性は、サーバとクライアント装置の両方が、サーバとクライアント装置との間で双方向通信を行うのに利用可能である。従って、状態属性は、サーバ及びクライアント装置が使用できる非常に単純な通信プロトコルを提供して、人を介さずにクライアント装置への新しいデータインスタンスの読み込みを自動的に連係させる。

状態属性の値は、クライアント装置によって自動的に行われるべき動作のリストを規定してもよい。例えば、クライアント装置は、状態属性の値が「新規」である場合、その状態属性に関連付けられたデータインスタンスの読み込みを自動的に開始してもよい。

妥当性チェックは、一般的に、サーバがサービスプロバイダから受信したデータインスタンスに対して実行するものであり、また、一般的に、サーバから受信したデータインスタンスに対してクライアント装置が実行することもある。サーバによって実行される妥当性チェックは、クライアントによって実行される妥当性チェックとは異なることがあるが、クライアント装置によって実行される妥当性チェックはいずれも、サーバ装置への通知なしに変更されてもよい。妥当性チェックは、例えば、データインスタンスが十分最新であるかの確認、または、データインスタンスに含まれるデータが所与の許容範囲よりも厳密に正しいと特定されるかについての確認を含んでもよい。

従って、クライアント装置のうち第１クライアント装置に関連付けられた状態属性の集合内の各状態属性は、さらに、状態属性に関連付けられたデータインスタンスが、例えば、クライアント装置のうち第１クライアント装置がデータインスタンスを読み込んだ後に行った妥当性チェックに合格しなかったため、クライアント装置のうち第１クライアント装置に拒否されたことを示す値を含む値をとってもよい。

従って、状態属性を用いて、クライアント装置は、データインスタンスがクライアント装置の妥当性チェックに合格しなかったことを自動的にサーバ装置にフラグで知らせることができる。このように、様々なクライアントは、特定のデータインスタンスがクライアントの妥当性チェックに合格しなかったことを知らせるための多数の異なる通信方法を有する必要はない。その代わりに、各クライアントに対して各データインスタンスの状態を中央ログに保持し、状態属性によってサーバ内に保持する。１つ以上のクライアントの妥当性チェックに合格しなかった結果、状態属性は、データレポジトリのどのデータインスタンスに注意が必要であるかを特定するのに用いられる。

状態属性に対応するデータインスタンスがクライアント装置の妥当性チェックに合格した場合、その状態属性の値は、例えば、クライアント装置によって、「有効」と設定されてもよい。データインスタンスがクライアント装置の妥当性チェックに合格しなかった場合、クライアントは、状態属性の値を「拒否」と設定してもよい。

好ましくは、サーバは、データフィードでサービスプロバイダからデータインスタンスを受信するように構成されてもよく、各データフィードは、データインスタンスのストリームを供給する。データレポジトリは、フィード、日付及びバージョン番号によってデータインスタンスを保存するように構成されてもよい。

サーバは、データフィードで受信されたデータインスタンスをデータレポジトリに保存する前に、例えば、データインスタンスが全て共通形式で保持されるように形式を整えるように構成されてもよい。好ましくは、クライアント装置は、サービスプロバイダが用いる様々な形式を扱わなければならないのではなく、共通形式を扱うように構成されてもよい。

データフィードの各連続するデータインスタンスは、データフィードの先行するデータインスタンスの更新情報であってもよく、データレポジトリは、連続するデータインスタンスと先行するデータインスタンスの両方を保存するように構成されてもよい。このように全てのデータインスタンスの履歴を保持することで、クライアント装置は、監査目的で、データインスタンスに関連付けられた状態属性を見ることによって、どの日付にどのデータインスタンスが利用可能であったか、及び、これらのデータインスタンスのうちどのデータインスタンスがクライアント装置によって実際に読み込まれたかを判定することができる。

好ましくは、クライアントレポジトリは、各クライアント装置にクライアントＡＰＩを提供してもよく、当該クライアントＡＰＩは、クライアント装置に対する状態属性の集合を含む。クライアントＡＰＩ（アプリケーションプログラミングインターフェース）は、例えば、どのデータフィードにクライアント装置が興味を持っているか、ひいては、データレポジトリのどのデータインスタンスについてクライアントＡＰＩが状態属性を保存すべきかといった、クライアント装置に関する他の情報を含んでもよい。

クライアントＡＰＩは、クライアント装置が、利用可能なデータフィードのリストの受信を開始することができる、リストフィード機能を提供してもよい。例えば、クライアント装置は、サーバにリストフィード要求を送信し、サーバは、クライアント装置が選択可能なデータフィードのリストをクライアント装置に返してもよい。

クライアントＡＰＩは、クライアント装置が、クライアント装置に対する更新されたデータインスタンスのリストであって、クライアント装置に対する状態属性の値に基づいたリストの受信を開始することができる、リスト更新機能を提供してもよい。

クライアントＡＰＩは、クライアント装置が、クライアント装置によって特定されたデータフィードの最新のデータインスタンスの受信を開始することができる、フェッチデータ機能を提供してもよい。例えば、クライアント装置は、サーバに特定のデータフィードを指定するフェッチデータ要求を送信し、サーバは、そのデータフィードの最新のデータインスタンスを送信してもよい。

クライアントＡＰＩは、クライアント装置が、クライアント装置によって指定された日付のデータインスタンスのリストであって、クライアント装置に対する状態属性の値に基づいたリストの受信を開始することができる、リスト履歴機能を提供してもよい。

好ましくは、クライアントＡＰＩは、クライアント装置が、リスト更新機能、フェッチデータ機能またはリスト履歴機能に関連してモードパラメータを規定することを許可してもよい。当該モードパラメータは、クライアントが当該モードパラメータに対応する状態属性値を有するデータインスタンスまたはデータインスタンスのリストの受信を望んでいることを示すものである。

例えば、クライアント装置は、サーバにリスト更新要求を送信し、当該要求は、「新規」の状態属性値に対応するモードパラメータを含み、サーバは、データインスタンスがまだクライアント装置によって読み込まれていないことを示す「新規」の状態属性値を有する全てのデータインスタンスのリストを返してもよい。

クライアント装置は、サーバにフェッチデータ要求を送信し、当該要求はモードパラメータを含み、モードパラメータは、クライアント装置が当該モードパラメータに対応する状態属性値を有するデータインスタンスの受信を望んでいることを示してもよい。

クライアント装置は、特定の日付及びモードパラメータを指定するリスト履歴要求であって、クライアント装置が当該モードパラメータに対応する状態属性値を有する日付のデータインスタンスのリストの受信を望んでいることを示すリスト履歴要求をサーバに送信してもよい。

クライアントＡＰＩは、クライアント装置が特定のデータインスタンスについての状態属性の設定を開始することができる、設定機能を提供してもよい。例えば、クライアント装置は、一旦、データインスタンスがクライアント装置の妥当性チェックに合格すれば、当該データインスタンスに関連付けられた状態属性の値を「有効」と設定する設定要求を送信してもよい。

本発明の第２の態様によれば、複数のサービスプロバイダから複数のクライアントにデータを配信するデータ配信方法が提供される。前記方法は、
前記サービスプロバイダからデータインスタンスを受信することと、
前記データインスタンスをデータレポジトリに保存することと、
前記データインスタンスに関連付けられた状態属性をクライアントレポジトリに保存することと、を含み、
前記クライアントレポジトリは、クライアント装置ごとに、状態属性の各集合を保存し、状態属性の各集合は、各クライアント装置に対する前記データインスタンスの状態を示す、方法である。

データインスタンスに関連付けられた状態属性をクライアントレポジトリに保存することは、新しいデータインスタンスが関連するクライアント装置に対応する状態属性の集合に状態属性を追加することを含んでもよい。従って、状態属性の集合が全て、全てのデータインスタンスについての状態属性を含んでいなくてもよい。状態属性の集合は、状態属性の集合に関連付けられたクライアント装置が興味を持っているデータインスタンスの状態属性を含んでいればよい。

あるいは、クライアントレポジトリの状態属性の集合が全て、データレポジトリにある全てのデータインスタンスの状態属性を含んでもよい。

本発明の実施形態を、限定されない例として、添付の図面を参照して説明する。

本発明の実施形態に係るデータ配信システムの概略ブロック図である。 図１のデータ配信システムを用いて実施されるデータ配信方法のフロー図である。 異なるクライアント装置から異なる日に受信しているデータインスタンスを示す図である。 状態属性がとり得る様々な値の状態図である。 サーバによってクライアント装置に提供されるのに適したアプリケーションプログラミングインターフェース（ＡＰＩ）の概略図である。

本発明の実施形態を図１の概略図を参照して説明する。図１は、サービスプロバイダ側１１０、サーバ１２０及びクライアント側１４０を含むデータ配信システムを示す。

サービスプロバイダ側１１０は、複数のサービスプロバイダ１１１〜１１４を含み、クライアント側１４０は、複数のクライアント装置１４１〜１４４を含む。サーバ１２０は、データインスタンス１２５を保存するデータレポジトリ１２１、及び、複数の状態属性の集合１３１〜１３４を保存するクライアントレポジトリ１２２を含む。

説明上、データインスタンス１２５は、８個のデータインスタンス１２５１〜１２５８を含むように示されている。状態属性の集合は、各クライアント装置に対して１つあり、状態属性の集合１３１は、クライアント装置１４１に対応し、状態属性の集合１３２は、クライアント装置１４２に対応し、状態属性の集合１３３はクライアント装置１４３に対応し、状態属性の集合１３４は、クライアント装置１４４に対応する。

サービスプロバイダ１１１〜１１４のそれぞれは、各データフィードＦ１〜Ｆ４をサーバ１２０に供給し、サーバ１２０は、データフィードを受信し、データフィードに含まれるデータインスタンス１２５をデータレポジトリ１２１に保存する。

サーバ１２０は、データレポジトリ１２１にデータインスタンスを保存する前に、受信したデータフィードＦ１〜Ｆ４内のデータインスタンスの形式を整えて、データインスタンスが全て共通形式で保持されるようにする。クライアント装置１４１〜１４４は全て、共通形式を扱うように構成される。

状態属性の集合はそれぞれ、関連付けられたクライアント装置に関連するデータインスタンス１２５のそれぞれに対する状態属性を含む。例えば、クライアント装置１４１に関連するデータインスタンスがデータインスタンス１２５１、１２５４及び１２５６である場合、クライアント装置１４１に対する状態属性の集合１３１は、３つのデータインスタンス１２５１、１２５４及び１２５６に対応する３つの状態属性を保存することになる。状態属性はそれぞれ、クライアント装置１４１に対する対応するデータインスタンスの状態を示す。

図２を参照すると、図１のデータ配信システムを利用するデータ配信方法は、まず、サービスプロバイダからデータインスタンスを受信すること（２００）と、２番目に、データレポジトリにデータインスタンスを保存すること（２１０）と、３番目に、データインスタンスに関連付けられた状態属性を状態属性の集合に保存すること（２２０）と、を含み、当該状態属性は、新しいデータインスタンスが関連するクライアント装置に対応する状態属性の集合に保存される。

例えば、クライアント装置１４１及び１４３はデータフィードＦ１に興味を持っているが、クライアント装置１４２及び１４４は、データフィードＦ１に興味を持っていない場合、サービスプロバイダから新しいデータインスタンスを受信すること（２００）は、サービスプロバイダからデータフィードＦ１においてデータインスタンス１２５２を受信することを含み、新しいデータインスタンスをデータレポジトリに保存すること（２１０）は、データレポジトリ１２１にデータインスタンス１２５２を保存することを含み、データインスタンスに関連付けられた状態属性を状態属性の集合に保存すること（２２０）は、状態属性の集合１３１及び１３３のそれぞれに状態属性を保存することを含んでもよい。

サーバは、例えば、どの状態属性の集合にデータインスタンス１２５２についての状態属性を追加する必要があるかを、各クライアント装置が興味を持っているデータフィードのリストに基づいて判定する。当該リストは、クライアント装置ごとに状態属性の集合とともに保存されてもよい。

図１のデータレポジトリ１２１へのデータインスタンスの保存の例を図３を参照して説明する。図３は、Ｄ１〜Ｄ３の３日間にわたってサーバ１２０がデータフィードＦ１〜Ｆ４から受信しているデータインスタンス１２５１〜１２５８を示す。

特に、図３は、第１日目Ｄ１に、データインスタンス１２５１、１２５３及び１２５８を（各サービスプロバイダ１１１、１１２及び１１４に対応する）各データフィードＦ１、Ｆ２及びＦ４から受信し、第２日目Ｄ２に、データインスタンス１２５４及び１２５７を（各サービスプロバイダ１１２及び１１３に対応する）各データフィードＦ２及びＦ３から受信し、第３日目Ｄ３に、データインスタンス１２５２、１２５５及び１２５６を受信したことを示す。データインスタンス１２５２は、データフィードＦ１から受信し、データインスタンス１２５５及び１２５６は、両方ともデータフィードＦ２から１日のうち互いに異なる時間に受信した。

各データインスタンスは、どのデータフィードから受信したか、どの日付に受信したか、及び、バージョン番号によってデータレポジトリ１２１に保存される。バージョン番号は、その日の間に何回更新されたデータインスタンスを受信したかによって設定される。従って、データインスタンス１２５１〜１２５５及び１２５７は、全てバージョン番号１を有しており、データインスタンス１２５６は、データフィードＦ２について日付Ｄ３に２回目に受信したデータインスタンスであるため、バージョン番号２を有している。各データインスタンスは、特定のデータフィード／日付／インスタンスに対応する記憶場所に、及び／または、特定のフィード／日付／インスタンスを示すメタデータと共に保存されてもよい。

データフィードの各連続するデータインスタンスは、データフィードの先行するデータインスタンスの更新情報である。従って、データインスタンス１２５２は、データフィードＦ１からの最新のデータであるため、データインスタンス１２５１に取って代わる。データインスタンス１２５６は、データフィードＦ２からの最新のデータであるため、データインスタンス１２５３、１２５４及び１２５５に取って代わる。データフィードＦ３及びＦ４の最新のデータは、それぞれ、データインスタンス１２５７及び１２５８である。データインスタンス１２５１、１２５３及び１２５５は全て取って代わられてしまったが、データインスタンス１２５１〜１２５８は全て、まだデータレポジトリに保持されており、（それらの状態属性は、状態属性の集合にまだ保持されており）、必要に応じて過去に用いられたデータインスタンスの状態について確認できるようになっている。

状態属性がとり得る様々な状態属性値の例を図４を参照して説明する。図４は、状態属性の集合に関連付けられたクライアント装置が興味を持っている新しいデータインスタンスをサーバが受信した結果、状態属性の集合において状態属性が作成される際に状態属性４１０がとり得る値を示す、状態図４００である。

クライアント装置がデータインスタンスに興味を持っているかは、どのサービスプロバイダまたはデータフィードからデータインスタンスが受信されたかによって判定されてもよく、クライアント装置は、サービスプロバイダまたはデータフィードのリストによって当該サービスプロバイダまたはデータフィードに興味を持っていることが分かる。あるいは、クライアント装置は、単に、全てのデータインスタンスに興味を持っていると仮定してもよい。

まず、状態属性が作成されると、「新規」という値をとり、状態属性がその一部を形成する状態属性の集合に関連付けられたクライアント装置にとって、状態属性に対応するデータインスタンスが新しいことを示す。

クライアント装置がデータインスタンスを読み込む際、読み込みが成功した場合、状態属性値を「読み込み済み」に変更し、読み込みに失敗した場合、「失敗」に変更してもよい。

一旦、データインスタンスのクライアント装置への読み込みが成功すると、クライアント装置は、データインスタンスに妥当性チェックを行い、妥当性チェックに合格した場合、状態属性値を「有効」に変更し、妥当性チェックに合格しなかった場合、「拒否」に変更してもよい。

例えば、データインスタンス１２５２がデータレポジトリ１２１に保存された際にクライアント装置１４３に対応する状態属性の集合１３３において、新しい状態属性を作成してもよく、その後、データインスタンスをサービスプロバイダ１１１からデータフィードＦ１で受信する。新しい状態属性の作成の際、新しい状態属性は、クライアント装置１４３にとって新しいので、「新規」という値が割り当てられる。

続いて、クライアント装置１４３は、サーバ１２０から「新規」という状態属性値を読み取ることによって、新しいデータインスタンス１２５２が利用可能であることに気づき、クライアント１４３は、サーバ１２０からデータインスタンス１２５２を読み込む。状態属性は、読み込みが成功した場合、「読み込み済み」という値に変更され、例えば、サーバとクライアント装置との間の通信回線の故障によって、読み込みに失敗した場合、「失敗」という値に変更される。その後、再び読み込みを試みてもよい。

一旦、データインスタンス１２５２が読み込まれると、クライアントは、データインスタンス１２５２に妥当性チェックを行い、妥当性チェックに合格すると、状態属性の値を「有効」に変更し、例えば、クライアントがデータインスタンス１２５２のデータ許容範囲よりも近い許容範囲を有するデータを要求することによって、妥当性チェックに合格しなかった場合、「拒否」に変更する。例えば、クライアント装置が、データインスタンスが要件に対し十分であると最終的に判断する場合、または、クライアント装置が、データ妥当性要件を上げて、新しいデータ妥当性要件でデータインスタンスを再読み込みする場合、値は「有効」と「拒否」との間で変移してもよい。

サーバ１２０と各クライアント装置１４１〜１４３との間の通信は、各クライアント装置が提供したアプリケーションプログラミングインターフェース（ＡＰＩ）によって、サーバ１２０が管理してもよい。クライアントＡＰＩが動作する際に用いる状態属性値があるため、各クライアントのＡＰＩは、クライアントに関連する状態属性の集合を含むと考えてもよい。

図５は、サーバ１２０によってクライアント装置１４１〜１４４のそれぞれに提供されるクライアントＡＰＩ５００の概略図を示す。各クライアント装置は、クライアントＡＰＩを用いて、クライアント装置に関連付けられた状態属性の集合に動作する様々なコマンドによってサーバ１２０と通信する。

各クライアント装置によって起動される様々なＡＰＩ機能について図５を参照して、クライアント装置１４１を例に説明する。

クライアントＡＰＩ５００は、クライアント１４１が、クライアント装置が利用可能なデータフィードＦ１〜Ｆ４のリストの受信を開始できる、リストフィード機能を提供する。クライアント装置１４１は、例えば、ある種類またはあるカテゴリのデータインスタンスを供給するデータフィードＦ１及びＦ２など、クライアントが興味を持っているデータフィードの種類を特定する種類パラメータとともにリストフィード要求をサーバ１２０に送信することによって、リストフィード機能を起動する。

データフィードＦ１及びＦ２のリストは、クライアント装置１４１に返され、クライアントが興味を持っているフィードの記録としてクライアントＡＰＩに自動的に保存される。あるいは、クライアント装置１４１は、一旦クライアント装置がフィードのリストを受信すると、クライアント装置がどのデータフィードに興味を持っているかをクライアントＡＰＩに対して直接指定してもよい。

フィードＦ１及びＦ２は、クライアントが興味を持っているフィードのリストにあるので、サーバ１２０がフィードＦ１またはＦ２のうち１つから新しいデータインスタンスを受信する度に、状態属性がクライアント装置１４１に対する状態属性の集合１３１に追加される。

クライアントＡＰＩ５００は、クライアント装置１４１が、例えば、クライアント装置に対する更新されたデータインスタンスのリストであって、クライアント装置に対する状態属性の集合１３１の状態属性値に基づいたリストの受信を開始できる、リスト更新機能も提供する。クライアント装置１４１は、随意的なモードパラメータとともにリスト更新要求をサーバ１２０に送信することによってリスト更新機能を起動する。当該モードパラメータは、例えば、「新規」という状態属性値を有するデータインスタンスなど、リストがある種類のデータインスタンスのみを含むように指定する。

データインスタンスのリストは、クライアント装置１４１に返され、例えば、図３を参照すると、データフィードＦ１及びＦ２の他のデータインスタンス１２５１、１２５３、１２５４及び１２５５はクライアント装置１４１によって既に読み込まれており、以前にクライアント装置１４１によって「読み込み済み」と状態属性値が設定された場合、リストは、データインスタンス１２５２及び１２５６を指定してもよい。従って、リスト更新機能により、クライアント装置１４１は、新たな２つのデータインスタンス１２５２及び１２５６がダウンロード可能になったことを知ることができる。

クライアントＡＰＩ５００は、クライアント装置が、例えば、クライアント装置によって指定されたデータフィードの最新のデータインスタンスの受信を開始する、フェッチデータ機能も提供する。クライアント装置１４１は、必要なデータインスタンスの指定及び随意的なモードパラメータとともにフェッチデータ要求をサーバ１２０に送信することによってフェッチデータ機能を起動する。

必要なデータインスタンスは、データフィードによって指定されてもよく、例えば、クライアント装置がデータフィードＦ１からの最新のデータインスタンス１２５２を必要とする場合、値「Ｆ１」が要求に含まれてもよい。あるいは、図２に示す構造によってデータレポジトリ１２１へデータを保存するため、データフィード、データインスタンスの日付及びデータインスタンスのバージョンによって所与のデータインスタンスを完全に指定してもよい。

随意的なモードパラメータは、リスト更新機能と実質的に同じ機能を提供する。例えば、モードパラメータは、指定されたデータフィードのデータインスタンスのみがダウンロードされ、データインスタンスが指定された状態属性値を有するように指定してもよい。

クライアントＡＰＩ５００は、クライアント装置が、例えば、クライアント装置によって指定された日付のデータインスタンスのリストであって、クライアント装置に対する状態属性値に基づいたリストの受信を開始する、リスト履歴機能も提供する。クライアント装置１４１は、日付の指定及び随意的なモードパラメータとともにリスト履歴要求をサーバ１２０に送信することでリスト履歴機能を起動する。

例えば、図３を参照すると、クライアント装置１４１は、Ｄ１の日付を特定するリスト履歴要求、及び、「有効」の状態属性値を指定するモードパラメータをサーバ１２０に送信してもよい。その後、サーバ１２０は、データインスタンス１２５１及び１２５３がクライアント装置１４１によって、以前、日付Ｄ１に読み込まれ、妥当性が認められたデータインスタンスであるため、これらのデータインスタンス１２５１及び１２５３を指定するリストを返すことになる。なお、データインスタンス１２５８は、データフィードＦ１またはＦ２ではなく、データフィードＦ４から受信されたデータインスタンスであり、クライアント装置１４１が興味を持っているデータフィードはデータフィードＦ１及びＦ２のみであるので、データインスタンス１２５８に対応する状態属性の集合１３１の状態属性がないため、データインスタンス１２５８は含まれない。

クライアントＡＰＩ５００は、クライアント装置が、特定のデータインスタンスの状態属性値の設定を開始できる、設定機能も提供する。クライアント装置１４１は、データインスタンスの指定及び設定する状態属性値とともに設定要求をサーバ１２０に送信することで設定機能を起動する。

例えば、データインスタンス１２５２の読み込みに成功した後、クライアント装置１４１は、データインスタンス１２５２を指定するためのデータフィードＦ１、日付Ｄ３及びバージョン１を指定する設定要求、及び、指定されたデータインスタンス１２５２に関連付けられた状態属性値を「読み込み済み」に変更すべきであることを示すための値「読み込み済み」をサーバ１２０に送信する。

一旦クライアント装置がデータインスタンス１２５２に妥当性チェックを実行すると、クライアント装置１４１が設定要求を再度送信し、必要に応じて、状態属性値を「有効」または「拒否」に変更してもよい。

上記ＡＰＩの様々な機能は、クライアント装置がデータレポジトリ１２１のデータインスタンスを問い合わせるのに用いてもよい。さらに詳細な要求をするために、更なるパラメータをＡＰＩ要求に含めてもよい。当業者に明らかなように、例えば、データインスタンスの更新または削除、または、データインスタンスに関連付けられたメタデータの更新または削除など、更なるＡＰＩ機能を提供してもよい。

本発明のデータ処理システム及び方法は、様々なサービスプロバイダから取得し、様々なクライアント装置に供給する多種多様なデータ種類に適用されるが、経時的に頻繁に更新され、クライアント装置が妥当性チェックを行う種類のデータに特に適している。

例えば、特定のクライアントが、他のクライアントにとって必要ではないクエリを実行できる必要がある場合、様々なクライアントＡＰＩから供給される通信プロトコルは、互いに異なっていてもよい。

サービスプロバイダは、例えば、財務ベンチマークデータプロバイダであってもよく、データインスタンスは、例えば、財務ベンチマークデータであってもよく、クライアント装置は、財務ベンチマークデータの顧客であってもよい。

添付の請求の範囲に含まれる範囲内の更なる実施形態も、当業者に明らかであろう。

本発明は、データ配信システム、特に、多数のデータプロバイダからクライアント装置にデータを供給するデータ配信システムに関する。

クライアント装置は、多数の様々なデータソースにデータを要求することが多く、また、データソースはそれぞれ、大抵様々なフォーマット及び品質のデータを供給する。供給されるデータのフォーマット及び品質は、クライアントの要件に合うこともあれば、合わないこともある。

既知のデータ配信システムとして、国際公開公報第２０１２／０７３１７５号は、サービスプロバイダ側、サービスプロバイダ側に接続されたホスト側、及び、ホスト側に接続された顧客側を含むデータ配信システムを開示している。ホスト側のサーバは、サービスプロバイダ側の様々なサービスプロバイダからデータを収集し、顧客側のクライアントにデータを供給する。データは、各クライアントに関連付けられたユーザプロファイルに従って各クライアントに供給され、ユーザプロファイルは、ユーザが興味を持っているデータの種類を特定するものである。米国特許出願２０１１／０２９６３９７号は、ソフトウェアパッケージを管理するシステムを開示している。このシステムは、パッケージレポジトリと、パッケージサーバと、クライアントとを有し、これらがネットワークを介して接続されている。クライアントはパッケージマネジャを有し、パッケージサーバは、クライアントと相互作用をして、クライアント上にインストールされたパッケージを管理する。

クライアント装置の要件に合わせて様々なデータソースからデータを取り出し、クライアント装置に提示することができる、より高度なデータ配信システムが求められている。特に、データソースが、そういったデータの最新版を供給すること、クライアント装置が、データ要件を変更すること、前のバージョンのデータに対して、クライアントがどの時点でどのデータを有していたかなどを確認する必要がある監査を行うことがあるかもしれない。

様々なクライアント装置が様々な通信プロトコルを用いて、様々な方法でデータを列挙することがあるため、クライアント装置が、リストを保持して、サーバからの特定のデータの読み込みを要求することは、特に、クライアント装置がサーバにどんな新しいデータが存在するかわからない場合、困難だろう。

従って、本発明の目的は、既知の従来技術を改善することである。

本発明の第１の態様によれば、添付の請求項１〜１２のいずれか１項に記載のデータ配信システムが提供される。

クライアントごとの状態属性の集合を用いるということは、クライアントが追跡ジョブを行うことなく、あるいは、クライアントが新しいデータインスタンスが来る予定であると考えた時に要求を送信することなく、サーバがクライアントに対して各データインスタンスの状態を追跡することができるということである。

サーバが、状態属性を用いて、データインスタンスに対してクライアント装置の動作の状態を追跡するということは、サーバは、クライアント装置が異なるデータインスタンスを識別するのにどの制御プロトコルを使用するかを把握する必要がなく、単に、状態属性が示すデータインスタンスであって、クライアント装置への読み込みがまだ成功していないデータインスタンスであればどんなデータインスタンスでもクライアント装置に送信することができる、ということである。

さらに、１つのデータレポジトリが各データインスタンスのコピーをたった１つ保存するだけで、データインスタンスを別のクライアントに複製する必要がなく、全てのクライアント装置をカバーするように維持できる。各クライアントは、状態属性の集合を介して、データレポジトリのデータインスタンスを個別に見ることができる。各データインスタンスに対して、別の状態属性をクライアントごとに保存してもよい。

好ましくは、各状態属性は、特定のデータインスタンスに関連付けられていてもよい。その後、状態属性には、クライアント装置に対するデータインスタンスの様々な状態を示す様々な値を割り当てられてもよい。

クライアント装置のうち第１クライアント装置に関連付けられた状態属性の集合内の各状態属性は、状態属性に関連付けられたデータインスタンスがクライアント装置のうち第１クライアント装置にまだ読み込まれていないことを示す値；及び、状態属性に関連付けられたデータインスタンスがクライアント装置のうち第１クライアント装置に読み込まれたことを示す値を含む、値をとってもよい。

従って、サーバ装置がどのデータインスタンスがクライアント装置にまだ読み込まれていないかをクライアント装置に知らせる場合、及び／または、クライアント装置が、新しいデータインスタンスを読み込む準備ができていることを示す場合、クライアント装置に関連付けられた状態属性の集合を用いて、クライアント装置がまだ読み込んでいないデータインスタンスをプッシュ配信してもよい。例えば、状態属性の値は、クライアントが対応するデータインスタンスをまだ読み込んでいない場合、「新規」でもよく、クライアントが対応するデータインスタンスを読み込んだ場合、「読み込み済み」でもよい。

好ましくは、状態属性の値は、サーバとクライアント装置の両方によって設定されてもよい。例えば、状態属性が「新規」に設定される場合はサーバによって設定され、状態属性が「未読み込み」に設定される場合はクライアントによって設定されてもよい。そのため、状態属性は、サーバとクライアント装置の両方が、サーバとクライアント装置との間で双方向通信を行うのに利用可能である。従って、状態属性は、サーバ及びクライアント装置が使用できる非常に単純な通信プロトコルを提供して、人を介さずにクライアント装置への新しいデータインスタンスの読み込みを自動的に連係させる。

状態属性の値は、クライアント装置によって自動的に行われるべき動作のリストを規定してもよい。例えば、クライアント装置は、状態属性の値が「新規」である場合、その状態属性に関連付けられたデータインスタンスの読み込みを自動的に開始してもよい。

妥当性チェックは、一般的に、サーバがサービスプロバイダから受信したデータインスタンスに対して実行するものであり、また、一般的に、サーバから受信したデータインスタンスに対してクライアント装置が実行することもある。サーバによって実行される妥当性チェックは、クライアントによって実行される妥当性チェックとは異なることがあるが、クライアント装置によって実行される妥当性チェックはいずれも、サーバ装置への通知なしに変更されてもよい。妥当性チェックは、例えば、データインスタンスが十分最新であるかの確認、または、データインスタンスに含まれるデータが所与の許容範囲よりも厳密に正しいと特定されるかについての確認を含んでもよい。

従って、クライアント装置のうち第１クライアント装置に関連付けられた状態属性の集合内の各状態属性は、さらに、状態属性に関連付けられたデータインスタンスが、例えば、クライアント装置のうち第１クライアント装置がデータインスタンスを読み込んだ後に行った妥当性チェックに合格しなかったため、クライアント装置のうち第１クライアント装置に拒否されたことを示す値を含む値をとってもよい。

従って、状態属性を用いて、クライアント装置は、データインスタンスがクライアント装置の妥当性チェックに合格しなかったことを自動的にサーバ装置にフラグで知らせることができる。このように、様々なクライアントは、特定のデータインスタンスがクライアントの妥当性チェックに合格しなかったことを知らせるための多数の異なる通信方法を有する必要はない。その代わりに、各クライアントに対して各データインスタンスの状態を中央ログに保持し、状態属性によってサーバ内に保持する。１つ以上のクライアントの妥当性チェックに合格しなかった結果、状態属性は、データレポジトリのどのデータインスタンスに注意が必要であるかを特定するのに用いられる。

状態属性に対応するデータインスタンスがクライアント装置の妥当性チェックに合格した場合、その状態属性の値は、例えば、クライアント装置によって、「有効」と設定されてもよい。データインスタンスがクライアント装置の妥当性チェックに合格しなかった場合、クライアントは、状態属性の値を「拒否」と設定してもよい。

好ましくは、サーバは、データフィードでサービスプロバイダからデータインスタンスを受信するように構成されてもよく、各データフィードは、データインスタンスのストリームを供給する。データレポジトリは、フィード、日付及びバージョン番号によってデータインスタンスを保存するように構成されてもよい。

サーバは、データフィードで受信されたデータインスタンスをデータレポジトリに保存する前に、例えば、データインスタンスが全て共通形式で保持されるように形式を整えるように構成されてもよい。好ましくは、クライアント装置は、サービスプロバイダが用いる様々な形式を扱わなければならないのではなく、共通形式を扱うように構成されてもよい。

データフィードの各連続するデータインスタンスは、データフィードの先行するデータインスタンスの更新情報であってもよく、データレポジトリは、連続するデータインスタンスと先行するデータインスタンスの両方を保存するように構成されてもよい。このように全てのデータインスタンスの履歴を保持することで、クライアント装置は、監査目的で、データインスタンスに関連付けられた状態属性を見ることによって、どの日付にどのデータインスタンスが利用可能であったか、及び、これらのデータインスタンスのうちどのデータインスタンスがクライアント装置によって実際に読み込まれたかを判定することができる。

好ましくは、クライアントレポジトリは、各クライアント装置にクライアントＡＰＩを提供してもよく、当該クライアントＡＰＩは、クライアント装置に対する状態属性の集合を含む。クライアントＡＰＩ（アプリケーションプログラミングインターフェース）は、例えば、どのデータフィードにクライアント装置が興味を持っているか、ひいては、データレポジトリのどのデータインスタンスについてクライアントＡＰＩが状態属性を保存すべきかといった、クライアント装置に関する他の情報を含んでもよい。

クライアントＡＰＩは、クライアント装置が、利用可能なデータフィードのリストの受信を開始することができる、リストフィード機能を提供してもよい。例えば、クライアント装置は、サーバにリストフィード要求を送信し、サーバは、クライアント装置が選択可能なデータフィードのリストをクライアント装置に返してもよい。

クライアントＡＰＩは、クライアント装置が、クライアント装置に対する更新されたデータインスタンスのリストであって、クライアント装置に対する状態属性の値に基づいたリストの受信を開始することができる、リスト更新機能を提供してもよい。

クライアントＡＰＩは、クライアント装置が、クライアント装置によって特定されたデータフィードの最新のデータインスタンスの受信を開始することができる、フェッチデータ機能を提供してもよい。例えば、クライアント装置は、サーバに特定のデータフィードを指定するフェッチデータ要求を送信し、サーバは、そのデータフィードの最新のデータインスタンスを送信してもよい。

クライアントＡＰＩは、クライアント装置が、クライアント装置によって指定された日付のデータインスタンスのリストであって、クライアント装置に対する状態属性の値に基づいたリストの受信を開始することができる、リスト履歴機能を提供してもよい。

好ましくは、クライアントＡＰＩは、クライアント装置が、リスト更新機能、フェッチデータ機能またはリスト履歴機能に関連してモードパラメータを規定することを許可してもよい。当該モードパラメータは、クライアントが当該モードパラメータに対応する状態属性値を有するデータインスタンスまたはデータインスタンスのリストの受信を望んでいることを示すものである。

例えば、クライアント装置は、サーバにリスト更新要求を送信し、当該要求は、「新規」の状態属性値に対応するモードパラメータを含み、サーバは、データインスタンスがまだクライアント装置によって読み込まれていないことを示す「新規」の状態属性値を有する全てのデータインスタンスのリストを返してもよい。

クライアント装置は、サーバにフェッチデータ要求を送信し、当該要求はモードパラメータを含み、モードパラメータは、クライアント装置が当該モードパラメータに対応する状態属性値を有するデータインスタンスの受信を望んでいることを示してもよい。

クライアント装置は、特定の日付及びモードパラメータを指定するリスト履歴要求であって、クライアント装置が当該モードパラメータに対応する状態属性値を有する日付のデータインスタンスのリストの受信を望んでいることを示すリスト履歴要求をサーバに送信してもよい。

クライアントＡＰＩは、クライアント装置が特定のデータインスタンスについての状態属性の設定を開始することができる、設定機能を提供してもよい。例えば、クライアント装置は、一旦、データインスタンスがクライアント装置の妥当性チェックに合格すれば、当該データインスタンスに関連付けられた状態属性の値を「有効」と設定する設定要求を送信してもよい。

本発明の第２の態様によれば、添付の請求項１３に記載のデータ配信方法が提供される。

データインスタンスに関連付けられた状態属性をクライアントレポジトリに保存することは、新しいデータインスタンスが関連するクライアント装置に対応する状態属性の集合に状態属性を追加することを含んでもよい。従って、状態属性の集合が全て、全てのデータインスタンスについての状態属性を含んでいなくてもよい。状態属性の集合は、状態属性の集合に関連付けられたクライアント装置が興味を持っているデータインスタンスの状態属性を含んでいればよい。

あるいは、クライアントレポジトリの状態属性の集合が全て、データレポジトリにある全てのデータインスタンスの状態属性を含んでもよい。

本発明の実施形態を、限定されない例として、添付の図面を参照して説明する。

本発明の実施形態に係るデータ配信システムの概略ブロック図である。 図１のデータ配信システムを用いて実施されるデータ配信方法のフロー図である。 異なるクライアント装置から異なる日に受信しているデータインスタンスを示す図である。 状態属性がとり得る様々な値の状態図である。 サーバによってクライアント装置に提供されるのに適したアプリケーションプログラミングインターフェース（ＡＰＩ）の概略図である。

本発明の実施形態を図１の概略図を参照して説明する。図１は、サービスプロバイダ側１１０、サーバ１２０及びクライアント側１４０を含むデータ配信システムを示す。

サービスプロバイダ側１１０は、複数のサービスプロバイダ１１１〜１１４を含み、クライアント側１４０は、複数のクライアント装置１４１〜１４４を含む。サーバ１２０は、データインスタンス１２５を保存するデータレポジトリ１２１、及び、複数の状態属性の集合１３１〜１３４を保存するクライアントレポジトリ１２２を含む。

説明上、データインスタンス１２５は、８個のデータインスタンス１２５１〜１２５８を含むように示されている。状態属性の集合は、各クライアント装置に対して１つあり、状態属性の集合１３１は、クライアント装置１４１に対応し、状態属性の集合１３２は、クライアント装置１４２に対応し、状態属性の集合１３３はクライアント装置１４３に対応し、状態属性の集合１３４は、クライアント装置１４４に対応する。

サービスプロバイダ１１１〜１１４のそれぞれは、各データフィードＦ１〜Ｆ４をサーバ１２０に供給し、サーバ１２０は、データフィードを受信し、データフィードに含まれるデータインスタンス１２５をデータレポジトリ１２１に保存する。

サーバ１２０は、データレポジトリ１２１にデータインスタンスを保存する前に、受信したデータフィードＦ１〜Ｆ４内のデータインスタンスの形式を整えて、データインスタンスが全て共通形式で保持されるようにする。クライアント装置１４１〜１４４は全て、共通形式を扱うように構成される。

状態属性の集合はそれぞれ、関連付けられたクライアント装置に関連するデータインスタンス１２５のそれぞれに対する状態属性を含む。例えば、クライアント装置１４１に関連するデータインスタンスがデータインスタンス１２５１、１２５４及び１２５６である場合、クライアント装置１４１に対する状態属性の集合１３１は、３つのデータインスタンス１２５１、１２５４及び１２５６に対応する３つの状態属性を保存することになる。状態属性はそれぞれ、クライアント装置１４１に対する対応するデータインスタンスの状態を示す。

図２を参照すると、図１のデータ配信システムを利用するデータ配信方法は、まず、サービスプロバイダからデータインスタンスを受信すること（２００）と、２番目に、データレポジトリにデータインスタンスを保存すること（２１０）と、３番目に、データインスタンスに関連付けられた状態属性を状態属性の集合に保存すること（２２０）と、を含み、当該状態属性は、新しいデータインスタンスが関連するクライアント装置に対応する状態属性の集合に保存される。

例えば、クライアント装置１４１及び１４３はデータフィードＦ１に興味を持っているが、クライアント装置１４２及び１４４は、データフィードＦ１に興味を持っていない場合、サービスプロバイダから新しいデータインスタンスを受信すること（２００）は、サービスプロバイダからデータフィードＦ１においてデータインスタンス１２５２を受信することを含み、新しいデータインスタンスをデータレポジトリに保存すること（２１０）は、データレポジトリ１２１にデータインスタンス１２５２を保存することを含み、データインスタンスに関連付けられた状態属性を状態属性の集合に保存すること（２２０）は、状態属性の集合１３１及び１３３のそれぞれに状態属性を保存することを含んでもよい。

サーバは、例えば、どの状態属性の集合にデータインスタンス１２５２についての状態属性を追加する必要があるかを、各クライアント装置が興味を持っているデータフィードのリストに基づいて判定する。当該リストは、クライアント装置ごとに状態属性の集合とともに保存されてもよい。

図１のデータレポジトリ１２１へのデータインスタンスの保存の例を図３を参照して説明する。図３は、Ｄ１〜Ｄ３の３日間にわたってサーバ１２０がデータフィードＦ１〜Ｆ４から受信しているデータインスタンス１２５１〜１２５８を示す。

特に、図３は、第１日目Ｄ１に、データインスタンス１２５１、１２５３及び１２５８を（各サービスプロバイダ１１１、１１２及び１１４に対応する）各データフィードＦ１、Ｆ２及びＦ４から受信し、第２日目Ｄ２に、データインスタンス１２５４及び１２５７を（各サービスプロバイダ１１２及び１１３に対応する）各データフィードＦ２及びＦ３から受信し、第３日目Ｄ３に、データインスタンス１２５２、１２５５及び１２５６を受信したことを示す。データインスタンス１２５２は、データフィードＦ１から受信し、データインスタンス１２５５及び１２５６は、両方ともデータフィードＦ２から１日のうち互いに異なる時間に受信した。

各データインスタンスは、どのデータフィードから受信したか、どの日付に受信したか、及び、バージョン番号によってデータレポジトリ１２１に保存される。バージョン番号は、その日の間に何回更新されたデータインスタンスを受信したかによって設定される。従って、データインスタンス１２５１〜１２５５及び１２５７は、全てバージョン番号１を有しており、データインスタンス１２５６は、データフィードＦ２について日付Ｄ３に２回目に受信したデータインスタンスであるため、バージョン番号２を有している。各データインスタンスは、特定のデータフィード／日付／インスタンスに対応する記憶場所に、及び／または、特定のフィード／日付／インスタンスを示すメタデータと共に保存されてもよい。

データフィードの各連続するデータインスタンスは、データフィードの先行するデータインスタンスの更新情報である。従って、データインスタンス１２５２は、データフィードＦ１からの最新のデータであるため、データインスタンス１２５１に取って代わる。データインスタンス１２５６は、データフィードＦ２からの最新のデータであるため、データインスタンス１２５３、１２５４及び１２５５に取って代わる。データフィードＦ３及びＦ４の最新のデータは、それぞれ、データインスタンス１２５７及び１２５８である。データインスタンス１２５１、１２５３及び１２５５は全て取って代わられてしまったが、データインスタンス１２５１〜１２５８は全て、まだデータレポジトリに保持されており、（それらの状態属性は、状態属性の集合にまだ保持されており）、必要に応じて過去に用いられたデータインスタンスの状態について確認できるようになっている。

状態属性がとり得る様々な状態属性値の例を図４を参照して説明する。図４は、状態属性の集合に関連付けられたクライアント装置が興味を持っている新しいデータインスタンスをサーバが受信した結果、状態属性の集合において状態属性が作成される際に状態属性４１０がとり得る値を示す、状態図４００である。

クライアント装置がデータインスタンスに興味を持っているかは、どのサービスプロバイダまたはデータフィードからデータインスタンスが受信されたかによって判定されてもよく、クライアント装置は、サービスプロバイダまたはデータフィードのリストによって当該サービスプロバイダまたはデータフィードに興味を持っていることが分かる。あるいは、クライアント装置は、単に、全てのデータインスタンスに興味を持っていると仮定してもよい。

まず、状態属性が作成されると、「新規」という値をとり、状態属性がその一部を形成する状態属性の集合に関連付けられたクライアント装置にとって、状態属性に対応するデータインスタンスが新しいことを示す。

クライアント装置がデータインスタンスを読み込む際、読み込みが成功した場合、状態属性値を「読み込み済み」に変更し、読み込みに失敗した場合、「失敗」に変更してもよい。

一旦、データインスタンスのクライアント装置への読み込みが成功すると、クライアント装置は、データインスタンスに妥当性チェックを行い、妥当性チェックに合格した場合、状態属性値を「有効」に変更し、妥当性チェックに合格しなかった場合、「拒否」に変更してもよい。

例えば、データインスタンス１２５２がデータレポジトリ１２１に保存された際にクライアント装置１４３に対応する状態属性の集合１３３において、新しい状態属性を作成してもよく、その後、データインスタンスをサービスプロバイダ１１１からデータフィードＦ１で受信する。新しい状態属性の作成の際、新しい状態属性は、クライアント装置１４３にとって新しいので、「新規」という値が割り当てられる。

続いて、クライアント装置１４３は、サーバ１２０から「新規」という状態属性値を読み取ることによって、新しいデータインスタンス１２５２が利用可能であることに気づき、クライアント１４３は、サーバ１２０からデータインスタンス１２５２を読み込む。状態属性は、読み込みが成功した場合、「読み込み済み」という値に変更され、例えば、サーバとクライアント装置との間の通信回線の故障によって、読み込みに失敗した場合、「失敗」という値に変更される。その後、再び読み込みを試みてもよい。

一旦、データインスタンス１２５２が読み込まれると、クライアントは、データインスタンス１２５２に妥当性チェックを行い、妥当性チェックに合格すると、状態属性の値を「有効」に変更し、例えば、クライアントがデータインスタンス１２５２のデータ許容範囲よりも近い許容範囲を有するデータを要求することによって、妥当性チェックに合格しなかった場合、「拒否」に変更する。例えば、クライアント装置が、データインスタンスが要件に対し十分であると最終的に判断する場合、または、クライアント装置が、データ妥当性要件を上げて、新しいデータ妥当性要件でデータインスタンスを再読み込みする場合、値は「有効」と「拒否」との間で変移してもよい。

サーバ１２０と各クライアント装置１４１〜１４３との間の通信は、各クライアント装置が提供したアプリケーションプログラミングインターフェース（ＡＰＩ）によって、サーバ１２０が管理してもよい。クライアントＡＰＩが動作する際に用いる状態属性値があるため、各クライアントのＡＰＩは、クライアントに関連する状態属性の集合を含むと考えてもよい。

図５は、サーバ１２０によってクライアント装置１４１〜１４４のそれぞれに提供されるクライアントＡＰＩ５００の概略図を示す。各クライアント装置は、クライアントＡＰＩを用いて、クライアント装置に関連付けられた状態属性の集合に動作する様々なコマンドによってサーバ１２０と通信する。

各クライアント装置によって起動される様々なＡＰＩ機能について図５を参照して、クライアント装置１４１を例に説明する。

クライアントＡＰＩ５００は、クライアント１４１が、クライアント装置が利用可能なデータフィードＦ１〜Ｆ４のリストの受信を開始できる、リストフィード機能を提供する。クライアント装置１４１は、例えば、ある種類またはあるカテゴリのデータインスタンスを供給するデータフィードＦ１及びＦ２など、クライアントが興味を持っているデータフィードの種類を特定する種類パラメータとともにリストフィード要求をサーバ１２０に送信することによって、リストフィード機能を起動する。

データフィードＦ１及びＦ２のリストは、クライアント装置１４１に返され、クライアントが興味を持っているフィードの記録としてクライアントＡＰＩに自動的に保存される。あるいは、クライアント装置１４１は、一旦クライアント装置がフィードのリストを受信すると、クライアント装置がどのデータフィードに興味を持っているかをクライアントＡＰＩに対して直接指定してもよい。

フィードＦ１及びＦ２は、クライアントが興味を持っているフィードのリストにあるので、サーバ１２０がフィードＦ１またはＦ２のうち１つから新しいデータインスタンスを受信する度に、状態属性がクライアント装置１４１に対する状態属性の集合１３１に追加される。

クライアントＡＰＩ５００は、クライアント装置１４１が、例えば、クライアント装置に対する更新されたデータインスタンスのリストであって、クライアント装置に対する状態属性の集合１３１の状態属性値に基づいたリストの受信を開始できる、リスト更新機能も提供する。クライアント装置１４１は、随意的なモードパラメータとともにリスト更新要求をサーバ１２０に送信することによってリスト更新機能を起動する。当該モードパラメータは、例えば、「新規」という状態属性値を有するデータインスタンスなど、リストがある種類のデータインスタンスのみを含むように指定する。

データインスタンスのリストは、クライアント装置１４１に返され、例えば、図３を参照すると、データフィードＦ１及びＦ２の他のデータインスタンス１２５１、１２５３、１２５４及び１２５５はクライアント装置１４１によって既に読み込まれており、以前にクライアント装置１４１によって「読み込み済み」と状態属性値が設定された場合、リストは、データインスタンス１２５２及び１２５６を指定してもよい。従って、リスト更新機能により、クライアント装置１４１は、新たな２つのデータインスタンス１２５２及び１２５６がダウンロード可能になったことを知ることができる。

クライアントＡＰＩ５００は、クライアント装置が、例えば、クライアント装置によって指定されたデータフィードの最新のデータインスタンスの受信を開始する、フェッチデータ機能も提供する。クライアント装置１４１は、必要なデータインスタンスの指定及び随意的なモードパラメータとともにフェッチデータ要求をサーバ１２０に送信することによってフェッチデータ機能を起動する。

必要なデータインスタンスは、データフィードによって指定されてもよく、例えば、クライアント装置がデータフィードＦ１からの最新のデータインスタンス１２５２を必要とする場合、値「Ｆ１」が要求に含まれてもよい。あるいは、図２に示す構造によってデータレポジトリ１２１へデータを保存するため、データフィード、データインスタンスの日付及びデータインスタンスのバージョンによって所与のデータインスタンスを完全に指定してもよい。

随意的なモードパラメータは、リスト更新機能と実質的に同じ機能を提供する。例えば、モードパラメータは、指定されたデータフィードのデータインスタンスのみがダウンロードされ、データインスタンスが指定された状態属性値を有するように指定してもよい。

クライアントＡＰＩ５００は、クライアント装置が、例えば、クライアント装置によって指定された日付のデータインスタンスのリストであって、クライアント装置に対する状態属性値に基づいたリストの受信を開始する、リスト履歴機能も提供する。クライアント装置１４１は、日付の指定及び随意的なモードパラメータとともにリスト履歴要求をサーバ１２０に送信することでリスト履歴機能を起動する。

例えば、図３を参照すると、クライアント装置１４１は、Ｄ１の日付を特定するリスト履歴要求、及び、「有効」の状態属性値を指定するモードパラメータをサーバ１２０に送信してもよい。その後、サーバ１２０は、データインスタンス１２５１及び１２５３がクライアント装置１４１によって、以前、日付Ｄ１に読み込まれ、妥当性が認められたデータインスタンスであるため、これらのデータインスタンス１２５１及び１２５３を指定するリストを返すことになる。なお、データインスタンス１２５８は、データフィードＦ１またはＦ２ではなく、データフィードＦ４から受信されたデータインスタンスであり、クライアント装置１４１が興味を持っているデータフィードはデータフィードＦ１及びＦ２のみであるので、データインスタンス１２５８に対応する状態属性の集合１３１の状態属性がないため、データインスタンス１２５８は含まれない。

クライアントＡＰＩ５００は、クライアント装置が、特定のデータインスタンスの状態属性値の設定を開始できる、設定機能も提供する。クライアント装置１４１は、データインスタンスの指定及び設定する状態属性値とともに設定要求をサーバ１２０に送信することで設定機能を起動する。

例えば、データインスタンス１２５２の読み込みに成功した後、クライアント装置１４１は、データインスタンス１２５２を指定するためのデータフィードＦ１、日付Ｄ３及びバージョン１を指定する設定要求、及び、指定されたデータインスタンス１２５２に関連付けられた状態属性値を「読み込み済み」に変更すべきであることを示すための値「読み込み済み」をサーバ１２０に送信する。

一旦クライアント装置がデータインスタンス１２５２に妥当性チェックを実行すると、クライアント装置１４１が設定要求を再度送信し、必要に応じて、状態属性値を「有効」または「拒否」に変更してもよい。

上記ＡＰＩの様々な機能は、クライアント装置がデータレポジトリ１２１のデータインスタンスを問い合わせるのに用いてもよい。さらに詳細な要求をするために、更なるパラメータをＡＰＩ要求に含めてもよい。当業者に明らかなように、例えば、データインスタンスの更新または削除、または、データインスタンスに関連付けられたメタデータの更新または削除など、更なるＡＰＩ機能を提供してもよい。

本発明のデータ処理システム及び方法は、様々なサービスプロバイダから取得し、様々なクライアント装置に供給する多種多様なデータ種類に適用されるが、経時的に頻繁に更新され、クライアント装置が妥当性チェックを行う種類のデータに特に適している。

例えば、特定のクライアントが、他のクライアントにとって必要ではないクエリを実行できる必要がある場合、様々なクライアントＡＰＩから供給される通信プロトコルは、互いに異なっていてもよい。

サービスプロバイダは、例えば、財務ベンチマークデータプロバイダであってもよく、データインスタンスは、例えば、財務ベンチマークデータであってもよく、クライアント装置は、財務ベンチマークデータの顧客であってもよい。

添付の請求の範囲に含まれる範囲内の更なる実施形態も、当業者に明らかであろう。

Claims (15)

1. サーバに接続された複数のサービスプロバイダと、前記サーバに接続された複数のクライアント装置とを含むデータ配信システムであって、
   前記サーバは、前記サービスプロバイダからのデータインスタンスを保存するデータレポジトリと、前記クライアント装置ごとに状態属性の各集合を保存するクライアントレポジトリとを含み、前記状態属性の各集合は、各クライアント装置に対する前記データインスタンスの状態を示すデータ配信システム。
2. 請求項１に記載のデータ配信システムであって、各状態属性は、特定のデータインスタンスに関連付けられている、データ配信システム。
3. 請求項２に記載のデータ配信システムであって、前記クライアント装置のうちの第１クライアント装置に関連付けられた前記状態属性の集合内の各状態属性は、
   前記状態属性に関連付けられたデータインスタンスが前記クライアント装置のうち前記第１クライアント装置によってまだ読み込まれていないことを示す値と、
   前記状態属性に関連付けられたデータインスタンスが前記クライアント装置のうちの前記第１クライアント装置によって読み込まれたことを示す値と、
   を含む値をとり得る、データ配信システム。
4. 請求項３に記載のデータ配信システムであって、前記クライアント装置のうち前記第１クライアント装置に関連付けられた前記状態属性の集合内の各状態属性は、
   前記状態属性に関連付けられたデータインスタンスが、前記クライアント装置のうちの前記第１クライアント装置によって前記データインスタンスに実行された妥当性チェックに合格したことを示す値と、
   前記状態属性に関連付けられたデータインスタンスが、前記妥当性チェックに合格しなかったことを示す値と、
   を含む値をとり得る、データ配信システム。
5. 請求項１から４のいずれかに記載のデータ配信システムであって、前記サーバは、データフィードで前記サービスプロバイダから前記データインスタンスを受信するように構成され、各データフィードは、データインスタンスのストリームを供給する、データ配信システム。
6. 請求項５に記載のデータ配信システムであって、前記データレポジトリは、フィード、日付及びバージョン番号によって前記データインスタンスを保存するように構成される、データ配信システム。
7. 請求項５または６に記載のデータ配信システムであって、前記サーバは、前記データレポジトリに前記データインスタンスを保存する前に前記データフィードで受信したデータインスタンスの形式を整えるように構成される、データ配信システム。
8. 請求項５、６または７に記載のデータ配信システムであって、データフィードの各連続するデータインスタンスは、前記データフィードの先行するデータインスタンスの更新情報であり、前記データレポジトリは、前記連続するデータインスタンスと前記先行するデータインスタンスの両方を保存するように構成される、データ配信システム。
9. 請求項１から８のいずれかに記載のデータ配信システムであって、前記クライアントレポジトリは、各クライアント装置にクライアントＡＰＩを提供し、前記クライアントＡＰＩは、前記クライアント装置に対する前記状態属性の集合を含む、データ配信システム。
10. 請求項５から８のいずれか一項に追加した場合、請求項９に記載のデータ配信システムであって、前記クライアントＡＰＩは、どのデータフィードが前記クライアント装置に関連するか、ひいては、前記データレポジトリのどのデータインスタンスについて、前記クライアントＡＰＩが状態属性を保存すべきかを特定する、データ配信システム。
11. 請求項９または１０に記載のデータ配信システムであって、前記クライアントＡＰＩは、前記クライアント装置が利用可能な前記データフィードのリストの受信を開始できる、リストフィード機能を提供する、データ配信システム。
12. 請求項９、１０または１１に記載のデータ配信システムであって、前記クライアントＡＰＩは、
    前記クライアント装置が、前記クライアント装置に対する更新されたデータインスタンスのリストであって、前記クライアント装置の状態属性値に基づいたリストの受信を開始できる、リスト更新機能と、
    前記クライアント装置が、前記クライアント装置によって指定されたデータフィードの最新のデータインスタンスの受信を開始できる、フェッチデータ機能と、
    前記クライアント装置が、前記クライアント装置によって指定された日付のデータインスタンスのリストであって、前記クライアント装置の状態属性値に基づいたリストの受信を開始できる、リスト履歴機能と、
    のうちの少なくとも１つを提供する、データ配信システム。
13. 請求項１２に記載のデータ配信システムであって、前記クライアントＡＰＩは、前記リスト更新機能、前記フェッチデータ機能または前記リスト履歴機能と関連してモードパラメータを指定することを可能にし、前記モードパラメータは、前記クライアントが前記モードパラメータに対応する状態属性値を有するデータインスタンスまたはデータインスタンスのリストの受信を望んでいることを示す、データ配信システム。
14. 請求項９から１３のいずれか一項に記載のデータ配信システムであって、前記クライアントＡＰＩは、前記クライアント装置が、特定のデータインスタンスについての前記状態属性値の設定を開始することができる、設定機能を提供する、データ配信システム。
15. 複数のサービスプロバイダから複数のクライアント装置にデータを配信するデータ配信方法であって、
    前記サービスプロバイダからデータインスタンスを受信することと、
    前記データインスタンスをデータレポジトリに保存することと、
    前記データインスタンスに関連付けられた状態属性をクライアントレポジトリに保存することと、を含み、
    前記クライアントレポジトリは、クライアント装置ごとに、状態属性の各集合を保存し、状態属性の各集合は、前記各クライアント装置に対する前記データインスタンスの状態を示す、データ配信方法。

Images