JP2016212638A - リクエスト処理方法、装置、及びプログラム - Google Patents

Abstract

【課題】送信するメッセージの内容と送信先との関係を容易に確認できない場合でも、メッセージの誤送信を防止する。【解決手段】第１の通信装置から第２の通信装置に提供する対象のデータと、該対象のデータを前記第２の通信装置に対する提供の許可を求めるリクエストとを受信すると、前記リクエストの承認処理を行う端末に対して、前記第１の通信装置、前記第２の通信装置、前記端末のいずれかから過去に送信されたデータに含まれるメッセージが配置され、承認処理を起動する表示部品を含む承認処理画面情報を送信する。【選択図】図１４

Description

本発明は、リクエスト処理方法、リクエスト処理装置、及びリクエスト処理プログラムに関する。

従来、電子メールやファイルの送信に関し、誤送信を防止するための技術が存在する。

例えば、送信先アドレスの所有者と送信元アドレスの所有者との間の人的関係、及び送信先アドレスに対する過去の送信回数などの送信履歴を画面表示して、当該電子メールを送信してよいか否かを送信前に確認する方法が提案されている。さらに、この方法では、電子メールに添付されている添付ファイルのファイル名の中に含まれる文字列に対応する文書属性を特定する。そして、特定した文書属性を画面表示させると共に、添付ファイルが添付された電子メールを送信先アドレスに対して送信してよいか否かを確認するメッセージを画面表示させる。

また、第１の操作者の操作に基づき、送信先に送信すべき送信ファイルが添付された電子メールを作成し、作成された電子メールが送信先に送信される前に、電子メールを第１の操作者と異なる第２の操作者に確認可能とする方法が提案されている。

特開２０１５−００５２１０号公報 特開２００８−２４２９１９号公報

ここで、例えば、担当者が訪問先で行ったサービスや業務等の報告を、担当者から、訪問先とは異なる契約者に対して、メールやメールに添付した添付ファイルなどの電子的なメッセージにより送信する場合がある。この場合、担当者は、訪問先と契約者との関係を把握した上で、訪問先に関するメッセージを作成して契約者に送信する必要がある。

しかし、担当者は、訪問先のことはよく把握していても、契約者とは面識がない場合もあり、送信するメッセージの内容と送信先との関係を容易に確認できない場合がある。そのため、担当者が、訪問先と契約者との関係を誤認するなどして、ある訪問先に関する報告を、その訪問先とは関係のない契約者に送信してしまう可能性がある。

従来技術のように、送信先（契約者）と送信元（担当者）との間の人的関係や送信履歴を画面表示しても、上記のように、訪問先と契約者との関係を誤認する場合のような誤送信は防止することができない。また、送信者とは異なる人が送信するメール等を確認する場合でも、その確認する人も送信者と同様に、訪問先と契約者との関係を誤認する可能性はあり、上記のような誤送信を防止することはできない。

本発明は、一つの側面として、送信するメッセージの内容と送信先との関係を容易に確認できない場合でも、メッセージの誤送信を防止することを目的とする。

本発明は、一つの態様として、第１の通信装置から第２の通信装置に提供する対象のデータと、該対象のデータを前記第２の通信装置に対する提供の許可を求めるリクエストとを受信する。そして、前記リクエストの承認処理を行う端末に対して、前記第１の通信装置、前記第２の通信装置、前記端末のいずれかから過去に送信されたデータに含まれるメッセージが配置され、承認処理を起動する表示部品を含む承認処理画面情報を送信する。

一つの側面として、送信するメッセージの内容と送信先との関係を容易に確認できない場合でも、メッセージの誤送信を防止することができる、という効果を有する。

本実施形態に係るメッセージ投稿システムの概略構成を示すブロック図である。 本実施形態に係るリクエスト処理装置の機能ブロック図である。 世帯情報データベース（ＤＢ）の一例を示す図である。 担当者情報ＤＢの一例を示す図である。 メッセージＤＢの一例を示す図である。 メッセージ状態ＤＢの一例を示す図である。 本実施形態に係るリクエスト処理装置として機能するコンピュータの概略構成を示すブロック図である。 画面遷移を説明するためのシーケンス図である。 訪問レポート一覧画面の一例を示す図である。 メッセージ一覧画面の一例を示す図である。 訪問レポート作成画面の一例を示す図である。 訪問レポート確認画面の一例を示す図である。 承認待ちの訪問レポートが追加された担当者用のメッセージ一覧画面の一例を示す図である。 承認待ちの訪問レポートが追加された承認者用のメッセージ一覧画面の一例を示す図である。 承認後のメッセージ一覧画面の一例を示す図である。 否決後のメッセージ一覧画面の一例を示す図である。 メッセージ作成画面の一例を示す図である。 メッセージ確認画面の一例を示す図である。 本実施形態における担当者投稿時のリクエスト処理の一例を示すフローチャートである。 本実施形態における担当者投稿時のリクエスト処理の一例を示すフローチャートである。 本実施形態における担当者投稿時のリクエスト処理の一例を示すフローチャートである。

以下、図面を参照して、本発明に関する実施形態の一例を詳細に説明する。以下の実施形態では、訪問先と、契約者と、担当者及び承認者を含むサービス提供者とが登場人物となる、一種の訪問サービスに、本発明のリクエスト処理装置を含むメッセージ投稿システムを適用した例について説明する。

実施形態の詳細を説明する前に、実施形態で対象とする訪問サービスについて説明する。訪問サービスでは、例えば、別居している親世帯への訪問を依頼する子世帯が契約者であり、訪問を受ける親世帯が訪問先である。契約者とサービス提供者とは、契約者とサービス提供者とが共通して閲覧可能な電子掲示板などのウェブアプリケーションを介して、互いにメッセージをやり取り可能である。担当者は、訪問先である親世帯を訪問し、訪問した結果をまとめた訪問レポートを作成し、作成した訪問レポートをメッセージとして契約者である子世帯に送信する。

例えば、親世帯Ａを訪問した結果をまとめた訪問レポートは、親世帯Ａへの訪問サービスを契約している子世帯Ａへ送信すべきである。しかし、担当者は、親世帯を訪問するため、当然ながら親世帯の顔や名前はよく把握しているが、子世帯は単なる訪問サービスの契約者であるので、面識がない場合がある。また、訪問先である親世帯と子世帯とでは、苗字が異なる場合もあり親世帯と子世帯との関係を把握し難い場合もある。そのため、親世帯Ａの訪問レポートを、誤って子世帯Ｂへ送信してしまうという誤送信が生じ得る。訪問レポートには、親世帯の個人情報が記載されることが想定されるため、このような誤送信は防止すべきである。

なお、以下の実施形態において、担当者から契約者へ送信されるメッセージには、承認者の承認が必要なメッセージと承認が不要なメッセージとがあるものとする。以下では、上記の訪問レポートは承認が必要なメッセージ、訪問レポート以外は承認が不要なメッセージとして説明する。また、本実施形態において、送信者から送信先へ送信されるメッセージとは、送信者がメッセージ投稿システムに対して、送信先が閲覧可能な状態で投稿するメッセージである。

図１に示すように、本実施形態に係るメッセージ投稿システム１０は、リクエスト処理装置２０と、契約者端末４１と、担当者端末４２と、承認者端末４３とを含む。リクエスト処理装置２０と、契約者端末４１と、担当者端末４２と、承認者端末４３とは、ネットワーク４５を介して互いに接続される。

