JP2018041213A - システム、クライアント装置、サーバー装置、およびプログラム - Google Patents

Abstract

【課題】クライアント側とサーバー側でのチェックのためのルールを一元的に管理するとともに、クライアント種別を制限することなく、またルールの更新タイミングを制限することなく、ルールの更新を行うことのできるシステムを提供する。【解決手段】クライアント装置は、第１ルール記憶部と、第１チェック実行部と、ユーザーインタフェース制御部と、リクエスト送信部と、ルール更新部とを持つ。ルール更新部は、所定のトリガーに基づいて、第１ルール記憶部を更新するためのルールをサーバー装置に要求するとともに、要求への応答としてサーバー装置から送られるルールを用いて第１ルール記憶部を更新する。サーバー装置は、クライアント用ルール生成部を持つ。クライアント用ルール生成部は、ルール更新部からルールの要求を受けると、クライアント用のルールを生成し、生成したルールを要求元のクライアント装置に送信する。【選択図】図１

Description

本発明の実施形態は、システム、クライアント装置、サーバー装置、およびプログラムに関する。

コンピューターのアプリケーションシステムにおいて、ユーザーが画面上のフィールド等に入力した値に不備がないかどうかをチェックする入力チェックが行われる。通常、アプリケーションシステムがこのような入力チェック機能を有する。

クライアント・サーバー方式のシステムにおいて、クライアント装置側のユーザーインタフェースで入力された情報は、クライアント装置とサーバー装置の両方がチェックを行う。クライアント装置のみ、あるいはサーバー装置のみがチェックを行う方法では、チェックとして不十分である。
仮にクライアント装置のみでチェックする方式とした場合、クライアント側のユーザーが正規の画面への入力を行わずに、他の何らかの手段を用いて直接、サーバー装置へのリクエストを発行することがあり得る。この場合には、クライアント装置でのチェックを通らないリクエストが発生し得る。すると、不正な入力情報（例えば、データの型の不正や、数値範囲の不正など）をサーバー装置側で処理してしまう可能性が生じる。
また、仮にサーバー装置のみでチェックする方式とした場合、不正な入力情報であってもクライアント装置側からサーバー装置側にリクエストを送信してしまう状況が生じ得る。これにより、通信ネットワークやサーバー装置の負荷が高くなってしまうという問題が起こり得る。また、クライアント装置側での入力チェックが行われないと、ユーザーの操作性が低下する場合があり得る。

以上の理由により、クライアント装置側およびサーバー装置側の両方で、同等の入力情報チェックを行う必要がある。しかし、クライアント装置側とサーバー装置側の両方で同党の入力チェックを行うためには、そのチェックのためのルールや、チェックの結果がエラーであった場合に画面等に表示するメッセージを、それぞれの側で管理する必要がある。すると、チェックのためのルールと、エラー時のメッセージとを、クライアント用およびサーバー用の２種類維持しなければならなくなり、アプリケーションシステムの開発コストあるいは維持コストが余計にかかり、生産性が下がってしまうという問題がある。また、情報の管理が煩雑になり、ルールやメッセージ等を変更の場合に、変更漏れが生じ、クライアントとサーバーの両者間で不整合が生じる可能性が出てきて、アプリケーションシステムの保守性が悪くなる。

従来の技術においては、上記のような保守性の低下を防ぐための仕組みを工夫したシステムが存在する。
その従来技術では、クライアント装置がサーバー装置に対して画面遷移のリクエストを送ったタイミングで、サーバー装置はクライアント装置側のチェック実行機能を、クライアント装置に送信する。そのようなチェック実行機能は、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）で書かれたソースコードとして、サーバー装置からクライアント装置に送信される。このような従来技術によれば、チェックルールをサーバー装置側で一元的に管理することも可能となる。なお、この従来技術では、クライアント装置側がＪａｖａＳｃｒｉｐｔ（登録商標）の実行環境を有していることを前提としている。より具体的には、この従来技術では、クライアント装置側が、ＪａｖａＳｃｒｉｐｔ（登録商標）の仮想マシンを備えたウェブブラウザーを用いて実現されることを前提としている。

しかしながら、上記のような従来技術にも、次の問題がある。
第１に、クライアント装置側がウェブブラウザーで実現される場合にしか上記の従来技術を適用することができない。つまり、近年増加しつつある、スマートフォンで稼働するアプリケーションや、ＩｏＴ（Internet of Things）の端末装置などをクライアント側で用いる場合には、上記の従来技術を適用することができない。
第２に、クライアント装置とサーバー装置との間で入力チェックのルールを設定（最新のルールを適用して同期させる）するタイミングが、クライアント装置側からサーバー装置側に画面遷移のリクエストを送信したタイミングに限定されてしまう。そして、その他のタイミングにおいては入力チェックのルールを変更することができない。つまり、一旦ルールを設定すると、次にクライアント装置側から画面遷移のリクエストを送るタイミングまでは、ルールを変更することができない。

特開２００９−１８１３２０号公報

本発明が解決しようとする課題は、クライアント側とサーバー側でのチェックのためのルールを一元的に管理するとともに、クライアント種別を制限することなく、またルールの更新タイミングを制限することなく、ルールの更新を行うことのできるシステム、クライアント装置、サーバー装置、およびプログラムを提供することである。

実施形態のシステムは、クライアント装置とサーバー装置とを持つ。
クライアント装置は、第１ルール記憶部と、第１チェック実行部と、ユーザーインタフェース制御部と、リクエスト送信部と、ルール更新部とを持つ。第１ルール記憶部は、入力チェックに関するルールを記憶する。第１チェック実行部は、前記第１ルール記憶部に記憶されている前記ルールに基づいて入力データをチェックする。ユーザーインタフェース制御部は、ユーザーインタフェースを通して入力データを受け付ける。リクエスト送信部は、前記サーバー装置側に送信するためのリクエストに含まれる前記入力データの入力チェックを前記第１チェック実行部に依頼するとともに、チェック結果が合格であれば前記リクエストを前記サーバー装置に送信する。ルール更新部は、所定のトリガーに基づいて、前記第１ルール記憶部を更新するためのルールを前記サーバー装置に要求するとともに、前記要求への応答として前記サーバー装置から送られるルールを用いて前記第１ルール記憶部を更新する。
サーバー装置は、第２ルール記憶部と、第２チェック実行部と、リクエスト受信部と、クライアント用ルール生成部とを持つ。第２ルール記憶部は、入力チェックに関するルールを記憶する。第２チェック実行部は、前記第２ルール記憶部に記憶されている前記ルールに基づいて入力データをチェックする。リクエスト受信部は、前記リクエスト送信部から送信される前記リクエストを受信するとともに、前記リクエストに含まれる前記入力データの入力チェックを前記第２チェック実行部に依頼する。クライアント用ルール生成部は、前記ルール更新部から前記ルールの要求を受けると、前記第２ルール記憶部から読み出したルールに基づいてクライアント用のルールを生成し、生成したルールを要求元の前記クライアント装置に送信する。

第１の実施形態のアプリケーションシステムの概略機能構成を示すブロック図。 第１の実施形態のサーバー装置側で入力チェックのルールを更新する処理の手順を示すシーケンスチャート。 第１の実施形態のクライアント装置側で入力チェックのルールを更新する処理の手順を示すシーケンスチャート。 第１の実施形態のクライアント装置側からサーバー装置側へのリクエストの送信に伴う、入力チェックの処理の手順を示すシーケンスチャート。 第１の実施形態のサーバー装置側でルール読込部が読み込む入力チェックルールの構成を示す概略図。 第１の実施形態のサーバー装置側のルール記憶部のデータ構成を示す概略図。 第１の実施形態のサーバー装置側からクライアント装置側に更新のために送られるルールのデータ（ＪＳＯＮ形式）の例を示す概略図。 第１の実施形態のクライアント装置側からサーバー装置側に送られるリクエストのデータ例を示す概略図。 第１の実施形態のクライアント装置側およびサーバー装置側での、チェック実行部による判断の分岐を示すディシジョンチャート。 第２の実施形態のアプリケーションシステムの概略機能構成を示すブロック図。 第２の実施形態のクライアント装置側で入力チェックのルールを更新する処理の手順を示すシーケンスチャート。 第２の実施形態のクライアント装置側からサーバー装置側へのリクエストの送信に伴う、入力チェックの処理の手順を示すシーケンスチャート。 第２の実施形態のチェック結果記憶部が記憶するチェック結果データの構成および例を示す概略図。 第２の実施形態において、サーバー装置側からクライアント装置側に更新のために送られるルールのデータの例を示す概略図。 第２の実施形態において、リクエストの際に入力画面から入力されたデータの例を示す概略図。

