(57)【要約】【課題】不正にライセンスキーが作成されることを未然に防ぐことを可能とする。【解決手段】認証サーバが、使用する機能がコード化された注文内容を基に、機能コードを生成し、ユーザを介して、機器の固有コードを前記認証サーバに転送するステップと、前記認証サーバが、前記機能コードと前記機器固有コードを基に、第１のライセンスキーを生成し、前記機器が、ユーザからコード化された注文内容を入力し、前記機器が、前記認証サーバから、ユーザを介して、前記第１のライセンスキーを入力し、前記機器が、入力したコード化された注文内容を基に、機能コードを生成し、更に、生成された機能コードと機器の機器固有コードを基に第２のライセンスキーを生成し、前記機器が前記第１のライセンスキーと前記第２のライセンスキーとを比較し、両者が一致した場合に、認証成功とする。【選択図】図４
2008197795.tif 000002
【特許請求の範囲】
【請求項１】
認証サーバが、使用する機能がコード化された注文内容を基に、機能コードを生成するステップと、
ユーザを介して、機器の固有コードを前記認証サーバに転送するステップと、
前記認証サーバが、前記機能コードと前記機器固有コードを基に、第１のライセンスキーを生成するステップと、
前記機器が、ユーザからコード化された注文内容を入力するステップと、
前記機器が、前記認証サーバから、ユーザを介して、前記第１のライセンスキーを入力するステップと、
前記機器が、入力したコード化された注文内容を基に、機能コードを生成し、更に、生成された機能コードと機器の機器固有コードを基に第２のライセンスキーを生成するステップと、
前記機器が前記第１のライセンスキーと前記第２のライセンスキーとを比較し、両者が一致した場合に、認証成功とするステップと、
を備えることを特徴とする機能ライセンス認証方法。
【請求項２】
請求項１に記載の機能ライセンス認証方法において、前記認証サーバのＵＲＬは、販売会社からユーザに渡される注文内容書に記載されたものであることを特徴とする機能ライセンス認証方法。
【請求項３】
請求項２に記載の機能ライセンス認証方法において、
前記注文内容書には、コード化された機能も記載されていることを特徴とする機能ライセンス認証方法。
【請求項４】
認証サーバと機器とを備え、
認証サーバが、使用する機能がコード化された注文内容を基に、機能コードを生成し、
ユーザを介して、機器の機器固有コードを前記認証サーバに転送し、
前記認証サーバが、前記機能コードと前記機器固有コードを基に、第１のライセンスキーを生成し、
前記機器が、ユーザからコード化された注文内容を入力し、
前記機器が、前記認証サーバから、ユーザを介して、前記第１のライセンスキーを入力し、
前記機器が、入力したコード化された注文内容を基に、機能コードを生成し、更に、生成された機能コードと機器の機器固有コードを基に第２のライセンスキーを生成し、
前記機器が前記第１のライセンスキーと前記第２のライセンスキーとを比較し、両者が一致した場合に、認証成功とすることを特徴とする機能ライセンス認証システム。
【請求項５】
請求項４に記載の機能ライセンス認証システムにおいて、前記認証サーバのＵＲＬは、販売会社からユーザに渡される注文内容書に記載されたものであることを特徴とする機能ライセンス認証システム。
【請求項６】
請求項４に記載の機能ライセンス認証システムにおいて、
前記注文内容書には、コード化された機能も記載されていることを特徴とする機能ライセンス認証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器（電話システムなど）の機能を利用するためのライセンスを取得するための機能ライセンス認証システム及び機能ライセンス認証方法に関する。
【背景技術】
【０００２】
以下に従来のライセンスキーの発行手順および機器での認証手順を示す。
【０００３】
「機能コード」は、使用制限を解除する機能の内容を表しており、機器へ解除する機能の内容を通知するために使用され、認証にも使用する。
【０００４】
「機器固有コード」は、機器個々に固有の番号であり、工場で生産時に書き込まれた番号である。工場での生産後に書き換えが困難である必要がある。
【０００５】
「ライセンスキー」は、機器固有コードと機能コードから作成され、機器は入力されたライセンスキーが認証されたものであることを確認するために使用する。
【０００６】
従来の認証作業は図１の手順で行う。
（１）ユーザは、使用する機器の機能、クライアントごとの機能とクライアントの数を販売会社に注文する（ステップＳ９０１）。
（２）販売会社は、注文内容を認証サーバに登録する（ステップＳ９０３）。
（３）認証サーバは、注文内容から「機能コード」を作成する（ステップＳ９０４）。
（４）販売会社は、認証サーバから「機能コード」を取得する（ステップＳ９０５）。
（５）販売会社は、「機能コード」、注文内容、及び認証サーバのアドレスを紙に印刷（図２参照）し、ユーザに販売する（ステップＳ９０４）。
（６）ユーザは、使用中の機器から「機器固有コード」を読み込む（ステップＳ９０９）。
（７）ユーザは、認証サーバにアクセスし、「機器固有コード」を認証サーバに入力する（ステップＳ９１１）。
（８）認証サーバでは、「機器固有コード」と「機能コード」から「ライセンスキー」を計算する（ステップＳ９１２）。
（９）ユーザは、「ライセンスキー」を認証サーバから入手する（ステップＳ９１３）。
（１０）ユーザは、「機能コード」と「ライセンスキー」を機器に、入力する（ステップＳ９１５）。
（１１）機器は、入力された「機能コード」と機器内の「機器固有コード」より「ライセンスキー」を計算し、入力された「ライセンスキー」と比較する。同じであれば機能コードが認証されたものであると認識し、「機能コード」に埋め込まれた機能を動作させる（ステップＳ９１７）。
【０００７】
「機能コード」、「機器固有コード」、「ライセンスキー」は次のように作成、計算される。
【０００８】
「機能コード」は、使用制限を解除する機能の内容を表しており、次のように作成する。
【０００９】
機器にて使用する機能はＯＮ／ＯＦＦのみを判断し、ａ１、ａ２、ａ３、ａ４、ａ５、ａ６、ａ７、ａ８の８種類あるとする。
【００１０】
クライアントを最大４０９５台接続可能な機器にて、クライアントが使用する機能をｂ１、ｂ２、ｂ３、ｂ４とする。
【００１１】
機器にて使用する機能のＯＮ／ＯＦＦをビットにて表すと、８ｂｉｔ必要となる。
【００１２】
機能ａ１のみＯＮの場合、０００００００１となり、例として１６進数で表現すると「０１」となる。
【００１３】
機能ａ１のみＯＦＦでａ２、ａ３、ａ４、ａ５、ａ６、ａ７、ａ８がＯＮの場合、１１１１１１１０で、１６進数で表現すると「ＦＥ」となる。
【００１４】
クライアント機能は何台のクライアントに使用を許可するかの台数を設定するものとし、機能ｂ１を使用可能なクライアント数が０台の場合は、１６進数で０台で「０００」、４０９５台で「ＦＦＦ」となる。
【００１５】
機能ｂ２も１６進数で「０００」〜「ＦＦＦ」の３桁必要となる。
【００１６】
全ての機能を表記する場合、機能ａ１、ａ２、ａ３、ａ４、ａ５、ａ６、ａ７、ａ８にて「００」〜「ＦＦ」、機能ｂ１にて「０００」〜「ＦＦＦ」、機能ｂ２〜ｂ４も同様に「０００」〜「ＦＦＦ」必要であり、合計すると「００  ０００  ０００  ０００  ０００」〜「ＦＦＦＦＦＦＦＦＦＦＦＦＦＦ」の１４桁となる。仮にクライアント用機能のｂ５が追加された場合は、１７桁となる。
【００１７】
「機器固有コード」は、シリアル番号やＭＡＣアドレスのような形態にて供給される。仮に１６進数で「００００」〜「ＦＦＦＦ」の番号とする。
【００１８】
「ライセンスキー」の作成方法は様々あるが例として積を求める。
【００１９】
機器固有コードが「ＡＢＣＤ」で、機能コードが「０３０６４４Ｄ２００００００」とした場合、ライセンスキーは、「７９ＢＦＤ６２２Ａ００００００」となる。機能コードが同じであっても機器固有コードが異なる場合、ライセンスキーは異なった値となる必要がある。
【００２０】
機器に入力された機能コード、ライセンスキーの認証は、次のように行う。ライセンスキーは、認証サーバと機器の両方で計算される。認証サーバと機器の両方にて、同一の機能コード、機器固有コードを用いて同一の法則（この場合は積）にて計算されたライセンスキーは同一となる。機器側には認証サーバにて計算されたライセンスキーが入力されるため、比較を行い同じであれば認証許可となる。機能コードが同じであっても、他の機器にライセンスキーを入力した場合は、機器固有コードが異なるため、機器内で計算されたライセンスキーが異なり認証が許可されない。
【特許文献１】特開２００４−２５２９３１号公報
【特許文献２】特開２００６−０３１３２０号公報
【特許文献３】特開２００６−０５９１６４号公報
【特許文献４】特開２００６−１９５８２６号公報
【発明の開示】
【発明が解決しようとする課題】
【００２１】
従来方式においては、ユーザに発行されるライセンスキーに解除する機能数や管理するクライアント数、機器固有の番号が含まれるため、各コードが暗号化されている、されていないに関わらずライセンスキーの計算方式を推測可能であり、不正にライセンスキーが作成される危険性があった。また管理する機能数が多い場合、発行されるライセンスキーの桁数が膨大な桁数となり、入力が煩雑となる。
【００２２】
そこで、本発明は、不正にライセンスキーが作成されることを未然に防ぐことを可能とする機能ライセンス認証方法及び機能ライセンス認証システムを提供することを目的とする。
【課題を解決するための手段】
【００２３】
本発明においては、次の変更を行う。
【００２４】
＜１＞従来、機能コード紙に表記されていた「機能コード」を表記しない。注文内容のみ表記した注文内容書『図３』に変更する。
【００２５】
認証サーバでは、販売店による注文内容の入力により「機能コード」を作成するが、出力を行わないように変更する。
【００２６】
＜２＞ユーザは従来機器にて入力していた「機能コード」を入力しない。
【００２７】
＜３＞ユーザによる機器への注文内容の入力を追加する。
【００２８】
機器側では、「機能コード」の入力を要求しないが、注文内容を入力する方式に変更する。動作させる機能は入力された注文内容とする。また、注文内容の入力から仮の「機能コード」を作成する。仮の「機能コード」と「機器固有コード」から「ライセンスキー」を計算する。
【発明の効果】
【００２９】
従来方式では、販売店から通知された「機能コード」を機器に入力する必要があったが、本発明では「機能コード」の入力が不要となる。
【００３０】
また、「機能コード」が不要となるため、「機能コード」を不正に作成されることが無い。
【００３１】
さらに、ユーザに「機能コード」が開示されないため、注文内容と、「機器固有コード」から計算される「ライセンスキー」がどのように計算されているかの推測が難しくなるため不正に「ライセンスキー」を作成、つまりは不正に機能制限の解除を行うことが難しくなる。
【００３２】
この方式では、機器へ『注文内容』の入力が必要となるが、注文内容書に書かれた通りに数字入力するだけであり、脈絡の無い文字の羅列である「機能コード」と比較し、入力作業が苦とならない。
【発明を実施するための最良の形態】
【００３３】
ソフトウェアおよびハードウェアの機能に使用制限を掛け、ライセンスキーを販売することで機能制限を解除する機器が存在する。従来このライセンスキーの作成には下記の条件が必要となる。第一にライセンスの不正使用を防止するためにライセンスキーに機器固有の番号を含むこと。第二にライセンスキーに解除する機能の内容が含まれること。第一、第二の条件を含むライセンスキーを暗号化等の演算を行い発行した場合、ライセンスキーを入力された機器は逆演算もしくは復号化キーが必要となるが、逆演算可能とするとセキュリティーが低下し、また復号化キーは取り扱いが複雑となる。
【００３４】
本発明ではライセンスキーの入力を簡便化し、かつセキュリティーの低下が発生しない認証方式を提供することを特徴とする。
【００３５】
以下、図面を参照して本発明を実施するための最良の形態について詳細に説明する。
【００３６】
ＰＢＸなどの電話機器にて機器の機能や電話機ごとの機能などがある。これらの機能の使用を制限して通常は使用できないようにした電話機機器を作成する。ユーザは、使用したい機器の機能及び電話機ごとの機能を必要台数分注文する。電話機器の販売会社は、注文を受けた機器の機能及び電話機ごとの機能を必要台数分使用できるようにする必要がある。
【００３７】
例として電話機が最大４０９５台収容可能な電話機器とする。
【００３８】
機器の機能としてａ１、ａ２、ａ３、ａ４、ａ５、ａ６、ａ７、ａ８があるとする。
【００３９】
電話機ごとの機能としてｂ１、ｂ２、ｂ３、ｂ４があるとする。
【００４０】
ユーザおよび販売店は次の作業を行い機能の使用制限を解除する。
【００４１】
次に、図４を参照して本実施形態による機能ライセンス認証方法の説明をする。
（１）ユーザ２０７は販売会社２０３に機器の機能ａ１、ａ２および電話機ごとの機能ｂ１を１００台分、機能ｂ２を１２３４台分注文する（ステップＳ１０１）。
（２）販売会社２０３は注文内容を認証サーバ２０５に登録する（ステップＳ１０３）。
（３）認証サーバ２０５は、注文内容から次の「機能コード」を作成して記録する（ステップＳ１０４）。「機能コード」は、「０３０６４４Ｄ２００００００」となる。
（４）販売会社２０３は、注文内容および認証サーバ２０５のアドレスを表記した注文確認書（図３参照）を発行してユーザ２０７に販売する（ステップＳ１０５）。
（５）ユーザ２０７は、使用中の機器（電話システム２０１など）から「機器固有コード」（「ＡＢＣＤ」）を読み込む（ステップＳ１０７）。
（６）ユーザ２０７は、注文確認書に書かれたアドレスにアクセスして認証サーバ２０５に「機器固有コード」（「ＡＢＣＤ」）を入力する（ステップＳ１０９）。
認証サーバ２０５では、「機器固有コード」（「ＡＢＣＤ」）と「機能コード」（「０３０６４４Ｄ２００００００」）から「ライセンスキー」（「７９ＢＦＤ６２２Ａ００００００」）を計算する（ステップＳ１１０）。
（７）ユーザ２０７は認証サーバ２０５から「ライセンスキー」（「７９ＢＦＤ６２２Ａ００００００」）を入手する（ステップＳ１１１）。
（８）ユーザ２０７は、機器のメニューにて注文内容（ａ１＝１、ａ２＝１、ｂ１＝１００、ｂ２＝１２３４）を機器（電話システム２０１など）に入力する（ステップＳ１１３）。
（９）ユーザ２０７は、「ライセンスキー」（「７９ＢＦＤ６２２Ａ００００００」）を機器（電話システム２０１など）に入力する（ステップＳ１１５）。
【００４２】
機器（電話システム２０１など）では、（８）で入力された注文内容から「機能コード」（「０３０６４４Ｄ２００００００」）を作成する。さらに内部に記録されている「機器固有コード」（「ＡＢＣＤ」）と、注文内容から作成した「機能コード」（「０３０６４４Ｄ２００００００」）から「ライセンスキー」（「７９ＢＦＤ６２２Ａ００００００」）を計算する。ここで、（９）にて入力された「ライセンスキー」と機器内部で計算された「ライセンスキー」を比較し、同じであるため、（８）で入力された注文内容が認証され機能を動作させる（ステップＳ１１６）。
【００４３】
機能の使用制限を掛けることが可能なサーバなどの機器は、電話機器やサーバなどがある。
【００４４】
「機能コード」は、２進数、１０進数、１６進数、ＡＳＣＩＩコードを用いてキャラクターとする、暗号化するなど、様々な方法がある。
【００４５】
「機能コード」は、機能の内容だけでなく、発行の日付や乱数と組み合わせたりする方法もある。
【００４６】
「ライセンスキー」の算出は、積だけでなく暗号化も含めて様々な方法がある。
【００４７】
「ライセンスキー」は全桁を表記しているが、チェックサムにする、一部分を切り出して認証するなどの方法がある。
【００４８】
本発明にて運用可能な機能数に制限は無い。
【００４９】
従来方式と本発明を組み合わせて、図５の手順にて機能コード紙に書かれている機能コードは乱数など意味の無い値とし、実際には認証しない方法もある。
【００５０】
「機能コード」、「注文内容書」は紙による供給以外に電子メールによる供給、インターネットのＷｅｂサイトへの表記、機器によるインターネットへのアクセスと自動入手の方法がある。
【図面の簡単な説明】
【００５１】
【図１】従来の機能ライセンス認証システムの構成を示すブロック図である。
【図２】図１に示すシステムにおいて、ユーザに発行される機能コード紙の例を示す図である。
【図３】図４に示すシステムにおいて、ユーザに発行される注文内容書の例を示す図である。
【図４】本発明の実施形態による機能ライセンス認証システムの構成を示すブロック図である。
【図５】本発明の他の実施形態による機能ライセンス認証システムの構成を示すブロック図である。
【符号の説明】
【００５２】
２０１  機器（電話システムなど）
２０３  販売会社
２０５  認証サーバ
２０７  ユーザ
【図１】
2008197795.tif 000003
【図２】
2008197795.tif 000004
【図３】
2008197795.tif 000005
【図４】
2008197795.tif 000006
【図５】
2008197795.tif 000007