JP5373175B1 - 通信方法、通信装置、および、プログラム - Google Patents

Abstract

【課題】チャットサービスのメンバから非メンバに対して初めてメッセージを送る際には、非メンバのメールアドレス等を逐一登録する必要があり、チャットサービスの使用開始までの作業が煩わしかった。
【解決手段】ユーザ端末から、チャットサービスの開始の要求があると、メモリに格納された登録情報から最も適した通信方式を決定し、ユーザ端末から送信されたメッセージをその通信方式に変換して、相手先に送信する。送信相手先への通信の際に適用される通信方式は、送信相手先のユーザについてのメンバ情報を用いて、送信先のユーザがチャットシステムの登録メンバであるか否かを判別し、送信相手が登録メンバの場合は原則としてチャット方式が選択される。一方、送信相手が非登録メンバの場合は、チャット形式以外の通信方式を選択される。
【選択図】図１

Description

本発明は、情報処理端末を用いたメッセージの送受信を行う技術に関する。

従来、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）端末や携帯端末等の情報処理装置を用いてリアルタイムの文字通信を行う、いわゆるチャットというサービスが提供されている。
しかしながら、従来のチャットサービスにおいては、チャットサービスに加入、登録していない非メンバに対してチャットを行いたい場合であっても、そのメンバがチャットサービスに登録しない限り、チャットをすることができなかった。そのため、非メンバに対しては、別途メール等を送らなければならず、操作が煩雑になりがちであった。
この様な課題に対して、特許文献１では、第１のインターフェースから、ｅメールやチャットなどのモダリティを別のモダリティに変換し、コンピュータネットワークを介して第２のインターフェースに提供するマルチモーダル通信のための方法について開示している。

特表２０１１−５２５６７６号公報

しかしながら、従来の技術では、チャットサービスのメンバから非メンバに対して初めてメッセージを送る際には、非メンバのメールアドレス等を逐一登録する必要があり、チャットサービスの使用開始までの作業が煩わしく、障壁が高かった。また、ユーザがメッセージを送信する際に、ユーザ自身が通信方式を選択する必要があるなど、改善の余地があった。

本発明はかかる課題に鑑みてなされたものであり、その目的は、非ユーザとのチャットであったとしても、シームレスなメッセージのやり取りを可能にして、ユーザへの負担を軽減する通信方法、通信装置、および、プログラムを提供することにある。

本発明のある態様は、通信方法に関する。この通信方法は、情報処理端末を用いたメッセージの送受信を行うサービスに用いられる方法であって、送信先と、当該送信先に送信されるべきメッセージとを受け付けるステップ、受け付けた送信先のユーザについてのメンバ情報を用いて、送信先のユーザがチャットシステムの登録メンバであるか否かを判別するステップ、受け付けた送信先に関してメモリに登録されている１以上の通信方式から、適用すべき通信方式の優先順位が示された情報にしたがって、１つの通信方式を選択するステップ、選択された通信方式によって、送信先にメッセージを送信するステップ、を含む。適用すべき通信方式の優先順位が示された情報は、送信先のユーザが登録メンバであればチャット形式を選択し、非登録メンバであればチャット形式以外の通信方式を選択することが示されている。

このような態様によると、受け付けた送信先に関してメモリに登録されている１以上の通信方式から適用すべき通信方式の優先順位が示された情報にしたがって１つの通信方式を選択することによって、通信方式が自動設定されるため、非登録メンバに対してメッセージを送る際のユーザへの負担を軽減できる。

また、この通信方法は、情報処理端末に記憶されている１以上の連絡先情報を取得するステップ、取得した連絡先情報と、登録済の連絡先情報とを照合するステップ、照合の結果、２つの連絡先情報に共通する情報が含まれている場合、登録済の連絡先情報に、取得した連絡先情報を結合させるステップ、を含んでもよい。

このような態様によると、取得した連絡先情報と登録済の連絡先情報とを照合した結果、２つの連絡先情報に共通する情報が含まれている場合、登録済の連絡先情報に取得した連絡先情報を結合することによって、サービス使用開始時のユーザへの負担を軽減することができる。

また、この通信方法は、チャット以外の通信方式によるメッセージを受け付けた場合、該メッセージをチャット形式のメッセージに変換するステップ、変換したメッセージをチャットインタフェースに表示させるステップ、を含んでもよい。

このような態様によると、チャット形式のメッセージに変換してチャットインタフェースに表示させることによって、非登録メンバとの間でメッセージをやりとりした場合でも、メッセージを同じチャット画面上に表示することができるので、チャットをしている感覚でメッセージをやりとりできる。

また、この通信方法は、チャットインターフェースに表示された１以上のメッセージをユーザに選択させるステップ、選択されたメッセージにフラグを付して、前記ユーザが選択したメッセージとして管理するステップ、前記ユーザからの指示を契機として、フラグをもとに、前記ユーザが過去に選択した１以上のメッセージを抽出するステップ、抽出したメッセージを、Ｗｅｂページへエクスポートして、所定のユーザに閲覧させるステップ、を含んでもよい。

このような態様によると、フラグをもとに、ユーザが過去に選択した１以上のメッセージを抽出してＷｅｂページへエクスポート（Ｗｅｂページを更新）することによって、チャットでのメッセージのやりとりを広く共有することが容易となる。

また、この通信方法は、１以上の候補日時と、１以上の候補地とをそれぞれ１つずつ組み合わせたイベント情報を作成するステップ、作成されたイベント情報に関するイベントへの参加の可否を問い合わせるステップと、を含んでもよい。この場合、選択するステップは、イベントへの参加の可否を問い合わせる際に、チャット以外の通信方式を選択した場合、参加の可否に関する回答をユーザから受け付けるためのＵＲＬ情報を送信すべきメッセージに含める。

このような態様によると、参加の可否に関する回答をユーザから受け付けるためのＵＲＬ情報を送信すべきメッセージに含めることによって、非登録ユーザに対してであっても、簡易にイベント参加を問い合わせることができる。

本発明の別の態様は、プログラムである。このプログラムは、情報処理端末を用いたメッセージの送受信を行うサービスに用いられるプログラムであって、送信先と、当該送信先に送信されるべきメッセージとを受け付けるステップ、受け付けた送信先のユーザについてのメンバ情報を用いて、送信先のユーザがチャットシステムの登録メンバであるか否かを判別するステップ、受け付けた送信先に関してメモリに登録されている１以上の通信方式から、適用すべき通信方式の優先順位が示された情報にしたがって、１つの通信方式を選択するステップ、選択された通信方式によって、送信先にメッセージを送信するステップ、を含む処理をコンピュータに実行させる。適用すべき通信方式の優先順位が示された情報は、送信先のユーザが登録メンバであればチャット形式を選択し、非登録メンバであればチャット形式以外の通信方式を選択することが示されている。

本発明の別の態様は、通信装置である。この通信装置は、情報処理端末を用いたメッセージの送受信を行うサービスに用いられる通信装置であって、送信先と、当該送信先に送信されるべきメッセージとを受け付ける受付部と、受け付けた送信先のユーザについてのメンバ情報を用いて、送信先のユーザがチャットシステムの登録メンバであるか否かを判別し、受け付けた送信先に関してメモリに登録されている１以上の通信方式から、適用すべき通信方式の優先順位が示された情報にしたがって、１つの通信方式を選択する選択部と、選択された通信方式によって、送信先にメッセージを送信する送信部と、備える。前記適用すべき通信方式の優先順位が示された情報は、送信先のユーザが登録メンバであればチャット形式を選択し、非登録メンバであればチャット形式以外の通信方式を選択することが示されている。

