(57)【要約】【課題】  携帯端末からウェブサーバにデータを送信する際に、ネットワークに障害が発生したとしてもユーザに意識させることなくキャッシングすることが可能であり、さらにネットワークの状態変化に応じてデータ再送信処理、再送信において発生したアプリケーション上の問題のユーザへの通知を行う仕組みを提供する。【解決手段】  携帯端末のウェブブラウザにおいてユーザが入力したデータをウェブアプリケーションサーバに送信するために、ネットワーク状態が正常である否か判定し、正常である場合には、ウェブアプリケーションサーバに送信し、障害である場合には、データを未送信データ記憶手段に登録させる。未送信データ記憶手段に登録された未送信データに対して、ネットワークの状態が正常であり、障害から回復した場合には、送信する。その際、アプリケーションとしてのエラーが発生する可能性もあるが、それらについてはユーザに警告する。【選択図】図５
2014089631.tif 000002
【特許請求の範囲】
【請求項１】
ウェブアプリケーションサーバとネットワークを介して接続可能な携帯端末であって、
前記携帯端末のウェブブラウザにおいてユーザが入力したデータを受け付ける入力受付手段と、
前記入力受付手段により受け付けたデータを、前記ウェブアプリケーションサーバに送信するためにネットワークの状態が正常であるか障害があるかを判定するネットワーク状態判定手段と、
前記ネットワーク状態判定手段によりネットワークの状態が正常であると判定された場合には、前記データを前記ウェブアプリケーションサーバに送信するデータ送信手段と、
前記データ送信手段により送信された前記データに対する前記ウェブアプリケーションサーバにおけるアプリケーションの処理が成功したか否かを、該ウェブアプリケーションサーバから受け付ける処理結果受付手段と、
前記処理結果受付手段により受け付けた結果が成功か否かを判定する処理結果判定手段と、
前記ネットワーク状態判定手段によりネットワークの状態が障害であると判定された場合、または前記処理結果判定手段により、前記アプリケーションの処理が成功ではなかったと判定された場合、前記データを未送信データ記憶手段に登録させる未送信データ登録手段と、
前記未送信データ記憶手段に登録された前記データを取得するデータ取得手段と、
を備え、
前記データ送信手段は、更に、
前記未送信データ記憶手段に登録された未送信の前記データに対して、前記ネットワーク状態判定手段によりネットワークの状態が正常であり、障害から回復したと判定された場合には、前記データ取得手段により未送信の該データを取得し、送信することを特徴とする携帯端末。
【請求項２】
前記処理結果判定手段により処理が成功した場合には、前記未送信データ記憶手段に登録された前記データを削除する未送信データ削除手段と、
を更に備え、
前記入力受付手段は、更に、
前記処理結果判定手段により処理が成功ではなかった場合には、ユーザに前記データの再編集をさせ、該再編集させた結果を入力として受け付けることを特徴とする請求項１に記載の携帯端末。
【請求項３】
前記未送信データ記憶手段に登録された未送信の前記データに対して、所定の時間または時刻の経過に基づき、前記携帯端末のユーザに、該データの前記未送信データ記憶手段への登録を継続するか否かの確認を通知する継続登録確認通知手段と、
前記未送信データ削除手段は、更に、
前記継続登録確認通知手段により確認したユーザの確認結果が、前記データの登録を継続しないものである場合には、該データを前記未送信データ記憶手段から削除するものであることを特徴とするたは請求項２に記載の携帯端末。
【請求項４】
ウェブアプリケーションサーバとネットワークを介して接続可能な携帯端末の制御方法であって、
入力受付手段が、前記携帯端末のウェブブラウザにおいてユーザが入力したデータを受け付ける入力受付ステップと、
ネットワーク状態判定手段が、前記入力受付ステップにより受け付けたデータを、前記ウェブアプリケーションサーバに送信するためにネットワークの状態が正常であるか障害があるかを判定するネットワーク状態判定ステップと、
データ送信手段が、前記ネットワーク状態判定ステップによりネットワークの状態が正常であると判定された場合には、前記データを前記ウェブアプリケーションサーバに送信するデータ送信ステップと、
処理結果受付手段が、前記データ送信ステップにより送信された前記データに対する前記ウェブアプリケーションサーバにおけるアプリケーションの処理が成功したか否かを、該ウェブアプリケーションサーバから受け付ける処理結果受付ステップと、
処理結果判定手段が、前記処理結果受付ステップにより受け付けた結果が成功か否かを判定する処理結果判定ステップと、
未送信データ登録手段が、前記ネットワーク状態判定ステップによりネットワークの状態が障害であると判定された場合、または前記処理結果判定ステップにより、前記アプリケーションの処理が成功ではなかったと判定された場合、前記データを未送信データ記憶手段に登録させる未送信データ登録ステップと、
データ取得手段が、前記未送信データ記憶手段に登録された前記データを取得するデータ取得ステップと、
を備え、
前記データ送信ステップは、更に、
前記未送信データ記憶手段に登録された未送信の前記データに対して、前記ネットワーク状態判定ステップによりネットワークの状態が正常であり、障害から回復したと判定された場合には、前記データ取得ステップにより未送信の該データを取得し、送信することを特徴とする携帯端末の制御方法。
【請求項５】
コンピュータを、ウェブアプリケーションサーバとネットワークを介して接続可能な携帯端末として機能させるためのプログラムであって、
前記コンピュータを、
前記携帯端末のウェブブラウザにおいてユーザが入力したデータを受け付ける入力受付手段、
前記入力受付手段により受け付けたデータを、前記ウェブアプリケーションサーバに送信するためにネットワークの状態が正常であるか障害があるかを判定するネットワーク状態判定手段、
前記ネットワーク状態判定手段によりネットワークの状態が正常であると判定された場合には、前記データを前記ウェブアプリケーションサーバに送信するデータ送信手段、
前記データ送信手段により送信された前記データに対する前記ウェブアプリケーションサーバにおけるアプリケーションの処理が成功したか否かを、該ウェブアプリケーションサーバから受け付ける処理結果受付手段、
前記処理結果受付手段により受け付けた結果が成功か否かを判定する処理結果判定手段、
前記ネットワーク状態判定手段によりネットワークの状態が障害であると判定された場合、または前記処理結果判定手段により、前記アプリケーションの処理が成功ではなかったと判定された場合、前記データを未送信データ記憶手段に登録させる未送信データ登録手段、
前記未送信データ記憶手段に登録された前記データを取得するデータ取得手段、
として機能させ、
前記データ送信手段は、更に、
前記未送信データ記憶手段に登録された未送信の前記データに対して、前記ネットワーク状態判定手段によりネットワークの状態が正常であり、障害から回復したと判定された場合には、前記データ取得手段により未送信の該データを取得し、送信することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブブラウザで入力したデータをウェブアプリケーションサーバ（以下ウェブサーバと略す）に送信する際に、ネットワークに障害がある場合のデータ喪失を防止する技術に関する。
【背景技術】
【０００２】
情報処理装置（パーソナルコンピュータ、携帯端末を含む）のウェブブラウザ（以下ブラウザと略す）において表示されたフォームに入力を行い、ウェブサーバへ送信（Ｓｕｂｍｉｔ）を行う処理において問題が発生する場合がある。例えば、入力データに不備があり、ウェブサーバが正しく処理が行えない場合であるが、このような場合はせっかく入力したフォームデータを無駄にしないようにするため、ウェブサーバ側でユーザが入力したデータを復元した画面を戻すようにする方法がある。
【０００３】
しかしながら、ネットワーク接続不良によりウェブサーバへ送信できない場合は、前述のウェブサーバ側の復元された画面を戻すことはできないため、ブラウザのキャッシュに頼るなどの方法によることになる。
【０００４】
前述のことは、企業内のＬＡＮでパーソナルコンピュータ上のブラウザから入力を行い、ウェブサーバにデータを送信する場合のように、ネットワークに障害が発生する可能性が低い場合はあまり問題とはならない。仮に一時的に障害が起こってもリトライするなどして、比較的短時間で問題を回避できる可能性が高いからである。また、画面が広いパーソナルコンピュータなどの場合には、データを入力したブラウザをアイコン化（最小化）するなどして、それ以降の業務には差し支えないようにしてデータを残す（ブラウザのキャッシュを利用する）ことが容易だからである。
【０００５】
しかしながら、例えば携帯端末（モバイル端末）のブラウザ使用する場合のように、ネットワークの障害（電波が届かないなどによる断線を含む）が発生する確率が高い場合には、大きな問題となる。
【０００６】
すなわち、前述のパーソナルコンピュータのように、ネットワークがつながるまでブラウザを閉じずに残し、入力したデータをブラウザのキャッシュから消さないようにすることは現実的ではない。
【０００７】
特許文献１では、アプリケーションサーバからイベント（データ等）を受け取り、他のアプリケーションサーバに送信する際に、ブローカを介するような構成となっている。
【０００８】
ブローカは、アプリケーションサーバがから送信されたイベントをローカルのキューに格納し、ネットワークの断線の状況を確認して接続状態でアクティブ（イベントを送信可能）であるなら送信する技術を提供する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１１−７６６０３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しなしながら、特許文献１では、ネットワークの接続状態に問題がない場合であっても、一度ローカルキューに格納するため、送信の頻度が高い場合にはブローカの負荷が高くなる。特に特許文献１においては、アプリケーションとブローカの両方が携帯端末で動作する技術について説明している。しかし近年、携帯端末をビジネスマンが外出先で利用し、会社のウェブサーバに対して大量のデータを送信する場合がある。この場合、前述のように携帯端末の負荷は非常に高くなるという問題があった。
【００１１】
本発明は、上記問題に鑑み、携帯端末からウェブサーバにデータを送信する際に、ネットワークに障害が発生したとしてもユーザに意識させることなくキャッシングすることが可能であり、さらにネットワークの状態変化に応じてデータ再送信処理、再送信において発生したアプリケーション上の問題のユーザへの通知を行う仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、ウェブアプリケーションサーバとネットワークを介して接続可能な携帯端末であって、前記携帯端末のウェブブラウザにおいてユーザが入力したデータを受け付ける入力受付手段と、前記入力受付手段により受け付けたデータを、前記ウェブアプリケーションサーバに送信するためにネットワークの状態が正常であるか障害があるかを判定するネットワーク状態判定手段と、前記ネットワーク状態判定手段によりネットワークの状態が正常であると判定された場合には、前記データを前記ウェブアプリケーションサーバに送信するデータ送信手段と、前記データ送信手段により送信された前記データに対する前記ウェブアプリケーションサーバにおけるアプリケーションの処理が成功したか否かを、該ウェブアプリケーションサーバから受け付ける処理結果受付手段と、前記処理結果受付手段により受け付けた結果が成功か否かを判定する処理結果判定手段と、前記ネットワーク状態判定手段によりネットワークの状態が障害であると判定された場合、または前記処理結果判定手段により、前記アプリケーションの処理が成功ではなかったと判定された場合、前記データを未送信データ記憶手段に登録させる未送信データ登録手段と、前記未送信データ記憶手段に登録された前記データを取得するデータ取得手段と、を備え、前記データ送信手段は、更に、前記未送信データ記憶手段に登録された未送信の前記データに対して、前記ネットワーク状態判定手段によりネットワークの状態が正常であり、障害から回復したと判定された場合には、前記データ取得手段により未送信の該データを取得し、送信することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、携帯端末からウェブサーバにデータを送信する際に、ネットワークに障害が発生したとしてもユーザに意識させることなくキャッシングすることが可能であり、さらにネットワークの状態変化に応じてデータ再送信処理、再送信において発生したアプリケーション上の問題のユーザへの通知を行う仕組みを提供することを可能とする。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係わるシステム構成の一例を示す図である。
【図２】本発明の実施形態に係わる携帯端末のハードウェア構成の一例を示すブロック図である。
【図３】本発明の実施形態に係わる携帯端末のＧＵＩ（グラフィカルユーザインタフェース）の一例を示す図である。
【図４】本発明の実施形態に係わる未送信のデータを格納するデータ構成の一例を示す図である。
【図５】本発明の実施形態に係わるユーザが入力したデータに対して、ネットワークの状態をチェックして送信を行う処理の一例を示すフローチャートである。
【図６】本発明の実施形態に係る未送信のデータの保存と再送のリトライを行う処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を、図面を参照して詳細に説明する。
【００１６】
図１は、本発明の実施形態に係わるシステム構成の一例を示す図である。
【００１７】
本実施の形態におけるシステム構成では、携帯端末１０１が、ウェブサーバ１０２と、ネットワーク１０３（社内で接続されるＬＡＮなど）、１０４（社外で接続されるインターネットなど）を介して接続されている。
【００１８】
図１では、携帯端末１０１を外出先において、社内に構築されたウェブサーバ１０２に接続して使用する例を示しているが、これはあくまで一例である。ウェブサーバ１０２は、他社のインターネットサービスであってもよいし、携帯端末１０１は、社内の無線通信などにより、同じ社内のウェブサーバ１０２に接続してもよい。また、携帯端末１０１は、インターネットだけではなく、一部において公衆回線（携帯電話のキャリアの回線）を介してウェブサーバ１０２にアクセスするものであってもよい。
【００１９】
携帯端末１０１は、ユーザの操作をウェブブラウザ（ブラウザ）によって受け付け、ウェブサーバ１０２のウェブアプリケーションにアクセスし、ブラウザ上にテキスト入力フィールド、ラジオボタンなどを表示させる（ＨＴＭＬ５など）。また、ユーザの入力操作を受け付け、ユーザの入力をウェブサーバ１０２に送信する。
【００２０】
ウェブサーバ１０２は、前述の送信結果を受信してウェブアプリケーションにおけるロジックに従って処理する。また処理に応じて、処理結果を携帯端末１０１に送り返し、携帯端末１０１のブラウザで表示させる場合がある。
【００２１】
図２は、本発明の実施形態に係わる携帯端末１０１のハードウェア構成の一例を示すブロック図である。その他の情報処理装置、すなわちウェブサーバ１０２に対しても適用可能である。
【００２２】
図２に示すように、携帯端末１０１は、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０２、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、通信Ｉ／Ｆコントローラ２０８等が接続された構成を採る。
【００２３】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２４】
また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、各サーバあるいは各ＰＣが実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。また、本発明を実施するために必要な情報が記憶されている。なお外部メモリはデータベースであってもよい。
【００２５】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。
【００２６】
また、入力コントローラ２０５は、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。
【００２７】
ビデオコントローラ２０６は、ディスプレイ２１０等の表示器への表示を制御する。尚、表示器は液晶ディスプレイ等の表示器でもよい。これらは、必要に応じて管理者が使用する。
【００２８】
メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、あるいは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｏｃｉａｔｉｏｎ）カードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００２９】
通信Ｉ／Ｆコントローラ２０８は、ネットワーク１０３、１０４を介して外部機器と接続・通信し、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を用いた通信等が可能である。
【００３０】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上に表示することが可能である。また、ＣＰＵ２０１は、ディスプレイ２１０上のマウスカーソル（図示しない）等によるユーザ指示を可能とする。
【００３１】
本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイルおよび各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明についても後述する。
【００３２】
図３は、本発明の実施形態に係る携帯端末のＧＵＩ（グラフィカルユーザインタフェース）の一例を示す図である。ＧＵＩとしてはブラウザを前提として、ウェブサーバ１０２から送られてきた帳票に入力し、データの送受信を行う例を処理順に従って示す。
【００３３】
携帯端末１０１ａの表示画面は、在庫管理システムの帳票のうち、在庫引き当て画面を表示させ、ユーザからの入力受け付けが完了した状態を示している。個数入力フィールド３０１ａには、数値で「２５」が入力されている。
【００３４】
ユーザが送信ボタン３０２を押下すると、受注ＩＤ、商品ＩＤ、個数、その他本画面には表示されていないが、入力したデータがあればウェブサーバ１０２に送信（Ｓｕｂｍｉｔ）する。また、ユーザが終了ボタン３０３を押下すると、帳票への入力を終了し、他の画面（例えばアプリケーションのトップ画面）に戻るなどの動作をする。
【００３５】
携帯端末１０１ｂの表示画面は、携帯端末１０１ａにおいて送信ボタン３０２を押下した結果として「ネットワークに障害が発生」しているため、データ送信ができない旨のメッセージが表示された状態を示している。携帯端末１０１は、ユーザが様々な場所（例えば電車の中）で使用可能であるため、ネットワークが接続不可能であるなど、他の何らかの事情によりネットワークの断線が起こっている（ネットワーク障害）頻度が高い。（例えば電車を降りた後）ネットワークの使用が可能となったら自動的に再送信するように、格納する旨を表示時する。それによりユーザは携帯端末１０１において、他の作業を行うことができるようになる。
【００３６】
従来の技術では、ウェブブラウザを閉じてしまうと、ユーザが入力したデータは格納されずなくなってしまう。また、仮に格納する仕組みをアプリケーション側で組み込んだとしても、ユーザはある程度時間が経過した後で、データの格納先を探し、格納先からデータを取得し再度データの送信を試みなければならない。
【００３７】
次に、携帯端末１０１ｃは、前述の通りネットワークの使用が可能となり、自動的に格納したデータを取得して再送信した際の表示画面である。
【００３８】
３０５のメッセージは（ネットワークの状態に問題はなくデータの送信はできたものの）、ウェブサーバ１０２側のエラーが発生した旨の説明である。すなわち、例えば３０１ａで指定した在庫引き当ての個数、２５個に対して、在庫管理システムのデータベースを確認した結果、数量が足りない等が原因で、在庫管理システムとして「正常に動作した際に返信されるエラー」がある。日時（３０６）は、受注ＩＤ「０００８０」として、「２０１２／１０／１３  １１：２１」に、最初に送信したデータであることを示している。また、日時（３０７）は、格納されたデータが後述された所定の時刻を経過した場合に、ユーザに格納されたデータを削除せず、ネットワークの確認を継続するかを確認した最終時刻が「２０１２／１０／１３  １１：３１」であることを示す。
【００３９】
ユーザから「はい」のボタン（３０８）の押下を受け付けると、携帯端末１０１は、１０１ａの画面に戻りユーザに編集を促す（後述する１０１ｄ）。「いいえ」のボタン（３０９）の押下を受け付けると、携帯端末１０１は、他の画面（例えばアプリケーションのトップ画面）に戻るなどの動作をする。
【００４０】
携帯端末１０１ｄの表示画面は、ウェブサーバ１０２側でのアプリケーション（前述の例では、在庫管理システム）から返されたエラー情報に基づき、個数入力フィールド３０１ｂのように表示形態を変えて（３０１ｂでは２重枠、その他背景の色変更、文字のフォントや色の変更）、値の変更をユーザに促す。
【００４１】
以上で、図３の表示画面である１０１ａから１０１ｄを用いた、携帯端末１０１における処理の説明を完了する。
【００４２】
図４は、本発明の実施形態に係わる未送信のデータを格納するデータ構成の一例を示す図である。携帯端末１０１においてユーザが入力したデータの送信が、ネットワークの障害により失敗した場合に、そのデータを一時的に格納するためのローカルストレージのデータ構成（未送信データ記憶部４００）である。
【００４３】
未送信データ記憶部４００は、（格納するデータの）ＩＤ４０１、初期送信日時４０２、最終再送信試行日時４０３、経過時間４０４、データ格納先４０５等のデータ項目から構成されるデータベースである。
【００４４】
ＩＤ４０１は、未送信データ記憶部４００の１つのレコードおよびそのレコードに１対１で対応する後述する格納データ４１０を特定するための識別子である。
【００４５】
初期送信日時４０２は、前述の格納データ４１０を最初に携帯端末１０１からウェブサーバ１０２に送信した日時である。すなわち、ユーザが携帯端末１０１において、前記の格納データ４１０を初めて送信し、ネットワークの障害のためにエラーとなった場合に格納したときの日時である。
【００４６】
最終再送信試行日時４０３は、格納データ４１０を携帯端末１０１からウェブサーバ１０２に送信しようとネットワークの状態チェックした日時である。すなわち、初期送信日時４０２において格納データ４１０を未送信データ記憶部４００に格納した後、ネットワークの状態を自動的に確認する処理を、送信可能になるまで繰り返す。また、送信可能になったとしてもアプリケーションのエラーとなり格納されたままの可能性がある。その時の送信日時が最終再送信試行日時４０３に格納される。
【００４７】
経過時間４０４は、前述のように自動的に送信を繰り返す時間のうち、最初に送信または送信試行してから最後に送信試行するまでの時間間隔である。経過時間４０４が所定の時間間隔を超えると、図６のフローチャートの処理について後述するように、待機（格納データ４１０を未送信データ記憶部４００に格納したままの状態）を継続するか否かをユーザに確認する。
【００４８】
前述の「所定の時間」とは、不図示の記憶部に登録されている。この登録は、全ての格納データ４１０に同一のものであってもよいし、また異なるものであってもよい。
【００４９】
また前述では、「所定の時間間隔」として説明したが、「所定の時刻」であってもよい。「所定の時刻」である場合には、経過時間４０４はデータ項目として不要である。
【００５０】
また、それぞれの格納データ４１０について「所定の時間間隔」の後でデータが格納されたままの場合に、格納したままの状態にするか否かをユーザに問い合わせる。待機を継続する場合には、経過時間４０４をリセットする。すなわち、一度リセットした後に改めて「所定の時間間隔」を計測する。
【００５１】
データ格納先４０５は、送信できなかったデータを格納している具体的な場所を示す。ローカルストレージが任意のバイナリデータを格納可能な場合には、データ格納先４０５に格納データ４１０の実体を格納してもよい。また、後述するように格納データは、実際には１つのファイルに格納されており、ＩＤ４０１に基づいて１つの格納データ４１０の格納位置を特定するようにしてもよい。
【００５２】
格納データ４１０は、１つのデータを格納の実体である。例えば、各々の格納データ４１０をファイルとして、または前述の通り１つのファイルにおけるＩＤ４０１に対応する一部の領域などである。あるいは前述のファイルの代わりにデータベースのバイナリデータとして登録してもよい。
【００５３】
ファイルに格納する例としては、入力データ毎に、「データ名」と「値」を対にして登録する構成がある。データベースを用いる例としては、「キーバリュー形式」のストレージを用いることができる。あるいは、ＸＭＬなどのマークアップ言語の形式でタグ名と、タグに対応する値として格納するなどのデータ構成も可能である。あるいは、リレーショナルデータベースを用いて、表形式（テーブル形式）で格納形式を構成してもよい。その他、任意の形式が可能である。
【００５４】
次に図５、図６のフローチャートを用いて、アプリケーションの帳票に入力されたデータの携帯端末１０１からウェブサーバ１０２への送信処理について説明する。
【００５５】
図５は、本発明の実施形態に係わるユーザが入力したデータに対して、ネットワークの状態をチェックして送信を行う処理の一例を示すフローチャートである。図５におけるＳ５０１からＳ５１２の各ステップは、携帯端末１０１のＣＰＵ２０１によって、またＳ５２１からＳ５２５の各ステップは、ウェブサーバ１０２によって実行される。
【００５６】
Ｓ５０１においては、携帯端末１０１がウェブサーバ１０２から受信したアプリケーションの帳票画面（例えば図３の１０１ａ）における、ユーザのデータ入力を受け付ける（入力受付部）。
【００５７】
Ｓ５０２においては、ユーザの帳票に対する操作を受け付ける。図３の例では、送信ボタン３０２、終了ボタン３０３のユーザによる押下を受け付ける。
【００５８】
Ｓ５０３においては、Ｓ５０２におけるユーザの操作が「終了」ボタンの押下であるか否かを判定する。「終了」ボタンの押下である場合（ＹＥＳの場合）には、フローチャートを終了する。そうではない場合、具体的には「送信」ボタンの押下である場合（ＮＯの場合）には、Ｓ５０４に進む。
【００５９】
Ｓ５０４においては、入力データを携帯端末１０１からウェブサーバ１０２に送信するためのネットワーク１０３、１０４が送信可能な状態（正常な状態）であるか否かを確認する（ネットワーク状態判定部）。
【００６０】
Ｓ５０５においては、Ｓ５０４における判定結果が「正常」である場合（ＹＥＳの場合）には、Ｓ５０６に進む。障害がある場合（ＮＯの場合）には、Ｓ５０８に進む。
【００６１】
Ｓ５０６においては、Ｓ５０１で受け付けたアプリケーションの帳票に入力されたデータを、ウェブサーバ１０２に送信する。
【００６２】
Ｓ５２１においては、Ｓ５０６において携帯端末１０１から送信されたデータを受信する。
【００６３】
Ｓ５２２においては、アプリケーションによるデータの処理を行う。具体的には、Ｓ５２１において受信したデータに基づいて、対応するアプリケーション及びアプリケーションの機能毎に処理される。
【００６４】
Ｓ５２３においては、アプリケーションによるデータの処理が成功か否かを判定する（処理結果判定部）。成功の場合（ＹＥＳの場合）には、Ｓ５２４に進む。エラーの場合（ＮＯの場合）には、Ｓ５２５に進む。
【００６５】
Ｓ５２４においては、アプリケーションの処理が成功したことを、携帯端末１０１に通知する。
【００６６】
Ｓ５０７においては、ウェブサーバ１０２からアプリケーションの処理が成功した旨を受け付ける（処理結果受付部）。その後、データが未送信データ記憶部に格納されていたデータである場合には、削除し（未送信データ削除部）、図５のフローチャートの処理を完了する。
【００６７】
Ｓ５２５においては、エラーであることを１０１に通知する。
【００６８】
Ｓ５１０においては、ウェブサーバ１０２からアプリケーションの処理がエラーである旨を受け付ける（処理結果受付部）。
また図５のフローチャートでは、ウェブサーバ１０２側において、Ｓ５２３で判定した処理結果を、Ｓ５２４、Ｓ５２５により通知、携帯端末１０１のＳ５０７、Ｓ５１０で受け付けている。しかし、処理結果を携帯端末１０１で受け付けてから、処理結果の内容により、Ｓ５０７、Ｓ５１０のいずれに進むかの判定をしてもよい。
【００６９】
Ｓ５１１においては、エラーである旨を携帯端末１０１の画面に表示し、そのあとの対応が「Ｓ５０１で入力したデータの再編集」であるか否かをユーザに確認する。具体的には、例えば図３の１０１ｃの画面を表示し、「はい」ボタン（３０８）または「いいえ」ボタン（３０９）の押下を受け付ける。
【００７０】
Ｓ５１２においては、前述のユーザへの確認結果が「再編集」であるか否かを判定する。確認結果が再編集である場合（ＹＥＳの場合）には、Ｓ５０１に戻る。具体的には、図３の画面（１０１ｄ）のようにエラーが発生した入力フィールドの表示形態を変更し、ユーザが再編集すべき項目を分かりやすく表示する。この画面は、ウェブサーバ１０２のアプリケーションからエラーの通知とともに受け付けてもよい。エラーの項目を特定する情報を受け付け、携帯端末１０１のブラウザにおいて表示形態を変更してもよい。すなわち表示形態の変更をするための方式は問わない。確認結果が再編集ではない場合（ＮＯの場合）には、図５のフローチャートの処理を完了する。
【００７１】
Ｓ５０８は、ネットワークが正常ではない場合に処理されるサブルーチンである。詳細は図６で説明するが、ネットワークの障害のために一度、ユーザの入力データを前記の未送信データ記憶部４００に格納し、再送信のための制御を行う。図６の処理結果として「再送信」をする場合（ＹＥＳの場合）には、Ｓ５０６に進む（既に説明）。「再送信」しない、すなわち「終了」（「待機状態の終了」）の場合（ＮＯの場合）には、図５のフローチャートの処理を完了する。
以上で、図５のフローチャートの処理の説明を完了する。
【００７２】
図６は、本発明の実施形態に係る未送信のデータの保存と再送のリトライを行う処理の一例を示すフローチャートである。図６における各ステップは、携帯端末１０１のＣＰＵ２０１によって実行される。また図６のフローチャートの処理は、図５において、ブラウザにおけるユーザの入力データをウェブサーバ１０２に送信する前にネットワークの状態を確認し、正常ではない（障害がある）と判定される場合に実行される。
【００７３】
Ｓ６０１においては、未送信（ネットワークの障害により送信不可）のデータを、ローカルストレージに格納する（未送信データ登録部）。具体的には図４で説明したデータ構成などによる携帯端末１０１におけるデータベースに格納する。また、ローカルストレージの例としては、ＨＴＭＬ５のＲＦＣ仕様で規定されている永続ストレージなどがあるため、その機能を使用してもよい。
【００７４】
Ｓ６０２においては、格納したデータの経過時間を初期化する。具体的には、格納データ４１０に対応する図４の経過時間４０４を０にする。
【００７５】
Ｓ６０３においては、ネットワークの状態が「送信不可」の状態から「正常」に回復しているかを定期的にチェックする。
【００７６】
Ｓ６０４においては、前述でチェックしたネットワークの状態が、正常であるか否かを判定する。正常である場合（ＹＥＳの場合）には、Ｓ６０５に進む。送信不可のままの場合（ＮＯの場合）には、Ｓ６０７に進む。
【００７７】
Ｓ６０５においては、ローカルストレージに格納した格納データ４１０を取得する（データ取得部）。
【００７８】
Ｓ６０６においては、格納データ４１０を「再送信」するよう指定して、図６のフローチャートを完了する。
【００７９】
Ｓ６０７においては、格納されたデータを未送信データ記憶手段に格納したままにするか否かをユーザに問い合わせるため、経過時間または時刻を確認する。具体的には、各格納データに対して図４の経過時間４０４を取得し、前述の「所定の時間間隔」と比較し経過しているかどうか算出する。または、前述の通り「所定の時刻」により問い合わせを判断する場合には、現在時刻（携帯端末１０１のシステム時刻など）を経過しているかどうか算出する。
【００８０】
Ｓ６０８においては、Ｓ６０７において「所定の時間間隔」または「所定の時刻」を経過しているか算出された結果に基づき、経過しているか否かを判定する。経過している場合（ＹＥＳの場合）には、Ｓ６０９に進む。経過していない場合（ＮＯの場合）は、Ｓ６０３に進む。
【００８１】
Ｓ６０９においては、携帯端末１０１のユーザから、格納されたデータの再送信の待機状態を継続するか否かの確認を通知し、結果を受け付ける（継続登録確認通知部）。具体的には、図３の１０１ｄにおいて、「送信」ボタン（３０２）または「終了」ボタン（３０３）の押下を受け付ける。
【００８２】
Ｓ６１０においては、格納データ４１０に対して、未送信データ記憶部４００に記憶したまま再送信の待機状態を継続するか否かを判定する。具体的には、Ｓ６０９で受け付けたボタンが、「終了」ボタン（３０３）の場合（ＮＯの場合）には、Ｓ６１１に進む。「送信」ボタン（３０２）の場合（ＹＥＳの場合）には、Ｓ６１３に進む。
【００８３】
Ｓ６１１においては、未送信データ記憶部４００に記憶された格納データ４１０を削除する（未送信データ削除部）。
【００８４】
Ｓ６１２においては、「待機状態の終了」を指定して図６のフローチャートを完了する。
【００８５】
Ｓ６１３においては、図４の経過時間をリセット（０）にして、Ｓ６１３に進む。
【００８６】
前述の説明では、図６のフローチャートの処理を、図５のＳ５０８に対応するサブルーチンとした。しかし、Ｓ５０８においては図６のフローチャートの処理を別のプロセス（子プロセス）として起動のみしてもよい。これにより次のステップ（Ｓ５０６、Ｓ５０９）には進まずにいったんフローチャートの処理を完了してユーザが他の作業を行えるようにし、図６のフローチャートから「再送信」、「待機状態の終了」が返された段階で、続く処理が再開されるように実装されてもよい。
【００８７】
以上、図５、図６で説明したフローチャートの処理により、ネットワークの障害がある場合でも、ユーザが明示的に携帯端末１０１におけるデータ格納を指示せずに、作業中のブラウザ（現在のアプリケーションに対応）を終了、他の作業を開始、などが可能になるといった効果を得られる。
【００８８】
また、前述の方法によって、ユーザがブラウザに入力したデータ、特に業務用のアプリケーションの場合には、大量の入力データを喪失することなく、ネットワークが回復するまで該データを格納しておくことが可能となる。
【００８９】
また、未送信データ記憶部４００の格納データ４１０は、ネットワークの状態が回復した時点で、ユーザに意識させることが可能と言った効果を得られる。
【００９０】
さらに、ウェブサーバ１０２に送信し、ウェブアプリケーションで処理した結果がエラーとなった場合には、ユーザに再編集を促すことが可能になるといった効果が得られる。
【００９１】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【００９２】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【００９３】
また、本発明におけるプログラムは、図５、図６に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図５、図６の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図５、図６の各装置の処理方法ごとのプログラムであってもよい。
【００９４】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【００９５】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【００９６】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。
【００９７】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００９８】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００９９】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。  さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１００】
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１０１】
１０１  携帯端末
１０２  ウェブサーバ
１０３  ネットワーク
１０４  ネットワーク
４０１  ＩＤ
４０２  初期送信日時
４０３  最終再送信試行日時
４０４  経過時間
４０５  データ格納先
４１０  格納データ
【図１】
2014089631.tif 000003
【図２】
2014089631.tif 000004
【図３】
2014089631.tif 000005
【図４】
2014089631.tif 000006
【図５】
2014089631.tif 000007
【図６】
2014089631.tif 000008