JP3617997B2 - データ更新方式 - Google Patents

Description

技術分野
本発明は、計算機システムにおけるデータ更新方式及びデータ更新方法に関し、特に、多様な通信環境に接続された多数の利用者端末で共有される共有データの更新を行なうデータ更新方式及びデータ更新方法に関する。
背景技術
従来から計算機システムにおいて、２つ以上の実行単位がデータを共有し、各々の実行単位が共有データの更新を行なう場合、共有データの一貫性をいかに維持するか、また、各々の実行単位が各々に共有データのコピーを持つ場合、オリジナルの共有データと各々のコピーデータ、また、各々のコピーデータ同士の一貫性をいかに維持するかがさまざまなレベルにおいて問題となってきた。たとえば、共有メモリ型のマルチプロセッサ計算機で各CPU（セントラルプロセッシングユニット）が共有メモリのデータ更新を行なう場合、テストアンドセット命令によって共有メモリ上のデータをもとに排他制御を行ない、同時書き込みによってデータ一貫性が損なわれるのを防ぐ、また、各々のCPUがキャッシュメモリを持つ場合、ライトスルー、コピーバック、及びスヌーピングの利用といった解決策によりCPU間のキャッシュデータの一貫性を守ってきた。
また、プロセス間で共有されるファイルもその一例である。複数のプロセスからのアクセスを許しても厳密なファイルデータの一貫性は求めない、あるいは、データの一貫性を重視する場合、性能を犠牲にしてもセマフォロック機構によるプロセス間の排他制御を行なうといった対応がなされてきた。この他にも、データ一貫性に関する技術はその枚挙に暇がない。具体的な技術の一例として、特開昭62−206935にはシステム資源の排他制御のための制御ファイルアクセスを更新キューと処理タスクによってシリアライズする技術が開示されている。
本発明がその主な適用先とする応用プログラムレベルにおいて、データ一貫性が重視される問題の一つがデータベースによるトランザクション処理である。銀行口座や在庫管理など厳密な商取り引きを電子的に具現化するもので、ACID（Atomicity,Consistency,Isolation and Durability）プロパティと呼ばれる特性を満足するものでなければならないとされている。すなわちシステムで扱われる一つ一つのトランザクションは、「分離できない」もの、「データの一貫性を損なわない」もの、「他トランザクションとは隔離されている」もの、「データは決して失われない」ものでなければならない。
この特性を実現するために従来のシステムはトランザクションは同期的に処理されるものとしてきた。つまり、ある端末からデータベースデータの更新を実行する場合、データベースに接続し、データベースの更新権を得て、データ参照、更新を行ない、データベース更新命令（コミット）を発行して一連の動作を完了する。例えば、他のデータベース利用者が更新しようとするデータを更新中の場合は、更新トランザクションはデータベースに接続した状態で、データ更新可能となるのを待つ。一連の動作はデータベース接続を保ったまま中断なしに実行される。
もし、一連の動作中にデータベース接続が切断されると、実行中のトランザクションは中断され、トランザクションは無効になる。分離中断されない更新データ特定、更新データ排他制御、データ操作、データベース更新という一連のトランザクション動作が保証されることを前提に、従来のデータベースシステムはデータ一貫性を保証してきた。
さて、特表平３−505938には、「場立ち」を基本として行なわれる先物取り引き市場を「場」という物理的なスペースの外に計算機システムを利用することにより拡張するための技術が公表されている。「場」にいることによって得られる情報を計算機システムによって提供し、「場」での取り引き機構、即ち、トランザクション機構も計算機システムによって実現する。
本発明を適用するすべきシステムは、例えば、特表平３−505938に記述されているシステムである。本発明を適用することにより、その目的としている「場」の拡大をさらに実現することが可能である。
従来のトランザクション処理は、データベースアクセス負荷調節を目的としてTP（Transaction Processing）モニタなどのキューイング機構を使用する場合を含め、端末からのデータ更新要求は同期的に処理されることを前提に、各トランザクション処理の排他制御機構を設けることにより実現されてきた。端末からの同期処理を行なうにはなんらかの通信プロトコルにより端末とホスト（あるいはサーバ）との接続状態が保証されている必要があった。通信回線の品質はある程度までは通信プロトコルによって保障されるが、PHS（Personal Handyphone System）、携帯電話等の無線回線の利用においては、回線の切断、また、ユーザが明示的に無線回線の使用を行なわない場合を含めて回線の接続状態が必ずしも保証されない。また、転送速度も低速である。このような無線回線を利用する端末からトランザクション処理を行なおうとする場合、無効トランザクションが多発すると予想される。トランザクションが無効となることによりユーザは不利益を被り、システムとしても負担が増えることとなる。
本発明の目的は、必ずしも接続状態を保証できない端末を使用しても、利用者間で公平にデータ更新トランザクションを実行できるデータ更新方式及び方法を提供することである。
発明の開示
この発明に係るデータ更新方式は、複数の利用者端末と、利用者間の共有データを管理するサーバとを備え、上記複数の利用者端末と上記サーバは上記利用者端末と上記サーバとの間で相互に同期が取られた時刻を計時する計時機能モジュールをそれぞれ保持し、上記利用者端末は、上記共有データの更新要求時、上記計時機能モジュールにより獲得した時刻をデータ更新要求発行時刻として共有データ更新要求に付して上記サーバに送信し、共有データ更新要求が上記サーバに受信されるまで、上記データ更新要求発行時刻を当初の送信時と同一としたまま繰り返し送信する更新要求送信処理部を有し、上記サーバは、上記利用者端末から受信した共有データ更新要求に付されたデータ更新要求発行時刻に基づき、上記共有データの更新順序を決定する共有データ管理モジュールを有することを特徴とする。
共有データ管理モジュールは、更新要求受け付け期間を設定する更新規則管理部と、上記更新要求受け付け期間に受信した共有データ更新要求を受け付ける更新要求管理部とを備えたことを特徴とする。
更新規則管理部は、さらに、上記更新要求受け付け期間に含まれる有効更新要求発行期間を設定し、更新要求管理部は、受信した共有データ更新要求のデータ更新要求発行時刻が該有効更新要求発行期間内にある共有データ更新要求を受け付けることを特徴とする。
更新要求送信処理部は、データ更新条件を含む共有データ更新要求をサーバに送信し、共有データ管理モジュールは、上記更新要求受け付け期間の終了後、上記共有データ更新要求に含まれたデータ更新条件をデータ更新要求発行時刻の順に吟味し、上記データ更新要求が満足される時、上記共有データ更新要求に応じて共有データ更新値を決定し、上記共有データを該共有データ更新値に更新するデータ更新部を備えたことを特徴とする。
データ更新部は、上記有効更新要求発行期間内に、すでに受信した共有データ更新要求に含まれるデータ更新条件をデータ更新要求発行時刻の順に吟味し、上記データ更新条件が満足される場合は、上記共有データ更新要求に基づく共有データ更新予測値を決定することを特徴とする。
共有データ管理モジュールは、利用者端末に対して所定段階に強度が分類された権限の内の１つの権限を付与し、該権限により各利用者端末に送信する情報を選択する利用者通知部を有することを特徴とする。
利用者通信部は、一定以上の強度の権限を持つ利用者端末のみに共有データの更新履歴を送信することを特徴とする。
利用者通知部は、一定以上の強度の権限を持つ利用者端末のみに、各利用者端末からのデータ更新要求の内容を送信することを特徴とする。
共有データ管理モジュールは、共有データを更新した時に利用者端末に通知する利用者通知部を有することを特徴とする。
利用者通知部は、上記通知の内容に、少なくとも共有データの更新前後の差の情報を含むことを特徴とする。
利用者通知部は、共有データの更新前に該共有データにアクセスしたことのある利用者端末に対して通知することを特徴とする。
利用者通知部は、共有データの更新前の一定期間内に該共有データにアクセスしたことのある利用者端末に対して通知することを特徴とする。
利用者端末は、サーバに対して情報送信要求を送信し、共有データ管理モジュールは、利用者端末から情報送信要求を受信し、該利用者端末の共有データへのアクセス履歴を吟味し、該利用者端末が情報送信要求の受信前に該共有データにアクセスしたことがある場合、該情報送信要求に応答する利用者通知部を有することを特徴とする。
利用者通知部は、利用者端末が上記情報送信要求の受信前の一定期間内に上記共有データにアクセスしたことがある場合、情報送信要求に応答することを特徴とする。
利用者端末からの情報送信要求は、サーバにすでに到着している共有データ更新処理前のデータ更新要求の内容に対する送信要求であることを特徴とする。
利用者端末は、共有データの更新を監視する条件を送信し、共有データ管理モジュールは、送信された条件を登録し、共有データ更新により条件が満たされた時に該利用者端末に共有データ更新を通知する利用者通知部を有することを特徴とする。
利用者端末は共有データの更新を監視する条件を送信し、共有データ管理モジュールは、送信された条件を登録し、上記共有データ更新予測値が条件を満たす時に利用者端末に共有データ更新予測値が条件を満たすことを通知する利用者通知部を有することを特徴とする。
上記計時機能モジュールは、暗号化処理部を備えたことを特徴とする。
上記計時機能モジュールは、利用者端末の認証機能を備えたことを特徴とする。
サーバは、共有データ管理モジュールが受信した各利用者端末からの共有データ更新要求をデータ更新要求発行時刻の順にならべた共有データ更新要求キューを記憶する記憶部を有することを特徴とする。
この発明に係るデータ更新方法は、複数の利用者端末と、利用者間の共有データを管理するサーバとを備え、上記複数の利用者端末と上記サーバとが、時刻を計時するは計時機能モジュールをそれぞれ保持している計算機システムのデータ更新方法において、上記複数の利用者端末の計時機能モジュールと上記サーバの計時機能モジュールとの間で相互に同期を取る工程と、上記利用者端末により、上記共有データの更新要求時、上記計時機能モジュールより獲得した時刻をデータ更新要求発行時刻として共有データ更新要求に付して上記サーバに送信し、共有データ更新要求が上記サーバに受信されるまで、上記データ更新要求発行時刻を当初の送信時と同一としたまま繰り返し送信する工程と、上記サーバにより、上記利用者端末から共有データ更新要求を受信し、受信した共有データ更新要求に付されたデータ更新要求発行時刻に基づき、上記共有データの更新順序を決定する工程を備えたことを特徴とする。
共有データ更新要求は、第１の条件と数量の条件を含む売り注文または買い注文であり、データ更新要求発行時刻が昇順となるように共有データ更新要求キューの形式でサーバの記憶部に保持され、下記ステップを有することを特徴とする。
ａ）サーバの記憶部に記憶された共有データ更新要求キューの状態により、下記（a1）〜（a3）のいずれかのステップを実行するチェックステップ；
a1）サーバの記憶部に記憶された共有データ更新要求キューに注文が保持されていない場合、処理を終了するステップ；
a2）サーバ記憶部に記憶された共有データ更新要求キューの先頭の注文が買い注文の場合、この買い注文を主注文とし、売り注文を対応注文として下記（ｂ）第１条件比較ステップに進むステップ；
a3）サーバ記憶部に記憶された共有データ更新要求キューの先頭の注文が売り注文の場合、この売り注文を主注文とし、買い注文を対応注文として下記（ｂ）第１条件比較ステップに進むステップ；
ｂ）サーバ記憶部に記憶された共有データ更新要求キューから対応注文を昇順に読出し、上記主注文と第１の条件が一致する対応注文があるか否かにより次のいずれかのステップを実行する第１条件比較ステップ；
b1）第１の条件が一致する対応注文がない場合、この主注文を不成立注文として上記共有データ更新要求キューから削除し、上記（ａ）チェックステップに戻るステップ；
b2）第１の条件が一致する対応注文がある場合、主注文と対応注文である買い注文と売り注文の数量を比較し、その結果により下記いずれかのステップを実行するステップ：
b21）買い注文の数量が売り注文の数量を超えている場合、この買い注文とこの売り注文は不成立とし、共有データ更新要求キュー内の該対応注文の次の対応注文から読出しを再開し、上記第１条件比較ステップに戻るステップ；
b22）買い注文の数量が売り注文の数量と等しい場合、この買い注文と売り注文は成立とし、この買い注文と売り注文をそれぞれ共有データ更新要求キューから削除し、上記（ａ）チェックステップに戻るステップ：
b23）売り注文の数量が買い注文の数量を越える場合、この買い注文と売り注文は成立とし、この買い注文は共有データ更新要求キューから削除し、この売り注文の数量をこの買い注文の数量を超えた数量に置き換えて、売り注文のキューデータを更新して記憶し、上記（ａ）チェックステップに戻るステップ。
【図面の簡単な説明】
図１は、本発明を適用したシステムの構成例の図である。
図２は、本発明による計時機能の組み込み例の図である。
図３は、本発明による計時機能モジュールのブロック図である。
図４は、本発明による共有データ管理サーバ構成例の図である。
図５は、本発明による共有データ管理モジュールの構成例の図である。
図６は、本発明を利用した端末アプリケーションの入力画面例の図である。
図７は、本発明による共有データ更新要求発行処理フロー図である。
図８は、本発明による共有データ更新要求データ例の図である。
図９は、本発明による共有データ更新要求受け付け処理フロー図である。
図10は、本発明による共有データ更新処理フロー図である。
図11は、本発明による利用者IDデータ例の図である。
図12は、本発明による通知サービス登録処理フロー図である。
図13は、本発明によるデータモニタリング登録キュー模式図である。
図14は、本発明による共有データ更新要求キュー例の図である。
図15は、本発明による通知サービス登録テーブル模式図である。
発明を実施するための最良の形態
実施の形態1.
以下、本発明に係るデータ更新方法を図１から図13に基づいて説明する。本実施形態では、本発明を商品取り引きシステムに適用した例について説明するが、この商品取り引きシステムは、多数の利用者が参加するトランザクションシステムの一種である。当システムはバーチャルな市場を提供するもので、市場への参加は当システムが提供する端末を利用することによってのみ可能である。参加者は有線で接続された端末だけでなく、無線端末を利用しても公平に市場に参加できる。
図１に示すように、利用者は携帯端末101、102から無線電話回線を利用して基地局107から公衆網108経由で参加したり、公衆回線109とパーソナルコンピュータPC経由で接続されたイントラネットに接続された端末103、104から参加する場合もあり、また、共有データの管理を行なうサーバ110が接続された同一のLAN（Local Area Network）に接続された端末105、106から参加する場合もある。図１には前述したような３種類の通信メディアが示されている。
次にシステムの構成を説明するが、以後、上記携帯端末101、102および上記端末103から106の端末の総称を利用者端末とする。
図２に示すように、本システムに参加する利用者端末は計時機能を有する計時機能モジュール201を保持し、サーバ110は計時機能モジュール402を保持している。また、各利用者端末には、サーバ110との間でデータあるいは情報の送受信を行うために、端末用通信プログラム202がインストールされている。この端末用通信プログラム202は、更新要求送信処理部の一例である。この更新要求送信処理部は、後述する共有データ更新要求送信機能を有する。
この端末用通信プログラム202は、特定の利用者のみ使用可能であり、パスワードにより利用者を確認する機能を有する。また、各利用者端末には、メモリ203がインストールされている。
また、上記計時機能モジュール201は携帯端末101を含むすべての利用者端末で同一のものを使用する。本計時機能モジュール201は各利用者端末に対して着脱式で、システム管理者によって認証と、本システムが採用する標準時間への時計合わせが行なわれて有効となり、特定の利用者のみに配布される。システム管理者は、例えば、商品取り引き市場にシステムが適用される場合、市場の監査組織が行なうべきもので、システム管理者は上記計時機能モジュール201を厳重に管理する。
上記計時機能モジュール201は、本システムにおいてはPCカードとして実現される。
図３に上記上記計時機能モジュール201の機能ブロック図を示す。301はPCカードインターフェースロジック、302は内部バス、303はバックアップ電池、304は暗号化およびコントロールロジック、305はクロック、306は認証データ格納用EPROM（Erasable Programmable Read Only Memory）である。コントロールロジック304には時計合わせホスト認証ロジックが組み込まれており、クロック305と後述の本システムの標準時間との時計合わせ、およびEPROM306への利用者認証データ設定を行なう初期設定がなされて、本計時機能モジュール201は有効となる。
この時計合わせ及び利用者認証データ設定は、システム管理者により行われる。
また、上記端末用通信プログラム202は、利用者端末にこの計時機能モジュール201が装着されているかどうかを検出し、さらに計時機能モジュール201が装着されていて、利用者が正しいパスワードを入力したときのみデータあるいは情報の送受信が可能となり、利用者から上記端末用通信プログラム202が使用可能となる。
当システムにおける共有データ管理者であるサーバ110の機能構成を図４に示す。当システムにおける共有データは、データベースDBの各テーブルのレコードのデータである。
LAN401に接続されて、サーバ110は各利用者端末から利用される。サーバ用計時機能モジュール402は、本システムの標準時間であり、各利用者端末の計時機能モジュール201の基準となるクロックを保持している。各利用者端末の計時機能モジュール201は、このクロックと一致するように、システム管理者によって時計合わせがされる。
403は更新要求格納用ディスク、404は共有データ管理モジュール、405は共有データ格納用ディスクである。406はメモリである。1100は、後述する利用者管理テーブルである。
図５に示すように、共有データ管理モジュール404は、利用者からの共有データ更新要求を受け付け、保存管理する更新要求管理部501、各種利用者へのデータ更新状況通知サービスを行なう利用者通知部502、更新要求受け付け期間の設定や共有データ更新のための調停を行なう更新規則管理部503、整理された（キューイングされた）更新要求データから共有データの更新を行なうデータ更新部504から構成される。
以下、本システムの動作を次の１から６の各機能に基づいて説明する。
1.利用者端末における更新要求データ受け付け送信機能
2.更新規則管理機能
3.共有データ更新要求管理機能
4.データ更新機能
5.価格予測機能
6.更新内容利用者通知機能
1.利用者端末における更新要求データ受け付け送信機能
まず、利用者端末での共有データ更新要求送信機能について説明する。ここでは、利用者が利用する通信メディアについては言及しないが、利用者端末から更新要求を発行し、更新要求管理部501に登録されるまでのメカニズムを通信再試行メカニズムを含めて説明する。
利用者端末はPCカードインターフェースを備えており、計時機能モジュール201がシステムに組み入れられ、さらに利用者が正しいパスワードを入力したことを端末用通信プログラム202が確認すると、利用者端末における端末用通信プログラム202が利用可能となる。
すでに述べた通り、本実施形態では本システムを商品取り引きシステムに応用した例を示しているが、利用者端末上の端末用通信プログラム202が用意する買い注文画面を図６（ａ）に示す。
601は注文画面で、商品ID（Identification）、買い数量、買値条件を各々対話式で設定する。図６の商品IDは２月中旬収穫のオレンジを表わしている。
買い数量には、この数量丁度か、この数量以下か、この数量以上かを表わすオプション、「just」「max」「min」を付け、買値は上限値を設定する。図６（ａ）の例では、数量200個丁度の買い注文を表わしている。
商品ID、買い数量及び買値条件を設定後、利用者は表示画面を確認の上、602の送信ボタンを押下する。
また、上記オプシュン「max」「min」は複合使用が可能であり、たとえば以下のような表現も可能である。
100＜買値＜200
図６（ｂ）は売り注文画面であり、603は注文画面に、買い注文と同様に商品IDを入力した後、売り数量を入力する。売りの場合には、数量にオプションは付けず、売値は下限値を入力する。
商品ID、売り数量及び売値条件を設定後、利用者は表示画面を確認の上、604の送信ボタンを押下する。
上記買値または売値が、本発明における第１の条件である。
利用者による送信ボタン602あるいは604の押下により、端末用通信プログラム202は利用できる通信メディアと、コンフィグレーションデータとして登録されているサーバアドレスにより、買い注文または売り注文、つまり、共有データ更新要求をサーバ110に送信する。
端末用通信プログラム202が、利用者からの買い注文または売り注文を受け付けた後のサーバ110への送信手順について、図７のフローチャートを参照して説明する。
なお端末用通信プログラム202は利用者の誤操作を未然に防ぐため買い注文、売り注文を別画面としているが、更新処理としては同一である。以下、買い注文として説明する。
最初の処理として、ステップ701でサーバアドレスを計時機能モジュール201から取得する。当システムにおいてはサーバアドレスはIP（Internet Protocol）アドレスにて表現されている。
ステップ702で利用者から与えられた買い注文データを計時機能モジュール201が受け付けるフォーマットに整理し、ステップ703で計時機能モジュール201に703でフォーマットされた買い注文データを入力する。計時機能モジュール201はこの入力により、図８に示すフォーマットの更新要求データ800を生成し、初期設定時に与えられた暗号鍵により、更新要求データ800を暗号化する。
この更新要求データ800は、利用者を特定する利用者ID801、計時機能により得た本発明におけるデータ更新要求発行時刻である発信時刻802、商品ジャンルを表わすテーブルID803、前記商品IDと同じ意味のレコードID804、数量データに対するオペレーション（買いなら減算、売りなら加算）805、数量（オペランド）806、オペレーション実行可否を決定する条件807、共有データ更新に伴う清算トランザクションを行なうための利用者清算銀行口座808を含む。条件807は、オペレーション805が減算すなわち買い注文の場合は自動的に買値の上限値を示し、オペレーション805が加算すなわち売り注文の場合なら自動的に売値の下限値を示す。
図８の更新要求データ800において、発信時刻は1997年９月17日11時３分32秒12、テーブルIDは果物、レコードIDは２月中旬収穫のオレンジを意味し、数量200個丁度、買い値350以下の買い注文である。
端末用通信プログラム202は暗号化された更新要求データ800を計時機能モジュール201から受けとる（ステップ704）。端末用通信プログラム202は、ステップ705で暗号化された更新要求データ800をサーバに送信する。
サーバへの送信はこれまで説明してきた通り利用者端末が利用する通信メディアにより必要ずしも成功するとは限らない。利用者端末は通信に成功するまで再試行を重ねる。再試行の場合でも、端末用通信プログラム202は更新要求データ800の発信時刻802を変化させず、当初の送信時と同一の発信時刻802を用いて再送する。こうして必ずしも接続状態を保証できない端末を使用しても、利用者間で公平にデータ更新トランザクションを実行できるデータ更新方式及び方法を提供することが可能になる。当システムにおいては、通信プロトコルとしてTCP（Transation Control Protocol）を利用しているのでサーバへ送信されたか否かは確実に知ることができる。
暗号化された更新要求データ800はサーバの更新要求受け付け期間内に到達する限り有効であるので、通信に失敗する場合、利用者は利用者端末内に保存されている更新要求データ800を他の通信メディアを利用して送信することもできる。もちろん、利用者端末は更新要求データ800をメモリ203の中に保存することもできる。
サーバ110は、更新要求データを受信した場合、受理メッセージを利用者端末に送信する。利用者端末はステップ706でサーバ110からの受理メッセージを受け、サーバ110が更新要求を受け付けたかどうかを確認し（受け付け期間内でない場合に受理されない可能性がある）、利用者に通知する。
2.更新規則管理機能
更新規則管理機能は更新規則管理部503が持ち、更新要求受け付け時間の管理、更新要求発行時刻の妥当性の管理、共有データ更新の制御を行なう。
本実施形態では商品取り引きに応用されている例を示しているが、本機能が参照利用／管理するコンフィグレーションデータファイルに固定的に、有効更新要求発行期間として午前９時〜午後３時、更新要求受け付け期間として午前９時〜午後９時を設定している。
この有効更新要求発行期間は一般の市場の営業時間に相当するものと想定しており、この時間内に発行された買い注文、売り注文のみが有効とするものである。
また、有効更新要求発行期間内に発行された注文でも通信状況により遅延してサーバに到着することがあり、その遅延時間を考慮して、この更新要求受け付け期間内に到着した注文は、受け付けるとするものである。
データ更新処理は午後９時の受け付け終了をもって開始する設定となっている。
3.共有データ更新要求管理機能
更新要求管理部501が持つ、利用者からの共有データ更新要求の受け手となる機能であり、利用者からの更新要求を受けて、更新要求キューを生成し管理する。本処理フローを図９を用いて説明する。
本処理は独立したコンテクストで動作しており、常に、利用者端末からの更新要求の着信をモニタしている。厳密には、着信コネクト要求によって新規のコンテクストが生成され、更新要求キューに一つあるグローバルロックを取得の上、ステップ901以下の処理を行なうが、ここではフローをループ処理として表記してある。更新要求の着信が重なった時は処理がシリアライズされるが、利用者間のトランザクションの公平性には影響しない。
ステップ901で、暗号化された更新要求データ800を受けとると、この更新要求データを複合化し、図８に示した更新要求データ800を得る。
ステップ902で更新要求データ中の利用者IDをチェックし、利用者IDが不正ならば、ID不正により更新要求登録がなされなかった旨を該利用者にステップ906で通知する。
続いてステップ903で更新規則管理部503に問い合わせ、更新要求データ800に付された発信時刻が有効更新要求発行期間内か否か、また着信時刻が更新要求受け付け期間内か否かを吟味して、いずれか一方でも所定期間内でなければ、ステップ906で同じく理由とともに更新要求登録が拒絶された旨を該利用者に通知する。
ステップ903で発信時刻、着信時刻とも所定期間内であったら、ステップ904では、図８の更新要求データ800に、更新要求キュー上へ登録するためのキューリンクポインタ２つと、該利用者への返信用に該利用者のアドレスを付加し、発信時刻の昇順（時刻の早い順）へ更新要求キューに挿入する。
図14にメモリ406に作られた更新要求キュー（以下、単にキューともいう）の構成例を示す。1401は図14に例示する更新要求キューを管理するヘッダである。該ヘッダに３つのキューデータがキューイングされている。図８に示すフォーマットの更新要求データ800に加え、キュー上の前キューデータを示すキューリンクポインタ1403と後キューデータを示すポキューリンクインタ1404、および利用者アドレス（ポートアドレス）1402を付加されたデータが各キューデータを構成している。各キューデータは固定長でありキューイングに十分なサイズのメモリ領域を固定的に使用する。この領域をメモリプールと呼ぶがメモリプールによりキューリンクポインタ操作によってメモリ領域の再利用が可能である。
さらに、該当する更新要求キューのメモリプールに対応する（記憶部の一例である）更新要求格納用ディスク403へのメモリプールの内容書き込みをステップ905で行なって、ステップ907で該更新要求がサーバ110に受理されて登録された旨を該利用者に通知する。
さらに、ステップ908で更新要求データ800の転送要求を予め登録をしている利用者に当更新要求を転送する。更新要求データ800の転送要求の登録については、以下の「6.更新内容利用者通知機能」において説明する。
もし、何らかのシステム障害でシステムがダウンした場合、更新要求格納用ディスク403からメモリプールの内容の読出しを行なってメモリ406に更新要求キューを復旧する。
4.データ更新機能
本機能はデータ更新部504が持つ機能であり、更新規則による当機能の動作、更新要求データ800のデキュー、更新要求の吟味メカニズムについて主に説明する。
本システムにおいて、データ更新機能は市場営業日の午後９時に更新規則管理機能により起動される。本実施例において結果的にデータ更新はバッチ的に処理されるがもちろんこれは本発明の制限するところではない。
本データ更新処理を図10のフローを用いて説明する。
すでに更新要求キューは各レコード毎に利用者の更新要求発行時刻に基づいて整理されているので、当更新処理はステップ1001で各レコードについて発行時刻の古い順に更新要求キューをアクセスして以下に述べるようにキューデータを処理し、処理したキューデータをデキュー（削除）していく。すべての更新要求キューのキューデータの処理を終了したところで本処理は終了となる。
ステップ1002で、更新要求キューの買い注文と売り注文の照合を行う。更新要求キューの先頭にあるキューデータ（未処理のキューデータの中で更新要求発行時刻の最も古い注文）が買い注文であれば、売り注文のキューデータを昇順にサーチし、発見した売り注文に対し、ステップ1003で価格が合致するかどうかをチェックする。合致していれば（売り価格≦買い価格であれば）、さらにステップ1004で、この売り注文の数量と買い注文の数量を比較し、売り注文の数量が買い注文の数量を満足する場合（売り注文の数量≧買い注文の数量の場合）は、この取り引きは成立したものとし価格をデータベースに登録する。そして、成立した買い注文のキューデータと売り注文のキューデータをステップ1010でデキューする。この時、売り注文の数量の方が多く（売り注文の数量＞買い注文の数量）残数がある場合は、この残数（残数＝売り注文の数量−買い注文の数量）を新たにこの売り注文の数量と設定し直す。買い注文のキューデータはデキューする（ステップ1010）。価格、あるいは、数量が合致しなかった場合、ステップ1002に戻り次の候補をサーチする。ただし、数量が満足されなかった場合は、続けて売り注文のキューデータを読出して、価格および数量が満足される売り注文を検索し、条件の合う売り注文がなかった場合は、この買い注文は不成立となる。この不成立となった買い注文のキューデータはデキューされる（ステップ1009）。以上の場合は、買い注文が本発明における主注文、売り注文が対応注文となる。
更新要求キューの先頭にあるキューデータが売り注文の場合はキュー上の買い注文を対象に同様の処理を行う。この場合は、売り注文が本発明における主注文、買い注文が対応注文となる。
サーチして最後まで、売買が成立しなかった売り注文または買い注文と、売り注文の中で残数があるものが残注文として更新要求キューからのデキュー時に抽出される。以上のように、注文が成立してもしなくても、先頭のキューデータを更新要求キューから削除（デキュー）する。このキューデータの削除はヘッダのポインタのつけかえにより行われる。こうしてキューデータが順に先頭にくりあげられ処理される。
売買が成立した場合、すなわち、更新条件が合致したならばステップ1005で更新要求データ中に設定されたオペレーション805（買いなら減算、売りなら加算）とオペランド806（当システムにおいては商品数量）で、共有データを更新する。つまり、当システムが利用するデータベース中の当該レコードのデータを更新する。また、商品売買に伴う清算を更新要求データ800内に設定された清算用銀行口座808にて行なう。
共有データの更新が終了したならば、利用者通知部502を通して、該更新を発行した利用者に売買が成立し、該共有データ更新が終了したことをステップ1006で通知する。
この利用者への通知は夜間であるため、利用者端末が起動されていないことがあるが、利用者端末に受信されなかった通知は、次回利用者端末が起動された際に再度送信される。
また、利用者端末側からも、端末用通信プログラム202を利用して、自分が送信した更新要求の結果を問い合わせることが可能である。
さらに、ステップ1007で共有データの更新通知要求を予め登録をしているユーザに、更新したレコードの更新前レコードと更新後レコードの差分データを送信する。この共有データの更新通知の登録については、以下の「6.更新内容利用者通知機能」において説明する。
もし、条件に合致しない場合、すなわち残注文となった場合は、ステップ1008で該更新要求を発行した利用者に共有データの更新が行なわれなかったことを通知する。当通知は更新要求キューに登録されているポートアドレスに通知する。
5.価格予測機能
本機能は、データ更新機能と同じくデータ更新部504が持つ機能である。
上記データ更新機能は、更新要求受け付け期間終了（本実施形態では午後９時）以後、売り注文と買い注文のキューデータを照合して売買価格を最終決定するものであるが、本価格予測機能は、有効更新要求発行期間（本実施形態では午前９時〜３時）内に受信した買い注文と売り注文を格納したキューデータを、この有効更新要求発行期間内の一定時間ごと（例えば10分毎）に照合し、その時点で成立する売買の価格を、価格の予測値とするものである。この時間帯には、すでに発信されていてもまだ受信されていない注文がある可能性があり、データ更新機能が起動してから正式に決定される価格とは異なる場合があるため、誤差を許容する予測値として取り扱う。
この一定時間内に複数の売買が成立した場合には、この最高値と最低値を予測値とする。また、平均値を予測値としてもよい。
6.更新内容利用者通知機能
本機能は利用者通知部502が持つ機能である。
本システムは、計時機能モジュール201によるサーバ110への利用者登録の際、サーバ110の管理データとして利用者IDを登録するが、この時、サーバ110には利用者の権限も登録される。この権限は本商品取り引き市場での実績に応じて与えられ、権限に応じて利用者は、下記のデータ提供サービスを利用できる。権限は権限１から権限３の３段階で与えられるので、各段階の権限について説明する。
１）権限1:共有データ更新時に通知を受けることができる。
共有データの更新が終了したデータの最新情報を得ることができる。当システムにおいて具体的には午後９時以降、決裁された商品取り引きデータを更新通知により逐次参照することができる。この権限１は、上記「4.データ更新機能」で述べた共有データの更新通知を受けることができる権限である。
２）権限2:共有データ更新前にサーバが管理する共有データ更新要求の内容を受けとることができる。
午前９時の市場開始時から、更新要求受け付け終了までの到着した更新要求データの内容を逐次受けとることができ、最新の市場動向を知ることができる。また、決裁前の更新要求データをもとにした市場動向の予測値を得ることもできる。この権限２は、上記「3.共有データ更新要求管理機能」で述べた更新要求データの転送を受けることができる権限である。
３）権限3:過去の共有データ更新履歴を得ることができる。
過去に渡り共有データの更新履歴を得ることができる。
ただし、上記権限２は権限１を包含し、権限３は権限１、権限２を包含する。利用者の権限は１、２、３のいずれかで登録され、データ参照サービスへの登録要求が利用者からあった時は権限をチェックしてデータ参照サービスへの登録処理がなされる。
以下、上記データ参照サービスの配信処理の説明を行うが、これに先立ち、データ参照サービスの利用者登録について説明する。
図11に示すのは登録された内容を管理するシステムの利用者管理テーブル1100であり、更新要求格納用ディスク403に保存されている。1101には利用者IDが格納され、1102には前述した利用者権限が登録されている。1103以降には当利用者が発行した共有データ更新要求履歴が登録されている。
本実施形態におけるシステムの共有データアクセスは、更新についてはサーバ110に依頼することによって行なわれているが、読出しについては各利用者が直接データベースにアクセスすることにより行なわれている。従って、アクセス履歴として共有データ更新要求発行のみに着目しているが、これは、本発明の制限するところではない。
図12に更新内容通知サービスへの利用者登録処理フローを示す。
図12に示す利用者登録処理フローは権限１に対応する共有データ更新時の通知サービスと、権限２に対応する更新要求データの逐次報告サービスにおいて利用される。
ステップ1201で利用者から通知サービスへの登録要求を受けとると、ステップ1202で当該利用者の権限をチェックし、通知サービスを受ける権限があれば図15に示す権限に応じた通知サービス登録テーブル1501,1502にエントリ1503,1504を追加し、通知サービスが登録されたことを当該利用者に通知する。通知サービス登録テーブル1501,1502には利用者管理テーブル1100への利用者ポインタであるエントリ1503とデータアクセス履歴による通知制限情報であるエントリ1504が格納される。もし、利用者の権限が該通知サービスにそぐわなければステップ1204で該利用者に通知サービス登録テーブルに登録されなかった旨を報告する。
共有データの更新が発生したとき、共有データの更新通知要求を予め登録した利用者（権限１の利用者）に対して、データ更新部504が更新通知を行なうことはすでに説明した。ここでは、データアクセス履歴による制限によりステップ1007の差分データ送信処理がどのように動作するかを説明する。
通知サービス登録テーブル1501,1502中のエントリ1504には無制限であれば０が、一度アクセスした実績のあるレコードに限るのであれば−１が、最後のアクセスから一定期間にかぎるのであれば、当該期間が一時間単位で登録されている。エントリとして０が登録されている時は、無条件で差分データの送信を行なう（利用者の希望により更新があった通知だけ行なわれるよう選択もできる）。−１が登録されている場合は、利用者管理テーブル1100への利用者ポインタから利用者管理テーブル1100をアクセスし、当該利用者が過去に当該レコードにアクセスしたことがあるかどうかを共有データ更新履歴1103〜1105を参照し、参照したことがあれば差分データを送信する。参照有効期間が登録されていれば、履歴情報の当該レコードの最後のアクセス時刻（更新要求発行時刻）を参照し、当該レコードのアクセス履歴があり、最後のアクセス時刻が有効期間内であれば差分データを送信する。
サーバ110が更新要求を受け付けた場合、共有データの更新要求データ800の転送登録がなされている利用者（権限２の利用者）に対して、更新要求データ800の転送を行なうことはすでに述べた。908における通知制限も、前述した1007における処理と同様の処理が行なわれる。
本システムにおいて利用者は、権限３を有していれば、共有データの更新履歴と共有データ更新前の更新要求データ800との通知を要求できる。本システムは、共有データ更新履歴問い合わせ用のポートと更新要求データ問い合わせ用ポートとを備えている。本システムにおいて共有データの更新履歴はデータベースのログ機能をもって実現されており、テーブル、レコード、期間を指定して、利用者がサーバの共有データ更新履歴問い合わせ用のポートにデータ要求を出すと、サーバは利用者の権限チェックの上、データベースに問い合わせを行ない、当該レコードの利用者からの履歴を要求する期間の更新履歴を利用者へ返送する。
共有データ更新前の更新要求データ800を利用者はテーブル指定、レコード指定、アクセス実績のあるレコードのみ指定、あるいは、最後のアクセスから一定期間内にあるレコードのみ指定して、あるいは、これら条件を組合せ、要求することができる。
サーバ110は利用者から上記要求を更新要求データ問い合わせ用ポートに受けると、ユーザ権現を確認の上、キューに保持管理する更新要求データを要求受付の古い順にサーチし条件に合うもののリストを作成して利用者へ返送する。サーバ110は更新要求データ800を受けとると更新要求キューの排他制御用ロックを取得して更新要求データ800を更新要求キューに挿入するが、サーチ処理は更新要求キューの排他制御用ロックを適宜解放しながら実行する。
さて、本システムは共有データと予測値のモニタ機能を備えている。モニタ機能は、共有データそのものとサーバ110が更新要求から算出する予測値とをモニタリングする。たとえば、利用者があるレコード、つまり、銘柄に対し、残数量、取り引き値をモニタすることができる。本システムは、共有データのモニタ要求を受信するモニタ登録ポートと予測値のモニタ要求を受信するモニタ登録ポートを備えている。利用者は本サーバの共有データと、更新要求からの予測値とのいずれかのモニタ登録ポートにテーブル、レコード、モニタ条件を指定してモニタ要求をサーバへ送信する。利用者の権限をチェックの上（共有データのモニタはすべての利用者が利用可能であるが、予測値のモニタには２以上の権限が必要である）、サーバは図13に示すモニタキュー1300にモニタ要求の登録を行なう。モニタキュー1300はレコード単位に管理され、各レコード名（図13においては、“ORG2−E"）をハッシュキーとするハッシュエントリになっている。1301のヘッダはハッシュキーであり、モニタサービス登録テーブル1321〜1323からなるハッシュリンク1399に接続されている。図13には、１つのキューしか図示していないが、モニタキュー1300へのモニタ要求の登録は共有データのモニタ要求と予測値のモニタ要求の２つのキューがある。
図10に示した共有データ更新処理の1007では、利用者へのデータ更新通知処理1006の後、該レコードの共有データのモニタサービス登録テーブル1321〜1323中のモニタ条件をサーチし、現変更により条件を満たしたユーザにその旨を通知する。図13の例で、モニタキューの一番目のモニタサービス登録テーブル1321の利用者は1303の取り引き値と1304の数量の二つの条件を設定しているがいずれか一つの条件が成立すると通知が行なわれる。
なお、上記実施形態では、買い注文と売り注文は商品取り引きにおける注文であったが、商品の売買における注文のみでなく、例えばスーパーマーケットにおける在庫管理等でもよい。この場合は在庫補給要求が買い注文、在庫補給が売り注文に相当し、本発明における買い注文と売り注文とは、あるシステムに対する需要と供給に相当するものであれば他の形態でもよい。
また、上記実施形態では、有効更新要求発行期間として午前９時〜午後３時、更新要求受け付け期間として午前９時〜午後９時を設定しているが、それぞれ他の時間帯でもよく、さらに数分単位あるいは数日単位の設定でもよい。
また更新要求受け付け期間と有効更新要求発行期間が一致する形でも運用可能である。
また、上記各モジュール、各部は、ソフトウエアで実現されても良いし、ハードウエアで実現されても良いし、ソフトウエアとハードウエアの組み合わせで実現されても良い。
産業上の利用可能性
以上のように、本発明に係るデータ更新方式及びデータ更新方法は、データ更新要求発行時刻に基づいて上記共有データの更新を行うようにしたので、利用者端末とサーバとの通信接続状態に依存しない公平なデータ更新を実行することができる。
また、この要求受け付け期間の設定法により、あるいは、有効更新要求発行期間の設定法により、システムの柔軟な運用が可能になる。
また、利用者端末はデータ更新条件の設定法により、システムを柔軟に利用することが可能になる。
また、共有データ更新要求に応じて共有データ更新予測値を決定するようにしたので、利用者端末は自らの共有データ更新要求に対する評価が効率的にくだせる。
また、権限により各利用者端末に送信する情報を選択するようにしたので、サーバは効率的に情報を送信できる。
また、サーバは、一定以上の強度の権限を持つ利用者端末のみに共有データの更新履歴や各利用者端末からのデータ更新要求の内容を送信するようにしたので、サーバはシステムの負荷や、利用者のニーズにあわせて、効率的に情報を送信できる。
また、サーバは、共有データを更新した時に利用者端末に通知するようにしたので、利用者は効率的に判断をくだせる。
また、上記通知の内容には少なくとも共有データの更新前後の差の情報を含むようにしたので、利用者は共有データの再現を容易に行なうことができる。
また、サーバが通知を行う利用者端末は、共有データの更新前に該共有データにアクセスしたことのある利用者端末のみであるようにしたので、システムの負荷や、利用者のニーズにあわせた運用が可能になる。
また、サーバが通知を行う利用者端末は、共有データの更新前の一定期間内に該共有データにアクセスしたことのある利用者端末のみであるようにしたので、システムの負荷や、利用者のニーズにあわせた運用が可能になる。
また、サーバは、利用者端末から情報送信要求があった場合、該利用者端末の共有データへのアクセス履歴を吟味し、該利用者端末が該要求の前に該共有データにアクセスしたことがある場合のみ、該情報送信要求に応答するようにしたので、システムの負荷や、利用者のニーズにあわせた運用が可能になる。
また、サーバは、利用者端末が上記要求前の一定期間内に上記共有データにアクセスしたことがある場合のみ、応答するようにしたので、システムの負荷や、利用者のニーズにあわせた運用が可能になる。
また、情報送信要求は、サーバにすでに到着している共有データ更新処理前のデータ更新要求の内容に対する送信要求であるようにしたので、利用者のニーズにあわせた運用が可能になる。
また、利用者端末が共有データの更新に対して条件を登録し、サーバのデータ更新により該利用者端末が設定した条件が満たされた時に該共有データ管理者が該利用者端末に通知するようにしたので、利用者は共有データの更新を監視することができる。
また、利用者端末が共有データの更新に対して条件を登録し、サーバは、上記の利用者端末または他の利用者端末からのデータ更新要求による共有データ更新予測値が利用者端末が設定した条件を満たした時に利用者端末に通知するようにしたので、利用者は共有データの予測値を知ることができる。
また、上記計時機能は、上記システム管理者のみが解読可能な暗号化処置が施されているので、時系列データ更新を行なう上での不正を防止する。
また、上記計時機能に利用者認証機能を付加したので、利用者を特定し、不正を防止する。
また、サーバは、利用者端末からの共有データ更新要求をメモリに記憶するようにしたので、管理者システムに障害が発生した場合でも、受理したデータ更新を正しく共有データに管理システム復旧後に反映することができる。
また、共有データ更新要求は、第１の条件と数量の条件を含む売り注文または買い注文であり、共有データ更新要求キューにデータ更新要求発行時刻を昇順として保持されており、注文が買い注文の場合、この買い注文に対し昇順にまず第１の条件が合う売り注文を検索し、第１の条件が合えば、次いで数量の条件が合うかどうかを検索するようにし、逆に、注文が売り注文の場合、この売り注文に対し昇順にまず第１の条件が合う買い注文を検索し、第１の条件が合えば、次いで数量の条件が合うかどうかを検索するようにしたので、効率的に条件が合う買い注文と売り注文を検索することができる。

