JP5157520B2

JP5157520B2 - 処理制御システム、サーバ及び処理制御プログラム

Info

Publication number: JP5157520B2
Application number: JP2008042377A
Authority: JP
Inventors: 弘之樹加藤
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2008-02-25
Filing date: 2008-02-25
Publication date: 2013-03-06
Anticipated expiration: 2028-02-25
Also published as: JP2009199481A

Description

本発明は、処理制御システム、サーバ及び処理制御プログラムに関する。

従来のクライアントサーバシステムは、１台のサーバに対して複数台のクライアントから接続される「一対多」の関係のみならず、処理能力の増大、負荷分散等の目的としてサーバを複数台用意した「多対多」の関係で構築される場合がある。

ところで、クライアントにインストールされ利用されるアプリケーションの中には、利用可能なユーザあるいはユーザ数を限定してサーバへの接続を許可するものがある。これは、サーバの負荷やクライアントアクセスライセンスが有償であることなどによるものである。なお、１ユーザ１ライセンスの原則に則ったソフトウェアの供給のために、クライアントマシン間で通信し、排他利用を前提に使用を許可する技術が提案されている（例えば、特許文献１）。

特開２００４−１３９２３８号公報

しかしながら、従来の「一対多」の構成によるクライアントサーバシステムにおけるサーバは、購入したクライアントアクセスライセンス（ＣＡＬ）の数を上限としてクライアントからの接続を許容するのみでよかった。

「多対多」の構成のサーバ側でＣＡＬを管理する場合において、一ユーザが複数台のサーバに接続した場合、そのユーザに対して接続サーバ数分のＣＡＬの設定が必要になる。すなわち、一ユーザに対して複数のＣＡＬ契約が必要になる場合がある。

また、「多対多」の構成のサーバ側でＣＡＬを管理する場合において、購入数分のＣＡＬを全てのサーバに対して設定すると、購入数以上のユーザがアプリケーションを同時に利用できてしまうため、ライセンスの契約違反が発生するおそれがある。

一方、クライアントにＣＡＬを設定する場合には、一般ユーザが個々に自分が使用するクライアントにＣＡＬを設定することが必要となる場合がある。

本発明は、複数台のクライアントと複数台のサーバとを有するシステムにおいて、使用が許可された分のライセンスは使用でき、使用を許可した分のライセンスを超える使用を許容しないようにすることを目的とする。

本発明に係る処理制御システムは、アプリケーションが搭載された複数台のクライアントと複数台のサーバとを有した処理制御システムにおいて、前記複数台のサーバのそれぞれは、アプリケーションの使用の可否に関する情報がユーザ毎に設定され、かつ使用権有りと設定されたユーザの数が使用権に関する所定の取決め事項によってアプリケーションの使用が許可されたユーザの数以下に設定された、使用権情報を記憶する使用権情報記憶手段と、前記クライアントからユーザ識別情報を含むアクセス要求が送られてきた場合、使用権情報を参照して当該ユーザによるアプリケーションの使用の可否を判定する使用可否判定手段と、前記使用可否判定手段によりアプリケーション使用可と判定されたユーザが使用する前記クライアントからの要求に応じて当該アプリケーションを利用した処理を実行する処理手段と、を有し、前記複数台のクライアントのそれぞれは、予め決められた規則に従ってアプリケーション使用許可要求の送信先とする前記サーバを決定する使用許可要求手段と、アプリケーション使用許可要求に応じて要求送信先のいずれかの前記サーバからアプリケーションの使用可と判定された場合において、ユーザから指示されたいずれかの前記サーバに対して、当該アプリケーションを利用してアクセスを行うアプリケーション実行手段と、を有することを特徴とする。

