JP2022006818A

JP2022006818A - 契約締結方法、契約締結プログラム及び契約締結システム

Info

Publication number: JP2022006818A
Application number: JP2020109317A
Authority: JP
Inventors: 啓成西村; Hiroshige Nishimura
Original assignee: Donuts Co Ltd
Current assignee: Donuts Co Ltd
Priority date: 2020-06-25
Filing date: 2020-06-25
Publication date: 2022-01-13
Anticipated expiration: 2040-06-25
Also published as: JP7117812B2

Abstract

【課題】事業者内部の意思決定過程と、契約相手との契約締結過程とを一気通貫で管理することができ、事後の検索や検証に資するようになる契約締結方法、契約締結プログラム及び契約締結システムを提供する。
【解決手段】契約締結システムは、契約データの入力を受け付ける契約データ入力受付ステップと、契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付けるＩＤ入力受付ステップと、ＩＤ入力受付ステップにて受け付けた契約当事者の契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断ステップと、可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する。
【選択図】図４

Description

新規性喪失の例外適用申請有り

本発明は、事業者内部での検討結果を踏まえた契約締結を行うためのシステム、同システムを動作させるための方法及びプログラムなどに関する。

事業者間で契約書を締結する際には通常、各当事者の担当者が契約内容について交渉し、まとまった交渉結果がそれぞれの事業者内部で稟議を経ることで検討され、決裁を得たうえで最終的な合意のための契約締結処理を行うる。

このようなプロセスにおいては、契約主体が複数存在することは当然のことながら、それぞれの契約主体の内部においても複数の関係者が介在することが通常であるため、関係者ごとの契約締結に関するかかわり方の管理が大きな課題となってきた。

そこで従来から、契約締結作業を効率化するための管理システムに関する種々の技術が開示されている。例えば特許文献１には、契約締結の申込みと承諾のやり取りを、通信ネットワークを介して実現する技術が開示されており、特許文献２には、契約締結を通信ネットワークを介して実現する際に当事者の真正の証明に用いられる電子署名に関する技術が開示されている。

特開２００２－１０９２１８特開２０１４－１２７０３４

しかしながら、特許文献１に記載されている先行技術は、あくまで申込と承諾の意思表示がネットワーク上でやり取りされるだけで、当該意思が当事者の事業者内部で真正な手続を経て行われたものであるか不明確である。また、特許文献２に記載されている先行技術においても、意思表示をする者の真正は証明しうるものの、当該意思が、事業者内部の適正な意思決定過程を経たものかの担保がないという点において、契約管理のあり方として十分とは言い難い。

このように、従来の契約締結フローにおいては、事業者内部の意思決定過程と、契約締結過程とが別々に管理されており、その管理方法や管理態様が異なっていたために、真に効率的な管理ができていたとはいいがたく、また、万が一問題が生じた場合の検証も容易に出来るとは言い難かった。

以上のような課題を解決すべく、本発明は、契約データの入力を受け付ける契約データ入力受付ステップと、契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付けるＩＤ入力受付ステップと、ＩＤ入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断ステップと、可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する契約締結ステップと、をコンピュータにて実行する契約締結方法などを提案する。

なお前記方法に関連して、契約締結ステップが締結日時を記録するタイムスタンプ付与サブステップをさらに有する契約締結方法なども提案する。

また、前記方法に関連して、複数の契約当事者の検討ステータスを記録する決裁処理利用記録ステップを更に有し、可否判断ステップは、決裁処理利用記録ステップにて記録された検討ステータスを用いる決裁状況判断利用サブステップをさらに有する契約締結方法なども提案する。

さらに前記方法に関連して、検討ステータスと紐づけられた通知先の情報を取得する通知先情報取得ステップと、契約締結ステップにて契約締結処理が行われた場合に、取得した通知先に締結処理に関する通知を出力する通知出力ステップをさらに有する契約締結方法なども提案する。

そして、ここまで掲げてきた各方法をコンピュータで実現するためのプログラムや当該方法を用いたシステムなどについても提案する。

主に以上のような構成をとる本発明によって、事業者内部の意思決定過程と、契約相手との契約締結過程とを一気通貫で管理することができ、事後の検索や検証に資するようになる。

本発明の契約締結システムの概要を示す図実施形態１の契約締結システムの機能ブロックの一例を示す図実施形態１の契約締結システムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図実施形態１の契約締結システムにおける処理の流れの一例を示す図実施形態１の契約締結システムにおける処理の別の流れの一例を示す図実施形態１の契約締結システムにおける処理の更に別の流れの一例を示す図実施形態２の契約締結システムの機能ブロックの一例を示す図実施形態２の契約締結システムにおける処理の流れの一例を示す図実施形態３の契約締結システムの機能ブロックの一例を示す図実施形態３の契約締結システムにおける処理の流れの一例を示す図

