JP2017182486A - 登録管理システム、登録管理方法、および登録管理プログラム - Google Patents

Abstract

【課題】情報の重複登録の抑制と情報登録の利便性とのバランスを取ることを目的とする。【解決手段】一実施形態に係る登録管理システムは、登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信部と、対象情報およびユーザＩＤに基づいて、登録対象およびユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録部と、登録データベース内で重複する対象情報を特定し、該特定した対象情報に対応する少なくとも一部のユーザＩＤに対する特別処理を実行する特別処理部とを備える。【選択図】図５

Description

本発明の一側面は、ユーザ端末からの指示に基づく情報の登録を管理するシステム、方法、およびプログラムに関する。

従来から、ユーザ端末からの指示に基づく情報の登録を管理する様々な仕組みが存在する。例えば下記特許文献１には、懸賞応募受付の処理において適切な応募状況のチェックを行う情報処理装置が記載されている。この情報処理装置は、懸賞応募者からのメールを受信した場合に、懸賞応募者のメールアドレスを用いてユーザデータベースを検索する。そして、同じメールアドレスを含むレコードが抽出されなかった場合には、情報処理装置はそのメールアドレスを含むレコードをユーザデータベースに追加し、懸賞応募者のメールアドレスに対して返信メールを送信する。これにより二重登録が防止される。

特開２００４−２１２７０号公報

一般に二重登録の防止は情報の登録において非常に重要な要素である。その一方で、二重登録を厳密に規制すると、場合によってはユーザがそのような登録の管理に不便さを感じることがあり得る。そのため、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることが望まれている。

本発明の一側面に係る登録管理システムは、登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信部と、対象情報およびユーザＩＤに基づいて、登録対象およびユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録部と、登録データベース内で重複する対象情報を特定し、該特定した対象情報に対応する１以上のユーザＩＤの少なくとも一部に対して特別処理を実行する特別処理部とを備える。

本発明の一側面に係る登録管理方法は、プロセッサを備える登録管理システムにより実行される登録管理方法であって、登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信ステップと、対象情報およびユーザＩＤに基づいて、登録対象およびユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録ステップと、登録データベース内で重複する対象情報を特定し、該特定した対象情報に対応する１以上のユーザＩＤの少なくとも一部に対して特別処理を実行する特別処理ステップとを含む。

本発明の一側面に係る登録管理プログラムは、登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信ステップと、対象情報およびユーザＩＤに基づいて、登録対象およびユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録ステップと、登録データベース内で重複する対象情報を特定し、該特定した対象情報に対応する１以上のユーザＩＤの少なくとも一部に対して特別処理を実行する特別処理ステップとをコンピュータに実行させる。

このような側面においては、登録情報の重複が発生すると、その重複登録を行ったユーザの少なくとも一部に対して特別処理が実行される。このように、重複登録を一旦は許容しつつ、その後にその特別処理を実行することで、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることができる。

本発明の一側面によれば、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることができる。

実施形態に係る登録管理システムの全体構成を示す図である。 登録データベースの例を示す図である。 対象ユーザデータベースの例を示す図である。 実施形態に係るサーバに用いられるコンピュータのハードウェア構成を示す図である。 実施形態に係るサーバの機能構成を示す図である。 複数のユーザが関わった重複登録の一例を示す図である。 複数のユーザが関わった重複登録の別の例を示す図である。 実施形態に係るサーバによる登録処理を示すフローチャートである。 実施形態に係るサーバによる特別処理を示すフローチャートである。 実施形態に係る登録管理プログラムの構成を示す図である。

以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一または同等の要素には同一の符号を付し、重複する説明を省略する。

図１〜図７を参照しながら、実施形態に係る登録管理システム１の機能および構成を説明する。登録管理システム１は、複数のユーザから所定の情報を収集するコンピュータ・システムである。登録管理システム１はその情報を登録情報として蓄積する。

図１は登録管理システム１の全体構成を示す。登録管理システム１はサーバ１０と、複数のユーザ端末２０と、データベース群３０とを備える。データベース群３０は登録データベース３１および対象ユーザデータベース３２を含む。これらの装置はインターネットやイントラネットなどの通信ネットワークＮを通じて互いにデータを送受信することができる。通信ネットワークＮの具体的な構成、すなわち装置間の具体的な接続の態様は何ら限定されない。サーバ１０の管理者はデータベース群３０の各データベースの管理者と同じであってもよいし互いに異なってもよい。データベース群３０内の各データベースの管理者は同一であってもよいし互いに異なってもよい。

登録情報の構成および内容は何ら限定されないが、本実施形態では、登録情報は、ある特定の商品が利用された態様（あるいは、その推定）を示すとする。「商品の利用」は消費（例えば、食べる、飲むなど）を含む概念である。「商品が利用された態様」とは、商品が利用された際の、該商品の周囲の状況または環境である。例えば、商品が利用された場所（地理的位置）または日時、または商品を利用した人は、「商品が利用された態様」の一種である。登録情報は、実際に起こった事実を示してもよいし、起こったと推定される事実を示してもよい。

図１に模式的に示すように、登録情報の収集を目的として商品４０にはバーコード４１が付与される。ユーザはユーザ端末２０を操作して、そのバーコード４１を読み取ることで得られる商品情報と、該バーコードが読み取られた状況を示す状況情報とをサーバ１０に送信する。「バーコードが読み取られた状況」とは、バーコードが読み取られた際の周囲の環境である。サーバ１０はその商品情報および状況情報に基づいて登録情報を生成し、その登録情報を登録データベース３１に格納する。この登録処理が繰り返されることで多くの登録情報が登録管理システム１内に蓄積される。