なお、以上の構成要素の任意の組み合わせ、本発明の表現を法補、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によると、非ユーザとのチャットであったとしても、シームレスなメッセージのやり取りを可能にして、ユーザへの負担を軽減することができる。

本発明の実施例を説明する前に、まず、本発明の概要を述べる。本発明は、情報通信端末装置間においてメッセージを送受信するためのチャットサービスに関する。チャットサービスに登録しているメンバ（以下、「登録メンバ」という。）は、チャットサービスを用いてメッセージのやり取りをするに際し、相手方がチャットサービスに登録しているか否かを意識することなく、その相手方との間でチャットを実施することができる。

チャットサービスに登録していないメンバ（以下、「非登録メンバ」という。）との間でチャットをする場合、従来は、その非登録メンバに対して、登録メンバになるよう促すか、あるいは、チャット以外の方法によって通信を行っていた。モダリティ変換技術を用いることで、非登録メンバと登録メンバとの間でチャットをするサービスも存在するが、使用の際に非登録メンバの情報を逐一入力する手間が必要であったり、サービス使用に制限が課されていたりするなど、非常に使い勝手が悪いものであった。

本発明においては、以上の使い勝手の悪さを解消しており、チャットの相手方のサービス登録状況をユーザに意識させることなく、極めてスムーズにチャットサービスを実施することができることとなる。また、本発明は、３名以上のユーザ（非登録メンバを含んでも良い）がチャットを行う場合にも適用可能である。以下、例を用いて説明する。

まず、実施例１について説明する。図１は、本発明の実施例１にかかるチャットシステム１００を示す図である。チャットシステム１００は、サーバ１０と、サーバ１０と基地局４０とを有線回線で接続するネットワーク３０と、基地局４０で代表される第１基地局４０ａ〜第３基地局４０ｃと、モバイル端末５０で代表される第１モバイル端末５０ａ〜第３モバイル端末５０ｃと、ＰＣ端末７０とを含む。

なお、図示の都合上、基地局４０、モバイル端末５０は共に３台のみ図示したが、これにかぎらず、それ以上の基地局４０、モバイル端末５０が存在してもよい。ＰＣ端末７０についても同様である。また、第１モバイル端末５０ａ〜第３モバイル端末５０ｃは、それぞれ異なる基地局５０と接続されるとして図示しているが、これにかぎらず、１つの基地局５０に複数のモバイル端末５０が接続されていても、本発明が適用可能であることは言うまでもない。

サーバ１０は、チャットサービスを実施、提供するための装置である。サーバ１０は、ネットワーク３０と基地局４０とを介して、モバイル端末５０やＰＣ端末７０との間で、チャット処理のための通信処理を実行する。なお、以下においては、説明を簡易にするため、単に、「サーバ１０とモバイル端末４０ないしＰＣ端末７０との間で通信処理を実行する」などと表現し、ネットワーク３０および基地局４０を介する点については記載を省略する。また、以下においては、モバイル端末５０やＰＣ端末７０を総称して、ユーザ端末と表現することもある。

サーバ１０は、ユーザ端末からの要求にしたがって、アプリをダウンロードさせる。その後、ユーザ端末内のメモリに記憶されている連絡先情報をアップロードさせて、サーバ１０内のメモリにインポートする。サーバ１０は、ユーザ端末からチャットサービスの開始の要求があると、チャットサービスの相手先への通信方式を決定する。具体的には、通信方式の優先度情報に従って、サーバ１０内のメモリに格納された登録情報から最も適した通信方式を決定し、ユーザ端末から送信されたメッセージをその通信方式に変換して、相手先に送信する。

送信相手先への通信の際に適用される通信方式は、送信相手が登録メンバの場合は原則としてチャット方式が選択される。一方、送信相手が非登録メンバの場合は、非登録メンバに関してメモリに登録された情報に応じた方式が選択される。詳細は後述する。このような態様をとることで、ユーザは、相手先が非登録メンバであっても、それを意識することなく、チャットをすることができる。

ユーザ端末は、チャットサービスを使用する場合は、まず、サーバ１０にアクセスして、アプリをダウンロードし、インストールする。ついで、サーバ１０からの要求にしたがって、端末内に登録されている連絡先情報をアップロードする。以後、チャットサービスを利用する場合は、アプリを立ち上げ、送信先を指定するとともに、送信先へのメッセージを作成して、送信すればよい。なお、前述しているように、ユーザ端末の使用者は、チャットシステム１００の利用に際して、送信先のユーザが非登録ユーザであるか否かは問われない。

図２は、図１のチャットシステム１００におけるサーバ１０の構成例を示す図である。サーバ１０は、サーバ受信部１２と、チャット制御部１４と、サーバ送信部１６と、サーバメモリ２０とを含む。

サーバ受信部１２は、ユーザ端末からの信号を受信し、所定の復調処理を実施して、チャット制御部１４に復調された信号を送る。サーバ送信部１６は、チャット制御部１４にて選択された通信方式にて、所定のメッセージを送信相手へ送信する。サーバ受信部１２、および、サーバ送信部１６における変復調処理は、従来用いられている変復調技術が用いられてよく、このような態様であったとしても、本発明を適用することができることは当業者に理解されるところである。

チャット制御部１４は、サーバ受信部１２からの信号を受けて、内容に応じた処理を実施して、サーバメモリ２０にアクセスし、また、サーバ送信部１６に対して送信を指示する。サーバ受信部１２から受ける信号はユーザ端末からの信号であり、たとえば、チャットサービスを利用するためのアプリ（以下、チャットアプリという。）のダウンロード要求、ユーザ端末からアップロードされた情報、送信先、ならびに、送信先へのメッセージなどである。

チャット制御部１４は、サーバメモリ２０に対して、ユーザにダウンロードさせるためのチャットアプリを読み出したり、ユーザ端末から送信された連絡先情報をインポートしたり、通信方式を決定するための情報にアクセスを行う。チャット制御部１４は、ユーザからの要求にしたがって、ユーザ端末にアプリをダウンロードさせる。ユーザ端末にダウンロードさせた後において、チャット制御部１４は、ユーザ端末に対して、そのユーザ端末に記憶された連絡先情報を当該サーバ１０にインポートさせるか否かの問合せを行う。インポートの許可があった場合、ユーザ端末から連絡先情報が送られてくるので、チャット制御部１４は、サーバメモリ２０に当該情報を書き込む。

また、チャット制御部１４は、送信先への通信方式を決定する場合に、送信先に関してサーバメモリ２０に登録されている１以上の通信方式から、適用すべき通信方式の優先順位が示された情報にしたがって、１つの通信方式を選択する。「適用すべき通信方式の優先順位が示された情報」や選択の詳細については後述することとする。

図３は、図２のサーバ１０におけるチャット制御部１４の構成例を示す図である。チャット制御部１４は、登録制御部２２と、選択部２４と、変換部２６とを含む。登録制御部２２は、ユーザ端末から取得した連絡先情報をサーバメモリ２０に登録する処理を行う。選択部２４は、ユーザ端末からのチャット要求を契機として、サーバメモリ２０にアクセスして送信先の情報を取得し、送信先への通信方式を決定し、変換部２６に伝える。変換部２６は、変換部２６より伝えられた通信方式のフォーマットに、ユーザ端末から受け付けた送信先へのメッセージを変換する。変換部２６による変換は、公知の方法で行われてもよい。以下、順に説明する。