本発明に係る処理制御プログラムは、アプリケーションが搭載された複数台のクライアントと共にクライアントサーバシステムに含まれる複数台のサーバのそれぞれを、前記クライアントからユーザ識別情報を含むアプリケーション使用許可要求が送られてきた場合、アプリケーションの使用の可否に関する情報がユーザ毎に設定され、かつ使用可と設定されたユーザの数が使用権に関する所定の取決め事項によってアプリケーションの使用が許可されたユーザの数以下に設定された、使用権情報を参照することにより、当該ユーザによるアプリケーションの使用の可否を判定する使用可否判定手段、前記使用可否判定手段によりアプリケーション使用可と判定されたユーザが使用する前記クライアントからの要求に応じて当該アプリケーションを利用した処理を実行する処理手段、前記クライアントからユーザ識別情報を含むアクセス要求が送られてきた場合、アプリケーションを使用した当該サーバへのアクセスの可否に関する情報がユーザ毎に設定されたアクセス権情報を参照することにより、当該ユーザのアプリケーションを使用したアクセスの可否を判定するアクセス可否判定手段、として機能させ、前記処理手段は、アクセス可と判定されたユーザが使用する前記クライアントからの要求に応じて当該アプリケーションを利用した処理を実行することを特徴とする。

請求項１記載の発明によれば、使用が許可された分のライセンスは使用でき、使用を許可した分のライセンスを超える使用を許容しない。
更に、アプリケーションの使用許可の要求先とするサーバを特定することができる。

請求項２記載の発明によれば、使用が許可された分のライセンスは使用でき、使用を許可した分のライセンスを超える使用を許容しない。
更に、サーバへのアクセスを許可するクライアントを制限することができる。

以下、図面に基づいて、本発明の好適な実施の形態について説明する。

実施の形態１．

図１は、本発明の実施の一形態に係る処理制御システムの全体構成図の例である。図１には、複数台のサーバ２０と複数台のクライアント３０とがネットワーク１２で接続された構成が示されている。クライアント３０には、文書の登録や編集等の所定の処理を実行するアプリケーションが搭載されている。クライアントユーザは、そのアプリケーションを起動して、いずれかのサーバ２０に接続して所望の文書に対して処理を行う。本実施の形態におけるクライアント３０は、いずれのサーバ２０にもアクセス可能であり、また、各サーバ２０は、いずれのクライアント３０からの接続要求に応じて格納した文書等のファイルに対して処理を実行させる。

図２は、本実施の形態におけるサーバ２０のハードウェア構成図の例である。サーバ２０は、従前から存在するサーバコンピュータとして汎用的なハードウェア構成で実現できる。すなわち、サーバ２０は、図２に示したようにＣＰＵ１、ＲＯＭ２、ＲＡＭ３、ハードディスクドライブ（ＨＤＤ）４を接続したＨＤＤコントローラ５、入力手段として設けられたマウス６とキーボード７、及び表示装置として設けられたディスプレイ８をそれぞれ接続する入出力コントローラ９、通信手段として設けられたネットワークコントローラ１０を内部バス１１に接続して構成される。

なお、サーバ２０は、性能的に差異はあるかもしれないが、ハードウェア構成としては同様でよい。また、管理クライアント１０もサーバ２０と同じコンピュータであることから、性能的に差異はあるかもしれないが、そのハードウェア構成は図２と同じように図示することができる。

図３は、本実施の形態における処理制御システムのブロック構成図の例である。なお、図１に示した複数台のサーバ２０は、それぞれ同等の機能を有するため図２では１台のみ図示した。クライアント３０においても同様である。

クライアント３０は、使用許可要求部３１及びアプリケーション実行部３２を有している。使用許可要求部３１は、搭載されたアプリケーションの使用を許可してもらうために使用許可要求をいずれかのサーバ２０に対して送信する。なお、使用権については、追って詳述する。アプリケーション実行部３２は、使用許可要求部３１による問合せにより使用可と判定されたアプリケーションを実行して、いずれかのサーバ２０へアクセスを行う。なお、本実施の形態でいう「アクセス」というのは、サーバ２０に対して行う処理を指す場合と、またサーバ２０においてファイルを格納した記憶手段に対して行う処理（ファイルアクセス）を指す場合とがある。また、「処理」という場合は、サーバ２０に対してアクセスを行い、当該サーバ２０に格納されたファイルに対してアクセスを行って施される文書処理のことをいう。文書処理が新たに開始される場合、サーバ２０に対してアクセスが発生すると共に当該文書の記憶手段にもアクセスが発生し、それから記憶手段に格納された文書に処理が施されるため、広義には「アクセス」と「処理」は同義と用いる場合もある。

クライアント３０における各構成要素３１，３２は、クライアント３０を形成するコンピュータと、コンピュータに搭載されたＣＰＵ１で動作するプログラムとの協調動作により実現される。また、ローカル文書記憶部３４は、クライアント３０に搭載された外部記憶装置にて実現される。