「商品」とは有償または無償で取引される有体物または無体物であり、したがってサービスを含む概念である。例えば、商品は飲食物であってもよい。「ユーザ」とは何らかのかたちで商品を認識した人であり、例えば、店舗で商品を手に取った人、商品を購入した人、商品を他人から譲り受けた人などを含む。したがって、ユーザは商品の購入者または消費者であってもよい。

バーコード４１の例として一次元バーコードおよび二次元バーコードが挙げられるが、バーコード４１の種類は何ら限定されない。二次元バーコードの代表例としてＱＲコード（登録商標）およびカラーバーコードが挙げられるが、任意の種類の二次元バーコードが採用されてよい。

「商品に付与されたバーコード」とは、商品が未開封の状態においてその商品と共に提供されるバーコードを意味する。例えば、商品の包装に印刷または貼付されたバーコード、商品と共に包装内に入れられたバーコード、商品そのものに印刷または貼付されたバーコードはいずれも、「商品に付与されたバーコード」の一態様である。もちろん、バーコードを商品に付与する方法はこれらに限定されない。

本実施形態では、ユーザが購入または譲り受けにより商品を取得した後にその商品のバーコードを読むことを前提とする。また、登録管理システム１は一つのバーコードに基づく登録情報が一度だけ登録されることを期待する。しかし、実際には悪意のあるユーザが一つのバーコードに基づく登録情報を複数回登録する可能性がある。また、複数のユーザのそれぞれが、意図的にまたは意図せず、同じバーコードに基づく登録情報を登録する可能性もある。登録管理システム１の特徴の一つはこのような重複登録に対する処理である。本明細書では、重複しているか否かを検査する対象となる情報を対象情報といい、その対象情報で示される内容を登録対象という。本実施形態では、対象情報は商品情報であり、登録対象は個々の商品である。対象情報が重複するとは、２以上の同一の対象情報が登録データベース３１に記憶された状態を意味する。

ユーザは、バーコード読取機能を備えるユーザ端末２０を用いて商品４０のバーコード４１を読み取り、この操作により得られた商品情報をサーバ１０に送信してもよい。あるいは、ユーザは他の端末または装置（例えばバーコードリーダ）がバーコード４１を読み取ることで取得した商品情報を自分のユーザ端末２０に受信および記憶させ、その商品情報をサーバ１０に向けてサーバ１０に送信してもよい。すなわち、バーコードを読み取るユーザ端末と商品情報をサーバに送信するユーザ端末とが同じであってもよいし異なってもよい。

本実施形態では、商品情報は商品ＩＤ、シリアル番号、ロット番号、および消費期限を含むものとする。商品ＩＤは、商品管理のために商品の型または種類を一意に特定するための識別子である。シリアル番号は、一つ一つの個体を一意に特定するための識別子である。ある一つの商品ＩＤで示される複数個の商品の中で、ある一つのシリアル番号を持つ商品（個体）は一つしか存在しない。本実施形態で示される登録対象は、商品ＩＤおよびシリアル番号の組合せで示される個々の商品である。ロット番号は、商品の生産または在庫を管理するための識別子であり、例えば製造ライン毎に一意のロット番号が割り当てられる。もちろん、バーコードで示される商品情報の内容は何ら限定されず、例えば、商品情報は製造時期を含んでもよいし、懸賞の応募に必要な情報を含んでもよい。バーコード４１は、店舗にあるレジでの精算の際に読み取られるバーコードとは独立したものであってもよいし、購入手続に必要な情報を含んでもよい。

本実施形態では、状況情報は少なくともユーザＩＤを含み、地理的位置または読取日時（読取時期の一例）をさらに含んでもよい。ユーザＩＤは、商品情報を送信したユーザ端末２０のユーザを一意に特定する識別子である。ユーザＩＤは、ユーザが登録管理システム１の利用を事前に申し込んだ際に付与または設定される。地理的位置とは、ユーザ端末２０が商品情報をサーバ１０に送信した時の該ユーザ端末２０の位置である。読取日時は、バーコードが読み取られた時点として扱われる情報である。読取時期は、実際にバーコードが読み取られた時点であってもよいし、その読み取りが行われた時点と見なすことができる時点であってもよい。

サーバ１０は、１以上のユーザ端末２０から商品情報および状況情報を受信して、これらの情報に基づく登録情報を登録データベース３１に登録するコンピュータである。さらにサーバ１０は、重複した商品情報に関連するユーザに対する特別処理も実行する。サーバ１０は１台のコンピュータで構成されてもよいし、複数台のコンピュータで構成されてもよい。複数台のコンピュータを用いる場合には、これらのコンピュータがインターネットやイントラネットなどの通信ネットワークを介して接続されることで、論理的に一つのサーバ１０が構築される。

ユーザ端末２０は、ユーザが所有または利用するコンピュータである。ユーザ端末２０の例として、タブレット端末および高機能携帯電話機（スマートフォン）などの携帯端末と、据置型または携帯型のパーソナルコンピュータとが挙げられるが、ユーザ端末２０の具体的な種類は限定されない。本実施形態では、ユーザ端末２０は商品情報および状況情報をサーバ１０に登録させるためのアプリケーション・プログラム（登録アプリケーション）を実行可能であるとする。

データベース群３０は、１以上のデータベースの集合である。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システムでもよいし、テキストファイルでもよい。上述したように、本実施形態では、データベース群３０は登録データベース３１および対象ユーザデータベース３２を含む。

