JP2000250872A - 業務処理システムの統合管理方式 - Google Patents

Abstract

(57)【要約】 【課題】 ユーザインタフェースの統一化、簡略化を図
り、業務処理アプリケーションの新規導入や、改版・改
修の影響が少なく、人事異動、組織変更に柔軟に対応で
きる業務処理システムの統合管理方式を実現する。 【解決手段】 管理サーバ１が業務を起動する起動情報
３と業務の起動を許可する起動許可情報４を保持する。
ユーザは、業務を処理する端末から業務処理システム全
体への接続要求として、ユーザ認証のための情報を管理
サーバ１へ送る。管理サーバ１は、認証を行ない、起動
を許可されている業務を検索する。検索した結果、使用
可能業務の一覧を業務メニューとして端末に表示する。
ユーザは表示された業務メニューから、実行する業務を
選択する。管理サーバは、選択された業務の起動情報を
端末に通知する。起動情報を通知された端末は、その起
動情報をもとに所望の業務サーバに接続し、業務を行な
う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアント／サ
ーバシステムにおけるユーザインタフェースに関する。
特に、クライアントから様々な業務を行なう際のサーバ
への接続を一元的に管理する業務処理システムの統合管
理方式に関するものである。

【０００２】

【従来の技術】図２１は、「特開平２−２７５５６３号
公報」に開示された「情報処理システムにおけるサーバ
利用方式」のブロック図である。この「情報処理システ
ムにおけるサーバ利用方式」は、クライアント／サーバ
システムにおいて、端末からサービス名を指定して管理
サーバに接続すると、管理サーバが指定されたサービス
を遂行するサーバに接続してサービスを行なうよう管理
するものである。また、端末からサービス名を指定して
管理サーバに接続すると、管理サーバが指定されたサー
ビスを遂行するサーバに接続してサービスを行なう点、
または、問い合わせに対して、該当サーバの位置を回答
する点を開示した技術として、「特開平７−３１１７４
５号公報」の「分散処理システム」、「特開平６−３０
９２６２号公報」の「分散サービス制御システム」があ
る。これらは、サービス（業務）の接続情報を管理する
システムであるが、利用者の属性、組織情報、サービス
（業務）の起動情報・許可情報及び計算機資源の統合管
理を行なうものではなかった。

【０００３】図２２は、従来の業務サーバと端末との関
係を示す図である。従来のクライアント／サーバシステ
ムにおいて、端末から業務を行なう際、サーバに接続す
る操作は端末からユーザが行なっていた。例えば、経理
課のＡさんが、端末Ａを使用して、サーバＡに接続する
ような場合の操作である。また、業務が複数にわたり、
複数のクライアント／サーバシステムを扱う場合は、そ
のシステム毎にサーバへの接続操作が必要となる。その
ため、ユーザは、図２２に示すように業務をどのサーバ
において行なうのかを判断しなければならなかった。ま
た、サーバへの接続操作もシステム毎に異なるため、そ
れぞれの操作をユーザが習得しなければならなかった。
また、図２２に示すように、システム毎に接続端末が異
なる場合は、使用端末もユーザが選択しなければならな
かった。さらに、システムの管理者においては、システ
ム毎にユーザのセキュリティ／認証を定義しなければな
らず、管理が煩雑となっていた。

【０００４】現在、マルチベンダ環境下で業務処理シス
テムが構築されている。それらのシステムは、様々な開
発言語、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の
種類などが混在した環境になっている場合が多い。ま
た、システムの新規導入や改版・改修が頻繁に起こって
いる。図２３は、従来の業務サーバを示す図である。図
において、９００ａ，９００ｂ，９００ｃは業務サー
バ、９１０ａ，９１０ｂ，９１０ｃは業務アプリケーシ
ョン、９１２ａ，９１２ｂ，９１２ｃは起動情報、９１
４ａ，９１４ｂ，９１４ｃは許可情報である。業務処理
システムを起動するための起動情報・許可情報は、図２
３のようにシステム毎に管理・設定している。システム
の導入／改版・改修時には、起動情報もシステム毎に個
別に更新される。

【０００５】また、業務処理システムの起動を許可する
ための許可情報も、業務システムを起動するための起動
情報と同様に、図２３に示すようにシステム毎に管理設
定されている。このため、許可情報もシステム毎に個別
に更新する必要があり、システムの導入／改版・改修時
の負荷が大きいという問題点があった。例えば、端末Ａ
を使用してサーバＡに接続している経理課のＡさんが、
人事課に移動し、端末Ｂを使用してサーバＢに接続する
ことになった場合、サーバＡに登録されているＡさんの
ユーザ情報を抹消して、新たにサーバＢにＡさんのユー
ザ情報を登録しなければならなかった。

【０００６】同一内容の業務でも、端末のＯＳやＨ／Ｗ
の相違によってアプリケーションが別々に存在する場
合、ユーザがそのＡＰＰを判断し、選択をしなければな
らなかった。

【０００７】また、業務処理の運用上、上長がその業務
の担当者として部下を指名して、利用を委任しているこ
とが多い。利用の委任には、上長による委任で定常的に
業務を行なう指名業務と出張等で不在になる期間の業務
の代行（代行業務）とがある。図２４は、業務処理シス
テムの利用を委任する際の従来のオペレーションを示す
図である。担当者の業務処理システムへのログイン時に
は、一般にＩＤ番号＋パスワード、ＩＤカード等でセキ
ュリティがかけられる。このため、利用を委任する際、
図２４に示すように、上長などの指名者（Ａ者）から被
指名者／代行者（Ｂ者）にパスワードを伝達したり、Ｉ
Ｄカードを受け渡すことを行なっていた。ＩＤカードを
受け渡すのは、パスワードを伝達すると機密漏洩の恐れ
があるためである。しかしながら、パスワードやＩＤカ
ードなしで業務処理システムへのログインを行うこと
は、システム化が困難であった。このため、従来の業務
処理システムには、このような委任形態を、システムと
してサポートするものはなかった。

