JP2016054442A - 通信端末装置、通信システム、通信方法、及びプログラム - Google Patents

Abstract

【課題】通信端末装置が接続されたネットワーク状況に応じて、次回の送信までの再送信待ち時間を調整する。【解決手段】通信ネットワーク２を介してログファイルをログアップロードサーバ５０へ送信する送信ステップ（ｓｔ１２０）と、ログアップロードサーバ５０へのログファイルのある送信が失敗した場合に、当該送信から次回の送信までのリトライ時間（再送信待ち時間）を算出する再送信待ち時間算出ステップ（ｓｔ１１０）と、リトライ時間が経過した場合に、送信ステップによりログアップロードサーバ５０へログファイルを再送信させる制御ステップ（ｓｔ１２０）と、を備え、再送信待ち時間算出ステップは、前回のリトライ時間よりも次回のリトライ時間を長く算出する。【選択図】図１８

Description

本発明は、通信ネットワークを介してサーバに通信情報を再送信するのに好適な通信端末装置、通信システム、通信方法、及びプログラムに関する。

テレビ会議システムにおけるログデータは、障害発生時の原因究明のために必要である。特に通信端末では、ログファイルをサーバに送信する機能があるため、ユーザからサポートセンタに障害の問い合わせがあった場合などにおいて、ユーザがサーバへのログデータのアップロードを依頼し、それを解析するケースがある。
こうしたログアップロードは、通常、通信ネットワーク経由で行われるため、ネットワークが何らかの理由で切断されている場合、ログアップロードを実施することができないといった問題があった。
こうした場合において、ログアップロードが失敗した後に再アップロードを行う技術として、特許文献１が報告されている。
特許文献１には、ホストコンピュータ間でのファイル転送において、ファイル転送失敗時にオペレータの再送操作を省略する目的で、ファイル転送が失敗した際に、実際のファイルの転送を司るファイル転送機能手段からの転送結果コードを解析し、該転送結果コードがリトライ対象と一致した場合には、転送が失敗したファイルを再度転送するように制御することを特徴とするファイル転送制御システムが開示されている。

しかし、一定時間ごとに再送信するように構成された従来の技術では、端末が接続された通信ネットワーク環境にかかわらず一定時間後に再送信するため、一定時間ごとの再送信しかできなかった。このため、通信ネットワーク環境に合わせた適切なアップロード間隔に調整することができないといった問題があった。
特許文献１にあっては、ファイル転送をリトライする技術が記載されている。しかし、端末が接続された通信ネットワーク状況に応じて、次回のファイル転送までの待ち時間を調整できなかった。
本発明は、上記に鑑みてなされたもので、その目的としては、通信端末装置が接続されたネットワーク状況に応じて、次回の送信までの再送信待ち時間を調整することができる通信端末装置、通信システム、通信方法、及びプログラムを提供することにある。

請求項１記載の発明は、上記課題を解決するため、ネットワークを介してサーバに接続する通信端末装置であって、前記ネットワークを介して通信情報をサーバへ送信する送信手段と、
前記サーバへの前記通信情報のある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間を算出する再送信待ち時間算出手段と、前記再送信待ち時間が経過した場合に、前記送信手段により前記サーバへ前記通信情報を再送信させる制御手段と、を備え、前記再送信待ち時間算出手段は、前回の再送信待ち時間よりも次回の再送信待ち時間を長く算出することを特徴とする。

本発明によれば、ネットワークを介してサーバへの通信情報のある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間を算出し、再送信待ち時間が経過した場合に、サーバへ通信情報を再送信させる際に、前回の再送信待ち時間よりも次回の再送信待ち時間を長く算出することで、通信端末装置が接続されたネットワーク状況に応じて、次回の送信までの再送信待ち時間を調整することができる。

本発明の一実施形態に係る通信システムの概略図である。 本発明の一実施形態に係る通信端末のハードウェア構成図である。 本発明の一実施形態に係るログアップロードサーバのハードウェア構成図である。 本実施形態の通信システムを構成する各端末、装置及びシステムの機能ブロック図である。 ログ情報作成部により作成されたログ情報の一例を示す図である。 メッセージ作成部により作成された送信データの一例を示す図である。 ログ管理テーブルに関連付けられて管理されたログＩＤとログ情報を示す図である。 ログ情報およびログアップロード機能について説明するための模式図である。 通常時のログアップロードが成功した時のシーケンス図である。 ネットワーク切断時にリトライが無い場合のシーケンス図である。 ネットワーク切断時にリトライが有る場合のシーケンス図である。 ネットワーク切断時にリトライがあり、且つタイムアウトした場合のシーケンス図である。 アップロード処理時に設定されるリトライ（一定時間）の時間間隔について説明するための模式図である。 アップロード処理におけるリトライ時間（重み付け有り）の時間間隔について説明するための模式図である。 ログ再送制御部のシーケンス動作を説明するためのシーケンス図である。 ログ再送制御部が実行する重み値の算出方法について説明するための模式図である。 ログ再送制御部が実行する重み値の算出方法について説明するためのフローチャートである。 ログ再送制御部が実行するリトライ処理のサブルーチンを示すフローチャートである。

本発明の実施の形態を説明する。
本発明は、ログアップロードのリトライ時間（再送信待ち時間）の算出に際して、以下の特徴を有する。要するに、サーバへのログアップロードの再送信に失敗した回数を算出して、次回の再送信までの再送信待ち時間を算出する式に適応する重み値を調整することで、例えば通信ネットワークの接続回復が早い環境ではより早くアップロードを完了し、接続回復が遅い環境では無駄なリクエストを減らすことができることが特徴になっている。
以下、本発明の特徴について、図面を参照して詳細に説明する。

＜実施形態の全体構成＞
以下、図１乃至図１８を参照して、本発明の一実施形態について説明する。図１は、本発明の一実施形態に係る通信システム１の概略図であり、まずは図１を用いて、本実施形態の概略を説明する。

図１に示す通信システム１は、複数の通信端末（１０ａａ、１０ａｂ、…、１０ｄｂ）、各通信端末（１０ａａ、１０ａｂ、…、１０ｄｂ）用のディスプレイ（１２０ａａ、１２０ａｂ、…、１２０ｄｂ）、及びログアップロードサーバ５０によって構築されている。
なお、本実施形態では、通信端末（１０ａａ、１０ａｂ、…、１０ｄｂ）のうち任意の通信端末を示す場合には「通信端末１０」を用いる。また、ディスプレイ（１２０ａａ、１２０ａｂ、…、１２０ｄｂ）のうち任意のディスプレイを示す場合には「ディスプレイ１２０」を用いる。
通信端末１０は、他の通信端末１０との間で、画像データ、音声データ等の送受信を行う。本実施形態では、画像データの画像が動画の場合について説明するが、動画だけでなく静止画であってもよい。また、画像データの画像には、動画と静止画の両方が含まれてもよい。ログアップロードサーバ５０は、通信端末１０を一元的に管理する。

また、図１に示す複数のルータ（７０ａ、７０ｂ、…、７０ｇ）は、画像データ及び音声データの最適な経路の選択を行う。なお、本実施形態では、ルータ（７０ａ、７０ｂ、…、７０ｇ）のうち任意のルータを示す場合には「ルータ７０」を用いる。プログラム提供システム９０は、通信端末１０に各種機能又は各種手段を実現させるための通信端末用プログラムが記憶された、ＨＤ（Ｈａｒｄ Ｄｉｓｋ）（図示しない）を備えており、通信端末１０に、通信端末用プログラムを送信することができる。また、プログラム提供システム９０のＨＤには、ログアップロードサーバ５０に各種機能又は各種手段を実現させるための通信管理用プログラムも記憶されており、ログアップロードサーバ５０に、通信管理用プログラムを送信する。

また、通信端末１０ａａ、通信端末１０ａｂ、及びルータ７０ａは、ＬＡＮ２ａによって通信可能に接続されている。通信端末１０ｂａ、通信端末１０ｂｂ、及びルータ７０ｂは、ＬＡＮ２ｂによって通信可能に接続されている。また、ＬＡＮ２ａ及びＬＡＮ２ｂは、ルータ７０ｃが含まれた専用線２ａｂによって通信可能に接続されており、所定の地域Ａ内で構築されている。例えば、地域Ａは日本であり、ＬＡＮ２ａは東京の事業所内で構築されており、ＬＡＮ２ｂは大阪の事業所内で構築されている。

