JP2006190108A

JP2006190108A - 医薬ビジネス情報共有システム

Info

Publication number: JP2006190108A
Application number: JP2005001784A
Authority: JP
Inventors: Modde Jean-Paul; ジャン・ポールモッド
Original assignee: DENDRITE JAPAN CORP
Current assignee: DENDRITE JAPAN CORP
Priority date: 2005-01-06
Filing date: 2005-01-06
Publication date: 2006-07-20

Abstract

【課題】多数の製薬会社と多数の卸会社とが、多数のターゲットに関して、情報を共有すること。
【解決手段】製薬会社のユーザは、エディタを用いてプロモーションの依頼を作成する。作成されたプロモーションの依頼は、クライアント機１からＷＥＢサーバ２００を介してデータベース１１０に保存される。このデータベース１１０に予め登録されている卸会社を作成したプロモーションの依頼に対し、１：多で関連づける。関連づけられた卸会社は、依頼のあったプロモーションを実施し、その結果をデータベース１１０に登録する。製薬会社は、登録された回答結果をデータで受けることができる。
【選択図】図５

Description

本発明は医薬ビジネス情報共有システムに関する。

医薬業界においては、製薬会社が複数の卸会社と取引して、種々の営業活動を行っている。そのような営業活動においては、対象となるターゲット（病院、クリニック、或いは個人の医師）に対する市場調査、製品の販促活動等のプロモーション活動や、上記ターゲット施設そのものの情報の共有化が含まれている。

従来、製薬会社と卸会社との間で行われるプロモーション等の営業活動や情報の交換は、それぞれの製薬会社が個別に卸会社と契約して、プロモーション活動を紙媒体で行ない、その結果を紙媒体、個人間の電子メール、卸会社固有の形式でのデータ交換、または口頭で行なっているに過ぎなかった。そのため、いわゆるＷｅｂ−ＥＤＩ（Ｗｅｂ − ＥｌｅｃｔｒｏｎｉｃＤａｔａＩｎｔｅｒｃｈａｎｇｅ：電子データ交換）を実現し、データの二次加工や様式の標準化、共通化を図ることが望まれている。

医薬に関する販促情報を電子データ交換するためには、製薬会社と卸会社との間で情報のフォーマットを標準化し、共通化されたフォーマットを管理運営していかなければならない。

しかし、図１に示すように、製薬会社と卸会社とは、それぞれが５０以上の多：多の関係で取引をしている。

さらに図２に示すように、製薬会社と卸会社とは、それぞれが数千、数万の多数のターゲットと多：多の関係で取引や販促活動を行っている。

加えて、図２に示すように、各製薬会社と卸会社は、それぞれが、本店、支店、営業所、課を有し、各会社の担当者毎にターゲットが決められている。また、製薬会社の担当者においては、いわゆるＭＲ（医薬情報提供者：ＭｅｄｉｃａｌＲｅｐｒｅｓｅｎｔａｔｉｖｅ）や、その上司（上長）、卸会社にあっては、いわゆるＭＳ（マーケッティングスペシャリスト）や、その上司（上長）が含まれる。

そのため、製薬会社が個々のプロモーション結果をＭＲに通知したり、集計や分析を行なうことは、負担が大きく、現状では行われていなかった。また、卸会社にとっても、製薬会社毎にフォームの異なる紙媒体で対応することが通常は必要になり、ＭＳの活動効率に支障を来したり、活動品質の低下を招く等の問題に繋がっていた。

本発明は上記不具合に鑑みてなされたものであり、多数の製薬会社と多数の卸会社とが、多数のターゲットに関して、情報を共有することのできる医薬ビジネス情報共有システムを提供することを課題としている。

上記課題を解決するために、本発明は、製薬会社を一元的に管理するための属性を有する製薬マスタエンティティ、製薬マスタエンティティに対して１：多のカーディナリティで関連可能な外部キー属性を有し、製薬会社の担当者を一元的に管理するための属性を有する製薬ユーザエンティティ、卸会社を一元的に管理するための属性を有する卸マスタエンティティ、卸マスタエンティティに対して１：多のカーディナリティで関連可能な外部キー属性を有し、卸会社の担当者を一元的に管理するための属性を有する卸ユーザエンティティ、製薬会社と卸会社との間で情報共有の対象となるターゲットを一元的に管理するための属性を有するターゲットマスタエンティティ、製薬会社と卸会社の何れかの担当者が発信する依頼情報を記録する属性を有する発信マスタエンティティ、発信マスタエンティティと１：多のカーディナリティで関連可能な外部キー属性を有し、発信された依頼情報に対する回答を記憶する属性を有する回答用のエンティティとを記憶するデータベースと、このデータベースのエンティティを管理するデータベースマネジメントシステムと、このデータベースとクライアント機との間でトランザクションを実行するサーバシステムとを備えた医薬ビジネス情報共有システムであって、上記データベースは、製薬マスタエンティティと卸マスタエンティティとを多：多のカーディナリティで関連づける属性を主キーとする製薬／卸連関エンティティと、卸ユーザエンティティとターゲットエンティティとを多：多のカーディナリティで関連づける属性を主キーとするターゲット／ユーザ連関エンティティと、ターゲットエンティティと発信マスタエンティティとを多：多のカーディナリティで関連づける属性を主キーとする対象ターゲット管理連関エンティティと、発信マスタエンティティと卸マスタエンティティとを多：多で関連づける属性を主キーとする依頼先登録マスタテーブル連関エンティティとを記憶していることを特徴とする医薬ビジネス情報共有システムである。

この態様では、製薬マスタエンティティに製薬会社の情報が、製薬ユーザエンティティに製薬会社の担当者の情報が、卸マスタエンティティに卸会社の情報が、卸ユーザエンティティに卸会社の担当者の情報が、ターゲットエンティティにターゲットの情報が、発信マスタエンティティに依頼情報が、それぞれ記憶される。

加えて、製薬／卸連関エンティティによって、製薬マスタエンティティに管理される製薬会社の情報が卸マスタエンティティに管理される卸会社の情報と多：多で関連づけられ、ターゲット／ユーザ連関エンティティによって、卸会社の担当者とターゲットとが多：多で関連づけられ、対象ターゲット管理連関エンティティによって、ターゲットと依頼情報とが多：多で関連づけられ、依頼先登録マスタテーブル連関エンティティによって、依頼情報と依頼先となる卸会社とが多：多で関連づけられる。この結果、ある特定の依頼情報について、複数のターゲットと、複数の卸会社または卸会社の担当者とを任意に組み合わせて関連づけて、管理することができる。従って、例えば、依頼情報として、製薬会社がプロモーション依頼を作成した場合、このプロモーション依頼に対して、複数の卸会社を指定することができるとともに、卸会社は、自分が指定されたプロモーション依頼に対し、複数のターゲットを関連づけて、プロモーションを実施することが可能になる。また、このプロモーション依頼に対して、卸会社の担当者は、依頼元の製薬会社に対し、回答情報を関連づけて返信することが可能になる。なお、「エンティティ」とは、いわゆるコッド（Ｃｏｄｄ）が１９７０年に提案したリレーショナルデータベースモデル理論にいうリレーションを実装したデータ群をいい、具体的には、二次元のデータ構造で表される有限部分集合である。「タプル」とは、同理論における二次元のデータ構造の行を意図している。「属性」とは、同理論におけるアトリビュートのことをいい、タプルを構成する列を意図している。さらに、「カーディナリティ」とは、同理論に基づく、ＥＲモデルにおいて、あるエンティティと別のエンティティとが相互に関連する関係をいい、１：１、１：多、多：１、多：多がある。「連関エンティティ」とは、二つのエンティティを多：多のカーディナリティで関連づけるために、両エンティティからそれぞれ１：多の関係で関連づけられるエンティティをいう。

また、回答用のエンティティとしては、正規化理論に基づき、複数のエンティティ（スキーマ）に分割された構成であってもよい。また、担当者は、製薬会社にあっては、いわゆるＭＲ（医薬情報提供者：ＭｅｄｉｃａｌＲｅｐｒｅｓｅｎｔａｔｉｖｅ）や、その上司（上長）、卸会社にあっては、いわゆるＭＳ（マーケッティングスペシャリスト）が含まれる概念である。

本発明の別の態様において、上記発信マスタエンティティは、製薬会社用と卸会社用とに独立して記憶されている。この態様では、製薬会社用の発信マスタエンティティと依頼先登録エンティティとを用いて、製薬会社が卸会社との間で情報の共有化を図ることができるとともに、卸会社も卸会社用の発信マスタエンティティと卸登録エンティティとを用いて、特定の企業と特定の情報を共有することが可能になる。

本発明のさらに別の態様において、上記データベースは、卸マスタエンティティを親として直系の１：多のカーディナリティで関連づけられ、卸会社の組織を特定する属性を有する複数の卸組織エンティティを有し、上記卸登録マスタエンティティは、卸マスタエンティティ、各卸組織エンティティ、並びに卸ユーザエンティティとそれぞれ１：多のカーディナリティで関連づけられる外部キーを有している。この態様では、依頼情報と依頼先とを関連づける場合、依頼情報を必要に応じて、卸組織エンティティに特定される組織または卸ユーザエンティティに特定される個人とを関連づけることが可能になる。卸組織エンティティとしては、卸会社の本店を特定する卸本店エンティティ、支店を特定する卸支店エンティティ、営業所を特定する卸営業所エンティティ、課を特定する卸課エンティティが例示される。また、直系の１：多のカーディナリティとは、卸エンティティに対して卸本店エンティティが１：多、卸本店エンティティに対して卸支店エンティティが１：多、・・・であることを意味している。

本発明のさらに別の態様において、上記データベースは、上記製薬ユーザエンティティに対し、１：多のカーディナリティで関連可能な外部キー属性を有する製薬ユーザ担当ターゲットエンティティと、この製薬ユーザ担当ターゲットエンティティと上記ターゲットマスタテーブルとを多：多のカーディナリティで関連づける属性を主キーとする担当ターゲット／ターゲットリンク連関エンティティとを記憶している。この態様では、製薬会社の担当者が、商品説明や販促等で担当しているターゲットを有している場合において、担当者毎に、複数の担当ターゲットを設定できるとともに、設定された担当ターゲットの情報と依頼情報とを、ターゲットマスタエンティティ及び対象ターゲット管理連関エンティティに基づいて、多：多のカーディナリティで関連づけることができる。この結果、例えば、製薬会社から依頼されたプロモーションの回答を卸会社が行う際に、当該プロモーションに係るターゲットを担当する製薬会社の担当者を担当ターゲット／ターゲットリンク連関エンティティから特定し、この担当者に対して情報を提供する等のサービスを行うことが可能になる。

本発明のさらに別の態様において、上記データベースは、発信マスタエンティティに対して１：多のカーディナリティで関連可能な外部キー属性を有し、依頼情報として発信マスタエンティティに登録される依頼情報の意思表示項目を生成するための属性を有する意思表示マスタエンティティと、この意思表示マスタエンティティに対して１：多のカーディナリティで関連可能な外部キー属性を有し、当該意思表示マスタエンティティの意思表示項目に対する回答を生成するための属性を有する回答用のエンティティとを有している。この態様では、依頼情報の依頼フォームを生成する場合、依頼情報毎に、種々の意思表示項目と、各意思表示項目に対する複数の回答とを設定して、多様な依頼フォームを生成することが可能になる。例えば、一つの意思表示項目に対し、ＹＥＳ／ＮＯ型の回答、自由書式の回答、トグルボタンでの回答等を設定し、多様な様式のプロモーション依頼フォームを生成し、依頼情報の作成エディタとしてクライアント機に提供することが可能になる。上記「意思表示項目」は、主として、質問項目を意図しているが、それに限らず、例えば、依頼元の担当者が依頼先に対する指示や注意事項の表示を含む概念である。

本発明のさらに別の態様において、上記データベースマネジメントシステムは、上記発信マスタエンティティと卸登録マスタエンティティとをユニオン結合したメインテーブルと、上記意思表示マスタエンティティと卸登録マスタエンティティとをユニオン結合した意思表示テーブルと、上記回答用のエンティティと卸登録マスタエンティティとをユニオン結合した回答テーブルとを生成するものであり、上記回答マスタテーブルは、上記メインテーブルに対して１：多で関連づけられているものである。この態様では、発信マスタエンティティ、意思表示マスタエンティティ、回答用のエンティティについて、それぞれ卸登録マスタエンティティとユニオン結合されたテーブルが生成されることにより、回答用のエンティティの処理速度が速くなる。

本発明のさらに別の態様において、上記データベースマネジメントシステムは、回答用のエンティティに記録された履歴回数をカウントしたサマリテーブルを生成するものである。この態様では、サマリテーブルにアクセスすることにより、共有されるべき情報毎に各情報の履歴や頻度を集計し、課金管理等に供することが可能になる。

本発明のさらに別の態様において、上記サーバシステムは、依頼元からの依頼情報と依頼先とを関連づける依頼情報／依頼先関連情報の入力手段を含み、製薬会社と卸会社のうち何れかの依頼元に対して、依頼情報の作成または修正用のエディタを、認証を受けたアカウントを有するクライアント機に提供する作成編集エディタ提供手段と、提供された作成編集エディタによって生成された依頼情報を発信マスタエンティティに記録するとともに、上記入力情報によって入力された依頼情報／依頼先関連情報を依頼先登録マスタテーブル連関エンティティに記録する発信情報記録手段とを備えている。この態様では、依頼元となる製薬会社または卸会社に対して、プロモーション等の依頼情報の作成編集エディタが提供され、依頼元のオペレータは、クライアント機に提供された作成編集エディタに基づいて、フォーマットの標準化された依頼情報を作成または編集することが可能になる。さらに、作成編集エディタの入力手段によって、依頼情報／依頼先関連情報を依頼先登録マスタテーブル連関エンティティに登録することができるので、作成または編集された依頼情報と依頼先とを多：多で関連づけることができる。

上記サーバシステムは、発信マスタエンティティに記録された依頼情報を依頼先となる会社に提供する依頼情報提供手段と、提供された依頼情報に対する回答を入力するための回答エディタを、認証を受けたアカウントを有するクライアント機に提供する回答エディタ提供手段と、提供された回答エディタによって入力された回答情報を回答用のエンティティに記録する回答情報記録手段と、回答された情報を依頼先に提供する回答提供手段とを備えている。この態様では、依頼先には、プロモーション依頼情報提供手段によって、作成された依頼情報が提供されるので、依頼先の担当者は、提供された依頼情報を出力し、必要な対応を行なうことができる。例えば、依頼情報がプロモーションの実施依頼である場合、これをプリントアウトする等して出力し、取引先のターゲットに対してプロモーションを行ない、その結果を回答エディタ提供手段を用いて入力することが可能になる。そして、この回答情報は、回答提供手段によって、依頼先に提供されるので、依頼者は、何ら、プロモーションの書式について、各社毎に取り決めを行なうことなく、標準化された回答情報を得ることが可能になる。

本発明のさらに別の態様において、上記回答用のエンティティは、保存される回答情報に対して、当該回答情報者の上司が付加する上長情報を保存する属性を有し、上記サーバシステムは、回答情報者の上司に対し、保存される回答情報に対して上記上長情報を付加する上長確認入力エディタを提供する情報付加エディタ提供手段を有している。この態様では、担当者の回答に対し、上司がコメントや承認等の情報を上長情報として付加することができるとともに、上長が付加した情報を含めて、依頼元に提示することもできる。

本発明のさらに別の態様において、上記回答用のエンティティは、依頼元の担当者に回答を提供するための条件となる値をフラグとして保存する属性を有し、上記回答提供手段は、上記回答用エンティティの上記条件となる値に基づき、許可された回答のみを依頼先に提供するものであるするものである。この態様では、回答を提供するための条件となる値をフラグとして、依頼元と依頼先とが交わした契約内容に基づき設定することができる。上記「回答を提供するための条件となる値」は、単数であってもよく、複数であってもよい。また、「値」とは、数値に限らず、文字列を含む概念である。依頼先から依頼元に回答を送る場合、この「回答」は、通常は、依頼先が依頼元に課金する有料コンテンツである。従って、依頼先、依頼元の双方において、この有料コンテンツとしての「回答」が、契約通りの条件で提供されることが必要になる。本態様では、回答用のエンティティによって、課金対象となる「回答」の提供を契約内容に基づいて管理されるので、回答の課金管理が確実となり、取引が安全に行なわれることになる。

本発明のさらに別の態様において、上記回答エディタ提供手段は、依頼先が一時的にデータを保存するための一時保存フラグを入力する手段を有し、上記回答用のエンティティは、上記一時保存フラグを保存するための属性を有し、上記回答用のエンティティは、上記条件となる値として、一時保存フラグを保存するための属性を有するものである。

