JP6465166B2 - 電子機器 - Google Patents

Description

本発明は、電子機器に関する。

従来より、気に入らないプレゼントをもらわないようにしたり、プレゼントが重複したりしないようにするために、サーバを介在させてユーザが知人にプレゼントを要求するおねだり機能が提案されており、その一部は実現化されている（例えば、特許文献１参照）。

特開２００２−３１２６１３号公報

しかしながら、従来のおねだり機能は個人あてのおねだりであったため、プレゼントのやりとりの態様によっては、当該おねだり機能を使えないことがあった。

そこで、本発明は上記の課題に鑑みてなされたものであり、複数人による商品の共同購入を支援することが可能な電子機器を提供することを目的とする。

本発明の電子機器は、第１グループの購入品又は購入予定品に関する情報を取得する情報取得部（２６，２１）と、前記情報取得部が取得した情報に基づいて、前記第１グループとは異なる第２グループに前記第１グループの購入品又は前記購入予定品に関連する商品の情報を提供する情報提供部（２６，２１）と、を備えた電子機器である。

この場合において、本発明の電子機器は、前記第１グループと前記第２グループとの少なくとも一方のグループのメンバーを自薦又は他薦により募集する募集部（２６）を備えていてもよい。この場合、前記募集部は、前記商品を受け取る人からの指定により他薦メンバーを募集することとしてもよい。

本発明の電子機器においては、前記情報提供部は、前記関連する商品の購入場所に関する情報を提供することとしてもよい。この場合において、本発明の電子機器は、前記第２グループの各メンバーの位置情報を検出する位置情報検出部（２６，２１）を備え、前記情報提供部は、前記第２グループの各メンバーの位置情報に基づいて、前記関連する商品の購入場所に関する情報を提供することができる。

また、前記情報提供部は、前記第２グループの人数に関する情報に基づいて、前記関連する商品の情報を提供することとしてもよい。また、前記情報提供部は、前記関連する商品の情報として、前記第１グループの購入品又は購入予定品よりも安価な商品の情報を提供することとしてもよい。また、前記情報提供部は、前記第２グループからの要求に応じて前記関連する商品の情報を提供することとしてもよい。

また、本発明の電子機器は、イベント情報を記憶するイベント記憶部（２３）を備えており、前記情報提供部は、前記イベント記憶部に記憶されたイベント情報を前記第１、第２グループへ提供することとしてもよい。また、本発明の電子機器は、複数のメンバーを、各メンバーの属性に応じて前記第１グループと、前記第２グループとにグルーピングする調整部（２６）を備えていてもよい。また、本発明の電子機器は、前記第１グループのメンバーの画像及び／又は前記第２グループのメンバーに関連する人の画像を記憶する画像記憶部（２３）を備えていてもよい。この場合、本発明の電子機器は、前記第１、第２グループが購入した商品を受け取る人に対する通知情報を前記画像記憶部に記憶されている画像を用いて作成する作成部（２５）を備えていてもよい。

なお、本発明をわかりやすく説明するために、上記においては一実施形態を表す図面の符号に対応つけて説明したが、本発明は、これに限定されるものではなく、後述の実施形態の構成を適宜改良しても良く、また、少なくとも一部を他の構成物に代替させても良い。更に、その配置について特に限定のない構成要件は、実施形態で開示した配置に限らず、その機能を達成できる位置に配置することができる。

本発明の電子機器は、複数人による商品の共同購入を支援することができるという効果を奏する。

一実施形態に係る情報処理システムの構成を示す図である。 携帯機器の外観図である。 一実施形態に係る情報処理システムのブロック図である 携帯機器からサーバに対してプレゼント依頼者の登録を行うためのフローチャートである。 プレゼント依頼者登録画面の一例を示す図である。 プレゼント依頼者ＤＢの一例を示す図である。 候補者入力画面の一例を示す図である。 候補者ＤＢの一例を示す図である。 図９（ａ）は、依頼者追加確認画面の一例を示す図であり、図９（ｂ）は、メッセージ画面の一例を示す図である。 プレゼント希望登録画面の一例を示す図である。 候補者の受諾を得るための処理を示すフローチャートである。 図１２（ａ）は、連絡画面の一例を示す図であり、図１２（ｂ）、図１２（ｃ）は、確認画面の一例を示す図である。 真の候補者ＤＢの一例を示す図である。 プレゼント依頼処理を示すフローチャートである。 イベント連絡画面を示す図である。 図１４のステップＳ２１０の具体的処理を示すフローチャートである。 図１７（ａ）〜図１７（ｃ）は、親族グループに対する依頼画面の例を示す図である。 友人グループに対する依頼画面の例を示す図である。 図１９（ａ）は、受諾者テーブル（親族）の一例を示す図であり、図１９（ｂ）は、受諾者テーブル（友人）の一例を示す図である。 選択画面の一例を示す図である。 情報提供画面の一例を示す図である。

以下、一実施形態について、図１〜図２１に基づいて、詳細に説明する。図１には、一実施形態に係る情報処理システム１の構成が概略的に示されている。

情報処理システム１は、図１に示すように、複数の携帯機器１０と、サーバ２０と、クチコミ情報部４０と、を備える。携帯機器１０、サーバ２０及びクチコミ情報部４０は、インターネット等のネットワーク８０に接続されている。

携帯機器１０は、携帯電話やスマートフォン、ＰＨＳ（Personal Handy-phone System）、ＰＤＡ（Personal Digital Assistant）などの機器である。なお、本実施形態では、プレゼントをもらう側のユーザが利用する携帯機器を「携帯機器１０Ａ」又は「依頼側の携帯機器１０Ａ」と呼び、プレゼントをあげる側のユーザが利用する携帯機器を「携帯機器１０Ｂ」又は「被依頼側の携帯機器１０Ｂ」と呼ぶものとする。

携帯機器１０Ａは、電話機能、インターネット等に接続するための通信機能、及びプログラムを実行するためのデータ処理機能等を有する。携帯機器１０Ａは、一例として、携帯機器１０の外観図である図２に示すように、長方形の主面（図２の−Ｙ面）を有する薄板状の形状を有し、片手の手のひらで把持することができる程度の大きさを有している。

