JP5390079B2 - 端末発見システム - Google Patents
端末発見システム Download PDFInfo
- Publication number
- JP5390079B2 JP5390079B2 JP2007189313A JP2007189313A JP5390079B2 JP 5390079 B2 JP5390079 B2 JP 5390079B2 JP 2007189313 A JP2007189313 A JP 2007189313A JP 2007189313 A JP2007189313 A JP 2007189313A JP 5390079 B2 JP5390079 B2 JP 5390079B2
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- information
- name
- host name
- name resolution
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
本発明は、端末発見システムに関する。
従来、端末が盗難された場合に、盗難された端末を発見するのが困難であるという問題があった。
その対策として、特許文献１は、図１５に示すような盗難端末発見保護システム１５００を提案している。盗難端末発見保護システム１５００は、端末１５０１と、アクセスポイント１５０２と、ネットワーク装置１５０３と、管理装置１５０４とから構成されている。端末１５０１が盗難された場合、予め、端末１５０１に固有の端末識別子をネットワーク装置１５０３に登録しておく。その後、端末１５０１がネットワークに接続されると、端末１５０１に搭載されたプログラムが起動されて、端末１５０１は端末識別子を最寄のアクセスポイント１５０２へ送信する。アクセスポイント１５０２は、アクセスポイント１５０２を特定するアクセスポイント識別子を端末識別子に付加してネットワーク装置１５０３へ送信する。ネットワーク装置１５０３は、端末識別子の登録の有無により、送信元の端末が盗難されたものか否かを判断する。盗難された端末ではないと判断されると、ネットワーク装置１５０３は、ネットワーク識別子を取得し、アクセスポイント１５０２を介して端末１５０１へ送信する。
その対策として、特許文献１は、図１５に示すような盗難端末発見保護システム１５００を提案している。盗難端末発見保護システム１５００は、端末１５０１と、アクセスポイント１５０２と、ネットワーク装置１５０３と、管理装置１５０４とから構成されている。端末１５０１が盗難された場合、予め、端末１５０１に固有の端末識別子をネットワーク装置１５０３に登録しておく。その後、端末１５０１がネットワークに接続されると、端末１５０１に搭載されたプログラムが起動されて、端末１５０１は端末識別子を最寄のアクセスポイント１５０２へ送信する。アクセスポイント１５０２は、アクセスポイント１５０２を特定するアクセスポイント識別子を端末識別子に付加してネットワーク装置１５０３へ送信する。ネットワーク装置１５０３は、端末識別子の登録の有無により、送信元の端末が盗難されたものか否かを判断する。盗難された端末ではないと判断されると、ネットワーク装置１５０３は、ネットワーク識別子を取得し、アクセスポイント１５０２を介して端末１５０１へ送信する。
しかしながら、関連する盗難端末発見保護システムでは、盗難された端末（盗難端末）が接続されるアクセスポイントと同じネットワーク上にネットワーク装置が存在している場合にしか盗難端末を発見することができない。盗難端末がどのネットワーク上で不正使用されるかを予測することは不可能である。そのため、関連する盗難端末発見保護システムでは、盗難端末が不正使用されるネットワーク上の全てに予めネットワーク装置を設け、盗難端末がどのネットワーク上で不正使用されても発見できるようにすることは不可能であった。また、関連する盗難端末発見保護システムでは、たとえ、ネットワーク装置が設けられたネットワーク上で盗難端末が不正使用された場合であっても、ネットワーク装置へのアクセス制限が盗難端末にかけられているような場合には、盗難端末を発見することはできなかった。本発明の目的は、上記課題に鑑み、盗難等によって不正使用されている端末が、自端末の属するネットワーク以外のどのネットワークに接続された場合でも、盗難等によって不正使用されていることを認識することが可能な端末発見システムを提供することである。
本発明の第１の情報処理装置は、所定情報を含むホスト名による外部からの名前解決依頼により、特定の端末が外部ネットワークに接続されたことを検出する制御手段を備えたことを特徴とする。
本発明の第１の端末発見方法は、所定情報を含むホスト名による外部からの名前解決依頼により、特定の端末が外部ネットワークに接続されたことを検出することを特徴とする。
本発明の第１の端末発見システムは、ネットワークを介して端末と情報処理装置とが接続された端末発見システムにおいて、端末は、所定のタイミングで、所定情報を含むホスト名の名前解決を情報処理装置に依頼し、情報処理装置は、所定情報を含むホスト名による外部からの名前解決依頼により、特定の端末が外部ネットワークに接続されたことを検出することを特徴とする。
本発明の第１の端末は、ネットワークを介して情報処理装置と接続された端末において、所定のタイミングで、所定情報を含むホスト名の名前解決を情報処理装置に依頼する制御手段を備えることを特徴とする。
本発明の第１の端末における方法は、ネットワークを介して情報処理装置と接続され、所定情報を含むホスト名の情報を備えた端末における方法において、所定のタイミングで所定情報を含むホスト名の名前解決を情報処理装置に依頼するステップを有することを特徴とする。
本発明の第１のプログラムは、ネットワークを介して情報処理装置と接続された端末に実行させるプログラムにおいて、所定のタイミングで所定情報を含むホスト名の名前解決を情報処理装置に依頼する処理を実行させることを特徴とする。
本発明の第１の端末発見方法は、所定情報を含むホスト名による外部からの名前解決依頼により、特定の端末が外部ネットワークに接続されたことを検出することを特徴とする。
本発明の第１の端末発見システムは、ネットワークを介して端末と情報処理装置とが接続された端末発見システムにおいて、端末は、所定のタイミングで、所定情報を含むホスト名の名前解決を情報処理装置に依頼し、情報処理装置は、所定情報を含むホスト名による外部からの名前解決依頼により、特定の端末が外部ネットワークに接続されたことを検出することを特徴とする。
本発明の第１の端末は、ネットワークを介して情報処理装置と接続された端末において、所定のタイミングで、所定情報を含むホスト名の名前解決を情報処理装置に依頼する制御手段を備えることを特徴とする。
本発明の第１の端末における方法は、ネットワークを介して情報処理装置と接続され、所定情報を含むホスト名の情報を備えた端末における方法において、所定のタイミングで所定情報を含むホスト名の名前解決を情報処理装置に依頼するステップを有することを特徴とする。
本発明の第１のプログラムは、ネットワークを介して情報処理装置と接続された端末に実行させるプログラムにおいて、所定のタイミングで所定情報を含むホスト名の名前解決を情報処理装置に依頼する処理を実行させることを特徴とする。
本発明の端末発見システムによれば、盗難等によって不正使用されている端末が自端末の属するネットワーク以外のどのネットワークに接続された場合でも、盗難等によって不正使用されていること認識することができる。
次に、本発明の実施例について図面を参照して詳細に説明する。
本発明の端末発見システムにおける第１の実施例について説明する。第１の実施例では、端末の不正使用の一形態として盗難された場合について説明する。また、端末としてパーソナルコンピュータ（ＰＣ）が使用された場合を例に挙げて説明する。
図１はＰＣが盗難される前の端末発見システムの状態を示す図である。図２はＰＣが盗難された後の端末発見システムの状態を示す図である。
端末発見システムは、ＰＣおよび通知先サーバ１２０により構成される。盗難される前のＰＣを盗難前ＰＣ１１１と呼び、盗難された後のＰＣを盗難後ＰＣ１１２と呼ぶことにする。盗難前ＰＣ１１１は、図１のように、通知先サーバ１２０が属するネットワークと同じネットワーク内で使用されるものと想定する。例えば、盗難前ＰＣ１１１は通知先サーバ１２０が属するイントラネット内でのみ使用される。盗難後ＰＣ１１２は、図２のように、通知先サーバ１２０が属するネットワークとは異なるネットワーク上で使用されるものと想定する。
ＰＣ（盗難前ＰＣ１１１および盗難後ＰＣ１１２)は、通信部１１３と制御手段としてのＣＰＵ１１４と記憶部１１５と入力部１１６とから構成される。
ＰＣのＣＰＵ１１４は、所定情報を含むホスト名を生成して記憶部１１５に記憶する。所定情報とは、ドメイン部の前に設けられる文字列のことであり、端末発見システムで管理するＰＣに対して一意に決定される。例えば、IamPCを所定情報としnec.co.jpをドメイン部とした場合、所定情報を含むホスト名はIamPC.nec.co.jpとなる。所定情報は管理するＰＣに対して付与される文字列であるため、所定情報を含むホスト名に対応するアドレスはネットワーク上に存在しない。所定情報を含むホスト名は、予め生成され、名前解決情報１２４に格納される。所定情報を含むホスト名はＰＣが自動的に生成する構成にしても良いし、ユーザ等が作成する構成にしても良い。所定情報を含むホスト名が生成されると、ＣＰＵ１１０は、所定のタイミングで記憶部１１５から所定情報を含むホスト名を読み出し、通信部１１３を介して通知先サーバ１２０に送信し、所定情報を含むホスト名の名前解決（ホスト名に対応するアドレスの情報を取得すること）を依頼する。所定のタイミングは、ＰＣの起動時としても良いし、予め決められた時間間隔（定期的）としても良い。所定情報を含むホスト名の名前解決が依頼されるタイミングは、これらに限定されない。
通知先サーバ１２０は、通信部１２１とＣＰＵ１２２と記憶部１２３とから構成される。例えば、通知先サーバはＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍサーバ（ＤＮＳサーバ）であり、特定のドメインサーバとして動作している。なお、通知先サーバ１２０はＤＮＳサーバに限定されず、同様の機能を有する情報処理装置であれば何でも良い。
通知先サーバ１２０の記憶部１２３には、ホスト名とアドレスとが対応付けられた名前解決情報１２４が格納されている。ＣＰＵ１２２は、通信部１２１を介して所定情報を含むホスト名を受け取ると、受け取った所定情報を含むホスト名を名前解決情報１２４に格納する。
図３に名前解決情報１２４の具体例を示す。名前解決情報１２４は、ホスト名のフィールド３００およびアドレス名のフィールド３１０から構成される。名前解決可能なホスト名に対しては、ホスト名に対応するアドレスがアドレス名のフィールド３１０に格納されている。所定情報を含むホスト名については、対応するアドレスがネットワーク上に存在しないため、所定情報を含むホスト名に対応するアドレス名のフィールド３１０には何も格納されず空となっている。
図３を参照して、通知先サーバ１２０がnec.co.jpドメインサーバとして動作し、所定情報を含むホスト名としてIamPC.nec.co.jpが生成された場合の名前解決情報１２４について説明する。ホスト名のフィールド３００には、ドメイン部としてnec.co.jpを含む以下の５つのホスト名（abvde.nec.co.jpとfghigk.nec.co.jpとlmnop.nec.co.jpとqrstuv.nec.co.jpとIamPC.nec.co.jp）が格納されている。５つのホスト名のうち、IamPC.nec.co.jpのみが所定情報（IamPC）を含むホスト名であり名前解決できないホスト名である。その他は名前解決が可能なホスト名である。IamPC.nec.co.jpに対応するアドレスはネットワーク上に存在しないため、IamPC.nec.co.jpに対応するアドレス名のフィールド３１０は空となっている。その他のホスト名に対応するアドレス名のフィールド３１０には、各ホスト名に対応するアドレスが格納されている。ここでは、アドレスとしてIPアドレスを例に挙げているが、これに限定されない。
通知先サーバ１２０のＣＰＵ１２２は、ＰＣから名前解決の依頼を受けると、名前解決情報１２４を参照し、依頼されたホスト名が格納されているかを判断する。依頼されたホスト名が格納されていない場合には当該ホスト名は通知先サーバ１２０自身が管理しているホスト名ではないことを意味している。そのため、依頼されたホスト名が格納されていない場合には、ＣＰＵ１２２は、当該ホスト名の名前解決に失敗した旨をＰＣへ通知する。
一方、依頼されたホスト名が格納されている場合には、当該ホスト名は通知先サーバ１２０自身が管理しているホスト名であることを意味している。そのため、次に、ＣＰＵ１２２は、ホスト名に対応するアドレス名が名前解決情報１２４に格納されているかを判断する。依頼されたホスト名に対応するアドレス名が格納されていれば、当該ホスト名は名前解決可能なホスト名であることを意味しており、ＣＰＵ１２２は、ホスト名に対応するアドレスを読み出し、通信部１２１を介して読み出されたアドレスをＰＣに送信する。一方、依頼されたホスト名に対応するアドレス名が格納されていなければ、当該ホスト名は所定情報を含むホスト名であることを意味している。そのため、次に、ＣＰＵ１２２は、通知先サーバ１２０が属するネットワーク以外のネットワークに属するＰＣからの名前解決の依頼か（外部ネットワークからの依頼か）を判断する。第１の実施例では、ＰＣは、通知先サーバ１２０と同じネットワーク上（通知先サーバ１２０が属するイントラネット内など）で使用され、PCが盗難等により不正使用された場合のみ外部ネットワークに接続されると想定している。そのため、同じネットワーク上のＰＣからの名前解決の依頼ならば、ＣＰＵ１２２は、名前解決を依頼したＰＣは盗難されたものではないと判断することができる。一方、外部ネットワークからの依頼ならば、ＣＰＵ１２２は、名前解決を依頼したＰＣは盗難されたＰＣであると判断することができる。
第１の実施例の概略図を図４に示す。第１の実施例では、盗難前PC１１１はネットワーク１に接続され、盗難後PC１１２はネットワーク２に接続されている。DNSサーバ４００はキャッシュ機能を有しており、ネットワーク２上に存在する。そして、DNSサーバ４００はネットワークを介してルートドメインサーバ４１０とjpドメインサーバ４２０とco.jpドメインサーバ４３０とに接続されている。通知先サーバ１２０はネットワーク１上に存在する。
ここでは、ＰＣは盗難された後、ネットワーク１とは異なるネットワーク２上で不正に使用されているものと想定する。そして、通知先サーバ１２０はnec.co.jpドメインサーバとして動作し、所定情報を含むホスト名はIamPC.nec.co.jpであると想定する。
盗難後PC１１２は、DNSサーバ４００の情報を取得し、DNSサーバ４００にIamPC.nec.co.jpの名前解決を依頼する。DNSサーバ４００ではIamPC.nec.co.jp の名前解決をすることができないため、DNSサーバ４００は外部のＤＮＳサーバに問い合わせ（リゾルバ動作）を行う。一般的なDNSの仕組みを利用して、ルートドメインサーバ４１０、jpドメインサーバ４２０、co.jpドメインサーバ４３０、通知先サーバ１２０の順で問い合わせが行われる。
図５に端末発見システムのフローチャートを示す。
ＰＣのＣＰＵ１１４は、所定情報を含むホスト名を生成し、記憶部１１５に格納する（Ｓ５００）。ＰＣのＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ５０１）。所定のタイミングになったと判断されると、ＰＣのＣＰＵ１１４は、DNSサーバ４００の情報を取得し（Ｓ５０２）、DNSサーバ４００に所定情報を含むホスト名の名前解決を依頼する（Ｓ５０３）。
DNSサーバ４００は、ＰＣから名前解決の依頼を受けると（Ｓ５０４）、依頼されたホスト名について自DNSサーバ４００で名前解決可能か否かを判断する（Ｓ５０５）。自DNSサーバ４００で解決できないと判断すると、他のＤＮＳサーバに問い合わせ（S５０６）、他のＤＮＳサーバからの返答を待つ。一方、自DNSサーバ４００で解決できると判断すると、DNSサーバ４００は所定情報を含むホスト名に対応するアドレス名を読み出し（Ｓ５０７）、依頼元のＰＣに返答する（Ｓ５０８、Ｓ５０９）。
通知先サーバ１２０のＣＰＵ１２２は、DNSサーバ４００から所定情報を含むホスト名の名前解決が依頼されると（Ｓ５１０）、名前解決情報１２４を参照し（Ｓ５１１）、依頼されたホスト名が名前解決情報１２４に格納されている情報か否かを判断する（Ｓ５１２）。依頼されたホスト名が格納されていない場合には、通知先サーバ１２０のＣＰＵ１２２はDNSサーバ４００を介して名前解決の失敗を依頼元のＰＣに通知する（Ｓ５１３、Ｓ５１４、Ｓ５１５）。依頼されたホスト名が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４を参照し、依頼されたホスト名に対応するアドレス名が格納されているか否かを判断する（Ｓ５１６）。ホスト名に対応するアドレス名が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４からアドレス名を読み出し（Ｓ５１７）、DNSサーバ４００を介して依頼元のＰＣに返答する（Ｓ５１８、Ｓ５１９、Ｓ５２０）。一方、ホスト名に対応するアドレス名が格納されていない場合には、ＣＰＵ１２２は、通知先サーバ１２０の属するネットワーク１以外のネットワーク（外部ネットワーク）からの依頼か否かを判断する（Ｓ５２１）。外部ネットワークからの依頼と判断された場合には、ＣＰＵ１２２は、盗難されたＰＣからの依頼と認識することができる（Ｓ５２２）。一方、外部ネットワークからの依頼ではないと判断された場合には、ＣＰＵ１２２は、依頼元のＰＣは盗難されたものではないと認識することができる（Ｓ５２３）。
次に、名前解決を依頼されたホスト名がIamPC.nec.co.jp（所定情報を含むホスト名）の場合のフローチャートについて説明する。名前解決情報１２４は図３のようになっていると想定する。
端末のＣＰＵ１１４は、IamPC.nec.co.jpを生成し、記憶部１１５に格納する（Ｓ５００）。ＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ５０１）。所定のタイミングになったと判断されると、ＣＰＵ１１４は、DNSサーバ４００の情報を取得し（Ｓ５０２）、DNSサーバ４００にIamPC.nec.co.jpの名前解決を依頼する（Ｓ５０３）。
DNSサーバ４００は、IamPC.nec.co.jpの名前解決の依頼を受けると（Ｓ５０４）、自サーバ（DNSサーバ４００）で名前解決が可能か否かを判断する（Ｓ５０５）。IamPC.nec.co.jpは自サーバ（DNSサーバ４００）で名前解決できないため、他のＤＮＳサーバに問い合わせ（Ｓ５０６）、他のＤＮＳサーバからの返答を待つ。
通知先サーバ１２０のCPU１２２は、DNSサーバ４００からIamPC.nec.co.jpの名前解決が依頼されると（Ｓ５１０）、名前解決情報１２４を参照し（Ｓ５１１）、IamPC.nec.co.jpが名前解決情報１２４に格納されているか否かを判断する（Ｓ５１２）。図２のように、名前解決情報１２４のホスト名のフィールド３００にはIamPC.nec.co.jpが格納されているので、ＣＰＵ１２２は、IamPC.nec.co.jpに対応するアドレス名が格納されているか否かを判断する（Ｓ５１６）。図３のように、名前解決情報１２４にはIamPC.nec.co.jpに対応するアドレス名は格納されていないため、ＣＰＵ１２２は、IamPC.nec.co.jpの名前解決は外部ネットワークからの依頼かを判断する（Ｓ５２１）。外部ネットワークからの依頼であるため、ＣＰＵ１２２は、盗難されたＰＣからの依頼と認識することができる（Ｓ５２２）。
なお、第１の実施例では、端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第１の実施例を適用することができる。
以上説明したように、第１の実施例によれば、盗難等によって不正使用されている端末が自端末の属するネットワーク以外のどのネットワークに接続された場合でも、盗難等によって不正使用されていることを認識することが可能となる。たとえ、盗難等により不正使用されている端末が外部接続の制限されたネットワーク上にある場合でも、盗難等により不正使用されていることを認識することが可能となる。また、盗難等により不正使用されている端末の属するネットワークを予測することができる。なぜなら、通知先サーバはＤＮＳサーバのアドレスを特定することが可能であり、そして、盗難等により不正使用されている端末はDNSサーバの近傍にあると考えられるからである。
図１はＰＣが盗難される前の端末発見システムの状態を示す図である。図２はＰＣが盗難された後の端末発見システムの状態を示す図である。
端末発見システムは、ＰＣおよび通知先サーバ１２０により構成される。盗難される前のＰＣを盗難前ＰＣ１１１と呼び、盗難された後のＰＣを盗難後ＰＣ１１２と呼ぶことにする。盗難前ＰＣ１１１は、図１のように、通知先サーバ１２０が属するネットワークと同じネットワーク内で使用されるものと想定する。例えば、盗難前ＰＣ１１１は通知先サーバ１２０が属するイントラネット内でのみ使用される。盗難後ＰＣ１１２は、図２のように、通知先サーバ１２０が属するネットワークとは異なるネットワーク上で使用されるものと想定する。
ＰＣ（盗難前ＰＣ１１１および盗難後ＰＣ１１２)は、通信部１１３と制御手段としてのＣＰＵ１１４と記憶部１１５と入力部１１６とから構成される。
ＰＣのＣＰＵ１１４は、所定情報を含むホスト名を生成して記憶部１１５に記憶する。所定情報とは、ドメイン部の前に設けられる文字列のことであり、端末発見システムで管理するＰＣに対して一意に決定される。例えば、IamPCを所定情報としnec.co.jpをドメイン部とした場合、所定情報を含むホスト名はIamPC.nec.co.jpとなる。所定情報は管理するＰＣに対して付与される文字列であるため、所定情報を含むホスト名に対応するアドレスはネットワーク上に存在しない。所定情報を含むホスト名は、予め生成され、名前解決情報１２４に格納される。所定情報を含むホスト名はＰＣが自動的に生成する構成にしても良いし、ユーザ等が作成する構成にしても良い。所定情報を含むホスト名が生成されると、ＣＰＵ１１０は、所定のタイミングで記憶部１１５から所定情報を含むホスト名を読み出し、通信部１１３を介して通知先サーバ１２０に送信し、所定情報を含むホスト名の名前解決（ホスト名に対応するアドレスの情報を取得すること）を依頼する。所定のタイミングは、ＰＣの起動時としても良いし、予め決められた時間間隔（定期的）としても良い。所定情報を含むホスト名の名前解決が依頼されるタイミングは、これらに限定されない。
通知先サーバ１２０は、通信部１２１とＣＰＵ１２２と記憶部１２３とから構成される。例えば、通知先サーバはＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍサーバ（ＤＮＳサーバ）であり、特定のドメインサーバとして動作している。なお、通知先サーバ１２０はＤＮＳサーバに限定されず、同様の機能を有する情報処理装置であれば何でも良い。
通知先サーバ１２０の記憶部１２３には、ホスト名とアドレスとが対応付けられた名前解決情報１２４が格納されている。ＣＰＵ１２２は、通信部１２１を介して所定情報を含むホスト名を受け取ると、受け取った所定情報を含むホスト名を名前解決情報１２４に格納する。
図３に名前解決情報１２４の具体例を示す。名前解決情報１２４は、ホスト名のフィールド３００およびアドレス名のフィールド３１０から構成される。名前解決可能なホスト名に対しては、ホスト名に対応するアドレスがアドレス名のフィールド３１０に格納されている。所定情報を含むホスト名については、対応するアドレスがネットワーク上に存在しないため、所定情報を含むホスト名に対応するアドレス名のフィールド３１０には何も格納されず空となっている。
図３を参照して、通知先サーバ１２０がnec.co.jpドメインサーバとして動作し、所定情報を含むホスト名としてIamPC.nec.co.jpが生成された場合の名前解決情報１２４について説明する。ホスト名のフィールド３００には、ドメイン部としてnec.co.jpを含む以下の５つのホスト名（abvde.nec.co.jpとfghigk.nec.co.jpとlmnop.nec.co.jpとqrstuv.nec.co.jpとIamPC.nec.co.jp）が格納されている。５つのホスト名のうち、IamPC.nec.co.jpのみが所定情報（IamPC）を含むホスト名であり名前解決できないホスト名である。その他は名前解決が可能なホスト名である。IamPC.nec.co.jpに対応するアドレスはネットワーク上に存在しないため、IamPC.nec.co.jpに対応するアドレス名のフィールド３１０は空となっている。その他のホスト名に対応するアドレス名のフィールド３１０には、各ホスト名に対応するアドレスが格納されている。ここでは、アドレスとしてIPアドレスを例に挙げているが、これに限定されない。
通知先サーバ１２０のＣＰＵ１２２は、ＰＣから名前解決の依頼を受けると、名前解決情報１２４を参照し、依頼されたホスト名が格納されているかを判断する。依頼されたホスト名が格納されていない場合には当該ホスト名は通知先サーバ１２０自身が管理しているホスト名ではないことを意味している。そのため、依頼されたホスト名が格納されていない場合には、ＣＰＵ１２２は、当該ホスト名の名前解決に失敗した旨をＰＣへ通知する。
一方、依頼されたホスト名が格納されている場合には、当該ホスト名は通知先サーバ１２０自身が管理しているホスト名であることを意味している。そのため、次に、ＣＰＵ１２２は、ホスト名に対応するアドレス名が名前解決情報１２４に格納されているかを判断する。依頼されたホスト名に対応するアドレス名が格納されていれば、当該ホスト名は名前解決可能なホスト名であることを意味しており、ＣＰＵ１２２は、ホスト名に対応するアドレスを読み出し、通信部１２１を介して読み出されたアドレスをＰＣに送信する。一方、依頼されたホスト名に対応するアドレス名が格納されていなければ、当該ホスト名は所定情報を含むホスト名であることを意味している。そのため、次に、ＣＰＵ１２２は、通知先サーバ１２０が属するネットワーク以外のネットワークに属するＰＣからの名前解決の依頼か（外部ネットワークからの依頼か）を判断する。第１の実施例では、ＰＣは、通知先サーバ１２０と同じネットワーク上（通知先サーバ１２０が属するイントラネット内など）で使用され、PCが盗難等により不正使用された場合のみ外部ネットワークに接続されると想定している。そのため、同じネットワーク上のＰＣからの名前解決の依頼ならば、ＣＰＵ１２２は、名前解決を依頼したＰＣは盗難されたものではないと判断することができる。一方、外部ネットワークからの依頼ならば、ＣＰＵ１２２は、名前解決を依頼したＰＣは盗難されたＰＣであると判断することができる。
第１の実施例の概略図を図４に示す。第１の実施例では、盗難前PC１１１はネットワーク１に接続され、盗難後PC１１２はネットワーク２に接続されている。DNSサーバ４００はキャッシュ機能を有しており、ネットワーク２上に存在する。そして、DNSサーバ４００はネットワークを介してルートドメインサーバ４１０とjpドメインサーバ４２０とco.jpドメインサーバ４３０とに接続されている。通知先サーバ１２０はネットワーク１上に存在する。
ここでは、ＰＣは盗難された後、ネットワーク１とは異なるネットワーク２上で不正に使用されているものと想定する。そして、通知先サーバ１２０はnec.co.jpドメインサーバとして動作し、所定情報を含むホスト名はIamPC.nec.co.jpであると想定する。
盗難後PC１１２は、DNSサーバ４００の情報を取得し、DNSサーバ４００にIamPC.nec.co.jpの名前解決を依頼する。DNSサーバ４００ではIamPC.nec.co.jp の名前解決をすることができないため、DNSサーバ４００は外部のＤＮＳサーバに問い合わせ（リゾルバ動作）を行う。一般的なDNSの仕組みを利用して、ルートドメインサーバ４１０、jpドメインサーバ４２０、co.jpドメインサーバ４３０、通知先サーバ１２０の順で問い合わせが行われる。
図５に端末発見システムのフローチャートを示す。
ＰＣのＣＰＵ１１４は、所定情報を含むホスト名を生成し、記憶部１１５に格納する（Ｓ５００）。ＰＣのＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ５０１）。所定のタイミングになったと判断されると、ＰＣのＣＰＵ１１４は、DNSサーバ４００の情報を取得し（Ｓ５０２）、DNSサーバ４００に所定情報を含むホスト名の名前解決を依頼する（Ｓ５０３）。
DNSサーバ４００は、ＰＣから名前解決の依頼を受けると（Ｓ５０４）、依頼されたホスト名について自DNSサーバ４００で名前解決可能か否かを判断する（Ｓ５０５）。自DNSサーバ４００で解決できないと判断すると、他のＤＮＳサーバに問い合わせ（S５０６）、他のＤＮＳサーバからの返答を待つ。一方、自DNSサーバ４００で解決できると判断すると、DNSサーバ４００は所定情報を含むホスト名に対応するアドレス名を読み出し（Ｓ５０７）、依頼元のＰＣに返答する（Ｓ５０８、Ｓ５０９）。
通知先サーバ１２０のＣＰＵ１２２は、DNSサーバ４００から所定情報を含むホスト名の名前解決が依頼されると（Ｓ５１０）、名前解決情報１２４を参照し（Ｓ５１１）、依頼されたホスト名が名前解決情報１２４に格納されている情報か否かを判断する（Ｓ５１２）。依頼されたホスト名が格納されていない場合には、通知先サーバ１２０のＣＰＵ１２２はDNSサーバ４００を介して名前解決の失敗を依頼元のＰＣに通知する（Ｓ５１３、Ｓ５１４、Ｓ５１５）。依頼されたホスト名が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４を参照し、依頼されたホスト名に対応するアドレス名が格納されているか否かを判断する（Ｓ５１６）。ホスト名に対応するアドレス名が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４からアドレス名を読み出し（Ｓ５１７）、DNSサーバ４００を介して依頼元のＰＣに返答する（Ｓ５１８、Ｓ５１９、Ｓ５２０）。一方、ホスト名に対応するアドレス名が格納されていない場合には、ＣＰＵ１２２は、通知先サーバ１２０の属するネットワーク１以外のネットワーク（外部ネットワーク）からの依頼か否かを判断する（Ｓ５２１）。外部ネットワークからの依頼と判断された場合には、ＣＰＵ１２２は、盗難されたＰＣからの依頼と認識することができる（Ｓ５２２）。一方、外部ネットワークからの依頼ではないと判断された場合には、ＣＰＵ１２２は、依頼元のＰＣは盗難されたものではないと認識することができる（Ｓ５２３）。
次に、名前解決を依頼されたホスト名がIamPC.nec.co.jp（所定情報を含むホスト名）の場合のフローチャートについて説明する。名前解決情報１２４は図３のようになっていると想定する。
端末のＣＰＵ１１４は、IamPC.nec.co.jpを生成し、記憶部１１５に格納する（Ｓ５００）。ＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ５０１）。所定のタイミングになったと判断されると、ＣＰＵ１１４は、DNSサーバ４００の情報を取得し（Ｓ５０２）、DNSサーバ４００にIamPC.nec.co.jpの名前解決を依頼する（Ｓ５０３）。
DNSサーバ４００は、IamPC.nec.co.jpの名前解決の依頼を受けると（Ｓ５０４）、自サーバ（DNSサーバ４００）で名前解決が可能か否かを判断する（Ｓ５０５）。IamPC.nec.co.jpは自サーバ（DNSサーバ４００）で名前解決できないため、他のＤＮＳサーバに問い合わせ（Ｓ５０６）、他のＤＮＳサーバからの返答を待つ。
通知先サーバ１２０のCPU１２２は、DNSサーバ４００からIamPC.nec.co.jpの名前解決が依頼されると（Ｓ５１０）、名前解決情報１２４を参照し（Ｓ５１１）、IamPC.nec.co.jpが名前解決情報１２４に格納されているか否かを判断する（Ｓ５１２）。図２のように、名前解決情報１２４のホスト名のフィールド３００にはIamPC.nec.co.jpが格納されているので、ＣＰＵ１２２は、IamPC.nec.co.jpに対応するアドレス名が格納されているか否かを判断する（Ｓ５１６）。図３のように、名前解決情報１２４にはIamPC.nec.co.jpに対応するアドレス名は格納されていないため、ＣＰＵ１２２は、IamPC.nec.co.jpの名前解決は外部ネットワークからの依頼かを判断する（Ｓ５２１）。外部ネットワークからの依頼であるため、ＣＰＵ１２２は、盗難されたＰＣからの依頼と認識することができる（Ｓ５２２）。
なお、第１の実施例では、端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第１の実施例を適用することができる。
以上説明したように、第１の実施例によれば、盗難等によって不正使用されている端末が自端末の属するネットワーク以外のどのネットワークに接続された場合でも、盗難等によって不正使用されていることを認識することが可能となる。たとえ、盗難等により不正使用されている端末が外部接続の制限されたネットワーク上にある場合でも、盗難等により不正使用されていることを認識することが可能となる。また、盗難等により不正使用されている端末の属するネットワークを予測することができる。なぜなら、通知先サーバはＤＮＳサーバのアドレスを特定することが可能であり、そして、盗難等により不正使用されている端末はDNSサーバの近傍にあると考えられるからである。
次に、第２の実施例について説明する。
第１の実施例では、端末発見システムの管理下のＰＣに対して一意に所定情報を決定する構成としたため、通知先サーバ１２０は、端末が盗難されたことは認識できるものの盗難された端末を特定することはできなかった。
そこで、第２の実施例では、盗難等によって不正使用されている端末が自端末の属するネットワーク以外のどのネットワークに接続された場合でも、盗難等によって不正使用されている端末を特定（発見）できるようにする。
第２の実施例では、第１の実施例と同様、端末の不正使用の一形態として盗難された場合について説明する。また、端末としてパーソナルコンピュータ（ＰＣ）が使用された場合を例に挙げて説明する。
第２の実施例における端末発見システムの状態を示す図は、第１の実施例の図１および図２と同様である。ネットワークの接続関係も第１の実施例の図４と同様である。第２の実施例では、ホスト名に含まれる所定情報がＰＣの固有情報である点および名前解決情報１２４の内容および通知先サーバ１２０の判断方法が第１の実施例とは異なる。その他は第１の実施例と同様である。
第１の実施例では、端末発見システムの管理下のＰＣに対して一意に所定情報を決定する構成としたため、通知先サーバ１２０は、端末が盗難されたことは認識できるものの盗難された端末を特定することはできなかった。
そこで、第２の実施例では、盗難等によって不正使用されている端末が自端末の属するネットワーク以外のどのネットワークに接続された場合でも、盗難等によって不正使用されている端末を特定（発見）できるようにする。
第２の実施例では、第１の実施例と同様、端末の不正使用の一形態として盗難された場合について説明する。また、端末としてパーソナルコンピュータ（ＰＣ）が使用された場合を例に挙げて説明する。
第２の実施例における端末発見システムの状態を示す図は、第１の実施例の図１および図２と同様である。ネットワークの接続関係も第１の実施例の図４と同様である。第２の実施例では、ホスト名に含まれる所定情報がＰＣの固有情報である点および名前解決情報１２４の内容および通知先サーバ１２０の判断方法が第１の実施例とは異なる。その他は第１の実施例と同様である。
第２の実施例では、端末発見システムの管理するＰＣのそれぞれに対して、所定情報としてＰＣの固有情報を含むホスト名が生成される。所定情報とは、ドメイン部の前に設けられる文字列のことである。第２の実施例では、端末発見システムが４台のＰＣ１１３、１１４、１１５、１１６を管理していると想定する。例えば、ＰＣ１１３の固有情報がIamPC113でありドメイン部がnec.co.jpとすると、ＰＣ１１３では所定情報を含むホスト名としてIamPC113.nec.co.jpが生成される。同様にして、ＰＣ１１４ではIamPC114.nec.co.jpが生成され、ＰＣ１１５ではIamPC115.nec.co.jpが生成され、ＰＣ１１６ではIamPC116.nec.co.jpが生成される。第１の実施例と同様、所定情報を含むホスト名は予め生成され、名前解決情報１２４に格納される。所定情報を含むホスト名はＰＣが自動的に生成する構成にしても良いし、ユーザ等が作成する構成にしても良い。所定のタイミングになると、ＰＣ１１３、１１４、１１５、１１６は、生成されたホスト名の名前解決を依頼する。
図６に名前解決情報１２４の具体例を示す。第２の実施例の名前解決情報１２４では、ホスト名のフィールド３００およびアドレス名のフィールド３１０に加え、ＰＣ情報のフィールド３２０を有する。所定情報を含むホスト名に対応させてＰＣを特定する情報（ＰＣ情報）をＰＣ情報のフィールド３２０に格納する。名前解決可能なホスト名に対しては、ホスト名に対応するアドレスがアドレス名のフィールド３１０に格納されている。所定情報を含むホスト名については、対応するアドレスがネットワーク上に存在しないため、所定情報を含むホスト名に対応するアドレス名のフィールド３１０には何も格納されず空となっている。
図６を参照して、通知先サーバ１２０がnec.co.jpドメインサーバとして動作し、所定情報を含むホスト名としてIamPC113.nec.co.jpとIamPC114.nec.co.jpとIamPC115.nec.co.jpとIamPC116.nec.co.jpが生成された場合の名前解決情報１２４について説明する。
ホスト名のフィールド３００には、ドメイン部としてnec.co.jpを含む以下の８つのホスト名（abvde.nec.co.jpとfghigk.nec.co.jpとlmnop.nec.co.jpとqrstuv.nec.co.jpとIamPC113.nec.co.jpとIamPC114.nec.co.jpとIamPC115.nec.co.jpとIamPC116.nec.co.jp）が格納されている。８つのホスト名のうち、IamPC113.nec.co.jpとIamPC114.nec.co.jpとIamPC115.nec.co.jpとIamPC116.nec.co.jpは所定情報を含むホスト名であり、ＰＣ情報のフィールド３２０にPC情報が格納されている。そして、これらのホスト名に対応するアドレスはネットワーク上に存在しないため、対応するアドレス名のフィールド３１０は空となっている。一方、abvde.nec.co.jpとfghigk.nec.co.jpとlmnop.nec.co.jpとqrstuv.nec.co.jpは、名前解決可能なホスト名であるため、アドレス名のフィールド３１０には、各ホスト名に対応するアドレスが格納されている。ここでは、アドレスとしてIPアドレスを例に挙げているが、これに限定されない。
通知先サーバ１２０については、盗難PCからの依頼と認識された（図５のS５２２）後の動作が第１の実施例とは異なる。その他の動作は第１の実施例と同様である。第２の実施例では、通知先サーバ１２０は、名前解決の依頼元のPCが盗難されたものであると判断されると、名前解決情報１２４のＰＣ情報を参照して盗難されたPCを特定することができる。
図７に、第２の実施例における端末発見システムのフローチャートを示す。依頼元のＰＣの動作およびDNSサーバ４００の動作は第１の実施例と同様であるため、通知先サーバ１２０の動作についてのみ説明する。
通知先サーバ１２０のＣＰＵ１２２は、DNSサーバ４００からＰＣの固有情報を含むホスト名の名前解決が依頼されると（Ｓ５１０）、名前解決情報１２４を参照し（Ｓ５１１）、依頼されたホスト名が名前解決情報１２４に格納されている情報か否かを判断する（Ｓ５１２）。依頼されたホスト名が格納されていない場合には、ＣＰＵ１２２は、DNSサーバ４００を介して名前解決の失敗をＰＣに通知する（Ｓ５１３）。依頼されたホスト名が格納されている場合には、ＣＰＵ１２２は、依頼されたホスト名に対応するアドレス名が格納されているか否かを判断する（Ｓ５１６）。ホスト名に対応するアドレス名が格納されている場合には、ＣＰＵ１２２は、名前解決情報１２４からアドレス名を読み出し（Ｓ５１７）、DNSサーバ４００に返答する（Ｓ５１８）。一方、ホスト名に対応するアドレス名が格納されていない場合には、ＣＰＵ１２２は、通知先サーバ１２０の属するネットワーク１以外のネットワーク（外部ネットワーク）からの依頼か否かを判断する（Ｓ５２１）。外部ネットワークからの依頼と判断されると、ＣＰＵ１２２は、盗難されたＰＣからの依頼と認識する（Ｓ５２２）。そして、ＣＰＵ１２２は、名前解決情報１２４を参照し、盗難されたと認識したＰＣを特定することができる（Ｓ７００）。一方、外部ネットワークからの依頼ではないと判断されると、ＣＰＵ１２２は、依頼を行ったＰＣは盗難されたものではないと認識することができる（Ｓ５２３）。
次に、名前解決を依頼されたホスト名がIamPC113.nec.co.jp（所定情報を含むホスト名）の場合のフローチャートについて説明する。名前解決情報１２４は図６のようになっていると想定する。
通知先サーバ１２０のＣＰＵ１２２は、DNSサーバ４００から所定のタイミングでIamPC113.nec.co.jpの名前解決が依頼されると（Ｓ５１０）名前解決情報１２４を参照し（Ｓ５１１）、IamPC113.nec.co.jpが名前解決情報１２４に格納されているか否かを判断する（Ｓ５１２）。図３のように、名前解決情報１２４にはIamPC113nec.co.jpが格納されているので、ＣＰＵ１２２は、IamPC113.nec.co.jpに対応するアドレス名が格納されているか否かを判断する（Ｓ５１６）。図３のように、名前解決情報１２４にはIamPC113.nec.co.jpに対応するアドレス名は格納されていないため、ＣＰＵ１２２は、IamPC113.nec.co.jpの名前解決は外部ネットワークからの依頼かを判断する（Ｓ５２１）。外部ネットワークからの依頼であるため、ＣＰＵ１２２は、盗難されたＰＣからの依頼と認識する（Ｓ５２２）。そして、ＣＰＵ１２２は名前解決情報１２４を参照し、盗難されたPCはPC１１３であると特定することができる（S７００）。
なお、第１の実施例と同様、第２の実施例では、端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第２の実施例を適用することができる。
以上説明したように、第１の実施例によれば、盗難等によって不正使用されている端末が自端末の属するネットワーク以外のどのネットワークに接続された場合でも、盗難等によって不正使用されている端末を特定（発見）することが可能となる。
図６に名前解決情報１２４の具体例を示す。第２の実施例の名前解決情報１２４では、ホスト名のフィールド３００およびアドレス名のフィールド３１０に加え、ＰＣ情報のフィールド３２０を有する。所定情報を含むホスト名に対応させてＰＣを特定する情報（ＰＣ情報）をＰＣ情報のフィールド３２０に格納する。名前解決可能なホスト名に対しては、ホスト名に対応するアドレスがアドレス名のフィールド３１０に格納されている。所定情報を含むホスト名については、対応するアドレスがネットワーク上に存在しないため、所定情報を含むホスト名に対応するアドレス名のフィールド３１０には何も格納されず空となっている。
図６を参照して、通知先サーバ１２０がnec.co.jpドメインサーバとして動作し、所定情報を含むホスト名としてIamPC113.nec.co.jpとIamPC114.nec.co.jpとIamPC115.nec.co.jpとIamPC116.nec.co.jpが生成された場合の名前解決情報１２４について説明する。
ホスト名のフィールド３００には、ドメイン部としてnec.co.jpを含む以下の８つのホスト名（abvde.nec.co.jpとfghigk.nec.co.jpとlmnop.nec.co.jpとqrstuv.nec.co.jpとIamPC113.nec.co.jpとIamPC114.nec.co.jpとIamPC115.nec.co.jpとIamPC116.nec.co.jp）が格納されている。８つのホスト名のうち、IamPC113.nec.co.jpとIamPC114.nec.co.jpとIamPC115.nec.co.jpとIamPC116.nec.co.jpは所定情報を含むホスト名であり、ＰＣ情報のフィールド３２０にPC情報が格納されている。そして、これらのホスト名に対応するアドレスはネットワーク上に存在しないため、対応するアドレス名のフィールド３１０は空となっている。一方、abvde.nec.co.jpとfghigk.nec.co.jpとlmnop.nec.co.jpとqrstuv.nec.co.jpは、名前解決可能なホスト名であるため、アドレス名のフィールド３１０には、各ホスト名に対応するアドレスが格納されている。ここでは、アドレスとしてIPアドレスを例に挙げているが、これに限定されない。
通知先サーバ１２０については、盗難PCからの依頼と認識された（図５のS５２２）後の動作が第１の実施例とは異なる。その他の動作は第１の実施例と同様である。第２の実施例では、通知先サーバ１２０は、名前解決の依頼元のPCが盗難されたものであると判断されると、名前解決情報１２４のＰＣ情報を参照して盗難されたPCを特定することができる。
図７に、第２の実施例における端末発見システムのフローチャートを示す。依頼元のＰＣの動作およびDNSサーバ４００の動作は第１の実施例と同様であるため、通知先サーバ１２０の動作についてのみ説明する。
通知先サーバ１２０のＣＰＵ１２２は、DNSサーバ４００からＰＣの固有情報を含むホスト名の名前解決が依頼されると（Ｓ５１０）、名前解決情報１２４を参照し（Ｓ５１１）、依頼されたホスト名が名前解決情報１２４に格納されている情報か否かを判断する（Ｓ５１２）。依頼されたホスト名が格納されていない場合には、ＣＰＵ１２２は、DNSサーバ４００を介して名前解決の失敗をＰＣに通知する（Ｓ５１３）。依頼されたホスト名が格納されている場合には、ＣＰＵ１２２は、依頼されたホスト名に対応するアドレス名が格納されているか否かを判断する（Ｓ５１６）。ホスト名に対応するアドレス名が格納されている場合には、ＣＰＵ１２２は、名前解決情報１２４からアドレス名を読み出し（Ｓ５１７）、DNSサーバ４００に返答する（Ｓ５１８）。一方、ホスト名に対応するアドレス名が格納されていない場合には、ＣＰＵ１２２は、通知先サーバ１２０の属するネットワーク１以外のネットワーク（外部ネットワーク）からの依頼か否かを判断する（Ｓ５２１）。外部ネットワークからの依頼と判断されると、ＣＰＵ１２２は、盗難されたＰＣからの依頼と認識する（Ｓ５２２）。そして、ＣＰＵ１２２は、名前解決情報１２４を参照し、盗難されたと認識したＰＣを特定することができる（Ｓ７００）。一方、外部ネットワークからの依頼ではないと判断されると、ＣＰＵ１２２は、依頼を行ったＰＣは盗難されたものではないと認識することができる（Ｓ５２３）。
次に、名前解決を依頼されたホスト名がIamPC113.nec.co.jp（所定情報を含むホスト名）の場合のフローチャートについて説明する。名前解決情報１２４は図６のようになっていると想定する。
通知先サーバ１２０のＣＰＵ１２２は、DNSサーバ４００から所定のタイミングでIamPC113.nec.co.jpの名前解決が依頼されると（Ｓ５１０）名前解決情報１２４を参照し（Ｓ５１１）、IamPC113.nec.co.jpが名前解決情報１２４に格納されているか否かを判断する（Ｓ５１２）。図３のように、名前解決情報１２４にはIamPC113nec.co.jpが格納されているので、ＣＰＵ１２２は、IamPC113.nec.co.jpに対応するアドレス名が格納されているか否かを判断する（Ｓ５１６）。図３のように、名前解決情報１２４にはIamPC113.nec.co.jpに対応するアドレス名は格納されていないため、ＣＰＵ１２２は、IamPC113.nec.co.jpの名前解決は外部ネットワークからの依頼かを判断する（Ｓ５２１）。外部ネットワークからの依頼であるため、ＣＰＵ１２２は、盗難されたＰＣからの依頼と認識する（Ｓ５２２）。そして、ＣＰＵ１２２は名前解決情報１２４を参照し、盗難されたPCはPC１１３であると特定することができる（S７００）。
なお、第１の実施例と同様、第２の実施例では、端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第２の実施例を適用することができる。
以上説明したように、第１の実施例によれば、盗難等によって不正使用されている端末が自端末の属するネットワーク以外のどのネットワークに接続された場合でも、盗難等によって不正使用されている端末を特定（発見）することが可能となる。
次に、第３の実施例について説明する。
第２の実施例では、盗難等によって不正使用されている端末が自端末の属するネットワークに接続されている場合には端末を特定（発見）することはできなかった。
そこで、第３の実施例では、盗難等によって不正使用されている端末がどのネットワークに接続されている場合にも端末を特定（発見）することができるようにする。
第３の実施例では、第２の実施例と同様、端末の不正使用の一形態として盗難された場合について説明する。また、端末としてパーソナルコンピュータ（ＰＣ）が使用された場合を例に挙げて説明する。
第３の実施例では、盗難後ＰＣ１１２が自ＰＣの属するネットワークに接続された場合について説明する。盗難後ＰＣ１１２が外部ネットワークに接続された場合については第２の実施例と同様であるため、説明を省略する。
第３の実施例の名前解決情報１２４では、盗難されたことを示す情報が格納されている。PCが盗難されたことに気づいたユーザは、通知先サーバ３００にアクセスし、PCが盗難された旨を示す情報を名前解決情報１２４に格納する。
図８に名前解決情報１２４の具体例を示す。ここでは、PC１１３が盗難されたことに気づいたユーザにより、すでにその旨が書き換えられた場合について説明する。第３の実施例の名前解決情報１２４では、ホスト名のフィールド２００およびアドレス名のフィールド２１０およびＰＣ情報のフィールド２２０に加え、PCが盗難された旨を示すフラグ情報８００を有する。ホスト名のフィールド２００およびアドレス名のフィールド２１０およびＰＣ情報のフィールド２２０は第２の実施例と同様であり、フラグ情報８００を有する点のみが第２の実施例と異なる。第３の実施例の名前解決情報１２４では、端末発見システムが管理しているPC（PC１１３、１１４、１１５、１１６）に対してのみフラグ情報８００が格納されている。ここでは、ユーザが盗難を認識しているPC１１３に対応するフラグ情報７００のみがONとなっており、その他のPCのフラグ情報７００はOFFとなっている。
第３の実施例では、図９のようにネットワーク接続されている。盗難後PC１１２が自PCの属するネットワークに接続された場合を実線で示し、盗難後PC１１２が外部ネットワークに接続された場合を点線で示す。以下、盗難後PC１１２が自PCの属するネットワークに接続された場合のみ説明する。
通知先サーバ１２０は、盗難後PC１１２から所定情報を含むホスト名の名前解決の依頼を受けると、名前解決情報１２４を参照する。依頼されたホスト名に対応するフラグ情報８００がONとなっている場合には、通知先サーバ１２０は、ホスト名に対応するPCが盗難されていることを認識することができる。なお、盗難後PC１１２が外部ネットワークに接続された場合は第２の実施例と同様である。
第２の実施例では、盗難等によって不正使用されている端末が自端末の属するネットワークに接続されている場合には端末を特定（発見）することはできなかった。
そこで、第３の実施例では、盗難等によって不正使用されている端末がどのネットワークに接続されている場合にも端末を特定（発見）することができるようにする。
第３の実施例では、第２の実施例と同様、端末の不正使用の一形態として盗難された場合について説明する。また、端末としてパーソナルコンピュータ（ＰＣ）が使用された場合を例に挙げて説明する。
第３の実施例では、盗難後ＰＣ１１２が自ＰＣの属するネットワークに接続された場合について説明する。盗難後ＰＣ１１２が外部ネットワークに接続された場合については第２の実施例と同様であるため、説明を省略する。
第３の実施例の名前解決情報１２４では、盗難されたことを示す情報が格納されている。PCが盗難されたことに気づいたユーザは、通知先サーバ３００にアクセスし、PCが盗難された旨を示す情報を名前解決情報１２４に格納する。
図８に名前解決情報１２４の具体例を示す。ここでは、PC１１３が盗難されたことに気づいたユーザにより、すでにその旨が書き換えられた場合について説明する。第３の実施例の名前解決情報１２４では、ホスト名のフィールド２００およびアドレス名のフィールド２１０およびＰＣ情報のフィールド２２０に加え、PCが盗難された旨を示すフラグ情報８００を有する。ホスト名のフィールド２００およびアドレス名のフィールド２１０およびＰＣ情報のフィールド２２０は第２の実施例と同様であり、フラグ情報８００を有する点のみが第２の実施例と異なる。第３の実施例の名前解決情報１２４では、端末発見システムが管理しているPC（PC１１３、１１４、１１５、１１６）に対してのみフラグ情報８００が格納されている。ここでは、ユーザが盗難を認識しているPC１１３に対応するフラグ情報７００のみがONとなっており、その他のPCのフラグ情報７００はOFFとなっている。
第３の実施例では、図９のようにネットワーク接続されている。盗難後PC１１２が自PCの属するネットワークに接続された場合を実線で示し、盗難後PC１１２が外部ネットワークに接続された場合を点線で示す。以下、盗難後PC１１２が自PCの属するネットワークに接続された場合のみ説明する。
通知先サーバ１２０は、盗難後PC１１２から所定情報を含むホスト名の名前解決の依頼を受けると、名前解決情報１２４を参照する。依頼されたホスト名に対応するフラグ情報８００がONとなっている場合には、通知先サーバ１２０は、ホスト名に対応するPCが盗難されていることを認識することができる。なお、盗難後PC１１２が外部ネットワークに接続された場合は第２の実施例と同様である。
図１０に、第３の実施例における端末発見システムのフローチャートを示す。ここでは、盗難後PC１１２が自PCの属するネットワーク内で接続された場合のフローチャートのみを示す。盗難後ＰＣ１１２が外部ネットワークに接続された場合のフローチャートは、第２の実施例の図７と同様である。
ＰＣのＣＰＵ１１４は、所定情報を含むホスト名を生成し、記憶部１１５に格納する（Ｓ１０００）。ＰＣのＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ１００１）。所定のタイミングになったと判断されると、ＰＣのＣＰＵ１１４は、通知先サーバ１２０の情報を取得し（９０２）、通知先サーバ１２０に所定情報を含むホスト名の名前解決を依頼する（Ｓ１００３）。
通知先サーバ１２０のＣＰＵ１２２は、所定のタイミングでＰＣから所定情報を含むホスト名の名前解決が依頼されると（Ｓ１００４）、名前解決情報１２４を参照し（Ｓ１００５）、依頼されたホスト名が名前解決情報１２４に格納されているか否かを判断する（Ｓ１００６）。依頼されたホスト名が格納されていない場合には、通知先サーバ１２０は他のDNSサーバに問い合わせを行う（Ｓ１００７）。依頼されたホスト名が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４を参照し、依頼されたホスト名に対応するフラグ情報が格納されているか否かを判断する（Ｓ１００８）。ホスト名に対応するフラグ情報が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、フラグ情報がONか否かを判断する（Ｓ１００９）。フラグ情報がONの場合には、盗難されたPCからの依頼と認識し（Ｓ１０１０）、盗難されたPCを特定することができる（Ｓ１０１１）。一方、フラグ情報がOFFの場合には、盗難されていないと認識することができる（Ｓ１０１２）。一方、S１００８おいて、依頼されたホスト名に対応するフラグ情報が格納されていないと判断された場合には、ホスト名に対応するアドレスの情報が格納されているかを判断する（Ｓ１０１３）。アドレスが格納されていると判断された場合には、アドレスを読み出し（Ｓ１０１４）、依頼元のＰＣに返答する（Ｓ１０１５、Ｓ１０１６）。一方、依頼されたホスト名に対応するアドレスが格納されていないと判断された場合には、名前解決の失敗を依頼元のＰＣに通知する（Ｓ１０１７、Ｓ１０１８）。
ＰＣのＣＰＵ１１４は、所定情報を含むホスト名を生成し、記憶部１１５に格納する（Ｓ１０００）。ＰＣのＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ１００１）。所定のタイミングになったと判断されると、ＰＣのＣＰＵ１１４は、通知先サーバ１２０の情報を取得し（９０２）、通知先サーバ１２０に所定情報を含むホスト名の名前解決を依頼する（Ｓ１００３）。
通知先サーバ１２０のＣＰＵ１２２は、所定のタイミングでＰＣから所定情報を含むホスト名の名前解決が依頼されると（Ｓ１００４）、名前解決情報１２４を参照し（Ｓ１００５）、依頼されたホスト名が名前解決情報１２４に格納されているか否かを判断する（Ｓ１００６）。依頼されたホスト名が格納されていない場合には、通知先サーバ１２０は他のDNSサーバに問い合わせを行う（Ｓ１００７）。依頼されたホスト名が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４を参照し、依頼されたホスト名に対応するフラグ情報が格納されているか否かを判断する（Ｓ１００８）。ホスト名に対応するフラグ情報が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、フラグ情報がONか否かを判断する（Ｓ１００９）。フラグ情報がONの場合には、盗難されたPCからの依頼と認識し（Ｓ１０１０）、盗難されたPCを特定することができる（Ｓ１０１１）。一方、フラグ情報がOFFの場合には、盗難されていないと認識することができる（Ｓ１０１２）。一方、S１００８おいて、依頼されたホスト名に対応するフラグ情報が格納されていないと判断された場合には、ホスト名に対応するアドレスの情報が格納されているかを判断する（Ｓ１０１３）。アドレスが格納されていると判断された場合には、アドレスを読み出し（Ｓ１０１４）、依頼元のＰＣに返答する（Ｓ１０１５、Ｓ１０１６）。一方、依頼されたホスト名に対応するアドレスが格納されていないと判断された場合には、名前解決の失敗を依頼元のＰＣに通知する（Ｓ１０１７、Ｓ１０１８）。
次に、名前解決を依頼されたホスト名がIamPC113.nec.co.jp（所定情報を含むホスト名）の場合における通知先サーバ１２０のフローチャートについて説明する。名前解決情報１２４は図８のようになっていると想定する。
通知先サーバ１２０のＣＰＵ１２２は、ＰＣからIamPC113.nec.co.jpの名前解決が依頼されると（Ｓ１００４）、名前解決情報１２４を参照し（Ｓ１００５）、IamPC113.nec.co.jpが名前解決情報１２４に格納されている情報か否かを判断する（Ｓ１００６）。IamPC113.nec.co.jpは格納されているため、通知先サーバ１２０のＣＰＵ１２２は、依頼されたホスト名に対応するフラグ情報が格納されているか否かを判断する（Ｓ１００８）。IamPC113.nec.co.jpに対応するフラグ情報は格納されているため、フラグ情報がON か否かを判断する（Ｓ１００９）。フラグ情報がONであるため、通知先サーバ１２０のＣＰＵ１２２は、盗難されたPCからの依頼と認識し（Ｓ１０１０）、名前解決情報１２４を参照して盗難されたＰＣがＰＣ１１３であることを特定することができる（Ｓ１０１１）。
なお、第２の実施例と同様、第３の実施例では、端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第３の実施例を適用することができる。
以上説明したように、第３の実施例によれば、盗難等によって不正使用されている端末がどのネットワークに接続された場合でも、盗難等によって不正使用されている端末を特定（発見）することが可能となる。
通知先サーバ１２０のＣＰＵ１２２は、ＰＣからIamPC113.nec.co.jpの名前解決が依頼されると（Ｓ１００４）、名前解決情報１２４を参照し（Ｓ１００５）、IamPC113.nec.co.jpが名前解決情報１２４に格納されている情報か否かを判断する（Ｓ１００６）。IamPC113.nec.co.jpは格納されているため、通知先サーバ１２０のＣＰＵ１２２は、依頼されたホスト名に対応するフラグ情報が格納されているか否かを判断する（Ｓ１００８）。IamPC113.nec.co.jpに対応するフラグ情報は格納されているため、フラグ情報がON か否かを判断する（Ｓ１００９）。フラグ情報がONであるため、通知先サーバ１２０のＣＰＵ１２２は、盗難されたPCからの依頼と認識し（Ｓ１０１０）、名前解決情報１２４を参照して盗難されたＰＣがＰＣ１１３であることを特定することができる（Ｓ１０１１）。
なお、第２の実施例と同様、第３の実施例では、端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第３の実施例を適用することができる。
以上説明したように、第３の実施例によれば、盗難等によって不正使用されている端末がどのネットワークに接続された場合でも、盗難等によって不正使用されている端末を特定（発見）することが可能となる。
次に、第４の実施例について説明する。
第３の実施例では、盗難された端末を特定（発見）することはできたが、盗難された端末の使用を規制することはできなかった。
第３の実施例では、盗難された端末を特定（発見）することはできたが、盗難された端末の使用を規制することはできなかった。
そこで、第４の実施例では、盗難された端末に対して通知先サーバ１２０が規制を行えるようにする。
第４の実施例では、第３の実施例と同様、端末の不正使用の一形態として盗難された場合について説明する。また、端末としてパーソナルコンピュータ（ＰＣ）が使用された場合を例に挙げて説明する。
第４の実施例では、第３の実施例と同様、図９のようにネットワーク接続されている。第４の実施例においても、第３の実施例と同様、盗難前ＰＣ１１１は通知先サーバ１２０が属するネットワークと同じネットワーク内で使用されるものと想定する。例えば、盗難前ＰＣ１１１は通知先サーバが属するイントラネット内でのみ使用される。
図１１に、第４の実施例における端末発見システムのブロック図を示す。
通知先サーバ１２０は、通信部１２１とＣＰＵ１２２と記憶部１２３とから構成される。記憶部１２３には、ＰＣに対する規制指示の情報が格納された規制指示情報１１１０が格納されている。規制指示とは、ＰＣ内の情報の参照制限やＰＣ内の情報の削除等を示す。ＣＰＵ１２２は、第３の実施例と同様の方法で盗難されたＰＣを特定（発見）すると、規制指示情報１１１０を参照し、規制指示を読み出し、規制指示を含む応答を盗難されたＰＣへ返信する。規制指示情報１１１０には、所定の文字列等が格納されている。例えば、規制指示情報１１１０はabcdなどの文字列やＩＰアドレスなどである。規制指示情報１１１０はこれに限定されない。その他の構成は、第３の実施例と同様である。
ＰＣは、通信部１１３とＣＰＵ１１４と記憶部１１５と入力部１１６とから構成される。第４の実施例では、記憶部１１５には規制指示の変換情報１１２０が格納されている。規制指示の変換情報１１２０には、所定の文字列と規制指示を示す規制指示コマンドとを対応させた情報が格納されている。規制指示とは、ＰＣ内の情報の参照制限やＰＣ内の情報の削除等である。規制指示の変換情報１１２０では、abcdなどの文字列を規制指示コマンドに対応させるようにしても良いし、ＩＰアドレスを規制指示コマンドに対応させるようにしても良い。規制指示の内容および規制指示の変換情報１１２０はこれに限定されない。
ＣＰＵ１１４は、通知先サーバ１２０から規制指示を含む応答を受け取ると、規制指示の変換情報１１２０を参照して規制指示コマンドに変換を行い、自ＰＣに対して規制を行う。その他の構成は、第３の実施例と同様である。
規制指示を含む応答は、盗難後ＰＣ１１２が外部ネットワークに接続された場合には、DNSサーバ４００を介して盗難後ＰＣ１１２に送られる。盗難後ＰＣ１１２が外部ネットワークに接続された場合のDNSサーバ４００の動作について説明する。
DNSサーバ４００は、ＰＣから名前解決を依頼されると、依頼元のＰＣのアドレスを記憶部（図示しない）に格納しておき、通知先サーバ１２０に名前解決を依頼する。DNSサーバ４００は、通知先サーバ３００から規制指示を含む応答を受け取ると、どの名前解決に対する応答かを判断し、記憶部から対応するアドレスを読み出し、依頼元のＰＣに規制指示を含む応答を転送する。
図１２に、第４の実施例において盗難後PC１１２が外部ネットワークに接続された場合のフローチャートを示す。盗難されたPCを特定するまでの動作の流れは第３の実施例と同様である（通知先サーバ１２０の動作は図７のS７００まで同様であり、DNSサーバ４００の動作は図７のS５１９まで同様であり、ＰＣの動作は図７のS５２０まで同様である）ため、ここでは、盗難されたPCが特定された後のフローチャートについて説明する。
第４の実施例では、第３の実施例と同様、端末の不正使用の一形態として盗難された場合について説明する。また、端末としてパーソナルコンピュータ（ＰＣ）が使用された場合を例に挙げて説明する。
第４の実施例では、第３の実施例と同様、図９のようにネットワーク接続されている。第４の実施例においても、第３の実施例と同様、盗難前ＰＣ１１１は通知先サーバ１２０が属するネットワークと同じネットワーク内で使用されるものと想定する。例えば、盗難前ＰＣ１１１は通知先サーバが属するイントラネット内でのみ使用される。
図１１に、第４の実施例における端末発見システムのブロック図を示す。
通知先サーバ１２０は、通信部１２１とＣＰＵ１２２と記憶部１２３とから構成される。記憶部１２３には、ＰＣに対する規制指示の情報が格納された規制指示情報１１１０が格納されている。規制指示とは、ＰＣ内の情報の参照制限やＰＣ内の情報の削除等を示す。ＣＰＵ１２２は、第３の実施例と同様の方法で盗難されたＰＣを特定（発見）すると、規制指示情報１１１０を参照し、規制指示を読み出し、規制指示を含む応答を盗難されたＰＣへ返信する。規制指示情報１１１０には、所定の文字列等が格納されている。例えば、規制指示情報１１１０はabcdなどの文字列やＩＰアドレスなどである。規制指示情報１１１０はこれに限定されない。その他の構成は、第３の実施例と同様である。
ＰＣは、通信部１１３とＣＰＵ１１４と記憶部１１５と入力部１１６とから構成される。第４の実施例では、記憶部１１５には規制指示の変換情報１１２０が格納されている。規制指示の変換情報１１２０には、所定の文字列と規制指示を示す規制指示コマンドとを対応させた情報が格納されている。規制指示とは、ＰＣ内の情報の参照制限やＰＣ内の情報の削除等である。規制指示の変換情報１１２０では、abcdなどの文字列を規制指示コマンドに対応させるようにしても良いし、ＩＰアドレスを規制指示コマンドに対応させるようにしても良い。規制指示の内容および規制指示の変換情報１１２０はこれに限定されない。
ＣＰＵ１１４は、通知先サーバ１２０から規制指示を含む応答を受け取ると、規制指示の変換情報１１２０を参照して規制指示コマンドに変換を行い、自ＰＣに対して規制を行う。その他の構成は、第３の実施例と同様である。
規制指示を含む応答は、盗難後ＰＣ１１２が外部ネットワークに接続された場合には、DNSサーバ４００を介して盗難後ＰＣ１１２に送られる。盗難後ＰＣ１１２が外部ネットワークに接続された場合のDNSサーバ４００の動作について説明する。
DNSサーバ４００は、ＰＣから名前解決を依頼されると、依頼元のＰＣのアドレスを記憶部（図示しない）に格納しておき、通知先サーバ１２０に名前解決を依頼する。DNSサーバ４００は、通知先サーバ３００から規制指示を含む応答を受け取ると、どの名前解決に対する応答かを判断し、記憶部から対応するアドレスを読み出し、依頼元のＰＣに規制指示を含む応答を転送する。
図１２に、第４の実施例において盗難後PC１１２が外部ネットワークに接続された場合のフローチャートを示す。盗難されたPCを特定するまでの動作の流れは第３の実施例と同様である（通知先サーバ１２０の動作は図７のS７００まで同様であり、DNSサーバ４００の動作は図７のS５１９まで同様であり、ＰＣの動作は図７のS５２０まで同様である）ため、ここでは、盗難されたPCが特定された後のフローチャートについて説明する。
通知先サーバ１２０のＣＰＵ１２２は、盗難されたＰＣを特定すると、規制指示情報１１１０を参照して（Ｓ１２００）規制指示を読み出す（Ｓ１２０１）。そして、通知先サーバ１２０のＣＰＵ１２２は規制指示を含む応答をDNSサーバ４００を介してＰＣに送信する（Ｓ１２０２、S１２０３）。ＰＣのＣＰＵ１１４は、規制指示を含む応答を受信すると（Ｓ１２０４）、規制指示の変換情報１１２０を参照する（Ｓ１２０５）。ＰＣのＣＰＵ１１４は、規制指示コマンドを読み出し（Ｓ１２０６）、規制指示を行うことができる（Ｓ１２０７）。
図１３に、第４の実施例において盗難後PC１１２が自PCの属するネットワークに接続された場合のフローチャートを示す。盗難されたPCを特定するまでの流れは第３の実施例と同様である（通知先サーバ１２０の動作は図１０のS１０１１まで同様であり、ＰＣの動作は図１０のS１０１６まで同様である）ため、ここでは、盗難されたPCが特定された後の流れについて説明する。
図１３に、第４の実施例において盗難後PC１１２が自PCの属するネットワークに接続された場合のフローチャートを示す。盗難されたPCを特定するまでの流れは第３の実施例と同様である（通知先サーバ１２０の動作は図１０のS１０１１まで同様であり、ＰＣの動作は図１０のS１０１６まで同様である）ため、ここでは、盗難されたPCが特定された後の流れについて説明する。
通知先サーバ１２０のＣＰＵ１２２は、盗難されたＰＣを特定すると、規制指示情報１０１０を参照して（Ｓ１３００）、規制指示を読み出す（Ｓ１３０１）。そして、通知先サーバ１２０のＣＰＵ１２２は規制指示を含む応答をＰＣに送信する（Ｓ１３０２）。ＰＣのＣＰＵ１１４は、規制指示を含む応答を受信すると（Ｓ１３０３）、規制指示の変換情報１1２０を参照する（Ｓ１3０４）。ＰＣのＣＰＵ１１４は、規制指示コマンドを読み出し（Ｓ１3０５）、規制指示を行うことができる（Ｓ１3０６）。
なお、第３の実施例と同様、第４の実施例では端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第４の実施例を適用することができる。
以上説明したように、第４の実施例によれば、盗難等によって不正使用されている端末がどのネットワークに接続された場合でも、盗難等によって不正使用されている端末に対して規制を行うことが可能となり、端末内の情報漏洩等を防ぐことができる。
なお、第３の実施例と同様、第４の実施例では端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第４の実施例を適用することができる。
以上説明したように、第４の実施例によれば、盗難等によって不正使用されている端末がどのネットワークに接続された場合でも、盗難等によって不正使用されている端末に対して規制を行うことが可能となり、端末内の情報漏洩等を防ぐことができる。
次に、第５の実施例について説明する。
第４の実施例では、盗難後PC１１２が外部ネットワークに接続された場合には、名前解決の依頼はDNSサーバ４００を介して行われる。そのため、通知先サーバ１２０はDNSサーバ４００の位置は認識可能だが、依頼元のＰＣの位置は認識することができなかった。
第５の実施例では、通知先サーバ１２０が依頼元のＰＣの位置を認識できるようにする。
第５の実施例では、第４の実施例と同様、端末の不正使用の一形態として盗難された場合について説明する。また、端末としてパーソナルコンピュータ（ＰＣ）が使用された場合を例に挙げて説明する。
第５の実施例では、第４の実施例と同様、端末の不正使用の一形態として盗難された場合について説明する。また、端末としてパーソナルコンピュータ（ＰＣ）が使用された場合を例に挙げて説明する。
第５の実施例では、第４の実施例と同様、図９のようにネットワーク接続されている。第５の実施例では、ＰＣが定期的に自ＰＣのアドレス（ＩＰアドレスなど）を取得し、取得したアドレスをホスト名に含ませるようにする。所定情報を含むホスト名は、所定情報とドメイン部とから構成される。
例えば、ＰＣの固有情報の前にIPアドレスを付加した文字列を所定情報とする。IPアドレスが210.150.181.195でありＰＣの固有情報がIamPC113である場合には、所定情報は210.150.181.195IamPC113となる。さらにドメイン部がnec.co.jpならば、所定情報を含むホスト名は210.150.181.195IamPC 113.nec.co.jpとなる。
第５の実施例では、第４の実施例の図８と同様の名前解決情報１２４を備えている。通知先サーバ１２０のCPU１２２は、所定情報を含むホスト名の名前解決を依頼されると名前解決情報１２４を参照し、ホスト名のフィールド３００に格納されたホスト名と後方が一致するものがあるか否かを判断する。第４の実施例の図５のS５１２では依頼されたホスト名全体との完全一致を判断しているのに対して、第５の実施例では依頼されたホスト名の後方一致のみを判断している。第５の実施例では、盗難されたＰＣからの依頼と認識されると、依頼されたホスト名の後方一致部以外を読み出し、依頼元のＰＣの位置を特定することができる。
図１４に、第５の実施例のフローチャートを示す。
第５の実施例における規制指示の動作は第４の実施例と同様であるため説明を省略する。ここでは、所定情報を含むホスト名の名前解決が依頼されてから依頼元のＰＣを特定するまでのフローチャートについて説明する。
ＰＣのＣＰＵ１１４は、自ＰＣの位置情報を取得する（Ｓ１４００）。そして、自ＰＣの位置情報を含ませたホスト名を生成し、記憶部１１５に格納する（Ｓ１４０１）。ＰＣのＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ１４０２）。所定のタイミングになったと判断されると、ＰＣのＣＰＵ１１４は、通知先サーバ１２０の情報を取得し（１４０３）、通知先サーバ１２０にホスト名の名前解決を依頼する（Ｓ１４０４）。
通知先サーバ１２０のＣＰＵ１２２は、所定のタイミングでＰＣから所定情報を含むホスト名の名前解決が依頼されると（Ｓ１４０５）、名前解決情報１２４を参照し（Ｓ１４０６）、依頼されたホスト名と後方一致するホスト名が名前解決情報１２４に格納されているか否かを判断する（Ｓ１４０７）。依頼されたホスト名と後方一致するホスト名が格納されていない場合には、通知先サーバ１２０は他のDNSサーバに問い合わせを行う（Ｓ１４０８）。依頼されたホスト名と後方一致するホスト名が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４を参照し、後方一致したホスト名に対応するフラグ情報が格納されているか否かを判断する（Ｓ１４０９）。後方一致したホスト名に対応するフラグ情報が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、フラグ情報がONか否かを判断する（Ｓ１４１０）。フラグ情報がONの場合には、盗難されたPCからの依頼と認識し（Ｓ１４１１）、依頼されたホスト名のうち後方一致部以外を読み出す（Ｓ１４１２）。盗難されたPCの位置を特定することができる（Ｓ１４１３）。一方、フラグ情報がOFFの場合には、盗難されていないと認識することができる（Ｓ１４１４）。一方、S１４０９おいて、後方一致したホスト名に対応するフラグ情報が格納されていないと判断された場合には、後方一致したホスト名に対応するアドレスの情報が格納されているかを判断する（Ｓ１４１５）。アドレスが格納されていると判断された場合には、アドレスを読み出し（Ｓ１４１６）、依頼元のＰＣに返答する（Ｓ１４１７、Ｓ１４１８）。一方、後方一致したホスト名に対応するアドレスが格納されていないと判断された場合には、名前解決の失敗を依頼元のＰＣに通知する（Ｓ１４１９、Ｓ１４２０）。
次に、210.150.181.195IamPC113.nec.co.jp（ＰＣの位置情報が210.150.181.195であり、かつ、ＰＣの固有情報がIamPC113であり、かつドメイン部がnec.co.jpであるホスト名）の名前解決が依頼された場合のフローチャートについて説明する。名前解決情報１２４は図８のようになっていると想定する。
ＰＣのＣＰＵ１１４は、自ＰＣの位置情報として210.150.181.195を取得する（Ｓ１４００）。ＰＣの固有情報がIamPC113であるため、ＰＣのＣＰＵ１１４は、所定情報を含むホスト名として210.150.181.195IamPC113.nec.co.jpを生成し、記憶部１１５に格納する（Ｓ１４０１）。ＰＣのＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ１４０２）。所定のタイミングになったと判断されると、ＰＣのＣＰＵ１１４は、通知先サーバ１２０の情報を取得し（１４０３）、通知先サーバ１２０に210.150.181.195IamPC113.nec.co.jpの名前解決を依頼する（Ｓ１４０４）。
通知先サーバ１２０のＣＰＵ１２２は、所定のタイミングでＰＣから210.150.181.195IamPC 113.nec.co.jpの名前解決が依頼されると（Ｓ１４０５）、名前解決情報１２４を参照し（Ｓ１４０６）、210.150.181.195IamPC113.nec.co.jpと後方一致するホスト名が名前解決情報１２４に格納されているか否かを判断する（Ｓ１４０７）。名前解決情報１２４のホスト名のフィールド３００にはIamPC113.nec.co.jpが格納されているため、依頼されたホスト名と後方一致するホスト名が格納されていると判断する。そして、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４を参照し、後方一致したホスト名に対応するフラグ情報が格納されているか否かを判断する（Ｓ１４０９）。フラグ情報（ON）が格納されているため（Ｓ１４１０）、通知先サーバ１２０のＣＰＵ１２２は、盗難されたPCからの依頼と認識し（Ｓ１４１１）、依頼されたホスト名の後方一致部（IamPC113.nec.co.jp）以外として210.150.181.195を読み出す（Ｓ１４１２）。210.150.181.195は依頼元のPCのIPアドレスであり、通知先サーバ１２０のＣＰＵ１２２は、盗難されたPCの位置を特定することができる（Ｓ１４１３）。
なお、所定情報は、依頼元のＰＣのアドレスに限定されない。所定情報は、GPS情報など、依頼元のＰＣの位置が特定できる情報であれば何でも良い。
なお、第５の実施例と同様、第４の実施例では端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第５の実施例を適用することができる。
例えば、ＰＣの固有情報の前にIPアドレスを付加した文字列を所定情報とする。IPアドレスが210.150.181.195でありＰＣの固有情報がIamPC113である場合には、所定情報は210.150.181.195IamPC113となる。さらにドメイン部がnec.co.jpならば、所定情報を含むホスト名は210.150.181.195IamPC 113.nec.co.jpとなる。
第５の実施例では、第４の実施例の図８と同様の名前解決情報１２４を備えている。通知先サーバ１２０のCPU１２２は、所定情報を含むホスト名の名前解決を依頼されると名前解決情報１２４を参照し、ホスト名のフィールド３００に格納されたホスト名と後方が一致するものがあるか否かを判断する。第４の実施例の図５のS５１２では依頼されたホスト名全体との完全一致を判断しているのに対して、第５の実施例では依頼されたホスト名の後方一致のみを判断している。第５の実施例では、盗難されたＰＣからの依頼と認識されると、依頼されたホスト名の後方一致部以外を読み出し、依頼元のＰＣの位置を特定することができる。
図１４に、第５の実施例のフローチャートを示す。
第５の実施例における規制指示の動作は第４の実施例と同様であるため説明を省略する。ここでは、所定情報を含むホスト名の名前解決が依頼されてから依頼元のＰＣを特定するまでのフローチャートについて説明する。
ＰＣのＣＰＵ１１４は、自ＰＣの位置情報を取得する（Ｓ１４００）。そして、自ＰＣの位置情報を含ませたホスト名を生成し、記憶部１１５に格納する（Ｓ１４０１）。ＰＣのＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ１４０２）。所定のタイミングになったと判断されると、ＰＣのＣＰＵ１１４は、通知先サーバ１２０の情報を取得し（１４０３）、通知先サーバ１２０にホスト名の名前解決を依頼する（Ｓ１４０４）。
通知先サーバ１２０のＣＰＵ１２２は、所定のタイミングでＰＣから所定情報を含むホスト名の名前解決が依頼されると（Ｓ１４０５）、名前解決情報１２４を参照し（Ｓ１４０６）、依頼されたホスト名と後方一致するホスト名が名前解決情報１２４に格納されているか否かを判断する（Ｓ１４０７）。依頼されたホスト名と後方一致するホスト名が格納されていない場合には、通知先サーバ１２０は他のDNSサーバに問い合わせを行う（Ｓ１４０８）。依頼されたホスト名と後方一致するホスト名が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４を参照し、後方一致したホスト名に対応するフラグ情報が格納されているか否かを判断する（Ｓ１４０９）。後方一致したホスト名に対応するフラグ情報が格納されている場合には、通知先サーバ１２０のＣＰＵ１２２は、フラグ情報がONか否かを判断する（Ｓ１４１０）。フラグ情報がONの場合には、盗難されたPCからの依頼と認識し（Ｓ１４１１）、依頼されたホスト名のうち後方一致部以外を読み出す（Ｓ１４１２）。盗難されたPCの位置を特定することができる（Ｓ１４１３）。一方、フラグ情報がOFFの場合には、盗難されていないと認識することができる（Ｓ１４１４）。一方、S１４０９おいて、後方一致したホスト名に対応するフラグ情報が格納されていないと判断された場合には、後方一致したホスト名に対応するアドレスの情報が格納されているかを判断する（Ｓ１４１５）。アドレスが格納されていると判断された場合には、アドレスを読み出し（Ｓ１４１６）、依頼元のＰＣに返答する（Ｓ１４１７、Ｓ１４１８）。一方、後方一致したホスト名に対応するアドレスが格納されていないと判断された場合には、名前解決の失敗を依頼元のＰＣに通知する（Ｓ１４１９、Ｓ１４２０）。
次に、210.150.181.195IamPC113.nec.co.jp（ＰＣの位置情報が210.150.181.195であり、かつ、ＰＣの固有情報がIamPC113であり、かつドメイン部がnec.co.jpであるホスト名）の名前解決が依頼された場合のフローチャートについて説明する。名前解決情報１２４は図８のようになっていると想定する。
ＰＣのＣＰＵ１１４は、自ＰＣの位置情報として210.150.181.195を取得する（Ｓ１４００）。ＰＣの固有情報がIamPC113であるため、ＰＣのＣＰＵ１１４は、所定情報を含むホスト名として210.150.181.195IamPC113.nec.co.jpを生成し、記憶部１１５に格納する（Ｓ１４０１）。ＰＣのＣＰＵ１１４は、所定のタイミングになったか否かを判断する（Ｓ１４０２）。所定のタイミングになったと判断されると、ＰＣのＣＰＵ１１４は、通知先サーバ１２０の情報を取得し（１４０３）、通知先サーバ１２０に210.150.181.195IamPC113.nec.co.jpの名前解決を依頼する（Ｓ１４０４）。
通知先サーバ１２０のＣＰＵ１２２は、所定のタイミングでＰＣから210.150.181.195IamPC 113.nec.co.jpの名前解決が依頼されると（Ｓ１４０５）、名前解決情報１２４を参照し（Ｓ１４０６）、210.150.181.195IamPC113.nec.co.jpと後方一致するホスト名が名前解決情報１２４に格納されているか否かを判断する（Ｓ１４０７）。名前解決情報１２４のホスト名のフィールド３００にはIamPC113.nec.co.jpが格納されているため、依頼されたホスト名と後方一致するホスト名が格納されていると判断する。そして、通知先サーバ１２０のＣＰＵ１２２は、名前解決情報１２４を参照し、後方一致したホスト名に対応するフラグ情報が格納されているか否かを判断する（Ｓ１４０９）。フラグ情報（ON）が格納されているため（Ｓ１４１０）、通知先サーバ１２０のＣＰＵ１２２は、盗難されたPCからの依頼と認識し（Ｓ１４１１）、依頼されたホスト名の後方一致部（IamPC113.nec.co.jp）以外として210.150.181.195を読み出す（Ｓ１４１２）。210.150.181.195は依頼元のPCのIPアドレスであり、通知先サーバ１２０のＣＰＵ１２２は、盗難されたPCの位置を特定することができる（Ｓ１４１３）。
なお、所定情報は、依頼元のＰＣのアドレスに限定されない。所定情報は、GPS情報など、依頼元のＰＣの位置が特定できる情報であれば何でも良い。
なお、第５の実施例と同様、第４の実施例では端末が不正使用された一例としてＰＣが盗難された場合について説明したが、これに限られるものではない。例えば、特定のネットワークでしか使用されるはずのない端末を正規のユーザが他のネットワークで使用する場合等にも本発明の第５の実施例を適用することができる。
よって、第５の実施例では、通知先サーバ１２０が、盗難等により不正使用されているＰＣの位置を特定できるようになる。
１１１ 盗難前ＰＣ
１１２ 盗難後ＰＣ
１１３ 通信部
１１４ ＣＰＵ
１１５ 記憶部
１１６ 入力部
１２０ 通知先サーバ（nec.co.jpドメインサーバ）
１２１ 通信部
１２２ ＣＰＵ
１２３ 記憶部
１２４ 名前解決情報
３００ ホスト名のフィールド
３１０ アドレス名のフィールド
３２０ ＰＣ情報のフィールド
４００ ＤＮＳサーバ
４１０ ルートドメインサーバ
４２０ ｊｐドメインサーバ
４３０ co.jp.ドメインサーバ
１１１０ 規制指示情報
１１２０ 規制指示の変換情報
１５００ 端末発見保護システム
１５０１ 端末
１５０２ アクセスポイント
１５０３ ネットワーク装置
１５０４ 管理装置
１１２ 盗難後ＰＣ
１１３ 通信部
１１４ ＣＰＵ
１１５ 記憶部
１１６ 入力部
１２０ 通知先サーバ（nec.co.jpドメインサーバ）
１２１ 通信部
１２２ ＣＰＵ
１２３ 記憶部
１２４ 名前解決情報
３００ ホスト名のフィールド
３１０ アドレス名のフィールド
３２０ ＰＣ情報のフィールド
４００ ＤＮＳサーバ
４１０ ルートドメインサーバ
４２０ ｊｐドメインサーバ
４３０ co.jp.ドメインサーバ
１１１０ 規制指示情報
１１２０ 規制指示の変換情報
１５００ 端末発見保護システム
１５０１ 端末
１５０２ アクセスポイント
１５０３ ネットワーク装置
１５０４ 管理装置
Claims (14)
- 端末に対して一意に決定された所定情報を含むホスト名の名前解決を目的とした外部ネットワークからの名前解決依頼がされた場合に、前記端末が外部ネットワークに接続されたことを検出する制御手段を備えたことを特徴とする情報処理装置。
- 前記所定情報を含むホスト名が登録された名前解決情報が格納された記憶手段を備え、前記制御手段は、前記名前解決情報に基づいて、前記端末が外部ネットワークに接続されたか否かを判断することを特徴とする請求項１記載の情報処理装置。
- 前記所定情報は、自情報処理装置の管理する端末に対して一意に決定されていることを特徴とする請求項２記載の情報処理装置。
- 前記所定情報は、自情報処理装置の管理する端末ごとに固有の情報であることを特徴とする請求項３記載の情報処理装置。
- 前記所定情報には、前記端末のアドレスの情報が含まれることを特徴とする請求項４記載の情報処理装置。
- 前記名前解決情報には、自情報処理装置が名前解決可能なホスト名と当該ホスト名に対応するアドレスの情報が格納され、
前記制御手段は、前記名前解決可能なホスト名の名前解決が依頼されたとき、当該ホスト名に対応するアドレスの情報を依頼元に送信することを特徴とする請求項２ないし５のいずれか１項記載の情報処理装置。 - 前記制御手段は、前記端末が外部ネットワークに接続されたことを検出した場合、前記端末に対する規制指示を含む応答を依頼元に送信することを特徴とする請求項１ないし６のいずれか1項記載の情報処理装置。
- 前記規制指示を含む応答が特定の文字列であることを特徴とする請求項７記載の情報処理装置。
- 端末に対して一意に決定された所定情報を含むホスト名の名前解決を目的とした外部ネットワークからの名前解決依頼がされた場合に、前記端末が外部ネットワークに接続されたことを検出することを特徴とする端末発見方法。
- 前記所定情報を含むホスト名が登録された名前解決情報を備え、
前記名前解決情報に基づいて、前記端末が外部ネットワークに接続されたか否かを判断することを特徴とする請求項９記載の端末発見方法。 - 外部ネットワークに接続されたと判断された場合、前記端末に対する規制指示を含む応答を依頼元に送信することを特徴とする請求項９または１０記載の端末発見方法。
- ネットワークを介して端末と情報処理装置とが接続された端末発見システムにおいて、
前記端末は、所定のタイミングで、前記端末に一意に決定された所定情報を含むホスト名の名前解決を前記情報処理装置に依頼し、
前記情報処理装置は、前記所定情報を含むホスト名の名前解決を目的とした外部ネットワークからの名前解決依頼がされた場合に、前記端末が外部ネットワークに接続されたことを検出することを特徴とする端末発見システム。 - 前記情報処理装置は、前記所定情報を含むホスト名が登録された名前解決情報を備え、前記名前解決情報に基づいて前記端末が外部ネットワークに接続されたか否かを判断することを特徴とする請求項１２記載の端末発見システム。
- 前記情報処理装置は、前記端末に対する規制指示を含む応答を依頼元に送信し、
前記端末は、前記規制指示を含む応答を受信すると、前記規制指示に基づいて規制を行うことを特徴とする請求項１２または１３記載の端末発見システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007189313A JP5390079B2 (ja) | 2007-07-20 | 2007-07-20 | 端末発見システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007189313A JP5390079B2 (ja) | 2007-07-20 | 2007-07-20 | 端末発見システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009027504A JP2009027504A (ja) | 2009-02-05 |
| JP5390079B2 true JP5390079B2 (ja) | 2014-01-15 |
Family
ID=40398877
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007189313A Expired - Fee Related JP5390079B2 (ja) | 2007-07-20 | 2007-07-20 | 端末発見システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5390079B2 (ja) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6244758B1 (en) | 1994-11-15 | 2001-06-12 | Absolute Software Corp. | Apparatus and method for monitoring electronic devices via a global network |
| EP1041483A1 (en) | 1999-03-30 | 2000-10-04 | International Business Machines Corporation | Discovering stolen or lost network-attachable computer systems |
| JPWO2006011511A1 (ja) | 2004-07-28 | 2008-05-01 | オリエント測器コンピュータ株式会社 | 端末情報通知機能を備えたコンピュータシステムおよびコンピュータ |
| JP2007018081A (ja) * | 2005-07-05 | 2007-01-25 | Ttt Kk | ユーザ認証システム、ユーザ認証方法、ユーザ認証方法を実現するためのプログラム、及びプログラムを記憶した記憶媒体 |
-
2007
- 2007-07-20 JP JP2007189313A patent/JP5390079B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2009027504A (ja) | 2009-02-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20200374650A1 (en) | Obtaining user assistance | |
| JP4897813B2 (ja) | データ転送装置 | |
| JP5905019B2 (ja) | 印刷システム、印刷装置、印刷方法、及びプログラム | |
| US7987153B2 (en) | Apparatus and method for automatically migrating user's working data | |
| US20060161526A1 (en) | Obtaining user assistance | |
| JP2007048002A (ja) | 情報処理装置及びその制御方法、並びにコンピュータプログラム及びコンピュータ可読記憶媒体 | |
| US9069501B2 (en) | Mechanism that allows initiating print without being aware of the printer email address | |
| US20090204648A1 (en) | Tracking metadata for files to automate selective backup of applications and their associated data | |
| JP2012079170A (ja) | 表示装置、開示制御装置、開示制御方法、及びプログラム | |
| KR20160067769A (ko) | 라이센스 관리 방법 및 장치 | |
| US20100146390A1 (en) | Obtaining user assestance | |
| JP5390079B2 (ja) | 端末発見システム | |
| JP2010044519A (ja) | 利用者情報管理プログラム、情報管理プログラム、情報管理装置、利用者情報管理装置及び情報管理システム | |
| CN104360850B (zh) | 一种业务代码处理方法及装置 | |
| JP2008191740A (ja) | 中継装置、中継方法、及び、プログラム | |
| JP4962050B2 (ja) | 情報受け渡し装置、方法、プログラム及び記憶媒体 | |
| JP2008204277A (ja) | 印刷用プログラム及びプリンタ | |
| JP4689635B2 (ja) | メタデータ管理方法、メタデータ管理システム、及び、メタデータ管理プログラム | |
| JP2010224729A (ja) | 情報処理装置、ネットワーク設定方法、及びプログラム | |
| JP2007288410A (ja) | 情報処理装置、データ処理方法、記憶媒体、プログラム | |
| RU2658875C1 (ru) | Способ и сервер для определения порядка отрисовки карты | |
| JP5089744B2 (ja) | 情報処理装置及びその制御方法、並びにコンピュータプログラム | |
| JP4764149B2 (ja) | データ転送方法及び情報処理装置 | |
| JP2010086203A (ja) | アドレス対応付け方法、アドレス対応付けプログラム及び装置 | |
| US20110153800A1 (en) | Identity sharing method and apparatus in mobile computing environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20090513 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100611 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20110705 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110929 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120522 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120719 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120814 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20121114 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20121122 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20121221 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130819 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131010 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |