JP2018010603A - レンズ販売システム - Google Patents

Abstract

【課題】検眼をしたレンズの度数情報をユーザが取得することを可能とするレンズ販売システムを提供すること。提供すること。【解決手段】店舗側端末は、検眼識別情報と度数情報とを関連付けた検眼履歴を作成し、ユーザ識別情報と検眼識別情報を組み合わせてデータベースサーバに送信する。データベースサーバは、検眼識別情報をユーザ識別情報ごとに対応付けたユーザデータベースを構築し、ユーザのユーザ識別情報について、対応する検眼識別情報を特定し、検眼管理端末にアクセスすることにより、検眼識別情報に基づいた度数情報を取得する。【選択図】図１

Description

本発明は、レンズの販売システムに関する。

通常、メガネやコンタクトレンズなどを販売する場合、検眼してから適切なレンズを選択するが、このとき、顧客の側にレンズの度数データが適切に伝えられるということは一般的ではなかった。検眼の際には検眼データとして記録され、レンズの販売の際に、顧客にレンズを提供する際にレンズの度数データが用いられるが、度数データを顧客ごとに管理して、必要とする顧客に提示するということは一般的ではない。

その理由として、レンズの度数データは、レンズの特性を示す多岐にわたるデータからなるものであり、視力が何度というような単純なデータではなく、またデータ形式も一般の利用者にとってなじみのないものであることから、提供するのに適していないというのが１つである。もう１つとして、検眼をしてその流れでレンズを販売する慣行上、度数データのみを単独で流通させるのは都合が悪く、検眼をした店舗においてそのままレンズを購入させ、再度の来店の場合には店舗において過去の度数データを用いて販売する方が望ましいという点がある。

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

たとえば特許文献１には、カルテ情報及びレンズ属性情報を入力して、カルテ情報及びレンズ属性情報に基づく購入データをＰＯＳ端末に送信する店舗システムが記載されている。しかしながら、これはＰＯＳ端末に送信して顧客ごとの売上登録処理をするものであって、登録されたカルテ情報やレンズ属性情報を顧客が再度利用できるようにアクセス可能に管理されたものではない。

これに対して、本実施の形態では、検眼をしたレンズの度数情報をユーザが取得することを可能とするレンズ販売システムを提供することを目的とする。

本発明にかかるレンズ販売システムは、店舗側端末とデータベースサーバを備え、互いにネットワーク接続される。前記店舗側端末は、ユーザが装着したレンズの度数情報を含む検眼結果を入力する入力部と、前記検眼結果を識別する検眼識別情報と前記入力された度数情報とを関連付けた検眼履歴を作成することにより、検眼データベースを構築する検眼管理部と、ユーザを識別するユーザ識別情報と前記作成された検眼履歴を組み合わせてユーザレンズ情報を作成し、作成された前記ユーザレンズ情報を前記データベースサーバに送信するユーザ管理部を備える。前記データベースサーバは、前記ユーザ管理部から送信されたユーザレンズ情報に基づき、少なくとも１つ以上の検眼履歴をユーザ識別情報ごとに対応付けたユーザデータベースを構築するデータベース部と、アクセス認証の結果アクセスを認められたユーザのユーザ識別情報について、前記ユーザデータベースを参照することにより、対応する検眼識別情報を特定する特定部と、前記ユーザデータベースを参照することにより、前記特定部によって特定された検眼識別情報に基づいた度数情報を取得する度数検索部と、を備える。

本実施形態のレンズ販売システムによれば、検眼をしたレンズの度数情報をユーザが取得することが可能となる。

レンズ販売システムのシステム構成図。 検眼データベースを示す図。 検眼段階のフローチャート。 顧客情報登録処理を示すフローチャート。 販売入力データと販売管理データを示す図。 販売管理データの生成処理を示すフローチャート。 販売管理データの出力処理を示すフローチャート。 ユーザデータベースの登録処理を示すフローチャート。 ユーザデータベースサーバの概要を示す図。 検眼履歴に基づく購入処理を示すフローチャート。 度数情報の一覧表示を表示する表示画面の一例。 同一属性の度数情報の一覧表示を表示する表示画面の一例である。 購入履歴に基づく再購入処理を示すフローチャート。 購入履歴の一覧表示を表示する表示画面の一例。 同一属性の購入履歴の一覧表示を表示する表示画面の一例。 保証書コードと度数情報を表示する表示画面の一例。 度数コードの入力画面の一例。 保証書コードに基づく度数情報の取得処理を示すフローチャート。 保証処理の入力段階のフローチャート。 保証処理を示すフローチャート。 保証処理のデータベース登録を示すフローチャート。 レンズ販売システムの他のシステム構成図。 販売情報の概要を示す図。 度数情報を取得して購入する処理を示すフローチャート。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本発明は、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、以下の図面の記載において、同一または類似の部分には同一または類似の符号を付して表している。図面は模式的なものであり、必ずしも実際の寸法や比率等とは一致しない。図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることがある。

図１は、レンズ販売システムのシステム構成図を示す。レンズ販売システムは、店舗端末２８とユーザデータベースサーバ３０を、ネットワークを介して互いに接続することで構成されている。店舗端末２８の他に、さらに他の店舗端末２９もまたネットワークを介して接続されている。他の店舗端末２９は、１つに限らず数多く接続されるが、説明のためこれ以外は図示しない。実際は多数の他の店舗端末２９が備えられる構成となる。

なお、他の店舗端末２９の構成は店舗端末２８と同一であり、店舗端末２８について説明したものは、他の店舗端末２９でも同様である。外部端末の一例である携帯端末３５もネットワークを介して接続可能であり、携帯端末３５からユーザデータベースサーバ３０にアクセスする。外部端末としては携帯端末３５を例に挙げて説明するが、携帯端末３５に替えて、ネットワークを介して接続可能な各種情報処理装置とすることができる。

店舗端末２８は、検眼端末１０及び販売管理端末２０を備え、それぞれネットワークに接続される。検眼端末１０及び販売管理端末２０はローカルエリアネットワークへの接続として、外部との接続をインターネットやＶＰＮ接続とする構成としてもよく、それぞれインターネットなどの外部ネットワークに接続されるように構成してもよい。

なお、図１では店舗端末２８としてネットワークに接続する構成を説明しているが、検眼端末１０及び販売管理端末２０をそれぞれ単独の構成として、それぞれネットワークに接続する構成としてもよく、この場合の構成を図２１に示す。図２１のように構成した場合も、全体処理としては図１に示したものと同一であるが、相違する点もあるので、その点は後述する。

検眼端末１０、販売管理端末２０、ユーザデータベースサーバ３０は、それぞれＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）と、画像処理部と、メモリを備えている。ＣＰＵ、ＲＯＭ、ＲＡＭ、画像処理部及びメモリは、バスを介して相互に接続されている。

ＣＰＵは、ＲＯＭに記録されているプログラム、又はメモリからＲＡＭにロードされたプログラムに従って各種の処理を実行する。ＲＡＭには、ＣＰＵが各種の処理を実行する上において必要なデータ等も適宜記憶される。

画像処理部は、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）や、ＶＲＡＭ（Ｖｉｄｅｏ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等から構成されており、ＣＰＵと協働して、画像のデータに対して各種画像処理を施す。

メモリは、ＤＲＡＭやキャッシュメモリ、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等何らかの記憶媒体が挙げられる。メモリは、バスにより接続されるもののみならず、ドライブを介して読み書きされるものも含まれる。本実施形態で記憶されたデータは、一時的記憶も不揮発性メモリによる長期記憶の場合も、このメモリにいったん記憶するものとして説明する。