以下、実施形態のシステム、クライアント装置、サーバー装置、およびプログラムを、図面を参照して説明する。

（第１の実施形態）
ここでは、第１の実施形態について説明する。
まず、機能の構成について説明する。
図１は、本実施形態によるアプリケーションシステムを構成する装置と、各装置における概略機能構成とを示す、ブロック図である。なお、同図では、入力情報のチェックと、そのルールの維持・更新に関する機能のみを示している。つまり、同図では、適用業務に特有の機能を示していない。
図示するように、アプリケーションシステム１は、クライアント装置２とサーバー装置３とを含んで構成される。クライアント装置２は、例えば、パーソナルコンピューター（ＰＣ）や、スマートフォンや、タブレット端末や、ウェアラブル端末などを用いて実現される。サーバー装置３は、サーバー用コンピューターを用いて実現される。クライアント装置２とサーバー装置３との間は、通信回線（インターネットを含む）で結ばれており、相互に通信可能となっている。

クライアント装置２は、ＵＩ制御部１０１と、リクエスト送信部１０２と、トリガー生成部２０１と、ルール更新部２０２と、ルール受信部２０３と、ルール記憶部２０４と、チェック実行部２０５と、を含んで構成される。
また、サーバー装置３は、リクエスト受信部１０３と、処理実行部１０４と、ルール読込部３０２と、ルール記憶部３０３と、クライアント用ルール生成部３０４と、チェック実行部３０５とを含んで構成される。
アプリケーションシステム１は、クライアント装置２側とサーバー装置３側とで、統合的に入力情報チェックのためのルールを管理する。そのための各部の機能について、次に説明する。

以上列挙した各部の機能は、電子回路を用いて実現される。また、コンピューターとプログラムとを用いて、各部の機能を実現するようにしてもよい。また、各部において、情報を記憶する場合には、磁気ハードディスク装置や半導体メモリなどといった記憶媒体・記録媒体を用いるようにする。

クライアント装置２側の各部の機能は、次の通りである。
ＵＩ制御部１０１は、クライアント側のユーザーインタフェースを制御する機能を有する。ＵＩ制御部１０１は、ユーザーインタフェースの一つとして、クライアント装置２の画面等から情報を入力するための機能を実現する。ＵＩ制御部１０１は、例えば、画面内に情報を入力するためのフィールドを表示し、そのフィールドに入力される情報を取得する。フィールドは、テキストや数字を入力するためのフィールドの他に、プルダウンメニューや、チェックボックスや、ラジオボタンなどといった、情報入力のための手段を含む。つまり、ＵＩ制御部１０１は、ユーザーインタフェースを通して入力データを受け付ける機能を有する。
リクエスト送信部１０２は、ＵＩ制御部１０１が取得した情報を受けとり、それらの情報に基づくリクエストをサーバー装置３に対して送信する。なお、リクエスト送信部１０２は、サーバー装置３にリクエストを送信する前に、入力された情報のチェックをチェック実行部２０５に依頼する。つまり、リクエスト送信部１０２は、サーバー装置３側に送信するためのリクエストに含まれる入力データの入力チェックをチェック実行部２０５に依頼するとともに、チェック結果が合格であればリクエストをサーバー装置３に送信するものである。チェック実行部２０５によるチェックの結果、エラーがなかった場合には、リクエスト送信部１０２は、上記のリクエストを送信する。チェック実行部２０５によるチェックの結果、エラーがあった場合には、リクエスト送信部１０２は、上記のリクエストを送信せず、エラーメッセージを表示するようＵＩ制御部に処理を戻す。

トリガー生成部２０１は、トリガーを生成し、ルール更新部２０２にそのトリガーを通知する。このトリガーは、入力チェックのルールを更新するきっかけとなるものである。トリガーは、例えば、アプリケー起動や、画面上の入力フィールドのアクティブ化など、任意の事象によって生じるものである。トリガー生成部２０１がどのような事象に基づいてトリガーを生成するかは、別途定めておくことができる。アプリケーションシステムに望まれる挙動に基づいて、トリガーを予め定義しておくようにすればよい。

ルール更新部２０２は、トリガー生成部２０１からの要求（トリガー）に応じて、サーバー装置３側に、クライアント装置用（自装置用）に入力チェックのルールを更新することを要求する。具体的には、ルール更新部２０２は、サーバー装置３の、クライアント用ルール生成部３０４に、ルールの更新を要求する。
また、ルール更新部２０２は、上記の要求に応じてルール受信部２０３が受信するルールを取得し、取得したルールで、ルール記憶部２０４を更新する。
つまり、ルール更新部２０２は、所定のトリガーに基づいて、ルール記憶部２０４を更新するためのルールをサーバー装置３に要求するとともに、その要求への応答としてサーバー装置３から送られるルールを用いてルール記憶部２０４を更新するものである。
ルール受信部２０３は、ルール更新部２０２からの要求に基づいてクライアント用ルール生成部３０４が生成したルールを受信する。ルール受信部２０３は、受信したルールをルール更新部２０２に渡す。

ルール記憶部２０４は、クライアント装置２側での入力チェックに使用するルールを、記憶する。上述した通り、ルール記憶部２０４に記憶されるルールは、ルール更新部２０２によって所定のタイミングで更新される。なお、ルール記憶部２０４は、磁気ハードディスク装置や半導体メモリなどの記憶手段を用いて実現される。
チェック実行部２０５は、ルール記憶部２０４に記憶されているルールを参照することによって、そのルールに基づいて、入力情報のチェックを実行する。前述の通り、チェック実行部２０５は、リクエスト送信部１０２からの依頼に基づいて、入力情報のチェックを行う。チェック実行部２０５は、チェックを実行した結果、エラーがあったか否かを表す情報を、リクエスト送信部１０２に返す。つまり、チェック実行部２０５は、リクエスト送信部１０２から渡されるリクエストをサーバー装置３側に送信してよいかどうかを判定する。

サーバー装置３側の各部の機能は、次の通りである。
リクエスト受信部１０３は、クライアント装置２側のリクエスト送信部１０２から送信されるリクエストを受信する。そして、リクエスト受信部１０３は、チェック実行部３０５に、受信したリクエスト内に含まれる情報（クライアント装置２側で入力された情報）のチェックを依頼する。つまり、リクエスト受信部１０３クライアント装置２側から送信されるリクエストを受信するとともに、リクエストに含まれる入力データの入力チェックをチェック実行部３０５に依頼するものである。チェック実行部３０５のチェックの結果、エラーが発見されなかった場合には、リクエスト受信部１０３は、処理実行部１０４にそのリクエストの処理を依頼する。チェック実行部３０５のチェックの結果、エラーが発見された場合には、リクエスト受信部１０３は、エラー時のための例外処理に制御を渡す。
処理実行部１０４は、リクエスト受信部１０３から渡されるリクエストの内容に応じた処理を実行する。なお、処理実行部１０４が実行する具体的な処理の内容は、アプリケーションシステム１がカバーする業務の内容に依存するものである。

ルール読込部３０２は、外部から渡される入力チェックのルールを読み込み、読み込んだルールの情報に基づいて、ルール記憶部３０３に記憶されているルールを更新する。なお、ルール読込部３０２に渡されるルールは、所定の様式で記述されたルールである。
ルール記憶部３０３は、サーバー装置３側において、入力チェックのためのルールを記憶する。ルール記憶部３０３が記憶するルールは、サーバー側のチェック実行部３０５によってチェックのために参照されるとともに、クライアント装置２側に渡すルールを生成するためにクライアント用ルール生成部３０４によって参照される。なお、ルール記憶部３０３は、磁気ハードディスク装置や半導体メモリなどの記憶手段を用いて実現される。

クライアント用ルール生成部３０４は、クライアント装置２側からの要求に応じて、ルール記憶部３０３から入力チェック用のルールを読み込み、クライアント側の入力チェックルールを作成し、クライアント装置２側に送信する。

