JP6312305B2 - メッセージ配信サーバ - Google Patents

Description

本発明は、データ処理技術に関し、特にユーザ間のメッセージの交換を支援する技術に関する。

ユーザ間でメッセージを交換する技術として、電子メールやインスタントメッセージ等が普及している。特許文献１は、送信側ユーザが指定した日時に電子メールを配送するメッセージ通信システムを提案している。

特開平１−１２８６４１号公報

先行技術でも指定の日時に電子メールを送ることができる。しかし、電子メールを書いて保存したときと将来それを配信するときの間に時間差があるという点に着目すれば、電子メールが配信される相手に期待感をもたせ、ないし準備をさせるための、さらに利便性の高い技術がありうると本発明者は認識した。

上記課題を解決するために、本発明のある態様のメッセージ配信サーバは、送信側ユーザ甲の装置から送信された、受信側ユーザ乙宛のメッセージと、メッセージの開示条件を受信する受信部と、メッセージが現在は開示されないが将来開示される旨を示唆する情報を乙の装置に表示させる予告部と、開示条件が満たされた場合にメッセージを乙の装置に表示させる開示部と、を備える。

本発明の別の態様は、メッセージの送信装置である。この装置は、送信側ユーザ甲による、受信側ユーザ乙宛のメッセージと、メッセージの開示条件の入力を受け付ける受付部と、開示条件を付したメッセージをサーバへ送信することにより、メッセージが現在は開示されないが将来開示される旨を示唆する情報を乙の装置に表示させる処理と、開示条件が満たされた場合にメッセージを乙の装置に表示させる処理とを、サーバに実行させる送信部と、を備える。

本発明のさらに別の態様は、メッセージの受信装置である。この装置は、メッセージの受信部と、受信されたメッセージを画面に表示させるメッセージ表示部と、を備える。メッセージ表示部は、所定の開示条件が付されたメッセージが受信された場合、メッセージが現在は開示されないが将来開示される旨を示唆する情報を画面に表示させ、開示条件が満たされた場合にメッセージを画面に表示させる。

なお、以上に示した各構成要素の任意の組み合わせ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。

本発明によれば、将来時点において内容を開示すべきメッセージの配信について、ユーザの利便性を向上させることができる。

メッセージ交換システムの構成を示す図である。 図１のユーザ端末の機能構成を示すブロック図である。 送信メッセージ保持部に保持されるデータの構成を示す図である。 受信メッセージ保持部に保持されるデータの構成を示す図である。 図１のメッセージ配信サーバの機能構成を示すブロック図である。 メッセージ保持部に保持されるデータの構成を示す図である。 受信メッセージの表示画面を示す図である。 受信トレイ画面を示す図である。 送信トレイ画面を示す図である。

実施の形態として提案する情報処理システムは、送信側ユーザ（発信者）により何らかの開示条件が付されたメッセージを受信側ユーザ（宛先として指定された受取人）へ配信する。そして、開示条件が満たされた場合にメッセージの内容を受信側ユーザに開示するメッセージ交換サービスを提供する。言わば、メッセージの配信予約サービスを提供する。開示条件は、受信側ユーザに対するメッセージの開示を許可する条件であり、言い換えれば、受信側ユーザによるメッセージの閲覧を許可する条件である。例えば、開示日時やタイミングを規定するものである。開示条件が付されたメッセージは、将来時点において閲覧可能となるタイムカプセルと言える。

実施の形態のメッセージ交換サービスでは、開示条件が満たされてメッセージの内容を受信側ユーザへ開示する前に、現在はメッセージが開示されないが将来開示される旨を示唆する予告を受信側ユーザへ提示する。「メッセージ」は、電子メールデータやプレーンテキスト、所定フォーマットの文書データ、音声、画像、動画等、様々な公知の形態を含む。また、実施の形態のメッセージ交換サービスの仕組みは、様々な情報処理システム・サービスに適用可能である。例えば、電子メールシステム、インスタントメッセージサービス、ショートメッセージサービス、マルチメディアメッセージングサービスに適用することができる。

（第１の実施の形態）
図１は、第１の実施の形態のメッセージ交換システムの構成を示す。メッセージ交換システム１０は、ユーザ端末１２で総称される複数のユーザ端末１２ａ、１２ｂ、１２ｃ、１２ｄと、メッセージ配信サーバ１４を備える。ユーザ端末１２とメッセージ配信サーバ１４は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網１６を介して接続される。

ユーザ端末１２は、メッセージ交換サービスを利用するユーザにより操作される情報処理装置である。ユーザ端末１２は、様々な形態が想定され、例えばＰＣ、タブレット端末、スマートフォン、フィーチャーフォンであってもよい。メッセージ配信サーバ１４は、メッセージ交換サービスを提供し、ユーザ端末１２間でメッセージを中継する情報処理装置である。メッセージ交換システム１０が電子メールシステムとして実現される場合、メッセージ配信サーバ１４は、メールサーバとして実装されてもよい。また、後述するユーザ端末１２のメッセージ交換アプリケーション１００は、電子メールクライアントアプリケーション（いわゆるメーラー）として実装されてもよい。

図２は、図１のユーザ端末１２の機能構成を示すブロック図である。ユーザ端末１２は、インタフェース部２０、メッセージ送信処理部２２、メッセージ受信処理部２４を備える。本明細書のブロック図で示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

インタフェース部２０は、ユーザとユーザ端末１２、ユーザ端末１２と外部装置とのインタフェース機能を提供する。インタフェース部２０は、操作検出部３０、表示制御部３２、通信部３４を含む。操作検出部３０は、キーボードやマウス等の入力装置に対するユーザの操作入力を検出し、その操作内容を他の機能ブロックへ通知する。メッセージ送信処理部２２およびメッセージ受信処理部２４は、操作検出部３０を介して、ユーザが入力した操作を受け付ける。

表示制御部３２は、メッセージ送信処理部２２およびメッセージ受信処理部２４から出力されたデータを、不図示のディスプレイドライバを介してディスプレイに表示させる。メッセージ送信処理部２２およびメッセージ受信処理部２４は、表示制御部３２を介して、テキストや画像等の各種コンテンツをディスプレイに表示させる。通信部３４は、所定のプロトコル（ＨＴＴＰやＳＭＴＰ、ＰＯＰ等）にしたがって外部装置と通信する。メッセージ送信処理部２２およびメッセージ受信処理部２４は、通信部３４を介して、各種データをメッセージ配信サーバ１４と送受する。

メッセージ送信処理部２２は、メッセージの送信と、送信したメッセージの閲覧に関するデータ処理を実行する。メッセージ受信処理部２４は、メッセージの受信と、受信したメッセージの閲覧に関するデータ処理を実行する。メッセージ送信処理部２２およびメッセージ受信処理部２４の機能は、ユーザ端末１２のＯＳやウェブブラウザ等の機能の少なくとも一部を使用して実現してもよい。

実装の一例として、メッセージ送信処理部２２およびメッセージ受信処理部２４の機能を包含するメッセージ交換アプリケーション１００がユーザ端末１２のストレージにインストールされてよい。ユーザがユーザ端末１２においてメッセージ交換アプリケーション１００を起動すると、ユーザ端末１２のＣＰＵが、メッセージ送信処理部２２およびメッセージ受信処理部２４の各機能ブロックに対応するプログラムモジュールをメインメモリに読み出して実行することにより、メッセージ送信処理部２２およびメッセージ受信処理部２４の機能が発揮されてよい。各種データの保持部は、ストレージやメインメモリ等の所定の記憶装置により実現されてよい。