検眼端末１０、販売管理端末２０、ユーザデータベースサーバ３０のそれぞれには入出力インターフェースが接続されている。入出力インターフェースを介して、表示部、撮像部、入力部、通信部が接続されている。入力部は、各種ボタンにより構成され、ユーザの指示操作を受け付ける。通信部は、インターネットを含むネットワークを介して他の装置との間で行う通信を制御する。

検眼端末１０、販売管理端末２０、ユーザデータベースサーバ３０は、それぞれ以上の各構成を備えるが、機能的構成についてはそれぞれ後述する。各機能的構成は、ＣＰＵ、ＲＯＭ、ＲＡＭ、画像処理部及びメモリの協働動作により機能的に実現される。これらの各部の機能は電子回路又はプログラムによって提供されるモジュール構成であり、プログラムについてはＲＯＭに格納され、ＣＰＵにより適宜読み出しながら各部と協働することで実行される。図１に示した各機能的構成については、図２以降の各図をそれぞれ参照しながら説明する。

（検眼端末１０について）
検眼端末１０は、検眼の際に検眼結果を入力して記録し、必要に応じてデータを送信する端末であり、機能的構成として検眼データベース１１、入力部１２、検眼管理部１３を備える。

入力部１２は、ユーザが装着したレンズの度数情報を含む検眼結果を入力する。具体的にはユーザの指示操作を受け付ける各種ボタンやスキャン用装置などを備え、操作を通して度数情報を含む検眼結果を入力する。検眼結果とは、主に検眼に用いたレンズについての情報であり、度数情報は、検眼に用いたレンズの度数に関する情報である。

度数情報は、左眼と右眼のそれぞれについてのレンズの度数が挙げられる。レンズの度数は、いわゆるディオプトリー（Ｄ）と呼ばれるものであり、レンズの焦点距離の逆数によって定義される。具体的には、ＳＰＨ球面度数が挙げられる。度数情報については、左眼と右眼のそれぞれについての乱視軸の情報もまた挙げられる。

乱視は、円柱度数と円柱軸で表される。この円柱度数が乱視度数ということになり「ＣＹＬ」と呼ばれる。円柱軸は乱視の角度を表し、「ＡＸＩＳ」と呼ばれます。これらの乱視度数、乱視軸の角度もまた、度数情報の１つとして挙げられる。

さらに、ＰＤ値と呼ばれる瞳孔間距離もまた度数情報の１つとして挙げられる。瞳孔間距離は、一眼の瞳孔中心から他眼の瞳孔間中心までの距離である。さらに、ＣＤ値と呼ばれる、一対のレンズの心取り点間に要求される水平距離である心取り点間距離も挙げられる。さらにＯＣＤ値と呼ばれる、一対のレンズの水平方向の光学中心間距離も挙げられる。さらにＡＤＤ（加入度数）、ＥＰ（目の位置）など、様々なデータが度数情報として用いられる。

以上のように度数情報は多岐にわたる情報であるので、入力部１２は単純に数値を操作により入力してもよいが、レンズに付属しているコード情報を読み取ることにより、度数情報を読み込んで入力することもできる。

検眼管理部１３は、検眼結果を識別する検眼識別情報と、入力された度数情報とを関連付けた検眼履歴を作成する。検眼管理部１３は、作成した検眼履歴からなる検眼データベース１３を構築する。検眼データベース１３については図２に示す。

図２では、受付ＩＤ１５が検眼識別番号の例として挙げられる。受付ＩＤ１５には、たとえば１０１、１０２、２０４、２０５などの数字が割り振られる。このように、検眼をした際の検眼結果については、それぞれ検眼結果ごとに受付ＩＤ１５が割り当てられる。受付ＩＤ１５は、検眼結果ごとに割り当てられる情報であるので、検眼結果を識別する情報となる。

検眼管理部１３は、入力された度数情報を以上の受付ＩＤ１５に関連付ける。この関連付けられた組が検眼履歴１６となる。検眼管理部１３は、受付ＩＤ１５と度数情報を１つの組とした検眼履歴１６について、複数集めた検眼データベース１１を、図２に示すように構築する。

図３は、検眼段階のフローチャートを示す。最初に検眼端末１０に対して入力部１２により受付登録をする（ステップ１０５）。受付登録の結果、受付ＩＤ１５が割当てられるので、検眼端末１０は受付票を発行する（ステップ１１０）。受付票にはバーコードなどの受付ＩＤ１５を特定することができる情報を印刷する。そして、入力部１２を介して度数情報を入力すると（ステップ１１５）、検眼管理部１３は、入力された度数情報を受付ＩＤ１５に関連付ける（ステップ１１５）。関連付けによって検眼履歴１６を作成したら、これを検眼データベース１１のデータの１つとして構築する。

（販売管理端末２０について）
販売管理端末２０は、キャッシュレジなどの販売機能と、販売に関するデータを管理する販売管理機能を有する販売端末として備えられる。販売端末は、販売の際に店舗に設けられる端末で、レジ機能のほか、販売した商品の情報や、売上に関する情報を取り扱う。本実施例においては販売端末のうち販売管理機能に着目して、販売管理端末２０として説明する。販売管理端末２０は、機能的構成として度数取得部２１と、販売管理部２２と、ユーザ管理部２３を有する。販売管理端末２０では、度数情報、顧客情報、フレーム情報、レンズ情報も入力する。この一連の販売管理端末２０への入力処理を、図４を参照して説明する。

図４は、レンズ販売の際の顧客情報登録処理を示すフローチャートを示す。まず販売管理端末にて受付票の照合を行う（ステップ２００）。図３を参照して説明した検眼プロセスにおいて、ステップ１１０で受付票を発行しているので、これを受け取った被験者は購入にあたってこの受付票を持参する。オペレータは、この受付票を受け取って、販売管理端末２０に入力し、販売管理端末２０で受付処理する。受付票にはバーコードやＱＲコード（登録商標）などの情報が記載されており、これを読み取って入力するが、数字や記号を記載しておいて、これを手入力してもよい。そして度数取得部２１は、受付票の情報に基づいて検眼識別情報（受付ＩＤ１５）を解析して特定する（ステップ２１０）。

ここで、受付ＩＤ１５は必ずしも１つとは限らない。検眼は複数回行われている場合があるからである。特に、レンズの用途について、遠方を見る自動車運転用とコンピュータなどの近方を見るＰＣ用では必要とされるレンズの度数も異なる。このため複数回の検眼を行った結果複数の受付ＩＤ１５が発行され、その結果複数の受付票が発行されている場合がある。また異なる日や店舗で検眼している場合もある。これらの複数の受付票を、購入段階で複数提示した場合、複数の受付ＩＤを取得することになる。

次に販売管理部２２は、レンズとともに販売する商品の商品情報として、レンズ情報及びフレーム情報を取得する（ステップ２１５）。レンズとともに販売する商品とは、販売対象がメガネの場合は、特にメガネのフレームが挙げられる。販売対象としてはメガネのほかコンタクトレンズなども挙げられ、いずれの場合も付属品に関する情報が商品情報として挙げられる。これらの商品に関する情報の一例として、たとえばフレーム情報とレンズ情報を挙げて説明する。

フレーム情報には、フレームを特定する情報、及びフレームに関する付随情報を含む。たとえば、フレームＩＤや、価格、色、形などの情報を含むことができる。フレームの１つ１つに対してフレームＩＤが割り当てられており、フレームＩＤごとに該当するフレームについての価格（料金）を含む各種情報が対応付けられて販売管理端末２０又はその他の外部サーバに記憶されている。

レンズ情報には、レンズを特定する情報、及びレンズに関する付随情報を含む。たとえば、レンズＩＤや、価格、色、性能などの情報を含むことができる。フレームと同様レンズについても、１つ１つに対してそれぞれレンズＩＤが割り当てられている。ただしレンズについては度数も考慮すると膨大な種類となるので、度数情報とは分けた部分でレンズＩＤを割り当てる。