【０００８】

【発明が解決しようとする課題】この発明は上記のよう
な問題点を解決するためになされたもので、改版や改修
が頻繁に行なわれている場合でも、業務処理システムの
モジュール起動の情報を、簡単に管理する業務処理シス
テムの統合管理方式を実現することを目的とする。ま
た、業務の起動情報と、実行許可情報とを備えたデータ
モデルを管理サーバにおいて管理することで、新規導入
や改版・改修の影響の少ないシステム構築が行なえる業
務処理システムの統合管理方式を実現することを目的と
する。また、業務を上長から委任されて担当したり、担
当者の不在時に代行して担当する処理形態をサポートす
る業務処理システムの統合管理方式を実現することを目
的とする。

【０００９】

【課題を解決するための手段】この発明の業務処理シス
テムの統合管理方式は、以下の要素を備えたことを特徴
とする。 （ａ）業務を処理する業務サーバ、（ｂ）上記業務サー
バで処理される業務を起動する起動情報を保持し、業務
の起動を管理する管理サーバ、（ｃ）上記管理サーバに
接続し、上記管理サーバの保持する起動情報を用いて業
務サーバと接続して業務を処理する端末。

【００１０】上記管理サーバは、上記業務サーバで処理
される業務の起動を許可する起動許可情報を保持し、上
記起動許可情報を参照して上記端末を上記業務サーバと
接続させて上記端末からの業務の起動を管理することを
特徴とする。

【００１１】上記管理サーバは、上記起動情報として業
務サーバを識別するサーバ識別子を保持することを特徴
とする。

【００１２】上記管理サーバは、上記起動情報を上記業
務サーバで処理される業務の起動の形態に対応して保持
することを特徴とする。

【００１３】上記管理サーバは、上記起動許可情報とし
て上記端末の属性による業務の起動の可否を保持するこ
とを特徴とする。

【００１４】上記管理サーバは、上記起動許可情報とし
て上記端末を操作する操作者の属性による業務の起動の
可否を保持することを特徴とする。

【００１５】上記管理サーバは、上記起動許可情報とし
て業務の起動を許可された操作者からの委任を示す情報
を保持することを特徴とする。

【００１６】上記管理サーバは、上記起動許可情報とし
て業務の起動を許可された操作者の代行を示す情報を保
持することを特徴とする。

【００１７】この発明の業務処理システムの統合管理方
式は、以下の要素を備えたことを特徴とする。 （ａ）業務を処理する業務サーバ、（ｂ）上記業務サー
バに接続可能な端末、（ｃ）上記業務サーバで処理され
る業務の起動を許可する起動許可情報を保持し、上記起
動許可情報を参照して上記端末を上記業務サーバと接続
させて上記端末からの業務の起動を管理する管理サー
バ。

【００１８】

【発明の実施の形態】実施の形態１．この発明の業務処
理システムの統合管理方式では、管理サーバが業務を起
動する起動情報と業務の起動を許可する起動許可情報を
保持する。ユーザは、業務を処理する端末から業務処理
システム全体への接続要求として、ユーザ認証のための
情報（ユーザＩＤ、パスワード、証明書など）を管理サ
ーバへ送る。管理サーバは、その情報をもとに認証を行
ない、業務処理システムの使用権のあるユーザであれ
ば、起動を許可されている業務を検索する。検索した結
果、使用可能業務の一覧を業務メニューとして、端末に
表示する。ユーザは表示された業務メニューから、実行
する業務を選択する。管理サーバは、選択された業務の
起動情報（サーバ接続情報、業務ログイン情報、ユーザ
情報）を端末に通知する。起動情報を通知された端末
は、その起動情報をもとに、所望の業務サーバに接続
し、業務を行なう。すなわち、ユーザが接続要求を送る
相手は管理サーバだけでよく、業務毎にユーザが複数の
サーバにアクセスする操作を行う必要がなくなる。

【００１９】以下に、この発明の実施の形態について、
図を用いて説明する。図１は、この発明の業務処理シス
テムの統合管理方式の構成例を示す概要図である。図に
おいて、１は、通信回線１０を介して端末５と接続可能
な管理サーバである。２は、管理サーバ１に接続された
管理データベースであり、起動情報３と起動許可情報４
とを保持する。業務サーバ１００ａ，１００ｂ，１００
ｃは、それぞれ業務アプリケーション１１０ａ，１１０
ｂ，１１０ｃを処理する。業務サーバ１００ａ，１００
ｂ，１００ｃは、それぞれ、通信回線１１を介して端末
５と接続可能である。管理データベース２は、例えば、
ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒ
ｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）を用いたディレ
クトリデータベースが使用される。ＬＤＡＰを用いたデ
ィレクトリデータベースとは、インターネット対応の分
散データベースであり、使用形態は、ユーザに任せられ
ている。オブジェクト指向で、階層構造になっており、
上位の属性を継承するという特徴がある。