この態様では、依頼先が回答情報を入力するに当たり、一時的にデータベースに回答を保存しておくことによって、回答先を依頼先に提出することを留保することができる。

さらに別の具体的な態様において、上記回答用のエンティティは、上記条件となる値として、上長の承認を保存する属性を有している。その場合には、上長の承認の有無に基づき、例えば、上長の承認があった場合にのみ回答を依頼先に提供する、といった設定が可能になる。

本発明のさらに別の態様において、上記データベースは、上記製薬ユーザエンティティに対し、１：多のカーディナリティで関連可能な外部キー属性を有する製薬ユーザ担当ターゲットエンティティと、この製薬ユーザ担当ターゲットエンティティと上記ターゲットマスタテーブルとを多：多のカーディナリティで関連づける属性を主キーとする担当ターゲット／ターゲットリンク連関エンティティとを記憶し、上記回答提供手段は、担当ターゲット／ターゲットリンク連関エンティティによって特定される依頼元のユーザが存在する場合に、当該依頼元のユーザのメールアドレスに回答が更新された旨を報知する電子メールを自動送信するものである。この態様では、依頼先に対して回答が提供されるタイミングで、電子メールにより、担当者に報知することが可能になる。従って、担当者は、可及的に速やかに、依頼情報に対する回答があったことを知ることができる。

本発明のさらに別の態様において、上記データベースは、ユーザエンティティに対して１：多のカーディナリティで関連づけられる外部キー属性を有し、ユーザ毎に種類の異なる報告情報を特定する属性を含むアラートエンティティを記憶し、上記回答提供手段は、担当ターゲット／ターゲットリンク連関エンティティによって特定される依頼元のユーザが存在しない場合に、アラートエンティティによって特定されるユーザに対して回答が更新された旨を報知する電子メールを自動送信するものである。この態様では、ターゲットを直接担当する担当者がいない場合や、ターゲットや担当者登録に漏れがあった場合でも、予めアラートエンティティに設定されたユーザに対して報知用の電子メールを自動配信することが可能になる。

以上説明したように、本発明によれば、多数の製薬会社と多数の卸会社とが標準化された依頼情報や依頼情報に基づく回答を交換し、多数のターゲットに対して営業情報を共有化することができるという顕著な効果を奏する。

以下、添付図面を参照しながら、本発明の好ましい実施形態について詳述する。

図３、図４は、本発明の実施の一形態に係る情報共有システム１０の概略構成を示す構成図である。

これらの図を参照して、情報共有システム１０は、データベースサーバ１００と、ＷＥＢサーバ２００と、ＦＴＰサーバ３００と、メールサーバ４００とを備えたシステムである。

クライアント機１〜３は、ＴＣＰ／ＩＰプロトコルによって、インターネットに接続可能な環境と、インターネット経由で配信されるＨＴＭＬテキストをＧＵＩで表示するブラウザＢとを有している種々の情報処理装置によって具体化することが可能であり、図示の例では、パーソナルコンピュータ１、ＰＤＡ（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌ（Ｄａｔａ）Ａｓｓｉｓｔａｎｔｓ）２、携帯電話３が採用される。

データベースサーバ１００は、多数のテーブルをエンティティとして有するデータベース１１０と、このデータベース１１０を管理するデータベースマネジメントシステム１１５とを有している。

また、ＷＥＢサーバ２００、ＦＴＰサーバ３００、メールサーバ４００は、一台または複数台のサーバ用オペレーティングシステムがインストールされたサーバシステム５００によって実現されているものである。

ＷＥＢサーバ２００は、例えばマイクロソフト社製のＩＩＳ（ＩｎｔｅｒｎｅｔＩｎｆｏｒｍａｔｉｏｎＳｅｒｖｅｒ）等のミドルウェア２０１と、このミドルウェア２０１上で機能し、例えばＴＣＰ／ＩＰプロトコルによって、クライアント機１〜３とＨＴＭＬの送受信を行なう通信機能やＨＴＭＬを生成する機能を有するサーバスクリブティングプログラム（例えばマイクロソフト社製のＡＳＰ（ＡｃｔｉｖｅＳｅｒｖｅｒＰａｇｅｓ））２０２と、サーバスクリブティングプログラム２０２に対して、分散オブジェクトプログラムの仕様でプログラム部品を提供する多数のコンポーネントオブジェクト（例えばマイクロソフト社製のＣＯＭ＋）２０３と、各コンポーネントオブジェクト２０３と接続されるデータアクセスコンポーネント（例えばマイクロソフト社製のＡＤＯＯＬＥＤＢ（ＡｃｔｉｖｅＸＤａｔａＯｂｊｅｃｔ））２０４と、このデータアクセスコンポーネント２０４とデータベースサーバ１００のデータベースマネジメントシステム１１５との間でインターフェースプログラム（例えばマイクロソフト社製のＯＤＢＣ（ＯｐｅｎＤａｔａｂａｓｅＣｏｎｎｅｃｔｉｖｉｔｙ））２０５とを機能的に備えており、これらのプログラム機能を用いて、後述するフローに基づき、クライアント機１、２、３と通信し、所定の条件でデータベースサーバ１００のデータベース１１０に接続して、データの送受信を行なうとともに、トグルボタンやリストボタン等、種々のＧＵＩオブジェクトを利用可能な画面をＨＴＭＬで生成するものである。また、ＷＥＢサーバ２００は、クッキー（Ｃｏｏｋｉｅ）によって、クライアント機１〜３のユーザ情報を交換可能にしている。図示の実施形態では、データベースサーバ１００とＷＥＢサーバ２００とは、いわゆる２層型のサーバシステムを構築しているが、ＷＥＢサーバ２００からビジネスファンクション層を分離させた３層型のサーバシステムを採用してもよい。

ＦＴＰサーバ３００は、クライアント機１〜３とデータベースサーバ１００との間でトランザクションを処理するためのものであり、後述するフローチャートに基づいて、データの送受信をクライアント機１〜３とデータベースサーバ１００との間で行っている。このＦＴＰサーバ３００には、登録されている会社毎に共有フォルダ３０１が形成されており、ファイルの交換は、ＦＴＰサーバ３００の共有フォルダ３０１を介してクライアント機１〜３とデータベースサーバ１００との間で行われることになる。ＦＴＰサーバ３００は、ＷＥＢサーバ２００が構築されているサーバ機にインストールされて、ＦＴＰデーモン３０２を常駐させている。

メールサーバ４００は、ＳＭＴＰサーバ４０１とＰＯＰサーバ４０２とを機能的に有する周知の構成のものである。

図５は、情報共有システム１０を利用したワークフローを示す説明図である。

次に、同図を参照して、標準的なフローにおいて、依頼元となる製薬会社は、クライアント機１からＷＥＢサーバ２００にアクセスし、依頼情報としてのプロモーションの依頼をアップロードする。この依頼情報は、ユーザの要望によって、直接または、ＦＴＰサーバ３００を介してデータベース１１０のプロモーションテーブル群１６０にアップロードされる。他方、依頼先となる卸会社は、アップロードされたプロモーション依頼を出力し、プロモーションを実施する。この実施結果は、再度、プロモーション結果入力／編集画面７４０（図４２参照）によって、データベース１１０に入力される。この際、卸会社の上司は、上長確認入力エディタ８１０（図５２参照）を用いて、上長情報（確認または承認、或いはコメント等）をプロモーションの回答に対して付与することが可能である。この回答は、一定の条件で依頼元となる製薬会社に提示され、製薬会社は、ＦＴＰサーバ３００によって、ＣＳＶ形式で回答をダウンロードすることができるようになっている。

図示の実施形態において、情報共有システム１０は、サードパーティによって、構築運用されている。従って、製薬会社も卸会社もプロモーションやその回答をやり取りするためのデータベースを構築する必要がない。

次に、情報共有システム１０のデータベースについて、図６〜図８を参照しながら、説明する。

まず、図６を参照して、データベースサーバ１００のデータベース１１０には、製薬会社に関係する製薬会社テーブル群１２０と、卸会社に関係する卸会社テーブル群１３０と、ターゲットに関係するターゲットテーブル群１４０とが概念的に形成されている。

製薬会社テーブル群１２０には、製薬会社自身に関する属性（例えばＩＤコード、会社名、カナ名等）からなる製薬マスタテーブル１２１と、この製薬マスタテーブル１２１を親として直系の１：多のカーディナリティで関連づけられ、製薬会社の組織を特定する属性を有する複数の製薬組織テーブル１２２〜１２５と、上記製薬マスタテーブル１２１に対して１：多のカーディナリティを有し、当該製薬会社に所属するユーザに関する属性（例えば、所属部署コード、ユーザＩＤ、役職コード、ロックカウント、最終ログイン時刻、アクセス元ＩＰアドレス、機能フラグ、ｅ−ｍａｉｌアドレス等）からなる製薬ユーザテーブル１２６と、情報共有システム１０のＷＥＢサーバ２００が生成するＨＴＭＬページに掲載される情報を保存する属性からなる製薬システムアナウンステーブル１２７と、情報共有システム１０から特定の報知情報がある場合に、その情報と送信先（ｅ−ｍａｉｌアドレス）とを特定するための属性を有する製薬アラート送信先テーブル１２８とを有している。さらに図示の実施形態では、製薬ユーザテーブル１２６に対して１：多のカーディナリティで関連可能な外部キーを有する製薬ユーザ担当ターゲットテーブル１２９が設けられている。この製薬ユーザ担当ターゲットテーブル１２９は、製薬ユーザが担当するターゲットをそれぞれのＩＤで管理するためのものである。また、図示の実施形態において、製薬ユーザテーブル１２６は、製薬組織テーブル１２２〜１２５のそれぞれと１：多のカーディナリティで関連づける外部キーを有している。この結果、個々のユーザについて、勤務している本店、支店、営業所、課を特定できるようになっている。

次に、卸会社テーブル群１３０には、製薬会社テーブル群１２０と同様に、卸会社自身に関する属性（例えばＩＤコード、会社名、カナ名等）からなる卸マスタテーブル１３１と、この卸マスタテーブル１３１を親として直系の１：多のカーディナリティで関連づけられ、卸会社の組織を特定する属性を有する複数の卸組織テーブル１３２〜１３５と、上記卸マスタテーブル１３１に対して１：多のカーディナリティを有し、当該卸会社に所属するユーザに関する属性（例えば、所属部署コード、ユーザＩＤ、役職コード、ロックカウント、最終ログイン時刻、アクセス元ＩＰアドレス、機能フラグ、ｅ−ｍａｉｌアドレス、ＴＥＬ番号、ＦＡＸ番号等）からなる卸ユーザテーブル１３６と、情報共有システム１０のＷＥＢサーバ２００が生成するＨＴＭＬページに掲載される情報を保存する属性からなる卸システムアナウンステーブル１３７と、情報共有システム１０から特定の報知情報がある場合に、その情報と送信先（ｅ−ｍａｉｌアドレス）とを特定するための属性を有する卸アラート送信先テーブル１３８とを有している。また、図示の実施形態において、卸ユーザテーブル１３６は、卸組織テーブル１３２〜１３５のそれぞれと１：多のカーディナリティで関連づける外部キーを有している。この結果、卸ユーザについても、個々のユーザについて、勤務している本店、支店、営業所、課を特定できるようになっている。

さらに、ターゲットテーブル群１４０には、ターゲットとなる施設、医院、クリニック、或いは個人医師、教授等に関する属性（例えば、施設コード、施設略式名称、施設カナ名、都道府県コード、施設住所等）からなるターゲットマスタテーブル１４１が設けられている。

ここで、製薬マスタテーブル１２１と卸マスタテーブル１３１とは、連関エンティティである製薬／卸リンクテーブル１５１によって、多：多のカーディナリティで関連づけられている。従って、この連関エンティティ１５１により、複数の製薬会社と、複数の卸会社とを関連づけることが可能になる。さらに、製薬ユーザテーブル１２６と卸マスタテーブル１３１とは、連関エンティティである製薬ユーザ／卸リンクテーブル１５２によって、多：多のカーディナリティで関連づけられている。従って、この連関エンティティ１５２によって、製薬会社の複数のユーザと複数の卸会社とを関連づけることが可能になる。

さらに図示の実施形態においては、卸ユーザテーブル１３６とターゲットマスタテーブル１４１とが、連関エンティティであるターゲット／ユーザリンクテーブル１５３によって、多：多のカーディナリティで関連づけられている。従って、この連関エンティティ１５３によって、卸会社に勤務する複数のユーザと複数のターゲットとを関連づけることが可能になる。

さらに図示の実施形態では、製薬ユーザ担当ターゲットテーブル１２９とターゲットマスタテーブル１４１とが、連関エンティティである担当ターゲット／ターゲットリンクテーブル１５４によって多：多のカーディナリティで関連づけられている。従って、この連関エンティティ１５４により、複数のターゲットと、複数の製薬ユーザとを関連づけることが可能になっている。

この情報共有システム１０を運用するに際しては、まず、情報の共有に関する契約（主としてプロモーションの実施契約）を行った製薬会社と卸会社から必要な情報を得て、対応するテーブルにデータを登録する。

製薬会社も卸会社も新規の場合には、製薬マスタテーブル１２１、製薬組織テーブル１２２〜１２５、製薬ユーザテーブル１２６、製薬ユーザ担当ターゲットテーブル１２９、製薬／卸リンクテーブル１５１、製薬ユーザ／卸リンクテーブル１５２、担当ターゲット／ターゲットリンクテーブル１５４、卸マスタテーブル１３１、卸組織テーブル１３２〜１３５、卸ユーザテーブル１３６が、それぞれ更新される。

製薬会社が既メンバで、卸会社が新規の場合には、製薬／卸リンクテーブル１５１、製薬ユーザ／卸リンクテーブル１５２、卸マスタテーブル１３１、卸組織テーブル１３２〜１３５、卸ユーザテーブル１３６が更新される。

他方、製薬会社が新規で、卸会社が既メンバの場合には、製薬マスタテーブル１２１、製薬組織テーブル１２２〜１２５、製薬ユーザテーブル１２６、製薬／卸リンクテーブル１５１、製薬ユーザ／担当ターゲットテーブル１２９、担当ターゲット／ターゲットリンクテーブル１５４が更新される。

また、ターゲットの情報については、登録されたメンバ（主として製薬会社）からデータが提出され、このデータが名寄せされた状態でターゲットマスタテーブル１４１に登録され、指示のあった製薬会社、卸会社に対して、それぞれ連関エンティティ１５３、１５４で関連づけられるようになっている。

次に、図７を参照して、図示の実施形態におけるデータベース１１０には、製薬会社が卸会社に対してプロモーションを依頼するために使用される製薬会社側プロモーションテーブル群１６０が概念的に形成されている。このテーブル群１６０には、プロモーションの依頼を依頼情報として保存するプロモーションマスタテーブル１６１が含まれている。プロモーションマスタテーブル１６１は、後述するプロモーション作成／編集エディタを生成する際に、当該プロモーションの基本情報（プロモーション開始日、プロモーション終了日、プロモーション入力開始日、プロモーション入力終了日、タイトル、タイトル略称、表示順、入力方法、プロモーションのカテゴリ等）を保存するためのものである。このプロモーションマスタテーブル１６１には、１：多のカーディナリティでプロモーションカテゴリマスタテーブル１６２が関連づけられている。プロモーションカテゴリマスタテーブル１６２は、後述するプロモーション作成／編集エディタを生成する際に、当該プロモーションのカテゴリを保存するための情報を記録する属性を有している。

また、プロモーションマスタテーブル１６１には、１：多のカーディナリティで関連づけられるプロモーション意思表示マスタテーブル１６３が記憶されている。このプロモーション意思表示マスタテーブル１６３は、後述するプロモーション作成／編集エディタを生成する際に、作成者にプロモーションの意思表示項目を提供するための情報を記録する属性を有している。さらに、このプロモーション意思表示マスタテーブル１６３には、１：多のカーディナリティで関連づけられるプロモーション回答マスタテーブル１６４が記憶されている。このプロモーション回答マスタテーブル１６４は、後述するプロモーション作成／編集エディタを生成する際に、作成者に対し、各質問毎にプロモーションの回答項目を提供するための情報を記録する属性を有している。

図示の実施形態においては、卸会社が自社内でプロモーションを実施するための卸会社側プロモーションテーブル群１７０が設けられている。この卸会社側プロモーションテーブル群１７０は、製薬会社側プロモーションテーブル群１６０と同様なプロモーションマスタテーブル１６１、プロモーションカテゴリマスタテーブル１６２、プロモーション意思表示マスタテーブル１６３、プロモーション回答マスタテーブル１７４が記憶されている。

