JP2007042070A - 多数のクライアントとのデータ処理のためのシステムサーバ及びデータ処理方法（ａｓｙｓｔｅｍｓｅｒｖｅｒｆｏｒｄａｔａｐｒｏｃｅｓｓｉｎｇｗｉｔｈｍｕｌｔｉｐｌｅｃｌｉｅｎｔｓａｎｄａｄａｔａｐｒｏｃｅｓｓｉｎｇｍｅｔｈｏｄ） - Google Patents

Abstract

【課題】システム資源を效率的に運用する。
【解決手段】本発明は、有無線通信網を介して接続されたサーバと一つ以上のクライアントとの間のデータ処理のためのシステムサーバ及びデータ処理方法に関する。システムサーバは、クライアントとの接続を開始するか中断する接続モジュールと、上記クライアントとデータを送受信するデータ送受信モジュールと、スレッドを生成して上記クライアントに割り当てるスレッド管理モジュールと、上記クライアントに割り当てられたセッションのＩＤと、上記クライアントが処理を要請した被処理データの処理状態に関する情報とを格納するセッション情報データベース、及び上記セッション情報データベースに格納された当該被処理データの処理状態に関する情報を更新し、当該被処理データの処理状態に基づいてデータ処理を行っていないと判断される場合には、該当セッションを終了するセッション管理モジュールを含む。
【選択図】図２

Description

本発明は、多数のクライアントとのデータ処理のためのシステムサーバ及びデータ処理方法に関する。特に、本発明は、データ処理を安定的かつ效率的にすると共に、クライアントの情報をリアルタイムでモニタリングすることができるシステムサーバ及びデータ処理方法に関する。

最近、企業の内外部の業務をリアルタイムで処理することができる「リアルタイム企業（ＲｅａｌＴｉｍｅＥｎｔｅｒｐｒｉｓｅ；ＲＴＥ）」システムを取り入れる企業が増えつつある。すなわち、企業の内部の業務処理はもちろん外部のパートナー及び顧客に係る業務までリアルタイムで管理して処理できるようにすることで業務效率を極大化するために、ＲＴＥシステムが導入されている。

ところが、ＣＤＭＡまたは無線ＬＡＮなどの無線通信網でＲＴＥシステムのようなデータ処理システムを構築する場合、現在のＩＴインフラの限界のため、データ整合性、データ処理の安全性、システムの信頼性などが依然として足りないのが実情である。特に、サーバに多数のユーザが同時に接続した場合には不要な（ｇａｒｂａｇｅ）セッションによってシステムがダウンする場合がたびたび発生する。

また、ＲＴＥシステムは特に企業外部業務の管理のために、サーバに接続した各クライアントの状態をモニタリングしてクライアントが要請するデータ処理を效率的かつ安定的に処理することが重要な課題である。

本発明は、多数のクライアントとのデータ処理のためのシステムサーバであって、各セッションのデータ処理状態をモニタリングすると共に不要なセッションを管理することにより、システム資源を效率的に運用することを目的とする。

さらに、本発明は、效率的かつ安定的なデータ処理のために、同時接続者の処理及び重複データの処理プロセスを改善することを目的とする。

上記目的を達成するために、本発明は、有無線通信網を介して接続されたサーバと一つ以上のクライアントとの間のデータ処理のためのシステムサーバであって、クライアントとの接続を開始するか中断する接続モジュールと、上記クライアントとデータを送受信するデータ送受信モジュールと、スレッドを生成して上記クライアントに割り当てるスレッド管理モジュールと、上記クライアントに割り当てられたセッションのＩＤと、上記クライアントが処理を要請した被処理データの処理状態に関する情報とを格納するセッション情報データベース、及び上記セッション情報データベースに格納された当該被処理データの処理状態に関する情報を更新し、当該被処理データの処理状態に基づいてデータ処理を行っていないと判断される場合には、該当セッションを終了するセッション管理モジュールを含むシステムサーバを提供する。

