JPWO2014002138A1 - 携帯端末管理サーバ、および携帯端末管理プログラム - Google Patents

Abstract

携帯通信端末に帳票に関する情報を提供する業務システムにおいて、不正ライセンスによる不正行為を防止し、システム管理者及びユーザを保護する。ＥＲＰが稼動する携帯端末管理サーバ１０が、サーバ管理者ＺからユーザＸに対して発行されたユーザライセンス情報に基づいて携帯端末３１に対してログインを許可するか否か判定し、ログイン状態の携帯端末３１からの処理要求に応じて統合基幹業務システム１００に対して処理要求を行う場合には、サーバ管理者Ｚに対して発行されたライセンス情報であるサーバライセンス情報であって、ユーザライセンス情報を一意に特定可能なサーバライセンス情報を提示してその処理要求を行う。

Description

本発明は、ＥＲＰが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する携帯端末管理サーバ、および携帯端末管理サーバに搭載される携帯端末管理プログラムに関する。

従来から、企業における基幹業務システムを構築するためのパッケージソフトウェアとして、ＥＲＰ（Enterprise Resource Planning）と呼ばれるものが主流となっていた。このＥＲＰが搭載された基幹業務システム（統合基幹業務システム、ＥＲＰシステム）では、リレーショナルデータベース上で構築されることが多くなってきており、業務処理に主眼をおいたアプリケーションプログラムの設計がなされることが多く、帳票出力には主眼が置かれずに運用されることが多い。

このような状況の下、大量の業務データを高速に処理し、様々な切り口で業務データを分析し、帳票出力することを目的として、基幹業務システムの補完的な役割を担う様々なデータウェアハウスシステムが提供されるようになった（特許文献１参照）。

このような帳票出力を目的とする基幹情報管理システムにおいて、携帯通信端末（携帯端末）に対して帳票などの情報を提供するものが提案されている（特許文献２−３参照）。

特開２００２―３１２２０８号公報 特開２００３―３２３５８２号公報 特開２００７―２００１３６号公報

上記のような携帯通信端末に帳票などの情報を提供する基幹情報管理システムにおいては、外出先や移動中でも情報を取得することが可能となるという利便性は有しているが、情報漏えいの危険性が高まるという問題があった。従って、携帯通信端末に帳票などの情報を提供する基幹情報管理システムにおいては、その安全性の高いものが求められている。

上記のような基幹情報管理システムでは、一般に、ユーザ側にライセンスを付与することとし、ライセンシーのみにシステムの利用を認めることとしている。このように、上記のような基幹情報管理システムでは、ライセンスにより登録ユーザであるか否かの管理することとしているが、例えば、１ライセンスを複数ユーザで使用するといった不正がなされる可能性があるという問題があった。このような不正がなされた場合には、システム管理者にとって多大な不利益が生じることは言うまでもないが、不正ユーザにより使用されることとなるため、登録ユーザの登録データ内に不正なデータが入ってくるおそれや、登録ユーザの登録データが不正にダウンロードされるおそれがあった。よって、システムの安全性を高めるとともに、システム管理者及びユーザを保護する観点から、そのような不正を容易かつ確実に防止するための技術が求められている。

本発明は、上述した問題を解消し、携帯通信端末に帳票に関する情報を提供する業務システム（ＥＲＰシステム）において、不正ライセンスによる不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者及びユーザを保護することができるようにすることを目的とする。

本発明の携帯端末管理サーバは、ＥＲＰが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する携帯端末管理サーバであって、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを前記携帯端末に対して照会可能に記憶するプロセスフローデータ記憶手段と、前記携帯端末管理サーバのサーバ管理者から前記ユーザに対して発行されたライセンス情報であるユーザライセンス情報を提示した前記携帯端末からのログイン要求があったときに、提示されたユーザライセンス情報に基づいて当該携帯端末に対してログインを許可するか否か判定するログイン判定手段と、該ログイン判定手段によってログインを許可すると判定された場合にログイン処理を行うログイン処理手段と、該ログイン処理手段によってログイン処理が実行されたログイン状態の前記携帯端末からの各種処理要求を受け付ける処理要求受付手段と、該処理要求受付手段によって受け付けられた処理要求に応じて、所定処理を実行する処理実行手段とを含み、該処理実行手段は、所定処理として、前記携帯端末管理サーバと通信を行うことにより機能を発揮する統合基幹業務システムに対して処理要求を行う場合には、前記サーバ管理者に対して発行されたライセンス情報であるサーバライセンス情報であって、前記ユーザライセンス情報を一意に特定可能な当該サーバライセンス情報を提示して当該処理要求を行うことを特徴とする。

上記の構成としたことで、携帯端末に帳票に関する情報を提供する業務システムにおいて、不正ライセンスによる不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者及びユーザを保護することができるようになる。

前記ユーザライセンス情報として、前記サーバライセンス情報が用いられ、前記ログイン判定手段は、前記ユーザライセンス情報として提示された前記サーバライセンス情報により前記ユーザが登録ユーザであるか否かを判定することによって、前記携帯端末に対してログインを許可するか否か判定する構成とされていてもよい。

ユーザライセンス情報は、サーバライセンス情報１つに対して１つ発行可能で、サーバライセンス情報の１つに対応付けされたライセンス情報であり、前記ログイン判定手段は、提示された前記ユーザライセンス情報により前記ユーザが登録ユーザであるか否かを判定することによって、前記携帯端末に対してログインを許可するか否か判定し、前記処理実行手段は、前記ログイン判定手段により用いられた前記ユーザライセンス情報と１対１で対応付けされている前記サーバライセンス情報を提示して前記統合基幹業務システムに対して当該処理要求を行う構成とされていてもよい。

前記ライセンス情報として、ユーザＩＤとパスワードとが用いられる構成とされていてもよい。

また、本発明の携帯端末管理プログラムは、ＥＲＰを稼動させ、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する処理を携帯端末管理サーバに実行させる携帯端末管理プログラムであって、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを前記携帯端末に対して照会可能に記憶するプロセスフローデータ記憶手段を備えた前記携帯端末管理サーバに、前記携帯端末管理サーバのサーバ管理者から前記ユーザに対して発行されたライセンス情報であるユーザライセンス情報を提示した前記携帯端末からのログイン要求があったときに、提示されたユーザライセンス情報に基づいて当該携帯端末に対してログインを許可するか否か判定するログイン判定処理と、該ログイン判定処理にてログインを許可すると判定した場合にログイン処理を行うログイン処理実行処理と、該ログイン処理実行処理にてログイン処理が実行されたログイン状態の前記携帯端末からの各種処理要求を受け付ける処理要求受付処理と、該処理要求受付処理にて受け付けた処理要求に応じて、所定処理を実行する所定処理実行処理とを実行させ、該所定処理実行処理では、所定処理として、前記携帯端末管理サーバと通信を行うことにより機能を発揮する統合基幹業務システムに対して処理要求を行う場合に、前記サーバ管理者に対して発行されたライセンス情報であるサーバライセンス情報であって、前記ユーザライセンス情報を一意に特定可能な当該サーバライセンス情報を提示して当該処理要求を行う処理を実行させるためのものである。

本発明によれば、携帯端末に帳票に関する情報を提供する業務システムにおいて、不正ライセンスによる不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者及びユーザを保護することができるようになる。

基幹情報管理システムの構成例を示すブロック図である。 携帯端末管理サーバの構成例を示すブロック図である。 プロセスフローデータの格納状態の例を示す説明図である。 更新条件データの格納状態の例を示す説明図である。 プロセスフローデータ提供処理の例を示すフローチャートである。 データ検索画面の例を示す説明図である。 検索結果画面の例を示す説明図である。 認証処理の例を示すフローチャートである。 認証処理の内容を説明するためのタイムチャートである。 認証処理の他の例を示すフローチャートである。 ユーザ情報の例を示す説明図である。 認証処理の他の内容を説明するためのタイムチャートである。 プロセスフローデータ更新処理の例を示すフローチャートである。 編集画面の例を示す説明図である。 データベース更新処理の例を示すフローチャートである。 帳票出力処理の例を示すフローチャートである。 プロセスフローデータ更新要求入力画面の例を示す説明図である。 更新エラー通知表示画面の例を示す説明図である。 帳票表示画面の例を示す説明図である。 プロセスフローデータの状態に基づく帳票ステータスの遷移について説明するための説明図である。 基幹情報管理システムの他の構成例を示すブロック図である。 認証処理のさらに他の例を示すフローチャートである。 ユーザ情報の他の例を示す説明図である。 認証処理のさらに他の内容を説明するためのタイムチャートである。

以下、本発明の一実施の形態の例について図面を参照して説明する。
図１は、本発明の一実施の形態に係る基幹情報管理システム５００の構成例を示すブロック図である。図１に示すように、基幹情報管理システム５００は、携帯端末管理サーバ１０と、中継機２０と、複数の携帯端末３１〜３Ｎ（Ｎは任意の正の整数）と、統合基幹業務システム１００と、統合基幹業務システム２００と、統合基幹業務システム３００とを含む。携帯端末管理サーバ１０と各携帯端末３１〜３Ｎとは、それぞれ、インターネットなどの通信ネットワーク４０及び中継機２０を介して接続される。携帯端末管理サーバ１０は、統合基幹業務システム１００、統合基幹業務システム２００、統合基幹業務システム３００と、それぞれＬＡＮ（Local Area Network）や専用通信回線などの通信ネットワーク５１，５２，５３を介して接続される。なお、携帯端末同士や統合基幹業務システム同士は、携帯端末管理サーバを介して通信可能な構成としてもよいし、通信不能な構成としてもよい。

統合基幹業務システム１００は、基幹業務サーバ１１０と、データウェアハウスサーバ（ＤＷＨサーバ）１２０と、プロセスフローＤＢ１０１とを含む。統合基幹業務システム２００は、ＤＷＨサーバ２２０と、プロセスフローＤＢ２０１とを含む。統合基幹業務システム３００は、基幹業務サーバ３１０と、プロセスフローＤＢ３０１とを含む。

構成が異なる複数の統合基幹業務システム１００，２００，３００は、必要に応じて（すなわち、それぞれが有する機能に応じて）携帯端末管理サーバ１０と通信（各種情報の送受信）を行うことにより、統合基幹業務システムとしての機能を発揮する。すなわち、基幹情報管理システム５００においては、基幹業務サーバを有さないシステム２００や、ＤＷＨサーバを有さないシステム３００であっても、携帯端末管理サーバ１０との通信を行うことにより、統合基幹業務システムとしての機能を発揮することができる。なお、図示しないが、プロセスフローＤＢを有さないシステムであっても、携帯端末管理サーバ１０にてプロセスフローデータを記憶することにより、統合基幹業務システムとしての機能を発揮することができる。各基幹業務システムが備える基幹業務サーバ等には公知の技術が用いられるため、以下、統合基幹業務システム１００を例にして説明を行う。

基幹業務サーバ１１０とＤＷＨサーバ１２０とは、専用通信回線により接続されているものとする。

基幹業務サーバ１１０は、例えば基幹情報管理システム５００の管理者によって管理されるサーバであり、各種業務に関する帳票情報を管理（例えば、情報の作成や更新、保存など。）するための各種の機能を有する。基幹業務サーバ１１０は、ＯＳ（Operating System）やリレーショナルＤＢを備えた一般的な情報処理装置によって構成される。