Claims (18)

1. 複数の利用者端末と、利用者間の共有データを管理するサーバとを備えた商品取り引きシステムの データ更新方式において、
   上記複数の利用者端末と上記サーバとは、上記利用者端末と上記サーバとの間で相互に同期が取られた時刻を計時する計時機能モジュールをそれぞれ着脱可能に保持し、
   計時機能モジュールは、
   着脱可能なインターフェースロジックと、
   時刻を計時するクロックと、
   クロックの時計合わせと、サーバアドレスと認証データと暗号鍵とのメモリ設定とを実行するとともに、クロッ クにより計時された時刻をデータ更新要求発行時刻とし て付した共有データ更新要求を生成して、生成した共有 データ更新要求を、メモリ設定された暗号鍵により暗号 化して出力するコントロールロジックとを有し、
   計時機能モジュールは、
   インターフェースロジックを介して上記複数の利用者端末と上記サーバとに着脱可能に装着され、
   上記利用者端末は、
   認証データがメモリ設定された計時機能モジュールが装着されている場合に、上記サーバと通信が可能になり、上記計時機能モジュールにメモリ設定されたサーバアドレスを取得して、サーバとの通信を開始するとともに、
   上記利用者端末は、
   上記共有データの更新要求時、上記計時機能モジュールから、クロックにより計時された時刻をデータ更新要求発行時刻として付して暗号化した共有データ更新要求を 獲得して上記サーバに送信し、共有データ更新要求が上記サーバに受信されるまで、上記データ更新要求発行時刻を当初の送信時と同一としたまま繰り返し送信する更新要求送信処理部を有し、
   上記サーバは、上記利用者端末から受信した共有データ更新要求に付されたデータ更新要求発行時刻に基づき、上記共有データの更新順序を決定する共有データ管理モジュールを有することを特徴とするデータ更新方式。
