JP2013161353A

JP2013161353A - ネットワークシステム

Info

Publication number: JP2013161353A
Application number: JP2012024220A
Authority: JP
Inventors: Kazuhiro Ogura; 一宏小椋
Original assignee: HDE Inc
Current assignee: HDE Inc
Priority date: 2012-02-07
Filing date: 2012-02-07
Publication date: 2013-08-19
Anticipated expiration: 2032-02-07
Also published as: JP5918557B2

Abstract

【課題】クラウドコンピューティングにおいてコスト削減が可能であり、障害に耐えられると共に、データの整合性を維持可能なユーザ認証を行うことが可能なネットワークシステムを提供すること。
【解決手段】メインサーバ、複数のサブサーバそれぞれがインターネットを介して接続され、端末、当該複数のサブサーバそれぞれがインターネットを介して接続されたネットワークシステムであって、サブサーバが認証処理を行い、サブサーバが端末からのパスワードの更新登録要求情報を受け付けた場合に、メインサーバに新たなパスワードを送信する。
【選択図】図１

Description

本発明は、ネットワークシステムに関する。

従来から、端末から受信したユーザＩＤとパスワードなどのユーザ情報と、認証データベースに登録されているユーザ情報とを照合してユーザ認証を行うネットワークシステムが存在する。

このようなネットワークシステムでは、認証サーバを多重化し、障害に強いシステムを構築する場合がある。例えば、特許文献１に開示されている認証システムは、多重化された認証サーバ間で定期的に通信を行い、通信のために鍵ペアを用いることが記載されている（特許文献１の００１９段落参照）。

また、近年は、クラウドコンピューティングと呼ばれるシステムによって、インターネットを介してユーザの端末が何処からでもサーバにアクセスできるようになり、ユーザの利便性を図れるようになってきている。このようなクラウドコンピューティングでは、ユーザに提供するサービスの開発を行う会社（開発者）が、クラウドコンピューティングのサーバを提供する会社からサーバを借り受け、このサーバ上に、Ｗｅｂアプリケーション等の付随機能を開発することがある。

クラウドコンピューティングのサーバを提供する会社から借り受けるサーバは、サーバ構築がなされており、セキュリティ、バックアップ機能等が充実し障害にも強いので、開発者はサーバ管理に関する労力を省くことができ、ユーザに提供するサービス（付随機能）の開発業務に特化できる。また、開発者は、自社でサーバを運用するよりも費用を削減できる。このように、クラウドコンピューティングはサービスの提供を受けるユーザだけでなく開発者にとってもメリットが多い。

特開２００５−１６５６７１号公報

クラウドコンピューティングにおいてユーザ認証を行う場合には、データを多重化し、障害に耐えられるシステムを提供することが望ましい。また、クラウドコンピューティングにおいてユーザに提供するサービスを開発する開発者は、クラウドコンピューティングのサーバ（メインサーバ）を提供する会社に対して、使用料金を支払うことがある。例えば、開発者は、メインサーバを提供する会社に対して、メインサーバの所定単位あたりの使用料金（例えば、メインサーバのデータベースへの１回の参照に伴う使用料金、１ギガバイトあたりの使用料金、メインサーバの１ＣＰＵ時間あたりの使用料金等）を支払うことになる。

本発明は、上述した課題に鑑みたものであり、クラウドコンピューティングにおいてコスト削減が可能であり、障害に耐えられると共に、データの整合性を維持可能なユーザ認証を行うことが可能なネットワークシステムを提供することにある。

（１）本発明は、メインサーバ、複数のサブサーバそれぞれがインターネットを介して接続され、端末、当該複数のサブサーバそれぞれがインターネットを介して接続されたネットワークシステムであって、前記サブサーバは、サブサーバ用の認証データベースと、前記端末から受信したユーザＩＤとパスワードとを含むユーザ情報と、前記サブサーバ用の認証データベースに登録されているユーザ情報とを照合して認証判定を行う認証判定部と、前記端末からユーザ情報の更新登録要求情報を受信した場合であって前記メインサーバと通信可能である場合に、前記サブサーバ用の認証データベースに登録されているユーザ情報を、前記端末から受信したユーザ情報に更新する処理を行う、又は、前記端末から受信したユーザ情報を前記サブサーバ用の認証データベースに登録する処理を行うデータ制御部と、前記端末からユーザ情報の更新登録要求情報を受信した場合であって前記メインサーバと通信可能である場合に、前記端末から受信したユーザ情報を前記メインサーバに送信する処理を行う通信制御部とを含み、前記メインサーバは、メインサーバ用の認証データベースと、前記サブサーバからユーザ情報を受信する処理を行う通信制御部と、前記サブサーバからユーザ情報を受信した場合に、前記メインサーバ用の認証データベースに登録されているユーザ情報を、受信したユーザ情報に更新する処理を行う、又は、受信したユーザ情報を前記メインサーバ用の認証データベースに登録する処理を行うデータ制御部とを含み、前記サブサーバの通信制御部が、前記端末からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバ及び前記メインサーバと通信可能である場合に、当該ユーザ情報に含まれるユーザＩＤを当該他のサブサーバに送信する処理を行い、他のサブサーバから送信されたユーザＩＤを受信した場合に、前記メインサーバから当該ユーザＩＤのユーザ情報を受信する処理を行い、前記サブサーバのデータ制御部が、他のサブサーバから送信されたユーザＩＤを受信した場合に、自サーバ用の認証データベースに登録されている当該ユーザＩＤのユーザ情報を、前記メインサーバから受信した当該ユーザＩＤのユーザ情報に更新する処理を行う、又は、前記メインサーバから受信した当該ユーザＩＤのユーザ情報を自サーバ用の認証データベースに登録する処理を行うネットワークシステムに関する。

本発明によれば、サブサーバが認証判定を行い、ユーザ情報の更新時又は登録時のみにメインサーバへのアクセスが行われることになる。つまり、本発明によれば、メインサーバへのアクセスを減らすことができるので、開発者がクラウドコンピューティングのサーバを提供する会社に支払う費用を削減することが可能である。また、本発明によれば、セキュリティや障害に強いメインサーバに認証データベースのデータが格納され、更にサブサーバを多重化しているので障害に耐えられるシステムを提供できる。また、一のサブサーバにおいてユーザ情報の更新又は登録があった場合に、他のサブサーバはメインサーバからユーザ情報を受信して更新又は登録するのでデータの整合性を維持することができる。

（２）また、本発明のネットワークシステムは、前記複数のサブサーバそれぞれとインターネットを介して接続される更新通知データベースを更に含み、前記サブサーバが、所定周期で、前記更新通知データベースに自サーバの識別情報に対応づけられたユーザＩＤが登録されているか否かを判断する判断部を更に含み、前記サブサーバのデータ制御部が、前記端末からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバと通信不能である場合に、当該他のサブサーバの識別情報に対応づけて、当該ユーザ情報に含まれるユーザＩＤを前記更新通知データベースに登録する処理を行い、前記サブサーバの通信制御部が、前記更新通知データベースに自サーバの識別情報に対応づけられたユーザＩＤが登録されている場合に、前記メインサーバから当該ユーザＩＤのユーザ情報を受信する処理を行い、前記サブサーバのデータ制御部が、前記更新通知データベースに自サーバの識別情報に対応づけられたユーザＩＤが登録されている場合に、自サーバ用の認証データベースに登録されているユーザ情報を、前記メインサーバから受信した当該ユーザＩＤのユーザ情報に更新する処理を行う、又は、前記メインサーバから受信した当該ユーザＩＤのユーザ情報を自サーバ用の認証データベースに登録する処理を行うようにしてもよい。

本発明によれば、サブサーバは所定周期で自サーバ用の認証データベースに登録されているユーザ情報を更新又は認証データベースにユーザ情報を登録すべきか判断することになる。つまり、サブサーバ間で通信不能である場合において、サブサーバはメインサーバからユーザ情報を受信することによってデータの整合性を維持することができる。

（３）また、本発明のネットワークシステムは、前記サブサーバのデータ制御部が、前記更新通知データベースに登録されている当該ユーザＩＤの更新日時が自サーバ用の認証データベースに登録されている当該ユーザＩＤの更新日時よりも新しい場合に、自サーバ用の認証データベースに登録されているユーザ情報を、前記メインサーバから受信した当該ユーザＩＤのユーザ情報に更新する処理を行うようにしてもよい。

本発明によれば、サブサーバにおいて、更新日時の新しいユーザ情報が認証データベースに登録されていることになるのでデータの整合性を維持することができる。

