JP2002297394A - 情報処理装置及びその方法とそのシステム - Google Patents

Abstract

(57)【要約】 【課題】 各ユーザに提供する機能の設定・変更を容易
にする。 【解決手段】 インターネット１０１を介してユーザに
アプリケーションを提供する情報処理装置において、ア
プリケーションのフレームワークを記憶するアプリケー
ション・フレームワーク２０４と、各機能に対応する機
能部品オブジェクトを記憶する機能部品オブジェクトラ
イブラリ２０５と、アプリケーション・フレームワーク
２０４に記憶されたアプリケーションのフレームワーク
と、ユーザの機能要求に応じた機能部品オブジェクトと
を組合わせ、当該ユーザにアプリケーションとして提供
する。又各ユーザに提供している機能部品オブジェクト
の変更、機能追加を容易に行うことができ、更には、新
規な機能部品オブジェクトの追加に際して、その機能部
品の価格をユーザのニーズやアンケートに基づいて決定
することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えばＡＳＰ(App
lication Service Provider)などにおいて、ユーザに提
供するアプリケーションプログラムを、オブジェクト指
向アプリケーションにより実現する情報処理装置及びそ
の方法とそのシステムに関するものである。

【０００２】

【従来の技術】ＡＳＰとは、インターネット経由で、同
一のアプリケーションを複数ユーザーに提供し、そのア
プリケーション、ハードウェア、運用管理を、提供する
ベンダー側が集中管理することで、ユーザに対して安価
にアプリケーションの利用環境を提供するサービスであ
る。これによりユーザは、アプリケーションを利用する
にあたって発生する、ハードウェア、アプリケーション
の開発、インフラ整備等の初期コスト、そしてそれを維
持管理するための運用コストを、共同利用と集中管理に
より削減できる。

【０００３】

【発明が解決しようとする課題】しかし、その反面、同
一のアプリケーションを複数ユーザに提供するため、ユ
ーザ個別の変更要求、機能追加要求などへの対応ができ
ない、もしくは困難であるという問題がある。

【０００４】また仮に、ユーザ個別に対応した機能変更
又は追加等を行う場合、各ユーザ個別に対応した運用管
理がベンダー側に発生し、そのために発生するコスト
を、そのユーザに負担してもらうと、ＡＳＰとしての価
格メリットが薄れてしまう。又このコストをベンダー側
で負担すると、ベンダーとしての事業が圧迫されてしま
うことになる。

【０００５】また、ある程度汎用的な業務向けのアプリ
ケーションを開発し、それを多数のユーザに販売するこ
とにより、ユーザ個別に受託して開発するよりも安い価
格で各種アプリケーションを提供するパッケージアプリ
ケーションが知られている。このようなパッケージアプ
リケーションでは、各ユーザ毎のカスタマイズも、他ユ
ーザへの影響がないため比較的柔軟に対応できる。しか
しそのカスタマイズ作業は各ユーザ毎に発生し、そのカ
スタマイズに関わる工数と一定の余剰分は、そのユーザ
が負担しなければならない。よって、ユーザにとって
は、パッケージを購入したにもかかわらず、それ以上の
カスタマイズ料金が発生し、パッケージアプリケーショ
ンのメリットが薄れてしまうことになる。

【０００６】そして何より、ハードウェア及びソフトウ
ェア購入という初期投資と、その後の運用管理が利用す
る各ユーザに発生し、これが大きなコスト負担となる。
中小企業のＩＴ化が進まない一因は、これら運用管理コ
ストの大きさにあるとも言えるであろう。

【０００７】本発明は上記従来例に鑑みてなされたもの
で、各ユーザに提供する機能の設定・変更を容易にした
情報処理装置及びその方法とそのシステムを提供するこ
とを目的とする。

【０００８】また本発明の目的は、新規な機能を機能部
品として登録し、全てのユーザが利用可能なサービスと
して提供できる情報処理装置及びその方法とそのシステ
ムを提供することにある。

【０００９】

【課題を解決するための手段】上記目的を達成するため
に本発明の情報処理装置は以下のような構成を備える。
即ち、インターネットを介してユーザにアプリケーショ
ンを提供する情報処理装置であって、アプリケーション
のフレームワークを記憶するフレームワーク記憶手段
と、各機能に対応する機能部品オブジェクトを記憶する
機能部品オブジェクト記憶手段と、前記フレームワーク
記憶手段に記憶されたアプリケーションのフレームワー
クと、ユーザの機能要求に応じた、前記機能部品オブジ
ェクト記憶手段に記憶された機能部品オブジェクトとを
組合わせ、当該ユーザにアプリケーションとして提供す
るように制御する制御手段と、を有することを特徴とす
る。

【００１０】上記目的を達成するために本発明の情報処
理方法は以下のような工程を備える。即ち、インターネ
ットを介してユーザにアプリケーションを提供する情報
処理方法であって、各ユーザに提供するアプリケーショ
ンを、アプリケーションのフレームワークと、当該ユー
ザの機能要求に応じた機能部品オブジェクトとを組合わ
せ、当該ユーザにアプリケーションとして提供すること
を特徴とする。

