JP6462085B2 - メッセージ配信サーバおよびメッセージの送信装置 - Google Patents

Description

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

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

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

上記特許文献１の仕組みにより、送信側ユーザの甲は任意の指定日時に受信者側ユーザの乙へ第１の電子メールを配送させることができる。しかしながら本発明者は、第１の電子メールが実際に乙へ配送される前に、乙から甲への第２の電子メールが配送されることがあり得ることに想到し、第２の電子メールの後から第１の電子メールが配送されると、甲と乙との意思疎通を却って阻害しかねないと考えた。

上記課題を解決するために、本発明のある態様のメッセージ配信サーバは、送信側ユーザ甲の装置から送信された、受信側ユーザ乙宛のメッセージと、メッセージの開示条件を受信する受信部と、開示条件が満たされた場合にメッセージを乙の装置へ送信する送信部と、開示条件が満たされる前に、乙から甲宛の連絡がなされたことを示す情報が受け付けられた場合に、メッセージを乙の装置へ送信することを中止させる制御部と、を備える。

本発明の別の態様は、メッセージの送信装置である。この装置は、送信側ユーザ甲による、受信側ユーザ乙宛のメッセージと、メッセージの開示条件の入力を受け付ける受付部と、開示条件を付与したメッセージをサーバへ送信することにより、開示条件が満たされた場合にメッセージを乙の装置へ送信する処理をサーバに実行させる送信部と、を備える。送信部は、甲の入力内容に応じて所定の配信中止オプションをさらに付与したメッセージをサーバへ送信することにより、開示条件が満たされる前に、乙から甲宛の連絡がなされたことを示す情報が受け付けられた場合に、メッセージを乙の装置へ送信することを中止させる。

本発明のさらに別の態様は、メッセージ配信サーバである。このメッセージ配信サーバは、送信側ユーザ甲の装置から送信された、受信側ユーザ乙宛のメッセージと、メッセージの開示条件を受信する受信部と、開示条件が満たされた場合に、乙の装置においてメッセージを開示させる開示部と、開示条件が満たされる前に、乙から甲宛の連絡がなされたことを示す情報が受け付けられた場合に、乙の装置におけるメッセージの開示を中止させる制御部と、を備える。

本発明のさらに別の態様は、メッセージの送信装置である。この装置は、送信側ユーザ甲による、受信側ユーザ乙宛のメッセージと、メッセージの開示条件の入力を受け付ける受付部と、開示条件を付与したメッセージをサーバへ送信することにより、開示条件が満たされた場合に、乙の装置においてメッセージを開示させる処理をサーバに実行させる送信部と、を備える。送信部は、甲の入力内容に応じて所定の配信中止オプションをさらに付与したメッセージをサーバへ送信することにより、開示条件が満たされる前に、乙から甲宛の連絡がなされたことを示す情報が受け付けられた場合に、乙の装置におけるメッセージの開示を中止させる。

本発明のさらに別の態様は、メッセージ配信サーバである。このメッセージ配信サーバは、送信側ユーザ甲の装置から送信された、受信側ユーザ乙宛のメッセージを受信し、所定の記憶領域に保存する受信部と、乙宛のメッセージの保存後、そのメッセージの乙への送信よりも前に、乙の装置から甲宛のメッセージが送信された場合、乙宛のメッセージの送信を中止する送信部と、を備える。

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

本発明によれば、第１の利用者からのメッセージを将来時点において第２の利用者へ配信するシステムにおける利用者の利便性を向上させることができる。

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

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

ここで甲から乙宛に特定の日時に至ることを開示条件とするメッセージであり、イベントへの出欠有無の連絡を督促するリマインドメッセージを受け付けたとする。通常、上記日時に至ればリマインドメッセージを乙へ配信すればよい。しかし、上記日時に至る前に、乙から甲宛にイベントへの出席または欠席を示すメッセージが送信されることがある。この場合、上記日時にリマインドメッセージを乙へ配信してしまうと、既に出欠連絡したにもかかわらず督促を受けた乙は気分を害してしまいかねない。連絡の行き違いを予め断る文面がリマインドメッセージに記載されることもあるが、異なる企業間や組織間でメッセージが送受される場合等、円滑な人間関係を阻害することにもなりかねない。

そこで、実施の形態のメッセージ交換サービスでは、甲から開示条件付きのメッセージを受け付け、その開示条件が満たされてメッセージの内容を乙へ開示する前に、乙から甲への連絡行動、具体的にはメッセージの送信がなされた場合、甲からの上記メッセージを乙へ配信することを中止する。すなわち、乙から甲へのメッセージ送信によって、もはや送信すべきでなくなった甲から乙へのメッセージの送信を抑制する。これにより、メッセージの行き違いや不整合の発生を防止し、サービス利用者の利便性を向上させる。

「メッセージ」は、電子メールデータやプレーンテキスト、所定フォーマットの文書データ等、様々な公知の形態を含む。また、実施の形態のメッセージ交換サービスの仕組みは、様々な情報処理システム・サービスに適用可能である。例えば、電子メールシステム、インスタントメッセージサービス、ショートメッセージサービス、マルチメディアメッセージングサービスに適用することができる。

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

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

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

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

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

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

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

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

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