メッセージ送信処理部２２は、送信メッセージ保持部４０、メッセージ作成部４２、メッセージ送信部４８、送信メッセージ記録部５０、ステータス更新部５１、送信トレイ表示部５２、送信メッセージ表示部５４を含む。メッセージ送信処理部２２の説明において特に断らない場合、「ユーザ」は自装置のユーザであり、メッセージ送信者を意味する。

送信メッセージ保持部４０は、自装置からメッセージ配信サーバ１４へ送信した１つ以上のメッセージについて、各メッセージの本文と各種属性情報を保持する。送信メッセージ保持部４０は、送信メッセージの履歴を保持するとも言える。

図３は、送信メッセージ保持部４０に保持されるデータの構成を示す。ＩＤ欄には、メッセージをユニークに特定可能なメッセージＩＤが格納される。メッセージ欄には、メッセージの本文が格納される。宛先・送信元の識別情報（メールアドレス等）やタイトルがさらに格納されてもよい。エラーフラグ欄には、メッセージの送信においてエラーが発生したか（値１）、またはエラー未発生で正常に送信できたか（値０）を示す値が格納される。このエラーには、メッセージ配信サーバ１４によるメッセージ中継時のエラーであり、メッセージ配信サーバ１４から通知されたエラーも含まれる。

カプセルフラグ欄には、開示条件が付された言わばカプセルメッセージか（値１）、開示条件が付与されない言わば通常のメッセージか（値０）を示す値が格納される。開示条件欄には、ユーザがメッセージに付与した開示条件が格納される。開示フラグ欄には、開示条件が付されたメッセージが受信側ユーザに未開示か（値０）、もしくは開示済か（値１）を示す値が格納される。カプセルフラグが「０」であれば、開示条件欄および開示フラグ欄のデータは未設定（図の「−」）となる。

開示条件には、その充足有無をシステムが自動で判別可能な様々な条件、また、その充足有無を人手により確認可能な様々な条件が指定される。例えば、日時条件として、特定の年月日、日時、期間（送信後何日〜何年）、消息不明時、消息不明が確認された後の特定の期間（日付）、死亡確認時、死亡が確認された後の特定の期間（日付）が指定されてもよい。例えば、開示条件として死亡時を指定する場合、もしものときの遺言の配信を予約することになる。また、ユーザが予め記念日と日付の対応関係をメッセージ配信サーバ１４に登録した場合、記念日（例えば家族の誕生日や結婚記念日、三回忌）の名称で指定されてもよい。

さらにまた、開示条件として特定の気象条件（雨、気温３０度以上等）が指定されてもよい。この開示条件は販売促進メッセージの提供に好適である。例えば、タクシー会社の広告メッセージの配信予約において、開示条件として「雨」が指定されてもよい。また、ビール会社の広告メッセージの配信予約において、開示条件として「気温３０度以上」が指定されてもよい。

図２に戻り、メッセージ作成部４２は、メッセージの作成に関する処理を実行する。メッセージ作成部４２は、作成画面表示部４４、開示条件付与部４６を含む。作成画面表示部４４は、開示条件設定エリアを含むメッセージ作成画面をディスプレイに表示させる。メッセージ作成画面には、メッセージの受信者側ユーザの識別情報（例えば宛先情報であり、宛先メールアドレス等）やメッセージのタイトル、本文が入力される。開示条件設定エリアには、上述したように様々な態様の開示条件が任意で入力される。

メッセージ作成部４２は、メッセージ作成画面に入力されたデータにしたがって、宛先情報やメッセージのタイトル、本文を含む送信用のメッセージデータを生成する。開示条件付与部４６は、メッセージ作成画面の開示条件設定エリアに開示条件が入力された場合に、その開示条件を示す開示条件データをメッセージデータに付加する。

メッセージ送信部４８は、メッセージ作成部４２により生成されたメッセージデータをメッセージ配信サーバ１４へ送信する。このメッセージデータは、送信側ユーザ（送信元ユーザ）の識別情報と、受信側ユーザ（宛先ユーザ）の識別情報を含む。識別情報は、公知のＩＤやアドレスでよく、例えばメールアドレスでもよい。

送信メッセージ記録部５０は、メッセージ送信部４８により送信されたメッセージデータを送信メッセージ保持部４０に格納し、エラーフラグ、カプセルフラグ、開示条件、開示フラグの値をメッセージデータにしたがって設定する。例えば、エラーフラグの初期値は「０」とする。また、メッセージデータに開示条件データが付加されていた場合、カプセルフラグを「１」として開示条件を記録する。開示条件が付加されたメッセージの送信時の開示フラグは「０（未開示）」とする。

ステータス更新部５１は、メッセージ配信サーバ１４からのメッセージ配信エラーの通知が後述のメッセージ受信部５８で受信されると、配信エラーとなったメッセージのエラーフラグを「１」に更新する。またステータス更新部５１は、メッセージ配信サーバ１４から、開示条件付きのメッセージの開示条件が満たされて、当該メッセージを開示した旨の通知を受け付けると、当該メッセージの開示フラグを「１（開示済）」に変更する。

送信トレイ表示部５２は、自装置からメッセージ配信サーバ１４へ送信したメッセージの一覧画面である送信トレイ画面をディスプレイに表示させる。言い換えれば、自装置から他のユーザ端末１２宛に送信したメッセージの履歴を表示させる。具体的には、送信トレイ表示部５２は、送信メッセージ保持部４０に格納されたデータを参照して、送信メッセージの種類や送信状況に応じた態様で各メッセージのタイトルを並べた送信トレイ画面を表示させる。送信トレイ表示部５２は、少なくとも、開示条件を付加して送信したメッセージと、開示条件を付加せず送信したメッセージを異なる態様で表示させる。

例えば、送信トレイ表示部５２は、開示条件が付加された旨を示す所定の形状・模様・色彩のシンボルを、開示条件が付加されたメッセージのみに設定することで、他の種類のメッセージと区別可能に表示させてもよい。また送信トレイ表示部５２は、メッセージのタイトルや本文について、その文字サイズ・フォント・色等をメッセージの種類・属性ごとに変更してもよく、開示条件が付加されているか否かに応じて、異なる文字サイズ・フォント・色を設定してもよい。

実施の形態では、送信トレイ表示部５２は、送信トレイ画面において、（１）開示条件が付与され、現在未開示のメッセージと、（２）送信エラーとなったメッセージを、「未送信メッセージ」グループを示す第１の態様で表示させる。その一方、送信トレイ画面において、（３）開示条件が付与されず、送信エラー未発生のメッセージ、言わば正常な送信済メッセージ、（４）開示条件が付与され、現在開示済のメッセージを、第１の態様とは異なり「送信済メッセージ」グループを示す第２の態様で表示させる。

例えば、「未送信メッセージ」グループのメッセージは、そのタイトルをボールド体の黒色文字で表示させる一方、「送信済メッセージ」グループのメッセージは、そのタイトルを通常フォントの黒色文字で表示させてもよい。また、グループ毎に異なる形状や色彩のシンボルを各メッセージのタイトルに付して表示させてもよい。送信トレイ画面の表示例は後述する。

送信トレイ表示部５２は、エラーフラグ＝０、カプセルフラグ＝１、開示フラグ＝０のメッセージを（１）のメッセージとして識別する。また、エラーフラグ＝１のメッセージを（２）のメッセージとして識別する。また、エラーフラグ＝０、カプセルフラグ＝０のメッセージを（３）のメッセージとして識別する。また、エラーフラグ＝０、カプセルフラグ＝１、開示フラグ＝１のメッセージを（４）のメッセージとして識別する。なお送信トレイ表示部５２は、公知の方法により（５）作成中のメッセージを識別し、「未送信メッセージ」を示す第１の態様で送信トレイ画面に表示させてもよい。

