特許 7548182 情報処理装置および情報処理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-02

(45)【発行日】2024-09-10

(54)【発明の名称】情報処理装置および情報処理方法

(51)【国際特許分類】

   G06Q 30/06 20230101AFI20240903BHJP

   G06Q 30/018 20230101ALI20240903BHJP

【ＦＩ】

G06Q30/06

G06Q30/018 342

【請求項の数】 16

(21)【出願番号】P 2021165555

(22)【出願日】2021-10-07

(65)【公開番号】P2023056285

(43)【公開日】2023-04-19

【審査請求日】2023-07-11

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】110002860

【氏名又は名称】弁理士法人秀和特許事務所

(72)【発明者】

【氏名】長坂 修

(72)【発明者】

【氏名】大塩 典彦

(72)【発明者】

【氏名】榊原 孝典

(72)【発明者】

【氏名】岡 尚哉

【審査官】大野 朋也

(56)【参考文献】

【文献】特開２００２－０４０９４３（ＪＰ，Ａ）

【文献】特開２００３－３４６０１０（ＪＰ，Ａ）

【文献】特開２００８－２０４１３０（ＪＰ，Ａ）

【文献】特開２０２１－１３１７４３（ＪＰ，Ａ）

【文献】特開２００５－２０９１８０（ＪＰ，Ａ）

【文献】韓国登録特許第１０－２２１７６８４（ＫＲ，Ｂ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

車両部品を含む商品の発注の受け付けを行う情報処理装置であって、
少なくとも、複数の車両の各々を識別する識別子、前記識別子ごとに関連付けられている、前記複数の車両の各々に適合する複数の商品の各々を識別する品番、および前記品番ごとに関連付けられている、少なくとも前記複数の商品の各々にかかる発注制限の有無を示す発注制限情報を含むパーツリストと、過去の商品の発注の履歴が記憶された発注履歴であって、少なくとも、発注された商品が使用される車両を識別する識別子、および前記発注履歴の前記識別子ごとに関連付けられている、前記発注された商品を識別する品番を含む発注履歴とが記憶された記憶部と、
ユーザによって指定された対象車両の識別子を取得することと、
前記パーツリストから、少なくとも前記対象車両の識別子と同一の前記パーツリストの前記識別子に対応する前記パーツリストの前記品番を含む商品の一覧を取得することと、
前記発注制限情報に基づいて、前記商品の一覧に含まれている複数の商品であって、前記対象車両の識別子と同一の前記パーツリストの前記識別子に対応する前記パーツリストの前記品番によって識別される複数の商品の各々について、発注制限がかかっているか否かを判定することと、
前記商品の一覧に含まれている前記複数の商品の少なくとも１つに発注制限がかかっている場合に、発注制限がかかっている商品の各々について、前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の品番と同一の品番が前記発注履歴にあるか否かを判定することと、
前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の品番と同一の品番が前記発注履歴にある場合に、前記発注制限がかかっている商品の１つである、所定の車両部品がアップグレードされている旨を表示するステッカーを少なくとも含む第一の商品の発注を受け付けないと決定し、前記対象車両の識別子と同一の識別子が前記発注履歴にないと判定した場合、および前記発注制限がかかっていると判定した商品の品番と同一の品番が前記発注履歴にないと判定した場合のうちの少なくとも一方の場合に、前記第一の商品の発注を受け付けると決定することと、
を実行する制御部と、を有する、
情報処理装置。

【請求項2】

前記第一の商品は、前記ステッカーと、前記所定の車両部品がセットになった商品であり、
前記制御部は、前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の１つである、前記第一の商品の品番と同一の品番が前記発注履歴にある場合に、前記第一の商品の発注を受け付けない、
請求項１に記載の情報処理装置。

【請求項3】

前記第一の商品は、前記ステッカーのみからなる商品であり、
前記制御部は、前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の１つである、前記ステッカーと同一のステッカーを含む商品の品番と同一の品番が前記発注履歴にある場合に、前記第一の商品の発注を受け付けない、
請求項１に記載の情報処理装置。

