(57)【要約】  複数の利用者に対してサービスを提供するサービス提供システムにおいて、各利用者の利用者端末に対して、所定の処理を実行することの認証を求める認証要求を送信する送信手段と、各利用者の利用者端末から、利用者の署名が付加された認証応答を受信する受信手段と、前記複数の利用者全員についての署名検証に成功した場合に、各利用者に対する前記所定の処理を実行する実行手段とを備える。
2020145163.tif 000002
【特許請求の範囲】
【請求項１】
複数の利用者に対してサービスを提供するサービス提供システムであって、
各利用者の利用者端末に対して、所定の処理を実行することの認証を求める認証要求を送信する送信手段と、
各利用者の利用者端末から、利用者の署名が付加された認証応答を受信する受信手段と、
前記複数の利用者全員についての署名検証に成功した場合に、各利用者に対する前記所定の処理を実行する実行手段と
を備えることを特徴とするサービス提供システム。
【請求項２】
複数の利用者に対してサービスを提供するサービス提供装置であって、
所定の処理を実行することの認証を求める認証要求を受信した各利用者の利用者端末から、利用者の署名が付加された認証応答を受信する受信手段と、
前記複数の利用者全員についての署名検証に成功した場合に、各利用者に対する前記所定の処理を実行するよう、当該所定の処理を実行するシステムに対して実行要求を送信する要求手段と
を備えることを特徴とするサービス提供装置。
【請求項３】
複数の利用者に対してサービスを提供するサービス提供装置であって、
所定の処理を実行することを認証した利用者の署名が付加された署名文を検証したシステムから、各利用者についての確認要求を受信する受信手段と、
前記複数の利用者全員についての前記確認要求を受信した場合に、各利用者に対する前記所定の処理を実行するよう、当該所定の処理を実行する前記システムに対して実行要求を送信する要求手段と
を備えることを特徴とするサービス提供装置。
【請求項４】
前記要求手段は、前記実行要求に、前記サービスの提供者の署名を付加し、当該署名を付加した前記実行要求を前記システムに送信する
請求項２又は３に記載のサービス提供装置。
【請求項５】
複数の利用者に対してサービスを提供するサービス提供システムが実行するサービス提供方法であって、
各利用者の利用者端末に対して、所定の処理を実行することの認証を求める認証要求を送信する送信ステップと、
各利用者の利用者端末から、利用者の署名が付加された認証応答を受信する受信ステップと、
前記複数の利用者全員についての署名検証に成功した場合に、各利用者に対する前記所定の処理を実行する実行ステップと
を備えることを特徴とするサービス提供方法。
【請求項６】
コンピュータを、請求項１に記載のサービス提供システムにおける各手段として機能させるためのプログラム。
【請求項７】
コンピュータを、請求項２又は３に記載のサービス提供装置における各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の利用者にサービスを提供するサービス提供システムに関連するものである。
【背景技術】
【０００２】
近年、Ｆｉｎｔｅｃｈが注目されており、特に金融機関への更新情報を開放するために、オープンＡＰＩの推進・アクセス認可の標準仕様「ＯＡｕｔｈ」（非特許文献１参照）の策定が進められている。ＯＡｕｔｈは権限の認可を行うためのオープンスタンダードであり、広く使われる標準を見据えて、大枠でのプロトコルが定められている。【０００３】
現在、金融取引における更新系操作では、ＯＡｕｔｈによる認可処理後に、銀行が直接利用者に取引認証を求めている。また更新系操作において、利用者端末・金融サービス提供者の乗っ取りに関する考察がされており、そこでは二要素認証による解決が示唆されている。【０００４】
一方、今後クラウドファンディングや割り勘アプリ等の多人数が寄与する取引が金融サービス提供者を介して行われる可能性がある。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】The OAuth 2.0 Authorization Framework, https://tools.ietf.org/html/rfc6749
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したように、ＯＡｕｔｈの認可プロトコルに沿った取引認証（認可者の介在するプロトコル）では、金融機関（銀行等）が最終確認として、利用者に更新確認を行う。【０００７】
しかし、多人数が寄与する取引認証において、上記のような更新確認を行うと個々人で認証の可否が異なった場合に、全体の一連の取引処理の不可分性が失われる。認証の可否が全員で一致した状態で、そのことが銀行に改ざんなく伝わる必要があるが、従来技術では、これを実現する手段はない。なお、このような課題は、金融サービスに限られずに生じ得る課題である。【０００８】
本発明は上記の点に鑑みてなされたものであり、複数の利用者にサービスを提供する際に、複数の利用者全員の認証結果が一致した場合にのみ、処理を実行することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
開示の技術によれば、複数の利用者に対してサービスを提供するサービス提供システムであって、
各利用者の利用者端末に対して、所定の処理を実行することの認証を求める認証要求を送信する送信手段と、
各利用者の利用者端末から、利用者の署名が付加された認証応答を受信する受信手段と、
前記複数の利用者全員についての署名検証に成功した場合に、各利用者に対する前記所定の処理を実行する実行手段と
を備えることを特徴とするサービス提供システムが提供される。
【発明の効果】
【００１０】
開示の技術によれば、複数の利用者にサービスを提供する際に、複数の利用者全員の認証結果が一致した場合にのみ、処理を実行することを可能とする技術が提供される。
【図面の簡単な説明】
【００１１】
【図１】ＯＡｕｔｈを用いた従来の処理の流れを説明するための図である。
【図２】本発明の実施の形態の概要を説明するための図である。
【図３】本発明の実施の形態におけるシステム構成を示す図である。
【図４】利用者端末１００の構成図である。
【図５】金融系サービス提供者装置２００の構成図である。
【図６】銀行サーバ３００の構成図である。
【図７】装置のハードウェア構成の例を示す図である。
【図８】実施例１−１におけるシーケンス図である。
【図９】実施例１−２におけるシーケンス図である。
【図１０】実施例１−３におけるシーケンス図である。
【図１１】実施例２におけるシーケンス図である。
【図１２】実施例３におけるシーケンス図である。
【図１３】実施例４におけるシーケンス図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照して本発明の実施の形態を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
【００１３】
例えば、以下で説明するように、本実施の形態では、ＯＡｕｔｈに基づく処理を説明しているが、本発明はＯＡｕｔｈを利用しない方式にも適用可能である。また、本実施の形態では、一例として、金融系サービスに本発明を適用する例を説明しているが、本発明は、金融系サービスに限らず、複数の利用者にサービスを提供する様々な分野のサービスに適用可能である。また、以下で説明する「認証」は「承認」に置き換えてもよい。
【００１４】
（ＯＡｕｔｈを用いた処理の概要）
本実施の形態では、ＯＡｕｔｈを用いていることから、ＯＡｕｔｈを用いた処理の概要として、まず、ＯＡｕｔｈによる認可後に銀行が利用者に更新確認（署名）を求める処理（従来技術）について図１を参照して説明する。
【００１５】
非特許文献１に開示されたＯＡｕｔｈ２．０（以下、ＯＡｕｔｈと記載）では、リソースオーナー、クライアント、リソースサーバ、認可サーバからなる４種類のロールを想定している。本実施の形態で想定している金融系サービスでは、リソースオーナーは、金融系サービスの利用者に該当し、クライアントは、金融系サービス提供者に該当し、リソースサーバ及び認可サーバは、銀行（あるいはその他の金融機関）に該当する。
【００１６】
図１において、シーケンスの各ステップは、括弧内の文字で識別されている。例えば、（Ａ）はステップＡである。以降で説明する各シーケンス図においても同様である。また、図１の例では、銀行サーバが、リソースサーバの機能及び認可サーバの機能を含む。
【００１７】
図１のステップＡにおいて、金融系サービス提供者が利用者に対してＡｕｔｈｏｒｉｚａｔｉｏｎ  Ｒｅｑｕｅｓｔ（認可リクエスト）を送信する。Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｒｅｑｕｅｓｔは、リソースサーバへのアクセスをクライアントに許可することをリソースオーナに確認するためのメッセージである。
【００１８】
ステップＢにおいて、利用者はＡｕｔｈｏｒｉｚａｔｉｏｎ  Ｇｒａｎｔ（認可認証）を金融系サービス提供者に送信し、ステップＣにおいて、金融系サービス提供者は、Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｃｏｄｅ（認可コード）を銀行サーバに送信する。
【００１９】
ステップＤにおいて、銀行サーバは金融系サービス提供者に対してＡｃｃｅｓｓ  Ｔｏｋｅｎ（アクセストークン）を送信し、ステップＥにおいて、金融系サービス提供者は、Ａｃｃｅｓｓ  Ｔｏｋｅｎを用いてリソースサーバにアクセスし、金融系サービスにおいて必要な処理（例：口座からの引き落とし）を実行するよう要求する。
【００２０】
ステップＦにおいて、銀行サーバは署名要求を利用者に送り、ステップＧにおいて、利用者は署名を付加した文を署名応答として銀行サーバに送信する。銀行サーバは、署名を検証することで、利用者の更新確認（利用者のリソース（口座等）が更新されることの認証）がとれたことを確認し、要求された処理を実行し、ステップＨにおいて、Ｐｒｏｔｅｃｔｅｄ  Ｒｅｓｏｕｒｃｅ（処理を実行したことの報告）を金融系サービス提供者に送信する。
【００２１】
本実施の形態において想定している割り勘アプリ等の複数人が関与する金融系サービスにおいては、複数人の全員の認証結果がＯＫにならなければ、サービスとして完結しないので、複数人の全員の認証結果を確認する必要がある。しかし、上記の従来技術では、個々の利用者についての認証結果を確認できるだけで、複数人の全員の認証結果がＯＫになったかどうかを確認した上での処理を行うことができない。
【００２２】
（実施の形態の概要）
上記の課題を解決するために、本実施の形態では、全員の取引を把握している金融系サービス提供者を通信の終端として、金融系サービス提供者が全員の認証結果を確認することとしている。また、金融系サービス提供者が署名を打つことで、全体の取引に関する責任を金融系サービス提供者が持つことを明確にするようにしてもよい。
【００２３】
上記を実現するための処理の例として、実施例１（具体的には実施例１−１〜１−３）、実施例２、実施例３、実施例４がある。これらの実施例におけるシーケンスは、図２に示すように、ＯＡｕｔｈプロトコルの途中に位置する。実施例１〜４の詳細シーケンスについては後述する。
【００２４】
（システム・装置の構成）
図３に、本実施の形態における金融系サービス提供システムの全体構成図を示す。図３に示すとおり、本システムは、ｎ台の利用者端末１００（１〜ｎ）、金融系サービス提供者装置２００、銀行認可サーバ３１０、銀行リソースサーバ３２０を備え、これらの装置がネットワーク４００に接続される。なお、実施例４で説明するように、取引認証サーバ３３０がネットワーク４００に接続されていてもよい。
【００２５】
なお、銀行認可サーバ３１０と銀行リソースサーバ３２０とを分けずに、銀行認可サーバ３１０の機能と銀行リソースサーバ３２０の機能を含む銀行サーバ３００を備えてもよい。また、銀行認可サーバ３１０、銀行リソースサーバ３２０、及び銀行サーバ３００はいずれも利用者毎に異なってもよい。つまり、銀行認可サーバ３１０、銀行リソースサーバ３２０、及び銀行サーバ３００はそれぞれ複数台であってもよい。
【００２６】
図３に示す利用者端末１００、金融系サービス提供者装置２００、銀行認可サーバ３１０と銀行リソースサーバ３２０の組（あるいは銀行サーバ３００）がそれぞれ、図１、２に示した利用者、金融系サービス提供者、銀行サーバに相当する。
【００２７】
利用者端末１００はｎ台存在するが、これは、本実施の形態で想定する複数人が関与する金融系サービスを利用する当該複数人（ｎ人）の端末に相当する。つまり、本実施の形態で、全員が認証可（認証ＯＫ）であるとは、ｎ台全ての利用者端末１００から送られた署名の検証結果がＯＫであることを意味する。各利用者端末１００は、例えば、ＰＣ、スマートフォン、タブレット等である。
【００２８】
なお、図３で示した構成は一例に過ぎない。例えば、銀行側の装置（銀行認可サーバ３１０、銀行リソースサーバ３２０、あるいは銀行サーバ３００等）に金融系サービス提供者装置２００における全部の機能又は一部の機能（全員認証の確認機能等）を備えてもよい。逆に、銀行側の装置（銀行認可サーバ３１０、銀行リソースサーバ３２０、あるいは銀行サーバ３００等）の機能の全部又は一部（例えば、取引処理（所定の処理）の実行機能）を金融系サービス提供者装置２００に備えてもよい。また、各装置において、署名を検証する機能を外部に別装置として備えてもよい。また、金融系サービス提供者装置２００において、全員認証を確認する機能を外部に別装置として備えてもよい。また、銀行認可サーバ３１０と銀行リソースサーバ３２０からなる構成、あるいは銀行サーバ３００を「システム」と称してもよい。
【００２９】
図４は、利用者端末１００の構成図である。図４に示すように、利用者端末１００は、認可要求処理部１１０、及び署名処理部１２０を備える。図５は、金融系サービス提供者装置２００の構成図である。図５に示すように、金融系サービス提供者装置２００は、アクセス処理部２１０、及び全員可否確認部２２０を備える。図６は、銀行サーバ３００の構成図である。図６に示すように、銀行サーバ３００は、アクセス処理部３５０、署名処理部３６０を有する。
【００３０】
上記の各機能部（及び銀行認可サーバ３１０、銀行リソースサーバ３２０）の動作については、後述する各実施例の説明において、これらの機能部（及び銀行認可サーバ３１０、銀行リソースサーバ３２０）を用いて説明する。
【００３１】
なお、実施例によっては、使用しない機能部が存在する。各実施例において、使用しない機能部については、該当装置の中に備えないこととしてもよい。
【００３２】
（ハードウェア構成例）
本実施の形態における各装置（利用者端末１００、金融系サービス提供者装置２００、銀行サーバ３００、銀行認可サーバ３１０、銀行リソースサーバ３２０、取引認証サーバ３３０等）は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。なお、この「コンピュータ」は、クラウドサービスにより提供される仮想マシンであってもよい。仮想マシンを使用する場合、ここで説明する「ハードウェア」とは仮想的なハードウェアである。
【００３３】
当該装置は、コンピュータに内蔵されるＣＰＵ（Central Processing Unit）やメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。なお、ＣＰＵをプロセッサと称してもよい。また、本明細書における「手段」を、「回路」又は「部」に置き換えてもよい。
【００３４】
図７は、本実施の形態における上記コンピュータのハードウェア構成例を示す図である。図７のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、及び入力装置１００７等を有する。
【００３５】
当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００３６】
メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。
【００３７】
以下、実施例１−１〜実施例１−３、実施例２、実施例３、実施例４を詳細に説明する。なお、各実施例のシーケンスにおけるステップＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｈについては、図１で説明したＯＡｕｔｈを用いた処理におけるステップＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｈと基本的に同じであるので、これらのステップの説明は簡単なものとしている。
【００３８】
また、各実施例において、ｎ台ある利用者端末１００はそれぞれ同様の処理を行うので、各実施例では、１つの利用者端末１００についてのシーケンスを示している。また、銀行サーバ３００、銀行認可サーバ３１０、銀行リソースサーバ３２０についても複数台が存在し得、それぞれ同様の処理を行うので、各実施例では、それぞれ１つに関してのシーケンスを示している。
【００３９】
まず、実施例１として、実施例１−１〜実施例１−３を説明する。実施例１では、利用者と金融系サービス提供者との間の通信で全体の取引認証を完結させることとしている。
【００４０】
（実施例１−１）
図８は、実施例１−１におけるシーケンス図である。利用者端末１００の認可要求処理部１１０及び金融系サービス提供者装置２００のアクセス処理部２１０によりステップＡ、Ｂが実行された後、ステップＭ−１において、金融系サービス提供者装置２００の全員可否確認部２２０は、利用者端末１００に対して、署名要求（認証要求と呼んでも良い）を送信する。この署名要求は、例えば、その利用者の口座から支払いを行ってよいかの認証を求める文（"署名対象文"と呼ぶ）である。
【００４１】
ステップＭ−２において、利用者端末１００において署名対象文が表示され、これを見た利用者による操作（例：確認ボタンをタッチ）により、利用者端末１００の署名処理部１２０が署名を計算し、当該署名を署名対象文に付加する。署名が付加された署名対象文を署名文と呼ぶ。
【００４２】
ステップＭ−３において、利用者端末１００の署名処理部１２０は、署名文を署名応答（認証応答と呼んでもよい）として金融系サービス提供者装置２００に送信する。
【００４３】
ステップＭ−４において、金融系サービス提供者装置２００の全員可否確認部２２０は、利用者端末１００から受信した署名文の署名を検証し、検証に成功すれば、当該利用者は、この取引を認証したことを確認できる。
【００４４】
ステップＡからステップＭ−３までの処理が、ｎ台ある利用者端末１００のそれぞれにより行われ、ステップＭ−４において、全員可否確認部２２０は、全員の利用者についての認証結果がＯＫであることを確認すると、各利用者についての確認応答に金融系サービス提供者の署名を付加する。ここでの署名を付加することは必須ではなく、ここでの署名を付加しないこととしてもよい。なお、ｎ台の利用者端末１００のうち、ステップＭ−３までの処理を実行しない端末が１つでもある場合には、全員の認証結果がＯＫにならない。
【００４５】
上記の「確認応答」は、例えば、利用者から受信した署名文である。この場合、金融系サービス提供者の署名を付加する場合には、それぞれの利用者から受信した署名文に当該署名を付加する。
【００４６】
ステップＭ−５において、金融系サービス提供者装置２００の全員可否確認部２２０は、各利用者について、金融系サービス提供者の署名が付された確認応答（利用者の署名文）を、当該利用者が利用する銀行の銀行サーバ３００に送信する。
【００４７】
ステップＭ−６において、銀行サーバ３００の署名処理部３６０は、金融系サービス提供者の署名を検証することで、利用者全員が認証した上で、当該利用者の取引が認証されたことを確認できる。なお、金融系サービス提供者の署名が付されない場合、銀行サーバ３００は、確認応答を受信したことでもって、利用者全員が取引を認証した上で、当該利用者の取引が認証されたことを確認する。
【００４８】
その後、各利用者に関して、銀行サーバ３００のアクセス処理部３５０と金融系サービス提供者装置２００のアクセス処理部２１０との間で、ステップＤ、Ｅ、Ｈが実行される。
【００４９】
なお、確認応答の受信に基づいて、銀行サーバ３００（他の実施例では、銀行認可サーバ３１０又は銀行リソースサーバ３２０）は所定の処理（口座からの引き落とし等）を実行するので、確認応答を実行要求と称してもよい。他の実施例でも同様である。
【００５０】
（実施例１−２）
図９は、実施例１−２におけるシーケンス図である。実施例１−２は、実施例１−１の銀行サーバ３００を、銀行認可サーバ３１０と銀行リソースサーバに置き換えた例である。
【００５１】
実施例１−２において、ステップＡ〜ステップＭ−４は、実施例１−１のステップＡ〜ステップＭ−４と同じである。
【００５２】
ステップＭ−５において、金融系サービス提供者装置２００の全員可否確認部２２０は、各利用者について、金融系サービス提供者の署名が付された確認応答（利用者の署名文）を、当該利用者が利用する銀行の銀行認可サーバ３１０に送信する。
【００５３】
ステップＭ−６において、銀行認可サーバ３１０は、金融系サービス提供者の署名を検証することで、利用者全員が取引を認証した上で、当該利用者の取引が認証されたことを確認できる。なお、金融系サービス提供者の署名が付されない場合、銀行認可サーバ３１０は、確認応答を受信したことでもって、利用者全員が取引を認証した上で、当該利用者の取引が認証されたことを確認する。
【００５４】
その後、各利用者に関して、ステップＤで銀行認可サーバ３１０がＡｃｃｅｓｓ  Ｔｏｋｅｎを金融系サービス提供者装置２００のアクセス処理部２１０に送信し、金融系サービス提供者装置２００のアクセス処理部２１０と銀行リソースサーバ３２０との間でステップＥ、Ｈが実行される。また、例えば銀行リソースサーバ３２０が、所定の処理を実行する。
【００５５】
（実施例１−３）
図１０は、実施例１−３におけるシーケンス図である。実施例１−３は、実施例１−２におけるステップＭ−６（署名検証）を銀行リソースサーバ３２０が実行するようにした例である。
【００５６】
実施例１−３において、ステップＡ〜ステップＭ−５は、実施例１−２のステップＡ〜ステップＭ−５と同じである。
【００５７】
実施例１−３では、ステップＭ−５の後、各利用者について、ステップＤ、Ｅ、Ｍ−６、Ｈが実行される。
【００５８】
ステップＤにおいて、銀行認可サーバ３１０は、ステップＭ−５で受信した金融系サービス提供者の署名（あるいは、当該署名を付加した確認応答、又は、当該署名を付加しない場合は確認応答のみ）をＡｃｃｅｓｓ  Ｔｏｋｅｎに含め、当該署名を含めたＡｃｃｅｓｓ  Ｔｏｋｅｎを金融系サービス提供者装置２００のアクセス処理部２１０に送信する。ステップＥにおいて、金融系サービス提供者装置２００のアクセス処理部２１０は、当該Ａｃｃｅｓｓ  Ｔｏｋｅｎを銀行リソースサーバ３２０に送信する。
【００５９】
ステップＭ−６において、銀行リソースサーバ３２０は、Ａｃｃｅｓｓ  Ｔｏｋｅｎに含まれる金融系サービス提供者の署名を検証することで、利用者全員が取引を認証した上で、当該利用者の取引が認証されたことを確認できる。なお、金融系サービス提供者の署名が付されない場合、銀行リソースサーバ３２０は、Ａｃｃｅｓｓ  Ｔｏｋｅｎに含まれる確認応答を受信したことでもって、利用者全員が取引を認証した上で、当該利用者の取引が認証されたことを確認する。
【００６０】
ステップＨにおいて、銀行リソースサーバ３２０は、Ｐｒｏｔｅｃｔｅｄ  Ｒｅｓｏｕｒｃｅを金融系サービス提供者装置２００に送信する。また、例えば銀行リソースサーバ３２０が、所定の処理を実行する。
【００６１】
（実施例２）
次に、実施例２を説明する。図１１は、実施例２におけるシーケンス図である。実施例２においては、銀行側の処理を「銀行認可サーバ３１０又は銀行リソースサーバ３２０」が実行する。すなわち、実施例２において、銀行側の各処理は銀行認可サーバ３１０と銀行リソースサーバ３２０のどれが行ってもよい。なお、実施例２において、「銀行認可サーバ３１０又は銀行リソースサーバ３２０」を銀行サーバ３００に置き換えてもよい。
【００６２】
図１１に示すように、利用者端末１００の認可要求処理部１１０及び金融系サービス提供者装置２００のアクセス処理部２１０によりステップＡ、Ｂが実行された後、金融系サービス提供者装置２００のアクセス処理部２１０と「銀行認可サーバ３１０又は銀行リソースサーバ３２０」との間でステップＣ、Ｄ、Ｅが実行される。
【００６３】
ステップＭ−１において、「銀行認可サーバ３１０又は銀行リソースサーバ３２０」は、利用者端末１００に対して、署名要求を送信する。この署名要求は、例えば、その利用者の口座から支払いを行ってよいかの確認を求める文（"署名対象文"と呼ぶ）である。
【００６４】
ステップＭ−２において、利用者端末１００において署名対象文が表示され、これを見た利用者による操作（例：確認ボタンをタッチ）により、利用者端末１００の署名処理部１２０が署名を計算し、当該署名を署名対象文に付加する。署名が付加された署名対象文を署名文と呼ぶ。
【００６５】
ステップＭ−３において、利用者端末１００の署名処理部１２０は、署名文を署名応答として「銀行認可サーバ３１０又は銀行リソースサーバ３２０」に送信する。
【００６６】
ステップＭ−４において、「銀行認可サーバ３１０又は銀行リソースサーバ３２０」は、署名文の署名を検証し、検証成功であれば、当該利用者は、この取引を認証したことを確認できる。ステップＭ−５において確認要求を金融系サービス提供者装置２００の全員可否確認部２２０に送信する。ステップＭ−５における確認要求は、例えば、検証に成功した利用者の署名文であるが、これに限られず、利用者を識別できる情報であればよい。
【００６７】
ステップＡからステップＭ−５までの処理が、ｎ台ある利用者端末１００のそれぞれにより行われ、ステップＭ−６において、全員可否確認部２２０は、全員の利用者について確認要求を受信したこと（つまり、認証結果がＯＫであること）を確認すると、ステップＭ−７において、各利用者についての確認応答を、当該利用者が利用する銀行の「銀行認可サーバ３１０又は銀行リソースサーバ３２０」に送信する。
【００６８】
各利用者について、確認応答を受信した「銀行認可サーバ３１０又は銀行リソースサーバ３２０」は、当該利用者についての所定の処理を実行し、ステップＨにおいて、Ｐｒｏｔｅｃｔｅｄ  Ｒｅｓｏｕｒｃｅを金融系サービス提供者装置２００に送信する。
【００６９】
なお、実施例２においても、ステップＭ−７において、金融系サービス提供者の署名を確認応答に付して送信し、「銀行認可サーバ３１０又は銀行リソースサーバ３２０」において、当該署名を検証することとしてもよい。
【００７０】
（実施例３）
次に、実施例３を説明する。図１２は、実施例３におけるシーケンス図である。実施例３においては、実施例２と同様に、銀行側の処理を「銀行認可サーバ３１０又は銀行リソースサーバ３２０」が実行する。すなわち、実施例３において、銀行側の各処理は銀行認可サーバ３１０と銀行リソースサーバ３２０のどれが行ってもよい。なお、実施例３において、「銀行認可サーバ３１０又は銀行リソースサーバ３２０」を銀行サーバ３００に置き換えてもよい。
【００７１】
図１２に示すように、利用者端末１００の認可要求処理部１１０及び金融系サービス提供者装置２００のアクセス処理部２１０によりステップＡ、Ｂが実行された後、金融系サービス提供者装置２００のアクセス処理部２１０と「銀行認可サーバ３１０又は銀行リソースサーバ３２０」との間でステップＣ、Ｄ、Ｅが実行される。
【００７２】
ステップＭ−１において、「銀行認可サーバ３１０又は銀行リソースサーバ３２０」は、利用者端末１００に対して、署名要求を送信する。この署名要求は、例えば、その利用者の口座から支払いを行ってよいかの確認を求める文（"署名対象文"と呼ぶ）である。
【００７３】
ステップＭ−２において、利用者端末１００において署名対象文が表示され、これを見た利用者による操作（例：確認ボタンをタッチ）により、利用者端末１００の署名処理部１２０が署名を計算し、当該署名を署名対象文に付加する。署名が付加された署名対象文を署名文と呼ぶ。
【００７４】
ステップＭ−３において、利用者端末１００の署名処理部１２０は、署名文を署名応答として金融系サービス提供者装置２００に送信する。
【００７５】
ステップＭ−４において、金融系サービス提供者装置２００の全員可否確認部２２０は、利用者端末１００から受信した署名文の署名を検証し、検証に成功すれば、当該利用者は、この取引を認証したことを確認できる。
【００７６】
ステップＡからステップＭ−３までの処理が、ｎ台ある利用者端末１００のそれぞれにより行われ、ステップＭ−４において、全員可否確認部２２０は、全員の利用者についての認証結果がＯＫであることを確認すると、各利用者についての確認応答に金融系サービス提供者の署名を付加する。なお、ここでの署名を付加することは必須ではなく、ここでの署名を付加しないこととしてもよい。なお、ｎ台の利用者端末１００のうち、ステップＭ−３までの処理を実行しない端末が１つでもある場合には、全員の認証結果がＯＫにならない。
【００７７】
上記の「確認応答」は、利用者から受信した署名文である。この場合、金融系サービス提供者の署名を付加する場合には、それぞれの利用者から受信した署名文に当該署名を付加する。
【００７８】
ステップＭ−５において、金融系サービス提供者装置２００の全員可否確認部２２０は、各利用者について、金融系サービス提供者の署名が付された確認応答（利用者の署名文）を、当該利用者が利用する銀行の銀行サーバ３００に送信する。
【００７９】
ステップＭ−６において、「銀行認可サーバ３１０又は銀行リソースサーバ３２０」は、金融系サービス提供者の署名を検証することで、利用者全員が認証した上で、当該利用者の取引が認証されたことを確認できる。なお、金融系サービス提供者の署名が付されない場合、「銀行認可サーバ３１０又は銀行リソースサーバ３２０」は、確認応答を受信したことでもって、利用者全員が取引を認証した上で、当該利用者の取引が認証されたことを確認する。
【００８０】
各利用者について、確認応答を検証した「銀行認可サーバ３１０又は銀行リソースサーバ３２０」は、当該利用者についての所定の処理を実行し、ステップＨにおいて、Ｐｒｏｔｅｃｔｅｄ  Ｒｅｓｏｕｒｃｅを金融系サービス提供者装置２００に送信する。
【００８１】
（実施例４）
次に、実施例４を説明する。実施例４は、実施例３における「銀行認可サーバ３１０又は銀行リソースサーバ３２０」の取引認証を行なう機能を取引認証サーバ３３０として外部に切り出した構成を採用している。図１３は、実施例４におけるシーケンス図である。
【００８２】
図１３に示すように、利用者端末１００の認可要求処理部１１０及び金融系サービス提供者装置２００のアクセス処理部２１０によりステップＡ、Ｂが実行された後、金融系サービス提供者装置２００のアクセス処理部２１０と「銀行認可サーバ３１０又は銀行リソースサーバ３２０」との間でステップＣ、Ｄ、Ｅが実行される。
【００８３】
ステップＭ−０において、「銀行認可サーバ３１０又は銀行リソースサーバ３２０」は、取引認証サーバ３３０に認証要求を送信する。ステップＭ−１において、取引認証サーバ３３０は、利用者端末１００に対して、署名要求を送信する。この署名要求は、例えば、その利用者の口座から支払いを行ってよいかの確認を求める文（"署名対象文"と呼ぶ）である。
【００８４】
ステップＭ−２において、利用者端末１００において署名対象文が表示され、これを見た利用者による操作（例：確認ボタンをタッチ）により、利用者端末１００の署名処理部１２０が署名を計算し、当該署名を署名対象文に付加する。署名が付加された署名対象文を署名文と呼ぶ。
【００８５】
ステップＭ−３において、利用者端末１００の署名処理部１２０は、署名文を署名応答として金融系サービス提供者装置２００に送信する。
【００８６】
ステップＭ−４において、金融系サービス提供者装置２００の全員可否確認部２２０は、利用者端末１００から受信した署名文の署名を検証し、検証に成功すれば、当該利用者は、この取引を認証したことを確認できる。
【００８７】
ステップＡからステップＭ−３までの処理が、ｎ台ある利用者端末１００のそれぞれにより行われ、ステップＭ−４において、全員可否確認部２２０は、全員の利用者についての認証結果がＯＫであることを確認すると、各利用者についての確認応答に金融系サービス提供者の署名を付加する。なお、ここでの署名を付加することは必須ではなく、ここでの署名を付加しないこととしてもよい。なお、ｎ台の利用者端末１００のうち、ステップＭ−３までの処理を実行しない端末が１つでもある場合には、全員の認証結果がＯＫにならない。
【００８８】
上記の「確認応答」は、利用者から受信した署名文である。この場合、金融系サービス提供者の署名を付加する場合には、それぞれの利用者から受信した署名文に当該署名を付加する。
【００８９】
ステップＭ−５において、金融系サービス提供者装置２００の全員可否確認部２２０は、各利用者について、金融系サービス提供者の署名が付された確認応答（利用者の署名文）を、取引認証サーバ３３０に送信する。
【００９０】
ステップＭ−６において、取引認証サーバ３３０は、金融系サービス提供者の署名を検証することで、利用者全員が認証した上で、当該利用者の取引が認証されたことを確認できる。ステップＭ−７において、取引認証サーバ３３０は、認証結果を「銀行認可サーバ３１０又は銀行リソースサーバ３２０」に送信する。
【００９１】
各利用者について、認証結果を受信した「銀行認可サーバ３１０又は銀行リソースサーバ３２０」は、当該利用者についての所定の処理を実行し、ステップＨにおいて、Ｐｒｏｔｅｃｔｅｄ  Ｒｅｓｏｕｒｃｅを金融系サービス提供者装置２００に送信する。
【００９２】
（実施の形態の効果等）
各実施例で説明した本実施の形態の技術によれば、複数人（特に多人数）が関与する処理において、利用者による認証結果が全員一致した場合にのみ、当該処理を実施することが可能となる。
【００９３】
例えば、多人数の全員が支払い等の取引を行う必要のある金融系サービス（例えば割り勘サービス等）において、「全員が取引をしない」または「全員が取引する」のどちらかを金融系サービス提供者が確認することが可能となる。これにより、例えば銀行は全員の取引が保証された取引認証を行うことが可能になる。
【００９４】
なお、実施例１、３、４では、金融サービス提供者の確認フェーズにおいて、金融サービス提供者が署名を行うことで、上記の保証を署名の形で残すことができる。
【００９５】
（実施の形態のまとめ）
以上、実施例１〜４を用いて説明した実施の形態には、少なくとも、下記の第１項〜第７項の構成が含まれる。
（第１項）
複数の利用者に対してサービスを提供するサービス提供システムであって、
各利用者の利用者端末に対して、所定の処理を実行することの認証を求める認証要求を送信する送信手段と、
各利用者の利用者端末から、利用者の署名が付加された認証応答を受信する受信手段と、
前記複数の利用者全員についての署名検証に成功した場合に、各利用者に対する前記所定の処理を実行する実行手段と
を備えることを特徴とするサービス提供システム。
（第２項）
複数の利用者に対してサービスを提供するサービス提供装置であって、
所定の処理を実行することの認証を求める認証要求を受信した各利用者の利用者端末から、利用者の署名が付加された認証応答を受信する受信手段と、
前記複数の利用者全員についての署名検証に成功した場合に、各利用者に対する前記所定の処理を実行するよう、当該所定の処理を実行するシステムに対して実行要求を送信する要求手段と
を備えることを特徴とするサービス提供装置。
（第３項）
複数の利用者に対してサービスを提供するサービス提供装置であって、
所定の処理を実行することを認証した利用者の署名が付加された署名文を検証したシステムから、各利用者についての確認要求を受信する受信手段と、
前記複数の利用者全員についての前記確認要求を受信した場合に、各利用者に対する前記所定の処理を実行するよう、当該所定の処理を実行する前記システムに対して実行要求を送信する要求手段と
を備えることを特徴とするサービス提供装置。
（第４項）
前記要求手段は、前記実行要求に、前記サービスの提供者の署名を付加し、当該署名を付加した前記実行要求を前記システムに送信する
第２項又は第３項に記載のサービス提供装置。
（第５項）
複数の利用者に対してサービスを提供するサービス提供システムが実行するサービス提供方法であって、
各利用者の利用者端末に対して、所定の処理を実行することの認証を求める認証要求を送信する送信ステップと、
各利用者の利用者端末から、利用者の署名が付加された認証応答を受信する受信ステップと、
前記複数の利用者全員についての署名検証に成功した場合に、各利用者に対する前記所定の処理を実行する実行ステップと
を備えることを特徴とするサービス提供方法。
（第６項）
コンピュータを、第１項に記載のサービス提供システムにおける各手段として機能させるためのプログラム。
（第７項）
コンピュータを、第２項又は第３項に記載のサービス提供装置における各手段として機能させるためのプログラム。
【００９６】
以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【００９７】
本特許出願は２０１９年１月１１日に出願した日本国特許出願第２０１９−００３６２２号に基づきその優先権を主張するものであり、日本国特許出願第２０１９−００３６２２号の全内容を本願に援用する。
【符号の説明】
【００９８】
１００  利用者端末
１１０  認可要求処理部
１２０  署名処理部
２００  金融系サービス提供者装置
２１０  アクセス処理部
２２０  全員可否確認部
３００  銀行サーバ
３１０  銀行認可サーバ
３２０  銀行リソースサーバ
３３０  取引認証サーバ
３５０  アクセス処理部
３６０  署名処理部
４００  ネットワーク
【図１】
2020145163.tif 000003
【図２】
2020145163.tif 000004
【図３】
2020145163.tif 000005
【図４】
2020145163.tif 000006
【図５】
2020145163.tif 000007
【図６】
2020145163.tif 000008
【図７】
2020145163.tif 000009
【図８】
2020145163.tif 000010
【図９】
2020145163.tif 000011
【図１０】
2020145163.tif 000012
【図１１】
2020145163.tif 000013
【図１２】
2020145163.tif 000014
【図１３】
2020145163.tif 000015
【国際調査報告】
2020145163.tif 000016
2020145163.tif 000017
2020145163.tif 000018
2020145163.tif 000019