まず図１を示す。図１は本発明の概要を示す図で、Ａ社とＢ社とが契約締結する場合の概要を示す一例を示す図である。同図において示されているように、Ａ社の契約担当者であるＡ１は、Ｂ社の契約担当者であるＢ１と契約内容素案を取りまとめたのち、自社内の稟議のため、当該素案をＡ２ないしＡ６に回覧し決裁を求める（Ｂ社内においても同様の稟議フローが生じる）。Ａ１は、これらの稟議フローがすべて実行された場合においてのみ、Ｂ１に対し、契約締結のためのコンピュータ処理の実行を依頼できるようになる。Ｂ１においても同様のフローが採用されることで、Ａ社Ｂ社ともに契約締結フローに瑕疵がないことをコンピュータ上で記録することができ、本システムを採用することで、社内の稟議フローの管理と、社外との契約締結フローとを、一気通貫で管理することが可能になる。

以下、本発明の各実施形態について図面とともに説明する。まず実施形態と請求項の相互の関係は、以下のとおりである。まず、実施形態１は、主に請求項１、２、５、６などに対応する。実施形態２は、主に請求項３などに対応する。実施形態３は、主に請求４などに対応する。なお、本発明はこれらの実施形態に何ら限定されるものではなく、技術常識に従って特許請求の範囲の各請求項に記載の技術的思想を有し、その要旨を逸脱しない範囲内において、様々な態様で実施し得る。

＜＜実施形態１＞＞
＜概要＞
図２は、本実施形態の契約締結方法を一のシステムにて実現する場合の機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「契約締結システム」０２００は、「契約データ入力部」０２０１と、「ＩＤ入力受付部」０２０２と、「可否判断部」０２０３と、「契約締結部」０２０４と、を有する。

なお、以下で詳しく説明する契約締結システムは、その機能の一又は複数の機能を複数の装置にて実現するようにも構成され得るものであって、その機能ブロックは、いずれもハードウェア又はソフトウェアとして実現され得る。コンピュータを用いるものを例にすれば、ＣＰＵやメインメモリ、ＧＰＵ、ＴＰＵ、画像メモリ、バス、二次記憶装置（ハードディスクや不揮発性メモリ）、キーボードや操作ボタン、タッチパネル、タッチパネルをタッチするための電子ペンなどの各種入力デバイス、マイク、ディスプレイその他各種出力デバイス、その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のインターフェース、通信用インターフェース、それらのハードウェアを制御するためのドライバプログラムやその他のアプリケーションプログラムなどが挙げられる。

これらの装置は、一の事業者内部でのみ用いられる場合もあれば、複数の事業者間で用いられる場合もある。すなわち、稟議フローに関する処理は通常、一の事業者内部でのみ実行されるが、契約締結フローに関する処理は通常、複数の事業者間で実行される。

そして各々の装置のメインメモリ上に展開したプログラムに従った演算処理によって、入力デバイスやその他インターフェースなどから入力されメモリやハードウェア上に保持されているデータなどが加工、蓄積されたり、前記各ハードウェアやソフトウェアを制御するための命令が生成されたりする。ここで、上記プログラムは、モジュール化された複数のプログラムとして実現されてもよいし、２以上のプログラムを組み合わせて一のプログラムとして実現されても良い。クラウドコンピューティングの形式にて分散処理されてももちろんよいし、ＡＰＩ連携の形式にて複数の事業者間にまたがって提供される複数のプログラムによって実行処理されてもよい。

＜機能的構成＞
「契約データ入力受付部」０２０１は、契約データの入力を受け付けるように構成されている。ここでいう契約データとは、契約書の文書データであることもあれば、特定の契約内容を識別するためのＩＤのような情報であってもよい。この場合には、特定の契約内容を示すデータは、本システムの外部又は内部の別の機能により保持保管されることとなる。特定の契約内容が記録されている契約書の文書データを用いない構成をも採用可能とすることにより、図１を用いて説明した例の場合で言えば、Ａ１又はＢ１が本機能を利用する際に、徒に契約内容が外部に漏出するリスクを低減することができる。

「ＩＤ入力受付部」０２０２は、契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付けるように構成されている。ここでいう契約当事者とは、事業者間で契約を締結する場合には当該事業者を識別するためのＩＤである。

ここで、契約当事者ＩＤは、一の事業者にとっては契約相手方を識別するためのＩＤということになり、図１を用いて説明した例の場合で言えば、Ａ１ないしＡ社にとっては、Ｂ社を識別するためのＩＤの入力を受け付けるように構成される。当該構成を採用することにより、特定の事業者との契約締結管理を容易に行うことができる。