【００１１】上記目的を達成するために本発明の情報処
理システムは以下のような構成を備える。即ち、インタ
ーネットを介してサーバと複数のユーザとが接続され、
前記サーバより各ユーザにアプリケーションを提供する
情報処理システムであって、前記サーバは、アプリケー
ションのフレームワークを記憶するフレームワーク記憶
手段と、各機能に対応する機能部品オブジェクトを記憶
する機能部品オブジェクト記憶手段と、前記フレームワ
ーク記憶手段に記憶されたアプリケーションのフレーム
ワークと、ユーザの機能要求に応じた、前記機能部品オ
ブジェクト記憶手段に記憶された機能部品オブジェクト
とを組合わせ、当該ユーザにアプリケーションとして提
供するように制御する制御手段と、を有することを特徴
とする。

【００１２】

【発明の実施の形態】以下、添付図面を参照して本発明
の好適な実施の形態を詳細に説明する。

【００１３】本実施の形態では、オブジェクト指向技術
により開発されたアプリケーションにおいて、各オブジ
ェクトを利用顧客毎に、選択統合し提供するサービスで
あることから名付けられたObjectsIntegrationService
「ＯＩＳ」を用いた求貨求車システムの例で説明する
が、本発明はこのようなシステムに限定されるものでは
ない。

【００１４】この求貨求車システムは、例えば往路で荷
物を運搬した車両が復路で空荷になるのを防止し、実車
率を高めて、運搬コストを低下させるインターネットシ
ステムサービスである。

【００１５】まず最初に、オブジェクト指向のアプリケ
ーション開発のメリットと、その活用の主な概要を説明
する。オブジェクト指向開発アプリケーションは、ソフ
トウェアをオブジェクト単位で管理しているため、その
オブジェクトの部品化、および再利用が可能となる。こ
れは、そのアプリケーションを構成する各オブジェクト
は、それ以外のオブジェクトに対して影響を及ぼさない
ことから、ビジネススピードに対応したアプリケーショ
ンの変更（バージョンアップ）、管理（メンテナンス）
が容易になるというメリットがある。このため、各種ア
プリケーションの受託開発や、パッケージアプリケーシ
ョンのカスタマイズに際しても、そのオブジェクトの変
更や再利用が可能になり、最初からそのアプリケーショ
ンを開発する場合に比べて、比較的低コストでカスタマ
イズ或いはバージョンアップできるという利点がある。

【００１６】しかし、そのアプリケーションの管理は、
結局、各ユーザ毎に発生しているため、オブジェクト指
向のメリットを完全に発揮することができない。またオ
ブジェクトの再利用によるアプリケーションの実装に際
しても、その価格決定は、開発したベンダーに完全に依
存する。従って、その価格設定では、ベンダーが利益を
確保することはできても、そのメリットがユーザに反映
されなければ、オブジェクト指向開発アプリケーション
の購入側であるユーザにおけるメリットは完全に発揮さ
れずに薄れてしまう。

【００１７】そこで、本実施の形態では、アプリケーシ
ョンを、そのフレームワークと、それぞれが機能部品で
ある各オブジェクトとで構成し、ユーザごとに提供する
オブジェクトを設定して提供するとともに、新規のオブ
ジェクトを適正な価格でユーザに提供することを目的と
している。

【００１８】以下、具体的に説明する。

【００１９】図１は、本実施の形態に係る求貨求車シス
テムの基本概略構成を示す概念図である。

【００２０】このシステムはインターネット１０１に公
衆回線などを介して接続される求貨求車システムサーバ
１００と、同じくインターネット１０１に公衆回線など
を介して接続される複数のユーザ端末１０２〜１０４と
を有している。各ユーザ端末は、Ｗｅｂサーバを介し
て、これとリンクする求貨求車システムサーバ１００に
アクセス可能なプラウザ機能を有するコンピュータであ
れば、専用機であっても、他の処理を行い得る汎用機で
あってもよい。但し、実際に取り引きの信頼性を確保す
るために後述する参加人データベースに信用情報を登録
し、例えばパスワード，ＩＤ等を取得することで、サー
バ１００にアクセス、又は競りに参加できるようにする
と良い。

【００２１】このサーバ１００は、回線インターフェー
ス（Ｉ／Ｆ）部１１２を介して外部、即ち、インターネ
ット１０１を介して各ユーザ端末との間で、各種データ
を送受信できるようになっており、各ユーザ端末から入
力された内容が、必要に応じて処理部１１０にて処理さ
れ、記憶部１１１に記憶される。また逆に、記憶部１１
１に記憶された内容が処理部１１０によって処理され、
各ユーザ端末に送信される。

【００２２】処理部１１０は、記憶部１１１または他の
記憶手段（媒体）に記憶されたプログラムを実行するＣ
ＰＵを備えていても良く、後述する会員情報の管理、競
り対象データと、これに対応する入札データとの比較、
同一対象に対する入札データ同士の比較などを行うもの
である。

【００２３】図２は、本実施の形態に係る求貨求車シス
テムにおける求貨求車システムサーバ１００の構成を中
心により詳しく示す概念図で、図１の構成と共通する部
分は同じ番号で示している。