一方、通信端末１０ｃａ、通信端末１０ｃｂ、及びルータ７０ｃは、ＬＡＮ２ｃによって通信可能に接続されている。通信端末１０ｄａ、通信端末１０ｄｂ、及びルータ７０ｄは、ＬＡＮ２ｄによって通信可能に接続されている。また、ＬＡＮ２ｃ及びＬＡＮ２ｄは、ルータ７０ｅが含まれた専用線２ｃｄによって通信可能に接続されており、所定の地域Ｂ内で構築されている。例えば、地域Ｂはアメリカであり、ＬＡＮ２ｃはニューヨークの事業所内で構築されており、ＬＡＮ２ｄはワシントンＤ．Ｃ．の事業所内で構築されている。地域Ａ及び地域Ｂは、それぞれルータ（７０ｃ、７０ｅ）からインターネット２ｉを介して通信可能に接続されている。

また、ログアップロードサーバ５０は、インターネット２ｉを介して、通信端末１０と通信可能に接続されている。
ログアップロードサーバ５０、及びプログラム提供システム９０は、地域Ａ又は地域Ｂに設置されていてもよいし、これら以外の地域に設置されていてもよい。
なお、本実施形態では、ＬＡＮ２ａ、ＬＡＮ２ｂ、専用線２ａｂ、インターネット２ｉ、専用線２ｃｄ、ＬＡＮ２ｃ、及びＬＡＮ２ｄによって、本実施形態の通信ネットワーク２が構築されている。この通信ネットワーク２には、有線だけでなく無線による通信が行われる箇所があってもよい。

また、図１において、各通信端末１０、ログアップロードサーバ５０、各ルータ７０、及びプログラム提供システム９０の下に示す４組の数字は、一般的なＩＰｖ４におけるＩＰアドレスを簡易的に示している。例えば、通信端末１０ａａのＩＰアドレスは「１．２．１．３」である。また、ＩＰｖ４ではなく、ＩＰｖ６を用いてもよいが、説明を簡略化するため、ＩＰｖ４を用いて説明する。

＜実施形態のハードウェア構成＞
次に、本実施形態のハードウェア構成を説明する。
図２は、本発明の一実施形態に係る通信端末１０のハードウェア構成図である。
図２に示すように、本実施形態の通信端末１０は、通信端末１０全体の動作を制御するＣＰＵ（Central Processing Unit）１０１、通信端末用プログラムを記憶したＲＯＭ（Read Only Memory）１０２、ＣＰＵ１０１のワークエリアとして使用されるＲＡＭ（Random Access Memory）１０３、画像データや音声データ等の各種データを記憶するフラッシュメモリ１０４、ＣＰＵ１０１の制御にしたがってフラッシュメモリ１０４に対する各種データの読み出し又は書き込みを制御するＳＳＤ（Solid State Drive）１０５、フラッシュメモリ等の記録メディア１０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアドライブ１０７、通信端末１０の宛先を選択する場合などに操作される操作ボタン１０８、通信端末１０の電源のＯＮ／ＯＦＦを切り換えるための電源スイッチ１０９、後述の通信ネットワーク２を利用してデータ伝送をするためのネットワークＩ／Ｆ１１１、ＣＰＵ１０１の制御に従って被写体を撮像し画像データを得るＣＭＯＳ（Ｃomplementary Metal Oxide Semiconductor）１１２、このＣＭＯＳ１１２の駆動を制御する撮像素子Ｉ／Ｆ１１３、音声を入力するマイク１１４、音声を出力するスピーカ１１５、ＣＰＵ１０１の制御に従ってマイク１１４及びスピーカ１１５との間で音声信号の入出力を処理する音声入出力Ｉ／Ｆ１１６、ＣＰＵ１０１の制御に従って外付けのディスプレイ１２０に画像データを伝送するディスプレイＩ／Ｆ１１７、及び上記各構成要素を図２に示すように電気的に接続するためのアドレスバスやデータバス等のバスライン１１０を備えている。

なお、記録メディア１０６は、通信端末１０に対して着脱自在な構成となっている。また、ＣＰＵ１０１の制御にしたがってデータの読み出し又は書き込みを行う不揮発性メモリであれば、フラッシュメモリ１０４に限らず、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）等を用いてもよい。更に、ＣＭＯＳ１１２は、光を電荷に変換して被写体の画像（映像）を電子化する固体撮像素子であり、被写体を撮像するものであればＣＭＯＳに限らず、ＣＣＤ（Charge Coupled Device）等を用いてもよい。また、ディスプレイ１２０は、被写体の画像や操作用アイコン等を表示する液晶や有機ＥＬによって構成されている。

更に、上記通信端末用プログラムは、インストール可能な形式又は実行可能な形式のファイルで、上記記録メディア１０６等の、コンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。

図３は、本発明の一実施形態に係るログアップロードサーバ５０のハードウェア構成図である。
ログアップロードサーバ５０は、ログアップロードサーバ５０全体の動作を制御するＣＰＵ２０１、通信管理用プログラムを記憶したＲＯＭ２０２、ＣＰＵ２０１のワークエリアとして使用されるＲＡＭ２０３、各種データを記憶するＨＤ（Hard Disk）２０４、ＣＰＵ２０１の制御にしたがってＨＤ２０４に対する各種データの読み出し又は書き込みを制御するＨＤＤ（Hard Disk Drive）２０５、フラッシュメモリ等の記録メディア２０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアドライブ２０７、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示するディスプレイ２０８、後述の通信ネットワーク２を利用してデータ伝送をするためのネットワークＩ／Ｆ２０９、文字、数値、各種指示などの入力のための複数のキーを備えたキーボード２１１、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行うマウス２１２、着脱可能な記録媒体の一例としてのＣＤ−ＲＯＭ（Compact Disc Read Only Memory）２１３に対するデータの読み出し又は書き込みを制御するＣＤ−ＲＯＭドライブ２１４、及び、上記各構成要素を図３に示すように電気的に接続するためのアドレスバスやデータバス等のバスライン２１０を備えている。

なお、上記通信管理用プログラムは、インストール可能な形式又は実行可能な形式のファイルで、上記記録メディア２０６やＣＤ−ＲＯＭ２１３等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。

更に、プログラム提供システム９０は、上記ログアップロードサーバ５０と同様のハードウェア構成を有しているため、その説明を省略する。但し、ＲＯＭ２０２には、プログラム提供システム９０を制御するためのプログラム提供用プログラムが記録されている。この場合も、プログラム提供用プログラムは、インストール可能な形式又は実行可能な形式のファイルで、上記記録メディア２０６やＣＤ−ＲＯＭ２１３等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。

更に、ログアップロードサーバ５０は、上記ログアップロードサーバ５０と同様のハードウェア構成を有しているため、その説明を省略する。但し、ＲＯＭ２０２には、ログアップロードサーバ５０を制御するためのログアップロードサーバ用プログラムが記録されている。この場合も、ログアップロードサーバ用プログラムは、インストール可能な形式又は実行可能な形式のファイルで、上記記録メディア２０６やＣＤ−ＲＯＭ２１３等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。
なお、上記着脱可能な記録媒体の他の例として、ＣＤ−Ｒ（Compact Disc Recordable）、ＤＶＤ（Digital Versatile Disk）、ブルーレイディスク等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。

＜実施形態の機能構成＞
次に、本実施形態の機能構成について説明する。図４は、本実施形態の通信システム１を構成する各端末、装置及びシステムの機能ブロック図である。図４では、通信端末１０、ログアップロードサーバ５０が、通信ネットワーク２を介してデータ通信することができるように接続されている。また、図４では、ログアップロードサーバ５０が、ＬＡＮ２ｅを介してデータ通信することができるように接続されている。なお、図１に示すプログラム提供システム９０は、テレビ会議の通信において直接関係ないため、図４では省略されている。

＜通信端末の機能構成＞
通信端末１０は、送受信部１１、操作入力受付部１２、ログイン要求部１３、撮像部１４ａ、画像表示制御部１４ｂ、音声入力部１５ａ、音声出力部１５ｂ、遅延検出部１７、形式情報取得部１８、記憶・読出処理部１９、ログ情報作成部２０、及びメッセージ作成部２１を有している。これら各部は、図２に示す各構成要素のいずれかが、ＲＯＭ２０２に記憶されているプログラムに従ったＣＰＵ２０１からの命令によって動作することで実現される機能又は手段である。また、通信端末１０は、図２に示すＳＳＤ１０５によって構築される記憶部１０００を有している。

