JP2014026486A - サーバ装置 - Google Patents

Abstract

【課題】チャットサービス上における友だちは、そのサービスに登録しているユーザのみを対象としているため、未登録のユーザを友だちにすることができなかった。
【解決手段】サーバ装置１０は、チャットサービスに登録している登録ユーザ同士におけるメッセージの送受信を制御し、かつ、登録ユーザと未登録のユーザとの間におけるメッセージの送受信を制御する。また、サーバ装置１０は、登録ユーザのフレンドリストを管理し、登録ユーザに対して、フレンドリストに追加すべき他のユーザを推奨する。また、サーバ装置１０は、チャットサービスへの登録の有無に応じて設定された所定の条件を用いて、登録ユーザに推奨すべき他のユーザを決定する。
【選択図】図１

Description

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

従来、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）端末や携帯端末等の情報処理装置を用いてリアルタイムの文字通信を行う、いわゆるチャットというサービスが提供されている。
チャットの態様として、ユーザが1対1で行うユーザ間チャットや、特定のグループに属する複数のユーザ間で行うグループ内チャット、あるいは、グループ間のチャットが挙げられる。従来、ユーザ間でグループを形成しチャットを行う技術を開示した特許文献が開示されている。
このようなユーザ間チャット、グループ内チャット、グループ間チャットを適用したサービスは多く見受けられるが、これらのサービスは、チャットを開始するに当たり、友だち登録、グループ登録等所定の承認プロセスを経ることが前提となる。
２０１０年以降、スマートフォンと呼ばれる多機能型携帯端末が急速に普及し、携帯端末で利用されることを前提としたチャットサービスが多く提供され、利用者数が増えている。このようなサービス普及により、これまで知り合うことのなかった、新しい友だちや知り合いを増やせるようなサービス・機能が期待されている。

特開２０００−０２２７０６号公報

しかしながら、従来の技術では、チャットサービス上における友だちは、そのサービスに登録しているユーザのみを対象としているため、未登録のユーザを友だちにすることができなかった。

本発明はかかる課題に鑑みてなされたものであり、その目的は、チャットサービスに未登録のユーザであっても、そのユーザをそのチャットサービスにおける友だちに登録できるサーバ装置、方法、および、プログラムを提供することにある。

本発明のある態様は、サーバ装置に関する。このサーバ装置は、チャットサービスに登録している登録ユーザ同士におけるメッセージの送受信を制御し、かつ、登録ユーザと未登録のユーザとの間におけるメッセージの送受信を制御するサーバ装置であって、登録ユーザのフレンドリストを管理するフレンドリスト管理部と、登録ユーザに対して、フレンドリストに追加すべき他のユーザを推奨するサジェスト部と、を備える。サジェスト部は、チャットサービスへの登録の有無に応じて設定された所定の条件を用いて、登録ユーザに推奨すべき他のユーザを決定する。

このような態様によると、チャットサービスへの登録の有無に応じて設定された所定の条件を用いて、推奨すべき他のユーザを決定することによって、未登録のユーザを友だちとしてフレンドリストに登録することができる。

また、このサーバ装置は、サジェスト部によって推奨された他のユーザのユーザ情報をサジェストリストに登録するサジェストリスト管理部と、をさらに備えてもよい。フレンドリスト管理部は、サジェストリストに含まれたユーザ情報のうち、当該登録ユーザによって選択されたユーザ情報をフレンドリストに追加してもよい。また、サジェストリスト管理部は、フレンドリストへのユーザ情報の追加に伴って、そのユーザ情報をサジェストリストから消去してもよい。

このような態様によると、当該登録ユーザによって選択された他のユーザに係るユーザ情報をフレンドリストに追加することによって、他のユーザを友だちとして簡易に登録できる。また、フレンドリストへの追加に伴って、そのユーザ情報をサジェストリストから消去することによって、友だちとして登録されている他のユーザを再度推薦するといった誤推薦を防止できる。

また、このサーバ装置において、サジェスト部は、チャットサービスに登録されていない未登録ユーザであって、登録ユーザが管理するユーザ情報の中に、その未登録ユーザのユーザ情報が含まれている場合、その未登録ユーザを当該登録ユーザに推奨すべき他のユーザとして決定してもよい。

このような態様によると、登録ユーザが管理するユーザ情報の中に未登録ユーザのユーザ情報が含まれている場合、その未登録ユーザを当該登録ユーザに推奨すべき他のユーザとして決定することによって、未登録のユーザであっても友だちにすることができる。

また、このサーバ装置において、サジェスト部は、登録ユーザが管理するユーザ情報の中に未登録ユーザのユーザ情報が含まれており、かつ、そのユーザ情報に、モバイルに関する連絡先情報が含まれている場合、その未登録ユーザを当該登録ユーザに推奨すべき他のユーザとして決定してもよい。

このような態様によると、未登録ユーザのユーザ情報内にモバイルに関する連絡先情報が含まれている場合、その未登録ユーザを当該登録ユーザに推奨すべき他のユーザとして決定することによって、モバイルにて使用されることが多いチャットシステムを頻繁に使用させることができる。