【請求項4】

前記発注履歴は、さらに、前記発注履歴の前記識別子ごとに関連付けられている、車両のオーナーを識別するオーナー識別子を含み、
前記制御部は、
前記対象車両の現在のオーナーのオーナー識別子を取得し、
前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の品番と同一の品番が前記発注履歴にある場合に、さらに前記現在のオーナーのオーナー識別子と同一のオーナー識別子が前記発注履歴にあるか否かを判定する、
請求項２または３に記載の情報処理装置。

【請求項5】

前記制御部は、前記商品の一覧に基づいて、前記対象車両に適合する一以上の前記商品のリストを生成する、
請求項１から４のいずれか１項に記載の情報処理装置。

【請求項6】

前記制御部は、発注を受け付けないと決定した前記商品を除外して前記リストを生成する、
請求項５に記載の情報処理装置。

【請求項7】

前記制御部は、発注を受け付けないと決定した前記商品を選択不可にした前記リストを生成する、
請求項５に記載の情報処理装置。

【請求項8】

車両部品を含む商品の発注の受け付けを行うコンピュータが実行する情報処理方法であって、
前記コンピュータは、少なくとも、複数の車両の各々を識別する識別子、前記識別子ごとに関連付けられている、前記複数の車両の各々に適合する複数の商品の各々を識別する品番、および前記品番ごとに関連付けられている、少なくとも前記複数の商品の各々にかかる発注制限の有無を示す発注制限情報を含むパーツリストと、過去の商品の発注の履歴が記憶された発注履歴であって、少なくとも、発注された商品が使用される車両を識別する識別子、および前記発注履歴の前記識別子ごとに関連付けられている、前記発注された商品を識別する品番を含む発注履歴とが記憶された記憶部を備え、
前記コンピュータは、
ユーザによって指定された対象車両の識別子を取得し、
前記パーツリストから、少なくとも前記対象車両の識別子と同一の前記パーツリストの前記識別子に対応する前記パーツリストの前記品番を含む商品の一覧を取得し、
前記発注制限情報に基づいて、前記商品の一覧に含まれている複数の商品であって、前記対象車両の識別子と同一の前記パーツリストの前記識別子に対応する前記パーツリスト
の前記品番によって識別される複数の商品の各々について、発注制限がかかっているか否かを判定し、
前記商品の一覧に含まれている前記複数の商品の少なくとも１つに発注制限がかかっている場合に、発注制限がかかっている商品の各々について、前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の品番と同一の品番が前記発注履歴にあるか否かを判定し、
前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の品番と同一の品番が前記発注履歴にある場合に、前記発注制限がかかっている商品の１つである、所定の車両部品がアップグレードされている旨を表示するステッカーを少なくとも含む第一の商品の発注を受け付けないと決定し、前記対象車両の識別子と同一の識別子が前記発注履歴にないと判定した場合、および前記発注制限がかかっていると判定した商品の品番と同一の品番が前記発注履歴にないと判定した場合のうちの少なくとも一方の場合に、前記第一の商品の発注を受け付けると決定する、
情報処理方法。

【請求項9】

前記第一の商品は、前記ステッカーと、前記所定の車両部品がセットになった商品であり、
前記コンピュータは、前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の１つである、前記第一の商品の品番と同一の品番が前記発注履歴にある場合に、前記第一の商品の発注を受け付けない、
請求項８に記載の情報処理方法。

【請求項10】

前記第一の商品は、前記ステッカーのみからなる商品であり、
前記コンピュータは、前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の１つである、前記ステッカーと同一のステッカーを含む商品の品番と同一の品番が前記発注履歴にある場合に、前記第一の商品の発注を受け付けない、
請求項８に記載の情報処理方法。

【請求項11】