契約当事者ＩＤの入力態様については、契約データの入力を受け付ける際に都度契約当事者ＩＤの入力を直接入力する態様が一例として考えられるが、あらかじめ一又は複数の契約当事者ＩＤを記録しておき、検索及び選択処理により特定の契約当事者ＩＤを抽出したうえでその入力を受け付けるような構成であることが望ましい。継続的に取引する可能性のある事業者であれば、過去の契約締結状況なども踏まえた契約管理が求められる場合もあるところ、当該構成を採用すれば、契約当事者ＩＤ入力を受け付けることで、当該ＩＤと紐づけて管理される他の契約情報を種々の管理フローに利用することができ、より効果的な契約管理を行うことができるようになる。

なおここで、契約当事者ＩＤとして自らを識別するためのＩＤの入力を受け付ける場合もありうるが、当該処理はＩＤ入力受付部における機能として構成する必要はない。例えば、本実施形態にかかる契約締結システムの利用を開始するためのログイン処理の場合などに利用事業者のＩＤ入力を受け付ける形式により、当該利用者の契約当事者ＩＤ入力を受け付けることが考えられる。

そして契約当事者ＩＤの入力に関連して、「利用事業者のＩＤ入力を受け付ける形式」の具体例についていうと、利用事業者内の複数の利用者を識別するためのＩＤである利用事業者内利用者ＩＤの入力を受け付ける構成も考えられる。図１を用いて説明した例の場合で言えば、Ａ１ないしＡ６、Ｂ１ないしＢ４をそれぞれ識別するためのＩＤがここでいう利用事業者内利用者ＩＤに該当する。利用事業者内利用者ＩＤをそのまま契約当事者ＩＤとして用いてもよいし、特定の契約当事者ＩＤと紐づけて一又は複数の利用事業者内利用者ＩＤを用いてもよい。当該情報を取得することにより、後述する契約締結検討状況の管理をより機能的に行うことが可能になる。

「可否判断部」０２０３は、ＩＤ入力受付部にて受け付けた契約当事者における契約データ入力受付部にて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断するＩＤ入力受付部にて受け付けた契約当事者の契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断するように構成されている。

検討ステータスは、例えば、特定の契約内容に関する契約当事者内での稟議の状況に応じて選択特定される情報であって、随時個々の利用事業者内利用者の管理する端末から送信され、変更され、更新されうる。具体的には、すべての決裁担当者における決裁が完了したか否かを示す情報である場合もあれば、当該決裁においてどのような留意すべき点があるかを示す具体的な情報を含む場合もある。個々の決裁担当者を識別するための利用事業者内利用者ＩＤや、それらの決裁担当者が決裁処理を行った順番や日時等の情報をも含めてもよい。当該構成を採用すれば、決裁担当者ごとの決裁処理状況の把握もできる。例えば、契約締結に先立ち気になる点につき、本システム上で疑問点の質問や回答、決裁処理に必要となる補足情報の添付、当該契約相手方や他事業者と過去に行った同種又は他種契約締結の顛末に関する情報の参照といった処理をも行うことが可能となる。さらに、かかる種々の処理が決裁処理の過程で行われたこと自体を記録することができるため、検討ステータスを以後の契約締結処理の際のナレッジとして活用することも可能になる。

なお可否判断部では、検討ステータスに応じて契約締結可否を判断するように構成されているが、ここでいう「契約締結可否を判断する」とは、個別具体的な契約の内容を踏まえた契約締結の可否を判断する処理までは要しない。すなわち、検討ステータスが最低限求められる稟議フローを経ていることを示す情報を含んでいる場合には、当該契約の内容を参照することなく契約締結が可能と判断してよい。

ただもちろん、可否判断部において、契約内容の当否を判定するような機能を設けることも考えられる。より具体的には、検討ステータスの内容に応じて、過去の契約締結事例と比較処理したりすることにより契約締結可否を判断することが考えられる。過去の契約締結事例については、当該契約当事者者ＩＤ（利用事業者内利用者ＩＤである場合も含まれる）と紐づいて管理されるあらゆる契約締結事例である場合や、本システムを利用する他の契約当事者ＩＤにて識別される契約当事者の契約締結事例である場合があってもよい。それらの情報を機械学習その他の手段によって学習したうえで所定の学習モデルを生成し、当該学習モデルを用いて契約締結可否を判断する構成を採用することにより、図１を用いた例の場合でいえば、Ａ１やＢ１が契約締結業務に精通していない場合であっても、当該検討ステータスを参照し安心して契約締結処理を進めることができるようになる。

