JP2023049691A - 合鍵受注方法およびプログラム - Google Patents

Abstract

【課題】元鍵に対して認証ＩＤや新たな鍵情報を付与してセキュリティを高める合鍵受注システム、合鍵受注方法及び合鍵受注プログラムを提供する。
【解決手段】合鍵受注方法において、管理サーバは、合鍵の注文と共に元鍵の形状を特定する鍵情報を端末から受信し、鍵番号に元鍵を特定するための認証ＩＤを対応付けて格納する段階と、を有する。管理サーバは、元鍵に、鍵情報とは異なる新たな鍵情報を付与する段階をさらに有し、新たな鍵情報と認証ＩＤとを紐づけて格納してもよい。また、合鍵受注プログラムは、管理サーバに、合鍵の注文と共に元鍵の形状を特定する鍵情報を受信する手順と、鍵番号に元鍵を特定するための認証ＩＤを対応付けて格納する手順と、を実行させる。
【選択図】図５

Description

本発明は、合鍵受注方法およびプログラムに関する。

一般客から鍵の複製を受注した鍵複製業者が、元鍵の複製に適するブランクキーを容易に選定できないときに、元鍵を撮影して鍵の表裏両面の画像情報を取得し、その画像情報を探索サービス業者に送ることで、探索サービス業者にブランクキーの探索を依頼するシステムが知られている（例えば、特許文献１を参照）。
［先行技術文献］
［特許文献］
［特許文献１］ 特開２０１６－３１５５５号公報

本発明の第１の態様においては、合鍵受注方法であって、管理サーバが、合鍵の注文と共に元鍵の形状を特定する鍵情報を端末から受信する段階と、管理サーバが、鍵情報に元鍵を特定するための認証ＩＤを対応付けて格納する段階と、を有する。

本発明の第２の態様においては、プログラムであって、管理サーバに、合鍵の注文と共に元鍵の形状を特定する鍵情報を端末から受信する手順と、鍵情報に元鍵を特定するための認証ＩＤを対応付けて格納する手順と、を実行させる。

なお、上記の発明の概要は、本発明の特徴の全てを列挙したものではない。また、これらの特徴群のサブコンビネーションもまた、発明となりうる。

一実施形態による合鍵受注システム１０の概略図である。 管理サーバ１００のブロック図である。 一実施形態による管理サーバ１００のデータベース１０７に格納されるテーブル１０９の一例である。 一実施形態による合鍵受注方法のフロー図である。 画像に基づく発注判断を行う処理（Ｓ２０）の一例である。 図５の発注判断処理Ｓ２００の一例を示す。 一実施形態による、元鍵２５の鍵種類がＩである場合における、元鍵２５の複数の鍵刻みの、それぞれの深さ度合を示す数値の組み合わせを特定する方法を説明するための図である。 一実施形態による、元鍵２５の鍵種類がＩＩである場合における、元鍵２５の数値の組み合わせを特定する方法を説明するための図である。 ステップＳ２０２で管理サーバ１００により付与されて格納される認証ＩＤおよび新鍵番号のテーブル１１１の例である。 認証ＩＤに基づく発注判断を行う処理（Ｓ３０）の一例である。 認証ＩＤを認証カード２９に表示する形態を示す。 認証カード２９に表示された認証ＩＤを読み込んで管理サーバ１００に送信する形態を示す。 本発明の複数の態様が全体的又は部分的に具現化されうるコンピュータ１２００の例を示す。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、一実施形態による合鍵受注システム１０の概略図である。合鍵は、元鍵の形状を特定する鍵情報に基づいて作られることがある。元鍵の鍵情報の一例としての鍵番号は当該元鍵のヘッド部分に刻印されていることがある。この場合に、元鍵の鍵番号が他人に見られてしまうと、当該他人が合鍵を作れてしまうという不具合がある。そこで、この実施形態による合鍵受注システム１０は、元鍵に対して認証ＩＤや新たな鍵情報を付与してセキュリティを高めるものである。

合鍵受注システム１０は、ユーザ２０によって発注される元鍵２５の合鍵作成を受注するか否かを、当該元鍵２５、および、当該元鍵２５に紐づけられた付属品、の少なくとも一方から得られた第１情報に基づいて判定する。合鍵受注システム１０は、管理サーバ１００、合鍵製造装置２００および発注端末３０を備える。管理サーバ１００、合鍵製造装置２００および発注端末３０は、通信ネットワーク５０を介して互いに通信する。通信ネットワーク５０は有線か無線かを問わない。

合鍵受注システム１０は、元鍵２５、および、当該元鍵２５に紐づけられた付属品、の少なくとも一方から発注端末３０によって得られた第１情報と、管理サーバ１００が管理している、鍵の形状に関する第２情報とを照合する。合鍵受注システム１０は、当該照合結果に基づいて、発注端末３０から発注される元鍵２５の合鍵の作成を受注するか否かを判定する。本実施形態の合鍵受注システム１０は、当該第１情報として、元鍵２５の画像を用いる。合鍵受注システム１０は、当該受注の判定に関する何れの処理においても、ユーザ２０の識別情報や、ユーザ２０の本人認証などを用いなくてもよい。ただし、例えばセキュリティ向上を目的として、当該識別情報や認証などを追加的に必要としてもよい。

合鍵受注システム１０はさらに、元鍵２５からの合鍵２７の受注受付時に、元鍵を特定するための認証ＩＤおよび新たな鍵番号である新鍵番号を付与する。なお、元鍵の鍵番号の方を元鍵番号と呼ぶことがある。新たな鍵番号は合鍵２７に刻印され、合鍵２７がユーザ２０に届けられる。

本実施形態において、発注端末３０は、例えばスマートフォンやタブレットなどの通信端末であり、ユーザ２０によって所有される。発注端末３０は、ユーザ２０による操作に応じて、合鍵の作成を管理サーバ１００に発注する。合鍵は元鍵２５から作成される場合と合鍵２７から作成される場合がある。

元鍵２５から合鍵を作成する場合に、発注端末３０は、ユーザ２０の操作によって元鍵２５を撮影し、撮影した元鍵２５の画像を含む第１情報を管理サーバ１００に送信する。本実施形態の発注端末３０は更に、ユーザ２０によって元鍵２５の鍵番号を入力され、入力された鍵番号の鍵番号情報を管理サーバ１００に送信する。発注端末３０は、管理サーバ１００に対して、鍵番号情報を送信した後に第１情報を送信してもよく、その逆であってもよく、鍵番号情報及び第１情報を一緒に送信してもよい。また、発注端末３０は、予めインストールされた合鍵受注システム用のアプリケーションをユーザ２０によって起動された後、当該アプリケーション上で、鍵番号情報の送信、元鍵２５の撮影、および、第１情報の送信の少なくとも何れかを実行してもよい。

合鍵２７から更なる合鍵を作成する場合に、発注端末３０はユーザ２０から入力された新鍵番号と認証ＩＤを管理サーバ１００に送信する。発注端末３０は、予めインストールされた合鍵受注システム用のアプリケーションをユーザ２０によって起動された後、当該アプリケーション上で上記情報の入力および送信を実行してもよい。

本実施形態において、管理サーバ１００は、鍵を複製する業者によって所有される。管理サーバ１００は、発注端末３０から入力された情報に基づいて合鍵の作成を受注するか否かを判断する。受注すると判断した場合に管理サーバ１００は、合鍵製造装置２００に合鍵を製造するための情報を送信する。

合鍵製造装置２００は、ブランクキーがセットされて管理サーバ１００から鍵の形状を特定する情報を受信することにより、元鍵２５に対応した合鍵２７を製造する。合鍵製造装置２００は、合鍵２７の製造時に管理サーバ１００から受信した新鍵番号をヘッド部分に刻印する。なお、合鍵２７からの更なる合鍵作成の場合も、合鍵２７は元鍵２５に対応しているので、更なる合鍵も元鍵２５に対応しているともいえる。

図２は、管理サーバ１００のブロック図である。管理サーバ１００は、通信部１０１と、照合部１０３と、判定部１０５と、データベース１０７とを備える。

通信部１０１は、管理サーバ１００の外部の装置、例えば合鍵製造装置２００及び発注端末３０と相互に通信する。通信部１０１は、照合部１０３および判定部１０５との間で、相互にデータを入出力する。

照合部１０３は、通信部１０１を介して発注端末３０から合鍵の発注を受信した場合に、元鍵２５からの合鍵作成であるか否かを判断する。まず元鍵２５からの合鍵作成である場合を説明し、合鍵２７からの更なる合鍵作成については後述する。