たとえば通常の効果のレンズ、ＰＣ用のブルーカットしたレンズ、又は強力にブルーカットしたレンズ等の、レンズの種類に応じてレンズＩＤを割り当てている。レンズＩＤごとに該当するレンズについての料金を含む各種情報が対応付けられて販売管理端末２０又はその他の外部サーバに記憶されている。また、フレーム、レンズ以外の各種商品情報についても、それぞれＩＤを割り当てることにより、各種商品を特定する情報及び付随する情報を記憶する。

次にユーザ管理部２３は、ユーザ識別情報としての顧客ＩＤの入力を受け付ける。入力を受け付けるに際して、入力対象となる顧客について顧客ＩＤが既に登録されているか否かを判定する（ステップ２２０）。顧客ＩＤが既に登録されている場合（ステップ２２０：Ｙｅｓ）、ユーザ管理部２３は、顧客ＩＤの入力を受け付ける（ステップ２２５）。

顧客ＩＤが登録されていない場合（ステップ２２０：Ｎｏ）、ユーザ管理部２３は、顧客情報の入力を受け付ける（ステップ２３０）。ここで顧客情報は、顧客の氏名、住所、電話番号、メールアドレスや、各種アンケート結果などの当該顧客についての各種情報である。入力されたら、その顧客について顧客ＩＤを割り当て、割り当てた顧客ＩＤを発行する（ステップ２３５）。

以上のように入力された又は新たに発行された顧客ＩＤについて、ステップ２１０で特定された受付ＩＤを対応付ける（ステップ２４０）。

図５は、レンズ販売の際の販売入力データと販売管理データを示す。以上のように受付ＩＤが特定され、顧客ＩＤに対応付けられ、フレームＩＤ、レンズＩＤが入力されることにより販売入力データ２５が作成される。したがって、販売入力データ２５は受付ＩＤ、顧客ＩＤ、フレームＩＤ、レンズＩＤを含み、それぞれ対応付けられているが、これ以外の同時に購入される商品情報も含むことができる。フレーム、レンズについてはフレームＩＤ、レンズＩＤ以外の情報をそれぞれ含んでもよい。

また、後述のステップ３０５で作成する保証情報も販売管理情報２６に含む。販売管理部２２は、販売管理情報２６を生成する場合に、販売管理情報２６の元となる度数情報に関連付けられた検眼識別情報（受付ＩＤ１５）を、当該受付ＩＤ１５と対応する別のコード形式の証明情報、例えば上述の保証情報に変換して、販売情報２８とともに含めて証明書として発行する。保証情報の発行は、販売情報２８の中に含めてもよいし、別々のシートとしてもよい。

そして、作成された販売入力データ２５から、販売処理に必要となる販売管理データ２６を作成する。このための一連の処理について、図６を参照して説明する。

図６は、販売管理データの生成処理を示すフローチャートを示す。まず度数取得部２１は、購入対象の受付ＩＤ１５を選択する（ステップ２５０）。基本的には検眼を１回行うことで受付ＩＤ１５は１つ発行されることになるので、その場合はその１つの受付ＩＤ１５を自動的に選択することになるが、上述のように複数の受付ＩＤ１５を取得する場合があるので、その場合は、その複数の中から１つを選択する。

次に度数取得部２１は、選択した受付ＩＤ１５からレンズ度数を取得する（ステップ２５５）。つまりステップ２１０で特定することにより取得した受付ＩＤ１５から、検眼管理端末１０にアクセスして入力された受付ＩＤ１５に関連付けられた度数情報を取得する。受付ＩＤと度数情報は、図２に示したように履歴情報として組となって検眼データベース１１にデータベース化されているので、検眼端末１０にアクセスすることにより、度数情報を取得する。

なお、ここでは選択した受付ＩＤ１５についてのみレンズ度数を取得したが、ステップ２５０とステップ２５５を逆にして、複数の受付ＩＤ１５のすべてについてレンズ度数を取得しておき（ステップ２５５）、そこから最新となるものを１つを選択（ステップ２５０）してもよい。

次に、販売管理部２２は、販売入力データ２５に含まれるフレームＩＤから料金情報を取得する（ステップ２６０）。次に、販売管理部２２は、販売入力データ２５に含まれるレンズＩＤから料金情報を取得する（ステップ２６５）。フレーム、レンズ以外の各種商品情報についても、ＩＤを割り当てて料金管理を行うこともできる。

以上によりフレームの料金とレンズの料金が求められるので、販売管理部２２はさらにフレームの料金とレンズの料金を合算し、その他各種商品やサービスがある場合にはそれらを入力して合算する。それにより、販売管理部２２は、合計金額を算出し、販売画面に表示する（ステップ２７０）。

この際に商品の受け渡しはその場で行うか、後日の受け取りかを確認することにより、確認結果に基づいて、販売管理部２２は商品受け渡しフラグを特定する（ステップ２７５）。商品受け渡しフラグは、商品をすでに受け渡したか、後日の受け渡しとするかを特定するフラグである。以上により、図５に示した販売管理データ２６を構成する各種情報は得られたので、以上の処理により販売管理部２２は、図５に示した販売管理データ２６を生成する。

図７は、販売管理データの出力処理を示すフローチャートを示す。まず、販売管理部２２は、保証情報を作成する（ステップ３０５）。保証情報として、保証コード、保証回数、保証期間、保証開始日の情報が挙げられる。保証コードは、受付ＩＤ１５に基づいた、受付ＩＤに対応するコード情報であり、バーコード、ＱＲコード（登録商標）として生成することができる。また、受付ＩＤの数字に、チェックデジットの数字を組み合わせたデータとすることもできる。

保証回数は、たとえば２回まで購入した商品、レンズを交換することができるとした交換の残り回数であり、購入後にレンズ交換をするごとに減少する値である。保証期間はたとえば６か月、１年、などの保証開始日を起算日とした保証を受けることが期間の値である。保証開始日は、通常は商品の購入日をそのまま保証日とするが、料金の支払いと商品の受取日が異なる場合には、商品の受取日をもって保証開始日を起算することができる。

さらに度数コードを作成する（ステップ３１０）。度数コードは、受付ＩＤ１５に基づいた、受付ＩＤに対応するコード情報であり、バーコード、ＱＲコード（登録商標）として生成することができる。また、受付ＩＤの数字に、チェックデジットの数字を組み合わせたデータとすることもできる。

そして、販売管理データ２６に基づき画面表示をして、表示画面を介して店舗の販売スタッフは商品の販売処理、会計処理を行う（ステップ３１２）。すなわち表示画面に表示された金額の支払いを受け、販売完了のデータを記録する。このときにレンズを含む商品を受け渡す場合は受け渡しを行い、後日受け渡しの場合はその旨を記載したシートを印刷して手渡す。

販売の完了を受けて販売管理部２２は、販売管理データ２６に基づいて販売完了データを生成する。すなわち、商品情報及び度数取得部２１によって取得された度数情報に基づいた販売完了データを生成、出力する（ステップ３１５）。販売完了データとは、販売に際して顧客に提示する情報が挙げられた、最終的な料金や、商品の詳細、保証等についての情報である。

さらに、顧客ＩＤごとに属性情報を設定することもできる。属性情報とは、例えば同一の家族であるか、もしくは同一の会社であるかどうかなど、同一属性か否かを識別するための情報である。ある顧客ＩＤと他の顧客ＩＤとの間で同一の属性かどうか、例えば親と子などの家族関係であるかどうかの情報を、属性情報として販売管理データ２６に含めて生成することができる。そして、ユーザ管理部２３は、販売管理データ２６をデータベースサーバ３０に送信する（ステップ３３０）。

