特許 7213838 承認支援装置、認証システム、承認支援方法及び承認支援プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-01-19

(45)【発行日】2023-01-27

(54)【発明の名称】承認支援装置、認証システム、承認支援方法及び承認支援プログラム

(51)【国際特許分類】

   G06F 21/33 20130101AFI20230120BHJP

   G06F 21/62 20130101ALI20230120BHJP

   G06F 3/0481 20220101ALI20230120BHJP

   G06Q 10/10 20230101ALI20230120BHJP

【ＦＩ】

G06F21/33

G06F21/62

G06F3/0481

G06Q10/10

【請求項の数】 12

(21)【出願番号】P 2020034102

(22)【出願日】2020-02-28

(65)【公開番号】P2021135953

(43)【公開日】2021-09-13

【審査請求日】2022-02-08

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100106002

【弁理士】

【氏名又は名称】正林 真之

(74)【代理人】

【識別番号】100120891

【弁理士】

【氏名又は名称】林 一好

(72)【発明者】

【氏名】田淵 純一

【審査官】吉田 歩

(56)【参考文献】

【文献】特開２００２－１０９４５７（ＪＰ，Ａ）

【文献】特開２００２－２３０２４１（ＪＰ，Ａ）

【文献】特開２０１７－１８２３２９（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／３３

Ｇ０６Ｆ ２１／６２

Ｇ０６Ｆ ３／０４８１

Ｇ０６Ｑ １０／１０

(57)【特許請求の範囲】

【請求項1】

機能の実行に必要な権限の範囲を示す全体数値範囲を取得する第１取得部と、
１又は複数のユーザの承認操作に応じて既に承認された権限それぞれに対応する数値範囲の和を取得する第２取得部と、
ユーザ毎に設定された、当該ユーザの権限の範囲を示す数値範囲を取得する第３取得部と、
承認操作が行われる際に、前記全体数値範囲に対して、既に承認された権限に対応する数値範囲の和、及び当該承認操作を行うユーザの権限に対応する数値範囲を、相対的な割合を視認可能な図形により提示する提示部と、を備える承認支援装置。

【請求項2】

前記提示部は、前記図形としてのプログレスバーの長さで数値範囲を示す請求項１に記載の承認支援装置。

【請求項3】

前記提示部は、前記図形としての円グラフの面積で数値範囲を示す請求項１に記載の承認支援装置。

【請求項4】

前記提示部は、承認を要する複数の機能について、前記図形を一覧表示させる請求項１から請求項３のいずれかに記載の承認支援装置。

【請求項5】

前記第３取得部は、前記ユーザの権限の範囲としての数値範囲に含まれ、当該ユーザが通常の承認操作により付与する権限の範囲を示す基本承認範囲をさらに取得し、
前記提示部は、前記複数の機能のうち、前記基本承認範囲が前記数値範囲の和に連続する範囲を含む機能を優先して一覧表示させる請求項４に記載の承認支援装置。

【請求項6】

前記提示部は、前記複数の機能のうち、前記ユーザの権限の範囲としての数値範囲が前記数値範囲の和に連続する範囲を含む機能を優先して一覧表示させる請求項４又は請求項５に記載の承認支援装置。

【請求項7】

前記提示部は、前記複数の機能のうち、前記ユーザの権限の範囲としての数値範囲を足し合わせることで前記全体数値範囲を充足する機能を強調して表示させる請求項４から請求項６のいずれかに記載の承認支援装置。

【請求項8】

前記ユーザの権限の範囲としての数値範囲のうち、いずれの範囲を承認するかを示す承認範囲の選択を受け付ける選択部を備える請求項１から請求項７のいずれかに記載の承認支援装置。

【請求項9】

前記第３取得部は、前記ユーザの権限の範囲としての数値範囲に含まれ、当該ユーザが通常の承認操作により付与する権限の範囲を示す基本承認範囲をさらに取得し、
前記選択部は、前記基本承認範囲を前記承認範囲の初期値とする請求項８に記載の承認支援装置。

【請求項10】

ユーザ毎に、当該ユーザの権限の範囲を示す数値範囲が設定された権限データを管理する権限管理部と、
機能の実行に必要な権限の範囲を示す全体数値範囲に対して、１又は複数のユーザの承認操作に応じて、当該１又は複数のユーザそれぞれの権限に対応する数値範囲の和が前記全体数値範囲を充足した場合に、当該機能の実行権限を付与する権限付与部と、
前記承認操作の際に、前記全体数値範囲に対して、既に承認された権限に対応する数値範囲の和、及び当該承認操作を行うユーザの権限に対応する数値範囲を、相対的な割合を視認可能な図形により表示させる表示制御部と、を備える認証システム。

【請求項11】

機能の実行に必要な権限の範囲を示す全体数値範囲を取得する第１取得ステップと、
１又は複数のユーザの承認操作に応じて既に承認された権限それぞれに対応する数値範囲の和を取得する第２取得ステップと、
ユーザ毎に設定された、当該ユーザの権限の範囲を示す数値範囲を取得する第３取得ステップと、
承認操作が行われる際に、前記全体数値範囲に対して、既に承認された権限に対応する数値範囲の和、及び当該承認操作を行うユーザの権限に対応する数値範囲を、相対的な割合を視認可能な図形データにより提示する提示ステップと、をコンピュータが実行する承認支援方法。

【請求項12】

請求項１から請求項９のいずれかに記載の承認支援装置としてコンピュータを機能させるための承認支援プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、認証システムに伴うユーザインタフェースを提供する承認支援装置、承認支援方法及び承認支援プログラムに関する。

【背景技術】

【0002】

従来、組織内の認証システムでは、実行したい機能それぞれに対して、複数の承認者を経由する承認フローが定められ、ユーザは、最終承認が得られて初めて機能を実行する権限を得られる（例えば、特許文献１参照）。

【0003】

具体的には、従来の認証システムは、
・組織を木構造の人のデータとして保持し、
・木構造の一部を特権グループとして保持し、
・権限毎に、木構造の人を特定の階層まで辿る承認経路と、特権グループによる承認の要否とを組み合わせた承認フローを一つ以上保持し、
・権限の要求時に、指定した承認フローを辿る全ての人の承認を得る、
ことにより、権限を付与している。

【0004】