ここで、「帳票」とは、帳簿や伝票類の総称である。また、「帳簿」とは、金銭や品物の出納に関する事項が記入されるものであり、「伝票」とは、帳簿を作成する際の基となるデータであり業務上の取引等の証拠となるものである。本例においては、基幹業務サーバ１１０が、帳票データとして伝票データのみを示すプロセスデータ（各業務プロセスに関するデータ）を扱う場合を例に説明を行なう。

基幹業務サーバ１１０は、業務アプリケーションプログラムに従って各種の処理を実行する。業務アプリケーションプログラムとしては、例えば、販売業務管理プログラム、販売業務管理プログラム、生産管理プログラム、財務会計管理プログラム、および管理会計管理プログラムなどがある。

ＤＷＨサーバ１２０は、例えば本システムのシステム管理者によって管理されるサーバであり、データウェアハウスを実現するための各種の機能を有する。ここで、「データウェアハウス」とは、時系列で蓄積された帳票データなどの業務データの中から各項目間の関連性を分析するシステムをいう。また、ＤＷＨサーバ１２０は、基幹業務サーバ１１０から転送されたＣＳＶ（Comma Separated Values）形式のファイルを所定のデータ形式に変換するなどして、所定の格納領域に各種データを登録する機能を有する。なお、ＤＷＨサーバ１２０は、データ形式の変換を行わず、ＣＳＶ形式の状態から各格納領域に応じたデータを抽出する構成とされていてもよい。

プロセスフローＤＢ１０１は、基幹業務サーバ１１０の業務アプリケーションプログラムＤＢ（図示せず）に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータ（または帳票データ）により構成されるプロセスフローデータを記憶する記憶媒体である。なお、プロセスフローデータについては、後で詳しく説明する。また、本例においては、統合基幹業務システム１００は、ＤＷＨサーバ１２０によって管理される業務関連データＤＢ（図示せず）を含み、基幹業務サーバ１１０は、プロセスフローＤＢ１０１に記憶されたプロセスデータを、所定の抽出条件に応じてＣＳＶ形式に変換して携帯端末管理サーバ１０に送信する機能を有する。なお、本例においては、基幹業務サーバ１１０は、ＦＴＰ（File Transfer Protocol）によりＣＳＶ形式にしたデータファイルを携帯端末管理サーバ１０に転送する。

携帯端末管理サーバ１０は、ＥＲＰが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供するサーバである。携帯端末管理サーバ１０は、例えばＷＷＷサーバなどの情報処理装置によって構成され、基幹情報管理システム５００のシステム管理者、あるいは基幹情報管理システム５００のシステム管理者とは別の携帯端末管理サーバ１０の管理者によって管理される。

図２は、携帯端末管理サーバ１０の構成例を示すブロック図である。図２に示すように、携帯端末管理サーバ１０は、プロセスフローデータの管理に関する処理を行うプロセスフローデータ管理部１１と、ログインの管理に関する処理を行うログイン管理部１２と、携帯端末３１〜３Ｎにプロセスフローデータを提供する処理などを実行するプロセスフローデータ提供処理部１３と、携帯端末３１〜３Ｎからの要求に応じてプロセスフローデータを更新する処理などを実行するプロセスフローデータ更新処理部１４と、顧客情報の管理に関する処理を行う顧客情報管理部１５と、業務アプリケーションプログラムＤＢ１７と、プロセスフローＤＢ１８と、一般的な基幹業務サーバとしての機能を実現するために必要な各種データ（例えば、業務アプリケーションプログラムＤＢ１７に格納される各種プログラムが利用するデータ）を格納するその他ＤＢ１９とを備えている。なお、その他ＤＢ１９については、本発明に特に関係しない部分であるため、詳しい説明は省略する。

業務アプリケーションプログラムＤＢ１７は、各種業務に用いられるプログラムを記憶する記憶媒体である。業務アプリケーションプログラムＤＢ１７に記憶されるプログラムとしては、販売業務管理プログラム、購買業務管理プログラム、生産管理プログラム、財務会計管理プログラム、および管理会計管理プログラムなどがある。

プロセスフローＤＢ１８は、業務アプリケーションプログラムＤＢ１７に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータ（または帳票データ）により構成されるプロセスフローデータを記憶する記憶媒体である。本例においては、プロセスフローＤＢ１８において、複数の業務プロセスを含むプロセスフロー（業務フロー）に関する各種データを含むプロセスフローデータがプロセスフローテーブルＰＴに格納される場合について説明する。また、本例においては、携帯端末管理サーバ１０が、プロセスフロー毎に発生するプロセスフローデータを１つのプロセスフローテーブルＰＴにて一元管理する場合について説明する。なお、本例においては、プロセスフローデータには、一般的に用いられている伝票データ（例えば、受注伝票に対応する伝票データについては、受注伝票ヘッダ情報、受注伝票明細情報、および納入日日程などが対応付けされ、伝票番号などのキーを元に検索可能な構造で記憶されたデータ。なお、伝票番号には、受注番号、発注番号、出荷番号、入出庫番号、請求書照会、請求番号、会計番号などが含まれる。）が含まれるものとする。

なお、携帯端末管理サーバ１０が、プロセスフローデータを、例えば、後述するタイプ毎に、あるいは後述する共通データの内容の一部（例えば、受注先など）が同じもの毎に、複数のテーブルで管理する構成としてもよい。

図３は、プロセスフローＤＢ１８におけるプロセスフローデータの格納状態の例を示す説明図である。図３に示すように、本例におけるプロセスフローデータは、主キー部と、参照キー部と、タイプ部と、ステータス部と、共通データ部と、プロセス固有データ部とを含む。なお、プロセスフローデータの各部に対応する項目（すなわち、プロセスフローテーブルＰＴにおける各列項目）が、それぞれ、プロセスフローデータを構成するプロセスデータの種類を示す。すなわち、プロセスフローを構成する各業務プロセスに関するデータは、プロセスフローデータを構成する各部に割り当てられて格納される。なお、一連の業務に係るプロセスフロー（例えば、ある企業からの受注から納品までの一連のプロセスフロー）に関するプロセスデータは、プロセスフローテーブルＰＴにおいて同一エントリ（すなわち、プロセステーブルＰＴにおける同一行）に格納される。このような構成とすることにより、各プロセスデータ間の対応関係を定義することができる。

ここで、「主キー部」とは、プロセスフローデータのうち、プロセスフローデータを一意に特定するためのデータである主キーデータが格納される部分である。本例においては、主キー部は、プロセスフロー番号とプロセスフロー明細番号とにより構成される。すなわち、本例においては、プロセスフロー番号とプロセスフロー明細番号との組み合わせが、各プロセスフローデータの識別子（ＩＤ）となる。主キー部は、プロセスフローデータの初回登録時に更新される。なお、ここでの「プロセスフローデータの初回登録時」とは、プロセスフローデータにエントリ（データ行）が追加されるとき、例えば、あるプロセスフローに属するプロセスデータであって、対応する他のプロセスデータが未登録のプロセスデータが登録されるときを意味するものとする。また、ここでの「更新」とは、データの追加を含むものとする。

なお、「プロセスフロー番号」とは、１つのプロセスフローデータ（すなわち、図３に示すプロセスフローテーブルＰＴにおける１列）を特定するための識別子である。プロセスフロー番号は、所定の項目が同じプロセスデータ毎に付与される。本例においては、プロセスフロー番号は、プロセスフローデータにおけるタイプと受注先とが同じプロセスフローデータに対して同一の番号が付与される。

また、「プロセスフロー明細番号」とは、同一のプロセスフロー番号が付与されたプロセスフローデータの中から特定のプロセスフローデータを特定するための識別子である。すなわち、例えば図３に示すプロセスフローテーブルＰＴは、プロセスフローのタイプ「在庫売上」における業務プロセス「受注」において、受注先「Ｔ００１」から金額「１２００」と「２６００」の業務を受注したことを示すプロセスデータを含むプロセスフローデータを、それぞれプロセスフロー番号「０００００１」とプロセスフロー明細番号「００１０」または「００２０」の組み合わせにより一意に特定することができる。

次いで、「参照キー部」とは、プロセスフローデータのうち、売上返品に対する元取引など、プロセスフローに関連する他のプロセスフローデータ（または、他のプロセスデータ）を特定するためのデータである参照キーデータが格納される部分である。本例においては、参照キー部は、参照番号と参照明細番号とにより構成される。参照キー部は、プロセスフローデータの初回登録時に更新される。

なお、参照番号と参照明細番号には、それぞれ、プロセスフローに関連する他のプロセスフローのプロセスフロー番号とプロセスフロー明細番号とが格納される。ただし、新規取引の場合など、プロセスフローに関連する他のプロセスフローがない場合には、参照キー部には、同一エントリの主キー部と同じ値を示すデータが（すなわち、参照番号にはプロセスフロー番号が、参照明細番号にはプロセスフロー明細番号がそれぞれ）格納される。また、参照キー部が、プロセスフローに関連する他のプロセスデータを示す場合、参照キー部には、プロセスデータの種類を特定するためのデータがさらに設けられる。

また、「タイプ部」とは、プロセスフローデータのうち、在庫売上やサンプル出荷など、プロセスフローの種類を示すデータであるタイプデータが格納される部分である。タイプ部は、プロセスフローデータの初回登録時に更新される。なお、プロセスフローの種類は、在庫売上やサンプル出荷に限られない。また、プロセスフローの種類毎にどのプロセスが必要なのかが予め決まっているものとする（すなわち、プロセスフローの種類毎に含まれる業務プロセスの種類や数が異なる）。

また、「ステータス部」とは、プロセスフローデータのうち、プロセスフローの進捗を表すデータ（すなわち、プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータ）であるステータスデータが格納される部分である。本例においては、ステータスデータは、プロセスフローが必要とする業務プロセスに対し、未済のものには「０」、既済のものには「１」が設定されることにより、各業務プロセスの進捗を示す。すなわち、例えば図３に示すように、「在庫売上」のプロセスフローであって、プロセスフローに含まれる業務プロセスが「受注」、「出荷」、「出庫」、「出庫検収」、および「売上」である場合に、業務プロセス「受注」に関するプロセス固有データ（例えば、受注日）が登録されたとする。この場合、ステータスデータは、「売上」に対応する部分が「１」になり、その他の部分は初期状態（すなわち、「０」が設定された状態）のままとなる。

すなわち、本例におけるステータス部は、業務プロセス毎に更新される。言い換えれば、ステータス部は、後述するプロセス固有データの入力のとき、具体的には、所定のステータス変更条件が満たされたことにより各業務プロセスが完了した判定されたときに更新される。なお、ステータス変更条件は特に限定されないが、本例においては、「１つの業務プロセスに対応するプロセス固有データが全て入力されること」がステータス変更条件として携帯端末管理サーバ１０の所定の記憶領域に記憶されているものとする。

なお、本例においては、異なる種類のプロセスフローが同一のテーブルに格納されるため、テーブルを構成する項目（列項目）のうち、特定のプロセスフローには不要なプロセスデータを格納する部分が生じる場合もある。この場合、プロセスフローテーブルにおいては、不要なプロセスデータを格納する部分が空データとなり、空データに対応するステータスデータには「０」が格納されるものとする。