登録制御部２２は、ユーザ端末にチャットアプリがインストールされ、ユーザ端末内の連絡先情報がアップロードされたのを契機として、その連絡先情報をサーバメモリ２０に登録する。その際、登録制御部２２は、まず、アップロードの主体となったユーザ端末にＩＤを付与する。

さらに、登録制御部２２は、アップロードされた連絡先情報と、登録メンバの連絡先情報とを照合する。登録メンバの連絡先情報とは、すでにチャットサービスに登録しているメンバの連絡先情報である。また、登録制御部２２は、アップロードされた連絡先情報と、登録済の連絡先情報とを照合してもよい。登録済の連絡先情報とは、サーバメモリ２０に記憶されている、他の登録ユーザによってすでにインポートされていた非登録メンバの連絡先情報を含む連絡先情報である。

連絡先情報とは、氏名、フリガナ、電話番号、携帯電話番号、Ｅメールアドレス、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）情報、メンバ情報などを含む。電話番号、携帯電話番号、Ｅメールアドレス、あるいは、ＳＮＳ情報は、複数であってもよい。ＳＮＳ情報は、ｆａｃｅｂｏｏｋ、ｔｗｉｔｔｅｒ、ｍｉｘｉ、Ｌｉｎｋｅｄｉｎ（以上４つはすべて登録商標）などのＳＮＳにおいてユーザを識別し、また、そのユーザに対して連絡をするために必要な１以上の情報を含む。メンバ情報は、チャットシステムを利用するためのアプリをインストールしているか否かを示す情報であり、登録メンバであるか非登録メンバであるかを判断するためのフラグとなる。

照合の結果、２つの連絡先情報に共通部分があった場合、登録制御部２２は、２つの連絡先情報を統合して記憶する。たとえば、以下に示すような２つの連絡先情報であったとすると、両連絡先情報において、氏名と携帯電話番号が同一である。そのため、双方の連絡先情報は同一人物にかかるものであると推定できる。

アップロードされた連絡先情報
氏名 Ａ
携帯電話番号 090-XXX-YYYY
Ｅメールアドレス b@ppp.co.jp
登録済の連絡先情報
氏名 Ａ
携帯電話番号 090-XXX-YYYY
電話番号 03-mmmm-nnnn
Ｅメールアドレス a@qqq.ne.jp

よって、登録制御部２２は、上記２つの連絡先情報を統合して、以下のような１つの連絡先情報として、サーバメモリ２０に記憶する。

統合後の連絡先情報
氏名 Ａ
携帯電話番号 090-XXX-YYYY
電話番号 03-mmmm-nnnn
Ｅメールアドレス a@qqq.ne.jp
Ｅメールアドレス b@ppp.co.jp

なお、２つの連絡先情報が完全一致する場合、登録制御部２２は、統合処理をしなくてもよい。お互いに補間すべき情報がないからである。また、統合の際に、共通部分の個数をもって、統合するか否かの条件してもよいし、１以上の所定の情報が一致していることを条件としてもよいし、これらの組み合わせでもよい。この個数を増やすほど、同一人物にかかるものである確率が高まるからである。また、1以上の所定の情報を、たとえば氏名と携帯電話番号のようにすることで、不変あるいは変更されにくい連絡先情報を判断基準にできるので、同一人物にかかるものである確率をより高めることができる。なお、処理スピード、処理負荷の観点と、確率を高めることはトレードオフの関係にあるが、これらを鑑みると、上記個数は、２ないし３が好適であるといえ、また、所定の情報は、氏名と携帯電話番号および／または電話番号の組み合わせが好適であるといえる。

つぎに、選択部２４について説明する。選択部２４は、受け付けた送信先のユーザに関してサーバメモリ２０に登録されている１以上の通信方式から、適用すべき通信方式の優先順位が示された情報にしたがって、１つの通信方式を選択する。ただし、サーバ受信部１２から受け付けたメッセージがチャット形式である場合と、そうでない場合とで、選択部２４は動作が異なる。チャット形式の場合は、登録ユーザからのメッセージであり、チャット形式以外の形式の場合は、非登録ユーザからのメッセージとなるからである。

ここでは、まず、サーバ受信部１２から受け付けたメッセージがチャット形式である場合について、例を用いて説明する。この例においては、以下のユーザＡ、ユーザＢ、ユーザＣの連絡先情報がサーバメモリ２０に記憶されていることを前提とする。

ユーザＡ
氏名
Ｅメールアドレス
登録メンバ
ユーザＢ
氏名
Ｅメールアドレス
ＳＮＳ情報
非登録メンバ
ユーザＣ
氏名
Ｅメールアドレス１
Ｅメールアドレス２
非登録メンバ

また、適用すべき通信方式の優先順位が示された情報（以下、優先度情報という。）が以下のように設定されていたと仮定する。なお、この優先度情報とは、たとえば、以下のような情報となる。優先度１は、もっとも優先度が高いことを示し、番号が大きくなるほど優先度が低くなることを示している。

優先度１ チャット形式
優先度２ Ｅメール形式
優先度３ ＳＮＳ形式

なお、この優先度情報は、登録ユーザごとに設定されていてもよい。また、登録ユーザが任意に設定してもよい。また、常に、チャット形式が優先度１になるように設定されてもよいし、この場合に、優先度２以降の形式をユーザが任意に設定できるようになっていてもよい。

以上のような場合において、ユーザＡが送信先である場合について説明する。まず、選択部２４は、送信先について記憶されている連絡先情報のうち、メンバ情報を取得する。ここで、メンバ情報により、送信先のユーザが登録メンバであることが判明し、この場合、チャット形式が選ばれる。

ここで、選択部２４は、変換部２６に対して、受け付けたメッセージをチャット形式に変換する旨を指示する。なお、登録メンバである場合、選択部２４は、優先度情報にアクセスすることなく、チャット形式を選択してもよい。

次に、ユーザＢが送信先である場合について説明する。上述のユーザＡの場合と異なり、ユーザＢは非登録メンバとなる。このような場合、選択部２４は、優先度情報のうち、優先度２を参照する。ここで、優先度２はＥメール形式となっているので、選択部２４は、Ｅメールアドレスが、ユーザＢの連絡先情報として存在するか否かを照合する。

上記の例においては、ユーザＢのＥメールアドレスが存在するため、選択部２４は、通信方式としてＥメール形式を選択することとなる。なお、ユーザＢのＥメールアドレスが登録されていなかった場合、次の優先度３のＳＮＳ形式について登録されているかが判断され、この場合においてはユーザＢの登録情報としてＳＮＳ情報が登録されているため、選択部２４は、ＳＮＳ形式を選択することとなる。

次に、ユーザＣが送信先である場合について説明する。ユーザＣの登録情報によると、ユーザＣは非登録メンバであるため、選択部２４は、優先度２のＥメール形式が選択できるかどうかを判断するために、ユーザＣの登録情報にＥメールアドレスが存在するか否かを確認する。ここで、ユーザＣの登録情報として、Ｅメールアドレスが２つ存在している。このような場合、選択部２４は、携帯電話宛のＥメールアドレスを優先して選択する。