図３は、送信メッセージ保持部４０に保持されるデータの構成を示す。同図の（ａ）は、メッセージの基本情報を保持するテーブルであり、全てのメッセージについて値が設定される。ＩＤ欄には、メッセージをユニークに特定可能なメッセージＩＤが格納される。Ｆｒｏｍ欄にはメッセージ送信者（送信元のユーザ端末１２）の識別情報、Ｔｏ欄にはメッセージ受信者（宛先のユーザ端末１２）の識別情報が格納される。識別情報は、各種のネットワークアドレス、装置識別子、メールアドレス等でもよい。メッセージ欄には、メッセージの本文やタイトルが格納される。カプセルフラグ欄には、開示条件が付された言わばカプセルメッセージか（値１）、開示条件が付与されない言わば通常メッセージか（値０）を示す値が格納される。

図３の（ｂ）は、開示条件が付されたメッセージの属性情報を保持する拡張テーブルであり、カプセルフラグ＝１のメッセージについて値が設定される。同図の「−」は値が未設定であることを示す。開示条件欄には、ユーザがメッセージに付与した開示条件を示すデータが格納される。開示フラグ欄には、開示条件が充足されたか否か、言い換えれば、開示条件が付されたメッセージが受信側ユーザに未開示か（値０）、もしくは開示済か（値１）を示す値が格納される。

送信中止ＯＰフラグ欄には、ユーザがメッセージの配信に対して送信中止オプションを選択したか（値１）、未選択か（値０）を示す値が格納される。送信中止済フラグ欄には、メッセージの配信が中止されたか（値１）否か（値０）を示す値が格納される。送信中止オプションは、開示条件の充足前に、当該メッセージの受信者から送信者へのメッセージ送信、すなわち当該メッセージとは逆方向のメッセージ伝達がなされた場合に、当該メッセージの送信中止を指定するオプションである。送信中止オプションの選択は、開示条件の付与が前提となる。送信中止ＯＰフラグが「０」であれば、メッセージの配信中止処理はなされず、送信中止済フラグ欄は未設定とする。また、開示フラグが「０」で、かつ送信中止済フラグが「０」は、開示条件の充足待ちであり、開示条件が充足されればメッセージが配信される状態であることを示す。

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

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

図２に戻り、メッセージ作成部４２は、メッセージの作成に関する処理を実行する。メッセージ作成部４２は、作成画面表示部４４、開示条件付与部４６、送信中止ＯＰ付与部４７を含む。作成画面表示部４４は、開示条件の入力エリアと、送信中止オプションの選択エリアを含むメッセージ作成画面をディスプレイに表示させる。メッセージ作成画面には、メッセージの受信者側ユーザの識別情報やメッセージのタイトル、本文が入力される。開示条件設定エリアには、上述したように様々な態様の開示条件が任意で入力される。送信中止オプションの選択エリアには、送信中止オプションの選択有無が入力される。デフォルトでは送信中止オプションを未選択とし、ユーザは任意で送信中止オプションを選択し、有効にする。

メッセージ作成部４２は、メッセージ作成画面へユーザが入力したデータにしたがって、宛先情報やメッセージのタイトル、本文を含む送信用のメッセージデータを生成する。開示条件付与部４６は、メッセージ作成画面の開示条件入力エリアに開示条件が入力された場合に、その開示条件を示す開示条件データをメッセージデータに付加する。送信中止ＯＰ付与部４７は、送信中止オプションが選択された場合に、送信中止オプションが選択されたことを示すオプション選択データをメッセージデータに付加する。

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

送信メッセージ記録部５０は、メッセージ送信部４８により送信されたメッセージデータを送信メッセージ保持部４０に格納し、カプセルフラグ、開示条件、開示フラグ、送信中止ＯＰフラグ、送信中止済フラグの値をメッセージデータにしたがって設定する。例えば、メッセージデータが開示条件データを含む場合、カプセルフラグを「１」とし、開示フラグには初期値「０」を設定する。また、メッセージデータがオプション選択データを含む場合、送信中止ＯＰフラグを「１」とし、送信中止済フラグには初期値「０」を設定する。

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

送信トレイ表示部５２は、自装置からメッセージ配信サーバ１４へ送信したメッセージの一覧画面である送信トレイ画面をディスプレイに表示させる。言い換えれば、自装置から他のユーザ端末１２宛に送信したメッセージの履歴を表示させる。具体的には、送信トレイ表示部５２は、送信メッセージ保持部４０に格納されたデータを参照して、送信メッセージの種類や送信状況に応じた態様で各メッセージのタイトルを並べた送信トレイ画面を表示させる。送信トレイ表示部５２は、送信トレイ画面において、少なくとも、メッセージ配信サーバ１４へ送信した開示条件付きメッセージのうち、当該メッセージの受信側ユーザからの連絡がなされたことに起因してメッセージ配信サーバ１４が送信を中止したメッセージ（以下、「送信中止メッセージ」とも呼ぶ。）を、他のメッセージとは異なる態様で表示させる。

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

実施の形態では、送信トレイ表示部５２は、送信トレイ画面において、（１）開示条件が付与されずに送信されたメッセージ、言わば通常の送信済メッセージと、（２）開示条件が付与され、現在開示済のメッセージを、「開示済メッセージ」グループを示す第１の態様で表示させる。また、（３）開示条件が付与され、現在未開示で、送信中止となっていないメッセージを、「未開示メッセージ」グループを示す第２の態様で表示させる。また、（４）開示条件が付与され、送信中止オプションが選択され、送信中止となったメッセージを、「送信中止メッセージ」グループを示す第３の態様で表示させる。

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