登録データベース３１は、登録対象およびユーザＩＤの組合せを示す登録情報を記憶する装置である。図２は、登録データベース３１に記憶される登録情報の例を示す。本実施形態では、登録情報の各レコードは、対象情報である商品情報（シリアル番号、ロット番号、商品ＩＤ、および消費期限）と状況情報（地理的位置、読取日時、およびユーザＩＤ）との組合せを示す。図２は例えば、ユーザ「Ｕ００１」が、２０１６年３月２０日の１９時４５分に地理的位置（ｘ１，ｙ１）で、シリアル番号が「１０２３４０５６７」で商品ＩＤが「Ｐ１２３０」である商品のバーコードを読み取ったことを示す。図２は、ユーザ「Ｕ００１」が登録した商品情報とユーザ「Ｕ００３」が登録した商品情報とが重複することも示す。

なお、登録情報の構成および表現方法は図２の例に限定されず、登録対象およびユーザＩＤの組合せを示す限り何ら限定されない。図２に示す３レコードではすべてのデータ項目に値が設定されているが、地理的位置または読取日時が空値（ｎｕｌｌ）であってもよい。商品情報は商品の属性を示す任意の情報（例えば商品名）を含んでもよい。地理的位置は緯度経度ではなく住所で表されてもよい。

対象ユーザデータベース３２は、重複する商品情報（対象情報）に対応するユーザを示す対象ユーザ情報を記憶する装置である。「重複する商品情報に対応するユーザ」とは、重複する商品情報を登録したユーザを意味する。図３は、対象ユーザデータベース３２に記憶される対象ユーザ情報の例を示す。本実施形態では、対象ユーザ情報の各レコードはユーザＩＤ、重複回数、警告フラグ、およびブロックフラグを示す。重複回数は、ユーザが商品情報を重複して登録した回数である。この重複回数は、一人のユーザが一つの商品情報を複数回登録した場合も、一つの商品を複数のユーザが登録した場合もカウントされる値である。なお、重複回数は、一人のユーザが一つの商品情報を複数回登録した場合と、一つの商品を複数のユーザが登録した場合とのどちらか一方でのみカウントされてもよい。警告フラグは、重複登録に対する警告がユーザに対して出されたか否かを示す値であり、本実施形態では、「０（警告が出されたことがない）」または「１（警告が出された）」で示される。ブロックフラグは、ユーザからの登録要求を拒否（登録情報の格納の拒否）するか否かを示す値であり、本実施形態では、「０（登録要求を拒否しない）」または「１（登録要求を拒否する）」で示される。図３は例えば、ユーザ「Ｕ００３」が重複登録を３回行い、警告を受け、登録要求を拒否されている（すなわち、商品情報を登録できない）ことを示す。なお、対象ユーザ情報の構成および表現方法は図３の例に限定されない。

データベース群３０内の各データベースおよび各レコードの構成は上記のものに限定されず、各データベースに対して任意の正規化または冗長化を行ってよい。

図４は、サーバ１０として機能するコンピュータ１００の一般的なハードウェア構成を示す。コンピュータ１００は、オペレーティングシステムやアプリケーション・プログラムなどを実行するプロセッサ（例えばＣＰＵ）１０１と、ＲＯＭおよびＲＡＭで構成される主記憶部１０２と、ハードディスクやフラッシュメモリなどで構成される補助記憶部１０３と、ネットワークカードまたは無線通信モジュールで構成される通信制御部１０４と、キーボードやマウスなどの入力装置１０５と、モニタなどの出力装置１０６とを備える。

サーバ１０の各機能要素は、プロセッサ１０１または主記憶部１０２の上に所定のソフトウェア（例えば、後述する登録管理プログラムＰ１）を読み込ませてそのソフトウェアを実行させることで実現される。プロセッサ１０１はそのソフトウェアに従って、通信制御部１０４、入力装置１０５、または出力装置１０６を動作させ、主記憶部１０２または補助記憶部１０３におけるデータの読み出し及び書き込みを行う。処理に必要なデータまたはデータベースは主記憶部１０２または補助記憶部１０３内に格納される。

図５は、サーバ１０の機能構成を示す図である。図５に示すように、サーバ１０は機能的構成要素として受信部１１、登録部１２、および特別処理部１３を備える。

受信部１１は、ユーザ端末２０から商品情報および状況情報を受信する機能要素である。本実施形態では、受信部１１は商品情報および状況情報を含む登録要求をユーザ端末２０から受信するものとする。しかし、受信部１１が商品情報および状況情報を同時に受信することは必須ではなく、受信部１１はこれらの情報を異なるタイミングで受信してもよい。いずれにしても、受信部１１は受信した商品情報および状況情報を登録部１２に出力する。

ユーザ端末２０は、バーコードの読み取りにより得られた商品情報、または他の端末または装置から受信した商品情報を取得する。その後にユーザが登録要求の送信をユーザ端末２０に指示すると、ユーザ端末２０は状況情報を取得する。

ユーザ端末２０は少なくともユーザＩＤを状況情報として取得する。例えば、ユーザ端末２０は、ユーザが登録管理システム１を利用する前にユーザ端末２０上で所定の処理（例えば登録管理システム１へのログイン）を行った際に用いられたユーザＩＤを取得する。ユーザ端末２０は上記の登録アプリケーションを介してユーザＩＤを取得してもよい。

