JP5064126B2 - 利用されるサービスを制御するサーバシステム - Google Patents

Description

本発明は、サーバシステムに関する。

サービスの利用を制限する方法の一つに、例えば、パスワードを含んだログイン要求をユーザ端末から受けて、そのログイン要求に含まれているパスワードが正当か否かにより、ログインを許可するか否かを制御する方法がある。ログインが拒否された場合には、サーバシステムが提供するサービスを利用することはできないが、ログインが許可された場合には、そのサービスを利用することができる。この種の技術については、例えば、特許文献１に開示の技術がある。

特開２００６−４３３３号公報

ところで、サーバシステムが提供するサービスは、一般に、インターネット等の通信ネットワークを介して遠隔のユーザ端末から利用される。新しいサービスのためのコンピュータプログラムがサーバシステムで動作することになる場合、その新サービスが一般のユーザにリリースされる前に、そのコンピュータプログラムが正常に動作するか否かの動作チェックを行うべきである。その動作チェックは、例えば、一般のユーザの使用環境とは異なる環境（例えば、社内のオフラインの環境で）で行っても良いが、正確なチェック結果を得るために、一般のユーザの使用環境と同じ環境で行った方が望ましい。

一般のユーザの使用環境と同じ環境で動作チェックを行う場合、例えば、一般のユーザと同様に、動作チェックを行うユーザが、遠隔からサーバシステムにログインして、動作チェックを行うことになる。この場合、この動作チェックの最中に、一般ユーザからログインされてその新サービスが利用されてしまうことを防ぐ必要がある。

また、上記の例に限らず、特定ユーザとしてのログインを許可して良いケースと一般ユーザとしてのログインを許可してはならないケースとがある。

従って、本発明の目的は、どのようなログイン許否の判断を行うかを適切に制御することにある。

本発明の他の目的は、後の記載から明らかになるであろう。

サーバシステムに、サービスの提供のための処理を表した情報である処理定義とそのサービスの識別子とがサービス毎に対応付けられたサービス制御情報に記憶させる。サーバシステムは、ユーザに利用されるサービスの識別子を受信し、受信したサービス識別子に対応した処理定義をサービス制御情報から特定する。特定された処理定義が、特定ユーザとしてのログインを表すサービス識別子に対応している処理定義であるならば、特定ユーザとしてのログインの許否を判断する特定ログインプロセスを実行し、一方、特定された処理定義が、一般ユーザとしてのログインを表すサービス識別子に対応している処理定義であるならば、一般ユーザとしてのログインの許否を判断する一般ログインプロセスを実行する。

一つの実施形態では、サーバシステムに備えられる一又は複数のアプリケーションに、特定ユーザとしてのログインの許否を判断する特定ログインプロセスと、一般ユーザとしてのログインの許否を判断する一般ログインプロセスとが含まれている。また、サーバシステムの記憶資源に、サービスの提供のための処理を表した情報である処理定義とそのサービスの識別子とがサービス毎に対応付けられたサービス制御情報が記憶される。サーバシステムが、ユーザに利用されるサービスの識別子を受信する受信手段と、その受信手段で受信したサービス識別子に対応した処理定義を前記サービス管理情報から特定し、特定した処理定義を基に特定されるプロセスを実行させるサービス制御手段とを備える。サービス識別子として、特定ユーザとしてのログインを表す特定ログインと、一般ユーザとしてのログインを表す一般ログインとがある。特定ログインに対応付けられている処理定義は、特定ログインプロセスの実行を表し、一般ログインに対応付けられている処理定義は、一般ログインプロセスの実行を表す。受信手段で受信したサービス識別子が、特定ログインであるならば、サービス制御手段が、前記特定ログインに対応付けられている処理定義が表す特定ログインプロセスを実行させる。一方、受信手段で受信したサービス識別子が、一般ログインであるならば、サービス制御手段が、一般ログインに対応付けられている処理定義が表す一般ログインプロセスを実行させる。

一つの実施形態では、サーバシステムに、更に、特定ユーザ用のＵＲＬと一般ユーザ用のＵＲＬのいずれかのＵＲＬを用いたアクセスをユーザ端末から受け付けるアクセス受付手段と、ログイン画面情報送信手段とが備えられる。ログイン画面情報送信手段は、特定ユーザ用のＵＲＬを用いたアクセスを受けた場合に、特定ログインが埋め込まれた特定ログイン画面情報をユーザ端末に送信し、一般ユーザ用のＵＲＬを用いたアクセスを受けた場合に、一般ログインが埋め込まれた一般ログイン画面情報をユーザ端末に送信する。受信手段が、ユーザ端末において特定ログイン画面情報が表すログイン画面にログイン要求が入力された場合に、その特定ログイン画面情報に埋め込まれている特定ログインを受信し、ユーザ端末において一般ログイン画面情報が表すログイン画面にログイン要求が入力された場合に、その一般ログイン画面情報に埋め込まれている一般ログインを受信する。

一つの実施形態では、サービス制御情報において、サービス毎に、更に、サービス許可時間帯が対応付けられている。サービス制御手段が、受信したサービス識別子に対応したサービス許可時間帯をサービス制御情報から特定し、特定されたサービス許可時間帯に現在時刻が属していれば、そのサービス識別子に対応した処理定義から特定されるプロセスを実行させる。

一つの実施形態では、受信手段は、それの受信可否状態が受信可状態であれば、前記サービス識別子を受け付け、その受信可否状態が受信不可状態であれば、サービス識別子を受け付けない。

一つの実施形態では、サーバシステムの記憶資源に、ログインが許可されるユーザのユーザ識別子が登録されたユーザ管理情報と、特定ユーザのユーザ識別子が登録された特定ユーザ管理情報とが更に記憶される。受信手段が、サービス識別子とユーザ識別子とを受信する。一般ログインプロセスは、受信したユーザ識別子がユーザ管理情報に登録されていれば、ログインを許可するとの判断をする。特定ログインプロセスは、受信したユーザ識別子がユーザ管理情報と特定ユーザ管理情報の両方に登録されていれば、ログインを許可するとの判断をする。

一つの実施形態では、特定ユーザ管理情報には、特定ユーザ毎に、更に、所定種類の値が対応付けられている。特定ログインプロセスは、受信したユーザ識別子がユーザ管理情報と特定ユーザ管理情報の両方に登録されており、且つ、そのユーザ識別子に対応した所定種類の値が所定の条件を満たしている場合に、ログインを許可するとの判断をする。

