JP2008299680A - 近接通信手段を用いたサービスシステム - Google Patents

Abstract

【課題】ユーザによるサービスの利用場所のデータやその際に使用されたアプリの種類を蓄積することにより、効果的なレコメンドサービスを行う。
【解決手段】近接通信手段を有する携帯端末にサービスを提供するサービス機器と、データベースサーバを有する近接通信サービスシステムであって、前記データベースサーバは携帯端末及び前記サービス機器とインターネットを介して通信可能とされ、前記サービス機器が携帯端末に対し近接通信によりサービスを提供すると、前記データベースサーバは、当該携帯端末の携帯端末識別情報、前記サービス機器内に格納されている前記サービス機器の設置場所を示す場所情報、及び前記サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報を、当該携帯端末及び／又は前記サービス機器からインターネットを介して収集し、格納することを特徴とする。
【選択図】図１

Description

本発明は、近接通信手段を用いたシステム、その携帯端末、サービス機器、データベースサーバ等に関する。

現在の近接通信はＰＯＳなどの課金を目的としたシステムに利用されているのが一般的である。そこで、近接通信機能を有する携帯端末を用いたＰＯＳシステムを例にとり、図１０及び図１１を用いて、従来の典型的な近接通信システムについて説明する。

図１０のシステムは、携帯端末（５０１）と、この携帯端末にPOSサービスを提供するＰＯＳシステムであるサービス機器（５０２）、アプリケーション（以下、「アプリ」という。）のダウンロード元となるインターネットサーバ（５２４）から構成されている。

携帯端末（５０１）は、内部にネットワーク通信部（５０５）、メモリ部（５１４）、時計部（５１７）、アプリ部（５１５）、近接通信用のＩＣカード（５１２）を有している。
サービス機器（５０２）は、データ格納部（５０９）、ＰＯＳアプリケーション部（５１０）及び近接通信用ＩＣカード・リーダー／ライター（５１１。以下、場合により「ＩＣカードＲ／Ｗ」という。）を有する。
また、インターネットサーバ（５２４）は、アプリ保存部（５２５）及びネットワーク通信部（５２６）を有している。

携帯端末（５０１）はネットワーク通信部（５０５）を通じて、インターネットサーバ（５２４）はネットワーク通信部（５２６）を通じて、それぞれインターネット（１８）に接続可能となっている。
そして、携帯端末（５０１）とサービス機器（５０２）は近接通信が可能となっている。この近接通信は、携帯端末（５０２）のＩＣカード（５１２）と、サービス機器（５０２）のＩＣカードＲ／Ｗ（５１１）を通じて行われる。

次に、このシステムの使用の態様を、図１１を用いて説明する。
このシステムの使用に際し、ユーザは携帯端末（５０１）を使い、インターネットサーバ（５２４）から、あらかじめ、必要なデータ管理アプリをダウンロードしておく（ＳＰ１０１）。すなわち、インターネットサーバ（５２４）は、ユーザの携帯端末（５０１）からのダウンロード要求に対応して、データ管理アプリを送信する（ＳＰ３０１）。

そして、ユーザが携帯端末（５０１）をサービス機器（５０２）のＩＣカードＲ／Ｗ（５１１）にタッチ（近接させる場合を含む。以下同じ。）すると（ＳＰ１０２）、サービス機器（５０２）において、ＰＯＳで使用した金額が計算され、携帯端末（５０１）内部のメモリ部（ａ３）から利用金額を引き落とすことが指令される（ＳＰ２０２）。これに対応して、携帯端末（５０２）において、メモリ部（５１４）に記憶されていた「利用日時」、「利用金額」、「残金額」が更新される（ＳＰ１０３）。そして、サービス機器（５０２）において、データ格納部（５０９）に、「携帯端末識別子」と、これに対応する「利用日時」、「利用金額」が格納される（ＳＰ２０３）。ここにおいて「携帯端末識別子」としては、多くの場合、「ＩＣカード識別子」が用いられる。
これにより、ユーザ側においても、サービス機器側においても、当該ユーザによるＰＯＳの利用履歴が記録される。

このように、従来の近接通信の利用のされ方は、特定の種類のサービス機器において、単純に、課金に必要なサービスの履歴を記録するものであった。

なお、近距離の通信機能を備えた携帯端末を用いて利用者個人の嗜好や要求を情報サービス提供者側に伝え、これに応じたサービスの提供を受けるシステムに関する発明として、特開２００５−２９２１２６がある。
特開２００５−２９２１２６号公報

しかしながら、従来のシステムにおいては、特定のサービスに関する情報のみを管理し、付加的な情報の管理がなされていないため、ユーザの使用履歴のデータが有効に活用されているとは言い難い状況であった。

本発明の発明者は、近接通信においては、携帯端末が現実にサービス機器に近接して通信を行うため、その時点におけるユーザ（携帯端末）の居場所が特定できるという点に着眼し、ユーザによるサービスの利用場所のデータやその際に使用されたアプリないしアプリの種類を蓄積し、これを活用することにより、従来無かったレコメンドサービスが可能となることを見出した。
具体的には、本発明は以下のような解決手段を提供する。

