特開 2023-32864 業務実績管理システム、及び業務実績管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023032864

(43)【公開日】2023-03-09

(54)【発明の名称】業務実績管理システム、及び業務実績管理方法

(51)【国際特許分類】

   G06Q 10/00 20230101AFI20230302BHJP

【ＦＩ】

G06Q10/00

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2021139211

(22)【出願日】2021-08-27

(71)【出願人】

【識別番号】000153546

【氏名又は名称】株式会社日立物流

(74)【代理人】

【識別番号】110001678

【氏名又は名称】藤央弁理士法人

(72)【発明者】

【氏名】下村 真帆

(72)【発明者】

【氏名】小坂 忠義

(72)【発明者】

【氏名】古家 直樹

(72)【発明者】

【氏名】長谷川 学

(72)【発明者】

【氏名】鴨志田 亮太

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA20

(57)【要約】

【課題】端末により受注企業のサーバの宛先を取得する。
【解決手段】業務実績管理システムであって、複数の企業の各々のサーバと、少なくとも委託元企業のサーバとネットワークを介して接続される端末とを備え、サーバは、取得した識別情報が付された発注情報が第１記憶部に記憶されているかを判定し、取得した識別情報が付された発注情報が第１記憶部に記憶されている場合、当該発注情報の受注企業のサーバのネットワーク上のアドレス情報を取得することによって、受注企業のサーバを段階的に探し、取得した識別情報が付された発注情報が第１記憶部に記憶されていない場合、最終受注企業であることを示す情報を端末に送信し、端末は、最終受注企業であることを示す情報の送信元のサーバのネットワーク上のアドレス情報を、最終受注企業のサーバのネットワーク上のアドレス情報として特定する。
【選択図】図２

【特許請求の範囲】

【請求項1】

複数の企業間で発注及び受注からなる業務委託が段階的に行われる商取引において、業務を請け負う受注企業のサーバを探索する業務実績管理システムであって、
前記複数の企業の各々のサーバと、
少なくとも委託元企業のサーバとネットワークを介して接続される端末とを備え、
前記サーバの各々は、所定の処理を実行する第１演算装置と、前記第１演算装置に接続された第１記憶部とを有し、
前記端末は、所定の処理を実行する第２演算装置と、前記第２演算装置に接続された第２記憶部とを有し、
前記サーバは、
取得した識別情報が付された発注情報が前記第１記憶部に記憶されているかを判定し、
前記取得した識別情報が付された発注情報が前記第１記憶部に記憶されている場合、当該発注情報の受注企業のサーバのネットワーク上のアドレス情報を取得することによって、前記受注企業のサーバを段階的に探し、
前記取得した識別情報が付された発注情報が前記第１記憶部に記憶されていない場合、最終受注企業であることを示す情報を前記端末に送信し、
前記端末は、前記最終受注企業であることを示す情報の送信元のサーバのネットワーク上のアドレス情報を、前記最終受注企業のサーバのネットワーク上のアドレス情報として特定することを特徴とする業務実績管理システム。

【請求項2】

請求項１に記載の業務実績管理システムであって、
前記識別情報は、前記業務委託のフローにおける複数の企業間の受注及び発注に共通の案件ＩＤであって、
前記端末は、前記発注情報に付される案件ＩＤを前記サーバに送信し、
前記サーバは、
取得した前記案件ＩＤが付された発注情報が前記第１記憶部に記憶されている場合、当該発注情報の受注企業のサーバのネットワーク上のアドレス情報を取得し、
前記案件ＩＤ及び前記受注企業のサーバのネットワーク上のアドレス情報を前記端末に送信し、
前記端末は、前記サーバから受信した受注企業のサーバのネットワーク上のアドレス情報に従って、前記発注情報に付される案件ＩＤを前記受注企業のサーバに送信することを特徴とする業務実績管理システム。

【請求項3】

請求項１に記載の業務実績管理システムであって、
前記端末は、前記発注情報に付される識別情報を前記委託元企業の前記サーバに送信し、
前記サーバは、
前記取得した識別情報が付された発注情報が前記第１記憶部に記憶されている場合、当該発注情報の受注企業のサーバのネットワーク上のアドレス情報を取得し、前記受注企業のサーバのネットワーク上のアドレス情報に従って前記受注企業のサーバに前記識別情報を送信し、
前記取得した識別情報が付された発注情報が前記第１記憶部に記憶されていない場合、最終受注企業であることを示す情報及び前記最終受注企業のサーバのネットワーク上のアドレス情報を前記端末に送信することを特徴とする業務実績管理システム。

【請求項4】

請求項２に記載の業務実績管理システムであって、
前記端末は、発注情報のハッシュ値を記憶する第２記憶部を有し、
前記サーバは、前記取得した識別情報が付された発注情報を示すデータ及び受注情報を示すデータの少なくとも一方を前記端末に送信し、
前記端末は、
前記取得した前記発注情報を示すデータ及び前記受注情報を示すデータを前記第２記憶部に記憶し、
同じ識別情報に関連付けられる発注情報を示すデータと受注情報を示すデータとを比較し、
前記比較の結果、二つのデータが同じであると判定されると、受注企業のサーバに前記識別情報を送信することを特徴とする業務実績管理システム。

【請求項5】

請求項３に記載の業務実績管理システムであって、
前記サーバは、
前記取得した識別情報及び当該識別情報の発注情報を示すデータを受注企業のサーバに送信し、
同じ識別情報が付された受注情報を示すデータと、他の前記サーバから取得した発注情報を示すデータとを比較し、
前記比較の結果、二つのデータが同じであると判定されると、受注企業のサーバに前記識別情報を送信することを特徴とする業務実績管理システム。

【請求項6】

請求項４に記載の業務実績管理システムであって、
前記サーバが、耐改ざん性を持つ第３記憶部にアクセス可能であり、
前記サーバは、
前記識別情報と関連付けて発注情報を前記第３記憶部に送信し、
他の前記サーバから取得した発注情報を示すデータと前記第３記憶部から取得した発注情報を示すデータとを比較することを特徴とする業務実績管理システム。

【請求項7】

請求項１に記載の業務実績管理システムであって、
前記端末は、
前記識別情報及び当該識別情報が付された発注情報について特定された最終受注企業のサーバのネットワーク上のアドレス情報を特定し、
前記識別情報及び当該識別情報が付された発注情報にかかる業務実績を、前記アドレス情報が特定された最終受注企業のサーバに送信することを特徴とする業務実績管理システム。

【請求項8】

請求項１に記載の業務実績管理システムであって、
前記端末は、
前記アドレス情報が特定されたサーバに、前記識別情報と暗号化された業務実績を送信し、
前記業務実績を復号するための鍵を前記アドレス情報が特定された最終受注企業のサーバに送信し、
前記サーバは、取得した鍵を用いて前記業務実績を復号することを特徴とする業務実績管理システム。

【請求項9】

請求項７に記載の業務実績管理システムであって、
前記サーバは、取得した業務実績に基づいて、受注企業への支払データを生成することを特徴とする業務実績管理システム。

【請求項10】

複数の企業間で発注及び受注からなる業務委託が段階的に行われる商取引において、受注企業のサーバを探索する業務実績管理システムが実行する業務実績管理方法であって、
前記業務実績管理システムは、前記複数の企業の各々のサーバと、少なくとも委託元企業のサーバとネットワークを介して接続される端末とを有し、
前記サーバの各々は、所定の処理を実行する第１演算装置と、前記第１演算装置に接続された第１記憶部とを有し、
前記端末は、所定の処理を実行する第２演算装置と、前記第２演算装置に接続された第２記憶部とを有し、
前記業務実績管理方法は、
前記サーバの第１演算装置が、取得した識別情報が付された発注情報が前記第１記憶部に記憶されているかを判定し、
前記サーバの第１演算装置が、前記取得した識別情報が付された発注情報が前記第１記憶部に記憶されている場合、当該発注情報の受注企業のサーバのネットワーク上のアドレス情報を取得して、受注企業のサーバを段階的に探し、
前記サーバの第１演算装置が、前記取得した識別情報が付された発注情報が前記第１記憶部に記憶されていない場合、最終受注企業であることを示す情報を前記端末に送信し、
前記端末の第２演算装置が、前記最終受注企業であることを示す情報の送信元のサーバのネットワーク上のアドレス情報を、前記最終受注企業のサーバのネットワーク上のアドレス情報として特定することを特徴とする業務実績管理方法。