携帯機器１０は、図２及び情報処理システム１のブロック図である図３に示すように、表示部１１、入力部１２、撮像部１３、ＧＰＳ（Global Positioning System）モジュール１４、通信部１５、及び制御部１６を有する。

表示部１１は、例えば液晶表示素子を用いたデバイスであり、画像、各種情報、及びボタン等の操作入力用画像を表示する。入力部１２は、本実施形態においては、表示部１１の表面に設けられたタッチパネルであり、ユーザが表示部１１の表面（入力部１２）に触れたという情報や、ユーザの指の動きに応じた情報を入力する。なお、入力部１２は、テンキーなどのキーボードであってもよい。

撮像部１３は、撮影レンズや撮像素子（ＣＣＤおよびＣＭＯＳデバイス）を有する。本実施形態の撮像部１３は、ユーザやユーザが欲しい商品などを撮像するために用いられる。なお、この撮像部１３は、図２に示すように、表示部１１と同じ面に設けることとしてもよいし、表示部１１とは異なる面（裏面）に設けることとしてもよい。また、撮像部１３は、両面に設けることとしてもよい。ＧＰＳモジュール１４は、携帯機器１０の位置（例えば緯度や経度）を検出するセンサである。通信部１５は、ネットワーク８０を介してサーバ２０や他の携帯機器１０と通信する。通信部１５は、例えば、インターネット等の広域ネットワークにアクセスする無線通信ユニット、Bluetooth（登録商標）による通信を実現するBluetooth（登録商標）ユニット、及び、Felica（登録商標）チップ等を有するものとする。

制御部１６は、ＣＰＵを有し、携帯機器１０Ａの各部を統括的に制御するとともに、プレゼントに関する各種処理を行う。

被依頼側の携帯機器１０Ｂは、サーバ２０を介した携帯機器１０Ａからのプレゼント要求に応答するための機器である。携帯機器１０Ｂは、図３に示すように、携帯機器１０Ａと同様、表示部３１、入力部３２、撮像部３３、ＧＰＳモジュール３４、通信部３５及び制御部３６を有している。なお、それぞれの構成要素は、携帯機器１０Ａと同一又は同等の構成とすることができるので、その説明を省略するものとする。

サーバ２０は、依頼側の携帯機器１０Ａから入力された入力情報に基づいて、被依頼側の携帯機器１０Ｂに対してプレゼントのリクエストを行う機能を有する。サーバ２０は、図３に示すように、通信部２１、メモリ２３、カレンダ部２４、画像処理部２５および調整・制御部２６を有する。

通信部２１は、依頼側の携帯機器１０Ａ、被依頼側の携帯機器１０Ｂ、及びクチコミ情報部４０と通信を行い、各種情報を取得（入力）する。通信部２１は、インターネット等の広域ネットワークにアクセスする無線通信ユニット、Bluetooth（登録商標）による通信を実現するBluetooth（登録商標）ユニット、及び、Felica（登録商標）チップ等を有する。

調整・制御部２６は、ＣＰＵを有し、サーバ２０の各部を制御するとともに、プレゼントのやり取りが適切に行われるようにするための各種制御・処理を行う。例えば、調整・制御部２６は、プレゼントを購入するまでの各種調整（プレゼントを贈る側の人（被依頼者（候補者））の人数の調整や、被依頼者（候補者）の属性・カテゴリ調整（選別）、商品を決定するための調整、後述する依頼者主体モード及び候補者主体モードの調整、その他各種情報の調整など）を行う。なお、本実施形態においては、サーバ２０にアプリケーションのソフトウエアがインストールされることで、調整・制御部２６の機能が実現されている。

メモリ２３は、不揮発性のメモリ（例えばフラッシュメモリ）であり、携帯機器１０Ａ，１０Ｂの撮像部１３、３３で撮像された画像、クチコミ情報部４０から取得した情報や画像、プレゼントの履歴などの各種情報、後述するデータベースなどを記憶している。

カレンダ部２４は、年、月、日、時刻といった時間情報を取得して、調整・制御部２６に出力する。また、カレンダ部２４は、計時機能を有する。

画像処理部２５は、メモリ２３に記憶されている複数の画像の少なくとも一部を用いて、新たな画像を生成する処理を行う。例えば、画像処理部２５は、プレゼントの画像と、贈り主の画像とを合成する処理などを行う。

次に、上記のように構成される本実施形態の情報処理システム１における処理について、図４〜図２１に基づいて詳細に説明する。

（依頼側のユーザ登録処理）
図４は、携帯機器１０Ａからサーバ２０に対してユーザ（依頼側のユーザ）がプレゼント依頼者の登録を行うためのフローチャートである。なお、プレゼント依頼者は、携帯機器１０Ａのユーザ自身であってもよいし、ユーザ以外の人物であってもよい。この図４の処理は、携帯機器１０Ａと、サーバ２０との通信が成立した状態で開始される。

図４の処理では、ステップＳ１０において、サーバ２０の調整・制御部２６が、携帯機器１０Ａからの登録開始指示が出されるまで待機する。この場合、携帯機器１０Ａのユーザが、入力部１２を介してユーザ登録の開始ボタンを押すなどした段階で、ステップＳ１２に移行する。

ステップＳ１２に移行すると、調整・制御部２６は、通信部２１を介して、携帯機器１０Ａに対して、プレゼント依頼者登録画面（図５参照）を送信する。このプレゼント依頼者登録画面には、図５に示すように、プレゼント依頼者の氏名、生年月日、連絡先（例えば、メールアドレス）を入力する欄、恒例イベントの有無を入力するチェックボックス、「登録」、「キャンセル」ボタンが設けられているものとする。

次いで、ステップＳ１４では、調整・制御部２６が、携帯機器１０Ａのユーザによってプレゼント依頼者登録画面の各欄への入力が行われ、登録ボタンが押されるまで待機する。この場合、携帯機器１０Ａのユーザによって、登録ボタンが押された段階で、ステップＳ１６に移行する。

ステップＳ１６に移行すると、調整・制御部２６は、通信部２１を介してプレゼント依頼者の氏名、生年月日、連絡先（メールアドレス等）、恒例イベントの有無を取得（入力）し、取得した情報をメモリ２３に格納されているプレゼント依頼者ＤＢ（図６参照）に登録する。

