JP2017073075A - 対象物管理システム、対象物管理方法、サーバ装置、及びプログラム - Google Patents

Abstract

【課題】数量単位で消費されるボトル等の実対象物の購買等を、仮想対象物を介して実質的に管理し、仮想対象物を複数のブロックに分割し、各ブロックに属性情報を持たせることで、実対象物をブロック単位に異なる条件で実質的に購買等可能とする。【解決手段】本発明は、ユーザ端末及び店舗端末と通信自在で、実対象物の少なくとも購入及び消費を、仮想対象を介して管理するサーバ装置１であって、ユーザ端末と通信する通信部１２と、仮想対象の仮想対象情報を管理する仮想対象情報管理部１１ｃと、仮想対象情報を記憶する仮想対象ＤＢ１５と、仮想対象情報を更新する更新部１１ｅとを備え、ユーザ端末又は店舗端末より実対象物の購入又は消費等に係る指示を受けると、更新部１１ｅは、ＤＢ１５の仮想対象情報を更新し、更新された仮想対象情報を通信部１２を介してユーザ端末に送信し更新内容の確認を促す。【選択図】図３

Description

本発明は、例えば、酒類や肉類等、数量が消費される性質の対象物の購買等を管理するシステム等に係り、特に、仮想対象を介して実対象物の購買等を管理する対象物管理システム、対象物管理方法、サーバ装置、及びプログラムに関する。

従来、居酒屋やバー等では、ボトルキープが一般的になされている。ここで、ボトルキープとは、購入したボトルの酒類を居酒屋で消費し、店を出るときにボトル内に酒類が残っている場合には、次回の消費に持ち越すため、店にて保持してもらうことをいう。ボトルキープによれば、ユーザは、購入したボトルに自己のニックネーム等を記載した札を下げる等して、店内に自己のボトルをキープすることができる。情報技術が発展した今日では、このボトルキープを更に簡便なものとするための種々の技術が提案されている。

例えば、特許文献１では、ボトル情報サーバが、ボトルキープの情報に含まれる各ボトルの有効期限を管理し、有効期限が近いボトルについては、そのボトルをキープしているお客のユーザ端末へ期限が近い旨の電子メールを送信するボトルキープ情報提供システムが開示されている。

特開２００３−１６２５７０号公報

しかしながら、特許文献１に開示されたシステムでは、有効期限に基づく電子メールをユーザ端末に一方的に送るにすぎず、数量が消費される性質の対象物としてのボトルの購買等を広範に管理するものではない。

従来のボトルキープは、１店舗について１ボトルをキープするのが原則であり、多店舗において複数のボトルを適宜消費可能なようにキープすることはなされていない。さらに従来のボトルキープはボトル単位での管理であり、当該ボトルを複数のブロックに分割して各ブロックごとに属性情報（例えば、有効期限、使用店舗、使用ユーザ）を持たせてブロック単位での購買等を管理、支援するシステムは存在しない。

また、情報技術が発達した今日においては、特典ポイントの授受は一般的になされているが、これはあくまでもポイントの授受にすぎず、実対象物を、仮想対象を介して実質的に管理するのとは技術的事項として異なる。さらに、１つの実対象物を、仮想対象を介して、複数のユーザにより、複数の店舗で利用可能なようにシェアすることは、仮想対象を媒介とするからこそ実現されるものであるが、このような技術は従来存在しない。

本発明は、このような課題に鑑みてなされたものであり、実対象物の購買等を、仮想対象を介して実質的に管理することを目的とする。さらに、仮想対象を複数のブロックに分割し、各ブロックに属性情報を持たせることで、仮想対象ブロック単位に異なる条件で実質的に購買等可能とすることを目的とする。

上記課題を解決するため、本発明の第１の態様に係るサーバ装置は、少なくともユーザ端末及び店舗端末と通信自在であり、実対象物の少なくとも購入及び消費を、仮想対象を介して管理するサーバ装置であって、上記ユーザ端末と通信する通信手段と、上記仮想対象の仮想対象情報を管理する仮想対象情報管理手段と、上記仮想対象情報を記憶する記憶手段と、上記仮想対象情報を更新する更新手段と、を備え、上記ユーザ端末又は上記店舗端末より、上記実対象物の少なくとも購入又は消費に係る指示を受けると、上記更新手段は、上記記憶手段の上記仮想対象情報を更新し、上記仮想対象は、複数のブロックに分割されており、各ブロックに属性情報が対応付けられて上記仮想対象情報の一部として上記記憶手段に記憶されており、上記実対象物の少なくとも購入及び消費では、上記実対象物に対応する上記仮想対象を構成する上記ブロックごとに独立して購入及び消費が可能であり、ブロックに係る購入又は消費の指示を受けると、上記更新手段は、上記仮想対象情報のうち当該ブロックに係る部分を更新している。

本発明の第２の態様に係るサーバ装置は、第１の態様において、上記属性情報とは、上記仮想対象に対応する上記実対象物の利用の有効期限、利用可能なユーザ、利用可能な店舗の情報の少なくともいずれかを含んでいる。

本発明の第３の態様に係るサーバ装置は、第１又は第２の態様において、上記実対象物に対応する上記仮想対象は、上記ブロックごとの属性情報により、その利用権限を複数のユーザで共有し、あるいは他のユーザに移行することができる。

本発明の第４の態様に係るサーバ装置は、第１乃至第３の態様において、上記店舗端末又はプレゼント対象者以外のユーザ端末より、上記実対象物のプレゼントに係る指示を受けると、上記更新手段は上記記憶手段の上記仮想対象情報を更新し、更新された仮想対象情報を、上記通信手段を介して、上記プレゼント対象者のユーザ端末に送信し、上記プレゼントの内容の確認を促す。

本発明の第５の態様に係るサーバ装置は、第１乃至第４の態様において、上記実対象物とは、酒類である。

本発明の第６の態様に係る対象物管理システムは、ユーザ端末、店舗端末、及びサーバ装置を有し、実対象物の少なくとも購入及び消費を、仮想対象を介して管理する対象物管理システムであって、上記ユーザ端末は、上記実対象物の少なくとも購入及び消費に係る指示をするユーザ指示手段を備え、上記店舗端末は、上記実対象物の少なくとも購入及び消費に係る指示をする店舗指示手段を備え、上記サーバ装置は、上記ユーザ端末と通信する通信手段と、上記仮想対象の仮想対象情報を管理する仮想対象情報管理手段と、上記仮想対象情報を記憶する記憶手段と、上記仮想対象情報を更新する更新手段と、を備え、上記サーバ装置では、上記ユーザ端末又は上記店舗端末より、上記実対象物の少なくとも購入又は消費に係る指示を受けると、上記更新手段は、上記記憶手段の上記仮想対象情報を更新し、更新された仮想対象情報を、上記通信手段を介して、上記ユーザ端末に送信し、更新内容の確認を促し、上記仮想対象は、複数のブロックに分割されており、各ブロックに属性情報が対応付けられて上記仮想対象情報の一部として上記記憶手段に記憶されており、上記実対象物の少なくとも購入及び消費では、上記実対象物に対応する上記仮想対象を構成する上記ブロックごとに独立して購入及び消費が可能であり、ブロックに係る購入又は消費の指示を受けると、上記更新手段は、上記仮想対象情報のうち当該ブロックに係る部分を更新する。