ユーザ端末２０は、自機の地理的位置（現在位置）を取得してもよい。ユーザ端末２０がＧＰＳ（全地球測位システム）を備える場合には、ユーザ端末２０はそのＧＰＳで得られた地理的位置（例えば、緯度経度）を取得することができる。あるいは、ユーザ端末２０は無線通信ネットワークのアクセスポイントの位置に基づいて自機の地理的位置を推定してもよい。ユーザ端末２０はバーコードが読み取られた日時または現在日時を読取日時として取得してもよい。

商品情報および状況情報を取得すると、ユーザ端末２０はこれらの情報を含む登録要求を生成し、この登録要求をサーバ１０に送信する。受信部１１はその登録要求を受信して登録部１２に出力する。

登録部１２は、登録要求（すなわち、商品情報および状況情報）に基づいて登録情報を生成し、その登録情報を登録データベース３１に格納する機能要素である。

まず、登録部１２は登録要求から商品情報および状況情報を抽出する。続いて、登録部１２は登録情報を格納するか否かを判定する。具体的には、登録部１２は対象ユーザデータベース３２を参照して、状況情報に含まれるユーザＩＤに対応する対象ユーザ情報のブロックフラグを確認する。そのブロックフラグが「１」である場合には、登録部１２は登録情報を格納することなく処理を終了する。一方、そのブロックフラグが「０」である場合、またはユーザＩＤに対応する対象ユーザ情報が存在しない場合には、登録部１２は登録情報を格納すると判定する。

登録処理を実行する場合には、登録部１２は商品情報および状況情報に基づいて登録情報を生成し、その登録情報を登録データベース３１に格納する。登録情報が登録対象（商品）とユーザＩＤとの組合せを示す限り、登録情報の生成方法は限定されない。例えば、登録部１２は商品情報および状況情報を互いに関連付けることで登録情報のレコードを一つ生成してもよい。あるいは、登録部１２は、登録情報の少なくとも一つのデータ項目の値を商品情報または状況情報に基づいて生成し、商品情報、状況情報、または生成した情報を用いて登録情報のレコードを一つ生成してもよい。例えば、登録要求から抽出した状況情報が読取日時を含んでいない場合には、登録部１２は自機のタイマを参照して現在日時を取得し、その現在日時を読取日時として設定してもよい。あるいは、登録部１２は受信部１１が登録要求を受信した日時を読取日時として設定してもよい。

特別処理部１３は、登録データベース３１内に重複して存在する商品情報（対象情報）を特定し、特定した商品情報に対応するユーザＩＤの少なくとも一部に対して特別処理を実行する機能要素である。「特別処理」とは、重複して存在する対象情報に対応するユーザがこれ以上対象情報を重複して登録しないことを目的とする処理である。したがって、特別処理は、さらなる対象情報の重複を牽制する処理でもよいし、さらなる対象情報の重複を防ぐ処理でもよい。

特別処理部１３は任意のタイミングで作動してよい。例えば、特別処理部１３は定期的に作動してもよいし、登録部１２が登録情報の１レコードを登録データベース３１に格納したことを契機として作動してもよい。

作動するタイミングになると、特別処理部１３は登録データベース３１を参照して、重複する商品情報（すなわち、２レコード以上存在する商品情報）を特定する。重複する商品情報が存在しない場合には、特別処理部１３は以降の処理を実行しない。重複する商品情報が存在する場合には、特別処理部１３はその商品情報を含む登録情報から１以上のユーザＩＤ（すなわち、特定した商品情報に対応するユーザＩＤ）を特定する。

続いて、特別処理部１３は特定した各ユーザＩＤについて、対象ユーザ情報の格納または更新を実行する。特別処理部１３は各ユーザＩＤについて、該ユーザＩＤに対応する商品（商品ＩＤとシリアル番号との組合せ）のうち、重複して登録されている商品の個数を重複回数として算出する。例えば、ユーザＡが商品Ｘを複数回登録している場合には、特別処理部１３は一回の重複が発生したと判定する。ユーザＡが商品Ｘを一回だけ登録し、ユーザＢが商品Ｘを一回だけ登録した場合にも、特別処理部１３は一回の重複が発生したと判定する。

特定した一つのユーザＩＤに対応する対象ユーザ情報が対象ユーザデータベース３２に未だ存在しない場合には、特別処理部１３はそのユーザＩＤの対象ユーザ情報を生成する。具体的には、特別処理部１３は、算出した重複回数を含み、かつ警告フラグおよびブロックフラグの双方が「０」である対象ユーザ情報を生成する。そして、特別処理部１３は生成した対象ユーザ情報を対象ユーザデータベース３２に格納する。一方、特定した一つのユーザＩＤに対応する対象ユーザ情報が対象ユーザデータベース３２に既に存在する場合には、特別処理部１３はその対象ユーザ情報の重複回数を算出した値で更新する。ただし、この更新で重複回数が変わらない場合があり得る。

特定したすべてのユーザＩＤについて対象ユーザ情報の格納または更新を実行すると、特別処理部１３は少なくとも対象ユーザデータベース３２を参照して、特別処理の対象となるユーザを特定する。本実施形態における特別処理の例として、警告と登録要求の拒否とを示す。警告とは、重複登録をこれ以上行わないように促すためのメッセージをユーザ端末２０に送信することである。登録要求の拒否とは、ユーザ端末２０から登録要求を受信しても登録情報を格納しないことである。本実施形態では、特別処理部１３は警告を受けたユーザに対してのみ登録要求を拒否するものとする。

特別処理の対象となるユーザを特定する方法は限定されず、以下のように様々な手法が考えられる。警告と登録要求の拒否とでユーザの特定方法が異なってもよい。