なおここで、検討ステータスの内容は、適宜利用者が確認できるように出力されることが望ましい。出力態様に特に限定を設ける必要はないが、具体的には、契約締結検討状況として、決裁段階における懸念点や懸念解消のための施策案、当該懸念や施策案を表明した決裁権者、決裁日時等が出力されることが望ましい。当該構成を採用すれば、利用者は可否判断部の判断結果が契約締結不可という判断結果である場合において、どのような対処が必要かを速やかに判断し、事業者内部で調整したり、契約相手方と擦り合わせを実行したりすることが可能になる。なお、ここでいう事業者内部の調整や、契約相手方との擦り合わせに関する情報も、当該検討ステータスとして又は検討ステータスと紐づけて保持することにより、当該情報をナレッジとして以後の契約管理の際に活用することが可能になる。

「契約締結部」０２０４は、可否判断部の判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行するように構成されている。ここでいう契約締結処理とは、たとえば、契約相手方に対し契約締結を実行する処理であることが考えられ、具体的には、所定の契約データにつき、契約締結の意思がある旨の情報である申込情報を、特定の契約当事者ＩＤにて識別される事業者ないし当該事業者の担当者に送信し、当該送信に対応し同じく契約締結の意思がある旨の情報である承諾情報を受信する処理を行う。このように、契約締結前の稟議フローの結果を踏まえてそのまま契約締結処理が実行できる構成を採用することにより、一連の契約締結経過を一気通貫で管理できるだけでなく、契約締結までの処理を契約担当者においてスムーズに行うことができる。

なおここでいう「契約締結処理を実行する」とは、上述した申込情報の送信と承諾情報の受信とが機能として備えられていればよく、より具体的に、申込情報と承諾情報とを相互に管理する機能まで備えておく必要はない。本発明は、少なくとも一の事業者内部における契約締結管理の便宜に関するものであり、その限りにおいて必要な情報として申込所法の送信と承諾情報の受信とが、特定の契約データを紐づけられ管理可能であればよいからである。

ただしかし、上記のような要請を超え、本発明に付随して、契約相手方との契約締結に関する具体的な情報をも記録管理する構成があってももちろんよい。具体的には、契約締結部において、締結日時を記録するタイムスタンプ付与手段をさらに備えるような構成を採用してもよい。具体的には、申込情報が送信された日時、承諾情報を受信した日時をともに記録し、当該情報にタイムスタンプを付与する電磁的処理を施すとともに、当該情報を記録することが考えられる。付与されたタイムスタンプに関する情報は、契約当事者双方に対して通知される。

さらにタイムスタンプに限らず、当該契約データの内容をもともに記録する構成があってもよい。この場合には契約データは上述した特定の契約内容を識別するためのＩＤのような情報ではなく、契約書の内容を把握可能な文書データにて又は当該契約内容を適宜の技術を用いてコントラクトコード化したうえで記録することとなる。当該情報は、利用者の管理する端末で記録される場合のほか、第三者の管理する端末（クラウドサーバを含む。）又は複数の端末にて分散管理される場合が考えられる。当該構成を採用すれば、万が一当該契約内容に疑義が生じたり、契約内容に関する紛争が生じたりした場合においても、契約内容の証明ないし実行を円滑に行うことができるようになる。

＜具体的な構成＞
ここで図３を示す。同図は本実施形態の契約締結システムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図である。各装置はいずれも、それぞれ各種演算処理を実行するための「ＣＰＵ」０３０１と、「記憶装置（記憶媒体）」０３０２と、「メインメモリ」０３０３と、「入力インターフェース」０３０４、「出力インターフェース」０３０５、「ネットワークインターフェース」０３０６と、を備え、入出力インターフェースを介して、例えば「タッチパネル」０３０７や「ディスプレイ」０３０８などの外部周辺装置と情報の送受信を行う。また、ネットワークインターフェースを介して「契約相手方端末」０３０９や他の「利用事業者内利用者端末」０３１０などの外部装置と情報の送受信を行う。このネットワークインターフェースの具体的な態様は有線、無線を問わず、また、通信方法も直接、間接を問わない。よって特定の外部装置ないし同装置の利用者と紐づけられた第三者の管理するサーバとの間で情報の送受信を行ういわゆるクラウドコンピューティングの形式を採用することも可能である。

記憶装置には以下で説明するような各種プログラムが格納されており、ＣＰＵはこれら各種プログラムをメインメモリのワーク領域内に読み出して展開、実行する。なお、これらの構成は、「システムバス」０３９９などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う（以上の構成の基本的な構成は、以下で説明する他の装置のいずれについても同様である。

（契約データ入力受付部の具体的な構成）
契約データ入力受付部は、コンピュータプログラムとコンピュータハードウェアにより構成され、端末から契約データの入力を受け付けるように構成されている。具体的には、ＣＰＵが記憶装置から「契約データ入力受付プログラム」０３１１をメインメモリに読み出して実行し、端末から契約データのアップロードを受け付けたり、特定の契約書を識別するためのＩＤの入力を受け付けたりすると、当該入力受付した内容を所定単位ごとに定められたアドレスに格納する。契約データは、本発明の作用であるか否かを問わず、内部あるいは外部の端末から書込まれあるいは作成され、変更されうる。

