JP6599684B2 - リソース割り当てシステム - Google Patents

Description

本発明は、需要に対してリソースを割り当てる際の技術に関し、特に、利用期限が限定されている有限のリソースを割り当てるリソース割り当てシステムに適用して有効な技術に関するものである。

例えば、新幹線などの交通機関における指定席やコンサートのチケットなどのように、数が有限であるとともに利用期限が限定され、その期限を過ぎて売れ残ったものについては価値が無くなってしまうような商品やサービス等（以下では「リソース」と記載する場合がある）の場合、販売側としては、売れ残るよりは大幅に値下げしてでも期限までに売り切った方が有効である。しかしながら、恒常的な値引き販売は、通常料金で購入する顧客を減少させ、価格体系の破壊を招くことになり得る。

これに対し、既存の料金体系を破壊することなく売れ残っているリソース（以下では「在庫」と記載する場合がある）の販売を促進する手法が検討されている。

例えば、航空券の販売を行う「GetGoing」というサービス（非特許文献１および特許文献１を参照）では、ユーザは、指定した「出発地」、「行き先エリアまたは旅のテーマ」、「旅行日程」、「人数」の条件に対して抽出された複数の候補地から価格情報を参照しながら行き先候補を２ヶ所に絞り込み、それぞれ希望の時間帯に合ったフライトを選択して予約する。このとき、最終的な行き先の決定はユーザではなくシステムがランダムに行う。すなわち、ユーザは、最終的な行き先の決定をシステムに委ねるのと引き換えに大幅なディスカウントを得ることができる。これにより、通常料金で購入する顧客を害することなく、「どこかに行きたい」というユーザを対象に在庫の販売促進を図ることができる。

国際公開第２０１３／０５９６８８号

"コインを投げる要領で行き先を決める？航空券予約ECサイト「GetGoing」が提供する、旅行の新しい価値観"、［online］、２０１３年６年３日、［平成２７年７月２４日検索］、インターネット＜URL：http://cart.st/corp/blog/2013/06/ecgetgoing/＞

上述したような従来技術を利用することで、航空券に係る在庫の販売を促進することができるが、従来技術では、ユーザには２ヶ所にまで希望の候補地を絞り込める余地が残されているため、販売者が希望する候補地（在庫が多く残るであろう候補地）が選択されない可能性も高い。多数の候補地の中からシステムが最終的な行き先を決定するというようにした場合でも同様であり、販売者側としてできるだけ在庫を売りたい候補地が選択されないという場合が生じやすい。

販売者側としては在庫が多く残るであろう候補地が選択されやすい仕組みとするのが望ましいが、何をもって「在庫が多い」とするかについても一義的ではない。例えば、ユーザが旅行を行う際の航空便や新幹線などの交通機関のように、片道ではなく往復での在庫が販売の対象となる場合、すなわち、複数種類のリソースを組み合わせて割り当てるような場合には、往路便と復路便等、複数種類のリソースの在庫数をそれぞれ考慮した上で効率的な在庫の割り当てを行える必要がある。

そこで本発明の目的は、複数種類のリソースの組み合わせとその割り当ての決定をシステムが行う仕組みにおいて、各組み合わせに係るリソース毎の在庫数を考慮した上で、ユーザ、割り当て者双方にとって効果的・効率的な在庫の割り当てを可能とするリソース割り当てシステムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるリソース割り当てシステムは、複数種類のリソースの組み合わせをユーザに割り当てるリソース割り当てシステムであって、リソースの在庫を保持する在庫記録部と、情報処理端末を介したユーザからのリソースの割り当てに係る条件の入力を受け付けて、前記条件に合致する各種類のリソース候補の情報を前記在庫記録部から取得し、前記リソース候補の組み合わせの条件となる結合条件の中から所定の数を結合条件候補として抽出し、前記条件で指定された前記結合条件候補によって組み合わせられる前記リソース候補の組み合わせの中から所定の基準に基づいて１つを選択して、これを前記ユーザに割り当てるリソースの組み合わせ候補とする割り当て候補抽出部と、を有するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、複数種類のリソースの組み合わせとその割り当ての決定をシステムが行う仕組みにおいて、各組み合わせに係るリソース毎の在庫数を考慮した上で、ユーザ、割り当て者双方にとって効果的・効率的な在庫の割り当てをすることが可能となる。

本発明の一実施の形態であるリソース割り当てシステムの構成例について概要を示した図である。 本発明の一実施の形態におけるリソースの割り当て処理の流れの例について概要を示したフローチャートである。 （ａ）、（ｂ）は、本発明の一実施の形態における該当リソースリストの具体的な例について概要を示した図である。 本発明の一実施の形態における結合条件候補リストの具体的な例について概要を示した図である。 本発明の一実施の形態における結合条件リストの具体的な例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態における候補リソースリストの具体的な例について概要を示した図である。 本発明の一実施の形態における候補リソースリストの具体的な例について概要を示した図である。 本発明の一実施の形態における候補リソースリストにおける各リソースの組合せ状況の例について示した図である。 本発明の一実施の形態におけるリソースの組み合わせの順位を決定する第０方式の処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態における第１方式によりリソースの組み合わせの順位を決定する際の例について示した図である。 本発明の一実施の形態におけるリソースの組み合わせの順位を決定する第２方式の処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態における第２方式によりリソースの組み合わせの順位を決定する際の例について示した図である。 本発明の一実施の形態における同一結合条件内でのリソースの複数の組み合わせについて順位を決定する際の例について示した図である。 本発明の一実施の形態におけるリソースの組み合わせの順位を決定する第３方式の処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態における第３方式によりリソースの組み合わせの順位を決定する際の例について示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態における第１方式により各リソースにウェイトを設定した場合の抽選確率の例を示した図である。 （ａ）〜（ｄ）は、本発明の一実施の形態における第３方式で決定される組み合わせ毎ウェイトの例を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態における第３方式により各リソースにウェイトを設定した場合の抽選確率の例を示した図である。 本発明の一実施の形態におけるリソースの組み合わせ毎の抽選確率が決定された際の優先順位の決定方法の例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。

＜システム構成＞
図１は、本発明の一実施の形態であるリソース割り当てシステムの構成例について概要を示した図である。本実施の形態のリソース割り当てシステム１は、ユーザに対して、入力された条件に基づいて複数種類のリソースの組み合わせからなる候補を抽出し、その中から最終的に割り当てる組み合わせをシステムが抽選により自動的に決定する情報処理システムである。例えば、「どこかに旅行したい」というユーザを対象に、新幹線などの交通機関における指定席について、入力された条件に基づいて抽出した複数の目的地の候補から最終的な行き先および号や便をシステムが抽選により自動的に決定する。

これにより、販売者（リソースの割り当て者）が希望する指定席等のリソース（在庫が多く残るであろうリソース）を優先的に選択して在庫の販売促進を図ることを可能とする。一方で、本実施の形態では、自動的に決定したリソースの組み合わせに係る情報（上記の例では新幹線での行き先）を利用期限直前までユーザに対して秘匿しておくことで、リソースの割り当て結果に対する意外性や期待感をユーザに対して提供することも可能とする。