（通信端末の各機能部）
次に、通信端末の各部を詳細に説明する。通信端末１０の送受信部１１は、図２に示すネットワークＩ／Ｆ１１１によって実現され、通信ネットワーク２を介して他の端末、装置又はシステムと各種データ（情報）の送受信を行う。操作入力受付部１２は、図２に示す操作ボタン１０８、及び電源スイッチ１０９によって実現され、利用者による各種入力を受け付ける。例えば、利用者が、図２に示す電源スイッチ１０９をＯＮにすると、図４に示す操作入力受付部１２が電源ＯＮを受け付けて、電源をＯＮにする。
ログイン要求部１３は、図２に示すＣＰＵ１０１からの命令によって実現され、上記電源ＯＮの受け付けを契機として、送受信部１１から通信ネットワーク２を介してログアップロードサーバ５０に、ログインを要求する旨を示すログイン要求情報、及び通信端末１０ａｂの現時点のＩＰアドレスを自動的に送信する。

撮像部１４ａは、図２に示すＣＭＯＳ１１２、及び撮像素子Ｉ／Ｆ１１３によって実現され、被写体を撮像して、この撮像して得た画像データを出力する。映像表示制御部１４ｂは、図２に示すディスプレイＩ／Ｆ１１７によって実現され、外付けのディスプレイ１２０に対して画像データを送信するための制御を行う。音声入力部１５ａは、図２に示すマイク１１４、及び音声入出力Ｉ／Ｆ１１６によって実現され、利用者の音声を入力し、この音声を音声信号に変換することで、音声信号に係る音声データを出力する。音声出力部１５ｂは、図２に示すスピーカ１１５、及び音声入出力Ｉ／Ｆ１１６によって実現され、音声データに係る音声信号を音声に変換して出力する。

形式情報取得部１８は、図２に示すＣＰＵ１０１からの命令によって実現され、記憶部１０００に登録された形式情報を取得する。ログ情報作成部２０は、図２に示すＣＰＵ１０１からの命令によって実現され、他の通信端末との通信を行う際に操作入力受付部１２が受け付けた操作の内容や通信端末の各部が行った処理の内容に基づきログ情報を作成する。ここで、ログ情報作成部２０は、ログ情報を作成することが可能な複数の形式の中から形式情報取得部１８によって取得された形式情報により示される形式を選択し、選択された形式でログ情報を作成する。

図５に、ログ情報作成部２０により作成されたログ情報の一例を示す。このログ情報の「ｔｙｐｅ」の項目には、他の通信端末との間の通信で送受信される情報が要求に関するものであることを表す「ｒｅｑｕｅｓｔ」や、応答に関するものであることを表す「ｒｅｓｐｏｎｓｅ」等の情報が記録される。
このログ情報の「Ｃａｌｌ−ＩＤ」の項目には、他の通信端末との通信を識別するための識別情報が記録される。このログ情報の「Ｃｏｍｍａｎｄ」の項目には、操作入力受付部１２により操作の入力を受け付けた要求の内容が記録され、通信の開始を要求する「ｉｎｖｉｔｅ」や、通信の終了を要求する「ｅｎｄ」等の情報が記録される。ログ情報の「Ｒｅｓｕｌｔ」の項目には、他の通信端末からの又は他の通信端末に対する応答の内容が記録され、許可を表す情報や、不許可を表す情報等が記録される。なお、図５では、ＪＳＯＮの形式により作成されたログ情報の一例を示したが、形式情報取得部１８により取得された形式情報で示される形式に従い同様の情報が含まれるログ情報が作成される。

メッセージ作成部２１は、図２に示すＣＰＵ１０１からの命令によって実現され、自端末を識別するための通信端末ＩＤを含むメッセージをログアップロードサーバ５０によって解釈される形式で作成する。ここで、ログアップロードサーバ５０によって解釈される形式は、ログアップロードサーバ５０と自端末である通信端末との通信で用いられる通信プロトコルに従った形式であり、通信端末用プログラムによって予め定められている。この通信プロトコルには、インターネット技術タスクフォースにより標準化される通信プロトコルが好適に用いられ、ＸＭＰＰ（Extensible Messaging and Presence Protocol）が例示される。なお、本実施形態では、メッセージとは、送信データの中に少なくともログ情報が含まれる旨を送信先に伝達するためのメッセージを意味する。

メッセージ作成部２１は、作成されたメッセージ２１００の所定の個所に、ログ情報作成部２０によって作成されたログ情報を含めて送信データ２２００を作成する。ここで、メッセージ作成部２１により作成された送信データ２２００の一例を図６に示す。
図６の例では、送信データ２２００は、ＪＳＯＮの形式により作成されたログ情報２０００と、ＸＭＰＰの一つであるＲＦＣ（Request for Comments）３９２１に従いＸＭＬの形式で作成されたメッセージ２１００と、を含む。本実施形態では、通信端末用プログラム及び通信管理用プログラムのそれぞれのプログラムによって、送信データの「＜ｍｅｓｓａｇｅ＞」タグの子ノードである「＜ｂｏｄｙ＞」タグにはログ情報が含まれる旨が定められている。このため、図６の送信データを受信したログアップロードサーバ５０は「＜ｂｏｄｙ＞」タグにログ情報が含まれることを把握することができる。なお、ＲＦＣ３９２１によると「＜ｂｏｄｙ＞」タグに任意の文字列を記録することが可能とされているため、図６では「＜ｂｏｄｙ＞」タグにログ情報を含める構成としている。ログ情報２０００を送信データ２２００に含める方法は、ログアップロードサーバ５０に対応する通信プロトコルに従うものであれば特に限定されない。

また、記憶・読出処理部１９は、図２に示すＳＳＤ１０５によって実行され、記憶部１０００に各種データを記憶したり、記憶部１０００に記憶された各種データを読み出したりする処理を行う。記憶部１０００には、通信端末１０を識別するための端末ＩＤ（Identification）、及びパスワード、並びに、画像データ、及び音声データ等が記憶される。

なお、本実施形態の端末ＩＤは、それぞれ通信端末１０を一意に識別するために使われる言語、文字、記号、又は各種のしるし等の識別情報を示す。また、端末ＩＤ、上記言語、文字、記号、及び各種のしるしのうち、少なくとも２つが組み合わされた識別情報であってもよい。また、以下では、テレビ会議の開始を要求する要求元としての通信端末１０を「要求元端末１０Ａ」とし、要求先である宛先としての通信端末１０を「宛先端末１０Ｂ」として説明する。

＜ログアップロードサーバの機能構成＞
次に、ログアップロードサーバ５０の機能又は手段について説明する。ログアップロードサーバ５０は、送受信部５０１、端末認証部５０２、状態管理部５０３、端末抽出部５０４、端末状態取得部５０５、記憶・読出処理部５０９、及びログ情報抽出部５１１を有している。これら各部は、図３に示す各構成要素のいずれかが、ＲＯＭ２０２に記憶されているプログラムに従ったＣＰＵ２０１からの命令によって動作することで実現される機能又は手段である。また、ログアップロードサーバ５０は、図３に示すＨＤ２０４により構築される記憶部５０００を有している。

（端末認証管理テーブル）
更に、記憶部５０００には、図示しない端末認証管理テーブルによって構成されている端末認証管理ＤＢ５００２が構築されている。この端末認証管理テーブルでは、ログアップロードサーバ５０によって管理される全ての通信端末１０の各端末ＩＤに対して、各パスワードが関連付けられて管理される。例えば、端末認証管理テーブルにおいて、通信端末１０ａａの端末ＩＤは「０１ａａ」で示し、パスワードは「ａａａａ」で示す。

（端末管理テーブル）
また、記憶部５０００には、端末管理テーブルによって構成されている端末管理ＤＢ５００３が構築されている。この端末管理テーブルでは、各通信端末１０の端末ＩＤ毎に、各通信端末１０の稼動状態、後述のログイン要求情報がログアップロードサーバ５０で受信された受信日時、及び通信端末１０のＩＰアドレスが関連付けられて管理される。
例えば、端末管理テーブルにおいて、端末ＩＤが「０１ａａ」の通信端末１０ａａは、稼動状態が「ＯＮライン」で、ログアップロードサーバ５０でログイン要求情報が受信された日時が「２００９年１１月１０日の１３時４０分」であることを示し、この通信端末１０ａａのＩＰアドレスが「１．２．１．３」であることを示す。