チェック実行部３０５は、ルール記憶部３０３に格納されているルールを読み出し、そのルールに基づいて、リクエスト受信部１０３から依頼されたリクエストに含まれる入力情報をチェックする。チェックの結果、エラーが含まれていた場合には、チェック実行部３０５は、そのリクエストを処理しないようリクエスト受信部１０３に応答する。チェックの結果、エラーが含まれていなかった場合には、チェック実行部３０５は、そのリクエストの処理を引き続き実行するようリクエスト受信部１０３に応答する。

以上、図１に示した機能構成では、クライアント装置２側での入力情報のチェックとサーバー装置３側での入力情報のチェックを、同じルールに基づいて実行できる。ルールは、元々、サーバー装置３側で一元的に管理される。また、所定のトリガーに基づいて、クライアント装置側のルール更新部２０２が、サーバー装置３側のクライアント用ルール生成部３０４に対して、ルールの更新を要求する。この要求があったとき、クライアント用ルール生成部３０４は、その時点でルール記憶部３０３に記憶されているルールの情報に基づいて、クライアント装置２用のルールを生成し、クライアント装置２側に返信する。生成されたルールを受信すると、クライアント装置２側のルール更新部２０２は、ルールを記憶しているルール記憶部２０４を更新する。つまり、画面遷移のタイミングに限らず、任意のトリガーのタイミングで、クライアント装置２側のルールを更新することができる。クライアント装置２が複数台存在している場合にも、同様に機能する。また、クライアント装置２の種類が複数ある（例えば、パーソナルコンピューターとスマートフォンなど）場合にも、それぞれのクライアント装置２で、サーバー装置３から送られる最新のルールを用いた入力チェックを行える。

次に、アプリケーションシステム１における主要な処理について、順に説明する。
図２は、サーバー装置側で入力チェックのルールを更新する処理の手順を示すシーケンスチャートである。なお、このサーバー装置側でのルール更新の処理は、例えば、アプリケーションシステムの起動時あるいは再起動時に実行される。ただし、アプリケーションシステムの稼働中や、アプリケーションシステムの停止中に、サーバー装置側でのルール更新を行うようにしてもよい。
まずステップＳ１において、ルール読込部３０２は、入力チェックルールを読み込む。なお、この入力チェックルールは、例えばテキストファイルとして与えられるものである。
次にステップＳ２において、ルール読込部３０２は、読み込んだ入力チェックルールを用いて、ルール記憶部３０３に保持されているルールを更新する。

図３は、クライアント装置側で入力チェックのルールを更新する処理の手順を示すシーケンスチャートである。このクライアント装置側でのルールの更新は、任意のトリガーを起点として実行される。トリガーの例は、クライアント側でのアプリケーションプログラムの起動や、入力画面における画面遷移等である。以下、このチャートに沿って、手順を説明する。

まずステップＳ１１において、トリガー生成部２０１が、ルールの更新を要求する。
次にステップＳ１２において、ルール更新部２０２が、ルール記憶部２０４にその時点で記憶されているルールのバージョンを確認する。具体的には、ルール更新部２０２は、ルール記憶部２０４から現在のバージョン情報を読み出す。なお、バージョン情報は、例えば、日時の文字列の情報である。
次にステップＳ１３において、ルール更新部２０２は、サーバー装置側のクライアント用ルール生成部３０４に、ルールの更新要求を送信する。なお、この際、ルール更新部２０２は、ステップＳ１２で取得した現在のルールのバージョン情報を、更新要求に付けて送信する。

次にステップＳ１４において、更新要求を受けたクライアント用ルール生成部３０４は、ルール記憶部３０３から、入力チェック用のルールを読み込む。
次にステップＳ１５において、クライアント用ルール生成部３０４は、ルールのバージョン情報をチェックする。即ち、クライアント用ルール生成部３０４は、クライアント装置側から受け取ったバージョン情報（そのクライアント装置がその時点で保持しているルールのバージョン）と、サーバー装置側で保持しているバージョン情報とを比較する。ここで、比較結果に基づいて処理は分岐する。図において、「ａｌｔ」と記載されている部分では、比較結果に基づいていずれか一方が実行される。
クライアント装置側のルールのバージョンが最新ではなかった場合、つまりクライアント装置側のルールのバージョンが、サーバー装置側で保持しているルールのバージョンよりも古かった場合には、次のステップＳ１６に進む。
クライアント装置側のルールのバージョンが最新であった場合、つまりクライアント装置側のルールのバージョンが、サーバー装置側で保持しているルールのバージョンと同一であった場合には、ステップＳ１９に飛ぶ。

ステップＳ１６に進んだ場合、同ステップにおいて、クライアント用ルール生成部３０４は、クライアント装置用のルールを生成し、クライアント装置２側に送信する。なお、クライアント用ルール生成部３０４は、ＪＳＯＮ（JavaScript Object Notation，ジェイソン）形式のルールを、クライアント装置２側に送信する。ＪＳＯＮ形式は、様々なプラットフォーム間、様々なプログラミング言語間でデータを交換するのに適した形式である。ＪＳＯＮ形式のルールを用いることにより、クライアント装置の種別に依らず、クライアント装置側で処理可能となる。また、このとき、クライアント用ルール生成部３０４は、送信するルールに、そのルールのバージョン情報を添付してクライアント装置２側に送信する。クライアント装置２側では、ルール受信部２０３がそのルールを受信し、ルール更新部２０２に渡す。
次にステップＳ１７において、ルール更新部２０２は、受け取ったルールを用いて、ルール記憶部２０４を更新する。この更新により、ルール記憶部２０４に記憶されていた旧ルールは削除される。なお、ルール更新部２０２は、ルール記憶部２０４上のルールを更新する際に、バージョン情報もあわせて更新する。
次にステップＳ１８において、ルール更新部２０２は、ＵＩ制御部１０１に、ルールの変更があったことを示す変更通知を渡す。
ステップＳ１５からＳ１６に進んだ場合、以上で、クライアント装置側でのルール更新の処理を完了する。

ステップＳ１５からＳ１９に進んだ場合、ステップＳ１９において、クライアント用ルール生成部３０４は、クライアント装置側ではルールの更新が不要であることを示す通知を、クライアント装置２に送る。この通知を、クライアント側入力チェックルール変更不要通知と呼ぶ。ルールの更新が不要である理由は、クライアント装置２側で保持しているルールが最新のバージョンであるためである。
ステップＳ１５からＳ１９に進んだ場合、以上で、クライアント装置側でのルール更新の処理を完了する。

図４は、クライアント装置側からサーバー装置側へのリクエストの送信に伴う、入力チェックの処理の手順を示すシーケンスチャートである。クライアント装置２側における入力値のチェックは、入力値のチェックは、リクエスト送信ボタンの押下や、入力フィールド間でのフォーカスの移動などといった、ユーザーのアクションに応じて実行される。また、サーバー装置３側における入力値のチェックは、クライアント側からのリクエストを受信したタイミングで実行される。なお、以下では、クライアント装置２においてリクエスト送信ボタンが押下され、クライアント装置２がリクエストを送信する、一連の処理における手順を説明する。

まずステップＳ２１において、ＵＩ制御部１０１は、画面等からユーザーが入力したデータを取得し、その入力データを含むリクエストをリクエスト送信部１０２に渡す。
次にステップＳ２２において、リクエスト送信部１０２は、入力データをチェック実行部２０５に渡し、入力データのチェックを依頼する。
次にステップＳ２３において、チェック実行部２０５は、ルール記憶部２０４に記憶されている入力チェック用のルールを参照する。

次にステップＳ２４において、チェック実行部２０５は、ルール記憶部２０４から読み出したルールに基づいて、リクエスト送信部１０２から渡された入力データをチェックする。そして、チェック実行部２０５は、入力データに関してエラーの有無を判定する。
次にステップＳ２５において、チェック実行部２０５は、チェック結果をリクエスト送信部１０２に返す。リクエスト送信部１０２は、チェック結果に基づき、リクエストをサーバー装置３側に送信するか否かを判断する。チェック結果として、エラーがなかった場合（入力チェック合格の場合）に限り、リクエスト送信部１０２は、リクエストをサーバー装置３側に送信する。この図に示すのは、入力チェックの結果、エラーがなかった場合である。
なお、チェック結果としてエラーがあった場合（入力チェック不合格の場合）には、リクエスト送信部１０２は、以後の処理を中止する。つまり、エラーの場合には、リクエスト送信部１０２は、サーバー装置３側に、リクエストを送信しない。
次にステップＳ２６において、リクエスト送信部１０２は、クライアント装置２側において入力チェック済みのリクエストを、サーバー装置３に送信する。