変形例として、送信トレイ表示部５２は、送信トレイ画面において、（１）開示条件が付与され、現在未開示のメッセージを「予約メッセージ」グループを示す第１の態様で表示させてもよい。その一方、送信トレイ画面において、（２）送信エラーとなったメッセージ、（３）開示条件が付与されず、送信エラー未発生のメッセージ、言わば正常な送信済メッセージ、（４）開示条件が付与され、現在開示済のメッセージを、第１の態様とは異なり「送信済メッセージ」グループを示す第２の態様で表示させてもよい。

このように、実施の形態と変形例のいずれの場合も、（３）のメッセージと（４）のメッセージの双方を同じ態様で表示させる。（４）の開示条件は既に満たされており、閲覧制限は解除されているため、ユーザにとって通常の送信済メッセージと区別する必要がなく、むしろ通常の送信済メッセージと同じ態様で表示させた方がユーザにとって利便性が高いからである。

送信メッセージ表示部５４は、送信トレイ画面においてユーザが選択したメッセージのデータを送信メッセージ保持部４０から取得し、ディスプレイに表示させる。送信メッセージ保持部４０に開示条件も格納されている場合、その開示条件も表示させる。

メッセージ受信処理部２４は、受信メッセージ保持部５６と、メッセージ受信部５８と、受信メッセージ記録部６０と、ステータス更新部６２と、受信トレイ表示部６４と、受信メッセージ表示部６６を含む。メッセージ受信処理部２４の説明において特に断らない場合、「ユーザ」は自装置のユーザであり、メッセージ受信者を意味する。

受信メッセージ保持部５６は、メッセージ配信サーバ１４から受信した１つ以上のメッセージについて、各メッセージの本文と各種属性情報を保持する。受信メッセージ保持部５６は、受信メッセージの履歴を保持するとも言える。

図４は、受信メッセージ保持部５６に保持されるデータの構成を示す。本メッセージ欄には、受信メッセージの本文が格納される。宛先・送信元の識別情報（メールアドレス等）やタイトルがさらに格納されてもよい。予告メッセージ欄には、受信メッセージに付加された予告メッセージが格納される。実施の形態では、開示条件が付加されたメッセージに対して、メッセージ配信サーバ１４が予告メッセージを設定する。予告メッセージは、メッセージの本文が、現在は開示されないものの将来開示される旨を示唆する情報であり、文字列や画像等、任意の形式であってよい。未読フラグ欄には、受信者側ユーザによるメッセージの閲覧状況を示す値が格納される。具体的には、閲覧済＝０、未読＝１が格納されることとする。

カプセルフラグ欄の意味は図３と同じである。開示フラグ欄には、メッセージの開示・閲覧が現在禁止されているか（値０）、メッセージの開示・閲覧が現在許可されているか（値１）を示す値が格納される。開示条件が付されたメッセージの受信時には、当該メッセージの開示フラグは「０」に設定される。カプセルフラグが０（すなわち開示条件が付与されていないメッセージ）の場合、開示フラグの値は未設定「−」となる。

図２に戻り、メッセージ受信部５８は、メッセージ配信サーバ１４から送信されたユーザ宛のメッセージを受信する。メッセージ受信部５８は、ユーザの操作に応じて、または所定の時間間隔にて自動で、ユーザ宛のメッセージの提供をメッセージ配信サーバ１４へ要求し、メッセージ配信サーバ１４に蓄積されたユーザ宛のメッセージをメッセージ配信サーバ１４から取得してもよい。

受信メッセージ記録部６０は、メッセージ受信部５８で受信されたメッセージデータを受信メッセージ保持部５６へ格納する。メッセージ配信サーバ１４から受信したメッセージデータは、ＩＤ、本メッセージ、予告メッセージ、カプセルフラグ、開示フラグを含む。受信メッセージ記録部６０は、メッセージの未読フラグを「１」に設定する。

ステータス更新部６２は、開示条件付きのメッセージについて、その開示条件が満たされたことを示す情報をメッセージ配信サーバ１４から受信し、当該メッセージの開示フラグを「１（開示・閲覧可能）」に変更する。またステータス更新部６２は、受信メッセージ表示部６６によりディスプレイに表示された、言い換えれば、ユーザにより閲覧されたメッセージの未読フラグが「１」である場合に、当該未読フラグを「０」に変更する。

受信トレイ表示部６４は、自装置がメッセージ配信サーバ１４から受信したメッセージの一覧画面である受信トレイ画面をディスプレイに表示させる。受信トレイ表示部６４は、受信メッセージ保持部５６に格納されたデータを参照して、受信メッセージの種類や閲覧状況に応じた態様で各メッセージを一覧表示させる。少なくとも受信トレイ表示部６４は、開示条件が付加されたメッセージと、開示条件なしのメッセージを、送信トレイ表示部５２の説明で既述したように異なる態様で表示させる。

実施の形態では、受信トレイ表示部６４は、受信トレイ画面において、（１）通常未読メッセージと、（２）カプセル解除未読メッセージと、（３）カプセル化未読メッセージと、（４）通常既読メッセージ、（５）カプセル解除既読メッセージのそれぞれを、互いに異なるグループを示す異なる態様で表示させる。（１）は、開示条件が付加されていない未読状態のメッセージである。（２）は、開示条件が付され、その開示条件が充足して閲覧可能になったメッセージのうち未読状態のメッセージである。（３）は、開示条件が付され、その開示条件が未充足であるため閲覧が許可されないメッセージである。（４）は、開示条件が付加されていない既読状態のメッセージである。（５）は、開示条件が付され、その開示条件が充足して閲覧可能になったメッセージのうち既読状態のメッセージである。受信トレイ画面の表示例は後述する。

受信トレイ表示部６４は、未読フラグ＝１、カプセルフラグ＝０のメッセージを（１）のメッセージとして識別し、未読フラグ＝１、カプセルフラグ＝１、開示フラグ＝１のメッセージを（２）のメッセージとして識別する。また、未読フラグ＝１、カプセルフラグ＝１、開示フラグ＝０のメッセージを（３）のメッセージとして識別し、未読フラグ＝０、カプセルフラグ＝０のメッセージを（４）のメッセージとして識別する。また、未読フラグ＝０、カプセルフラグ＝１、開示フラグ＝１のメッセージを（５）のメッセージとして識別する。

変形例として、受信トレイ表示部６４は、未読フラグ＝１、カプセルフラグ＝０のメッセージと、未読フラグ＝１、カプセルフラグ＝１、開示フラグ＝１のメッセージの両方を同じ未読メッセージとして識別してもよい。すなわち、上記の（１）通常未読メッセージと（２）カプセル解除未読メッセージを同じ態様で表示させてもよく、言い換えれば、開示条件が付されたメッセージを、その開示条件が満たされて閲覧可能になった場合は、開示条件が付されていない通常の未読メッセージと同じ態様で表示させてもよい。同様に、未読フラグ＝０、カプセルフラグ＝０のメッセージと、未読フラグ＝０、カプセルフラグ＝１、開示フラグ＝１のメッセージの両方を同じ既読メッセージとして識別してもよい。すなわち、上記の（４）通常既読メッセージと（５）カプセル解除既読メッセージを同じ態様で表示させてもよい。