（宛先リスト管理テーブル）
更に、記憶部５０００には、図示しない宛先リスト管理テーブルによって構成されている宛先リスト管理ＤＢ５００４が構築されている。この宛先リスト管理テーブルでは、テレビ会議の開始を要求する要求元端末１０Ａの端末ＩＤに対して、宛先端末１０Ｂの候補として登録されている宛先端末１０Ｂの端末ＩＤが全て関連付けられて管理される。
例えば、宛先リスト管理テーブルにおいて、端末ＩＤが「０１ａａ」である要求元端末１０ａａからテレビ会議の開始を要求することができる宛先端末１０Ｂの候補は、端末ＩＤが「０１ａｂ」の通信端末１０ａｂ、端末ＩＤが「０１ｂａ」の通信端末１０ｂａ、及び端末ＩＤが「０１ｄｂ」の通信端末１０ｄｂの３つであることを示す。この宛先端末１０Ｂの候補は、要求元端末１０Ａからログアップロードサーバ５０に対する追加又は削除の要請により、追加又は削除されることで更新される。

（アドレス優先度管理テーブル）
更に、記憶部５０００には、図示しないアドレス優先度管理テーブルによって構成されている優先度管理ＤＢ５００６が構築されている。このアドレス優先度管理テーブルでは、一般的なＩＰｖ４におけるＩＰアドレスのうちの４組のドットアドレス（Ｄｏｔ Ａｄｄｒｅｓｓ）部分の同異に応じて、アドレス優先度のポイントが高くなるように関連付けられて管理される。例えば、アドレス優先度管理テーブルにおいて、ドットアドレスの上位から下位にかけて３つの値が同じＩＰアドレスの場合には、アドレス優先度のポイントが「５」である。ドットアドレスの上位から下位にかけて２つの値が同じＩＰアドレスの場合には、アドレス優先度のポイントが「３」である。この場合、最下位のドットアドレスの値が同じであるか否かは優先度に関係ない。ドットアドレスの最上位の値が同じで、上位から２番目の値が異なるＩＰアドレスの場合には、アドレス優先度のポイントが「１」である。この場合、上位から３番目及び最下位のドットアドレスの値が同じであるか否かは優先度には関係ない。ドットアドレスの最上位の値が異なるＩＰアドレスの場合には、アドレス優先度のポイントが「０」である。この場合、上位から２番目、３番目、及び最下位のドットアドレスの値が同じであるか否かは優先度には関係ない。

（ログアップロードサーバの各機能部）
次に、ログアップロードサーバ５０の各機能部について詳細に説明する。なお、以下では、ログアップロードサーバ５０の各部を説明するにあたって、図３に示す各構成要素のうち、ログアップロードサーバ５０の各部を実現させるための主な構成要素との関係も説明する。

送受信部５０１は、図２に示すネットワークＩ／Ｆ２０９によって実行され、通信ネットワーク２又はＬＡＮ２ｅを介して他の端末、装置又はシステムと各種データ（情報）の送受信を行う。
端末認証部５０２は、送受信部５０１を介して受信されたログイン要求情報に含まれている端末ＩＤ及びパスワードを検索キーとし、記憶部５０００の端末認証管理ＤＢ５００２を検索し、端末認証管理ＤＢ５００２に同一の端末ＩＤ及びパスワードが管理されているかを判断することによって端末認証を行う。
状態管理部５０３は、ログイン要求してきた要求元端末１０Ａの稼動状態を管理すべく、端末管理ＤＢ５００３（図示しない）に、この要求元端末１０Ａの端末ＩＤ、要求元端末１０Ａの稼動状態、ログアップロードサーバ５０でログイン要求情報が受信された受信日時、及び要求元端末１０のＩＰアドレスを関連付けて記憶して管理する。

端末抽出部５０４は、ログイン要求した要求元端末１０Ａの端末ＩＤをキーとして、宛先リスト管理ＤＢ５００４（図示しない）を検索し、要求元端末１０Ａと通信することができる宛先端末１０Ｂの候補の端末ＩＤを読み出すことで、端末ＩＤを抽出する。また、端末抽出部５０４は、ログイン要求してきた要求元端末１０Ａの端末ＩＤをキーとして、宛先リスト管理ＤＢ５００４を検索し、上記要求元端末１０Ａの端末ＩＤを宛先端末１０Ｂの候補として登録している他の要求元端末１０Ａの端末ＩＤも抽出する。

端末状態取得部５０５は、上記端末抽出部５０４によって抽出された宛先端末１０Ｂの候補の端末ＩＤを検索キーとして、端末管理ＤＢ５００３を検索し、上記端末抽出部５０４によって抽出された端末ＩＤ毎に稼動状態を読み出す。これにより、端末状態取得部５０５は、ログイン要求してきた要求元端末１０Ａと通信することができる宛先端末１０Ｂの候補の稼動状態を取得することができる。また、端末状態取得部５０５は、上記端末抽出部５０４によって抽出された端末ＩＤを検索キーとして、端末状態管理ＤＢ５００３を検索し、ログイン要求してきた要求元端末１０Ａの稼動状態も取得する。
記憶・読出処理部５０９は、図３に示すＨＤＤ２０５によって実行され、記憶部５０００に各種データを記憶する処理を行い、記憶部５０００に記憶された各種データを読み出す処理を行う。

ログ情報抽出部５１１は、通信端末１０によって送信される送信データ２２００から、ログ情報２０００を抽出する。ここで、ログ情報２０００を抽出する方法は、送信データ２２００の形式により異なり、ログアップロードサーバ用プログラムにより予め定められている。例えば、送信データ２２００が図６に示すようなＲＦＣ３９２１のプロトコルにより作成されたものである場合には、ログ情報抽出部５１１は、「＜ｂｏｄｙ＞」タグに記録されたログ情報２０００を抽出する。
この場合、ログ情報抽出部５１１は、ＲＯＭ２０２に記録されたパーサ（構文解析を行うプログラムを意味する）を用いて送信データ２２００を解析し、「＜ｍｅｓｓａｇｅ＞」タグの子ノードである「＜ｂｏｄｙ＞」タグからログ情報２０００を抽出することができる。

＜ログアップロードサーバの機能構成＞
次に、ログアップロードサーバ５０の機能又は手段について説明する。ログアップロードサーバ５０は、送受信部５５１、ログ情報管理部５５２、記憶・読出処理部５５９を有している。これら各部は、図３に示す各構成要素のいずれかが、ＲＯＭ２０２に記憶されているプログラムに従ったＣＰＵ２０１からの命令によって動作することで実現される機能又は手段である。また、ログアップロードサーバ５０は、図３に示すＨＤ２０４により構築される記憶部５５００を有している。

（ログ管理テーブル）
記憶部５５００には、図７に示すログ管理テーブルによって構成されているログ管理ＤＢ５５０１が構築されている。このログ管理テーブルは、通信端末１０の端末ＩＤ毎に作成され、ログ情報の識別情報（ログＩＤという）と、ログ情報とが関連付けられて管理される。

（ログアップロードサーバの各機能部）
次に、ログアップロードサーバ５０の各機能部について詳細に説明する。なお、以下では、ログアップロードサーバ５０の各部を説明するにあたって、図３に示す各構成要素のうち、ログアップロードサーバ５０の各部を実現させるための主な構成要素との関係も説明する。

送受信部５５１は、図２に示すネットワークＩ／Ｆ２０９によって実行され、ＬＡＮ２ｅを介してログアップロードサーバ５０と各種データ（情報）の送受信を行う。また、ログ情報管理部５５２は、ログアップロードサーバ５０からの要求に応じて、ログ管理ＤＢ５５０１に構築されているログ管理ＤＢの作成やログ情報の記憶、更新を行ったり、ログ管理ＤＢからログ情報を取得したりする。記憶・読出処理部５５９は、図３に示すＨＤＤ２０５によって実行され、記憶部５５００に各種データを記憶したり、記憶部５５００に記憶された各種データを読み出したりする処理を行う。

図４を参照して、本実施形態の通信システム１に備えたログ再送制御部２２について説明する。
通信端末１０とログアップロードサーバ５０は、通信ネットワーク２を介してデータ通信することができるように接続されている。本発明では、通信端末１０に、再送を制御するログ再送制御部２２を備え、ログ再送制御部２２は、ログ再送時のリトライ時間を算出するとともに、リトライ時間を管理している。