照合部１０３は、発注端末３０で取得された元鍵２５の画像に関する第１情報を通信部１０１から入力される。照合部１０３は、第１情報を入力された後、データベース１０７を参照し、データベース１０７に格納されている第２情報を取得する。より具体的には、照合部１０３は、第１情報と共に鍵番号情報を通信部１０１から入力された場合に、データベース１０７に格納されている複数の第２情報から、当該鍵番号情報に示される鍵番号に対応する第２情報を抽出する。

照合部１０３は、第１情報と第２情報とを照合し、照合結果を判定部１０５に出力する。なお、照合部１０３は、データベース１０７から、第２情報と紐付けられて格納されている鍵種類も抽出してもよい。照合部１０３は更に、データベース１０７に格納されている複数の撮影条件および判定条件を参照し、当該鍵種類に対応する少なくとも１つの撮影条件および判定条件を決定してもよい。照合部１０３は更に、鍵種類に基づいて決定した撮影条件および判定条件を、照合結果と共に判定部１０５に出力してもよい。

判定部１０５は、照合部１０３から照合結果を入力された場合、発注端末３０から発注される元鍵２５の合鍵の作成を受注するか否かを、当該照合結果に基づいて判定する。判定部１０５は、当該合鍵の作成を受注すると判定した場合、通信部１０１を介して発注端末３０にユーザ２０の発注情報を要求してもよい。判定部１０５は、当該合鍵の作成を受注しないと判定した場合、通信部１０１を介して発注端末３０に発注不可情報を送信することで、受注を断ってもよい。

なお、判定部１０５は、照合部１０３から当該照合結果と共に判定条件を入力された場合、当該判定条件を用いて上記受注の可否を判定してもよい。当該判定条件は、照合結果に含まれる第１情報と第２情報との一致度合いに対する閾値を含んでもよい。当該閾値は、データベース１０７に格納され、判定部１０５によって参照されてもよい。

判定部１０５はまた、照合部１０３から当該照合結果と共に撮影条件を入力された場合、当該撮影条件に基づき、通信部１０１を介して発注端末３０に更なる第１情報を要求してもよい。判定部１０５は、当該更なる第１情報として、既に取得している元鍵２５の画像に示される元鍵２５の向きとは異なる向きの元鍵２５の別の画像を要求してもよい。

図３は、一実施形態による管理サーバ１００のデータベース１０７に格納されるテーブル１０９の一例である。テーブル１０９は、５列で構成され、２行目以降に累積データが格納される。テーブル１０９の１行目には、左から順に、「鍵番号」、「鍵種類」、「数値の組み合わせ」、「撮影条件」、「判定条件」といった、各列の項目名が示される。

テーブル１０９の１列目に格納される「鍵番号」は、一例として、１０桁の英数字の組み合わせである。テーブル１０９の２列目に格納される「鍵種類」は、一例として、ＩからＩＶの何れかである。鍵種類Ｉの鍵の一例は、鍵刻み形状が表と裏で対称、すなわち鍵刻み形状が表と裏で同じであって且つ表裏面にディンプルが無い鍵である。鍵種類ＩＩの鍵の一例は、鍵刻み形状が表と裏で同じであって且つ表裏面の少なくとも一方にディンプルが有る鍵である。鍵種類ＩＩＩの鍵の一例は、鍵刻み形状が表と裏で非対称、すなわち鍵刻み形状が表と裏で異なり且つ表裏面にディンプルが無い鍵である。鍵種類ＩＶの鍵の一例は、鍵刻み形状が表と裏で異なり且つ表裏面の少なくとも一方にディンプルが有る鍵である。

テーブル１０９の３列目に格納される「数値の組み合わせ」は、一例として、１８桁の数値、２７桁の数値、３６桁の数値、および、５４桁の数値の何れかである。換言すると、「数値の組み合わせ」として、９桁の数値が、２セット、３セット、４セットまたは６セット格納される。

本実施形態において、鍵の形状に関する第２情報は、鍵の複数の鍵刻みの、それぞれの深さ度合を示す数値の組み合わせを含む。データベース１０７は、複数の第２情報を格納しており、一例として、第２情報は、当該テーブル１０９の３列目に格納される「数値の組み合わせ」を含む。

テーブル１０９の４列目に格納される「撮影条件」の具体例は、第１情報として、鍵の正面画像のみを必要とすることであってもよい。また、当該具体例は、第１情報として、鍵の正面画像と側面画像とを必要とすることであってもよい。また、当該具体例は、第１情報として、鍵の表面画像と裏面画像とを必要とすることであってもよい。当該具体例は、第１情報として、鍵の表面画像と裏面画像と両側面画像とを必要とすることであってもよい。

テーブル１０９の５列目に格納される「判定条件」の具体例は、第１情報と第２情報との一致度合いが０～１で表される場合において、当該一致度合いに対する閾値、例えば０．９、０．８、０．７、０．５などの閾値であってもよい。

テーブル１０９の２行目以降の各行には、「鍵番号」と、「鍵種類」と、「数値の組み合わせ」と、「撮影条件」と、「判定条件」とが互いに紐付けられて格納されている。なお、図示の例では、鍵種類Ｉの場合に、「数値の組み合わせ」が１８桁の数値であり、「撮影条件」が正面画像であり、「判定条件」が閾値０．９である。また、鍵種類ＩＩの場合に、「数値の組み合わせ」が２７桁の数値であり、「撮影条件」が正面画像および側面画像であり、「判定条件」が閾値０．８である。また、鍵種類ＩＩＩの場合に、「数値の組み合わせ」が３６桁の数値であり、「撮影条件」が表面画像および裏面画像であり、「判定条件」が閾値０．７である。また、鍵種類ＩＶの場合に、「数値の組み合わせ」が５４桁の数値であり、「撮影条件」が表面画像、裏面画像および両側面画像であり、「判定条件」が閾値０．５である。以上の通り、鍵番号は元鍵２５の形状を特定する情報となっている。

図４は、一実施形態による合鍵受注方法のフロー図である。当該方法において、発注端末３０からの合鍵作成の発注を管理サーバ１００が受信する（Ｓ１０）。

管理サーバ１００は、当該発注が元鍵２５からの合鍵作成であるか否かを判断する（Ｓ１２）。この場合に、管理サーバ１００の照合部１０３は、発注端末３０から鍵番号を受信し、当該鍵番号がテーブルに格納されている鍵番号と一致する場合に、元鍵２５からの合鍵作成であると判断する。

元鍵２５からの合鍵作成と判断した場合に（Ｓ１２：Ｙｅｓ）、管理サーバ１００は画像に基づく発注判断を行う（Ｓ２０）。一方、元鍵２５からの合鍵作成でないと判断した場合に（Ｓ１２：Ｎｏ）、管理サーバ１００は認証ＩＤに基づく発注判断を行う（Ｓ３０）。元鍵２５からの合鍵作成でない場合の例は、合鍵２７からの更なる合鍵作成である。

図５は、画像に基づく発注判断を行う処理（Ｓ２０）の一例である。当該合鍵受注方法において、ユーザ２０は、発注端末３０を操作することによって、自身が所持している元鍵２５の合鍵の作成を管理サーバ１００に発注する。鍵の複製業者によって所有される管理サーバ１００は、発注端末３０から発注される元鍵２５の合鍵の作成を受注するか否かを判定する。管理サーバ１００は、当該作成を受注すると決定した場合に、管理サーバ１００の所有者に元鍵２５の合鍵の作成を開始させるための通知をしてもよい。

図５に示すフローは、一例として、ユーザ２０が、発注端末３０の合鍵受注システム用のアプリケーションを起動することによって開始されてもよい。ユーザ２０は、発注端末３０のディスプレイに表示されるアプリケーションの操作説明に従って、当該フローで必要とされる、発注端末３０上の各操作を行ってもよい。

発注端末３０は、ユーザ２０に、鍵番号を入力させる（Ｓ１０１）。発注端末３０は、鍵番号が入力された場合、内蔵のカメラを起動して、ユーザ２０に、元鍵２５を撮影させる（Ｓ１０３）。発注端末３０は、元鍵２５の撮影を終えた場合、撮影した元鍵２５の画像を含む第１情報を、ステップ１０１で入力された鍵番号の鍵番号情報と共に管理サーバ１００に送信する（Ｓ１０５）。

本実施形態の発注端末３０は、一例として、鍵番号が入力された時点から、鍵番号情報等を管理サーバ１００に送信する時点までに、時間制限を設けてもよい。時間制限は、例えば数分であってもよい。発注端末３０は更に、当該鍵番号情報と共に管理サーバ１００に送信する第１情報として、当該時間範囲内に撮影した画像のみを許容してもよい。当該判断には、例えばＥＸＩＦ内のタイムスタンプが用いられる。具体的な一例として、発注端末３０は、第１情報に含まれる画像の撮影時間が当該時間範囲外であると判断した場合、当該第１情報を管理サーバ１００に送信することを中止してもよい。