（ＩＤ入力受付部の具体的な構成）
ＩＤ入力受付部は、コンピュータプログラムとコンピュータハードウェアにより構成され、端末から契約当事者ＩＤの入力を受け付けるように構成されている。具体的には、ＣＰＵが記憶装置から「ＩＤ入力受付プログラム」０３１２をメインメモリに読み出して実行し、端末から契約当事者ＩＤの入力を受け付けたり、あらかじめ格納されている一又は複数の契約当事者ＩＤの中から所定の契約当事者ＩＤの検索又は選択処理を受け付けたりすると、当該入力受付した内容を所定単位ごとに定められたアドレスに格納する。

（可否判断部の具体的な構成）
可否判断部は、コンピュータプログラムとコンピュータハードウェアにより構成され、外部端末から契約書面の入力を受け付けるように構成されている。具体的には、契約データ入力受付プログラムの実行により受け付けた契約データと、ＩＤ入力受付プログラムの実行により受け付けた契約当事者とを読み出しＣＰＵが記憶装置から「可否判断プログラム」０３１３をメインメモリに読み出して実行し、個々の利用事業者内利用者の管理する端末からの入力を通じて保持する検討ステータスをメモリの所定のアドレスから読み出し、当該検討ステータスに応じて前記契約データの締結可否の判断処理を実行し、当該処理結果をメインメモリの所定のアドレスに格納する。

（契約締結部の具体的な構成）
契約締結部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成されている。具体的には、ＣＰＵが記憶装置から「契約締結プログラム」０３１４をメインメモリに読み出して実行し、可否判断プログラムの実行結果を読み出すとともに、当該実行結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する。

なおここで、契約締結プログラムの実行に際しては、当該実行に付随してタイムスタンプを付与する処理を行う場合もあり、この場合には、締結対象となる契約データとタイムスタンプとを紐づけて契約締結処理を実行する。

＜処理の流れ＞
図４は、本実施形態の契約締結システムにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０４０１では、契約データの入力を受け付ける（契約データ入力受付ステップ）。ステップＳ０４０２では、契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付ける（ＩＤ入力受付ステップ）。ここでステップＳ０４０１とステップＳ０４０２の順序は特に問わず、両者の順番が入れ替わってもよい。

そしてステップＳ０４０３では、ＩＤ入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断し（可否判断ステップ）、ここでの判断結果が契約締結可能との内容であれば、ステップＳ０４０４として契約締結処理を実行し（契約締結ステップ）、判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、再度の契約締結検討を促す処理を行う。なお契約締結処理においては、当該契約締結処理に対してタイムスタンプを付与する処理が行われる場合もある。

ここで図５を示す。同図は、本実施形態の契約締結システムを一の事業者内の複数の利用者、すなわち利用事業者内利用者で利用する場合の各利用者間における処理の流れの一例を示す図である。同図においては図１を用いて説明した例と同様の例に即して説明するものとし、その処理の流れは以下のステップからなる。まずステップＳ０５０１ではＢ１から契約データの入力を受け付ける（契約データ入力受付ステップ）。ステップＳ０５０２では、Ｂ１から契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付ける（ＩＤ入力受付ステップ）。ここでステップＳ０５０１とステップＳ０５０２の順序は特に問わず、両者の順番が入れ替わってもよい。

そしてステップＳ０５０３では、ＩＤ入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じてＢ１による契約締結可否を判断する（可否判断ステップ）。このとき可否判断ステップでの判断に先立って、ステップＳ０５９９として、一又は複数の利用事業者内利用者による稟議を経てＢ２ないしＢ４から種々の情報を取得し検討ステータスが生成され、保持され又は更新されている（検討ステータス生成ステップ）。なお同図では便宜上Ｂ社側の処理の流れを図示したが、Ａ社側においてももちろん同様の処理の流れを想定することができる。

そして可否判断ステップでの判断結果が契約締結可能との内容であれば、ステップＳ０５０４としてＢ１が契約締結処理を実行する（契約締結ステップ）。判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、Ｂ１に対し再度の契約締結検討を促す処理を行う。

次に図６を示す。同図は本実施形態の契約締結システムを契約当事者間で利用する場合の各利用者間における処理の流れの一例を示す図である。同図においては図１を用いて説明した例と同様の例に即して説明するものとし、その処理の流れは以下のステップからなる。まずステップＳ０６０１では、Ａ１（Ｂ１）により契約データの入力を受け付ける（契約データ入力受付ステップ）。ステップＳ０６０２では、Ａ１（Ｂ１）により契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付ける（ＩＤ入力受付ステップ）。ここでステップＳ０６０１とステップＳ０６０２の順序は特に問わず、両者の順番が入れ替わってもよい。