また、本発明は、有無線通信網を介して接続されたサーバと一つ以上のクライアントとの間のデータ処理方法であって、（１）クライアントとの接続を開始するか中断するステップと、（２）クライアントとデータを送受信するステップと、（３）スレッドを生成して上記クライアントに割り当てるステップと、（４）上記クライアントに割り当てられたセッションのＩＤと、上記クライアントが処理を要請した被処理データの処理状態に関する情報とをセッション情報データベースに格納するステップと、（５）当該被処理データの処理状態をモニタリングして、上記セッション情報データベースに格納されたデータ処理状態に関する情報を更新するステップと、（６）当該被処理データの処理状態に関する情報に基づいて、当該セッションによってデータ処理が行われているかどうかを判断するステップ、及び（７）上記判断の結果、当該セッションによってデータ処理が行われていないと判断される場合には、当該セッションを終了するステップを含むデータ処理方法を提供する。

本発明によれば、各セッションのデータ処理状態をモニタリングして、このようなデータ処理状態に基づいて現在データ処理を行っていないと判断されるセッションを終了する。このようにして、多数のユーザが同時にサーバに接続した場合、不要なセッションによってシステム資源が無駄使いされることを防止することができる。

また、既存に未処理されたデータまたは伝送過程で誤りの発生したデータは別に管理することで、処理が抜け落ちされるか重複されることを防止することができる。

以下、添付された図面を参照して本発明の好適な実施例に関して詳しく説明する。

図１は、本発明の一実施例に係るデータ処理システム２００を概念的に示すブロック図である。本発明のデータ処理システム２００は、サーバ１００とクライアント（１０−１、１０−２、１０−３；以下"１０"と総称する）、及びサーバ１００とクライアント１０とを接続する有無線通信網２０を含む。本実施例において、サーバ１００は、ＳＡＰ、Ｏｒａｃｌｅ、ＭＳ−ＳＱＬなどの基幹システム１００−１と、互いに異なる機種のクライアント１０とサーバ１００とを連結するミドルウェア１００−２とを含むことにする。

システムサーバ１００の各構成は専用ハードウェアを構成して具現することもでき、通常の汎用コンピューターシステムをプログラミングして具現することももちろん可能である。

図２は、データ処理システム２００のサーバ１００の構成の第１の実施例を示すブロック図である。上記サーバ１００は、接続モジュール１１０と、データ送受信モジュール１２０と、スレッド管理モジュール１３０と、セッション情報データベース１４０、及びセッション管理モジュール１５０を含む。モジュール（１１０ないし１５０）はバスによって相互に繋がれる。

上記接続モジュール１１０は、クライアント１０とサーバ１００との間の接続を開始するか終了する。上記接続の開始または終了は、クライアント１０またはサーバ１００の要請または指示に従って行われても良く、一定の場合に自動で行われても良い。例えば、上記接続モジュール１１０は、クライアント１０から接続要請のある場合、該接続要請に従って接続を開始し、それ以上プロセスを進行することができないか、プロセスを完結した場合には、接続を自動で終了するのが好ましい。特に、クライアントからコミット（ｃｏｍｍｉｔ）メッセージが受信されれば、接続を自動で終了するのがデータ処理料金を低減するにおいて好ましい。

上記データ送受信モジュール１２０は、クライアント１０からデータを受信するかクライアント１０へデータを送信する。

上記スレッド管理モジュール１３０は、スレッドを生成して割り当てる。クライアント１０がサーバに接続すれば、リスナーはスレッド・プール（ｔｈｒｅａｄｐｏｏｌ）に上記クライアントに割り当てる担当スレッドを要請する。この時、上記スレッド管理モジュール１３０は、スレッド・プールに現在待機中の余裕スレッドが存在する場合には、該余裕スレッドを担当スレッドとして割り当て、スレッド・プールに現在待機中の余裕スレッドが存在しない場合には同時接続者の数を確認する。もし接続者の数が許容可能な最大同時接続者の数を超過していない場合には、上記スレッド管理モジュール１３０がスレッドを追加生成してクライアント１０に割り当て、最大同時接続者の数を超過している場合には、該当クライアントはスレッドを割り当てられるために待機する。