受信メッセージ表示部６６は、受信メッセージ画面をディスプレイに表示させる。受信メッセージ表示部６６は、受信トレイ画面においてユーザが選択したメッセージ（以下、「被選択メッセージ」と呼ぶ。）について、本メッセージ（例えば本文、タイトル）、送信元情報等の表示対象データを受信メッセージ保持部５６から取得し、これらのデータを受信メッセージ画面１１０に表示させる。受信メッセージ表示部６６は、被選択メッセージのカプセルフラグが「０」の場合、すなわち、被選択メッセージに開示条件が付されていないとき、被選択メッセージの内容をディスプレイに表示させる。同様に、被選択メッセージのカプセルフラグが「１」で、かつ開示フラグが「１」である場合、すなわち、被選択メッセージの開示条件が満たされている場合、被選択メッセージの内容をディスプレイに表示させる。受信メッセージ表示部６６は、本メッセージの内容を表示したメッセージについて、その未読フラグを「０」に更新する。

その一方、受信メッセージ表示部６６は、被選択メッセージのカプセルフラグが「１」で、開示フラグが「０」の場合、すなわち、被選択メッセージの開示条件が満たされていない場合、その被選択メッセージの本メッセージ（例えば本文、タイトル）を画面に表示させない。その代わりに、被選択メッセージが、現在は開示されないが将来開示される旨を示唆する予告メッセージをディスプレイに表示させる。受信メッセージ画面の表示例は後述する。

図５は、図１のメッセージ配信サーバ１４の機能構成を示すブロック図である。メッセージ配信サーバ１４は、通信部７０、メッセージ中継部７２を備える。通信部７０は、所定のプロトコルにしたがって外部装置と通信する。メッセージ中継部７２は、通信部３４を介して、各種データをユーザ端末１２と送受する。メッセージ中継部７２は、あるユーザ端末１２から送信されたメッセージを、宛先として指定されたユーザのユーザ端末１２へ中継するためのデータ処理を実行する。

メッセージ中継部７２は、メッセージ保持部８０、メッセージ受信部８２、判定主体決定部８５、開示判定部８６、メッセージ送信部８８、開示通知部９２を含む。

メッセージ保持部８０は、メッセージ受信部８２が受信したメッセージの本文と各種属性情報を保持する。メッセージ保持部８０は、ユーザ端末１２間でやりとりされるメッセージの履歴を保持するとも言える。図６は、メッセージ保持部８０に保持されるデータの構成を示す。図６の各項目の意味は、図３または図４で説明したとおりである。

図５に戻り、メッセージ受信部８２は、ユーザ端末１２から送信されたメッセージデータを受信する。メッセージ受信部８２のメッセージ記録部８４は、受信したメッセージデータをメッセージ保持部８０に格納する。メッセージ記録部８４は、受信したメッセージデータで指定されたＩＤと本メッセージをメッセージ保持部８０へ格納する。受信したメッセージデータが開示条件を含まなければ、カプセルフラグを「０」とし、開示フラグは設定しない。

その一方、受信したメッセージデータが開示条件データを含む場合、メッセージ記録部８４は、開示条件欄に開示条件データを格納するとともに、カプセルフラグを「１」、開示フラグを「０」に設定する。さらにメッセージ記録部８４は、開示条件に応じた予告メッセージを作成し、予告メッセージ欄に格納する。このとき、開示条件そのものを予告メッセージとしてもよい。また、開示条件として定められた日付や開示タイミングを示す文字列に、予め定められた修飾文字列、例えば「に開封可能になります」等を加えた文字列を予告メッセージとして記録してもよい。

判定主体決定部８５は、メッセージ受信部８２が受信したメッセージデータごとに、メッセージの送信者により入力されたメッセージ本文や開示条件等に応じて、各メッセージに付された開示条件の充足状況を判定すべき主体を決定する。メッセージ配信サーバ１４とユーザ端末１２（送信者端末または受信者端末）のいずれも開示条件充足有無の判定主体となり得る。メッセージ送信者は、メッセージ作成画面において判定主体とする装置を指定入力し、判定主体決定部８５は、送信者が指定した装置を判定主体として決定してもよい。また判定主体決定部８５は、上記の日時条件や気象条件が開示条件として指定された場合に、メッセージ配信サーバ１４を判定主体として自律的に決定してもよい。実施の形態では、メッセージ配信サーバ１４自身を判定主体として決定することとし、他装置を判定主体とする場合については変形例として後述する。

開示判定部８６は、メッセージ保持部８０に格納されたメッセージのうち、カプセルフラグが「１」、開示フラグが「０」のメッセージ、すなわち、開示条件がそれまで未充足であったメッセージついて、現時点で開示条件が充足されたか否かを定期的に判定する。開示条件が充足されたと判定したメッセージがある場合、そのメッセージの開示フラグを「１」に変更する。

例えば、開示条件が特定の日時に到達することであった場合、開示判定部８６は、現在日時（システム日時等）が、開示条件が定める日時を経過した場合に開示条件が充足されたと判定する。また、開示条件が記念日（家族の誕生日や結婚記念日、三回忌）の名称で指定された場合、開示判定部８６は、送信側ユーザにより予め登録されて、所定のテーブルに格納されたユーザの記念日と日付の対応関係を参照し、記念日を日付で置き換えた上で、開示条件の充足有無を判定する。

また、開示条件が特定人物（例えば送信側ユーザ）の死亡である場合、公知の方法により特定人物が死亡したか否かを判定し、死亡を確認した場合に開示条件が充足されたと判定する。例えば、本発明者が「特開２０１３−１０１５４９号公報」で提案している技術を使用してもよい。本発明者は、この特許文献の中で、本人へメール等で生存確認し、それが途絶えたら、本人が予め自分の電話帳の中で指定する人（エンディングパートナー）に死亡確認する技術を提案している。また、一部類似するが、特定人物に関して予め定められた連絡先（例えば携帯端末等）に生存確認依頼の情報を送信し、その送信においてエラーが発生したことや、所定の応答がなかった場合に、特定人物の死亡が確認されたと判定してもよい。また、担当者が特定人物の死亡を電話連絡等、人手で確認し、その確認結果をメッセージ配信サーバ１４へ入力することにより、開示判定部８６が死亡確認結果を取得してもよい。消息不明の確認についても死亡確認と同様の方法で実現されてよい。

また、開示条件が特定の気象を指定する場合、外部の気象情報提供サーバから当日の気象情報を取得し、当日の気象情報が特定の気象に整合する場合に開示条件が充足されたと判定する。一部既述したように、開示条件の充足有無の判定は、メッセージ配信サーバ１４が他の装置と適宜連携して自動で実行してもよい。また、担当者が人手により確認し、その確認結果がメッセージ配信サーバ１４に記録され、開示判定部８６がその確認結果を参照することにより実現してもよい。

メッセージ送信部８８は、送信側ユーザのユーザ端末１２から送信され、メッセージ受信部８２が受信したメッセージを、宛先として指定された受信側ユーザのユーザ端末１２へ送信する。具体的には、メッセージ保持部８０に新たなメッセージデータが記録されたことを検出した場合に、そのメッセージＩＤと本メッセージを取得し、ユーザ端末１２へプッシュ送信する。ユーザ端末１２からの要求に応じてメッセージを送信してもよく、所定の時間間隔で定期的にメッセージを送信してもよい。

メッセージ送信部８８のカプセルメッセージ送信部９０は、送信側ユーザのユーザ端末１２から送信されたメッセージのうち、開示条件が付されたメッセージをユーザ端末１２へ送信する。具体的には、メッセージＩＤ、本メッセージ、予告メッセージ、カプセルフラグ、開示フラグをメッセージ保持部８０から取得し、ユーザ端末１２へ送信する。このときのカプセルフラグは「１」であり、開示条件がすでに満たされていれば開示フラグは「１」、満たされていなければ開示フラグは「０」である。