本実施の形態のリソース割り当てシステム１は、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ等により実装されたサーバシステムであるリソース割り当てサーバ１０と、リソースの管理主体が各リソースの空き状況（在庫）を管理するとともに、顧客に対する在庫の割り当てを処理するために運営するリソース管理システム２０とを有し、これらが図示しないＬＡＮ（Local Area Network）等のネットワークを介して通信可能な構成を有する。本実施の形態では、図１に示すように、鉄道会社等が有する既存の予約管理システム等からなるリソース管理システム２０を前提とし、これと連携する形でリソース割り当てサーバ１０を別途設けているが、これらを一体の情報処理システムとして構築することも当然可能である。

また、リソース割り当てサーバ１０およびリソース管理システム２０に対してインターネット等のネットワーク３０を介してユーザが保有するＰＣ（Personal Computer）や、タブレット端末、スマートフォン等の情報処理端末からなるユーザ端末４０が接続可能な構成を有する。

リソース管理システム２０は、鉄道会社等のリソース管理主体が有する既存の情報処理システムであり、少なくとも、対象の管理主体が管理・提供する各リソースに対する割り当て要求を受け付けて割り当てを行い、その状況を保持、管理する機能を有する。本実施の形態では、例えば、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装された割り当て処理部２１を有する。また、データベース等により実装された在庫データベース（ＤＢ）２２および割り当て履歴ＤＢ２３などの各データストアを有する。

割り当て処理部２１は、リソースの割り当て要求を受け付けるインタフェースを有し、割り当てが行われた場合には、その内容に基づいて、在庫情報を管理する在庫ＤＢ２２、およびユーザに対する割り当て履歴（リソースの利用履歴）を記録する割り当て履歴ＤＢ２３の内容を更新する。割り当て処理部２１が有するインタフェースは、例えば、ネットワーク３０を介したユーザ端末４０等からの割り当て要求を受け付けるユーザインタフェースであってもよいし、後述するリソース割り当てサーバ１０からの指示を受け付けるプログラミングインタフェースやデータ連携のインタフェースであってもよい。

リソース割り当てサーバ１０は、ユーザからの条件の入力を受け付けて、複数種類のリソースの組み合わせからなる割り当ての候補を抽出するとともに、その中から最終的な組み合わせを抽選により決定する機能を有するサーバシステムであり、例えば、図示しないＯＳやＤＢＭＳ、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装された在庫管理部１１、割り当て候補抽出部１２、および申込管理部１３などの各部を有する。また、データベースやファイルテーブル等により実装された在庫ＤＢ１４、割り当て履歴ＤＢ１５、ユーザＤＢ１６、および申込ＤＢ１７などの各データストアを有する。

在庫管理部１１は、割り当ての対象となるリソースの在庫に係る情報を在庫ＤＢ１４に保持して管理する機能を有する。本実施の形態では、例えば、リソース管理システム２０において最新の在庫情報を保持している在庫ＤＢ２２から定期的に、もしくは随時に必要な在庫情報を抽出して、コピーやレプリケーション等することで在庫ＤＢ１４を構築する。リソース割り当てサーバ１０に在庫ＤＢ１４を有さず、リソース管理システム２０上の在庫ＤＢ２２を直接参照する構成としてもよい。また、在庫情報に限らず、各ユーザについてのリソースの過去の割り当て履歴（リソースの利用履歴）の情報をリソース管理システム２０上の割り当て履歴ＤＢ２３から抽出してコピーやレプリケーション等することで、リソース割り当てサーバ１０上に割り当て履歴ＤＢ１５を構築するようにしてもよい。

割り当て候補抽出部１２は、ユーザ端末４０を介したユーザからの条件の入力を受け付けて、在庫ＤＢ１４の在庫情報や、割り当て履歴ＤＢ１５の過去の割り当て情報、ユーザＤＢ１６に登録されているユーザの属性情報などに基づいて複数種類のリソースの組み合わせについての候補を複数抽出するとともに、その中から最終的な組み合わせを抽選により決定し、ユーザ端末４０に対して提示する機能を有する。なお、リソースの組み合わせについての候補の抽出や、最終的な組み合わせの決定等に係る処理内容の詳細については後述する。

申込管理部１３は、ユーザ端末４０を介したユーザからのリソースの割り当て・利用の申し込みの入力を受け付けて、申込ＤＢ１７に登録する機能を有する。後述するように、本実施の形態では、申し込みを受け付ける時点では、ユーザにはリソースの組み合わせの候補のみが提示されている状態であり、申し込みの内容にはこれらの候補の内容が含まれる。申込管理部１３は、例えば、申し込みの受け付け後、リソースの利用期限までの間の所定のタイミングで、最終的な組み合わせをユーザに対して通知する。最終的な組み合わせが決定された時点で、その内容に基づいてリソース管理システム２０の割り当て処理部２１を介して自動的に割り当てを登録して確定させてもよいし、ユーザがユーザ端末４０により割り当て処理部２１にアクセスして手動で割り当てを登録して確定させてもよい。

＜処理の流れ＞
図２は、本実施の形態におけるリソースの割り当て処理の流れの例について概要を示したフローチャートである。以下の例では、新幹線による旅行などのように行きと帰りの新幹線という２種類のリソースを組み合わせて割り当てる（販売する）場合について説明するが、３種類以上のリソースの組み合わせを対象とするものであってもよい。

まず、リソース割り当てサーバ１０がユーザからリソースの割り当てに係る条件の入力を受け付ける（Ｓ１０）。例えば、リソース割り当てサーバ１０がユーザ端末４０上の図示しないＷｅｂブラウザや専用のアプリケーション等からの要求に基づいて表示させた条件入力の画面を介してユーザから指定された割り当て・利用を希望するリソースの条件の情報を受け付ける。

条件には、例えば、各リソースについての利用希望日や利用時間帯、利用希望数などが含まれる。ここで、ユーザが全ての条件を指定できるものとすると、リソースの販売者・提供者側が販売を希望するリソース（在庫が多く残るであろうリソース）を優先的に販売して在庫の効率的販売を図ることができなくなる。

したがって、本実施の形態では、ユーザが希望リソースを特定するための条件のうち少なくとも一部については指定できないものとし、当該条件の制限がないことによって生じる一定の幅に含まれる対象リソースの中から複数の候補を選択してユーザに提示するものとする。すなわち、ユーザが最終的に割り当てられるリソースの決定をシステムに委ねることで、リソースの提供者は在庫を効率的に販売することができる一方で、ユーザは、例えば、これと引き換えに大幅なディスカウントを得ることができる。

ユーザによる指定を受け付けない（すなわち、リソースの提供者側が自身に有利に決定することができる）条件については、特に限定されないが、例えば、新幹線の行き先などのリソースのタイプや属性の一部、発時刻などのリソースの利用時間帯などとすることができる。以下に説明する本実施の形態では、新幹線での旅行等における行き先（すなわち、行きの新幹線の到着駅、および帰りの新幹線の出発駅であり、それぞれのリソースの属性の一部）についてユーザによる指定を受け付けないものとする。

ユーザからの条件の入力を受け付けると、リソース割り当てサーバ１０の割り当て候補抽出部１２が、２種類のリソースを組み合わせる条件となる結合条件の候補を決定する一連の処理を行う（Ｓ２０）。例えば、リソースが新幹線の座席（チケット）である場合、行きの新幹線と帰りの新幹線という２種類のリソースにおける結合条件は行き先・目的地（すなわち、行きの新幹線の到着駅であり、帰りの新幹線の出発駅）である。