前記発注履歴は、さらに、前記発注履歴の前記識別子ごとに関連付けられている、車両のオーナーを識別するオーナー識別子を含み、
前記コンピュータは、
前記対象車両の現在のオーナーのオーナー識別子を取得し、
前記対象車両の識別子と同一の識別子が前記発注履歴にあり、かつ前記発注制限がかかっている商品の品番と同一の品番が前記発注履歴にある場合に、さらに前記現在のオーナーのオーナー識別子と同一のオーナー識別子が前記発注履歴にあるか否かを判定する、
請求項８から１０のいずれか１項に記載の情報処理方法。

【請求項12】

前記コンピュータは、前記商品の一覧に基づいて、前記対象車両に適合する一以上の前記商品のリストを生成する、
請求項８から１１のいずれか１項に記載の情報処理方法。

【請求項13】

前記コンピュータは、発注を受け付けないと決定した前記商品を除外して前記リストを生成する、
請求項１２に記載の情報処理方法。

【請求項14】

前記コンピュータは、発注を受け付けないと決定した前記商品を選択不可にした前記リストを生成する、
請求項１２に記載の情報処理方法。

【請求項15】

請求項８から１４のいずれか１項に記載の情報処理方法をコンピュータに実行させるためのプログラム。

【請求項16】

車両部品を含む商品の発注の受け付けを行う情報処理装置であって、
少なくとも、複数の車両の各々を識別する識別子、前記識別子ごとに関連付けられている、前記複数の車両の各々に適合する複数の商品の各々を識別する品番、および前記品番ごとに関連付けられている、少なくとも前記複数の商品の各々にかかる発注制限の有無を示す発注制限情報を含むパーツリストと、過去の商品のアップグレードの履歴が記憶されたアップグレード履歴であって、少なくとも、アップグレードされた商品が使用される車両を識別する識別子、および前記アップグレード履歴の前記識別子ごとに関連付けられている、前記アップグレードされた商品を識別する品番を含むアップグレード履歴とが記憶された記憶部と、
ユーザによって指定された対象車両の識別子を取得することと、
前記パーツリストから、少なくとも前記対象車両の識別子と同一の前記パーツリストの前記識別子に対応する前記パーツリストの前記品番を含む商品の一覧を取得することと、
前記発注制限情報に基づいて、前記商品の一覧に含まれている複数の商品であって、前記対象車両の識別子と同一の前記パーツリストの前記識別子に対応する前記パーツリストの前記品番によって識別される複数の商品の各々について、発注制限がかかっているか否かを判定することと、
前記商品の一覧に含まれている前記複数の商品の少なくとも１つに発注制限がかかっている場合に、発注制限がかかっている商品の各々について、前記対象車両の識別子と同一の識別子が前記アップグレード履歴にあり、かつ前記発注制限がかかっている商品の品番と同一の品番が前記アップグレード履歴にあるか否かを判定することと、
前記対象車両の識別子と同一の識別子が前記アップグレード履歴にあり、かつ前記発注制限がかかっている商品の品番と同一の品番が前記アップグレード履歴にある場合に、前記発注制限がかかっている商品の１つである、所定の車両部品がアップグレードされている旨を表示するステッカーを少なくとも含む第一の商品の発注を受け付けないと決定し、前記対象車両の識別子と同一の識別子が前記アップグレード履歴にないと判定した場合、および前記発注制限がかかっていると判定した商品の品番と同一の品番が前記アップグレード履歴にないと判定した場合のうちの少なくとも一方の場合に、前記第一の商品の発注を受け付けると決定することと、
を実行する制御部と、を有する、
情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、車両部品の発注システムに関する。

【背景技術】

【0002】

中古車の評価は、オプションや装備品などに基づいて変化することが知られている。これに関連して、特許文献１には、中古車として販売される車両の来歴（部品の交換履歴、整備履歴など）をサーバ装置に登録し、消費者に提供するシステムが開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００５－３４６１７０号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

本開示は、車両部品に関連する証明書を適切に管理することを目的とする。

【課題を解決するための手段】

【0005】

