JP6892053B2 - Ａｉを使用したソースコード売買システム - Google Patents

Description

本発明は、コンピュータプログラムのソースコードの売買を仲介するソースコード売買システムに関する。

各種の商品の売買を仲介する売買システムが知られている。販売者と購入者との間で価格調整を行う機能を有する売買システムも多い。価格調整に当たっては、販売希望数量と購入希望数量との需給関係によって妥当な価格を導出することが可能である。

ここで、商品が複製可能なデータである場合には、販売希望数量が定まらない場合が多い。物品の生産をせずに複製をすれば生産できるので、生産能力に起因する販売数量の制限がないためである。仮に販売希望数量を無限大（または十分に大きな数量）とすると、需給関係によって導出される価格は、商品の価値よりも小さなものとなってしまう。

特許文献１には、購入対象データについて、実際に発生した販売価格に基づいて価格を決定する価格決定システムが開示されている。購入者（需要側）の判断に基づいて価格を決定することとなり、商品としてのデータの価値を反映した価格とすることができる。

商品がコンピュータプログラムのソースコード（以下、単に「ソースコード」と言う。）である場合にも、特許文献１に開示された方法を使用することは可能である。しかしながら、ソースコードの商品自体の内的な要素や外部サービスなどの外的な要素を把握しておらず、商品としてのソースコードの価値を十分に反映した価格とすることはできていない。

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

本発明は、商品としてのソースコードの価値を反映した価格で売買の仲介を行うことのできるソースコード売買システムを提供することを課題とする。
そこで、本発明は、ソースコードの類似度に基づく売買利益の配分の仕組みや、外部ソースの情報を活用したダイナミックプライシング（変動価格）の仕組みを提供する。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。

本発明によれば、ソースコードの類似度に基づく売買利益の配分の仕組みや、外部ソースの情報を活用したダイナミックプライシング（変動価格）の仕組みを提供することができる。

ソースコード売買システムの構成例を示す図である。 価格決定データの例を示す図である。 価格決定部１５の計算の例を示すフローチャートの例である。 ソースコード売買システム１を含む全体システム４００の構成例である。 ソースコード売買システム１のハードウェア構成の例である。 ソースコード売買システム１を含む全体システム４００の接続関係の例である。 価格データ１８の構成例である。 類似度判定フロー８００の例である。 参照先配分率決定フロー９００の例である。 機能ブロックを用いた参照先配分率決定フロー１０００の例である。 価格決定フロー１１００の例である。 予想価格算出フロー１２００の例である。 分類器によるソースコードの分類フロー１３００の例である。 外部情報による価格調整フロー１４００の例である。 ニュースサイトの情報に基づく価格調整フロー１５００の例である。 外部情報による価格調整の実行頻度変更フロー１６００の例である。 Ｗｅｂ画面１７００の例である。 スマートフォン画面１８００の例である。

以下、本発明の実施例を説明する。

（システムの構成）
図１は、ソースコード売買システムの構成を示す図である。ソースコード売買システム１は、１又は２以上の販売者端末２１及び購入者端末２２と、ネットワークを介して接続されている。ソースコード売買システム１は、商品登録部１１を介して販売者端末２１から登録されたソースコードデータ１２を、売買仲介部１３を介して購入者端末２２のユーザにダウンロード販売する。なお、販売形式はダウンロード販売でなくともよい。

ソースコード売買システム１は、商品登録部１１、売買仲介部１３、価格決定部１５、類比判定部１６及びソースコード要望提示部１７を備え、ソースコードデータ１２及び価格決定データ１４を保持している。

商品登録部１１は、販売者端末２１から、販売を希望するソースコードに係る情報を受信する。販売を希望するソースコードをアップロードさせてソースコードデータ１２として格納し、後述する書誌事項１４ｄを受信して価格決定データ１４を更新する。

ソースコードデータ１２は、販売されるソースコードである。

売買仲介部１３は、購入者端末２２に販売されるソースコード及び価格を含む情報を表示し、購入者端末からの購入申込を受付け、ソースコードをダウンロードさせる。購入されると、後述する販売実績１４ｂについて価格決定データ１４を更新する。

売買仲介部１３は、また、各々のソースコードの詳細を表示するホームページへのリンクを備えている。リンクによって詳細が表示されると、後述する注目度１４ｃについて価格決定データ１４を更新する。

価格決定データ１４は、各々のソースコードの価格を決定するためのデータである。詳細は後述する。

価格決定部１５は、価格決定データ１４に基づいて各々のソースコードの価格を決定し、保持する。保持された価格は、売買仲介部１３によって用いられる。

類比判定部１６は、２のソースコードについて、その一方が他方を使用して作成されたと推認できるような類似度を計算し、類似度が十分に大きな場合には類似である（一方が他方を使用して作成された）と判断し、後述する類否情報１４ｅについて価格決定データ１４を更新する。

ここで、類似度を計算する手法は、いかなるものであってもよい。例えば、ソースコードを行単位に分割して同一内容の行の比率を求める、ソースコード中の変数名の一致度合いを求める、その他の方法を用いることができる。本発明では、類似であるか否かの判断をすることができれば十分である。

ソースコード要望提示部１７は、購入者端末２２からソースコード作成の要望（作成を希望するソースコードの機能等）を受け付け、受け付けた要望の一覧を購入者端末２２（複数の購入者端末２２があり、ソースコード作成の要望を入力した購入者端末２２以外の購入者端末２２をも含む）に表示する。表示に際してはそのソースコードの作成を自分も望むことを投票する手段（例えば「いいね」ボタン）を提供する。投票が行われると、後述する注目度１４ｃについて価格決定データ１４を更新する。

ソースコード要望提示部１７は、また、受け付けた要望の一覧を販売者端末２１にも表示する（ただし、ソースコード売買システム１がインターネットのホームページとして運用されるのであれば、同一の端末機が販売者端末２１にも購入者端末２２にもなり得るので、販売者端末２１に表示するための特別の仕組は要しない）。その際、投票数も合わせて表示するものとする。販売者は、作成の要望の多いソースコードに係る情報を得ることができ、開発を行うことができる。

図２は、価格決定データを示す図である。価格決定データ１４は、各々のソースコード（図中の１行）について、ソースコードＩＤ１４ａ、販売実績１４ｂ、注目度１４ｃ、書誌事項１４ｄ及び類否情報１４ｅを含んでいる。

ソースコードＩＤ１４ａは、各々のソースコードを一意に同定するためのＩＤである。

販売実績１４ｂは、販売数量及び販売価格を含むデータであり、発売開始からの累積の販売数量（累積数量）１４ｂ１１及び販売価格（累積価格）１４ｂ１２、並びに、事前に定めた最近の期間の販売数量（最近数量）１４ｂ２１及び販売価格（最近価格）１４ｂ２２を含む。ただし、累積数量１４ｂ１１及び累積価格１４ｂ１２、又は、最近数量１４ｂ２１及び最近価格１４ｂ２２の一方のみとしてもよい。

最近数量１４ｂ２１及び最近価格１４ｂ２２を求めるためには、売買仲介部１３から販売数量及び販売価格を販売時点と共に受領し、販売時点に基づいて所定の最近の期間のみについて積算することができる。又は、例えば１日毎の期間について最近数量１４ｂ２１及び最近価格１４ｂ２２を求めるのであれば、期間の開始時に最近数量１４ｂ２１及び最近価格１４ｂ２２の値を０とし、売買仲介部１３から受領する販売数量及び販売価格を積算してもよい。

注目度１４ｃは、各々のソースコードが注目されている（関心を持たれている）度合を示すデータであり、ソースコード要望提示部１７から受領する投票数１４ｃ１及び売買仲介部１３から受領するページビュー数１４ｃ２を含む。なお、投票数１４ｃ１及びページビュー数１４ｃ２についても、販売実績１４ｂと同様に累積、最近又はその両方とすることができる。

書誌事項１４ｄは、商品登録部１１から受領する書誌情報のデータであり、作成者１４ｄ１及び言語１４ｄ２を含む。

類否情報１４ｅは、類比判定部１６から受領する類似度のデータであり、使用ソースコード１４ｅ１及び使用率１４ｅ２を含む。図は、ソースコードＤが、そのうち７０％についてソースコードＡを用いて作成された場合のものである。

図３は、価格決定部の計算の例を示すフローチャートである。価格決定部１５は、１日につき一度起動され、各々のソースコードの価格を計算する。起動の間隔は、１日よりも長い間隔、例えば３日、１週間等としてもよい。

また、１日よりも短い間隔（例えば６時間）としてもよいが、最近数量１４ｂ２１及び最近価格１４ｂ２２を価格決定部１５の起動間隔に合わせると、昼間と夜間とで大きく変動する可能性がある。この点、世界各国からのソースコード購入を処理する場合には、変動が緩和されるので、１日よりも短い間隔として価格を頻繁に改定することが容易となる。

価格決定部１５は、ステップ１５ａにおいて、価格（Ｐ）にＲ０を乗じて減額する（０＜Ｒ０＜１）。その後、価格決定データ１４を読み込み、それに基づいて価格を調整する。価格決定データ１４に基づく調整で価格が上昇しない場合には、ソースコードの価格は時間の経過（価格決定部１５の動作回数）によって下落する。価格を上昇させる要因が発生すれば価格の低下が止まるので、時間経過による価格の低下と、単位時間当たりの価格上昇要因発生とが均衡する価格として、商品としてのソースコードの価値に合った価格に収束すると考えられる。

価格決定データ１４に基づく調整は、販売実績に基づく調整（ステップ１５ｂ）、注目度に基づく調整（ステップ１５ｃ）、書誌事項に基づく調整（ステップ１５ｄ）、及び類否情報に基づく調整（ステップ１５ｅ）が行われる。

販売実績に基づく調整（ステップ１５ｂ）は、販売実績１４ｂ（累積数量１４ｂ１１、累積価格１４ｂ１２、最近数量１４ｂ２１、最近価格１４ｂ２２）に基づいて価格を調整する。

例えば、累積数量１４ｂ１１について、その値ｂ１１から、基準値ｂ’１１を減算し、それに所定の比率Ｒｂ１１を乗算した値を価格Ｐに加算する。ｂ１１＞ｂ’１１であれば価格が上昇し、ｂ１１＜ｂ’１１であれば価格が下降する。（以下、価格データ１４に含まれる値について、価格データ１４において「１４」に続く符号で示し（例えば、ｂ１１は符号１４ｂ１１である累積数量の値を示す。）、それに係る比率を「Ｒ」の後のその符号をつけて示す。）

累積価格１４ｂ１２、最近数量１４ｂ２１、最近価格１４ｂ２２についても同様の計算を行う。これにより、販売実績１４ｂに基づく価格調整が行われる。なお、累積数量１４ｂ１１、累積価格１４ｂ１２、最近数量１４ｂ２１、最近価格１４ｂ２２のすべてについて価格調整を行わずにその一部について行ってもよい。例えば、最近数量１４ｂ２１、最近価格１４ｂ２２のみについて価格調整を行うこととしてもよい。最近の販売実績のみが反映され、需要の変化に対応するものとなる。

なお、Ｐ＝Ｐ＋（ｂ１１―ｂ’１１）×Ｒｂ１１との数式は、価格調整の行い方の一例であり、任意の数式として設計してよい。

以上、販売実績１４ｂ（累積数量１４ｂ１１、累積価格１４ｂ１１、最近数量１４ｂ２１、最近価格１４ｂ２２）に基づく価格調整を説明した。具体的にいかなる価格調整を行うかについては、一例であり、任意の設計としてよい。

注目度に基づく調整（ステップ１５ｃ）は、注目度１４ｃ（投票数１４ｃ１、ページビュー数１４ｃ２）に基づいて価格を調整する。数式は、販売実績に基づく調整（ステップ１５ｂ）と同様とした。

書誌事項に基づく調整（ステップ１５ｄ）は、書誌事項１４ｄ（作成者１４ｄ１、言語１４ｄ２）に基づいて価格を調整する。書誌事項１４ｄは数値ではないので、書誌事項１４ｄを数値に変換する関数ｆを用いる。

関数ｆの具体形は、設計事項として定めてよい。例えば、作成者１４ｄ１、言語１４ｄ２のそれぞれについて、その価値をソースコード売買システム１の運営者が定めて決定してもよい。また、同一の作成者１４ｄ１、同一の言語１４ｄ２である他のソースコードの販売実績１４ｂに基づいて計算してもよい。

類否情報に基づく調整（ステップ１５ｅ）は、類否情報１４e（使用ソースコード１４ｅ１、使用率１４e２）に基づいて価格を調整する。各々のソースコードについて、そのソースコードを使用する他のソースコード（使用ソースコード１４ｅ１）が存在する場合、使用する他のソースコードの価格Ｐ（ｅ１）の使用率e２を乗算した値が、そのソースコードの価値を推定する根拠となる。これに、所定の比率Ｒｅを乗算した値を価格Ｐに加算する。なお、Σは、使用する他のソースコードが複数ある場合に、全ての使用する他のソースコードについて加算する。

なお、Ｐ＝Ｐ＋（Σ（Ｐ（ｅ１）・ｅ２）×Ｒｅとの数式は、価格調整の行い方の一例であり、任意の数式として設計してよい。

以上詳細に説明したように、本実施例のソースコード売買システム１は、価格決定データ１４に基づいて価格を決定する価格決定部１５を備える。価格決定データ１４として、販売実績１４ｂ、注目度１４ｃ、書誌事項１４ｄ、類否情報１４ｅを用いることで、ソースコードの価値を反映した価格とすることができる。

なお、ソースコードの価値をより正確に反映した価格とするため、価格決定データ１４に他の情報をさらに保持し、価格決定部１５において処理してもよい。他の情報としては、ソースコードの詳細を表示するホームページの「お気に入り」の登録数、ソースコードについて評価を求めた場合の評価値、クレームの数、その他を用いることができる。

本実施例では、ソースコードの類似度に基づき売上利益の配分を行う構成の例を説明する。
図４は、ソースコード売買システム１を含む全体システム４００の構成例である。
全体システム４００は、複数のソースコード販売者端末２１と複数のソースコード購入者端末２２と複数の外部サービスサーバ２３とソースコード売買システム１を有し、それぞれの端末やサーバがネットワークを介してソースコード売買システム１に接続されている。なお、ネットワークは有線、無線を問わない。
販売者端末２１は、例えばソフトウェア開発会社、システム構築会社、大学等教育機関、個人プログラマー等が使用するコンピュータやタブレットなどの端末であり、自らが作成したソフトウェアもしくは他のソフトウェアを改良したソフトウェア等のソースコードを提供及び販売する。

購入者端末２２は、例えばソフトウェア開発会社、システム構築会社、大学等教育機関、個人プログラマー等が使用するコンピュータやタブレットなどの端末であり、販売されるソフトウェアのソースコードを購入する。
ソースコード売買システム１は、販売者端末２１と購入者端末２２間をつなぎ、適切な価格でソースコードを販売する仲介を行う。
外部サービスサーバ２３は、例えば本ソースコード売買システム１と同様にソースコードを売買するコード売買サイトや、検索エンジンサイトや、ニュースや株価を提供するニュースサイト等である。ソースコード売買システム１は、これらの外部サービスサーバ２３から、ソースコードに関する販売価格情報や、ソースコードに関連したニュースの記事情報や株価情報などの外部情報を取得する。

全体システム４００のそれぞれの端末やソースコード売買システム１は、例えば、スマートフォン、タブレット、携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末でもよいし、メガネ型や腕時計型、着衣型などのウェアラブル端末でもよい。また、据置型または携帯型のコンピュータや、クラウドやネットワーク上に配置されるサーバでもよい。あるいは、これらの複数の端末の組合せであってもよい。例えば、１台のスマートフォンと１台のウェアラブル端末との組合せが論理的に一つの端末として機能し得る。またこれら以外の情報処理端末であってもよい。

全体システム４００のそれぞれの端末やソースコード売買システム１は、それぞれオペレーティングシステムやアプリケーション、プログラムなどを実行するプロセッサと、ＲＡＭ（Random Access Memory）等の主記憶装置と、ＩＣカードやハードディスクドライブ、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置と、ネットワークカードや無線通信モジュール、モバイル通信モジュール等の通信制御部と、タッチパネルやキーボード、マウス、音声入力、カメラ部の撮像による動き検知による入力などの入力装置と、モニタやディスプレイ等の出力装置とを備える。なお、出力装置は、外部のモニタやディスプレイ、プリンタ、機器などに、出力するための情報を送信する装置や端子であってもよい。

主記憶装置には、各種プログラムやアプリケーションなど（モジュール）が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで全体システムの各機能要素が実現される。なお、これらの各モジュールは集積化する等によりハードウェアで実装してもよい。また、各モジュールはそれぞれ独立したプログラムやアプリケーションでもよいが、１つの統合プログラムやアプリケーションの中の一部のサブプログラムや関数などの形で実装されていてもよい。本明細書では、各モジュールを各「処理部」という呼び方をする。

本明細書では、各モジュール（各処理部）が、処理を行う主体（主語）として記載をしているが、実際には各種プログラムやアプリケーションなど（モジュール）を処理するプロセッサが処理を実行する。
補助記憶装置には、各種データベース（ＤＢ）が記憶されている。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システムでもよいし、表計算ソフトウェアでもよいし、ＸＭＬなどのテキストファイルでもよい。

図５は、ソースコード売買システム１のハードウェア構成の例である。
ソースコード売買システム１は、例えばクラウド上に配置されたサーバで構成される。
主記憶装置５０１には、商品登録部１１、売買仲介部１３、価格決定部１５、類否判定部１６、ソースコード要望提示部１７、外部情報取得部３１、価格調整部３２等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ５０３が実行することでソースコード売買システム１の各機能要素が実現される。

価格決定部１５は、販売実績やソースコードの書誌情報（例えば作成者、プログラム言語、評価等、ソースコードのカテゴリ）に基づいてソースコードの販売価格を変動させ、決定する。
また、本実施例ではさらに、新たにソースコードが登録される場合に、すでに登録されているソースコードの情報に基づいて機械学習による分析を行うことで、ソースコードの販売予想価格を算出し、販売価格を決定する。
類否判定部１６は、ソースコード同士の類似度を文字列の差分検出アルゴリズム等に基づき算出する。

外部情報取得部３１は、定期的にもしくは任意のタイミングで、ソースコードを売買するコード売買サイトや、検索エンジンサイトや、ニュースや株価を提供するニュースサイト等の外部サービスサーバ２３から、ソースコードに関する販売価格情報や、ソースコードに関連したニュースの記事情報や株価情報などの外部情報を取得する。
価格調整部３２は、価格決定部１５で決定された価格を外部情報に基づき定期的にもしくは任意のタイミングで更新する。

補助記憶装置５０２は、ソースコードデータ１２、価格決定データ１４及び価格データ１８を備える。
ソースコードデータ１２は、販売者端末２１から送信されたソースコードを登録、記憶する。
価格決定データ１４は、価格決定部１５が価格決定を行うための基礎となる情報を登録しており、例えば図２に示すような情報を記憶する。また、外部情報取得部３１により取得された外部情報が、処理、整形されて記憶されている。
価格データ１８は、販売者が希望する希望価格や、価格決定部１５が出した予想価格、価格調整部３２により調整された最終価格、類似度に基づく参照先ソースコードへの配分率等の価格に関する情報を記憶する。

図６は、ソースコード売買システム１を含む全体システム４００の接続関係の例である。実施例１との差分についてのみ説明する。
外部情報取得部３１は、外部サービスサーバ２３とネットワークを介して接続しており、各種外部情報を取得する。外部情報取得部３１は取得した情報を処理、整形、評価等することにより、価格決定部１５及び価格調整部３２が処理できる形の情報にして、価格決定データ１４に記憶する。
価格調整部３２は、価格決定データ１４に記憶された外部情報に基づく情報に従って、価格決定データ１４に基づいて価格決定部１５が決定した価格を、定期的にもしくは任意のタイミングで調整する。

図７は、価格データ１８の構成例である。
価格データ１８は、ＩＤ７０１、プロダクトＩＤ７０２、希望価格７０３、予想価格７０４、最終価格７０５、アルゴリズムタイプ７０６、参照先７０７、売上配分率７０８、参照先配分率７０９、更新日時７１０を有する。
ＩＤ７０１、はソースコードに対する価格を決定する際にシーケンシャルに生成される情報である。
プロダクトＩＤは実際のソースコードを含む「商品」を特定する情報であり、図示しないプロダクト情報のプロダクトＩＤを参照する。プロダクト情報には、ソースコードと対応付けて商品に関する情報が記載されており、例えばユーザＩＤ、ユーザ名、ステータス、価格履歴、プロダクト詳細、デザイン詳細、使用方法、限定事項、プロダクトイメージ、プレビューＵＲＬ、プロダクトビデオＵＲＬ、ユーザガイド、初期価格（希望価格）等の情報が記憶されている。

希望価格７０３は、販売者が希望する販売価格を記録する。
予想価格７０４は、販売実績やソースコードの書誌情報（例えば作成者、プログラム言語、評価、カテゴリ等）に基づくソースコードの予測販売価格や、すでに登録されている他のソースコードの情報に基づいて機械学習による分析を行い算出された予想販売価格を記憶する。
最終価格７０５は、希望価格７０３や予想価格７０４や、外部情報による調整に基づき算出された最終的な価格である。
アルゴリズムタイプ７０６はどのアルゴリズムに基づいて最終的な価格が決定されたのかを示す。autoは、販売実績やソースコードの書誌情報（例えば作成者、プログラム言語、評価、カテゴリ等）に基づくソースコードの予測販売価格や、すでに登録されている他のソースコードの情報に基づいて機械学習による分析を行い算出されたことを示す。

newsはニュースサイトから取得した情報に基づいて算出されたことを示す。codeは、他のソースコード売買サイトの価格情報に基づいて算出されたことを示す。searchは検索サイトから取得した情報に基づいて算出されたことを示す。
参照先７０７は、ソースコードが他のソースコードをコピーして、もしくは他のコードから改変して作成されている場合に、その他のソースコードを参照する情報である。プロダクト情報のプロダクトＩＤを参照する。

売上配分率７０８は、そのソースコードを販売した後に販売者に支払われる売り上げの配分率を規定する。ここでは割合で出しているが、販売に対する所定の経費や手数料を差し引いた後の金額を分配することとしてもよい。特定の方法で売上金を分配できる方法が記載されていればよい。
参照先配分率７０９は、他のソースコードを参照している場合に、その参照先のソースコードの販売者に対しても売り上げの一部を分配するための配分率を規定する。例えばソースコードのうちの３０％を他のソースコードから流用している場合には、売り上げの３０％を他のソースコードの販売者に配分する。
更新日時７１０は、情報が更新された日時を記憶する。

図８は、類似度判定フロー８００の例である。
類否判定部１６は、ソースコードデータ１２から取得したソースコードのプログラム言語を判別する（８１０）。書誌情報（書誌事項）１４ｄの言語１４ｄ２に基づいて判別してもよいし、ソースコードの構文を解析することにより判別してもよい。
類否判定部１６は、判別したプログラム言語と同一のプログラム言語により記述された他のソースコードをソースコードデータ１２から取得する（８２０）。なお、あらかじめ書誌情報に登録されているソースコードのカテゴリに従い、新規のソースコードと同一又は関連するカテゴリの中のみを検索することで検索効率を上げてもよい。
類否判定部１６は、それらの類似度を文字列の差分検出アルゴリズムにより算出し（８３０）、これを出力・表示する（８４０）。
差分検出アルゴリズムとしては、レーベンシュタイン距離を用いて文字列間の距離を判別する方法や、Ｍｙｅｒｓ差分アルゴリズム（Myers Diff algorithm）を用いる方法などがある。

図９は、参照先配分率決定フロー９００の例である。
商品登録部１１は、新規ソースコードの登録を受け付ける（９１０）。
類否判定部１６は、新規ソースコードが過去にソースコードデータ１２に記憶されているソースコードと類似しているかどうか類似度を算出する（９２０）。
類否判定部１６は、類似している他のソースコードが存在する場合には、新規ソースコードにしめる他のソースコードに類似している部分の割合（類似部分の割合）を参照先配分率とする。例えば、新規ソースコードのうちの３０％が他のソースコードに類似している場合には、３０％を参照先配分率とする（９４０）。

次に、類否判定部１６は新規ソースコードの中に、類似していると判断された他のソースコードへの参照が記載されているかどうかを判別する（９５０）。
参照が記載されている場合には、他のソースコードに依拠した旨を正当に開示したインセンティブとして、新規ソースコードに対する配分率を上げる。すなわち参照先配分率を例えば２％下げる（９６０）。

類似判定９３０において類似するソードコードが存在しない場合には、類否判定部１６は、新規ソースコードの配分率を１００％にする。すなわち、参照先配分率を０％とする（９７０）。
類否判定部１６は、参照先配分率を価格データ１８の参照先配分率７０９に記憶する（９８０）。
なお、参照記載へのインセンティブとして、配分率を調整することとしたが、このステップ９５０、９６０は設けない構成としてもよい。
また、インセンティブのつけ方として、参照先の配分率を下げ、新規ソースコードの配分率を上げる構成としたが、その代わりに、もしくはそれと並行して、売り上げに対する売上配分率７０８を上げることによりインセンティブをつける、という構成にしてもよい。

図１０は、機能ブロックを用いた参照先配分率決定フロー１０００の例である。
商品登録部１１は、新規ソースコードの登録を受け付ける（１０１０）。
類否判定部１６は、新規ソースコードを機能ブロックごとに分解する（１０２０）。ソースコードは通常いくつかの機能ごとに仕様が分かれている。例えばＥＣサイトのソースコードであれば、顧客管理機能、決済機能、商品管理機能、販売インタフェース生成機能、受発注管理機能などである。ゲームのソースコードであれば、ログイン管理機能、ユーザ入力処理機能、画面生成機能、出力管理機能、３Ｄモデル処理機能などである。
それぞれのソースコードのカテゴリごとに、ソースコードの内容は異なっていても、機能としては同様のものを持っていることが多い。例えばＥＣサイトであれば、デザインや商品の管理方法などは異なっていても、どのＥＣサイトのソースコードであっても大抵は上記の各種機能を持ち合わせている。

ソースコードのカテゴリ（ジャンル）は、大分類として、管理系、Ｗｅｂ系、バッチ処理系、組み込み系、音声映像処理系、データ処理系、ゲーム系等に分けることができ、それぞれの大分類は中で中分類や小分類に分けることができる。例えばＷｅｂ系の中の中分類としては、Ｗｅｂサイト構築ソフト、ＣＳＳデザイン、ＨＴＭＬデザイン、ＪａｖａＳｃｒｉｐｔ（登録商標）処理、ＥＣサイトなどに分類することができる。これらの情報は書誌情報に登録されている。
類否判定部１６は、書誌情報に基づき同一または関連するカテゴリごとにあらかじめ登録されている一般的な機能ブロックの構造の情報に基づいて、新規ソースコードを解析し機能ブロックごとにソースコードを分解する。ソースコードの中に記載されているコメント欄に記載された説明を検索・解析したり、よく使われる関数やモジュールを検索・解析したりすることで、ソースコードの機能の区切り部分を特定し、機能ブロックを分解することができる。
なお、登録のたびに人手によって機能の区切り部分を特定して機能ブロックを特定する構成としてもよい。

分解された各機能ブロックには、それぞれ重要度及びこれに基づく重み係数が設定されている。例えばＥＣサイトであれば商品管理機能や決済機能の重要度が「高」、顧客管理機能や販売インタフェースの生成機能の重要度は「中」等と設定されている。
類否判定部１６は、分解された機能ブロックごとに過去にソースコードデータ１２に記憶されているソースコードと類似しているか類似度を算出する（１０３０）。
類否判定部１６は、類似している他のソースコードが存在する場合には、機能ブロックごとに新規ソースコードにしめる他のソースコードに類似している部分の割合（類似部分の割合）を求め、これに各機能ブロックの重み係数を乗算し、すべてを合計することで参照先配分率を決定する（１０５０）。

例えば、あるソースコードがＡ、Ｂ、Ｃの３つの機能ブロックからなり、それぞれのソースコード中の重要度に基づく重み係数が２０％、５０％、３０％だとする。Ａ、Ｂ、Ｃがコピーしている他のソースコードの割合がそれぞれ、７０％、２０％、８０％だとする。この場合Ａ、Ｂ、Ｃの他のソースコードに対する依拠する度合いはそれぞれの数値を乗算し、１４％、１０％、２４％となる。
結果、このソースコードがトータルで他のソースコードに依拠する度合いは、これらの合計の４８％となり、この数値を参照先配分率とする。

次に、類否判定部１６は新規ソースコードの中に、類似していると判断された他のソースコードへの参照が記載されているかどうかを判別する（１０６０）。
参照が記載されている場合には、他のソースコードに依拠した旨を正当に開示したインセンティブとして、新規ソースコードに対する配分率を上げる。すなわち参照先配分率を例えば２％下げる（１０７０）。

類似判定１０４０において類似するソードコードが存在しない場合には、類否判定部１６は、新規ソースコードの配分率を１００％にする。すなわち、参照先配分率を０％とする（１０８０）。
類否判定部１６は、参照先配分率を価格データ１８の参照先配分率７０９に記憶する（１０９０）。

売買仲介部１３は、購入者端末２２からの注文を受け、ソースコードを販売した場合には、販売価格に対し価格データ１８の売上配分率７０８を乗算することで、売上分配利益を算出する。その後売買仲介部１３は、この売上分配利益を参照先配分率７０９に基づいて、売れたソースコードの販売者端末２１と参照先のソースコードの販売者端末２１との間で分配する。
本実施例では、このようにしてソースコードの類似度を用いて、参照先のソースコードにも売り上げを分配することができ、ソースコード販売者のインセンティブを高めることができる。

本実施例では、ソースコードの販売価格を決定・調整する方法を説明する。

図１１は、価格決定フロー１１００の例である。
価格決定部１５は、販売者端末２１が入力した希望価格７０３を価格データ１８から取得する（１１１０）。
価格決定部１５は、価格決定データ１４に記載された情報に基づいて、ソースコードの予想価格（予想販売価格）を算出する（１１２０）。
希望価格から予想価格が５０％以上ずれている場合には（１１３０）予想価格と希望価格の中間の値を最終価格とする（１１４０）。５０％以上のずれが無い場合には、希望価格を最終価格とする（１１５０）。

例えば、希望価格が１０００円で予想価格が２０００円であった場合には、最終価格は中間の１５００円となる。なお、予想価格と希望価格の中間の値ではなく、希望価格から予想価格と希望価格の差分の２５％の位置にしたり（先の例であれば最終価格１２５０円）、予想価格を最終価格としてもよい（最終価格２０００円）。いずれにしても、希望価格より予想価格が高い場合には、希望価格より高い額の最終価格が設定される。
なお、逆に希望価格よりも予想価格が低い場合には、同様に希望価格よりも低い額の最終価格を設定してもよいし、販売者端末２１の意向を尊重し、最終価格を希望価格として値段は下げない、という構成としてもよい。
価格を下げる場合には、例えば希望価格が１０００円で予想価格が６００円であった場合には、最終価格は中間の８００円となる。なお、予想価格と希望価格の中間の値ではなく、希望価格から予想価格と希望価格の差分の２５％の位置にしたり（先の例であれば最終価格９００円）、予想価格を最終価格としてもよい（最終価格６００円）。

また、現構成では、微修正が多数発生しないように、希望価格から予想価格が５０％以上ずれているときにのみ価格調整を行うフローだが、１１３０を設けず、少しでもずれていたら価格調整を行うという構成としてもよい。
この予想価格算出処理１１２０は比較的短期間（例えば一日１回）繰り返し算出され、最終価格が調整される。２回目以降の算出では、希望価格の代わりに、現在の最終価格が使用され、最終価格が順次更新されることとなる。

なお、ある期間内において外部サービスサーバにて公開された特定の言語の商品（ソースコード）の量が多い場合に、ソースコードの予想価格算出処理を実施することとしてもよい。
例えば、外部情報取得部３１が、ソースコード提供サイトから、商品（プロダクト）の一覧を取得する。自システムの特定のソースコードと同じプログラミング言語の商品のうち、ソースコード提供サイトに新たに投入された（更新された）商品に関連するものの割合が所定の値（例えば５％）を超えている場合に、予想価格算出処理を実行する。
例えばこの場合に、自システムのそのプログラミング言語に関連するすべての商品の予想価格算出を行う構成としてもよい。

この最終価格に対し、価格調整部３２が月に一度、外部情報に基づく価格調整を実行する（１１６０、１１７０）。なお、月に一度外部情報の取得を行ってもよいが、外部情報の取得は一日一度などより頻度高く実施しておいて、外部情報に基づく情報を逐次価格決定データ１４に記憶しておき、そのデータに基づいて月に一度価格調整を実行するという構成にしてもよい。
その結果修正された最終価格を、価格データ１８の最終価格７０５に記憶する（１１８０）。

図１２は、予想価格算出フロー１２００の例である。
商品登録部１１は、新規ソースコードの登録を受け付ける（１２１０）。
価格決定部１５は、ソースコードを処理できる形に整形し（１２２０）、マルチクラス分類器によるソースコードの分類を実行し、ソースコードを分類する（１２３０）。
価格決定部１５は、分類されたソースコードに対して機械学習による回帰分析を行うことで、ソースコードに対する予想価格を算出する（１２４０）。例えば、回帰分析の方法として勾配ブースティング回帰分析が用いられるが、これに限定されるものではなく他の価格算出アルゴリズムを用いてもよい。
価格決定部１５は、算出された予想価格に価格ポリシーを適用し（１２５０）、ポリシーに従った適切な価格になっているかどうかを確認する。
価格決定部１５は、算出された予想価格を価格データ１８に記憶する（１２６０）。

図１３は、分類器によるソースコードの分類フロー１３００の例である。
価格決定部１５は、トレーニングデータを取得（１３１０）。
価格決定部１５は、ソースコードのプログラム言語とカテゴリ（機能）などの書誌情報に基づいてクラス分けを行い、重複を排除することで、ソースコードの分類を行う（１３２０）。
価格決定部１５は、さらに分類されたソースコードに対応するプロダクト情報のプロダクト詳細に記載されたソースコードの詳細に対して、分類を実施し、関連用語を取得する（１３３０）。分類の方法としては例えば、Bag-of-words分類が利用できる。
価格決定部１５は、関連用語を用いてテキスト分類を実施する（１３４０）。分類としては例えば単純ベイズ分類が利用できる。例えば１３１０で取得したトレーニングデータと１３３０で取得した関連用語とに基づいて、データをトレーニングし、分類モデルを適用することで単純ベイズ分類を実行する。
価格決定部１５は、ベイズスコア等のテキスト分類スコアを出力する（１３５０）。
価格決定部１５は、得られたテキスト分類スコアに基づいて、ソースコードの分類を実施する。

図１４は、外部情報による価格調整フロー１４００の例である。
図１１で説明したように、価格決定部１５はソースコードの内容、売買情報又は書誌情報の少なくとも一つに基づいて、毎日１度など比較的短い頻度でソースコードの販売価格を算出する。一方価格調整部３２は、毎月１度など価格調整部３２の価格決定期間よりは長い頻度で価格決定部１５の決めた販売価格を外部サービスサーバ２３から取得された情報に基づいて調整する。
このようにして順次変動される（ダイナミックプライシング：Dynamic Pricing）変動価格（ダイナミックプライス：Dynamic Price）は売買仲介部１３により表示される。

価格調整部３２は、ソースコード提供サイトの販売価格に基づく調整に基づく価格の調整を実施する（１４１０）。
外部情報取得部３１が、ソースコード提供サイトの製品情報から、ソースコードを特定する情報及びこのソースコードの販売価格（ソースコード提供サイト価格）を取得する。例えば、ソースコード提供サイトの新製品発表のページにアクセスし、ここに順次掲載されるソースコードの詳細情報や販売価格情報をスクレイピングすることによって、それぞれのソースコードを特定する情報（例えばソースコード名や作成者、販売会社、型番、バージョン名、プログラム言語等の情報の一つ、またはいくつかの組み合わせ等ソースコードを特定できればよい）を取得し、整形した後に、価格決定データ１４の中に順次格納していく。
価格調整部３２は、ソースコード提供サイトに掲載されていたソースコードを特定する情報に対応する自システムが持つソースコードの情報を取得し、この販売価格をソースコード提供サイト価格に基づいて調整する。

価格調整部３２は、ソースコード提供サイト価格の方が現在の自システムの販売価格よりも高い場合には、自システムのソースコードの販売価格を高くする。例えば、ソースコード提供サイト価格と同価格に設定する。又はソースコード提供サイト価格と現在の販売価格との中間の価格に設定する。
例えば、ソースコード提供サイトに掲載されているＡというソースコードのソースコード提供サイト価格が２０００円で、ソースコード売買システム１の現在のＡに対応するソースコードの販売価格が１０００円であった場合、最終販売価格を中間の１５００円に調整する。

なお、ソースコード提供サイト価格と現在の販売価格の中間の値ではなく、現在の販売価格からソースコード提供サイト価格と現在の販売価格との間の差分の２５％の位置にしたり（先の例であれば最終販売価格１２５０円）、ソースコード提供サイト価格を販売価格としてもよい（最終販売価格２０００円）。
なお、逆に現在の価格よりもソースコード提供サイト価格が低い場合には、同様に販売価格よりも低い額の最終販売価格に下げてもよいし、販売者の意向を尊重し、最終販売価格を据え置き、現在の販売価格のままとする構成としてもよい。
価格を下げる場合には、例えばソースコード提供サイト価格が６００円で現在の販売価格が１０００円であった場合には、最終販売価格は中間の８００円となる。なお、ソースコード提供サイト価格と現在の販売価格の中間の値ではなく、ソースコード提供サイト価格からソースコード提供サイト価格と現在の販売価格の差分の２５％の位置にしたり（先の例であれば最終販売価格９００円）、ソースコード提供サイト価格を最終販売価格としてもよい（最終販売価格６００円）。

なお、価格差がある場合にすぐに価格調整を行うのではなく、ある期間内において外部サービスサーバにて公開された特定の言語の商品（ソースコード）の量が多い場合に、そのソースコードの価格調整を実施することとしてもよい。
例えば、外部情報取得部３１は、ソースコード提供サイトから、商品（プロダクト）の一覧を取得する。自システムのソースコードと同じプログラミング言語の商品のうち、ソースコード提供サイトに新たに投入された商品に関連するものの割合が所定の値（例えば５％）を超えている場合に、価格調整を実施する。
この場合に、この同じプログラミング言語の全商品の情報を取得し、分類及び価格算出の処理に利用してもよい。

次に価格調整部３２は、検索サイトにおける検索に基づく調整に基づく価格の調整を実施する（１４２０）。
価格決定データ１４は、ソースコードデータ１２に記憶されているソースコードに対応する複数の検索用語を記憶している。外部情報取得部３１は、検索サイトから、記憶されているソースコードに対応するソースコードに関する情報を検索用語に基づいて検索する。例えば、ソースコードのカテゴリやタグや詳細情報などに記載されるような情報が検索用語として記憶されている。
検索により、対応するソースコードを特定する情報及びこのソースコードの価格情報（検索サイト価格）を取得する。
前記価格調整部３２は、このソースコードを特定する情報に対応する自システムのソースコードの販売価格を、検索サイト価格に基づいて調整する。

例えば、価格調整部３２は、検索サイト価格の方が現在の販売価格よりも高い場合には、販売価格を高くする。例えば、販売価格を検索サイト価格と同価格に設定する。又は検索サイト価格と現在の販売価格との中間の価格に設定する。
例えば、検索により見つかったＢというソースコードの検索サイト価格が２０００円で、ソースコード売買システム１の現在のＢに対応するソースコードの販売価格が１０００円であった場合、最終販売価格を中間の１５００円に調整する。

なお、検索サイト価格と現在の販売価格の中間の値ではなく、現在の販売価格から検索サイト価格と現在の販売価格との間の差分の２５％の位置にしたり（先の例であれば最終販売価格１２５０円）、検索サイト価格を販売価格としてもよい（最終販売価格２０００円）。
なお、逆に現在の価格よりも検索サイト価格が低い場合には、同様に販売価格よりも低い額の最終販売価格に下げてもよいし、販売者の意向を尊重し、最終販売価格を据え置き、現在の販売価格のままとする構成としてもよい。
価格を下げる場合には、例えば検索サイト価格が６００円で現在の販売価格が１０００円であった場合には、最終販売価格は中間の８００円となる。なお、検索サイト価格と現在の販売価格の中間の値ではなく、検索サイト価格から検索サイト価格と現在の販売価格の差分の２５％の位置にしたり（先の例であれば最終販売価格９００円）、検索サイト価格を最終販売価格としてもよい（最終販売価格６００円）。
価格調整部３２は、ニュースサイトの情報に基づく価格の調整を実施する（１４３０）。詳細は図１５で説明する。

なお、ソースコード提供サイトの販売価格に基づく調整（１４２０）、検索サイトにおける検索に基づく調整（１４３０）、ニュースサイトの情報に基づく調整（１４３０）は、すべてを実施せず、このうちのいずれかを実施する構成としてもよい。また、それぞれの実施頻度やタイミングは別々であってもよい。
また、これらは１つの外部情報の取得に応じてすぐに価格を調整するのではなく、複数の外部情報を例えば１月分蓄積し、これらの情報を解析したうえで統合化や平均化等したうえで１月に１度実行すればよい。

図１５は、ニュースサイトの情報に基づく価格調整フロー１５００の例である。
価格決定データ１４は、ソースコードデータ１２に記憶されているソースコードに対応する複数の検索用語を記憶している。
外部情報取得部３１は、ニュースを配信するニュースサイトにアクセスし（１５１０）、ニュースサイトから、記憶されているソースコードに対応するソースコードを特定する情報（例えばソースコード名や作成者、販売会社、型番、バージョン名、プログラム言語等の情報の一つ、またはいくつかの組み合わせ等ソースコードを特定できればよい）及び関連する記事情報を取得する（１５２０、１５３０）。

例えば、ニュースサイトにアクセスし、所定の期間（例えば過去１ヵ月）の記事のタイトルと内容を取得し、この中から検索用語にヒットするものを抽出することでソースコードに対応する記事情報を取得する。他には、例えばソースコードの製造会社や販売会社の株価情報を取得することもできる。
外部情報取得部３１は、取得した記事情報の内容が肯定的か中立か否定的かを評価する（１５４０）。なお、この処理は価格調整部３２が実行してもよい。

価格調整部３２は、ニュースサイトに掲載されていたソースコードを特定する情報に対応する自システムのソースコードの現在の販売価格を、記事情報の内容の評価に基づいて調整する（１５５０）。
例えば、記事情報の内容の評価が肯定的である場合に販売価格を上げる。記事情報の内容が否定的である場合には販売価格を下げてもよいし、販売者の意向を尊重し現状価格を維持してもよい。

価格決定データ１４は、肯定的な内容を示す複数の記事用語（肯定的な記事用語）や、否定的な内容を示す複数の記事用語（否定的な記事用語）を記憶しており、外部情報取得部３１は、ニュースサイトから取得した記事情報に対して、肯定的な内容を示す記事用語が含まれているか、どれくらいの数含まれているかを解析し、記事情報の内容が肯定的かどうかを評価する。
例えば、外部情報取得部３１は、記事情報に含まれる肯定的な記事用語の数が所定の数や割合（例えば１０００語当たり１０個以上や１％）以上ある場合や、又は記事情報に含まれる肯定的な記事用語の数が否定的な内容を示す記事用語の数よりも多い場合に、記事情報の内容が肯定的であると評価する。

また、例えば記事情報が株価に関するものであれば、ソースコードの製造会社又は販売会社の株価が上昇している場合には肯定的な内容であると評価したり、株価が上昇する可能性が高いと投資家や金融機関等が評価している場合に肯定的な内容であると評価する。
価格調整部３２は、調査対象として価格決定データ１４に記憶されているすべてのニュースサイトに対して検索調査が終了した場合に処理を終了する（１５６０）。

図１６は、外部情報による価格調整の実行頻度変更フロー１６００の例である。
価格決定部１５はソースコードの内容、売買情報又は書誌情報の少なくとも一つに基づいて、毎日１度など比較的短い頻度でソースコードの販売価格を算出する。一方価格調整部３２は、毎月１度など価格調整部３２の価格決定期間よりは長い頻度で価格決定部１５の決めた販売価格を外部サービスサーバ２３から取得された情報に基づいて調整する。
これは、外部サーバから取得する外部情報が常に発生するわけではなく断片的であり、ある程度蓄積してから価格調整を行った方が価格の変動が安定するという理由と、外部情報の解析処理は計算機資源を消費する重い処理であり、高頻度で実施すると負荷が高いという理由によるものである。
しかしながら、特定のイベントが発生する場合には外部情報による価格調整をもっと高頻度で実施したほうが適切にソースコードの価格を反映できる場合がある。

外部情報取得部３１は、ソースコードを売買するコード売買サイトや、検索エンジンサイトや、ニュースや株価を提供するニュースサイト等の外部サービスサーバ２３から、ソースコードに関する販売価格情報や、ソースコードに関連したニュースの記事情報や株価情報などの外部情報を取得する（１６１０）。
外部情報取得部３１は、これらの外部情報からソースコードを特定する（１６２０）。

特定したソースコードに対する外部情報の新規掲載頻度が高頻度でない（例えば一日５回未満）の場合（１６３０）、外部情報による価格調整の実行頻度を現在の月一回のままとする（１６５０）。一方、外部情報の新規掲載頻度が高頻度（例えば一日５回以上）の場合（１６３０）、特定したソースコードに対する外部情報による価格調整の実行頻度を高くする（例えば週１回に上げる）（１６４０）。
このような構成にすることで、通常は計算機の価格調整負荷を月一程度におさえつつ、特定のソースコードに関する世の中の関心が上がってきた場合には、より高い頻度で価格を調整し、より世の中のニーズに近い販売価格を提示することができる。

他の方法としては、ある期間内において特定のソースコードの商品の量が多い場合に、そのソースコードの価格調整頻度を上げることが考えられる。
例えば、外部情報取得部３１は、外部サービスサーバ２３（例えばソースコード提供サイトや、検索サイト、ニュースサイト等）から、商品（プロダクト）の一覧を取得する。
外部情報取得部３１は、特定したソースコードと同じプログラミング言語の商品の全数における特定したソースコードに関する外部情報の数が、所定の値（例えば５％）を超えている場合に、価格調整の実行頻度を高くする、または、価格調整を実行する。

他の方法としては、ある期間内において特定のソースコードの価格の更新頻度（変動）が多い場合に、そのソースコードの価格調整頻度を上げることが考えられる。
例えば、外部情報取得部３１は、外部サービスサーバ２３（例えばソースコード提供サイトや、検索サイト、ニュースサイト等）から、商品（プロダクト）の一覧を取得する。
外部情報取得部３１は、特定したソースコードと同じまたは関連する外部サービスサーバのソースコードの価格の更新頻度（変動）が所定の値（例えば週に１回）を超えている場合に、価格調整の実行頻度を高くする。

図１７は、Ｗｅｂ画面１７００の例である。
売買仲介部１３は、購入者端末２２に対してソースコードを販売するためのＷｅｂ画面１７００を表示する。Ｗｅｂ画面１７００は、ソースコードのタイトル１７１０と、詳細情報１７４０と、プログラム言語や作成者、カテゴリやタブなどの書誌情報１７２０と、価格表示１７３０と、購入のためのカート追加ボタン１７５０とを有する。
図１１の価格決定フローに基づき毎日１度かそれ以上の頻度で価格の見直しが行われ、価格表示１７３０の価格が更新される。また月の最初に外部情報による価格調整が実施され、外部情報の内容や量に応じて、価格表示１７３０の価格が更新される。