これに代えて、管理サーバ１００が、上記時間範囲内に撮影した画像であるか否かを判断してもよい。具体的には、管理サーバ１００は、発注端末３０から第１情報等を受信した場合に、第１情報等を受信した時点から遡ること一定時間以内に撮影された元鍵２５の画像のみを許容してもよい。

管理サーバ１００は、第１情報および鍵番号情報を発注端末３０から受信した場合、受注判断処理を行う（Ｓ２００）。受注判断処理（Ｓ２００）については後述する。

管理サーバ１００は、受注判断処理Ｓ２００で受注すると判定した場合（Ｓ２００：ＹＥＳ）、発注端末３０から発注される元鍵２５の合鍵２７の作成を受注すると決定する（Ｓ１２７）。さらに管理サーバ１００は、発注端末３０に対して、合鍵２７の注文本数、大型キーヘッドの有無、決済情報などの情報を含む発注情報を要求する（Ｓ１２９）。

発注端末３０は、ユーザ２０に、発注情報を入力させ（Ｓ１３１）、発注情報を管理サーバ１００に送信する（Ｓ１３３）。

管理サーバ１００は発注情報を受信したら、元鍵２５を特定するための認証ＩＤおよび合鍵２７のための新鍵番号を元鍵２５に付与する（Ｓ２０２）。管理サーバ１００は、元鍵番号、認証ＩＤおよび新鍵番号を互いに対応付けてデータベース１０７に格納する。

管理サーバ１００は、合鍵２７を製造するための情報を合鍵製造装置２００に出力する（Ｓ２０４）。当該情報には、新鍵番号および鍵の形状を特定する情報が含まれる。鍵の形状を特定する情報には、図３の「鍵種類」および「数値の組み合わせ」が含まれる。これにより、合鍵製造装置２００は、新鍵番号を刻印した合鍵２７を製造する。

付言すれば、合鍵２７に新鍵番号を刻印することは、新鍵番号を合鍵２７に物理的に表示する一例となっている。刻印に代えて印刷等その他の表示方法であってもよい。また、合鍵２７のヘッド部分にＩＣチップを設けて、新鍵番号を記憶させてもよい。

管理サーバ１００は、さらに、認証ＩＤおよび新鍵番号をデータとして発注端末３０に出力する（Ｓ１５４）。この場合に、管理サーバ１００は認証ＩＤおよび新鍵番号を発注端末３０の表示画面に表示させてもよいし、電子メールの本文に記載またはＰＤＦ等の添付物に記載して発注端末３０に送信してもよい。また、管理サーバ１００は新鍵番号の一部のみを発注端末３０に送信してもよい。これにより当該フローを終了する。

一方、管理サーバ１００は、発注判断処理において発注が不可と判断された場合（Ｓ２００：ＮＯ）、上述した発注不可情報を発注端末３０に送信する（Ｓ１１４）。これにより、当該フローは終了する。

図５のフローは管理サーバ１００などの各装置が動作している間は繰り返し実行される。なお、本フローにおいて、管理サーバ１００は、ステップＳ１２７で受注を決定した後に、発注端末３０に対して発注情報を送信させる構成としたが、当該発注情報は、ステップＳ１０５において第１情報等と共に送信させてもよい。

図６は、図５の発注判断処理Ｓ２００の一例を示す。管理サーバ１００は、第１情報および鍵番号情報を発注端末３０から受信した場合、データベース１０７に格納されている複数の第２情報から、当該鍵番号情報に示される鍵番号に対応する第２情報を抽出する（Ｓ１０７）。ステップＳ１０７において、本実施形態の管理サーバ１００は更に、当該鍵番号に対応する鍵種類も抽出する。

例えば、発注端末３０から受信した鍵番号が「４３２７ＳＨＩＴＥＧ」である場合、管理サーバ１００は、図３に示すテーブルから、鍵種類としてＩを抽出し、第２情報として１８桁の数値の組み合わせ「０３４００２０００ １００２１０３００」を抽出する。また例えば、発注端末３０から受信した鍵番号が「２１８５ＴＥＷＰＯＥ」である場合、管理サーバ１００は、図３に示すテーブルから、鍵種類としてＩＩを抽出し、第２情報として２７桁の数値の組み合わせ「１０３２４００２２ ４１３３２１００２ ０１０２４３２２４」を抽出する。

管理サーバ１００は、当該鍵番号を用いることによって、鍵の鍵刻み形状の対称性および鍵の表裏面におけるディンプルの有無に応じて設定された複数の撮影条件の中から少なくとも１つの撮影条件を決定する（Ｓ１０９）。本実施形態の管理サーバ１００は、ステップＳ１０７で抽出した鍵種類に基づいて１つの撮影条件を決定する。なお、管理サーバ１００は、当該対称性および当該ディンプルの有無の何れか一方のみに応じて設定された複数の撮影条件の中から少なくとも１つの撮影条件を決定してもよい。

ステップＳ１０９において、より具体的には、本実施形態の管理サーバ１００は、図３のテーブルに示すように、鍵種類Ｉの場合には第１情報として元鍵２５の正面画像のみを必要とする。管理サーバ１００は、鍵種類ＩＩの場合には第１情報として元鍵２５の正面画像および側面画像を必要とする。管理サーバ１００は、鍵種類ＩＩＩの場合には第１情報として元鍵２５の表面画像および裏面画像を必要とする。管理サーバ１００は、鍵種類ＩＶの場合には第１情報として元鍵２５の表面画像、裏面画像および両側面画像を必要とする。

なお、ステップＳ１０９において、管理サーバ１００は、鍵番号を用いることに代えて又は加えて、第１情報に含まれる元鍵２５の画像を用いることによって、複数の撮影条件の中から少なくとも１つの撮影条件を決定してもよい。例えば、当該画像に示される鍵の鍵刻み形状やつまみ形状などから、元鍵２５が表裏面の少なくとも一方にディンプルを有するか否か、元鍵２５の鍵刻み形状が表と裏で対称であるか否か、等が判別可能であり、当該判別結果に応じて上記の撮影条件を決定することができる。

ステップＳ１０９において、管理サーバ１００は更に、鍵番号を用いることによって、鍵の鍵刻み形状の複雑度合いに応じて設定された複数の判定条件の中から少なくとも１つの判定条件を選択する。本実施形態の管理サーバ１００は、ステップＳ１０７で抽出した鍵種類に基づいて１つの判定条件を選択、すなわち決定する。

鍵の鍵刻み形状の複雑度合いについて、具体的には、鍵の表裏面にディンプルが無い場合に比べて、鍵の表裏面の少なくとも一方にディンプルが有る場合の方が、複雑度合いが高い。また、鍵刻み形状が鍵の表と裏で対称な場合に比べて、鍵刻み形状が鍵の表と裏で非対称な場合の方が、複雑度合いが高い。

上述の通り、判定条件は、一例として、照合結果に含まれる第１情報と第２情報との一致度合いに対する閾値を含んでもよい。そして、当該閾値は、鍵の鍵刻み形状の複雑度合いに応じて異ならせてもよい。例えば、鍵刻み形状が複雑なものほど鍵刻み形状の正確な判別が困難になる傾向がある場合には、当該閾値は、鍵の鍵刻み形状の複雑度合いが高いほど低くてもよい。これに代えて、例えば、鍵刻み形状を複雑にしているものほどセキュリティを高めている傾向がある場合には、当該閾値は、鍵の鍵刻み形状の複雑度合いが高いほど高くてもよい。

管理サーバ１００は、発注端末３０から受信した第１情報と、ステップＳ１０７で抽出した第２情報とを照合する（Ｓ１１１）。ただし、本実施形態の管理サーバ１００は、当該照合の前に先ず、当該第１情報を解析することで、元鍵２５に関する上記数値の組み合わせを特定する。より具体的には、管理サーバ１００は、当該第１情報に含まれる元鍵２５の画像を解析することで、元鍵２５に関する上記数値の組み合わせを特定する。

当該解析は、一例として、平滑化（ガウシアンフィルタ）、適応的閾値処理、モルフォロジー変換（膨張）、トリミング、ハフ変換などの画像処理手段を用いてもよい。また、当該解析には、一例として、ＡＩによる画像認識技術を適用してもよい。

ここで、一実施形態による、元鍵２５の鍵種類がＩである場合における、元鍵２５の複数の鍵刻みの、それぞれの深さ度合を示す数値の組み合わせを特定する方法を説明すべく、図７を参照する。図７の上側には、第１情報に含まれる元鍵２５の正面画像のうち、元鍵２５のブレード部分を部分的に拡大した画像を模式的に示す。図７の下側には、上側に示す元鍵２５のブレード部分を、長手方向に９列の線で区分し、各列の名前と、各列の線上の鍵刻み深さの数値とを示す。図７の例では、各列の線上において、当該画像の上側の鍵刻み深さの数値と、当該画像の下側の鍵刻み深さの数値とを示す。