サーバ２０は、使用可否判定部２１、アプリケーション処理部２２及びアプリケーション利用情報記憶部２４を有している。アプリケーション利用情報記憶部２４には、後述するアプリケーション利用情報が記憶される。使用可否判定部２１は、いずれかのクライアント３０からのアプリケーション使用許可要求に応じ、アプリケーション利用情報を参照して当該ユーザによるアプリケーションの使用の可否を判定し、その判定結果を要求元のクライアント３０へ返信する。アプリケーション処理部２２は、アプリケーション使用可と判定されたユーザが使用するクライアント３０からの当該アプリケーションを使用したアクセス要求に応じ、処理を実行する。

サーバ２０における各構成要素２１，２２は、サーバ２０を形成するコンピュータと、コンピュータに搭載されたＣＰＵ１で動作するプログラムとの協調動作により実現される。また、アプリケーション利用情報記憶部２４は、サーバ２０に搭載されたＨＤＤ４あるいはＲＡＭ３等の記憶手段にて実現してもよい。あるいは、他のコンピュータが有する記憶手段等外部に存在する記憶手段を利用してよい。この場合、使用可否判定部２１は、外部の存在するアプリケーション利用情報記憶部２４をアクセスすることになる。

また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがインストールプログラムを順次実行することで各種処理が実現される。

次に、本実施の形態において特徴的な使用権について説明する。

本実施の形態では、クライアント３０にインストールされて実行されるアプリケーションは、ライセンス契約（ＣＡＬ）によって使用が許可されるユーザの数が制限されているものである。また、このアプリケーションは、インストールされたクライアント３０がサーバ２０に接続できて文書処理等の所定の処理機能を発揮するものである。ユーザ数の制限はライセンス契約によるものに限らず、所定の取決め事項によるものであればよく、例えば覚書等によるものであってもよい。

ここで、本実施の形態において用いる「使用権」というのは、アプリケーションを使ってよい権利と定義する。「使用権」は、アプリケーションを使用する権利であり、アプリケーションを使用してどのサーバ２０に対してアクセスをしてよいか否かについては関係のない権利である。

図４は、本実施の形態におけるアプリケーション利用情報のデータ構成例を示した図である。アプリケーション利用情報は、アプリケーションの使用の可否に関する情報をユーザ毎に設定して生成され、アプリケーション利用情報記憶部２４に予め登録される情報である。本実施の形態では、ユーザの識別情報であるユーザＩＤに使用権の有無が対応付けして設定される。図４に例示したように、サーバ管理者によってアプリケーションの使用の可否に関する情報として“有”、“無”というフラグ情報が設定される。サーバ１の設定内容例によると、Ｕ０００１とＵ０００５に使用権が設定されている。そして、ライセンス契約によるユーザの数は４なので、Ｕ０００１及びＵ０００５以外にあと２人に使用権を設定することが可能である。実際には契約数より少なく設定することは得策ではないので、運用上、設定可能数の上限である４人に使用権を設定することになる。

なお、図４では３台のサーバについて例示したように、運用上、アプリケーション利用情報として、サーバ毎に異なる内容が設定されると考えられる。例えば、サーバが部門毎に設置されているものとし、アプリケーションが会計アプリケーションであるとする。この場合、経理部のサーバ管理者は、経理部に所属する全員にそのアプリケーションを使えるようなライセンス契約を締結することが考えられ、また、技術部のサーバ管理者は、技術部の管理者のみにその会計アプリケーションを使えるようなライセンス契約を締結することが考えられる。このように、運用的にはサーバ２０によってＣＡＬのユーザの数及び使用権を付与するユーザが異なってくる。そして、各サーバ２０においては、当該アプリケーションを使用させるのに適切なユーザに対してした使用権“有”の設定を保持管理することになる。

次に、本実施の形態における動作の例について、図４に例示した設定例に従い図５及び図６に示したフローチャートを用いて説明する。なお、ここでは、いずれかのクライアント３０を使用するユーザは、まだアプリケーションの使用を許可されていないものとする。そして、クライアント３０には、全てのサーバ２０を使用許可の要求先として設定され、またサーバ１，２，３，・・・という順番にて使用許可の要求を送るという規則が予め設定されているものとする。