一つの実施形態では、受信可否状態を更新する第一の主体と、特定ユーザ管理情報を更新する第二の主体とが異なっている。

一つの実施形態では、サービス識別子として、アプリケーションプログラムの動作チェックにおいて発見された不具合に対応するためのサービスを表す不具合対応がある。一又は複数のアプリケーションプログラムに、不具合に対応するためのプロセスが含まれている。そのプロセスの実行を表す処理定義が、サービス制御情報において、上記不具合対応に対応付けられている。

一つの実施形態では、サーバシステムの記憶資源に、ユーザ識別子、所定種類の値及びセッション識別子が登録されるセッション管理情報が更に記憶される。そのサーバシステムに、更に、セッション識別子の割り振りを行うセッション管理手段が備えられる。サービス制御情報において、サービス毎に、更に、閾値が対応付けられている。特定ログインプロセスは、ログインを許可するとの判断になった場合、ユーザ識別子及び所定種類の値を送信する。セッション管理手段が、送信されたユーザ識別子及び所定種類の値と割り振られたセッション識別子とをセッション管理情報に登録し、そのセッション識別子を送信する。その後、セッション管理手段は、ユーザ端末から、サービス識別子とそのセッション識別子とを受け付け、そのセッション識別子に対応したユーザ識別子及び所定種類の値をセッション管理情報から特定し、特定されたユーザ識別子及び所定種類の値と、受け付けたサービス識別子とを、サービス制御手段に送信する。サービス制御手段が、そのサービス識別子に対応した閾値をサービス制御情報から特定し、受けた所定種類の値が特定された閾値を超えている場合に、そのサービス識別子に対応した処理定義を基に特定されるプロセスを実行させる。

前述した複数の実施形態のうちの二以上の実施形態を組合せで実現することも可能である。また、前述した各手段は、ハードウェア（例えば回路）、コンピュータプログラム、或いはそれらの組み合わせ（例えば、一部をコンピュータプログラムで実行し残りをハードウェアで実行する）によって実現することもできる。各コンピュータプログラムは、コンピュータマシンに備えられる記憶資源（例えばメモリ）から読み込むことができる。その記憶資源には、ＣＤ−ＲＯＭやＤＶＤ（Digital Versatile Disk）等の記録媒体を介してインストールすることもできるし、インターネットやＬＡＮ等の通信ネットワークを介してダウンロードすることもできる。

以下、図面を参照して、本発明の幾つかの実施形態を詳細に説明する。

図１は、本発明の第一の実施形態に係るコンピュータシステムの構成を示す。まず、この図を参照して、そのコンピュータシステムの概要を説明する。

ユーザ端末１０１とサーバシステム１０５との間で、通信ネットワーク（例えばインターネット）１０３を介して、通信が行われる。

ユーザ端末１０１は、ＣＰＵやメモリ等を備えた情報処理端末であり、例えば、パーソナルコンピュータ、携帯電話機或いはＰＤＡ（Personal Digital Assistants）である。ユーザ端末１０１を使用するユーザは、「特定ユーザ」或いは「一般ユーザ」である。これらのユーザを格別区別しないで説明する場合には、単に「ユーザ」と総称する。

サーバシステム１０５は、一又は複数の情報処理装置で構築される。情報処理装置は、コンピュータプログラムやデータが記憶される記憶資源（メモリ及び／又は他種の記憶デバイスで構成されたハードウェア資源）や、コンピュータプログラムを読み込んで実行するプロセッサ（例えばＣＰＵ（Central Processing Unit））を備える。サーバシステム１０５で実行されるコンピュータプログラムとして、例えば、ＷＥＢサーバ１０７、ＷＡＳ（ＷＥＢアプリケーションサーバ）１０８、業務制御サーバ１０９、複数のアプリケーションサーバ（ＡＰＬサーバ）１１１及びＤＢ（データベース）サーバ１１３がある。各サーバ１０７、１０８、１０９、１１１及び１１３は、一以上の情報処理装置内のプロセッサで実行される。以下、動作の主体がコンピュータプログラムである場合には、実際には、コンピュータプログラムを実行するプロセッサがその動作の主体である。

ＷＥＢサーバ１０７は、ＷＥＢブラウザなどの図示しないクライアントソフトウェア（ユーザ端末１０１内のプロセッサで実行されるコンピュータプログラム）と通信する。

ＷＡＳ１０８は、ＷＥＢサーバ１０７を通じて受けた情報を業務制御サーバ１０９に送信する。

業務制御サーバ１０９は、ＷＡＳ１０８を通じて受信した情報を基に、複数のＡＰＬサーバ１１１のうちのどのＡＰＬサーバ１１１のどのプロセスを実行するかを制御する。

ＡＰＬサーバ１１１は、所定のサービスを提供する。サービスとしては、サーバシステム１０５へのログイン、株式などの売買などが挙げられる。

ＤＢサーバ１１３は、例えばテーブルを管理しており、ＡＰＬサーバ１１１から参照要求を受け、その参照要求に応答して、テーブルに記録されているデータを返す。

サーバシステム１０５の外部に、例えば、運用サーバ１２１と開発者端末１２３がある。運用サーバ１２１は、サーバシステム１０５の外部にある情報処理装置内のプロセッサで実行されるコンピュータプログラムであり、業務制御サーバ１０９に関する状態を制御する。開発者端末１２３は、サーバシステム１０５の開発者が使用する情報処理端末であり、例えば、開発者からの指示により、サーバシステム１０５における種々のテーブルを更新する。運用サーバ１２１及び開発者端末１２３からサーバシステム１０５へのアクセスは、通信ネットワーク１０３又はそれとは別の通信ネットワーク（例えばＬＡＮ（Local Area Network））を介して行われる。

以上が、本実施形態に係るコンピュータシステムの概要である。

本実施形態で言う「特定ユーザ」とは、通信ネットワーク１０３を介してログインした一般ユーザに新サービスが利用される前に（つまりリリースされる前に）、一般ユーザと同様に通信ネットワーク１０３を介してログインしその新サービスを利用してみることで（つまり一般ユーザと同様の環境で新サービスを利用してみることで）、新サービスを提供するＡＰＬサーバ１１１（或いはそのＡＰＬサーバ１１１に加えられた新プロセス）が正常に動作するかどうかの動作チェックを行うユーザである。

