(57)【要約】      （修正有）【課題】自分の空き時間枠を有効利用したい人と、他人の空き時間枠を利用したいと考える人とを、広告配信によって橋渡しをする広告配信システムを提供する。【解決手段】広告主が使用する広告主端末３およびユーザが使用するユーザ端末２と通信可能に接続するサーバ１が、広告主端末３から受信した情報に基づき広告配信先となるユーザの条件を設定する配信先ユーザ条件設定手段と、ユーザ端末２から受信したスケジュールを含むユーザ個人情報に基づいてユーザの特徴を分析するユーザプロフィール抽出手段と、設定されたユーザの条件とユーザの特徴とに基づき広告配信先のユーザを抽出する配信先ユーザ検索手段と、抽出されたユーザに広告を配信する広告文送信表示手段と、を備える。配信先ユーザ条件は、必須条件群、任意条件のアイテム群、及びアイテムごとに設定されたカテゴリー別重みの集合、から構成される。【選択図】図１
2016218654.tif 000002
【特許請求の範囲】
【請求項１】
広告主が使用する広告主端末およびユーザが使用するユーザ端末と通信可能に接続するサーバが、
前記広告主端末から受信した情報に基づき広告配信先となるユーザの条件を設定する配信先ユーザ条件設定手段と、
前記ユーザ端末から受信したスケジュールを含むユーザ個人情報に基づいてユーザの特徴を抽出するユーザプロフィール抽出手段と、
前記設定された条件と前記ユーザの特徴とに基づき広告配信先のユーザを抽出する配信先ユーザ検索手段と、
前記抽出されたユーザに広告を配信する広告文送信表示手段とを
備えることを特徴とする広告配信システム。
【請求項２】
前記配信先ユーザ条件は、必須条件群、任意条件のアイテム群、及びアイテムごとのカテゴリー別重みの集合、とから構成され、
前記配信先ユーザ検索手段は、先ず必須条件をすべて満たすユーザを選び、次に任意条件の各アイテムに重み付けした総和を算出して評価値とし、この評価値に基づき広告配信先を決定していくことを特徴とする請求項１に記載の広告配信システム。
【請求項３】
前記必須条件には、配信する広告に対応する日時と、ユーザのスケジュール上の空き時間枠とが一致することを含むことを特徴とする請求項２に記載の広告配信システム。
【請求項４】
前記広告文送信表示手段は、配信する広告を配信先のユーザのスケジュールに組み込んで当該ユーザのユーザ端末に送信することを特徴とする請求項１に記載の広告配信システム。
【請求項５】
前記配信先ユーザ検索手段は、前記配信される広告の広告主に対して公開が許可されているユーザの情報に基づいて配信先を抽出することを特徴とする請求項１に記載の広告配信システム。
【請求項６】
前記サーバは、配信広告諾否処理手段を備え、
前記配信広告諾否処理手段は、配信した広告に対する配信先ユーザの反応が「受諾」、「拒否」、「無回答」のいずれであるかを判定するとともに、前記配信された広告が所定時間内に閲覧されなかったときは「無関心」と判定し、
前記反応が「無関心」以外の場合は当該ユーザにアプローチ費を付与し、さらに「受諾」の場合はマッチング成立費を付与する
ことを特徴とする請求項１に記載の広告配信システム。
【請求項７】
前記配信広告諾否処理手段は、配信された広告に対する各ユーザの過去の履歴情報に基づいてアクティブ指数を算定し、
前記配信先ユーザ検索手段は、該アクティブ指数も勘案して広告配信先のユーザを抽出することを特徴とする請求項６に記載の広告配信システム。
【請求項８】
前記サーバは、配信先ユーザ条件のテンプレートを格納するデータベースを備え、
前記配信先ユーザ条件設定手段は、前記広告主端末から受信した情報を前記テンプレートにあてはめることを特徴とする請求項１〜３のいずれか１に記載の広告配信システム。
【請求項９】
前記サーバは、特徴抽出ルールを格納するデータベースを備え、
前記ユーザプロフィール抽出手段は、明示的あるいは黙示的なユーザ個人情報と前記特徴抽出ルールとから、ユーザプロフィールを抽出することを特徴とする請求項１に記載の広告配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自分の空き時間枠を有効利用したい人と、他人の空き時間枠を利用したいと考える人とを、広告配信によって橋渡しをする広告配信システムに関する。
【背景技術】
【０００２】
個人のスケジュールを管理するアプリケーションソフトが出回っている。ＳＮＳの普及もあいまって、このスケジュールを友人や会社の同僚などと共有したり、第三者に公開したりすることが行われている。公開された他人のスケジュールを閲覧して、自社のビジネスに活用しようとするシステムのアイデアも生まれ、このようなシステムが複数特許出願されている。
特開２００３−１４０５９０号公報（特許文献１）には、ユーザにスケジュールとそのユーザの嗜好に沿った広告を配信する「スケジュール通信方法、装置およびシステム」が開示されている。
特開２０１０−３３４９５号公報（特許文献２）には、インターネットを介した簡便な求人広告を可能にする「求人求職支援システム、スケジュール共有システムおよび求人求職支援方法」が開示されている。
【０００３】
いずれの特許文献に記載の発明も、空き時間を有効利用したい人や、他人の空き時間を利用したい人にとって好都合な広告形態を実現するものである。ところで、終身雇用制が崩れつつある現在の雇用環境にあって、自分のキャリアを伸ばしていくことを肯定的に受け止める風潮が生まれつつある。たいていの企業は社員の副業に否定的であったが、最近では副業を容認する企業も出現している。そのため、自分の空き時間を利用したい人と他人の空き時間を利用したい人の双方に資するシステムへの需要は増加することが予想される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１４０５９０号公報
【特許文献２】特開２０１０−３３４９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載の発明によれば、広告主は、広告を配信しようとする相手のスケジュールや嗜好を考慮して広告配信を行うので広告効率が高まるという効果がある。相手のスケジュールが空白の時間帯に、求人広告を送るので、闇雲に送るよりも効率がよいことはたしかである。しかしながら、スケジュールの空き時間といっても、その時間帯のもつ価値はユーザごとに異なる。たとえば、薬剤師の資格を持っている人と、資格や特技を持っていない人とでは時給に換算したときの価値が異なってくる。特許文献１の〔００８４〕〜〔００９４〕の記載からは、個人ごとの空き時間の価値についての考慮が希薄である。例えば、〔００９０〕には、音楽に興味がありそうなユーザに音楽に関連するアルバイトの求人広告を優先的に送信するといった趣旨が記載されている。しかし、このユーザが税理士や翻訳家などの専門職に現在就いているならば、音楽関連のアルバイト情報を送信することは無意味である。このように、特許文献１の発明は広告の効率化を目的としているにもかかわらず、その目的を十分に達成するには限界がある。
【０００６】
特許文献２に記載の発明によれば、広告主が求人情報の配信先を決定する際に参照するのは登録済み求職情報に含まれるキーワードである。このキーワードと求人情報に伴うキーワードとが一致しているときに求人情報を配信するわけである（〔００２２〕を参照）。しかしながら、空き時間に副業をしたいと考える人に対し、そのスケジュールを考慮することなくキーワードの有無のみで求人情報を送るのでは、効率のよい求人求職システムとはいえない。〔００５６〕には、「ユーザの非公開領域３２４Ａ、３２４Ｂには、スケジュール３３８Ａ、３３８Ｂを登録可能である。スケジュール３３８Ａ、３３８Ｂは、例えば、カレンダーに相当する情報としてよく、各日付の、仕事を入れることが可能な時間帯を指定可能である。」と記載されているが、「仕事を入れることが可能な時間帯」をターゲットとして求人情報を送ることは特に記載がない。まして、この時間帯が有する価値を評価するという考え方は皆無である。
【０００７】
本発明は、上記の問題点に鑑み、広告を配信する際に、空き時間と、ユーザによって異なるその空き時間の持つ価値とを勘案し、効率の高い広告配信を実現することを目的とする。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、本発明の広告配信システムは、
広告主が使用する広告主端末およびユーザが使用するユーザ端末と通信可能に接続するサーバが、
前記広告主端末から受信した情報に基づき広告配信先となるユーザの条件を設定する配信先ユーザ条件設定手段と、前記ユーザ端末から受信したスケジュールを含むユーザ個人情報に基づいてユーザの特徴を抽出するユーザプロフィール抽出手段と、前記設定された条件と前記ユーザの特徴とに基づき広告配信先のユーザを抽出する配信先ユーザ検索手段と、前記抽出されたユーザに広告を配信する広告文送信表示手段とを備えることを特徴とする。
広告配信先の決定には、必須条件群、任意条件のアイテム群、及びアイテムごとのカテゴリー別重みの集合、とから構成される配信先ユーザ条件の利用が考えられる。前記配信先ユーザ検索手段は、先ず必須条件をすべて満たすユーザを選び、次に任意条件の各アイテムに重み付けした総和を算出して評価値とし、この評価値に基づき広告配信先を決定していくことができる。
【０００９】
このように、ユーザの特徴を勘案して広告配信先を決定するので、無駄な広告費の出費を抑えることができる。また、配信先の決定に際し、ユーザのスケジュールも考慮するならば、日時の特定を伴う求人広告やイベント開催広告などの配信に適したシステムとなる。
【００１０】
上記の目的を達成するために、前記必須条件には、配信する広告に対応する日時と、ユーザのスケジュール上の空き時間枠との一致を含むことが望ましい。
本発明は空き時間枠の有効利用が第一の目的なので、多くの広告で日時が必須条件となる。その場合、全部一致していることまで要求されるのではなく、一部において一致していれば日時の条件を満たすとみなされることもある。例えば、毎週末のアルバイトを募集する広告の場合、週末の１日でも空いているならば配信対象ユーザとなりうる。
また、前記広告文送信表示手段は、配信する広告を配信先のユーザのスケジュールに組み込んでもよい。特に空き時間枠をターゲットとする広告であれば、スケジュール表の空き時間帯のスケジュール欄に広告が表示されるとユーザにとって見やすく、閲覧される可能性が高まる。
【００１１】
ただし、前記配信先ユーザ検索手段は、前記配信される広告の広告主に対して公開が許可されているユーザの情報に基づいて配信先を抽出することが望ましい。広告主（通常営利目的の民間人）が自分の広告配信の可否を、ユーザが自ら公開を希望しない情報に基づいて判断することは適当でないからである。
【００１２】
上記の目的を達成するために、前記サーバは、配信広告諾否処理手段を備え、
前記配信広告諾否処理手段は、配信した広告に対する配信先ユーザの反応を判定する。
判定法について以下に述べる。
通常、ユーザ端末へ配信される広告には広告情報へのリンクが張られている。このリンクを所定時間内にクリックしなかった時は「無関心」、クリックして閲覧した広告本体に含まれるボタンなどを押下して肯定的な応答をした時は「受諾」、否定的な応答をした時は「拒否」、広告本体を閲覧するが「受諾」も「拒否」もしない時は「無回答」と判定する。
前記反応が「無関心」以外の場合は当該ユーザにアプローチ費を付与し、さらに「受諾」の場合はマッチング成立費を付与するとよい。
無関心以外の場合は、広告本体を閲覧したと考えられるので、アプローチ費が付与される。これにより、配信された広告を一応眺めてみようという動機付けがうまれる。「受諾」の場合は、広告主にとっての目的がかなったのであるから相手にアプローチ費に上乗せしたマッチング成立費が付与される。例えば、この広告が求人に関するものであれば、求人に応じるとマッチング成立費という報酬が得られることになる。これは他のインターネット上の求人システムとの差別化要因となる。
【００１３】
配信された広告に対する各ユーザの過去の履歴情報を記憶する機能があれば、この履歴情報に基づきアクティブ指数を算定し、前記配信先ユーザ検索手段は、該アクティブ指数も勘案して広告配信先のユーザを抽出するとよい。
「アクティブ指数」とは、配信された広告に対する積極度である。配信される都度広告を閲覧したり、多くの広告に肯定的な応答をしたりする積極的なユーザはアクティブ指数が高くなる。
これにより、広告主にとって配信先として適当な条件を備えているユーザであっても、広告に関心のないユーザに配信したり、アプローチ費の取得のみを目的として常時「無回答」であったり「拒否」ボタンをクリックしてばかりいるようなユーザに配信したりすることを少なくでき、広告費の無駄を抑制できる。
【００１４】
上記の目的を達成するために、前記サーバは、配信先ユーザ条件のテンプレートを格納するデータベースを備え、
前記配信先ユーザ条件設定手段は、前記広告主端末から受信した情報を前記テンプレートにあてはめるとよい。
業種によって設定される条件は異なる。また、業種が同じでも職種が違えば条件が異なってくる。テンプレートがシステムに予め用意されているならば、滅多に求人広告を出さないような小規模広告主などにとって、条件設定に伴う負担が軽減される。これにより、本システムを利用しようとする広告主の増加が期待できる。
【００１５】
上記の目的を達成するために、前記サーバは、特徴抽出ルールを格納するデータベースを備え、
前記ユーザプロフィール抽出手段は、明示的あるいは黙示的なユーザ個人情報と前記特徴抽出ルールとから、ユーザプロフィールを抽出する。
ユーザ登録時にユーザ個人情報の入力を要求するが、あまりに詳細な情報を入力させようとすると敬遠されてしまう。一方、明示的にユーザに入力させない事項であっても、ユーザの公開範囲内のスケジュールなどによってもユーザの個人情報が推測できることがある。
この推測しうる情報もユーザ情報として登録しておくならば、広告配信の効率化に資することになる。
【発明の効果】
【００１６】
広告配信先の決定にあたり、空き時間の有無と空き時間の価値とを優先的に考慮するので、無駄な広告費をカットすることができる。さらに、ユーザプロフィールを利用するのでより効率の良い広告配信が実現できる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態のシステム構成図である。
【図２】本実施形態のユーザ個人情報データベースのデータ構造例である。
【図３】本実施形態のユーザスケジュールデータベースのデータ構造例である。
【図４】本実施形態の広告主情報データベースのデータ構造例である。
【図５】本実施形態の配信広告情報データベースのデータ構造例である。
【図６】本実施形態の広告費の分配について説明する図である。
【図７】本実施形態の特徴抽出ルールデータベースのデータ構造例である。
【図８】図１の広告配信処理部の内部構成図である。
【図９】本実施形態のユーザの特徴抽出結果を例示する図である。
【図１０】本実施形態の登録された配信広告と関連情報を例示する図である。
【図１１】本実施形態の配信先ユーザ条件の設定、及び評価値の算出式を例示する図である。
【図１２】本実施形態のユーザ端末に表示される広告と、広告主への応答画面を例示する図である。
【発明を実施するための形態】
【００１８】
本発明の一実施形態であるシステム（以下、「本システム」）について、図面を参照しながら説明する。
本システムが配信する広告は求人広告にとどまらない。例えば空き時間を自己啓発に利用したい人に対して、関連ツールの広告を行うことも含まれる。このようにさまざまな分野の広告が考えられるが、本実施形態では求人広告を例にとって説明する。
【００１９】
本システムは、図１に示すように、サーバ１がユーザ端末２と広告主端末３と通信ネットワークＮを介して接続することによって構成される。端末２、３は図１では１台ずつしか図示されていないが、任意台数接続される。また、サーバ１は、その機能を複数のコンピュータが分散して実行してもかまわない。
【００２０】
サーバ１は、その機能から記憶部と処理部と通信インターフェース部に大別される。
記憶部には、ユーザ側の情報を格納するデータベース１１、広告主側の情報を格納するデータベース１２、システム側が所定の処理のために参照するデータベース１３、その他の図示しない記憶部が含まれる。これらは、ＲＯＭ、ハードディスクなどの記憶媒体によって実現される。
処理部は、広告配信処理部１６と会計処理部１７に大別される。処理部は、ＲＯＭなどの記憶媒体に格納されているコンピュータプログラムがメモリ上に読み込まれ、ＣＰＵが実行することにより実現されるが、一部の機能をハードウェアが実現することもある。
通信インターフェース部には、ユーザ端末通信部１４と広告主端末通信部１５が含まれる。この通信部１４，１５の実体はＷｅｂサーバであり、ソフトウェアとハードウェアとが協働して実現する。
【００２１】
次に、記憶部に含まれる各種データベース（以下、データベースを「ＤＢ」と記す）について詳しく説明する。
ユーザ個人情報ＤＢ１１１は、図２に例示するようにサーバ１に登録したユーザの個人情報がユーザ識別情報（１１１ａ）と対応づけて格納されている。ユーザ端末２から氏名、住所、生年月日、メールアドレスなどの基本的な個人情報（１１１ｂ）や、希望職種や趣味などの任意的な個人情報（１１１ｃ）が入力されるのでこれを格納する。個人情報ごとに情報公開範囲も記憶するとよい。本システムは、配信された広告への対応によって報酬を付与するので、報酬の現在高も記憶する（１１１ｄ）。また、ユーザによって入力された事項以外にシステム側で推測し抽出する事項もある。これもユーザ個人情報ＤＢ１１１に記憶しておくとよい（１１１ｅ）。他に、広告への対応を反映したアクティブ指数などの情報も適宜記憶するとよい。
【００２２】
ユーザスケジュールＤＢ１１２は、図３に例示するようにユーザ毎のスケジュールをユーザ識別情報と対応づけて格納するものである。スケジュール用アプリケーションソフトなどが市販されているので、これをユーザ端末２に実装し、スケジュールを作成したり更新したり、作成されたスケジュールをインターネット上にアップロードして他者に公開したりすればよい。なお、ユーザは、公開範囲を指定可能とし、これをユーザスケジュールＤＢ１１２に記憶するとよい。プライベートな予定を友人や同僚には公開するが、それ以外の人には公開しないといった設定をすることはユーザの自由である。
【００２３】
広告主情報ＤＢ１２１は、図４に例示するように広告主の識別情報と対応づけて社名、住所、担当者名、担当者の電話番号・メールアドレスなどを格納する。
なお、広告主は法人に限らず、個人のこともありうる。例えば、フリーランスのデザイナーは本システムにユーザとして登録すると同時に、アシスタント募集の際に広告を配信することもあるからである。このような個人の情報は、ユーザ個人情報ＤＢ１１１と広告主情報ＤＢ１２１の双方に登録される。
【００２４】
配信広告情報ＤＢ１２２は、図５に示すように、ユーザ端末２に配信しようとする広告内容を格納する。広告主の識別情報および広告を識別する情報（１２２ａ）と対応づけて、配信期間（１２２ｂ）、キーワードや広告文などの広告内容（１２２ｃ）、広告のより詳細な情報の記憶場所（１２２ｄ）などを記憶する。詳細な情報の記憶場所とはＵＲＬなどのことであるが、この記憶場所はサーバ１の管理下にあることが望ましい。もし、サーバ１の外部に記憶してあるのでは、本システムとは無関係に他のシステムなどから広告内容を閲覧できてしまうからである。
配信広告情報ＤＢ１２２には、広告を配信しようとするユーザの条件（１２２ｅ）や広告費に関する情報（１２２ｆ）も記憶する。本システムは、広告費の分配についても特徴があるので、広告費欄１２２ｆに記憶される広告費に関する情報について図６を参照しながら説明する。
【００２５】
１件の広告出稿に際し、広告主から広告費総額（Ｘ円）が本システムの運営者に提示される。本システムに最低限保証される金額（Ｖ円）及びＶ円を引いた残額の所定割合（Ａ％）の合計が本システムのマージンとなる。残りの金額（＝（Ｘ−Ｖ）÷（１００％−Ａ％））がユーザへのインセンティブとして付与される総額である。インセンティブにはアプローチ費（Ｙ円／人）とマッチング成立費（Ｚ円／人）があり、広告に対して何らかのアプローチをしてきた人（Ｂ人）にアプローチ費が付与される。さらに、このアプローチをしてきた人の中で、広告に応じた人（Ｃ人）にはマッチング成立費も付与される。
本システムの運営者には、一定額・一定割合が支払われる。一定額Ｖ円は、運営者に不安を与えないためにも変動させない方がよい。他方一定割合Ａ％の方は、情勢の変化によっては変動もあり得る（例えばマッチングの成立可否に連動させるなど）。
運営者へ支払った残りがユーザへの報酬であって、マッチング成立が予想外に少なかったり、広告にアクセスしたユーザが少なかったりすると広告費が余ることになる。つまり、最初に提示した広告費Ｘ円は上限額であり、この範囲内で広告を配信する。
【００２６】
図６の試算例１は、大きなイベントの会場整備のアルバイトを募集する広告を想定している。試算例２は、ドラッグストアチェーンが薬剤師を募集する広告を想定している。例１ではアプローチ費が５０円、マッチング成立費が５００円であるのに対し、例２ではアプローチ費が１，０００円、マッチング成立費が１５，０００円である。このように例１に比べ例２が高額となるのは、例１は、目的の日時にスケジュールの空きがある人であれば誰でも応募が可能であるのに対し、例２は薬剤師の資格保有者でなければ応募ができないからである。同じ時間帯に空きがあるといっても、その空き時間の価値は資格や特技のない人と希少な国家資格を保有する人とでは価値が異なるのである。つまり、アプローチ費とマッチング成立費の多寡は広告配信対象ユーザの空き時間枠の価値を反映しているのである。
また、報酬は競合他社からの引き合い状況などを考慮して決めるとよい。例えば、外国人観光客が増加しているので通訳ガイドの需要が増え続け、求人求職システムが競って語学のできる人材を探すようになると予想される。そこで、通訳ガイドの求人広告へ応じた人への報酬を多くするならば競合システムに出稿する場合との差別化が図れる。
【００２７】
特徴抽出ルールＤＢ１３１は、図７に例示するように、キーワードなど（１３１ａ）と抽出される特徴（１３１ｂ）との対応を記憶するものである。記憶されたルールは、ユーザが明示的に入力した個人情報や公開しているスケジュールから得られたキーワードに基づいてユーザのプロフィールをサーバ１が抽出するために参照される。
例えば、個人情報に「女性  ３０歳」が登録され、スケジュールに「保育所  おやつ」などの単語が記入されている場合は、このユーザが子供を持つ女性であることが推測される。この推測は、「女性  ５０歳未満  保育所  父母会  おやつ  ⇒  母親」という特徴抽出ルールがあれば、人手を介さずにサーバ１が自動的に行うことができる。
【００２８】
テンプレートＤＢ１３２は、広告主が望ましい広告配信先を決定するのに役立つテンプレートが格納されている。テンプレートについては、後で詳しく説明する。
【００２９】
続いて、処理部に含まれる広告配信処理部１６と会計処理部１７について説明する。
図８に示すように、広告配信処理部１６には、入力情報登録部１６１と配信先ユーザ条件設定部１６２とユーザプロフィール抽出部１６３と配信先ユーザ検索部１６４と広告文送信表示部１６５と配信広告諾否処理部１６６が含まれる。これらの広告配信処理部１６に含まれる各部１６１〜１６６と会計処理部１７は、図示しない制御部による処理制御によって連携動作する。
【００３０】
入力情報登録部１６１は、ユーザ端末２からユーザ端末通信部１４を介してｗｅｂベースで入力された情報をユーザ個人情報ＤＢ１１１とユーザスケジュールＤＢ１１２に登録する。また、広告主端末３から広告主端末通信部１５を介してｗｅｂベースで入力された情報を広告主情報ＤＢ１２１と配信広告情報ＤＢ１２２に登録する。なお、ユーザ端末２と広告主端末３のそれぞれがサーバ１に最初にアクセスし登録するときには識別情報（ユーザＩＤ，広告主ＩＤ）とパスワードを発行し、以後サーバ１にログインするときにこれらの識別情報とパスワードとを認証に利用する。
【００３１】
配信先ユーザ条件設定部１６２は、広告主端末３からアクセスがあると配信広告情報ＤＢ１２２を参照し、まだ条件設定がなされていないならば、テンプレートＤＢ１３２から広告主の業種や求人職種に合致した条件設定テンプレートを表示させる。広告主端末３から入力される情報に基づいてテンプレートが修正され、広告主の所望の条件が設定され、これを配信広告情報ＤＢ１２２に格納する（図５の欄１２２ｅ）。
【００３２】
ユーザプロフィール抽出部１６３は、ユーザ端末２から入力された個人情報やスケジュールから推測できるユーザプロフィールを抽出する。例えば、明示的に趣味が音楽とは入力されなかったが、スケジュールにコンサートやライブの文字が含まれていれば音楽が趣味と推測し、ユーザ個人情報ＤＢ１１１に格納する。この推測にあたって適宜、特徴抽出ルールＤＢ１３１を参照する。
【００３３】
配信先ユーザ検索部１６４は、広告主が登録した設定条件に、ユーザ個人情報ＤＢ１１１から取り出した情報をあてはめ、当該ユーザの空き時間の価値を評価する。この評価値に基づいて、広告配信対象となるユーザを検索する。検索のための評価値の範囲、検索されたユーザ数が広告費を超過するほど多い場合の絞り込みの条件等も配信広告情報ＤＢ１２２に予め格納しておき、この条件に従って配信先ユーザを決定すればよい。
【００３４】
広告文送信表示部１６５は、広告配信先ユーザのユーザ端末２に対し、ユーザ端末通信部１４を介してｗｅｂベースで広告を送信・表示する。その際、ユーザスケジュールＤＢ１１２から当該ユーザのスケジュールを抽出し、広告が目的としている日時に対応したスペースに組み込む形式で広告を配信する。
【００３５】
配信広告諾否処理部１６６は、広告を配信されたユーザの反応を分析する。広告には、通常「受諾」と「拒否」のボタンを含み（図１２（ｂ）を参照）、「受諾」ボタンがクリックされたならば、マッチング成立と判定しマッチング成立費を付与する。あわせて、アプローチ費を付与してもよい。
「拒否」ボタンがクリックされたならば、マッチングは成立しなかったが、一応広告に関心を示してくれたのでアプローチ費は付与する。「受諾」ボタンも「拒否」ボタンも押されなかった、つまり「無回答」の場合は、アプローチ費も付与しない。
なお、配信された広告情報はキーワードだけにして、詳細を見るには更にリンクのクリックなどの操作を要する構成にすることもできる。この場合は、サーバ１側はユーザが広告を閲覧したか否かという情報を取得でき、リンクがクリックされなかったときは広告に「無関心」と判断できる。「受諾」と「拒否」のボタンのいずれもクリックされなかった「無回答」の場合でも、一応リンクをクリックしたときは、広告に少しは関心を示してくれたと解釈し、アプローチ費を付与してもよい。
これらの「受諾」「拒否」「無回答」「無関心」という広告に対する反応は、ユーザ個人情報ＤＢ１１１に登録しておく。これらの反応に基づいてユーザのアクティブ指数を算出してもよい。例えば、当初は１００％に設定しておき、「受諾」以外の反応ならば１回につきＮ％減算し、評価値の算出時に考慮するとよい。つまり、毎回「拒否」する人はアプローチ費取得が目的と推測され、毎回「無回答」の人は広告に興味がないと推測されるので、アクティブ指数を低く設定する。これにより評価値が低くなり、広告配信先としての優先順位が低くなる。
【００３６】
会計処理部１７は、広告主から提示された広告費の振り分け処理をする。図６に示したように、当初提示された広告費から一定額あるいは一定割合が本システムの運営者に支払われ、残りはユーザに報酬（アプローチ費またはマッチング成立費）として付与される。ユーザにどのタイミングで報酬を支払うかは予め定めた取り決めに従い、会計処理部１７が処理をする。例えば、会計処理部１７は、ユーザ個人情報ＤＢ１１１に未払いの報酬を記録し（図２の欄１１１ｄ）、所定のタイミングでインターネットバンキングを利用して振り込むなどの一連の処理を担う。
【００３７】
ユーザ端末２は、本システムを利用して広告の配信を受けようとするユーザが使用するパソコン、スマートフォン、タブレット端末などである。
広告主端末３は、本システムを利用して広告を配信しようとする広告主が使用するパソコン、スマートフォン、タブレット端末などである。
ユーザ端末２と広告主端末３のいずれも、サーバ１とｗｅｂベースで情報の送受信を行うのでブラウザ、そしてスケジュールを管理するためのスケジュール用アプリがインストールされていることは必須である。また、キーボード、マウスやタッチパネルなどの入力手段と、画面表示手段も必須である。ユーザおよび広告主は入力手段を介して文字を入力したり、リンクやボタンの選択操作（本明細書では、「クリック」と表現している）をする。
【００３８】
以上、本システムの構成について説明した。続いて本システムの動作を説明する。
【００３９】
まず、ユーザ登録について説明する。
ユーザ甲は、本システムへの登録時に、氏名「甲○男」、住所「東京都渋谷区」、メールアドレス「kou@xxxxxx,jp」等と入力するとサーバ１はユーザＩＤ＝０１０１を発行し、ユーザ個人情報ＤＢ１１１には、図９の（ａ）のような情報が格納される。報酬の現在高やアクティブ指数はシステム登録時は０円と１００％である。
あわせて、ユーザ甲は、自分のスケジュールをサーバ１に登録することを要する。なぜなら、本システムにとって重要なのはユーザのスケジュール表の空き時間帯であるからである。本システムは、ユーザの空き時間帯に合致する求人広告を配信することによって、闇雲な広告配信による無駄な費用支出の防止を目的とする。したがって、登録ユーザのスケジュールの開示は必須である。ただし、スケジュール内の一部をユーザの意思により非公開とすることはかまわない。
なお、本システムでは１人のユーザは重複登録はできないものとする。アプローチ費を目当てに多重登録する者を防止するためである。
【００４０】
図９（ｂ）によれば、ユーザ甲のスケジュールには、「散歩」、「脳トレ」、「ポチ」という単語が記載されている。さらに、ユーザ甲のスケジュールの午後３時以降は空き時間が多い。そこで、特徴抽出ルールＤＢ１３１を参照するとキーワード「散歩」と「脳トレ」の組み合わせから、ユーザ甲は高齢者と推測され、キーワード「ポチ」から犬を飼っている或は犬好きと推測され、空き時間帯から退職者と推測される。そこでユーザ個人情報ＤＢ１１１の欄１１１ｅには、図９（ｃ）のように、「高齢者、犬好き、退職者」という推測された情報も格納しておく。
ユーザの空き時間の価値を評価するためには、そのユーザに関する情報が多いほど精度が高まる。しかし、大量の項目をユーザに入力させるのではユーザに嫌悪感を抱かせる。一方、ユーザが明示的に入力した項目に限らず、スケジュール表内のメモや抽出された単語からユーザのプロフィールを推測できることが多い。サーバ１は、特徴抽出ルールＤＢ１３１を用意して、ユーザのプロフィールを推測し、その結果もユーザ個人情報ＤＢ１１１に登録する。これにより、ユーザに関して蓄積された情報が増加し、より的確な広告配信が実現できる。
例えば、スケジュール表に「裁判所」とか「依頼人」とか「口頭弁論」といった単語が記載されている場合、明示的な職業の登録がなくても弁護士であると推測される。そのため、このユーザに週末の空き時間枠があるからといってイベント警備のアルバイトの求人広告を配信するようなことは避けられる。
【００４１】
次に、広告主の登録について説明する。
乙社は、本システムへの登録時に、社名「乙株式会社」、住所「東京都港区」、担当者「担当乙子」、職種「ペットシッター派遣業」等と入力するとサーバ１は広告主ＩＤ＝３２０２を発行し広告主情報ＤＢ１２１には、図１０（ａ）のような情報が格納される。また、配信広告情報ＤＢ１２２に図１０（ｂ）に示すような情報を格納する。例えば、広告文「毎週木曜日夕方に大型犬の散歩代行をしてくれる方を求む」を広告ＩＤ＝３２０２−３と対応づけて欄１２２ｃに格納する。あわせて、この広告の配信予定期間を欄１２２ｂに、広告内容の詳細へのリンクを欄１２２ｄに格納する。広告を出稿するに際し、広告費も設定しなくてはならないので、図６に示したような広告費の配分に関する情報を欄１２２ｆに格納する。
【００４２】
乙社は、配信先ユーザ条件（欄１２２ｅ）も設定しなくてはならない。
乙社は、図示しないｗｅｂ画面のメニュー項目から、テンプレートを要求すると、サーバ１はテンプレートＤＢ１３２から図１１（ａ）のようなテンプレートを抽出し広告主端末３に表示させる。
このテンプレートでは必須条件は日時（Ａ１）、作業地域（Ａ２）、保有資格（Ａ３）である。任意条件のアイテム（以下、「アイテム」という）は性別（Ｂ１）、年齢（Ｂ２）、要介護者等の有無（Ｂ３）、職歴の有無（Ｂ４）であり、アイテムＢ１〜Ｂ４は、それぞれカテゴリーを持ち、カテゴリー別の重みＣ１〜Ｃ４が指定されている。
この配信先ユーザ条件は、ユーザの空き時間の価値を評価するために用いられる。
【００４３】
一般に評価値Ｖａｌは、図１１（ｃ）に示す式で算出される。
必須条件Ａｉ（ｉ＝０〜Ｎ）は、０か１の値を持ち、Ｎ個の必須条件の積を求める。すべての必須条件の値が１のときのみ１になる。アイテムＢｊ（ｊ＝０〜Ｍ）は、それぞれ点数を持つ。すべてのアイテムの重みが１．０であれば、アイテムの点数の和は１００点となる。重み付きのアイテムの点数Ｂｊ×Ｃｊの和が任意条件の値である。評価値Ｖａｌは、必須条件の値、重み付きアイテムの値の合計、及びアクティブ指数Ｄの積である。
なお、必須条件が無い（Ｎ＝０）場合は、必須条件の値は１とする。任意条件が無い（アイテム個数Ｍ＝０）場合は、任意条件の値は１００点とする。
【００４４】
それでは、乙株式会社の求人広告用の条件設定について図１１（ｂ）に従い説明する。
大型犬の散歩代行という仕事内容から保有資格の有無は問わないのでテンプレートの必須条件Ａ３のチェックを外す。日時（Ａ１）欄には「木曜、夕方」と記入し、作業地域（Ａ２）欄には「東京都港区周辺」と記入する。
アイテムである性別（Ｂ１）に６０点を付与し、性別のカテゴリーが男性ならば１．０、女性ならば０．３の重み（Ｃ１）をつける。アイテムである年齢（Ｂ２）に４０点を付与し、年齢のカテゴリーが５０歳未満ならば１．０、５０歳以上ならば０．５の重み（Ｃ２）をつける。犬の散歩代行という仕事内容から要介護者等の有無（Ｂ３）や職歴の有無（Ｂ４）は問わないので、点数は０点とする。このようにテンプレートを自社用に修正し、配信広告情報ＤＢ１２２の欄１２２ｅに登録する。
【００４５】
続いて、乙社による広告配信先の検索について説明する。
乙社からの広告配信要求を受けたサーバ１は、ユーザ個人情報ＤＢ１１１を参照し、配信先として適したユーザを検索する。
ユーザ甲が配信先として検索されるか否かは、次のように決定される。
ユーザ甲のプロフィールを図１１（ｂ）に示した乙社の検索条件にあてはめ、ユーザ甲の空き時間を評価する。評価値Ｖａｌは図１１（ｃ）においてＮ＝２，Ｍ＝２の場合なので、次の式で算出する。
Ｖａｌ＝（Ａ１×Ａ２）×（Ｂ１×Ｃ１＋Ｂ２×Ｃ２）×Ｄ
必須条件Ａ１は日時であり、木曜日夕方には１、それ以外は０を値にもつ。
必須条件Ａ２は作業地域であり、港区周辺は１、それ以外は０を値にもつ。
ユーザ甲は、木曜日の夕方が空いているのでＡ１＝１である。また、ユーザ甲の住所は東京都渋谷区なので東京都港区周辺であり、Ａ２＝１である。
ユーザ甲の場合、必須条件であるＡ１とＡ２のいずれも１なので（Ａ１×Ａ２）＝１である。もし、（Ａ１×Ａ２）＝０であるならば、配信先のユーザとして不適当なので任意条件の吟味は打ち切られる。
【００４６】
図１１（ｂ）の例では任意条件のアイテムはＢ１とＢ２の２種類があって、それぞれ６０点と４０点が与えられている。
アイテムＢ１は性別であって、カテゴリーが男性ならば１．０、女性ならば０．３で重み付けをするが、ユーザ甲は男性なので、Ｂ１×Ｃ１＝６０点×１．０＝６０点となる。
アイテムＢ２は年齢であって、５０歳未満ならば１．０、５０歳以上ならば０．５で重みづけをするが、ユーザ甲は高齢者と推測されるので、Ｂ２×Ｃ２＝４０点×０．５＝２０点となる。
よって、ユーザ甲の任意条件の点数（Ｂ１×Ｃ１＋Ｂ２×Ｃ２）は８０点となる。
Ｄはユーザごとのアクティブ指数であり、仮に１００％とすると、ユーザ甲の評価値Ｖａｌは、８０点となる。もし、配信先の条件として評価値が６０点以上と定めているならば、ユーザ甲は乙社の広告の配信先となりうる。
もし、乙社が予算の関係で想定している人数を上回る配信先ユーザが検索された場合は、所定のルールのもと、実際の配信先ユーザを決定する。例えば、評価値の上位の人から順に選択したり、ランダムに選択したりする。
この値Ｖａｌは、配信先ユーザとしての条件を満たした結果、配信先となり且つ広告を受諾したユーザにはマッチング成立費が付与される。値Ｖａｌが広告配信の条件に達していなければ、広告が配信されないのでマッチング成立費もアプローチ費も付与されることはない。つまり、値Ｖａｌは、当該ユーザの空き時間のもつ価値を反映しているのである。
【００４７】
ユーザ甲が配信対象に選ばれた場合、サーバ１は、乙社の広告をユーザ甲のスケジュールの目的日時欄に組み込んでユーザ甲のユーザ端末２に配信する。ユーザ甲のユーザ端末２には図１２（ａ）のように、広告を含んだスケジュールが画面表示される。破線で囲んだ部分が配信された広告である。もし、所定時間内に広告中の「詳細」のリンクがクリックされると、図１２（ｂ）のように詳細な広告の内容と各種ボタンを含む画面が表示される。もし、図１２（ａ）のリンクがクリックされなければ、ユーザ甲は「無関心」と判定し、アクティブ指数を当初の１００％から減算する。もし、ユーザ甲がリンクをクリックしたならば、アプローチ費を付与する。付与されたアプローチ費はユーザ個人情報ＤＢ１１１に反映される（図２の欄１１１ｄ）。
【００４８】
ユーザ甲が「詳細」リンクをクリックすると、画面表示は図１２（ｂ）に示すように変化する。ここで、ユーザ甲が「拒否」ボタンをクリックしたならば、或は所定時間内にいずれのボタンもクリックしなければアプローチ費の取得が目当てと推測してアクティブ指数を減算する。
もし、ユーザ甲が「受諾」ボタンをクリックしたならば、成約したと判定して、マッチング成立費を付与する。マッチング成立費はアプローチ費よりも通常高額に設定している。成約したときは、アプローチ費に加えてマッチング成立費を付与するか、アプローチ費よりも高額なマッチング成立費のみを付与するかは広告主次第である。
なお、受諾するか否かの意思決定の前に、図１２（ｂ）で「質問」ボタンをクリックし、図１２（ｃ）に示す画面に遷移して広告主への質問を送信することができる。ここで、質問と回答のやり取りは任意回数行えるものとする。
【００４９】
ここで気をつけるべきことは、本システム上は成約し、それによりマッチング成立費が付与されたとしても、そのユーザを実際に雇用するとは限らないということである。雇用するか否かは本システム外で広告主がユーザと交渉して決めるようにしてもよい。あくまでも本システムは広告を適切なユーザに配信するための環境を提供することを主目的としているのである。
【００５０】
配信された広告へのユーザの対応に応じて報酬が計算され、ユーザ個人情報ＤＢ１１１の報酬額（欄１１１ｄ）が更新されるとともに、会計処理部１７は予め指定されたタイミングでインターネットバンキングなどを利用した入出金処理を行う。
【００５１】
また、ユーザの対応に応じてアクティブ指数を更新し、ユーザ個人情報ＤＢ１１１に登録する。配信された広告に対して「拒否」ボタンを連続してクリックしたので、現在のアクティブ指数から所定の値だけ減算したり、前回まで連続して「拒否」ボタンをクリックしたが、今回は「受諾」ボタンをクリックしたので所定の値を加算したりするなど予め定めたルールのもとで更新すればよい。このルールはサーバ１が一律に設定してもよいが、広告主ごとに或は業種ごとに設定してもよい。
【００５２】
上記の実施形態は、本発明の例示に過ぎず、特許請求の範囲を逸脱しない範囲で様々な変形が可能である。
上記の実施形態では、求人広告の配信を想定していたが、他人の空き時間帯を利用するのは求人に限らず、イベント開催の案内や習い事の勧誘など各種考えられる。これらも求人広告の場合と処理上の相違はほとんどない。要は本発明は、空いた時間を持て余し有効利用したいと考える者（個人）とその空き時間をいろいろな形で利用したい者（企業や個人）との一般的なマッチングシステムなのである。
上記の実施形態では、広告費の分配に用いる式や配信先ユーザ選択のための評価値算出式を例示したが、これらの式に限るものではない。データベースの構造も、配信先検索の効率を高めるためにさまざまな工夫が考えられる。例えば、本発明を専門職のための求人広告に限定利用するならば、職種ごとにテンプレートを用意し、ユーザ登録時に自分の職種に合致したテンプレートからユーザ情報を入力してもらってもよい。
また、報酬についても受諾した人にのみ付与してもよい。さらに、今回必須条件を満たしていなくても、任意条件のアイテムが所定の評価値を満たしていれば、後日の配信先ユーザの候補として記憶部に登録しておいてもよい。たとえば、今回の日時の条件とまったく合致しなくても、次回以降合致することもありうるからである。
【産業上の利用可能性】
【００５３】
現代人の時間管理ツールはスケジュール表であり、これには確保された時間枠（＝予定）が埋めつくされている一方、空いた時間枠はブランクとなっている。２４時間３６５日は万人に等しく与えられているとはいえ、その空いた時間枠の価値は人によって様々である。本発明は、キャリア（学歴、職歴、資格等）や嗜好性等を時間枠のニーズに照合し、値付けすることにより、時間枠提供者と時間枠購入者をマッチングして時間枠の売買取引を行うものである。このように、未来の空き時間枠の価値評価という考え方を取り入れた本発明は、従来の日本型雇用が衰退しつつある昨今の新しい労働市場に適合した求人システム等として利用されることが期待できる。
【符号の説明】
【００５４】
１：サーバ
１１１：ユーザ個人情報ＤＢ
１１２：ユーザスケジュールＤＢ
１２１：広告主情報ＤＢ
１２２：配信広告情報ＤＢ
１３１：特徴抽出ルールＤＢ
１３２：テンプレートＤＢ
１４：ユーザ端末通信部
１５：広告主端末通信部
１６：広告配信処理部
１６１：入力情報登録部
１６２：配信先ユーザ条件設定部
１６３：ユーザプロフィール抽出部
１６４：配信先ユーザ検索部
１６５：広告文送信表示部
１６６：配信広告諾否処理部
１７：会計処理部
２：ユーザ端末
３：広告主端末
Ｎ：通信ネットワーク
【図１】
2016218654.tif 000003
【図２】
2016218654.tif 000004
【図３】
2016218654.tif 000005
【図４】
2016218654.tif 000006
【図５】
2016218654.tif 000007
【図６】
2016218654.tif 000008
【図７】
2016218654.tif 000009
【図８】
2016218654.tif 000010
【図９】
2016218654.tif 000011
【図１０】
2016218654.tif 000012
【図１１】
2016218654.tif 000013
【図１２】
2016218654.tif 000014