契約者端末４１、担当者端末４２、及び承認者端末４３の各々は、後述するメッセージ等が表示される表示部、及び各種情報の入力操作を行うための操作部を備えた情報処理装置である。契約者端末４１、担当者端末４２、及び承認者端末４３の各々は、例えば、パーソナルコンピュータ、タブレット、スマートフォン、携帯電話等である。本実施形態では、契約者が利用する情報処理装置を契約者端末４１、担当者が利用する情報処理装置を担当者端末４２、及び承認者が利用する情報処理装置を承認者端末４３として区別する。なお、図１には、契約者端末４１、担当者端末４２、及び承認者端末４３が各々１台の例を示しているが、それぞれ複数台以上がメッセージ投稿システム１０に含まれてもよい。

リクエスト処理装置２０は、図２に示すように、受付部２１と、生成部２２と、送信部２３とを含む。また、リクエスト処理装置２０の所定の記憶領域には、世帯情報データベース（ＤＢ）３１と、担当者情報ＤＢ３２と、メッセージＤＢ３３と、メッセージ状態ＤＢ３４とが記憶される。

世帯情報ＤＢ３１には、訪問先である親世帯及び契約者である子世帯に関する情報が格納される。図３に、世帯情報ＤＢ３１の一例を示す。図３の例では、訪問先毎に、「訪問先番号」、「訪問先氏名」、「担当者ＩＤ」、「契約者」等の各項目に対応する情報が格納される。「訪問先番号」は、訪問先の識別番号である。なお、本実施形態では、１件の訪問先に１人の訪問対象者が存在する場合について説明するが、１件の訪問先に複数の訪問対象者が存在してもよい。「担当者ＩＤ」は、該当の訪問先を訪問する担当者の識別番号である。「契約者」は、該当の訪問先に対する訪問サービスを契約した子世帯である。世帯情報ＤＢ３１には、その他にも、契約者の住所、連絡先、訪問先と契約者との続柄、契約者が利用する契約者端末４１の機種、訪問先（訪問対象者）の健康状態や趣味などの情報を格納してもよい。

担当者情報ＤＢ３２には、サービス提供者の担当者に関する情報が格納される。図４に、担当者情報ＤＢ３２の一例を示す。図４の例では、担当者毎に、「担当者ＩＤ」、「担当者氏名」、「承認者ＩＤ」等の各項目に対応する情報が格納される。「承認者ＩＤ」は、該当の担当者が承認の必要なメッセージを送信する際に承認を行う承認者の識別情報である。担当者情報ＤＢ３２には、その他にも、担当者の連絡先、所属部署、勤務形態等の情報を格納してもよい。

メッセージＤＢ３３には、契約者、担当者、及び承認者のいずれかから送信されたメッセージに関する情報が格納される。図５に、メッセージＤＢ３３の一例を示す。図５の例では、メッセージ１件毎に、「メッセージＩＤ」、「訪問先番号」、「送信日時」、「送信者」、「送信先」、「承認者」、「件名」、「ひと言フラグ」、「本文」、「添付ファイル」等の各項目に対応する情報が格納される。「メッセージＩＤ」は、メッセージの識別番号であり、例えば、リクエスト処理装置２０でメッセージを受け付けた順に付与された通し番号である。「訪問先番号」は、該当のメッセージが、どの訪問先についてのメッセージであるかを示す情報である。「送信者」及び「送信先」の各々は、契約者、担当者、又は承認者を特定する情報であり、図５では、ぞれぞれの氏名で特定する例を示している。なお、「送信先」は複数設定可能である。

「承認者」は、該当のメッセージが、承認が必要なメッセージの場合における承認者を特定する情報であり、図５では、氏名で特定する例を示している。「件名」、「ひと言フラグ」、「本文」、及び「添付ファイル」は、メッセージの内容を示すものである。「ひと言フラグ」は、メッセージの内容を端的に表すひと言として予め定められた定型文の各々に対応付けられた、１、２、３等の番号である。例えば、ひと言フラグ＝１が設定されている場合には、メッセージに「新しい状況です」というひと言を付加することができる。また、例えば、ひと言フラグ＝２では、「知りたがっていました」、ひと言フラグ＝３では、「ご連絡ありがとうございます」というひと言を、メッセージに付加することができる。

メッセージ状態ＤＢ３４は、各メッセージの承認状態を示す情報、及びメッセージが閲覧されたか否かを示す情報が格納される。図６に、メッセージ状態ＤＢ３４の一例を示す。図６の例では、メッセージ１件毎に、「メッセージＩＤ」、「承認要否フラグ」、「状態」、「状態更新日時」、「既読／未読」、「担当者未読超過」等の各項目に対応する情報が格納される。「承認要否フラグ」は、該当のメッセージが承認の必要なメッセージか、承認の不要なメッセージかを示す情報である。

「状態」は、リクエスト処理装置２０で受け付けたメッセージの状態を示す情報である。メッセージの状態としては、承認待ち、否決、送信済み、及び一時保存がある。「承認待ち」は、担当者がメッセージを契約者へ送信する前に、承認者に承認依頼を行い、未だ承認又は否決がされていない状態である。「否決」は、承認待ちのメッセージを承認者が否決した状態である。「送信済み」は、承認待ちのメッセージを承認者が承認し、送信先である契約者に送信された状態、又は、承認が必要ないメッセージの投稿が指示されて、送信先へメッセージが送信された状態である。「一時保存」は、リクエスト処理装置２０で受け付け、未だ送信先へ送信されていないメッセージを、リクエスト処理装置２０において一時保存している状態である。

「状態更新日時」は、該当のメッセージの状態が、「状態」欄の情報が示す現在の状態に更新された日時である。「既読／未読」は、送信先へ送信済みのメッセージについては、送信先で閲覧されたか否かを示す情報である。例えば、送信済みのメッセージが閲覧された場合には「既読」、未だ閲覧されていない場合には「未読」とすることができる。また、承認待ちのメッセージについては、承認者が閲覧したか否か、承認又は否決済みのメッセージについては、担当者が閲覧したか否かを示す情報となる。「担当者未読超過」は、否決されたメッセージを、担当者が閲覧することなく経過した時間を表す情報である。

受付部２１は、契約者端末４１、担当者端末４２、及び承認者端末４３の各々から送信されたメッセージを受け付ける。受付部２１は、受け付けたメッセージに含まれる情報と、世帯情報ＤＢ３１及び担当者情報ＤＢ３２の各々に格納された情報に基づいて、メッセージＤＢ３３及びメッセージ状態ＤＢ３４の各々の各項目に、それぞれ対応する情報を格納する。また、受付部２１は、契約者端末４１、担当者端末４２、及び承認者端末４３の各々のから送信された各種選択情報（詳細は後述）を受け付け、受け付けた選択情報を生成部２２に通知する。

生成部２２は、受付部２１から通知された選択情報と、各種ＤＢに格納された情報とに基づいて、契約者端末４１、担当者端末４２、及び承認者端末４３の各々の表示部に表示させる画面を示す各種画面情報を生成する。生成部２２は、生成した各種画面情報を送信部２３へ受け渡す。

また、生成部２２は、メッセージＤＢ３３へのアクセス状況（メッセージ一覧画面の閲覧状況）を確認し、メッセージ状態ＤＢ３４の「既読／未読」を更新する。また、生成部２２は、定期的にメッセージ状態ＤＢ３４を確認し、「状態」が否決、かつ「既読／未読」が未読のメッセージの「状態更新日時」と、現在日時との差を求め、「担当者未読超過」欄を更新する。

送信部２３は、生成部２２から受け渡された各種画面情報を、契約者端末４１、担当者端末４２、及び承認者端末４３のうちの対応する端末へ送信する。