承認の際には、それぞれの経路又は特権グループにおいて承認を行うことが可能な人が、要求されている権限と、承認フローの中の現在の承認状況とを確認した上で、承認又は否認の判断を行う。この承認フローに従った承認を順番に得ることにより、最終的に権限が付与される。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２００４－２４６５１６号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、従来の認証システムにおいては、組織上のある権限を持つ人が不在時に承認を完了させることができないため、代理といった新たな概念を導入する必要があった。また、特殊な組織構造を作ることが困難なため、例えば、４階層の組織を想定した承認フローが設定された認証システムでは、新たに２階層のみの組織を想定する場合には、既存の承認フローが利用できず、２階層向けの承認フローを追加で設定する必要があった。

【0007】

これらの課題は、従来の認証システムが木構造のデータに基づく処理を行っているために、木構造の変化により承認フローを変更しなければならないことに起因している。すなわち、複雑な木構造を持つ組織ほど、認証システムに対して多くの承認フローを設定しなければならなかった。

【0008】

また、このように複雑化した認証システムにおいて、承認者は、自分が承認を与えようとしている権限、及び付与対象の人が適切であるかを判断するために、自分がどの立場で承認しようとしているか、通常と異なる特殊な承認フローを経ていないか、といった承認時の状況に注意する必要がある。さらに、承認者は、自分が承認する前に他の承認者によってどのような確認が行われたか、自分が最終承認者であるか等を把握する必要がある。

【0009】

例えば、承認者は、組織の上位者として、特権グループの一員として、又は誰かの代理として承認を行うが、承認時のシステム上での自分の立場及び権限を誤認して誤った承認を与えないように、表示されているログイン名又は役割名等から注意深く判断する必要があった。また、例えば、形式的なフォーマットの確認だけを行う承認権限と、緊急時用に全権限を持つ承認権限との両方を有する承認者は、経てきた承認フローの違いによって、確認すべき事項の範囲が異なることに注意する必要があった。
そして、承認フローを確認しなければ、これまでにどのような確認がなされてきたのかを把握できない。これまでの確認事項を把握できない状態で承認を行うには、承認者が全項目を確認しなければならないため、承認業務の分担を目指す認証システムの価値が低減してしまう。さらに、承認者は、自分が最終承認者である場合には、承認直後に権限が付与されてしまうため、必要な確認が全て行われてきたことを把握する必要がある。

【0010】

このように、従来の認証システムの複雑さに起因して、承認者は、承認時に様々な注意を払わなければならず、これによりシステムの利便性が損なわれていた。
本発明は、承認フローの各段階において、承認者が確認事項の範囲を視覚的に容易に把握できる承認支援装置、認証システム、承認支援方法及び承認支援プログラムを提供することを目的とする。

【課題を解決するための手段】

【0011】

本発明に係る承認支援装置は、機能の実行に必要な権限の範囲を示す全体数値範囲を取得する第１取得部と、１又は複数のユーザの承認操作に応じて既に承認された権限それぞれに対応する数値範囲の和を取得する第２取得部と、ユーザ毎に設定された、当該ユーザの権限の範囲を示す数値範囲を取得する第３取得部と、承認操作が行われる際に、前記全体数値範囲に対して、既に承認された権限に対応する数値範囲の和、及び当該承認操作を行うユーザの権限に対応する数値範囲を、相対的な割合を視認可能な図形により提示する提示部と、を備える。

【0012】

前記提示部は、前記図形としてのプログレスバーの長さで数値範囲を示してもよい。

【0013】

前記提示部は、前記図形としての円グラフの面積で数値範囲を示してもよい。

【0014】

前記提示部は、承認を要する複数の機能について、前記図形を一覧表示させてもよい。

【0015】

前記第３取得部は、前記ユーザの権限の範囲としての数値範囲に含まれ、当該ユーザが通常の承認操作により付与する権限の範囲を示す基本承認範囲をさらに取得し、前記提示部は、前記複数の機能のうち、前記基本承認範囲が前記数値範囲の和に連続する範囲を含む機能を優先して一覧表示させてもよい。

【0016】

前記提示部は、前記複数の機能のうち、前記ユーザの権限の範囲としての数値範囲が前記数値範囲の和に連続する範囲を含む機能を優先して一覧表示させてもよい。

【0017】

前記提示部は、前記複数の機能のうち、前記ユーザの権限の範囲としての数値範囲を足し合わせることで前記全体数値範囲を充足する機能を強調して表示させてもよい。

【0018】

前記承認支援装置は、前記ユーザの権限の範囲としての数値範囲のうち、いずれの範囲を承認するかを示す承認範囲の選択を受け付ける選択部を備えてもよい。

【0019】

前記第３取得部は、前記ユーザの権限の範囲としての数値範囲に含まれ、当該ユーザが通常の承認操作により付与する権限の範囲を示す基本承認範囲をさらに取得し、前記選択部は、前記基本承認範囲を前記承認範囲の初期値としてもよい。

【0020】

本発明に係る認証システムは、ユーザ毎に、当該ユーザの権限の範囲を示す数値範囲が設定された権限データを管理する権限管理部と、機能の実行に必要な権限の範囲を示す全体数値範囲に対して、１又は複数のユーザの承認操作に応じて、当該１又は複数のユーザそれぞれの権限に対応する数値範囲の和が前記全体数値範囲を充足した場合に、当該機能の実行権限を付与する権限付与部と、前記承認操作の際に、前記全体数値範囲に対して、既に承認された権限に対応する数値範囲の和、及び当該承認操作を行うユーザの権限に対応する数値範囲を、相対的な割合を視認可能な図形により表示させる表示制御部と、を備える。

【0021】

本発明に係る承認支援方法は、機能の実行に必要な権限の範囲を示す全体数値範囲を取得する第１取得ステップと、１又は複数のユーザの承認操作に応じて既に承認された権限それぞれに対応する数値範囲の和を取得する第２取得ステップと、ユーザ毎に設定された、当該ユーザの権限の範囲を示す数値範囲を取得する第３取得ステップと、承認操作が行われる際に、前記全体数値範囲に対して、既に承認された権限に対応する数値範囲の和、及び当該承認操作を行うユーザの権限に対応する数値範囲を、相対的な割合を視認可能な図形データにより提示する提示ステップと、をコンピュータが実行する。

【0022】