なお、本実施形態では、携帯機器１０Ａのユーザが、ユーザの子供（氏名「ＡＡＡＢＢＢ」）をプレゼント依頼者（依頼者ＩＤ＝００１）として登録したものとして以下説明する。ただし、これに限らず、ユーザは、ユーザ自身あるいは子供以外の他人をプレゼント依頼者として登録することとしてもよい。

ここで、恒例イベントとは、プレンゼント依頼者の生年月日とカレンダ部２４の情報とから自動的に抽出することが可能なイベント（例えば誕生祝い、入学祝い、クリスマスといったイベント）を意味する。したがって、ユーザが、プレゼント依頼者登録画面において、恒例イベント有りのチェックボックスをチェックした場合には、調整・制御部２６は、各恒例イベントの前にプレゼント依頼を自動的に行う、又は恒例イベントごとにプレゼント依頼を行うかを携帯機器１０のユーザに確認するような処理を実行する。なお、プレゼント依頼者がユーザ本人である場合で、恒例イベントの前にユーザの確認を必要とせずに自動的にプレゼント依頼を行うような場合には、ユーザにとって予期せぬプレゼント贈ることができるという効果（サプライズ効果）がある。一方、ユーザが、恒例イベント無しのチェックボックスをチェックした場合には、イベントが発生するごとにユーザ自身がプレゼント依頼を行う必要がある。

次いで、ステップＳ１８においては、調整・制御部２６が、プレゼント依頼者のプレゼント要求に応じてくれそうな人（候補者）を入力するための候補者入力画面（図７参照）を携帯機器１０Ａに対して送信する。ここで、候補者入力画面には、図７に示すように、候補者の氏名、属性、生年月日、連絡先（メールアドレス等）、目安金額を入力する欄と、依頼者主体モードと候補者主体モードのいずれかを選択するためのチェックボックス、「登録」、「次の候補者入力」、「キャンセル」ボタンが含まれているものとする。

属性の欄には、祖父母や叔父叔母、友人（ママ友）などのカテゴリを入力することができるものとする。また、目安金額の欄には、候補者に要求できそうな金額を入力することができるものとする。なお、目安金額の欄への入力は必須であってもよいし、必須でなくてもよい。また、入力された属性ごとに目安金額が自動で入力されるようにしてもよい。なお、自動で入力された目安金額は後で修正できるようにしてもよい。

依頼者主体モードは、携帯機器１０Ａのユーザやプレゼント依頼者がプレゼントの内容を指定する主導権を握るモードであり、候補者主体モードは、候補者がプレゼントの内容を決定する主導権を握るモードである。なお、例えば、属性の欄に、祖父、祖母や叔父、叔母などが入力された場合には、調整・制御部２６は、自動的に依頼者主体モードにチェックを入れ、友人（ママ友）が入力された場合には、自動的に候補者主体モードにチェックを入れるようにしてもよい（ただし、後でユーザが変更できるものとする）。また、前述したように、プレゼント依頼者登録画面（図５）において恒例イベント有りが選択され、かつ調整・制御部２６がイベントごとのプレゼント依頼者への確認を行わないような場合には、調整・制御部２６は、候補者主体モードで固定する（候補者主体モードのみ選択できる）ようにしてもよい。

次いで、ステップＳ２０では、調整・制御部２６が、携帯機器１０Ａ上において登録ボタンが押されるまで待機する。なお、携帯機器１０Ａのユーザは、候補者入力画面の「次の候補者入力」のボタンを押すことにより、複数の候補者の情報を入力できるものとする。

携帯機器１０Ａのユーザが、登録ボタンを押すと、ステップＳ２２に移行し、調整・制御部２６は、入力された候補者の情報を候補者ＤＢ（図８参照）に登録する。図８では、祖母、叔母、２人のママ友の４人がプレゼント依頼者ＩＤ「００１」に対応する候補者として登録された状態が示されている（ただし、ステップＳ２２の段階では、候補者ＤＢの「プレゼント希望」の欄は空欄であるものとする）。

なお、本実施形態においては、属性が祖父や祖母である場合には、恒例イベントの全てにおいて候補者になるというルールが調整・制御部２６において定められているものとする。また、属性が叔父叔母である場合には、恒例イベントのうち入学式や成人式において候補者になり、属性がママ友である場合には、恒例イベントのうちクリスマスにおいて候補者になるというルールが調整・制御部２６において定められているものとする。ただし、これに限らず、携帯機器１０のユーザが、各属性ごとに候補者になるイベントのルールを定めることができるようにしてもよい。

次いで、ステップＳ２４では、調整・制御部２６が、プレゼント依頼者の追加があるかをユーザに問い合わせるための画面（依頼者追加確認画面：図９（ａ）参照）を携帯機器１０Ａに対して送信する。次いで、ステップＳ２６では、調整・制御部２６は、ユーザによって「はい」、「いいえ」のいずれのボタンが押されたかを確認することで、プレゼント依頼者の追加があるか否かを判断する。ここでの判断が肯定された場合（「はい」が押された場合）には、ステップＳ１２に戻り、ステップＳ１２〜Ｓ２６の処理・判断を繰り返す。一方、ステップＳ２６の判断が否定された場合（「いいえ」ボタンが押された場合）には、ステップＳ２８に移行する。

ステップＳ２８に移行すると、調整・制御部２６は、ユーザが設定した候補者がプレゼント依頼者になった場合に、ユーザ自身が当該プレゼント依頼者に対してプレゼントをあげることを希望するかどうかを問うメッセージ画面（図９（ｂ）参照）を通信部２１を介して携帯機器１０Ａに対して送信する。なお、メッセージ画面には、図９（ｂ）に示すように、「候補者に対してプレゼントをあげることを希望しますか？」などのメッセージと、「希望する」、「希望しない」ボタンとを含まれているものとする。この場合、携帯機器１０Ｂのユーザは、「希望する」、「希望しない」ボタンのいずれかを押すものとする。

次いで、ステップＳ３０では、調整・制御部２６が、携帯機器１０Ａのユーザが「希望する」ボタンを押したか否かを判断する。ここでの判断が否定された場合には、図４の全処理を終了するが、肯定された場合（プレゼントする候補者として自薦した場合）には、ステップＳ３２に移行する。