また、「共通データ部」とは、プロセスフローデータのうち、受注先や出荷先など、業務プロセスによらないデータ（すなわち、同一のプロセスフローに含まれる業務プロセス間で共通するデータ）である共通データが格納される部分である。共通データ部は、プロセスフローデータの初回登録時に更新される。

また、「プロセス固有データ部」とは、プロセスフローデータのうち、受注日や各業務プロセスにおいて登録されるデータ（例えば、「納期必着」や「ワレモノ（割れ物注意）」などの注意事項を示すテキストデータ）など、同一のプロセスフローに含まれる各業務プロセスに固有のデータであるプロセス固有データが格納される部分である。プロセス固有データ部は、業務プロセス毎に更新される。よって、本例においては、プロセスフローデータのうち、業務プロセスによるものが「プロセス固有データ」であり、業務プロセスによらないものが「共通データ」であるといえる。

以上が本例におけるプロセスフローデータに関する説明となるが、ここで、図３に示す各種用語の定義について簡単に説明する。

先ず、「受注」とは、得意先から注文を受け、得意先との契約を結んだ状態を意味する。また、「出荷指示」とは、倉庫業者や物流担当者に商品を出荷する指示を行った状態を意味する。また、「出庫」とは、商品が倉庫から出荷され、移動が開始された状態を意味する。また、「検収」とは、得意先の検収が完了し、商品の所有権が得意先に移行した状態を意味する。また、「売上」とは、得意先の検収を確認し、得意先に対する債権金額が確定（＝債権を計上）した状態を意味する。

また、「検収」の用語は、「納入品やサービスが、注文通りの仕様（＝注文通りの数量、色や形、品質）になっているかを検査する業務」や「検収完了時、資産の所有権が移行する」という意味でも用いられる。なお、財務会計上（または、制度会計上）やＥＲＰシステム上では、資産の所有権の移行タイミングを明確にするために、「検収」というイベントが出庫と区別して定義される。

また、本例においては、プロセスフローＤＢ１８には、プロセスフローデータ（または、プロセスフローテーブルＰＴ）の更新条件を示す更新条件データが登録される更新条件テーブルＵＴが備えられる。

図４は、プロセスフローＤＢ１８における更新条件テーブルＵＴに格納される更新条件データの格納状態の例を示す説明図である。図４に示すように、本例における更新条件データは、業務プロセスの名称と、プロセスフローのタイプと、プロセスフローデータ更新条件とを含む。

ここで、「プロセスフローデータ更新条件」とは、プロセスフローのタイプに応じたプロセスデータの登録条件を示すものである。本例においては、プロセスフローデータ更新条件は、ある業務プロセスに関するプロセスデータをプロセスフローデータに追加する場合に、その前提としてプロセスフローデータが有しているべきプロセスデータの種類（すなわち、プロセスフローにおいて完了しているべき業務プロセスの種類）を示す。すなわち、更新条件テーブルＵＴが図４に示したものである場合、例えば業務プロセス「出庫検収」に関するプロセスデータがタイプ「在庫売上」のプロセスフローデータに追加されるには、予め定められた業務プロセス「受注」、「出荷指示」、および「出庫」（すなわち、図４において業務プロセス名称「出庫検収」とタイプ「在庫売上」と同一列のセルに「１」が設定された業務プロセス）に関するプロセスデータがプロセスフローデータに登録されている必要がある。なお、更新条件テーブルＵＴは、基幹情報管理システム５００の管理者によって作成される構成としてもよいし、携帯端末３１〜３Ｎのユーザにより作成可能な構成とされていてもよい。

携帯端末管理サーバ１０は、プロセスフローＤＢ１８およびその他ＤＢ１９に格納された各種データを、所定の外部装置、本例においては携帯端末３１〜３Ｎ及び統合基幹業務システム１００，２００，３００からの要求に応じて提供する機能を有する。すなわち、携帯端末管理サーバ１０は、基幹業務サーバとしての機能を有する。言い換えれば、携帯端末管理サーバ１０は、ＥＲＰエンジンを備える。

なお、図示しないが、本例においては、携帯端末管理サーバ１０は、データウェアハウスを実現するための各種の機能を有するＤＷＨサーバとしての機能を有するものとする。携帯端末管理サーバ１０が、ＥＲＰエンジンと、ＤＷＨサーバとして機能するための構成とを備えることにより、構成の異なる統合基幹業務システム（例えば、基幹業務サーバとＤＷＨサーバのうち、両方を有する統合基幹業務システム１００と、ＤＷＨサーバのみを有する統合基幹業務システム２００と、ＤＷＨサーバのみを有する統合基幹業務システム３００。）に対しても、統合基幹業務システムとして要求される情報の提供を行うことができるようになる。

各携帯端末３１〜３Ｎは、ＣＰＵ（中央処理装置）、ＲＯＭ、ＲＡＭ、および表示部などを備えた例えばＩｐａｄ（登録商標）などの情報処理装置である。本例においては、各携帯端末３１〜３Ｎは、Ｗｅｂブラウザなど、帳票データを扱うために利用可能な各種アプリケーションを有しているものとする。また、本例においては、各携帯端末３１〜３Ｎは、例えばユーザによる操作入力に応じて、携帯端末管理サーバ１０から必要な帳票データ（本例においては、プロセスフローデータ）を取得するためのクエリ（検索項目、検索キー、抽出キーなど）を定義し、携帯端末管理サーバ１０に送信する機能を有する。

本例においては、各携帯端末３１〜３Ｎは、中継機２０及び通信ネットワーク４０を介して携帯端末管理サーバ１０と通信し、携帯端末管理サーバ１０から取得したデータを例えば所定のＷｅｂアプリケーション（Ｗｅｂブラウザ）などのソフトウェアの機能により表示部に出力する機能を有する。

次に、本例の基幹情報管理システム５００の動作について図面を参照して説明する。なお、本発明に特に関係しない動作や処理については、その内容を省略している場合がある。

図５は、本例の基幹情報管理システム５００における携帯端末管理サーバ１０などが実行するプロセスフローデータ提供処理の例を示すフローチャートである。ここでは、携帯端末管理サーバ１０が、ユーザＸが使用する携帯端末３１からの要求に応じてプロセスフローデータを提供する場合を例に説明する。

プロセスフローデータ提供処理において、先ず、携帯端末３１は、ユーザＸのログイン操作によるログイン要求を受け付ける（ステップＳ１０１）。このログイン操作は、例えば予め設定された暗証番号の入力操作などが考えられる。携帯端末３１へのログインが許可されると、携帯端末３１に搭載されている各種の機能を利用するための各種の操作を行うことが許容される。

ユーザＸが携帯端末３１にログインしている状態であるときに、ユーザＸによって所定のログイン操作が実行されると、携帯端末３１は、携帯端末管理サーバ１０に対してアクセスし、ログイン要求を行う（ステップＳ１０２）。このログイン要求は、例えば、予め定められたログイン判定に用いられる所定の情報（例えばユーザＸに対して発行された電子証明書、ユーザＩＤ、パスワードなど）が提示されて行われる。

携帯端末管理サーバ１０のログイン管理部１２は、ログイン要求を受けると、ログインを許可するか否かを判定するための認証処理を行う（ステップＳ１０３ａ）。この認証処理は、例えば、ユーザＩＤ、パスワード、電子証明書などによって行うようにすればよい。

ログイン管理部１２は、ログインを許可すると判定した場合には（ステップＳ１０３ｂのＹ）、携帯端末３１をログイン状態に設定する。携帯端末３１をログイン状態するとは、携帯端末３１にインストールされている帳票データを扱うために利用されるソフトウェアアプリケーションを有効（使用可能な状態）にすることを言う。ログイン状態に設定されると、携帯端末管理サーバ１０のプロセスフローデータ提供処理部１３は、データ検索画面を示すデータ検索画面情報を携帯端末３１に送信する（ステップＳ１０４）。なお、ログインを許可しないと判定した場合には（ステップＳ１０３ｂのＮ）、ログイン管理部１２は、携帯端末３１をログイン状態に設定することなくプロセスフローデータ提供処理を終了する。なお、ログインを許可しないと判定した場合には、ログイン管理部１２が、その旨を携帯端末３１に対して通知する処理を行う。

データ検索画面情報を受信すると、携帯端末３１は、受信したデータ検索画面情報が示すデータ検索画面を自己が備える表示部に表示する（ステップＳ１０５）。

図６は、データ検索画面の例を示す説明図である。図６に示すように、データ検索画面には、検索対象とする項目（検索項目）を入力する検索項目入力領域６０１と、検索の際に用いるキーワード（検索ワード）を入力する検索ワード入力領域６０２と、前画面に戻る際に押下される戻るボタンＢ１と、検索を実行する際に押下される検索ボタンＢ２とが設けられている。

データ検索画面において、ユーザＸは、携帯端末３１が備える操作部（例えばタッチパネルが配置された表示部に表示されたキーボード）を操作して、検索項目と検索ワードとを入力し、検索ボタンＢ２を押下する。検索項目には、プロセスフローデータを構成し得る項目（例えば、受注伝票、在庫、取引先、商品名。）が入力される。検索ワードには、プロセスフローデータに関連する文字列（例えば、取引先の名称や商品の名称。）が入力される。

検索項目及び検索ワードが入力された状態で検索ボタンＢ２が押下されると、携帯端末３１は、携帯端末管理サーバ１０に対して、入力された検索項目及び検索ワードを検索条件として提示して、プロセスフローデータの提供要求を行う（ステップＳ１０６）。なお、上記の検索条件は一例であり、任意のプロセスフローデータ（または、プロセスフローデータを構成するプロセスデータ）を検索可能な条件であれば他のどのような条件であってもよい。

携帯端末管理サーバ１０は、プロセスフローデータの提供要求を受け付けると、プロセスフローＤＢ１８を参照して、受け付けた提供要求によって提示された検索条件に従ってプロセスフローデータを検索する（ステップＳ１０７）。なお、プロセスフローＤＢ１８に該当データが存在しない場合には、携帯端末管理サーバ１０は、ステップＳ１０７にて、総合基幹業務システム１００，２００，３００に対して該当データの取得要求を行い、総合基幹業務システム１００，２００，３００から該当データを取得する。

検索条件に従ってプロセスフローデータを検索すると、携帯端末管理サーバ１０は、検索したプロセスフローデータを検索結果として表示する検索結果画面を示す検索結果画面情報を携帯端末３１に送信する（ステップＳ１０８）。

検索結果画面情報を受信すると、携帯端末３１は、受信した検索結果画面情報が示す検索結果画面を自己が備える表示部に表示する（ステップＳ１０９）。

図７は、検索結果画面の例を示す説明図である。図７に示すように、検索結果画面には、検索結果を表示する表示領域７０１と、前画面に戻る際に押下される戻るボタンＢ１と、検索結果の編集を行う際に押下される編集ボタンＢ３とが設けられている。

その後、ユーザＸによるブラウザを終了する操作などのアクセスを終了するための操作がなされた場合には（ステップＳ１１０のＹ）、携帯端末３１は、携帯端末管理サーバ１０に対してログアウト要求を行う（ステップＳ１１１）。なお、戻るボタンＢ１の押下などアクセスを継続するための操作がなされた場合には（ステップＳ１１０のＮ）、携帯端末３１は、ステップＳ１０５の処理に移行してデータ検索画面（図６参照）を表示する。