開示通知部９２は、開示条件が付されたメッセージついて、その開示条件が満たされて、受信側ユーザが閲覧可能になった旨をユーザ端末１２へプッシュ通知する。具体的には、開示通知部９２は、メッセージ保持部８０を監視し、開示判定部８６により開示フラグが「０」から「１」へ変更されたメッセージを検出する。開示通知部９２は、開示フラグが「０」から「１」へ変更されたメッセージについて、そのメッセージＩＤと、開示フラグ変更の旨（言い換えればメッセージの開示を許可する旨）を示す情報を、宛先ユーザの識別情報により特定される受信側ユーザのユーザ端末１２へ送信する。また、同じ情報を、送信元ユーザの識別情報により特定される送信側ユーザのユーザ端末１２へ送信する。

以上の構成によるメッセージ交換システム１０の動作を、受信メッセージの表示画面を示す図７を参照しつつ説明する。ここでは、送信側ユーザの甲が使用する端末（ユーザ端末１２ａ）から、受信側ユーザの乙が使用する端末（ユーザ端末１２ｂ）へ、開示条件付きのメッセージを送信する。すなわち、メッセージの送信側装置をユーザ端末１２ａとし、受信側装置をユーザ端末１２ｂとする。また、メッセージの内容は２０１３年１２月２０日以降に閲覧を許可すべき人事情報とし、開示条件として２０１３年１２月２０日に至ることが指定される。すなわち、２０１３年１２月２０日以降に閲覧を許可する旨の開示条件がメッセージに付与される。

甲は、ユーザ端末１２ａにてメッセージ交換アプリケーション１００の画面を起動し、その画面でメッセージの作成を選択する。ユーザ端末１２ａのメッセージ作成部４２はメッセージ作成画面を表示させる。甲は、メッセージ作成画面に、乙宛のメッセージを入力し、さらに開示条件を入力する。メッセージ送信部４８は、メッセージ作成画面に入力されたメッセージと開示条件を対応づけてメッセージ配信サーバ１４へ送信する。送信メッセージ記録部５０は、メッセージ配信サーバ１４に送信されたメッセージと開示条件を対応づけて送信メッセージ保持部４０へ記録する。

甲が、メッセージ交換アプリケーション１００の画面で送信トレイを選択すると、送信トレイ表示部５２は、送信メッセージの一覧を送信トレイ画面に表示させる。その際、送信トレイ表示部５２は、開示条件が付与され、現在受信側ユーザに未開示のメッセージ（上記乙宛のメッセージを含む）と、開示条件が付与されず、受信側ユーザが閲覧可能なメッセージを互いに異なる態様で表示させる。

メッセージ配信サーバ１４のメッセージ受信部８２は、ユーザ端末１２ａから送信されたメッセージと開示条件を受信する。メッセージ記録部８４は、受信されたメッセージについて、本メッセージ、予告メッセージ「１２月２０日に開封予定」、開示条件をメッセージ保持部８０へ記録する。メッセージ送信部８８は、メッセージ受信部８２により受信されたメッセージに関する本メッセージと予告メッセージを乙のユーザ端末１２ｂへ送信する。このとき、開示フラグ「０」を付加して送信する。

ユーザ端末１２ｂのメッセージ受信部５８は、メッセージ配信サーバ１４から送信されたメッセージデータを受信し、受信メッセージ記録部６０は、受信されたメッセージデータを受信メッセージ保持部５６へ格納する。乙は、メッセージ交換アプリケーション１００の画面を起動し、その画面で受信トレイを選択する。受信トレイ表示部６４は、受信メッセージの一覧を受信トレイ画面に表示させる。その際、受信トレイ表示部６４は、開示条件が付与された未読メッセージ（上記乙宛のメッセージを含む）と、開示条件が付与されていない未読メッセージと、既読メッセージを互いに異なる態様で一覧表示させる。

乙は、受信トレイ画面で閲覧したいメッセージを選択し、受信メッセージ表示部６６は、乙により選択されたメッセージを受信メッセージ画面に表示させる。ここでは、開示条件が付与された未読メッセージであり、開示条件が未充足の未読メッセージである上記乙宛のメッセージを選択する。受信メッセージ表示部６６は、図７（ａ）（ｂ）で示すように、受信メッセージ画面１１０においてメッセージの本文を非表示とする。その代わりに、メッセージの本文が将来時点において閲覧可能になる旨を示唆する予告メッセージ１１２と予告画像１１４を表示させる。仮に開示条件が甲の死亡時であれば、「甲がお亡くなりになったときに開封」等の予告メッセージ１１２を表示させてもよい。また開示条件が気温３０度以上であれば、「気温３０度以上のときに開封」等の予告メッセージ１１２を表示させてもよい。

図７（ａ）は、開示条件の充足まで３日以上要する場合の予告画像１１４を示しており、この例では１２月１６日まで亀裂のないカプセル（タマゴ）を表示させる。その一方、図７（ｂ）は、開示条件の充足まで３日未満の場合の予告画像１１４を示しており、この例では１２月１７日以降、亀裂のあるカプセルを表示させる。このように、受信メッセージ表示部６６は、現在日時から開示条件充足までの期間の長短に応じて予告メッセージ１１２と予告画像１１４の内容を変更してもよい。具体的には、現在日時から開示条件充足までの期間の長短を示唆する態様で予告画像１１４を表示させてもよい。例えば、開示条件充足までの残り期間が短くなるほどカプセルの亀裂が広がっていく態様や、予告メッセージ１１２や予告画像１１４の色彩が濃くなっていく態様で表示させてもよい。

このように、予告メッセージ１１２と予告画像１１４の表示態様を変更させるために、メッセージ配信サーバ１４がユーザ端末１２ｂへ開示条件そのものを提供し、ユーザ端末１２ｂの判定部が開示条件充足までの残り期間の長短を判定してもよい。また、開示条件充足までの残り期間の長短、すなわち、予告メッセージ１１２と予告画像１１４を複数段階の態様のうちどの態様で表示させるかをメッセージ配信サーバ１４の開示判定部８６が判定してもよい。そしてメッセージ配信サーバ１４の開示通知部９２が、開示判定部８６による判定結果をユーザ端末１２へ送信し、ユーザ端末１２ｂの受信メッセージ保持部５６に記憶させてもよい。

また図７（ａ）（ｂ）で示すように、受信メッセージ表示部６６は、開示条件が充足されるまでの間、メッセージの本来のタイトルも非開示とし、単に甲からメッセージが届いた旨のタイトルに変換し、変換後のタイトルを表示させる。変形例として、乙の事前の心づもりを支援するために、タイトルについては、開示条件が未充足であっても甲が作成したオリジナルの内容を表示させてもよい。なお、送信元のユーザ名は開示条件充足前から開示することで、誰からのメッセージであるかは把握可能とする。

メッセージ配信サーバ１４の開示判定部８６は、開示条件がそれまで未充足のメッセージについて、現在時点で開示条件が充足された否かを定期的に判定する。ここでは、１２月２０日に至った場合に、開示判定部８６は、甲から乙宛のメッセージの開示条件が充足されたと判定し、その開示フラグを「１」に変更する。開示通知部９２は、当該メッセージの開示を許可する旨をユーザ端末１２ａとユーザ端末１２ｂの双方へ通知する。

ユーザ端末１２ａのステータス更新部５１は、送信メッセージ保持部４０に保持された甲から乙宛のメッセージの開示フラグを「１」に変更する。以降、送信トレイ表示部５２は、送信トレイ画面において、当該メッセージを、開示条件が付与されず、受信側ユーザが閲覧可能なメッセージと同じ態様で表示させる。

