JP2024022850A - 受発注システム及び受発注管理方法 - Google Patents

Abstract

【課題】企業間の受発注情報を秘匿化する。【解決手段】受発注を管理する受発注システムであって、鍵管理サーバは、鍵シェアを取得可能な企業の認証情報を当該鍵シェアに付与するアクセス権管理部と、前記鍵シェアを鍵管理シェアサーバに配布する通信部とを有し、端末は、前記鍵シェアを前記鍵シェア保持サーバに要求する情報送信部と、取得した複数の前記鍵シェアから暗号鍵を復元する鍵復元・生成部と、前記復元された暗号鍵を用いて、入力された発注情報を暗号化し、受注情報を復号化する暗号・復号部と、前記復号化された受注情報を表示する表示部とを有し、前記情報送信部は、前記暗号化された発注情報を０次サーバに送信し、前記鍵シェア保持サーバは、前記認証情報に基づいて、各端末への鍵シェアの送信可否を判定する認証部を有する。【選択図】図１

Description

本発明は、受発注システムに関する。

一つの案件の業務全部又は一部を、０次企業から１次企業へ委託し、１次企業から２次企業へ委託するという流れで、再委託、再々委託のように、発注及び受注による業務の委託を段階的に繰り返すことにより、チェーン状又はフロー状の業務委託構造が形成される。このとき、最初の発注元である０次企業が、各段階の業務委託にかかる受発注情報を提供するサーバを運営することがある。

本技術分野の背景技術として、以下の先行技術がある。特許文献１（特開２０２１－１５８５４８号公報）には、ネットワーク上の複数の情報処理装置のうち少なくともいずれかであって、管理対象の情報を保持する記憶装置と、前記記憶装置から前記情報を読み出し、当該情報を所定数に分割し、前記分割で得た分割情報それぞれを異なる鍵で暗号化して所定数の暗号化情報を生成する処理と、前記鍵それぞれを秘密分散させ、所定数の分散化鍵を生成する処理と、前記ネットワーク上の他の情報処理装置からの情報提供要求が示す情報又は当該情報処理装置の運用者が関与する事案の情報、に対応する暗号化情報を、前記生成した暗号化情報から抽出し、前記他の情報処理装置に送信する処理と、前記所定数の分散化鍵を、前記ネットワーク上の各情報処理装置に分配する処理を実行する演算装置と、を備えることを特徴とする情報共有管理装置が記載されている。

特開２０２１－１５８５４８号公報

前述のような業務委託構造において、１次企業と２次企業の間の通信は、０次企業に秘匿化される必要がある。例えば、０次企業が復号化できないように、１次企業の受発注情報を暗号化する秘匿化がある。このとき、０次企業のサーバが秘密鍵を保持すると、０次企業が暗号文を復号化できる。１次企業や２次企業のクライアント端末で秘密鍵を保持すると、秘密鍵の紛失や流出リスクがある。また、第三者企業（例えば、金融機関）のサーバが秘密鍵を保持する場合、第三者企業が０次企業のサーバにアクセスして受発注情報を閲覧できる可能性ある。さらに、第三者企業のサーバが不正にアクセスされて秘密鍵が流出し、攻撃者が０次企業のサーバにアクセスして受発注情報を閲覧できる可能性がある。

本発明は、段階的な業務委託構造において、企業間の受発注情報の秘匿化を目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数の企業間で発注及び受注からなる業務委託が段階的に行われる商取引における業務の受発注を管理する受発注システムであって、プログラムを実行する第１演算装置と前記演算装置がアクセス可能な第１記憶装置とを有し、発注情報及び受注情報を管理する０次サーバと、プログラムを実行する第２演算装置と前記演算装置がアクセス可能な第２記憶装置とを有し、前記発注情報及び前記受注情報を暗号化するための暗号鍵を管理する鍵管理サーバと、プログラムを実行する第３演算装置と前記演算装置がアクセス可能な第３記憶装置とを有し、前記鍵から生成された複数の鍵シェアの一部を各々保持する複数の鍵シェア保持サーバと、プログラムを実行する第４演算装置と前記演算装置がアクセス可能な第４記憶装置とを有し、前記発注情報及び前記受注情報が入出力される端末と、を備え、前記鍵管理サーバは、前記第２演算装置が、前記鍵シェアを取得可能な企業の認証情報を当該鍵シェアに付与するアクセス権管理部と、前記第２演算装置が、前記鍵シェアを前記鍵シェア保持サーバに配布する通信部とを有し、前記端末は、前記第４演算装置が、前記鍵シェアを前記鍵シェア保持サーバに要求する情報送信部と、前記第４演算装置が、取得した複数の前記鍵シェアから暗号鍵を復元する鍵復元・生成部と、前記第４演算装置が、前記復元された暗号鍵を用いて、入力された発注情報を暗号化し、受注情報を復号化する暗号・復号部と、前記第４演算装置が、前記復号化された受注情報を表示する表示部とを有し、前記情報送信部は、前記暗号化された発注情報を前記０次サーバに送信し、前記鍵シェア保持サーバは、前記第３演算装置が、前記認証情報に基づいて、各端末への前記鍵シェアの送信可否を判定する認証部を有することを特徴とする。

本発明の一態様によれば、企業間の受発注情報を秘匿化できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

本発明の実施例のソリューションコンセプトを示す図である。 実施例１の受発注システムの構成を示す図である。 実施例１のアクセス権情報の構成例を示す図である。 実施例１のパスワード情報の構成例を示す図である。 実施例１の鍵生成・配布処理のシーケンス図である。 実施例１の１次企業から２次企業への発注処理のシーケンス図である。 実施例１の１次企業から２次企業への発注処理のシーケンス図である。 実施例１の２次企業が発注を確認する処理のシーケンス図である。 実施例１の配送完了通知から支払いまでの処理のシーケンス図である。 実施例１の配送完了通知から支払いまでの処理のシーケンス図である。 実施例１の０次企業サーバから送信される電子メールの例を示す図である。 実施例１の０次企業サーバから送信される電子メールの例を示す図である。 実施例１の０次企業サーバから送信される電子メールの例を示す図である。 実施例１の発注情報表示画面の例を示す図である。 実施例１の発注情報入力画面の例を示す図である。 実施例１の発注情報表示画面の例を示す図である。 実施例１の支払い確認画面の例を示す図である。 実施例２の受発注システムの構成を示す図である。 実施例２の鍵生成・配布処理のシーケンス図である。 実施例１の０次企業サーバの物理的な構成を示すブロック図である。

以下、添付図面を参照して、本発明の実施例を詳細に説明する。なお、以下の実施例は本発明の一例に過ぎず、本発明は図示された構成に限定されるものではない。

図１は、本発明の実施例のソリューションコンセプトを示す図である。

前述したように、一つの案件の業務全部又は一部を、０次企業から１次企業へ委託し、１次企業から２次企業へ委託するという流れで、再委託、再々委託のように、発注及び受注による業務の委託を段階的に繰り返すことにより、チェーン状又はフロー状の業務委託構造（以下、単に「業務委託フロー」という。）が形成される。なお、各段階の委託元は、発注元物流企業には限らず、各段階において委託元及び委託先がある。この場合、１次企業と２次企業の間の通信は、０次企業に秘匿化される必要がある。特に委託金額は秘匿性が高く、１次企業から２次企業への委託金額は、０次企業に知られるべきものではない。

このため、本実施例の受発注システムでは、１次企業や２次企業が使用する秘密鍵を秘密分散によって複数の秘密鍵シェアに分割し、複数企業のサーバで秘密鍵シェアを保持する。なお、秘密鍵シェアを２社以上のサーバで分散保持し、特に、０次企業以外の第三者企業を含めた複数のサーバで分散保持して、特定企業のサーバが全ての秘密鍵シェアを保持することによる秘密鍵の復元を防止する。例えば、（ｋ，ｎ）秘密分散法では、各企業のサーバが保持可能な秘密鍵のシェアは（ｋ－１）個以内となり、ｎ＝ｋ＝２の場合、各企業が保持可能な各秘密鍵のシェアは１個以内となる。各秘密鍵シェアのアクセス権が管理され、特定の企業のサーバのみが、秘密鍵シェアを入手して使用できるようにする。

