(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0014】
以下、本発明の実施形態について図面を参照して説明する。
【0015】
図1は、実施形態に係るメッセージ閲覧システム1を含む全体的な構成を示すブロック図である。
この図に示されるように、メッセージ閲覧システム1では、管理サーバ10とSNSサーバ50と複数の端末装置20−1、20−2、20−3、…とが、インターネットNa、ゲートウェイ12および移動通信網Nbを介して接続された構成となっている。
SNSサーバ50は、SNS運営者によって運営されるものであり、メッセージ閲覧システム1の外部に設けられている。このSNSサーバ50は、SNS会員(以下、単に「会員」という。)同士が交流するためのSNS(第1サービス)を提供するために、会員に関する情報や、会員から投稿されたメッセージなどを管理する。
本実施形態では、管理サーバ10は、会員のうち、後述する条件を満たした利用者に、後述する第1機能から第4機能までのサービス(第2サービス)を提供する。このため、管理サーバ10は、第1機能から第4機能までのサービスの提供に必要な情報を管理する。
なお、以下においては、会員のうち、第1機能から第4機能までのサービスの提供を受ける利用者によって操作される端末装置20−1、20−2、20−3、…について、端末装置を特定せずに一般的に説明するために、符号のうち「−(ハイフン)」以下を省略して単に「20」とする。
【0016】
端末装置20は、例えば利用者が操作する携帯電話機である。この端末装置20の詳細については後述するが、表示部211とともに、当該表示部211に重ねられたタッチパネル212を有し、利用者が表示部211の画面に対してタッチ操作等することで、必要な情報の入力や各種の指示が与えられる構成となっている。
端末装置20は、移動通信網Nbに限られず、無線LAN(Local Area Network)に接続される構成であっても良い。無線LANに接続される構成において、端末装置20は、無線基地局(アクセスポイント)およびインターネットNaを経由して、上記SNSサーバ50と管理サーバ10に接続される。また、端末装置20は、携帯電話機に限られず、タブレット型のコンピュータやPDA(Personal Digital Assistant)などでも良い。
【0017】
なお、
図1においては、SNSサーバ50をメッセージ閲覧システム1の外部としているが、内部に含めた構成であっても良い。
また、
図1では、SNSサーバ50と管理サーバ10とのそれぞれを1台で構築しているが、2台以上に分散(仮想的な1台のサーバで構成)させても良い。
一方で、SNSサーバ50と管理サーバ10とを1台で構築しても良い。
また、管理サーバ10がSNSサーバ50と端末装置20とを中継するように構成しても良い。
SNSサーバ50で管理される会員から投稿されたメッセージは、メッセージ閲覧システム1に係る端末装置20以外のインターネットNaを介して接続される外部コンピュータからもアクセス可能である。しかしながら、メッセージ閲覧システム1に係る端末装置20からアクセスした場合には、後述する第1機能から第4機能までのサービスの提供を受けることが可能である。
【0018】
図2は、管理サーバ10のハードウェア的な構成を示すブロック図である。この図に示されるように、管理サーバ10は、装置全体を制御するCPU(Central Processing Unit)101と、CPU101の主記憶部として機能するRAM(Random Access Memory)102と、ブートプログラムなどを記憶したROM(Read Only Memory)103と、ネットワークを介して通信するためのインターフェース(I/F)104と、各種のプログラムやデータを記憶する副記憶部としての記憶部105と、現在時刻の時間情報を出力するリアルタイムクロック(RTC)106と、を含む。記憶部105は、ハードディスクドライブなどであり、上述したサービスを利用者に提供するためのサービスプログラムや、後述するデータベースで各種テーブルを格納する。
【0019】
図3は、端末装置20のハードウェア的な構成を示すブロック図である。この図に示されるように、端末装置20は、CPU201と、RAM202と、ROM203と、通信部204と、記憶部205と、RTC206と、表示部211と、タッチパネル212と、位置取得部213と、を含む。
CPU201は、記憶部205に記憶された各種のプログラムを実行することで端末装置20の各部を制御する。記憶部205は、不揮発性メモリなどであり、上記サービスを提供するためのアプリケーションプログラムや、後述するアバター(利用者画像)などを格納する。このアプリケーションプログラムは、特定の配信サイトからダウンロードされて、端末装置20にインストールされたものである。通信部204は、移動通信網Nbや無線LANなど介して管理サーバ10と通信する。RTC206は、現在時刻の時間情報を出力する。
【0020】
表示部211は、例えば液晶表示装置や有機EL(Electro Luminescence)装置などの表示パネルである。タッチパネル212は、詳細については省略するが、表示部211と一体に構成され、表示された画面のタッチ位置(XY座標値)を検出し、検出したタッチ位置を示す位置情報をCPU201に出力する。CPU201は、タッチパネル212からの位置情報に基づいて、タッチ位置の移動方向や、移動速度、タッチ操作の種類等を検出する。
ここで、検出可能なタッチ操作の種類には、例えばタップ、フリック、ドラッグ、ピンチ等が含まれる。このうち、タップとは、表示画面を指で軽く叩く操作である。フリックとは、画面に表示された対象物を指で軽く払う操作である。ドラッグとは、画面に表示された対象物を指で接触させた状態で移動させる操作である。ピンチとは、表示画面に二本の指を接触させた状態で広げたり狭めたりする操作である。
【0021】
位置取得部213は、例えばGPS(Global Positioning System)によって端末装置20の位置情報を取得する。なお、この位置情報は、後述するチェックインなどによって使用される。また、位置情報としては、経度および緯度であるが、高度を加えても良い。位置情報についてはGPSに限られず、複数の無線基地局による電波強度や電波到達時間などを比較して取得しても良いし、これらとGPSを組み合わせて取得しても良い。
【0022】
実施形態に係るメッセージ閲覧システム1では、管理サーバ10において上記サービスプログラムを実行することによって、端末装置20において上記アプリケーションプログラムを実行することによって、次の第1機能から第4機能までの各機能のサービスを利用者(主体者)に提供するための機能ブロックが適宜構築される。
すなわち、第1機能では、端末装置20において主体者を含む複数人がグループ化される。このグループ化に際し、端末装置20の利用者である主体者は、グループに他の会員を登録したり、反対に登録した他の会員を削除したりして、グループを編集する。この編集の際に、会員に対応するアバターが表示部211に表示される、というサービスが主体者に提供される。
次に、第2機能では、グループの構成員に対応したアバターが、当該構成員の投稿や応答に応じた配置で表示される、というサービスが提供される。
さらに、第3機能では、各アバターが、当該構成員の投稿内容や投稿形式に応じたモーションで表示される、というサービスが提供される。
そして、第4機能では、主体者が、ある仲間の投稿に対し、アイコンのタップ操作や、利用者のアバターをタッチ操作等することによって応答したとき、当該仲間のアバターが、応答操作に応じたモーションで表示される、というサービスが提供される。自己の投稿に対して、別の仲間が応答したときに、自己に対応するアバターに、当該応答内容に応じたモーションやアイコンが付加される。
【0023】
グループは、詳細については後述するが、サービスの提供を受ける主体者と、当該主体者によって選定された会員である仲間とで構成される。このため、グループの構成員という場合には、主体者と仲間との双方が含まれる。また、グループの構成員については、主体者の編集によらずに、SNS(第1サービス)で所定の関係(例えば友達関係)にある利用者を割り当てる構成や、上記SNSでの当該利用者のうち、第1機能から第4機能までによるサービス(第2サービス)の利用者を割り当てる構成、SNSでの当該利用者のうち、所定の期間内に主体者とコミュニケーションがあった利用者を構成員として割り当てる構成も採用し得る。つまり、グループの構成員は、時間経過とともに利用者が固定的であって良いし、時間経過とともに利用者が変化しても良い。
なお、各機能のサービスの提供するための動作説明については、適宜分けて説明することにする。
【0024】
ここで、「投稿」とは、自己や他の利用者(仲間)が情報を発信することをいい、情報の発信については意識的および無意識的(自動的)の双方が含まれる。本実施形態においては説明の便宜上、投稿を次の4形式としている。すなわち、所定の文字数(例えば140字)以内で文章を発信する「つぶやき」、所定の形式で綴った内容で発信する「日記」、画像データをアップロードする「フォト」、および、位置情報で特定される場所(店などのスポット)の情報を利用者同士で共有する「チェックイン」の4形式としている。
【0025】
また、「応答」とは、ある利用者の「投稿」に対して他の利用者が何らかの形で返信することをいう。すなわち、「応答」は、必ず元となる「投稿」を前提としている。また、1つの「投稿」に対して、1つ以上の「応答」がある場合もあるが、まったく「応答」がない場合もある。
ここで、本実施形態においては説明の便宜上、「応答」を次の4形式としている。すなわち、投稿に対する驚きを示す「クラッカー」、投稿に対する感嘆を示す「へぇ」、投稿に対する賛同、賞賛等を示す「イイネ」、および、投稿に対してテキストで返信する「コメント」の4形式としている。
なお、「投稿」および「応答」については、例えば「転送」等のこれらの以外の形式が加わっても良いのはもちろんである。
【0026】
ある利用者が「投稿」したとき、その「投稿」は、投稿した利用者の会員IDと投稿の形式に応じた投稿ID(つぶやきID等)と内容(テキスト)と発信日時(日付および時間)とに対応付けられてSNSサーバ50の記憶部に記憶される。
また、「応答」については、その「応答」の元となる「投稿」の投稿IDと投稿した会員IDとに紐付けられるとともに、応答した利用者の会員IDと当該応答の形式に応じた投稿IDと応答内容と発信日時とに対応付けられてSNSサーバ50の記憶部または管理サーバ10の記憶部105に記憶される。
詳細には、「投稿」と、「応答」のうち「コメント」とは、SNSサーバ50の記憶部に投稿IDと関連付けて記憶される。一方、「応答」のうち「コメント」以外については、管理サーバ10の記憶部105に記憶される。つまり、SNSサーバ50の記憶部に記憶される「投稿」と「コメント」とは、インターネットNaを介して接続される外部コンピュータからもアクセス可能である。一方、「応答」のうち「コメント」以外については、本メッセージ閲覧システム1に係る端末装置20、すなわち、会員のうち、第1機能から第4機能までのサービスの提供を受ける利用者によって操作される端末装置20のみからしかアクセスできない。
なお、「投稿」および「応答」が、あるグループの構成員に対して発信される場合には、当該「投稿」および「投稿」は、当該グループを特定する情報(グループID)に対応付けられる。また、SNSサーバ50の記憶部に記憶される「投稿」と、「応答」のうち「コメント」とを対応付けた記憶内容や、管理サーバ10の記憶部105に記憶される「コメント」以外によって投稿・応答履歴が形成される。このような投稿・応答履歴を用いた画面の一例については、後述することにする。
【0027】
<第1機能>
まず、実施形態に係るメッセージ閲覧システム1において、上記第1機能のサービスを提供する際の動作について説明する。
【0028】
図4は、メッセージ閲覧システム1において第1機能のサービスを提供するために構築される機能ブロックを示す図である。
この図に示されるように、管理サーバ10側では、CPU101がサービスプログラムを実行することによって受付部151および管理部152が構築される。一方、端末装置20側では、CPU201がアプリケーションプログラムを実行することによって、入力指示部251、描画部252および表示制御部253が構築される。詳細には、主体者が主に上記第1機能によるサービスの提供を受けるための操作をしたときに、管理サーバ10と端末装置20とで
図4に示される機能ブロックが構築される。
なお、この図では、インターネットNa、ゲートウェイ12および移動通信網Nbについては、データを単に中継するのみであるので、図示を省略している。
【0029】
図において、入力指示部251は、タッチパネル212へのタッチ操作等によって入力された指示やテキストなどの操作情報を出力する。受付部151は、入力指示部251による操作情報を、端末装置20から受け付ける。管理部152は、入力指示部251による情報に応じて記憶部105の記憶内容を管理したり、各部を制御したりする。
なお、
図4においては、説明の便宜上、ある1台の端末装置20に着目して、当該端末装置20と管理サーバ10との情報やメッセージなどの授受について図示しているに過ぎない。管理サーバ10の受付部151、管理部152は、実際には、複数の端末装置20から情報を受け付け(あるいは、受信し)、逆に、管理部152は、複数の端末装置20に情報を送信する。
【0030】
第1機能の実行に際し、記憶部105において、
図5に示されるようなユーザ登録テーブルや、
図6に示されるようなグループテーブルが管理される。
このうち、ユーザ登録テーブルは、SNSサーバ50でSNSに登録されている会員のうち、第1機能から第4機能までのサービスの提供を受ける利用者を、
図5に示されるように、複数の英数字で一意に識別する会員IDと、例えば通し番号で識別する利用者IDとを対応付けて記憶するテーブルである。本実施形態において、SNSによって提供されている既存のサービスを利用している会員の全てが、第1機能から第4機能までのサービスを利用しているとは限らないため、第1機能から第4機能までのサービスを提供するために利用者IDを付与して利用者を特定することにしている。
これにより、会員IDが付与された会員であっても、ユーザ登録テーブルにおいて利用者IDが登録されていなければ、第1機能から第4機能までのサービスの提供を受けることができる利用者ではない、逆にいえば、ユーザ登録テーブルにおいて会員IDと利用者IDとが対応付けられていれば、当該会員は第1機能から第4機能までのサービスを提供することができる利用者である、と管理部152が判別することができる。
【0031】
本実施形態において利用者は、1または複数のグループを設定することができる。1つのグループは、自己を主体者とし、他の9人以下の利用者を仲間としたメンバーで構成され、いずれのメンバーも、このSNSの会員であることを条件としている。このようなグループを管理するのが、グループテーブルである。
グループテーブルでは、
図6に示されるように、主体者に対してグループIDで識別されるグループが1または複数登録される。
各グループには、グループ名称が付与されるとともに、主体者を中心とした仲間aから仲間iまでにわたって利用者のSNSの会員IDが設定される。SNS上で仲間関係(友達関係)が構築されている会員IDについては、管理部152がSNSサーバ50に問合せることで取得される。仲間は、SNSの会員ではあるものの、第1機能から第4機能までのサービスを利用している利用者とは限らないため、会員IDで管理することになっている。
したがって、主体者については、SNSの会員であって、第1機能から第4機能までのサービスの提供を受けるかことができる利用者であるが、主体者が設定したグループを構成する仲間については、当該会員であるものの、第1機能から第4機能までのサービスの提供を受けることができない者、すなわち非利用者である場合がある。
【0032】
なお、会員IDは、例えば複数の英数字等から構成されるが、
図6においては簡易的に「?????」と表記している。また、グループの構成員が9人設定されないときには、仲間aから仲間iまでのうち、未設定の仲間の会員IDが空文字となる、あるいは、未設定である旨の情報が格納される。
図6の例において、矢印で示されるグループは、利用者IDが「1」である利用者が1番目に設定したグループであり、「チームA」というグループ名称が付与されて仲間aから仲間hまで設定されて、仲間iが未設定の状態である。
【0033】
説明を
図4に戻すと、表示制御部253は、主体者となる利用者の端末装置20の表示部211に対し、指定されたグループの構成員に対応したアバターの配置情報、すなわち、どのアバターを、どの地点に配置させるのかを示す情報を出力する。また、表示制御部253は、入力指示部251からの操作情報に応じて、表示部211の表示内容を規定する制御情報も出力する。
【0034】
一方、端末装置20の記憶部205の一部の記憶領域には、画像記憶部261が割り当てられる。ここで、画像記憶部261は、当該端末装置20の利用者によってグループの構成員として登録された仲間および自己のアバターの画像情報を記憶する。
画像記憶部261には、例えば次のようにして、仲間および自己のアバターの画像情報が記憶される。詳細には、第1機能から第4機能までのサービスの提供を受けるため利用者として登録されるときに、当該利用者の分身としてのアバターが当該利用者によって作成、選択などされて、当該アバターの画像情報が利用者IDに対応付けられて記憶部105の画像記憶部121に記憶される。このため、第1機能から第4機能までのサービスの提供を受けることのできる利用者になるためには、自身を示すアバターの登録が必要となる。
ここで、主体者によって、あるグループに、ある仲間が登録されたときに、管理部152は、第1に、ユーザ登録テーブルを参照して、当該仲間の会員IDに利用者IDが付与されているか否かを判別する。管理部152は、第2に、当該仲間の会員IDに利用者IDが付与されていれば、当該利用者IDに対応したアバターの画像情報を、当該利用者IDとともに当該主体者の端末装置20の画像記憶部261に転送する。一方、管理部152は、第3に、当該仲間の会員IDに利用者IDが付与されていなければ、例えば黒アバター(規定画像)の画像情報を、当該会員IDとともに当該端末装置20の画像記憶部261に転送する。これにより、主体者の端末装置20においては、画像記憶部261に、登録した仲間に対応したアバターの画像情報が利用者ID(または会員ID)に対応付けられて記憶されることになる。
なお、自己のアバターについては、登録時に記憶部105(画像記憶部121)に記憶されたアバターの画像情報を、管理部151が、端末装置20に転送することによって、画像記憶部261に記憶される。
【0035】
描画部252は、画像記憶部261に記憶されたアバターの画像情報を読み出すとともに、アバターの配置情報で示される地点に当該アバターを描画するように、表示部211に対応したフレームバッファにレンダリングする。なお、アバターの描画については後述するようにグリッドを単位として実行される場合がある。
表示部211は、フレームバッファにレンダリングされた描画情報にしたがって画像を表示する。
【0036】
上述したように
図6において、矢印で示されるグループには、仲間aから仲間hまで設定されて、仲間iが未設定の状態である。この状態において、利用者IDが「1」である主体者と仲間a〜仲間hとに対応するアバターは、それぞれ
図7に示されるものとなっていると仮定する。そして、未設定の仲間iとして、
図7に示されるようなアバターおよびその利用者を登録する場合について説明する。
【0037】
まず、
図8に示されるように、表示部211による表示画面は、領域B1と領域B2とに分かれている。領域B1では、主体者のアバターを中心とするサークルに仲間a〜hのアバターが等間隔で配置している。なお、この段階において仲間iはグループに未設定であるので、仲間iに相当する地点にはアバターが配置していない。
一方、領域B2には、グループに登録する仲間の候補が、左右に並べられて配置している。なお、図において領域B2には三体のアバターのみが表示されているが、左右へのフリック操作によって、他のアバターを出現させて候補にすることができる。また、三体のうち、左右のアバターは、すでに仲間h、eとして登録されているので、重複登録を避けるための登録不可を示すマークが付与されている。
【0038】
このような画面は、利用者IDが「1」である主体者が操作する端末装置20において、グループIDが「1」であるグループが入力指示部251によって選択されている状態が前提であり、次のようにして表示部211に表示される。
詳細には、領域B1については、表示制御部253は、管理部152に対し、グループIDが「1」であるグループの仲間a〜iについての情報を要求する。一方、管理部152は、グループテーブルを参照して、当該グループを構成する仲間a〜iの情報を取得する。これにより、管理部152は、仲間a〜hについては会員IDを、仲間iについては未設定である旨を、それぞれ取得する。次に、管理部152は、取得した会員IDに利用者IDが対応付けられているか否かについて、ユーザ登録テーブルを参照して判別する。管理部152は、取得した会員IDに利用者IDが対応付けられていれば、その利用者IDを、利用者IDが対応付けられていなければ、取得した会員IDを、それぞれ表示制御部253に返信する。なお、この例では、仲間a〜hの会員IDは、すべて利用者IDに対応付けられている。
【0039】
表示制御部253は、返信された仲間a〜hの利用者IDと、仲間iが未設定である旨の情報とを、描画部252に供給する。描画部252は、当該利用者IDに対応するアバターの画像情報を、自己のアバターの画像情報とともに画像記憶部261から読み出し、領域B1において仲間に対応する地点にアバターを描画する。これによって、領域B1では、主体者のアバターを中心とするサークルに仲間a〜hのアバターが配置されて表示されることになる。
なお、グループ編集の第1機能において仲間に対応する地点は、
図8に示されるように、主体者を中心とするサークルであって、手前側を仲間iに対応する地点とし、反時計回りに、順次、仲間h、g、f、e、d、c、b、aに対応する地点として定められる。また、後述するように、第2機能以降において、仲間に対応する地点は、各種条件によって変更される場合がある。
【0040】
次に、領域B2については、仲間として追加で登録することができる候補が提示される。候補になり得る者は、主体者に対しSNSにおいて所定の関係、例えば仲間関係を有する者である。このため、管理部152は、選択されたグループの仲間についての情報が要求されたときに、当該主体者と仲間関係にある会員IDをSNSサーバ50に問い合わせて所定人数分取得する。管理部152は、取得した会員IDにユーザ登録テーブルにおいて利用者IDが付与されていれば、当該利用者IDとアバターの画像情報とを表示制御部253に供給し、利用者IDが付与されていなければ、当該取得した会員IDと黒アバターの画像情報とを表示制御部253に供給する。表示制御部253は、供給された利用者のアバターの画像情報(または非利用者の黒アバター情報)を、描画部252に転送する。描画部252は、供給されたアバターの画像情報のうち、領域B2における3地点にアバターを描画する。これによって、領域B2では、登録の候補となる主体者のアバターが表示されることになる。なお、表示制御部253は、管理部151から供給されたアバターがすでに領域B1に表示されていれば、登録不可のマークを当該アバターに重ねて描画するように、描画部252に指示する。また、3地点に対してフリック操作がなされたら、他の候補者となるアバターを表示させる。これによって、領域B2では、仲間として追加で登録することができる候補のアバターが表示されることになる。
【0041】
さて、
図8に示される画面において、領域B2に表示されているアバターのうち、登録不可のマークが付されていないアバターをグループの仲間として登録する場合、主体者は、図において破線の矢印に沿って、当該アバターを、領域B1におけるサークルにおいてアバターが配置していない場所までドラッグする。
【0042】
ドラッグすると、画面が
図9に示されるようなものとなる。すなわち、領域B1において仲間iに対応するアバター、すなわちドラッグされたアバターが配置することになる。
なお、このようにアバターが登録されると、この操作情報が受付部151を介して管理部152に通知される。管理部152は、グループテーブルにおいて、当該グループの仲間iに、当該アバターに対応する会員IDを登録する。
また、領域B2において、元のアバターには、仲間iへの登録に伴って登録不可を示すマークが付与される。
【0043】
ところで、グループテーブルにおいて、仲間は、上述した利用者IDではなく、会員IDで登録される。このため、SNSの会員であるが、第1機能から第4機能までのサービスの提供を受けることができない者が、主体者によってグループに登録される場合がある。詳細には、あるグループに仲間が主体者によって追加される場合、上述したように当該主体者と仲間関係を有する会員であれば、第1機能から第4機能までの第2サービスの提供を受けることができる利用者でなくても、追加する仲間の候補者として提示される。このため、会員であるが利用者ではない者が、グループの仲間として登録される場合がある。
この場合、当該仲間として登録された者には、アバターが登録(対応付けられて)いないので、予め定められた規定画像としての黒アバターが表示される。
【0044】
図10は、例えば仲間dに対応する会員が第1機能から第4機能までのサービスの提供を受けることができない者が、グループに登録されたときの表示例である。なお、規定画像の例としては、黒アバターに限られず、他の色や種々の模様で塗り潰したアバターなどが挙げられる。また、特に図示しないが、上述したように、主体者と仲間関係にある会員であって、利用者でない者がグループに追加する候補者として提示される場合には、領域B2に、当該者に対応して黒アバターが表示される。
【0045】
ここまでは、グループへの登録についての説明であったが、例えば削除については登録とは逆の動作で実行される。すなわち、領域B1に表示されたアバターが、領域B2までドラッグされる。
なお、このようにアバターが削除されると、この操作情報が入力指示部251から受付部151を介して管理部152に供給されて、管理部152は、グループテーブルにおける当該グループから、ドラッグされたアバターに対応する会員IDを削除する。
【0046】
さて、第1機能では、
図8乃至
図10に示された画面のように、主体者によって設定されたグループの構成員に対応したアバターが表示されるが、実際には、後述する第2機能から第4機能までのように、投稿や応答に応じてアバターの配置地点や向きが変更されたり、アバターにモーションが付与されて表示されたりする。また、第4機能においては、アバターを選定することにより、一対一の投稿、応答でコミュニケーションすることができる。ただし、黒アバターで表示された会員については、第1機能から第4機能までのサービスの提供を受けることができない者であるので、主体者は、当該会員に対して、これらのサービスを経由して主体者とコミュニケーションすることができない。
このため、主体者が、黒アバターで表示されている会員に対して、第1機能から第4機能までのサービスを経由してコミュニケーションを図ろうとしたときに、次のような処理のいずれかが実行される。このような処理としては、第1に、黒アバターで表示されている会員が非利用者であるために、第1機能から第4機能までのサービスを経由したコミュニケーションが不可能である旨の画面を提示する処理(第1処理)、第2に、第1機能から第4機能までのサービスを経由してコミュニケーションするための操作を無効化する処理(第2処理)、および、第3に、当該会員に対して第1機能から第4機能までのサービスの提供を受けるための手続(登録)を促す処理(第3処理)、が挙げられる。
【0047】
第1処理としては、主体者が黒アバターの会員に対して第1機能から第4機能までのサービスを経由してコミュニケーションするための操作、例えば表示部211に表示された黒アバターをタップする操作をしたとき、その操作を示す操作情報を入力指示部251が表示制御部253に供給する。このときに、表示制御部253は、描画部252に対して、次のような警告画面を提示するように指示する。これにより、表示部211では、例えば
図11(a)に示されるように、タップ操作した黒アバターの会員が非利用者である旨とともに、第1機能から第4機能までのサービスを経由したコミュニケーションが不可能である旨がポップアップで表示される。
【0048】
第2処理としては、主体者が例えば黒アバターをタップする操作をしたときに、その操作情報が入力指示部251から表示制御部253に供給される点は、第1処理と同様であるが、表示制御部252は、当該操作が無効であると判別して、コミュニケーションするための処理に移行しない。このため、
図11(b)に示されるように、表示部211において、主体者が黒アバターをタップ操作しても何ら表示が変更されることはない。
【0049】
第3の処理としては、主体者が例えば黒アバターをタップする操作をしたときに、その操作情報が入力指示部251から供給されると、表示制御部253は、描画部252に対して、次のような内容を表示するように指示する。すなわち、表示部211では、例えば
図12(a)に示されるように、黒アバターに対応する仲間を、第1機能から第4機能までのサービスに招待するか否かを問い合わせる画面がポップアップで表示される。問い合わせ画面では、例えば招待することを指定するソフトウェアボタン291と、招待しないことを指定するソフトウェアボタン292とが表示される。ここで、ソフトウェアボタン292が操作されたとき、この問い合わせ画面の表示が終了する一方、ソフトウェアボタン291が操作されたとき、その操作情報を入力指示部251から受付部151を介して受け取った管理部152が、SNSサーバ50に対し、黒アバターに対応する会員の端末装置に、当該招待を通知するように指示する。この指示により、SNSサーバ50は、当該会員(この段階では非利用者)の端末装置に、例えば
図12(b)に示されるような招待の通知画面を表示させる。
この通知画面では、例えば招待されたことを示すメッセージとともに、当該招待を承認することを指定するソフトウェアボタン293と、拒否することを指定するソフトウェアボタン294とが表示される。ここで、ソフトウェアボタン294が操作されたとき、この通知画面の表示が終了する一方、ソフトウェアボタン293が操作されたとき、第1機能から第4機能までのサービスの提供を受けることができる利用者として手続きをするためのサイトへ移行する。当該会員は、当該サイトにおいて自己を示すアバターなどを設定することによって、利用者として登録されることになる。
【0050】
以上説明してきたように、第1機能によるサービスを提供するにあたって、端末装置20は、第1サービス(SNS)において、自装置を利用する第1利用者(主体者)と他装置を利用する複数の第2利用者とが登録されたグループで送信されたメッセージを、当該第1サービス(SNS)に対応するサービス装置(SNSサーバ50)から取得して表示部211に表示させる。そして、当該端末装置20は、利用者画像(例えばアバター)を登録している利用者に対して、第1サービス(SNS)とは異なる第2サービス(上記第1機能または第2機能から第4機能までのいずれか若しくは全部のサービス)の提供を受けるサービス提供部(描画部252および表示部211)と、複数の第2利用者のうち、一部または全部である特定利用者(利用者または非利用者)のそれぞれに対応した利用者画像と、当該第1利用者とのそれぞれに対応した利用者画像を表示部211に表示させる表示制御部253を備えている。
そして、表示制御部253は、特定利用者のうち、第2サービスが提供されない者(非利用者)の利用者画像として所定の規定画像(例えば黒アバター)を表示部211に表示させる。これにより、第1利用者(主体者)は、第1サービスを基本として、さらに別の第2サービスが提供される場合であっても、第2サービスの提供を受けている利用者と、第2サービスの提供を受けていない非利用者を容易に区別することができるようになる。ここで、第2サービスとは、利用者画像(例えばアバター)を利用したサービスであって、例えば、掲示板やチャットのようなコミュニティサービスやゲームなどである。
【0051】
なお、特定利用者は、複数の利用者のうち、所定の選定条件を満たす一部の利用者であっても良い。所定の選定条件としては、例えば、複数の利用者のうち、最近に投稿/応答した者の上位者であることや、投稿数/応答数が多い上位者であることなどのように、時間経過とともに特定利用者が変化する性質のものであっても良いし、複数の利用者のうち、いずれかの利用者によって予め選択された者などのように、時間経過に対して特定利用者が変化しない性質のものであっても良い。
【0052】
また、サービス提供部は、特定利用者に対応した利用者画像のうち、規定画像(例えば黒アバター)を除外した利用者画像(例えばアバター)が選択されたときに、選択された利用者画像に対応する特定利用者と交流する第2サービスを提供し、特定利用者に対応した規定画像が選択されたとき、選択された特定利用者と交流する第2サービスを提供しない構成が好ましい。また、表示制御部253は、規定画像が選択されたとき、表示部211に、第2サービスを提供できない旨の画面を表示させても良いし、選択を無効としても良いし、選択された規定画像に対応する特定利用者を第2サービスに招待するか否かの確認画面を表示させても良い。
【0053】
第1機能においては、次のような応用例・変形例が可能である。
例えば
図4では、描画部252および表示制御部253について端末装置20側に設けた構成を例示したが、
図13に示すように、管理サーバ10側に設けた構成としても良い。この構成では、例えば管理サーバ10側の描画部252は、画像記憶部121に記憶されたアバターの画像情報を、管理部152を介して読み出すとともに、アバターの配置情報で示される地点に当該アバターを配置したウェブ画面を作成して、端末装置20に送信する一方、端末装置20は、ブラウザによって当該ウェブ画面を表示する。
この構成によれば、端末装置20側でアバターの画像情報を記憶する必要がないし、アバターの描画処理も不要となるので、端末装置20側での負担を軽減することができる。
【0054】
なお、
図4において、管理サーバ10側にユーザ登録テーブル、グループテーブルおよび画像記憶部121が構築され、端末装置20側に画像記憶部261が構築されたが、これらのテーブルや記憶部については、メッセージ閲覧システム1において管理サーバ10や端末装置20からアクセス可能であれば、管理サーバ10や端末装置20以外の外部サーバに構築されても良い。
【0055】
<第2機能>
次に、メッセージ閲覧システム1において、上記第2機能のサービスを提供する際の動作について説明する。
【0056】
図14は、メッセージ閲覧システム1において第2機能のサービスを提供するために構築される機能ブロックを示す図である。
この図に示されるように、端末装置20側においては、第1機能のサービスを提供する際の機能ブロック(
図4参照)に対して割当部254、位置決定部255および位置変更部256が加わるとともに、管理サーバ10側における記憶部105では、ユーザ登録テーブル、グループテーブルに加えて、親密度テーブルが管理される。
【0057】
親密度テーブルは、
図15に示されるように、基準利用者からみた対象利用者への親密性の大きさを示す値(「親密度」と称する)を記憶するテーブルである。なお、本実施形態において親密度を、基準利用者からみた対象利用者への値としているので、方向性も問題となる。すなわち、利用者A、B同士の親密度は、利用者Aを基準利用者とし利用者Bを対象利用者としてみたときの親密度と、利用者Bを基準利用者とし利用者Aを対象利用者としてみたときの親密度とは、必ずしも一致しないことになる。
もっとも、方向性を問題とせずに、両者の和の平均値を親密度として扱っても良い。
【0058】
また、本実施形態において、親密度は、例えば「0」から「32」までの整数値である。この親密度は、例えば
図16に示されるようなアップ条件(第1条件)を満たしたときに増加し、ダウン条件(第2条件)を満たしたときに減少する。なお、親密度テーブルでは、親密度が最後に変化したときの原因の発生時間を示す最終更新時間の時間情報が対応付けられて記憶される。
【0059】
図17は、親密度テーブルの更新処理を示すフローチャートである。
まず、受付部151は、いずれかの端末装置20において、前回処理時から現時点までに利用者のいずれかによる応答があったか否かを判別する(ステップSa11)。応答があれば(ステップSa11の判別結果が「Yes」であれば)、受付部151は、当該応答の内容、形式を管理部152に通知し、管理部152は、親密度テーブルにおいて、当該応答の内容、形式に応じて基準利用者と対象利用者とを特定し、当該基準利用者からみた当該対象利用者への親密度を、当該応答の態様に応じて値だけアップさせる(ステップSa12)。
【0060】
例えば、ある利用者(基準利用者)の投稿に対して、別の利用者(対象利用者)がコメントで応答したとき、基準利用者からみた対象利用者への親密度が「5」だけアップされる(
図16の(1)参照)。
また例えば、ある利用者(基準利用者)の投稿に対して、別の利用者(対象利用者)がコメント以外の形式(クラッカー、へぇ、イイネ)で応答したとき、基準利用者からみた対象利用者への親密度が「3」だけアップされる(
図16の(2)参照)。
そのほかにも、
図16の(3)から(5)までの応答があったときにも同様に、親密度がアップされる。
基準利用者による投稿に対して対象利用者が応答してくれたとき、当該基準利用者からすれば当該対象利用者に一種の親近感を発生させる事象となるので、本実施形態では、基準利用者からみた対象利用者への親密度をアップさせる構成となっている。
一方、対象利用者による応答がなければ(ステップSa11の判別結果が「No」であれば)、ステップSa12におけるテーブルの更新がスキップされる。
【0061】
続いて、管理部152は、RTC106の時間情報で示される現在時刻が27時(午前3時)を過ぎたか否かを判別する(ステップSa13)。この判別結果が「Yes」であれば、管理部152は、すべての親密度を一律に「1」だけダウンさせる(ステップSa14)。これにより、毎日27時に、すべての利用者に対する親密度が「1」だけダウンされる(
図16の(6)参照)。
一方、現在時刻が27時前または27時を過ぎて一律ダウン処理が終了した場合(ステップSa13の判別結果が「No」である場合)、ステップSa14におけるテーブルの更新がスキップされる。
【0062】
そして、管理部152は、投稿・応答履歴を参照し、ある利用者による投稿の日時から現在時刻に至るまでに一定期間(例えば5日)経過し、かつ、当該投稿に対して、仲間が応答しなかったものがあるか否かを判別する(ステップSa15)。
なお、投稿と、応答のうち「コメント」についてはSNSサーバ50に記憶され、応答のうち「コメント」以外については管理サーバ10に記憶されているので、管理部152は、SNSサーバ50と、自己の記憶部105との双方にアクセスして、投稿・応答履歴を取得することになる。
ステップSa15の判別結果が「Yes」であれば、管理部152は、当該仲間である者(主体者)からみた当該投稿をした者(対象利用者)に対する親密度を「3」だけダウンさせる(ステップSa16)。これにより、ある者の投稿に対して仲間が一定期間応答しなかったときに、当該仲間からみた投稿者への親密度がダウンされる(
図16の(7)参照)。
【0063】
ステップSa15の判別結果が「No」である場合に、または、ステップSa16の処理後に、処理手順がステップSa11に戻る。これにより、ステップSa11〜Sa16が繰り返し実行されるので、応答や時間経過に応じて親密度テーブルが更新されることになる。
【0064】
次に、親密度テーブルの内容に応じてアバターを配置させるためのアバター配置処理について説明する。
【0065】
図18は、アバター配置処理を示すフローチャートである。
まず、第2機能によるサービスを所望する主体者は、端末装置20における入力指示部251に対するタッチ操作等によって当該サービスの提供を受けたい旨を指示するとともに、表示させたいグループを選択する。入力指示部251は、選択されたグループのグループIDを主体者の利用者IDとともに出力し、受付部151は、当該利用者IDおよび当該グループIDの情報を管理部152に通知する(ステップSb11)。
【0066】
第1に、管理部152は、当該利用者IDと当該グループIDで特定されるグループの構成員のうち、主体者を除く仲間の会員IDを、グループテーブルを参照して特定する。第2に、管理部152は、取得した会員IDをSNSサーバ50へ通知し、当該グループの構成員による投稿をSNSサーバ50から取得する。第3に、管理部152は、取得した投稿を端末装置20の割当部254へ通知する。第4に、割当部254は、通知された投稿に含まれる発信日時から、当該グループに含まれる仲間全員分の最終投稿時間を取得する(ステップSb12)。
なお、ここでいう最終投稿時間とは、仲間が最後に投稿した時間をいう。
【0067】
割当部254は、グループの仲間に対応したアバターを、最終投稿時間が新しい順番で、予め定められた規則にしたがって基準位置に割り当て、この割当結果を位置決定部255に通知する(ステップSb13)。
本実施形態において、グループの利用者に対応したアバターの基準位置については、平面視したときに主体者を中心にした仮想円であって、互いに一定距離を保った地点に配置させる状態が基本であり、この基本配置の状態から投稿、応答や親密度に応じて表示位置を変更する構成となっている。なお、平面視の状態を表示部211に表示させると、立体感に乏しくなるので、本実施形態では、後述する例のように配置を俯瞰状態で表示することにしている。ただし、俯瞰状態では距離感を正しく表すことができない場合があるので、配置および距離については平面視した状態で説明することにする。
【0068】
図19は、基本配置を説明するための平面図である。
この図において、C0は、グループの構成員に対応するアバターを配置する際に基準となる地点である。地点C0を中心とした円周Dと、地点C0からみて6時の方向に延在する直線との交点が地点C9である。地点C9から時計回りで順に地点C8、C7、C6、…、C2、C1が等間隔で配置している。換言すれば、地点C1〜C9は、地点C0を中心として40度の角度ずつ順次回転させた9本の放射状直線と円周Dとの各交点である。
【0069】
割当部254は、地点C0に対して主体者のアバターを割り当て、地点C1〜C9に対して、仲間のアバターを、最終投稿時間の順序で
図20に示されるような規則で割り当てる。本実施形態において、このような規則で割り当てている理由は次の通りである。すなわち、最終投稿時間が比較的新しい仲間は、活発に投稿する可能性があり、このような仲間のアバターを円周Dにおいて順番に割り当てると、見難い表示となってしまうので、これを避けるためである。端的にいえば、活発に投稿する可能性のある仲間のアバターを分散させることよって、表示の見易さを確保するためである。
また、地点C0〜C9は、それぞれに割り当てられたアバターを表示する際の基準となる。このため以下においては、地点C0〜C9は、それぞれに割り当てられたアバターの基準位置ということになる。
【0070】
ここで、現在時刻からみて最終投稿時間が例えば三日以上経過している仲間が存在する場合、割当部254は、その仲間に対応するアバターについては、投稿時間が新しい仲間のアバターを割り当てた後に残っている地点に任意の規則で(例えばランダムに)割り当てる。
したがって、最終投稿時間が三日以上経過している仲間のアバターについては、投稿時間の順にしたがった割当の対象から除外されることになる。
【0071】
なお、アバターを基準位置に割り当てる判断根拠(投稿の更新日)としては、最終投稿時間ではなく、次のようなものを採用しても良い。例えば、ある利用者が投稿したときに、その投稿に対して、その利用者(投稿者)自身による1以上の応答があったときに、その利用者自身による応答のうち、最終の応答時間を、その利用者の判断根拠としても良い。
また例えば、ある利用者が投稿したときに、その投稿に対して、他の利用者による1以上の応答があったときに、その応答のうち、最終の応答時間を、その利用者の判断根拠としても良い。
【0072】
説明を
図18のフローチャートに戻すと、位置決定部255は、主体者に対応するアバターの立ち位置を基準位置C0に決定するとともに、グループの仲間に対応するアバターの立ち位置を、割当部254によって割り当てられた基準位置に仮決定する(ステップSb14)。
これにより、位置決定部255では、例えば
図24に示されるような一次配置が決定される。なお、
図24の一次配置は、仲間a〜iにそれぞれ
図7に示されるようなアバターが対応している場合であって、投稿順が、最新のものから仲間c、d、h、e、g、b、a、f、iである場合であって、
図20に示した規則にしたがって基準位置C1〜C9を割り当てた場合の例である。
【0073】
ここで、アバターの立ち位置の決定について詳述する。端末装置20における画像記憶部261から読み出されるアバターの画像情報は、上述したように、管理サーバ10における記憶部105から転送されたものである。このアバターには、重心がかかるような「合わせ位置」とともに、アバターの外形枠が、表示部211における表示グリッドを単位として規定されている。仲間eに対応するアバターでいえば、
図23(a)で示される通りである。
ここで、表示グリッドとは、
図23(b)において「+」字で示されるような格子点であって、表示部211において、複数ピクセルおきに縦および横方向に仮想的に配列したものである。
位置決定部255は、表示グリッドのうち、基準位置に対応するピクセルに最も近いものに「合わせ位置」が一致するようにアバターの立ち位置を決定する。仲間eに対応するアバターでいえば、
図23(c)で示されるように立ち位置を決定する。後述する位置変更部256についても、合わせ位置をグリッドに一致させてアバターを描画したときの状態をシミュレートした上で、アバターの立ち位置を変更する。
【0074】
なお、ステップSb14の一次配置については、本実施形態では、アバターの立ち位置を決定するだけで、一次配置された状態のアバターが表示部211に表示されることはないが、後述するように一次配置された状態のアバターを表示しても良い。
【0075】
この後、管理部152は、親密度テーブルを参照して、当該グループの構成員をそれぞれ基準利用者とするとともに他の構成員を対象利用者とした親密度を読み出して、位置決定部255に供給する(ステップSb15)。ここで、読み出される親密度は、主体者からみた仲間への親密度(9通り)、各仲間からみた主体者への親密度(9通り)、および、ある仲間からみた別の仲間への親密度(72通り)の計90通りである。
【0076】
次に、位置決定部255は、主体者および仲間に対応するアバターの立ち位置を、それぞれの基準位置から、親密度の対象利用者に対応するアバターの基準位置に向かう方向に、当該対象利用者への親密度に応じた分だけ移動させた地点に決定する(ステップSb16)。なお、ステップSb14の位置決定では、投稿の順序で基準位置に割り当てたに過ぎないので、仮決定というニュアンスがあるのに対し、ステップSb16の位置決定では、さらに親密度を考慮しているので、本決定というニュアンスがある。
【0077】
図21は、親密度に応じた立ち位置の移動を示す平面図である。
この図において、基準範囲Ar0は、基準位置C0を中心とした円の内側領域である。基準範囲Ar1〜Ar9の各々も同様に、それぞれ基準位置C1〜C9を中心とした円の内側領域である。なお、基準範囲Ar0の半径は、基準範囲Ar1〜Ar9の各半径よりも大きいが、この大小関係については任意である。
【0078】
例えば、基準位置C9に割り当てられた仲間と基準位置C2に割り当てられた仲間とにおいて、互いに投稿・応答が繰り返される場合、互いの親密度がアップする。
このため、図に示されるように、位置決定部255は、基準位置C9に割り当てられた仲間(基準利用者)に対応するアバターについて、当該基準位置C9から基準位置C2に向かって、基準位置C2に割り当てられた仲間(対象利用者)への親密度の大きさに応じた距離の立ち位置Ca9に移動させる。
【0079】
同様に、位置決定部255は、基準位置C2に割り当てられた仲間(基準利用者)に対応するアバターについても、当該基準位置C2から基準位置C9に向かって、基準位置C9に割り当てられた仲間(対象利用者)への親密度の大きさに応じた距離の立ち位置Ca2に移動させる。なお、この例では、基準位置C2の仲間からみた基準位置C9の仲間への親密度が、基準位置C9の仲間からみた基準位置C2の仲間への親密度よりも大きい場合を示している。
【0080】
また例えば、基準位置C4の仲間と基準位置C5の仲間とにおいて、互いに投稿・応答が繰り返される場合、互いの親密度がアップするので、位置決定部255は、基準位置C4の仲間に対応するアバターについて、当該基準位置C4から基準位置C5に向かって、基準位置C5の仲間への親密度の大きさに応じた距離の立ち位置Ca4に移動させ、基準位置C5の仲間に対応するアバターについても、当該基準位置C5から基準位置C4に向かって、基準位置C4の仲間への親密度の大きさに応じた距離の立ち位置Ca5に移動させる。
【0081】
このように位置決定部255は、各主体者および仲間に対応するアバターの立ち位置を親密度に応じた位置に本決定する(二次配置)。本実施形態では、一次配置と同様に二次配置された状態のアバターが表示部211に表示されることはないが、後述するように二次配置された状態のアバターを表示しても良い。仮に、二次配置された状態のアバターを表示するとした場合の画面例は、
図25に示される通りであり、
図21で示した位置の例に対応している。
【0082】
親密度の最大値「32」に対応する移動量は、基準範囲Ar1〜Ar9の半径に等しい。このため、親密度に応じてアバターの立ち位置が基準位置から移動しても、基準範囲の外側に脱することはない。
また、ここでの説明は、基準利用者からみた1人の対象利用者への親密度で説明しているが、実際には、複数の対象利用者への親密度が発生している場合もある。複数の対象利用者への親密度が発生している場合、位置決定部255は、基準利用者に対応するアバターを、例えば個々の対象利用者への親密度に応じて移動した点集合の重心に移動させる。
【0083】
続いて、
図18に示すフローチャートにおいて、管理部152は、投稿・応答履歴を参照して、グループの構成員による投稿に対して当該グループの他の構成員による応答が紐付けられているか否かを、グループの各構成員についてそれぞれ判別する(ステップSb17)。投稿に対する応答が存在すれば(ステップSb17の判別結果が「Yes」であれば)、管理部152は、当該投稿者および応答者の利用者IDの全組を位置変更部256に通知する(ステップSb18)。
なお、投稿に対する応答が存在しなければ(ステップSb17の判別結果が「No」であれば)、ステップSb18の処理はスキップする。
【0084】
次に、位置変更部256は、構成員に対応するアバターの立ち位置を、応答に応じて変更する(ステップSb19)。
詳細には、位置変更部256は、グループの構成員による投稿に対して他の構成員による応答が紐付けられている場合に、当該応答者に対応するアバターの立ち位置を、投稿者に対応するアバターの立ち位置に接近した投稿者接近位置に変更する(三次配置)。
【0085】
図22は、位置の接近を示す平面図である。
この図において、投稿者接近位置とは、本実施形態にあっては、対象となる応答者の基準位置と投稿者に対応するアバターの立ち位置とを結ぶ直線上であって、投稿者に対応するアバターの立ち位置から距離rだけ離れた地点としている。
例えば基準位置C2にアバターが割り当てられた仲間の投稿に対し、基準位置C1にアバターが割り当てられた仲間が応答したとき、位置変更部256は、基準位置C1に割り当てられたアバターの立ち位置を、基準位置C2に割り当てられたアバターの立ち位置Ca2に向かった投稿者接近位置Cb1に変更する。
また、例えば基準位置C9にアバターが割り当てられた仲間の投稿に対し、基準位置C8にアバターが割り当てられた仲間が応答したとき、位置変更部256は、基準位置C8に割り当てられたアバターの立ち位置を、基準位置C9に割り当てられたアバターの立ち位置Ca9に向かった投稿者接近位置Cb8に変更する。
なお、投稿者接近位置については、上記に限られず、基準範囲から超えて投稿者に接近すれば良い。このため、投稿者の基準位置から距離rだけ離れた地点としても良い。
【0086】
本実施形態では、三次配置された状態のアバターが表示部211に表示されることはないが、後述するように三次配置された状態のアバターを表示しても良い。仮に、三次配置された状態のアバターを表示するとした場合の画面例は、
図26に示される通りであり、
図22で示した位置の例に対応している。
【0087】
ところで、第2機能によるサービスについては、位置変更部256で決定した三次配置に基づいて、表示部211が表示画面に表示するようにしても良いが、単に立ち位置を変更しただけでは、あるアバターの顔が他のアバターの接近によって隠されてしまい、当該アバターがどの仲間の分身であるかが一見して判りにくくなる場合があり得る。
図26の例でいえば、仲間eに対応するアバターの顔の一部が、仲間cのアバターの接近によって隠され、同様に、仲間bに対応するアバターの顔の一部が、自身の接近によって仲間iに対応するアバターによって隠されている。
そこで、位置変更部256は、次のようにして、顔が隠れないようにアバターの立ち位置を微修正する(ステップSb20)。
【0088】
図23(d)に示されるように、アバターの顔部分が隠される場合とは、アバターの顔部分を規定する外形枠同士がハッチングで示されるように重複する場合である。このため、位置変更部256は、描画部252の描画をシミュレートして、例えば仲間eのアバターの顔部分と仲間cのアバターの顔部分とが重複するであろうと判別した場合、
図23(e)に示されるように、仲間eのアバターに接近する仲間cのアバターを、仲間eのアバターの顔部分が隠れない地点まで移動させる(接近方向とは逆方向に戻す)ように微修正し、この微修正についての移動情報を得る。
位置変更部256では、微修正に係るアバターを、変更された移動情報に基づいて再度、配置し直す。これにより、
図23(f)に示されるように、アバター同士が接近しても、互いの顔部分が視認されるように微修正される。
なお、
図26の三次配置において、仲間bのアバターの顔部分についても、仲間iのアバターによって隠されるので、仲間iのアバターに接近する仲間bのアバターを、顔部分が隠れない地点まで移動させる(接近方向とは逆方向に戻す)ように微修正し、この微修正についての移動情報を得る。
【0089】
これにより、例えば
図27に示されるように、立ち位置が変更された場合に、アバターの顔部分が隠れないようなアバターの配置が修正される(四次配置)。位置変更部256は描画部252に四次配置を出力し、描画部252は、グループ構成員に対応するアバターの画像情報を画像記憶部261から読み出すとともに、決定された四次配置の地点に立脚するようなアバターを所定の背景画像とともに描画する。
【0090】
ステップSb20の後、別の操作が指示されたり、終了させる旨が指示されたりしたとき、アバターの配置状態が記憶部205に記憶された後、このアバター配置処理が終了する。
終了後、ある程度の時間が経過して、再び、アバター配置処理の実行が指示されると、それまでの期間において、親密度テーブルの内容が更新されるので、アバターの表示位置は、前回の実行時とは異なり、再度実行指示における投稿や応答、親密度に応じて変更される。特に、投稿がなされると、最終投稿時間が更新されるだけでなく、基準位置への割り当ても変更されることになる。
ここで、例えば、アバター配置処理が再び実行されて四次配置が決定されたときに、前回の表示されたアバターの立ち位置から、今回の四次配置で決定された位置まで、各アバターが歩いて移動するようなモーションが与えられると、前回から今回の状態変化をアバターのモーションで視覚的に知ることができる。
【0091】
本実施形態においては、グループ構成員のアバターは、投稿の順序で
図20に示されるような基準位置に割り当てられるとともに、グループ構成員同士の親密度が高いほど、構成員のアバターの立ち位置が近づく。さらに、投稿に対して応答した構成員のアバターが、投稿者のアバターに対して投稿者接近位置まで接近するとともに、アバターの顔部分が隠れないようにアバターの立ち位置を微修正される。したがって、本実施形態によれば、主体者は、自己を含むグループ構成員同士における親密度や、どの構成員にどのような順序で投稿しているのか、さらには、どの構成員の投稿に対してどの構成員が応答しているのかを、視覚的に、かつ、判り易く把握することが可能になる。
【0092】
以上説明してきたように、第2機能によるサービスを提供するにあたって、メッセージ閲覧システム1は、複数の利用者の間で、投稿と当該投稿に対する応答とによって交換されるメッセージの閲覧サービスを提供するものである。そして、そのメッセージ閲覧システム1は、複数の利用者のうち、一部または全部である複数の特定利用者に対応した利用者画像(例えばアバター)のそれぞれを、画面における利用者画像の数の基準位置に、所定の規則にしたがって割り当てる割当部254と、複数の特定利用者に対応した利用者画像のそれぞれに割り当てられた基準位置を、各利用者画像を表示する表示位置として決定する位置決定部255と、利用者の投稿に対して応答した利用者に対応した利用者画像の表示位置を、投稿した利用者に対応した利用者画像に接近した位置に変更する位置変更部256を備えている。
これにより、複数の利用者のうち、一部または全部である複数の特定利用者に対応した利用者画像(例えばアバター)は、当初、画面における基準位置に割り当てられて、当該基準位置を表示位置として決定される。その後、ある利用者の投稿に対して別の利用者が応答すると、当該別の利用者(応答者)に対応した利用者画像の表示位置が、投稿した利用者(投稿者)に対応した利用者画像に接近した位置に変更される。このため、自分以外の利用者の投稿に対して応答した利用者を一見して把握することができる。
【0093】
なお、特定利用者は、複数の利用者のうち、所定の選定条件を満たす一部の利用者であっても良い。所定の選定条件としては、例えば、複数の利用者のうち、最近に投稿/応答した者の上位者であることや、投稿数/応答数が多い上位者であることなどのように、時間経過とともに特定利用者が変化する性質のものであっても良いし、複数の利用者のうち、いずれかの利用者によって予め選択された者などのように、時間経過に対して特定利用者が変化しない性質のものであっても良い。
【0094】
第2機能においては、次のような各種の応用例・変形例が可能である。
【0095】
上述した例において投稿者接近位置は親密度を反映していないので、四次配置では、応答した仲間の親密度を把握することができない。このため、アバターを、前回の配置状態から、
図27の四次配置の表示画面に示される立ち位置まで、直ちに遷移させてしまうと、応答した仲間における親密度をアバターの立ち位置で正しく表示する機会が失われる。
そこで、上述したように一次配置、二次配置および三次配置に対応した状態で順番にアバターを表示部211に表示させると、一旦、二次配置の表示画面で親密度を反映した立ち位置でアバターが表示されるので、グループ構成員における親密度をアバターの立ち位置で正しく表示する機会が担保されることになる。
【0096】
また、一次配置において、グループの仲間に対応するアバターを、投稿の順序で、
図20に示されるような規則で基準位置に割り当てたが、この規則はあくまでも一例である。また、仲間に対応するアバターについては、投稿の順序とは関係なく、基準位置に対し固定的に割り当てても良い。例えば、
図28に示されるように、投稿の順序とは関係なく、グループテーブルに登録された仲間a〜iに対応するアバターを、基準位置C1〜C9にそれぞれ時間経過に対して固定的に割り当てても良い。
仲間a〜iに対応するアバターを基準位置C1〜C9にそれぞれ固定的に割り当てた場合の一次配置は、
図29に示される通りとなる。固定的に割り当てた場合において、四次表示画面の終了後、ある程度の時間が経過して、再び、アバター配置処理の実行が指示されたときに、それまでの期間において親密度テーブルの内容が更新されていても、一次配置においてアバターに割り当てられる基準位置は変更されない。したがって、固定的に割り当てた場合には、主体者からみれば、自己を含めた構成員の親密度変化を感じ取りやすくなる。
【0097】
上述した例では、投稿に対して応答した利用者のアバターは、親密度に応じた位置から、当該投稿者のアバターに接近した位置に変更するようにしたが、これに限られない。
例えば
図30に示されるように、投稿者のアバターの周辺に、円形の固定位置(1)〜(9)を設けて、当該投稿者に対して応答があった場合に、当該投稿者からみた応答者の親密度と当該応答者からみた当該投稿者の親密度との平均値が高い順に固定位置(1)、(2)、(3)、…、を割り当てて当該応答者のアバターを配置するようにしても良い。このとき、固定位置(1)〜(9)の各々については、それらの中心点を「合わせ位置」としてアバターが描画されてもアバター(の顔部分)が重ならないように配置が定められているのが望ましい。
このような固定位置に応答者のアバターを配置させる構成にすると、投稿に対して多数の仲間が応答しても、見難くなることはないし、また、応答者と投稿者との親密度の順番を知ることもできる。さらに、顔が隠れないようする処理(
図23の(d)、(e)、(f)参照)を不要とすることができる。
【0098】
図14では、描画部252、割当部254、位置決定部255および位置変更部256について端末装置20側に設けた構成を例示したが、
図31に示すように、管理サーバ10側に設けた構成としても良い。
この構成では、例えば表示部211で表示すべき画面を管理サーバ10側で作成して、ウェブ画面として端末装置20に送信し、端末装置20がブラウザによって当該ウェブ画面を表示する構成となる。また、この構成では、管理サーバ10側の描画部252は、画像記憶部121に記憶されたアバターの画像情報を、管理部152を介して読み出して用いる。この構成によれば、画像記憶部261においてアバターの画像情報を記憶する必要がないし、アバターの描画処理も不要となるので、端末装置20側での負担を軽減することができる。
【0099】
また、
図14では、管理サーバ10側にユーザ登録テーブル、グループテーブルおよび親密度テーブルが構築され、端末装置20側に画像記憶部261が構築されたが、これらのテーブルや記憶部については、メッセージ閲覧システム1において管理サーバ10や端末装置20からアクセス可能であれば、管理サーバ10や端末装置20以外の外部サーバに構築されても良い。
【0100】
<第3機能>
メッセージ閲覧システム1において、上記第3機能のサービスを提供する際の動作について説明する。
【0101】
図32は、メッセージ閲覧システム1において第3機能のサービスを提供するために構築される機能ブロックを示す図である。
この図に示されるように、端末装置20側では、第1機能の機能ブロック(
図4参照)に対して判別部257、設定部258が構築されるとともに、記憶部205では、画像記憶部261に加えてキーワード記憶部262、モーション記憶部263が管理される。
【0102】
上述したように、第3機能では、各アバターが当該利用者の投稿内容や投稿形式に応じたモーションで表示するサービスが主体者に提供されるが、ここでは、例えば上記第2機能におけるアバターの配置処理から引き続いて実行されるものとする。このため、
図27に示されるような四次配置に基づいた表示画面において各アバターがそれぞれに対応する仲間の投稿内容や投稿形式に応じたモーションで表示される。
【0103】
図33は、第3機能におけるモーションの一覧を示す図である。
第3機能では、アバターに対応した仲間による投稿があった場合に、当該投稿に含まれる文章から感情が特定できたとき、アバターには当該感情に応じてモーション(動き)が与えられる。本実施形態においては、感情に応じたモーションとして例えば「喜び」、「嬉しい」、「怒り」、「悲しみ」、「疑問」および「焦り」の6形式が想定されている。一方、感情が特定できないとき、アバターには当該投稿の形式に応じたーションが与えられる。上述したように本実施形態においては、投稿の形式として「つぶやき」、「日記」、「フォト」および「チェックイン」の4形式が想定されている。ここで、感情が特定できないときや当該投稿の形式が「チェックイン」であれば、アバターには投稿の形式に応じたモーションが与えられる。この「チェックイン」については、投稿内容に感情表現が含まれないことが多いため感情の特定を判断せず、「飲食系」、「買い物」および「その他」の3形式に応じたモーションが与えられる。
なお、「チェックイン」の形式は、例えば投稿の文章に含まれる属性データで識別される。
また、アバターに対応した仲間が一定期間にわたって投稿しない場合、アバターは待機しているようなモーションが与えられる。なお、モーションの形式については、これらに限られないことはいうまでもない。
【0104】
本実施形態においては、投稿に含まれる文章から感情を特定するために用いられるものがキーワード記憶部262である。
図34は、キーワード記憶部262の記憶内容を示す図である。この図に示されるように、キーワード記憶部262では、上記6形式の感情のそれぞれに、当該感情を特徴付ける感情キーワードが1以上対応付けられて記憶されている。感情には、図に示されるように優先度が規定されている。これは、1つ投稿から複数の感情が特定されときに、優先度の高い感情のいずれか1つが特定できるようにするためである。なお、感情キーワードには、感情に関係する単語のほかに、感情を表現する際に用いられる、いわゆる顔文字も含まれる。また、この記憶内容は、例えば管理サーバ10の記憶部105に記憶されていたものをキーワード記憶部262に転送したものが用いられる。
【0105】
モーション記憶部263は、アバターにモーションを与える際に、当該モーションを規定するモーション情報を、感情、投稿形式、チェックインの形式毎に、それぞれ記憶する。ここで、アバターの画像情報が、四肢や、頭、顔、着衣などの外形や特徴点をベクターデータとして規定している場合、モーション情報は、その感情や投稿形式などに応じてどの部分を、どの方向に、どの程度、どのような順番で変化させるなどを規定した情報の集合体である。なお、モーション情報は、アバターのみではなく、アバターの周辺に動きを与える場合も含まれる。
このようなモーション情報は、アバター毎に対応させても良いし、各アバターにわたって共通化したものを用いても良い。
なお、このモーション情報は、例えば管理サーバ10の記憶部105に予め記憶されていたものをモーション記憶部263に転送したものが用いられる。
【0106】
なお、感情表現の具体例については
図36に、投稿動作の具体例については
図37に、チェックイン(スポットカテゴリー)動作の具体例については
図38に、待機動作の具体例については
図39に、それぞれ示される通りである。
また、アバターの画像情報が、ビットマップデータで規定されている場合、モーション情報は、その感情や投稿形式などをコマ送りで表現するビットマップデータの集合体であれば良い。
【0107】
次に、投稿の内容や形式等に応じてアバターにモーションを設定するモーション設定処理について説明する。
【0108】
図35は、モーション設定処理を示すフローチャートである。なお、このモーション設定処理は、アバターの1体分の処理であり、上記第2機能におけるアバターの配置処理から引き続いて実行されるのであれば、主体者を含めたアバターの10体分の処理が実行される。
【0109】
まず、判別部257は、第1に、ある一体のアバターに着目して、当該アバターに対応する利用者の最終投稿時間を、第2機能におけるステップSb12と同様な手法によって取得する。判別部257は、第2に、当該アバターの情報を管理部152に問い合わせて取得する(ステップSc11)。
続いて、判別部257は、取得した最終投稿時間からRTC206で示される現在時刻までの期間が一定期間(例えば三日)以上であるか否かを判別する(ステップSc12)。
【0110】
一定期間経過している場合(ステップSc12の判別結果が「Yes」である場合)、その旨を設定部258に通知し、設定部258は、着目しているアバターに対し、モーションとして待機動作を選択する(ステップSc13)。ここで、本実施形態において待機動作には、
図39において(a)の柔軟体操、(b)の挨拶、および(c)の睡眠の3種類が想定されている。設定部258は、柔軟体操、挨拶または睡眠のいずれかの1つをランダムに、または、順番に選択する。
なお、(a)の柔軟体操は、アバターの両腕を回転させるモーションであり、(b)の挨拶は、アバターの右手を挙げるモーションであり、(c)の睡眠は、イビキを示す擬声語を図に示されるように順番に繰り返して表示するモーションである。
【0111】
一方、一定期間経過していない場合(ステップSc12の判別結果が「No」である場合)、判別部257は、管理部152を介して投稿履歴を参照し、当該投稿の形式を特定する(ステップSc14)。そして、判別部257は、特定した投稿の形式が「チェックイン」であるか、それ以外のものであるか、を判別する(ステップSc15)。ここで、特定された投稿の形式が「チェックイン」以外の「つぶやき」、「日記」または「フォト」であるとき(ステップSb15の判別結果が「No」であるとき)、判別部257は、着目しているアバターに対応した利用者による最新の投稿に含まれる文章、すなわち「つぶやき」や、「日記」、「フォト」に付帯する文章を解析する(ステップSc16)。詳細には、判別部257は、当該投稿による含まれる文章を、投稿履歴を参照して取得した後、当該文章を文節に区切るとともに、各文節のうち、キーワード記憶部262における感情キーワードに該当するものを感情毎に集計する。
そして、判別部257は、この集計値から、当該投稿の感情が特定できたか否かを判別する(ステップSc17)。詳細には、判別部257は、集計値がすべてゼロでないとき、判別結果を「Yes」として、すなわち感情を特定できたと判別する。このとき、判別部257は、集計値が最大なものをその投稿の感情として特定し、集計値が同じものがあれば、
図34において優先度の高い方を、当該投稿の感情として特定して、その特定結果を設定部258に通知する。
【0112】
設定部258は、着目しているアバターに対し、特定された感情表現動作に対応するモーションを選択する(ステップSc18)。なお、本実施形態において感情に対応する動作は、次のようなものとなっている。
すなわち、「喜び」は、
図36(a)で示されるように、アバターの両腕を上げ下げさせて万歳するモーションであり、「嬉しい」は、同図(b)で示されるように、アバターの上半身を視線方向からみて左右に揺らすモーションであり、「怒り」は、同図(c)で示されるように、アバターの両肩を震わすモーションである。また、「悲しみ」は、同図(d)で示されるように、アバターの両目から涙が溢れるモーションであり、「疑問」は、同図(e)で示されるように、アバターが首をひねるモーションであり、「焦り」は、同図(f)で示されるように、アバターから汗が噴き出るモーションである。
【0113】
また、判別部257は、集計値がすべてゼロであるとき、判別結果を「No」として、すなわち感情を特定できなかったと判別する。このとき、設定部258は、着目しているアバターに対し、特定された投稿の形式に対応するモーションを選択する(ステップSc19)。なお、本実施形態において投稿の形式に対応する動作は、次のようなものとなっている。すなわち、「つぶやき」は、
図37(a)で示されるように、アバターが左手を口に添えて口を動かすモーションであり、「日記」は、同図(b)で示されるように、右手に持ったペンで日記帳に書き込みをするモーションであり、「フォト」は、同図(c)で示されるように撮影動作、すなわち左手でカメラを構えて右手人差し指でレリーズする(シャッターボタンを押す)モーションである。
【0114】
一方、特定された投稿の形式が「チェックイン」であるとき(ステップSb15の判別結果が「Yes」であるとき)、判別部257は、属性データを参照して、当該チェックインの形式(スポットカテゴリー)を特定する(ステップSc20)。
設定部258は、着目しているアバターに対し、特定されたスポットカテゴリーに対応するモーションを選択する(ステップSc21)。詳細には、設定部258は、特定されたスポットカテゴリーが飲食系であれば、
図38(a)で示されるように、アバターがカップで珈琲を飲むモーションを選択し、買い物系であれば、同図(b)で示されるように、左手に紙袋を提げて、上半身を左右に揺らしながら歩くモーションを選択する。なお、設定部258は、特定されたスポットカテゴリーが飲食系でも買い物系でもないとき、同図(c)で示されるように、その他として、左手に持った旗を振り回すようなモーションを選択する。なお、チェックインの形式については、投稿の際に取得した店舗情報や位置情報などから特定される。
【0115】
設定部258は、ステップSc13、Sc18、Sc19、Sc21においてモーションを選択すると、当該選択したモーションに対応するモーション情報を、モーション記憶部263から読み出す。設定部258は、着目しているアバターに、選択したモーションに対応するモーション情報を設定して、その設定情報を描画部252に出力する(ステップSc22)。
【0116】
この後、フローチャートでは特に図示しないが、着目する対象が別のアバターに変更されて、当該別のアバターについても同様な処理が実行される。このような処理は、四次配置に基づく表示画面で表示された10体分のアバターの各々にモーションがそれぞれ設定されるまで繰り返し実行される。
【0117】
描画部252は、設定されたモーション情報で規定されたモーションを付与して、各アバターをそれぞれ描画する。これにより、表示部211では、利用者の親密度や応答に応じた立ち位置で表示されたアバターが、さらに当該利用者による投稿内容や投稿形式に応じてモーションすることになる。したがって、主体者は、自己を含めたグループの構成員の投稿近況や投稿内容等を一見して知ることができる。
【0118】
このようなモーション設定処理については一定期間(例えば10分)毎に、繰り返し実行するようにしても良い。このように繰り返し実行すると、例えば、三日以内に投稿したものの、それ以降投稿していない構成員のアバターについては、感情または投稿形式に応じたモーションから、投稿から三日経過した時点で待機動作のモーションに切り替わる。また、構成員が投稿してから三日以内に再度投稿した場合、当該構成員のアバターは、前回の投稿内容に応じたモーションから今回の投稿内容に応じたモーションに切り替わる。したがって、グループ構成員の投稿近況や投稿内容等の変化についても知ることもできる。
【0119】
上述したように第3機能では、
図27に示される表示画面において、各アバターがそれぞれに対応する構成員の投稿内容や投稿形式に応じたモーションで表示される。この表示画面において、例えば右上に表示された「グループA」というボタン301、すなわち、これらのアバターに対応する利用者によって構成されるグループの名前を示すボタン301を主体者がタッチ操作すると、例えば判別部257は、管理部152を介して当該グループの構成員の投稿・応答履歴を参照する。そして、判別部257は、これらの投稿・応答履歴を描画部252に転送し、描画部252は、表示部211に、当該グループの構成員による「投稿」と当該「投稿」に紐付けられた「応答」との履歴を時間の順で表示させる。
【0120】
図40は、当該タッチ操作によって表示される投稿・応答履歴に基づく画面の一例を示す図である。この表示画面において、(3)は、形式が「つぶやき」の「投稿」であり、(1)、(2)は、いずれも当該「投稿」に対する「応答」である。(1)、(2)の「応答」は、いずれも形式が「コメント」であり、(3)の「投稿」に紐付けられていることが判るように、図において右側にインデントされている。また、(5)は、形式が「日記」の「投稿」であり、(4)は、当該「投稿」に対して形式が「コメント」の「応答」である。
この表示画面では、「投稿」同士を比較したとき、上に位置するものほど時間的に後になされた例である。例えば、(3)の「投稿」と(5)の「応答」とを比較したときに、上に位置する(3)の「投稿」は(5)の「投稿」よりも時間的に後になされている。また、同じ「投稿」に紐付けられた「応答」同士を比較したとき、上に位置するものほど時間的に後になされた例である。例えば同じ(3)の「投稿」に紐付けられた(1)、(2)の「応答」同士を比較したとき、上に位置する(1)の「応答」は(2)の「応答」よりも時間的に後になされている。
いずれの「投稿」および「応答」には、それを発信した者を示すためのアバターの簡易画像とともに、名前、形式、発信日時、テキスト(メッセージ)が関連付けられて表示される。また、「日記」に対応するテキストは一部しか表示できないので、詳細な表示に移行するためのソフトウェアボタン324が表示されている。
【0121】
なお、
図40の表示画面において、ボタン302は、
図27の表示画面に戻ることを指示するソフトウェアボタンである。入力フィールド311は、主体者が「グループA」において新規の「つぶやき」を投稿する場合に、テキストを入力するための領域である。入力フィールド311を用いてテキストを入力する際には別途のソフトウェアキーボード(図示省略)が表示される。ボタン313は、入力フィールド311に入力されたテキストでの投稿を指示するソフトウェアボタンである。
なお、ボタン313が主体者によって操作されると、入力フィールド311に入力されたテキストが、入力指示部251、受付部151、管理部152を介してSNSサーバ50に供給されて、投稿した主体者の会員IDと投稿ID(つぶやきID等)とテキストと発信日時とグループIDに対応付けられて投稿・応答履歴に追加記憶される。
【0122】
また、入力フィールド321は、「投稿」に対して「コメント」で応答する場合に、テキストを入力するための領域である。ボタン323は、入力フィールド321に入力されたテキストでの「応答」を指示するソフトウェアボタンである。このため、入力フィールド321およびボタン323は、「投稿」ごとに設けられる。なお、ボタン323が主体者によって操作されると、入力フィールド321に入力されたテキストが、入力指示部251、受付部151、管理部152を介してSNSサーバ50に供給されて、応答した主体者の会員IDと応答ID(コメント)とテキストと発信日時とグループIDと元の投稿IDとに対応付けられて投稿・応答履歴に追加記憶される。
【0123】
また、この第3機能については、第2機能によるアバターの配置処理から引き続いて実行する構成としたが、第2機能とは独立して実行しても良い。例えば、グループを選択した後に、各アバターを基準位置に配置させた状態でモーションを設定しても良い。また、グループの構成員の選択を促す画面を表示させるとともに、構成員が選択されたときに、選択された構成員のアバターにモーションを設定しても良い。
【0124】
以上説明してきたように、第3機能によるサービスを提供するにあたって、メッセージ閲覧システム1は、複数の利用者の間で、複数の形式(例えば「つぶやき」、「日記」、「フォト」、「チェックイン」)のいずれかの形式の投稿と当該投稿に対する応答とによって交換されるメッセージの閲覧サービスを提供するものである。そして、そのメッセージ閲覧システム1は、画面上で表示される利用者画像(例えばアバター)であって、複数の利用者のそれぞれに対応した利用者画像を記憶する画像記憶部261と、利用者画像のモーションを定義したモーション情報を、感情の種類または投稿の形式に関連付けて記憶するモーション記憶部263と、感情の種類に応じたキーワードを記憶するキーワード記憶部262を備える。さらに、複数の形式のうち特定形式(例えば「つぶやき」、「日記」、「フォト」)の投稿の文章からキーワード記憶部262に記憶されたキーワードが含まれるか否かで感情の種類のいずれかを特定できるか、いずれも特定できないかを判別する判別部257を備える。そして、利用者からの投稿が特定形式の場合で、判別部257で感情の種類を特定できたとき、特定した感情に対応したモーション情報を選択し、判別部257で特定できなかったときは特定形式に対応したモーション情報を選択し、選択したモーション情報に基づいて、投稿した利用者に対応した利用者画像のモーションを設定する設定部258を備えている。
さらに、設定部258は、利用者からの投稿が特定形式以外(例えば「チェックイン」)の場合に、投稿の形式に対応したモーション情報を選択するようにしても良い。つまり、感情の種類を特定しにくい投稿形式に対しては、判別部257での感情の種類を特定の判別を行わないようにすることも可能である。
これにより、投稿が特定形式であって、投稿の文章から感情が特定できたときには、当該感情に対応したモーションが当該投稿をした利用者の利用者画像(例えばアバター)に設定され、投稿の文章から感情が特定できないときには、投稿の形式に応じたモーションが当該利用者の利用者画像に設定される。したがって、複数の利用者のいずれから投稿があったときに、利用者画像に様々なモーションを与えることができるだけでなく、そのモーションから投稿の文章内容や投稿の形式を一見して知らせることができるので、サービスの提供を受ける利用者に興味を抱かせることが可能になる。
【0125】
第3機能においては、次のような各種の応用例・変形例が可能である。
【0126】
第3機能では、「応答」という概念をなくして「投稿」だけとした構成が可能である。「応答」という概念をなくした構成においては、ある「投稿」に対して、「投稿」で返答することになる。なお、この構成において、「投稿」として「つぶやき」、「日記」、「フォト」、「チェックイン」のように様々な形式を用いても良いのは、もちろんである。
【0127】
図41は、「投稿」のみの履歴に基づく画面の一例を示す図である。この画面は、対応関係を明確するために、
図40の表示画面における「応答」をすべて「投稿」に置き換えたものである。「応答」がなく、すべて同列の「投稿」となるので、単純に発信日時の順に表示される。なお、
図41の画面において、「フォト」対応する(6)の投稿では、アップロードされた画像が表示できないので、当該画像の表示に移行するためのソフトウェアボタン325が表示されている。
【0128】
図32では、描画部252、判別部257および設定部258について端末装置20側に設けた構成を例示したが、
図42に示すように、管理サーバ10側に設けた構成としても良い。
この構成では、例えば表示部211で表示すべき画面を管理サーバ10側で作成して、ウェブ画面として端末装置20に送信し、端末装置20がブラウザによって当該ウェブ画面を表示する構成となる。この構成では、モーション記憶部およびキーワード記憶部は、管理サーバ10側の記憶部105に記憶される。また、この構成において、管理サーバ10側の判別部257は、管理部152を介してキーワード記憶部にアクセスし、設定部258は、同様に管理部152を介してモーション記憶部にアクセスする。なお、この構成では、時間情報の取得は、管理サーバ10側のRTC106が用いられる。この構成によれば、端末装置20側に、キーワードの抽出や、モーション情報の設定、アバターの描画処理などが不要となるので、端末装置20側での負担を軽減することができる。
【0129】
第3機能において「応答」のないサービスを提供にするにあたって、メッセージ閲覧システム1は、例えば1対1チャットやグループチャットのように、複数の利用者の間で、複数の形式のいずれかの形式の投稿によって交換されるメッセージの閲覧サービスを提供するものとなる。すなわち、そのメッセージ閲覧システム1は、画面上で表示される利用者画像であって、複数の利用者のそれぞれに対応した利用者画像を記憶する画像記憶部261と、利用者画像のモーションを定義したモーション情報を、感情の種類または投稿の形式に関連付けて記憶するモーション記憶部263と、感情の種類に応じたキーワードを記憶するキーワード記憶部262を備える。
さらに、複数の形式のうち特定形式の投稿の文章からキーワード記憶部に記憶されたキーワードが含まれるか否かで感情の種類のいずれかを特定できるか、いずれも特定できないかを判別する判別部257を備える。そして、利用者からの投稿が特定形式(例えば「つぶやき」、「日記」、「フォト」)の場合で、判別部257で感情の種類を特定できたとき、特定した感情に対応したモーション情報を選択し、選択したモーション情報に基づいて、当該投稿した利用者に対応した利用者画像のモーションを設定する設定部258を備える。
くわえて、設定部258は、判別部257で特定できなかったときは、特定形式に対応したモーション情報を選択する構成としても良いし、利用者からの投稿が特定形式以外(例えば「チェックイン」)の場合に、投稿の形式に対応したモーション情報を選択するようにしても良い。
【0130】
また、
図32では、管理サーバ10における記憶部105の記憶内容が端末装置20に転送されることにより、当該端末装置20側で画像記憶部261、キーワード記憶部262およびモーション記憶部263が構築されたが、これらの記憶部については、メッセージ閲覧システム1において管理サーバ10や端末装置20からアクセス可能であれば、管理サーバ10や端末装置20以外の外部サーバに構築されても良い。
第3機能のサービスの提供にあたって、
図32に示されるように画像記憶部が端末装置20に構築される場合には、描画部252が当該画像記憶部を参照するので、画像参照部として機能する。また、
図42に示されるように画像記憶部が管理サーバ10に構築される場合には、管理部152が当該画像記憶部を参照するので、画像参照部として機能する。なお、特に図示しないが、画像記憶部が外部サーバに構築される場合には、描画部252、管理部152または別途の機能ブロックが外部サーバにおける画像記憶部を参照する。このため、描画部252、管理部152または別途の機能ブロックのいずれかが画像参照部として機能する。
図32に示されるようにキーワード記憶部が端末装置20に構築される場合には、判別部257が当該キーワード記憶部を参照するので、キーワード参照部として機能する。また、
図42に示されるようにキーワード記憶部が管理サーバ10に構築される場合には、管理部152が当該キーワード記憶部を参照するので、キーワード参照部として機能する。なお、特に図示しないが、キーワード記憶部が外部サーバに構築される場合には、判別部257、管理部152または別途の機能ブロックのいずれか外部サーバにおけるキーワード記憶部を参照するので、当該いずれかがキーワード参照部として機能する。
同様に、
図32に示されるようにモーション記憶部が端末装置20に構築される場合には、設定部258が当該モーション記憶部を参照するので、モーション参照部として機能する。また、
図42に示されるようにモーション記憶部が管理サーバ10に構築される場合には、管理部152が当該キーワード記憶部を参照するので、モーション参照部として機能する。なお、特に図示しないが、モーション記憶部が外部サーバに構築される場合には、設定部258、管理部152または別途の機能ブロックが外部サーバにおけるモーション記憶部を参照するので、設定部258、管理部152または別途の機能ブロックのいずれかがモーション参照部として機能する。
【0131】
<第4機能>
続いて、メッセージ閲覧システム1における上記第4機能について説明する。
この第4機能においては、第2機能における四次配置に基づく表示画面に対して、投稿があったことを示す吹き出しが
図43に示されるように表示される。なお、投稿がなければ、吹き出しが示されない。
【0132】
図44は、メッセージ閲覧システム1において第4機能のサービスを提供する際に構築される機能ブロックを示す図である。
この図に示されるように、端末装置20側においては、第1機能の機能ブロック(
図4参照)に対して判別部257、設定部258が構築されるとともに、記憶部205では、画像記憶部261に加えてモーション記憶部263および絵柄記憶部264が管理され、管理サーバ10側における記憶部105ではリアクションテーブルが管理される。
【0133】
上述したように、第4機能では、主体者が、ある仲間の投稿に対し、アイコンや当該仲間のアバターをタッチ操作等することによって応答すると、当該仲間のアバターが当該応答形式に応じたモーションで表示される、すなわち、アバターが応答形式に応じてリアクションする、というサービスが提供される。
ここで、応答形式については、本実施形態では、アイコン操作等する形式と、投稿した仲間に対応したアバターをタッチ操作等する形式と、コメントで応答する形式との3形式に分けられる。このうち、アイコン操作等による応答形式とアバターのタッチ操作等による応答形式とは、それぞれ定型応答文に対応している。詳細には、アイコン操作等による応答形式には、定型応答文に対応した「クラッカー」、「へぇ」および「イイネ(ハート)」の3形式があり、アバターのタッチ操作等による応答形式には、定型応答文に対応した「パンチ」、「胴上げ」、「くるくる」および「なでなで」の4形式がある。
モーション記憶部263は、アイコン操作等による3形式と、アバターのタッチ操作等による4形式とのそれぞれに対応したアニメーション情報およびモーション情報を記憶する。
【0134】
一方で、第4機能では、自己の投稿に対して別の利用者が応答したときに、自己に対応するアバターに、当該別の利用者の応答内容に応じたモーションやアイコン(絵柄)が付加される。
絵柄記憶部264は、アバターに対し応答形式に応じて付加されるアイコンを記憶する。このアイコンは、例えば管理サーバ10の記憶部105に記憶されていたものを絵柄記憶部264に転送したものが用いられる。
なお、アイコンは、応答形式を規定するものと、アバターに対し当該応答形式に応じて付加表示されるものとの2種類があるので、混同を避けるために、後者に係るアイコンを絵柄画像と称することにする。
また、利用者の応答内容を記録するためのものがリアクションテーブルであり、管理サーバ10の記憶部105に記憶される。
【0135】
図45および
図46は、リアクションテーブルの一例を示す図である。このうち、
図45は、形式が「つぶやき」である投稿に対しての応答を示し、
図46は、形式が「日記」、「フォト」および「チェックイン」である投稿に対しての応答を示している。
これらの図に示されるように、各投稿には、SNSサーバ50にて一意に識別するためのIDがそれぞれ付与される。そして、一つの投稿に対し応答があったとき、応答者の利用者ID毎に、各応答形式におけるリアクション数の合計値が記憶される。
なお、
図45および
図46では、リアクションテーブルを投稿形式で分類したが、投稿形式を特定する識別IDを投稿毎に付与して、1つのテーブルで管理しても良い。
【0136】
図47は、リアクション設定処理を示すフローチャートである。なお、このリアクション設定処理では、誰の投稿に対して応答するかについて、主体者によって選定されている状態を前提としている。また、応答しようとする投稿者の選定については、例えば
図43に示す画面において、投稿者に対応するアバターまたは当該アバターに付随する吹き出しを、主体者がタップやフリックなどのタッチ操作することによってなされる。
【0137】
図48は、主体者が仲間による投稿に対して応答するために、当該仲間(投稿者)を選定したときの表示画面の一例である。この図に示されるように、表示部211には、選定した投稿者に対応するアバターが表示されるとともに、画面の上端には枠272が表示され、画面の下端には、アイコン281〜285が操作ボタンとして表示される。枠272には、当該投稿者のニックネームとともに、当該投稿者による投稿のうち、最新のものに係る文章が表示される。
なお、この図の表示画面では、アバターに対応した仲間が「つぶやき」の投稿したことによって、当該アバターに
図37(a)のモーションが付与された例である(第3機能)。
また、アイコン281は、「クラッカー」に対応するものであり、枠272に示される投稿に対して驚きで応答する場合に用いられる。アイコン282は、「へぇ」に対応するものであり、当該投稿に対して感嘆で応答する場合に用いられる。アイコン283は、「イイネ(ハート)」に対応するものであり、当該投稿に対して賛同、賞賛等で応答する場合に用いられる。アイコン284は、「コメント」に対応するものであり、投稿に対してテキストで返信する場合に用いられる。アイコン285は、いわゆる閉じるボタンであり、仲間による投稿に対して応答することを終了して、
図43の画面に戻ることを指示する場合に用いられる。
なお、「履歴」と付された吹き出し271をタッチ操作すると、例えば後述するように当該投稿および当該投稿に紐付けられた応答の履歴が時間の順で表示される。
【0138】
さて、
図47において、まず、判別部257は、入力指示部251から応答操作を、詳細には、主体者が端末装置20において投稿に対して応答操作をしたか否かを判別する(ステップSd11)。
図48の表示画面の例でいえば、アイコン281〜285のいずれかをタップしたか、または、投稿者に対応するアバターに対してタッチ操作をしたか、否かが判別される。
なんらかの応答操作をしたと判別したならば(ステップSd11の判別結果が「Yes」であれば)、判別部257は、当該応答操作がいずれかのアイコンをタップした操作であるか否かを判別する(ステップSd12)。
【0139】
アイコン281〜285のいずれかがタップされた場合、さらに、判別部257は、当該タップされたアイコンがコメントに対応するアイコン284であるか否かを判別する(ステップSd13)。
この判別結果が「No」であれば、判別部257は、当該タップされたアイコンが閉じるボタンに相当するアイコン285であるか否かを判別する(ステップSd14)。このアイコン285がタップされたのであれば(ステップSd14における判別結果が「Yes」であれば)、このリアクション設定処理が終了する。
【0140】
一方、アイコン281〜283のいずれかがタップされた場合(ステップSd14における判別結果が「No」である場合)、判別部257は、タップされたアイコンの情報を設定部258に通知し、設定部258は、当該タップされたアイコンに対応する絵柄画像、アニメーション情報およびモーション情報を選択する(ステップSd15)。
【0141】
例えば、アイコン281がタップされたのであれば、設定部258は、クラッカーを絵柄画像として選択するとともに、当該クラッカーから紙吹雪が吹き出すアニメーション情報を選択し、投稿者に対応するアバターが驚くモーション情報を選択する。なお、このように情報が選択されると、描画部252は、アバターの左側にクラッカーを配置し、当該クラッカーから紙吹雪が吹き出すとともに、当該アバターが驚くように、アバターおよびアバター周辺を描画する。なお、アイコン281が連続してタップ(連打)されたのであれば、描画部252は、タップ毎に、クラッカーの炸裂および紙吹雪の吹き出すように描画する。
また例えば、アイコン282がタップされたのであれば、設定部258は、「へぇ」なる文字を絵柄画像として選択し、当該文字が初期サイズで画面下側から移動しながら拡大して、画面の中央部付近で停止するアニメーション情報を選択し、投稿者に対応するアバターが例えば2回うなずくモーション情報を選択する。なお、このように情報が選択されると、描画部252は、「へぇ」なる文字を初期サイズでアバターの足下近傍から浮かび上がりつつ徐々にサイズが拡大してアバターの頭部付近で停止し、当該アバターが2回うなずくように描画する。なお、アイコン282がタップされる毎に、例えば「へぇ」なる文字の初期サイズを10%ずつ拡大するように描画する。
【0142】
一方、アイコン283がタップされたのであれば、設定部258は、ハートマークを絵柄画像として選択し、当該マークが初期サイズで画面下側から移動しながら拡大して、画面の中央部付近で停止するアニメーション情報を選択し、投稿者に対応するアバターが喜ぶモーション情報を選択する。なお、このような情報が選択されると、描画部252は、ハートマークを初期サイズでアバターの足下近傍から風船のように浮かび上がりつつ徐々にサイズが拡大してアバターの頭部付近で停止し、当該アバターが喜ぶように描画する。なお、アイコン283がタップされる毎に、ハートマークの初期サイズが例えば10%ずつ拡大し、最大200%に達する毎に、新たなハートマークが異なる地点で浮かび上がるように描画する。
図49は、アイコン283がタップされた場合の表示画面の例である。アイコン283がタップに応じて反転するとともに、アバターには、アイコン283へのタップに応じて喜ぶ(
図36(a)参照)モーションが付与される。
【0143】
設定部258は、当該タップされたアイコンに対応する絵柄画像、アニメーション情報およびモーション情報を選択した後、対象となっている投稿の形式、投稿者に対応する利用者ID、主体者の利用者ID、タップされたアイコンの種別およびタップ数を管理部152に通知する。
ここで、応答した主体者は、投稿に対する応答者になる。このため、管理部152は、設定部258から通知された内容にしたがってリアクションテーブルを更新する(ステップSd16)。詳細には、管理部152は、対象となっている投稿の形式であって、投稿者に対応する利用者ID、主体者(応答者)の利用者ID、および、タップされたアイコンの種別に対応する回数を、通知されたタップ数分だけアップカウントする。
【0144】
ところで、アイコン284がタップされた場合(ステップSd13の判別結果が「Yes」となる場合)、判別部257は、描画部252に対してコメントの入力画面を表示するように指示する(ステップSd17)。これにより、主体者の端末装置20では、実際に表示部211にはコメント入力画面(図示省略)が表示されて、当該主体者は、テキストを入力して投稿に対して応答することになる。
【0145】
さて、主体者が端末装置20において投稿に対し応答操作をした場合に、その応答操作が投稿者に対応するアバターへのタッチ操作であるとき(ステップSd12の判別結果が「No」であるとき)、判別部257は、タッチ操作の種類およびタッチ操作されたアバターの部位に応じて応答形式を特定して、その応答形式を示す情報を設定部258に通知し、設定部258は、当該応答形式に応じたモーション情報を選択する(ステップSd18)。
【0146】
なお、アバターへのタッチ操作等に対し、特定される応答形式、および、選択されるモーション情報については、次の通りである。
すなわち、アバターへのタッチ操作が頭部または腹部に対するタップであれば、応答形式が「パンチ」であると特定される。ここで、頭部に対するタップであれば、アバターがのけぞるようなモーション情報が選択され、腹部に対するタップであれば、アバターが前屈みとなるようなモーション情報が選択される。このとき、アバターが苦痛でゆがむような表情をモーション情報に加えても良い。
図50は、アバターの頭部がタップされた場合の表示画面の例である。タップされた部位が応じてヒットマーク286が表示される。
【0147】
また、アバターへの操作が下から上に払うようなフリックであれば、応答形式が「胴上げ」であると特定されて、立ち位置からジャンプした後、元の立ち位置に着地するようなモーション情報が選択される。
一方、アバターへの操作が繰り返し左右に往復させる軌跡を描くような操作であれば、応答形式が「くるくる」であると特定されて、アバターが回転するようなモーション情報が選択される。
さらに、アバターへのタッチ操作が頭部を左右に振る軌跡を描くような操作であれば、応答形式が「なでなで」であると特定されて、照れながら頭部を揺らすようなモーション情報が選択される。
なお、応答形式が「胴上げ」、「くるくる」、「なでなで」であると特定された場合のモーションについては特に図示はしないが、アバターが喜び、または、嬉しさの表情を浮かべるようなモーション情報を加えても良い。
また、これ以外のタッチ操作であれば、例えば当該タッチ操作が無効である旨を判別して何も処理を実行しない構成としても良い。
【0148】
設定部258は、応答形式に応じたモーション情報を選択した後、対象となっている投稿の形式、投稿者に対応する利用者ID、主体者の利用者ID、応答形式を管理部152に通知する。管理部152は、設定部258から通知された内容にしたがってリアクションテーブルを更新する(ステップSd19)。詳細には、管理部152は、対象となっている投稿形式であって、投稿者に対応する利用者ID、主体者を応答者とした利用者ID、および、特定された応答形式に対応する回数を例えば「1」だけアップカウントする。
【0149】
ステップSd15、Sd18においてモーションを選択すると、設定部258は、当該選択したモーションに対応するモーション情報を、モーション記憶部263から読み出す。設定部258は、選択した投稿者に対応するアバターに、当該モーション情報を設定して、その設定情報を描画部252に出力する(ステップSd20)。
【0150】
描画部252は、設定されたモーション情報で規定されたモーションを付与して、投稿者に対応するアバターをそれぞれ描画する。このとき、描画部252は、絵柄画像が選択されているのであれば、操作に応じて絵柄画像にアニメーション効果を与えて描画する。これにより、表示部211では、投稿者に対応するアバターが、主体者の応答形式、すなわち投稿者の投稿に対しての自己の感情に応じてモーションすることになる。
【0151】
このように主体者が仲間の投稿に対して応答すると、当該仲間のアバターが当該投稿の形式に応じてモーションするとともに、リアクションテーブルが更新される。逆にいえば、主体者が投稿したときに、他の端末装置20において他の利用者も同様に、当該投稿に対して応答する。そして、その応答に応じてリアクションテーブルが更新される。
自己の投稿に対して他の利用者がどのように応答したのかについては、表示部211において中心に表示された自己のアバターに反映される。
【0152】
詳細には、例えば
図43に示す画面において、仲間に対応するアバターではなく、自己、すなわち画面の中心に位置するアバターまたは当該アバターに付随する吹き出しを、主体者が入力指示部251を介してタップやフリックなどのタッチ操作をすれば、その操作情報が入力指示部251から受付部151を介して管理部152に供給される。この操作情報の供給を受けた管理部152は、リアクションテーブルを参照して、当該主体者の最新投稿に対して他の利用者による応答を形式毎に累計し、これら形式毎に累計した値の情報を、上記操作情報を供給した端末装置20の設定部258に通知する。設定部258は、当該累計した値で定められる応答の形式に応じてモーション情報や絵柄画像を選択して、主体者に対応するアバターに設定し、描画部252に設定内容を通知する。描画部252は設定内容に応じて描画する。
【0153】
これにより、例えば
図51に示されるような画面が表示される。この図に示される画面において、自己に対応するアバターは、自己の投稿に対する応答の形式に応じてモーションするとともに、当該形式に対応した絵柄画像がアニメーションで表示される。この例でいえば、ハートマークが出現していることから、自己の投稿に対して「イイネ(ハート)」という応答があったことが一見して判る。また、自己に対応するアバターには、「イイネ(ハート)」に対応して「喜び」のモーション(
図36(a)参照)が付与される。なお、枠272には、自己の最新の投稿にかかる文章が表示されて、アバターのモーションと表示される絵柄画像の根拠となった投稿が確認できるようになっている。
また、例えば
図52に示されるような画面が表示されたとき、「へぇ」という文字が出現していることから、自己の投稿に対して「へぇ」という応答があったことが判る。また、自己に対応するアバターには、「へぇ」に対応して例えば2回うなずくモーションが付与される。
一方、自己の投稿に対して応答が複数ある場合に、設定部258は、リアクションテーブルのうち、累計した値が最大である形式に対応したモーション情報を1つ選択するとともに、当該形式に対応した絵柄画像を選択して、描画部252が、選択に応じた画面を描画する構成としても良い。
この場合に、設定部258は、リアクションテーブルのうち、累計した値が大きい形式の順に、対応したモーション情報および絵柄情報を選択して、主体者に対応するアバターに設定しても良い。例えば、自己の投稿に対して応答の数が「イイネ(ハート)」、「へぇ」の順にあった場合に、
図51に示した画面の後、
図52に示した画像に変化することになる。モーションおよび絵柄画像の順序は、応答の形式毎に累計した値が大きい順に限られず、ランダムであっても良い。
なお、
図52の画面において、「応答数」と付された吹き出し273がタップされると、
図53に示されるように、リアクションの詳細(形式、累計値、相手の名前)が表示される。このうち「相手の名前」とは、例えば投稿に対して最も速く「応答」した者の名前であり。
【0154】
第4機能では、仲間の投稿に対し、アイコンへのタップや当該仲間に対応するアバターへのタッチ操作によって応答することができる。このとき、当該仲間に対応するアバターが、当該応答の内容に応じてモーションしたり、アバター周辺に絵柄画像がアニメーションで表示したりする。
一方で、自己の投稿に対して、別の利用者が応答したときに、自己に対応するアバターを、当該別の利用者による応答の形式に応じてモーションしたり、アバター周辺に絵柄画像がアニメーションで表示したりする。
【0155】
図48、
図49または
図50の画面において、「履歴」と付された吹き出し271をタッチ操作すると、当該アバターに対応した仲間による投稿と当該投稿に紐付けられた応答との履歴が時間の順で表示される。
【0156】
図54は、当該タッチ操作によって表示される投稿・応答履歴に基づく画面の一例を示す図であり、基本的には、
図40に示した画面とほぼ同様である。ただし、
図40の画面では、選択されたグループの構成員による投稿および当該投稿に紐付けられた応答が時間の順で表示されたものであるのに対して、
図54に示される画面では、当該グループの構成員のうち、選択した仲間(この例では仲間b)の投稿と当該投稿に紐付けられた応答が時間の順で表示される。また、
図54に示される画面は、「応答」として「コメント」に、アイコン操作による「クラッカー」、「イイネ」や、アバターへの操作による「パンチ」が加わった例である。
【0157】
以上説明してきたように、第4機能によるサービスを提供するにあたって、メッセージ閲覧システム1は、複数の利用者の間で、複数の形式のいずれかの形式の投稿と当該投稿に対する応答とによって交換されるメッセージの閲覧サービスを提供するものである。そして、そのメッセージ閲覧システム1は、画面上で表示される利用者画像(例えばアバター)であって、複数の利用者のそれぞれに対応した利用者画像を記憶する画像記憶部261と、投稿に対して、互いに異なる複数の定型応答文のそれぞれに対応した複数の応答形式で応答する入力指示部251と、利用者画像のモーションを定義したモーション情報を、複数の応答形式のそれぞれに関連付けて記憶するモーション記憶部263を備える。そして、投稿に対して応答した応答形式に対応したモーション情報を選択し、選択したモーション情報に基づいて、応答する利用者の画面上に表示される投稿した投稿利用者に対応した利用者画像のモーションを設定する設定部258を備えている。これにより、先の利用者による投稿に対して別の利用者が応答したとき、当該応答形式に対応したモーションが投稿した利用者(投稿者)に対応した利用者画像に設定される。したがって、グループを構成する複数の利用者のなかで、応答する別の利用者(応答者)からすれば、投稿に対する自己の感情を、投稿の利用者画像のモーションで表現することができるので、サービスの提供を受ける別の利用者に興味を抱かせることが可能になる。
【0158】
第4機能においては、次のような各種の応用例・変形例が可能である。
【0159】
第4機能においても、第3機能の応用例・変形例と同様に「応答」という概念をなくして「投稿」だけとした構成が可能である。第4機能では、モーション情報や絵柄情報は応答の形式に対応しているので、「応答」という概念をなくす場合には、モーション情報や絵柄情報を「投稿」の形式に対応させる。この構成においては、ある「投稿」に対して、選択したアバターへの操作(くるくる、パンチなど)や、当該アバターを表示画面(
図48等参照)において定型文に対応したアイコン281〜284への操作による「投稿」で返答することになる。したがって、この構成では、主体者と当該アバターの仲間との一対一でメッセージが交換される。なお、この構成において、「投稿」として「つぶやき」、「日記」、「フォト」、「チェックイン」のように様々な形式を用いても良いのは、もちろんである。
【0160】
図55は、「投稿」のみの履歴に基づく画面の一例を示す図である。この画面は、「半ズボンT田」という名前の主体者と、「グループA」において「スエナガ」という名前の仲間bとでメッセージが交換される場合の例であって、例えば「投稿」のみとした場合の
図49、
図50または
図51の画面において、当該主体者が「履歴」と付された吹き出し271をタッチ操作したときの例である。
【0161】
図55に示される画面は、基本的には、
図41に示した画面とほぼ同様である。ただし、
図41の画面では、選択されたグループの(主体者を含む)構成員全員による投稿が時間の順で表示されたものであるのに対して、
図55に示される画面では、当該グループの構成員のうち、主体者と選択された仲間との2名による投稿が時間の順で表示される。なお、
図55に示される画面は、「つぶやき」、「フォト」の投稿に、アイコン操作による「イイネ」が投稿として加わった例である。
【0162】
第4機能において「応答」のないサービスを提供するにあたって、メッセージ閲覧システム1は、例えば1対1チャットのように、2人の利用者(主体者と他の利用者)の間で投稿されるメッセージの閲覧サービスを提供するものとなる。すなわち、そのメッセージ閲覧システム1は、画面上で表示される利用者画像(例えばアバター)であって、利用者の利用者画像を記憶する画像記憶部261と、互いに異なる複数の定型文のそれぞれに対応した複数の投稿形式で投稿する入力指示部251と、利用者画像のモーションを定義したモーション情報を、複数の投稿形式のそれぞれに関連付けて記憶するモーション記憶部263を備える。そして、投稿した投稿形式に対応したモーション情報を選択し、選択したモーション情報に基づいて、当該投稿した利用者の画面上に表示される相手の利用者画像のモーションを設定する設定部258を備えている。これにより、先の利用者による投稿に対して別の利用者が投稿したとき、当該投稿形式に対応したモーションが投稿した利用者(投稿者)に対応した利用者画像に設定される。したがって、グループを構成する複数の利用者のなかで、投稿する別の利用者(投稿者)からすれば、投稿に対する自己の感情を、投稿の利用者画像のモーションで表現することができるので、サービスの提供を受ける別の利用者に興味を抱かせることが可能になる。
【0163】
図44では、描画部252、判別部257および設定部258について端末装置20側に設けた構成を例示したが、
図56に示すように、管理サーバ10側に設けた構成としても良い。
この構成では、例えば表示部211で表示すべき画面を管理サーバ10側で作成して、ウェブ画面として端末装置20に送信し、端末装置20がブラウザによって当該ウェブ画面を表示する構成となる。この構成では、モーション記憶部およびキーワード記憶部は、管理サーバ10側の記憶部105に記憶される。また、この構成において、管理サーバ10側の判別部257は、管理部152を介してキーワード記憶部にアクセスし、設定部258は、同様に管理部152を介してモーション記憶部にアクセスする。なお、この構成では、時間情報の取得は、管理サーバ10側のRTC106が用いられる。この構成によれば、端末装置20側に、モーション情報の設定や、アバターの描画処理などが不要となるので、端末装置20側での負担を軽減することができる。
【0164】
また、
図44では、当該端末装置20側で画像記憶部261およびモーション記憶部263が構築されたが、これらの記憶部については、メッセージ閲覧システム1において管理サーバ10や端末装置20からアクセス可能であれば、管理サーバ10や端末装置20以外の外部サーバに構築されても良い。
第4機能のサービスの提供にあたって、
図44に示されるように画像記憶部が端末装置20に構築される場合には、描画部252が画像参照部として機能し、
図56に示されるように画像記憶部が管理サーバ10に構築される場合には、管理部152が画像参照部として機能する。なお、特に図示しないが、画像記憶部が外部サーバに構築される場合には、描画部252、管理部152または別途の機能ブロックのいずれかが画像参照部として機能する。
同様に、
図44に示されるようにモーション記憶部が端末装置20に構築される場合には、設定部258がモーション参照部として機能し、
図56に示されるようにモーション記憶部が管理サーバ10に構築される場合には、管理部152がモーション参照部として機能する。なお、特に図示しないが、モーション記憶部が外部サーバに構築される場合には、設定部258、管理部152または別途の機能ブロックのいずれかがモーション参照部として機能する。
【0165】
このように、各機能ブロックについて、管理サーバ10側に構築されるか、端末装置20側に構築されるかについては、任意である。さらにいえば、上記第1機能から第4機能までの表示が、結果的に、主体者が操作する端末装置20の表示部211に上述した表示されるのであれば、各機能ブロックについて管理サーバ10側に構築されるか、端末装置20側に構築されるかについては、問わないと考える。
【0166】
なお、第1機能から第4機能までのサービスは、主に描画部252による表示部211の表示画面によって利用者に提供されるので、描画部252および表示部211がサービス提供部として機能する。
【0167】
実施形態では、SNSサーバ50におけるSNSに登録している会員のうち、一部の利用者が第1機能から第4機能までのサービスを受けるとして説明したが、本発明は、これに限られない。例えば、SNSにおける登録会員同士の交流の場において第1機能、すなわちグループの登録、編集、表示等にかかるサービスを提供する一方で、SNSにおける登録会員のうち、所定の手続きをした利用者に対しメッセージの投稿、応答の閲覧サービスを提供して、これらの投稿、応答に応じて第2機能から第4機能までのいずれか若しくは全部のサービスを第2サービスとして提供する構成としても良い。
このような構成にあっては、SNSにおいて多数のグループが形成されるとともに、あるグループを構成する会員のうち、所定の手続きをした複数の利用者同士でメッセージの閲覧サービスが提供される。このとき、グループを構成する会員でメッセージの閲覧が可能となるのは、所定の手続きをした利用者であり、主体者の意志とは無関係である。このため、利用者に対応したアバターを当該利用者の投稿や応答に応じた配置で表示する場合に、端末装置で表示するには多すぎる状況も発生し得る。
そこで、このような構成において、割当部254は、あるグループを構成する会員でメッセージの閲覧可能な複数の利用者のうち、所定の選定条件を満たす例えば9名を、ステップSb13で主体者とともに特定利用者として選定し、当該特定利用者のアバターを投稿や応答に応じて配置しても良い。
なお、所定の選定条件の例としては、複数の利用者のうち、最新に投稿/応答した者の上位9名以内であることや、投稿数/応答数が多い上位9名以内であることなどが挙げられる。このような選定条件を導入したとき、例えば主体者以外のアバターは、その時々の状況に応じて変化することになる。また、所定の選定条件の他の例としては、主体者に予め選択された利用者であることなどが挙げられる。
【0168】
<付記>
上述した実施形態や、応用・変形の態様からは、ある利用者に対して別の利用者が応答する場合であっても、当該別の利用者に興味を抱かせる技術を提供する、という観点より、以下の発明が把握される。
【0169】
すなわち、複数の利用者の間で、投稿と当該投稿に対する応答とによって交換されるメッセージの閲覧サービスを提供するメッセージ閲覧システム(1)であって、画面上で表示される利用者画像であって、前記複数の利用者のそれぞれに対応した利用者画像を記憶する画像記憶部(261)と、投稿に対して、互いに異なる複数の定型応答文のそれぞれに対応した複数の応答形式で応答する入力指示部(251)と、前記利用者画像のモーションを定義したモーション情報を、前記複数の応答形式のそれぞれに関連付けて記憶するモーション記憶部(263)と、投稿に対して応答した応答形式に対応したモーション情報を選択し、選択したモーション情報に基づいて、応答する利用者の画面上に表示される投稿した投稿利用者に対応した利用者画像のモーションを設定する設定部(258)と、を備えるメッセージ閲覧システム(1)が把握される。
【0170】
このメッセージ閲覧システム(1)において、画面上に表示する利用者画像に付加して表示する絵柄画像を定義した絵柄情報を、前記複数の応答形式のそれぞれに関連付けて記憶する絵柄記憶部(264)を有し、前記設定部(258)は、応答形式に対応したモーション情報および絵柄情報を選択し、選択したモーション情報および絵柄情報に基づいて、前記投稿利用者に対応した利用者画像のモーションおよび絵柄画像を設定する構成としても良い。
【0171】
また、本発明において、前記設定部(258)は、前記投稿利用者が自身の投稿に対する応答を受けた場合、当該応答の応答形式に対応したモーション情報を選択し、選択したモーション情報に基づいて、投稿利用者に対応した利用者画像のモーションを設定しても良い。
ここで、前記設定部(258)は、前記自身の投稿に対する応答が複数ある場合に、当該複数の応答のそれぞれの応答形式に対応した複数のモーション情報に基づいて、択一的または順番的に選択したモーション情報にしたがって、投稿利用者に対応した利用者画像のモーションを設定しても良い。
【0172】
上記構成において、前記設定部(258)は、投稿利用者が自身の投稿に対する応答を受けた場合、当該応答の応答形式に対応した絵柄情報を選択し、選択した絵柄情報に基づいて、投稿利用者に対応した利用者画像に絵柄画像を設定する態様としても良い。
この態様において、前記設定部(258)は、前記自身の投稿に対する応答が複数ある場合に、当該複数の応答のそれぞれの応答形式に対応した複数の絵柄情報に基づいて、択一的または順番的に選択した絵柄情報にしたがって、投稿利用者に対応した利用者画像に絵柄画像を設定しても良い。
【0173】
本発明において、前記複数の応答形式の全部または一部のそれぞれは、互いに異なる定型応答文に対応した操作ボタンの種類に対応付けられていても良い。
また、前記複数の応答形式の全部または一部のそれぞれは、互いに異なる定型応答文に対応した、画面上に表示された利用者画像に対する指のタッチまたは指の移動軌跡の種類に対応付けられていても良い。
【0174】
把握される発明としては、メッセージ閲覧システム(1)のみならず、当該システム(1)を構成するサーバ(10)や、当該サーバ(10)の制御方法、コンピュータを当該サーバ(10)として機能させるプログラムとして概念することができるし、また、当該システム(1)を構成する端末装置(20)や、当該端末装置(20)の制御方法、コンピュータを当該端末装置(20)として機能させるプログラムとして概念することができる。