図示の実施形態において、各プロモーションマスタテーブル１６１、１７１と、ターゲットマスタテーブル１４１とが、連関エンティティである対象ターゲット管理テーブル１５５によって、多：多のカーディナリティで関連づけられている。この結果、作成された各プロモーションに対して、多数のターゲットを関連づけることが可能になるとともに、各ターゲットに対して、複数のプロモーションを関連づけることが可能になる。

また、各プロモーションマスタテーブル１６１、１７１と、卸マスタテーブル１３１並びに卸組織テーブル１３２〜１３５とは、連関エンティティである卸登録マスタテーブル１５６によって、多：多のカーディナリティで関連づけられている。従って、後述するように、各プロモーションに対して、複数の卸会社またはその所属組織或いは担当者を関連づけることができるとともに、各卸会社や所属組織毎に複数のプロモーションを関連づけて提示することが可能になる。さらに図示の実施形態において、卸登録マスタテーブル１５６は、プロモーションマスタテーブル１６１、１７１の非キー属性と同じ非キー属性を有しており、ＷＥＢサーバ２００にプログラムされたＳＱＬによって、卸会社が登録された時点で当該プロモーションの情報が卸登録マスタテーブル１５６にもコピーされるようになっている。

次に、図８を参照して、データベース１１０には、プロモーション結果管理テーブル群１８０が概念的に形成されている。このテーブル群１８０には、卸会社が登録されたプロモーションを保存する属性を有するプロモーションメインテーブル１８１と、このプロモーションメインテーブル１８１に対して１：多のカーディナリティで関連づけられ、当該プロモーションの意思表示項目を記憶する属性を有するプロモーション意思表示テーブル１８２と、このプロモーション意思表示テーブル１８２に対して１：多のカーディナリティで関連づけられ、意思表示項目に対する回答を記憶する属性を有するプロモーション回答テーブル１８３とを有している。これらは、プロモーションをリレーショナルデータベースで管理するに当たり、いわゆる正規化の要請によって３つのテーブルに分割されたエンティティである。

各テーブル１８１〜１８３は、上記ＳＱＬによって、卸登録マスタテーブル１５６の主キー属性の値と、対応するプロモーションテーブル群の全属性の内容がユニオン結合でコピーされる非正規形のテーブルである。本実施形態では、このような非キー属性のテーブルを生成することによって、検索速度を高めるようにしている。

プロモーションメインテーブルは候補キーとして、｛卸コード、プロモーションコード｝を含んでいる。従って、卸組織とプロモーションとが特定されることにより、非キー属性を一意に特定することが可能になっている。

次に、データベース１１０には、プロモーションに対する回答等を管理するための活動履歴管理テーブル群１９０が概念的に形成されている。

この活動履歴管理テーブル群１９０には、上記プロモーションメインテーブル１８１に対して１：多のカーディナリティで関連づけられるプロモーションユーザ回答メインテーブル１９１が設けられている。プロモーションユーザ回答メインテーブル１９１の属性としては、主キーとして、｛製薬コード、卸コード、プロモーションコード、施設コード｝を有しており、各プロモーションマスタテーブル１６１、１７１に登録されたプロモーションに対して、実質的に１：多のカーディナリティで関連づけ可能になっている。また、非キー属性としては、｛プロモーション実施日、プロモーション入力日、メールアドレス、コメント、送信フラグ、送信日付、ユーザ名、施設略式名称、承認フラグ、承認日付、マネージャーコメント、マネージャーコメント更新日付、コメント更新マネージャー名、承認マネージャー名｝を有しており、後述するプログラムによって、卸会社からの回答が保存されるようになっている。さらに外部キーとして、｛卸本店コード、卸支店コード、卸営業所コード、卸課コード、ユーザコード、コメント更新マネージャーコード、承認マネージャーコード｝を有しており、後述するように、回答者や回答者の所属組織、或いは上長情報の登録者等を保存できるようになっている。加えて、プロモーションユーザ回答メインテーブル１９１は、対象ターゲット管理に対し、１：多のカーディナリティで関連づけられている。この結果、プロモーションユーザ回答メインテーブル１９１は、プロモーション依頼とターゲットとを多：多のカーディナリティで関連づける連関エンティティとして機能する。このプロモーションユーザ回答メインテーブル１９１の属性のうち、属性｛送信フラグ、承認フラグ｝は、依頼元に対して回答を送信するための条件となる値を入力するためのフラグであり、これらの組み合わせによって、作成した回答の送付可否を契約に基づいて決定できるようになっている。さらに、送信フラグの値としては、送信が完了した場合：１、未送信の場合：０、一時保存中：２、という設定になっており、後述するプロモーション結果入力／編集画面７４０におけるデータ保存時に、クリックされたボタン７４４、７４５によって値が変更されるようになっている（図４４参照）。また、承認フラグの値としては、上長の承認がない場合：０、ある場合：１が設定されており、契約内容によっては、上長の承認がなければ、データを依頼元に提供するのを規制できるようになっている。

次に、活動履歴管理テーブル群１９０には、プロモーションユーザ回答メインテーブル１９１に対し、１：１のカーディナリティで関連するプロモーションユーザ回答詳細テーブル１９２が含まれている。このプロモーションユーザ回答詳細テーブル１９２は、主としてユーザの回答したコメントを保存するためのテーブルである。

次に、活動履歴管理テーブル群１９０には、製薬向けサマリテーブル１９３と、卸向けサマリテーブル１９４とを有している。各テーブル１９３、１９４は、それぞれ製薬会社、卸会社毎に担当したプロモーションの履歴回数を集計するものである。

各サマリテーブル１９３、１９４の属性は、
｛製薬コード、卸コード、プロモーションコード、施設コード、ユーザコード、プロモーションタイトル略称、卸本店コード、卸支店コード、卸営業所コード、卸課コード、卸本店名、卸支店名、卸営業所名、卸課名、ユーザ名、ユーザカナ名、施設略式名称、施設カナ名、プロモーション回数、プロモーション回数、プロモーション回数、プロモーション回数｝
であり、主キーとして、それぞれ
｛製薬コード、卸コード、プロモーションコード、施設コード｝
を有している。従って、製薬会社及び卸会社は、製薬会社がプロモーション依頼に登録した卸会社毎に、施設毎のプロモーション回数を集計することが可能になる。また、外部キーとして、｛卸本店コード、卸支店コード、卸営業所コード、卸課コード｝を有しているので、主キー属性である「卸会社」毎に各組織毎の集計を得ることが可能になる。

また、活動履歴管理テーブル群１９０には、コミュニケーションメッセージテーブル１９５が含まれている。このコミュニケーションメッセージテーブル１９５は、候補キーとして、｛製薬会社、プロモーション、ターゲット、メッセージＩｄ｝、｛卸会社、プロモーション、ターゲット、メッセージＩｄ｝を有しており、製薬会社と卸会社との間で、特定のプロモーション、特定のターゲットについて、相互に通信できるようになっている。

さらに図示の実施形態におけるデータベース１１０には、主として、製薬会社が卸会社に対してプロモーションの実施依頼を支援するためのメタデータテーブル群が概念的に形成されている。メタデータテーブル群には、意思表示項目をプログラムに提供するためのヘルプアイテムテーブル、説明事項を提供するためのヘルプメッセージテーブル、エラー画面を生成するためのエラーデータテーブルが含まれている。

次に、本実施形態のＷＥＢサーバ２００によって実現されるプログラムについて説明する。

図９〜図１１は、情報共有システム１０を利用するユーザが用いる画面遷移図である。

なお、各図とも、一部の画面を省略している。

各図を参照して、製薬会社、卸会社のユーザ（管理者を含む）は、それぞれクライアント機１〜３のブラウザＢに予め指定された情報共有システム１０のＵＲＬを入力することにより、ログイン画面６００を閲覧することができる。なお図示の実施形態では、各画面のタイトルバーに上流側の遷移画面を示すボタン６１０ａが表示されるようになっており（例えば図１６参照）、このボタン６１０ａをクリックすることによって、各図の遷移画面に移動することができるようになっている。

図１２は、各ユーザに共通するログイン画面６００を示すものであり、図１３は、このログイン画面によって操作されたデータのフローを示すフローチャートである。

これらの図を参照して、各ユーザは、ログイン画面６００の入力項目６０１に必要事項を入力し、ログインボタン６０２をクリックする。これにより、図１３のステップＳ１で示すように、ログイン要求がクライアント機１（〜３）からＷＥＢサーバ２００に送信される。ＷＥＢサーバ２００は、クライアント機１〜３からのログイン要求を受信し（ステップＳ２）、送信されたコードやパスワード等の情報に基づいて、メニュー表示サブルーチン処理を行ない（ステップＳ３）、データを送信する（ステップＳ４）。

他方、クライアント機１〜３では、ＷＥＢサーバ２００からの応答を待ち（ステップＳ５）、応答があった場合には、送信されたＨＴＭＬ文書を表示する（ステップＳ６）。

図１４は、図１３のメニュー表示サブルーチン処理の詳細である。

同図を参照して、ログイン要求があると、ＷＥＢサーバ２００は、ログインしたユーザに対応するテーブル（製薬会社の関係者の場合には製薬ユーザテーブル１２６、卸会社の関係者の場合には卸ユーザテーブル１３６に接続し、該当するユーザのデータを検索する（ステップＳ３１）。入力された会社コード、パスワード、ユーザＩＤが一致しない場合、ＷＥＢサーバ２００は、エラーデータテーブル、メッセージテーブルに接続し、エラーＨＴＭＬを作成し、例えば、図１５に示すエラー画面を送信する。本実施形態では、エラー回数をカウントし、ユーザテーブル１２６、１３６の属性「ロックカウント」に値を更新し、所定回数エラーが続いた場合には、アクセスを禁止するロックアウト処理を行なうようになっており、ロックアウト処理が実行された場合には、それ以降は、正規の会社コード、パスワード、ユーザＩＤが入力されても、ログインできないようになっている。

ステップＳ３２において、会社コード、パスワード、ユーザＩＤが一致し、且つロックアウトされていない場合、ＷＥＢサーバ２００は、ユーザテーブル１２６、１３６の役職コード属性から、ログインしたユーザが管理者であるか否かを判別する（ステップＳ３５）。役職コードが一般ユーザのものである場合には、ＷＥＢサーバ２００は、一般ユーザ用のＨＴＭＬを生成し、クライアント機１〜３に送信する（ステップＳ３６）。また、管理職である場合には管理者用ＨＴＭＬを生成し、クライアント機１〜３に送信する（ステップＳ３７）。各ユーザ向けのＨＴＭＬを作成するに際し、ＷＥＢサーバ２００は、ログインしたユーザの最終ログイン時刻を表示する。

次に製薬会社がログインした場合のフローについて、図１６以下を参照しながら説明する。なお、一般ユーザがアクセス可能な画面は、管理者ユーザがアクセス可能な画面に含まれていることから、以下の説明では、管理者のアクセス画面について説明し、一般ユーザのアクセス画面については説明を省略する。また、クライアント機１は、パーソナルコンピュータで具体化されたものとする。

図１６は、製薬会社のユーザがログインした場合のメニュー画面６１０を示す図である。

同図を参照して、メニュー画面６１０には、プロモーションの依頼を行なうためのプロモーションマスタテーブル作成ボタン６１１と、既作成のプロモーションの集計情報を表示するためのサマリ表示ボタン６１２とが設けられている。さらに、これらボタン６１１、６１２の下側には、図１４のステップＳ３７（Ｓ３６）の作成時に、読取られた最終ログイン時刻が「前回のログイン時刻」として表示される。

次に、メニュー画面６１０からプロモーションマスタテーブル作成ボタン６１１をクリックした場合の動作について、図１７、図１８を参照しながら説明する。図１７はプロモーションの一覧要求があった場合のフローチャートであり、図１８は図１７の処理によって生成された画面を示す図である。

図１７を参照して、ユーザがプロモーションマスタテーブル作成ボタン６１１をクリックすると、クライアント機１から、プロモーション一覧要求がＷＥＢサーバ２００に送信される（ステップＳ１７１）。この一覧要求を受信すると（ステップＳ１７２）、ＷＥＢサーバ２００は、製薬会社側プロモーションテーブル群１６０の各テーブルに接続し（ステップＳ１７３）、一覧データを作成する（ステップＳ１７４）。この一覧データを作成した後、ＷＥＢサーバ２００は、一覧データを送信する（ステップＳ１７５）。

他方、クライアント機１では、プロモーションマスタテーブル作成ボタン６１１をクリックした後、受信を待機し（ステップＳ１７６）、タイムアウトの場合、または受信不良には、エラー画面を表示し（ステップＳ１７７、Ｓ１７８）、受信できた場合には、データを展開して一覧画面６２０を表示する（ステップＳ１７９）。

図１８を参照して、生成されたプロモーション一覧画面６２０は、ログインしたユーザの情報に基づいて、プロモーションを検索するための検索フレーム６２１と、この検索フレーム６２１の下段に設けられて、プロモーションをリストアップする一覧フレーム６２２とが設けられている。

検索フレーム６２１には、検索用の入力ボックス６２１ａ〜６２１ｆと、検索ボタン６２１ｇ、全入力ボックス６２１ａ〜６２１ｆをＮｕｌｌにするリセットボタン６２１ｈが設けられており、入力ボックス６２１ａ〜６２１ｆに選択的に入力された文字列に基づいて、検索ボタン６２１ｇをクリックすることにより、一覧フレーム６２２に表示されているプロモーションの絞り込み検索を行なうことができるようになっている。

一覧フレーム６２２には、プロモーションマスタテーブル１６１の属性に基づき、製薬会社名、プロモーションのタイトル、コード、プロモーションの開始日、同終了日、プロモーションの実施状況、カテゴリ、作成者、作成者の所属先、卸登録が項目として設けられ、プロモーションマスタテーブル１６１に記録されているプロモーションのタプルが、ログインしたユーザのアカウントに基づいて絞り込まれた状態でリストアップされている。各表ヘッダ６２２ａ〜６２２ｋは、周知のＧＵＩ技術によって、タプルを並び替えるボタンを兼ねている。

各タプルは、プロモーションマスタテーブル１６１の属性「状況」の値に基づいて、プロモーションがまだ実施されていない未着手タプル１と、実施中の着手タプルと、終了したタプルとに識別されており、未着手タプル１のみを編集することができるようになっている。未着手タプルについては、「［プレビュー］」という文字列が、プロモーションマスタテーブル１６１の属性「タイトル」に登録された値に付加されて表示されている。この文字列は、ハイパーリンクが設定されており、この文字列をクリックすることによって、当該タプルの編集作業を行うことができるようになっている。また、後述するように、編集可能な未着手タプルについては、当該プロモーションに対して卸会社を登録することも可能である。編集のできない残余のタプルについては、「［編集不可］」という文字列が、プロモーションマスタテーブル１６１の属性「タイトル」に登録された値に付加されて表示されている。

次に、一覧フレーム６２２の上方には、新たなタプル（プロモーション依頼）を追加するための新規作成ボタン６２４ａと、削除ボタン６２４ｂとが設けられている。そして、新規作成ボタン６２４ａをクリックすることにより、次に説明するプロモーションの作成編集エディタが生成され、画面が遷移する。また、削除可能な未着手タプルについては、左端にチェックボックスが表示されており、このチェックボックスにマークを付けて削除ボタンをクリックすることにより、当該未着手タプルが削除されるようになっている。

次に、図１９〜図２３を参照して、プロモーションの作成、編集、登録処理について説明する。図１９は、プロモーションを作成してから登録するまでの処理全体を示すフローチャート、図２０は、図１９のプロモーション作成／編集データ処理のサブルーチンを示すフローチャートである。

図１８及び図１９を参照して、図１８の新規作成ボタン６２４ａまたは、未着手タプルのタイトル列に表示された文字列「［プレビュー］」をクリックすることにより、クライアント機１は、プロモーションの作成／編集要求をＷＥＢサーバ２００に送信する（ステップＳ１９１）。クライアント機１からの要求を受信すると（ステップＳ１９２）、ＷＥＢサーバ２００は、メタデータテーブル群に接続し、ＨＴＭＬで具体化されるプロモーションの作成編集エディタの生成に必要なデータを取得する（ステップＳ１９３）。さらに、プロモーション作成／編集データ処理サブルーチンに移行して、プロモーションの作成編集エディタを生成する（ステップＳ１９４）。次いで、生成されたデータをクライアント機１に送信する（ステップＳ１９５）。