本実施形態のネットワーク図の一例。図２（Ａ）（Ｂ）（Ｃ）は、本実施形態の機能ブロック図の一例。図３（Ａ）（Ｂ）（Ｃ）は、データベースの説明図。図４（Ａ）（Ｂ）（Ｃ）は、ネットワークの概略図。本実施形態の処理の流れを示すフローチャート図。本実施形態の処理の流れを示すフローチャート図。本実施形態の処理の流れを示すフローチャート図。本実施形態の処理の流れを示すフローチャート図。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

１．ネットワーク
図１は、本実施形態のネットワーク図の一例である。本実施形態のネットワークシステムは、メインサーバ１０、２以上のサブサーバ３０それぞれがインターネット（広義にはネットワーク）を介して接続される。また、本実施形態のネットワークシステムは、端末２０、複数のサブサーバ３０それぞれがインターネットを介して接続される。また、本実施形態のネットワークシステムは、複数のサブサーバ３０それぞれと更新通知データベース４１とがインターネットを介して接続される。また、サブサーバ３０、各種サーバ５１〜５４それぞれがインターネットを介して接続される。

メインサーバ１０は、開発者がクラウドコンピューティングのサーバを提供する会社から従量課金で借り受けるスペックの高いサーバであり、メインサーバ１０は認証データベース１１（メインサーバ用の認証データベース）を含む。認証データベース１１には、サブサーバ３０においてユーザ認証を行うためのユーザ情報等のデータが格納されている。

また、サブサーバ３０は、ユーザの端末２０から送信されるユーザ情報に基づいて、ユーザに提供するサービスの認証処理を行う。サブサーバ３０は、開発者が所有するサーバでもよいし、開発者がクラウドコンピューティングのサーバを提供する会社から定額課金で安く借り受けられるスペックの低いサーバでもよい。サブサーバ３０は認証データベース３１（サブサーバ用の認証データベース）を含む。認証データベース３１には、ユーザ認証を行うためのユーザ情報等のデータが格納されている。

また、本実施形態では、複数のサブサーバ３０が相互にインターネットに接続され、多重化されている。例えば、図１に示すように、サブサーバ３０−Ａ、３０−Ｂがそれぞれインターネットに接続される。そして、端末２０は、ＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）６０等によってサブサーバ３０−Ａ、３０−Ｂのうちいずれかのサブサーバにアクセスすることになる。なお、本実施形態では、端末２０がサブサーバ３０−Ａ、３０−Ｂのうちいずれのサーバへアクセスするかを、ＤＮＳ以外の負荷分散装置に基づいて決定してもよい。

また、本実施形態のネットワークシステムのＤＮＳのＭＸレコードには、サブサーバ３０−Ａのサーバ名を定義するレコードと、サブサーバ３０−Ｂのサーバ名を定義するレコードとを設定する。その際に、サブサーバ３０−Ａ、３０−ＢのＭＸレコードの優先順位（プリファレンス値）を同位にして設定してもよい。このようにすれば、サブサーバ３０−Ａ、３０−Ｂそれぞれが、ほぼ均等に端末２０からのアクセスを受け付けることができる。

サブサーバ３０は、ネットワークを介して、複数の端末２０と接続される。例えば、本実施形態のサブサーバ３０は、インターネットを介して、会社や学校などの小規模ネットワーク７０を構成する各端末２０−Ａ〜２０−Ｃと接続されている。また、サブサーバ３０は、インターネットを介して、ｕｓｅｒＡの自宅８０の端末２０−Ｆと接続可能である。なお、本実施形態の端末２０は有線又は無線によってサブサーバ３０と接続される。

また、サブサーバ３０（３０−Ａ、３０−Ｂ）は、ネットワークを介してメールサーバ５１、ファイルサーバ５２、ショッピングサーバ５３、写真サーバ５４などの種々のサーバ（サービス提供サーバ）と接続されている。例えば、メールサーバ５１は、サブサーバ３０が認証を許可したユーザＩＤに関するメールサービスの提供を行う。また、ファイルサーバ５２は、サブサーバ３０が認証を許可したユーザＩＤに関するファイルサービスの提供を行う。また、ショッピングサーバ５３は、サブサーバ３０が認証を許可したユーザＩＤに関するショッピングサービスの提供を行う。また、写真サーバ５４は、サブサーバ３０が認証を許可したユーザＩＤに関する写真サービスの提供を行う。つまり、ユーザは、１つのユーザＩＤとパスワード等を覚えるだけで、サブサーバ３０への認証が許可されると種々のサーバ５１〜５４からサービスの提供を受けることができるシングルサインオンが可能となる。なお、サブサーバ３０は、各種サーバ５１〜５４と認証の許可又は不許可等のデータを送信する場合には、電子署名などを用いてデータの暗号化を行うようにしてもよい。

２．構成
図２（Ａ）（Ｂ）（Ｃ）は、本実施形態のネットワークシステムの機能ブロック図の一例である。なお、本実施形態のネットワークシステムは、図２の各部を全て含む必要はなく、その一部を省略した構成としてもよい。

２．１メインサーバ
まず、図２（Ａ）を用いて、メインサーバ１０の機能について説明する。記憶部１７０は、処理部１００などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などのハードウェアにより実現できる。

また、情報記憶媒体１８０は、コンピュータにより読み取り可能であり、この情報記憶媒体１８０にはプログラムやデータなどが格納されている。即ち、情報記憶媒体１８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。つまり、処理部１００は、この情報記憶媒体１８０に格納されるプログラム（データ）から読み出されたデータに基づいて本実施形態の種々の処理を行うことができる。

例えば、情報記録媒体１８０は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）、メモリカード等である。

処理部１００は、記憶部１７０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。なお、本実施形態の処理部１００が、情報記憶媒体１８０に格納されているプログラムやデータを読み出し、読み出したプログラムやデータを記憶部１７０に格納し、そのプログラムやデータに基づいて処理を行ってもよい。

処理部１００（プロセッサ）は、記憶部１７０内の主記憶部をワーク領域として各種処理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）などのハードウェアや、プログラムにより実現できる。処理部１００は、通信制御部１１１、データ制御部１１２を含む。

通信制御部１１１は、サブサーバ３０とネットワーク（イントラネット又はインターネット）を介してデータを送受信する処理を行う。例えば、通信制御部１１１は、サブサーバ３０から送信されるユーザＩＤ、パスワード等のユーザ情報を受信する処理を行う。

データ制御部１１２は、認証データベース１１に、情報（データ）を登録する処理、更新する処理、削除する処理等を行う。例えば、データ制御部１１２は、サブサーバ３０からユーザ情報（ユーザＩＤ、パスワード）を受信した場合に、認証データベース１１に登録されているユーザ情報を、受信したユーザ情報に更新する処理を行う、又は、受信したユーザ情報を認証データベース１１に登録する処理を行う。例えば、データ制御部１１２は、サブサーバ３０からユーザ情報を受信した場合であって、認証データベース１１に当該ユーザ情報が登録されていない場合に、受信した当該ユーザ情報を認証データベース１１に登録する処理を行う。なお、データ制御部１１２は、サブサーバ３０からユーザ情報の更新要求情報を受信した場合にサブサーバ３０から受信したユーザ情報に更新する処理を行い、サブサーバ３０からユーザ情報の登録要求情報を受信した場合に受信したユーザ情報を認証データベース１１に登録してもよい。また、データ制御部１１２は、サブサーバ３０からユーザ情報の削除要求情報を受信した場合に、当該ユーザ情報を認証データベース１１から削除してもよい。

また、メインサーバ１０は、認証データベース１１を含む。認証データベース１１には、ユーザＩＤ、当該ユーザＩＤのパスワード等の情報が登録（格納、記憶）される。なお、本実施形態の認証データベース１１に、ユーザＩＤに対応づけて多要素認証に必要な証明情報、ワンタイムパスワードのｓｅｅｄ番号（種番号）等を格納してもよい。また、本実施形態では、メインサーバ１０のデータ制御部１１２が、ユーザ情報を認証データベース１１に登録する処理を行う。

なお、本実施形態では、メインサーバ１０の記憶部１７０に、認証データベース１１のデータを記憶させるようにしてもよいし、認証データベース１１の記憶部（記憶領域）は、メインサーバ１０の記憶部１７０（記憶領域）から物理的に分離されていてもよい。例えば、認証データベース１１は、ネットワーク（イントラネット又はインターネット）を介してメインサーバ１０と接続されていてもよい。

また、本実施形態では、管理者からの入力情報に基づいて、ユーザ情報を認証データベース１１に登録してもよい。また、管理者からの入力情報に基づいて、認証データベース１１に登録されているユーザ情報を更新してもよい。また、管理者からの入力情報に基づいて、認証データベース１１からユーザ情報を削除してもよい。

２．２サブサーバ
次に、図２（Ｂ）を用いて、サブサーバ３０の機能について説明する。記憶部３７０は、処理部３００などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などのハードウェアにより実現できる。

