知財求人 - 知財ポータルサイト「IP Force」
▶ ジーエムオーグローバルサイン ピーティーイー リミテッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022116431
(43)【公開日】2022-08-10
(54)【発明の名称】ライセンス管理システム、ライセンス管理方法
(51)【国際特許分類】
G06F 21/33 20130101AFI20220803BHJP
G06F 21/10 20130101ALI20220803BHJP
【ＦＩ】
G06F21/33 350
G06F21/10 350
【審査請求】未請求
【請求項の数】6
【出願形態】ＯＬ
(21)【出願番号】P 2021012591
(22)【出願日】2021-01-29
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
(71)【出願人】
【識別番号】519010617
【氏名又は名称】ジーエムオーグローバルサイン ピーティーイー リミテッド
(74)【代理人】
【識別番号】100085660
【弁理士】
【氏名又は名称】鈴木 均
(74)【代理人】
【識別番号】100149892
【弁理士】
【氏名又は名称】小川 弥生
(74)【代理人】
【識別番号】100185672
【弁理士】
【氏名又は名称】池田 雅人
(72)【発明者】
【氏名】杉本 浩一
(72)【発明者】
【氏名】山田 匡志
(57)【要約】
【課題】サービスに関するライセンス管理の負担を低減する。
【解決手段】サービスを実行するサービス実行サーバ５０と、端末装置１０に対する提供のためにサービスの実行を要求するサービス提供サーバ４０と、サービスの提供に係るライセンス情報を管理するライセンス管理部３０と、を備え、サービス提供サーバ４０は、ライセンス管理部３０が管理するライセンス情報を含むアクセストークンをサービス実行サーバ５０に提示することにより、サービスの実行を要求し、サービス実行サーバ５０は、アクセストークンを提示してサービスの提供を要求したサービス提供サーバ４０に対してサービスを提供する。
【選択図】図７
【解決手段】サービスを実行するサービス実行サーバ５０と、端末装置１０に対する提供のためにサービスの実行を要求するサービス提供サーバ４０と、サービスの提供に係るライセンス情報を管理するライセンス管理部３０と、を備え、サービス提供サーバ４０は、ライセンス管理部３０が管理するライセンス情報を含むアクセストークンをサービス実行サーバ５０に提示することにより、サービスの実行を要求し、サービス実行サーバ５０は、アクセストークンを提示してサービスの提供を要求したサービス提供サーバ４０に対してサービスを提供する。
【選択図】図７
【特許請求の範囲】
【請求項1】
サービスの提供を行うサービス提供部と、
前記サービスの提供を要求するサービス要求部と、
前記サービスの提供に係るライセンスを管理するライセンス管理部と、
を備え、
前記サービス要求部は、ライセンスと関連するアクセストークンを前記サービス提供部に提示することにより、前記サービスの提供を要求し、
前記サービス提供部は、前記アクセストークンを提示して前記サービスの提供を要求した前記サービス要求部に対して、前記サービスを提供する、
ことを特徴とするライセンス管理システム。
前記サービスの提供を要求するサービス要求部と、
前記サービスの提供に係るライセンスを管理するライセンス管理部と、
を備え、
前記サービス要求部は、ライセンスと関連するアクセストークンを前記サービス提供部に提示することにより、前記サービスの提供を要求し、
前記サービス提供部は、前記アクセストークンを提示して前記サービスの提供を要求した前記サービス要求部に対して、前記サービスを提供する、
ことを特徴とするライセンス管理システム。
【請求項2】
前記サービスは、タイムスタンプの提供に関するサービスであり、
前記サービス提供部は、前記アクセストークンを提示してタイムスタンプの提供を要求した前記サービス要求部に対して前記サービスを提供する、
ことを特徴とする請求項１に記載のライセンス管理システム。
前記サービス提供部は、前記アクセストークンを提示してタイムスタンプの提供を要求した前記サービス要求部に対して前記サービスを提供する、
ことを特徴とする請求項１に記載のライセンス管理システム。
【請求項3】
前記サービスは、電子署名の提供に関するサービスであり、
前記サービス提供部は、前記アクセストークンを提示して電子署名の提供を要求した前記サービス要求部に対して前記サービスを提供する、
ことを特徴とする請求項１に記載のライセンス管理システム。
前記サービス提供部は、前記アクセストークンを提示して電子署名の提供を要求した前記サービス要求部に対して前記サービスを提供する、
ことを特徴とする請求項１に記載のライセンス管理システム。
【請求項4】
前記ライセンス管理部は、前記サービスを利用する利用者の認証情報と、前記利用者に対して登録されたライセンスと、を関連づけて管理しており、
前記利用者に対して登録されたライセンスを前記ライセンス管理部に確認し、前記アクセストークンを発行するライセンス確認部をさらに備え、
前記ライセンス確認部は、前記利用者の端末装置による認証要求に対して前記利用者の認証を行い、前記認証が成功した場合、前記利用者のライセンスに基づく前記アクセストークンを発行する、
ことを特徴とする請求項１乃至３の何れか一項に記載のライセンス管理システム。
前記利用者に対して登録されたライセンスを前記ライセンス管理部に確認し、前記アクセストークンを発行するライセンス確認部をさらに備え、
前記ライセンス確認部は、前記利用者の端末装置による認証要求に対して前記利用者の認証を行い、前記認証が成功した場合、前記利用者のライセンスに基づく前記アクセストークンを発行する、
ことを特徴とする請求項１乃至３の何れか一項に記載のライセンス管理システム。
【請求項5】
前記サービス提供部は、前記アクセストークンに応じたライセンスを、前記ライセンス管理部との間で同期して保持することを特徴とする請求項１乃至４の何れか一項に記載のライセンス管理システム。
【請求項6】
サービスの提供を行うサービス提供部と、前記サービスの提供を要求するサービス要求部と、前記サービスの提供に係るライセンスを管理するライセンス管理部と、を備えるライセンス管理システムのライセンス管理方法であって、
前記サービス要求部が、ライセンスと関連するアクセストークンを前記サービス提供部に提示することにより、前記サービスの提供を要求するステップと、
前記サービス提供部が、前記アクセストークンを提示して前記サービスの提供を要求した前記サービス要求部に対して、前記サービスを提供するステップと、
を含むことを特徴とするライセンス管理方法。
前記サービス要求部が、ライセンスと関連するアクセストークンを前記サービス提供部に提示することにより、前記サービスの提供を要求するステップと、
前記サービス提供部が、前記アクセストークンを提示して前記サービスの提供を要求した前記サービス要求部に対して、前記サービスを提供するステップと、
を含むことを特徴とするライセンス管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ライセンス管理システム、ライセンス管理方法に係り、特に、一般的なサービスにて使用される、ライセンス管理を目的としたアクセストークンの使用に関する。
【背景技術】
【0002】
近年、世界的にインターネットが普及し、インターネット上で様々なサービスが展開されている。インターネット上のサービスは、無料で利用可能なもの、有料のもの、様々であるが、特に有料サービスにおいては、サービス利用ユーザに対し、ライセンス登録を前提とし、サービスを受けるためには、事前に登録した、ライセンスを提示することを要求するシステムが多く存在する。ライセンスの提示やチェックの方法は様々で、一般的には、サービスを提供するベンダーが独自のＡＰＩを提供し、サービスを受けるクライアントはベンダーの提供する独自のＡＰＩを実装しなければならない。
一方で、インターネット上で利用される認証・認可の仕組みは、ＩＤ／パスワードによる基本認証や、ＨＴＴＰＳによるクライアント認証など、従来より標準化されているものも多く、独自のＡＰＩを実装しなくても利用可能なサービスが多く存在する。さらに、最近のテクノロジーとして、認証・認可をシステム連携する仕組みも普及してきており、特に、ＨＴＴＰプロトコル上で簡易に実現できるＯＡｕｔｈ２と呼ばれる技術も標準化されて利用されるようになってきた。
ＯＡｕｔｈ２を用いると、ユーザは、認可サーバに、ID/パスワード等の認証情報を提供することになる。サービスプロバイダは、ユーザに対し、個々の認証情報を要求する必要はなく、認可サーバから与えられた情報に基づいて、保護されたリソースへのアクセスができるようになる。
すなわち、ＯＡｕｔｈ２では、保護されたリソースへのアクセス制御に対する認証・認可を認可サーバに委ね、認可サーバから提供された認可済み情報を元に作成されたトークン（アクセストークンと呼ぶ）を提示することによって、サービスプロバイダは保護されたリソースにアクセスできる。
このように、ＯＡｕｔｈ２は認証済み情報を元に作成されたトークンをシステム間で連携することによりＳＳＯ（シングルサインオン）を実現する（特許文献１参照）。
先に述べたように、一般的にはライセンス管理はサービスプロバイダごとに提供される。認証後、アプリケーションレベルでのライセンス管理する、という実装が主である。
ライセンスとはサービスを使用するうえで必要な概念であり、ライセンスを提示することによりサービスプロバイダはサービスを提供することが可能になる。
一方で、インターネット上で利用される認証・認可の仕組みは、ＩＤ／パスワードによる基本認証や、ＨＴＴＰＳによるクライアント認証など、従来より標準化されているものも多く、独自のＡＰＩを実装しなくても利用可能なサービスが多く存在する。さらに、最近のテクノロジーとして、認証・認可をシステム連携する仕組みも普及してきており、特に、ＨＴＴＰプロトコル上で簡易に実現できるＯＡｕｔｈ２と呼ばれる技術も標準化されて利用されるようになってきた。
ＯＡｕｔｈ２を用いると、ユーザは、認可サーバに、ID/パスワード等の認証情報を提供することになる。サービスプロバイダは、ユーザに対し、個々の認証情報を要求する必要はなく、認可サーバから与えられた情報に基づいて、保護されたリソースへのアクセスができるようになる。
すなわち、ＯＡｕｔｈ２では、保護されたリソースへのアクセス制御に対する認証・認可を認可サーバに委ね、認可サーバから提供された認可済み情報を元に作成されたトークン（アクセストークンと呼ぶ）を提示することによって、サービスプロバイダは保護されたリソースにアクセスできる。
このように、ＯＡｕｔｈ２は認証済み情報を元に作成されたトークンをシステム間で連携することによりＳＳＯ（シングルサインオン）を実現する（特許文献１参照）。
先に述べたように、一般的にはライセンス管理はサービスプロバイダごとに提供される。認証後、アプリケーションレベルでのライセンス管理する、という実装が主である。
ライセンスとはサービスを使用するうえで必要な概念であり、ライセンスを提示することによりサービスプロバイダはサービスを提供することが可能になる。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１７－２２８０５９公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、ライセンスはサービスプロバイダのシステムと密になっており、例えば外部のアプライアンスを用いた場合などは、既存のライセンス管理の仕組みとアプライアンスの仕様により、連携がうまくとれず管理が煩雑になるという問題がある。
本来しかるべきプロトコルやＡＰＩ（アプリケーション・プログラミング・インターフェース）の仕様を阻害するような実装、または開発者、利用者に負荷をかけるといったサービスが多々あるのが現状である。
本発明は上記の問題点を解決するために発明されたものであり、アクセストークンを用いてラインセンス管理を行うことにより、利用者や開発者の負担の軽減及びライセンス管理の煩雑さを解決すること目的とする
本来しかるべきプロトコルやＡＰＩ（アプリケーション・プログラミング・インターフェース）の仕様を阻害するような実装、または開発者、利用者に負荷をかけるといったサービスが多々あるのが現状である。
本発明は上記の問題点を解決するために発明されたものであり、アクセストークンを用いてラインセンス管理を行うことにより、利用者や開発者の負担の軽減及びライセンス管理の煩雑さを解決すること目的とする
【課題を解決するための手段】
【0005】
上記の課題を解決するために、本発明は、サービスの提供を行うサービス提供部と、前記サービスの提供を要求するサービス要求部と、前記サービスの提供に係るライセンスを管理するライセンス管理部と、を備え、前記サービス要求部は、ライセンスと関連するアクセストークンを前記サービス提供部に提示することにより、前記サービスの提供を要求し、前記サービス提供部は、前記アクセストークンを提示して前記サービスの提供を要求した前記サービス要求部に対して、前記サービスを提供する、ライセンス管理システムを特徴とする。
【発明の効果】
【0006】
上記のように構成することにより、ライセンスに応じたサービスの提供を行うにあたりライセンス情報が連携されたアクセストークンを提示することにより、利用者、開発者の負荷を軽減可能なライセンス管理を実現することができる。
【図面の簡単な説明】
【0007】
【図1】本実施形態のシステム構成を説明する図である。
【図2】端末装置の機能構成を説明する図である。
【図3】認可サーバの機能構成を説明する図である。
【図4】ライセンス管理サーバの機能構成を説明する図である。
【図5】サービス提供サーバの機能構成を説明する図である。
【図6】サービス実行サーバの機能構成を説明する図である。
【図7】本実施形態のサービス提供処理を説明するシーケンス図である。
【図9】タイムスタンプサーバの機能構成を示す図である。
【図10】本実施形態のタイムスタンプ提供処理を説明するシーケンス図である。
【図11】タイムスタンプサービスに関するアクセストークンを示す図である。
【図12】タイムスタンプサービスに関してライセンス管理サーバが備えるライセンス管理データベースを示す図である。
【図13】電子署名サーバの機能構成を示す図である。
【図14】本実施形態の電子署名提供処理を説明するシーケンス図である。
【発明を実施するための形態】
【0008】
以下に、図面を参照して本発明の実施の形態を詳細に説明する。
本実施形態の説明に先立ち、前提技術を説明する
［ＯＡｕｔｈ２．０］
ここでは、ＲＦＣ６７４９で述べられているＯＡｕｔｈ２．０の認可グラントが認可コードである例を説明する。
ＯＡｕｔｈ２．０における認可コード処理においては、認可サーバが、クライアント、端末装置を仲介し、認可サーバが直接端末装置に対し認証を要求する。
クライアントはあらかじめｓｃｏｐｅと呼ばれる権限の範囲を認可サーバにリクエストする。端末装置と認可サーバとの間での認証が成功すると、クライアントは、権限に応じた情報をリソースサーバーから（一般的にはＡＰＩを通じて）取得することが可能になる。
なお権限については、複数の指定をすることが可能である。
本実施形態の説明に先立ち、前提技術を説明する
［ＯＡｕｔｈ２．０］
ここでは、ＲＦＣ６７４９で述べられているＯＡｕｔｈ２．０の認可グラントが認可コードである例を説明する。
ＯＡｕｔｈ２．０における認可コード処理においては、認可サーバが、クライアント、端末装置を仲介し、認可サーバが直接端末装置に対し認証を要求する。
クライアントはあらかじめｓｃｏｐｅと呼ばれる権限の範囲を認可サーバにリクエストする。端末装置と認可サーバとの間での認証が成功すると、クライアントは、権限に応じた情報をリソースサーバーから（一般的にはＡＰＩを通じて）取得することが可能になる。
なお権限については、複数の指定をすることが可能である。
【0009】
ここで必要となる情報がアクセストークンである。アクセストークンは、認可サーバより提供される認可コードを認可サーバに提示することによって得ることができる。即ち、利用者と認可サーバ間の認証が成功した際に、認可サーバより認可コードが与えられ、クライアントは認可コードを認可サーバに提供することによって、アクセストークンを得る。
クライアントにはクライアントタイプという定義が存在し、クライアントタイプにはコンフィデンシャルとパブリックがある。
クライアントタイプがコンフィデンシャルの場合には、クライアントが認可コードを認可サーバに送信する際にシークレット情報が用いられ、クライアントタイプがパブリックの場合よりもセキュアである。しかしＪａｖａｓｃｒｉｐｔなど、フロントエンドのみで完結する場合には、パブリックのクライアントタイプが用いられることが多い。
クライアントにはクライアントタイプという定義が存在し、クライアントタイプにはコンフィデンシャルとパブリックがある。
クライアントタイプがコンフィデンシャルの場合には、クライアントが認可コードを認可サーバに送信する際にシークレット情報が用いられ、クライアントタイプがパブリックの場合よりもセキュアである。しかしＪａｖａｓｃｒｉｐｔなど、フロントエンドのみで完結する場合には、パブリックのクライアントタイプが用いられることが多い。
【0010】
ＯＡｕｔｈ２．０は通常、利用者の特定情報をアクセストークンに保持しシステム連携を図るものだが、アクセストークンの検証自体には複数の方法が用いられる。
例として挙げられるのがＲＦＣ７５１９にて規定されているＪＷＴという方法である。ＲＦＣ７５１９にはＲＦＣ７５１７に記載のあるＪＷＫ、ＲＦＣ７５１５のＪＷＳ、とＲＦＣ７５１６ＪＷＥという方法も記載され、デジタル署名、ＭＡＣ計算を使用、エンコーディングを暗号化などの違いが存在する。
例として挙げられるのがＲＦＣ７５１９にて規定されているＪＷＴという方法である。ＲＦＣ７５１９にはＲＦＣ７５１７に記載のあるＪＷＫ、ＲＦＣ７５１５のＪＷＳ、とＲＦＣ７５１６ＪＷＥという方法も記載され、デジタル署名、ＭＡＣ計算を使用、エンコーディングを暗号化などの違いが存在する。
【0011】
［ライセンス管理サーバ］
ライセンス管理サーバは、顧客ごとにどの商材の何の項目がいくつあるかというデータの保持、更新などを行い、決済と結びつけるために存在する。ここでは便宜的にライセンス管理サーバとしているが、多数の別の呼称があるためここでは割愛する。
ライセンス管理サーバは一般的なサービスにおいて企業ごとに独自の形態が存在しており、サービス間の連携の際には都度特別なインターフェースを要求することが多い。また外部システムとの連携の際には特にデータのフォーマットの違いなどにより連携をしづらいものである。
本実施形態のシステムでは、ＯＡｕｔｈ２．０を使用したアクセストークンとライセンス管理サーバが提供するライセンスデータとを紐づけることにより、ライセンス情報の相互運用性を向上し、利用者、開発者の負担を軽減することが出来る。
ライセンス管理サーバは、顧客ごとにどの商材の何の項目がいくつあるかというデータの保持、更新などを行い、決済と結びつけるために存在する。ここでは便宜的にライセンス管理サーバとしているが、多数の別の呼称があるためここでは割愛する。
ライセンス管理サーバは一般的なサービスにおいて企業ごとに独自の形態が存在しており、サービス間の連携の際には都度特別なインターフェースを要求することが多い。また外部システムとの連携の際には特にデータのフォーマットの違いなどにより連携をしづらいものである。
本実施形態のシステムでは、ＯＡｕｔｈ２．０を使用したアクセストークンとライセンス管理サーバが提供するライセンスデータとを紐づけることにより、ライセンス情報の相互運用性を向上し、利用者、開発者の負担を軽減することが出来る。
【0012】
以下に本実施形態を詳細に説明する。
図１は、本実施形態のシステム構成を説明する図である。
図１に示すように、本実施形態のシステム１は、端末装置１０と、認可サーバ２０と、ライセンス管理サーバ３０と、サービス提供サーバ４０と、サービス実行サーバ５０と、を備えている。
端末装置１０は、タイムスタンプや電子署名などのサービスを利用する利用者が用いる一般的なＰＣやスマートフォンである。
サービス提供サーバ４０は、上記に説明したＯＡｕｔｈ２．０のクライアントに該当し、サービス実行サーバ５０からサービスの提供をうける端末装置１０が最初にアクセスするフロントエンドとなる。端末装置１０は、後述するサービス実行サーバ５０によるタイムスタンプや電子署名などのサービスを、サービス実行サーバ５０ではなくサービス提供サーバ４０に対して要求する。
図１は、本実施形態のシステム構成を説明する図である。
図１に示すように、本実施形態のシステム１は、端末装置１０と、認可サーバ２０と、ライセンス管理サーバ３０と、サービス提供サーバ４０と、サービス実行サーバ５０と、を備えている。
端末装置１０は、タイムスタンプや電子署名などのサービスを利用する利用者が用いる一般的なＰＣやスマートフォンである。
サービス提供サーバ４０は、上記に説明したＯＡｕｔｈ２．０のクライアントに該当し、サービス実行サーバ５０からサービスの提供をうける端末装置１０が最初にアクセスするフロントエンドとなる。端末装置１０は、後述するサービス実行サーバ５０によるタイムスタンプや電子署名などのサービスを、サービス実行サーバ５０ではなくサービス提供サーバ４０に対して要求する。
【0013】
サービス実行サーバ５０は、タイムスタンプや電子署名などのサービスを実行し、サービス実行結果を、サービス提供サーバ４０に供給する。
ライセンス管理サーバ３０は、端末装置１０又はその利用者と、サービス種別や、ライセンスＩＤ、登録済ライセンス数を関連付けたライセンスデータを、ライセンス管理データベースで管理している。
認可サーバ２０は、サービス提供サーバ４０の要求を受けて端末装置１０を認証し、認証が成功したときに、認可コードを端末装置１０に供給する。端末装置１０は認可コードをサービス提供サーバ４０に提供する。サービス提供サーバ４０は端末装置１０から提供された認可コードを認可サーバ２０に送ることによって、認可サーバ２０よりアクセストークン（Access token）を得ようとする。
認可サーバ２０は、ライセンス管理サーバ３０に対してライセンス確認を行い、ライセンスデータに基づいてアクセストークンを発行する。
サービス提供サーバ４０が、アクセストークンを提示してサービス実行装置５０にサービス要求を行うと、サービス実行サーバ５０は、提示されたアクセストークンに応じてサービスを実行し、サービス実行結果をサービス提供サーバ４０に返却するとともに、ライセンスサーバに対して、ライセンス情報を更新する。
ライセンス管理サーバ３０は、端末装置１０又はその利用者と、サービス種別や、ライセンスＩＤ、登録済ライセンス数を関連付けたライセンスデータを、ライセンス管理データベースで管理している。
認可サーバ２０は、サービス提供サーバ４０の要求を受けて端末装置１０を認証し、認証が成功したときに、認可コードを端末装置１０に供給する。端末装置１０は認可コードをサービス提供サーバ４０に提供する。サービス提供サーバ４０は端末装置１０から提供された認可コードを認可サーバ２０に送ることによって、認可サーバ２０よりアクセストークン（Access token）を得ようとする。
認可サーバ２０は、ライセンス管理サーバ３０に対してライセンス確認を行い、ライセンスデータに基づいてアクセストークンを発行する。
サービス提供サーバ４０が、アクセストークンを提示してサービス実行装置５０にサービス要求を行うと、サービス実行サーバ５０は、提示されたアクセストークンに応じてサービスを実行し、サービス実行結果をサービス提供サーバ４０に返却するとともに、ライセンスサーバに対して、ライセンス情報を更新する。
【0014】
図１では、ライセンス管理サーバ３０と認可サーバ２０とは分離した構成として説明しているが、それに限らず一つのサーバとして統合されてもよい。この場合、ライセンス管理サーバ３０が、ライセンス管理のみならず端末装置１０又はその利用者の認証及びアクセストークンの発行までを行うということである。
以下では、ライセンス管理サーバ３０と認可サーバ２０の機能を個別に説明していくが、一つのサーバとして構成される場合、ライセンス管理サーバ３０が、下記に説明する認可サーバ２０の各制御部を備え、各制御部の処理を実行するものとする。
以下では、ライセンス管理サーバ３０と認可サーバ２０の機能を個別に説明していくが、一つのサーバとして構成される場合、ライセンス管理サーバ３０が、下記に説明する認可サーバ２０の各制御部を備え、各制御部の処理を実行するものとする。
【0015】
端末装置１０と、認可サーバ２０と、ライセンス管理サーバ３０と、サービス提供サーバ４０と、サービス実行サーバ５０と、はいずれもインターネットに接続され、互いに通信可能に構成されている。
これらの装置、システム間でやり取りされるデータの類は、おもにＨＴＴＰリクエストやＨＴＴＰレスポンスのパラメータとして（ＨＴＴＰプロトコルを利用して）送受信される。ただし、セキュリティ確保が必要な部分においては、通信自体を、ＨＴＴＰＳやＶＰＮを利用するなどして保護する。
これらの装置、システム間でやり取りされるデータの類は、おもにＨＴＴＰリクエストやＨＴＴＰレスポンスのパラメータとして（ＨＴＴＰプロトコルを利用して）送受信される。ただし、セキュリティ確保が必要な部分においては、通信自体を、ＨＴＴＰＳやＶＰＮを利用するなどして保護する。
【0016】
図２は、端末装置の機能構成を説明する図であり、（ａ）はハードウェアによる機能構成を示し、（ｂ）はソフトウェアによる機能構成を示している。
図２（ａ）に示すように、端末装置１０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、端末装置１０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）１０１と、ＣＰＵ１０１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）１０２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などの記憶装置１０３や不図示のＲＯＭ（Read Only Memory）と、を備えている。
端末装置１０は、ネットワークＩ／Ｆ１０４を備え、インターネットに接続可能である。端末装置１０は、表示装置１０６を備え、各種の情報を表示する。
図２（ａ）に示すように、端末装置１０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、端末装置１０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）１０１と、ＣＰＵ１０１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）１０２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などの記憶装置１０３や不図示のＲＯＭ（Read Only Memory）と、を備えている。
端末装置１０は、ネットワークＩ／Ｆ１０４を備え、インターネットに接続可能である。端末装置１０は、表示装置１０６を備え、各種の情報を表示する。
【0017】
ＣＰＵ１０１は、端末装置１０が備えて制御部を実現する制御回路の一例であり、制御回路としては、その他にマルチコアＣＰＵ、ＦＰＧＡ（Field Programmable Gate Array）、ＰＬＤ（Programmable Logic Device）などのプロセッサを適用することが出来る。
記憶装置１０３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスク（Hard Disk）を駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
記憶装置１０３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスク（Hard Disk）を駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
【0018】
また、端末装置１０は、ＦＤ（Floppy Disk）、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disk）などの光学ディスク、フラッシュメモリなどの着脱可能な記憶媒体１０７に対してプログラムやデータを読み書きする読書装置１０５を備えてもよい。
読書装置１０５は、ＦＤＤ（Floppy Disk Drive）、ＣＤＤ（Compact Disc Drive）、ＤＶＤＤ（Digital Versatile Disc Drive）、ＢＤＤ（Blu-ray（登録商標） Disk Drive）、ＵＳＢ（Universal Serial Bus）などである。
ＣＰＵ１０１、ＲＡＭ１０２、記憶装置１０３、ネットワークＩ／Ｆ１０４、読書装置１０５は例えば内部バスを介して接続されている。
読書装置１０５は、ＦＤＤ（Floppy Disk Drive）、ＣＤＤ（Compact Disc Drive）、ＤＶＤＤ（Digital Versatile Disc Drive）、ＢＤＤ（Blu-ray（登録商標） Disk Drive）、ＵＳＢ（Universal Serial Bus）などである。
ＣＰＵ１０１、ＲＡＭ１０２、記憶装置１０３、ネットワークＩ／Ｆ１０４、読書装置１０５は例えば内部バスを介して接続されている。
【0019】
図２（ｂ）に示すように、端末装置１０は、制御部１０Ａとして、サービス要求部１１、認証部１２、サービスデータ取得部１３、ライセンス登録部１４、認証情報登録部１５と、を備える。
これらの処理部は、端末装置１０の制御部１０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１０３に含まれるハードディスクや記憶媒体１０７に格納され得る。プログラムは、記憶装置１０３や読書装置１０５によって記憶装置１０３や記憶媒体１０７からＲＡＭ１０２に読み出されてＣＰＵ１０１によって実行される。記憶装置１０３やＲＡＭ１０２は、端末装置１０の記憶部１０Ｂを構成する。
これらの処理部は、端末装置１０の制御部１０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１０３に含まれるハードディスクや記憶媒体１０７に格納され得る。プログラムは、記憶装置１０３や読書装置１０５によって記憶装置１０３や記憶媒体１０７からＲＡＭ１０２に読み出されてＣＰＵ１０１によって実行される。記憶装置１０３やＲＡＭ１０２は、端末装置１０の記憶部１０Ｂを構成する。
【0020】
サービス要求部１１は、サービス提供サーバ４０にアクセスし、サービス実行サーバ５０に対してサービス実行を要求する処理を行う。
認証部１２は、認可サーバ２０に対し、端末装置１０又はその利用者の認証を行う。
サービスデータ取得部１３は、サービス提供サーバ４０からサービスデータを取得する処理を行う。サービスデータとは、サービス実行サーバ５０で実行されたサービスの結果データ（下記に説明する、タイムスタンプや電子署名）である。
ライセンス登録部１４は、ライセンス管理サーバ３０に対してライセンス情報（サービス種別やライセンスＩＤなど）を登録する処理を行う。
認証情報登録部１５は、認可サーバ２０に対して認証情報を登録する処理を行う。
認証部１２は、認可サーバ２０に対し、端末装置１０又はその利用者の認証を行う。
サービスデータ取得部１３は、サービス提供サーバ４０からサービスデータを取得する処理を行う。サービスデータとは、サービス実行サーバ５０で実行されたサービスの結果データ（下記に説明する、タイムスタンプや電子署名）である。
ライセンス登録部１４は、ライセンス管理サーバ３０に対してライセンス情報（サービス種別やライセンスＩＤなど）を登録する処理を行う。
認証情報登録部１５は、認可サーバ２０に対して認証情報を登録する処理を行う。
【0021】
図３は、認可サーバの機能構成を説明する図であり、（ａ）はハードウェアによる機能構成を示し、（ｂ）はソフトウェアによる機能構成を示している。
図３（ａ）に示すように、認可サーバ２０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、認可サーバ２０の機能を実現するプログラムを実行するＣＰＵ１１１と、ＣＰＵ１１１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ１１２と、プログラムやデータが格納されるＨＤＤやＳＳＤなどの記憶装置１１３や不図示のＲＯＭと、を備えている。
認可サーバ２０は、ネットワークＩ／Ｆ１１４を備え、インターネットに接続可能である。認可サーバ２０は、表示装置１１６を備え、各種の情報を表示する。
図３（ａ）に示すように、認可サーバ２０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、認可サーバ２０の機能を実現するプログラムを実行するＣＰＵ１１１と、ＣＰＵ１１１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ１１２と、プログラムやデータが格納されるＨＤＤやＳＳＤなどの記憶装置１１３や不図示のＲＯＭと、を備えている。
認可サーバ２０は、ネットワークＩ／Ｆ１１４を備え、インターネットに接続可能である。認可サーバ２０は、表示装置１１６を備え、各種の情報を表示する。
【0022】
ＣＰＵ１１１は、認可サーバ２０が備えて制御部を実現する制御回路の一例であり、制御回路としては、その他にマルチコアＣＰＵ、ＦＰＧＡ、ＰＬＤなどのプロセッサを適用することが出来る。
記憶装置１１３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスクを駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
記憶装置１１３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスクを駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
【0023】
また、認可サーバ２０は、ＦＤ、ＣＤやＤＶＤ、ＢＤなどの光学ディスク、フラッシュメモリなどの着脱可能な記憶媒体１１７に対してプログラムやデータを読み書きする読書装置１１５を備えてもよい。
読書装置１１５は、ＦＤＤ、ＣＤＤ、ＤＶＤＤ、ＢＤＤ、ＵＳＢなどである。
ＣＰＵ１１１、ＲＡＭ１１２、記憶装置１１３、ネットワークＩ／Ｆ１１４、読書装置１１５は例えば内部バスを介して接続されている。
読書装置１１５は、ＦＤＤ、ＣＤＤ、ＤＶＤＤ、ＢＤＤ、ＵＳＢなどである。
ＣＰＵ１１１、ＲＡＭ１１２、記憶装置１１３、ネットワークＩ／Ｆ１１４、読書装置１１５は例えば内部バスを介して接続されている。
【0024】
図３（ｂ）に示すように、認可サーバ２０は、制御部２０Ａとして、認可要求受付部２１と、認可コード発行部２２と、トークン要求受付部２３と、トークン発行部２４、端末装置登録部２５と、を備える。
これらの処理部は、認可サーバ２０の制御部２０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１１３に含まれるハードディスクや記憶媒体１１７に格納され得る。プログラムは、記憶装置１１３や読書装置１１５によって記憶装置１１３や記憶媒体１１７からＲＡＭ１１２に読み出されてＣＰＵ１１１によって実行される。
記憶装置１１３やＲＡＭ１１２は、認可サーバ２０の記憶部２０Ｂを構成する。
これらの処理部は、認可サーバ２０の制御部２０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１１３に含まれるハードディスクや記憶媒体１１７に格納され得る。プログラムは、記憶装置１１３や読書装置１１５によって記憶装置１１３や記憶媒体１１７からＲＡＭ１１２に読み出されてＣＰＵ１１１によって実行される。
記憶装置１１３やＲＡＭ１１２は、認可サーバ２０の記憶部２０Ｂを構成する。
【0025】
認可要求受付部２１は、認証画面を端末装置１０に対して提示する処理を行う。
認可コード発行部２２は、サービス提供サーバ４０に対して（端末装置１０を経由して）認可コードを発行する処理を行う。
トークン要求受付部２３は、アクセストークン要求を受け付け、認証した端末装置１０のライセンス情報をライセンス管理サーバ３０に対して要求する処理を行う。
トークン発行部２４は、ライセンス管理サーバ３０から取得したライセンス情報を付与したアクセストークンを発行し、サービス提供サーバ４０に対して送信する処理を行う。
端末装置登録部２５は、端末装置１０から認証情報を受け付けてデータベースに登録する処理を行う。
認可コード発行部２２は、サービス提供サーバ４０に対して（端末装置１０を経由して）認可コードを発行する処理を行う。
トークン要求受付部２３は、アクセストークン要求を受け付け、認証した端末装置１０のライセンス情報をライセンス管理サーバ３０に対して要求する処理を行う。
トークン発行部２４は、ライセンス管理サーバ３０から取得したライセンス情報を付与したアクセストークンを発行し、サービス提供サーバ４０に対して送信する処理を行う。
端末装置登録部２５は、端末装置１０から認証情報を受け付けてデータベースに登録する処理を行う。
【0026】
図４は、ライセンス管理サーバの機能構成を説明する図であり、（ａ）はハードウェアによる機能構成を示し、（ｂ）はソフトウェアによる機能構成を示している。
図４（ａ）に示すように、ライセンス管理サーバ３０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、ライセンス管理サーバ３０の機能を実現するプログラムを実行するＣＰＵ１２１と、ＣＰＵ１２１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ１２２と、プログラムやデータが格納されるＨＤＤやＳＳＤなどの記憶装置１２３や不図示のＲＯＭと、を備えている。
ライセンス管理サーバ３０は、ネットワークＩ／Ｆ１２４を備え、インターネットに接続可能である。ライセンス管理サーバ３０は、表示装置１２６を備え、各種の情報を表示する。
図４（ａ）に示すように、ライセンス管理サーバ３０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、ライセンス管理サーバ３０の機能を実現するプログラムを実行するＣＰＵ１２１と、ＣＰＵ１２１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ１２２と、プログラムやデータが格納されるＨＤＤやＳＳＤなどの記憶装置１２３や不図示のＲＯＭと、を備えている。
ライセンス管理サーバ３０は、ネットワークＩ／Ｆ１２４を備え、インターネットに接続可能である。ライセンス管理サーバ３０は、表示装置１２６を備え、各種の情報を表示する。
【0027】
ＣＰＵ１２１は、ライセンス管理サーバ３０が備えて制御部を実現する制御回路の一例であり、制御回路としては、その他にマルチコアＣＰＵ、ＦＰＧＡ、ＰＬＤなどのプロセッサを適用することが出来る。
記憶装置１２３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスクを駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
記憶装置１２３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスクを駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
【0028】
また、ライセンス管理サーバ３０は、ＦＤ、ＣＤやＤＶＤ、ＢＤなどの光学ディスク、フラッシュメモリなどの着脱可能な記憶媒体１２７に対してプログラムやデータを読み書きする読書装置１２５を備えてもよい。
読書装置１２５は、ＦＤＤ、ＣＤＤ、ＤＶＤＤ、ＢＤＤ、ＵＳＢなどである。
ＣＰＵ１２１、ＲＡＭ１２２、記憶装置１２３、ネットワークＩ／Ｆ１２４、読書装置１２５は例えば内部バスを介して接続されている。
読書装置１２５は、ＦＤＤ、ＣＤＤ、ＤＶＤＤ、ＢＤＤ、ＵＳＢなどである。
ＣＰＵ１２１、ＲＡＭ１２２、記憶装置１２３、ネットワークＩ／Ｆ１２４、読書装置１２５は例えば内部バスを介して接続されている。
【0029】
図４（ｂ）に示すように、ライセンス管理サーバ３０は、制御部３０Ａとして、端末装置検索部３１と、ライセンス検索部３２と、ライセンス発行部３３と、ライセンス同期部３４と、ライセンス登録部３５と、を備える。
これらの処理部は、ライセンス管理サーバ３０の制御部３０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１２３に含まれるハードディスクや記憶媒体１２７に格納され得る。プログラムは、記憶装置１２３や読書装置１２５によって記憶装置１２３や記憶媒体１２７からＲＡＭ１２２に読み出されてＣＰＵ１２１によって実行される。記憶装置１２３やＲＡＭ１２２は、ライセンス管理サーバ３０の記憶部３０Ｂを構成する。記憶部３０Ｂは、ライセンス管理データベース８０を格納する。
これらの処理部は、ライセンス管理サーバ３０の制御部３０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１２３に含まれるハードディスクや記憶媒体１２７に格納され得る。プログラムは、記憶装置１２３や読書装置１２５によって記憶装置１２３や記憶媒体１２７からＲＡＭ１２２に読み出されてＣＰＵ１２１によって実行される。記憶装置１２３やＲＡＭ１２２は、ライセンス管理サーバ３０の記憶部３０Ｂを構成する。記憶部３０Ｂは、ライセンス管理データベース８０を格納する。
【0030】
端末装置検索部３１は、認可サーバ２０よるライセンス要求を受けてライセンス管理データベースを検索し、端末装置１０又はその利用者を特定する処理を行う。
ライセンス検索部３２は、特定された端末装置についてライセンス管理データベースを検索し、端末装置に対して登録されているライセンス情報（サービス種別やライセンスＩＤなど）を検索する処理を行う。
ライセンス発行部３３は、検索の結果特定されたライセンス情報（サービス種別やライセンスＩＤなど）を認可サーバ２０に送信する。
ライセンス同期部３４は、サービス実行サーバ５０によるライセンス同期要求を受けて、ライセンス管理データベースの更新情報をサービス実行サーバ５０に提供する（ライセンス管理データベースの内容をサービス実行サーバ５０と同期する）。
ライセンス登録部３５は、端末装置１０などからライセンス情報（サービス種別やライセンスＩＤなど）を受け付け、ライセンス管理データベースに登録する処理を行う。
ライセンス検索部３２は、特定された端末装置についてライセンス管理データベースを検索し、端末装置に対して登録されているライセンス情報（サービス種別やライセンスＩＤなど）を検索する処理を行う。
ライセンス発行部３３は、検索の結果特定されたライセンス情報（サービス種別やライセンスＩＤなど）を認可サーバ２０に送信する。
ライセンス同期部３４は、サービス実行サーバ５０によるライセンス同期要求を受けて、ライセンス管理データベースの更新情報をサービス実行サーバ５０に提供する（ライセンス管理データベースの内容をサービス実行サーバ５０と同期する）。
ライセンス登録部３５は、端末装置１０などからライセンス情報（サービス種別やライセンスＩＤなど）を受け付け、ライセンス管理データベースに登録する処理を行う。
【0031】
図５は、サービス提供サーバの機能構成を説明する図であり（ａ）はハードウェアによる機能構成を示し、（ｂ）はソフトウェアによる機能構成を示している。
図５（ａ）に示すように、サービス提供サーバ４０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、サービス提供サーバ４０の機能を実現するプログラムを実行するＣＰＵ１３１と、ＣＰＵ１３１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ１３２と、プログラムやデータが格納されるＨＤＤやＳＳＤなどの記憶装置１３３や不図示のＲＯＭと、を備えている。
サービス提供サーバ４０は、ネットワークＩ／Ｆ１３４を備え、インターネットに接続可能である。サービス提供サーバ４０は、表示装置１３６を備え、各種の情報を表示する。
図５（ａ）に示すように、サービス提供サーバ４０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、サービス提供サーバ４０の機能を実現するプログラムを実行するＣＰＵ１３１と、ＣＰＵ１３１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ１３２と、プログラムやデータが格納されるＨＤＤやＳＳＤなどの記憶装置１３３や不図示のＲＯＭと、を備えている。
サービス提供サーバ４０は、ネットワークＩ／Ｆ１３４を備え、インターネットに接続可能である。サービス提供サーバ４０は、表示装置１３６を備え、各種の情報を表示する。
【0032】
ＣＰＵ１３１は、サービス提供サーバ４０が備えて制御部を実現する制御回路の一例であり、制御回路としては、その他にマルチコアＣＰＵ、ＦＰＧＡ、ＰＬＤなどのプロセッサを適用することが出来る。
記憶装置１３３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスクを駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
記憶装置１３３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスクを駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
【0033】
また、サービス提供サーバ４０は、ＦＤ、ＣＤやＤＶＤ、ＢＤ）などの光学ディスク、フラッシュメモリなどの着脱可能な記憶媒体１３７に対してプログラムやデータを読み書きする読書装置１３５を備えてもよい。
読書装置１３５は、ＦＤＤ、ＣＤＤ、ＤＶＤＤ、ＢＤＤ、ＵＳＢなどである。
ＣＰＵ１３１、ＲＡＭ１３２、記憶装置１３３、ネットワークＩ／Ｆ１３４、読書装置１３５は例えば内部バスを介して接続されている。
図５（ｂ）に示すように、サービス提供サーバ４０は、制御部４０Ａとして、サービス要求受付部４１と、リダイレクト部４２と、認可コード取得部４３と、トークン要求部４４と、サービス要求部４５と、サービス応答部４６と、を備える。
これらの処理部は、サービス提供サーバ４０の制御部４０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１３３に含まれるハードディスクや記憶媒体１３７に格納され得る。プログラムは、記憶装置１３３や読書装置１３５によって記憶装置１３３や記憶媒体１３７からＲＡＭ１３２に読み出されてＣＰＵ１３１によって実行される。
記憶装置１３３やＲＡＭ１３２は、サービス提供サーバ４０の記憶部４０Ｂを構成する。
読書装置１３５は、ＦＤＤ、ＣＤＤ、ＤＶＤＤ、ＢＤＤ、ＵＳＢなどである。
ＣＰＵ１３１、ＲＡＭ１３２、記憶装置１３３、ネットワークＩ／Ｆ１３４、読書装置１３５は例えば内部バスを介して接続されている。
図５（ｂ）に示すように、サービス提供サーバ４０は、制御部４０Ａとして、サービス要求受付部４１と、リダイレクト部４２と、認可コード取得部４３と、トークン要求部４４と、サービス要求部４５と、サービス応答部４６と、を備える。
これらの処理部は、サービス提供サーバ４０の制御部４０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１３３に含まれるハードディスクや記憶媒体１３７に格納され得る。プログラムは、記憶装置１３３や読書装置１３５によって記憶装置１３３や記憶媒体１３７からＲＡＭ１３２に読み出されてＣＰＵ１３１によって実行される。
記憶装置１３３やＲＡＭ１３２は、サービス提供サーバ４０の記憶部４０Ｂを構成する。
【0034】
サービス要求受付部４１は、端末装置１０によるサービス実行サーバ５０対するサービス実行要求を受け付ける処理を行う。
リダイレクト部４２は、端末装置１０によるサービス実行要求を認可サーバ２０にリダイレクトする処理を行う。
認可コード取得部４３は、認可サーバ２０による認証が成功した場合に（端末装置１０を経由して）認可サーバ２０により発行された認可コードを取得する。
リダイレクト部４２は、端末装置１０によるサービス実行要求を認可サーバ２０にリダイレクトする処理を行う。
認可コード取得部４３は、認可サーバ２０による認証が成功した場合に（端末装置１０を経由して）認可サーバ２０により発行された認可コードを取得する。
【0035】
トークン要求部４４は、取得した認可コードに基づいて、アクセストークン要求を認可サーバ２０に送信し、認可サーバ２０からライセンス情報を含むアクセストークンを取得する処理を行う。
サービス要求部４５は、アクセストークンを用いて、サービス実行サーバ５０に対してサービス実行要求を行う。
サービス応答部４６は、サービス実行サーバ５０からサービス応答（サービス実行結果）を取得し、端末装置１０に送信する処理を行う。
サービス要求部４５は、アクセストークンを用いて、サービス実行サーバ５０に対してサービス実行要求を行う。
サービス応答部４６は、サービス実行サーバ５０からサービス応答（サービス実行結果）を取得し、端末装置１０に送信する処理を行う。
【0036】
図６は、サービス実行サーバの機能構成を説明する図であり、（ａ）はハードウェアによる機能構成を示し、（ｂ）はソフトウェアによる機能構成を示している。
図６（ａ）に示すように、サービス実行サーバ５０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、サービス実行サーバ５０の機能を実現するプログラムを実行するＣＰＵ１４１と、ＣＰＵ１４１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ１４２と、プログラムやデータが格納されるＨＤＤやＳＳＤなどの記憶装置１４３や不図示のＲＯＭと、を備えている。
サービス実行サーバ５０は、ネットワークＩ／Ｆ１４４を備え、インターネットに接続可能である。サービス実行サーバ５０は、表示装置１４６を備え、各種の情報を表示する。
図６（ａ）に示すように、サービス実行サーバ５０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、サービス実行サーバ５０の機能を実現するプログラムを実行するＣＰＵ１４１と、ＣＰＵ１４１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ１４２と、プログラムやデータが格納されるＨＤＤやＳＳＤなどの記憶装置１４３や不図示のＲＯＭと、を備えている。
サービス実行サーバ５０は、ネットワークＩ／Ｆ１４４を備え、インターネットに接続可能である。サービス実行サーバ５０は、表示装置１４６を備え、各種の情報を表示する。
【0037】
ＣＰＵ１４１は、サービス実行サーバ５０が備えて制御部を実現する制御回路の一例であり、制御回路としては、その他にマルチコアＣＰＵ、ＦＰＧＡ、ＰＬＤなどのプロセッサを適用することが出来る。
記憶装置１４３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスクを駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
記憶装置１４３として代表的なものはＨＤＤである。ＨＤＤは、内蔵するハードディスクを駆動するドライブ装置であり、ＨＤＤは記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
【0038】
また、サービス実行サーバ５０は、ＦＤ、ＣＤやＤＶＤ、ＢＤなどの光学ディスク、フラッシュメモリなどの着脱可能な記憶媒体１４７に対してプログラムやデータを読み書きする読書装置１４５を備えてもよい。
読書装置１４５は、ＦＤＤ、ＣＤＤ、ＤＶＤＤ、ＢＤＤ、ＵＳＢなどである。
ＣＰＵ１４１、ＲＡＭ１４２、記憶装置１４３、ネットワークＩ／Ｆ１４４、読書装置１４５は例えば内部バスを介して接続されている。
図６（ｂ）に示すように、サービス実行サーバ５０は、制御部６０Ａとして、トークン検証部５１と、サービス要求受付部５２と、サービス実行部５３と、サービス応答部５４と、ライセンス同期部５５と、を備えている。
これらの処理部は、サービス実行サーバ５０の制御部５０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１４３に含まれるハードディスクや記憶媒体１４７に格納され得る。プログラムは、記憶装置１４３や読書装置１４５によって記憶装置１４３や記憶媒体１４７からＲＡＭ１４２に読み出されてＣＰＵ１４１によって実行される。記憶装置１４３やＲＡＭ１４２は、サービス実行サーバ５０の記憶部５０Ｂを構成する。
読書装置１４５は、ＦＤＤ、ＣＤＤ、ＤＶＤＤ、ＢＤＤ、ＵＳＢなどである。
ＣＰＵ１４１、ＲＡＭ１４２、記憶装置１４３、ネットワークＩ／Ｆ１４４、読書装置１４５は例えば内部バスを介して接続されている。
図６（ｂ）に示すように、サービス実行サーバ５０は、制御部６０Ａとして、トークン検証部５１と、サービス要求受付部５２と、サービス実行部５３と、サービス応答部５４と、ライセンス同期部５５と、を備えている。
これらの処理部は、サービス実行サーバ５０の制御部５０Ａの機能を実現するプログラムであり、当該プログラムは、記憶装置１４３に含まれるハードディスクや記憶媒体１４７に格納され得る。プログラムは、記憶装置１４３や読書装置１４５によって記憶装置１４３や記憶媒体１４７からＲＡＭ１４２に読み出されてＣＰＵ１４１によって実行される。記憶装置１４３やＲＡＭ１４２は、サービス実行サーバ５０の記憶部５０Ｂを構成する。
【0039】
トークン検証部５１は、サービス提供サーバ４０から送信されたアクセストークンを検証する処理を行う。
サービス要求受付部５２は、サービス提供サーバ４０からのサービス要求を受け付け、検証する処理を行う。
サービス実行部５３は、タイムスタンプや電子署名など要求されたサービスを実際に実行する処理を行う。
サービス応答部５４は、サービス実行結果をサービス提供サーバ４０に返却する処理を行う。
ライセンス同期部５５は、ライセンス管理サーバ３０に対してライセンスデータの同期要求を行う。
サービス要求受付部５２は、サービス提供サーバ４０からのサービス要求を受け付け、検証する処理を行う。
サービス実行部５３は、タイムスタンプや電子署名など要求されたサービスを実際に実行する処理を行う。
サービス応答部５４は、サービス実行結果をサービス提供サーバ４０に返却する処理を行う。
ライセンス同期部５５は、ライセンス管理サーバ３０に対してライセンスデータの同期要求を行う。
【0040】
上記の構成を示す各装置による本実施形態の処理を概説する。
端末装置１０が、サービス要求部１１により、サービス提供サーバ４０にアクセスし、サービス実行を要求すると、サービス提供サーバ４０は、サービス要求受付部４１によりサービス要求を受け付け、リダイレクト部４２により認可サーバ２０にアクセスをリダイレクトする。
認可サーバ２０は、認可要求受付部２１により、認証画面を端末装置１０に対して提示する。
端末装置１０において、事前に認可サーバ２０に対して登録した認証情報を認証画面に入力すると、認証部１２により、認可サーバ２０に対し認証を行うことができる。
認証が成功した場合、認可サーバ２０は認可コード発行部２２により、サービス提供サーバ４０に対して（端末装置１０を経由して）認可コードを発行する。
サービス提供サーバ４０は、認可コード取得部４３により受信した認可コードを、トークン要求部４４によって認可サーバ２０に対し送信する。
事前に取得しているクライアントＩＤ及びクライアントシークレットを用いることで認証を行い、サービス提供サーバ４０は、認可サーバ２０からアクセストークンを受信することができる。
端末装置１０が、サービス要求部１１により、サービス提供サーバ４０にアクセスし、サービス実行を要求すると、サービス提供サーバ４０は、サービス要求受付部４１によりサービス要求を受け付け、リダイレクト部４２により認可サーバ２０にアクセスをリダイレクトする。
認可サーバ２０は、認可要求受付部２１により、認証画面を端末装置１０に対して提示する。
端末装置１０において、事前に認可サーバ２０に対して登録した認証情報を認証画面に入力すると、認証部１２により、認可サーバ２０に対し認証を行うことができる。
認証が成功した場合、認可サーバ２０は認可コード発行部２２により、サービス提供サーバ４０に対して（端末装置１０を経由して）認可コードを発行する。
サービス提供サーバ４０は、認可コード取得部４３により受信した認可コードを、トークン要求部４４によって認可サーバ２０に対し送信する。
事前に取得しているクライアントＩＤ及びクライアントシークレットを用いることで認証を行い、サービス提供サーバ４０は、認可サーバ２０からアクセストークンを受信することができる。
【0041】
認可サーバ２０は、アクセストークンを発行する前にトークン要求受付部２３により、ライセンス管理サーバ３０と通信を行い、認証した端末装置１０のライセンス情報をトークン発行部２４によりアクセストークンに付与する。
その際、ライセンス管理サーバ３０は、認可サーバ２０から送られてくるライセンス要求を受け、端末装置検索部３１及びライセンス検索部３２により、端末装置１０に関するライセンスデータの特定を行い、ライセンス発行部３３により、正規のライセンスを有することを示すライセンス情報（サービス種別やライセンスＩＤなど）を出力して認可サーバ２０に送信する。
認可サーバ２０は、ライセンス情報（サービス種別やライセンスＩＤなど）をアクセストークンに付与する。ライセンス情報のアクセストークンへの付与の方法は上記以外にも存在するが、例としてアクセストークン中に付与する方法として説明をしていく。
その際、ライセンス管理サーバ３０は、認可サーバ２０から送られてくるライセンス要求を受け、端末装置検索部３１及びライセンス検索部３２により、端末装置１０に関するライセンスデータの特定を行い、ライセンス発行部３３により、正規のライセンスを有することを示すライセンス情報（サービス種別やライセンスＩＤなど）を出力して認可サーバ２０に送信する。
認可サーバ２０は、ライセンス情報（サービス種別やライセンスＩＤなど）をアクセストークンに付与する。ライセンス情報のアクセストークンへの付与の方法は上記以外にも存在するが、例としてアクセストークン中に付与する方法として説明をしていく。
【0042】
サービス提供サーバ４０は、ライセンス情報（サービス種別やライセンスＩＤなど）を含むアクセストークンを認可サーバ２０より受け、受信したアクセストークンを用いて、サービス要求部によってサービス実行サーバ５０に対してサービス実行要求を行う。
サービス実行サーバ５０はＯＡｕｔｈ２．０のリソースサーバーという位置づけであり、アクセストークンの検証を行わなければならない。
サービス実行サーバ５０はＯＡｕｔｈ２．０のリソースサーバーという位置づけであり、アクセストークンの検証を行わなければならない。
【0043】
一般的にアクセストークンの検証において用いられる手法としては公開鍵認証方式がとられるケースが多い。
事前に認可サーバ２０にて秘密鍵と公開鍵のペアの生成を行いサービス実行サーバ５０は公開鍵を保持し、ハッシュ値の計算と暗号化処理を行うことで安全なアクセストークンであることを証明することができる。この処理はトークン検証部５１により実行される。
アクセストークンに使用される認証方式には複数あるが、ここでは公開鍵認証のみの説明とする。
事前に認可サーバ２０にて秘密鍵と公開鍵のペアの生成を行いサービス実行サーバ５０は公開鍵を保持し、ハッシュ値の計算と暗号化処理を行うことで安全なアクセストークンであることを証明することができる。この処理はトークン検証部５１により実行される。
アクセストークンに使用される認証方式には複数あるが、ここでは公開鍵認証のみの説明とする。
【0044】
公開鍵認証にてアクセストークンの検証に成功したサービス実行サーバ５０は、アクセストークンに含まれるライセンス情報（サービス種別やライセンスＩＤなど）の確認を行う。
ライセンス管理サーバ３０とサービス実行サーバ５０との間の同期処理により、事前に登録している範囲にて、ライセンスの種類、属性が共有されている。サービス実行サーバ５０は、端末装置１０のライセンス情報をデータベースまたはストレージ、テンポラリ領域に一時的に保管をしている。
事前に付与されているライセンスデータを元に、サービス実行サーバ５０は、サービス実行部５３によりアクセストークンの範囲でサービスを実行し、実行結果をサービス応答部５４によりサービス提供サーバ４０へ返却する。
ライセンス管理サーバ３０とサービス実行サーバ５０との間の同期処理により、事前に登録している範囲にて、ライセンスの種類、属性が共有されている。サービス実行サーバ５０は、端末装置１０のライセンス情報をデータベースまたはストレージ、テンポラリ領域に一時的に保管をしている。
事前に付与されているライセンスデータを元に、サービス実行サーバ５０は、サービス実行部５３によりアクセストークンの範囲でサービスを実行し、実行結果をサービス応答部５４によりサービス提供サーバ４０へ返却する。
【0045】
サービス実行サーバ５０より戻り値（実行結果）を受信したサービス提供サーバ４０は、サービス応答部４６により、データの加工、処理等を行い、最終結果を端末装置１０に返却する。
端末装置１０はサービスデータ取得部１３により、サービス提供サーバ４０からサービスデータを取得する処理を行い、ライセンス管理がされたサービス提供の一連の流れが完結する。
端末装置１０はサービスデータ取得部１３により、サービス提供サーバ４０からサービスデータを取得する処理を行い、ライセンス管理がされたサービス提供の一連の流れが完結する。
【0046】
ライセンス情報は、基本的にはサービス実行サーバ５０とライセンス管理サーバ３０との間で分離しているので、サービス実行サーバ５０とライセンス管理サーバ３０との間で、別途、定期的なライセンスデータの同期処理を行うことでライセンスデータの整合性を担保する必要がある。
サービス実行サーバ５０は、ライセンス管理サーバ３０に定期的にライセンスデータの同期を要求し、ライセンス管理サーバ３０がライセンス管理データベースで管理するライセンスデータ（サービス種別やライセンスＩＤなど）を提供される。
ライセンス管理サーバ３０は、ライセンス登録時にサービス実行サーバ５０から同期要求があると、正しいライセンスデータ（サービス種別やライセンスＩＤなど）がサービス実行サーバ５０にいかない場合があるので、同期中にはライセンス登録を受け付けないか、ライセンス登録中には同期要求を受けないようにする（排他処理）ことが望ましい。
この処理は、サービス実行サーバ５０のライセンス同期部５５によりライセンスデータの同期要求が発行され、ライセンス管理サーバ３０のライセンス同期部３４により更新処理（ライセンス管理データベースで管理するライセンスデータの新規差分の送信など）が行われる。
サービス実行サーバ５０は、ライセンス管理サーバ３０に定期的にライセンスデータの同期を要求し、ライセンス管理サーバ３０がライセンス管理データベースで管理するライセンスデータ（サービス種別やライセンスＩＤなど）を提供される。
ライセンス管理サーバ３０は、ライセンス登録時にサービス実行サーバ５０から同期要求があると、正しいライセンスデータ（サービス種別やライセンスＩＤなど）がサービス実行サーバ５０にいかない場合があるので、同期中にはライセンス登録を受け付けないか、ライセンス登録中には同期要求を受けないようにする（排他処理）ことが望ましい。
この処理は、サービス実行サーバ５０のライセンス同期部５５によりライセンスデータの同期要求が発行され、ライセンス管理サーバ３０のライセンス同期部３４により更新処理（ライセンス管理データベースで管理するライセンスデータの新規差分の送信など）が行われる。
【0047】
図７は、本実施形態のサービス提供処理を説明するシーケンス図である。
シングルサインオンの技術において、認可サーバ２０は、認証情報を提供するIdentity Provider（ＩｄＰ）であり、サービス提供サーバ４０は、認証情報を利用するService Provider（ＳＰ）である。
ステップＳ１において、利用者が使用する端末装置１０（ウェブブラウザ）は、サービス要求のため、サービス提供サーバ４０にアクセスする。
サービス要求を受けたサービス提供サーバ４０は、ステップＳ２において、利用者を認可サーバ２０にリダイレクトするページを端末装置１０に供給する。
利用者の操作により、端末装置１０は、ステップＳ３において、認可サーバ２０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいて利用者の認証を要求するための手続である。
シングルサインオンの技術において、認可サーバ２０は、認証情報を提供するIdentity Provider（ＩｄＰ）であり、サービス提供サーバ４０は、認証情報を利用するService Provider（ＳＰ）である。
ステップＳ１において、利用者が使用する端末装置１０（ウェブブラウザ）は、サービス要求のため、サービス提供サーバ４０にアクセスする。
サービス要求を受けたサービス提供サーバ４０は、ステップＳ２において、利用者を認可サーバ２０にリダイレクトするページを端末装置１０に供給する。
利用者の操作により、端末装置１０は、ステップＳ３において、認可サーバ２０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいて利用者の認証を要求するための手続である。
【0048】
ステップＳ４の認証処理において、認可サーバ２０は、認証情報（例えば、利用者ＩＤとパスワード）の入力を利用者に要求する。なお、ステップＳ４の認証処理において、認証情報の入力はＲＦＣ６７４９（ＯＡｕｔｈ２．０）で規定される処理とは異なり、認可サーバ２０と端末装置１０との間で別途確立されるセッションにおいて行われる。
利用者の認証が正常に行われると、認可サーバ２０は、利用者の確認を得たうえで認可を確立し、ステップＳ５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
利用者の認証が正常に行われると、認可サーバ２０は、利用者の確認を得たうえで認可を確立し、ステップＳ５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
【0049】
認可サーバ２０から送信された認可コードを受信した端末装置１０（ウェブブラウザ）は、ステップＳ６において、認可コードをサービス提供サーバ４０に転送（Redirect）する。
端末装置１０から転送された認可コードを取得したサービス提供サーバ４０は、ステップＳ７において、この認可コードを用いて、アクセストークン要求（Access token request）を認可サーバ２０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
アクセストークン要求を受け付けた認可サーバ２０は、ステップＳ８において、端末装置１０又はその利用者のＩＤ情報に基づくライセンス管理サーバ３０に対してライセンス要求を行う。
端末装置１０から転送された認可コードを取得したサービス提供サーバ４０は、ステップＳ７において、この認可コードを用いて、アクセストークン要求（Access token request）を認可サーバ２０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
アクセストークン要求を受け付けた認可サーバ２０は、ステップＳ８において、端末装置１０又はその利用者のＩＤ情報に基づくライセンス管理サーバ３０に対してライセンス要求を行う。
【0050】
ライセンス管理サーバ３０は、認可サーバ２０によるライセンス要求を受け、ステップＳ９において、ライセンス管理データベースから、端末装置１０に関するライセンスデータの特定を行うライセンス特定処理を行い、ステップＳ１０において、特定したライセンスデータに基づくライセンス情報を認可サーバ２０に送信する。
ステップＳ１１において、認可サーバ２０は、ライセンス情報を含むアクセストークン応答（Access token response）をサービス提供サーバ４０に返す。すなわち、認可サーバ２０は、ライセンスを含むアクセストークンをサービス提供サーバ４０に送信する（ＲＦＣ６７４９＃４．１．４．）。
ステップＳ１１において、認可サーバ２０は、ライセンス情報を含むアクセストークン応答（Access token response）をサービス提供サーバ４０に返す。すなわち、認可サーバ２０は、ライセンスを含むアクセストークンをサービス提供サーバ４０に送信する（ＲＦＣ６７４９＃４．１．４．）。
【0051】
認可サーバ２０からアクセストークンを取得したサービス提供サーバ４０は、ステップＳ１２において、サービス実行サーバ５０に対してアクセストークンを送信してサービス要求を行う。
サービス要求を受けたサービス実行サーバ５０は、アクセストークン内のライセンス情報に基づき、ステップＳ１３にてサービス実行処理を行い、ステップＳ１４にてサービス提供サーバ４０に対してサービス応答を行う。
サービス実行サーバ５０は、ステップＳ１５においてライセンス同期要求をライセンス管理サーバ３０に送信し、ステップＳ１６において、ライセンス管理サーバ３０からの同期結果の送信を受ける。
サービス実行サーバによるライセンス同期処理（ステップＳ１５～Ｓ１６）は、サービス実行処理とは別に、定期的に、または、非定期的に、非同期に行われてもよい。
サービス要求を受けたサービス実行サーバ５０は、アクセストークン内のライセンス情報に基づき、ステップＳ１３にてサービス実行処理を行い、ステップＳ１４にてサービス提供サーバ４０に対してサービス応答を行う。
サービス実行サーバ５０は、ステップＳ１５においてライセンス同期要求をライセンス管理サーバ３０に送信し、ステップＳ１６において、ライセンス管理サーバ３０からの同期結果の送信を受ける。
サービス実行サーバによるライセンス同期処理（ステップＳ１５～Ｓ１６）は、サービス実行処理とは別に、定期的に、または、非定期的に、非同期に行われてもよい。
【0052】
図８は、図７の処理に先立って行われる装置間の事前登録処理を説明する図である。
図８（ａ）は、端末装置が、認可サーバ、ライセンス管理サーバに対して行う事前登録処理を説明する図である。
図７で説明した処理に先立って、端末装置１０は、図８（ａ）に示すように、認可サーバ２０に対して認証情報（例えば、ＩＤ情報、パスワード）の登録処理を行うとともに、ライセンス管理サーバ３０に対して、ＩＤ情報とライセンスデータ（サービス種別やライセンスＩＤなど）の登録処理を行う。
認証情報の事前登録処理は、端末装置１０の認証情報登録部１５及び認可サーバ２０の端末装置登録部２５により行われる。
認可サーバ２０は、端末装置１０のＩＤ情報とパスワードを保持する。
ライセンス情報の事前登録処理は、端末装置１０のライセンス登録部１４及びライセンス管理サーバ３０ライセンス登録部３５により行われる。
ライセンス管理サーバ３０は、端末装置１０のＩＤ情報とライセンスデータ（サービス種別やライセンスＩＤなど）とをライセンス管理データベース８０に格納する。
ライセンス管理サーバ３０は、ライセンス管理データベース８０において、ライセンスデータとして端末装置１０又はその利用者とライセンスＩＤ、サービス種別、登録済ライセンス数（特に、後述するタイムスタンプの場合）などを関連づけて管理する。サービスの１つの例として、タイムスタンプサービスがあるが、この場合、端末装置１０又はその利用者毎に、所有するライセンス数、つまり、タイムスタンプを発行できる数を管理する。
図８（ａ）は、端末装置が、認可サーバ、ライセンス管理サーバに対して行う事前登録処理を説明する図である。
図７で説明した処理に先立って、端末装置１０は、図８（ａ）に示すように、認可サーバ２０に対して認証情報（例えば、ＩＤ情報、パスワード）の登録処理を行うとともに、ライセンス管理サーバ３０に対して、ＩＤ情報とライセンスデータ（サービス種別やライセンスＩＤなど）の登録処理を行う。
認証情報の事前登録処理は、端末装置１０の認証情報登録部１５及び認可サーバ２０の端末装置登録部２５により行われる。
認可サーバ２０は、端末装置１０のＩＤ情報とパスワードを保持する。
ライセンス情報の事前登録処理は、端末装置１０のライセンス登録部１４及びライセンス管理サーバ３０ライセンス登録部３５により行われる。
ライセンス管理サーバ３０は、端末装置１０のＩＤ情報とライセンスデータ（サービス種別やライセンスＩＤなど）とをライセンス管理データベース８０に格納する。
ライセンス管理サーバ３０は、ライセンス管理データベース８０において、ライセンスデータとして端末装置１０又はその利用者とライセンスＩＤ、サービス種別、登録済ライセンス数（特に、後述するタイムスタンプの場合）などを関連づけて管理する。サービスの１つの例として、タイムスタンプサービスがあるが、この場合、端末装置１０又はその利用者毎に、所有するライセンス数、つまり、タイムスタンプを発行できる数を管理する。
【0053】
図８（ａ）の事前登録処理を行うことにより、サービス提供サーバ４０が端末装置１０の認証情報を管理する必要がなく、またライセンス情報の管理を行う必要性もない。その結果、システム的に疎結合の状態を作り出すことができる。
また、認可サーバ２０は、アクセストークンの定義情報を、事前にサービス実行サーバ５０に対して提供する。これにより、アクセストークン中の情報をサービス実行サーバ５０が受け付けることが可能となる。
また、認可サーバ２０は、アクセストークンの定義情報を、事前にサービス実行サーバ５０に対して提供する。これにより、アクセストークン中の情報をサービス実行サーバ５０が受け付けることが可能となる。
【0054】
図８（ｂ）は、認可サーバとサービス提供サーバとの間で行う事前登録処理を説明する図である。
上記したコンフィデンシャルの方法を採用する場合、サービス提供サーバ４０は、図８（ｂ）に示すように、認可サーバ２０との合意の上で、リダイレクト用のＵＲＩを認可サーバ２０事前に提供し、クライアントＩＤとクライアントシークレットを認可サーバ２０から受信する必要性がある。
認可サーバ２０への認可コードの取得リクエストの際にはクライアントＩＤが求められるケースが多く、認可コードを認可サーバ２０に送信し、アクセストークンをリクエストする際の認証情報としてクライアントＩＤ及びクライアントシークレットは使用され、より高レベルのセキュリティを確保することが可能である。
図８で説明した処理により、ＯＡｕｔｈ２．０のアクセストークンとライセンスとの紐づけの準備が完了した。
以下に、サービス実行サーバ５０で、タイムスタンプや電子署名など、具体的なサービスを実行・提供する場合の処理を具体的に説明していく。
下記の説明において、タイムスタンプを提供するサービス実行サーバ５０をタイムスタンプサーバ５０ａとし、電子署名を提供するサービス実行サーバ５０を電子署名サーバ５０ｂとして説明する。端末装置、認可サーバ、ライセンス管理サーバ、サービス提供サーバについては、上記と同じ符号（端末装置１０、認可コード２０、ライセンス管理サーバ３０、サービス提供サーバ４０）を付して説明する。
上記したコンフィデンシャルの方法を採用する場合、サービス提供サーバ４０は、図８（ｂ）に示すように、認可サーバ２０との合意の上で、リダイレクト用のＵＲＩを認可サーバ２０事前に提供し、クライアントＩＤとクライアントシークレットを認可サーバ２０から受信する必要性がある。
認可サーバ２０への認可コードの取得リクエストの際にはクライアントＩＤが求められるケースが多く、認可コードを認可サーバ２０に送信し、アクセストークンをリクエストする際の認証情報としてクライアントＩＤ及びクライアントシークレットは使用され、より高レベルのセキュリティを確保することが可能である。
図８で説明した処理により、ＯＡｕｔｈ２．０のアクセストークンとライセンスとの紐づけの準備が完了した。
以下に、サービス実行サーバ５０で、タイムスタンプや電子署名など、具体的なサービスを実行・提供する場合の処理を具体的に説明していく。
下記の説明において、タイムスタンプを提供するサービス実行サーバ５０をタイムスタンプサーバ５０ａとし、電子署名を提供するサービス実行サーバ５０を電子署名サーバ５０ｂとして説明する。端末装置、認可サーバ、ライセンス管理サーバ、サービス提供サーバについては、上記と同じ符号（端末装置１０、認可コード２０、ライセンス管理サーバ３０、サービス提供サーバ４０）を付して説明する。
【0055】
［サービス実行サーバがタイムスタンプサービスを提供する場合］
本実施形態のサービス実行サーバ５０は、タイムスタンプを発行するタイムスタンプサーバ５０ａとして機能しうる。
この場合、アクセストークンを用いたライセンス管理は、基本的に上記に説明したとおりである。ただし、サービス要求（タイムスタンプ要求）のフォーマットはＲＦＣ３１６１に則り、またそれに対する応答（タイムスタンプレスポンス）も同様に、ＲＦＣ３１６１を満たす必要性がある。
本実施形態のサービス実行サーバ５０は、タイムスタンプを発行するタイムスタンプサーバ５０ａとして機能しうる。
この場合、アクセストークンを用いたライセンス管理は、基本的に上記に説明したとおりである。ただし、サービス要求（タイムスタンプ要求）のフォーマットはＲＦＣ３１６１に則り、またそれに対する応答（タイムスタンプレスポンス）も同様に、ＲＦＣ３１６１を満たす必要性がある。
【0056】
図９は、タイムスタンプサーバの機能構成を示す図である。
ハードウェア構成は、図６のサービス実行サーバ５０と同じであり、タイムスタンプサーバの制御部の構成のみを説明する。
図９に示すように、タイムスタンプサーバ５０ａとしてのサービス実行サーバは、トークン検証部５１Ａと、タイムスタンプ要求受付部５２Ａと、タイムスタンプ生成部５３Ａと、タイムスタンプ返却部５４Ａと、ライセンス同期部５５Ａと、を備えている。
トークン検証部５１Ａは、トークン検証部５１に対応し、サービス提供サーバ４０から送信されたアクセストークンを検証する処理を行う。
タイムスタンプ要求受付部５２Ａは、サービス要求受付部５２に対応し、サービス提供サーバ４０からのタイムスタンプ要求を受け付ける処理を行う。
タイムスタンプ生成部５３Ａは、サービス実行部５３に対応し、要求されタイムスタンプの生成を実際に実行する処理を行う。
タイムスタンプ返却部５４Ａは、サービス応答部５４に対応し、生成したタイムスタンプを、サービス提供サーバ４０に返却する処理を行う。
ライセンス同期部５５Ａは、ライセンス同期部５５に対応し、ライセンス管理サーバ３０に対して、ライセンスデータの同期要求を行う。
ハードウェア構成は、図６のサービス実行サーバ５０と同じであり、タイムスタンプサーバの制御部の構成のみを説明する。
図９に示すように、タイムスタンプサーバ５０ａとしてのサービス実行サーバは、トークン検証部５１Ａと、タイムスタンプ要求受付部５２Ａと、タイムスタンプ生成部５３Ａと、タイムスタンプ返却部５４Ａと、ライセンス同期部５５Ａと、を備えている。
トークン検証部５１Ａは、トークン検証部５１に対応し、サービス提供サーバ４０から送信されたアクセストークンを検証する処理を行う。
タイムスタンプ要求受付部５２Ａは、サービス要求受付部５２に対応し、サービス提供サーバ４０からのタイムスタンプ要求を受け付ける処理を行う。
タイムスタンプ生成部５３Ａは、サービス実行部５３に対応し、要求されタイムスタンプの生成を実際に実行する処理を行う。
タイムスタンプ返却部５４Ａは、サービス応答部５４に対応し、生成したタイムスタンプを、サービス提供サーバ４０に返却する処理を行う。
ライセンス同期部５５Ａは、ライセンス同期部５５に対応し、ライセンス管理サーバ３０に対して、ライセンスデータの同期要求を行う。
【0057】
［タイムスタンプについて］
ＲＦＣ３１６１にて、リクエストフォーマット及び、レスポンスフォーマット、振る舞いが定義されているプロトコルの仕様である。また、ＲＦＣ３６２８にてタイムスタンプサービスの運用上の要求事項が定義されている。
一般的にタイムスタンプサービスは対象コンテンツがその時刻に存在していたこと、その後改ざんされていないことを証明する方法として用いられる。後述の電子署名、またコードサインの用途に用いられることが多い。
ＲＦＣ３１６１にて、リクエストフォーマット及び、レスポンスフォーマット、振る舞いが定義されているプロトコルの仕様である。また、ＲＦＣ３６２８にてタイムスタンプサービスの運用上の要求事項が定義されている。
一般的にタイムスタンプサービスは対象コンテンツがその時刻に存在していたこと、その後改ざんされていないことを証明する方法として用いられる。後述の電子署名、またコードサインの用途に用いられることが多い。
【0058】
処理の概要を説明する。
端末装置１０はサービス提供サーバ４０に対しタイムスタンプサービス要求を行う。
サービス提供サーバ４０はリダイレクトを行い、端末装置１０に認可サーバ２０の認証画面を表示する。
認証が成功すると、サービス提供サーバ４０は、認可サーバ２０より認可コードを受信し、認可コード（クライアントタイプがコンフィデンシャルの場合、併せて、クライアントＩＤ及びクライアントシークレット）を付与し、認可サーバ２０にアクセストークンのリクエストを行う。
認可サーバ２０は、ライセンス管理サーバ３０にライセンス要求を行う。
ライセンス管理サーバ３０が行う下記に詳述するライセンス特定処理の結果として、ライセンス情報（サービス種別やライセンスＩＤ、さらにはタイムスタンプの発行要求枚数など）、が発行され、ライセンス情報を含むアクセストークンがサービス提供サーバ４０に送される。
サービス提供サーバ４０は認可サーバ２０より受信した、ライセンス情報を含むアクセストークンをタイムスタンプサーバ５０ａに提示してタイムスタンプ要求を行うのである。
タイムスタンプサービスにアクセスする際には、リクエストの形式として下記の形をとる必要がある。
TimeStampReq ::= SEQUENCE {
version INTEGER { v1(1) },
messageImprint ,
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL }
なお、オプションであるreqPolicy、nonce、extensionsは必ずしもリクエストに含む必要はない。
特にextensionsに関しては、将来の拡張などを見越した仕様を含ませるケースなどに使用され、指定されないことが多い。
また、reqPolicyは、タイムスタンプのサービスインスタンスが複数ある場合に、特定のインスタンスへリクエストを送る場合に用いられるものだが、一般のクライアントが指定することは少なく、特定のＵＲＩへのリクエストをゲートウェイなどで、特定のインスタンスに紐づけていることも多い。
タイムスタンプ要求受付部５２Ａは、タイムスタンプ要求の検証を行い、例えば、messageImprint中のハッシュ値がタイムスタンプサービスとして受け付けていない脆弱性のあるアルゴリズムの際はエラーを返すなどの処理を行う。
端末装置１０はサービス提供サーバ４０に対しタイムスタンプサービス要求を行う。
サービス提供サーバ４０はリダイレクトを行い、端末装置１０に認可サーバ２０の認証画面を表示する。
認証が成功すると、サービス提供サーバ４０は、認可サーバ２０より認可コードを受信し、認可コード（クライアントタイプがコンフィデンシャルの場合、併せて、クライアントＩＤ及びクライアントシークレット）を付与し、認可サーバ２０にアクセストークンのリクエストを行う。
認可サーバ２０は、ライセンス管理サーバ３０にライセンス要求を行う。
ライセンス管理サーバ３０が行う下記に詳述するライセンス特定処理の結果として、ライセンス情報（サービス種別やライセンスＩＤ、さらにはタイムスタンプの発行要求枚数など）、が発行され、ライセンス情報を含むアクセストークンがサービス提供サーバ４０に送される。
サービス提供サーバ４０は認可サーバ２０より受信した、ライセンス情報を含むアクセストークンをタイムスタンプサーバ５０ａに提示してタイムスタンプ要求を行うのである。
タイムスタンプサービスにアクセスする際には、リクエストの形式として下記の形をとる必要がある。
TimeStampReq ::= SEQUENCE {
version INTEGER { v1(1) },
messageImprint ,
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL }
なお、オプションであるreqPolicy、nonce、extensionsは必ずしもリクエストに含む必要はない。
特にextensionsに関しては、将来の拡張などを見越した仕様を含ませるケースなどに使用され、指定されないことが多い。
また、reqPolicyは、タイムスタンプのサービスインスタンスが複数ある場合に、特定のインスタンスへリクエストを送る場合に用いられるものだが、一般のクライアントが指定することは少なく、特定のＵＲＩへのリクエストをゲートウェイなどで、特定のインスタンスに紐づけていることも多い。
タイムスタンプ要求受付部５２Ａは、タイムスタンプ要求の検証を行い、例えば、messageImprint中のハッシュ値がタイムスタンプサービスとして受け付けていない脆弱性のあるアルゴリズムの際はエラーを返すなどの処理を行う。
【0059】
タイムスタンプサービスにアクセストークンとライセンス管理を導入することには非常に有用な点がある。特にＲＦＣ３１６１はあくまでプロトコルの仕様を決定しているのみであり、付随するビジネスロジックについては各ベンダー、開発者の判断に委ねられる。ベンダーによっては独自のＡＰＩを実装したクライアントソフト等の開発を行い、ＲＦＣ３１６１を外部から使えるようにはせずに、ある種の独自ＡＰＩにて実装しているという状態になっている可能性がある。この場合、クライアントは個々で独自ＡＰＩを実装する必要があり、標準のＲＦＣ３１６１に比較すると相互運用性の面で不利となる。
【0060】
アクセストークンとライセンス管理の仕組みはＯＡｕｔｈ２．０のアクセストークンを使用することを前提としているため、既存のＲＦＣ３１６１のプロトコルの仕様を改変することなく、ライセンスの管理も可能とするものである。
基本的にＲＦＣ３１６１のタイムスタンプ要求は、ＨＴＴＰベースのリクエストにより実装が可能であり、アクセストークンをリクエストヘッダーに含ませた場合、追加のパラメータや複数リクエストなど付与することがなく、またプロトコルの仕様違反を起こすことなく実装が可能である。
https://www.ipa.go.jp/security/rfc/RFC3161EN.html#34に記されるように、ＲＦＣ３１６１には、content typeの制約があるのみであり、他のヘッダー情報を付与してはならないという文書は見当たらない。
基本的にＲＦＣ３１６１のタイムスタンプ要求は、ＨＴＴＰベースのリクエストにより実装が可能であり、アクセストークンをリクエストヘッダーに含ませた場合、追加のパラメータや複数リクエストなど付与することがなく、またプロトコルの仕様違反を起こすことなく実装が可能である。
https://www.ipa.go.jp/security/rfc/RFC3161EN.html#34に記されるように、ＲＦＣ３１６１には、content typeの制約があるのみであり、他のヘッダー情報を付与してはならないという文書は見当たらない。
【0061】
アクセストークンとライセンス管理をタイムスタンプの例を用いて説明するにあたり、ＪＷＴを使用したより具体的な例を元に説明する。特に、ここでは前述の公開鍵認証方法を行うにあたり、署名が施されたＪＷＳでの実装方法について記載する。
上記したように、ＪＷＳはＪＳＯＮデータ任意の値を含め、署名、暗号化などの方法によりデータの受け渡しを想定とした仕様である。ＪＷＳ中のデータ定義は必須部分及び事前に定義されているフィールドを除き実装者が自由に決めることができる。
特に重要となってくるのが、ｓｃｏｐｅの処理により決定される権限の箇所であり、ｓｃｏｐｅによりＪＷＳ中に含まれるデータを変更する実装が多いため、注意が必要である。
ＪＷＴとＪＷＳの大まかな違いとして、実装レベルでのＪＷＴは仕様として大きな枠組みを決定しているだけであり、改竄防止手段としてＪＷＳを使用するという前提にて記載する。特にＪＷＳの使用方法について本実施形態では記載せず、具体例のみの記載とする。
上記したように、ＪＷＳはＪＳＯＮデータ任意の値を含め、署名、暗号化などの方法によりデータの受け渡しを想定とした仕様である。ＪＷＳ中のデータ定義は必須部分及び事前に定義されているフィールドを除き実装者が自由に決めることができる。
特に重要となってくるのが、ｓｃｏｐｅの処理により決定される権限の箇所であり、ｓｃｏｐｅによりＪＷＳ中に含まれるデータを変更する実装が多いため、注意が必要である。
ＪＷＴとＪＷＳの大まかな違いとして、実装レベルでのＪＷＴは仕様として大きな枠組みを決定しているだけであり、改竄防止手段としてＪＷＳを使用するという前提にて記載する。特にＪＷＳの使用方法について本実施形態では記載せず、具体例のみの記載とする。
【0062】
ＪＷＳを使用することでアクセストークンの検証を公開鍵認証方式にて実施することが可能になる。事前に秘密鍵、公開鍵のペアを認可サーバ２０で発行しておき公開鍵をタイムスタンプサーバ５０ａに配置しておく。
ここでは詳細に言及しないが、安全な秘密鍵、公開鍵のペアを作成するにあたりオープンソースのライブラリを使用することが多いが、ＨＳＭ（Hardware Security Module）にて鍵ペアを生成して保管する方式のほうがよりセキュリティ強度が高い。
ここで説明している公開鍵認証方式を採用することで、タイムスタンプサーバ５０ａのアクセストークン検証処理部により公開鍵認証方式を使用し、アクセストークンの検証を行うことが可能になる。
ここでは詳細に言及しないが、安全な秘密鍵、公開鍵のペアを作成するにあたりオープンソースのライブラリを使用することが多いが、ＨＳＭ（Hardware Security Module）にて鍵ペアを生成して保管する方式のほうがよりセキュリティ強度が高い。
ここで説明している公開鍵認証方式を採用することで、タイムスタンプサーバ５０ａのアクセストークン検証処理部により公開鍵認証方式を使用し、アクセストークンの検証を行うことが可能になる。
【0063】
ＪＷＳのトークンにてライセンス情報を紐づける場合、ＪＳＯＮのペイロード部分にライセンス情報を記載する必要がある。
タイムスタンプサービスを提供しているタイムスタンプ局ごとにライセンスの概念は異なるが、ここでは一例として、図１２に示すライセンス管理データベースで定義される例を取り上げている。
タイムスタンプサービスを提供しているタイムスタンプ局ごとにライセンスの概念は異なるが、ここでは一例として、図１２に示すライセンス管理データベースで定義される例を取り上げている。
【0064】
図１０は、本実施形態のタイムスタンプ提供処理を説明するシーケンス図である。
ステップＳ２１において、利用者が使用する端末装置１０（ウェブブラウザ）は、タイムスタンプの要求のため、サービス提供サーバ４０にアクセスする。
タイムスタンプ要求を受けたサービス提供サーバ４０は、ステップＳ２２において、利用者を認可サーバ２０にリダイレクトするページを端末装置１０に供給する。
利用者の操作により、端末装置１０は、ステップＳ２３において、認可サーバ２０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいて利用者の認証を要求するための手続である。
ステップＳ２１において、利用者が使用する端末装置１０（ウェブブラウザ）は、タイムスタンプの要求のため、サービス提供サーバ４０にアクセスする。
タイムスタンプ要求を受けたサービス提供サーバ４０は、ステップＳ２２において、利用者を認可サーバ２０にリダイレクトするページを端末装置１０に供給する。
利用者の操作により、端末装置１０は、ステップＳ２３において、認可サーバ２０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいて利用者の認証を要求するための手続である。
【0065】
ステップＳ２４の認証処理において、認可サーバ２０は、認証情報（例えば、利用者ＩＤとパスワード）の入力を利用者に要求する。なお、ステップＳ２４の認証処理において、認証情報の入力はＲＦＣ６７４９（ＯＡｕｔｈ２．０）で規定される処理とは異なり、認可サーバ２０と端末装置１０との間で別途確立されるセッションにおいて行われる。
利用者の認証が正常に行われると、認可サーバ２０は、利用者の確認を得たうえで認可を確立し、ステップＳ２５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
利用者の認証が正常に行われると、認可サーバ２０は、利用者の確認を得たうえで認可を確立し、ステップＳ２５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
【0066】
認可サーバ２０から送信された認可コードを受信した端末装置１０（ウェブブラウザ）は、ステップＳ２６において、認可コードをサービス提供サーバ４０に転送（Redirect）する。
端末装置１０から転送された認可コードを取得したサービス提供サーバ４０は、ステップＳ２７において、この認可コードを用いて、アクセストークン要求（Access token request）を認可サーバ２０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
アクセストークン要求を受け付けた認可サーバ２０は、ステップＳ２８において、端末装置１０又はその利用者のＩＤ情報に基づくライセンス管理サーバ３０に対してライセンス要求を行う。
端末装置１０から転送された認可コードを取得したサービス提供サーバ４０は、ステップＳ２７において、この認可コードを用いて、アクセストークン要求（Access token request）を認可サーバ２０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
アクセストークン要求を受け付けた認可サーバ２０は、ステップＳ２８において、端末装置１０又はその利用者のＩＤ情報に基づくライセンス管理サーバ３０に対してライセンス要求を行う。
【0067】
ライセンス管理サーバ３０は、認可サーバ２０によるライセンス要求を受け、ステップＳ２９において、ライセンス管理データベースから端末装置１０のライセンスデータ（サービス種別やライセンスＩＤ）特定するライセンス特定処理を行い、ステップＳ３０において、タイムスタンプの発行可能枚数などをさらに含む、特定したライセンス情報を認可サーバ２０に送信する。
ステップＳ３１において、認可サーバ２０は、ライセンス情報を含むアクセストークン応答（Access token response）をサービス提供サーバ４０に返す。すなわち、認可サーバ２０は、ライセンスを含むアクセストークンをサービス提供サーバ４０に送信する（ＲＦＣ６７４９＃４．１．４．）。
ステップＳ３１において、認可サーバ２０は、ライセンス情報を含むアクセストークン応答（Access token response）をサービス提供サーバ４０に返す。すなわち、認可サーバ２０は、ライセンスを含むアクセストークンをサービス提供サーバ４０に送信する（ＲＦＣ６７４９＃４．１．４．）。
【0068】
図１１は、タイムスタンプサービスに関するアクセストークンを示す図である。
図１１に示すように、アクセストークンにおいて、ＪＷＳ中にペイロードのデータを入れる。図１１に示すような挿入されたライセンス情報、及びＪＷＳに必要なヘッダー情報、署名値をアクセストークンとして使用し、サービス提供サーバ４０に返却することでライセンスが付与されたアクセストークンが完成する。
図１１に示すように、アクセストークンにおいて、ＪＷＳ中にペイロードのデータを入れる。図１１に示すような挿入されたライセンス情報、及びＪＷＳに必要なヘッダー情報、署名値をアクセストークンとして使用し、サービス提供サーバ４０に返却することでライセンスが付与されたアクセストークンが完成する。
【0069】
図１０の説明に戻り、認可サーバ２０からアクセストークンを取得したサービス提供サーバ４０は、ステップＳ３２において、タイムスタンプサーバ５０ａに対してアクセストークンを送信してタイムスタンプ要求を行う。
タイムスタンプ要求を受けたタイムスタンプサーバ５０ａは、ステップＳ３３においてサービス実行処理を行い、ステップＳ３６にてサービス提供サーバ４０に対してサービス応答を行う。
タイムスタンプサーバに５０Ａよるライセンス同期処理（ステップＳ３３～Ｓ３４）は、タイムスタンプ生成処理とは別に、定期的に、または、非定期的に、非同期に行われてもよい。
タイムスタンプ要求を受けたタイムスタンプサーバ５０ａは、ステップＳ３３においてサービス実行処理を行い、ステップＳ３６にてサービス提供サーバ４０に対してサービス応答を行う。
タイムスタンプサーバに５０Ａよるライセンス同期処理（ステップＳ３３～Ｓ３４）は、タイムスタンプ生成処理とは別に、定期的に、または、非定期的に、非同期に行われてもよい。
【0070】
ステップＳ２９のライセンス特定処理を詳述する。
まず、図１２は、タイムスタンプサービスに関してライセンス管理サーバが備えるライセンス管理データベースを示す図である。
図１２に示すライセンス管理データベース８０は、ライセンスＩＤテーブル８１、端末装置ＩＤテーブル８２、サービス種別テーブル８３、登録済ライセンス数テーブル８４を関連づけて管理している。
通常はリレーショナルなどでそれぞれのＩＤにてデータは定義されるが、より分かりやすく説明するため非正規化をしている例をとりあげる。
ライセンス管理サーバ３０は、ライセンス特定処理において、端末装置ＩＤテーブル８２において、ライセンス要求に係る端末装置１０又はその利用者の端末装置ＩＤを検索する。
ライセンス管理サーバ３０は、該当する端末装置１０又はその利用者の端末装置ＩＤが見つかると、登録済みライセンス数テーブル８４を参照し、発行可能枚数を含むライセンス情報を認可サーバ２０に返す。
まず、図１２は、タイムスタンプサービスに関してライセンス管理サーバが備えるライセンス管理データベースを示す図である。
図１２に示すライセンス管理データベース８０は、ライセンスＩＤテーブル８１、端末装置ＩＤテーブル８２、サービス種別テーブル８３、登録済ライセンス数テーブル８４を関連づけて管理している。
通常はリレーショナルなどでそれぞれのＩＤにてデータは定義されるが、より分かりやすく説明するため非正規化をしている例をとりあげる。
ライセンス管理サーバ３０は、ライセンス特定処理において、端末装置ＩＤテーブル８２において、ライセンス要求に係る端末装置１０又はその利用者の端末装置ＩＤを検索する。
ライセンス管理サーバ３０は、該当する端末装置１０又はその利用者の端末装置ＩＤが見つかると、登録済みライセンス数テーブル８４を参照し、発行可能枚数を含むライセンス情報を認可サーバ２０に返す。
【0071】
認可サーバ２０は、発行可能枚数を含むライセンス情報をライセンス管理サーバ３０から受け取ると、ライセンス情報を含むアクセストークンをタイムスタンプ要求として、サービス提供サーバ４０に送る。
サービス提供サーバ４０はタイムスタンプサーバ５０ａにサービス提供サーバ４０から受け取ったアクセストークンと共にタイムスタンプ要求を送る。
タイムスタンプサーバ５０ａはサービス提供サーバ４０より受け取ったタイムスタンプ要求に基づき、タイムスタンプ生成処理を行う
サービス提供サーバ４０はタイムスタンプサーバ５０ａにサービス提供サーバ４０から受け取ったアクセストークンと共にタイムスタンプ要求を送る。
タイムスタンプサーバ５０ａはサービス提供サーバ４０より受け取ったタイムスタンプ要求に基づき、タイムスタンプ生成処理を行う
【0072】
ステップＳ３３のタイムスタンプ生成処理において、タイムスタンプサーバ５０ａは、トークン検証部５１Ａによりアクセストークンを検証し、事前に認可サーバ２０から提供されていた定義情報を用いてライセンス情報を確認する（アクセストークンの定義情報は認可サーバ２０とタイムスタンプサーバ５０ａとで事前に共有されている必要がある）。
アクセストークン、ライセンス情報が有効であれば、すなわちトークン検証部５１Ａによるアクセストークンの検証、タイムスタンプ要求受付部５２Ａによるタイムスタンプ要求の確認が成功した場合には、タイムスタンプサーバ５０ａは、ステップＳ５３のタイムスタンプ生成処理において、サービス提供サーバ４０より受け取ったアクセストークン内のライセンス情報の発行可能枚数を上限としたタイムスタンプをサービス提供サーバ４０に対して発行する。タイムスタンプの発行は、タイムスタンプ生成部５３Ａが、サービス提供サーバ４０から送られてくるmessageImprint中のハッシュ値に対しタイムスタンプサーバ５０ａが時刻と共に電子署名を施すことによって行われる。
タイムスタンプサーバ５０ａは、実際に発行したタイムスタンプ生成数を保持する。ここで、ライセンス情報の発行可能枚数と実際に発行したタイムスタンプ生成数を比較することは重要である。発行したタイムスタンプ生成数は、ライセンス情報内のタイムスタンプ発行可能枚数を超えることはできない。
アクセストークン、ライセンス情報が有効であれば、すなわちトークン検証部５１Ａによるアクセストークンの検証、タイムスタンプ要求受付部５２Ａによるタイムスタンプ要求の確認が成功した場合には、タイムスタンプサーバ５０ａは、ステップＳ５３のタイムスタンプ生成処理において、サービス提供サーバ４０より受け取ったアクセストークン内のライセンス情報の発行可能枚数を上限としたタイムスタンプをサービス提供サーバ４０に対して発行する。タイムスタンプの発行は、タイムスタンプ生成部５３Ａが、サービス提供サーバ４０から送られてくるmessageImprint中のハッシュ値に対しタイムスタンプサーバ５０ａが時刻と共に電子署名を施すことによって行われる。
タイムスタンプサーバ５０ａは、実際に発行したタイムスタンプ生成数を保持する。ここで、ライセンス情報の発行可能枚数と実際に発行したタイムスタンプ生成数を比較することは重要である。発行したタイムスタンプ生成数は、ライセンス情報内のタイムスタンプ発行可能枚数を超えることはできない。
【0073】
タイムスタンプサーバ５０ａは、ステップＳ３４においてタイムスタンプの返却処理を行う。
サービス提供サーバ４０は、タイムスタンプサーバ５０ａより受信したのタイムスタンプ応答をもとに、コードサイン、ＰＤＦ等へのタイムスタンプ署名付加等を行い、端末装置１０へ結果を返却する。
タイムスタンプサーバ５０ａは、上記と同様に、定期的にライセンス管理サーバ３０とライセンスデータの同期処理を行い、ライセンスを更新する。排他処理によりデータの不整合を防ぐ必要があることも上記と同様である。
ステップＳ３５～Ｓ３６のライセンス同期処理において、ライセンス管理サーバ３０は、登録済ライセンス数テーブル８４から発行枚数をマイナス（ディクリメント）する。なお、ある端末装置１０又はその利用者について、登録済ライセンス数テーブル８４で管理される登録済ライセンス数が「０」であると、その端末装置１０又はその利用者に関してライセンスを使い切っていることを意味する。
登録済ライセンス数テーブル８４で管理されるライセンス数が例えば０である場合、ライセンス管理サーバ３０は、ステップＳ３１で、タイムスタンプサーバ５０ａで受け付けられないライセンス情報を送信する。
この場合、認可サーバ２０によってアクセストークン自体は発行されても、アクセストークンに含まれるライセンス情報によって、タイムスタンプサーバ５０ａは電子署名の発行を拒否する。
サービス提供サーバ４０は、タイムスタンプサーバ５０ａより受信したのタイムスタンプ応答をもとに、コードサイン、ＰＤＦ等へのタイムスタンプ署名付加等を行い、端末装置１０へ結果を返却する。
タイムスタンプサーバ５０ａは、上記と同様に、定期的にライセンス管理サーバ３０とライセンスデータの同期処理を行い、ライセンスを更新する。排他処理によりデータの不整合を防ぐ必要があることも上記と同様である。
ステップＳ３５～Ｓ３６のライセンス同期処理において、ライセンス管理サーバ３０は、登録済ライセンス数テーブル８４から発行枚数をマイナス（ディクリメント）する。なお、ある端末装置１０又はその利用者について、登録済ライセンス数テーブル８４で管理される登録済ライセンス数が「０」であると、その端末装置１０又はその利用者に関してライセンスを使い切っていることを意味する。
登録済ライセンス数テーブル８４で管理されるライセンス数が例えば０である場合、ライセンス管理サーバ３０は、ステップＳ３１で、タイムスタンプサーバ５０ａで受け付けられないライセンス情報を送信する。
この場合、認可サーバ２０によってアクセストークン自体は発行されても、アクセストークンに含まれるライセンス情報によって、タイムスタンプサーバ５０ａは電子署名の発行を拒否する。
【0074】
［サービス実行サーバが電子署名サービスを提供する場合］
一例として、本実施形態のサービス実行サーバ５０は、電子署名サーバ５０ｂである。この場合のアクセストークンを用いたライセンス管理では、基本的な処理は上記に説明したとおりである。
図１３は、電子署名サーバの機能構成を示す図である。
ハードウェア構成は、図６のサービス実行サーバ５０と同じであり、電子署名サーバの制御部の構成のみを説明する。
図１３に示すように、電子署名サーバ５０ｂとしてのサービス実行サーバは、トークン検証部５１Ｂと、電子署名要求受付部５２Ｂと、電子署名生成部５３Ｂと、電子署名返却部５４Ｂと、ライセンス同期部５５Ｂと、を備えている。
トークン検証部５１Ｂは、トークン検証部５１に対応し、サービス提供サーバ４０から送信されたアクセストークンを検証する処理を行う。
電子署名要求受付部５２Ｂは、サービス要求受付部５２に対応し、サービス提供サーバ４０からの電子署名要求を受け付ける処理を行う。
電子署名生成部５３Ｂは、サービス実行部５３に対応し、要求された電子署名の生成を実際に実行する処理を行う。
電子署名返却部５４Ｂは、サービス応答部５４に対応し、生成した電子署名を、サービス提供サーバ４０に返却する処理を行う。
ライセンス同期部５５Ｂは、ライセンス同期部５５に対応し、ライセンス管理サーバ３０に対して、ライセンスデータの同期要求を行う。
一例として、本実施形態のサービス実行サーバ５０は、電子署名サーバ５０ｂである。この場合のアクセストークンを用いたライセンス管理では、基本的な処理は上記に説明したとおりである。
図１３は、電子署名サーバの機能構成を示す図である。
ハードウェア構成は、図６のサービス実行サーバ５０と同じであり、電子署名サーバの制御部の構成のみを説明する。
図１３に示すように、電子署名サーバ５０ｂとしてのサービス実行サーバは、トークン検証部５１Ｂと、電子署名要求受付部５２Ｂと、電子署名生成部５３Ｂと、電子署名返却部５４Ｂと、ライセンス同期部５５Ｂと、を備えている。
トークン検証部５１Ｂは、トークン検証部５１に対応し、サービス提供サーバ４０から送信されたアクセストークンを検証する処理を行う。
電子署名要求受付部５２Ｂは、サービス要求受付部５２に対応し、サービス提供サーバ４０からの電子署名要求を受け付ける処理を行う。
電子署名生成部５３Ｂは、サービス実行部５３に対応し、要求された電子署名の生成を実際に実行する処理を行う。
電子署名返却部５４Ｂは、サービス応答部５４に対応し、生成した電子署名を、サービス提供サーバ４０に返却する処理を行う。
ライセンス同期部５５Ｂは、ライセンス同期部５５に対応し、ライセンス管理サーバ３０に対して、ライセンスデータの同期要求を行う。
【0075】
［電子署名について］
電子署名は署名検証を行うことによる改竄防止と、上記のタイムスタンプを使用した時刻証明を行い、情報の改竄を防ぐことを目的とする。タイムスタンプの使用は任意である。
電子署名にはおおまかにＣＡｄＥＳ、ＸＡｄＥＳ、ＰＡｄＥＳという署名プロファイルが存在し、利用者は、それぞれ用途にあったプロファイルを選択し使用する。ここでは特にＰＡｄＥＳについてのサービスを例として説明する。
電子署名は署名検証を行うことによる改竄防止と、上記のタイムスタンプを使用した時刻証明を行い、情報の改竄を防ぐことを目的とする。タイムスタンプの使用は任意である。
電子署名にはおおまかにＣＡｄＥＳ、ＸＡｄＥＳ、ＰＡｄＥＳという署名プロファイルが存在し、利用者は、それぞれ用途にあったプロファイルを選択し使用する。ここでは特にＰＡｄＥＳについてのサービスを例として説明する。
【0076】
ＰＡｄＥＳ、ＰＤＦ署名を行う場合、対象データのハッシュ値を計算し、ＲＦＣ５６５２のＣＭＳのＳｉｇｎｅｄＡｔｔｒｉｂｕｔｅｓ属性を生成し一般てきにＲＳＡで署名を行い、ＣＭＳ、ＳｉｇｎｅｄＤａｔａフィールドに格納し、対象データに埋め込むことでＰＤＦ署名となる。
なお、対象データは事前にパディングを設けＣＭＳデータの格納領域を作成しておく必要がある。
なお、対象データは事前にパディングを設けＣＭＳデータの格納領域を作成しておく必要がある。
【0077】
一例として、ここで説明するＰＤＦ署名に関してはすべて電子署名サーバ５０ｂにて上記処理を行うものとし、サービス提供サーバ４０がＰＤＦファイルを電子署名サーバ５０ｂに送信するだけでＰＤＦ署名が完結するものとする。
端末装置１０は、サービス提供サーバ４０に対する電子署名要求の際に、ＰＤＦファイルをサービス提供サーバ４０にアップロードし、サービス提供サーバ４０は認可サーバ２０の認証ページを端末装置１０に対して表示する。
認証が成功した場合、サービス提供サーバ４０は、認可サーバ２０から認可コードを受信し、認可コード（クライアントタイプがコンフィデンシャルの場合には、さらにクライアントＩＤ及びクライアントシークレット）を認可サーバ２０に送信し、アクセストークンを受信する。
アクセストークンを受信したサービス提供サーバ４０は、電子署名サーバ５０ｂに対する電子署名要求として、端末装置１０が事前にアップロードしたＰＤＦファイルとアクセストークンを送信する。
端末装置１０は、サービス提供サーバ４０に対する電子署名要求の際に、ＰＤＦファイルをサービス提供サーバ４０にアップロードし、サービス提供サーバ４０は認可サーバ２０の認証ページを端末装置１０に対して表示する。
認証が成功した場合、サービス提供サーバ４０は、認可サーバ２０から認可コードを受信し、認可コード（クライアントタイプがコンフィデンシャルの場合には、さらにクライアントＩＤ及びクライアントシークレット）を認可サーバ２０に送信し、アクセストークンを受信する。
アクセストークンを受信したサービス提供サーバ４０は、電子署名サーバ５０ｂに対する電子署名要求として、端末装置１０が事前にアップロードしたＰＤＦファイルとアクセストークンを送信する。
【0078】
電子署名要求を受信した際、電子署名サーバ５０ｂはアクセストークンの検証を行う。検証方式については、公開鍵認証方式とする。
トークン検証部５１Ｂにより公開鍵認証方式にて検証が成功した場合、電子署名要求受付部５２Ｂによりリクエストを判定し、電子署名生成部５３Ｂにより、説明した処理が行われる。ＰＤＦ署名が完了したのち電子署名返却部５４Ｂにより署名されたＰＤＦファイルをサービス提供サーバ４０に返却する。
サービス提供サーバ４０は、電子署名サーバ５０ｂから受信した電子署名済みＰＤＦファイルを端末装置１０に返却し、処理が完了する。
電子署名サーバ５０ｂは、前述したように、定期的に、あるいは、不定期的にライセンス管理サーバ３０とライセンスデータの同期処理を行い、ライセンスを更新する。排他処理によりデータの不整合を防ぐ必要があることも上記と同様である。
トークン検証部５１Ｂにより公開鍵認証方式にて検証が成功した場合、電子署名要求受付部５２Ｂによりリクエストを判定し、電子署名生成部５３Ｂにより、説明した処理が行われる。ＰＤＦ署名が完了したのち電子署名返却部５４Ｂにより署名されたＰＤＦファイルをサービス提供サーバ４０に返却する。
サービス提供サーバ４０は、電子署名サーバ５０ｂから受信した電子署名済みＰＤＦファイルを端末装置１０に返却し、処理が完了する。
電子署名サーバ５０ｂは、前述したように、定期的に、あるいは、不定期的にライセンス管理サーバ３０とライセンスデータの同期処理を行い、ライセンスを更新する。排他処理によりデータの不整合を防ぐ必要があることも上記と同様である。
【0079】
図１４は、本実施形態の電子署名提供処理を説明するシーケンス図である。
ステップＳ４１において、利用者が使用する端末装置１０（ウェブブラウザ）は、サービス提供サーバ４０にアクセスし、電子署名要求を送信する。
電子署名要求を受けたサービス提供サーバ４０は、ステップＳ４２において、利用者を認可サーバ２０にリダイレクトするページを端末装置１０に供給する。
利用者の操作により、端末装置１０は、ステップＳ４３において、認可サーバ２０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいて利用者の認証を要求するための手続である。
ステップＳ４１において、利用者が使用する端末装置１０（ウェブブラウザ）は、サービス提供サーバ４０にアクセスし、電子署名要求を送信する。
電子署名要求を受けたサービス提供サーバ４０は、ステップＳ４２において、利用者を認可サーバ２０にリダイレクトするページを端末装置１０に供給する。
利用者の操作により、端末装置１０は、ステップＳ４３において、認可サーバ２０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいて利用者の認証を要求するための手続である。
【0080】
ステップＳ４４の認証処理において、認可サーバ２０は、認証情報（例えば、利用者ＩＤとパスワード）の入力を利用者に要求する。なお、ステップＳ４４の認証処理において、認証情報の入力はＲＦＣ６７４９（ＯＡｕｔｈ２．０）で規定される処理とは異なり、認可サーバ２０と端末装置１０との間で別途確立されるセッションにおいて行われる。
利用者の認証が正常に行われると、認可サーバ２０は、利用者の確認を得たうえで認可を確立し、ステップＳ４５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
利用者の認証が正常に行われると、認可サーバ２０は、利用者の確認を得たうえで認可を確立し、ステップＳ４５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
【0081】
認可サーバ２０から送信された認可コードを受信した端末装置１０（ウェブブラウザ）は、ステップＳ４６において、認可コードをサービス提供サーバ４０に転送（Redirect）する。
端末装置１０から転送された認可コードを取得したサービス提供サーバ４０は、ステップＳ４７において、この認可コードを用いて、アクセストークン要求（Access token request）を認可サーバ２０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
アクセストークン要求を受け付けた認可サーバ２０は、ステップＳ４８において、端末装置１０又はその利用者のＩＤ情報に基づくライセンス要求を、ライセンス管理サーバ３０に対して行う。
端末装置１０から転送された認可コードを取得したサービス提供サーバ４０は、ステップＳ４７において、この認可コードを用いて、アクセストークン要求（Access token request）を認可サーバ２０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
アクセストークン要求を受け付けた認可サーバ２０は、ステップＳ４８において、端末装置１０又はその利用者のＩＤ情報に基づくライセンス要求を、ライセンス管理サーバ３０に対して行う。
【0082】
ライセンス管理サーバ３０は、認可サーバ２０によるライセンス要求を受け、ステップＳ４９において、ライセンス管理データベースから端末装置１０に関するライセンスデータを特定するライセンス特定処理を行い、ステップＳ５０において、特定したライセンスデータに基づくライセンス情報を認可サーバ２０に送信する。
ステップＳ５１において、認可サーバ２０は、ライセンスを含むアクセストークン応答（Access token response）をサービス提供サーバ４０に返す。すなわち、認可サーバ２０は、ライセンスを含むアクセストークンをサービス提供サーバ４０に送信する（ＲＦＣ６７４９＃４．１．４．）。
ステップＳ５１において、認可サーバ２０は、ライセンスを含むアクセストークン応答（Access token response）をサービス提供サーバ４０に返す。すなわち、認可サーバ２０は、ライセンスを含むアクセストークンをサービス提供サーバ４０に送信する（ＲＦＣ６７４９＃４．１．４．）。
【0083】
認可サーバ２０からアクセストークンを取得したサービス提供サーバ４０は、ステップＳ５２において、電子署名サーバ５０ｂに対してアクセストークンを送信して電子署名要求を行う。
電子署名要求を受けた電子署名サーバ５０ｂは、ステップＳ５３において、アクセストークン検証部５１Ｂによりアクセストークンを検証し、電子署名要求受付部５２Ｂによりライセンスを検証し、電子署名生成部５３Ｂにより電子署名実行処理を行う。
電子署名サーバ５０ｂは、ステップＳ５４において、電子署名返却部５４Ｂによりサービス提供サーバ４０に対して電子署名応答を行う。
電子署名サーバ５０ｂはステップＳ５５において、ライセンス同期部５６Ｂによりライセンス同期要求をライセンス管理サーバ３０に送信し、ライセンス管理サーバ３０は、ステップＳ５６において、ライセンス同期結果を電子署名サーバ５０ｂに送信する。
電子署名サーバによるライセンス同期処理（ステップＳ５５～Ｓ５６）は、サービス実行処理とは別に、定期的に、または、非定期的に、非同期に行われてもよい。
電子署名要求を受けた電子署名サーバ５０ｂは、ステップＳ５３において、アクセストークン検証部５１Ｂによりアクセストークンを検証し、電子署名要求受付部５２Ｂによりライセンスを検証し、電子署名生成部５３Ｂにより電子署名実行処理を行う。
電子署名サーバ５０ｂは、ステップＳ５４において、電子署名返却部５４Ｂによりサービス提供サーバ４０に対して電子署名応答を行う。
電子署名サーバ５０ｂはステップＳ５５において、ライセンス同期部５６Ｂによりライセンス同期要求をライセンス管理サーバ３０に送信し、ライセンス管理サーバ３０は、ステップＳ５６において、ライセンス同期結果を電子署名サーバ５０ｂに送信する。
電子署名サーバによるライセンス同期処理（ステップＳ５５～Ｓ５６）は、サービス実行処理とは別に、定期的に、または、非定期的に、非同期に行われてもよい。
【0084】
電子署名に関しても電子署名の場合と同様に、ライセンスデータとして登録済ライセンス数をライセンス管理サーバ３０で管理し、端末装置１０による電子署名要求は電子署名の実行可能回数を含む（実行回数を指定できる）にようにしてもよい。
この場合、ライセンス管理サーバ３０は、ライセンス特定処理において、端末装置ＩＤテーブル８２において、ライセンス要求に係る端末装置１０又はその利用者の端末装置ＩＤを検索する。
ライセンス管理サーバ３０は、該当する端末装置１０又はその利用者の端末装置ＩＤを検索し、登録済ライセンス数テーブル８４で管理される登録済ライセンス数を取得し、サービス種別、発行可能枚数を含むライセンス情報を認可サーバ２０に返す。
この場合、ライセンス管理サーバ３０は、ライセンス特定処理において、端末装置ＩＤテーブル８２において、ライセンス要求に係る端末装置１０又はその利用者の端末装置ＩＤを検索する。
ライセンス管理サーバ３０は、該当する端末装置１０又はその利用者の端末装置ＩＤを検索し、登録済ライセンス数テーブル８４で管理される登録済ライセンス数を取得し、サービス種別、発行可能枚数を含むライセンス情報を認可サーバ２０に返す。
【0085】
認可サーバ２０は、発行可能枚数含むライセンス情報をライセンス管理サーバ３０かから受け取ると、ライセンス情報を含むアクセストークンを電子署名要求として、サービス提供サーバ４０に送る。
【0086】
ステップＳ５３の電子署名実行処理において、電子署名サーバ５０ｂは、トークン検証部５１Ｂによりアクセストークンを検証し、事前に認可サーバ２０から提供されていた定義情報を用いてライセンス情報を確認する。
アクセストークン、ライセンス情報が有効であれば、すなわちトークン検証部５１Ｂによるアクセストークンの検証、電子署名要求受付部５２Ｂによる電子署名要求の確認が成功した場合には、電子署名サーバ５０ｂは、ステップＳ５３の電子署名実行処理において、アクセストークンに含まれるライセンス情報が指定する発行可能枚数分だけ、電子署名をサービス提供サーバ４０に対して発行できる。
ステップＳ５５～Ｓ５６のライセンス同期処理において、ライセンス管理サーバ３０は、登録済ライセンス数テーブル８４から発行枚数をマイナス（ディクリメント）する。なお、ある端末装置１０又はその利用者について、登録済ライセンス数テーブル８４で管理される登録済ライセンス数が「０」であると、その端末装置１０又はその利用者に関してライセンスを使い切っていることを意味する。
登録済ライセンス数テーブル８４で管理されるライセンス数が例えば０である場合、ライセンス管理サーバ３０は、ステップＳ５１で、電子署名サーバ５０ｂで受け付けられないライセンス情報を送信する。
この場合、認可サーバ２０によってアクセストークン自体は発行されても、アクセストークンに含まれるライセンス情報によって、電子署名サーバ５０ｂは電子署名の発行を拒否する。
アクセストークン、ライセンス情報が有効であれば、すなわちトークン検証部５１Ｂによるアクセストークンの検証、電子署名要求受付部５２Ｂによる電子署名要求の確認が成功した場合には、電子署名サーバ５０ｂは、ステップＳ５３の電子署名実行処理において、アクセストークンに含まれるライセンス情報が指定する発行可能枚数分だけ、電子署名をサービス提供サーバ４０に対して発行できる。
ステップＳ５５～Ｓ５６のライセンス同期処理において、ライセンス管理サーバ３０は、登録済ライセンス数テーブル８４から発行枚数をマイナス（ディクリメント）する。なお、ある端末装置１０又はその利用者について、登録済ライセンス数テーブル８４で管理される登録済ライセンス数が「０」であると、その端末装置１０又はその利用者に関してライセンスを使い切っていることを意味する。
登録済ライセンス数テーブル８４で管理されるライセンス数が例えば０である場合、ライセンス管理サーバ３０は、ステップＳ５１で、電子署名サーバ５０ｂで受け付けられないライセンス情報を送信する。
この場合、認可サーバ２０によってアクセストークン自体は発行されても、アクセストークンに含まれるライセンス情報によって、電子署名サーバ５０ｂは電子署名の発行を拒否する。
【符号の説明】
【0087】
１ システム、１０ 端末装置、１１ サービス要求部、１２ 認証部、１３ サービスデータ取得部、１４ ライセンス登録部、１５ 認証情報登録部、２０ 認可サーバ、２１ 認可要求受付部、２２ 認可コード発行部、２３ トークン要求受付部、２４ トークン発行部、２５ 端末装置登録部、３０ ライセンス管理サーバ、３１ 端末装置検索部、３２ ライセンス検索部、３３ ライセンス発行部、３４ ライセンス同期部、３５ ライセンス登録部、４０ サービス提供サーバ、４１ サービス要求受付部、４２ リダイレクト部、４３ 認可コード取得部、４４ トークン要求部、４５ サービス要求部、４６ サービス応答部、５０ サービス実行サーバ（５０ａ タイムスタンプサーバ、５０ｂ 電子署名サーバ）、５１ トークン検証部（５１Ａ トークン検証部、５１Ｂ トークン検証部）、５２ サービス要求受付部（５２Ａ タイムスタンプ要求受付部、５２Ｂ 電子署名要求受付部）、５３ サービス実行部（５３Ａ タイムスタンプ生成部、５３Ｂ 電子署名生成部）、５４ サービス応答部（５４Ａ タイムスタンプ返却部、５４Ｂ 電子署名返却部）、５５ ライセンス同期部（５５Ａ ライセンス同期部、５５Ｂ ライセンス同期部）８０ ライセンス管理データベース
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】