【００２４】図２において、記憶部１１１には、会員デ
ータベース２０１、荷物データベース２０２，空車デー
タベース２０３がそれぞれ構築されている。会員データ
ベース２０１の各レコードは、荷物データベース２０２
又は空車データベース２０３の各レコードにリンクして
いる。これにより、１つの会員が別々の複数の荷物を運
びたい場合や、または１つの会員が復路便の荷物を探す
場合、更には、１つの会員が複数台の空車を有している
場合などに対処できるようになっている。会員データベ
ース２０１のフィールドとしては、名前、住所、連絡
先、主取引先、過去にトラブルがあったか、即ち、クレ
ーム履歴などの公開情報の他に各種信用情報、会員ＩＤ
などがある。荷物データベース２０２のフィールドとし
ては、商品名，積地、降地、降日、重量、所有会員（例
えばＩＤ）等を必須項目（空白を禁止するフィールド）
とし、積込み条件（パレット、平積みなど）、荷降条
件、指定車種等をオプション項目とする公開情報の他、
入札終了時間（寄付希望時間）、荷物ＩＤ、各種状態を
表すフラグ、さらに入札する際の入札運賃、非公開情報
としての希望運賃等がある。更に空車データベース２０
３のフィールドとしては、空車地、空車日、希望行き
先、車種、積載量、所有会員（例えばＩＤ）等を必須項
目（空白を禁止するフィールド）とし、運転手名、車
番、携帯電話番号、空車時刻、養生等をオプション項目
とする公開情報の他に、入札終了時間（寄付希望時
間）、車両ＩＤ、各種状態を表すフラグ、更に入札する
際の入札運賃、非公開情報としての希望運賃等がある。
尚、記憶部１１１には、アクセスログ、競りの履歴など
も記憶するが、通常のサーバ運営上の管理項目であるの
で、その詳細な説明は省略する。

【００２５】２０４はアプリケーションの基幹部分（フ
レームワーク）で、各ユーザに提供するアプリケーショ
ンの基幹となる部分（コアオブジェクト）を保持してい
る。２０５は機能部品であるオブジェクトライブラリ
で、それぞれ異なる機能を実現するオブジェクト（図２
の例では、オブジェクトＡ〜オブジェクトＧ）が保持さ
れている。２０６はオブジェクト設定部で、各ユーザの
希望に応じて、そのユーザに必要な機能を有する機能部
品であるオブジェクトを機能部品オブジェクトライブラ
リ２０５から選択し、その選択したオブジェクトとアプ
リケーションフレームワーク２０４とを組合わせて、各
ユーザに対応したアプリケーションを作成している。特
にここでは、各アプリケーションをそれぞれ単一のユー
ザに対応させるのではなく、同じ機能を要求するユーザ
グループ（ここではグループ甲、乙、丙）２０９〜２１
１に分けて、各ユーザグループ単位で、提供するアプリ
ケーションを管理している。これらグループは、その取
り扱う搬送対象物や搬送条件などに応じてそれぞれ所望
する要求が異なるので、例えば鉄鋼運搬業者、化学薬品
の運搬業者、引っ越し専門業者などといったように分類
され、各グループのユーザのそれぞれは、そのグループ
に提供されるアプリケーションを共同して利用すること
ができる。

【００２６】また、各種機能部品であるオブジェクト
（Ａ〜Ｇ）の機能としては、例えば、荷物登録、空車登
録、搬送する商品の選択処理を階層化する機能等が挙げ
られる。

【００２７】又２０７はＷＷＷサーバ、２０８は、この
ＡＳＰを運営している事業者の端末である。

【００２８】図３は、本実施の形態に係るアプリケーシ
ョンフレームワーク２０４と機能部品オブジェクトライ
ブラリ２０５との関係を、各オブジェクト単位で説明す
るための図である。

【００２９】アプリケーションフレームワーク２０４
は、複数のコアオブジェクトで構成されており、各コア
オブジェクトは、オブジェクト指向プログラムで作成さ
れており、それぞれ入力(in)と出力(out)を有し、各コ
アオブジェクトの間に、追加された機能オブジェクトを
挿入して、所望の機能を有するアプリケーションを作成
することができる。図３の例では、アプリケーションフ
レームワーク２０４に機能部品オブジェクトライブラリ
２０５の機能Ａ、及び機能Ｂのオブジェクトが付加され
たアプリケーションの例で示している。

【００３０】図４は、本実施の形態に係る事業者の端末
２０８のハードウェア構成を説明するブロック図で、こ
こではこの事業者端末２０８は、サーバ１００の機能を
も共有している場合で説明する。

【００３１】図４において、４０１はＣＰＵで、ＲＡＭ
４０２のプログラムエリア４１０に記憶されたプログラ
ム（後述のフローチャートの処理を実行するプログラム
を含む）に従って、この端末２０８及びサーバ１００の
全体の動作を制御するとともに、システムバス４０８を
介して、このバス４０８に接続されている各部に制御信
号を出力して、各部の動作を制御している。ＲＡＭ４０
２は、外部記憶装置等からインストールされた各種プロ
グラムを記憶するとともに、ＣＰＵ４０１による各種制
御処理の実行時に、各種データを一時的に保存するワー
クエリアとしても使用される。４０３はＣＲＴや液晶な
どの表示部で、オペレータへの各種メッセージやデータ
入力画面等を表示する。４０４はネットワーク・インタ
ーフェース（Ｉ／Ｆ）部で、公衆回線などと接続されて
インターネット１０１への接続を可能にしている。４０
５は入力部で、例えばキーボードやマウス等のポインテ
ィングデバイスを備えている。４０６は大容量の記憶装
置で、例えばハードディスクやＭＯ等を有し、前述の図
２の記憶部１１１を構成している。４０７はＣＤ−ＲＯ
Ｍドライブやハードディスクドライブ等の外部記憶装置
で、各種プログラムや各種データのインストールなどに
も使用される。