また、情報記憶媒体３８０は、コンピュータにより読み取り可能であり、この情報記憶媒体３８０にはプログラムやデータなどが格納されている。即ち、情報記憶媒体３８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。つまり、処理部３００は、この情報記憶媒体３８０に格納されるプログラム（データ）から読み出されたデータに基づいて本実施形態の種々の処理を行うことができる。

例えば、情報記録媒体３８０は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）、メモリカード等である。

処理部３００は、記憶部３７０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。なお、本実施形態の処理部３００が、情報記憶媒体３８０に格納されているプログラムやデータを読み出し、読み出したプログラムやデータを記憶部３７０に格納し、そのプログラムやデータに基づいて処理を行ってもよい。

処理部３００（プロセッサ）は、記憶部３７０内の主記憶部をワーク領域として各種処理を行う。処理部３００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）などのハードウェアや、プログラムにより実現できる。処理部３００は、通信制御部３１１、データ制御部３１２、判断部３１３、認証判定部３１４、Ｗｅｂ処理部３１５を含む。

通信制御部３１１は、メインサーバ１０、端末２０とネットワークを介してデータを送受信する処理を行う。例えば、通信制御部３１１は、端末２０によって送信されるユーザＩＤ、パスワードを含むユーザ情報を受信する処理を行う。また、通信制御部３１１は、認証の許可又は不許可を端末２０に送信するようにしてもよい。

また、通信制御部３１１は、端末２０からユーザ情報の更新登録要求情報を受信した場合であってメインサーバ１０と通信可能である場合に、端末２０から受信したユーザ情報をメインサーバ１０に送信する処理を行う。

また、通信制御部３１１は、端末２０からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバ３０及びメインサーバ１０と通信可能である場合に、当該ユーザ情報に含まれるユーザＩＤを当該他のサブサーバに送信する処理を行う。例えば、サブサーバ３０−Ａの通信制御部３１１は、端末２０からユーザ情報の更新登録要求情報を受信した場合であってサブサーバ３０−Ｂ及びメインサーバ１０と通信可能である場合に、当該ユーザ情報に含まれるユーザＩＤをサブサーバ３０−Ｂに送信する処理を行う。また、サブサーバ３０−Ｂの通信制御部３１１は、端末２０からユーザ情報の更新登録要求情報を受信した場合であってサブサーバ３０−Ａ及びメインサーバ１０と通信可能である場合に、当該ユーザ情報に含まれるユーザＩＤをサブサーバ３０−Ａに送信する処理を行う。

また、通信制御部３１１は、他のサブサーバから送信されたユーザＩＤを受信した場合に、メインサーバ１０から当該ユーザＩＤのユーザ情報を受信する処理を行う。例えば、サブサーバ３０−Ａの通信制御部３１１は、サブサーバ３０−Ｂから送信されたユーザＩＤを受信した場合に、メインサーバ１０から当該ユーザＩＤのユーザ情報を受信する処理を行う。また、サブサーバ３０−Ｂの通信制御部３１１は、サブサーバ３０−Ａから送信されたユーザＩＤを受信した場合に、メインサーバ１０から当該ユーザＩＤのユーザ情報を受信する処理を行う。

また、通信制御部３１１は、更新通知データベース４１に自サーバの識別情報に対応づけられたユーザＩＤが登録されている場合に、メインサーバ１０から当該ユーザＩＤのユーザ情報を受信する処理を行う。例えば、サブサーバ３０−Ａの通信制御部３１１は、更新通知データベース４１にサブサーバ３０−Ａの識別情報に対応づけられたユーザＩＤが登録されている場合に、メインサーバ１０から当該ユーザＩＤのユーザ情報を受信する処理を行う。また、サブサーバ３０−Ｂの通信制御部３１１は、更新通知データベース４１にサブサーバ３０−Ｂの識別情報に対応づけられたユーザＩＤが登録されている場合に、メインサーバ１０から当該ユーザＩＤのユーザ情報を受信する処理を行う。

また、通信制御部３１１は、メールサーバ５１、ファイルサーバ５２、ショッピングサーバ５３、写真サーバ５４の各種サーバとネットワークを介してデータを送受信する処理を行う。例えば、通信制御部３１１は、認証の許可又は不許可を各種サーバ５１〜５４に送信するようにしてもよい。

データ制御部３１２は、認証データベース１１や更新通知データベース４１にデータの追加、削除、変更等の制御を行う。例えば、データ制御部３１２は、端末２０からユーザ情報（ユーザＩＤ、パスワード）を受信した場合に、所定条件下で認証データベース３１に登録されているユーザ情報を、受信したユーザ情報に更新する処理を行う。また、データ制御部３１２は、所定条件下でユーザ情報を認証データベース３１に登録してもよい。また、データ制御部３１２は、所定条件下でユーザ情報を認証データベース３１から削除してもよい。

また、データ制御部３１２は、所定条件下で更新通知データベース４１に登録されているユーザＩＤ等を更新する処理を行ってもよい。また、データ制御部３１２は、所定条件下でユーザＩＤ等を更新通知データベース４１に登録してもよい。また、データ制御部３１２は、所定条件下でユーザＩＤ等を更新通知データベース４１から削除してもよい。

特に、本実施形態のデータ制御部３１２は、端末２０からユーザ情報の更新登録要求情報を受信した場合であってメインサーバ１０と通信可能である場合に、サブサーバ用の認証データベース３１に登録されているユーザ情報を、端末２０から受信したユーザ情報に更新する処理を行う、又は、端末２０から受信したユーザ情報をサブサーバ用の認証データベース３１に登録する処理を行う。例えば、データ制御部３１２は、端末２０からユーザ情報を受信した場合であって、認証データベース３１に当該ユーザ情報が登録されていない場合に、受信した当該ユーザ情報を認証データベース３１に登録する処理を行う。

また、データ制御部３１２は、他のサブサーバから送信されたユーザＩＤを受信した場合に、自サーバ用の認証データベース３１に登録されている当該ユーザＩＤのユーザ情報を、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報に更新する処理を行う。例えば、サブサーバ３０−Ａのデータ制御部３１２は、サブサーバ３０−Ｂから送信されたユーザＩＤを受信した場合に、自サーバ３０−Ａ用の認証データベース３１−Ａに登録されている当該ユーザＩＤのユーザ情報を、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報に更新する処理を行う。また、サブサーバ３０−Ｂのデータ制御部３１２は、サブサーバ３０−Ａから送信されたユーザＩＤを受信した場合に、自サーバ３０−Ｂ用の認証データベース３１−Ｂに登録されている当該ユーザＩＤのユーザ情報を、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報に更新する処理を行う。

また、データ制御部３１２は、他のサブサーバから送信されたユーザＩＤを受信した場合に、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報を自サーバ用の認証データベース３１に登録する処理を行ってもよい。例えば、サブサーバ３０−Ａのデータ制御部３１２は、サブサーバ３０−Ｂから送信されたユーザＩＤを受信した場合であって、認証データベース３１−Ａに当該ユーザ情報が登録されていない場合に、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報を認証データベース３１−Ａに登録する処理を行う。また、サブサーバ３０−Ｂのデータ制御部３１２は、サブサーバ３０−Ａから送信されたユーザＩＤを受信した場合であって、認証データベース３１−Ｂに当該ユーザ情報が登録されていない場合に、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報を認証データベース３１−Ｂに登録する処理を行う。

また、データ制御部３１２は、更新通知データベース４１に自サーバの識別情報に対応づけられたユーザＩＤが登録されている場合に、自サーバ用の認証データベース３１に登録されているユーザ情報を、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報に更新する処理を行う。例えば、サブサーバ３０−Ａのデータ制御部３１２は、更新通知データベース４１にサブサーバ３０−Ａの識別情報に対応づけられたユーザＩＤが登録されている場合に、サブサーバ３０−Ａ用の認証データベース３１−Ａに登録されているユーザ情報を、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報に更新する処理を行う。また、サブサーバ３０−Ｂのデータ制御部３１２は、更新通知データベース４１にサブサーバ３０−Ｂの識別情報に対応づけられたユーザＩＤが登録されている場合に、サブサーバ３０−Ｂ用の認証データベース３１−Ｂに登録されているユーザ情報を、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報に更新する処理を行う。

