(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023124182
(43)【公開日】2023-09-06
(54)【発明の名称】物品管理システム、およびプログラム
(51)【国際特許分類】
G06Q 10/087 20230101AFI20230830BHJP
G06Q 50/28 20120101ALI20230830BHJP
B65G 1/137 20060101ALI20230830BHJP
【ＦＩ】
G06Q10/08 330
G06Q50/28
B65G1/137 B
【審査請求】未請求
【請求項の数】3
【出願形態】ＯＬ
(21)【出願番号】P 2022027800
(22)【出願日】2022-02-25
(71)【出願人】
【識別番号】597151563
【氏名又は名称】株式会社ゼンリン
(74)【代理人】
【識別番号】100095407
【弁理士】
【氏名又は名称】木村 満
(74)【代理人】
【識別番号】100181618
【弁理士】
【氏名又は名称】宮脇 良平
(74)【代理人】
【識別番号】100162259
【弁理士】
【氏名又は名称】末富 孝典
(74)【代理人】
【識別番号】100146916
【弁理士】
【氏名又は名称】廣石 雅紀
(74)【代理人】
【識別番号】100147924
【弁理士】
【氏名又は名称】美恵 英樹
(72)【発明者】
【氏名】山田 久
(72)【発明者】
【氏名】甲斐 真紀子
(72)【発明者】
【氏名】黒木 湧太郎
(72)【発明者】
【氏名】鶴房 敬也
【テーマコード（参考）】
3F522
5L049
【Ｆターム（参考）】
3F522AA04
3F522BB06
3F522CC09
3F522GG02
3F522HH17
3F522LL42
5L049AA16
5L049CC52
(57)【要約】
【課題】 複数の管理主体にわたって物品の在庫管理等を実現する。
【解決手段】 複数の管理主体は、系列店における商品在庫を、個別システム１０で管理している。物品管理システム１００は、これらの個別システム１０から、各店舗の商品在庫情報などを受け取る。管理主体ごとに店舗および商品を管理するために用いているコードは異なるため、これを複数の管理主体にわたって一義的に店舗を特定可能な共通コード、一義的に商品を特定可能な商品共通コードに対応づけるための共通コードデータベース１０４を用意しておく。物品管理システム１００は、個別システムから受け取った商品在庫情報を、共通コードおよび商品共通コードを用いて集計することにより、複数の管理主体にわたって、各店舗における在庫を統合的に管理する。
【選択図】 図１
【解決手段】 複数の管理主体は、系列店における商品在庫を、個別システム１０で管理している。物品管理システム１００は、これらの個別システム１０から、各店舗の商品在庫情報などを受け取る。管理主体ごとに店舗および商品を管理するために用いているコードは異なるため、これを複数の管理主体にわたって一義的に店舗を特定可能な共通コード、一義的に商品を特定可能な商品共通コードに対応づけるための共通コードデータベース１０４を用意しておく。物品管理システム１００は、個別システムから受け取った商品在庫情報を、共通コードおよび商品共通コードを用いて集計することにより、複数の管理主体にわたって、各店舗における在庫を統合的に管理する。
【選択図】 図１
【特許請求の範囲】
【請求項1】
複数の管理主体が管理している物品を、統合的に管理するための物品管理システムであって、
それぞれの前記管理主体が前記物品を保管する保管場所を表す前記管理主体固有の情報に、前記複数の管理主体の保管場所を一義的に表す保管場所の共通コードを対応づけるための共通コードデータベースと、
特定の物品について、前記共通コードで特定される前記保管場所ごとの数量を集計する集計部とを備える物品管理システム。
それぞれの前記管理主体が前記物品を保管する保管場所を表す前記管理主体固有の情報に、前記複数の管理主体の保管場所を一義的に表す保管場所の共通コードを対応づけるための共通コードデータベースと、
特定の物品について、前記共通コードで特定される前記保管場所ごとの数量を集計する集計部とを備える物品管理システム。
【請求項2】
請求項１記載の物品管理システムであって、
前記集計の結果を出力する出力部を備える物品管理システム。
前記集計の結果を出力する出力部を備える物品管理システム。
【請求項3】
コンピュータによって、複数の管理主体が管理している物品を、統合的に管理するためのプログラムであって、
それぞれの前記管理主体が前記物品を保管する保管場所を表す前記管理主体固有の情報に、前記複数の管理主体の保管場所を一義的に表す保管場所の共通コードを対応づけるための共通コードデータベースを参照する機能、
特定の物品について、前記共通コードで特定される前記保管場所ごとの数量を集計する機能をコンピュータに実現させるためのプログラム。
それぞれの前記管理主体が前記物品を保管する保管場所を表す前記管理主体固有の情報に、前記複数の管理主体の保管場所を一義的に表す保管場所の共通コードを対応づけるための共通コードデータベースを参照する機能、
特定の物品について、前記共通コードで特定される前記保管場所ごとの数量を集計する機能をコンピュータに実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データ及びデータを利用した装置に関する。
【背景技術】
【0002】
商品コードごとの在庫数量を格納する在庫管理データベースにより商品の各店の在庫を地図上に表示するシステムが存在する（特許文献１）。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１４－１６４３３０号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
本発明は、在庫管理データをより有効に活用することを課題とする。
【課題を解決するための手段】
【0005】
本発明は、
複数の管理主体が管理している物品を、統合的に管理するための物品管理システムであって、
それぞれの前記管理主体が前記物品を保管する保管場所を表す前記管理主体固有の情報に、前記複数の管理主体の保管場所を一義的に表す保管場所の共通コードを対応づけるための共通コードデータベースと、
特定の物品について、前記共通コードで特定される前記保管場所ごとの数量を集計する集計部とを備える物品管理システムと構成することができる。
複数の管理主体が管理している物品を、統合的に管理するための物品管理システムであって、
それぞれの前記管理主体が前記物品を保管する保管場所を表す前記管理主体固有の情報に、前記複数の管理主体の保管場所を一義的に表す保管場所の共通コードを対応づけるための共通コードデータベースと、
特定の物品について、前記共通コードで特定される前記保管場所ごとの数量を集計する集計部とを備える物品管理システムと構成することができる。
【0006】
本発明の一実施形態において、上述の物品管理システムとしての態様の他、コンピュータによって物品を管理する物品管理方法として構成してもよい。また、かかる管理を実現するプログラム、および該プログラムを記録したコンピュータ読み取り可能な記録媒体として構成することもできる。
【図面の簡単な説明】
【0007】
【図1】物品管理システムの構成を示す説明図である。
【図2】データベースの構成を示す説明図である。
【図3】商品在庫検索処理のフローチャートである。
【図4】集計例を示す説明図である。
【図5】出力例（１）を示す説明図である。
【図6】出力例（２）を示す説明図である。
【図7】マスタデータベース更新処理のフローチャートである。
【図8】変形例（１）の商品在庫検索処理のフローチャートである。
【図9】変形例（２）の商品在庫検索処理のフローチャートである。
【図10】集計結果のソート例を示す説明図である。
【図11】アフィリエイト処理のフローチャートである。
【図12】時系列列変化出力処理のフローチャートである。
【図13】マスタデータベース更新処理のフローチャートである。
【図14】物資配給支援処理のフローチャートである。
【発明を実施するための形態】
【0008】
以下、本発明の物品管理システムの実施例について、商品の在庫を管理するシステムとして構成した場合を例にとって説明する。コンビニエンスストア、スーパーなどの小売業においては、各企業は、直営、フランチャイズなどによって複数の系列店を通じて商品の販売をしている。本実施例は、かかる状況を想定し、複数の企業が有する複数の系列店における商品の在庫を統合的に管理するためのシステムである。
即ち、本実施例では、商品が物品に相当し、それを販売する店舗が保管場所に相当する。また、これらの店舗を経営する企業が管理主体に相当する。
以下の実施例は、一例に過ぎず、本発明は種々の物品、管理主体等に適用可能であることは当然である。
即ち、本実施例では、商品が物品に相当し、それを販売する店舗が保管場所に相当する。また、これらの店舗を経営する企業が管理主体に相当する。
以下の実施例は、一例に過ぎず、本発明は種々の物品、管理主体等に適用可能であることは当然である。
【0009】
実施例は、以下の項目に分けて説明する。
Ａ．システム構成：
Ｂ．商品在庫検索処理：
Ｃ．マスタデータベース更新処理：
Ｄ．変形例としての商品在庫検索処理（１）：
Ｅ．変形例としての商品在庫検索処理（２）：
Ｆ．アフィリエイト処理：
Ｇ．時系列変化出力処理：
Ｈ．物資配給支援処理：
Ｉ．効果及び変形例：
Ａ．システム構成：
Ｂ．商品在庫検索処理：
Ｃ．マスタデータベース更新処理：
Ｄ．変形例としての商品在庫検索処理（１）：
Ｅ．変形例としての商品在庫検索処理（２）：
Ｆ．アフィリエイト処理：
Ｇ．時系列変化出力処理：
Ｈ．物資配給支援処理：
Ｉ．効果及び変形例：
【0010】
Ａ．システム構成：
図１は、物品管理システムの構成を示す説明図である。本実施例では、インターネットその他のネットワークＩＮＴに接続され、ＣＰＵ、メモリを備えたサーバ１００に、図示する種々の機能を実現するプログラムをインストールすることによってソフトウェア的に構成した。これらの機能の一部または全部をハードウェア的に構成してもよい。
また、物品管理システムは、必ずしも一台のサーバ、コンピュータなどによって構成する必要はなく、複数台のサーバ等を相互に接続して構成してもよい。
図１は、物品管理システムの構成を示す説明図である。本実施例では、インターネットその他のネットワークＩＮＴに接続され、ＣＰＵ、メモリを備えたサーバ１００に、図示する種々の機能を実現するプログラムをインストールすることによってソフトウェア的に構成した。これらの機能の一部または全部をハードウェア的に構成してもよい。
また、物品管理システムは、必ずしも一台のサーバ、コンピュータなどによって構成する必要はなく、複数台のサーバ等を相互に接続して構成してもよい。
【0011】
本実施例では、物品管理システムは、系列店を営む管理主体としての企業とは別の運営主体が管理・運営するものとして説明するが、いずれかの管理主体が運営するものとしてもよい。また、物品管理システムは、管理主体が運用する個別システム１０、一般消費者などのユーザが使用するスマートフォン、タブレットその他の端末２０などとネットワークＩＮＴを介して種々の情報の授受を行うが、こうした情報の授受についても、種々の形態が可能であり、例えば、スタンドアロンの一台のコンピュータ、サーバなどで情報の入出力を行うものとしてもよい。
【0012】
以下、図中の機能について説明する。
ユーザが利用する端末２０には、物品管理システムで提供されるサービスを利用するためのプログラムであるサービス用アプリ２１がインストールされている。本実施例では、サービス用アプリ２１は、例えば、ユーザが検索する商品の情報を入力したり、検索した結果の表示などに利用される。これらに加えて他の機能にも利用可能としてもよい。また、サービス用アプリ２１に代えて、端末２０が有しているブラウザその他のアプリを適宜、利用するようにしてもよい。
ユーザが利用する端末２０には、物品管理システムで提供されるサービスを利用するためのプログラムであるサービス用アプリ２１がインストールされている。本実施例では、サービス用アプリ２１は、例えば、ユーザが検索する商品の情報を入力したり、検索した結果の表示などに利用される。これらに加えて他の機能にも利用可能としてもよい。また、サービス用アプリ２１に代えて、端末２０が有しているブラウザその他のアプリを適宜、利用するようにしてもよい。
【0013】
管理主体が利用する個別システム１０は、元来、管理主体が系列店などの情報、商品の在庫管理などに用いるシステムであり、ＣＰＵ、メモリを備えるサーバまたはコンピュータで構成されている。本実施例では、さらに、図示する機能を実現するプログラムをインストールされ、物品管理システムに種々の商品の在庫情報、系列店の店舗情報などを提供し、また物品管理システムから、他の管理主体も含めた統合的な物品管理情報を取得するなどの機能を実現している。
個別システム１０の入出力部１１は、物品管理システムとの間で、上述した情報の授受を実現する。
商品データベース１４は、管理主体が取り扱う商品の種別、在庫などを記憶するデータベースである。
店舗データベース１５は、管理主体の系列店の情報を記憶するデータベースである。
データベース管理部１３は、これらのデータベースへのデータの格納、読み出しなどを行う。
報告部１２は、物品管理システムに対して、商品の在庫情報などを所定のタイミングで報告する機能を奏する。タイミングは、サーバ１００から問い合わせを受けた直後でもよいし、サーバ１００からの問い合わせにかかわらず、管理主体の任意のタイミングであってもよい。
個別システム１０の入出力部１１は、物品管理システムとの間で、上述した情報の授受を実現する。
商品データベース１４は、管理主体が取り扱う商品の種別、在庫などを記憶するデータベースである。
店舗データベース１５は、管理主体の系列店の情報を記憶するデータベースである。
データベース管理部１３は、これらのデータベースへのデータの格納、読み出しなどを行う。
報告部１２は、物品管理システムに対して、商品の在庫情報などを所定のタイミングで報告する機能を奏する。タイミングは、サーバ１００から問い合わせを受けた直後でもよいし、サーバ１００からの問い合わせにかかわらず、管理主体の任意のタイミングであってもよい。
【0014】
物品管理システムの機能は、次の通りである。
ユーザデータベース１０１は、物品管理システムの利用者の情報を格納する。本実施例では、利用者は、商品の管理主体および一般消費者が挙げられる。管理主体の情報を管理するデータベースと、一般消費者を管理するデータベースとを分けてもよい。
マスタデータベース１０２は、複数の管理主体の商品の在庫情報などを統合的に管理するデータベースである。マスタデータベース１０２を参照することにより、特定の商品について、複数の管理主体にわたって、それぞれの系列店の在庫の状況などを容易に把握することが可能となる。
オリジナルデータベース１０３は、マスタデータベース１０２で管理される情報に加えて、商品について、管理主体に固有の情報を格納するデータベースである。オリジナルデータベース１０３とマスタデータベース１０２とを一つにまとめて構成してもよい。
共通コードデータベース１０４は、複数の管理主体にわたって複数の系列店や商品を一義的に表す共通コードを付与するためのデータベースである。共通コードには、複数の系列店の店舗を一義的に表すための店舗の共通コード（保管場所の共通コードの一例）を含む。また、共通コードには、複数の商品を一義的に表すための商品共通コードを更に含んでいてもよい。このうち、店舗の共通コードは、たとえば、各店舗をユニークな識別子で表したものである。複数の店舗が広いエリアに跨る場合には、そのエリア内でユニークとなるよう識別子で表される。エリアが全国に跨る場合には、全国でユニークとなる。こうすることで、複数の管理主体およびその系列店にわたって商品の在庫情報などを統合的に管理することが可能となる。以下では、共通コードデータベース１０４に、店舗の共通コードと商品共通コードを含む場合を例に挙げる。なお、各管理主体が各物品について商品共通コードを既に使用している場合には、ここで言う商品共通コードは不要となる。
地図データベース１０５は、物品管理システムにおける在庫情報などを地図上に表示等する場合に利用される地図データを記憶する。本実施例では、屋台のように移動する店舗を対象に含めることも可能であるため、その経路を表示等するためのネットワークデータを含めてもよい。
上述した各データベースの具体的な構成は後述する。また、上述した以外にデータベースを設けても良いし、上述の一部を省略してもよい。
ユーザデータベース１０１は、物品管理システムの利用者の情報を格納する。本実施例では、利用者は、商品の管理主体および一般消費者が挙げられる。管理主体の情報を管理するデータベースと、一般消費者を管理するデータベースとを分けてもよい。
マスタデータベース１０２は、複数の管理主体の商品の在庫情報などを統合的に管理するデータベースである。マスタデータベース１０２を参照することにより、特定の商品について、複数の管理主体にわたって、それぞれの系列店の在庫の状況などを容易に把握することが可能となる。
オリジナルデータベース１０３は、マスタデータベース１０２で管理される情報に加えて、商品について、管理主体に固有の情報を格納するデータベースである。オリジナルデータベース１０３とマスタデータベース１０２とを一つにまとめて構成してもよい。
共通コードデータベース１０４は、複数の管理主体にわたって複数の系列店や商品を一義的に表す共通コードを付与するためのデータベースである。共通コードには、複数の系列店の店舗を一義的に表すための店舗の共通コード（保管場所の共通コードの一例）を含む。また、共通コードには、複数の商品を一義的に表すための商品共通コードを更に含んでいてもよい。このうち、店舗の共通コードは、たとえば、各店舗をユニークな識別子で表したものである。複数の店舗が広いエリアに跨る場合には、そのエリア内でユニークとなるよう識別子で表される。エリアが全国に跨る場合には、全国でユニークとなる。こうすることで、複数の管理主体およびその系列店にわたって商品の在庫情報などを統合的に管理することが可能となる。以下では、共通コードデータベース１０４に、店舗の共通コードと商品共通コードを含む場合を例に挙げる。なお、各管理主体が各物品について商品共通コードを既に使用している場合には、ここで言う商品共通コードは不要となる。
地図データベース１０５は、物品管理システムにおける在庫情報などを地図上に表示等する場合に利用される地図データを記憶する。本実施例では、屋台のように移動する店舗を対象に含めることも可能であるため、その経路を表示等するためのネットワークデータを含めてもよい。
上述した各データベースの具体的な構成は後述する。また、上述した以外にデータベースを設けても良いし、上述の一部を省略してもよい。
【0015】
データベース管理部１１０は、上述した各データベースへのデータの格納、読み出しを行う。
入出力部１２０は、種々の情報の入出力を行う。入力する情報としては、個別システム１０からの情報、端末２０からの情報などが挙げられる。出力する情報としては、商品の在庫情報その他の管理結果などが含まれる。
集計部１３０は、指定された商品の在庫数などを集計する。集計は種々の態様で行い得るが、複数の管理主体にわたって集計することができる点が特徴である。
アフィリエイト処理部１４０は、ユーザが端末２０で物品管理システムから提供される情報（たとえば、商品や店舗のバナー広告、在庫数そのものなど）を見た後、それに応じて店舗に行ったなどの条件が整った時に、メリットを受けた所定の管理主体等に対して広告料を請求するなどの処理を実行する。
表示制御部１５０は、個別システム１０、またはユーザの端末２０に表示するための画面を生成する。表示制御部１５０が生成する画面としては、例えば、物品管理システムを利用するための入力画面や、結果の出力画面などが挙げられる。表示制御部１５０は、これらの画面を表示するための画像データ等を生成し、ネットワークＩＮＴを介して個別システム１０や端末２０に画面を表示させるのである。
入出力部１２０は、種々の情報の入出力を行う。入力する情報としては、個別システム１０からの情報、端末２０からの情報などが挙げられる。出力する情報としては、商品の在庫情報その他の管理結果などが含まれる。
集計部１３０は、指定された商品の在庫数などを集計する。集計は種々の態様で行い得るが、複数の管理主体にわたって集計することができる点が特徴である。
アフィリエイト処理部１４０は、ユーザが端末２０で物品管理システムから提供される情報（たとえば、商品や店舗のバナー広告、在庫数そのものなど）を見た後、それに応じて店舗に行ったなどの条件が整った時に、メリットを受けた所定の管理主体等に対して広告料を請求するなどの処理を実行する。
表示制御部１５０は、個別システム１０、またはユーザの端末２０に表示するための画面を生成する。表示制御部１５０が生成する画面としては、例えば、物品管理システムを利用するための入力画面や、結果の出力画面などが挙げられる。表示制御部１５０は、これらの画面を表示するための画像データ等を生成し、ネットワークＩＮＴを介して個別システム１０や端末２０に画面を表示させるのである。
【0016】
以上で説明した構成は一例に過ぎず、種々の変形例が可能である。上述以外の機能を追加してもよいし、一部を省略してもよい。
【0017】
図２は、データベースの構成を示す説明図である。個別システム１０に備えられた商品データベース１４、店舗データベース１５の構成、および物品管理システムに備えられたマスタデータベース１０２、オリジナルデータベース１０３、共通コードデータベース１０４の構成を示した。
【0018】
商品データベース１４には、商品の識別子である商品コードをキーとして、商品名、カテゴリ、メーカー価格など商品の属性が記憶されている。商品データベース１４に記憶されているデータの内容やその構造は、管理主体ごとに異なっていても差し支えない。
商品コードは、管理主体がそれぞれの商品に付与したものである。従って、管理主体内で一義的に商品を特定できるものであればよい。同じ商品を特定するために他の管理主体では全く異なる商品コードが使用されていても差し支えない。また、同じ商品コードが、他の管理主体では別の商品を表すものとして使用されていても差し支えない。
商品コードは、管理主体がそれぞれの商品に付与したものである。従って、管理主体内で一義的に商品を特定できるものであればよい。同じ商品を特定するために他の管理主体では全く異なる商品コードが使用されていても差し支えない。また、同じ商品コードが、他の管理主体では別の商品を表すものとして使用されていても差し支えない。
【0019】
店舗データベース１５は、管理主体ごとに系列店を表す情報を記憶している。記憶されているデータの内容やその構造は、管理主体ごとに異なっていても差し支えない。
店舗コードは、管理主体が各系列店に付した識別子である。管理主体ごとに付与するものであるため、それぞれの管理主体内で一義的に店舗を特定できるものであればよい。他の管理主体が付与する店舗コードと重複していても差し支えない。
店舗コードをキーとして、店舗名、位置、責任者などの店舗の属性情報が記憶されている。なお、店舗名はそれぞれの管理主体内では、各店舗を一義的に特定できる情報となっていることが通常であるから、店舗名を店舗コードとして利用してもよい。
また、その店舗における商品の在庫情報も記憶されている。商品の在庫情報としては、商品コード、在庫、価格などの一組の情報が、その店舗で取り扱う商品をカバーするよう繰り返して記憶されることになる。在庫情報は、時々刻々変化する情報であるため、情報が記憶された時刻を併せて記憶しておいてもよい。なお、価格も、広告掲載品やタイムセール品、店舗の閉店時間や賞味期限が近づいた値引き品など、日や時間によって変化する情報である。また、最新の情報だけでなく、過去の情報や、入荷予定などの将来の情報も時系列に記憶するようにしてもよい。本実施例では、在庫情報を店舗データベース１５に組み込む形で構成しているが、在庫情報を別のデータベースとして構成することも可能である。
店舗コードは、管理主体が各系列店に付した識別子である。管理主体ごとに付与するものであるため、それぞれの管理主体内で一義的に店舗を特定できるものであればよい。他の管理主体が付与する店舗コードと重複していても差し支えない。
店舗コードをキーとして、店舗名、位置、責任者などの店舗の属性情報が記憶されている。なお、店舗名はそれぞれの管理主体内では、各店舗を一義的に特定できる情報となっていることが通常であるから、店舗名を店舗コードとして利用してもよい。
また、その店舗における商品の在庫情報も記憶されている。商品の在庫情報としては、商品コード、在庫、価格などの一組の情報が、その店舗で取り扱う商品をカバーするよう繰り返して記憶されることになる。在庫情報は、時々刻々変化する情報であるため、情報が記憶された時刻を併せて記憶しておいてもよい。なお、価格も、広告掲載品やタイムセール品、店舗の閉店時間や賞味期限が近づいた値引き品など、日や時間によって変化する情報である。また、最新の情報だけでなく、過去の情報や、入荷予定などの将来の情報も時系列に記憶するようにしてもよい。本実施例では、在庫情報を店舗データベース１５に組み込む形で構成しているが、在庫情報を別のデータベースとして構成することも可能である。
【0020】
共通コードデータベース１０４は、管理主体ごとに異なるコードの共通化を図るための情報を記憶している。本実施例では、商品についてのコードの共通化を図るデータと、店舗についてのコードの共通化を図るデータに分けて記憶した。データ構造および内容は、種々の変形例をとり得る。本実施形態では、商品についてのコードの共通化を図るデータを商品共通コードと示し、店舗についてのコードの共通化を図るデータを、共通コードまたは店舗の共通コードと示す場合がある。
【0021】
商品の共通化を図るデータは、図中の左側に示した。商品共通コードは、複数の管理主体にまたがって商品を一義的に特定できる識別子である。かかる商品共通コードとしては、例えば、ＪＡＮコードなどを用いることができるが、本実施例に固有のコード体系を用いても差し支えない。
商品共通コードに対しては、商品名が対応づけて記憶される。併せて、カテゴリ、メーカーなどの属性情報を記憶してもよい。
また、それぞれの管理主体で同じ商品に対して用いられる商品コードが紐付けられている。この情報は、図中に示す通り、管理主体を表す「小売業者」情報と、その管理主体で用いられている商品コードが一組となって、複数の管理主体について記憶されることになる。「小売業者」の情報は、名称や、ユーザデータベース１０１において管理主体を表すために付与される識別子など種々の形式を用いることができる。
商品共通コードに対しては、商品名が対応づけて記憶される。併せて、カテゴリ、メーカーなどの属性情報を記憶してもよい。
また、それぞれの管理主体で同じ商品に対して用いられる商品コードが紐付けられている。この情報は、図中に示す通り、管理主体を表す「小売業者」情報と、その管理主体で用いられている商品コードが一組となって、複数の管理主体について記憶されることになる。「小売業者」の情報は、名称や、ユーザデータベース１０１において管理主体を表すために付与される識別子など種々の形式を用いることができる。
【0022】
店舗の共通化を図るデータは、図中の右側に示した。店舗の共通コードは、複数の管理主体にまたがって店舗を一義的に特定できる識別子である。例えば、管理主体を表す識別子と、そこで用いられている店舗コードとを組み合わせて設定してもよいし、本実施例に固有のコード体系を用いても差し支えない。
店舗の共通コードに対しては、図中に示す通り、管理主体を表す「小売業者」情報と、その管理主体で用いられている店舗コードが記憶されている。また、店舗名、位置などの属性情報も併せて記憶される。属性情報としては、営業時間、店舗の種別（コンビニエンスストア、スーパーなどを意味する）などを併せて記憶するようにしてもよい。
店舗の共通コードに対しては、図中に示す通り、管理主体を表す「小売業者」情報と、その管理主体で用いられている店舗コードが記憶されている。また、店舗名、位置などの属性情報も併せて記憶される。属性情報としては、営業時間、店舗の種別（コンビニエンスストア、スーパーなどを意味する）などを併せて記憶するようにしてもよい。
【0023】
このように設定された共通コードデータベース１０４を用いることにより、管理主体ごとに異なる商品コード、店舗コードを共通化することができる。
例えば、図示するように、管理主体の個別システムにおける商品データベース１４に記憶されている商品コードは、共通コードデータベース１０４に記憶されている商品コードと対応しているから、これに基づいて、当該商品を表す商品共通コードを特定することができる。逆に、商品共通コードがわかる場合には、共通コードデータベース１０４を参照することにより、それぞれの管理主体では、どのような商品コードが用いられているのかを特定することができる。
また、管理主体の店舗データベース１５で用いられている店舗コードは、共通コードデータベース１０４に記憶されている店舗コードと対応しているから、店舗についても同様に管理主体ごとの店舗コードと共通コードとを相互に特定することができる。
例えば、図示するように、管理主体の個別システムにおける商品データベース１４に記憶されている商品コードは、共通コードデータベース１０４に記憶されている商品コードと対応しているから、これに基づいて、当該商品を表す商品共通コードを特定することができる。逆に、商品共通コードがわかる場合には、共通コードデータベース１０４を参照することにより、それぞれの管理主体では、どのような商品コードが用いられているのかを特定することができる。
また、管理主体の店舗データベース１５で用いられている店舗コードは、共通コードデータベース１０４に記憶されている店舗コードと対応しているから、店舗についても同様に管理主体ごとの店舗コードと共通コードとを相互に特定することができる。
【0024】
マスタデータベース１０２は、複数の管理主体の商品の在庫情報などを統合的に管理するデータベースである。商品共通コードと店舗の共通コードとをキーとして、在庫数、価格、属性などの情報が記憶されている。即ち、商品共通コードにより商品が特定され、店舗の共通コードにより店舗が特定されることになるから、特定の店舗における特定の商品について、上述の情報を知ることができるデータベースとなっている。在庫数などは時間の経過に伴い変動するから、データが記憶された時刻を対応づけて記憶してもよいし、最新のデータだけでなく過去のデータも時系列に記憶しておいてもよい。
属性としては、商品の名称など種々のデータを記憶することができるが、その内容は、レコードごとに異なっていても良い。例えば、ある店舗で販売されている商品に対して、その店舗限りの値引き情報や特典などが記憶されていてもよいし、「○○にぴったり」などの広告情報が記憶されていてもよい。
属性としては、商品の名称など種々のデータを記憶することができるが、その内容は、レコードごとに異なっていても良い。例えば、ある店舗で販売されている商品に対して、その店舗限りの値引き情報や特典などが記憶されていてもよいし、「○○にぴったり」などの広告情報が記憶されていてもよい。
【0025】
オリジナルデータベース１０３は、マスタデータベース１０２で管理される情報に加えて、商品について、管理主体に固有の情報を格納するデータベースである。図示する通り、商品非共通コードが用いられる他、そのデータ構造は、マスタデータベース１０２と同じである。商品非共通コードとは、商品共通コードと異なり、管理主体に固有の商品コードである。複数の管理主体で重複しないように構成されていれば、商品データベース１４で用いられている商品コードをそのまま用いることもできる。かかる構成としては、例えば、管理主体を表す識別子を商品コードに付加する形が挙げられる。
商品非共通コードは、共通コードデータベース１０４と同様のデータによって、それぞれの管理主体が用いている商品コードと紐付けられているものとする。
商品非共通コードは、共通コードデータベース１０４と同様のデータによって、それぞれの管理主体が用いている商品コードと紐付けられているものとする。
【0026】
また、商品非共通コードは、商品共通コードに枝番を付与する形で設定してもよい。商品共通コードは物品管理システムが付与するものであるのに対し、商品非共通コードは管理主体が任意に設定できるものである点で相違する。こうすることにより、例えば、商品共通コードで表される商品について、新品／中古、商品の色など種々の属性に応じて細分化した枝番を設定することができ、より細かく商品の管理を行うことが可能となる。
【0027】
商品非共通コードは、階層構造とすることにより、商品共通コードと関連を持たせるようにしてもよい。例えば、商品非共通コードについて、上位層では食品、雑貨などの大分類を表し、中位層では食品について野菜、肉、加工品というように中分類を表し、下位層では具体的な商品名を表すなどのように階層構造としておくのである。同様に、商品共通コードもこうした階層構造にしておく。３階層に限る必要は無く階層の数は任意に決めることができる。
こうすることで、商品非共通コードを用いる場合でも、上位層または中位層などでは商品共通コードと関連づけることができるから、オリジナルデータベース１０３に記憶されている商品の情報をより有効活用することが可能となる。
商品共通コードに対して枝番を付与する形で商品非共通コードを設定する形式は、商品非共通コードが商品共通コードの下位層に属するという意味で階層構造の一例ということもできる。
こうすることで、商品非共通コードを用いる場合でも、上位層または中位層などでは商品共通コードと関連づけることができるから、オリジナルデータベース１０３に記憶されている商品の情報をより有効活用することが可能となる。
商品共通コードに対して枝番を付与する形で商品非共通コードを設定する形式は、商品非共通コードが商品共通コードの下位層に属するという意味で階層構造の一例ということもできる。
【0028】
Ｂ．商品在庫検索処理：
図３は、商品在庫検索処理のフローチャートである。指定された商品について、複数の管理主体にわたって在庫数の情報を検索し、集計する処理である。物品管理システムの集計部１３０が主として行う処理であり、ハードウェア的にはサーバ１００が実行する処理である。
図３は、商品在庫検索処理のフローチャートである。指定された商品について、複数の管理主体にわたって在庫数の情報を検索し、集計する処理である。物品管理システムの集計部１３０が主として行う処理であり、ハードウェア的にはサーバ１００が実行する処理である。
【0029】
処理を開始すると、物品管理システムは、検索の対象となる商品の指定を受け付ける（ステップＳ１０）。この指定は、例えば、一般消費者が端末２０を用いて行う場合が想定される。また、当該商品のメーカーなどが生産計画を作成するとき、販促活動やマーケティングを行うときの参考にする、卸売会社や物流会社などが流通・運送計画を作成するときや運転手を確保するときの参考にするなどの目的などで物品管理システムを利用する場面も想定される。さらに、管理主体が、他の管理主体も含めた全体の在庫状況などを把握するために利用する場面も考えられる。
【0030】
指定の受け付けには、例えば、商品共通コード、商品名、写真などを用いることができる。写真を用いる場合としては、例えば、インターネットで見つけた商品の画像を送信したり、街中で見つけた商品の写真を撮影して送信する場合などが考えられる。物品管理システムが、送信された写真に基づいて画像検索で、対応する商品共通コードを特定できるようにしておけばよい。
上記の項目は、これらを単独で用いてもよいし、複数の組み合わせで用いても良い。上記の項目以外に、商品のメーカー名、愛称や通称など種々の情報を組み合わせて特定できるようにしてもよい。商品名などの種々の情報から商品共通コードを検索可能な仕組みを設けてもよい。
上記の項目は、これらを単独で用いてもよいし、複数の組み合わせで用いても良い。上記の項目以外に、商品のメーカー名、愛称や通称など種々の情報を組み合わせて特定できるようにしてもよい。商品名などの種々の情報から商品共通コードを検索可能な仕組みを設けてもよい。
【0031】
次に、物品管理システムは検索対象領域の指定を受け付ける（ステップＳ１１）。例えば、端末２０の位置情報を基準として、その周囲の一定の領域を検索対象領域としてもよい。また、市町村名などの行政界で指定してもよい。検索対象領域は、必ずしも閉じた一カ所の領域である必要はなく、例えば、政令指定都市、人口○人以上の都市、スキー場などのように散在する地域を指定可能としてもよい。なお、検索対象領域は、指定なし、即ち日本国内全体を対象とするものとしても良い。
【0032】
商品および検索対象領域が決まると、物品管理システムは、管理主体に指定された商品の在庫を問い合わせる（ステップＳ１２）。指定された商品に対応する商品共通コードを、物品管理システムに登録されている各管理主体に送信して、その在庫数などの回答を得るようにすればよい。
このとき指定された検索対象領域内に存在する店舗のみを指定して問い合わせるようにしてもよい。こうすれば、管理主体の個別システムと物品管理システムとの間の通信量を抑制できる利点がある。
このとき指定された検索対象領域内に存在する店舗のみを指定して問い合わせるようにしてもよい。こうすれば、管理主体の個別システムと物品管理システムとの間の通信量を抑制できる利点がある。
【0033】
物品管理システムは、管理主体からの回答に対して、共通店舗コードを割り当てて集計する（ステップＳ１３）。指定された検索対象領域を外れる店舗を含む回答が得られている場合には、物品管理システムは、検索対象領域内の情報のみを選択して集計すればよい。
管理主体からは、店舗コードごとに在庫数などの回答が得られるから、この店舗コードを共通コードデータベース１０４を参照して店舗の共通コードに変換することにより、店舗の共通コードをキーとした集計が可能となる。この集計方法については、後で具体例を示す。
こうして集計が完了すると、物品管理システムは、結果の出力および保存を行って（ステップＳ１４）、商品在庫検索処理を終了する。結果の出力先は、端末２０などが挙げられる。
管理主体からは、店舗コードごとに在庫数などの回答が得られるから、この店舗コードを共通コードデータベース１０４を参照して店舗の共通コードに変換することにより、店舗の共通コードをキーとした集計が可能となる。この集計方法については、後で具体例を示す。
こうして集計が完了すると、物品管理システムは、結果の出力および保存を行って（ステップＳ１４）、商品在庫検索処理を終了する。結果の出力先は、端末２０などが挙げられる。
【0034】
図４は、集計例を示す説明図である。
一番左側には、特定の商品について、Ａ社、Ｂ社の２つの管理主体からの回答を模式的に示した。この例では、店舗名がそれぞれの管理主体において「店舗コード」として利用されているものとして説明する。Ａ社の「○○店」、Ｂ社の「○○店」という店舗名は、重複しているが、それぞれの管理主体内では店舗は特定されるから店舗コードとして機能することになる。しかし、Ａ社、Ｂ社にわたって在庫情報を統合的に管理しようとすると、「○○店」では、店舗を一義的に特定することはできない。
一番左側には、特定の商品について、Ａ社、Ｂ社の２つの管理主体からの回答を模式的に示した。この例では、店舗名がそれぞれの管理主体において「店舗コード」として利用されているものとして説明する。Ａ社の「○○店」、Ｂ社の「○○店」という店舗名は、重複しているが、それぞれの管理主体内では店舗は特定されるから店舗コードとして機能することになる。しかし、Ａ社、Ｂ社にわたって在庫情報を統合的に管理しようとすると、「○○店」では、店舗を一義的に特定することはできない。
【0035】
そこで、本実施例では、共通コードデータベース１０４を参照して、それぞれの店舗名を共通コードに置き換える。図４の中央に、その対応づけを示した。
上段には、Ａ社についての店舗の共通コードデータベース１０４を示した。○○店には、Ａ１という店舗の共通コードが割り当てられ、またその位置情報が付されている。同様に××店には、Ａ２という店舗の共通コードが割り当てられている。
下段には、Ｂ社についての店舗の共通コードデータベース１０４を示した。○○店にはＢ１、□□店にはＢ２という店舗の共通コードが割り当てられている。
このように店舗の共通コードに置き換えることにより、Ａ社、Ｂ社にわたって、店舗を一義的に特定できることになる。従って、図４の右側に示すように、店舗の共通コードをキーとして、特定の商品の在庫数を集計することが可能となる。即ち、Ａ社の○○店における在庫ａ１個という情報は、店舗の共通コードＡ１の店舗における在庫ａ１個という情報として集計されるのである。他の店舗における在庫情報も同様である。
上段には、Ａ社についての店舗の共通コードデータベース１０４を示した。○○店には、Ａ１という店舗の共通コードが割り当てられ、またその位置情報が付されている。同様に××店には、Ａ２という店舗の共通コードが割り当てられている。
下段には、Ｂ社についての店舗の共通コードデータベース１０４を示した。○○店にはＢ１、□□店にはＢ２という店舗の共通コードが割り当てられている。
このように店舗の共通コードに置き換えることにより、Ａ社、Ｂ社にわたって、店舗を一義的に特定できることになる。従って、図４の右側に示すように、店舗の共通コードをキーとして、特定の商品の在庫数を集計することが可能となる。即ち、Ａ社の○○店における在庫ａ１個という情報は、店舗の共通コードＡ１の店舗における在庫ａ１個という情報として集計されるのである。他の店舗における在庫情報も同様である。
【0036】
【0037】
図５（ａ）は、地図上に集計結果を出力する例を示した。左側に示すように、この例では、「××ポテトチップス」が対象の商品である。商品共通コードも示されている。
そして、その下に、複数の店舗の名称および在庫数が一覧として表示され、右側には地図上にアイコンで各店舗の位置が示されている。また、それぞれのアイコンに付した数字は、各店舗における在庫数を表している。ここに出力される店舗は、複数の管理主体の系列店が混在している。
これらのアイコンのいずれかをクリックすれば、地図中に「△△コンビニ神田須田町１丁目店」のように店舗名称その他の詳細な情報が表示されるようになっている。
そして、その下に、複数の店舗の名称および在庫数が一覧として表示され、右側には地図上にアイコンで各店舗の位置が示されている。また、それぞれのアイコンに付した数字は、各店舗における在庫数を表している。ここに出力される店舗は、複数の管理主体の系列店が混在している。
これらのアイコンのいずれかをクリックすれば、地図中に「△△コンビニ神田須田町１丁目店」のように店舗名称その他の詳細な情報が表示されるようになっている。
【0038】
この出力は、図５（ｂ）に示すように地図を用いないリスト形式をとってもよい。リスト形式の出力では、図示する通り、店舗名、在庫数、検索した商品の金額、店舗の営業時間などの詳細な情報が一覧できるため、ユーザが店舗を選択しやすいという利点がある。
また、各店舗に対応づけて表示されている「地図」のボタンをクリックすれば、その店舗周辺の地図が表示される。ユーザの現在位置からの経路を併せて表示してもよい。
リストの右側には、レビューも表示した。過去の利用者の評価が、星印の数で示されている。また、「レビュー」ボタンをクリックすることにより、ユーザが自身のレビューを投稿することも可能となっている。リストには、その他、種々の情報を表示可能である。
また、各店舗に対応づけて表示されている「地図」のボタンをクリックすれば、その店舗周辺の地図が表示される。ユーザの現在位置からの経路を併せて表示してもよい。
リストの右側には、レビューも表示した。過去の利用者の評価が、星印の数で示されている。また、「レビュー」ボタンをクリックすることにより、ユーザが自身のレビューを投稿することも可能となっている。リストには、その他、種々の情報を表示可能である。
【0039】
【0040】
特許文献１に示したように、従来においても、管理主体単位で各店舗の在庫数などを出力する技術は提案されていた。しかし、かかる方法では、一般消費者が特定の商品を検索し、ある管理主体の系列店の店舗の情報を得たとしても、別の系列店であればもっと近くに在庫があるかも知れず、利便性に欠ける面があった。
これに対し、本実施例では、ユーザは、複数の管理主体の系列店が統合的に出力されるため、検索した商品が、管理主体を問わず、どの店舗で販売されているか、また在庫がどれくらいあるかを容易に知ることができる。また、本実施例の出力によって得られた在庫情報によれば、他の管理主体の店舗ならもっと近くで入手できたかも知れない、という思いをすることなく安心して店舗に赴くことができる利点もある。また、賞味期限が近づいた値引き品などの食品の在庫情報をユーザが知り購入することによって、近年の社会問題となっている食品ロスの削減に貢献することにも繋がる。更には、限定品や希少品など入手が困難な商品について、ユーザがいくつもの店舗を訪れて探し回る必要もなくなる。加えて、災害発生時など有事においては、食料や生活必需品などの商品を求めて、一般消費者が店舗に殺到するという事態を軽減することができる。店舗にとっても、在庫情報に関する一般消費者からの問い合わせに対応する時間を削減することができるだけでなく、メーカーの生産計画の精度が向上することによって、在庫不足による売上機会の逸失を防止することができる。
これに対し、本実施例では、ユーザは、複数の管理主体の系列店が統合的に出力されるため、検索した商品が、管理主体を問わず、どの店舗で販売されているか、また在庫がどれくらいあるかを容易に知ることができる。また、本実施例の出力によって得られた在庫情報によれば、他の管理主体の店舗ならもっと近くで入手できたかも知れない、という思いをすることなく安心して店舗に赴くことができる利点もある。また、賞味期限が近づいた値引き品などの食品の在庫情報をユーザが知り購入することによって、近年の社会問題となっている食品ロスの削減に貢献することにも繋がる。更には、限定品や希少品など入手が困難な商品について、ユーザがいくつもの店舗を訪れて探し回る必要もなくなる。加えて、災害発生時など有事においては、食料や生活必需品などの商品を求めて、一般消費者が店舗に殺到するという事態を軽減することができる。店舗にとっても、在庫情報に関する一般消費者からの問い合わせに対応する時間を削減することができるだけでなく、メーカーの生産計画の精度が向上することによって、在庫不足による売上機会の逸失を防止することができる。
【0041】
かかる出力を実現したのは、本実施例において、それぞれの管理主体の系列店を、店舗の共通コードで管理可能としたからである。系列店の名称は、地名、町名などを用いて「○○町店」のように決められることが多く、複数の管理主体間で重複することが多い。このため、複数の管理主体にわたって、統合的に在庫管理することは容易ではなかったのである。
本実施例では、かかる課題を、複数の管理主体にわたって一義的に店舗を特定可能な店舗の共通コードを導入することで回避した。また、こうすることにより、店舗の共通コードをキーとする在庫管理情報は、そのままでは、どの管理主体のどの店舗の情報かは分からない状態となるため、管理主体としても物品管理システムに在庫情報を提供する抵抗感が低くなるという利点もある。
本実施例では、かかる課題を、複数の管理主体にわたって一義的に店舗を特定可能な店舗の共通コードを導入することで回避した。また、こうすることにより、店舗の共通コードをキーとする在庫管理情報は、そのままでは、どの管理主体のどの店舗の情報かは分からない状態となるため、管理主体としても物品管理システムに在庫情報を提供する抵抗感が低くなるという利点もある。
【0042】
図６は、出力例（２）を示す説明図である。移動店舗を含んでいる場合の出力例を示した。移動店舗を含む場合も、図５（１）、図５（２）に示した形式の表示をとることはできるが、図６の例では、移動することを考慮し、その経路および到着時刻などを併せて表示するようにしている。
図中では、所定の経路を移動しながらお弁当を販売する移動店舗としてのお弁当屋、および所定の営業時間だけ特定の場所で営業するおでんの屋台を例示した。
お弁当屋については、地図上に移動経路を示しそれぞれの地点の到着予定時刻や、その時点での想定される在庫数などを併せて表示している。図の例では、地点ｐ１（到着時刻１１：００、在庫２０個）、地点ｐ２（到着時刻１１：３０、在庫１５個）となっており、地点ｐ３、ｐ４についても同様の内容の表示がなされている。
これらの到着時刻、在庫数は過去の実績に基づいた予測結果として表示することができる。実際の状況に応じて表示内容を更新してもよい。例えば、地点ｐ１を出発する時点で、その時刻に基づいて地点ｐ２以降の到着時刻を修正してもよい。また、地点ｐ１を出発する時点での在庫数に応じて地点ｐ２以降の在庫数を修正してもよい。こうすることで、より正確な情報をユーザに提供することが可能となる。
図中では、所定の経路を移動しながらお弁当を販売する移動店舗としてのお弁当屋、および所定の営業時間だけ特定の場所で営業するおでんの屋台を例示した。
お弁当屋については、地図上に移動経路を示しそれぞれの地点の到着予定時刻や、その時点での想定される在庫数などを併せて表示している。図の例では、地点ｐ１（到着時刻１１：００、在庫２０個）、地点ｐ２（到着時刻１１：３０、在庫１５個）となっており、地点ｐ３、ｐ４についても同様の内容の表示がなされている。
これらの到着時刻、在庫数は過去の実績に基づいた予測結果として表示することができる。実際の状況に応じて表示内容を更新してもよい。例えば、地点ｐ１を出発する時点で、その時刻に基づいて地点ｐ２以降の到着時刻を修正してもよい。また、地点ｐ１を出発する時点での在庫数に応じて地点ｐ２以降の在庫数を修正してもよい。こうすることで、より正確な情報をユーザに提供することが可能となる。
【0043】
おでんの屋台については、営業する地点を示すとともに、その営業時間に関する情報を併せて表示している。また、併せて提供できる料理の在庫量を表示してもよい。
この表示は、営業時間外であっても行うようにしてもよい。こうすれば、ユーザは、営業時間帯を考慮して、屋台を訪れることが可能となる。
また、屋台の表示は、営業時間内にのみ行うようにしてもよい。こうすることで、ユーザが、営業していない時間であるにもかかわらず営業しているものと勘違いするおそれを抑制することができる。
これらの表示は、ユーザの設定によって切り換え可能としてもよい。
この表示は、営業時間外であっても行うようにしてもよい。こうすれば、ユーザは、営業時間帯を考慮して、屋台を訪れることが可能となる。
また、屋台の表示は、営業時間内にのみ行うようにしてもよい。こうすることで、ユーザが、営業していない時間であるにもかかわらず営業しているものと勘違いするおそれを抑制することができる。
これらの表示は、ユーザの設定によって切り換え可能としてもよい。
【0044】
図６に示した通り、物品管理システムは、移動店舗についても在庫情報を提供可能である。図６では、移動店舗のみを例示したが、例えば、「お弁当」はコンビニエンスストアでも販売しているため、図５（ａ）に示した表示を、それぞれの固定の店舗に対して行うとともに、移動店舗については図６に示した表示を行うようにしてもよい。
【0045】
Ｃ．マスタデータベース更新処理：
商品在庫検索処理（図４）では、検索時に対象となる商品の在庫情報を、管理主体に問い合わせる処理例を示した。こうすることにより、最新の在庫情報を得ることができる利点がある一方、問い合わせ時の通信量が増えるというデメリットも存在する。
一方、マスタデータベース１０２に、適宜、在庫情報を更新しておけば、商品在庫検索処理（図４）では、マスタデータベース１０２を参照することにより、検索時に管理主体に問い合わせするまでもなく、容易に集計を行うことが可能となる。
商品在庫検索処理（図４）では、検索時に対象となる商品の在庫情報を、管理主体に問い合わせる処理例を示した。こうすることにより、最新の在庫情報を得ることができる利点がある一方、問い合わせ時の通信量が増えるというデメリットも存在する。
一方、マスタデータベース１０２に、適宜、在庫情報を更新しておけば、商品在庫検索処理（図４）では、マスタデータベース１０２を参照することにより、検索時に管理主体に問い合わせするまでもなく、容易に集計を行うことが可能となる。
【0046】
図７は、マスタデータベース更新処理のフローチャートである。上述した通り、マスタデータベース１０２の内容を更新するための処理である。主としてデータベース管理部１１０によって実行される処理であり、ハードウェア的にはサーバ１００によって実行される処理である。
【0047】
処理を開始すると、物品管理システムは、マスタデータベースを読み込む（ステップＳ２０）。
そして、管理主体から更新情報を受け取る（ステップＳ２１）。更新情報は、従前の情報からの変更内容のみを受け取るようにしてもよい。また、通信を行う時点での在庫情報全体を受け取るようにしてもよい。
そして、管理主体から更新情報を受け取る（ステップＳ２１）。更新情報は、従前の情報からの変更内容のみを受け取るようにしてもよい。また、通信を行う時点での在庫情報全体を受け取るようにしてもよい。
【0048】
物品管理システムは、受け取った情報について、管理主体の店舗名を店舗の共通コードに置き換える（ステップＳ２２）。置換方法は図４で説明した通りである。店舗名以外に、管理主体に固有の店舗コードが用いられている場合も同様である。
そして、置き換えた店舗の共通コード、商品共通コードにより、マスタデータベース１０２の対応するレコードを検索する（ステップＳ２３）。
対応するレコードが存在する場合は（ステップＳ２４）、データを更新すればよい（ステップＳ２５）。
一方、新たな商品を扱い始めた場合など、マスタデータベース１０２には、対応するレコードがない場合は（ステップＳ２４）、物品管理システムは、新規レコードを作成し（ステップＳ２６）、そこに在庫情報を記憶する。
そして、置き換えた店舗の共通コード、商品共通コードにより、マスタデータベース１０２の対応するレコードを検索する（ステップＳ２３）。
対応するレコードが存在する場合は（ステップＳ２４）、データを更新すればよい（ステップＳ２５）。
一方、新たな商品を扱い始めた場合など、マスタデータベース１０２には、対応するレコードがない場合は（ステップＳ２４）、物品管理システムは、新規レコードを作成し（ステップＳ２６）、そこに在庫情報を記憶する。
【0049】
こうして全レコードについてデータの更新をすると、物品管理システムは、更新したマスタデータを格納して（ステップＳ２７）、マスタデータベース更新処理を終了する。更新前のマスタデータベースは、時系列の変化をみるために残しておいても良い。
【0050】
以上で示したマスタデータベース更新処理によれば、適宜、マスタデータベースを最新の状態にできるため、通信量を抑制しながら、在庫情報の集計ができる利点がある。
マスタデータベース更新処理は、全ての管理主体について同じタイミング、頻度で更新されることが好ましいが、更新タイミング、頻度が異なることを排除するものでない。
管理主体によって更新タイミング、頻度が異なる場合には、データの精度にばらつきが生じないように配慮することがこのましい。例えば、管理主体の系列店で、商品の仕入れ、販売がなされたときにその店舗についてマスタデータベース更新処理を行うようにしてもよい。こうすれば、更新タイミング、頻度が統一されていなくても、在庫情報に変動をもたらすイベントが生じるタイミングでマスタデータベースが更新されるため、情報の精度を維持することができる。
また、マスタデータベースを定期的に更新するようにしてもよい。この場合には、過去の仕入れ、販売の頻度などに基づいて、これらのイベントが生じる時間帯、頻度などを求め、その結果に応じて、更新する間隔を設定してもよい。更新のタイミングは、曜日、時間帯などに応じて変動させてもよい。
さらに、物品管理システムを利用する頻度に応じて、更新のタイミングを決めてもよい。即ち、ユーザが、物品管理システムで在庫の集計等を行った過去の実績に基づいて、その間隔や頻度を求め、これに応じてマスタデータベースを更新する間隔を設定してもよい。こうすることにより、物品管理システムの利用頻度が低い時間帯は通信量を抑制しつつ、利用頻度が高い時間帯に、マスタデータベースの精度を維持することができる利点がある。
この他、マスタデータの更新は種々のタイミングで行うことができる。
マスタデータベース更新処理は、全ての管理主体について同じタイミング、頻度で更新されることが好ましいが、更新タイミング、頻度が異なることを排除するものでない。
管理主体によって更新タイミング、頻度が異なる場合には、データの精度にばらつきが生じないように配慮することがこのましい。例えば、管理主体の系列店で、商品の仕入れ、販売がなされたときにその店舗についてマスタデータベース更新処理を行うようにしてもよい。こうすれば、更新タイミング、頻度が統一されていなくても、在庫情報に変動をもたらすイベントが生じるタイミングでマスタデータベースが更新されるため、情報の精度を維持することができる。
また、マスタデータベースを定期的に更新するようにしてもよい。この場合には、過去の仕入れ、販売の頻度などに基づいて、これらのイベントが生じる時間帯、頻度などを求め、その結果に応じて、更新する間隔を設定してもよい。更新のタイミングは、曜日、時間帯などに応じて変動させてもよい。
さらに、物品管理システムを利用する頻度に応じて、更新のタイミングを決めてもよい。即ち、ユーザが、物品管理システムで在庫の集計等を行った過去の実績に基づいて、その間隔や頻度を求め、これに応じてマスタデータベースを更新する間隔を設定してもよい。こうすることにより、物品管理システムの利用頻度が低い時間帯は通信量を抑制しつつ、利用頻度が高い時間帯に、マスタデータベースの精度を維持することができる利点がある。
この他、マスタデータの更新は種々のタイミングで行うことができる。
【0051】
Ｄ．変形例としての商品在庫検索処理（１）：
本実施例では、複数の管理主体にわたって共通の商品共通コードだけでなく、管理主体に固有の商品非共通コードの使用も許容している（図１、２参照）。以下では、商品非共通コードも利用した商品在庫検索処理について説明する。
本実施例では、複数の管理主体にわたって共通の商品共通コードだけでなく、管理主体に固有の商品非共通コードの使用も許容している（図１、２参照）。以下では、商品非共通コードも利用した商品在庫検索処理について説明する。
【0052】
図８は、変形例（１）の商品在庫検索処理のフローチャートである。
処理を開始すると、物品管理システムは、商品の検索条件の指定を受け付ける（ステップＳ３０）。図中に検索条件を指定する画面例を示した。
この画面では、検索するための対象エリアを、地域で指定するようになっている。
また、商品については、キーワードを入力できる。例えば、商品の略称や愛称、特徴、コマーシャルで起用されているタレント名などが挙げられる。
また、ジャンルを選択できる。この例では、スポーツなどの大分類と、ランニングなどの小分類で選択できる例を示したが、階層の数や内容は問わない。
さらに、検索にあたっての新品、中古品、新モデル、旧モデルなどの区分も指定可能とした。
商品の写真がある場合は、それを提供してもよい。
また、商品を紹介した記事などを知っている場合には、そのＵＲＬなどを入力してもよい。
これらの条件は、全てを入力する必要はなく、一部のみを入力してもよい。また、項目についても、全てを設ける必要はなく一部を設けるようにしてもよい。
処理を開始すると、物品管理システムは、商品の検索条件の指定を受け付ける（ステップＳ３０）。図中に検索条件を指定する画面例を示した。
この画面では、検索するための対象エリアを、地域で指定するようになっている。
また、商品については、キーワードを入力できる。例えば、商品の略称や愛称、特徴、コマーシャルで起用されているタレント名などが挙げられる。
また、ジャンルを選択できる。この例では、スポーツなどの大分類と、ランニングなどの小分類で選択できる例を示したが、階層の数や内容は問わない。
さらに、検索にあたっての新品、中古品、新モデル、旧モデルなどの区分も指定可能とした。
商品の写真がある場合は、それを提供してもよい。
また、商品を紹介した記事などを知っている場合には、そのＵＲＬなどを入力してもよい。
これらの条件は、全てを入力する必要はなく、一部のみを入力してもよい。また、項目についても、全てを設ける必要はなく一部を設けるようにしてもよい。
【0053】
こうして指定された検索条件のうち、写真およびＵＲＬは、そのままでは検索に適さないため、物品管理システムは、これに基づいて検索条件を設定する（ステップＳ３１）。
例えば、写真については画像検索で、該当する商品を探し出し、その名称等を特定する。
ＵＲＬについては、指定された記事を解析し、商品名などを特定する。
例えば、写真については画像検索で、該当する商品を探し出し、その名称等を特定する。
ＵＲＬについては、指定された記事を解析し、商品名などを特定する。
【0054】
こうして検索条件が指定されると、物品管理システムは、マスタデータベースおよびオリジナルデータベースを検索する（ステップＳ３２）。指定された検索条件によって商品共通コードが特定される場合には、マスタデータからそれに対応するレコードを検索すればよい。ただし、オリジナルデータベースにおいて、共通コードに枝番を付す形で商品非共通コードが設定されている場合には、オリジナルデータベースも検索対象となる。
また、商品共通コード、商品非共通コードのいずれも特定できない場合において、これらのコードが階層的に用意されている場合には、指定された検索条件に従って、上位階層のコードに該当するレコードを検索する。
また、商品共通コード、商品非共通コードのいずれも特定できない場合において、これらのコードが階層的に用意されている場合には、指定された検索条件に従って、上位階層のコードに該当するレコードを検索する。
【0055】
こうしてレコードの検索ができると、物品管理システムは、検索結果に対して、店舗の共通コードを割り当てて集計し、検索条件の適合度に応じてソートする（ステップＳ３３）。上述の通り、商品共通コード、商品非共通コードで検索対象が特定されているものは優先度を高くし、上位階層での検索結果は優先度を低くするなどのソートが考えられる。
結果が得られると、物品管理システムは、結果を出力および保存して（ステップＳ３４）、商品在庫検索処理を終了する。
結果が得られると、物品管理システムは、結果を出力および保存して（ステップＳ３４）、商品在庫検索処理を終了する。
【0056】
以上で説明した変形例（１）の商品在庫検索処理によれば、オリジナルデータベースを活用することにより、商品を新品、中古品などの細分化した区分で検索可能となり、物品管理システムの利便性を一層、向上させることができる。
【0057】
Ｅ．変形例としての商品在庫検索処理（２）：
図９は、変形例（２）の商品在庫検索処理のフローチャートである。複数の商品在庫の検索を行う例を示した。
図９は、変形例（２）の商品在庫検索処理のフローチャートである。複数の商品在庫の検索を行う例を示した。
【0058】
処理を開始すると物品管理システムは、対象となる複数の商品の指定を受け付け（ステップＳ４０）、検索対象領域の指定を受け付ける（ステップＳ４１）。これらの処理は、商品が複数になっている点を除けば、商品在庫検索処理（図３）と同じである。
【0059】
そして、物品管理システムは、管理主体に商品在庫を問い合わせ（ステップＳ４２）、その回答に対して店舗の共通コードを割り当てて集計する（ステップＳ４３）。これらの処理も、商品在庫検索処理（図３）と同じである。ただし、この変形例では、対象となる商品が複数存在するため、全ての商品について同様の処理を繰り返し実行する（ステップＳ４４）。
【0060】
商品在庫情報が得られると、物品管理システムは、結果のソートを行って（ステップＳ４５）、その結果を出力および保存して（ステップＳ４６）、商品在庫検索処理を終了する。
【0061】
図１０は、集計結果のソート例を示す説明図である。商品Ｐ１、Ｐ２、Ｐ３の３つを対象として検索を行った場合を例示した。
左側には、ソート前の検索結果を示している。管理主体としての小売業者Ａ社のａ１店、ａ２店、Ｂ社のｂ１店の結果が示されている。各店舗に対し、商品ごとに、在庫数、価格および店舗までの距離が示されている。
左側には、ソート前の検索結果を示している。管理主体としての小売業者Ａ社のａ１店、ａ２店、Ｂ社のｂ１店の結果が示されている。各店舗に対し、商品ごとに、在庫数、価格および店舗までの距離が示されている。
【0062】
結果のソートは種々の条件で行うことができる。この例では、
（条件１）一つの店舗で、指定した全ての商品が購入できること
（条件２）購入した場合の価格が安いこと
の優先度で２つの条件に基づいてソートした場合を例示している。
Ａ社のａ１店は、商品Ｐ２について在庫が無しとなっているので、条件１を満たさない。
次に、Ａ社のａ２店では、商品Ｐ１、Ｐ２、Ｐ３を購入すると、代金が２２００円となる。これに対し、Ｂ社のｂ１店では、代金が２１４０円となり、ａ２店よりも安くなる。従って、条件２により、ｂ１店の方が上位となる。こうして得られた結果を図１０の右側に示した。
（条件１）一つの店舗で、指定した全ての商品が購入できること
（条件２）購入した場合の価格が安いこと
の優先度で２つの条件に基づいてソートした場合を例示している。
Ａ社のａ１店は、商品Ｐ２について在庫が無しとなっているので、条件１を満たさない。
次に、Ａ社のａ２店では、商品Ｐ１、Ｐ２、Ｐ３を購入すると、代金が２２００円となる。これに対し、Ｂ社のｂ１店では、代金が２１４０円となり、ａ２店よりも安くなる。従って、条件２により、ｂ１店の方が上位となる。こうして得られた結果を図１０の右側に示した。
【0063】
このように複数の商品を対象とすることにより、一層、利便性を向上させることができる。また、ソートして結果を表示することにより、さらに利便性を向上させることが可能となる。
【0064】
ソート条件は、任意に決めることができる。店舗までの距離を条件に入れてもよい。また、在庫数が多い店舗を優先するようにしてもよい。
上述の例では、条件１、条件２のように優先順位を設けたが、例えば、条件１、条件２について、それぞれポイントを付与し、両者の総和によってソートするようにすれば、複数の条件を並列で総合的に評価したソート結果を得ることが可能となる。
上述の例では、条件１、条件２のように優先順位を設けたが、例えば、条件１、条件２について、それぞれポイントを付与し、両者の総和によってソートするようにすれば、複数の条件を並列で総合的に評価したソート結果を得ることが可能となる。
【0065】
Ｆ．アフィリエイト処理：
物品管理システムは、広告などを提供するシステムと連動してアフィリエイトを実現してもよい。広告は、典型的には、商品や店舗のバナー広告であるが、在庫数など本システムが提供する情報全てが対象となる。そして、情報を見た消費者が、実際に店舗に行ったなどの条件が整った時に、メリットを受けた所定の管理主体等に対して広告料を請求するのである。
図１１は、アフィリエイト処理のフローチャートである。主としてアフィリエイト処理部（図１参照）が実行する処理であり、ハードウェア的にはサーバ１００が実行する処理である。
物品管理システムは、広告などを提供するシステムと連動してアフィリエイトを実現してもよい。広告は、典型的には、商品や店舗のバナー広告であるが、在庫数など本システムが提供する情報全てが対象となる。そして、情報を見た消費者が、実際に店舗に行ったなどの条件が整った時に、メリットを受けた所定の管理主体等に対して広告料を請求するのである。
図１１は、アフィリエイト処理のフローチャートである。主としてアフィリエイト処理部（図１参照）が実行する処理であり、ハードウェア的にはサーバ１００が実行する処理である。
【0066】
処理を開始すると、物品管理システムは、ユーザの端末２０に表示された商品のバナー等の広告のクリックを検出する（ステップＳ５０）。例えば、端末２０にインストールされたサービス用アプリ２１がクリックを検出し、その情報を物品管理システムに送信するようにすればよい。
そして、物品管理システムは、クリックされたバナーの商品情報を検索対象の指定と捉えて商品在庫検索処理を実行する（ステップＳ５１）。この処理は、図３、８、９などで説明した処理と同様でよい。
そして、物品管理システムは、クリックされたバナーの商品情報を検索対象の指定と捉えて商品在庫検索処理を実行する（ステップＳ５１）。この処理は、図３、８、９などで説明した処理と同様でよい。
【0067】
在庫情報を提供すると、物品管理システムは、その後のユーザの位置情報を取得する（ステップＳ５２）。端末２０の位置情報を、サービス用アプリ２１が逐次、物品管理システムに送信するようにすればよい。
位置情報の取得は、商品在庫検索処理で提供した店舗に、ユーザが入店したことが確認できるまで（ステップＳ５３）、または終了条件が成立するまで（ステップＳ５４）、繰り返し実行する。
そして、ユーザの入店が確認できた場合には、物品管理システムは、バナーを提供している広告システムに対して、ユーザの入店通知を送信する（ステップＳ５４）。その後、メリットを受けた所定の管理主体等に対して広告料を請求する。
終了条件としては（ステップＳ５４）、ユーザがいずれの店舗にも入店しなかった場合、即ち、在庫情報の提供後の時間経過が所定値を超えた場合や、在庫情報を提供したいずれの店舗からも所定の距離以上離れてしまった場合などが挙げられる。
位置情報の取得は、商品在庫検索処理で提供した店舗に、ユーザが入店したことが確認できるまで（ステップＳ５３）、または終了条件が成立するまで（ステップＳ５４）、繰り返し実行する。
そして、ユーザの入店が確認できた場合には、物品管理システムは、バナーを提供している広告システムに対して、ユーザの入店通知を送信する（ステップＳ５４）。その後、メリットを受けた所定の管理主体等に対して広告料を請求する。
終了条件としては（ステップＳ５４）、ユーザがいずれの店舗にも入店しなかった場合、即ち、在庫情報の提供後の時間経過が所定値を超えた場合や、在庫情報を提供したいずれの店舗からも所定の距離以上離れてしまった場合などが挙げられる。
【0068】
処理によれば、インターネット上などで実現されているアフィリエイトと同様の処理を、実存する店舗を対象として行うことが可能となり、本システムの有用性が高まる。
なお、バナー等の広告は、ユーザの過去の商品在庫検索結果に応じて、ユーザの興味・関心に合致するものを表示させてもよい。また、ユーザの現在や過去の位置情報に応じて、ユーザの現在地周辺や自宅周辺の店舗、通勤や通学ルート沿いなどの店舗の広告を表示させてもよい。
なお、バナー等の広告は、ユーザの過去の商品在庫検索結果に応じて、ユーザの興味・関心に合致するものを表示させてもよい。また、ユーザの現在や過去の位置情報に応じて、ユーザの現在地周辺や自宅周辺の店舗、通勤や通学ルート沿いなどの店舗の広告を表示させてもよい。
【0069】
Ｇ．時系列変化出力処理：
図１２は、時系列変化出力処理のフローチャートである。過去の商品在庫検索結果を利用して、時系列変化を出力する処理である。主として集計部（図１参照）が実行する処理であり、ハードウェア的にはサーバ１００が実行する処理である。
図１２は、時系列変化出力処理のフローチャートである。過去の商品在庫検索結果を利用して、時系列変化を出力する処理である。主として集計部（図１参照）が実行する処理であり、ハードウェア的にはサーバ１００が実行する処理である。
【0070】
処理を開始すると、物品管理システムは、対象商品の指定を受け付ける（ステップＳ６０）。そして、指定された商品について、過去の集計結果を読み込む（ステップＳ６１）。
【0071】
過去の集計結果は、それぞれの日時における各店舗の在庫数が記録されているデータである。従って、物品管理システムは、過去の集計結果の差分を算出することにより、時間ごとの販売量を算出することができる（ステップＳ６２）。
ただし、商品の仕入れが行われた場合には在庫数が増えることがある。過去における仕入れ数の情報も保管されている場合には、これを考慮することで販売量を算出することができる。
一方、仕入れ数の情報が保管されていない場合には、在庫数が増えている時間帯の販売量は無視するものとしてもよい。このように販売量が得られない時間帯が存在したとしても、次の時間帯には、販売によって在庫数が減れば、販売量は得られる。
ただし、商品の仕入れが行われた場合には在庫数が増えることがある。過去における仕入れ数の情報も保管されている場合には、これを考慮することで販売量を算出することができる。
一方、仕入れ数の情報が保管されていない場合には、在庫数が増えている時間帯の販売量は無視するものとしてもよい。このように販売量が得られない時間帯が存在したとしても、次の時間帯には、販売によって在庫数が減れば、販売量は得られる。
【0072】
こうして時間帯ごとの販売量を算出すると、物品管理システムは、結果を出力する（ステップＳ６３）。
図中に出力例を示した。それぞれ店舗ごとの販売量を柱状のグラフで表している。この出力を見れば、午前９時、午後１時に販売量が多い店舗と、午後１０時に販売量が多い店舗が確認でき、対象商品に対する需要が高まる地域が時間帯に応じて変化することが分かる。
図中に出力例を示した。それぞれ店舗ごとの販売量を柱状のグラフで表している。この出力を見れば、午前９時、午後１時に販売量が多い店舗と、午後１０時に販売量が多い店舗が確認でき、対象商品に対する需要が高まる地域が時間帯に応じて変化することが分かる。
【0073】
以上の処理によれば、管理主体が商品の販売戦略等を検討するのに有用な情報を提供することが可能となる。
上述の例では、販売量を表示する例を示したが、単純に在庫量の変化を示すようにしてもよい。時系列のデータを活用して表示するデータは、種々の態様を取ることが可能である。
上述の例では、販売量を表示する例を示したが、単純に在庫量の変化を示すようにしてもよい。時系列のデータを活用して表示するデータは、種々の態様を取ることが可能である。
【0074】
Ｈ．物資配給支援処理：
以上で説明した実施例では、商品を販売する場面を想定して説明した。本実施例は、かかる場合だけでなく、種々の物品管理に活用することが可能である。その一例として、災害の避難所に対する物資の補給に活用した場合を以下、説明する。
この例においては、物品は補給される物資が相当する。また、それぞれの避難所が保管場所に相当する。避難所は自治体によって管理されているから、自治体が管理主体に相当する。
以上で説明した実施例では、商品を販売する場面を想定して説明した。本実施例は、かかる場合だけでなく、種々の物品管理に活用することが可能である。その一例として、災害の避難所に対する物資の補給に活用した場合を以下、説明する。
この例においては、物品は補給される物資が相当する。また、それぞれの避難所が保管場所に相当する。避難所は自治体によって管理されているから、自治体が管理主体に相当する。
【0075】
図１３は、マスタデータベース更新処理のフローチャートである。避難所における物資の在庫状況を適宜、更新するための処理である。
物品管理システムは、処理を開始すると、マスタデータベースを読み込む（ステップＳ７０）。そして、自治体から更新情報を受け取る（ステップＳ７１）。自治体が、避難所の物資の在庫情報を個別に管理する個別システム１０（図１参照）を有しているとは限らないため、この更新情報は、自治体職員が物品管理システムの提供するフォームを利用して入力する方法や、所定のフォーマットのテキストデータ、表データなどを送信する方法などをとってもよい。
物品管理システムは、処理を開始すると、マスタデータベースを読み込む（ステップＳ７０）。そして、自治体から更新情報を受け取る（ステップＳ７１）。自治体が、避難所の物資の在庫情報を個別に管理する個別システム１０（図１参照）を有しているとは限らないため、この更新情報は、自治体職員が物品管理システムの提供するフォームを利用して入力する方法や、所定のフォーマットのテキストデータ、表データなどを送信する方法などをとってもよい。
【0076】
物品管理システムは、更新情報を受け取ると、自治体が管理する複数の避難所を共通コードに置き換える（ステップＳ７２）。この処理は、図４で説明した店舗名を共通コードに置き換える処理と同じである。
【0077】
そして、物品管理システムは、共通コード、物資コードに基づいて対応するレコードを検索する（ステップＳ７３）。ここで物資コードとは、商品共通コードと同じく、複数の自治体にわたって、物資に対して共通に割り当てたコードを意味する。
【0078】
物品管理システムは、レコードが存在する場合には（ステップＳ７４）、そのデータを更新し（ステップＳ７５）、レコードが存在しない場合には（ステップＳ７６）、新規レコードを作成する（ステップＳ７６）。そして、更新したマスタデータを格納する（ステップＳ７７）。
【0079】
図１４は、物資配給支援処理のフローチャートである。避難所に対して必要な物資を偏り無く配給する支援を行うための処理である。
物品管理システムは、物資の検索条件の指定を受け付ける（ステップＳ８０）。例えば、支援物資として食料が自治体に届いたときには、食料を検索対象として指定すればよい。また、特定の物資が不足しているか否かを知りたいときには、その物資を検索対象として指定すればよい。
物品管理システムは、物資の検索条件の指定を受け付ける（ステップＳ８０）。例えば、支援物資として食料が自治体に届いたときには、食料を検索対象として指定すればよい。また、特定の物資が不足しているか否かを知りたいときには、その物資を検索対象として指定すればよい。
【0080】
物品管理システムは、指定された条件に基づいてマスタデータベースを検索し、結果を集計する（ステップＳ８１）。避難所は複数の自治体にわたって特定可能な共通コードが付されているから、ステップＳ８１の処理によって、複数の自治体に管理されている避難所にわたって、指定された物資の在庫数を把握することができる。
【0081】
次に物品管理システムは、各避難所の必要数を算出する（ステップＳ８２）。例えば、各避難所の属性データとして、避難している人数が記憶されていれば、その人数に基づいて必要数を算出することができる。人数の情報が、年齢、性別などに応じて詳細に記憶されている場合には、必要数の算出に、これらの情報を考慮してもよい。例えば、食料については、男性、女性、大人と子供などで必要な量が異なるため、年齢、性別などの情報を考慮することにより、精度良く必要数を求めることができる。また、避難している実際の人数が記憶されていない場合には、各避難所の広さなどに基づき予め定められた収容可能人数を、実際に避難している人数とみなして、必要数を算出してもよい。
【0082】
次に物品管理システムは、配給可能な物資の数、必要数に基づいて各避難所への配給数を決定する（ステップＳ８３）。例えば、検索した時点での在庫が必要数を上回っている避難所については、配給の必要はないと判断される。即ち、必要数－在庫数が必要な配給数と求められる。これを各避難所に対して算出し、配給可能な物資を按分して、各避難所に対する配給数を決めるように決めればよい。
各避難所への配給数を決める際には、種々の優先順位を設けてもよい。例えば、配給可能な物資が届いた自治体が管理する避難所を優先し、余裕がある場合に他の自治体が管理する避難所に配給するようにしてもよい。また、避難者の年齢、性別、高齢者や障碍者などの要配慮者の人数、避難所が福祉避難所であるか否かなどを考慮して優先度を決めてもよい。前回の配給からの経過時間や、避難所までの所要時間などを考慮して優先度を決めてもよい。
各避難所への配給数を決める際には、種々の優先順位を設けてもよい。例えば、配給可能な物資が届いた自治体が管理する避難所を優先し、余裕がある場合に他の自治体が管理する避難所に配給するようにしてもよい。また、避難者の年齢、性別、高齢者や障碍者などの要配慮者の人数、避難所が福祉避難所であるか否かなどを考慮して優先度を決めてもよい。前回の配給からの経過時間や、避難所までの所要時間などを考慮して優先度を決めてもよい。
【0083】
さらに、物品管理システムは、物資が不足していると判断される場合には（ステップＳ８４）、物資要求を出力する（ステップＳ８５）。この出力は、自治体の職員が利用する端末に表示する方法、予め設定されたアドレスに電子メールを送信する方法、被災者への物資の募集をするホームページなどに対して物資要求をアップロードする方法など種々の態様をとることができる。
以上の処理を終えると、物品管理システムは、結果を出力及び保存し（ステップＳ８６）、物資配給支援処理を終了する。
以上の処理を終えると、物品管理システムは、結果を出力及び保存し（ステップＳ８６）、物資配給支援処理を終了する。
【0084】
以上の処理によれば、複数の自治体にわたって、物資の在庫を管理することができ、また在庫に基づいて物資の配給を支援することができる。従って、避難者に必要な物資が偏りなく配給することが可能となる。
なお、避難所の管理主体は自治体に限らず、民間企業や非営利団体、個人の場合でもよい。また、物資を運搬する車両や給水車、トイレカーなどの移動予定の経路や各避難所への到着時刻も併せて表示することで、各避難所では物資の到着に備えて受入体制と各避難者への配給体制を整えておくことができるだけでなく、いつ到着するのかを避難者が把握することもできる。更に、管理主体が民間企業の場合は、自社や関連企業が保有または管理するオフィスや倉庫を避難所とみなして、事業継続計画（ＢＣＰ）の一環として、物品管理システムで自社や関連企業の保有する物資を管理することができる。
また、災害発生時の物資の補給という意味では、自動販売機を物資の供給機とみなすこともできる。例えば、自動販売機の中には、災害発生時に災害モードに切り替わり一般消費者に飲料を無料または安価で提供する機種も存在するため、管理主体が飲料の補充を行う上で有用である。
なお、避難所の管理主体は自治体に限らず、民間企業や非営利団体、個人の場合でもよい。また、物資を運搬する車両や給水車、トイレカーなどの移動予定の経路や各避難所への到着時刻も併せて表示することで、各避難所では物資の到着に備えて受入体制と各避難者への配給体制を整えておくことができるだけでなく、いつ到着するのかを避難者が把握することもできる。更に、管理主体が民間企業の場合は、自社や関連企業が保有または管理するオフィスや倉庫を避難所とみなして、事業継続計画（ＢＣＰ）の一環として、物品管理システムで自社や関連企業の保有する物資を管理することができる。
また、災害発生時の物資の補給という意味では、自動販売機を物資の供給機とみなすこともできる。例えば、自動販売機の中には、災害発生時に災害モードに切り替わり一般消費者に飲料を無料または安価で提供する機種も存在するため、管理主体が飲料の補充を行う上で有用である。
【0085】
Ｉ．効果及び変形例：
以上で説明した本実施例の物品管理システムによれば、複数の管理主体にわたって商品、物資などの物品の在庫を管理することが可能となる利点がある。こうして管理された情報は、物品の需要者に対して容易に物品を入手できる情報を提供するために活用できる。また、物品の生産計画などに活用することもできる。また、災害時には物資の配給支援などにも活用することができる。
以上で説明した本実施例の物品管理システムによれば、複数の管理主体にわたって商品、物資などの物品の在庫を管理することが可能となる利点がある。こうして管理された情報は、物品の需要者に対して容易に物品を入手できる情報を提供するために活用できる。また、物品の生産計画などに活用することもできる。また、災害時には物資の配給支援などにも活用することができる。
【0086】
実施例で説明した種々の特徴は、必ずしも全てを備えている必要はなく、適宜、その一部を省略したり組み合わせたりすることが可能である。また、本発明は実施例に限らず以下に説明する通り種々の変形例を構成することが可能である。
【0087】
本発明は、先に述べた通り、
複数の管理主体が管理している物品を、統合的に管理するための物品管理システムであって、
それぞれの前記管理主体が前記物品を保管する保管場所を表す前記管理主体固有の情報に、前記複数の管理主体の保管場所を一義的に表す保管場所の共通コードを対応づけるための共通コードデータベースと、
特定の物品について、前記共通コードで特定される前記保管場所ごとの数量を集計する集計部とを備える物品管理システムと構成できるが、これに対して種々の変形例を構成することができる。
複数の管理主体が管理している物品を、統合的に管理するための物品管理システムであって、
それぞれの前記管理主体が前記物品を保管する保管場所を表す前記管理主体固有の情報に、前記複数の管理主体の保管場所を一義的に表す保管場所の共通コードを対応づけるための共通コードデータベースと、
特定の物品について、前記共通コードで特定される前記保管場所ごとの数量を集計する集計部とを備える物品管理システムと構成できるが、これに対して種々の変形例を構成することができる。
【0088】
管理対象となる物品としては、製造、販売、賃貸借など種々の取引の対象となる商品、製品などの動産が挙げられる。
前記保管場所とは、物品を保管する場所である。保管場所としては、例えば、店舗、自動販売機などの無人店舗、屋台などの移動店舗、倉庫、工場、配送センター、避難所などが挙げられる。
前記管理主体とは、物品を保管場所で保管する法人または自然人である。管理主体としては、例えば、複数の店舗を直接経営したり、フランチャイズ契約に基づいて経営する会社などが挙げられる。
集計する数量としては、保管場所で保管される物品の保管数量のほか、保管場所に仕入れた物品の仕入数量、保管場所で販売される物品の販売数量、保管場所で消費される物品の消費数量、保管場所で要求のある物品の需要数量、保管場所で備蓄される物品の備蓄数量等が挙げられる。
なお、物品を特定する方法としては、管理主体を問わず物品自体に固有に付された共通の物品コードを用いるようにしてもよい。こうすることで物品を容易に誤りなく特定することが可能となり、集計の精度向上を図ることもできる。かかる物品コードを用いる他、製造メーカー、種別、名称などの組み合わせを用いて特定するようにしてもよい。
前記保管場所とは、物品を保管する場所である。保管場所としては、例えば、店舗、自動販売機などの無人店舗、屋台などの移動店舗、倉庫、工場、配送センター、避難所などが挙げられる。
前記管理主体とは、物品を保管場所で保管する法人または自然人である。管理主体としては、例えば、複数の店舗を直接経営したり、フランチャイズ契約に基づいて経営する会社などが挙げられる。
集計する数量としては、保管場所で保管される物品の保管数量のほか、保管場所に仕入れた物品の仕入数量、保管場所で販売される物品の販売数量、保管場所で消費される物品の消費数量、保管場所で要求のある物品の需要数量、保管場所で備蓄される物品の備蓄数量等が挙げられる。
なお、物品を特定する方法としては、管理主体を問わず物品自体に固有に付された共通の物品コードを用いるようにしてもよい。こうすることで物品を容易に誤りなく特定することが可能となり、集計の精度向上を図ることもできる。かかる物品コードを用いる他、製造メーカー、種別、名称などの組み合わせを用いて特定するようにしてもよい。
【0089】
本発明は、上述の態様において、
前記物品を管理するために前記管理主体が運用する個別システムと接続され、
利用者から物品の指定を受け付ける入出力部を有し、
前記集計部は、指定された物品の数量を、前記管理主体およびその保管場所ごとに前記個別システムから取得するものとしてもよい。
前記物品を管理するために前記管理主体が運用する個別システムと接続され、
利用者から物品の指定を受け付ける入出力部を有し、
前記集計部は、指定された物品の数量を、前記管理主体およびその保管場所ごとに前記個別システムから取得するものとしてもよい。
【0090】
こうすることにより、最新の情報を取得することができ、集計の精度向上を図ることができる。また、本発明では、共通コードが設定されているため、複数の管理主体の保管場所ごとの情報を容易に混乱なく管理することができる利点がある。
【0091】
前記態様において、
前記集計部は、管理主体に対して、保管場所を絞り込んで情報を得るものとしてもよい。
前記集計部は、管理主体に対して、保管場所を絞り込んで情報を得るものとしてもよい。
【0092】
例えば、利用者は、自身がいる場所の周囲の情報を知りたいというように、全ての保管場所について情報を得る必要はない場面が考えられる。上記態様によれば、かかる場合に必要な情報のみを得ることができ、集計に要する負荷および処理時間、通信量などを抑制することができる。
集計する保管場所の絞り込みは、種々の条件で行うことができる。例えば、指定した位置の周辺領域という条件による絞り込み、市町村名などによる絞り込み、コンビニエンスストアなど業種による絞り込み、営業時間による絞り込み、駐車場の有無などの属性による絞り込みなどが挙げられる。
集計する保管場所の絞り込みは、種々の条件で行うことができる。例えば、指定した位置の周辺領域という条件による絞り込み、市町村名などによる絞り込み、コンビニエンスストアなど業種による絞り込み、営業時間による絞り込み、駐車場の有無などの属性による絞り込みなどが挙げられる。
【0093】
上述したいずれの態様においても、
前記保管場所ごとの前記物品の数量を記憶したマスタデータベースを備え、
前記集計部は、前記マスタデータベースを参照して集計するものとしてもよい。
前記保管場所ごとの前記物品の数量を記憶したマスタデータベースを備え、
前記集計部は、前記マスタデータベースを参照して集計するものとしてもよい。
【0094】
こうすることにより、管理主体と通信等をしなくても集計可能となり、例えば、管理主体のシステムの稼働状態に関わらず集計できるなどの利点がある。
なお、上記態様において、マスタデータベースは種々のタイミングで更新することが好ましい。かかる更新は、例えば、定期的に行ってもよいし、管理主体から集計の指示を受けたときなど、所定のイベントの発生をトリガとして更新するようにしてもよい。
また、管理主体からマスタデータベースを更新するための情報の提供を受ける場合、その情報の量や頻度が低い場合には、当該管理主体に本発明のシステムから提供する情報を抑制するなどの仕組みを組み込むことで、情報の提供を促すようにしてもよい。
なお、上記態様において、マスタデータベースは種々のタイミングで更新することが好ましい。かかる更新は、例えば、定期的に行ってもよいし、管理主体から集計の指示を受けたときなど、所定のイベントの発生をトリガとして更新するようにしてもよい。
また、管理主体からマスタデータベースを更新するための情報の提供を受ける場合、その情報の量や頻度が低い場合には、当該管理主体に本発明のシステムから提供する情報を抑制するなどの仕組みを組み込むことで、情報の提供を促すようにしてもよい。
【0095】
本発明では、先に説明した通り、管理主体を問わず物品自体に固有に付された共通の物品コードを用いることが好ましいが、
かかるコードに加えて、管理主体に固有の物品コードを用いることを許容してもよい。
固有の物品コードとしては、管理主体で共通して利用する物品コードとは異なる物品コードを使用する場合や、共通して利用する物品コードに、枝番などを付す場合などが考えられる。
こうすることにより、共通の物品コードの対象となっていない商品を、本システムの管理対象としたり、共通の物品コードで表される物品を、新品／中古などのように細分化して管理対象とすることができる。
かかるコードに加えて、管理主体に固有の物品コードを用いることを許容してもよい。
固有の物品コードとしては、管理主体で共通して利用する物品コードとは異なる物品コードを使用する場合や、共通して利用する物品コードに、枝番などを付す場合などが考えられる。
こうすることにより、共通の物品コードの対象となっていない商品を、本システムの管理対象としたり、共通の物品コードで表される物品を、新品／中古などのように細分化して管理対象とすることができる。
【0096】
また、共通の物品コードは、物品の種別を表す上位階層のコード、具体的な物品名を表す下位階層のコードのように階層構造で定義しておき、
管理主体に固有の物品コードは、共通の物品コードにおけるいずれかの上位階層のコードと関連づけるものとしてもよい。
こうすることにより、上位階層においては管理主体を問わない共通の集計対象としつつ、下位階層では管理主体に固有の集計を行うなど多様な集計を実現することが可能となる。
管理主体に固有の物品コードは、共通の物品コードにおけるいずれかの上位階層のコードと関連づけるものとしてもよい。
こうすることにより、上位階層においては管理主体を問わない共通の集計対象としつつ、下位階層では管理主体に固有の集計を行うなど多様な集計を実現することが可能となる。
【0097】
本発明においては、上述のいずれの態様においても、
前記集計の結果を出力する出力部を備えるものとしてもよい。
こうすることにより、集計結果を有用に利用することができる。出力方法としては、例えば、保管場所ごとに物品の数量をリスト形式等で出力してもよいし、保管場所を地図に表示等した上で、それぞれの保管場所ごとに数量を出力するようにしてもよい。
前記集計の結果を出力する出力部を備えるものとしてもよい。
こうすることにより、集計結果を有用に利用することができる。出力方法としては、例えば、保管場所ごとに物品の数量をリスト形式等で出力してもよいし、保管場所を地図に表示等した上で、それぞれの保管場所ごとに数量を出力するようにしてもよい。
【0098】
かかる出力においては、保管場所の属性情報を併せて出力してもよい。
属性情報としては、営業時間、利用者による評価、現在位置からの所要時間、利用可能な決済サービスなど種々の情報が挙げられる。これらの情報を提供することにより利便性を向上させることができる。
属性情報としては、営業時間、利用者による評価、現在位置からの所要時間、利用可能な決済サービスなど種々の情報が挙げられる。これらの情報を提供することにより利便性を向上させることができる。
【0099】
さらに、本発明においては、
前記集計部は、特定の物品に対する需要を併せて集計するようにしてもよい。
前記集計部は、特定の物品に対する需要を併せて集計するようにしてもよい。
【0100】
需要は、種々の方法で収益可能である。例えば、特定の物品の閲覧数や指示数、在庫数の変化、必要としている施設の収容人数などから集計してもよい。
【0101】
本発明においては、
前記集計部は、過去の集計結果を保持しておき、
前記出力部は、集計結果の時系列変化を出力してもよい。
こうすることで在庫の時系列変化を把握することができ、需要予測などに有効活用することができる。
前記集計部は、過去の集計結果を保持しておき、
前記出力部は、集計結果の時系列変化を出力してもよい。
こうすることで在庫の時系列変化を把握することができ、需要予測などに有効活用することができる。
【0102】
本発明においては、
前記出力部は、物品の属性情報を併せて出力してもよい。
属性情報としては、物品の価格、サイズ、色、仕様、原材料、アレルギー情報、賞味期限、セールの実施予定など種々の情報を用いることができる。こうすることで利用者に対して有用な情報を提供することができ、利便性を向上させることができる。
前記出力部は、物品の属性情報を併せて出力してもよい。
属性情報としては、物品の価格、サイズ、色、仕様、原材料、アレルギー情報、賞味期限、セールの実施予定など種々の情報を用いることができる。こうすることで利用者に対して有用な情報を提供することができ、利便性を向上させることができる。
【0103】
本発明においては、
前記保管場所は、移動可能な施設であり、
前記出力部は、保管場所の移動についての情報も併せて出力してもよい。
移動可能な保管場所は、例えば、移動可能な弁当屋、屋台、移動可能な商店などが挙げられる。また、移動情報とは、移動予定の経路や到着時刻などが挙げられる。
上記態様によれば、物品の購入等に、移動情報を有効活用することができる。
前記保管場所は、移動可能な施設であり、
前記出力部は、保管場所の移動についての情報も併せて出力してもよい。
移動可能な保管場所は、例えば、移動可能な弁当屋、屋台、移動可能な商店などが挙げられる。また、移動情報とは、移動予定の経路や到着時刻などが挙げられる。
上記態様によれば、物品の購入等に、移動情報を有効活用することができる。
【0104】
本発明においては、
出力部が集計結果を出力した後、それを閲覧した利用者の行動を取得する可能としてもよい。
こうすることにより、出力した情報の有用性を評価することができる。行動の取得は、位置情報を利用してもよいし、それぞれの保管場所で利用される決済サービスなどを通じて取得してもよい。
この場合において、利用者の行動により、出力されたいずれかの保管場所を利用（例えば、店舗に入店）したと判断される場合には、管理主体が本システム等の運用者に対して所定の特典（例えば、店舗の広告料）を与えるなどの態様をとってもよい。
また、この場合において、利用者が次回以降に本システムを利用し集計結果を出力するときには、以前に利用したことがある保管場所が上位になるように集計結果の順序を入れ替えて表示させてもよいし、集計結果のうち以前に利用したことがある保管場所を強調して表示させてもよい。
出力部が集計結果を出力した後、それを閲覧した利用者の行動を取得する可能としてもよい。
こうすることにより、出力した情報の有用性を評価することができる。行動の取得は、位置情報を利用してもよいし、それぞれの保管場所で利用される決済サービスなどを通じて取得してもよい。
この場合において、利用者の行動により、出力されたいずれかの保管場所を利用（例えば、店舗に入店）したと判断される場合には、管理主体が本システム等の運用者に対して所定の特典（例えば、店舗の広告料）を与えるなどの態様をとってもよい。
また、この場合において、利用者が次回以降に本システムを利用し集計結果を出力するときには、以前に利用したことがある保管場所が上位になるように集計結果の順序を入れ替えて表示させてもよいし、集計結果のうち以前に利用したことがある保管場所を強調して表示させてもよい。
【0105】
以上の実施形態の全部又は一部に記載された態様は、用地データ、地図データまたは地物データの適切な処理、処理速度の向上、処理精度の向上、使い勝手の向上、データを利用した機能の向上又は適切な機能の提供その他の機能向上または適切な機能の提供、データ及び／又はプログラムの容量の削減、装置及び／又はシステムの小型化等の適切なデータ、プログラム、記録媒体、装置及び／又はシステムの提供、並びにデータ、プログラム、装置又はシステムの制作・製造コストの削減、制作・製造の容易化、制作・製造時間の短縮等のデータ、プログラム、記録媒体、装置及び／又はシステムの制作・製造の適切化のいずれか一つの課題を解決する。
【符号の説明】
【0106】
１ サーバ
１０ 個別システム
１１ 入出力部
１２ 報告部
１３ データベース管理部
１４ 商品データベース
１５ 店舗データベース
２０ 端末
２１ サービス用アプリ
１００ サーバ
１０１ ユーザデータベース
１０２ マスタデータベース
１０３ オリジナルデータベース
１０４ 共通コードデータベース
１０５ 地図データベース
１１０ データベース管理部
１２０ 入出力部
１３０ 集計部
１４０ アフィリエイト処理部
１５０ 表示制御部
１０ 個別システム
１１ 入出力部
１２ 報告部
１３ データベース管理部
１４ 商品データベース
１５ 店舗データベース
２０ 端末
２１ サービス用アプリ
１００ サーバ
１０１ ユーザデータベース
１０２ マスタデータベース
１０３ オリジナルデータベース
１０４ 共通コードデータベース
１０５ 地図データベース
１１０ データベース管理部
１２０ 入出力部
１３０ 集計部
１４０ アフィリエイト処理部
１５０ 表示制御部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】