請求項１に記載の発明は、近接通信手段を有する携帯端末にサービスを提供するサービス機器と、データベースサーバを有する近接通信サービスシステムであって、前記データベースサーバは携帯端末及び前記サービス機器とインターネットを介して通信可能とされ、前記サービス機器が携帯端末に対し近接通信によりサービスを提供すると、前記データベースサーバは、当該携帯端末の携帯端末識別情報、前記サービス機器内に格納されている前記サービス機器の設置場所を示す場所情報、及び前記サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報を、当該携帯端末及び／又は前記サービス機器からインターネットを介して収集し、格納することを特徴とするシステムである。

ひとつのデータベースサーバに対し、サービス機器は多数あってよく、各サービス機器は多数の携帯端末にサービス提供が可能である。
なお、本明細書において、近接通信とは、微弱電波を用いた近距離通信手段であって、非接触ＩＣカード技術やＢｌｕｅｔｏｏｔｈ等の技術を含むがこれに限られない。
携帯端末とは、典型的には近接通信手段を有する携帯電話であるが、近接通信手段を有する機器ないしカード等であればよい。
サービス機器とは、近接通信を用いて携帯端末にサービスを提供する機器をいう。
また、アプリ、ないしアプリケーションとは、近接通信を用いてサービス機器がサービスを行う際に、携帯端末において必要とされるアプリケーションソフトウェアをいう。

請求項２に記載の発明は、近接通信手段を有する携帯端末にサービスを提供するサービス機器と、携帯端末用のアプリケーションを保存するインターネットサーバと、データベースサーバを有する近接通信サービスシステムであって、携帯端末と前記インターネットサーバ間、携帯端末と前記データベースサーバ間、及び前記サービス機器と前記データベースサーバ間は、インターネットを介して通信可能とされ、前記データベースサーバは、前記サービス機器が携帯端末に対し近接通信によりサービスを提供するたびに、当該携帯端末の携帯端末識別情報、前記サービス機器内に格納されている前記サービス機器の設置場所を示す場所情報、及び前記サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報を当該携帯端末及び／又は前記サービス機器からインターネットを介して収集し、格納することを特徴とするシステムである。

請求項３に記載の発明は、前記サービス機器が携帯端末にサービスを提供する際に、前記データベースサーバに当該携帯端末につき過去に蓄積された場所情報及びアプリケーション情報が存する場合には、これらを用いて、当該携帯端末に対しレコメンデーションを行うことを特徴とする請求項１又は請求項２に記載のシステムである。

請求項４に記載の発明は、請求項１乃至３のいずれか記載のシステムに用いられる携帯端末である。

請求項５に記載の発明は、請求項１乃至３のいずれか記載のシステムに用いられるサービス機器である。

請求項６に記載の発明は、請求項１乃至３のいずれか記載のシステムに用いられるデータベースサーバである。

請求項７に記載の発明は、携帯端末であって、近接通信手段、ネットワーク通信部、メモリ部を有し、近接通信手段によりサービス機器からサービスを受ける際に前記サービス機器から前記サービス機器の設置場所に関する情報である場所情報を受領し、当該場所情報を、当該サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報と共に、インターネットを介してデータベースサーバに送信する機能を有することを特徴とする携帯端末である。

請求項８に記載の発明は、請求項１乃至請求項３のいずれかに記載のシステムに用いられることを特徴とする、請求項７に記載の携帯端末である。

請求項９に記載の発明は、サービス機器であって、近接通信手段、ネットワーク通信部、データ格納部、サービス機器属性記憶部を有し、近接通信手段により携帯端末にサービスを提供する際に、当該携帯端末に対し、サービス機器属性記憶部に格納された自らの設置場所に関する情報である場所情報を送信し、当該携帯端末からその携帯端末識別子、当該サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報を受領し、これら情報をインターネットを介してデータベースサーバに送信する機能を有することを特徴とするサービス機器である。

請求項１０に記載の発明は、請求項１乃至請求項３のいずれかに記載のシステムに用いられることを特徴とする、請求項９に記載のサービス機器である。

請求項１１に記載の発明は、データベースサーバであって、ネットワーク通信部及びデータ格納部を有し、近接通信手段を有する携帯端末がサービス機器からサービス提供を受けた際の情報として、当該携帯端末の端末識別子、当該サービス機器の設置場所を示す場所情報、及び当該サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報を、当該携帯端末及び／又は当該サービス機器からインターネットを介して受領し、格納することを特徴とするデータベースサーバである。

請求項１２に記載の発明は、請求項１乃至請求項３のいずれかに記載のシステムに用いられることを特徴とする、請求項１１に記載のデータベースサーバである。

請求項１３に記載の発明は、近接通信手段を有する携帯端末にサービスを提供するサービス機器であって、携帯端末に対し近接通信によりサービスを開始する際、当該携帯端末に当該サービスに必要なアプリケーションが保存されていない場合には、当該携帯端末に対し当該アプリケーションが保存されているインターネットサーバの情報を送信し、当該携帯端末において当該アプリケーションのダウンロードを可能とさせることを特徴とするサービス機器である。

請求項１４に記載の発明は、近接通信手段を有する携帯端末であって、サービス機器から近接通信によりサービスの提供を受ける際、当該サービスに必要なアプリケーションを保存していない場合には、当該サービス機器から当該サービスに必要なアプリケーションが保存されているインターネットサーバの情報の送信を受け、当該アプリケーションをダウンロードすることを特徴とする携帯端末である。