図５において、ユーザがアプリケーションの利用を開始したいために所定の操作を行う。所定の操作として、本実施の形態ではアプリケーションの起動操作を想定しているが、使用の許可を問い合わせる特有の操作でもよい。この操作に応じて、使用許可要求部３１は、前述した所定の規則に従い使用の許可要求先とするサーバ２０、ここではサーバ１を特定する（ステップ１０１）。そして、サーバ１に対して操作したユーザのユーザＩＤを含めてアプリケーションの使用許可要求を送信する（ステップ１０２）。なお、ユーザＩＤは、例えばクライアント３０の使用開始時に入力されたログインＩＤ等から特定可能である。

図６において、サーバ２０における使用可否判定部２１は、いずれかのクライアント３０から送られてきた使用許可要求を受け付けると（ステップ１１１）、その要求に含まれているユーザＩＤをキーにしてアプリケーション利用情報記憶部２４を検索することによって当該ユーザの使用権の設定内容を特定する。そして、当該ユーザの使用権が“有”であれば、当該ユーザはアプリケーションを使用可と判定する。一方、当該ユーザの使用権が“無”であれば、当該ユーザはアプリケーションを使用不可と判定する（ステップ１１２）。例えば、図４の設定例に従うと、サーバ１の使用可否判定部２１は、ユーザＩＤ“Ｕ００１”のユーザからの要求に対しては使用可と判定し、ユーザＩＤ“Ｕ００２”のユーザからの要求に対しては使用不可と判定する。使用可否判定部２１は、この判定結果を要求元のクライアント３０へ返信する（ステップ１１３）。

図５において、送信した使用許可要求に応じてサーバ２０から返信されてきた判定結果が使用可であった場合（ステップ１０３でＹ）、使用が許可されたと認識して、当該アプリケーションの「使用可」という状態であることを示すフラグ情報等を内部に保持しておく（ステップ１０４）。一方、返信されてきた判定結果が使用不可であった場合（ステップ１０３でＮ）、要求先として指定された全てのサーバ２０に対して使用許可要求を送信していなければ（ステップ１０５でＮ）、前述した規則に従い次のサーバ２０、ここではサーバ２を特定する（ステップ１０１）。そして、サーバ２に対して操作したユーザのユーザＩＤを含めてアプリケーションの使用許可要求を送信する（ステップ１０２）。

なお、サーバ２における処理は、図６を用いて前述したとおりなので説明を省略する。また、サーバ２０から返信されてきた判定結果によってクライアント３０において行う処理の内容も前述したとおりなので説明を省略する。

クライアント３０は、以上のようにしていずれかのサーバ２０から使用の許可を得ることになる。もし、いずれのサーバ２０からも使用可という判定結果が得られなかった場合（ステップ１０５でＹ）、使用が許可されなかったと認識して、当該アプリケーションの「使用不可」という状態であることを示すフラグ情報等を内部に保持しておく（ステップ１０６）。この結果、当該ユーザは、アプリケーションの利用はできない。例えば、アプリケーションが起動されたことにより図５に示した処理が開始されたならば、アプリケーションは強制的に終了されることになる。

使用が許可されたユーザは、当該アプリケーションを利用してサーバ２０に接続し、そのサーバ２０に格納されているファイル、あるいは当該サーバ２０を介してファイルにアクセスすることになる。すなわち、本実施の形態においては、ユーザは自分にアプリケーションの利用を許可したサーバ２０に限定されることなく、使用しているクライアント３０を所望のサーバ２０に接続してファイルアクセスを行うことができる。

本実施の形態では、論理的には、１台のサーバ２０に多数のユーザが集中してしまうことが起こり得る。確かに、集中したサーバ２０においては、自らアプリケーションの利用を許可していないユーザによってアクセスされることになる。しかしながら、アプリケーションを使用するユーザにとってみれば、いずれかのサーバ２０のアプリケーション利用情報には使用権が有りと設定されているはずだからアプリケーションの利用自体は、いずれのサーバ２０にて使用可と判定されようとも本来許可されるべきものである。従って、ユーザにしてみれば、いずれのサーバ２０に許可されようと、そのことに特別な意味はなく、アプリケーションが利用できればよい。一方、アプリケーションを提供したメーカ側からしてみれば、ライセンス契約をしたユーザに対してのみアプリケーションの利用が許可されるので、いずれのサーバ２０にてアプリケーションの処理が実行されようともシステム全体で考えると一概に不当であるとは言えず、契約範囲内と考えられる。