他方、クライアント機１では、プロモーションの作成／編集要求（ステップＳ１９１）をＷＥＢサーバ２００に送信した後、受信を待機し（ステップＳ１９６）、タイムアウトの場合、または受信不良には、エラー画面を表示し（ステップＳ１９７、Ｓ１９８）、受信できた場合には、データを展開して一覧データ作成処理サブルーチンＳ１９９に移行する。

次に、図２０を参照して、ステップＳ１９４におけるプロモーション作成／編集データ処理サブルーチンにおいては、クライアント機１からの要求が新規作成であるか、編集要求であるかが、それぞれの出力に基づいて判別され（ステップＳ１９４１）、新規作成の場合には、新規のＩＤコードが付与された空配列ＨＴＭＬが生成される（ステップＳ１９４２）。他方、編集要求である場合には、再度、プロモーションマスタテーブル１６１、プロモーションカテゴリマスタテーブル１６２、プロモーション意思表示マスタテーブル１６３、プロモーション回答マスタテーブル１６４に接続し（ステップＳ１９４３）、対応するタプルを取り出して、既存データ作成用配列ＨＴＭＬを作成する（ステップＳ１９４４）。

図２１は、新規のプロモーション依頼を作成するための画面（作成編集エディタ）６３０を示す図である。

同図を参照して、生成されたＨＴＭＬにより具体化される作成編集エディタ６３０は、プロモーションテーブル群１６０のマスタテーブル１６１、カテゴリマスタテーブル１６２の各属性をいわゆる単票形式で並べたプロパティフレーム６３１と、このプロパティフレーム６３１の下に形成されるプロモーションフレーム６３２とを有している。

プロパティフレーム６３１の項目としては、プロジェクトの「正式名称」６３１ａ、「略式名称」６３１ｂ、プロジェクトの目的を表す「サブジェクト１」６３１ｃ、テーマを表す「サブジェクト２」６３１ｄ、実施予定の「日付の範囲」６３１ｅ、実施されたプロモーションの「実績日付」６３１ｆ、プロモーションの「カテゴリ」６３１ｇ、「入力形式」６３１ｈ等が設けられている。生成されるプロモーションは、上述したプロモーションテーブル群１６０の論理構造により、このプロパティフレーム６３１を共通項目として、複数の意思表示項目（ここでは主として質問項目）を有し、且つ各意思表示項目に対して複数の回答項目を設定することができるようになっている。このプロパティフレーム６３１には、作成したプロモーションのプレビュー画面（卸会社が閲覧する画面）を表示するプレビューボタン６３１ｉが設けられている。なお、意思表示項目としては、上記質問項目の他、製薬会社が卸会社に対する注意事項や指示を含めることが可能になっている。

プロモーションフレーム６３２は、いわゆる連票形式で、多数の意思表示項目を設定可能な構成になっている。プロモーションフレーム６３２に表示される意思表示項目毎の欄６３２ａには、プロモーション意思表示マスタテーブル１６３の属性とプロモーション回答マスタテーブル１６４の属性に記録されるデータ入力ボックス６３２ｂが形成される。各データ入力ボックス６３２ｂには、回答の種類を入力するトグルボックス６３２ｃが設けられており、メタデータテーブル群から読み出された回答種類のデータがトグルリストとして表示されるようになっている。

プロモーションフレーム６３２とプロパティフレーム６３１との間には、設問を追加するための設問追加ボタン６３０ａと、プロモーションを保存する保存ボタン６３０ｂと、保存して続けるための保存続行ボタン６３０ｃとが設けられており、この追加ボタン６３０ａをクリックするたびに、プロモーションフレーム６３２のソースとなっているプロモーションマスタテーブル１６１のプロモーションＩｄに対応する外部キーを付加しながら、プロモーション意思表示マスタテーブル１６３に新しいタプルが追加されるようになっている。

また、各欄６３２ａには、回答追加ボタン６３２ｄが生成される。この回答追加ボタン６３２ｄをクリックすることにより、当該欄６３２ａのソースとなっているプロモーション意思表示マスタテーブル１６３の質問Ｉｄに対応する外部キーを付加しながら、プロモーション回答マスタテーブル１６４に新しいタプルが追加され、一の意思表示項目に対して複数の回答項目を追加できるようになっている。

図２２は、プロモーションが入力された画面（作成編集エディタ）６３０を示す図である。

同図を参照して、プロモーションを作成し続けた場合や、上述した図２０のフローにおいて、ステップＳ１９４４の既存データのＨＴＭＬが生成された場合には、各図に例示するように、意思表示項目の欄６３２ａ毎に、種々のＧＵＩオブジェクトＯＪ１〜ＯＪ５を用いて、項目が設定されることになる。例えば、ＯＪ１は、項目の順番を繰り上げるコマンドを要求するオブジェクト、ＯＪ２は、項目の順番を繰り下げるコマンドを要求するオブジェクト、ＯＪ３は、項目を削除するコマンドを要求するオブジェクト、ＯＪ４は、後続する設問を設定するためのコンボボックス、ＯＪ５は、フリーテキストを選択するためのチェックボックスである。これらには、イベントプロシージャが実装されており、ＷＥＢサーバ２００に実装されたサーバスクリブティングプログラム２０２とコンポーネントオブジェクト２０３とによって、これらのオブジェクトＯＪ１〜ＯＪ５を含めた画面を生成し、欄６３２ａ内での並び替えやデータの追加、削除ができるようになっている。

図２３及び図２４は、クライアント機１において、プロモーションを作成する時のプロモーション作成処理サブルーチンを示すフローチャートである。

図１９から図２４を参照して、作成編集エディタ６３０がクライアント機１に表示されると、ハートビート処理が実行される（ステップＳ１９９０）。

図２５は、ハートビート処理の詳細を示すフローチャートである。

同図を参照して、ハートビート処理は、Ｊａｖａ（登録商標）スクリプトによって具体化されるものであり、操作フラグを宣言して、セッションの管理を行うものである。ハートビート処理が開始されると、クライアント機１は、定期的にハートビート要求を出力する（ステップＳ２５１）。次いで、クライアント機１は、上記操作フラグが更新されているか否かを判断し（ステップＳ２５２）、更新されていれば、ＷＥＢサーバ２００にダミーページの送信を要求するとともに（ステップＳ２５３）、ステップＳ２５１において、操作フラグが更新されていない場合には、セッションを遮断して処理を終了するものである（ステップＳ２５４）。これにより、ユーザは、プロモーションの作成に相当の時間をかけていても、継続的にセッションを維持しておくことが可能になる。

図２３に戻って、上記ハートビート処理と同時に、クライアント機１には、図２１（及びまたは図２２）の画面が表示される（ステップＳ１９９１）。さらに、上記ハートビート処理のために、何らかの操作があった場合には、Ｊａｖａ（登録商標）アプレットにおいて宣言されている操作フラグを更新する（ステップＳ１９９２）。

上述したように、ユーザは、図２１に示す設問追加ボタン６３０ａによって、設問の追加要求を命令し（ステップＳ１９９３）、オブジェクトＯＪ１〜ＯＪ５によって、設問の削除要求を命令し（ステップＳ１９９４）、回答追加ボタン６３２ｄによって、回答の追加要求を命令し（ステップＳ１９９５）、オブジェクトＯＪ１〜ＯＪ５によって、回答の削除要求を命令することができる（ステップＳ１９９６）。

これらの要求があると、クライアント機１は、タイムアウトしているか否か（セッションが遮断されているか否か）判別し（ステップＳ１９９８）、セッションが遮断されている場合には、タイムアウト画面を表示する（ステップＳ１９９９）とともに、セッションが接続されている場合には、ソート処理要求をＷＥＢサーバ２００に出力し（ステップＳ１９９Ａ）、作成画面表示のステップＳ１９９１に制御を戻す。

図２６は、プレビュー画面６４０を示す図である。

図２１、図２２及び図２６を参照して、プロパティフレーム６３１にあるプレビューボタン６３１ｉをクリックすると、確認メッセージボックス（図示せず）が表示された後、図２６に示すプレビュー画面６４０が表示される。

図２６では、後述するプロモーション回答作業時に、依頼先となる卸会社の担当者が実際に入力する画面と同じものをプレビューさせて、作成者にプロモーションの依頼のチェックをさせるための機能である。このプレビュー画面６４０は、一種のダミー画面であり、データの入力自体は許容されるが、入力されたデータがデータベースのテーブルに登録されることはない。

次に図１９を参照して、ユーザが作成編集エディタ（図２１、図２２）６３０の作成を行っている間、ＷＥＢサーバ２００は、セッションが接続されている間、クライアント機１からの保存要求を待機する（ステップＳ２００）。この過程で、ユーザが、図２４のステップＳ１９９Ｈに示すプロモーション依頼の保存処理を行った場合、この保存要求が送信されてＷＥＢサーバ２００に受信される（図１９のステップＳ２０１）。この保存要求処理が保存要求では、ＷＥＢサーバ２００は、図２７に示す処理を行う。

図２７は、クライアント機から要求されたプロモーション依頼の保存処理を示すフローチャートである。

同図を参照して、保存処理サブルーチンＳ２０１では、まず、ＷＥＢサーバ２００は、製薬会社側プロモーションテーブル群１６０（図７参照）に接続し（ステップＳ２０１１）、送信されたデータの有無を確認する（ステップＳ２０１２）。仮にデータが既存のプロモーション依頼の更新であった場合、ＷＥＢサーバ２００は、プロモーションマスタテーブル１６１内の該当データを削除する（ステップＳ２０１３）。次いで、削除の良否が判別され（ステップＳ２０１５）、削除が仮に不成功だった場合、ＷＥＢサーバ２００は、データベースマネジメントシステム１１５からその情報を取得し、エラーメッセージ用のＨＴＭＬを作成する（ステップＳ２０１６）。

他方、ステップＳ２０１２において、送信されたデータが新規である場合、またはステップＳ２０１４において削除が成功した場合、ＷＥＢサーバ２００は、再度、プロモーションテーブル群２００１に接続して、データの更新を行う（ステップＳ２０１６）。

この処理が成功した場合には、コミット終了のＨＴＭＬを作成する（ステップＳ２０１７、Ｓ２０１８）。他方、ステップＳ２０１６において、データの更新に失敗した場合には、ステップＳ２０１４の場合と同様に、エラーメッセージ用のＨＴＭＬを作成する（ステップＳ２０１５）。そして、何れの場合にも、作成されたＨＴＭＬがクライアント機１に送信され、処理が終了する（ステップＳ２０１９）。

図２４を参照して、クライアント機１は、図２７の処理により送信されたデータの受信を待ち受ける（ステップＳ１９９Ｊ）。送信されたデータがエラーメッセージ用のＨＴＭＬであった場合、この画面が表示されて処理が終了する（ステップＳ１９９Ｋ）。他方、コミット完了のＨＴＭＬであった場合、処理を終了すべきか否かが判別され（ステップＳ１９９Ｌ）、終了しない場合には、図１９のステップＳ１９１に戻って、新たなプロモーション依頼の作成を行う（ステップＳ１９９Ｌ）。

図２４のステップＳ１９９Ｌの判別は、保存要求が作成編集エディタ６３０の保存ボタン６３０ｂによるものか、保存続行ボタン６３０ｃによるものかによって識別される。

次に、作成されたプロモーション依頼に対して、依頼先となる卸会社を関連づける処理について説明する。

図２８は、卸登録処理をするためのアイコンを示す図であり、図２９は、卸会社を登録する場合の処理全体を示すフローチャート、図３０は図２９における卸登録データ作成処理のサブルーチンを示すフローチャート、図３１は、図３０のサブルーチンによって生成された画面を示す図である。

まず、図１８を参照して、各タプルの卸登録項目には、卸登録アイコン６２２Ｌが表示されている。この卸登録アイコン６２２Ｌは、プロモーション依頼の態様によって、図２８に示すように、卸会社が未登録の態様（図２８（Ａ）参照）、登録済の態様（図２８（Ｂ）参照）、登録できない態様（図２８（Ｃ）参照）の３種類の状態に遷移するようにプログラムされており、ユーザは、未登録のアイコン（図２８（Ａ））をクリックすることによって、ＷＥＢサーバ２００に対し、卸登録要求を送信することが可能になっている。

図２９を参照して、卸登録要求（ステップＳ２８１）がクライアント機１からあると、ＷＥＢサーバ２００は、この要求を受信し（ステップＳ２８２）、卸登録データ作成処理サブルーチンを実行する（ステップＳ２８３）。このサブルーチンを実行した後、生成されたデータをクライアント機１に送信する（ステップＳ２８４）。

他方、クライアント機１では、卸登録要求（ステップＳ２８１）をＷＥＢサーバ２００に送信した後、受信を待機し（ステップＳ２８５）、タイムアウトの場合、または受信不良には、エラー画面を表示し（ステップＳ２８６、Ｓ２８７）、受信できた場合には、データを展開して卸登録処理サブルーチンＳ２８８に移行する。

図３１を参照して、ＷＥＢサーバ２００での卸登録データ作成処理サブルーチンが実行されることによりクライアント機１に表示される卸登録画面６５０は、卸会社の組織をツリー構造で表示する卸組織フレーム６５１と、登録されるべき卸会社をリスト形式で一覧する卸一覧フレーム６５２とを有している。

卸組織フレーム６５１と卸一覧フレーム６５２との間には、移動ボタン６５０ａ、６５０ｂが上下に配列されている。上側の移動ボタン６５０ａは、卸組織フレーム６５２で選択された組織を卸一覧フレーム６５２に移動する要求を命令するためのものであり、下側の移動ボタン６５０ａは、卸一覧フレーム６５２の登録を解除する要求を命令するためのものである。

図３０を参照して、卸登録画面６５０の全体を構成するＨＴＭＬを生成するために、まず、ＷＥＢサーバ２００は、製薬／卸リンクテーブル１５１、卸マスタテーブル１３１、卸本店テーブル１３２、卸支店テーブル１３３、卸営業所テーブル１３４、卸課テーブル１３５、並びに卸登録マスタテーブル１５６に接続する（ステップＳ２９３１〜Ｓ２９３７）。次いで、静的ＳＱＬにより、製薬会社と、卸会社の各組織（卸マスタテーブル１３１、卸本店テーブル１３２、卸支店テーブル１３３、卸営業所テーブル１３４、卸課テーブル１３５によって特定される組織）の組み合わせから、卸登録マスタテーブル１５６に登録されていないデータを抽出する（ステップＳ２９３８）。そして、取り出されたデータに基づいて、ツリー構造のＨＴＭＬを生成する（ステップＳ２９３９）。

これらのステップＳ２９３１〜Ｓ２９３９により、製薬／卸リンクテーブル１５１から依頼元の製薬会社が取引先としている卸会社が絞り込まれ、図３１に示すように、絞り込まれた卸会社の組織が、ツリー構造で卸組織フレーム６５１に表示されることになる。

次に、卸登録画面６５０の操作におけるデータ処理について、図３２〜図３４を参照しながら説明する。

図３２及び図３３は、クライアント機１における卸登録処理サブルーチン（図２９のステップＳ２９８）を示すフローチャートであり、図３４は、卸登録処理サブルーチンにおいて、卸一覧フレーム６５２を更新する場合の処理を示すフローチャートである。

まず、図３２並びに図３１を参照して、クライアント機１においては、卸登録画面６５０の卸組織フレーム６５１を参照しながら、ユーザがプロモーションを実施させたい卸会社の組織を選択する。この作業では、図３０のフローによって生成された卸登録画面６５０が表示され（ステップＳ３２１）、ユーザが卸組織フレーム６５１に表示されているツリーを展開することによって、所望の組織が選択される（ステップＳ３２２〜Ｓ３２５）。ユーザがツリーを操作することによって、卸組織フレーム６５１のソート要求がクライアント機１に命令される。この命令がなされると、ソート要求がＷＥＢサーバ２００に送信される（ステップＳ３２６）。

ソート要求がなされると、処理は、図２９で説明した卸登録要求のフロー（ステップＳ２９１）に戻り、再度、卸組織フレーム６５１が再構築されて表示されることになる。

次に、図３１、図３３を参照して、卸会社（組織）を登録する場合、ユーザは、卸組織フレーム６５１で登録したい会社をハイライトさせ、移動ボタン６２０ａをクリックする。

この操作により、クライアント機１においては、登録ステップが開始される（ステップＳ３３０）。このフローでは、まず、卸組織フレーム６５１で卸会社（組織）が選択されているか否かが判別され（ステップＳ３３１）、仮に何れの組織も選択されていない（ハイライトされていない）場合には、メタデータテーブル群（このテーブル群のデータは、卸登録画面６５０が送信されてきた時にクライアント機１に格納されている）からワーニングメッセージを選択して、ワーニングメッセージを表示する（ステップＳ３３２）。