リクエスト処理装置２０は、例えば、図７に示すコンピュータ５０で実現することができる。コンピュータ５０はＣＰＵ５１、一時記憶領域としてのメモリ５２、及び不揮発性の記憶部５３を備える。また、コンピュータ５０は、表示装置及び入力装置等の入出力装置５８が接続される入出力インターフェース（Ｉ／Ｆ）５４を備える。また、コンピュータ５０は、記録媒体５９に対するデータの読み込みと書き込みとを制御するｒｅａｄ／ｗｒｉｔｅ（Ｒ／Ｗ）部５５、及びインターネット等のネットワーク４５に接続されるネットワークＩ／Ｆ５６を備える。ＣＰＵ５１、メモリ５２、記憶部５３、入出力Ｉ／Ｆ５４、Ｒ／Ｗ部５５、及びネットワークＩ／Ｆ５６は、バス５７を介して互いに接続される。

記憶部５３は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（solid state drive）、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部５３には、コンピュータ５０をリクエスト処理装置２０として機能させるためのリクエスト処理プログラム６０が記憶される。また、記憶部５３は、世帯情報ＤＢ３１、担当者情報ＤＢ３２、メッセージＤＢ３３、及びメッセージ状態ＤＢ３４の各々を構成する情報が記憶される情報記憶領域７０を有する。

ＣＰＵ５１は、リクエスト処理プログラム６０を記憶部５３から読み出してメモリ５２に展開し、リクエスト処理プログラム６０が有するプロセスを順次実行する。また、ＣＰＵ５１は、情報記憶領域７０から各種情報を読み出し、世帯情報ＤＢ３１、担当者情報ＤＢ３２、メッセージＤＢ３３、及びメッセージ状態ＤＢ３４の各々をメモリ５２に展開する。

リクエスト処理プログラム６０は、受付プロセス６１と、生成プロセス６２と、送信プロセス６３とを有する。ＣＰＵ５１は、受付プロセス６１を実行することで、図２に示す受付部２１として動作する。また、ＣＰＵ５１は、生成プロセス６２を実行することで、図２に示す生成部２２として動作する。また、ＣＰＵ５１は、送信プロセス６３を実行することで、図２に示す送信部２３として動作する。これにより、リクエスト処理プログラム６０を実行したコンピュータ５０が、リクエスト処理装置２０として機能することになる。

なお、リクエスト処理プログラム６０により実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ（Application Specific Integrated Circuit）等で実現することも可能である。

次に、本実施形態に係るメッセージ投稿システム１０の作用について説明する。まず、図８に示すシーケンス図を参照して、リクエスト処理装置２０の生成部２２で生成される画面情報が示す画面の遷移について、担当者が訪問レポートを送信する場合を例に説明する。

まず、担当者が、担当者端末４２において、メッセージ投稿システム１０により提供されるアプリケーションを起動して、担当者ＩＤを用いてログインする。そして、メニュー画面（図示省略）から訪問レポートのメニューを選択する（Ｓ１１）。これにより、担当者端末４２から、訪問レポートのメニューを選択した選択情報がリクエスト処理装置２０へ送信される。なお、以下では、各端末において、何らかのメニュー又はボタンを選択する、との説明は、選択されたメニュー又はボタンに応じた選択情報がリクエスト処理装置２０へ送信されることを意味する。

リクエスト処理装置２０では、訪問レポートのメニューを選択した選択情報を受け付けると、訪問レポート一覧画面情報を担当者端末４２に送信する。担当者端末４２の表示部には、例えば、図９に示すような、訪問レポート一覧画面８０が表示される。なお、以下では、リクエスト処理装置２０において、何らかの画面を表示する、との説明は、生成部２２が生成した画面情報をいずれかの端末へ送信し、その端末の表示部に、生成された画面情報が示す画面が表示されることを意味する。

図９に示す訪問レポート一覧画面８０は、検索条件指定領域８１と、検索結果表示領域８２とを含む。検索条件指定領域８１には、訪問レポートを作成する訪問先を検索するための検索条件の指定に利用されるテキストボックス群８３と、指定した検索条件で検索を実行する際に選択される検索ボタン８４とが配置される。図９では、テキストボックス群８３により検索条件として指定可能な項目は、「訪問先番号」、「担当者」、「承認状態」、及び「担当者未読超過」である例を示している。なお、「承認状態」は、メッセージ状態ＤＢ３４の項目「状態」に相当する。

担当者は、担当者端末４２に表示された訪問レポート一覧画面８０の検索条件指定領域８１において、テキストボックス群８３を利用して検索条件を指定し、検索ボタン８４を選択する（Ｓ１２）。そして、リクエスト処理装置２０では、指定された検索条件に基づいて検索を行い、検索された訪問先の一覧８５を、訪問レポート一覧画面８０の検索結果表示領域８２に表示する。図９の例では、一覧８５には、検索条件として指定可能な項目と同様の項目が含まれ、各行が検索された訪問先１件に相当する。また、一覧８５に含まれる訪問先のいずれかを選択するための詳細ボタン８６が、一覧８５の各行に対応して配置される。

検索について、より具体的に説明する。生成部２２が、メッセージ状態ＤＢ３４において、検索条件として指定されている「承認状態」及び「担当者未読超過」と、「状態」及び「担当者未読超過」の欄が一致するメッセージを全て特定する。次に、生成部２２は、特定したメッセージのメッセージＩＤに対応する「訪問先番号」を、メッセージＤＢ３３から特定する。次に、生成部２２は、特定した「訪問先番号」に対応する「担当者ＩＤ」を、世帯情報ＤＢ３１から特定し、特定した「担当者ＩＤ」に対応する「担当者氏名」を、担当者情報ＤＢ３２から特定する。そして、生成部２２は、特定した「訪問先番号」及び「担当者氏名」を、一覧８５の「訪問先番号」及び「担当者」欄に表示する。

また、生成部２２が、検索条件に基づいてメッセージ状態ＤＢ３４から特定したメッセージを、メッセージＤＢ３３を参照して訪問先番号毎に分類する。生成部２２は、メッセージ状態ＤＢ３４において、訪問先番号毎に分類されたメッセージ群に、「状態」欄が、一時保存、承認待ち、又は否決のメッセージが存在するか否かを判定する。一時保存、承認待ち、及び否決の各々に該当するメッセージが１件でも存在する場合には、生成部２２は、一覧８５において、対応する訪問先番号の「一時保存」、「承認待ち」、及び「否決」の各欄に印（図９の例では、チェックマーク）を表示する。

また、生成部２２は、メッセージ状態ＤＢ３４において、訪問先番号毎に分類されたメッセージＩＤに対応する「担当者未読超過」欄のうち、直近の情報を抽出して、一覧８５において、対応する訪問先番号の「担当者未読超過」欄に表示する。

なお、検索条件として、上述の項目が全て指定される必要はなく、指定された項目に応じて、該当する訪問先を検索する処理を実行すればよい。

担当者は、検索結果表示領域８２に表示された一覧８５から、訪問レポートを作成する対象の訪問先番号に対応する詳細ボタン８６を選択する（Ｓ１３）。

リクエスト処理装置２０では、選択された訪問先番号について、サービス提供者（担当者及び承認者）と契約者との間でやり取りされたメッセージの一覧として、例えば、図１０に示すような、メッセージ一覧画面９０Ａを表示する。図１０に示すメッセージ一覧画面９０Ａには、サービス提供者（担当者及び承認者）と契約者との間でやり取りされたメッセージ９１が、各メッセージの送信日時に基づいて、時系列に並べられて表示される。