2. 共有データ管理モジュールは、
   更新要求受け付け期間を設定する更新規則管理部と、
   上記更新要求受け付け期間に受信した共有データ更新要求を受け付ける更新要求管理部とを備えたことを特徴とする請求項１に記載のデータ更新方式。
3. 更新規則管理部は、さらに、上記更新要求受け付け期間よりも短い有効更新要求発行期間を設定し、
   更新要求管理部は、受信した共有データ更新要求のデータ更新要求発行時刻が該有効更新要求発行期間内にある共有データ更新要求を受け付けることを特徴とする請求項２に記載のデータ更新方式。
4. 更新要求送信処理部は、データ更新条件を含む共有データ更新要求をサーバに送信し、
   共有データ管理モジュールは、上記更新要求受け付け期間の終了後、上記共有データ更新要求に含まれたデータ更新条件をデータ更新要求発行時刻の順に吟味し、上記データ更新条件が満足される時、上記共有データ更新要求に応じて共有データ更新値を決定し、上記共有データを該共有データ更新値に更新するデータ更新部を備えたことを特徴とする請求項３に記載のデータ更新方式。
5. データ更新部は、上記有効更新要求発行期間内に、すでに受信した共有データ更新要求に含まれるデータ更新条件をデータ更新要求発行時刻の順に吟味し、上記データ更新条件が満足される場合は、上記共有データ更新要求に基づく共有データ更新予測値を決定することを特徴とする請求項４に記載のデータ更新方式。
6. 共有データ管理モジュールは、利用者端末に対して所定段階に強度が分類された権限の内の１つの権限を付与し、該権限により各利用者端末に送信する情報を選択する利用者通知部を有することを特徴とする請求項１に記載のデータ更新方式。
7. 利用者通知部は、一定以上の強度の権限をもつ利用者端末のみに共有データの更新履歴を送信することを特徴とする請求項６に記載のデータ更新方式。
8. 利用者通知部は、一定以上の強度の権限を持つ利用者端末のみに、各利用者端末からのデータ更新要求の内容を送信することを特徴とする請求項６に記載のデータ更新方式。
9. 共有データ管理モジュールは、共有データを更新した時に利用者端末に通知する利用者通知部を有することを特徴とする請求項１に記載のデータ更新方式。
10. 利用者通知部は、上記通知の内容に、少なくとも共有データの更新前後の差の情報を含むことを特徴とする請求項９に記載のデータ更新方式。
11. 利用者通知部は、共有データの更新前に該共有データにアクセスしたことのある利用者端末に対して通知をすることを特徴とする請求項９に記載のデータ更新方式。
12. 利用者通知部は、共有データの更新前の一定期間内に該共有データにアクセスしたことのある利用者端末に対して通知することを特徴とする請求項９に記載のデータ更新方式。
13. 利用者端末は、サーバに対して情報送信要求を送信し、
    共有データ管理モジュールは、利用者端末から情報送信要求を受信し、該利用者端末の共有データへのアクセス履歴を吟味し、該利用者端末が情報送信要求の受信前に該共有データにアクセスしたことがある場合、該情報送信要求に応答する利用者通知部を有することを特徴とする請求項１に記載のデータ更新方式。