【００３２】この求貨求車システムでは、１つ又は２つ
以上の荷主の主催する荷物に対する競りと、同じく１つ
又は２つ以上の車主の主催する空車に対する競りを並列
に開催可能となっている。また、１つの荷物又は１つの
空車を登録することで、それを競りの対象とする競りを
開催するものとし、また競りを開催すると同時に、その
登録したＩＤで他の１つの又は２つ以上の競りに参加
（入札）することができる。こうして荷主の条件に合致
する、或いは最も近いユーザが競り落とすと、その契約
内容が画面に表示されて、互いに確認を行うことが出来
る。

【００３３】次に、このような求貨求車システムにおい
て、各ユーザが所望する機能部品に相当するオブジェク
トを新たに登録したり、或いはその機能を変更する場合
の処理について説明する。

【００３４】図５は、本実施の形態に係る求貨求車シス
テムにおけるＯＩＳ部品（機能部品オブジェクトライブ
ラリ）の新規登録処理を説明するフローチャートであ
る。尚、このＯＩＳは、ＡＳＰの１つのメニューとして
ユーザに提供される。つまり特定のユーザのみが利用で
きる機能としてではなく、全ての利用可能なユーザが、
各ユーザのニーズに応じて、それらＯＩＳメニューのサ
ービスを取捨選択して利用することができる。これによ
り、あるユーザのニーズから誕生した使いやすい機能を
機能部品オブジェクトとして部品化し、ライブラリ２０
５に搭載することもできる。そしてＯＩＳメニューとし
て各ユーザに提示して提供可能にすることにより、その
機能を各ユーザが個別にカスタマイズして作成する場合
よりも、より安価にその機能を提供して、そのユーザの
アプリケーションに実装することができる。

【００３５】図５の処理は、ＩＤ、パスワードを入力し
て、この求貨求車システムにログインした後、次に実行
する処理として、画面上で「ＯＩＳ部品新規登録」を選
択することにより開始される。まずステップＳ１で、表
示部４０３の画面に、図７に示すようなＯＩＳ登録部品
選択画面を表示する。図７において、７０１はＯＩＳ登
録部品リストで、各登録部品がＯＩＳ部品のシステム名
で表示されている。７０２は現在選択されている登録部
品名を示している。この状態で、「選択」ボタン７０３
が指示されると、ＯＩＳの新規登録部品として「Object
parts A」が選択される。このようにしてステップＳ１
で、ＯＩＳ部品が選択・指定されるとステップＳ２に進
み、ステップＳ１で選択したＯＩＳ部品の詳細を設定す
る。

【００３６】この詳細設定の画面表示例を図８に示す。

【００３７】図８において、８０１には、選択されたＯ
ＩＳ部品のシステム名「Object parts A」が表示されて
いる。８０２は「ＯＩＳ部品名」で、ＯＩＳ部品のシス
テム名「Object parts A」では、その部品の機能が不明
瞭であるため、アプリケーションでの機能に見合った任
意の名称を設定を可能にしている。８０３は「金額」欄
を示し、ここに登録された金額が、実際にＯＩＳ機能と
して追加作業を行った際に、積算金額として加算される
ことになる。８０４は「関連元画面設定」、８０５は
「関連先画面設定」で、このＯＩＳ部品が、アプリケー
ションフレームワーク２０４のどの画面（コアオブジェ
クト）に追加されるかを指定する。以上の設定が完了し
た後、「登録」ボタン８０６が指示されると、これら設
定された各項目が確認画面として表示され、ここで確認
を指示することにより、その登録処理が完了する（図５
のステップＳ３）。

【００３８】次に図６のフローチャートを参照して、本
実施の形態に係る求貨求車システムにおける、各ユーザ
に対するＯＩＳ部品（機能部品オブジェクトライブラ
リ）の追加・変更処理を説明する。

【００３９】図８の処理は、ＩＤ、パスワードを入力し
て、この求貨求車システムにログインした後、次に実行
する処理として、画面上で「ユーザの機能追加・変更」
を選択することにより開始される。まずステップＳ１１
において、図９に示すように、ユーザ名のリスト９０１
が表示される。ここで「ＡＢＣ株式会社」９０２が選択
され、「選択」ボタン９０３が指示されるとステップＳ
１２に進む。ステップＳ１２では、図１０に示すよう
に、その選択されたユーザ名９０４と、そのユーザが選
択している機能部品の画面名とそのフォーム及びアイテ
ムからなるリスト９０５が表示される。この様にして表
示された複数の対象ＯＩＳの中から、その機能を変更し
たいＯＩＳが選択される。図１０の例では、ＯＩＳとし
て「荷物登録」が選択されたものとする。次にステップ
Ｓ１３に進み、その「荷物登録」の「フォーム」の変更
が指示されたかをみる。そうでなければステップＳ１５
に進むが、「フォーム」の変更が指示されるとステップ
Ｓ１４に進み、例えば画面に現在のフォーム（例えば、
Ｍ行、Ｎ列）を表示し、入力部４０５により入力される
値に応じて、その表示フォームを変更することができ
る。