ところで、各サーバ２０において個々に管理している使用権を集中管理するよう構成してもよいが、サーバ２０個々に使用権を設定できるように構成すると、例えば、サーバが部門毎に設置されている場合、自部門のサーバ２０にてライセンス管理を行えばよいので、運用上またセキュリティ上都合がよい。

なお、本実施の形態では、アプリケーション起動時に図５に示した処理を実施して使用の許可を要求するように説明したが、例えばユーザログイン時など都合の良いタイミングで実施するようにしてもよい。

また、使用許可要求を送信するサーバ２０及びその要求する順番を予め規則として設定するようにしたが、規則としては、上記例のように順番を固定的に決めておく必要はなく、例えば、ユーザＩＤ等から当該ユーザが所属する部署を判別して自部門のサーバ２０から送信対象としたり、負荷の小さいサーバ２０を優先して送信対象とするようにしてもよい。また、クライアント３０毎またはユーザ毎に規則を異ならせるようにしてもよい。

また、上記各実施の形態においては、１つのアプリケーションに着目して説明したが、複数のアプリケーションに対して並行して適用可能である。

また、本実施の形態においては、会計アプリケーションなどを例示したが、アプリケーションは、特に限定する必要はなく文書管理アプリケーション等の種々のアプリケーションに適用可能である。これらの変形例は、後述する実施の形態においても同様に適用可能である。

実施の形態２．

上記実施の形態１では、クライアント３０は、アプリケーションの利用が許可されると、いずれのサーバ２０にも接続することが可能であった。しかしながら、サーバ２０の負荷等を考慮すると、クライアント３０からの接続を無制限に認めたくない場合もある。サーバ２０が部門毎に設置されているとすると、サーバ２０にかかる負荷、またセキュリティの問題等から他部門に所属するユーザの利用を無制限に認めたくない場合もある。そこで、本実施の形態では、接続に関する権限を設定してクライアント３０からの接続に制限を設けることができるようにした。

図７は、本実施の形態における処理制御システムのブロック構成図の例である。なお、実施の形態１と同じ構成要素には同じ符号を付け、適宜説明を省略する。クライアント３０は、実施の形態１に接続許可要求部３３を追加した構成を有している。接続許可要求部３３は、ユーザからの指示に従い、接続を許可してもらいたいサーバ２０に対して接続許可要求を送信する。接続許可要求部３３は、クライアント３０を形成するコンピュータと、コンピュータに搭載されたＣＰＵ１で動作するプログラムとの協調動作により実現される。

一方、本実施の形態におけるサーバ２０は、接続可否判定部２３が新たに追加されたことと、図８に例示したようにアプリケーション利用情報にユーザＩＤを対応させて、アプリケーションを使用したアクセスの可否に関するアクセス権情報として接続権の有無が設定されたことが実施の形態１と異なっている。接続可否判定部２３は、クライアント３０からユーザＩＤを含むアクセス要求が送られてきた場合、アプリケーション利用情報を参照することにより、当該ユーザのアプリケーションを使用したアクセスの可否を判定する。接続可否判定部２３は、サーバ２０を形成するコンピュータと、コンピュータに搭載されたＣＰＵ１で動作するプログラムとの協調動作により実現される。アプリケーション利用情報記憶部２４には、図８に示したアプリケーション利用が記憶される。

ここで、本実施の形態において用いる接続権について説明する。

本実施の形態において用いる「接続権」というのは、クライアント３０を当該サーバ２０へ接続してよい権利と定義する。実施の形態１において、「使用権」は、アプリケーションを使用する権利であり、アプリケーションを使用してどのサーバ２０に対してアクセスをしてよいか否かについては関係のない権利であると説明したが、「接続権」は、アプリケーションの使用が許可されたユーザに対して、当該ユーザが使用しているクライアント３０を当該サーバ２０へ接続してよいか否かに関する権利である。