前述した秘密鍵シェアによる受発注情報の秘匿化とサプライチェーン・ファイナンスを組み合わせてもよい。サプライチェーン・ファイナンスによって、委託先の１次企業や２次企業から作業完了の連絡を受け、委託元の０次企業や１次企業が作業完了（支払い）を承認すると、金融機関から１次企業や２次企業に委託費用が支払われて、委託費用の早期支払による、委託先の資金繰りを改善できる。

本明細書及び図面における「０次」、「１次」、「２次」などの表記は、構成要素を識別するために付するものであり、必ずしも、数、順序、又はその内容を限定するものではない。なお、本発明を輸送業、特に商品の納品業務に適用した場合の実施例を説明するが、輸送業に限らず多段階の業務委託フローとなる業界であれば、例えば建設業や製造業にも本発明は適用可能である。

本実施例では鍵シェアを複数の企業に分散して管理すればよく、鍵シェアの保持者は０次企業と金融機関でなくてもよい。例えば、システム提供会社や認証機関や公的機関が鍵シェアを保持してもよい。

＜実施例１＞
図２は、本発明の実施例１の受発注システムの構成を示す図である。

実施例１の受発注システムは、０次企業サーバ１００（請求項の「０次サーバ」に相当）、０次企業の記憶装置１５０（請求項の「第１記憶装置」に相当）、第三者サーバ２００（請求項の「鍵シェア保持サーバ」に相当）、第三者企業の記憶装置２５０（請求項の「第３記憶装置」に相当）、鍵管理サーバ３００（請求項の「鍵管理サーバ」に相当）、０次クライアント１８０、１次クライアント４００、及び２次クライアント５００（クライアント１８０、４００、５００は請求項の「端末」に相当）を有する。０次企業サーバ１００、第三者サーバ２００、鍵管理サーバ３００、０次クライアント１８０、１次クライアント４００、及び２次クライアント５００はネットワークを介して接続される。なお、受発注の階層構造は２次企業以外に３次企業や４次企業を含む多段階の階層構造でもよいが、０次企業から２次企業までの２階層の受発注構造で説明する。

０次企業サーバ１００は、０次企業、０次企業の子会社等の関連企業、又はサーバ管理の業務委託先企業が運用する計算機であり、メール通知部１１０、発注情報送受信部１２０、シェア・ｐｋ送信部１３０、及び認証部１４０を有する。メール通知部１１０は、１次企業及び２次企業の作業の契機となる電子メールを作成し、送信する。なお、１次クライアント４００及び２次クライアント５００に専用アプリケーションを導入すれば、メール通知部１１０は、電子メールではなく、当該専用アプリケーションへの通知を送信してもよい。発注情報送受信部１２０は、１次クライアント４００や２次クライアント５００と発注情報を送受信する。シェア・ｐｋ送信部１３０は、１次クライアント４００及び２次クライアント５００からの要求に従って、記憶装置１５０に格納された秘密鍵シェア及び公開鍵を送信する。認証部１４０は、鍵管理サーバ３００に格納されたパスワード情報を参照して、０次企業サーバ１００にアクセスする１次クライアント４００及び２次クライアント５００を認証する。認証部１４０による認証方法は、ＩＰアドレス及びパスワード以外の方法でもよい、ＩＰアドレスは、他人が成り済ます可能性があるため、例えば、鍵生成者が発行したクライアント証明書によって、正規のクライアントであることを認証してもよい。また、鍵管理サーバ３００が認証を行ってもよい。

記憶装置１５０は、０次企業が運用する記憶装置であり、１次企業から２次企業への発注情報が暗号化されたデータを格納する。また、記憶装置１５０は、暗号鍵ｐｋ１、ｐｋ２、ｓｋ１－ｓ１、ｓｋ２－ｓ１を格納する。ｐｋ１は、１次クライアント４００の公開鍵であり、ｐｋ２は、２次クライアント５００の公開鍵であり、ｓｋ１－ｓ１は、１次クライアント４００の秘密鍵のシェアであり、ｓｋ２－ｓ１は、２次クライアント５００の秘密鍵のシェアである。記憶装置１５０は、０次企業サーバ１００と別体に構成されても、０次企業サーバ１００と一体に（すなわち、０次企業サーバ１００内の補助記憶装置３に）構成されてもよい。

０次クライアント１８０は、０次企業が０次企業サーバ１００へアクセスするために使用する計算機であり、ｗｅｂブラウザ又は専用アプリケーションが動作している。

第三者サーバ２００は、金融機関などの第三者企業が運用する計算機であり、シェア送信部２１０、金額受信部２２０、及び認証部２３０（請求項の「認証部」に相当）を有する。シェア送信部２１０は、１次クライアント４００及び２次クライアント５００からの要求に従って、記憶装置２５０に格納された秘密鍵シェアを送信する。金額受信部２２０は、企業間で支払われる金額のデータを受信し、支払データを生成して、金融機関の勘定系システムに送信する。認証部２３０は、鍵管理サーバ３００に格納されたパスワード情報を参照して、第三者サーバ２００にアクセスする１次クライアント４００及び２次クライアント５００を認証する。

記憶装置２５０は、第三者企業が運用する記憶装置であり、暗号鍵シェアｓｋ１－ｓ２、ｓｋ１－ｓ２を格納する。ｓｋ１－ｓ２は、１次クライアント４００の秘密鍵のシェアであり、ｓｋ２－ｓ２は、２次クライアントの秘密鍵のシェアである。記憶装置２５０は、第三者サーバ２００と別体に構成されても、第三者サーバ２００と一体に（すなわち、第三者サーバ２００内の補助記憶装置に）構成されてもよい。

１次クライアント４００の秘密鍵ｓｋ１は、記憶装置１５０に格納されるｓｋ１－ｓ１と、記憶装置２５０に格納されるｓｋ１－ｓ２から復元して、生成できる。同様に、２次クライアント５００の秘密鍵ｓｋ２は、記憶装置１５０に格納されるｓｋ２－ｓ１と、記憶装置２５０に格納されるｓｋ２－ｓ２から復元して、生成できる。

記憶装置１５０と記憶装置２５０は、別個に設けられても、物理的に一つの記憶装置を論理的に分割して使用するものでもよい。

鍵管理サーバ３００は、０次企業以外の企業が運営する計算機であり、通信部３１０（請求項の「通信部」に相当）、アクセス権管理部３２０（請求項の「アクセス権管理部」に相当）、分割部３３０、鍵生成部３４０（請求項の「鍵生成部」に相当）、及び記憶部３５０（請求項の「第２記憶装置」に相当）を有する。通信部３１０は、他の装置との通信を制御する。アクセス権管理部３２０は、記憶部３５０に格納されたパスワード情報を参照して、鍵管理サーバ３００にアクセスする１次クライアント４００及び２次クライアント５００を認証する。分割部３３０（請求項の「分割部」に相当）は、鍵生成部３４０が生成した秘密鍵を分割して秘密鍵シェアを生成する。秘密鍵シェアは、（ｋ，ｎ）秘密分散法で生成するとよいが、電子割符のように何らかの形で暗号化の鍵を複数の断片に分割できれば、他の方法で生成してもよい。鍵生成部３４０は、１次クライアント４００又は２次クライアント５００からの要求に従って、秘密鍵と公開鍵を含む鍵ペアを生成する。記憶部３５０は、アクセス権管理部３２０が認証に用いるパスワード情報及びアクセス権情報を格納する。アクセス権情報の詳細は図３に示し、パスワード情報の詳細は図４に示す。

鍵管理サーバ３００の記憶部３５０は、秘密鍵シェアの全部または一部を格納してもよい。秘密鍵シェアを格納するグループに鍵管理サーバ３００を含めてもよい。

鍵管理サーバ３００は、０次企業、第三者企業のいずれでもない企業（鍵生成者）が運営する計算機としたが、鍵生成者は第三者企業が兼ねてもよい。鍵生成者が０次企業であると、０次企業が秘密鍵を知ることができ、不適切である。