また、データ制御部３１２は、更新通知データベース４１に自サーバの識別情報に対応づけられたユーザＩＤが登録されている場合に、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報を自サーバ用の認証データベースに登録する処理を行ってもよい。例えば、サブサーバ３０−Ａのデータ制御部３１２は、更新通知データベース４１に自サーバ３０−Ａの識別情報に対応づけられたユーザＩＤが登録されている場合であって、認証データベース３１−Ａに当該ユーザ情報が登録されていない場合に、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報を認証データベース３１−Ａに登録する処理を行う。また、サブサーバ３０−Ｂのデータ制御部３１２は、更新通知データベース４１に自サーバ３０−Ｂの識別情報に対応づけられたユーザＩＤが登録されている場合であって、認証データベース３１−Ｂに当該ユーザ情報が登録されていない場合に、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報を認証データベース３１−Ｂに登録する処理を行う。

また、データ制御部３１２は、更新通知データベース４１に登録されている当該ユーザＩＤの更新日時が自サーバ用の認証データベース３１に登録されている当該ユーザＩＤの更新日時よりも新しい場合に、自サーバ用の認証データベース３１に登録されているユーザ情報を、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報に更新する処理を行う。

例えば、サブサーバ３０−Ａのデータ制御部３１２は、更新通知データベース４１に登録されている当該ユーザＩＤの更新日時がサブサーバ３０−Ａ用の認証データベース３１−Ａに登録されている当該ユーザＩＤの更新日時よりも新しい場合に、サブサーバ３０−Ａ用の認証データベース３１−Ａに登録されているユーザ情報を、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報に更新する処理を行う。

また、サブサーバ３０−Ｂのデータ制御部３１２は、更新通知データベース４１に登録されている当該ユーザＩＤの更新日時がサブサーバ３０−Ｂ用の認証データベース３１−Ｂに登録されている当該ユーザＩＤの更新日時よりも新しい場合に、サブサーバ３０−Ｂ用の認証データベース３１−Ｂに登録されているユーザ情報を、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報に更新する処理を行う。

データ制御部３１２は、端末２０からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバと通信不能である場合に、当該他のサブサーバの識別情報に対応づけて、当該ユーザ情報に含まれるユーザＩＤを更新通知データベース４１に登録する処理を行う。なお、本実施形態のデータ制御部３１２は、（Ａ）端末２０からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバと通信不能である場合、かつ、（Ｂ）メインサーバ１０と通信可能である場合に、当該他のサブサーバの識別情報に対応づけて、当該ユーザ情報に含まれるユーザＩＤを更新通知データベース４１に登録する処理を行う。

例えば、サブサーバ３０−Ａのデータ制御部３１２は、（Ａ）端末２０からユーザ情報の更新登録要求情報を受信した場合であってサブサーバ３０−Ｂと通信不能である場合、かつ、（Ｂ）サブサーバ３０−Ａとメインサーバ１０とが通信可能である場合に、サブサーバ３０−Ｂの識別情報に対応づけて、当該ユーザ情報に含まれるユーザＩＤを更新通知データベース４１に登録する処理を行う。

また、例えば、サブサーバ３０−Ｂのデータ制御部３１２は、（Ａ）端末２０からユーザ情報の更新登録要求情報を受信した場合であってサブサーバ３０−Ａと通信不能である場合、かつ、（Ｂ）サブサーバ３０−Ｂとメインサーバ１０とが通信可能である場合に、サブサーバ３０−Ａの識別情報に対応づけて、当該ユーザ情報に含まれるユーザＩＤを更新通知データベース４１に登録する処理を行う。

判断部３１３は、所定周期で（例えば、１０分毎に）、更新通知データベース４１に自サーバの識別情報に対応づけられたユーザＩＤが登録されているか否かを判断する。例えば、サブサーバ３０−Ａの判断部３１３は、所定周期で更新通知データベース４１にサブサーバ３０−Ａの識別情報に対応づけられたユーザＩＤが登録されているか否かを判断する。また、サブサーバ３０−Ｂの判断部３１３は、所定周期で更新通知データベース４１にサブサーバ３０−Ｂの識別情報に対応づけられたユーザＩＤが登録されているか否かを判断する。

また、データ制御部３１２は、端末２０からユーザ情報の更新要求情報を受信した場合に、認証データベース３１に登録されているユーザ情報を、端末２０から受信したユーザ情報に更新する処理を行ってもよい。また、データ制御部３１２は、端末２０からユーザ情報の登録要求情報を受信した場合に、端末２０から受信したユーザ情報を認証データベース３１に登録する処理を行ってもよい。また、データ制御部３１２は、端末２０からユーザ情報の削除要求情報を受信した場合に、認証データベース３１から当該ユーザ情報を削除する処理を行ってもよい。

認証判定部３１４は、ユーザＩＤの認証の許可又は不許可を判定する。例えば、認証判定部３１４は、端末２０から受信したユーザＩＤとパスワードとを含むユーザ情報と、サブサーバ用の認証データベース３１に登録されているユーザ情報とを照合して認証判定を行う。つまり、認証判定部３１４は、端末２０から受信したユーザＩＤと、認証データベース３１に登録されているユーザＩＤが一致し、端末２０から受信したユーザＩＤのパスワードと、認証データベース３１に登録されている当該ユーザＩＤに対応づけられたパスワードとが一致する場合に認証を許可し、ユーザＩＤ又はパスワードが一致しない場合は認証を不許可と判定する。なお、認証判定部３１４は、証明情報、ワンタイムパスワードの照合、ＳＳＬクライアント証明書等を用いた認証を行ってもよい。

Ｗｅｂ処理部３１５は、Ｗｅｂサーバとして機能する。例えば、Ｗｅｂ処理部３１５は、ＨＴＴＰ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）を通じて、端末２０にインストールされているＷｅｂブラウザ２１０の要求に応じてデータを送信する処理、端末２０のＷｅｂブラウザ２１０によって送信されるデータを受信する処理を行う。特に、本実施形態では、Ｗｅｂ処理部３１５が、ユーザ認証を行うためのログイン画面を提供し、端末２０のＷｅｂブラウザ２１０によって送信されたユーザＩＤ、パスワード等のユーザ情報を受信する処理を行うようにしてもよい。

また、サブサーバ３０は、認証データベース３１を含む。認証データベース３１には、ユーザＩＤ、当該ユーザＩＤのパスワード等の情報が登録（格納、記憶）される。なお、本実施形態の認証データベース３１に、ユーザＩＤに対応づけて多要素認証に必要な証明情報、ワンタイムパスワードのｓｅｅｄ番号（種番号）等を格納してもよい。

なお、本実施形態では、サブサーバ３０の記憶部３７０に、認証データベース３１のデータを記憶させるようにしてもよいし、認証データベース３１の記憶部（記憶領域）は、サブサーバ３０の記憶部３７０（記憶領域）から物理的に分離されていてもよい。例えば、認証データベース３１は、ネットワーク（イントラネット又はインターネット）を介してサブサーバ３０と接続されていてもよい。

つまり、サブサーバ３０−Ａの記憶部３７０に、認証データベース３１−Ａのデータを記憶させるようにしてもよいし、認証データベース３１−Ａの記憶部（記憶領域）は、サブサーバ３０−Ａの記憶部３７０（記憶領域）から物理的に分離されていてもよい。

また、サブサーバ３０−Ｂの記憶部３７０に、認証データベース３１−Ｂのデータを記憶させるようにしてもよいし、認証データベース３１−Ｂの記憶部（記憶領域）は、サブサーバ３０−Ｂの記憶部３７０（記憶領域）から物理的に分離されていてもよい。

また、本実施形態では、管理者からの入力情報に基づいて、ユーザ情報を認証データベース３１に登録してもよい。また、管理者からの入力情報に基づいて、認証データベース３１に登録されているユーザ情報を更新してもよい。また、管理者からの入力情報に基づいて、認証データベース３１からユーザ情報を削除してもよい。

２．３端末
次に、図２（Ｃ）を用いて、端末２０の機能について説明する。端末２０は、コンピュータ、スマートフォン、タブレット型コンピュータ、携帯電話、ゲーム機などである。記憶部２７０は、処理部２００などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などのハードウェアにより実現できる。

また、情報記憶媒体２８０は、コンピュータにより読み取り可能であり、この情報記憶媒体２８０にはプログラムやデータなどが格納されている。即ち、情報記憶媒体２８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。つまり、処理部２００は、この情報記憶媒体２８０に格納されるプログラム（データ）から読み出されたデータに基づいて本実施形態の種々の処理を行うことができる。

例えば、情報記録媒体２８０は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）、メモリカード等である。

処理部２００は、記憶部２７０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。なお、本実施形態の処理部２００が、情報記憶媒体２８０に格納されているプログラムやデータを読み出し、読み出したプログラムやデータを記憶部２７０に格納し、そのプログラムやデータに基づいて処理を行ってもよい。

処理部２００（プロセッサ）は、記憶部２７０内の主記憶部をワーク領域として各種処理を行う。処理部２００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）などのハードウェアや、プログラムにより実現できる。