［警告］
特別処理部１３は対象ユーザデータベース３２を参照して、重複回数が閾値Ｔａ以上であり、かつ警告フラグが「０」であるユーザＩＤを警告対象として特定してもよい。ここで、閾値Ｔａは２以上であれば何でもよい。このような閾値Ｔａの設定は、個々のユーザに対して少なくとも一回は商品情報の重複登録が許容されることを意味する。あるいは、特別処理部１３はある限られた期間（例えば、最近の一か月または半年）における重複回数が閾値Ｔａ以上であり、かつ警告フラグが「０」であるユーザＩＤを警告対象として特定してもよい。

特別処理部１３は対象ユーザデータベース３２だけでなく登録データベース３１も参照して警告対象のユーザＩＤを特定してもよい。

例えば、特別処理部１３は対象ユーザデータベース３２を参照して、重複回数が閾値Ｔａ以上であり、かつ警告フラグが「０」であるユーザＩＤを特定する。続いて、特別処理部１３は特定した各ユーザＩＤについて重複登録の割合を求め、その割合が閾値Ｔｂ（％）以上である場合に該ユーザＩＤを警告対象として特定する。閾値Ｔｂは任意の基準で定めてよい。重複登録の割合は、登録情報で示される商品の個数（重複する商品の個数は１と見なす）に対する重複回数の割合である。例えば、ユーザＡが四つの商品Ｑ，Ｒ，Ｓ，Ｔを登録しており、該ユーザＡの重複回数が２であれば、重複登録の割合は５０％（２／４）である。あるいは、特別処理部１３はある限られた期間（例えば、最近の一か月または半年）における重複登録の割合が閾値Ｔｂ（％）以上であるユーザＩＤを警告対象として特定してもよい。

あるいは、特別処理部１３は対象ユーザデータベース３２を参照して、重複回数が閾値Ｔａ以上であり、かつ警告フラグが「０」であるユーザＩＤを特定する。続いて、特別処理部１３は特定した各ユーザＩＤについて、読取日時が消費期限より後である登録情報が存在するか否かを判定し、そのような登録情報が存在する場合に該ユーザＩＤを警告対象として特定する。

このように警告対象の特定方法は様々である。いずれにしても、特別処理部１３は、特定したユーザＩＤに対応するユーザ端末２０に警告のためのメッセージを送信すると共に、該ユーザＩＤの対象ユーザ情報の警告フラグを「１」に更新する。

［登録要求の拒否］
特別処理部１３は対象ユーザデータベース３２を参照して、重複回数が閾値Ｔｃ以上であり、かつ警告フラグが「１」であるユーザＩＤを拒否対象として特定してもよい。閾値Ｔｃは閾値Ｔａより大きい。あるいは、特別処理部１３はある限られた期間（例えば、最近の一か月または半年）における重複回数が閾値Ｔｃ以上であり、かつ警告フラグが「０」であるユーザＩＤを拒否対象として特定してもよい。

特別処理部１３は対象ユーザデータベース３２だけでなく登録データベース３１も参照して拒否対象のユーザＩＤを特定してもよい。

例えば、特別処理部１３は対象ユーザデータベース３２を参照して、重複回数が閾値Ｔｃ以上であり、かつ警告フラグが「１」であるユーザＩＤを特定する。続いて、特別処理部１３は特定した各ユーザＩＤについて重複登録の割合を求め、その割合が閾値Ｔｄ（％）である場合に該ユーザＩＤを拒否対象として特定する。閾値Ｔｄは任意の基準で定めてよい。あるいは、特別処理部１３はある限られた期間（例えば、最近の一か月または半年）における重複登録の割合が閾値Ｔｄ（％）以上であるユーザＩＤを拒否対象として特定してもよい。

あるいは、特別処理部１３は対象ユーザデータベース３２を参照して、重複回数が閾値Ｔｃ以上であり、かつ警告フラグが「１」であるユーザＩＤを特定する。続いて、特別処理部１３は特定した各ユーザＩＤについて、読取日時が消費期限より後である登録情報が存在するか否かを判定し、そのような登録情報が存在する場合に該ユーザＩＤを拒否対象として特定する。

あるいは、特別処理部１３は対象ユーザデータベース３２を参照して、重複回数が閾値Ｔｃ以上であり、かつ警告フラグが「１」であるユーザＩＤを特定する。続いて、特別処理部１３は特定した各ユーザＩＤについて、該ユーザＩＤと他のユーザＩＤとの双方が関連する重複登録を特定し、その重複登録の態様により拒否対象を特定する。

例えば、特定した一人のユーザが他の１ユーザとの間でのみ重複登録を複数回行っていた場合には、特別処理部１３はその特定したユーザを拒否対象としない。言い換えると、特定した一つのユーザＩＤの重複登録が一つの他のユーザＩＤとの間でのみ生じている場合には、特別処理部１３はその特定したユーザＩＤを拒否対象としない。図６に示すように、ユーザＡがユーザＢとの間でのみ重複登録を繰返し行っているような場合には、特別処理部１３はユーザＡを拒否対象として特定しない。これは、ユーザＡ，Ｂのつながりが強い（例えば家族）と推定して、ユーザＡに警告は発するがユーザＡを拒否対象とはしないを意図する。なお、特別処理部１３はこのようなユーザＡ，Ｂの一方のみを拒否対象としてもよい。