【００２０】図２は、この発明の業務処理システムの統
合管理方式の構成図である。この発明の業務処理システ
ムの統合管理方式では、改版・改修の頻繁な業務システ
ムＡ〜Ｃから起動情報及び起動許可情報を分離し、管理
サーバで一元管理する。端末は、管理サーバに対して、
接続要求（ユーザＩＤ、パスワード）を送る（１）。端
末は、管理サーバ（起動情報サーバ）から起動パラメー
タ、リソース種別、リソースダウンロード方法、格納サ
ーバ位置等の起動情報を取得（２）し、その情報を元に
業務システムの業務アプリケーション１１０ａ〜１１０
ｃを起動する（３）。このように、管理サーバで起動・
許可情報を保持し、許可された業務を表示して実行させ
るので、業務サーバで頻繁に改版・改修が行われても、
サーバ毎に起動に関する情報を保守する必要がなく、管
理サーバの起動・許可情報だけをメンテナンスすればよ
い。また、ユーザは、管理サーバにより業務アプリケー
ションの起動情報を取得するので、複数の異なる業務サ
ーバへの接続操作を習得する必要がない。

【００２１】図３は、この発明の業務処理システムの統
合管理方式のデータモデルを示す図である。このような
データモデルにより起動情報を管理することで、許可情
報と起動情報を個別に更新することができ、保守性が向
上する。図３において、１２００の黒丸に＋１をそえた
ものは、’１以上’の関係をあらわしている。すなわ
ち、「システム」１３００に対して、１以上の「業務」
１３０２が定義される。１２０４は、「起動」１３０４
が、「業務」１３０２に対して、’０か１’の関係であ
ることを表している。１２０２，１２０３，１２０７，
１２０８は、’ａ ｐａｒｔ ｏｆ’の関係を表してい
る。「業務」１３０２は、一つの「実行許可」１３０６
を持つ。１２０５は、’ａ ｋｉｎｄ ｏｆ’の関係を
表している。「起動」１３０４は、後述する端末型，ｗ
ｅｂ型，エミュレータ形の起動方法の相違を吸収するた
めの、サブクラスの「起動種」１３０８で定義される。
「実行許可」１３０６はゼロ以上の「端末指定」１３１
０と、同じく、ゼロ以上の「利用者指定」１３１２を持
つ。

【００２２】次に、起動方法について説明する。「起動
種」１３０８に、端末起動型、ＵＲＬ起動型、ホストエ
ミュレータ型など起動方式が異なる場合の各種インスタ
ンスを作成することができる。それぞれの起動方法やモ
ジュール格納サーバの情報は、管理サーバに起動・許可
情報として格納している。格納している起動情報は管理
サーバから端末に与えられる。このため、ユーザは起動
方法の相違を意識せずに起動することができる。

【００２３】次に、実行許可について述べる。「実行許
可」１３０６は、「端末指定」，「利用者指定」の２つ
の情報を持つことができ、起動可否の権限を業務毎に設
定できる。「端末指定」１３１０では、業務の実行でき
る端末の制限、また、別営業所・支店（出張先など）で
の利用を可能にするために、端末を識別するための識別
子である端末ＩＤ、端末の設置場所などの情報を指定す
る。「利用者指定」１３１２では、業務の実行権限を制
限するために、利用者、役職、所属等の情報を指定し
て、業務の許可の可否を設定する。

【００２４】図４は、この発明の実施の形態の処理系を
示す図である。図５は，この実施の形態の業務処理シス
テムへのログイン画面例を示す図である。図において、
５０は、業務処理システムログイン画面であり、タイト
ル５１とユーザＩＤ入力エリア５２とパスワード入力エ
リア５３とログインボタン５４を有している。図６は、
管理サーバにより表示される業務処理システムのメニュ
ー画面例である。図において、６０は，業務処理システ
ムメニュー画面であり、タイトル６１とユーザ名表示エ
リア６２、パス表示エリア６３、メニュー表示エリア６
４からなる。前述したように，端末からログイン情報と
して図５に示すようにユーザＩＤとパスワードを送る
と、管理サーバは、これらの正当性をチェックする。次
に、あらかじめ設定されているシステム使用権（許可情
報）を参照して、そのユーザに実行が許可されている業
務を図６に示すようなメニュー画面の形式で表示する。
図６の６４に示すように表示されるメニューは、階層構
造になっている。この階層構造は、管理データベースの
データ構造を反映させたものである。

【００２５】図７、図８は、この発明の業務処理システ
ムの統合管理方式の管理サーバが保持するデータの構造
の一例を示す図である。図に示すように、管理データベ
ースは、全社７１の下位に，ユーザ情報７２，組織情報
７３，業務情報８４，資源情報８５を持っている。ユー
ザ情報７２は、ユーザＩＤ７４をキーとし、ユーザ情報
項目７５を保持する。組織情報７３は、例えば、本店７
６、東北支店７７、大阪支店７８等を下位に持つ。ま
た、本店７６の下には、人事部７９、総務部８０等があ
り、組織情報項目８１を保持して、階層構造をとってい
る。業務情報８４は、管理業務８６、製造業務８７、販
売業務８８等を下位に持つ。また、管理業務８６の下に
は、経理８９、人事９０、給与９１等があり、さらに、
給与９０の下には、マスタ保守９３、勤務状況９４、月
次計算９５等のアプリケーションがあり、業務情報項目
９６を保持して、階層構造をとっている。この業務情報
の階層構造が、ユーザに表示されるメニューの階層構造
と対応している。資源情報８５は、本店管轄９７、東北
支店管轄９８、大阪支店管轄９９等を下位に持つ。ま
た、東北支店管轄９８の下には、青森センタ１２１、秋
田センタ１２２、岩手センタ１２３等があり、資源情報
項目１２４を保持している。さらに、秋田センタ１２２
の下には、例えば、端末Ａ００１、サーバＡ００１、プ
リンタＡ００１等の各資源の情報が保持され、階層構造
をとっている。