本発明に係る承認支援プログラムは、前記承認支援装置としてコンピュータを機能させるためのものである。

【発明の効果】

【0023】

本発明によれば、認証システムにおける承認フローの各段階において、承認者が確認事項の範囲を視覚的に容易に把握できる。

【図面の簡単な説明】

【0024】

【図1】実施形態における認証システムの機能構成を示す図である。

【図2】実施形態におけるプログレスバーを例示する図である。

【図3】実施形態におけるプログレスバーの表示例を示す図である。

【図4】実施形態におけるプログレスバーの一覧表示の例を示す図である。

【図5】実施形態における承認範囲の選択方法を例示する図である。

【図6】第１実装例におけるサービス提供システムの構成を示す図である。

【図7】第１実装例における認証装置の機能構成を示す図である。

【図8】第１実装例におけるサービス提供装置の機能構成を示す図である。

【図9】第１実装例におけるサービス提供システムの第１の処理手順例を示すシーケンス図である。

【図10】第１実装例におけるサービス提供システムの第２の処理手順例を示すシーケンス図である。

【図11】第２実装例における認証装置の機能構成を示す図である。

【図12】第２実装例におけるサービス提供システムの処理手順例を示すシーケンス図である。

【発明を実施するための形態】

【0025】

以下、本発明の実施形態の一例について説明する。
本実施形態の認証システムは、実行する機能に必要な権限、及び各ユーザが有する権限の範囲を数値範囲により管理し、承認者が承認を行う際に、既に承認された範囲と、これから承認する範囲とを示すプログレスバーを表示する。

【0026】

ここで、承認フローの進捗状況を承認者に提示する従来の認証システムとして、承認フロー中で必要な承認の個数のうち、現在までに承認済みの数を表示するものがある。例えば、６つの承認が必要で３つの承認が既にされている場合、全体を示すプログレスバーの半分が塗りつぶされる。さらに、今後の承認範囲が示される場合、例えば、今後の承認範囲として、プログレスバーの３／６から４／６の範囲が塗りつぶされる。

【0027】

しかしながら、このような従来の認証システムでは、例えば、自分を最上位とした６階層の組織と２階層の組織とを同時に持つ承認者の場合、６階層の組織の方がより多くプログレスバーが塗りつぶされる。このため、自分の行使する権限の範囲が狭く見えるが、実際にはいずれの組織から上がってきた承認依頼に対しても同じ注意を払えばよい場合もある。
また、６階層の組織において、緊急扱いで上がってきた自分の下で１度しか承認されていない承認依頼は、２階層の組織から上がってきた承認依頼に表示されるプログレスバーと同じ範囲が塗りつぶされることになるが、実際には異なる注意を払わなければならないことが多い。

【0028】

このような問題を回避するために、プログレスバーに承認位置を示すマーカー又は承認者を表示したり、文章による説明を記載したりといった対策が考えられるが、いずれも、文字を読む、マーカーの数を確認する等、承認者に必要な確認事項を増やすこととなる。

【0029】

これに対して、本実施形態では、次のような機能構成により、承認者が確認事項の範囲を視覚的に容易に把握できるようにする。

【0030】

図１は、本実施形態における認証システム１の機能構成を示す図である。
認証システム１は、１又は複数の情報処理装置（コンピュータ）により構成され、権限管理部１００と、権限付与部２００と、表示制御部３００とを備える。

【0031】

権限管理部１００は、ユーザ毎に、ユーザの権限の範囲を示す数値範囲が設定された権限データを管理する。
数値範囲は、例えば、２つの数値により表現され、範囲の大きさにより権限の大きさが表現される。

【0032】

権限付与部２００は、要求された機能の実行に必要な権限の範囲を示す全体数値範囲に対して、１又は複数のユーザの承認操作に応じて、承認したユーザそれぞれの権限に対応する数値範囲の和が全体数値範囲を充足した場合に、この機能の実行権限を要求者に付与する。

【0033】

表示制御部３００は、承認者による承認操作の際に、全体数値範囲に対して、既に承認された権限に対応する数値範囲の和、及び承認者の権限に対応する数値範囲を、相対的な割合を視認可能な図形により表示させる。
具体的には、表示制御部３００は、例えば、図形としてのプログレスバーの長さで数値範囲を示すが、図形はこれには限られない。例えば、円グラフの面積等で数値範囲が示されてもよい。

【0034】

図２は、本実施形態におけるプログレスバーを例示する図である。
プログレスバーは、全体数値範囲のうち、一つ又は複数の数値範囲を表示するためのユーザインタフェースであり、例えば、横長の長方形、あるいは端部に円形の意匠、グラデーション等が施された図形が用いられる。

【0035】

この例では、全体数値範囲に対して、既に承認された範囲と、これから承認する範囲とが色分けして表示されている。これにより、承認者は、単一のプログレスバーにより、現在の承認状況及びこれから承認される範囲を視認できる。

【0036】

表示制御部３００は、第１取得部３１０と、第２取得部３２０と、第３取得部３３０と、提示部３４０と、選択部３５０とを備える。なお、表示制御部３００は、独立した情報処理装置（承認支援装置）として設けられてもよい。

【0037】

第１取得部３１０は、機能の実行に必要な権限の範囲を示す全体数値範囲を取得する。全体数値範囲は、例えば、予め機能毎にユーザの権限と対応付けて管理されるものであってよい。

【0038】

第２取得部３２０は、承認者の承認操作に応じて既に承認された権限それぞれに対応する数値範囲の和を取得する。
数値範囲の和は、権限付与部２００により計算されたものが第２取得部３２０に提供されてもよいが、第２取得部３２０が承認者毎の数値範囲に基づいて和を計算してもよい。

【0039】

第３取得部３３０は、ユーザ毎に設定された、ユーザの権限の範囲を示す数値範囲を権限管理部１００から取得する。
また、第３取得部３３０は、ユーザの権限の範囲としての数値範囲に含まれ、このユーザが通常の承認操作により付与する権限の範囲を示す基本承認範囲をさらに取得してもよい。

【0040】

提示部３４０は、承認操作が行われる際に、承認要求された機能に関する前述のプログレスバーを承認者に対して提示する。
具体的には、例えば、承認支援装置としての承認者の端末がプログレスバーの画像を生成して画面表示する。あるいは、承認者の端末が承認支援装置の提示部３４０から表示データを受信して画面表示してもよい。