ステップＳ３２に移行すると、調整・制御部２６は、通信部２１を介してプレゼント要求があった場合に受諾する可能性のある人の入力（チェック）を行うための画面（プレゼント希望登録画面：図１０参照）を携帯機器１０Ａに対して送信する。次いで、ステップＳ３４では、調整・制御部２６が、携帯機器１０Ａのユーザによって登録ボタンが押されるまで待機し、押された段階で、ステップＳ３６に移行する。なお、本実施形態では、図１０の画面上において祖母、叔母、ママ友の全てにチェックを入れた状態で登録ボタンが押されたものとする。

ステップＳ３６に移行すると、調整・制御部２６は、候補者ＤＢ（図８）のうち、図１０のプレゼント希望登録画面上でチェックされた候補者に対応するプレゼント希望の欄に「○」を登録し、チェックされていない候補者に対応するプレゼント希望の欄に「×」を登録する。その後は、図４の全処理を終了する。

なお、図７の候補者入力画面上において候補者を登録する際に、プレゼントをあげることを希望するか否かを入力できるようにしてもよい。この場合、図４のステップＳ３０〜Ｓ３６を省略することができる。

なお、詳細は図１１の処理の説明において述べるが、図４のステップＳ２２で候補者として登録したユーザであっても、当該ユーザが受諾しない限りは、プレゼント要求対象のユーザ（被依頼者又は真の候補者と呼ぶ）にはなりえないものとする。

（候補者の受諾を得るための処理）
次に、図１１に基づいて、調整・制御部２６によって行われる候補者の受諾を得るための処理について説明する。なお、図１１の処理は、図４の処理において新たな候補者が候補者ＤＢに登録された後に開始される処理である。

図１１の処理では、ステップＳ１０２において、調整・制御部２６が、図４のステップＳ２２で登録された候補者の携帯機器１０Ｂに対し、通信部２１を介して、連絡画面（図１２（ａ）参照）をメール等により送付する。なお、連絡画面には、候補者となることを受諾するか否かを問うメッセージと、登録内容（図４のステップＳ２２で登録された内容）と、「受諾する」、「受諾しない」ボタンと、回答希望期限（図１２では１週間）の記載が含まれている。なお、候補者として受諾した場合でも、プレゼント依頼の連絡があるだけであり、必ずしもプレゼントをしなくてはいけないというものではない。したがって、図１２の連絡メールにその旨を記載しておいてもよい。

次いで、ステップＳ１０４では、調整・制御部２６は、候補者から回答があったか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１１２に移行するが、判断が否定された場合には、ステップＳ１０６に移行する。なお、候補者は、図１２（ａ）の連絡画面の登録内容を編集した上で、「受諾する」ボタンを押すこともできるものとする。

ステップＳ１０４の判断が否定されてステップＳ１０６に移行すると、調整・制御部２６は、所定時間経過したか否かを判断する。なお、ここでの所定時間とは、回答期限よりも短い期限で、回答期限から導き出される連絡画面を再送するのに適した時間であるものとする。ここでの判断が肯定された場合には、ステップＳ１０８に移行し、調整・制御部２６は、回答期限内であるか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１０２に戻る。一方、ステップＳ１０８の判断が否定された場合、すなわち、所定回数（例えば３回）連絡画面を送信したにもかかわらず、回答期限内に回答が得られなかった場合には、ステップＳ１１０に移行する。

ステップＳ１１０に移行した場合、調整・制御部２６は、候補者が受諾を拒否したものと判定し、ステップＳ１１２に移行する。

ステップＳ１１２に移行した場合、調整・制御部２６は、候補者による登録内容の編集有無を確認する。なお、本実施形態においては、ママ友「ＫＫＫＬＬＬ」からクリスマスに加えて誕生会のイベント追加があったものとする。

次いで、ステップＳ１１４では、調整・制御部２６は、候補者の回答内容（受諾したこと）と、登録内容と、回答期限と、を記載した確認画面（図１２（ｂ）参照）を携帯機器１０Ａのユーザ又はプレゼント依頼者（ここでは、携帯機器１０Ａのユーザとする）に送信する。なお、候補者が受諾を拒否した場合には、調整・制御部２６は、例えば、図１２（ｃ）に示すような画面をユーザ又はプレゼント依頼者に送信するものとする。

次いで、ステップＳ１１６では、調整・制御部２６は、携帯機器１０Ａのユーザから回答があったか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１１８に移行するが、判断が否定された場合には、ステップＳ１２４に移行する。なお、携帯機器１０Ａのユーザが図１２（ｃ）においてＯＫボタンを押した場合にも、ステップＳ１１６の判断は肯定されることになる。

ステップＳ１１６の判断が否定されてステップＳ１１８に移行すると、調整・制御部２６は、所定時間経過したか否かを判断する。なお、ここでの所定時間とは、回答期限よりも短い期限で、回答期限から導き出される確認画面を再送するのに適した時間であるものとする。ここでの判断が肯定された場合には、ステップＳ１２０に移行し、調整・制御部２６は、回答期限内であるか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１１４に戻る。一方、ステップＳ１２０の判断が否定された場合、すなわち、所定回数（例えば３回）連絡画面を送信したにもかかわらず、回答期限内に回答が得られなかった場合には、ステップＳ１２２に移行する。

ステップＳ１２２では、調整・制御部２６は、携帯機器１０Ａのユーザが受諾を拒否したものと判定し、ステップＳ１２４に移行する。

ステップＳ１２４に移行すると、調整・制御部２６は、候補者に対して携帯機器１０Ａのユーザによって受諾されたこと又は拒否されたことの連絡をメール等を用いて行う。そして、次のステップＳ１２６では、調整・制御部２６は、携帯機器１０Ａのユーザと候補者との間で受諾し合った場合には、その受諾内容を図１３に示す真の候補者ＤＢに格納する。なお、図８には、祖母「ＡＡＡＣＣＣ」、叔母「ＤＤＤＦＦＦ」が、登録内容を編集せずに候補者になることを受諾し、ママ友「ＫＫＫＬＬＬ」が、登録内容を編集して候補者になることを受諾した場合の例が示されている。以上の処理により図１１の全処理が終了する。