処理部２００は、Ｗｅｂブラウザ２１０、通信制御部２１１を含む。端末２０は、Ｗｅｂブラウザ２１０によって、インターネットを介してＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）によって指定されたＷｅｂサーバからの情報を表示させることができる。例えば、端末２０は、サブサーバ３０において認証が許可されると、Ｗｅｂサーバ機能を備えたメールサーバ５１から端末２０のユーザＩＤのメール情報（ユーザの受信メール、送信されたメール等）を表示させることができる。また、本実施形態のＷｅｂブラウザ２１０は、ファイルのダウンロードが禁止されているＷｅｂブラウザであってもよい。

通信制御部２１１は、ネットワークを介してサブサーバ３０、各種サーバ５１〜５４等とデータを送受信する処理を行う。例えば、通信制御部２１１は、入力部２２０から入力されたユーザＩＤとパスワードとを、サブサーバ３０に送信する処理を行う。本実施形態では、ＤＮＳ６０によってサブサーバ３０−Ａ、３０−Ｂのうちいずれかのサブサーバに、ユーザＩＤとパスワードとを含むユーザ情報を送信する処理を行う。

また、通信制御部２１１は、認証判定の結果（許可又は不許可）をサブサーバ３０から受信するようにしてもよい。また、通信制御部２１１は、サブサーバ３０によって認証が許可された場合に、メールサーバ５１から当該端末２０のユーザＩＤに関するメール情報を受信するようにしてもよい。

入力部２２０は、ユーザ（操作者）からの入力情報を入力するための入力機器（コントローラ）であり、ユーザの入力情報を処理部２００に出力する。本実施形態の入力部２２０は、ユーザの入力情報（入力信号）を検出する検出部を備えていてもよい。例えば、入力部２２０は、キーボードの入力情報を検出し、タッチパネル型ディスプレイの接触位置（タッチ位置）を検出する。

また、入力部２２０は、３軸の加速度を検出する加速度センサや、角速度を検出するジャイロセンサ、撮像部を備えた入力機器でもよい。また入力部２２０は、入力機器と一体化されている端末２０（スマートフォン、携帯電話、携帯端末、携帯型ゲーム装置）なども含まれる。

表示部２９０は、ブラウザの情報、画像を出力するものであり、その機能は、ＣＲＴ、ＬＣＤ、タッチパネル型ディスプレイ、あるいはＨＭＤ（ヘッドマウントディスプレイ）などにより実現できる。

２．４更新通知データベース
本実施形態のネットワークシステムは、更新通知データベース４１を含む。更新通知データベース４１は、サブサーバ３０の識別情報毎に、更新が必要なユーザＩＤが登録（格納、記憶）される。本実施形態では、サブサーバ３０のデータ制御部３１２が、登録処理を行う。

なお、本実施形態では、更新通知データベース４１の記憶部（記憶領域）は、各サブサーバ３０−Ａ、３０−Ｂの記憶部３７０（記憶領域）、から物理的に分離されている。例えば、更新通知データベース４１は、ネットワーク（インターネット）を介してサブサーバ３０と接続されている。

また、本実施形態では、管理者からの入力情報に基づいて、ユーザＩＤ等を更新通知データベース４１に登録してもよい。また、管理者からの入力情報に基づいて、更新通知データベース４１に登録されているユーザＩＤ等を更新してもよい。また、管理者からの入力情報に基づいて、更新通知データベース４１からユーザＩＤ等を削除してもよい。

３．本実施形態の処理の手法
本実施形態では、クラウドコンピューティングで認証を行うサーバを多重化する手法を採用する。例えば、図１に示すように、認証を行うサーバ（認証サーバ）は、サブサーバ３０−Ａ、サブサーバ３０−Ｂである。なお、本実施形態のネットワークシステムでは、２つのサブサーバ３０によって構成されているが、３つ以上のサブサーバ３０で構成されていてもよい。

また、本実施形態では、図１に示すように、ＤＮＳ６０によって、端末２０からは複数のサブサーバ（サブサーバ３０−Ａ、３０−Ｂ）のうちいずれか一方のサブサーバが選択される。そして、端末２０は、選択されたサブサーバにおいて認証要求（ログイン処理要求）を行う。つまり、本実施形態によれば、複数のサブサーバで運用されるので、仮に一方のサブサーバに障害が発生しても、他方のサブサーバが運用を続けている限り端末からのログインが可能となる。このように、本実施形態では障害に耐えられるシステムを提供している。

また、メインサーバ１０は認証データベース１１を含み、サブサーバ３０は認証データベース３１を含む。図３（Ａ）は、メインサーバ１０、サブサーバ３０が管理する認証データベース１１、３１に登録されているユーザ情報の一例である。ユーザ情報は、ユーザＩＤ（ユーザ識別情報、ユーザ名）、パスワードを含む。また、ユーザ情報（ユーザＩＤ又はパスワード）が更新される度に更新日時（タイムスタンプ）が登録される。本実施形態では、「Ａ会社」、「Ｂ会社」、「ＡＢＣ学校」のように組織毎にユーザ情報を管理する。例えば、図３（Ａ）は、「Ａ会社」のユーザ情報の一例である。

また、本実施形態では、メインサーバ１０が管理する認証データベース１１を複製したデータが、サブサーバ３０が管理する認証データベース３１に登録される。また、本実施形態では、サブサーバ３０を多重化しているので、サブサーバ３０−Ａ、３０−Ｂそれぞれの認証データベース３１−Ａ、３１−Ｂには、メインサーバ１０が管理する認証データベース１１を複製したデータが格納される。

ところで、メインサーバ１０は、クラウドコンピューティングのサーバを提供する会社から従量課金で借り受けるサーバであり、認証データベース１１への参照回数、更新回数などのクエリー回数が増加するにつれて、開発者がクラウドコンピューティングのサーバを提供する会社へ支払う費用が増大する。そのため、費用削減のために、サブサーバ３０からメインサーバ１０へのクエリー回数等を節約し、効率よくデータの整合性を図ることが望ましい。

そこで、本実施形態ではサブサーバ３０が認証処理を行い、サブサーバ３０が端末２０からのパスワードの更新登録要求情報を受け付けた場合に、メインサーバ１０に新たなパスワードを送信するように制御している。つまり、サブサーバ３０が端末２０から受信したユーザ情報に基づき認証判定を行うので、認証判定のための端末２０からメインサーバ１０へのクエリー（参照、アクセス）を防止することができる。また、サブサーバ３０はパスワード等のユーザ情報が更新されるタイミングで、メインサーバ１０にユーザ情報を送信する。そして、メインサーバ１０は、サブサーバ３０から受信したユーザ情報に基づいて更新処理を行うようにする。このように、メインサーバ１０へのクエリー回数を節約し、効率よくデータの整合性を図っている。また、本実施形態では、データの整合性を図るために、端末２０からパスワードの更新登録要求情報を受け付けた場合に、サブサーバ３０がメインサーバ１０と通信可能である場合に自サーバ３０においてパスワードを更新する。

なお、本実施形態のサブサーバ３０は、使用料金が固定のサーバであり、メインサーバ１０のようにクエリー回数で料金が変動するサーバではない。

また、本実施形態では、端末２０がＤＮＳ６０によって割り振られた１つのサブサーバ３０においてパスワードの更新登録要求情報を受け付けている。したがって、本実施形態では、一方のサブサーバにおいてパスワードの更新処理を行った場合に、他方のサブサーバにおいても更新処理を行い、パスワード変更時のデータ整合性を図れるようにしている。

特に本実施形態では、メインサーバ１０の認証データベース１１に格納されているデータが正しいデータであるとみなして運用している。例えば、図４（Ａ）に示すように、メインサーバ１０、サブサーバ３０−Ａ、３０−Ｂがそれぞれ互いに通信可能な場合には、次のように更新処理を行う。

まず、サブサーバ３０−Ａが、端末２０からのパスワードの更新登録要求情報を受け付けると自サーバ３０−Ａにおいてパスワードの更新処理を行い、メインサーバ１０にユーザＩＤ、パスワードを含むユーザ情報を送信する。かかる場合に、サブサーバ３０−Ａは、メインサーバ１０にユーザ情報の更新登録要求情報を送信してもよい。そして、サブサーバ３０−Ａは、サブサーバ３０−Ｂに、更新されたパスワードを送信せずに、更新されたユーザＩＤを送信するようにしている。かかる場合に、サブサーバ３０−Ａは、サブサーバ３０−Ｂにユーザ情報の更新登録要求情報を送信してもよい。