次にステップＳ２７において、クライアント装置２側からリクエストを受信したリクエスト受信部１０３は、リクエストに含まれていた入力データをチェック実行部３０５に渡し、そのチェックを依頼する。
次にステップＳ２８において、チェック実行部３０５は、ルール記憶部３０３に記憶されている入力チェック用のルールを参照する。

次にステップＳ２９において、チェック実行部３０５は、ルール記憶部３０３から読み出したルールに基づいて、リクエスト受信部１０３から渡された入力データの値をチェックする。そして、チェック実行部３０５は、入力データに関してエラーの有無を判定する。
次にステップＳ３０において、チェック実行部３０５は、チェック結果をリクエスト受信部１０３に返す。リクエスト受信部１０３は、チェック結果に基づき、リクエストを処理実行部１０４に渡すか否かを判断する。チェック結果として、エラーがなかった場合（入力チェック合格の場合）に限り、リクエスト受信部１０３は、リクエストを処理実行部１０４に渡す。この図に示すのは、入力値のチェックの結果、エラーがなかった場合である。
なお、チェック結果として、エラーがあった場合（入力チェック不合格の場合）には、リクエスト受信部１０３は、以後の処理を中止する。つまり、エラーの場合には、リクエスト受信部１０３は、処理実行部１０４にリクエストを渡さない。

チェック結果に問題がない場合、リクエスト受信部１０３は、次にステップＳ３１において、チェック済みの入力データを含んだリクエストを、処理実行部１０４に渡す。これに応じて、処理実行部１０４は、入力データを用いた処理を行う。ここで、処理実行部１０４が行う処理の内容は任意であり、アプリケーションシステムがとに特有の処理が行われる。
次にステップＳ３２において、処理実行部１０４は、処理結果（サーバー処理結果）をリクエスト受信部１０３に返す。
次にステップＳ３３において、リクエスト受信部１０３は、処理実行部１０４から受け取ったサーバー処理結果を、クライアント装置２側のＵＩ制御部１０１に返送する。ＵＩ制御部１０１は、受信したサーバー処理結果に基づいて画面表示を行う。

以上、主要な処理の手順について説明したが、次に、各処理で用いるデータの構成について説明する。

図５は、サーバー装置側でルール読込部が読み込む入力チェックルールの構成を示す概略図である。図示するように、入力チェックルールは、ＸＭＬ（Extensible Markup Language）形式で記述されているデータである。図２のステップＳ１で説明したように、ルール読込部３０２が、ファイル等として供給されるこの入力チェックデータのデータを読み込む。
ここでは、例として、３つのデータ項目についてのルールを示している。これらの各項目が、ＵＩ制御部１０１によって表示される入力用画面のフィールドに対応している。各データ項目は、ｉｔｅｍ要素に対応する。ｉｔｅｍ要素の属性として、ｋｅｙ属性はそのデータ項目の識別名を表し、ｎａｍｅ属性はそのデータ項目の名称を表す。また、チェック用のルールは、例えば、ｒｅｇｅｘｐ要素や、ｌｅｎｇｔｈ要素や、ｄａｔｅ−ｖａｌｕｅ要素等を用いて表される。

ｒｅｇｅｘｐ要素は、正規表現（regular expression）によって表現されるルールを記述するために用いられる。入力データが、ルールに記述された正規表現にマッチする場合に、その入力データは正しいものと判定される。入力データがその正規表現にマッチしない場合には、エラーと判定される。
ｌｅｎｇｔｈ要素は、ストリング型のデータの長さに関するルールを記述するために用いられる。ｍｉｎ属性は、長さの最小値を表す。ｍａｘ属性は、長さの最大値を表す。入力データの長さが、ルールに記述された最小値以上で、且つ最大値以下の場合に、その入力データは正しいものと判定される。入力データの長さが、それ医以外の場合には、エラーと判定される。
ｄａｔｅ−ｖａｌｕｅ要素は、日付型のデータの形式や範囲に関するルールを記述するために用いられる。ｆｏｒｍａｔ属性は、日付の記載形式に関するルールを表す。例えば、ｆｏｒｍａｔの値が”ＹＹＹＹ−ＭＭ−ＤＤ”と指定されている場合には、その形式で記載された日付データが正しいものと判定され、その他の日付データはエラーと判定される。ここで、ＹＹＹＹは４桁で表される年であり、ＭＭは２桁で表される月であり、ＤＤは２桁で表される日である。また、ｂｅｇｉｎ属性およびｅｎｄ属性は、それぞれ、日付の値の範囲（期間）を表すものである。ｂｅｇｉｎ属性は、期間の最初の日を表す。ｅｎｄ属性は、期間の最後の日を表す。入力データがこの期間の範囲内にある場合には、その日付データは正しいものと判定される。入力データの日付がその期間の範囲外である場合には、エラーと判定される。

図５に示した例では、第１のルールは、データ項目ｅｍｐｎｏ（データ項目名は「従業員番号」）に関するルールである。そして、正規表現「/(^￥d{3,5}$)/」（ただし、この正規表現中の「￥」は、実際には半角文字）により入力データをチェックしようとするものである。なお、この正規表現は、３桁以上且つ５桁以下の数値にマッチする。
また、第２のルールは、データ項目ｅｎａｍｅ（データ項目名は「氏名」）に関するルールである。そして、その文字列の長さに関して、下限を設けず（ｍｉｎ＝””）、上限を２０としている。
また、第３のルールは、データ項目ｈｉｒｅｄａｔｅ（データ項目名は「入社年月日」）に関するルールである。そして、日付データの記載形式が「ＹＹＹＹ−ＭＭ−ＤＤ」であることをチェックしようとするものである。また、日付データが、「２０１１−１０−０１」から「２０１５−０９−３０」までの期間内にあることをチェックしようとするものである。

図６は、サーバー装置側のルール記憶部のデータ構成を示す概略図である。図示するように、ルール記憶部３０３は、バージョン情報とルールとを記憶している。本実施形態におけるバージョン情報は、日時の文字列である。図示する例におけるバージョン情報「２０１５０９１１−１６５０」は、ルールが２０１５年９月１１日の１６時５０分のバージョンであることを表している。なお、バージョン情報は、ルールのバージョンを特定できる情報であれば、日時の情報として表されていなくてもよい。また、ルール記憶部３０３におけるルールは、２次元の表の構造で表されている。この表は、ｋｅｙ、ｎａｍｅ、ｌｅｎｇｔｈ、ｒｅｇｅｘｐ、ｄａｔｅ−ｖａｌｕｅという５個の項目を有している。また、表の各行が、データ項目に対応している。そして、図６に示すルール記憶部３０３のデータ例は、図５に示した入力データチェック用のルールに対応している。

クライアント装置２側におけるルール記憶部２０４が保持するデータの構成は、サーバー装置３側におけるルール記憶部３０３のそれと同様である。つまり、クライアント装置２側において、ルール記憶部２０４は、図６に示した構成と同様のデータを記憶する。したがって、ここでは、詳しい説明を省略する。

図７は、サーバー装置側からクライアント装置側に更新のために送られるルールのデータの例を示す概略図である。つまり、図示するデータは、図３のステップＳ１６において、サーバー装置３側のクライアント用ルール生成部３０４から、クライアント装置２に対して送信されるデータである。前述の通り、サーバー装置３側のクライアント用ルール生成部３０４は、ＪＳＯＮ形式で記述されたデータを送信する。ただし、更新のためにルールを送信する際に必ずしもＪＳＯＮ形式を用いる必要はなく、その他の形式のデータで送信することも可能である。なお、同図において、便宜的に、行番号を付与している。
図示する通り、このデータは、バージョン情報とルールとを含んでいる。第２行目の「ｖｅｒｓｉｏｎ：」に続く「２０１５０９１１−１６５０」がバージョン情報である。そして、第３行目の「ｒｕｌｅｓ：」に続く部分がルールである。ルールは、第３行目の左角括弧と第１９行目の右角括弧に囲まれた部分に記述されている。この記述は、３個のルールを含んでいる。