（ユーザデータベースサーバ３０について）
ユーザデータベースサーバ３０は、顧客ＩＤごとの各顧客の管理データや販売に関するデータを一元的に管理するデータベースを備えたサーバである。ユーザデータベースサーバ３０は、機能的構成としてユーザデータベース３１、特定部３２、データベース部３３、度数検索部３４、再販売処理部３７及び保証処理部３８を備える。

図８は、ユーザデータベースの登録処理を示すフローチャートを示す。まずデータベース部３３は、ユーザ管理部２３から販売管理データ２６を受信する（ステップ３５０）。データベース部３３は、販売管理データ２６に含まれる顧客ＩＤについて、ユーザデータベース３１を参照することにより、該当する情報が登録されているか否かを確認、判定する（ステップ３６０）。

ユーザデータベース３１は、ユーザ管理部２３から送信された販売管理データ２６に基づいて、図９に示すように構築されている。ユーザデータベース３１は、図９に示すように、取得した販売管理データ２６を、顧客ＩＤごとのデータとして管理しているデータベースである。

受信した販売管理データ２６に含まれる顧客ＩＤについて登録されていると判定された場合（ステップ３６０：Ｙｅｓ）、データベース部３３は、ユーザデータベース３１を参照することにより、ユーザ管理部２３から送信された販売管理データ２６に含まれる顧客ＩＤを検索する（ステップ３６５）。登録されていないと判定された場合（ステップ３６０：Ｎｏ）、ユーザ管理部２３から送信された販売管理データ２６に含まれる顧客ＩＤについて、ユーザデータベース３１に項目を作成し、送信された販売管理データ２６をユーザデータベース３１に登録する（ステップ３７０）。

そして、いずれの場合についても検索または新規作成した所定の顧客ＩＤの項目の１つとして、送信された販売管理データ２６を対応させて登録する（ステップ３７５）。このようにしてデータベース部３３は、ユーザ管理部２３から送信された販売管理データ２６に基づき、少なくとも１つ以上の検眼識別情報（受付ＩＤ１５）をユーザ識別情報（顧客ＩＤ）ごとに対応付けたユーザデータベース３１を構築する。

以上のように、受付票と顧客情報に基づき販売管理データ２６を生成し、販売管理データ２６に基づき、顧客に渡す印刷物の記載対象となる販売完了データが生成された。その一方で販売管理データ２６を送信することにより、ユーザデータベース３１に顧客ごとのデータを追加することができる。

（度数情報取得の第１の例）
以上のように構築されたユーザデータベース３１から、ユーザの入力処理により、過去に検眼された度数情報を取得し、再度の検眼を繰り返すことなく購入する商品を選択する処理について説明する。携帯端末３５から入力することによりインターネットを通じて購入処理する場合を中心に説明するが、携帯端末３５に限らず、ネットワークに接続されているコンピュータや、その他店舗端末を通じての購入処理としてもよい。

図１０Ａは、検眼履歴に基づく購入処理を示すフローチャートである。まずユーザは、携帯端末３５から顧客情報を入力する（ステップ５００）。顧客情報としては、顧客ＩＤとパスワードを入力することができるが、この他にも顧客を特定する情報と、その顧客であることを認証する情報を入力することにより、アクセス認証のための入力を行う。

ここで、各顧客ＩＤについては属性情報を設定していたので、設定により、同一属性に係る顧客ＩＤについては同様にアクセス可能としてもよい。つまり所定の顧客ＩＤについてアクセスしたことにより、複数の顧客ＩＤについての情報についてアクセスすることになる。後述の説明では単一の顧客ＩＤを例にして説明するが、複数の顧客ＩＤのついての情報を、顧客ＩＤごとに区別して検索、取得し、画面表示していくことも可能である。

入力を受けて、特定部３２は、顧客情報を認証情報によりアクセス認証をして、アクセスの可否を決定する。アクセスを認められない場合は処理を終了する。アクセス許可の場合に次の処理に進む。アクセス認証により許可された場合、携帯端末３５とユーザデータベースサーバ３０との間で通信処理を行う。

次に、特定部３２は、アクセス認証の結果アクセスを認められたユーザのユーザ識別情報（顧客情報、顧客ＩＤ）について、ユーザデータベース３１を参照することにより、対応する検眼識別情報（受付ＩＤ１５）を検索して特定する（ステップ５０５）。そして、データベース部３３は、特定部３２によって特定された複数（少なくとも１つ）の受付ＩＤ１５に対応付けられた度数情報をユーザデータベース３１から取得して（ステップ５１５）、携帯端末３５に送信する。そして、度数検索部３４は、受付ＩＤ１５のそれぞれに対応付けられた複数の度数情報について度数一覧を作成し、携帯端末３５に一覧表示する（ステップ５２０）。その結果、携帯端末３５ではユーザ自身が過去に検眼したレンズの度数情報を取得できる。

図１０Ｂは、度数情報の一覧表示を表示する表示画面の一例である。携帯端末３５は、複数の検眼識別情報（受付ＩＤ１５）のそれぞれに基づいた複数の度数情報の一覧を、表示画面４０の下部、一覧表示領域４１に表示する。一方で一覧表示領域４１に表示される複数の度数情報のうちの１つを指示マーク４２が指すように表示されている。この指示マーク４２を操作することにより、表示された一覧表示領域の複数の項目の中から、項目の１つを選択する。

一方で表示画面４０の上部には、購入対象となるメガネについての情報を表示する。図１０Ｂの例では、商品名と商品の写真を表示している。該当する商品については、指示マーク４２に当てられた検眼識別情報（受付ＩＤ１５）、度数情報に対応して購入された商品の情報を表示してもよく、また、図１０Ｂの表示画面の前に商品一覧を表示しておき、商品一覧から所定の商品を選択した後に図１０Ｂの画面に移行してもよい。この場合、商品一覧から選択した商品についての情報を表示画面４０の上部に表示する。

携帯端末３５の表示画面４０を介して検眼識別情報（受付ＩＤ１５）、度数情報に対応する項目の１つを選択した場合、携帯端末３５はその選択結果をユーザデータベースサーバ３０に送信する。ユーザデータベースサーバ３０の再販売処理部３７は、この送信結果、すなわち度数検索部３４によって作成された度数一覧に含まれる複数の度数情報のうち１つについての購入指示を受け付けて、再販売処理を実行する（ステップ５２５）。

また、顧客ＩＤごとに属性情報を設定し、同一の属性情報からのアクセスについて、同一の属性情報にかかる顧客ＩＤの各種情報を表示することもできる。属性情報の例として同一の家族の場合、すなわち、親の顧客ＩＤでアクセスした場合に、配偶者や子の顧客ＩＤにかかる情報を表示する場合について説明する。

図１１は、同一属性の度数情報の一覧表示を表示する表示画面の一例である。表示画面の概要は図１０Ｂに示したものと同一であり、参照符号は同一のものを用いる。この場合特定部３２は、アクセス認証の結果アクセスを認められたユーザのユーザ識別情報（顧客情報、顧客ＩＤ）に加え、同一属性のユーザ識別情報について、ユーザデータベース３１を参照することにより、対応する検眼識別情報（受付ＩＤ１５）を検索して特定する。次に、そして、データベース部３３は、受付ＩＤ１５に対応付けられた度数情報をユーザデータベース３１から取得して、携帯端末３５に送信する。

その結果、図１０Ｂでは本人について検眼された度数情報のみしか表示されなかったところ、図１１では、本人に関連付けられた属性、すなわち家族が検眼した度数情報を表示することができる。図１１では具体的に「お子様」を例にしているが、自分の両親や配偶者を、同一属性として設定しておくことにより、度数情報の取得処理の中で、本人のみならず同一属性の過去の度数情報についても度数情報を表示画面４０の下部、一覧表示領域４１に表示することにより、参照することができる。

