(57)【要約】【課題】顧客環境と管理環境に分離された販売システムにおいて、管理環境で新規登録、更新したデータに自動的に印をつけることで、管理作業を簡単にする。【解決手段】顧客用と管理用のインスタンスと、インスタンス間の同期を取る手段を備える。同期手段は、自動的に付与された印を削除してから、管理用インスタンスから顧客用インスタンスに複写処理を行う。【選択図】        図１
2004280517.tif 000002
【特許請求の範囲】
【請求項１】
付与されたキーワードやカテゴリによって分類・検索可能な、一般顧客に対するサービスを行う販売環境と、
管理者がデータの更新を行うための管理環境と、
管理環境と販売環境の内容を同期する同期手段の、少なくとも３つの要素から構成される商品販売システムにおいて、
管理環境において何らかの情報が変更されたデータに関して、予約済のキーワードもしくはカテゴリのどちらか一方、もしくはその両方を付与することで、情報が変更されたデータを簡便に検索する手段を提供することを特徴とする商品販売システム。
【請求項２】
請求項１の商品販売システムにおいて、
同期手段によって管理環境と販売環境の同期を取る際に、予約済キーワードとカテゴリを削除してから同期を取ることを特徴とする商品販売システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、商品販売システムに関する。
【０００２】
【従来の技術】
インターネット経由で物品や画像などの商品を配布・販売する場合、商品管理を行うデータベースなどを用いて商品にキーワードやカテゴリをデータに付与して整理してインターネットで接続された一般顧客に呈示・公開し、配布・販売するのが通常であった。
【０００３】
こういった販売システムの場合、顧客に対する商品販売を滞り無く続ける一方、管理者は商品の新規登録や更新などの管理作業が臨機応変に行える必要があった。
【０００４】
上記を実現するための工夫は多数あるが、その一つの例として前記データベースを多重化して登録・更新専用の環境を販売活動用のデータベース環境と別に用意、全てのデータ登録・更新処理と検証はそちらで行い、適当なタイミングで販売活動用環境にデータを転送するように構成することで、管理者が安全にデータを管理できるシステムが考えられている。
【０００５】
【発明が解決しようとする課題】
しかし、上記環境の場合、新規登録・更新したデータを他のデータと区別する方法がなく、管理者は専用のカテゴリやキーワードを明示的に定義して販売環境にデータを移行する直前に当該カテゴリ・キーワードを削除するか、もしくは新規登録・更新を示すカテゴリやキーワードを特に付与せず、紙にメモをして残しておくなどの手段を講じておく必要があった。
【０００６】
本発明は、上記問題点に着目してなされたものであって、顧客環境と管理環境に分離された販売システムにおいて、管理環境で新規登録、更新したデータに自動的に印をつけることで、管理作業を簡単にすることのできる商品販売システムを提供することを目的としている。
【０００７】
【課題を解決するための手段】
この問題に対処するために、本発明においては、登録専用環境において新規登録・更新がなされたデータに特別なキーワード、もしくはカテゴリのいずれか、もしくはその両方を自動的に付与することで、登録・更新したデータに管理者が簡便にアクセスする手段を提供する。
【０００８】
更に、上記キーワード、カテゴリを一般顧客に公開しないために、販売環境にデータを移行する際に当該キーワード・カテゴリ情報を自動的に削除する手段も同時に提供する。
【０００９】
上記構成を、改めて以下（１）、（２）に整理して示す。
【００１０】
（１）付与されたキーワードやカテゴリによって分類・検索可能な、一般顧客に対するサービスを行う販売環境と、
管理者がデータの更新を行うための管理環境と、
管理環境と販売環境の内容を同期する同期手段の、少なくとも３つの要素から構成される商品販売システムにおいて、
管理環境において何らかの情報が変更されたデータに関して、予約済のキーワードもしくはカテゴリのどちらか一方、もしくはその両方を付与することで、情報が変更されたデータを簡便に検索する手段を提供することを特徴とする商品販売システム。
【００１１】
（２）上記（１）の商品販売システムにおいて、
同期手段によって管理環境と販売環境の同期を取る際に、予約済キーワードとカテゴリを削除してから同期を取ることを特徴とする商品販売システム。
【００１２】
【発明の実施の形態】
以下に本発明の実施の形態を、実施例に基づいて図面を参照しながら説明する。
【００１３】
【実施例１】
以下、具体的な例をあげて、実施例１を説明する。
【００１４】
図１は、実施例１の説明に用いるための販売システムの一例であり、画像データを配信するシステムの概略図である。本実施例においては、更新されたデータに対しては予約済キーワード「＿ＵＰＤＡＴＥＤ＿」と予約済カテゴリ「＿ＵＰＤＡＴＥＤ＿」が、追加されたデータに対してはそれぞれ「＿ＡＰＰＥＮＤＥＤ＿」「＿ＡＰＰＥＮＤＥＤ＿」という予約済キーワードを追加するとする。
【００１５】
一般顧客ＵＳＥＲ、管理者ＨＯＬＤＥＲは、ＮｅｔｓｃａｐｅやＩｎｔｅｒｎｅｔ  ＥｘｐｌｏｒｅｒなどのＷｅｂビューワアプリケーションを用いて、インターネットなどを経由でＨＴＴＰサーバＨＴＴＰＤに接続している。一般顧客ＵＳＥＲ，管理者ＨＯＬＤＥＲともに、データの検索や更新などの処理をＵＲＬ（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）で指定し、ＨＴＴＰサーバＨＴＴＰＤがＵＲＬを解釈し、ＣＧＩを適宜起動して検索や登録・更新を行う。必要ならば、管理者ＨＯＬＤＥＲはデータファイルを後述ＴＭＰ２にアップロードも行う。
【００１６】
本実施例においては、ＴＭＰ２はＨＯＬＤＥＲからアップロードされたマルチメディアデータが一時的に置かれる場所であり、一般顧客ＵＳＥＲがダウンロードするマルチメディアデータが一時的に保管される記憶領域ＴＭＰ１とは異なっているが、ＴＭＰ１とＴＭＰ２が同一記憶領域であっても、名前の衝突を回避すれば単一の記憶領域でもよい。
【００１７】
ＣＧＩ１，ＣＧＩ２，ＣＧＩ３は本システムで使用するＣｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅの一部であって、ＭＤＢへのデータ追加や更新を行う。
【００１８】
ＣＧＩ１，ＣＧＩ２は検索にまつわるＣＧＩで、本実施例での説明は省略する。ＣＧＩ３は登録・更新を行うＣＧＩであり、詳細は後述する。
【００１９】
ＣＤＢ，ＭＤＢはリレーショナルデータベースのインスタンスであり、少なくともＭＤＢは内部にＣＧＩ実行に必要な構造をもったテーブル群ＴＢＬＳを持つ。テーブル群ＴＢＬＳの構成に関しては後述する。
【００２０】
ＩＭＧＳは、マルチメディアデータを蓄積するための記憶領域であって、各々のデータはファイル名などで特定できるよう構成されている。本実施例においては、マルチメディアデータ本体はＣＤＢ，ＭＤＢには含まれない。データ本体は記憶領域ＩＭＧＳに格納され、ＣＤＢ，ＭＤＢにはその参照（ファイルパス）が格納される。また、本実施例においては、記憶領域ＩＭＧＳに格納されるマルチメディアデータファイルの名前の衝突は発生しないように管理されるとする。
【００２１】
ＳＹＮＣは上記ＭＤＢのテーブル群ＴＢＬＳの情報をＣＤＢに反映する機構である。本実施例においては、図１１に示すＳＱＬがその実体である。なお、本実施例においては、ＣＤＢ上にもＭＤＢのテーブル群ＴＢＬＳと同一の構造を持つことを前提としているが、図１１のＳＱＬを適当に再構成することで、ＣＤＢとＭＤＢが共通の構造を持たなくてもよいことは明らかである。
【００２２】
次に、図２に、ＣＤＢ，ＭＤＢの構造を示す。
【００２３】
既に述べたとおり、本実施例におけるＣＤＢ，ＭＤＢは、共通の構造を持ったテーブル群ＴＢＬＳを持つ。本実施例においては、ＴＢＬＳはキーワード情報ＫＥＹＷＯＲＤとコンテンツのＩＤであるＣＩＤとの関連を保持するテーブルＫＥＹＳと、カテゴリ情報ＣＡＴＥＧＯＲＹとＣＩＤとの関連を保持するテーブルＣＡＴＥ、ＣＩＤとコンテンツの実体であるファイルのパスＦＩＬＥＮＡＭＥとの関連を保持するテーブルＤＡＴからなるとする。
【００２４】
図３は、実施例１で使用するＳＱＬ文のテンプレート一覧である。実際に使用される際には、可変部分＄ＫＥＹＷＯＲＤ，＄ＦＩＬＥＮＡＭＥ，＄ＣＡＴＥＧＯＲＹ，＄ＣＩＤに適当な値をセットしてから使用される。
【００２５】
図４は、本実施例で使用するＵＲＬである。本実施例では一般顧客ＵＳＥＲや管理者ＨＯＬＤＥＲが使用する検索機能は関連しないので、管理者ＨＯＬＤＥＲのみが使用するデータの新規登録・更新のみを取り上げる。
【００２６】
図４のＵＲＬ１を用いて、ＵＲＬの構造を説明する。
【００２７】
ＵＲＬ１において、「ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏ．ｊｐ／ＣＧＩ３」をスクリプト部と呼び、実際に起動されるＣＧＩを指定する働きを持つ。
【００２８】
それに対して「？」に続く「ＣＩＤ＝１」の部分はクエリ文字列部と呼ばれ、スクリプト部で指定されたＣＧＩに引数として渡される。
【００２９】
クエリ文字列部は、「＆」で区切った複数のオプションを指定可能であり、本システムにおいては、オプションは「項目名＝値」の構造であるとする。即ち、「ＣＩＤ＝１」というオプションは、「ＣＩＤという項目名に対して、１という値が指定された」と解釈する。
【００３０】
なお、本システムにおいては、単一のＵＲＬにおいて同一項目名に対して複数の値を与えることは出来ないとする。即ち、複数のキーワードの同時指定はできない。一方、ＫＥＹＳやＣＡＴＥにおいて、単一データに複数のキーワードもしくはカテゴリが関連付けられることは、一方が予約済キーワード、予約済カテゴリの場合のみ許されるとする。
【００３１】
次に、図５のフローを用いて、ＣＧＩ３によるＭＤＢへの登録・更新動作の詳細を示す。
【００３２】
Ｓ１において、クエリ文字列が引数として取りこまれる。
【００３３】
Ｓ２において、切り出された引数にＣＩＤのオプションが含まれているか否かを調べる。ＣＩＤの指定がある場合は既存データの更新と見なしてＳ３へ、ＣＩＤの指定がない場合は新規データの追加と見なしてＳ１０に進む。
【００３４】
更新の場合、まずＳ３において引数にＫＥＹＷＯＲＤオプションが含まれているかチェックする。含まれていた場合、Ｓ４に進む。含まれない場合はＳ５に進む。
【００３５】
Ｓ４において、ＫＥＹＳ．ＫＥＹＷＯＲＤの更新が行われる。具体的には、図３（３）のＳＱＬ文の＄ＫＥＹＷＯＲＤの部分にＫＥＹＷＯＲＤオプションで指定された値を、＄ＣＩＤの部分にＳ２で切り出したＣＩＤオプションの値を埋めこんで、完全なＳＱＬ文を構成しＭＤＢに対して発行、ＫＥＹＳテーブルにおいて当該ＣＩＤに付与されたキーワードを更新する。その後で、当該ＣＩＤに予約キーワード「＿ＵＰＤＡＴＥＤ＿」と予約カテゴリ「＿ＵＰＤＡＴＥＤ＿」を付与する。当該予約キーワード、予約カテゴリが登録済なら、新たには登録されないことに注意する。
【００３６】
次に、Ｓ５において引数にＣＡＴＥＧＯＲＹオプションが含まれているかチェックする。含まれていた場合、Ｓ６に進む。含まれない場合はＳ７に進む。
【００３７】
Ｓ６において、ＣＡＴＥ．ＣＡＴＥＧＯＲＹの更新が行われる。具体的には、図３（４）のＳＱＬ文の＄ＣＡＴＥＧＯＲＹの部分にＣＡＴＥＧＯＲＹオプションで指定された値を、＄ＣＩＤの部分にＳ２で切り出したＣＩＤオプションの値を埋めこんで、完全なＳＱＬ文を構成しＭＤＢに対して発行、ＣＡＴＥテーブルにおいて当該ＣＩＤに付与されたカテゴリを更新する。本ステップでも、Ｓ４同様に予約キーワード・予約カテゴリの付与が行われる。
【００３８】
Ｓ７において、オプションにＵＰＬＯＡＤが指定されているかチェックする。含まれていたらＳ８に進み、含まれていなければ処理を終了する。
【００３９】
Ｓ８において、記憶領域ＩＭＧＳへのファイル格納処理が行われた後Ｓ９に進む。記憶領域ＩＭＧＳに格納されるファイルは、何らかの手段を用いて予め記憶領域ＴＭＰ２にアップロードされている必要がある。
【００４０】
Ｓ８でファイルの実体が記憶領域ＩＭＧＳ上の所定の位置（本実施例では￥￥ＩＭＧＳの直下とする）に移動した後、Ｓ９においてＭＤＢ上のＦＩＬＥＮＡＭＥのパス登録を更新する。具体的には、図３（２）のＳＱＬ文中の＄ＦＩＬＥＮＡＭＥの部分にＵＰＬＯＡＤで指定されたファイル名を、＄ＣＩＤの部分にＣＩＤで指定された値を埋めこみ、ＭＤＢに対して発行することで、ＣＩＤで指定したデータファイルの置き換えを実行する。本ステップでも、Ｓ４同様に予約キーワード・予約カテゴリの付与が行われる。
【００４１】
一方、Ｓ２においてＣＩＤを検出できなかった場合、引数で指定されたデータをもって、ＣＧＩ３は新たなデータエントリを新規に登録するためＳ１０に進む。
【００４２】
新規登録の場合、データファイルとキーワードの両方の指定が必要になるため、Ｓ１０においてＫＥＹＷＯＲＤオプション、Ｓ１１においてＣＡＴＥＧＯＲＹオプション、Ｓ１２においてＵＰＬＯＡＤオプションの有無を調べる。その全てが揃っていなければ、データ不充分で新規登録出来ないため、ＣＧＩ３の処理を終了する。
【００４３】
ＫＥＹＷＯＲＤ，ＣＡＴＥＧＯＲＹ，ＵＰＬＯＡＤの全てが存在した場合、Ｓ１３においてＳ９同様、データファイルの記憶領域ＩＭＧＳへの格納処理が行われる。
【００４４】
続いてＳ１４において、ＦＩＬＥＮＡＭＥ、ＣＡＴＥＧＯＲＹ、ＫＥＹＷＯＲＤの新規登録、即ち、ＤＡＴとＫＥＹＳの両テーブルへのレコード追加が行われる。具体的には、図３（１）のＳＱＬ文に含まれる＄ＫＥＹＷＯＲＤにＫＥＹＷＯＲＤオプションで指定した文字列を、＄ＦＩＬＥＮＡＭＥにＵＰＬＯＡＤオプションで与えられたファイル名を、＄ＣＡＴＥＧＯＲＹにＣＡＴＥＧＯＲＹオプションで与えられたファイル名を埋めこみ、＄ＣＩＤに適当な数値を埋めこんだＳＱＬ文をＭＤＢに対して発行することで行う。ここで＄ＣＩＤの値として選ばれる数値は、例えば既存のＣＩＤの最大値を調べ、それに＋１した値を採用すれば、ＭＤＢ上で重複することはない。最後に予約キーワード「＿ＡＰＰＥＮＤＥＤ＿」予約カテゴリ「＿ＡＰＰＥＮＤＥＤ＿」が付与されてＣＧＩ３の処理を終了する。
【００４５】
以下、図６〜図９を用いて、図５のフローを説明する。
【００４６】
図６は、管理者ＨＯＬＤＥＲが図４のＵＲＬ１を発行して登録済のデータファイルを更新（置き換え）する際のデータの流れを示している。
【００４７】
管理者ＨＯＬＤＥＲは、まずＴＭＰに３．ｊｐｇをＦＴＰなどの手段を用いてアップロードした後、ＨＴＴＰＤに対してＵＲＬ３を発行する。
【００４８】
ＨＴＴＰＤに到着したＵＲＬ３はＨＴＴＰＤによって解析され、そのスクリプト部からＣＧＩ３が選択される。引数は、ＵＲＬ３のクエリ文字列が切り出されて渡される。
【００４９】
ＣＧＩ３に渡される引数にはＣＩＤオプションが含まれているので、Ｓ２において既存のデータの更新と判断する。次にＵＰＬＯＡＤオプションのみの指定なのでキーワードに関する更新はない、と判断してＳ３からＳ５に進み、ＣＧＩ３は、ＴＭＰから３．ｊｐｇを読み出し記憶領域ＩＭＧＳ下に格納した後、図３（２）を元に一連のＳＱＬを生成、ＭＤＢに対して発行して、ＣＩＤ＝１に対応したＦＩＬＥＮＡＭＥを更新する。
【００５０】
同時に、ＣＩＤ＝１に予約済キーワードと予約済カテゴリを追加すると、ＭＤＢの状態は図７の状態になり、ＣＩＤ＝１のデータファイルに関して正しく更新された上で予約済のキーワードとカテゴリ「＿ＵＰＤＡＴＥＤ＿」が付与されたことがわかる。
【００５１】
図８は、ＵＲＬ１を処理した後、管理者ＨＯＬＤＥＲが図４のＵＲＬ２を発行して、更に新たなデータを登録する場合のデータの流れを示している。
【００５２】
管理者ＨＯＬＤＥＲは、まずＴＭＰに４．ｊｐｇをＦＴＰなどの手段を用いてアップロードし、その後でＨＴＴＰＤに対してＵＲＬ２を発行する。
【００５３】
ＨＴＴＰＤに到着したＵＲＬ２はＨＴＴＰＤによって解析され、図６同様にそのスクリプト部からＣＧＩ３が選択される。引数には、ＵＲＬ２のクエリ文字列が渡される。
【００５４】
今回ＣＧＩ３に渡る引数にはＣＩＤオプションがないので、ＣＧＩ３は、Ｓ２においてデータの新規登録と判断し、Ｓ１０に進む。Ｓ１０〜Ｓ１２において、引数にＫＥＹＷＯＲＤオプション、ＣＡＴＥＧＯＲＹ、ＵＰＬＯＡＤオプションの全てが含まれているか調べる。今回の場合引数には全てが含まれているので、Ｓ１３においてＣＧＩ３はＴＭＰから４．ｊｐｇを取りだし、記憶領域ＩＭＧＳ下の所定の位置に置いた後、Ｓ１４において図３（１）を元に一連のＳＱＬを作成、ＭＤＢに対して発行される。ＣＩＤの値は、本実施例ではＭＤＢ上に存在するＣＩＤの最大値＋１を採用している。以上の処理が終わってＳ１４を終了すると、ＭＤＢは図９の状態になり、ＨＯＬＤＥＲが明示せずとも、あるレコードが新規登録されたか更新されたかが、一目瞭然となる。
【００５５】
【実施例２】
以下、実施例１の説明に続ける形で実施例２を説明する。
【００５６】
図１０に、同期処理時のデータの流れを示す。同期処理ＳＹＮＣは、主にＭＤＢからＣＤＢにデータをコピーする処理を行う。そのＳＹＮＣの処理の詳細を図１１に示す。
【００５７】
図１１は一連のＳＱＬ文のテンプレートである。テーブル名に続く「＠」は、そのテーブルを持つインスタンスを指定している。
【００５８】
（１）〜（３）においてＣＤＢ側のＫＥＹＳ，ＤＡＴ，ＣＡＴＥ上の全ての情報を削除し、（４）〜（５）において、ＭＤＢ上のＫＥＹＳ，ＣＡＴＥから予約済のキーワード、カテゴリを削除している。最後に、（６）〜（８）でＣＤＢからＭＤＢにデータをコピーしている。
【００５９】
このように構成することでＭＤＢからデータを読み出す際に、予約済キーワード・予約済カテゴリは読み出されないことは明らかであり、図９の状態からＳＹＮＣを実行すれば、図１２の状態になるのは明らかである。
【００６０】
【発明の効果】
以上実施例１のように構成することで、管理者が明示的にキーワードやカテゴリを付与せずとも予約済のキーワードとカテゴリが付与されるようになり、管理者が当該キーワード情報やカテゴリ情報を用いることで、登録・更新した情報を簡便に参照できるようになる。
【００６１】
更に実施例２のように構成することで、実施例１で付与された定義済キーワードやカテゴリが同期時に管理環境から削除されてから販売環境に複写されるため、管理のためだけに必要であった定義済キーワードやカテゴリを、管理者が明示的に削除してから同期せずとも、一般顧客の眼に触れることはなくなる。
【図面の簡単な説明】
【図１】実施例１の説明に用いるための販売システムの一例であり、画像データを配信するシステムの概略図
【図２】ＣＤＢ，ＭＤＢの構造を示す図
【図３】実施例１で使用するＳＱＬ文のテンプレート一覧を示す図
【図４】本実施例で使用するＵＲＬ
【図５】ＣＧＩ３によるＭＤＢへの登録・更新動作の詳細を示すフローチャート
【図６】図５のフローを説明する図であって、管理者ＨＯＬＤＥＲが図４のＵＲＬ１を発行して登録済のデータファイルを更新（置き換え）する際のデータの流れを示している図
【図７】図５のフローを説明する図であって、ＣＩＤ＝１に予約済キーワードと予約済カテゴリを追加したときのＭＤＢの状態を示す図
【図８】図５のフローを説明する図であって、ＵＲＬ１を処理した後、管理者ＨＯＬＤＥＲが図４のＵＲＬ２を発行して、更に新たなデータを登録する場合のデータの流れを示す図
【図９】図５のフローを説明する図
【図１０】同期処理時のデータの流れを示す図
【図１１】一連のＳＱＬ文のテンプレート
【図１２】図９の状態からＳＹＮＣを実行したときの状態を示す図
【符号の説明】
ＵＳＥＲ  一般顧客
ＨＯＬＤＥＲ  管理者
ＨＴＴＰＤ  ＨＴＴＰサーバ
ＴＭＰ１、ＴＭＰ２  記憶領域
ＴＢＬＳ  テーブル群
ＩＭＧＳ  マルチメディアデータを蓄積するための記憶領域
ＣＤＢ、ＭＤＢ  リレーショナルデータベースのインスタンス
【図１】
2004280517.tif 000003
【図２】
2004280517.tif 000004
【図３】
2004280517.tif 000005
【図４】
2004280517.tif 000006
【図５】
2004280517.tif 000007
【図６】
2004280517.tif 000008
【図７】
2004280517.tif 000009
【図８】
2004280517.tif 000010
【図９】
2004280517.tif 000011
【図１０】
2004280517.tif 000012
【図１１】
2004280517.tif 000013
【図１２】
2004280517.tif 000014