なお、２つ以上の携帯電話宛のＥメールアドレスが登録されている場合、より遅い時期に登録されているＥメールアドレスを選択してもよい。より遅い時期に登録されたＥメールアドレスのほうが、より最近に登録された最新の情報である可能性があり、より確実にユーザＣにメッセージを到達させることができるからである。

また、優先度情報としてＥメール形式が優先度２に設定されているが、これを以下の優先度情報の例２のように、宛先に応じて優先度を設定してもよい。

＜優先度情報の例２＞
優先度１ チャット形式
優先度２ 携帯電話以外を宛先とするＥメールアドレス
優先度３ 携帯電話宛のＥメールアドレス

また、以下の優先度情報の例３のように、gmail.comやフリーアドレスのように、携帯電話であるか他の宛先であるかを問わない汎用のＥメールアドレスを設定できるようにしてもよい。このように優先度情報を設定することで、より柔軟に送信先を選択することができ、より確実に送信先にメッセージを到達させることができる。

＜優先度情報の例３＞
優先度１ チャット形式
優先度２ 汎用のＥメールアドレス
優先度３ 携帯電話宛のＥメールアドレス
優先度４ 携帯電話以外を宛先とするＥメールアドレス

変換部２６は、送信先が非登録ユーザである場合、サーバ受信部１２から受け付けたメッセージに、ＵＲＬ情報を付加する。ＵＲＬ情報とは、非登録ユーザにチャットシステムへの招待を促すＷｅｂページへのリンクに関する情報である。非登録ユーザは、この情報をクリックすることで、サーバ１０にアクセスでき、そこから、チャットを実施するためのチャットアプリをダウンロードできることとなる。つぎに、変換部２６は、選択部２４から指示された通信方式の形式に、送信すべきメッセージを変換してサーバ送信部１６に送る。

つぎに、サーバ受信部１２から受け付けたメッセージがチャット形式以外の形式の場合について説明する。この場合におけるメッセージは、非登録ユーザから登録ユーザへのメッセージとなる。そのため、サーバメモリ２０においては、宛先であるユーザの登録情報は、登録ユーザとなる。ここで、チャット形式は、登録メンバにかかる優先度情報の優先度１となっている。よって、前述したように、選択部２４は、登録ユーザ宛のメッセージの通信方式としてチャット形式を選択することとなる。

ついで、変換部２６は、非登録メンバから受け付けたメッセージをチャット形式に変換する。変換されたメッセージは、サーバ送信部１６を介して、宛先であるユーザ端末５０に送信される。ユーザ端末５０においては、端末のディスプレイ上のチャットインタフェース画面に、送信されたメッセージが表示される。以上のような態様により、チャットシステム１００においては、サーバ１０において記録されている連絡先情報と優先度情報から通信方式を適切に変換することで、登録メンバ、非登録メンバ間においても、ユーザに余計な操作をさせることなく、スムーズなチャットが実現できる。

つぎに、ユーザ端末側の構成について説明する。図４は、図１のモバイル端末５０あるいはＰＣ端末７０における構成例を示す図である。ここでは、説明の都合上、モバイル端末５０の構成として説明するが、ＰＣ端末７０においても同様の構成となる。

モバイル端末５０は、端末受信部５２と、端末制御部５４と、端末送信部５６と、ユーザインタフェース５８と、端末メモリ６０とを備える。端末受信部５２は、サーバ１０からダウンロードしたチャットアプリや、サーバ１０から送信された他のユーザからのメッセージなどを受信する。

端末制御部５４は、ユーザからの指示を受け付けて、端末メモリ６０にアクセスしながら、チャットアプリのインストール制御や、端末メモリ６０に登録された連絡先情報のアップロード制御、あるいは、チャットのための送信先の選択、送信先へのメッセージ管理などを行う。

また、ユーザインタフェース５８は、ユーザへのメッセージを画面に表示し、また、キーボードやタッチパネルなどを操作した結果として入力されたユーザからの指示を受け付けて、端末制御部５４に伝える。ユーザへのメッセージとは、たとえば、メモリ６０に記憶された連絡先情報をサーバ１０内にインポートしてもよいか否かの問合せや、チャットを行う際の送信先の指定や、送信先へのメッセージ編集画面などである。これらのメッセージは、所定のチャットインタフェース画面に表示されてもよい。

以下、ユーザＡがチャットサービスの使用を開始する場面の一例として、モバイル端末５０の総括的な動作を説明する。

ユーザＡが、ユーザＡのモバイル端末５０に、チャットアプリをインストールしたとする。その際に、端末制御部５４は、「アドレス帳をインポートしますか？」などのようなポップアップメッセージをユーザインタフェース５８に表示させ、これに対してユーザがＹｅｓボタンを押すと、端末メモリ６０に記憶されている連絡先情報が、サーバ１０のサーバメモリ２０にインポートされる。

なお、チャットアプリをインストールする際に、ポップアップ表示等を出さずに、自動的にユーザＡの端末メモリ６０に記憶されている連絡先情報がサーバ１０にインポートされてもよい。また、定期的に、インポート処理が実施されてもよいし、新たな連絡先情報が端末メモリ６０に追加された場合にインポート処理が実施されてもよい。

次に、サーバ１０において、連絡先情報に含まれた電話番号やＥメールアドレス等と、サーバ１０に記憶されている登録メンバの連絡先情報とが照合され、一致する登録メンバが存在する場合、登録メンバの連絡先情報とインポートされたアドレス情報とが結合される。

この様に、チャットアプリをインストールすれば、モバイル端末５０の端末メモリ６０に登録されているユーザの知り合い等に関する連絡先情報が、チャット相手として自動的に登録される。そのため、ユーザはストレスを感じることなく、チャットサービスの使用を開始することができる。

つぎに、ユーザＡが、ユーザＢとチャットを介してメッセージのやりとりをする場面の一例を説明する。

ユーザＡは、チャットアプリを起動させると、ユーザインタフェース５８は、送信先の候補を表示する。ユーザＡは、表示された候補から、メッセージの送信相手として、たとえば、ユーザＢを選択する。選択された送信先は、端末制御部５４、端末送信部５６を介して、サーバ１０に通知される。

つぎに、サーバ１０は、ユーザＢの連絡先情報及び優先度情報に基づいて、メッセージの通信方式（チャット、メール、ＳＮＳ）を決定する。優先度情報とは、前述したように、どの通信方式を利用してメッセージを送信するかの優先順位を示す情報である。例えば、優先度情報がチャット＞ＳＮＳメッセージ＞Ｅメールアドレス＞ＳＭＳの順になっており、ユーザＢがチャットサービスの登録メンバである場合は、通信方式はチャットとなる。また、ユーザＢが非登録メンバであってＥメールアドレスと電話番号のみがわかっている場合は、より優先順位が高い、Ｅメール形式による通信形式が選択される。

ユーザＡがユーザインタフェース５８により画面に表示されたチャットインターフェース画面のメッセージ欄に、ユーザＢへのメッセージを記入し、送信ボタンを押すと、その旨が端末制御部５４、端末送信部５６、さらには、サーバ１０を介して、ユーザＢに対してメッセージが送信される。ユーザＢへの通信方式としてＥメール方式が選択されている場合、サーバ１０がユーザＡのチャットメッセージをＥメール形式に変換し、端末メモリ６０よりインポートされたユーザＢのメールアドレスを宛先としてメールがサーバ１０より送信される。