なお、図１１の処理開始段階において、プレゼント依頼者「ＡＡＡＢＢＢ」に対してプレゼントをあげることを希望する人が別に存在する場合（図８の候補者ＤＢで、ＡＡＡＢＢＢに対するプレゼント希望を表明している場合）もある。このような場合には、当該プレゼントをあげることを希望する人（ここでは、従兄弟とする）の携帯機器に対して、図１２と同様の連絡画面を送信することとしてもよい。この場合、図１１の処理を経ることで、プレゼントをあげることを希望する従兄弟を真の候補者ＤＢ（図１３）に登録することが可能となる。

（プレゼント依頼処理）
次に、図１４のフローチャートに沿って、候補者に対してプレゼントを依頼する処理について詳細に説明する。なお、図１４の処理は、プレゼントに関するイベントの数週間前になった段階で開始される処理であるものとする。以下においては、一例として、プレゼント依頼者（ＡＡＡＢＢＢ）の誕生日の数週間前になった場合について説明する。

図１４の処理では、まず、ステップＳ２０２において、調整・制御部２６は、図６のプレゼント依頼者ＤＢを参照してプレゼント依頼者に対する連絡を行う。この場合、調整・制御部２６は、通信部２１を介して、プレゼント依頼者（又は携帯機器１０Ａのユーザ）に対して、図１５に示すようなイベント連絡画面を送信する。なお、図１５のイベント連絡画面には、プレゼント依頼をするかしないかを回答するためのボタンと、欲しいものを入力する欄と、画像を添付する欄と、送信ボタンとが含まれる。

次いで、ステップＳ２０４では、調整・制御部２６が、回答があるまで待機する。なお、ここでは、図１１のステップＳ１０４〜Ｓ１１０、Ｓ１１６〜Ｓ１２２と同様、回答期限を設定し、回答がなければ当該回答期限内に連絡画面を複数回送信するようにしてもよい。この場合、回答期限内に回答がなければ、調整・制御部２６は、プレゼント依頼を行わない、又は依頼者主体モードを候補者主体モードに変更して依頼する、などすることとしてもよい。

なお、本実施形態においては、プレゼント依頼者「ＡＡＡＢＢＢ」から欲しいものとして「赤い自転車」の回答が得られ、プレゼント依頼者「ＡＡＡＢＢＢ」の最近の画像が添付されていたものとする。

ステップＳ２０６に移行した場合、調整・制御部２６は、回答が肯定的であったか否かを判断する。ここでの判断が否定された場合には、図１４の全処理を終了するが、肯定された場合には、ステップＳ２０８に移行する。

ステップＳ２０８に移行すると、調整・制御部２６は、図１３の真の候補者ＤＢを参照して、イベント「誕生日」に対応する候補者を確認する。ここでは、図１３から、祖母「ＡＡＡＣＣＣ」、叔母「ＤＤＤＦＦＦ」、ママ友「ＫＫＫＬＬＬ」が候補者として確認されることになる。また、調整・制御部２６は、不図示の属性−グループ対応表等を用いて、祖母と叔母は「親族」のグループに属し、ママ友は「友人」のグループに属することについて確認する。なお、グループの確認を行うのは、同一のグループに属している候補者であれば、複数の候補者が集まってプレゼントすることにより個別にプレゼントするよりも高価なプレゼントができる一方、異なるグループの候補者が集まってプレゼントすることは現実的には少ないからである。また、グループを作ることにより居住地が離れていたとしても、同一のグループの属している候補者がプレゼント依頼者に対してプレゼントを行うことができる。更に、調整・制御部２６は、図１３の真の候補者ＤＢを参照して、祖母「ＡＡＡＣＣＣ」、叔母「ＤＤＤＦＦＦ」が「依頼者主体モード」であり、ママ友「ＫＫＫＬＬＬ」が「候補者主体モード」であることを確認する。

次いで、ステップＳ２１０では、調整・制御部２６が、プレゼントのプレゼント要求があったことを候補者へ連絡するとともに、プレゼントに関する情報提供および収集を行う。具体的には、調整・制御部２６は、図１６のフローチャートに沿った処理を実行する。

調整・制御部２６は、図１６のステップＳ３０２において、「親類」グループの祖母及び叔母に対して、プレゼント依頼者「ＡＡＡＢＢＢ」が欲しいものの情報と、依頼者の画像を含む依頼画面（図１７（ａ）参照）を送信する。具体的には、図１７（ａ）に示すように、調整・制御部２６は、誕生日に欲しいプレゼントの名称「赤い自転車」と、メモリ２３に記憶されている又はネットワーク８０を介して外部（例えばクチコミ情報部４０など）から取得した赤い自転車の画像と、プレゼント依頼者から送付された画像とを含めた依頼画面を作成して、送信する。なお、調整・制御部２６は、依頼画面を作成する際に、図１７（ｂ）に示すように、プレゼント依頼者「ＡＡＡＢＢＢ」と同じ年齢の子供が赤い自転車に乗っている画像や情報をクチコミ情報部４０から取得して添付してもよいし、図１７（ｃ）に示すように、同じ年齢の子供が赤い自転車に乗っている画像にプレゼント依頼者の顔の画像を合成して添付してもよい。この場合の画像合成は、図２の画像処理部２５が行うものとする。このようにすることで、祖母や叔母は、プレゼントした商品を使用するプレゼント依頼者の様子をイメージしやすくなる。なお、調整・制御部２６は、依頼画面において、購入金額の負担について問い合わせることとしてもよい。この場合、一例として、均等、お任せ、５０％、５千円などから選択できるようにしておけばよい。

次いで、ステップＳ３０４では、調整・制御部２６が、通信部２１を介して、「友人」グループのママ友「ＫＫＫＬＬＬ」に対して、プレゼント依頼者「ＡＡＡＢＢＢ」の誕生日のプレゼント依頼通知と、プレゼントに関する情報提供を含む依頼画面（図１８参照）を送信する。

例えば、プレゼントに関する情報提供として、プレゼント依頼者が受け取ったことがある物、最近買った物の情報を提供すれば、プレゼントが過去のプレゼントと重複するのを防止することができる。また、プレゼントに関する情報提供として、受け取った又は買ったプレゼントの履歴から導き出される、プレゼント依頼者が嗜好するジャンル（ゲームやＤＶＤなど）の情報を提供すれば、プレゼントする物を決める際の参考となる。