そして図１０Ｂと同様に、一覧表示領域４１に表示される複数の度数情報のうちの１つを指示マーク４２が指すように表示されている。この指示マーク４２を操作することにより、表示された一覧表示領域の複数の項目の中から、項目の１つを選択する。このように操作することにより、過去の度数情報に基づき、本人以外のユーザもメガネやコンタクトレンズなどのレンズ商品を購入することができる。たとえば本人が忙しい場合など、必ずしも本人による購入処理がなされなくても、身内の人間が代わりに購入処理をすることができる。

以上のように、本人又は同一属性の者からの購入指示に対して、再販売処理部３７は、購入指示が示す度数情報に基づいて、販売情報２８を検索し、検索結果に基づき、再販売にかかる販売管理データ２６を生成する。ここでの販売情報２８の生成処理は、図６及び図７に示した一連の販売及び会計処理と同一であるので、販売管理端末２０に関して説明した処理を繰り返すことになるが、処理は再販売処理部３７で実行する。

以上の処理により、ユーザは携帯端末３５からの操作入力により度数情報を取得することができる。度数情報を取得することができる結果として、ユーザデータベースサーバ３０との通信処理を介して購入対象のレンズを特定することができ、購入対象を事前予約すること、ネット通販などで所望のレンズ商品を取得することができる。

（度数情報取得の第２の例）
度数情報取得の第２の例として、購入履歴から度数情報を取得し、販売指示をする場合について説明する。第１の例では度数情報の一覧から商品を選択していたのに対して、購入履歴から選択する点で異なるが、その他の点では同じである。そこで、携帯端末３５から入力することによりインターネットを通じて購入処理する場合を中心に説明する。

図１２は、購入履歴に基づく再購入処理を示すフローチャートを示す。まずユーザは、携帯端末３５から顧客情報を入力する（ステップ５００）。そして特定部３２は、アクセス認証する。特定部３２は、このユーザのユーザ識別情報（顧客情報、顧客ＩＤ）について、ユーザデータベース３１を参照し、検索する。それにより特定部３２は、対応する検眼識別情報（受付ＩＤ１５）を特定する（ステップ５０５）。この２つの処理は度数情報取得の第１の例の処理と同一である。

ここで、アクセスした顧客の顧客ＩＤについて受付ＩＤ１５が複数であるとして、この中でも特に販売フラグで購入済になっているもののみを特定部３２で抽出する（ステップ５６０）。購入済の商品の一覧を作成するためである。

抽出に際しては、特定部３２は、図９に示した販売管理データ２６に含まれる販売フラグを参照する。図９に示すように、販売情報２８の元となる度数情報に関連付けられた検眼識別情報（受付ＩＤ１５）について、販売管理データ２６を作成された状態となっている。販売管理データ２６は、販売されたことを識別する販売識別情報（販売フラグ）がさらに付帯されたものである。そして、データベース部３３は、販売識別情報を付帯先の検眼識別情報（受付ＩＤ１５）に対応付けてユーザデータベース３１を構築している。なお、未販売の受付ＩＤを受信しない場合、特定部３２は、販売フラグを参照することなく、販売情報２８の元となる度数情報に関連付けられた検眼識別情報（受付ＩＤ１５）について、販売管理データ２６を作成してもよい。

そして、度数検索部３４は、特定部３２によって特定された複数の検眼識別情報のうち、販売識別情報が付帯されたものについての一覧である購入履歴を作成して携帯端末３５に一覧表示する（ステップ５６５）。

図１３は、購入履歴の一覧表示を表示する表示画面の一例である。図１０Ｂの場合と同様に、携帯端末３５は、購入履歴の一覧を、表示画面４０の下部、一覧表示領域５１に表示する。一方で一覧表示領域５１に表示される複数の度数情報のうちの１つを指示マーク５２が指すように表示されている。この指示マーク５２を操作することにより、表示された一覧表示領域の複数の項目の中から、項目の１つを選択する。一方で表示画面４０の上部には、購入対象となるメガネについての情報を表示する。この点については度数情報取得の第１の例と同じであるので説明を省略する。

図１４は、同一属性の購入履歴の一覧表示を表示する表示画面の一例である。
図１１の場合と同様に、携帯端末３５は、家族などの同一属性の購入履歴の一覧を、表示画面４０の下部、一覧表示領域５１に表示する。同一属性にかかる説明は、図１１において説明したものと同様である。一方で一覧表示領域５１に表示される複数の度数情報のうちの１つを指示マーク５２が指すように表示されている。この指示マーク５２を操作することにより、表示された一覧表示領域の複数の項目の中から、項目の１つを選択する。一方で表示画面４０の上部には、購入対象となるメガネについての情報を表示する。この点についてもまた、度数情報取得の第１の例と同じであるので説明を省略する。

携帯端末３５の表示画面４０を介して購入履歴の項目の１つを選択した場合、携帯端末３５はその選択結果をユーザデータベースサーバ３０に送信する。そして特定部３２は、選択された履歴についての受付ＩＤ１５を特定し、その受付ＩＤ１５に基づいて、ユーザデータベース３１にアクセスすることにより、ユーザデータベース３１から度数情報を取得して携帯端末３５に送信する（ステップ５７０）。

一方で再販売処理部３７は、携帯端末３５での選択結果と度数情報を購入指示として受け付けて、再販売処理を実行する（ステップ５７５）。販売処理については度数情報取得の第１の例における説明と同一であるので、ここでは説明を省略する。

以上の処理により、ユーザは携帯端末３５からの操作入力により、購入履歴に基づいて購入を指示することができるとともに、購入対象となるレンズについての度数情報を取得することができる。さらに、ユーザデータベースサーバ３０との通信処理を介して購入対象のレンズを特定することができ、購入対象を事前予約すること、ネット通販などで所望のレンズ商品を取得することができる。

（度数情報取得の第３の例）
度数情報取得の第３の例として、保証情報から度数情報を取得し、店舗端末２８側で表示する場合について説明する。保証情報として、購入時にユーザはＱＲコード（登録商標）である保証書コード６１をあらかじめ取得しているので、店舗に足を運んだときに、携帯端末３５のたとえばアプリケーションソフトを介して、保証書コード６１を表示する。すなわち、アプリケーションソフトを事前にインストールしておき、アプリケーションソフトを起動するときに、顧客情報とパスワードを入力することでログインすることで、ＱＲコード（登録商標）の情報にアクセスする。または、携帯端末３５で保証書などの保証情報が記載されている印刷物から、撮影して取り込んでもよい。図１５は、保証書コードと度数情報を表示する表示画面の一例を示す。

携帯端末３５は表示画面４０の中ほどに保証書コード６１を表示し、ユーザが、店舗端末２８の販売管理端末２０にかざすことにより、販売管理端末２０で保証書コード６１を認識する。または、ユーザが保証書などの保証情報が記載されている印刷物を提示し、店員が店舗端末の販売管理端末２０にかざすことにより、販売管理端末２０で保証書コード６１を認識してもよい。販売管理端末２０は、認識した内容を解析することにより、度数欄６２に度数情報を表示する。また、図１０Ｂ及び図１３の場合と同様に、携帯端末３５は表示画面４０の上部に、購入対象となるメガネについての情報を表示してもよいが、販売管理端末２０で表示すればよい。販売管理端末２０の表示画面に、購入対象となるメガネについての情報を表示する。

図１６は度数コードの入力画面の一例を示す。図１５ではＱＲコード（登録商標）により店舗で入力する例を示したが、保証情報として度数コードもまた購入時の印刷物に記載している。ネットワークを介して再販売処理、保証処理を行う場合は、販売管理端末２０に対して度数コードを入力することで処理を行う。この場合の度数コードは受付ＩＤ１５を特定する数字の組み合わせである。なお、携帯端末３５に度数コードを入力することによりユーザデータベースサーバ３０を介して販売管理端末２０に送信することで、同様に入力してもよい。