非登録ユーザであるユーザＢがユーザＡからのＥメール形式のメッセージを受信し、そのメッセージに対してＥメール形式にて返信すると、サーバ１０は、まず、ユーザＢからのＥメールをチャット形式のメッセージに変換して、ユーザＡのモバイル端末５０に送信し、その端末のディスプレイ上のチャットインターフェースに表示させる。

図５は、図３のチャット制御部１４の第１の処理手順を示すフローチャートである。この第１の処理手順は、ユーザ端末にアプリをダウンロードさせたことを契機として開始される。

まず、チャット制御部１４は、サーバ送信部１６を介して、ユーザ端末にインポート要求を行う（Ｓ１０）。インポート要求とは、ユーザ端末内のメモリに記憶されている連絡先情報をサーバ１０にアップロードさせて、サーバ１０内のサーバメモリ２０に記憶させてもよいか否かを問い合わせるためのものである。

ここで、ユーザ端末からインポートを許可しない旨の信号をサーバ受信部１２にて受け付けた場合（Ｓ１２のＮｏ）、チャット制御部１４は、この処理を終了する。一方、ユーザ端末からインポートを許可する旨の信号を受け付けた場合（Ｓ１２のＹｅｓ）、ついで送信されてくる連絡先情報をサーバ受信部１２を介して、取得する。

取得した連絡先情報と、サーバメモリ２０にすでに登録されている連絡先情報とを照合した結果、共通する情報が存在した場合（Ｓ１４のＹｅｓ）、登録制御部２２は、サーバメモリ２０内に記憶されていた連絡先情報と、取得した連絡先情報とを統合する（Ｓ１６）。一方、共通した情報が存在しなかった場合（Ｓ１４のＮｏ）、登録制御部２２は、取得した連絡先情報をそのままサーバメモリ２０に登録する（Ｓ１８）。その際、連絡先情報を特定するためのＩＤなどを付してもよい。

ここで、インポートすべきすべての連絡先情報がインポートされた場合（Ｓ２０のＹｅｓ）、チャット制御部１４は、この処理を終了する。一方、他の連絡先情報がある場合（Ｓ２０のＮｏ）、チャット制御部１４は、Ｓ１４の処理に戻り、インポートすべき連絡先情報がなくなるまで、Ｓ１４〜Ｓ２０の処理を繰り返す。

図６は、図３のチャット制御部１４の第２の処理手順を示すフローチャートである。この第２の処理手順は、ユーザ端末がチャットを開始したことを契機として開始される。

チャット制御部１４は、サーバ受信部１２を介して、ユーザが指定した送信先と、当該送信先に送信されるべきメッセージとを取得する（Ｓ３０）。ついで、チャット制御部１４は、送信先に関してサーバメモリ２０に登録されている連絡先情報のうちの１以上の通信方式から、適用すべき通信方式の優先順位が示された優先度情報にしたがって、１つの通信方式を選択する（Ｓ３２）。

ここで、送信先が未登録ユーザの場合（Ｓ３４のＹｅｓ）、チャット制御部１４は、送信すべきメッセージに、未登録ユーザにチャットシステムへの参加を促すためのＵＲＬ情報を付加する（Ｓ３６）。登録ユーザの場合（Ｓ３４のＮｏ）、Ｓ３８の処理に移る。

チャット制御部１４は、送信すべきメッセージに対して、Ｓ３２において選択された通信方式に変換する処理を実施する（Ｓ３８）。ついで、チャット制御部１４は、サーバ送信部１６に対して、変換したメッセージをユーザから指定された送信先に送信させる（Ｓ４０）。

以上のような態様によると、受け付けた送信先に関してメモリに登録されている１以上の通信方式から適用すべき通信方式の優先順位が示された情報にしたがって１つの通信方式を選択することによって、通信方式が自動設定されるため、メッセージを送る際のユーザへの負担を軽減できる。

また、取得した連絡先情報と登録済の連絡先情報とを照合した結果、２つの連絡先情報に共通する情報が含まれている場合、登録済の連絡先情報に取得した連絡先情報を結合することによって、サービス使用開始時のユーザへの負担を軽減することができる。

つぎに、実施例２について説明する。まず概要を述べる。実施例２では、実施例１の態様に加え、チャットインターフェースに表示されるメッセージの中で、ユーザーが任意に選択したメッセージをサーバ１０に保存することができる。その際、サーバ１０は、複数のユーザによる選択を受付けすることが可能である。選択されたメッセージには、例えば、ピンのマーク等のフラグが付けられて、後に図示するようなピンボードとして画面に表示されてもよい。チャット参加者は、このピンボードによって、選択されたメッセージを確認することができる。

さらに、実施例２では、ピンボードをＷｅｂページに変換し、Ｗｅｂ上へアップすることができる。これによって、選択されたメッセージを広く共有することが可能となる。また、Ｗｅｂページにアクセスできる人を制限したい場合は、Ｗｅｂページにパスワードを付与してもよい。以上のような態様をとることで、実施例２は、特に、ビジネスにおけるチャット会議や、イベントのスケジューリング等に便利である。以下、図面を用いて詳細に説明する。なお、実施例１と同様の構成をとる場合、同じ番号を付して、説明を省略する。

図７は、本発明の実施例２にかかるチャット制御部７２の構成例を示す図である。チャット制御部７２は、メッセージ管理部６２と、Ｗｅｂ更新部６４とを備える。なお、図３のチャット制御部１４に含まれた登録制御部２２、選択部２４、変換部２６は図示を省略している。

まず、ユーザは、ユーザ端末５０のディスプレイ上のチャットインターフェースに表示された１以上のメッセージを選択し、選択されたメッセージには、選択された旨のフラグが表示されるとともに、サーバ１０に対して、選択したメッセージを特定するための情報を送信する。選択したメッセージを特定するための情報（以下、選択メッセージ特定情報という。）とは、メッセージを特定するための識別番号でもよいし、その識別番号と対応付けたフラグでもよい。

サーバ１０のメッセージ管理部６２は、サーバ受信部１２を介して、選択メッセージ特定情報を取得して、そのメッセージを前記ユーザが選択したものとして管理するために、サーバメモリ２０に選択メッセージ特定情報とユーザＩＤとを紐づけて記憶させる。メッセージ管理部６２は、メッセージ自体もサーバメモリ２０に記憶させてもよい。

ここで、ユーザにより過去に選択されたメッセージをまとめて表示させるための要求をユーザがチャットインタフェースを介して行った場合、ユーザ端末５０は、サーバ１０に対して表示を指示するための要求を行う。サーバ１０のメッセージ管理部６２は、表示要求にかかるユーザからの指示を受けたことを契機として、サーバメモリ２０にアクセスして、選択メッセージ特定情報を取得し、該当するメッセージをＷｅｂ更新部６４に通知する。Ｗｅｂ更新部６４は、選択メッセージ特定情報により特定されたメッセージをＷｅｂページに表示するための処理を実施する。

なお、Ｗｅｂ更新部６４は、選択されたメッセージをユーザに閲覧させる際に、ユーザに対してパスワードを要求してもよい。これにより、セキュリティ性を高めることができる。これにより、選択を行ったユーザ以外のユーザであっても、パスワードを知っていれば、選択されたメッセージを閲覧できるため、複数のユーザによりメッセージを共有することができる。