実施例２で説明するように、秘密鍵及び公開鍵は、鍵管理サーバ３００でなく、１次クライアント４００及び２次クライアント５００で生成してもよい。

１次クライアント４００は、１次企業が０次企業サーバ１００及び第三者サーバ２００へアクセスするために使用する計算機であり、入力部４１０、情報受信部４２０、情報送信部４３０（請求項の「情報送信部」に相当）、表示部４４０（請求項の「表示部」に相当）、暗号復号部４５０（請求項の「暗号・複合部」に相当）、及び鍵復元・生成部４６０（請求項の「鍵復元・生成部」に相当）を有する。１次クライアント４００の各部は、ｗｅｂブラウザ又は専用アプリケーションで構成するとよい。入力部４１０は、ユーザからのデータ入力を受け付ける。情報受信部４２０は、他の装置から送信されるデータを受信する。情報送信部４３０は、他の装置へデータを送信する。表示部４４０は、演算処理の結果や他の装置から受信したデータをユーザに表示する。暗号復号部４５０は、暗号化されて転送されたデータを復号し、平文のデータを生成する。鍵復元・生成部４６０は、収集した鍵シェアから元の鍵を復元し、生成する。

２次クライアント５００は、２次企業が０次企業サーバ１００及び第三者サーバ２００へアクセスするために使用する計算機であり、入力部５１０、情報受信部５２０、情報送信部５３０（請求項の「情報送信部」に相当）、表示部５４０（請求項の「表示部」に相当）、暗号復号部５５０（請求項の「暗号・複合部」に相当）、及び鍵復元・生成部５６０（請求項の「鍵復元・生成部」に相当）を有する。２次クライアント５００の各部は、ｗｅｂブラウザ又は専用アプリケーションで構成するとよい。入力部５１０は、ユーザからのデータ入力を受け付ける。情報受信部５２０は、他の装置から送信されるデータを受信する。情報送信部５３０は、他の装置へデータを送信する。表示部５４０は、演算処理の結果や他の装置から受信したデータをユーザに表示する。暗号復号部５５０は、暗号化されて転送されたデータを復号し、平文のデータを生成する。鍵復元・生成部５６０は、収集した鍵シェアから元の鍵を復元し、生成する。

ここで、０次企業サーバ１００による第三者サーバ２００からの秘密鍵シェアの不正な入手や、第三者サーバ２００による０次企業サーバ１００からの秘密鍵シェアの不正な入手は、例えば０次企業サーバ１００、第三者サーバ２００のソースをＯＳＳにして公開することにより抑制できる。

図１８は、本実施例の０次企業サーバ１００の物理的な構成を示すブロック図である。

本実施例の０次企業サーバ１００は、プロセッサ（ＣＰＵ）１、メモリ２、補助記憶装置３及び通信インターフェース４を有する計算機によって構成される。０次企業サーバ１００は、入力インターフェース５及び出力インターフェース８を有してもよい。

プロセッサ１は、メモリ２に格納されたプログラムを実行する演算装置である。プロセッサ１が各種プログラムを実行することによって、０次企業サーバ１００の各機能部（例えば、メール通知部１１０、発注情報送受信部１２０、シェア・ｐｋ送信部１３０、認証部１４０など）による機能が実現される。なお、プロセッサ１がプログラムを実行して行う処理の一部を、他の演算装置（例えば、ＡＳＩＣ、ＦＰＧＡ等のハードウェア）で実行してもよい。なお、前述した０次企業サーバ１００の各機能部による機能を実現するプロセッサ１は、請求項における「第１演算装置」に相当する。

メモリ２は、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭを含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶素子であり、プロセッサ１が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。

補助記憶装置３は、例えば、磁気記憶装置（ＨＤＤ）、フラッシュメモリ（ＳＳＤ）等の大容量かつ不揮発性の記憶装置である。また、補助記憶装置３は、プロセッサ１がプログラムの実行時に使用するデータ、及びプロセッサ１が実行するプログラムを格納する。すなわち、プログラムは、補助記憶装置３から読み出されて、メモリ２にロードされて、プロセッサ１によって実行されることによって、０次企業サーバ１００の各機能を実現する。

通信インターフェース４は、所定のプロトコルに従って、他の装置との通信を制御するネットワークインターフェース装置である。

入力インターフェース５は、キーボード６やマウス７などの入力装置が接続され、オペレータからの入力を受けるインターフェースである。出力インターフェース８は、ディスプレイ装置９やプリンタ（図示省略）などの出力装置が接続され、プログラムの実行結果をユーザが視認可能な形式で出力するインターフェースである。なお、０次企業サーバ１００にネットワークを介して接続されたユーザ端末が入力装置及び出力装置を提供してもよい。この場合、０次企業サーバ１００がウェブサーバの機能を有し、ユーザ端末が０次企業サーバ１００に所定のプロトコル（例えばｈｔｔｐ）でアクセスしてもよい。

プロセッサ１が実行するプログラムは、リムーバブルメディア（ＣＤ－ＲＯＭ、フラッシュメモリなど）又はネットワークを介して０次企業サーバ１００に提供され、非一時的記憶媒体である不揮発性の補助記憶装置３に格納される。このため、０次企業サーバ１００は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。

０次企業サーバ１００は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。例えば、メール通知部１１０、発注情報送受信部１２０、シェア・ｐｋ送信部１３０、認証部１４０は、各々別個の物理的又は論理的計算機上で動作するものでも、複数が組み合わされて一つの物理的又は論理的計算機上で動作するものでもよい。

図１８を参照して０次企業サーバ１００の物理的な構成を説明したが、他のサーバ（第三者サーバ２００、鍵管理サーバ３００）も同じ構成でよい。さらに、０次クライアント１８０、１次クライアント４００及び２次クライアント５００も一般的な計算機で構成でき、図１８と同じ構成の計算機でよい。なお、第三者サーバ２００の物理的な構成の一つであるプロセッサ（ＣＰＵ）１（図１８参照）は、請求項の「第３演算装置」に相当し、鍵管理サーバ３００の物理的な構成の一つであるプロセッサ１は、請求項の「第２演算装置」に相当し、１次クライアント４００及び２次クライアント５００の物理的な構成の一つであるプロセッサ１は、請求項の「第４演算装置」に相当する。

図３は、本実施例のアクセス権情報の構成例を示す図である。

アクセス権情報は、秘密鍵シェアへのアクセス可否の判定に使用する情報であり、ユーザ名、ユーザＩＤ、及びＩＰアドレスが対応付けられて記録される。ユーザ名は、受発注システムを利用するユーザを一意に識別可能な名称であり、一部に企業名を含むように定義するとよい。ユーザＩＤは、ユーザを一意に識別可能な記号又は番号である。ＩＰアドレスは、当該ユーザが使用するクライアント４００、５００に付与されたアドレスである。

アクセス権情報は、０次企業サーバ１００および第三者サーバ２００で保持され、鍵管理サーバ３００で保持してもよい。

図４は、本実施例のパスワード情報の構成例を示す図である。

パスワード情報には、ユーザＩＤ、パスワード、及び鍵情報が対応付けられて記録される。ユーザＩＤは、受発注システムを利用するユーザを一意に識別可能な記号又は番号である。パスワードは、当該ユーザが入力し、認証に使用されるパスワードである。鍵情報は、当該ユーザＩＤ及びパスワードによって認証されるアクセス権が付与された秘密鍵の識別情報である。

パスワード情報は、鍵管理サーバ３００で保持される。

図５は、実施例１の鍵生成・配布処理のシーケンス図である。

１次クライアント４００の情報送信部４３０は、鍵管理サーバ３００に鍵生成を要求する（１００１）。

鍵管理サーバ３００が鍵生成要求を受信すると、鍵生成部３４０は秘密鍵ｓｋ１と公開鍵ｐｋ１のペアを生成する（１００２）。そして、鍵管理サーバ３００の通信部３１０は、１次クライアント４００にＩＤとパスワードを要求する（１００３）。

１次クライアント４００では、入力部４１０がＩＤとパスワードの入力を受けると（１００４）、情報送信部４３０がＩＤとパスワードを鍵管理サーバ３００に送信する（１００５）。