本発明の第７の態様に係る対象物管理方法は、ユーザ端末、店舗端末、及びサーバ装置を有し、実対象物の少なくとも購入及び消費を仮想対象を介して管理する対象物管理システムによる方法であって、上記ユーザ端末又は上記店舗端末が、上記実対象物の少なくとも購入及び消費に係る指示をするステップと、上記サーバ装置が、上記ユーザ端末と通信するステップと、上記仮想対象の仮想対象情報を管理するステップと、上記仮想対象情報を更新するステップと、を有し、上記サーバ装置では、上記ユーザ端末又は上記店舗端末より、上記実対象物の少なくとも購入又は消費に係る指示を受けると、上上記仮想対象情報を更新し、更新された仮想対象情報を、上記ユーザ端末に送信し、更新内容の確認を促し、上記仮想対象は、複数のブロックに分割されており、各ブロックに属性情報が対応付けられて上記仮想対象情報の一部としてに記憶されており、上記実対象物の少なくとも購入及び消費では、上記実対象物に対応する上記仮想対象を構成する上記ブロックごとに独立して購入及び消費が可能であり、ブロックに係る購入又は消費の指示を受けると、上記仮想対象情報のうち当該ブロックに係る部分を更新する。

本発明の第８の態様に係るプログラムは、実対象物の少なくとも購入及び消費を、仮想対象を介して管理するプログラムであって、コンピュータが、上記仮想対象の仮想対象情報を管理する仮想対象情報管理手段、上記仮想対象情報を更新する更新手段として機能し、上記ユーザ端末又は上記店舗端末より、上記実対象物の少なくとも購入又は消費に係る指示を受けると、上記更新手段は、上記記憶手段の上記仮想対象情報を更新し、更新された仮想対象情報を、上記通信手段を介して、上記ユーザ端末に送信し、更新内容の確認を促し、上記仮想対象は、複数のブロックに分割されており、各ブロックに属性情報が対応付けられて上記仮想対象情報の一部として管理されており、上記実対象物の少なくとも購入及び消費では、上記実対象物に対応する上記仮想対象を構成する上記ブロックごとに独立して購入及び消費が可能であり、ブロックに係る購入又は消費の指示を受けると、上記仮想対象情報のうち当該ブロックに係る部分を更新する。

本発明によれば、実対象物の購買等を、仮想対象を介して実質的に管理する対象物管理システム、対象物管理方法、サーバ装置、及びプログラムを提供することができる。さらに、仮想対象を複数のブロックに分割し、各ブロックに属性情報を持たせることで、実対象物をブロック単位に異なる条件で実質的に購買等可能とする対象物管理システム、対象物管理方法、サーバ装置、及びプログラムを提供することができる。

本発明の一実施形態に係る対象物管理システムの構成図である。 本発明の一実施形態に係る対象物管理システムの概念図である。 サーバ装置の構成図である。 ユーザ端末の構成図である。 店舗端末の構成図である。 （ａ）乃至（ｃ）はテーブルの一例を示す図である。 （ａ）及び（ｂ）はテーブルの一例を示す図である。 個人ボトルの単店舗サービスに係るテーブル参照例を示す図である。 個人ボトルの複数店舗サービスに係るテーブル参照例を示す図である。 共有ボトルの単店舗サービスに係るテーブル参照例を示す図である。 ブロック単位での有効期限に係るテーブル参照例を示す図である。 ボトル取得時の処理の流れを説明する画面遷移図である。 共有者追加に係る処理の流れを示すフローチャートである。 共有者追加に係る処理の流れを説明する画面遷移図である。 （ａ）及び（ｂ）はテーブルの一例を示す図である。 ポイント新規購入に係るテーブル参照例を示す図である。 ポイント追加購入に係るテーブル参照例を示す図である。 ユーザによる購入に係る処理の流れを示すフローチャートである。 ユーザによる購入に係る処理の流れを示す画面遷移図である。 店舗を介した購入に係る処理の流れを示すフローチャートである。 店舗を介した購入に係る処理の流れを示す画面遷移図である。 （ａ）及び（ｂ）はテーブルの一例を示す図である。 ポイント消費に係るテーブル参照例を示す図である。 ユーザによる消費に係る処理の流れを示すフローチャートである。 ユーザによる消費に係る処理の流れを示す画面遷移図である。 店舗を介した消費に係る処理の流れを示すフローチャートである。 店舗を介した消費に係る処理の流れを示す画面遷移図である。 （ａ）及び（ｂ）はテーブルの一例を示す図である。 ポイント移行に係るテーブル参照例を示す図である。 移行に係る処理の流れを示すフローチャートである。 移行に係る処理の流れを示す画面遷移図である。 （ａ）乃至（ｃ）はテーブルの一例を示す図である。 プレゼントに係るテーブル参照例を示す図である。 プレゼントに係るテーブル参照例を示す図である。 プレゼントに係る処理の流れを示すフローチャートである。 プレゼントに係る処理の流れを示す画面遷移図である。

以下、図面を参照しつつ本発明の実施形態について説明する。

図１には本発明の一実施形態に係る対象物管理システムの構成を示し説明する。

同図に示されるように、対象物管理システムは、サーバ装置１と、ユーザ端末２と、店舗端末３とを備えている。これらは、インターネット等のネットワーク５を介してデータの授受が可能なように通信自在に接続されている。尚、サーバ装置１とは別体の管理用のサーバ装置を更に備えて、システム全体の設定、管理、制御を当該管理用のサーバで統括するように構成することもできる。

このような構成において、サーバ装置１は、データベース（以下、ＤＢ）４を備えており、実対象物に係る仮想対象の仮想対象情報を各種テーブル形式で保持している。ユーザ端末２は、所定のアプリケーションプログラムを実装した後、当該プログラムを実行することで、仮想対象（バーチャルオブジェクトともいう）を介して実対象物（リアルオブジェクトともいう）の購入、消費、権限移行、権限授受、権限の共有等をすることが可能となる。一般に数量により消費される実対象物、例えば酒類のボトルであれば、ボトル単位でのキープが基本となるが、この実施形態に係るシステムでは、仮想対象を更に複数のブロックに分割し、それぞれのブロックに属性情報を持たせることで、ブロック単位での購入、消費等が実現されている。

ここで、図２を参照して、本発明の一実施形態に係る対象物管理システムの特徴について更に詳細に説明する。

同図に示されるように、サーバ装置１は、ＤＢ４にて実対象物に係る仮想対象の仮想対象情報を保持している。そして、ユーザＡ，Ｂ・・・による行動（例えば、実対象物の購入、消費、権限移行、権限のプレゼント）等があると、仮想対象情報を適宜更新する。従って、実対象物を、仮想対象を介して間接的にキープ等できることになる。例えば、実対象物が数量単位で消費される酒類のボトルであれば、当該ボトルを、仮想対象を介して実質的にボトルキープできることになる。

仮想対象を介してユーザの行動（購買、消費、権限移行、権限のプレゼント）等に対応し、管理することができるので、１つの実対象物を複数の店舗Ｘ，Ｙで利用可能とし、更には複数のユーザＡ，Ｂ・・・により利用可能とすることもできる。

また、仮想対象は、複数のブロック１、ブロック２、ブロック３・・・ブロックｎに分割されており、それぞれのブロックが属性情報を有している。この属性情報は仮想対象情報の一部としてＤＢ４にて保持されている。属性情報としては、残容量、有効期限（例えば、土日のみ、平日１６時から１８時等）、利用可能店舗、利用可能ユーザ等の情報を含む。

したがって、実対象物が酒類のボトルであれば、ボトル単位のほか、ボトルを数量単位で複数のブロックに分割し、そのブロック単位で異なる属性情報に基づいて各種利用条件等を定めることが可能となる。