また、メッセージ管理部６２は、メッセージ特定情報によって特定されるメッセージの他、そのメッセージに関連づけられたメッセージ特定情報もあわせて管理してもよい。この場合、メッセージ管理部６２は、ユーザ端末５０から取得した選択メッセージ特定情報と、その選択メッセージ特定情報にかかるメッセージに続くメッセージのうち、何個のメッセージを管理すべきかを示す情報をサーバメモリ２０に記憶する。この情報は、ユーザ端末５０によって通知される。このような態様をとることによって、特定の話題をまとめて１つのスレッドとして管理し、表示させることができる。

図８は、本発明の実施例２にかかるユーザ端末とサーバ１０によるメッセージ管理に関する処理手順例を示すシーケンス図である。

まず、ユーザ端末は、ユーザからの指示により、メッセージを選択する（Ｓ５０、Ｓ５６）。ついで、ユーザ端末は、選択されたメッセージにかかる選択メッセージ特定情報をサーバ１０に通知する（Ｓ５２、Ｓ５８）。サーバ１０は、ユーザ端末から通知された選択メッセージ特定情報にしたがって、サーバメモリ２０において選択されたメッセージを管理する（Ｓ５４、Ｓ６０）。なお、図８においては、２つのメッセージを選択する例を示しているが、これに限らず、１回のみであってもよいし、３回以上選択されてもよい。

ここで、ユーザにより、ユーザ端末が表示要求を受け付けた場合（Ｓ６２）、ユーザ端末は、過去に選択したメッセージを表示させるための指示をサーバ１０に通知する（Ｓ６４）。サーバ１０は、ユーザ端末からの指示を契機として、サーバメモリ２０にて管理しているメッセージをＷｅｂページに表示させるためのＷｅｂ更新処理をする（Ｓ６６）。さいごに、ユーザ端末は、サーバ１０にアクセスして、メッセージを閲覧するためのＷｅｂページをディスプレイ上に表示させる（Ｓ６８）。

つぎに、実施例３について説明する。まず概要を述べる。実施例３においては、チャットインタフェース上で、イベント等のスケジューリング管理を行うことができる。ユーザは、チャットシステム内においてイベントを作成し、チャット相手に対して、イベントの参加の有無をチャット上で回答させる。また、チャット相手から得られた回答は自動集計され、ユーザは、集計結果を一覧することが可能である。

また、単にイベント参加の可否だけでなく、イベント開催の日時や場所の候補をいくつか挙げ、候補ごとにチャット相手に回答させてもよい。チャットサービスの非登録メンバに対しては、メール本文中にイベントの参加可否や希望日を選択するためのＷｅｂページのＵＲＬを記載しておく。または、メール本文中に、参加と不参加とで別々のＵＲＬを貼っておき、参加のＵＲＬを押せば参加と返事、不参加のＵＲＬを押せば不参加と返事することができる様にしてもよい。

このイベント等のスケジューリング管理は、以下の機能を有してもよい。
（１）イベントを主催するユーザーは、友達や家族とのイベント予定を調整できる。参加の有無、希望日時、希望場所を回答させ、主催者が集計結果を一覧できる。
（２）イベントを開催する日時の投票、および、集計ができる。日時の候補は、複数であってもよい。場所についても同様である。イベントを開催する会場ごとの選択肢であってもよい。
（３）回答者は各日程ごとに「○」「△」「×」などの複数の選択肢から回答できる。
（４）日時を指定せず、「いま暇な人募集」のようなイベントも開催できる。
（５）所定の日までに回答してないユーザーに対してリマインドメッセージを送ることができる。また、参加予定者に対して、たとえば、開催の24時間前などに参加者に対してメッセージを送ることができる。
（６）チャットインタフェースにて実施できるほか、Ｗｅｂブラウザ上でも同様に実施でき、双方は同期される。そのため、アプリの非登録ユーザーであっても、簡易にこの機能を使用することができる。

以上の機能を実現するために、チャットシステムを管理するサーバは、ユーザの指示にしたがって、１以上の候補日時と、１以上の候補地とをそれぞれ１つずつ組み合わせたイベント情報を作成し、作成されたイベント情報に関するイベントへの参加の可否を問い合わせる。イベントへの参加の可否を非登録ユーザなどに対して問い合わせる際において、チャット以外の通信方式を選択した場合、参加の可否に関する回答をユーザから受け付けるためのＵＲＬ情報を送信すべきメッセージに含めてもよい。

以下、図面を用いて詳細に説明する。なお、実施例１、２と同様の構成をとる場合、同じ番号を付して、説明を省略する。

図９は、本発明の実施例３にかかるチャット制御部７４の構成例を示す図である。チャット制御部７４は、イベント管理部８０を含む。なお、図３のチャット制御部１４に含まれた登録制御部２２、選択部２４、変換部２６は図示を省略している。

イベント管理部８０は、サーバ受信部１２を介して受け付けられたユーザからのイベントに関する指示にしたがって、サーバメモリ２０にアクセスし、イベントに関する情報を管理する。イベントに関する指示には、ユーザからのイベントに関する情報の入力や、イベント参加を促したいユーザに関する情報などが含まれる。

また、イベント管理部８０は、ユーザからのイベントに関する指示にしたがって、所定の画面をユーザ端末のディスプレイのチャットインタフェース画面に表示する。以下、例を用いて、説明する。

図１０は、本発明の実施例３にかかるチャットインタフェース画面の遷移例を示す図である。チャットインタフェース画面は、グローバルメニュー画面Ｇ０と、イベントホーム画面Ｇ１と、メンバー選択画面Ｇ２と、イベント作成画面Ｇ３と、チャット画面Ｇ４と、イベント詳細画面Ｇ５と、イベント回答確認画面Ｇ６とを含む。

Ｇ０からＧ６までのチャットインタフェース画面は、ユーザから受け付けた指示にしたがって、サーバ１０内のサーバメモリ２０において管理されているイベント情報が更新され、更新の態様に応じて、図１０に示すごとく、それぞれの画面に遷移していく。

ユーザがチャットを開始すると、まず、チャットシステム１００の初期画面となるグローバルメニュー画面Ｇ０がユーザ端末に表示される。ここでユーザがイベントに関する処理を要求した場合、イベントホーム画面Ｇ１に遷移する。このイベントホーム画面Ｇ１を起点として、ユーザはイベントを作成し、また、管理することとなる。

図１１は、図１０のイベント画面Ｇ１の表示例を示す図である。イベント画面Ｇ１は、グローバルメニュー画面Ｇ０から遷移されて、イベントを一元管理する画面であり、ユーザは、この画面により、進行中ならびに過去に参加したイベントを確認することができる。図示するように、イベント画面Ｇ１には、新規イベント作成ボタンＧ１０と、イベント欄Ｇ１２が表示される。イベント欄Ｇ１２には、イベント画像Ｇ１４やイベント参加者画像Ｇ１６などが表示される。

ユーザは、新規にイベントを作成する際に、新規イベント作成ボタンＧ１０をタップすることで、イベントを作成できる。イベントを作成する際は、メンバー選択画面Ｇ２に遷移し、イベント参加を問い合わせるメンバをユーザに選択させる画面が表示される。