この場合、ママ友「ＫＫＫＬＬＬ」は、図１８の依頼画面上において情報提供内容を確認した上で、「希望商品」や「希望しない商品」の欄にプレゼントしたい又はしたくない商品名を記入した後に「受諾する」ボタンを押すか、あるいは何も記入せずに「受諾しない」ボタンを押すことになる。なお、「希望しない商品の欄」に記入する事項は、プレゼント依頼者に関する情報（プレゼント依頼者が欲しがらないであろう商品の情報）であるといえる。

次いで、ステップＳ３０６では、調整・制御部２６は、各グループに属する全員から回答があるまで待機する。なお、ここでは、図１１と同様、回答期限を設けたり、回答期限内に複数回依頼画面を送ったりすることとしてもよい。また、回答期限内に回答がなかった場合には、拒否したものと判断してもよい。なお、本実施形態では、全ての候補者からプレゼント要求を受諾する旨の回答があったものとする。その後は、図１４のステップＳ２１２に移行する。

なお、プレゼント要求を承諾する回答を行う場合に、候補者など（ママ友であれば、候補者の子供）の画像を添付できるようにしてもよい。この場合、携帯機器１０Ｂの不図示のメモリに格納されている画像を添付するようにしてもよいし、撮像部３３を用いて撮像した画像を添付するようにしてもよい。なお、サーバ２０のメモリ２３に、候補者などの画像データが既に記憶されているような場合には、画像の撮像を省略してもよい。なお、添付された画像の利用方法については後述する。

なお、ステップＳ２０２に先駆けて上記ステップＳ２１０の処理を行うようにしてもよい。この場合、候補者の人数が決定してからステップＳ２０２を行うことになる。

次いで、ステップＳ２１２では、調整・制御部２６が、ステップＳ２１０で取得した候補者の回答に基づき、候補者の決定及び情報の整理を行う。本実施形態では、図１９（ａ）の受諾者テーブル（親族）に示すように、２名の候補者が赤い自転車を購入することを受諾し、祖母「ＡＡＡＣＣＣ」の希望金額が「おまかせ」、叔母「ＤＤＤＦＦＦ」の希望金額が「１万円」であったものとする。ここで、調整・制御部２６は、親類の等級に基づいてプレゼント金額の総額および負担額の調整をするものとする。具体的には、プレゼント依頼者にとって祖母は第２親等であり、叔母は第３親等である。したがって、調整・制御部２６は、例えば、叔母の希望金額「１万円」に基づいて、祖母の希望金額を叔母の金額の１．５倍（１万５千円）とするなどすればよい。なお、同一親等の候補者が複数存在し、各候補者の希望金額が「おまかせ」であった場合には、同一金額にすればよいし、同一親等の候補者が複数存在し、希望金額がバラバラであった場合には、最も低い希望金額で統一するようにしてもよい。また、商品の購入金額となるように各候補者の金額を調整（例えば、各候補者に対して同一金額を上乗せしたり、希望金額に応じた割合で上乗せするなど）してもよい。

また、調整・制御部２６は、図１９（ｂ）の受諾者テーブル（友人）に示すように、「友人」グループのママ友「ＫＫＫＬＬＬ」が、プレゼント要求に同意したことと、希望しない商品として最新のゲームソフト名「ＸＸＸＸ」が入力されたことを確認する。なお、希望しない商品として入力される商品は、例えば、ママ友「ＫＫＫＬＬＬ」の子供が購入済みであり、プレゼントしてしまうと友達同士で重複してしまう商品などが想定される。

次いで、図１４のステップＳ２１４では、調整・制御部２６は、１人の候補者（受諾者）を特定する。

次いで、ステップＳ２１６では、調整・制御部２６は、特定した候補者が、依頼者主体モードか候補者主体モードかを判断する。ここでの判断が肯定された場合（特定した候補者が祖母や叔母であった場合）には、ステップＳ２１８に移行する。

ステップＳ２１８に移行すると、調整・制御部２６は、プレゼント依頼者（又は携帯機器１０Ａのユーザ）に対して赤い自転車に関する情報を提供して（図２０の選択画面参照）、ユーザにプレゼントを決定してもらう。例えば、調整・制御部２６は、図２０に示すように、調整・制御部２６が調整した金額以下の自転車の情報をクチコミ情報部４０から収集して、３車種程度の自転車の画像や仕様、クチコミ情報をユーザに送付する。この場合、本願出願人が特願２０１２−４５８４８号にて提案したように、クチコミ情報部４０が信頼性の高いクチコミ情報を取得して、ユーザに信頼性の高いクチコミ情報を送付すれば、本情報処理システム１の信頼性を向上させることができる。

次いで、ステップＳ２２０では、調整・制御部２６が、回答があるまで待機する。なお、調整・制御部２６は、図１１と同様、回答期限を設定してもよいし、回答期限内に図２０の選択画面を複数回送信してもよい。回答期限内に回答がなければ、調整・制御部２６が、最も人気のある車種やクチコミの評価が最も高い車種を自動的に選択することとしてもよいし、候補者（受諾者）に車種を選択させてもよい。その後は、ステップＳ２２６に移行する。

一方、ステップＳ２１６の判断が否定された場合（候補者主体モードであった場合）には、ステップＳ２２２に移行し、調整・制御部２６は、候補者であるママ友「ＫＫＫＬＬＬ」へ情報提供を行う。この場合、調整・制御部２６は、ママ友の候補者が希望商品を入力していた場合には、その商品の情報をママ友の候補者に提供する。一方、希望商品が入力されなかった場合には、調整・制御部２６は、希望しない商品を除外したうえで、友人グループの購入品として、親族グループの購入品に関連する商品の情報を提供する。本実施形態では、親族グループの購入品が「赤い自転車」であるので、調整・制御部２６は、赤い自転車に合った色のヘルメット（２千円程度）の情報（図２１に示すような情報提供画面）をママ友「ＫＫＫＬＬＬ」に対して提供するものとする。