このような動作チェックの最中に、一般ユーザがログインして新サービスが利用されることを防ぐ必要がある。また、動作チェック中には利用されてはならないサービス（以下、使用禁止サービス）が動作チェック中に利用されてしまうことを防ぐ必要がある。更に、そのような動作チェックが必要の無い時に行われてしまうことも防ぐべきである。

以下、本実施形態に係るコンピュータシステムにおける種々の要素について詳細に説明するが、その際、適宜に、上記の課題を解決するために施されている工夫も説明する。

図２Ａは、ＷＡＳ１０８の構成例を示す。

ＷＡＳ１０８には、ユーザからのログインを受け付けるための画面（ログイン画面）を表す情報を提供する受付制御プログラム１０８１が備えられる。受付制御プログラム１０８１は、二種類のＵＲＬ（Uniform Resource Locator）のうちのどれを使用してユーザ端末１０１よりアクセスされたかに応じて、そのユーザ端末１０１に送信するログイン画面情報を違える。

ここで、「二種類のＵＲＬ」とは、特定ユーザ用ＵＲＬと一般ユーザ用ＵＲＬである。サーバシステム１０５は、これら二種類のＵＲＬのいずれの種類のＵＲＬを使用してもユーザ端末１０１からのアクセスを受けることができるように構成されている（アクセスを受けるためのポートの数は、例えば一つであるが、複数であっても良い）。

「特定ユーザ用ＵＲＬ」とは、特定ユーザとしてアクセスするために使用される非公表のＵＲＬ、具体的には、特定ユーザのみが知っているＵＲＬである。一方、「一般ユーザ用ＵＲＬ」とは、一般ユーザとしてアクセスするために使用されるＵＲＬであり、例えば、公表されるＵＲＬである。

受付制御プログラム１０８１は、特定ユーザ用ＵＲＬを受けた場合には、特定ユーザ用ログイン画面を表す情報を、ＷＥＢサーバ１０７を通じてユーザ端末１０１に送信し、一般ユーザ用ＵＲＬを受けた場合には、一般ユーザ用ログイン画面を表す情報を、ＷＥＢサーバ１０７を通じてユーザ端末１０１に送信する。

図２Ｂに、特定ユーザ用ログイン画面１０８３Ｓを示し、図２Ｃに、一般ユーザ用ログイン画面１０８３Ｇを示す。これらのログイン画面１０８３Ｓ及び１０８３Ｇは、見た目上は同じである。すなわち、それぞれのログイン画面１０８３Ｓ及び１０８３Ｇには、ログインに必要な情報の入力をユーザから受けるためのツール（例えば、ユーザＩＤが入力されるテキストボックス１０８３１及びパスワードが入力されるテキストボックス１０８３３）や、ログイン実行をユーザから受け付けるためのログインボタン１０８３５がある。ログインボタン１０８３５を表す情報（以下、ログインボタン情報）には、例えば、サービスの識別子であるサービスＩＤが埋め込まれている（例えばその所定のサービスＩＤを送信するコンピュータプログラムが埋め込まれている）。

特定ユーザ用ログイン画面１０８３Ｓを表す情報と、一般ユーザ用ログイン画面１０８３Ｇを表す情報との相違点は、ログインボタン情報に埋め込まれているサービスＩＤ（例えば、そのサービスＩＤを送信するコンピュータプログラム）にある。具体的には、特定ユーザ用ログイン画面１０８３Ｓを表す情報におけるログインボタン情報には、サービスＩＤ“特定ログイン”が埋め込まれており、一般ユーザ用ログイン画面１０８３Ｇを表す情報におけるログインボタン情報には、サービスＩＤ“一般ログイン”が埋め込まれている。ログイン画面１０８３Ｓ、１０８３Ｇにおいて、ユーザＩＤ及びパスワードが入力されログインボタン１０８３５が押された場合に、ユーザＩＤ、パスワード、及び、そのログインボタン１０８３５を表す情報に埋め込まれているサービスＩＤを含んだログイン要求が、ユーザ端末１０１から送信され、そのログイン要求に含まれているユーザＩＤ、パスワード及びサービスＩＤが、ＷＥＢサーバ１０７及びＷＡＳ１０８を通じて、業務制御サーバ１０９に入力される。

図３に、業務制御サーバ１０９の構成と、その業務制御サーバ１０９に関する状態を制御する運用サーバ１２１の構成を示す。

業務制御サーバ１０９は、インタフェース（Ｉ／Ｆ）プログラム１０９２、受付オープン実行プログラム１０９１Ｐ、受付クローズ実行プログラム１０９１Ｑ及びサービス呼出プログラム１０９３を備える。サービス呼出プログラム１０９３により、サービス制御テーブル１０９５が参照される。

Ｉ／Ｆプログラム１０９２は、ＷＡＳ１０８との通信のインタフェースとして機能するコンピュータプログラムであり、ＷＡＳ１０８との間で情報の送受信を行う。Ｉ／Ｆプログラム１０９２が情報を受信できるか否かの状態（以下、受信可否状態）が、受付オープン実行プログラム１０９１Ｐや受付クローズ実行プログラム１０９１Ｑにより制御される。受信可否状態がオープン（受信可能状態）であれば、例えば、ユーザＩＤやパスワードが特定ユーザ及び一般ユーザのどの種のユーザによって入力されたかに関わらず、ユーザＩＤ、パスワード及びサービスＩＤがＩ／Ｆプログラム１０９２で受信されるが、受信可否状態がクローズ（受信不可状態）であれば、ユーザＩＤやパスワードがどの種のユーザによって入力されたかに関わらず、ユーザＩＤ、パスワード及びサービスＩＤのＩ／Ｆプログラム１０９２での受信が拒否される。