上記セッション情報データベース１４０は、現在接続中のクライアント１０それぞれに付与されたセッションＩＤと、該当クライアントが処理を要請した被処理データの処理状態に関する情報とをセッション情報として格納する。ここで被処理データの処理状態とは、例えば、データの処理が開始される前なら「処理待機」、処理中なら「処理中」、処理が終了すれば「処理完了」などと定義された情報を意味する。一方、上記のセッションＩＤはそれぞれのユーザ毎に固有のものに設定されることが好ましい。このように固有のセッションＩＤを付与することにより、各ユーザがどのような装備を利用して接続したのかを追跡することができる。

上記セッション管理モジュール１５０は、上記セッション情報データベース１４０に格納された被処理データの処理状態、すなわちセッション情報を更新し、各セッションを上記セッション情報によって分類する。例えば、上記セッション管理モジュール１５０は、「処理待機」状態にあった被処理データに対する処理が開始されれば、セッション情報データベース１４０に格納されたセッション情報を「処理中」に更新して格納する。セッション管理モジュール１５０は、各セッションのデータ処理状態を継続的にモニタリングして、セッション情報の更新はリアルタイムで行われることが好ましい。

さらに、セッション管理モジュール１５０は、上記データ処理状態に基づいてデータ処理を行っていないと判断される場合には、該当セッションを終了する。例えば、上記セッション管理モジュール１５０は、スレッドの割り当ての時からセッションのデータ処理状態が「処理完了」になるまでかかる時間をチェックしながら、予め定められた時間以上が必要となる場合には該当セッションを終了する。あるいは、セッション管理モジュール１５０は、セッション情報が更新されるのにかかる時間を測定しても良い。この場合、もし一定時間以上経過した後にもセッション情報が更新されなければ、該当セッションがデータ処理を行っていないと見なして該当セッションを終了しても良い。このように、セッション情報、すなわち、セッションのデータ処理状態に基づいてデータ処理を行っていないセッションを終了することにより、サーバ１００を效率的に使うことができる。

データ処理が完了する前にセッションが終了された場合には、サーバ１００がクライアント１０へデータ処理が完了していない旨のメッセージを送信し、クライアント１０は、処理されていない被処理データをローカルメモリーまたはローカルデータベースに格納しておいてから、後でサーバ１００に処理を再び要請することができる。より具体的に、セッション管理モジュール１５０が、セッションのセッション情報に基づいて該当セッションがデータ処理を行っていないと判断した場合には、サーバ１００は、該当セッションを終了してデータ処理が完了していない旨のメッセージをクライアント１０へ送信する。この時、クライアント１０は、処理されていない被処理データをローカルデータベースに格納しておいてから、後でもう一度サーバ１００にデータ処理を要請する。このようにすることで、データ処理の抜け落ちを防止することができる。

図３は、データ処理システム２００のサーバ１００の構成の第２の実施例を示すブロック図である。図２に示された第１の実施例と同じ図面符号を使った構成要素は、第１の実施例とその構成及び機能において類似するので、以下では第１の実施例と異なる部分についてのみ説明する。

具体的に、図３に示されたように、第２の実施例は上記第１の実施例の構成に加えて、バッファーモジュール１６０及びデータ処理モジュール１７０をさらに含む。

本実施例においては、「処理待機」という情報がクライアントのセッション情報としてセッション情報データベースに格納されれば、セッション管理モジュール１５０が、各クライアントからの被処理データを順次にバッファーモジュール１６０に渡すことにより、被処理データがバッファーモジュール１６０に格納される。バッファーモジュール１６０に格納された被処理データは順次にデータ処理モジュール１７０に渡される。すなわち、本実施例においては、クライアント接続の時に割り当てられたスレッドはサーバとクライアントとの間の通信を担当し、データの処理は別のデータ処理モジュールで行うという点で上記した第１の実施例と区別される。データ処理性能を向上するために、上記データ処理モジュール１７０は別のスレッド・プールを有することが好ましい。

このようにバッファーモジュール１６０を、接続モジュール１１０とデータ処理モジュール１７０との間に設けることで、瞬間的に接続者が爆走して多くのデータ処理要請が入って来てもこれらをバッファーに積んで順次に処理することができる。よって、基幹システムにおける処理が遅延してもゲートウェイの性能を維持することが可能である。