そしてステップＳ０６０３では、ＩＤ入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じてＡ１（Ｂ１）による契約締結可否を判断し（可否判断ステップ）、ここでの判断結果が契約締結可能との内容であれば、ステップＳ０６０４としてＡ１（Ｂ１）が契約締結処理を実行する（契約締結ステップ）。契約締結ステップの具体的な内容としては、Ａ１（Ｂ１）のいずれかから契約締結に関する申込情報を送信し、Ａ１又はＢ１のうち相手方となる当事者（同図の場合はＢ１）が当該申込情報を受信したのち承諾情報を送信する。申込情報を送信した当事者（同図の場合はＡ１）のもとで承諾情報を受信する。なお判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、Ａ１（Ｂ１）に対し、再度の契約締結検討を促す処理を行う。

＜効果＞
以上の構成を採用する契約締結システムを利用することにより、事業者内部の意思決定過程と、契約相手との契約締結過程とを、一気通貫で管理することができ、事後の検索や検証に資するようになる。

＜＜実施形態２＞＞
＜概要＞
本実施形態の契約締結方法は、基本的には実施形態１に記載の契約締結方法の技術的特徴と同様であるが、複数の契約当事者の検討ステータスを記録するとともに、記録された検討ステータスを用いて契約締結可否判断を行うことを更なる技術的特徴として備えている。以下では、実施形態１で言及した点とは異なる上記特徴について詳しく説明をする。

＜機能的構成＞
図７は、本実施形態の契約締結方法を一のシステムにて実現する場合の機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「契約締結システム」０７００は、「契約データ入力受付部」０７０１と、「ＩＤ入力受付部」０７０２と、「可否判断部」０７０３と、「契約締結部」０７０４と、「決裁処理利用記録部」０７０５と、を有し、可否判断部は「決裁状況判断利用手段」０７１３をさらに有する。基本的な構成は、実施形態１の図２を用いて説明した契約締結システムと共通するため、以下では相違点である「決裁処理利用記録部」０７０５及び「決裁状況判断利用手段」０７１３の機能について説明する。

「決裁処理利用記録部」０７０５は、複数の契約当事者の検討ステータスを記録するように構成されている。ここでいう複数の契約当事者とは、いわゆる契約相手方のことをいい、図１を用いて説明した例の場合であればＡ社とＢ社のことをいう。契約当事者が複数にわたる場合には、当該契約当事者のすべての検討ステータスが記録可能である。

なお本実施形態においては、検討ステータスを構成する種々の情報につき、当該検討を行う契約当事者にて、それぞれ複数の契約当事者に対して公開可能か否かの選択が可能であることが望ましい。検討ステータスの内容としては事業者内で秘匿すべき事項もあれば、積極的に契約相手方に伝えたい事項もありその性質は様々にありうるところである。そのような性質に応じた公開選択が可能な構成を採用することで、検討ステータスの効果的な管理と活用が可能になる。

「決裁状況判断利用手段」０７１３は、可否判断部において、決裁処理利用記録部にて記録された検討ステータスを用いて契約締結可否を判断するように構成されている。具体的な判断処理の態様としては、他の契約当事者の検討ステータスの内容が契約締結可という内容であるかどうかを、自身においても契約締結可との判断材料に用いる場合もあれば、契約ステータスの内容として、特定の懸念事項や留意事項、要望事項等が含まれている場合には、当該事項を踏まえて契約締結可否の判断を行う。

ちなみに、上述のとおり検討ステータスについては、公開するか否かを選択可能に構成することができるほか、複数の契約当事者のすべての契約当事者の検討ステータスが記録可能とも限らない。したがって決裁状況判断利用手段においては、記録された検討ステータスのうち、利用可能と識別できる情報のみを用いて契約締結可否を判断するように構成されていればよい。

なおここで、決裁状況判断利用手段においては、契約締結可否判断を行うのみでなく、当該可否破断の結果を、契約相手方に通知する機能をさらに備えてもよい。上述のように契約ステータスの内容として各種事項が含まれている場合には、当該事項に対応した回答を、契約締結可否判断とともに通知する構成をとることが考えられ、当該通知を受領した契約相手方は、スムーズな契約締結のために是正対応すべき事項が明確になるため、結果として契約締結のための調整が必要となる場合であっても、従前の経緯を踏まえたスムーズな処理が可能になる。

＜具体的な構成＞
本実施形態の契約締結システムを構成する各装置のハードウェア構成は、基本的には、図３を用いて説明した実施形態１の契約締結システムにおけるハードウェア構成と同様である。そこで以下については、これまで説明していない「決裁処理利用記録部」及び「決裁状況判断利用手段」の具体的な処理について説明する。

