(57)【要約】【課題】  安心して気軽に他人とコミュニケーションをとることのできるサービスを実現するための情報処理装置、情報処理方法及び情報処理システムを提供することを目的とする。【解決手段】    上記課題を解決するために、例えば、サービス業者が所有するサーバが、登録者及び登録者に関するデータを記憶し、該記憶された登録者からメールを受信し、該受信したメールの内容と該登録者に関するデータとに基づいて送信相手を少なくとも1つ選択し、該選択された少なくとも１つの選択相手にメールを送信するように構成すればよい。【選択図】  図４
2005084948.tif 000002
【特許請求の範囲】
【請求項１】
登録者及び登録者に関するデータを記憶し、
該記憶された登録者からメールを受信し、
該受信したメールの内容と該登録者に関するデータとに基づいて送信相手を1つ選択し、
該選択された１つの選択相手にメールを送信することを特徴とする情報処理方法。
【請求項２】
請求項１記載の情報処理方法において、
前記選択相手にメールを送信する場合に前記受信したメールのメールアドレスを秘匿するように制御することを特徴とする情報処理方法。
【請求項３】
請求項１記載の情報処理方法において、
前記登録者からメールを受信する場合にメール内容のジャンルを特定するためのジャンルデータを受信し、前記受信したジャンルデータを基に送信相手を選択するように制御することを特徴とする情報処理方法。
【請求項４】
請求項１記載の情報処理方法において、
前記送信相手を選択する際にランダムに送信相手を選択するように制御することを特徴とする情報処理方法。
【請求項５】
登録者に関するデータを有する登録者データベース、課金に関するデータを有する課金データベース及び広告に関するデータを有する広告データベースを記憶し、
該登録者データベースに記憶された登録者からメールを受信すると該受信したメールの内容に基づいて該登録者データベースに記憶された送信相手を少なくとも1つ選択し、
該登録者の該登録者データベースに記憶されたプロフィール情報を参照し、
該参照したプロフィール情報に広告データの視聴を要求する旨が記載されてあった場合に該広告データベースより広告データを抽出して該メールに付加し、受信したメールのメールアドレスを異なるメールアドレスに変換し、該選択された送信相手に該広告データが付加されたメールを送信することを特徴とする情報処理方法。
【請求項６】
請求項５記載の情報処理方法において、
前記メールを送信後に前記課金データベース及び前記広告データベースを更新することを特徴とする情報処理方法。
【請求項７】
請求項５記載の情報処理方法において、
前記参照したプロフィール情報に広告データの視聴を要求しない旨が記載されてあった場合に広告データを該メールデータに付加せずに送信することを特徴とする情報処理方法。
【請求項８】
請求項５記載の情報処理方法において、
前記送信相手を選択する際にランダムに送信相手を選択するように制御することを特徴とする情報処理方法。
【請求項９】
請求項５記載の情報処理方法において、
前記送信相手を選択する際に前記プロフィール情報に基づいて送信相手を選択するように制御することを特徴とする情報処理方法。
【請求項１０】
登録者及び登録者に関するデータを記憶する記憶部と、
該記憶された登録者からメールを受信する受信部と、
該メールの内容と該登録者に関するデータとに基づいて送信相手を少なくとも1つ選択し、該選択された少なくとも１つの選択相手にメールを送信する送信部とを有することを特徴とする情報処理装置。
【請求項１１】
メールソフトを記憶する記憶部と、
該記憶部により記憶されたメールソフトの起動を指示するメール起動指示部と、
該メール起動指示部により該メールソフトを起動した後にメールの送信相手の人数を指定する送信相手人数指定部と、
該送信相手人数指定部により指定された人数にメールを送信するように制御する制御部とを有することを特徴とする情報処理装置。
【請求項１２】
請求項１１記載の情報処理装置において、
メールの送信相手をその送信相手が属するカテゴリから選択する送信相手選択部と、
該送信相手選択部により選択された該送信者にメールを送信するように制御する制御部とを有することを特徴とする情報処理装置。
【請求項１３】
広告データが付加されたメールを受信する受信部と、
該受信部により受信された該広告データが付加されたメールを表示する表示部と、
該表示部により該メールを表示する際に該受信部により受信された該メールに広告データが付加されている旨を通知する広告通知部と、
該広告データの表示を指示する広告表示指示部と、
該広告表示指示部により該広告の表示が指示された場合に該広告データを表示するように制御する制御部とを有することを特徴とする情報処理装置。
【請求項１４】
請求項１３記載の情報処理装置において、
前記広告データが簡易広告データと詳細広告データとを有し、
該簡易広告データまたは該詳細広告データの表示を選択する広告表示選択部とを備えることを特徴とする情報処理装置。
【請求項１５】
メールソフトを記憶する記憶部と、
該記憶部により記憶されたメールソフトの起動を指示するメール起動指示部と、
該メール起動指示部によりメールの起動がなされた後にメールの送信相手を選択する送信相手選択部と、
該送信相手選択部により送信相手を選択する際に該送信相手の返信に関する情報を表示するように制御する制御部とを備えることを特徴とする情報処理装置。
【請求項１６】
請求項１５記載の情報処理装置において、
前記返信に関する情報が、返信する確率、返信メールの内容に関する評価もしくは返信に有する時間であることを特徴とする情報処理装置。
【請求項１７】
他の装置と通信する通信部と、
該通信部を介してメールの送受信を行うためのメールソフトを記憶するメールソフト記憶部と、
画像情報を出力する撮像部と、
該撮像部により出力された画像情報に含まれる識別情報を認識する認識部と、
該メールソフト記憶部により記憶された該メールソフトの起動を指示を行うメールソフト起動指示部と、
メールの送信相手の人数を指定する送信相手人数指定部と、
メールの送信相手をその送信相手が属するカテゴリから特定する送信相手特定部と、
該認識部により該識別情報を認識した後に該メールソフト起動指示部により該メールソフトの起動の指示が行われると送信したい文字を入力するための本文欄及び送信相手先を指定するための宛先欄を少なくとも有するメール作成画面を表示するとともに該本文欄には該認識部により認識された該識別情報を挿入し、該宛先欄において送信相手を選択する際に該送信相手人数指定部により送信相手の人数を指定し、該送信相手特定部により送信相手を特定するための表示画面を表示するように制御する制御部とを備えることを特徴とする情報処理装置。
【請求項１８】
登録者、登録者の住所を示す住所データ及び登録者の現在の位置を示す現在位置データを記憶し、
該記憶された登録者からメールを受信し、
該メールの内容と該住所データもしくは該現在位置データとに基づいて送信相手を少なくとも1つ選択し、
該選択された少なくとも１つの選択相手にメールを送信することを特徴とする情報処理方法。
【請求項１９】
位置情報を検出する位置情報検出部と、
該位置情報検出部により検出された位置情報に基づいて所定領域の範囲を特定するための送信相手先範囲特定データを記憶する記憶部と、
該位置情報検出部により検出された該位置情報と該記憶部により記憶された該送信相手先範囲特定データとに基づいて送信相手の地域を示す送信相手先地域データを特定する送信相手地域特定部と、
他の装置と通信する通信部と、
該通信部を介してメールの送受信を行うためのメールソフトを記憶するメールソフト記憶部と、
該メールソフト記憶部により記憶された該メールソフトの起動を指示を行うメールソフト起動指示部と、
該メールソフト起動指示部により該メールソフトの起動の指示が行われ送信相手を選択する場合に該送信相手地域特定部により特定された該送信相手先地域データを送信する送信手段とを備えることを特徴とする情報処理装置。
【請求項２０】
サーバと第１の情報処理装置及び第２の情報処理装置とから構成される情報処理システムにおいて、
該サーバは、第１及び第２の情報処理装置からそれぞれの所有者のデータを受信し、該所有者のデータを記憶し、該第１の情報処理装置からメールを受信し、該メールの内容と該第１の情報処理装置の所有者に関するデータとに基づいて該第２の情報処理装置を送信相手として選択し、該選択された第２の情報処理装置にメールを送信することを特徴とする情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及び情報処理システムに関するものである。
【背景技術】
【０００２】
特開２００１−２７６４３６公報には、キャラクタとしての電子ペットが第３者を求めて自由にネット上を行き来することによりメール友達を勝手に探してくれて気安く多くの人とコミュニケーションを行う方法について開示されている。
【０００３】
【特許文献１】特開２００１−２７６４３６
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献１に開示された発明の利益を享受するためには、キャラクタとしての電子ペットを扱えるソフトウェアもしくは端末を自分はもちろん送信相手も所有する必要があった。
【０００５】
また、上記特許文献１では、キャラクタとしての電子ペットを介することで不特定の人と気軽にコミュニケーションがとれるメリットがあるが、プライバシー等の保護に関する検討が不十分であり、不必要に自分のメールアドレス等を通知する恐れがある。  
そこで、本発明は、上記問題点を克服し、なおかつ、プライバシーを保護しつつ他人とコミュニケーションをとることのできる情報処理装置、情報処理方法及び情報処理システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、例えば、特許請求の範囲の如く構成すればよい。
【発明の効果】
【０００７】
本発明によれば、使い勝手のよい情報処理装置、情報処理方法、情報処理システム及びソフトウェアを提供することができる。
【発明を実施するための最良の形態】
【０００８】
以下、本発明の実施の形態を、図面を用いて説明する。なお、以下の図面において、同一の構成部については同じ番号を用いる。
【０００９】
図１は、本実施形態（第1の実施形態）に係るシステム全体の構成図である。本実施形態では、ユーザ、サービスを行う主体であるサービス業者及びサービス業者に広告の依頼を頼む広告依頼者とから構成されるサービスについて説明する。ユーザは携帯電話１００を有し、また、サービス業者はサーバ２００を、広告依頼者はサーバ３００を有しているものとする。なお、ここでは、ユーザが所有する情報処理装置として携帯電話を考えたが、ＰＤＡやノートＰＣ等であっても構わない。
【００１０】
図２は、携帯電話１００の構成を示す図である。ＣＰＵ１０１は、記憶部１０４に記憶されたプログラム（例えば、メールソフト）に基づいて動作し、例えば、入力部１０５からの入力に応じて各部を制御するものである。
【００１１】
表示部１０２は、例えば、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electroluminesence）等で構成され、撮像部１０３により撮像された画像や画像認識部１０７により認識された文字情報等を表示する。その他、表示部１０２に、例えば、電源状態、電波強度、電池残量、サーバ接続状態、未読メール等の動作状態、入力した電話番号、メール宛先、メール送信文書等や、動画および静止画、着信時の発呼者の電話番号、着信メール文書、接続されたインターネット画面等の受信データの表示、更に、携帯電話の機能を利用するために必要な画面を表示する。
【００１２】
撮像部１０３は、例えば、カメラモジュールなどで構成されたものであり、被写体である人の顔や、景色、文字などを撮像し、ＣＰＵ１０２で扱える画像情報に変換し、変換された画像情報は必要に応じて表示部１０２等に出力する。ユーザは、表示部１０２に出力された画像情報をモニタしながら撮像したい画像を選んでシャッター等により撮像の指示を行う。シャッターが押下されれば、撮像された画像情報は記憶部１０４に記憶される。
【００１３】
記憶部１０４は、例えば、ＲＯＭ（Read Only Memory）やＲＡＭ(Random Access Memory)
等で構成され、携帯電話１００で扱うデータやメールソフト等のソフトウェア等も記憶す
る。入力部１０５は、キーボードやタッチパネルで構成され、電話番号その他の情報を入
力する入力部であり、携帯電話の電源をＯＮ/ＯＦＦするとき、被写体を撮像するとき等、ユーザが携帯電話に入力を与える際に使用するものである。
【００１４】
通信部１０６は、携帯電話１００がインターネットや他の携帯電話などにアクセスするための通信処理を行う。通信部１０６は、図２に示すように１つのみを使用する場合に限らず、例えば、ＣＤＭＡ、ＥＶ−ＤＯ、無線ＬＡＮ等の複数の通信方式を利用可能にするために複数備えても良い。画像認識部１０７は、画像情報に含まれる文字や記号等の識別情報を認識するものであり、詳細は後述する。
【００１５】
図３（１）は、サーバ２００の構成を示す図である。制御部２０１は、各部を統括的に制御するものである。データベース２０２は、種々のデータベースを記憶しており、本実施形態においては、サービスの登録者に関するデータからなる登録者データベース（以下、登録者ＤＢ）２０２１、課金に関するデータからなる課金データベース（以下、課金ＤＢ）２０２２及び広告に関するデータからなる広告データベース（以下、広告ＤＢ）２０２３を有する。なお、各データベースの具体例については後述する。
【００１６】
通信部２０３は、携帯電話等とデータのやり取りを行い、例えば、メールの送受信に関する通信処理を行う。送信相手選択部２０４は、通信部２０３を介して受信されたデータとデータベース記憶部２０２に記憶されたデータに基いてメールの送信相手先を選択するものである。入力部２０５は、外部より入力を受け付け、表示部２０５は、各種データを表示するものであり、例えば、データベース記憶部２０２の整理等を行う際に入力部２０５や表示部２０６は利用される。なお、制御部２０１が送信相手選択部２０４の処理を行うように構成しても構わない。
【００１７】
図３（２）は、サーバ３００の構成を示す図である。サーバ３００は、サーバ２００に対してサービス実行の際に宣伝したい広告データを供給するものである。サーバ３００は、制御部３０１、広告データ記憶部３０２、通信部３０３、入力部３０４、表示部３０５から構成される。
【００１８】
制御部３０１は、各部を統括的に制御し、広告データ記憶部３０２は、商品や会社等の宣伝データやサービス業者との契約に関する契約データを含む広告データを記憶する。入力部３０４は外部より入力を受け付け、表示部３０５は各種データを表示するものであり、例えば、広告データ記憶部３０２に記憶された広告データを整理するため等に入力部２０５や表示部２０６は用いられる。
【００１９】
なお、本実施形態では、サーバ２００とサーバ３００とを別々に設けたが、サーバ２００に広告データ記憶部３０２を設けるようにしてもよい。これにより、広告依頼者（サーバ３００）の設備負担を軽減するとともにサービス業者が広告データを一括管理することにより広告データの変更や調整等が効率的に行えるというメリットがある。
【００２０】
次に、本実施形態におけるサービスについて説明する。本サービスは、知らない人にも何かを伝えたい場面、例えば、ある作家の本を読んで感動し、とりあえず誰でもいいから話を聞いて欲しいといったときに簡単な操作で1または２以上の相手にメールを送信するといった場面について説明する。
【００２１】
しかし、知らない人とメールをやり取りする場合、いたずらメールを受信したり、何らかの犯罪に巻き込まれる恐れがある。そのため、本サービスでは、ユーザのメールアドレス等の個人情報を相手に通知しないようにする。
【００２２】
すなわち、本サービスの目的とするところは、知人等だけでなく知らない人ともメールのやり取りを通じて、新しい人と知り合う喜びを感じたり、知らない人からの意外なリアクションを楽しむといったことを安心して行えることを実現するものである。以下、本サービスを「風船メール（サービス）」と命名する。
【００２３】
次に、サービス業者が、メール転送する際に広告の付加有無を判定する場合について説明する。
【００２４】
以下、サーバ２００の処理について説明する。図４は、本サービスを実行する際のサーバ２００の処理を中心に記載したフローであり、ユーザＡからユーザＢにメールが送信される場合を想定した図である。ここで、ユーザＡが所有する携帯電話を携帯電話Ａ、ユーザＢが所有する携帯電話を携帯電話Ｂとする。
【００２５】
まず、電話や着信の待受状態において、ユーザＡによりサービスの実行指示がなされると（Ｓ４０１、Ｓ４０２）、サービス実行指示信号が携帯電話ＡのＣＰＵ１０１に入力され、当該ＣＰＵ１０１は、記憶部１０４に記憶されているメールソフトを起動する（Ｓ４０３）。メールソフトが起動されると、メール作成用の画面が表示部１０２に表示され、この表示画面を介してメールが作成される（Ｓ４０４）。
【００２６】
メール作成の際には、例えば、ユーザは入力部１０５を介してメール本文（件名や文章）を入力し、更に送信相手を選択する方法を指示する。ここでは、ユーザＡがランダムに送信相手が選択するように指示した場合について説明する。
【００２７】
ユーザによりメール送信の指示がなされれば、メール本文データ及び送信相手のランダム選択方法を示したランダム選択方法指示データがメールデータとしてＣＰＵ１０１及び通信部１０６を介してサーバ２００に送信される（４０５）。
【００２８】
メールデータを受信したサーバ２００は、メールデータを解析し、ユーザＡが本サービスの正規の登録者かどうかを登録者ＤＢ２０２１に基づいて認証する（Ｓ４０６，Ｓ４０７）。例えば、メールアドレスに基づいて認証する。認証の結果、ユーザＡが正規の登録者でなかったならば、サーバ２００の制御部２０１は、登録者でないことを示すエラーメッセージもしくは本サービスに加入を促すサービス勧誘メッセージを携帯電話Ａに送信する。正規の登録者であるならば、受信したランダム選択方法指示データに基づいて登録者ＤＢ２０２１に記憶された登録者の中から送信相手を選択して処理を続ける（Ｓ４０８）。
ここでは、ランダム選択の結果、ユーザＢの1人が選択されたものとする。
【００２９】
制御部２０１は、登録者ＤＢ２０２１に記憶されているユーザＢのプロフィール情報を参照する（Ｓ４０９）。制御部２０１は、広告データの視聴要求の有無を検出し（Ｓ４１０）、広告データ視聴要求が有りの場合は、広告ＤＢに記憶された広告データを受信したメールに付加するとともに広告ＤＢの広告累積回数を更新する（Ｓ４１１）。広告データ視聴要求無しの場合は、受信したメールに広告データを付加しない（Ｓ４１２）。その後、制御部２０１は、ユーザＡのメールアドレスを異なるメールアドレス、例えば、サービスを代表するメールアドレス等に変換してユーザＢに送信する（Ｓ４１３）。ユーザＢは、サーバ２００により送信されたメールを受信する。
【００３０】
このように、本実施形態では、メールアドレスを交換して送信することにより、送信者のプライバシーを保護することができる。
【００３１】
なお、ユーザＡのメールアドレスを秘匿する方法としては、上記方法に限定されるものではない。
【００３２】
送信後、サーバ２００は、メールデータのデータ通信量（パケット量）に応じて課金処理を行う。その際、上記Ｓ４１０において広告データ視聴要求が「有」だった場合は、所定の金額割り引いて課金ＤＢに記録するか、無料として取り扱う。一方、広告データ視聴要求が「無」だった場合は、通常どおりの金額で課金ＤＢに記録される。なお、送信相手は一人ではなく、複数人であっても構わない。
【００３３】
また、図４の例では、Ａ→Ｂに送信場合の処理を示しているが、ユーザＢがユーザＡに返信する際においても、同様に、ユーザＡが広告データの視聴を希望しているかどうかをサーバ２００は判定し、希望していると判定された場合だけ広告データはサーバ２００を介してユーザＡに送信される。また、ユーザＢのメールアドレスの秘匿変換処理も行う。
【００３４】
以上により、お互いのメールアドレスが秘匿処理されることで、安心して知らない人ともメールのやり取りを行うことができ、知らない人からの意外なリアクションを楽しむことができる。
【００３５】
このように、本実施形態のサービスによれば、通常ユーザに常時携帯される携帯電話を利用することで、例えば、会議と会議との間の空き時間や電車等での移動時間等のすきま時間を利用して、いつでもどこでも気軽に他人とコミュニケーンを取れる。
【００３６】
また、本サービスでは、ユーザが広告を視聴する場合は低額もしくは無料でメールサービスを利用できる。
【００３７】
更に、本サービスでは、サーバで大部分の処理を行わせるためにユーザは特別な端末や専用ソフトウェア等を用意する必要がない。従って、専用ソフトウェア等を搭載した端末同士のコミュニケーションに限定されることは無いため、ユーザに利用しやすい形態となっている。
【００３８】
次に，広告依頼者がサービス業者に広告データを供給する際の処理について説明する。この場合、広告依頼者は入力部３０４等を介して広告データをサーバ２００に送信する指示を行う。送信指示を受けた制御部３０１は、広告データ記憶部３０２から入力に応じた広告データを抽出し、当該広告データをサーバ２００に送信する。
【００３９】
広告データを受信したサーバ２００は、その広告データを広告ＤＢ２０２３に新規に記憶もしくは更新する。
【００４０】
これにより、広告依頼者は広告のバージョンアップや差し替えなどを容易に行えることができる。また、サービス業者にとってみれば、サービス実行の際に広告を簡単に付加できるとともに広告宣伝料の収入を得ることができる。その結果、安価なサービスを提供することができ、より多くの顧客創出が期待できる。
【００４１】
次に、サーバ２００のデータベース記憶部２０２が有する各データベースの具体例について図５を用いて説明する。
【００４２】
図５（１）は、登録者ＤＢ２０２１の例であり、登録者名、電話番号、メールアドレス及びプロフィール情報等を含んだデータベースとなっている。ここで、プロフィール情報とは、登録者に関する情報であり、例えば、図５（１）に示すように、性別、生年月日、広告の有無、所定のアンケートに対する返答意思の有無、登録者の得意ジャンル等である。当然のことながら、ここに列挙されたものに限定されるものではない。
【００４３】
また、得意ジャンルとは、ユーザが興味を示すものや得意な分野に関わるものであり、例えば、野球、料理、クラシック音楽等が挙げられる。
【００４４】
ここで、アンケートの返答意思が「有」に選択された登録ユーザは、メール送信相手からメールデータと共に所定のアンケートを受信する。なお、この際の処理は上述してきた例で「広告データ」であったところを「アンケートデータ」として同様に行えばよい。アンケート依頼者は、携帯電話のメール機能を利用することで、所定のアンケートを幅広くかつ確実にメールデータとして回収できる。
【００４５】
また、アンケートに対して返答を行う際にサーバ２００が自動的に性別や生年月日を付加して返信するようにすれば、ユーザはわざわざ入力する手間が省け、一方、アンケート依頼者はアンケート対象者の個人情報を容易に取得できる。
【００４６】
なお、上述してきたような登録者ＤＢ２０２１のデータは、サービス業者が入力部２０５を介して入力するようにしてもよいし、登録者データファイルを受信した制御部２０１が登録者ＤＢ２０２１に新たに登録するか、もしくは既存データを更新するようにしても構わない。
【００４７】
図５（２）は、課金ＤＢの例であり、例えば、登録者名、これまでの通話料を示す累積通話料、累積データ通信料、種々のサービス利用料金の合計金額である利用サービス料等から構成される。
【００４８】
図５（３）は、広告ＤＢの例であり、例えば、広告依頼者、広告方法、広告頻度、広告累積回数等から構成される。ここで、広告依頼者は、例えば、広告の掲載を希望する企業等である。広告方法とは、広告データを通知するための手段であり、例えば、テキストデータや音声データ等で表される。広告頻度とは、広告データとして携帯電話等に送信する頻度を示したもので、例えば、0.7だと10回中7回は広告データとして選択されることを意味する。すなわち、この頻度が高いほど携帯電話に広告データとして送信される確率が高くなる。この広告頻度は、例えば、広告依頼主からサービス業者に支払われる広告代金に応じて決定される。
【００４９】
なお、このように広告を付加する頻度に重み付けをせずに送信相手に広告データを送信するようにしても構わない。
【００５０】
広告累積回数は、サーバ２００が広告データを送信した回数を示したものである。なお、広告累積回数ではなく、サーバ２００が広告データを送信した人数を示した累積人数等であっても構わない。
【００５１】
また、上記では、ユーザが送信相手の選択方法をサーバに指示するように構成したが、これに限定するものではなく、サーバがメールデータの内容を読み取り自動的に送信相手を選択する方法を決定するようにしても構わない。
【００５２】
次に、登録者の得意ジャンルの項目を基に、サーバ２００が送信相手を検出する方法を図６のフローに基づいて説明する。
【００５３】
例えば、あるユーザが「メジャーリーグの○○選手について知りたい」というメールを送信したときに、当該メールを受信したサーバ２００は、メール解析処理を行う（Ｓ６０１、Ｓ６０２）。具体的には、予め記憶部１０４に記憶されたジャンルディレクトリに応じて「メジャーリーグ」「○○選手」→「野球」と推測処理を行い、ジャンルキーワード「野球」を検出する（Ｓ６０３）。そして、登録者ＤＢ２０２１から得意ジャンルが「野球」となっている登録者ＤＢ２２０１を検索し（Ｓ６０４）、該当する送信者を抽出する（Ｓ６０５）。ここで、ジャンルディレクトリとは、各ジャンル毎にその関連する単語を記憶した辞書データである。図７に示した図は、ジャンルディレクトリのジャンルが「野球」の例である。その後、ＣＰＵ１０１は、抽出された送信者にメールを送信する（Ｓ６０６）
以上のように、登録者ＤＢ２０２１に予め記録された登録者の得意ジャンルに基づいて送信相手が選択されるために、メールを送信したユーザは、返事を受ける確率が高くなる。また、メールを受信したユーザにとって自分の得意ジャンルについてのメールであるため、円滑なコミュニケーションが期待できる。
【００５４】
なお、ここでは、サーバ２００がジャンルディレクトリを検索してジャンルを特定するようにしたが、ユーザがメールを送信する際に当該メールの内容のジャンルを指定するようにしても構わない。これにより、ジャンルディレクトリ及びそれを用いた推測処理が不要となるためサーバ２００の記憶容量の効率的利用やＣＰＵ処理の負荷を低減できる。
【００５５】
図８は、本実施形態の表示画面例である。図８（１）は、登録者ＤＢ２０２１にユーザが登録する際の画面例である。ここでは、名前、性別、生年月日、広告の有無、アンケートの返事意思の有無、得意ジャンル等を登録項目としているが、これに限定するものではない。図８（２）は、サービス実行の選択画面例である。
【００５６】
図８（３）は、風船メールサービスを利用してメールを送信する際の表示画面例である。本実施形態では、ユーザがジャンル及び送信相手数を指定できるように構成している。ジャンル及び送信相手数を指定するための欄には、前回に本サービスを利用してメールを送信した際に指定したジャンル及び送信した送信相手数を記憶部１０４に記憶させておき、それぞれを表示させるようにしてもよい。これにより、ユーザはメール送信する際に過去の送信履歴を参考とすることができるため使い勝手がよい。
【００５７】
また、入力の方法は、ユーザが入力部１０５を介してプルダウン形式で入力するようにしたり、所定の操作キーを操作して入力するようにしても構わない。
【００５８】
図８（４）は、風船メールサービスを利用してメールを受信際の表示画面例である。受信されたメールに広告が付加されている場合を示しており、「広告を見る」ことを指示すると、図８（５）のような広告画面が表示される。
【００５９】
なお、ここでは、メール本文の表示と広告データの表示を図８（４）と（５）のように異なる表示画面で構成したが、メール本文が表示された同じ画面内に広告データを表示するようにしても構わない。この場合は、携帯電話の画面の大きさを考慮して、広告データの文字データの大きさを小さくしたり、アイコン等を利用して視覚的に分かり易く通知する。
【００６０】
また、アイコンや小さく表示された広告を指定したときのみ詳細な広告データを表示するようにしてもよい。図８（６）はこの場合の表示画面例を示す。このとき、サーバ２００は、広告に関する簡単なデータ（以下、簡易広告データ）と、当該広告について詳細な情報が記載されたデータ（以下、詳細広告データ）の両者を関連付けるようにして広告ＤＢ２０２３に記憶しておく。そして、メール本文を表示する際にメール本文の視聴の邪魔にならない位置に簡易広告データを表示し、入力部を１０５を介して詳細広告データの表示指示がなされれば、当該指示信号を受信したＣＰＵ１０１は、広告ＤＢ２０２３に記憶された当該詳細広告データを表示部１０２に表示する。これにより、ユーザはまず簡単な広告を見て、興味があったもののみ詳細な情報を参照することができる。
【００６１】
なお、サーバ２００は、登録者ＤＢに登録されたプロフィール情報に基づいて広告データを決定しても良い。例えば、送信対象のユーザのプロフィール情報の得意ジャンルが「音楽」の場合、サーバ２００は「音楽」に関する広告データを広告ＤＢ２０２３より抽出して送信するようにする。この場合、広告データは各ジャンルに対応付けられて広告ＤＢ２０２３に記憶されているものとする。もし、得意ジャンルに対応した広告データが無かった場合には、サーバ２００はランダムに他のジャンルの広告データを広告ＤＢ２０２３より選択して送信する。
【００６２】
これらにより、各登録ユーザの得意ジャンルに合わせた広告データが送信されるようになるので、当該広告が視聴される可能性はあがり、広告依頼主にとっては効果的な広告方法となる。また、ユーザも興味がある分野の広告を参照することができるというメリットがある。
【００６３】
なお、上記図２において、撮像部１０３と画像認識部１０７を用いる構成を想定したが、上記実施形態においては省略しても構わない。
【００６４】
次に、第２の実施形態について説明する。本実施形態は、ＯＣＲ（Optical Character Recognition）機能を用いて文字認識可能な携帯電話を利用したサービスについて説明する。具体的には、日常生活で見つけた単語や記号等を撮像部１３及び画像認識部１０７を利用して携帯電話に取り込み、当該単語等の意味やそれに関する意見・感想をメールを介して聞くといったサービスである。なお、前述の実施形態のように、サーバ２００はお互いのメールアドレスは秘匿するよう処理することにより、知人でない人にも安心してメールのやり取りを行うことができる。また、携帯電話やサーバ２００の構成図は図２及び図３で示したものと同様である。
【００６５】
画像認識部１０７は、前述したように、画像情報に含まれる文字や記号等の識別情報を認識する。ここで、識別情報とは、文字、記号等で表された情報であり、例えば、ホームページのアドレス、メールアドレス、住所、電話番号、地図情報あるいは英語の単語等のように文字や記号等で表現されたものであり、事物を識別できる情報であれば上記例以外のものでも構わない。また、ここで、認識とは、撮像部１０３により撮像された画像情報に含まれる識別情報を抽出し、その識別情報を所定の領域ごとに分割し、分割された領域を所定のパラメータ値に変換し、そのパラメータ値に基づいて分割された領域がどのような情報であるかを決定することをいう。より具体的にいえば、例えば、画像情報内の「abc」という文字を「認識」する場合を考えると、まず、「abc」が画像情報内のどの位置の情報であるかを特定し、次に、「a」「b」「c」に分割し、「a」を所定のパラメータ値（例えば、その文字を縦、横、斜めからの見た線分の構成を、文字の白色部分を「０」、黒色部分を「１」としてパラメータ化された値）に変換する。そして、変換されたパラメータ値に最も類似したパラメータ値と対応付けされた文字を文字パターンデータ表より選び出す。文字パターンデータ表とは、パラメータ値とそのパラメータ値に対応したアルファベット等の文字とが記述されている表であり、予め記憶されているものである。
【００６６】
ＣＰＵ１０１は、モード判定フラグを利用して、撮像モードが通常の静止画又は動画を撮像する通常撮像モードであるか、画像認識部１０７を利用して識別情報を認識するモードである認識モードであるかを判定する。ここで、モード判定フラグは、例えば、記憶部１０４に記憶されたソフトウェアのプログラム中に存在する変数で、認識モードの場合と通常撮像モードとでは異なる値になるようにし、ＣＰＵ１０１はこの変数に基づいて認識モードと通常撮像モードと、例えば、入力部１０５による操作により切り換える。以下、実施形態では、「認識モード」と「通常撮像モード」との２種類を有する場合を考えるが、これに限定されるものではなく、それ以外にモードがあっても構わない。
【００６７】
本実施形態における携帯電話の処理フローを図９に示す。まず、認識モードに移行する指示がされたＣＰＵ１０１は、認識モードに設定する（Ｓ９０１）。認識対象である認識対象単語の特定処理を行う（Ｓ９０２）。
【００６８】
例えば、認識対象単語が「イカロス」であるならば、ユーザが入力部１０５を利用して、上記「イカロス」の認識部分をカーソル等で指定できるようにする。また、認識対象単語が英文中の英単語の場合は、例えば、表示部１０２の中心に表示された「＋」マークを識別情報の上に持っていき、「＋」マークの位置から近傍のスペース情報からスペース情報までの部分を一区切りの単語として自動的に特定するようにしてもよい。また、動画の場合は、動画を静止画でコマ送りできるように設定しておき、そのコマ送り画面で認識対象部を選択できるようにしても構わない。
【００６９】
また、ここでは、ＣＰＵ１０１は、認識対象である「イカロス」を点線等で囲むように処理する。これは、認識対象の識別情報が撮像された画像情報内のどこに位置されているかをユーザが容易に把握できるようにするためである。その際、画像編集部において認識対象となる「イカロス」を拡大または縮小した画像を作成し、その画像を表示してもよい。拡大するには、例えば、１×１画素で表示していたところを２×２画素で表示する。さらに、画像編集部で認識対象となる文字の画像部分を白黒に変換したものやセピア色に変換したり、または、白黒反転したものを作成しその画像を表示したりしてもよく、画像内でどれが認識対象であるかが明確に分かるように表示すれば、上記例に限定されるものではない。
【００７０】
認識対象である識別情報を特定した後に、ＣＰＵ１０１は当該識別情報の認識処理を行う（Ｓ９０３）。そして、自動的もしくは手動で本サービスの実行が指示されれば、ＣＰＵ１０１は、表示部１０２にメール作成用の画面を表示する（Ｓ９０５）。ここでは、メール作成用画面は、送信相手先のメールアドレスを入力するための宛先欄、メールの件名を入力するための件名欄、メールの本文を入力するための本文欄及び画像ファイル等を添付するための添付欄とから構成されているものとする。Ｓ９０５の際に、ＣＰＵ１０１は、認識処理の結果を自動的に本文欄に挿入させる。これにより、ユーザはわざわざコピー＆ペースト等の不要な操作を省くことができる。なお、携帯電話が有する画像認識部はＣＰＵで構成してもよい。
【００７１】
また、上記では、自動的に本文欄に認識結果（例：「イカロス」）が挿入されるような構成をとったが、それだけでなく、ユーザ自らが入力部１０５を介してコメント等を入力できるようにしても構わない。これによれば、例えば、認識結果の「イカロス」の後に文章を付け加えて「イカロスって一体何なのですか？」と質問文を作成することが容易に行うことができる。また、その際に、認識結果とそれに付加した文章（イラストあるいは絵文字など含む）とを区別するために、それぞれを異なる色で表示したり、認識結果のみにアンダーラインを引いたり、認識結果の文字の大きさを変えたりしてもよい。
【００７２】
サーバ２００の処理は、上述してきたサーバ２００の処理と同様であるため、説明は省略する。
【００７３】
その後、メールの送信指示信号を受信したＣＰＵ１０１は、通信部１０６を介して送信相手先にメールを送信する（Ｓ９０６）。
【００７４】
以上により、本実施形態によれば、ユーザは携帯電話に備わった文字認識機能を利用することにより、上記第1の実施形態に示したサービスを利用する際の文字入力の手間を削減することができ、使い勝手がよい。これは、特に、ユーザが、例えば、雑誌や新聞等の記事を見ているときや、街を何気なく歩いている場合に、興味のある単語が目にとまり、その詳細な情報を誰かにいち早く伝えたい場合などに有効である。
【００７５】
また、上述してきたサービスを利用する際に、送信する側は気軽にメールを送信できるが、メールを受信する側にとってみれば、突然知らない人からメールを受け取る場合があり、ユーザによっては面倒臭くなり返事を出さない人もあるかもしれない。そうなると、送信する側にとってみれば、せっかくメールを送信したのに返事がこないことになり、寂しい思いをすることは必然的である。そのため、メールを受信した者が返信しやすい環境を作り出すことは非常に重要な課題となってくる。
【００７６】
そこで、以下、メールを受信した者がメールを返信しやすくなるするための方法、システムについて説明する。
【００７７】
まず、返信者の特典として、データ通信料を割り引くことについて説明する。本サービスにおいて受信したメールに返信すると、サーバ２００はその返信履歴を記憶しておき、返信履歴に対応して課金ＤＢ２０２３に記憶された累積データ通信料から所定の金額を割り引くといった処理を行う。また、一度返信メールを送れば、次の５回分のメール料は無料とか、２００円分データ通信無料といったようにしてもよい。このように、データ通信料を割り引くようにすることで、返信意欲を高めることができる。
【００７８】
次に、返信者の特典として、抽選で景品等があたる福引データをもらえる場合について説明する。この場合、返信者はサーバ２００より福引データを受信し、当該受信した福引データをもとに所定の景品等の抽選を行える。景品の抽選形式はどのようなものでも構わない。例えば、福引データが７桁の数字と考え、1等や2等に該当する７桁の数字（以下、当選数字）をルーレット等で予め決めておく。そして、当選数字に該当する、もしくは当選数字に近い福引データを所有する返信者に景品が届くようにする。このように、返信することで所定の景品等の抽選を行えるようにすれば、ユーザからの返答を促進できると考えられる。また、景品としては、車や自転車等だけでなく、音楽や動画などのデジタルコンテンツ、例えば、ＭＰ３、ＭＰＥＧ等であっても構わないのは言うまでもない。デジタルコンテンツの景品であれば、インターネット経由等で直ちに賞品をもらえるとともに包装紙等の余計なゴミを出す必要も無くなり、環境保全に貢献する。
【００７９】
また次に、返信者の特典として、返信率や返信した内容に応じたランキング表なるものを用いる場合について説明する。この場合、返信者により返信されたメールの内容を元の送信者が評価を行えるようにする。例えば、ユーザＡが「あなたの好きな国は？」というメールをユーザＢに送信し、ユーザＢが「動物王国」と返信した場合について説明する。ユーザＡがユーザＢからの返信を受信した際に、ＣＰＵ１０１は、「このメールの評価は？Ａ．良い  Ｂ.まあまあ  Ｃ.悪い」等の評価画面を表示をする。ユーザＡはこの評価画面を介してユーザＢからの返信メールを評価する。ここでは、ユーザＢからのシュールな返答にユーザＡは満足したものとし、「Ａ」を選択するものとする。
【００８０】
そうした場合、例えば、予め、Ａ：5点、Ｂ：3点、Ｃ：１点というように決められていたなら、5点を示す評価データがサーバ２００に送信される。評価データを受信したサーバ２００は、登録者ＤＢ２０２１に当該評価データに基づいて当該点数を加算していく。ここでは、登録者ＤＢの各登録者の欄には、返信評価データ欄が設けられている。このように集計された返信評価データを基に、サーバ２００は、順位を定めてランキング表を作成し、定期的にサービスの登録者に通知するか、あるいは、ランキング表を掲載しているＨＰ等を更新する。これにより、ユーザに競争意識を芽生えさせ、返信意欲を高めることができる。また、ランキング上位者に、例えば、景品等が当たりやすいとか、秘密のＨＰのアドレスを教えてもらえるといった特定の優遇措置を与えるようにすれば、更に、返信意欲を高めることができる。
【００８１】
上記実施形態では、サーバ２００は、ランダムに、もしくは、プロフィール情報に基づいて送信相手を選択するようにしたが、ユーザがある程度送信相手を選択できるようにしても構わない。以下、図１０を用いて説明する。
【００８２】
図１０（１）〜（５）は、登録者のプロフィール情報に基づいて得意ジャンル別、性別、地域別、返信・評価別といったカテゴリに送信相手候補を分類している場合の表示画面例を示したものである。
【００８３】
図１０（１）〜（３）は、例えば、ユーザが囲碁に関するコメントをメールで誰かしらに伝える場合の表示画面例である。この場合、ユーザにより「ジャンル別」が選択されると、各種のジャンルが表示部１０２に表示される（図１０（２））。更に、表示されたジャンルの中から「囲碁」が選択されると、プロフィール情報の得意ジャンルを囲碁とした登録者のニックネーム等が表示される（図１０（３））。その際に、図１０（３）に図示されるように、メールを受信したユーザがそのメールに対して返信する返信率、その返信メールの内容の評価等の返信に関する情報を表示するようにすれば、ユーザが送信相手を選択する際の参考となり便利である。
【００８４】
そして、表示された登録者のニックネーム等が少なくとも1つ選択されると、サーバ２００はその選択されたニックネーム等に該当する登録者を登録者ＤＢ２０２１から検索し、当該登録者のメールアドレス先へメールを送信する。
【００８５】
また、図１０（３）には図示していないが、メールを受信したユーザが返信するまでに要した時間（以下、返信時間）等も表示しても構わない。この場合、返信時間は、サーバ２００が送信相手にメールを送信した送信時刻を記憶しておき、当該送信メールに対して返信が来た時刻から上記送信時刻を差し引くなどの処理をして求められる。
【００８６】
図１０（４）（５）は、送信相手を選択する際に「地域別」を基に選択される場合の表示画面例である。図１０（５）に図示するように、例えば、「関西」等の地方別、「大阪」等の都道府県別、「八尾市」等の市長村別、もしくは「郵便番号」等を選択できるようにする。この場合、サーバ２００は、登録者ＤＢ２０２１にプロフィール情報として予め登録された住所データを基に各登録者を地方別、都道府県又は市町村等のカテゴリに分類しておく。携帯電話等により送信相手先のいる地域（以下、送信相手先地域）の指定がなされた場合、携帯電話のＣＰＵ１０１はその地域指定データをサーバ２００に送信し、地域指定データを受信したサーバ２００は、登録者ＤＢ２０２１より当該地域別データに該当するカテゴリの中から送信者を選択し、当該選択された送信者にメールを送信する。
【００８７】
更に、ＧＰＳ等の携帯電話の位置情報を検出する位置情報検出部が携帯電話１００に設けられている場合は、当該位置情報検出部により検出された位置情報に基づいて、送信相手先地域を自動的に特定しても構わない。
【００８８】
この場合、例えば、図１０（５）の画面において、「４．ＧＰＳ利用」が選択されれば、ＣＰＵ１０１は、位置情報検出部に携帯電話の現在位置を取得するように指示し、当該位置情報検出部により検出された位置情報と予め記憶部１０４に記憶された送信相手先範囲特定データとに基づいて送信相手先地域を特定する。
【００８９】
ここで、送信相手先範囲特定データとは、所定の位置ポイントに基づいて所定領域の範囲を特定するためのデータであり、例えば、半径５km以内の範囲といったことを示すものである。より具体的に説明すれば、例えば、大阪城に旅行に行った場合に、「４．ＧＰＳ利用」が選択されれば、ＣＰＵ１０１は、大阪城を中心に半径５km以内の範囲を送信相手先地域として特定し、サーバ２００に送信相手地域データを送信する。そして、当該送信先地域データを受信したサーバ２００は、当該範囲内の住所の登録者群を登録者ＤＢ２０２１から送信相手先の母集団とし、そこから、例えば、ランダムに５人といったように送信相手先を決定する。
【００９０】
これにより、ユーザは自分が現在いる位置に近い所に住所を有する他のユーザと気軽にメールのやり取りを行えるため、例えば、地域限定のローカル話に花を咲かせ、親近感あふれたコミュニケーションをとることができる。
【００９１】
また、ユーザによりサーバ２００に登録された住所とユーザが今いる位置とは必ずしも一致しない場合が多い。そこで、登録者ＤＢ２０２１にユーザの住所データのみならず、ユーザが今いる現在位置データも登録者ＤＢ２０２１に記憶するようにしても構わない。
【００９２】
この場合、ユーザは所定の操作を介して現在位置を示す現在位置データをＧＰＳ等により取得し、当該現在位置データをサーバ２００に送信する。そして、現在位置データを受信したサーバ２００は、登録者ＤＢ２０２１に予め登録された住所データと対応付けるように現在位置データを記憶する。サーバ２００は、登録者ＤＢ２０２１に登録された住所データ及び現在位置データを参照して送信相手先の母集団を決定する。
【００９３】
これにより、例えば、東京の住所を登録したユーザが大阪に出張したような場合に、東京の住所のみならず大阪の位置を登録できるため、送信相手先として「東京」を選択されたメールのみならず、「大阪」を選択されたメールも受信することができる。その結果、コミュニケーションを行う機会を拡大することができる。  
このように、サーバ２００がサービス登録者の位置に関する情報として住所データと現在位置データの両者を有することで当該サービスを充実させることができる。
【００９４】
また、上記サーバ２００は、住所データ及び現在位置データの両方を共に参照する構成を考えたが、図１０（６）のように、どちらか一方のみを優先的に参照するようにサーバ２００に指示できるようにしても構わないし、登録者の位置情報として任意の位置を示す位置データを登録者ＤＢ２０２１に登録できるようにしても構わない。更に、ユーザが一旦登録した現在位置データをユーザ自らが削除するように構成してもよいし、現在位置データを更新する際にその都度ユーザに更新の有無を選択させてもよい。
【００９５】
また、上述した例では、ユーザによって現在位置データをサーバ２００に通知もしくは更新されるようにしたが、これに限定するものではない。例えば、携帯電話と交信している基地局の位置情報（基地局位置情報）を利用して自動的に現在位置データを通知もしくは更新できるようにしたり、本サービスを利用すると自動的にＧＰＳ等により携帯電話の位置情報等を取得するようにしても構わない。
【００９６】
以上の実施形態では、ジャンルや地域を選択した場合を例にとって説明したが、性別、返信・評価別といったカテゴリを選択してもよいことは言うまでもない。
【００９７】
以上のように、複数の項目を選択することができるため、ユーザは自ら所望する送信相手を選択することができ、使い勝手がよい
なお、送信相手が複数人になる場合には、選択した送信相手が誰であるかを区別するために、例えば、選択された送信相手のニックネーム等を網掛け表示したり、色を変えたり、あるいは、選択された送信相手をチェックするためのチェックボックス等を利用すれば、更に使い勝手は向上する。
【００９８】
なお、上記においては、ジャンル名及び地域名を選択画面を介して選択できるように構成したが、入力部１０５によりジャンル名や地域名などの文字をデータを直接入力できるようにしても構わない。
【００９９】
更に、上記においては、本サービスを利用すると受信メールの数が膨大になる可能性が高い。例えば、一度に１００通ものメールを受信したりすると、通信回線のパンクを招いていしまったり、多大な通信コストもかかってしまうため、ユーザにとってはゆゆしき問題を生じる恐れがある。そのため、受信メールの数や受信メールのジャンルなどでメールを選別する場合について説明する。
【０１００】
例えば、本サービスに関するメールを一日に５通以上受信しないようにする場合について説明する。携帯電話１００は、受信したメールの数を計数（カウント）するメールカウンタを設けて、例えば、００：００から２４：００までを一日と規定しておき、その間にメールカウンタが予めユーザに設定されたメール受信限界数「５」の閾値を超えると、ＣＰＵ１０１は、それ以降の本サービスに関するメールは受信しない旨を示すメール受信拒否データをサーバ２００に送信する。メール受信拒否データを受信したサーバ２００は、それ以後のメールを当該ユーザの携帯電話に送信しないようにする。その際、サーバ２００は当該メールを消去してもよいし、一応記憶しておき次の日になって改めて送信するようにしてもよい。一日が経過すれば、ＣＰＵ１０１は、メールカウンタをゼロにリセットする。
【０１０１】
ジャンルで受信メールを選別する際も同様に行う。例えば、ジャンル「野球」以外のメールは受信しないといった場合について説明する。この場合、受信したメールのジャンルデータが「野球」であるか否かをサーバ２００が判定し、「野球」以外のメールは送信しないようにする。なお、例えば、ジャンルが「野球」のメールを「５」通以内といったようにメール受信数の閾値とメール内容のジャンルとを組み合わせてメール受信の数を限定するようにしても構わない。
【０１０２】
以上により、本サービスを利用したとしても受信メールの数が膨大になるといった問題を防ぐことができるため、ユーザにとって便利である。
【０１０３】
なお、上述してきた携帯電話やサーバ２００の機能をソフトウェアで実現してもよく、例えば、記録媒体やインターネットに接続されたサーバ２００から当該ソフトウェアを受信して当該機能を実現するようにしてもよい。これにより、携帯電話やサーバにおいて、必要な機能だけを搭載したり、また、好みに応じて色々な機能を追加もしくは削除、あるいは更新することが容易となる。
【０１０４】
また、ユーザのメールアドレスを秘匿するようにしたり、登録者をニックネーム等で表示するようにしたのはプライバシー保護の観点であるためであり、ユーザ本人が本名もしくは自分のメールアドレスを開示しても良いというのであれば、秘匿するようにしなくてもよい。
【０１０５】
また、上記実施形態では、サーバにデータベース記憶部を設けるように構成したが、携帯電話１００の記憶部内に設けて、携帯電話１００内でメール内容に応じてメール送信相手を特定するように処理しても構わない。この際、アドレス帳等の項目に「趣味」欄が設けられ、ＣＰＵ１０２は当該「趣味」欄に記載されているデータと記憶部１０４に記憶されたデータベースとに基づいて送信相手先を選択するように処理する。これにより、サーバの処理を低減できる。
【０１０６】
なお、上述してきた実施形態を組み合わせて構成することができることは言うまでもない。
【０１０７】
また、本発明は、上記に示された実施形態に限定されるものではなく、ここに開示された原理及び新しい特性は広範囲の技術的範囲を含むものである。例えば、上記で示した構成ブロック図、フローチャート、表示画面例等はあくまで実施形態を具体的に説明するために例示したものであり、開示された範囲に拘束されるものではない。
【図面の簡単な説明】
【０１０８】
【図１】第１の実施形態に係るサービスの全体システム図である。
【図２】第１の実施形態に係る携帯電話のブロック図である。
【図３】第１の実施形態にかかるサーバのブロック図である。
【図４】第１の実施形態における処理手順を示すシーケンス図である。
【図５】各データベースの例である。
【図６】送信者を特定するフローチャートである。
【図７】ジャンルディレクトリの１例である。
【図８】第１の実施形態における携帯電話の表示画面例である。
【図９】第２の実施形態における携帯電話のフローチャートである。
【図１０】送信相手を選択する際の携帯電話の表示画面例である。
【符号の説明】
【０１０９】
１００  携帯電話
１０１  ＣＰＵ
１０２  表示部
１０３  撮像部
１０４  記憶部
１０５  入力部
１０６  通信部
１０７  画像認識部
２０１  制御部
２０２  データベース記憶部
２０３  通信部
２０４  送信相手選択部
２０５  入力部
２０６  表示部
３００  サーバ
３０１  制御部
３０２  広告データ記憶部
３０３  通信部
３０４  入力部
３０５  表示部
【図１】
2005084948.tif 000003
【図２】
2005084948.tif 000004
【図３】
2005084948.tif 000005
【図４】
2005084948.tif 000006
【図５】
2005084948.tif 000007
【図６】
2005084948.tif 000008
【図７】
2005084948.tif 000009
【図８】
2005084948.tif 000010
【図９】
2005084948.tif 000011
【図１０】
2005084948.tif 000012