例えば受付ＩＤ１５が１２ケタの数字の組み合わせである場合、販売管理部２２は、この１２ケタの数字を合計する等の組み合わせの演算により、２ケタの数字を求め、得られた２ケタの数字を受付ＩＤ１５の１２ケタと組み合わせて１４桁の数字とすることで度数コードを生成する。このようにすることで、受付ＩＤ１５と１対１対応の数字として度数コードを与えることができる一方で、チェックデジットとの組み合わせにより、認証性を高めた状態で度数コードを利用することができる。

図１７は、保証書コードに基づく度数情報の取得処理を示すフローチャートを示す。まず販売管理端末２０に保証書コード６１又は度数コードを入力する（ステップ６０５）。保証書コードは図１５に、度数コードは図１６に、それぞれ入力画面とともに示した通りである。

次に、特定部３２は受付ＩＤ１５を特定する（ステップ６１０）。上述のように、保証書コード６１と度数コードのいずれも受付ＩＤ１５から対応付けたデータであるので、逆に保証書コード６１又は度数コードを解析することにより受付ＩＤ１５を特定することができる。そして特定部３２は、検眼識別情報（受付ＩＤ１５）から、ユーザデータベース３１を参照することにより、ユーザ識別情報（顧客情報、顧客ＩＤ）を検索して特定する（ステップ６１５）。第１の例及び第２の例では顧客ＩＤから受付ＩＤ１５を特定していたが、第３の例ではこれらの逆の処理となる。

そして第１の例及び第２の例の場合と同様に、度数取得部２１は、解析された検眼識別情報（受付ＩＤ１５）についてユーザデータベース３１から度数情報を取得する（ステップ６２０）。これらの処理の結果として必要なデータが揃ったので、度数取得部２１は、図１５に示すような度数情報を含む保証情報を販売管理端末２０の表示画面に表示する（ステップ６３０）。

なお、ここでは保証情報から１つの受付ＩＤ１５が求められるのでそのまま度数情報を取得したが、顧客ＩＤも取得しているので、ここからさらに同一顧客の他の受付ＩＤ１５を取得して、対応する度数情報を取得することもできる。すなわち特定部３２は、証明情報から特定した検眼識別情報（受付ＩＤ１５）について、ユーザデータベース３１を参照することにより、対応するユーザ識別情報（顧客ＩＤ）を特定し、さらに特定したユーザ識別情報（顧客ＩＤ）に基づいて、対応する複数の検眼識別情報を特定する。

具体的には、ステップ６１５で取得したユーザのユーザ識別情報（顧客情報、顧客ＩＤ）について、ユーザデータベース３１を参照することにより、対応する検眼識別情報（受付ＩＤ１５）をさらに検索して特定する（図１２のステップ５０５と同じ）。複数の受付ＩＤ１５が特定された状態なので、特定部３２は、検索された受付ＩＤ１５のリストとして度数取得部２１に送信する。１つの場合は、その１つの受付ＩＤ１５を度数取得部２１に送信する。

以上の第３の例により、保証情報を入力することにより、販売管理端末２０で受付ＩＤ１５を得ることができるので、ここから度数情報を取得することができる。保証に関する内容を提示することができるので、より明確に保証内容を確認することができる。さらに、保証内容が携帯端末３５に表示される場合には、保証内容を認証することができ、携帯端末３５上の情報によりレンズの保証を付与することができるシステムが提供できる。

（保証処理について）
以上、図１５〜１７を参照することにより保証書コードにより度数情報を取得し、必要な情報を提示する点について説明したが、その後の保証処理の流れについて、図１８〜図２０を参照することにより説明する。

図１８は、保証処理の入力段階のフローチャートを示す。販売管理端末２０に保証書コード６１又は度数コードを入力する（ステップ６０５）。次に、特定部３２は受付ＩＤ１５を特定する（ステップ６１０）。これらは図１７の場合と同一の処理である。

そして、特定部３２は、ユーザデータベース３１を参照することにより、該当する受付ＩＤ１５について保証期間内であるか否かを判定する（ステップ７１５）。保証期間外であれば保証できない旨を表示画面４０に表示して一連の処理を終了する。保証期間内であれば次に進む。

さらに特定部３２は、ユーザデータベース３１を参照することにより、該当する受付ＩＤ１５について保証回数内であるか否かを判定する（ステップ７２０）。保証回数を超えていれば保証できない旨を表示画面４０に表示して一連の処理を終了する。保証期間内であれば次に進み、販売管理端末２０を介して交換商品の情報の入力を受け付ける（ステップ７３０）。

図１９は、保証処理を示すフローチャートをさらに示す。そして図１７の場合と同様に、度数検索部３４は、解析された検眼識別情報（受付ＩＤ１５）について、ユーザデータベース３１にアクセスすることにより度数情報を取得して（ステップ７３５）、またユーザデータベース３１を参照することにより商品情報を取得して、販売管理端末２０に送信する。これらの処理の結果として必要なデータが揃ったので、販売管理端末２０では、図１５に示すような度数情報を含む保証情報を表示画面４０に表示する。

次に販売管理部２２は保証金額を算出する（ステップ７４０）。保証情報と共に保証の対象となる、購入したレンズを含む商品の商品情報が得られているので、これらの情報に基づいて、元の料金である保証金額を算出する。次に販売管理部２２は交換対象金額を算出する（ステップ７４５）。交換商品の情報を受け付けており、また交換対象となるレンズの度数情報を得ていることから、具体的な交換内容が特定されていることで、販売管理部２２はその内容に基づき交換対象金額を算出する。

販売管理部２２はさらに交換対象金額から保証金額を差し引いた差額を算出して販売管理端末２０の表示部に表示し（ステップ７５０）、保証を受けることが確定したら、その保証の内容をユーザデータベースサーバ３０に送信する（ステップ７５５）。この内容について確定すれば元の商品よりも高い商品にて保証を受けたい場合でも、差額を支払うことで決済できるように顧客に情報を提示できる。

図２０は、保証処理のデータベース登録を示すフローチャートを示す。図１９の処理において保証内容が確定したら送信されてくるので、まず特定部３２は、送信されてきた保証内容を受信し（ステップ７７０）、受信内容に基づき受付ＩＤ１５を特定する（ステップ７７５）。

データベース部３３は、保証内容を参照してレンズ情報及びフレーム情報を更新する（ステップ７８０）。さらに、保証回数を１回消費したことから、データベース部３３は、保証回数を１回減ずる（ステップ７８５）。これにより、保証処理段階のユーザデータベースサーバ３０における処理を終了する。

以上の構成により、ユーザが保証情報にアクセスして保証を受けることがサービスを提供することができるとともに、保証回数などの保証に関する情報をサーバ側で管理することができ、さらにフレーム情報やレンズ情報などの保証段階での購入情報も含めて顧客情報を管理しつつ、インターネットを介した商品提供を実現することができる。

（他の実施の形態）
図２１は、レンズ販売システムの他のシステム構成図である。各構成の動作は上述のように図１に示した場合と同様であるが、相違する点のみ説明する。本実施の形態では、検眼端末１０、販売管理端末２０が、店舗端末２８の一機能としてではなく、それぞれ単独の端末としてそれぞれネットワークに接続されている。そして度数情報を含む検眼履歴の情報は検眼端末１０で管理されており、販売管理端末２０及びユーザデータベースサーバ３０は、それぞれ検眼端末１０にネットワークを介してアクセスすることにより、度数情報を取得する。

