(57)【要約】【課題】手書き入力された情報と手書き入力の対象の文字列とのずれの発生を抑制する。【解決手段】画面生成プログラムは、所定の文字列を含み、該文字列に対する手書き入力が可能な画面を表示させる第一の画面データを生成し、前記第一の画面データを第一の端末に送信し、前記所定の文字列に対する手書き入力情報を、前記第一の端末より受信し、前記第一の画面データと同じ表示形式の前記所定の文字列と、前記手書き入力情報とを第二の端末に送信する処理をコンピュータに実行させる。【選択図】図３
2014048709.tif 000002
【特許請求の範囲】
【請求項１】
所定の文字列を含み、該文字列に対する手書き入力が可能な画面を表示させるための第一の画面データを生成し、
前記第一の画面データを第一の端末に送信し、
前記所定の文字列に対する手書き入力情報を、前記第一の端末より受信し、
前記第一の画面データと同じ表示形式の前記所定の文字列と、前記手書き入力情報とを第二の端末に送信する処理をコンピュータに実行させる画面生成プログラム。
【請求項２】
前記所定の文字列を前記第一の画面データと同じ表示形式で含み、前記手書き入力情報が前記所定の文字列に重畳された画面を表示させる第二の画面データを生成する処理を前記コンピュータに実行させ、
前記第二の端末に送信する処理は、前記第二の画面データを第二の端末に送信する請求項１記載の画面生成プログラム。
【請求項３】
前記所定の文字列と、前記第二の端末における前記所定の文字列の表示形式を示す表示形式情報とを前記第二の端末より受信する処理を前記コンピュータに実行させ、
前記第一の画面データを生成する処理は、前記第二の端末より受信された前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第一の画面データを生成し、
前記第二の画面データを生成する処理は、前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第二の画面データを生成する請求項２記載の画面生成プログラム。
【請求項４】
前記第一の端末より受信する処理は、前記手書き入力情報と、前記第一の端末における前記所定の文字列の表示形式を示す表示形式情報とを前記第一の端末より受信し、
前記第二の画面データを生成する処理は、前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第二の画面データを生成する請求項２記載の画面生成プログラム。
【請求項５】
所定の文字列を含み、該文字列に対する手書き入力が可能な画面を表示させる第一の画面データを生成し、
前記第一の画面データを第一の端末に送信し、
前記所定の文字列に対する手書き入力情報を、前記第一の端末より受信し、
前記第一の画面データと同じ表示形式の前記所定の文字列と、前記手書き入力情報とを第二の端末に送信する処理をコンピュータが実行する画面生成方法。
【請求項６】
所定の文字列を含み、該文字列に対する手書き入力が可能な画面を表示させる第一の画面データを生成する生成部と、
前記第一の画面データを第一の端末に送信する第一の送信部と、
前記所定の文字列に対する手書き入力情報を、前記第一の端末より受信する受信部と、
前記第一の画面データと同じ表示形式の前記所定の文字列と、前記手書き入力情報とを第二の端末に送信する第二の送信部とを有する画面生成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画面生成プログラム、画面生成方法、及び画面生成装置に関する。
【背景技術】
【０００２】
例えば、ビジネス上の電子メールについて、内容に誤りの有るメールや、表現が適切でないメール等が顧客や取引先等に送信されてしまうと、顧客や取引先の信用を失ったり、感情を損なったりする可能性がある。
【０００３】
そこで、従来、ビジネスユースのメールシステムにおいて、利用者（以下、承認依頼者とする）が、メールを送信しようとすると、自動的に、その利用者の上司（以下、承認者とする）に承認依頼が届き、承認者がその内容をチェックすることが可能なメールシステムが有る。承認者の承認が得られたら、当該メールは宛先に正式に送信され、承認者の承認が得られない場合、当該メールは承認依頼者に差し戻される。
【０００４】
メールが承認依頼者に差し戻される場合、修正内容が明示されることが好ましい。修正内容の明示は、メールの本文内に文章を追記することや、専用のコメント欄に記載することによって行われることが考えられる。しかし、この場合、承認者からすれば、いずれの段落のいずれの部分をどのように変更すべきであるのか、といったような内容を文章で表現するのは非常に煩わしいという問題がある。また、承認依頼者からすれば、いずれの部分をどのように変更すべきであるのかを直感的に把握するのが困難であるという問題がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００３−１８７０６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
そこで、昨今、利用者が拡大しているスマートフォンのような小型携帯端末の手書き入力機能を利用して承認者が修正内容を明示することが考えられる。手書き入力機能とは、承認対象のメール本文に対して、マウス、タッチパッド、又はタッチパネル等のポインティングデバイスによって、図形や文字等を描画可能な機能をいう。
【０００７】
手書き入力機能によれば、承認者は、紙面上に書き入れを行うような感覚で、修正内容を明示することができる。承認依頼者は、手書き入力された図形や文字等を参照して、直感的に修正内容を把握することができる。
【０００８】
しかしながら、手書き入力機能によって入力された情報は、承認依頼対象のメール本文からは独立した画像データ（以下、「手書き入力画像」という。）に記録される。したがって、承認者が利用する端末におけるメールの表示形式（例えば、フォント、フォントサイズ等）と、承認依頼者が利用する端末におけるメールの表示形式とが異なっている場合、承認依頼者側の端末において、手書き入力画像が正しく表示されない可能性がある。すなわち、手書き入力画像が、承認依頼対象のメール本文にそのまま重畳された場合、手書き入力画像内の描画要素と、メール本文の文字列との間にずれが生じる可能性が有る。
【０００９】
そこで、本発明の一側面では、手書き入力された情報と手書き入力の対象の文字列とのずれの発生を抑制すること目的とする。
【課題を解決するための手段】
【００１０】
一つの案では、画面生成プログラムは、所定の文字列を含み、該文字列に対する手書き入力が可能な画面を表示させる第一の画面データを生成し、前記第一の画面データを第一の端末に送信し、前記所定の文字列に対する手書き入力情報を、前記第一の端末より受信し、前記第一の画面データと同じ表示形式の前記所定の文字列と、前記手書き入力情報とを第二の端末に送信する処理をコンピュータに実行させる。
【発明の効果】
【００１１】
一態様によれば、手書き入力された情報と手書き入力の対象の文字列とのずれの発生を抑制する。
【図面の簡単な説明】
【００１２】
【図１】本実施の形態におけるメールシステムの構成例を示す図である。
【図２】本実施の形態におけるメールサーバのハードウェア構成例を示す図である。
【図３】本実施の形態におけるメールシステムの機能構成例を示す図である。
【図４】メールサーバが実行する処理手順を説明するためのフローチャートである。
【図５】メールサーバが実行する処理手順を説明するためのフローチャートである。
【図６】ユーザ情報記憶部の構成例を示す図である。
【図７】メール記憶部の構成例を示す図である。
【図８】受信メール一覧画面の表示例を示す図である。
【図９】承認依頼情報記憶部の構成例を示す図である。
【図１０】メール作成画面の表示例を示す図である。
【図１１】表示形式記憶部の構成例を示す図である。
【図１２】承認依頼一覧画面の表示例を示す図である。
【図１３】承認画面の表示例を示す図である。
【図１４】承認画面の本文表示領域に対する属性情報の設定例を示す図である。
【図１５】手書き入力が可能な承認画面の表示例を示す図である。
【図１６】承認結果一覧画面の表示例を示す図である。
【図１７】修正画面の表示例を示す図である。
【図１８】再承認依頼時の承認画面の表示例を示す図である。
【発明を実施するための形態】
【００１３】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本実施の形態におけるメールシステムの構成例を示す図である。
【００１４】
図１に示されるメールシステム１において、メールサーバ１０、クライアント端末２０ａ、及びクライアント端末２０ｂ等は、ＬＡＮ（Local Area Network）又はインターネット等のネットワークを介して通信可能とされている。ネットワークの一部は、無線であってもよい。
【００１５】
メールサーバ１０は、Ｗｅｂメールサービスを、例えば、イントラネット上のサービス又はクラウドサービス等の形態で提供する１以上のコンピュータである。Ｗｅｂメールサービスにおいて、各ユーザの受信メールや送信メール等は、サーバ側であるメールサーバ１０において管理される。
【００１６】
クライアント端末２０ａ及び２０ｂは、Ｗｅｂメールサービスのユーザが利用する端末である。本実施の形態において、クライアント端末２０ｂは、メールを作成し、当該メールの承認を承認者に依頼する承認依頼者が利用する端末である。クライアント端末２０ａは、メールの承認者が利用する端末である。クライアント端末２０ａ及びクライアント端末２０ｂの一例として、ＰＣ（Personal Computer）、携帯電話、スマートフォン、又はタブレット型端末等が挙げられる。但し、クライアント端末２０ａは、マウス、タッチパッド、又はタッチパネル等のポインティングデバイスを利用で可能な端末であるのが好適である。なお、クライアント端末２０ａ及び２０ｂを区別しない場合、「クライアント端末２０」という。
【００１７】
図２は、本実施の形態におけるメールサーバのハードウェア構成例を示す図である。図２のメールサーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００１８】
メールサーバ１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１９】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってメールサーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００２０】
なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。
【００２１】
なお、クライアント端末２０ａ及びクライアント端末２０ｂについても、図２に示されるハードウェアを有していてもよい。
【００２２】
図３は、本実施の形態におけるメールシステムの機能構成例を示す図である。図３において、メールサーバ１０は、認証部１１１、受信メール一覧画面生成部１１２、メール作成画面生成部１１３、承認依頼一覧画面生成部１１４、承認画面生成部１１５、承認結果一覧画面生成部１１６、修正画面生成部１１７、承認依頼部１１８、承認処理部１１９、メール送信部１２０、要求受信部１２１、及び応答返信部１２２等を有する。これら各部は、メールサーバ１０にインストールされた一以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。
【００２３】
メールサーバ１０は、また、ユーザ情報記憶部１３１、メール記憶部１３２、承認依頼情報記憶部１３３、及び表示形式記憶部１３４等を利用する。これら各記憶部は、補助記憶装置１０２、又はメールサーバ１０にネットワークを介して接続される記憶装置等を利用して実現可能である。
【００２４】
要求受信部１２１は、クライアント端末２０からの要求を受信する。認証部１１１は、Ｗｅｂメールサービスのユーザの認証処理を実行する。受信メール一覧画面生成部１１２は、認証されたユーザの受信メールの一覧を表示させる画面（以下、「受信メール一覧画面」という。）の画面データを生成する。画面データは、ＨＴＭＬ（HyperText Markup Language）やスクリプト等を利用して生成されてもよい。メール作成画面生成部１１３は、新規メール又は返信メール等をユーザに作成させるための画面（以下、「メール作成画面」という。）の画面データを生成する。なお、メール作成画面を介して作成され、送信指示が入力されたメールについては、当該メールの作成者に対応する承認者に対して承認依頼が行われる。承認依頼一覧画面生成部１１４は、一人の承認者に対する承認依頼の一覧を表示させる画面（以下、「承認依頼一覧画面」という。）の画面データを生成する。承認画面生成部１１５は、承認依頼一覧画面において選択された承認依頼について承認又は修正指示の入力等を行わせる画面（以下、「承認画面」という。）の画面データを生成する。承認結果一覧画面生成部１１６は、修正指示が入力された承認依頼に対する承認結果の一覧を表示させる画面（以下、「承認結果一覧画面」という。）の画面データを生成する。修正画面生成部１１７は、修正指示が入力されている承認結果に係るメールの内容を修正させる画面（以下、「修正画面」という。）の画面データを生成する。
【００２５】
承認依頼部１１８は、メール作成画面において送信指示が入力されたメールについて、承認依頼のための処理を実行する。具体的には、承認依頼部１１８は、当該メールに関する承認依頼を示すレコードを生成し、当該レコードを承認依頼情報記憶部１３３に記憶する。
【００２６】
承認処理部１１９は、承認画面における承認結果に応じた処理を実行する。メール送信部１２０は、承認されたメールを宛先に送信する。応答返信部１２２は、クライアント端末２０からの要求に応じた応答を、クライアント端末２０に返信する。例えば、当該応答には、上記のいずれかの画面データが含まれる。
【００２７】
ユーザ情報記憶部１３１は、メールサーバ１０が提供するＷｅｂメールサービスのユーザごとの情報を記憶する。メール記憶部１３２は、ユーザごとに受信メール又は送信メールの情報を記憶する。承認依頼情報記憶部１３３は、送信メールに関して行われる承認依頼ごとに、当該承認依頼に関する情報を記憶する。表示形式記憶部１３４は、クライアント端末２０ｂにおいてメール作成画面が表示されていた際の、本文の入力領域における文字列の表示形式情報を記憶する。表示形式情報には、例えば、フォント名、フォントサイズ、１行の文字数、及び行間隔等が含まれる。なお、承認画面や修正画面において、承認依頼の対象とされたメールの本文が表示される領域の文字列の表示形式は、当該表示形式情報に基づいて決定される。
【００２８】
クライアント端末２０は、ブラウザ部２１等を含む。ブラウザ部２１は、クライアント端末２０にインストールされたプログラムが、クライアント端末２０のＣＰＵに実行させる処理により実現される。ブラウザ部２１は、メールサーバ１０によって生成される画面データに基づく画面をクライアント端末２０の表示装置に表示させたり、当該画面に対する入力に応じた要求を、メールサーバ１０に送信したりする。
【００２９】
以下、メールシステム１において、メールサーバ１０が実行する処理手順について説明する。図４及び図５は、メールサーバ１０が実行する処理手順を説明するためのフローチャートである。
【００３０】
メールサーバ１０の要求受信部１２１は、クライアント端末２０からの要求の受信を待機している。要求受信部１２１が、いずれかのクライアント端末２０から、受信メールの一覧の表示要求を受信すると（Ｓ１０１でＹｅｓ）、認証部１１１は、ログイン画面を表示させる画面データを含む応答を、クライアント端末２０に返信する（Ｓ１０２）。ログイン画面とは、ユーザＩＤ及びパスワードを入力させるための画面をいう。当該応答を受信したクライアント端末２０のブラウザ部２１は、当該応答に含まれている画面データに基づいて、ログイン画面を表示させる。ユーザは、ログイン画面に対してユーザＩＤ及びパスワードを入力する。なお、本実施の形態では、各ユーザのメールアドレスが各ユーザのユーザＩＤとして利用される。ログイン画面に対してログイン指示が入力されると、ブラウザ部２１は、入力されたユーザＩＤ及びパスワードが指定されたログイン要求を、メールサーバ１０に送信する。
【００３１】
メールサーバ１０の要求受信部１２１が、ユーザＩＤ及びパスワードが指定されたログイン要求を受信すると（Ｓ１０３でＹｅｓ）、認証部１１１は、ユーザ情報記憶部１３１を参照して、当該ユーザＩＤ及びパスワードについて認証処理を実行する（Ｓ１０４）。
【００３２】
図６は、ユーザ情報記憶部の構成例を示す図である。図６において、ユーザ情報記憶部１３１は、ユーザごとに、ユーザＩＤ、パスワード、名前、承認者アドレス、及び承認者名等を対応付けて記憶する。
【００３３】
ユーザＩＤは、ユーザごとの識別情報であると共に、ユーザのメールアドレスである。パスワードは、ユーザのパスワードである。名前は、ユーザの名前である。承認者アドレスは、ユーザにとって承認者となるユーザのメールアドレス及びユーザＩＤである。承認者名は、ユーザにとって承認者となるユーザの名前である。
【００３４】
ステップＳ１０４における認証処理において、ログイン要求に指定されたユーザＩＤ及びパスワードを含むレコードがユーザ情報記憶部１３１に記憶されている場合は、認証は成功したと判定される。認証に成功した場合、ログイン要求に指定されたユーザＩＤは、ログインユーザＩＤとして、例えば、メモリ装置１０３に記憶される。ログイン要求に指定されたユーザＩＤ及びパスワードを含むレコードがユーザ情報記憶部１３１に記憶されていない場合は、認証は失敗したと判定される。なお、認証に成功した場合、クライアント端末２０とメールサーバ１０との間では、例えば、一般的なセッション管理が行われる。したがって、メールサーバ１０は、複数のクライアント端末２０に対して並行して対応している場合であっても、各クライアント端末２０からの要求に対応するログインユーザＩＤを特定することができる。
【００３５】
認証に失敗した場合（Ｓ１０５でＮｏ）、図４及び図５の処理は終了する。認証に成功した場合（Ｓ１０５でＹｅｓ）、受信メール一覧画面生成部１１２は、ログインユーザＩＤに対応する受信メールの一覧をメール記憶部１３２より取得し、受信メール一覧画面を表示させる画面データを生成する（Ｓ１０６）。
【００３６】
図７は、メール記憶部の構成例を示す図である。図７において、（Ａ）は、ユーザＩＤが、「ｙａｍａｄａ＠ｘｘｘ．ｗｗｗ」であるユーザ（以下、「ユーザｙａｍａｄａ」という。）に対するレコードを示し、（Ｂ）は、ユーザＩＤが、「ｔａｎａｋａ＠ｘｘｘ．ｗｗｗ」であるユーザ（以下、「ユーザｔａｎａｋａ」という。）に対するレコードを示す。
【００３７】
図７に示されるように、メール記憶部１３２は、ユーザの受信メール又は送信メールごとに、ユーザＩＤ、区分、メッセージＩＤ、送信元アドレス、宛先アドレス、日時、及びメール情報等を記憶する。
【００３８】
ユーザＩＤは、当該メールの送信者又は受信者であるユーザのユーザＩＤである。区分は、当該メールが受信メールであるか、送信メールであるかを示す情報である。送信元アドレスは、当該メールの送信元のメールアドレスである。宛先アドレスは、当該メールの宛先のメールアドレスである。日時は、受信メールについては受信日時、送信メールについては送信日時である。
【００３９】
メール情報は、メール自体の内容である。図７では、件名及び本文がメール情報を構成する。件名は、メールの件名又はタイトルである。本文は、メールの本文の文字列である。
【００４０】
ステップＳ１０６では、ログインユーザＩＤに係るレコードであって、かつ、「区分」の値が「受信」であるレコードが抽出される。抽出されたレコードに基づいて受信メール一覧画面を表示させる画面データが生成される。
【００４１】
続いて、応答返信部１２２は、当該画面データを含む応答を、クライアント端末２０に返信する（Ｓ１０７）。当該応答を受信したクライアント端末２０のブラウザ部２１は、当該応答に含まれている画面データに基づいて、受信メール一覧画面を表示させる。
【００４２】
図８は、受信メール一覧画面の表示例を示す図である。図８において、上側に示されている受信メール一覧画面５１０ａは、図７の（Ａ）のレコードに対応する。すなわち、受信メール一覧画面５１０ａは、ユーザｙａｍａｄａが、ログインユーザである場合に表示される画面である。下側に示されている受信メール一覧画面５１０ｂは、図７の（Ｂ）のレコードに対応する。すなわち、受信メール一覧画面５１０ｂは、ユーザｔａｎａｋａが、ログインユーザである場合に表示される画面である。なお、受信メール一覧画面５１０ａ及び受信メール一覧画面５１０ｂを区別しない場合、「受信メール一覧画面５１０」という。
【００４３】
各受信メール一覧画面５１０は、受信メール一覧領域５１１、新規作成ボタン５１２、返信ボタン５１３、承認結果一覧ボタン５１４、及びログアウトボタン５１６等を含む。
【００４４】
受信メール一覧領域５１１には、受信メールごとに、差出人、日時、及び件名が表示される。差出人、日時、及び件名には、メール記憶部１３２（図７）における、「送信元アドレス」、「日時」、又は「件名」の値が表示される。
【００４５】
新規作成ボタン５１２は、新規のメールの作成指示を受け付けるためのボタンである。返信ボタン５１３は、受信メール一覧領域５１１において選択されている受信メールに対する返信メールの作成指示を受け付けるためのボタンである。承認結果一覧ボタン５１４は、承認結果一覧の表示指示を受け付けるためのボタンである。ログアウトボタン５１６は、ログアウト指示を受け付けるためのボタンである。
【００４６】
受信メール一覧画面５１０ａは、更に、承認処理ボタン５１５を有する。これは、ユーザｙａｍａｄａには、承認依頼が有るためである。本実施の形態において、ユーザｙａｍａｄａは、クライアント端末２０ｂのユーザ、すなわち、承認者であり、ユーザｔａｎａｋａは、クライアント端末２０ａのユーザ、すなわち、承認依頼者である。
【００４７】
承認依頼の有無は、承認依頼情報記憶部１３３を参照することにより特定することができる。図９は、承認依頼情報記憶部の構成例を示す図である。図９では、便宜上、ユーザｙａｍａｄａに対する承認依頼に係るレコードが示されている。
【００４８】
図９に示されるように、承認依頼情報記憶部１３３は、承認者のユーザＩＤに対応付けて、当該承認者に対する承認依頼ごとに、承認依頼ＩＤ、メッセージＩＤ、状態、依頼者ＩＤ、宛先アドレス、ＣＣアドレス、承認依頼日時、チェックシート名、及びメール情報等を記憶する。
【００４９】
承認依頼ＩＤは、承認依頼ごとの識別情報である。メッセージＩＤは、承認依頼の対象とされたメールのメッセージＩＤである。状態は、承認依頼の状態であり、「承認依頼中」、「差し戻し」、又は「承認済み」の値のいずれかをとる。依頼者ＩＤは、承認依頼者のユーザＩＤである。宛先アドレスは、承認依頼の対象とされたメールの宛先となるメールアドレスである。ＣＣアドレスは、承認依頼の対象とされたメールのＣＣ宛のメールアドレスである。承認依頼日時は、承認依頼が行われた日時である。チェックシート名は、チェックシートを格納したファイルのファイル名である。チェックシートとは、承認者による手書き入力によって描き込まれた情報（描画要素）が記録された画像データをいう。チェックシート名は、差し戻された承認依頼に関して有効である。メール情報は、承認依頼の対象とされたメールの件名及び本文である。
【００５０】
すなわち、受信メール一覧画面生成部１１２は、ステップＳ１０７において、ログインユーザＩＤに対応する承認依頼情報記憶部１３３のレコードの中で、「状態」の値が「承認依頼中」であるレコードの件数を計数する。当該レコードの数が０であれば、受信メール一覧画面生成部１１２は、生成対象の受信メール一覧画面５１０に対して承認処理ボタン５１５を配置しない。または、承認処理ボタン５１５がグレーアウトされてもよい。当該レコードの数が１以上であれば、受信メール一覧画面生成部１１２は、生成対象の受信メール一覧画面５１０に対して承認処理ボタン５１５を配置し、当該レコード数が承認待ち件数として承認処理ボタン５１５に表示されるようにする。図９に示すユーザｙａｍａｄａに対する承認依頼に係るレコードでは、「状態」の値が「承認依頼中」であるレコードが２件有る。したがって、図８のユーザｙａｍａｄａに対する受信メール一覧画面５１０ａの承認処理ボタン５１５には、承認待ちの件数が２件であるメッセージが表示されている。
【００５１】
受信メール一覧画面５１０において、新規作成ボタン５１２又は返信ボタン５１３が押下されると、当該クライアント端末２０のブラウザ部２１は、メール作成要求をメールサーバ１０に送信する。なお、返信ボタン５１３が押下された場合、メール作成要求には、受信メール一覧領域５１１において選択されているメールのメッセージＩＤが指定される。
【００５２】
メールサーバ１０の要求受信部１２１が、メール作成要求を受信すると（Ｓ１０８でＹｅｓ）、メール作成画面生成部１１３は、メール作成画面を表示させる画面データを生成する（Ｓ１０９）。続いて、応答返信部１２２は、当該画面データを含む応答を、クライアント端末２０に返信する（Ｓ１１０）。当該応答を受信したクライアント端末２０のブラウザ部２１は、当該応答に含まれている画面データに基づいて、メール作成画面を表示させる。
【００５３】
図１０は、メール作成画面の表示例を示す図である。図１０において、メール作成画面５２０は、宛先入力領域５２１、ＣＣ入力領域５２２、件名入力領域５２３、本文入力領域５２４、送信ボタン５２５、及びログアウトボタン５２６等を含む。
【００５４】
宛先入力領域５２１及びＣＣ入力領域５２２は、宛先のメールアドレス又はＣＣ（カーボンコピー）宛のメールアドレスの入力領域である。件名入力領域５２３は、メールの件名の入力領域である。本文入力領域５２４は、メールの本文の入力領域である。
【００５５】
送信ボタン５２５は、メールの送信指示を受け付けるためのボタンである。ログアウトボタン５２６は、ログアウト指示を受け付けるためのボタンである。
【００５６】
なお、メール作成要求にメッセージＩＤが指定されている場合、すなわち、受信メール一覧画面５１０において、返信ボタン５１３が押下された場合、メール作成画面生成部１１３は、宛先入力領域５２１及び本文入力領域５２４に予め返信元のメールに関する値が設定されたメール作成画面５２０を生成する。すなわち、宛先入力領域５２１には、当該メッセージＩＤに対応付けてメール記憶部１３２の「送信元アドレス」に記憶されているメールアドレスが設定される。本文入力領域５２４には、当該メッセージＩＤに対応付けてメール記憶部１３２の「本文」に記憶されている文字列（メッセージ）が引用される。
【００５７】
ここでは、承認依頼者であるユーザｔａｎａｋａが利用するクライアント端末２０ｂに、メール作成画面５２０が表示されていることとする。メール作成画面５２０において必要事項が入力され、送信ボタン５２５が押下されると、クライアント端末２０ｂのブラウザ部２１は、メールの送信要求をメールサーバ１０に送信する。メールの送信要求には、メール作成画面５２０に入力された、宛先アドレス、ＣＣアドレス、件名、及び本文の文字列（メッセージ）と、本文入力領域５２４の表示形式情報とが指定される。本文入力領域５２４の表示形式情報とは、本文入力領域５２４の属性情報又は設定情報を構成する情報であり、本文入力領域５２４に表示される文字列の表示形式又は表示態様を示す情報である。本実施の形態において、表示形式情報には、例えば、フォント名、フォントサイズ、１行の文字数、及び行間隔等が含まれる。１行の文字数は、本文入力領域５２４の横幅のサイズと、フォントサイズとに基づいて算出されてもよい。また、表示色等、他の情報が、表示形式情報に含まれてもよい。
【００５８】
なお、メール送信要求に指定される本文入力領域５２４の表示形式情報は、ステップＳ１０９においてメール作成画面５４０の画像データが生成された際に本文入力領域５２４に設定された通りであるとは限らない。例えば、ユーザによって、メール作成画面５２０のサイズが変更されたり、フォントサイズの拡大等が行われたりした場合、本文入力領域５２４の表示形式情報は、当初の値と異なったものとなる。メール送信要求には、送信ボタン５２５が押下された時点における、本文入力領域５２４の表示形式情報が指定される。
【００５９】
メールサーバ１０の要求受信部１２１が、メール送信要求を受信すると（Ｓ１１１でＹｅｓ）、メッセージ承認依頼部１１８は、メール送信要求に係るログインユーザＩＤ（送信者のユーザＩＤ）に対応付けられてユーザ情報記憶部１３１（図６）に記憶されている承認者アドレスを取得する（Ｓ１１２）。続いて、承認依頼部１１８は、承認依頼情報記憶部１３３（図９）に対して、当該承認者アドレス（すなわち、承認者のユーザＩＤ）に対応するレコードを生成する（Ｓ１１３）。当該レコードの「承認依頼ＩＤ」には、自動的に割り当てられた値が記憶される。「メッセージＩＤ」には、メール送信要求の受信に応じて自動的に割り当てられる値が記憶される。「状態」には「承認依頼中」が記憶される。「依頼者ＩＤ」には、メール送信要求に係るログインユーザＩＤ（送信者のユーザＩＤ）が記憶される。「宛先アドレス」には、メール送信要求に指定されている宛先アドレスが記憶される。「承認依頼日時」には、現在日時が記憶される。「メール情報」の「件名」及び「本文」には、メッセージ要求に指定されている件名及び本文の文字列が記憶される。
【００６０】
なお、ここでは、図９における１行目のレコードが新たに記憶されたこととする。すなわち、ユーザｔａｎａｋａからユーザｙａｍａｄａに対して、承認依頼が行われたこととする。
【００６１】
続いて、承認依頼部１１８は、メール送信要求に指定されていた表示形式情報を、送信対象のメールに対して割り当てられたメッセージＩＤに対応付けて、表示形式記憶部１３４に記憶する（Ｓ１１４）。
【００６２】
図１１は、表示形式記憶部の構成例を示す図である。図１１に示されるように、表示形式記憶部１３４は、メッセージＩＤに対応付けて、フォント名、フォントサイズ、１行の文字数、及び行間隔等を含む表示形式情報を記憶する。なお、ここでは、２行目のレコードが新たに記憶されたこととする。
【００６３】
一方、承認者であるユーザｙａｍａｄａが利用するクライアント端末２０ａに、図８に示される受信メール一覧画面５１０ａが表示されている状態において、承認処理ボタン５１５が押下されると、クライアント端末２０ａのブラウザ部２１は、承認依頼一覧表示要求をメールサーバ１０に送信する。
【００６４】
メールサーバ１０の要求受信部１２１が、承認依頼一覧表示要求を受信すると（Ｓ１１５でＹｅｓ）、承認依頼一覧画面生成部１１４は、当該要求に係るログインユーザＩＤに対応するレコードであって、「状態」の値が「承認依頼中」であるレコードを承認依頼情報記憶部１３３より抽出する（Ｓ１１６）。ここでは、図９に示される、ユーザｙａｍａｄａに対応するレコードの中から、「状態」の値が「承認依頼中」であるレコードが抽出される。
【００６５】
続いて、承認依頼一覧画面生成部１１４は、抽出されたレコードに基づいて、承認依頼一覧画面を表示させる画面データ生成する（Ｓ１１７）。続いて、応答返信部１２２は、当該画面データを含む応答を、クライアント端末２０ａに返信する（Ｓ１１８）。当該応答を受信したクライアント端末２０ａのブラウザ部２１は、当該応答に含まれている画面データに基づいて、承認依頼一覧画面を表示させる。
【００６６】
図１２は、承認依頼一覧画面の表示例を示す図である。図１２に示されるように、承認依頼一覧画面５３０には、承認依頼の一覧が表示される。図１２では、承認依頼ごとに、依頼者ＩＤ、承認依頼日時、及び件名が表示される例が示されている。これらの値は、承認依頼情報記憶部１３３より取得可能である。
【００６７】
承認者によって、承認依頼一覧画面５３０内のいずれかの承認依頼が選択されると、クライアント端末２０ａのブラウザ部２１は、選択された承認依頼に対応する承認依頼ＩＤを指定して、承認処理要求をメールサーバ１０に送信する。ここでは、図１２において、１行目の承認依頼（ユーザｔａｎａｋａからの承認依頼）に対する承認処理要求が送信されたこととする。
【００６８】
メールサーバ１０の要求受信部１２１が、承認処理要求を受信すると（Ｓ１１９でＹｅｓ）、承認画面生成部１１５は、承認処理要求に指定されている承認依頼ＩＤを含むレコードを、承認依頼情報記憶部１３３より取得する（Ｓ１２０）。ここでは、図９の１行目のレコードが取得される。取得されたレコードを、以下、「対象承認依頼レコード」という。続いて、承認画面生成部１１５は、対象承認依頼レコードの「メッセージＩＤ」に記憶されているメッセージＩＤに対応する表示形式情報を、表示形式情報記憶部（図１１）より取得する（Ｓ１２１）。続いて、承認画面生成部１１５は、対象承認依頼レコードと、取得された表示形式情報とに基づいて、承認画面を表示させる画面データを生成する（Ｓ１２２）。続いて、応答返信部１２２は、当該画面データを含む応答を返信する（Ｓ１２３）。当該応答を受信したクライアント端末２０ａのブラウザ部２１は、当該応答に含まれている画面データに基づいて、承認画面を表示させる。
【００６９】
図１３は、承認画面の表示例を示す図である。図１３に示されるように、承認画面５４０は、確認領域５４１、送信ボタン５４６、差し戻しボタン５４７、手書きチェックボタン５４８、及びログアウトボタン５４９等を含む。
【００７０】
確認領域５４１は、承認依頼対象のメールの内容を確認させるための領域であり、宛先表示領域５４２、ＣＣ表示領域５４３、件名表示領域５４４、及び本文表示領域５４５等を含む。宛先表示領域５４２、ＣＣ表示領域５４３、件名表示領域５４４、及び本文表示領域５４５には、順番に、対象承認依頼レコードの、「宛先アドレス」、「ＣＣアドレス」、「件名」、又は「本文」に記憶されている文字列が表示される。
【００７１】
送信ボタン５４６は、承認依頼対象のメールの送信指示を受け付けるためのボタンである。差し戻しボタン５４７は、承認依頼対象のメールの差し戻し指示を受け付けるためのボタンである。手書きチェックボタン５４８は、手書きチェック指示を受け付けるためのボタンである。ログアウトボタン５４９は、ログアウト指示を受け付けるためのボタンである。
【００７２】
なお、本文表示領域５４５における文字列の表示形式は、ステップＳ１２１において取得された表示形式情報に基づく。すなわち、承認画面生成部１１５は、当該表示形式情報に基づいて、承認画面５４０に係る画面データにおいて本文表示領域５４５に対する属性情報を設定する。例えば、当該画面データにおいて、本文表示領域５４５に対する属性情報は、図１４に示されるように設定される。
【００７３】
図１４は、承認画面の本文表示領域に対する属性情報の設定例を示す図である。図１４において、＜ｆｏｎｔ＞タグ５１のｓｉｚｅ属性及びｆａｃｅ属性のそれぞれの値には、フォントサイズ又はフォント名が指定されている。また、＜ＤＩＶ＞タグ５２のｓｔｙｌｅ属性の値には、行間隔が指定されている。更に、＜ｔｅｘｔａｒｅａ＞タグ５３のｃｏｌｓ属性の値には、１行の文字数が指定されている。
【００７４】
これらのタグの間に、本文の文字列が記述されている。したがって、本文の文字列の表示形式は、各タグの各属性の値に設定された通りとなる。これらの属性の値は、ステップＳ１２１において取得された表示形式情報に基づく。
【００７５】
例えば、確認領域５４１を閲覧した承認者が、本文や、宛先、ＣＣ等について問題無いと判断した場合（すなわち、承認できる場合）、承認者は、送信ボタン５４６を押下する。この場合、クライアント端末２０ａのブラウザ部２１は、承認要求をメールサーバ１０に送信する。承認要求には、閲覧対象とされている承認依頼に係る承認依頼ＩＤが指定される。
【００７６】
一方、確認領域５４１を閲覧した承認者が、本文に対して修正指示を手書き入力によって書き込みたい場合、承認者は、手書きチェックボタン５４８を押下する。この場合、クライアント端末２０ａのブラウザ部２１は、手書きチェック要求をメールサーバ１０に送信する。手書きチェック要求には、閲覧対象とされている承認依頼に係る承認依頼ＩＤが指定される。
【００７７】
メールサーバ１０の要求受信部１２１が、手書きチェック要求を受信すると（Ｓ１２４でＹｅｓ）、承認画面生成部１１５は、本文表示領域５４５に対して手書き入力が可能な承認画面５４０ａを表示させる画面データを生成する（Ｓ１２５）。すなわち、本文表示領域５４５に対するポインティングデバイスの軌跡を描画要素として含む画像データを生成する機能が組み込まれた画面データが生成される。なお、承認画面５４０ａの生成に用いられる情報は、ステップＳ１２２において生成される承認画面５４０と同じでよい。続いて、応答返信部１２２は、生成された画面データを返信する（Ｓ１２６）。
【００７８】
図１５は、手書き入力が可能な承認画面の表示例を示す図である。図１５中、図１３と同一部分には同一符号を付し、その説明は省略する。
【００７９】
図１５に示される承認画面５４０ａは、手書き入力領域５５０を有する。すなわち、手書き入力領域５５０内におけるポインティングデバイスによる入力は、クライアント端末２０ａのブラウザ部２１によって、描画要素としてクライアント端末２０ａのメモリに記憶される。図１５では、手書き入力によって既に書き込みが行われた状態が示されている。なお、本文表示領域５４５の属性情報は、図１３及び図１４において説明した通り、当該承認依頼の対象のメッセージＩＤに対応付けられて表示形式記憶部１３４に記憶されている表示形式情報に従う。したがって、本文表示領域５４５には、クライアント端末２０ｂにおいてメール作成画面５２０（図１０）の本文入力領域５２４に本文の文字列が入力された際の当該文字列の表示形式と同じ表示形式で、本文の文字列が表示されている。
【００８０】
この状態において、承認者によって差し戻しボタン５４７が押下されると、クライアント端末２０ａのブラウザ部２１は、手書き入力領域５５０に対する描画要素が記録された画像データと、承認依頼ＩＤとが指定された差し戻し要求をメールサーバ１０に送信する。当該画像データが、本実施の形態においてチェックシートと呼ばれる画像データである。なお、チェックシートは、背景が透明色の画像データである。また、チェックシートのサイズは、例えば、手書き入力領域５５０と同じでもよいし、本文表示領域５４５と同じでもよい。
【００８１】
メールサーバ１０の要求受信部１２１が、承認結果を受信すると（Ｓ１２７でＹｅｓ）、承認処理部１１９は、承認依頼情報記憶部１３３において、承認結果に指定されている承認依頼ＩＤに対応するレコードの「状態」に対して、「差し戻し」又は「承認済み」を記憶する（Ｓ１２８）。承認結果とは、図１３の承認画面５４０の送信ボタン５４６の押下に応じて送信される承認要求、又は図１５の承認画面５４０ａの差し戻しボタン５４７の押下に応じて送信される差し戻し要求をいう。なお、差し戻し要求の場合であって、チェックシートが指定されている場合、承認処理部１１９は、チェックシートを格納したファイルを、例えば、補助記憶装置１０２に記憶する。また、承認処理部１１９は、そのファイル名を、承認依頼情報記憶部１３３において、差し戻し要求に指定されている承認依頼ＩＤに対応するレコードの「チェックシート名」に記憶する。
【００８２】
承認された場合、すなわち、承認要求が受信された場合（Ｓ１２９でＹｅｓ）、メール送信部１２０は、承認要求に指定されている承認依頼ＩＤに対応付けて承認依頼情報記憶部１３３に記憶されているメッセージＩＤに対応するメールを、当該メールの宛先アドレスに送信する（Ｓ１３０）。当該メールの宛先アドレスが、メールシステム１内のメールアドレスである場合、メールの送信は、メール記憶部１３２（図７）に、宛先アドレスをユーザＩＤとするレコードとして、新たに記憶することによって実現される。すなわち、当該レコードの「区分」には、「受信」が記憶される。当該レコードの「メッセージＩＤ」には、当該メールのメッセージＩＤが記憶される。当該レコードの「送信元アドレス」には、当該メールの送信元アドレスが記憶される。当該レコードの「宛先アドレス」には、当該メールの宛先アドレスが記憶される。当該レコードの「日時」には、現在日時が記憶される。当該レコードの「件名」及び「本文」には、当該メールの件名又は本文が記憶される。一方、送信者アドレスをユーザＩＤとするレコードとして、当該レコードの「区分」が送信となり、同様の情報もメール記憶部１３２に記憶される。
【００８３】
一方、承認依頼者であるユーザｔａｎａｋａが利用するクライアント端末２０ｂに、図８に示される受信メール一覧画面５１０ｂが表示されている状態において、承認結果一覧ボタン５１４が押下されると、クライアント端末２０ｂのブラウザ部２１は、承認結果一覧の表示要求をメールサーバ１０に送信する。
【００８４】
メールサーバ１０の要求受信部１２１が、承認結果一覧の表示要求を受信すると（Ｓ１３１でＹｅｓ）、承認結果一覧画面生成部１１６は、承認結果一覧の表示要求に係るログインユーザＩＤに対応付けられてユーザ情報記憶部１３１（図６）に記憶されている承認者アドレスを取得する（Ｓ１３２）。続いて、承認結果一覧画面生成部１１６は、承認者アドレスに対応する承認依頼情報記憶部１３３のレコード（図９）の中から、「依頼者ＩＤ」の値が、承認結果一覧の表示要求に係るログインユーザＩＤであるレコードを抽出する（Ｓ１３３）。続いて、承認結果一覧画面生成部１１６は、抽出されたレコードに基づいて、承認結果一覧画面を表示させる画面データを生成する（Ｓ１３４）。続いて、応答返信部１２２は、当該画面データを含む応答を、クライアント端末２０ｂに返信する（Ｓ１３５）。当該応答を受信したクライアント端末２０ｂのブラウザ部２１は、当該応答に含まれている画面データに基づいて、承認結果一覧画面を表示させる。
【００８５】
図１６は、承認結果一覧画面の表示例を示す図である。図１６に示されるように、承認結果一覧画面５６０は、承認依頼一覧領域５６１、修正ボタン５６２、及びログアウトボタン５６３等を含む。
【００８６】
承認依頼一覧領域５６１には、承認依頼の一覧が表示される。図１６では、承認依頼ごとに、承認依頼日時、件名、及び状態が表示される例が示されている。これらの値は、承認依頼情報記憶部１３３より取得可能である。修正ボタン５６２は、承認依頼一覧領域５６１において選択された承認依頼の対象のメールの修正指示を受け付けるためのボタンである。ログアウトボタン５６３は、ログアウト指示を受け付けるためのボタンである。
【００８７】
例えば、承認依頼一覧領域５６１において、「状態」の値が「差し戻し」である承認依頼が選択され、修正ボタン５６２が押下されると、クライアント端末２０ｂのブラウザ部２１は、修正要求をメールサーバ１０に送信する。修正要求には、選択された承認依頼に対応する承認依頼ＩＤが指定される。
【００８８】
メールサーバ１０の要求受信部１２１が、修正要求を受信すると（Ｓ１３６でＹｅｓ）、修正画面生成部１１７は、修正要求に指定されている承認依頼ＩＤを含むレコードを、承認依頼情報記憶部１３３より取得する（Ｓ１３７）。ここでは、図９の１行目のレコードが取得される。但し、この時点において、当該レコードの「状態」の値は、「差し戻し」に更新されている。取得されたレコードを、以下、「対象承認依頼レコード」という。続いて、修正画面生成部１１７は、対象承認依頼レコードの「メッセージＩＤ」に記憶されているメッセージＩＤに対応する表示形式情報を、表示形式情報記憶部（図１１）より取得する（Ｓ１３８）。ちなみに、図５では、便宜上、Ｓ１３６が待機ループをするように記載しているが、図１６にてログアウトボタンを押下すると、図４、図５の処理が終了することになる。
続いて、修正画面生成部１１７は、対象承認依頼レコードと、取得された表示形式情報とに基づいて、修正画面を表示させる画面データを生成する（Ｓ１３９）。続いて、修正画面生成部１１７は、対象承認依頼レコードの「チェックシート名」に記憶されているファイル名に係るファイルよりチェックシートを取得し、当該チェックシートを、修正画面の所定の位置に重畳させる（Ｓ１４０）。すなわち、修正画面の所定の位置にチェックシートが重畳されるようにするための定義情報が、ステップＳ１３９において生成された画面データに追加される。続いて、応答返信部１２２は、当該画面データを含む応答を返信する（Ｓ１４１）。当該応答を受信したクライアント端末２０ｂのブラウザ部２１は、当該応答に含まれている画面データに基づいて、修正画面を表示させる。
【００８９】
図１７は、修正画面の表示例を示す図である。図１７において、修正画面５７０は、宛先修正領域５７１、ＣＣ修正領域５７２、件名修正領域５７３、本文修正領域５７４、チェック結果表示領域５７５、送信ボタン５７６、及びログアウトボタン５７７等を含む。
【００９０】
宛先修正領域５７１、ＣＣ修正領域５７２、件名修正領域５７３、及び本文修正領域５７４には、対象承認依頼レコードにおける、「宛先アドレス」、「ＣＣアドレス」、「件名」、又は「本文」に記憶されている文字列が表示される。宛先修正領域５７１、ＣＣ修正領域５７２、及び本文修正領域５７４は、入力可能であり、承認依頼者は、宛先アドレス、ＣＣアドレス、又は本文を、チェック結果表示領域５７５の表示内容を参考にして、修正することができる。
【００９１】
チェック結果表示領域５７５は、承認者によるチェック結果が表示される領域である。具体的には、チェック結果表示領域５７５には、チェック対象本文表示領域５７５ａ及びチェックシート５７５ｂ等が含まれる。チェック対象本文表示領域５７５ａにおける文字列の表示形式は、ステップＳ１３８において取得された表示形式情報に基づく。すなわち、修正画面生成部１１７は、当該表示形式情報に基づいて、修正画面５７０に係る画面データにおいて、チェック対象本文表示領域５７５ａに対する属性情報を設定する。例えば、当該画面データにおいて、チェック対象本文表示領域５７５ａに対する属性情報は、図１４に示したように設定される。
【００９２】
したがって、チェック対象本文表示領域５７５ａにおける文字列の表示形式は、図１３又は図１５における本文表示領域５４５と同一となる。すなわち、チェック対象本文表示領域５７５ａと本文表示領域５４５とにおいて、文字列のフォント、フォントサイズ、行間隔、及び１行の文字数等は、同じとなる。したがって、チェック対象本文表示領域５７５ａと本文表示領域５４５とにおいて、本文の文字列のレイアウトは同一となる。また、チェック対象本文表示領域５７５ａ及び本文表示領域５４５に対するチェックシートの相対的な位置関係は、同じとされる。したがって、図１７に示されるように、チェック対象本文表示領域５７５ａに表示される文字列と、チェックシート５７５ｂにおける描画要素との相対的な位置関係は、図１５における本文表示領域５４５と、チェックシートとの相対的な位置関係と同じとなる。すなわち、クライアント端末２０ａとクライアント端末２０ｂとが異なる機種の端末であったとしても、修正画面５７０のチェック結果表示領域５７５には、承認画面５４０において承認者によって手書き入力された状態が再現される。
【００９３】
修正画面５７０において、宛先アドレス、ＣＣアドレス、件名、又は本文が修正され、送信ボタン５７６が押下されると、ブラウザ部２１は、メールの送信要求をメールサーバ１０に送信する。メールの送信要求には、修正画面５７０に入力された、宛先アドレス、ＣＣアドレス、件名、及び本文の文字列（メッセージ）と、本文修正領域５７４の表示形式情報とが指定される。当該メール送信要求を受信したメールサーバ１０は、図４のステップＳ１１２〜Ｓ１１４を実行する。したがって、改めて承認依頼（再承認依頼）が承認依頼情報記憶部１３３に記憶される。
【００９４】
その後、再承認依頼に関して、ステップＳ１１９〜Ｓ１２３が実行される場合、生成される承認画面５４０は、例えば、図１３に示した通りでもよいし、図１８に示される通りでもよい。
【００９５】
図１８は、再承認依頼時の承認画面の表示例を示す図である。図１８中、図１３と同一部分には同一符号を付し、その説明は省略する。
【００９６】
図１８に示される承認画面５４０ａの確認領域５４１ａは、前回チェック結果表示領域５５１を更に含む。前回チェック結果表示領域５５１では、前回の承認依頼においてチェック対象とされた本文に対して、当該本文に対するチェック結果を示すチェックシートが重畳されて表示される。再承認依頼時の承認画面５４０ａにおいて、前回チェック結果表示領域５５１が表示されることで、承認者は、本文表示領域５４５に表示される本文に関して、前回のチェック結果に対する修正が適切に行われているか否か等を容易に確認することができる。
【００９７】
なお、メールサーバ１０においてログアウト要求が受信された場合（Ｓ１４２でＹｅｓ）、ログアウト要求に係るセッションは終了する。
【００９８】
上述したように、本実施の形態によれば、修正画面５７０において、チェック対象本文表示領域５７５ａにおける文字列の表示形式は、承認画面５４０（図１５）の本文表示領域５４５において手書き入力が行われた際の文字列の表示形式と同じとされる。したがって、承認者が手書き入力した情報が記録された手書きチャックシート５７５ｂが、修正画面５７０のチェック対象本文表示領域５７５ａに重畳される際に、両者の間にずれが発生する可能性を低減させることができる。
【００９９】
特に、近年では、ＰＣ（Personal Computer）のみならず、携帯電話、スマートフォン、又はタブレット端末等、多種多様な端末でメールを閲覧できるようになっている。したがって、承認依頼者がＰＣで作成したメールを、承認者がタブレット型端末でチェックし、承認依頼者が再びＰＣでチェック結果を確認するといった状況が多くなることが予測される。本実施の形態によれば、このように、承認依頼者と承認者との間で異なる種類の端末が利用される状況であっても、メール本文の文字列とチェックシート内の描画要素との間にずれが発生する可能性を低減させることができる。なお、チェック結果を表示する領域全体を縮小し、その割合にて、手書きチェックシートを同様に縮小させて小型端末に表示させることも可能である。また、拡大も同様に可能である。
【０１００】
なお、本実施の形態では、ステップＳ１１１において受信されるメールの送信要求に、メール作成画面５２０の本文入力領域５２４の表示形式情報が指定される例を説明した。すなわち、当該表示形式情報が、承認画面５４０（図１５）の本文表示領域５４５及び修正画面５７０のチェック対象本文表示領域５７５ａに設定される例を説明した。
【０１０１】
但し、チェック対象本文表示領域５７５ａ内の文字列と、チェックシート５７５ｂとのずれの発生を抑制するには、少なくとも、修正画面５７０のチェック対象本文表示領域５７５ａの表示形式と、承認画面５４０の本文表示領域５４５の表示形式とが一致していればよい。
【０１０２】
したがって、例えば、Ｓ１２６において受信される承認結果に、承認画面５４０の本文表示領域５４５の表示形式情報が指定され、当該表示形式情報が、承認依頼対象のメールＩＤに対応付けられて表示形式記憶部１３４に記憶されてもよい。修正画面５７０の生成時におけるステップＳ１３８では、当該表示形式情報に基づいて、修正画面５７０の画面データが生成されてもよい。この場合、ステップＳ１１１において受信されるメールの送信要求には、表示形式情報は指定されなくてもよい。
【０１０３】
このような形態によれば、例えば、承認画面５４０の画面サイズの変更等が行われた後に、手書き入力が行われた場合であっても、画面サイズの変更後に対応した表示形式情報に基づいて、修正画面５７０の画面データが生成される。したがって、承認画面５４０の画面サイズの変更等が行われた後に、手書き入力が行われた場合であっても、修正画面５７０において、チェック対象本文表示領域５７５ａ内の文字列と、チェックシート５７５ｂとのずれの発生を抑制することができる。
【０１０４】
一方、本実施の形態のように、メールの送信要求に、メール作成画面５２０の本文入力領域５２４の表示形式情報が指定される場合、修正画面５７０のチェック対象本文表示領域５７５ａには、承認依頼者が当初入力した表示形式で本文が表示される。したがって、承認依頼者に対して、修正画面５７０のチェック対象本文表示領域５７５ａに表示される本文の表示形式について違和感を与える可能性を低減させることができる。
【０１０５】
なお、本実施の形態において説明した内容は、一方が、他方の入力した文字列に対して手書き入力を行い、当該手書き入力結果を当該他方に表示可能なコミュニケーション手段であれば、電子メール以外のコミュニケーション手段に適用されてもよい。
【０１０６】
なお、本実施の形態において、メールサーバ１０は、画面生成装置の一例である。承認画面生成部１１５は、生成部の一例である。応答返信部１２２は、第一の送信部及び第二の送信部の一例である。要求受信部１２１は、受信部の一例である。
【０１０７】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【０１０８】
以上の説明に関し、更に以下の項を開示する。
（付記１）
所定の文字列を含み、該文字列に対する手書き入力が可能な画面を表示させる第一の画面データを生成し、
前記第一の画面データを第一の端末に送信し、
前記所定の文字列に対する手書き入力情報を、前記第一の端末より受信し、
前記第一の画面データと同じ表示形式の前記所定の文字列と、前記手書き入力情報とを第二の端末に送信する処理をコンピュータに実行させる画面生成プログラム。
（付記２）
前記所定の文字列を前記第一の画面データと同じ表示形式で含み、前記手書き入力情報が前記所定の文字列に重畳された画面を表示させる第二の画面データを生成する処理を前記コンピュータに実行させ、
前記第二の端末に送信する処理は、前記第二の画面データを第二の端末に送信する付記１記載の画面生成プログラム。
（付記３）
前記所定の文字列と、前記第二の端末における前記所定の文字列の表示形式を示す表示形式情報とを前記第二の端末より受信する処理を前記コンピュータに実行させ、
前記第一の画面データを生成する処理は、前記第二の端末より受信された前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第一の画面データを生成し、
前記第二の画面データを生成する処理は、前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第二の画面データを生成する付記２記載の画面生成プログラム。
（付記４）
前記第一の端末より受信する処理は、前記手書き入力情報と、前記第一の端末における前記所定の文字列の表示形式を示す表示形式情報とを前記第一の端末より受信し、
前記第二の画面データを生成する処理は、前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第二の画面データを生成する付記２記載の画面生成プログラム。
（付記５）
所定の文字列を含み、該文字列に対する手書き入力が可能な画面を表示させる第一の画面データを生成し、
前記第一の画面データを第一の端末に送信し、
前記所定の文字列に対する手書き入力情報を、前記第一の端末より受信し、
前記第一の画面データと同じ表示形式の前記所定の文字列と、前記手書き入力情報とを第二の端末に送信する処理をコンピュータが実行する画面生成方法。
（付記６）
前記所定の文字列を前記第一の画面データと同じ表示形式で含み、前記手書き入力情報が前記所定の文字列に重畳された画面を表示させる第二の画面データを生成する処理を前記コンピュータが実行し、
前記第二の端末に送信する処理は、前記第二の画面データを第二の端末に送信する付記５記載の画面生成方法。
（付記７）
前記所定の文字列と、前記第二の端末における前記所定の文字列の表示形式を示す表示形式情報とを前記第二の端末より受信する処理を前記コンピュータが実行し、
前記第一の画面データを生成する処理は、前記第二の端末より受信された前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第一の画面データを生成し、
前記第二の画面データを生成する処理は、前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第二の画面データを生成する付記６記載の画面生成方法。
（付記８）
前記第一の端末より受信する処理は、前記手書き入力情報と、前記第一の端末における前記所定の文字列の表示形式を示す表示形式情報とを前記第一の端末より受信し、
前記第二の画面データを生成する処理は、前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第二の画面データを生成する付記６記載の画面生成方法。
（付記９）
所定の文字列を含み、該文字列に対する手書き入力が可能な画面を表示させる第一の画面データを生成する生成部と、
前記第一の画面データを第一の端末に送信する第一の送信部と、
前記所定の文字列に対する手書き入力情報を、前記第一の端末より受信する受信部と、
前記第一の画面データと同じ表示形式の前記所定の文字列と、前記手書き入力情報とを第二の端末に送信する第二の送信部とを有する画面生成装置。
（付記１０）
前記所定の文字列を前記第一の画面データと同じ表示形式で含み、前記手書き入力情報が前記所定の文字列に重畳された画面を表示させる第二の画面データを生成する第二の生成部を有し、
前記第二の送信部は、前記第二の画面データを第二の端末に送信する付記９記載の画面生成装置。
（付記１１）
前記所定の文字列と、前記第二の端末における前記所定の文字列の表示形式を示す表示形式情報とを前記第二の端末より受信する第二の受信部を有し、
前記生成部は、前記第二の端末より受信された前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第一の画面データを生成し、
前記第二の生成部は、前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第二の画面データを生成する付記１０記載の画面生成装置。
（付記１２）
前記受信部は、前記手書き入力情報と、前記第一の端末における前記所定の文字列の表示形式を示す表示形式情報とを前記第一の端末より受信し、
前記第二の生成部は、前記所定の文字列を前記表示形式情報が示す表示形式で含む画面を表示させる前記第二の画面データを生成する付記１０記載の画面生成装置。
【符号の説明】
【０１０９】
１            メールシステム
１０          メールサーバ
２０ａ、２０ｂ    クライアント端末
２１          ブラウザ部
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１１１        認証部
１１２        受信メール一覧画面生成部
１１３        メール作成画面生成部
１１４        承認依頼一覧画面生成部
１１５        承認画面生成部
１１６        承認結果一覧画面生成部
１１７        修正画面生成部
１１８        承認依頼部
１１９        承認処理部
１２０        メール送信部
１２１        要求受信部
１２２        応答返信部
１３１        ユーザ情報記憶部
１３２        メール記憶部
１３３        承認依頼情報記憶部
１３４        表示形式記憶部
Ｂ            バス
【図１】
2014048709.tif 000003
【図２】
2014048709.tif 000004
【図３】
2014048709.tif 000005
【図４】
2014048709.tif 000006
【図５】
2014048709.tif 000007
【図６】
2014048709.tif 000008
【図７】
2014048709.tif 000009
【図８】
2014048709.tif 000010
【図９】
2014048709.tif 000011
【図１０】
2014048709.tif 000012
【図１１】
2014048709.tif 000013
【図１２】
2014048709.tif 000014
【図１３】
2014048709.tif 000015
【図１４】
2014048709.tif 000016
【図１５】
2014048709.tif 000017
【図１６】
2014048709.tif 000018
【図１７】
2014048709.tif 000019
【図１８】
2014048709.tif 000020