例えば、実対象である１本のボトル（１０００ｍｌ）を２００ｍｌごとの５つのブロックＢ１，Ｂ２，Ｂ３，Ｂ４，Ｂ５に分割した場合を想定すると、ブロックＢ１についてはユーザＡ，Ｂで利用可能とし、ブロックＢ２については店舗Ｘ，Ｙで利用可能とし、ブロックＢ３については有効期限を他よりも長く設定するなど、多様な運用が実現されることになる。また、残容量についても、ブロック単位で管理し、そもそも各ブロックに割り当てられる容量を自由に設定することも可能となる。尚、仮想対象が飲料や酒類のボトルであれば、仮想対象は「バーチャルボトル」と称することができる。

図３には、サーバ装置１の構成例を示し説明する。

同図に示されるように、サーバ装置１は、制御部１１を備えており、制御部１１は制御バス１９を介して通信部１２、記憶部１３、ＤＢ４と接続されている。ＤＢ４は、詳細にはユーザＤＢ１４、仮想対象ＤＢ１５、及び店舗ＤＢ１６からなる。制御部１１は、記憶部１３のプログラムを読み出し実行することで、主制御部１１ａ、ユーザ情報管理部１１ｂ、仮想対象情報管理部１１ｃ、店舗情報管理部１１ｄ、更新部１１ｅ、及び決済部１１ｆとして機能することになる。

このような構成において、通信手段としての通信部１２はユーザ端末２や店舗端末３とネットワーク５を介して通信する。記憶部１３は、メモリやＨＤＤ（Hard Disc Drive）等からなり、上述の通りプログラムを記憶すると共に、その実行時にはワークエリアを提供する。ユーザＤＢ１４は、詳細は後述するが、ユーザ情報をテーブル形式で保持している。記憶手段としての仮想対象ＤＢ１５は、詳細は後述するが、仮想対象情報をテーブル形式で保持している。店舗ＤＢ１６は、詳細は後述するが、店舗情報をテーブル形式で保持している。

制御部１１では、実対象物の少なくとも購入及び消費を、仮想対象を介して管理するよう制御する。より詳細には、ユーザ情報管理部１１ｂは、ユーザＤＢ１４へのユーザ情報の登録、管理等を行う。仮想対象情報管理手段としての仮想対象情報管理部１１ｃは、仮想対象ＤＢ１５の仮想対象情報の登録、管理等を行う。店舗情報管理部１１ｄは、店舗ＤＢ１６の店舗情報の登録、管理等を行う。更新手段としての更新部１ｅは、仮想対象情報等の変更があったときに更新をする。決済部１１ｆは、ユーザ端末２等から購入指示等がなされたときに決済処理を実行する。

ユーザ端末２又は店舗端末３より、実対象物の少なくとも購入又は消費に係る指示を受けると、更新手段としての更新部１１ｅは、記憶手段としての仮想対象ＤＢ１５の仮想対象情報を更新し、更新された仮想対象情報を、通信手段としての通信部１２を介して、ユーザ端末２に送信し、更新内容の確認を促すことになる。

仮想対象は、複数のブロックに分割されており、各ブロックに属性情報が対応付けられて仮想対象情報の一部として仮想対象ＤＢ１５に記憶されている。実対象物の少なくとも購入及び消費では、実対象物に対応する仮想対象を構成するブロックごとに独立して購入及び消費が可能であり、一のブロックに係る購入又は消費の指示を受けると、更新部１１ｅは、仮想対象情報のうち当該ブロックに係る部分を更新する。

ここで、属性情報とは、仮想対象に対応する実対象物の利用の有効期限、利用可能なユーザ、利用可能な店舗の情報の少なくともいずれかを含んでいる。実対象物に対応する仮想対象は、ブロック単位で、その利用権限を複数のユーザで共有し、あるいは他のユーザに移行することができる。また、店舗端末３より、実対象物のプレゼントに係る指示を受けると、更新部１１ｅは仮想対象ＤＢ１５の仮想対象情報を更新し、更新された仮想対象情報を、通信部１２を介して、ユーザ端末２に送信し、店舗により実施されたプレゼントの内容の確認を促す。実対象物とは、数量単位で消費される性質の酒類のボトルやグラム単位で取引がされる肉などであってよい。

図４にはユーザ端末２の詳細な構成例を示し説明する。

同図に示されるように、ユーザ端末２は、制御部２１を備えており、制御部２１は制御バス２８を介して通信部２２、操作部２３、表示部２４、及び記憶部２５と接続されている。操作部２３と表示部２４は、タッチパネル２７となって一体に構成されてもよい。制御部２１は、記憶部２５に記憶されているプログラム２６を読み出し実行することで、主制御部２１ａ、購入指示部２１ｂ、消費指示部２１ｃ、移行指示部２１ｄ、共有者追加指示部２１ｅ、及び表示制御部２１ｆとして機能する。ユーザ端末２としては、スマートフォン、タブレット端末、ノート型パソコン等種々のものを採用することができる。

このような構成において、通信部２２は、ネットワーク５を介してサーバ装置１等と通信をする。操作部２３は、マウスやキーボード等も概念上含み、ユーザによる各種操作を受け付ける。表示部２４は、液晶ディスプレイ等で構成され、各種表示を行う。記憶部２５は、メモリやＨＤＤ等で構成されており、プログラムを記憶していると共に、その実行時にはワークエリアを提供する。

制御部２１の各部２１ａから２１ｆは、次のように機能する。

主制御部２１ａは、全体的な制御を司っている。購入指示部２１ｂは、操作部２３の操作に基づいて、実対象物に係る仮想対象の購入の指示をサーバ装置１に対して行う。消費指示部２１ｃは、操作部２３の操作に基づいて、実対象物に係る仮想対象の消費の指示をサーバ装置１に対して行う。移行指示部２１ｄは、操作部２３の操作に基づいて、実対象物に係る仮想対象の権限移行に係る指示をサーバ装置１に対して行う。共有者追加指示部２１ｅは、操作部２３の操作に基づいて、実対象物に係る仮想対象の共有者の追加に係る指示をサーバ装置１に対して行う。そして、表示制御部２１ｆは、サーバ装置１から送信されてきたデータに基づいて表示部２４での各種表示を制御する。

図５には店舗端末３の詳細な構成例を示し説明する。

同図に示されるように、店舗端末３は、制御部３１を備えており、該制御部３１は制御バス３８を介して通信部３２、操作部３３、表示部３４、及び記憶部３５と接続されている。操作部３３と表示部３４は、タッチパネル３７となって一体に構成されてもよい。制御部３１は、記憶部３５に記憶されているプログラム３６を読み出し実行することで、主制御部３１ａ、ポイント（または権限）付与指示部３１ｂ、消費指示部３１ｃ、プレゼント指示部３１ｄ、及び表示制御部３１ｅとして機能する。店舗端末３としては、スマートフォン、タブレット端末、ノート型パソコン等種々のものを採用することができる。

このような構成において、通信部３２は、ネットワーク５を介してサーバ装置１等と通信をする。操作部３３は、マウスやキーボード等も概念上含み、ユーザによる各種操作を受け付ける。表示部３４は、液晶ディスプレイ等で構成され、各種表示を行う。記憶部３５は、メモリやＨＤＤ等で構成されており、プログラムを記憶していると共に、その実行時にはワークエリアを提供する。

制御部３１の各部３１ａから３１ｅは、次のように機能する。

主制御部３１ａは、全体的な制御を司っている。ポイント付与指示部３１ｂは、実対象物に係る仮想対象の利用権限をユーザに付与するようサーバ装置１に指示する。より具体的には、利用権限はポイント付与という形で実行され、ポイント（複数のブロックからなる）の調整を行う場合、構成要素であるブロックの追加や、ブロック内の値（例えば属性情報）の更新を行うことで、実行する。