【００４０】次にステップＳ１５に進み、「荷物登録」
の「アイテム」が指示された後、そのアイテムの変更、
或いは新規追加が指示されたかどうかをみる。

【００４１】この場合の表示部４０３の画面表示例を図
１１に示す。

【００４２】図１１において、９０４は、図９で選択さ
れたユーザ名を示し、９０８は図１０で選択された画面
名「荷物登録」を示し、９０８は現在選択されている変
更対象が「アイテム」であることを示している。９０９
〜９１１は、このアイテムに対する変更内容を指示する
領域で、９０９はアイテムの「新規登録」、９１０はア
イテムの「変更」、そして９１１はアイテムの「削除」
を、それぞれ指示するための領域である。９１２は、こ
の「荷物登録」の画面で表示されるアイテムのリストを
示し、このリスト内の「商品」９１３が指示されると図
１２の画面に移行する。尚、この画面上に表示しきれな
いアイテム数がある場合には、リスト９１１２をスクロ
ール表示することにより、全アイテムを表示できる。

【００４３】図１２は、図１１で「変更」９１０が指示
されて、アイテム「商品」の詳細を表示する場合の画面
例を示し、９１４はアイテム「商品」の名称や表示形
式、表示位置及び属性などを一覧表示するリストであ
る。ここで、これらの値を変更することにより、このア
イテム「商品」の名称や表示形式、属性などを変更する
ことができる。また、９１５には、この画面で利用でき
るＯＩＳ部品が表示されており、その部品名を入力部４
０５を使用してクリックすることにより、一覧表示エリ
ア９１４に反映させることができる。

【００４４】また、図１１の状態で「新既登録」９０９
が指示された場合は、図１２において、一覧リスト９１
４の設定内容が全て未指定（空白）のリストが表示さ
れ、ＯＩＳ部品欄９１５には、図１２の９１５で示すよ
うな部品一覧が表示される。ここでＯＩＳ部品が選択・
指示されると、金額欄９１６には、そのＯＩＳ部品の価
格が表示され、それに対応するリスト９１４の各欄に
は、部品名等が表示される。ここで、更に表示形式や
行、列、属性やオプション等を指定することにより、新
たなアイテムを新規登録することができる。

【００４５】次に、ユーザからのニーズにより、或いは
ＡＳＰにおいて追加したい機能のニーズがある場合、そ
の機能部品オブジェクトを作成する前に、そのオブジェ
クトの価格を決定する処理について説明する。

【００４６】図１３は、本実施の形態に係る求貨求車シ
ステムにおける、新規機能部品オブジェクト（ＯＩＳ）
の価格決定処理を示すフローチャートである。

【００４７】この処理は、ユーザからのニーズ、或いは
ＡＳＰにより見出されたニーズに基づいて開始され、ま
ずステップＳ２１で、そのニーズを基に、開発工数及び
マージン率を設定する。次にステップＳ２２に進み、初
期開発分の価格、予想利用者数等を基に、そのＯＩＳの
予定価格を求める。

【００４８】図１４は、このような各種データを入力す
るための画面例を示す図である。

【００４９】図１４において、１４００は、この機能の
仮称欄、１４０１はこの機能の詳細を説明する欄、１４
０２は、この機能を実装する画面を指示する欄である。
例えば、この一例としては、「仮称」を「代行入力」と
し、「詳細」は「幹事会社が荷物会員の荷物を代行入力
できる機能」、そして「実装」は「幹事会社画面」とす
ることなどが考えられる。

【００５０】１４０３は開発工数（単位：円）の入力
欄、１４０５は予想利用者数の入力欄である。これら各
欄の入力が終了した後、「設定」ボタン１４０６が指示
されると、これら入力された値が設定され、これらの値
に基づいて、予定価格が決定される。

【００５１】次にステップＳ２３に進み、各ユーザに対
してメールを送信し、その予定価格に対する意見（アン
ケート）を求める。

【００５２】このアンケート画面の表示例を図１５に示
す。

【００５３】図１５では、この新規なＯＩＳの予定価格
１４１０が表示され、更に、各ユーザのニーズを問うた
めの欄１４１１、価格設定に対する意見を求める欄１４
１２が表示されている。ここで、各ユーザが、自分の意
見に該当するチェックボタンをチェックし、入力が終了
した後、「送信」ボタン１４１３を指示することによ
り、そのユーザの意見がＡＳＰ側に送信される。

【００５４】こうしてステップＳ２４で、そのアンケー
ト結果を集計し、後述する重み付けや計算式に従って
「ニーズ実数」（ニーズがあると考えられる利用者
数）、「ニーズ比率」（全体に占めるニーズの比率）を
求め、これらニーズ反応に基づく価格を決定する。次に
ステップＳ２６に進み、「価格反応」（後述する）を求
め、これに基づいて判断された「価格反応からの価格」
を決定する。そしてステップＳ２７に進み、これら価格
に基づいて販売価格を決定し、それをユーザに通知す
る。