図８は、ログ情報およびログアップロード機能について説明するための模式図である。
通信端末１０では、当該端末のログ情報作成部２０において作成したログ情報を格納したログファイルを記憶部１０００に蓄積している。
ユーザ側において、ユーザが通信端末１０を使用した際に何らかの障害が発生した場合、ユーザがサポートセンタに例えば電話機を用いて問い合わせを行ったときに、サポートセンタ側のオペレータからの依頼により、通信端末１０に実装されたログアップロード機能を操作することによって、記憶部１０００に記憶されている必要なログファイルが、サポートセンタ側のログアップロードサーバ５０にアップロードされるように運用することになっている。
サポートセンタ側では、ログアップロードサーバ５０にアップロードされたログファイルに基づいて、障害発生原因の解析作業を行い、障害対応を行う。
なお、上述した例では、ユーザがサポートセンタに例えば電話機を用いて問い合わせをおこなう場合について説明したが、電話機に代わって、携帯電話のメール機能を用いてもよい。

図９は、通常時のログアップロードが成功した時のシーケンス図である。
まず、通信端末１０に障害が発生したこととする。この際、ユーザが例えば電話機を用いて通信端末１０に障害があることをサポートセンタに報告する（Ｓ５）。
このとき、サポートセンタ側では、ユーザから障害報告を受けた担当者は、通信端末１０に保存されたログファイルを解析するため、ユーザに通信端末１０に備わったログアップロード機能の操作を依頼する（Ｓ１０）。
次いで、ユーザは、通信端末１０に備わったログアップロード機能を操作する（Ｓ１５）。
通信端末１０は、ログファイルをログアップロードサーバ５０にアップロードする（Ｓ２０）。
シーケンスＳ２０において、通信端末１０から通信ネットワーク２を介してログアップロードサーバ５０へのセッションが確立し、通信端末１０からログアップロードサーバ５０へのアップロードが成功した場合、通信端末１０は、ログアップロード機能により成功通知をユーザに通知する（Ｓ２５）。
サポートセンタでは、担当者はログアップロードサーバ５０にアップロードされたログファイルを解析し、障害原因を調査する（Ｓ３０）。
ここで、通信端末１０とログアップロードサーバ５０間に設けられた通信ネットワーク２が正常に接続している場合は、ユーザは一度の操作でアップロードを達成することができる。
ログファイルのサイズは、数１００ＫＢから１ＭＢ程度であり、個々の通信端末１０の稼働状況に依存して変動する。アップロードに要する時間は、ネットワーク状況とログファイルのサイズによっても変化するが、通常、１〜３秒程度で完了する。

図１０は、ネットワーク切断時にリトライが無い場合のシーケンス図である。
ユーザが例えば電話機を用いて通信端末１０に障害があることをサポートセンタに報告する（Ｓ１０５）。
このとき、サポートセンタ側では、ユーザから障害報告を受けた担当者は、通信端末１０に保存されたログファイルを解析するため、ユーザに通信端末１０に備わったログアップロード機能の操作を依頼する（Ｓ１１０）。
次いで、ユーザは、通信端末１０に備わったログアップロード機能を操作する（Ｓ１１５）。
通信端末１０は、ログファイルをログアップロードサーバ５０にアップロードを実行するが、通信端末１０に障害が発生した場合は、何らかの原因で通信端末１０が通信ネットワークから切断されたことに起因する場合が多くある（Ｓ１２０）。
この場合、ログアップロードの操作を依頼した時点で、当該通信端末１０が通信ネットワークから切断されており、通信端末１０から通信ネットワーク２を介してログアップロードサーバ５０へのセッションが確立しておらず、アップロードが失敗する可能性は非常に高く、アップロードが失敗した場合はユーザに失敗通知を通知する（Ｓ１２５）。
ここで、ログファイルをログアップロードサーバ５０にアップロードするためには、ユーザは成功するまで処理を繰り返す必要がある。このため、シーケンスＳ１１５〜Ｓ１２５と同様にＳ１１５‘〜Ｓ１２５’を繰り返す。

ネットワーク切断の原因が解消し、通信端末１０が再び通信ネットワーク２に接続した場合に、ネットワーク接続が回復する（Ｓ１３０）。
次いで、ユーザは、通信端末１０に備わったログアップロード機能を操作する（Ｓ１３５）。
ネットワーク接続後にユーザが再び操作することで、通信端末１０は、ログファイルをログアップロードサーバ５０にアップロードする（Ｓ１４０）。
シーケンスＳ１３０において、通信端末１０からログアップロードサーバ５０へのアップロードが成功した場合、通信端末１０は、ログアップロード機能により成功通知をユーザに通知する（Ｓ１４５）。
サポートセンタでは、担当者はログアップロードサーバ５０にアップロードされたログファイルを解析し、障害原因を調査する（Ｓ１５０）。

図１１は、ネットワーク切断時にリトライが有る場合のシーケンス図である。
ユーザが例えば電話機を用いて通信端末１０に障害があることをサポートセンタに報告する（Ｓ２０５）。
このとき、サポートセンタ側では、ユーザから障害報告を受けた担当者は、通信端末１０に保存されたログファイルを解析するため、ユーザに通信端末１０に備わったログアップロード機能の操作を依頼する（Ｓ２１０）。
次いで、ユーザは、通信端末１０に備わったログアップロード機能を操作する（Ｓ２１５）。なお、リトライ操作をユーザに繰り返させると、ユーザの操作負担が高くなるため、ユーザが操作するのは最初の一度だけとする。
ここで、ユーザによる操作があった時点でアップロードが失敗した場合には、一定時間内にプログラムが自動リトライを実施し、ログアップロード機能を繰り返す（Ｓ２２０〜Ｓ２３５）

ネットワーク切断の原因が解消し、通信端末１０が再び通信ネットワーク２に接続した場合に、ネットワーク接続が回復する（Ｓ２４０）。
ネットワーク接続後に再びログアップロード機能を実行することで、通信端末１０は、ログファイルをログアップロードサーバ５０にアップロードする（Ｓ２４５）。
シーケンスＳ２４０において、通信端末１０からログアップロードサーバ５０へのアップロードが成功した場合、通信端末１０は、ログアップロード機能により成功通知をユーザに通知する（Ｓ２５０）。
サポートセンタでは、担当者はログアップロードサーバ５０にアップロードされたログファイルを解析し、障害原因を調査する（Ｓ２５５）。

図１２は、ネットワーク切断時にリトライがあり、且つタイムアウトした場合のシーケンス図である。
シーケンスＳ３０５〜Ｓ３４０については、上述したシーケンスＳ２０５〜Ｓ２３５（図１１）と同様であり、アップロードが失敗した場合には、一定時間内にプログラムが自動リトライを実施し、ログアップロード機能を繰り返す。
ここで、リトライ処理には一定時間のタイムアウトを設定しておき、タイムアウトした場合は、リトライ処理を停止し、アップロードが失敗したこととする（Ｓ３４５）。
シーケンスＳ３４５において、リトライ処理がタイムアウトした場合、通信端末１０は、ログアップロード機能により失敗通知をユーザに通知する（Ｓ３５０）。

図１３（ａ）（ｂ）は、アップロード処理時に設定されるリトライ（一定時間）の時間間隔について説明するための模式図である。
リトライ処理のタイミングは、最初の失敗時点（時刻）からの経過時間によって決定する。
最とも単純な手法は、失敗時点から一定時間毎にリトライ処理を行う手法である。
しかし、通信ネットワーク２が切断される原因は、大きく二つの種類が考えられる。
第１に、ＷＩＦＩ接続の不調などによる瞬間的な切断である。第２に、ネットワーク障害などによる長期的な切断である。
このように仮定した上で、例えばリトライ時間を１秒（図１３（ａ））、１０秒（図１３（ｂ））と設定した場合の特徴は以下のようになる。

図１３（ａ）に示すように、リトライ時間を１秒に設定した場合、ネットワーク接続が回復した直後にアップロード処理を行えるのでアップロードが成功する。インターネット接続が回復するまでの時間が短時間であれば、アップロード処理が完了するまでのタイムラグを短くすることができるという利点を有している。
しかし、ネットワーク接続が回復するまでに長時間かかる場合は、通信ネットワークに無駄なトラフィックが大量に発生する。また、通信端末がモバイル端末である場合、バッテリを多く消費する恐れがあるという欠点を有している。
一方、図１３（ｂ）に示すように、リトライ時間を１０秒に設定した場合、ネットワーク接続が回復するまでに長時間かかっても、ネットワークトラフィックが少なく、モバイル端末などの場合でもバッテリの消費が少なく済むという利点を有している。
しかし、ネットワーク接続が回復しても、最長で１０秒間のタイムラグが発生する。この場合、通信ネットワークが瞬間的な切断だったとしても、アップロード処理が完了するまで時間がかかるという欠点を有している。