また、このサーバ装置において、サジェスト部は、未登録ユーザであった第１ユーザに対して、第１ユーザが登録ユーザになった後に推奨すべき他の既登録ユーザとして、未登録であったときにすでにフレンドリストに第１ユーザを追加している既登録ユーザを決定してもよい。

このような態様によると、未登録ユーザであった第１ユーザに対して、第１ユーザが登録ユーザになった後に推奨すべき他の既登録ユーザとして、未登録であったときにすでにフレンドリストに第１ユーザを追加している既登録ユーザを決定することによって、未登録ユーザには新規登録の時点から多数の友だちが推奨されるため、友だち関係を形成しやすく、チャットサービスの使用意欲を高めることができる。

また、このサーバ装置において、サジェスト部は、チャットサービスに登録されているユーザであって、かつ、そのユーザのフレンドリストに登録ユーザが含まれている場合に、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定してもよい。

このような態様によると、フレンドリストに登録ユーザが含まれている場合に、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定することによって、お互いに友だちとしてフレンドリストに登録でき、以後のチャットを円滑に実施することができる。

また、このサーバ装置において、サジェスト部は、チャットサービスに登録されているユーザであって、かつ、現在もしくは過去において、チャットサービス上でそのユーザと前記登録ユーザとの間でお互いにメッセージを送受信したことがある場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定してもよい。

このような態様によると、現在もしくは過去において、チャットサービス上でそのユーザと前記登録ユーザとの間でお互いにメッセージを送受信したことがある場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定することによって、チャットにて知り合ったユーザを友だちとして簡易に登録できる。

また、このサーバ装置は、それぞれ特定の性質を有する複数のグループを設定するグループ設定部と、グループ設定部によって設定された複数のグループのうち、登録ユーザにより選択されたグループと、その登録ユーザとを関連づけて管理するグループ管理部と、をさらに備えてもよい。サジェスト部は、チャットサービスに登録されているユーザであって、かつ、グループ管理部によって管理されている同じグループにそのユーザと登録ユーザとが共に関連づけられている場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定してもよい。

このような態様によると、グループ管理部によって管理されている同じグループにそのユーザと登録ユーザとが共に関連づけられている場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定することによって、同じグループに所属しているユーザを友だちとして簡易に登録できる。

また、このサーバ装置において、サジェスト部は、チャットサービスに登録されているユーザであって、かつ、そのユーザと登録ユーザのそれぞれのフレンドリストに共通のユーザが１人以上含まれている場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定してもよい。

このような態様によると、フレンドリストに共通のユーザが１人以上含まれている場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定することによって、共通の友だちが多いユーザを友だちとして簡易に登録できる。

また、このサーバ装置において、サジェスト部は、チャットサービスに登録されているユーザであって、かつ、そのユーザと登録ユーザとがＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）上の友達である場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定してもよい。

このような態様によると、ＳＮＳ上の友達である場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定することによって、ＳＮＳ上の友だちをチャットシステムでも同様に友だちとして簡易に登録できる。

また、このサーバ装置は、登録ユーザからの要求にもとづいて検索する場合は当該サーバ装置に記憶されているすべてのユーザ情報を対象として、登録ユーザからの要求がない場合は登録ユーザのサジェストリストに含まれたユーザを対象として、表示対象とすべき１以上のユーザを検索する検索部と、検索部によって検索された１以上のユーザ情報の表示順序を決定する表示順序決定部と、表示順序決定部によって決定された順序で、検索部によって検索されたユーザのユーザ情報を登録ユーザのチャット画面上に表示する表示制御部と、をさらに備えてもよい。

このような態様によると、検索された１以上のユーザ情報の表示順序を決定することによって、登録ユーザと関係の深いユーザを優先的に表示させることができる。

また、このサーバ装置において、表示順序決定部は、検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、フレンドリストに登録ユーザが含まれているユーザの優先順位が上位となるように、表示順序を決定してもよい。

このような態様によると、フレンドリストに登録ユーザが含まれているユーザの優先順位が上位となるように、表示順序を決定することによって、自分をフレンドリストに追加しているユーザを優先的に表示させることができるため、登録ユーザは、より親密度が高いユーザを効率的に知ることができる。

また、このサーバ装置において、表示順序決定部は、検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、現在もしくは過去において、登録ユーザとの間でなされたメッセージの送受信の回数が多いユーザほど優先順位が上位となるように、表示順序を決定してもよい。

このような態様によると、現在もしくは過去におけるチャットの回数に応じて表示することによって、登録ユーザは、より親密度が高いと推定されるユーザを効率的に知ることができる。

また、このサーバ装置は、それぞれ特定の性質を有する複数のグループを設定するグループ設定部と、グループ設定部によって設定された複数のグループのうち、登録ユーザにより選択されたグループと、その登録ユーザとを関連づけて管理するグループ管理部と、をさらに備えてもよい。表示順序決定部は、検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、登録ユーザと共に関連づけられたグループの数が多いユーザほど優先順位が上位となるように、表示順序を決定してもよい。

このような態様によると、お互いに登録しているグループの数が多いユーザを上位に表示することによって、登録ユーザは、より親密度が高いと推定されるユーザを効率的に知ることができる。