【請求項11】

請求項１０に記載の業務実績管理方法であって、
前記識別情報は、前記業務委託のフローにおける複数の企業間の受注及び発注に共通の案件ＩＤであって、
前記業務実績管理方法は、
前記端末の第２演算装置が、前記発注情報に付される案件ＩＤを前記サーバに送信し、
前記サーバの第１演算装置が、取得した前記案件ＩＤが付された発注情報が前記第１記憶部に記憶されている場合、当該発注情報の受注企業のサーバのネットワーク上のアドレス情報を取得して、前記端末に送信し、
前記サーバの第１演算装置が、前記取得した案件ＩＤ及び前記受注企業のサーバのネットワーク上のアドレス情報を前記端末に送信し、
前記端末が、前記サーバから受信した受注企業のサーバのネットワーク上のアドレス情報に従って、前記発注情報に付される案件ＩＤを前記サーバに送信することを特徴とする業務実績管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一の業者が請け負った業務を、委託、再委託のように連なって業務委託が行われる場合の実績管理に適した、業務実績管理システムに関する。

【背景技術】

【0002】

物流業界や建設業界では、繁忙期の需要に応えつつ効率的な経営を維持するために、顧客から受注した業務の全部又は一部を他の企業に委託することが多い。また、委託元企業から仕事を受注した委託先の企業が、さらに別の企業に作業を委託することもあり、複数の企業間で受発注処理が発生する委託構造が成り立っている。このように、一つの業務に対して繰り返し委託、再委託、再々委託が行われ、チェーン状又はフロー状に業務が委託された場合、最終的に仕事を請け負った委託先企業がその作業を完了させることになる。

【0003】

物流業界や建設業界では、作業効率化のため、業務を遂行する作業者（最終作業者）の作業状況や商品の納品状況をリアルタイムに把握することが求められる。例えば、物流業界では、商品の配送を担当するドライバが最終作業者となり、ドライバによる商品の納品実績を、受注企業からのフロー（受発注）に参加した企業間で共有することが求められる。

【0004】

現状、物流業界では、納品先の担当者がサインした受領書を、最終業務を担当した受注企業を始点に、当該受注企業からその発注企業へと順次送付することにより、納品実績を共有している。しかし、複数の企業間で受領書を送付するのは時間がかかるため、電子化した納品実績を迅速に共有できる仕組みが必要である。

【0005】

複数の企業が多段に連結するサプライチェーンを推定する技術として、特開２０１１―００８３０９号公報（特許文献１）に記載の技術がある。特許文献１によれば、評価対象とする商取引先の会員情報と、製品の品目情報に関わる受発注情報から、当該会員情報及び、当該品目情報に関わるサプライチェーンを推定し、推定したサプライチェーンを、前記品目情報に関わる属性情報を使用して絞り込み、前記絞り込んだサプライチェーンにおける各会員の環境情報交換履歴における情報要求日と情報回答日から、前記会員別の情報回答期間を評価し、前記絞り込んだサプライチェーンに従って、前記評価した会員別の情報回答期間を集計し、前記集計した評価対象企業の情報回答期間をネットワークを介してユーザコンピュータへ回答するシステムが記載されている（要約参照）。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２０１１－００８３０９号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

前述した特許文献１では、製品の品目情報に関する受発注情報を共通の記憶部で保持し、その受発注情報から当該会員情報及び、当該品目情報に関わるサプライチェーンを推定している。しかし、サプライチェーンに参加する会員の中で、直接取引に関係ない会員に、受発注関係や取引先の企業の情報を秘匿化することを、特許文献１は想定していない。サプライチェーンに参加する各会員が関わる受発注情報を共通の記憶部で管理する場合でも、記憶部に対するアクセス制御によって秘匿化が実現できるが、どのデータを誰に秘匿化するなどを設定する必要があり、記憶部を管理する者の手間が大きい。

【0008】

そこで、以下の条件を満たした上で、納品実績を電子データとして取得し、かかる納品業務に参加する企業間で共有する仕組みを実現することが求められる。納品実績の電子データとしては、例えば、サイン付き受領書の画像などが考えられる。

【0009】

第一の条件として、最終的に業務を遂行する企業（以下、「最終受注企業」という。）の責任者が、納品実績を初めに受け取ること。

【0010】

第二の条件として、納入者が端末を用いて納品実績を送信する時に、複雑な操作を納入者に要求しないこと。例えば、送信先のサーバ情報の入力やメールアドレスの入力などの複雑な操作をしなくても、アプリ上で納品実績を容易に指定のサーバに送信できる仕組みを構築する。

【0011】

第三の条件として、最終受注先企業が零細企業である場合を考慮すること。例えば、最終受注企業が、納品実績を送信するための端末を用意できない場合や、納品実績送信用のアプリを開発できない場合にも対応できるようにするのが望ましい。従って、委託元である企業がそれらの端末やアプリを用意することを前提とする。

【0012】

第四の条件として、納入者が用いる端末が納品の度に異なる場合を考慮すること。従って、納入者が用いる端末に、納品実績送信先のサーバ情報やメールアドレスなどを事前に登録できない場合にも対応できるようにする。

【0013】

第五の条件として、企業の情報漏洩リスク防止のために、受発注取引（契約）に直接関係のない企業には秘匿とすること。具体的には一案件にかかる業務委託に参加していても、委託、再委託、再々委託のようにフローが長くなると自らの取引とは関係のない受発注（契約）が発生する。商取引の健全性のため、発注者、受注者に関連のない第三者企業が閲覧できないようにする必要がある。ここで、発注者とは他の企業に仕事を依頼する企業であり、受注者とは他の企業から仕事の依頼を受ける企業である。

【0014】

ここで懸念される課題として、最終受注企業（納入者）が手入力などでサーバ情報を入力するのが困難と想定されること（上記、第二の条件）や、委託元企業が直接受発注取引（契約）に関与しない最終受注企業の情報を知ることは難しい（上記、第五の条件）ことから、最終受注企業のサーバ情報を、端末（委託元となる企業が貸し出すものを想定）に入力することが困難、ということが挙げられる。従って、委託元企業が、受注企業及びそのサーバ情報を知らない場合でも、端末が最終受注企業のサーバのアドレスを取得し、業務実績を送信できる仕組みが求められる。

【0015】

そこで、本発明では、一の業者が請け負った業務を他の業者に発注・受注する業務委託が、複数回行われる商取引において、参加する各企業のサーバが、直接関係のある受発注取引の情報のみを管理し、秘匿化を実現できるととともに、元請業者企業が、最終受注企業のサーバ情報を知らず、また、当該元請業者が貸与する端末にその情報を入力できない場合でも、最終受注企業がサーバの宛先に送付した情報を、端末により取得できるようにすることを目的とする。

【課題を解決するための手段】

【0016】

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数の企業間で発注及び受注からなる業務委託が段階的に行われる商取引において、業務を請け負う受注企業のサーバを探索する業務実績管理システムであって、前記複数の企業の各々のサーバと、少なくとも委託元企業のサーバとネットワークを介して接続される端末とを備え、前記サーバの各々は、所定の処理を実行する第１演算装置と、前記第１演算装置に接続された第１記憶部とを有し、前記端末は、所定の処理を実行する第２演算装置と、前記第２演算装置に接続された第２記憶部とを有し、前記サーバは、取得した識別情報が付された発注情報が前記第１記憶部に記憶されているかを判定し、前記取得した識別情報が付された発注情報が前記第１記憶部に記憶されている場合、当該発注情報の受注企業のサーバのネットワーク上のアドレス情報を取得することによって、前記受注企業のサーバを段階的に探し、前記取得した識別情報が付された発注情報が前記第１記憶部に記憶されていない場合、最終受注企業であることを示す情報を前記端末に送信し、前記端末は、前記最終受注企業であることを示す情報の送信元のサーバのネットワーク上のアドレス情報を、前記最終受注企業のサーバのネットワーク上のアドレス情報として特定することを特徴とする。