【００５５】図１６は、こうして計算された「ニーズ実
数」１６０１、「ニーズ比率」１６０２、「価格反応」
１６０３、及びこれらに基づいて決定された価格１６０
４〜１６０７を表示する画面例を示す図である。そし
て、ここで「公開」ボタン１６０８が指示されると、決
定価格１６０７が、各ユーザに対して通知される。

【００５６】「ニーズ回答係数」は、必要ない、あ
まり必要ないを共に「０」に設定し、あれば使うを
「０．５」に、必要を「０．８」に、そして必ず必
要を「１」に設定する。また「ニーズ比率係数」は、全
体に占めるニーズの割合を示し、０〜．２未満は１２
０％、０．２〜０．４未満は１１０％、０．４〜
０．６未満を１００％に、０．６〜０．８未満を９０
％に、そして０．８〜１を８０％に設定している。
又、価格のアンケートに対して、安い、すこし安い
及び適正を共に１００％に設定し、すこし高いを８
０％に、そして高いを５０％に設定する。そしてニー
ズのアンケートに対して〜で回答したユーザを対象
利用者数とし、その対象利用者の価格アンケートに基づ
く値の合計を求め、その合計を対象利用者数で割ること
により、上述の「価格反応」が求められる。

【００５７】こうした前提に基づいて、１１人の利用者
（Ａ乃至Ｋ）から得たアンケートに基づく価格決定の一
例を図１７に示す。

【００５８】ここでは開発工数（原価）が４００万円
で、初期開発費用がマージン比率（１５０％）により６
００万円となり、予想利用者数が「３」人として予定価
格が２００万円の場合、これがアンケート結果に基づい
て「１，２０４，３０３円」に決定された場合を示して
いる。尚、アンケート回答欄における各数字は、上述の
アンケートの番号〜にそれぞれ対応している。

【００５９】こうして決定された各値は、図１６の対応
する欄にそれぞれ表示され、「公開」ボタン１６０８の
指示により、電子メール形式で各ユーザに通知される。

【００６０】以上説明したように本実施の形態によれ
ば、 ・アプリケーションを多数のユーザに利用してもらい、
各機能部品オブジェクトを再利用する。

【００６１】・そのアプリケーションを一元管理する。 という環境の下で、各ユーザ別に画面の変更、機能の変
更を可能にできる。

【００６２】また、あるユーザのニーズ等から誕生し
た、使いやすい機能を部品化し、ＯＩＳメニューとし
て、個別カスタマイズより安価な価格で提供し、その機
能を、それを希望するユーザのアプリケーションに実装
することができる。

【００６３】ここで、安価に提供することができるの
は、ＡＳＰがその利用ライセンスの収益により運営され
ているため、個々の機能を提供するのに際して、その対
価を一つのユーザのみから一括して徴収する必要がない
からである。

【００６４】また本実施の形態では、各機能オブジェク
トの変更作業にかかる価格、又新たな機能を開発して実
装する価格が予めメニュー化されており、利用側はピザ
のトッピングを追加するかのように、実際に提供される
機能に基づき、必要費用を計算しながら、その機能の導
入を検討することが可能となる。このように、あるユー
ザのニーズから誕生した新規な機能部品は、専用機能部
品としてではなく、ＯＩＳの１メニューとして利用する
ことができる。このため、先行者が価格的に損をするこ
ともなく、２人目のユーザからは既存メニューとして検
討することができる。

【００６５】なお本発明は、複数の機器（例えばホスト
コンピュータ、インターフェース機器、リーダ、プリン
タなど）から構成されるシステムに適用しても、一つの
機器からなる装置（例えば、複写機、ファクシミリ装置
など）に適用してもよい。

【００６６】また本発明の目的は、前述した実施形態の
機能を実現するソフトウェアのプログラムコードを記録
した記憶媒体（または記録媒体）を、システムあるいは
装置に供給し、そのシステムあるいは装置のコンピュー
タ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプ
ログラムコードを読み出し実行することによっても、達
成される。この場合、記憶媒体から読み出されたプログ
ラムコード自体が前述した実施形態の機能を実現するこ
とになり、そのプログラムコードを記憶した記憶媒体は
本発明を構成することになる。また、コンピュータが読
み出したプログラムコードを実行することにより、前述
した実施形態の機能が実現されるだけでなく、そのプロ
グラムコードの指示に基づき、コンピュータ上で稼働し
ているオペレーティングシステム（ＯＳ）などが実際の
処理の一部または全部を行い、その処理によって前述し
た実施形態の機能が実現される場合も含まれる。

【００６７】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された機能拡張カー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書込まれた後、そのプログラムコードの指示
に基づき、その機能拡張カードや機能拡張ユニットに備
わるＣＰＵなどが実際の処理の一部または全部を行い、
その処理によって前述した実施形態の機能が実現される
場合も含まれる。

【００６８】

【発明の効果】以上説明したように本発明によれば、各
ユーザに提供する機能の設定・変更を容易にできるとい
う効果がある。

【００６９】また本発明によれば、新規な機能を機能部
品として登録し、全てのユーザが利用可能なサービスと
して提供できるという効果がある。

【図面の簡単な説明】

【図１】本実施の形態に係る求貨求車システムの基本概
略構成を示す概念図である。

【図２】本実施の形態に係る求貨求車システムにおける
求貨求車システムサーバの構成を中心により詳しく示す
概念図である。