図７に示す例では、管理サーバ１００は、元鍵２５に関する上記数値の組み合わせとして、上側の１列目～９列目の数値と下側の１列目～９列目の数値とを順に並べた、１８桁の数値の組み合わせ「０３４００２０００ １００２１０３００」を特定する。

なお、管理サーバ１００は、元鍵２５の画像から特定する数値のセットを並べる順番を鍵種類に応じて決めてもよい。換言すると、例えば９桁といった数値のセットを順に並べる基準は、鍵種類に応じて予め定められていてもよい。具体的な一例は、鍵種類ＩからＩＶの何れにおいても、１～９桁の数値のセットは正面画像または表面画像の上側の鍵刻み深さの数値であり、１０～１８桁の数値のセットは正面画像または表面画像の下側の鍵刻み深さの数値である。鍵種類ＩＩにおいては、１９～２７桁の数値のセットは側面画像の鍵刻み深さの数値である。

鍵種類ＩＩＩおよびＩＶにおいては、１９～２７桁の数値のセットは裏面画像の上側の鍵刻み深さの数値であり、２８～３６桁の数値のセットは裏面画像の下側の鍵刻み深さの数値である。鍵種類ＩＶにおいては、３７～４５桁の数値のセットは一方の側面画像の鍵刻み深さの数値であり、４６～５４桁の数値のセットは他方の側面画像の鍵刻み深さの数値である。

図６のフロー図の説明に戻ると、ステップＳ１１１において、本実施形態の管理サーバ１００は、元鍵２５に関する上記数値の組み合わせを特定した場合に、特定した当該数値の組み合わせと、ステップＳ１０７で抽出した第２情報に含まれる数値の組み合わせとを照合する。管理サーバ１００は、一例として、両組み合わせの同じ桁の数値同士が一致している割合に応じた０～１の一致度合いを照合結果としてもよい。より具体的には、管理サーバ１００は、数値が一致している桁が多いほど、全体としての一致度が高い照合結果を出力してもよい。

管理サーバ１００は、発注端末３０から発注される元鍵２５の合鍵の作成を受注するか否かを、ステップＳ１１１の照合結果に基づいて判定する（Ｓ１１３）。本実施形態の管理サーバ１００は、ステップＳ１０９で決定した判定条件を用いて、合鍵の作成を受注するか否かを判定する。

ステップＳ１１３において、管理サーバ１００は、照合結果が判定条件を満たすと判定した場合（Ｓ１１３：ＹＥＳ）、ステップＳ１０９で決定した撮影条件が、元鍵２５の向きが異なる複数の画像を第１情報として必要とすることであるか否か、換言すると、第１情報として更なる画像を必要とするか否かを判断する（Ｓ１１５）。

管理サーバ１００は、第１情報として更なる画像を必要とすると判断した場合（Ｓ１１５：ＹＥＳ）、発注端末３０に対して、既に取得された元鍵２５の画像に示される元鍵２５の向きとは異なる向きの元鍵２５の画像を追加で取得するように要求する（Ｓ１１７）。本実施形態においては、管理サーバ１００は、元鍵２５の鍵種類がＩＩ、ＩＩＩおよびＩＶの何れかであると判断した場合には、第１情報として更なる画像を必要とすると判断してもよい。より具体的には、管理サーバ１００は、元鍵２５の鍵種類がＩＩであると判断した場合には、第１情報として側面画像を必要とすると判断してもよい。また、管理サーバ１００は、元鍵２５の鍵種類がＩＩＩであると判断した場合には、第１情報として裏面画像を必要とすると判断してもよい。また、管理サーバ１００は、元鍵２５の鍵種類がＩＶであると判断した場合には、第１情報として裏面画像および両側面画像を必要とすると判断してもよい。

発注端末３０は、管理サーバ１００から上記要求を示す情報を受信した場合、ユーザ２０に、当初とは異なる角度で元鍵２５を撮影させ（Ｓ１１９）、撮影した元鍵２５の画像を含む更なる第１情報を管理サーバ１００に送信する（Ｓ１２１）。

なお、発注端末３０は、ステップＳ１０３で内蔵のカメラを起動した後、上記要求を示す情報のような何らかの情報を管理サーバ１００から受信するまで、カメラを起動し続けていてもよい。これに代えて、発注端末３０は、ステップＳ１０５で第１情報等を管理サーバ１００に送信した後に、再び元鍵２５を撮影するように要求されるまで、カメラをオフにしておいてもよい。

管理サーバ１００は、更なる第１情報を発注端末３０から受信した場合、更なる第１情報と、ステップＳ１０７で抽出した第２情報のうちの未使用の情報とを照合する（ステップＳ１２３）。

ここで、一実施形態による、元鍵２５の鍵種類がＩＩである場合における、元鍵２５の数値の組み合わせを特定する方法を説明するべく、図８を参照する。上記の複数の撮影条件は、元鍵２５がディンプルを含む場合に、少なくとも、元鍵２５の正面画像と、元鍵２５の長手方向の側面画像とを、第１情報として必要とすることを含んでもよい。この場合、一例として、ステップＳ１１１で照合対象となる当初の第１情報には、元鍵２５の正面画像が含まれ、ステップＳ１２３で照合対象となる更なる第１情報には、元鍵２５の長手方向の側面画像が含まれる。

図８の上側には、当初の第１情報に含まれる元鍵２５の正面画像のうち、元鍵２５のブレード部分を部分的に拡大した画像を模式的に示す。図８の中央には、更なる第１情報に含まれる元鍵２５の長手方向の側面画像のうち、元鍵２５のブレード部分を部分的に拡大した画像を模式的に示す。図８の下側には、上側に示す元鍵２５のブレード部分を、長手方向に１１列の線で区分し、各列の名前と、各列の線上の鍵刻み深さの数値とを示す。

図８の例では、各列の線上において、図８の上側に示す正面画像の上側の鍵刻み深さの数値と、当該正面画像の下側の鍵刻み深さの数値と、図８の中央に示す側面画像の鍵刻み深さの数値と、を示す。なお、本実施形態の元鍵２５には、表面および裏面の同じ位置に、鍵の刻み形状とは無関係なダミーのディンプルが形成されており、上記の１１列のうち、３列目と４列目との間に位置する。管理サーバ１００は、当該ダミーのディンプルの存在および位置を予め知っていてもよい。

図８に示す例では、管理サーバ１００は、ステップＳ１１１において、元鍵２５に関する上記数値の組み合わせとして、上側の１列目～１１列目の数値と中央側の１列目～１１列目の数値とを順に並べた、２２桁の数値の組み合わせ「３０００００１３０００ ００２００４００１１０」を特定する。また、本例では、管理サーバ１００は、ステップＳ１２３において、元鍵２５に関する上記数値の組み合わせの残りとして、下側の１列目～１１列目の数値を順に並べた、１１桁の数値の組み合わせ「０１０２０００００００」を特定する。なお、図８に示す例では、管理サーバ１００が管理している複数の第２情報には、３３桁の数値の組み合わせが含まれるものとする。

図６のフロー図の説明に戻ると、上述の通り、ステップＳ１２３では、ステップＳ１０７で抽出した第２情報のうち、ステップＳ１１１で使用しなかった情報を照合対象とする。具体例として、管理サーバ１００は、ステップＳ１１１において、当初の第１情報に含まれる元鍵２５の正面画像から１８桁の数値の組み合わせ「１０３２４０１２２ ４１３３２２００２」を特定し、その一方で、図３に示すテーブルから、鍵種類ＩＩと、第２情報として２７桁の数値の組み合わせ「１０３２４００２２ ４１３３２１００２ ０１０２４３２２４」とを抽出しているものとする。この場合、管理サーバ１００は、当初の第１情報に基づく１８桁の数値の組み合わせと、第２情報の２７桁の数値の組み合わせのうちの１８桁までの数値の組み合わせとを照合する。

そして、管理サーバ１００は、ステップＳ１２３において、更なる第１情報に含まれる元鍵２５の側面画像から９桁の数値の組み合わせ「１１１２４３２２４」を特定し、当該９桁の数値の組み合わせと、第２情報の２７桁の数値の組み合わせのうちの１９桁～２７桁までの数値の組み合わせとを照合する。

管理サーバ１００は、ステップＳ１１３の判定に加えて、発注端末３０から発注される元鍵２５の合鍵の作成を受注するか否かを、ステップＳ１２３の照合結果に基づいて最終的に判定する（Ｓ１２５）。本実施形態の管理サーバ１００は、ステップＳ１１３の判定と同様に、ステップＳ１０９で決定した判定条件を用いて、合鍵の作成を受注するか否かを最終的に判定する。