【発明の効果】

【0017】

本発明の一態様によれば、端末が最終受注企業のサーバ情報を取得できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

【図面の簡単な説明】

【0018】

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

【図2】実施例１の業務実績管理システムのハードウェア構成例を示すブロック図である。

【図3】実施例１の業務実績管理システムの論理構成を示すブロック図である。

【図4A】実施例１の通知処理手順の例を示すフローチャートである。

【図4B】実施例１の通知処理手順の例を示すフローチャートである。

【図4C】実施例１の通知処理手順の例を示すフローチャートである。

【図5】実施例１の通知処理の流れを示すシーケンス図である。

【図6】実施例１の発注情報の一例を示す図である。

【図7】実施例２の受発注情報の一例を示す図である。

【図8A】実施例２の通知処理手順の例を示すフローチャートである。

【図8B】実施例２の通知処理手順の例を示すフローチャートである。

【図8C】実施例２の通知処理手順の例を示すフローチャートである。

【図9】実施例３の通知処理手順の例を示すフローチャートである。

【図10】実施例３の通知処理の流れを示すシーケンス図である。

【図11】実施例３のハッシュ値情報の一例を示す図である。

【図12A】実施例４の通知処理手順の例を示すフローチャートである。

【図12B】実施例４の通知処理手順の例を示すフローチャートである。

【図13】実施例４の通知処理の流れを示すシーケンス図である。

【図14】実施例５の通知処理手順の例を示すフローチャートである。

【図15】実施例５の通知処理の流れを示すシーケンス図である。

【図16A】実施例６の通知処理手順の例を示すフローチャートである。

【図16B】実施例６の通知処理手順の例を示すフローチャートである。

【図17】実施例６の通知処理の流れを示すシーケンス図である。

【発明を実施するための形態】

【0019】

以下、添付図面を参照して、本発明の実施例を詳細に説明する。なお、以下の実施例は本発明の一例に過ぎず、本発明は図示された構成に限定されるものではない。また、多くの場合ユーザは納入者を指す。

【0020】

本明細書等における「０次」、「１次」、「２次」などの表記は、構成要素を識別するために付するものであり、必ずしも、数、順序、又はその内容を限定するものではない。なお、以下の実施例では、一つの案件の仕事全部又は一部を、０次企業から１次企業へ委託し、１次企業から２次企業へ委託するという流れで、再委託、再々委託のように、発注及び受注による業務の委託を段階的に繰り返すことにより、チェーン状又はフロー状の業務委託構造（以下、単に「業務委託フロー」という。）が形成される。なお、０次企業が委託元企業であるとは限らず、各段階において委託元及び委託先がある。

【0021】

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

【0022】

本ソリューションでは、０次企業００１、１次企業００２、２次企業００３及び金融機関００４が登場する。０次企業００１から１次企業００２へ業務を委託し（ステップＳ０１１）、１次企業００２から２次企業００３へ業務を委託し（ステップＳ０１２）、２次企業の納入者が業務を完了後、２次企業から１次企業へ納品完了を報告し（ステップＳ０１３）、１次企業から０次企業へ納品完了を報告する（ステップＳ０１４）。１次企業から０次企業へ納品完了報告後に、その業務の対価が０次企業から１次企業に支払われる（ステップＳ０１５）。同様に、２次企業から１次企業へ納品完了報告後に、その業務の対価が１次企業から２次企業に支払われる（ステップＳ０１６）。業務の対価の支払いは、銀行などの金融機関が発行する法定通貨や、仮想通貨などの様々な手段を採用してもよい。

【0023】

なお、本発明を輸送業、特に商品の納品業務に適用した場合の実施例を説明するが、輸送業に限らず多段階の業務委託フローとなっている業界であれば、例えば建設業や製造業にも本発明は適用可能である。

【実施例0024】

実施例１では、多段階の業務委託フローに参加する各企業が、自社による受注及び発注の情報のみを自社のサーバで管理している状況において、最終の委託先企業を知らない委託元企業が提供するシステムに入力された納品先のサイン付き受領書の画像を納品実績として、最終の委託先企業のサーバに送信する。

【0025】

本実施例で取り扱われる受領書は、納品先が商品を受領したことを証明するために作成される文書であり、受領書は委託元である０次企業が発行し、納品先での受領サインの記入によって、納品先が納品物を受領したことの証書である。通常は、納品先がサインした受領書が、業務委託フローの下流から上流に送付され、最初の委託元企業に返却される場合が多い。

【0026】

納品先の担当者とは、納品先で商品を受け取る業務を担当する人や納品先の責任者である。例えば、納品先の担当者は、納品先である企業で納品物の受取業務を担当する人や納品先の現場の責任者でもよいし、納品先である個人本人でもよい。また、納品実績は、納品先が物品を受領したことの証拠となる電子化された情報であり、例えば、納品先のサイン付き受領書の画像である。

【0027】

＜業務実績管理システムのハードウェア構成例＞
図２は、実施例１の業務実績管理システムのハードウェア構成例を示すブロック図である。

【0028】

業務実績管理システム１００は、サーバ１１０、端末１２０、及びネットワーク１３０を有する。サーバ１１０と端末１２０は、有線又は無線によるネットワーク１３０で通信が可能であり、情報を送受信できる。

【0029】

サーバ１１０は、記憶部１１１、制御部１１２、表示部１１３、入力部１１４、及び通信部１１５を有する。サーバ１１０が、表示部１１３及び入力部１１４を有さなくてもよい。例えば、サーバ１１０とネットワーク１３０による通信が可能で、入力部、表示部、及び通信部を有するクライアント装置を別に設け、クライアント装置がサーバ１１０から送信された情報を表示したり、クライアント装置に入力された情報をサーバ１１０に送信したりしてもよい。

【0030】

また、サーバ１１０は業務委託フローに参加する企業ごとに設けられ、サーバ１１０の数は任意である。実施例１では、ある業務の委託構造に参加する企業が４社あり、業務実績管理システム１００が、０次企業のサーバ１１０－１、１次企業のサーバ１１０－２、２次企業のサーバ１１０－３、及び３次企業のサーバ１１０－４を有する例で説明する。

【0031】

記憶部１１１は、例えば半導体記憶装置、磁気ディスク装置、不揮発性の記憶素子であるＲＯＭ、揮発性の記憶素子であるＲＡＭ、又はそれらの組合せなどで構成され、不揮発性記憶領域及び揮発性記憶領域を含む。記憶部１１１は、制御部１１２によって実行されるプログラム、制御部１１２による処理の際に参照されるデータ、及びや制御部１１２による処理で出力されたデータなどを格納する。

【0032】

制御部１１２は、記憶部１１１、表示部１１３、入力部１１４、及び通信部１１５と接続されており、記憶部１１１に格納されたプログラムに記述された命令に従って、後述する種々の処理を実行する演算装置である。例えば、発注情報などの記憶部１１１への書き込みや、端末１２０から受信したデータをクエリとして、記憶部１１１に格納されたデータの検索などを行う。

【0033】

表示部１１３は、例えば画像表示装置（ディスプレイ）のような情報を出力するデバイスであり、例えば、発注情報を入力するための画面や、端末１２０から受信した受領書画像などの納品実績などを画面上に表示する。

【0034】

入力部１１４は、例えばタッチパネルやキーボード、マウスなどの入力装置であり、発注情報などを入力するために使用される。

【0035】

通信部１１５は、有線又は無線によるネットワーク１３０と接続するインターフェース装置であり、端末１２０との間で、案件ＩＤや発注ＩＤ、サーバ１１０のネットワーク上のアドレス情報の送受信、納品実績などの情報を受信する。

【0036】

サーバ１１０にネットワークを介して接続された管理者端末（図示省略）が表示部１１３及び入力部１１４を提供してもよい。この場合、サーバ１１０がウェブサーバの機能を有し、管理者端末がサーバ１１０に所定のプロトコル（例えばｈｔｔｐ）でアクセスしてもよい。

