(57)【要約】【課題】料金の支払い方法が決まっているサービスをその方法で料金を支払えないユーザに提供するための依頼をすること。【解決手段】判定手段１０１は、特定の支払い方法で料金を支払う有料のサービスを利用する利用ユーザがその特定方法でそのサービス料金を支払えるか否かを判定する。決定手段１０２は、料金の支払いを依頼する相手である依頼ユーザを決定する。詳細には、決定手段１０２は、前述の依頼に影響を与え得る影響情報に基づいて、依頼ユーザの候補となる候補ユーザから依頼ユーザを決定する。送信手段１０３は、判定手段１０１によりサービス料金が支払えないと判定された場合に、決定手段１０２により決定された依頼ユーザに対応する宛先に、依頼の内容を示す依頼データを送信する。【選択図】図３
2015011608.tif 000002
【特許請求の範囲】
【請求項１】
特定の支払い方法で料金を支払う有料のサービスを利用する利用ユーザが当該支払い方法で当該サービスの料金を支払えるか否かを判定する判定手段と、
前記判定手段により支払えないと判定された場合に、当該料金の支払いを依頼する相手である依頼ユーザに対応する宛先に、当該依頼の内容を示す依頼データを送信する送信手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記依頼に影響を与え得る影響情報に基づいて、前記依頼ユーザの候補となる候補ユーザから当該依頼ユーザを決定する決定手段を備え、
前記送信手段は、前記決定手段により決定された依頼ユーザに対応する宛先に、前記依頼データを送信する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記決定手段は、前記候補ユーザの属性を前記影響情報として前記決定を行う
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記決定手段は、前記利用ユーザ及び前記候補ユーザの交流の履歴を前記影響情報として前記決定を行う
ことを特徴とする請求項２または３に記載の情報処理装置。
【請求項５】
前記決定手段は、前記支払い方法における前記候補ユーザの支払い能力を前記影響情報として前記決定を行う
ことを特徴とする請求項２から４までのいずれか１項に記載の情報処理装置。
【請求項６】
前記決定手段は、ネットワークを介して利用するサービスの前記候補ユーザの利用状態を前記影響情報として前記決定を行う
ことを特徴とする請求項２から５までのいずれか１項に記載の情報処理装置。
【請求項７】
前記決定手段は、前記候補ユーザが前記依頼の承諾の可否を表明している場合に、当該表明した内容を前記影響情報として前記決定を行う
ことを特徴とする請求項２から６までのいずれか１項に記載の情報処理装置。
【請求項８】
前記送信手段により前記依頼データが送信された前記依頼ユーザによる前記サービスの料金の支払いの状況を示す状況情報を取得する取得手段を備え、
前記決定手段は、前記送信手段により前記依頼データが送信されてから決められた時間が経過するまでに前記取得手段により前記サービスの料金が支払われたことを示す状況情報が取得されない場合には、別の依頼ユーザを決定し、
前記送信手段は、前記決定手段により別の依頼ユーザが決定された場合には、当該別の依頼ユーザに対応する宛先に前記依頼データを送信する
ことを特徴とする請求項２から７までのいずれか１項に記載の情報処理装置。
【請求項９】
前記取得手段により取得された前記サービスの料金の支払いの状況を前記利用ユーザに通知する通知手段を備える
ことを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
前記送信手段は、前記利用ユーザ及び前記依頼ユーザがともに利用可能な支払い方法がある場合に、当該利用ユーザが前記サービスの料金を当該支払い方法で当該依頼ユーザに支払うための支払いデータを、当該支払い方法に対応する宛先に送信する
ことを特徴とする請求項２から９までのいずれか１項に記載の情報処理装置。
【請求項１１】
前記利用ユーザ及び前記依頼ユーザがともに利用可能な支払い方法においては、当該利用ユーザが当該依頼ユーザに対して予め料金を支払っておくことが可能であり、
前記決定手段は、前記利用ユーザから料金が予め支払われているか否かを前記影響情報として前記決定を行う
ことを特徴とする請求項１０に記載の情報処理装置。
【請求項１２】
コンピュータを、
特定の支払い方法で料金を支払う有料のサービスを利用する利用ユーザが当該支払い方法で当該サービスの料金を支払えるか否かを判定する判定手段と、
前記判定手段により支払えないと判定された場合に、当該料金の支払いを依頼する相手である依頼ユーザに対応する宛先に、当該依頼の内容を示す依頼データを送信する送信手段
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
特許文献１には、クライアントＡの電子マネーの正当性及びクライアントＢの電子マネーの正当性がそれぞれ検証されて双方に不正が発見されなければ、依頼情報に基づいて決済処理が行われる技術が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−２４６８５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、料金の支払い方法が決まっているサービスをその方法で料金を支払えないユーザに提供するたの依頼をすることを目的とする。
【課題を解決するための手段】
【０００５】
本発明の請求項１に係る情報処理装置は、特定の支払い方法で料金を支払う有料のサービスを利用する利用ユーザが当該支払い方法で当該サービスの料金を支払えるか否かを判定する判定手段と、前記判定手段により支払えないと判定された場合に、当該料金の支払いを依頼する相手である依頼ユーザに対応する宛先に、当該依頼の内容を示す依頼データを送信する送信手段とを備えることを特徴とする。
【０００６】
本発明の請求項２に係る情報処理装置は、請求項１に記載の構成において、前記依頼に影響を与え得る影響情報に基づいて、前記依頼ユーザの候補となる候補ユーザから当該依頼ユーザを決定する決定手段を備え、前記送信手段は、前記決定手段により決定された依頼ユーザに対応する宛先に、前記依頼データを送信することを特徴とする。
【０００７】
本発明の請求項３に係る情報処理装置は、請求項２に記載の構成において、前記決定手段は、前記候補ユーザの属性を前記影響情報として前記決定を行うことを特徴とする。
【０００８】
本発明の請求項４に係る情報処理装置は、請求項２または３に記載の構成において、前記決定手段は、前記利用ユーザ及び前記候補ユーザの交流の履歴を前記影響情報として前記決定を行うことを特徴とする。
【０００９】
本発明の請求項５に係る情報処理装置は、請求項２から４までのいずれか１項に記載の構成において、前記決定手段は、前記支払い方法における前記候補ユーザの支払い能力を前記影響情報として前記決定を行うことを特徴とする。
【００１０】
本発明の請求項６に係る情報処理装置は、請求項２から５までのいずれか１項に記載の構成において、前記決定手段は、ネットワークを介して利用するサービスの前記候補ユーザの利用状態を前記影響情報として前記決定を行うことを特徴とする。
【００１１】
本発明の請求項７に係る情報処理装置は、請求項２から６までのいずれか１項に記載の構成において、前記決定手段は、前記候補ユーザが前記依頼の承諾の可否を表明している場合に、当該表明した内容を前記影響情報として前記決定を行うことを特徴とする。
【００１２】
本発明の請求項８に係る情報処理装置は、請求項２から７までのいずれか１項に記載の構成において、前記送信手段により前記依頼データが送信された前記依頼ユーザによる前記サービスの料金の支払いの状況を示す状況情報を取得する取得手段を備え、前記決定手段は、前記送信手段により前記依頼データが送信されてから決められた時間が経過するまでに前記取得手段により前記サービスの料金が支払われたことを示す状況情報が取得されない場合には、別の依頼ユーザを決定し、前記送信手段は、前記決定手段により別の依頼ユーザが決定された場合には、当該別の依頼ユーザに対応する宛先に前記依頼データを送信することを特徴とする。
【００１３】
本発明の請求項９に係る情報処理装置は、請求項８に記載の構成において、前記取得手段により取得された前記サービスの料金の支払いの状況を前記利用ユーザに通知する通知手段を備えることを特徴とする。
【００１４】
本発明の請求項１０に係る情報処理装置は、請求項２から９までのいずれか１項に記載の構成において、前記送信手段は、前記利用ユーザ及び前記依頼ユーザがともに利用可能な支払い方法がある場合に、当該利用ユーザが前記サービスの料金を当該支払い方法で当該依頼ユーザに支払うための支払いデータを、当該支払い方法に対応する宛先に送信することを特徴とする。
【００１５】
本発明の請求項１１に係る情報処理装置は、請求項１０に記載の構成において、前記利用ユーザ及び前記依頼ユーザがともに利用可能な支払い方法においては、当該利用ユーザが当該依頼ユーザに対して予め料金を支払っておくことが可能であり、前記決定手段は、前記利用ユーザから料金が予め支払われているか否かを前記影響情報として前記決定を行うことを特徴とする。
【００１６】
本発明の請求項１２に係るプログラムは、コンピュータを、特定の支払い方法で料金を支払う有料のサービスを利用する利用ユーザが当該支払い方法で当該サービスの料金を支払えるか否かを判定する判定手段と、前記判定手段により支払えないと判定された場合に、当該料金の支払いを依頼する相手である依頼ユーザに対応する宛先に、当該依頼の内容を示す依頼データを送信する送信手段として機能させることを特徴とする。
【発明の効果】
【００１７】
請求項１、１２に係る発明によれば、料金の支払い方法が決まっているサービスをその方法で料金を支払えないユーザに提供するための依頼をすることができる。
請求項２に係る発明によれば、影響情報に関係なく依頼ユーザを決定する場合に比べて、より望ましい相手に支払いの依頼をすることができる。
請求項３に係る発明によれば、候補ユーザの属性を影響情報として用いない場合に比べて、より望ましい相手に支払いの依頼をすることができる。
請求項４に係る発明によれば、候補ユーザの交流の履歴を影響情報として用いない場合に比べて、より望ましい相手に支払いの依頼をすることができる。
請求項５に係る発明によれば、候補ユーザの支払い能力を影響情報として用いない場合に比べて、より望ましい相手に支払いの依頼をすることができる。
【００１８】
請求項６に係る発明によれば、ネットワークを介して利用するサービスの候補ユーザの利用状態を影響情報として用いない場合に比べて、より望ましい相手に支払いの依頼をすることができる。
請求項７に係る発明によれば、候補ユーザが表明している依頼の承諾の可否を影響情報として用いない場合に比べて、より望ましい相手に支払いの依頼をすることができる。
請求項８に係る発明によれば、別の依頼ユーザを決定しない場合に比べて、支払いがされないということが起こりにくくすることができる。
請求項９に係る発明によれば、支払いの状況が通知されない場合に比べて、利用ユーザが有料のサービスを早く利用することができる。
請求項１０に係る発明によれば、支払いデータの送信を行わない場合に比べて、利用ユーザによる依頼ユーザへの返金の手間を減らすことができる。
請求項１１に係る発明によれば、予め支払われている料金の有無を影響情報として用いない場合に比べて、利用ユーザが有料のサービスを早く利用することができる。
【図面の簡単な説明】
【００１９】
【図１】第１実施形態の情報処理システムの全体構成の一例を示す図。
【図２】情報処理装置１０のハードウェア構成の一例を示す図。
【図３】情報処理装置１０の機能構成の一例を示す図。
【図４】支払い方法を選択させる画像の一例を示す図。
【図５】依頼条件の例を示す図。
【図６】表示された依頼データの一例を示す図。
【図７】支払いサイトの一例を示す図。
【図８】支払いの完了が通知された場合に表示される画像の一例を示す図。
【図９】表示された通知データの一例を示す図。
【図１０】依頼処理における各装置の動作の一例を示すシーケンス図。
【図１１】提供処理における各装置の動作の一例を示すシーケンス図。
【図１２】第１及び第２優先度テーブルの一例を示す図。
【図１３】第４実施形態の情報処理装置の機能構成の一例を示す図。
【図１４】依頼処理における各装置の動作の一例を示すシーケンス図。
【図１５】第５実施形態で用いられる依頼データの一例を示す図。
【発明を実施するための形態】
【００２０】
［１］第１実施形態
［１−１］全体構成
図１は、第１実施形態の情報処理システムの全体構成の一例を示す図である。図１では、ネットワーク２と、複数の情報処理装置１０と、第１ユーザ端末２０と、複数の第２ユーザ端末３０と、ＳＮＳ（Social Networking Service）サーバ装置４０と、複数のサービスサーバ装置５０とを備える情報処理システム１が示されている。情報処理システム１は、ユーザに有料のサービス（以下「有料サービス」という）を提供するとともに、その有料サービスの料金（以下「サービス料金」という）をユーザに課金するための課金処理を行うシステムである。有料サービスとは、例えば、２つのデータの差分を抽出する差分抽出サービスやデータのフォーマットを変換する変換サービス、ＯＣＲ（Optical Character Recognition）サービス、翻訳サービスなどである。
【００２１】
情報処理システム１では、或るユーザが有料サービスを利用する場合に、その利用ユーザ（有料サービスを利用するユーザ）とは異なるユーザにそのサービス料金の支払いが依頼されることがある。以下では、このようなサービス料金の支払いの依頼のことを「支払い依頼」という。また、支払い依頼が行われるユーザ（支払いを依頼されるユーザ）を「依頼ユーザ」といい、依頼ユーザの候補となるユーザのことを「候補ユーザ」という。図１の例では、利用ユーザが第１ユーザ端末２０を使用し、候補ユーザが第２ユーザ端末３０を使用するものとする。つまり、第２ユーザ端末３０は、依頼ユーザが使用することにもなる。
【００２２】
第１ユーザ端末２０及び第２ユーザ端末３０は、いずれも、スマートフォン、タブレット端末及びパーソナルコンピュータ等の装置である。図１の例では、第１ユーザ端末２０及び第２ユーザ端末３０は、いずれもネットワーク２と無線通信（例えば移動体通信や無線ＬＡＮ（Local Area Network）通信）を行う。なお、これらの端末は、ネットワーク２と有線通信を行ってもよい。
【００２３】
ネットワーク２は、インターネット及び移動体通信網等を含んで通信を行うシステムであり、自システムに接続された装置及び自システムと無線通信を行う装置同士のデータのやり取りを仲介する。図１の例では、ネットワーク２には、情報処理装置１０及びＳＮＳサーバ装置４０が接続されている。ＳＮＳサーバ装置４０は、登録されたユーザにＳＮＳを提供する装置である。本実施形態では、ＳＮＳといえば、ＳＮＳサーバ装置４０が提供するＳＮＳのことを指すものとする。このＳＮＳは、利用ユーザ及び候補ユーザが利用している。ＳＮＳサーバ装置４０は、これらのユーザに関して登録された情報（以下「第１登録情報」という）を記憶し、第１登録情報（例えばユーザＩＤやパスワード）に基づいてログインしたユーザに対してＳＮＳを提供する。
【００２４】
サービスサーバ装置５０は、差分抽出サービスや翻訳サービスなどの有料サービスにおいて、差分の抽出やデータのフォーマットの変換などの処理（以下「サービス処理」という）をそれぞれ行う装置である。なお、図１の例では、説明を分かりやすくするために１台の装置で表したが、これらのサービスは、いわゆるクラウドサービスで提供されていてもよい。サービスサーバ装置５０は、サービス処理を行った結果を示す結果データを、情報処理装置１０に送信する。結果データとは、例えば、抽出した差分を示すデータや翻訳した文書を示すデータなどである。
【００２５】
複数の情報処理装置１０は、コンビニエンスストアなどのユーザが訪れる施設にそれぞれ設置され、有料サービスを利用する利用ユーザによって操作される装置である。情報処理装置１０は、利用する有料サービスを選択する操作を受け付け、選択された有料サービスを提供するための処理の実行を要求する旨を示す要求データをサービスサーバ装置５０に送信する。サービスサーバ装置５０は、要求データに基づいて処理を行い、その結果を示す結果データを情報処理装置１０に送信する。情報処理装置１０は、サービスサーバ装置５０から送信されてきた結果データを出力する。このようにして、利用ユーザに有料サービスが提供される。また、情報処理装置１０は、提供された有料サービスのサービス料金についての課金処理を行う。
【００２６】
［１−２］ハードウェア構成
図２は、情報処理装置１０のハードウェア構成の一例を示す図である。情報処理装置１０は、制御部１１と、記憶部１２と、通信部１３と、操作部１４と、表示部１５と、画像形成部１６と、電子決済部１７とを備えるコンピュータである。制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）及びリアルタイムクロックを備え、ＣＰＵが、ＲＡＭをワークエリアとして用いてＲＯＭや記憶部１２に記憶されたプログラムを実行することによって各部の動作を制御する。リアルタイムクロックは、現在の日時を算出してＣＰＵに通知する。
【００２７】
記憶部１２は、ハードディスク等を備え、制御部１１が制御に用いるデータやプログラム、画像データなどを記憶する。記憶部１２には、上述した課金処理を行うための処理プログラムが記憶されている。通信部１３は、通信を行うための通信回路を備え、例えばネットワーク２を介して外部装置と通信を行う。操作部１４は、タッチパネルやボタン等の操作子を備え、それらの操作子に対するユーザの操作を受け付ける。操作部１４は、受け付けたユーザの操作に応じた操作データを制御部１１に供給し、制御部１１は、供給された操作データに応じて処理を行う。
【００２８】
表示部１５は、液晶ディスプレイ等を備え、表示面に画像を表示する。この表示面には操作部１４のタッチパネルが重ねて設けられており、操作子を表す操作子画像による操作も可能となっている。画像形成部１６は、用紙等の媒体に画像を形成する手段であり、例えば、イエロー（Ｙ）、マゼンタ（Ｍ）、シアン（Ｃ）及びブラック（Ｋ）の４色のトナーを用いて電子写真方式で用紙に画像を形成する。画像形成部１６は、例えばファクシミリ機能や画像形成機能が実行されたときに、画像データが示す画像を記録媒体に形成することで、画像データを媒体に出力する。
【００２９】
電子決済部１７は、ユーザが所持するＮＦＣ（Near Field Communication）チップを備えた電子決済用のＩＣ（Integrated Circuit）カードとＮＦＣの規格に準拠したＮＦＣ通信を行うことで電子決済を行うための装置である。電子決済部１７は、図示せぬ電子決済システムと接続されており、ＮＦＣ通信によりＩＣカードから読み取ったＩＣカード番号や与信情報に基づく電子決済の処理を行う。電子決済部１７には、電子決済システムから支払いが完了したことを示すデータ（以下「決済完了データ」という）が送信されてくる。電子決済部１７は、受信した決済完了データを制御部１１に供給する。
【００３０】
［１−３］機能構成
情報処理システム１は、以上のハードウェア構成に基づき、上述した課金処理を行う。情報処理装置１０の制御部１１が記憶部１２に記憶されている処理プログラムを実行して各部を制御することで、以下に述べる機能が実現される。
図３は、情報処理装置１０の機能構成の一例を示す図である。情報処理装置１０は、判定手段１０１と、決定手段１０２と、送信手段１０３と、取得手段１０４と、提供手段１０５と、通知手段１０６とを備える。
【００３１】
［１−３−１］判定手段１０１
判定手段１０１は、特定の支払い方法（以下「特定支払い方法」という）で料金を支払う有料サービスを利用する利用ユーザがその特定方法でそのサービス料金（すなわちその有料サービスの料金）を支払えるか否かを判定する手段の一例である。特定支払い方法とは、例えば、特定の事業者によって運営されている電子決済により支払うという方法である。本実施形態では、対応するＩＣカードを用いなければ支払えない支払い方法が特定支払い方法である場合について説明する。判定手段１０１は、例えば、制御部１１、記憶部１２、操作部１４及び表示部１５により実現される機能である。
【００３２】
本実施形態の有料サービスは、登録されたユーザに提供されるようになっており、記憶部１２には、各ユーザについて登録された情報（以下「第２登録情報」という。前述した第１登録情報とは異なるもの。）が記憶されている。第２登録情報は、例えば、ユーザＩＤやパスワードなどである。制御部１１は、操作部１４の操作によりユーザＩＤ及びパスワードが入力されると、入力されたユーザＩＤ及びパスワードを含む第２登録情報を登録したユーザを利用ユーザとして、有料サービスを提供する。具体的には、利用ユーザにより有料サービスを利用するための操作が行われると、制御部１１は、操作の内容に基づいて提供する有料サービスの内容を決定する。
【００３３】
この操作は、サービス料金の支払い前に行われるものであり、以下では「支払い前操作」という。制御部１１は、支払い前操作により有料サービスの内容を決定すると、その有料サービスを識別するための番号（以下「サービス番号」という）を発行し、決定した内容に対応付けて記憶部１２に記憶させる。サービス番号は、支払いの依頼や支払いの完了などがどのサービスに対して行われたものかを識別するために用いられる。また、制御部１１は、決定した有料サービスの内容に基づいてサービス料金を算出し、算出したサービス料金の支払い方法を選択させる画像を表示部１５に表示させる。
【００３４】
図４は、支払い方法を選択させる画像の一例を示す図である。この例では、「サービス料金は１０００円です。支払い方法を選んで下さい。」という文字列と、「特定支払い方法で支払う」という文字列を含む操作子画像Ｂ１と、「支払いを依頼する」という文字列を含む操作子画像Ｂ２とが表示部１５に表示されている。制御部１１は、操作部１４から操作子画像Ｂ１を選択したことを示す操作データが供給された場合には、利用ユーザが特定支払い方法で支払えると判定し、操作子画像Ｂ２を選択したことを示す操作データが供給された場合には、利用ユーザが特定支払い方法で支払えないと判定する。判定手段１０１は、このように判定を行い、特定支払い方法で支払えないと判定した場合には、例えば判定を行った利用ユーザのユーザＩＤを、サービス番号とともに決定手段１０２に供給する。
【００３５】
制御部１１は、判定手段１０１により利用ユーザが特定支払い方法で支払えると判定された場合には、例えば「ＩＣカードをかざして下さい」という文字列を表示部１５に表示させて、利用ユーザが電子決済部１７にＩＣカードをかざしてＮＦＣ通信がされると、ＩＣカードから読み取ったＩＣカード番号や与信情報に基づく電子決済の処理を行う。例えば、制御部１１は、読み取ったＩＣカード番号（すなわち利用ユーザのＩＣカード番号）及びサービス料金を示すデータを、特定支払い方法で用いられる電子決済システムに送信する。これにより、利用ユーザが自身でサービス料金を支払う場合の電子決済が行われる。判定手段１０１は、特定支払い方法で支払えると判定した場合には、その旨をサービス番号とともに取得手段１０４に通知する。
【００３６】
［１−３−２］決定手段１０２
決定手段１０２は、支払い依頼に影響を与え得る情報（以下「影響情報」という）に基づいて、上述した候補ユーザから依頼ユーザ（支払い依頼がされる候補ユーザ）を決定する手段の一例である。影響情報は、より詳細には、支払い依頼を行う相手（依頼ユーザ）を決定する際に影響を与え得る情報である。この影響情報が異なれば、支払い依頼を行う相手も変わることがある。本実施形態では、決定手段１０２は、候補ユーザの属性を影響情報として依頼ユーザの決定を行う。決定手段１０２は、例えば、制御部１１、記憶部１２及び通信部１３により実現される機能である。
【００３７】
記憶部１２に記憶されている第２登録情報には、利用ユーザ及び候補ユーザ等のユーザの属性を表す情報が含まれている。ユーザの属性は、例えば、住所、生年月日、勤め先、所属組織（所属している組織のこと。）及び利用サービス（利用しているサービスのこと。ＳＮＳや通信販売のサービスなど。）等である。制御部１１は、予め決められた条件が満たされるか否かをこれらの属性を用いて判断し、満たされる場合に、その属性の候補ユーザを依頼ユーザとして決定する。このように、満たされた場合に依頼ユーザが決定される条件のことを以下では「依頼条件」という。依頼条件と、依頼条件の判断に用いる属性との例について図５を参照して説明する。
【００３８】
図５は、依頼条件の例を示す図である。この例では、「利用ユーザの家族（成年）」、「利用ユーザの同僚」及び「利用ユーザと利用サービスが共通」という依頼条件を判断する際に、「住所、生年月日」、「勤め先、所属組織」及び「利用サービス」という属性がそれぞれ用いられることが示されている。制御部１１は、例えば、或る候補ユーザの属性のうち、住所が利用ユーザと共通し、且つ、年齢が２０才以上である場合に、その候補ユーザは依頼条件を満たすと判断し、依頼ユーザとして決定する。また、制御部１１は、或る候補ユーザの属性のうち、勤め先及び所属組織がどちらも利用ユーザと共通する場合や、利用サービスが利用ユーザと共通する場合に、その候補ユーザは依頼条件を満たすと判断し、依頼ユーザとして決定する。決定手段１０２は、このようにして依頼ユーザを決定し、決定した依頼ユーザを識別する情報として、例えば第２登録情報に含まれるユーザＩＤをサービス番号とともに送信手段１０３に供給する。
【００３９】
［１−３−３］送信手段１０３
送信手段１０３は、判定手段１０１によりサービス料金が支払えないと判定された場合に、そのサービス料金の支払いを依頼する相手である依頼ユーザに対応する宛先に、その依頼の内容を示すデータ（以下「依頼データ」という）を送信する手段の一例である。より詳細には、送信手段１０３は、決定手段１０２により決定された依頼ユーザに対応する宛先に、依頼データを送信する。送信手段１０３は、例えば、制御部１１、記憶部１２及び通信部１３により実現される機能である。
【００４０】
依頼ユーザに対応する宛先とは、例えば、依頼ユーザの電子メールアドレスや依頼ユーザのＳＮＳのアカウントである。本実施形態では、記憶部１２は、第２登録情報として候補ユーザがＳＮＳ（ＳＮＳサーバ装置４０により提供されているＳＮＳ）で用いているアカウントを記憶している。制御部１１は、決定手段１０２からユーザＩＤを供給されると、供給されたユーザＩＤを含む第２登録情報に含まれるアカウントを宛先として、通信部１３を介して依頼データをサービス番号とともに送信する。送信手段１０３は、こうして依頼データを送信すると、その旨をサービス番号とともに取得手段１０４に通知する。
【００４１】
なお、送信手段１０３は、決定手段１０２により複数の依頼ユーザが決定された場合に、それら全てに依頼データを送信してもよいし、そのうちのさらに利用ユーザにより選択された依頼ユーザにだけ依頼データを送信してもよい。前者の場合、送信手段１０３は、決定された複数の依頼ユーザにそれぞれ対応する複数の宛先に依頼データを送信する。後者の場合、送信手段１０３は、決定された依頼ユーザのいずれかを選択するための画像を表示して、利用ユーザにより選択された依頼ユーザに対応する宛先に依頼データを送信する。
【００４２】
依頼データは、例えば、支払いを依頼する文章と、支払いを行う場合に用いられるサイト（以下「支払いサイト」という）のＵＲＬ（Uniform Resource Locator）とを示すデータである。本実施形態では、ＳＮＳサーバ装置４０が、支払いサイトを提供している。この支払いサイトは、ＳＮＳを利用する中で生じる支払いを行うためのサイトであり、ＳＮＳのサービスの一環として提供されている。依頼データがＳＮＳへ投稿されると、利用ユーザが例えば第１ユーザ端末２０を用いてＳＮＳへログインすることで、利用ユーザのアカウントに投稿された依頼データの内容が表示される。
【００４３】
図６は、表示された依頼データの一例を示す図である。この例では、「◎支払い依頼のご案内」、「ユーザ２さんへ、ユーザ１さんから、１０００円の支払い依頼があります。」及び「支払う場合はＵＲＬ１、支払わない場合はＵＲＬ２を選択して下さい。」という文字列により表される依頼データが表示されている。「ＵＲＬ１」及び「ＵＲＬ２」という部分は、実際にはＵＲＬそのものが表示されており、これらの部分を依頼ユーザが選択することで、選択されたＵＲＬのサイトが表示される。依頼ユーザがＵＲＬ２を選択すると、第２ユーザ端末３０は、例えば、支払いを拒否することを示す拒否データをサービス番号とともに情報処理装置１０及び第１ユーザ端末２０に送信する。
【００４４】
依頼ユーザがＵＲＬ１を選択すると、第２ユーザ端末３０は、前述した支払いサイトを表示する。
図７は、支払いサイトの一例を示す図である。この例では、「有料サービスの内容」から「支払総額：１０００円」及び「サービス番号：ｘｘｘｘｘｘｘ」までの文字列と、「ＩＣカード番号を入力して下さい。」という文字列と、ＩＣカード番号を入力する入力欄Ｃ１と、入力を完了させるための操作子画像Ｂ１とが第２ユーザ端末３０に表示されている。このサービス番号は、上述した支払い前操作により利用ユーザが利用しようとしているサービス毎に制御部１１が付与した番号である。
【００４５】
依頼ユーザが入力欄Ｃ１に自身が所持するＩＣカード番号を入力して操作子画像Ｂ３を選択することで、入力されたＩＣカード番号（すなわち依頼ユーザのＩＣカード番号）及びサービス料金を示すデータが特定支払い方法で用いられる電子決済システムに送信され、依頼されたサービス料金の支払いが行われる。電子決済システムにおいて決済が完了すると、上述した決済完了データ（支払いが完了したことを示すデータ）がＳＮＳサーバ装置４０に送信され、ＳＮＳサーバ装置４０が、例えば支払いが完了した旨を、サービス番号とともに支払いサイトに掲載する。
【００４６】
［１−３−４］取得手段１０４
取得手段１０４は、利用ユーザが利用した有料サービスのサービス料金の支払いの状況（以下「支払い状況」という）を示す情報（以下「状況情報」という）取得する手段の一例である。取得手段１０４は、例えば、制御部１１、記憶部１２及び通信部１３により実現される機能である。判定手段１０１が特定支払い方法で支払えると判定した場合には、判定手段１０１からその旨がサービス番号とともに制御部１１に通知される。その場合、制御部１１は、電子決済部１７から決済完了データが供給されてきたときに、供給された決済完了データ及び先に通知されたサービス番号を、そのサービス番号に対応する支払い（すなわちそのサービス番号により識別される有料サービスのサービス料金の支払い）が完了したことを示す状況情報として取得する。
【００４７】
また、判定手段１０１が特定支払い方法で支払えないと判定した場合には、送信手段１０３から依頼データを送信した旨が制御部１１に通知される。その場合、制御部１１は、例えば前述した支払いサイトにアクセスし、通知されたサービス番号とともに支払いが完了した旨を示すデータが送信されてきた場合に、そのデータを、そのサービス番号に対応する支払いが完了したことを示す状況情報として取得する。取得手段１０４は、このようにして状況情報を取得し、サービス料金の支払いが完了したことを示す状況情報を取得した場合に、サービス料金の支払いが完了したことを、その支払いに対応するサービス番号とともに提供手段１０５及び通知手段１０６に通知する。
【００４８】
［１−３−５］提供手段１０５
提供手段１０５は、取得手段１０４によりサービス料金の支払いが完了したことを示す状況情報が取得された場合に、有料サービスを利用ユーザに提供する手段の一例である。提供手段１０５は、例えば、制御部１１、記憶部１２、通信部１３、操作部１４、表示部１５及び画像形成部１６により実現される機能である。利用ユーザが操作部１４を操作してサービス番号を入力すると、制御部１１は、入力されたサービス番号に対応する支払いが完了したことが通知されていれば、例えば図８に示す画像を表示部１５に表示させる。
【００４９】
図８は、有料サービスの支払いが完了した場合に表示される画像の一例を示す図である。この例では、「サービス番号：ｘｘｘｘｘｘｘの支払いが完了しています。提供を開始しますか？」という文字列と、「開始する」という文字列を含む操作子画像Ｂ４とが表示されている。制御部１１は、操作子画像Ｂ４を選択する操作が行われると、サービス番号に対応付けて記憶されている内容の有料サービスを提供するための処理を行う。制御部１１は、例えば、支払い前操作として、差分抽出サービスの選択と差分を抽出する２つのデータの指定とが行われていた場合には、指定された２つのデータ及びそれらの差分の抽出を要求する旨を示すデータを、上述した要求データ（有料サービスを提供するための処理の実行を要求するデータ）としてサービスサーバ装置５０に送信する。
【００５０】
サービスサーバ装置５０は、要求データを受信すると、要求データが示す２つのデータの差分を抽出し、その結果を示す結果データ（この場合、抽出された差分を示すデータ）を情報処理装置１０に送信する。制御部１１は、サービスサーバ装置５０から送信されてきた結果データを、画像形成部１６を制御して媒体に形成させる。こうして媒体に差分を表す画像が形成されることで、差分抽出サービスが利用ユーザに提供される。提供手段１０５は、以上のとおり有料サービスの提供を行う。
なお、提供手段１０５は、支払い前操作が行われたときに、予め要求データをサービスサーバ装置５０に送信して結果データを受け取っておき、支払いが完了してサービス番号が入力されたときに結果データの出力だけを行うようにしてもよい。
【００５１】
［１−３−６］通知手段１０６
通知手段１０６は、取得手段１０４により取得されたサービス料金の支払い状況を利用ユーザに通知する手段の一例である。通知手段１０６は、例えば、制御部１１及び通信部１３により実現される機能である。制御部１１は、取得手段１０４からサービス番号及びそれに対応する支払いが完了したことが通知されると、利用ユーザにその旨を通知をするためのデータ（以下「通知データ」という）を、通信部１３を介して第１ユーザ端末２０に送信する。第１ユーザ端末２０は、情報処理装置１０から送信されてきた通知データを表示する。
【００５２】
図９は、表示された通知データの一例を示す図である。図９（ａ）に示す例では、第１ユーザ端末２０に、「支払い状況の通知」というタイトルの文字列と、「サービス番号：ｘｘｘｘｘｘｘの支払いはまだ完了していません。」という文字列と、サービスの内容を表す文字列とが表示されている。また、図９（ｂ）に示す例では、図９（ａ）と異なり、「サービス番号：ｘｘｘｘｘｘｘの支払いが完了しました。」という文字列が表示されている。このように、通知手段１０６が通知データを送信することで、取得された支払い状況が利用ユーザに通知される。具体的には、図９（ａ）の例では、支払いが完了していないという支払い状況が通知され、図９（ｂ）の例では、支払いが完了したという支払い状況が通知される。
【００５３】
なお、通知手段１０６は、通知データを利用ユーザのＳＮＳのアカウントや電子メールアドレス宛に送信することで、通知データの内容、すなわちサービス料金の支払い状況を利用ユーザに通知してもよい。この場合、ＳＮＳやメールソフトの機能で新たな投稿やメールがあったことが利用ユーザに知らされることで、支払い状況の通知がされる。また、通知手段１０６は、電話で通知を行ってもよいし、ここまでに述べた複数の通知方法を並行して用いてもよい。
【００５４】
［１−４］動作
情報処理システム１は、以上の構成に基づき上述した課金処理（サービス料金をユーザに課金するための処理）を行う。以下では、課金処理のうち、支払い依頼に関する依頼処理と、有料サービスの提供に関する提供処理とに分けてそれぞれ説明する。
図１０は、依頼処理における各装置の動作の一例を示すシーケンス図である。依頼処理は、情報処理装置１０が、上述した支払い前操作（サービス料金の支払い前に行われる操作）を受け付ける（ステップＳ１１）ことを契機に開始される。
【００５５】
情報処理装置１０は、次に、図４に示すように、利用ユーザが利用しようとしている有料サービスのサービス料金及び支払い方法を表示する（ステップＳ１２）。続いて、情報処理装置１０は、利用ユーザが支払い方法を選択する操作（選択操作）を受け付ける（ステップＳ１３）。情報処理装置１０は、図４に示す例であれば、操作子画像Ｂ１を選択する操作か操作子画像Ｂ２を選択する操作のいずれかを受け付ける。そして、情報処理装置１０は、特定支払い方法での支払いの可否を判定する（ステップＳ１４）。情報処理装置１０は、図４に示す例であれば、操作子画像Ｂ１の選択操作を受け付けた場合には特定支払い方法で支払えると判定し、操作子画像Ｂ２の選択操作を受け付けた場合には特定支払い方法で支払えないと判定する。ステップＳ１２、Ｓ１３及びＳ１４は判定手段１０１が行う動作である。
【００５６】
ステップＳ１４において特定支払い方法で支払えると判定された場合には、例えば利用ユーザが電子決済部１７にＩＣカードをかざすことで特定支払い方法でのサービス料金の支払いが行われて情報処理装置１０が有料サービスを提供する。図１０では、この場合の動作については省略し、ステップＳ１４において特定支払い方法で支払えないと判定された場合の動作について説明する。
【００５７】
情報処理装置１０は、特定支払い方法で支払えないと判定した場合に、支払いを依頼する相手である依頼ユーザを決定する（ステップＳ１５）。ステップＳ１５は決定手段１０２が行う動作である。次に、情報処理装置１０は、決定した依頼ユーザに対応する宛先に依頼データを送信する（ステップＳ１６）。図１０の例では、情報処理装置１０は、依頼ユーザのアカウントに依頼データを投稿することで、ＳＮＳサーバ装置４０に依頼データを送信する。
【００５８】
ＳＮＳサーバ装置４０は、ステップＳ１６において依頼データを受信すると、依頼データが投稿されたアカウントに対応付けてその依頼データを記憶する。ＳＮＳサーバ装置４０は、そのアカウントでログインしてきた第２ユーザ端末３０とデータのやり取りをすることで（ステップＳ２１）、ＳＮＳを依頼ユーザに提供する。以降、ステップＳ２２からＳ２５までは、第２ユーザ端末３０がＳＮＳサーバ装置４０とデータをやり取りしながら行う動作である。
【００５９】
第２ユーザ端末３０は、図１０の例では、図６に示す依頼データを表示する（ステップＳ２２）。次に、第２ユーザ端末３０は、依頼ユーザにより支払いが承諾されたか否かを判断する（ステップＳ２３）。第２ユーザ端末３０は、図６の例であれば、ＵＲＬ１が選択された場合に支払いが承諾されたと判断し、ＵＲＬ２が選択された場合に支払いが拒否されたと判断する。第２ユーザ端末３０は、支払いが承諾された（ＹＥＳ）と判断した場合には、例えば図７に示す支払いサイトを表示する（ステップＳ２４）。続いて、第２ユーザ端末３０が依頼ユーザのＩＣカード番号を入力する操作（入力操作）を受け付けると（ステップＳ２５）、ＳＮＳサーバ装置４０は、入力された依頼ユーザのＩＣカード番号等のデータを、特定支払い方法で用いられる電子決済システムに送信する（ステップＳ２６）。これにより、利用ユーザが利用した有料サービスのサービス料金が、その電子決済システムにより決済され、特定支払い方法によって支払われることになる。
【００６０】
また、第２ユーザ端末３０は、ステップＳ２３において支払い依頼が拒否された（ＮＯ）、（図６の例ではＵＲＬ２が選択された）と判断した場合には、上述した拒否データ（支払いを拒否することを示すデータ）を情報処理装置１０及び図示していない第１ユーザ端末２０に送信する（ステップＳ２７）。
【００６１】
図１１は、提供処理における各装置の動作の一例を示すシーケンス図である。提供処理は、情報処理装置１０が、上述した状況情報（サービス料金の支払い状況を示す情報）を取得する（ステップＳ３１）ことを契機に開始される。ステップＳ３１は取得手段１０４が行う動作である。情報処理装置１０は、次に、取得した状況情報に基づき支払いが完了したか否かを判断する（ステップＳ３２）。情報処理装置１０は、支払いが完了した（ＹＥＳ）と判断した場合には、上述した通知データ（サービス番号及びそれに対応する支払いが完了したことを通知するためのデータ）を第１ユーザ端末２０に送信する（ステップＳ３３）。ステップＳ３２及びＳ３３は通知手段１０６が行う動作である。第１ユーザ端末２０は、ステップＳ３３において受信した通知データ（例えば図９（ｂ）に示す通知データ）を表示する（ステップＳ３４）。
【００６２】
利用ユーザは、表示された通知データからサービス料金の支払いが完了したことを知り、有料サービスの提供を受けるために情報処理装置１０が設置されている場所に移動する。この場合の情報処理装置１０は、図１０に示すステップＳ１１で利用操作を行った情報処理装置１０でもよいし、それ以外の情報処理装置１０でもよい。図１１では、別の情報処理装置１０が有料サービスを提供する場合について説明する。別の情報処理装置１０は、利用ユーザがサービス番号を入力する操作（入力操作）を受け付けると（ステップＳ３５）、そのサービス番号により識別される有料サービスの内容について他の情報処理装置１０に対して問い合わせを行い（ステップＳ３６）、回答された内容で有料サービスを提供する（ステップＳ３７）。具体的には、情報処理装置１０は、要求データを図示せぬサービスサーバ装置５０に送信し、その結果送信されてくる結果データを出力することで有料サービスを提供する。ステップＳ３４、Ｓ３５及びＳ３６は、提供手段１０５が行う動作である。
【００６３】
［１−５］第１実施形態による効果
本実施形態では、例えば利用ユーザが特定支払い方法で用いられるＩＣカードを所持していない場合に、他のユーザにその支払いが依頼される。つまり、本実施形態によれば、料金の支払い方法が決まっているサービスをその方法で料金を支払えないユーザに提供するための依頼がされることになる。また、支払いを依頼されたユーザ、すなわち依頼ユーザがそのＩＣカードを所持していて支払いを承諾すれば、サービス料金が支払われる。これにより、前述のとおり支払い方法が決まっているサービスが、その方法で料金を支払えないユーザに提供されることになる。
【００６４】
また、本実施形態では、候補ユーザの属性が影響情報、すなわち、支払い依頼に影響を与え得る情報として用いられる。例えば図５で説明したように候補ユーザの属性を用いると、利用ユーザにとって他のユーザに比べて支払いを依頼しやすい家族や同僚、共通の利用サービスを利用しているユーザなどが依頼ユーザとして決定されることになる。これにより、候補ユーザの属性を影響情報として用いない場合に比べて、より望ましい相手に支払いの依頼がされることになる。
【００６５】
このように、本実施形態によれば、影響情報に基づいて依頼ユーザを決定することで、影響情報に関係なく依頼ユーザを決定する場合に比べて、より望ましい相手に支払いの依頼がされることになる。
また、本実施形態では、上記のとおり利用ユーザに支払い状況が通知される。これにより、支払い状況が通知されない場合に比べて、支払いが完了したことを早く知ることで、利用ユーザが有料のサービスを早く利用することになる。
【００６６】
［２］第２実施形態
本発明の第２実施形態について、以下、第１実施形態と異なる点を中心に説明する。第１実施形態では、影響情報として候補ユーザの属性が用いられたが、第２実施形態では、これとは異なる４つの影響情報が用いられる。以下では、それらの影響情報にそれぞれ基づいて依頼ユーザを決定する４つの決定方法と、それぞれの決定方法が用いられることによる効果について、順番に説明する。
【００６７】
［２−１］第２の決定方法
第２の決定方法では、決定手段１０２は、利用ユーザ及び候補ユーザの交流の履歴を影響情報として依頼ユーザの決定を行う。交流の履歴は、例えば、ＳＮＳで利用ユーザのアカウント宛てに過去に投稿した回数（「過去投稿数」という）や決まった期間（過去１年など）におけるその頻度（「投稿頻度」という）などによって表される。決定手段１０２は、例えば、過去投稿数が閾値（例えば１００）以上である候補ユーザを依頼ユーザとして決定したり、投稿頻度が閾値（例えば３０）以上の候補ユーザを依頼ユーザとして決定したりする。このように、決定手段１０２は、利用ユーザ及び候補ユーザの交流の履歴を用いて或る条件（満たされた場合に依頼ユーザが決定される条件であり、上述した依頼条件。）が満たされるか否かを判断し、満たされる場合にその候補ユーザを依頼ユーザとして決定する。
【００６８】
この場合、決定手段１０２は、利用ユーザ及び依頼ユーザの投稿のやり取りを参照するために、例えば、有料サービスにおいて独自に登録されたアカウントでＳＮＳにログインする。各ユーザが、そのアカウントに対して自身への投稿を参照できるような設定を行っておくことで、決定手段１０２が、交流の履歴に基づく決定を行う。なお、そのようなアカウントを用いずに、利用ユーザが支払い前操作において自身のアカウントを入力するようにしてもよい。その場合、決定手段１０２は、利用ユーザのアカウントを用いてＳＮＳにログインし、利用ユーザ及び依頼ユーザの投稿のやり取りを参照する。
【００６９】
なお、ＳＮＳによっては交流の多い相手を表す設定がされている場合がある。例えば、ユーザの属性情報を全て閲覧させる設定や、他のユーザとのやり取りを閲覧させる設定などである。決定手段１０２は、このような設定がされている場合に、依頼条件が満たされると判断してもよい。
利用ユーザにとっては、交流が多い候補ユーザほど、親密な関係にあるため支払いを依頼しやすい場合がある。このような場合に、例えば上記の例のように第２の決定方法が用いられると、交流が多い候補ユーザが交流が少ない候補ユーザよりも依頼ユーザとして決定されやすいようになる。これにより、候補ユーザの交流の履歴を影響情報として用いない場合に比べて、より望ましい相手に支払いの依頼がされることになる。
【００７０】
［２−２］第３の決定方法
第３の決定方法では、決定手段１０２は、特定支払い方法における候補ユーザの支払い能力を影響情報として依頼ユーザの決定を行う。支払い能力は、例えば、特定支払い方法で用いられる支払いサイトへの登録の有無や特定支払い方法で用いられるＩＣカードの有無、特定支払い方法で用いられる口座の残高などによって表される。決定手段１０２は、例えば、支払いサイトへの登録が有る候補ユーザやＩＣカードを所持する候補ユーザを依頼ユーザとして決定する。これらの場合、決定手段１０２は、登録の有無やＩＣカードの所持の有無を依頼条件として用いる。決定手段１０２は、これらの依頼条件を、例えば、第２登録情報の１つとしてユーザによって登録されている情報を用いて判断する。また、決定手段１０２は、過去に特定支払い方法で支払いを行ったユーザのユーザＩＤに対応付けてその旨を記憶しておくことで、これらの依頼条件の判断を行ってもよい。
【００７１】
また、決定手段１０２は、例えばＳＮＳが支払いサイトで利用可能な口座の残高を開示している場合に、候補ユーザのＳＮＳのアカウント及びパスワードを第２登録情報として登録させておき、それらの情報を用いてＳＮＳサーバ装置４０にアクセスして候補ユーザの口座の残高を参照する。決定手段１０２は、参照した口座の残高がサービス料金以上である場合に、依頼条件が満たされると判断して、その候補ユーザを依頼ユーザとして決定する。
【００７２】
支払い能力が無い候補ユーザに支払いを依頼しても、当然ながら支払いは行えない。例えば上記の例のように第３の決定方法が用いられると、支払い能力の有る候補ユーザが依頼ユーザとして決定される。これにより、候補ユーザの支払い能力を影響情報として用いない場合に比べて、より望ましい相手に支払いの依頼がされることになる。
なお、決定手段１０２は、例えば口座の残高を参照して、支払い能力が有る候補ユーザのうち、支払い能力の最も高い候補ユーザを依頼ユーザとして決定してもよい。サービス料金に対して支払い能力に余裕がある方が支払いを承諾しやすいから、このような決定をしない場合に比べて、支払いの依頼が承諾されやすくなる。また、決定手段１０２は、過去に支払い依頼を承諾して支払った回数または支払ったサービス料金の合計が最も大きい候補ユーザを依頼ユーザとして決定してもよい。
【００７３】
［２−３］第４の決定方法
第４の決定方法では、決定手段１０２は、ネットワークを介して利用するサービス（以下「ネットワークサービス」という）の候補ユーザの利用状態を影響情報として依頼ユーザの決定を行う。ネットワークサービスとは、ＳＮＳや通信販売のサービスなどである。これらのネットワークサービスの利用状態とは、例えば、ログインが必要なサービスであれば、候補ユーザがログインしているか否かという状態である。決定手段１０２は、例えば、ネットワークサービスにアクセスし、第２登録情報として記憶している候補ユーザのアカウントがログインされている場合に、依頼条件が満たされると判断して、その候補ユーザを依頼ユーザとして決定する。
【００７４】
候補ユーザがネットワークサービスを利用している状態であるということは、利用していない状態である場合に比べて、その候補ユーザがスマートフォン等を使用して支払いの操作を行える状態である可能性が高い。例えば上記の例のように第４の決定方法が用いられると、そのように支払いの操作を行える状態である可能性の高い候補ユーザが依頼ユーザとして決定されるから、ネットワークサービスの候補ユーザの利用状態を影響情報として用いない場合に比べて、より望ましい相手に支払いの依頼がされることになる。
【００７５】
なお、ネットワークサービスがユーザの状態を他のユーザに伝えるための機能を有している場合がある。例えば、「チャット中」、「離席中」や「会議中」といった状態を伝える機能である。このようなネットワークサービスが利用されている場合には、決定手段１０２は、この機能により伝えられる候補ユーザの利用状態に基づいて依頼ユーザを決定してもよい。具体的には、「離席中」や「会議中」となっている候補ユーザではなく「チャット中」となっている候補ユーザを依頼ユーザとして決定する。
【００７６】
［２−４］第５の決定方法
第５の決定方法では、決定手段１０２は、候補ユーザが依頼の承諾の可否を表明している場合に、その表明した内容を影響情報として依頼ユーザの決定を行う。本実施形態では、第２登録情報に、候補ユーザが表明している依頼の承諾の可否を表す情報（以下「可否情報」という）があり、例えば「承諾する」という可否情報が登録されていればその候補ユーザは支払い依頼があった場合にそれを承諾することを表しており、「拒否する」という可否情報が登録されていればその候補ユーザは支払い依頼があった場合にそれを拒否することを表している。決定手段１０２は、候補ユーザの第２登録情報に「承諾する」という可否情報が含まれている場合に、依頼条件が満たされると判断して、その候補ユーザを依頼ユーザとして決定する。
【００７７】
可否情報は、候補ユーザが自ら登録した情報であるため、候補ユーザの属性等に比べて、支払い依頼を承諾するか否かについての候補ユーザの意向を正確に表したものになりやすい。そのため、可否情報を影響情報として用いない場合に比べて、決定された依頼ユーザが支払い依頼を承諾するという意向である可能性が高く、より望ましい相手に支払いの依頼がされることになる。
【００７８】
［３］第３実施形態
本発明の第３実施形態について、以下、第１及び第２実施形態と異なる点を中心に説明する。第１及び第２実施形態では、影響情報に基づいて依頼条件が満たされるか否かを判断し、満たされると判断した場合に依頼ユーザを決定したが、第３実施形態では、影響情報に基づいて優先度を求め、求めた優先度を用いて依頼ユーザを決定する。以下では、影響情報として利用ユーザと候補ユーザとの交流の履歴と、候補ユーザの支払い能力とが用いられる場合について説明する。
【００７９】
［３−１］機能構成
本実施形態では、決定手段１０２は、交流の履歴及び優先度を対応付けた第１優先度テーブルと、支払い能力及び優先度を対応付けた第２優先度テーブルとを記憶している。
図１２は、第１及び第２優先度テーブルの一例を示す図である。図１２（ａ）では、「２０未満」、「２０以上５０未満」及び「５０以上」という交流の履歴（この例では過去の投稿回数）と、「１」、「２」及び「３」という優先度とが対応付けられている。図１２（ｂ）では、「１倍以上３倍未満」、「３倍以上１０倍未満」及び「１０倍以上」という支払い能力（この例では、口座の残高とサービス料金の比率）と、「１」、「２」及び「３」という優先度とが対応付けられている。
【００８０】
決定手段１０２は、例えば、或る候補ユーザの交流の履歴（過去の投稿数）が２５回である場合、第１優先度テーブルにおいて２５回、すなわち「２０以上５０未満」という交流の履歴に対応付けられている優先度の「２」を読み出す。また、その候補ユーザの口座の残高が１５０００円でサービス料金が１０００円である場合、第２優先度テーブルにおいて１５倍（１５０００円÷１０００円）という支払い能力に対応付けられている「３」という優先度を読み出す。決定手段１０２は、読み出した優先度の合計（この場合２＋３＝５）を、その候補ユーザの優先度として求める。決定手段１０２は、他の候補ユーザに付いても上記のように優先度を求め、求めた優先度が大きいほうから所定の人数（例えば３人）の候補ユーザを、依頼ユーザとして決定する。
【００８１】
なお、決定手段１０２は、交流の履歴及び支払い能力以外にも、候補ユーザの属性、ネットワークサービスの候補ユーザの利用状態及び候補ユーザの依頼の承諾の可否という各影響情報をともに用いてもよいし、それらを様々に組み合わせて用いてもよい。また、決定手段１０２は、これらの影響情報のうちの１つだけを用いてもよい。また、決定手段１０２は、求めた優先度の大きいほうから依頼ユーザを決定するのではなく、例えば２番目から４番目の候補ユーザを依頼ユーザに決定したり、偶数番目の候補ユーザを依頼ユーザとして決定してもよい。要するに、決定手段１０２は、影響情報に基づいて各候補ユーザの優先度を求め、求めた優先度に基づいて依頼ユーザを決定すればよい。
【００８２】
［３−２］第３実施形態による効果
本実施形態では、第１及び第２実施形態のように、依頼条件を満たす候補ユーザが依頼ユーザとして決定されるのではなく、各候補ユーザについて求められた優先度に基づいて依頼ユーザが決定される。言い換えると、本実施形態では、第１及び第２実施形態のように絶対的な基準ではなく、相対的な基準に基づいて依頼ユーザが決定される。例えば交流の履歴である利用ユーザへの投稿回数は、利用ユーザがＳＮＳの利用を開始してから経過した期間が短いほど、少なくなる。このため、絶対的な基準を用いると、その基準を満たす候補ユーザがいないという事態が生じることがあるが、相対的な基準を用いると、その基準を満たす候補ユーザがいないという事態が生じなくなる。
【００８３】
［４］第４実施形態
本発明の第４実施形態について、以下、上記各実施形態と異なる点を中心に説明する。第４実施形態では、依頼ユーザにより支払いが拒否された場合や、決められた時間内に支払いが完了しない場合に、別の候補ユーザに支払いが依頼される。
【００８４】
［４−１］機能構成
図１３は、第４実施形態の情報処理装置の機能構成の一例を示す図である。この例では、図３に示す各手段を備えた情報処理装置１０ａが示されている。本実施形態では、決定手段１０２は、まず、第３実施形態のように、優先度を用いて依頼ユーザを決定する。具体的には、決定手段１０２は、図１２に示す第１及び第２優先度テーブルを用いて求めた優先度が大きいほうから例えば３人の候補ユーザを依頼ユーザとして決定する。
【００８５】
［４−１−１］支払いが拒否された場合
取得手段１０４は、上述したとおり、判定手段１０１が特定支払い方法で支払えないと判定した場合には、送信手段１０３により依頼データが送信された依頼ユーザによる有料サービスのサービス料金の支払い状況を示す状況情報を取得する。取得手段１０４は、第２ユーザ端末３０から拒否データが送信されてくると、その拒否データを、サービス料金の支払いがされないという状況を示す状況情報として取得する。この場合、取得手段１０４は、サービス料金の支払いが拒否されたことを、その支払いに対応するサービス番号とともに提供手段１０５及び通知手段１０６に加え、決定手段１０２に通知する。
【００８６】
決定手段１０２は、取得手段１０４が依頼ユーザにより支払いが拒否されたことを示す状況情報を取得した場合に、別の依頼ユーザを決定する。本実施形態では、決定手段１０２は、上記のとおり決定した３人の依頼ユーザがいずれも支払いを拒否した場合に、第１及び第２優先度テーブルを用いて求めた優先度が大きいほうから４、５及び６番目の３人の候補ユーザを別の依頼ユーザとして決定する。
【００８７】
［４−１−２］時間内に支払いが完了しない場合
この場合、送信手段１０３が、依頼データを送信したときに、その旨を決定手段１０２に通知する。決定手段１０２は、送信手段１０３により依頼データが送信されてから決められた時間（例えば１時間や半日）が経過するまでに取得手段１０４によりサービス料金が支払われたことを示す状況情報が取得されない場合には、別の依頼ユーザを決定する。
送信手段１０３は、支払いが拒否された場合及び時間内に支払いが完了しない場合のいずれにおいても、決定手段１０２により別の依頼ユーザが決定された場合には、その別の依頼ユーザに対応する宛先に依頼データを送信する。
【００８８】
［４−２］動作
図１４は、本実施形態の依頼処理における各装置の動作の一例を示すシーケンス図である。この例では、図１１に示すステップＳ３１の動作が依頼処理における動作として行われる。情報処理装置１０は、まず、状況情報を取得する（ステップＳ３１）。情報処理装置１０は、次に、取得した状況情報に基づいて、支払いが完了したか否かを判断し（ステップＳ３２）、完了していない（ＮＯ）と判断した場合に、さらに、支払いが拒否されたかまたは決められた時間が経過したか否かを判断する（ステップＳ４１）。情報処理装置１０は、ステップＳ４１で否（ＮＯ）と判断した場合には、ステップＳ３１に戻って動作を行う。情報処理装置１０は、ステップＳ４１で支払いが拒否されたまたは決められた時間が経過した（ＹＥＳ）と判断した場合には、別の依頼ユーザを決定する（ステップＳ４２）。ステップＳ４２は決定手段１０２が行う動作である。この後は、図１０に示すステップＳ１６以降の動作が行われる。
【００８９】
［４−３］第４実施形態による効果
本実施形態では、依頼ユーザにより支払いが拒否された場合や、決められた時間内に支払いが完了しない場合であっても、さらに別の候補ユーザが依頼ユーザとして決定され、支払い依頼が行われる。このような本実施形態によれば、別の依頼ユーザを決定しない場合に比べて、支払いがされないということが起こりにくくなる。なお、決定手段１０２による別の依頼ユーザの決定は、１回だけでなく、２回以上行われてもよい。これにより、サービス料金を支払ってくれる依頼ユーザが見つかるまで、支払い依頼が繰り返し行われることになる。
【００９０】
［５］第５実施形態
本発明の第５実施形態について、以下、上記の各実施形態と異なる点を中心に説明する。依頼ユーザによる支払いは、利用ユーザが支払うべきサービス料金の支払いを立て替えたものであるから、利用ユーザが依頼ユーザに立て替えてもらったサービス料金（以下「立て替え金」という）を支払う場合がある。第５実施形態では、立て替え金の支払いを、利用ユーザの操作に基づいて情報処理装置１０が行う。
【００９１】
［５−１］機能構成
本実施形態では、送信手段１０３が、利用ユーザ及び依頼ユーザがともに利用可能な支払い方法（以下「共通支払い方法」という）がある場合に、共通支払い方法での返済を希望する旨を示す依頼データを送信する。共通支払い方法とは、例えば、上述した特定支払い方法とは異なる種類のＩＣカードを用いて行う電子決済（言い換えると、異なる事業者により運営されている電子決済）による支払いである。
【００９２】
図１５は、本実施形態で用いられる依頼データの一例を示す図である。図１５（ａ）の例では、第２ユーザ端末３０に、「ユーザ２さんへ、ユーザ１さんから、決済手段甲での１０００円の支払い依頼があります。なお、ユーザ１さんはこの金額を決済手段乙で返済することを希望しています。」という文字列が表示されている。「決済手段甲」は特定支払い方法で用いられる決済手段を表し、「決済手段乙」は共通支払い方法で用いられる決済手段を表している。依頼ユーザが支払いを承諾してＵＲＬ１を選択すると、例えば図１５（ｂ）に示す表示がされる。図１５（ｂ）の例では、有料サービスの内容に加え、「決済手段甲のＩＣカード番号」及び「決済手段乙のＩＣカード番号」という文字列と、それらの入力欄Ｃ２及びＣ３と、入力を完了させるための操作子画像Ｂ５とが第２ユーザ端末３０に表示されている。第２ユーザ端末３０は、操作子画像Ｂ５が選択されると、入力欄Ｃ３に入力されたＩＣカード番号が、例えば情報処理装置１０に送信される。
【００９３】
送信手段１０３は、依頼ユーザのＩＣカード番号を受信すると、利用ユーザが有料サービスのサービス料金を共通支払い方法で依頼ユーザに支払うための支払いデータを、共通支払い方法に対応する宛先に送信する。支払いデータとは、例えば、電子決済乙で用いられる利用ユーザのＩＣカード番号、依頼ユーザのＩＣカード番号及び立て替え金を示すデータである。利用ユーザのＩＣカード番号は、例えば、利用ユーザが支払い前操作において入力するようにしておく。共通支払い方法に対応する宛先とは、例えば、電子決済乙を提供する電子決済システムに外部装置がアクセスするときに用いられるアクセス先である。本実施形態では、送信手段１０３は、各支払い手段に対応付けてこのようなアクセス先を記憶している。共通支払い方法で用いられる電子決済システムは、支払いデータを受信すると、利用ユーザのＩＣカード番号に対応付けられた電子マネーが立て替え金以上残っていれば、その電子マネーから立て替え金を差し引き、依頼ユーザのＩＣカード番号に対応付けられている電子マネーにその立て替え金を加える。このようにして、電子決済乙による立て替え金の返済が行われる。
【００９４】
［５−２］第５実施形態による効果
利用ユーザが依頼ユーザに立て替えてもらったサービス料金を返金しようとすると、直接会って現金を渡したり、依頼ユーザの銀行の口座に振り込んだりする手間が生じる。本実施形態では、支払いデータが共通支払い方法に対応する宛先（上記の例では共通支払い方法で用いられる電子決済システムのアクセス先）に送信されることで、そのような手間を生じさせることなく、依頼ユーザに立て替えてもらったサービス料金を利用ユーザが返金することになる。つまり、本実施形態によれば、支払いデータの送信を行わない場合に比べて、利用ユーザによる依頼ユーザへの返金の手間が減ることになる。
【００９５】
［６］変形例
上述した各実施形態は、それぞれ本発明の実施の一例に過ぎず、以下のように変形させてもよい。また、上述した各実施形態及び以下に示す各変形例は、必要に応じて組み合わせて実施してもよい。
【００９６】
［６−１］サービス料金の前払い
第５実施形態で述べた共通支払い方法において、利用ユーザが依頼ユーザに対して予め料金を支払っておくこと（いわゆる前払い）が可能であるものとしたときに、上記以外の方法で依頼ユーザを決定してもよい。例えば、共通支払い方法において用いられる電子決済システムは、ネットワーク２を介して閲覧可能なサイトにおいて、前払いを受け付けるサービスを提供している。例えば利用ユーザが第１ユーザ端末２０などを操作してそのサイトにアクセスし、予め支払っておきたい料金を支払うための操作を行うことで、電子決済システムが利用ユーザの電子マネーの残高から依頼ユーザの電子マネーの残高にその料金分の電子マネーを付け替えることで、前払いが行われる。
【００９７】
本変形例では、決定手段１０２が、利用ユーザから料金が予め支払われているか否かを影響情報として依頼ユーザを決定する。例えば、決定手段１０２は、利用ユーザから予め支払われている料金がサービスの料金以上である候補ユーザを依頼ユーザとして決定する。また、決定手段１０２は、利用ユーザから予め支払われている料金が多い候補ユーザほど優先して依頼ユーザとして決定してもよい。いずれの場合も、支払い依頼がされた依頼ユーザは、利用ユーザから予め料金を支払ってもらっている、すなわち前払いがされているため、前払いがされていない場合に比べて支払い依頼を承諾しやすい。一方、利用ユーザにとっては、予め支払われている料金の有無（すなわち前払いの有無）を影響情報として用いない場合に比べて、支払い依頼が承諾されやすくなるから、支払い依頼が拒否されて他の依頼ユーザに依頼するといった時間を費やすことが少なくなり、利用ユーザが有料サービスを早く利用することになる。
【００９８】
［６−２］返済方法
第５実施形態では、利用ユーザは、依頼ユーザにお金で立て替え金を返済したが、これに限らず、例えば電子マネーで利用可能なポイントで返済してもよいし、両者が利用しているＳＮＳ等のネットワークサービスで利用可能な時間を制限しているサービス（例えば動画を視聴するサービス）がある場合に、その時間を延長することで返済してもよい。これらの場合、例えば送信手段１０３が、返済するポイントや延長する時間を示すデータを、それぞれポイントを管理するシステムやサービスの利用可能な時間を管理するシステムに送信することで、返済が行われる。
【００９９】
［６−３］特定支払い方法の利用可否の判定方法
判定手段１０１は、上記実施形態で述べたものとは異なる方法で判定を行ってもよい。例えば、判定手段１０１は、ユーザが特定支払い方法を利用可能であるか否かを示す情報（以下「可否情報」という）を含む第２登録情報を記憶しておく。可否情報は、ユーザが登録してもよいし、第２登録情報に基づいて、有料サービスの提供を行っている事業者が調べて登録してもよい。判定手段１０１は、ユーザＩＤ等が入力されて利用ユーザに有料サービスを提供する場合に、そのユーザＩＤ等とともに第２登録情報として登録されているか可否情報に基づいて判定を行う（具体的には、利用可能という可否情報が登録されていれば、利用ユーザが特定支払い方法で支払えると判定する）。
【０１００】
また、判定手段１０１は、利用ユーザの特定支払い方法で支払い可能な金額に基づいて判定を行ってもよい。例えば、特定支払い方法で用いられる電子決済システムに問い合わせることで利用ユーザの電子決済が可能な金額を示す情報が取得される場合に、判定手段１０１は、そうして取得した情報が示す金額がサービス料金未満であれば、利用ユーザが特定支払い方法で支払えないと判定する。
【０１０１】
［６−４］依頼ユーザの決定方法
決定手段１０２は、上記実施形態で述べたものとは異なる方法で決定を行ってもよい。例えば、利用ユーザが候補ユーザの所属するグループを登録しておき、決定手段１０２が、そのグループに所属する候補ユーザを依頼ユーザとして決定する。この場合、決定手段１０２は、グループが複数登録されていれば、どのグループに依頼するかだけを決定すればよい。例えば、グループα、β、γという３つのグループが登録されている場合に、決定手段１０２は、依頼条件を満たす候補ユーザが最も多いグループに所属する候補ユーザを依頼ユーザとして決定する。
【０１０２】
グループの例としては、図５の例でも述べた家族、同僚及び利用サービスが共通する人たちである。他にも、サービス料金の支払いの立て替えを行うことを目的に集まった候補ユーザ同士をグループとしてもよい。この場合、各候補ユーザが出し合ったお金を口座に貯めておき、そのお金でグループに属する依頼ユーザがサービス料金を支払えるようにしておけばよい。本変形例によれば、利用ユーザが支払いを依頼しやすい相手や金銭的な余裕がありそうな相手などをグループとして登録しておくことで、そのような相手が依頼ユーザとして決定されやすくなる。
【０１０３】
なお、各グループの属性も登録されていて、属性毎の優先度が決められている場合には、決定手段１０２は、その属性に基づいて依頼するグループを決定、すなわちそのグループに所属する候補ユーザを依頼ユーザとして決定してもよい。例えば上述した依頼条件を候補ユーザ毎に判断する場合、候補ユーザが増えるとその判断のための処理の負荷が膨大になるが、グループの属性に基づいて判断することで、その負荷が少なくなる。
【０１０４】
［６−５］別の依頼ユーザを決定する契機
決定手段１０２は、第４実施形態では、依頼ユーザによる支払いの拒否や決められた時間内での支払いの未完了を契機として別の依頼ユーザを決定したが、これ以外の契機に別の依頼ユーザを決定してもよい。例えば、決定手段１０２は、決定した依頼ユーザがＳＮＳからログアウトした場合に、別の依頼ユーザを決定する。この場合、決定手段１０２は、第２実施形態で述べたようにＳＮＳにログインして依頼ユーザのアカウントを参照し、ログインしていた状態からログオフした状態になった場合に、別の依頼ユーザを決定する。
【０１０５】
他にも、決定手段１０２は、複数の依頼ユーザを決定した場合に、依頼ユーザ毎に異なる時間だけ支払いを待ち、それらの時間が経過するたびに順次別の依頼ユーザを決定してもよい。例えばユーザ１、２及び３に対して１時間、２時間及び３時間支払いを待つものとして、決定手段１０２は、ユーザ１の支払いがないまま１時間経過すると、ユーザ４を別の依頼ユーザとして決定し、ユーザ２の支払いがないまま２時間経過すると、ユーザ５を別の依頼ユーザとして決定するといった具合である。
【０１０６】
［６−６］利用ユーザへの通知方法
また、上記の各実施形態では、情報処理装置１０がサービス料金の支払い状況を利用ユーザに通知したが、これに限らず、例えばＳＮＳサーバ装置４０が通知してもよいし、サービスサーバ装置５０が通知してもよい。または、特定支払い方法で用いられる電子決済システムが通知してもよい。いずれの場合も、通知を行う主体となる装置が、支払い状況を示す状況情報を取得し、支払いが完了したことを示す状況情報を取得した場合に、この通知を行えばよい。なお、これらの場合には、情報処理装置が通知手段１０６を備えていなくてもよい。
【０１０７】
［６−７］サービス料金の支払い方法
依頼ユーザによるサービス料金の支払い方法は、上述したものに限らない。例えば、依頼データが示すＵＲＬにアクセスすると、利用ユーザに関連付いた有料サービスの内容を示す情報が表示され、依頼ユーザがそのうちの支払いを行う有料サービスを選択すると、図７に示すような支払いサイトが表示されて支払いが行われる。また、依頼ユーザが支払いを行ったときに、第２ユーザ端末３０に対して支払いが完了したことを証明する証明データが送信され、その証明データを第１ユーザ端末２０を経由して情報処理装置１０に渡すことで、その情報処理装置１０が有料サービスを提供するようにしてもよい。
【０１０８】
［６−８］依頼データを送信する宛先
送信手段１０３は、上述した各実施形態では、決定手段１０２により決定された依頼ユーザに対応する宛先に依頼データを送信したが、これに限らず、例えば予め決められた宛先に依頼データを送信してもよい。例えば、有料サービスを利用するユーザが共通して用いる立て替えのための決済手段があり、その決済手段での支払いを依頼するために用意された宛先に送信手段１０３が依頼データを送信するという場合である。また、外部装置から通知された宛先に送信手段１０３が依頼データを送信してもよい。要するに、送信手段１０３は、依頼された支払いが行われることになっていれば、どのような宛先に依頼データを送信してもよい。なお、本変形例では、情報処理装置は、決定手段１０２を備えていなくてもよい。
【０１０９】
［６−９］外部装置での有料サービスの提供
情報処理装置は、提供手段１０５を備えていなくてもよい。例えば、有料サービスが媒体への出力を行わなくても利用ユーザに提供可能な場合がある。その場合、サービスサーバ装置５０から第１ユーザ端末２０に結果データを送信することで有料サービスが提供されるから、情報処理装置が提供手段１０５を備えていなくてもよい。この場合でも、情報処理装置の送信手段１０３が依頼データを送信することで、料金の支払い方法が決まっているサービスをその方法で料金を支払えないユーザに提供するための依頼がされることになる。
【０１１０】
［６−１０］通信販売を有料サービスとして提供
情報処理システムでは、通信販売が有料サービスとして提供されてもよい。この場合、情報処理装置は、利用ユーザにより直接操作されるのではなく、ネットワーク２を介して第１ユーザ端末２０とデータをやり取りすることで、利用ユーザに有料サービスを提供する。この場合も、情報処理装置が依頼ユーザを決定して依頼データを送信することで、料金の支払い方法が決まっているサービスをその方法で料金を支払えないユーザに提供するための依頼がされることになる。また、情報処理装置は、ＳＮＳのアカウントや電子メールアドレスを利用して依頼データを送信する代わりに、例えば通信販売に登録しているユーザ同士が交流するためのアカウントを利用して依頼データを送信してもよい。ユーザ同士の交流は、例えば口コミ情報の投稿などを通して行われる。
【０１１１】
［６−１１］或る事項に応じた動作
図５及び図１２で説明した動作において用いられるテーブルは、それらの図に示したものに限らない。例えば、テーブルの行数は２以上であればいくつでもよい。また、昇順（または降順）に並べられているものを降順（または昇順）に並び替えてもよいし、そのような順番に関係なく並び替えをしてもよい。また、テーブルを用いずに、各セルの内容を数値で表し、数式を用いて算出される値を用いてもよい。図１２（ａ）の例であれば、例えば、交流の履歴を２０で減算した値を優先度として算出する、といった具合である。この場合、交流の履歴が４０であれば優先度が２、３０であれば優先度が１．５となる。要するに、これらの動作では、或る事項（図１２（ａ）の例であれば交流の履歴）に応じて他の事項（図１２（ａ）の例であれば優先度）が決まるようになっていればよい。
【０１１２】
［６−１２］発明のカテゴリ
本発明は、情報処理装置及び情報処理装置を備える情報処理システムの他にも、情報処理装置等の装置が実施する処理を実現するための情報処理方法としても捉えられるものである。ここでいう処理とは、例えば、図１０に示す課金処理である。また、本発明は、情報処理装置のようなコンピュータを、図３等に示す手段として機能させるためのプログラムとしても捉えられるものである。このプログラムは、それを記憶させた光ディスク等の記録媒体の形態で提供されたり、インターネット等のネットワークを介して、コンピュータにダウンロードさせ、それをインストールして利用可能にするなどの形態でも提供されたりするものであってもよい。
【符号の説明】
【０１１３】
１…情報処理システム、２…ネットワーク、１０…情報処理装置、２０…第１ユーザ端末、３０…第２ユーザ端末、４０…ＳＮＳサーバ装置、５０…サービスサーバ装置、１１…制御部、１２…記憶部、１３…通信部、１４…操作部、１５…表示部、１６…画像形成部、１７…電子決済部、１０１…判定手段、１０２…決定手段、１０３…送信手段、１０４…取得手段、１０５…提供手段、１０６…通知手段
【図１】
2015011608.tif 000003
【図２】
2015011608.tif 000004
【図３】
2015011608.tif 000005
【図４】
2015011608.tif 000006
【図５】
2015011608.tif 000007
【図６】
2015011608.tif 000008
【図７】
2015011608.tif 000009
【図８】
2015011608.tif 000010
【図９】
2015011608.tif 000011
【図１０】
2015011608.tif 000012
【図１１】
2015011608.tif 000013
【図１２】
2015011608.tif 000014
【図１３】
2015011608.tif 000015
【図１４】
2015011608.tif 000016
【図１５】
2015011608.tif 000017