以下、本発明の実施の形態を、図面を参照しつつ説明する。図1は本発明の実施形態に係るマッチングシステム1の概要を説明する図である。
本発明に係るマッチングシステム1には、インターネットなどの通信ネットワークNに接続された情報処理装置20と、当該情報処理装置20で実行・処理されるプログラムとを用いて構成することができる。情報処理装置20としては、データの送受信を行う通信部と、データの演算処理を行う演算処理部と、データを記憶する記憶部と、データの表示を行うデータ表示部などを有している、現在広く普及しているパーソナルコンピューターやサーバーなどを用いることができる。もちろん、パーソナルコンピューター、サーバー以外の情報処理装置20を適宜利用するようにしてもよい。
マッチングシステム1に用いられる情報処理装置20は、上記のように記憶部を有しており、この記憶部には複数のデータベース(DB)が記憶されている(吹き出し部参照)。データベース(DB)に記憶されているデータは、本発明に係るマッチングシステム1の処理で参照されたり、或いは、本発明に係るマッチングシステム1の処理を通じて、データベース(DB)にデータが書き込まれたりする。
上記のように複数のデータベース(DB)が記憶される情報処理装置20で構成される本発明に係るマッチングシステム1は、複数のサイズがある商品を提供する企業側と、企業が提供する商品の購入を検討・希望するユーザー側との間のマッチングを行うシステムである。特に、本発明に係るマッチングシステム1は、ユーザーにとって最適なサイズの商品を選択する際の支援を行うことが目的である。
本発明に係るマッチングシステム1においては、企業側は通信ネットワークNを介して商品情報を提供し、かつ、商品の販売を行うことが想定されている。このために用いられるのが、個々の企業が保有する情報処理装置70である。図1においては、これらは企業側端末群として示されている。企業が用いる情報処理装置70としても、パーソナルコンピューターやサーバーなどの任意のものを用いることができる。情報処理装置70は、通信回線Nと通信可能に接続されている。なお、図1には企業が用いる情報処理装置70として複数記載されているが、本発明に係るマッチングシステム1に参加する企業数が複数を前提としている分けではなく、単数の企業であっても構わない。
また、本発明に係るマッチングシステム1においては、企業が提供する商品の購入を検討・希望するユーザーは、自らが所有する情報処理装置50を用いて、本発明に係るマッチングシステム1に通信ネットワークNを介してアクセスすることが想定されている。複数のユーザーが所有している情報処理装置50は、図1においては、ユーザー側端末群として示されている。ユーザーが用いる情報処理装置50としては、パーソナルコンピューター、サーバー、スマートフォン、タブレット端末などの任意のものを用いることができる。情報処理装置50は、通信回線Nと通信可能に接続される。
本発明に係るマッチングシステム1では、企業が提供する商品としては「サイズ」などの、例えば大小の概念が存在する商品であることを前提としている。以下の実施形態では、本発明に係るマッチングシステム1で扱う商品の例として、サイズが複数ある衣服や指輪を挙げて説明するが、本発明に係るマッチングシステム1は、これ以外の商品―例えば、靴、家具など―も扱い得るものである。さらに、何らかの形での数値化を行うことが可能であれば、食品、化粧品なども扱い得るものである。
また、以下の実施形態では、本発明に係るマッチングシステム1では購買を対象とした商品を扱う例に基づいて説明を行うが、本発明に係るマッチングシステム1では、結婚式の貸し衣装などレンタルを対象とした商品を扱うようにしてもよい。
また、本発明に係るマッチングシステム1は、ネットショッピングにおける商品選定のためのみならず、ネットオークションにおける商品選定のためにも供することが可能である。
企業は衣服など、複数のサイズが存在しその中から適切なサイズのものが選択される商品を、通信ネットワークNを介して、ユーザーに販売することを意図している。本発明に係るマッチングシステム1では、このような企業が販売しようとする商品のデータが記録されたデータベースを有している。このデータベースを商品データベースDB2と称する。
一方、ユーザーは自らが所有する情報処理装置50によって、商品データベースDB2から抽出された商品を参照し、商品を選定する。この時、本発明に係るマッチングシステム1では、ユーザーにとって適正なサイズ選択の支援を行う。
本発明に係るマッチングシステム1では、ユーザーが商品を注文する際、適切なサイズを選択する上で、参考とされる基準となる商品(以下、「基準商品」という。また、特にこの基準商品が衣服の場合には「基準服」という。)の設定がされている。このような基準商品は、1つの商品のカテゴリーに複数設定されていることが好ましい。本発明に係るマッチングシステム1を構成する情報処理装置20は、これら基準商品に関するデータが記憶されるデータベースを有している。このようなデータベースが、基準服(基準商品)データベースDB1である。
なお、本明細書においては、理解の便のために、基準服(基準商品)データベースDB1と商品データベースDB2とを区別して説明するが、商品データベースDB2の中に、基準服(基準商品)データベースDB1の内容が含まれたようなデータ構造とすることもできる。
図2は本発明の実施形態に係るマッチングシステム1の基準服(基準商品)データベースDB1のデータ構造例を示す図である。
基準服(基準商品)データベースDB1に記憶される基準服(基準商品)を提供する企業(企業としては、メーカーであっても、商社などの販売会社であってもよい)は複数であることが好ましい。基準服(基準商品)を提供する企業の企業名は、基準服(基準商品)データベースDB1の項目名の1つとされている。例えば、図2の基準服(基準商品)データベースDB1の例では、企業名として「A社」、「B社」、「C社」、「D社」、・・・が記録されている。
また、基準服(基準商品)データベースDB1には、複数のカテゴリーに関するデータが記憶されている。そして、1つの商品カテゴリーの下には、複数の基準服(基準商品)に係るデータが記憶される構造となっている。ここでは、基準商品として基準服を想定しており、例えば、図2の基準服(基準商品)データベースDB1の例では、カテゴリーとして「コート」、「ワイシャツ」、「ポロシャツ」、「スラックス」、・・・が記録されている。
なお、「コート」、「ワイシャツ」、「ポロシャツ」、「スラックス」、・・・などの商品のカテゴリーの名称は、同種類と目される商品の分類時の項目名である、ということができる。本発明に係るマッチングシステム1で用い得る商品のカテゴリーの名称は、特にこれらに限定されるわけではない。
また、基準服(基準商品)データベースDB1には、基準服(基準商品)の型番に関するデータが記憶されている。例えば、図2の基準服(基準商品)データベースDB1の例では、型番として「EEEE」、「FFFF」、「GGGG」、「HHHH」、・・・が記録されている。
また、基準服(基準商品)データベースDB1には、基準服(基準商品)のサイズに関するデータが記憶されている。例えば、図2の基準服(基準商品)データベースDB1の例では、サイズとして「XS」、「S」、「M」、「L」、・・・が記録されている。
本実施形態では、「企業名」、「カテゴリー」、「型番」、「サイズ」の個々が一意に決まると、1つの基準服が決定する。そして、当該1つの基準服に対する情報としてa[i]が記述されている。iは自然数の変数である。iのそれぞれに対応した項目には基準サイズに関する情報が記述されている。本例(ポロシャツ)では、i=1〜4までの項目があり、それぞれ毎に基準サイズが記述されている。なお、nはiが取り得る最大の自然数であり、本例(ポロシャツ)の例ではn=4である。
図2の例では、a[1]の項目は「首周り基準寸法」で基準寸法値として「40cm」が、また、a[2]の項目は「裄丈基準寸法」で基準寸法値として「83cm」が、また、a[3]の項目は「胸囲基準寸法」で基準寸法値として「88cm」が、また、a[4]の項目は「胴囲基準寸法」で基準寸法値として「82cm」が記憶されている。
また、前記の1つの基準服に対する情報には、画像データ(・・・.jpg)が含まれていることが好ましい。
ユーザーは、新たな商品を注文とする際のサイズを選定するための基準商品として、以上のように構成される基準服(基準商品)データベースDB1から、基準服を選択して、当該基準服からの差分を入力する。一方、本発明に係るマッチングシステム1では、当該基準服からの差分を受信すると、商品データベースDB2から、ユーザーが所望とするサイズ感の商品を抽出して、抽出した商品をユーザーに対して提示する仕組みとなっている。
次に、商品データベースDB2について説明する。図3は本発明の実施形態に係るマッチングシステム1の商品データベースDB2のデータ構造例を示す図である。
商品データベースDB2は、複数のカテゴリーに関するデータが記憶されている。そして、1つの商品カテゴリーの下には、複数の商品に係るデータが記憶される構造となっている。本例におけるカテゴリーとしては、「ポロシャツ」、「コート」、「ワイシャツ」、・・・が記録されている。そして、例えば「ポロシャツ」の商品カテゴリーの下に、実際の商品群が記憶される構造となっている。
それぞれの商品カテゴリーの下には、個々の商品(この場合は、ポロシャツ)に関する情報としてA[j][i]が記述されている。ここで、jは自然数の変数であり、商品の固有(ID)番号である。
また、iは自然数の変数であり、a[i]におけるiと同様の変数である。A[j][i]には、固有番号がjである商品の、iに対応した項目のサイズ情報が記述されている。
カテゴリーがポロシャツである場合は、i=1〜4までの項目があり、A[j][1]には固有番号がjである商品の「首周り寸法」が、また、A[j][2]には同商品の「裄丈寸法」が、また、A[j][3]には同商品の「胸囲寸法」が、また、A[j][4]には同商品の「胴囲寸法」が記憶されている。
また、商品データベースDB2には、固有番号がjである商品のデータとして、さらに「企業名」、「型番」、そして同商品の画像データがjに対応付けられて記憶されている。
次に、本発明に係るマッチングシステム1でユーザーに関する情報として記憶されているユーザーアカウントデータベースDB3について説明する。このようなユーザーアカウントデータベースDB3に登録される情報は、個々のユーザーが各自の情報処理装置50から情報をアップロードすることで構成されるものである。
図4は本発明の実施形態に係るマッチングシステム1のユーザーアカウントデータベースDB3及びユーザー要求データベースDB5のデータ構造例を示す図である。本発明に係るマッチングシステム1のユーザーアカウントデータベースDB3には、それぞれのユーザーの「ユーザーアカウントID」、「メールアドレス」、「パスワード」、「氏名」、「性別」、「生年月日」、「住所」、「電話番号」、・・・などの各項目のデータが記憶されている。このようなユーザーアカウントデータベースDB3の構築のための技術には従来周知のものを用いることができる。
上記のようなユーザーアカウントデータベースDB3に登録されているユーザーが、本発明に係るマッチングシステム1を利用して商品選定・購入などを行った際に履歴として残るデータが、ユーザー要求データベースDB5に保存される。ユーザー要求データベースDB5に保存されるシステムの利用履歴データは、ユーザーアカウントデータベースDB3のアカウントデータと紐付けされている。
図4に示す例では、ある日時に、ポロシャツの商品カテゴリーで、基準服としてB社の型番EEEEのものを用いたこととが利用履歴データに登録されていることが示されている。また、基準寸法(基準データ)であるa[1]〜a[4](このデータは既に基準服(基準商品)データベースDB1登録済み)に対して、ユーザーによって、差分データとしてd[1]〜d[4]が入力され、優先度データとしてW[1]〜W[4]が入力されたことが利用履歴データに登録される。差分データd[i]は基準データからの差分を示すユーザーが入力するデータである。優先度データW[i]は、複数の寸法項目が、どのような優先度であるかを示すデータであり、ユーザーが入力するデータである。
また、ユーザー要求データベースDB5の個々のレコード(利用履歴データ)には、ユーザーが実際に注文したり、或いは逆注文を行ったりした場合の記録も残される。「逆注文」自体については後に説明するが、ユーザーが実際に注文した場合には「注文フラグ」に1がたち、逆注文を行った場合には「逆注文フラグ」に1がたつようにされている。また、注文を行った場合には、注文を行った商品に係る情報(商品の固有番号、ID番号j)についても、利用履歴データに残されるようになっている。
ところで、上記のように構成されているユーザー要求データベースDB5に蓄積されていくデータは、個別のユーザーに対するメールなどによる広告、或いは、プッシュ型による広告を行う際の基礎となるデータとして有効活用することができる。本発明に係るマッチングシステム1で蓄積されたユーザー要求データベースDB5に基づいて、ユーザーに送信・配信されるメールや広告を、広告情報と称する。
上記のようなユーザーに関連するデータベースの他に、本発明に係るマッチングシステム1においては、企業の情報が収録されてなるデータベースも構築される。次に、企業側のデータベースである企業アカウントデータベースDB4について説明する。
図5は本発明の実施形態に係るマッチングシステム1の企業アカウントデータベースDB4のデータ構造例を示す図である。本発明に係るマッチングシステム1の企業アカウントデータベースDB4には、それぞれの企業の「企業アカウントID」、「メールアドレス」、「パスワード」、「法人名」、「住所」、「電話番号」、・・・などの各項目のデータが記憶されている。このような企業アカウントデータベースDB4の構築のための技術には従来周知のものを用いることができる。
図5に示す企業アカウントデータベースDB4に登録される企業は、企業が提供する商品に関する情報を、本発明に係るマッチングシステム1の商品データベースDB2に登録し、ユーザーからのアクセス数を増大させることで、商品の売り上げの向上を期待することができる。
このために企業は、企業アカウントデータベースDB4に紐付ける形で、商品データベースDB2に自らの商品情報をアップロードすることが求められる。このようなアップロードのためのフォーマットの一例が図6に示すものである。なお、企業が商品情報をアップロードする際には、企業に対して適宜課金を行うことも望ましい実施形態である。
図6は商品データベースDB2へのデータ登録のためにマッチングシステム1に送信されるデータ構造例を示す図である。ここでは、ある企業が商品であるポロシャツの登録を行う際に、本発明に係るマッチングシステム1に送信するデータを示している。
図6に示すように、当該企業の企業アカウントIDに係るヘッダー情報の下には、xを仮の変数として登録されるべきデータA[x][1]には商品の「首周り寸法」が「41cm」であることが、また、A[x][2]には同商品の「裄丈寸法」が」「83cm」であることが、また、A[x][3]には同商品の「胸囲寸法」が「90cm」であることが、また、A[x][4]には同商品の「胴囲寸法」が「81cm」であることが記憶されている。また、同ヘッダー情報の下には、型番や画像データに係る情報も記述される。各企業は、例えば、このようなフォーマットによって本発明に係るマッチングシステム1にデータ送信を行う。なお、このようなアップロードのためのデータフォーマットとして、表計算ソフトウエアであるエクセル(登録商標)などのワークシートを用いるようにすると、ハンドリングがしやすい。
また、商品データベースDB2への商品データの登録は、企業が保有する情報処理装置70からのアップロードである必要は必ずしもなく、マッチングシステム1に用いられる情報処理装置20によって行うことも可能である。
図7は企業から送信されるデータの商品データベースDB2への追加・登録を説明する図である。図6で示すようなフォーマットで送信されたデータを、マッチングシステム1が受信すると、商品カテゴリーがデータから抽出され、さらに新たな固有番号であるj’が発行される。続いて、ヘッダー情報から「企業名」などの情報が抽出され、商品データベースDB2の追加・登録可能なフォーマット(図3と同様のフォーマット)とされた後に、商品データベースDB2に記録される。
次に、顧客評価データベースDB6について説明する。図8は本発明の実施形態に係るマッチングシステム1の顧客評価データベースDB6のデータ構造例を示す図である。
本発明に係るマッチングシステム1では、ユーザーは商品データベースDB2から抽出された商品を参照し、商品を選定するが、この抽出の際には、これまでの購入者の評価も反映されるようにしている。このために、本発明に係るマッチングシステム1では、顧客による評価データを蓄積することができる顧客評価データベースDB6が準備されている。
まず、商品データベースDB2には、個々の商品に関する情報としてA[j][i]が記述されていることは説明した。このA[j][i]に対しては、記録項目B[j]、b[j]及びg[kj]が、紐付けられることで付加されている。
B[j]は、固有(ID)番号jの商品が販売された総数を計数するカウンタである。イメージをつけるために一例として、販売数が5000であったことと仮定する。
また、b[j]は、販売された固有(ID)番号jの商品に対して、ユーザーから受け付けたフィードバックの件数を計数するカウンタである。ここで、b[j]をカウントする際には、固有(ID)番号jの商品を購入した実績のあるユーザーからのフィードバックのみをカウントするようにシステムを構成する。
イメージをつけるために一例として、フィードバック数が50件であったことと仮定する。固有(ID)番号jの商品にとって、最新のフィードバックを第kj番目のフィードバックとしてカウントする。本例では、kj=50である。
Σg[p]は評価積算カウンタと称し、フィードバックの際におけるユーザーの点数付けを累積したものである。点数付けの一例として、商品のフィット感の評価を挙げている。例えば、「ほぼ満足」は1点、「やや満足」は2点、「不満」は3点、「非常に不満」は4点として積算が行われる。g[p]は、第p番目のフィードバックユーザーによる点数付けを表すものである。本例の点数付けによれば、g[p]は、1、2、3、4のいずれかの値をとることになる。
顧客評価データベースDB6では、固有(ID)番号jの商品のg[1]、g[2]、・・・、g[p]、・・・、g[kj]及び、これらの値の総和をG値(より詳しくはG[j]値)と称し、蓄積するようにしている。
なお、顧客評価データベースDB6を作成する際の基礎となる商品の販売数の計数や、フィードバック件数の計数や、ユーザー評価の積算のアルゴリズムには従来周知のものを適宜利用することができる。
また、本実施形態では、「ほぼ満足」、「やや満足」などのあらかじめ定められた選択肢と、その選択肢に対応する点数によって、フィードバックユーザーによる点数付けを行うようにしていたが、本発明に係るマッチングシステム1がこれに限定されるものではない。例えば、フィードバックユーザーからマッチングシステム1が受信するデータ項目には、コメント欄などを設けておき、当該コメント欄中の記載内容(テキストデータ)を言語解析技術によって、当該記載内容(テキストデータ)に対応する点数を算出し、算出された点数によって、フィードバックユーザーによる点数付けを行うようにしてもよい。ここで、前者の選択肢に基づく点数付けの方法と、後者のコメント欄に基づく点数付けの方法と、は併用するようにしてもよい。
また、本実施形態においては、フィードバックユーザーによる点数付けは、商品全体としてのフィット感の評価のみを対象とする例につき説明したが、本発明に係るマッチングシステム1では、商品の個別部位などそれぞれのフィット感の評価の点数付けがフィードバックされる構成とすることもできる。
次に、以上のような各データベースを有する本発明に係るマッチングシステム1の処理について説明する。図9は本発明の実施形態に係るマッチングシステム1のメイン処理のフローチャートを示す図である。なお、以下のフローチャートの説明では、適宜ユーザーインターフェイス画面を参照しながら説明を行うが、例えば、ユーザーインターフェイス画面における「戻る」ボタンに対応したステップなどについては、本流の処理からは外れるものであるので、フローチャートには記載されていない。本明細書では、このような方針の下で作成されたフローチャートが示されている。
また、以下のフローチャートにおいて、データベースの検索などは情報処理装置20側が担い、ユーザーインターフェイス画面における表示などは、ユーザー側の情報処理装置50が主として実行する処理である。いずれにしても、情報処理装置20とユーザー側の情報処理装置50とは、通信ネットワークNを介してデータの送受が可能とされており、本明細書におけるフローチャートによる処理は両情報処理装置が協働して実行するものであると考えることができる。
図9において、ステップS100でマッチングシステムのメイン処理が開始されると続いて、ステップS101に進む。
ステップS101においては、ユーザーに対して、どの基準服(基準商品)を尺度として購入する商品を選択したいかを決めてもらうべく、ユーザーに対して基準服(基準商品)の検索条件の入力を促す処理が実行される。
図10はこのようなステップで用いられるユーザーインターフェイス画面の一例を示すものである。このユーザーインターフェイス画面では、「企業名」、「カテゴリー」、「型番」、「サイズ」の各項目の選択欄が設けられている。また、ユーザーインターフェイス画面では、各項目の選択欄にはプルダウンメニューが設定されており、ユーザーがカーソルCの操作を行うことで各項目の選択欄に所望とする情報を入力することができるようにされている。
図10の例では、ユーザーは「カテゴリー」の選択欄で、「ポロシャツ」の検索条件をカーソルCで設定している様子を示している。上記のようなユーザーによる入力によって、ステップS102では、基準服(基準商品)を検索するための条件の設定が完了する。
続く、ステップS103では、ステップS102で設定された検索条件に基づいて基準服(基準商品)データベースDB1の検索が実行される。次のステップS104では、基準服(基準商品)データベースDB1の検索によって抽出された基準服(基準商品)を表示する。図11は、このようなステップで実行される基準服(基準商品)の検索結果の表示画面の一例である。
図11では、基準服の検索条件として「企業名」は「B社」、「型番」は「EEEE」、「カテゴリー」は「ポロシャツ」、「サイズ」は「M」が選択された場合の検索結果であることを示している。また、図11の表示画面においては、検索の結果抽出された基準服の画像、及びこの基準服の各基準寸法(これを、「基準データ」とも言う。)が示されている。本例では、基準服における「首周り」の基準寸法が「40cm」であり、「裄丈」の基準寸法が「83cm」であり、「胸囲」の基準寸法が「88cm」であり、「胴囲」の基準寸法が「82cm」である。
続くステップS105では、上記のようにして選択された基準服(基準商品)からの差分入力をユーザーに対して促す。差分とは、基準服における基準寸法とユーザーが所望とする寸法との間の差であり、本明細書ではこのような差分を、「差分データ」や「d値」或いは「差分値」などとも言う。
図12はステップ105で用いられるユーザーインターフェイス画面の一例を示すものである。このようなユーザーインターフェイス画面では、ポロシャツの画像と、このポロシャツの画像中のどの部位の寸法が、参照すべき寸法であるのかが明示されていることが好ましい。例えば、図12の例では、画像中に「首周り」の寸法が(1)に相当する部位であること、「裄丈」の寸法が(2)に相当する部位であること、「胸囲」の寸法が(3)に相当する部位であること、「胴囲」の寸法が(4)に相当する部位であることが示されている。
また、図12のユーザーインターフェイス画面では、「首周り」、「裄丈」、「胸囲」、「胴囲」の各基準寸法(基準データ)からの差分値(差分データ)の入力欄が設けられている。各差分値の入力欄にはプルダウンメニューが設定されており、ユーザーがカーソルCの操作を行うことで各項目の選択欄に所望とする差分値を入力することができるようにされている。
図12の例では、ユーザーは「胴囲」の入力欄で、「−1cm」の差分値の入力設定をカーソルCで行っている様子を示している。上記のようなユーザーによる入力によって、ステップS105では、基準服(基準商品)の基準寸法からの差分値の入力が完了する。
続く、ステップS106では、図12に示すようなユーザーインターフェイス画面で収集された情報が、マッチングシステム1を構成する情報処理装置20側に送信され、ユーザーの基準値毎に対する差分(d値)の設定が行われる。
続くステップS107では、寸法毎の優先度入力をユーザーに対して促す。例えば、ポロシャツの場合、寸法項目として(1)「首周り」、(2)「裄丈」、(3)「胸囲」、(4)「胴囲」の4種類が存在するが、ユーザーはそれらの寸法項目のうち最重要視する順から下位へと順位付けを行うことが求められる。
図13はステップ107で用いられるユーザーインターフェイス画面の一例を示すものである。本ユーザーインターフェイス画面においても、ポロシャツの画像と、このポロシャツの画像中のどの部位の寸法項目が、参照すべき寸法項目であるのかが明示されていることが好ましい。例えば、図13の例では、画像中に「首周り」の寸法項目が(1)に相当する部位であること、「裄丈」の寸法項目が(2)に相当する部位であること、「胸囲」の寸法項目が(3)に相当する部位であること、「胴囲」の寸法項目が(4)に相当する部位であることが示されている。
また、図13のユーザーインターフェイス画面では、(1)「首周り」、(2)「裄丈」、(3)「胸囲」、(4)「胴囲」の各部位の寸法項目の優先度の入力を行う入力欄が設けられている。各寸法項目の入力欄にはプルダウンメニューが設定されており、ユーザーがカーソルCの操作を行うことで各寸法項目の入力欄に所望とする優先度を入力することができるようにされている。
図13の例では、ユーザーは(4)「胴囲」の入力欄において「胴囲」の優先度が「3位」であることをカーソルCによって設定している様子を示している。上記のようなユーザーによる入力によって、ステップS107では、各寸法項目のユーザーにとっての優先度の入力が完了する。
続く、ステップS108では、図13に示すようなユーザーインターフェイス画面で収集された情報が、マッチングシステム1を構成する情報処理装置20側に送信され、ユーザーの寸法項目毎の優先度の設定が行われる。
ここで、上記のように設定される寸法項目の優先度を示す値をW値と称する。さらに、前述したiを用いて一般化すると、W[i]は、各寸法項目ごとにユーザーが設定する優先度である、ということができる。
なお、本実施形態では、寸法項目毎の優先度の設定を、ユーザーが行うような構成としているが、デフォルト値によって予め優先度を設定するような構成とすることもできる。このような場合には、ステップS107、ステップS108は省略される。
続く、ステップS109においては、D値として定義する値を算出し、D値が小さい順に、商品データベースDB2をソートして、このソート結果に基づいた表示を行う。なお、以下に説明するD値の算出方法は、あくまで一例であることを付言しておく。D値はより一般的な表記を行うと、前述したj(商品の固有(ID)番号)を用いて、D[j]と表記することができる。すなわち、D[j]はjの関数であり、商品毎に算出される値であることがわかる。また、D[j]は、あるユーザーにとっての所望(理想)とする寸法値からの、個別の商品毎の乖離度を示す数値である。このD[j]が小さい値であればあるほど、基本的に、ユーザーにとっては寸法の観点からより所望(理想)とする商品に近いものであるといえる。
このようなD[j]は下式(1)によって算出することができる。
K1、K2は重み付けを行うための所定の定数(ただし、K1≧0、K2≧0)であり、D’[j]は下式(2)よって、また、AveG[j]は下式(3)によって算出することができる。
D’[j]の算出のための(2)式において、nはiが取り得る最大の自然数であり、これまで例示してきたポロシャツの例ではn=4である。
また、(2)式において、W[i]は、ユーザーによって入力される優先度データであり、複数の寸法項目が、どのような優先度であるかを示すものである。図14は、ポロシャツを例としたときに、ユーザーによって設定されるW値の例を示す図である。W値は、優先度が数値化されていれば、どのようなものを用いてもよいが、本例では、優先度が高い順から4/4、3/4、2/4、1/4とされている。
また、(2)式において、H[i]は、各寸法項目間の尺度を補正する係数である。このような係数は、寸法項目毎に予め決められていることが想定されている。図15は、ポロシャツを例としたときに、寸法項目毎に設定されるH値の例を示す図である。H値は、各寸法項目同士が比較対象となり得るよう補正を行う係数であればどのようなものを用いてもよいが、本例では、基準データである基準寸法の逆数が用いられている。すなわち、本例では、「首周り用補正係数」(H[1])として1/40が、また、「裄丈用補正係数」(H[2])として1/83が、また、「胸囲用補正係数」(H[3])として1/88が、また、「胴囲用補正係数」(H[4])として1/82が用いられるように設定されている。
また、(2)式において、A[j][i]は、固有(ID)番号jを有する商品の寸法項目ごと(i=1〜n)の値である。説明している固有番号がjであるポロシャツ(i=1〜4)を例にとれば、A[j][1]は「首周り寸法」であり、A[j][2]は「裄丈寸法」であり、A[j][3]は「胸囲寸法」であり、A[j][4]は「胴囲寸法」である。
以上のように算出される(2)式のD’[j]は、固有(ID)番号jを有する商品のサイズが、基本的にユーザーが所望するサイズに近ければ近いほど、小さい値を取ることとなる。これに重み付けのための定数K1が乗ぜられた(1)式の第1項K1×D’[j]も、当該商品のサイズが、ユーザーが所望するサイズに近ければ近いほど、小さい値となる。
また、(2)式において、a[i]は、基準服(基準商品)の基準寸法項目ごと(i=1〜n)の値(基準寸法値)である。n=4であるポロシャツの場合、a[1]は「首周り」の首周り基準寸法値(40cm)であり、a[2]は「裄丈」の首周り基準寸法値(83cm)であり、a[3]は「胸囲」の首周り基準寸法値(88cm)であり、a[4]は胴囲」の首周り基準寸法値(82cm)である。
また、(2)式において、d[i]は、ユーザーによって入力された基準データからの差分を示す差分データである。従って、(a[i]+d[i])の値は、ユーザーにとって寸法項目毎の所望とする寸法値である、ということができる。
また、(3)式において、g[p]は、第p番目のフィードバックユーザーによる点数付けを表すものであり、顧客評価データベースDB6に登録されているものである。
AveG[j]は、最初のフィードバックユーザーによる点数付けg[1]から、最後の第kj番目のフィードバックユーザーによる点数付けg[kj]までの二乗和のルートをとり、さらにこれをkjで除したものである。AveG[j]は、G値の平均値的な値であるものと考えることができる。
以上のように算出される(3)式のAveG[j]は、ユーザーによるフィードバックの際のフィット感の評価が高ければ高いほど、小さい値を取ることとなる。これに重み付けのための定数K2が乗ぜられた(2)式の第2項K2×AveG[j]も、当該商品のサイズに関するこれまでの評価(フィット感について評価)が、高ければ高いほど、小さい値を取る。
例えば、(1)式において、K1=1に設定し、K2=0に設定すると、D[j]は固有(ID)番号jを有する商品のサイズが、ユーザーが所望するサイズに近いか否かという観点のみを表す数値となる。すなわち、ユーザーによって入力された差分データのみから、商品データベースDB2に登録されている個別の商品毎の乖離度を示す数値であるD[j]を算出するパターンとなる。(前者の例、という。)
一方、例えば、(1)式において、K1=1に設定し、K2=1に設定すると、D[j]は固有(ID)番号jを有する商品のサイズが、ユーザーが所望するサイズに近いか否かという第1の観点と、これまでのフィット感の評価が高いか否かという第2の観点の双方が加味された数値となる。(後者の例、という。)
ユーザーによって入力された差分データのみから、商品データベースDB2に登録されている個別の商品毎の乖離度を示す数値であるD[j]を算出するようにする(前者の例)と、企業側の商品提供時の努力や、企業によって提供される商品に対する評価が反映されない形で、商品の順位付けが行われてしまう、という課題が生じてしまうこととなる。そこで、本発明では、重み付けのための定数K1、K2を適宜変更することで、このような課題を解決するようにしている。
後者の例のような設定とすれば、企業によって提供される商品に対する評価(フィット感の評価)が反映された形で乖離度D[j]が算出され、さらにこの乖離度D[j]に基づいて、商品の順位付けが行われ、ユーザーに商品情報が提供される。これにより、自らの商品の順位付けを落としたくない企業の自助努力を促すことが可能となり、ユーザーにとっての利益が増大する。また、K2の値を大きく設定することは、企業側の商品提供時の企業努力が足りない分に対するペナルティー的な意味合いを含んでいる。
なお、K2などの定数は、時間(例えば、日数)の経過に応じて漸減する関数としておくことで、乖離度D[j]が大きくなってしまうペナルティーを日数の経過によって、緩和するようにもできる。
以上のように、本発明に係るマッチングシステム1によれば、ユーザーは、基本的に、基準服(基準商品)からの差分データに基づいて、候補となる商品が抽出され提示を受けるようになっていることから、ユーザーがイメージする通りのサイズの商品を注文することができる可能性が極めて高くなる。
また、本発明に係るマッチングシステム1によれば、サイズの相違が発生する確率が減り、商品の返品や交換といった無駄の発生を抑制することができる。
また、本発明に係るマッチングシステムによれば、企業サイドは、ユーザーの要求を把握した上で商品等を製造することが可能となり、無駄な生産や在庫を抑制することができる。
また、本発明に係るマッチングシステム1によれば、購入時においてサイズが完全に合致する商品でなかったとしても、ユーザーは自らの許容範囲内で購入を決定することとなるので、ユーザーにとっては納得のいく商品の購入を行うことが可能となる。
ステップS109では、固有(ID)番号jの商品毎に、ユーザーにとっての乖離度であるD[j]が算出され、さらに、この算出されたD[j]の値が小さい順に、商品データベースDB2に記録されている商品のソートを行い、ソートした結果を表示する。このようなソート結果の表示は、ユーザーにとっては、商品データベースDB2に記録されている商品が、自ら所望とするサイズ順となるように検索・抽出された表示結果となる。図16は、このような商品の検索結果の表示画面の一例である。
図16のような表示画面では、例えば、UI1〜UI6の表示を設けることができる。UI1の表示欄においては、商品のソート結果の「順位」の項目、商品の「企業名」の項目、商品の「型番」の項目、全ての寸法項目における基準寸法から差分の和を示す「総合」の項目、商品の「首周り」の寸法項目、商品の「裄丈」の寸法項目、商品の「胸囲」の寸法項目、商品の「胴囲」の寸法項目を設けて、各商品を表示することができる。
UI2においては、UI1の表示欄においてカーソルCによって選択されている商品(ポロシャツ)に係るイメージ画像を表示することができる。このようなイメージ画像表示には、商品データベースDB2に記録されているものが用いられる。また、このようなイメージ画像表示においては、商品の画像を、人のシルエット画像に重ね合わせるようにしてもよい。
また、UI2の表示においては、サイズ的な特徴点について、バルーン表示を行うようにすることもできる。図16の例では、ポロシャツの画像の胸囲の部位からの吹き出しにより「胸囲:ゆとり」などの情報を表示するようにしている。このような情報は、基準データと、ユーザーによって入力された差分データと、商品の実際の寸法データとから算出することができる。
また、UI3においては、UI1の表示欄においてカーソルCによって選択されている商品(ポロシャツ)に係る情報を、レーダーチャートなどの視覚情報に基づいて表示することができる。図16の例では、全ての寸法項目における基準寸法から差分の和を示す「総合」の項目、商品の「首周り」の寸法項目、商品の「裄丈」の寸法項目、商品の「胸囲」の寸法項目、商品の「胴囲」の寸法項目の各項目における値に基づいて、描画されたレーダーチャートを表示している。
また、UI1の表示欄については、初期においては、ユーザーが入力した差分データのみに基づいて商品が検索・抽出されソートされた表示結果となっている。このようなソート結果以外のソートを行いたいというニーズもある。そこで、UI4は、他のソート方法の選択欄となっている。ソート方法の選択欄にはプルダウンメニューが設定されており、ユーザーがカーソルCの操作を行うことでの選択欄に所望とするソート方法を入力することができるようにされている。図示するように、ソート方法の条件には、「首周り」の差分データが小さい順、「裄丈」の差分データが小さい順、「胸囲」の差分データが小さい順、「胴囲」の差分データが小さい順、「企業名」の順などを含めることができる。
UI5は、UI1の表示欄においてカーソルCによって選択されている商品を注文する画面に移行する「注文へ」ボタンである。また、UI6は、逆注文を行いたい場合に押下する「逆注文へ」ボタンである。
さて、フローチャートに戻り、ステップS110に進むと、「注文処理」のサブルーチンが実行される。このようなサブルーチン処理は、例えば、先のUI5の「注文へ」ボタンが、カーソルCによって押下された場合に起動されるものである。
続く、ステップS111で、マッチングシステムのメイン処理を終了する。
次に、先のフローチャートにおける「注文処理」のサブルーチンについて説明する。図17は本発明の実施形態に係るマッチングシステム1の注文処理のサブルーチンのフローチャートを示す図である。
ステップS200において、注文処理サブルーチンが開始されると、続いて、ステップS201 では、注文がなされたか否かが判定される。すなわち、ステップS201では、UI5の「注文へ」ボタンが押下されたか、UI6の「逆注文へ」ボタンが押下されたか判定される。
ステップS201にける判定がYESの場合、すなわち、UI5の「注文へ」ボタンが押下された場合には、ステップS220に進み、注文手続き処理ルーチンが実行される。このような注文手続き処理ルーチンに進むと、UI1の表示欄においてカーソルCによって選択されている商品の注文手続きが実行される。なお、注文手続き処理ルーチンについては、一般的なネットショッピングで周知な処理であるので説明を省略する。
一方、ステップS201にける判定がNOの場合、すなわち、UI6の「逆注文へ」ボタンが押下された場合には、ステップS202に進み、逆注文条件データ作成し、これを表示することで、ユーザーに対して所定の入力を促すようにする。
ここで、本明細書において「逆注文」とは、買い手側が売り手側に対して購入条件を提示することで、取引を行う形態の注文を言う。この「逆注文」には競り下げの概念は含まれていない。ただし、本発明に係るマッチングシステム1では、競り下げの概念を含まない「逆注文」に代えて、競り下げの概念を含む「逆オークション」を行い得るように構成することもできる。
図18はステップ107で用いられるユーザーインターフェイス画面の一例を示すものである。図18に示すユーザーインターフェイス画面では、逆注文を行うための条件が設定される。
ユーザーインターフェイス画面では、ポロシャツの画像と、このポロシャツの画像中のどの部位の寸法が参照すべき寸法であるのかが表示され、さらに、逆注文の条件としては、(1)「首周り」の寸法値が41cmであり、(2)「裄丈」の寸法値が83cmであり、(3)「胸囲」の寸法値が90cmであり、(4)「胴囲」の寸法値が81cmであることが表示される。ここで、各寸法値は、(a[i]+d[i])の値が設定される。a[i]は、基準服における各寸法項目の基準データであり、d[i]は、ユーザーによって入力された基準データからの差分を示す差分データである。
また、ユーザーインターフェイス画面には、逆注文の条件として、ユーザーによって希望購入金額が入力される金額入力欄が設けられており、ユーザーはこの金額入力欄にキーボード(不図示)等で入力を行い希望する金額の設定を行うことが想定されている。また、ユーザーインターフェイス画面には、逆注文の条件として、ユーザーの希望納期が入力される希望納期欄が設けられており、プルダウンメニューによって希望納期欄の入力が行えるようになっている。
また、ユーザーインターフェイス画面には、「上記の条件で「ポロシャツ」メーカーに対して逆注文を実行します。」のメッセージと共に、「逆注文実行」のボタンなどが設けられている。この「逆注文実行」のボタンがカーソルCによって押下されると、ステップS203において、本発明に係るマッチングシステム1によって逆注文の実行が確認される。
次のステップS204では、図18に示すユーザーインターフェイス画面で設定された逆注文の条件を、企業アカウントデータベースDB4に登録されている企業側の情報処理装置70端末に送信する。これにより、各企業はユーザーの希望の条件を知ることができ、当該ユーザーに対する希望に応じることができる企業は、それに応えるようにする行動を起こすことが可能となる。ステップS205では、元のメインルーチンにリターンする。
本発明に係るマッチングシステム1は、ユーザー入力した差分データに基づいて、逆注文を行い得るようになっており、ユーザーにとっては希望するサイズ・及び金額の商品を入手できる可能性が極めて高くなる。
次に、本発明に係るマッチングシステム1におけるプレゼントモードについて説明する。知人に服やアクセサリーなどのサイズを選択しなければならないプレゼントをしたいが、その人に合っているサイズを知らない、一方、その人のメールアドレスについては知っている、というシチュエーションがある。本発明におけるプレゼントモードでは、このようなシチュエーションでも、プレゼントしたい人の合うサイズの服やアクセサリーをプレゼントすることを可能とするものである。
本発明に係るマッチングシステム1は、それぞれのユーザーのサイズ情報や注文履歴が収集されるユーザー要求データベースDB5を有している。そこで、本発明に係るマッチングシステム1では、このようなユーザー要求データベースDB5を利用することで、上記のようなシチュエーションにおけるニーズに応えるようにするものである。
図19は本発明の実施形態に係るマッチングシステム1のプレゼントモード処理のフローチャートを示す図である。
不図示のユーザーインターフェイス画面等をユーザーが操作することで、ステップS300でプレゼントモードの処理が開始されると、続いて、ステップS301では、ユーザーに対してプレゼントする相手の情報、及び、プレゼント品のカテゴリーの入力を促す処理が実行される。
図20はステップS301で用いられるユーザーインターフェイス画面の一例を示すものである。このようなユーザーインターフェイス画面において、ユーザーは、例えば、プレゼントする相手のメールアドレスを入力する。また、このようなユーザーインターフェイス画面には、プレゼントした商品の「カテゴリー」の選択欄が設けられている。選択欄にはプルダウンメニューが設定されており、ユーザーがカーソルCの操作を行うことで所望とするカテゴリー情報を入力することができるようにされている。図20の例では、ユーザーがカーソルCによって、「リング」のカテゴリーを選択している様子を示している。
上記のようなユーザーインターフェイス画面によって、ステップS302では、検索条件が設定され、これに基づいてユーザー要求データベースDB5の検索が実行される。
まず、ステップS303では、検索条件として入力されたメールアドレスやIDに基づくユーザーアカウント情報が存在するか否かが判定される。ステップS303の判定結果がNOであれば、ステップS309に進み、プレゼントモードを終了する。
一方、ステップS303の判定結果がYESであれば、ステップS304に進む。ステップS304では、検索条件で設定された商品のカテゴリーのサイズ情報が存在するか否かが判定される。すなわち、プレゼントする相手が過去に、当該カテゴリーの商品を購入したりしてそのサイズ情報がユーザー要求データベースDB5に存在するか否かが判定される。ステップS304の判定結果がNOであれば、ステップS309に進み、プレゼントモードを終了する。
ステップS304の判定結果がYESであれば、ステップS305に進み、続いて商品を提供する企業名(ブランド名)の入力を促す。図21はステップS304で用いられるユーザーインターフェイス画面の一例を示すものである。
このようなユーザーインターフェイス画面では、該当するカテゴリーの商品のサイズ情報がある旨を、ユーザーに報知すると共に、商品を提供する企業名を選択する選択欄が設けられている。
選択欄にはプルダウンメニューが設定されており、ユーザーがカーソルCの操作を行うことで所望とする企業名を入力することができるようにされている。図20の例では、ユーザーがカーソルCによって、「Q社」を選択している様子を示している。
図21に示すユーザーインターフェイス画面によって、企業名の検索条件が設定されると、続いて、ステップS306では、このような検索条件に基づいて、商品データベースDB2の検索が実行される。
ステップS307では、商品データベースDB2の検索結果が表示される。図22はステップS307によるユーザーインターフェイス画面の一例を示すものである。このユーザーインターフェイス画面では、Q社のリング3種類が、型番と画像情報と共に示されている。また、このユーザーインターフェイス画面では、画像の右隣のチェックボックスにーソルCによってチェックを入れて、「プレゼンの注文」ボタンを押下することで、ステップS308に進む。
ステップS308では、注文手続き処理が実行され、ステップS309で、プレゼントモード処理が終了される。なお、注文手続き処理については、一般的なネットショッピングで周知な処理であるので説明を省略する。
このように本発明に係るマッチングシステム1は、ユーザーのサイズ情報や注文履歴が記憶されるユーザー要求データベースDB5を有しているので、このような本発明に係るマッチングシステム1によれば、服やアクセサリーなどのサイズ情報を知らない相手に対しても、実サイズをプレゼント相手から聞き出すこともなく、気軽にプレゼントすることが可能となる。
なお、本発明に係るマッチングシステム1は、上記のように、ユーザーのサイズ情報や注文履歴が記憶されるユーザー要求データベースDB5を有しているために、前記プレゼントモードの他に、ユーザーのサイズに合致した商品(サイズは合っているが、デザインなどはわからない商品)が含まれた福袋のような形態での商品販売を行い得る取引モードも実現すること可能である。
次に、本発明の他の実施形態について説明する。本実施形態は、ユーザーインターフェイス画面の構成が異なるのみであるので、この画面の例示に基づいて説明を行う。これまで説明した実施形態では、1つのカテゴリーに属する商品のみをユーザーインターフェイス画面で表示するようにしていたが、本実施形態では、複数のカテゴリーに属する複数の商品を1つのユーザーインターフェイス画面で表示することができるようにされている。このようなユーザーインターフェイス画面へと導かれる前段の過程では、ユーザーがマッチングシステム1によって、複数の商品カテゴリーで商品の抽出を行ったことが前提となる。
図23は本発明の他の実施形態に係るマッチングシステム1のユーザーインターフェイス画面例を示す図である。図23の例では、UI1〜UI3の表示部において「キャップ」、「ポロシャツ」、「パンツ」のカテゴリーの個別商品のイメージ画像が表示されるようになっている。このようなイメージ画像の表示には、商品データベースDB2に記録されている画像データが用いられる。このようなイメージ画像表示においては、商品の画像を、人のシルエット画像に重ね合わせるようにしてもよい。
また、これらのイメージ画像表示の右側に配置された「変更」ボタンのUI4〜UI6の押下により、それぞれのカテゴリーにおいて表示させる個別商品の変更を行うようにすることが好ましい。このような構成により、本実施形態のユーザーインターフェイス画面によって、ユーザーはコーディネートのイメージを把握しつつ、注文などを実行することができる。
また、UI7の「注文」ボタンを、カーソルCによって押下することで、表示されている個別の商品を一括して購入する手続きに進めるように構成することも好ましい。
以上のような他の実施形態に係るマッチングシステム1によれば、ユーザーは複数の商品イメージを簡単に組み合わせてコーディネートが可能となり、無駄の少ない商品購入を行うことができるようになる。
以上、このような本発明に係るマッチングシステム1によれば、サイズの相違が発生する確率が減り、商品の返品や交換といった無駄の発生を抑制することができる。また、本発明に係るマッチングシステム1によれば、企業サイドは、ユーザーの要求を把握した上で商品等を製造することが可能となり、無駄な生産や在庫を抑制することができる。
また、本発明に係るマッチングシステム1によれば、購入時においてサイズが完全に合致する商品でなかったとしても、ユーザーは自らの許容範囲内で購入を決定することとなるので、ユーザーにとっては納得のいく商品の購入を行うことが可能となる。