また、このサーバ装置において、表示順序決定部は、表示順序を決定するための条件として、
（条件１）フレンドリスト内の前記登録ユーザの存否
（条件２）前記登録ユーザとのメッセージの送受信の回数Ａ
（条件３）前記登録ユーザと共に関連づけられたグループの数Ｂ
（条件４）お互いのフレンドリスト内の共通のユーザの人数Ｃ
が設定され、それぞれの条件について優先ポイントＰ１〜Ｐ４が設定されている場合に、
Ｐ１＋Ａ×Ｐ２＋Ｂ×Ｐ３＋Ｃ×Ｐ４
によって算出された値の大小によって表示順序を決定してもよい。また、このサーバ装置において、表示順序決定部は、優先ポイントとして、Ｐ１≧Ｐ２≧Ｐ３≧Ｐ４となるように設定されていてもよい。

このような態様によると、登録ユーザは、より親密度が高いと推定されるユーザを効率的に知ることができる。

本発明の別の態様は、方法である。この方法は、チャットサービスに登録している登録ユーザ同士におけるメッセージの送受信を制御し、かつ、登録ユーザと未登録のユーザとの間におけるメッセージの送受信を制御する方法であって、登録ユーザのフレンドリストを管理するステップと、登録ユーザに対して、フレンドリストに追加すべき他のユーザを推奨するステップと、を含み、チャットサービスへの登録の有無に応じて設定された所定の条件を用いて、前記登録ユーザに推奨すべき他のユーザを決定する。

本発明の別の態様は、プログラムである。このプログラムは、チャットサービスに登録している登録ユーザ同士におけるメッセージの送受信を制御し、かつ、登録ユーザと未登録のユーザとの間におけるメッセージの送受信を制御する方法であって、登録ユーザのフレンドリストを管理するステップと、登録ユーザに対して、フレンドリストに追加すべき他のユーザを推奨するステップと、を含み、チャットサービスへの登録の有無に応じて設定された所定の条件を用いて、前記登録ユーザに推奨すべき他のユーザを決定する処理をコンピュータに実行させる。

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

本発明によると、未登録ユーザであったとしても、チャットサービス上の友だちとして登録できる。

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

また、登録ユーザは、チャットサービスを管理するサーバ（以下、「チャットサーバ」ともいう。）上に知り合い（以下、「フレンド」もしくは「友だち」という）をフレンドリストに登録することで、チャット相手を効率的に探したり、また、チャット相手について記録されているユーザ情報を閲覧できる。なお、フレンドリストは、登録ユーザ毎にサーバにて管理される。

フレンドリストへの登録は、チャットサーバから推奨される友だち候補のリスト（以下、「サジェストリスト」という。）をもとに、サジェストリストに含まれたいずれかのユーザを選択することによってなされる。詳細は後述するが、推奨の基準は、チャットサービス上におけるその登録ユーザとの間の「親密度」であり、これが高いほど優先的にサジェストリストに追加される。また、サジェストリストには、チャットサービスに登録していないユーザ（以下、「未登録ユーザ」という。）も含まれる。なお、サジェストリストは、登録ユーザ毎にサーバにて管理される。

サジェストリストには、知り合いの名前をチャット画面上に入力して検索することによって表示されるリスト、あるいは、ユーザの端末に記憶されている電話帳をチャットサーバにアップロードすることによって表示されるリストなどを含めることができる。このように生成されたサジェストリストの中から、登録ユーザにより友だちとして登録したい他のユーザが選択されることによって、フレンドリストに登録できる。なお、サジェストリストがユーザ端末に表示される際の順序は、前述した推奨の基準「親密度」に相当する基準となる。

ここで、未登録ユーザであってもフレンドリストに登録されている可能性があることから、新たにチャットサービスに登録した未登録ユーザであっても、既登録ユーザの中には、その未登録ユーザをすでにフレンドリストに追加している場合がある。こういった場合に、その未登録ユーザが登録ユーザになった後に、未登録であったときにすでにフレンドリストに追加している既登録ユーザを友だちとして推奨することによって、新規登録ユーザには、新規登録の時点から多数の友だちが推奨されるため、友だち関係を形成しやすく、チャットサービスの使用意欲を高めることができる。

従来のチャットサービスにおいては、サービスに登録したものの、友だちが思うように増えず、サービスの使用頻度が低くなったり、サービスを停止したりするといった課題があったが、本発明においては、以上の課題を解消しており、チャット開始当初から複数の友だちを獲得できるチャンスがあるため、チャットサービスの使用意欲を高められ、ひいてはチャットサービス全体を盛り上げることができる。以下、例を用いて説明する。

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

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

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

サーバ１０は、ユーザ端末からの要求にしたがって、アプリをダウンロードさせる。その後、ユーザ端末内のメモリに記憶されている連絡先情報をアップロードさせて、サーバ１０内のメモリにインポートすることによって、ユーザはチャットサービスの使用を開始することができる。ここで、サーバ１０は、チャットシステムにおける友だちを推奨する友だち推奨機能と、友だちのリストを管理するフレンドリスト管理機能と、友だちなどを検索したり、チャット相手を検索する検索機能と、チャット相手とチャットをするためのメール統合機能と、を有する。