【００２６】業務アプリケーションを構築する具体的な
リソースの種別としては、Ｃ言語リソース、ＶＢ（Ｖｉ
ｓｕａｌ Ｂａｓｉｃ）リソース、ＪＡＶＡアプリケー
ション、ＪＡＶＡ ａｐｐｌｅｔ、ＵＲＬ（Ｕｎｉｆｏ
ｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）、エミュレ
ータなどがある。Ｃ言語リソースとは、Ｃ言語で開発さ
れたアプリケーション、ＶＢリソースとは、Ｖｉｓｕａ
ｌ Ｂａｓｉｃで開発されたアプリケーション、ＪＡＶ
ＡアプリケーションとはＪＡＶＡ言語で開発されたアプ
リケーションである。ＪＡＶＡ ａｐｐｌｅｔとは、Ｊ
ＡＶＡ言語で作成された、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄ
ｅ Ｗｅｂ）プラウザによってダウンロードし実行可能
なアプリケーションであり、事前にコンパイルしてＷＷ
Ｗサーバに登録しておく。ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒ
ｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）は、インターネット
上でアクセス可能なリソースの名前の指定方法である。
エミュレータは、ホストとオンライン接続で使用される
端末として動作させる形式である。

【００２７】これらのリソースは、起動のタイプによ
り、以下のように３種類に分類される。１番目は、端末
上で、端末のＣＰＵを使用してプログラムを直接、実行
する形式の端末起動型である。Ｃ言語リソース、ＶＢ
（Ｖｉｓｕａｌ Ｂａｓｉｃ）リソース、ＪＡＶＡアプ
リケーションが、これに該当する。２番目は、ブラウザ
により起動される形式であり、ＪＡＶＡ ａｐｐｌｅ
ｔ、ＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅ Ｌｏｃ
ａｔｏｒ）が、これに該当する。３番目は、ホストエミ
ュレータ型である。以下に、上記のタイプ毎に起動時の
流れを説明する。

【００２８】まず、端末起動型について、図９、図１０
を用いて説明する。本システムでは、業務アプリケーシ
ョンは適切な業務サーバからその都度ダウンロードさ
せ、業務終了後は、端末からダウンロードファイルを削
除させる。業務起動セキュリティを考慮しなくてよい業
務や、処理速度の性能が要求される特殊な業務に限定し
て、端末にアプリケーションプログラムファイルの常駐
を許す。図９は、一般的なプログラムの起動処理の流れ
である。まず、プログラムファイルを転送する転送方式
を決定する（Ｓ１０）。転送種別としては、例えば、ｆ
ｔｐ（ｆｉｌｅ ｔｒａｎｓｆｅｒ ｐｒｏｔｃｏ
ｌ）、ファイル共有等がある。次に、サーバ名や、サー
バとの位置関係、例えば、最寄のサーバか、ユーザの所
属で固定にするか等により、接続サーバを決定する（Ｓ
１１）。次に、サーバ内の格納パス（Ｓ１２）、プログ
ラムファイル名（Ｓ１３）を決定する。この実施の形態
では、同一業務に対しては、どのサーバでも同一パス、
同一ファイル名でリソースを格納するものとする。次
に、端末にプログラムをダウンロードするときのディレ
クトリを決定する（Ｓ１４）。この実施の形態では、プ
ログラム格納ディレクトリは、あらかじめ固定として設
定しておくものとする。次に、プログラムファイルのダ
ウンロードを開始する（Ｓ１５）。ダウンロードの終了
後、プログラムファイルが圧縮されていれば圧縮種別に
あった解凍を行う（Ｓ１６）。その後、実行に必要なパ
ラメータを決定し（Ｓ１７）、プログラムを起動する
（Ｓ１８）。プログラム終了後は、端末からプログラム
ファイルを削除する。また、端末に常駐しているプログ
ラムの場合は、プログラムが最新バージョンであるかの
バージョンチェックを行なった後、最新バージョンでな
かった場合には、同様に図９の処理を行う。この場合
は、プログラム終了後もプログラムファイルを削除しな
い。

【００２９】図１０は、常駐プログラムで最新バージョ
ンであるときの処理の流れ図である。プログラムが最新
バージョンであるとき、ファイル転送から圧縮解凍まで
の処理は不要であり、最新バージョンのプログラムにパ
ラメータを決定する（Ｓ１７）と、すぐ起動（Ｓ１８）
可能である。

【００３０】次に、ブラウザ起動型（ＵＲＬ型）につい
て説明する。図１１は、ブラウザ起動型の処理の流れ図
である。この場合も、まず、サーバ名や、サーバとの位
置関係、例えば、最寄のサーバか、ユーザの所属により
固定にするか等の条件で、接続サーバを決定する（Ｓ２
１）。次に、サーバ内の格納パス（Ｓ２２）、業務ファ
イル名（Ｓ２３）を決定する。端末起動型の場合と同様
に、この実施の形態では、同一業務に対しては、どのサ
ーバでも同一パス、同一ファイル名でリソースを格納す
るものとする。その後、実行に必要なパラメータを決定
（Ｓ２７）し、プログラムを起動する（Ｓ２８）。