そして、ユーザＩＤを受信したサブサーバ３０−Ｂは、メインサーバ１０に問い合わせ、メインサーバ１０の認証データベース１１から当該ユーザＩＤに対応する新たなパスワードを受信し、サブサーバ３０−Ｂはパスワードの更新処理を行っている。このように、本実施形態では、データの整合性を図るために、サブサーバ３０−Ｂは、メインサーバ１０からパスワードを受信して更新するように制御している。

このように本実施形態では、メインサーバ１０へのアクセスを減らすことができるので、クラウドコンピューティングにおいてコスト削減が可能である。また、サブサーバ３０を多重化しているので、障害に耐えられる。また、一のサブサーバにおいてユーザ情報の変更があった場合に、他のサブサーバはメインサーバ１０からユーザ情報を受信して更新するのでデータの整合性を維持することができる。

また、図４（Ｂ）に示すように、サブサーバ３０−Ａ、３０−Ｂで通信不能な場合がある。本実施形態では、図４（Ｂ）に示すように、サブサーバ３０−Ａ、３０−Ｂ間で通信不能である場合には、更新通知データベース４１に更新情報を格納する処理を行い、各サブサーバ３０−Ａ、３０−Ｂは、所定周期で更新通知データベース４１を参照し、メインサーバ１０からパスワードを受信して、パスワードの更新処理を行うようにしている。

図３（Ｂ）は、更新通知データベース４１に登録されているサブサーバ３０−Ｂの識別情報「２」に対応づけて登録された、サブサーバ３０−Ｂに通知するための更新情報９０の一例である。更新情報は、ユーザＩＤを含み、更新日時（タイムスタンプ）が登録される。更新日時は、更新通知データベース４１に登録された日時でもよいし、サブサーバ３０−Ａにおいてユーザ情報が更新された更新日時でもよい。つまり、図３（Ｂ）は、メインサーバ１０、サブサーバ３０−ＡにおいてｕｓｅｒＡ、ｕｓｅｒＢのパスワードの変更処理が行われたが、サブサーバ３０−Ａ、３０−Ｂ間で通信ができない場合に、サブサーバ３０−Ａがサブサーバ３０−ＢにｕｓｅｒＡ、ｕｓｅｒＢがパスワードを変更したことを知らせるための情報を更新情報９０として、サブサーバ３０−Ｂの識別情報「２」に対応づけて、更新通知データベース４１に登録している。

例えば、サブサーバ３０−Ａが、端末２０から、ｕｓｅｒＡのパスワード変更を受け付けた場合には、まず、サブサーバ３０−Ａ、メインサーバ１０においてパスワードを更新する。そして、サブサーバ３０−Ａがサブサーバ３０−Ｂと通信できない場合には、更新通知データベース４１に、変更されたユーザＩＤ「ｕｓｅｒＡ」、及び更新日時「２０１２年１月１２日９時１５分２０秒」を登録する。

サブサーバ３０−Ｂは、所定周期（例えば、１０分毎）に更新通知データベース４１のサブサーバ３０−Ｂの識別情報「２」に対応付けられた更新情報を参照し、更新通知データベース４１にユーザＩＤが格納されている場合には、そのユーザＩＤの新たなパスワードをメインサーバ１０から取得して、更新処理を行う。例えば、更新通知データベース４１に、図３（Ｂ）に示すように、ｕｓｅｒＡ、ｕｓｅｒＢのデータが格納されていたとする。すると、サブサーバ３０−Ｂは、ｕｓｅｒＡ、ｕｓｅｒＢの更新日時を参照し、更新通知データベース４１に登録されているｕｓｅｒＡの更新日時が、サブサーバ３０−Ｂの認証データベース３１−Ｂに既に登録されているｕｓｅｒＡの更新日時よりも新しい場合に、更新処理を行う。同様に、サブサーバ３０−Ｂは、更新通知データベース４１に登録されているｕｓｅｒＢの更新日時が、サブサーバ３０−Ｂの認証データベース３１−Ｂに既に登録されているｕｓｅｒＢの更新日時よりも新しい場合に、更新処理を行う。例えば、更新通知データベース４１に登録されているｕｓｅｒＡの更新日時が「２０１２年１月１２日９時１５分２０秒」であり、サブサーバ３０−Ｂの認証データベース３１−Ｂに既に登録されているｕｓｅｒＡの更新日時は「２０１２年１月３日７時５分１３秒」である場合には、更新通知データベース４１に登録されているｕｓｅｒＡのパスワードが新しいので、更新処理を行う。

また、図３（Ｃ）は、更新通知データベース４１に登録されているサブサーバ３０−Ａの識別情報「１」に対応づけて登録された、サブサーバ３０−Ａに通知するための更新情報９１の一例である。更新日時は、更新通知データベース４１に登録された日時でもよいし、サブサーバ３０−Ｂにおいてユーザ情報が更新された更新日時でもよい。つまり、図３（Ｃ）は、メインサーバ１０、サブサーバ３０−ＢにおいてｕｓｅｒＦ、ｕｓｅｒＡのパスワードの変更処理が行われたが、サブサーバ３０−Ａ、３０−Ｂ間で通信ができない場合に、サブサーバ３０−Ｂがサブサーバ３０−ＡにｕｓｅｒＦ、ｕｓｅｒＡがパスワードを変更したことを知らせるための情報を更新情報９１として、サブサーバ３０−Ａの識別情報「１」に対応づけて、更新通知データベース４１に登録している。このように、本実施形態では、サブサーバ毎に、更新情報を格納している。

例えば、サブサーバ３０−Ｂが、端末２０から、ｕｓｅｒＡのパスワード変更を受け付けた場合には、まず、サブサーバ３０−Ｂ、メインサーバ１０においてパスワードを更新する。そして、サブサーバ３０−Ｂがサブサーバ３０−Ａと通信できない場合には、更新通知データベース４１に、変更されたユーザＩＤ「ｕｓｅｒＡ」、及び更新日時「２０１２年１月１１日１時１２分４５秒」を登録する。

サブサーバ３０−Ａは、所定周期（例えば、１０分毎）に、更新通知データベース４１のサブサーバ３０−Ａの識別情報「１」に対応付けられた更新情報を参照し、更新通知データベース４１にユーザＩＤが格納されている場合には、そのユーザＩＤの新たなパスワードをメインサーバ１０から取得して、更新処理を行う。例えば、更新通知データベース４１に、図３（Ｃ）に示すように、ｕｓｅｒＦ、ｕｓｅｒＡのデータが格納されていたとする。すると、サブサーバ３０−Ａは、ｕｓｅｒＦ、ｕｓｅｒＡのデータを参照し、更新通知データベース４１に登録されているｕｓｅｒＦの更新日時が、サブサーバ３０−Ａの認証データベース３１−Ａに既に登録されているｕｓｅｒＦの更新日時よりも新しい場合に、更新処理を行う。同様に、サブサーバ３０−Ａは、更新通知データベース４１に登録されているｕｓｅｒＡの更新日時が、サブサーバ３０−Ａの認証データベース３１−Ａに既に登録されているｕｓｅｒＡの更新日時よりも新しい場合に、更新処理を行う。例えば更新通知データベース４１に登録されているｕｓｅｒＡの更新日時が「２０１２年１月１１日１時１２分４５秒」であり、サブサーバ３０−Ａの認証データベース３１−Ａに既に登録されているｕｓｅｒＡの更新日時は「２０１２年１月１２日９時１５分２０秒」である場合には、更新通知データベース４１に登録されているｕｓｅｒＡのパスワードが古いので、更新処理を行わない。つまり、認証データベース３１−Ａに既に登録されているｕｓｅｒＡの更新日時が新しいので更新処理を行わずに処理を終了する。

なお、更新通知データベース４１に格納される更新情報９０、９１は、「ユーザＩＤ」に対応づけて「更新日時」を登録している。また、各サブサーバ３０−Ａ、３０−Ｂは、所定周期（例えば、１０分毎）に更新通知データベース４１を参照した場合には、参照後、更新通知データベース４１から参照済みのデータを削除する処理を行うようにしてもよい。

また、図４（Ｃ）に示すように、サブサーバ３０−Ａ、メインサーバ１０間で通信ができない場合には、サブサーバ３０−Ａ、３０−Ｂ、及びメインサーバ１０においてパスワード（ユーザ情報）の更新処理ができないように制御している。なお、本実施形態では、サブサーバ３０−ＡはユーザＩＤ、パスワードを用いた認証処理は可能であり、端末２０はログインを行うことは可能である。また、図４（Ｃ）に示すように、サブサーバ３０−Ｂ、メインサーバ１０間において通信可能な場合には、サブサーバ３０−Ｂ、メインサーバ１０において更新処理が可能である。例えば、サブサーバ３０−Ａとメインサーバ１０間において通信可能となった場合には、サブサーバ３０−Ａが更新通知データベース４１を参照することによって速やかにユーザ情報の更新処理を行うことができる。