友だち推奨機能は、フレンドリストに登録すべきユーザを紹介、推奨する機能（以下、「サジェスト機能」という。）を有する。詳細は後述するが、サジェスト機能は、登録ユーザに推奨すべき他のユーザを決定する。フレンドリスト管理機能は、推奨されたユーザのうち、登録ユーザによって選択されたユーザをフレンドリストに登録する機能を有する。検索機能は、サーバ１０内に記憶されたユーザ情報を対象として検索し、検索された１以上のユーザ情報をユーザ端末に所定の順序で表示する。ユーザ情報は、登録ユーザのＩＤ、所属するグループのＩＤ、過去のチャット相手のユーザＩＤ、ＳＮＳ上のＩＤなどが含まれる。

メール統合機能は、チャット相手が登録ユーザであるか否かをユーザに考慮させることなく、所望のユーザとの間でチャットを実施させるための機能である。サーバ１０は、ユーザ端末からチャットサービスの開始の要求があると、チャットサービスの相手先への通信方式を決定する。具体的には、通信方式の優先度情報に従って、サーバ１０内のメモリに格納された登録情報から最も適した通信方式を決定し、ユーザ端末から送信されたメッセージをその通信方式、たとえば、Ｅメールの形式に変換して、相手先に送信する。

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

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

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

サーバ受信部１２は、ユーザ端末からの信号を受信し、所定の復調処理を実施して、チャット制御部１４に復調された信号を送る。サーバ送信部１６は、チャット制御部１４にて選択された通信方式にて、所定のメッセージを送信相手へ送信する。また、サーバ送信部１６は、所定のタイミングで、サーバメモリ２０内に記憶されたフレンドリスト、あるいは、サジェストリストをチャット制御部１４を介して取得し、そのリストに紐づけられたユーザのユーザ端末に送信する。サーバ受信部１２、および、サーバ送信部１６における変復調処理は、従来用いられている変復調技術が用いられてよく、このような態様であったとしても、本発明を適用することができることは当業者に理解されるところである。

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

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

また、チャット制御部１４は、友だち推奨機能を有し、チャットサービスへの登録の有無に応じて設定された所定の条件を用いて、友だち候補として、登録ユーザに推奨すべき他のユーザを決定して、サーバメモリ２０内のサジェストリストに登録する。チャットサービスへの登録の有無に応じて設定された所定の条件とは、推奨対象のユーザが登録ユーザである場合と、未登録ユーザである場合とで、それぞれ異なった条件であることを指す。この条件は、被推奨ユーザとの親密度を推定するための条件となる。

また、チャット制御部１４は、フレンドリスト管理機能を有し、友だち候補としてサジェストリストに登録されたユーザのうち、サーバ受信部１２を介して受け付けた、登録ユーザから選択されたユーザをサーバメモリ２０内のフレンドリストに登録する。フレンドリストは、サーバメモリ２０内において、登録ユーザごとに管理される。

また、チャット制御部１４は、検索機能を有し、登録ユーザからの要求がない場合は、サーバメモリ２０に記憶されている登録ユーザのサジェストリストに含まれたユーザを対象として、表示対象とすべき１以上のユーザを検索する。ここで検索されたユーザは、友だち候補として、ユーザ端末に表示される。

複数のユーザが検索された場合、所定のアルゴリズムによって表示順序を決定して、ユーザ端末のチャット画面上に表示する。すなわち、ユーザ端末には、「ともだちかも」として、友だち候補の一覧が表示される。検索のタイミング、表示のタイミングは、チャットサービスアプリを起動したときや、起動後、一定間隔において実施されてもよい。これにより、ユーザに対して、友だちを増やすきっかけを与えることができる。

また、チャット制御部１４は、登録ユーザから実名検索の要求をサーバ受信部１２から受け付けて、検索対象の実名を取得して、その実名を対象にサーバメモリ２０内に記憶されたすべてのユーザ情報を対象として検索する。検索は、前方一致、部分一致などの従来の検索技術が用いられてもよい。

複数のユーザが検索された場合、登録ユーザとの親密度に応じて決定される所定のアルゴリズムによって表示順序を決定して、サーバ送信部１６を介して送信し、ユーザ端末のチャット画面上に表示させる。サジェストリストは、サーバメモリ２０内において、登録ユーザごとに管理される。

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

図３は、図２のチャット制御部１４の構成例を示す図である。チャット制御部１４は、フレンド登録部２００と、検索表示部３００と、メール統合部４００とを含む。フレンド制御部２００は、フレンドリスト管理機能を有し、サーバメモリ２０内のサジェストリストおよびフレンドリストを管理する。

検索表示部３００は、検索機能を有し、サーバメモリ２０内のサジェストリストもしくはユーザ情報を用いて検索し、所定のアルゴリズムによって決定された表示順序で、ユーザ端末のチャット画面上に検索結果を表示する。メール統合部４００は、ユーザから受け付けた送信メッセージと送信先をもとに、送信先への通信方式を決定する。また、メール統合部４００は、メール統合機能を有し、ユーザ端末からの要求をもとにイベントを管理する。以下、順に説明する。

（１）フレンドリスト管理機能
まず、図３のフレンド登録部２００によるフレンドリスト管理機能について説明する。図４は、図３のフレンド登録部２００の構成例を示す図である。フレンド登録部２００は、グループ設定部２１０と、グループ管理部２１２と、サジェスト部２１４と、フレンドリスト管理部２１６と、サジェストリスト管理部２１８とを含む。