送信トレイ表示部５２は、以下のようにメッセージの種別を判定する。
（１）のメッセージ：カプセルフラグ＝０
（２）のメッセージ：カプセルフラグ＝１＆開示フラグ＝１
（３）のメッセージ：カプセルフラグ＝１＆開示フラグ＝０＆送信中止ＯＰフラグ＝０、または、カプセルフラグ＝１＆開示フラグ＝０＆送信中止ＯＰフラグ＝１＆送信中止済フラグ＝０
（４）のメッセージ：カプセルフラグ＝１＆開示フラグ＝０＆送信中止ＯＰフラグ＝１＆送信中止済フラグ＝１

既述したように、送信トレイ表示部５２は、（１）のメッセージと（２）のメッセージの双方を同じ態様で表示させる。（２）のメッセージの開示条件は既に満たされており、閲覧制限は解除されているため、ユーザにとって通常の送信済メッセージと区別する必要がなく、むしろ通常の送信済メッセージと同じ態様で表示させた方がユーザの利便性が高いからである。

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

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

受信メッセージ保持部５６は、メッセージ配信サーバ１４から受信した１つ以上のメッセージについて、各メッセージの本文と各種属性情報を保持する。受信メッセージ保持部５６は、受信メッセージの履歴を保持するとも言える。受信メッセージ保持部５６に格納されるデータの構成は、図３の（ａ）に示すＩＤ〜メッセージであってもよい。

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

受信トレイ表示部６４は、自装置がメッセージ配信サーバ１４から受信したメッセージの一覧画面である受信トレイ画面をディスプレイに表示させる。受信メッセージ表示部６６は、受信メッセージ画面をディスプレイに表示させる。受信メッセージ表示部６６は、受信トレイ画面においてユーザが選択したメッセージについて、その本文、タイトル、送信元情報等の表示対象データを受信メッセージ保持部５６から取得し、これらのデータを受信メッセージ画面１１０に表示させる。

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

メッセージ中継部７２は、メッセージ保持部８０、メッセージ受信部８２、メッセージ記録部８４、開示判定部８６、送信中止制御部８７、メッセージ送信部８８、送信状況通知部９２を含む。

メッセージ保持部８０は、メッセージ受信部８２が受信したメッセージの本文と各種属性情報を保持する。メッセージ保持部８０は、ユーザ端末１２間でやりとりされるメッセージの履歴を保持するとも言える。メッセージ保持部８０に保持されるデータの構成は、ユーザ端末１２の送信メッセージ保持部４０に保持されるデータの構成（図３を参照）と同じとする。

メッセージ受信部８２は、ユーザ端末１２から送信されたメッセージデータを受信する。メッセージ記録部８４は、メッセージ受信部８２が受信したメッセージデータをメッセージ保持部８０に格納する。メッセージ記録部８４は、ユーザ端末１２の送信メッセージ記録部５０と同様に、メッセージデータにしたがってメッセージ保持部８０の各項目値（図３を参照）を設定する。例えば、開示条件および送信中止オプションが付与されたメッセ−の場合、カプセルフラグ＝１、開示フラグ＝０、送信中止ＯＰフラグ＝１、送信中止済フラグ＝０を初期値として設定する。

開示判定部８６は、メッセージ保持部８０に格納されたメッセージのうち、開示条件がそれまで未充足であり、送信中止対象外のメッセージついて、現時点で開示条件が充足されたか否かを定期的に判定する。具体的には、カプセルフラグ＝１＆開示フラグ＝０＆送信中止ＯＰフラグ＝０、または、カプセルフラグ＝１＆開示フラグ＝０＆送信中止ＯＰフラグ＝１＆送信中止済フラグ＝０のメッセージを判定対象として識別する。送信中止済フラグ＝１のメッセージは判定対象外とする。開示判定部８６は、開示条件が充足されたと判定したメッセージが存在する場合、そのメッセージの開示フラグを「１」に変更する。

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

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

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

送信中止制御部８７は、開示条件および送信中止オプションが付されたメッセージについて、その開示条件が満たされる前に、当該メッセージの宛先ユーザから送信元ユーザ宛の連絡がなされたことを示す情報が受信されて、所定の記憶装置に記録された場合に、当該メッセージを宛先ユーザの装置へ送信することを中止させる。この記憶領域は、メインメモリ、キャッシュメモリ、ストレージ、外部記憶装置等、各種の記憶装置が提供するデータ記憶領域のうち予め定められた領域であってよい。送信中止制御部８７は、第１メッセージの開示条件充足前に、第１メッセージの宛先ユーザから送信元ユーザ宛に第２メッセージの送信がなされたか否かを判定し、第２メッセージの送信がなされた事実を検出すると、開示条件の充足有無にかかわらず第１メッセージの配信を中止させる。

具体的には、送信中止制御部８７は、メッセージ保持部８０を参照し、カプセルフラグ＝１＆開示フラグ＝０＆送信中止済フラグ＝０のメッセージを判定対象メッセージとして識別し、判定対象メッセージ毎に以下の処理を実行する。送信中止制御部８７は、判定対象メッセージの送信元識別情報（Ｆｒｏｍ）と宛先識別情報（Ｔｏ）を特定する。そして、判定対象メッセージの記録後（メッセージ配信サーバ１４での受信後）に記録されたメッセージの中に、判定対象メッセージの送信元識別情報を宛先として指定し、かつ、判定対象メッセージの宛先識別情報を送信元として指定するメッセージが存在するか否かを判定する。すなわち、判定対象メッセージとは逆方向に伝送されるメッセージの存在有無を判定する。存在する場合、判定対象メッセージの送信中止済フラグを「１」に変更する。