ステップＳ１０８にて検索結果画面情報を送信すると、ログイン管理部１２は、携帯端末３１との情報のやりとりが行われていない時間（待機時間）の計測を開始し、この待機時間が所定時間（例えば５分、１０分、３０分など）を経過（所定時間に到達）したか否かを監視する（ステップＳ１１２）。

待機時間の計測中にログアウト要求を受けると（ステップＳ１１３のＹ）、ログイン管理部１２は、待機時間の計測を中止し、携帯端末３１に対して今回の通信による履歴情報（通信履歴情報、操作履歴情報など）の消去要求を行い（ステップＳ１１４）、ログイン状態を解除するログアウト処理を行う（ステップＳ１１５）。

また、待機時間が所定時間を経過したと判定した場合には（ステップＳ１１２のＹ）、ログイン管理部１２は、待機時間の計測を終了し、携帯端末３１に対して今回の通信による履歴情報（通信履歴情報、操作履歴情報など）の消去要求を行い（ステップＳ１１４）、ログイン状態を解除するログアウト処理を行う（ステップＳ１１５）。

一方、携帯端末３１は、履歴情報の消去要求を受けると、携帯端末管理サーバ１０との今回の通信によって蓄積された履歴情報を消去する処理を行う（ステップＳ１１６）。

上記のようにして、ログイン処理によって操作可能となった携帯端末３１からのログイン要求に応じて携帯端末管理サーバ１０に対するログインを許可するか否か判定し、許可した場合にプロセスフローデータの提供要求を受け付けて、要求に応じたプロセスフローデータを提供する処理が実行される。

上記のようにしてプロセスフローデータの提供処理を行うことによって、ステップＳ１０１及びステップＳ１０３にて２重に認証を行うことができるため、携帯端末３１に対してプロセスフローデータを提供する際の安全性を向上させることが可能となる。

ここで、上述した認証処理（ステップＳ１０３ａ）の具体例について説明する。図８は、ステップＳ１０３ａの認証処理の例を示すフローチャートである。図９は、認証処理の内容を説明するためのタイムチャートである。本例では、基幹情報管理システム５００のシステム管理者Ｙにより携帯端末管理サーバ１０のサーバ管理者Ｚを介してユーザＸに対して発行されるユーザＩＤ（ＥＲＰユーザＩＤ）と、基幹情報管理システム５００のシステム管理者Ｙにより携帯端末管理サーバ１０のサーバ管理者Ｚを介してユーザＸに対して付与されるパスワード（ＥＲＰパスワード）とを用いた認証処理が行われるものとする。本例では、ＥＲＰユーザＩＤとＥＲＰパスワードは、システム管理者Ｙから携帯端末管理サーバ１０のサーバ管理者Ｚを介してユーザＸに付与されるものとする。よって、総合基幹業務システム１００，２００，３００及び携帯端末管理サーバ１０は、それぞれ、本システム５００のユーザに付与されているＥＲＰユーザＩＤとＥＲＰパスワードを保持している。ここでは、総合基幹業務システム１００のライセンスとして発行されたユーザＸのＥＲＰユーザＩＤ及びＥＲＰパスワードにより認証処理を行う場合を例に説明する。

携帯端末３１からのＥＲＰユーザＩＤ及びＥＲＰパスワードを提示したログイン要求を受けると（ステップＳ１００１）、携帯端末管理サーバ１０のログイン管理部１２は、認証処理において、先ず、携帯端末３１から提示されたＥＲＰユーザＩＤ及びＥＲＰパスワードを含む認証依頼情報を総合基幹業務システム１００に送信して、ユーザＸの認証を依頼する（ステップＳ５０１，ステップＳ１００２）。

認証の依頼を受けると、総合基幹業務システム１００は、自己が備えるデータベースに格納されているユーザ情報（ここでは、ユーザ毎のＥＲＰユーザＩＤやＥＲＰパスワードなどが対応付けされた情報）を参照し、携帯端末管理サーバ１０から受信したＥＲＰユーザＩＤ及びＥＲＰパスワードにより登録ユーザであるか否かを判定するための認証処理を行って、その認証の結果を携帯端末管理サーバ１０に対して通知する（ステップＳ１００３）。

認証の結果についての通知を受けると（ステップＳ５０２）、携帯端末管理サーバ１０は、受け付けた通知に従ってログインを許可するか否かを判定し（ステップＳ５０３）、ログインを許可すると判定した場合には、携帯端末３１のログインを許可する（ステップＳ１００４）。

ログインを許可したあとは、携帯端末管理サーバ１０は、携帯端末３１からの要求（ステップＳ１００５）に応じて各種の処理を行う。この各種の処理において、携帯端末管理サーバ１０は、総合基幹業務システム１００に対して処理（検索、情報提供、情報登録などの処理）を要求する場合には、携帯端末３１から提示されているＥＲＰユーザＩＤ及びＥＲＰパスワードを提示して処理要求を行う（ステップＳ１００６）。

そして、総合基幹業務システム１００は、提示されたＥＲＰユーザＩＤ及びＥＲＰパスワードにより登録ユーザであると判定した場合に、要求された処理を実行する。

上記のようにして、基幹情報管理システム５００のシステム管理者Ｙが発行したＥＲＰユーザＩＤとＥＲＰパスワードとを用いてサーバ管理者Ｚが管理する携帯端末管理サーバ１０が認証する構成としているので、携帯端末３１に帳票に関する情報を提供する基幹情報管理システム５００において、不正ライセンスによる不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者Ｙ及びユーザＸを保護することができるようになる。

次に、上述した認証処理（ステップＳ１０３ａ）の他の具体例について説明する。図１０は、ステップＳ１０３ａの認証処理の他の例を示すフローチャートである。図１１は、本例で用いるユーザ情報の例を示す説明図である。図１２は、認証処理の他の内容を説明するためのタイムチャートである。本例では、基幹情報管理システム５００のシステム管理者Ｙにより携帯端末管理サーバ１０に対して発行されるユーザＩＤ（ＥＲＰユーザＩＤ）と、基幹情報管理システム５００のシステム管理者Ｙにより携帯端末管理サーバ１０に対して付与されるパスワード（ＥＲＰパスワード）と、携帯端末管理サーバ１０のサーバ管理者Ｚによりユーザに対して発行されるユーザＩＤと、携帯端末管理サーバ１０のサーバ管理者Ｚによりユーザに対して付与されるパスワードを用いた認証処理が行われるものとする。本例では、ＥＲＰユーザＩＤとＥＲＰパスワードは、システム管理者Ｙから携帯端末管理サーバ１０のサーバ管理者Ｚに対して付与され、ユーザＩＤとパスワードは、サーバ管理者ＺからユーザＸに付与されるものとする。よって、総合基幹業務システム１００，２００，３００及び携帯端末管理サーバ１０は、それぞれ、本システム５００のサーバ管理者Ｚに付与されているＥＲＰユーザＩＤとＥＲＰパスワードを保持している。ここでは、総合基幹業務システム１００のライセンスとして発行されたＥＲＰユーザＩＤ及びＥＲＰパスワードであって、サーバ管理者ＺからユーザＸに付与されたユーザＩＤに対応付けされているＥＲＰユーザＩＤ及びＥＲＰパスワードと、サーバ管理者ＺからユーザＸに付与されたユーザＩＤ及びパスワードとにより認証処理を行う場合を例に説明する。なお、ＥＲＰユーザＩＤ及びＥＲＰパスワードと、ユーザＩＤ及びパスワードとは、１対１に対応付けられているものとする。すなわち、サーバ管理者Ｚは、システム管理者Ｙから与えられたライセンス１つ（１組のＥＲＰユーザＩＤ及びＥＲＰパスワード）について、１つのライセンス（１組のユーザＩＤ及びパスワード）をユーザに対して発行するものとする。

携帯端末３１からのユーザＩＤ及びパスワードを提示したログイン要求を受けると（ステップＳ１０１１）、携帯端末管理サーバ１０のログイン管理部１２は、認証処理において、先ず、自己が備えるデータベースに格納されているユーザ情報（ここでは、ユーザ毎のユーザＩＤやパスワードなどが対応付けされた情報）を参照し、携帯端末３１から提示されたユーザＩＤ及びパスワードによりサーバ管理者Ｚによって登録された登録ユーザであるか否かを確認する（ステップＳ５１１）。

登録ユーザであるか否かの判定を行うと、携帯端末管理サーバ１０は、その判定結果に従ってログインを許可するか否かを判定し（ステップＳ５０３）、ログインを許可すると判定した場合には、携帯端末３１のログインを許可する（ステップＳ１０１２）。

ログインを許可したあとは、携帯端末管理サーバ１０は、携帯端末３１からの要求（ステップＳ１０１３）に応じて各種の処理を行う。この各種の処理において、携帯端末管理サーバ１０は、総合基幹業務システム１００に対して処理（検索、情報提供、情報登録などの処理）を要求する場合には、自己が備えるデータベースに格納されているユーザ情報（図１１参照）を参照して、携帯端末３１から提示されているユーザＩＤに対応付けされているＥＲＰユーザＩＤ及びＥＲＰパスワードを特定し、特定したＥＲＰユーザＩＤ及びＥＲＰパスワードを提示して処理要求を行う（ステップＳ１０１４）。

そして、総合基幹業務システム１００は、提示されたＥＲＰユーザＩＤ及びＥＲＰパスワードにより登録ユーザであると判定した場合に、要求された処理を実行する。

上記のようにして、基幹情報管理システム５００のシステム管理者Ｙが発行したＥＲＰユーザＩＤとＥＲＰパスワードと、サーバ管理者ＺがＥＲＰユーザＩＤとＥＲＰパスワードと一意に対応付けして発行したユーザＩＤとパスワードとを用いて、サーバ管理者Ｚが管理する携帯端末管理サーバ１０が認証する構成としているので、携帯端末３１に帳票に関する情報を提供する基幹情報管理システム５００において、不正ライセンスによる不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者Ｙ及びユーザＸを保護することができるようになる。

図１３は、携帯端末管理サーバ１０と携帯端末３１が実行するプロセスフローデータ更新処理の例を示すフローチャートである。ここでは、ユーザＸが使用する携帯端末３１からの要求に応じてプロセスフローデータを更新する場合を例に説明する。

プロセスフローデータ更新処理におけるステップＳ２０１〜Ｓ２０９（ステップＳ１０３ａ，Ｓ１０３ｂを含む）は上述したプロセスフローデータ提供処理におけるステップＳ１０１〜Ｓ１０９（図５参照：ステップＳ１０３ａ，Ｓ１０３ｂを含む）と同様の処理であり、業務データ更新処理におけるステップＳ２１８〜Ｓ２２４は上述したプロセスフローデータ提供処理におけるステップＳ１１０〜Ｓ１１６（図５参照）と同様の処理であるため、業務データ更新処理におけるステップＳ２０１〜Ｓ２０９，Ｓ２１８〜Ｓ２２４についての詳細な説明は省略する。

プロセスフローデータ更新処理におけるステップＳ２０９にて検索結果画面情報が示す検索結果画面（図７参照）を自己が備える表示部に表示したあと、携帯端末３１は、編集ボタンＢ３の押下を受け付けると、表示領域７０１に表示されている検索結果を編集可能な編集画面を表示する。図１４は、編集画面の例を示す説明図である。図１４に示すように、編集画面には、検索結果を編集可能に表示する編集領域９０１と、前画面に戻る際に押下される戻るボタンＢ１と、編集結果を携帯端末管理サーバ１０側で保存されているプロセスフローデータに反映させる際に押下される更新ボタンＢ４とが設けられている。