グループ設定部２１０は、それぞれ特定の性質を有する複数のグループを設定する。グループ管理部２１２は、グループ設定部２１０によって設定された複数のグループのうち、登録ユーザにより選択されたグループと、その登録ユーザとを関連づけてサーバメモリ２０上で管理する。

ここで、「グループ」とは、同じ趣味や、共通の地域など、ユーザ間における任意の共通事項の存在をきっかけとして、任意のユーザによって作成される。グループへの加入は、グループに所属しているユーザからの招待や、自己の選択により加入することができる。グループに加入すると、自己のユーザ情報内に、加入したグループのグループＩＤが追加される。このグループＩＤを用いると、特定の仲間同士におけるチャットの実施や、後述するイベント生成、管理が容易となる。

フレンドリスト管理部２１６は、登録ユーザ毎に、フレンドリストをサーバメモリ２０上にて管理する。サジェスト部２１４は、登録ユーザに対して、その登録ユーザとの親密度を考慮して、フレンドリストに追加すべき他のユーザを推奨する。ここで、サジェスト部２１４は、チャットサービスへの登録の有無に応じて設定された所定の条件を用いて、登録ユーザに推奨すべき他のユーザを決定する。詳細は後述する。サジェストリスト管理部２１８は、サジェスト部２１４によって決定された他のユーザのユーザ情報をサーバメモリ２０内のサジェストリストに登録する。

ここで、フレンドリスト管理部２１６は、サジェストリストに含まれたユーザ情報のうち、当該登録ユーザによって選択されたユーザ情報をサーバメモリ２０内のフレンドリストに追加する。サジェストリスト管理部２１８は、フレンドリストへのユーザ情報の追加に伴って、そのユーザ情報をサーバメモリ２０内のサジェストリストから消去する。

ここで、サジェスト部２１４における動作例（Ａ）〜（Ｇ）について順に説明する。いずれも、登録ユーザとの親密度の高さに応じて、その登録ユーザに推奨すべきユーザが決定される。なお、（Ａ）は未登録ユーザが推奨対象となる場合、（Ｂ）〜（Ｇ）は登録ユーザが推奨対象となる場合の動作例である。

（Ａ）サジェスト部２１４は、チャットサービスに登録されていない未登録ユーザであって、ユーザ端末内に記憶されている連絡先情報の中に、フレンドリストに含まれていないユーザの情報が含まれている場合、そのユーザを友だち候補としてサーバメモリ２０内のサジェストリストに追加させる。登録ユーザであっても、サジェストリストに追加する対象としてもよい。また、追加させるユーザとして、連絡先情報にモバイルに関する連絡先情報、たとえば、携帯端末の電話番号やメールアドレスが含まれている場合に限定してもよい。

この（Ａ）の動作例は、たとえば、サーバ１０にユーザ端末内の連絡先情報がアップロードされたことを契機として実施されてもよい。アップロードは、チャットアプリをダウンロードした際に実施されるほか、連絡先情報に新たな情報が追加された際、あるいは、定期的に実施されるものである。これにより、ユーザは、ユーザ端末内に登録された友だちをチャットサービス上においても友だちとして登録できる。

（Ｂ）サジェスト部２１４は、未登録ユーザであった第１ユーザに対して、第１ユーザが登録ユーザになった後に推奨すべき他の既登録ユーザとして、未登録であったときにすでにフレンドリストに第１ユーザを追加している既登録ユーザをサーバメモリ２０内のサジェストリストに追加させる。これにより、新規登録ユーザである第１ユーザは、チャットサービスを開始した直後から、多くの友だちをフレンドリストに登録することができる。

（Ｃ）サジェスト部２１４は、そのユーザ自身をフレンドリストに任意のユーザを追加した他のユーザが存在する場合に、推奨すべきユーザとして、当該他のユーザを友だち候補としてサーバメモリ２０内のサジェストリストに追加させる。

この（Ｃ）の動作例は、たとえば、他のユーザがフレンドリストに新たに登録したことを契機として、その登録されたユーザのサジェストリストに、登録実行者の他のユーザが登録される。これにより、お互いに友だちとして登録されるきっかけとなり、以後のコミュニケーションが簡易に実施でき、また、チャットサービス全体を活性化できる。

（Ｄ）サジェスト部２１４は、現在または過去において、チャットシステム上においてメッセージの送受信をしたことがあるユーザが存在する場合に、推奨すべきユーザとして、そのユーザを友だち候補としてサーバメモリ２０内のサジェストリストに追加させる。

この（Ｄ）の動作例は、たとえば、チャットを開始するためのチャットルームと呼ばれるチャットシステム上の仮想空間内において、登録ユーザが入っているチャットルーム内に、登録ユーザが入る以前から入っていたユーザ、あるいは、登録ユーザが入った後に新たにユーザが入ってきたことを契機として、そのユーザが登録ユーザのサジェストリストに登録される。また、過去において、登録ユーザとチャットルームにおいて同居したことがあるユーザも、サジェストリストに登録される対象となる。このように、現在または過去において、チャットルーム内に同居した場合、登録ユーザのユーザ情報内に、同居したユーザのユーザＩＤが記憶され、これをもとに、サジェスト部２１４は推奨処理を実行することとなる。なお、チャットルームは、同じグループに所属するユーザで形成されるものでも、複数のグループにそれぞれ属するユーザ同士、たとえば、同じグループに属するユーザと他のグループに属するユーザとで形成されるものでもよい。サジェスト部２１４は、所属するグループによらず、チャットルーム内において登録ユーザとチャットを実施、もしくは、同居したことがあることをもって、そのユーザを推奨対象としてもよい。