送信中止制御部８７は、開示条件が付され、開示条件が未充足の全メッセージに対して上記判定処理を定期的に（例えば１時間おきに）実行してもよい。また、開示判定部８６が、あるメッセージの開示フラグを「１」へ変更した際に、そのメッセージを判定対象メッセージとして上記判定処理を実行してもよい。また、送信中止の精度を一層高めるために、両方のタイミングで上記判定処理を実行してもよい。

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

具体的には、メッセージ送信部８８は、メッセージ保持部８０を監視し、カプセルフラグ＝０のメッセージが新たに格納されたことを検出すると、当該メッセージを即時に宛先のユーザ端末１２へ送信する。その一方、カプセルフラグ＝１のメッセージについては、開示フラグが「１」へ変更されたことを検出した場合に、当該メッセージを宛先のユーザ端末１２へ送信する。メッセージ送信部８８は、送信中止済フラグが「１」へ変更されたメッセージについては、開示済フラグの値にかかわらず宛先のユーザ端末１２への送信を中止し、すなわち送信対象から除外する。

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

また送信状況通知部９２は、開示条件が付されたメッセージついて、その開示条件充足前に、宛先ユーザから送信元ユーザへの連絡がなされたことに起因して送信を中止した場合に、その旨を示す情報を送信元ユーザのユーザ端末１２へ送信する。言い換えれば、開示条件が付されたメッセージのうち、宛先ユーザへの配信を中止したメッセージ（ここでは「送信中止メッセージ」と呼ぶ。）の情報であり、例えばＩＤおよび送信中止の事実を送信元ユーザのユーザ端末１２へ送信する。送信状況通知部９２は、メッセージ保持部８０を監視し、送信中止制御部８７により送信中止済フラグが「０」から「１」へ変更されたメッセージを送信中止メッセージとして検出する。

以上の構成によるメッセージ交換システム１０の動作を説明する。ここでは、ユーザ甲が使用する端末（ユーザ端末１２ａ）から、ユーザ乙が使用する端末（ユーザ端末１２ｂ）へ、開示条件なしのメッセージを送信する。また、甲から、ユーザ丙が使用する端末（ユーザ端末１２ｃ）へ、開示条件および送信中止オプション付きのメッセージを送信する。さらにまた、甲から、ユーザ丁が使用する端末（ユーザ端末１２ｄ）へ、開示条件および送信中止オプション付きのメッセージを送信する。すなわち、メッセージの送信側装置をユーザ端末１２ａとし、受信側装置をユーザ端末１２ｂ、１２ｃ、１２ｄとする。開示条件は共通とし、１２月２０日８時に送ることが指定される。

甲は、ユーザ端末１２ａにてメッセージ交換アプリケーション１００の画面を起動し、その画面でメッセージの作成を選択する。ユーザ端末１２ａのメッセージ作成部４２はメッセージ作成画面を表示させる。甲は、メッセージ作成画面において、乙・丙・丁それぞれへのメッセージを入力し、丙・丁宛のメッセージについては開示条件を設定し、送信中止オプションも選択する。メッセージ送信部４８は、乙・丙・丁への３つのメッセージデータをメッセージ配信サーバ１４へ送信し、送信メッセージ記録部５０は、各メッセージデータを送信メッセージ保持部４０へ記録する。このとき丙・丁へのメッセージについては開示フラグを「０」、送信中止済フラグを「０」に設定する。なお、丙・丁宛のメッセージが同一内容であれば、１回メッセージを作成して丙と丁の両方のアドレスを指定する等により、同報送信してもよいことはもちろんである。

メッセージ配信サーバ１４のメッセージ受信部８２は、ユーザ端末１２ａから送信された乙・丙・丁への３つのメッセージデータを受信し、メッセージ記録部８４は、各メッセージデータをメッセージ保持部８０に格納する。このときメッセージ送信部８８は、乙宛のメッセージについて、開示条件が付されていないため、即時にユーザ端末１２ｂへ送信する。その一方、丙・丁宛のメッセージについては、開示フラグが「０」であるため送信を抑制する。開示判定部８６は、丙・丁宛のメッセージについて、開示条件が満たされたか否か、この例では現在日時が１２月２０日８時に至ったか否かを継続して判定する。

ここでメッセージ配信サーバ１４のメッセージ受信部８２は、１２月２０日の３時に、丙が作成した甲宛の開示条件なしメッセージをユーザ端末１２ｃから受信したとする。メッセージ記録部８４は、そのメッセージをメッセージ保持部８０に格納し、メッセージ送信部８８は、そのメッセージをユーザ端末１２ａへ送信する。送信中止制御部８７は、
丙から甲宛のメッセージがメッセージ保持部８０に記録されたことを検出し、メッセージ保持部８０に予め保持された甲から丙宛の開示条件付きメッセージについて、その送信中止済フラグを「１」へ変更する。

以降、当該メッセージは開示判定部８６による判定対象から除外され、また、メッセージ送信部８８による送信対象からも除外される。送信状況通知部９２は、甲から丙宛のメッセージの送信を中止した旨をユーザ端末１２ａへ通知する。ユーザ端末１２ａのステータス更新部５１は、送信メッセージ保持部４０に記録された甲から丙宛のメッセージについて、その送信中止済フラグを「１」へ変更する。