【0041】

認証システム１では、承認者は、承認時に立場の使い分けを行わず、行使する権限は、表示された「これから承認する範囲」により視覚的に把握できる。例えば、通常よりも広い範囲の承認を行う場合には、プログレスバー上に、通常よりも広い範囲が表示される。
認証システム１では複数の承認フローは区別されず、承認者は、必要とする権限の範囲をプログレスバーの長さにより視覚的に把握できる。例えば、承認者は、現時点までに承認を行った他の承認者によりどのような確認が行われたかを、プログレスバー上の「既に承認された範囲」により視覚的に把握できる。また、「これから承認する範囲」がプログレスバーの右端まで達しているか否かにより、最終承認であるか否かが判断できる。

【0042】

図３は、本実施形態におけるプログレスバーの表示例を示す図である。
プログレスバーは、その長さにより「必要な承認の量」が示され、この全体の長さが「既に承認された範囲」Ａ、「これから承認する範囲」Ｂ及び「残存承認範囲」Ｃに色分けされる。

【0043】

プログレスバー全体の長さによって、例えば（ａ１）と（ａ２）とを比較すると、（ａ１）の方がより多くの承認を必要とすることが分かる。
また、「既に承認された範囲」と「これから承認する範囲」との位置関係により、例えば、（ｂ１）では次に自分が承認すること、（ｂ２）では他の承認後に自分が承認することが分かる。
また、「これから承認する範囲」の長さと「残存承認範囲」の長さとの関係により、例えば、（ｃ１）と（ｃ２）とを比較すると、（ｃ２）の方がより多くの注意を払う必要があることが分かる。さらに、（ｃ３）では、最終承認者としての注意が必要となる。

【0044】

この他、提示部３４０は、承認を要する複数の機能（承認案件）について、対応する複数のプログレスバーを縦に並べて一覧表示させてもよい。
これにより、承認者は、例えば、全ての承認可能な案件の中から「これから承認する範囲」に基づいて、同一の注意を払えばよい案件群、及び通常と異なる特殊な承認が必要な案件を視認できる。さらに、「これから承認する範囲」の長さ等によりソートを行うことにより、さらに視認性の向上が期待できる。

【0045】

図４は、本実施形態におけるプログレスバーの一覧表示の例を示す図である。
ここでは、権限データに示す承認権限と基本承認範囲とを持つ承認者に対して提示される承認案件の一覧を例示している。

【0046】

提示部３４０は、一覧表示する複数の機能のうち、承認済みの権限に対する数値範囲の和、すなわち既に承認された範囲に連続する範囲を第３取得部３３０により取得した基本承認範囲が含むものを優先して一覧表示させている。
具体的には、案件５，１２，６がこれに該当し、基本承認範囲を承認する案件が最優先で表示される。

【0047】

次に、提示部３４０は、複数の機能のうち、ユーザの権限の範囲としての数値範囲が既に承認された範囲に連続する範囲を含む機能を優先して一覧表示させている。
具体的には、案件３，１がこれに該当し、基本承認範囲を超えて、既に承認された範囲に連続した範囲を承認可能な案件が優先して表示される。

【0048】

さらに、提示部３４０は、複数の機能のうち、ユーザの権限の範囲としての数値範囲を足し合わせることで全体数値範囲を充足する、すなわち自分の承認で決済が完了する機能を強調して表示させてもよい。
具体的には、案件６がこれに該当し、例えば、背景色が区別されて表示される。

【0049】

また、案件１０のように、これから承認する範囲に基本承認範囲が含まれない案件、案件４，２のように、既に承認された範囲に連続した承認権限を持たない案件、案件１１のように、自分が承認に関与しない案件等があわせて表示されてもよい。

【0050】

このような一覧表示を行うことにより、例えば、社長のように全権限を保持するユーザに対して、常に全案件が表示されるのではなく、最小限の注意を払って承認すればよい案件、すなわち基本承認範囲のみを承認する案件が優先的に表示される。
このとき、例えば、社長の権限を用いて即時に承認を完了させたい案件等、特定の種類の案件を探し出すことが可能となる。また、既に承認された範囲とこれから承認する範囲とが離れているような案件を前もって承認しておくといった利用も可能となる。

【0051】

なお、一覧表示の並び順は、用途に応じて変更されてもよく、プログレスバーに表示される各数値範囲と、前述の基本承認範囲を用いることで、承認者が払うべき注意に着目したソートが可能となる。

【0052】

選択部３５０は、ユーザの権限の範囲としての数値範囲のうち、いずれの範囲を承認するかを示す承認範囲の選択を受け付ける。
このとき、選択部３５０は、前述の基本承認範囲を承認範囲の初期値としてよい。

【0053】

図５は、本実施形態における承認範囲の選択方法を例示する図である。
この例では、全体承認範囲が０～１であり、既に承認された範囲が０～０．４である。
ここで、これから承認者が承認できる範囲は、承認者の権限に対応する数値範囲のうち未承認の範囲０．４～０．９である。

【0054】

ここで、デフォルトの承認範囲である基本承認範囲が０．５～０．８であるとき、例えば、０．４～０．５の領域、０．５～０．８の領域、又は０．８～０．９の領域のうち、１つ以上の領域を選択（例えば、クリック）することにより、承認範囲が指定されてもよい。
また、承認範囲の始点から終点までがドラッグ等により指定されてもよい。あるいは、デフォルトの承認範囲である基本承認範囲の始点又は終点を、承認可能範囲の中でドラッグ等により移動することにより、承認範囲が指定されてもよい。

【0055】

このように、承認範囲を選択するためのインタフェースが設けられることにより、基本承認範囲のみを承認するか、承認可能な範囲全体を承認するかといった選択が容易になる。また、基本承認範囲がデフォルトで選択されることにより、通常と異なる承認操作の場合にのみ追加の操作が課されるので、誤操作が抑制される。

【0056】

次に、本実施形態における認証システム１の実装例として、サービス提供システム１Ａ（第１実装例）及び１Ｂ（第２実装例）を説明する。

【0057】

［第１実装例］
図６は、第１実装例におけるサービス提供システム１Ａの構成を示す図である。

【0058】