【0037】

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

【0038】

サーバ１１０は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。サーバ１１０の各機能部は、各々別個の物理的又は論理的計算機上で動作するものでも、複数が組み合わされて一つの物理的又は論理的計算機上で動作するものでもよい。

【0039】

端末１２０は、納入者などのユーザ（最終の受注企業の従業員）が納品時に携帯し、サーバ１１０との間で情報を送受信する。例えば、端末１２０は、物流業務の場合、輸送業務を行うドライバなどが携帯する。端末１２０は、制御部１２１と、表示部１２２と、入力部１２３と、通信部１２４を有する。制御部１２１は、表示部１２２、入力部１２３、及び通信部１２４と接続し、端末１２０の動作全般を制御する。

【0040】

表示部１２２は、例えば画像表示装置（ディスプレイ）のような、情報を出力するデバイスである。表示部１２２は、ユーザへの操作指示や伝達事項などを画面表示する。案件ＩＤや端末１２０が最初に通信するサーバ１１０のネットワーク上のアドレス情報などを、受領書などの書面に印字されたバーコードから読み取る際に、表示部１２２がバーコードの読み取り画面を表示するとよい。また、納品実績として、サイン付き受領書の画像や納品物などの画像を用いる場合、表示部１２２がカメラの撮影画面を表示してもよい。

【0041】

入力部１２３は、業務実績管理システム１００の通知処理を開始する案件ＩＤ、納品実績、及び端末１２０が最初に通信するサーバ１１０のネットワーク上のアドレス情報など、端末１２０が送信する情報を受け付ける入力装置である。入力部１２３としては、例えば、タッチパネルやキーボード、マウスである。

【0042】

入力部１２３は、バーコードリーダや二次元コードリーダでもよく、これらのリーダを用いると、案件ＩＤや端末１２０が最初に通信するサーバ１１０のネットワーク上のアドレス情報などを、受領書などの書面に印字されたバーコードから読み取れる。また、入力部１２３は画像を撮影するカメラでもよく、サイン付き受領書の画像や納品物などの画像を納品実績として用いる撮影できる。

【0043】

通信部１２４は、有線又は無線の通信によってネットワーク１３０と接続し、端末１２０との間で、案件ＩＤ、発注ＩＤ、サーバ１１０のネットワーク上のアドレス情報などを送受信し、納品実績などの情報を送信する。

【0044】

ここで、サーバ１１０のネットワーク上のアドレス情報とは、例えば、サーバ１１０のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）、ホスト名、ポート番号、ファイルパス等である。

【0045】

＜業務実績管理システムの機能的構成例＞
図３は、実施例１の業務実績管理システム１００の論理構成を示すブロック図である。

【0046】

各サーバ１１０は、記憶部１１１と、発注情報入力部２１１と、発注情報送信部２１２と、実績取得部２１３と、受注者検索部２１４と、アドレス送信部２１５を有する。

【0047】

発注情報入力部２１１には、発注情報２３１が入力される。実績取得部２１３には、端末１２０から取得した納品実績２３４が入力され、表示部１１３に表示される。サーバ１１０に入力されたデータは、記憶部１１１に記憶される。

【0048】

端末１２０は、初期情報入力部２２１と、サーバ接続部２２２と、納品実績送信部２２３を有する。初期情報入力部２２１は、受領書に印字されたバーコード又は二次元コードを読み取ることで、案件ＩＤ２３２や端末１２０が最初に通信する０次企業のサーバのネットワーク上のアドレス情報２３３を取得する。また、納品実績２３４は、納品実績送信部２２３に入力され、３次企業のサーバに送信される。

【0049】

ここで、端末１２０の入力部１２３に入力される案件ＩＤ２３２や端末１２０が最初に通信するサーバ１１０のネットワーク上のアドレス情報２３３の取得方法は、受領書に印字されたバーコード又は二次元コードから取得する方法に限定されない。例えば、案件ＩＤ２３２については、端末１２０の表示部１２２が案件ＩＤの一覧を表示し、納品実績送信の通知処理を開始する案件ＩＤの選択によって案件ＩＤを取得してもよい。また、サーバ１１０のネットワーク上のアドレス情報２３３については、端末１２０の記憶部に０次企業のサーバのネットワーク上のアドレス情報２３３を事前に記憶してもよい。これにより、受領書に印字されたバーコード又は二次元コードがない場合でも、ユーザの作業を増加することなく、案件ＩＤ２３２や０次企業のサーバ１１０－１のネットワーク上のアドレス情報２３３を取得できる。

【0050】

なお、図３では、初期情報入力部２２１、サーバ接続部２２２及び納品実績送信部２２３は端末１２０に配置することを想定したが、端末１２０はｗｅｂブラウザを実行し、Ｗｅｂブラウザと連携したサーバ１１０－１の処理によって、それらの機能を実現してもよい。その場合、初期情報入力部２２１、サーバ接続部２２２及び納品実績送信部２２３は、例えば、図３に示したサーバ１１０－１の記憶部１１１に記憶されたプログラムを、制御部１１２が実行することによって実現できる。これにより、端末１２０にネイティブアプリを実装できない場合でも、業務実績管理システム１００を実現できる。

【0051】

図３に示すアドレス送信部２１５から受注者検索部２１４への通信は、実施例３では使用されない。また、後述する実施例３では、サーバ接続部２２２からアドレス送信部２１５への通信と、アドレス送信部２１５からサーバ接続部２２２への通信は使用されず、アドレス送信部２１５から受注者検索部２１４への通信が使用される。

【0052】

＜業務実績管理システムによる通知処理手順例＞
図４Ａ、図４Ｂ及び図４Ｃは、実施例１の業務実績管理システム１００による通知処理手順の例を示すフローチャートであり、図５は、通知処理の流れを示すシーケンス図である。

【0053】

業務実績管理システム１００による通知処理を開始する前に、０次企業のサーバ１１０－１の発注情報入力部２１１が１次企業への発注情報２３１を取得し、取得した発注情報２３１を記憶部１１１に記憶し、発注情報送信部２１２に送信する（ステップＳ３０１）。発注情報２３１の詳細は図６を参照して後述する。

【0054】

次に、業務実績管理システム１００は、企業の発注順序を表す変数ｎを０に設定する（ステップＳ３０２）。

【0055】

次に、ｎ次企業のサーバ１１０の発注情報送信部２１２は、ｎ＋１次企業のサーバ１１０の発注情報入力部２１１に、ｎ次企業からｎ＋１次企業への発注情報２３１を送信する（ステップＳ３０３）。

【0056】

次に、ｎ＋１次企業のサーバ１１０の発注情報入力部２１１は、ｎ＋１次企業への発注情報２３１を記憶部１１１に記憶する（ステップＳ３０４）。

【0057】

次に、ｎ＋１次企業のサーバ１１０の発注情報入力部２１１は、ｎ＋２次企業への発注情報２３１を取得するかどうかを判定する。ｎ＋２次企業への発注情報２３１がある場合（ステップＳ３０５：Ｙｅｓ）、業務実績管理システム１００は、ステップＳ３０６以降の通知処理を開始する。一方、ｎ＋２次企業への発注情報２３１がない場合（ステップＳ３０５：Ｎｏ）、業務実績管理システム１００は、ステップＳ３０８以降の通知処理を開始する。

【0058】

ステップＳ３０５でｎ＋２次企業への発注情報２３１を取得すると判定されると、ｎ＋１次企業のサーバ１１０の発注情報入力部２１１は、ｎ＋２次企業への発注情報２３１を記憶部１１１に記憶し、ｎ＋２次企業のサーバ１１０の発注情報入力部２１１に、ｎ＋１次企業からｎ＋２次企業への発注情報２３１を送信する（ステップＳ３０６）。

【0059】

次に、業務実績管理システム１００は、企業の発注順序を表す変数ｎに１を加算し（ステップＳ３０７）、ステップＳ３０３に戻る。

【0060】