１２月２０日の８時に至ると、開示判定部８６は、メッセージ保持部８０に保持された甲から丁宛の開示条件付きメッセージについて、その開示フラグを「１」へ変更する。メッセージ送信部８８は、この変更を検出し、甲から丁宛のメッセージをユーザ端末１２ｄへ送信する。送信状況通知部９２は、甲から丁宛のメッセージの開示条件が満たされ、丁に開示した旨をユーザ端末１２ａへ通知する。ユーザ端末１２ａのステータス更新部５１は、送信メッセージ保持部４０に記録された甲から丁宛のメッセージについて、その開示フラグを「１」へ変更する。

メッセージ交換アプリケーション１００の画面で甲が送信トレイの表示を選択すると、ユーザ端末１２ａの送信トレイ表示部５２は、メッセージの種類や現在時点の送信状況に応じて異なる態様で各メッセージのタイトルや宛先、送信日時等を並べた送信トレイ画面を表示させる。甲から乙・丙・丁のそれぞれに向けて送信されたメッセージの時系列での表示態様は以下のようになる。

（１）送信直後から１２月２０日３時までの送信トレイ画面：
乙宛のメッセージ 開示済メッセージを示す態様
丙宛のメッセージ 未開示メッセージを示す態様
丁宛のメッセージ 未開示メッセージを示す態様
（２）１２月２０日３時から１２月２０日８時までの送信トレイ画面：
乙宛のメッセージ 開示済メッセージを示す態様
丙宛のメッセージ 送信中止メッセージを示す態様
丁宛のメッセージ 未開示メッセージを示す態様
（３）１２月２０日８時以降の送信トレイ画面：
乙宛のメッセージ 開示済メッセージを示す態様
丙宛のメッセージ 送信中止メッセージを示す態様
丁宛のメッセージ 開示済メッセージを示す態様

送信トレイ画面において甲が特定のメッセージを選択すると、送信メッセージ表示部５４は、選択されたメッセージの本文や開示条件、送信中止オプション選択状況を示す詳細情報を画面に表示させる。

実施の形態のメッセージ交換システム１０によると、第１の利用者からのメッセージを開示条件が満たされた将来時点において第２の利用者へ配信するサービスにおいて、当該メッセージの配信前に第２の利用者から第１の利用者への連絡がなされた場合、当該メッセージの配信を中止させるための任意選択のオプションを提供できる。これにより、メッセージの行き違いや不整合の発生を防止し、サービス利用者の利便性を向上させる。

また、メッセージ配信サーバ１４は、配信を中止したメッセージの情報を送信元ユーザの端末へ通知する。これにより、送信元のユーザに、メッセージの配信中止を認識させ、メッセージが宛先に届いていないことを踏まえた適切な行動をとらせやすくなる。また、送信元ユーザの端末は、メッセージの一覧画面で、配信中止とされたメッセージを他のメッセージと異なる態様で表示させることにより、配信中止とされたメッセージを送信元ユーザが容易に把握できるよう支援できる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。便宜上、最初に送信される開示条件付きメッセージの送信側ユーザを「甲」、受信側ユーザを「乙」として説明する。

第１の変形例を説明する。上記実施の形態では、甲自身が送信中止オプションの選択有無を判断し、適宜メッセージに付加することとした。変形例として、送信中止オプションを設けず、メッセージ配信サーバ１４は、甲から乙宛の開示条件付き第１メッセージの送信にあたり、その開示条件が満たされる前に、乙から甲宛の第２メッセージを受信した場合に、自律的および強制的に、第１メッセージを乙へ送信することを中止してもよい。この場合に、第１メッセージの送信中止を甲の装置へ通知することは好適である。第１の変形例では、甲は自発的に送信中止オプションを選択しないため、第１メッセージの送信中止は予期しないと想定されるからである。送信中止を通知することにより、メッセージが宛先に届いていないことを踏まえた適切な行動を甲にとらせやすくなる。

また、第１の変形例におけるユーザ端末１２のメッセージ作成部４２は、メッセージ作成画面において、送信中止オプションに代えて、送信継続オプションを甲が選択できるようしてもよい。送信継続オプションが付された開示条件付き第１メッセージを受け付けたメッセージ配信サーバ１４は、その開示条件が満たされる前に、乙から甲宛の第２メッセージを受信した場合でも、開示条件充足有無の判定を継続する。そして開示条件が満たされると第１メッセージを乙へ送信する。すなわち、強制的な送信中止を抑制する。これにより、メッセージの内容に応じた柔軟な配信態様を実現できる。

第２の変形例を説明する。上記実施の形態では、甲が送信中止オプションの選択有無を判断したが、変形例として、システムが自律的および自動的に送信中止オプションを付与するか否かを判定してもよい。例えば、ユーザ端末１２のメッセージ作成部４２は、メッセージ作成画面にメッセージの目的や、種類、カテゴリ、用途を入力するカテゴリ入力エリアを設ける。カテゴリ入力エリアでは、年賀、クリスマスや誕生日等の記念日用、お祝い、遺言、お悔やみ、お詫び、リマインド等を含むプルダウンメニューから特定の項目が選択可能であってもよい。

ユーザ端末１２の送信中止ＯＰ付与部４７は、メッセージのカテゴリと送信中止オプション選択有無との対応関係を予め保持し、カテゴリ入力エリアへの入力内容に応じて、送信中止オプションの選択を示すデータをメッセージデータに付加する。それとともに送信メッセージ保持部４０の送信中止ＯＰフラグ欄に設定する。例えば、送信中止ＯＰ付与部４７は、年賀、記念日用、お祝い、遺言の場合に送信中止オプションを非選択とし、お悔やみ、お詫び、リマインドの場合に送信中止オプションを選択してもよい。この変形例によると、甲は単にメッセージの種類やカテゴリ、用途を選択すれば、送信中止オプションの付与をシステムが自動判定するため、メッセージの配信予約サービスの使い勝手、使いやすさを向上させることができる。