サービス提供システム１Ａは、ユーザを認証し、サービスの各機能を利用する際の権限を示すトークンをユーザに発行する認証装置１０と、トークンによりユーザの権限を確認し、サービスの各機能をＡＰＩによりユーザへ提供するサービス提供装置２０とを備え、それぞれ複数のユーザ（端末）と通信接続されている。

【0059】

ユーザＡは、ある機能、すなわちＡＰＩを利用する際に、認証装置１０にアクセスし、ユーザＡの権限に相当する認可トークンを取得する。
このとき、ユーザＡの権限がＡＰＩを実行するには不足する場合、例えば、他のユーザＢの承認が必要である場合、ユーザＡは、ユーザＢに対して承認要求を行い、ユーザＢは、認証装置１０からユーザＢの権限に相当する承認トークンを取得してユーザＡに送信する。
そして、ユーザＡは、認可トークン及び承認トークンを伴ってサービス提供装置２０が提供するＡＰＩを実行する。

【0060】

サービス提供装置２０は、ユーザＡからの要求に応じて、受信した認可トークン及び承認トークンが正しいこと、及びトークン群の権限を足し合わせたものがＡＰＩの実行権限を充足していることを確認した上で、ＡＰＩを実行する。

【0061】

ここで、認証装置１０が発行するトークン群（認可トークン又は承認トークン）には、それぞれスコープに対して権限の範囲を示す数値範囲が付与される。
従来のトークンは、
｛ｉｄ：“Ａ”，ｓｃｏｐｅ：“ｃａｎＳｅｎｄＭａｉｌ”｝＋署名
のように、スコープに文字列が設定されたものである。
これに対して、本実装例では、完全な実行権限を持たないユーザＡには、０～１の全数値範囲のうちの一部の数値範囲（例えば、０～０．５）が権限として設定され、認可トークンは、
｛ｉｄ：“Ａ”，ｓｃｏｐｅ：［“ｃａｎＳｅｎｄＭａｉｌ”，０，０．５］｝＋署名
のように、２つの数値（０，０．５）がスコープに付与された形式となる。

【0062】

また、別のユーザＢが、
｛ｉｄ：“Ｂ”，ｓｃｏｐｅ：［“ｃａｎＳｅｎｄＭａｉｌ”，０．５，１］｝＋署名
のように残りの権限（数値範囲０．５～１）を有している場合、まず、ユーザＡが実行案データ｛メールデータ｝をユーザＢに送信し、ユーザＢは、自分が有する認可トークンから実行対象（ｐｌａｎ）を制限した、
｛ｉｄ：“Ｂ”，ｓｃｏｐｅ：［“ｃａｎＳｅｎｄＭａｉｌ”，０．５，１］，ｐｌａｎ：｛メールデータ｝｝＋署名
のような承認トークンを認証装置１０から取得する。

【0063】

ユーザＡは、自分の認可トークン、及びユーザＢから受信した承認トークンを合わせて利用することで、スコープに付与された数値範囲の合計が０～１となり、「ｃａｎＳｅｎｄＭａｉｌ」に対応する機能（ＡＰＩ）を利用できる。

【0064】

図７は、第１実装例における認証装置１０の機能構成を示す図である。
認証装置１０は、サーバ装置等の情報処理装置（コンピュータ）であり、制御部１１及び記憶部１２の他、各種データの入出力デバイス及び通信デバイス等を備える。

【0065】

制御部１１は、認証装置１０の全体を制御する部分であり、記憶部１２に記憶された各種プログラムを適宜読み出して実行することにより、本実装例における各機能を実現する。制御部１１は、ＣＰＵであってよい。

【0066】

記憶部１２は、ハードウェア群を認証装置１０として機能させるためのプログラム及び各種データ等の記憶領域であり、ＲＯＭ、ＲＡＭ、フラッシュメモリ又はハードディスク（ＨＤＤ）等であってよい。

【0067】

制御部１１は、権限管理部１１１と、認可トークン発行部１１２と、承認トークン発行部１１３とを備える。

【0068】

権限管理部１１１は、ユーザに利用が許可された機能（ＡＰＩ）における権限の範囲を示す数値範囲が設定された権限データを記憶部１２に記憶し管理する。ユーザそれぞれには、複数の権限データが設定されてよい。
また、各機能を実行するために必要な権限データとして、機能毎にスコープの文字列と数値範囲とが同様に記憶される。

【0069】

例えば、
・係長の権限を持つユーザは、メールを送信できる。
・社員の権限を持つユーザは、メールの送信内容について係長の承認がある場合にのみ、メールを送信できる。
・全ての社員又は係長は、自らを差出人とするメールしか送信できない。
という条件に対しては、次のように権限設定される。
・メールを送信するＡＰＩに対して、［“ｃａｎＳｅｎｄＭａｉｌ”，［０．５，１］］
・係長Ｂに対して、［“ｃａｎＳｅｎｄＭａｉｌ”，０，１］
・社員Ａに対して、［“ｃａｎＳｅｎｄＭａｉｌ”，０，０．５］

【0070】

このように、権限データには、文字列と２つの数値とが、それぞれ識別可能な形で含まれる。
権限データに含まれる２つの数値は、数値範囲を示すものであり、例えば、数値範囲の始点及び終点であってよいが、これには限られず、始点と範囲の大きさ、あるいは終点と範囲の大きさ等であってもよい。以下、２つの数値は、範囲の始点及び終点であるものとして説明する。例えば、０．１と０．５が与えられた場合、０．１～０．５の数値範囲を示す。

【0071】

認可トークン発行部１１２は、ユーザ認証を行い、認証した第１のユーザに対して、この第１のユーザの権限データの一部又は全てに紐づく認可トークンを発行する。
認証の方式は、例えば、パスワード認証、共通鍵認証、２段階認証、生体認証、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔによる代理認証、他の認証システムから発行されたトークンによる認証等が適用可能であるが、これらには限られない。

【0072】

ユーザＡに発行される認可トークンの具体的なデータは、例えば、次のような形式で記述される。
｛
ｉｄ：“Ａ”，
ｓｃｏｐｅ：［“ｃａｎＳｅｎｄＭａｉｌ”，［０，０．５］］
｝，ｓｉｇｎａｔｕｒｅ ／／認証装置１０の署名

【0073】