ステップＳ３０５でｎ＋２次企業への発注情報２３１を取得しないと判定されると、端末１２０は、ユーザの所定の操作による通知処理の開始指示の有無を判定する（ステップＳ３０８）。開始指示がある場合（ステップＳ３０８：Ｙｅｓ）、端末１２０は、ステップＳ３０９以降の通知処理を開始する。開始指示がない場合（ステップＳ３０８：Ｎｏ）、ステップＳ３０９以降の通知処理を実行せず、処理を終了する。

【0061】

次に、端末１２０の初期情報入力部２２１は、受領書に印字されたバーコード又は二次元コードを読み取ることで、案件ＩＤ２３２と０次企業のサーバ１１０－１のネットワーク上のアドレス情報２３３を取得し、サーバ接続部２２２に送信する（ステップＳ３０９）。なお、初期情報入力部２２１による、案件ＩＤ２３２と０次企業のサーバのネットワーク上のアドレス情報２３３の取得方法は、受領書に印字されたバーコード又は二次元コードから取得する方法に限定されず、前述した他の方法を採用しうる。

【0062】

次に、端末１２０のサーバ接続部２２２が、０次企業のサーバ１１０－１の受注者検索部２１４に、案件ＩＤ２３２を送信する（ステップＳ３１０）。

【0063】

次に、業務実績管理システム１００は、企業の発注順序を表す変数ｍを０に設定する（ステップＳ３１１）。

【0064】

次に、ｍ次企業のサーバ１１０の受注者検索部２１４は、端末１２０のサーバ接続部２２２から取得した案件ＩＤ２３２に関連付けられ、発注者４０２が自社である、ｍ＋１次企業への発注情報２３１が、記憶部１１１に記憶されているかどうかを判定する（ステップＳ３１２）。ｍ＋１次企業への発注情報２３１がある場合（ステップＳ３１２：Ｙｅｓ）、業務実績管理システム１００は、ステップＳ３１３以降の通知処理を開始する。ｍ＋１次企業への発注情報２３１がない場合（ステップＳ３１２：Ｎｏ）、業務実績管理システム１００は、ステップＳ３１７以降の通知処理を開始する。

【0065】

ステップＳ３１２でｍ＋１次企業への発注情報２３１が記憶部１１１に記憶されていると判定されると、ｍ次企業のサーバ１１０の受注者検索部２１４は、案件ＩＤ２３２に関連付けて、記憶部１１１に記憶されているｍ＋１次企業への発注情報２３１から受注者のサーバ１１０のネットワーク上のアドレス情報４０５、すなわち、ｍ＋１次企業のサーバ１１０のネットワーク上のアドレス情報を検索し、案件ＩＤ２３２とｍ＋１次企業のサーバのネットワーク上のアドレス情報をアドレス送信部２１５に送信する（ステップＳ３１３）。

【0066】

次に、ｍ次企業のサーバ１１０のアドレス送信部２１５は、案件ＩＤ２３２とｍ＋１次企業のサーバのネットワーク上のアドレス情報を、端末１２０のサーバ接続部２２２に送信する（ステップＳ３１４）。ここで、端末１２０が記憶部を有し、ステップＳ３０９において、端末１２０がその記憶部に案件ＩＤを記憶する場合、現在処理中の案件ＩＤを知っているので、ｍ次企業のサーバ１１０のアドレス送信部２１５は、案件ＩＤ２３２を端末１２０のサーバ接続部２２２に送信しなくてもよい。これにより、ステップＳ３１４における、サーバ１１０と端末１２０のデータの通信量を削減できる。

【0067】

次に、端末１２０のサーバ接続部２２２は、案件ＩＤ２３２をｍ＋１次企業のサーバ１１０の受注者検索部２１４に送信する（ステップＳ３１５）。

【0068】

次に、業務実績管理システム１００は、企業の発注順序を表す変数ｍに１を加算し、ステップＳ３１２に戻る（ステップＳ３１６）。ステップＳ３１３からＳ３１５を、業務委託フローの０次、１次、２次へと順次辿って、段階的なサーバの探索を繰り返し実行することによって、委託元である０次企業のサーバ１１０－１から、最終的に作業を受注した３次企業のサーバ１１０－４に到達できる。

【0069】

ステップＳ３１２でｍ＋１次企業への発注情報２３１が記憶部１１１に記憶されていないと判定されると、企業の発注順序を表す変数ｍが最大値、すなわち最終の受注者となっているので、最終の受注者であるｍ次企業のサーバ１１０の受注者検索部２１４は、案件ＩＤ２３２とＮＵＬＬデータをアドレス送信部２１５に送信する（ステップＳ３１７）。

【0070】

次に、ｍ次企業のサーバ１１０のアドレス送信部２１５は、案件ＩＤ２３２とＮＵＬＬデータを端末１２０のサーバ接続部２２２に送信する（ステップＳ３１８）。

【0071】

次に、端末１２０のサーバ接続部２２２は、サーバ１１０から案件ＩＤ２３２とＮＵＬＬデータを受信すると、案件ＩＤ２３２とＮＵＬＬデータの送信元であるサーバ１１０のネットワーク上のアドレス情報を、納品実績送信部２２３に送信する（ステップＳ３１９）。このように、サーバ接続部２２２は、発注情報２３１が記憶部１１１に記憶されているかを判定し、発注情報２３１が記憶部１１１に記憶されている場合には、案件ＩＤ２３２に関連する発注情報２３１から、受注企業のサーバのネットワーク上のアドレス情報を検索する。そして、この受注企業のサーバの記憶部に、案件ＩＤ２３２に関連する発注情報２３１が、更に記憶されている場合、案件ＩＤ２３２に関連する発注情報２３１から、その受注企業のサーバのネットワーク上の固有情報を取得して端末１２０に送信する。受注企業のサーバに発注情報２３１が検出される場合には、このようにサーバを段階的に検索する。発注情報がない場合、案件ＩＤ２３２とＮＵＬＬデータを端末１２０に送信する。

【0072】

ここで、ステップＳ３１８において、ｍ次企業のサーバ１１０のアドレス送信部２１５は、ＮＵＬＬデータではなく、ｍ次企業のサーバのネットワーク上のアドレス情報を端末１２０のサーバ接続部２２２に送信してもよい。その場合、ステップＳ３１９では、端末１２０のサーバ接続部２２２は、サーバ１１０から受信したサーバ１１０のネットワーク上のアドレス情報と、そのデータの送信元のサーバ１１０のネットワーク上のアドレス情報を照合し、両者が同じであるかを判定する。アドレス情報が同じであれば、サーバ１１０から取得したサーバのネットワーク上のアドレス情報を、納品実績送信部２２３に送信する。このように端末がＮＵＬＬデータ（又はこれに代わるデータでも良い）を受信することをトリガーとして、最終受注企業のサーバのアドレスを取得し、業務実績を送信できるようになる。

【0073】

次に、端末１２０の納品実績送信部２２３は、納品実績２３４を取得後、サーバ接続部２２２から取得した、ｍ次企業のサーバのネットワーク上のアドレス情報に基づいて、案件ＩＤ２３２と納品実績２３４を、ｍ次企業のサーバ１１０の実績取得部２１３に送信する（ステップＳ３２０）。

【0074】

ここで、端末１２０の納品実績送信部２２３が受信する、納品実績２３４の詳細について説明する。納品実績２３４は、納品先が商品を受領したことの証拠となる情報を電子化したものである。例えば、納品先の担当者が受領サインを記入した受領書や納品書でもよいし、納品先での納品物の画像、納品先と納品物が一緒に写った画像でもよい。納品実績２３４に納入者の指紋情報や顔の特徴量を含めて、納品実績２３４の証拠能力を高めてもよい。サイン付き受領書の画像は納品実績２３４の一例であり、他の形態でもよい。

【0075】