一方、サーバ１００は、検査モジュール１８０及び／または誤りデータ管理モジュール１９０をさらに含むことができる。上記検査モジュール１８０は、クライアント１０から送信された被処理データに異常があるかどうかを検査する。

誤りデータ管理モジュール１９０は、データ処理モジュール１７０が被処理データのデータ処理を完了したが当該データ処理結果をクライアント１０へ伝送する過程で誤りが発生した場合に、当該被処理データを格納する格納装置を含む。さらに、上記誤りデータ管理モジュール１９０の格納装置は当該データ処理結果を格納する。

検査モジュール１８０がクライアント１０から受信された被処理データに異常があると判断した場合、クライアント１０へエラーメッセージが送信される。次に、スレッドを返し、セッションを終了することで、該当プロセスを終える。この場合、クライアント１０は、処理されていないデータをローカルメモリーまたはローカルデータベースに格納しておいてから、後でバッチ（ｂａｔｃｈ）処理することが好ましい。このように、サーバ１００が受信した被処理データに異常がある場合、当該被処理データをクライアント１０のローカルデータベースに格納しておいてから、後で再び処理することにより、データ処理の抜け落ちを防止することができる。

一方、クライアント１０から受信された被処理データに異常がないと判断した場合は、検査モジュール１８０は、誤りデータ管理モジュール１９０に上記被処理データと同じデータの処理結果が格納されているかどうかを確認する。より具体的に、例えば、各クライアント１０が被処理データをサーバ１００へ伝送する時、当該被処理データに識別字（ＩＤ）を付与し、検査モジュール１８０が、当該被処理データの識別字と誤りデータ管理モジュール１９０に格納されたデータの識別字とを比べることで、誤りデータ管理モジュール１９０が当該被処理データの処理結果を格納しているかどうかを判断する。本例において、誤りデータ管理モジュール１９０は、データの識別字及び／またはデータそのものを格納することができる。上記判断の結果、誤りデータ管理モジュール１９０に被処理データと同じデータの処理結果が格納されている場合、誤りデータ管理モジュール１９０に格納された当該処理結果が当該被処理データの処理結果としてクライアント１０へ伝送される。

このように、既に処理が完了したがその結果をクライアント１０へ伝送する段階で誤りが発生した場合には、サーバ１００が当該データの処理結果を別に格納して管理する。このようにして、クライアント１０が同じデータの処理を要請する時は、再びデータ処理を行うことなく既に格納されたデータ処理結果を伝送することで、結果的にデータ処理が重複されるのを防止することができる。

図４は、本発明に係るデータ処理方法の一実施例において、サーバ１００側のデータ処理過程の一例を示すフローチャートである。

図４ａは、プロセス開始からクライアントにスレッドを割り当てる過程を示す。クライアント１０から接続要請を受信（Ｓ４００）すれば、接続モジュール１１０は、サーバ１００とクライアント１０との間の接続を開始（Ｓ４１０）し、セッション管理モジュール１５０は、該当クライアントに対するセッションを生成（Ｓ４２０）する。この時、それぞれのユーザ毎に固有のセッションＩＤを付与することで、各ユーザが同一のセッションＩＤでどのような装備を利用して接続したのかを追跡することができる。

次に、スレッド・プールにスレッドを要請（Ｓ４３０）すれば、スレッド管理モジュール１３０は、スレッド・プールに現在待機中の余裕スレッドが存在するかどうかを判断（Ｓ４４０）して、スレッド・プールに現在待機中の余裕スレッドが存在する場合（Ｓ４４０：Ｙｅｓ）には該余裕スレッドを該当クライアント１０に担当スレッドとして割り当て、スレッド・プールに現在待機中の余裕スレッドが存在しない場合（Ｓ４４０：Ｎｏ）には同時接続者の数を確認（Ｓ４５０）する。もし接続者の数が許容可能な最大同時接続者の数を超過していない場合（Ｓ４５０：Ｎｏ）にはスレッドを追加生成（Ｓ４６０）して割り当てるが（Ｓ４７０）、最大同時接続者の数を超過している場合（Ｓ４５０：Ｙｅｓ）にはスレッドを割り当てられるために待機する。