承認トークン発行部１１３は、ユーザ認証を行い、第１のユーザによる機能の実行案データを承認した第２のユーザに対して、第２のユーザの権限データの一部又は全てに紐づく承認トークンを発行する。
認証の方式は、認可トークン発行部１１２と同様の手法が適用可能であり、さらに、認可トークン発行部１１２により発行された認可トークンによる認証であってもよい。

【0074】

また、承認トークン発行部１１３は、ユーザから、このユーザの権限データのうち、いずれかが指定された場合に、指定された権限データに紐づく承認トークンを発行する。

【0075】

第１のユーザＡから第２のユーザＢへ送信される実行案データ及び権限データは、例えば、次のような形式で記述される。
｛ａｐｉ：“ｓｅｎｄｍａｉｌ”，ｆｒｏｍ：“Ａ”，ｔｉｔｌｅ：“ｈｅｌｌｏ”，ｃｏｎｔｅｎｔ：“ｈｅｌｌｏ ｗｏｒｌｄ”｝ ／／実行案データ
［“ｃａｎＳｅｎｄＭａｉｌ”，［０，０．５］］ ／／権限データ

【0076】

また、第２のユーザＢに発行される認可トークンは、例えば、
｛
ｉｄ：“Ｂ”，
ｓｃｏｐｅ：［“ｃａｎＳｅｎｄＭａｉｌ”，［０，１］］
｝，ｓｉｇｎａｔｕｒｅ ／／認証装置１０の署名
であり、実行案データが提示されることで発行される承認トークンは、例えば、
｛
ｉｄ：“Ｂ”，
ｓｃｏｐｅ：［“ｃａｎＳｅｎｄＭａｉｌ”，［０，１］］
ｐｌａｎ：｛ａｐｉ：“ｓｅｎｄｍａｉｌ”，ｆｒｏｍ：“Ａ”，ｔｉｔｌｅ：“ｈｅｌｌｏ”，ｃｏｎｔｅｎｔ：“ｈｅｌｌｏ ｗｏｒｌｄ”｝
｝，ｓｉｇｎａｔｕｒｅ ／／認証装置１０の署名
と記述される。

【0077】

なお、権限データと認可トークン又は承認トークンとの紐付けは、例えば、次のいずれかの方法により行われる。
・トークンのデータ中に権限データを含む。
・トークンの発行時に、データベース等により権限データと紐付け管理される。
本実装例では、トークンのデータ中に権限データを含むものとしている。

【0078】

認可トークンと承認トークンとは、識別子が付与されることにより互いに識別可能に構成されてよい。
また、認可トークン及び承認トークンは、例えば次のような検証方法により、認証装置１０により発行されたものであることが検証可能である。
・電子署名による検証
・トークンをデータベースと照合することによる検証
・トークンのハッシュ値をデータベースと照合することによる検証
・上記のいずれかを行うＡＰＩを用いた検証

【0079】

図８は、第１実装例におけるサービス提供装置２０の機能構成を示す図である。
サービス提供装置２０は、サーバ装置等の情報処理装置（コンピュータ）であり、制御部２１及び記憶部２２の他、各種データの入出力デバイス及び通信デバイス等を備える。

【0080】

制御部２１は、サービス提供装置２０の全体を制御する部分であり、記憶部１２に記憶された各種プログラムを適宜読み出して実行することにより、本実装例における各機能を実現する。制御部１１は、ＣＰＵであってよい。

【0081】

記憶部１２は、ハードウェア群をサービス提供装置２０として機能させるためのプログラム及び各種データ等の記憶領域であり、ＲＯＭ、ＲＡＭ、フラッシュメモリ又はハードディスク（ＨＤＤ）等であってよい。

【0082】

制御部２１は、トークン受付部２１１と、機能提供部２１２とを備える。

【0083】

トークン受付部２１１は、認証装置１０により認証された第１のユーザに対して発行された認可トークン、及び第１のユーザによる機能（ＡＰＩ）の実行案データを承認した第２のユーザに対して発行された承認トークンを、第１のユーザから機能の実行要求と共に受信する。

【0084】

機能提供部２１２は、第１のユーザから受信した認可トークン及び承認トークンのそれぞれに紐づく数値範囲の足し合わせが所定の範囲を包含する場合に、第１のユーザに機能を提供する。
なお、所定の範囲とは、前述のように、機能（ＡＰＩ）毎に権限データに設定された数値範囲（例えば、０～１）である。

【0085】

ここで、数値範囲を足し合わせたものとは、対象の複数の数値範囲の全てが含まれる最小の数値範囲の集合を示す。例えば、０～０．５の数値範囲と、０．３～０．７の数値範囲とを足し合わせると、０～０．７の数値範囲が得られる。また、０～０．１の数値範囲と０．８～０．９の数値範囲を足し合わせると、０～０．１及び０．８～０．９の２つの数値範囲の集合が得られる。
このようなトークン群の数値範囲の足し合わせが機能（ＡＰＩ）の権限データに設定された数値範囲を包含する場合、機能の利用が許可される。

【0086】

図９は、第１実装例におけるサービス提供システム１Ａの第１の処理手順例を示すシーケンス図である。
この例では、社員Ａが係長Ｂの承認を得てメールを送信するためのＡＰＩを利用する場合を説明する。

【0087】

ステップＳ１において、社員Ａ（端末）は、認証装置１０から、メール送信機能に対する権限データＡ１（例えば、［“ｃａｎＳｅｎｄＭａｉｌ”，［０，０．５］］）に紐付いた認可トークンを取得する。

【0088】

ステップＳ２において、社員Ａは、メールを送信するＡＰＩの実行に必要なメールタイトル、メール送信先、メール本文等を持つ実行案データＸを生成する。
ステップＳ３において、社員Ａは、実行案データＸ及び権限データＡ１を、係長Ｂ（端末）に対して送信する。

【0089】

ステップＳ４において、係長Ｂは、実行案データＸ及び権限データＡ１の内容を確認する。
ステップＳ５において、係長Ｂは、認証装置１０から、実行案データＸ、及び係長Ｂに対して設定されている権限データＢ１に紐づいた承認トークンを取得する。
ステップＳ６において、係長Ｂは、承認トークンを社員Ａに対して送信する。

【0090】

ステップＳ７において、社員Ａは、認可トークンと承認トークンとを付与して、サービス提供装置２０が提供しているメールを送信するＡＰＩを呼び出す。