次に、ｍ次企業のサーバ１１０の実績取得部２１３は、受信した納品実績２３４を記憶部１１１に記憶後、表示部１１３に出力する（ステップＳ３２１）。ここで、ｍ次企業のサーバ１１０の実績取得部２１３が、ｍ次企業の担当者による納品実績の承認実績を取得してもよい。例えば、実績取得部２１３が、納品実績２３４と共に納品実績の承認ボタンを表示してもよい。この場合、ｍ次企業の担当者によって承認ボタンが操作された後に、サーバ１１０の実績取得部２１３が納品実績２３４を、記憶部１１１に記憶するとよい。一方、ｍ次企業の担当者によって承認ボタンが操作されない（例えば、却下ボタンが操作された）場合、サーバ１１０の実績取得部２１３が端末１２０に不承認実績を送信し、端末１２０のユーザに再度、納品実績の取得を促してもよい。これにより、最終受注企業によって承認された納品実績を、ｍ次企業のサーバ１１０が取得できる。

【0076】

ステップＳ３２１において、必ずしも納品実績２３４が表示部１１３に表示される必要はない。例えば、ｍ次企業のサーバ１１０の実績取得部２１３が納品実績２３４を受信後、受信した納品実績２３４を記憶部１１１に記憶してもよい。これにより、人が確認する作業を除いて、業務を効率化できる。

【0077】

ステップＳ３２１の後に、ステップＳ３２２からステップＳ３２６を実行するが、ステップＳ３０８に戻ってもよい。

【0078】

次に、ｍ次企業のサーバ１１０の受注者検索部２１４が、端末１２０のサーバ接続部２２２から取得した案件ＩＤ２３２に関連付けられ、受注者４０４が自社であるｍ－１次企業からの発注情報２３１が記憶部１１１に記憶されているかどうかを判定する（ステップＳ３２２）。ｍ－１次企業からの発注情報２３１がある場合（ステップＳ３２２：Ｙｅｓ）、業務実績管理システム１００は、ステップＳ３２３以降の通知処理を開始する。ｍ－１次企業からの発注情報２３１がない場合（ステップＳ３２２：Ｎｏ）、ステップＳ３０８に戻る。

【0079】

次に、ｍ次企業のサーバ１１０の実績取得部２１３が、記憶部１１１に記憶されており、端末１２０から取得した案件ＩＤに関連付けられており、受注者が自社であるｍ次企業への発注情報２３１から、発注者であるｍ－１次企業のサーバ１１０のネットワーク上のアドレス情報４０３を検索し、検索されたサーバ１１０に案件ＩＤと納品実績２３４を送信する（ステップＳ３２３）。

【0080】

次に、ｍ－１次企業のサーバ１１０の実績取得部２１３が、受信した案件ＩＤに関連付けて、受信した納品実績２３４を記憶部１１１に記憶する（ステップＳ３２４）。

【0081】

次に、発注者から受注者への支払金額情報が発注情報２３１に含まれる場合、ｍ－１次企業のサーバ１１０の実績取得部２１３が、案件ＩＤに関連付けられた発注情報２３１のｍ次企業への支払金額情報に基づいて、中央銀行が発行する法定通貨、仮想通貨などによる支払データを生成し、支払処理を実行する（ステップＳ３２５）。

【0082】

次に、業務実績管理システム１００は、企業の発注順序を表す変数ｍから１を減算し、ステップＳ３２２に戻る（ステップＳ３２６）。

【0083】

ステップ３２４において、記憶部１１１に納品実績２３４を記憶した後、即時にステップＳ３２５において支払い処理を実行せずに、発注者４０２のサーバ１１０の実績取得部２１３が、納品実績２３４と共に支払承認ボタンを表示して、支払承認ボタンが操作された後に支払処理を実行してもよい。

【0084】

ステップＳ３２２からステップＳ３２６によって、業務委託フローに参加する全企業に対して、ｍ次企業のサーバ１１０が端末１２０から取得した納品実績２３４を共有でき、納品実績２３４を取得後、発注者から受注者への支払いを早期に実行できる。

【0085】

なお、ステップＳ３０９において、端末１２０の納品実績送信部２２３が、取得した納品実績２３４を別のサーバに送信後、当該サーバから暗号化した納品実績を取得し、サーバ接続部２２２に送信してもよい。その後、ステップＳ３１０において、端末１２０のサーバ接続部２２２が、０次企業のサーバ１１０の受注者検索部２１４に、案件ＩＤ２３２と暗号化した納品実績を送信してもよい。さらに、ステップＳ３２０において、端末１２０の納品実績送信部２２３が、納品実績２３４を暗号化した当該別のサーバから秘密鍵を取得し、ｍ次企業のサーバ１１０の実績取得部２１３に、案件ＩＤ２３２と秘密鍵を送信してもよい。これにより、納品実績２３４を業務委託フローに参加する企業間で共有する時、最終受注企業から納品実績２３４ではなく、暗号化された納品実績を復号するための秘密鍵のみを送信すればよいため、データの送信量を削減できる。

【0086】

＜入力データの発注情報の一例＞
図６は、実施例１の業務実績管理システム１００のサーバ１１０へ入力される発注情報２３１の一例を示す図である。なお、図６に記載されているデータは一例である。

【0087】

発注情報２３１は、発注者が依頼し、受注者が引き受ける業務に関する情報である。発注情報２３１は、案件ＩＤ２３２、発注ＩＤ４０１、発注者４０２、発注者のサーバのネットワーク上のアドレス情報４０３、受注者４０４、及び受注者のサーバのネットワーク上のアドレス情報４０５を含む。

【0088】

案件ＩＤ２３２は、企業間で受発注される業務を識別するために付される識別情報である。案件ＩＤ２３２は、ステップＳ３０１において、０次企業から１次企業への発注情報２３１を作成する時に生成され、０次企業から受注した業務を、１次企業から２次企業へ、２次企業から３次企業へと委託するように、他の企業に同じ業務を委託する場合、各企業間で取引される発注情報２３１の案件ＩＤ２３２は同じ値である。

【0089】

発注ＩＤ４０１は、発注者と受注者の間で取り引きされる発注を識別する情報である。発注ＩＤ４０１は、各企業間で受発注取引をする度に生成される。例えば、０次企業から１次企業への発注情報２３１の発注ＩＤ４０１と、１次企業から２次企業への発注情報２３１の発注ＩＤ４０１は別の値となる。

【0090】

発注者４０２は業務を発注する委託元企業の情報であり、受注者４０４は業務を受注する委託先企業の情報である。発注者４０２及び受注者４０４は、企業の名称でもよいし、企業の識別情報でもよい。

【0091】

なお、発注者４０２のサーバ１１０の実績取得部２１３が、納品実績２３４を受注者４０４のサーバ１１０から取得する際に、発注情報２３１の発注者４０２のサーバ１１０が受注者４０４への支払処理を実行する場合、発注情報２３１が発注者から受注者への支払金額を含んでもよい。これにより、納品実績２３４を取得後、発注者から受注者への支払いを即時に実行できる。

【0092】

以上に説明したように、実施例１によれば、業務実績管理システム１００を用いて、納品実績を送信するための端末１２０を貸し出す委託元企業が、最終受注企業の名称やサーバ情報を知らない場合でも、その端末１２０が業務委託フローの上流から下流へサーバ１１０を順次辿って、段階的にサーバを探索でき、最終受注企業のサーバ１１０に納品実績を送信できる。また、ユーザが納品実績の送信先である、最終受注企業のサーバ情報を端末１２０に入力するなどの複雑な操作をしなくても、納品実績を容易に最終受注企業のサーバに送信できる。

【0093】

また、最終受注企業が、納品実績を送信するための端末１２０をユーザである最終受注企業の従業員に貸し出せない場合や、納品実績を送信するための環境を用意できない場合に、最終受注企業に代えて、委託元企業が納品実績を送信するための端末１２０を貸し出す場合でも、最終受注企業のサーバに納品実績を送信できる。さらに、納品実績を送信するための端末１２０が納品の度に異なったり、事前にサーバ情報やメールアドレス等の情報を端末１２０に記憶できなかったりした場合でも、最終受注企業のサーバに納品実績を送信できる。

【0094】