本発明により、ユーザ（携帯端末）の場所を軸としたユーザの行動履歴を利用して、効果的なマーケティング、レコメンデーション、広告等が可能なシステムを実現することができる。

また、新たなアプリを使用する際にも、わざわざ手動でダウンロードを行う必要がなく、自動的にこれをおこなうことができる。

以下、図面を参照しながら、本発明の実施の形態について説明する。
まず、図１に基づき、システム構成について説明する。

同図に示すように、本発明のシステムは、携帯端末（１）と、この携帯端末にサービスを提供するサービス機器（２）、データを蓄積するデータベースサーバ（３）、アプリを保存しておくインターネットサーバ（２４）を含んでいる。

携帯端末（１）は、内部にネットワーク通信部（５）、メモリ部（１４）、時計部（１７）、アプリフレームワーク部（１９）、共通アプリ部（２１）、アプリ部（１５）、及び近接通信用のＩＣカード（１２）を有している。

メモリ部（１４）に格納されるデータの構造例を図３−１に示す。同図記載のデータのうち、携帯端末識別子とは、携帯端末を特定・識別するための識別子であり、多くの場合ＩＣカード識別子が用いられる。これには、携帯端末ｉｄを用いても良い。利用アプリｉｄとは、当該近接通信を用いて行われる１回のサービス・セッション（以下、単に「セッション」という。）において用いられたアプリ自体又はアプリの種類を特定するためのｉｄである。利用日時は当該セッションが行われた日時であり、セッション継続中に携帯端末（１）の時計部（１７）から読み取られたものである。利用場所とは、サービス機器（２）の設置場所であり、後述するサービス機器（２）の中のサービス機器属性記憶部に記憶されている情報（以下、「場所情報」とも言う。）である。アプリデータとは、当該アプリを使用した際の保存データである。たとえば、サービス機器がカラオケ演奏装置である場合に、リクエストにより演奏された楽曲を特定するデータである。サービス機器ｉｄとは、サービス機器を識別するための固有のｉｄである。

サービス機器（２）は、ネットワーク通信部（６）、サービス機器属性部（１６）、データ格納部（９）、サービスアプリフレームワーク部（２０）、レコメンドエンジン部（２３）、共通サービスアプリ部（２２）、サービスアプリ部（１０）、及び近接通信用ＩＣカード・リーダー／ライター部（１１）を有する。図３−２に、データ格納部に格納されるデータの構造例を示す。

ここにおいて、よく使うデータ構造・機能など、サービス共通のロジックは、携帯端末（１）では共通アプリ部（２１）、サービス機器（２）では共通サービスアプリ部（２２）に格納されている。これらの、サービス共通のロジックはたとえば、ゲーム用で１つ、カラオケ用で１つなど業種やアプリのカテゴリー別に用意される。これは、携帯端末（１）においては複数個格納することができる。
また、サービス提供が行われる際の、具体的な個別のユーザインターフェースやサービス内容は、携帯端末（１）ではアプリ部（１５）、サービス機器（２）ではサービスアプリ部（１０）に格納されたプログラムが担当する。アプリ部（１５）には、個々のアプリとして独立した複数のアプリを格納することが可能である。

データベースサーバ（３）は、ネットワーク通信部（７）、データ格納部（８）、レコメンドデータ部（２７）を有する。図３−３にデータ格納部に格納されるデータの構造例、図３−４にレコメンドデータ部に格納されるデータの構造例を示す。
また、インターネットサーバ（２４）は、アプリ保存部（２５）及びネットワーク通信部（２６）を有している。

なお、これらの、携帯端末（１）、サービス機器（２）、データベースサーバ（３）、及びインターネットサーバ（２４）は、当然、それらの機器の内部に、それらの機器の動作を制御するＣＰＵ、プログラムやデータを格納するためのメモリ、そしてそれらを動作させるためのソフトウェアを包含しており、これらにより前述の各部分を動作させ、データを格納しているものであるが、それらの記載は省略する。

携帯端末（１）はネットワーク通信部（５）を通じて、サービス機器（２）はネットワーク通信部（６）を通じて、データベースサーバ（３）はネットワーク通信部（７）を通じて、インターネットサーバ（２４）はネットワーク通信部（２６）を通じて、それぞれインターネット（１８）に接続可能となっている。
そして、携帯端末（１）とサービス機器（２）とは近接通信が可能となっている。この近接通信は、携帯端末（１）のＩＣカード（１２）と、サービス機器（２）のＩＣカードＲ／Ｗ（１１）を通じて行われる。

次に、各機器の動作のフローを、図２を用いて説明する。
サービス機器（２）は、ユーザが携帯端末（１）をサービス機器（２）にタッチしたことを検出すると（Ｓ２０１）、携帯端末（１）に対し、ダウンロード済みのアプリの一覧を要求する（ＳＡ２０２）。
これを受けた携帯端末（１）は、アプリ部（１５）にある全てのアプリｉｄの一覧を近接通信により送信し（Ｓ１０１）、サービス機器はこれを受信する（Ｓ２０３）。