図８は、本実施の形態におけるアプリケーション利用情報のデータ構成例を示した図である。本実施の形態におけるアプリケーション利用情報には、ユーザＩＤに対応させて、使用権及び接続権の有無がそれぞれ対応付けして設定される。図８に例示したように、アプリケーションの使用が許可されたユーザが使用するクライアント３０からの接続要求に応じて当該クライアント３０の接続の可否に関する情報として“有”、“無”というフラグ情報がサーバ管理者により事前に設定される。サーバ１の設定内容例によると、Ｕ０００１，Ｕ０００２などには接続権が設定され、Ｕ０００４，Ｕ０００５には接続権が設定されていない。なお、接続権は、システム内部の運用に関する権利であって使用権とは異なりＣＡＬのユーザ数とは関係なく設定可能である。

なお、接続権は、サーバ毎に異なる内容が設定されると考えられる。例えば、サーバが部門毎に設置されているものとすると、各部門のサーバ２０には、自部門に所属するユーザのみからの要求に対して接続可能、すなわち接続権を“有”と設定したいと考えられる。このように、運用的にはサーバ２０によって接続権を付与するユーザが異なってくる。そして、各サーバ２０においては、自サーバ２０に接続させるのに適切なユーザに対してした接続権“有”の設定を保持管理することになる。

次に、本実施の形態における動作の例について図９及び図１０に示したフローチャートを用いて説明する。本実施の形態においては、まず、アプリケーションの使用が許可される必要があるが、この処理は実施の形態１と同じでよいので説明を省略する。ここでは、アプリケーションの使用の可否が判定されたユーザが、使用するクライアント３０に指示入力をすることによって行われる処理について説明する。

図９において、ユーザが接続先としたいサーバ２０を指定して所定の操作を行うと、接続許可要求部３３は、その指定されたサーバ２０を受け付ける（ステップ２０１）。そして、そのサーバ２０に対して、操作したユーザのユーザＩＤを含めて接続許可要求を送信する（ステップ２０２）。

図１０において、サーバ２０における接続可否判定部２３は、いずれかのクライアント３０から送られてきた接続許可要求を受け付けると（ステップ２１１）、その要求に含まれているユーザＩＤをキーにしてアプリケーション利用情報記憶部２４を検索することによって当該ユーザの接続権の設定内容を特定する。そして、接続要求を発したユーザの接続権が“有”であれば、当該ユーザからの接続は可と判定する。一方、当該ユーザの使用権が“無”であれば、当該ユーザからの接続は不可と判定する（ステップ２１２）。例えば、図８の設定例に従うと、サーバ１の接続可否判定部２３は、ユーザＩＤ“Ｕ００１”のユーザからの要求に対しては接続可と判定し、ユーザＩＤ“Ｕ００４”のユーザからの要求に対しては接続不可と判定する。接続可否判定部２３は、この判定結果を要求元のクライアント３０へ返信する（ステップ２１３）。

図９において、送信した接続許可要求に応じてサーバ２０から返信されてきた判定結果が接続可であった場合（ステップ２０３でＹ）、アプリケーション実行部３２は、接続が許可されたと認識して、当該サーバ２０と接続を行う（ステップ２０４）。一方、返信されてきた判定結果が使用不可であった場合（ステップ２０３でＮ）、接続が許可されなかったと認識して、アプリケーションは強制的に終了される。あるいは、使用権と同様に異なるサーバ２０に接続許可要求を送信するようにしてもよい。

本実施の形態において明らかにしたように、アプリケーションの使用を許可する使用権と、各サーバ２０がアプリケーションを利用してのアクセスを許可する接続権とをユーザに付与する別の権限として取り扱うようにしてもよい。

実施の形態３．

前述したように、使用権は、アプリケーションを使用してもよい権利であり、各ユーザに割り当てられる権利である。ただ、一ユーザのみのライセンス契約をして、全てのユーザがそのユーザアカウントを利用するようにすれば、複数のユーザによりアプリケーションの不正利用が可能になってしまう。そこで、本実施の形態では、このような不正を回避できるようにした。

図１１は、本実施の形態におけるアプリケーション利用情報のデータ構成例を示した図である。本実施の形態におけるアプリケーション利用情報には、ユーザＩＤに対応させて、使用権及び接続権に加えて使用が現時点で許可されているか否かを記録できるようにした。すなわち、アプリケーション利用情報における取得情報には、当該ユーザに対してアプリケーションの使用が許可された時点で“許可”と、設定される許可情報がユーザ毎に設定される。