（Ｅ）サジェスト部２１４は、同一のグループに共に所属しているユーザが存在する場合に、推奨すべきユーザとして、そのユーザを友だち候補としてサーバメモリ２０内のサジェストリストに追加させる。

この（Ｅ）の動作例は、登録ユーザが新たにグループに登録した場合、あるいは、登録ユーザが登録しているグループに新たに他のユーザが登録してきた場合を契機として、その新たに入ってきたユーザが、登録ユーザのサジェストリストに登録される。これにより、グループ内のコミュニケーションを活発化でき、後発にグループに参加したユーザであっても、積極的にそのグループに参加することができる。なお、サジェスト部２１４は、前述の（Ｄ）と組み合わせた条件をもって、推奨してもよい。すなわち、サジェスト部２１４は、登録ユーザとチャットを実施した、または、同居したユーザであって、かつ、同一グループであるユーザを推奨してもよい。

（Ｆ）サジェスト部２１４は、共通の友だちをフレンドリスト内に有するユーザを友だち候補としてサーバメモリ２０内のサジェストリストに追加させる。この（Ｆ）の動作例は、共通の友だちの人数が所定の人数、たとえば、３人以上になったことを契機として実行されてもよい。

（Ｇ）サジェスト部２１４は、ＳＮＳ上の友だちが登録ユーザである場合に、推奨すべきユーザとして、その友だちをチャットサービス上の友だち候補としてサーバメモリ２０内のサジェストリストに追加させる。この処理は、ＳＮＳ連携の要求をユーザ端末からサーバ受信部１２を介して受け付けたことを契機として実行されてもよい。ＳＮＳとは、Ｆａｃｅｂｏｏｋ（登録商標）などのネットワーク上のコミュニティを含む。これにより、ＳＮＳ上の友だちもチャットサ―ビス上の友だちとして簡易に登録できる。

以上、７つの場合を列挙したが、これにかぎらず、同じ年代、生年月日が同一、検索ユーザと居住地が同じ、後述するイベント管理機能において管理されるイベントに共に参加したことがあるなど、お互いに親密度が高いと推定される共通事項が存在するユーザがいた場合、そのユーザを登録ユーザのサジェストリストに登録してもよい。

また、フレンド登録部２００は、登録ユーザのＳＮＳ上の友だちであって、かつ、その友だちがチャットサービスに未登録である場合、その友だちに、チャットサービスへの登録を促す通知を行ってもよい。通知は、電子メールで行われてもよく、登録可能なＵＲＬに誘導させるためのメッセージが含まれる。これにより、チャットサービスの登録者を効率的に増やすことができる。

（２）検索機能
つぎに、図３の検索表示部３００による検索機能について説明する。図５は、図３の検索表示部３００の構成例を示す図である。検索表示部３００は、検索部３１０と、表示順序決定部３１２と、表示制御部３１４とを含む。なお、以下においては、検索を実行する登録ユーザを検索ユーザと称することとする。

検索部３１０は、検索ユーザのユーザ端末に表示された検索ウインドウ内になんらかの文字を入力するなどの登録ユーザからの検索要求にもとづいて検索する場合は当該サーバ装置に記憶されているすべてのユーザ情報を対象として、表示対象とすべき１以上のユーザを検索する。登録ユーザからの要求がない場合は、チャットアプリ起動時に、あるいは、定期的に、登録ユーザのサジェストリストに含まれたユーザを対象として、表示対象とすべき１以上のユーザを検索する。

表示順序決定部３１２は、検索部３１０によって複数のユーザが検索された場合、それらのユーザ情報の表示順序を所定の条件を用いて決定する。この所定の順序は、検索ユーザとの親密度の高さに応じて決定される。表示制御部３１４は、表示順序決定部３１２によって決定された順序で、検索部３１０によって検索されたユーザのユーザ情報を登録ユーザのチャット画面上に表示する。

ここで、表示順序決定部３１２における所定の条件について説明する。

（条件１）フレンドリスト内の検索ユーザの存否
表示順序決定部３１２は、検索された複数のユーザのうち、フレンドリストに検索ユーザが含まれている（検索ユーザをフレンドリストに登録している）ユーザの優先順位が上位となるように、表示順序を決定する。

（条件２）検索ユーザとのメッセージの送受信の回数
また、表示順序決定部３１２は、検索された複数のユーザのうち、現在もしくは過去において、検索ユーザとの間でなされたメッセージの送受信の回数が多いユーザほど優先順位が上位となるように、表示順序を決定する。

（条件３）検索ユーザと共に関連づけられたグループの数
また、表示順序決定部３１２は、検索された複数のユーザのうち、検索ユーザと共に関連づけられたグループの数が多いユーザほど優先順位が上位となるように、表示順序を決定する。