受付オープン実行プログラム１０９１Ｐは、呼び出された場合に、Ｉ／Ｆプログラム１０９２の受信可否状態を、オープンに更新する。受付クローズ実行プログラム１０９１Ｑは、呼び出された場合に、Ｉ／Ｆプログラム１０９２の受信可否状態を、クローズに更新する。これらのプログラム１０９１Ｐ及び１０９１Ｑのどちらかが、適時に、運用サーバ１２１に備えられている受付実行制御プログラム１２１１から呼び出される。受付実行制御プログラム１２１１は、スケジュール管理情報１２１２を基に、プログラム１０９１Ｐ及び１０９１Ｑのどちらを呼び出すかを選択する。例えば、スケジュール管理情報１２１２に、「毎日、０６：００にオープンにし、０２：００にクローズにする」ことを表す通常運用情報が含まれていれば、受付実行制御プログラム１２１１は、日々、現在時刻が０６：００になったら受付オープン実行プログラム１０９１Ｐを呼び出し、現在時刻が０２：００になったら受付クローズ実行プログラム１０９１Ｑを呼び出す。また、例えば、スケジュール管理情報１２１２に、「動作チェック期間に０５：００にオープンにする」ことを表す特別運用情報が含まれていれば、受付実行制御プログラム１２１１は、現在日時が動作チェック期間（例えば２００７／０６／１３〜２００７／０６／２０と定義された期間）に属しており且つ０５：００であれば、受付オープン実行プログラム１０９１Ｐを呼び出す。これらのプログラム１０９１Ｐ及び１０９１Ｑの呼出しは、スケジュール管理情報１２１２に基づいて自動で行われても良いし、運用サーバ１２１の管理者によって手動で行われても良い。

サービス制御テーブル１０９５は、どんなサービスＩＤをどんな時間帯に受信した場合にどんなサービスの利用を許可するかを制御するためのテーブルである。サービス制御テーブル１０９５には、例えば、サービスＩＤ、開始時刻、終了時刻及び処理定義の組合せが複数個記録されている。

サービス呼出プログラム１０９３は、Ｉ／Ｆプログラム１０９２が受けたサービスＩＤを用いてサービス制御テーブル１０９５を参照し、そのサービスＩＤに対応付けられている開始時刻、終了時刻及び処理定義を基に、どのＡＰＬサーバ１１１のどのプロセスを呼び出すかを制御する。このため、サービス制御テーブル１０９５において、どんな処理定義にどんな開始時刻及び終了時刻の組合せを対応付けるかによって、動作チェック中に使用禁止サービスが利用されてしまうことを防ぐことができる。

ここで、「処理定義」とは、実行する処理を表す情報であり、例えば、どのＡＰＬサーバ１１１におけるどのプロセスを実行するかを表す情報である。もし、複数のプロセスにより一つの処理が定義されている場合には、それら複数のプロセスをどんな順序で実行するかを表す情報が含まれても良い。

また、図示の通り、サービス制御テーブル１０９５には、同じサービスＩＤに、開始時刻、終了時刻及び処理定義の組合せを複数個対応付けることが可能である。このため、同種のサービスであっても、そのサービスに対応付ける開始時刻、終了時刻及び処理定義の組合せによって、特定ユーザによる動作チェックの最中に使用禁止サービスに対応した処理が行われないようにすることができる。具体的には、例えば、新サービスの動作チェックのための時間帯が０５：００以降０６：００未満の場合、その新サービスのサービスＩＤに対応付ける開始時刻を“０５：００”とし、終了時刻を“０６：００”とし、処理定義を、使用禁止サービス以外のサービスに対応した処理を表す情報とすれば、新サービスにおける使用禁止サービスが動作チェック中に利用されてしまうことを防ぐことができる。

複数のＡＰＬサーバ１１１には、例えば、ユーザからのログインの許否を判定するログイン用ＡＰＬサーバが含まれており、サービス呼出プログラム１０９３が受けたサービスＩＤが“特定ログイン”或いは“一般ログイン”の場合、ログイン用ＡＰＬサーバが呼び出される。図４を参照して、ログイン用ＡＰＬサーバについて説明する。

ログイン用ＡＰＬサーバ１１１Ｌには、サービスＩＤが“特定ログイン”の場合に呼び出される特定ログイン用プロセス１１１１Ｓと、サービスＩＤが“一般ログイン”の場合に呼び出される一般ログイン用プロセス１１１１Ｇとがある。特定ログイン用プロセス１１１１Ｓは、ＤＢサーバ１１３が管理するユーザ管理テーブル１１３１を参照して行う第一の判定と、ＤＢサーバ１１３が管理する特定ユーザ管理テーブル１１３３を参照して行う第二の判定とを行う。一般ログイン用プロセス１１１１Ｇは、第一の判定を行うが第二の判定を行わない。

ユーザ管理テーブル１１３１には、ユーザが特定ユーザであるか一般ユーザであるかに関わらず、ログインが許可されるべきユーザのユーザＩＤ及びパスワードが登録されている。特定ログイン用プロセス１１１１Ｓ及び一般ログイン用プロセス１１１１Ｇの両方が行う前述の第一の判定では、ログイン画面１０８３Ｓ、１０８３Ｇで入力されたユーザＩＤ及びパスワードの組合せがユーザ管理テーブル１１３１に登録されているか否かが判定される。一般ログイン用プロセス１１１１Ｇによる第一の判定の結果が肯定的である場合、一般ユーザのログインが許可され、第一の判定の結果が否定的である場合、一般ユーザのログインが拒否される。

特定ユーザ管理テーブル１１３３には、ログインが許可されるべき特定ユーザのユーザＩＤが登録されている。また、そのユーザＩＤ毎に、ログインが許可される期間の開始日及び終了日も登録されている。特定ログイン用プロセス１１１１Ｓが行う前述の第二の判定では、特定ユーザ用ログイン画面１０８３Ｓで入力されたユーザＩＤが特定ユーザ管理テーブル１１３３に登録されており、そのユーザＩＤに対応した開始日及び終了日で表される期間に現在日時が所属しているか否かが判定される。特定ログイン用プロセス１１１１Ｓによる第一の判定の結果と第二の判定の結果の両方が肯定的である場合に、特定ユーザのログインが許可される。第一の判定の結果と第二の判定の結果の少なくとも一方が否定的である場合に、特定ユーザのログインが拒否される。