クライアント１０に担当スレッドが割り当てられれば、図４ｂに示されたように、サーバのデータ送受信モジュール１２０はクライアント１０が処理を要請した被処理データを読み込み（Ｓ４８０）、この被処理データに異常があるか否かを検査（Ｓ４９０）する。もし被処理データに異常がある場合（Ｓ４９０：Ｎｏ）にはクライアント１０へエラーメッセージを送信（Ｓ５００）してプロセスを終了する。上述したように、エラーメッセージを受信したクライアント１０は、被処理データをローカルデータベースに格納することが好ましい。

被処理データに異常がない場合（Ｓ４９０：Ｙｅｓ）には、誤りデータ管理モジュール１９０に格納されているデータの中で被処理データと同一のものが存在するかどうかを確認する（Ｓ５１０）。これは上述したように、クライアント１０へ被処理データを送信する時、各データに固有のＩＤを付与し、誤りデータ管理モジュール１９０に格納されている既存のデータの中で被処理データと同一のＩＤを持つものがあるかどうかを比べることで可能である。もし誤りデータ管理モジュール１９０に被処理データと同一のＩＤを持つデータがあれば（Ｓ５１０：Ｙｅｓ）、誤りデータ管理モジュール１９０に格納された当該データの既存の処理結果をクライアント１０へ送信（Ｓ５２０）し、送信が正常に行われば該当プロセスが終了する。

誤りデータ管理モジュール１９０に当該被処理データと同一のデータが格納されていない場合（Ｓ５１０：Ｎｏ）には、被処理データの処理が開始される。この時、処理の開始に先立って「処理待機」という情報が該当クライアントのセッション情報としてセッション情報データベース１４０に格納（Ｓ５３０）される。次に、被処理データはバッファーモジュール１６０に格納（Ｓ５４０）された後、データ処理モジュール１７０に順次に渡される。このように被処理データを一応バッファーに格納することで、瞬間的に接続者が爆走しても被処理データをバッファーに積んで順次にデータを処理することができ、基幹システムにおける処理が遅れてもゲートウェイでの処理要請を遅延させないようにすることができる。

データ処理モジュール１７０で該当被処理データの処理が開始されれば、該当クライアント１０のセッション情報は「処理中」に更新（Ｓ５５０）され、処理が完了すればセッション情報が「処理完了」に更新（Ｓ５６０）される。

被処理データの処理が完了すれば、該当被処理データの処理を要請したクライアント１０へその結果が送信されるが、伝送が正常に行われると（Ｓ５７０：Ｎｏ）、クライアント１０がコミットメッセージをサーバ１００へ送信する。コミットメッセージが受信されれば、該当クライアント１０に割り当てられたスレッドをスレッドプールに返し、該当セッションを終了する（Ｓ５９０）ことでプロセスが終了する。

もしクライアント１０へのデータ送信の時に誤りが発生（Ｓ５７０：Ｙｅｓ）すれば、データ処理結果は誤りデータ管理モジュール１９０に格納（Ｓ５８０）され、プロセスが終了する。

一方、本発明は、セッションのデータ処理過程をモニタリングすることで、データ処理を行っていないセッションを終了する。例えば、スレッドを割り当てた時点からデータ処理を開始した時点、データ処理開始の時からデータ処理完了の時までの時間などをチェックして、この時間が予め定められた基準時間を超過する場合には、データ処理を行っていないと見なしてセッションを終了する。これはスレッド割り当てモジュール、バッファー、データ処理モジュールなどと連動するセッション管理モジュールがセッションのデータ処理状態を持続的にモニタリングすることで可能である。このようにすることで、不要なセッションによってシステム資源が無駄使いされることを防止することができる。

この場合、サーバ１００は、クライアント１０へデータ未処理メッセージを送信することが好ましい。データ未処理メッセージを受信すれば、クライアント１０は該当データをローカルデータベースに格納しておいてから、後でバッチ処理することで処理の抜け落ちを防止することができる。

図５は、本発明に係るデータ処理方法の一実施例において、クライアント１０側の処理過程を示すフローチャートである。