14. 利用者通知部は、利用者端末が上記情報送信要求の受信前の一定期間内に上記共有データにアクセスしたことがある場合、情報送信要求に応答することを特徴とする請求項13に記載のデータ更新方式。
15. 利用者端末からの情報送信要求は、サーバにすでに到着している共有データ更新処理前のデータ更新要求の内容に対する送信要求であることを特徴とする請求項13に記載のデータ更新方式。
16. 利用者端末は、共有データの更新を監視する条件を送信し、
    共有データ管理モジュールは、送信された条件を登録し、共有データ更新により条件が満たされた時に該利用者端末に共有データ更新を通知する利用者通知部を有することを特徴とする請求項１に記載のデータ更新方式。
17. 利用者端末は共有データの更新を監視する条件を送信し、共有データ管理モジュールは、送信された条件を登録し、上記共有データ更新予測値が条件を満たす時に利用者端末に共有データ更新予測値が条件を満たすことを通知する利用者通知部を有することを特徴とする請求項５に記載のデータ更新方式。
18. サーバは、共有データ管理モジュールが受信した各利用者端末からの共有データ更新要求をデータ更新要求発行時刻の順にならべた共有データ更新要求キューを記憶する記憶部を有することを特徴とする請求項１に記載のデータ更新方式。

Images