具体的には、生成部２２は、メッセージＤＢ３３において、「訪問先番号」欄が、選択された訪問先番号と一致するメッセージを全て特定する。そして、生成部２２は、特定したメッセージの「送信日時」順にメッセージを配列したメッセージ一覧画面情報を生成する。メッセージ一覧画面９０Ａに表示するメッセージには、メッセージの送信者、ひと言フラグに対応するひと言、題名、本文、添付ファイル、送信日時に関する情報等を含めることができる。また、生成部２２は、メッセージ状態ＤＢ３４を参照して、各メッセージの「状態」欄の情報に応じて、各メッセージの表示態様（詳細は後述）を決定する。さらに、生成部２２は、各メッセージ状態ＤＢ３４の「既読／未読」欄を参照して、各メッセージが未読か既読かの表示を、各メッセージと対応付けて配置する。

また、メッセージ一覧画面９０Ａには、新たに訪問レポートを作成する際に担当者に選択される報告ボタン９２が含まれる。このように、報告ボタン９２をメッセージ一覧画面９０Ａに設けることで、担当者は、過去に担当者と契約者との間でやり取りされたメッセージを確認した上で、新たな訪問レポートを作成することができる。

担当者が報告ボタン９２を選択すると（Ｓ１４）、リクエスト処理装置２０では、例えば、図１１に示すような、訪問レポート作成画面１００Ａを表示する。図１１に示す訪問レポート作成画面１００Ａには、「承認依頼」、「訪問先」、「宛先」、「件名」、「ひと言」、「本文」、及び「添付」の欄が含まれる。「承認依頼」欄は、契約者への訪問レポートの送信に対する許可を与える承認者を指定する欄である。「承認依頼」欄は、例えば、担当者情報ＤＢ３２において、担当者に対応付けられた承認者ＩＤが示す承認者を選択可能なプルダウンメニューとすることができる。「訪問先」欄は、訪問レポート作成画面１００Ａを表示する契機となった報告ボタン９２が含まれるメッセージ一覧画面９０Ａの対象となる訪問先番号が示す訪問先が表示される欄である。「宛先」欄は、メッセージの送信先を指定する欄である。「宛先」欄は、例えば、世帯情報ＤＢ３１において、訪問先番号に対応付けられた契約者を表示することができる。また、世帯情報ＤＢ３１に、メッセージの送信先として、契約者以外にも複数の家族等が登録されている場合には、「宛先」欄を、送信先を選択可能なプルダウンメニューとすることができる。また、「宛先」欄としては、必要に応じて、ＣＣ欄、ＢＣＣ欄等を設けてもよい。

「件名」欄及び「本文」欄は、任意のテキストを入力可能な欄である。「ひと言」欄は、例えば、ひと言フラグで特定されるいずれかのひと言を選択可能なプルダウンメニューとすることができる。「添付」欄は、添付ファイルを指定するための欄であり、指定された添付ファイルのファイル名が表示される。

また、訪問レポート作成画面１００Ａには、確認ボタン１０１と、一時保存ボタン１０２と、キャンセルボタン１０３とが含まれる。確認ボタン１０１は、訪問レポート作成画面１００Ａに入力された内容を確認する際に選択される。一時保存ボタン１０２は、訪問レポート作成画面１００Ａに入力された内容を一時保存して、メッセージ一覧画面９０Ａに戻る際に選択される。キャンセルボタン１０３は、訪問レポート作成画面１００Ａに入力された内容を破棄して、メッセージ一覧画面９０Ａに戻る際に選択される。

担当者が、訪問レポート作成画面１００Ａにおいて訪問レポートを作成し（Ｓ１５）、確認ボタン１０１を選択すると（Ｓ１６）、リクエスト処理装置２０では、例えば、図１２に示すような、訪問レポート確認画面１１０Ａを表示する。訪問レポート確認画面１１０Ａに含まれる欄は、訪問レポート作成画面１００Ａに含まれる欄と同様であるが、いずれの欄も編集不可能な状態で表示される。

また、訪問レポート確認画面１１０Ａには、承認依頼ボタン１１１と、キャンセルボタン１１２とが含まれる。承認依頼ボタン１１１は、訪問レポート確認画面１１０Ａに表示された内容で承認者に承認を依頼する際に選択される。キャンセルボタン１１２は、訪問レポート確認画面１１０Ａを閉じて、訪問レポート作成画面１００Ａに戻る際に選択される。

担当者は、作成した訪問レポートの内容を確認すると、訪問レポート確認画面１１０Ａにおいて、承認依頼ボタン１１１を選択する（Ｓ１７）。リクエスト処理装置２０では、例えば、図１３に示すように、図１０に示すメッセージ一覧画面９０Ａに、作成された訪問レポートを承認待ちの状態で追加したメッセージ一覧画面９０Ｂを、担当者端末４２の表示部に表示する。担当者端末４２の表示部に表示されるメッセージ一覧画面９０Ｂには、承認待ちのメッセージ（訪問レポート）に付随して、担当者が承認者へ行った承認依頼を取り戻す際に選択される承認依頼取戻しボタン９３が配置される。承認依頼取戻しボタン９３が選択されると、メッセージ一覧画面９０Ｂから承認待ちのメッセージが削除され、図１０の状態のメッセージ一覧画面９０Ａに戻る。

一方、リクエスト処理装置２０では、例えば、図１４に示すように、図１０のメッセージ一覧画面９０Ａに、作成された訪問レポートを承認待ちの状態で追加したメッセージ一覧画面９０Ｃを、承認者端末４３の表示部に表示する。承認者端末４３の表示部に表示されるメッセージ一覧画面９０Ｃには、承認待ちのメッセージ（訪問レポート）に付随して、承認待ちのメッセージを承認する際に選択される承認ボタン９４と、否決する際に選択される否決ボタン９５とが配置される。承認待ちのメッセージは、過去に担当者と契約者との間でやり取りされたメッセージと共にメッセージ一覧画面９０Ｃに表示されるため、承認者は、過去のやり取りを参照した上で、作成された訪問メッセージの内容を確認することができる。なお、メッセージ一覧画面９０Ｃは、本発明の承認処理画面情報が示す画面の一例である。

承認ボタン９４が選択されると（Ｓ１９）、承認待ちのメッセージ（訪問レポート）が、正式に投稿される。具体的には、図１５に示すように、承認待ちのメッセージが、契約者、担当者、及び承認者の全てで閲覧可能な状態となったメッセージ一覧画面９０Ｄが、契約者端末４１、担当者端末４２、及び承認者端末４３の各々の表示部に表示される（Ｓ２０）。

一方、否決ボタン９５が選択されると（Ｓ１９）、図１６に示すように、否決された承認待ちのメッセージ（訪問レポート）に付随して、編集ボタン９６及び削除ボタン９７が配置されたメッセージ一覧画面９０Ｅが、担当者端末４２の表示部に表示される。担当者が編集ボタン９６を選択すると（Ｓ２１）、図１１に示す訪問レポート作成画面１００Ａが表示され、訪問レポートを再度編集可能な状態となる。削除ボタン９７が選択されると、メッセージ一覧画面９０Ｅから承認待ちのメッセージが削除され、図１０の状態のメッセージ一覧画面９０Ａに戻る。

なお、図１０、及び図１３〜図１６に示すメッセージ一覧画面では、正式に投稿されたメッセージは実線の吹き出しで図示し、承認待ち又は否決後のメッセージは破線の吹き出しで図示している。