なお、業務委託フローに参加する全企業の発注情報を共通サーバで管理し、納品実績を送信するための端末１２０がその共通サーバ上で最終受注企業のサーバ情報を検索し、そのサーバに納品実績を送信してもよい。しかし、共通サーバを管理する第三者機関が必要となるため、サーバの運用コストがかかり、発注情報に記載されている支払金額情報や受発注取引先の名前やサーバ情報などは、取引に直接関係のない企業に対して秘匿化すべきである。この場合、発注情報のアクセス制御を設定する必要があり、共通サーバを管理する者の作業工数が大きい。

【0095】

一方、本実施例の業務実績管理システム１００を用いると、各企業が直接関係ある発注情報のみ自社のサーバで管理するので、共通サーバが不要であり、サーバの運用コストを削減できる。また、受発注情報を各企業が分散して管理することによって、受発注情報を直接取引に関係のない企業に対して秘匿化できるため、共通サーバを管理する者の作業工数を削減できる。

【実施例0096】

次に、本発明の実施例２について説明する。実施例１では、発注ＩＤ４０１とは別に、業務委託フローで取り引きされる全ての発注情報２３１に、関係する企業内で共通する案件ＩＤ２３２が付与される。実施例２では、業務委託フローに参加する全企業で共有する案件ＩＤが付与されない。

【0097】

実施例２では、前述した実施例１との相違点を主に説明し、実施例１と同じ構成及び処理には同じ符号を付し、それらの説明は省略する。以下、図１、図２、図３、図５、図６、図７、図８Ａ、図８Ｂ及び図８Ｃを参照し、実施例１と相違する部分を説明する。

【0098】

＜実施例２における入力データの発注情報の一例＞
実施例２では、図６の発注情報２３１は案件ＩＤ２３２を含まない。

【0099】

＜実施例２における機能的構成例を示すブロック図＞
実施例２では、サーバ１１０の記憶部１１１は、受発注情報５００を記憶する。受発注情報５００の詳細は図７を参照して後述する。

【0100】

＜業務実績管理システムによる通知処理手順例＞
図８Ａ、図８Ｂ及び図８Ｃは、実施例２の業務実績管理システム１００による通知処理手順の例を示すフローチャートである。実施例２において、通知処理の流れを示すシーケンス図は実施例１（図５）と同じであるが、ステップＳ３１４、Ｓ３１５、Ｓ３１８、Ｓ３２０を、それぞれステップＳ３１４ａ、Ｓ３１５ａ、Ｓ３１８ａ、Ｓ３２０ａと読み替えられる。

【0101】

実施例２では、図８Ａに示すステップＳ３０１～Ｓ３０５、Ｓ３０７の処理は前述した実施例１と同じである。

【0102】

ステップＳ３０５でｎ＋２次企業への発注情報２３１を取得すると判定されると、ｎ＋１次企業のサーバ１１０の発注情報入力部２１１が、ステップＳ３０３においてｎ次企業のサーバ１１０から取得したｎ＋１次企業への発注情報２３１と、ステップＳ３０５において入力されたｎ＋２次企業への発注情報２３１に基づいて、受発注情報５００を作成する。その後、ｎ＋１次企業のサーバ１１０の発注情報入力部２１１が、ｎ＋２次企業への発注情報２３１と受発注情報５００を記憶部１１１に記憶し、ｎ＋２次企業への発注情報２３１を、ｎ＋１次企業のサーバ１１０の発注情報送信部２１２に送信する（ステップＳ３０６ａ）。

【0103】

次に、図８Ｂに示すステップＳ３０８～Ｓ３１７について説明する。

【0104】

ステップＳ３０５でｎ＋２次企業への発注情報２３１を取得しないと判定されると、端末１２０は、ユーザの所定の操作による通知処理の開始指示の有無を判定する（ステップＳ３０８）。開始指示がある場合（ステップＳ３０８：Ｙｅｓ）、端末１２０は、ステップＳ３０９以降の通知処理を開始する。開始指示がない場合（ステップＳ３０８：Ｎｏ）、ステップＳ３０９以降の通知処理を実行せず、処理を終了する。

【0105】

次に、端末１２０の初期情報入力部２２１は、受領書に印字されたバーコード又は二次元コードを読み取ることで、１次企業への発注情報２３１の発注ＩＤ４０１と０次企業のサーバのネットワーク上のアドレス情報２３３を取得し、サーバ接続部２２２に送信する（ステップＳ３０９）。なお、初期情報入力部２２１による、０次企業のサーバのネットワーク上のアドレス情報２３３の取得方法は、受領書に印字されたバーコード又は二次元コードから取得する方法に限定されず、前述した他の方法を採用しうる。

【0106】

次に、端末１２０のサーバ接続部２２２が、０次企業のサーバ１１０－１の受注者検索部２１４に、１次企業への発注情報２３１の発注ＩＤ４０１を送信する（ステップＳ３１０）。

【0107】

次に、０次企業のサーバ１１０－１の受注者検索部２１４が、端末１２０のサーバ接続部２２２から取得した発注ＩＤ４０１に関連付けられた１次企業への発注情報２３１から、１次企業のサーバのネットワーク上のアドレス情報を検索し、発注ＩＤ４０１と１次企業のサーバのネットワーク上のアドレス情報をアドレス送信部２１５に送信する（ステップＳ８０１）。

【0108】

次に、０次企業のサーバ１１０のアドレス送信部２１５が、端末１２０のサーバ接続部２２２に発注ＩＤを送信し、端末１２０のサーバ接続部２２２が、発注ＩＤ４０１を１次企業のサーバ１１０の受注者検索部２１４に送信する（ステップＳ８０２）。

【0109】

次に、業務実績管理システム１００は、企業の発注順序を表す変数ｍに１を設定する（ステップＳ３１１ａ）。

【0110】

次に、ｍ次企業のサーバ１１０の受注者検索部２１４は、端末１２０のサーバ接続部２２２から取得した発注ＩＤ４０１を受注ＩＤ５０１の値としている受発注情報５００が、記憶部１１１に記憶されているかどうかを判定する（ステップＳ３１２ａ）。受発注情報５００がある場合（ステップＳ３１２ａ：Ｙｅｓ）、業務実績管理システム１００は、ステップＳ３１３ａ以降の通知処理を開始する。受発注情報５００がない場合（ステップＳ３１２ａ：Ｎｏ）、業務実績管理システム１００は、ステップＳ３１７ａ以降の通知処理を開始する。

【0111】

ステップＳ３１２ａでｍ＋１次企業への発注情報２３１が記憶部１１１に記憶されていると判定されると、ｍ次企業のサーバ１１０の受注者検索部２１４は、端末１２０のサーバ接続部２２２から取得した発注ＩＤ４０１を受注ＩＤ５０１の値としている受発注情報５００から、発注ＩＤ４０１と受注者のサーバ１１０のネットワーク上のアドレス情報４０５、すなわち、ｍ＋１次企業のサーバ１１０のネットワーク上のアドレス情報を検索し、アドレス送信部２１５に送信する（ステップＳ３１３ａ）。

【0112】

次に、ｍ次企業のサーバ１１０のアドレス送信部２１５は、発注ＩＤ４０１とｍ＋１次企業のサーバのネットワーク上のアドレス情報を、端末１２０のサーバ接続部２２２に送信する（ステップＳ３１４ａ）。

【0113】

次に、端末１２０のサーバ接続部２２２は、発注ＩＤ４０１をｍ＋１次企業のサーバ１１０の受注者検索部２１４に送信する（ステップＳ３１５ａ）。

【0114】

次に、業務実績管理システム１００は、企業の発注順序を表す変数ｍに１を加算し、ステップＳ３１２ａに戻る（ステップＳ３１６）。ステップＳ３１３ａからＳ３１５ａを、業務委託フローを辿って、段階的なサーバの探索を繰り返し実行することによって、委託元である０次企業のサーバ１１０－１から最終の受注者である３次企業のサーバ１１０－４に到達できる。

【0115】

ステップＳ３１２でｍ＋１次企業への発注情報２３１が記憶部１１１に記憶されていないと判定されると、企業の発注順序を表す変数ｍが最大値、すなわち最終の受注者となっているので、最終の受注者であるｍ次企業のサーバ１１０の受注者検索部２１４が、発注ＩＤ４０１とＮＵＬＬデータをアドレス送信部２１５に送信する（ステップＳ３１７ａ）。