このとき、当該サービス機器のサービス用のアプリが携帯端末（１）に保存されていないときは（Ｓ２０４）、サービス機器（２）は、携帯端末（１）に対し、それらアプリが格納されているインターネットサーバ（２４）のダウンロードＵＲＬを送信する（Ｓ２０５）。携帯端末（１）は、これを用いて、インターネットサーバ（２４）に当該アプリのダウンロード要求を出し、インターネットサーバ（２４）は、これに対応してアプリ保存部（２５）に保存されているアプリを送信する（Ｓ４０１）。これによりダウンロードされたアプリは、携帯端末（１）のアプリ部（１５）に保存される（Ｓ１０２）。さらに携帯端末（１）は、必要な共通アプリがダウンロードされていない場合には、インターネットサーバ（２４）からダウンロードし（Ｓ４０２）、共通アプリ部（２１）に保存する（Ｓ１０３）。このようにして、携帯端末（１）は、サービス機器（２）に対応したアプリを自動的に起動する（Ｓ１０４）。

また、当該サービス機器のサービス用のアプリが携帯端末（１）にダウンロード済みであれば（Ｓ２０４）、サービス機器（２）は、携帯端末（１）に対しアプリ起動コマンドを送出し（Ｓ２０６）、携帯端末（１）は、これによりアプリを起動する。

以上のように、当該サービス機器のサービス用のアプリが携帯端末（１）に過去にダウンロード済みである場合でも、そうでない場合でも、携帯端末（１）は、今回コンタクトしているサービス機器（２）に対応したアプリを自動的に起動することができる（ＳＡ１０５）ので、ユーザは手動でのダウンロード要求動作をする必要がない。

さらに、携帯端末（１）とサービス機器（２）とは、今回のセッションに必要なデータの交換を行う。このとき、携帯端末（１）はそのメモリ部（１４）内に、サービス機器（２）はそのデータ格納部（９）内に、それぞれ今回のセッションにおいて交換されたデータのセットを格納する。

具体的には、まず、サービス機器（２）は、携帯端末（１）に対し、携帯端末（１）における携帯端末識別子、アプリｉｄ、及びアプリデータの送信要求をする（Ｓ２０７）。ここにおいて、携帯端末識別子とは、ＩＣカードが持つ固有のＩＣカード識別子でもよいし、携帯端末を識別するための携帯端末固有の識別子（ｉｄ）でもよい。ＩＣカード識別子以外の識別子が用いられる場合には、必要に応じ、携帯端末（１）においてアプリを起動する際に、これをＩＣカード部に格納する等しておく。また、アプリｉｄとは、アプリの識別又はアプリの種類の識別に使われるデータである。

携帯端末（１）は、サービス機器（２）からの前記要求（Ｓ２０７）に対応して、そのメモリ部（１４）に格納されているそれらのデータをサービス機器（２）に対して送信する（Ｓ１０５）。サービス機器（２）はこれらを受信し（Ｓ２０８）、データ格納部（９）に記憶する（Ｓ２０９）。

次に、サービス機器（２）は、携帯端末（１）に対し、サービス機器ｉｄ、設置場所データを送信する（Ｓ２１１）。サービス機器ｉｄとは、サービス機器（２）内のサービス機器属性記憶部（１６）内に格納されている当該サービス機器固有のｉｄである。設置場所データとは、やはりサービス機器属性記憶部（１６）に格納されている、当該サービス機器が設置されている場所の情報（場所情報）である。これは、都道府県のような大きな区分によってもよいし、緯度経度のような詳細な区分によってもよい。あるいは、「札幌カラオケボックスＡ店」といった、具体的なスポットを表す情報でもよく、「札幌、カラオケボックスＡ店」といった、それらの組み合わせでも良い。

携帯端末（１）は、これら情報を受信し（Ｓ１０６）、メモリ部（１４）内に記憶する（Ｓ１０７）。同時に、アプリ部（１５）に記憶されているアプリｉｄ、ＩＣカード（１２）内の携帯番号識別子、時計部（１７）から抽出された時間情報、アプリデータ情報等もメモリ部（１４）に格納する。

これらの動作により、携帯端末（１）のメモリ部（１４）には、今回のセッションに関する、携帯端末識別子、利用アプリｉｄ、利用日時、利用場所（場所情報）、アプリデータ、サービス機器ｉｄといった情報が格納されることになる。また、サービス機器（２）のデータ格納部（９）にも同様に、今回のセッションに関する、携帯端末識別子、利用日時、利用場所（場所情報）、アプリデータ、サービス機器ｉｄの情報が格納されることになる。
携帯端末（１）のメモリ部のデータ構造は、たとえば図３−１記載のようであり、サービス機器（２）のデータ格納部のデータ構造は、たとえば図３−２の記載のようなものが考えられる。

そして、携帯端末（１）のメモリ部（１４）、及びサービス機器（２）のデータ格納部（９）にそれぞれ今回のセッションにおいて格納された情報は、定期的にそれぞれにネットワーク通信部を通じて、インターネット（１８）を経由し、データベースサーバ（３）のデータ格納部（８）に蓄積される。この動作は、本フローチャートにおいては、Ｓ２１０→Ｓ３０１→Ｓ３０２、Ｓ１０８→Ｓ３０３→Ｓ３０４と記載されているが、このタイミングに限られるものではない。