（条件４）お互いのフレンドリスト内の共通のユーザの人数
表示順序決定部３１２は、検索された複数のユーザのうち、検索ユーザとの間で、お互いのフレンドリストに共通に登録されているユーザの人数が多いユーザほど優先順位が上位となるように、表示順序を決定する。

以上、４つの条件を列挙したが、これにかぎらず、検索ユーザと同じ年代、生年月日が同一、検索ユーザと居住地が同じ、後述するイベント管理機能において管理されるイベントに検索ユーザと共に参加したことがあるなど、検索ユーザとの間で親密度が高いと推定される共通事項が存在することを条件として、表示順序が決定されてもよい。

また、表示順序決定部３１２は、表示順序を決定するための条件１〜条件４について優先ポイントＰ１〜Ｐ４が設定されてもよい。このとき、条件２における「送受信の回数」をＡとし、条件３における「登録ユーザと共に関連づけられたグループの数」をＢとし、条件４における「お互いのフレンドリスト内の共通のユーザの人数」をＣとした場合、表示順序決定部３１２は、「Ｐ１＋Ａ×Ｐ２＋Ｂ×Ｐ３＋Ｃ×Ｐ４」の式にしたがって、スコアを算出し、スコアが大きい順に、表示順序を上位としてもよい。また、表示順序決定部３１２は、優先ポイントとして、Ｐ１≧Ｐ２≧Ｐ３≧Ｐ４となるように設定してもよい。なお、Ｐ１〜Ｐ４は実数であり、Ａ〜Ｃは正の整数である。

（３）メール統合機能
さいごに、図３のメール統合部４００によるメール統合機能について説明する。図６は、図３のメール統合部４００の構成例を示す図である。メール統合部４００は、チャット制御部１４は、登録制御部２２と、選択部２４と、変換部２６と、イベント管理部８０とを含む。

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

イベント管理部８０は、サーバ受信部１２を介して受け付けられたユーザからのイベントに関する指示にしたがって、サーバメモリ２０にアクセスし、イベントに関する情報を管理する。イベントに関する指示には、ユーザからのイベントに関する情報の入力や、イベント参加を促したいユーザに関する情報などが含まれる。また、イベント管理部８０は、ユーザからのイベントに関する指示にしたがって、所定の画面をユーザ端末のディスプレイのチャットインタフェース画面に表示する。以下、順に説明する。

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

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

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

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

アップロードされた連絡先情報
氏名 Ａ
携帯電話番号 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 (20)

1. チャットサービスに登録している登録ユーザ同士におけるメッセージの送受信を制御し、かつ、登録ユーザと未登録のユーザとの間におけるメッセージの送受信を制御するサーバ装置であって、
   登録ユーザのフレンドリストを管理するフレンドリスト管理部と、
   登録ユーザに対して、フレンドリストに追加すべき他のユーザを推奨するサジェスト部と、
   を備え、
   前記サジェスト部は、前記チャットサービスへの登録の有無に応じて設定された所定の条件を用いて、前記登録ユーザに推奨すべき他のユーザを決定する
   ことを特徴とするサーバ装置。
2. 前記サジェスト部によって推奨された他のユーザのユーザ情報をサジェストリストに登録するサジェストリスト管理部と、
   をさらに備え、
   前記フレンドリスト管理部は、前記サジェストリストに含まれたユーザ情報のうち、当該登録ユーザによって選択されたユーザ情報をフレンドリストに追加し、
   前記サジェストリスト管理部は、フレンドリストへの前記ユーザ情報の追加に伴って、そのユーザ情報をサジェストリストから消去する
   ことを特徴とする請求項１に記載のサーバ装置。
3. 前記サジェスト部は、前記チャットサービスに登録されていない未登録ユーザであって、前記登録ユーザが管理するユーザ情報の中にその未登録ユーザのユーザ情報が含まれている場合、その未登録ユーザを当該登録ユーザに推奨すべき他のユーザとして決定する
   ことを特徴とする請求項１または２に記載のサーバ装置。
4. 前記サジェスト部は、前記登録ユーザが管理するユーザ情報の中にその未登録ユーザのユーザ情報が含まれており、かつ、その未登録ユーザ情報に、モバイルに関する連絡先情報が含まれている場合、その未登録ユーザを当該登録ユーザに推奨すべき他のユーザとして決定する
   ことを特徴とする請求項３に記載のサーバ装置。
5. 前記サジェスト部は、未登録ユーザであった第１ユーザに対して、第１ユーザが登録ユーザになった後に推奨すべき他の既登録ユーザとして、未登録であったときにすでにフレンドリストに第１ユーザを追加している既登録ユーザを決定することを特徴とする請求項３または４に記載のサーバ装置。
6. 前記サジェスト部は、前記チャットサービスに登録されているユーザであって、かつ、そのユーザのフレンドリストに前記登録ユーザが含まれている場合に、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定する
   ことを特徴とする請求項１から５のいずれかに記載のサーバ装置。
7. 前記サジェスト部は、前記チャットサービスに登録されているユーザであって、かつ、現在もしくは過去において、前記チャットサービス上でそのユーザと前記登録ユーザとの間でお互いにメッセージを送受信したことがある場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定する
   ことを特徴とする請求項１から５のいずれかに記載のサーバ装置。