一連の処理ではまず、ステップＳ１０で入力された条件に合致するリソースをリソースの種類毎に在庫ＤＢ１４から抽出して該当リソースリストを作成する（Ｓ２１）。具体的には、リソースの種類毎に、在庫ＤＢ１４に登録されている在庫の中から、入力された条件において指定されたリソースの属性（例えば、出発駅など）や、利用希望日付および時間帯に該当し、かつ指定された利用希望数より在庫数が多いものを抽出して該当リソースリストを作成する。なお、在庫ＤＢ１４には、在庫管理部１１により予め全便の全在庫のリストが反映・登録されているものとする。ここでの在庫数は、各リソースについての提供・販売可能数−提供・販売済数として算出される。

図３は、該当リソースリストの具体的な例について概要を示した図である。図３（ａ）、（ｂ）は、それぞれ、図２の条件入力画面において指定された条件に合致する複数種類のリソース（行きと帰りの新幹線）に含まれるレコードからなる該当リソースリストの例を示している。

図３（ａ）では、４月１７日に利用可能な「リソース１」という種類のリソース（例えば、指定された出発駅からの行きの新幹線）について、在庫数が利用希望数以上のレコードがリストされており、図３（ｂ）では、４月１８日に利用可能な「リソース２」という種類のリソース（例えば、指定された出発駅への帰りの新幹線）について、在庫数が利用希望数以上のレコードがリストされている。また、各リストでは、各リソースのレコードについて組み合わせを作成する際の結合条件として用いられる属性の情報（例えば、行きの新幹線では到着駅、帰りの新幹線では出発駅）が、それぞれ「属性１」、「属性２」として示されている。

なお、ユーザにより指定された条件以外の追加条件として、例えば、各リソースの大きさやキャパシティなどの所定の属性や、現在の在庫数の多寡の程度などに応じて、一定の在庫数以下のものは提供・販売不可として取り扱う（もしくはリストから除外する）ようにしてもよい。図３の例では、網掛けされた各リソースが追加条件に該当するものとして提供・販売不可として取り扱われることを示している。

図２に戻り、次に、ステップＳ２１で作成した該当リソースリストに基づいて、各リストに共通して含まれる属性からなる結合条件候補リストを作成する（Ｓ２２）。具体的には、図３の例では、「リソース１」の該当リソースリストから「属性１」の値のリスト（例えば、行きの新幹線の到着駅のリスト）を抽出し、さらに「リソース２」の該当リソースリストから「属性２」の値のリスト（例えば、帰りの新幹線の出発駅のリスト）を抽出する。そして、「リソース１」と「リソース２」の該当リソースリストの双方に共通して含まれる属性の値を抽出して結合条件候補リストとする。

なお、本実施の形態では、上記のように「リソース１」と「リソース２」で個別に属性の値のリストを抽出して、双方に共通する値を抽出する処理手順としているが、同様の結果を得ることができるものであれば処理手順は特に限定されない。例えば、ステップＳ２１およびＳ２２に相当する処理として、先に「リソース１」のみについて該当リソースリストを作成して「属性１」の値のリストを抽出し、その後、「リソース２」について、「属性２」の値が「リソース１」の「属性１」の値のリストに含まれるもののみを対象として該当リソースリストを作成し、「リソース２」の該当リソースリストに含まれる「属性２」の値を結合条件候補リストとする処理手順としてもよい。

本実施の形態では、上述したように、リソースの組み合わせにおける結合条件のパターンとして複数の候補をユーザに提示し、その中からシステムが好適な結合条件およびその結合条件に係るリソースのレコードの組み合わせを選択する構成とする。したがって、ステップＳ２２で作成した結合条件候補リストに含まれる結合条件の数が所定の数（例えば数個）以下の場合は、複数の結合条件の候補の中から選択するという仕組みが成立しない場合が生じ得る。したがって、ステップＳ２２で作成した結合条件候補リストに含まれる結合条件の数が所定の数以下であるか否かをチェックし（Ｓ２３）、所定の数以下の場合には、例えば、ユーザ端末４０に対して「該当するリソースはご用意できませんでした」等のメッセージを表示して処理を終了する。

図４は、結合条件候補リストの具体的な例について概要を示した図である。図中の表における左側の列は、図３（ａ）に示した「リソース１」の該当リソースリストから「属性１」の値を抽出したものを示し、表の中央の列は、図３（ｂ）に示した「リソース２」の該当リソースリストから「属性２」の値を抽出したものを示している。そして表の右側の列は、これらに共通して含まれる属性値、すなわち、「リソース１」と「リソース２」のレコードの組み合わせを作ることができる属性値のリストを示している。本実施の形態では、原則としてユーザは、例えば新幹線で出発地から１ヶ所の目的地に行き、そこから出発地に帰ってくるものであることを想定しているため、リソースの組み合わせとしては、出発地と目的地との間で時間帯も含めて往復することができる組み合わせがあることが必要となる。

図２に戻り、次に、ステップＳ２２、Ｓ２３で作成したリソースの組み合わせについての結合条件候補リストに含まれる結合条件から、ユーザに対して候補として提示する所定の数の結合条件を選択して結合条件リストを作成する（Ｓ２４）。具体的には、例えば、結合条件候補リストに含まれる各結合条件を所定の基準でスコアリングする等により順位付けし、上位のものから順に所定の数の結合条件を選択して結合条件リストとする。もしくは、算出したスコアに応じて設定された抽選確率に基づいてランダムな抽選により所定の数の結合条件を選択するようにしてもよい。

スコアリングに際しては、例えば、各結合条件について所定のパラメータ毎にウェイトを設定して重み付けし、各ウェイトを乗算することでスコアを算出する。基本となるパラメータは結合条件に対応するリソースの組み合わせ毎の在庫数であり、在庫数が多い結合条件ほどスコアが高くなるようウェイトを設定するものとするが、これに他のパラメータによるウェイトを反映することができる。例えば、結合条件別のパラメータとしては、結合条件や対応するリソースの人気（利用者数や提供数が多いリソース）や、リソースの提供者・販売者等が催すキャンペーン等の対象であるか否かなどによりウェイトを設定することができる。

また、同じ結合条件内でも、利用対象の月や曜日、時間帯、もしくはこれらの組み合わせの別でウェイトを設定することができる。例えば、同じリソースでも金曜日の夕方は平日の他の時間帯に比べて需要が高く在庫が販売されやすいなどの事情を反映させることができる。さらに、ユーザ毎の個人別のウェイトとして、例えば、過去に本実施の形態のリソース割り当てシステム１により抽選・決定されたものや過去に利用したことがあるリソースの組み合わせや結合条件については再度選択されにくくするようにウェイトを設定することができる。

図５は、結合条件リストの具体的な例について概要を示した図である。図中の左側の表は、図４に示したリソースの組み合わせについての結合条件候補リストに含まれる各結合条件について、上述したような結合条件別、月別、曜日別、および個人別のパラメータ毎にウェイトを設定し、各ウェイトを乗算した結果を示している。そして、乗算結果の上位の所定の数（本実施の形態では４つ）の結合条件を抽出して結合条件リストとしたものを右側の表に示している。なお、各パラメータがどのような条件に該当した場合にどのような値のウェイトを設定するかについての設定情報は、例えば、図示しない設定ファイルやテーブル等に予め登録して外出しにしておき、必要に応じて変更できるようにしてもよい。

上述したように、結合条件候補リスト中の結合条件から所定の数の候補を選択する際には、パラメータ毎にウェイトを設定してスコアリングし、上位の所定の数を選択、もしくは抽選により所定の数を選択することで行う。例えば、上位の所定の数を選択するものとした場合、近接した時間間隔で同一ユーザについて複数回検索を行った場合、在庫数がその間に大きく変化していない限り、基本的には同じ内容の結合条件が候補として選択されることになるが、在庫数が変化した場合には候補の結合条件も変化することがあり得る。また、抽選により所定の数を選択するものとした場合は、当然ながら検索を行う毎に候補の結合条件が変化し得る。このとき、いい組み合わせの候補が現れるまで何度も検索を繰り返すことをユーザに許容すると、システムに対して過大な負荷がかかることになる。

そこで本実施の形態では、ユーザが入力した条件と検索結果の結合条件の候補の内容をＣｏｏｋｉｅに記録する等により、再度同じ条件が入力された場合、在庫が存在する限りにおいて最初に出力した結合条件の候補と同じ内容の候補を出力する。在庫の変動により在庫数が不足する状態となった場合など、当初の検索結果の結合条件の候補を選択できない場合には、「該当なし」として応答する。これによりユーザによる検索の繰り返しを抑制することができる。同じ条件が指定された場合に、常に当初の検索結果を用いるのではなく、回数制限を設けて一定の回数に限り再度の検索処理を許容するようにしてもよい。また、例えば数日後など一定期間を経過した後にはリセットして再度新規の検索ができるようにする。

図２に戻り、所定の数の結合条件の候補が決定されると、次に、複数種類のリソース（本実施の形態では「リソース１」と「リソース２」であり、例えば新幹線の行きと帰りなど）のレコードの組み合わせのうち、実際にユーザに提供・販売する組み合わせを決定する一連の処理を行う（Ｓ３０）。ここでは、リソース毎、レコード毎などの在庫に応じたウェイトを設定して各リソースの組み合わせをスコアリングし、スコアに応じた抽選確率で最終的なリソースの組み合わせを抽選により決定する。

なお、本実施の形態では、上述したように、最終的なリソースの組み合わせの決定や、実際の割り当て（リソースの提供・販売）の登録のタイミング等については柔軟に設定することができるため、設定によってはリソース管理システム２０で実際にリソースの組み合わせを割り当てる際に既に対象の組み合わせに係るリソースの在庫がなくなっていて割り当てできないという事態が生じ得る。

そこで本実施の形態では、上記のようなリスクを回避するため、最終的なリソースの組み合わせを抽選により決定する際に、抽選された１つの組み合わせ以外の他の組み合わせについても予め抽選により順位を決定して優先順位のリストとしておく。これにより、実際の割り当て時に対象の組み合わせの在庫がない場合でも、速やかに次順位の候補を対象として割り当ての登録をすることができる。次順位の候補の組み合わせにも在庫がない場合には、さらに次順位の候補、というように割り当てが確定して登録できるまで優先順位のリストから順次代替の候補を抽出して割り当てを試みることができる。

また、本実施の形態では、上述したように、実際の割り当ての登録を行っても最終的なリソースの組み合わせの情報は利用直前までユーザに対して通知しないようにすることもできることから、上記のようなリソースの組み合わせの決定過程についてもユーザから秘匿することができる。なお、リソースの組み合わせの候補の全てについて優先順位を決定してもよいし、上位から所定の順位までのみ優先順位を決定して以降は省略することで効率化してもよい。

ステップＳ３０の一連の処理では、まず、ステップＳ１０で指定された条件と、ステップＳ２４で作成された結合条件リストに含まれる所定の数の結合条件の候補とに合致するリソースからなる候補リソースリストを作成する（Ｓ３１）。具体的には、ステップＳ２１で作成した各リソースの該当リソースリストから、結合条件リストに含まれる各結合条件の属性値に該当するリソースのレコードをそれぞれ抽出し、各リソースについて可能な全てのレコードの組み合わせからなる候補リソースリストを作成する。

図６、図７は、候補リソースリストの具体的な例について概要を示した図である。図６（ａ）、（ｂ）は、それぞれ、上述の図３（ａ）、（ｂ）に示した「リソース１」（例えば、行きの新幹線）および「リソース２」（例えば、帰りの新幹線）の該当リソースリストから、図５に示した結合条件リストに含まれる各結合条件の属性値に該当するレコードを抽出した「リソース１」および「リソース２」の候補リソースリストの例を示している。また図７は、図６（ａ）、（ｂ）に示した候補リソースリストに基づいて作成された組み合わせに係る候補リソースリスト（例えば、往復での新幹線の候補）の例を示している。図中では便宜上、結合条件の候補（「属性１」、「属性２」の値）毎に太線枠で囲って示している。

図８は、候補リソースリストにおける各リソースの組合せ状況の例について示した図である。ここでは、図７に示した組み合わせに係る候補リソースリストにおけるリソースの組み合わせ状況を図示している。図中では上段に「リソース１」（例えば、行きの新幹線）の候補リソースリストに含まれる各リソースについて「属性１」の値とリソース名および在庫数を示し、下段に「リソース２」（例えば、帰りの新幹線）の候補リソースリストに含まれる各リソースについて「属性２」の値とリソース名および在庫数を示している。

また、各リソースの組み合わせとして可能なものとして、「リソース１」の「属性１」（例えば、行きの新幹線の到着駅）の値と「リソース２」の「属性２」（例えば、帰りの新幹線の出発駅）の値が同一であるものについて、日付と利用可能時間を考慮した上で総当りで組み合わせたものを実線で示している。すなわち、「リソース１」と「リソース２」のリソースを結ぶ各実線は図７に示した組み合わせに係る候補リソースリストの各行に対応している。

図２に戻り、次に、ステップＳ３１で作成した組み合わせに係る候補リソースリスト中の各リソースの組み合わせについて、所定の条件に基づいて優先順位を決定する処理を行う（Ｓ３２）。優先順位の決定方法には各種のものが考えられ、任意の方法を適宜採用することができる。例えば、最も単純かつ一般的に考え得る方法として、組み合わせを考慮せずに、各リソースで順次（本実施の形態では「リソース１」、「リソース２」の順（もしくはその逆））個別に対象のレコードを選択・決定した後、これらを組み合わせるという方法が考えられる。

図９は、本実施の形態におけるリソースの組み合わせの順位を決定する第０方式の処理の流れの例について概要を示したフローチャートである。処理を開始すると、まず、「リソース１」（例えば、行きの新幹線）の候補リソースリストから対象とするリソースのレコードを無作為に１つ抽選して決定する（Ｓ３２１＿１）。次に、ステップＳ３２１＿１で決定したリソースの「属性１」（例えば、行きの新幹線の到着駅）の値に対応する「属性２」（例えば、帰りの新幹線の出発駅）の値を有するリソースのレコードを、「リソース２」（例えば、帰りの新幹線）の候補リソースリストから無作為に１つ抽選して決定する（Ｓ３２１＿２）。

その後、ステップＳ３２１＿１およびＳ３２１＿２で決定した「リソース１」と「リソース２」の各リソースのレコードの組み合わせが既に抽出済みであるか否かを判定する（Ｓ３２１＿３）。既に抽出済みである場合は、ステップＳ３２１＿１に戻って処理を繰り返す。