これら情報は、携帯端末（１）からの情報なのか、サービス機器（２）からの情報なのかを区別するための、受信対象種別情報とともに格納される。データベースサーバのデータ格納部におけるデータ構造は、たとえば、図３−３のようになる。
なお、このように、携帯端末（１）及びサービス機器（２）から、共にデータが送信されると、受信対象種別情報以外のデータは同一の２つのデータ・セットがデータベースサーバ（３）のデータ格納部（８）に格納されることになるが、このような二重の格納は、データの正確性を検証するために有効である。ただし、携帯端末（１）、サービス機器（２）の一方のみからデータベースサーバ（３）にデータ送信することとしてもよい。

このようにして蓄積されたデータのセットの特徴は、ユーザが現実に出向いて使用した場所のデータ（利用場所＝場所情報）及び使用したアプリ又はアプリの種類の情報（アプリｉｄ）を含んでいる点にある。
そして、ある携帯端末につき、このデータ・セットが複数蓄積されると、当該ユーザが、何処で何をすることが多いのかという行動パターンの情報として用いることができる。
そこで、この情報を利用することにより、レコメンドデータ部に記憶されている広告データ、レコメンドデータ（推奨データ）等を用いて、当該ユーザに対し、従来は不可能であった形でのレコメンドが可能となる。

すなわち、レコメンドエンジン部は、データベースサーバ上のレコメンドデータ部にある推奨データを元に、ユーザの趣向性にあったデータ加工を行いうる。そして、レコメンドデータ部にある広告データを元に、当該サービス機器を現在使用しているユーザの嗜好にあった広告を表示させることができる。

たとえば、札幌でカラオケ店やゲームセンターに行くことの多いユーザが、はじめて東京でゲームセンターに行ったとする。すなわち、このユーザがはじめて東京のゲームセンターのゲーム機器に近接通信を行ったとする。このとき、このユーザは、実際に東京にいることが確実なのであり、かつ、通常の行動範囲が札幌であるということは、東京の地理には不慣れであることが推測される。そして、当該ユーザが通常、カラオケ店とゲームセンターを多用しているとすれば、現在いる東京においてもゲームセンターに行くことを希望している可能性が高い。
したがって、この時点で当該ユーザに対し、東京のカラオケ店の情報を提供することは、ユーザの嗜好に極めてマッチした精度の高いレコメンドとなりうる。

このように、ユーザが近接通信を行った場所の情報をアプリの種類に関する情報と共に蓄積することにより、従来は不可能であった有効なレコメンドが可能となる。

レコメンドの具体的作成方法ないし態様については、多くの方法がありうるが、本発明は、近接通信によって得られた場所情報、及びアプリの種類に関する情報を使用してレコメンドを行うという点に特徴を有するものである。

次に、本発明のさらに詳細かつ具体的な実施例を示す。
まず、北海道・札幌のカラオケボックスに「Ｒｏｏｍ００１」という部屋と「Ｒｏｏｍ００２」という部屋があり、それぞれの部屋にサービス機器であるＢ社カラオケ演奏装置が設置してあり、また、渋谷にあるゲームセンターＣ店には、サービス機器としてＷ社ゲーム装置が設置されているものとする。これらの構成例を図４に示す。

それぞれのサービス機器は、内部のサービス機器属性記憶部に、それぞれ、その装置が設置してある場所の情報（場所情報）、サービス機器ｉｄなどを格納している。すなわち、札幌のカラオケボックスの「Ｒｏｏｍ００１」にあるＢ社カラオケ演奏装置（２Ａ）のサービス機器属性部（１６Ａ）には、サービス機器ｉｄとして「カラオケ装置Ａ」、設置場所（場所情報）として「札幌、カラオケボックスＡ店」というデータが記憶されている。「Ｒｏｏｍ００２」のＢ社カラオケ装置（２Ｂ）も、２Ａの装置と機器の種類、設置場所が同じであるため、そのサービス機器属性記憶部（１６Ｂ）には、同じ情報が格納されている。また、渋谷のゲームセンターＣ店のサービス機器であるＷ社ゲーム装置のサービス機器属性記憶部（１６Ｃ）には、サービス機器ｉｄとして「シューティングゲーム」、設置場所（場所情報）として「渋谷、ゲームセンターＣ店」というデータが格納されている。

当該携帯端末（１Ａ）の所有者であるＸは、札幌にあるカラオケボックスをよく利用する。Ｘがはじめて携帯端末のカラオケアプリを札幌のカラオケ店のＲｏｏｍ００１で使用した際のフローを図５及び図６に示す。
Ｘは、携帯端末（１Ａ）をカラオケ装置に用いるのは、はじめてであったため、サービス機器（２Ａ）を用いた際、自動的にカラオケアプリがダウンロードされる。このフローを図５を用いて説明する。