第２の変形例の別の態様として、ユーザ端末１２の送信中止ＯＰ付与部４７は、開示条件の内容に応じて、自律的および自動的に送信中止オプションを付与するか否かを判定してもよい。例えば、開示条件が特定の送信日時を規定するものであり、その送信日時と現在日時との乖離時間が所定時間未満である場合、例えば２４時間未満である場合に、送信中止オプションを自動で選択してもよい。逆に、開示条件が規定する送信日時と現在日時との乖離時間が所定時間以上であれば、例えば２４時間以上であれば、送信中止オプションを非選択としてもよい。時間の乖離が大きければ、メッセージの行き違いは生じにくいからである。

第２の変形例のさらに別の態様として、ユーザ端末１２の送信中止ＯＰ付与部４７は、メッセージのタイトルや本文に応じて、自律的および自動的に送信中止オプションを付与するか否かを判定してもよい。具体的には、送信中止ＯＰ付与部４７は、メッセージの種類やカテゴリ、用途毎の特徴的な文字列（以下、「特徴文字列」と呼ぶ。）と、特徴文字列を含む場合の送信中止オプション選択有無との対応関係を保持する。例えば、特徴文字列「おめでとう」は、お祝い用途として、送信中止オプション非選択と対応づけられてもよい。また、特徴文字列「申し訳ありません」は、お詫び用途として、送信中止オプション選択と対応づけられてもよい。送信中止ＯＰ付与部４７は、メッセージのタイトルおよび本文の文字列を取得し、その文字列の中から特徴文字列を検索する。特徴文字列を検出した場合、検出した特徴文字列に対応づけられた送信中止オプション選択（付与）または非選択（付与しない）の処理を実行してもよい。

なお、第２の変形例で説明した自律的および自動的に送信中止オプションを付与する手段は、ユーザ端末１２に代えてメッセージ配信サーバ１４が備えてもよいことはもちろんである。この場合、ユーザ端末１２から受信したメッセージデータ（例えば上記のカテゴリや開示条件、タイトル、本文を含む）に応じて送信中止オプションの選択・非選択を決定し、その結果に応じて、メッセージ保持部８０の送信中止ＯＰフラグ欄を設定すればよい。

第３の変形例を説明する。ユーザ端末１２のメッセージ送信処理部２２は、メッセージ変更部をさらに含んでもよい。この変形例の送信メッセージ表示部５４は、既に送信した開示条件付きのメッセージを変更・編集するためのメッセージ変更画面を表示させる。この変更・編集には、送信中止オプションの事後的な付与も含まれる。メッセージ変更部は、開示条件付きのメッセージについて、その開示フラグが「０」であることを条件として、メッセージ変更画面に入力された変更・編集内容を受け付け、送信メッセージ保持部４０に記録し、それまでのメッセージデータを上書き更新する。

またメッセージ変更部は、変更対象のメッセージのＩＤを指定し、変更後のメッセージ本文・タイトルを含む変更要求をメッセージ配信サーバ１４へ送信する。なお、ユーザが変更対象としたメッセージの開示フラグが「１」の場合、メッセージ変更部および送信メッセージ表示部５４は、メッセージが受信側ユーザに開示済であるため変更ができない旨を画面に表示させてもよい。これにより、メッセージが開示済という状況に応じた対応を送信側ユーザに実施させることができる。

メッセージ配信サーバ１４のメッセージ記録部８４は、メッセージ保持部８０に保持されたメッセージのうち、変更要求で指定されたＩＤで特定されるメッセージについて、その開示条件が未充足（開示フラグが「０」）である場合に、その本文やタイトル、送信中止ＯＰフラグ等を変更要求が示す内容に置き換える。これにより、開示条件付きメッセージ送信後の状況変化に応じた、事後的なメッセージの変更を実現できる。

第４の変形例を説明する。上記実施の形態では、乙から甲へ第２メッセージが送信されたこと、すなわち、乙から甲へ送信された第２メッセージをメッセージ配信サーバ１４が受信したことを契機として、開示条件充足待ちの甲から乙への第１メッセージの送信を中止した。変形例として、第１メッセージの中止契機は、第２メッセージ（すなわちメッセージ交換システム１０で伝送するメッセージ）以外でもよく、乙から甲へ連絡がなされた事実を示すコンピュータが読取り可能な情報がメッセージ配信サーバ１４に記録されたことであればよい。例えば、乙から甲へ電話連絡があった場合、その事実を示す情報を甲がユーザ端末１２へ入力し、ユーザ端末１２がメッセージ配信サーバ１４へ通知し、メッセージ配信サーバ１４が所定の記憶領域に記録する。メッセージ配信サーバ１４の送信中止制御部８７は、所定の記憶領域を監視し、乙から甲へ連絡がなされた事実を示す情報が格納された場合に、甲から乙への第１メッセージの送信を中止させる処理を実行する。