１個目のルールは、第４行目の左波括弧（curly brace）と第８行目の右波括弧に囲まれた部分に記述されている。このルールは、データ項目empno（従業員番号）に関するものであり、マッチする正規表現が規定されている。
２個目のルールは、第９行目の左波括弧と第１３行目の右波括弧に囲まれた部分に記述されている。このルールは、データ項目ename（氏名）に関するものであり、ストリング（文字列）の長さについての最小値と最大値とが規定されている。
３個目のルールは、第１４行目の左波括弧と第１８行目の右波括弧に囲まれた部分に記述されている。このルールは、データ項目hiredate（入社年月日）に関するものであり、日付の表現形式と、日付の範囲（期間の開始日および終了日）が規定されている。
なお、これら３個のルールは、図５に示したルール、図６に示したルールに対応しているものである。

図８は、クライアント装置側のＵＩ制御部が作成し、サーバー装置側に送られるリクエストのデータ例を示す概略図である。図示するように、このリクエストのデータも、ＪＳＯＮ形式で記述されたデータである。ただし、必ずしもＪＳＯＮ形式で記述する必要はなく、他の形式を用いるように定めてもよい。なお、同図では便宜的に、データの各行に行番号を付している。

図示するデータの例は、ユーザーインタフェース画面における３つの入力フィールドに対応している。第２行目のデータは、データ項目empno（従業員番号）の値として「２０８４」を保持するものである。第３行目のデータは、データ項目ename（氏名）の値として「Ｓｕｚｕｋｉ Ｊｉｒｏ」を保持するものである。第４行目のデータは、データ項目hiredate（入社年月日）の値として「２０１５−０９−０１」を保持するものである。

このリクエストのデータに関してチェック実行部２０５やチェック実行部３０５が入力値チェックの処理を行った場合を考える。なお、チェック処理に使用するルールは、図６等に示した通りである。チェック処理の結果は、次の通りである。即ち、最初のempno（従業員番号）に入力されたデータは「２０８４」である。このデータをempnoに関するルールでチェックすると、「３桁以上５桁以下の数値」であるというパターンにマッチするため、合格である。また、２番目のename（氏名）に入力されたデータは「Ｓｕｚｕｋｉ Ｊｉｒｏ」である。このデータをenameに関するルールでチェックすると、文字列の長さが０以上２０以下であるという条件を満たすため、合格である。また、３番目のhiredate（入社年月日）に入力されたデータは「２０１５−０９−０１」である。このデータをhiredateに関するルールでチェックすると、形式が「ＹＹＹＹ−ＭＭ−ＤＤ」にマッチし、且つ、この日付が、２０１１年１０月０１日で始まり２０１５年０９月３０日に終わる期間に含まれているという条件を満たすため、合格である。
つまり、このリクエストに含まれる入力値に関するチェックの結果、エラーはなかったことが確認される。

図９は、既に例示したルールに基づいてチェック実行部２０５やチェック実行部３０５がチェック処理を行う際の判断の分岐を示すディシジョンチャートである。同図は、チェック処理の入力と出力との関係を示している。また、同図では、入力の例として、図８にも示したリクエストを示している。図９に示した判断の手順は、次の通りでる。
ステップＳ４１は、empnoのデータに関するルールに対応している。ステップＳ４１において、与えられたデータempnoが、３桁以上且つ５桁以下の数値であるか否かを判定する。empnoが３桁以上且つ５桁以下の数値である場合（ステップＳ４１：ＹＥＳ）には、次のＳ４２に進む。empnoがその条件を満たさない場合（ステップＳ４１：ＮＯ）には、出力が「ｆａｌｓｅ」（チェック不合格）であることを決定し、このチェック処理全体を終了する。
ステップＳ４２は、enameのデータに関するルールに対応している。ステップＳ４２において、与えられたデータenameが、長さ２０以下の文字列であるか否かを判定する。enameが長さ２０以下の文字列である場合（ステップＳ４２：ＹＥＳ）には、次のＳ４３に進む。enameがその条件を満たさない場合（ステップＳ４２：ＮＯ）には、出力が「ｆａｌｓｅ」（チェック不合格）であることを決定し、このチェック処理全体を終了する。
ステップＳ４３は、hiredateのデータに関するルールに対応している。ステップＳ４３において、与えられたデータhiredateが、ＹＹＹＹ−ＭＭ−ＤＤの形式で、且つ２０１１年１０月０１日から２０１５年０９月３０日までの範囲内であるか否かを判定する。hiredateがＹＹＹＹ−ＭＭ−ＤＤの形式で、且つ２０１１年１０月０１日から２０１５年０９月３０日までの範囲内である場合（ステップＳ４３：ＹＥＳ）には、出力が「ｔｒｕｅ」（チェック合格）であることを決定し、このチェック処理全体を終了する。hiredateがその条件を満たさない場合（ステップＳ４３：ＮＯ）には、出力が「ｆａｌｓｅ」（チェック不合格）であることを決定し、このチェック処理全体を終了する。

上記の手順により、与えられた入力データに対して、チェック実行部２０５やチェック実行部３０５が、出力値として「ｔｒｕｅ」または「ｆａｌｓｅ」のいずれかを決定する。

この実施形態によれば、入力チェックのためのルールを、サーバー装置３側で一元的に統合して管理することが可能となる。また、トリガーの生成について適宜定めることにより、任意のタイミングで、クライアント装置２側で記憶しているルールを更新することが可能となる。

（第２の実施形態）
次に、第２の実施形態について説明する。なお、ここでは、本実施形態に特有の事項を中心に説明し、前実施形態で既に説明した事項については説明を省略する。
図１０は、本実施形態によるアプリケーションシステムの概略機能構成を示すブロック図である。図示するように、アプリケーションシステム１１は、クライアント装置１２とサーバー装置１３とを含んで構成される。第１の実施形態と同様に、クライアント装置１２とサーバー装置１３とは、通信回線等を介して相互に通信可能である。
本実施形態におけるクライアント装置１２は、例えば、Raspberry Pi（ＩｏＴ端末）を用いて実現される。ただし、他の装置によってクライアント装置１２を実現してもよい。

クライアント装置１２は、ＵＩ制御部１０１と、リクエスト送信部１０２と、トリガー生成部２０１と、ルール更新部２１２と、ルール受信部２０３と、ルール記憶部２０４と、チェック実行部２０５と、チェック結果記憶部２０６と、を含んで構成される。クライアント装置１２の特徴は、第１の実施形態にはなかったチェック結果記憶部２０６を有する点と、第１の実施形態におけるルール更新部２０２に代えてルール更新部２１２を有する点である。
また、サーバー装置１３は、リクエスト受信部１０３と、処理実行部１０４と、ルール読込部３０２と、ルール記憶部３０３と、クライアント用ルール生成部３１４と、チェック実行部３０５とを含んで構成される。サーバー装置１３の特徴は、第１の実施形態におけるクライアント用ルール生成部３０４に代えてクライアント用ルール生成部３１４を有する点である。

ここで、本実施形態に特有の機能について説明する。
チェック結果記憶部２０６は、チェック実行部２０５によるチェックの実行結果のデータを記憶する。具体的には、チェック結果記憶部２０６は、チェックの結果が合格であったか不合格であったかを表す統計情報を記憶する。さらに具体的には、チェック結果記憶部２０６は、入力チェックを行ったデータ項目ごとに、チェック合格の件数と、チェック不合格の件数と、合格率（チェック合格の件数を、チェック試行全体の件数で除した比率）とを記憶する。
ルール更新部２１２は、第１の実施形態におけるルール更新部２０２と同様に、サーバー装置１３側に対して、ルールの更新を要求する。そして、ルール更新部２１２は、サーバー装置１３側から送られてくるルールで、ルール記憶部２０４を更新する。ルール更新部２１２の、本実施形態に特有の機能は、サーバー装置１３側に対してルールの更新を要求する際に、チェック結果記憶部２０６に記憶されているチェック結果の統計情報を送信する点である。
クライアント用ルール生成部３１４は、第１の実施形態におけるクライアント用ルール生成部３０４と同様に、ルール記憶部３０３から読み出したルールを、ＪＳＯＮ形式のデータとして、クライアント装置１２側に送信する。クライアント用ルール生成部３１４の本実施形態に特有の機能は、クライアント用のルールを生成する際に、チェック結果の統計情報に基づいて、ルールを選択し、選択されたルールのみを送信する点である。具体的には、例えば、クライアント用ルール生成部３１４は、チェック合格率が所定の閾値未満であるデータ項目に関してのルールのみを選択し、そのルールのみをクライアント装置１２側に送信する。
上記のように、本実施形態の特徴は、チェック結果の情報を統計情報として蓄積し、そのチェック結果の情報に基づいて、サーバー装置１３側からクライアント装置１２側に送信するルールを絞り込むことである。