ユーザＸは、編集画面において、携帯端末３１を操作して、編集領域６０４に表示されているプロセスフローデータを追加（例えば、伝票の新規登録）、消去、変更などすることにより、検索結果として表示されているプロセスフローデータを編集する作業を行う。そして、編集作業を終えたあと、編集結果を携帯端末管理サーバ１０側で保存されているプロセスフローデータに反映させる場合には、ユーザＸは、携帯端末３１を操作して、更新ボタンＢ４を押下する。

更新ボタンＢ４の押下を受け付けた場合には、携帯端末３１は、携帯端末管理サーバ１０に対して編集結果の反映を要求するための情報書換要求を行う（ステップＳ２１０）。この要求においては、編集内容や、携帯端末管理サーバ１０に関する携帯端末管理サーバ情報（例えば、携帯端末管理サーバ１０に対して発行された電子証明書）、ユーザＸに関するユーザ情報（例えば、ユーザＸに対して発行された電子証明書など）などが提示される。

情報書換要求を受け付けると、携帯端末管理サーバ１０は、プロセスフローＤＢ１８にアクセスし、ログイン前の所定の処理（ログイン前処理）を行う（ステップＳ２１１）。本例においては、ログイン前処理として、携帯端末管理サーバ１０は、ログイン判定に用いられる所定の情報（ログイン判定情報。例えば、携帯端末管理サーバ１０に対して発行された電子証明書、ユーザＸに対して発行された電子証明書など。）を確認するための処理を行う。

ログイン前処理によりログイン判定情報を確認すると、携帯端末管理サーバ１０は、ログインを許可するか否かを判定する（ステップＳ２１２）。この判定は、例えば、ＩＤ、パスワード、電子証明書などによって行うようにすればよい。

携帯端末管理サーバ１０は、ログインを許可すると判定した場合には、携帯端末３１からの情報の受け入れに関して携帯端末３１をログイン状態（ここでは、プロセスフローＤＢ１８へのアクセスが許容された状態）に設定する（ステップＳ２１３）。

携帯端末３１をログイン状態に設定すると（すなわち、ログインを許可すると）、携帯端末管理サーバ１０は、ログイン状態に設定された携帯端末３１からの情報書換要求に従って、プロセスデータＤＢ１８に保存されている該当するプロセスフローデータを書き換える処理を実行する（ステップＳ２１４）。そして、携帯端末管理サーバ１０は、統合基幹業務システム１００，２００，３００に対して編集内容に従って書き換えたことを通知するための書換通知を送信する（ステップＳ２１５）。その後、各統合基幹業務システム１００，２００，３００は、受信した書換通知に応じて自己が備えるプロセスフローＤＢ１０１，２０１，３０１を更新する。なお、各プロセスフローＤＢ１８，１０１，２０１，３０１には、携帯端末３１による情報書換要求に応じて書き換えられた内容が記憶される構成としてもよい。すなわち、誰がいつプロセスフローデータを書き換えたかが記録される構成としてもよい。

プロセスフローＤＢ１８に記憶されている情報を書き換えると、携帯端末管理サーバ１０は、携帯端末３１に対して編集内容に従って書き換えたことを通知するための書換通知を送信する（ステップＳ２１６）。

書換通知を受信すると、携帯端末３１は、自己が編集画面の所定領域に、編集結果が反映された旨をユーザＸに報知するための書換反映通知を表示する（ステップＳ２１７）。

その後、上述したプロセスフローデータ提供処理（図５参照）と同様にして、ステップＳ２１８以降の処理が実行される。

上記のようにして、ログイン処理によって操作可能となった携帯端末３１からのログイン要求に応じて携帯端末管理サーバ１０に対するログインを許可するか否か判定し（ステップＳ１０３ａ）、許可した場合にプロセスフローデータの書換要求を受け付けて（ステップＳ２１０）、書換要求を受け付けた場合にプロセスフローＤＢ１８に対してログイン前処理を行い（ステップＳ２１１）、許可された場合にプロセスフローＤＢ１８のプロセスフローデータを書き換える処理が行われる（ステップＳ２１４）。

上記のようにしてプロセスフローデータの書換処理を行うことによって、ステップＳ２０１、ステップＳ１０３ａ及びステップＳ２１２にて３重に認証を行うことができるため、携帯端末３１からの要求に応じてプロセスフローデータを更新する際の安全性を向上させることが可能となる。なお、情報（データ）の書き換えを行う場合には、情報の提供を行う場合と異なるログイン判定を行う構成とすることにより、携帯端末３１が各種ＤＢにアクセスすることを制限することができるため、携帯端末３１からの要求に応じてプロセスフローデータを更新する際の安全性を向上させることが可能となる。

上記の例では、携帯端末管理サーバ１０が携帯端末３１からの書換要求を受け付ける毎にプロセスフローＤＢ１８に対してログイン判定を行い、ログイン許可をした場合にデータを書き換える処理が行われる構成としていたが、携帯端末管理サーバ１０が、携帯端末３１〜３Ｎからの書換要求を受け付けた場合に、その編集内容及び書換要求元となる携帯端末３１〜３Ｎに関する情報（認証に必要な情報）を蓄積しておき、所定のタイミング（例えば、毎日２３時など）でバッチ処理によりプロセスフローＤＢ１８に対して書換処理を行う構成としてもよい。この場合、所定のタイミングで、書換要求元となる各携帯端末３１〜３Ｎに関する情報を提示してログイン判定を行い、ログインが許可された端末装置を書換要求元とする編集内容のみをプロセスフローＤＢ１８にてプロセスフローデータに反映するようにすればよい。

すなわち、携帯端末管理サーバ１０が、ログイン状態の携帯端末からのプロセスフローデータの更新要求（情報書換要求）を受け付け、受け付けた更新要求の更新内容（編集内容）と、その更新要求を行った携帯端末を示す端末情報（例えば電子証明書）とを含む更新関連情報を蓄積（例えば携帯端末管理サーバ１０が備える記憶媒体に蓄積する。）し、所定のタイミング（例えば、毎日２３時など）となったときに、蓄積されている更新関連情報を用いて一括してプロセスフローデータを更新し、ログイン状態であった各携帯端末から受け付けた更新要求に応じた更新処理（情報書換）を一括して行う構成としてもよい。このように構成すれば、プロセスフローＤＢ１８へのアクセス回数を大幅に減らすことが可能となり、安全性をより向上させることができるようになる。

図１５は、携帯端末管理サーバ１０が実行するデータベース更新処理の例を示すフローチャートである。データベース更新処理では、携帯端末管理サーバ１０にてプロセスフローＤＢ１８に記憶されたプロセスフローデータを更新するための処理が実行される。なお、本例においては、携帯端末管理サーバ１０は、業務アプリケーションプログラムＤＢ１７に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータやプロセスフローデータを所定の時機に取得するものとし、以下で説明するデータベース更新処理は、携帯端末３１〜３Ｎからの更新要求に応じて更新する場合（例えば、上述したプロセスフローデータ更新処理。図１３参照。）とは異なる。

データベース更新処理において、先ず、携帯端末管理サーバ１０は、新たなプロセスフローデータ（新規プロセスフローデータ）を取得したか否かを判定する（ステップＳ３０１）。ここで、新規プロセスフローデータを取得していないと判定すると（ステップＳ３０１のＮ）、携帯端末管理サーバ１０は、後述するステップＳ３０３の処理に移行する。

一方、新規プロセスフローデータを取得したと判定すると（ステップＳ３０１のＹ）、携帯端末管理サーバ１０は、取得したプロセスフローデータをプロセスフローテーブルＰＴに登録する（ステップＳ３０２）。

次いで、携帯端末管理サーバ１０は、登録済みのプロセスフローデータに対応するプロセスデータ（すなわち、プロセスフローを構成する業務プロセスに関するデータ）を取得したか否かを判定する（ステップＳ３０３）。

なお、携帯端末管理サーバ１０による取得したプロセスデータが登録済みのプロセスデータである否かの判定は、取得したデータが有するプロセスフロー番号とプロセスフロー明細番号との組み合わせを有するプロセスフローデータがプロセスフローテーブルＰＴに格納されているか否かを判定することにより行う。そのため、本例においては、携帯端末管理サーバ１０が取得するデータ（業務の実行者により入力されたデータ、または業務アプリケーションプログラムにより作成されたデータ）に、主キー部を構成するデータ（すなわち、プロセスフロー番号とプロセスフロー明細番号）が含まれることが必要となる。

ここで、登録済みのプロセスフローデータに対応するプロセスデータを取得していないと判定すると（ステップＳ３０３のＮ）、携帯端末管理サーバ１０は、その他ＤＢ１９を参照し、取得したデータに対応する記憶領域を特定して、取得したデータを登録し（ステップＳ３０４）、ステップＳ３０１の処理に移行する。

一方、登録済みのプロセスフローデータに対応するプロセスデータを取得したと判定すると（ステップＳ３０３のＹ）、携帯端末管理サーバ１０は、取得したプロセスデータに対応する更新条件テーブルＵＴを参照して、取得したプロセスデータに応じた更新条件データを特定する（ステップＳ３０５）。本例においては、携帯端末管理サーバ１０は、プロセスデータが示す業務プロセスの種類とプロセスフローの識別情報（すなわち、プロセスフロー番号とプロセスフロー明細番号）に基づいて更新条件データを特定する。

更新条件データを特定すると、携帯端末管理サーバ１０は、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしているか否か判定する（ステップＳ３０６）。すなわち、携帯端末管理サーバ１０は、プロセスフローデータと更新条件データとに基づいて、取得したプロセスデータをプロセスフローデータの一部としてプロセスフローテーブルＰＴに登録するか否か判定する。本例においては、携帯端末管理サーバ１０は、取得したプロセスデータに対応するプロセスフローデータのステータス部と更新条件データとを比較し、更新条件データにて「１」が設定された業務プロセスがステータス部においても全て「１」に設定されている場合に、プロセスフローデータが更新条件を満たしていると判定する。

ここで、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしていないと判定すると（ステップＳ３０６のＮ）、携帯端末管理サーバ１０は、所定のエラー処理を実行し（ステップＳ３０７）、ステップＳ３０１の処理に移行する。なお、「エラー処理」とは、プロセスフローデータを更新しない処理であれば特に限定されず、例えば、更新条件が満たされるまでプロセスデータを所定の記憶領域に一時的に保存する処理であってもよいし、更新条件を満たしていないプロセスデータを取得することとなった原因を調べるための処理（すなわち、エラーを管理者に報知する処理や、充足されていない更新条件の内容を管理者に報知する処理など。）であってもよい。

一方、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしていると判定すると（ステップＳ３０６のＹ）、携帯端末管理サーバ１０は、プロセスフローテーブルＰＴに登録されたプロセスフローデータを更新する（ステップＳ３０８）。すなわち、携帯端末管理サーバ１０は、取得したプロセスデータをプロセスフローテーブルＰＴに登録する。

プロセスフローデータを更新すると、携帯端末管理サーバ１０は、プロセスフローデータの更新によりプロセスフローデータに関する所定のステータス変更条件が満たされたか否かを判定する（ステップＳ３０９）。ここで、プロセスフローデータが更新されたことに応じて所定のステータス変更条件が満たされていないと判定すると（ステップＳ３０９のＮ）、携帯端末管理サーバ１０は、ステップＳ３０１に移行する。