【図３】本実施の形態に係るアプリケーションフレーム
ワークと機能部品オブジェクトライブラリとの関係を、
各オブジェクト単位で説明するための図である。

【図４】本実施の形態に係る事業者の端末のハードウェ
ア構成を説明するブロック図である。

【図５】本実施の形態に係る求貨求車システムにおける
ＯＩＳ部品（機能部品オブジェクトライブラリ）の新規
登録処理を説明するフローチャートである。

【図６】本実施の形態に係る求貨求車システムにおける
ＯＩＳ部品（機能部品オブジェクトライブラリ）の追
加、変更処理を説明するフローチャートである。

【図７】本実施の形態に係る求貨求車システムにおける
ＯＩＳ登録部品選択画面の表示例を示す図である。

【図８】ＯＩＳ登録部品の詳細設定の画面表示例を示す
図である。

【図９】本実施の形態に係る求貨求車システムにおける
ユーザ名を選択するためのリスト表示例を示す図であ
る。

【図１０】ユーザ名に対応するＯＩＳ画面を変更する際
の表示例を示す図である。

【図１１】ユーザ名に対応するＯＩＳ画面のアイテムを
変更する際の表示例を示す図である。

【図１２】ユーザ名に対応するＯＩＳ画面のアイテムを
変更する際の表示例を示す図である。

【図１３】本実施の形態に係る求貨求車システムにおけ
る、新規機能部品オブジェクト（ＯＩＳ）の価格決定処
理を示すフローチャートである。

【図１４】新規機能部品オブジェクトの各種データを入
力するための画面表示例を示す図である。

【図１５】新規機能部品オブジェクトのニーズ及び価格
に対するアンケートを求める画面表示例を示す図であ
る。

【図１６】アンケート結果に基づく結果表示画面例を示
す図である。

【図１７】アンケート結果に基づく価格決定の一例を説
明する図である。

Claims (26)

【特許請求の範囲】
1. 【請求項１】 インターネットを介してユーザにアプリ
   ケーションを提供する情報処理装置であって、 アプリケーションのフレームワークを記憶するフレーム
   ワーク記憶手段と、 各機能に対応する機能部品オブジェクトを記憶する機能
   部品オブジェクト記憶手段と、 前記フレームワーク記憶手段に記憶されたアプリケーシ
   ョンのフレームワークと、ユーザの機能要求に応じた、
   前記機能部品オブジェクト記憶手段に記憶された機能部
   品オブジェクトとを組合わせ、当該ユーザにアプリケー
   ションとして提供するように制御する制御手段と、を有
   することを特徴とする情報処理装置。
2. 【請求項２】 前記機能部品オブジェクト記憶手段に新
   たな機能部品オブジェクトを追加する機能追加手段を更
   に有することを特徴とする請求項１に記載の情報処理装
   置。
3. 【請求項３】 前記機能部品オブジェクト記憶手段に記
   憶されている機能部品オブジェクトの内、所定のユーザ
   に対応する機能部品オブジェクトを変更する機能変更手
   段を更に有することを特徴とする請求項１に記載の情報
   処理装置。
4. 【請求項４】 前記機能変更手段は、前記所定のユーザ
   に対応する機能部品オブジェクトの表示フォーム、又は
   表示内容の少なくともいずれかを変更することを特徴と
   する請求項３に記載の情報処理装置。
5. 【請求項５】 前記機能追加手段は、更に、 新規機能オブジェクトの予想価格を算定する算定手段
   と、 前記新規機能オブジェクトのニーズ及び前記予想価格を
   ユーザに提示して問い合わせる問合せ手段と、 前記問合せ手段により問い合わせの回答結果に基づいて
   前記新規機能オブジェクトの価格を決定する価格決定手
   段と、有することを特徴とする請求項２に記載の情報処
   理装置。
6. 【請求項６】 前記問合せ手段による問合せは、前記ニ
   ーズ及び前記予想価格のそれぞれに対して複数の回答選
   択肢を設けており、 前記価格決定手段は、前記複数の回答選択肢のそれぞれ
   に重み付けを行って回答結果を集計し、前記ニーズ及び
   予想価格のそれぞれに対する問合せに対する回答結果に
   基づいて前記新規機能オブジェクトの価格を決定するこ
   とを特徴とする請求項５に記載の情報処理装置。
7. 【請求項７】 前記アプリケーションのフレームワーク
   は、オブジェクト指向プログラムで記述されていること
   を特徴とする請求項１乃至６のいずれか１項に記載の情
   報処理装置。
8. 【請求項８】 前記機能部品オブジェクトは、オブジェ
   クト指向プログラムで記述されていることを特徴とする
   請求項１乃至７のいずれか１項に記載の情報処理装置。
9. 【請求項９】 インターネットを介してユーザにアプリ
   ケーションを提供する情報処理方法であって、 各ユーザに提供するアプリケーションを、アプリケーシ
   ョンのフレームワークと、当該ユーザの機能要求に応じ
   た機能部品オブジェクトとを組合わせ、当該ユーザにア
   プリケーションとして提供することを特徴とする情報処
   理方法。
10. 【請求項１０】 新たな機能部品オブジェクトを追加す
    る機能追加工程を更に有することを特徴とする請求項９
    に記載の情報処理方法。
11. 【請求項１１】 所定のユーザに対応する機能部品オブ
    ジェクトを変更する機能変更工程を更に有することを特
    徴とする請求項９に記載の情報処理方法。
12. 【請求項１２】 前記機能変更工程では、前記所定のユ
    ーザに対応する機能部品オブジェクトの表示フォーム、
    又は表示内容の少なくともいずれかを変更することを特
    徴とする請求項１１に記載の情報処理方法。
13. 【請求項１３】 前記機能追加工程では、更に、 新規機能オブジェクトの予想価格を算定する算定工程
    と、 前記新規機能オブジェクトのニーズ及び前記予想価格を
    ユーザに提示して問い合わせる問合せ工程と、 前記問合せ工程による問い合わせの回答結果に基づいて
    前記新規機能オブジェクトの価格を決定する価格決定工
    程と、有することを特徴とする請求項１０に記載の情報
    処理方法。
14. 【請求項１４】 前記問合せ工程における問合せは、前
    記ニーズ及び前記予想価格のそれぞれに対して複数の回
    答選択肢を設けており、 前記価格決定工程では、前記複数の回答選択肢のそれぞ
    れに重み付けを行って回答結果を集計し、前記ニーズ及
    び予想価格のそれぞれに対する問合せに対する回答結果
    に基づいて前記新規機能オブジェクトの価格を決定する
    ことを特徴とする請求項１３に記載の情報処理方法。
15. 【請求項１５】 前記アプリケーションのフレームワー
    クは、オブジェクト指向プログラムで記述されているこ
    とを特徴とする請求項９乃至１４のいずれか１項に記載
    の情報処理方法。
16. 【請求項１６】 前記機能部品オブジェクトは、オブジ
    ェクト指向プログラムで記述されていることを特徴とす
    る請求項９乃至１５のいずれか１項に記載の情報処理方
    法。
17. 【請求項１７】 インターネットを介してサーバと複数
    のユーザとが接続され、前記サーバより各ユーザにアプ
    リケーションを提供する情報処理システムであって、 前記サーバは、 アプリケーションのフレームワークを記憶するフレーム
    ワーク記憶手段と、 各機能に対応する機能部品オブジェクトを記憶する機能
    部品オブジェクト記憶手段と、 前記フレームワーク記憶手段に記憶されたアプリケーシ
    ョンのフレームワークと、ユーザの機能要求に応じた、
    前記機能部品オブジェクト記憶手段に記憶された機能部
    品オブジェクトとを組合わせ、当該ユーザにアプリケー
    ションとして提供するように制御する制御手段と、を有
    することを特徴とする情報処理システム。
18. 【請求項１８】 前記サーバは、 前記機能部品オブジェクト記憶手段に新たな機能部品オ
    ブジェクトを追加する機能追加手段を更に有することを
    特徴とする請求項１７に記載の情報処理システム。
19. 【請求項１９】 前記サーバは、 前記機能部品オブジェクト記憶手段に記憶されている機
    能部品オブジェクトの内、所定のユーザに対応する機能
    部品オブジェクトを変更する機能変更手段を更に有する
    ことを特徴とする請求項１７に記載の情報処理システ
    ム。
20. 【請求項２０】 前記機能変更手段は、前記所定のユー
    ザに対応する機能部品オブジェクトの表示フォーム、又
    は表示内容の少なくともいずれかを変更することを特徴
    とする請求項１９に記載の情報処理システム。
21. 【請求項２１】 前記機能追加手段は、更に、 新規機能オブジェクトの予想価格を算定する算定手段
    と、 前記新規機能オブジェクトのニーズ及び前記予想価格を
    ユーザに提示して問い合わせる問合せ手段と、 前記問合せ手段により問い合わせの回答結果に基づいて
    前記新規機能オブジェクトの価格を決定する価格決定手
    段と、有することを特徴とする請求項１８に記載の情報
    処理システム。
22. 【請求項２２】 前記問合せ手段による問合せは、前記
    ニーズ及び前記予想価格のそれぞれに対して複数の回答
    選択肢を設けており、 前記価格決定手段は、前記複数の回答選択肢のそれぞれ
    に重み付けを行って回答結果を集計し、前記ニーズ及び
    予想価格のそれぞれに対する問合せに対する回答結果に
    基づいて前記新規機能オブジェクトの価格を決定するこ
    とを特徴とする請求項２１に記載の情報処理システム。
23. 【請求項２３】 前記制御手段は、 前記複数のユーザの内、同様な機能を要求するユーザ群
    単位で管理し、当該ユーザ群に共通する機能部品オブジ
    ェクトの組み合わせを提供することを特徴とする請求項
    １７に記載の情報処理システム。
24. 【請求項２４】 前記アプリケーションのフレームワー
    クは、オブジェクト指向プログラムで記述されているこ
    とを特徴とする請求項１７乃至２３のいずれか１項に記
    載の情報処理システム。
25. 【請求項２５】 前記機能部品オブジェクトは、オブジ
    ェクト指向プログラムで記述されていることを特徴とす
    る請求項１７乃至２４のいずれか１項に記載の情報処理
    システム。
26. 【請求項２６】 請求項９乃至１６のいずれか１項に記
    載の情報処理方法を実行するプログラムを記憶したこと
    を特徴とする、コンピュータにより読取り可能な記憶媒
    体。