イベント欄Ｇ１２には、イベントのタイトル、日時、場所、参加者一覧などが表示される。ユーザにより、個別のイベントの欄がタップされると、イベント詳細画面Ｇ５に遷移する。新規に作成されたイベントは、イベント欄Ｇ１２の最上部に表示され、過去のイベントほど、下部に表示される。イベントが終了した場合や、イベント自体が削除された場合、イベント欄Ｇ１２から削除される。なお、下部に表示されるイベントは、色調が薄く表示されたりするなど、新規のイベントと比較して、異なる表示処理が施されてもよい。

イベント画像Ｇ１４には、イベント作成において指定されたイベントを示す画像が表示される。指定されない場合は、任意の画像が表示されてもよい。イベント参加者画像Ｇ１６には、そのイベントに対してすでに参加の旨を回答したユーザによって指定された画像が表示される。

図１２は、図１０のイベント作成画面Ｇ３の表示例を示す図である。イベント作成画面Ｇ３は、参加問合メンバ画像Ｇ３０と、メンバー編集ボタンＧ３１と、イベント説明欄Ｇ３２と、候補追加ボタン３３と、回答候補ボタンＧ３４と、日程候補欄Ｇ３５と、時間候補欄Ｇ３６と、自由入力ボタンＧ３７と、マップ表示ボタンＧ３８と、検索ボタンＧ３９とが表示される。

参加問合メンバ画像Ｇ３０には、参加を問い合わせたメンバにかかる画像が表示される。メンバー編集ボタンＧ３１は、ユーザがタップすることによって、メンバー選択画面Ｇ２に遷移する。イベント説明欄Ｇ３２は、イベントのタイトルと、イベントの説明を記入するための欄である。なお、タイトルの入力は必須となる。候補追加ボタン３３は、日程、時間、あるいは、場所の候補を増やしたい際にユーザがタップするボタンである。ユーザがタップすると、図示されるように、候補が追加表示される。

回答候補ボタンＧ３４は、参加を問い合わせられたメンバーによりタップされるボタンであって、表示されている日程、時間、場所において開催されるイベントへの参加の可否の程度を選択肢から選択させるためのボタンである。ここでは、○、△、×のように、３択による選択肢を想定しているが、これに限られない。

日程候補欄Ｇ３５、時間候補欄Ｇ３６は、イベントを開催する日と時間とを記入する欄である。前述したごとく、候補追加ボタン３３により候補が複数ある場合、候補ごとに記入することとなる。

自由入力ボタンＧ３７は、場所に関して、コメントを記入する際にユーザがタップするボタンである。マップ表示ボタンＧ３８は、イベント作成者にあっては、当該場所を示す情報を設定するためのボタンであり、イベント参加を問い合わせられたユーザにあっては、場所の情報を表示させるためのボタンとなる。場所の情報は、住所や電話番号であってもよいし、地図情報でもよいし、これらの組み合わせであってもよい。検索ボタンＧ３９は、イベント参加を問い合わせられたユーザによって、場所等に関する情報を所定の検索ツールにより検索させるための画面に遷移するためのボタンである。

図１３は、図１０のチャット画面Ｇ４の第１の表示例を示す図である。このチャット画面Ｇ４は、作成されたイベントへの参加を問い合わせられたユーザのチャットインタフェースに表示される画面である。チャット画面Ｇ４は、単回答モード欄Ｇ４０と、選択肢モード欄Ｇ４１と、イベント説明欄Ｇ４２と、選択肢ボタンＧ４３と、回答ボタンＧ４４とが表示される。

単回答モード欄Ｇ４０には、作成されたイベントにおいて、イベントの日時、場所が１つのみ設定されている場合において表示される画面である。イベント説明欄Ｇ４２には、イベント名、日時、場所、ならびに、選択肢ボタンＧ４３が表示される。参加を問い合わせられたユーザがイベント名をタップすることで、イベント詳細画面Ｇ５に遷移する。回答ボタンＧ４４は、図示するごとく、○と△と×のそれぞれが表示されており、イベントへの参加を問い合わせられたユーザがいずれかをタップすることで、イベントへの参加の意志表明ができる。

選択肢モード欄４１には、単回答モード欄Ｇ４０と異なり、作成された１つのイベントに対して、複数の日時、場所が設定されている場合において表示される画面である。選択肢モードにおいては、ユーザが回答ボタンＧ４４をタップすることで、イベント詳細画面Ｇ５に遷移し、ユーザはイベント詳細画面Ｇ５から、それぞれの選択肢に対して、参加の意志表示をすることとなる。

図１４は、図１０のイベント詳細画面Ｇ５の表示例を示す図である。イベント詳細画面Ｇ５には、参加予定ユーザー画像Ｇ５０と、未回答ユーザー画像Ｇ５１と、一覧表示ボタンＧ５２と、回答ボタンＧ５３と、店舗画像Ｇ５４と、店舗リンクＧ５５と、コメント欄Ｇ５６とが表示される。

参加予定ユーザー画像Ｇ５０には、すでに参加を表明したユーザによって指定された画像が表示される。なお、三択での回答形式の場合、○と回答したユーザのみを表示してもよいし、○あるいは△と回答したユーザをあわせて表示してもよいし、○と△とで色をかえるなどの表示態様を変えて表示させてもよい。

未回答ユーザー画像Ｇ５１には、未回答のユーザによって指定された画像が表示される。参加予定ユーザー画像Ｇ５０と比べて、異なる表示態様で表示させてもよい。図１４においては、やや白い色調にて表示させた場合の例である。

一覧表示ボタンＧ５２は、友達一覧画面に遷移するためのボタンである。回答ボタンＧ５３においては、ユーザがタップすることで、回答の選択肢が表示され、いずれかを選択することで、回答が表示される。図示するごとく、日時、場所が複数ある場合、複数の回答ボタンＧ５３が表示される。

店舗画像Ｇ５４は、イベントが開催される店舗等があらかじめ指定している画像が表示される。店舗リンクＧ５５においては、ユーザがタップすることで、当該店舗の情報が示されたＷｅｂページが表示される。コメント欄Ｇ５６は、イベントへの参加の回答を行ったユーザがコメントを書き込むための欄である。

図１５は、図１０のチャット画面Ｇ４の第２の表示例を示す図である。第２の表示例は、図１３の第１の表示例、あるいは、図１４のイベント詳細画面Ｇ５において、いずれかのユーザーがイベント参加問合せに回答した場合に表示される画面の例である。第２の表示例においては、回答があったイベントに応じて、単回答モード表示欄Ｇ６０と、選択肢モード欄Ｇ６１が表示される。それぞれの欄において、参加を表明したユーザーによって指定された参加予定ユーザー画像Ｇ６２と、イベント詳細画面Ｇ５への遷移ボタンＧ６３が表示される。

図１６は、図１０のイベント回答確認画面Ｇ６の表示例を示す図である。このイベント回答確認画面Ｇ６は、イベントを作成したイベント主催者にかかるユーザが確認できる画面であり、その時点における回答状況が表示される画面となる。

イベント回答確認画面Ｇ６には、参加予定ユーザー画像Ｇ６４と、イベント作成画面Ｇ３への遷移ボタンＧ６５と、イベント選択肢カラムＧ６６と、が表示される。イベント選択肢カラムＧ６６には、イベントの候補数に応じて、列方向に、イベントの候補場所、日時が表示される。行方向には、それぞれの候補ごとに、○、△、×を回答した人数が表示される集計欄Ｇ６８と、回答者ごとの回答が表示される回答欄Ｇ６９とが表示される。