ユーザ端末１２ｂのステータス更新部６２は、受信メッセージ保持部５６に保持された甲から乙宛のメッセージの開示フラグを「１」に変更する。以降、乙が受信トレイ画面で甲から乙宛のメッセージを選択すると、受信メッセージ表示部６６は、図７（ｃ）で示すように、当該メッセージの本文を示す本メッセージ１１６と、オリジナルのタイトルを受信メッセージ画面１１０に表示させる。ステータス更新部６２は、当該メッセージの未読フラグを「０」に変更し、以降、受信トレイ画面において当該メッセージを既読メッセージとして表示させる。

図８は、受信トレイ表示部６４が表示する受信トレイ画面を示す。受信トレイ表示部６４は、受信トレイ画面１２０において、開示条件が付加されていない未読メッセージを、予告画像１２２なしのボールド体で表示し、開示条件が付加されていない既読メッセージを予告画像１２２なしの通常フォントで表示させる。その一方、受信トレイ表示部６４は、開示条件が付与されたメッセージを、予告画像１２２を付加した態様で表示させる。同図の予告画像１２２は図７と同様にカプセルである。開示条件が付加されたメッセージについては、その開示条件（図８では開示日時）をさらに表示させる。

受信トレイ表示部６４は、開示条件未充足のメッセージ（カプセルフラグ＝１、開示フラグ＝０）のうち、開示条件充足までの残り期間が短い（例えば３日未満の）メッセージには亀裂のあるカプセルの画像を付加する。その一方、開示条件までの残り期間が長い（例えば３日以上の）メッセージには亀裂のないカプセルの画像を付加する。

また受信トレイ表示部６４は、開示条件充足済の未読メッセージ（未読フラグ＝１、カプセルフラグ＝１、開示フラグ＝１）に、割れたカプセルを示す予告画像１２２（点滅した状態）を付加する。また開示条件充足済の既読メッセージ（未読フラグ＝０、カプセルフラグ＝１）に、割れたカプセルを示す予告画像１２２（点滅なし）を付加する。例えば、カプセルが割れて点滅している未読メッセージ「忘年会のお知らせ」を乙が選択し、受信メッセージ画面で本文を閲覧した場合、以降の受信トレイ画面１２０では当該メッセージのカプセルの点滅は停止する。このように受信トレイ画面１２０では、開示条件付きメッセージの演出として、亀裂なしのカプセル→開示日が近づくにつれてカプセルに亀裂が入る→カプセルが割れて点滅する状態→カプセルが割れた状態（点滅なし）を表示する。

メッセージ交換アプリケーション１００が起動されたときに、新たに開示条件が充足した（開示フラグが０から１に更新された）メッセージがあれば、メッセージ交換アプリケーション１００のトップ画面表示部（不図示）は、アプリケーションのトップ画面においてカプセルが割れるアニメーションを表示させてもよい。アニメーション表示後、受信トレイ表示部６４は、カプセルが割れて点滅している当該未読メッセージを含む受信トレイ画面１２０を表示させてもよい。また受信メッセージ表示部６６は、当該未読メッセージの本文を受信メッセージ画面１１０に表示させてもよい。

このように、メッセージ交換アプリケーション１００では、通常のメーラ等と異なり、メッセージ開示までの期間の長短を示唆する演出を表示させる。例えば、メッセージの開示タイミングが近づくと、その旨を示唆する態様で、受信メッセージ画面１１０および受信トレイ画面１２０の予告画像を変化させる。これにより、メッセージが開示されるまでの間に受信者の期待感を醸成し、またその期待感を徐々に高めていくことができる。また、新たに開示条件が充足したメッセージの存在をユーザが一目で把握できるよう演出を実行する。新たに閲覧可能になったメッセージの存在を積極的にユーザに示すことにより、当該メッセージの閲覧をユーザに促し、また、開示条件が充足するまでの間の演出で醸成したユーザの期待感をさらに高めることができる。

図９は、送信トレイ表示部５２が表示する送信トレイ画面を示す。送信トレイ表示部５２は、送信トレイ画面１３０に送信予定ボタン１３２と送信済ボタン１３４を配置する。送信予定ボタン１３２は、開示条件が付与され、現在受信側ユーザに未開示のメッセージを一覧表示させるボタンである。送信済ボタン１３４は、開示条件がもともと付与されないメッセージ、および、開示条件が付与されたものの、開示条件が満たされて現在受信側ユーザに開示済のメッセージを一覧表示させるボタンである。図９では、甲が送信予定ボタン１３２を選択した状態を示している。送信トレイ表示部５２は、送信メッセージ保持部４０に格納された各メッセージの開示条件を参照し、予告画像１２２と同様の予告画像１３６を各メッセージに付加する。すなわち、開示条件充足までの残り期間に応じて予告画像１３６の態様を変化させる。

また、送信トレイ表示部５２は、開示条件付きメッセージの開示条件が満たされて開示フラグが「１」になった場合、当該メッセージを、送信済ボタン１３４選択時の画面で表示させるよう切替える。送信トレイ表示部５２は、開示条件が満たされて開示フラグが「１」になったメッセージを、開示条件が付されないメッセージとは異なる態様で表示させてもよい。例えば、図８と同様に、割れたカプセルを示す予告画像１３６を付加して表示させてもよい。なお、図９で示した送信予定ボタン１３２選択時の送信トレイ画面１３０で表示されるメッセージは、後述の第１の変形例で示す編集・改変可能なメッセージとなる。

実施の形態のメッセージ交換システム１０によると、メールを書いて保存したときと将来それを配信するときの間に時間差があるという点に着目した、利便性の高いメッセージ配信サービスを提供できる。例えば、メッセージの受信側ユーザに対して、メッセージの内容を実際に開示する前に、将来時点で開示予定である旨を予告する。言い換えれば、将来時点で開示されるメッセージが届いた事実を通知する。これにより、メッセージが将来配信される相手に期待感をもたせ、ないし準備をさせることができる。

また、送信メッセージの一覧表示画面において、開示条件付きのメッセージであり、現在受信側ユーザに非開示のメッセージを、開示条件なしのメッセージおよび受信側ユーザに開示済のメッセージと異なる態様で表示させる。これにより、開示条件付きのメッセージについて、受信側ユーザによる閲覧状況を送信側ユーザが容易に把握することを支援でき、その状況を踏まえたアクションを送信側ユーザが実施することを支援できる。

また、受信メッセージの一覧表示画面において、開示条件付きのメッセージであり、現在受信側ユーザに非開示のメッセージを、開示条件なしのメッセージおよび受信側ユーザに開示済のメッセージと異なる態様で表示させる。これにより、開示条件付きのメッセージの存在を受信側ユーザが容易に把握することを支援でき、事前の心づもりや、開示条件付きのメッセージが届いている状況を踏まえたアクションを受信側ユーザが実施することを支援できる。

（第２の実施の形態）
上記第１の実施の形態のメッセージ配信サーバ１４は、開示条件付きのメッセージを受け付けた際に、予告メッセージとともに本メッセージを宛先のユーザ端末１２へ送信した。これに対し、第２の実施の形態のメッセージ配信サーバ１４は、開示条件が満たされるまではメッセージ本文の配信を抑制して予告メッセージのみを配信する。第２の実施の形態のメッセージ交換システム１０、ユーザ端末１２、メッセージ配信サーバ１４の構成は、第１の実施の形態と同様である。