以下、図５及び図６を参照して、本実施形態で行われる処理の流れを説明する。なお、その説明では、適宜に、「ログイン不可時間帯」、「動作チェック時間帯」及び「一般利用可時間帯」といった３種類の時間帯を例に採る。ログイン不可時間帯とは、いずれのユーザからのログインも拒否される時間帯のことである。動作チェック時間帯とは、新サービスのリリース前の上述した動作チェックのための時間帯のことであり、特定ユーザからのログインは許可されるが一般ユーザからのログインは拒否される時間帯である。一般利用可時間帯とは、一般ユーザがサービスを利用することが可能な時間帯のことであり、一般ユーザからのログインは許可されるが動作チェックのための特定ユーザからのログインは拒否される時間帯のことである。業務制御サーバ１０９のＩ／Ｆプログラム１０９２の受信可否状態は、ログイン不可時間帯では、運用サーバ１２１からの制御によりクローズとされ、動作チェック時間帯では、特別運用のために例外的にオープンとされ、一般利用可能時間帯ではオープンとされるものとする。また、業務制御サーバ１０９により参照されるサービス制御テーブル１０９５（図３参照）において、サービスＩＤ“特定ログイン”に対応するサービス許可時間帯（開始時刻及び終了時刻が表す時間帯）は、動作チェック時間帯であり、サービスＩＤ“一般ログイン”に対応するサービス許可時間帯は、一般利用可時間帯であるとする。

特定ユーザに使用されるユーザ端末１０１は、特定ユーザ用ＵＲＬでサーバシステム１０５にアクセスし、一般ユーザに使用されるユーザ端末１０１は、一般ユーザ用ＵＲＬでサーバシステム１０５にアクセスする。ＷＥＢサーバ１０７が、受けたアクセスに使用されたＵＲＬをＷＡＳ１０８に通知する。

図５に示すように、ＷＡＳ１０８では、受付制御プログラム１０８１が、ＷＥＢサーバ１０７が受けたＵＲＬの通知をＷＥＢサーバ１０７から受ける（Ｓ１）。受付制御プログラム１０８１は、そのＵＲＬが特定ユーザ用ＵＲＬであるか一般ユーザ用ＵＲＬであるかを判断する（Ｓ２）。通知されたＵＲＬが特定ユーザ用ＵＲＬである場合（Ｓ２でＹＥＳ）、受付制御プログラム１０８１は、特定ユーザ用ログイン画面１０８３Ｓを表す情報を送信し（Ｓ３）、通知されたＵＲＬが一般ユーザ用ＵＲＬである場合（Ｓ２でＮＯ）、一般ユーザ用ログイン画面１０８３Ｇを表す情報を送信する（Ｓ４）。

送信された情報は、ＷＥＢサーバ１０７を通じて、アクセス元のユーザ端末１０１に送信され、そのユーザ端末１０１において、その情報を基にログイン画面１０８３Ｓ又は１０８３Ｇが表示される。ログイン画面１０８３Ｓ又は１０８３Ｇにおいて、ユーザＩＤ及びパスワードが入力されログインボタン１０８３５が押されたことに応答して、ユーザＩＤ、パスワード、及び、ログインボタン１０８３５を表す情報に埋め込まれているサービスＩＤ（“特定ログイン”又は“一般ログイン”）を含んだログイン要求が、ユーザ端末１０１から送信される。送信されたログイン要求に含まれているユーザＩＤ、パスワード及びサービスＩＤは、ＷＥＢサーバ１０７及びＷＡＳ１０８を通じて、業務制御サーバ１０９のＩ／Ｆプログラム１０９２が受信する。

このとき、前述の例の通り、現在時刻がログイン不可時間帯に属していれば、Ｉ／Ｆプログラム１０９２の受信可否状態がクローズとされている。受信可否状態がクローズであれば（Ｓ５でＹＥＳ）、Ｉ／Ｆプログラム１０９２によりエラー情報が返される（Ｓ６）。エラー情報は、ＷＡＳ１０８及びＷＥＢサーバ１０７を通じて、アクセス元のユーザ端末１０１に送られる。

一方、現在時刻が動作チェック時間帯或いは一般利用可時間帯に属していれば、Ｉ／Ｆプログラム１０９２の受信可否状態がオープンとされている。受信可否状態がオープンであれば（Ｓ５でＹＥＳ）、Ｉ／Ｆプログラム１０９２が受信したサービスＩＤがサービス呼出プログラム１０９３に送られる。

図６に示すように、業務制御サーバ１０９において、サービス呼出プログラム１０９３が、Ｉ／Ｆプログラム１０９２を通じて受けたサービスＩＤに対応するサービス許可時間帯（開始時刻と終了時刻で表される時間帯）及び処理定義を、そのサービスＩＤを用いてサービス制御テーブル１０９５を参照することにより特定し、特定したサービス許可時間帯に現在時刻が属するか否かを判断する（Ｓ７）。現在時刻が属するサービス許可時間帯が無ければ（Ｓ７でＮＯ）、サービス呼出プログラム１０９３がエラー情報を返す（Ｓ８）。エラー情報は、ＷＡＳ１０８及びＷＥＢサーバ１０７を通じて、アクセス元のユーザ端末１０１に送られる。一方、現在時刻が属するサービス許可時間帯が有れば（Ｓ７でＹＥＳ）、サービス呼出プログラム１０９３が、特定された処理定義に対応するプロセスを呼び出す（Ｓ９）。

具体的には、例えば、受けたサービスＩＤが“特定ログイン”である場合、現在時刻が動作チェック時間帯に属していれば、サービス許可時間帯に属するため、Ｓ７でＹＥＳとなりＳ９が実行され、一方、現在時刻が一般利用可時間帯であれば、サービス許可時間帯に属していないため、Ｓ７でＮＯとなりＳ８が実行される。なお、サービスＩＤ“特定ログイン”に対応付けられている処理定義が、ログイン用ＡＰＬサーバ１１１Ｌの特定ログイン用プロセス１１１１Ｓの呼び出しを表しているため、この場合でのＳ９では、特定ログイン用プロセス１１１１Ｓが呼び出される。

また、例えば、受けたサービスＩＤが“一般ログイン”である場合、現在時刻が一般利用可時間帯に属していれば、サービス許可時間帯に属するため、Ｓ７でＹＥＳとなりＳ９が実行され、一方、現在時刻が動作チェック時間帯であれば、サービス許可時間帯に属していないため、Ｓ７でＮＯとなりＳ８が実行される。なお、サービスＩＤ“一般ログイン”に対応付けられている処理定義が、ログイン用ＡＰＬサーバ１１１Ｌの一般ログイン用プロセス１１１１Ｇの呼び出しを表しているため、この場合でのＳ９では、一般ログイン用プロセス１１１１Ｇが呼び出される。