他方、卸組織が選択されている場合には、ＷＥＢサーバ２００に登録保存要求を送信する（ステップＳ３３３）。クライアント機１では、その後、ＷＥＢサーバ２００の応答を待ち、その結果を表示する（ステップＳ３３４、Ｓ３３５）。

ここで、登録保存要求を受けたＷＥＢサーバ２００は、図２７で説明した保存処理と同様のプロセスで卸登録マスタテーブル１５６に接続し、選択された卸組織のＩＤとプロモーション依頼のＩＤとを関連づけて登録し、応答データをクライアント機１に送信する。ここで、図示の実施形態では、卸登録マスタテーブル１５６へのデータ登録コミットが成功した時点で、図３４の処理を実行して、卸一覧フレーム６５２の画面を更新する。

図３４を参照して、卸登録コミットがなされると、ＷＥＢサーバ２００は、動的ＳＱＬによるデータ作成作業を開始する。この動的ＳＱＬでは、改めて卸登録マスタテーブル１５６に接続する（ステップＳ３４１）。次いで、卸組織フレーム６５１に選択された卸組織に基づいて、プロモーションマスタテーブル１６１を絞り込み、卸組織が登録されたタプルを取得する（ステップＳ３４２）。さらに、動的ＳＱＬを実行して卸一覧フレーム６５２を表示するＨＴＭＬを生成する（ステップＳ３４３）。クライアント機１には、このＨＴＭＬが完了応答とともにＷＥＢサーバ２００から送信される。

図３５は、卸組織が登録されている卸登録画面６５０を示す図である。

同図を参照して、図示の例では、一つの卸組織を選択した例である。図３５に示すように、卸組織が選択されると、卸一覧フレーム６５２には、卸登録マスタテーブル１５６の項目に基づいて、卸名、第１階層〜第４階層までの項目が設けられ、卸会社名、卸本店名、卸支店名、卸営業所名、卸課名が表示可能になっている。また、登録した卸組織を削除するために、卸一覧フレーム６５２にタプルが表示される場合には、その左端に削除を指定するためのチェックボックス６５２ｂが形成されるようになっている。

ここで、卸登録マスタテーブル１５６は、連関エンティティであるため、これら卸組織の情報は、主キー属性に持たせている。他方、ユーザが選択する卸組織は、下位の組織がブランクである場合もある。そのため、図示の実施形態では、図３３のステップＳ３３３において、卸登録マスタテーブル１５６に情報を追加する場合、ブランクの組織部分については、ワイルドカードを当てて全ての組織を指定させている。図３５に示す例では、支店までが指定されており、それ以降は、指定されていないので、テーブル上では、ワイルドカードで全ての支店が指定され、表示では、「全て」という文字列を用いている。

さらに、上記ステップＳ３３３における登録保存要求がＷＥＢサーバ２００で実行されると、卸登録マスタテーブル１５６と同時に、プロモーションメインテーブル１８１、プロモーション意思表示テーブル１８２、プロモーション回答テーブル１８３に、対応するプロモーションテーブル群１６０のデータがコピーされる。これにより、正規化されたプロモーション依頼の情報と卸登録情報とを結合させることができるので、演算処理が早くなる。

登録した卸組織を解除する場合、ユーザは、削除対象となるタプルのチェックボックス６５２ｂにチェックマークを入れ、移動ボタン６２０ｂをクリックして、削除要求を命令する。

図３３に戻って、移動ボタン６２０ｂがクリックされると（ステップＳ３３６）、クライアント機１は、チェックボックス６５２ｂにチェックされたタプルをソートする（ステップＳ３３７）。仮にチェックされたタプルが全く存在しない場合には、ステップＳ３３２に移行して、ワーニングメッセージを表示する。

他方、チェックされたタプルが検出された場合には、当該卸組織を登録解除する解除保存要求をＷＥＢサーバ２００に出力する（ステップＳ３３８）。その後、クライアント機１は、ＷＥＢサーバ２００から完了応答を待ち、エラーの場合には、ステップＳ３３５に移動し、成功した場合には、卸登録画面６５０表示（ステップＳ３２１）に制御を移す。

解除保存要求を受けると、ＷＥＢサーバ２００は、登録保存要求の場合と同様に、卸登録マスタテーブル１５６、プロモーションメインテーブル１８１、プロモーション意思表示テーブル１８２、プロモーション回答テーブル１８３に接続し、削除対象となっているタプルを削除する。

なお、本実施形態においては、卸一覧フレーム６５２に表示されている卸名の表ヘッダ６５２ａに表示されている文字列をクリックすると、プロパティ編集画面６６０（図９参照）が表示され、登録された卸組織毎に実施期間や入力方式等のプロパティを設定できるようになっている。このプロパティ情報は、プロモーションマスタテーブル１６１の属性として、所要の項目を登録しておくことにより、それらの属性を用いて設定できるようになっている。なお上述したように、各プロモーション依頼は、プロモーションマスタテーブル１６１に登録されているとともに、卸登録マスタテーブル１５６によって、卸組織のテーブルに対して多：多のカーディナリティで関連づけられているとともに、このプロパティ設定は、上記卸登録テーブル１５６を修正するものであることから、一のプロモーションに対するプロパティを変更すると、全ての卸組織のプロモーションも変更される。

次に、作成されたプロモーション依頼を依頼先の卸会社が出力する作業について説明する。

図３６は、卸会社の一般ユーザのメニュー画面７００を示している。

図９及び図３６を参照して、メニュー画面７００には、依頼されたプロモーションに対してターゲットを関連づけるためのターゲット選択ボタン７０１と、既作成のプロモーションの集計情報を表示するためのサマリ表示ボタン７０２と、ユーザ（卸会社のユーザ）が担当するターゲットの登録／解除を行なうための担当ターゲット登録ボタン７０３とが設けられている。さらに、これらのボタン７０１〜７０３の下側には、卸システムアナウンステーブル１３７に登録されたヘッドオフィスメッセージを表示する欄７０４と、コミュニケーションメッセージテーブル１９５に登録された情報に基づくメッセージを表示する欄７０５と、ＷＥＢサーバ２００が送信する情報欄７０６とが設けられている。

図３７はターゲットの一覧要求があった場合のフローチャートである。

図３７を参照して、メニュー画面７００からターゲット選択ボタン７０１をクリックすると、クライアント機１から、ターゲット一覧要求がＷＥＢサーバ２００に送信される（ステップＳ３６１）。この一覧要求を受信すると（ステップＳ３６２）、ＷＥＢサーバ２００は、ターゲットユーザリンクテーブルテーブル１５３、ターゲットマスタテーブル１４１、対象ターゲット管理テーブル１５５、プロモーションメインテーブル１８１、及びプロモーションユーザ回答メインテーブル１９１に接続し（ステップＳ３６３）、一覧データを作成する（ステップＳ３６４）。この一覧データを作成した後、ＷＥＢサーバ２００は、一覧データを送信する（ステップＳ３６５）。

他方、クライアント機１では、ユーザがターゲット選択ボタン７０１をクリックした後、受信を待機し（ステップＳ３６６）、タイムアウトの場合、または受信不良には、エラー画面を表示し（ステップＳ３６７、Ｓ３６８）、受信できた場合には、データを展開して一覧画面６２０を表示する（ステップＳ３６９）。

図３８を参照して、生成されたターゲット選択画面７１０は、ログインしたユーザの情報に基づいて、プロモーションを検索するための検索フレーム７１１と、この検索フレーム７１１の下段に設けられて、プロモーションをリストアップする一覧フレーム７１２とが設けられている。

検索フレーム７１１には、検索用の入力ボックス７１１ａ〜７１１ｈと、検索ボタン７１１ｉ、全入力ボックス７１１ａ〜７１１ｈをＮｕｌｌにするリセットボタン７１１ｊが設けられており、入力ボックス７１１ａ〜７１１ｈに選択的に入力された文字列に基づいて、検索ボタンをクリックすることにより、一覧フレーム７１２に表示されているプロモーションの絞り込み検索を行なうことができるようになっている。

一覧フレーム７１２には、ターゲットユーザリンクテーブル１５３、ターゲットマスタテーブル１４１、対象ターゲット管理テーブル１５５、プロモーションメイン１８１、プロモーションユーザ回答メインテーブル１９１の属性に基づき、施設名、製薬会社名、選択ボックス、プロモーションのタイトル、予定期限、実施期限、プロモーションの実施日時、実施状況、確認者名、上長確認日等が項目として設けられ、プロモーションユーザ回答メインテーブル１９１に記録されているターゲットのタプルが、ログインしたユーザのアカウントに基づいて、動的ＳＱＬにより絞り込まれた状態でリストアップされている。各表ヘッダ７１２ａ〜７１２ｋは、周知のＧＵＩ技術によって、タプルを並び替えるボタンを兼ねており、これらのボタンをクリックすることによって、動的ＳＱＬにより、並び替え作業をＷＥＢサーバ２００に実行させて、ソートされた画面を受信できるようになっている。

上述したように、プロモーションユーザ回答メインテーブル１９１は、プロモーション依頼とターゲットとを多：多のカーディナリティで関連づける連関エンティティでもあるので、自社に関連する全てのプロモーションについて、複数のターゲットを指定することが可能になる。

また、ターゲット／ユーザリンクテーブル１５３を用いて、当該卸会社に関連するターゲットを取り出すことができるので、通常、卸会社のユーザは、自動的に自分に関連するターゲットのリストを得ることが可能になる。

次に、一覧フレーム７１２の上方には、タプル（プロモーション依頼）を印刷するための印刷ボタン７２４ａと、タプルを削除するための削除ボタン７２４ｂとが設けられている。そして、印刷ボタン７２４ａをクリックすることにより、プロモーションの内容を表示するＨＴＭＬが生成され、登録確認画面７３０に遷移する。

図３９は、遷移した登録確認画面７３０、図４０は、印刷されたサンプルを示す図である。ユーザは、登録確認画面７３０を表示するブラウザＢの機能を用いてターゲット毎にプロモーションを印刷することが可能になる（図４０参照）。

また、削除可能なタプルについては、左端にチェックボックスが表示されており、このチェックボックスにマークを付けて削除ボタンをクリックすることにより、選択された回答結果を削除することができるようになっている。

図５を参照して、卸会社は、予め製薬会社との契約内容に基づき、印刷されたプロモーションを各ターゲット毎に実施する。

そして、実施されたプロモーションは、図３８に示すターゲット選択画面７１０から、該当するタプルのプロモーションタイトルをクリックすることによって開始される。

図４１は、プロモーション結果作成処理の全体フローを示すフローチャートである。

図４１を参照して、ユーザがタプルのプロモーションタイトルをクリックした場合、クライアント機１は、ＷＥＢサーバ２００に対して、プロモーション結果作成要求を送信する（ステップＳ４１１）。

ＷＥＢサーバ２００は、クライアント機１からの要求を受信すると（ステップＳ４１２）、メタデータテーブル群に接続し、ＨＴＭＬで具体化されるプロモーション結果の作成編集エディタの生成に必要なデータを取得する（ステップＳ４１３）。さらに、プロモーション作成／編集データ処理サブルーチンに移行して、プロモーションの作成編集エディタを生成する（ステップＳ４１４）。次いで、生成されたデータをクライアント機１に送信する（ステップＳ４１５）。

他方、クライアント機１では、プロモーションの作成／編集要求（ステップＳ４１１）をＷＥＢサーバ２００に送信した後、受信を待機し（ステップＳ４１６）、タイムアウトの場合、または受信不良には、エラー画面を表示し（ステップＳ４１７、Ｓ４１８）、受信できた場合には、データを展開してプロモーション結果作成処理サブルーチンＳ４１９に移行する。

図４２〜図４４は、図４１のフローにより生成されたＨＴＭＬに基づく画面を示す図であり、図４５は、プロモーション結果入力／編集画面７４０におけるクライアント機１の制御フローを示すフローチャートである。

まず、図４２〜図４３を参照して、プロモーション結果入力／編集画面７４０には、製薬会社が作成したプロモーションに対するアンケートが連票形式で表示されている。

図４２を参照して、プロモーション結果入力／編集画面７４０には、カレンダボタン７４０ａが設けられている。このカレンダボタン７４０ａをクリックすると、カレンダ画面ＣＬ（図４２に仮想線でのみ図示）がポップアップし、プロモーションの実施日を入力することができる。

アンケートの最後には、図４３に示すように、リセットボタン７４１と、次ページに遷移するための保存ボタン７４４とが形成されており、リセットボタン７４１を押すと、それまで入力した事項が全てリセット（Ｎｕｌｌに更新）される一方、保存ボタン７４４をクリックすることによって、次のページに遷移するようになっている。

プロモーション結果入力／編集画面７４０の最終ページの最下部には、保存ボタン７４５、一時保存ボタン７４４、保存ボタン７４５が形成されている。保存ボタン７４５をクリックすると、プロモーション結果入力／編集画面７４０の最初のページ（図４２参照）に遷移する。また、一時保存ボタン７４５をクリックすると、入力されたデータがプロモーションユーザ回答メイン１９１に登録される。さらに、移動ボタン７４４をクリックすると、入力されたデータがプロモーションユーザ回答メイン１９１に登録されるとともに、画面がターゲット選択画面７２０に遷移する。

次に、クライアント機１におけるこれらの制御について、図４５を参照しながら説明する。

まず、ＷＥＢサーバ２００からデータが送信されると、クライアント機１は、プロモーション結果入力／編集画面７４０を表示し（ステップＳ４１９）、プレビュー命令を待機する（ステップＳ４１９２）。仮に、図４３の保存ボタン７４４がクリックされると、クライアント機１にプレビューが命令され、クライアント機１は、図４４に示す登録確認画面Ｓ４１９３を表示し（ステップＳ４１９３）、保存命令を待機する（ステップＳ４１９４）。なお、このフローチャートでは、省略されているが、登録確認画面７３０が表示されて後、保存ボタン７４５がクリックされた場合には、処理を終了して画面をプロモーション結果入力／編集画面７４０に遷移させることはいうまでもない。

一時保存ボタン７４４または保存ボタン７４５がクリックされると、クライアント機１は、回答の整合性チェックサブルーチンを実行する（ステップＳ４１９５）。

図４６は、整合性チェックの詳細を示すフローチャートである。

図４６を参照して、クライアント機１は、まず、チェック対象となる設問番号を初期化する（ステップＳ４６１）。次いで、初期化された設問番号に該当する設問に対する回答状況を取得する（ステップＳ４６２）。次いで、設問のタイプが検討され、リストボックス形式の質問またはチェックボックス形式の回答形式である場合、回答が一つ以上選択されているか否かが検出される（ステップＳ４６３〜Ｓ４６５）。仮に、回答が全く選択されていない場合（値がＮｕｌｌである場合）には、整合性が不合格と認定され、回答が正しくない旨のワーニングメッセージを表示して（ステップＳ４６６）、回答が正しくなかった設問部分を画面上部に自動スクロールし、ユーザに再入力を促して処理を終了する（ステップＳ４６７）。他方、回答が選択されている場合には、設問番号を更新し（ステップＳ４６８）、次の設問の整合性をチェックする（ステップＳ４６９）。仮に全ての設問のチェックが終了している場合には、整合性合格と認定して、処理を終了する。他方、未チェックの設問がある場合には、ステップＳ４６２に制御を戻して、チェックを続ける。

この実施形態では、設問回答形式として、上記リストボックス、チェックボックスの他にラジオボタンやフリーテキスト形式のものが含まれている。しかし、ラジオボタンについては、必ず回答が選択された状態になるので、整合性チェックの対象とはされない。また、フリーテキスト形式のものについても、任意回答であるので、整合性チェックの対象とはされない。

図４５に戻って、整合性チェックが終了した後、クライアント機１は、保存のタイプによって、保存態様を変更する（ステップＳ４１９６〜Ｓ４１９８）。

まず、保存命令が一時保存である場合、すなわち、一時保存ボタン７４４をクリックしたことによる保存命令である場合、クライアント機１は、プロモーションユーザ回答メインテーブル１９１の属性「送信フラグ」に一時保存を意味するデータを付して保存する。他方、保存命令が、保存ボタン７４５をクリックしたことによる保存命令である場合、クライアント機１は、プロモーションユーザ回答メインテーブル１９１の属性「送信フラグ」に保存を意味するデータを付して保存する。この結果、後述するように、属性「送信フラグ」を参照することによって、爾後の処理を分岐させることが可能になる。ここで、卸会社から製薬会社に回答を送る場合、この「回答」は、通常は、卸会社が製薬会社に課金する有料コンテンツである。従って、依頼先、依頼元の双方において、この有料コンテンツとしての「回答」が、契約通りの条件で提供されることが必要になる。本実施形態では、プロモーションユーザ回答メインテーブル１９１に属性｛送信フラグ、承認フラグ｝によって、課金対象となる「回答」の提供を契約内容に基づいて管理されるので、回答の課金管理が確実となり、取引が安全に行なわれることになる。