図１４は、アップロード処理におけるリトライ時間（重み付け有り）の時間間隔について説明するための模式図である。
ネットワーク状況として、瞬間的な切断と長期的な切断との両者を考慮して、リトライ時間の適切な最適化を実施するために、リトライ時間を最初に１秒から始め、次回以降のリトライ毎にその次の回のリトライ時間を一定の割合で長く伸ばしていく手法が考えられる。
この手法により、以下の利点が得られ、アップロード処理時のリトライを自動化して効率良く行うことができる。
ネットワーク状況として、瞬間的なネットワーク切断の場合、リトライに要する時間は最低でも１秒で済む。一方、長期的なネットワーク切断の場合、無駄なリクエストを減らし、ネットワーク資源やバッテリ資源を節約することができる。
また、リトライ時間をどの程度の割合で伸ばしていくのかは、ネットワーク状況に応じて変更するのが望ましい。

このリトライ時間を延ばす割合を「重み値」と呼ぶことにする。重み値が２である場合は、最初の失敗から１秒後にリトライし、それ以降はリトライ時間を２倍にしてリトライする。
一方、通信端末が接続されている通信ネットワークにおいて、ネットワーク切断からの回復が早い場合が多いときは、重み値を小さく設定する。一方、ネットワーク切断から回復するまでに要する時間がかかる場合、重み値は大きく設定する方がよい。
そこで、図１４（ｂ）に示すように、デフォルト値として重み値を２としリトライを実施する。
そして、リトライが発生するたびに通信端末内のＲＡＭにその回数を記録し、リトライ回数が多ければ次のログアップロード処理では重み値を増加させる。逆にリトライ回数が少なければ、重み値を減少させることで、通信端末が接続可能な通信ネットワークに適した重み値に近づけていくことができる。
ここで、重み値をＷとし、リトライ回数をｋとした場合に、ｋ回目のアップロードを実行する際のリトライ時間Ｔｒは、リトライ開始時点から、
Ｔｒ＝Ｗ＾（ｋ−１） （１）
秒後となる。

図１５は、ログ再送制御部２２のシーケンス動作を説明するためのシーケンス図である。
ユーザは、通信端末１０に備わったログアップロード機能を操作する（Ｓ４０５）。
通信端末１０は、アップロードの実施中に現在の重み値Ｗから算出したタイムアウト時間Ｔｏ内において、リトライ処理を実施す（Ｓ４１０、Ｓ４１５）。
ここで、リトライ処理において設定されたタイムアウト時間Ｔｏが経過し、タイムアウトした場合には、リトライ処理を停止し、アップロードが失敗したこととする（Ｓ４２０）。
通信端末１０は、現在の重み値Ｗから０．２だけ引いた値を算出し、この値を次回に用いる重み値Ｗとして更新してＲＡＭに記憶する（Ｓ４２５）。
次いで、シーケンスＳ４２０において、リトライ処理がタイムアウトした場合、通信端末１０は、ログアップロード機能により失敗通知をユーザに通知する（Ｓ４３０）。

また別の機会において、ユーザは通信端末１０に備わったログアップロード機能を操作する（Ｓ４３５）。
通信端末１０は、ＲＡＭから今回用いる重み値Ｗを読み出し、この重み値Ｗに基づいて、タイムアウト時間Ｔｏを算出しておき、このタイムアウト時間Ｔｏ内において、アップロードのリトライ処理を実施する（Ｓ４４０）。
ネットワーク接続が回復した直後にアップロードのリトライ処理が成功した場合（Ｓ４４５）、ログ再送制御部２２は現在の重み値Ｗに０．２を加算した値を算出し、この値を次回に用いる重み値Ｗとして更新してＲＡＭに記憶する（Ｓ４５０）。
シーケンスＳ４４５において、通信端末１０からログアップロードサーバ５０へのアップロードが成功した場合、通信端末１０は、ログアップロード機能により成功通知をユーザに通知する（Ｓ４５５）。

図１６は、ログ再送制御部２２が実行する重み値の算出方法について説明するための模式図である。
ログ再送制御部２２は、重み値Ｗのデフォルト値を２とし、予め通信端末のＥＥＰＲＯＭに記憶しておく。
ログ再送制御部２２は、ログアップロード処理を実行する前に、タイムアウト時間Ｔｏをタイマに設定しておき、リトライ処理を行い、リトライ処理中にタイムアウト時間Ｔｏが経過するとログアップロード処理が失敗したこととしてリトライ処理を停止する。
ログ再送制御部２２は、このタイムアウト時間Ｔｏ内にリトライ処理が成功した失敗したかを表すフラグＦの値に基づいて、次回のタイムアウト時間Ｔｏを算出するための重み値Ｗの更新値を算出する。

ここで、重み値Ｗを算出するための算出式を一般化して説明する。
ｋ回目のリトライ処理をＲ（ｋ）で表し、ログ再送制御部２２は、成功だった場合はフラグＦに１を返し、失敗だった場合はフラグＦに−１を返す。
ｋ回目のリトライ処理に適用する重み値Ｗ（ｋ）は、下記の式（２）で算出できる。
Ｗ（ｋ）＝Ｗ（ｋ−１）＋０．２＊Ｒ（ｋ−１） （２）
ログ再送制御部２２は、重み値Ｗの上限を３．０とし、その下限を１．２としておき、算出結果がその範囲（１．２〜３．０）を超える場合は、上限または下限に補正する。
このように、更新後の重み値を所定の範囲内に制限することで、次回の送信までの再送信待ち時間を制限した範囲内で調整することができる。

図１７は、ログ再送制御部２２が実行する重み値の算出方法について説明するためのフローチャートである。
通信端末１０のモニタ上には、ログアップロード機能を行うための指示を入力するソフトボタンが表示されていることとする。
まず、ステップＳｔ１０では、ログ再送制御部２２は、ログアップロード機能を行うためのソフトボタンがＯＮ操作されたか否かを判断し、ＯＮ操作された場合にステップＳｔ１５に進む。
次いで、ステップＳｔ１５では、ログ再送制御部２２は、ＥＥＰＲＯＭから重み値Ｗを読み出す。なお、上述したように、重み値Ｗのデフォルト値は２であるので、最初にＥＥＰＲＯＭから２が重み値Ｗとして読み出される。

次いで、ステップＳｔ２０では、ログ再送制御部２２は、ＥＥＰＲＯＭから取得した重み値Ｗに基づいて、タイムアウト時間Ｔｏを算出し、タイマに設定する。この結果、タイマは時間Ｔｏから０までカウントダウンを開始する。
ここで、タイムアウト時間Ｔｏは、リトライ時間Ｔｒ（式（１））から、
Ｔｏ＝Ｔｒ（１）＋Ｔｒ（２）＋・・・＋Ｔｒ（ｋ）
＝１＋Ｗ＾１＋・・・・・・・・・＋Ｗ＾（ｋ−１） （３）
となる。なお、リトライ回数ｋは適度な自然数に設定すればよい。
次いで、ステップＳｔ２５では、ログ再送制御部２２は、リトライ処理を実施するためにリトライ処理のサブルーチン（図１８）をコールする。なお、リトライ処理のサブルーチンから復帰（リターン）した際には、リトライ成功で１、リトライ失敗で−１をフラグＦとして返す。

次いで、ステップＳｔ３０では、ログ再送制御部２２は、フラグＦに基づいて、リトライ処理が成功したか否かを判断する。フラグＦが１である場合にはリトライ処理が成功したのでステップＳｔ３５に進む。一方、フラグＦが−１である場合にはリトライ処理が失敗したのでステップＳｔ４５に進む。
リトライ処理が成功し、ログアップロード処理を実行した場合に、ステップＳｔ３５では、ログ再送制御部２２は、今回の重み値Ｗから０．２だけ引いてＷを減少させ、ＥＥＰＲＯＭに記憶する。ＥＥＰＲＯＭに記憶させた重み値Ｗは、次回のリトライ処理に使用する重み値Ｗとなる。
次いで、ステップＳｔ４０では、ログ再送制御部２２は、ログアップロード処理が成功した旨を表す成功通知をモニタに表示するとともに、音声信号またはビープ音を発生し、ユーザに報知する。