ログイン用ＡＰＬサーバ１１１Ｌでは、呼び出されたプロセス１１１１Ｓ又は１１１１Ｇが実行され（Ｓ１０）、そのプロセス１１１１Ｓ又は１１１１Ｇの結果（つまり、ログインを許可するか拒否するか）が、業務制御サーバ１０９のサービス呼出プログラム１０９３に返される。特定ログイン用プロセス１１１１Ｓが呼び出された場合、前述した第一の判定と第二の判定の両方が行われ、両方の判定の結果が肯定的の場合に、プロセス１１１１Ｓの結果がログインの許可となり、少なくとも一方が否定的の場合に、プロセス１１１Ｓの結果がログインの拒否となる。一般ログイン用プロセス１１１１Ｇが呼び出された場合、前述した第一の判定のみが行われ、その判定の結果が肯定的の場合に、プロセス１１１１Ｇの結果がログインの許可となり、否定的の場合に、プロセス１１１Ｇの結果がログインの拒否となる。

業務制御サーバ１０９のサービス呼出プログラム１０９３は、プロセスの結果に即した結果（ログイン許可或いはログイン拒否）を返す。その結果は、ＷＡＳ１０８及びＷＥＢサーバ１０７を通じて、アクセス元のユーザ端末１０１に送られる。

特定ユーザは、ログインが許可された場合、動作チェック時間帯において、ユーザ端末１０１を操作して、リリース予定の新サービスを利用することができる（新サービスに限らず、他のサービスが利用されても良い）。その際、新サービスを提供するＡＰＬサーバ１１１のプロセスに不具合があることがわかった場合、不具合を直すための処理を行う。もし、動作チェック時間帯において直すことができそうになければ、一般ユーザが新サービスを利用しようとした場合に所望のメッセージ（例えば、リリース予定の新サービスのリリース開始日が遅れる等の告知）が表示されるような設定を行うことができる。

なお、不具合を直したりメッセージが表示されるような設定をしたりといった、不具合対応処理は、特定ユーザから連絡を受けた開発者が開発者端末１２３を使用して行っても良いが、特定ユーザがログインに使用したユーザ端末１０１から行っても良い。そのために、例えば、ＡＰＬサーバ１１１として、不具合対応処理のためのＡＰＬサーバ１１１がサーバシステム１０５に存在してもよい。そして、不具合対応処理を表すサービスＩＤと、不具合対応処理のためのＡＰＬサーバ１１１のプロセスを表した処理定義とが、サービス制御テーブル１０９５において、動作チェック時間帯を表す開始時刻及び終了時刻に対応付けられても良い。これにより、不具合対応処理のサービスの利用を特定ユーザ且つ動作チェック時間帯でのみに制限することができる。

以上が、第一の実施形態についての説明である。この実施形態によれば、下記のことが言える。

（１）サーバシステム１０５へのアクセスのためのＵＲＬとして、一般ユーザ用ＵＲＬの他に、特定ユーザ用ＵＲＬが設けられている。これにより、一般ユーザのログインのための入口と特定ユーザのログインのための入口が論理的に分離することができる。

（２）特定ユーザ用ＵＲＬと一般ユーザ用ＵＲＬのどちらが使用されたかによって、異なるサービスＩＤが埋め込まれた異なるログイン画面情報が送信される。これにより、どちらのＵＲＬを使用したアクセスかによって、どの種のユーザとしてのログインであるかが自動的に決まる。

（３）業務制御サーバ１０９の受信可否状態がオープンであるかクローズであるかによって、特定ユーザであるか一般ユーザであるかに関わらず、情報の受信の可否が制御される。このため、例えば特別の期間中ではない場合には、動作チェック時間帯の開始時刻であっても受信可否状態をクローズとしておくことで、特定ユーザからの不必要なログインを拒否することができる。

（４）業務制御サーバ１０９の受信可否状態がオープンの場合、業務制御サーバ１０９において、サービスＩＤに対応したサービス許可時間帯（開始時刻及び終了時刻が表す時間帯）がサービス制御テーブル１０９５から特定され、現在時刻がサービス許可時間帯に属していなければ、サービスの利用（例えばログイン）が拒否される。動作チェック時間帯には業務制御サーバ１０９の受信可否状態がオープンとされているため、動作チェック時間帯にはサービスＩＤ“特定ログイン”だけでなくサービスＩＤ“一般ログイン”を受け得るが、サービスＩＤ“特定ログイン”にサービス許可時間帯として動作チェック時間帯を対応付け、サービスＩＤ“一般ログイン”にサービス許可時間帯として一般利用可時間帯を対応付けておくことで、動作チェック時間帯に一般ユーザからのログインが許可されてしまうことを防ぐことができる。また、サービスＩＤに対応付けるサービス許可時間帯と処理定義により、動作チェック時間帯に使用禁止サービスが利用されてしまうことを防ぐことができる。

（５）特定ユーザのログインを許可するか否かの判定を行う特定ログイン用プロセス１１１１Ｓが呼び出された場合、ユーザ管理テーブル１１３１だけでなく、特定ユーザ管理テーブル１１３３に、特定ユーザのユーザＩＤが登録されており、且つ、開始日及び終了日が表す期間に現在日時が属していれば、ログインが許可されるが、そうでなければ、ログインが拒否される。つまり、特定ユーザのログインが許可されるのは、その特定ユーザが予め認められたユーザであって、開始日及び終了日が表す期間にアクセスしてきた場合である。このため、予め認められていないユーザから特定ユーザとしての不正なアクセスがあった場合や、開始日及び終了日が表す期間以外にアクセスがあった場合には、ログインを拒否することができる。

（６）業務制御サーバ１０９の受信可否状態を更新する第一の主体と、サーバシステム１０５におけるサービス制御テーブル１０９５及び特定ユーザ管理テーブル１１３３を更新する第二の主体が異なっている。これにより、例えば、受信可否状態とサービス制御テーブル１０９５及び特定ユーザ管理テーブル１１３３とのいずれか一方が不正に更新されても、他方が不正に更新されていなければ、不正にログインされてしまうことを防ぐことができる。なお、サービス制御テーブル１０９５及び特定ユーザ管理テーブル１１３３の両方を、開発者が開発者端末１２３を使用して更新するとしたが、サービス制御テーブル１０９５を更新できる主体と特定ユーザ管理テーブル１１３３を更新できる主体が別々であっても良い。例えば、サーバシステム１０５に、第一の認証情報（例えばＩＤ及びパスワード）を受けた場合にサービス制御テーブル１０９５の更新を許可する第一の更新許否制御プログラムと、第二の認証情報を受けた場合に特定ユーザ管理テーブル１１３３の更新を許可する第二の更新許否制御プログラムとが設けられても良い。こうすることで、サービス制御テーブル１０９５及び特定ユーザ管理テーブル１１３３の一方が不正に更新されても他方が不正に更新されなければ不正にログインが行われてしまうことを防ぐことができる。