管理サーバ１００は、ステップＳ１２５において照合結果が判定条件を満たすと判定した場合（Ｓ１２５：ＹＥＳ）、および、ステップＳ１１５において撮影条件が第１情報として更なる画像を必要とすることではないと判断した場合（Ｓ１１５：ＮＯ）、の何れにおいても、図５のステップＳ１２７へ進む。

なお、図６を用いて説明した、鍵種類ＩＩの元鍵２５について２７桁の数値の組み合わせ同士を照合する場合の具体例を詳述する。管理サーバ１００は、ステップＳ１１１で、１８桁の両数値のうち２つが±１の範囲内で異なっていると判定し、一致度合いが（１８－２）／１８≒０．８９である、との照合結果を出力する。管理サーバ１００は、ステップＳ１１３で、判定条件である一致度合いの閾値０．８を満たすと判定してもよい。そして、管理サーバ１００は、ステップＳ１２３で、９桁の両数値のうち２つが±１の範囲内で異なっていると判定し、例えば、一致度合いが約０．７８である、との照合結果を出力し、ステップＳ１２５で、判定条件である一致度合いの閾値０．８を満たさないと判定してもよい。なお、管理サーバ１００は、上記の一致度合いの演算において、比較する各桁の数値のずれ度合いが大きいほど一致度合いが低くなるような係数を用いてもよい。

一方、管理サーバ１００は、ステップＳ１１３において照合結果が判定条件を満たさないと判定した場合（Ｓ１１３：ＮＯ）、および、ステップＳ１２５において照合結果が判定条件を満たさないと判定した場合（Ｓ１２５：ＮＯ）、の何れにおいても、ステップＳ１１４に進む。

図９は、ステップＳ２０２で管理サーバ１００により付与されて格納される認証ＩＤおよび新鍵番号のテーブル１１１の例である。管理サーバ１００は、元鍵番号に対応付けて認証ＩＤおよび新鍵番号をテーブル１１１に格納する。互いに対応付けられているという観点から、認証ＩＤは元鍵２５を特定するものであるとともに合鍵２７を特定するものでもあるといえる。

認証ＩＤは任意の桁数および文字数の数字列や文字列であってよい。図９の例では、６桁の数字列である。

新鍵番号も任意の桁数および文字数の数字列や文字列であってよいが、元鍵番号とは異なる番号である。新鍵番号から元鍵番号が推認できるような番号でないことが好ましい。

新鍵番号は、元鍵番号とは、数字の桁数、数字以外の記号の数、および、数字と数字以外の記号との順序、の少なくともいずれかが異なることが好ましい。図９の例では、元鍵番号は４桁の数字とその後の６英文字とからなっているが、新鍵番号は３英文字とその後の５桁の数字とからなっている。付言すれば、新鍵番号は元鍵番号の付与ルールとは異なるルールで付与されている。これにより、番号自体で元鍵番号か新鍵番号かを区別することができる。よってこの場合には、図４のステップＳ１２において、入力された鍵番号がテーブル１０９にあるかどうかの判断に代えてまたは加えて、入力された鍵番号をデータベース１０７に予め格納されている付与ルールに当てはめることにより、元鍵番号か新鍵番号かを判断することで元鍵２５からの合鍵作成であるか否かを判断してもよい。

図１０は、認証ＩＤに基づく発注判断を行う処理（Ｓ３０）の一例である。当該合鍵受注方法において、ユーザ２０は、発注端末３０を操作することによって、自身が所持している合鍵２７の更なる合鍵（孫鍵と呼ぶことがある）の作成を管理サーバ１００に発注する。管理サーバ１００は、発注端末３０から発注される孫鍵の作成を受注するか否かを判定する。管理サーバ１００は、当該作成を受注すると決定した場合に、管理サーバ１００の所有者に孫鍵の作成を開始させるための通知をしてもよい。なお、図１０において図５および図６と同じ動作には同じステップの番号を付して説明を省略する。

図１０に示すフローも図５および図６と同様に、ユーザ２０が、発注端末３０の合鍵受注システム用のアプリケーションを起動することによって開始されてもよい。ユーザ２０は、発注端末３０のディスプレイに表示されるアプリケーションの操作説明に従って、当該フローで必要とされる、発注端末３０上の各操作を行ってもよい。

発注端末３０は、ユーザ２０に新鍵番号を入力させる（Ｓ３０１）。発注端末３０はさらに、ユーザ２０に認証ＩＤを入力させる（Ｓ３０３）。発注端末３０は、入力された新鍵番号および認証ＩＤを管理サーバ１００に送信する（ステップＳ３０５）。

管理サーバ１００は、新鍵番号および認証ＩＤを発注端末３０から受信した場合、データベース１０７のテーブル１１１と照合する（Ｓ３０７）。具体的には、管理サーバ１００の照合部１０３は、受信した新鍵番号と認証ＩＤとの組み合わせと同じものが、テーブル１１１に格納されているかどうかを判断する。

判定部１０５は照合部１０３の照合結果に基づいて受注するか否かを判定する（Ｓ３０９）。すなわち、照合部１０３により、受信した新鍵番号と認証ＩＤとの組み合わせと同じものがテーブル１１１に格納されていると判断された場合、判定部１０５は照合結果がＯＫであるとして（Ｓ３０９：Ｙｅｓ）、受注を決定する（Ｓ１２７）。一方、照合部１０３により、受信した新鍵番号と認証ＩＤとの組み合わせと同じものがテーブル１１１に格納されていないと判断された場合、判定部１０５は照合結果がＯＫでないとして（Ｓ３０９：Ｎｏ）、受注を受け付けず、ステップＳ１１４に進む。

ステップＳ１２７以降は図５のステップＳ１２９からＳ１３３と同様の動作の後に、孫鍵を製造するための情報を合鍵製造装置２００に出力する。当該情報には、新鍵番号および鍵の形状を特定する情報が含まれる。鍵の形状を特定する情報には、図３の「鍵種類」および「数値の組み合わせ」が含まれる。これにより、合鍵製造装置２００は、新鍵番号を刻印した孫鍵としての合鍵２７を製造する。

以上、本実施形態によれば、合鍵から更なる合鍵を作成する場合に認証ＩＤとともに照合を行うので、合鍵発行のセキュリティを高めることができる。さらに、元鍵の発行時に認証ＩＤとの対応付けがなされていなくても、後日対応付けができるので、それにより合鍵発行のセキュリティを高めることができる。さらに、新鍵番号を付与するので、元鍵番号を他人に知られるリスクを低減しつつ、さらなる合鍵を作ることもできるというユーザへの利便性を向上することができる。

図１１は、認証ＩＤを認証カード２９に表示する形態を示す。図１１において図１と同じ構成には同じ参照番号を付して説明を省略する。

図１１は、図１の構成に加えてカード発行装置２１０を有する。カード発行装置２１０は通信ネットワーク５０を介して少なくとも管理サーバ１００と通信する。

図１１において、図５のステップＳ１５４に代えてまたはこれに加えて、管理サーバ１００が認証ＩＤをカード発行装置２１０に出力する。カード発行装置２１０は、認証ＩＤを表示した認証カード２９を発行する。当該認証カード２９は郵送等によりユーザ２０に届けられる。付言すれば、図１１の例においては、認証ＩＤを物理的な媒体に表示してユーザ２０に通知する一例となっている。

なお、カード発行装置２１０に代えて、鍵を複製する業者によって認証カード２９に記入されてもよい。また、認証カード２９に代えて、紙やその他の物理的な媒体に認証ＩＤを付与してもよい。さらに、当該媒体に認証ＩＤに加えて新鍵番号も表示してもよい。

図１２は、認証カード２９に表示された認証ＩＤを読み込んで管理サーバ１００に送信する形態を示す。図１２において図１および図１１と同じ構成には同じ参照番号を付して説明を省略する。

図１２において、受付サーバ１０２が設置されている。受付サーバ１０２は、ネットワーク５０を介して少なくとも発注端末３０及び管理サーバ１００と通信する。

受付サーバ１０２は、発注端末３０からの合鍵作成の発注を受信し、管理サーバ１００に送信する。この場合に、受付サーバ１０２は、図１から図１１で説明した管理サーバ１００の一部の機能を受け持ってよい。

管理サーバ１００は、合鍵作成の発注を受け付けた場合に、認証ＩＤを自ら付与することに代えて、外部から入力されたものを用いる。例えば、カード発行装置２１０により元鍵番号との対応付けなしに予め発行された認証カード２９に付与された認証ＩＤを用いる。この場合に、認証カード２９に付与された認証ＩＤは合鍵製造者等によってキーボードなどで入力されてよい。これに代えて、当該認証ＩＤがスキャンされてＯＣＲで読み取られてもよい。さらに、認証ＩＤがバーコードやＩＣチップなど光学的、電気的または磁気的に読み取り可能に認証カード２９に付与されている場合には、対応する読取方法で読み取られて管理サーバ１００に入力されてもよい。