一方、ステップＳ３２１＿３で対象のレコードの組み合わせが抽出済みでない場合は、対象の組み合わせを優先順位のリストの末尾に追加して順位を決定する（Ｓ３２１＿４）。順位を決定した組み合わせの情報は、図２のステップＳ３１で作成した組み合わせに係る候補リソースリストから削除する。その後、候補リソースリスト中に残りがあるか否かを判定する（Ｓ３２１＿５）。残りがある場合はステップＳ３２１＿１に戻って処理を繰り返す一方、残りがなくなった場合は処理を終了する。

上記のような第０方式を採用した場合、リソースの組み合わせについて優先順位のリストを作成する際のロジックがシンプルになり、実装が容易になるという利点を有する。一方で、決定した「リソース１」と「リソース２」のレコードの組み合わせに対して、新たに順位を決定した場合には組み合わせに係る候補リソースリストに対して消し込みを行う必要があり、また、既に順位を決定済みである場合には対象の組み合わせを決定した処理が無駄になってしまうなど、処理の効率が悪く処理時間を要する場合があり得る。

また、在庫の提供・販売という観点でも効率性が低下する場合がある。第０方式では、各リソースの在庫数の多寡を全く考慮していないため、在庫数が少ないリソースやリソースのグループ（例えば、到着駅が同じなど「属性１」や「属性２」の値が同じリソースのグループ）であっても先に販売されてしまう可能性があり、在庫数が多いリソースについて効率的に販売したいという販売者側の要望を満たすことができない。また、在庫数が少ないリソースやリソースのグループであっても無作為に選択されて販売され得る結果、販売不可（売り切れ）となるリソースやリソースのグループが多く出現する場合があり、ひいてはリソースや結合条件の候補を所定の数だけ選択することができなくなる場合も生じ得る。

これに対し、在庫数が多いリソースから優先的に販売されるよう、第０方式のような無作為の抽出ではなく、各リソースに対して在庫数に応じたウェイトをつけて重み付けし、在庫数が多いリソースほど選択・抽選されやすくすることが考えられる（この方式を「第１方式」とする）。図１０は、第１方式によりリソースの組み合わせの順位を決定する際の例について示した図である。図１０の例では、説明の便宜のため、図８に示した各リソースの組み合わせの例における在庫数とは異なり、「リソース１」と「リソース２」の各リソースはそれぞれ図示するような在庫数であったものとする。

第１方式では、第０方式と同様に、まず上段の「リソース１」の中から対象のリソースを１つ選択するが、その際、第０方式のような無作為選択ではなく、在庫数に応じて設定されたウェイトを考慮して決定する。図１０の例では、結合条件である「属性１」の値について、他と比較して在庫数がいずれも１００個と多い属性値が「Ａ」のリソースのうち「Ａ１＿２」が抽選・選択されたことを太枠で示している。次に、下段の「リソース２」のうち、選択された「リソース１」（図の例では「Ａ１＿２」）の「属性１」の値（図の例では「Ａ」）に対応する「属性２」の値を有するものから在庫数に応じて設定されたウェイトを考慮して１つ決定する。図１０の例では在庫数がいずれも１０個である「属性２」が「Ａ」である「リソース２」のうち「Ａ２＿３」が抽選・選択されたことを太枠で示している。

上記の第１方式の場合、ウェイトにより在庫数の多寡を考慮することができるものの、例えば、「リソース１」と「リソース２」の間の在庫数の偏りや、「リソース１」の各リソースの間の在庫数の偏りと「リソース２」の各リソースの間の在庫数の偏りが大きい場合には、在庫の多寡を適切に評価することができずに非効率な販売となる場合が生じ得る。

例えば図１０の例における属性値が「Ａ」の各リソースにおいて、上段の「リソース１」の３つのリソース（「Ａ１＿１」、「Ａ１＿２」、「Ａ１＿３」）の在庫数の合計は３００個と多数であるが、下段の「リソース２」の３つのリソース（「Ａ２＿１」、「Ａ２＿２」、「Ａ２＿３」）の在庫数の合計は３０個しかなく大きな偏りがある。この場合、これらの双方のリソースを同時に割り当てることができる人数（例えば、行きと帰りの新幹線の場合、目的地「Ａ」との間で実際に往復することができる人数）は最大で３０人しかいないことになる。すなわち、リソースの組み合わせという観点での割り当て可能キャパシティは３０個である。

これに対し、図１０の例における属性値が「Ｄ」のリソースは、上段の「リソース１」のリソース（「Ｄ１＿１」）の在庫数が３０個であり、上記の属性値が「Ａ」のリソースに比べてはるかに在庫数が少ないが、下段の「リソース２」のリソース（「Ｄ２＿１」）の在庫数も３０個であり、割り当て可能キャパシティは属性値が「Ａ」のリソースと同じ３０個となる。このように、リソースの組み合わせを考慮した割り当て可能キャパシティという点では同じであるにも関わらず、「リソース１」の在庫数が多い属性値が「Ａ」のリソースの方が、「リソース１」からの抽選の際に圧倒的に選択されやすくなってしまい、結果として非効率な販売となり得る。リソースや結合条件によっては上記の例のように、例えば、平日の日中は在庫が比較的多い一方で、金曜日の夕方はほぼ在庫がない状態となるのが通常、というように在庫数に大きな偏りがある場合もある。

図１１は、リソースの組み合わせの順位を決定する第２方式の処理の流れの例について概要を示したフローチャートである。この第２方式では、結合条件の属性値が同じリソースの組み合わせのグループ（例えば、新幹線での目的地の駅が同じ組み合わせ）毎の各リソースの在庫数の偏りに伴う非効率を解消するため、リソースの組み合わせでの在庫数を考慮してウェイトを設定する。処理を開始すると、まず、各リソース（本実施の形態では「リソース１」と「リソース２」）の候補のレコードについて、全ての組み合わせを作成する（Ｓ３２２＿１）。この処理は図２のステップＳ３１において作成した組み合わせに係る候補リソースリストの作成と同内容である。

次に、ステップＳ３２２＿１で取得した各組み合わせについて、各リソースの在庫数のいずれか少ない方を、組み合わせとしての在庫数（組み合わせ在庫数）とする（Ｓ３２２＿２）。そして、各組み合わせについて組み合わせ在庫数をウェイトとして重み付けした上で優先順位を抽選・決定し（Ｓ３２２＿３）、処理を終了する。各組み合わせについて抽選により優先順位を抽選・決定する手法については後述する。

図１２は、第２方式によりリソースの組み合わせの順位を決定する際の例について示した図である。図１２の例では、図８に示した各リソースの組み合わせの例における在庫数と同様の在庫数であったものとする。図中では、結合条件の属性値が「Ａ」であるリソースの組み合わせと「Ｄ」であるリソースの組み合わせについて、それぞれ、各組み合わせについてステップＳ３２２＿２で決定された組み合わせ在庫数を示している。また、属性値が「Ａ」であるリソースの全ての組み合わせ（９パターン）についての組み合わせ在庫数の合計は１４０であり、属性値が「Ｄ」であるリソースの全ての組み合わせ（１パターン）についての組み合わせ在庫数の合計は１０であることを示している。