以下、本発明の第二の実施形態を説明する。その際、第一の実施形態との相違点を主に説明し、第一の実施形態との共通点については説明を省略或いは簡略する。

この第二の実施形態では、特定ユーザは、第一の実施形態で説明したような動作チェックをするユーザではなく、一般ユーザよりも優遇されているユーザである。具体的には、例えば、一般ユーザが利用可能なサービスを、そのサービスの利用開始時刻よりも早い時刻から利用することができたり、一般ユーザが利用できないようなサービスを利用することができたりするユーザである。

例えば、図７Ａに示すように、特定ユーザ管理テーブル２１３３には、特定ユーザのユーザＩＤ毎に、開始日及び終了日に代えて（又は加えて）、その特定ユーザの現在の資産総額が対応付けられる。

また、図７Ｂに示すように、セッション管理テーブル２０８２が用意され、それが、ＷＡＳ２０８により参照及び更新される。セッション管理テーブル２０８２には、ユーザＩＤ及び現在資産総額の組合せとその組合せに対して用意されたセッションＩＤが登録される。

また、図７Ｃに示すように、業務制御サーバ２０９に参照されるサービス制御テーブル２０９５に、サービスＩＤ及び処理定義の組合せに、開始時刻及び終了時刻に代えて（又は加えて）、資産総額閾値が対応付けられる。

この第二の実施形態では、以下の処理が行われる。

すなわち、図８Ａに示すように、ログイン画面でユーザＩＤ及びパスワードが入力されログインボタンが押された場合に、ＷＡＳ２０８を介して、業務制御サーバ２０９に、ユーザＩＤ、パスワード及びサービスＩＤが入力される。業務制御サーバ２０９によって、そのサービスＩＤに対応したプロセスが呼び出される。特定ログイン用プロセスが呼び出された場合、特定ログイン用プロセスは、第二の判定（又は更なる第三の判定）として、入力されたユーザＩＤに対応した現在資産総額が所定の資産総額を超えているかどうかの判定を行う。その判定の結果が肯定的である場合、特定ログイン用プロセスは、入力されたユーザＩＤとそのユーザＩＤに対応付けられている現在資産総額とを業務制御サーバ２０９に送る。業務制御サーバ２０９は、そのユーザＩＤ及び現在資産総額をＷＡＳ２０８に送る。ＷＡＳ２０８は、そのユーザＩＤ及び現在資産総額に対してセッションＩＤを割り振り、割り振ったセッションＩＤと、ユーザＩＤ及び現在資産総額とをセッション管理テーブル２０８２に登録し、アクセス元のユーザ端末１０１に、セッションＩＤを返す。これにより、特定ユーザからのログインが完了する。

特定ユーザからログインされている状態において、特定ユーザにより何らかのサービスの利用が要求された場合には、図８Ｂに示すように、ＷＡＳ２０８が、そのサービスのサービスＩＤと、割り振られたセッションＩＤとを受ける。ＷＡＳ２０８の受付制御部２０８１は、そのセッションＩＤに対応したユーザＩＤ及び現在資産総額をセッション管理テーブル２０８２から読出し、読み出したユーザＩＤ及び現在資産総額とサービスＩＤとを業務制御サーバ２０９に送る。業務制御サーバ２０９では、サービス呼出部２０９３が、そのサービスＩＤに対応し現在資産総額が資産総額閾値を超えている処理定義をサービス制御テーブル２０９５から特定し、特定された処理定義に対応するプロセスを呼び出す。

この第二の実施形態によれば、特定ユーザとしてユーザＩＤが登録されていても、その特定ユーザの現在の資産総額に応じて、利用可能なサービスを制限することができる。

以上、本発明の幾つかの実施形態を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、サービスＩＤやユーザＩＤに対応付ける値として、開始時刻、終了時刻、開始日、終了日及び現在資産総額を例に採ったが、それ以外の種類の値が対応付けられても良い。

図１は、本発明の第一の実施形態に係るコンピュータシステムの構成を示す。 図２Ａは、ＷＡＳの構成を示す。図２Ｂは、特定ユーザ用ログイン画面を示す。図２Ｃは、一般ユーザ用ログイン画面を示す。 図３は、業務制御サーバの構成と運用サーバの構成を示す。 図４は、ログイン用ＡＰＬサーバの構成とＤＢサーバが管理する各テーブルの構成を示す。 図５は、第一の実施形態で行われる処理の流れの一部を示す。 図６は、第一の実施形態で行われる処理の流れ残りの部分を示す。 図７Ａは、本発明の第二の実施形態における特定ユーザ管理テーブルの構成を示す。図７Ｂは、第二の実施形態でＷＡＳに参照及び更新されるセッション管理テーブルの構成を示す。図７Ｃは、第二の実施形態におけるサービス制御テーブルの構成を示す。 図８Ａは、第二の実施形態におけるログインの流れの説明図である。図８Ｂは、第二の実施形態におけるログイン完了後のサービス利用制限の説明図である。

符号の説明

１０１Ｓ…特定ユーザ端末 １０１Ｇ…一般ユーザ端末 １０３…通信ネットワーク １０５…サーバシステム １０７…ＷＷＷサーバ １０８…ＷＡＳ（ＷＥＢアプリケーションサーバ） １０９…業務制御サーバ １１１…ＡＰＬ（アプリケーション）サーバ １１３…ＤＢ（データベース）サーバ

Claims (9)