イベント主催者は、イベントの参加の可否状況を視認して、いずれの候補を採用するかを決定し、採用にかかる候補の欄に表示されたイベント確定ボタンＧ６７をタップする。イベント確定ボタンＧ６７がタップされると、確定されたイベントに参加の旨を回答したユーザにその旨のメッセージが通知される。メッセージは、登録ユーザであればチャットインタフェース上に表示される。非登録ユーザであれば、変換された通信方式により通知される。あるいは、決定されたイベントを知らせるためのＵＲＬを通知する。なお、参加不明、参加不可能の旨を回答したユーザーに対しても通知されてもよい。その場合、イベント主催者は、コメントをあわせて通知することができ、そのコメントはあらかじめ設定されたいくつかの定型文から選択されてもよい。

以上、本発明を実施例をもとに説明した。本発明は上述した実施例並びに各実施例の内容に限定されるものではなく、本発明の要旨の範囲内において種々に変形して実施をすることが可能である。上記実施例は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

実施例１にかかるチャットシステムを示す図である。 図１のチャットシステムにおけるサーバの構成例を示す図である。 図２のサーバにおけるチャット制御部の構成例を示す図である。 図１のモバイル端末あるいはＰＣ端末における構成例を示す図である。 図３のチャット制御部の第１の処理手順を示すフローチャートである。 図３のチャット制御部の第２の処理手順を示すフローチャートである。 実施例２にかかるチャット制御部の構成例を示す図である。 実施例２にかかるユーザ端末とサーバによるメッセージ管理に関する処理手順例を示すシーケンス図である。 実施例３にかかるチャット制御部の構成例を示す図である。 実施例３にかかるチャットインタフェース画面の遷移例を示す図である。 図１０のイベント画面Ｇ１の表示例を示す図である。 図１０のイベント作成画面Ｇ３の表示例を示す図である。 図１０のチャット画面Ｇ４の第１の表示例を示す図である。 図１０のイベント詳細画面Ｇ５の表示例を示す図である。 図１０のチャット画面Ｇ４の第２の表示例を示す図である。 図１０のイベント回答確認画面Ｇ６の表示例を示す図である。

１０ サーバ、 １２ サーバ受信部、 １４ チャット制御部、 １６ サーバ送信部、 ２０ サーバメモリ、 ２２ 登録制御部、 ２４ 選択部、 ２６ 変換部、 ３０ ネットワーク、 ４０ 基地局、 ４０ａ 第１基地局、 ４０ｂ 第２基地局、 ４０ｃ 第３基地局、 ５０ モバイル端末、 ５０ａ 第１モバイル端末、 ５０ｂ 第２モバイル端末、 ５０ｃ 第３モバイル端末、 ５２ 端末受信部、 ５４ 端末制御部、 ５６ 端末送信部、 ５８ ユーザインタフェース、 ６０ 端末メモリ、 ６２ メッセージ管理部、 ６４ Ｗｅｂ更新部、 ７０ ＰＣ端末、 ７２ チャット制御部、 ７４ チャット制御部、 ８０ イベント管理部、 １００ チャットシステム

Claims (7)

1. 情報処理端末を用いたメッセージの送受信を行うサービスに用いられる方法であって、
   送信先と、当該送信先に送信されるべきメッセージとを受け付けるステップ、
   受け付けた送信先のユーザについてのメンバ情報を用いて、送信先のユーザがチャットシステムの登録メンバであるか否かを判別するステップ、
   受け付けた送信先に関してメモリに登録されている１以上の通信方式から、適用すべき通信方式の優先順位が示された情報にしたがって、１つの通信方式を選択するステップ、
   選択された通信方式によって、送信先にメッセージを送信するステップ、
   を含み、
   前記適用すべき通信方式の優先順位が示された情報は、送信先のユーザが登録メンバであればチャット形式を選択し、非登録メンバであればチャット形式以外の通信方式を選択することが示されている
   ことを特徴とする通信方法。
2. 情報処理端末に記憶されている１以上の連絡先情報を取得するステップ、
   取得した連絡先情報と、登録済の連絡先情報とを照合するステップ、
   照合の結果、２つの連絡先情報に共通する情報が含まれている場合、登録済の連絡先情報に、取得した連絡先情報を結合させるステップ、
   を含むことを特徴とする請求項１に記載の通信方法。
3. チャット以外の通信方式によるメッセージを受け付けた場合、該メッセージをチャット形式のメッセージに変換するステップ、
   変換したメッセージをチャットインタフェースに表示させるステップ、
   を含むことを特徴とする請求項１又は２に記載の通信方法。
4. チャットインターフェースに表示された１以上のメッセージをユーザに選択させるステップ、
   選択されたメッセージにフラグを付して、前記ユーザが選択したメッセージとして管理するステップ、
   前記ユーザからの指示を契機として、フラグをもとに、前記ユーザが過去に選択した１以上のメッセージを抽出するステップ、
   抽出したメッセージを、Ｗｅｂページへエクスポートして、所定のユーザに閲覧させるステップ、
   を含むことを特徴とする請求項１乃至３のいずれか１項に記載の通信方法。
5. １以上の候補日時と、１以上の候補地とをそれぞれ１つずつ組み合わせたイベント情報を作成するステップ、
   作成されたイベント情報に関するイベントへの参加の可否を問い合わせるステップと、
   を含み、
   前記選択するステップは、イベントへの参加の可否を問い合わせる際において、チャット以外の通信方式を選択した場合、参加の可否に関する回答をユーザから受け付けるためのＵＲＬ情報を送信すべきメッセージに含めることを特徴とする請求項１乃至４のいずれか１項に記載の通信方法。
6. 情報処理端末を用いたメッセージの送受信を行うサービスに用いられるプログラムであって、
   送信先と、当該送信先に送信されるべきメッセージとを受け付けるステップ、
   受け付けた送信先のユーザについてのメンバ情報を用いて、送信先のユーザがチャットシステムの登録メンバであるか否かを判別するステップ、
   受け付けた送信先に関してメモリに登録されている１以上の通信方式から、適用すべき通信方式の優先順位が示された情報にしたがって、１つの通信方式を選択するステップ、
   選択された通信方式によって、送信先にメッセージを送信するステップ、
   を含む処理をコンピュータに実行させ、
   前記適用すべき通信方式の優先順位が示された情報は、送信先のユーザが登録メンバであればチャット形式を選択し、非登録メンバであればチャット形式以外の通信方式を選択することが示されている
   ことを特徴とするプログラム。
7. 情報処理端末を用いたメッセージの送受信を行うサービスに用いられる通信装置であって、
   送信先と、当該送信先に送信されるべきメッセージとを受け付ける受付部と、
   受け付けた送信先のユーザについてのメンバ情報を用いて、送信先のユーザがチャットシステムの登録メンバであるか否かを判別し、受け付けた送信先に関してメモリに登録されている１以上の通信方式から、適用すべき通信方式の優先順位が示された情報にしたがって、１つの通信方式を選択する選択部と、
   選択された通信方式によって、送信先にメッセージを送信する送信部と、
   を備え、
   前記適用すべき通信方式の優先順位が示された情報は、送信先のユーザが登録メンバであればチャット形式を選択し、非登録メンバであればチャット形式以外の通信方式を選択することが示されている
   ことを特徴とする通信装置。
   
   

Images