鍵管理サーバ３００がＩＤとパスワードを受信すると、分割部３３０が、生成された秘密鍵を分割して秘密鍵シェアｓｋ１－ｓ１、ｓｋ１－ｓ２を生成し（１００６）、アクセス権管理部３２０が、生成された秘密鍵シェアと受信したＩＤ及びパスワードのペアを関連付けることによって、生成された秘密鍵シェアに受信したＩＤとパスワードによるアクセス権情報を付与し（１００７）、当該ＩＤとパスワードを含むパスワード情報を記憶部３５０に格納する（１００８）。秘密鍵の分割数及び秘密鍵シェアの格納先は、０次企業が予め定めておくとよい。また、秘密鍵の分割数及び秘密鍵シェアの格納先は、企業毎に変えてもよい。そして、鍵管理サーバ３００の通信部３１０は、秘密鍵シェアｓｋ１－ｓ１と公開鍵ｐｋ１を０次企業サーバ１００に送信する（１００９）。

０次企業サーバ１００は、受信した秘密鍵シェアｓｋ１－ｓ１を記憶装置１５０に格納する（１０１０）。

また、鍵管理サーバ３００の通信部３１０は、他の秘密鍵シェア（ｓｋ１－ｓ２）を第三者サーバ２００に送信する（１０１１）。

第三者サーバ２００は、受信した秘密鍵シェアを記憶装置２５０に格納する（１０１２）。

さらに、鍵管理サーバ３００の通信部３１０は、クライアント証明書を０次企業サーバ１００に送信する（１０１３）。

本実施例において、暗号はＥＣＤＨ－ＡＥＳを使用するが、他の暗号方式（例えば、共通鍵方式、公開鍵方式、ハイブリッド方式）でもよい。例えば、公開鍵暗号方式を用いると、１次企業から２次企業への受発注情報は、１次企業が見るデータと２次企業が見るデータとは異なる公開鍵で暗号化した異なる暗号化データになる。一方、ハイブリッド暗号方式（例えばＥＣＤＨ－ＡＥＳ）や共通鍵暗号方式では、１次企業が見るデータと２次企業が見るデータとは同じ暗号化データになるので、共通鍵方式やハイブリッド方式の方が公開鍵暗号方式より、記憶装置１５０、２５０に格納するデータ量を少なくできる。

図６及び図７は、実施例１の１次企業から２次企業への発注処理のシーケンス図である。

０次企業のユーザは、０次企業から１次企業へ委託する業務の発注情報を０次クライアント入力し、０次企業サーバ１００へ送信する（１１０１）。

０次企業サーバ１００は、委託業務の発注情報を受信すると、メール通知部１１０が発注の電子メールを送信する（１１０２）。この電子メールは、図１１Ａに示すように、１次クライアント４００から０次企業サーバ１００にアクセスして、発注情報を確認するためのリンクの情報が含まれる。

１次企業のユーザの操作によって、１次クライアント４００の表示部４４０が受信した電子メールを表示すると、さらに１次企業のユーザは、１次クライアント４００を操作して、表示された電子メールに含まれるリンクを選択する。入力部４１０がリンクの選択を受け付けると、情報送信部４３０は、選択されたリンクにアクセスして、発注情報を０次企業サーバ１００に要求する（１１０３）。

０次企業サーバ１００が発注情報の要求を受信すると、発注情報送受信部１２０がログイン画面の表示データを１次クライアント４００に送信する（１１０４）。

１次クライアント４００の表示部４４０がログイン画面を表示すると、１次企業のユーザは、ＩＤとパスワードを入力する（１１０５）。入力部４１０がＩＤとパスワードを受け付けると、１次クライアント４００の情報送信部４３０は、入力されたＩＤとパスワードを０次企業サーバ１００に送信する（１１０６）。

０次企業サーバ１００の認証部１４０は、パスワード情報取得要求を鍵管理サーバ３００に送信する（１１０７）。

鍵管理サーバ３００がパスワード情報取得要求を受信すると、通信部３１０が０次企業サーバ１００にパスワード情報を送信する（１１０８）。

０次企業サーバ１００がパスワード情報を受信すると、受信したパスワード情報を用いて、認証部１４０が１次クライアント４００を認証する（１１０９）。そして、認証に成功すると、発注情報送受信部１２０が、１次クライアント４００へ発注情報を送信する（１１１０）。

１次企業のユーザの操作によって、１次クライアント４００の表示部４４０が受信した発注情報を表示する。発注情報表示画面は、図１２に示すように、２次企業への発注ボタンが設けられており、１次企業のユーザが発注ボタンを操作すると、図１３に示す発注画面が表示される。１次企業のユーザは、品名毎に発注先を選択し、金額を入力して、確定ボタンを操作すると、入力部４１０が発注先の２次企業及び金額を受け付ける（１１１１）。

その後、１次クライアント４００の情報送信部４３０は、ＩＤとＩＰアドレスとパスワードを送信して、２次クライアント５００の公開鍵ｐｋ２及び１次クライアント４００の秘密鍵シェアｓｋ１－ｓ１を０次企業サーバ１００へ要求する（１１１２）。

０次企業サーバ１００がＩＤとＩＰアドレスとパスワードを受信すると、認証部１４０が、受信したＩＤとＩＰアドレスとパスワードの双方が図３のＩＰアドレス及び図４のパスワードと一致することを以て１次クライアント４００を認証する（１１１３）。そして、認証に成功すると、シェア・ｐｋ送信部１３０が、２次クライアント５００の公開鍵ｐｋ２と１次クライアント４００の秘密鍵シェアｓｋ１－ｓ１を１次クライアント４００へ送信する（１１１４）。

また、１次クライアント４００の情報送信部４３０は、ＩＤとＩＰアドレスとパスワードを送信して、１次クライアント４００の秘密鍵シェアｓｋ１－ｓ２を第三者サーバ２００へ要求する（１１１５）。

第三者サーバ２００がＩＤとＩＰアドレスとパスワードを受信すると、認証部２３０が、鍵管理サーバ３００にパスワード情報の取得を要求する（１１１６）。

鍵管理サーバ３００がパスワード情報取得要求を受信すると、通信部３１０が第三者サーバ２００にパスワード情報を送信する（１１１７）。

第三者サーバ２００がパスワード情報を受信すると、受信したパスワード情報を用いて、認証部２３０が１次クライアント４００を認証する（１１１８）。そして、認証に成功すると、シェア送信部２１０が、１次クライアント４００の秘密鍵シェアｓｋ１－ｓ２を１次クライアント４００へ送信する（１１１９）。

１次クライアント４００が秘密鍵シェアｓｋ１－ｓ１、ｓｋ１－ｓ２を受信した後、鍵復元・生成部４６０は、二つの秘密鍵シェアｓｋ１－ｓ１、ｓｋ１－ｓ２から秘密鍵ｓｋ１を復元し（１１２０）、１次クライアント４００の秘密鍵ｓｋ１と２次クライアント５００の公開鍵ｐｋ２からＡＥＳ共通鍵を生成する（１１２１）。そして、暗号復号部４５０が、生成したＡＥＳ共通鍵を用いて２次企業への発注情報を暗号化する（１１２２）。そして、情報送信部４３０は、暗号化された２次企業への発注情報を０次企業サーバ１００へ送信する（１１２３）。

０次企業サーバ１００は、ＡＥＳ共通鍵を用いて暗号化された２次企業への発注情報を記憶装置１５０に格納する。

図８は、実施例１の２次企業が発注を確認する処理のシーケンス図である。

０次企業サーバ１００は、２次企業への発注情報を１次クライアント４００から受信すると、メール通知部１１０が発注の電子メールを送信する（１２０１）。この電子メールは、図１１Ｂに示すように、２次クライアント５００から０次企業サーバ１００にアクセスして、発注情報を確認するためのリンクの情報が含まれる。

２次企業のユーザの操作によって、２次クライアント５００の表示部５４０が受信した電子メールを表示すると、さらに２次企業のユーザは、２次クライアント５００を操作して、表示された電子メールに含まれるリンクを選択する。入力部５１０がリンクの選択を受け付けると、情報送信部５３０は、選択されたリンクにアクセスして、発注情報を０次企業サーバ１００に要求する（１２０２）。