（決裁処理利用記録部の具体的な構成）
決裁処理利用記録部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、ＣＰＵが記憶装置から「決裁処理利用記録プログラム」をメインメモリに読み出して実行し、複数の契約当事者の検討ステータスをそれぞれ取得し、メインメモリの所定のアドレスに管理する。このとき個々の検討ステータスについては、検討ステータスを構成する種々の情報につき、公開可否の選択を受け付ける処理を行う場合もある。

（決裁状況判断利用手段の具体的な構成）
決裁状況判断利用手段は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、可否判断プログラムの実行に際してＣＰＵが記憶装置から「決裁状況判断利用サブプログラム」をメインメモリに読み出して実行し、決裁処理利用記録ステップにて記録された複数の契約当事者の検討ステータスを読み出して、当該検討ステータスに応じて契約データの締結可否の判断処理を実行し、当該処理結果をメインメモリの所定のアドレスに格納する。

＜処理の流れ＞
図８は、本実施形態の契約締結システムにおける処理の流れの一例を示す図である。同図は本実施形態の契約締結システムを契約当事者間で利用する場合の各利用者間における処理の流れの一例を示す図である。同図においては図１を用いて説明した例と同様の例に即して説明するものとし、その処理の流れは以下のステップからなる。まずステップＳ０８００では、一又は複数の利用事業者内利用者による稟議を経てＡ及びＢにおいてそれぞれ検討ステータスが生成され、記録されている（決裁処理利用記録ステップ）。そしてステップＳ０８０１では、Ａ１（Ｂ１）により契約データの入力を受け付ける（契約データ入力受付ステップ）。ステップＳ０８０２では、Ａ１（Ｂ１）により契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付ける（ＩＤ入力受付ステップ）。ここでステップＳ０８０１とステップＳ０８０２の順序は特に問わず、両者の順番が入れ替わってもよい。

そしてステップＳ０８０３では、ＩＤ入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスのうち決裁処理利用記録ステップにて記録された検討ステータスを用いてＡ１（Ｂ１）による契約締結可否を判断する（可否判断ステップ）。ここでの判断結果が契約締結可能との内容であれば、ステップＳ０８０４としてＡ１（Ｂ１）が契約締結処理を実行し（契約締結ステップ）、判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、再度の契約締結検討を促す処理を行う。

＜効果＞
本実施形態の契約締結システムを用いることにより、実施形態１の契約締結システムを用いる場合に比べ、相手方の決裁状況を把握できることで、より安心して契約締結処理を進めることができるようになる。

＜＜実施形態３＞＞
＜概要＞
本実施形態の契約締結システムは、基本的には実施形態１又は２に記載の契約締結システムの技術的特徴と同様であるが、検討ステータスと紐づけられた通知先の情報を取得し、契約締結処理が行われた場合に、取得した通知先に締結処理に関する通知を出力する点を更なる技術的特徴として備えている。以下では、実施形態１及び２で言及した点とは異なる上記特徴について詳しく説明をする。

＜機能的構成＞
図９は、本実施形態の契約締結システムを一のコンピュータ（装置）で実現した場合の機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「契約締結システム」０９００は、「契約データ入力受付部」０９０１と、「ＩＤ入力受付部」０９０２と、「可否判断部」０９０３と、「契約締結部」０９０４と、「通知先情報取得部」０９０５と、「通知出力部」０９０６をさらに有する。基本的な構成は、実施形態１の図２を用いて説明した契約締結システムと共通するため、以下では相違点である「通知先情報取得部」０９０５及び「通知出力部」０９０６の機能について説明する。

「通知先情報取得部」０９０５は、検討ステータスと紐づけられた通知先の情報を取得するように構成されている。ここでいう通知先とは、契約当事者あるいは、一又は複数の利用事業者内利用者の通知先のことを言い、「検討ステータスと紐づけられた」とは、事業者内の稟議フローと関連付けて通知先の情報が設定されることを意味する。具体的な通知手段は本システムを用いて出力されるメッセージ機能のほか、電子メールその他の手段を特に問わない。

また、通知先の情報として上述の通知先のほか、通知すべき利用事業者内利用者の特定又は優先順位、通知すべき契約種別、通知出力の態様等を含めることができる。かかる構成を採用することにより、事業者内の稟議フローに応じて契約締結の事実さえ確認できればいい決裁権者と、契約内容まで確認したい決裁権者、そもそも当該事実について子細に確認する必要のない決裁権者等、決裁権者ごとの要求に柔軟に対応することができる。

