実施の形態として提案する情報処理システムは、送信側ユーザ(発信者)により何らかの開示条件が付されたメッセージを受信側ユーザ(宛先として指定された受取人)へ配信する。そして、開示条件が満たされた場合にメッセージの内容を受信側ユーザに開示するメッセージ交換サービスを提供する。言わば、メッセージの配信予約サービスを提供する。開示条件は、受信側ユーザに対するメッセージの開示を許可する条件であり、言い換えれば、受信側ユーザによるメッセージの閲覧を許可する条件である。例えば、開示日時やタイミングを規定するものである。開示条件が付されたメッセージは、将来時点において閲覧可能となるタイムカプセルと言える。
実施の形態のメッセージ交換サービスでは、開示条件が満たされてメッセージの内容を受信側ユーザへ開示する前に、現在はメッセージが開示されないが将来開示される旨を示唆する予告を受信側ユーザへ提示する。「メッセージ」は、電子メールデータやプレーンテキスト、所定フォーマットの文書データ、音声、画像、動画等、様々な公知の形態を含む。また、実施の形態のメッセージ交換サービスの仕組みは、様々な情報処理システム・サービスに適用可能である。例えば、電子メールシステム、インスタントメッセージサービス、ショートメッセージサービス、マルチメディアメッセージングサービスに適用することができる。
(第1の実施の形態)
図1は、第1の実施の形態のメッセージ交換システムの構成を示す。メッセージ交換システム10は、ユーザ端末12で総称される複数のユーザ端末12a、12b、12c、12dと、メッセージ配信サーバ14を備える。ユーザ端末12とメッセージ配信サーバ14は、LAN・WAN・インターネット等を含む通信網16を介して接続される。
ユーザ端末12は、メッセージ交換サービスを利用するユーザにより操作される情報処理装置である。ユーザ端末12は、様々な形態が想定され、例えばPC、タブレット端末、スマートフォン、フィーチャーフォンであってもよい。メッセージ配信サーバ14は、メッセージ交換サービスを提供し、ユーザ端末12間でメッセージを中継する情報処理装置である。メッセージ交換システム10が電子メールシステムとして実現される場合、メッセージ配信サーバ14は、メールサーバとして実装されてもよい。また、後述するユーザ端末12のメッセージ交換アプリケーション100は、電子メールクライアントアプリケーション(いわゆるメーラー)として実装されてもよい。
図2は、図1のユーザ端末12の機能構成を示すブロック図である。ユーザ端末12は、インタフェース部20、メッセージ送信処理部22、メッセージ受信処理部24を備える。本明細書のブロック図で示す各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
インタフェース部20は、ユーザとユーザ端末12、ユーザ端末12と外部装置とのインタフェース機能を提供する。インタフェース部20は、操作検出部30、表示制御部32、通信部34を含む。操作検出部30は、キーボードやマウス等の入力装置に対するユーザの操作入力を検出し、その操作内容を他の機能ブロックへ通知する。メッセージ送信処理部22およびメッセージ受信処理部24は、操作検出部30を介して、ユーザが入力した操作を受け付ける。
表示制御部32は、メッセージ送信処理部22およびメッセージ受信処理部24から出力されたデータを、不図示のディスプレイドライバを介してディスプレイに表示させる。メッセージ送信処理部22およびメッセージ受信処理部24は、表示制御部32を介して、テキストや画像等の各種コンテンツをディスプレイに表示させる。通信部34は、所定のプロトコル(HTTPやSMTP、POP等)にしたがって外部装置と通信する。メッセージ送信処理部22およびメッセージ受信処理部24は、通信部34を介して、各種データをメッセージ配信サーバ14と送受する。
メッセージ送信処理部22は、メッセージの送信と、送信したメッセージの閲覧に関するデータ処理を実行する。メッセージ受信処理部24は、メッセージの受信と、受信したメッセージの閲覧に関するデータ処理を実行する。メッセージ送信処理部22およびメッセージ受信処理部24の機能は、ユーザ端末12のOSやウェブブラウザ等の機能の少なくとも一部を使用して実現してもよい。
実装の一例として、メッセージ送信処理部22およびメッセージ受信処理部24の機能を包含するメッセージ交換アプリケーション100がユーザ端末12のストレージにインストールされてよい。ユーザがユーザ端末12においてメッセージ交換アプリケーション100を起動すると、ユーザ端末12のCPUが、メッセージ送信処理部22およびメッセージ受信処理部24の各機能ブロックに対応するプログラムモジュールをメインメモリに読み出して実行することにより、メッセージ送信処理部22およびメッセージ受信処理部24の機能が発揮されてよい。各種データの保持部は、ストレージやメインメモリ等の所定の記憶装置により実現されてよい。
メッセージ送信処理部22は、送信メッセージ保持部40、メッセージ作成部42、メッセージ送信部48、送信メッセージ記録部50、ステータス更新部51、送信トレイ表示部52、送信メッセージ表示部54を含む。メッセージ送信処理部22の説明において特に断らない場合、「ユーザ」は自装置のユーザであり、メッセージ送信者を意味する。
送信メッセージ保持部40は、自装置からメッセージ配信サーバ14へ送信した1つ以上のメッセージについて、各メッセージの本文と各種属性情報を保持する。送信メッセージ保持部40は、送信メッセージの履歴を保持するとも言える。
図3は、送信メッセージ保持部40に保持されるデータの構成を示す。ID欄には、メッセージをユニークに特定可能なメッセージIDが格納される。メッセージ欄には、メッセージの本文が格納される。宛先・送信元の識別情報(メールアドレス等)やタイトルがさらに格納されてもよい。エラーフラグ欄には、メッセージの送信においてエラーが発生したか(値1)、またはエラー未発生で正常に送信できたか(値0)を示す値が格納される。このエラーには、メッセージ配信サーバ14によるメッセージ中継時のエラーであり、メッセージ配信サーバ14から通知されたエラーも含まれる。
カプセルフラグ欄には、開示条件が付された言わばカプセルメッセージか(値1)、開示条件が付与されない言わば通常のメッセージか(値0)を示す値が格納される。開示条件欄には、ユーザがメッセージに付与した開示条件が格納される。開示フラグ欄には、開示条件が付されたメッセージが受信側ユーザに未開示か(値0)、もしくは開示済か(値1)を示す値が格納される。カプセルフラグが「0」であれば、開示条件欄および開示フラグ欄のデータは未設定(図の「−」)となる。
開示条件には、その充足有無をシステムが自動で判別可能な様々な条件、また、その充足有無を人手により確認可能な様々な条件が指定される。例えば、日時条件として、特定の年月日、日時、期間(送信後何日〜何年)、消息不明時、消息不明が確認された後の特定の期間(日付)、死亡確認時、死亡が確認された後の特定の期間(日付)が指定されてもよい。例えば、開示条件として死亡時を指定する場合、もしものときの遺言の配信を予約することになる。また、ユーザが予め記念日と日付の対応関係をメッセージ配信サーバ14に登録した場合、記念日(例えば家族の誕生日や結婚記念日、三回忌)の名称で指定されてもよい。
さらにまた、開示条件として特定の気象条件(雨、気温30度以上等)が指定されてもよい。この開示条件は販売促進メッセージの提供に好適である。例えば、タクシー会社の広告メッセージの配信予約において、開示条件として「雨」が指定されてもよい。また、ビール会社の広告メッセージの配信予約において、開示条件として「気温30度以上」が指定されてもよい。
図2に戻り、メッセージ作成部42は、メッセージの作成に関する処理を実行する。メッセージ作成部42は、作成画面表示部44、開示条件付与部46を含む。作成画面表示部44は、開示条件設定エリアを含むメッセージ作成画面をディスプレイに表示させる。メッセージ作成画面には、メッセージの受信者側ユーザの識別情報(例えば宛先情報であり、宛先メールアドレス等)やメッセージのタイトル、本文が入力される。開示条件設定エリアには、上述したように様々な態様の開示条件が任意で入力される。
メッセージ作成部42は、メッセージ作成画面に入力されたデータにしたがって、宛先情報やメッセージのタイトル、本文を含む送信用のメッセージデータを生成する。開示条件付与部46は、メッセージ作成画面の開示条件設定エリアに開示条件が入力された場合に、その開示条件を示す開示条件データをメッセージデータに付加する。
メッセージ送信部48は、メッセージ作成部42により生成されたメッセージデータをメッセージ配信サーバ14へ送信する。このメッセージデータは、送信側ユーザ(送信元ユーザ)の識別情報と、受信側ユーザ(宛先ユーザ)の識別情報を含む。識別情報は、公知のIDやアドレスでよく、例えばメールアドレスでもよい。
送信メッセージ記録部50は、メッセージ送信部48により送信されたメッセージデータを送信メッセージ保持部40に格納し、エラーフラグ、カプセルフラグ、開示条件、開示フラグの値をメッセージデータにしたがって設定する。例えば、エラーフラグの初期値は「0」とする。また、メッセージデータに開示条件データが付加されていた場合、カプセルフラグを「1」として開示条件を記録する。開示条件が付加されたメッセージの送信時の開示フラグは「0(未開示)」とする。
ステータス更新部51は、メッセージ配信サーバ14からのメッセージ配信エラーの通知が後述のメッセージ受信部58で受信されると、配信エラーとなったメッセージのエラーフラグを「1」に更新する。またステータス更新部51は、メッセージ配信サーバ14から、開示条件付きのメッセージの開示条件が満たされて、当該メッセージを開示した旨の通知を受け付けると、当該メッセージの開示フラグを「1(開示済)」に変更する。
送信トレイ表示部52は、自装置からメッセージ配信サーバ14へ送信したメッセージの一覧画面である送信トレイ画面をディスプレイに表示させる。言い換えれば、自装置から他のユーザ端末12宛に送信したメッセージの履歴を表示させる。具体的には、送信トレイ表示部52は、送信メッセージ保持部40に格納されたデータを参照して、送信メッセージの種類や送信状況に応じた態様で各メッセージのタイトルを並べた送信トレイ画面を表示させる。送信トレイ表示部52は、少なくとも、開示条件を付加して送信したメッセージと、開示条件を付加せず送信したメッセージを異なる態様で表示させる。
例えば、送信トレイ表示部52は、開示条件が付加された旨を示す所定の形状・模様・色彩のシンボルを、開示条件が付加されたメッセージのみに設定することで、他の種類のメッセージと区別可能に表示させてもよい。また送信トレイ表示部52は、メッセージのタイトルや本文について、その文字サイズ・フォント・色等をメッセージの種類・属性ごとに変更してもよく、開示条件が付加されているか否かに応じて、異なる文字サイズ・フォント・色を設定してもよい。
実施の形態では、送信トレイ表示部52は、送信トレイ画面において、(1)開示条件が付与され、現在未開示のメッセージと、(2)送信エラーとなったメッセージを、「未送信メッセージ」グループを示す第1の態様で表示させる。その一方、送信トレイ画面において、(3)開示条件が付与されず、送信エラー未発生のメッセージ、言わば正常な送信済メッセージ、(4)開示条件が付与され、現在開示済のメッセージを、第1の態様とは異なり「送信済メッセージ」グループを示す第2の態様で表示させる。
例えば、「未送信メッセージ」グループのメッセージは、そのタイトルをボールド体の黒色文字で表示させる一方、「送信済メッセージ」グループのメッセージは、そのタイトルを通常フォントの黒色文字で表示させてもよい。また、グループ毎に異なる形状や色彩のシンボルを各メッセージのタイトルに付して表示させてもよい。送信トレイ画面の表示例は後述する。
送信トレイ表示部52は、エラーフラグ=0、カプセルフラグ=1、開示フラグ=0のメッセージを(1)のメッセージとして識別する。また、エラーフラグ=1のメッセージを(2)のメッセージとして識別する。また、エラーフラグ=0、カプセルフラグ=0のメッセージを(3)のメッセージとして識別する。また、エラーフラグ=0、カプセルフラグ=1、開示フラグ=1のメッセージを(4)のメッセージとして識別する。なお送信トレイ表示部52は、公知の方法により(5)作成中のメッセージを識別し、「未送信メッセージ」を示す第1の態様で送信トレイ画面に表示させてもよい。
変形例として、送信トレイ表示部52は、送信トレイ画面において、(1)開示条件が付与され、現在未開示のメッセージを「予約メッセージ」グループを示す第1の態様で表示させてもよい。その一方、送信トレイ画面において、(2)送信エラーとなったメッセージ、(3)開示条件が付与されず、送信エラー未発生のメッセージ、言わば正常な送信済メッセージ、(4)開示条件が付与され、現在開示済のメッセージを、第1の態様とは異なり「送信済メッセージ」グループを示す第2の態様で表示させてもよい。
このように、実施の形態と変形例のいずれの場合も、(3)のメッセージと(4)のメッセージの双方を同じ態様で表示させる。(4)の開示条件は既に満たされており、閲覧制限は解除されているため、ユーザにとって通常の送信済メッセージと区別する必要がなく、むしろ通常の送信済メッセージと同じ態様で表示させた方がユーザにとって利便性が高いからである。
送信メッセージ表示部54は、送信トレイ画面においてユーザが選択したメッセージのデータを送信メッセージ保持部40から取得し、ディスプレイに表示させる。送信メッセージ保持部40に開示条件も格納されている場合、その開示条件も表示させる。
メッセージ受信処理部24は、受信メッセージ保持部56と、メッセージ受信部58と、受信メッセージ記録部60と、ステータス更新部62と、受信トレイ表示部64と、受信メッセージ表示部66を含む。メッセージ受信処理部24の説明において特に断らない場合、「ユーザ」は自装置のユーザであり、メッセージ受信者を意味する。
受信メッセージ保持部56は、メッセージ配信サーバ14から受信した1つ以上のメッセージについて、各メッセージの本文と各種属性情報を保持する。受信メッセージ保持部56は、受信メッセージの履歴を保持するとも言える。
図4は、受信メッセージ保持部56に保持されるデータの構成を示す。本メッセージ欄には、受信メッセージの本文が格納される。宛先・送信元の識別情報(メールアドレス等)やタイトルがさらに格納されてもよい。予告メッセージ欄には、受信メッセージに付加された予告メッセージが格納される。実施の形態では、開示条件が付加されたメッセージに対して、メッセージ配信サーバ14が予告メッセージを設定する。予告メッセージは、メッセージの本文が、現在は開示されないものの将来開示される旨を示唆する情報であり、文字列や画像等、任意の形式であってよい。未読フラグ欄には、受信者側ユーザによるメッセージの閲覧状況を示す値が格納される。具体的には、閲覧済=0、未読=1が格納されることとする。
カプセルフラグ欄の意味は図3と同じである。開示フラグ欄には、メッセージの開示・閲覧が現在禁止されているか(値0)、メッセージの開示・閲覧が現在許可されているか(値1)を示す値が格納される。開示条件が付されたメッセージの受信時には、当該メッセージの開示フラグは「0」に設定される。カプセルフラグが0(すなわち開示条件が付与されていないメッセージ)の場合、開示フラグの値は未設定「−」となる。
図2に戻り、メッセージ受信部58は、メッセージ配信サーバ14から送信されたユーザ宛のメッセージを受信する。メッセージ受信部58は、ユーザの操作に応じて、または所定の時間間隔にて自動で、ユーザ宛のメッセージの提供をメッセージ配信サーバ14へ要求し、メッセージ配信サーバ14に蓄積されたユーザ宛のメッセージをメッセージ配信サーバ14から取得してもよい。
受信メッセージ記録部60は、メッセージ受信部58で受信されたメッセージデータを受信メッセージ保持部56へ格納する。メッセージ配信サーバ14から受信したメッセージデータは、ID、本メッセージ、予告メッセージ、カプセルフラグ、開示フラグを含む。受信メッセージ記録部60は、メッセージの未読フラグを「1」に設定する。
ステータス更新部62は、開示条件付きのメッセージについて、その開示条件が満たされたことを示す情報をメッセージ配信サーバ14から受信し、当該メッセージの開示フラグを「1(開示・閲覧可能)」に変更する。またステータス更新部62は、受信メッセージ表示部66によりディスプレイに表示された、言い換えれば、ユーザにより閲覧されたメッセージの未読フラグが「1」である場合に、当該未読フラグを「0」に変更する。
受信トレイ表示部64は、自装置がメッセージ配信サーバ14から受信したメッセージの一覧画面である受信トレイ画面をディスプレイに表示させる。受信トレイ表示部64は、受信メッセージ保持部56に格納されたデータを参照して、受信メッセージの種類や閲覧状況に応じた態様で各メッセージを一覧表示させる。少なくとも受信トレイ表示部64は、開示条件が付加されたメッセージと、開示条件なしのメッセージを、送信トレイ表示部52の説明で既述したように異なる態様で表示させる。
実施の形態では、受信トレイ表示部64は、受信トレイ画面において、(1)通常未読メッセージと、(2)カプセル解除未読メッセージと、(3)カプセル化未読メッセージと、(4)通常既読メッセージ、(5)カプセル解除既読メッセージのそれぞれを、互いに異なるグループを示す異なる態様で表示させる。(1)は、開示条件が付加されていない未読状態のメッセージである。(2)は、開示条件が付され、その開示条件が充足して閲覧可能になったメッセージのうち未読状態のメッセージである。(3)は、開示条件が付され、その開示条件が未充足であるため閲覧が許可されないメッセージである。(4)は、開示条件が付加されていない既読状態のメッセージである。(5)は、開示条件が付され、その開示条件が充足して閲覧可能になったメッセージのうち既読状態のメッセージである。受信トレイ画面の表示例は後述する。
受信トレイ表示部64は、未読フラグ=1、カプセルフラグ=0のメッセージを(1)のメッセージとして識別し、未読フラグ=1、カプセルフラグ=1、開示フラグ=1のメッセージを(2)のメッセージとして識別する。また、未読フラグ=1、カプセルフラグ=1、開示フラグ=0のメッセージを(3)のメッセージとして識別し、未読フラグ=0、カプセルフラグ=0のメッセージを(4)のメッセージとして識別する。また、未読フラグ=0、カプセルフラグ=1、開示フラグ=1のメッセージを(5)のメッセージとして識別する。
変形例として、受信トレイ表示部64は、未読フラグ=1、カプセルフラグ=0のメッセージと、未読フラグ=1、カプセルフラグ=1、開示フラグ=1のメッセージの両方を同じ未読メッセージとして識別してもよい。すなわち、上記の(1)通常未読メッセージと(2)カプセル解除未読メッセージを同じ態様で表示させてもよく、言い換えれば、開示条件が付されたメッセージを、その開示条件が満たされて閲覧可能になった場合は、開示条件が付されていない通常の未読メッセージと同じ態様で表示させてもよい。同様に、未読フラグ=0、カプセルフラグ=0のメッセージと、未読フラグ=0、カプセルフラグ=1、開示フラグ=1のメッセージの両方を同じ既読メッセージとして識別してもよい。すなわち、上記の(4)通常既読メッセージと(5)カプセル解除既読メッセージを同じ態様で表示させてもよい。
受信メッセージ表示部66は、受信メッセージ画面をディスプレイに表示させる。受信メッセージ表示部66は、受信トレイ画面においてユーザが選択したメッセージ(以下、「被選択メッセージ」と呼ぶ。)について、本メッセージ(例えば本文、タイトル)、送信元情報等の表示対象データを受信メッセージ保持部56から取得し、これらのデータを受信メッセージ画面110に表示させる。受信メッセージ表示部66は、被選択メッセージのカプセルフラグが「0」の場合、すなわち、被選択メッセージに開示条件が付されていないとき、被選択メッセージの内容をディスプレイに表示させる。同様に、被選択メッセージのカプセルフラグが「1」で、かつ開示フラグが「1」である場合、すなわち、被選択メッセージの開示条件が満たされている場合、被選択メッセージの内容をディスプレイに表示させる。受信メッセージ表示部66は、本メッセージの内容を表示したメッセージについて、その未読フラグを「0」に更新する。
その一方、受信メッセージ表示部66は、被選択メッセージのカプセルフラグが「1」で、開示フラグが「0」の場合、すなわち、被選択メッセージの開示条件が満たされていない場合、その被選択メッセージの本メッセージ(例えば本文、タイトル)を画面に表示させない。その代わりに、被選択メッセージが、現在は開示されないが将来開示される旨を示唆する予告メッセージをディスプレイに表示させる。受信メッセージ画面の表示例は後述する。
図5は、図1のメッセージ配信サーバ14の機能構成を示すブロック図である。メッセージ配信サーバ14は、通信部70、メッセージ中継部72を備える。通信部70は、所定のプロトコルにしたがって外部装置と通信する。メッセージ中継部72は、通信部34を介して、各種データをユーザ端末12と送受する。メッセージ中継部72は、あるユーザ端末12から送信されたメッセージを、宛先として指定されたユーザのユーザ端末12へ中継するためのデータ処理を実行する。
メッセージ中継部72は、メッセージ保持部80、メッセージ受信部82、判定主体決定部85、開示判定部86、メッセージ送信部88、開示通知部92を含む。
メッセージ保持部80は、メッセージ受信部82が受信したメッセージの本文と各種属性情報を保持する。メッセージ保持部80は、ユーザ端末12間でやりとりされるメッセージの履歴を保持するとも言える。図6は、メッセージ保持部80に保持されるデータの構成を示す。図6の各項目の意味は、図3または図4で説明したとおりである。
図5に戻り、メッセージ受信部82は、ユーザ端末12から送信されたメッセージデータを受信する。メッセージ受信部82のメッセージ記録部84は、受信したメッセージデータをメッセージ保持部80に格納する。メッセージ記録部84は、受信したメッセージデータで指定されたIDと本メッセージをメッセージ保持部80へ格納する。受信したメッセージデータが開示条件を含まなければ、カプセルフラグを「0」とし、開示フラグは設定しない。
その一方、受信したメッセージデータが開示条件データを含む場合、メッセージ記録部84は、開示条件欄に開示条件データを格納するとともに、カプセルフラグを「1」、開示フラグを「0」に設定する。さらにメッセージ記録部84は、開示条件に応じた予告メッセージを作成し、予告メッセージ欄に格納する。このとき、開示条件そのものを予告メッセージとしてもよい。また、開示条件として定められた日付や開示タイミングを示す文字列に、予め定められた修飾文字列、例えば「に開封可能になります」等を加えた文字列を予告メッセージとして記録してもよい。
判定主体決定部85は、メッセージ受信部82が受信したメッセージデータごとに、メッセージの送信者により入力されたメッセージ本文や開示条件等に応じて、各メッセージに付された開示条件の充足状況を判定すべき主体を決定する。メッセージ配信サーバ14とユーザ端末12(送信者端末または受信者端末)のいずれも開示条件充足有無の判定主体となり得る。メッセージ送信者は、メッセージ作成画面において判定主体とする装置を指定入力し、判定主体決定部85は、送信者が指定した装置を判定主体として決定してもよい。また判定主体決定部85は、上記の日時条件や気象条件が開示条件として指定された場合に、メッセージ配信サーバ14を判定主体として自律的に決定してもよい。実施の形態では、メッセージ配信サーバ14自身を判定主体として決定することとし、他装置を判定主体とする場合については変形例として後述する。
開示判定部86は、メッセージ保持部80に格納されたメッセージのうち、カプセルフラグが「1」、開示フラグが「0」のメッセージ、すなわち、開示条件がそれまで未充足であったメッセージついて、現時点で開示条件が充足されたか否かを定期的に判定する。開示条件が充足されたと判定したメッセージがある場合、そのメッセージの開示フラグを「1」に変更する。
例えば、開示条件が特定の日時に到達することであった場合、開示判定部86は、現在日時(システム日時等)が、開示条件が定める日時を経過した場合に開示条件が充足されたと判定する。また、開示条件が記念日(家族の誕生日や結婚記念日、三回忌)の名称で指定された場合、開示判定部86は、送信側ユーザにより予め登録されて、所定のテーブルに格納されたユーザの記念日と日付の対応関係を参照し、記念日を日付で置き換えた上で、開示条件の充足有無を判定する。
また、開示条件が特定人物(例えば送信側ユーザ)の死亡である場合、公知の方法により特定人物が死亡したか否かを判定し、死亡を確認した場合に開示条件が充足されたと判定する。例えば、本発明者が「特開2013−101549号公報」で提案している技術を使用してもよい。本発明者は、この特許文献の中で、本人へメール等で生存確認し、それが途絶えたら、本人が予め自分の電話帳の中で指定する人(エンディングパートナー)に死亡確認する技術を提案している。また、一部類似するが、特定人物に関して予め定められた連絡先(例えば携帯端末等)に生存確認依頼の情報を送信し、その送信においてエラーが発生したことや、所定の応答がなかった場合に、特定人物の死亡が確認されたと判定してもよい。また、担当者が特定人物の死亡を電話連絡等、人手で確認し、その確認結果をメッセージ配信サーバ14へ入力することにより、開示判定部86が死亡確認結果を取得してもよい。消息不明の確認についても死亡確認と同様の方法で実現されてよい。
また、開示条件が特定の気象を指定する場合、外部の気象情報提供サーバから当日の気象情報を取得し、当日の気象情報が特定の気象に整合する場合に開示条件が充足されたと判定する。一部既述したように、開示条件の充足有無の判定は、メッセージ配信サーバ14が他の装置と適宜連携して自動で実行してもよい。また、担当者が人手により確認し、その確認結果がメッセージ配信サーバ14に記録され、開示判定部86がその確認結果を参照することにより実現してもよい。
メッセージ送信部88は、送信側ユーザのユーザ端末12から送信され、メッセージ受信部82が受信したメッセージを、宛先として指定された受信側ユーザのユーザ端末12へ送信する。具体的には、メッセージ保持部80に新たなメッセージデータが記録されたことを検出した場合に、そのメッセージIDと本メッセージを取得し、ユーザ端末12へプッシュ送信する。ユーザ端末12からの要求に応じてメッセージを送信してもよく、所定の時間間隔で定期的にメッセージを送信してもよい。
メッセージ送信部88のカプセルメッセージ送信部90は、送信側ユーザのユーザ端末12から送信されたメッセージのうち、開示条件が付されたメッセージをユーザ端末12へ送信する。具体的には、メッセージID、本メッセージ、予告メッセージ、カプセルフラグ、開示フラグをメッセージ保持部80から取得し、ユーザ端末12へ送信する。このときのカプセルフラグは「1」であり、開示条件がすでに満たされていれば開示フラグは「1」、満たされていなければ開示フラグは「0」である。
開示通知部92は、開示条件が付されたメッセージついて、その開示条件が満たされて、受信側ユーザが閲覧可能になった旨をユーザ端末12へプッシュ通知する。具体的には、開示通知部92は、メッセージ保持部80を監視し、開示判定部86により開示フラグが「0」から「1」へ変更されたメッセージを検出する。開示通知部92は、開示フラグが「0」から「1」へ変更されたメッセージについて、そのメッセージIDと、開示フラグ変更の旨(言い換えればメッセージの開示を許可する旨)を示す情報を、宛先ユーザの識別情報により特定される受信側ユーザのユーザ端末12へ送信する。また、同じ情報を、送信元ユーザの識別情報により特定される送信側ユーザのユーザ端末12へ送信する。
以上の構成によるメッセージ交換システム10の動作を、受信メッセージの表示画面を示す図7を参照しつつ説明する。ここでは、送信側ユーザの甲が使用する端末(ユーザ端末12a)から、受信側ユーザの乙が使用する端末(ユーザ端末12b)へ、開示条件付きのメッセージを送信する。すなわち、メッセージの送信側装置をユーザ端末12aとし、受信側装置をユーザ端末12bとする。また、メッセージの内容は2013年12月20日以降に閲覧を許可すべき人事情報とし、開示条件として2013年12月20日に至ることが指定される。すなわち、2013年12月20日以降に閲覧を許可する旨の開示条件がメッセージに付与される。
甲は、ユーザ端末12aにてメッセージ交換アプリケーション100の画面を起動し、その画面でメッセージの作成を選択する。ユーザ端末12aのメッセージ作成部42はメッセージ作成画面を表示させる。甲は、メッセージ作成画面に、乙宛のメッセージを入力し、さらに開示条件を入力する。メッセージ送信部48は、メッセージ作成画面に入力されたメッセージと開示条件を対応づけてメッセージ配信サーバ14へ送信する。送信メッセージ記録部50は、メッセージ配信サーバ14に送信されたメッセージと開示条件を対応づけて送信メッセージ保持部40へ記録する。
甲が、メッセージ交換アプリケーション100の画面で送信トレイを選択すると、送信トレイ表示部52は、送信メッセージの一覧を送信トレイ画面に表示させる。その際、送信トレイ表示部52は、開示条件が付与され、現在受信側ユーザに未開示のメッセージ(上記乙宛のメッセージを含む)と、開示条件が付与されず、受信側ユーザが閲覧可能なメッセージを互いに異なる態様で表示させる。
メッセージ配信サーバ14のメッセージ受信部82は、ユーザ端末12aから送信されたメッセージと開示条件を受信する。メッセージ記録部84は、受信されたメッセージについて、本メッセージ、予告メッセージ「12月20日に開封予定」、開示条件をメッセージ保持部80へ記録する。メッセージ送信部88は、メッセージ受信部82により受信されたメッセージに関する本メッセージと予告メッセージを乙のユーザ端末12bへ送信する。このとき、開示フラグ「0」を付加して送信する。
ユーザ端末12bのメッセージ受信部58は、メッセージ配信サーバ14から送信されたメッセージデータを受信し、受信メッセージ記録部60は、受信されたメッセージデータを受信メッセージ保持部56へ格納する。乙は、メッセージ交換アプリケーション100の画面を起動し、その画面で受信トレイを選択する。受信トレイ表示部64は、受信メッセージの一覧を受信トレイ画面に表示させる。その際、受信トレイ表示部64は、開示条件が付与された未読メッセージ(上記乙宛のメッセージを含む)と、開示条件が付与されていない未読メッセージと、既読メッセージを互いに異なる態様で一覧表示させる。
乙は、受信トレイ画面で閲覧したいメッセージを選択し、受信メッセージ表示部66は、乙により選択されたメッセージを受信メッセージ画面に表示させる。ここでは、開示条件が付与された未読メッセージであり、開示条件が未充足の未読メッセージである上記乙宛のメッセージを選択する。受信メッセージ表示部66は、図7(a)(b)で示すように、受信メッセージ画面110においてメッセージの本文を非表示とする。その代わりに、メッセージの本文が将来時点において閲覧可能になる旨を示唆する予告メッセージ112と予告画像114を表示させる。仮に開示条件が甲の死亡時であれば、「甲がお亡くなりになったときに開封」等の予告メッセージ112を表示させてもよい。また開示条件が気温30度以上であれば、「気温30度以上のときに開封」等の予告メッセージ112を表示させてもよい。
図7(a)は、開示条件の充足まで3日以上要する場合の予告画像114を示しており、この例では12月16日まで亀裂のないカプセル(タマゴ)を表示させる。その一方、図7(b)は、開示条件の充足まで3日未満の場合の予告画像114を示しており、この例では12月17日以降、亀裂のあるカプセルを表示させる。このように、受信メッセージ表示部66は、現在日時から開示条件充足までの期間の長短に応じて予告メッセージ112と予告画像114の内容を変更してもよい。具体的には、現在日時から開示条件充足までの期間の長短を示唆する態様で予告画像114を表示させてもよい。例えば、開示条件充足までの残り期間が短くなるほどカプセルの亀裂が広がっていく態様や、予告メッセージ112や予告画像114の色彩が濃くなっていく態様で表示させてもよい。
このように、予告メッセージ112と予告画像114の表示態様を変更させるために、メッセージ配信サーバ14がユーザ端末12bへ開示条件そのものを提供し、ユーザ端末12bの判定部が開示条件充足までの残り期間の長短を判定してもよい。また、開示条件充足までの残り期間の長短、すなわち、予告メッセージ112と予告画像114を複数段階の態様のうちどの態様で表示させるかをメッセージ配信サーバ14の開示判定部86が判定してもよい。そしてメッセージ配信サーバ14の開示通知部92が、開示判定部86による判定結果をユーザ端末12へ送信し、ユーザ端末12bの受信メッセージ保持部56に記憶させてもよい。
また図7(a)(b)で示すように、受信メッセージ表示部66は、開示条件が充足されるまでの間、メッセージの本来のタイトルも非開示とし、単に甲からメッセージが届いた旨のタイトルに変換し、変換後のタイトルを表示させる。変形例として、乙の事前の心づもりを支援するために、タイトルについては、開示条件が未充足であっても甲が作成したオリジナルの内容を表示させてもよい。なお、送信元のユーザ名は開示条件充足前から開示することで、誰からのメッセージであるかは把握可能とする。
メッセージ配信サーバ14の開示判定部86は、開示条件がそれまで未充足のメッセージについて、現在時点で開示条件が充足された否かを定期的に判定する。ここでは、12月20日に至った場合に、開示判定部86は、甲から乙宛のメッセージの開示条件が充足されたと判定し、その開示フラグを「1」に変更する。開示通知部92は、当該メッセージの開示を許可する旨をユーザ端末12aとユーザ端末12bの双方へ通知する。
ユーザ端末12aのステータス更新部51は、送信メッセージ保持部40に保持された甲から乙宛のメッセージの開示フラグを「1」に変更する。以降、送信トレイ表示部52は、送信トレイ画面において、当該メッセージを、開示条件が付与されず、受信側ユーザが閲覧可能なメッセージと同じ態様で表示させる。
ユーザ端末12bのステータス更新部62は、受信メッセージ保持部56に保持された甲から乙宛のメッセージの開示フラグを「1」に変更する。以降、乙が受信トレイ画面で甲から乙宛のメッセージを選択すると、受信メッセージ表示部66は、図7(c)で示すように、当該メッセージの本文を示す本メッセージ116と、オリジナルのタイトルを受信メッセージ画面110に表示させる。ステータス更新部62は、当該メッセージの未読フラグを「0」に変更し、以降、受信トレイ画面において当該メッセージを既読メッセージとして表示させる。
図8は、受信トレイ表示部64が表示する受信トレイ画面を示す。受信トレイ表示部64は、受信トレイ画面120において、開示条件が付加されていない未読メッセージを、予告画像122なしのボールド体で表示し、開示条件が付加されていない既読メッセージを予告画像122なしの通常フォントで表示させる。その一方、受信トレイ表示部64は、開示条件が付与されたメッセージを、予告画像122を付加した態様で表示させる。同図の予告画像122は図7と同様にカプセルである。開示条件が付加されたメッセージについては、その開示条件(図8では開示日時)をさらに表示させる。
受信トレイ表示部64は、開示条件未充足のメッセージ(カプセルフラグ=1、開示フラグ=0)のうち、開示条件充足までの残り期間が短い(例えば3日未満の)メッセージには亀裂のあるカプセルの画像を付加する。その一方、開示条件までの残り期間が長い(例えば3日以上の)メッセージには亀裂のないカプセルの画像を付加する。
また受信トレイ表示部64は、開示条件充足済の未読メッセージ(未読フラグ=1、カプセルフラグ=1、開示フラグ=1)に、割れたカプセルを示す予告画像122(点滅した状態)を付加する。また開示条件充足済の既読メッセージ(未読フラグ=0、カプセルフラグ=1)に、割れたカプセルを示す予告画像122(点滅なし)を付加する。例えば、カプセルが割れて点滅している未読メッセージ「忘年会のお知らせ」を乙が選択し、受信メッセージ画面で本文を閲覧した場合、以降の受信トレイ画面120では当該メッセージのカプセルの点滅は停止する。このように受信トレイ画面120では、開示条件付きメッセージの演出として、亀裂なしのカプセル→開示日が近づくにつれてカプセルに亀裂が入る→カプセルが割れて点滅する状態→カプセルが割れた状態(点滅なし)を表示する。
メッセージ交換アプリケーション100が起動されたときに、新たに開示条件が充足した(開示フラグが0から1に更新された)メッセージがあれば、メッセージ交換アプリケーション100のトップ画面表示部(不図示)は、アプリケーションのトップ画面においてカプセルが割れるアニメーションを表示させてもよい。アニメーション表示後、受信トレイ表示部64は、カプセルが割れて点滅している当該未読メッセージを含む受信トレイ画面120を表示させてもよい。また受信メッセージ表示部66は、当該未読メッセージの本文を受信メッセージ画面110に表示させてもよい。
このように、メッセージ交換アプリケーション100では、通常のメーラ等と異なり、メッセージ開示までの期間の長短を示唆する演出を表示させる。例えば、メッセージの開示タイミングが近づくと、その旨を示唆する態様で、受信メッセージ画面110および受信トレイ画面120の予告画像を変化させる。これにより、メッセージが開示されるまでの間に受信者の期待感を醸成し、またその期待感を徐々に高めていくことができる。また、新たに開示条件が充足したメッセージの存在をユーザが一目で把握できるよう演出を実行する。新たに閲覧可能になったメッセージの存在を積極的にユーザに示すことにより、当該メッセージの閲覧をユーザに促し、また、開示条件が充足するまでの間の演出で醸成したユーザの期待感をさらに高めることができる。
図9は、送信トレイ表示部52が表示する送信トレイ画面を示す。送信トレイ表示部52は、送信トレイ画面130に送信予定ボタン132と送信済ボタン134を配置する。送信予定ボタン132は、開示条件が付与され、現在受信側ユーザに未開示のメッセージを一覧表示させるボタンである。送信済ボタン134は、開示条件がもともと付与されないメッセージ、および、開示条件が付与されたものの、開示条件が満たされて現在受信側ユーザに開示済のメッセージを一覧表示させるボタンである。図9では、甲が送信予定ボタン132を選択した状態を示している。送信トレイ表示部52は、送信メッセージ保持部40に格納された各メッセージの開示条件を参照し、予告画像122と同様の予告画像136を各メッセージに付加する。すなわち、開示条件充足までの残り期間に応じて予告画像136の態様を変化させる。
また、送信トレイ表示部52は、開示条件付きメッセージの開示条件が満たされて開示フラグが「1」になった場合、当該メッセージを、送信済ボタン134選択時の画面で表示させるよう切替える。送信トレイ表示部52は、開示条件が満たされて開示フラグが「1」になったメッセージを、開示条件が付されないメッセージとは異なる態様で表示させてもよい。例えば、図8と同様に、割れたカプセルを示す予告画像136を付加して表示させてもよい。なお、図9で示した送信予定ボタン132選択時の送信トレイ画面130で表示されるメッセージは、後述の第1の変形例で示す編集・改変可能なメッセージとなる。
実施の形態のメッセージ交換システム10によると、メールを書いて保存したときと将来それを配信するときの間に時間差があるという点に着目した、利便性の高いメッセージ配信サービスを提供できる。例えば、メッセージの受信側ユーザに対して、メッセージの内容を実際に開示する前に、将来時点で開示予定である旨を予告する。言い換えれば、将来時点で開示されるメッセージが届いた事実を通知する。これにより、メッセージが将来配信される相手に期待感をもたせ、ないし準備をさせることができる。
また、送信メッセージの一覧表示画面において、開示条件付きのメッセージであり、現在受信側ユーザに非開示のメッセージを、開示条件なしのメッセージおよび受信側ユーザに開示済のメッセージと異なる態様で表示させる。これにより、開示条件付きのメッセージについて、受信側ユーザによる閲覧状況を送信側ユーザが容易に把握することを支援でき、その状況を踏まえたアクションを送信側ユーザが実施することを支援できる。
また、受信メッセージの一覧表示画面において、開示条件付きのメッセージであり、現在受信側ユーザに非開示のメッセージを、開示条件なしのメッセージおよび受信側ユーザに開示済のメッセージと異なる態様で表示させる。これにより、開示条件付きのメッセージの存在を受信側ユーザが容易に把握することを支援でき、事前の心づもりや、開示条件付きのメッセージが届いている状況を踏まえたアクションを受信側ユーザが実施することを支援できる。
(第2の実施の形態)
上記第1の実施の形態のメッセージ配信サーバ14は、開示条件付きのメッセージを受け付けた際に、予告メッセージとともに本メッセージを宛先のユーザ端末12へ送信した。これに対し、第2の実施の形態のメッセージ配信サーバ14は、開示条件が満たされるまではメッセージ本文の配信を抑制して予告メッセージのみを配信する。第2の実施の形態のメッセージ交換システム10、ユーザ端末12、メッセージ配信サーバ14の構成は、第1の実施の形態と同様である。
具体的には、メッセージ配信サーバ14のカプセルメッセージ送信部90は、開示条件付きのメッセージを受け付けた際に、予告メッセージをユーザ端末12へ送信する一方、本メッセージをユーザ端末12へ送信することを抑制して、宛先のユーザ端末12において予告メッセージを表示させる。カプセルメッセージ送信部90は、開示判定部86により開示条件が満たされたことが判定された際に、送信メッセージ保持部40に記憶された本メッセージをユーザ端末12へ送信して、宛先のユーザ端末12において本メッセージを表示させる。カプセルメッセージ送信部90は、予告メッセージを示す電子メールと、その予告メッセージに対応する本メッセージを示す電子メールのメッセージIDを同一の値に設定してもよい。ユーザ端末12の受信メッセージ表示部66は、メッセージIDにより先に受信した予告メッセージの第1メールと、後に受信した本メッセージの第2メールを対応づけ、第2メールを受信した場合にそれまでの予告メッセージに代えて本メッセージを受信メッセージ画面に表示させてもよい。
第2の実施の形態の構成でも、第1の実施の形態と同様の効果を奏する。また、開示条件が満たされるまではメッセージ本文を宛先へ配信しないため、開示条件が満たされるまでのメッセージ本文の秘匿を一層確実なものにできる。また第2の実施の形態では、メッセージ配信サーバ14が予告メッセージの配信と、本メッセージの配信を時間的に分離するため、ユーザ端末12のメッセージ受信処理部24は、一般的なメッセージクライアントや、電子メールクライアント(メーラ)で実現できる。
第1の実施の形態と第2の実施の形態の両方に適用可能な技術として、好ましくは、一般的なメッセージクライアントを使用するユーザに対しても予告メッセージを配信する一方、メッセージ交換アプリケーション100を導入済のユーザに限定して本メッセージを配信する。具体的には、メッセージ配信サーバ14は、メッセージ交換アプリケーション100を自端末に導入した利用者情報(IDやメールアドレス等)を所定の記憶領域に保持する。ユーザが所定のデジタルコンテンツ配信サイトからメッセージ交換アプリケーション100をダウンロードして自端末にインストールすると、当該ユーザの情報が上記利用者情報へ追加される。メッセージ配信サーバ14は、利用者情報を参照して、開示条件付きメッセージの宛先ユーザがメッセージ交換アプリケーション100をインストール済か否かを判定する宛先判定部をさらに備える。
メッセージ配信サーバ14のカプセルメッセージ送信部90は、宛先ユーザがメッセージ交換アプリケーション100を導入済か否かにかかわらず、宛先ユーザへ予告メッセージを配信する。ただし、メッセージ交換アプリケーション100を導入済のユーザには、図7の(a)で示したような予告メッセージを配信する一方、メッセージ交換アプリケーション100を未導入のユーザには、図7の(a)の内容に加え、メッセージ交換アプリケーション100の導入を促進する情報を付加する。例えば、「メッセージ本文の閲覧にはメッセージ交換アプリケーションのインストールが必要です」等のメッセージや、ダウンロードサイトのURL文字列を付加してもよい。
また、カプセルメッセージ送信部90は、宛先ユーザがメッセージ交換アプリケーション100を導入済であること、すなわち利用者情報に登録済であることを条件として、宛先ユーザへ本メッセージを配信する。第1の実施の形態では、開示条件が満たされたか否かにかかわらず、本メッセージを宛先ユーザへ即時配信し、第2の実施の形態では、開示条件が満たされたことを条件として、本メッセージを宛先ユーザへ配信する。
この態様によると、メッセージ交換アプリケーション100を未使用のユーザに対して、一般的なメッセージクライアント(メーラ等)により予告メッセージを閲覧可能としつつも、本メッセージの閲覧を禁止することができる。すなわち、メッセージ交換アプリケーション100を未使用のユーザは、予告されたメッセージを閲覧することができない。これにより、ユーザ端末12へのメッセージ交換アプリケーション100のダウンロードおよびインストールを促進できる。また、予告が来ることで、「こんなサービスがあるのか」と思って、メッセージ交換アプリケーション100を調べ、またダウンロードする人が出てくる。それがメッセージ交換アプリケーション100(すなわち実施の形態のメッセージ交換システム10に関する装置や方法)を普及させる力になる。
なお、メッセージ交換アプリケーション100を未導入のユーザを指定する宛先情報として、通常のメールアドレスが使用されてもよい。また、メッセージ交換アプリケーション100を導入済のユーザを指定する宛先情報として、メッセージ交換システム10がユーザ毎に独自で割り当てた独自アドレスが使用されてもよい。メッセージ配信サーバ14のカプセルメッセージ送信部90は、送信者が宛先情報として通常のメールアドレスを指定した場合に、メッセージ交換アプリケーション100未導入のユーザ向けの処理を実行し、送信者が宛先情報として独自アドレスを指定した場合に、メッセージ交換アプリケーション100導入済のユーザ向けの処理を実行してもよい。
以上、本発明を第1および第2の実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
第1の変形例を説明する。まず、第1の実施の形態において開示条件付きメッセージの事後的な変更(編集・改変)を実現する方法を説明する。ユーザ端末12のメッセージ送信処理部22は、メッセージ変更部をさらに含んでもよい。この変形例の送信メッセージ表示部54は、既に送信した開示条件付きのメッセージを変更・編集するためのメッセージ変更画面を表示させる。メッセージ変更部は、開示条件付きのメッセージについて、その開示フラグが「0」であることを条件として、メッセージ変更画面に入力された変更・編集内容を受け付け、送信メッセージ保持部40に記録し、それまでのメッセージデータを上書き更新する。またメッセージ変更部は、変更対象のメッセージのIDを指定し、変更後のメッセージ本文・タイトルを含む変更要求をメッセージ配信サーバ14へ送信する。なお、ユーザが変更対象としたメッセージの開示フラグが「1」の場合、メッセージ変更部および送信メッセージ表示部54は、メッセージが受信側ユーザに開示済であるため変更ができない旨を画面に表示させてもよい。これにより、メッセージが開示済という状況に応じた対応を送信側ユーザに実施させることができる。
メッセージ配信サーバ14のメッセージ記録部84は、メッセージ保持部80に保持されたメッセージのうち、変更要求で指定されたIDで特定されるメッセージについて、その開示条件が未充足(開示フラグが「0」)である場合に、その本文・タイトルを変更要求が示す内容に置き換える。メッセージ配信サーバ14のカプセルメッセージ送信部90は、変更要求で指定されたID、本文、タイトルを含む置換用メッセージデータを宛先の受信側ユーザのユーザ端末12へ送信する。受信側ユーザのユーザ端末12の受信メッセージ記録部60は、受信メッセージ保持部56に保持されたメッセージのうち、置換用メッセージデータで指定されたIDにより特定されるメッセージについて、その本文・タイトルを置き換える。これにより、開示条件付きメッセージ送信後の状況変化に応じた、事後的なメッセージの変更を実現できる。
第2の実施の形態においても、上記の第1の変形例に示したメッセージ変更の構成を適用可能であり、開示条件付きメッセージの事後的な変更を実現できる。第2の実施の形態では、開示条件が満たされるまで開示条件付きメッセージの本文を受信側ユーザのユーザ端末12へ提供しない。したがって、メッセージ配信サーバ14のメッセージ保持部80に記憶されたメッセージの本文やタイトルを変更すればよい。
第2の変形例として、メッセージ交換システム10におけるメッセージ配信サーバ14はウェブアプリケーションサーバであってもよく、ユーザ端末12はウェブブラウザを搭載したウェブクライアントであってもよい。言わばウェブメールシステムとして実現されてもよい。この場合、メッセージの本文やタイトル、各種フラグはメッセージ配信サーバ14が一元的に管理してもよい。またメッセージ配信サーバ14は、図2に記載した画面生成機能を一括して保持してもよい。すなわちメッセージ配信サーバ14は、各ユーザの送信トレイ画面、送信メッセージ画面、受信トレイ画面、受信メッセージ画面等のウェブページを一括して生成し、メッセージ送信元およびメッセージ送信先のユーザ端末12へ提供して、各端末のウェブブラウザ画面で表示させてもよい。
第3の変形例を説明する。上記実施の形態では、開示条件として日時条件と気象条件を例示したが、開示条件はこれに留まらない。例えば、開示条件として、メッセージ送信先の相手の状態を指定してもよく、具体的には相手の機嫌がよいこと、相手の機嫌がよい場合にメッセージを送信することを指定してもよい。ここでは、第1メッセージの送信側ユーザ(送信元)を甲、受信側ユーザ(宛先)を乙とし、その開示条件として乙の機嫌がよいことが指定されるとする。メッセージ配信サーバ14の開示判定部86は、所定のアルゴリズムにしたがって、乙の機嫌がよいと判定した場合に、第1メッセージの開示条件が満たされたと判定し、メッセージ保持部80の開示フラグを「1」に変更してもよい。
ある態様として、開示判定部86は、第1メッセージがメッセージ配信サーバ14で受信された後に、送信側ユーザを乙とする第2メッセージを受信した場合、その内容(タイトルや本文等)を参照する。開示判定部86は、受信側ユーザが甲であることを加重条件として第2メッセージを識別してもよい。開示判定部86は、第2メッセージに機嫌がよいことを示す所定のキーワード(楽しい、うれしい等)や、所定の画像(笑顔のスタンプ等)が含まれる場合に、乙の機嫌がよいと判定する。別の態様として、メッセージ配信サーバ14は、甲・乙等の各ユーザが自端末に入力した機嫌がよい〜悪いの加減を示す指標値(とても良い、少し良い、普通、少し悪い、とても悪い等)をユーザ端末12から取得し、所定の記憶領域に記録する。開示判定部86は、その指標値を参照して、乙の機嫌がよいか否か、言い換えれば、第1メッセージの開示条件が満たされたか否かを判定する。例えば、「とても良い」または「少し良い」場合に、第1メッセージの開示条件が満たされたと判定してもよい。
第4の変形例を説明する。上記実施の形態では、開示条件の充足有無をメッセージ配信サーバ14で判定することとした。変形例として、開示事情件の充足有無をユーザ端末12(送信者端末または受信者端末)が判定してもよい。メッセージ配信サーバ14の判定主体決定部85は、メッセージ作成画面において判定主体をユーザ端末12とすることを送信者が指定した場合に、ユーザ端末12を判定主体として決定してもよい。また判定主体決定部85は、開示条件が所定の条件であった場合に、ユーザ端末12を判定主体として自律的に決定してもよい。このときの開示条件は、ユーザ端末12の各種センサ(温度センサ、脈拍センサ等)や各種デバイス(GPS等を利用する位置測位装置)を使用して充足有無を判定可能な条件であってもよい。例えば、受信者(または送信者)が、特定の地域・場所にいることや、周囲の気温が30度以上であること、心拍数が高いこと(例えば140拍/分以上のとき)であってもよい。また、受信者が疲れているとき等の定性的な開示条件が指定されてもよい。この場合、ユーザ端末12の開示条件付与部46またはメッセージ配信サーバ14のメッセージ記録部84は、心拍数が140以上等の定量的な条件に置き換えて開示条件を記録してもよい。
この変形例では、ユーザ端末12は、メッセージ配信サーバ14の開示判定部86と同様の開示条件判定部を備える。メッセージ配信サーバ14の判定主体決定部85は、ユーザ端末12の開示条件判定部に、開示条件を通知し、開示条件の充足有無を判定させる。ユーザ端末12の開示条件判定部は、各種のセンサやデバイスが検知した情報に応じて開示条件の充足有無を判定し、開示条件が充足した場合、その事実を示す情報をメッセージ配信サーバ14へ送信する。メッセージ配信サーバ14の開示判定部86は、この情報を受信すると、実施の形態と同様に開示条件充足時の処理を実行し、受信者端末におけるメッセージ本文の閲覧を可能にする。この変形例によると、メッセージの送信者や受信者の様々な状態を開示条件として、メッセージの配信を制御することができる。
このようにユーザ端末12に開示条件判定部を備えることで、例えばランニング中の友人が坂道を登っている最中に応援メッセージを届けるようなことができる。受信者のおかれた状況に応じてメッセージを届けることで、単にメッセージを届けるよりも暖かみや思いやりを強く感じさせ、効果的に思いを伝えることができる。
第5の変形例を説明する。上記実施の形態では、開示条件付きメッセージ毎の予告メッセージをメッセージ配信サーバ14のメッセージ記録部84が生成し、メッセージ記録部84に記録することとした。変形例として、メッセージ記録部84に代わってカプセルメッセージ送信部90が、あるメッセージに関する予告メッセージの送信タイミングに至る都度、そのメッセージの開示条件に応じた予告メッセージを生成し、宛先のユーザ端末12へ送信してもよい。
上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。例えば、請求項に記載の予告部は、実施の形態に記載のメッセージ配信サーバ14のカプセルメッセージ送信部90により実現される。また、請求項に記載の開示部は、実施の形態に記載のメッセージ配信サーバ14の開示通知部92により実現される。