一方、プロセスフローデータが更新されたことに応じて所定のステータス変更条件が満たされたと判定すると（ステップＳ３０９のＹ）、携帯端末管理サーバ１０は、満たされたステータス変更条件に基づいて、プロセスフローデータが含むステータスデータを更新し（ステップＳ３１０）、ステップＳ３０１の処理に移行する。

本例におけるデータベース更新処理は、例えば、携帯端末管理サーバ１０の管理者による終了操作により終了する。

なお、データベース更新処理は、リアルタイムに実行される処理であってもよいし、特定の単位時間毎に実行されるバッチ処理であってもよい。また、例えば指定された期間だけリアルタイム処理を行うような、一部にリアルタイム性を有した処理（準リアルタイム処理）であってもよい。

図１６は、携帯端末管理サーバ１０と携帯端末３１とが実行する帳票出力処理の例を示すフローチャートである。帳票出力処理では、携帯端末管理サーバ１０が携帯端末３１に対してプロセスフローデータ（プロセスフローデータの一部または全部）を提供することにより、携帯端末３１が備える表示画面に帳票を表示するための処理が実行される。なお、ログイン管理については上述したプロセスフローデータ提供処理（図５参照）と同様の処理を行うため、ここでの説明は省略する。なお、帳票出力処理は、所定形式の帳票を出力する点でプロセスフローデータ提供処理とは異なる。

また、本例においては、携帯端末３１からの要求に応じて、携帯端末管理サーバ１０がプロセスフローデータを更新する場合についての説明も行う。なお、本例においては、ここで説明するプロセスフローＤＢ１８更新処理（すなわち、帳票出力処理におけるプロセスフローＤＢ１８の更新処理）は、データベース更新処理（図１５参照）の１例である。

帳票出力処理において、先ず、携帯端末３１は、例えば携帯端末３１のユーザＸによる操作入力に応じて、プロセスフローデータ更新要求入力画面要求を携帯端末管理サーバ１０に送信する（ステップＳ５０１）。

プロセスフローデータ更新要求入力画面要求を受信すると、携帯端末管理サーバ１０は、受信したプロセスフローデータ更新要求入力画面要求に応じたプロセスフローデータ更新要求入力画面を送信する（ステップＳ４０１）。

プロセスフローデータ更新要求入力画面を受信すると、携帯端末３１は、自己が備える表示部の表示画面にプロセスフローデータ更新要求入力画面を表示する（ステップＳ５０２）。

図１７は、プロセスフローデータ更新要求入力画面の例を示す説明図である。図１７に示すように、プロセスフローデータ更新要求入力画面には、更新対象の識別情報（本例においては、プロセスフローデータの主キー部に対応するデータ。すなわち、プロセスフロー番号とプロセスフロー明細番号。）の入力を受け付ける主キーデータ入力領域１２０１と、ユーザＸによるプロセスデータが示す業務プロセスの種類の入力を受け付ける業務プロセス入力領域１２０２と、その他のプロセスデータの内容の入力を受け付ける詳細データ入力領域１２０３と、表示部に出力される表示画面を他の表示画面に切替える要求を受け付ける戻るボタン１２０４と、各入力領域（本例においては、主キーデータ入力領域１２０１、業務プロセス入力領域１２０２、詳細データ入力領域１２０３。）に入力された内容に基づくプロセスフローデータの更新要求を受け付ける更新ボタン１２０５とが設けられる。

プロセスフローデータ更新要求入力画面において、ユーザＸは、携帯端末３１が備える操作部（例えば、タッチパネルが配置された表示部に表示された表示領域やボタン）を操作する。すなわち、携帯端末３１は、例えばユーザＸの指により各入力領域が押下されると、押下された入力領域に対するテキストデータ（数字と文字とを含む。）の入力の受付を開始する。そして、携帯端末３１は、例えばタッチパネルが配置された表示部にキーボードを表示して（図示せず）、ユーザＸによるテキストデータの入力を受け付け、受け付けたテキストデータを選択された領域に表示する。また、携帯端末３１は、業務プロセス入力領域１２０２の選択を受け付けると、プルダウン形式で、所定の業務プロセス名称を選択可能に表示する。なお、プロセスデータの入力を受け付ける方法はこれに限定されず、例えば、携帯端末３１が、所定のデータ形式にまとめられた複数のプロセスデータを一度に受け付ける構成としてもよい。

携帯端末３１は、ユーザＸによる更新ボタン１２０５の選択を受け付けると、各入力領域に入力されたデータにより構成されるプロセスデータによるプロセスフローデータの更新要求を受け付けたものと判定する（ステップＳ５０３）。

プロセスフローデータの更新要求（更新要求）を受け付けたものと判定すると、携帯端末３１は、受け付けた更新要求を携帯端末管理サーバ１０に送信する（ステップＳ５０４）。

更新要求を受信すると、携帯端末管理サーバ１０は、プロセスフローテーブルＰＴに登録されたプロセスフローデータのうち、受信した更新要求に応じたプロセスフローデータを取得する（ステップＳ４０２）。なお、このとき携帯端末管理サーバ１０は、更新要求が示す主キーデータ（すなわち、主キーデータ入力領域１２０１に入力されたデータ）を含むプロセスフローデータを、更新要求（すなわち、受信したプロセスデータ）に応じたプロセスフローデータとして取得する。また、ここでの「取得」とは、後述する処理においてプロセスフローデータと更新条件データとを比較等するために一時的に所定の記憶領域に記憶するという意味である。

更新要求に応じたプロセスフローデータを取得すると、携帯端末管理サーバ１０は、更新要求に応じた更新条件データを取得する（ステップＳ４０３）。ここで、更新要求に応じた更新条件データとは、更新要求が示す業務プロセスとプロセスフローデータのタイプ（すなわち、業務プロセス入力領域１２０２に入力された業務プロセスと、ステップＳ４０２の処理にて取得したプロセスフローデータが示すタイプ）とにより特定可能な更新条件データを意味する（図４参照）。

更新条件データを取得すると、携帯端末管理サーバ１０は、取得したプロセスフローデータと更新条件データとを比較し（ステップＳ４０４）、プロセスフローデータの更新条件が満たされているか否か判定する（ステップＳ４０５）。

ここで、更新条件データにおいて「１」が設定された項目の何れか１つ以上がプロセスフローデータのステータス部において「１」に設定されていないことにより、プロセスフローデータの更新条件が満たされていないと判定すると（ステップＳ４０５のＮ）、携帯端末管理サーバ１０は、更新エラー通知を作成して携帯端末３１に送信し（ステップＳ４０６）、ここでの処理を終了する。

更新エラー通知を受信すると（ステップＳ５０５のＹ）、携帯端末３１は、受信した更新エラー通知に基づいて、自己が備える表示部の表示画面に更新エラー通知表示画面を表示する（ステップＳ５０６）。

図１８は、更新エラー通知表示画面の例を示す説明図である。図１８に示すように、更新エラー通知表示画面には、プロセスフローデータ更新要求入力画面に重畳して表示される更新エラー通知表示領域１３０１が設けられる。ここで、本例における更新エラー通知表示領域１３０１には、更新エラーをユーザＸに報知するための定型文の他、更新条件の詳細を表示する旨の要求を受け付けるための詳細表示ボタン１３０２と、更新エラー通知表示領域１３０１を表示画面から消去する旨の要求を受け付ける閉じるボタン１３０３とが設けられる。

携帯端末３１は、ユーザＸによる詳細表示ボタン１３０２の選択を受け付けたことに応じて、例えば、携帯端末管理サーバ１０におけるプロセスフローデータと更新条件データとの比較結果をユーザＸが認識可能な形態（例えば、プロセスフローデータのステータス部と更新条件データのプロセスフローデータ更新条件とを示す対照表。）で表示する。

一方、更新条件データにおいて「１」が設定された項目の全てが、プロセスフローデータのステータス部において「１」に設定されていることによりプロセスフローデータの更新条件が満たされていると判定すると（ステップＳ４０５のＹ）、携帯端末管理サーバ１０は、更新要求が示すプロセスデータをプロセスフローデータに追加してプロセスフローデータを更新する（ステップＳ４０７）。

プロセスフローデータを更新すると、携帯端末管理サーバ１０は、更新したプロセスフローデータを携帯端末３１に送信して（ステップＳ４０８）、ここでの処理を終了する。

一方、プロセスフローデータを受信すると、携帯端末３１は、受信したプロセスフローデータに基づいて、自己が備える表示部の表示画面に帳票表示画面を表示する（ステップＳ５０７）。

図１９は、帳票表示画面の例を示す説明図である。図１９に示すように、帳票表示画面には、プロセスフローデータに基づいた帳票を表示する帳票表示領域１４０１と、帳票ステータス表示領域１４０２と、戻るボタン１４０３と、変更ボタン１４０４とが設けられる。なお、携帯端末３１は、例えば携帯端末３１に備えられたキーボードなどの操作に応じて帳票表示領域１４０１に表示される帳票の縮尺を変更する。

ここで、帳票表示領域１４０１には、所定の表示形態でプロセスフローデータの一部または全部が表示される。なお、本例においては、所定の表示形態でプロセスフローデータの一部または全部を表示するための情報が、携帯端末管理サーバ１０により作成されて、例えば帳票出力処理におけるステップＳ４０８のタイミングで、携帯端末３１に送信されるものとする。なお、携帯端末３１が、自己が備える記憶装置に記憶された情報に基づいて、受信したプロセスフローデータの一部または全部を所定の表示形態で帳票表示領域１４０１に表示する構成としてもよい。

また、帳票ステータス表示領域１４０２は、帳票表示領域１４０１に表示される帳票の種類（または、状況。以下、ステータスという。）を表示する領域である。なお、帳票のステータスとしては、例えば、受注伝票、出庫伝票、検収伝票、および請求書など、種々のものが考えられる。

また、戻るボタン１４０３は、表示画面をプロセスフローデータ更新要求入力画面に戻す旨の要求を受け付けるためのボタンである。なお、携帯端末３１が、ユーザＸによる戻るボタン１４０３の選択を受け付けたことに応じて、表示画面をプロセスフローデータ更新要求入力画面に戻すだけでなく、携帯端末管理サーバ１０に対して、更新要求に基づくプロセスフローデータの更新を取り消す旨の要求を送信する構成としてもよい。この場合、携帯端末３１は、戻すボタン３３の選択に応じて、各入力領域（本例においては、主キーデータ入力領域１２０１、業務プロセス入力領域１２０２、詳細データ入力領域１２０３。）に入力されていたテキストデータ（業務プロセス入力領域１２０２においては、選択されていた業務プロセス）を示す状態でプロセスフローデータ更新要求入力画面を表示する構成とされていてもよい。このような構成とすることにより、ユーザＸによる入力内容の確認を容易にすることができるようになる。

また、変更ボタン１４０４は、帳票表示領域１４０１の表示内容を変更する旨の要求を受け付けるためのボタンである。以下、帳票表示領域１４０１の表示内容の変更処理に関して説明する。

帳票表示画面を表示すると、携帯端末３１は、ユーザＸによる帳票ステータス変更要求を受け付けたか否かを判定する（ステップＳ５０８）。