管理サーバ１００は入力された認証ＩＤを元鍵番号に対応付けてテーブル１１１に格納する。管理サーバ１００はさらに、図１から図１１で説明した他の動作を行う。管理サーバ１００はこれに加えて、元鍵番号と認証ＩＤとの組または少なくとも認証ＩＤを注文受付サーバ１０２に送信してもよい。認証ＩＤのデータの流れを図中の破線矢印で示した。なお、認証カード２９に予め付与された認証ＩＤを用いるか否かは、受付サーバ１０２を設置するか否かと独立して適用されてよい。

上記いずれの実施形態においても、認証ＩＤが付与された後に元鍵２５からの合鍵２７の作成を禁止してもよいし、禁止しなくてもよい。禁止しない場合には元鍵番号と認証ＩＤの組み合わせを照合し、同じ組み合わせがテーブル１１１に存在するという照合結果が得られたら合鍵２７を作成し、得られなければ作成を却下してもよい。さらに、禁止するかしないかを発注端末３０を介してユーザ２０に選択させてもよい。

一律に禁止する場合には、テーブル１１１に元鍵番号に対応付けて新鍵番号が格納されていたら、元鍵２５からの合鍵２７の作成を禁止してもよい。また、ユーザ２０に選択させる場合には、テーブル１１１に元鍵２５からの合鍵２７の作成可否のフラグを設け、ユーザ２０の選択に応じて格納されたフラグにより、作成可否を判断してもよい。

また、合鍵２７から孫鍵を作成する場合に、図５のステップＳ２０２からＳ１５４と同様に、新たな認証ＩＤおよび新たな新鍵番号が付与され、出力されてもよい。また、図４から図６のフローにおいて、発注端末３０を介したユーザ２０からの指示により、合鍵２７を作成せず、認証ＩＤおよび新鍵番号の少なくとも一方を付与して、データまたは物理的な媒体でユーザ２０に通知してもよい。この場合に、それ以降の合鍵２７の発注に対し、元鍵番号と、認証ＩＤおよび新鍵番号の少なくとも一方とをテーブル１１１と照合して合鍵２７を受注するかどうかを判断してよい。また、合鍵２７を作成する場合であっても、認証ＩＤを付与するが新鍵番号を付与しない形態であってもよい。この場合には、その後の合鍵２７の受注の判断は元鍵番号と認証ＩＤの組み合わせを照合することで行われてよい。

上記実施形態では、図４のステップＳ１２において、元鍵番号がテーブル１０９に格納されているかどうか、または、元鍵番号がデータベース１０７に格納された元鍵番号の付与ルールに従っているかどうかで判断する例を説明した。これに代えてまたはこれに加えて、発注端末３０において元鍵２５からの合鍵発注か合鍵２７からの合鍵発注かをユーザ２０に入力させ、その情報に基づいて判断してもよい。また、上記実施形態ではテーブル１０９とテーブル１１１が別々であるが、一つのテーブルにまとまっていてもよい。

上記いずれの実施形態においても、元鍵情報及び新鍵情報の一例として、英数字の組み合わせからなる鍵番号を説明した。元鍵情報及び・又は新鍵情報は、鍵「番号」に限られず、他の情報であってもよい。他の情報の例はバーコードおよび２次元コードなどの画像並びにその画像が示すコンピュータで処理可能なデータ、ＩＣチップに記憶された電気信号または磁気信号およびその信号が示すコンピュータで処理可能なデータなどである。

上記いずれの実施形態においても、認証ＩＤ及び新鍵情報を付与する過程で互いに異なる複数の元鍵情報に対して同じ認証ＩＤ及び・又は同じ新鍵情報が対応づけられてもよい。また、一つの元鍵情報に複数の認証ＩＤ及び・又は複数の新鍵情報が対応づけられてもよい。

上記いずれの実施形態においても、元鍵情報又は新鍵情報によって特定される形状は解錠のための有効パターン刻みを含んでいればよく、解錠に寄与しないダミー刻みは含まれなくてよい。また、当該元鍵情報又は新鍵情報ではブランキー形状やキーヘッドの形状は特定されなくてもよい。

さらに他の変形例として、管理サーバのデータベースには、鍵番号と、鍵の形状に関する第２情報との組み合わせが複数格納されており、管理サーバは、発注端末から元鍵の鍵番号情報を受信すると、鍵番号情報に示される鍵番号に対応する第２情報をデータベースから抽出し、発注端末から受信した第１情報を照合する構成として説明した。また、鍵の形状に関する第２情報は、鍵の複数の鍵刻みの、それぞれの深さ度合を示す数値の組み合わせを含むものとして説明した。これに代えて、鍵の形状に関する第２情報は、鍵番号が鍵の形状と対応付けられている場合には、鍵番号そのものを含んでもよく、管理サーバのデータベースには、複数の鍵番号のみが格納されていてもよい。

この場合、管理サーバは、発注端末から元鍵の画像を含む第１情報を受信した場合に、当該画像を解析して、元鍵に刻印されている鍵番号を取得したり、元鍵に刻印、プリント等されているＱＲコード（登録商標）やバーコード等に示される鍵番号を取得したりしてもよい。管理サーバは、発注端末が画像解析して取得した鍵番号を含む第１情報を受信してもよい。そして、管理サーバは、第１情報、すなわち鍵番号と、データベースに格納されている複数の第２情報、すなわち複数の鍵番号とを照合し、第１情報と何れか１つの第２情報とが相互に一致した場合に、元鍵の合鍵作成を受注すると判定してもよい。

また例えば、第１情報は、発注端末で取得された元鍵の画像を含むものとして説明した。これに代えて又は加えて、第１情報は、元鍵に紐づけられた付属品の画像、および、元鍵に設けられた電子チップに格納されているデータ、のうちの少なくとも１つを含んでもよい。元鍵に紐づけられた付属品の一例は、セキュリティカードであってもよい。当該セキュリティカードには、元鍵の鍵番号に対応する番号そのもの、または当該番号を示すＱＲコード（登録商標）やバーコード等が、刻印、プリント等されている。また、当該電子チップは、例えば、元鍵のヘッドに埋め込まれていてもよく、元鍵のヘッド表面に取り付けられていてもよい。当該電子チップに格納されているデータは、元鍵の鍵番号であってもよい。

また例えば、第１情報および第２情報は、例えば、鍵のメーカーによって鍵の表面に刻印されるメーカー刻印の画像を含んでもよい。この場合、鍵の表面に刻印されるメーカー刻印の画像は、鍵の形状に関する第２情報の一例であってもよく、管理サーバのデータベースには、１または複数のメーカー刻印の画像のみが格納されていてもよい。

この場合、発注端末は、カメラによって当該付属品を撮像したり、リーダによって当該電子チップと無線通信することで当該データを読み取ったりすることによって、第１情報を取得してもよい。管理サーバは、第１情報、すなわち鍵番号と、データベースに格納されている複数の第２情報、すなわち複数の鍵番号とを照合し、第１情報と何れか１つの第２情報とが相互に一致した場合に、元鍵の合鍵作成を受注すると判定してもよい。

なお、セキュリティカードや電子チップが有する情報は、元鍵の鍵番号に代えて又は加えて、元鍵の鍵刻みの深さ度合を示す数値の組み合わせであってもよい。この場合には、管理サーバは、図１等を用いて説明した実施形態と同様に、元鍵の合鍵の作成を受注するための複数の処理を実行してもよい。

また例えば、元鍵の鍵番号は、ユーザによって発注端末に入力される構成として説明した。しかしながら、元鍵の鍵識別情報、例えば上述の鍵番号や、ＱＲコード（登録商標）や、バーコード等が元鍵に刻印、プリント等されている場合には、当該構成に代えて又は加えて、当該鍵識別情報は、第１情報に含まれる元鍵の画像を解析することで取得されてもよい。当該解析は、管理サーバが行ってもよく、発注端末が行ってもよい。

また例えば、管理サーバは、第１情報に含まれる元鍵の画像を解析することで、元鍵の複数の鍵刻みのそれぞれの深さ度合を示す数値の組み合わせを特定する構成として説明した。管理サーバは、当該構成に代えて又は加えて、第１情報に含まれる元鍵の画像を解析することで、鍵刻みの深さ度合を示す数値を特定することなく、元鍵の鍵刻み形状を特定してもよい。この場合、第２情報は、当該数値の組み合わせに代えて又は加えて、鍵刻み形状を含み、すなわち鍵刻み形状を示すデータを含む。管理サーバは、特定した元鍵の鍵刻み形状と、第２情報に含まれる鍵刻み形状とを照合する。換言すると、管理サーバは、２つの画像に示される鍵刻み形状同士を照合する。