なお、本実施の形態におけるシステムのブロック構成は、実施の形態２と同じでよく、アプリケーション利用情報記憶部２４に設定されるアプリケーション利用情報及びアプリケーション利用情報を参照して使用の可否を判定する使用可否判定部２１の処理内容が異なってくる。以下、本実施の形態における動作について説明する。なお、処理内容は、実施の形態１とはサーバ２０における使用の可否の判定処理（図６のステップ１１２）が異なるので、この処理について説明する。

サーバ２０における使用可否判定部２１は、いずれかのクライアント３０から送られてきた使用許可要求に含まれているユーザＩＤをキーにしてアプリケーション利用情報記憶部２４を検索することによって当該ユーザの使用権の設定内容を特定する。そして、当該ユーザの使用権が“有”の場合、更に許可情報を参照して“許可”と設定されていなければ、当該ユーザはアプリケーションを使用可と判定する。そして、許可情報に“許可”と設定する。一方、当該ユーザの使用権が“無”である場合、また使用権が“有”であっても許可情報に“許可”が設定されていた場合、当該ユーザはアプリケーションを使用不可と判定する（ステップ１１２）。このようにして、一ユーザに対して重複した使用の許可を行わない。

なお、本実施の形態では、ユーザがログアウトしたことを監視して、ユーザによるアプリケーションを利用しないことが確認できると、当該ユーザの許可情報に設定した“許可”を“−”に変更する手段が必要になってくる。あるいは、アプリケーション利用情報における許可情報に、当該ユーザがログインしたときに“未取得”と、要求に応じて使用を許可した時点で“取得”と、アプリケーションの使用をしないことをユーザが宣言した時点で“未取得”と、ログアウトした時点で“−”と、いうようにログインの状態を合わせてユーザのアプリケーションの利用状態を管理するようにしてもよい。

実施の形態４．

上記実施の形態３では、一ユーザによるアプリケーションの重複利用を阻止できるような構成とした。ただ、一ユーザが複数台のクライアント３０を用い、それぞれのクライアント３０においてアプリケーションを実行させたいような利用も考えられる。つまり、一ユーザがアプリケーションを複数同時に利用したい場合も考えられる。しかしその一方で、同時利用可能なアプリケーションの数を無制限にしてしまうと、ＣＡＬの関係上、思わしくないかもしれない。そこで、本実施の形態においては、制限を設けつつも、一ユーザがアプリケーションを複数同時に利用できるようにした。

図１２は、本実施の形態におけるアプリケーション利用情報のデータ構成例を示した図である。本実施の形態におけるアプリケーション利用情報には、ユーザＩＤに対応させて設定する使用権に当該ユーザがアプリケーションを同時に使用できる上限値を設定できるようにした。図１２の例によると、ユーザＩＤ“Ｕ０００１”のユーザにはアプリケーションを２つ同時に利用できるように設定されている。更に、アプリケーション利用情報には、ユーザＩＤに対応させて利用数の項目が設けられており、ここには当該ユーザが現時点において利用しているアプリケーションの数が設定される。

サーバ２０における使用可否判定部２１は、いずれかのクライアント３０から送られてきた使用許可要求に含まれているユーザＩＤをキーにしてアプリケーション利用情報記憶部２４を検索することによって当該ユーザの使用権の設定内容を特定する。そして、当該ユーザの使用権として１以上が設定されている場合、更に利用数を参照して（使用権）＞（利用数）であれば、当該ユーザはアプリケーションを使用可と判定する。そして、利用数に１を加算する。一方、当該ユーザの使用権として０が設定されている場合、また使用権として１以上が設定されていても（使用権）≦（利用数）の場合、当該ユーザはアプリケーションを使用不可と判定する（ステップ１１２）。このようにして、一ユーザに対して複数のアプリケーションの同時使用を許可可能にする。

なお、本実施の形態では、ユーザがアプリケーションを使用しない宣言を受け付けることで当該ユーザの利用数から１を減算する手段が必要になってくる。なお、アプリケーションを使用しない宣言は、アプリケーションの終了、ユーザによる明示的な指示等によりクライアント３０がサーバ２０へ送信するようにしてもよい。

なお、上記各実施の形態においては、サーバ２０への接続とは異なるアプリケーションの使用権という概念を設けてアプリケーションの使用の許可を判定するようにしたが、この使用権に適用した処理をアプリケーションの取得権という概念にも応用してもよい。すなわち、クライアント３０にインストールするアプリケーションをどのサーバ２０から取得するかというときに、その取得可能とするサーバ２０をユーザ毎に設定できるようにしてもよい。