まず、Ｘが携帯端末（１Ａ）をサービス機器であるカラオケ演奏装置（２Ａ）にタッチする。カラオケ演奏装置（２Ａ）は、ポーリングにより携帯端末（１Ａ）を検出し（ＳＡ２０１）、携帯端末（１Ａ）に対し、ダウンロード済みのアプリ一覧を送信要求する（ＳＡ２０２）。これを受けて、携帯端末（１Ａ）は、そのアプリ部にあるすべてのアプリｉｄを送信する（ＳＡ１０１）。カラオケ演奏装置（２Ａ）は、これを受信し（ＳＡ２０３）、カラオケアプリがダウンロード済みか否かを確認する（ＳＡ２０４）。今回は、ダウンロードされていないため、携帯端末（１Ａ）に対し、ダウンロードＵＲＬを送信する（ＳＡ２０５）。これを受けて、携帯端末（１Ａ）は、送信されたＵＲＬに該当するインターネットサーバ（２４Ａ）から、カラオケアプリをダウンロードし（ＳＡ４０１）、アプリ部に保存する（ＳＡ１０２）。さらに、共通アプリ部に「カラオケ共通アプリ」がダウンロードされていないので、これもインターネットサーバ（２４Ａ）からダウンロードし（ＳＡ４０２）、共通アプリ部に保存する（ＳＡ１０３）。そして、カラオケアプリを自動的に起動する（ＳＡ１０４）。すなわち、ユーザであるＸは、単に携帯端末（１Ａ）をサービス機器であるカラオケ演奏装置（２Ａ）にタッチするだけで、自動的にカラオケアプリがその携帯端末（１Ａ）にダウンロードされるため、手動でのダウンロード行為は不要である。

その後、Ｘが、カラオケアプリがダウンロードされたことを確認後、そのカラオケアプリにより、「襟裳岬」という曲をリクエストし、カラオケ演奏装置（２Ａ）にタッチしたとする。以後の動作を図６に基づき説明する。

カラオケ演奏装置（２Ａ）は、ポーリングによりこれを検出し（ＳＢ２０１）、ダウンロード済みのアプリ一覧を送信要求し（ＳＢ２０２）、携帯端末（１Ａ）は、アプリ部にある全てのアプリｉｄを送信する（ＳＢ１０１）。これを受信したカラオケ演奏装置は（ＳＢ２０３）は、カラオケアプリがすでにダウンロード済みであるか否かを確認する（ＳＢ２０４）。なお、ここまでの動作は、図５と同様である。したがって、ソフトウェアの実現方法によっては、図５の動作のあと、一旦終了することなく、以下の動作に移るようにしてもよい。

今回は、カラオケアプリがすでにダウンロードされているため、カラオケ演奏装置（２Ａ）は、携帯端末（１Ａ）に対し、アプリｉｄと、携帯端末識別子、及びアプリデータを送信要求する（ＳＢ２０７）。これに対応して、携帯端末（１Ａ）は、携帯端末識別子としてＡ＝１９１１２３７８１０ａ５６ｂ０１、アプリｉｄ＝「カラオケアプリＡ」、アプリデータ＝「襟裳岬」を送信する（ＳＢ１０５）。
カラオケ演奏装置（２Ａ）は、これを受信し（ＳＢ２０８）、データ格納部に保存する（ＳＢ２０９）。

次に、カラオケ演奏装置（２Ａ）は、携帯端末（１Ａ）に対し、サービス機器属性記憶部の、サービス機器ｉｄ及び設置場所（場所情報）を送信する（ＳＢ２１１）。この場合のサービス機器ｉｄは「カラオケ装置Ａ」、場所情報は、「札幌、カラオケボックスＡ店」となる。携帯端末（１Ａ）は、これを受信し（ＳＢ１０６）、メモリ部に保存する（ＳＢ１０７）。

これと平行して、カラオケ演奏装置（２Ａ）によりサービス提供としてのカラオケの演奏がなされる（ＳＢ２１５）。
今回の場合には、レコメンドエンジン部は（２３Ａ）は結果としてレコメンドを行わないので、以後のフローは省略する。

そして、携帯端末（１Ａ）のメモリ部、及びサービス機器（２Ａ）のデータ格納部にそれぞれ今回のセッションにおいて格納された情報は、定期的にそれぞれにネットワーク通信部を通じて、インターネット（１８）を経由し、データベースサーバ（３Ａ）のデータ格納部に蓄積される。

次に、Ｘが、別の日に同じカラオケボックスのＲｏｏｍ００２で、携帯端末（１Ａ）のカラオケアプリを用いてカラオケ演奏装置を使用したとする。
この場合のフローは、図６とほぼ同様であり、異なるのは、利用日時（「２００７／５／２１ １８：００」）とアプリデータの値（「北の国から」）である。このセッションにおいて、携帯端末（１Ａ）のメモリ部、及びカラオケ演奏装置（２Ａ）のデータ格納部にそれぞれ格納されたデータは、それぞれにネットワーク通信部を通じて、インターネット（１８）を経由し、データベースサーバ（３Ａ）のデータ格納部に蓄積される。

この結果、データベースサーバ（３Ａ）には、携帯端末（１Ａ）を示す携帯端末識別子に関し、札幌において、カラオケアプリが複数回使用されたことが記録されることになる。

その後、Ｘが東京の渋谷に行き、ゲームセンターＣ店に行って、携帯端末（１Ａ）による近接通信を用いて、サービス機器であるＷ社ゲーム装置（２Ｃ）を利用した場合について説明する。なお、Ｘは、ゲームセンターにはよく行っており、ゲームアプリは携帯端末（１Ａ）にダウンロード済みであるとする。この際のダウンロードのシーケンスを図７に示すが、基本的には図５と同様であるので説明は省略する。そして、Ｘが、携帯端末（１Ａ）において、ゲームアプリを起動し、アプリデータとして「最強ウェポン」を選択し、ゲーム装置（２Ｃ）にタッチしたとする。
以後のフローを、図８を用いて説明する。