０次企業サーバ１００が発注情報の要求を受信すると、発注情報送受信部１２０がログイン画面の表示データを２次クライアント５００に送信する（１２０３）。

２次クライアント５００の表示部５４０がログイン画面を表示すると、２次企業のユーザは、ＩＤとパスワードを入力する（１２０４）。入力部５１０がＩＤとパスワードを受け付けると、２次クライアント５００の情報送信部５３０は、入力されたＩＤとパスワードを０次企業サーバ１００に送信する（１２０５）。

０次企業サーバ１００の認証部１４０は、パスワード情報取得要求を鍵管理サーバ３００に送信する（１２０６）。

鍵管理サーバ３００がパスワード情報取得要求を受信すると、通信部３１０が０次企業サーバ１００にパスワード情報を送信する（１２０７）。

０次企業サーバ１００がパスワード情報を受信すると、受信したパスワード情報を用いて、認証部１４０が２次クライアント５００を認証する（１２０８）。そして、認証に成功すると、発注情報送受信部１２０が、２次クライアント５００へ発注情報と２次クライアント５００の秘密鍵シェアｓｋ２－ｓ１と１次クライアント４００の公開鍵ｐｋ１を送信する（１２０９）。

２次クライアント５００が秘密鍵シェアｓｋ２－ｓ１と公開鍵ｐｋ１を受信すると、２次クライアント５００の情報送信部５３０は、入力されたＩＤとパスワードを第三者サーバ２００に送信する（１２１０）。

第三者サーバ２００がＩＤとＩＰアドレスとパスワードを受信すると、認証部２３０が、鍵管理サーバ３００にパスワード情報の取得を要求する（１２１１）。

鍵管理サーバ３００がパスワード情報取得要求を受信すると、通信部３１０が第三者サーバ２００にパスワード情報を送信する（１２１２）。

第三者サーバ２００がパスワード情報を受信すると、受信したパスワード情報を用いて、認証部２３０が２次クライアント５００を認証する（１２１３）。そして、認証に成功すると、シェア送信部２１０が、２次クライアント５００の秘密鍵シェアｓｋ２－ｓ２を２次クライアント５００へ送信する（１２１４）。

２次クライアント５００が秘密鍵シェアｓｋ２－ｓ１、ｓｋ２－ｓ２を受信した後、鍵復元・生成部５６０は、二つの秘密鍵シェアｓｋ２－ｓ１、ｓｋ２－ｓ２から秘密鍵ｓｋ２を復元し（１２１５）、２次クライアント５００の秘密鍵ｓｋ２と１次クライアント４００の公開鍵ｐｋ１からＡＥＳ共通鍵を生成する（１２１６）。そして、暗号復号部５５０が、生成したＡＥＳ共通鍵を用いて２次企業への発注情報を復号化する（１２１７）。そして、２次企業のユーザの操作によって、２次クライアント５００の表示部５４０が受信した発注情報を表示する。発注情報表示画面は、図１４に示すように、承認ボタンが設けられており、１次企業のユーザが承認ボタンを操作すると、１次企業から２次企業へ委託される業務の受発注が確定する（１２１８）。なお、発注情報表示画面には、さらに業務を小分けして３次企業へ発注するために操作するボタンが設けられてもよい。そして、情報送信部５３０は、発注情報への承認を０次企業サーバ１００へ送信する（１２１９）。

図９及び図１０は、実施例１の配送完了通知から支払いまでの処理のシーケンス図である。

まず、２次企業のユーザは、０次企業サーバ１００にアクセスして業務完了を入力し、業務完了を通知する（１３０１）。

０次企業のユーザは、０次クライアント１８０から０次企業サーバ１００にアクセスして、業務完了通知を受信する（１３０２）。０次クライアント１８０には、図１５に示すような支払確認画面が表示され、承認ボタンの操作によって、１次企業へ委託した業務の完了が承認され、１次企業への支払が承認される（１３０３）。０次クライアント１８０の入力部が１次企業への支払承認を受け付けると、０次クライアント１８０から０次企業サーバ１００に１次企業への支払承認が送信される（１３０４）。

０次企業サーバ１００は、１次企業への支払承認を０次クライアント１８０から受信すると、メール通知部１１０が発注の電子メールを送信する（１３０５）。この電子メールは、図１１Ｃに示すように、１次クライアント４００から０次企業サーバ１００にアクセスして、２次企業への支払いを行うためのリンクの情報が含まれる。

１次企業のユーザの操作によって、１次クライアント４００の表示部４４０が受信した電子メールを表示すると、さらに１次企業のユーザは、１次クライアント４００を操作して、表示された電子メールに含まれるリンクを選択する。入力部４１０がリンクの選択を受け付けると、情報送信部４３０は、選択されたリンクにアクセスして、２次企業への発注情報を０次企業サーバ１００に要求する（１３０６）。

０次企業サーバ１００が発注情報の要求を受信すると、発注情報送受信部１２０がログイン画面の表示データを１次クライアント４００に送信する（１３０７）。

１次クライアント４００の表示部４４０がログイン画面を表示すると、１次企業のユーザは、ＩＤとパスワードを入力する（１３０８）。入力部４１０がＩＤとパスワードを受け付けると、１次クライアント４００の情報送信部４３０は、入力されたＩＤとパスワードを０次企業サーバ１００に送信する（１３０９）。

０次企業サーバ１００の認証部１４０は、パスワード情報取得要求を鍵管理サーバ３００に送信する（１３１０）。

鍵管理サーバ３００がパスワード情報取得要求を受信すると、通信部３１０が０次企業サーバ１００にパスワード情報を送信する（１３１１）。

０次企業サーバ１００がパスワード情報を受信すると、受信したパスワード情報を用いて、認証部１４０が１次クライアント４００を認証する（１３１２）。そして、認証に成功すると、発注情報送受信部１２０が２次企業への発注情報を送信し、シェア・ｐｋ送信部１３０が１次クライアント４００の秘密鍵シェアｓｋ１－ｓ１及び２次クライアント５００の公開鍵ｐｋ２を１次クライアント４００へ送信する（１３１３）。

その後、１次クライアント４００の情報送信部４３０は、ＩＤとＩＰアドレスとパスワードを送信して、１次クライアント４００の秘密鍵シェアｓｋ１－ｓ２を第三者サーバ２００へ要求する（１３１４）。

第三者サーバ２００がＩＤとパスワードを受信すると、認証部２３０が、鍵管理サーバ３００にパスワード情報の取得を要求する（１３１５）。

鍵管理サーバ３００がパスワード情報取得要求を受信すると、通信部３１０が第三者サーバ２００にパスワード情報を送信する（１３１６）。

第三者サーバ２００がパスワード情報を受信すると、受信したパスワード情報を用いて、認証部２３０が１次クライアント４００を認証する（１３１７）。そして、認証に成功すると、シェア送信部２１０が、１次クライアント４００の秘密鍵シェアｓｋ１－ｓ２を１次クライアント４００へ送信する（１３１８）。

１次クライアント４００が秘密鍵シェアｓｋ１－ｓ１、ｓｋ１－ｓ２を受信した後、鍵復元・生成部４６０は、二つの秘密鍵シェアｓｋ１－ｓ１、ｓｋ１－ｓ２から秘密鍵ｓｋ１を復元し（１３１９）、１次クライアント４００の秘密鍵ｓｋ１と２次クライアント５００の公開鍵ｐｋ２からＡＥＳ共通鍵を生成する（１３２０）。そして、暗号復号部４５０が、生成したＡＥＳ共通鍵を用いて２次企業への発注情報を復号する（１３２１）。そして、１次企業のユーザの操作によって、１次クライアント４００の表示部４４０が受信した発注情報を表示する。支払い確認画面は、図１５に示すように、承認ボタンが設けられており、１次企業のユーザが承認ボタンを操作すると、当該委託業務の完了が承認され、１次企業から２次企業への支払いが確定する（１３２２）。

