(57)【要約】      （修正有）【課題】インターネットのログインシステムを不正なアクセスから防御する。【解決手段】Ｗｅｂページ画面の表示を制御することによって、画面上のコンテンツ情報をいっさい消去し、閲覧そのものができなくする「表示済ＵＲＬの自動廃棄処理」を行う。すなわち、利用者が一旦画面を表示した〔ＵＲＬ〕を他者（ミラー・ブラウザー実行者等のクラッカー）に利用不可能にする。クラッカーがスパイ行為をするには、利用者が実行した〔ＵＲＬ〕を手掛かりにして、後追いで画面表示する方法しかない。そこで表示済ＵＲＬの画面を後追いで表示しても、瞬時に白紙化状態にする仕組みを設けることで、ミラー・ブラウザーによる「悪意の情報収集」を遮断すれば、同時にそれは「情報漏洩」も遮断できる。【選択図】なし【特許請求の範囲】
【請求項１】
前記のような時間のズレを応用することによって、秒遅れの〔ＵＲＬ〕でアクセスしても画面表示ができない（白紙化状態）ことから、〔ＵＲＬ〕が自動廃棄される仕組みとなること、及び当該仕組みはＰＯＳT・ＧＥＴパラメーターに兼用できることを特徴とする表示済ＵＲＬの自動廃棄処理技術のうち「時間のズレ応用技術」。
【請求項２】
前記のようなカレント性媒体に記録したデータを「存在」又は「不存在」と判定することによって、ブラウザー画面を表示又は不表示（もしくはその逆）に制御することを特徴とする表示済ＵＲＬの自動廃棄処理技術のうち「データの移動応用技術」。
【請求項３】
前記のような随伴現象を露見・顕在化させる手段並び利用者のノンストレス、ノンストップな機能・利便性を具備した並列処理が可能なことを特徴とする表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」。
【請求項４】
前記のような適宜な数字を結合化したＩＰアドレスと原本ＩＰアドレス、もしくは異なる「結合ＩＰアドレス」同士を各自対峙させ、これによって不一致を誘導する仕組みとすることで重複化したＩＰアドレスの検出を可能にし、並びにステップの移動時にこれが行えるので「ＯＵＴ」時データの真偽検証用途にも応用できることを特徴とする表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」。
【請求項５】
「随伴現象」を露見・顕在化させる単純・単一の仕組みなので、応用範囲としてソフト面のみならず例えばＩＰスプーフィングのような事例等に対処するハード面のモジュール・プログラムとしても適応・補填できることを特徴とする表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」。
【請求項６】
特定のＩＰアドレスを対象としたものでもノードアドレスでもデータグラムでもなく、あくまで発信ＩＰアドレスが重複する、その「随伴現象」をそもそも不審と見做し、それを「不正な通信」の判定根拠にしていて、かつ、システムのアクセスルート、すなわちページ内のどの位置に当該検出手段を配置しても特に問題はなく、検出できることを特徴とする表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」。
【請求項７】
配置する位置状況によっては認証確定に至る過程以前のアクセスルートの段階で「随伴現象検出プログラム」が発現して「随伴現象」を露見・顕在化させることが可能となる仕組みを有することを特徴とする表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」。
【請求項８】
随伴現象(an accompanying phenomenon)を検知・検出することで、メインシステムとは別運用の「認証サーバー」並びに被ＤＤｏＳ攻撃対象サーバーなどでも「随伴現象」を露見・顕在化させることが可能となる仕組みを有すること、及びメインシステムから画像認証サーバーへ送られるＰＯＳＴデータに予め「クエスチョン・マーク」を付さないプログラム仕様にすることで、「画像認証サーバー」宛送り付け連結パラメーターに対し「クエスチョン・マーク」を除去して、これにより通信エラーを惹起せしめ、又はこの連結パラメーターに対しＣＡＰＴＣＨＡの「判読文字」のみを該当「ｎａｍｅ」から除去する仕組みを当該「随伴現象検出プログラム」に組み込めることを特徴とする表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」。
【請求項９】
前記のような出処の異なるＩＰアドレスを補捉して分離するための照合手段を有していることを特徴とする表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」。
【請求項１０】
少なくともログインシステムに特化した手口・シナリオ型の現況のウィルスを、結果的に無意味・無害化するという意味から既存のウィルス対策ソフトを相互補完すること、並びに従来限定的にしか照合結果を得られなかったドット付きの現形ＩＰアドレスを、数字等を結合化することによって他の媒体との組み合わせパターンのバリエーションを広げられることに最大の特徴を有する表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」。
【請求項１１】
外部ネットワークを経てトップページに至ったメンバーのＩＰアドレスを初期照合・抽出・検出する手段は、トップページ内に記録媒体（「ＩＰアドレス履歴記録媒体」）へ直結するアクセス導線を設けて行い、その単一検出・照合する方法は、単一検出・照合が実行可能な「検索構文」を保存媒体に対応する数だけ配置して行うか、もしくは一つの「検索構文」が複数の保存媒体に対して順次単一検出・照合が実行可能な「検索構文」の仕組みによって行い、以って適宜対応処理することを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項１２】
トップページにおいて各媒体に記録される「当日通し番号」の番号連続性の整合が通し番号検問によって常時チェックされていて、当該通し番号検問の順番確定を参照することで、副次的に媒体記録時の排他制御を補佐すること、及び飛び番号・同一番号等不整合な「当日通し番号」を検出した場合ルートの遮断が実行処理できることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項１３】
「当日通し番号」のスタート番号が日ごとに加算され、あるいは予め決めてある数字に達したとき番号が飛び番号になるような対応表を有していることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項１４】
ロボットがメンバーの端末を踏み台にして［端末ＩＰアドレス］を偽装して侵入した状況を想定し、これを阻止する手段を保存媒体へ至るアクセス導線に複数配置して判定できるようにして、その判定対象の「原本ＩＰアドレス」にシステム接続時の秒数等の偶発性・流動値を結合することで、重複ＩＰアドレスによる「随伴現象」を作為的に作出・露見させる前記「ツインズＩＰブロック」でルートを遮断し、あるいは予めＰＯＳＴデータに「クエスチョン・マーク」を付さないプログラム仕様にすることで、ＧＥＴパラメーターから「クエスチョン・マーク」を除去して３０５通信エラーを生起させ、もしくはＧＥＴパラメーターの総バイト数から「ドメイン」と「クエスチョン・マーク」の合算バイト数を減算し減算値バイト数に短縮して実効性を削ぐことで、これによって該当ＩＰアドレスの通過ルートを遮断すること、並びに一旦、更新追加記録されたデータの取り消しもしくは保留措置が講じられることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項１５】
「バイト数別Ｍａ媒体」と「カレントＩＰアドレス記録媒体」の並列同時の照合処理の仕組みは、どちらか一方で先行して行うと同時に、他方へ直結するアクセス導線を他方の検索構文に設けることで、通常ＩＤのような「メンバーアカウント」を単一に検索する構文がこれを並列同時に検出するので、同時に照合を図ることができることから、よって保存媒体とその媒体へ直結するアクセス導線及び該当データを検索する構文をこのような二列構成にすることで、同時二面照合することが可能になること、又は、隠しステップを設け、その媒体へ直結するアクセス導線の分岐送致手段を＜META＞もしくは＜IFRAME＞タグによって実行処理することを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項１６】
「プルダウン式入力認証ＭＡ」の仕組みには、キーロガー対策が配されていて、１文字ごとプルダウン・メニュー（数字・アルファベット大文字・小文字）から文字を選択する「プルダウン式入力」が前記パスワード桁数１個と複数列横並びに配置されていること、更に選択文字確認用のフィールドが設けられていること、そして先行して複式操作ボタンを１回押すことで確認用フィールド内に確認用の選択した文字が充当表示されること、また、その次に送信ボタンを押すことが当該「プルダウン式入力認証ＭＡ」のクリア条件となる、このような複式操作の実行が不可欠であって、かつ、パスワード桁数を適正に選択することによってのみ、バイト数別に保存された「バイト数別Ｍａ媒体」との、当該複式関連付け因果性（トップページのＰＯＳＴボタンを押したことの確認、複式操作ボタンを１回押す複式操作及びパスワード桁数の選択）照合が可能となること、これにより前記「バイト数別Ｍａ媒体」に対して、通常ＩＤのようなメンバーアカウントを検索照合することができることで、適正なアクセスルート先が確保されることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項１７】
前記のようにロボットの偽装ＩＰアドレスによる侵入に対して、そのパラメーターに「クエスチョン・マーク」と「ドメイン」が存在するか否かの割り出し判定を行い、それが確認された場合、媒体が存在するディレクトリへ至る「媒体直通ルートパス」を分断・遮断することによって、その該当記録媒体に対して照合処理そのものが行われないようにする仕組みとロボットによる偽装ＩＰログインを確認・断定（前記「１２２」）する仕組みとを兼備することを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項１８】
当日通し番号を核組成として暗号化された〔ワンタイムアカウント〕は、当日の認証手段である〔当日アクセス情報〕が「錠」を構成し、その「錠」を開ける「鍵」に当たるものであって、偶発性を有してメンバー個々固有に生成され、かつ結合の順序が、当日が偶・奇数日か通し番号が偶・奇数かによって先頭もしくは後尾のように結合位置が異なり、しかも結合される文字が数字あるいはアルファベット・記号に入れ替わるグレゴリウス暦〔当日偶・奇数曜日キー〕のため結合ボーダーを隠蔽化できることで偽造を阻止することを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項１９】
［セッション管理キー設定］は、〔当日アクセス情報〕の「錠」に対して、ここで「鍵」を設定する仕組みであって、前記「プルダウン式入力認証ＭＡ」で選択した「メンバーアカウント」の文字が隠しフィールドに反映され、更に「パスワード桁数の数字」の選択結果がここで反映され、画面の適宜な位置に表示された〔ワンタイムアカウント〕を仮想の「鍵」としてコピー＆ペーストで入力することでログインパスワード認証へ移れる、鍵構成設定の仕組みであること、及び前記「メンバーアカウント」が照合不一致した場合の仕掛けとして上記隠しフィールドの＜input type=hidden 空=空value=空＞のようになることで、実質［セッション管理キー設定］の実効性が不能になることから、当日認証手段を得られなくする仕組みであることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２０】
ＩＰアドレス履歴記録媒体には、ＩＰアドレスのバイト数（桁数）別記録方式によってデータの分散化が図られる入れ子構造になっているため、照合処理が単一で済み、かつ、システム接続時照合の場合のアクセス分担処理数が軽減すること、並びに侵入ロボットがメンバーアカウントを検索照合する際、パスワード桁数の数字を誤って選択すると、ここでアクセスルートの遮断処理ができることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２１】
メンバーのログインのパターンは、前述したように４つのタイプしか存在せず、タイプ１は、ＩＰアドレス無変更で初回ログイン、タイプ２は、ＩＰアドレス無変更で当日２回目かそれ以降のログイン、タイプ３は、ＩＰアドレス変更で当日２回目かそれ以降のログイン、そしてタイプ４は、ＩＰアドレス変更で初回ログインとなり、ただし、初期（初回）は、必ずタイプ１かタイプ４のどちらかになって、次回又はそれ以降には、タイプ２か、タイプ３かのどちらかに分岐することを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２２】
無登録者及びクラッカーが手動で行う不正ログインは、常に条件が「初回」かつ「ＩＰアドレス変更」となること、並びこのような不正ログインが「当日通し番号」の流動値を生成するための条件として資することを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２３】
適宜な各所定位置に媒体直通ルートパスのような該当ディレクトリの媒体に直結するアクセス導線を設け、各所定位置で得られた判定結果の各符番を所定の順序で結合することで、このような方法で作出したそれぞれ異なる固有値パターンを有した、「連結符番」が、適宜な通過あるいは遮断の制御のための識別判定用途もしくは追加記録の停止・保留手段として資すること、更にメソッド判定「０」を初頭に付け、ＩＰアドレス履歴記録媒体を要にして〔当日アクセス情報〕の記録媒体であるカレントＩＰアドレス記録媒体、ログデータ、第二認証媒体でのそれぞれの照合判定結果を４パターン（タイプ１は「００１００」、タイプ２は「０１１１１」、タイプ３は「０１０１１」、タイプ４は「０００００」）のような連結固有値にすることで、このように形成された「連結符番判定」を適宜に活用すれば、ＩＰアドレスを偽装した自動プログラムによる不正アクセスを阻止・制御する仕組みになることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２４】
クラッカーの不正アクセスの犯跡記録を検出するための手段として、メンバーの「メンバーアカウント」が窃取されていることの根拠を得るには、その順序をＩＰアドレス履歴記録媒体で先に行い、通常ＩＤのような「メンバーアカウント」で照合一致した後、「秘密の質問」の照合に移るようにすることで「秘密の質問」がクリアできなかった場合、それを窃取確定の犯跡記録とすることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２５】
目下、現在進行形の流通データを記録するカレント性媒体（ＩＰアドレス履歴記録媒体・カレントＩＰアドレス記録媒体・ログデータ・第二認証媒体・時刻付与媒体）は、主要データの保有媒体であるＩＰアドレス履歴記録媒体を要にしてこれら５者が相関関係を有していて、互いを監視したり、補佐したり、あるいは他を代替したりして有機的な関係を保持していることから、各媒体に対象・該当データが存在すれば「１」、不存在であれば「０」のように判定し、それらを順次結合した、「連結符番判定」を形成することで、従来、認証手段の要とされなかった発信元ＩＰアドレスを、その変更・無変更に関わらず、一意性（unique）・一連性を有した当日限定のメンバー識別・紐付け情報として、一意性を有した認証手段とすることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２６】
通信中のパケットには必ずＩＰアドレスが在中することから、ＨＴＴＰ通信におけるステートレス通信の特性に即応性・順応性を保持した認証手段であること、並びに適宜な媒体へアクセス導線を設けることで、ページ（ステップ）の「ＩＮ」ばかりでなく、「ＯＵＴ」のデータチェックがその都度、発信元ＩＰアドレスを一意性（unique）・一連性として自動的に実行できることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２７】
利用者の端末に在中するＣｏｏｋｉｅ情報に一切依存しないため、Ｗｅｂサーバーが外部ネットワークを経由して端末とのやり取りを行わずに、そしてＷｅｂブラウザーの「Ｃｏｏｋｉｅブロック」を実行したままインターネット接続が可能になるログインシステムであること、かつ、Ｗｅｂサーバーが利用者の端末に介在することを不要にした仕組み技術であることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２８】
前記パターン数字（「１３３」「２３３」「１４４」「２４４」）もしくはその合算値の連続数字の判定数字（「７」「８」「９」「１０」）を形成させこれを活用して、発信元ＩＰアドレスの一意性（unique）・一連性を常に確保・維持・制御することで、データを受け継げないステートレス通信の特性に最も適した一連性認証手段の仕組みを発揮させ、以ってＩＰアドレスを偽装したロボットを臨機応変、かつシステム内のどのルートからでもケース・バイ・ケースで自在に制御・遮断できることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項２９】
どのルートからでも照合照査は可能なので、前記「バイト数別Ｉｐ媒体」内のデータに［更新追加記録］されたデータのうち、「パターン数字」を、ルートを遮断する判定の前記「Ｅ」に上書きもしくは変更処理することで、不正・不要なパラメーター・データを記録停止・保留にして排除し、あるいは次回から利用禁止措置を講じることで、メンバーの現有ＩＰアドレスの一意性（unique）・一連性を常時、確保できることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項３０】
ＩＰアドレス単一による照合の仕組み的遺漏を補足するために、前記ログデータの記録と並列処理できる「第二認証媒体」のような記録媒体を設け、当該記録媒体に初回ログイン時、前記「当日日付」「当日通し番号」「ワンタイムアカウント」「メンバーアカウント」等を記録し、「当日通し番号」〔ワンタイムアカウント〕の重複発行を回避することで、これらのデータの根拠を基に〔当日アクセス情報〕の一意性（unique）を保持し、当日２回目かそれ以降にメンバーのＩＰアドレスが急遽変更された場合などの緊急・局面的状況に臨機応変に対処できることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項３１】
「鍵」発行方式において「認証局」のような第三者の介在を設ける必要がない自己完結型という点で、「鍵」発行方式の仕組みそのものが異なることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項３２】
〔当日アクセス情報〕及び〔ワンタイムアカウント〕の仕組みは、仮想上、一方の〔当日アクセス情報〕を「錠」一方の〔ワンタイムアカウント〕が「鍵」のように構成されており、メンバーがこの「錠」に対して自己の「鍵」を生成（設定）することが不可欠なような構造になっていて、かつ、この「鍵」の組成条件には、グレゴリウス暦の「曜日キー」が含まれていることから、「流動性」「偶発性」「ナンス性」のような最強の耐性強度を保持することができ、これら「錠」と「鍵」を使って施錠したり開錠したりして登録メンバーのステップ移動時「ＩＮ」「ＯＵＴ」の検証手段とすることで、セキュリティー面のより強化された臨機応変な［セッション管理］が遺漏なく実施できること、並びに「ログアウト」の自動化が図れることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項３３】
〔秒数ランダム曜日キー〕の生成は、例えば、前記ログデータ記録時の００〜５９秒のような数字が暗号されたものと、グレゴリウス暦の「曜日」１字の日曜〜土曜を例えば「数字（０〜６）」または「アルファベット（ａ〜ｇ）（Ａ〜Ｇ）（ｈ〜ｎ）（Ｈ〜Ｎ）・・・・」のような７文字にして入れ替え、それを結合したものであり、このようにグレゴリウス暦の〔秒数ランダム曜日キー〕の生成が、偶発性を有しているため、他の組成と結合されたとき、結合ボーダーが不明瞭となることから、組み合わせ暗号の結合区界を隠蔽化する手段となることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項３４】
メンバーのログインパスワードの仕組みは、アルファベット文字と数字から１字を選択することができるプルダウン・メニューが複数列横並びに配列構成されていて、これら複数個の各プルダウンの構文「ｎａｍｅ」が生成・形成されるには、上記、セッション管理キー設定の送致データが第二認証媒体で照合されたときの照合時刻と、〔ワンタイムアカウント〕を「鍵」とする仕組みの一致が当該「ｎａｍｅ」を構成するためには不可欠であって、これによって通常ＩＤのような固有記号の「メンバーアカウント」と「照合時刻」が「ｎａｍｅ」に付与されて暗号され、かつ「照合時刻」の暗号は文字位置の置き換え法則の仕組みを有した対数表をもとにシャッフルされて結合・連結され、加えて、この「ｎａｍｅ」にも〔秒数ランダム曜日キー〕のような偶発性・流動性を有した組成条件が含まれていることで「ｎａｍｅ」の結合ボーダーが不明瞭となり、日替わり可変長・可変値にすることができ、かつ、メンバー個々固有の異なる値を毎回、ナンス性を有して生成・発行できることで冗長化された煩雑な構造になるため、ログインパスワードを解読する前の段階で「ｎａｍｅ」の解読を困難にすること、また、キーロガー対策を兼備していること、更に「ＰＷ確認フィールド」が設けられていて、所定通りの適正な選択を行ったことでしか因果性を得られない前記複式一連関連付けの重層ブロック構造による仕掛けによりメンバーのログインパスワードが「ＰＷ確認フィールド」にリアルに充当表示されることから、メンバーは充当表示されたパスワード文字を見ながらプルダウン式文字入力ができる利便性を享受することができることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項３５】
前記のような一連の重層ブロック構造による「ＯＵＴ」データを検証する仕組みを有することで、通常ＩＤのような「メンバーアカウント」「ログインパスワード」の両方を窃取されても、その不正ログインを阻止することができることを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項３６】
ログインパスワードの「ｎａｍｅ」の復号手段は、連結パラメーターの総バイト数から、照合の対象となる「一区切り」を逐次抽出し、逐次減算を繰り返し判定根拠媒体値と対象となる「一区切り」とを照合・照査することを復号手段とするような仕組みを有することを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項３７】
パスワードクラッキングを目的とする、通常の連結パラメーター攻撃に対して、その総バイト数を計測し、アンバサンドとイコールから各プルダウンの単体バイト数をミニマムのバイト数、マックスのバイト数に区分けして割り出すことで、攻撃パラメーターに対してミニマム・マックスに応じて、総バイト数から短縮し、以ってそのパラメーターを不能にすることで、当該攻撃を阻止することを特徴とするインシデント対応型ログインシステムのうち、セッション管理技術。
【請求項３８】
送信者が「送信者ボックス」からコンテンツ情報を送信する場合、外部ネットワーク上の送信途中で急遽、「送信者ＩＰアドレス」が更新される状況を想定して、外部ネットワークに出る前に、該当媒体記録用の［連続ページ番号］を取得（発行）し、これを該当媒体に先行割符として記録しておき、送信データを「ＯＵＴ」する直前に前記「バイト数別Ｉｐ媒体」で一旦、自己のＩＰアドレスの照合を図り、その後にＥＬ−ＳＳＬに託すようにすることで、リターンしてきたＥＬ−ＳＳＬ受信データのなかで「送信者ＩＰアドレス」が更新されていたとしても戻り値にこの［連続ページ番号］及び前記媒体識別ニックネーム（但し、［指名］）が含まれていることを確認するだけで、「ＩＮ」において［連続ページ番号］の整合性を図ることができるので、これによって「送信者ＩＰアドレス」が更新されていたとしても、これを引き継ぐことでＩＰアドレスの一意性を一連して確保できること、並びに「ＯＵＴ」時のデータの検証をも確保できることを特徴とするインシデント対応型ログインシステムのうち、閲覧に特化した管理技術。
【請求項３９】
〔隠蔽ディレクトリ〕となる「サブルーチン」を構成する仕組みは、上記「照合構造」の方を先に表示し、そのなかに入れ子の「サブルーチン」を隠すような構成・構造を有した「サブルーチン」擬きのように構成されていて、従来、固定長・固定名が常識とされていた「サブルーチン」を暗号化することによって、可変長・可変名値にし、更にこの「サブルーチン（擬き）」の構文に変数を（「$main」のような）設定することが可能になり、ページ画面を検索する度にその都度、異なる不定流動値が得られるようになることから、上記「照合構造」の条件を満たしたときが一致、条件を満たさなかったときが不一致のような状況が作出されるため、上記「暗号化サブルーチン」が既定通りの条件を満たしたとき（一致したとき）以外、ページ画面にコンテンツ情報を表示しないようにすることができるので、以って、牢固な［セッション管理］並びに［閲覧に特化した管理］を並行して維持できることを特徴とするインシデント対応型ログインシステムのうち、閲覧に特化した管理技術。
【請求項４０】
受信した個々のページのガイダンス情報（「インデックス情報」）を構成する仕組みは、仮想上、送信者が送信データの「錠」となる情報を提供し、受け取ったこの情報に受信者が「鍵」を掛けることによって、受信ページ１件ごとに内鍵施錠されたようにして機密性を高めることで、「プレビュー漏洩」を防止・制御することを特徴とするインシデント対応型ログインシステムのうち、閲覧に特化した管理技術。
【請求項４１】
「着脱変換プログラム」は、〔隠蔽ディレクトリ〕の「照合構造」「ＵＲＬ」「サブルーチン（擬き）」「ディレクトリ」を創出する手段と共にＵＲＬの自動廃棄処理を達成するための手段であって、画面表示されない隠しステップ内にこれが設けられていて、それらの仕組み機能によって、ＵＲＬ（ＧＥＴパラメーター）のステップ移動手段を実行し、かつ、初期ＵＲＬが廃棄されて別様ＵＲＬになって＜IFRAME＞タグ等によって前記ログデータへ送致されるため、前記ログデータ等の媒体での検索照合によるデータの抽出（受信者の原本ＩＰアドレス）、データの交換（受信者の原本ＩＰアドレスが送信者のワンタイムアカウントと交換）、データの挿入結合、データの除去結合、データの分岐、２方向のデータ送信経路手段の作出等が実行処理できること、及び後期戻りＵＲＬの経由送致手段を＜IFRAME＞タグ等と＜META HTTP＞タグによって別々に分岐して行うことで、後期ＵＲＬの戻り値データが、一方は相対処理媒体へ送致され上書き処理され、一方はＷｅｂブラウザーのＵＲＬフィールド欄に隠蔽ディレクトリＵＲＬとして充当（送致）されることから、これによって一方は媒体記録手段のため「アクセス履歴」に残らず、一方は上記「照合構造」の照合手段であって最終ＵＲＬとなるので「アクセス履歴」に残ること、更に当該「着脱変換プログラム」が実行される条件は、上記隠しステップ内の経路上のパケットに在中する受信者・メンバーの現有ＩＰアドレスと前記バイト数別Ｉｐ媒体に記録保存されたＩＰアドレス（前者）が一致していて、前記ログデータと〔当日アクセス情報〕のＩＰアドレス（後者）が一致していることが不可欠（真正性の確保）であること、また、当日限定の措置、もしくはログイン条件として前者と後者それぞれ異なる原本ＩＰアドレスが存在することもあり得ることを特徴とするインシデント対応型ログインシステムのうち、閲覧に特化した管理技術。
【請求項４２】
ステップ内で隠蔽処理が可能で、かつ、ページのソースを開示することができない前記隠しステップが適宜な位置に存在していることを特徴とするインシデント対応型ログインシステムのうち、セッション管理・閲覧に特化した管理技術。
【請求項４３】
〔隠蔽ディレクトリ〕の組成が生成される仕組みは、主として前記隠しステップ内で行われ、メンバーの個別（［指名］・［全員］）媒体から送信データの「保存時刻（暗号）」を抽出して復号し、スライド計算時計がジャスト時刻を基に現「スライド時間」（送信データの「保存時刻」を起点に経過した秒単位時間）を算出し、データに曜日キーが結合され、暗号ルーチン生成体で上記したような「サブルーチン（擬き）」の〔隠蔽ディレクトリ〕の組成が生成されること、並びに「ディレクトリ」「サブルーチン（擬き）」「ＵＲＬ」「照合構造」の４相の機能を複合的に有し、そのデータの移転・局面状況に応じ４相４様に有機的に発揮・機能することで、閲覧する度に暗号化された「不定流動ＵＲＬ」が形成・構成される仕組みであることを特徴とするインシデント対応型ログインシステムのうち、閲覧に特化した管理技術。
【請求項４４】
〔隠蔽ディレクトリ〕内で個々のページ検索を行うプログラムを構成する仕組みは、「ｉｆ構文」（「==」「eq」演算子）を用いて作為的［照合構造］を先行して構成し、そのなかに入れ子の「サブルーチン」を隠すような〔隠蔽ディレクトリ〕の構造にすることで、この〔隠蔽ディレクトリ〕の［照合構造］が一致したときのみページ検索画面が表示され、かつ、この〔隠蔽ディレクトリ〕は秒差調整された「スライド時間」の暗号化等によって、閲覧する度に「不定流動ＵＲＬ」になるように前記隠しステップ内で自動的に生成されるために、「アクセス履歴」から秒差遅れの要求ＵＲＬでアクセスしても自動廃棄処理化が常時成立完成されていることから、［照合構造］が不一致の場合は、ページ検索画面（業種別フォーマット）が不表示になるような仕組みを作出することで「プレビュー漏洩」の遮断処理を可能とすることを特徴とするインシデント対応型ログインシステムのうち、閲覧に特化した管理技術。
【請求項４５】
トラバーサル防御プログラムは、機密情報等を記録したファイル並びにＭＩＭＥ形式系データを格納した各様態ディレクトリ内に常駐していて、直引き絶対パス、もしくは不正な手段あるいは執拗な回数でアクセスしてきた要求ＵＲＬからサイト・ドメインを検出し、拡張子を検出し、適宜な経路手順に該当・相当しない要求ＵＲＬと判定することで、即時、前記「クローンＩＰアドレス」を対峙させ、「随伴現象(an accompanying
phenomenon)検出プログラム」を誘発させて、このような手動、自動攻撃に対して遮断制御処理を行う仕組みを実装した待機型プログラムが主要ディレクトリ内に配備されていることで［セッション管理］並びに［閲覧に特化した管理］が維持できることを特徴とするインシデント対応型ログインシステムのうち、セッション管理・閲覧に特化した管理技術。
【請求項４６】
「アクセス履歴」に残るＵＲＬの無効化処理を行うための措置であるＵＲＬの一律固定の仕組みは、前記したように常にＵＲＬが同一固定（例：「https://domain/members/」）になるようにすることで、クラッカー（ボットネット）から「アクセス履歴」を窃取されてもそのＵＲＬを実質的に無効化にすることを目的としていて、特にログイン（メンバーアカウントやログインパスワード）入力実行時及びコンテンツ・データ送信実行時の「ＦＯＲＭ」に必要であって、かつ前記媒体直通ルートパスのような複数のアクセスルートの方向付けが記述された「対応表」が設けられていて、「ＦＯＲＭ」の送付時に「action=’./members/abc1’」もしくは＜input type=hidden name=job value=abc1＞から前記コール符番（abc1）を分離し、かつ前記コール符番を内部プロセスで隠蔽処理し、この「対応表」が、前記コール符番に応じたアクセスルート先へ、ＰＯＳＴの送付データを対象媒体へと誘導することで、これによりＷｅｂブラウザーのフィールド欄の要求ＵＲＬを常に一律固定に維持することができること、及びブックマークによるアクセス禁止措置を設けること、これらによって「アクセス履歴」に残るＵＲＬの無効化処理を行うことを特徴とするインシデント対応型ログインシステムのうち、セッション管理・閲覧に特化した管理技術。
【請求項４７】
業種ごとに特化した業種別フォーマットを適宜活用することで、上書き不可のＣＤ−ROMに保存したワープロ文書を自己専有媒体に転送し、前記仮想上の［サーバー内図書館］において上書き・書き込み作成・編集処理作業を行い、更にこの経由表示されたワープロ文書のデータからコピー＆ペースト機能でワード・プロセッサ専用フォーマットに移し保存することができることを特徴とするインシデント対応型ログインシステムのうち、業種別フォーマット管理技術。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットのログインシステムのうち、特にＷｅｂブラウザー画面の表示を制御することによって、ログインシステムを不正なアクセスから防御し、「情報収集」「情報漏洩」「通信アクセスルート」の遮断を行うための、インシデント対応型ログインシステム実装プログラム等並びにその周辺・関連制御技術に関する。
具体的には、既存のＣｏｏｋｉｅ及びＣｏｏｋｉｅをベースにした「認証技術」の置換を目的とする。この［一意性認証技術］は、通信パケットに在中するＩＰアドレスを応用・活用して、不正アクセスに対し［侵入検知防御］を行うことを主旨としている。従来、ＩＰアドレスを応用して「侵入検知防御」を行う場合、ハード面重視型に偏向していた。本発明は、むしろこれをハード面の方を従にし、ソフト面重視型システム実装プログラムを主にすることによって、「情報収集」「情報漏洩」「通信アクセスルート」の遮断を行い、インシデント対応型ログインシステムを実現する。
【背景技術】
【０００２】
近年、ボットネット（以下、マルウェア、スパイウェア等の侵入プログラムを総称して「ボットネット」と云う。また、不正実行者を「クラッカー」と云う。）の台頭により、インターネット環境が悪化の一途にある。ネットユーザーに利用を手控えさせ、使い勝手を悪くしているばかりでなく、各分野、各方面の業務に多大な影響を与え、インターネットが無法地帯化している。また、スタンドアロン型ソフトの多くは、この先、インターネットとの連動化が進む気運にあるなか、ボットネットの存在が足枷となっているのは否めない。
そればかりか、「情報」は盗る方より盗られる方が悪い、との論理がいつのまにか闊歩し、それが定着されつつある。このようなモラル・ハザードは危惧されるべきことである。
【０００３】
とりわけ会員制サービスを提供するシステムのような場合、アクセス権のない者から不正にアクセスされる、［成りすましログイン］は極めて深刻な事態である。しかもそれは、会員の端末を「踏み台」にして、そこを経由してシステムに頻繁に侵入行為が行われていてもそれに気づけない。これを「クラッカー」たちがアクセスするための［表ルート］とすると、当然、これと対義に当たる［裏ルート］も存在する。
ボットネットはシステム内の道なきところに道は作れない。このことは、システムの仕様手順通りのアクセスルートを踏んで侵入するしかないことになるが、但し、俯瞰的に裏道や抜け道を探り当てることはできる。［裏ルート］もこれに当たり、後述する「ステップの飛び越え」もこれに相当する。また、このような「踏み台」介在型の［成りすましログイン］を含む不正アクセスにも、４〜５つのパターンがある。
【０００４】
一般にはあまりよく知られていないが、［成りすましログイン］の事案の多くはＣｏｏｋｉｅが何らかのかたちで関与している。Ｃｏｏｋｉｅは、利用者の端末内の格納フォルダに保存・蓄積される記録ファイルのことで、これは、システム・サーバーがブラウザーを介してアクセス情報等を利用者の端末に介入して記録処理するために設けられているファイルである。しかもこの記録ファイルは利用者によって情報の書き換えができる。
Ｃｏｏｋｉｅに関して、現況では、解釈や認識に誤解がみられるが、基本的にはＣｏｏｋｉｅは、ユーザーの端末を識別するためのもので、それを手がかりにして本人認証を行っているから、識別・認証の決め手を得る手段のひとつである。
【０００５】
システムのＷｅｂサーバーが利用者の端末に介入する目的は、利用者個々を識別し所在を確認する用途のためであるが、もともとこのような確認を必要とするのは、ＨＴＴＰ通信（インターネット）の仕組みが、１回毎に通信が初期化されてしまう構造上の理由（特性）に拠っている。すなわちインターネットの「ＦＯＲＭ」の仕組みは、基本的にデータを受け継がない・受け継げないステートレス通信によって行われていて、これは、利用者が「ＦＯＲＭ」イン〜アウトになると、これで一旦終りになる。その後は、常に通信が半接続状態である。
つまりこの通信は、リクエスト、レスポンスの入・出力一行程で接続状態が初期化されるのである。従ってこのことは、ステップが重層する会員制システムのような場合、ログインパスワードを、異なる「ＦＯＲＭ」１回毎に入れ直さなければ構造上、安全性が保てない、ということを意味する。
【０００６】
入・出力一行程で通信の接続状態が初期化されるということは、システムのＷｅｂサーバーが、その都度、利用者個々の入力データを識別できなくなる、ということになる。そこでこれをカバー（補完）する仕組みとして開発された技術がＣｏｏｋｉｅである。Ｃｏｏｋｉｅは利用者個々を紐付けすることで、異なる「ＦＯＲＭ」１回毎のパスワード入力を不要にした。現況のシステム・プログラムの多くは、Ｃｏｏｋｉｅの他にセッションＩＤ・ＣｏｏｋｉｅＩＤ（符号・番号）というアクセス権の付与手段を別途に設けている。これをステップの移動の都度、データを内部的に自動携行（紐付け）することで認証手段としている。
因みにこのＣｏｏｋｉｅが開発されたのは、１９９６年頃とされている。
【０００７】
しかしながら当時とはセキュリティー事情が様変わりしており、各分野、各方面に及ぼす脅威も当時とは比べ物にならない。また、このセッションＩＤも元を糺せばＣｏｏｋｉｅであって、いわば親子、あるいは兄弟の関係にある。もしくは双生児である。両者の違いは、Ｃｏｏｋｉｅが利用者の端末に保存される情報であるのに対して、セッションＩＤはシステム・サーバー内に保存される機密情報である。しかもシステムのＷｅｂサーバーは、初回認証時は、利用者の端末内のＣｏｏｋｉｅ情報を拠り所としてセッションＩＤを発行する。そのセッションＩＤも、マニュアル化・モジュール化されたプログラムをシステムに実装しているため、ほぼ仕様が一律に等しくなる。そうすると、これに起因するセキュリティー・ホールを攻撃された場合、成す術がない。
【０００８】
ここで問題になるのは、異なるシステム毎にそのシステムのＷｅｂサーバーは利用者の端末に介入してＣｏｏｋｉｅ情報を確認し、システムのプログラム仕様に基づきセッションＩＤを発行する、という点である。この仕組みだと、ボットネットが利用者の端末に潜伏し、その初期段階にＣｏｏｋｉｅ情報を改竄して、そっくり偽情報にしてスリ替えておく、という手法が使われた場合、システム・サーバーは、盗用したＣｏｏｋｉｅ情報の出処・真偽に対して為す術がないことになる。
もともとシステム・サーバーはＣｏｏｋｉｅ情報の出処を利用者の端末から確認して、これを決め手としているからである。しかもこれによって、ボットネットの術中に陥ると、遠隔操作を駆使することが可能になって、いつでも自由に利用者の端末を往来できる［表・裏ルート］が築かれてしまう。通常、利用者は、セッションの「ログアウト」によって、ログインのひと区切り毎にアクセスの遮断を講じている。が、Ｃｏｏｋｉｅ情報を盗用された場合は、セッションハイジャックやクロスサイトスクリプチィング（セッションＩＤ等の漏洩）などの攻撃手法で、クラッカーにログインパスワードやセッションＩＤ等の機密情報をすでに奪われている。
【０００９】
こうなると、本来のアクセス権が奪われ、クラッカーの方に主導権が知らぬ間に移動してしまう。このような裏をかかれた方法が使われると、利用者はそのような事情を知ることなく、システムにログインしていることになる。その結果、個人情報はいつの間にか筒抜けにされている。その手口のひとつが［裏ルート］から秘かに行われるミラー・ブラウザー（遠隔覗き見）である。そしてこれによる情報収集やモニタリング（監視活動）が日々入念に執拗に行われつづける。
【００１０】
ここでクラッカーが常套手段としている小道具プログラムを挙げておくと、キーボードの入力情報からパスワード等を逆探知するキーロガー、窃取した「アクセス履歴」「Ｃｏｏｋｉｅ情報」等の送信手段であるボットメール、潜伏先のデータの消去や改竄を行うプログラム、一種のブラウザー・リモコンの実装、［裏ルート］の構築など、である。これら小道具を手口・シナリオとして端末に仕込み、ミラー・ブラウザーを定点観測的に行い、機が熟すのを待つと考えてよい。クラッカーの狙いは対価の獲得に他ならない。そこから直接、対価が得られるものは、すべて攻撃対象となる。対価の値が高いと踏めば多少のリスクも厭わなくなる。そしてその脅威は、やがてネットを離れ日常の生活圏を脅かす。多くのインターネットと縁のない人間がこれに関わり巻き込まれ、依頼者すらコントロールの効かない「欲」の入り乱れた闇構図ができあがる。最早これは、現実化している。
【００１１】
本発明は、これら諸般の脅威や現況のセキュリティー事情に鑑みて創出した技術であり、かつ用途において表裏一体の二面性を持つ。詳細は後述するが、ひとつの用途は、上記のような［成りすましログイン］によって行われる「悪意の情報収集」をさせない技術、そしてもうひとつの用途は、通信伝送手段を阻害することになる「情報漏洩」を起こさない技術、すなわちインシデント対応型ログインシステムの創出である。
うち「悪意の情報収集」をさせない技術とは、Ｗｅｂブラウザーの画面表示を、端末ＯＳのキャッシュ・メモリ及びシステムに実装するプログラムによって制御することで、当該画面を白紙化状態にし、上記のミラー・ブラウザーを遮断する技術を指す。
さらに「情報漏洩」を起こさない技術とは、具体的には、ブラウザーの「アクセス履歴」から追跡行為をできなくする技術、及びスパイウェアに対する防御を図る自動処理化技術を言う。
とりわけインシデント対応型ログインシステムは、Ｗｅｂサーバー及びＷｅｂブラウザーから発生する「情報漏洩」の諸因を完全に遮断する。後述するような流出漏洩（セッション管理）、プレビュー漏洩（閲覧に特化した管理）、をクラッカーに一切、許さない技術を提供する。これによりインシデント対応型のＷｅｂブラウザーが実現する。
すなわち、Ｗｅｂブラウザーをツールとする、機密情報を扱うプロジェクト業務が可能になる。
また、「通信アクセスルート」の遮断に関しては、具体的には、ボットネットの送り付けパラメーター攻撃に対する防御手段を言う。送り付けパラメーター、とは、対象サイトに向けて、絶対パス（ドメインを含む要求ＵＲＬ）の導線を設定して目的を遂げようとする不正プログラムのことを指す。
この他、ＨＴＭLファイルの中に直接、埋め込む＜IMG SRC=”ボットネット宛ＵＲＬ”＞＜IFRAME SRC =”ボットネット宛ＵＲＬ”＞＜META HTTP−EQUIV=”Refresh”CONTENT=’0;URL=”ボットネット宛ＵＲＬ”’＞等も含まれる。この場合の目的は、自分宛に「ボットネット宛ＵＲＬ」（端末情報等）が届くことで、このＨＴＭLファイル（「偽ポップアップ画面」）を画面表示した利用者の動静を探知する。更にＷｅｂサーバー内に保存してある機密情報を窃取するための「ディレクトリ・トラバーサル」のような攻撃も送り付けパラメーターの部類に属す。
尚、ログインシステムのうち、本発明の上記プログラムに関しては、具体的にはネットバンキングのシステムに実装もしくはシステム・サーバーに組み込むＡＰＩ方式にすることも念頭に入れている。またネットバンキングに特化して、ステップ間の「経由証明」を検証できないために生じるステップのフリーパス化、ステップの飛び越えに関して、これを検証し阻止する技術。
またネットワーク上の脅威となる、攻撃加担型「踏み台端末」についても、これをクラッカーから防衛するための技術も提供する。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２０１３−１０２４５４号広報
【００１３】
【非特許文献１】鈴木憲治他著  「ＰＨＰ逆引きレシピ」翔泳社  ２０１３
【発明の概要】
【発明が解決しようとする課題】
【００１４】
ボットネットの手口・シナリオにとって弱点が一つある。それはウィルスに感染させただけではターゲットとして利用価値があるかどうか、まだ、未確定という点である。ウィルス感染は、ネットワーク上では不特定多数であって、対象者を選んで感染させているわけではない。クラッカーの目的は、対価の獲得である。従って利用価値があるかどうか、それを見極め確定するためにはターゲットに関する一定の下調べが必要になる。それが、隠密下に行われるミラー・ブラウザーによる「悪意の情報収集」である。かつこれをよりリアルに具現化するのが、ブラウザーの「アクセス履歴」（ＵＲＬ）から得られる確実かつ詳細情報である。
【００１５】
一方、ＯＳ（Ｗｉｎｄｏｗｓ７）には、「インターネットの出入口の通信を監視し、不正な通信を遮断する」ファイアウォールが標準搭載されていることになっている。しかし、現実にはマルウェア、スパイウェア等の不正プログラムに侵入潜伏されている。そうするとこれは、不正な通信に対してファイアウォールの検出・識別手段に脆弱性がある、遺漏
があるということになる。
【００１６】
ＯＳはもともとバンドルソフトやインストールソフトと共存関係にあり、これらバンドルソフトのなかには、パターンファイル照合のために、その実行サーバーに対して門戸を解放し処理を行なわせてもいる。更にログインシステムのサーバーはＣｏｏｋｉｅ認証のために利用者の端末に介入する。またバンドルソフトを感染媒体とするような特殊な事例もある。このようなインターネットの複雑化した通信環境からすれば「不正な通信」を割り出すことは極めて困難であり、まして潜伏中のマルウェアの挙動を監視するのは至難である。
【００１７】
さらに特殊な事例として、次のような端末を狙った、ストーカー型の標的・侵入事例が確認されている。日本語名にしてある三重四重の入れ子フォルダに不正プログラムを常駐させる事例、ブラウザーのバージョン（Ｗｉｎｄｏｗｓ７の場合、バンドルのＩＥは９．０）を逆に７．０にまで下げ、１１にまで段階的に上げるアップダウン事例。また、仕様書通りのリカバリーが完了した直後に２時間も要してレジストリーの更新が行われる事例。しかもレジストリーの更新は、ネット回線を抜いた状態でこれが行われている。
＊尚、ＩＥ７．０以降が「ＥＶ−ＳＳＬ」（サーバー証明書）に対応している。
【００１８】
また海外向けに用意してあった広報翻訳文を記録したファイルや翻訳名称入れ画像をＣＤ−ＲＯＭに保存しておくと、それが「読み取り専用」にされ、ファイル１つを削除しただけでＣＤ−ＲＯＭ全部が一挙に消去。さらにデジタルカメラに保存した７００枚を超える画像が、フォーマット・ファイル１つを削除しただけで一挙にすべて消滅。これらは、ネット回線を抜いた状態で、かつメール等のバンドルソフトをすべてアンインストールしていて実行されているから、「不正な通信」がどこから侵入してくるのか確かめようがないことになる。その他、作動試験プログラムへの頻繁な侵入アクセス・改竄行為等。これらは、一連の犯跡を消去しようとする証拠湮滅に他ならない。
＊尚、上記のような一連のストーカー的妨害行為は、２０１３年９月２６日を機に始まって、やがては端末を破壊されることを想定したため、端末をインターネットから遮断するに至る１年以上続いた。
【００１９】
現状ではこのような錯綜する通信事情から「不正な通信」の根拠を確定できなかったということになり、クラッカーに［裏ルート］を設営されても遠隔操作に歯止めがかけられない、もしくはそのようなブロック措置を今まで講じられなかったということになる。すなわち、これは、決め手となる「確実な検識体」や適宜な手段がこれまで見つからなかった、もしくは探し得なかった、ことを意味している。
【００２０】
Ｗｅｂブラウザーの機能には、手動で、許可するアクセス先のサイト・ドメインを設定することができるようになっている。が、ほとんど使いこなせていないのが現状である。野球の初心者にいきなりジャスト・ミートを指導しても分らないのと同じで、利便性が良いとは言えないばかりか、クラッカーにとって、むしろ好都合なファクターですらある。
以上から本発明が解決しなければならない課題は、次の３点に絞ることができる。
【００２１】
ア１）、［成りすましログイン］の端緒は、ミラー・ブラウザー（遠隔覗き見）から始まっている。
既存技術では［裏ルート］からのミラー・ブラウザーが容易に可能である。これを阻止する手段が必要であり、逆に潜伏先からターゲットに関する情報が得られなくなれば、ボットネットは身動きがとれずウィルス感染も実質、無意味になる。少なくともログインシステムに特化した手口・シナリオ型のウィルス感染に対しては無害化し、不正プログラムを無効化することができる。
【００２２】
ア２）、更にログインシステム及びＷｅｂブラウザーに対して、インシデントの外部要因（ネットワーク系の脅威）に対する対応策が必要である。Ｗｅｂブラウザー（端末）にデータを残さない「Cache Control」（キャッシュを無効化するプログラム）のような仕組みを、システムの実装プログラムに設けていても、例えば、表示したページ前後のリンクの依存関係から、万全とはいえず、ハイパーリンクを辿られると、それが情報漏洩の予期せぬ糸口となる。
また、既存のログインシステムでは、Ｗｅｂブラウザーの「アクセス履歴」のＵＲＬ情報が情報漏洩の引き金となっている。インシデント対応型には「漏洩」を阻止する制御手段が必要であり、それには［遮断］の仕組み技術が必須となる。それを実効化することでＷｅｂブラウザーは、最も安全性と信頼性の高い［伝送］［提供］手段を有したインタラクティブな対話型情報共有ツールとなる。
情報漏洩に関しては、紛失・盗難、Ｐ２Ｐファイル交換ソフト経由、誤送信、従事者による外部持ち出し等の人的な内部要因が８割強で、スパイウェア等のネットワーク系の外部要因は１割に過ぎない、と言われている。しかし、この１割が企業や組織にとっては致命的になる。とりわけ専門分野のノウハウや各分野、各方面のトレード・シークレットを含む機密情報を扱うプロジェクト業務にとって、信用失墜は、プロジェクト業務そのものが根本から意味をなさなくなる。
【００２３】
ここで本発明が解決しなければならない技術的課題を総括する。既存のベース技術では、最早、現下の錯綜したセキュリティー事情に対応できない。クラッカーによる不正アクセスの脅威を克服できない限り、インターネットの利用はけして安全なツールとは言えないことになる。
例えば、不正アクセスに対し既存の技術ベースは、ＩＰアドレスを応用した場合、ハード面に偏向しており、ＩＰフィルタリング（ブラックリスト活用等）・ルーチィング制御（ルーター）・ＩＰアドレス変換（ＮＡＴ，ＮＡＰＴ）等によって、その不正通信に対し［侵入検知防御］措置を行っている。しかしボットネット等の侵入手口は、ネットワーク上の他者の端末やサーバー、あるいは認証サーバー（別運用）を中継・介在してこれを［踏み台］としてシステムに侵入する。そうした場合、複数のＩＰアドレスが重複するため、ハード面偏向型のベース技術では、ステートレス通信の特性からしてもこれに対処できず、一方に対応している間に一方から擦り抜けられてしまう。このような事象を解決することが本発明の技術的課題である。
現況のログインシステムは、このようなハード面重視型の技術ベースによってシステムの通信が防衛されている。よって現下のセキュリティー事情に鑑みれば、不正アクセスの脅威を払拭できない状況にあると言っても過言でない。
【００２４】
更にＣｏｏｋｉｅを活用したログインシステムの「認証技術」の最大の弱点として、Ｗｅｂサーバーが利用者の端末に介入してＣｏｏｋｉｅ情報を確認し、それを「本人認証」のための識別根拠にしている、という点である。このような仕組みであると、悪意のあるサーバーも端末に介入（侵入）できることになる。そうすると端末に「介入」と「侵入」の区分けをする仕組みを新たに設けねばならなくなるが、技術的にその区分け識別は困難である。むしろ「介入」と「侵入」の定義すらおぼつか無い。
しかもＷｅｂサーバーは外部ネットワークを経由して利用者の端末に介入することから、これをＳＳＬ（暗号・復号）に委ねる他ない。更にＳＳＬで行って来いし、システムにリターンしてきたパラメーターはＧＥＴである。これもボットネットに好都合な条件を提供している。ロボットの送り付けパラメーターはすべてＧＥＴである。しかし、これを区分け判定する仕組みは、ＳＳＬに委ねた場合、「共通鍵」方式による施錠された発信データの正当性・信憑性を得る手段だけである。
このことは、ＳＳＬに委ねてもいない仕様の異なるデータに成り変わられたり、スリ変えられたりしても、これに気づけない、ということになる。
すなわち、ＳＳＬ（暗号・復号）技術は、外部ネットワーク上で発信データが漏洩したり、改竄されたりするのを防止するための検証・確認手段である。送ってもいないデータが戻ってくる道理がない、という前提が崩れると打つ手がない。しかもＷｅｂサーバーがＳＳＬに委ねるのは、利用者が「ＯＵＴ」する方のデータである。
【００２５】
この他Ｃｏｏｋｉｅを活用したログインシステムでは、セッションＩＤの照合処理がステップページの「ＩＮ」のheader部で１回限りしかできない。これはステップが変わる度にセッションＩＤが異なるわけではないので、複数の照合処理を設けても意味を持たないが、問題は「ＩＮ」よりも「ＯＵＴ」の方である。既存技術の場合、「ＯＵＴ」は、ひとが「ＦＯＲＭ」のボタンを押すことを前提にしていて、いわば他力本願であることから、ロボットにこの盲点を衝かれている。ここでいう他力本願とは、一旦、識別されて認証された者が途中で入れ替わる道理がない、という前提である。
しかし、例えばここにＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆのステップがあるとすると、ひとの場合、ＡからＢのステップへと移動するには「ＦＯＲＭ」のボタンをクリックすることになるが、ロボットは、これができないので、例えば、Ａステップ対応のパラメーターを送りつけてくる。そして少し間をおいて、次のＢステップ対応のパラメーターを送りつけてくる。このような方法で、「ＦＯＲＭ」のボタン操作が行えないハンディを逆手にとって、次々に「ステップ対応パラメーター」を間欠的に送りこんでくる。そうすると、Ｂ、Ｃ、Ｄ、Ｅを省いて、一気にＦステップ対応のパラメーターを送りつけてくることもできることになる。「ステップ対応パラメーター」が自動クリック・ボタンのような役割をするからである。
【００２６】
しかもこの場合、「ＩＮ」をクリアしたロボットの送り付けパラメーターは、一度もＳＳＬに委ねていないことになる。順序を逆に変容させた、一種のトリックである。よって、セッションＩＤを窃取されていた場合、既存のログインシステムには、「ＯＵＴ」をチェックする検証の仕組みがないので、ステップは次々とクリアされてしまうことになる。このような事象を解決することも本発明の技術的課題である。
このような方法が容易に可能になるのは、Ｗｅｂ通信がもともとデータの識別を受け継げないステートレスな通信であるからで、これも盲点のひとつと言える。
しかし「ＯＵＴ」をチェックする仕組みがこれにあれば、ロボットの、このような方法は通用しなくなる。
【００２７】
従来、［ＩＰアドレス］をソフト面の技術に応用・活用することに躊躇してきたのは、ひとつにはネットワーク上で急遽、発信元［ＩＰアドレス］が更新された場合、これに対処する手段仕組みが見いだせなかったためである。［ＩＰアドレス］を認証手段に応用できなかったのはこれがネックとなっていたからで、従来技術の［ＩＰアドレス］に関する技術的課題はほぼこれに尽きる。
そこで本発明は、通信パケットに在中する［ＩＰアドレス］をソフト面の技術に応用・活用することによって、別途「ＯＵＴ」をチェックする検証の仕組み技術を設け、既存のＣｏｏｋｉｅをベースにした「認証技術」とは全く異なるアクセス権の付与手段を創出し提供する。
かつ最もステートレス通信の特性に即応・順応する「インシデント対策対応型のログインシステム」「一意性認証技術」を提供する。特に本発明のインシデント対応型のログインシステムは、不正アクセスの脅威から完全に防御することができる。
既存の技術ベースは、クラッカーに研究し尽くされて疲弊化しており、閉塞状態にある。すなわち、技術のベースを変えない限り、現況のような無限ループな鼬ごっこがこの先も続くことになる。
よって、これを打開するには、ネットワーク上で急遽、発信元［ＩＰアドレス］が更新されても、又は何度変更になってもそれに対応できる仕組みの創出、システムのサーバーが会員利用者の端末に介入せずにシステム内の保有データによる有機的連携のみで、更に「認証サーバー」に依存しない自己完結型サーバーで、認証手段を確保できる仕組みの創出、「ＦＯＲＭ」のデータがＳＳＬ（暗号・復号）に渡される「ＯUT」時にこれの真偽が検証できる仕組みの創出が急務である。そしてこれらは、ステートレス通信の特性に最も即応・順応できる仕組みとなる。
更に本発明は、自動化されたロボットの不正プログラムの最大の弱点をＧＥＴパラメーターと捉え、この条件を逆に最大限に利用する。
【課題を解決するための手段】
【００２８】
本発明は、上記、ア１）の課題に対しては、基本的に「表示済ＵＲＬの自動廃棄処理」という方法でこれを解決する。
本発明の当該「表示済ＵＲＬの自動廃棄処理」とは、Ｗｅｂページ画面の表示を制御することによって、画面上のコンテンツ情報をいっさい消去し、閲覧そのものができなくする技術のことである。すなわち、利用者が一旦画面を表示した〔ＵＲＬ〕を他者に利用不可能にする。他者とはこの場合、ミラー・ブラウザー実行者等のクラッカーのことである。クラッカーがスパイ行為をするには、利用者が実行した〔ＵＲＬ〕を手掛かりにして、後追いで画面表示する方法しかない。
そこで表示済ＵＲＬの画面を後追いで表示しても、瞬時に白紙化状態にする仕組みを設けることで、ミラー・ブラウザーによる「悪意の情報収集」を遮断すれば、同時にそれは「情報漏洩」も遮断できることになる。
一方、利用者がこれによって、一旦表示した画面の〔ＵＲＬ〕が使えないわけではない。要は表示済〔ＵＲＬ〕に限定しての封印措置である。
Ｗｅｂブラウザーには、端末ＯＳにキャッシュ(cache)メモリがあって、一旦表示した画面情報のデータは端末に蓄積保存される。しかし立場が逆のクラッカーには、利用者が画面を表示するまで、その〔ＵＲＬ〕を知る術はない。このことから、利用者が表示済にした〔ＵＲＬ〕をその都度、自動廃棄できる仕組みをシステムのプログラムに実装することで、クラッカーはＷｅｂサーバーから、当該〔ＵＲＬ〕を手掛かりとした情報を得ることが一切できなくなる。これは、クラッカーは利用者の後追いになるため、常に自動廃棄画面（白紙化状態）に遭遇することになるからである。
【００２９】
本来、Ｗｅｂブラウザー・ソフトウェアは、画面上のコンテンツ情報を人に公開するためのツールであって、そのためにいつでも同一「ＵＲＬ（Uniform Resource Locator）」の画面提供という表現形式が考えられた。このため、これまで、画面を瞬時に白紙化状態するなどということは無意味なことと考えられていた。しかし、Ｗｅｂのシステムによっては、これを悪用された場合、便利なツールが一変してミラー・ブラウザー（遠隔覗き見）のような情報の漏洩ツールと化す。ある意味、諸刃の剣でもある。
現Ｗｅｂブラウザーの〔ＵＲＬ〕とは、文字通り同一画面を提供することなので、正規利用者がアクセスする時間帯が分かれば、防備の甘いログインシステムの場合、ミラー・ブラウザーは日常茶飯化し、脅威に晒される。これは、利用者が気づかないうちに行われているため、不正アクセスを認識・確認することができないので、発覚もしない。つまり、気づけないから発覚も探知も知る術がなく、いわば知らぬが仏状態でいられる。
【００３０】
上記本発明の「表示済ＵＲＬの自動廃棄処理」とは、具体的には、「時間のズレ応用技術」、「データの移動応用技術」、「重複ＩＰアドレスの検出」（ネットワーク上のグローバルＩＰアドレスを以下「ＩＰアドレス」という。また、本発明で「結合ＩＰアドレス」という場合、「ＩＰアドレス」の先頭もしくは後尾に適宜な数字を結合することを指す。）の３つの異なるタイプの仕組みを、個々独立してあるいは適宜組み合わせて応用・活用する技術である。
当該技術は、Ｗｅｂブラウザーの画面表示は、１回表示されると人が人為的に操作しない限り、表示した画面のままを保持しつづける（端末内のキャッシュ(cache)メモリに一定期間データが記憶される）表示特性の応用である。これは、端末キャッシュ・メモリからの記憶データの反映表示の活用である。利用者にとって１回表示されれば、閲覧そのものに特に支障が生じない、このことを前提としている。
本発明の自動廃棄処理技術は、このようなＷｅｂブラウザー画面の表示特性を応用し、また上記の３つの異なるタイプの仕組みを独立してあるいは組み合わせて応用・活用することができる。
以下、本発明の「表示済ＵＲＬの自動廃棄処理」に関する３つのタイプの仕組み・機能等を各自説明する。
【００３１】
うち、「時間のズレ応用技術」に関して説明すると、時間の誤差が生じる仕組みは、ボットネットとシステムの正規利用者が、同時アクセスしたと仮定してみると分かり易いかもしれない。この場合、随伴アクセスであっても、ボットネットの通信は基本的に後追いになる。そうすると、先着の正規利用者が１回画面表示したことで、２回目の表示を停止する機能が作動するため、後着のボットネットは、これと同一画面を見ることができなくなる。すなわち、これが、表示済〔ＵＲＬ〕に限定しての封印措置である。
【００３２】
これは、画面表示と同時に記録媒体に表示時刻を記録させることで、この表示時刻は時間の進行に伴って既に過去時間となることから、このような事象を生起させことができる。サーバー時計（グリニッジ時）がこれを判定すると、サーバー時計は、常に現在進行時刻を元に判定するから、当然、そこに「時間のズレ」が生じることになる。よってこのことは、「秒の壁」が創れることを意味する。
この「時間のズレ応用技術」は、インシデント対応型の項で後述する「スライド時間」の概念と共通する。本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「時間のズレ応用技術」は、このような時間のズレを応用することによって、秒遅れの〔ＵＲＬ〕でアクセスしても画面表示ができないことから、〔ＵＲＬ〕が自動廃棄される仕組みとなること、及び当該仕組みはＰＯＳT・ＧＥＴパラメーターに兼用できることを特徴としている。
【００３３】
次の「データの移動応用技術」とは、〔ＵＲＬ〕に含まれるカレント性（目下、現在進行形）を有したデータを各ステップごとに媒体に記録し、ステップ移動時にそれを自動的に削除していくと、記録によって「存在」、削除によって「不存在」の状況が自ずと創り出されることになる。そうすると、「存在」の時に画面を表示し、「不存在」の時に画面を表示しない仕組みにすることができる。当然、この逆も応用できる。
本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「データの移動応用技術」は、このようなカレント性媒体に記録したデータを「存在」又は「不存在」と判定することによって、ブラウザー画面を表示又は不表示（もしくはその逆）に制御することを特徴としている。
【００３４】
このように「存在」「不存在」が確定する仕組みにすることで、正規利用者より常に後追いアクセスになるボットネットは、データ「不存在」の状況に恒常的に直面することになる。これは、利用者と随伴アクセスによってシステムに侵入しても、「アクセス履歴」の〔ＵＲＬ〕を辿って後追いアクセスしても同様である。
【００３５】
次の「重複ＩＰアドレスの検出」とは、具体的には、ロボットがＩＰアドレスを偽装する、あるいは中継ぎ用の踏み台を介在させていることを指す。本発明による「重複ＩＰアドレスの検出」の仕組みは、重複ＩＰアドレスを随伴現象(an accompanying phenomenon)として捉え、これをそれぞれ分離することによって照合の手段とする。
これに関しては、先ず「重複ＩＰアドレス」が検出される根拠について説明する必要がある。すなわちこれはボットネットが自らの犯跡を隠すために、踏み台とする中継サーバーや個人の端末、もしくは認証サーバーを中継（「踏み台端末」）に利用することによって起きる、ステートレス通信特有の必定事象である。
すなわち、インターネットの通信は、１通信（データ・ダウンロード）毎に接続が初期化されるため、例えばＡとＢのようにダブルもしくはトリプルのＩＰアドレスが交互に入れ替わって現れても、その都度、通信が仕切り直しされて接続されるので、それをチェックする仕組みを持たなければ、それぞれが別々の単体のＩＰアドレスと認識される。また、ＩＰアドレスが重複した場合、通信には「先行」「後行」という事象が生じることになるが、これもそれを判定する仕組みがなければ、うち一つは通過する。結果としてアクセスの主導権を得た一つのＩＰアドレスだけが順当に接続されていく。このようにステートレス通信とは、基本的に常にＺｅｒoからのスタートとなる。
【００３６】
クラッカーによるボットネットはこれを悪用しているとも言えるが、もともとＨＴＴＰ通信は、発信元のＩＰアドレスが存在しない、ということは、自分宛に通信データが戻らないことになるので、このような辻褄合わせの事情から行われていても、結果的に犯跡を隠そうとしたつもりがＩＰアドレスの重複という随伴現象になる。これを露見・顕在化させる技術が本発明の当該「重複ＩＰアドレスの検出」の仕組みである。また随伴現象を検出するプログラムである。
しかも単にボットネットの侵入をブロックするだけでなく、利用者は何の支障なくシステムを引き続き現在進行形で利用できる並列処理構造を有している。
本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」は、このような随伴現象を露見・顕在化させる手段並び利用者のノンストレス、ノンストップな機能・利便性を具備した並列処理が可能なことを特徴としている。
【００３７】
「重複ＩＰアドレスの検出」の仕組みは、基本的に適宜な位置において一方の「原本ＩＰアドレス」の先頭もしくは後尾に適宜な数字を結合すると、一方は「結合ＩＰアドレス」、他方は「原本ＩＰアドレス」のままになる。このことから照合不一致を検知することが可能になるので、これを応用している。又は、双方の「原本ＩＰアドレス」に適宜な「結合値」を連結して複数の「結合ＩＰアドレス」を作出し、適宜な位置において、それぞれの「結合値」を抽出し、別の「結合ＩＰアドレス」に交換結合することによって照合不一致を検知する。
上記のうち、後者の方は、ステップの移動後にこれが行えるので、記録媒体を活用することで、例えば「結合値」をステップ到着時間等にすることによって、偶発・流動値が得られることから、これの偽造は困難であるため、「ＯＵＴ」時データの真偽検証用途に応用することができる。
すなわち、本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」は、このような適宜な数字を結合化したＩＰアドレスと原本ＩＰアドレス、もしくは異なる「結合ＩＰアドレス」同士を各自対峙させ、これによって不一致を誘導する仕組みとすることで重複化したＩＰアドレスの検出を可能にし、並びにステップの移動時にこれが行えるので「ＯＵＴ」時データの真偽検証用途にも応用できることを特徴としている。
【００３８】
従来、不審なＩＰアドレスは、ブラックリストに一旦、登録しておいて次回から、これを照合ブロックするという方法が在来の技術ベースの主流となっていた。これは、ＩＰアドレスが重複した場合、少なくとも初回に限っては、どちらか一方を「不正・不審」と決めつける根拠がない等の理由による。このため、ＩＰアドレスに数字を結合して「結合ＩＰアドレス」のようにしても意味がなく、また必要性もなかった。従ってパケットデータとして流れてくる現在進行形の随伴ＩＰアドレスを対峙させ、リアルタイムに、照合ブロックする手段として活用することがこれまで必要とされなかった。
また、「．」付きのＩＰアドレスをそのまま対峙させても限定的にしか比較照合ができない。これらの理由から照合手段としての位置付けがされず、軽んじられ、むしろ照合手段としては有用と看做されなかった。これらは、ＩＰスプーフィングの例を挙げるまでもなく、ＩＰアドレスの「正当な一方」を割り出すことに、これまで固執してきたことが根底にあるものと考えられる。いわば既存の技術ベースの盲点である。
【００３９】
また、前記したように基本的にＩＰアドレスをセキュリティー手段として活用する場合、ソフト面よりもむしろハード面の方に重点が置かれ、例えばファイアウォール、ルータのトンネリング手法（特定のＩＰアドレスを持つパケットだけを通過させる）などハード依存型の技術として、セキュリティー強化を図るのが既存技術のベースの主流となっていた。これは、識別・判定手段としての根拠・信頼性においてネットワーク上でＩＰアドレスが急遽、変更された場合の対処の問題が根底にあった。すなわち、そのような場合の緊急時に臨機応変に対処する仕組みを創出することが困難だった。このため、ソフト面ではさほど重要視されてこなかった。
本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」は、「随伴現象」を露見・顕在化させる単純・単一の仕組みなので、応用範囲としてソフト面のみならず例えばＩＰスプーフィングのような事例等に対処するハード面のモジュール・プログラムとしても適応・補填できることを特徴としている。
【００４０】
本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」は、特定のＩＰアドレスを対象としたものでもノードアドレスでもデータグラムでもなく、あくまで発信ＩＰアドレスが重複する、その「随伴現象」をそもそも不審と見做し、それを「不正な通信」の判定根拠にしていて、かつ、システムのアクセスルート、すなわちページ内のどの位置に当該検出手段を配置しても特に問題はなく、検出できることを特徴とする。
これは、例えばネットワーク上のトラフィック・輻輳トラブル、停電等でＩＰアドレスがタイムリーに入れ替わり変更される場合が生じてもそれは発信元ＩＰアドレスが重複することはなく、あくまで単一である、という通信プロトコルに拠っている。
本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」は、配置する位置状況によっては認証確定に至る過程以前のアクセスルートの段階で「随伴現象検出プログラム」が発現して「随伴現象」を露見・顕在化させることが可能となる仕組みを有することを特徴とする。
【００４１】
従って、「重複ＩＰアドレス」から随伴現象(an accompanying phenomenon)を検知・検出することで、ログインシステムのアクセスルートを、確実に遺漏なくロボットからブロックできる。
クラッカーが［成りすましログイン］を実行する場合、前記したように多様なパターンがある。１つ目のパターンは、そのシステムの会員利用者の端末を「踏み台」として利用するパターン。２つ目のパターンは、会員利用者の端末を経由せずに第三者の端末を「踏み台」として利用するパターン。３つ目のパターンは、これらのいずれにも該当しない特殊なもので、第三者の端末を「踏み台」として認証サーバーを経由するパターンである。これは、メインのシステムとは別運用の「認証サーバー」などで起こり得る事例である。しかもこの場合、本システムに戻ったデータは認証済みになる。
とりわけ「画像認証」（ＣＡＰＴＣＨＡ）を手段とするログインシステムの場合、このような裏をかかれた［成りすまし］が行われると、対処する術がない。ＣＡＰＴＣＨＡは、もともとシステムの「ＦＯＲＭ」を通じてチュ−リングテストを行うことを前提にして構築されており、「画像文字」の生成発行、照合処理を目的とするサーバーである。
しかし方式・次元を異にすれば、この前提も簡単に崩される。Ｗｅｂブラウザーの許容値範囲（バイト数）内の連結パラメーターに「判読文字」を幾重にも織り込んで、何度も送り付けて来られると、「認証サーバー」は、「判読文字」を判定処理することを本来の使命とするサーバーなので、それが合致すれば、この実行者はロボットではない、すなわち「人」と判断する。しかもメインシステムと運用が異なるため、「ＩＮ」データの真偽を検証する手段がない。
一説では、ＯＣＲ（自動文字読取）を実装したマルウェアによってＣＡＰＴＣＨＡは突破されたといわれている。しかし、もしそうだとすると、このマルウェア（ＯＣＲ）は、踏み台の端末、もしくは認証サーバー、又はメインのシステムのいずれかに潜伏していて、ロボットのログイン実行時に同時連動・稼働していたことになる。ましてＷｅｂブラウザーの許容値バイト数から考えると、ログイン実行時に同時進行でマルウェア（ＯＣＲ）をインジェクションすることは殆ど不可能である。
更に会員利用者の端末を経由する方法も、会員利用者がログイン中にその通信セッションに割り込んで行うものと、会員利用者が未ログインであるにも関わらず利用者の端末を経由して行う２通りのパターンがある。よって４つ目のパターンがこれになる。そうすると、後者の方は、会員利用者とは別途の第三者の端末を使って［成りすましログイン］を行った事例と全く同一の様態になる。これは、前記したように重複ＩＰアドレスによる通信には「先行」「後行」という事象が生じるので、アクセス主導権を握った方が常に「先行」となるからである。
剰えこの事例は、端末に攻撃プログラムを常駐させることで、ＤＤｏＳ攻撃への転用が可能になる。そして端末ユーザーは自己が攻撃加担型「踏み台端末」にされたことにすら気づかないうちに加害者になる。
第三者の端末を「踏み台」とするパターンも、利用者が未ログインの端末を「踏み台」とするパターンも基本的に端末所有者の不在を狙った不正アクセスであり、かつクラッカーにアクセス主導権を握られている。
なお、利用者が未ログインで電源ケーブルを抜いていても端末にはバッテリーが装着されているのでネットの通信ケーブルを抜いていない限りこれは起こり得る。
【００４２】
更にこれを分析すると、［成りすましログイン］には、２つの手法パターンがあることが分かる。一つは、［表ルート］から侵入する手法。もう一つは、［裏ルート］から侵入する手法で、この［裏ルート］の場合、ボットネットは、「踏み台」として、会員利用者の端末とは別途の端末もしくはサーバーを中継・介在させて、システムに不正アクセス（侵入）することになる。
【００４３】
なお、［表ルート］というのは、会員利用者の端末を「踏み台」にして不正アクセスすることを指す。［裏ルート］とは、会員利用者の端末を「踏み台」にせずに他の第三者端末・サーバー等を「踏み台」にして、対象システム・サーバーへかつ、対象利用者のアクセス権（ログインパスワード・ＩＤ等）を奪って不正にアクセスすることを指す。
このような［表・裏ルート］の使い分けが用いられるのは、ロボットの場合、「ＦＯＲＭ」のボタンを押せないので連続して次のステップに移れないからである。
しかしロボットのこのようなハンディも、Ｃｏｏｋｉｅ・セッションＩＤの仕組みを応用した既存のシステムでは、ステップの飛び越えが可能なため、もしくはステップの移動、特に「ＯＵＴ」時の通過を検証する手段がないため、裏をかかれたことになる。
【００４４】
３種類のパターンがある「踏み台端末」のうち、問題となるのは、司令サーバーが端末に介在してＤＤｏｓ攻撃用途に加担させるパターンである。仮に司令サーバーが介在するパターンが、もし単独に存在しているとすると、ＤＤｏｓ攻撃加担用途専用のマルウェアも存在していることになる。しかしそうだとすると、まだ攻撃対象が決まらないうちから、ＤＤｏｓ攻撃用途に専ら加担させるためだけにネットワーク上に感染媒体を仕掛けておかねばならなくなる。またそのような不特定多数の中から「踏み台」専用端末をどうやって見分け区分けし確定するか、という問題も浮上する。
もっとも傭兵の頭数を揃えておいて戦を始めるという戦法もあるので、不特定多数な頭数を揃えるのは当たり外れを考慮しての保険的措置とも言えなくもない。しかしこのように考えていくと、「踏み台端末」は、使いまわしと考えた方が自然である。一種の転用使いまわし、流用使いまわしである。
本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」は、随伴現象(an accompanying phenomenon)を検知・検出することで、メインシステムとは別運用の「認証サーバー」並びに被ＤＤｏＳ攻撃対象サーバーなどでも「随伴現象」を露見・顕在化させることが可能となる仕組みを有すること、及びメインシステムから画像認証サーバーへ送られるＰＯＳＴデータに予め「クエスチョン・マーク」を付さないプログラム仕様にすることで、「画像認証サーバー」宛送り付け連結パラメーターに対し「クエスチョン・マーク」を除去して、これにより通信エラーを惹起せしめ、又はこの連結パラメーターに対しＣＡＰＴＣＨＡの「判読文字」のみを該当「ｎａｍｅ」から除去する仕組みを当該「随伴現象検出プログラム」に組み込めることを特徴としている。
【００４５】
しかしながらどのように偽装しても、もともと出処の異なるＩＰアドレスが存在することは、紛れもない事実であり、本発明の、「随伴現象検出プログラム」は、これを確実に捕捉して分離させ照合することが可能である。
本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」は、このような出処の異なるＩＰアドレスを補捉して分離するための照合手段を有していることを特徴としている。
【００４６】
これは、実は、ウィルスが端末内にこのまま常駐しつづけるか、踏み台端末として転用されるか、という問題と密接に絡んでくる。それを判断するのはロボットではない、人である。すなわち現状のウィルス駆除ソフトの機能・実行・処理は不正プログラムの排除・フィルタリングである。ウィルス駆除ソフトは、前記のようなボットネットの小道具プログラムを利用者の端末内から排除する一定の効果はある。
しかし、ボットネットのプログラムを遠隔操作していたのは、ひとである。このことは、利用者の端末内に潜伏・常駐して利用者の内情を探るスカビンジング行為をするなどして、これまで時間を要して周到に探索活動を行っていたことを意味する。
【００４７】
メールによる情報のやりとりは無論のこと、顧客情報などの保存ファイルの殆どは盗まれている。特に「端末情報」「プロバイダー情報」「利用先システムの情報」はボットネットの実行者・クラッカーに筒抜けである。
しかしながら現況のウィルス駆除ソフトには、それらの盗まれた情報をボットネットのサーバーから消去・消滅させることは出来ない。従ってこのような事実からすれば、ボットネットの脅威をなんら払拭できたわけではないことになる。
【００４８】
すなわちこれは、ウィルス駆除ソフトによってウィルス（小道具プログラム）の排除が仮に実行されても、このターゲートの利用価値が高ければ、今度は手を変え、品を替えして、不特定多数から「特定多数」に切り替わることになる。また、このターゲートの利用価値が低ければ、単なる踏み台端末として転用の途が残されている。役割分担が初めから「踏み台端末」として決まっている端末など存在しないと考えた方が自然である。それは、手間のかかる選定作業や確定に至る手順から考えても、そんな効率の悪いことはしないことになる。
【００４９】
よって、本発明に係る表示済ＵＲＬの自動廃棄処理技術のうち「随伴現象検出プログラム」は、少なくともログインシステムに特化した手口・シナリオ型の現況のウィルスを、結果的に無意味・無害化するという意味から既存のウィルス対策ソフトを相互補完すること、並びに従来限定的にしか照合結果を得られなかったドット付きの現形ＩＰアドレスを、数字等を結合化することによって他の媒体との組み合わせパターンのバリエーションを広げられることに最大の特徴を有している。
【００５０】
なお、前記ブラウザーの画面表示制御に用いる文言もしくは画面の白紙化状態に関しては、特にこれと限定することなく、適宜なメッセージ等が望ましいが、本発明の要旨はあくまで「情報漏洩」の遮断、あるいは「悪意の情報収集」の遮断にある。更に本発明の主旨は、ボットネットの攻撃（脅威）をシカトすることにある。
【００５１】
上記、ア２）の課題のうち、インシデント対応型に関しては、前記「時間のズレ応用技術」「データの移動応用技術」「随伴現象検出プログラム」を一体的・発展的・総合的に組み合わせる他、新たに本発明の［遮断］の仕組み技術を「セッション・セキュリティー層」としてシステムに実装することで、これを独立させ、セキュリティー面を格段に強化した［セッション管理］を図るという方法、並びに［閲覧に特化した管理］を制御処理できる仕組みを別途、システムに導入することでこれを解決する。
【００５２】
セキュリティー面を強化した［セッション管理］とは、基本的には、A）データを窃取されないようにする仕組み（流出漏洩）のことで、［閲覧に特化した管理］とは、B）データを閲覧できないようにする仕組み（プレビュー漏洩）をシステムに設けることであり、両者ともインシデントに対する懸念を払拭するための技術である。
これを具体的にイメージすると、外部から仮に端末やシステムに侵入されても情報漏洩が発生する虞を皆無にし、遠隔地の限られたメンバーだけで機密情報を同時進行でインタラクティブに、そして対話型にやり取りすることができ、かつ、グループウェアやＳＮＳ投稿に近い機能を有して用途・業種ごとに特化した「インシデント対応型ログインシステム」の実現ということになる。
すなわち、「ENCTYPE=’multipart/form-data’」を設けたアップロード機能送信ＦＯＲＭの場合、ＣＤ−ＲＯＭからデータを直接取り出して転送することができる。このことは、機密性の高い情報を端末内に保存しないスタイルを、ユーザーが自ら自身の端末をカスタマイズすることが可能になる。
【００５３】
もともと［遮断］の仕組み技術を有しない既存のログインシステムとＷｅｂブラウザーによるセッション管理では、インシデントの問題を殆ど解決できない。例えば、システムが抱える脅威にセッションハイジャック（セッションＩＤの漏洩や窃取されることによる成りすましログイン等）やディレクトリ・トラバーサル（エンド・ディレクトリ内に保存されたセッションＩＤ等の記録情報を、システムの通常アクセスルート〔絶対パスによる要求ＵＲＬ〕を介して不正に情報を読み出し、窃取する攻撃手法）の問題があり、現状、これらの攻撃に対して、システムの実装プログラムが脆弱性を克服できているとは言い難い。逆にＷｅｂブラウザーの「Ｃｏｏｋｉｅ・ブロック」を活用すればシステムが使えなくなる。
更にＷｅｂブラウザーにはミラー・ブラウザーのような「悪意の情報収集」の脅威がある。この外、パスワードクラッキングの脅威も、現状のＣｏｏｋｉｅを基本にした認証手段では防御できてはいない。
また、システム以外の脅威に、メールの受信後はスパイウェア等の格好の標的になることも懸念材料になる。また、ファイル交換ソフト（Ｐ２Ｐ）による感染拡散も脅威である。よって、既存の技術では、上記のような本発明の「インシデント対応型ログインシステム」の実現は、技術的に殆ど困難である。
【００５４】
上記のような本発明のインシデント対応型ログインシステムを具体化するには、基本的に既存のメール送・受信手段に対置する、別様の［伝送］［提供］の手段を確保することが必須になる。これは、メンバーがインタラクティブな情報共有ツールとして活用するには、文書、画像、音声、動画、ＤＴＰ、圧縮・解凍などのＭＩＭＥ形式系データが不可欠となるからである。Ｗｅｂブラウザーは多岐の通信処理プロトコルに対応しており、多種多様の拡張子を扱える点で多角的なパフォーマンス性を提供・実現できる。ここで云う多角的なパフォーマンス性とは、音声・動画などの視聴覚的媒体やページのレイアウト構成面（ｈｔｍｌメールのような）等を指す。
しかしＷｅｂブラウザーは、情報の［伝送］（送信）と［提供］（閲覧）の公開を主目的とするツールである性質上、情報の漏洩や窃取されることに対してもともと無頓着・無防備であり、［遮断］の仕組み技術そのものがベースにない。
また、インシデントの問題を解決するには、ＭＩＭＥ形式系データを個別ファイルとしてメールに添付し、メール・サーバーに送り、これを先方が受信する既存の方法では達成できない。
【００５５】
そこで本発明の「インシデント対応型ログインシステム」では、送信手段に前記アップロード機能送信ＦＯＲＭを設け、ＭＩＭＥ形式系データをＨＴＭＬページに埋め込んで直接、ｈｔｍｌメールのように出力表現できる方法でこれに対処する。上記の「グループウェアやＳＮＳ投稿に近い機能」とは、このことを指す。仮想上のイメージとして、これを「サーバー内図書館」ということができる。従って、既存のメーラーを一切、使用しない。むしろ、メーラーの代替として本発明の「インシデント対応型ログインシステム」を利用する。また、ＦＴＰソフトもシステムの管理者以外これを認めない。更に、基本的にデータの受信後はプリントアウトが必要、もしくはそれが望ましい。
本発明のインシデント対応型ログインシステムのうち、業種ごとに特化した業種別フォーマットを活用することで、ワード・プロセッサ専用フォーマット（上書き不可のＣＤ−ROM）に保存したワープロ文書を自己専有媒体に転送し、上記［サーバー内図書館］においてこれをサーバー内で書き込み作成・編集することができる。
【００５６】
情報のやり取りを基本的にサーバー内に限定する方式である。メンバーが受信したデータを閲覧する場合、「サーバー内図書館」のみで閲覧することで、基本的には、B）プレビュー漏洩を阻止・制御することができる。
すなわち、Ｗｅｂブラウザーをツールとして本発明の「インシデント対応型ログインシステム」を実現するには、従来の［セッション管理］の仕組みを強化するだけではインシデントの問題を解決できない。［セッション管理］は、ボットネットをシステムに直接侵入させない仕組みであって、むしろA）流出漏洩（データを窃取されないようにする仕組み）の方に属する。
これに対して、B）プレビュー漏洩の方は、クラッカーにデータを閲覧できないようにする仕組みである。これは、Ｗｅｂブラウザーがもともと閲覧用途に特化したツールのため、現状のままでは、例えば、「ディレクトリ・トラバーサル」のような絶対パスによる間接侵入に対しては無防備であり、蟻の穴から堤も崩れる、ことになる。
これには別途に、［閲覧に特化した管理］という仕組み技術が必要になる。閲覧に限ってこれを管理するための専用の仕組みをシステムに別仕様で設けることが不可欠である。従来の［セッション管理］に加え［閲覧に特化した管理］の仕組み技術を装備することで、既存のＣｏｏｋｉｅをベースにした「認証技術」とは全く異なるアクセス権の付与手段を創出することができる。これの詳細については後述する。
【００５７】
なお、セキュリティー面を強化した［セッション管理］のなかには、「偽装ＩＰアドレス」「パスワードクラッキング」「セッションハイジャック」「ディレクトリ・トラバーサル」「送り付けパラメーター攻撃」の脅威に対する特化型の技術的対応策・回避策を含み、以下に記述している。
上記のような攻撃に対し、以下、これの対抗策をそれぞれの攻撃事例ごとに示す。本発明の「インシデント対応型ログインシステム」では、インシデントの問題をこれら対抗策によって基本的に解決する。また、各対抗策については順次概略から詳述に移り説明する。
【００５８】
まず「偽装ＩＰアドレス」に関しては、〔当日アクセス情報〕をこれに対置することで解決する。〔当日アクセス情報〕とは、メンバーに対して当日限定のアクセス権を付与するためのものであって、一種のページ（ステップ）「在籍証明書」に相当する。このことから、本発明の「インシデント対応型ログインシステム」のうち、〔当日アクセス情報〕には、基本的に［ログアウト］を必要としていないので、メンバーの［ログイン］判定は、「当日初回」、「当日２回目かそれ以降」、という捉え方になる。
なお、〔当日アクセス情報〕の記録媒体は、「カレントＩＰアドレス記録媒体」である。ここには、初回ログイン時の基礎データが記録される。基礎データには、「当日日付」「当日通し番号」「ＩＰアドレス」「メンバーアカウント」「［指名］媒体ニックネーム」「［全員］媒体ニックネーム」などのデータである。「［指名］媒体ニックネーム」・「［全員］媒体ニックネーム」については、後述するが、メンバーが、閲覧ページを検索するとき必要になる。閲覧ページのガイドダンス媒体には個々に媒体識別ニックネームが付けられていて、これを随時「対応表」から取得する。
システムに接続されると、最初にトップページが画面表示される。ここには次のページに移るための「ＰＯＳＴボタン」が設けられていて、ここで当日の通し番号検問が常時チェックされている。また、この「ＰＯＳＴボタン」を押すことで、メソッド判定が「ＰＯＳＴ」と判定できるので、メンバーのＩＰアドレス等のデータが保存された「ＩＰアドレス履歴記録媒体」で自動的にメンバーのＩＰアドレスが接続判定される。
この「ＩＰアドレス履歴記録媒体」には、「ＩＰアドレス・パターン数字」と「メンバーアカウント・パスワード桁数」が、そのバイト（桁）数に応じて別々に記録保存されている。これによりまず、メンバーの発信元ＩＰアドレスと同一のＩＰアドレスが実在すれば「無変更」、実在しなければ「変更」が一次的に確定できる。
【００５９】
その照合手段は、トップページ内に「ＩＰアドレス履歴記録媒体」へ直結するアクセス導線を設け、メンバーのＩＰアドレスが抽出・検出できる「単項目検索構文」を媒体対応数だけ配置することで可能である。この場合、「ＩＰアドレス履歴記録媒体」へ直結するアクセス導線には、メンバーのＩＰアドレスが通信パケットに在中されているので、複数の保存媒体に対して、逐次、単一検索構文が順次処理していくことができる。すなわち、メンバーのＩＰアドレスのバイト数を確定することで、該当保存媒体をダイレクトに把捉することができる。
ここで云う、複数の保存媒体、とは、ＩＰアドレスは、３桁の数字の列にドットを付して４つ並んでいて、最大１５バイト、最小７バイトになるので、バイト数別に保存されている、ということを指す。そうすると、例えばトップページで１５バイトのＩＰアドレスが検出されたとすると、１５バイト用の「保存媒体」のなかにしか存在しないので、「単項目検索構文」もその対応数だけ設け、その媒体へ直結するアクセス導線を引いておけば、該当媒体への処理が図られ直ちに存在の有無を割り出し、確定判定させることができる。
例えば、検出ＩＰアドレスが１５バイトだとすると、＜META HTTP−EQUIV=”Refresh”CONTENT=’0;URL=”１５バイト用媒体向けＵＲＬ”’＞（もしくは、＜IFRAME SRC=”１５バイト用媒体向けＵＲＬ”＞）のようにすることができる。当該＜META＞タグの場合、そのURLは絶対パスになる。
これを接続ＩＰ判定という。すなわち、メンバーのＩＰアドレスが現状のままか、あるいは変更されているかを直ちに割り出し判定する。更新されている場合、自動的に１件の「更新追加記録」データ（「ＩＰアドレス・パターン数字」）が記録保存される。
ＩＰアドレスが保存された方を「バイト数別Ｉｐ媒体」、メンバーアカウントが保存された方を「バイト数別Ｍａ媒体」という。うち、「Ｉｐ」はＩＰアドレスの略称、うち、「Ｍａ」はメンバーアカウントの略称。「バイト数別Ｉｐ媒体」の方は、８つの媒体に、「バイト数別Ｍａ媒体」の方は、メンバーのパスワード桁数６〜９の４つの媒体に振り分けて保存されている。メンバーが当日初回ログインの場合、自身の「メンバーアカウント」の照合に最初に入らなければならない。これには、「メンバーアカウント」を照合する媒体がパスワード桁数６〜９に振り分けて保存されているので、この入力条件も必要になる。
【００６０】
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、外部ネットワークを経てトップページに至ったメンバーのＩＰアドレスを初期照合・抽出・検出する手段は、トップページ内に記録媒体（「ＩＰアドレス履歴記録媒体」）へ直結するアクセス導線を設けて行い、その単一検出・照合する方法は、単一検出・照合が実行可能な「検索構文」を保存媒体に対応する数だけ配置して行うか、もしくは一つの「検索構文」が複数の保存媒体に対して順次単一検出・照合が実行可能な「検索構文」の仕組みによって行い、以って適宜対応処理することを特徴としている。
また、本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、トップページにおいて各媒体に記録される「当日通し番号」の番号連続性の整合が通し番号検問によって常時チェックされていて、当該通し番号検問の順番確定を参照することで、副次的に媒体記録時の排他制御を補佐すること、及び飛び番号・同一番号等不整合な「当日通し番号」を検出した場合ルートの遮断が実行処理できることを特徴としている。
更に本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、「当日通し番号」のスタート番号が日ごとに加算され、あるいは予め決めてある数字に達したとき番号が飛び番号になるような対応表を有していることを特徴としている。
【００６１】
但し、接続ＩＰ判定の前にツインズＩＰブロックによるチェックが行われる。「ツインズＩＰブロック」とは、基本的に重複ＩＰアドレスの「随伴現象」を検出する技術であるが、ここでは、特にロボットがメンバーの端末を踏み台として［端末ＩＰアドレス］同伴で侵入した場合を想定する。仮にメンバーのＩＰアドレスを偽装して侵入した場合、ＩＰアドレスが重複していても双子のように［同一］という事象、もしくは［単一］となる事象が起こり得る可能性が考えられる。この事例では、利用者がログイン中あるいは未ログインを問わない。むしろ当日初回ログインか、当日２回目かそれ以降の条件の方が重要になる。
そこでこの場合、「原本ＩＰアドレス」に接続時の秒数等の流動値を結合する。そうすると、ＩＰアドレスが重複していた場合、「随伴現象」が露見する。これによるログイン中の正規のメンバーへの影響はなにも生じない。
正規のメンバーに、仮に上記のようなツインズＩＰブロックによるチェックが行われても、メンバーの場合ＩＰアドレスはもともと金太郎飴の断面のように単一であり、重複していないので、例えば、「２２１.１６.８１.３５」のＩＰアドレスに秒数「３８」が結合されても「２２１.１６.８１.３５３８」のような［単一］になるだけで、他の数字に変化することはなく、同一ＩＰアドレスが対峙する。
メンバーがログイン中にセッションに割り込んだ場合は、メンバーは先行、ロボットが後追い、かつロボットは自己のＩＰアドレスを持ち込んでいるうえ、メンバーのログイン操作の結果情報が自動的にロボットにそのまま反映されるわけではない。また、メンバーが未ログインでロボット単独侵入（端末侵入による［端末ＩＰアドレス］）の場合は、［同一］という事象の可能性が考えられるが、この場合も自己のＩＰアドレスを持ち込んでいる。重複ＩＰアドレスによりロボット自滅ということになる。
このような場合のアクセス条件は、ロボットが単独でシステムに侵入して接続ポイントを通過する場合、要求ＵＲＬが絶対パスになるので、メンバーがログイン中にセッションに割り込んだ方がそれを回避できる利点を得られるだけのことになる。
ロボットは、通過するのが目的ではなく、この場合の目的は、「メンバーアカウント」を照合するための「プルダウン式入力認証ＭＡ」のＦＯＲＭの攻略になる。従ってメンバーが未ログイン中に、メンバーの端末を経由して［端末ＩＰアドレス］を使って行われるロボットの不正ログインも要求ＵＲＬは絶対パスになる。かつ、先行、後追いの条件がないので単なるメンバーの［端末ＩＰアドレス］と同伴ということになる。ただ［同一］事象を得られる可能性はゼロではないので無視できない。
【００６２】
しかし、ロボットによる偽装重複の場合、一方は他方と［同一］を装うためにメッキ状態になっているだけで、それぞれの原本ＩＰアドレスは、ダブルもしくはトリプルで存在する。従ってこの場合、ステートレス通信の常に初期化される特性を逆利用して、メッキ状態に化ける瞬時に刺激（秒数等）を与えることによって、すなわち流動値を結合することで、メッキのはく離を誘導するか、もしくは異なる他方に刺激が転移することになるので、どちらか一方のＩＰアドレスが変化することになる。基本的にこれがツインズＩＰブロックを誘発させる仕組みの主旨である。
更に自動化されたロボットの不正プログラムの最大の弱点はＧＥＴパラメーターなので、「ドメイン」「クエスチョン・マーク」を検出し、３０５送信エラー、もしくはＧＥＴパラメーターの総バイト数から、「ドメイン」と「クエスチョン・マーク」のバイト数を減算し、当該ＧＥＴパラメーターを減算値に短縮して実効性を削ぐこともできる。
【００６３】
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、ロボットがメンバーの端末を踏み台にして［端末ＩＰアドレス］を偽装して侵入した状況を想定し、これを阻止する手段を保存媒体へ至るアクセス導線に複数配置して判定できるようにして、その判定対象の「原本ＩＰアドレス」にシステム接続時の秒数等の偶発性・流動値を結合することで、重複ＩＰアドレスによる「随伴現象」を作為的に作出・露見させる前記「ツインズＩＰブロック」でルートを遮断し、あるいは予めＰＯＳＴデータに「クエスチョン・マーク」を付さないプログラム仕様にすることで、ＧＥＴパラメーターから「クエスチョン・マーク」を除去して３０５通信エラーを生起させ、もしくはＧＥＴパラメーターの総バイト数から「ドメイン」と「クエスチョン・マーク」の合算バイト数を減算し減算値バイト数に短縮して実効性を削ぐことで、これによって該当ＩＰアドレスの通過ルートを遮断すること、並びに一旦、更新追加記録されたデータの取り消しもしくは保留措置が講じられることを特徴としている。
本発明のインシデント対応型ログインシステムでは、このようにして上記「バイト数別Ｉｐ媒体」に実在しないＩＰアドレスに対して、システム内を徘徊したりランニングしたりジャンプしたりすることを一切禁止することができる。
【００６４】
次に接続ＩＰ判定を経ると、必ず「メンバーアカウント」の入力が求められる。本発明のインシデント対応型ログインシステムでは、これを「プルダウン式入力認証ＭＡ」と呼ぶ。うち、「ＭＡ」はメンバーアカウントの略称。この「メンバーアカウント」は、「カレントＩＰアドレス記録媒体」と「ＩＰアドレス履歴記録媒体」の両方の媒体で別々に同時二面照合される。
すなわち、本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、「バイト数別Ｍａ媒体」と「カレントＩＰアドレス記録媒体」の並列同時の照合処理の仕組みは、どちらか一方で先行して行うと同時に、他方へ直結するアクセス導線を他方の検索構文に設けることで、通常ＩＤのような「メンバーアカウント」を単一に検索する構文がこれを並列同時に検出するので、同時に照合を図ることができることから、よって保存媒体とその媒体へ直結するアクセス導線及び該当データを検索する構文をこのような二列構成にすることで、同時二面照合することが可能になること、又は、隠しステップを設け、その媒体へ直結するアクセス導線の分岐送致手段を＜META＞もしくは＜IFRAME＞タグによって実行処理することを特徴としている。
【００６５】
そうすると、４つのパターンが確定する。１つ目は、ＩＰアドレスの方は存在しないが、メンバーアカウントは一致する。２つ目は、ＩＰアドレスは存在するが、メンバーアカウントは一致しない。３つ目は、ＩＰアドレスもメンバーアカウントも存在する一致する。４つ目は、ＩＰアドレスもメンバーアカウントも存在しない一致しない。
このうち２つ目と４つ目は、「メンバーアカウント」が一致しないので、４つ目のパターンのみは、登録メンバー以外によるアクセスということが、確認できる。うち、２つ目のパターンは、ＩＰアドレスを偽装しているか、もしくは登録メンバーによる入力ミスの可能性もある。
更に１つ目のパターンは、当日２回目かそれ以降でＩＰアドレスが「変更」。３つ目のパターンは、当日２回目かそれ以降でＩＰアドレスが「無変更」。
このように照合・判定が初期段階で実行され、「ＩＰアドレス履歴記録媒体」を相互補完する「ログデータ」と「第二認証媒体」へとデータが受け継がれ記録されていく。
【００６６】
ここで、先に「メンバーアカウント」（プルダウン式入力認証ＭＡ）の操作・照合の仕組みについて説明する。この文字入力は、１文字ごとプルダウン・メニュー（数字０〜９・アルファベットａ〜ｚＡ〜Ｚ）から文字を選択する「プルダウン式入力」になっていて、これが、パスワード桁数１個と８列横並びに配置され、更に送信ＰＯＳＴボタンの前に確認用のフィールドが設けられている。すなわち、人でしか操作ができない仕組みになっている。これは、キーロガー対策とロボットによる偽装ＩＰ侵入を想定しての防御措置である。
メンバーがパスワード桁数１個とプルダウン・メニューから「メンバーアカウント」の文字を８列選択し終え、先頭の複式操作ボタンを１回押すと、「ＭＡ確認フィールド」の中に選択した文字が充当表示される。ただし、トップページのＰＯＳＴボタンを押したことがここで確認されるので、それが確認できない場合、「複式操作ボタン」と送信「ＰＯＳＴボタン」が表示されない仕組みになっている。
また、「ＭＡ確認フィールド」が空白のままではJava Scriptアラートが表示され、先に進むことができない。従ってメンバーは、送信ボタンを押す前にこれを行うことが必要になる。これにより「ＭＡ確認フィールド」の中に文字が充当され「カレントＩＰアドレス記録媒体」と「ＩＰアドレス履歴記録媒体」内の「バイト数別Ｍａ媒体」の両方で前記した同時に二面照合される仕組みである。かつ、パスワード桁数６〜９を選択することで、６〜９のバイト数別に保存された「バイト数別Ｍａ媒体」との照合が可能となる。このような複式関連付け因果性照合となっている。
【００６７】
しかも、この複式操作をしないまま送信ボタンを押すと、そのＩＰアドレスに対して、それ以降のアクセスルートが遮断される。よってこのことから、上記２つ目のパターンの偽装ＩＰアドレスは、通過できなくなる。これは、通過を許可するＩＰアドレスを絞り込むためで、偽装ＩＰアドレスのようなロボットによる自動によるものと、クラッカー等が手動によって行うものの両方を先行予備的に排除する。この場合、送信データは上記した「バイト数別Ｍａ媒体」で照合されるので、クラッカー等が手動で、もしパスワード桁数（６〜９）の選択を誤ると、「メンバーアカウント」の照合そのものができなくなる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、「プルダウン式入力認証ＭＡ」の仕組みには、キーロガー対策が配されていて、１文字ごとプルダウン・メニュー（数字・アルファベット大文字・小文字）から文字を選択する「プルダウン式入力」が前記パスワード桁数１個と複数列横並びに配置されていること、更に選択文字確認用のフィールドが設けられていること、そして先行して複式操作ボタンを１回押すことで確認用フィールド内に確認用の選択した文字が充当表示されること、また、その次に送信ボタンを押すことが当該「プルダウン式入力認証ＭＡ」のクリア条件となる、このような複式操作の実行が不可欠であって、かつ、パスワード桁数を適正に選択することによってのみ、バイト数別に保存された「バイト数別Ｍａ媒体」との、当該複式関連付け因果性（トップページのＰＯＳＴボタンを押したことの確認、複式操作ボタンを１回押す複式操作及びパスワード桁数の選択）照合が可能となること、これにより前記「バイト数別Ｍａ媒体」に対してメンバーアカウントを検索照合することができることで、適正なアクセスルート先が確保されることを特徴としている。
【００６８】
ロボットが偽装ＩＰで侵入した場合、上記の「トップページのＰＯＳＴボタンを押さずに」「複式操作をしないまま」と同様のことになる。これは、ネットワークを経由してシステムに侵入するにはドメインを含む「絶対パス」でしかパラメーターを送れないため、パスワード桁数１個とプルダウン８列と「ＭＡ確認フィールド」とを予め結合したパラメーターを組み立てダイレクトに送り付けてくるからである。すなわち「複式操作」をすることができないための実行手口に他ならない。しかもこのパラメーターは、メソッドがＧＥＴになる。
そこでパラメーターに「クエスチョン・マーク」と「ドメイン」が確認された場合、前記したようにＰＯＳＴデータに「クエスチョン・マーク」を付さないプログラム仕様にすることで、次のようなルート遮断措置を講じることができる。
例えば人が操作するＦＯＲMの場合、＜FORM action=’./’ method=POST＞＜input type=hidden name=job value=members＞のようになる。一方、ロボットでは「http://domain/members?--------」のようなパラメーターになる。人が操作する方のＦＯＲMのこの場合の、「action=’./’」は、プログラム・ファイル名が「index.拡張子」で、「members」というディレクトリ内にこのプログラム・ファイルが存在していることを意味している。通常、ファイル名が「index」の場合、「action=’./’」のように省略できる。
そうするとこの場合、「カレントＩＰアドレス記録媒体」と「ＩＰアドレス履歴記録媒体」は、必ずしも「members」というディレクトリ内には存在していなくともよいので、「members」からその所在位置の「カレントＩＰアドレス記録媒体」と「ＩＰアドレス履歴記録媒体」を呼び出して照合するためには、それぞれの媒体が存在するディレクトリへ至るそれぞれ異なる「./../ 媒体名.拡張子」のような「媒体直通ルートパス」（アクセス導線）が設けられていなければ当初の目的を実効できなくなる。
アクセスルート遮断措置とは、具体的にはこの「媒体直通ルートパス」のカットを指す。媒体との導線経路がカットされることで、ロボットのＧＥＴのパラメーターは行き場を失う。
【００６９】
外部ネットワークを経由するメソッドがＧＥＴのパラメーターには必ず「クエスチョン・マーク」と「ドメイン」が存在するが、ＰＯＳＴにはそれが必要ではないので、上記の「媒体直通ルートパス」を「クエスチョン・マーク」と「ドメイン」の存在確認判定次第でカットすることができる。これにより以降のアクセスルートを完全に遮断するので、例えば、「ＩＰアドレス履歴記録媒体」と相互補完の関係にある媒体である「ログデータ」や「第二認証媒体」にも記録されなくなる。よってロボットが送り付けてきた「http://domain/members?--------」は、パラメーターの実効性としての効力が無効化される。
なお、呼び出すそれぞれの媒体が存在する位置に関しては、実行プログラム・ファイルが存在するディレクトリを起点にして、その階層位置が以降（その先）・以前（その前）を問わず、これを当て嵌めることができる。また、この「媒体直通ルートパス」のカットは、ロボットに特定・限定したものである。
【００７０】
そうすると、「カレントＩＰアドレス記録媒体」と「ＩＰアドレス履歴記録媒体」を呼び出すことができなくなるので、呼び出すことができない場合、当然、照合は行われない。この場合、接続ＩＰ判定のみは処理されているので、その判定符号を創出すると、例えば「１空空」のようにすることができる。
すなわち、接続ＩＰ判定を「１」、「カレントＩＰアドレス記録媒体」と「ＩＰアドレス履歴記録媒体」には照合されないので、「空」「空」になる。従って、「空」のときだけ例えば「２」のように置き換えると、「１２２」のようになって、ロボットによる偽装ＩＰログインと、直ちに確定・断定できる。
一方、人が操作するＦＯＲMの場合の判定符号は、媒体と照合されるので「１０１」（当日初回でＩＰ無変更）、「１１１」（当日２回目かそれ以降でＩＰ無変更）、「１１０」（当日２回目かそれ以降でＩＰ変更）、「１００」（当日初回でＩＰ変更）のようになる。従ってこれ以外の判定符号を通過させる必要はないので、当該判定符号を活用することで通過、遮断を一次仮制御することができる。
ただ当日初回でＩＰ変更の場合、クラッカーやメンバー以外の手動アクセスに対しての判定符号も、「１００」になるので、この場合、メンバーによる当日初回でＩＰ変更なのか、クラッカーやメンバー以外で当日初回のＩＰ変更なのか、ここでは未確定である。この件は後述する「秘密の質問」で対処する。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、このようにロボットの偽装ＩＰアドレスによる侵入に対して、そのパラメーターに「？」と「ドメイン」が存在するか否かの割り出し判定を行い、それが確認された場合、媒体が存在するディレクトリへ至る「媒体直通ルートパス」を分断・遮断することによって、その該当記録媒体に対して照合処理そのものが行われないようにする仕組みとロボットによる偽装ＩＰログインを確認・断定（前記「１２２」）する仕組みとを兼備することを特徴としている。
【００７１】
このようにしてトップページを経由したことを前提として、当日の「在籍証明書」が存在するか否か、の確認が行われ、同時にカレントＩＰアドレス記録媒体に、メンバーの上記照合結果が、当日初回であれば、「当日日付」「当日通し番号」「原本ＩＰアドレス」「メンバーアカウント」「［指名］媒体識別ニックネーム」「［全員］媒体識別ニックネーム」が自動的に記録される。
この真偽判定情報が、メンバーの〔当日アクセス情報〕の「錠」の方になる仕組みである。当然、前記ツインズＩＰブロックや「１２２」が判定された場合、通過を認める必要がないので、「錠」の方は生成されない。
なお、上記「［指名］・［全員］媒体識別ニックネーム」については、後述するが、本発明のインシデント対応型ログインシステムには、［指名］送信・［全員］送信に区分けされていて、［指名］送信の場合、メンバーは、直接、指名者宛にコンテンツ情報を送信する。このため、メンバーの頭数に応じたコンテンツ情報保存［専有］媒体が設けられている。更に、それらの［専有］媒体とは別に、受信ページを表示するためのガイダンス情報を記録した媒体があって、これには「媒体識別ニックネーム」が付けられている。このような「媒体識別ニックネーム」が、有用となる局面は、頻度として少ないものの、例えば、外部ネットワークを経由して送信する途上でメンバーのＩＰアドレスが急遽、更新される局面が生じた場合、当該「媒体識別ニックネーム」と［連続ページ番号］が先行割符としてガイダンス情報を記録した媒体（［指名］受信ガイドデータ）に存在することで、メンバーのＩＰアドレスが更新されていたとしても、「媒体識別ニックネーム」と［連続ページ番号］を根拠に「更新ＩＰアドレス」に一意性を付与することができる。これの詳細は後述する。
【００７２】
次にログデータにはトップページを経由したメンバーを前提にメンバーの基礎データ（「当日日付」「原本ＩＰアドレス」「当日通し番号」「曜日キー」「アクセス時分秒」）が、他の連携媒体（ＩＰアドレス履歴記録媒体）と照査され、記録される。特にこの場合、前記「通し番号検問」が有用となる。
次にログデータと並列処理して第二認証媒体に「当日日付」「当日通し番号」「ワンタイムアカウント」「メンバーアカウント」「パスワード桁数」「第２メソッド判定」が記録される。
ログデータと第二認証媒体に「当日日付」と「当日通し番号」が記録されているのは、当日同一メンバーの同一データが重複記録されるのを回避する措置であると共に、この２つの媒体は、相互補完の関係にあるので、一方のデータの証明力が弱いとき一方が他方を補佐するためである。
すなわち、「対」の関係にある「ＩＰアドレス」と「メンバーアカウント」だけでは、判定根拠が不安定である。例えば当日２回目ログインで「ＩＰアドレス」が変更された場合、ＩＰアドレス履歴記録媒体（「バイト数別Ｉｐ媒体」）のなかに「ＩＰアドレス」が存在しなくとも、第二認証媒体に「メンバーアカウント」が確認できれば、これによってこの「当日通し番号」の所有者が裏付けられ、確かな証明が得られる。
【００７３】
このように第二認証媒体が有用なのは、例えば、状況的局面によっては、メンバーの原本ＩＰアドレスのみではメンバーの真偽・識別が困難となる場合があり、これを想定してのものである。これの詳細及び「第２メソッド判定」の詳細については後述する。
問題は、この場合の登録固定媒体でのデータ照合は、メンバーの「ＩＰアドレス」をメインに行われるので、上記のような「１２２」単一では、クラッカー（ロボット）に巧妙に「ＩＰアドレス」を偽装されると、通過される可能性が万が一にも生じる点である。
そこで、例えば、この〔当日アクセス情報〕を自動生成された「錠」とすると、この「錠」を開けるのは、登録メンバー以外に許可する必要はないので、組成核が「当日通し番号」の暗号化された〔ワンタイムアカウント〕という当日限り有効の「鍵」をメンバーが毎回ログインする度にシステムに自ら設定する。本発明のインシデント対応型ログインシステムでは、これをセッション管理キー設定という。この場合も前記「通し番号検問」の有用性が発揮される。
【００７４】
例えばロボットが仮にツインズＩＰブロックを潜り抜けて、当日２回目かそれ以降の、メンバーの「偽装ＩＰアドレス」で侵入しても、「１２２」判定を活用することで、ロボットには〔ワンタイムアカウント〕（「鍵」）は提供しないようにすることができる。
仮にこれが当日初回無変更でメンバーの「偽装ＩＰアドレス」で侵入しても、この場合、ロボットには「錠」の方のデータが生成されていないので、〔ワンタイムアカウント〕が発行されない。このように「錠」が実在しなければ「鍵」があっても役に立たない、逆に「錠」が実在していても「鍵」がなければ開錠できない。
このようにすることでロボットの偽装ＩＰアドレスによる不正アクセスを阻止することができる。しかも当日通し番号が偶数か奇数かの条件によって〔ワンタイムアカウント〕が生成されるので、そもそも、偶発性流動値である「当日通し番号」を偽造することそのものが不可能である。
【００７５】
ここで、〔当日アクセス情報〕の「錠」と「鍵」が自動生成される仕組みについて説明すると、次のようになる。まず、メンバーの端末がトップページに接続されると、接続ＩＰ判定が自動的に行われ、次に「メンバーアカウント」（「プルダウン式入力認証ＭＡ」）の入力を求められる。このようにしてメンバーの当日セッション歴の確認が行われる。これは、メンバーのログインが当日２回目かそれ以降であれば、セッション管理キー設定に自動的に移動させるためである。
当日２回目かそれ以降の場合、「プルダウン式入力認証ＭＡ」を経ずにセッション管理キー設定に入るため、「パスワード桁数」は、メンバーがプルダウンから選択することになる。また、このセッション管理キー設定の「ＦＯＲＭ」には「メンバーアカウント」を充当する隠しフィールドがあるが、この場合、〔当日アクセス情報〕の「錠」のデータに「メンバーアカウント」が記録されているので、隠しフィールドには充当される。
一方、当日初回の場合、ログデータ、第二認証媒体には、当然、メンバーの当日データは空であるため、他の連携媒体と照査して記録せねばならない。このように、上記４つの各媒体は、ＩＰアドレス履歴記録媒体を要にして相関関係を有していて、互いを監視したり、補佐したり、あるいは他を代替したりして有機的な相互関係を保持している。すなわち、これらの媒体は、目下、稼働中の現在進行形のデータであるカレント性データの収納媒体である。
【００７６】
接続ＩＰ判定の結果、ＩＰアドレス履歴記録媒体にメンバーのＩＰアドレスと同一のＩＰアドレスが実在すれば、メンバーのＩＰアドレスが変更されていない、ということになり、かつ、並行して「メンバーアカウント」の照合が図られるので、初回ログインであれば、カレントＩＰアドレス記録媒体で、この間に〔当日アクセス情報〕の「錠」が自動生成されていることになる。このようにしてメンバーの正当性・真正性が保全されていく。
一方、〔当日アクセス情報〕の「鍵」の方は、第二認証媒体に記録される際、「通し番号検問」で「当日通し番号」の整合が確認された後、組成核を「当日通し番号」とした〔ワンタイムアカウント〕がここで暗号化され生成される。かつ、当日通し番号を核としたこの〔ワンタイムアカウント〕の結合には、グレゴリウス暦の「曜日キー」が組成として含まれているので、クラッカーは、２４時間以内に解読しなければならなくなる。
なお、当日２回目かそれ以降の場合、「プルダウン式入力認証ＭＡ」を経ずに直接、セッション管理キー設定に入る件に関しては、特にこだわることなく、当日初回のように「プルダウン式入力認証ＭＡ」から入っても構わない仕組みにしてもよい。この場合、仕様を変えればよい。
【００７７】
しかもこの〔ワンタイムアカウント〕には、例えば第二認証媒体に記録されたメンバーの当日通し番号が偶数か奇数かと、当日が奇数日か偶数日かによって結合の順序・結合する文字が異なる仕組みが設けられている。通し番号が奇数のときで奇数日は「数字２字（０６）」が先頭に結合され、通し番号が偶数のときで偶数日は「アルファベット２字（ａｇ）」が後尾に結合される。また、通し番号が偶数のときで奇数日は「数字２字」が後尾に結合され、通し番号が奇数のときで偶数日は「アルファベット２字」が先頭に結合される。よって４パターンの組み合わせが生成され暗号化される、〔当日偶・奇数曜日キー〕となる。上記の数字のうち、日曜を「０」土曜を「６」、アルファベットのうち、日曜を「ａ」土曜を「ｇ」とした場合の一例である。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、当日通し番号を核組成として暗号化された〔ワンタイムアカウント〕は、当日の認証手段である〔当日アクセス情報〕が「錠」を構成し、その「錠」を開ける「鍵」に当たるものであって、偶発性を有してメンバー個々固有に生成され、かつ結合の順序が、当日が偶・奇数日か通し番号が偶・奇数かによって先頭もしくは後尾のように結合位置が異なり、しかも結合される文字が数字あるいはアルファベット・記号に入れ替わるグレゴリウス暦〔当日偶・奇数曜日キー〕のため結合ボーダーを隠蔽化できることで偽造を阻止することを特徴としている。
これは、〔ワンタイムアカウント〕の結合ボーダーを隠蔽化し、容易に偽造されないようにするための仕組みである。なお、元の「曜日キー」は、日曜日を数字「０６」、アルファベット「ａｇ」もしくは記号「＃％」のようにした対応表を有す。ただし、数字及びアルファベット・記号の組み合わせは固定でなくともよい。
すなわち、この〔当日アクセス情報〕と〔ワンタイムアカウント〕は、当日１日限り有効の認証手段である。
【００７８】
次のセッション管理キー設定は、次のような手順で〔ワンタイムアカウント〕を入力する。メンバーが「プルダウン式入力認証ＭＡ」を操作して通過すると、切り替わった画面上の適宜な位置に〔ワンタイムアカウント〕の文字が表示されていて、メンバーがマウスでコピー＆ペーストしてフィールドに流し込む方式である。これとは別に上記の「メンバーアカウント」の複式操作を行ったときに選択した「パスワード桁数（６〜９）」がこの＜ＦＯＲＭ＞のフィールドに充当表示されている。このパスワード桁数は、ログインパスワード認証を行う際に必要になるので、上記のような関連付け因果性の仕掛けのひとつである。このパスワード桁数は、ここで変更できない。
なお、「適宜な位置」とは、送信＜ＦＯＲＭ＞〜＜／ＦＯＲＭ＞構文内の外に表示することを意味し、＜ＦＯＲＭ＞を起点に文字列を採取していこうとするロボットにコピー＆ペースト情報を拾いにくくしている。
更にこの送信＜ＦＯＲＭ＞には、前記したような隠しフィールドに「メンバーアカウント」のキーが設けられていて、前記「１２２」のような不正な通信の場合、「メンバーアカウント」の構文「ｎａｍｅ」が空になる仕掛けがされている。このＦＯＲＭのデータはパスワード認証に入る前段階で第二認証媒体によって照合されるので、「ｎａｍｅ」が不調な場合、パスワード認証の端緒につけなくなる。更にメンバーがログインパスワード認証へ移動するには、ここでの「照合時刻」と「メンバーアカウント」がログインパスワード認証を実行するための付与条件となる。これについては後述する。
【００７９】
但し、当該セッション管理キー設定でのコピー＆ペースト情報は、パスワードクラッキング等のリプレーアタック（執拗攻撃）を想定し、そのアクセスの通信メソッドが不正な場合、画面上に表示されない。不正な通信メソッドとは、この場合、ＧＥＴパラメーターを含む。トップページ経由でないアクセスはすべて不正アクセスと看做される。例えば、正規メンバーが「アクセス履歴」のＵＲＬやブックマークから通信接続した場合もトップページを経由していないのでこれに該当し、メソッド判定はＧＥＴになる。従ってメンバーの「アクセス履歴」情報を窃取したクラッカーが手動でＵＲＬを辿ってのアクセスもメソッド判定はＧＥＴになる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、［セッション管理キー設定］は、〔当日アクセス情報〕の「錠」に対して、ここで「鍵」を設定する仕組みであって、前記「プルダウン式入力認証ＭＡ」で選択した「メンバーアカウント」の文字が隠しフィールドに反映され、更に「パスワード桁数の数字」の選択結果がここで反映され、画面の適宜な位置に表示された〔ワンタイムアカウント〕を仮想の「鍵」としてコピー＆ペーストで入力することでログインパスワード認証へ移れる、鍵構成設定の仕組みであること、及び前記「メンバーアカウント」が照合不一致した場合の仕掛けとして上記隠しフィールドの＜input type=hidden 空=空value=空＞のようになることで、実質［セッション管理キー設定］の実効性が不能になることから、当日認証手段を得られなくする仕組みであることを特徴としている。
【００８０】
なお、ＩＰアドレス履歴記録媒体のうち、「バイト数別Ｉｐ媒体」には原本ＩＰアドレス・パターン数字が保存されていて、ドットを除去したバイト数別（もしくはドットを除去しないバイト数別）５桁から１２桁の８媒体のバイト数別記録方式の入れ子構造になっている。また「バイト数別Ｍａ媒体」の方はメンバーアカウント、パスワード桁数が、６〜９のパスワード桁数に応じて保存されている。それぞれ別々に振り分けて伏在記録されている。これにより接続ＩＰ判定が実行される際、メンバーのドットを除去した（もしくはドットを除去しない）現有ＩＰアドレスの桁数が、仮に１０桁とすると、メンバーのＩＰアドレスは当然、１０桁の記録媒体へ記録されていることになるので、１０桁の記録媒体への照合処理１回のみで、変更されているか否かを直ちに判定することができる。メンバーアカウントの方も、「バイト数別Ｍａ媒体」にはメンバーのログインパスワード（６〜９）の桁数に応じて振り分けて収納されているので、同じ条件で照合処理することができる。
通常、Ｗｅｂサーバーが読み込み可能な言語であれば、データを抽出するための［単項目検索］［複項目検索］の構文を記述でき、必要状況に応じてそれを使い分けることができる。［単項目検索］は、該当するデータを１件のみ取り出す、［複項目検索］は、該当するデータを複数件束で取り出すことができる。
データベースの記録・登録方法は、基本的にデータ１件ごとに上積み式に蓄積保存されていくので、メンバーの照合対象用データの位置は常に上部に存在することになる。従って［単項目検索］によって、現ＩＰアドレスと照合するための該当データを取り出す、あるいは実在しないを即座に判定することができる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、ＩＰアドレス履歴記録媒体には、ＩＰアドレスのバイト数（桁数）別記録方式によってデータの分散化が図られる入れ子構造になっているため、照合処理が単一で済み、かつ、システム接続時照合の場合のアクセス分担処理数が軽減すること、並びに侵入ロボットがメンバーアカウントを検索照合する際、パスワード桁数の数字を誤って選択すると、ここでアクセスルートの遮断処理ができることを特徴としている。
【００８１】
上記の説明は、主にメンバーのＩＰアドレスが無変更を前提としたものであるが、例えば、状況的局面によっては、頻度として少ないものの、当日２回目かそれ以降にメンバーのＩＰアドレスが急遽、変更される可能性もある。そうすると、ＩＰアドレスのみ単一の根拠では、ＩＰアドレスと「当日通し番号」を対とした場合、メンバーの真偽・識別が困難となる状況が生じる。ログデータから抽出した「原本ＩＰアドレス」は、初期ログインのときのもので、当日２回目かそれ以降にメンバーのＩＰアドレスが変更された場合、ＩＰアドレスの照合を根拠にして「当日通し番号」の所有者を判定することができなくなる。この「当日通し番号」は、ログデータと照査して「ワンタイムアカウント」（鍵）を構成するためには必須の組成である。
そこで有用となるのがログデータと並列処理された第二認証媒体による記録データである。ここには、「当日日付」「当日通し番号」「ワンタイムアカウント」「メンバーアカウント」「パスワード桁数」「第２メソッド判定」が記録されているので、この「当日通し番号」の所有者が、「メンバーアカウント」を共通項の条件（ＩＰアドレス履歴記録媒体の「メンバーアカウント」と第二認証媒体の「メンバーアカウント」）として、当日２回目かそれ以降にＩＰアドレスが変更されたメンバーの「当日通し番号」と判定することができる。よって「当日通し番号」を共通項として、次のような状況的局面を確実に区分け判定することができる。
【００８２】
その１．「当日日付」のメンバーの「当日通し番号」が〔当日アクセス情報〕、ログデータ、第二認証媒体に存在しないとき、メンバーは、初回ログインである。その２．「当日日付」のメンバーの「当日通し番号」と「ワンタイムアカウント」が第二認証媒体に存在し、かつ、カレントＩＰアドレス記録媒体（〔当日アクセス情報〕）にも両者が存在する場合、メンバーは、当日２回目かそれ以降のログインである。その３．ログデータ、第二認証媒体、カレントＩＰアドレス記録媒体に同一「当日通し番号」が存在し、ログデータとカレントＩＰアドレス記録媒体の「ＩＰアドレス」が異なる場合は、メンバーは、確実に当日２回目かそれ以降のログインであり、かつＩＰアドレスが変更されている。
【００８３】
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、メンバーのログインのパターンは、前述したように４つのタイプしか存在せず、タイプ１は、ＩＰアドレス無変更で初回ログイン、タイプ２は、ＩＰアドレス無変更で当日２回目かそれ以降のログイン、タイプ３は、ＩＰアドレス変更で当日２回目かそれ以降のログイン、そしてタイプ４は、ＩＰアドレス変更で初回ログインとなり、ただし、初期（初回）は、必ずタイプ１かタイプ４のどちらかになって、次回又はそれ以降には、タイプ２か、タイプ３かのどちらかに分岐することを特徴とする。
更に、本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、無登録者及びクラッカーが手動で行う不正ログインは、常に条件が「初回」かつ「ＩＰアドレス変更」となること、並びこのような不正ログインが「当日通し番号」の流動値を生成するための条件として資することを特徴としている。
そうすると、メンバーがトップページを経てシステムに接続したと同時に、ＩＰアドレス履歴記録媒体で自動照合され、次に必ず「メンバーアカウント」の入力が求められるので、ログデータ・第二認証媒体の記録を含めこれらの照会判定・結果をパターン符号にすることができる。
カレントＩＰアドレス記録媒体の〔当日アクセス情報〕の存在の有無、次にＩＰアドレス履歴記録媒体に対してメンバーのＩＰアドレスが実在するか否かを照会し、存在すれば「１」、不存在であれば「０」、ログデータに当日のメンバーのデータが存在すれば「１」、不存在であれば「０」、また、ログデータと並列処理される第二認証媒体に当日のメンバーのデータが存在するか否かの確認を行い、存在すれば「１」、不存在であれば「０」のように順次判定し、この数字を上記の順序で結合し、タイプ１・タイプ２・タイプ３・タイプ４毎に生成するとそれぞれ異なることが分かる。このように判定結果を連結符番にしていくと、上記の４つのタイプは、それぞれ「連結符番判定」が異なる４パターンの固有値に構成することができる。
因みにタイプ１は「０１００」、タイプ２は「１１１１」、タイプ３は「１０１１」、タイプ４は「００００」のようになる。なお、ここでは、メンバーアカウントが不一致の場合、通過させる必要はないので、メンバーアカウントが一致したことを前提としている。
【００８４】
これを具体的に説明すると、まず、タイプ１は、ＩＰアドレス無変更で初回ログインなので、メンバーの〔当日アクセス情報〕はなく、該当する「存在」データは、ＩＰアドレス履歴記録媒体だけにしか存在しない。タイプ２は、ＩＰアドレス無変更で当日２回目かそれ以降のログインなので、当日の「存在」データは、メンバーの〔当日アクセス情報〕、ＩＰアドレス履歴記録媒体・ログデータ・第二認証媒体のそれぞれに存在する。タイプ３は、ＩＰアドレス変更で当日２回目かそれ以降のログインなので、ＩＰアドレス履歴記録媒体には原本ＩＰアドレスは存在しないが、メンバーの〔当日アクセス情報〕、ログデータと第二認証媒体には当日の「存在」データが存在する。そしてタイプ４は、ＩＰアドレス変更で初回ログインなので、メンバーの〔当日アクセス情報〕、ＩＰアドレス履歴記録媒体・ログデータ・第二認証媒体のいずれにも当日の該当データは存在しない。以上のようにそれぞれ異なる４パターンの「連結符番判定」を形成することができる。
なお、符番の判定を得る方法及びその結合の方法は、例えばトップページ等の所定位置に媒体直通ルートパス（「./../../データベース」）のような相対パスによる、該当ディレクトリまでのアクセス導線を設け、所定位置で得られたその判定結果の各符番を所定の順序で結合することによって行うことができる。
【００８５】
更にクラッカーの偽装ＩＰアドレスによる侵入を想定して、メソッド判定「１」を初頭に付け、タイプ１を「１０１００」、タイプ２を「１１１１１」、タイプ３を「１１０１１」、タイプ４を「１００００」のように５桁にすることができる。これは、メンバーがシステムに入るには、最初にトップページのＰＯＳＴボタン、次に「メンバーアカウント」を入力する際にも、「ＦＯＲＭ」のＰＯＳＴボタンを押して入るため、メソッド判定「１」を既に得ていることになるので、「連結符番判定」としては、成立している。
この場合、ロボットがメンバーのＩＰアドレスを偽装して、ＩＰアドレス履歴記録媒体で接続判定の一致を得るには、ＩＰアドレスが無変更のタイプ１の「１０１００」とタイプ２の「１１１１１」しかない。
しかし、ロボットは、送り付けＧＥＴパラメーターのため、メソッド判定が「０」になる。そうすると、タイプ１は「００１００」、タイプ２は「０１１１１」のようになるので、当該「連結符番判定」を活用することによっても偽装ＩＰアドレスによる侵入を阻止することができる。
よって、もしチャンスがあるとすれば、手動によって行うことができるタイプ４だけになる。この場合、タイプ４は、ＩＰアドレス変更で初回ログインなので、メンバーの〔当日アクセス情報〕、ＩＰアドレス履歴記録媒体・ログデータ・第二認証媒体のいずれにも当日の該当データが存在しない。因みにこの場合人であるクラッカーの「連結符番判定」は、「１００００」になるので、メンバーと同一条件になる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、適宜な各所定位置に媒体直通ルートパスのような該当ディレクトリの媒体に直結するアクセス導線を設け、各所定位置で得られた判定結果の各符番を所定の順序で結合することで、このような方法で作出したそれぞれ異なる固有値パターンを有した、「連結符番」が、適宜な通過あるいは遮断の制御のための識別判定用途もしくは追加記録の停止・保留手段として資すること、更にメソッド判定「０」を初頭に付け、ＩＰアドレス履歴記録媒体を要にして〔当日アクセス情報〕の記録媒体であるカレントＩＰアドレス記録媒体、ログデータ、第二認証媒体でのそれぞれの照合判定結果を４パターン（タイプ１は「００１００」、タイプ２は「０１１１１」、タイプ３は「０１０１１」、タイプ４は「０００００」）のような連結固有値にすることで、このように形成された「連結符番判定」を適宜に活用すれば、ＩＰアドレスを偽装した自動プログラムによる不正アクセスを阻止・制御する仕組みになることを特徴としている。
【００８６】
因みに手動によるクラッカーのタイプ４の状況を、ここでシミュレーションしてみると、「１００００」の「連結符番判定」が形成された場合、クラッカーは、セッション管理キー設定に入る前に、「プルダウン式入力認証ＭＡ」による「パスワード桁数」＋「メンバーアカウント」と「秘密の質問（２件）」をクリアせねばならない。順序として、ＩＰアドレス履歴記録媒体で、「メンバーアカウント」が照合一致した後、「秘密の質問（２件）」が照合される。これは、「メンバーアカウント」が照合一致したことで、「変更」されたＩＰアドレスが、クラッカーの現有ＩＰアドレスであると確認するためである。また、照合が一致したことで、ログデータ・第二認証媒体に所定のデータを記録することができるが、これには別の意図もある。
もしクラッカーが「秘密の質問（２件）」が２回、不一致の場合、ここで前記、第二認証媒体の「第２メソッド判定」が初期値「１」から強制的に「０」になり、これにより以降のアクセスルートがブロックされるようになる。
メンバーも条件的に同じであるが、メンバーの場合は入力ミスである。クラッカーの場合、管理者に連絡して初期値「１」に戻してもらうわけにはいかない。この「第２メソッド判定」は、犯跡記録として残ることになる。照合の順序を上記のようにしているのは、メンバーの「メンバーアカウント」が窃取されている可能性を検出するためである。従って、「メンバーアカウント」がクリアされ、「第２メソッド判定」が「０」になった場合、このメンバーの「メンバーアカウント」が窃取されていることが確定する。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、クラッカーの不正アクセスの犯跡記録を検出するための手段として、メンバーの「メンバーアカウント」が窃取されていることの根拠を得るには、その順序をＩＰアドレス履歴記録媒体で先に行い、通常ＩＤのような「メンバーアカウント」で照合一致した後、「秘密の質問」の照合に移るようにすることで「秘密の質問」がクリアできなかった場合、それを窃取確定の犯跡記録とすることを特徴としている。
このことは、「メンバーアカウント」の発行を永久固定でなく「暫定」とすることができることを意味する。
【００８７】
なお、前述したように［セッション管理キー設定］のＦＯＲＭには、前記したように＜input type=hidden $name= $account value=＞のような隠しフィールドに「メンバーアカウント」のキーが複式関連付けの仕掛けとして設けられていて、このＦＯＲＭのデータは、第二認証媒体によって照合が図られる。このようにＩＰアドレス履歴記録媒体、ログデータ、第二認証媒体は三つ巴の相互補完の関係にあるので、これら３者の整合性が完全に整わない場合は、上記「$name」（$account）は空になる。すなわち、「$name」カット処理が緊急発動する。すると＜input type=hidden空=空value=空＞のようになるので、システムはこれを識別できなくなる。
更にその判定が、初頭が「０」の「００１００」「０１１１１」のように判定された場合、［セッション管理キー設定］のＦＯＲＭそのものを表示しないようにすることができる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、目下、現在進行形の流通データを記録するカレント性媒体（ＩＰアドレス履歴記録媒体・カレントＩＰアドレス記録媒体・ログデータ・第二認証媒体・時刻付与媒体）は、主要データの保有媒体であるＩＰアドレス履歴記録媒体を要にしてこれら５者が相関関係を有していて、互いを監視したり、補佐したり、あるいは他を代替したりして有機的な関係を保持していることから、各媒体に対象・該当データが存在すれば「１」、不存在であれば「０」のように判定し、それらを順次結合した、「連結符番判定」を形成することで、従来、認証手段の要とされなかった発信元ＩＰアドレスを、その変更・無変更に関わらず、一意性（unique）・一連性を有した当日限定のメンバー識別・紐付け情報として、一意性を有した認証手段とすることを特徴としている。
従来、ゲームのスコア用データ等を除けば、ログインシステムにおいてカレント性データの有用性が必要と認識されなかったのは、ログインシステムの認証手段が基本的にデータをＳＳＬに渡すことを前提として構成・構築されているためである。
なお、時刻付与媒体に関しては、後述するが、ログインパスワード認証に不可欠な仕組みである。
【００８８】
更にＩＰアドレスは、通信中のパケットデータに必ず在中していて、そのパケットデータを他と識別するためのものである。そうすると、ＨＴＴＰ通信の入力データを受け継げない特性を有するステートレス通信にとって、当該ＩＰアドレスを、一意性（unique）・一連性とする認証手段は、最も即応性・順応性を保持した、理にかなった本人認証を確保できる仕組みということになる。
すなわち、Ｃｏｏｋｉｅ・セッションＩＤを識別（紐付け情報）手段とする既存技術の場合、ステップ移動の都度、逐一、紐付け情報を呼び出すことで認証手段としているが、前記したようにページを表示する直前「header部」で１回しかこれが行えない上に通過時（ＯＵＴ）はフリーパスとなるため、ステップの飛び越えが可能になる。
従って、この紐付け情報認証手段を「半自動型携行処理」とすると、当該ＩＰアドレスを紐付け情報とする認証手段は、「全自動型携行処理」ということになる。これによりメンバーの端末に在中するＣｏｏｋｉｅ情報に依存することなく、Ｗｅｂブラウザーの「Ｃｏｏｋｉｅブロック」を実行したままのインターネット接続が可能になる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、通信中のパケットには必ずＩＰアドレスが在中することから、ＨＴＴＰ通信におけるステートレス通信の特性に即応性・順応性を保持した認証手段であること、並びに適宜な媒体へアクセス導線を設けることで、ページ（ステップ）の「ＩＮ」ばかりでなく、「ＯＵＴ」のデータチェックがその都度、発信元ＩＰアドレスを一意性（unique）・一連性として自動的に実行できることを特徴としている。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、利用者の端末に在中するＣｏｏｋｉｅ情報に一切依存しないため、Ｗｅｂサーバーが外部ネットワークを経由して端末とのやり取りを行わずに、そしてＷｅｂブラウザーの「Ｃｏｏｋｉｅブロック」を実行したままインターネット接続が可能になるログインシステムであること、かつ、Ｗｅｂサーバーが利用者の端末に介在することを不要にした仕組み技術であることを特徴としている。
【００８９】
更に、上記の連結符番を、別の仕様に変えることもできる。例えば、「接続ＩＰ判定」の結果を、メンバーの現ＩＰアドレスが「ＩＰアドレス履歴記録媒体」に「不存在」（変更）のときは奇数の「１」にし、「存在」（無変更）するときは偶数の「２」にし、更に〔当日アクセス情報〕（カレントＩＰアドレス記録媒体）とログデータにメンバーの当日ログインデータが「不存在」（当日初回）のときを奇数の「３」にし、当日ログインデータが「存在」（当日２回目かそれ以降）するときを偶数の「４」にする。このようにすることで、ログデータ及び第二認証媒体にデータが重複記録されないような回避措置を設けることができる。
またメンバーのＩＰアドレス変更回数を割り出すことができる。前述したように初回は、「接続ＩＰ判定」の結果が「不存在」（変更）か「存在」（無変更）の２つのタイプしかなく、かつ、〔当日アクセス情報〕とログデータには当日ログインデータが「不存在」である。この場合の数字は、「１３３」か「２３３」になる。一方、当日２回目の場合の数字は、「１４４」か「２４４」になる。そこで各値をそれぞれで合算すると、「１３３」は「７」、「２３３」は「８」、「１４４」と「２４４」はそれぞれ「９」「１０」のように連続数字になる。
そうすると、このような奇数・偶数にすることで、上記のような連続数字を活用すれば、例えば「７」「８」は当日初回ログイン、「９」「１０」は当日２回目かそれ以降のログインというような、メンバーの当日ログイン状況を判定する「基礎数字」を生成できる。この場合、「Ａ」「Ｂ」「Ｃ」「Ｄ」のように置き換えても構わない。
このようにすると、「Ａ」（「７」）と「Ｄ」（「９」）のときだけ「ＩＰアドレス履歴記録媒体」にメンバーの変更された現ＩＰアドレスを１件更新追加記録すればよく、「Ａ」（「７」）と「Ｂ」（「８」）のときだけ〔当日アクセス情報〕とログデータの媒体に初回１回だけ記録すればよいことになる。
すると、「Ｃ」のような次期（当日２回目かそれ以降）ログインの場合、それが「７」から移動したのであれば、基礎数１プラス更新追加記録回数（１）を合算すると、ＩＰアドレス変更回数「２」を割り出すことができる。それが「８」から移動したのであれば、基礎数０プラス更新追加記録回数（１）で、ＩＰアドレス変更回数「１」になる。次期ログイン「Ｄ」の場合、それが「７」から移動したのであれば、基礎数１プラス更新追加記録回数（０）なのでＩＰアドレス変更回数「１」になる。それが「８」から移動したのであれば、基礎数０プラス更新追加記録回数（０）なのでＩＰアドレス変更回数「０」になる。
【００９０】
このように「１３３」「２３３」「１４４」「２４４」のようなパターン数字、「７」「８」「９」「１０」のような連続数字の判定数字を形成することによって、「ＩＰアドレス履歴記録媒体」のうち［バイト数別Ｉｐ媒体］に現在存在する登録メンバーの保存ＩＰアドレスと照合判定し、「７」（「１３３」）と「９」（「１４４」）のときだけ、変更ＩＰアドレスを［更新追加記録］することで、ネットワーク上でメンバーのＩＰアドレスが何度、変更されても、あるいは急遽、変更されても通信パケットに在中する発信元ＩＰアドレスの一意性・一連性を常に保持すると共に臨機応変に対処することができる。従来ネックとなっていたＩＰアドレスの急遽、変更に対する技術的課題をこれにより解決できる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、前記パターン数字（「１３３」「２３３」「１４４」「２４４」）もしくはその合算値の連続数字の判定数字（「７」「８」「９」「１０」）を形成させこれを活用して、発信元ＩＰアドレスの一意性（unique）・一連性を常に確保・維持・制御することで、データを受け継げないステートレス通信の特性に最も適した一連性認証手段の仕組みを発揮させ、以ってＩＰアドレスを偽装したロボットを臨機応変、かつシステム内のどのルートからでもケース・バイ・ケースで自在に制御・遮断できることを特徴としている。
更に「１３３」「２３３」「１４４」「２４４」のようなパターン数字に、前記「プルダウン式入力認証ＭＡ」の操作時に「ＰＯＳＴ」のＦＯＲＭボタンを押したことで、メソッド判定「１」を既に得ていることになるので、メンバーの場合、「１３３１」「２３３１」「１４４１」「２４４１」のようなパターン数字が確保されることになる。
しかし、ＩＰアドレスを偽装したロボットの場合、「２３３０」「２４４０」のようなパターン数字になる。そうすると、このようなパターン数字が生成されたときに、「Ｅ」にすることができるので、この「Ｅ」を活用することでＩＰアドレスを偽装したロボットを臨機応変、かつシステム内のどのルートからでもケース・バイ・ケースで自在に制御することが可能になる。
【００９１】
また、当該「Ｅ」の活用を、クラッカーや登録メンバー以外の不要なアクセスに対し、秘密の質問をクリアできなかった場合、「バイト数別Ｉｐ媒体」に［更新追加記録］されたデータのうち、「パターン数字」を「Ｅ」に上書きもしくは変更処理することで、該当ＩＰアドレスのアクセスルートを遮断し、不測の事態に対処することができる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、どのルートからでも照合照査は可能なので、前記「バイト数別Ｉｐ媒体」内のデータに［更新追加記録］されたデータのうち、「パターン数字」を、ルートを遮断する判定の前記「Ｅ」に上書きもしくは変更処理することで、不正・不要なパラメーター・データを記録停止・保留にして排除し、あるいは次回から利用禁止措置を講じることで、メンバーの現有ＩＰアドレスの一意性（unique）・一連性を常時、確保できることを特徴としている。
【００９２】
なお、局面的に当日２回目かそれ以降にＩＰアドレスが変更された、と断定された（タイプ３の「１１０１１」）場合、当該メンバーに対して、既記録の〔当日アクセス情報〕ののうち、ＩＰアドレスの変更をしないようにする。これは、「当日通し番号」及び「ワンタイムアカウント」が既に発行されているので、重複発行を回避するための当日限定の臨時措置として行われる。すなわち、ＩＰアドレスの変更処理（カレントＩＰアドレス記録媒体の「ＩＰアドレス」）は、他の仕組みとの絡みから初回ログインの場合に限定している。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、ＩＰアドレス単一による照合の仕組み的遺漏を補足するために、前記ログデータの記録と並列処理できる「第二認証媒体」のような記録媒体を設け、当該記録媒体に初回ログイン時、前記「当日日付」「当日通し番号」「ワンタイムアカウント」「メンバーアカウント」等を記録し、「当日通し番号」〔ワンタイムアカウント〕の重複発行を回避することで、これらのデータの根拠を基に〔当日アクセス情報〕の一意性（unique）を保持し、当日２回目かそれ以降にメンバーのＩＰアドレスが急遽変更された場合などの緊急・局面的状況に臨機応変に対処できることを特徴としている。
【００９３】
なお、上記のような「錠」に「鍵」で施錠する仕組みは、一見、ＥＶ−ＳＳＬの「公開鍵」「秘密鍵」の方式に類似するかに見えるが、本発明の「インシデント対応型ログインシステム」の場合、ＥＶ−ＳＳＬのように不特定多数を対象としない、特定数のメンバーが対象となる。また、暗号・復号・仕掛けや仕組み的にも異なり、割符式に似た「錠」と「鍵」である。
あるいは後述する［提供］（閲覧）に関しては、「錠」の発行者は、［伝送］（送信）側になる。一方、「公開鍵」「秘密鍵」の方式の場合、「錠」の発行者は認証局である。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、「鍵」発行方式において「認証局」のような第三者の介在を設ける必要がない自己完結型という点で、「鍵」発行方式の仕組みそのものが異なることを特徴としている。
しかも〔当日アクセス情報〕を「錠」、〔ワンタイムアカウント〕を「鍵」とすることで、耐性強度を保持するので、「ログアウト」の自動化が図れる。ただ解読のための時間的猶予を与えてしまうことになるが、これについては、後述する。
【００９４】
一方、既存の「ログアウト」の仕組みは、ユーザーが手動でセッションの終了措置をその都度講じているが、これは、ログインした通信の接続を一旦、切断することによって他者に不正に介入されないための措置である。しかし、クラッカーからＣｏｏｋｉｅ情報のスリ替えやセッションハイジャック等によって、セッションＩＤなどの認証情報を窃取されていてそれに気づかない場合、クラッカーには［裏ルート］を通じて成りすましログインがいつでも可能になるから、これでは気休めにしかならない。
当該「セッション管理技術」の場合、Ｃｏｏｋｉｅによる既存のベース技術を用いないため、「セッションハイジャック」もＣｏｏｋｉｅ情報のスリ替えも脅威にならない。
しかも自動生成された〔当日アクセス情報〕を「錠」とし、メンバーが設定した〔ワンタイムアカウント〕を当日有効「鍵」とすることで、このような個々のメンバー紐付け情報を自動携行することが可能になる。
【００９５】
よって、本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、〔当日アクセス情報〕及び〔ワンタイムアカウント〕の仕組みは、仮想上、一方の〔当日アクセス情報〕を「錠」一方の〔ワンタイムアカウント〕が「鍵」のように構成されており、メンバーがこの「錠」に対して自己の「鍵」を生成（設定）することが不可欠なような構造になっていて、かつ、この「鍵」の組成条件には、グレゴリウス暦の「曜日キー」が含まれていることから、「流動性」「偶発性」「ナンス性」のような最強の耐性強度を保持することができ、これら「錠」と「鍵」を使って施錠したり開錠したりして登録メンバーのステップ移動時「ＩＮ」「ＯＵＴ」の検証手段とすることで、セキュリティー面のより強化された臨機応変な［セッション管理］が遺漏なく実施できること、並びに「ログアウト」の自動化が図れることを特徴としている。
【００９６】
次の「パスワードクラッキング」に対しては、〔ログインパスワードの「ｎａｍｅ」の暗号化〕という方法をこれに対置することで解決する。当該「インシデント対応型ログインシステム」の〔ログインパスワード〕は、既存のシステムが「ソフトウェアキーボード」という方法でキーロガー対策を講じているのに対して、パスワードの数字・アルファベット文字をプルダウン・メニューから１字ずつ選択する方式で、これを行うことになる。このため、各プルダウン・メニューは、０〜９の数字とａ〜ｚのアルファベット２６文字の計３６字もしくは大文字を含むと６２字になり、これがマックスの場合、９列横並びに、ミニマムの場合、６列横並びに画面上に配列されている。前述のメンバーアカウントの照合手段を「プルダウン式入力認証ＭＡ」と呼ぶのに対して、ここでは「プルダウン式入力認証ＰＷ」という。「ＰＷ」はパスワードの略称。
かつ、「プルダウン式入力認証ＭＡ」で選択したＦＯＲＭの「パスワード桁数」の６〜９の値が、ここでプルダウン・メニューに反映され複式一連関連付け因果性の仕掛けとして構成されているので、「桁数」を誤って選択すると、致命的になる。メンバーの場合、自分のパスワードの桁数を誤って選択することは考えにくい。
更に最終プルダウン６〜９番目の隣に確認用のフィールドが設けられていて、この「ＰＷ確認フィールド」にはメンバーのログインパスワードがリアルに充当表示される。「桁数」を誤って選択した場合は、ログインパスワードの記録媒体である「認証用データ登録媒体」も６〜９のパスワードの桁数に応じて分散化され別々に伏在収納されているので、検索・照合そのものができない。従ってこのような場合、「ＰＷ確認フィールド」にはパスワードが充当されない。よってこの場合、そもそも「プルダウン式入力認証ＰＷ」は形骸化され役に立たなくなる。
【００９７】
ログインパスワードの入力方法がこのようなプルダウン構成のため、各プルダウン個々に結合「ｎａｍｅ」を設けることができるばかりでなく、「ｎａｍｅ」個々をメンバーごとに固有の暗号化ができる。しかも上記〔当日アクセス情報〕の「錠」と「鍵」である〔ワンタイムアカウント〕をメンバー自ら設定・完成することによってのみ、上記したようにメンバーの「メンバーアカウント」と「照合時刻」が毎回付与され、この２つが基本的に「ｎａｍｅ」の主要構成要素として暗号化され、結合されることになる。
上記のように最重要機密情報であるログインパスワードを「ＰＷ確認フィールド」にリアルに充当表示できるのは、ツインズＩＰブロックを手始めに複式操作、メンバーアカウントの隠しフィールド、上記のパスワード桁数のように二重三重の重層ブロック構造（隠し罠の仕掛け）による防護措置を講じているために可能な仕組みである。更にこれは、メンバーに対しての利便性の提供でもあるが、このログインパスワードの露出を〔表〕とすれば、〔裏〕は、各プルダウン個々の「ｎａｍｅ」の暗号化であって、ログインする度に充分な耐性強度（偶発・流動性）が得られることからむしろこれの方が、ここでは実質のログインパスワードである。
このうち、「照合時刻」とは、前記したようにメンバーが「鍵」をセッション管理キー設定に施錠し、第二認証媒体で照合したときの照合時刻のことであるので、ログインする度、毎回異なる値になる。
かつ、この「照合時刻」は、毎回〔時刻付与媒体〕に「メンバーアカウント」「当日通し番号」「『Ｅ』判定の有無」と共に記録される。従って、照合時刻は偶発数字になる。かつ、この「ｎａｍｅ」にもグレゴリウス暦の「曜日キー」である、ログデータ記録時の秒を組成とする〔秒数ランダム曜日キー〕が結合されている。なお、当日２回目かそれ以降の場合の〔秒数ランダム曜日キー〕の「秒」のみはログデータに記録したものを流用する。
よってこのことは、クラッカーが「パスワードクラッキング」の端緒にすら就けないことを意味する。むしろログインパスワードの方を「不変」にしてもよいことにもなる。
【００９８】
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、〔秒数ランダム曜日キー〕の生成は、例えば、前記ログデータ記録時の００〜５９秒のような数字が暗号されたものと、グレゴリウス暦の「曜日」１字の日曜〜土曜を例えば「数字（０〜６）」または「アルファベット（ａ〜ｇ）（Ａ〜Ｇ）（ｈ〜ｎ）（Ｈ〜Ｎ）・・・・」のような７文字にして入れ替え、それを結合したものであり、このようにグレゴリウス暦の〔秒数ランダム曜日キー〕の生成が、偶発性を有しているため、他の組成と結合されたとき、結合ボーダーが不明瞭となることから、組み合わせ暗号の結合区界を隠蔽化する手段となることを特徴としている。
【００９９】
このことからクラッカーが「パスワードクラッキング」の端緒につくには、上記の「ｎａｍｅ」の構成要素のような作為的冗長化が障害となり、その解読作業が至難となる。すなわち、グレゴリウス暦の〔秒数ランダム曜日キー〕ひとつを例に挙げても、翌日には、ゼロからのスタートとなる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、メンバーのログインパスワードの仕組みは、アルファベット文字と数字から１字を選択することができるプルダウン・メニューが複数列横並びに配列構成されていて、これら複数個の各プルダウンの構文「ｎａｍｅ」が生成・形成されるには、上記、セッション管理キー設定の送致データが第二認証媒体で照合されたときの照合時刻と、〔ワンタイムアカウント〕を「鍵」とする仕組みの一致が当該「ｎａｍｅ」を構成するためには不可欠であって、これによって通常ＩＤのような固有記号の「メンバーアカウント」と「照合時刻」が「ｎａｍｅ」に付与されて暗号され、かつ「照合時刻」の暗号は文字位置の置き換え法則の仕組みを有した対数表をもとにシャッフルされて結合・連結され、加えて、この「ｎａｍｅ」にも〔秒数ランダム曜日キー〕のような偶発性・流動性を有した組成条件が含まれていることで「ｎａｍｅ」の結合ボーダーが不明瞭となり、日替わり可変長・可変値にすることができ、かつ、メンバー個々固有の異なる値を毎回、ナンス性を有して生成・発行できることで冗長化された煩雑な構造になるため、ログインパスワードを解読する前の段階で「ｎａｍｅ」の解読を困難にすること、また、キーロガー対策を兼備していること、更に「ＰＷ確認フィールド」が設けられていて、所定通りの適正な選択を行ったことでしか因果性を得られない前記複式一連関連付けの重層ブロック構造による仕掛けによりメンバーのログインパスワードが「ＰＷ確認フィールド」にリアルに充当表示されることから、メンバーは充当表示されたパスワード文字を見ながらプルダウン式文字入力ができる利便性を享受することができることを特徴としている。ここで云う、ナンス性とは、一度しか利用しない暗号化文字列を言う。
【０１００】
なお、毎回セッション管理キー設定の都度〔時刻付与媒体〕に記録される「照合時刻」データの照合は、復号時にその都度、確認照査が行われる。更にメンバーのログインの都度、毎回、記録されることから、そのメンバーの当日ログイン回数を掌握することができる。従ってこのことは、他の媒体と組み合わせることで、メンバー以外の不正アクセスを制御することに資する。更にログインパスワードの各「ｖａｌｕｅ」も連結時に暗号化される。
【０１０１】
ここで仮にクラッカー（ロボット）に「メンバーアカウント」「ログインパスワード」の両方を窃取されて、前述した「ステップ対応パラメーター」を間欠的に送り込まれた場合をシミュレーションしてみる。ロボットが、各ＦＯＲＭ（プルダウン式入力認証ＭＡ・セッション管理キー設定・プルダウン式入力認証ＰＷ）を攻略するには、要求ＵＲＬにドメイン・クエスチョン・マークを含むＧＥＴパラメーターになる。
仮にプルダウン式入力認証ＭＡに対する「ステップ対応パラメーター」が攻略できたとする。次はセッション管理キー設定に対する「ステップ対応パラメーター」になるが、これを組み立てるためには、当日アクセス情報のワンタイムアカウント（鍵）が必要になる。仮にこの場合、コピー＆ペースト情報を持ち帰って、再度、パラメーターを組み立て直したとする。
しかし、ロボットがプルダウン式入力認証ＰＷを攻略するには、時刻付与媒体に記録された「照合時刻」がログインパスワードの「ｎａｍｅ」を構成するための必須条件となる。かつ、結合するグレゴリウス暦の〔秒数ランダム曜日キー〕の秒は、ログデータ内にある。これらが分からない限り、「ステップ対応パラメーター」を組み立てることができない。しかも「ｎａｍｅ」は暗号化されて結合され、かつ「照合時刻」の暗号は文字位置の置き換え法則の仕組みを有した対数表をもとにシャッフルされて結合されることで攻略することがより困難になる。このように「照合時刻」や〔秒数ランダム曜日キー〕も複式一連関連付けの仕掛けである。
そこで、ロボットはプルダウン式入力認証ＰＷのソースから必要データだけを抽出して、この情報を持ち帰って、再度、パラメーターを組み立て直したとする。しかし、この場合、時刻付与媒体には「『Ｅ』判定」が記録されていることになるので、「ログインパスワード」を収納する認証用データ登録媒体との照合ができなくなる。すなわち、これが「ＯＵＴ」データを検証する仕組みでもある。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、このようにロボットに「メンバーアカウント」「ログインパスワード」の両方を窃取されていたとしても重層ブロック構造による「ＯＵＴ」データを検証する仕組みを活用することでロボットの侵入を阻止することができる。
もっともロボットに「メンバーアカウント」「ログインパスワード」の両方を窃取されていた場合、人であるクラッカーが手動で不正ログインすることになるが、秘密の質問（２件）にブロックされ、バイト数別Ｉｐ媒体に記録されたそのＩＰアドレスに対して、パターン数字を「『Ｅ』判定」に変更することができるので、以後出入り禁止になる。クラッカーやロボットは、「当日通し番号」の流動値の発生にただ貢献するだけのことになる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、前記のような一連の重層ブロック構造による「ＯＵＴ」データを検証する仕組みを有することで、通常ＩＤのような「メンバーアカウント」「ログインパスワード」の両方を窃取されても、その不正ログインを阻止することができることを特徴としている。
【０１０２】
また、本発明のインシデント対応型ログインシステムのうち、セッション管理技術のログインパスワードの復号照合に関しては、次のようになる。
「ＦＯＲＭ」のデータの送・受信は、ＰＯＳＴもＧＥＴも基本的に連結パラメーターによって内部処理的に行われている。従って、「ｎａｍｅ」と「ｖａｌｕｅ」のバイト数が分かれば、連結パラメーターから割り出して個別に単体ごとに各データとして取り出すことができる。例えば、「ｎａｍｅ」を暗号化したときに、「ｎａｍｅ」と「＆＝」を加算したバイト数を順次、全体長の総バイト数（連結パラメーター）から減算していけば、各「ｖａｌｕｅ」の値が得られる。プルダウン式入力認証ＰＷの場合、各「ｖａｌｕｅ」の値は、１バイト（半角１文字）である。
そして、基本的にメソッドが「ＧＥＴ」も「ＰＯＳＴ」も、各データ値をアンバサンド（「＆」）とイコール（「＝」）で連結されたパラメーターとして次へと送られるので、当該「ｎａｍｅ」の復号照合は、例えば、固有記号のメンバーアカウントと〔秒数ランダム曜日キー〕の合算バイト数及び「照合時刻」の暗号文字バイト数とプルダウン番号文字数にアンバサンド１字、イコール１バイト及びパスワード文字の１字バイトを、各「ｎａｍｅ」の一区切り（セグメント）とすることができることから、これを連結パラメーターの総バイト数から逐次減算して、照合対象の「一区切り」となるバイト数の値を抽出して、それを判定根拠媒体値と照合・照査することが可能である。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術では、ログインパスワードの「ｎａｍｅ」の復号手段は、連結パラメーターの総バイト数から、照合の対象となる「一区切り」を逐次抽出し、逐次減算を繰り返し判定根拠媒体値と対象となる「一区切り」とを照合・照査することを復号手段とするような仕組みを有することを特徴としている。
【０１０３】
上記の例では、このメンバーのログインパスワードの桁数が仮に９とすると、「ドメイン・サブルーチン＆９ＨｐＸ６ＺｋｑutgRk6jk Jsi2pdwlv１＝Ｚ・・・・・・・＆９ＨｐＸ６ＺｋｑutgRk6jk swlvi2pdJ９＝ｔ」のように連結されてパラメーターになっている。この例の場合、「Ｚ」と「ｔ」が１番９番のログインパスワードの組成である。
この例では、規定数の「ドメイン・サブルーチン」を除くと、アンバサンド（「＆」）と「メンバーアカウント」のバイト数は９バイト、〔秒数ランダム曜日キー〕のバイト数は８バイト、「現在経過時刻(X)」の暗号化バイト数は９バイトなので、計２６バイトになる。更にこれにプルダウン番号の１とイコール（「＝」）とパスワードの１文字の計３バイトを加算すると、２９バイトになる。すなわち、この例の場合、２９バイトが個々のプルダウンの単体バイト数（＠）ということになる。
従って、メンバーのログインパスワードのバイト数は、６〜９と幅があるから、ミニマムで１７４バイト、マックスで２６１バイトということになる。
そうすると、「ｎａｍｅ」と「ｖａｌｕｅ」の組み合わせパターンを何種類も連結・結合させた膨大なバイト数のパラメーターを送り付けてくる、通常のパラメーター攻撃に対しては、バイト短縮・ブロックを活用することで、これを阻止することができる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理技術は、パスワードクラッキングを目的とする、通常の連結パラメーター攻撃に対して、その総バイト数を計測し、アンバサンドとイコールから各プルダウンの単体バイト数をミニマムのバイト数、マックスのバイト数に区分けして割り出すことで、攻撃パラメーターに対してミニマム・マックスに応じて、総バイト数から短縮し、以ってそのパラメーターを不能にすることで、当該攻撃を阻止することを特徴とする。
【０１０４】
以上のようにして、「プルダウン式入力認証ＭＡ」「プルダウン式入力認証ＰＷ」「セッション管理キー設定」をクリアしたメンバーは、「閲覧者ボックス」「送信者ボックス」に入って、本発明のインシデント対応型ログインシステムを情報共用ツールとして利用することができるようになる。
「閲覧者ボックス」「送信者ボックス」に入ったメンバーにとって、重要なキーがここでひとつある。それは［連続ページ番号］である。
ここで云う［連続ページ番号］とは、前記したように外部ネットワークを経由する前に取得した「連続ページ番号」のことである。これを、外部ネットワークに出る前に先行割符情報として確保しておく理由は、［連続ページ番号］に一意性を付与するためである。
例えば、「送信者ボックス」に入ったメンバーのＩＰアドレスが外部ネットワーク上で送信途中でも急遽、更新される可能性もゼロではない。そうすると当日２回目かそれ以降の場合、ログデータに記録されたＩＰアドレスのみでメンバーの真偽を判定することが困難になる。例えば、ロボットがメンバーのＩＰアドレスを偽装して侵入してもこれに似た状況になる。しかもＥＬ−ＳＳＬに託されリターンされるデータのメソッドはＧＥＴのため、ことさら厄介な判定になる。
しかし外部ネットワークに出る前のメンバーの送信データは、この場合、ＯＵＴであり、メンバーのＩＰアドレスは単一である。かつ、この段階ではまだシステム内に滞在している。一方、ロボットは、この場合、送り付けパラメーターであって、偽装ＩＰアドレスの他に自己のＩＰアドレスを所持・同伴している。
そこで送信データをＯＵＴする直前に「バイト数別Ｉｐ媒体」で一旦、照合を図り、その後にＥＬ−ＳＳＬに託すようにすれば、仮にリターンしてきたデータのＩＰアドレスが更新されていたとしても、戻り値にこの［連続ページ番号］が含まれていることを確認するだけで、「ＩＮ」時に「先行割符データ」との整合性を図ることができる。
すなわち、［連続ページ番号］は、唯一固有値であるので、該当［指名］・［全員］媒体に先行割符として記録されている、この［連続ページ番号］と送信者の当日ワンタイムアカウントを根拠に、更新されていたＩＰアドレスが送信者のものと断定・判定することが可能になる。
【０１０５】
しかもロボットは、この［連続ページ番号］及び識別用の媒体ニックネームを探知することができない。仮に媒体ニックネームを探知することができたとしても、［連続ページ番号］は流動・変動値であり、パラメーターに偽造して連結したとしても「ＩＮ」でその整合性を図ることができなくなる。
本発明に係るインシデント対応型ログインシステムのうち、閲覧に特化した管理技術では、送信者が「送信者ボックス」からコンテンツ情報を送信する場合、外部ネットワーク上の送信途中で急遽、「送信者ＩＰアドレス」が更新される状況を想定して、外部ネットワークに出る前に、該当媒体記録用の［連続ページ番号］を取得（発行）し、これを該当媒体に先行割符として記録しておき、送信データを「ＯＵＴ」する直前に前記「バイト数別Ｉｐ媒体」で一旦、自己のＩＰアドレスの照合を図り、その後にＥＬ−ＳＳＬに託すようにすることで、リターンしてきたＥＬ−ＳＳＬ受信データのなかで「送信者ＩＰアドレス」が更新されていたとしても戻り値にこの［連続ページ番号］及び前記媒体識別ニックネーム（但し、［指名］）が含まれていることを確認するだけで、「ＩＮ」において［連続ページ番号］の整合性を図ることができるので、これによって「送信者ＩＰアドレス」が更新されていたとしても、これを引き継ぐことでＩＰアドレスの一意性を一連して確保できること、並びに「ＯＵＴ」時のデータの検証をも確保できることを特徴としている。
【０１０６】
次の「セッションハイジャック」に関しては、本発明の「インシデント対応型ログインシステム」では、既存のＣｏｏｋｉｅ及びセッションＩＤの仕組み技術を活用しないことで、これを解決する。
既存技術の「セッションＩＤ」とは、ログイン初回認証の終了後、利用者のログインパスワードの代用として利用者個々を紐付けするためにシステム内を持ち回ることができるようにした仕組みのことである。前述したようにステートレス通信の機能的不備をカバーするためのもので、これを自動携行することで、アクセス権の付与手段としている。
そうすると、上記、本発明の〔当日アクセス情報〕を「錠」とし、〔ワンタイムアカウント〕を「鍵」とする、当日１日限り使い捨ての認証手段がこれに相当する。しかもＣｏｏｋｉｅを活用しないので、Ｃｏｏｋｉｅ情報を改竄されスリ替えられても支障が生じない。また、「セッションハイジャック」の脅威も対象外となる。
【０１０７】
次の「ディレクトリ・トラバーサル」の攻撃・脅威に対しては、〔隠蔽ディレクトリ〕という方法でこれを解決する。この方法には、［セッション管理］面と［閲覧に特化した管理］面の二面性を兼備するので、それらを交えて以下、説明する。
通常、照合・検索用のデータ・ファイルが保存・格納されたディレクトリは、それを検索するための要求ＵＲＬから見た場合、エンド・ディレクトリはカレント（目下、選択・稼働中）になるので、このエンド・ディレクトリをサブルーチンという見方もできる。
当該〔隠蔽ディレクトリ〕では、これをサブルーチンと想定する。例えば、ＣＧＩの構文で、サブルーチンを呼び出す場合、Ｃ言語で「main」という名のサブルーチンを呼び出すとすると、「main(){」となり、ＰＨＰ言語では「function main(){」となり、Ｐｅｒｌ言語では「sub main{」のようになる。すなわち、これら構文の初頭「{」鉤かっこから最終鉤かっこ「}」までが「main」という名のサブルーチンのページ画面（もしくはステップ）を表示するための一連のプログラム言語構文になる。
【０１０８】
そうすると、ページ画面を表示するには必ずしも「サブルーチン」ばかりでなく、サブルーチンのなかに作為的な「照合構造」を設けて、この作為的な「照合構造」の結果次第をページ画面として表示してもよいことになる。というより、そのような仕様・構造にできる。また、更に順序を逆にし、作為的な「照合構造」を先に表示して、そのなかに入れ子の「サブルーチン」を隠すようにしてもよい。すなわち、作為的な「照合構造」のなかに入れ子の「サブルーチン」が存在して、本来の検索画面がその中で表示される構成である。基本的にこれが「暗号化サブルーチン」（〔隠蔽ディレクトリ〕）の仕組みである。
従って、本発明に係るインシデント対応型ログインシステムのうち、閲覧に特化した管理技術では、〔隠蔽ディレクトリ〕となる「暗号化サブルーチン」が作出・構成される仕組みは、このように作為的な「照合構造」を設定することで、一致・不一致が構成されるため、「暗号化サブルーチン」が既定通りの条件を満たしたとき以外、ページ画面にコンテンツ情報を表示しないようにすることができる。当然、この場合、一致した時のみ検索画面のコンテンツ情報が画面表示される。
このような「照合構造」の結果画面が、当該〔隠蔽ディレクトリ〕である。しかも上記「main」に相当する部分を常に流動値の暗号化にすることができる。
通常、「main」を「function $main(){」ように変数（$main）にすると、その構文は確実にシステム（文法）エラーになる。しかし「照合構造」の構文にすれば所定の目的を達せられる。すなわち、「$main」の変数は、その都度異なる不定流動値の暗号化になる。よって、正確には「サブルーチン」ではないが、「サブルーチン」擬きのようにすれば、「暗号化サブルーチン」となる〔隠蔽ディレクトリ〕を構成することが可能になる。
従って、エンド・ディレクトリを上記のような刻々と変化する「暗号化サブルーチン」の構成にすることで、固定の絶対パスを要求ＵＲＬにして攻撃する「ディレクトリ・トラバーサル」に対して、各媒体に実装したトラバーサル防御プログラム（待機型プログラム）と連動して牢固な［セッション管理］及び［閲覧に特化した管理］が併行して維持管理できる。なお、待機型トラバーサル防御プログラムについては後述する。
【０１０９】
更に、この「暗号化サブルーチン」の組成には送信者の当日「ワンタイムアカウント」が含まれているため、この「送信者ワンタイムアカウント」が判明しない限り、「ディレクトリ・トラバーサル」のような攻撃を試みても要求ＵＲＬのバイト数多寡によっても阻止される。通常、ディレクトリのパーミッション値の設定、エンド・ディレクトリ内に「index.html」あるいは「default.html」のようなｈｔｍｌ拡張子の空ファイルを投入しておくことでも対処できるが、必ずしも万全というわけではない。
本発明に係るインシデント対応型ログインシステムのうち、閲覧に特化した管理技術では、〔隠蔽ディレクトリ〕となる「サブルーチン」を構成する仕組みは、上記「照合構造」の方を先に表示し、そのなかに入れ子の「サブルーチン」を隠すような構成・構造を有した「サブルーチン」擬きのように構成されていて、従来、固定長・固定名が常識とされていた「サブルーチン」を暗号化することによって、可変長・可変名値にし、更にこの「サブルーチン（擬き）」の構文に変数を（「$main」のような）設定することが可能になり、ページ画面を検索する度にその都度、異なる不定流動値が得られるようになることから、上記「照合構造」の条件を満たしたときが一致、条件を満たさなかったときが不一致のような状況が作出されるため、上記「暗号化サブルーチン」が既定通りの条件を満たしたとき（一致したとき）以外、ページ画面にコンテンツ情報を表示しないようにすることができるので、以って、牢固な［セッション管理］並びに［閲覧に特化した管理］を並行して維持できることを特徴としている。
【０１１０】
次に上記〔隠蔽ディレクトリ〕が形成され構成される流れについて説明する。一連のログイン認証が終了した状態でメンバーは「閲覧者ボックス」「送信者ボックス」に入ることができる。当該閲覧に特化した管理技術の場合、送信者ボックスの送信者が１ページ毎にデータをアップロード機能送信「ＦＯＲＭ」を用いて発信し、受信者がこれを［指名］・［全員］それぞれ別々に１ページ毎、これを受信する。
まず、発信には、指名送信と全員送信があって、指名送信の場合のコンテンツ情報は、メンバー個々の［専有］媒体（テキスト系・バイナリー系）に記録される。全員送信の場合は、共用保存媒体（テキスト系・バイナリー系）へそれぞれ別々の媒体に記録される。
更にガイダンス情報が送信者から届けられる。ガイダンス情報である［指名］送信の送信者属性データは、メンバー個々の［専有］媒体である「［指名］受信ガイドデータ」へ、全員送信の送信者属性データは、一旦、「共用「錠」データ媒体」にストックされる。従って、各メンバーは、共用のガイダンス情報のみは、自分専用の「［全員］受信ガイドデータ」へガイダンス情報を移すことになる。因みに各メンバー専用の「［指名］・［全員］受信ガイドデータ」には、前記したように識別用の媒体ニックネームが各自に割り当てられている。これらは、前記一連の［セッション管理］が行われた時点で、〔当日アクセス情報〕の記録媒体にメンバー個々に保存されている。
そして、これらの発信データは、外部ネットワークを経由する前に「連続ページ番号」を確保する必要性から、送信者属性（送信者のワンタイムアカウント）情報と、ここで取得した「連続ページ番号」が、先行割符データとして、全員送信の場合「共用「錠」データ媒体」に、指名送信の場合「［指名］受信ガイドデータ」に先行記録され、それぞれの「連続ページ番号」を送信者は確保する。この「連続ページ番号」と識別用の媒体ニックネームが有用となる仕組みの詳細については後述する。
なお、コンテンツ情報のファイル（テキスト系・バイナリー系）等のデータも、［指名］は個別拡張子別収納、［全員］の方は共用拡張子別収納のように別々の媒体に保存収納される。
【０１１１】
そして［指名］の送信データの方が外部ネットワークを経由（ＥＶ−ＳＳＬ）して戻ってくると、コンテンツ情報の媒体に保存処理された後、その送信者の属性情報であるガイダンス情報が、受信者の媒体（受信ガイドデータ）へ送られる。受信者の媒体に記録される属性情報は、送信者の原本ＩＰアドレス、曜日キー、送信データの保存時刻（暗号）、ソートカテゴリー（索引・分類）符番、ページ表題名（タイトル）である。これらの情報が受信者の「［指名］受信ガイドデータ」に後行割符データとして記録され、「錠」の情報となる。このようにして送受信が行われ、メンバーは自己の閲覧ページの情報を確保する。
前記「認証局」の項で説明した「錠」と「鍵」の仕組みである。すなわち、当該閲覧に特化した管理は、送信者が受信者に「錠」を提供し、受信者がこの「錠」に自分専用の「鍵」で施錠する仕組みである。
【０１１２】
但し、受信者が受信ページに「鍵」を掛けるのは、メンバーがそのページを表示して閲覧するときである。１ページ毎に施錠して閲覧するのは、自分以外の者が閲覧できないようにするためである。例えば、現有ＩＰアドレスが当日２回目かそれ以降のログインで更新されたとしても、前記メンバーアカウントを根拠に［当日アクセス情報］と第二認証媒体で照らし合わすことで、更新・無更新を確認できるので、［当日アクセス情報］に存在する原本ＩＰアドレスを唯一の「鍵」とすることができる。［当日アクセス情報］内の原本ＩＰアドレスは、終日、変更されないので初回ログインからの一連性が保てる仕組みとなる。
本発明に係るインシデント対応型ログインシステムのうち、閲覧に特化した管理技術では、仮想上、受信した個々のページのガイダンス情報（「インデックス情報」）を構成する仕組みは、送信者が送信データの「錠」となる情報を提供し、受け取ったこの情報に受信者が「鍵」を掛けることによって、受信ページ１件ごとに内鍵施錠されたようにして機密性を高めることで、「プレビュー漏洩」を防止・制御することを特徴としている。
すなわち、ログインパスワード等の一連の認証は、システムに入らせないようにする仕組みであり、受信者が受信ページに「鍵」を掛けるのは自分以外の者が閲覧できないようにする仕組みである。
着信件数サインを確認した受信者は、プレビューボタンとインデックス切替えボタンで、［指名］用の「インデックス情報」と［全員］用の「インデックス情報」に切り替えることができる。この「インデックス情報」は、「［指名］受信ガイドデータ」「［全員］受信ガイドデータ」に蓄積記録されたデータの反映である。それぞれの「インデックス情報」には、カテゴリー別にタイトル・ハイパーリンクの一覧が設けられている。このハイパーリンクのタイトルをクリックすることによって、各ページの情報画面を表示することができる。
ハイパーリンクには、「ソートカテゴリー符番」「受信者の原本ＩＰアドレス」「連続ページ番号」「当日ダミー」の順に結合されていて、ハイパーリンクのＵＲＬを構成している。うち、「受信者の原本ＩＰアドレス」は、［当日アクセス情報］内から原本ＩＰアドレスが付与されている。これは、［指名］［全員］とも受信ガイドデータから媒体直通ルートパスを［当日アクセス情報］の媒体へアクセス導線として設けることで取得が可能である。同様に「［指名］・［全員］媒体識別ニックネーム」も「対応表」・アクセス導線を設けることで取得できる。すなわち、「インデックス情報」のタイトル（ハイパーリンク）の一覧は、ここでは「ソートカテゴリー符番」のキーによって［複項目検索］の構文から検索された反映情報群である。よって、［当日アクセス情報］から付与された「受信者の原本ＩＰアドレス」を「鍵」として結合することができる。
【０１１３】
一方、［全員］の方のデータは、「［全員］受信ガイドデータ（共用「錠」データ媒体）」から、属性情報を取得する。この属性情報には、送信者の当日原本ＩＰアドレス、送信者の当日ワンタイムアカウント、曜日キー、送信データの保存時刻（暗号）、ページ表題名（タイトル）、外部ネットワーク経由前からの［連続ページ番号］が保存されている。基本的に［指名］と同じであるが、受信メンバーの「媒体識別ニックネーム」のみは、受信メンバーによる後付けになる。
【０１１４】
次にここで「インデックス情報」に表示される、各閲覧ページのハイパーリンクについて説明すると、例えば、「http://domain/j52121. 435. 71. 1270109（alkj2gwz5t）00000」のようなＵＲＬが１ページごとに「ハイパーリンク」になっていて、うち、domain/の後「j521」がソートカテゴリー符番、次の「21. 435. 71. 127」が受信者の原本ＩＰアドレス、その次の「0109」が連続ページ番号（［指名］［全員］）。そして「alkj2gwz5t」が、送信者の当日のワンタイムアカウントであるが、この時点ではハイパーリンクに表示（結合）されていない。その後の「00000」は当日ダミーで、結合区界の隠蔽のための措置である。当日ダミーの配列数字及び桁数は、当日ごとに変動する。尚、「インデックス情報」のページ上では、このＵＲＬは見えず、送信者の付した表題名がそのままタイトル・ハイパーリンクになる。
上記した当日２回目かそれ以降のログイン時メンバーのＩＰアドレスが変更された場合〔当日アクセス情報〕の「原本ＩＰアドレス」を変更しない理由は、これの絡みである。「原本ＩＰアドレス」を変更すると、当日、複数の送信者の「原本ＩＰアドレス」が存在することになり、支障・混乱を来すことになるからである。これは当日限定の措置であって、「21. 435. 71. 127」の部分は、翌日になると、仮に更に更新された場合、初回に変更された現有「原本ＩＰアドレス」になる。
この当日限定の措置は、メンバー共通の規定になるので、発信者から提供される「受信ガイドデータ」の「錠」情報の、発信者の原本ＩＰアドレスも同様の条件が当て嵌まる。
因みに、「j521」の最尾の「1」は、［指名］を表し、［全員］の場合は、ここが「0」になる。［閲覧に特化した管理］においては、当該ハイパーリンクをインデックスＵＲＬという。なお、「http://domain/」の部分は、この場合相対パス（「./」）になる。
このようにこのタイトル・ハイパーリンクには、検索用のディレクトリが含まれていない。専一のコンテンツ情報を画面表示するには、通常、検索用のディレクトリが必要になるが、このインデックスＵＲＬは、〔隠蔽ディレクトリ〕を形成するための導入ＵＲＬである。
【０１１５】
このインデックスＵＲＬをクリックすると同時に、「インデックスＵＲＬ」が別仕様の送信手段に切り替わり、受信者の原本ＩＰアドレスが前記ログデータで当日初回のものかどうかの実在確認が行われる。
実在確認の判定は、前記ログデータと〔当日アクセス情報〕の当日日付のデータのなかに「21. 435. 71. 127」が実在すれば順当にトップページを経由して発行されていることが確認できる。なお、その送信・返信・経由手段は「着脱変換プログラム」及び「隠しステップ」によって処理されている。これについては、後述する。
すなわちこれは次のような理由による。「インデックス情報」のインデックスＵＲＬは、［指名］・［全員］受信ガイドデータと連繋した蓄積情報の反映である。このため、例えば、メンバーがこのＧＥＴパラメーターをブックマークから辿ってアクセスすることができることになる。このことはクラッカーにとっても同一条件になる。
そうすると、メンバーのなかにはログイン認証を経ずに、ブックマークから辿ってアクセスすることがいつの間にか習慣づけられてしまうことになる。そうなると、これは、やがてはセキュリティー・ホールを生む。
そこで［閲覧に特化した管理］では、ブックマーク（お気に入り）の禁止措置として、受信者の当日の原本ＩＰアドレスがログデータで照合確認できない場合（ＩＰアドレスが変更されていたような場合）、メンバーも「インデックス情報」が使えないようにしている。
更に「インデックスＵＲＬ」の要求ＵＲＬが絶対パスではアクセスできない仕組みも対策として講じている。これは、ブックマークの禁止措置とは別のもので、クラッカーは、絶対パスでしかアクセスできないことを逆利用した措置であり、「ディレクトリ・トラバーサル」に対して適応でき通用する。
【０１１６】
ここで、「着脱変換プログラム」及び「隠しステップ」について詳述する。
「インデックス情報」に在中する上記受信者の原本ＩＰアドレス「21. 435. 71. 127」は、〔当日アクセス情報〕の記録媒体から媒体直通ルートパスのアクセス導線によって付与されている。
メンバーが「インデックスＵＲＬ」の一つをクリックすると、直ぐに送りの切替えポイント（ＩＮ）で送致手段が＜IFRAME＞にバトンタッチされ、「インデックスＵＲＬ」はここで、廃棄される。仮にロボットが絶対パスで侵入した場合、＜IFRAME＞にバトンタッチされない仕組みもここには設けられている。よって、メンバーは＜IFRAME＞の手段で、隠しステップのなかに入る。この隠しステップ内に入る＜IFRAME＞には、＜IFRAME SRC =”前記ログデータへの媒体直通ルートパス”＞が設定されていて、「21. 435. 71. 127」と「媒体識別ニックネーム」（例えば「tokyo」）と「連続ページ番号」が挿入結合されている。そして自動的に前記ログデータで「21. 435. 71. 127」の真偽を確定させる。真偽とは、〔当日アクセス情報〕の原本ＩＰアドレスとログデータの原本ＩＰアドレスの一致のことである。これによって、当日初回ログインであることの真正性を確認することができる。
確定後、ここで「ＯＵＴ」（戻り）の切替えポイントに移り、データが分岐し、２方向のデータ経路が作出される。一方は「相対処理媒体」へ、一方は「隠蔽ディレクトリＵＲＬ」となって、それぞれ別々の経路でリターン送致される。
この場合、当該隠しステップ内で先行して「スライド計算時計」が、この時のジャスト時刻を基に［スライド時間］を計時し「暗号ルーチン生成体」の機能によって、［スライド時間］が暗号化される。更にここで「受信者の原本ＩＰアドレス」が「送信者のワンタイムアカウント」（「alkj2gwz5t」）と交換される。
従って、「相対処理媒体」へ送られるデータは、「送信者のワンタイムアカウント」「曜日キー」「スライド時間の暗号化」「連続ページ番号」「媒体識別ニックネーム」である。
「相対処理媒体」に旧の残存データがあればその都度、上書き処理されてクリアされる。すなわち、これらのデータは、前記〔隠蔽ディレクトリ〕の「照合構造」を構成する左右一方宛のものである。閲覧ページは１ページごと画面表示するので、その都度、これが唯一の参照データとなるため、「相対処理媒体」には、蓄積保存する必要がなく、常に上書き処理される。これについては後述にて詳しく説明する。
２方向の戻り値データ経路のうち、「相対処理媒体」へ送られるデータの経由送致手段は、＜IFRAME＞等によって行われ、もう一方の戻り値データの経由送致手段は、＜META HTTP−EQUIV=”Refresh”CONTENT=’0;URL=”「送信者のワンタイムアカウント」「曜日キー」「スライド時間の暗号化」が結合されたＵＲＬ”’＞によって行われる。このＵＲＬが、「照合構造」の左右一方の「隠蔽ディレクトリＵＲＬ」である。
うち、「媒体識別ニックネーム」が含まれた「相対処理媒体」のデータは、露出されないが、「＜META HTTP＞」の方は、「隠蔽ディレクトリＵＲＬ」としてＷｅｂブラウザーのＵＲＬフィールド欄に充当表示される。
このことは、ＷｅｂブラウザーのＵＲＬフィールド欄に充当表示された方だけが、「アクセス履歴」として残留されることになり、もう一方の＜IFRAME＞の経由送致手段によって行われた、戻り値データの方は、Ｗｅｂブラウザーの「アクセス履歴」に残らない。しかも「相対処理媒体」のデータには、作為的「照合構造」のなかに作出される入れ子の「サブルーチン」の検索用キーが、このとき既に確保されている。
すなわち、検索用キーとは、「連続ページ番号」のことであり、この「連続ページ番号」は、このメンバーにとって唯一固有のものなので、業種別フォーマット等のアプリケーションを用いてコンテンツ情報を画面表示させることができる。
【０１１７】
このように本発明に係るインシデント対応型ログインシステムのうち、閲覧に特化した管理技術では、「着脱変換プログラム」は、〔隠蔽ディレクトリ〕の「照合構造」「ＵＲＬ」「サブルーチン（擬き）」「ディレクトリ」を創出する手段と共にＵＲＬの自動廃棄処理を達成するための手段であって、画面表示されない隠しステップ内にこれが設けられていて、それらの仕組み機能によって、ＵＲＬ（ＧＥＴパラメーター）のステップ移動手段を実行し、かつ、初期ＵＲＬが廃棄されて別様ＵＲＬになって＜IFRAME＞タグ等によって前記ログデータへ送致されるため、前記ログデータ等の媒体での検索照合によるデータの抽出（受信者の原本ＩＰアドレス）、データの交換（受信者の原本ＩＰアドレスが送信者のワンタイムアカウントと交換）、データの挿入結合、データの除去結合、データの分岐、２方向のデータ送信経路手段の作出等が実行処理できること、及び後期戻りＵＲＬの経由送致手段を＜IFRAME＞タグ等と＜META HTTP＞タグによって別々に分岐して行うことで、後期ＵＲＬの戻り値データが、一方は相対処理媒体へ送致され上書き処理され、一方はＷｅｂブラウザーのＵＲＬフィールド欄に隠蔽ディレクトリＵＲＬとして充当（送致）されることから、これによって一方は媒体記録手段のため「アクセス履歴」に残らず、一方は上記「照合構造」の照合手段であって最終ＵＲＬとなるので「アクセス履歴」に残ること、更に当該「着脱変換プログラム」が実行される条件は、上記隠しステップ内の経路上のパケットに在中する受信者・メンバーの現有ＩＰアドレスと前記バイト数別Ｉｐ媒体に記録保存されたＩＰアドレス（前者）が一致していて、前記ログデータと〔当日アクセス情報〕のＩＰアドレス（後者）が一致していることが不可欠（真正性の確保）であること、また、当日限定の措置、もしくはログイン条件として前者と後者それぞれ異なる原本ＩＰアドレスが存在することもあり得ることを特徴としている。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理・閲覧に特化した管理技術には、ステップ内で隠蔽処理が可能で、かつ、ページのソースを開示することができない前記隠しステップが適宜な位置に存在していることを特徴としている。
【０１１８】
更に、本発明に係るインシデント対応型ログインシステムのうち、閲覧に特化した管理技術では、〔隠蔽ディレクトリ〕の組成が生成される仕組みは、主として前記隠しステップ内で行われ、メンバーの個別（［指名］・［全員］）媒体から送信データの「保存時刻（暗号）」を抽出して復号し、スライド計算時計がジャスト時刻を基に現「スライド時間」（送信データの「保存時刻」を起点に経過した秒単位時間）を算出し、データに曜日キーが結合され、暗号ルーチン生成体で上記したような「サブルーチン（擬き）」の〔隠蔽ディレクトリ〕の組成が生成されること、並びに「ディレクトリ」「サブルーチン（擬き）」「ＵＲＬ」「照合構造」の４相の機能を複合的に有し、そのデータの移転・局面状況に応じ４相４様に有機的に発揮・機能することで、閲覧する度に暗号化された「不定流動ＵＲＬ」が形成・構成される仕組みであることを特徴としている。
すなわち、
1441166781964_0
のような〔隠蔽ディレクトリ〕がその都度、形成される。このうち、「alkj2gwz5t」が送信者の当日ワンタイムアカウント、「pZsmnhg」が曜日キー、「d9bk3NvfreSpq」が「スライド時間」の暗号である。
なお、ここでの曜日キーは、〔秒数ランダム曜日キー〕であるが、「秒」の組成は、受
信ガイドデータに送信者が記録したときの時分秒である。例えば、記録したときの時分秒が「２０：５４：３８」だとすると、「３８」の暗号化されたものが「pZsmnh」、仮に土曜日を「g」とすると、その結合したものである。
【０１１９】
ここで云う「スライド時間」とは、次のような意味になる。過去から未来を見た場合、時間は刻々と刻まれていくので、ボーダー時刻としての「現在」は存在しない。すべて「未来」に括られ、近い「未来」遠い「未来」のように時間の短長だけになる。逆に未来から過去を見た場合、時間は刻々と刻まれていくので、ボーダー時刻としての「現在」は存在しない。すべて「過去」に括られ、近い「過去」遠い「過去」のように時間の短長だけになる。
そこで、［閲覧に特化した管理］においては、これを「スライド時間」、すなわち、送信データの「保存時刻」を起点にして時間がスライドしている、と捉える。そうすると、時間は、常にスライドするから、暗号ルーチン生成体で作出される〔隠蔽ディレクトリ〕は、隠蔽ディレクトリ構成体でそのＵＲＬが形成され、閲覧する度に暗号化された「不定流動ＵＲＬ」になる。
クラッカーが仮にメンバーの端末にスパイウェア等を常駐させたとしても、Ｗｅｂブラウザーの「アクセス履歴」から得られるＵＲＬ情報は、閲覧する度に暗号化された「不定流動ＵＲＬ」と「インデックスＵＲＬ（ハイパーリンク）」ということになる。うち、「不定流動ＵＲＬ」には、送信者の当日のワンタイムアカウントと、「スライド時間」の暗号が含まれている。しかも曜日キーが結合ボーダーを不明瞭にしている。
「インデックスＵＲＬ」の方は、［連続ページ番号］とソートカテゴリー符番と受信者の、ボーダーが不明瞭なＩＰアドレス、及び当日ダミー文字列のみである。
【０１２０】
「インデックスＵＲＬ（ハイパーリンク）」が〔隠蔽ディレクトリ〕へ変遷されたことが分かっても、肝心の「スライド時間」の暗号値がクラッカーには分からない。なお、「インデックスＵＲＬ」の「21. 435. 71. 127」は、クラッカーがメンバーのＩＰアドレスを偽装することを想定しての予防措置である。これは、ロボットがＩＰアドレスを偽装して［裏ルート］からアクセスしても「対価」（窃取情報）を持ち帰るためには自己のＩＰアドレスが必須になる、ということを想定している。仮に［裏ルート］から踏み台を道連れにアクセスすれば、「随伴現象検出プログラム」でブロックされる。
ただこの場合、ＵＲＬは、どちらもＧＥＴパラメーターとしてＷｅｂブラウザーの「アクセス履歴」に残る。
1441166781964_1
の方は、「スライド時間」がブロック機能として働くため、ＵＲＬの自動廃棄処理が可能になるが、「インデックスＵＲＬ」の方は、［裏ルート］から「偽装ＩＰアドレス」でアクセスしてきた場合、通過される可能性がゼロではない。
しかし、上記したように「インデックス情報」のハイパーリンクは、Ｗｅｂサーバー内のアクセスルートのため、相対パス（「./」）で構わない。一方、クラッカーが［裏ルート］からアクセスする場合、絶対パスでなければアクセス・ポジションを確保できない。また、そのアクセスルートにツインズＩＰブロックもしくはアカンパニングフェノメノンを配置できる。
すなわち、一方は「./j52121.435.71.127010900000」のような相対パスとなり、一方は「http://domain/j52121. 435. 71. 127010900000」のような絶対パスになる。この場合、媒体識別ニックネームの「tokyo」は、「着脱変換プログラム」によって＜IFRAME＞にバトンタッチされたとき廃棄されるので、「アクセス履歴」に残らない。
従って、相対パスと絶対パスではバイト数が異なることになる。これによりバイト数多寡を判定することが可能である。更に閲覧者ボックスでは、サイト・ドメインそのものが閲覧者には必要でないので、「http://domain」を除去することが可能である。
【０１２１】
以上のように目的は、「情報漏洩の阻止・遮断」が共通であっても、物理的に（データを窃取されないようにする仕組み）と物理的に（データを閲覧できないようにする仕組み）とでは、その防御するための手段・方法が自ずと異なる。このように本発明のインシデント対応型ログインシステムには、この両方が兼備されている。
ここで、前記した、作為的「照合構造」を先に表示して、そのなかに入れ子の「サブルーチン」を隠す仕組みとその〔隠蔽ディレクトリ〕が構成・構造について説明する。
例えば、http://domain/alkj2gwz5tpZsmnhgd9bk3NvfreSpqのような〔隠蔽ディレクトリ〕が一方の送られてきた「被照合値」とすると、これに一致するようにするためには、これと同一ＵＲＬが形成される「実照合値」を適宜な媒体から呼び出し、生成すればよいことになる。これにより一致・不一致を構成できる。
すなわち、呼び出す適宜な媒体とは、前記隠しステップ内で前記脱着変換プログラムによって作出されたデータを、「相対処理媒体」へ記録したものがこれにあたる。「相対処理媒体」には、「送信者のワンタイムアカウント」「曜日キー」「スライド時間の暗号化」が存在するので、これらのデータを「相対処理媒体」から抽出し結合生成すれば、下記のような対の「$ROUTINE」が形成できる。
そうすると、「if($ROUTINE eq $URL){ 」のような「ｉｆ構文」を用いて双方の照合を図り、一致した場合のみページ検索ができる画面を表示できるようにすることが可能になる。この場合、「$ROUTINE」を「実照合値」とすると、「$URL」（〔隠蔽ディレクトリ〕）の方が「被照合値」になる。
従って、この「$URL」（〔隠蔽ディレクトリ〕）の方が、前記脱着変換プログラムの＜META HTTP＞タグの経由送致手段2によって、前記ログデータを経由して戻ってきたＵＲＬになる。
前記したように「alkj2gwz5t」が送信者の当日ワンタイムアカウント、「pZsmnhg」が〔秒数ランダム曜日キー〕、「d9bk3NvfreSpq」が「スライド時間」の暗号である。
一方、クラッカーには、「http://domain/alkj2gwz5t pZsmnhgd9bk3NvfreSpq」のような「アクセス履歴」のＵＲＬしか知ることができない。よってこのＵＲＬのうち、曜日キーと送信者の当日ワンタイムアカウントが仮に偶然符合しても、秒差調整された「スライド時間」の暗号は、常に自動廃棄処理が進行しているため、確実に不一致になる。かつ、閲覧する都度、流動値になる。
更にメンバーには検索画面を表示し、クラッカーには不一致になって停止するよう誘導するには、「}else{print “適宜な警告メッセージ” ; exit;}」のようにすればよい。
本発明に係るインシデント対応型ログインシステムのうち、閲覧に特化した管理技術では、〔隠蔽ディレクトリ〕内で個々のページ検索を行うプログラムを構成する仕組みは、「ｉｆ構文」（「==」「eq」演算子）を用いて作為的［照合構造］を先行して構成し、そのなかに入れ子の「サブルーチン」を隠すような〔隠蔽ディレクトリ〕の構造にすることで、この〔隠蔽ディレクトリ〕の［照合構造］が一致したときのみページ検索画面が表示され、かつ、この〔隠蔽ディレクトリ〕は秒差調整された「スライド時間」の暗号化等によって、閲覧する度に「不定流動ＵＲＬ」になるように前記隠しステップ内で自動的に生成されるために、「アクセス履歴」から秒差遅れの要求ＵＲＬでアクセスしても自動廃棄処理化が常時成立完成されていることから、［照合構造］が不一致の場合は、ページ検索画面（業種別フォーマット）が不表示になるような仕組みを作出することで「プレビュー漏洩」の遮断処理を可能とすることを特徴としている。
【０１２２】
なお、プログラム言語によって異なるが、通常のＣＧＩアプリケーションの場合、プログラムの仕様に「サブルーチン導入構文」が設けられていて、そこに呼び出す各サブルーチン名が固定で複数記述されている。すなわち、サブルーチン名は不動・固定とされているので、例えば、ＦＯＲMのなかの隠しフィールドに「＜input type=hidden name=job value=サブルーチン名＞」のようにサブルーチン名を設定するか、「action=./?job=サブルーチン名」のようにしていて、このサブルーチン名が、上記「サブルーチン導入構文」の複数の呼び出し用応答サブルーチンの一つと合致することで、サブルーチンの実行プログラムへ案内されるような仕組み構造になっている。
そうすると、当該「インデックスＵＲＬ」には、「tokyo」のようなメンバー固有の「媒体識別ニックネーム」を挿入することができるので、これをサブルーチンの実行プログラム名にすることもできる。すなわち、「サブルーチン導入構文」にメンバーの頭数分のサブルーチン名を固定で記述しておき、それと対の、例えばＰｅｒｌ言語の場合、「sub tokyo 1{」のようにしたサブルーチン実行プログラムをモジュール化して配することで、「tokyo 1」が［指名］「tokyo 0」は［全員］用のサブルーチンにすることができる。
しかしサブルーチンは、本来、検索実行処理用途のためのものであって、仮に「sub tokyo 1{」のようなメンバー個々のサブルーチンを構成しても、この場合、入れ子がサブルーチンになるので、ページの検索がここで先に実行処理されてしまうことになる。しかも暗号ルーチン生成体とスライド計算時計はこのなかに配することになるので、前記のような〔隠蔽ディレクトリ〕の秒差調整された「スライド時間」の暗号ＵＲＬをここで作出しても意味のないことになる。かつ、この場合、ＷｅｂブラウザーのＵＲＬフィールド欄には秒差調整された「スライド時間」の暗号ＵＲＬは表示されないことになる。
一方、本発明の〔隠蔽ディレクトリ〕は、左右が符合（合致）することで、入れ子のなかに入れるようにする手段の仕組みである。従って、「インデックスＵＲＬ」から変遷して、隠蔽ディレクトリＵＲＬになって、合致が図られるのでＷｅｂブラウザーのＵＲＬフィールド欄に充当表示されることになる。すなわち、入れ子のなかのページ検索の処理は、すでに終わっていて、合致によって恰も隠しカーテン（幕）が開かれるようなイメージになる。
このことから当該〔隠蔽ディレクトリ〕の仕組み・構造は、既存のサブルーチンと順序が逆の構造になっていて、特殊性を有していることが、既存のサブルーチンと対比することによっても裏付けられる。すなわち、既存のサブルーチンの技術では作れない、ということになる。よって既存のサブルーチンの技術では「プレビュー漏洩」を遮断制御することができない。
【０１２３】
なお、ディレクトリ・トラバーサルに関しては、別途、各記録・保管媒体を格納するディレクトリ内にトラバーサル防御プログラム（待機型プログラム）を配備する。とりわけ本発明のインシデント対応型ログインシステムにおいては、カレントＩＰアドレス記録媒体、ＩＰアドレス履歴記録媒体、認証用データ登録媒体、個別拡張子別収納、共用テキスト系媒体、共用バイナリー系媒体（共用拡張子別収納）、第二認証媒体に対して厳重な保管・管理がインシデントにとっては生命線といえる。特にメンバーのパスワードなどの属性個人情報が登録固定された認証用データ登録媒体やＩＰアドレスによる単一照合の仕組み的遺漏を補足するための第二認証媒体、あるいは時刻付与媒体からのデータの漏洩は、当該プロジェクトの危殆化を招く。
【０１２４】
この待機型プログラムは、攻撃してくるクラッカーに対し、これを監視するためにディレクトリ内に常駐していて適宜、相対的なブロッキング措置を講じる。
クラッカーの弱点は次のようになる。外部ネットワーク経由のクラッカーには直引き絶対パス（サイト・ドメイン）の手段でしかディレクトリの所在を探り当てることができない。かつ、記録ファイルやＭＩＭＥ形式系データには固有の拡張子があり、これらを読み出し（呼び出す）するためには、それぞれ対応の拡張子を直引き絶対パスに付することが必要になる。これらの攻撃条件は絶対である。そうすると、これらの攻撃条件を検出したアクセスを手続違反アクセスと断定することができる。
通常、検索のためのアクセス導線はバックグラウンド処理され隠密化するので、「サイト・ドメイン」「拡張子」が検索のためのアクセス導線に露見することはない。
そこで本発明のインシデント対応型ログインシステムのうち、トラバーサル防御プログラムにおいては、これを手続違反アクセスと捉え、即時、「随伴現象(an accompanying phenomenon)検出プログラム」等を発動させる。対峙するＩＰアドレスに関しては、クラッカーの原本ＩＰアドレスに「１」を結合することで「クローンＩＰアドレス」を形成する。このようにすることで、手動、自動（不正プログラム）攻撃に対して強制退去措置を講じることができる。「随伴現象(an accompanying phenomenon)検出プログラム」は、もともとロボット（自動）の挙動を想定したものであるが、当該「クローンＩＰアドレス」の生成により手動攻撃に対しても有効となる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理・閲覧に特化した管理技術では、トラバーサル防御プログラムは、機密情報等を記録したファイル並びにＭＩＭＥ形式系データを格納した各様態ディレクトリ内に常駐していて、直引き絶対パス、もしくは不正な手段あるいは執拗な回数でアクセスしてきた要求ＵＲＬからサイト・ドメインを検出し、拡張子を検出し、適宜な経路手順に該当・相当しない要求ＵＲＬと判定することで、即時、前記「クローンＩＰアドレス」を対峙させ、「随伴現象(an accompanying phenomenon)検出プログラム」を誘発させて、このような手動、自動攻撃に対して遮断制御処理を行う仕組みを実装した待機型プログラムが主要ディレクトリ内に配備されていることで［セッション管理］並びに［閲覧に特化した管理］が維持できることを特徴としている。
【０１２５】
更にディレクトリ・トラバーサル攻撃に対しては、ログイン実行時あるいはコンテンツ送信データの実行時の［セッション管理］面の対策が必要である。すなわち、「アクセス履歴」の無効化を行う措置である。
例えば、前記したように〔当日アクセス情報〕を「錠」とし、〔ワンタイムアカウント〕を当日有効「鍵」としてメンバーが設定する場合、〔ワンタイムアカウント〕が画面上の適宜な位置に表示されていて、メンバーがマウスでコピー＆ペーストしてフィールドに流し込む方式であるので攻撃を受けやすい状況にある。
そうすると、この場合の「アクセス履歴」はそのまま残ることになる。そこで、この場合の対処として、例えば、「https://domain/members/」のようにＷｅｂブラウザーのＵＲＬフィールドの「ＵＲＬ」をログイン実行時あるいは送信データの実行時に一律に固定するようにする。一律固定されたディレクトリ「/members/」は、カレント・ディレクトリではないので、このままでは、「ＦＯＲＭ」送信によって「メンバーアカウント」や「ログインパスワード」の照合処理ができない。
しかしここに「https://domain/members/abc1」のようにし、「abc1」をコール符番にすることで、このコール符番に対応したそれぞれのカレント・ディレクトリを媒体直通ルートパスで呼び出すことができる。イメージ的に捉えると、例えば鉄道のターンテーブル（転車台）のように随意方向転換してカレント・ディレクトリの所在を探り当てそのアクセスの導線へ向かわせ、「ＦＯＲＭ」の送信データを届ける方式である。ただ、このままではコール符番「abc1」が露見しているので、「abc1」をＵＲＬフィールドから、除去する。
「ＦＯＲＭ」送信の場合、「FORM method=POST action=’./members/abc1’」のようにすることができる。すなわち、「abc1」が、カレント・ディレクトリの所在を探り当てるアクセス導線の符番なので、クラッカーは、一律固定の「https://domain/members/」では、カレント・ディレクトリの所在を探り当てることができなくなる。更にこの場合、クラッカーが、ページ画面のソースが開けないように要求ＵＲＬのバイト数が既定数を上回る「https://domain/members/abc1」のようにして送り付けた場合、強制的に元の一律固定の要求ＵＲＬに戻すことができる。
ただ、このように一律固定にすると、Ｗｅｂブラウザーは、メンバーが当日初回にアクセスした画面である、「メンバーアカウント」を入力したときの画面を「アクセス履歴」に残す可能性がある。また、最悪、コピー＆ペーストしてフィールドに流し込む画面（セッション管理キー設定）が表示されることも考えられる。
【０１２６】
ここで上記のコピー＆ペーストの事例をシミュレーションしてみると、仮にセッション管理キー設定がフィールドに流し込む画面の場合では、クラッカーがこれを自動で実行するには、前記で説明したように、システムにメンバーと同伴して入ったと同時に「随伴現象(an accompanying phenomenon)検出プログラム」が発動されるので、メンバーがログアウト中の絶妙なタイミングを狙わなければならなくなる。
前記したように実際にはコピー＆ペースト情報は、この場合、不表示になるが、飽くまでこれはシミュレーションである。そこで、このコピー＆ペースト情報を一旦、拠点に持ち帰り、［裏ルート］から連結パラメーターを組み立て自動で実行したとする。
しかしこれも「一律固定の要求ＵＲＬ」に戻される。第一がこの場合の送信メソッドは、自動で実行したとすれば「ＧＥＴ」になるので、メソッド判定を適応して３０５送信エラーに持ち込むことができる。更にクラッカーが要求ＵＲＬをそのまま使ってリスクを承知で［裏ルート］から手動でアクセスしたとする。
一見、成功するかに思えるが、この場合、システムは、当日２回目かそれ以降のログインで、急遽、ＩＰアドレスが更新されたもの（タイプ３「１１０１１」）と看做すことになる。するとこの場合、クラッカーは、メンバーのメンバーアカウントを先に入手していて、かつ、パスワード桁数も知っていなければ成立しない。というのは、メンバーアカウントの入力を省いてセッション管理キー設定の入力欄を表示していることになるので、隠しフィールドの「メンバーアカウント」が空欄のままになっているからである。ＩＰアドレスが変更された場合、整合性の根拠は、これと「対」となるメンバーアカウントになる。
そうすると、前述したように隠しフィールドの「$name」カット処理が緊急発動する。＜input type=hidden $name=$memberaccount value=＞は、＜input type=hidden 空=空value=空＞のようになる。
このようにＩＰアドレス履歴記録媒体、ログデータ、第二認証媒体は三つ巴の相互補完の関係にあることから、これら３者の整合性が完全に整わない場合、セッション管理キー設定の隠しフィールドの「ｎａｍｅ」タグ及び「ｎａｍｅ」並びに「ｖａｌｕｅ」の値を自動的に空にすることができる。
【０１２７】
従って、手順を逸脱した不正なセッション管理キー設定の入力欄表示が行われた場合、タイプ１（「１０１００」）、タイプ２（「１１１１１」）、タイプ４（「１００００」）もすべてカット処理が緊急発動される。
しかもクラッカーは「
1441166781964_2
」の画面を「アクセス履歴」のＵＲＬを通じてクリックして表示していることになる。そうすると、これは単なるハイパーリンクと同様になるので、メソッド判定は「ＧＥＴ」を判定する。このように同一ＵＲＬでも内部処理された流れのＵＲＬと、外部からクリックして表示されたＵＲＬとではメソッド判定が異なる。正確には、メソッド判定が「ＰＯＳＴ」ではない、あるいは「ＰＯＳＴ」に該当しないため「ＧＥＴ」と判定されることになる。
従って、「アクセス履歴」のＵＲＬを辿ってアクセスしたすべてのアクセスに対して、メソッド判定を「ＧＥＴ」と看做すことができるので、これの判定を活用できる。
なお、実際のターンテーブルの場合は、線路から入車してきた車両を１台ごと方向転換させているため、車両をクロスして配置するようなことはできないが、バーチャルではターンテーブル上に幾交叉もの「車両」をクロスして配置しても構わない。ここでは複数の記録処理媒体へのアクセス導線が必要になる。
【０１２８】
そこで、例えば「abc1」のような各コール符番に対応する複数のアクセスルートの方向付けが記録された「対応表」を設け、「action=’./members/abc1’」から「abc1」を分離することで、「abc1」に応じたアクセス導線へ「ＦＯＲＭ」の送信データを送るようにする。「対応表」がこの場合、ターンテーブル上に配置された幾交叉もの「クロス車両」のようなイメージになる。システムのアクセスルートはツリー構成の階層で云えば、「前に戻る」「下（先）に下がる（進む）」「同一階層の数個先へ進む」のこの３つしかないので、例えば、「abc1」のとき、「前に戻る」、「abc2」のとき、「同一階層の３個先へ進む」のように該当記録処理媒体が存在するディレクトリの位置を指定しておけばよいことになる。するとターンテーブル上のバーチャル「車両」は既にその方向へ進む態勢でいるので、自動的に指示通りに走り出す。
なお、ＦＯＲＭの記述を「action=’./members/’」にして、＜FORM action=’./members/’method=POST＞＜input type=hidden name=job value=abc1＞のようにコール符番を隠しフィールドに挿入しても目的は達成できる。
本発明に係るインシデント対応型ログインシステムのうち、セッション管理・閲覧に特化した管理技術では、「アクセス履歴」に残るＵＲＬの無効化処理を行うための措置であるＵＲＬの一律固定の仕組みは、前記したように常にＵＲＬが同一固定（例：「https://domain/members/」）になるようにすることで、クラッカー（ボットネット）から「アクセス履歴」を窃取されてもそのＵＲＬを実質的に無効化にすることを目的としていて、特にログイン（メンバーアカウントやログインパスワード）入力実行時及びコンテンツ・データ送信実行時の「ＦＯＲＭ」に必要であって、かつ前記媒体直通ルートパスのような複数のアクセスルートの方向付けが記述された「対応表」が設けられていて、「ＦＯＲＭ」の送付時に「action=’./members/abc1’」もしくは＜input type=hidden name=job value=abc1＞から前記コール符番（abc1）を分離し、かつ前記コール符番を内部プロセスで隠蔽処理し、この「対応表」が、前記コール符番に応じたアクセスルート先へ、ＰＯＳＴの送付データを対象媒体へと誘導することで、これによりＷｅｂブラウザーのフィールド欄の要求ＵＲＬを常に一律固定に維持することができること、及びブックマークによるアクセス禁止措置を設けること、これらによって「アクセス履歴」に残るＵＲＬの無効化処理を行うことを特徴としている。
以上からログイン実行時（メンバーアカウント入力のプルダウン式入力認証ＭＡのＦＯＲＭ、セッション管理キー設定のＦＯＲＭ、プルダウン式入力認証ＰＷのＦＯＲＭ）あるいはコンテンツ・データの送信実行時のＦＯＲＭのＵＲＬに対してＷｅｂブラウザーのフィールド欄からＵＲＬを一律固定にすることができる。一方、クラッカーが「アクセス履歴」から辿れるアクセスルートは一律固定されたＵＲＬ一つしかない。
【０１２９】
本発明のインシデント対応型ログインシステムのうち、業種別フォーマット管理技術は、業種ごとに特化した業種別フォーマットを適宜活用することで、上書き不可のＣＤ−ROMに保存したワープロ文書を自己専有媒体に転送し、前記仮想上の［サーバー内図書館］において上書き・書き込み作成・編集処理作業を行い、更にこの経由表示されたワープロ文書のデータからコピー＆ペースト機能でワード・プロセッサ専用フォーマットに移し保存することができることを特徴としている。
【発明の効果】
【０１３０】
ア１）本発明の「表示済ＵＲＬの自動廃棄処理」に関する効果
ア１、ボットネットは、会員利用者の端末侵入からのアクセスも裏ルートからのアク
セスもどちらからも情報の収集ができなくなることで、長期的な足止め状態に
据え置くことができる。利用者はウィルス感染（ボットネットから）の影響を
うけることなく、ウィルス感染を気にすることなく（ログインシステム特化型
の手口・シナリオ）、システムに対して通常のログイン利用ができる。
【０１３１】
ア１、本発明の「表示済ＵＲＬの自動廃棄処理」は、別面、ログインシステムの「ログ
アウト」の自動化でもある。１回画面が表示されたことで、そのＷｅｂページの
自動廃棄が完了するため、従来のようにセッションの間隙を衝かれることもなく
、ステップ毎に「ログアウト」が自動化する。これによって利便性が向上する。
【０１３２】
ア１、更に本発明の「表示済ＵＲＬの自動廃棄処理」は、ブラウザーの「アクセス履歴」
機能の追跡ブロックの自動化でもある。これまで利用者が毎回利用の度に手動で
追跡ブロック措置を講じデータを消去しなければならなかったが、本発明によれ
ばそれが不要になる。
【０１３３】
ア１、本発明の「表示済ＵＲＬの自動廃棄処理」（時間のズレ応用技術、データの移動応
用技術）は、ＨＴＴＰ−Ｒｒｅｆｅｒｅｒによる情報漏洩に対してもカバーす
る。ＨＴＴＰ−Ｒｒｅｆｅｒｅｒとは、ＵＲＬを表示するＷｅｂブラウザーのフ
ィールド欄に露出される、現ページのひとつ前の来歴ＵＲＬのことをいう。Ｗｅ
ｂページによっては、来歴ＵＲＬが露見すれば情報漏洩を招致する。
【０１３４】
ア１、本発明の「随伴現象検出プログラム」（an accompanying phenomenon）は、「画像認証サーバー」に対するサービス妨害攻撃（ＤＤｏＳ）を阻止することができる。
ア２）本発明の「インシデント対応型ログインシステム」に関する効果
【０１３５】
ア２、本発明の「インシデント対応型ログインシステム」の総合的成果は、信頼性、機
密性が確保された伝送・提供手段の構築にある。Ｗｅｂブラウザーは本来、多
岐の通信処理プロトコルに対応している。よって、各分野、各方面の業務に利
用転用できる、インシデント対策の施された、次世代型Ｗｅｂブラウザーが実
現する。
【０１３６】
ア２、本発明の「インシデント対応型ログインシステム」とは、表示済ＵＲＬの自動廃
棄処理化を行うことで、成りすましログインの糸口となる遠隔覗き見（ミラー・
ブラウザー）を防止する技術を基本としている。
【０１３７】
ア２、本発明の「インシデント対応型ログインシステム」は、流出漏洩（データを窃取
されないようにする仕組み）プレビュー漏洩（データを閲覧できないようにす
る仕組み）を兼備した堅固なセキュリティーを端末・システム両面で保持でき
る。
【０１３８】
ア２、本発明のインシデント対応型ログインシステムによれば、自己宛送信が可能なので、ＣＤ−ＲＯＭ（ＣＤ−Ｒ）に保存した書きかけのワープロ文書等を自己専有媒体に転送し、業種ごとに特化した業種別フォーマットを介してサーバー内でワード・プロセッサを使って編集し保管することで、知財情報等のデータの機密性を保つことができる。また、プリントアウトもサーバー内のデータから直接行うことで情報漏洩を完全に遮断することができる。
【０１３９】
ア２、既存のＣｏｏｋｉｅをベースにした「認証技術」とは全く異なる、ＩＰアドレスの一意性を根拠にしたアクセス権の付与手段を創出し提供する。
【発明を実施するための形態】
【０１４０】
以下、本発明を実施するための形態につき各相当図面を参照して、ア１）、ア２）を個々に説明する。
前記ア１）の本発明の「表示済ＵＲＬの自動廃棄処理」うち、図１は、「時間のズレ応用技術」の仕組みを表す概略図である。
「時間のズレ応用技術」を実施するための一形態につき、以下、図１を参照して説明する。
Ｗｅｂ通信は、ブラウザーのＵＲＬを唯一の手がかりとしてページのコンテンツ情報を提供・伝達する手段である。従って、所定の「ＵＲＬ」が分からなければ、そのページを表示し閲覧することができない、とするのが、Ｗｅｂページである。
また、Ｗｅｂのページ構成を満たす条件として、前ページ、後ページをブラウザーの「戻る」「進む」で操作する場合において特に支障がなく、前後ページを比較参照する場合において通常の閲覧が可能であれば別段問題はないことになる。
ところがもともとＷｅｂページは「ＵＲＬ」を根拠として情報を提供する手段であるので、「ＵＲＬ」が分からないということは極めて不便である。そういう面においてブラウザーの「アクセス履歴」は機能的に優れてはいるが、前述したようにこれを悪用されると、一転して情報の漏洩ツールと化す。
【０１４１】
本発明の「表示済ＵＲＬの自動廃棄処理」のうち、「時間のズレ応用技術」は、ボットネットにＷｅｂブラウザー(7)を上記のような情報の漏洩ツールとさせないための技術であって、Ｗｅｂ画面の表示を「時間のズレ応用技術」の仕組みによって制御することにより、これを実現する。
「時間のズレ・誤差」が発生する仕組みについては、その根拠判定をサーバー時計(2)に求める。この場合、システムのサーバー時計は、グリニッジ標準時刻を基準に設定されている。
図１の１−２に示すように記録媒体Ａ(5)に記録した時間とリアルタイムに進行するサーバー時計(2)を対比した時、そこに時間の誤差(11)が形成される。
【０１４２】
図１の１−１に示すようにＵＲＬ１(1)（パラメーター）がステップ(3)に到着した時、所定のデータが記録媒体Ａ(5)に記憶される。その際、図１の１−３に示す経過時刻等の参照資料となるスタディ・データ(13)からステップ到着時刻(t)より得られた現在経過時刻(X)を取り出し、記録媒体Ａ(5)に記録する。これによって上記ＵＲＬ１(1)（パラメーター）のデータは、記録媒体Ａ(5)に記憶されたことで、不動となり、確認体(6)がこれを認識して、Ｗｅｂブラウザー(7)に表示一致画面(8)が表示される。表示一致画面(8)には所定のコンテンツ情報が表示される。
【０１４３】
Ｗｅｂページの表示画面は、１度表示されると、その画面を表示しつづけるブラウザーの特性から、利用者には特に支障はない。この場合、「ＵＲＬの自動廃棄処理」が実際に完了しているか否かは、利用者がブラウザーの「更新」操作を行って確認するしか方法はないことになるが、正規の利用者が通常、使用するにあたって、そのような確認は不要である。更に一旦、表示されたことで、前後ページを比較参照することができるので通常の閲覧が可能になる。
【０１４４】
一方、ボットネットが、利用者と随伴アクセスによって同一「ＵＲＬ」を表示しても、ＵＲＬ判定(9)が確認体(6)から時間のズレを割り出し、１回目のＵＲＬ表示済を判定し、２回目のＵＲＬ表示をブロックするため、表示不一致画面(10)（白紙化状態等）へ誘導する。これによってクラッカーは利用者と同一画面を閲覧することができない。これは、秒差の遅れによりデータが後着となる理由の他に随伴ＩＰアドレスの照合時間も関係する。この場合、ボットネットは条件的にハンディを負っていることになるので、先着の利用者の方の画面表示が優先されることになる。
なお、誤差判定根拠(12)の機能は、ＵＲＬ１(1)のデータとして記録媒体Ａ(5)に記録されたときの「記録時間」とサーバー時計(2)の「現在時刻」との時間の誤差を計時する。
【０１４５】
通常、静的Ｗｅｂページ、動的Ｗｅｂページともに、ブラウザーの「更新」操作を行っても画面表示は何ら影響を受けないし、左右されないが、本発明の場合、時間のズレで「ＵＲＬの自動廃棄処理」が完了するため、「更新」操作すると画面が表示一致画面(8)から表示不一致画面(10)（白紙化状態等）へ入れ替わる。自動的に画面表示を制御することができるので、同一の「ＵＲＬ」であっても、記録媒体Ａ(5)に記憶された同一時刻以外のＵＲＬはすべて自動廃棄されることになる。これによりミラー・ブラウザー（遠隔覗き見）は成立しなくなる。
【０１４６】
次に、「データの移動応用技術」を実施するための一形態につき、図２を参照して以下説明する。
図２の２−１に示すように、まずＵＲＬ１(14)（パラメーター）が、ステップ１(15)に到着した時、記録媒体１(16)に記録される。
これを判定体１(17)が有効と認識してＵＲＬ１画面(18)に情報コンテンツを表示する。その際の判定根拠は、ＵＲＬ１(14)のデータが記録媒体１(16)に記録されたことによるデータの「存在」による。
【０１４７】
更にステップ移動に伴い、その際、「存在」データは自動的に記録媒体１(16)から削除される。これにより記録媒体１(16)からＵＲＬ１(14)のデータが消去されたことで、データが「不存在」となる。このデータ「不存在」を判定体２(19)が認識してＵＲＬ１画面(18)の情報コンテンツを不表示にする。この不表示がＵＲＬ１廃棄画面(20)に相当する。当該「データの移動応用技術」の仕組みはこのように構成されている。すなわち、ステップ移動毎に媒体に「ＵＲＬ」のデータを記録することで「存在」、記録媒体から［ＵＲＬ］のデータが自動的に削除されることで「不存在」が形成される。
そうすると、クラッカーが利用者の端末から「アクセス履歴」の［ＵＲＬ］情報を入手して、［裏ルート］からミラー・ブラウザーによる手法で、システムのＷｅｂサーバーにアクセスしたとしても、利用者が先行して１回閲覧したことによって、媒体のデータが削除されており、常時「不存在」（ＵＲＬ１廃棄画面）となる。これはステップの移動によって、ひとつ前のステップは使い捨てにされている。
【０１４８】
通常、静的Ｗｅｂページの場合、「ファイル名」を有した個々のファイルとして単独にＷｅｂサーバーのディレクトリに保存されているが、動的Ｗｅｂページの場合、必ずしも個々のファイルとして保存されているわけではなく、基本的に単独の「ファイル名」そのものがない。その表示画面の生成ファクターがデータベースに纏まった情報源として存在していて、そのデータベースから呼出したデータの組成・組み合わせ条件によって画面表示される仕組みである。
従って組み合わせパターンによって画面情報が変化するが、上記のようにデータ「不存在」もしくはデータ「存在」が形成される条件によって、コンテンツ情報が画面から不表示に変化するＷｅｂページは現実にはない。というより既存のＷｅｂ技術の場合、そのような表現方法（自動廃棄処理）そのものが無意味であったからに他ならない。
すなわち、既存のデータベースは、表示画面の情報諸元であって、通常は、データの自動削除はされない。例えば、投稿サイトなどでデータベースからデータが削除される場合は、その投稿者の意思によって行われる。
従って、本発明の「表示済ＵＲＬの自動廃棄処理」は、カレント性（目下、現在進行形）データを含むデータの移動によって、作為的制御あるいは強制的制御を行い、該当［ＵＲＬ］を表示させない技術である。これは、端末ＯＳ内のキャッシュ(cache)メモリの仕組みとは直接には関係しない。
【０１４９】
このような構成・仕組みにすることで、［ＵＲＬ］の自動廃棄が成立完了することになるため、［表ルート］から利用者の端末への不正アクセスも、［裏ルート］からの他者の端末を中継してのシステムへの不正アクセスも、正規利用者が画面表示したことで、その［ＵＲＬ］は使い捨てられているので、「ミラー・ブラウザー」が発生しないことになる。よって、ボットネットの「ミラー・ブラウザー」をすべて封じることができる。なお、図２の２−２は、「データの移動」の流れを示す。
因みに、本発明の「データの移動応用技術」を実施するための一形態は、ボットネットに対して［裏ルート］専用のものと看做すことができる。
【０１５０】
次に本発明の「随伴現象(an accompanying phenomenon)検出プログラム」を実施するための基本的形態につき、以下、説明する。
本発明の場合、ＩＰアドレス「随伴現象(an accompanying phenomenon)」の生起は、図３の３−１に示すように一方（Ａ−ＩＰ）が他方（Ｂ−ＩＰ）に絡みついている状態と仮定している。よって本発明の「随伴現象検出プログラム」は、この絡みついたそれぞれをステートレス通信の接続初期化断絶時に剥離・分離させることによって、もともとの単一ＩＰアドレスに戻し露見させる技術である。このようにすることで異なる複数のＩＰアドレスを顕在化させることができる。
【０１５１】
その場合、本発明では、原本ＩＰアドレスに適宜な数字を結合して結合ＩＰアドレスにする。なお、ＩＰアドレスの「．」（ドット）を除去するには、小数点の「．」を除去するように関数による構文では実行処理出来ないので、本発明では、簡易な方法として「結合化」を行う。
以下、図３を交え、本来のＩＰアドレスに適宜な数字（結合値）を結合して結合ＩＰアドレスにする仕組み、その一実施形態について説明する。但し、下の説明では、「結合値」を現在経過時刻にしているが、本発明では、「結合値」は現在経過時刻に限らない。例えば、「結合値」を当日通し番号や当日整理券番号にすると、アクセス数が「結合値」の条件になるので仕様が異なることになる。
今、仮にＢ−ＩＰ(30)のＩＰアドレスが「１１２．５２．３．２」（112.52.3.2）として、Ａ−ＩＰ(29) のＩＰアドレスが「２１３．１５．３．１６」（213.15.3.16）だとする。この時、図３の３−２のステップＡ(31)の到着時刻(t1)が［７：４６：２８］だとすると、現在経過時刻(X1)は、「27988」になる。現在経過時刻(X1)は随時、スタディ・データ(42)から取り出すことができる。
Ｂ−ＩＰ(30)の（112.52.3.2）に「27988」を後尾に結合すると「112.52.3.227988」、Ａ−ＩＰ(29)の（213.15.3.16）に「27988」を後尾に結合すると、「213.15.3.1627988」のようになる。
ここで記憶媒体Ｙ(34)に［７：４６：２８（074628）］時刻によって発生する結合値「27988」と一方のＡ−ＩＰ(29)の基準・結合ＩＰ「213.15.3.1627988」だけを記録し、ＵＲＬ−Ａ(37)のパラメーターに現在経過時刻(X1)の「27988」を反面確認照合のために埋め込み、ステップＢ(32)に移動したとする。
このようにすると、仮想上、記憶媒体Ｙ(34)とＵＲＬ−Ａ(37)のパラメーターとＡ−ＩＰ(29)とＢ−ＩＰ(30)に、現在経過時刻(X1)「27988」がそれぞれ存在することになる。
そこで移動したステップＢ(32)で、ＵＲＬ−Ａ(37)のパラメーターに存在する「27988」を抽出しておき、記憶媒体Ｙ(34)内のＡ−ＩＰ(29)の結合ＩＰ「213.15.3.1627988」から「27988」を取り出して、ここで照合を図ったとする。
【０１５２】
そうすると、移動ステップＢ(32)のheader(H)で照合を図った場合、上記ＵＲＬ−Ａ(37)パラメーターに存在する「27988」と記憶媒体Ｙ(34)内の結合値「27988」は当然、一致する。更に単一ＩＰアドレスであれば、本来は結合ＩＰ「213.15.3.1627988」だけしかないことになるので、そこから結合値「27988」が取り出せることになる。
ここでこの取り出した結合値「27988」を「213.15.3.16」に結合し、新たに結合ＩＰを作出し、記憶媒体Ｙ(34)内の基準・結合ＩＰ「213.15.3.1627988」と照合した場合、必ず一致するはずである。
更に念を押し、body(B)とfooter(F)で照合を図ったとしても、結果は変わらず一致することになる。
ところが発信ＩＰアドレスが重複した場合、header(H)もしくはbody(B)かfooter(F)のいずれかでＢ−ＩＰ(30) （「112.52.3.2」）が発現することになるので、結合ＩＰ「112.52.3.227988」となって顕在・露見する。このため、記憶媒体Ｙ(34)内の基準・結合ＩＰ「213.15.3.1627988」と照合すると、照合不一致が起きる。これは、前述したように発信ＩＰアドレスが重複した場合、通信には「先行」「後行」が発生するので、一種の物理的な「通信の衝突」現象によるものである。すなわち、「通信の衝突」による結合値の転移が発生する。
しかし、単一の場合、この物理的な「通信の衝突」が起きる余地が全くない。従って、結合値の転移は発生しない。
これが、結合ＩＰアドレスの「随伴現象」の基本的な仕組みである。本発明の「随伴現象検出プログラム」の目的は、この顕在化を誘発することにある。
【０１５３】
尚、現在経過時刻(X1)は、図３のスタディ・データ(42)の現在判定時刻(t1)の対応値のことである。スタディ・データ(42)には、当日の０時０分１秒(t1)〜２３時５９分５９秒(t1)に対応する現在経過時刻(X1)が秒刻みのデータとしてすべて格納されている。＊この場合、０時は、２４時と置き換える。
以上が、本発明の「随伴現象検出プログラム」を実施するための基本的形態である。
【０１５４】
通常、発信ＩＰアドレスが重複した場合、どちらが正当な発信ＩＰアドレスか、判別できない。ましてドットの付いたままであると、照合手段も限られるので、タイミングや照合する位置によっては「不正な通信」を見逃してしまう可能性が高い。
本発明の場合、誤り検出や正当な発信ＩＰアドレスの根拠を割り出しているのではないので、どちらか一方のみを一貫して基準にして照合していけばよいことになる。すなわち、上記したようにパケットデータにＩＰアドレスが重複した場合、その通信には「先行」と「後行」が生じるので、メインルーチン(Mr)において定点観測的に「先行」のみを一貫して抽出することができる。
これは、正当な通信であれば、ＩＰアドレスの「随伴現象」は起こり得ない、という通信プロトコルの基本原則を前提としている。本来、単一ＩＰアドレスの場合、「どちらか一方」という条件はない。そして発信ＩＰアドレスは、もともと単一ＩＰアドレスである。
更に言えば、対価の獲得目的のボットネットが犯跡隠蔽の手段として用いるＩＰアドレスの偽装工作は自己リスクの回避策であって、この先、ウィルス（不正プログラム）の手口・シナリオが変わっても基本的にこの方針は変えられない。
【０１５５】
本発明の「随伴現象検出プログラム」のうち、これを実施するための上記一実施形態の「随伴現象」検出手段に関しては、前述したようにＩＰアドレスを結合化し、随時、その状況に応じて結合ＩＰアドレスの適宜なパターンの組み合わせ（先頭と後尾の入れ替え）を用い、これらの組み合わせパターンによるＩＰアドレスの対峙によって行い、阻止する判定手段に関しては、ＩＰアドレスの不一致によって行うものとする。
なお、ＩＰアドレスの「．」（ドット）について再度、言及しておくと、ＩＰアドレスの「ドット」は、表記文字としては、例えば「２．５４」のような小数点と同一であるが、プログラミングする場合、単なる関数構文で小数点（ドット）が除去できるのに対して、ＩＰアドレスの「．」だけは関数構文では除去することができない。これはどのプログラム言語によっても単なる関数処理でＩＰアドレスから「ドット」を外すことはできない。従って、ＩＰアドレスから「ドット」を外すためには、別途、それ専用のプログラムが必要になる。
【０１５６】
上記の外、ア２）の別途に本発明の前記「時間のズレ応用技術」「データの移動応用技術」「随伴現象検出プログラム」を一体的・発展的・総合的に組み合わせた、本発明のインシデント対応型ログインシステム実施形態例について、以下、図４、図５を参照して、まず、輪郭・概略等を説明する。なお、図４は、本発明に係るインシデント対応型ログインシステムのうち、閲覧に特化した管理の構成図である。図５は、本発明に係るインシデント対応型ログインシステムのうち、セッション管理の構成図である。
これについては、「要約書」に記載した通り、機密性の高い情報を複数の遠隔地のユーザー間で、相互にリアルタイムなやり取りする上で欠かせない、情報漏洩に不安のない、最も安全性と信頼性の高い［伝送］と［提供］を共有するツールが実現化する。
これには、Ｗｅｂサーバーに、１回表示したＵＲＬをすべて自動廃棄する仕組みを有した本発明の上記のようなプログラムを実装、もしくはＡＰＩ方式にすることが不可欠である。かつＷｅｂブラウザーの画面表示方式が、Ｗｅｂサーバーからダウンロード（ＤＬ）されたデータを一旦、キャッシュ・メモリに蓄積・保存し、これをＤＬデータと交代・交換して画面表示するＷｅｂブラウザー特有の「保存・表示の仕組み方式」が鍵を握っている。
【０１５７】
企業やその分野のグループが個々で開発プロジェクトの詳細な打ち合わせを行う場合、あるいは知財情報、とりわけ弁理士事務所と依頼企業との間で情報（認証制『２０１４年１０月〜』ワード文書等）のやり取りをする場合、これには、情報の漏洩・流出による、インシデントの問題が最大のテーマになる。例えば、既存のメール方式による［伝送］手段の場合、ＳＳＬ暗号（Ｓ/ＭＩＭＥ）によってメール情報が外部ネットワークへ流出・漏洩するのを防いでいるが、このＳＳＬ暗号化が通用するのは、ネットワーク上の送信過程においてのみ有効であって、一旦、ユーザーの端末側に平文（復号）着信すると、スパイウェアなどクラッカーによる盗読の脅威に晒される。更に言えば、認証制に伴うメーカーサイドの海賊版対策プログラムの流出悪用も無視できない。
また、Ｗｅｂメールの活用は、ミラー・ブラウザーによる情報漏洩を誘発する状況にある。これに関しては、イントラネット、エクストラネット、グループウェア等も例外ではない。
その意味では、大容量のデータをサーバーの倉庫（専用ディレクトリ）に格納できる、ストレージ方式の場合、ドメインを除くＵＲＬを暗号化しており、この「暗号化ＵＲＬ」が分からない限りアクセスできない点で機密情報の［提供］手段として優れている。しかし、肝心の「暗号化ＵＲＬ」を相手に通知する手段はメールやＷｅｂページに依存している。
インシデントに対する懸念を払拭できない以上、安全かつ確実な［伝送］［提供］の共有ツールとは言えない、ことになる。
そのためには、A）データを窃取されないようにする仕組み（流出漏洩）、と同時に、B）データを閲覧できないようにする仕組み（プレビュー漏洩）を並立してシステムに装備することが必要である。
【０１５８】
本発明のインシデント対応型ログインシステム実施形態例は、具体的なビションとしては、「開発プロジェクト特化型システム」を含む、イントラネット、エクストラネットの「枝出しネットワーク」構築という方向性・位置付けになる。
例えば、弁理士、税理士、弁護士などは、イントラネットやエクストラネットを構築する企業にとって、グループ企業でも外郭でもないが、これら企業体と連携して活動しており、専門職の協力パートナーである。かつその企業にとって機密性の高い知財情報、財務情報、法務情報を日常的に扱っている。また複数の企業との取引関係があり、インシデントに対する懸念を最も強く意識せざるを得ない分野・立場にいる。
しかし複数のイントラネット、エクストラネットのネットワークに所属するには、運用・管理・コスト面で躊躇せざるをえない。このような相対的協力関係にある専門職は、報道対カメラマン、出版対デザイナーや翻訳者、知財調査対探偵（コピー製品）、代理人、海外エージェント、バイヤーなど多岐に亘る。
従って、インシデントに対して安全かつ確実な［伝送］［提供］の共有ツールを大多数が未だ得られていない、というのが現状である。すなわち、これらの専門職の［伝送］［提供］手段は、現状では、概ね大半をＥ−メール、電話、Ｆａｘ、郵便に依存しているということになる。しかしＥ−メール送受信の場合、特定「標的型攻撃」に遭うと、用意周到なステレス型のシナリオが組み込まれ、対価を獲得しようとするから、通常の防御手段では殆ど役に立たなくなる。
【０１５９】
更にイントラネットやエクストラネットを構築する企業・組織・団体の専門分野を異にすると、建設・土木・建築、車両、鉄道、船舶、海運、航空、鉄鋼、機械、電機、電力（原子力発電所）、保険、投資信託、証券、銀行、出版、情報、新聞、通信、食品、物流、衣料、製薬、医療、警備、大学・研究機関、政党、公共機関、各国外務省、各国大使館・公使館、検察、刑務所、裁判所、警察、軍需、国連機関・・・等、インシデントに対する不安や業種ごとにその分野特有の特殊事情を有した「枝出しネットワーク」の対象専門職は数限りない。
また、ユーザー・インターフェース面を充実化させ、閲覧するためのツール・業種別フォーマット(59)や業種特化型送信ツールにバリエーションを持たせることで、例を挙げれば、既存のネットバンキング方式のような一律固定画面とは異なる法人向けに特化したネットバンキングを構築することも可能になる。ここでは、銀行と法人間で機密書類や資料のやり取りや融資の決済も電子化でき、より対面交渉に近い、ペイ・バイ・フォンのようなことも可能になる。よって事務的業務の効率・簡素化が実現できることになる。これはほんの一例に過ぎない。
【０１６０】
本発明のインシデント対応型ログインシステム実施形態例は、現状のイントラネット、エクストラネットのネットワークが、「データ層」（データベース処理）(d)「ファンクション層」（アプリケーション処理）(g)「プレゼンテーション層」（ユーザー・インターフェース処理）(f)の３層で構成されているのに対して、別途に「セキュリティー層」をセッション・セキュリティー処理(e-1)、更に閲覧・セキュリティー処理(e-2)に特化・独立して付加し、４層構造にした。
これは、A）データを窃取されない仕組み（流出漏洩）、B）データを閲覧できない仕組み（プレビュー漏洩）を確保するための手段に他ならない。
本発明の当該インシデント対応型ログインシステム実施形態例は、「開発プロジェクト特化型システム」及びイントラネット、エクストラネットの「枝出しネットワーク」を想定しており、個々の単体グループとしてはメンバー数もさほど多くなく限定的になり、またメンバーのコンピュータ・リテラシーも比較的高いと考えられる。
【０１６１】
以上を踏まえて、以下、［伝送］（送信）手段に関して図４、図５を参照して詳細を説明する。まず、基本的にＭＩＭＥ形式系の送信データは、外部ネットワーク(Nw)（ＥＶ−SSL）を経由することになる。この場合、ＥＶ−SSLによって、セキュリティー面（インシデント対策）が万全であることを前提とする。また、送信実行中にクラッカーによるセッションの割り込みが発生してもツインズＩＰブロック(78)あるいは〔当日アクセス情報〕の「錠」と「鍵」構造のセッション管理キー設定等の「セッション管理」により、送信実行者（メンバー）が「認証」に至る前段階でボットネットは拘束されるので、システムから直接、［伝送］情報を窃取することはできない。これは、詳細を後述するが、［表ルート］［裏ルート］共にクラッカーはシステムに侵入できない、仮にできても「閲覧に特化した管理」により阻止され目的を達成できない。
【０１６２】
前記したように既存の技術ベースは、ＩＰアドレスを応用した場合、ハード面に偏向していて、Ｃｏｏｋｉｅをベースにしたログインシステムの「認証技術」もこれに依存している。しかし現下のような錯綜するセキュリティー事情に鑑みれば、不正アクセスの脅威を払拭できない状況にある。前記したようにハード面の偏向は、以下のような理由が根底にある。
これまでネットワーク上で発信元ＩＰアドレスが急遽、更新される事例はすでに公知のことである。そうすると、通信パケットに在中する発信元［ＩＰアドレス］をソフト面の「認証技術」に応用した場合、このような緊急時に対して臨機応変にかつ即時に対処することが極めて困難である。
そこで本発明のインシデント対応型ログインシステム実施形態例は、前記したように前記［ＩＰアドレス］の一意性の維持・確保のような、緊急時にいつでも臨機応変に対応することができる仕組みを創出することで、発信元［ＩＰアドレス］をソフト面の技術に応用・活用できるようにしている。これによって、ステートレス通信の特性に最も即応・順応する「インシデント対策対応型のログインシステム一意性認証技術」を提供することが可能になる。
【０１６３】
本発明のインシデント対応型ログインシステム実施形態例のうち、メンバーの認証を行う「セッション管理」は、図５のうち、点線で示す認証ゾーン１(Z1)、認証ゾーン２(Z2)、認証ゾーン３(Z3)のように構成されている。以下、これらの認証の流れについて説明する。ここでは、クラッカーやロボットによる侵入・攻撃事例については前述したので、利用者の操作手順並びに各仕組みや機能面を中心に説明する。
認証ゾーン１(Z1)では、登録メンバーの真偽を識別するための処理が主として行われ、メンバーであるオペレーターによる運転前点検のようなイメージになる。
まずメンバーの端末がトップページを経て、システムに接続されると同時に接続ＩＰ判定(Ci)が行われ、メンバーの現有ＩＰアドレスの更新の有無がＩＰアドレス履歴記録媒体(69)にある二つの伏在記録のうち、バイト数別Ｉｐ媒体(Ip)の方で判定される。この場合、前記ツインズＩＰブロック(78)という仕組みによって、偽装ＩＰアドレスで侵入したロボットはすべて排除される。これは、ロボットがメンバーの端末を経由してメンバーのＩＰアドレスを偽装した場合の阻止手段である。
このことによりその接続ＩＰはメンバーのＩＰアドレスと判定できるので、メンバーの現有ＩＰアドレスがＩＰ桁数別記録方式(71)の媒体に存在しなければ、「変更」が確定し、１件更新追加記録される。これらは内部処理として自動的に行われるので、メンバーが直接これを意識することはない。システムに接続されると、まず表示されるのは、トップページのＰＯＳＴボタン(82)、次にメンバーアカウントを照合するプルダウン式入力認証ＭＡ(73)である。当該ＦＯＲＭのＵＲＬフィールド欄は、前記したように「一律固定ＵＲＬ(88)」にされている。
プルダウン式入力認証ＭＡ(73)の文字入力は、キーロガー対策のため、１文字ごとプルダウン・メニュー（数字０〜９・アルファベットａ〜ｚＡ〜Ｚ）から文字を選択する「プルダウン式入力」になっていて、これらが、パスワード桁数１個と８列横並びに配置されている。かつ、メンバーがパスワード桁数１個とプルダウン・メニューから「メンバーアカウント」の文字を８列選択し終え、複式操作ボタン(87)を１回押すと、「ＭＡ確認フィールド(Mf)」の中に選択した文字が充当表示される。このような複式操作をすることで、この「ＦＯＲＭ」のＰＯＳＴデータは、カレントＩＰアドレス記録媒体(68)とＩＰアドレス履歴記録媒体(69)のうちもう１つの「バイト数別Ｍａ媒体(Ma)」の保存媒体で同時に二面照合が図られる。また、このような複式操作の構成にすることより、ロボットの侵入を困難にしている。
【０１６４】
これは、カレントＩＰアドレス記録媒体(68)に同一の「メンバーアカウント」が既に存在すれば、このメンバーは、当日２回目かそれ以降ということになるので、認証ゾーン２(Z2)のセッション管理キー設定(SK)の「ＦＯＲＭ」へ直ぐに移動させるためである。設定キーである〔ワンタイムアカウント(75)〕が初回ログイン時に生成されているのでこれが可能になる。ただし、これは、前述したように特に拘らない。
反対にカレントＩＰアドレス記録媒体(68)に同一「メンバーアカウント」が存在しないということは、メンバーのログインが当日初回ということになる。この場合、ログデータ(Ld)、第二認証媒体(83)にもメンバーの当日データが存在しないことになるので、当日基礎データが充当記録される。ログデータ(Ld)に充当される基礎データは、「当日日付」「原本ＩＰアドレス」「当日通し番号」「曜日キー」「アクセス時分秒」。第二認証媒体(83)に充当される基礎データは、「当日日付」「当日通し番号」「ワンタイムアカウント(75)」「メンバーアカウント」「パスワード桁数」「第２メソッド判定」である。
カレントＩＰアドレス記録媒体(68)には、先行して「当日日付」「当日通し番号」「原本ＩＰアドレス」「メンバーアカウント」「媒体識別ニックネーム」が記録される。初回のみ、〔ワンタイムアカウント(75) 〕が生成され上書きされる。
これらの、カレントＩＰアドレス記録媒体(68)に記録される当日データは、メンバーに対してアクセス権を付与するための仕組みである、〔当日アクセス情報(86)〕の「錠」となる情報であり、当日の「在籍証明書」になる。
本発明のインシデント対応型ログインシステム実施形態例のうち、セッション管理キー設定(SK)の「ＦＯＲＭ」は、上記の「錠」に当たり、これに「鍵」となる「ワンタイムアカウント(108)」をメンバーが差し込むことで、あたかもオペレーターが、これより運転に入るようなイメージになる。当該セッション管理キー設定(SK)のＦＯＲＭのＵＲＬフィールド欄も、前記したように「一律固定ＵＲＬ(88)」にされている。
【０１６５】
認証ゾーン２(Z2)では、ここでは流れとして登録メンバーの真偽が確定しているので、ログインパスワード認証に入るための準備が主として行われる。
セッション管理キー設定(SK)の「ＦＯＲＭ」には、画面上の適宜な位置に〔ワンタイムアカウント(75)〕の文字が表示されていて、メンバーがマウスでコピー＆ペーストしてフィールドに流し込む方式である。この他、隠しフィールド(Hf)に「メンバーアカウント」が組み込まれていて、更に上記の「プルダウン式入力認証ＭＡ(73)」の複式操作を行ったときに選択したパスワード桁数が＜ＦＯＲＭ＞のフィールドに、例えば「７」を選択した場合、「７」が充当表示される。この数字は、ここで変更することができない。メンバーが当日２回目かそれ以降の場合、これらが調整されている。
ログインパスワード認証もプルダウン・メニューから数字・アルファベット文字を選択する方式なので、上記のように例えば「７」を選択した場合、プルダウン・メニューも横７列しか表示されない。しかもこの場合、順当であればＰＷ確認フィールド(Pf)にメンバーのログインパスワードがリアルに充当表示されるが、パスワード桁数の選択を誤った場合、ＰＷ確認フィールド(Pf)は空になる。これは、ログインパスワードを格納している認証用データ登録媒体(70)もパスワードの桁数別に４つの媒体に分散収納されているため、メンバーが「７」を選んだとすると、認証用データ登録媒体(70)内の「７」の媒体に、隠しフィールド(Hf)の「メンバーアカウント」と符合するログインパスワードが存在しなければ検索できないからである。当該プルダウン式入力認証ＰＷ(72)のＦＯＲＭのＵＲＬフィールド欄も、前記したように「一律固定ＵＲＬ(88)」にされている。
このように一連の流れには、必ず前後の仕組みとの一連関連付けの因果性の仕掛けが施されていて、それをクリアできなければ次のステップに進めない。あるいは処理上の実効性が得られなくなる。
このようにしてセッション管理キー設定(SK)の「ＦＯＲＭ」のデータは、第二認証媒体(83)で〔当日アクセス情報(86)〕の「鍵」となる〔ワンタイムアカウント(75)〕の照合処理が図られる。
【０１６６】
認証ゾーン３(Z3)は、ここでは流れとして登録メンバーがログインパスワード認証を経て送信者ボックス(Sb)あるいは閲覧者ボックス(Vb) を確保するまでのプロセスが中心になる。
「ログインパスワード」の場合、上記したようにプルダウン式入力認証ＭＡ(73)で自己のパスワード桁数を選んだ値（プルダウン配列個数）がそのままここに表示される。例えば９文字ある結合「ｎａｍｅ」の場合は以下のようになる。
＜select  name=９ＨｐＸ６Ｚｋｑ１＞〜＜select  name=９ＨｐＸ６Ｚｋｑ９＞。うち、「＜select  name」は、ＣＧＩの構文の初頭に付するプルダウンのタグを表す。うち、「９ＨｐＸ６Ｚｋｑ１」から「９ＨｐＸ６Ｚｋｑ９」は、「１」〜「９」まであるプルダウンの結合用の「ｎａｍｅ」を表す。
すなわち、セッション管理キー設定(SK)の隠しフィールドに設けられた「メンバーアカウント」が暗号化（９ＨｐＸ６Ｚｋｑ）されて、「ログインパスワード」の「ｎａｍｅ」を構成する主要組成として付与され、いわばここで再活用される。これもセッション管理キー設定(SK)の仕組みとの関連付けになる。
「メンバーアカウント」が暗号化された部分が「９ＨｐＸ６Ｚｋｑ」に相当し、後尾の「１」〜「９」はプルダウンの各番号に当たる。画面表示としては、これら９個のプルダウンが横一線に並んで配列されていることになる。なお、自己の選んだパスワード桁数の値が正確であれば、ＰＷ確認フィールド(Pf)に、メンバーの「ログインパスワード」が充当表示されているので、メンバーはこの充当文字を見ながらプルダウンから１文字ごと選んでいけばよい。
【０１６７】
更にこの９個の「ｎａｍｅ」は、正確には、第二認証媒体(83)で照合が図られたときの照合時刻(Xt)である現在経過時刻(X)が結合条件に加わり、プルダウン番号の前にサンドイッチ状に挟まれる。例えば照合一致した時刻(t)が［７：４６：２８］だとすると、現在経過時刻(X)は、「27988」になる。しかもこの「27988」も、例えば、（si2pdwlv
）のように暗号化され、かつ、暗号化された「ユーザーアカウント」に結合付加されるとき、文字の位置がシャッフルして、サンドイッチ状に挟まれる。すなわち、プルダウン番号１番が＜select  name=９ＨｐＸ６Ｚｋｑsi2pdwlv１＞〜プルダウン番号９番が＜select  name=９ＨｐＸ６Ｚｋｑswlvi2pd９＞のようになる。
なお、シャッフルの仕組みは、現在経過時刻(X)に応じて原本となる（si2pdwlv）の文字位置の置き換え法則があって、これによって行う。このようにすることで、「ユーザーアカウント」の方の暗号とシャッフルされた方の暗号の境界が分からなくなってしまう。
また、照合が一致した時刻(t)は、偶発数字である。したがって、〔当日アクセス情報(86)〕の「鍵」となる〔ワンタイムアカウント(75〕が、第二認証媒体(83)で照合された時刻を特定することは、不可能である。かつ、当日、初回あるいは２回目かそれ以降、ログインする都度、毎回、この「鍵」で施錠するため、照合時刻(Xt)がその度に入れ変わる。よって「ｎａｍｅ」の条件は、その度に変更されることから、牢固なナンス性を有している。
【０１６８】
更に、セッション管理キー設定(SK)のＰＯＳＴボタン(82)をメンバーが押すと、「ＦＯＲＭ」の〔ワンタイムアカウント(75)〕等のデータは第二認証媒体(83)で照合され、一致した場合のみ時刻付与媒体(84)へと渡される。ここで照合されたときの「照合時刻(Xt)」が時刻付与媒体(84)で、「メンバーアカウント」「当日通し番号」「パターン数字（あるいは「『Ｅ』判定」）」と共に裏付け情報として記録される。
従って時刻付与媒体(84)を結ぶ媒体直通ルートパス(Dp)（＊図示していない）を適宜な位置に設ければ、どのアクセスルートからでもデータを参照できるので、これによって、メンバーのログイン回数が掌握できることになり、このことは、バイト数別Ｉｐ媒体(Ip)あるいはバイト数別Ｍａ媒体(Ma)と適宜に組み合わせることで、ステップの「ＩＮ」「ＯＵＴ」を事細かにチェックすることが可能になる。
このようにしてメンバーであるオペレーターが、自己の送信者ボックス(Sb)あるいは閲覧者ボックス(Vb) を確保することができる。以上が、本発明のインシデント対応型ログインシステム実施形態例のうち、「セッション管理」に相当する。
【０１６９】
当該「ｎａｍｅ」の暗号化に関していえば、クラッカーがまず難航するのは、もともと「ｎａｍｅ」は固定値である、という概念への戸惑いになるであろう。例えば、<input type=text name=dog value=oneone><input type=hidden name=cat value=nyonyo>のような「ＰＯＳＴ」データの場合、これを前記の「ドメイン・サブルーチン＆９ＨｐＸ６ＺｋｑJsi2pdwlv１＝Ｚ・・・・・・・＆９ＨｐＸ６Ｚｋｑswlvi2pdJ９＝ｔ」に置き換えると、「ドメイン・サブルーチン・プログラム名＆dog＝oneone・・・・・・・＆cat＝nyonyo」になる。「dog」と「cat」が「ｎａｍｅ」である。「oneone」と「nyonyo」が「ｖａｌｕｅ」である。
従来の場合、「ｎａｍｅ」は固定値（固定長）なので、ＣＧＩの構文に付するタグを
次々取り外していけば、容易に連結パラメーターを組み立てることができた。すなわち、<FORM method=POST action=ドメイン・サブルーチン>から</FORM>の終了タグ
までの中に存在するＨＴＭＬタグ（<input type=text name=）を文字列のなかから、必
要な分だけを抽出すればよかった。タグのバイト数が分かっているので、ラッコが貝の
殻を割って、なかからむき身を得るような方法で不要タグを順次取り外し、必要データ
だけを次々に＆＝で結合していけばよかったのである。
ところが、本発明のインシデント対応型ログインシステム実施形態例では、「ｎａｍｅ」は固定値ではなく、不定流動値である。かつ「照合時刻」という偶発数字の暗号化がセットされ、しかも組み合わせた暗号の結合境界が分からない。因みに１日は、８６４００秒ある。これにグレゴリウス暦の〔秒数ランダム曜日キー〕が加わる。従来のような方法は全く通用しない。加えてパラメーターの絶対必要バイト数を算出することでバイト短縮・ブロック(79)によりアクセスルートを寸断することができる。また、３０５送信エラー(80)も活用できる。
【０１７０】
次に［提供］（閲覧）手段に関しての「閲覧に特化した管理」について説明する。尚ここでは、［提供］（閲覧）手段の「ログイン」は「送信」の場合と共通なので、上記のような説明によってメンバーの「ログイン」が終了していることを前提とする。
上記の［伝送］手段には、送信するデータに応じて、提供側ブラウザー(45)の送信先選択(46)を選ぶことでメンバー「指定送信」と「全員送信」の切り替え選択ができる。これにより被提供側ブラウザー(58) のメンバーがデータを受信したとき、着信件数サイン(49)の表示カラーが異なって表示されるので、「指名送信」か「全員送信」か、をすぐに識別できる。かつ送信メンバー名及び送信メンバーの所属先等も判明する。送信先選択(46)のデフォルトは、「全員送信」である。
送信者ボックス(Sb)に入るアクセス権を得たメンバーは、［指名］か［全員］かの送信先選択(46)ボタンを押すことで、アップロード機能送信ＦＯＲＭ(47)を表示することができる。入力データは、外部ネットワーク(48)（ＥＶ−SSL）を経由して、システムへ送付され、共用あるいは個専有の媒体に記録・保存される。この場合、テキスト系（文字情報）とバイナリー系は別々に記録・保存される。更に画像・音声等のコンテンツ・データは、個専有拡張子別収納(66)、共用拡張子別収納(67) のような媒体に拡張子別に区分けして保存される。またこれらが記録・保存される媒体には、トラバーサル防御プログラム(57)が実装されていて、クラッカー等が保存ファイルを探索・探知しようとしても、前記したクローンＩＰアドレス(56)が発現され、これを阻止する。
【０１７１】
一方、被提供側ブラウザー(58) 側の、閲覧者ボックス(Vb)に入ったメンバーが、ページを閲覧する場合、前記したようにインデックス情報(63)のタイトル・ハイパーリンク(55)をクリックすることで、１ページごとにページを表示する。これについては、以下、操作手順や隠蔽ディレクトリ(Sd)の仕組みも併せて詳述する。
例えば、ブラウザーの「アクセス履歴」に「http://niche-echo.com/main/」と表示された場合、通常は、これをミラー・ブラウザー（遠隔覗き見）することができる。既存技術では、「セッションＩＤ」「https://」や「Cache Control」（ブラウザーのキャッシュを無効化するプログラム）によって遮断しているが、前述したようにＣｏｏｋｉｅがスリ変えられ、［裏ルート］から同時進行でミラー・ブラウザーが行われた場合、「/main/」が検索ディレクトリに相当するので、当然、コンテンツ情報は画面表示される。
これは、データベースが「/main/」に存在するということを意味しているので、条件処理によって「検索」が実行されるからである。そこでこの「/main/」を隠蔽ディレクトリ(Sd)に変換すると、http:// niche-echo.com/alkj2gwz5tpZsmnhd9bk3NvfreSpqのようになる。この「http:// niche-echo.com/alkj2gwz5tpZsmnhyd9bk3NvfreSpq」は、「アクセス履歴」に残ることになる。
しかしこの「http://niche-echo.com/alkj2gwz5tpZsmnhd9bk3NvfreSpq」のＵＲＬのうち、「alkj2gwz5tpZsmnhd9bk3NvfreSpq」の部分は、送信者がコンテンツ情報をサーバーに送って記録・保存されたときの、その保存時刻の「スライド時間」の暗号を含むＵＲＬである。正確には、「alkj2gwz5tpZsmnhd9bk3NvfreSpq」のうち、「d9bk3NvfreSpq」は、共用テキスト系媒体(43) ・共用バイナリー系媒体(44)、あるいは個専有テキスト系媒体(64) ・個専有バイナリー系媒体(65)に記録されたときから経過したその、「スライド時間」が暗号化されたものである。
閲覧者であるメンバーがこのページ情報を閲覧するためには、「インデックス情報」のハイパーリンクのページ・タイトルを必ずクリックしなければならない。よってこのＵＲＬが常に「アクセス履歴」に残ることになる。
「インデックス情報」は［指名］受信ガイドデータ(60)、［全員］受信ガイドデータ(61)の各データの反映情報であり、それぞれのハイパーリンクのＵＲＬには、［当日アクセス情報］からのアクセス導線によって付与された受信者の原本ＩＰアドレスが「鍵」として連結されている。更にこのＵＲＬにはこの他、［連続ページ番号］が結合されていて、［当日アクセス情報］の媒体で「鍵」の照合が図られ、次に指名の方は［指名］受信ガイドデータ(60)へ、全員の方は［全員］受信ガイドデータ(61)へと渡される。このようにして、受信データ１件ごとに閲覧メンバーが自己で内鍵を掛ける。
よって、このハイパーリンクのＵＲＬを辿ることでしか、上記した隠蔽ディレクトリ(Sd)に変換されない。すなわち、それぞれの受信ガイドデータでの検索は、［連続ページ番号］のキーによって前記［単項目検索(Sr)］で抽出する。これによって受信者の原本ＩＰアドレスが、ここで送信者のワンタイムアカウントと交換され、曜日キーが連結されて暗号ルーチン生成体(54) で、スライド計算時計(53)がスライド時間を時計し、このＵＲＬに連結される。以上のようにして隠蔽ディレクトリ(Sd)が形成される。これらが主として［閲覧に特化した管理］である。
【０１７２】
ここで「スライド時間」という意味について前記説明を補足する。共用テキスト系媒体(43) ・共用バイナリー系媒体(44) あるいは個専有テキスト系媒体(64) ・個専有バイナリー系媒体(65)等にデータが記録保存されたときの時刻は処理上、常に不動になる。そうすると、これをそのまま暗号化してしまうと、すぐに復号化され、クラッカーに解読されてしまう。そこで、「時差調整」が必要になる。「時差調整」とは、送信者がデータを送った時刻、と閲覧者が閲覧する時刻との時差、すなわち、経過した時間のことを指す。データが記録保存されたときの時刻と、閲覧した時刻には、当然、時差が生じることになるので、これを毎回（当日）、閲覧するページを画面に表示する都度、計時・算出すると流動化数字になる。それを暗号化すれば、結果的に保存されたときの時刻は、容易に判明しなくなる。これが、基本的に隠蔽ディレクトリ(Sd)の仕組みである。そして、常に流動化する「スライド時間」の仕組みになる。
これを具体的に言い換えると、仮に保存時刻が［７：４６：２８］だとすると、当日０時より算出した現在経過時刻(X)は、「27988」になる。これよりジャスト３０分遅れて［８：１６：２８］に閲覧したとすると、現在経過時刻(X)は「29788」になるので、そこに「1800」秒の時差が生じる。本発明のインシデント対応型ログインシステム実施形態例では、この時差を「スライド時間」という。
すなわち、メンバーがページを閲覧する場合、タイトル・ハイパーリンク(55)をクリックすると、［指名］受信ガイドデータ(60)もしくは［全員］受信ガイドデータ(61)に保存されたページ個々の「錠」データのうち、送信者のワンタイムアカウントと当日アクセス情報(86)から付与された受信者の原本ＩＰアドレス（「鍵」）がここで交換され、隠しステップ内の暗号ルーチン生成体(54)で、スライド計算時計(53)が上記「1800」秒の時差を計時する。これによって「スライド時間」を割り出す。そしてこれらが結合される。このようにして「スライド時間」が暗号化された、ＵＲＬの組成となる隠蔽ディレクトリ(Sd) が生成され、ＷｅｂブラウザーのＵＲＬフィールド欄に充当表示される。
クラッカーが、この「http://niche-echo.com/alkj2gwz5tpZsmnhd9bk3NvfreSpq」を「アクセス履歴」から入手してアクセスしても、この隠蔽ディレクトリＵＲＬ(51)は、「スライド時間」をスライド計算時計(53)がこれを計時し、「スライド時間」の経過により、ＵＲＬそのものが、もはや過去時間として自動廃棄されることになる。このため、前記「サブルーチン」擬きが、常に符合されなくなって、不一致になるため、コンテンツ情報は表示されない。
すなわち、既存のサブルーチンに相当する部分が照合構造になっていて、検索手段の方が入れ子のなかにあるので、実際には［連続ページ番号］のキーによって検索が終了していてコンテンツ情報が表示されていても、ロボットに肝心の入れ子の中を意図的に見られないようにする遮蔽カーテンのような仕組みになる。
これは、前記、表示時間のズレを応用した仕組みと基本的に同じであり、かつＵＲＬの「自動廃棄処理」を構成する仕組みである。
【０１７３】
Ｗｅｂブラウザーは、本来がパブリックに情報の［伝送］（送信）と［提供］（閲覧）を主目的とするツールであることから、これまで、技術的にも相反する［遮断］（漏洩）の概念が必要とされなかった。したがって、現状のままのＷｅｂブラウザーであれば、情報漏洩を阻止する手段がない。そしてインシデントの問題（脅威）が最大のネックとなる。
しかし、本発明のＵＲＬの「廃棄処理」の仕組みプログラムをＷｅｂサーバーに実装、もしくはＡＰＩ方式にすることで、［伝送］と［提供］と［遮断］がそれぞれ役割分担されて三位一体となる技術に変貌する。かつ、Ｗｅｂブラウザーと合体することで、インシデント対策が強固に施された、最も安全性と信頼性の高い情報の［伝送］［提供］［遮断］手段が実現する。各分野、各方面のトレード・シークレットを含む機密情報を扱うプロジェクト業務、あるいはイントラネット、エクストラネットの「枝出しネットワーク」の専門職ユーザーの双方向情報共有ツールとして通常利用することが可能となる。
更に当該インシデント対応型ログインシステム実施形態によれば、世界中のどこからでも時間と距離に関係なく、リアルタイムな情報を相互にやり取りできる共有ツールが実現する。このことは、複数の取引先、あるいは支社・拠点を海外に持って、事業を展開している企業や組織にとって、利便性の高い必需ツールとなる。本社・支社間を常時、オンライン化して置くことで、機密情報を回覧式に扱えることから、情報の格差を均等にできるばかりでなく、格段に事業のスピード化、効率化が実現できる。「枝出しネットワーク」を、このように海外向けに応用することも可能である。
この他、ノマドロジー型在宅勤務ツールとしても、将来的に活用が期待できる。さらに当該インシデント対応型ログインシステム実施形態によれば、メーラーの代替用途としても活用できるので、機密性の高い情報を端末に保存せず、機密情報のやり取りを当該インシデント対応型ログインシステムによって行い、専ら機密性の高い情報資産をサーバーに保管することで、仮想的に利用者専用の［サーバー内図書館］を構築することも可能である。
【０１７４】
例えば、ＣＤ−ＲＯＭのうち、ＣＤ−ＲＷは、上書きが可能なため、この機能が端末内でデータの消去（証拠湮滅）に悪用される。しかし、ロボットは、ＣＤ−Ｒに一旦、保存したデータを消去できない。当該インシデント対応型ログインシステム実施形態によれば、業種ごとに特化した業種別フォーマット(59)を活用することで、ワード・プロセッサ専用フォーマット(CD-R)に保存したワープロ文書を自己専有媒体に転送し、前記［サーバー内図書館］においてこれをサーバー内で書き込み作成・編集することができる。
また、［サーバー内図書館］にこれを保管し、あるいはコピー＆ペースト機能でワード・プロセッサ専用フォーマット(CD-R)に保存することもできる。機密情報の大半は、ワープロ文書と考えられるので、端末保管データに依存しない端末を自身でカスタマイズすることができる。よって、とりわけ弁理士事務所と依頼企業との間で知財情報のやり取りをする場合、本発明の上記のような業種別フォーマット(59)を活用することで、流出漏洩、プレビュー漏洩を自己防衛することが可能になる。
【図面の簡単な説明】
【０１７５】
【図１】図１は、本発明の「時間のズレ」の仕組みを表す概略図である。
【０１７６】
【図２】図２は、本発明のデータの移動（「存在」「不存在」）の仕組みを表す概略図である。
【０１７７】
【図３】図３は、本発明の随伴現象検出プログラムの仕組み・概念図である。
【０１７８】
【図４】図４は、本発明に係るインシデント対応型ログインシステムのうち、閲覧に特化した管理の構成図である。
【０１７９】
【図５】図５は、本発明に係るインシデント対応型ログインシステムのうち、セッション管理の構成図である。
【０１８０】
1……ＵＲＬ１
2……サーバー時計
3……ステップ
4……排他制御
5……記録媒体Ａ
6……確認体
7……Ｗｅｂブラウザー
8……表示一致画面
9……ＵＲＬ判定
10……表示不一致画面
11……時間の誤差
12……誤差判定根拠
13……スタディ・データ
X……現在経過時刻
t……ステップ到着時刻
14……パラメーターＵＲＬ１
15……ステップ１
16……記録媒体１
17……判定体１
18……ＵＲＬ１画面
19……判定体２
20……ＵＲＬ１廃棄画面
21……パラメーターＵＲＬ２
22……ステップ２
23……記録媒体２
24……判定体３
25……ＵＲＬ２画面
26……判定体４
27……ＵＲＬ２廃棄画面
28……データ判定根拠
29……Ａ−ＩＰ
30……Ｂ−ＩＰ
31……ステップＡ
32……ステップＢ
33……ステップＣ
34……記憶媒体Ｙ
35……記憶媒体Ｚ
36……Ｗｅｂのページ構成
37……ＵＲＬ−Ａ
38……ＵＲＬ−Ｂ
39……到着時刻Ａ
40……到着時刻Ｂ
41……到着時刻Ｃ
42……スタディ・データ
X1……現在経過時刻
t1……現在判定時刻
H……header
B……body
F……footer
Mr……メインルーチン
To……先行結合
Ba……後行結合
43……共用テキスト系媒体
44……共用バイナリー系媒体
Dp……媒体直通ルートパス
45……提供側ブラウザー
46……送信先選択
47……アップロード機能送信ＦＯＲＭ
48……外部ネットワーク
49……着信件数サイン
50……プレビューボタン
Cp……切替えポイント
Sd……送致手段
Rd1…経由送致手段１
Rd2…経由送致手段２
51……隠蔽ディレクトリＵＲＬ
52……相対処理媒体
53……スライド計算時計
54……暗号ルーチン生成体
55……タイトル・ハイパーリンク
Td……当日アクセス情報
56……クローンＩＰアドレス
57……トラバーサル防御プログラム
58……被提供側ブラウザー
59……業種別フォーマット
60……［指名］受信ガイドデータ
61……［全員］受信ガイドデータ
62……一律固定ＵＲＬ
Rv……着信履歴情報
63……インデックス情報
64……個専有テキスト系媒体
65……個専有バイナリー系媒体
66……個専有拡張子別収納
67……共用拡張子別収納
Cb……インデックス切替えボタン
d……データベース処理
e-2……閲覧・セキュリティー処理
f……ユーザー・インターフェース処理
g……アプリケーション処理
Sh……着脱変換プログラム    
N1……［指名］媒体ニックネーム
Hs……隠しステップ
Rs……媒体ニックネーム対応表
Np……連続ページ番号
Po……ＰＯＳＴボタン
Bc……コール符番
Ss……ＳＳＬ
CD-R……ワード・プロセッサ専用フォーマット
e-1……セッション・セキュリティー処理
68……カレントＩＰアドレス記録媒体
69……ＩＰアドレス履歴記録媒体
Ip……バイト数別Ｉｐ媒体
Ma……バイト数別Ｍａ媒体
Sr……単項目検索
Wr……複項目検索
70……認証用データ登録媒体
Dp……媒体直通ルートパス
Re……更新追加記録
√……通し番号検問
Ld……ログデータ
71……ＩＰ桁数別記録方式
PW……パスワード桁数
72……プルダウン式入力認証ＰＷ
73……プルダウン式入力認証ＭＡ
Z1……認証ゾーン１
Sq……秘密の質問
74……拒否画面
75……ワンタイムアカウント
76……システム接続ポイント
Ci……接続ＩＰ判定
Sd……並列同時処理
Nw……外部ネットワーク
77……トップページ
Ap……アカンパニングフェノメノン
78……ツインズＩＰブロック
79……バイト短縮・ブロック
80……３０５送信エラー
81……メソッド判定符号
82……ＰＯＳＴボタン
Z2……認証ゾーン２
Pn……当日通し番号
SK……セッション管理キー設定
MA……メンバーアカウント
Xt……照合時刻
83……第二認証媒体
Pd……プルダウン式入力
Pf……ＰＷ確認フィールド
Mf……ＭＡ確認フィールド
84……時刻付与媒体
Z3……認証ゾーン３
Sb……送信者ボックス
Vb……閲覧者ボックス
85……ＰＷ桁数別記録方式
Hf……隠しフィールド
Kd……鍵発行処理
86……当日アクセス情報
87……複式操作ボタン
88……一律固定ＵＲＬ
89……コール符番
90……トラバーサル防御プログラム
Np……連続ページ番号
【図１】
2017049821.tif 000002
【図２】
2017049821.tif 000003
【図３】
2017049821.tif 000004
【図４】
2017049821.tif 000005
【図５】
2017049821.tif 000006