図１８は、スマートフォン画面１８００の例である。
スマートフォン画面１８００は、ソースコードのタイトル１８１０と、書誌情報１８２０と、価格表示１８３０を有する。タイトル等をタップすることで、ソースコードの詳細情報を表示する画面に遷移する。
スマートフォン画面においても毎日１度かそれ以上の頻度で価格の見直しが行われ、価格表示１８３０の価格が更新される。また月の最初に外部情報による価格調整が実施され、外部上の内容や量に応じて、価格表示１８３０の価格が更新される。
なお、ソースコードが他のソースコードを一部使用している場合には、参照先コード７０７や参照先配分率７０９（又は参照先コードの使用率）を図１７や図１８に表示してもよい。
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
なお、上述の実施例は少なくとも以下に記載の構成を開示している。
（１）
ソフトウェアのソースコードを売買するためのソースコード売買システムであって、
ソースコードを記憶する記憶手段と、
前記ソースコードの内容、売買情報又は書誌情報の少なくとも一つに基づいて、前記ソースコードの第１の販売価格を算出する価格決定手段と、
前記ソースコード売買システムの外部にある外部サービスサーバから情報を取得する外部情報取得手段と、
前記第１の販売価格を、前記外部サービスサーバから取得した情報に基づいて調整し、第２の販売価格を算出する価格調整手段と、
算出された前記第２の販売価格を表示する売買仲介手段と、
を有する
ことを特徴とするソースコード売買システム。
（２）
（１）に記載のソースコード売買システムであって、
前記外部情報取得手段は、前記外部サービスサーバの一つであるソースコード提供サイトの製品情報から、第２のソースコードを特定する情報と前記第２のソースコードの販売価格を示すソースコード提供サイト価格に関する情報とを取得し、
前記価格調整手段は、前記第２のソースコードを特定する情報に対応する前記記憶手段に記憶された前記ソースコードの前記第１の販売価格を、前記ソースコード提供サイト価格に関する情報に基づいて調整することにより、前記第２の販売価格を算出する
ことを特徴とするソースコード売買システム。
（３）
（２）に記載のソースコード売買システムであって、
前記価格調整手段は、前記ソースコード提供サイト価格の方が前記第１の販売価格よりも高い場合に、前記第１の販売価格よりも高い前記第２の販売価格を設定する
ことを特徴とするソースコード売買システム。
（４）
（２）に記載のソースコード売買システムであって、
前記価格調整手段は、前記ソースコード提供サイト価格の方が前記第１の販売価格よりも高い場合に、前記第２の販売価格を、前記ソースコード提供サイト価格と同価格、又は前記ソースコード提供サイト価格と前記第１の販売価格との間の価格、のいずれかに設定する
ことを特徴とするソースコード売買システム。
（５）
（２）〜（４）のいずれか１項に記載のソースコード売買システムであって、
前記記憶手段に記憶されている特定のプログラミング言語のソースコードの数に対する、外部情報取得手段がソースコード提供サイトから取得した前記特定のプログラミング言語に関する更新されたソースコードの数が所定の割合を超えていた場合に、前記第１の販売価格の調整による前記第２の販売価格の算出を実行する
ことを特徴とするソースコード売買システム。
（６）
（１）〜（５）のいずれか１項に記載のソースコード売買システムであって、
前記記憶手段は、前記ソースコードに対応する複数の検索用語を記憶しており、
前記外部情報取得手段は、前記外部サービスサーバの一つである検索サイトから、前記複数の検索用語に基づいて検索された第３のソースコードを特定する情報と前記第３のソースコードに対応する価格を示す検索サイト価格に関する情報とを取得し、
前記価格調整手段は、前記第３のソースコードを特定する情報に対応する前記記憶手段に記憶された前記ソースコードの前記第１の販売価格を、前記検索サイト価格に関する情報に基づいて調整することにより、前記第２の販売価格を算出する
ことを特徴とするソースコード売買システム。
（７）
（６）に記載のソースコード売買システムであって、
前記価格調整手段は、前記検索サイト価格の方が前記第１の販売価格よりも高い場合に、前記第１の販売価格よりも高い前記第２の販売価格を設定する
ことを特徴とするソースコード売買システム。
（８）
（６）に記載のソースコード売買システムであって、
前記価格調整手段は、前記検索サイト価格の方が前記第１の販売価格よりも高い場合に、前記第２の販売価格を、前記検索サイト価格と同価格、又は前記検索サイト価格と前記第１の販売価格との間の価格、のいずれかに設定する
ことを特徴とするソースコード売買システム。
（９）
（１）〜（８）のいずれか１項に記載のソースコード売買システムであって、
前記記憶手段は、前記ソースコードに対応する第２の複数の検索用語を記憶しており、
前記外部情報取得手段は、前記外部サービスサーバの一つでありニュースを配信するニュースサイトから、前記第２の複数の検索用語に基づいて検索された第４のソースコードを特定する情報と記事情報とを取得し、前記記事情報の内容が肯定的かどうかを評価し、
前記価格調整手段は、前記第４のソースコードを特定する情報に対応する前記記憶手段に記憶された前記ソースコードの前記第１の販売価格を、前記記事情報の内容の評価に基づいて調整することにより、前記第２の販売価格を算出する
ことを特徴とするソースコード売買システム。
（１０）
（９）に記載のソースコード売買システムであって、
前記記事情報の内容の評価が肯定的である場合に、前記第１の販売価格よりも高い前記第２の販売価格を設定する
ことを特徴とするソースコード売買システム。
（１１）
（９）又は（１０）に記載のソースコード売買システムであって、
前記記憶手段は、肯定的な内容を示す複数の記事用語を記憶しており、
前記外部情報取得手段は、前記記事情報に含まれる前記記事用語に基づいて前記記事情報の内容が肯定的であることを評価する
ことを特徴とするソースコード売買システム。
（１２）
（１１）に記載のソースコード売買システムであって、
前記外部情報取得手段は、前記記事情報に含まれる前記記事用語の数が、前記記事情報に含まれる否定的な内容を示す複数の記事用語の数よりも多い場合に、前記記事情報の内容が肯定的であると評価する
ことを特徴とするソースコード売買システム。
（１３）
（９）〜（１２）のいずれか１項に記載のソースコード売買システムであって、
前記外部情報取得手段は、前記第４のソースコードを特定する情報に関する前記記事情報の配信頻度が所定の値を超えている場合に、前記価格調整手段による前記第２の販売価格の算出の頻度を高める
ことを特徴とするソースコード売買システム。
（１４）
（１）〜（１３）のいずれか１項に記載のソースコード売買システムであって、
ソースコードの類似度を判定する類否判定手段を有し、
前記類否判定手段は、前記記憶手段に記憶される新たなソースコードに類似する類似ソースコードが前記記憶手段に記憶されている場合に、前記新たなソースコードに対する前記類似ソースコードの使用割合を算出し、
前記価格決定手段は、前記使用割合に基づいて前記新たなソースコードの売上代金の分配割合を決定する
ことを特徴とするソースコード売買システム。
（１５）
（１４）に記載のソースコード売買システムであって、
前記類否判定手段は、前記新たなソースコードを複数の機能ブロックに分割し、それぞれの機能ブロックごとに前記記憶手段に記憶されているソースコードとの類似度を判定する
ことを特徴とするソースコード売買システム。
（１６）
（１５）に記載のソースコード売買システムであって、
前記類否判定手段は、前記新たなソースコードの前記機能ブロックごとの重要度を算出し、
前記価格決定手段は、前記機能ブロックごとの類似度と前記機能ブロックごとの重要度とに基づいて、前記新たなソースコードの売上代金の分配割合を決定する
ことを特徴とするソースコード売買システム。
（１７）
（１４）〜（１６）のいずれか１項に記載のソースコード売買システムであって、
前記価格決定手段は、前記新たなソースコードに類似する前記類似ソースコードが前記記憶手段に記憶されている場合であって、前記類似ソースコードへの参照情報が前記新たなソースコードに記載されている場合には、前記新たなソースコードに対する売上代金の分配割合を増加させる
ことを特徴とするソースコード売買システム。
（１８）
（１）〜（１７）のいずれか１項に記載のソースコード売買システムであって、
前記価格決定手段は、前記ソースコードの前記内容に対し、マルチクラス分類器を用いてカテゴリの分類を行い、当該分類されたソースコードに対して回帰分析を行うことで、前記第１の販売価格を算出する
ことを特徴とするソースコード売買システム。
（１９）
（１８）に記載のソースコード売買システムであって、
前記マルチクラス分類器は、単純ベイズ分類器又はＢａｇ−ｏｆ−ｗｏｒｄｓ分類器の少なくとも一つである
ことを特徴とするソースコード売買システム。
（２０）
（１８）又は（１９）に記載のソースコード売買システムであって、
前記回帰分析は、勾配ブースティング回帰分析である
ことを特徴とするソースコード売買システム。
（２１）
ソースコード売買システムにおけるソフトウェアのソースコードの販売方法であって
販売するソースコードを記憶し、
前記ソースコードの内容、売買情報又は書誌情報の少なくとも一つに基づいて、前記ソースコードの第１の販売価格を算出し、
前記第１の販売価格を、前記ソースコード売買システムの外部にある前記外部サービスサーバから取得した情報に基づいて調整し、第２の販売価格を算出し、
算出された前記第２の販売価格を表示する
ことを特徴とするソースコードの販売方法。
（２２）
（２１）に記載のソースコードの販売方法であって、
前記外部サービスサーバの一つであるソースコード提供サイトの製品情報から、第２のソースコードを特定する情報と前記第２のソースコードの販売価格を示すソースコード提供サイト価格に関する情報とを取得し、
前記第２のソースコードを特定する情報に対応する記憶手段に記憶された前記ソースコードの前記第１の販売価格を、前記ソースコード提供サイト価格に関する情報に基づいて調整することにより、前記第２の販売価格を算出する
ことを特徴とするソースコードの販売方法。
（２３）
（２１）又は（２２）に記載のソースコードの販売方法であって、
記憶手段は、前記ソースコードに対応する複数の検索用語を記憶しており、
前記外部サービスサーバの一つである検索サイトから、前記検索用語に基づいて検索された第３のソースコードを特定する情報と前記第３のソースコードに対応する価格を示す検索サイト価格に関する情報とを取得し、
前記第３のソースコードを特定する情報に対応する前記記憶手段に記憶された前記ソースコードの前記第１の販売価格を、検索サイト価格に関する情報に基づいて調整することにより、前記第２の販売価格を算出する
ことを特徴とするソースコードの販売方法。
（２４）
（２１）〜（２３）のいずれか１項に記載のソースコード販売方法であって、
記憶手段は、前記ソースコードに対応する第２の複数の検索用語を記憶しており、
前記外部サービスサーバの一つでありニュースを配信するニュースサイトから、前記第２の検索用語に基づいて検索された第４のソースコードを特定する情報と記事情報とを取得し、前記記事情報の内容が肯定的かどうかを評価し、
前記第４のソースコードを特定する情報に対応する前記記憶手段に記憶された前記ソースコードの前記第１の販売価格を、前記記事情報の内容の評価に基づいて調整することにより、前記第２の販売価格を算出する
ことを特徴とするソースコードの販売方法。
（２５）
（２１）〜（２４）のいずれか１項に記載のソースコード販売方法であって、
前記記憶手段に記憶される新たなソースコードに類似する類似ソースコードが前記記憶手段に記憶されている場合に、前記新たなソースコードに対する前記類似ソースコードの使用割合を算出し、
前記使用割合に基づいて前記新たなソースコードの売上代金の分配割合を決定する
ことを特徴とするソースコードの販売方法。
（２６）
（２５）に記載のソースコード販売方法であって、
前記新たなソースコードに類似する前記類似ソースコードが前記記憶手段に記憶されている場合であって、前記類似ソースコードへの参照情報が前記新たなソースコードに記載されている場合には、前記新たなソースコードに対する売上代金の分配割合を増加させる
ことを特徴とするソースコードの販売方法。
（２７）
（２１）〜（２６）のいずれか１項に記載のソースコード販売方法であって、
前記ソースコードの前記内容に対し、マルチクラス分類器を用いてカテゴリの分類を行い、当該分類されたソースコードに対して回帰分析を行うことで、前記第１の販売価格を算出する
ことを特徴とするソースコードの販売方法。