そして、情報送信部４３０は、支払いの承認を０次企業サーバ１００へ通知し（１３２３）、当該委託業務の支払金額の情報を第三者サーバ２００へ送信する（１３２４）。

第三者サーバ２００は支払金額の情報を受信すると、１次企業から２次企業への振込データを作成し、１次企業から２次企業への支払いを実行する。

図１１Ａ～図１１Ｃは、０次企業サーバ１００から送信される電子メールの例を示す図である。

本実施例の受発注システムでは、電子メールなどの通知をトリガにして、当該通知に含まれるリンクによって、ユーザに次の作業を促している。図１１Ａは、０次企業から１次企業へ業務が発注される際に送信される電子メールの例であり、１次クライアント４００から０次企業サーバ１００にアクセスして、発注情報を確認するためのリンクの情報が含まれる。図１１Ｂは、１次企業から２次企業へ業務が発注される際に送信される電子メールの例であり、２次クライアント５００から０次企業サーバ１００にアクセスして、発注情報を確認するためのリンクの情報が含まれる。図１１Ｃは、２次企業の業務完了を契機に１次企業に送信される電子メールの例であり、１次クライアント４００から０次企業サーバ１００にアクセスして、発注情報及び支払情報を確認するためのリンクの情報が含まれる。

図１２は、発注情報表示画面の例を示す図である。

図１２に示す発注情報表示画面は、０次企業から１次企業へ業務が発注される際に送信される電子メール（図１１Ａ）に含まれるリンクによって、０次企業サーバ１００にアクセスして、ログイン後に表示される（図６のステップ１１１０、１１１１）。発注情報表示画面は、発注される業務の宛先（受注者）、発注元（発注者）、業務を表す情報（発注ＩＤ、発注日、受注日、発注金額）、及び業務内容（輸送する品名、数量、出発地、目的地）を表示する。受注者（例えば、１次企業）のユーザは、発注情報表示画面を見て、発注内容を知ることができる。

発注情報表示画面には、２次企業への発注ボタンが設けられており、１次企業のユーザが発注ボタンを操作すると、発注情報入力画面（図１３）が表示される。また、発注情報表示画面には、当該業務を受注しない場合に操作される「受注しない」ボタンが設けられる。

図１３は、発注情報入力画面の例を示す図である。

図１３に示す発注情報入力画面は、受注した業務の宛先（再委託する本人）、発注元（受注した業務の発注者）、業務を表す情報（発注ＩＤ、発注日、受注日、発注金額）、及び業務内容（輸送する品名、数量、出発地、目的地）を表示する。業務内容には、再委託先を入力する発注先欄と再委託の対価額を入力する金額欄が設けられている。再委託先である発注先は、プルダウンで選択可能とするとよい。再委託する受注者（例えば、１次企業）のユーザは、発注情報入力画面を見て、業務（輸送）毎に再委託先及び委託金額を決定し、発注情報入力画面に入力する。１次企業のユーザが確定ボタンを操作すると、１次クライアント４００が発注先の２次企業及び金額を受け付ける。

１次クライアント４００が受け付けた２次企業への発注情報は、１次クライアント４００の秘密鍵ｓｋ１と２次クライアント５００の公開鍵ｐｋ２から生成されたＡＥＳ共通鍵を用いて暗号化され、０次企業サーバ１００へ送信される（図６のステップ１１２０、１１２１）。

図１４は、発注情報表示画面の例を示す図である。

図１４に示す発注情報表示画面は、１次企業から２次企業へ業務が発注される際に送信される電子メール（図１１Ｂ）に含まれるリンクによって、０次企業サーバ１００にアクセスして、ログイン後に表示される（図８のステップ１２１８）。発注情報表示画面は、発注される業務の宛先（受注者）、発注元（発注者）、業務を表す情報（発注ＩＤ、発注日、受注日、発注金額）、及び業務内容（輸送する品名、数量、出発地、目的地）を表示する。受注者（例えば、２次企業）のユーザは、発注情報表示画面を見て、発注内容を知ることができる。

発注情報表示画面には、当該業務を受注しない場合に操作される「受注しない」ボタンと、当該業務を受注する場合に操作される「承認」ボタンが設けられる。２次企業のユーザが承認ボタンを操作すると、承認通知が０次企業サーバ１００へ送信される（図８のステップ１２１９）。

図１５は、支払い確認画面の例を示す図である。

図１５に示す支払い確認画面は、２次企業の業務完了時に送信される業務完了通知（図９のステップ１３０２）を契機として表示される（図１０のステップ１３２２）。支払い確認画面は、対価の支払先（委託業務の受注者）、業務を表す情報（発注ＩＤ、発注日、業務完了日時、発注金額）、及び業務内容（輸送する品名、数量、出発地、目的地）を表示する。業務委託者（例えば、１次企業）のユーザは、支払い確認画面を見て、支払い内容を確認する。

支払い確認画面には、２次企業からの請求書を（例えばｐｄｆ形式で）表示するための「請求書表示」ボタンと、当該支払いを承認する場合に操作される「承認」ボタンが設けられる。１次企業のユーザが承認ボタンを操作すると、支払いの承認を０次企業サーバ１００へ通知し（図１０のステップ１３２３）、支払金額の情報を第三者サーバ２００へ送信する（図１０のステップ１３２４）。

以上に説明したように、本発明の実施例１によると、複数の企業間で発注及び受注からなる業務委託が段階的に行われる商取引において、企業間の受発注情報を秘匿化できる。特に、秘匿性が高い委託金額を他の段階の企業に秘匿化できる。

＜実施例２＞
次に、本発明の実施例２について説明する。実施例２では、鍵管理サーバ３００ではなくクライアント４００、５００が鍵ペアを生成し、秘密鍵シェアを生成する。なお、実施例２において、実施例１との相違点を主に説明し、実施例１と同じ構成及び処理には同じ符号を付し、それらの説明は省略する。

図１６は、本発明の実施例２の受発注システムの構成を示す図である。

実施例２の受発注システムは、０次企業サーバ１００、０次企業の記憶装置１５０、第三者サーバ２００、第三者企業の記憶装置２５０、鍵管理サーバ３００、０次クライアント１８０、１次クライアント４００、及び２次クライアント５００を有する。０次企業サーバ１００、第三者サーバ２００、鍵管理サーバ３００、０次クライアント１８０、１次クライアント４００、及び２次クライアント５００はネットワークを介して接続される。なお、受発注の階層構造は２次企業以外に３次企業や４次企業を含む多段階の階層構造でもよいが、０次企業から２次企業までの２階層の受発注構造で説明する。

０次企業サーバ１００は、０次企業が運用する計算機であり、その構成は実施例１と同じである。記憶装置１５０は、０次企業が運用する記憶装置であり、その構成は実施例１と同じである。

０次クライアント１８０は、０次企業が０次企業サーバ１００へアクセスするために使用する計算機であり、ｗｅｂブラウザ又は専用アプリケーションが動作している。

第三者サーバ２００は、金融機関などの第三者企業が運用する計算機であり、その構成は実施例１と同じである。記憶装置２５０は、第三者企業が運用する記憶装置であり、その構成は実施例１と同じである。

鍵管理サーバ３００は、０次企業以外の企業が運営する計算機であり、通信部３１０、アクセス権管理部３２０、及び記憶部３５０を有する。通信部３１０は、他の装置との通信を制御する。アクセス権管理部３２０は、記憶部３５０に格納されたパスワード情報を参照して、鍵管理サーバ３００にアクセスする１次クライアント４００及び２次クライアント５００を認証する。記憶部３５０は、アクセス権管理部３２０が認証に用いるパスワード情報及びアクセス権情報を格納する。