【0091】

ステップＳ８において、サービス提供装置２０は、権限データＡ１と権限データＢ１にスコープの文字列として“ｃａｎＳｅｎｄＭａｉｌ”が含まれていることを確認する。

【0092】

ステップＳ９において、サービス提供装置２０は、ＡＰＩの実行時に指定されたメールタイトル、メール送信先、メール本文等が、承認トークンに紐づいた実行案データのメールタイトル、メール送信先、メール本文等と等しいことを確認する。

【0093】

ステップＳ１０において、サービス提供装置２０は、権限データＡ１の２つの数値［０，０．５］、及び権限データＢ１の２つの数値［０，１］によって示される数値範囲を足し合わせた［０，１］で示される数値範囲がメールを送信するＡＰＩに設定された権限データの２つの数値［０，１］で示される数値範囲を包含していることを確認する。

【0094】

ステップＳ１１において、サービス提供装置２０は、認可トークン及び承認トークンに付与された署名を検証し、メール送信の機能を実行する。

【0095】

図１０は、第１実装例におけるサービス提供システム１Ａの第２の処理手順例を示すシーケンス図である。
この例では、ユーザＡが複数のユーザＵ１～Ｕｎの承認を得て対象のＡＰＩを利用する場合を説明する。

【0096】

ステップＳ２１において、ユーザＡ（端末）は、認証装置１０から、対象のＡＰＩに対する権限データに紐付いた認可トークンＫを取得する。
ステップＳ２２において、ユーザＡは、対象のＡＰＩの実行に必要な実行案データＸを生成する。

【0097】

ステップＳ２３において、ユーザＡは、自身に設定された権限データのうち、対象のＡＰＩの実行に利用する権限データＫｄ、及び実行案データＸを、ユーザＵ１～Ｕｎ（端末）に対して送信する。
なお、ユーザＵ１～Ｕｎへのデータ送信は、一斉であってもよいが、ユーザＡは、一部のユーザＵｘに先に送信し、後述の承認トークンが返却されるのを待って、返却された１つ以上の承認トークンと共に、権限データＫｄ及び実行案データＸを他のユーザＵｙへ送信してもよい。

【0098】

ステップＳ２４において、ユーザＵ１～Ｕｎは、それぞれＫｄ、Ｘ、及び承認トークン群の内容を確認し、認証装置１０から、実行案データＸ、及び自分に対して設定されている権限データに紐づいた承認トークンＫ１～Ｋｎを取得する。
ステップＳ２５において、ユーザＵ１～Ｕｎは、それぞれが取得した承認トークンＫ１～ＫｎをユーザＡに対して送信する。

【0099】

ステップＳ２６において、ユーザＡは、認可トークンＫ及び承認トークンＫ１～Ｋｎを付与して対象のＡＰＩを呼び出す。

【0100】

ステップＳ２７において、サービス提供装置２０は、付与された認可トークンＫが１つであることを確認する。
ステップＳ２８において、サービス提供装置２０は、付与された認可トークンＫ及び全ての承認トークンＫ１～Ｋｎの正当性を検証し、結果を確認する。

【0101】

ステップＳ２９において、サービス提供装置２０は、付与された認可トークンＫと全ての承認トークンＫ１～Ｋｎとに紐づけられた権限データを全て取得する。
ステップＳ３０において、サービス提供装置２０は、付与された全ての承認トークンＫ１～Ｋｎに紐づけられた実行案データＸを全て取得する。

【0102】

ステップＳ３１において、サービス提供装置２０は、取得した権限データ全てについて、対象のＡＰＩに設定された権限データに含まれるスコープの文字列と等しい文字列が含まれていることを確認する。

【0103】

ステップＳ３２において、サービス提供装置２０は、実行案データＸの全てについて、呼び出されたＡＰＩの要求内容を対象としたものであることを確認する。
この確認方法は、例えば、次の（１）～（３）のいずれかによる。

【0104】

（１）実行案データＸの形式を、ＡＰＩ利用時に入力予定の電文の全て又は一部とする場合、サービス提供装置２０は、対象のＡＰＩに対して実際に送信された電文の全て又は一部が実行案データＸと等しいことを確認する。
なお、電文の一部を利用する場合、電文のどの部分を実行案データＸとして利用するのか（例えば、ＨＴＴＰの場合におけるＨＴＴＰ Ｒｅｑｕｅｓｔデータ等）を、ＡＰＩ毎又は全体として予め決めておくものとする。

【0105】

（２）実行案データＸの形式を、ＡＰＩ利用時に必要となる一部又は全ての引数をＪＳＯＮ、ＸＭＬ等の方法でエンコードしたものとする場合、サービス提供装置２０は、実行案データＸに指定された一部又は全ての引数が対象のＡＰＩに対して実際に指定された値と等しいことを確認する。
なお、エンコードの方法は予め決めておくものとする。また、引数の一部を利用する場合、どの引数を確認対象とするのか（例えば、ＨＴＴＰの場合におけるＰＡＴＨ、ヘッダ、ＱｕｅｒｙＳｔｒｉｎｇ、ＰＯＳＴＤＡＴＡ等）をＡＰＩ毎又は全体として予め決めておくものとする。このとき、実行案データＸに指定する引数として、正規表現、ワイルドカード、数値範囲等を利用できるように予め決めておくことにより、サービス提供装置２０は、指定された値と等しいことを確認する代わりに、正規表現、ワイルドカード、数値範囲等による照合を行ってもよい。

【0106】

（３）実行案データＸの形式を、あらゆる引数によるＡＰＩ実行を許可することを示す文字列又は値（例えば、“ＡＬＬ”、“＊”、数値の１等）とする場合、サービス提供装置２０は、対象のＡＰＩへの要求内容に関わらず確認できたものとする。

【0107】

ステップＳ３３において、サービス提供装置２０は、全ての権限データの２つの数値によって示される数値範囲を足し合わせたものが、対象のＡＰＩに設定された２つの数値によって示される数値範囲を包含していることを確認する。

【0108】

ステップＳ３４において、サービス提供装置２０は、全ての事項が確認できた場合に対象のＡＰＩにより提供される機能の実行を許可する。
なお、サービス提供装置２０は、他のシステムの権限管理と併用する場合、このステップにおいては、実行可と判断する代わりに、予めスコープに設定された範囲において実行可とし、他の権限の確認結果と合わせて実行可否を判断してもよい。