次に、本実施形態における処理手順について説明する。
なお、サーバー装置１３側での入力チェック用のルールの更新の処理は、第１の実施形態におけるそれと同様であるため、ここでは説明を省略する。

図１１は、クライアント装置側で入力チェックのルールを更新する処理の手順を示すシーケンスチャートである。このクライアント装置側でのルールの更新は、任意のトリガーを起点として実行される。以下、このチャートに沿って、手順を説明する。
まずステップＳ５１において、トリガー生成部２０１が、ルールの更新を要求する。本実施形態では、一例として、Raspberry Piのサービス起動をトリガーとする。
次にステップＳ５２において、ルール更新部２１２が、ルール記憶部２０４にその時点で記憶されているルールのバージョンを確認する。この処理は、図３のステップＳ１２の処理と同様である。
次にステップＳ５３において、ルール更新部２１２が、チェック結果記憶部２０６から、チェック結果の情報を読み出す。なお、ここで取得するチェック結果の情報は、当該クライアント装置における過去のチェック結果の統計情報である。チェック結果の情報の具体例については、後述する。
次にステップＳ５４において、ルール更新部２１２は、サーバー装置側のクライアント用ルール生成部３１４に、ルールの更新要求を送信する。なお、この際、ルール更新部２１２は、ステップＳ５２で取得した現在のルールのバージョン情報と、ステップＳ５３で取得したチェック結果の情報とを、更新要求とともに送信する。

次にステップＳ５５において、クライアント用ルール生成部３１４は、ルール記憶部３０３から、入力チェック用のルールを読み込む。この処理は、図３のステップＳ１４の処理と同様である。
次にステップＳ５６において、クライアント用ルール生成部３１４は、ルールのバージョン情報をチェックする。この処理は、図３のステップＳ１５の処理と同様である。そして、バージョン情報に依存して、処理は分岐する。図において、「ａｌｔ」と記載されている部分では、バージョン情報に基づいていずれか一方が実行される。
クライアント装置側のルールのバージョンが最新ではなかった場合、次のステップＳ５７に進む。
クライアント装置側のルールのバージョンが最新であった場合、ステップＳ６０に飛ぶ。

ステップＳ５７に進んだ場合、同ステップにおいて、クライアント用ルール生成部３１４は、要求元のクライアント装置１２用のルールを生成し、クライアント装置１２側に送信する。
なお、クライアント用ルール生成部３１４は、クライアント装置１２側から受信したチェック結果情報に基づいて、ルールを選択し、選択されたルールのみをクライアント装置１２側に送信する。具体的には、クライアント用ルール生成部３１４は、受信したチェック結果情報を参照し、過去のチェック処理における合格率が所定の閾値未満のルールのみを選択する。より具体的には、クライアント用ルール生成部３１４は、ルール記憶部３０３から読み出したルールのうち、過去のチェック処理における合格率が所定の閾値未満のkeyに関するルールのみを選択する。ここで、合格率の閾値として例えば０．６を用いる。あるいは、合格率の閾値として、例えば、０．５以上且つ０．７以下の範囲内のいずれかの値を用いる。
また、クライアント用ルール生成部３１４は、送信するルールに、そのルールのバージョン情報を添付してクライアント装置１２側に送信する。
クライアント装置１２側では、ルール受信部２０３がそのルールを受信し、ルール更新部２１２に渡す。

次にステップＳ５８において、ルール更新部２０２は、受け取ったルールを用いて、ルール記憶部２０４を更新する。この処理は、図３のステップＳ１７の処理と同様である。
次にステップＳ５９において、ルール更新部２１２は、ＵＩ制御部１０１に、ルールの変更があったことを示す変更通知を渡す。
ステップＳ５６からＳ５７に進んだ場合、以上で、クライアント装置側でのルール更新の処理を完了する。

ステップＳ５６からＳ６０に進んだ場合、ステップＳ５６において、クライアント用ルール生成部３１４は、クライアント装置側ではルール更新不要通知を、クライアント装置１２に送る。この処理は、図３のステップＳ１９の処理と同様である。
ステップＳ５６からＳ６０に進んだ場合、以上で、クライアント装置側でのルール更新の処理を完了する。

図１２は、クライアント装置側からサーバー装置側へのリクエストの送信に伴う、入力チェックの処理の手順を示すシーケンスチャートである。以下では、クライアント装置１２においてリクエスト送信ボタンが押下され、クライアント装置１２がリクエストを送信する、一連の処理における手順を説明する。
まずステップＳ７１において、入力データを含むリクエストをリクエスト送信部１０２に渡す。この処理は、図４のステップＳ２１の処理と同様である。
次にステップＳ７２において、リクエスト送信部１０２は、チェック実行部２０５にｍ入力データのチェックを依頼する。この処理は、図４のステップＳ２２の処理と同様である。
次にステップＳ７３において、チェック実行部２０５は、ルール記憶部２０４に記憶されているルールを参照する。この処理は、図４のステップＳ２３の処理と同様である。
次にステップＳ７４において、チェック実行部２０５は、ルール記憶部２０４から読み出したルールに基づいて、リクエスト送信部１０２から渡された入力データをチェックする。この処理は、図４のステップＳ２４の処理と同様である。

次にステップＳ７５において、チェック実行部２０５は、ステップＳ７４で実行したチェックの結果を、チェック結果記憶部２０６に書き込む。具体的には、チェック実行部２０５は、チェックを行ったデータ項目ごとに、チェック結果がｔｒｕｅ（チェック合格）であるかｆａｌｓｅ（チェック不合格）であるかを表す統計情報を更新する。
なお、チェック結果データの具体例と、統計情報の更新のしかたについては、後で、図１３を参照しながら説明する。

次にステップＳ７６において、チェック実行部２０５は、チェック結果をリクエスト送信部１０２に返す。そして、リクエスト送信部１０２は、チェック結果に基づき、リクエストをサーバー装置１３側に送信するか否かを判断する。リクエスト送信部１０２は、チェック合格の場合にのみリクエストをサーバー装置１３側に送信する。チェック不合格の場合には、クライアント装置１２は、以後の処理を注視する。この処理は、図４のステップＳ２５の処理と同様である。

次にステップＳ７７において、リクエスト送信部１０２は、入力チェック済みのリクエストを、サーバー装置１３に送信する。この処理は、図４のステップＳ２６の処理と同様である。
次にステップＳ７８において、リクエスト受信部１０３は、受信したリクエストに含まれていた入力データのチェックを、チェック実行部３０５に依頼する。この処理は、図４のステップＳ２７の処理と同様である。
次にステップＳ７９において、チェック実行部３０５は、ルール記憶部３０３に記憶されているルールを参照する。この処理は、図４のステップＳ２８の処理と同様である。
次にステップＳ８０において、チェック実行部３０５は、リクエスト受信部１０３から渡された入力データの値をチェックする。この処理は、図４のステップＳ２９の処理と同様である。
次にステップＳ８１において、チェック実行部３０５は、チェック結果をリクエスト受信部１０３に返す。リクエスト受信部１０３は、そのチェック結果に基づき、リクエストを処理実行部１０４に渡すか否かを判断する。この処理は、図４のステップＳ３０の処理と同様である。

チェック結果に問題がない場合、リクエスト受信部１０３は、次にステップＳ８２において、チェック済みの入力データを含んだリクエストを、処理実行部１０４に渡す。処理実行部１０４は、入力データを用いた処理を行う。そして、処理実行部１０４は、その処理の結果（サーバー処理結果）をリクエスト受信部１０３に返す。この処理は、図４のステップＳ３１およびＳ３２の処理と同様である。
次にステップＳ８３において、リクエスト受信部１０３は、処理実行部１０４から受け取ったサーバー処理結果を、クライアント装置１２側に返送する。この処理は、図４のステップＳ３３の処理と同様である。