【００３１】次に、ホストエミュレータ型について、図
１２を用いて説明する。図１２は、ホストエミュレータ
型の処理の流れ図である。まず、ホスト名や、ホストと
の位置関係、例えば、最寄のホストか、ユーザの所属で
固定にするか等により、接続ホストを決定する（Ｓ３
１）。次に、ログオン方式を決定する（Ｓ３２）。ログ
オン方式の具体例としては、ＴＳＳ（ｔｉｍｅ ｓｈａ
ｒｉｎｇ ｓｙｓｔｅｍ）がある。次に、ログオン名を
決定する（Ｓ３３）。この実施の形態では、同一業務に
対しては、どのホストでも同一ログオン名であるとす
る。次に、ホスト内の格納パス（Ｓ３４）、業務ファイ
ル名を決定する（Ｓ３５）。この実施の形態では、同一
業務に対しては、どのホストでも同一パス、同一ファイ
ル名でリソースを格納するものとする。その後、実行に
必要なパラメータを決定（Ｓ３７）し、プログラムを起
動する（Ｓ３８）。

【００３２】次に、接続サーバの決定について説明す
る。所属部課、端末位置から接続する業務サーバを決定
する。その際、業務の局所性やサーバと端末の間の距離
が考慮される。また、この実施の形態では、接続サーバ
のあて先の指定方法を３種類に分けている。この分類
は、業務の性質によって行っている。一つ目のタイプ
は、一台で全社分の処理を行う場合のサーバである。こ
の場合、サーバ名は固定となる。二つ目のタイプは、所
属部課固有のデータを処理する業務の場合である。この
場合は、ユーザの所属部課に応じて、サーバを決定す
る。このとき、サーバや端末に関する資源情報として、
所属部課に関する情報を保持しているものとし、この情
報を参照してサーバを決定する。三つ目のタイプは、端
末とサーバとの距離によりサーバを決定する業務の場合
である。具体的には、起動場所から最も近いサーバで実
行するよう設定されている業務である。この場合は、端
末の設置場所に応じて、サーバを決定する。このとき、
サーバや端末に関する資源情報として、設置場所に関す
る情報を保持しているものとし、この情報を参照してサ
ーバを決定する。

【００３３】図１３は、起動指定別に業務を起動する起
動情報の項目をまとめた図である。まず、端末起動型の
起動情報について説明する。最新バージョン１４０は、
常駐プログラムのとき、プログラムのバージョンを示
す。非常駐の時はブランクとする。業務タイプ１４２
は、サーバあて先決定のタイプである。システム名１４
４は、リソースのシステム名、システムレベル１４６
は、システムの展開されているレベル、プログラムファ
イル名１４８は、プログラムのファイル名、ディレクト
リ名をフルパスで記述する。リソースファイル取得方法
１４９は、ＦＴＰかファイル共有かの別を指定する。リ
ソースファイル形式１５２は、圧縮方法の種別を指定す
る。具体例としては、ＬＺＨなどがある。パラメータ１
５４は、プログラム起動時に引数として利用される、ユ
ーザＩＤ、時刻等の起動パラメータの項目を格納する。

【００３４】次に、ＵＲＬ型の起動情報について説明す
る。プロトコル１６０は、ｈｔｔｐなどのプロトコル種
別、業務タイプ１６２は、サーバあて先決定のタイプで
ある。システム名１６４は、リソースのシステム名、シ
ステムレベル１６６は、システムの展開されているレベ
ル、業務ファイル名１６８は、プログラムのファイル
名、ディレクトリ名をフルパスで記述する。パラメータ
１７０は、プログラム起動時に引数として利用される、
ユーザＩＤ、時刻等の起動パラメータの項目を格納す
る。

【００３５】次に、ホストエミュレータ型の起動情報に
ついて説明する。ホスト名１８０は、ホスト名称、ログ
オン名１８２はログオンに使用するユーザＩＤ、アプリ
ケーション名（ＡＰＰ名）１８４は、起動するアプリケ
ーションの名称であり、フルパスで指定する。パラメー
タ１８６は、プログラム起動時に引数として利用され
る、ユーザＩＤ、時刻等の起動パラメータの項目を格納
する。

【００３６】次に、起動許可情報について説明する。こ
の発明の業務処理システムの統合管理方式では、個人に
より、実行許可される業務が決定され、決定された業務
を業務メニューとして表示する。実行許可の判定には、
個人・組織による判定、端末・起動場所による判定、利
用時間帯による判定、上長指名の業務判定、代行業務の
指定による業務判定がある。

【００３７】図１４は、起動許可情報を示す図であり、
判定材料２００毎に、判定に使用する情報２０２をまと
めたものである。個人・組織による判定はユーザの権限
により、起動許可された業務を表示して選択させるため
に行なう。この実施の形態では、ユーザＩＤをはじめと
して、ユーザ情報（個人情報）のそれぞれの項目で業務
の起動許可の判定を行う。また、役職や、部署など個人
が属する所属部課情報との関連でも、業務の起動許可の
判定を行う。その場合には、ユーザ情報の所属部課コー
ドから組織情報を参照して許可情報を得る。また、社員
区分、出向区分など従業員の属性に関する区分により判
定を行なっても良い。

【００３８】端末による判定は、以下のように行なう。
携帯型でない端末（据置型端末）では、事業場コードな
どの計算機情報から設置場所が分かるので、設置場所に
より起動許可を与える運用ができる。例えば、端末のＩ
Ｄの何桁目から何桁が設置場所を示すというコード体系
を用いても良い。また、設置場所という項目を独立させ
て設けても良い。設置場所だけでなく、端末１台毎に起
動許可を与えるやり方でも良く、その場合には、端末Ｉ
Ｄや端末のアドレスによる許可を行なう。携帯型端末の
場合、据置型端末とは異なり、端末自身の情報を用いて
どの場所から起動したかを判定するのは困難である。従
って、携帯型端末（可搬型端末）か、据置型端末かを識
別できるコード体系にするか、識別できる項目を設ける
ことが望ましい。