一方、特定した一人のユーザが複数の他ユーザとの間で重複登録を行っていた場合には、特別処理部１３はその特定したユーザを拒否対象とする。言い換えると、特定した一つのユーザＩＤの重複登録が複数の他のユーザＩＤとの間で生じている場合には、特別処理部１３はその特定したユーザＩＤを拒否対象とする。図７に示すように、ユーザＣが複数のユーザＤ，Ｅ，Ｆと重複登録を行っているような場合には、ユーザＣが不特定のユーザと繰返し重複登録を行っていると推定して、ユーザＣを拒否対象とする。

あるいは、特別処理部１３は特定した一人のユーザが所定数以上の他のユーザとの間で重複登録を行った場合に、その特定したユーザを拒否対象としてもよい。ここでの「所定数」とは、１以上の任意の数（閾値）である。あるいは、特別処理部１３は、特定した一人のユーザが他のユーザとの間で重複登録した割合が所定の閾値以上である場合に、その特定したユーザを拒否対象としてもよい。ここで、「他のユーザとの間で重複登録した割合」とは、特定したユーザの登録情報で示される商品の個数（重複する商品の個数は１と見なす）に対する、他のユーザとの間で重複登録した商品の個数の割合である。

あるいは、特別処理部１３はユーザ同士の関係を示すユーザ関係情報を所定のユーザ関係データベースから取得し、そのユーザ関係情報に基づいて重複登録の態様を判定してもよい。ユーザ関係情報は、ユーザ端末２０に記憶された電話帳であってもよいし、所定のサーバ（例えばソーシャル・ネットワーキング・サービス（ＳＮＳ）のサーバ）に記憶されたユーザ関係情報であってもよい。

特定した一人のユーザが、そのユーザ関係情報で示される別のユーザとの間でのみ重複登録を行っていた場合には、特別処理部１３はその特定したユーザを拒否対象としない。言い換えると、特定した一つのユーザＩＤの重複登録が、ユーザ関係情報で該ユーザＩＤと関連付けられている他のユーザＩＤとの間でのみ生じている場合には、特別処理部１３はその特定したユーザＩＤを拒否対象としない。これは、一定以上の強いつながりあるユーザ同士の間の重複登録については、警告の対象とはするが拒否の対象とはしないことを意図する。なお、特別処理部１３はこのような２ユーザの一方のみを拒否対象としてもよい。

一方、特定した一人のユーザが、ユーザ関係情報で示されない所定数以上の別のユーザとの間で重複登録を行っていた場合には、特別処理部１３はその特定したユーザを拒否対象とする。言い換えると、特定した一つのユーザＩＤの重複登録が、ユーザ関係情報で該ユーザＩＤと関連付けられていない所定数以上の他のユーザＩＤとの間で生じている場合には、特別処理部１３はその特定したユーザＩＤを拒否対象とする。ここでの「所定数」とは、１以上の任意の数（閾値）である。あるいは、特別処理部１３は、特定した一人のユーザが、ユーザ関係情報で示されない他のユーザとの間で重複登録した割合が所定の閾値以上である場合に、その特定したユーザを拒否対象としてもよい。ここで、「ユーザ関係情報で示されない他のユーザとの間で重複登録した割合」とは、特定したユーザの登録情報で示される商品の個数（重複する商品の個数は１と見なす）に対する、ユーザ関係情報で示されない他のユーザとの間で重複登録した商品の個数の割合である。

このように拒否対象の特定方法は様々である。いずれにしても、特別処理部１３は、特定したユーザＩＤのブロックフラグを「１」に更新する。

警告対象および拒否対象の特定方法は上記の例に限定されない。例えば、特別処理部１３は、拒否対象を特定する場合と同様に、図６および図７に示すような複数のユーザ間の重複登録の態様に基づいて警告対象を特定してもよい。あるいは、特別処理部１３は、拒否対象を特定する場合と同様に、電話帳のようなユーザ関係情報を参照して警告対象を特定してもよい。

特別処理部１３は、あるユーザを特別処理の対象とするか否かを判定する際に用いる閾値（例えば、上述した様々な「所定数」または「所定の閾値」）をユーザ毎に変えてもよい。例えば、特別処理部１３は各登録情報について、状況情報で示される地理的位置と各店舗の位置を示す店舗情報（例えば、図示しない店舗データベースに記憶された該店舗情報）とを比較して、対象情報（商品情報）が店舗で読み取られたか否かを判定する。そして、特別処理部１３は、店舗で読み取られたと判定された対象情報に対応するユーザについての閾値を、店舗で読み取られたと判定された対象情報のどれにも対応しないユーザについての閾値よりも低くする。この場合には、店舗で不正行為を行ったと推定されるユーザに対して、重複登録に対する特別処理をより早い段階で実行することができる。

特別処理部１３は、特定した対象情報、すなわち重複する対象情報を登録データベース３１から削除することなく上記の特別処理を実行する。この処理は、既に登録された情報は残しつつ、将来のさらなる重複登録の防止を図ることを意図するものである。

次に、図８および図９を参照しながら、登録管理システム１（サーバ１０）の動作を説明するとともに本実施形態に係る登録管理方法について説明する。

図８は登録情報を格納する処理の例を示す。まず、受信部１１が登録要求をユーザ端末２０から受信する（ステップＳ１１、受信ステップ）。続いて、登録部１２が対象ユーザデータベース３２を参照して、登録の可否を判定する（ステップＳ１２）。登録要求で示されるユーザＩＤに対応するブロックフラグが「０」である場合、またはそのユーザＩＤに対応する対象ユーザ情報が存在しない場合には、登録部１２は登録が可能であると判定する（ステップＳ１３においてＹＥＳ）。そして、登録部１２は登録要求に基づいて登録情報を生成し、その登録情報を登録データベース３１に格納する（ステップＳ１４、登録ステップ）。一方、登録要求で示されるユーザＩＤに対応するブロックフラグが「１」である場合には、登録部１２は登録が不可能であると判定し（ステップＳ１３においてＮＯ）、登録情報の生成および格納をすることなく処理を終了する。