次に、本実施形態の各処理で用いるデータの構成について説明する。
図１３は、チェック結果記憶部が記憶するチェック結果データの構成および例を示す概略図である。図示するように、チェック結果記憶部２０６は、バージョン情報と、チェック結果の統計情報とを有している。バージョン情報は、ルールのバージョンを表す情報である。本実施形態では、バージョン情報として、日時の文字列を有している。チェック結果の統計情報は、データ項目（ｋｅｙ）ごとに、ｔｒｕｅ（チェック合格）のカウント数値と、ｆａｌｓｅ（チェック不合格）のカウント数値と、ｒａｔｅ（合格率）の数値を含む。

図示する例では、バージョン情報は「２０１５０９０１−１８０９」である。
また、データ項目ｅｍｐｎｏに関して、ｔｒｕｅの数値は３５、ｆａｌｓｅの数値は２、ｒａｔｅは０．９５（３５／（３５＋２））である。データ項目ｅｎａｍｅに関して、ｔｒｕｅの数値は３２、ｆａｌｓｅの数値は３、ｒａｔｅは０．９１（３２／（３２＋３））である。データ項目ｈｉｒｅｄａｔｅに関して、ｔｒｕｅの数値は１７、ｆａｌｓｅの数値は１５、ｒａｔｅは０．５３（１７／（１７＋１５））である。ただし、ｒａｔｅに関しては小数点第３位を四捨五入している。

チェック実行部２０５は、チェック処理を実行する都度、チェック結果記憶部２０６を更新する。具体的には、チェック実行部２０５は、データ項目（ｋｅｙ）ごとにチェック結果におけるｔｒｕｅまたはｆａｌｓｅのカウントを増分する。また、チェック実行部２０５は、（ｔｒｕｅのカウント数値／（ｔｒｕｅのカウント数値＋ｆａｌｓｅのカウント数値））の式によってｒａｔｅを計算し、更新する。
ルール更新部２１２は、サーバー装置１３側に対してルールの更新を要求するとき、チェック結果記憶部２０６から、上述した、バージョン情報およびチェック結果の統計数値を読み出して、サーバー装置１３側にそれらの情報を送信する。
また、ルール更新部２１２は、ルールを更新する際には、チェック結果の統計情報を初期化する。具体的には、ルール更新部２１２は、チェック結果データを初期化する際に、ｔｒｕｅおよびｆａｌｓｅの数値を０にリセットする。
なお、このとき、ルール更新部２１２は、変更されたルールについてのみ、チェック結果の統計情報を初期化するようにしてもよい。

図１４は、本実施形態において、サーバー装置側からクライアント装置側に更新のために送られるルールのデータの例を示す概略図である。
本実施形態では、クライアント用ルール生成部３１４が、チェック結果データに基づいて選択したルールのみを、クライアント装置１２側に送信することとしている。図７（第１の実施形態）に示したルールでは、データ項目ｅｍｐｎｏ，ｅｎａｍｅ，ｈｉｒｅｄａｔｅの各々に関するルールを、サーバー装置側からクライアント装置側に送るようにしていた。本実施形態では、所定の基準による条件（例えば、ｒａｔｅ（チェック合格率）が６０％未満）を満たすルールのみが、サーバー装置側からクライアント装置側に送られる。ここでは、クライアント用ルール生成部３１４が、チェック合格率が６０％未満である（図１３を参照）ｈｉｒｅｄａｔｅのみについて、ルールを送信する。クライアント用ルール生成部３１４は、他のデータ項目（ｅｍｐｎｏとｅｎａｍｅ）についてのルールをクライアント装置１２側に送らない。

図１５は、リクエストの際に入力画面から入力されたデータの例を示す概略図である。図示するように、このリクエストは、ｅｍｐｎｏとｅｎａｍｅとｈｉｒｅｄａｔｅの各データ項目に関する入力値を有している。これらのデータ項目のうち、ｈｉｒｅｄａｔｅのデータは、データ形式が「ＹＹＹＹ−ＭＭ−ＤＤ」であることという条件を満たさないため、チェック不合格となる。

この図１５に示したデータの、ｅｍｐｎｏとｅｎａｍｅとｈｉｒｅｄａｔｅの各データ項目に関して入力チェックを行った場合、ｅｍｐｎｏとｅｎａｍｅのデータは合格と判定され、ｈｉｒｅｄａｔｅのデータは不合格と判定される。そして、この判定結果にしたがって、チェック実行部２０５は、チェック結果記憶部２０６を更新する。

本実施形態によれば、クライアント装置側の入力チェックの処理量を軽減化することができる。計算資源が少ない計算機をクライアント装置として用いる場合（例えば、Raspberry Piなど）でも問題なく処理することが可能となる。

次に、第２の実施形態のいくつかの変形例を説明する。
第１変形例では、ルール更新部２１２は、所定の頻度で、チェック結果の統計情報として、すべてのデータ項目に関して、閾値未満（例えば、６０％未満）の値を、サーバー装置１３側に送信する。このようにすべてのデータ項目に関して閾値未満の値を送信した場合には、サーバー装置１３は、すべてのデータ項目に関するルールをクライアント装置１２側に送信する。これにより、すべてのデータ項目に関して、上記所定の頻度で、チェック結果の統計を取得することが可能となる。

第２変形例では、第１変形例の代わりに、サーバー装置側のクライアント用ルール生成部３１４が、所定の頻度で、すべてのデータ項目に関するルールを、クライアント装置１２側に送信するようにする。これにより、クライアント装置１２側で意識することなく、すべてのデータ項目に関して、上記所定の頻度で、チェック結果の統計を取得することが可能となる。

第３変形例では、特定のクライアント装置１２のみにおけるチェック結果の統計情報に基づくのではなく、サーバー装置１３側で収集するすべてのクライアント装置１２における統計情報に基づいて、どのデータ項目に関するルールを送信するかを判断する。つまり、クライアント用ルール生成部３１４は、複数のクライアント装置１２側からチェック結果の統計情報を受信する都度、それを蓄積する。そして、クライアント用ルール生成部３１４は、所定のタイミングで、それらの統計情報を集計し、複数のクライアント装置１２の全体でのチェック合格率を算出する。そして、チェック合格率の低いデータ項目に関するルールのみを、それらのクライアント装置１２に送るようにする。クライアント装置１２側では、サーバー装置１３側から送信されたルールで、各々のルール記憶部２０４を更新する。なお、本変形例において、チェック結果の統計情報が乏しい（例えば、チェックの実行回数が所定の閾値より少ない）クライアント装置１２に関してのみ、サーバー装置１３が他のクライアント装置１２から受信したチェック結果に基づいてチェック合格率の判定を行うようにしてもよい。つまり、本変形例では、クライアント用ルール生成部３１４は、クライアント装置１２側のルール更新部２１２から受信したチェック結果を記憶する手段を有し、記憶したチェック結果に基づいて、他のクライアント装置１２におけるルール更新部２１２からのルールの要求があったときに、チェック結果としてチェック合格率が所定の閾値より低いデータ項目のみについて当該他のクライアント１２用のルールを生成し、生成したルールを要求元である当該他のクライアント装置１２に送信する。これにより、処理の実行回数が少ないクライアント装置２においても、他のクライアント装置におけるチェック結果に基づいて、ルールを選択的に更新することが可能となる。

第４変形例では、ルール更新部２１２は、チェック結果データをサーバー装置１３側に送信しない。そして、サーバー装置１３におけるクライアント用ルール生成部３１４は、すべてのデータ項目に関するルールをクライアント装置１２に送信する。クライアント装置１２側では、ルール更新部２１２は、チェック結果記憶部２０６を参照し、受信したルールのうちのチェック合格率が所定の閾値未満のデータ項目に関するルールのみで、ルール記憶部２０４の更新を行う。つまり、本変形例では、ルール更新部２１２は、ルール記憶部２０４を更新するためのルールをサーバー装置１３側から受け取った際に、チェック結果記憶部２０６から読み出したチェック結果に関する情報に基づき、チェック結果としてチェック合格率が所定の閾値より低いデータ項目のみについてのサーバー装置１３側から受け取ったルールを用いて、ルール記憶部２０４を更新する、この更新以後は、ルール更新部２１２が選択した、チェック合格率が所定の閾値未満のデータ項目のみについて、チェック実行部２０５がチェックを行う様になる。これにより、サーバー装置１３側の処理負荷を軽減することができる。