一方、リトライ処理が失敗し、ログアップロード処理を実行できなかった場合に、ステップＳｔ４５では、ログ再送制御部２２は、今回の重み値Ｗに０．２だけ加えてＷを増加させ、ＥＥＰＲＯＭに記憶する。ＥＥＰＲＯＭに記憶させた重み値Ｗは、次回のリトライ処理に使用する重み値Ｗとなる。
次いで、ステップＳｔ５０では、ログ再送制御部２２は、ログアップロード処理が失敗した旨を表す失敗通知をモニタに表示するとともに、音声信号またはビープ音を発生し、ユーザに報知する。
このように、ログ再送制御部２２では、重み値Ｗに基づいて、タイムアウト時間Ｔｏを算出し、タイムアウト時間Ｔｏまでの間に再送信の結果に応じて重み値Ｗを更新するので、再送信の結果に応じて次回のリトライ時間（再送信待ち時間）を調整することができる。
また、ログ再送制御部２２では、再送信が成功した場合に重み値Ｗよりも次回の重み値Ｗを小さな値に更新し、再送信が失敗した場合に前回の重み値Ｗよりも次回の重み値Ｗを大きな値に更新することで、通信ネットワークの状況に応じて、次回の送信までのリトライ時間（再送信待ち時間）を調整することができる。
次いで、ステップＳｔ５５では、ログ再送制御部２２は、ログアップロード機能を停止するため、ソフトボタンがＯＦＦ操作されたか否かを判断し、ＯＦＦ操作された場合には処理を終了する。一方、ＯＦＦ操作がない場合には処理を継続するためステップＳｔ１５に戻る。

再度、ステップＳｔ１５に戻った場合には、ログ再送制御部２２は、ＥＥＰＲＯＭから重み値Ｗを読み出すが、この際の重み値Ｗはデフォルト値（２）ではなく、上述したステップＳｔ４５において記憶された値となる。
また、ＯＦＦ操作が行われた後に、再度、ＯＮ操作が行われ、ステップＳｔ１０からＳｔ１５に進んだ場合も、ログ再送制御部２２は、ＥＥＰＲＯＭから重み値Ｗを読み出すが、この際の重み値Ｗはデフォルト値（２）ではなく、上述したステップＳｔ４５又はＳｔ４０において記憶された値となる。

図１８は、ログ再送制御部２２が実行するリトライ処理のサブルーチンを示すフローチャートである。
まず、ステップＳｔ１１０では、ログ再送制御部２２は、ＥＥＰＲＯＭから取得した重み値Ｗに基づいて、１回目からｋ回目、ｎ回目（最大回目）までのリトライ時間Ｔｒを生成し、ＲＡＭ上に設けられたテーブルに記憶する。
ここで、ｋは再送信を失敗した回数、Ｗはリトライ時間（再送信待ち時間）Ｔｒを長く算出する割合を表す重み値を表している。
この結果、例えば表１に示すような処理番号ｋ、リトライ時間Ｔｒがテーブルに記憶される。

なお、表１に示すリトライ時間ｔｒは、ＥＥＰＲＯＭから取得した重み値Ｗが例えば１．８のときに式（１）に従って算出した値である。
このように、再送信を失敗した回数ｋ、リトライ時間（再送信待ち時間）Ｔｒを長く算出する割合を表す重み値Ｗに基づいて、次回の送信までのリトライ時間（再送信待ち時間）Ｔｒを算出しておくことができる。
次いで、ステップＳｔ１１５では、ログ再送制御部２２は、ループ処理に用いる処理番号ｋとして、ｋ＝１に設定する。

次いで、ステップＳｔ１２０では、ログ再送制御部２２は、リトライ処理を実施する。すなわち、リトライ処理では、通信端末１０から通信ネットワーク２を介してログアップロードサーバ５０へのセッションの確立を行い、通信端末１０からログアップロードサーバ５０へのログファイルのアップロードを行う。
次いで、ステップＳｔ１２５では、ログ再送制御部２２は、上記セッションが確立してリトライ処理が成功したか否かを判断する。リトライ処理が成功した場合にはステップＳｔ１３０に進む。一方、リトライ処理が成功しなかった場合（失敗）にはステップＳｔ１３５に進む。
次いで、ステップＳｔ１３０では、ログ再送制御部２２は、リトライ処理が成功した場合には、フラグＦに１を設定し、メインルーチンに復帰（リターン）する。
次いで、ステップＳｔ１３５では、ログ再送制御部２２は、処理番号ｋに１を加算（インクリメント）してｋ＝ｋ＋１に設定する。

次いで、ステップＳｔ１４０では、ログ再送制御部２２は、ｋ回目のリトライ時間Ｔｒをテーブルから読み出し、タイマＴｒに設定し、タイマによるカウントダウンをスタートする。
次いで、ステップＳｔ１４５では、ログ再送制御部２２は、タイマＴｒのカウント値が０になったか否かを判断する。タイマＴｒが０になった場合にはステップＳｔ１５０に進む。
次いで、ステップＳｔ１５０では、ログ再送制御部２２は、タイムアウト時間Ｔｏに到達したか否かを判断する。タイムアウト時間Ｔｏに到達した場合にはステップＳｔ１６０に進む。一方、まだタイムアウト時間Ｔｏに到達していない場合は、ステップＳ１５５に進む。
次いで、ステップＳｔ１５５では、ログ再送制御部２２は、タイムアウト時間Ｔｏに到達していない場合に、処理番号ｋがｎ＋１（最大回目＋１）に到達したか否かを判断する。処理番号ｋがｎ＋１に到達した場合にはステップＳｔ１６０に進む。一方、処理番号ｋがまだｎ＋１に到達していない場合は、ステップＳ１２０に戻る。
次いで、ステップＳｔ１５５では、ログ再送制御部２２は、タイムアウト時間Ｔｏに到達した場合、又は処理番号ｋがｎ＋１に到達した場合には、リトライ処理が失敗したこととし、フラグＦ＝−１に設定し、メインルーチンに復帰（リターン）する。

本実施形態によれば、通信ネットワーク２を介してログアップロードサーバ５０へのログファイルのある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間（リトライ時間）を算出し、リトライ時間（再送信待ち時間）が経過した場合に、ログアップロードサーバ５０へログファイルを再送信させる際に、前回のリトライ時間よりも次回のリトライ時間を長く算出することで、通信端末が接続された通信ネットワークの状況に応じて、次回の送信までのリトライ時間を調整することができる。
この結果、例えば通信ネットワークの接続回復が早い環境ではなるべく早くアップロードを完了し、接続回復が遅い環境では無駄なリクエストをなるべく減らすことができるので、端末が接続された通信ネットワーク環境に応じて、ログアップロードを自動でリトライするための適切なリトライ時間を算出することができ、このリトライ時間を用いてアップロードをリトライすることにより、電池の消耗を減らし、無駄なネットワークトラフィックを抑制することができる。

＜他の実施形態＞
上述した実施形態にあっては、ログ再送制御部２２において、再送信を失敗した回数ｋ、重み値Ｗに基づいて、リトライ時間Ｔｒを予め算出し、ＲＡＭ上のテーブルに記憶しておくように構成したが、本発明はこれに限定されるものではない。
すなわち、他の実施形態にあっては、ログ再送制御部２２において、再送信を失敗した回数ｋを計数しておき、再送信を失敗した場合に、重み値Ｗに基づいて、送信が失敗した後にリトライ時間Ｔｒを算出するように構成してもよい。
これにより、通信ネットワーク２を介してログアップロードサーバ５０へのログファイルのある送信が失敗した場合に、当該送信から次回の送信までのリトライ時間を算出し、リトライ時間が経過した場合に、ログアップロードサーバ５０へログファイルを再送信させる際に、前回のリトライ時間よりも次回のリトライ時間を長く算出することで、通信端末が接続された通信ネットワークの状況に応じて、次回の送信までのリトライ時間を調整することができる。
また、再送信を失敗した場合に、再送信を失敗した回数ｋ、重み値Ｗに基づいて、次回の送信までのリトライ時間を調整することができる。