図９は特別処理（特別処理ステップ）の例を示す。特別処理部１３はまず、登録データベース３１を参照して、重複して存在する対象情報（商品情報）を特定する（ステップＳ２１）。重複する対象情報を１以上特定した場合には（ステップＳ２２においてＹＥＳ）、特別処理部１３は特定した個々の対象情報に対応する１以上のユーザＩＤを特定する（ステップＳ２３）、上述したように、このユーザＩＤの特定方法については様々な手法が考えられる。続いて、特別処理部１３は特定したユーザＩＤに対応する対象ユーザ情報を格納または更新する（ステップＳ２４）。そして、特別処理部１３は特定した対象情報に対応するユーザＩＤの少なくとも一部に対する特別処理（例えば、警告、または登録要求の拒否）を実行する（ステップＳ２５）。上述したように、特別処理の具体的な手法および判定方法は様々であり、特定のものに限定されるものではない。

次に、図１０を参照しながら、コンピュータをサーバ１０として機能させるための登録管理プログラムＰ１を説明する。

登録管理プログラムＰ１はメインモジュールＰ１０、受信モジュールＰ１１、登録モジュールＰ１２、および特別処理モジュールＰ１３を含む。メインモジュールＰ１０は、ユーザからの要求に基づく情報の登録を統括的に実行する部分である。受信モジュールＰ１１、登録モジュールＰ１２、および特別処理モジュールＰ１３を実行することにより実現される機能はそれぞれ、上記の受信部１１、登録部１２、および特別処理部１３の機能と同様である。

登録管理プログラムＰ１は、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、半導体メモリなどの有形の記録媒体に固定的に記録された上で提供されてもよい。あるいは、登録管理プログラムＰ１は、搬送波に重畳されたデータ信号として通信ネットワークを介して提供されてもよい。

以上説明したように、本発明の一側面に係る登録管理システムは、登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信部と、対象情報およびユーザＩＤに基づいて、登録対象およびユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録部と、登録データベース内で重複する対象情報を特定し、該特定した対象情報に対応する１以上のユーザＩＤの少なくとも一部に対して特別処理を実行する特別処理部とを備える。

本発明の一側面に係る登録管理方法は、プロセッサを備える登録管理システムにより実行される登録管理方法であって、登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信ステップと、対象情報およびユーザＩＤに基づいて、登録対象およびユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録ステップと、登録データベース内で重複する対象情報を特定し、該特定した対象情報に対応する１以上のユーザＩＤの少なくとも一部に対して特別処理を実行する特別処理ステップとを含む。

本発明の一側面に係る登録管理プログラムは、登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信ステップと、対象情報およびユーザＩＤに基づいて、登録対象およびユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録ステップと、登録データベース内で重複する対象情報を特定し、該特定した対象情報に対応する１以上のユーザＩＤの少なくとも一部に対して特別処理を実行する特別処理ステップとをコンピュータに実行させる。

このような側面においては、登録情報の重複が発生すると、その重複登録を行ったユーザの少なくとも一部に対して特別処理が実行される。このように、重複登録を一旦は許容しつつ、その後にその特別処理を実行することで、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることができる。

他の側面に係る登録管理システムでは、特別処理部が、特定した対象情報を含む登録情報を登録データベースから削除することなく特別処理を実行してもよい。既に発生した重複登録を残しつつ特別処理を実行することで、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることができる。

他の側面に係る登録管理システムでは、特別処理が警告、または登録情報の格納の拒否であってもよい。警告、または登録情報の格納の拒否により、情報の重複登録を抑制することが可能になる。

他の側面に係る登録管理システムでは、特別処理部が、特定した対象情報に対応する１以上のユーザＩＤのうち、重複登録の回数または割合が所定の閾値以上であるユーザＩＤに対して特別処理を実行してもよい。重複登録が多いユーザに限って特別処理を実行することで、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることができる。

他の側面に係る登録管理システムでは、特別処理部が、特定した対象情報に対応する１以上のユーザＩＤのうち、所定数以上の他のユーザＩＤとの間で重複登録が生じているユーザＩＤに対して、または他のユーザＩＤとの間での重複登録の割合が所定の閾値以上であるユーザＩＤに対して特別処理を実行してもよい。他のユーザとの間で重複登録を行ったユーザに限って特別処理を実行することで、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることができる。

他の側面に係る登録管理システムでは、特別処理部が、ユーザ関係情報を記憶するユーザ関係データベースを参照し、特定した対象情報に対応する１以上のユーザＩＤのうち、ユーザ関係情報で示されない所定数以上の他のユーザＩＤとの間で重複登録が生じているユーザＩＤに対して、またはユーザ関係情報で示されない他のユーザＩＤとの間での重複登録の割合が所定の閾値以上であるユーザＩＤに対して特別処理を実行してもよい。特段のつながりがないと推定されるユーザとの間で重複登録を行ったユーザに限って特別処理を実行することで、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることができる。

他の側面に係る登録管理システムでは、特別処理部が、特定した対象情報に対応する１以上のユーザＩＤのうち、所定の限られた期間における重複登録の回数または割合が所定の閾値以上であるユーザＩＤに対して特別処理を実行してもよい。所定の期間に多く重複登録をしたユーザに限って特別処理を実行することで、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることができる。