1. 特定ユーザとしてのログインの許否を判断する特定ログインプロセスと、一般ユーザとしてのログインの許否を判断する一般ログインプロセスとを含んだ一又は複数のアプリケーションプログラムと、
   サービスの提供のための処理を表した情報である処理定義とそのサービスの識別子とがサービス毎に対応付けられたサービス制御情報と、
   ユーザに利用されるサービスの識別子を受信する受信手段と、
   前記受信手段で受信したサービス識別子に対応した処理定義を前記サービス管理情報から特定し、特定した処理定義を基に特定されるプロセスを実行させるサービス制御手段と
   を備え、
   サービス識別子として、特定ユーザとしてのログインを表す特定ログインと、一般ユーザとしてのログインを表す一般ログインとがあり、
   前記サービス制御情報において、サービス毎に、更に、サービス許可時間帯が対応付けられており、
   前記特定ログインに対応付けられている処理定義は、前記特定ログインプロセスの実行を表し、前記一般ログインに対応付けられている処理定義は、前記一般ログインプロセスの実行を表し、
   前記サービス制御手段が、前記受信したサービス識別子に対応したサービス許可時間帯を前記サービス制御情報から特定し、特定されたサービス許可時間帯に現在時刻が属していれば、そのサービス識別子に対応した処理定義から特定されるプロセスを実行させるようになっており、
   前記受信したサービス識別子が、前記特定ログインであるならば、前記サービス制御手段が、前記特定ログインに対応付けられている処理定義が表す特定ログインプロセスを実行させ、
   前記受信したサービス識別子が、前記一般ログインであるならば、前記サービス制御手段が、前記一般ログインに対応付けられている処理定義が表す一般ログインプロセスを実行させる、
   サーバシステム。
2. 特定ユーザ用のＵＲＬと一般ユーザ用のＵＲＬのいずれかのＵＲＬを用いたアクセスをユーザ端末から受け付けるアクセス受付手段と、
   前記特定ユーザ用のＵＲＬを用いたアクセスを受けた場合に、前記特定ログインが埋め込まれた特定ログイン画面情報を前記ユーザ端末に送信し、前記一般ユーザ用のＵＲＬを用いたアクセスを受けた場合に、前記一般ログインが埋め込まれた一般ログイン画面情報を前記ユーザ端末に送信するログイン画面情報送信手段と
   を更に備え、
   前記受信手段が、前記ユーザ端末において特定ログイン画面情報が表すログイン画面にログイン要求が入力された場合に、その特定ログイン画面情報に埋め込まれている前記特定ログインを受信し、前記ユーザ端末において一般ログイン画面情報が表すログイン画面にログイン要求が入力された場合に、その一般ログイン画面情報に埋め込まれている前記一般ログインを受信する、
   請求項１記載のサーバシステム。
3. 前記受信手段は、それの受信可否状態が受信可状態であれば、前記サービス識別子を受け付け、その受信可否状態が受信不可状態であれば、前記サービス識別子を受け付けない、
   請求項１記載のサーバシステム。
4. ログインが許可されるユーザのユーザ識別子が登録されたユーザ管理情報と、特定ユーザのユーザ識別子が登録された特定ユーザ管理情報とが更に備えられ、
   前記受信手段が、サービス識別子とユーザ識別子とを受信し、
   前記一般ログインプロセスは、前記受信したユーザ識別子が前記ユーザ管理情報に登録されていれば、ログインを許可するとの判断をし、
   前記特定ログインプロセスは、前記受信したユーザ識別子が前記ユーザ管理情報と前記特定ユーザ管理情報の両方に登録されていれば、ログインを許可するとの判断をする、
   請求項１乃至３のうちのいずれか１項に記載のサーバシステム。
5. 前記特定ユーザ管理情報には、特定ユーザ毎に、更に、所定種類の値が対応付けられており、
   前記特定ログインプロセスは、前記受信したユーザ識別子が前記ユーザ管理情報と前記特定ユーザ管理情報の両方に登録されており、且つ、そのユーザ識別子に対応した所定種類の値が所定の条件を満たしている場合に、ログインを許可するとの判断をする、
   請求項４記載のサーバシステム。
6. 前記受信可否状態を更新する第一の主体と、前記特定ユーザ管理情報を更新する第二の主体とが異なっている、
   請求項５記載のサーバシステム。
7. 前記サービス識別子として、アプリケーションプログラムの動作チェックにおいて発見された不具合に対応するためのサービスを表す不具合対応があり、
   前記一又は複数のアプリケーションプログラムに、前記不具合に対応するためのプロセスが含まれており、
   そのプロセスの実行を表す処理定義が、前記サービス制御情報において、前記不具合対応に対応付けられている、
   請求項１記載のサーバシステム。
8. ユーザ識別子、所定種類の値及びセッション識別子が登録されるセッション管理情報と、
   セッション識別子の割り振りを行うセッション管理手段と
   を更に備え、
   前記サービス制御情報において、サービス毎に、更に、閾値が対応付けられており、
   前記特定ログインプロセスは、ログインを許可するとの判断になった場合、ユーザ識別子及び所定種類の値を送信し、
   前記セッション管理手段が、前記送信されたユーザ識別子及び所定種類の値と割り振られたセッション識別子とを前記セッション管理情報に登録し、そのセッション識別子を送信し、その後、ユーザ端末から、サービス識別子とそのセッション識別子とを受け付け、そのセッション識別子に対応したユーザ識別子及び所定種類の値を前記セッション管理情報から特定し、特定されたユーザ識別子及び所定種類の値と、受け付けたサービス識別子とを、前記サービス制御手段に送信し、
   前記サービス制御手段が、そのサービス識別子に対応した閾値を前記サービス制御情報から特定し、受けた所定種類の値が特定された閾値を超えている場合に、そのサービス識別子に対応した処理定義を基に特定されるプロセスを実行させる、
   請求項５記載のサーバシステム。
9. ユーザに利用されるサービスの識別子を受信し、
   受信したサービス識別子に対応した処理定義を、サービスの提供のための処理を表した情報である処理定義とそのサービスの識別子とサービス許可時間帯とがサービス毎に対応付けられたサービス制御情報から特定し、
   特定された処理定義が、特定ユーザとしてのログインを表すサービス識別子に対応している処理定義であるならば、特定ユーザとしてのログインの許否を判断する特定ログインプロセスを実行し、
   特定された処理定義が、一般ユーザとしてのログインを表すサービス識別子に対応している処理定義であるならば、一般ユーザとしてのログインの許否を判断する一般ログインプロセスを実行し、
   ログインの許可がされた後、サービス識別子として、アプリケーションプログラムの動作チェックにおいて発見された不具合に対応するためのサービスを表す不具合対応を受信した場合、その不具合対応に対応したサービス許可時間帯を前記サービス制御情報から特定し、特定されたサービス許可時間帯に現在時刻が属していれば、不具合対応に対応した処理定義から特定される、不具合に対応するためのプロセスを実行する、
   事前動作チェックの際に発見された不具合への対応方法。

Images