【００３９】また、業務情報として各業務毎に利用可能
時間帯を持たせることにより、利用時間による業務の起
動許可判定を行なう。例えば、システムデータのメンテ
ナンス時間を利用不可としたり、ホストのバッチ処理時
間に端末からの業務が行なえないようにする。この場
合、管理サーバは、端末から接続要求に基づいて業務メ
ニューを表示する時と、端末から選択した業務を起動す
る時に利用可能時間による判定を行なう。更に、利用者
別に利用可能時間帯を設定しても良い。それにより、利
用者に優先度を持たせることもできる。また、特定の時
間帯に利用が集中するのを防ぐことができる。また、セ
キュリティを向上させることができる。

【００４０】また、上長の指名により、担当者として業
務を遂行する際の判定のために、ユーザ情報に、指名業
務情報を設ける。具体的には、上長からの実行許可を示
す指名業務という項目を個人情報の配属の下に持たせ、
業務コード（業務ＩＤ）と職位ＩＤを格納する。これに
より、定常的な代行業務として、特定の個人にその業務
を割り当てるとともに、その業務の起動許可を与えるこ
とができる。これにより、上長が指名した部下に業務権
限を定常的に委任することをシステムでサポートでき
る。

【００４１】また、定常的な代行（指名業務）ではな
く、役職者の不在時などに、一時的に、部下に業務を委
任する時に起動許可を判定するために、不在時代行とい
う属性で配属を持たせ、職位ＩＤを格納する。これによ
り、上長不在時の代行権を部下に与えることをシステム
でサポートできる。更に、指名業務、代行業務の可否を
確実にするために、業務情報側では、許可情報として指
名可否及び代行可否の属性を設け、指名や不在による代
行が許されない場合には、指名不可及び代行不可を設定
する。これにより、ユーザ情報と業務情報の両方から業
務代行を確実にサポートできる。

【００４２】次に、この実施の形態の管理データベース
の構造を説明する。この実施の形態の管理データベース
は、個人情報（ユーザ情報）、組織情報、業務情報、資
源情報（計算機情報）を有している。まず、個人情報に
ついて、図１５を用いて説明する。図１５は、個人情報
のデータ構造を示す図である。個人情報は、ユーザＩＤ
３０１、パスワード３０３、漢字氏３０５、漢字名３０
７、カナ氏３０９、カナ名３１１、雇用区分３１３、メ
ールアドレス３１５等の項目を持つ。

【００４３】ここでは、個人情報の中の属性データを用
いて、階層構造を持たせることはしない。個人が所属し
ている組織の情報は、配属３２１として、個人を識別す
るユーザＩＤ３０１からリンクする情報として保持され
る。配属には、ほかに、３３１，３４１に示すように、
兼任、不在時代行がある。それぞれ項目として、職位３
２２，３３２，３４２を持つ。職位は、組織情報の部署
の職位にリンクしている。また、前述したように、配属
から指名業務へリンクする情報として、指名業務３５１
がある。指名業務は、指名者職位３５２、業務３５３、
期間開始日３５４、期間終了日３５５の情報を保持す
る。このように、ユーザ情報自身では、階層管理をせ
ず、配属を示す属性を持たせるようにしているので、人
事異動に対しても柔軟に対応できる。

【００４４】次に、組織情報について、図１６を用いて
説明する。図１６は、組織情報のデータ構造を示す図で
ある。組織情報は、部署コード３６１、部署名称３６
３、部署略称３６５、支社コード３６７等の項目を持
つ。組織情報では、部署コード３６１により階層管理を
行なう。部署と役割は、職位３６９を介して対応をとら
れる。３７１は、役職としての役割を示しており、役職
名３７３、役職コード３７５を有する。３７７は、専任
職としての役割を示しており、専任職名３７９、専任職
コード３８０を有する。３８１は、一般としての役割を
示している。職位３６９は、役割のほかにも、前述した
ように、配属（個人情報）とそれぞれリンクしている。

【００４５】次に、業務情報について、図１７を用いて
説明する。図１７は、業務情報のデータ構造を示す図で
ある。業務情報は、システム４００と、業務４１０を有
しており、メニューコードにより階層管理される。シス
テム４００は、システム名４０２，システムＩＤ４０
４，展開レベル４０６等を有している。また、システム
４００は、後述する資源情報のサーバと業務４１０へリ
ンクしている。業務４１０は、メニュー名４１２、メニ
ューコード４１４を有しており、４１６，４１８に示す
ように起動（起動情報），実行許可（起動許可情報）の
それぞれにリンクしている。

【００４６】次に、資源情報について、図１８を用いて
説明する。図１８は、資源情報のデータ構造を示す図で
ある。資源情報は、プリンタ４３０，端末４４０，サー
バ４５０の３通りである。この３通りの資源情報は、そ
れぞれ、名称４３１，４４１，４５１，型式４３２，４
４２，４５２，資産Ｎｏ４３３，４４３，４５３，設置
場所４３４，４４４，４５４，管理部署４３５，４４
６，４５７を有している。さらにまた、プリンタ４３０
は、スプール位置４３６、種別４３７を有し、端末４４
０はＯＳ情報４４５、種別４４７を有し、サーバはＯＳ
情報４５５，搭載システム４５６を有している。搭載シ
ステム４５６は複数のシステムを有してもよい。プリン
タ４３０，端末４４０，サーバ４５０は、場所４６０に
リンクしている。場所４６０は、場所名４６１，住所４
６２，ビル名４６３，フロア４６４を有しており、部署
（組織情報）にリンクしている。資源情報に関しては、
塔載するシステムにより、例えば、ＵＮＩＸ管理系とＮ
Ｔ管理系を分けて管理しても良い。