次いで、ステップＳ２２４では、調整・制御部２６が、回答があるまで待機する。なお、この場合においても、調整・制御部２６は、回答期限を設定してもよいし、回答期限内に図２１の選択画面を複数回送信してもよい。なお、回答期限内に回答がない場合や、回答はあったものの拒否された場合には、調整・制御部２６が、設定された金額で子供に人気のある商品の情報をクチコミ情報部４０から入手して、再度、情報提供を行うようにしてもよい。なお、候補者（受諾者）が複数存在する場合には、回答期限内に少なくとも１人から回答があれば、その回答を全員の総意として扱うこととしてもよい。なお、ステップＳ２２４の後は、ステップＳ２２６に移行する。

ステップＳ２２０又はＳ２２４の処理を経て、ステップＳ２２６に移行すると、調整・制御部２６は、候補者（受諾者）全員を特定したか否かを判断する。ここでの判断が否定された場合には、ステップＳ２２８において、次の候補者（受諾者）を特定した後、ステップＳ２１６に移行する。その後は、ステップＳ２１６〜Ｓ２２８の処理・判断を繰り返し、ステップＳ２２６の判断が肯定された段階で、ステップＳ２３０に移行する。なお、ステップＳ２１４〜Ｓ２２８の処理は、候補者（受諾者）全員に対して同時にステップＳ２１６〜Ｓ２２４の処理を実行し、全員の回答が得られた段階で、ステップＳ２３０に移行するような流れとしてもよい。

ステップＳ２３０に移行すると、調整・制御部２６は、ステップＳ２２０，ステップＳ２２４の回答に基づいて購入品を決定する。ここでは、親族グループの購入品として赤い自転車が決定され、友人グループの購入品としてヘルメットが決定されたものとする。なお、依頼者がヘルメットを既に所有している場合も考えられるので、候補者主体モードで決定された商品については、プレゼント依頼者に対して所有の有無を問い合わせるようにしてもよい。

次いで、ステップＳ２３２では、調整・制御部２６が、通信部２１を介して不図示の購入サイトに対して自転車とヘルメットの購入手続きを行うとともに、画像添付処理を行う。この場合、画像処理部２５は、プレゼントの自転車に添付する画像を作成するために、プレゼントする自転車の画像の周りに、祖母や叔母の顔の画像を配置した合成画像を作成する。同様に、画像処理部２５は、プレゼントのヘルメットの画像の周りにママ友「ＫＫＫＬＬＬ」の子供の顔の画像を配置した合成画像を作成する。そして、調整・制御部２６は、不図示の購入サイトに対して購入手続きをする際に、画像処理部２５が作成した合成画像を添付して、当該合成画像をプレゼントに添付する（メッセージカードのようにプレゼントと同封する）旨を連絡する。なお、調整・制御部２６は、後日、候補者（受諾者）に対して、購入金額を請求する。この場合、調整・制御部２６は、例えば、振込先を記載したメールを各候補者（受諾者）に送付するなどすればよい。

以上、詳細に説明したように、本実施形態によると、調整・制御部２６は、通信部２１を介して、複数の候補者に商品の共同購入に関する情報を提供し、調整・制御部２６は、商品に関する調整を行うので、複数の候補者がプレゼントを共同購入する場合であっても、購入商品の調整や支払額の調整などにより、共同購入を簡易に行うことが可能となる。このため、高価なプレゼント（カメラや携帯端末などのデジタル機器）をもらうことが可能となり、また、デジタル機器のアクセサリ（レンズ、スピーカ、ヘッドホン、記憶媒体）を合わせてもらうことが可能となる。

また、本実施形態では、調整・制御部２６は、商品の決定に関してプレゼント依頼者を主導にするか候補者を主導にするか（依頼者主体モードにするか候補者主体モードにするか）を、例えば候補者の属性に基づいて定めることから、候補者の属性に応じた適切な商品の決定が可能である。

また、本実施形態では、調整・制御部２６は、プレゼント依頼者に関する情報（例えば、図１８の依頼画面に表示されている情報）を複数の候補者に提供するため、候補者は、当該提供された情報に基づいて、購入したい商品（希望商品）を決定したり、購入したくない商品（希望しない商品）を決定したりすることができる。

また、本実施形態では、調整・制御部２６は、図１８の依頼画面を用いて、複数の候補者からプレゼント依頼者に関する情報や商品に関する情報（例えば、希望しない商品の情報）を収集するので、候補者の有する情報に基づいて、プレゼントする商品を決定することが可能となる。

また、調整・制御部２６は、複数の候補者をプレゼント依頼者に対する属性に基づいて複数のグループ（親族グループや友人グループ）にグルーピングし、複数のグループごとに、異なる情報を提供する。これにより、共同購入が属性の近い人の集まり（グループ）ごとに行われることになるため、円滑な共同購入を実現することができる。

また、調整・制御部２６は、図８に示すように、各候補者に応じて設定されたイベントの情報に基づいて、複数の候補者にプレゼントに関する情報を提供するので、イベントごとに適切なプレゼントのやりとりを行うことができる。

また、本実施形態では、調整・制御部２６が、複数の候補者の画像や商品の画像を取得し、これらを用いてプレゼントに添付する画像を画像処理部２５に合成させるので、プレゼントに添付する添付書類（メッセージカードなど）を簡易に作成することができる。

また、調整・制御部２６は、プレゼント依頼者の画像を用いて図１７に示す依頼画面を作成するので、候補者は、当該画像を見ることで、プレゼントした商品を使用するプレゼント依頼者の様子を容易にイメージすることができる。

また、本実施形態では、調整・制御部２６は、親族グループの購入品又は購入予定品に関する情報に基づいて、友人グループに親族グループの購入品又は購入予定品に関連する商品の情報を提供するので、プレゼント依頼者は、自己が主導して選んだ商品とそれに関連する商品とを１つのイベントにおいてもらうことができる。

なお、調整・制御部２６は、親族グループに情報を提供するタイミングを、友人グループに情報を提供するタイミングよりも早くする、すなわち、親族グループの購入商品が決定した後に友人グループに情報を提供するようにしてもよい。このようにすることで、親族グループの購入商品に付随する商品を友人グループが贈る商品として決定するなどすることができる。