検眼端末１０は、レンズ販売店に設置されている場合もあるが、視力の検査などは眼科において行う場合も依然として多い。しかしながら、眼科でなされた診察情報は、個人情報でありその都度認証を経て取得する場合が望ましい場合があり、また、視力についても診察を受ける場合に変化していることもある。その場合に最新の情報に更新することが望ましい。このようなことを勘案して、ユーザがレンズ販売についてＥＣのサイトにアクセスするだけで、ＥＣのサイトから眼科のサイトを参照することにより、最適なレンズを購入することができるようなシステム構成を本実施の形態では実現する。

図５に示したように、本実施の形態でも販売入力データ２５から販売管理データ２６を生成する。図１の実施の形態では、販売管理データ２６を直接ユーザデータベースサーバ３０で管理していたが、ここでは販売情報２８、ユーザレンズ情報３６を、販売管理データ２６から区別して処理を行う。

まず、販売の完了を受けて販売管理部２２は、販売管理データ２６に基づいて図２２に示す販売情報２８を生成する。すなわち、商品情報及び度数取得部２１によって取得された度数情報に基づいた販売情報２８を生成、出力する（ステップ３１５）。このようにレンズに関する情報と商品に関する情報に基づいて、販売管理部２２は販売情報を生成する。販売情報２８とは、販売に際して顧客に提示する情報が挙げられた、最終的な料金や、商品の詳細、保証等についての情報である。

図２２は販売情報の概要を示す。図５に示したように販売管理データ２６は既に生成されているが、販売管理データ２６は会計に用いる販売管理端末２０のためのデータとして用いる。販売情報２８は、顧客に渡すレシート、領収書、保証書に記載する情報であるという性質上、販売管理データ２６とは異なり、またユーザデータベースサーバ３０に送るデータもまた、販売管理データ２６とは異なる。

具体的には、販売情報２８には、度数情報が販売管理データ２６から除外される。上述のように顧客が直接把握するにはなじまない情報だからである。販売情報２８で顧客ＩＤはそのまま用いているが、顧客ＩＤにかえて、もしくは顧客ＩＤとともに顧客名を使用してもよい。この他、フレームＩＤ、レンズＩＤなど、ＩＤ情報に替えて分かりやすいように具体的な情報を記載する。商品渡フラグについては、商品を渡したかどうかの具体的な情報を記載し、受け取り日時や場所などの商品渡情報としてもよい。

そして、図７に示したステップ３１５の処理に続き、ユーザ管理部２３は、販売管理データ２６に基づき、ユーザを識別するユーザ識別情報（顧客ＩＤ）と、販売管理端末３０で入力された検眼識別情報を組み合わせてユーザレンズ情報３６を作成する。ユーザレンズ情報３６は、ユーザの検眼にかかるレンズの情報、ユーザに販売したレンズについての情報をユーザデータベースサーバ３０で管理するためにまとめた情報である。

具体的には、ユーザレンズ情報３６は、受付ＩＤ１５、販売フラグ、ステップ２１５で説明したレンズ情報及びフレーム情報、商品渡フラグ、保証回数の情報を含む。複数回検眼を行い、複数の受付票が提示されている場合には受付ＩＤ１５は複数あるので、図２２に示すようにそれぞれを顧客ＩＤに対応付ける。

この場合、実際に販売されていないレンズの受付ＩＤ１５も含んでいるので、販売フラグを、販売済か否かを区別する情報として含める。保証情報については、保証回数の情報を含む。保証開始日については、販売日の情報から導くことができ、保証書コードは受付ＩＤ１５から求めることができるのでここでは省略するが、含めてもよい。そして、ユーザ管理部２３は、作成されたユーザレンズ情報３６をデータベースサーバ３０に送信する。そしてデータベース部３３では、受け取ったユーザレンズ情報３６に基づいてユーザデータベース３１を構築する。図１の実施の形態では、販売管理情報２６に基づいていたところ、本実施の形態では、ユーザレンズ情報３６に基づいてユーザデータベース３１を構築する。

以上のようにデータベースサーバ３０にユーザレンズ情報３６に基づくユーザデータベースを構築することができたので、これに対して、携帯端末３５からデータベースサーバ３０にアクセスすることにより度数情報を取得する処理について説明する。度数情報取得の第２の例及び度数情報取得の第３の例は処理が共通するので説明を省略するが、度数情報取得の第１の例については異なるので説明する。

図２３は、度数情報を取得して購入する処理を示すフローチャートである。まずユーザは、携帯端末３５から顧客情報を入力する（ステップ５００）。顧客情報としては、顧客ＩＤとパスワードを入力することにより、アクセス認証のための入力を行う。

ここで、各顧客ＩＤについては属性情報を設定していたので、設定により、同一属性に係る顧客ＩＤについては同様にアクセス可能としてもよい。つまり所定の顧客ＩＤについてアクセスしたことにより、複数の顧客ＩＤについての情報についてアクセスすることになる。後述の説明では単一の顧客ＩＤを例にして説明するが、複数の顧客ＩＤのついての情報を、顧客ＩＤごとに区別して検索、取得し、画面表示していくことも可能である。

入力を受けて、特定部３２は、顧客情報を認証情報によりアクセス認証をして、アクセスの可否を決定する。アクセスを認められない場合は処理を終了する。アクセス許可の場合に次の処理に進む。アクセス認証により許可された場合、携帯端末３５とユーザデータベースサーバ３０との間で通信処理を行う。

次に、特定部３２は、アクセス認証の結果アクセスを認められたユーザのユーザ識別情報（顧客情報、顧客ＩＤ）について、ユーザデータベース３１を参照することにより、対応する検眼識別情報（受付ＩＤ１５）を検索して特定する（ステップ５０５）。

ここで、アクセスした顧客の顧客ＩＤについて受付ＩＤ１５は１つの場合もあるが、複数の場合もある。複数の受付ＩＤ１５が検索された場合、特定部３２は、検索された受付ＩＤ１５のリストとして携帯端末３５に送信する。１つの場合は、その１つの受付ＩＤ１５を携帯端末３５に送信する。

携帯端末３５では、アクセスした顧客ＩＤについての受付ＩＤのリストを受信したので、これらの検眼識別情報（受付ＩＤ１５）について、度数検索部３４は、検眼管理端末１０にアクセスすることにより（ステップ５１０）、度数情報を取得して携帯端末３５に送信する（ステップ５１５）。

そして、特定部３２によって複数（少なくとも１つ）の検眼識別情報（受付ＩＤ１５）及び度数情報が特定されているので、度数検索部３４は、特定された複数の検眼識別情報（受付ＩＤ１５）のそれぞれに基づいた複数の度数情報を取得して度数一覧を作成し、携帯端末３５に一覧表示する（ステップ５２０）。以上の結果、図１０Ｂに示した度数の一覧が表示される。

携帯端末３５の表示画面４０を介して検眼識別情報（受付ＩＤ１５）、度数情報に対応する項目の１つを選択した場合、携帯端末３５はその選択結果をユーザデータベースサーバ３０に送信する。ユーザデータベースサーバ３０の購入指示部３９は、この送信結果、すなわち度数検索部３４によって作成された度数一覧に含まれる複数の度数情報のうち１つについての購入指示を受け付けて、販売管理端末２０に送信することにより購入指示処理を実行する（ステップ５２５）。

以上のように構成することにより、検眼端末１０が独自にネットワークに接続されている場合、特に眼科で検眼履歴にかかるシステムを管理しているような場合に、ユーザはレンズを購入するときに、ＥＣのサイトにアクセスするだけで、眼科のサイトを参照することにより、最適なレンズを購入することができるようなシステム構成を実現することができる。

以上、本発明について実施例を用いて説明したが、本発明の技術的範囲は上記実施例に記載の範囲には限定されない。上記実施例に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。その様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