本例においては、携帯端末３１は、先ず、ユーザＸによる帳票ステータス表示領域１４０２の選択を受け付ける。そして、ユーザＸによる帳票ステータス表示領域１４０２の選択を受け付けると、携帯端末３１は、表示可能な帳票の形態を示す帳票ステータス名称のリストを、例えばプルダウン形式で選択可能に表示する。

なお、ここで表示する帳票ステータス名称については、携帯端末管理サーバ１０からプロセスフローデータと共に受信しているものとする。具体的には、携帯端末管理サーバ１０は、予め所定の記憶領域に記憶された帳票の形態に関するデータ（帳票形態データ）とプロセスフローデータの状態（すなわち、プロセスフローテーブルＰＴの各列項目の入力状態）とに基づいて、表示可能な帳票の形態を示す帳票ステータス名称を特定する。すなわち、例えば携帯端末３１に送信するプロセスフローデータのタイプが「在庫売上」であり、プロセス固有データ部に業務プロセス「受注」に関するプロセスデータしか登録されていない場合には、携帯端末管理サーバ１０は、帳票ステータス名称として「受注伝票」のみを特定する。また、業務プロセス「受注」に関するプロセスデータの他、業務プロセス「出庫」に関するプロセスデータが登録されている場合、携帯端末管理サーバ１０は、帳票ステータス名称として、「受注伝票」と「出庫伝票」とを特定する。

図２０は、プロセスフローデータの状態に基づく帳票ステータスの遷移について説明するための説明図である。図２０において、画像１５０１〜１５０４が、それぞれプロセスフローデータに基づいて帳票表示領域１４０１に表示され得る帳票（具体的には、伝票）の形態であるとする。なお、画像１５０１〜１５０４は、帳票ステータスの遷移について説明するための説明図であり、各種帳票としての役割を果たすための具体的記載例を示すものではない。

ここで、画像１５０４を例にして説明すると、画像１５０４における領域１５１１が帳票ステータス名称を、領域１５１２がプロセスフローのタイプを、領域１５１３がプロセスフローデータに含まれるプロセスデータの業務プロセスの名称をそれぞれ示す領域（本例においては、文字列表示領域）であるものとする。なお、本例においては、プロセスフローデータに含まれるプロセスデータの種類に対応した帳票ステータス名称を領域１５１１に表示している。

この場合、図２０における画像１５０１から画像１５０４への遷移が示すように、１つのプロセスフローデータに対して各業務プロセスに応じたプロセスデータが登録されていく度に、帳票ステータス名称（すなわち、プロセスフローデータに基づいて表示可能な帳票の形態）の種類が増えていくことになる。これは、「次の種類の帳票があるかないか」ではなく、「プロセスフローデータの状態に応じて帳票のステータスが上がっていく（すなわち、表示可能な帳票の種類が増えていく）」ことを意味する。

以下、帳票出力処理におけるステップＳ５０７の処理の前に、携帯端末３１が、業務プロセス「受注」，「出荷指示」，「出庫」，「出庫検収」を含むプロセスフローデータを受信した場合を例にして説明を続ける。なお、本例においては、ステップＳ５０７の処理にて、携帯端末３１が、受信したプロセスフローデータが示すプロセスフローにおいて業務プロセス「受注」，「出荷指示」，「出庫」，「出庫検収」のうち最も上位に位置する業務プロセス「受注」に対応する帳票ステータス名称「受注伝票」に対応する帳票を、帳票表示領域１４０１に表示していたものとする（図１９参照）。なお、携帯端末３１は、ステップＳ４０７の処理にて新たにプロセスフローデータに追加されたプロセスデータに応じた業務プロセスに対応する帳票を帳票表示領域１４０１に表示する構成とされていてもよい。

帳票ステータス変更要求の受付判定処理（ステップＳ５０８）において、ユーザＸによる帳票ステータス変更要求を受け付けていないと判定すると（ステップＳ５０８のＮ）、携帯端末３１は、後述するステップＳ５１０の処理に移行する。

一方、ユーザＸによる帳票ステータス変更要求を受け付けたと判定すると（ステップＳ５０８のＹ）、携帯端末３１は、帳票表示領域１４０１に、受け付けた変更要求に応じた帳票を表示する（ステップＳ５０９）。本例においては、携帯端末３１が、ユーザＸによる業務プロセス「出庫」に対応する帳票ステータス名称「出庫伝票」の選択を受け付けて、業務プロセス「出庫」に対応する帳票（出庫伝票）を帳票表示領域１４０１に表示するものとする。なお、この場合、携帯端末３１は、帳票ステータス表示領域１４０２に、帳票ステータス名称「出庫伝票」を表示する。

帳票ステータス変更要求に応じた帳票を表示すると、携帯端末３１は、帳票出力処理を終了するか否かを判定する（ステップＳ５１０）。ここで、帳票出力処理を終了しないと判定すると（ステップＳ５１０のＮ）、携帯端末３１は、ステップＳ５０８の処理に移行する。

一方、例えばユーザＸによる所定の終了操作を受け付けたことにより帳票出力処理を終了するものと判定すると（ステップＳ５１０のＹ）、携帯端末３１は、ここでの処理を終了する。

以上に説明したように、上述した実施の形態では、ＥＲＰが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する携帯端末管理サーバ１０が、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを携帯端末３１に対して照会可能に記憶するプロセスフローＤＢ１８を備え、携帯端末管理サーバ１０のサーバ管理者ＺからユーザＸに対して発行されたライセンス情報であるユーザライセンス情報（例えば、ユーザＩＤ、パスワード）を提示した携帯端末３１からのログイン要求があったときに、提示されたユーザライセンス情報に基づいて携帯端末３１に対してログインを許可するか否か判定し、ログインを許可すると判定された場合にログイン処理を行い、ログイン処理が実行されたログイン状態の携帯端末３１からの各種処理要求を受け付け、受け付けた処理要求に応じて、所定処理（例えば、帳票データの照会、帳票データの登録など、携帯端末３１からの要求に応じて行う各種の処理）を実行し、所定処理として、携帯端末管理サーバ１０と通信を行うことにより機能を発揮する統合基幹業務システム１００に対して処理要求を行う場合には、サーバ管理者Ｚに対して発行されたライセンス情報であるサーバライセンス情報（例えば、ＥＲＰユーザＩＤ、ＥＲＰパスワード）であって、ユーザライセンス情報を一意に特定可能（１対１に対応することによって特定可能となっている場合や、ユーザライセンス情報にサーバライセンス情報そのものを使用していることにより特定可能となっている場合などが該当する）なサーバライセンス情報を提示してその処理要求を行う構成としているので、携帯端末３１に帳票に関する情報を提供する業務システム（例えば、基幹情報管理システム５００）において、不正ライセンスによる不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者及びユーザを保護することができるようになるという効果を得ることができる。

すなわち、携帯端末管理サーバ１０が、サーバ管理者ＺからユーザＸに対して発行されたユーザライセンス情報に基づいて携帯端末３１に対してログインを許可するか否か判定し、ログイン状態の携帯端末３１からの処理要求に応じて統合基幹業務システム１００に対して処理要求を行う場合には、サーバ管理者Ｚに対して発行されたライセンス情報であるサーバライセンス情報であって、ユーザライセンス情報を一意に特定可能なサーバライセンス情報を提示してその処理要求を行う構成としているので、サーバライセンス情報によって一意に特定可能なユーザライセンス情報により携帯端末３１に対してログインを許可するか否か判定することができ、不正なユーザライセンス情報が不正に使用されるような不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者及びユーザを保護することができるようになる。

また、上述した実施の形態において、ユーザライセンス情報として、サーバライセンス情報が用いられ、携帯端末管理サーバ１０が、ユーザライセンス情報として提示されたサーバライセンス情報によりユーザＸが登録ユーザであるか否かを判定することによって、携帯端末３１に対してログインを許可するか否か判定する構成とした場合には、サーバライセンス情報そのものを用いたユーザライセンス情報により携帯端末３１に対してログインを許可するか否か判定することができ、不正なユーザライセンス情報が不正に使用されるような不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者及びユーザを保護することができるようになる。

また、上述した実施の形態において、ユーザライセンス情報は、サーバライセンス情報１つに対して１つ発行可能で、サーバライセンス情報の１つに対応付けされたライセンス情報であり、携帯端末管理サーバ１０が、提示されたユーザライセンス情報によりユーザが登録ユーザであるか否かを判定することによって、携帯端末３１に対してログインを許可するか否か判定し、ログイン判定に用いられたユーザライセンス情報と１対１で対応付けされているサーバライセンス情報を提示して統合基幹業務システム１００に対してその処理要求を行う構成とした場合には、サーバライセンス情報に１対１で対応付けされているユーザライセンス情報により携帯端末３１に対してログインを許可するか否か判定することができ、不正なユーザライセンス情報が不正に使用されるような不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者及びユーザを保護することができるようになる。

また、上述した実施の形態では、携帯端末３１〜３Ｎが、予め定められた正規のログイン操作を受け付けた場合にのみログインを許可する構成としているので、携帯端末３１〜３Ｎでの認証も必要とするようにすることができ、２重あるいは３重の認証を必要とするようにすることができ、安全性をさらに高めることが可能となる。

また、上述した実施の形態では、携帯端末管理サーバ１０が、携帯端末３１〜３Ｎからのログアウト要求があったことに応じて、ログイン状態を解除するログアウト処理を行い、ログアウト処理が実行されたことに応じて、携帯端末３１〜３Ｎに対して伝票データの提供に関わる通信履歴情報を削除するよう要求する構成としているので（例えば、ステップＳＳ１１４。図５参照。）、通信履歴情報を消去させることが可能となり、携帯端末３１〜３Ｎの紛失等によって情報が漏洩してしまうことを防止することができるようになる。

また、上述した実施の形態では、携帯端末管理サーバ１０が、ログイン状態の携帯端末３１〜３Ｎとの情報のやりとりが行われていない時間を計測し、その計測時間が所定時間に達した場合に（例えば、ステップＳ１１２。図５参照。）、携帯端末３１〜３Ｎに対してプロセスフローデータの提供に関わる通信履歴情報を削除するよう要求する構成としているので、通信履歴情報を消去させることが可能となり、携帯端末３１〜３Ｎの紛失等によって情報が漏洩してしまうことを防止することができるようになる。

なお、上述した実施の形態では特に言及していないが、例えば図２１に示すようなデータ同期サーバ６０を含む基幹情報管理システム５０１とした場合であっても、基幹情報管理システム５００の場合と同様に上述した各処理を行うことができる。

図２１は、本発明の一実施の形態に係る基幹情報管理システム５０１の構成例を示すブロック図である。図２１に示すように、基幹情報管理システム５０１は、携帯端末管理サーバ１０と、データ同期サーバ６０と、中継機２０と、複数の携帯端末３１〜３Ｎ（Ｎは任意の正の整数）と、統合基幹業務システム１００と、統合基幹業務システム２００と、統合基幹業務システム３００とを含む。携帯端末管理サーバ１０と各携帯端末３１〜３Ｎとは、それぞれ、データ同期サーバ６０、インターネットなどの通信ネットワーク４０及び中継機２０を介して接続される。携帯端末管理サーバ１０は、統合基幹業務システム１００、統合基幹業務システム２００、統合基幹業務システム３００と、それぞれＬＡＮや専用通信回線などの通信ネットワーク５１，５２，５３を介して接続される。なお、携帯端末同士や統合基幹業務システム同士は、携帯端末管理サーバを介して通信可能な構成としてもよいし、通信不能な構成としてもよい。また、携帯端末管理サーバ１０は、ＬＡＮや専用通信回線などの通信ネットワークを介してデータ同期サーバ６０と接続される。