なお、プレゼント依頼者は、買い替えを必要とする商品がある場合には、その型番と、最新機種が欲しい旨を入力することとしてもよい。この場合、調整・制御部２６が、型番に対応する最新機種の情報を候補者に提供するようにすればよい。

なお、上記実施形態では、イベントごとのプレゼント依頼に応じてプレゼントの調整を行う場合について説明したが、これに限られるものではない。例えば、候補者が旅行をしていることがサーバ２０に入力された場合には、調整・制御部２６は、プレゼント依頼者に対して、プレゼント（おみやげ）を欲しいか否かを問い合わせることとしてもよい。この場合、プレゼント依頼者が、欲しいおみやげのジャンルや商品名などを携帯機器１０Ａの画面上で入力すれば、調整・制御部２６は、当該入力された情報を候補者に対して通知することができる。これにより、プレゼント依頼者の希望に沿ったおみやげを購入することができるようになる。

また、上記実施形態では、イベントが予め定められているような場合について説明したが、これに限られるものではない。例えば、生年月日などからは予測できないようなイベント（例えば、合唱コンクールで優勝した場合など）が発生したような場合には、プレゼント依頼者からのイベントの入力に応じて、調整・制御部２６は、臨時のプレゼント依頼を行うようにしてもよい。また、プレゼント依頼者に臨時のイベントが発生したことに、候補者が気づいたときには、候補者がその旨をサーバ２０に登録できるようにしてもよい。この場合、調整・制御部２６は、当該登録された臨時のイベントに対するプレゼント依頼を、候補者の全て又は少なくとも一部に対して行うこととすればよい。

なお、プレゼント依頼者がブログやtwitterやＳＮＳなどを行っている場合には、調整・制御部２６は、これらからプレゼント依頼者の情報（好きなジャンルや最近購入した商品、嗜好など）を取得して、プレゼントの候補を選定するようにしてもよい。

また、上記実施形態では、依頼者主体モードにおいて、プレゼント依頼者が「赤い自転車」との要求を出す場合について説明したが、これに限られるものではない。例えば、プレゼント依頼者は、メーカや、型番、値段などを指定してプレゼント依頼することとしてもよい。この場合において、候補者側の予算が、指定された値段よりも高い場合には、調整・制御部２６は、指定された型番に基づいてアップグレードの調整を行い、候補者側の予算が指定された値段よりも低い場合は、調整・制御部２６はダウングレードの調整を行うようにしてもよい。

また、上記実施形態では、プレゼントする商品の決定やプレゼントの購入まで、サーバ２０が行う場合について説明したが、これに限られるものではない。例えば、プレゼントの決定までをサーバ２０側で行い、実際の購入は候補者に行わせるようにしてもよい。この場合、調整・制御部２６は、携帯機器１０ＢのＧＰＳモジュール３４の位置情報のログ（候補者が普段生活している位置範囲）に基づいて、商品を購入する店舗を調整（決定）し、通信部２１を介して、携帯機器１０Ｂに対して店舗の所在に関する位置情報を提供するようにしてもよい。また、店舗の所在とともに、クチコミ情報部４０によりその店舗のクチコミ情報を提供するようにしてもよい。この場合、特に、店舗の候補が複数ある場合には、クチコミ情報によりそれぞれの店舗を比較することができる。

なお、上記実施形態では、情報処理システム１を私生活において利用する場合について説明したが、これに限られるものではない。例えば、情報処理システム１をビジネスに使用することとしてもよい。この場合、恒例のイベントとしてお中元やお歳暮などを加えてもよく、カレンダ部２４から予測できないイベントとして、昇進や退職（寿退職など自己都合の退職）、出産などを加えてもよい。

また、上記実施形態では、携帯機器１０として、電話機能のある片手サイズの大きさの機器を採用した場合について説明したが、これに限らず、タブレット型コンピュータやパーソナルコンピュータを採用してもよい。

なお、上記実施形態では、サーバ２０が、共同購入に関する各種処理を行う場合について説明したが、これに限らず、サーバ２０が行った処理を携帯機器１０Ａ内の制御部１６が行うこととしてもよい。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

１０ 携帯機器
２０ サーバ
２１ 通信部
２３ メモリ
２５ 画像処理部
２６ 調整・制御部

Claims (7)

1. イベントの情報と、人物に関する情報と、前記人物の属性情報と、を記憶する記憶部と、
   前記イベントごとに、前記人物の属性情報に含まれる、前記イベントにおいて商品を受け取る人との関係に少なくとも基づいて、前記商品の購入費用を分担する候補者を、前記人物の中から決定する決定部と、
   前記候補者を、前記人物の属性情報に基づいて、第１グループと、前記第１グループとは異なる第２グループと、に分類する分類部と、
   前記商品の共同購入に関する第１情報を前記第１グループに含まれる前記候補者の電子機器に送信し、前記第１情報とは異なる、前記商品の共同購入に関する第２情報を前記第２グループに含まれる前記候補者の電子機器に送信する情報提供部と、
   を備える電子機器。
2. 前記候補者の前記電子機器に入力された情報に基づいて、前記候補者によって実際に購入される商品、前記実際に購入される商品を購入する場所、及び前記実際に購入される商品の前記候補者の負担金額の少なくとも１つを調整する調整部、
   を備える請求項１記載の電子機器。
3. 前記調整部は、前記候補者によって実際に購入される商品の調整に関して前記商品を購入する候補者を主導にするか、前記商品を受け取る人を主導にするかを調整する、請求項２に記載の電子機器。
4. 前記情報提供部は、前記商品を受け取る人の画像と、前記商品の画像とを合成した合成画像を前記候補者の前記電子機器に送信する、請求項１から３のいずれか一項記載の電子機器。
5. 前記合成画像は、前記商品を受け取る人が、前記商品を使用している状態を示す画像である、請求項４記載の電子機器。
6. 前記第１グループの購入品又は前記第１グループの購入予定品に関する情報を取得する情報取得部を備え、
   前記情報提供部は、前記第１グループの購入品又は前記第１グループの購入予定品に関連する商品の情報を前記第２グループに提供する、請求項１から５のいずれか一項記載の電子機器。
7. 前記情報提供部は、前記第１グループの購入品又は前記第１グループの購入予定品と共に使用される商品に関する情報を前記関連する商品の情報として送信する、請求項６記載の電子機器。

Images