また、上記の例では、訪問レポート作成時の画面遷移について説明したが、本実施形態では、承認が必要でないメッセージの投稿も可能である。また、契約者及び承認者がメッセージを投稿する際は、内容に関わらず、承認は不要である。この場合、メッセージを投稿しようとする者の端末の表示部に表示されたメッセージ一覧画面９０Ａからメッセージ作成ボタン（図示省略）が選択された場合に、生成部２２は、例えば、図１７に示すような、メッセージ作成画面１００Ｂを表示する。メッセージ作成画面１００Ｂは、図１１に示す訪問レポート作成画面１００Ａと異なり、「承認依頼」の欄が設けられていない。メッセージ作成画面１００Ｂのその他の点は、図１１に示す訪問レポート作成画面１００Ａと同様である。

メッセージ作成画面１００Ｂの確認ボタン１０１がメッセージの投稿者により選択されると、生成部２２は、例えば、図１８に示すメッセージ確認画面１１０Ｂを表示する。メッセージ確認画面１１０Ｂには、図１２に示す訪問レポート確認画面１１０Ａの承認依頼ボタン１１１に代えて、投稿ボタン１１３が設けられる。投稿ボタン１１３が選択されると、作成されたメッセージは、承認待ちの状態を経ることなく、メッセージ一覧画面９０Ａに正式に投稿される。

なお、承認が必要なメッセージ（訪問レポート）、及び承認が不要なメッセージのいずれを作成する場合も、報告ボタン９２又はメッセージ作成ボタン（図示省略）から、図１１に示す訪問レポート作成画面１００Ａと同様の作成画面を表示してもよい。そして、作成画面において、「承認依頼」欄に承認者が指定された場合には、承認が必要なメッセージ（訪問レポート）として扱い、「承認依頼」欄が空欄の場合には、承認が不要なメッセージとして扱ってもよい。この場合、「承認依頼」欄を、担当者に対応した承認者と空欄とを選択可能なプルダウンメニューとすればよい。

次に、リクエスト処理装置２０で実行されるリクエスト処理について説明する。まず、担当者がメッセージを投稿する際のリクエスト処理について説明する。担当者が、担当者端末４２において、メッセージ投稿システム１０により提供されるアプリケーションを起動して、担当者ＩＤを用いてログインする。そして、担当者が、メニュー画面（図示省略）から訪問レポートのメニューを選択すると、リクエスト処理装置２０が、図１９〜図２１に示す担当者投稿時のリクエスト処理を実行する。なお、図８のシーケンス図を用いて詳細を説明済みの処理については、詳細な説明を省略する。

図１９に示すリクエスト処理のステップＳ３１で、生成部２２が、例えば、図９に示す訪問レポート一覧画面８０を、担当者端末４２の表示部に表示する。

次に、ステップＳ３２で、受付部２１が、訪問レポート一覧画面８０の検索ボタン８４が選択されたか否かを判定する。検索ボタン８４が選択された場合には、処理はステップＳ３３へ移行し、選択されていない場合には、本ステップの判定を繰り返す。

ステップＳ３３では、生成部２２が、受付部２１が受け付けた検索条件に基づいて、各ＤＢを参照し、検索条件に合致する訪問先を検索する。そして、生成部２２は、検索した訪問先の一覧８５を、担当者端末４２の表示部に表示されている訪問レポート一覧画面８０の検索結果表示領域８２に表示する。

次に、ステップＳ３４で、受付部２１が、訪問レポート一覧画面８０の詳細ボタン８６が選択されたか否かを判定する。詳細ボタン８６が選択された場合には、処理はステップＳ３５へ移行し、選択されていない場合には、本ステップの判定を繰り返す。

ステップＳ３５では、受付部２１が、どの詳細ボタン８６が選択されたかに応じて、選択された訪問先を示す訪問先番号を生成部２２に通知する。生成部２２は、受付部２１から通知された訪問先番号に基づいて、メッセージＤＢ３３及びメッセージ状態ＤＢ３４を参照し、選択された訪問先に関するメッセージの各々及び各メッセージの状態を特定する。そして、生成部２２は、特定した情報に基づいて、担当者端末４２の表示部に、例えば、図１０に示すように、選択された訪問先に関するメッセージ一覧画面９０Ａを表示する。

次に、ステップＳ３６で、受付部２１が、メッセージ一覧画面９０Ａの報告ボタン９２が選択されたか否かを判定する。報告ボタン９２が選択された場合には、処理はステップＳ３７へ移行し、選択されていない場合には、処理はステップＳ５５へ移行する。

ステップＳ３７では、受付部２１が、どの訪問先に関するメッセージ一覧画面９０Ａの報告ボタン９２が選択されたかを示す訪問先番号を生成部２２に通知する。生成部２２は、受付部２１から通知された訪問先番号と、世帯情報ＤＢ３１及び担当者情報ＤＢ３２とに基づいて、訪問先番号に対応する訪問先、宛先、承認者等を特定する。そして、特定した情報を用いて、担当者端末４２の表示部に、例えば、図１１に示すような訪問レポート作成画面１００Ａを表示する。

次に、ステップＳ３８で、受付部２１が、訪問レポート作成画面１００Ａの確認ボタン１０１が選択されたか否かを判定する。確認ボタン１０１が選択された場合には、処理は図２０のステップＳ４２へ移行し、選択されていない場合には、処理はステップＳ３９へ移行する。ステップＳ３９では、受付部２１が、訪問レポート作成画面１００Ａの一時保存ボタン１０２が選択されたか否かを判定する。一時保存ボタン１０２が選択された場合には、処理はステップＳ４０へ移行し、選択されていない場合には、処理はステップＳ４１へ移行する。

ステップＳ４０では、生成部２２が、訪問レポート作成画面１００Ａに入力されている内容をメッセージＤＢ３３に保存すると共に、メッセージ状態ＤＢ３４に、「状態」欄を「一時保存」とする情報を登録する。そして、処理はステップＳ３６に戻り、訪問レポート作成画面１００Ａを閉じて、メッセージ一覧画面９０Ａが表示される。なお、一時保存された訪問レポートが存在する状態で、上記ステップＳ３７へ移行した場合には、一時保存された情報を含む訪問レポート作成画面１００Ａを表示することができる。この際、一時保存されたメッセージのメッセージＩＤを、訪問レポート作成画面１００Ａの表示等の移行の処理に対応付ける。そして、メッセージＩＤが対応付けられた処理において、メッセージＤＢ３３及びメッセージ状態ＤＢ３４への登録処理が発生した場合には、対応付けられているメッセージＩＤと「メッセージＩＤ」が登録するメッセージの各情報を更新する。

一方、ステップＳ４１では、受付部２１が、訪問レポート作成画面１００Ａのキャンセルボタン１０３が選択されたか否かを判定する。キャンセルボタン１０３が選択された場合には、処理はステップＳ３６に戻り、選択されていない場合には、処理はステップＳ３８に戻る。

図２０のステップＳ４２では、生成部２２が、担当者端末４２の表示部に、例えば、図１２に示すような訪問レポート確認画面１１０Ａを表示する。

次に、ステップＳ４３で、受付部２１が、訪問レポート確認画面１１０Ａの承認依頼ボタン１１１が選択されたか否かを判定する。承認依頼ボタン１１１が選択された場合には、処理はステップＳ４４へ移行し、選択されていない場合には、処理はステップＳ４５へ移行する。

ステップＳ４４では、生成部２２が、訪問レポート確認画面１１０Ａに表示された内容をメッセージＤＢ３３に保存すると共に、メッセージ状態ＤＢ３４に、「状態」欄を「承認待ち」とする情報を登録する。そして、生成部２２は、担当者端末４２の表示部に、例えば、図１３に示すようなメッセージ一覧画面９０Ｂを表示し、承認者端末４３の表示部に、例えば、図１４に示すようなメッセージ一覧画面９０Ｃを表示する。