他の側面に係る登録管理システムでは、登録対象が商品であり、特別処理部が、特定した対象情報に対応する１以上のユーザＩＤのうち、商品の消費期限の後に登録データベースに格納された登録情報で示されるユーザＩＤに対して特別処理を実行してもよい。消費期限を過ぎて対象情報を登録したようなユーザに限って特別処理を実行することで、情報の重複登録の抑制と情報登録の利便性とのバランスを取ることができる。

以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。

上記実施形態では特別処理部１３が重複する対象情報を登録データベース３１から削除することなく特別処理を実行したが、特別処理部はその重複を解消するために、重複する対象情報の少なくとも一部を削除してもよい。

上記実施形態では、特別処理部１３が、一度警告を送ったユーザに対して登録要求の拒否を実行したが、特別処理部は警告を送ることなく登録要求の拒否を実行してもよい。

対象情報および登録対象は、商品以外の物または事象に関するものでもよい。また、対象情報はユーザ端末においてバーコードの読み取り以外の手段により取得されてもよく、例えばユーザにより入力された情報であってもよい。

特別処理部は、重複登録の回数または割合を計算する際に、以前に警告対象または拒否対象と判定したユーザの登録情報を用いることなくその計算を実行してもよい。

サーバ１０とデータベース群３０内の少なくとも一つのデータベースとは一体でもよい。上記実施形態では登録管理システム１がデータベース群３０を備えたが、各データベースの設置箇所は限定されない。例えば、データベース群３０またはその中のデータベースの少なくとも一つが、登録管理システム１とは別のコンピュータ・システムの中に存在してもよい。

１…登録管理システム、１０…サーバ、１１…受信部、１２…登録部、１３…特別処理部、２０…ユーザ端末、３０…データベース群、３１…登録データベース、３２…対象ユーザデータベース、Ｐ１…登録管理プログラム、Ｐ１０…メインモジュール、Ｐ１１…受信モジュール、Ｐ１２…登録モジュール、Ｐ１３…特別処理モジュール。

Claims (10)

1. 登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信部と、
   前記対象情報および前記ユーザＩＤに基づいて、前記登録対象および前記ユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録部と、
   前記登録データベース内で重複する前記対象情報を特定し、該特定した対象情報に対応する１以上の前記ユーザＩＤの少なくとも一部に対して特別処理を実行する特別処理部と
   を備える登録管理システム。
2. 前記特別処理部が、前記特定した対象情報を含む前記登録情報を前記登録データベースから削除することなく前記特別処理を実行する、
   請求項１に記載の登録管理システム。
3. 前記特別処理が警告、または前記登録情報の格納の拒否である、
   請求項１または２に記載の登録管理システム。
4. 前記特別処理部が、前記特定した対象情報に対応する前記１以上のユーザＩＤのうち、重複登録の回数または割合が所定の閾値以上であるユーザＩＤに対して前記特別処理を実行する、
   請求項１〜３のいずれか一項に記載の登録管理システム。
5. 前記特別処理部が、前記特定した対象情報に対応する前記１以上のユーザＩＤのうち、所定数以上の他のユーザＩＤとの間で重複登録が生じているユーザＩＤに対して、または他のユーザＩＤとの間での重複登録の割合が所定の閾値以上であるユーザＩＤに対して前記特別処理を実行する、
   請求項１〜３のいずれか一項に記載の登録管理システム。
6. 前記特別処理部が、
   ユーザ関係情報を記憶するユーザ関係データベースを参照し、
   前記特定した対象情報に対応する前記１以上のユーザＩＤのうち、前記ユーザ関係情報で示されない所定数以上の他のユーザＩＤとの間で重複登録が生じているユーザＩＤに対して、または前記ユーザ関係情報で示されない他のユーザＩＤとの間での重複登録の割合が所定の閾値以上であるユーザＩＤに対して前記特別処理を実行する、
   請求項１〜３のいずれか一項に記載の登録管理システム。
7. 前記特別処理部が、前記特定した対象情報に対応する前記１以上のユーザＩＤのうち、所定の限られた期間における重複登録の回数または割合が所定の閾値以上であるユーザＩＤに対して前記特別処理を実行する、
   請求項１〜３のいずれか一項に記載の登録管理システム。
8. 前記登録対象が商品であり、
   前記特別処理部が、前記特定した対象情報に対応する前記１以上のユーザＩＤのうち、前記商品の消費期限の後に前記登録データベースに格納された登録情報で示されるユーザＩＤに対して特別処理を実行する、
   請求項１〜３のいずれか一項に記載の登録管理システム。
9. プロセッサを備える登録管理システムにより実行される登録管理方法であって、
   登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信ステップと、
   前記対象情報および前記ユーザＩＤに基づいて、前記登録対象および前記ユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録ステップと、
   前記登録データベース内で重複する前記対象情報を特定し、該特定した対象情報に対応する１以上の前記ユーザＩＤの少なくとも一部に対して特別処理を実行する特別処理ステップと
   を含む登録管理方法。
10. 登録対象を示す対象情報とユーザＩＤとをユーザ端末から受信する受信ステップと、
    前記対象情報および前記ユーザＩＤに基づいて、前記登録対象および前記ユーザＩＤの組合せを示す登録情報を生成し、登録情報を登録データベースに格納する登録ステップと、
    前記登録データベース内で重複する前記対象情報を特定し、該特定した対象情報に対応する１以上の前記ユーザＩＤの少なくとも一部に対して特別処理を実行する特別処理ステップと
    をコンピュータに実行させる登録管理プログラム。

Images