消費指示部３１ｃは、実対象物に係る仮想対象のユーザによる消費をサーバ装置１に指示する。プレゼント指示部３１ｄは、実対象物に係る仮想対象のユーザへのプレゼントをサーバ装置１に指示する。そして、表示制御部３１ｅは、サーバ装置１から送信されてきたデータに基づいて表示部３４での各種表示を制御する。

図６（ａ）、図６（ｂ）、図６（ｃ）、図７（ａ）、及び図７（ｂ）には、サーバ装置１のＤＢ４に格納されているテーブルの一例を示し説明する。ここでは、実対象物がボトルである場合を例示する。

図６（ａ）は、ユーザＤＢ１４に格納されているテーブルUserの構成例を示している。テーブルUserは、サービスの利用者を表す。
各項目の意味内容は次の通りである。
・id ：ユーザに付与される識別番号
・name ：ユーザ名
・password ：認証用のパスワード
・email ：ユーザの電子メールアドレス

図６（ｂ）は、仮想対象ＤＢ１５に格納されているテーブルBottleDefの構成例を示している。テーブルBottleDefは、ボトルのメタ情報を定義する。
各項目の意味内容は次の通りである。
・ id ：ボトルに付与される識別番号
・ name ：ボトルの名称
・ unit ：仮想対象の単位
・ max Points ：キープできる最大ポイント
・ min Purchase Points ：ポイント購入の最小値
・ max Purchase Points ：ポイント購入の最大値
・ purchase Point Unit ：ポイント購入の最小単位
・ available From ：サービス提供開始日時
・ expireAt ：サービス提供終了日時

図６（ｃ）は、店舗ＤＢ１６に格納されているテーブルBottleSpotの構成例を示している。テーブルBottleSpotは、仮想対象のキープ等のサービスを提供する店舗を表す。
各項目の意味内容は次の通りである。
・id ：店舗に付与される識別番号
・name ：店舗名
・bottleDefs ：この店舗で利用可能なボトル（BottleDef）のid
・address ：店舗の住所
・location ：店舗の所在地の緯度経度
・説明 ：店舗の紹介

図７（ａ）は、仮想対象ＤＢ１５に格納されているテーブルUserBottleの構成例を示している。テーブルUserBottleは、仮想対象を表す。
各項目の意味内容は次の通りである。
・id ：ユーザ保有のボトルの識別番号
・bootle Def ：ボトルの種類
・owner ：ボトルを代表して所有するユーザ
・users ：ボトルを利用できるユーザ
・currentPoints ：現在キープしているポイントの合計
・nextExpDate ：最も早くポイントが失効する日時
・説明 ：ボトルの紹介

図７（ｂ）は、仮想対象ＤＢ１５に格納されているテーブルPointBlockの構成例を示している。テーブルPointBlockは、ボトルにキープされたポイントの内訳を表す。
各項目の意味内容は次の通りである。
・id ：仮想対象のブロックの識別番号
・attachableBottleDefs ：帰属可能なBottleDef
・attachedUserBottle ：帰属するUserBottle
・unit ： ポイントの単位
・origValue ：ポイントの初期値
・currentValue ：現在のポイント
・origExpDate ：ポイントの有効期限の初期値
・ShouldUsedBy ：ポイントの現在の有効期限
・transferable ：ポイントの他のユーザへの移行の可否
・説明 ：ブロックの紹介

図８には個人ボトルの単店舗サービスに係るテーブル参照例を示し説明する。

同図に示されるように、テーブルUserBottleは、bottleDefによりテーブルBottleDefと紐づけられており、usersによりテーブルUserと紐づけられている。テーブルBottleDefは、BootleSpotのbottleDefsによりテーブルBottleSpotと紐づけられている。そして、テーブルUserBottleは、PointBlockのattachedUserBottleによりテーブルPointsBlockと紐づけられている。「店舗０１」は「店舗０１のボトル」という仮想的なボトル（バーチャルボトル）を提供している。「Ａさんのボトル」には、３つの内訳（ブロック）からなるポイントが保持されている。「ユーザＡ」は「Ａさんのボトル」というボトルを利用できる。

図９には個人ボトルの複数店舗サービスに係るテーブル参照例を示し説明する。

同図に示されるように、各テーブルのリレーショナルな関係は図８と同様であるが、この例では、テーブルBottleDefと２つの店舗に関わるテーブルBottleSpotが紐づけられており、テーブルUserBottleには３つのブロックに関わるテーブルPointBlockと紐づけられている。「店舗０１」と「店舗０２」は、「店舗共通ボトル」という仮想的なボトル（バーチャルボトル）を提供している。「ユーザＡ」は、どちらの店舗でも「Ａさんのボトル」を利用できる。

図１０には共有ボトルの単店舗サービスに係るテーブル参照例を示し説明する。

同図に示されるように、各テーブルのリレーショナルな関係は図８と同様であるが、この例では、テーブルUserBottleが複数のブロックに係るテーブルPointBlockと紐づけられている。さらにテーブルUserBottleが複数のユーザに係るテーブルUserと紐づけられている。「ユーザＡ」と「ユーザＢ」は、どちらも「共有ボトル」というボトルを利用できる。

図１１にはブロック単位での有効期限に係るテーブル参照例を示し説明する。

同図に示されるように、各テーブルのリレーショナルな関係は図８と同様であるが、この例では、テーブルUserBottleが、３つのブロックに係るテーブルPointBlockと紐づけられている。内訳（ブロック）００１は失効しているので、内訳（ポイント）００２と００３の合計が現在のポイントになる。次に迎える失効日は10/31であり、次の失効日を迎えた後には、内訳（ブロック）を再集計して現在のポイントが更新される。

図１２には、ボトル取得時の処理の流れを画面遷移図で示し説明する。尚、この処理の流れはあくまでも一連にすぎない。

ボトル取得時には、店舗のボトルリストを参照してボトルの内容確認画面１００を表示し、利用を開始すると、ボトル画面１０１を表示する。取得済のボトルはマイボトルリストに登録されることになる。

以上が本実施形態の基本的な構成、作用となるが、次にこれらの説明をふまえて、本実施形態に係る対象物管理システム等による各種処理の流れを詳細に説明する。具体的には対象物の共有、対象物の購入、対象物の消費、対象物の利用権限の移行、及び（対象物の利用権限のプレゼントについて順立てて説明する。

（対象物の共有）
図１３のフローチャートを参照して、本発明の一実施形態に係る対象物管理システムによる共有者追加に係る処理の流れを説明する。以下の説明では、図１４に示される画面遷移図を適宜参照しつつ説明を進める。

処理を開始すると、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、表示部２４にボトル画面１０３を表示する（Ｓ１）。続いて、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、共有者追加画面１０４を表示する（Ｓ２）。この共有者追加画面１０４において、主制御部２１ａは、操作部２３が操作されるなどして共有者追加が選択されたか否かを判断し（Ｓ３）、共有者追加が選択されると（Ｓ３をＹｅｓ）、共有者追加指示部２１ｅが、サーバ装置１に対して共有者追加の指示を行う（Ｓ４）。

サーバ装置１では、この共有者追加の指示を受けると、更新部１１ｅが仮想対象ＤＢ１５を参照して仮想対象情報を更新する（Ｓ５）。そして、主制御部１１ａは、通信部１２を介して、更新データをユーザＡのユーザ端末２に送信する（Ｓ６）。ユーザＡのユーザ端末２は、この更新データを、通信部２２を介して受信すると、表示制御部２１ｆの制御の下、表示部２４に更新したボトル画面１０５を表示する（Ｓ７）。