データ同期サーバ６０は、携帯端末管理サーバ１０と携帯端末３１〜３Ｎとの間に介在し、携帯端末３１〜３Ｎ内にそれぞれ格納されるプロセスデータと自己が備えるＤＢに格納されているプロセスデータとを所定の同期ルール（例えば、特定のデータのみ同期させるといったルール）に従って同期させる機能を有する。データ同期サーバ６０は、例えばＷＷＷサーバなどの情報処理装置によって構成され、基幹情報管理システム５０１のシステム管理者によって管理される。

ここで、基幹情報管理システム５０１のように構成した場合における認証処理の具体例について説明する。この場合、上述した認証処理（ステップＳ１０３ａ）などは実行されず、データ同期サーバ６０によって同様に認証処理が実行されることとなる。

図２２は、データ同期サーバ６０が実行する認証処理の例を示すフローチャートである。図２３は、本例で用いるユーザ情報の例を示す説明図である。図２４は、認証処理のさらに他の内容を説明するためのタイムチャートである。基幹情報管理システム５０１のシステム管理者ＹＹにより携帯端末管理サーバ１０に対して付与されるユーザＩＤ（ＥＲＰユーザＩＤ）と、基幹情報管理システム５０１のシステム管理者ＹＹにより携帯端末管理サーバ１０に対して付与されるパスワード（ＥＲＰパスワード）と、データ同期サーバ６０のサーバ管理者ＺＺによりユーザＸに対して付与されるユーザＩＤ（ＤＤＳユーザＩＤ）と、データ同期サーバ６０のサーバ管理者ＺＺによりユーザＸに対して付与されるパスワード（ＤＤＳパスワード）とを用いた認証処理が行われるものとする。ＥＲＰユーザＩＤ、ＥＲＰパスワード、ＤＤＳユーザＩＤ及びＤＤＳパスワードを含むユーザ情報は、データ同期サーバ６０及び携帯端末管理サーバ１０それぞれで同期がとられており、データ同期サーバ６０及び携帯端末管理サーバ１０は、それぞれ、共通のユーザ情報を保持しているものとする。ここでは、総合基幹業務システム１００のライセンスとして発行されたＥＲＰユーザＩＤ及びＥＲＰパスワードなどにより認証処理を行う場合を例に説明する。なお、ＥＲＰユーザＩＤ及びＥＲＰパスワードと、ＤＤＳユーザＩＤ及びＤＤＳパスワードとは、１対１に対応付けられているものとする。すなわち、サーバ管理者ＺＺは、システム管理者ＹＹから与えられたライセンス１つ（１組のＥＲＰユーザＩＤ及びＥＲＰパスワード）について、１つのライセンス（１組のＤＤＳユーザＩＤ及びＤＤＳパスワード）をユーザに対して発行するものとする。

携帯端末３１からのＤＤＳユーザＩＤ及びＤＤＳパスワードを提示したログイン要求を受けると（ステップＳ１０２１）、データ同期サーバ６０は、認証処理において、先ず、自己が備えるデータベースに格納されているユーザ情報（ここでは、ユーザ毎のＤＤＳユーザＩＤやＤＤＳパスワードなどが対応付けされた情報）を参照し、携帯端末３１から提示されたＤＤＳユーザＩＤ及びＤＤＳパスワードによりサーバ管理者ＺＺによって登録された登録ユーザであるか否かを確認する（ステップＳ５２１）。

登録ユーザであった場合には、データ同期サーバ６０は、自己が備えるデータベースに格納されているユーザ情報（図２３参照）を参照して、携帯端末３１から提示されているＤＤＳユーザＩＤに対応付けされているＥＲＰユーザＩＤ及びＥＲＰパスワードを特定し、特定したＥＲＰユーザＩＤ及びＥＲＰパスワードを含む認証依頼情報を総合基幹業務システム１００に送信して、ユーザＸの認証を依頼する（ステップＳ５２２，ステップＳ１０２２）。

認証の依頼を受けると、総合基幹業務システム１００は、自己が備えるデータベースに格納されているユーザ情報（ここでは、ユーザ毎のＥＲＰユーザＩＤやＥＲＰパスワードなどが対応付けされた情報）を参照し、データ同期サーバ６０から受信したＥＲＰユーザＩＤ及びＥＲＰパスワードにより登録ユーザであるか否かを判定するための認証処理を行って、その認証の結果をデータ同期サーバ６０に対して通知する（ステップＳ１０２３）。

認証の結果についての通知を受けると（ステップＳ５２３）、データ同期サーバ６０は、受け付けた通知に従ってログインを許可するか否かを判定し（ステップＳ５２４）、ログインを許可すると判定した場合には、携帯端末３１の携帯端末管理サーバ１０に対するログインを許可する（ステップＳ１０２４）。

ログインを許可したあとは、携帯端末管理サーバ１０は、携帯端末３１からの要求（ステップＳ１０２５）に応じて各種の処理を行う。この各種の処理において、携帯端末管理サーバ１０は、総合基幹業務システム１００に対して処理（検索、情報提供、情報登録などの処理）を要求する場合には、自己が備えるデータベースに格納されているユーザ情報（図２３参照：データ同期サーバ６０が保持しているものと同じ）を参照して、携帯端末３１から提示されているＤＤＳユーザＩＤに対応付けされているＥＲＰユーザＩＤ及びＥＲＰパスワードを特定し、特定したＥＲＰユーザＩＤ及びＥＲＰパスワードを提示して処理要求を行う（ステップＳ１０２６）。

そして、総合基幹業務システム１００は、提示されたＥＲＰユーザＩＤ及びＥＲＰパスワードにより登録ユーザであると判定した場合に、要求された処理を実行する。

上記のようにして、基幹情報管理システム５０１のシステム管理者ＹＹが発行したＥＲＰユーザＩＤとＥＲＰパスワードと、サーバ管理者ＺＺがＥＲＰユーザＩＤとＥＲＰパスワードと一意に対応付けして発行したＤＤＳユーザＩＤとＤＤＳパスワードとを用いて、サーバ管理者ＺＺが管理するデータ同期サーバ６０が認証する構成としているので、携帯端末３１に帳票に関する情報を提供する基幹情報管理システム５０１において、不正ライセンスによる不正行為を防止することができ、システムの安全性を高めることができるとともに、システム管理者ＹＹ及びユーザＸを保護することができるようになる。

なお、上述した実施の形態では特に言及していないが、携帯端末管理サーバ１０は、自己が備える記憶媒体に記憶されている処理プログラム（携帯端末管理プログラム）に従って、上述した各処理（図５、図８、図１０、図１３、図１５、図１６参照）を実行する。

本発明によれば、携帯通信端末に帳票に関する情報を提供する業務システム（特に、ＥＲＰシステム）において、不正ライセンスによる不正行為を防止し、システム管理者及びユーザを保護するのに有用である。

１０ 携帯端末管理サーバ
２０ 中継機
３１〜３Ｎ 携帯端末
４０ 通信ネットワーク
５１，５２，５２ 通信ネットワーク
１００，２００，３００ 統合基幹業務システム
１１０，３１０ 基幹業務サーバ
１２０，２２０ ＤＷＨサーバ
５００ 基幹情報管理システム

Claims (5)

1. ＥＲＰが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する携帯端末管理サーバであって、
   複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを前記携帯端末に対して照会可能に記憶するプロセスフローデータ記憶手段と、
   前記携帯端末管理サーバのサーバ管理者から前記ユーザに対して発行されたライセンス情報であるユーザライセンス情報を提示した前記携帯端末からのログイン要求があったときに、提示されたユーザライセンス情報に基づいて当該携帯端末に対してログインを許可するか否か判定するログイン判定手段と、
   該ログイン判定手段によってログインを許可すると判定された場合にログイン処理を行うログイン処理手段と、
   該ログイン処理手段によってログイン処理が実行されたログイン状態の前記携帯端末からの各種処理要求を受け付ける処理要求受付手段と、
   該処理要求受付手段によって受け付けられた処理要求に応じて、所定処理を実行する処理実行手段とを含み、
   該処理実行手段は、所定処理として、前記携帯端末管理サーバと通信を行うことにより機能を発揮する統合基幹業務システムに対して処理要求を行う場合には、前記サーバ管理者に対して発行されたライセンス情報であるサーバライセンス情報であって、前記ユーザライセンス情報を一意に特定可能な当該サーバライセンス情報を提示して当該処理要求を行う
   ことを特徴とする携帯端末管理サーバ。
2. 前記ユーザライセンス情報として、前記サーバライセンス情報が用いられ、
   前記ログイン判定手段は、前記ユーザライセンス情報として提示された前記サーバライセンス情報により前記ユーザが登録ユーザであるか否かを判定することによって、前記携帯端末に対してログインを許可するか否か判定する
   請求項１記載の携帯端末管理サーバ。
3. ユーザライセンス情報は、サーバライセンス情報１つに対して１つ発行可能で、サーバライセンス情報の１つに対応付けされたライセンス情報であり、
   前記ログイン判定手段は、提示された前記ユーザライセンス情報により前記ユーザが登録ユーザであるか否かを判定することによって、前記携帯端末に対してログインを許可するか否か判定し、
   前記処理実行手段は、前記ログイン判定手段により用いられた前記ユーザライセンス情報と１対１で対応付けされている前記サーバライセンス情報を提示して前記統合基幹業務システムに対して当該処理要求を行う
   請求項１記載の携帯端末管理サーバ。
4. 前記ライセンス情報として、ユーザＩＤとパスワードとが用いられる
   請求項１から請求項３のうち何れかに記載の携帯端末管理サーバ。
5. ＥＲＰを稼動させ、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する処理を携帯端末管理サーバに実行させる携帯端末管理プログラムであって、
   複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを前記携帯端末に対して照会可能に記憶するプロセスフローデータ記憶手段を備えた前記携帯端末管理サーバに、
   前記携帯端末管理サーバのサーバ管理者から前記ユーザに対して発行されたライセンス情報であるユーザライセンス情報を提示した前記携帯端末からのログイン要求があったときに、提示されたユーザライセンス情報に基づいて当該携帯端末に対してログインを許可するか否か判定するログイン判定処理と、
   該ログイン判定処理にてログインを許可すると判定した場合にログイン処理を行うログイン処理実行処理と、
   該ログイン処理実行処理にてログイン処理が実行されたログイン状態の前記携帯端末からの各種処理要求を受け付ける処理要求受付処理と、
   該処理要求受付処理にて受け付けた処理要求に応じて、所定処理を実行する所定処理実行処理とを実行させ、
   該所定処理実行処理では、所定処理として、前記携帯端末管理サーバと通信を行うことにより機能を発揮する統合基幹業務システムに対して処理要求を行う場合に、前記サーバ管理者に対して発行されたライセンス情報であるサーバライセンス情報であって、前記ユーザライセンス情報を一意に特定可能な当該サーバライセンス情報を提示して当該処理要求を行う処理を
   実行させるための携帯端末管理プログラム。
   

Images