１次クライアント４００は、１次企業が０次企業サーバ１００及び第三者サーバ２００へアクセスするために使用する計算機であり、入力部４１０、情報受信部４２０、情報送信部４３０、表示部４４０、暗号復号部４５０、鍵復元・生成部４６０、鍵生成部４７０（請求項の「鍵生成部」に相当）、及び分割部４８０（請求項の「分割部」に相当）を有する。１次クライアント４００の各部は、ｗｅｂブラウザ又は専用アプリケーションで構成するとよい。専用アプリケーションは、０次企業サーバ１００による鍵の取得を防止するため、０次企業サーバ１００ではなく、第三者サーバ２００から配布するとよい。入力部４１０は、ユーザからのデータ入力を受け付ける。情報受信部４２０は、他の装置から送信されるデータを受信する。情報送信部４３０は、他の装置へデータを送信する。表示部４４０は、演算処理の結果や他の装置から受信したデータをユーザに表示する。暗号復号部４５０は、暗号化されて転送されたデータを復号し、平文のデータを生成する。鍵復元・生成部４６０は、収集した鍵シェアから元の鍵を復元し、生成する。鍵生成部４７０は、１次クライアント用の秘密鍵と公開鍵を含む鍵ペアを生成する。分割部４８０は、鍵生成部４７０が生成した秘密鍵を分割して秘密鍵シェアを生成する。秘密鍵シェアは、（ｋ，ｎ）秘密分散法で生成するとよいが、電子割符のように何らかの形で暗号化の鍵を複数の断片に分割できれば、他の方法で生成してもよい。

２次クライアント５００は、２次企業が０次企業サーバ１００及び第三者サーバ２００へアクセスするために使用する計算機であり、入力部５１０、情報受信部５２０、情報送信部５３０、表示部５４０、暗号復号部５５０、鍵復元・生成部５６０、鍵生成部５７０（請求項の「鍵生成部」に相当）、及び分割部５８０（請求項の「分割部」に相当）を有する。２次クライアント５００の各部は、ｗｅｂブラウザ又は専用アプリケーションで構成するとよい。専用アプリケーションは、０次企業サーバ１００による鍵の取得を防止するため、０次企業サーバ１００ではなく、第三者サーバ２００から配布するとよい。入力部５１０は、ユーザからのデータ入力を受け付ける。情報受信部５２０は、他の装置から送信されるデータを受信する。情報送信部５３０は、他の装置へデータを送信する。表示部５４０は、演算処理の結果や他の装置から受信したデータをユーザに表示する。暗号復号部５５０は、暗号化されて転送されたデータを復号し、平文のデータを生成する。鍵復元・生成部５６０は、収集した鍵シェアから元の鍵を復元し、生成する。鍵生成部５７０は、１次クライアント用の秘密鍵と公開鍵を含む鍵ペアを生成する。分割部５８０は、鍵生成部５７０が生成した秘密鍵を分割して秘密鍵シェアを生成する。秘密鍵シェアは、（ｋ，ｎ）秘密分散法で生成するとよいが、電子割符のように何らかの形で暗号化の鍵を複数の断片に分割できれば、他の方法で生成してもよい。

図１７は、実施例２の鍵生成・配布処理のシーケンス図である。

受発注システムが起動すると、鍵管理サーバ３００の通信部３１０は、１次クライアント４００及び２次クライアント５００にＩＤとパスワードを要求する（１４０１、１４０２）。

１次クライアント４００では、入力部４１０がＩＤとパスワードの入力を受けると（１４０３）、鍵生成部４７０が１次クライアント用の秘密鍵ｓｋ１と公開鍵ｐｋ１を含む鍵ペアを生成し、分割部４８０が生成された秘密鍵を分割して秘密鍵シェアｓｋ１－ｓ１、ｓｋ１－ｓ２を生成し（１４０４）、情報送信部４３０がＩＤとパスワードと鍵ペアと秘密鍵シェアを鍵管理サーバ３００に送信する（１４０５）。

また、２次クライアント５００では、入力部５１０がＩＤとパスワードの入力を受けると（１４０６）、鍵生成部５７０が２次クライアント用の秘密鍵ｓｋ２と公開鍵ｐｋ２を含む鍵ペアを生成し、分割部５８０が生成された秘密鍵を分割して秘密鍵シェアｓｋ２－ｓ１、ｓｋ２－ｓ２を生成し（１４０７）、情報送信部５３０がＩＤとパスワードと鍵ペアと秘密鍵シェアを鍵管理サーバ３００に送信する（１４０８）。

鍵管理サーバ３００は、１次クライアント４００又は２次クライアント５００からＩＤとパスワードと鍵ペアと秘密鍵シェアを受信すると、アクセス権管理部３２０が、受信したＩＤとパスワードを用いて、秘密鍵シェアにアクセス権を付与し、アクセス権情報を記憶部３５０に保存する（１４０９）。

その後、鍵管理サーバ３００の通信部３１０は、公開鍵ｐｋ１、ｐｋ２と秘密鍵シェアｓｋ１－ｓ１、ｓｋ２－ｓ１とアクセス権情報を０次企業サーバ１００に送信する（１４１０）。０次企業サーバ１００は、受信した公開鍵と秘密鍵シェアとアクセス権情報を記憶装置１５０に保存する（１４１１）。

また、通信部３１０は、他の秘密鍵シェアｓｋ１－ｓ２、ｓｋ２－ｓ２とアクセス権情報を第三者サーバ２００に送信する（１４１２）。第三者サーバ２００は、受信した秘密鍵シェアとアクセス権情報を記憶装置２５０に保存する（１４１３）。

秘密鍵の分割数及び秘密鍵シェアの格納先は、０次企業が予め定めておくとよい。また、秘密鍵の分割数及び秘密鍵シェアの格納先は、１次企業や２次企業毎に変えてもよい。

秘密鍵シェアが０次企業サーバ１００及び第三者サーバ２００に格納された後の処理は、前述した実施例１と同じである。

以上に説明したように、本発明の実施例２では、鍵管理サーバ３００でなくクライアント４００、５００が鍵ペアを生成し、秘密鍵シェアを生成するので、鍵管理サーバで鍵を生成する機能を保持する必要がなくなり、鍵管理サーバはアクセス権情報、パスワード情報の管理のみを行えば良くなる。また、クライアント４００、５００が、秘密鍵シェアへのアクセス権情報を付与し、パスワード情報と共に０次企業サーバ１００及び第三者サーバ２００に送信する。

＜実施例３＞
次に、本発明の実施例３について説明する。実施例３では、秘密分散の閾値ｋを３以上とする。すなわち、第三者企業を２社以上とし、０次企業を含めた３社以上で秘密鍵シェアを保持する。なお、実施例３において、実施例１との相違点を主に説明し、実施例１と同じ構成及び処理には同じ符号を付し、それらの説明は省略する。本実施例では鍵シェアを複数の企業に分散して管理すればよく、鍵シェアの保持者は０次企業と金融機関でなくてもよい。例えば、システム提供会社や認証機関や公的機関が鍵シェアを保持してもよい。

本発明の実施例３によると、０次企業や第三者企業は各社のサーバで管理されている一つの秘密鍵シェアを不正に取得し、二つ目の秘密鍵シェアを他社から不正に取得しても、さらに１社以上から秘密シェアを取得しないと暗号鍵を復元できないため、０次企業や第三者企業による発注情報の閲覧抑止効果が高くなる。また、攻撃者も三つ以上の秘密鍵シェアを入手しないと、暗号鍵を復元できないため、攻撃者への発注情報の流出を抑止する効果が高くなる。

＜実施例４＞
次に、本発明の実施例４について説明する。実施例４では、発注情報に電子署名を付与して、発注情報の改ざんを防止する。なお、実施例４において、実施例１との相違点を主に説明し、実施例１と同じ構成及び処理には同じ符号を付し、それらの説明は省略する。

実施例４では、発注情報に電子署名を付与して、２次企業が配送完了後に１次企業に支払い金額を請求する際の請求金額の改ざんを防止する。例えば、図８のステップ１２１６で２次クライアント５００から０次企業サーバ１００へ送信される発注情報への承認に、電子署名（例えば、発注情報のハッシュ値）を付与して、電子署名を０次企業サーバ１００へ送信する。図１０のステップ１３１９において、委託業務の完了を承認する際に、１次クライアント４００は発注情報から取得した電子署名と２次クライアント５００が承認した際の電子署名が一致することを確認する。これが一致する場合に承認可能とし、不一致の場合に承認不可能とする。これにより、２次企業が１次企業に支払い承認時の請求金額の改ざんを防止する。