１…ソースコード売買システム、１１…商品登録部、１２…ソースコードデータ、１３…売買仲介部、１４…価格決定データ、１５…価格決定部、１６…類否判定部、１７…ソースコード要望提示部、２１…販売者端末、２２…購入者端末、２３…外部サービスサーバ、３１…外部情報取得部、３２…価格調整部

Claims (11)

1. ソフトウェアのソースコードを売買するためのソースコード売買システムであって、
   前記ソースコードに対応する複数の検索用語を記憶する記憶手段と、
   前記ソースコードの内容、売買情報又は書誌情報の少なくとも１つに基づいて、前記ソースコードの第１の販売価格を算出する価格決定手段と、
   前記ソースコード売買システムの外部にあるニュースを配信するニュースサイトから前記検索用語に基づいて検索された第２のソースコードを特定する情報と記事情報とを取得する外部情報取得手段と、
   前記第２のソースコードを特定する情報に対応する前記ソースコードの前記第１の販売価格を、前記ニュースサイトから取得した前記記事情報の内容が肯定的かどうかの評価に基づいて調整することにより、第２の販売価格を算出する価格調整手段と、
   算出された前記第２の販売価格を表示する売買仲介手段と、
   を有する
   ことを特徴とするソースコード売買システム。
2. 請求項１に記載のソースコード売買システムであって、
   前記記事情報の内容の評価が肯定的である場合に、前記第１の販売価格よりも高い前記第２の販売価格を設定する
   ことを特徴とするソースコード売買システム。
3. 請求項１又は２に記載のソースコード売買システムであって、
   前記記憶手段は、複数の肯定的な内容を示す記事用語を記憶しており、
   前記外部情報取得手段は、前記記事情報に含まれる前記肯定的な内容を示す記事用語に基づいて前記記事情報の内容が肯定的であることを評価する
   ことを特徴とするソースコード売買システム。
4. 請求項３に記載のソースコード売買システムであって、
   前記外部情報取得手段は、前記記事情報に含まれる前記肯定的な内容を示す記事用語の数が、前記記事情報に含まれる否定的な内容を示す記事用語の数よりも多い場合に、前記記事情報の内容が肯定的であると評価する
   ことを特徴とするソースコード売買システム。
5. 請求項１〜４のいずれか１項に記載のソースコード売買システムであって、
   前記外部情報取得手段は、前記第２のソースコードを特定する情報に関する前記記事情報の配信頻度が所定の値を超えている場合に、前記価格調整手段による前記第２の販売価格の算出の頻度を高める
   ことを特徴とするソースコード売買システム。
6. ソースコード売買システムにおけるソフトウェアのソースコードの販売方法であって
   前記ソースコードに対応する複数の検索用語を記憶しており、
   前記ソースコードの内容、売買情報又は書誌情報の少なくとも１つに基づいて、前記ソースコードの第１の販売価格を算出し、
   前記ソースコード売買システムの外部にあるニュースを配信するニュースサイトから、前記検索用語に基づいて検索された第２のソースコードを特定する情報と記事情報とを取得し、前記記事情報の内容が肯定的かどうかを評価し、
   前記第２のソースコードを特定する情報に対応する前記ソースコードの前記第１の販売価格を、前記ニュースサイトから取得した前記記事情報の内容が肯定的かどうかの評価に基づいて調整することにより、第２の販売価格を算出し、
   算出された前記第２の販売価格を表示する
   ことを特徴とするソースコードの販売方法。
7. 請求項６に記載のソースコードの販売方法であって、
   前記記事情報の内容の評価が肯定的である場合に、前記第１の販売価格よりも高い前記第２の販売価格を設定する
   ことを特徴とするソースコードの販売方法。
8. 請求項６又は７に記載のソースコードの販売方法であって、
   複数の肯定的な内容を示す記事用語を記憶しており、
   前記記事情報に含まれる前記肯定的な内容を示す記事用語に基づいて前記記事情報の内容が肯定的であることを評価する
   ことを特徴とするソースコードの販売方法。
9. 請求項８に記載のソースコードの販売方法であって、
   前記記事情報に含まれる前記肯定的な内容を示す記事用語の数が、前記記事情報に含まれる否定的な内容を示す記事用語の数よりも多い場合に、前記記事情報の内容が肯定的であると評価する
   ことを特徴とするソースコードの販売方法。
10. 請求項６〜９のいずれか１項に記載のソースコードの販売方法であって、
    前記第２のソースコードを特定する情報に関する前記記事情報の配信頻度が所定の値を超えている場合に、前記第２の販売価格の算出の頻度を高める
    ことを特徴とするソースコードの販売方法。
11. ソフトウェアのソースコードを販売するソースコード売買システムに、請求項６〜１０のいずれか１項に記載のソースコードの販売方法の各ステップを実現させるプログラム。

Images