【0116】

次に、ｍ次企業のサーバ１１０のアドレス送信部２１５は、発注ＩＤ４０１とＮＵＬＬデータを端末１２０のサーバ接続部２２２に送信する（ステップＳ３１８ａ）。

【0117】

次に、端末１２０のサーバ接続部２２２は、サーバ１１０から発注ＩＤ４０１とＮＵＬＬデータを受信すると、発注ＩＤ４０１とＮＵＬＬデータの送信元であるサーバ１１０のネットワーク上のアドレス情報を、納品実績送信部２２３に送信する（ステップＳ３１９ａ）。ここで、ステップＳ３１８ａにおいて、ｍ次企業のサーバ１１０のアドレス送信部２１５は、ＮＵＬＬデータではなく、ｍ次企業のサーバのネットワーク上のアドレス情報を端末１２０のサーバ接続部２２２に送信してもよい。その場合、ステップＳ３１９ａでは、端末１２０のサーバ接続部２２２は、サーバ１１０から受信したサーバ１１０のネットワーク上のアドレス情報と、そのデータの送信元のサーバ１１０のネットワーク上のアドレス情報を照合し、両者が同じであるかを判定する。アドレス情報が同じであれば、サーバ１１０から取得したサーバのネットワーク上のアドレス情報を、納品実績送信部２２３に送信する。

【0118】

次に、端末１２０の納品実績送信部２２３は、納品実績２３４を取得後、サーバ接続部２２２から取得した、ｍ次企業のサーバのネットワーク上のアドレス情報に基づいて、発注ＩＤ４０１と納品実績２３４を、ｍ次企業のサーバ１１０の実績取得部２１３に送信する（ステップＳ３２０ａ）。

【0119】

次に、ｍ次企業のサーバ１１０の実績取得部２１３が、受信した納品実績２３４を記憶部１１１に記憶後、表示部１１３に出力する（ステップＳ３２１）。ここで、ｍ次企業のサーバ１１０の実績取得部２１３が、ｍ次企業の担当者による納品実績の承認実績を取得してもよい。例えば、実績取得部２１３が、納品実績２３４と共に納品実績の承認ボタンを表示してもよい。この場合、ｍ次企業の担当者によって承認ボタンが操作された後に、サーバ１１０の実績取得部２１３が納品実績２３４を、記憶部１１１に記憶するとよい。一方、ｍ次企業の担当者によって承認ボタンが操作されない（例えば、却下ボタンが操作された）場合、サーバ１１０の実績取得部２１３が端末１２０に不承認実績を送信し、端末１２０のユーザに再度、納品実績の取得を促してもよい。これにより、最終受注企業によって承認された納品実績を、ｍ次企業のサーバ１１０が取得できる。ステップＳ３２１において、必ずしも納品実績２３４が表示部１１３に表示される必要はない。例えば、ｍ次企業のサーバ１１０の実績取得部２１３が納品実績２３４を受信後、受信した納品実績２３４を記憶部１１１に記憶してもよい。これにより、人が確認する作業を除いて、業務を効率化できる。また、ステップＳ３２１の後に、ステップＳ８０３からステップＳ３２６を実行するが、ステップＳ３０８に戻ってもよい。

【0120】

次に、ｍ次企業のサーバ１１０の実績取得部２１３が、記憶部１１１に記憶されており、端末１２０から取得した発注ＩＤ４０１が受注ＩＤの値として格納されている受発注情報５００から、発注者であるｍ－１次企業のサーバのネットワーク上のアドレス情報４０３を検索し、検索されたサーバ１１０に発注ＩＤ４０１と納品実績２３４を送信する（ステップＳ８０３）。

【0121】

次に、ｍ－１次企業のサーバ１１０の実績取得部２１３が、発注ＩＤ４０１に関連付けて納品実績２３４を記憶部１１１に記憶する（ステップＳ８０４）。

【0122】

次に、発注者から受注者への支払金額情報が発注情報２３１に含まれる場合、ｍ－１次企業のサーバ１１０の実績取得部２１３が、発注ＩＤ４０１に関連付けられた発注情報２３１のｍ次企業への支払金額情報に基づいて、中央銀行が発行する法定通貨、仮想通貨などによる支払データを生成し、支払処理を実行する（ステップＳ８０５）。

【0123】

次に、ｍ－１次企業のサーバ１１０の受注者検索部２１４が、ｍ次企業のサーバ１１０から取得した発注ＩＤ４０１に紐づく受発注情報５００が、記憶部１１１に記憶されているかどうか判定する（ステップＳ３２２）。ｍ次企業からの受発注情報５００がある場合（ステップＳ３２２：Ｙｅｓ）、業務実績管理システム１００は、ステップＳ３２３以降の通知処理を開始する。ｍ次企業からの受発注情報５００がない場合（ステップＳ３２２：Ｎｏ）、ステップＳ３０８に戻る。

【0124】

次に、ｍ－１次企業のサーバ１１０の実績取得部２１３が、記憶部１１１に記憶されており、ｍ次企業のサーバ１１０から取得した発注ＩＤ４０１に関連付けられた受発注情報５００から、発注者であるｍ－２次企業のサーバ１１０のネットワーク上のアドレス情報４０３を検索し、検索されたサーバ１１０に発注ＩＤ４０１と納品実績２３４を送信する（ステップＳ３２３）。

【0125】

次に、ｍ－２次企業のサーバ１１０の実績取得部２１３が、ｍ－１次企業から受信した受注ＩＤ５０１の値を発注ＩＤ４０１として関連付けて、納品実績２３４を記憶部１１１に記憶する（ステップＳ３２４）。

【0126】

次に、発注者から受注者への支払金額情報が発注情報２３１に含まれる場合、ｍ－２次企業のサーバ１１０の実績取得部２１３が、ｍ－１次企業から受信した受注ＩＤ５０１が、発注ＩＤ４０１に関連付けられた発注情報２３１のｍ次企業への支払金額情報に基づいて、中央銀行が発行する法定通貨、仮想通貨などによる支払データを生成し、支払処理を実行する（ステップＳ３２５）。ステップ３２４において、記憶部１１１に納品実績２３４を記憶した後、即時にステップＳ３２５において支払い処理を実行せずに、発注者４０２のサーバ１１０の実績取得部２１３が、納品実績２３４と共に支払承認ボタンを表示して、支払承認ボタンが操作された後に支払処理を実行してもよい。

【0127】

＜サーバが記憶する受発注情報の一例＞
図７は、実施例２の業務実績管理システム１００のサーバ１１０の記憶部１１１に記憶される受発注情報５００の一例を示す図である。なお、図７に記載されているデータは一例である。

【0128】

受発注情報５００は、他社が自社に発注した発注情報２３１にかかる業務を自社が第３の企業に依頼した場合、他社が自社に発注した発注情報２３１と自社から第３の企業に発注した発注情報２３１を関連付けた情報である。受発注情報５００は、受注ＩＤ５０１、発注者４０２、発注者のサーバのネットワーク上のアドレス情報４０３、発注ＩＤ４０１、受注者４０４、及び受注者のサーバのネットワーク上のアドレス情報４０５を含む。

【0129】

受注ＩＤ５０１とは、他社が自社に発注した発注情報２３１の発注ＩＤ４０１である。そのため、発注者４０２は、他社から自社への発注情報２３１の発注者（当該他社）である。

【0130】

発注ＩＤ４０１は、自社から第３の企業への発注情報２３１の発注ＩＤである。また、受注者４０４は、自社から第３の企業への発注情報２３１の受注者（当該第３の企業）である。

【0131】

以上に説明したように、実施例２によれば、業務委託フローに参加する全ての企業で共有する案件ＩＤが無い場合でも、業務実績管理システム１００を用いて、納品実績を送信する端末１２０が業務委託フローの上流から下流のサーバ１１０を順次辿って、段階的にサーバを探索でき、最終受注企業のサーバに納品実績を送信できる。