＜実施例５＞
次に、本発明の実施例５について説明する。実施例５では、サーバ間でシングルサインオンを実現する。なお、実施例５において、実施例１との相違点を主に説明し、実施例１と同じ構成及び処理には同じ符号を付し、それらの説明は省略する。

実施例５において、０次企業サーバ１００、第三者サーバ２００間でシングルサインオンを実施する。具体的には、例えば既存の代行認証方式を用いるものとし、実施例１に記載の１次クライアント４００、２次クライアント５００の各々に専用エージェントを保持し、１度鍵管理サーバによる認証が通れば、以降の認証時には専用エージェントにてＩＤ、パスワード、ＩＰアドレスを自動入力する。これにより、１次クライアント４００、２次クライアント５００が０次企業サーバ１００、第三者サーバ２００に秘密鍵シェアの取得を要求する都度のパスワード入力が不要となり、ユーザのパスワード入力回数を削減できる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

１００ ０次企業サーバ
１１０ メール通知部
１２０ 発注情報送受信部
１３０ シェア・ｐｋ送信部
１４０ 認証部
１５０ 記憶装置
１８０ ０次クライアント
２００ 第三者サーバ
２１０ シェア送信部
２２０ 金額受信部
２３０ 認証部
２５０ 記憶装置
３００ 鍵管理サーバ
３１０ 通信部
３２０ アクセス権管理部
３３０ 分割部
３４０ 鍵生成部
３５０ 記憶部
４００ １次クライアント
４１０ 入力部
４２０ 情報受信部
４３０ 情報送信部
４４０ 表示部
４５０ 暗号復号部
４６０ 鍵復元・生成部
４７０ 鍵生成部
４８０ 分割部
５００ ２次クライアント
５１０ 入力部
５２０ 情報受信部
５３０ 情報送信部
５４０ 表示部
５５０ 暗号復号部
５６０ 鍵復元・生成部
５７０ 鍵生成部
５８０ 分割部

Claims (8)

1. 複数の企業間で発注及び受注からなる業務委託が段階的に行われる商取引における業務の受発注を管理する受発注システムであって、
   プログラムを実行する第１演算装置と前記演算装置がアクセス可能な第１記憶装置とを有し、発注情報及び受注情報を管理する０次サーバと、
   プログラムを実行する第２演算装置と前記演算装置がアクセス可能な第２記憶装置とを有し、前記発注情報及び前記受注情報を暗号化するための暗号鍵を管理する鍵管理サーバと、
   プログラムを実行する第３演算装置と前記演算装置がアクセス可能な第３記憶装置とを有し、前記鍵から生成された複数の鍵シェアの一部を各々保持する複数の鍵シェア保持サーバと、
   プログラムを実行する第４演算装置と前記演算装置がアクセス可能な第４記憶装置とを有し、前記発注情報及び前記受注情報が入出力される端末と、を備え、
   前記鍵管理サーバは、
   前記第２演算装置が、前記鍵シェアを取得可能な企業の認証情報を当該鍵シェアに付与するアクセス権管理部と、
   前記第２演算装置が、前記鍵シェアを前記鍵シェア保持サーバに配布する通信部とを有し、
   前記端末は、
   前記第４演算装置が、前記鍵シェアを前記鍵シェア保持サーバに要求する情報送信部と、
   前記第４演算装置が、取得した複数の前記鍵シェアから暗号鍵を復元する鍵復元・生成部と、
   前記第４演算装置が、前記復元された暗号鍵を用いて、入力された発注情報を暗号化し、受注情報を復号化する暗号・復号部と、
   前記第４演算装置が、前記復号化された受注情報を表示する表示部とを有し、
   前記情報送信部は、前記暗号化された発注情報を前記０次サーバに送信し、
   前記鍵シェア保持サーバは、前記第３演算装置が、前記認証情報に基づいて、各端末への前記鍵シェアの送信可否を判定する認証部を有することを特徴とする受発注システム。
2. 請求項１に記載の受発注システムであって、
   前記情報送信部は、前記０次サーバからの通知を受信後、前記鍵シェア保持サーバに前記認証情報を送信して、前記鍵シェアを要求し、
   前記鍵復元・生成部は、複数の前記鍵シェア保持サーバから取得した前記鍵シェアから暗号鍵を復元し、
   前記暗号・復号部は、前記０次サーバから受信した受注情報を、前記復元された暗号鍵を用いて復号化し、
   前記表示部は、前記復号化された受注情報を表示することを特徴とする受発注システム。
3. 請求項１に記載の受発注システムであって、
   前記情報送信部は、委託業務の完了を契機に、前記完了した委託業務にかかる発注情報を前記０次サーバから取得し、前記鍵シェア保持サーバに前記認証情報を送信して、前記鍵シェアを要求し、
   前記鍵復元・生成部は、複数の前記鍵シェア保持サーバから取得した前記鍵シェアから暗号鍵を復元し、
   前記暗号・復号部は、前記復元された暗号鍵を用いて、前記０次サーバから受信した発注情報を復号化し、
   前記表示部は、前記復号化された発注情報を表示して、当該委託業務の完了の承認を促すことを特徴とする受発注システム。
4. 請求項１に記載の受発注システムであって、
   前記端末は、
   前記鍵シェアを前記鍵シェア保持サーバに要求し、
   前記鍵シェア保持サーバの各々から前記０次サーバを経由せずに前記鍵シェアを取得することを特徴とする受発注システム。
5. 請求項１に記載の受発注システムであって、
   前記鍵管理サーバは、
   前記第２演算装置が、前記暗号鍵を生成する鍵生成部と、
   前記第２演算装置が、前記暗号鍵から複数の前記鍵シェアを生成する分割部とを有することを特徴とする受発注システム。
6. 請求項１に記載の受発注システムであって、
   前記端末は、
   前記第４演算装置が、前記暗号鍵を生成する鍵生成部と、
   前記第４演算装置が、前記暗号鍵から複数の前記鍵シェアを生成する分割部とを有することを特徴とする受発注システム。
7. 請求項５又は６に記載の受発注システムであって、
   前記分割部は（ｋ，ｎ）閾値秘密分散法を用いて、前記鍵シェアを生成し、
   前記通信部は、前記鍵シェア保持サーバの各々に（ｋ－１）個以下の前記鍵シェアを配布することを特徴とする受発注システム。
8. 複数の企業間で発注及び受注からなる業務委託が段階的に行われる商取引において、受発注システムが業務の受発注を管理する受発注管理方法であって、
   前記受発注システムは、プログラムを実行する第１演算装置と前記演算装置がアクセス可能な第１記憶装置とを有し、発注情報及び受注情報を管理する０次サーバと、プログラムを実行する第２演算装置と前記演算装置がアクセス可能な第２記憶装置とを有し、前記発注情報及び前記受注情報を暗号化するための暗号鍵を管理する鍵管理サーバと、プログラムを実行する第３演算装置と前記演算装置がアクセス可能な第３記憶装置とを有し、前記鍵から生成された複数の鍵シェアの一部を各々保持する複数の鍵シェア保持サーバと、プログラムを実行する第４演算装置と前記演算装置がアクセス可能な第４記憶装置とを有し、前記発注情報及び前記受注情報が入出力される端末と、を有し、
   前記受発注管理方法は、
   前記第２演算装置が、前記鍵シェアを取得可能な企業の認証情報を当該鍵シェアに付与し、
   前記第２演算装置が、前記鍵シェアを前記鍵シェア保持サーバに配布し、
   前記第４演算装置が、前記鍵シェアを前記鍵シェア保持サーバに要求し、
   前記第３演算装置が、前記認証情報に基づいて、各端末への前記鍵シェアの送信可否を判定し、
   前記第４演算装置が、取得した複数の前記鍵シェアから暗号鍵を復元し、
   前記第４演算装置が、前記復元された暗号鍵を用いて、発注情報を暗号化し、
   前記第４演算装置が、前記暗号化された発注情報を前記０次サーバに送信し、
   前記第４演算装置が、前記０次サーバから受信した受注情報を、前記復元された暗号鍵を用いて復号化し、
   前記第４演算装置が、前記復号化された受注情報を表示することを特徴とする受発注管理方法。

Images