図１２の例において、第２方式では、各リソースの組み合わせについて順位を抽選・決定する際に、結合条件の属性値が「Ａ」のリソースの組み合わせについては１４０のウェイトが設定され、結合条件の属性値が「Ｄ」のリソースの組み合わせについては１０のウェイトが設定される。このように、各リソースの組み合わせ毎の組み合わせ在庫数に基づいたウェイトが設定されるため、各リソースの組み合わせにおける「リソース１」と「リソース２」の間の在庫数の偏りによる非効率を解消することができるとともに、リソースの組み合わせとして在庫数が多い組み合わせほど高い優先順位で抽選されやすくなり、在庫を最後まで効率的に販売しやすくなる。

一方で、図１２の例では、結合条件の属性値が「Ａ」のリソースの全組み合わせのウェイトの合計と、結合条件の属性値が「Ｄ」のリソースの全組み合わせのウェイトの合計との比は１４：１となる。したがって、各リソースの組み合わせの順位を抽選・決定する際において、結合条件の属性値が「Ａ」のリソースの組み合わせのいずれかが選択される確率は、結合条件の属性値が「Ｄ」のリソースの組み合わせが選択される確率の１４倍となる。すなわち、最終的なリソースの組み合わせとして結合条件の属性値が「Ａ」のリソースの組み合わせが選択される確率は、結合条件の属性値が「Ｄ」のリソースの組み合わせが選択される確率の１４倍となる。

しかし、ここで上述したようなリソースの組み合わせという観点での割り当て可能キャパシティを考慮すると、結合条件の属性値が「Ａ」のリソースは全体で６０個であるのに対し、結合条件の属性値が「Ｄ」のリソースは１０個であり、割り当て可能キャパシティの比は６：１に過ぎない。すなわち、結合条件の属性値が「Ａ」のリソースのように「リソース１」と「リソース２」の組み合わせのパターンが多い結合条件ほど、割り当て可能キャパシティの偏りに比べてリソースの組み合わせという観点で大きいウェイトが設定される結果、最終的なリソースの組み合わせとしてより抽選されやすくなる。

したがって、第２方式は、リソースの組み合わせが多い結合条件（すなわち、リソースの提供数や利用者が多い属性値）からなるリソースを優先的に販売したいというような場合には有効である。なお、リソースの組み合わせが多い結合条件でも、在庫が減った（売り切った）リソースが増えてくるにしたがって組み合わせのパターンも減ってくるため、結合条件の属性値に対して大きいウェイトが設定される（すなわち在庫が販売されやすい）状態も緩和されてくる。

一方、結合条件毎の在庫数の偏りに加えて、結合条件内での各リソースの組み合わせの在庫数の偏りについても考慮することが望まれる。図１３は、同一結合条件内でのリソースの複数の組み合わせについて順位を決定する際の例について示した図である。例えば、ある結合条件について「リソース１」の候補のレコードが上段の図に示す３つ、「リソース２」の候補のレコードが下段の図に示す３つの状態で、これらの組み合わせの中から対象の組み合わせを抽選・選択する場合を考える。この場合、上記の第２方式では、図１１のステップＳ３２２＿２で決定する各リソースの組み合わせの組み合わせ在庫数は、いずれも在庫数が少ない方の１０に補正される。したがって、ステップＳ３２２＿３で組み合わせ在庫数に基づいて各リソースの組み合わせに対して設定されるウェイト、すなわち優先順位決定の際の抽選確率は、均等な値となる。

しかしながら、図１３の例では「リソース２」の「Ａ２＿１」のみ他のリソースの１０個と異なり８０個の在庫を有しており、優先順位決定の際に「リソース２」として「Ａ２＿１」を有する組み合わせが選択される抽選確率は他の組み合わせに比べて８倍とするのが実態に沿うものと考えられる。すなわち、第２方式では、図１３の例のようにある結合条件について「リソース１」（もしくは「リソース２」）の各レコードの在庫数が総じて少なく、かつ、「リソース２」（もしくは「リソース１」）の各レコードの在庫数が総じて多い場合には、「リソース２」（もしくは「リソース１」）の在庫数の分布や偏りが組み合わせを決定する際のウェイトに反映されなくなる。

図１４は、リソースの組み合わせの順位を決定する第３方式の処理の流れの例について概要を示したフローチャートである。この第３方式では、リソースの組み合わせのパターンが多い結合条件についてウェイトが大きく設定されることを回避しつつ、各結合条件でのリソースの種類（本実施の形態では「リソース１」と「リソース２」）毎の在庫数のバランスを考慮してウェイトを設定する。

処理を開始すると、まず、各リソース（本実施の形態では「リソース１」と「リソース２」）の候補のレコードについて、全ての組み合わせを作成する（Ｓ３２３＿１）。この処理は図２のステップＳ３１において作成した組み合わせに係る候補リソースリストの作成と同内容である。次に、ステップＳ３２２＿１で取得した各リソースの組み合わせについて、「リソース１」と「リソース２」のレコードの在庫数を乗算し、その値を結合条件内組み合わせ毎ウェイトとして決定する（Ｓ３２３＿２）。

次に、結合条件毎に「リソース１」の各レコードの在庫数の合計と「リソース２」の各レコードの在庫数の合計をそれぞれ算出し、その少ない方を結合条件毎ウェイトとして決定する（Ｓ３２３＿３）。すなわち、各結合条件でのリソースの組み合わせについての上述した割り当て可能キャパシティを算出して結合条件毎ウェイトとする。そして、ステップＳ３２３＿２で算出した結合条件内組み合わせ毎ウェイトと、ステップＳ３２３＿３で算出した結合条件毎ウェイトをリソースの組み合わせ毎に乗算して組み合わせ毎ウェイトを算出し（Ｓ３２３＿４）、組み合わせ毎ウェイトに基づいて抽選・選択を行って各リソースの組み合わせの優先順位を決定して（Ｓ３２３＿５）、処理を終了する。

図１５は、第３方式によりリソースの組み合わせの順位を決定する際の例について示した図である。図１５の例では、図８に示した各リソースの組み合わせの例における在庫数と同様の在庫数であったものとする。図中では、結合条件の属性値が「Ａ」のリソースについて、組み合わせ毎に算出した結合条件内組み合わせ毎ウェイトを示している。また、各結合条件について、それぞれ「リソース１」と「リソース２」の各リソースの在庫数合計を示し、その少ない方を結合条件毎ウェイトとしたことを示している。

以下では、上記の第３方式によりウェイトを設定した場合に、各リソースの組み合わせについての優先順位を決定するための抽選確率がどのように算出されるかを示す。図１６は、比較のために上述した第１方式により各リソースにウェイトを設定した場合の抽選確率の例を示した図である。図１６（ａ）、（ｂ）は、図２のステップＳ３１で作成されたリソースの組み合わせに係る候補リソースリストが図７（および図８）の例に示したものであった場合に、「リソース１」、「リソース２」のそれぞれについて、各リソースのみで在庫数をウェイトとして抽選確率を算出した場合を示している。

ここでは、「リソース１」、「リソース２」のそれぞれについて、全ての候補リソースの在庫数の合計（往路＝２１５、復路＝１８０となる）に対して１００％となる抽選確率を、各リソースの在庫数で単純に按分した値が抽選確率とされている。第１方式では、この抽選確率に基づいて順次抽選された「リソース１」のリソースと「リソース２」のリソースの組み合わせに対して優先順位が決定される。