サーバ装置１では、主制御部１１ａは、通信部１２を介して、共有完了通知をユーザＢのユーザ端末２に送信する（Ｓ８）。ユーザＢのユーザ端末２は、この共有完了通知を、通信部２２を介して受信すると、表示制御部２１ｆの制御の下、表示部２４に通知画面１０６を表示し（Ｓ９）、続いてボトル画面１０７を表示する（Ｓ１０）。こうして、共有者追加に係る一連の処理を終了する。

（対象物の購入）
図１５（ａ）及び図１５（ｂ）には、対象物の購入の際に生成、参照されるテーブルの一例を示し説明する。図１５（ａ）はテーブルPointTransactionの構成例を示している。このテーブルPointTransactionは、ポイント操作に関わるものである。
各項目の意味内容は次の通りである。
・id ：操作の識別番号
・type ：操作の種類
・points ：操作対象のポイント
・srcUserBottle ：ポイント移行元のボトル
・srcPointBlocks ：ポイント移行元のPointBlockのリスト
・srcUser ：ポイント移行元のユーザ
・dstUserBottle ：ポイント移行先のボトル
・dstPointBlocks ：ポイント移行先のPointBlockのリスト
・dstBottleSpot ：ポイント移行先の店舗
・dstUser ：ポイント移行先のユーザ
・event ：関連するイベント

図１５（ｂ）はテーブルPointBlockの構成例を示す。各項目の意味内容については前述した通りであるが、トランザクションの実行により、ポイントの属性情報が新規に追加されていることが分かる。

図１６にはポイント新規購入（同時にボトル新規取得）に係るテーブル参照例を示し説明する。

同図に示されるように、各テーブルのリレーショナルな関係は図８と同様であるが、この例では、テーブルUserBottleがテーブルPointTransactionとdstUserBottleにより紐づけられている。更に、テーブルPointBlockがテーブルPointTransactionとdstPointBlocksにより紐づけられている。従って、「Ａさん」が例えばクレジットカードで「店舗０１のボトル」のポイント１０００ｍｌを購入し、「１０００ｍｌ入ったＡさんのボトル」が生成されることになる。決済は、サーバ装置１の決済部１１ｆにより実行される。

図１７にはポイント追加購入に係るテーブル参照例を示し説明する。

同図に示されるように、各テーブルのリレーショナルな関係は図８と同様であるが、この例では、テーブルUserBottleがテーブルPointTransactionとdstUserBottleにより紐づけられている。テーブルUserBottleは、２つのブロックに係るテーブルPointBlockのattachedUserBottleにより紐づけされている。更に、２つのテーブルPointBlockがテーブルPointTransactionとdstPointBlocksにより紐づけられている。従って、購入前１０００ｍｌであったボトルが、５００ｍｌ購入することで、購入後に１５００ｍｌとなる。決済は、サーバ装置１の決済部１１ｆにより実行される。

以下、図１８のフローチャートを参照して、本発明の一実施形態に係る対象物管理システムによる購入（ユーザ操作）に係る処理の流れを説明する。以下の説明では、図１９に示される画面遷移図を適宜参照しつつ説明を進める。

処理を開始すると、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、表示部２４にボトル画面１０８を表示する（Ｓ１１）。続いて、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、購入画面１０９を表示する（Ｓ１２）。この購入画面１０９において、主制御部２１ａは、操作部２３が操作されるなどして購入が選択されたか否かを判断し（Ｓ１３）、購入が選択されると（Ｓ１３をＹｅｓ）、購入指示部２１ｂが、サーバ装置１に対して購入の指示を行う（Ｓ１４）。

サーバ装置１では、この購入の指示を受けると、更新部１１ｅが仮想対象ＤＢ１５を参照して仮想対象情報を更新する（Ｓ１５）。サーバ装置１では、決済部１１ｆが購入に係る決済を実行する（Ｓ１６）。そして、主制御部１１ａは、通信部１２を介して、更新データをユーザＡのユーザ端末２に送信する（Ｓ１７）。ユーザＡのユーザ端末２は、この更新データを、通信部２２を介して受信すると、表示制御部２１ｆの制御の下、表示部２４に更新したボトル画面１１０を表示する（Ｓ１８）。

こうして、購入に係る一連の処理を終了する。

以下、図２０のフローチャートを参照して、本発明の一実施形態に係る対象物管理システムによる購入（店舗操作）に係る処理の流れを説明する。以下の説明では、図２１に示される画面遷移図を適宜参照しつつ説明を進める。

処理を開始すると、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、表示部２４にボトル画面１１１を表示する（Ｓ２１）。ユーザＡはこのボトル画面１１１を店舗の店員に提示し、購入意思を伝え、現金を支払う。

店舗端末３は、表示制御部３１ｅの制御の下、表示部３４に利用者リスト画面１１２を表示し（Ｓ２２）、次いで主制御部３１ａは、利用者選択がなされか判断し（Ｓ２３）、利用者選択がなされると（Ｓ２３をＹｅｓ）、表示制御部３１ｅの制御の下、表示部３４にポイント付与画面１１３を表示する（Ｓ２４）。なお、この画面では、ポイントの数量の指定（選択）を受け付ける。そして、主制御部３１ａがポイント付与の指示がなされたか否かを判断し（Ｓ２５）、ポイント付与の指示がなされると（Ｓ２５をＹｅｓ）、ポイント付与指示部３１ｂがサーバ装置１にポイント付与指示を行う（Ｓ２６）。

サーバ装置１では、このポイント付与の指示を受けると、更新部１１ｅが仮想対象ＤＢ１５を参照して仮想対象情報を更新する（Ｓ２７）。そして、主制御部１１ａは、通信部１２を介して、更新データをユーザＡのユーザ端末２に送信する（Ｓ２８）。ユーザＡのユーザ端末２は、この更新データを、通信部２２を介して受信すると、表示制御部２１ｆの制御の下、表示部２４に更新したボトル画面１１４を表示する（Ｓ２９）。こうして、共有者追加に係る一連の処理を終了する。

（対象物の消費）
図２２（ａ）及び図２２（ｂ）には、対象物の消費の際に生成、参照されるテーブルの一例を示し、詳細を説明する。図２２（ａ）はテーブルPointTransactionの構成例を示している。このテーブルPointTransactionは、ポイント操作に関わるものである。各項目の意味内容は図１５で前述した通りである。この例では、ユーザＡから店舗ＡでボトルＡから１０００ｍｌ消費するトランザクションが発生している。

図２２（ｂ）はテーブルPointBlockの構成例を示す。各項目の意味内容については前述した通りであるが、トランザクションの実行により、ブロック１（id：PB21）のcuurentValueが８００から０に更新され、ブロック１（id：PB22）のcuurentValueが６００から４００に更新されている。つまり、ブロック１から８００ｍｌの全てが消費され、ブロック２から２００ｍｌだけ消費され、合計１０００ｍｌが消費されている。

図２３にはポイント消費に係るテーブル参照例を示し説明する。

同図に示されるように、各テーブルのリレーショナルな関係は図８と同様であるが、この例では、テーブルUserBottleがテーブルPointTransactionとsrcUserBottleにより紐づけられている。テーブルUserBottleは、２つのブロックに係るテーブルPointBlockとattachedUserBottleにより紐づけされている。更に、２つのテーブルPointBlockがテーブルPointTransactionとsrcPointBlocksにより紐づけられている。従って、利用前１５００ｍｌ（ブロック１が１０００ｍｌ、ブロック２が５００ｍｌ）あったところを１２００ｍｌ消費し、利用後、３００ｍｌに更新される。操作は、ユーザＡのユーザ端末２の操作により完結する。ユーザＡが行う操作と処理結果画面を店員が見て確認することで店舗は実際のサービス（消費した分のドリンク等）を提供する。