クライアント１０は、サーバに接続要請を送って（Ｓ１０００）、接続が正常に行われるとデータ処理要請をサーバ１００へ送信（Ｓ１１００）し、被処理データをローカルデータベースに格納する（Ｓ１２００）。もしデータ送信が正常に行われなければ（Ｓ１３００：Ｙｅｓ）、ローカルデータベースに格納しておいてから、後でバッチで一括処理する。

データ送信が正常に行われると（Ｓ１３００：Ｎｏ）、データ処理結果が受信されるまで待機する（Ｓ１４００）。もしサーバ１００から該当クライアント１０のセッションでデータ処理を行わない旨のデータ未処理メッセージを受信するか、またはサーバ１００のデータ処理が終了した後で処理されたデータを受信する過程で誤りが発生すれば（Ｓ１５００：Ｙｅｓ）、データ送信の時に誤りが発生した場合と同様にローカルデータベースに格納しておいてから、後でバッチで一括処理する。

処理されたデータが正常に受信（Ｓ１５００：Ｎｏ）されると、コミットメッセージをサーバ１００へ送信（Ｓ１６００）し、被処理データをローカルデータベースから削除することでプロセスを終了（Ｓ１７００）する。

以上、本発明の好ましい実施例に関して具体的に説明したが、本発明の技術的範囲はこれに限定されない。本発明の技術的範囲は特許請求の範囲によって決まり、本発明の技術的範囲内で上記の実施例の様々な変形及び修正が可能である。

本発明の一実施例に係るデータ処理システム２００を概念的に示すブロック図である。 データ処理システム２００のサーバ１００の構成の第１の実施例を示すブロック図である。 データ処理システム２００のサーバ１００の構成の第２の実施例を示すブロック図である。 本発明に係るデータ処理方法の一実施例において、サーバ１００側の処理過程を示すフローチャートである。 本発明に係るデータ処理方法の一実施例において、サーバ１００側の処理過程を示すフローチャートである。 本発明に係るデータ処理方法の一実施例において、クライアント１０側の処理過程を示すフローチャートである。

符号の説明

１０ クライアント
２０ 有無線通信網
１００ サーバ
１００−１ 基幹システム
１００−２ ミドルウェア
１１０ 接続モジュール
１２０ データ送受信モジュール
１３０ スレッド管理モジュール
１４０ セッション情報データベース
１５０ セッション管理モジュール
１６０ バッファーモジュール
１７０ データ処理モジュール
１８０ 検査モジュール
１９０ 誤りデータ管理モジュール
２００ データ処理システム

Claims (16)

1. 有無線通信網を介して接続されたサーバと一つ以上のクライアントとの間のデータ処理のためのシステムサーバであって、
   クライアントとの接続を開始するか中断する接続モジュールと、
   前記クライアントとデータを送受信するデータ送受信モジュールと、
   スレッドを生成して前記クライアントに割り当てるスレッド管理モジュールと、
   前記クライアントに割り当てられたセッションのIDと、前記クライアントが処理を要請した被処理データの処理状態に関する情報とを格納するセッション情報データベース、及び、
   前記セッション情報データベースに格納された当該被処理データの処理状態に関する情報を更新し、当該被処理データの処理状態に基づいてデータ処理を行っていないと判断される場合には、該当セッションを終了するセッション管理モジュールを含むシステムサーバ。
2. 前記セッション管理モジュールは、当該被処理データの処理状態に関する情報が所定時間更新されない場合、該当セッションを終了することを特徴とする請求項１に記載のシステムサーバ。
3. 前記セッション管理モジュールは、スレッドの割り当ての時からデータ処理を開始する時までの期間が所定時間を超過した場合、該当セッションを終了することを特徴とする請求項１に記載のシステムサーバ。
4. 前記セッション情報データベースに格納されたデータ処理状態に関する情報は、処理待機、処理中、処理完了に分類されることを特徴とする請求項１から３のいずれか一項に記載のシステムサーバ。
5. 前記セッションのＩＤは、各ユーザに固有のものであることを特徴とする請求項１から３のいずれか一項に記載のシステムサーバ。
6. 前記サーバは、当該被処理データが正常であるかどうかを検査する検査モジュールをさらに含み、
   当該被処理データにエラーがある時は、クライアントへエラーメッセージを送信することを特徴とする請求項１から３のいずれか一項に記載のシステムサーバ。