図１７、図１８では、第３方式により各リソースにウェイトを設定した場合にどのように抽選確率が算出されるかの例を示している。図１７は、図１４に示した第３方式の処理フローのステップＳ３２３＿４で決定される組み合わせ毎ウェイトの例を示した図である。図１７（ａ）〜（ｄ）は、それぞれ、図２のステップＳ３１で作成されたリソースの組み合わせに係る候補リソースリストが図７（および図８）の例に示したものであった場合に、４つの各結合条件の候補（属性値が「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」）を対象に、図１４に示した処理フローのステップＳ３２３＿２で決定される結合条件内組み合わせ毎ウェイトと、ステップＳ３２３＿３で決定される結合条件毎ウェイトとを乗算して組み合わせ毎ウェイトを算出した例を示している。

各図において、左辺の第１項では、対象の結合条件における「リソース１」の各リソースと「リソース２」の各リソースの全組み合わせからなるマトリクスにそれぞれの在庫数を乗算した結果を結合条件内組み合わせ毎ウェイトとして示している。各セルでは、上段に在庫数を乗算した値を示し、下段には当該値が対象の結合条件内全体に占める割合としてパーセントにより示している（以下の演算では下段のパーセント値を用いるものとする）。

また、左辺第２項では、図１５に示されている各結合条件の結合条件毎ウェイト（図１５の例では属性値が「Ａ」の結合条件が６０、属性値が「Ｂ」の結合条件が５０、属性値が「Ｃ」の結合条件が４５、属性値が「Ｄ」の結合条件が１０）について、全ての結合条件の合計（６０＋５０＋４５＋１０＝１６５）に占める割合として示している。そして、右辺では、「リソース１」の各リソースと「リソース２」の各リソースの組み合わせからなるマトリクスに左辺の計算結果として得られた組み合わせ毎ウェイトを示している。なお、図１７（ａ）〜（ｄ）に示された各結合条件の全てのリソースの組み合わせの組み合わせ毎ウェイトを全て合計すると１００％となる。第３方式では、この組み合わせ毎ウェイトを抽選確率として順次抽選することで各リソースの組み合わせの優先順位を決定する。

第３方式では、結合条件毎ウェイト（すなわち、上記の割り当て可能キャパシティ）によって結合条件毎に抽選確率を配分することで、例えば、在庫数が多くリソースの組み合わせパターンが多い結合条件がある場合にも、第２方式と比較して結合条件毎の在庫数に応じてより適切に販売することができる。すなわち、リソースの組み合わせパターンが多い結合条件に係るリソースが優先的に販売されるようなことにならず、結合条件毎のリソースの組み合わせでの在庫数（割り当て可能キャパシティ）が同じであれば、リソースの組み合わせパターンの多寡によって優先度（抽選確率）が影響されないようにすることができる。

また、同じ結合条件内では組み合わせ毎に各リソースの在庫数を乗算した結合条件内組み合わせ毎ウェイトによって抽選確率を配分することで、組み合わせとして余剰がある（在庫数が多い）リソースほど販売されやすくなり、在庫を最後まで効率的に販売することができる。また、各リソースの種類（本実施の形態では「リソース１」、「リソース２」）それぞれの在庫数の比率に応じて抽選確率を配分することになり、より適切に在庫を販売することができる。

なお、第３方式では、組み合わせにおけるリソース毎の在庫数を乗算して得た結合条件内組み合わせ毎ウェイトを用いていることから、実質的には、上述の第１方式などと同様に、「リソース１」と「リソース２」それぞれ個別に抽選・選択して結果を組み合わせることと等価である。したがって、いずれの方法を用いてもよいが、「リソース１」と「リソース２」でそれぞれ個別に抽選・選択して結果を組み合わせる後者の手法の場合、結合条件内組み合わせ毎ウェイトの算出は不要であるものの、全ての組み合わせに対して順位付けを行う際には組み合わせを考慮した消し込み処理等を行う必要があり非効率な処理となり得る。

図１８は、第３方式により各リソースにウェイトを設定した場合の抽選確率の例を示した図である。図１８（ａ）、（ｂ）は、図１７に示したリソースの組み合わせ毎の抽選確率（右辺の組み合わせ毎ウェイト）を、「リソース１」、「リソース２」に分けてそれぞれリソースのレコード毎に集計したものを示している。上述したように、第３方式は、図１８に示したような抽選確率によって「リソース１」、「リソース２」それぞれ個別にレコードを抽選・選択し、これらを組み合わせて決定することと等価である。

図１８に示した第３方式により決定された抽選確率を、図１６に示した第１方式により決定された抽選確率と比較すると、図１８の例では、結合条件間の在庫数のバランス、「リソース１」、「リソース２」それぞれにおける在庫数のバランスに基づいて抽選確率が補正されていることが分かる。例えば、図１８（ａ）の例では、在庫数が同じ３０の「リソース１」のリソースでも、属性値が「Ａ」の「Ａ１＿１」と属性値が「Ｂ」の「Ｂ１＿１」では、結合条件毎の「リソース２」の在庫数によって抽選確率が調整されて前者の方が抽選確率が高くなっている。

なお、本実施の形態では、抽選確率（もしくはウェイト）の異なる複数のリソースやその組み合わせから抽選で選択された要素を順次取り出して順位付け（ランキング）するが、その手法については特に限定されず、公知のものも含めて任意の手法をとることができる。

図１９は、本実施の形態におけるリソースの組み合わせ毎の抽選確率が決定された際の優先順位の決定方法の例について概要を示した図である。例えば、Ａ、Ｂ、Ｃの３つの要素に対して順位付けを行う場合、それぞれの抽選確率がＷ＝１、２、３であったとすると、左側の図に示すように、要素Ａの当選範囲Ｈ_Ａを０＜Ｈ_Ａ≦１、要素Ｂの当選範囲Ｈ_Ｂを１＜Ｈ_Ｂ≦３、要素Ｃの当選範囲Ｈ_Ｃを３＜Ｈ_Ｃ≦６とする。なお、当選範囲Ｈの配置の順序はこれに限られず任意とすることができる。

その後、乱数値Ｐを０＜Ｐ≦６の範囲で発生させ、Ｐが属する当選範囲Ｈに対応する要素が当選したものとする。図１９の例では要素Ｂが当選したことを示している。その後、当選した要素Ｂを順位リストの末尾に追加するとともに、当選範囲Ｈ_Ｂを取り除き、右側の図に示すように当選範囲Ｈ_Ｂ部分の間隙を詰めて当選範囲を再構成した上で次回の抽選を行う。このとき次回の抽選で生成する乱数値Ｐの範囲は０＜Ｐ≦４となる。このようにして当選した要素の当選範囲Ｈを順次取り除き、当選範囲Ｈが全てなくなるまで抽選を繰り返すことで、全ての要素について順位付けを行った結果の順位リストを得ることができる。

図２に戻り、ステップＳ３２においてリソースの組み合わせについての優先順位が決定されると、ステップＳ２４で作成した結合条件リストに含まれる所定の数の結合条件の情報をユーザ端末４０上に表示させる等によりユーザに対して出力する（Ｓ３３）。すなわち、この時点では、結合条件の候補はユーザに通知されるが、いずれのリソースの組み合わせが選択される（もしくは選択された）かはユーザにとって不明である。