【００４７】次に、上長の指名業務と不在時の代行業務
のシステム化について、さらに説明する。図１９は、こ
の発明の業務処理システムの統合管理方式の指名業務と
代行業務の構成図である。この発明の業務処理システム
の統合管理方式では、上長などは、指名に関する指名情
報と代行に関する代行情報をシステムの管理者に報告す
る。管理者は、指名情報、代行情報を管理する管理サー
バ１に登録する。この場合、上長などが、自ら管理者と
なっても構わない。利用者（ユーザ）は、管理サーバ１
に各自のユーザＩＤ、パスワードでログインする。管理
サーバ１は、登録されている指名情報、代行情報をもと
に、ユーザに、指名業務、代行業務の実行を許可する。
このように管理することで、システムへのログインのた
めに上長のパスワードを伝達する必要はなくなる。

【００４８】図２０は、この発明の業務処理システムの
統合管理方式のデータモデルを示す図である。このよう
なデータモデルにより代行情報と指名情報とを管理す
る。図２０において、「配属」１３２６は、「個人」１
３１４と「職位」１３１６とを関連付けるものである。
前述した、データ構造でも述べたように、所属、兼任、
不在時代行などのインスタンスがある。不在時代行のイ
ンスタンスに、代行される人（代行依頼者）の職位を持
つことで、代行業務の利用権限を得る。

【００４９】上長の指名で行なう指名業務は、「指名業
務」１３２８に対して、定義する。属性に、指名で行な
う業務のＩＤと指名元の上長の職位ＩＤ（指名者職位）
を持つ。職位による許可条件に加えて、「業務」１３０
２の「実行許可」１３０６に代行可否区分、指名可否区
分を持つ。代行業務、指名業務として実行する時は、こ
れらの区分が可である時だけ許可する。データの項目に
ついては、前述したデータ構造でも述べた通りである。

【００５０】このように、指名情報と代行情報を業務サ
ーバとは別の管理サーバに管理し、前述した図２０のデ
ータモデルを適用することで、他者へのパスワードの伝
達やＩＤカードの受渡しをすることなく、指名業務と代
行業務のシステム化を実現できる。

【００５１】以上のように、この実施の形態では、起動
許可情報を保持し、許可された業務をメニュー表示して
実行させる管理サーバを備えた業務処理システムの統合
管理方式について説明した。また、業務処理するアプリ
ケーションを起動するための起動情報を保持し、接続要
求のあった端末に起動情報を渡して起動させる管理サー
バを備えた業務処理システムの統合管理方式について説
明した。

【００５２】この実施の形態によれば、利用者情報と組
織情報を分けて持つとともに、システム内で、起動許可
情報を統合管理するので、人事異動・組織変更により、
各情報に変更が発生しても、利用者の操作には変更がな
く、システム内でその利用者に許可された業務のみがそ
の利用者用のメニューとして表示されるので、利用者は
変更の有無を意識せずログインしたメニュー画面に表示
された業務から、実行したい業務を選択できる。サーバ
を利用者が選択したり、利用者が起動方法を意識する必
要はなく、利用者に負荷をかけずに、システムの一元管
理ができるという効果がある。また、起動情報と起動許
可情報が管理サーバで一元管理されているので、保守が
容易に行なえるという効果がある。また、業務が、ユー
ザＩＤによる起動なので出張先からでも、すなわち、設
置場所が異なっても、所属している場所と同じ業務を実
行できる。あるいは、他の実行許可のやり方として、端
末ＩＤによる許可の与え方がある。出張先の端末に場所
による許可制限がかかっている場合は、モバイル端末な
どの可搬型端末を利用可能として許可情報を設定してお
き、ユーザＩＤと端末ＩＤで出張先でのサービス実行を
サポートしても良い。この場合、特定のモバイル端末を
１対１で利用者個人に割り当ててもいいし、複数のモバ
イル端末を用意し、出張者にその中のいずれかを出張中
に限り携帯させるという運用を行なっても良い。

【００５３】

【発明の効果】この発明によれば、業務サーバは、起動
情報や起動許可情報を持たないので、システムの改版・
改修が発生した時や、人事異動等でユーザ情報に変更が
生じた時に、管理サーバの管理する起動許可情報と起動
情報だけをメンテナンスすればよい。そのため、効率よ
く一元管理ができる。また、業務サーバへの接続に必要
な情報は、管理サーバから与えられるので、ユーザは、
業務サーバへの接続操作を習得する必要がない。また、
業務を処理する際、どの業務サーバに接続するかをユー
ザが判断する必要がない。また、業務を処理する際、ど
の端末を用いるかをユーザが判断する必要がない。ま
た、ユーザは、業務アプリケーションの起動方法の違い
を習得する必要がない。また、新規業務開発やハードウ
ェア増設の場合でも、変わるオブジェクト自体と管理サ
ーバの管理情報だけをメンテナンスすればよい。そのた
め、ユーザインタフェースを変更する必要がない。ま
た、端末側の情報の改修（データの書き換え、プログラ
ムのインストールなど）が必要ない。また、業務サーバ
毎のユーザ登録が必要ない。また、端末により業務処理
起動の制限が可能になる。また、ユーザに、権限のない
業務の存在を意識させることなく、利用可能な業務の選
択をさせることができる。また、パスワードやＩＤカー
ドを受け渡すことなく指名業務や代行業務を行なえるよ
うシステムでサポートできる。

【図面の簡単な説明】