この場合、管理サーバは、予め定められた照合ルールに基づいて、第１情報と第２情報との照合結果を出力してもよい。例えば、管理サーバは、既知の画像マッチング処理などを用いて、第１情報の画像に示される鍵刻み形状と第２情報の画像に示される鍵刻み形状とを照合した結果を出力してもよい。これに代えて、管理サーバは、鍵の画像と鍵の鍵刻み形状との対応関係を学習した学習器を用いて、すなわち人工知能（ＡＩ）を用いて、第１情報と第２情報との照合結果を出力してもよい。

また例えば、管理サーバは、追加的な構成として、第１情報に含まれる元鍵の画像の画質が予め定められた条件を満たさない場合に、発注端末に対して、既に取得された元鍵の画像と差替えるために元鍵の新しい画像を取得させてもよい。具体的な一例として、管理サーバは、第１情報に含まれる元鍵の画像の画質が、元鍵の鍵刻み形状を特定できない程度に粗いと判断した場合に、発注端末に対して元鍵の新しい画像を取得させ、管理サーバに再送させてもよい。管理サーバは、図６に示すフローのステップＳ１１１およびＳ１２３の少なくとも一方で当該判断をしてもよく、当該新しい画像を取得した場合には、ステップＳ１１１およびＳ１２３のそれぞれから再開してもよい。

また例えば、主に図４から図６を用いて説明したように、第１情報と第２情報とを照合する主体も、照合結果に基づいて合鍵作成を受注するか否かを判定する主体も、管理サーバとして説明した。これに代えて、これらの主体を発注端末としてもよい。具体的には、発注端末は、元鍵の画像に関する第１情報と、鍵の形状に関する第２情報とを照合する照合部と、ユーザが管理サーバに発注しようとする元鍵の合鍵の作成を受注するか否かを、照合部による照合結果に基づいて判定する判定部とを備えてもよい。発注端末の照合部は、元鍵の鍵識別情報を管理サーバに送信したことに応じて、第２情報を管理サーバから受信してもよい。これらの処理は何れも、発注端末に予めインストールされた専用のアプリケーション上で行われてもよい。なお、この場合の発注端末は、合鍵発注端末の一例である。

この場合、管理サーバは、複数の第２情報をデータベースで管理する。管理サーバは、鍵番号情報を発注端末から受信した場合に、データベースに格納されている複数の第２情報から、当該鍵番号情報に示される鍵番号に対応する第２情報を抽出する。当該第２情報には、鍵種類が紐付けられていてもよい。管理サーバは、抽出した第２情報を発注端末に送信し、発注端末から発注情報を受信するまで、何ら処理を行わなくてもよい。発注端末は、主に図４から図６のフローを用いて説明した、発注端末および管理サーバによる残りの処理を全て、自ら行ってもよい。

また例えば、合鍵受注システムにおいて、発注端末で取得された元鍵の画像に関する第１情報と、管理サーバが管理している、鍵の形状に関する第２情報とを照合する処理を、発注端末および管理サーバの一方が行ってもよい。この場合、合鍵受注システムにおいて、照合結果に基づいて、前記発注端末から発注される前記元鍵の合鍵の作成を受注するか否かを判定する処理を、発注端末および管理サーバの他方が行ってもよい。

また例えば、発注端末で起動される上述のアプリケーションは、セキュリティ向上を目的とした追加的な構成として、ユーザに対してシステムログイン用のパスワード入力を要求してもよい。また同様に、管理サーバまたは発注端末は、セキュリティ向上を目的とした追加的な構成として、元鍵の形状特定に必要な画像を合鍵作成発注の度に異ならせてもよい。当該画像は、元鍵の撮影角度が指定されたものであってもよく、静止画に代えて動画であってもよい。

また例えば、管理サーバは、図６のフローのステップＳ１０７で抽出した鍵種類に基づいて、撮影条件および判定条件を決定する構成として説明した。しかしながら、鍵番号自体が、鍵刻み形状が表と裏で対称の鍵であるか否かを直接的に示す場合がある。また同様に、鍵番号自体が、鍵の表面および裏面の少なくとも一方にディンプルが形成された鍵であるか否かを直接的に示す場合がある。また同様に、鍵番号自体が、鍵の鍵刻み形状の複雑度合いが高い鍵であるか否かを直接的に示す場合がある。そこで、管理サーバは、発注端末から受信した鍵番号情報に示される鍵番号から直接的に、撮影条件および判定条件の少なくとも一方を決定してもよい。

また例えば、第１情報に含まれる元鍵の画像は、発注端末の内蔵カメラでリアルタイムに撮影したものとして説明した。セキュリティ向上の観点では、当該構成とすることが好ましいが、これに代えて又は加えて、当該画像は、発注端末がダウンロードしたものであってもよい。

また例えば、上記の実施形態では、一例として、管理サーバが、第１情報に含まれる元鍵の画像から、元鍵の複数の鍵刻みのそれぞれの深さ度合を示す数値の組み合わせを特定し、第２情報に含まれる数値の組み合わせと照合する構成として説明した。これに代えて、管理サーバは、第１情報に含まれる元鍵の画像から、元鍵の複数の鍵刻みの何れか１つの深さ度合を示す数値を特定し、第２情報に含まれる数値と照合してもよい。

本発明の様々な実施形態は、フローチャートおよびブロック図を参照して記載されてよく、ここにおいてブロックは、（１）操作が実行されるプロセスの段階または（２）操作を実行する役割を持つ装置のセクションを表わしてよい。特定の段階およびセクションが、専用回路、コンピュータ可読媒体上に格納されるコンピュータ可読命令と共に供給されるプログラマブル回路、および／またはコンピュータ可読媒体上に格納されるコンピュータ可読命令と共に供給されるプロセッサによって実装されてよい。専用回路は、デジタルおよび／またはアナログハードウェア回路を含んでよく、集積回路（ＩＣ）および／またはディスクリート回路を含んでよい。プログラマブル回路は、論理ＡＮＤ、論理ＯＲ、論理ＸＯＲ、論理ＮＡＮＤ、論理ＮＯＲ、および他の論理操作、フリップフロップ、レジスタ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブルロジックアレイ（ＰＬＡ）等のようなメモリ要素等を含む、再構成可能なハードウェア回路を含んでよい。

コンピュータ可読媒体は、適切なデバイスによって実行される命令を格納可能な任意の有形なデバイスを含んでよく、その結果、そこに格納される命令を有するコンピュータ可読媒体は、フローチャートまたはブロック図で指定された操作を実行するための手段を作成すべく実行され得る命令を含む、製品を備えることになる。コンピュータ可読媒体の例としては、電子記憶媒体、磁気記憶媒体、光記憶媒体、電磁記憶媒体、半導体記憶媒体等が含まれてよい。コンピュータ可読媒体のより具体的な例としては、フロッピー（登録商標）ディスク、ディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭまたはフラッシュメモリ）、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、静的ランダムアクセスメモリ（ＳＲＡＭ）、コンパクトディスクリードオンリメモリ（ＣＤ-ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、ブルーレイ（ＲＴＭ）ディスク、メモリスティック、集積回路カード等が含まれてよい。

コンピュータ可読命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、またはＳｍａｌｌｔａｌｋ（登録商標）、ＪＡＶＡ（登録商標）、Ｃ＋＋等のようなオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語のような従来の手続型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで記述されたソースコードまたはオブジェクトコードのいずれかを含んでよい。

コンピュータ可読命令は、汎用コンピュータ、特殊目的のコンピュータ、若しくは他のプログラム可能なデータ処理装置のプロセッサまたはプログラマブル回路に対し、ローカルにまたはローカルエリアネットワーク（ＬＡＮ）、インターネット等のようなワイドエリアネットワーク（ＷＡＮ）を介して提供され、フローチャートまたはブロック図で指定された操作を実行するための手段を作成すべく、コンピュータ可読命令を実行してよい。プロセッサの例としては、コンピュータプロセッサ、処理ユニット、マイクロプロセッサ、デジタル信号プロセッサ、コントローラ、マイクロコントローラ等を含む。

図１３は、本発明の複数の態様が全体的又は部分的に具現化されうるコンピュータ１２００の例を示す。コンピュータ１２００にインストールされたプログラムは、コンピュータ１２００に、本発明の実施形態に係る装置に関連付けられるオペレーション又は当該装置の１又は複数の「部」として機能させ、又は当該オペレーション又は当該１又は複数の「部」を実行させることができ、及び／又はコンピュータ１２００に、本発明の実施形態に係るプロセス又は当該プロセスの段階を実行させることができる。このようなプログラムは、コンピュータ１２００に、本明細書に記載のフローチャート及びブロック図のブロックのうちのいくつか又はすべてに関連付けられた特定のオペレーションを実行させるべく、ＣＰＵ１２１２によって実行されてよい。

