(57)【要約】【課題】  複数のサービス会社が複数のサービスを提供するビジネスにおいて、サービスを受けるクライアントがシングルサインオンにて認証と課金を行える認証システムを通して、一部のサービスをとめずにサービスを切り替える手段と、一部のサービスをとめずに認証機能を切り替える手段と、一部のサービスをとめずに課金機能を切り替える手段とを有することを特徴とする認証システムを提供する。【解決手段】  サービスを受けるユーザ１１０が、認証・課金管理会社１２０が管理する認証・課金サーバ１２１を通して、サービス提供会社１３０−１〜１３０−ｎが提供する様々なサービスにアクセスすることが可能となる認証システムを構築する。認証・課金管理会社１２０は認証・課金サーバ１２０にてクライアント端末１１１からの要求に対してユーザ認証及び課金を実施する。また、サービス状態管理サーバ１２４は、一部のサービスをとめずにサービス、認証、課金機能の切り替えを実現するために、サービス状態管理ＤＢ１２５を保持する。【選択図】  図１
2010026957.tif 000002
【特許請求の範囲】
【請求項１】
サービスを受けるクライアントに対して、
認証と課金を管理している認証サービスを通して、
複数のサービス会社が提供するサービスを提供するビジネスにおいて、
クライアントがユーザ情報を元に認証する手段と、
認証に成功したクライアントに対してサービスを提供する手段と、
クライアントに提供したサービスを元に課金する手段と、
一部のサービスをとめずにサービスを切り替える手段と、
一部のサービスをとめずに認証機能を切り替える手段と、
一部のサービスをとめずに課金機能を切り替える手段と
を有することを特徴とする認証システム。
【請求項２】
請求項１記載の認証システムにおいて、サービスに応じて認証機能および課金機能を切り替える手段を有することを特徴とする認証システム。
【請求項３】
請求項１記載の認証システムにおいて、ユーザ情報に応じて認証機能および課金機能を切り替える手段を有することを特徴とする認証システム。
【請求項４】
請求項１記載の認証システムにおいて、認証レベルに応じたサービスを提供することを特徴とする認証システム。
【請求項５】
請求項１記載の認証システムにおいて、クライアントは認証された提供サービスのみをメニュー表示する手段を有することを特徴とする認証システム。
【請求項６】
請求項１記載の認証システムにおいて、提供サービスレベルに応じてサービスをグルーピングする手段を有することを特徴とする認証システム。
【請求項７】
請求項１記載の認証システムにおいて、認証レベルに応じて認証をグルーピング（部、課、Ｇｒ単位）する手段を有することを特徴とする認証システム。
【請求項８】
請求項１記載の認証システムにおいて、サービス単位に課金のグルーピングをする手段を有することを特徴とする認証システム。
【請求項９】
請求項１記載の認証システムにおいて、複数のサービス会社が提供するサービスに対してシングルサインオンを行う手段を有することを特徴とする認証システム。
【請求項１０】
請求項１記載の認証システムにおいて、ユーザ／パスワードによるユーザ認証を行う手段を有することを特徴とする認証システム。
【請求項１１】
請求項１記載の認証システムにおいて、認証カードによるユーザ認証を行う手段を有することを特徴とする認証システム。
【請求項１２】
請求項１記載の認証システムにおいて、生態認証によるユーザ認証を行う手段を有することを特徴とする認証システム。
【請求項１３】
請求項１記載の認証システムにおいて、認証・課金対象サービスを閉塞して、一部のサービスをとめずに認証・課金機能の切り替えを行う手段を有することを特徴とする認証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電力自由化の情報遮断を提供するビジネスにて、個別認証と複合認証を共用化することを可能とする遮断制御システムに関するものである。
【背景技術】
【０００２】
従来、特開２００２−３２２１６号公報のように、複数の会社が提供する多様なサービスを低コストで運用し、サービスの利用者には複数のサービスへのログインが一度の操作で実施可能とし、複数のサービス利用に対してユーザ単位、サービス単位に課金を可能とする認証システムが公開されている。
【０００３】
【特許文献１】特開２００２−３２２１６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
特開２００２−３２２１６号公報にて公開されている認証システムに対して、他のサービスを停止せずに、一部のサービスのみ停止する手段と、サービスの停止による認証・課金機能の利用可否を切り替える手段とを有するシステムを提供することにより、よりサービスの向上を図るものである。
【課題を解決するための手段】
【０００５】
そこで、本発明では、サービスを受けるクライアントに対して、認証と課金を一括管理する認証・課金管理サーバを通して、複数のサービス会社が提供するサービスを提供するビジネスにおいて、一部のサービスをとめずにサービスの停止／停止解除を実施する。
【発明の効果】
【０００６】
本発明により、一部のサービス停止によるシステム全面停止が回避され、サービス提供者、認証・課金管理会社、ユーザそれぞれが利益を得る機会が高まる。
【０００７】
システム開発者の立場からは、認証と課金のインタフェース統一の観点と、多種のサービス、ユーザ、認証、課金の組合せに対してＤＢによる制御を行うことから、アプリケーションの開発量削減が期待できる。
【０００８】
運用者の立場からは、サービスの停止と停止解除を実行するのみで、認証及び課金機能の利用可否をリアルタイムに自動切り替えが可能となるため、複雑なユーザ、認証、課金、サービスの関連を考慮せず、簡単にサービスの切り替えが可能となりサービス停止によるリスクを低減できる。
【発明を実施するための最良の形態】
【０００９】
本発明の実施の形態について、図面を用いて説明する。
図１は、クライアント端末１１１を保持するユーザ１１０と、認証・課金サーバ１２１及び認証情報ＤＢ１２２及び課金情報ＤＢ１２３及びサービス状態管理サーバ１２４及びサービス状態管理ＤＢ１２５を保持する認証・課金管理会社１２０と、サービス提供サーバ１４０−ｎを保持するサービス提供会社１３０−ｎから構成されるシステムの概略図である。
【００１０】
図２は、本実施例における全体の処理の流れを示すフローチャートである。
サービス登録２１０においては、サービス提供会社Ａ１３０−１が認証・課金管理会社１２０とサービスＡ２１１について契約を交わし、契約が成立２１２するとサービス提供会社が提供するサービスＡが登録２１３され、その情報がサービス状態情報ＤＢ１２５に登録される。この時、サービス提供会社Ａ１３０−１と認証・課金管理会社１２０が初めて契約を交わす場合、サービス提供会社Ａ１３０−１の情報が、サービス提供会社情報ＤＢ８００に登録される。
【００１１】
ユーザ契約２２０においては、サービス提供会社１３０−１〜１３０−ｎが提供する各種サービスを利用するために、認証・課金管理会社１２０にユーザ登録２２１を行う。認証・課金管理会社１２０は、ユーザＩＤ２２２を発行し、ユーザＩＤおよび登録されたユーザ情報をユーザ情報ＤＢ３２４に格納する。
【００１２】
サービス提供２３０においては、ユーザＩＤを発行されたユーザが認証・課金管理会社１２０の提供するポータルサイトにログイン２３１すると、認証・課金管理会社１２０にてユーザ認証が行われ、認証に成功するとユーザ認証キー２３２を発行する。ユーザ認証キー２３２を発行されたユーザ１１０は、サービス提供会社１３０−１〜１３０−ｎから提供されるサービスに対してサービス要求２３３を行うと、サービス提供会社は要求されたサービス提供２３４を行う。
【００１３】
サービス費支払２４０においては、ユーザ１１０がサービス提供の対価として会費２４１を支払い、認証・課金管理会社１２０が会費２４１を受け取る。認証・課金管理会社１２０はユーザ１１０から受け取った会費からサービス提供会社１３０−１〜１３０−ｎにサービス提供代２４２を支払う。
【００１４】
図３は、クライアント端末１１１が保持するユーザ情報入力機能３１０及び認証キー保持機能３１１と、認証・課金サーバ１２１が保持するユーザ情報管理機能３２０及び認証キー発行機能３２１及び認証管理機能３２２及び課金管理機能３２３と、サービス状態管理サーバが保持するサービス状態管理機能３３０と、サービス管理端末３４０が保持するサービス状態変更機能３５０の関係を示す図である。
【００１５】
ユーザがサービス提供を受ける場合、クライアント端末１１１のユーザ情報入力機能３１０はユーザが入力した情報を認証・課金管理サーバ３２４のユーザ情報管理機能３２０に送信する。ユーザ情報管理機能３２４は、ユーザ情報入力機能３１０から受け取った情報を認証管理機能３２２に渡すとともに、当該機能を動作させる。認証管理機能３２２は、該当ユーザに対する認証処理を実行し、認証に成功した場合、認証キー発行機能３２１を動作させる。認証に失敗した場合、クライアント端末に認証失敗の結果を返す。
【００１６】
ユーザの認証が成功した場合、認証キー発行機能３２０が発行した認証キーをクライアント端末１１１の認証キー保持機能が保持し、保持した認証キーによりユーザはサービスの提供を受けることが可能となる。ユーザは求めるサービスを受けようとする際、課金管理機能３２３が実行され、サービスに対する課金機能が実行可能であれば、ユーザに対してサービス利用料を計上してユーザ情報ＤＢ３２４に記録する。また、サービス提供会社に対してはサービス提供料を計上していサービス提供会社情報ＤＢ８００に記録する。
【００１７】
また、サービス状態変更機能３５０は、サービス提供会社が提供する各種サービスについて、あるサービスを停止したり、停止を解除したい場合、サービス管理端末３４０から入力された対象のサービス情報をサービス状態管理機能に送信する。サービス状態管理機能３３０は、受け取ったサービス情報を元にサービス状態管理ＤＢ１２５の該当サービスを指定された状態（稼動中／閉塞中）に変更する。さらに、サービス状態管理機能３３０は、該当サービスに関連する認証機能及び課金機能をサービス状態管理ＤＢ１２５から取得し、認証情報ＤＢ１２２及び課金情報ＤＢ１２３の該当レコードに対し各々閉塞状態または閉塞解除の状態に更新する。
【００１８】
図４は、各ユーザのユーザＩＤ４１０、ユーザ情報４２０内の氏名４２１、住所４２１、その他４２２、提供サービス４３０内のサービスＩＤ１ ４３１、サービスＩＤ２ ４３２を横軸にとり、各ユーザＩＤ４１０−１〜ｉの氏名４２１−１〜ｉ、住所４２２−１〜ｉ、その他４２３−１〜ｉ、サービスＩＤ１ ４３１−１〜ｉ、サービスＩＤ２ ４３２−１〜ｉの情報を縦軸としたユーザ情報ＤＢ３２４の内容を表す図である。ユーザ情報ＤＢ３２４において、各ユーザは複数のサービスＩＤを保持する。
【００１９】
図５は、各認証機能の認証ＩＤ５１０、認証論理名５２０、認証物理名５３０、認証機能閉塞状態５４０を横軸にとり、各認証ＩＤ５１０−１〜ｉの認証論理名５２０−１〜ｉ、認証物理名５３０−１〜ｉ、認証機能閉塞状態５４０−１〜ｉを縦軸とした認証情報ＤＢ１２２の内容を表す図である。
【００２０】
図６は、各課金機能の課金ＩＤ６１０、課金論理名６２０、課金物理名６３０、課金機能閉塞状態６４０を横軸にとり、各課金ＩＤ６１０−１〜ｉの課金論理名６２０−１〜ｉ、課金物理名６３０−１〜ｉ、課金機能閉塞状態６４０−１〜ｉを縦軸とした課金情報ＤＢ１２３の内容を表す図である。
【００２１】
図７は、各サービスのサービスＩＤ７１０、サービス名７２０、サービスＩＤに紐付く認証ＩＤ７３０、課金ＩＤ７４０、サービス提供会社ＩＤ７５０、サービス閉塞状態７６０を横軸にとり、各サービスＩＤ７１０−１〜ｉ、サービス名７２０−１〜ｉ、認証ＩＤ７３０−１〜ｉ、課金ＩＤ７４０−１〜ｉ、サービス提供会社ＩＤ７５０−１〜ｉ、サービス閉塞状態７６０−１〜ｉを縦軸としたサービス状態情報ＤＢ１２５の内容を表す図である。
【００２２】
図８は、各サービス提供会社のサービス提供会社ＩＤ８１０、サービス提供会社情報８２０内の会社名８２１、住所８２２、ＴＥＬ８２３、その他８２４を横軸にとり、各サービス提供会社ＩＤ８１０−１〜ｉ、会社名８２１−１〜ｉ、住所８２２−１〜ｉ、ＴＥＬ８２３−１〜ｉ、その他８２４−１〜ｉを縦軸としたサービス提供会社情報ＤＢ８００の内容を表す図である。
【００２３】
次に、サービス状態管理機能３３０、認証管理機能３２２、課金管理機能３２３の処理フローにより閉塞状態について、図９〜図１１を用いて詳細を説明する。
【００２４】
図９は、サービス状態管理機能３３０にて行われる処理のフロー図である。
処理９０１では、あるサービスに対して閉塞または閉塞解除を指定されるイベント待ちを行っている。この閉塞または閉塞解除の指定は、サービス管理端末３４０のサービス状態変更機能３５０から行う。処理９０１にて、イベントを受け取った時、処理９０２にて変数Ｓに対象のサービスＩＤを代入し、そのサービスに対して閉塞状態とすることを指定された場合、変数ｈに１（閉塞中）を代入し、サービスに対して閉塞解除とすることを指定された場合、変数ｈに０（閉塞解除）を代入する。処理９０３にてサービス状態管理ＤＢ１２５からサービスＩＤ Ｓに紐付く認証ＩＤを取得し、取得した認証ＩＤを変数Ｎに代入する。
【００２５】
処理９０４にてサービス状態管理ＤＢ１２５からサービスＩＤ Ｓに紐付く課金ＩＤを取得し、取得した課金ＩＤを変数Ｋに代入する。次に、処理９０５にて変数ｈの値が１（閉塞指定）か０（閉塞解除指定）かを判定する。変数ｈが１（閉塞指定）であれば、処理９０６にて認証情報ＤＢ１２２の認証ＩＤが変数Ｎであるレコードの認証機能閉塞状態の値を１増やし、処理９０７にて課金情報ＤＢ１２３の認証ＩＤが変数Ｋであるレコードの課金機能閉塞状態の値を１増やす。変数ｈが０（閉塞解除指定）であれば、処理９０８にて認証情報ＤＢ１２２の認証ＩＤが変数Ｎであるレコードの認証機能閉塞状態の値を１減らし、処理９０７にて課金情報ＤＢ１２３の認証ＩＤが変数Ｋであるレコードの課金機能閉塞状態の値を１減らす。次に、処理９０１の前に戻り、再び閉塞／解除支持を待つ。
【００２６】
図１０は、認証管理機能３２２にて行われる処理のフロー図である。
処理１００１にてログイン要求のあったユーザＩＤを変数Ｕに代入する。次に、処理１００２にてユーザ情報ＤＢ３２４からユーザＩＤが変数Ｕに等しいレコードのサービスＩＤ１、サービスＩＤ２、…を保持している数分取得し、取得したサービスＩＤの数を変数Ｓnに代入する。次に、処理１００３にて変数ｉに０を代入する。
【００２７】
処理１００４にて変数ＳｉにユーザＵのｉ番目のサービスＩＤを代入する。処理１００５にてサービス状態管理ＤＢ１２５からサービスＩＤが変数Ｓｉに等しいレコードの認証ＩＤを取得し、取得した認証ＩＤを変数Ｎに代入する。処理１００６にて認証情報ＤＢ１２２から認証ＩＤが変数Ｎに等しいレコードの閉塞状態を取得し、取得した閉塞状態を変数ｈに代入する。
【００２８】
処理１００７にて変数ｈが０（稼動中）かどうかを判定する。変数ｈが０以外（閉塞中）の場合、処理を終了する。変数ｈが０（稼動中）の場合、処理１００８にて変数Ｎに該当する認証物理名で表される認証機能を実行する。処理１００９にて認証結果が認証成功か失敗かを判定する。認証に失敗した場合、処理を終了する。認証に成功した場合、処理１０１０にて変数ｉにｉ＋１を代入する。
【００２９】
処理１０１１にて変数ｉの値とユーザＵのサービス数Ｓｎの値を比較する。変数ｉの値がＳｎより小さければ、処理１００４の前に戻り、処理１００４以降の処理を繰り返す。変数ｉの値がＳｎ以上であれば、処理１０１２にて認証キー発行機能３２１を実行する。
【００３０】
図１１は、課金管理機能３２３にて行われる処理のフロー図である。
処理１１０１にて課金対象のユーザＩＤを変数Ｕに代入する。処理１１０２にてユーザＵが利用したサービスの数を変数Ｓnに代入する。処理１１０３にて変数ｉに０を代入する。処理１１０４にて変数ＳｉにユーザＵの利用したｉ番目のサービスＩＤを代入する。
【００３１】
処理１１０５にてサービス状態管理ＤＢ１２５からサービスＩＤが変数Ｓｉに等しいレコードの課金ＩＤを取得し、取得した課金ＩＤを変数Ｋに代入する。次に、処理１１０６にて課金情報ＤＢ１２３から課金ＩＤが変数Ｋに等しいレコードの閉塞状態を取得し、取得した閉塞状態を変数ｈに代入する。次に、処理１１０７にて変数ｈが０（稼動中）かどうかを判定する。変数ｈが０以外（閉塞中）の場合、処理を終了する。変数ｈが０（稼動中）の場合、処理１１０８にて変数Ｋに該当する課金物理名で表される課金機能を実行する。処理１１０９にて変数ｉにｉ＋１を代入する。処理１１１０にて変数ｉの値とユーザＵのサービス数Ｓｎの値を比較する。変数ｉの値がＳｎより小さければ、処理１１０４の前に戻り、処理１１０４以降の処理を繰り返す。変数ｉの値がＳｎ以上であれば、処理を終了する。
【図面の簡単な説明】
【００３２】
【図１】システムの概略図
【図２】サービスフロー
【図３】システムの機能図
【図４】認証・課金管理会社が保持するユーザ情報ＤＢの内容
【図５】認証・課金管理会社が保持する認証情報ＤＢの内容
【図６】認証・課金管理会社が保持する課金情報ＤＢの内容
【図７】認証・課金管理会社が保持するサービス状態情報ＤＢの内容
【図８】認証・課金管理会社が保持するサービス提供会社情報ＤＢの内容
【図９】サービス状態管理機能の処理フロー図
【図１０】認証管理機能の処理フロー図
【図１１】課金管理機能の処理フロー図
【符号の説明】
【００３３】
１１０：ユーザ
１１１：クライアント端末
１２０：認証・課金管理会社
１２１：認証・課金サーバ
１２２：認証情報ＤＢ
１２３：課金情報ＤＢ
１２４：サービス状態管理サーバ
１２５：サービス状態管理ＤＢ
１３０−１、１３０−２、…：サービス提供会社
１４０−１、１４０−２、…：サービス提供サーバ
【図１】
2010026957.tif 000003
【図２】
2010026957.tif 000004
【図３】
2010026957.tif 000005
【図４】
2010026957.tif 000006
【図５】
2010026957.tif 000007
【図６】
2010026957.tif 000008
【図７】
2010026957.tif 000009
【図８】
2010026957.tif 000010
【図９】
2010026957.tif 000011
【図１０】
2010026957.tif 000012
【図１１】
2010026957.tif 000013