7. 前記サーバは、被処理データの処理が正常に完了したがその処理結果をクライアントへ送信する過程で誤りが発生した場合、前記被処理データの処理結果を格納する誤りデータ管理モジュールをさらに含み、
   前記検査モジュールは、さらに、当該被処理データの処理に先立って、前記誤りデータ管理モジュールが当該被処理データと同じデータの処理結果を格納しているか否かを検査し、もし当該被処理データと同じデータの処理結果を格納していると判断された場合には、前記誤りデータ管理モジュールに格納された被処理データの処理結果をクライアントへ送信することを特徴とする請求項６に記載のシステムサーバ。
8. 被処理データを順次に格納するバッファーモジュール、及び、
   前記バッファーモジュールから伝送された被処理データの処理を順次に行うデータ処理モジュールをさらに含むことを特徴とする請求項１に記載のシステムサーバ。
9. 有無線通信網を介して接続されたサーバと一つ以上のクライアントとの間のデータ処理方法であって、
   （１）クライアントとの接続を開始するか中断するステップと、
   （２）クライアントとデータを送受信するステップと、
   （３）スレッドを生成して前記クライアントに割り当てるステップと、
   （４）前記クライアントに割り当てられたセッションのＩＤと、前記クライアントが処理を要請した被処理データの処理状態に関する情報とをセッション情報データベースに格納するステップと、
   （５）当該被処理データの処理状態をモニタリングして、前記セッション情報データベースに格納されたデータ処理状態に関する情報を更新するステップと、
   （６）当該被処理データの処理状態に関する情報に基づいて、当該セッションによってデータ処理が行われているかどうかを判断するステップ、及び、
   （７）前記判断の結果、当該セッションによってデータ処理が行われていないと判断される場合には、当該セッションを終了するステップ
   を含むデータ処理方法。
10. 前記セッション情報データベースに格納された被処理データの処理状態に関する情報に基づいて当該セッションにおいてデータ処理に必要となる時間を測定して、前記測定された時間を所定時間と比較し、
    前記比較の結果、前記データ処理に必要となる時間が前記所定時間を超過する場合、前記ステップ（６）において、当該セッションにおいてデータ処理が行われていないと判断する請求項９に記載のデータ処理方法。
11. （８）当該セッションにおいてデータ処理が正常に完了したと判断された場合にはその処理結果をクライアントへ送信し、当該セッションを終了するステップをさらに含む請求項９に記載のデータ処理方法。
12. （８−１）前記処理結果をクライアントへ送信する時に誤りが発生した場合、前記処理結果を格納装置に格納するステップをさらに含むことを特徴とする請求項１１に記載のデータ処理方法。
13. （２−１）データ処理に先立って、当該クライアントから受信した被処理データに異常があるか否かを検査するステップ、及び、
    （２−２）前記（２−１）において当該被処理データに異常がないと判断された場合には、データ処理に先立って、前記格納装置が当該被処理データの処理結果を格納しているか否かを検査するステップをさらに含み、
    前記ステップ（２−１）の検査の結果、当該被処理データに異常があると判断されれば、クライアントへエラーメッセージを送信し、
    前記ステップ（２−２）の検査の結果、前記格納装置が当該被処理データの処理結果を格納していると判断されれば、前記格納装置に格納された処理結果をクライアントへ送信することを特徴とする請求項１２に記載のデータ処理方法。
14. 前記ステップ（４）において、前記セッション情報データベースに格納されたデータ処理状態に関する情報は、処理待機、処理中、処理完了に分類されることを特徴とする請求項９に記載のデータ処理方法。
15. （４−１）該当セッションのデータ処理状態に関する情報が処理待機である場合、当該被処理データをバッファーに順次に格納するステップをさらに含むことを特徴とする請求項１４に記載のデータ処理方法。
16. 前記セッションのＩＤは、各ユーザに固有のものであることを特徴とする請求項９に記載のデータ処理方法。

Images