なお、本実施形態では、サブサーバ３０が、自サーバから送信された接続確認情報（パケット）に対するメインサーバ１０からの返答パケットを所定期間内（例えば１０秒以内）に受信しなかった場合に、そのサブサーバ３０がメインサーバ１０と通信不能と判断し、そのサブサーバ３０がメインサーバ１０からの返答パケットを所定期間内に受信した場合に、そのサブサーバ３０がメインサーバ１０と通信可能と判断する。

また、本実施形態では、サブサーバ３０−Ａが、自サーバ３０−Ａから送信された接続確認情報（パケット）に対するサブサーバ３０−Ｂからの返答パケットを所定期間内（例えば１０秒以内）に受信しなかった場合に、サブサーバ３０−Ａがサブサーバ３０−Ｂと通信不能と判断し、サブサーバ３０−Ａがサブサーバ３０−Ｂからの返答パケットを所定期間内に受信した場合に、サブサーバ３０−Ａがサブサーバ３０−Ｂと通信可能と判断する。

同様に、サブサーバ３０−Ｂが、自サーバ３０−Ｂから送信された接続確認情報（パケット）に対するサブサーバ３０−Ａからの返答パケットを所定期間内（例えば１０秒以内）に受信しなかった場合に、サブサーバ３０−Ｂがサブサーバ３０−Ａと通信不能と判断し、サブサーバ３０−Ｂがサブサーバ３０−Ａからの返答パケットを所定期間内に受信した場合に、サブサーバ３０−Ｂがサブサーバ３０−Ａと通信可能と判断する。

４．処理の流れ
図５（Ａ）〜（Ｄ）は、本実施形態においてユーザＩＤに対応付けられたパスワードを更新する際の処理の流れを説明するためのフローチャートである。説明の便宜上、２つのサブサーバ３０−Ａ、３０−Ｂのうち、サブサーバ３０−Ａが端末２０からユーザ情報の更新登録要求情報を受信し、新たなパスワードを受け付けた場合を例にとり説明しているが、サブサーバ３０−Ｂが端末２０からユーザ情報の更新登録要求情報及び新たなパスワードを受けて付けてもよい。なお、サブサーバ３０−Ｂが端末２０からユーザ情報の更新登録要求情報を受信し、新たなパスワードを受け付けた場合には、以後の処理においてサブサーバ３０−Ａが図５（Ａ）〜（Ｄ）の３０−Ｂの処理を行い、サブサーバ３０−Ｂが図５（Ａ）〜（Ｄ）の３０−Ａの処理を行うことになる。

まず、図５（Ａ）に示すように、サブサーバ３０−Ａは、端末２０からユーザ情報の更新登録要求情報及び新たなパスワード（変更後のパスワード）を受信する（ステップＳ１０１）。そして、メインサーバ１０と通信可能か否かを判断する（ステップＳ１０２）。メインサーバ１０と通信可能でない場合には処理を終了する（ステップＳ１０２のＮ）。一方、メインサーバ１０と通信可能である場合には（ステップＳ１０２のＹ）、ユーザＩＤのパスワードを更新する（ステップＳ１０３）。つまり、端末２０から受け付けたユーザＩＤに対応するパスワードを、新たなパスワードとして更新する。次に、メインサーバ１０に、パスワードが更新されたユーザＩＤ及びパスワードを送信する（ステップＳ１０４）。

また、メインサーバ１０は、サブサーバ３０−ＡからユーザＩＤ及びパスワードを受信し（ステップＳ３０１）、当該ユーザＩＤのパスワードの更新処理を行う（ステップＳ３０２）。つまり、メインサーバ１０は、サブサーバ３０−ＡからユーザＩＤとパスワードとを受信し、そのユーザＩＤに対応するパスワードを受信したパスワードに更新する。

そして、サブサーバ３０−Ａは、サブサーバ３０−Ｂと通信可能か否かを判断する（ステップＳ１０５）。サブサーバ３０−Ａがサブサーバ３０−Ｂと通信可能（ステップＳ１０５のＹ）である場合には、図５（Ｂ）に示すように、サブサーバ３０−Ａが、サブサーバ３０−Ｂに更新されたユーザＩＤを送信する。サブサーバ３０−Ｂは、サブサーバ３０−ＡからユーザＩＤを受信し（ステップＳ２１１）、メインサーバ１０に当該ユーザＩＤのパスワードを要求する処理を行う（ステップＳ２１２）。メインサーバ１０は、ユーザＩＤのパスワード要求情報を受信すると（ステップＳ３１１）、当該ユーザＩＤのパスワードをサブサーバ３０−Ｂに送信する処理を行う（ステップＳ３１２）。そして、サブサーバ３０−Ｂは、ユーザＩＤのパスワードを受信すると（ステップＳ２１３）、当該ユーザＩＤのパスワードを更新する処理を行う（ステップＳ２１４）。

サブサーバ３０−Ａがサブサーバ３０−Ｂと通信不能（ステップＳ１０５のＮ）である場合には、図５（Ｃ）に示すように、サブサーバ３０−Ａが更新通知データベース４１に、サブサーバ３０−Ｂの識別情報、更新されたユーザＩＤ、更新日時を登録する（ステップＳ１２１）。

また、サブサーバ３０−Ｂは、所定周期で更新情報を確認し（ステップＳ２２１）、更新確認が到来すると（ステップＳ２２１のＹ）、更新通知データベース４１に登録されているサブサーバ３０−Ｂの識別情報「２」に対応づけられた更新情報を参照する（ステップＳ２２２）。

更新情報がある場合、つまり、更新通知データベース４１に登録されているサブサーバ３０−Ｂの識別情報「２」に対応づけられた更新情報（更新されたユーザＩＤ）がある場合には（ステップＳ２２３のＹ）、更新通知データベース４１に登録されているユーザＩＤを参照する（ステップＳ２２４）。一方、更新情報がない場合、つまり、更新通知データベース４１に登録されているサブサーバ３０−Ｂの識別情報「２」に対応づけられた更新情報（更新されたユーザＩＤ）がない場合には（ステップＳ２２３のＮ）、処理を終了する。

そして、図５（Ｄ）に示すように、サブサーバ３０−Ｂは、更新通知データベース４１において参照したユーザＩＤの更新日時と、既に認証データベース３１−Ｂに登録されている当該ユーザＩＤの更新日時とを比較し、更新通知データベース４１において参照したユーザＩＤの更新日時が新しい場合に、当該ユーザＩＤのパスワードを、メインサーバ１０に要求する（ステップＳ２３１）。

そして、メインサーバ１０は、ユーザＩＤのパスワード要求情報を受信すると（ステップＳ３３１）、そのユーザＩＤのパスワードをサブサーバ３０−Ｂに送信する（ステップＳ３３２）。そして、サブサーバ３０−Ｂは、メインサーバ１０からユーザＩＤのパスワードを受信すると（ステップＳ２３２）、当該ユーザＩＤのパスワードを更新する処理を行う（ステップＳ２３３）。そして、参照したユーザＩＤの更新情報を削除する処理を行う（ステップＳ２３４）。以上で処理が終了する。

５．その他
５．１更新処理について
本実施形態では、サブサーバ３０−Ａ、３０−Ｂ、メインサーバ１０において、ユーザ情報に含まれるパスワードの更新を例にとり説明したが、パスワード以外の情報、例えば、ユーザＩＤに対応づけて登録されている多要素認証に必要な「証明情報」、「ワンタイムパスワードのｓｅｅｄ番号（種番号）」等を更新する場合も、パスワードと同様に更新処理を行うようにしてもよい。

５．２メインサーバとの通信可否について
本実施形態では、サブサーバ３０とメインサーバ１０との通信可否につき、サブサーバ３０から送信された接続確認情報（パケット）に対するメインサーバ１０からの返答パケットが所定期間内に受信可能か否かで通信可能・不可能を判断する方法を例にとり説明したが、メインサーバ１０の認証データベース１１の当該ユーザ情報の更新が成功するか否かで通信可能・不可能を判断するようにしてもよい。

５．３登録処理について
本実施形態では、主に更新処理について説明したがユーザ情報の登録処理は次のようにして行う。具体的に説明すると、サブサーバ３０が、端末２０からユーザ情報の更新登録要求情報を受信した場合であってメインサーバ１０と通信可能である場合に、端末２０から受信したユーザ情報をサブサーバ用の認証データベース３１に登録する処理を行う。例えば、端末２０から受信したユーザ情報が認証データベース３１に未だ登録されていない場合に、当該ユーザ情報を登録する処理を行う。なお、サブサーバ３０は、メインサーバ１０と通信不能である場合には、登録処理を行わない。