一方、ステップＳ４５では、受付部２１が、訪問レポート確認画面１１０Ａのキャンセルボタン１１２が選択されたか否かを判定する。キャンセルボタン１１２が選択された場合には、処理は図１９のステップＳ３７に戻り、選択されていない場合には、処理はステップＳ４３に戻る。

次に、ステップＳ４６で、受付部２１が、担当者端末４２の表示部に表示されたメッセージ一覧画面９０Ｂの承認依頼取戻しボタン９３が選択されたか否かを判定する。承認依頼取戻しボタン９３が選択された場合には、処理はステップＳ４７へ移行し、選択されていない場合には、処理はステップＳ４８へ移行する。

ステップＳ４７では、生成部２２が、承認依頼が取り戻しされた訪問レポートについて、メッセージ状態ＤＢ３４の「状態」欄を「一時保存」に更新する。また、生成部２２は、担当者端末４２の表示部に表示したメッセージ一覧画面９０Ｂ、及び承認者端末４３の表示部に表示したメッセージ一覧画面９０Ｃの各々から、承認依頼が取戻しされた訪問レポートを削除する。そして、処理は図１９のステップＳ３７に戻る。ここで表示される訪問レポート作成画面１００Ａには、承認依頼が取戻しされ、一時保存された訪問レポートの内容を表示することができる。

一方、ステップＳ４８では、受付部２１が、承認者端末４３の表示部に表示されたメッセージ一覧画面９０Ｃの否決ボタン９５が選択されたか否かを判定する。否決ボタン９５が選択された場合には、処理はステップＳ４９へ移行し、選択されていない場合には、処理はステップＳ５３へ移行する。

ステップＳ４９では、生成部２２が、承認者端末４３の表示部に表示されたメッセージ一覧画面９０Ｃから、否決された訪問レポートを削除すると共に、否決された訪問レポートについて、メッセージ状態ＤＢ３４の「状態」欄を「否決」に更新する。また、生成部２２は、担当者端末４２の表示部に、例えば、図１６に示すようなメッセージ一覧画面９０Ｅを表示する。

次に、ステップＳ５０で、受付部２１が、担当者端末４２の表示部に表示されたメッセージ一覧画面９０Ｅの編集ボタン９６が選択されたか否かを判定する。編集ボタン９６が選択された場合には、処理はステップＳ４７へ移行し、選択されていない場合には、処理はステップＳ５１へ移行する。

ステップＳ５１では、受付部２１が、担当者端末４２の表示部に表示されたメッセージ一覧画面９０Ｅの削除ボタン９７が選択されたか否かを判定する。削除ボタン９７が選択された場合には、処理はステップＳ５２へ移行し、選択されていない場合には、処理はステップＳ５０に戻る。

ステップＳ５２では、生成部２２が、否決された訪問レポートについて、メッセージＤＢ３３及びメッセージ状態ＤＢ３４の各々から該当の情報を削除する。また、生成部２２は、担当者端末４２の表示部に表示されたメッセージ一覧画面９０Ｅから、否決された訪問メッセージを削除する。そして、処理は図１９のステップＳ３６に戻る。

一方、ステップＳ５３では、受付部２１が、承認者端末４３の表示部に表示されたメッセージ一覧画面９０Ｃの承認ボタン９４が選択されたか否かを判定する。承認ボタン９４が選択された場合には、処理はステップＳ５４へ移行し、選択されていない場合には、処理はステップＳ４６に戻る。

ステップＳ５４では、生成部２２が、承認された訪問レポートについて、メッセージ状態ＤＢ３４の「状態」欄を「送信済み」に変更する。また、生成部２２は、契約者端末４１、担当者端末４２、及び承認者端末４３の各々に、例えば、図１５に示すようなメッセージ一覧画面９０Ｄの画面情報を送信する。そして、担当者投稿時のリクエスト処理は終了する。

また、図１９のステップＳ３６で否定判定されて、処理がステップＳ５５へ移行すると、受付部２１が、メッセージ一覧画面９０Ａからメッセージ作成ボタン（図示省略）が選択されたか否かを判定する。選択された場合には、処理は図２１のステップＳ５６へ移行し、選択されていない場合には、処理はステップＳ３６に戻る。

ステップＳ５６では、生成部２２が、受付部２１が、どの訪問先に関するメッセージ一覧画面９０Ａにおいてメッセージ作成ボタンが選択されたかを示す訪問先番号を生成部２２に通知する。生成部２２は、受付部２１から通知された訪問先番号と、世帯情報ＤＢ３１及び担当者情報ＤＢ３２とに基づいて、訪問先番号に対応する訪問先、宛先、承認者等を特定する。そして、特定した情報を用いて、担当者端末４２の表示部に、例えば、図１７に示すようなメッセージ作成画面１００Ｂを表示する。

次に、ステップＳ５７で、受付部２１が、メッセージ作成画面１００Ｂの確認ボタン１０１が選択されたか否かを判定する。確認ボタン１０１が選択された場合には、処理はステップＳ５８へ移行し、選択されていない場合には、処理はステップＳ６２へ移行する。ステップＳ６２では、受付部２１が、メッセージ作成画面１００Ｂの一時保存ボタン１０２が選択されたか否かを判定する。一時保存ボタン１０２が選択された場合には、処理はステップＳ６３へ移行し、選択されていない場合には、処理はステップＳ６４へ移行する。

ステップＳ６３では、生成部２２が、メッセージ作成画面１００Ｂに入力されている内容をメッセージＤＢ３３に保存すると共に、メッセージ状態ＤＢ３４に、「状態」欄を「一時保存」とする情報を登録する。そして、処理はステップＳ３６に戻り、メッセージ作成画面１００Ｂを閉じて、メッセージ一覧画面９０Ａが表示される。

一方、ステップＳ６４では、受付部２１が、メッセージ作成画面１００Ｂのキャンセルボタン１０３が選択されたか否かを判定する。キャンセルボタン１０３が選択された場合には、処理はステップＳ３６に戻り、選択されていない場合には、処理はステップＳ５７に戻る。

ステップＳ５８では、生成部２２が、担当者端末４２の表示部に、例えば、図１８に示すようなメッセージ確認画面１１０Ｂを表示する。

次に、ステップＳ５９で、受付部２１が、メッセージ確認画面１１０Ｂの投稿ボタン１１３が選択されたか否かを判定する。投稿ボタン１１３が選択された場合には、処理はステップＳ６０へ移行し、選択されていない場合には、処理はステップＳ６１へ移行する。

ステップＳ６０では、生成部２２が、訪問レポート確認画面１１０Ａに表示している内容をメッセージＤＢ３３に保存すると共に、メッセージ状態ＤＢ３４に、「状態」欄を「送信済み」とする情報を登録する。そして、生成部２２は、契約者端末４１、担当者端末４２、及び承認者端末４３の各々に、例えば、図１５に示すようなメッセージ一覧画面９０Ｄの画面情報を送信する。そして、担当者投稿時のリクエスト処理は終了する。

一方、ステップＳ６１では、受付部２１が、メッセージ確認画面１１０Ｂのキャンセルボタン１１２が選択されたか否かを判定する。キャンセルボタン１１２が選択された場合には、処理は図１９のステップＳ３７に戻り、選択されていない場合には、処理はステップＳ５９に戻る。