＜本発明の実施態様例と効果＞
＜第１態様＞
本態様の通信端末１０は、通信ネットワーク２を介してログアップロードサーバ５０に接続する通信端末であって、通信ネットワーク２を介してログファイルをログアップロードサーバ５０へ送信する送信手段（送受信部１１）と、ログアップロードサーバ５０へのログファイルのある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間（リトライ時間）を算出する再送信待ち時間算出手段（ログ再送制御部２２）と、再送信待ち時間が経過した場合に、送信手段によりログアップロードサーバ５０へログファイルを再送信させる制御手段（ログ再送制御部２２）と、を備え、再送信待ち時間算出手段は、前回の再送信待ち時間よりも次回の再送信待ち時間を長く算出することを特徴とする。
本態様によれば、通信ネットワーク２を介してログアップロードサーバ５０へのログファイルのある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間（リトライ時間）を算出し、再送信待ち時間が経過した場合に、ログアップロードサーバ５０へログファイルを再送信させる際に、前回の再送信待ち時間よりも次回の再送信待ち時間を長く算出することで、通信端末が接続された通信ネットワークの状況に応じて、次回の送信までの再送信待ち時間を調整することができる。

＜第２態様＞
本態様の通信端末１０の再送信待ち時間算出手段（ログ再送制御部２２）は、再送信を失敗した回数、再送信待ち時間を長く算出する割合を表す重み値に基づいて、再送信待ち時間を算出することを特徴とする。
本態様によれば、再送信を失敗した回数、再送信待ち時間を長く算出する割合を表す重み値に基づいて、次回の送信までの再送信待ち時間を調整することができる。

＜第３態様＞
本態様の制御手段（ログ再送制御部２２）は、重み値に基づいて、タイムアウト時間を算出するタイムアウト時間算出手段と、タイムアウト時間までの間に再送信の結果に応じて重み値を更新する重み値更新手段と、を備えることを特徴とする。
本態様によれば、重み値に基づいて、タイムアウト時間を算出し、タイムアウト時間までの間に再送信の結果に応じて重み値を更新するので、再送信の結果に応じて次回の再送信待ち時間を調整することができる。

＜第４態様＞
本態様の重み値更新手段（ログ再送制御部２２）は、再送信が成功した場合に前回の重み値よりも次回の重み値を小さな値に更新し、再送信が失敗した場合に前回の重み値よりも次回の重み値を大きな値に更新することを特徴とする。
本態様によれば、再送信が成功した場合に重み値よりも次回の重み値を小さな値に更新し、再送信が失敗した場合に前回の重み値よりも次回の重み値を大きな値に更新することで、通信ネットワークの状況に応じて、次回の送信までの再送信待ち時間を調整することができる。

＜第５態様＞
本態様の重み値更新手段（ログ再送制御部２２）は、更新後の重み値を所定の範囲内に制限することを特徴とする。
本態様によれば、更新後の重み値を所定の範囲内に制限することで、次回の送信までの再送信待ち時間を制限した範囲内で調整することができる。

＜第６態様＞
本態様の通信情報は、自装置のログファイルであることを特徴とする。
本態様によれば、通信情報が自装置のログファイルであることで、ログファイルを再送信することができる。

＜第７態様＞
本態様の通信システム１は、第１態様乃至第６態様の何れか１つに記載の通信端末１０と、通信端末１０から通信情報を受信するログアップロードサーバ５０と、を備えたことを特徴とする。
本態様によれば、通信端末１０からログアップロードサーバ５０への再送信待ち時間を調整することができる。

＜第８態様＞
本態様の通信方法は、通信ネットワーク２を介してログアップロードサーバ５０に接続する通信端末における通信方法であって、通信ネットワーク２を介してログファイルをログアップロードサーバ５０へ送信する送信ステップ（ｓｔ１２０）と、ログアップロードサーバ５０へのログファイルのある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間（リトライ時間）を算出する再送信待ち時間算出ステップ（ｓｔ１１０）と、再送信待ち時間が経過した場合に、送信ステップによりログアップロードサーバ５０へログファイルを再送信させる制御ステップ（ｓｔ１２０）と、を備え、再送信待ち時間算出ステップは、前回の再送信待ち時間よりも次回の再送信待ち時間を長く算出することを特徴とする。
本態様によれば、通信ネットワーク２を介してログアップロードサーバ５０へのログファイルのある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間（リトライ時間）を算出し、再送信待ち時間が経過した場合に、ログアップロードサーバ５０へログファイルを再送信させる際に、前回の再送信待ち時間よりも次回の再送信待ち時間を長く算出することで、通信端末が接続された通信ネットワークの状況に応じて、次回の送信までの再送信待ち時間を調整することができる。

＜第９態様＞
本態様のプログラムは、第８態様記載の各ステップをプロセッサに実行させることを特徴とする。
本態様によれば、通信ネットワーク２を介してログアップロードサーバ５０へのログファイルのある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間（リトライ時間）を算出し、再送信待ち時間が経過した場合に、ログアップロードサーバ５０へログファイルを再送信させる際に、前回の再送信待ち時間よりも次回の再送信待ち時間を長く算出することで、通信端末が接続された通信ネットワークの状況に応じて、次回の送信までの再送信待ち時間を調整することができる。

１…通信システム、２…通信ネットワーク、１０…通信端末、１１…送受信部、１２…操作入力受付部、１３…ログイン要求部、１７…遅延検出部、１８…形式情報取得部、１９…記憶・読出処理部、２０…ログ情報作成部、２１…メッセージ作成部、２２…ログ再送制御部、５０…ログアップロードサーバ、７０…ルータ、９０…プログラム提供システム、１０１…ＣＰＵ、１０４…フラッシュメモリ、１０５…ＳＳＤ、１０６…記録メディア、１０７…メディアドライブ、１０８…操作ボタン、１０９…電源スイッチ、１１２…ＣＭＯＳ、１１４…マイク、１１５…スピーカ、１１０…バスライン、１２０…ディスプレイ、２０２…ＲＯＭ、２０３…ＲＡＭ、２０４…ＨＤ、２０５…ＨＤＤ、２１１…キーボード、２１２…マウス、２１４…ＣＤ−ＲＯＭドライブ、２１３…ＣＤＲＯＭ、５０２…端末認証部、５０３…状態管理部、５０４…端末抽出部、５０５…端末状態取得部、５１１…ログ情報抽出部、５５２…ログ情報管理部、１０００…記憶部、５５０１…ログ管理ＤＢ

特開平１０−０４０１９１号公報

Claims (9)

1. ネットワークを介してサーバに接続する通信端末装置であって、
   前記ネットワークを介して通信情報をサーバへ送信する送信手段と、
   前記サーバへの前記通信情報のある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間を算出する再送信待ち時間算出手段と、
   前記再送信待ち時間が経過した場合に、前記送信手段により前記サーバへ前記通信情報を再送信させる制御手段と、を備え、
   前記再送信待ち時間算出手段は、
   前回の再送信待ち時間よりも次回の再送信待ち時間を長く算出することを特徴とする通信端末装置。
2. 前記再送信待ち時間算出手段は、
   前記再送信を失敗した回数、前記再送信待ち時間を長く算出する割合を表す重み値に基づいて、前記再送信待ち時間を算出することを特徴とする請求項１記載の通信端末装置。
3. 前記制御手段は、
   前記重み値に基づいて、タイムアウト時間を算出するタイムアウト時間算出手段と、
   前記タイムアウト時間までの間に前記再送信の結果に応じて前記重み値を更新する重み値更新手段と、を備えることを特徴とする請求項１記載の通信端末装置。
4. 前記重み値更新手段は、
   前記再送信が成功した場合に前回の前記重み値よりも次回の重み値を小さな値に更新し、前記再送信が失敗した場合に前回の前記重み値よりも次回の重み値を大きな値に更新することを特徴とする請求項３記載の通信端末装置。
5. 前記重み値更新手段は、
   前記更新後の重み値を所定の範囲内に制限することを特徴とする請求項４記載の通信端末装置。
6. 前記通信情報は、
   自装置の履歴情報であることを特徴とする請求項１乃至５の何れか１つに記載の通信端末装置。
7. 請求項１乃至６の何れか１つに記載の通信端末装置と、
   前記通信端末装置から前記通信情報を受信する前記サーバと、を備えたことを特徴とする通信システム。
8. ネットワークを介してサーバに接続する通信端末装置における通信方法であって、
   前記ネットワークを介して通信情報をサーバへ送信する送信ステップと、
   前記サーバへの前記通信情報のある送信が失敗した場合に、当該送信から次回の送信までの再送信待ち時間を算出する再送信待ち時間算出ステップと、
   前記再送信待ち時間が経過した場合に、前記送信ステップにより前記サーバへ前記通信情報を再送信させる制御ステップと、を備え、
   前記再送信待ち時間算出ステップは、
   前回の再送信待ち時間よりも次回の再送信待ち時間を長く算出することを特徴とする通信方法。
9. 請求項８記載の各ステップをプロセッサに実行させることを特徴とするプログラム。

Images