第５変形例では、ルール更新部２１２は、チェック結果データをサーバー装置１３側に送信する。サーバー装置１３におけるクライアント用ルール生成部３１４は、当該クライアント装置１２からチェック結果の統計情報を受け取ったデータ項目に関しては、その統計情報に基づいて更新用ルールを送るか否かを判断する。そして、クライアント用ルール生成部３１４は、当該クライアント装置１２からチェック結果の統計情報を受け取らなかったデータ項目に関しては、他のクライアント装置１２から収集したチェック結果の統計情報に基づいて、更新用ルールを送るか否かを判断する。

上記各実施形態では、ルールのバージョン情報は、日時の文字列の情報であるものとしたが、バージョンを識別できる情報であれば、それ以外の形態のバージョン情報であってもよい。

以上説明した少なくともひとつの実施形態によれば、ルール更新部２０２（またはルール更新部２１２。以下同様。）は任意のタイミングでサーバー装置３側にルールの更新を要求する。また、ルール更新部２０２は、必ず、サーバー装置３側から送信されるルールで、ルール記憶部２０４を更新する。このようなルール更新部２０２を持つことにより、入力チェックのためのルールを、サーバー装置３側で一元的に統合して管理することが可能となる。また、トリガーの生成について適宜定めることにより、任意のタイミングで、クライアント装置２側で記憶しているルールを更新することが可能となる。

なお、上述した実施形態におけるクライアント装置およびサーバー装置の機能の少なくとも一部をコンピューターで実現するようにしても良い。その場合、機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１，１１…アプリケーションシステム（システム）、２，１２…クライアント装置、３，１３…サーバー装置、１０１…ＵＩ制御部（ユーザーインタフェース制御部）、１０２…リクエスト送信部、１０３…リクエスト受信部、１０４…処理実行部、２０１…トリガー生成部、２０２，２１２…ルール更新部、２０３…ルール受信部、２０４…ルール記憶部（第１ルール記憶部）、２０５…チェック実行部（第１チェック実行部）、２０６…チェック結果記憶部、３０２…ルール読込部、３０３…ルール記憶部（第２ルール記憶部）、３０４，３１４…クライアント用ルール生成部、３０５…チェック実行部（第２チェック実行部）

Claims (8)

1. クライアント装置とサーバー装置とを備えるシステムであって、
   前記クライアント装置は、
   入力チェックに関するルールを記憶する第１ルール記憶部と、
   前記第１ルール記憶部に記憶されている前記ルールに基づいて入力データをチェックする第１チェック実行部と、
   ユーザーインタフェースを通して入力データを受け付けるユーザーインタフェース制御部と、
   前記サーバー装置側に送信するためのリクエストに含まれる前記入力データの入力チェックを前記第１チェック実行部に依頼するとともに、チェック結果が合格であれば前記リクエストを前記サーバー装置に送信するリクエスト送信部と、
   所定のトリガーに基づいて、前記第１ルール記憶部を更新するためのルールを前記サーバー装置に要求するとともに、前記要求への応答として前記サーバー装置から送られるルールを用いて前記第１ルール記憶部を更新するルール更新部と、
   を備え、
   前記サーバー装置は、
   入力チェックに関するルールを記憶する第２ルール記憶部と、
   前記第２ルール記憶部に記憶されている前記ルールに基づいて入力データをチェックする第２チェック実行部と、
   前記リクエスト送信部から送信される前記リクエストを受信するとともに、前記リクエストに含まれる前記入力データの入力チェックを前記第２チェック実行部に依頼するリクエスト受信部と、
   前記ルール更新部から前記ルールの要求を受けると、前記第２ルール記憶部から読み出したルールに基づいてクライアント用のルールを生成し、生成したルールを要求元の前記クライアント装置に送信するクライアント用ルール生成部と、
   を備える、
   システム。
2. 前記クライアント装置は、
   前記第１チェック実行部によるチェック結果に関する情報を記憶するチェック結果記憶部、をさらに備え、
   前記第１チェック実行部は、実行したチェックのチェック結果に関する情報を前記チェック結果記憶部に書き込み、
   前記ルール更新部は、前記第１ルール記憶部を更新するためのルールを前記サーバー装置に要求する際に、前記チェック結果記憶部から読み出した前記チェック結果に関する情報をあわせて前記サーバー装置に送信するものであり、
   前記サーバー装置において、
   前記クライアント用ルール生成部は、前記ルール更新部から受信した前記チェック結果に関する情報に基づいて、チェック結果としてチェック合格率が所定の閾値より低いデータ項目のみについて前記クライアント用のルールを生成し、生成した前記ルールを要求元の前記クライアント装置に送信する、
   請求項１に記載のシステム。
3. 前記クライアント用ルール生成部は、前記ルール更新部から受信した前記チェック結果を記憶するものであり、記憶した前記チェック結果に基づいて、他のクライアント装置におけるルール更新部からのルールの要求があったときに、チェック結果としてチェック合格率が所定の閾値より低いデータ項目のみについて当該他のクライアント用のルールを生成し、生成したルールを要求元である当該他のクライアント装置に送信する、
   請求項２に記載のシステム。
4. 前記クライアント装置は、
   前記第１チェック実行部によるチェック結果に関する情報を記憶するチェック結果記憶部、をさらに備え、
   前記第１チェック実行部は、実行したチェックのチェック結果に関する情報を前記チェック結果記憶部に書き込み、
   前記ルール更新部は、前記第１ルール記憶部を更新するためのルールを前記サーバー装置側から受け取った際に、前記チェック結果記憶部から読み出した前記チェック結果に関する情報に基づき、チェック結果としてチェック合格率が所定の閾値より低いデータ項目のみについての前記サーバー装置側から受け取ったルールを用いて、前記第１ルール記憶部を更新する、
   請求項１に記載のシステム。
5. 入力チェックに関するルールを記憶するルール記憶部と、
   前記ルール記憶部に記憶されている前記ルールに基づいて入力データをチェックするチェック実行部と、
   ユーザーインタフェースを通して入力データを受け付けるユーザーインタフェース制御部と、
   前記サーバー装置側に送信するためのリクエストに含まれる前記入力データの入力チェックを前記チェック実行部に依頼するとともに、チェック結果が合格であれば前記リクエストを前記サーバー装置に送信するリクエスト送信部と、
   所定のトリガーに基づいて、前記ルール記憶部を更新するためのルールを前記サーバー装置に要求するとともに、前記要求への応答として前記サーバー装置から送られるルールを用いて前記ルール記憶部を更新するルール更新部と、
   を備えるクライアント装置。
6. 入力チェックに関するルールを記憶するルール記憶部と、
   前記ルール記憶部に記憶されている前記ルールに基づいて入力データをチェックするチェック実行部と、
   クライアント装置から送信されるリクエストを受信するとともに、前記リクエストに含まれる前記入力データの入力チェックを前記チェック実行部に依頼するリクエスト受信部と、
   前記クライアント装置からルールの要求を受けると、第２ルール記憶部から読み出したルールに基づいてクライアント用のルールを生成し、生成したルールを要求元のクライアント装置に送信するクライアント用ルール生成部と、
   を備えるサーバー装置。
7. コンピューターを、
   入力チェックに関するルールを記憶するルール記憶部、
   前記ルール記憶部に記憶されている前記ルールに基づいて入力データをチェックするチェック実行部、
   ユーザーインタフェースを通して入力データを受け付けるユーザーインタフェース制御部、
   前記サーバー装置側に送信するためのリクエストに含まれる前記入力データの入力チェックを前記チェック実行部に依頼するとともに、チェック結果が合格であれば前記リクエストを前記サーバー装置に送信するリクエスト送信部、
   所定のトリガーに基づいて、前記ルール記憶部を更新するためのルールを前記サーバー装置に要求するとともに、前記要求への応答として前記サーバー装置から送られるルールを用いて前記ルール記憶部を更新するルール更新部、
   として機能させるためのプログラム。
8. コンピューターを、
   入力チェックに関するルールを記憶するルール記憶部、
   前記ルール記憶部に記憶されている前記ルールに基づいて入力データをチェックするチェック実行部、
   クライアント装置から送信されるリクエストを受信するとともに、前記リクエストに含まれる前記入力データの入力チェックを前記チェック実行部に依頼するリクエスト受信部、
   前記クライアント装置からルールの要求を受けると、第２ルール記憶部から読み出したルールに基づいてクライアント用のルールを生成し、生成したルールを要求元のクライアント装置に送信するクライアント用ルール生成部、
   として機能させるためのプログラム。

Images