ゲーム装置（２Ｃ）は、ポーリングによって携帯端末（１Ａ）によってタッチされたことを検出し（ＳＤ２０１）、ダウンロード済みのアプリ一覧を送信要求し（ＳＤ２０２）、携帯端末（１Ａ）は、アプリ部にある全てのアプリｉｄを送信する（ＳＤ１０１）。ゲーム装置（２Ｃ）は、これを受信し（ＳＤ２０３）、ゲームアプリがすでにダウンロード済みであるか否かを確認する（ＳＤ２０４）。

ゲームアプリはすでにダウンロードされているため、ゲーム装置（２Ｃ）は、携帯端末（１Ａ）に対し、アプリｉｄと、携帯端末識別子、及びアプリデータを送信要求する（ＳＤ２０７）。これに対応して、携帯端末（１Ａ）は、携帯端末識別子としてＡ＝１９１１２３７８１０ａ５６ｂ０１、アプリｉｄ＝「ゲームアプリＡ」、アプリデータ＝「最強ウェポン」を送信する（ＳＤ１０５）。
ゲーム装置（２Ｃ）は、これを受信し（ＳＤ２０８）、データ格納部に保存する（ＳＤ２０９）。

次に、ゲーム装置（２Ｃ）は、携帯端末（１Ａ）に対し、サービス機器属性記憶部の、サービス機器ｉｄ＝「シューティングゲーム」及び設置場所（場所情報）＝「渋谷、ゲームセンターＣ店」を送信する（ＳＤ２１１）。携帯端末（１Ａ）は、これを受信し（ＳＤ１０６）、メモリ部に保存する（ＳＤ１０７）。

そして、携帯端末（１Ａ）のメモリ部、及びサービス機器（２Ｃ）のデータ格納部にそれぞれ今回のセッションにおいて格納された情報は、定期的にそれぞれにネットワーク通信部を通じて、インターネット（１８）を経由し、データベースサーバ（３Ａ）のデータ格納部に蓄積される。
この時点で、携帯端末（１Ａ）、及びデータベースサーバ（３Ａ）が保存するデータは、たとえば図９に示すようになっている。

次に、ゲーム機器（２Ｃ）のレコメンドエンジン部（２３Ｃ）は、レコメンドサービスを行うため、受信済みのアプリ部にある全てのアプリｉｄと、設置場所（場所情報）、携帯端末識別子をデータベースサーバ（３Ａ）に送信し（ＳＤ２１２）、データベースサーバ（３Ａ）は、これらを受信する（ＳＤ３０５）。

データベースサーバ（３Ａ）は、例えば図３−４に記載されたようなデータ構造のレコメンドデータ部を有する。データベースサーバ（３Ａ）は、当該レコメンドデータ部から、送信されたデータの携帯端末識別子に関するアプリｉｄと、場所情報に一致する広告データ及び広告データの設置場所データを検索する（ＳＤ３０６）。ここでは、たとえば、アプリｉｄ＝「カラオケアプリＡ」、「ゲームアプリＡ」、場所情報＝「渋谷」を含むデータとして、レコメンドデータ部において一致するのは、広告データ＝「渋谷カラオケＹ店広告」、広告データの設置場所＝「渋谷、カラオケＹ店」である。

さらに、もしデータベースサーバ（３Ａ）のデータ格納部に、受信した携帯端末識別子に関し、検索した広告データの設置場所及びアプリｉｄと一致する場所情報及びアプリｉｄデータが存在する場合には、すでにこの広告データの設置場所で同じ分野の近接通信が行われているので、この広告データは広告対象から除外される。
今回の場合には、データベースサーバ（３Ａ）のデータ格納部にはそのようなデータを含まないので、広告データは除外されない。

そこで、データベースサーバ（３Ａ）は、検索した広告データである「渋谷カラオケ店Ｙ広告」を、ゲーム装置（２Ｃ）に送信する（ＳＤ３０８）。
ゲーム装置（２Ｃ）のレコメンドエンジン部は、広告データを受信し（ＳＤ２１３）、この広告を表示する（ＳＤ２１４）。ここにおける表示は、単純な広告表示でもよいし、ゲーム内容や展開に関連付けられた表現とされていてもよい。たとえば、ゲームの背景やキャラクター等に、広告内容が反映されているようにされていてもよい。

そして、ゲーム装置（２Ｃ）は、ゲームのサービスを開始する（ＳＤ２１５）。
以上のように、本発明は、近接通信を行っているということが、ユーザがその場所に現実に存在したことを示すという点に着目し、これをデータとしてサーバに保存し、アプリの種類に関する情報等と共にレコメンドに使用することにより、現実のユーザの嗜好に合致したレコメンドを行うことが可能となる。