次に、承認者が承認処理を行う際のリクエスト処理について説明する。承認者が、承認者端末４３において、メッセージ投稿システム１０により提供されるアプリケーションを起動して、承認者ＩＤを用いてログインする。そして、承認者が、メニュー画面（図示省略）から訪問レポートのメニューを選択すると、リクエスト処理装置２０が、承認時のリクエスト処理を実行する。

承認時のリクエスト処理は、図１９に示す担当者投稿時のリクエスト処理のステップＳ３１〜Ｓ３５と概ね同様であるため、詳細な説明は省略する。なお、承認者は、検索条件として、「承認状態」から、状態が「承認待ち」のメッセージ（訪問レポート）を検索することにより、承認処理が未処理の訪問レポートを容易に検索することができる。また、検索条件として、「担当者未読超過時間」を指定することにより、否決した訪問レポートを担当者が所定時間以上確認していない場合を、容易に検索することができる。また、承認時のリクエスト処理で、生成部２２が、担当者投稿時のリクエスト処理のステップＳ３１〜Ｓ３５と同様に、メッセージ一覧画面９０Ａを承認者端末４３の表示部に表示した後の処理は、担当者投稿時のリクエスト処理にて実行される。

次に、契約者がメッセージの閲覧を行う際のリクエスト処理について説明する。契約者が、契約者端末４１において、メッセージ投稿システム１０により提供されるアプリケーションを起動して、契約者の識別番号又は契約者が契約している訪問先の訪問先番号を用いてログインする。そして、契約者が、メニュー画面（図示省略）からメッセージ閲覧のメニューを選択すると、生成部２２が、担当者投稿時のリクエスト処理のステップＳ３５と同様の処理により、契約者が契約している訪問先に関するメッセージ一覧画面９０Ａを、契約者端末４１の表示部に表示する。

また、契約者がメッセージを投稿する場合には、生成部２２は、担当者投稿時のリクエスト処理のステップＳ５５〜Ｓ５９と同様の処理を実行する。

以上説明したように、本実施形態に係るリクエスト処理装置を含むメッセージ投稿システムによれば、担当者が訪問先に関する訪問レポートを契約者に送信する際に、承認者に承認依頼を行う。この際、承認者の端末には、契約者と担当者との間で過去にやり取りされたメッセージの一覧と共に、承認対象のメッセージと、承認又は否決を選択するためのボタンとを表示する。従って、承認者は、契約者と担当者との間で過去にやり取りされたメッセージを参照して、承認依頼されているメッセージの送信先が誤っていないか否かを確認することができる。これにより、送信するメッセージの内容と送信先との関係を容易に確認できない場合でも、メッセージの誤送信を防止することができる。

また、契約者と担当者との間で過去にやり取りされたメッセージを参照して、承認依頼されているメッセージの内容に不適切な内容や、不足している内容がないかなどを確認することができ、業務の確実性が向上する。

なお、上記実施形態では、子世帯との契約により親世帯を訪問する訪問サービスに本発明を適用した場合について説明したが、これに限定されない。担当者が報告する内容と、報告の送信先との関係の把握が容易ではない場合には、本発明を適用することが有効である。

また、上記実施形態では、訪問サービスの中で、特に訪問レポートの送信に関する部分に本発明を適用した場合について説明したが、これに限定されない。例えば、訪問サービスを、親世帯と子世帯との関係をより深めるためのポータルサービス（例えば、家族史作成支援、家族間での写真共有サービス等）の一部に組み入れることも可能である。この場合、例えば、担当者が作成した訪問レポートが承認者により承認されると、ポータルサービスのサイト上に、訪問レポートが作成された旨を通知することができる。また、この通知には、メッセージ一覧画面へのリンクを貼っておいてもよい。

また、上記実施形態では、契約者とサービス提供者との間のやりとりを、電子掲示板形式のアプリケーションを介して、契約者とサービス提供者との間で、メッセージをやりとりする場合について説明したが、これに限定されない。例えば、通常の電子メールシステムにも適用可能である。この場合、担当者が承認依頼を行うと、訪問レポート（メール）が承認者へ送信され、承認者端末に、承認対象の訪問レポートと共に、契約者と担当者との間で過去にやり取りされたメールを合わせて表示すればよい。また、承認対象の訪問レポートと共に、承認又は否決を選択するためのボタン等を配置し、承認が選択された場合には、対象の訪問レポートを契約者に送信すればよい。否決が選択された場合には、対象の訪問レポートを担当者に返送すればよい。

また、上記実施形態において、承認者が、承認待ちのメッセージを否決する際には、その理由などについてコメントを付すようにしてもよい。例えば、承認者が否決ボタン９５を選択すると、コメント入力のための画面を表示し、コメントの入力を受け付ける。そして、入力されたコメント、又はコメントを表示するためのボタンを、メッセージ一覧画面９０Ｅに、編集ボタン９６及び削除ボタン９７と共に表示することができる。

なお、上記では、リクエスト処理プログラム６０が記憶部５３に予め記憶（インストール）されている態様を説明したが、これに限定されない。開示の技術に係るプログラムは、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＵＳＢメモリ等の記録媒体に記録された形態で提供することも可能である。

以上の実施形態に関し、更に以下の付記を開示する。

（付記１）
第１の通信装置から第２の通信装置に提供する対象のデータと、該対象のデータを前記第２の通信装置に対する提供の許可を求めるリクエストとを受信すると、前記リクエストの承認処理を行う端末に対して、前記第１の通信装置、前記第２の通信装置、前記端末のいずれかから過去に送信されたデータに含まれるメッセージが配置され、承認処理を起動する表示部品を含む承認処理画面情報を送信する
ことをコンピュータに実行させることを特徴とするリクエスト処理方法。

（付記２）
前記過去に送信されたデータは、前記第１の通信装置、前記第２の通信装置、及び前記端末の少なくとも１つに提供されたデータである付記１記載のリクエスト処理方法。

（付記３）
前記提供されたデータは、前記第１の通信装置、前記第２の通信装置、及び前記端末の少なくとも１つにおいて閲覧されたデータである付記２記載のリクエスト処理方法。

（付記４）
前記端末から、前記承認処理の結果として、承認することを示す応答を受信した場合に、前記第２の通信装置に提供する対象のデータを、前記第２の通信装置へ送信する
ことをさらに含む処理を前記コンピュータに実行させることを特徴とする付記１〜付記３のいずれか１項記載のリクエスト処理方法。

（付記５）
前記第１の通信装置から前記第２の通信装置に提供する対象のデータを受信したが、前記第２の通信装置に対する提供の許可を求めるリクエストを受信しない場合は、前記第２の通信装置に提供する対象のデータを、前記第２の通信装置へ送信する
ことをさらに含む処理を前記コンピュータに実行させることを特徴とする付記１〜付記４のいずれか１項記載のリクエスト処理方法。

（付記６）
前記承認処理画面情報が示す承認処理画面において、前記過去に送信されたデータに含まれるメッセージを時系列に配置する付記１〜付記５のいずれか１項記載のリクエスト処理方法。

（付記７）
第１の通信装置から第２の通信装置に提供する対象のデータと、該対象のデータを前記第２の通信装置に対する提供の許可を求めるリクエストとを受信すると、前記リクエストの承認処理を行う端末に対して、前記第１の通信装置、前記第２の通信装置、前記端末のいずれかから過去に送信されたデータに含まれるメッセージが配置され、承認処理を起動する表示部品を含む承認処理画面情報を送信する送信部と、
を含むリクエスト処理装置。