以下、図２４のフローチャートを参照して、本発明の一実施形態に係る対象物管理システムによる消費（ユーザ操作）に係る処理の流れを説明する。以下の説明では、図２５に示される画面遷移図を適宜参照しつつ説明を進める。

処理を開始すると、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、表示部２４にボトル画面１１５を表示する（Ｓ３１）。続いて、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、ポイント利用画面１１６を表示する（Ｓ３２）。このポイント利用画面１１６において、主制御部２１ａは、操作部２３が操作されるなどして利用が選択されたか否かを判断し（Ｓ３３）、利用が選択されると（Ｓ３３をＹｅｓ）、消費指示部２１ｃが、サーバ装置１に対して消費の指示を行う（Ｓ３４）。

サーバ装置１では、この消費の指示を受けると、更新部１１ｅが仮想対象ＤＢ１５を参照して仮想対象情報を更新する（Ｓ３５）。そして、主制御部１１ａは、通信部１２を介して、更新データをユーザＡのユーザ端末２に送信する（Ｓ３６）。ユーザＡのユーザ端末２は、この更新データを、通信部２２を介して受信すると、表示制御部２１ｆの制御の下、表示部２４に更新したボトル画面１１７を表示する（Ｓ１７）。ユーザ端末２では、表示制御部２１ｅの制御の下、表示部２４に更に利用履歴画面１１８を表示する（Ｓ１８）。

サーバ装置１では、主制御部１１ａが店舗に対して利用通知を行う（Ｓ３８）。店舗側では、店舗端末３が、この通知を、通信部３２を介して受信し、表示制御部３１ｅの制御の下、表示部３４に通知画面１１９を表示する（Ｓ３９）。こうして、消費に係る一連の処理を終了する。

以下、図２６のフローチャートを参照して、本発明の一実施形態に係る対象物管理システムによる消費（店舗操作）に係る処理の流れを説明する。以下の説明では、図２７に示される画面遷移図を適宜参照しつつ説明を進める。

処理を開始すると、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、表示部２４にボトル画面１２０を表示する（Ｓ４１）。ユーザＡはこのボトル画面１２０を店舗の店員に提示し、消費意思を伝える。

店舗端末３は、表示制御部３１ｅの制御の下、表示部３４に利用者リスト画面１２１を表示し（Ｓ４２）、次いで主制御部３１ａは、利用者選択がなされか判断し（Ｓ４３）、利用者選択がなされると（Ｓ４３をＹｅｓ）、表示制御部３１ｅの制御の下、表示部３４にポイント利用画面１２２を表示する（Ｓ４４）。そして、主制御部３１ａがポイント利用の指示がなされたか否かを判断し（Ｓ４５）、ポイント利用の指示がなされると（Ｓ４５をＹｅｓ）、消費指示部３１ｃがサーバ装置１に消費指示を行う（Ｓ４６）。

サーバ装置１では、この消費指示を受けると、更新部１１ｅが仮想対象ＤＢ１５を参照して仮想対象情報を更新する（Ｓ４７）。そして、主制御部１１ａは、通信部１２を介して、更新データをユーザＡのユーザ端末２に送信する（Ｓ４８）。ユーザＡのユーザ端末２は、この更新データを、通信部２２を介して受信すると、表示制御部２１ｆの制御の下、表示部２４に更新したボトル画面１２３を表示する（Ｓ２９）。さらに、ユーザ端末２では、表示制御部２１ｅの制御の下、表示部２４に更に利用履歴画面１２４を表示する（Ｓ５０）。

サーバ装置１は、主制御部１１ａが店舗端末３に対して通信部１２を介して利用通知を送信する（Ｓ５１）。店舗端末３は、通信部３２を介してこの通知を受信すると、表示制御部３１ｅの制御の下、表示部３４に通知画面１２５を表示する（Ｓ５２）。こうして、消費に係る一連の処理を終了する。

（対象物の利用権限の移行）
図２８（ａ）及び図２８（ｂ）には、対象物の利用権限の移行の際に生成、参照されるテーブルの一例を示し、詳細を説明する。図２８（ａ）はテーブルPointTransactionの構成例を示している。このテーブルPointTransactionは、ポイント操作に関わる。各項目の意味内容は図１５で前述した通りである。この例では、ユーザＡのボトルＣからユーザＢのボトルＤに１０００ｍｌを移行するトランザクションが発生している。

図２８（ｂ）はテーブルPointBlockの構成例を示す。各項目の意味内容については前述した通りであるが、トランザクションの実行により、ユーザＡのブロック１（id：PB31）のcuurentValueが８００から０に更新され、ブロック２（id：PB32）のcuurentValueが６００から４００に更新されている。そして、ユーザＢのブロック１（id：PB34）のcuurentValueが８００に更新され、ブロック２（id：PB35）のcuurentValueが２００に更新されている。つまり、ユーザＡからユーザＢに１０００ｍｌの利用権限の移行が実行され、それに伴い情報の更新がなされている。

図２９には対象物の利用権限の移行に係るテーブル参照例を示し説明する。

同図に示されるように、各テーブルのリレーショナルな関係は図８と同様であるが、この例では、移行元のユーザＡについては、テーブルUserがテーブルUserBottleとusersにより紐づけられており、テーブルUserBottleはテーブルPointBlockとsrcPointBlocksにより紐づけられている。移行先のユーザＢについては、テーブルUserがテーブルUserBottleとusersにより紐づけられており、テーブルUserBottleは２つのテーブルPointBlockとsrcPointBlocksにより紐づけられている。ユーザＡのテーブルPointBlockはテーブルPointTransactionとsrcPointBlocksにより紐づけられており、ユーザＢのテーブルPointsBlockはテーブルPointTransactionとdstPointBlocksにより紐づけられている。従って、ユーザＡは移行前１０００ｍｌあったところを４００ｍｌ移行して、６００ｍｌとなり、ユーザＢは４００ｍｌの移行を受けて、移行前１０００ｍｌだったところが移行後に５００ｍｌと更新される。

以下、図３０のフローチャートを参照して、本発明の一実施形態に係る対象物管理システムによる移行に係る処理の流れを説明する。以下の説明では、図３１に示される画面遷移図を適宜参照しつつ説明を進める。

処理を開始すると、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、表示部２４にボトル画面１２６を表示する（Ｓ６１）。続いて、ユーザＡのユーザ端末２は、表示制御部２１ｆの制御の下、ポイント移行画面１２７を表示する（Ｓ６２）。このポイント移行画面１２１において、主制御部２１ａは、操作Ｂ２３が操作されるなどしてポイント移行が選択されたか否かを判断し（Ｓ６３）、移行が選択されると（Ｓ６３をＹｅｓ）、移行指示部２１ｄが、サーバ装置１に対して移行指示を行う（Ｓ６４）。

サーバ装置１では、この移行指示を受けると、仮想対象ＤＢ１５を参照して仮想対象情報を更新する（Ｓ６５）。そして、主制御部１１ａは、通信部１２を介して、更新データをユーザＡのユーザ端末２に送信する（Ｓ６６）。ユーザＡのユーザ端末２は、この更新データを、通信部２２を介して受信すると、表示制御部２１ｆの制御の下、表示部２４に更新したボトル画面１２８を表示する（Ｓ６７）。