【図１】 この発明の業務処理システムの統合管理方式
の構成例を示す概要図である。

【図２】 この発明の業務処理システムの統合管理方式
の構成図である。

【図３】 この発明の業務処理システムの統合管理方式
のデータモデルを示す図である。

【図４】 この発明の実施の形態の処理系を示す図であ
る。

【図５】 この実施の形態の業務処理システムへのログ
イン画面を示す図である。

【図６】 この発明の実施の形態の管理サーバにより表
示される業務処理システムのメニュー画面である。

【図７】 この発明の業務処理システムの統合管理方式
の管理サーバが保持するデータの構造の一例を示す図で
ある。

【図８】 この発明の業務処理システムの統合管理方式
の管理サーバが保持するデータの構造の一例を示す図で
ある。

【図９】 この発明の業務処理システムの統合管理方式
で起動される業務プログラムが最新バージョンでないと
きの処理の流れ図である。

【図１０】 この発明の業務処理システムの統合管理方
式で起動される業務プログラムが最新バージョンである
ときの処理の流れ図である。

【図１１】 この発明の業務処理システムの統合管理方
式のブラウザ起動型の処理の流れ図である。

【図１２】 この発明の業務処理システムの統合管理方
式のホストエミュレータ型の処理の流れ図である。

【図１３】 この発明の業務処理システムの統合管理方
式の起動指定別に業務を起動する起動情報の項目をまと
めた図である。

【図１４】 この発明の業務処理システムの統合管理方
式の起動許可情報を示す図である。

【図１５】 この発明の業務処理システムの統合管理方
式の個人情報のデータ構造を示す図である。

【図１６】 この発明の業務処理システムの統合管理方
式の組織情報のデータ構造を示す図である。

【図１７】 この発明の業務処理システムの統合管理方
式の業務情報のデータ構造を示す図である。

【図１８】 この発明の業務処理システムの統合管理方
式の資源情報のデータ構造を示す図である。

【図１９】 この発明の業務処理システムの統合管理方
式の指名業務と代行業務の構成図である。

【図２０】 この発明の業務処理システムの統合管理方
式のデータモデルを示す図である。

【図２１】 「特開平２−２７５５６３号公報」に開示
された「情報処理システムにおけるサーバ利用方式」の
ブロック図である。

【図２２】 従来の業務サーバと端末との関係を示す図
である。

【図２３】 従来の業務サーバを示す図である。

【図２４】 従来の業務処理システムの利用を委任する
際のオペレーションを示す図である。

【符号の説明】

１ 管理サーバ、２ 管理データベース、３ 起動情
報、４ 起動許可情報、５ 端末、１０，１１ 通信回
線、１００ａ，１００ｂ，１００ｃ 業務サーバ、１１
０ａ，１１０ｂ，１１０ｃ 業務アプリケーション。

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B045 BB11 GG01 HH01 5B049 AA00 CC00 5B089 GA11 GA21 GB02 GB09 HA01 JB15 KA10 KA13 KB09 KB13 LB04 LB14

Claims (9)

【特許請求の範囲】
1. 【請求項１】 以下の要素を備えた業務処理システムの
   統合管理方式 （ａ）業務を処理する業務サーバ、（ｂ）上記業務サー
   バで処理される業務を起動する起動情報を保持し、業務
   の起動を管理する管理サーバ、（ｃ）上記管理サーバに
   接続し、上記管理サーバの保持する起動情報を用いて業
   務サーバと接続して業務を処理する端末。
2. 【請求項２】 上記管理サーバは、上記業務サーバで処
   理される業務の起動を許可する起動許可情報を保持し、
   上記起動許可情報を参照して上記端末を上記業務サーバ
   と接続させて上記端末からの業務の起動を管理すること
   を特徴とする請求項１に記載の業務処理システムの統合
   管理方式。
3. 【請求項３】 上記管理サーバは、上記起動情報として
   業務サーバを識別するサーバ識別子を保持することを特
   徴とする請求項１、２いずれかに記載の業務処理システ
   ムの統合管理方式。
4. 【請求項４】 上記管理サーバは、上記起動情報を上記
   業務サーバで処理される業務の起動の形態に対応して保
   持することを特徴とする請求項１〜３いずれかに記載の
   業務処理システムの統合管理方式。
5. 【請求項５】 上記管理サーバは、上記起動許可情報と
   して上記端末の属性による業務の起動の可否を保持する
   ことを特徴とする請求項１〜４いずれかに記載の業務処
   理システムの統合管理方式。
6. 【請求項６】 上記管理サーバは、上記起動許可情報と
   して上記端末を操作する操作者の属性による業務の起動
   の可否を保持することを特徴とする請求項１〜５いずれ
   かに記載の業務処理システムの統合管理方式。
7. 【請求項７】 上記管理サーバは、上記起動許可情報と
   して業務の起動を許可された操作者からの委任を示す情
   報を保持することを特徴とする請求項６に記載の業務処
   理システムの統合管理方式。
8. 【請求項８】 上記管理サーバは、上記起動許可情報と
   して業務の起動を許可された操作者の代行を示す情報を
   保持することを特徴とする請求項６に記載の業務処理シ
   ステムの統合管理方式。
9. 【請求項９】 以下の要素を備えた業務処理システムの
   統合管理方式 （ａ）業務を処理する業務サーバ、（ｂ）上記業務サー
   バに接続可能な端末、（ｃ）上記業務サーバで処理され
   る業務の起動を許可する起動許可情報を保持し、上記起
   動許可情報を参照して上記端末を上記業務サーバと接続
   させて上記端末からの業務の起動を管理する管理サー
   バ。