【0109】

［第２実装例］
第１実装例では、承認者である第２のユーザに対して承認トークンが発行され、ＡＰＩを実行する第１のユーザに提供された。これに対して、第２実装例では、認証装置１０から第１のユーザに対して、直接、承認トークンが発行される。
なお、本実装例において、第１実装例と同様の構成については同一の符号を付し、説明を省略又は簡略化する。

【0110】

図１１は、第２実装例における認証装置１０の機能構成を示す図である。
認証装置１０の制御部１１は、権限管理部１１１と、認可トークン発行部１１２と、承認トークン発行部１１３ａと、ユーザ決定部１１４とを備える。
第１実装例と比較して、承認トークン発行部１１３ａが変更され、ユーザ決定部１１４が追加されている。

【0111】

ユーザ決定部１１４は、第１のユーザからの要求に応じて、数値範囲の足し合わせが所定の範囲を包含するための権限データが設定された第２のユーザを決定する。
このとき、ユーザ決定部１１４は、例えば、条件を満たすために必要な最小限の数の第２のユーザを決定してもよいし、同一の数値範囲を承認可能な複数の第２のユーザを重複して決定してもよい。
また、ユーザ決定部１４は、第１のユーザからの指定により第２のユーザを決定してもよい。

【0112】

承認トークン発行部は、ユーザ決定部１４により決定された第２のユーザからの要求に応じて、第１のユーザに対して、第２のユーザの権限データに紐づいた承認トークンを発行する。

【0113】

図１２は、第２実装例におけるサービス提供システム１Ｂの処理手順例を示すシーケンス図である。
この例では、第１実装例（図９）と同様に、社員Ａが係長Ｂの承認を得てメールを送信するためのＡＰＩを利用する場合を説明する。

【0114】

ステップＳ４１において、社員Ａ（端末）は、認証装置１０から、メール送信機能に対する権限データＡ１（例えば、［“ｃａｎＳｅｎｄＭａｉｌ”，［０，０．５］］）に紐付いた認可トークンを取得する。

【0115】

ステップＳ４２において、社員Ａは、メールを送信するＡＰＩの実行に必要なメールタイトル、メール送信先、メール本文等を持つ実行案データＸを生成する。
ステップＳ４３において、社員Ａは、実行案データＸ及び権限データＡ１を、認証装置１０に対して送信する。

【0116】

ステップＳ４４において、認証装置１０は、“ｃａｎＳｅｎｄＭａｉｌ”に対する権限データに設定されている数値範囲［０，１］を満たすために、社員Ａから受信した数値範囲［０，０．５］では足りない［０．５，１］を含む権限、すなわち承認権限を有する第２のユーザとして、係長Ｂを決定する。

【0117】

ステップＳ４５において、認証装置１０は、決定した第２のユーザである係長Ｂ（端末）に対して、実行案データＸ及び権限データＡ１を送信すると共に、実行案データＸに対する承認を要求する。

【0118】

ステップＳ４６において、係長Ｂは、実行案データＸ及び権限データＡ１の内容を確認する。
ステップＳ４７において、係長Ｂは、認証装置１０に対して、実行案データＸを承認したことを通知する。

【0119】

ステップＳ４８において、認証装置１０は、実行案データＸ、及び係長Ｂに対して設定されている権限データＢ１に紐づいた承認トークンを生成し、社員Ａに対して送信する。

【0120】

ステップＳ４９において、社員Ａは、認可トークンと承認トークンとを付与して、サービス提供装置２０が提供しているメールを送信するＡＰＩを呼び出す。
以降、サービス提供装置２０は、第１実装例と同様の処理（ステップＳ８～Ｓ１１）を行い、メール送信の機能を実行する。

【0121】

なお、前述の実装例では、権限管理の対象とする機能はＡＰＩで提供されるものとして説明したが、実装の形態はこれには限られない。

【0122】

ユーザの端末間の通信は、直接通信であってよいが、これには限られない。例えば、認証装置１０を経由して通信されてもよいし、別途コミュニケーションサーバが設けられてもよい。

【0123】

機能の実行可否判定の処理について、１つ以上のトークン群から確認結果を返すＡＰＩを認証装置１０が提供し、サービス提供装置２０がこのＡＰＩを呼び出すことで確認結果を得てもよい。

【0124】

また、サービス提供装置２０は、認証装置１０に問い合わせることでトークン群の検証を行えるが、認証装置１０に問い合わせることなく、認可トークン及び承認トークンを検証してもよい。この場合、認証装置１０とサービス提供装置２０との間で、予め共通の鍵情報が設定される。

【0125】

サービス提供装置２０は、複数のトークンを受け付ける構成として説明したが、これには限られない。
例えば、１つのトークンを受け付ける既存の構成と互換性を持たせる場合、複数のトークンを配列として持つトークンがユーザからサービス提供装置２０へ送信される構成であってもよい。この場合、トークンの配列が認証装置１０に渡されて展開された後、認証装置１０がスコープの数値範囲を確認して結果をサービス提供装置２０に返信する。

【0126】

認証装置１０及びサービス提供装置２０は、一体の装置であってもよい。また、それぞれの装置が有する機能部は、複数の装置に分散配置されてもよい。

【0127】

以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、前述した実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、実施形態に記載されたものに限定されるものではない。

【0128】

認証システム１による承認支援方法は、ソフトウェアにより実現される。ソフトウェアによって実現される場合には、このソフトウェアを構成するプログラムが、情報処理装置（コンピュータ）にインストールされる。また、これらのプログラムは、ＣＤ－ＲＯＭのようなリムーバブルメディアに記録されてユーザに配布されてもよいし、ネットワークを介してユーザのコンピュータにダウンロードされることにより配布されてもよい。さらに、これらのプログラムは、ダウンロードされることなくネットワークを介したＷｅｂサービスとしてユーザのコンピュータに提供されてもよい。

【符号の説明】

【0129】

１ 認証システム
１００ 権限管理部
２００ 権限付与部
３００ 表示制御部（承認支援装置）
３１０ 第１取得部
３２０ 第２取得部
３３０ 第３取得部
３４０ 提示部
３５０ 選択部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】