本発明のシステム全体の構成 本発明のシステムの動作シーケンス図 本発明の実施例における携帯端末メモリ部のデータの構造例 本発明の実施例におけるサービス機器データ格納部のデータの構造例 本発明の実施例におけるデータベースサーバ・データ格納部のデータの構造例 本発明の実施例におけるデータベースサーバ・レコメンドデータ部のデータの構造例 本発明の詳細な実施例におけるサービス機器の構成 本発明の詳細な実施例におけるアプリのダウンロードシーケンス 本発明の詳細な実施例におけるアプリの使用シーケンス 本発明の詳細な実施例におけるアプリのダウンロードシーケンス 本発明の詳細な実施例におけるアプリの使用シーケンス 本発明の詳細な実施例におけるデータ例を示す図 従来の近接通信システムの構成図 従来の近接通信システムの動作シーケンス図

符号の説明

１ 携帯端末
２ サービス機器
３ データベースサーバ
８ データ格納部
９ データ格納部
１４ メモリ部
１６ サービス機器属性記憶部
１８ インターネット
２４ インターネットサーバ
２７ レコメンドデータ部

Claims (14)

1. 近接通信手段を有する携帯端末にサービスを提供するサービス機器と、データベースサーバを有する近接通信サービスシステムであって、前記データベースサーバは携帯端末及び前記サービス機器とインターネットを介して通信可能とされ、前記サービス機器が携帯端末に対し近接通信によりサービスを提供すると、前記データベースサーバは、当該携帯端末の携帯端末識別情報、前記サービス機器内に格納されている前記サービス機器の設置場所を示す場所情報、及び前記サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報を、当該携帯端末及び／又は前記サービス機器からインターネットを介して収集し、格納することを特徴とするシステム。
2. 近接通信手段を有する携帯端末にサービスを提供するサービス機器と、携帯端末用のアプリケーションを保存するインターネットサーバと、データベースサーバを有する近接通信サービスシステムであって、携帯端末と前記インターネットサーバ間、携帯端末と前記データベースサーバ間、及び前記サービス機器と前記データベースサーバ間は、インターネットを介して通信可能とされ、前記データベースサーバは、前記サービス機器が携帯端末に対し近接通信によりサービスを提供するたびに、当該携帯端末の携帯端末識別情報、前記サービス機器内に格納されている前記サービス機器の設置場所を示す場所情報、及び前記サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報を当該携帯端末及び／又は前記サービス機器からインターネットを介して収集し、格納することを特徴とするシステム。
3. 前記サービス機器が携帯端末にサービスを提供する際に、前記データベースサーバに当該携帯端末につき過去に蓄積された場所情報及びアプリケーション情報が存する場合には、これらを用いて、当該携帯端末に対しレコメンデーションを行うことを特徴とする請求項１又は請求項２に記載のシステム。
4. 請求項１乃至３のいずれか記載のシステムに用いられる携帯端末。
5. 請求項１乃至３のいずれか記載のシステムに用いられるサービス機器。
6. 請求項１乃至３のいずれか記載のシステムに用いられるデータベースサーバ。
7. 携帯端末であって、近接通信手段、ネットワーク通信部、メモリ部を有し、近接通信手段によりサービス機器からサービスを受ける際に前記サービス機器から前記サービス機器の設置場所に関する情報である場所情報を受領し、当該場所情報を、当該サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報と共に、インターネットを介してデータベースサーバに送信する機能を有することを特徴とする携帯端末。
8. 請求項１乃至請求項３のいずれかに記載のシステムに用いられることを特徴とする、請求項７に記載の携帯端末。
9. サービス機器であって、近接通信手段、ネットワーク通信部、データ格納部、サービス機器属性記憶部を有し、近接通信手段により携帯端末にサービスを提供する際に、当該携帯端末に対し、サービス機器属性記憶部に格納された自らの設置場所に関する情報である場所情報を送信し、当該携帯端末からその携帯端末識別子、当該サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報を受領し、これら情報をインターネットを介してデータベースサーバに送信する機能を有することを特徴とするサービス機器。
10. 請求項１乃至請求項３のいずれかに記載のシステムに用いられることを特徴とする、請求項９に記載のサービス機器。
11. データベースサーバであって、ネットワーク通信部及びデータ格納部を有し、近接通信手段を有する携帯端末がサービス機器からサービス提供を受けた際の情報として、当該携帯端末の端末識別子、当該サービス機器の設置場所を示す場所情報、及び当該サービスに用いられたアプリケーション又はその種類を示すアプリケーション情報を、当該携帯端末及び／又は当該サービス機器からインターネットを介して受領し、格納することを特徴とするデータベースサーバ。
12. 請求項１乃至請求項３のいずれかに記載のシステムに用いられることを特徴とする、請求項１１に記載のデータベースサーバ。
13. 近接通信手段を有する携帯端末にサービスを提供するサービス機器であって、携帯端末に対し近接通信によりサービスを開始する際、当該携帯端末に当該サービスに必要なアプリケーションが保存されていない場合には、当該携帯端末に対し当該アプリケーションが保存されているインターネットサーバの情報を送信し、当該携帯端末において当該アプリケーションのダウンロードを可能とさせることを特徴とするサービス機器。
14. 近接通信手段を有する携帯端末であって、サービス機器から近接通信によりサービスの提供を受ける際、当該サービスに必要なアプリケーションを保存していない場合には、当該サービス機器から当該サービスに必要なアプリケーションが保存されているインターネットサーバの情報の送信を受け、当該アプリケーションをダウンロードすることを特徴とする携帯端末。
    

Images