具体的には、メッセージ配信サーバ１４のカプセルメッセージ送信部９０は、開示条件付きのメッセージを受け付けた際に、予告メッセージをユーザ端末１２へ送信する一方、本メッセージをユーザ端末１２へ送信することを抑制して、宛先のユーザ端末１２において予告メッセージを表示させる。カプセルメッセージ送信部９０は、開示判定部８６により開示条件が満たされたことが判定された際に、送信メッセージ保持部４０に記憶された本メッセージをユーザ端末１２へ送信して、宛先のユーザ端末１２において本メッセージを表示させる。カプセルメッセージ送信部９０は、予告メッセージを示す電子メールと、その予告メッセージに対応する本メッセージを示す電子メールのメッセージＩＤを同一の値に設定してもよい。ユーザ端末１２の受信メッセージ表示部６６は、メッセージＩＤにより先に受信した予告メッセージの第１メールと、後に受信した本メッセージの第２メールを対応づけ、第２メールを受信した場合にそれまでの予告メッセージに代えて本メッセージを受信メッセージ画面に表示させてもよい。

第２の実施の形態の構成でも、第１の実施の形態と同様の効果を奏する。また、開示条件が満たされるまではメッセージ本文を宛先へ配信しないため、開示条件が満たされるまでのメッセージ本文の秘匿を一層確実なものにできる。また第２の実施の形態では、メッセージ配信サーバ１４が予告メッセージの配信と、本メッセージの配信を時間的に分離するため、ユーザ端末１２のメッセージ受信処理部２４は、一般的なメッセージクライアントや、電子メールクライアント（メーラ）で実現できる。

第１の実施の形態と第２の実施の形態の両方に適用可能な技術として、好ましくは、一般的なメッセージクライアントを使用するユーザに対しても予告メッセージを配信する一方、メッセージ交換アプリケーション１００を導入済のユーザに限定して本メッセージを配信する。具体的には、メッセージ配信サーバ１４は、メッセージ交換アプリケーション１００を自端末に導入した利用者情報（ＩＤやメールアドレス等）を所定の記憶領域に保持する。ユーザが所定のデジタルコンテンツ配信サイトからメッセージ交換アプリケーション１００をダウンロードして自端末にインストールすると、当該ユーザの情報が上記利用者情報へ追加される。メッセージ配信サーバ１４は、利用者情報を参照して、開示条件付きメッセージの宛先ユーザがメッセージ交換アプリケーション１００をインストール済か否かを判定する宛先判定部をさらに備える。

メッセージ配信サーバ１４のカプセルメッセージ送信部９０は、宛先ユーザがメッセージ交換アプリケーション１００を導入済か否かにかかわらず、宛先ユーザへ予告メッセージを配信する。ただし、メッセージ交換アプリケーション１００を導入済のユーザには、図７の（ａ）で示したような予告メッセージを配信する一方、メッセージ交換アプリケーション１００を未導入のユーザには、図７の（ａ）の内容に加え、メッセージ交換アプリケーション１００の導入を促進する情報を付加する。例えば、「メッセージ本文の閲覧にはメッセージ交換アプリケーションのインストールが必要です」等のメッセージや、ダウンロードサイトのＵＲＬ文字列を付加してもよい。

また、カプセルメッセージ送信部９０は、宛先ユーザがメッセージ交換アプリケーション１００を導入済であること、すなわち利用者情報に登録済であることを条件として、宛先ユーザへ本メッセージを配信する。第１の実施の形態では、開示条件が満たされたか否かにかかわらず、本メッセージを宛先ユーザへ即時配信し、第２の実施の形態では、開示条件が満たされたことを条件として、本メッセージを宛先ユーザへ配信する。

この態様によると、メッセージ交換アプリケーション１００を未使用のユーザに対して、一般的なメッセージクライアント（メーラ等）により予告メッセージを閲覧可能としつつも、本メッセージの閲覧を禁止することができる。すなわち、メッセージ交換アプリケーション１００を未使用のユーザは、予告されたメッセージを閲覧することができない。これにより、ユーザ端末１２へのメッセージ交換アプリケーション１００のダウンロードおよびインストールを促進できる。また、予告が来ることで、「こんなサービスがあるのか」と思って、メッセージ交換アプリケーション１００を調べ、またダウンロードする人が出てくる。それがメッセージ交換アプリケーション１００（すなわち実施の形態のメッセージ交換システム１０に関する装置や方法）を普及させる力になる。

なお、メッセージ交換アプリケーション１００を未導入のユーザを指定する宛先情報として、通常のメールアドレスが使用されてもよい。また、メッセージ交換アプリケーション１００を導入済のユーザを指定する宛先情報として、メッセージ交換システム１０がユーザ毎に独自で割り当てた独自アドレスが使用されてもよい。メッセージ配信サーバ１４のカプセルメッセージ送信部９０は、送信者が宛先情報として通常のメールアドレスを指定した場合に、メッセージ交換アプリケーション１００未導入のユーザ向けの処理を実行し、送信者が宛先情報として独自アドレスを指定した場合に、メッセージ交換アプリケーション１００導入済のユーザ向けの処理を実行してもよい。

以上、本発明を第１および第２の実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

第１の変形例を説明する。まず、第１の実施の形態において開示条件付きメッセージの事後的な変更（編集・改変）を実現する方法を説明する。ユーザ端末１２のメッセージ送信処理部２２は、メッセージ変更部をさらに含んでもよい。この変形例の送信メッセージ表示部５４は、既に送信した開示条件付きのメッセージを変更・編集するためのメッセージ変更画面を表示させる。メッセージ変更部は、開示条件付きのメッセージについて、その開示フラグが「０」であることを条件として、メッセージ変更画面に入力された変更・編集内容を受け付け、送信メッセージ保持部４０に記録し、それまでのメッセージデータを上書き更新する。またメッセージ変更部は、変更対象のメッセージのＩＤを指定し、変更後のメッセージ本文・タイトルを含む変更要求をメッセージ配信サーバ１４へ送信する。なお、ユーザが変更対象としたメッセージの開示フラグが「１」の場合、メッセージ変更部および送信メッセージ表示部５４は、メッセージが受信側ユーザに開示済であるため変更ができない旨を画面に表示させてもよい。これにより、メッセージが開示済という状況に応じた対応を送信側ユーザに実施させることができる。

メッセージ配信サーバ１４のメッセージ記録部８４は、メッセージ保持部８０に保持されたメッセージのうち、変更要求で指定されたＩＤで特定されるメッセージについて、その開示条件が未充足（開示フラグが「０」）である場合に、その本文・タイトルを変更要求が示す内容に置き換える。メッセージ配信サーバ１４のカプセルメッセージ送信部９０は、変更要求で指定されたＩＤ、本文、タイトルを含む置換用メッセージデータを宛先の受信側ユーザのユーザ端末１２へ送信する。受信側ユーザのユーザ端末１２の受信メッセージ記録部６０は、受信メッセージ保持部５６に保持されたメッセージのうち、置換用メッセージデータで指定されたＩＤにより特定されるメッセージについて、その本文・タイトルを置き換える。これにより、開示条件付きメッセージ送信後の状況変化に応じた、事後的なメッセージの変更を実現できる。

第２の実施の形態においても、上記の第１の変形例に示したメッセージ変更の構成を適用可能であり、開示条件付きメッセージの事後的な変更を実現できる。第２の実施の形態では、開示条件が満たされるまで開示条件付きメッセージの本文を受信側ユーザのユーザ端末１２へ提供しない。したがって、メッセージ配信サーバ１４のメッセージ保持部８０に記憶されたメッセージの本文やタイトルを変更すればよい。