8. それぞれ特定の性質を有する複数のグループを設定するグループ設定部と、
   前記グループ設定部によって設定された複数のグループのうち、登録ユーザにより選択されたグループと、その登録ユーザとを関連づけて管理するグループ管理部と、
   をさらに備え、
   前記サジェスト部は、前記チャットサービスに登録されているユーザであって、かつ、前記グループ管理部によって管理されている同じグループにそのユーザと前記登録ユーザとが共に関連づけられている場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定する
   ことを特徴とする請求項１から５のいずれかに記載のサーバ装置。
9. 前記サジェスト部は、前記チャットサービスに登録されているユーザであって、かつ、そのユーザと前記登録ユーザのそれぞれのフレンドリストに共通のユーザが１人以上含まれている場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定する
   ことを特徴とする請求項１から５のいずれかに記載のサーバ装置。
10. 前記サジェスト部は、前記チャットサービスに登録されているユーザであって、かつ、そのユーザと前記登録ユーザとがＳＮＳ上の友達である場合、そのユーザを当該登録ユーザに推奨すべき他のユーザとして決定する
    ことを特徴とする請求項１から５のいずれかに記載のサーバ装置。
11. 前記登録ユーザからの要求にもとづいて検索する場合は当該サーバ装置に記憶されているすべてのユーザ情報を対象として、前記登録ユーザからの要求がない場合は前記登録ユーザのサジェストリストに含まれたユーザを対象として、表示対象とすべき１以上のユーザを検索する検索部と、
    前記検索部によって検索された１以上のユーザ情報の表示順序を決定する表示順序決定部と、
    前記表示順序決定部によって決定された順序で、前記検索部によって検索されたユーザのユーザ情報を登録ユーザのチャット画面上に表示する表示制御部と、
    をさらに備えることを特徴とする請求項２から１０のいずれかに記載のサーバ装置。
12. 前記表示順序決定部は、前記検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、フレンドリストに前記登録ユーザが含まれているユーザの優先順位が上位となるように、表示順序を決定する
    ことを特徴とする請求項１１に記載のサーバ装置。
13. 前記表示順序決定部は、前記検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、現在もしくは過去において、前記登録ユーザとの間でなされたメッセージの送受信の回数が多いユーザほど優先順位が上位となるように、表示順序を決定する
    ことを特徴とする請求項１１に記載のサーバ装置。
14. それぞれ特定の性質を有する複数のグループを設定するグループ設定部と、
    前記グループ設定部によって設定された複数のグループのうち、登録ユーザにより選択されたグループと、その登録ユーザとを関連づけて管理するグループ管理部と、
    をさらに備え、
    前記表示順序決定部は、前記検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、前記登録ユーザと共に関連づけられたグループの数が多いユーザほど優先順位が上位となるように、表示順序を決定する
    ことを特徴とする請求項１１に記載のサーバ装置。
15. 前記表示順序決定部は、前記検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、前記登録ユーザとの間で、お互いのフレンドリストに共通に登録されているユーザの人数が多いユーザほど優先順位が上位となるように、表示順序を決定する
    ことを特徴とする請求項１１に記載のサーバ装置。
16. チャットサービスに登録している登録ユーザ同士におけるメッセージの送受信を制御し、かつ、登録ユーザと未登録のユーザとの間におけるメッセージの送受信を制御するサーバ装置であって、
    登録ユーザのフレンドリストを管理するフレンドリスト管理部と、
    前記登録ユーザからの要求にもとづいて検索する場合は当該サーバ装置に記憶されているすべてのユーザ情報を対象として、表示対象とすべき１以上のユーザを検索する検索部と、
    前記検索部によって検索された１以上のユーザ情報の表示順序を決定する表示順序決定部と、
    前記表示順序決定部によって決定された順序で、前記検索部によって検索されたユーザのユーザ情報を登録ユーザのチャット画面上に表示する表示制御部と、を備えることを特徴とするサーバ装置。
17. 前記表示順序決定部は、前記検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、フレンドリストに前記登録ユーザが含まれているユーザの優先順位が上位となるように、表示順序を決定する
    ことを特徴とする請求項１６に記載のサーバ装置。
18. 前記表示順序決定部は、前記検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、現在もしくは過去において、前記登録ユーザとの間でなされたメッセージの送受信の回数が多いユーザほど優先順位が上位となるように、表示順序を決定することを特徴とする請求項１６に記載のサーバ装置。
19. それぞれ特定の性質を有する複数のグループを設定するグループ設定部と、
    前記グループ設定部によって設定された複数のグループのうち、登録ユーザにより選択されたグループと、その登録ユーザとを関連づけて管理するグループ管理部と、
    をさらに備え、
    前記表示順序決定部は、前記検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、前記登録ユーザと共に関連づけられたグループの数が多いユーザほど優先順位が上位となるように、表示順序を決定する
    ことを特徴とする請求項１６に記載のサーバ装置。
20. 前記表示順序決定部は、前記検索部によって検索されたユーザが複数である場合、検索された複数のユーザのうち、前記登録ユーザとの間で、お互いのフレンドリストに共通に登録されているユーザの人数が多いユーザほど優先順位が上位となるように、表示順序を決定することを特徴とする請求項１６に記載のサーバ装置。
    
    
    
    

Images