本発明の実施の一形態に係る処理制御システムの全体構成図の例である。実施の形態１におけるサーバのハードウェア構成図の例である。実施の形態１における処理制御システムのブロック構成図の例である。実施の形態１におけるアプリケーション利用情報のデータ構成例を示した図である。実施の形態１においてアプリケーションの使用の許可を要求するクライアントにおける処理の例を示したフローチャートである。実施の形態１においてアプリケーション使用の可否を判定するサーバにおける処理の例を示したフローチャートである。実施の形態２における処理制御システムのブロック構成図の例である。実施の形態２におけるアプリケーション利用情報のデータ構成例を示した図である。実施の形態２において接続の許可を要求するクライアントにおける処理の例を示したフローチャートである。実施の形態２において接続の可否を判定するサーバにおける処理の例を示したフローチャートである。実施の形態３におけるアプリケーション利用情報のデータ構成例を示した図である。実施の形態４におけるアプリケーション利用情報のデータ構成例を示した図である。

符号の説明

１ＣＰＵ、２ＲＯＭ、３ＲＡＭ、４ハードディスクドライブ（ＨＤＤ）、５ＨＤＤコントローラ、６マウス、７キーボード、８ディスプレイ、９入出力コントローラ、１０ネットワークコントローラ、１１内部バス、１２ネットワーク、２０サーバ、２１使用可否判定部、２２アプリケーション処理部、２３接続可否判定部、２４アプリケーション利用情報記憶部、３０クライアント、３１使用許可要求部、３２アプリケーション実行部、３３接続許可要求部、３４ローカル文書記憶部。

Claims

アプリケーションが搭載された複数台のクライアントと複数台のサーバとを有した処理制御システムにおいて、
前記複数台のサーバのそれぞれは、
アプリケーションの使用の可否に関する情報がユーザ毎に設定され、かつ使用権有りと設定されたユーザの数が使用権に関する所定の取決め事項によってアプリケーションの使用が許可されたユーザの数以下に設定された、使用権情報を記憶する使用権情報記憶手段と、
前記クライアントからユーザ識別情報を含むアクセス要求が送られてきた場合、使用権情報を参照して当該ユーザによるアプリケーションの使用の可否を判定する使用可否判定手段と、
前記使用可否判定手段によりアプリケーション使用可と判定されたユーザが使用する前記クライアントからの要求に応じて当該アプリケーションを利用した処理を実行する処理手段と、
を有し、
前記複数台のクライアントのそれぞれは、
予め決められた規則に従ってアプリケーション使用許可要求の送信先とする前記サーバを決定する使用許可要求手段と、
アプリケーション使用許可要求に応じて要求送信先のいずれかの前記サーバからアプリケーションの使用可と判定された場合において、ユーザから指示されたいずれかの前記サーバに対して、当該アプリケーションを利用してアクセスを行うアプリケーション実行手段と、
を有することを特徴とする処理制御システム。
アプリケーションが搭載された複数台のクライアントと共にクライアントサーバシステムに含まれる複数台のサーバのそれぞれを、
前記クライアントからユーザ識別情報を含むアプリケーション使用許可要求が送られてきた場合、アプリケーションの使用の可否に関する情報がユーザ毎に設定され、かつ使用可と設定されたユーザの数が使用権に関する所定の取決め事項によってアプリケーションの使用が許可されたユーザの数以下に設定された、使用権情報を参照することにより、当該ユーザによるアプリケーションの使用の可否を判定する使用可否判定手段、
前記使用可否判定手段によりアプリケーション使用可と判定されたユーザが使用する前記クライアントからの要求に応じて当該アプリケーションを利用した処理を実行する処理手段、
前記クライアントからユーザ識別情報を含むアクセス要求が送られてきた場合、アプリケーションを使用した当該サーバへのアクセスの可否に関する情報がユーザ毎に設定されたアクセス権情報を参照することにより、当該ユーザのアプリケーションを使用したアクセスの可否を判定するアクセス可否判定手段、
として機能させ、
前記処理手段は、アクセス可と判定されたユーザが使用する前記クライアントからの要求に応じて当該アプリケーションを利用した処理を実行することを特徴とする処理制御プログラム。