本実施形態によるコンピュータ１２００は、ＣＰＵ１２１２、ＲＡＭ１２１４、グラフィックコントローラ１２１６、及びディスプレイデバイス１２１８を含み、これらはホストコントローラ１２１０によって相互に接続される。コンピュータ１２００はまた、通信インターフェース１２２２、ハードディスクドライブ１２２４、ＤＶＤ－ＲＯＭドライブ１２２６、及びＩＣカードドライブのような入出力ユニットを含み、これらは入出力コントローラ１２２０を介してホストコントローラ１２１０に接続される。コンピュータはまた、ＲＯＭ１２３０及びキーボード１２４２のようなレガシの入出力ユニットを含み、これらは入出力チップ１２４０を介して入出力コントローラ１２２０に接続される。

ＣＰＵ１２１２は、ＲＯＭ１２３０及びＲＡＭ１２１４内に格納されたプログラムに従い動作し、これにより各ユニットを制御する。グラフィックコントローラ１２１６は、ＲＡＭ１２１４内に提供されるフレームバッファ等又は当該グラフィックコントローラ１２１６自体の中に、ＣＰＵ１２１２によって生成されるイメージデータを取得し、イメージデータがディスプレイデバイス１２１８上に表示させる。

通信インターフェース１２２２は、ネットワークを介して他の電子デバイスと通信する。ハードディスクドライブ１２２４は、コンピュータ１２００内のＣＰＵ１２１２によって使用されるプログラム及びデータを格納する。ＤＶＤ－ＲＯＭドライブ１２２６は、プログラム又はデータをＤＶＤ－ＲＯＭ１２０１から読み取り、ハードディスクドライブ１２２４にＲＡＭ１２１４を介してプログラム又はデータを提供する。ＩＣカードドライブは、プログラム及びデータをＩＣカードから読み取り、及び／又はプログラム及びデータをＩＣカードに書き込む。

ＲＯＭ１２３０は、内部に、アクティブ化時にコンピュータ１２００によって実行されるブートプログラム等、及び／又はコンピュータ１２００のハードウェアに依存するプログラムを格納する。入出力チップ１２４０はまた、様々な入出力ユニットをパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して、入出力コントローラ１２２０に接続してよい。

プログラムが、ＤＶＤ－ＲＯＭ１２０１又はＩＣカードのようなコンピュータ可読記憶媒体によって提供される。プログラムは、コンピュータ可読記憶媒体から読み取られ、コンピュータ可読記憶媒体の例でもあるハードディスクドライブ１２２４、ＲＡＭ１２１４、又はＲＯＭ１２３０にインストールされ、ＣＰＵ１２１２によって実行される。これらのプログラム内に記述される情報処理は、コンピュータ１２００に読み取られ、プログラムと、上記様々なタイプのハードウェアリソースとの間の連携をもたらす。装置又は方法が、コンピュータ１２００の使用に従い情報のオペレーション又は処理を実現することによって構成されてよい。

例えば、通信がコンピュータ１２００及び外部デバイス間で実行される場合、ＣＰＵ１２１２は、ＲＡＭ１２１４にロードされた通信プログラムを実行し、通信プログラムに記述された処理に基づいて、通信インターフェース１２２２に対し、通信処理を命令してよい。通信インターフェース１２２２は、ＣＰＵ１２１２の制御の下、ＲＡＭ１２１４、ハードディスクドライブ１２２４、ＤＶＤ－ＲＯＭ１２０１、又はＩＣカードのような記録媒体内に提供される送信バッファ領域に格納された送信データを読み取り、読み取られた送信データをネットワークに送信し、又はネットワークから受信した受信データを記録媒体上に提供される受信バッファ領域等に書き込む。

また、ＣＰＵ１２１２は、ハードディスクドライブ１２２４、ＤＶＤ－ＲＯＭドライブ１２２６（ＤＶＤ－ＲＯＭ１２０１）、ＩＣカード等のような外部記録媒体に格納されたファイル又はデータベースの全部又は必要な部分がＲＡＭ１２１４に読み取られるようにし、ＲＡＭ１２１４上のデータに対し様々なタイプの処理を実行してよい。ＣＰＵ１２１２は次に、処理されたデータを外部記録媒体にライトバックしてよい。

様々なタイプのプログラム、データ、テーブル、及びデータベースのような、様々なタイプの情報が、情報処理されるべく、記録媒体に格納されてよい。ＣＰＵ１２１２は、ＲＡＭ１２１４から読み取られたデータに対し、本開示の随所に記載され、プログラムの命令シーケンスによって指定される様々なタイプのオペレーション、情報処理、条件判断、条件分岐、無条件分岐、情報の検索／置換等を含む、様々なタイプの処理を実行してよく、結果をＲＡＭ１２１４に対しライトバックする。また、ＣＰＵ１２１２は、記録媒体内のファイル、データベース等における情報を検索してよい。例えば、各々が第２の属性の属性値に関連付けられた第１の属性の属性値を有する複数のエントリが記録媒体内に格納される場合、ＣＰＵ１２１２は、当該複数のエントリの中から、第１の属性の属性値が指定されている条件に一致するエントリを検索し、当該エントリ内に格納された第２の属性の属性値を読み取り、これにより予め定められた条件を満たす第１の属性に関連付けられた第２の属性の属性値を取得してよい。

以上の説明によるプログラム又はソフトウェアモジュールは、コンピュータ１２００上又はコンピュータ１２００近傍のコンピュータ可読記憶媒体に格納されてよい。また、専用通信ネットワーク又はインターネットに接続されたサーバシステム内に提供されるハードディスク又はＲＡＭのような記録媒体が、コンピュータ可読記憶媒体として使用可能であり、これにより、プログラムをコンピュータ１２００にネットワークを介して提供する。

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

特許請求の範囲、明細書、および図面中において示した装置、システム、プログラム、および方法における動作、手順、ステップ、および段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り、任意の順序で実現しうることに留意すべきである。特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず、」、「次に、」等を用いて説明したとしても、この順で実施することが必須であることを意味するものではない。

１０ 合鍵受注システム、２０ ユーザ、２５ 元鍵、２７ 合鍵、２９ 認証カード、３０ 発注端末、５０ 通信ネットワーク、１００ 管理サーバ、１０１ 通信部、１０２ 受付サーバ、１０３ 照合部、１０５ 判定部、１０７ データベース、１０９ テーブル、１１１ テーブル、２００ 合鍵製造装置、２１０ カード発行装置、１２００ コンピュータ、１２０１ ＤＶＤ－ＲＯＭ、１２１０ ホストコントローラ、１２１２ ＣＰＵ、１２１４ ＲＡＭ、１２１６ グラフィックコントローラ、１２１８ ディスプレイデバイス、１２２０ 入出力コントローラ、１２２２ 通信インターフェース、１２２４ ハードディスクドライブ、１２２６ ＤＶＤ－ＲＯＭドライブ、１２３０ ＲＯＭ、１２４０ 入出力チップ、１２４２ キーボード

Claims (6)

1. 管理サーバが、合鍵の注文と共に元鍵の形状を特定する鍵情報を受信する段階と、
   前記管理サーバが、前記鍵情報に前記元鍵を特定するための認証ＩＤを対応付けて格納する段階と、を有する、
   合鍵受注方法。
2. 前記管理サーバが、前記元鍵に、前記鍵情報とは異なる新たな鍵情報を付与する段階をさらに有し、前記新たな鍵情報と前記認証ＩＤとは紐づけられて前記管理サーバに格納する、
   請求項１に記載の合鍵受注方法。
3. 前記新たな鍵情報を前記合鍵に物理的に表示する段階を更に備える請求項２に記載の合鍵受注方法。
4. 前記管理サーバが、合鍵の注文と共に前記認証ＩＤおよび前記新たな鍵情報を受信した場合に、前記管理サーバが管理している、前記認証ＩＤおよび前記新たな鍵情報とを照合する段階と、
   新たな合鍵の作成を受注するか否かを、前記照合する段階の照合結果に基づいて判定する段階と、をさらに有する、
   請求項２または３に記載の合鍵受注方法。
5. 前記管理サーバが、合鍵の注文と共に前記認証ＩＤおよび前記元鍵の鍵情報を受信した場合に、前記管理サーバが管理している、前記認証ＩＤおよび前記元鍵の鍵情報とを照合する段階と、
   新たな合鍵の作成を受注するか否かを、前記照合する段階の照合結果に基づいて判定する段階と、をさらに有する、
   請求項１から３のいずれか１項に記載の合鍵受注方法。
6. 管理サーバに、
   合鍵の注文と共に元鍵の形状を特定する鍵情報を受信する手順と、
   前記鍵情報に前記元鍵を特定するための認証ＩＤを対応付けて格納する手順と、
   を実行させるプログラム。

Images