第２の変形例として、メッセージ交換システム１０におけるメッセージ配信サーバ１４はウェブアプリケーションサーバであってもよく、ユーザ端末１２はウェブブラウザを搭載したウェブクライアントであってもよい。言わばウェブメールシステムとして実現されてもよい。この場合、メッセージの本文やタイトル、各種フラグはメッセージ配信サーバ１４が一元的に管理してもよい。またメッセージ配信サーバ１４は、図２に記載した画面生成機能を一括して保持してもよい。すなわちメッセージ配信サーバ１４は、各ユーザの送信トレイ画面、送信メッセージ画面、受信トレイ画面、受信メッセージ画面等のウェブページを一括して生成し、メッセージ送信元およびメッセージ送信先のユーザ端末１２へ提供して、各端末のウェブブラウザ画面で表示させてもよい。

第３の変形例を説明する。上記実施の形態では、開示条件として日時条件と気象条件を例示したが、開示条件はこれに留まらない。例えば、開示条件として、メッセージ送信先の相手の状態を指定してもよく、具体的には相手の機嫌がよいこと、相手の機嫌がよい場合にメッセージを送信することを指定してもよい。ここでは、第１メッセージの送信側ユーザ（送信元）を甲、受信側ユーザ（宛先）を乙とし、その開示条件として乙の機嫌がよいことが指定されるとする。メッセージ配信サーバ１４の開示判定部８６は、所定のアルゴリズムにしたがって、乙の機嫌がよいと判定した場合に、第１メッセージの開示条件が満たされたと判定し、メッセージ保持部８０の開示フラグを「１」に変更してもよい。

ある態様として、開示判定部８６は、第１メッセージがメッセージ配信サーバ１４で受信された後に、送信側ユーザを乙とする第２メッセージを受信した場合、その内容（タイトルや本文等）を参照する。開示判定部８６は、受信側ユーザが甲であることを加重条件として第２メッセージを識別してもよい。開示判定部８６は、第２メッセージに機嫌がよいことを示す所定のキーワード（楽しい、うれしい等）や、所定の画像（笑顔のスタンプ等）が含まれる場合に、乙の機嫌がよいと判定する。別の態様として、メッセージ配信サーバ１４は、甲・乙等の各ユーザが自端末に入力した機嫌がよい〜悪いの加減を示す指標値（とても良い、少し良い、普通、少し悪い、とても悪い等）をユーザ端末１２から取得し、所定の記憶領域に記録する。開示判定部８６は、その指標値を参照して、乙の機嫌がよいか否か、言い換えれば、第１メッセージの開示条件が満たされたか否かを判定する。例えば、「とても良い」または「少し良い」場合に、第１メッセージの開示条件が満たされたと判定してもよい。

第４の変形例を説明する。上記実施の形態では、開示条件の充足有無をメッセージ配信サーバ１４で判定することとした。変形例として、開示事情件の充足有無をユーザ端末１２（送信者端末または受信者端末）が判定してもよい。メッセージ配信サーバ１４の判定主体決定部８５は、メッセージ作成画面において判定主体をユーザ端末１２とすることを送信者が指定した場合に、ユーザ端末１２を判定主体として決定してもよい。また判定主体決定部８５は、開示条件が所定の条件であった場合に、ユーザ端末１２を判定主体として自律的に決定してもよい。このときの開示条件は、ユーザ端末１２の各種センサ（温度センサ、脈拍センサ等）や各種デバイス（ＧＰＳ等を利用する位置測位装置）を使用して充足有無を判定可能な条件であってもよい。例えば、受信者（または送信者）が、特定の地域・場所にいることや、周囲の気温が３０度以上であること、心拍数が高いこと（例えば１４０拍／分以上のとき）であってもよい。また、受信者が疲れているとき等の定性的な開示条件が指定されてもよい。この場合、ユーザ端末１２の開示条件付与部４６またはメッセージ配信サーバ１４のメッセージ記録部８４は、心拍数が１４０以上等の定量的な条件に置き換えて開示条件を記録してもよい。

この変形例では、ユーザ端末１２は、メッセージ配信サーバ１４の開示判定部８６と同様の開示条件判定部を備える。メッセージ配信サーバ１４の判定主体決定部８５は、ユーザ端末１２の開示条件判定部に、開示条件を通知し、開示条件の充足有無を判定させる。ユーザ端末１２の開示条件判定部は、各種のセンサやデバイスが検知した情報に応じて開示条件の充足有無を判定し、開示条件が充足した場合、その事実を示す情報をメッセージ配信サーバ１４へ送信する。メッセージ配信サーバ１４の開示判定部８６は、この情報を受信すると、実施の形態と同様に開示条件充足時の処理を実行し、受信者端末におけるメッセージ本文の閲覧を可能にする。この変形例によると、メッセージの送信者や受信者の様々な状態を開示条件として、メッセージの配信を制御することができる。

このようにユーザ端末１２に開示条件判定部を備えることで、例えばランニング中の友人が坂道を登っている最中に応援メッセージを届けるようなことができる。受信者のおかれた状況に応じてメッセージを届けることで、単にメッセージを届けるよりも暖かみや思いやりを強く感じさせ、効果的に思いを伝えることができる。

第５の変形例を説明する。上記実施の形態では、開示条件付きメッセージ毎の予告メッセージをメッセージ配信サーバ１４のメッセージ記録部８４が生成し、メッセージ記録部８４に記録することとした。変形例として、メッセージ記録部８４に代わってカプセルメッセージ送信部９０が、あるメッセージに関する予告メッセージの送信タイミングに至る都度、そのメッセージの開示条件に応じた予告メッセージを生成し、宛先のユーザ端末１２へ送信してもよい。

上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。

請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。例えば、請求項に記載の予告部は、実施の形態に記載のメッセージ配信サーバ１４のカプセルメッセージ送信部９０により実現される。また、請求項に記載の開示部は、実施の形態に記載のメッセージ配信サーバ１４の開示通知部９２により実現される。

１０ メッセージ交換システム、 １２ ユーザ端末、 １４ メッセージ配信サーバ、 ４２ メッセージ作成部、 ４８ メッセージ送信部、 ５１ ステータス更新部、 ５２ 送信トレイ表示部、 ５４ 送信メッセージ表示部、 ５８ メッセージ受信部、 ６２ ステータス更新部、 ６４ 受信トレイ表示部、 ６６ 受信メッセージ表示部、 ８２ メッセージ受信部、 ８５ 判定主体決定部、 ８６ 開示判定部、 ８８ メッセージ送信部、 ９０ カプセルメッセージ送信部、 ９２ 開示通知部。

Claims (2)

1. 送信側ユーザ甲の装置から送信された、受信側ユーザ乙宛のメッセージと、前記メッセージの開示条件を受信する受信部と、
   前記メッセージが現在は開示されないが将来開示される旨を示唆する予告情報を乙の装置に表示させる予告部と、
   前記開示条件が満たされた場合に前記メッセージを乙の装置に表示させる開示部と、
   前記メッセージを閲覧するための所定のアプリケーションを自身の装置に導入したユーザの情報を記憶する記憶部と、
   を備え、
   前記開示部は、乙が前記アプリケーションを導入済であることをさらなる条件として、前記メッセージを乙の装置に表示させ、
   前記予告部は、乙が前記アプリケーションを未導入の場合、前記メッセージが届いていることを示す内容に加えて、前記アプリケーションの導入を促す内容を含む予告情報を乙の装置に表示させることを特徴とするメッセージ配信サーバ。
2. 甲による入力内容に応じて、前記開示条件が満たされたか否かを本サーバが判定するか、または、前記乙の装置が判定するかを決定する判定主体決定部をさらに備えることを特徴とする請求項１に記載のメッセージ配信サーバ。

Images