本開示の第一の態様は、車両部品を含む商品の発注の受け付けを行う情報処理装置であって、対象車両について、所定の車両部品がアップグレードされている旨を表示するステッカーを少なくとも含む商品の発注履歴に基づいて、前記ステッカーを少なくとも含む第一の商品の発注を受け付けるか否かを決定する制御部を有する、情報処理装置である。

【0006】

また、本開示の第二の態様は、車両部品を含む商品の発注の受け付けを行うコンピュータが実行する情報処理方法であって、対象車両について、所定の車両部品がアップグレードされている旨を表示するステッカーを少なくとも含む商品の発注履歴に基づいて、前記ステッカーを少なくとも含む第一の商品の発注を受け付けるか否かを決定する、情報処理方法である。

【0007】

また、本開示の第三の態様は、車両部品を含む商品の発注の受け付けを行う情報処理装置であって、対象車両について、所定の車両部品のアップグレード履歴に基づいて、前記所定の車両部品がアップグレードされている旨を表示するステッカーを少なくとも含む商品の発注を受け付けるか否かを決定する制御部を有する、情報処理装置である。

【0008】

また、本開示の他の態様は、上記の情報処理方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体である。

【発明の効果】

【0009】

本開示によれば、車両部品に関連する証明書を適切に管理することができる。

【図面の簡単な説明】

【0010】

【図1】発注システムの概要を説明する図。

【図2】車体に貼付されるステッカーの一例を示した図。

【図3】ステッカーを貼付する位置を説明する図。

【図4】車両部品に貼付されるステッカーの一例を示した図。

【図5】車両部品にステッカーを貼付した場合の例を示した斜視図。

【図6】発注管理サーバ２００の構成要素を示した図。

【図7】車両メーカーによって供給される車両部品のタイプを説明する図。

【図8】記憶部に記憶されるパーツリストの例。

【図9】記憶部に記憶される発注履歴データの例。

【図10】ユーザ端末１００のシステム構成を示した図。

【図11】ユーザ端末１００および発注管理サーバ２００が実行する処理を示したシーケンス図。

【図12】検索フォームを含む画面の例。

【図13】ステップＳ１２において実行される処理を説明するフローチャート。

【図14】ステップＳ２４において実行される処理を説明するフローチャート。

【図15】発注が可能である商品のリストを出力する画面の例。

【図16】第二の実施形態で、ステップＳ２４において実行される処理のフローチャート。

【図17】第三の実施形態において供給される車両部品のタイプを説明する図。

【図18】第三の実施形態におけるパーツリストの例。

【図19】第三の実施形態で、ステップＳ２４において実行される処理のフローチャート。

【発明を実施するための形態】

【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】

制御部１０１は、ユーザ端末１００が行う制御を司る演算装置である。制御部１０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することができ
る。
制御部１０１は、発注管理サーバ２００にアクセスして、発注管理サーバ２００とインタラクションを行う機能を実行する。当該機能は、ユーザ端末１００で動作するウェブブラウザや、専用のアプリケーションソフトウェアによって実現されてもよい。

【0052】

記憶部１０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部１０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。補助記憶装置には、制御部１０１で実行されるプログラムをアプリケーションとしてパッケージ化したものを記憶してもよい。また、これらのアプリケーションを実行するためのオペレーティングシステムを記憶してもよい。補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、制御部１０１によって実行されることで、以降に説明する処理が行われる。

【0053】

主記憶装置は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を含んでもよい。また、補助記憶装置は、ＥＰＲＯＭ（Erasable Programmable ROM）やハード
ディスクドライブ（ＨＤＤ、Hard Disk Drive）を含んでもよい。さらに、補助記憶装置
は、リムーバブルメディア、すなわち可搬記録媒体を含んでもよい。

【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】

１００・・・ユーザ端末
１０１，２０１・・・制御部
１０２，２０２・・・記憶部
１０３，２０３・・・通信部
２００・・・発注管理サーバ
１０４・・・入出力部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】