「通知出力部」０９０６は、契約締結部にて契約締結処理が行われた場合に、取得した通知先に締結処理に関する通知を出力するように構成されている。ここでの通知の出力は、上述した通知先の情報を踏まえて適宜の方法により行われることができ、当該通知先の情報にかかわらず、適宜契約締結担当者により設定することも可能である。当該構成を採用することにより、契約締結処理段階でイレギュラーな事象が生じた場合にも、本システムを用いることで当該事象の報告まで記録することができ、のちの契約管理を適切に実施すること可能になる。

＜具体的な構成＞
本実施形態の契約締結システムを構成する各装置のハードウェア構成は、基本的には、図３を用いて説明した実施形態１の契約締結システムにおけるハードウェア構成と同様である。そこで以下については、これまで説明していない「通知先情報取得部」及び「通知出力部」の具体的な処理について説明する。

（通知先情報取得部の具体的な構成）
通知先情報取得部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、ＣＰＵが記憶装置から「通知先情報取得プログラム」をメインメモリに読み出して実行し、通知先の情報を検討ステータスと対応させて取得しメインメモリの所定のアドレスに格納する。

（通知出力部の具体的な構成）
通知出力部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、契約締結プログラムの実行により所定の処理が実行されると、ＣＰＵが記憶装置から「通知出力プログラム」をメインメモリに読み出して実行し、通知先情報取得プログラムの実行により取得していた情報をメインメモリに読み出し、当該情報に対応した通知先に対し、締結処理に関する通知を出力する

＜処理の流れ＞
図１０は、本実施形態の契約締結システムにおける処理の流れの一例を示す図である。同図は本実施形態の契約締結システムを契約当事者間で利用する場合の各利用者間における処理の流れの一例を示す図である。同図においては図１を用いて説明した例と同様の例に即して説明するものとし、その処理の流れは以下のステップからなる。まずステップＳ１０００では、検討ステータスと紐づけられた通知先の情報を取得する（通知先情報取得ステップ）。そしてステップＳ１００１では、Ａ１又はＢ１により契約データの入力を受け付ける（契約データ入力受付ステップ）。ステップＳ１００２では、Ａ１又はＢ１により契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付ける（ＩＤ入力受付ステップ）。ここでステップＳ１００１とステップＳ１００２の順序は特に問わず、両者の順番が入れ替わってもよい。

そしてステップＳ１００３では、ＩＤ入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスのうち決裁処理利用記録ステップにて記録された検討ステータスを用いてＡ１又はＢ１による契約締結可否を判断する（可否判断ステップ）。ここでの判断結果が契約締結可能との内容であれば、ステップＳ１００４としてＡ１又はＢ１が契約締結処理を実行し（契約締結ステップ）、ステップＳ１００５として、あらかじめ通知先情報取得ステップにて取得した通知先に締結処理に関する通知を出力する（通知出力ステップ）。判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、再度の契約締結検討を促す処理を行う。

＜効果＞
本実施形態の契約締結システムを用いることにより、実施形態１又は２の契約締結システムを用いる場合に比べ、事業者内の稟議に関与した契約締結者以外の者に対しても、契約締結管理をしやすい環境を提供できるようになる。

０２００・・・契約締結システム、０２０１・・・契約データ入力受付部、０２０２・・・ＩＤ入力受付部、０２０３・・・可否判断部、０２０４・・・契約締結部

Claims

契約データの入力を受け付ける契約データ入力受付ステップと、
契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付けるＩＤ入力受付ステップと、
ＩＤ入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断ステップと、
可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する契約締結ステップと、
をコンピュータにて実行する契約締結方法。
契約締結ステップは、締結日時を記録するタイムスタンプ付与サブステップをさらに有する請求項１に記載の契約締結方法。
複数の契約当事者の検討ステータスを記録する決裁処理利用記録ステップを更に有し、
可否判断ステップは、決裁処理利用記録ステップにて記録された検討ステータスを用いる決裁状況判断利用サブステップをさらに有する請求項１又は２に記載の契約締結方法。
検討ステータスと紐づけられた通知先の情報を取得する通知先情報取得ステップと、
契約締結ステップにて契約締結処理が行われた場合に、取得した通知先に締結処理に関する通知を出力する通知出力ステップをさらに有する請求項１から３のいずれか一に記載の契約締結方法。
契約データの入力を受け付ける契約データ入力受付ステップと、
契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付けるＩＤ入力受付ステップと、
ＩＤ入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断ステップと、
可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する契約締結ステップと、
をコンピュータに実行させる契約締結プログラム。
契約データの入力を受け付ける契約データ入力受付部と、
契約当事者を識別するＩＤである契約当事者ＩＤの入力を受け付けるＩＤ入力受付部と、
ＩＤ入力受付部にて受け付けた契約当事者における契約データ入力受付部にて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断部と、
可否判断部の判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する契約締結部と、
を有する契約締結システム。