また、サブサーバ３０が、他のサブサーバから送信されたユーザＩＤを受信した場合に、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報を自サーバ用の認証データベース３１に登録する処理を行う。例えば、サブサーバ３０が、他のサブサーバから送信されたユーザＩＤを受信した場合であって、当該ユーザＩＤが認証データベース３１に未だ登録されていない場合に、当該ユーザ情報を登録する処理を行う。

また、サブサーバ３０は、所定周期に、更新通知データベース４１に自サーバの識別情報に対応付けられた更新情報を参照し、更新通知データベース４１に自サーバの識別情報に対応づけられたユーザＩＤが登録されている場合に、メインサーバ１０から当該ユーザＩＤのユーザ情報を受信し、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報を自サーバ用の認証データベース３１に登録する処理を行う。例えば、メインサーバ１０から受信した当該ユーザＩＤのユーザ情報が認証データベース３１に未だ登録されていない場合に、当該ユーザＩＤのユーザ情報を登録する処理を行う。

５．４削除処理について
本実施形態のサブサーバ３０は、端末２０から削除要求情報を受信した場合に、端末２０から受信したユーザ情報の削除処理を行ってもよい。

具体的に説明すると、サブサーバ３０が、端末２０からユーザ情報の削除要求情報を受信した場合であってメインサーバ１０と通信可能である場合に、サブサーバ用の認証データベース３１に登録されているユーザ情報を削除する処理を行い、端末２０から受信したユーザ情報（ユーザＩＤでもよい）と削除要求情報とを、メインサーバ１０に送信する処理を行う。なお、サブサーバ３０は、メインサーバ１０と通信不能である場合には、削除処理を行わない。

そして、メインサーバ１０は、サブサーバ３０からユーザ情報と削除要求情報とを受信すると、メインサーバ用の認証データベース１１から当該ユーザ情報（サブサーバ３０から受信したユーザＩＤのユーザ情報）を削除する処理を行う。

また、サブサーバ３０（例えばサブサーバ３０−Ａ）は、端末２０からユーザ情報の削除要求情報を受信した場合であって他のサブサーバ３０（例えばサブサーバ３０−Ｂ）及びメインサーバ１０と通信可能である場合に、削除要求情報と当該ユーザ情報に含まれるユーザＩＤとを、当該他のサブサーバ３０（例えばサブサーバ３０−Ｂ）に送信する処理を行う。

また、サブサーバ３０（例えばサブサーバ３０−Ａ）は、他のサブサーバ３０（例えばサブサーバ３０−Ｂ）から送信された削除要求情報とユーザＩＤとを受信した場合に、自サーバ用の認証データベース３１（例えばサブサーバ３１−Ａ）から当該ユーザＩＤのユーザ情報を削除する処理を行う。

また、サブサーバ３０（例えばサブサーバ３０−Ａ）は、端末２０からユーザ情報の削除要求情報を受信した場合であって他のサブサーバ（例えばサブサーバ３０−Ｂ）と通信不能である場合に、当該他のサブサーバの識別情報（例えばサブサーバ３０−Ｂの識別情報「２」）に対応づけて、削除要求情報と共に当該ユーザ情報に含まれるユーザＩＤを、更新情報として更新通知データベース４１に登録する処理を行う。

そして、サブサーバ３０（例えばサブサーバ３０−Ｂ）は、所定周期に、更新通知データベース４１に自サーバの識別情報に対応付けられた更新情報を参照し、更新通知データベース４１に自サーバの識別情報（例えばサブサーバ３０−Ｂの識別情報「２」）に対応づけられたユーザＩＤと当該ユーザＩＤの削除要求情報とが登録されている場合に、自サーバ用の認証データベース３１（例えば認証データベース３１−Ｂ）から当該ユーザＩＤのユーザ情報を削除する処理を行う。

１０メインサーバ、１１認証データベース、１００処理部、１１１通信制御部、
１１２データ制御部、１７０記憶部、１８０情報記憶媒体、
２０端末、２００処理部、２１０Ｗｅｂブラウザ、２１１通信制御部、
２２０入力部、２７０記憶部、２８０情報記憶媒体、２９０表示部
３０、３０−Ａ、３０−Ｂサブサーバ、３１認証データベース、
３１−Ａサブサーバ３０−Ａ用の認証データベース、
３１−Ｂサブサーバ３０−Ｂ用の認証データベース、
３００処理部、３１１通信制御部、３１２データ制御部、３１３判断部、
３１４認証判定部、３１５Ｗｅｂ処理部、３７０記憶部、３８０情報記憶媒体、
４１更新通知データベース、５１メールサーバ、５２ファイルサーバ、
５３ショッピングサーバ、５４写真サーバ、６０ＤＮＳ

Claims

メインサーバ、複数のサブサーバそれぞれがインターネットを介して接続され、端末、当該複数のサブサーバそれぞれがインターネットを介して接続されたネットワークシステムであって、
前記サブサーバは、
サブサーバ用の認証データベースと、
前記端末から受信したユーザＩＤとパスワードとを含むユーザ情報と、前記サブサーバ用の認証データベースに登録されているユーザ情報とを照合して認証判定を行う認証判定部と、
前記端末からユーザ情報の更新登録要求情報を受信した場合であって前記メインサーバと通信可能である場合に、前記サブサーバ用の認証データベースに登録されているユーザ情報を、前記端末から受信したユーザ情報に更新する処理を行う、又は、前記端末から受信したユーザ情報を前記サブサーバ用の認証データベースに登録する処理を行うデータ制御部と、
前記端末からユーザ情報の更新登録要求情報を受信した場合であって前記メインサーバと通信可能である場合に、前記端末から受信したユーザ情報を前記メインサーバに送信する処理を行う通信制御部とを含み、
前記メインサーバは、
メインサーバ用の認証データベースと、
前記サブサーバからユーザ情報を受信する処理を行う通信制御部と、
前記サブサーバからユーザ情報を受信した場合に、前記メインサーバ用の認証データベースに登録されているユーザ情報を、受信したユーザ情報に更新する処理を行う、又は、受信したユーザ情報を前記メインサーバ用の認証データベースに登録する処理を行うデータ制御部とを含み、
前記サブサーバの通信制御部が、
前記端末からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバ及び前記メインサーバと通信可能である場合に、当該ユーザ情報に含まれるユーザＩＤを当該他のサブサーバに送信する処理を行い、
他のサブサーバから送信されたユーザＩＤを受信した場合に、前記メインサーバから当該ユーザＩＤのユーザ情報を受信する処理を行い、
前記サブサーバのデータ制御部が、
他のサブサーバから送信されたユーザＩＤを受信した場合に、自サーバ用の認証データベースに登録されている当該ユーザＩＤのユーザ情報を、前記メインサーバから受信した当該ユーザＩＤのユーザ情報に更新する処理を行う、又は、前記メインサーバから受信した当該ユーザＩＤのユーザ情報を自サーバ用の認証データベースに登録する処理を行うことを特徴とするネットワークシステム。
請求項１において、
前記複数のサブサーバそれぞれとインターネットを介して接続される更新通知データベースを更に含み、
前記サブサーバが、
所定周期で、前記更新通知データベースに自サーバの識別情報に対応づけられたユーザＩＤが登録されているか否かを判断する判断部を更に含み、
前記サブサーバのデータ制御部が、
前記端末からユーザ情報の更新登録要求情報を受信した場合であって他のサブサーバと通信不能である場合に、当該他のサブサーバの識別情報に対応づけて、当該ユーザ情報に含まれるユーザＩＤを前記更新通知データベースに登録する処理を行い、
前記サブサーバの通信制御部が、
前記更新通知データベースに自サーバの識別情報に対応づけられたユーザＩＤが登録されている場合に、前記メインサーバから当該ユーザＩＤのユーザ情報を受信する処理を行い、
前記サブサーバのデータ制御部が、
前記更新通知データベースに自サーバの識別情報に対応づけられたユーザＩＤが登録されている場合に、自サーバ用の認証データベースに登録されているユーザ情報を、前記メインサーバから受信した当該ユーザＩＤのユーザ情報に更新する処理を行う、又は、前記メインサーバから受信した当該ユーザＩＤのユーザ情報を自サーバ用の認証データベースに登録する処理を行うことを特徴とするネットワークシステム。
請求項２において、
前記サブサーバのデータ制御部が、
前記更新通知データベースに登録されている当該ユーザＩＤの更新日時が自サーバ用の認証データベースに登録されている当該ユーザＩＤの更新日時よりも新しい場合に、自サーバ用の認証データベースに登録されているユーザ情報を、前記メインサーバから受信した当該ユーザＩＤのユーザ情報に更新する処理を行うことを特徴とするネットワークシステム。