検眼端末１０、検眼データベース１１、入力部１２、検眼管理部１３、受付ＩＤ１５、販売管理端末２０、度数取得部２１、販売管理部２２、ユーザ管理部２３、販売入力データ２５、販売管理データ２６、販売情報２８、ユーザデータベースサーバ３０、ユーザデータベース３１、特定部３２、データベース部３３、度数検索部３４、携帯端末３５、ユーザレンズ情報３６、再販売処理部３７、保証処理部３８

Claims (15)

1. 店舗側端末とデータベースサーバを備え、互いにネットワーク接続されるレンズ販売システムであって、
   前記店舗側端末は、
   ユーザが装着したレンズの度数情報を含む検眼結果を入力する入力部と、
   前記検眼結果を識別する検眼識別情報と前記入力された度数情報とを関連付けた検眼履歴を作成することにより、検眼データベースを構築する検眼管理部と、
   ユーザを識別するユーザ識別情報と前記作成された検眼履歴を組み合わせて前記データベースサーバに送信するユーザ管理部を備え、
   前記データベースサーバは、
   前記ユーザ管理部から送信された少なくとも１つ以上の検眼履歴を、ユーザ識別情報ごとに対応付けたユーザデータベースを構築するデータベース部と、
   アクセス認証の結果アクセスを認められたユーザのユーザ識別情報について、前記ユーザデータベースを参照することにより、対応する検眼識別情報を特定する特定部と、
   前記ユーザデータベースを参照することにより、前記特定部によって特定された検眼識別情報に基づいた度数情報を取得する度数検索部と、
   を備えるレンズ販売システム。
2. レンズとともに販売する商品の商品情報を取得し、当該商品情報及び前記度数情報に基づいた販売情報を生成する販売管理部を、
   さらに備える、請求項１に記載のレンズ販売システム。
3. 前記販売管理部は、複数の検眼履歴が作成された場合に、作成した複数の検眼履歴のうちいずれかを選択し、前記商品情報及び選択した度数情報に基づいて、前記販売情報を生成し、
   前記ユーザ管理部は、前記ユーザ識別情報について、前記作成した複数の検眼履歴をいずれも関連付ける、
   請求項２に記載のレンズ販売システム。
4. 前記特定部によって複数の検眼識別情報が特定された場合、前記度数検索部は、前記特定された複数の検眼識別情報のそれぞれに基づいた複数の度数情報を取得して度数一覧を作成する、
   請求項１〜３のいずれかに記載のレンズ販売システム。
5. 前記データベースサーバは、前記度数検索部によって作成された度数一覧に含まれる前記複数の度数情報のうちのいずれかについての購入指示を、外部端末からネットワークを介して受け付けることにより、当該購入指示に基づいた販売情報を生成する再販売処理部を、
   さらに備える、請求項４に記載のレンズ販売システム。
6. 前記ユーザ管理部は、前記販売情報の元となる度数情報に関連付けられた検眼識別情報について、販売状況を識別する販売識別情報をさらに付帯し、
   前記データベース部は、前記販売識別情報を付帯先の検眼識別情報に対応付けて前記ユーザデータベースを構築し、
   前記度数検索部は、前記特定部によって特定された検眼識別情報のうち、前記販売識別情報が付帯されたものに基づいて度数情報を取得する、
   請求項２又は３に記載のレンズ販売システム。
7. 前記度数検索部は、前記特定部によって前記特定された複数の検眼識別情報のうち、前記販売識別情報が付帯されたものについての一覧である購入履歴を作成する、
   請求項６に記載のレンズ販売システム。
8. 前記データベースサーバは、前記度数検索部によって作成された購入履歴が示すうちの１つについて購入指示を受け付けて、当該購入指示に基づいた販売情報を生成する再販売処理部を、
   さらに備える、請求項７に記載のレンズ販売システム。
9. 前記販売管理部は、前記販売情報を生成する場合に、前記販売情報の元となる度数情報に関連付けられた検眼識別情報を、当該検眼識別情報と対応する別のコード形式の証明情報に変換して、前記販売情報とともに含めて証明書として発行し、
   前記特定部は、前記証明書に含まれる前記証明情報から対応する検眼識別情報を特定する、
   請求項２〜７のいずれかに記載のレンズ販売システム。
10. 前記特定部は、前記証明情報から特定した検眼識別情報について、前記ユーザデータベースを参照することにより、対応するユーザ識別情報を特定し、さらに特定したユーザ識別情報に基づいて、対応する複数の検眼識別情報を特定する、
    請求項９に記載のレンズ販売システム。
11. 前記ユーザデータベースは、記憶している検眼履歴のうち販売されたレンズのそれぞれについての保証情報を記憶し、
    前記データベースサーバは、
    外部端末からネットワークを介して受け付けることにより、前記販売管理部によって発行された証明書を含む保証要求の入力を受け付け、入力された保証要求に含まれる証明書によって特定される検眼識別情報に基づいて保証処理し、前記特定される検眼識別情報について、前記ユーザデータベースに記録された保証情報を更新する保証処理部を、
    さらに備える、請求項９又は１０に記載のレンズ販売システム。
12. 前記ユーザ管理部は、前記販売管理部によって生成された販売情報を、対応する前記検眼履歴に関連付けて前記データベースサーバに送信し、
    前記データベース部は、前記ユーザ管理部から送信された販売情報を含めて前記ユーザデータベースを構築し、
    前記保証処理部は、前記保証要求の入力とともに、交換対象となる商品についての入力を受け付け、前記ユーザデータベースを参照することにより、前記証明書から特定される検眼識別情報についての販売情報と比較し、比較した商品について価格に差額が生じた場合に、当該差額についての情報を前記外部端末に送信する、
    さらに備える、請求項１１に記載のレンズ販売システム。
13. 前記特定部は、前記アクセス認証の結果アクセスを認められたユーザのユーザ識別情報について属性情報を判別することにより、同一の属性情報に属すると判別されたユーザ識別情報について、前記ユーザデータベースを参照することにより、対応する検眼識別情報を特定し、
    前記度数検索部は、前記同一の属性情報に属すると判別されたユーザ識別情報について、前記検眼識別情報に基づいた度数情報を取得する、
    請求項１〜１２のいずれかに記載のレンズ販売システム。
14. ネットワーク接続されるデータベースサーバであって、
    ユーザを識別するユーザ識別情報と、当該ユーザの検眼結果を識別する検眼識別情報と、当該ユーザが装着したレンズの度数情報とを関連付けた検眼履歴をネットワークを介して受信し、受信した少なくとも１つ以上の検眼履歴について、ユーザ識別情報ごとに対応付けたユーザデータベースを構築するデータベース部と、
    アクセス認証の結果アクセスを認められたユーザのユーザ識別情報について、前記ユーザデータベースを参照することにより、対応する検眼識別情報を特定する特定部と、
    前記ユーザデータベースを参照することにより、前記特定部によって特定された検眼識別情報に基づいた度数情報を取得する度数検索部と、
    を備えるデータベースサーバ。
15. ネットワーク接続されるデータベースサーバに、
    ユーザを識別するユーザ識別情報と、当該ユーザの検眼結果を識別する検眼識別情報と、当該ユーザが装着したレンズの度数情報とを関連付けた検眼履歴をネットワークを介して受信し、受信した少なくとも１つ以上の検眼履歴について、ユーザ識別情報ごとに対応付けたユーザデータベースを構築する構築ステップと、
    アクセス認証の結果アクセスを認められたユーザのユーザ識別情報について、前記ユーザデータベースを参照することにより、対応する検眼識別情報を特定する特定ステップと、
    前記ユーザデータベースを参照することにより、前記特定部によって特定された検眼識別情報に基づいた度数情報を取得する度数検索ステップと、
    を実行させるデータベース管理プログラム。