サーバ装置１では、主制御部１１ａは、通信部１２を介して、移行通知をユーザＢのユーザ端末２に送信する（Ｓ６８）。ユーザＢのユーザ端末２は、この移行通知を、通信部２２を介して受信すると、表示制御部２１ｆの制御の下、表示部２４に通知画面１２９を表示し（Ｓ６９）、続いてボトル画面１３０を表示する（Ｓ７０）。こうして、移行に係る一連の処理を終了する。以上のユーザ間の利用権限（ポイントなど）の移行は、移行元のユーザの仮想対象を構成する複数のボトルをまたいで行うことが可能であり、移行に際して移行先のユーザの仮想対象に新たなブロックを生成したり、複数のブロックをまたいで利用権限（ポイントなど）を移行するようにしてもよい。

（対象物の利用権限のプレゼント）
図３２（ａ）から図３２（ｃ）には、対象物の利用権限のプレゼントの際に生成、参照されるテーブルの一例を示し、詳細を説明する。図３２（ａ）はテーブルEventの構成例を示している。このテーブルEventは、ポイント操作に関わる。各項目の意味内容は次の通りである。
・id ：イベントの識別番号
・type ：操作の種類
・points ：イベントに関連するポイント
・bottleDef ：イベントに関連するボトル定義
・srcBottleSpot ：イベントを作成した店舗
・srcUser ：イベント作成したユーザ
・dstUserBottles ；イベントの対象ボトル（複数可）
・dstUsers ：イベントの対象ユーザ（複数可）
・eventDate ：イベントが実施された日時
・expDate ：イベントが無効となる日時
・説明 ：イベントの紹介
この例では、店舗ＡがユーザＡとユーザＢにボトルＡを１０００ｍｌプレゼントするイベントが発生している。

図３２（ａ）はテーブルPointTransactionの構成例を示している。このテーブルPointTransactionは、ポイント操作に関わる。各項目の意味内容は図１５で前述した通りである。この例では、上述のイベント発生に伴い、ユーザＡが店舗Ａからのプレゼントを受け取るトランザクションが発生している。

図３２（ｂ）はテーブルPointBlockの構成例を示す。各項目の意味内容については前述した通りであるが、トランザクションの実行により、ユーザＡのブロック１（id：PB41）のcuurentValueが１０００に更新されている。つまり、ユーザＡに１０００ｍｌのプレゼントがなされている。

図３３にはプレゼント（受け取り前）に係るテーブル参照例を示し説明する。

同図に示されるように、各テーブルのリレーショナルな関係は図８と同様であるが、この例では、テーブルEventがテーブルBottleDefとbottleDefにより紐づけられ、テーブルUserとdstUsersにより紐づけられている。従って、「店舗０１」が「店舗０１のボトル」のポイント５００ｍｌを特定のユーザ（複数可）にプレゼントされ、それに伴い、テーブルの情報が更新される。プレゼント対象ユーザが明示的にプレゼントを受け取る操作をするまでは、ポイントは付与されず、有効期限を過ぎると受け取ることはできなくなる。

図３４にはプレゼント（受け取り後）に係るテーブル参照例を示し説明する。

同図に示されるように、各テーブルのリレーショナルな関係は図８と同様であるが、この例では、テーブルEventがテーブルBottleDefとbottleDefにより紐づけられ、テーブルUserとdstUsersにより紐づけられている。更にテーブルPointTransactionとテーブルEventとがeventにより紐づけられており、テーブルPointTransactionとテーブルUserBottleとがdstUserBottleにより紐づけられており、テーブルPointTransactionとテーブルPointBlockがdstPointBlocksにより紐づけられている。従って、イベントを受けてトランザクションが発生し、「店舗０１」が「店舗０１のボトル」のポイント５００ｍｌを特定のユーザ（複数可）にプレゼントされ、それに伴い各テーブルの情報が更新される。プレゼント対象ユーザが明示的にプレゼントを受け取る操作をするまでは、ポイントは付与されず、有効期限を過ぎると受け取ることはできなくなる。また、Ａさんのボトルが存在していなかった場合は、当該レコードを併せて生成する。

以下、図３５のフローチャートを参照して、本発明の一実施形態に係る対象物管理システムによるプレゼント（店舗操作）に係る処理の流れを説明する。以下の説明では、図３６に示される画面遷移図を適宜参照しつつ説明を進める。尚、ここでは店舗端末による処理例を示すが、他のユーザ端末、メーカー等の端末、あるいはメーカー等の依頼を受けた管理者端末又はサーバ装置側の操作でも同様の処理が実現される。

処理を開始すると、店舗端末３は、表示制御部３１ｅの制御の下、表示部３４にプレゼント設定画面１３１を表示し（Ｓ７１）、次いで主制御部３１ａは、プレゼントの提供先のユーザの選択がなされか判断し（Ｓ７２）、ユーザの選択がなされると（Ｓ７２をＹｅｓ）、プレゼント指示部３１ｄがサーバ装置１にプレゼント指示を行う（Ｓ７３）。

サーバ装置１では、このプレゼント指示を受けると、仮想対象ＤＢ１５を参照して仮想対象情報を更新する（Ｓ７４）。そして、主制御部１１ａは、通信部１２を介して、更新データをユーザＡのユーザ端末２に送信する（Ｓ７５）。ユーザＡのユーザ端末２は、この更新データを、通信部２２を介して受信すると、表示制御部２１ｅの制御の下、表示部２４にプレゼント確認画面１３２を表示する（Ｓ７６）。さらに、ユーザ端末２では、表示制御部２１ｅの制御の下、表示部２４に更に更新したボトル画面１３３を表示する（Ｓ７７）。こうして、プレゼントに係る一連の処理を終了する。

以上説明したように、本発明の一実施形態によれば、実対象物の購買等を、仮想対象を介して実質的に管理することができる。より詳細には、仮想対象を介してユーザの行動（購買、消費、権限移行、権限のプレゼント）等に対応し、管理することができるので、１つの実対象物を複数の店舗Ｘ，Ｙで利用可能とし、更には複数のユーザＡ，Ｂ・・・により利用可能とすることもできる。

さらに、本発明の一実施形態によれば、仮想対象を複数のブロックに分割し、各ブロックに属性情報を持たせることで、仮想対象ブロック単位に異なる条件で実質的に購買等可能とすることができる。より詳細には、仮想対象を、複数のブロック１、ブロック２、ブロック３・・・ブロックｎに分割し、それぞれのブロックに、残容量、有効期限、利用可能店舗、利用可能ユーザ等といった属性情報を持たせているので、独立した更新、管理が可能となる。したがって、実対象物が酒類のボトルであれば、ボトル単位のほか、ボトルを数量単位で複数のブロックに分割し、そのブロック単位で異なる属性情報に基づいて各種利用条件等を定めることが可能となる。

このような処理によれば、肉類や魚類等、数量単位で取引がされるものの、たくさん購入すると一度に消費しきれずに腐ってしまうような性質の実対象物や、飲料やお酒等のように数量単位で消費されるものの、ボトル単位で取引やキープがされるため、一度に消費できなかった場合に、次回に持ち越したいとのニーズがある実対象物を、一度の消費量にかかわらず多数、又は多量、購入し、複数のタイミングに分けて、複数のユーザで共有もしながら、消費することが可能となる。例えば、酒類であれば、ビールやシャンパン等は開封後は時間経過により炭酸が抜けて、もはや飲めなくなるような性質の実対象物にとっても好適である。以上は、店舗側にとっても、多数、又は多量に仕入れた肉類、魚類、飲料、酒類などを腐らせることなく、効率よくユーザに提供し得る環境を与えるものとなるので、その点でも、メリットがある。

以上、本発明の一実施形態について説明したが、本発明はこれに限定されることなく、その趣旨を逸脱しない範囲で種々の改良・変更が可能であることは勿論である。