保存要求を出力すると、ＷＥＢサーバ２００では、後述する図４７のフローで、プロモーションユーザ回答メインテーブル１９１、プロモーションユーザ回答詳細テーブル１９２に接続し、タプルを更新する。このコミットが完了すると、ＷＥＢサーバ２００は、完了応答を送信する。

保存要求を出力した後、クライアント機１は、ＷＥＢサーバ２００からの完了応答を待機する（ステップＳ４１９９）。完了応答が得られず、セッションが遮断した場合には、エラー画面を表示し、処理を終了する（ステップＳ４１９Ａ）。

完了応答があった場合には、処理を図３７で示したステップＳ３７９に戻して、画面をターゲット選択画面７１０に遷移させ（ステップＳ４１９Ｂ）、メインルーチンに戻る。

次に、図４７を参照しながら、プロモーション結果の保存処理について詳述する。

図４７は、プロモーション結果の保存処理サブルーチンＳ４２１を示すフローチャートである。

同図を参照して、クライアント機１からデータの保存要求があると、ＷＥＢサーバ２００は、プロモーションユーザ回答メインテーブル１９１、プロモーションユーザ回答詳細テーブル１９２に接続し（ステップＳ４２１１、Ｓ４２１２）、送信されたデータの有無を確認する（ステップＳ４２１３）。仮にデータが既存のプロモーション結果の更新であった場合、ＷＥＢサーバ２００は、各テーブル１９１、１９２内の該当データを削除する（ステップＳ４２１４）。次いで、削除の良否が判別され（ステップＳ４２１５）、削除が仮に不成功だった場合、ＷＥＢサーバ２００は、データベースマネジメントシステム１１５からその情報を取得し、エラーメッセージ用のＨＴＭＬを作成する（ステップＳ４２１６）。

他方、ステップＳ４２１３において、送信されたデータが新規である場合、またはステップＳ４２１５において削除が成功した場合、ＷＥＢサーバ２００は、再度、プロモーションユーザ回答メインテーブル１９１、プロモーションユーザ回答詳細テーブル１９２に接続して、データの更新を行う（ステップＳ４２１７）。

この処理が成功した場合には、コミット終了のＨＴＭＬを作成する（ステップＳ４２１８、Ｓ４２１９）。他方、ステップＳ４２１８において、データの更新に失敗した場合には、ステップＳ４２１５の場合と同様に、エラーメッセージ用のＨＴＭＬを作成する（ステップＳ４２１６）。

次に、登録されたプロモーション結果の入力について、製薬会社に対して自動送信が設定されているか否かが判別される（ステップＳ４２１９）。この判別は、具体的には、プロモーションユーザ回答メインテーブル１９１の属性「送信フラグ」の値によって、会社毎に設定されているものである。仮に、自動報告設定がなされている場合、処理はターゲット共通自動報告サブルーチンに移行する（ステップＳ４２１Ａ）。

他方、自動送信が設定されていない場合には、登録完了情報または生成されたエラーＨＴＭＬをクライアント機１に送信して、処理を終了する。

次に図４８を参照して、ターゲット共通自動報告サブルーチンについて説明する。

このサブルーチンが実行されると、ＷＥＢサーバ２００は、担当ターゲット／ターゲットリンクテーブルに接続し（ステップＳ４８１）、ターゲットのＩｄが共通する製薬会社のユーザを検索する（ステップＳ４８２）。ここで、ユーザの有無が判別され（ステップＳ４８３）、ユーザが見つかった場合には、製薬ユーザテーブル１２６に接続して（ステップＳ４８４）、検索された製薬会社のユーザのメールアドレスを検索する。メールアドレスの有無が判別され（ステップＳ４８５）、アドレスが見つかった場合には、そのアドレスを用いてプロモーション結果が入力された旨のメールを送信する。

他方、ステップＳ４８３でユーザが存在しない場合、またはステップＳ４８６でユーザのメールアドレスが登録されていない場合、ＷＥＢサーバ２００は、製薬アラート送信先テーブル１２０Ａに接続し（ステップＳ４８８）、送信先のメールアドレスを検索する（ステップＳ４８９）。ここで、メールアドレスの有無が判別され（ステップＳ４８９）、メールアドレスが検索された場合には、登録された製薬ユーザにメールが送信されるとともに（ステップＳ４８０Ａ）、検索されなかった場合には、アラームメールをシステム管理者に送信する（ステップＳ４８０Ｂ）。

このように、本実施形態では、担当ターゲット／ターゲットリンクテーブルによって、複数の担当と複数のターゲットとを関連づけることができるので、上述したような自動送信機能を持たせることも可能になる。

図４９は、登録によりプロモーション回答の状態遷移を示すアイコンを示す図である。

図３８及び図４９を参照して、プロモーション結果が登録されると、ターゲット選択画面７１０のステータス欄には、アイコン７１５が表示される。アイコン７１５は、図４９に示すように、例えば４つのステータス毎に変更されるものであり、（Ａ）は一時保存、（Ｂ）は保存後、上長の確認待ち、（Ｃ）は製薬会社への送信待ち、（Ｄ）は製薬会社へ送信済をそれぞれ表している。

これらのステータスは、プロモーションユーザ回答メインテーブル１９１の属性｛送信フラグ、承認フラグ｝に入力された値の組み合わせによって決定され、表示されるようになっている。各フラグへの値の入力は、上述した保存処理や後述する上長確認処理によって行われる。但し、上長が確認したプロモーション結果のみを製薬会社に送信する、上長が確認しなくても、製薬会社に送信する、といった運用は、企業毎に決定され、ＷＥＢサーバ２００にその条件付けがなされている。ＷＥＢサーバ２００は、上記条件に基づいて、夜間のバッチ処理により、ＦＴＰサーバ３００を作動させ、対応する製薬会社の共有フォルダ３０１に更新されたデータをアップロードする。

次に、卸会社のメニュー画面（図３６参照）７００から担当ターゲット登録ボタン７０３をクリックしたときの処理について説明する。

上述したように、通常、卸会社がシステムに登録される際、当該卸会社が担当するターゲットは、名寄せがされた状態でターゲットマスタテーブル１４１に登録され、ターゲット／ユーザリンクテーブル１５３によって管理される。

次に、卸会社の監督者が利用できる機能について説明する。

図５０は、卸会社の監督者用メニュー画面８００を示す図である。

同図を参照して、監督者用メニュー画面８００には、プロモーション結果に対する確認やコメントを入力するためのプロモーション確認コメント入力ボタン８０１と、自社内でプロモーションを実施するためのプロモーションマスタテーブル作成ボタン８０２と、本社メッセージを登録、編集するための本社メッセージ編集ボタン８０３と、ログインに失敗してロックアウトした社員のロックを解除するロックアウト解除ボタン８０４と、担当施設を参照する担当施設参照ボタン８０５と、入力されたプロモーションのサマリを表示するためのサマリ表示ボタン８０６とが設けられている。

さらに、これらのボタン８０１〜８０６の下側には、卸システムアナウンステーブル１３７に登録されたヘッドオフィスメッセージを表示する欄８００ａと、ＷＥＢサーバ２００が送信する情報欄８００ｂとが設けられている。

まず、登録されたプロモーション結果に対する上長の確認処理について説明する。

図５０を参照して、上記情報欄８００ｂには、卸会社の担当者が回答したプロモーションのうち、上長が未確認のものが集計されて表示されている。このリンクまたは、プロモーション確認コメント入力ボタン８０１をクリックすることにより、上長確認入力要求がクライアント機１からＷＥＢサーバ２００に対して送信される。

図５１は、上長確認入力処理の全体フローを示すフローチャートである。

図５１を参照して、クライアント機１は、ＷＥＢサーバ２００に対して、プロモーション結果作成要求を送信する（ステップＳ５１１）。

ＷＥＢサーバ２００は、クライアント機１からの要求を受信すると（ステップＳ５１２）、メタデータテーブル群に接続し、ＨＴＭＬで具体化されるプロモーション結果の上長確認入力エディタの生成に必要なデータを取得する（ステップＳ５１３）。さらに、上長確認入力データ処理サブルーチンに移行して、上長確認入力エディタ８１０を生成する（ステップＳ５１４）。次いで、生成されたデータをクライアント機１に送信する（ステップＳ５１５）。

他方、クライアント機１では、プロモーションの作成／編集要求（ステップＳ５１１）をＷＥＢサーバ２００に送信した後、受信を待機し（ステップＳ５１６）、タイムアウトの場合、または受信不良には、エラー画面を表示し（ステップＳ５１７、Ｓ５１８）、受信できた場合には、データを展開して上長確認入力処理サブルーチンＳ５１９に移行する。

図５２は、図５１の処理によって生成された上長確認入力エディタ（画面）８２０を示す図である。

同図を参照して、上長確認入力エディタ８１０は、検索フレーム８１１と、組織フレーム８１２及びプロモーションフレーム８１３とを有し、これらに囲まれた一覧フレーム８１４内にプロモーション結果が一覧形式でリストアップされている。

検索フレーム８１１には、検索用の入力ボックス８１１ａ〜８１１ｅと、検索ボタン８２１ｆと、全入力ボックス８１１ａ〜８１１ｅをＮｕｌｌにするリセットボタン８１１ｊが設けられており、入力ボックス８１１ａ〜８１１ｅに選択的に入力された文字列に基づいて、検索ボタンをクリックすることにより、一覧フレーム８１４に表示されているプロモーションの絞り込み検索を行なうことができるようになっている。

組織フレーム８１２は、自社の組織（本店、支店等）を卸会社テーブル群１３０のテーブル１３１〜１３５に基づいて、ツリー状に表示するものである。

プロモーションフレーム８１３は、プロモーションメインテーブル１８１とプロモーションユーザ回答メインテーブル１９１とのデータに基づき、自社に関連するプロモーションをツリー状に表示するものである。

一覧フレーム８１４は、検索フレーム８１１での検索結果に基づいて、プロモーションユーザ回答メインテーブル１９１のタプルをプロモーションの回答結果としてリストアップしたものであり、担当者名、施設名、製薬会社名、チェックボックス、ステータス、プロモーションタイトル、実施日時、期限、入力期限等が項目として設定されている。

上記ステータスの欄には、図４９で説明したアイコン７１５が表示されている。これらのプロモーション回答結果のうち、アイコン７１５が確認待ち（図４９（Ｂ）の状態）になっているものが、上長の確認対象となっている。なお、図示の実施形態では、図５０のメニュー画面から情報欄８００ｂのリンクをクリックした場合、この一覧フレーム８１４には、確認対象となっているタプルのみが動的ＳＱＬによって絞り込まれた状態で表示されるようになっている。

さらに、上長確認入力エディタ８１０のフレーム部分には、プロモーション結果に対する確認を承認する確認ボタン８１０ｄと、未確認状態を表示する未確認ボタン８１０ｅとが設けられている。そして、タプルのチェックボックスにマークを入れ、何れかのボタン８１０ｄ、８１０ｅをクリックすることにより、プロモーションユーザ回答メインテーブル１９１の承認フラグの値が更新される。この値の更新により、プロモーション回答毎にステータスが決定され、上記ステータス欄のアイコンが変化する。

上長確認入力エディタ８１０のユーザは、一覧フレーム８１４のタプルのうち、プロモーションタイトル欄の値をクリックすることにより、当該プロモーション結果の詳細を閲覧することが可能になっている。

図５３は、上長確認入力エディタ８１０から遷移したプレビュー画面８２０を示す図である。

同図を参照して、ユーザがプロモーションタイトル欄の値をクリックすることにより、ＷＥＢサーバ２００は、プロモーション結果管理テーブル群１８０の各テーブル１８１〜１８３、並びにプロモーション回答メインテーブル１９１及びプロモーションユーザ回答詳細テーブル１９２からプロモーション結果回答のプレビュー画面８２０を表示する。

このプレビュー画面８２０では、最終項目に上長がコメントを入力するための入力ボックス８２１が形成され、上長は、この入力ボックス８２１に文字列を入力することが可能になっている。

さらに、プレビュー画面８２０には、保存ボタン８２２、確認ボタン８２３、前ページに移動する移動ボタン８２４が設けられ、保存ボタン８２２または確認ボタン８２３をクリックすることにより、プロモーションユーザ回答メインテーブル１９１の承認フラグの値を更新しながら、上長確認入力エディタ８１０に遷移するようになっている。また、この際、上長は、この入力ボックス８２１にコメントを入力した場合には、その値が、プロモーションユーザ回答詳細テーブル１９２に保存されるようになっている。

図５４及び図５５は、プロモーション確認入力処理のサブルーチンを示すフローチャートである。

これらの図並びに図５２、図５３を参照して、図５１のフローにおいて、ＷＥＢサーバ２００からデータを受信（ステップＳ５１６）すると、クライアント機１は、図５２で示した上長確認入力エディタ８１０を表示する（ステップＳ５４１）。次いで、クライアント機１は、ユーザの入力を待機する（ステップＳ５４２、ステップＳ５４３、ステップＳ５４８）。

ユーザが一覧フレーム８１４の表ヘッダ８２４ａ〜８２４ｊをクリックすると、クライアント機１は、クリックされた属性をキーにして、プロモーション一覧画面のソート処理要求をＷＥＢサーバ２００に送信する（ステップＳ５４２、Ｓ５４４）。

ユーザが組織フレーム８１２またはプロモーションフレーム８１３のツリーを操作し、特定の組織またはプロモーションをハイライトさせた場合（ステップＳ５４５、ステップＳ５４６）、クライアント機１は、ハイライトされた属性をキーにして、一覧フレーム８１４のタプルを絞り込むフィルタ処理要求をＷＥＢサーバ２００に出力する（ステップＳ５４７）。

そして、これらの操作により、ＷＥＢサーバ２００は、動的ＳＱＬによって、一覧フレーム８１４のタプルのソートまたはフィルタ処理を行ない、ＨＴＭＬを生成して、クライアント機１に返信する。

次に、ユーザが組織フレーム８２４から特定のプロモーション名をクリックすると、当該タプルに係るプレビュー画面８２０（図５３参照）が表示される。クライアント機１は、このプレビュー画面８２０でユーザがコメントを入力するのを待機しており（ステップＳ５４０Ａ）、図５３のボタン８３２、８３３がユーザによってクリックされることによって、保存要求（ステップＳ５４０Ｂ）を出力する。これにより、上述したようにデータがＷＥＢサーバ２００に送信され、プロモーション回答メインテーブル１９１及びプロモーションユーザ回答詳細テーブル１９２が更新される。その後は、制御がステップＳ５４１に移行することにより、プレビュー画面８２０が上長確認入力エディタ８１０に遷移する。

図５５を参照して、プレビュー画面８２０の確認ボタン８２３がクリックされた場合、クライアント機１は、チェックボックス表ヘッダ８２４ｄの属性にチェックが入っているか否かを判別し（ステップＳ５５１、ステップＳ５５２）、何れのタプルにもチェックが入っていない場合にはワーニングメッセージを表示する（ステップＳ５４４）。他方、チェックが入っているタプルがある場合には、そのタプルについて、確認要求がＷＥＢサーバ２００に送信される。この要求を受けて、ＷＥＢサーバ２００は、プロモーションユーザ回答メインテーブル１９１の承認フラグの値を更新し、完了応答をクライアント機１に送信する。クライアント機１では、確認要求を行った後、完了応答を待機しており（ステップＳ５５５）、完了応答があった場合には、フローを図５４のステップＳ５４１に戻すとともに、セッションが遮断した場合には、エラー画面を表示して処理を終了する（ステップＳ５５６）。

上長確認入力エディタ８１０の未確認ボタン８３４がクリックされた場合も同様に、クライアント機１は、チェックボックス表ヘッダ８２４ｄの属性にチェックが入っているか否かを判別し（ステップＳ５５７、ステップＳ５５８）、何れのタプルにもチェックが入っていない場合にはワーニングメッセージを表示する（ステップＳ５４４）。他方、チェックが入っているタプルがある場合には、そのタプルについて、確認要求がＷＥＢサーバ２００に送信される。この要求を受けて、ＷＥＢサーバ２００は、プロモーションユーザ回答メインテーブル１９１の承認フラグの値をＮＵＬＬに更新し、完了応答をクライアント機１に送信する。クライアント機１では、確認要求を行った後、完了応答を待機しており（ステップＳ５５０Ａ）、完了応答があった場合には、フローを図５４のステップＳ５４１に戻すとともに、セッションが遮断した場合には、エラー画面を表示して処理を終了する（ステップＳ５５６）。

