(57)【要約】【課題】複数の企業や部門を跨る業務システムにおいて、必要最低限のメッセージの伝達を実現する。【解決手段】業務番号と任意のメッセージ本文よりなる、メッセージのフォーマットを定める。業務番号毎に送信先と送信方法を記述したテーブルを設ける。このテーブルの内容に従い、受信したメッセージを適切な送信先に、適切な送信方法にて送信する機能を設ける。【選択図】図１
2008250880.tif 000002
【特許請求の範囲】
【請求項１】
業務番号と任意の情報よりなるメッセージを、所定の手順にて受信するメッセージ受信部と、
前記業務番号と送信先と送信方法を列挙格納するサービステーブルと、
前記メッセージ受信部から得られた前記メッセージの前記業務番号に基づき、前記サービステーブルの該当レコードに記述されている前記送信先及び前記送信方法に従って、前記メッセージを送信するメッセージ送信部と
を具備することを特徴とする、メッセージ配信装置。
【請求項２】
更に、
前記メッセージ受信部から得られたメッセージを一時的に蓄積するメッセージスプーラを備えることを特徴とする、請求項１記載のメッセージ配信装置。
【請求項３】
コンピュータを、
業務番号と任意の情報よりなるメッセージを、所定の手順にて受信するメッセージ受信部と、
前記業務番号と送信先と送信方法を列挙格納するサービステーブルと、
前記メッセージ受信部から得られた前記メッセージの前記業務番号に基づき、前記サービステーブルの該当レコードに記述されている前記送信先及び前記送信方法に従って、前記メッセージを送信するメッセージ送信部
として機能させるための、メッセージ配信プログラム。
【請求項４】
更に、
前記メッセージ受信部から得られたメッセージを一時的に蓄積するメッセージスプーラを備えることを特徴とする、請求項３記載のメッセージ配信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、商品の商談から販売、運用そして廃棄等に至るまでを管理する、機器管理システムに適用して好適な技術に関する。
【背景技術】
【０００２】
顧客に販売したシステムや機器は、そのリース契約が切れるまで、顧客が使い続けてくれるとは限らない。ライバル企業の販売攻勢により、営業担当者の知らないうちに、顧客に納入した機器が他社製品にリプレースされてしまう、などということも起こる。できれば、そのような事態は極力避けたい。
そこで、リプレースが起こる前触れとして、リース契約を担当するリース会社に、他社の営業担当者或は顧客自身から、リース契約の解約に関する問い合わせが発生する。この現象を、買い替えを阻止するきっかけとして活用できれば、商機を失わずに済む。
【０００３】
なお、本発明の先行技術文献として、特許文献１を示す。
【特許文献１】特開２００６−３２３７７１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ここで、リース会社の担当者は、電話等によってそのような問い合わせを受けると、販売会社の営業担当者に伝える必要がある。
しかし、このような処理をリース会社の情報システムに実現しようとすると、リース会社の情報システムを構築する際に、販売会社が構築する販売管理システムに深く関わる必要が生じる。すると、システム構築の効率が低下するだけでなく、一方のシステム構築の進捗状況に他方のシステム構築の進捗が左右されてしまう、という不都合が生じる。
複数の企業や部門を跨る業務システムの構築は、その調整だけでも時間が掛かるため、非効率的である。
【０００５】
本発明はかかる点に鑑みてなされたものであり、複数の企業や部門を跨る業務システムにおいて、必要最低限のメッセージの伝達を実現する、メッセージ配信装置及びメッセージ配信プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するための本発明は、メッセージのフォーマットとして、業務番号と任意の情報よりなるものと定める。
このメッセージを、メッセージ受信部が所定の手順にて受信する。
一方、業務番号と送信先と送信方法を列挙格納するサービステーブルを設けておく。
メッセージ送信部は、受信したメッセージに記載されている業務番号でサービステーブルを検索し、得られたレコードに記述されている送信先及び送信方法に従って、メッセージを送信する。
以上のように構成したメッセージ配信装置である。
【０００７】
業務や会社を跨ぐメッセージの送受信を必要最低限の情報量で実現するために、業務番号と任意のメッセージ本文よりなる、メッセージのフォーマットを予め定めておく。
この業務番号毎に送信先と送信方法を記述したテーブルを設ける。このテーブルの内容に従い、受信したメッセージを適切な送信先に、適切な送信方法にて送信する機能を設ける。
【発明の効果】
【０００８】
本発明により、複数の企業や部門を跨る業務システムにおいて、必要最低限のメッセージの伝達を実現する、メッセージ配信装置及びメッセージ配信プログラムを提供できる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施の形態を、図１〜図６を参照して説明する。
【００１０】
図１は、本実施の形態の例である、機器管理システムの全体を示す概略図である。
本実施形態の機器管理システム１０１は、幾つかのｗｅｂサーバ１０２及び１０３と、データベースサーバ（以下「ＤＢサーバ」）１０４と、これらにアクセスする多くのクライアントＰＣ１０５、１０６及び１０７よりなる。また、クライアントＰＣに類する端末として、ハンディターミナル１０８もある。
社内ＬＡＮ１０９は周知のプライベートＩＰアドレスを主体とするＴＣＰ／ＩＰネットワークを構成し、グループ会社をも網羅するものである。
クライアントＰＣ１０５は典型的なパソコンであり、ｗｅｂサーバ１０２にアクセスするための、図示しないｗｅｂブラウザを稼動させている。
ｗｅｂサーバ１０２はそれらグループ会社毎、或は担当業務毎に分離され、分散されている。
ｗｅｂブラウザは周知のネットワーククライアントプログラムであり、ｈｔｍｌ文書を解釈し、システムのユーザインターフェースを提供する。
【００１１】
クライアントＰＣ１０５はｗｅｂサーバ１０２にアクセスする。
ｗｅｂサーバ１０２はＤＢサーバ１０４にアクセスする。
つまり、ｗｅｂサーバ１０２はクライアントＰＣ１０５に対してＤＢサーバ１０４にアクセスする際のユーザインターフェースを提供する。
【００１２】
ｗｅｂサーバ１０２及び１０３とＤＢサーバ１０４は、負荷分散や安全確保等を目的として、また安全確保のための二重化等の構築を容易にするため、それぞれ分散されている。
勿論、システムの規模が小さい場合には、これらを一体化することもできる。
【００１３】
図２はｗｅｂサーバ１０２等とＤＢサーバ１０４の詳細を示す機能ブロック図である。
ｗｅｂサーバ１０２はｗｅｂサーバプログラム２０２と、多くのｃｇｉ（Common Gateway Interface：ｗｅｂサーバがｗｅｂブラウザの要求に応じて、プログラムを起動するための仕組み。）を内包する。
各々のｃｇｉは、社内ＬＡＮ１０９にアクセス可能な従業員を認証するための従業員認証ｃｇｉ２０３を始め、各種ユーザインターフェースを作成するｈｔｍｌ文書を作成するｃｇｉが存在する。
ＤＢサーバ１０４は機器管理システム１０１の中心的な役割を担う、各種データを格納するテーブルを多数抱える。図２ではその一部を示している。
ＤＢサーバ１０４は周知のＳＱＬ（リレーショナルデータベースの操作に特化された言語。）サーバを構成する。
【００１４】
図３はＤＢサーバ１０４に含まれているテーブル群のフィールド名を一部抜粋した概略図である。
従業員テーブル３０２は、従業員を一意に識別する、従業員ＩＤを中心とするテーブルである。フィールドには、「従業員ＩＤ」の他に、従業員の「氏名」と「所属」を示すフィールド等が存在する。また、図示はしないがパスワードのハッシュ値等も含まれ、従業員のログイン認証等に用いられる。
【００１５】
顧客企業テーブル３０３は、顧客企業を一意に識別する、顧客ＩＤを中心とするテーブルである。フィールドには、「顧客ＩＤ」の他に、「顧客企業名」を示すフィールド等が存在する。クライアントＰＣ１０５の表示画面上に所望の顧客企業名を表示させる場合は、このテーブルから「顧客企業名」フィールドの値を取得する。
顧客担当者テーブル３０４は、顧客担当者を一意に識別する、担当者ＩＤを中心とするテーブルである。「担当者ＩＤ」の他に、顧客担当者の「担当者名」と、顧客企業を識別するための「顧客ＩＤ」フィールドが存在する。
顧客設置先テーブル３０５は、顧客に販売した機器を設置する際の設置場所（設置先）を一意に識別する、設置先ＩＤを中心とするテーブルである。「設置先ＩＤ」の他に、「設置場所」と「顧客ＩＤ」フィールドが存在する。
【００１６】
商談テーブル３０６は、商談を一意に識別する、商談ＩＤを中心とするテーブルである。営業担当者が顧客と商談を始めた際に、新規なレコードを起こす。フィールドは、
・「商談ＩＤ」の他に、
・商談の詳細内容の一つとして、商談を開始した日付を示す「商談日付」フィールドや、
・商談の進行状況、またその成果（仮契約、契約成立、契約失敗等）を示す「商談ステータス」フィールド、そして
・顧客企業テーブルの「顧客ＩＤ」、
・顧客担当者テーブルの「担当者ＩＤ」、
・従業員テーブルの「従業員ＩＤ」
が存在する。
【００１７】
契約テーブル３０７は、契約を一意に識別する、契約ＩＤを中心とするテーブルである。一契約につき、一つの新規なレコードを起こす。フィールドは、
・「契約ＩＤ」の他に、
・契約の種別を示す「契約種別ＩＤ」や、
・契約の詳細内容の一つとして、契約を作成した日付を示す「契約日付」フィールド、
・契約の進行状況、またその成果（仮契約、契約成立、契約失敗等）を示す「契約ステータス」フィールド、
・正式に発行された契約書の発行回数を格納する「発行回数ステータス」
が存在する。
【００１８】
商談契約テーブル３０８は、商談と契約との一対多の関係を記述する、「商談ＩＤ」と「契約ＩＤ」の組よりなるテーブルである。つまり、一つの商談について、複数の契約が発生し得る。このテーブルの存在により、契約ＩＤから商談ＩＤ、またその逆の参照が可能になっている。
【００１９】
禁則条件テーブル３０９は、営業担当者が商談を進める際に作成する見積もりにおいて、一緒に販売してはいけない商品や役務の組み合わせを記述するテーブルである。後述する商品基本情報テーブル３１２の「商品コード」或は役務基本情報テーブルの「役務コード」同士の組み合わせが列挙される。
【００２０】
締め日条件テーブル３１０は、コピー機等のカウンタを確認する作業の締め日に関する契約条件を記述するテーブルである。フィールドは、
・その機器がどの契約に属するかを示す「契約ＩＤ」と、
・機器を特定する「商品コード」と
・機器のシリアルナンバー（以下「機番」と呼ぶ。詳細は後述する。）の他に、
・契約の詳細内容の一つとして、締め日の条件を示す「締め日条件」フィールドと、
・「締め日条件」の優先順位を示す「優先順位」フィールド
が存在する。
【００２１】
契約種別テーブル３１１は、契約の種別を列挙するテーブルである。フィールドは、「契約種別ＩＤ」と「契約種別名」が存在する。
【００２２】
商品基本情報テーブル３１２は、商品を一意に識別する、商品コードを中心とするテーブルである。各々の商品を識別するための「商品コード」の他に、「商品名」「商品詳細情報」フィールド等が存在する。
役務基本情報テーブル３１３は、役務を一意に識別する、役務コードを中心とするテーブルである。各々の役務を識別するための「役務コード」の他に、「役務名」「役務詳細情報」フィールド等が存在する。
【００２３】
商品等構成テーブル３１５は、商品または役務と商品との一対多の関係を記述する、「商品コード」または「役務コード」と、「商品コード」または「役務コード」の組よりなるテーブルである。
例えば、コピー機本体には、ソーター、自動両面原稿送り装置、ステープラ等のハードウェアオプション品、またファクシミリ機能、プリンタ機能、スキャナ機能を実現するソフトウェアオプション品等が存在する。更に、当該コピー機に適用可能な保守サービスも存在する。このように、商品の中にはオプションとなる商品又は役務を含むものもある。
また、例えば「安心パック」という名称で、パソコンのメンテナンスサービスとウイルス防御ソフトウェア商品の提供を含む役務が考えられる。このように、役務の中には商品を含むものもある。
以上のような、商品または役務のシステム的構成を記述するために、このようなテーブルを設けている。
【００２４】
契約商品等テーブル３１４は、契約と商品或は役務との一対多の関係を記述する、「契約ＩＤ」と「商品コード」或は「役務コード」の組よりなるテーブルである。つまり、一つの契約について、複数の商品或は役務が発生し得る。また、このテーブルには「機番」と「設置先ＩＤ」等のフィールドが存在する。
【００２５】
機器管理テーブル３１６は本実施形態において中核的な役割を担うテーブルである。
一つの機器（商品）について、「商品コード」と「機番」にて一意に識別し、その機器の顧客に対する納入から、機器の廃棄或はリサイクルまで、「機器の一生」を日付とステータス情報にて逐一記録し、管理するテーブルである。フィールドは、
・「商品コード」と
・「機番」の他に、
・この機器が属する契約を示す、契約テーブル３０７の「契約ＩＤ」、
・この機器が設置されている場所を示す、顧客設置先テーブル３０５の「設置先ＩＤ」、
・この機器の状態を示す「機器稼動ステータス」と
・「機器物流ステータス」、そして
・それらステータス情報を記録した「日付」
が存在する。
【００２６】
カウンタ確認ログテーブル３１７は、主にコピー機に内蔵されている、使用の度にインクリメントされる「カウンタ」の数値を記録するテーブルである。コピー機は使用回数、つまりコピー出力によって消費される用紙の枚数に応じて、使用量が課金される仕組みになっている。そこで、毎月決まった締め日に、コピー機に内蔵されているカウンタの値を確認し、カウンタ確認ログテーブル３１７に記録する。フィールドは、
・「商品コード」と
・「機番」の他に、
・この機器が属する契約を示す、契約テーブル３０７の「契約ＩＤ」、
・「カウンタ値」と
・カウンタ値を取得した状態を示す「カウンタステータス」
が存在する。
【００２７】
契約書テンプレートテーブル３１８は、契約書に必要な雛形のパーツを識別するパーツコードと、テンプレートを識別するテンプレートコードを記録するテーブルである。パーツコードとテンプレートコードに対応する契約書の雛形がテンプレートファイルとして契約書テンプレートテーブル３１８に記録される。
契約書は、以下に記載する５つのパーツが組み合わされて作成される。ただし、ある契約書では必要とされるが、別の契約書では必要とされないパーツも存在する。これら５つのパーツを「基本パターン」とも称する。
・「表紙」…甲乙などの契約関係を表現するパーツ。
・「基本条項」…販売にあたって必要な「基本条項」を表現するパーツ。
・「サービス条項」…モノ（例えば、コピー機、ＰＣ）ではなく、保守サービスなどの付加価値に対する「基本条項」を表現するパーツ。
・「契約料金」…見積時の料金を表現するパーツ。
・「保守対象明細」…保守サービスを契約する場合は、そのサービスは何に対して行うのかを表現するパーツ。
【００２８】
［商談支援］
営業担当者が顧客に商品を売る際、複数の商品や役務を組み合わせて販売することが多くある。
例えば、企業の情報システムの場合は、サーバ、ネットワーク機器、クライアントＰＣ１０５、それらのためのソフトウェア等をセットにして販売する他、それらのメンテナンスの役務も含め、セット販売することが考えられる。
役務の内容によっては、既にソフトウェア等の商品が含まれている場合もある。
つまり、商品構成によっては商品が重複してしまったりすることが考えられる。
また、多くの商品等を購入して貰っている上得意先の場合、既に購入済みの商品等と重複したり、組み合わせてはいけないものを選ばないようにしなければならない。
このため、機器管理テーブル３１６から顧客の過去の購入情報を読み込み、それらと組み合わせてはいけない商品等を禁則条件テーブル３０９から読み出し、見積もりデータから除外する。
【００２９】
［契約書作成支援］
見積書を作成して顧客に提示したら、顧客はその内容に対し、導入するか否かを判断し、営業担当に回答する。
見積書にて作成した商品構成に応じて、選択可能な契約の組み合わせがメニューとして提示される。
顧客が所望の契約内容を選択したら、契約テーブル３０７に契約書を作成するに必要な情報、特に各種条件を示すフラグ情報群を記録し、契約書の雛形を選択的に読み出し、契約書を自動作成する。
また、このときに作成される契約書の条件情報は、販売する機器によっては締め日条件テーブル３１０にその条件を書き出し、カウンタ確認ログテーブル３１７を用いたカウンタ確認督促処理に使用される。
【００３０】
［機器管理］
商談が成立し、いよいよ顧客に商品を出荷する段になったら、営業担当は商談成立をｗｅｂサーバ１０２を通じて入力する。
すると、商談テーブル３０６のステータスが変更され、これに呼応して商品を発注するための商品発注依頼データが、契約テーブル３０７及び契約商品等テーブル３１４から作成され、配送会社が管理する伝票管理サーバに送信される。
伝票管理サーバは商品発注依頼データを受信すると、伝票テーブルに新規に伝票番号を起こし、受信した商品コードを記録する。そして、在庫テーブルに格納されている商品の機番を読み出し、伝票テーブルに記録する。こうして商品コードと機番の関係付けが行われる。なお、これ以降、二つ以上のテーブルの共通するフィールドについて関係付けることを「紐付け」と呼ぶ。
次に、伝票管理サーバは機番をＤＢサーバ１０４の契約商品等テーブル３１４に記録する。そして、機器管理テーブル３１６に新規にレコードを追加し、ステータス情報を記録する。こうして、「当該商品を設置先に出荷した」情報が、機器管理テーブル３１６に記録され、機器の管理が始まる。
これ以後は、役務等の作業が発生する度に、ハンディターミナル等を用いて商品コードと機番を入力することで機器が特定され、日付とステータス情報が追記録される。このような「機器の状態の記録」が、機器の廃棄或はリサイクルによる消滅まで行われる。
【００３１】
［カウンタ確認］
毎月の締め日の前にはコピー機のカウンタの値を確認しなければならない。
ところが、顧客によっては締め日までにカウンタ値を確認できない場合もある。
そのようなときには、予め契約書を作成する際に作成していた、締め日条件テーブル３１０に記録されている「アクション条件」を参照する。
締め日から何日経ったらどのようなカウンタ確認作業をするのか、そしてその作業は既に完遂したのか否かを確認し、適切な指示を担当者に提示する。
【００３２】
［買い替え阻止］
顧客に対する他社の売り込みにより、販売した機器がリプレースされてしまうと、顧客を失うこととなる。これを予防するために、対象契約におけるリース契約解除の際に、リース会社に対して契約解除の手数料の問い合わせが発生した事実を、リース会社担当者がシステムに入力する。
入力のアクションにより、契約テーブル３０７から営業担当者が特定され、当該営業担当者がクライアントＰＣ１０５にて情報システムにアクセスすると、ワーニングメッセージとしてその情報を表示する。
所定の営業活動を行った後に、そのワーニングメッセージは消去される。
【００３３】
以上の概略説明にてわかるように、本実施形態の機器管理システム１０１は、商談から契約、商品の納入、商品の運用、買い替えの予防、そして廃棄に至る迄の、「商品の一生」を営業的側面から管理すると共に、営業活動等を支援する総合的なシステムである。
【００３４】
［買い替え阻止の詳細］
図４は、本実施形態の機器管理システム１０１のうち、買い替え阻止機能に注目した部分の機能を説明する、ブロック図である。
図４の、点線で区分けされている部分は、グループ企業の各会社を表す。親会社４１１と販売会社４１３とリース会社４１２は、同一系列企業である。
リース会社４１２に勤務するリース担当者４０８は、クライアントＰＣ４１５を操作して、リース会社ｗｅｂサーバ４０２にアクセスし、所定の業務を遂行する。
販売会社４１３に勤務する営業担当者４０９は、クライアントＰＣ４１６を操作して、販売会社ｗｅｂサーバ４０４にアクセスし、所定の業務を遂行する。
リース会社ｗｅｂサーバ４０２と販売会社ｗｅｂサーバ４０４は、親会社４１１に備え付けられているＤＢサーバ１０４にアクセスする。
【００３５】
顧客に販売したシステムや機器は、そのリース契約が切れるまで、顧客が使い続けてくれるとは限らない。ライバル企業の販売攻勢により、営業担当者の知らないうちに、顧客に納入した機器が他社製品にリプレースされてしまう、などということも起こる。できれば、そのような事態は極力避けたい。
そこで、リプレースが起こる前触れとして、リース契約を担当するリース会社４１２に、他社の営業担当者或は顧客自身から、リース契約の解約に関する問い合わせが発生する。この現象を、買い替えを阻止するきっかけとして活用できれば、商機を失わずに済む。
【００３６】
ここで、リース会社４１２の担当者は、電話等によってそのような問い合わせを受けると、販売会社４１３の営業担当者に伝える必要がある。
しかし、このような処理をリース会社ｗｅｂサーバ４０２上に実現しようとすると、リース会社ｗｅｂサーバ４０２の処理内容が、販売会社４１３が構築する販売管理システムに深く立ち入ることとなってしまう。つまり、このような機能を実現するには、リース会社ｗｅｂサーバ４０２を構築する際に、販売会社ｗｅｂサーバ４０４の構築にも関わらなければならない。すると、システム構築の効率が低下するだけでなく、一方のシステム構築の進捗状況に他方のシステム構築の進捗が左右されてしまう、という不都合が生じる。
複数の企業や部門を跨る業務システムの構築は、その調整だけでも時間が掛かるため、非効率的である。
【００３７】
ところで、リース会社４１２から販売会社４１３に伝えたいことは、「ある日ある時に、ある契約ＩＤにおいて、契約解除の虞が生じた事実」という、必要最低限の情報である。リース会社４１２は、販売会社４１３が当該情報を受けて、然るべき営業担当者に伝えてくれるならば、わざわざ営業担当者の氏名等を知る必要はないのである。
そこで、このような「必要最低限の情報を伝えるだけの仕組み」を、本システムに導入する。
【００３８】
業務内容や会社を跨ぐ必要のある情報のやり取りについては、統一的なメッセージの送り先を決める。
そして、メッセージのフォーマットとして、業務内容に応じた番号と、メッセージの内容を決める。
最低限、業務内容に応じた番号と、これを取り出すための仕組みは、システムの全体として一意になるように決定する。
メッセージの内容は、メッセージの送信元と送信先との間で合意が取れていれば、基本的にはどのような形式であってもよい。極端な場合では、メッセージがなくても成り立つ。
メッセージのフォーマットさえ決めてしまえば、後はお互いのシステム構築の進捗状況に左右されることなく、迅速且つ確実なシステム構築ができる。また、業務内容が完全に切り分けられるので、責任範囲が明確化する。
【００３９】
メッセージ配送部４０５は、上述した、様々なメッセージの送受信を一手に引き受けるプログラムである。メッセージ配送部４０５は、同じ販売会社ｗｅｂサーバ４０４内のｃｇｉ４０７や、会社や業務を跨る他のｗｅｂサーバのｃｇｉ（図４ではその一例としてリース会社ｗｅｂサーバ４０２のｃｇｉ４０３）、またｃｇｉ以外にも多種多様なプログラムが発するメッセージを受信する。そして、受信したメッセージの先頭に記される業務番号に応じて、他のプログラムやサーバ等、適切な配送先にメッセージを配送する。
図４では一例として、同じ販売会社ｗｅｂサーバ４０４内のデーモンプログラム４０６に配送しているが、これ以外にも多数の配送先が存在する。
【００４０】
図５は、メッセージ配送部４０５の機能ブロック図である。
メッセージ受信部５０２は幾つかの手段を用いて、外部からメッセージを受信する。図５ではその一例として、周知の名前付きパイプ５０３とＴＣＰ特定ポート５０４を設けている。
名前付きパイプ５０３はＰＯＳＩＸ（Portable Operating System Interface for UNIX（登録商標））系ＯＳを始めとして、多くのネットワークＯＳで周知である。
ＴＣＰ特定ポートは、ＴＣＰの所定のポート番号にてメッセージを受信するインターフェースを設けることを意図している。
メッセージ受信部５０２を通じて受信したメッセージは、メッセージスプーラ５０５を通じて、スプールディレクトリ５０６に、ファイルとして一旦蓄えられる。蓄えられたメッセージはメッセージ送信部５０７にて、順次送信される。送信先と送信方法は、メッセージの先頭に記されている業務番号に応じて、サービステーブル５０８に記述されている通りに行われる。
【００４１】
サービステーブル５０８は、
・業務番号、
・送信先、そして
・送信方法
の、三つのフィールドを備えるテーブルである。
サービステーブル５０８は、受信したメッセージを、適切な送信先に、適切な送信方法にて送信するためのテーブルである。つまり、メッセージ送信のルールを列挙記述したテーブルである。
【００４２】
メッセージの送信方法は以下の通りである。
先ず、スプールディレクトリからメッセージスプーラを通じてメッセージを取り出す。
次に、取り出したメッセージの先頭に位置する業務番号でサービステーブル５０８を検索し、該当するレコードを特定する。
そして、特定したレコードの送信先フィールドと送信方法フィールドを読み込み、指定された送信先に対し、指定された送信方法にて送信する。
【００４３】
送信先は、ネットワーク越しであれば、ＵＲＬ（Uniform Resource Locator：ＴＣＰ／ＩＰネットワーク上に存在する情報資源（文書等）の場所を指し示す記述方式。）を記述する。同一マシン内のプログラムであれば、当該プログラム名をフルパスで記述する。
送信方法は、名前付きパイプやプロトコル名を記述する。
なお、複雑な送信方法を行う際には、送信先フィールドを空欄にして、送信方法にシェルスクリプト等のプログラム名を記述し、そのプログラムにメッセージの送信を任せる、という方法もできる。その際には、メッセージを一時的にファイルにして、当該プログラムに渡すか、或はパイプを用いて当該プログラムにメッセージを渡す等の方法が考えられる。
【００４４】
図６は、メッセージのフォーマットを示す概略図である。
図６（ａ）は、メッセージの基本的なフォーマットを示す概略図である。
メッセージの先頭は業務番号が格納される。
業務番号の次に、フィールドセパレータとしての改行コード（ＣＲ・ＬＦ）が続く。
改行コードの次に、メッセージ本文が続く。
【００４５】
メッセージ本文は任意である。必須の存在ではない。極端な例で言えば、業務番号と改行だけのメッセージも存在し得る。受信するアプリケーション側がそれを認識して所定の作業を遂行できれば良いのである。
メッセージを記述する際の文字コードは特に問わないが、可読性向上のため、業務番号を含め、全てテキストであることが望ましい。もし、バイナリデータを送信する際には、Ｂａｓｅ６４形式等、幾つかの周知の技術にて、バイナリデータをテキストデータに変換することで対応が可能である。
可読性を高めることは、例えばメッセージスプーラにログ記録機能を備えておき、システム全体の挙動を確認し、不慮の事故等に対応する際に、有用である。
【００４６】
なお、メッセージのフィールドを区別する方法は、周知の様々な方法を採用することができる。
フィールドセパレータは改行コードに限らず、メッセージと衝突しなければ、任意の文字コードを定めることができる。
業務番号の長さを固定長にすれば、業務番号とそれ以降のメッセージを区別するためのフィールドセパレータは不要になる。
また、メッセージは全てＸＭＬ（Extensible Markup Language：文書やデータの意味や構造を記述するためのマークアップ言語の一つであり、ＨＴＭＬより拡張性が高い。）であるものと定義すれば、ＸＭＬを記述する最初の文字である「<」以外の文字であれば、フィールドセパレータとして何でも利用可能になる。
【００４７】
図６（ｂ）及び（ｃ）は、メッセージの一例を示す概略図である。ここでは、リース会社４１２の担当者が契約解除の予兆情報を伝える際に、リース会社ｗｅｂサーバ４０２を通じて、販売会社ｗｅｂサーバ４０４へ送信するメッセージの中身を示す。
最初のフィールドは業務番号である「３３６４」という数字である。そして、フィールドセパレータの改行コードが続く。なお、図６（ｃ）ではこれを「定型部」として記述している。
ここまでが、メッセージの全体的なフォーマットとして決められている事項である。これ以降は任意のデータである。したがって、これ以降説明する事項は、リース会社ｗｅｂサーバ４０２を構築する者と、販売会社ｗｅｂサーバ４０４を構築する者同士が、お互いの合意で決めたルールである。図６（ｃ）ではこの部分を「任意部」として記述している。
【００４８】
次のフィールドは契約ＩＤである。ライバル会社の営業担当或は顧客が、契約解除を問い合わせてきた案件を特定するために必要な情報である。
次のフィールドはメッセージコードである。これは、リース会社ｗｅｂサーバ４０２を構築する者と、販売会社ｗｅｂサーバ４０４を構築する者同士が、お互いの合意で決めたメッセージコードである。その数字にどのような意味があるのかは、リース会社ｗｅｂサーバ４０２を構築する者と、販売会社ｗｅｂサーバ４０４を構築する者同士が理解できる事項である。図６（ｃ）では「４４４」という数字が記述されている。販売会社ｗｅｂサーバ４０４は、これが「契約解除の問い合わせがあった」ことを意味するコードとして、解釈できる。
次のフィールドは備考欄である。つまり、任意のテキストメッセージである。
リース会社４１２の担当者は、案件を特定した契約を担当する営業担当者の名前を知らない。必要なことは、担当者に必要事項を伝えることができればよいのである。そこで、「担当が誰かは知らないけれども、必要な情報をお伝えします」という意味を込めた文章が、リース担当者の任意で添えられる。
【００４９】
上述の実施形態では、リース会社から販売会社へ契約解除の予兆情報を伝達する際の事例で説明したが、伝達するメッセージの種類や、メッセージの送信者と受信者はこれに限られない。
以上説明したメッセージ配送の仕組みは、ＭＴＡ（Mail Transfer Agent：電子メールをネットワーク経由で配送するソフトウェア。）に似ているが、業務番号と送信方法等を記したテーブルの有無の点、また送信方法が任意に決定できる点等で大きく相違する。
【００５０】
本実施形態においては、情報伝達システムを開示した。
以上の概略説明にてわかるように、本実施形態の機器管理システム１０１が備える情報伝達機能は、責任範囲を明確に区分けしなければならない、大規模なｗｅｂアプリケーションシステムの構築において、各々のｗｅｂサーバの構築の独立性を担保することができる。つまり、各々のｗｅｂサーバの構築の進捗状況が、システム全体の構築の足を引っ張るような状況を極力防ぐことができる。
この仕組みにより、業務や会社を跨った情報伝達を、互いのシステムの中身を知ることなく、迅速且つ確実に実現することができる。
【００５１】
以上、本発明の実施形態例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含むことは言うまでもない。
【図面の簡単な説明】
【００５２】
【図１】本発明の一実施の形態による機器管理システムの全体を示す概略図である。
【図２】ｗｅｂサーバ等とＤＢサーバの詳細を示す機能ブロック図である。
【図３】ＤＢサーバに含まれているテーブル群のフィールド名を一部抜粋した概略図である。
【図４】本実施形態の機器管理システムのうち、買い替え阻止機能に注目した部分の機能を説明する、ブロック図である。
【図５】メッセージ配送部の機能ブロック図である。
【図６】メッセージのフォーマットを示す概略図である。
【符号の説明】
【００５３】
１０１…機器管理システム、１０２、１０３…ｗｅｂサーバ、１０４…ＤＢサーバ、１０５、１０６、１０７…クライアントＰＣ、１０８…ハンディターミナル、１０９…社内ＬＡＮ、２０２…ｗｅｂサーバプログラム、２０３…従業員認証ｃｇｉ、３０２…従業員テーブル、３０３…顧客企業テーブル、３０４…顧客担当者テーブル、３０５…顧客設置先テーブル、３０６…商談テーブル３０６、３０７…契約テーブル３０７、３０８…商談契約テーブル、３０９…禁則条件テーブル、３１０…締め日条件テーブル、３１１…契約種別テーブル、３１２…商品基本情報テーブル３１２、３１３…役務基本情報テーブル、３１４…契約商品等テーブル、３１５…役務商品テーブル、３１６…機器管理テーブル、３１７…カウンタ確認ログテーブル、４０２…リース会社ｗｅｂサーバ、４０３、４０７…ｃｇｉ、４０４…販売会社ｗｅｂサーバ、４０５…メッセージ配送部、４０６…デーモンプログラム、４０８…リース担当者、４０９…営業担当者、４１１…親会社、４１２…リース会社、４１３…販売会社、４１５、４１６…クライアントＰＣ、５０２…メッセージ受信部、５０３…名前付きパイプ、５０４…ＴＣＰ特定ポート、５０５…メッセージスプーラ、５０６…スプールディレクトリ、５０７…メッセージ送信部、５０８…サービステーブル
【図１】
2008250880.tif 000003
【図２】
2008250880.tif 000004
【図３】
2008250880.tif 000005
【図４】
2008250880.tif 000006
【図５】
2008250880.tif 000007
【図６】
2008250880.tif 000008