例えば、上記実施形態では、酒類のボトルを例示して説明したが、本発明はこれに限定されることなく、数量単位で増減（消費）のある様々な実対象物に適用可能である。例えば、実対象物としては、肉、魚、寿司桶に供給される寿司またはそのネタ、野菜、お菓子等、燃料、潤滑油、酒（日本酒、洋酒、焼酎、ワイン、ビール、発泡酒、ウィスキー、バーボン、カクテル）、飲料など数量単位で取引されるものや、カラオケボックスやマッサージ、エステなどの時間基準でサービスが提供される種々のものに対応可能である。

１…サーバ装置、２…ユーザ端末、３…店舗端末、４…ＤＢ、５…ネットワーク、１１…制御部、１１ａ…主制御部、１１ｂ…ユーザ情報管理部、１１ｃ…対象情報管理部、１１ｄ…店舗情報管理部、１１ｅ…更新部、１１ｆ…決済部、１２…通信部、１３…記憶部、１４…ユーザＤＢ、１５…対象ＤＢ、１６…店舗ＤＢ、２１…制御部、２１ａ…主制御部、２１ｂ…購入指示部、２１ｃ…消費指示部、２１ｄ…移行指示部、２１ｅ…共有者追加指示部、２１ｆ…表示制御部、２２…通信部、２３…操作部、２４…表示部、２５…記憶部、２６…プログラム、２７…タッチパネル、３１…制御部、３１ａ…主制御部、３１ｂ…ポイント付与指示部、３１ｃ…消費指示部、３１ｄ…プレゼント指示部、３１ｅ…表示制御部、３２…通信部、３３…操作部、３４…表示部、３５…記憶部、３６…プログラム、３７…タッチパネル。

Claims (8)

1. 少なくともユーザ端末及び店舗端末と通信自在であり、実対象物の少なくとも購入及び消費を、仮想対象を介して管理するサーバ装置であって、
   上記ユーザ端末と通信する通信手段と、
   上記仮想対象の仮想対象情報を管理する仮想対象情報管理手段と、
   上記仮想対象情報を記憶する記憶手段と、
   上記仮想対象情報を更新する更新手段と、を備え
   上記ユーザ端末又は上記店舗端末より、上記実対象物の少なくとも購入又は消費に係る指示を受けると、上記更新手段は、上記記憶手段の上記仮想対象情報を更新し、
   上記仮想対象は、複数のブロックに分割されており、各ブロックに属性情報が対応付けられて上記仮想対象情報の一部として上記記憶手段に記憶されており、
   上記実対象物の少なくとも購入及び消費では、上記実対象物に対応する上記仮想対象を構成する上記ブロックごとに独立して購入及び消費が可能であり、ブロックに係る購入又は消費の指示を受けると、上記更新手段は、上記仮想対象情報のうち当該ブロックに係る部分を更新する
   サーバ装置。
2. 上記属性情報とは、上記仮想対象に対応する上記実対象物の利用の有効期限、利用可能なユーザ、利用可能な店舗、移行可能かどうか、の情報の少なくともいずれかを含む
   請求項１に記載のサーバ装置。
3. 上記実対象物に対応する上記仮想対象は、上記ブロックごとの属性情報により、その利用権限を複数のユーザで共有し、あるいは他のユーザに移行することができる
   請求項１又は請求項２に記載のサーバ装置。
4. 上記店舗端末又はプレゼント対象者以外のユーザ端末より、上記実対象物のプレゼントに係る指示を受けると、上記更新手段は上記記憶手段の上記仮想対象情報を更新し、更新された仮想対象情報を、上記通信手段を介して、上記プレゼント対象者のユーザ端末に送信し、上記プレゼントの内容の確認を促す
   請求項１乃至請求項３のいずれか１項に記載のサーバ装置。
5. 上記実対象物とは、酒類である
   請求項１乃至請求項４のいずれか１項に記載のサーバ装置。
6. ユーザ端末、店舗端末、及びサーバ装置を有し、実対象物の少なくとも購入及び消費を、仮想対象を介して管理する対象物管理システムであって、
   上記ユーザ端末は、
   上記実対象物の少なくとも購入及び消費に係る指示をするユーザ指示手段を備え、
   上記店舗端末は、
   上記実対象物の少なくとも購入及び消費に係る指示をする店舗指示手段を備え、
   上記サーバ装置は、
   上記ユーザ端末と通信する通信手段と、
   上記仮想対象の仮想対象情報を管理する仮想対象情報管理手段と、
   上記仮想対象情報を記憶する記憶手段と、
   上記仮想対象情報を更新する更新手段と、を備え
   上記サーバ装置では、上記ユーザ端末又は上記店舗端末より、上記実対象物の少なくとも購入又は消費に係る指示を受けると、上記更新手段は、上記記憶手段の上記仮想対象情報を更新し、更新された仮想対象情報を、上記通信手段を介して、上記ユーザ端末に送信し、更新内容の確認を促し、
   上記仮想対象は、複数のブロックに分割されており、各ブロックに属性情報が対応付けられて上記仮想対象情報の一部として上記記憶手段に記憶されており、
   上記実対象物の少なくとも購入及び消費では、上記実対象物に対応する上記仮想対象を構成する上記ブロックごとに独立して購入及び消費が可能であり、ブロックに係る購入又は消費の指示を受けると、上記更新手段は、上記仮想対象情報のうち当該ブロックに係る部分を更新する
   対象物管理システム。
7. ユーザ端末、店舗端末、及びサーバ装置を有し、実対象物の少なくとも購入及び消費を仮想対象を介して管理する対象物管理システムによる方法であって、
   上記ユーザ端末又は上記店舗端末が、
   上記実対象物の少なくとも購入及び消費に係る指示をするステップと、
   上記サーバ装置が、
   上記ユーザ端末と通信するステップと、
   上記仮想対象の仮想対象情報を管理するステップと、
   上記仮想対象情報を更新するステップと、
   を有し、
   上記サーバ装置では、上記ユーザ端末又は上記店舗端末より、上記実対象物の少なくとも購入又は消費に係る指示を受けると、上上記仮想対象情報を更新し、更新された仮想対象情報を、上記ユーザ端末に送信し、更新内容の確認を促し、
   上記仮想対象は、複数のブロックに分割されており、各ブロックに属性情報が対応付けられて上記仮想対象情報の一部としてに記憶されており、
   上記実対象物の少なくとも購入及び消費では、上記実対象物に対応する上記仮想対象を構成する上記ブロックごとに独立して購入及び消費が可能であり、ブロックに係る購入又は消費の指示を受けると、上記仮想対象情報のうち当該ブロックに係る部分を更新する
   対象物管理方法。
8. 実対象物の少なくとも購入及び消費を、仮想対象を介して管理するプログラムであって、
   コンピュータが、
   上記仮想対象の仮想対象情報を管理する仮想対象情報管理手段、
   上記仮想対象情報を更新する更新手段として機能し
   上記ユーザ端末又は上記店舗端末より、上記実対象物の少なくとも購入又は消費に係る指示を受けると、上記更新手段は、上記記憶手段の上記仮想対象情報を更新し、更新された仮想対象情報を、上記通信手段を介して、上記ユーザ端末に送信し、更新内容の確認を促し、
   上記仮想対象は、複数のブロックに分割されており、各ブロックに属性情報が対応付けられて上記仮想対象情報の一部として管理されており、
   上記実対象物の少なくとも購入及び消費では、上記実対象物に対応する上記仮想対象を構成する上記ブロックごとに独立して購入及び消費が可能であり、ブロックに係る購入又は消費の指示を受けると、上記仮想対象情報のうち当該ブロックに係る部分を更新する
   プログラム。