（付記８）
前記過去に送信されたデータは、前記第１の通信装置、前記第２の通信装置、及び前記端末の少なくとも１つに提供されたデータである付記７記載のリクエスト処理装置。

（付記９）
前記提供されたデータは、前記第１の通信装置、前記第２の通信装置、及び前記端末の少なくとも１つにおいて閲覧されたデータである付記８記載のリクエスト処理装置。

（付記１０）
前記送信部は、前記端末から、前記承認処理の結果として、承認することを示す応答を受信した場合に、前記第２の通信装置に提供する対象のデータを、前記第２の通信装置へ送信する付記７〜付記９のいずれか１項記載のリクエスト処理装置。

（付記１１）
前記送信部は、前記第１の通信装置から前記第２の通信装置に提供する対象のデータを受信したが、前記第２の通信装置に対する提供の許可を求めるリクエストを受信しない場合は、前記第２の通信装置に提供する対象のデータを、前記第２の通信装置へ送信する付記７〜付記１０のいずれか１項記載のリクエスト処理装置。

（付記１２）
前記送信部は、前記承認処理画面情報が示す承認処理画面において、前記過去に送信されたデータに含まれるメッセージを時系列に配置する付記７〜付記１１のいずれか１項記載のリクエスト処理装置。

（付記１３）
第１の通信装置から第２の通信装置に提供する対象のデータと、該対象のデータを前記第２の通信装置に対する提供の許可を求めるリクエストとを受信すると、前記リクエストの承認処理を行う端末に対して、前記第１の通信装置、前記第２の通信装置、前記端末のいずれかから過去に送信されたデータに含まれるメッセージが配置され、承認処理を起動する表示部品を含む承認処理画面情報を送信する
ことをコンピュータに実行させることを特徴とするリクエスト処理プログラム。

（付記１４）
前記過去に送信されたデータは、前記第１の通信装置、前記第２の通信装置、及び前記端末の少なくとも１つに提供されたデータである付記１３記載のリクエスト処理プログラム。

（付記１５）
前記提供されたデータは、前記第１の通信装置、前記第２の通信装置、及び前記端末の少なくとも１つにおいて閲覧されたデータ付記１４記載のリクエスト処理プログラム。

（付記１６）
前記端末から、前記承認処理の結果として、承認することを示す応答を受信した場合に、前記第２の通信装置に提供する対象のデータを、前記第２の通信装置へ送信する
ことをさらに含む処理を前記コンピュータに実行させることを特徴とする付記１３〜付記１５のいずれか１項記載のリクエスト処理プログラム。

（付記１７）
前記第１の通信装置から前記第２の通信装置に提供する対象のデータを受信したが、前記第２の通信装置に対する提供の許可を求めるリクエストを受信しない場合は、前記第２の通信装置に提供する対象のデータを、前記第２の通信装置へ送信する
ことをさらに含む処理を前記コンピュータに実行させることを特徴とする付記１３〜付記１６のいずれか１項記載のリクエスト処理プログラム。

（付記１８）
前記承認処理画面情報が示す承認処理画面において、前記過去に送信されたデータに含まれるメッセージを時系列に配置する付記１３〜付記１７のいずれか１項記載のリクエスト処理プログラム。

（付記１９）
第１の通信装置から第２の通信装置に提供する対象のデータと、該対象のデータを前記第２の通信装置に対する提供の許可を求めるリクエストとを受信すると、前記リクエストの承認処理を行う端末に対して、前記第１の通信装置、前記第２の通信装置、前記端末のいずれかから過去に送信されたデータに含まれるメッセージが配置され、承認処理を起動する表示部品を含む承認処理画面情報を送信する
ことをコンピュータに実行させることを特徴とするリクエスト処理プログラムを記憶した記憶媒体。

１０ メッセージ投稿システム
２０ リクエスト処理装置
２１ 受付部
２２ 生成部
２３ 送信部
３１ 世帯情報データベース（ＤＢ）
３２ 担当者情報ＤＢ
３３ メッセージＤＢ
３４ メッセージ状態ＤＢ
４１ 契約者端末
４２ 担当者端末
４３ 承認者端末
５０ コンピュータ
５１ ＣＰＵ
５２ メモリ
５３ 記憶部
６０ リクエスト処理プログラム
６１ 受付プロセス
６２ 生成プロセス
６３ 送信プロセス
８０ 訪問レポート一覧画面
９０Ａ、９０Ｂ、９０Ｃ、９０Ｄ、９０Ｅ メッセージ一覧画面
９１ メッセージ
９４ 承認ボタン
９５ 否決ボタン
１００Ａ 訪問レポート作成画面
１００Ｂ メッセージ作成画面
１１０Ａ 訪問レポート確認画面
１１０Ｂ メッセージ確認画面
１１０Ａ メッセージ確認画面
１１０Ｂ メッセージ確認画面

Claims (8)

1. 第１の通信装置から第２の通信装置に提供する対象のデータと、該対象のデータを前記第２の通信装置に対する提供の許可を求めるリクエストとを受信すると、前記リクエストの承認処理を行う端末に対して、前記第１の通信装置、前記第２の通信装置、前記端末のいずれかから過去に送信されたデータに含まれるメッセージが配置され、承認処理を起動する表示部品を含む承認処理画面情報を送信する
   ことをコンピュータに実行させることを特徴とするリクエスト処理方法。
2. 前記過去に送信されたデータは、前記第１の通信装置、前記第２の通信装置、及び前記端末の少なくとも１つに提供されたデータである請求項１記載のリクエスト処理方法。
3. 前記提供されたデータは、前記第１の通信装置、前記第２の通信装置、及び前記端末の少なくとも１つにおいて閲覧されたデータである請求項２記載のリクエスト処理方法。
4. 前記端末から、前記承認処理の結果として、承認することを示す応答を受信した場合に、前記第２の通信装置に提供する対象のデータを、前記第２の通信装置へ送信する
   ことをさらに含む処理を前記コンピュータに実行させることを特徴とする請求項１〜請求項３のいずれか１項記載のリクエスト処理方法。
5. 前記第１の通信装置から前記第２の通信装置に提供する対象のデータを受信したが、前記第２の通信装置に対する提供の許可を求めるリクエストを受信しない場合は、前記第２の通信装置に提供する対象のデータを、前記第２の通信装置へ送信する
   ことをさらに含む処理を前記コンピュータに実行させることを特徴とする請求項１〜請求項４のいずれか１項記載のリクエスト処理方法。
6. 前記承認処理画面情報が示す承認処理画面において、前記過去に送信されたデータに含まれるメッセージを時系列に配置する請求項１〜請求項５のいずれか１項記載のリクエスト処理方法。
7. 第１の通信装置から第２の通信装置に提供する対象のデータと、該対象のデータを前記第２の通信装置に対する提供の許可を求めるリクエストとを受信すると、前記リクエストの承認処理を行う端末に対して、前記第１の通信装置、前記第２の通信装置、前記端末のいずれかから過去に送信されたデータに含まれるメッセージが配置され、承認処理を起動する表示部品を含む承認処理画面情報を送信する送信部と、
   を含むリクエスト処理装置。
8. 第１の通信装置から第２の通信装置に提供する対象のデータと、該対象のデータを前記第２の通信装置に対する提供の許可を求めるリクエストとを受信すると、前記リクエストの承認処理を行う端末に対して、前記第１の通信装置、前記第２の通信装置、前記端末のいずれかから過去に送信されたデータに含まれるメッセージが配置され、承認処理を起動する表示部品を含む承認処理画面情報を送信する
   ことをコンピュータに実行させることを特徴とするリクエスト処理プログラム。