次に、上長確認入力処理のサーバ側の保存処理について、説明する。

図５６は、図５１における上長確認保存処理サブルーチンのフローチャートである。

同図を参照して、ＷＥＢサーバ２００がクライアント機１から保存要求を受けると、その種別が判別され（ステップＳ５６１）、コメントの保存である場合には、プロモーションユーザ回答メインテーブル１９１及びプロモーションユーザ回答詳細テーブル１９２に接続して（ステップＳ５６２）、プロモーションユーザ回答詳細テーブル１９２にデータを保存する（ステップＳ５６３）。一方、確認登録の場合には、プロモーションユーザ回答メインテーブル１９１に接続し（ステップＳ５６４）、プロモーションユーザ回答メインテーブル１９１から承認フラグの既存のデータを取得する（ステップＳ５６５）。そして、確認ボタン８１０ｄと未確認ボタン８１０ｅの何れのボタンによって登録要求がなされたかが識別され（ステップＳ５６６）、確認要求の場合には、確認状態に承認フラグの値を更新し（ステップＳ５６７）、未確認要求の場合には、未確認状態（ＮＵＬＬ）に承認フラグの値を更新する（ステップＳ５６８）。

ステップＳ５６３、ステップＳ５６７、ステップＳ５６８の処理の後、コミットが成功したか否かが確認され（ステップＳ５６９）、成功した場合には、コミットが完了した旨のＨＴＭＬを生成し（ステップＳ５６０Ａ）、仮に未成功の場合には、エラーＨＴＭＬを生成する（ステップＳ５６０Ｂ）。そして、生成後のデータをクライアント機１に送信して処理を終了する（ステップＳ５６０Ｃ）。

なお、卸会社の監督者用メニュー画面からは、プロモーションマスタテーブル作成ボタン８０２をクリックすることにより、自社向けのプロモーション依頼を作成し、社内で実施することが可能である。これは、上述した製薬会社のプロモーション依頼の手順において、製薬会社側プロモーションテーブル群１６０に代えて卸会社側プロモーションテーブル群１７０を用いることにより、実現される。

また、本社メッセージ編集ボタン８０３をクリックして、システムアナウンステーブル１３７を編集する画面を利用することにより、関係者が利用するメニュー画面にメッセージを表示することが可能である。

また、ロックアウト解除ボタン８０４をクリックして、卸ユーザテーブル１３６を編集する画面を利用することにより、ログインに失敗してロックアウトした社員のロックを解除することが可能である。

さらに、担当施設参照ボタン８０５をクリックして、卸ユーザテーブル１３６ターゲット／ユーザリンクテーブル１５３を編集する画面を利用することにより、各担当者の担当ターゲットを参照することが可能である。

なお、本実施形態では、省略されているが、製薬会社においても、管理者用のメニュー画面を設け、ロックアウト解除やメッセージ編集等を行なうことができることはいうまでもない。

次に各ユーザに共通の機能について説明する。

図１６、図３６、図５０を参照して、各ユーザのメニュー画面には、サマリ表示ボタン６０２、７０２、８０６が設けられており、これらのボタンをクリックすると、ＷＥＢサーバ２００にサマリ表示要求が送信される。

図５７はサマリ表示要求処理の全体フローを示すフローチャートである。

図５７を参照して、サマリ表示要求（ステップＳ５７１）が送信され、ＷＥＢサーバ２００がクライアント機１からの要求を受信すると（ステップＳ５７２）、ＷＥＢサーバ２００は、組織ツリー作成処理サブルーチン（ステップＳ５７３）、プロモーションツリー作成処理サブルーチン（ステップＳ５７４）、及びサマリデータ処理サブルーチン（ステップＳ５７５）に移行して、サマリ画面９００を生成する。次いで、生成されたデータをクライアント機１に送信する（ステップＳ５７６）。

他方、クライアント機１では、サマリ表示要求（ステップＳ５７１）をＷＥＢサーバ２００に送信した後、受信を待機し（ステップＳ５７７）、タイムアウトの場合、または受信不良には、エラー画面を表示し（ステップＳ５７８、Ｓ５７９）、受信できた場合には、データを展開してサマリ画面を表示し、サマリ操作サブルーチンに移行する（ステップＳ５７０Ａ）。

図５８は、図５７の処理によって生成されたサマリ画面９００を示す図である。

図５８を参照して、サマリ画面９００は、集計リストを表示するリストフレーム９０１と、リストフレーム９０１の左上側に設けられ、卸組織をツリー構造で表示する組織フレーム９０２と、組織フレーム９０２の下側に設けられ、プロモーションをツリー構造で表示するプロモーションフレーム９０３とを有している。

図５９は、図５８の画面を生成する際のプロモーションツリー作成処理サブルーチンを示すフローチャート、図６０は同画面を生成する際の組織ツリー作成処理サブルーチンを示すフローチャート、図６１は、同画面を生成する際の組織ツリー作成処理サブルーチンを示すフローチャートである。

図５９を参照して、卸組織フレーム９０３（図５８参照）は、卸組織ツリー作成処理サブルーチン（ステップＳ５７３）によって生成される。このサブルーチンでは、ＷＥＢサーバ２００は、卸マスタテーブル１３１、卸本店テーブル１３２、卸支店テーブル１３３、卸営業所テーブル１３４、卸課テーブル１３５、及び卸ユーザマスタテーブル１３６に接続し（ステップＳ５７３〜Ｓ５７６）、静的ＳＱＬによって、卸組織情報とユーザの組み合わせ全てを取り出すクエリーを発行する（ステップＳ５７７）。次いで、ＷＥＢサーバ２００は、卸組織ツリーＨＴＭＬを作成する（ステップＳ５７８）。このＨＴＭＬがクライアント機１に送信されることにより、卸組織フレーム９０３（図５８参照）が表示される。

次に、図６０を参照して、組織フレーム９０２（図５８参照）は、プロモーションツリー作成処理サブルーチン（ステップＳ５７３）によって生成される。このサブルーチンでは、動的ＳＱＬが作成開始し、ＷＥＢサーバ２００は、プロモーションメインテーブル１８１に接続し、プロモーション履歴参照可能期間内に実施されていたプロモーション情報を取得するＳＱＬを作成する（ステップＳ５７３１）。次いで、このＳＱＬが実行され、プロモーションツリーＨＴＭＬが生成される（ステップＳ５７３２）。このＨＴＭＬがクライアント機１に送信されることにより、プロモーション組織フレーム９０４（図５８参照）が表示される。

次に、図６１を参照して、サマリデータ処理サブルーチン（ステップＳ５７５）について説明する。

このサブルーチンでは、まず、アクセスしたユーザが製薬会社のユーザであるか否かがアカウントＩＤに基づいて判別される（ステップＳ５７５１）。そして、判別されたユーザ毎に下記の通り動的ＳＱＬが作成開始される。

ユーザが製薬会社に所属する場合、ＷＥＢサーバ２００は、製薬会社向けサマリテーブル１９４に接続し（ステップＳ５７５２）、卸会社に所属する場合には、卸会社向けサマリテーブル１９３に接続する（ステップＳ５７５３）。ここで、卸会社向けサマリテーブル１９３に接続した場合には、直ちに当該卸会社に基づいて、プロモーションメインテーブル１８１の絞り込みが行われる（ステップＳ５７５４）。他方、製薬会社向けサマリテーブル１９４に接続された場合には、卸会社が図５８のサマリ画面９００からユーザが選択した後、卸会社に基づいて、プロモーションメインテーブル１８１の絞り込みが行われる（ステップＳ５７５５）。

次いで、図５８で示した組織フレーム９０２において、何れの組織または担当者が選択されているかが判別され（ステップＳ５７５６〜５７５０Ａ）、選択されている組織または担当者毎にプロモーションメインテーブル１８１が絞り込まれる（ステップＳ５７５０Ｂ〜Ｓ５７５０Ｆ）。さらに、図５８で示したプロモーションフレーム９０３において、プロモーションの選択が判別され（ステップＳ５７５０Ｇ）、プロモーションが選択されている場合には、当該プロモーションに基づいてプロモーションメインテーブル１８１が絞り込まれる（ステップＳ５７５０Ｈ）。これにより、動的ＳＱＬが生成される。

次いで、生成された動的ＳＱＬが実行され、サマリ画面ＨＴＭＬが生成される（ステップＳ５７５０Ｉ）。これにより、上記動的ＳＱＬで選択されたプロモーションメインテーブル１８１のタプルが図５８のリストフレーム９０１に表示されることになる。

図６２は、サマリ画面の各フレーム９０２、９０３を操作することによって、リストボックスに表示されるタプルの処理を示すフローチャートである。

図５８、図６２を参照して、サマリ画面９００が表示されると（ステップＳ６２１）、クライアント機１は、ユーザから組織フレーム９０２及びプロモーション９０３の中から特定の組織と特定のプロモーションが選択されるのを待機している（ステップＳ６２２、Ｓ６２３）。そして、両者が選択された場合に、それらをキーにして、サマリ条件変更要求を出力する（ステップＳ６２６）。ＷＥＢサーバ２００は、この要求を受けると、選択された卸組織とプロモーションとをキーにしてプロモーションメインテーブル１８１を図６１の動的ＳＱＬで絞り込み、生成された動的ＳＱＬを実行して、実行結果をクライアント機１に送信する。これにより、図６３で示すように、サマリ画面９００のリストフレーム９０１内に、プロモーションメインテーブル１８１のタプルが表示される。

図６３を参照して、生成されたＨＴＭＬは、リストフレーム９０１内に、施設名表ヘッダ９０１ａ、月次表ヘッダ９０１ｂ、階層変更ボタン９０１ｃ、ＣＳＶ出力ボタン９０１ｄを有している。

表ヘッダ９０１ａ〜９０１ｂは、各画面と同様に、表示されているタプルの並び替えを命令するボタンを兼ねている。また、階層変更ボタン９０１ｃは、表示されている施設の階層レベルを変更するためのものであり、このボタン９０１ｃを操作することにより、例えば、図６４のように、ターゲットの下位の組織を属性として追加することができるようになっている。また、ＣＳＶボタン９０１ｄは、表示されているタプルをＣＳＶ形式でダウンロードするためのものである。

図６５は、リストフレーム９０１が表示されたサマリ画面の操作処理を示すフローチャートである。

まず、サマリ画面９００が表示されると（ステップＳ６５１）、クライアント機１は、ユーザが表ヘッダ９０１ａ、９０１ｂを操作するか否か判別し（ステップＳ６５２、ステップＳ６５３）、操作された場合には、ソート処理要求をＷＥＢサーバ２００に出力する（ステップＳ６５４）。この要求が出力されると、ＷＥＢサーバ２００は、クリックされた表ヘッダ９０１ａ、９０１ｂの属性に基づいて、ＡＳＣまたはＤＩＳＣのソート処理を行なってＨＴＭＬを生成し、クライアント機１にデータを送信する。

また、階層変更ボタン９０１ｃがクリックされた場合（ステップＳ６５７）、クライアント機１は、サマリレベル変更処理要求をＷＥＢサーバ２００に送信する（ステップＳ６５８）。この要求を受信すると、ＷＥＢサーバ２００は、列属性を一階層分追加する動的ＳＱＬを生成して実行させ、生成されたＨＴＭＬをクライアント機１に送信する。図６３に示すように、生成されたＨＴＭＬには、さらに下位の組織やユーザのリンク９０１ｅが形成されており、これらをクリックすることによって、さらに、階層を変更することができるようになっている。

また、組織フレーム９０２やプロモーションフレーム９０３に変更があった場合には（ステップＳ６５７、ステップＳ６５８）、クライアント機１は、サマリ条件変更処理要求をＷＥＢサーバ２００に送信する（ステップＳ６５９）。この要求を受信すると、ＷＥＢサーバ２００は、図６１のサブルーチンを再度実行する。

次に、ＣＳＶボタン９０１ｄがクリックされた場合（ステップＳ６５０Ａ）、クライアント機１は、ＣＳＶ出力要求をＦＴＰサーバ３００に送信する。この送信を受けると、ＷＥＢサーバ２００は、表示されているタプルをＣＳＶ形式に変換し、変換されたデータをＦＴＰサーバ３００によって、クライアント機１にダウンロードさせる。

最後に処理が終了したか否かが判別され（ステップＳ６５０Ｃ）、終了していなければステップＳ６５２に処理を戻す。

次に、プロモーション履歴管理機能について説明する。

サマリ画面９００の各タプルの施設欄には、リンクが形成されており、このリンクをクリックすることによって、ＷＥＢサーバ２００に対し、該当するタプル毎の履歴を表示する要求が送信されるようになっている。

図６６は、履歴表示処理の全体フローを示すフローチャートである。

図６６を参照して、クライアント機１は、ＷＥＢサーバ２００に対して、履歴表示要求を送信する（ステップＳ６６１）。

ＷＥＢサーバ２００は、クライアント機１からの要求を受信すると（ステップＳ６６２）、プロモーションメインテーブル１８１に接続し、履歴表示画面の生成に必要なデータを取得する（ステップＳ６６３）。さらに、履歴表示画面処理サブルーチンに移行して、履歴一覧画面１０００を生成する（ステップＳ６６４）。次いで、生成されたデータをクライアント機１に送信する（ステップＳ６６５）。

他方、クライアント機１では、プロモーションの作成／編集要求（ステップＳ６６１）をＷＥＢサーバ２００に送信した後、受信を待機し（ステップＳ６６６）、タイムアウトの場合、または受信不良には、エラー画面を表示し（ステップＳ６６７、Ｓ６６８）、受信できた場合には、データを展開して履歴画面操作サブルーチンＳ６６９に移行する。

図６７は、生成された履歴一覧画面１０００を示す図である。

図６７を参照して、生成された履歴一覧画面１０００は、クリックされたプロモーションマスタテーブルのタプル（図６３参照）の情報に基づいて、プロモーションを検索するための検索フレーム１００１と、この検索フレーム１００１の下段に設けられて、プロモーションをリストアップする一覧フレーム１００２とが設けられている。

検索フレーム１００１には、検索用の入力ボックス１００１ａ〜１００１ｄと、検索ボタン１００１ｅ、全入力ボックス１００１ａ〜１００１ｄをＮｕｌｌにするリセットボタン１００１ｆとが設けられており、入力ボックス１００１ａ〜１００１ｄに選択的に入力された文字列に基づいて、検索ボタン１００１ｆをクリックすることにより、一覧フレーム１００２に表示されているプロモーションの絞り込み検索を行なうことができるようになっている。

一覧フレーム１００２に表示された各タプルには、各プロモーションの詳細表示を開閉するための表示ボタン１００２ａと、タプルを移動するための移動ボタン１００２ｂとが設けられている。

図６８は、図６７の履歴一覧画面１０００において、表示ボタン１００２ａが操作されたときの要求に対するＷＥＢサーバの処理を示すフローチャートである。

図６８を参照して、ＷＥＢサーバ２００は、動的ＳＱＬを実行し、プロモーションユーザ回答テーブル１９１、プロモーションユーザ回答詳細テーブル１９２にそれぞれ接続する（ステップＳ６８１、ステップＳ６８２）。

次いで、これらテーブルの絞り込み条件として、製薬会社が選択されているか否かが判別され（ステップＳ６８３）、選択されている場合（サマリ画面９００からクリックした場合には、未選択状態となっている）には、製薬会社をキーにして、プロモーションメインテーブル１８１に絞り込みが追加される（ステップＳ６８４）。さらに、製薬会社が選択されている場合には、カテゴリ（入力ボックス１００１ｃで選択されるプロモーションの分類）が選択されているか否かが判別され（ステップＳ６８５）、選択されている場合には、そのカテゴリでプロモーションメインテーブル１８１が絞り込まれる（ステップＳ６８６）。さらに、プロモーションが選択されているか否かが判別され（ステップＳ６８７）、選択されている場合には、選択されたプロモーションをキーにして、プロモーションメインテーブル１８１が絞り込まれる（ステップＳ６８８）。

また、日付の範囲（入力ボックス１００１ｄ）が選択されているか否かが判別され（ステップＳ６８９）、選択されている場合には、日付についてもプロモーションメインテーブル１８１が絞り込まれる（ステップＳ６８０Ａ）。

そして、生成された動的ＳＱＬに基づいて、サマリ画面ＨＴＭＬが接続されたテーブル１９１、１９２から生成され（ステップＳ６８０Ｂ）、クライアント機１に送信される（ステップＳ６８０Ｃ）。これにより、履歴一覧画面１０００が図６９で示すように遷移する。