またメッセージ交換システム１０が電子メールシステムである場合に、電子メールとは別の手段で乙から甲へ連絡がなされたこと、例えば、インスタントメッセージにより乙から甲へメッセージが送信されたことをメッセージ配信サーバ１４（この場合メールサーバ）が検出してもよい。例えば、メッセージ配信サーバ１４は、メッセージ交換システム１０における甲・乙の識別情報と、インスタントメッセージ交換システムにおける甲・乙の識別情報との対応関係を予め保持しておく。メッセージ配信サーバ１４は、インスタントメッセージ交換サーバへ送信元乙、宛先甲のメッセージが送信されたか否かを問い合わせ、インスタントメッセージ交換サーバからの回答電文を所定の記憶領域に記録する。メッセージ配信サーバ１４の送信中止制御部８７は、所定の記憶領域を監視し、乙から甲へインスタントメッセージが送信された事実を示す情報が格納された場合に、甲から乙への第１メッセージの送信を中止させる処理を実行する。

第５の変形例を説明する。一部既述したようにメッセージ交換アプリケーション１００は、インスタントメッセージを送受するインスタントメッセンジャーであってもよい。送信メッセージ表示部５４と、受信メッセージ表示部６６は、１つの画面（ここでは「トーク画面」と呼ぶ。）内に、送信メッセージと受信メッセージを時系列に並べて表示してもよい。この場合に、送信メッセージ表示部５４は、開示条件付きメッセージを、その開示条件が満たされて、メッセージが宛先ユーザに開示された時点、言い換えれば、メッセージのグループが開示済メッセージに変更された時点で、トーク画面に表示させてもよい。また、送信メッセージ表示部５４は、送信中止オプション選択メッセージを、通常は開示条件付きメッセージと同様のタイミングで表示させつつ、当該メッセージの送信中止がメッセージ配信サーバ１４から通知された場合はその時点、言い換えれば、メッセージのグループが送信中止メッセージに変更された時点で、トーク画面に表示させてもよい。既述したように、送信メッセージ表示部５４は、送信中止メッセージを開示済メッセージとは異なる態様で表示させる。

第６の変形例を説明する。上記実施の形態では言及していないが、メッセージ配信サーバ１４が、甲から乙宛の第１の開示条件付き第１のメッセージを受け付け後、第１の開示条件充足前に、乙から甲からの第２の開示条件付き第２のメッセージを受け付けた場合、メッセージ配信サーバ１４は、第１の開示条件が規定する（条件充足となる）日時と、第２の開示条件が規定する日時を比較し、前後関係を特定してもよい。そして、第１の開示条件が規定する日時が、第２の開示条件が規定する日時より前である場合、第１の開示条件が充足した際に第１のメッセージを乙へ送信してもよい。この場合、甲のメッセージが乙に開示される以前に、乙のメッセージが甲にされることはないからである。別の態様として、第１の開示条件が規定する日時が、第２の開示条件が規定する日時より所定時間以上前である場合、例えば５時間以上前や２４時間以上前である場合に、第１の開示条件が充足した際に第１のメッセージを乙へ送信してもよい。時間の乖離が大きければ、第１のメッセージを乙へ送信しても問題は生じにくいと考えられるからである。

さらに別の態様として、第２のメッセージに開示条件が付されるか否かにかかわらず、すなわち、仮に付された場合に第１の開示条件が規定する日時と第２の開示条件が規定する日時の前後関係にかかわらず、第１のメッセージを乙へ送信することを中止してもよい。未開示ではあるが、乙が甲宛のメッセージを送信した事実は存在するからである。この場合、メッセージ配信サーバ１４の送信状況通知部９２は、送信中止メッセージの通知に、乙から甲宛のメッセージを将来配信予定であることを示す情報を付加してもよい。

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

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

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

第９の変形例を説明する。上記実施の形態では、甲から乙宛の開示条件付きメッセージの配信において、開示条件が満たされた場合にメッセージを乙の端末へ送信した。変形例として、メッセージ配信サーバ１４は、メッセージそのものは乙の端末へ送信しておくものの、メッセージには閲覧を禁止する鍵をかけておき、その鍵を開示条件が満たされた場合に乙の端末へ送信し、メッセージの内容を乙に開示してもよい。この場合、メッセージ配信サーバ１４は、開示条件付きメッセージを甲の端末から受信すると、開示条件が満たされるまで、メッセージの内容を乙に対して非開示させつつ、開示条件が満たされた場合に、乙の端末においてメッセージの内容を開示させる開示部をさらに備えてもよい。

例えば、メッセージ配信サーバ１４のメッセージ記録部８４は、甲の端末からメッセージを受信すると、メッセージの内容（タイトルや本文等）を暗号化し、暗号化データと復号キーを対応づけてメッセージ保持部８０に記録する。メッセージ配信サーバ１４のメッセージ送信部８８は、メッセージが受信されると、開示条件の充足を待たず、暗号化データを乙の端末へ送信する。この時点では、乙の端末には暗号化データのみ提供され、乙はメッセージの内容を閲覧することはできない。その後、メッセージ配信サーバ１４の開示部は、開示条件が満たされたと判定された場合に、判定対象のメッセージに対応づけられた復号キーをメッセージ保持部８０から取得し、乙の端末へ送信する。乙の端末における不図示のメッセージ復号部は、メッセージ配信サーバ１４から提供された復号キーを使用して、事前に提供された暗号化データを復号する。そして受信メッセージ表示部６６は、復号されたメッセージの内容をディスプレイに表示させる。

メッセージ配信サーバ１４の開示部は、実施の形態のメッセージ送信部８８と同様に、送信中止制御部８７により送信中止済フラグが「１」に変更されたメッセージについては、開示条件の充足有無にかかわらず、復号キーの送信を中止する。これにより、乙に対してメッセージを非開示とした状態を維持し、実施の形態と同様に、メッセージの行き違いや不整合の発生を防止し、サービス利用者の利便性を向上させる。