その後、ユーザはリソースの割り当ての申し込みをするか否かを判断するが、申し込みをしなかった場合（他の画面に遷移したり、アプリケーションを終了させたり等の場合）は、上述したように、ステップＳ１０で入力された検索条件と、ステップＳ２４で作成した結合条件リストの情報をＣｏｏｋｉｅ等を用いて記憶するようにしてもよい。一方で、ユーザが申し込みをする場合は、ユーザ端末４０からの申し込みの要求を受け付けて申込処理を行い（Ｓ４０）、一連の処理を終了する。

申込処理では、例えば、ステップＳ２４で作成した結合条件リストや、ステップＳ３２で決定されたリソースの組み合わせ毎の優先順位のリスト等の情報を申込ＤＢ１７等に記録した上で、本実施の形態では、優先順位リストの最上位に記録されたリソースの組み合わせについて、リソース管理システム２０の割り当て処理部２１を介して実際に割り当ての処理を行い、在庫数を減算する（もしくは販売済み数を加算する）。上述したように、リソース管理システム２０での実際の割り当ての際に在庫数が不足するような状態となった場合には、優先順位リストの次順位に記録された往復便により代替して割り当て処理を行う。実際に割り当てられたリソースの組み合わせの情報については、本実施の形態では対象のリソースの利用日の数日前にユーザに対して通知する。

以上に説明したように、本発明の一実施の形態であるリソース割り当てシステム１によれば、ユーザから入力された条件に基づいて抽出した複数の結合条件やリソースの組み合わせの候補から最終的に割り当てるリソースの組み合わせをシステムが抽選により自動的に決定するというリソースの提供・販売手法を実現することができ、販売者が希望するリソースを優先的に選択して在庫の販売促進を図ることが可能である。また、自動的に決定したリソースの組み合わせを利用直前までユーザに対して秘匿しておくことで、リソースの利用に対する意外性や期待感をユーザに対して提供することも可能である。

そして、複数の結合条件の選択や、最終的なリソースの組み合わせの決定の際には、組み合わせられたリソース毎の在庫数や結合条件毎の在庫数などを含む各種のパラメータによってウェイトを設定して重み付けし、優先順位の高いものから販売するようにすることで、効率的、効果的に在庫の販売促進を行うことが可能である。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

具体的には、例えば上記の実施の形態では、複数種類のリソースについて、結合条件として属性値が同じもの（例えば、行きの新幹線の到着駅と帰りの新幹線の出発駅）を組み合わせてリソースの組み合わせとして販売する場合を例としているが、このようなパターンに限られず、適宜他のパターンに応用、適用することができる。例えば、結合条件として属性値が同じではなくても、一定の関係や範囲にあるリソースであれば組み合わせることができるようにしてもよい。

また、上記の実施の形態では新幹線における行きと帰りという異なる種類のリソースの組み合わせについて在庫数の多いものから優先的、効率的に販売する場合について例として言及しているが、これに限らず、組み合わせて割り当てるべき異なるリソースを、リソースの在庫量に応じて適切に割り当てる他のシステムや方法にも適用することができる。例えば、新幹線に限らず航空便などの他の交通機関にも適用可能であるし、交通機関やレンタカーとホテル、ホテルとレストラン、英会話の講師とレッスン用の部屋、人材派遣会社における要員と派遣先、弁当とお茶、など幅広く適用することができる。また、２つのリソースの組み合わせに限らず、３つ以上のリソースの組み合わせにも応用することが可能である。

本発明は、利用期限が限定されている有限のリソースを割り当てるリソース割り当てシステムに利用可能である。

１…リソース割り当てシステム、
１０…リソース割り当てサーバ、１１…在庫管理部、１２…割り当て候補抽出部、１３…申込管理部、１４…在庫ＤＢ、１５…割り当て履歴ＤＢ、１６…ユーザＤＢ、１７…申込ＤＢ、
２０…リソース管理システム、２１…割り当て処理部、２２…在庫ＤＢ、２３…割り当て履歴ＤＢ、
３０…ネットワーク、
４０…ユーザ端末

Claims (7)

1. 複数種類のリソースの組み合わせをユーザに割り当てるリソース割り当てシステムであって、
   リソースの在庫を保持する在庫記録部と、
   情報処理端末を介したユーザからのリソースの割り当てに係る条件の入力を受け付けて、前記条件に合致する各種類のリソース候補の情報を前記在庫記録部から取得し、前記リソース候補の組み合わせの条件となる結合条件の中から所定の数を結合条件候補として抽出し、前記条件で指定された前記結合条件候補によって組み合わせられる前記リソース候補の組み合わせの中から所定の基準に基づいて所定の数を選択して、これを前記ユーザに割り当てるリソースの組み合わせ候補とする割り当て候補抽出部と、
   を有し、
   前記結合条件は、２つ以上の前記各リソース候補の属性値が互いに同じ又は一定の関係や範囲にあることであり、
   前記割り当て候補抽出部は、所定の数の前記結合条件候補を抽出する際に、前記各結合条件に対して、前記結合条件毎の属性、各種類のリソースに対する前記ユーザの利用希望日に係る情報、および前記ユーザの属性のうち少なくともいずれか１つ以上を含むパラメータにつきウェイトを設定して重み付けを行って抽出する、リソース割り当てシステム。
2. 請求項１に記載のリソース割り当てシステムにおいて、
   前記割り当て候補抽出部は、前記リソースの組み合わせ候補を選択する際、前記各リソース候補の組み合わせに対してウェイトを設定して重み付けを行って選択する、リソース割り当てシステム。
3. 請求項２に記載のリソース割り当てシステムにおいて、
   前記ウェイトは、対象の前記リソース候補の組み合わせに係る各リソース候補のそれぞれの在庫数のうち、少ない方の在庫数に基づいて設定する、リソース割り当てシステム。
4. 請求項２に記載のリソース割り当てシステムにおいて、
   前記ウェイトは、前記各リソース候補の組み合わせに対応する前記結合条件候補毎の在庫数に基づいて設定される結合条件毎ウェイトと、対象の前記結合条件候補内での前記各リソース候補の組み合わせの在庫数に基づいて設定される結合条件内組み合わせ毎ウェイトとの乗算に基づいて設定する、リソース割り当てシステム。
5. 請求項４に記載のリソース割り当てシステムにおいて、
   前記結合条件毎ウェイトは、前記結合条件候補に係る全ての前記リソース候補の組み合わせにつき、各リソース候補のそれぞれの在庫数の合計のうち、少ない方の在庫数に基づいて設定する、リソース割り当てシステム。
6. 請求項４に記載のリソース割り当てシステムにおいて、
   前記結合条件内組み合わせ毎ウェイトは、対象の前記結合条件候補に係る前記各リソース候補の組み合わせにつき、各リソース候補のそれぞれの在庫数を乗算した値に基づいて設定する、リソース割り当てシステム。
7. 請求項１に記載のリソース割り当てシステムにおいて、
   前記割り当て候補抽出部は、前記ユーザからの前記条件の入力に対して第１の応答を行った後、所定の期間内に前記ユーザから再度同じ前記条件の入力を受け付けた場合、再度前記第１の応答を行う、リソース割り当てシステム。
   

Images