上述した実施形態は本発明の好ましい態様を例示したものに過ぎず、本発明は上述した実施形態に限定されない。本発明の特許請求の範囲内で種々の変更が可能であることはいうまでもない。

医薬業界における製薬会社と卸会社の関係を示す説明図である。医薬業界における製薬会社、卸会社、ターゲット（施設）の関係を示す説明図である。本発明の実施の一形態に係る医薬ビジネス情報共有システムの概略構成を示す図である。本発明の実施の一形態に係る医薬ビジネス情報共有システムの概略構成を示す構成図である。本発明の実施の一形態に係る医薬ビジネス情報共有システムを利用したワークフローを示す説明図である。本発明の実施形態に係るデータベースのＥＲ図である。本発明の実施形態に係るデータベースのＥＲ図である。本発明の実施形態に係るデータベースのＥＲ図である。本発明の実施形態に係る情報共有システムを利用するユーザが用いる画面遷移図である。本発明の実施形態に係る情報共有システムを利用するユーザが用いる画面遷移図である。本発明の実施形態に係る情報共有システムを利用するユーザが用いる画面遷移図である。各ユーザに共通するログイン画面を示すものである。同ログイン画面によって操作されたデータのフローを示すフローチャートである。図１３のメニュー表示サブルーチン処理の詳細である。エラー画面を示す図である。製薬会社のユーザがログインした場合のメニュー画面情報共有システム１０を示す図である。プロモーションの一覧要求があった場合のフローチャートである。図１７の処理によって生成された画面を示す図である。プロモーションを作成してから登録するまでの処理全体を示すフローチャートである。図１９のプロモーション作成／編集データ処理のサブルーチンを示すフローチャートである。新規のプロモーションを作成するための画面（作成編集エディタ）を示す図である。プロモーションが入力された画面（作成編集エディタ）を示す図である。クライアント機において、プロモーションを作成する時のプロモーション作成処理サブルーチンを示すフローチャートである。クライアント機において、プロモーションを作成する時のプロモーション作成処理サブルーチンを示すフローチャートである。ハートビート処理の詳細を示すフローチャートである。プレビュー画面を示す図である。クライアント機から要求されたプロモーション依頼の保存処理を示すフローチャートである。卸登録処理をするためのアイコンを示す図である。卸会社を登録する場合の処理全体を示すフローチャートである。図２９における卸登録データ作成処理のサブルーチンを示すフローチャートである。図３０のサブルーチンによって生成された画面を示す図である。クライアント機における卸登録処理サブルーチンを示すフローチャートである。クライアント機における卸登録処理サブルーチンを示すフローチャートである。卸登録処理サブルーチンにおいて、卸一覧フレームを更新する場合の処理を示すフローチャートである。卸組織が登録されている卸登録画面を示す図である。卸会社の一般ユーザのメニュー画面を示している。ターゲットの一覧要求があった場合のフローチャートである。施設選択画面を示す図である。遷移した登録確認画面である。印刷されたサンプルを示す図である。プロモーション結果作成処理の全体フローを示すフローチャートである。図４１のフローにより生成されたＨＴＭＬに基づく画面を示す図である。図４１のフローにより生成されたＨＴＭＬに基づく画面を示す図である。図４１のフローにより生成されたＨＴＭＬに基づく画面を示す図である。プロモーション結果入力／編集画面におけるクライアント機の制御フローを示すフローチャートである。整合性チェックの詳細を示すフローチャートである。プロモーション結果の保存処理サブルーチンを示すフローチャートである。ターゲット共通自動報告サブルーチンを示すフローチャートである。登録によりプロモーション回答の状態遷移を示すアイコンを示す図である。卸会社の監督者用メニュー画面を示す図である。上長確認入力処理の全体フローを示すフローチャートである。図５１の処理によって生成された上長確認入力エディタ（画面）を示す図である。確認入力エディタから遷移した登録確認画面を示す図である。プロモーション確認入力処理のサブルーチンを示すフローチャートである。プロモーション確認入力処理のサブルーチンを示すフローチャートである。図５１における上長確認保存処理サブルーチンのフローチャートである。サマリ表示要求処理の全体フローを示すフローチャートである。図５７の処理によって生成されたサマリ画面を示す図である。図５８の画面を生成する際のプロモーションツリー作成処理サブルーチンを示すフローチャートである。同画面を生成する際の組織ツリー作成処理サブルーチンを示すフローチャートである。同画面を生成する際の組織ツリー作成処理サブルーチンを示すフローチャートである。サマリ画面の各フレームを操作することによって、リストフレームに表示されるタプルの処理を示すフローチャートである。図６２の処理によって生成されたサマリ画面を示す図である。図６２の処理によって生成されたサマリ画面を示す図である。リストフレームが表示されたサマリ画面の操作処理を示すフローチャートである。履歴表示処理の全体フローを示すフローチャートである。図６６の処理によって生成された履歴画面を示す図である。図６７の履歴画面において、表示ボタンが操作されたときの要求に対するＷＥＢサーバの処理を示すフローチャートである。図６８の処理によって生成された画面である。

符号の説明

１パーソナルコンピュータ（クライアント機の一例）
２ＰＤＡ（クライアント機の一例）
３携帯電話（クライアント機の一例）
１０情報共有システム
１００データベースサーバ
１１５データベースマネジメントシステム
１２１製薬マスタテーブル（製薬マスタテーブルエンティティの一例）
１２６製薬ユーザテーブル（製薬ユーザエンティティの一例）
１２９担当ターゲットテーブル（担当ターゲット／ターゲットリンク連関エンティティの一例）
１２９製薬ユーザ担当ターゲットテーブル（製薬ユーザ担当ターゲットエンティティの一例）
１３０卸会社テーブル群
１３１卸マスタテーブル（卸マスタテーブルエンティティの一例）
１３２卸本店テーブル
１３３卸支店テーブル
１３４卸営業所テーブル
１３５卸課テーブル
１３６卸ユーザマスタテーブル（卸ユーザエンティティの一例）
１３７卸システムアナウンステーブル
１３８卸アラート送信先テーブル
１４１ターゲットマスタテーブル（ターゲットマスタテーブルエンティティの一例）
１５１製薬／卸リンクテーブル（製薬／卸連関エンティティの一例）
１５２製薬ユーザ／卸リンクテーブル
１５３ターゲットユーザリンクテーブルテーブル（ターゲット／ユーザ連関エンティティの一例）
１５３ユーザリンクテーブル
１５４ターゲットリンクテーブル
１５５対象ターゲット管理テーブル（対象ターゲット管理連関エンティティの一例）
１５６卸登録マスタテーブル（依頼先登録マスタテーブル連関エンティティの一例）
１６１プロモーションマスタテーブル（発信マスタテーブルエンティティの一例）
１６２プロモーションカテゴリマスタテーブル
１６３プロモーション意思表示マスタテーブル（意思表示マスタテーブルエンティティの一例）
１６４プロモーション回答マスタテーブル（回答マスタテーブルエンティティの一例）
１７４プロモーション回答マスタテーブル
１８０プロモーション結果管理テーブル群
１８１プロモーションマスタテーブル
１８１プロモーションメインテーブル
１８２プロモーション意思表示テーブル
１８３プロモーション回答テーブル
１９１プロモーションメインテーブル
１９１プロモーションユーザ回答テーブル
１９１プロモーションユーザ回答メイン
１９１プロモーションユーザ回答メインテーブル
１９１プロモーション回答メインテーブル
１９２プロモーションユーザ回答詳細テーブル
１９３サマリテーブル
１９４サマリテーブル
２００ＷＥＢサーバ（作成編集エディタ提供手段、発信情報記録手段、依頼情報提供手段、回答エディタ提供手段、回答情報記録手段、回答提供手段の一例）
３００ＦＴＰサーバ
４００メールサーバ
５００サーバシステム
６００メニュー画面
６００ログイン画面
６２０プロモーション一覧画面
６３０プロモーション作成／編集エディタ
６４０プレビュー画面
６５０卸登録画面
６６０プロパティ編集画面
７００メニュー画面
７１０ターゲット選択画面
７３０登録確認画面
７４０プロモーション結果入力／編集画面
８００監督者用メニュー画面
８１０上長確認入力エディタ
８２０プレビュー画面
９００サマリ画面
１０００履歴一覧画面

Claims

製薬会社を一元的に管理するための属性を有する製薬マスタエンティティ、製薬マスタエンティティに対して１：多のカーディナリティで関連可能な外部キー属性を有し、製薬会社の担当者を一元的に管理するための属性を有する製薬ユーザエンティティ、卸会社を一元的に管理するための属性を有する卸マスタエンティティ、卸マスタエンティティに対して１：多のカーディナリティで関連可能な外部キー属性を有し、卸会社の担当者を一元的に管理するための属性を有する卸ユーザエンティティ、製薬会社と卸会社との間で情報共有の対象となるターゲットを一元的に管理するための属性を有するターゲットマスタエンティティ、製薬会社と卸会社の何れかの担当者が発信する依頼情報を記録する属性を有する発信マスタエンティティ、発信マスタエンティティと１：多のカーディナリティで関連可能な外部キー属性を有し、発信された依頼情報に対する回答を記憶する属性を有する回答用のエンティティとを記憶するデータベースと、
このデータベースのエンティティを管理するデータベースマネジメントシステムと、
このデータベースとクライアント機との間でトランザクションを実行するサーバシステムと
を備えた医薬ビジネス情報共有システムであって、
上記データベースは、
製薬マスタエンティティと卸マスタエンティティとを多：多のカーディナリティで関連づける属性を主キーとする製薬／卸連関エンティティと、
卸ユーザエンティティとターゲットエンティティとを多：多のカーディナリティで関連づける属性を主キーとするターゲット／ユーザ連関エンティティと、
ターゲットエンティティと発信マスタエンティティとを多：多のカーディナリティで関連づける属性を主キーとする対象ターゲット管理連関エンティティと、
発信マスタエンティティと卸マスタエンティティとを多：多で関連づける属性を主キーとする依頼先登録マスタテーブル連関エンティティと
を記憶していることを特徴とする医薬ビジネス情報共有システム。
請求項１記載の医薬ビジネス情報共有システムにおいて、
上記発信マスタエンティティは、製薬会社用と卸会社用とに独立して記憶されていることを特徴とする医薬ビジネス情報共有システム。
請求項１または２記載の医薬ビジネス情報共有システムにおいて、
上記データベースは、
卸マスタエンティティを親として直系の１：多のカーディナリティで関連づけられ、卸会社の組織を特定する属性を有する複数の卸組織エンティティを有し、上記卸登録マスタエンティティは、卸マスタエンティティ、各卸組織エンティティ、並びに卸ユーザエンティティとそれぞれ１：多のカーディナリティで関連づけられる外部キーを有していることを特徴とする医薬ビジネス情報共有システム。
請求項１、２、または３記載の医薬ビジネス情報共有システムにおいて、
上記データベースは、
上記製薬ユーザエンティティに対し、１：多のカーディナリティで関連可能な外部キー属性を有する製薬ユーザ担当ターゲットエンティティと、
この製薬ユーザ担当ターゲットエンティティと上記ターゲットマスタテーブルとを多：多のカーディナリティで関連づける属性を主キーとする担当ターゲット／ターゲットリンク連関エンティティとを記憶していることを特徴とする医薬ビジネス情報共有システム。
請求項１から４の何れか１に記載の医薬ビジネス情報共有システムにおいて、
上記データベースは、
発信マスタエンティティに対して１：多のカーディナリティで関連可能な外部キー属性を有し、依頼情報として発信マスタエンティティに登録される依頼情報の意思表示項目を生成するための属性を有する意思表示マスタエンティティと、この意思表示マスタエンティティに対して１：多のカーディナリティで関連可能な外部キー属性を有し、当該意思表示マスタエンティティの意思表示項目に対する回答を生成するための属性を有する回答マスタエンティティとを有していることを特徴とする医薬ビジネス情報共有システム。
請求項５記載の医療ビジネス情報共有システムにおいて、
上記データベースマネジメントシステムは、
上記発信マスタエンティティと卸登録マスタエンティティとをユニオン結合したメインテーブルと、
上記意思表示マスタエンティティと卸登録マスタエンティティとをユニオン結合した意思表示テーブルと、
上記回答マスタエンティティと卸登録マスタエンティティとをユニオン結合した回答テーブルとを生成するものであり、
上記回答マスタテーブルは、上記メインテーブルに対して１：多で関連づけられているものであることを特徴とする医薬ビジネス情報共有システム。
請求項１から６の何れか１記載の医薬ビジネス情報共有システムにおいて、
上記データベースマネジメントシステムは、回答用のエンティティに記録された履歴回数をカウントしたサマリテーブルを生成するものであることを特徴とする医薬ビジネス情報共有システム。
請求項１から７の何れか１記載の医薬ビジネス情報共有システムにおいて、
上記サーバシステムは、
依頼元からの依頼情報と依頼先とを関連づける依頼情報／依頼先関連情報の入力手段を含み、製薬会社と卸会社のうち何れかの依頼元に対して、依頼情報の作成または修正用のエディタを、認証を受けたアカウントを有するクライアント機に提供する作成編集エディタ提供手段と、
提供された作成編集エディタによって生成された依頼情報を発信マスタエンティティに記録するとともに、上記入力情報によって入力された依頼情報／依頼先関連情報を依頼先登録マスタテーブル連関エンティティに記録する発信情報記録手段と
を備えていることを特徴とする医薬ビジネス情報共有システム。
請求項８記載の医薬ビジネス情報共有システムにおいて、
上記サーバシステムは、
発信マスタエンティティに記録された依頼情報を依頼先となる会社に提供する依頼情報提供手段と、
提供された依頼情報に対する回答を入力するための回答エディタを、認証を受けたアカウントを有するクライアント機に提供する回答エディタ提供手段と、
提供された回答エディタによって入力された回答情報を回答用のエンティティに記録する回答情報記録手段と、
回答された情報を依頼先に提供する回答提供手段と
を備えていることを特徴とする医薬ビジネス情報共有システム。
請求項８または９記載の医薬ビジネス情報共有システムにおいて、
上記回答用のエンティティは、保存される回答情報に対して、当該回答情報者の上司が付加する上長情報を保存する属性を有し、
上記サーバシステムは、回答情報者の上司に対し、保存される回答情報に対して上記上長情報を付加する上長確認入力エディタを提供する情報付加エディタ提供手段を有していることを特徴とする医薬ビジネス情報共有システム。
請求項８から１０の何れか１記載の医薬ビジネス情報共有システムにおいて、
上記回答用のエンティティは、依頼元の担当者に回答を提供するための条件となる値をフラグとして保存する属性を有し、
上記回答提供手段は、上記回答用エンティティの上記条件となる値に基づき、許可された回答のみを依頼先に提供するものであるするものであることを特徴とする医薬ビジネス情報共有システム。
請求項１１記載の医薬ビジネス情報共有システムにおいて、
上記回答エディタ提供手段は、依頼先が一時的にデータを保存するための一時保存フラグを入力する手段を有し、上記回答用のエンティティは、上記条件となる値として、一時保存フラグを保存するための属性を有するものであることを特徴とする医薬ビジネス情報共有システム。
請求項１１または１２記載の医薬ビジネス情報共有システムにおいて、
上記回答用のエンティティは、上記条件となる値として、上長の承認を保存する属性を有していることを特徴とする医薬ビジネス情報共有システム。
請求項８から１３の何れか１記載の医薬ビジネス情報共有システムにおいて、
上記データベースは、
上記製薬ユーザエンティティに対し、１：多のカーディナリティで関連可能な外部キー属性を有する製薬ユーザ担当ターゲットエンティティと、
この製薬ユーザ担当ターゲットエンティティと上記ターゲットマスタテーブルとを多：多のカーディナリティで関連づける属性を主キーとする担当ターゲット／ターゲットリンク連関エンティティとを記憶し、
上記回答提供手段は、
担当ターゲット／ターゲットリンク連関エンティティによって特定される依頼元のユーザが存在する場合に、当該依頼元のユーザのメールアドレスに回答が更新された旨を報知する電子メールを自動送信するものであることを特徴とする医薬ビジネス情報共有システム。
請求項８から１４の何れか１記載の医薬ビジネス情報共有システムにおいて、
上記データベースは、
ユーザエンティティに対して１：多のカーディナリティで関連づけられる外部キー属性を有し、ユーザ毎に種類の異なる報告情報を特定する属性を含むアラートエンティティを記憶し、
上記回答提供手段は、担当ターゲット／ターゲットリンク連関エンティティによって特定される依頼元のユーザが存在しない場合に、アラートエンティティによって特定されるユーザに対して回答が更新された旨を報知する電子メールを自動送信するものであることを特徴とする医薬ビジネス情報共有システム。