第１０の変形例を説明する。上記実施の形態では、送信側ユーザの甲が明示的に開示条件を指定したが、変形例として、甲がメッセージの開示条件を指定しない場合であっても、そのメッセージの乙への送信よりも前に、乙から甲宛のメッセージが送信された場合に、乙へのメッセージの送信を中止してもよい。この変形例では、甲がメッセージの開示条件を指定しなくても、そのメッセージの配信タイミングをシステムが自動で判断し、適宜メッセージの送信を遅延させてもよい。例えば、メッセージの内容（タイトルや本文等）に応じて、そのメッセージの開示条件（配信日時等）をシステムが自律的・自動的に設定し、開示条件が満たされた場合に、メッセージを乙の端末へ送信してもよい。ただし、メッセージの送信前、言い換えれば、自動的に付与した開示条件の充足前に、乙から甲への連絡があれば、メッセージの送信を中止する。

例えば、文字列「あけましておめでとう」を含む開示条件なしのメッセージが甲の端末から発信されると、メッセージ配信サーバ１４のメッセージ記録部８４は、開示条件「１月１日６時（すなわち元旦）」を当該メッセージ付与し、メッセージ保持部８０に記録してもよい。この場合、１月１日６時に至ると、それまでに送信中止済フラグが「１」に変更されていないことを条件として、開示判定部８６は開示条件が満たされと判定し、メッセージ送信部８８は当該メッセージを乙の端末へ送信する。すなわち、年賀メッセージの開示条件をユーザが指定しなくても、システムが自律的に当該メッセージを元旦に送信する。同様に、文字列「メリークリスマス」を含む開示条件なしのメッセージの場合、メッセージ配信サーバ１４のメッセージ記録部８４は、開示条件「１２月２４日０時」を当該メッセージに自動的に付与してもよい。

別の態様として、上記第２の変形例に一部類似するが、開示条件の指定が暗黙的になされてもよい。例えば、ユーザ端末１２のメッセージ作成部４２は、メッセージ作成画面にメッセージの目的や、種類、カテゴリ、用途を入力するカテゴリ入力エリアを設ける。カテゴリ入力エリアでは、年賀やクリスマス等を含むプルダウンメニューから特定の項目を選択可能としてもよい。ユーザはカテゴリ入力エリアにおいて特定の項目を選択することにより、暗黙的に開示条件（開示日時）を指定することになる。メッセージ作成部４２は、カテゴリ入力エリアでの選択項目（選択カテゴリ）をメッセージデータに付加する。メッセージ配信サーバ１４のメッセージ記録部８４は、カテゴリ入力エリアの各項目と開示条件（開示日時）との予め定められた対応関係を保持し、カテゴリ入力エリアでの選択項目に対応づけられた開示条件を自動的に設定する。ここでは、開示条件を自動で設定する処理をメッセージ配信サーバ１４が実行することとしたが、送信側ユーザ甲のユーザ端末１２が実行してもよく、ユーザ端末１２の開示条件付与部４６が実行してもよい。

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

請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

１０ メッセージ交換システム、 １２ ユーザ端末、 １４ メッセージ配信サーバ、 ４２ メッセージ作成部、 ４８ メッセージ送信部、 ５１ ステータス更新部、 ５２ 送信トレイ表示部、 ５４ 送信メッセージ表示部、 ８２ メッセージ受信部、 ８６ 開示判定部、 ８７ 送信中止制御部、 ８８ メッセージ送信部、 ９２ 送信状況通知部。

Claims (2)

1. 送信側ユーザ甲による、受信側ユーザ乙宛のメッセージと、前記メッセージの開示条件の入力を受け付ける受付部と、
   前記開示条件を付与したメッセージをサーバへ送信することにより、前記メッセージを、その内容が、前記開示条件が満たされた場合に閲覧可能となるメッセージとして乙の装置へ送信する処理を前記サーバに実行させる送信部と、
   自装置から送信したメッセージの一覧画面を表示させる一覧表示部と、
   を備え、
   前記サーバは、前記開示条件が付与されたメッセージの開示条件が満たされた場合、当該メッセージを開示した旨の第１情報を甲の装置へ通知し、前記開示条件が付与されたメッセージの開示が中止された場合、その旨を示す第２情報を甲の装置へ通知し、
   前記一覧表示部は、前記サーバから通知された第１情報と第２情報に基づいて、前記一覧画面において、乙に開示済のメッセージと、乙に未開示のまま開示中止となったメッセージの両方を表示させ、前記乙に開示済のメッセージと、前記乙に未開示のまま開示中止となったメッセージとを異なる態様で表示させることを特徴とするメッセージの送信装置。
2. 送信側ユーザ甲の装置から送信された、受信側ユーザ乙宛のメッセージと、前記メッセージの開示条件を受信する受信部と、
   前記メッセージを、その内容が、前記開示条件が満たされた場合に閲覧可能となるメッセージとして乙の装置へ送信する送信部と、
   前記開示条件が付与されたメッセージの開示条件が満たされた場合、当該メッセージを開示した旨の第１情報を甲の装置へ通知し、前記開示条件が付与されたメッセージの開示が中止された場合、その旨を示す第２情報を甲の装置へ通知することにより、甲の装置における送信メッセージの一覧画面において、乙に開示済のメッセージと、乙に未開示のまま開示中止となったメッセージの両方を表示させ、前記乙に開示済のメッセージと、前記乙に未開示のまま開示中止となったメッセージとを異なる態様で表示させる通知部と、
   を備えることを特徴とするメッセージ配信サーバ。

Images