(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-30
(45)【発行日】2024-09-09
(54)【発明の名称】合鍵受注方法およびプログラム
(51)【国際特許分類】
G06Q 10/20 20230101AFI20240902BHJP
【ＦＩ】
G06Q10/20
【請求項の数】
10
(21)【出願番号】P 2020183127
(22)【出願日】2020-10-30
(65)【公開番号】P2022073257
(43)【公開日】2022-05-17
【審査請求日】2023-10-12
(73)【特許権者】
【識別番号】390037028
【氏名又は名称】美和ロック株式会社
(74)【代理人】
【識別番号】110000877
【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所
(72)【発明者】
【氏名】田中 健一
(72)【発明者】
【氏名】高田 寿
【審査官】佐藤 敬介
(56)【参考文献】
【文献】特開２０１６－０３１５５５（ＪＰ，Ａ）
【文献】特開２００４－０２７５１９（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
元鍵の合鍵の作成を発注する発注者の発注端末によって、前記元鍵、および、前記元鍵に紐づけられた付属品、の少なくとも一方から得られた第１情報と、管理サーバが管理している、鍵の形状に関する第２情報とを照合する照合段階と、前記発注端末から前記発注者によって発注される前記元鍵の前記合鍵の作成を受注するか否かを、前記照合段階の照合結果に基づいて判定する判定段階と
を備える合鍵受注方法。
【請求項2】
元鍵、および、前記元鍵に紐づけられた付属品、の少なくとも一方から発注端末によって得られた第１情報と、管理サーバが管理している、鍵の形状に関する第２情報とを照合する照合段階と、
前記発注端末から発注される前記元鍵の合鍵の作成を受注するか否かを、前記照合段階の照合結果に基づいて判定する判定段階と、
ユーザが前記発注端末に入力する、前記元鍵の鍵番号を取得する取得段階と、
前記管理サーバが、データベースに格納されている複数の前記第２情報から、前記鍵番号に対応する前記第２情報を抽出する抽出段階と
を備え、
前記照合段階は、前記第１情報と、前記抽出段階で抽出した前記第２情報とを照合する、
合鍵受注方法。
【請求項3】
元鍵、および、前記元鍵に紐づけられた付属品、の少なくとも一方から発注端末によって得られた第１情報と、管理サーバが管理している、鍵の形状に関する第２情報とを照合する照合段階と、
前記発注端末から発注される前記元鍵の合鍵の作成を受注するか否かを、前記照合段階の照合結果に基づいて判定する判定段階と、
前記元鍵の鍵識別情報を、前記第１情報を解析することで取得する取得段階と、
前記管理サーバが、データベースに格納されている複数の前記第２情報から、前記鍵識別情報に対応する前記第２情報を抽出する抽出段階と
を備え、
前記照合段階は、前記第１情報と、前記抽出段階で抽出した前記第２情報とを照合する、
合鍵受注方法。
【請求項4】
元鍵、および、前記元鍵に紐づけられた付属品、の少なくとも一方から発注端末によって得られた第１情報と、管理サーバが管理している、鍵の形状に関する第２情報とを照合する照合段階と、
前記発注端末から発注される前記元鍵の合鍵の作成を受注するか否かを、前記照合段階の照合結果に基づいて判定する判定段階と、
前記第１情報に含まれる前記元鍵の画像を解析することで、前記元鍵の鍵刻みの深さ度合を示す数値を特定する特定段階と
を備え、
前記照合段階は、前記特定段階で特定した前記元鍵に関する数値と、前記第２情報に含まれる数値とを照合する、
合鍵受注方法。
【請求項5】
前記第１情報は、前記元鍵の画像、前記付属品の画像、および、前記元鍵に設けられた電子チップに格納されているデータ、のうちの少なくとも何れか１つを含む、
請求項１から４の何れか一項に記載の合鍵受注方法。
【請求項6】
前記第１情報に含まれる前記元鍵の画像を解析することで、前記元鍵の鍵刻み形状を特定する特定段階を備え、前記照合段階は、前記特定段階で特定した前記元鍵の前記鍵刻み形状と、前記第２情報に含まれる鍵刻み形状とを照合する、
請求項１から５の何れか一項に記載の合鍵受注方法。
【請求項7】
コンピュータに、元鍵の合鍵の作成を発注する発注者の発注端末によって、前記元鍵、および、前記元鍵に紐づけられた付属品、の少なくとも一方から得られた第１情報と、管理サーバが管理する、鍵の形状に関する第２情報とを照合する照合手順と、
前記発注端末から前記発注者によって発注される前記元鍵の前記合鍵の作成を受注するか否かを、前記照合手順の照合結果に基づいて判定する判定手順と
を実行させる、プログラム。
【請求項8】
コンピュータに、
元鍵、および、前記元鍵に紐づけられた付属品、の少なくとも一方から発注端末によって得られた第１情報と、管理サーバが管理する、鍵の形状に関する第２情報とを照合する照合手順と、
前記発注端末から発注される前記元鍵の合鍵の作成を受注するか否かを、前記照合手順の照合結果に基づいて判定する判定手順と、
ユーザが前記発注端末に入力する、前記元鍵の鍵番号を取得する取得手順と、
データベースに格納されている複数の前記第２情報から、前記鍵番号に対応する前記第２情報を抽出する抽出手順と
を実行させ、
前記照合手順は、前記第１情報と、前記抽出手順で抽出した前記第２情報とを照合する、
プログラム。
【請求項9】
コンピュータに、
元鍵、および、前記元鍵に紐づけられた付属品、の少なくとも一方から発注端末によって得られた第１情報と、管理サーバが管理する、鍵の形状に関する第２情報とを照合する照合手順と、
前記発注端末から発注される前記元鍵の合鍵の作成を受注するか否かを、前記照合手順の照合結果に基づいて判定する判定手順と、
前記元鍵の鍵識別情報を、前記第１情報を解析することで取得する取得手順と、
データベースに格納されている複数の前記第２情報から、前記鍵識別情報に対応する前記第２情報を抽出する抽出手順と
を備え、
前記照合手順は、前記第１情報と、前記抽出手順で抽出した前記第２情報とを照合する、
プログラム。
【請求項10】
コンピュータに、
元鍵、および、前記元鍵に紐づけられた付属品、の少なくとも一方から発注端末によって得られた第１情報と、管理サーバが管理する、鍵の形状に関する第２情報とを照合する照合手順と、
前記発注端末から発注される前記元鍵の合鍵の作成を受注するか否かを、前記照合手順の照合結果に基づいて判定する判定手順と、
前記第１情報に含まれる前記元鍵の画像を解析することで、前記元鍵の鍵刻みの深さ度合を示す数値を特定する特定手順と
を備え、
前記照合手順は、前記特定手順で特定した前記元鍵に関する数値と、前記第２情報に含まれる数値とを照合する、
プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、合鍵受注方法およびプログラムに関する。
【背景技術】
【0002】
一般客から鍵の複製を受注した鍵複製業者が、元鍵の複製に適するブランクキーを容易に選定できないときに、元鍵を撮影して鍵の表裏両面の画像情報を取得し、その画像情報を探索サービス業者に送ることで、探索サービス業者にブランクキーの探索を依頼するシステムが知られている（例えば、特許文献１を参照）。
［先行技術文献］
［特許文献］
［特許文献１］ 特開２０１６－３１５５５号公報
［先行技術文献］
［特許文献］
［特許文献１］ 特開２０１６－３１５５５号公報
【発明の概要】
【発明が解決しようとする課題】
【0003】
しかしながら、上記システムによれば、一般客は、元鍵を鍵複製業者に預けなければならなかった。
【課題を解決するための手段】
【0004】
本発明の一態様においては、合鍵受注方法が提供される。合鍵受注方法は、元鍵、および、元鍵に紐づけられた付属品、の少なくとも一方から発注端末によって得られた第１情報と、管理サーバが管理している、鍵の形状に関する第２情報とを照合する照合段階を備えてもよい。合鍵受注方法は、発注端末から発注される元鍵の合鍵の作成を受注するか否かを、照合段階の照合結果に基づいて判定する判定段階を備えてもよい。
【0005】
第１情報は、元鍵の画像、付属品の画像、および、元鍵に設けられた電子チップに格納されているデータ、のうちの少なくとも何れか１つを含んでもよい。
【0006】
合鍵受注方法は、ユーザが発注端末に入力する、元鍵の鍵番号を取得する取得段階と、管理サーバが、データベースに格納されている複数の第２情報から、鍵番号に対応する第２情報を抽出する抽出段階を備えてもよい。照合段階は、第１情報と、抽出段階で抽出した第２情報とを照合してもよい。
【0007】
合鍵受注方法は、元鍵の鍵識別情報を、第１情報を解析することで取得する取得段階を備えてもよい。合鍵受注方法は、管理サーバが、データベースに格納されている複数の第２情報から、鍵識別情報に対応する第２情報を抽出する抽出段階を備えてもよい。照合段階は、第１情報と、抽出段階で抽出した第２情報とを照合してもよい。
【0008】
合鍵受注方法は、第１情報に含まれる元鍵の画像を解析することで、元鍵の鍵刻みの深さ度合を示す数値を特定する特定段階を備えてもよい。照合段階は、特定段階で特定した元鍵に関する数値と、第２情報に含まれる数値とを照合してもよい。
【0009】
合鍵受注方法は、第１情報に含まれる元鍵の画像を解析することで、元鍵の鍵刻み形状を特定する特定段階を備えてもよい。照合段階は、特定段階で特定した元鍵の鍵刻み形状と、第２情報に含まれる鍵刻み形状とを照合してもよい。
【0010】
本発明の一態様においては、プログラムが提供される。プログラムは、コンピュータに、元鍵、および、元鍵に紐づけられた付属品、の少なくとも一方から発注端末によって得られた第１情報と、管理サーバが管理する、鍵の形状に関する第２情報とを照合する照合手順を実行させてもよい。プログラムは、コンピュータによって実行された場合に、コンピュータに、発注端末から発注される元鍵の合鍵の作成を受注するか否かを、照合手順の照合結果に基づいて判定する判定手順を実行させてもよい。
【0011】
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではない。また、これらの特徴群のサブコンビネーションもまた、発明となりうる。
【図面の簡単な説明】
【0012】
【図1】一実施形態による合鍵受注システム１０の概略図である。
【図2】一実施形態による管理サーバ１００のブロック図である。
【図3】一実施形態による管理サーバ１００のデータベース１０７に格納されるテーブルの一例である。
【図4】一実施形態による合鍵受注方法のフロー図である。
【図5】一実施形態による、元鍵２５の鍵種類がＩである場合における、元鍵２５の複数の鍵刻みの、それぞれの深さ度合を示す数値の組み合わせを特定する方法を説明するための図である。
【図6】一実施形態による、元鍵２５の鍵種類がＩＩである場合における、元鍵２５の数値の組み合わせを特定する方法を説明するための図である。
【図7】本発明の複数の態様が全体的又は部分的に具現化されうるコンピュータ１２００の例を示す図である。
【発明を実施するための形態】
【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】
１０ 合鍵受注システム、２０ ユーザ、２５ 元鍵、３０ 発注端末、５０ 通信ネットワーク、１００ 管理サーバ、１０１ 通信部、１０３ 照合部、１０５ 判定部、１０７ データベース、１２００ コンピュータ、１２０１ ＤＶＤ－ＲＯＭ、１２１０ ホストコントローラ、１２１２ ＣＰＵ、１２１４ ＲＡＭ、１２１６ グラフィックコントローラ、１２１８ ディスプレイデバイス、１２２０ 入出力コントローラ、１２２２ 通信インターフェース、１２２４ ハードディスクドライブ、１２２６ ＤＶＤ－ＲＯＭドライブ、１２３０ ＲＯＭ、１２４０ 入出力チップ、１２４２ キーボード
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
