IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社Donutsの特許一覧

特開2022-6818契約締結方法、契約締結プログラム及び契約締結システム
<>
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図1
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図2
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図3
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図4
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図5
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図6
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図7
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図8
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図9
  • 特開-契約締結方法、契約締結プログラム及び契約締結システム 図10
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022006818
(43)【公開日】2022-01-13
(54)【発明の名称】契約締結方法、契約締結プログラム及び契約締結システム
(51)【国際特許分類】
   G06Q 10/00 20120101AFI20220105BHJP
【FI】
G06Q10/00
【審査請求】有
【請求項の数】6
【出願形態】OL
(21)【出願番号】P 2020109317
(22)【出願日】2020-06-25
【新規性喪失の例外の表示】新規性喪失の例外適用申請有り
(71)【出願人】
【識別番号】712005584
【氏名又は名称】株式会社Donuts
(74)【代理人】
【識別番号】230116539
【弁護士】
【氏名又は名称】恩田 俊明
(72)【発明者】
【氏名】西村 啓成
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049AA20
(57)【要約】      (修正有)
【課題】事業者内部の意思決定過程と、契約相手との契約締結過程とを一気通貫で管理することができ、事後の検索や検証に資するようになる契約締結方法、契約締結プログラム及び契約締結システムを提供する。
【解決手段】契約締結システムは、契約データの入力を受け付ける契約データ入力受付ステップと、契約当事者を識別するIDである契約当事者IDの入力を受け付けるID入力受付ステップと、ID入力受付ステップにて受け付けた契約当事者の契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断ステップと、可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する。
【選択図】図4
【特許請求の範囲】
【請求項1】
契約データの入力を受け付ける契約データ入力受付ステップと、
契約当事者を識別するIDである契約当事者IDの入力を受け付けるID入力受付ステップと、
ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断ステップと、
可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する契約締結ステップと、
をコンピュータにて実行する契約締結方法。
【請求項2】
契約締結ステップは、締結日時を記録するタイムスタンプ付与サブステップをさらに有する請求項1に記載の契約締結方法。
【請求項3】
複数の契約当事者の検討ステータスを記録する決裁処理利用記録ステップを更に有し、
可否判断ステップは、決裁処理利用記録ステップにて記録された検討ステータスを用いる決裁状況判断利用サブステップをさらに有する請求項1又は2に記載の契約締結方法。
【請求項4】
検討ステータスと紐づけられた通知先の情報を取得する通知先情報取得ステップと、
契約締結ステップにて契約締結処理が行われた場合に、取得した通知先に締結処理に関する通知を出力する通知出力ステップをさらに有する請求項1から3のいずれか一に記載の契約締結方法。
【請求項5】
契約データの入力を受け付ける契約データ入力受付ステップと、
契約当事者を識別するIDである契約当事者IDの入力を受け付けるID入力受付ステップと、
ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断ステップと、
可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する契約締結ステップと、
をコンピュータに実行させる契約締結プログラム。
【請求項6】
契約データの入力を受け付ける契約データ入力受付部と、
契約当事者を識別するIDである契約当事者IDの入力を受け付けるID入力受付部と、
ID入力受付部にて受け付けた契約当事者における契約データ入力受付部にて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断部と、
可否判断部の判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する契約締結部と、
を有する契約締結システム。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、事業者内部での検討結果を踏まえた契約締結を行うためのシステム、同システムを動作させるための方法及びプログラムなどに関する。
【背景技術】
【0002】
事業者間で契約書を締結する際には通常、各当事者の担当者が契約内容について交渉し、まとまった交渉結果がそれぞれの事業者内部で稟議を経ることで検討され、決裁を得たうえで最終的な合意のための契約締結処理を行うる。
【0003】
このようなプロセスにおいては、契約主体が複数存在することは当然のことながら、それぞれの契約主体の内部においても複数の関係者が介在することが通常であるため、関係者ごとの契約締結に関するかかわり方の管理が大きな課題となってきた。
【0004】
そこで従来から、契約締結作業を効率化するための管理システムに関する種々の技術が開示されている。例えば特許文献1には、契約締結の申込みと承諾のやり取りを、通信ネットワークを介して実現する技術が開示されており、特許文献2には、契約締結を通信ネットワークを介して実現する際に当事者の真正の証明に用いられる電子署名に関する技術が開示されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2002-109218
【特許文献2】特開2014-127034
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、特許文献1に記載されている先行技術は、あくまで申込と承諾の意思表示がネットワーク上でやり取りされるだけで、当該意思が当事者の事業者内部で真正な手続を経て行われたものであるか不明確である。また、特許文献2に記載されている先行技術においても、意思表示をする者の真正は証明しうるものの、当該意思が、事業者内部の適正な意思決定過程を経たものかの担保がないという点において、契約管理のあり方として十分とは言い難い。
【0007】
このように、従来の契約締結フローにおいては、事業者内部の意思決定過程と、契約締結過程とが別々に管理されており、その管理方法や管理態様が異なっていたために、真に効率的な管理ができていたとはいいがたく、また、万が一問題が生じた場合の検証も容易に出来るとは言い難かった。
【課題を解決するための手段】
【0008】
以上のような課題を解決すべく、本発明は、契約データの入力を受け付ける契約データ入力受付ステップと、契約当事者を識別するIDである契約当事者IDの入力を受け付けるID入力受付ステップと、ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断する可否判断ステップと、可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する契約締結ステップと、をコンピュータにて実行する契約締結方法などを提案する。
【0009】
なお前記方法に関連して、契約締結ステップが締結日時を記録するタイムスタンプ付与サブステップをさらに有する契約締結方法なども提案する。
【0010】
また、前記方法に関連して、複数の契約当事者の検討ステータスを記録する決裁処理利用記録ステップを更に有し、可否判断ステップは、決裁処理利用記録ステップにて記録された検討ステータスを用いる決裁状況判断利用サブステップをさらに有する契約締結方法なども提案する。
【0011】
さらに前記方法に関連して、検討ステータスと紐づけられた通知先の情報を取得する通知先情報取得ステップと、契約締結ステップにて契約締結処理が行われた場合に、取得した通知先に締結処理に関する通知を出力する通知出力ステップをさらに有する契約締結方法なども提案する。
【0012】
そして、ここまで掲げてきた各方法をコンピュータで実現するためのプログラムや当該方法を用いたシステムなどについても提案する。
【発明の効果】
【0013】
主に以上のような構成をとる本発明によって、事業者内部の意思決定過程と、契約相手との契約締結過程とを一気通貫で管理することができ、事後の検索や検証に資するようになる。
【図面の簡単な説明】
【0014】
図1】本発明の契約締結システムの概要を示す図
図2】実施形態1の契約締結システムの機能ブロックの一例を示す図
図3】実施形態1の契約締結システムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図
図4】実施形態1の契約締結システムにおける処理の流れの一例を示す図
図5】実施形態1の契約締結システムにおける処理の別の流れの一例を示す図
図6】実施形態1の契約締結システムにおける処理の更に別の流れの一例を示す図
図7】実施形態2の契約締結システムの機能ブロックの一例を示す図
図8】実施形態2の契約締結システムにおける処理の流れの一例を示す図
図9】実施形態3の契約締結システムの機能ブロックの一例を示す図
図10】実施形態3の契約締結システムにおける処理の流れの一例を示す図
【発明を実施するための形態】
【0015】
まず図1を示す。図1は本発明の概要を示す図で、A社とB社とが契約締結する場合の概要を示す一例を示す図である。同図において示されているように、A社の契約担当者であるA1は、B社の契約担当者であるB1と契約内容素案を取りまとめたのち、自社内の稟議のため、当該素案をA2ないしA6に回覧し決裁を求める(B社内においても同様の稟議フローが生じる)。A1は、これらの稟議フローがすべて実行された場合においてのみ、B1に対し、契約締結のためのコンピュータ処理の実行を依頼できるようになる。B1においても同様のフローが採用されることで、A社B社ともに契約締結フローに瑕疵がないことをコンピュータ上で記録することができ、本システムを採用することで、社内の稟議フローの管理と、社外との契約締結フローとを、一気通貫で管理することが可能になる。
【0016】
以下、本発明の各実施形態について図面とともに説明する。まず実施形態と請求項の相互の関係は、以下のとおりである。まず、実施形態1は、主に請求項1、2、5、6などに対応する。実施形態2は、主に請求項3などに対応する。実施形態3は、主に請求4などに対応する。なお、本発明はこれらの実施形態に何ら限定されるものではなく、技術常識に従って特許請求の範囲の各請求項に記載の技術的思想を有し、その要旨を逸脱しない範囲内において、様々な態様で実施し得る。
【0017】
<<実施形態1>>
<概要>
図2は、本実施形態の契約締結方法を一のシステムにて実現する場合の機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「契約締結システム」0200は、「契約データ入力部」0201と、「ID入力受付部」0202と、「可否判断部」0203と、「契約締結部」0204と、を有する。
【0018】
なお、以下で詳しく説明する契約締結システムは、その機能の一又は複数の機能を複数の装置にて実現するようにも構成され得るものであって、その機能ブロックは、いずれもハードウェア又はソフトウェアとして実現され得る。コンピュータを用いるものを例にすれば、CPUやメインメモリ、GPU、TPU、画像メモリ、バス、二次記憶装置(ハードディスクや不揮発性メモリ)、キーボードや操作ボタン、タッチパネル、タッチパネルをタッチするための電子ペンなどの各種入力デバイス、マイク、ディスプレイその他各種出力デバイス、その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のインターフェース、通信用インターフェース、それらのハードウェアを制御するためのドライバプログラムやその他のアプリケーションプログラムなどが挙げられる。
【0019】
これらの装置は、一の事業者内部でのみ用いられる場合もあれば、複数の事業者間で用いられる場合もある。すなわち、稟議フローに関する処理は通常、一の事業者内部でのみ実行されるが、契約締結フローに関する処理は通常、複数の事業者間で実行される。
【0020】
そして各々の装置のメインメモリ上に展開したプログラムに従った演算処理によって、入力デバイスやその他インターフェースなどから入力されメモリやハードウェア上に保持されているデータなどが加工、蓄積されたり、前記各ハードウェアやソフトウェアを制御するための命令が生成されたりする。ここで、上記プログラムは、モジュール化された複数のプログラムとして実現されてもよいし、2以上のプログラムを組み合わせて一のプログラムとして実現されても良い。クラウドコンピューティングの形式にて分散処理されてももちろんよいし、API連携の形式にて複数の事業者間にまたがって提供される複数のプログラムによって実行処理されてもよい。
【0021】
<機能的構成>
「契約データ入力受付部」0201は、契約データの入力を受け付けるように構成されている。ここでいう契約データとは、契約書の文書データであることもあれば、特定の契約内容を識別するためのIDのような情報であってもよい。この場合には、特定の契約内容を示すデータは、本システムの外部又は内部の別の機能により保持保管されることとなる。特定の契約内容が記録されている契約書の文書データを用いない構成をも採用可能とすることにより、図1を用いて説明した例の場合で言えば、A1又はB1が本機能を利用する際に、徒に契約内容が外部に漏出するリスクを低減することができる。
【0022】
「ID入力受付部」0202は、契約当事者を識別するIDである契約当事者IDの入力を受け付けるように構成されている。ここでいう契約当事者とは、事業者間で契約を締結する場合には当該事業者を識別するためのIDである。
【0023】
ここで、契約当事者IDは、一の事業者にとっては契約相手方を識別するためのIDということになり、図1を用いて説明した例の場合で言えば、A1ないしA社にとっては、B社を識別するためのIDの入力を受け付けるように構成される。当該構成を採用することにより、特定の事業者との契約締結管理を容易に行うことができる。
【0024】
契約当事者IDの入力態様については、契約データの入力を受け付ける際に都度契約当事者IDの入力を直接入力する態様が一例として考えられるが、あらかじめ一又は複数の契約当事者IDを記録しておき、検索及び選択処理により特定の契約当事者IDを抽出したうえでその入力を受け付けるような構成であることが望ましい。継続的に取引する可能性のある事業者であれば、過去の契約締結状況なども踏まえた契約管理が求められる場合もあるところ、当該構成を採用すれば、契約当事者ID入力を受け付けることで、当該IDと紐づけて管理される他の契約情報を種々の管理フローに利用することができ、より効果的な契約管理を行うことができるようになる。
【0025】
なおここで、契約当事者IDとして自らを識別するためのIDの入力を受け付ける場合もありうるが、当該処理はID入力受付部における機能として構成する必要はない。例えば、本実施形態にかかる契約締結システムの利用を開始するためのログイン処理の場合などに利用事業者のID入力を受け付ける形式により、当該利用者の契約当事者ID入力を受け付けることが考えられる。
【0026】
そして契約当事者IDの入力に関連して、「利用事業者のID入力を受け付ける形式」の具体例についていうと、利用事業者内の複数の利用者を識別するためのIDである利用事業者内利用者IDの入力を受け付ける構成も考えられる。図1を用いて説明した例の場合で言えば、A1ないしA6、B1ないしB4をそれぞれ識別するためのIDがここでいう利用事業者内利用者IDに該当する。利用事業者内利用者IDをそのまま契約当事者IDとして用いてもよいし、特定の契約当事者IDと紐づけて一又は複数の利用事業者内利用者IDを用いてもよい。当該情報を取得することにより、後述する契約締結検討状況の管理をより機能的に行うことが可能になる。
【0027】
「可否判断部」0203は、ID入力受付部にて受け付けた契約当事者における契約データ入力受付部にて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断するID入力受付部にて受け付けた契約当事者の契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断するように構成されている。
【0028】
検討ステータスは、例えば、特定の契約内容に関する契約当事者内での稟議の状況に応じて選択特定される情報であって、随時個々の利用事業者内利用者の管理する端末から送信され、変更され、更新されうる。具体的には、すべての決裁担当者における決裁が完了したか否かを示す情報である場合もあれば、当該決裁においてどのような留意すべき点があるかを示す具体的な情報を含む場合もある。個々の決裁担当者を識別するための利用事業者内利用者IDや、それらの決裁担当者が決裁処理を行った順番や日時等の情報をも含めてもよい。当該構成を採用すれば、決裁担当者ごとの決裁処理状況の把握もできる。例えば、契約締結に先立ち気になる点につき、本システム上で疑問点の質問や回答、決裁処理に必要となる補足情報の添付、当該契約相手方や他事業者と過去に行った同種又は他種契約締結の顛末に関する情報の参照といった処理をも行うことが可能となる。さらに、かかる種々の処理が決裁処理の過程で行われたこと自体を記録することができるため、検討ステータスを以後の契約締結処理の際のナレッジとして活用することも可能になる。
【0029】
なお可否判断部では、検討ステータスに応じて契約締結可否を判断するように構成されているが、ここでいう「契約締結可否を判断する」とは、個別具体的な契約の内容を踏まえた契約締結の可否を判断する処理までは要しない。すなわち、検討ステータスが最低限求められる稟議フローを経ていることを示す情報を含んでいる場合には、当該契約の内容を参照することなく契約締結が可能と判断してよい。
【0030】
ただもちろん、可否判断部において、契約内容の当否を判定するような機能を設けることも考えられる。より具体的には、検討ステータスの内容に応じて、過去の契約締結事例と比較処理したりすることにより契約締結可否を判断することが考えられる。過去の契約締結事例については、当該契約当事者者ID(利用事業者内利用者IDである場合も含まれる)と紐づいて管理されるあらゆる契約締結事例である場合や、本システムを利用する他の契約当事者IDにて識別される契約当事者の契約締結事例である場合があってもよい。それらの情報を機械学習その他の手段によって学習したうえで所定の学習モデルを生成し、当該学習モデルを用いて契約締結可否を判断する構成を採用することにより、図1を用いた例の場合でいえば、A1やB1が契約締結業務に精通していない場合であっても、当該検討ステータスを参照し安心して契約締結処理を進めることができるようになる。
【0031】
なおここで、検討ステータスの内容は、適宜利用者が確認できるように出力されることが望ましい。出力態様に特に限定を設ける必要はないが、具体的には、契約締結検討状況として、決裁段階における懸念点や懸念解消のための施策案、当該懸念や施策案を表明した決裁権者、決裁日時等が出力されることが望ましい。当該構成を採用すれば、利用者は可否判断部の判断結果が契約締結不可という判断結果である場合において、どのような対処が必要かを速やかに判断し、事業者内部で調整したり、契約相手方と擦り合わせを実行したりすることが可能になる。なお、ここでいう事業者内部の調整や、契約相手方との擦り合わせに関する情報も、当該検討ステータスとして又は検討ステータスと紐づけて保持することにより、当該情報をナレッジとして以後の契約管理の際に活用することが可能になる。
【0032】
「契約締結部」0204は、可否判断部の判断結果が契約締結可能との判断結果である場合に限り契約締結処理を実行するように構成されている。ここでいう契約締結処理とは、たとえば、契約相手方に対し契約締結を実行する処理であることが考えられ、具体的には、所定の契約データにつき、契約締結の意思がある旨の情報である申込情報を、特定の契約当事者IDにて識別される事業者ないし当該事業者の担当者に送信し、当該送信に対応し同じく契約締結の意思がある旨の情報である承諾情報を受信する処理を行う。このように、契約締結前の稟議フローの結果を踏まえてそのまま契約締結処理が実行できる構成を採用することにより、一連の契約締結経過を一気通貫で管理できるだけでなく、契約締結までの処理を契約担当者においてスムーズに行うことができる。
【0033】
なおここでいう「契約締結処理を実行する」とは、上述した申込情報の送信と承諾情報の受信とが機能として備えられていればよく、より具体的に、申込情報と承諾情報とを相互に管理する機能まで備えておく必要はない。本発明は、少なくとも一の事業者内部における契約締結管理の便宜に関するものであり、その限りにおいて必要な情報として申込所法の送信と承諾情報の受信とが、特定の契約データを紐づけられ管理可能であればよいからである。
【0034】
ただしかし、上記のような要請を超え、本発明に付随して、契約相手方との契約締結に関する具体的な情報をも記録管理する構成があってももちろんよい。具体的には、契約締結部において、締結日時を記録するタイムスタンプ付与手段をさらに備えるような構成を採用してもよい。具体的には、申込情報が送信された日時、承諾情報を受信した日時をともに記録し、当該情報にタイムスタンプを付与する電磁的処理を施すとともに、当該情報を記録することが考えられる。付与されたタイムスタンプに関する情報は、契約当事者双方に対して通知される。
【0035】
さらにタイムスタンプに限らず、当該契約データの内容をもともに記録する構成があってもよい。この場合には契約データは上述した特定の契約内容を識別するためのIDのような情報ではなく、契約書の内容を把握可能な文書データにて又は当該契約内容を適宜の技術を用いてコントラクトコード化したうえで記録することとなる。当該情報は、利用者の管理する端末で記録される場合のほか、第三者の管理する端末(クラウドサーバを含む。)又は複数の端末にて分散管理される場合が考えられる。当該構成を採用すれば、万が一当該契約内容に疑義が生じたり、契約内容に関する紛争が生じたりした場合においても、契約内容の証明ないし実行を円滑に行うことができるようになる。
【0036】
<具体的な構成>
ここで図3を示す。同図は本実施形態の契約締結システムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図である。各装置はいずれも、それぞれ各種演算処理を実行するための「CPU」0301と、「記憶装置(記憶媒体)」0302と、「メインメモリ」0303と、「入力インターフェース」0304、「出力インターフェース」0305、「ネットワークインターフェース」0306と、を備え、入出力インターフェースを介して、例えば「タッチパネル」0307や「ディスプレイ」0308などの外部周辺装置と情報の送受信を行う。また、ネットワークインターフェースを介して「契約相手方端末」0309や他の「利用事業者内利用者端末」0310などの外部装置と情報の送受信を行う。このネットワークインターフェースの具体的な態様は有線、無線を問わず、また、通信方法も直接、間接を問わない。よって特定の外部装置ないし同装置の利用者と紐づけられた第三者の管理するサーバとの間で情報の送受信を行ういわゆるクラウドコンピューティングの形式を採用することも可能である。
【0037】
記憶装置には以下で説明するような各種プログラムが格納されており、CPUはこれら各種プログラムをメインメモリのワーク領域内に読み出して展開、実行する。なお、これらの構成は、「システムバス」0399などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う(以上の構成の基本的な構成は、以下で説明する他の装置のいずれについても同様である。
【0038】
(契約データ入力受付部の具体的な構成)
契約データ入力受付部は、コンピュータプログラムとコンピュータハードウェアにより構成され、端末から契約データの入力を受け付けるように構成されている。具体的には、CPUが記憶装置から「契約データ入力受付プログラム」0311をメインメモリに読み出して実行し、端末から契約データのアップロードを受け付けたり、特定の契約書を識別するためのIDの入力を受け付けたりすると、当該入力受付した内容を所定単位ごとに定められたアドレスに格納する。契約データは、本発明の作用であるか否かを問わず、内部あるいは外部の端末から書込まれあるいは作成され、変更されうる。
【0039】
(ID入力受付部の具体的な構成)
ID入力受付部は、コンピュータプログラムとコンピュータハードウェアにより構成され、端末から契約当事者IDの入力を受け付けるように構成されている。具体的には、CPUが記憶装置から「ID入力受付プログラム」0312をメインメモリに読み出して実行し、端末から契約当事者IDの入力を受け付けたり、あらかじめ格納されている一又は複数の契約当事者IDの中から所定の契約当事者IDの検索又は選択処理を受け付けたりすると、当該入力受付した内容を所定単位ごとに定められたアドレスに格納する。
【0040】
(可否判断部の具体的な構成)
可否判断部は、コンピュータプログラムとコンピュータハードウェアにより構成され、外部端末から契約書面の入力を受け付けるように構成されている。具体的には、契約データ入力受付プログラムの実行により受け付けた契約データと、ID入力受付プログラムの実行により受け付けた契約当事者とを読み出しCPUが記憶装置から「可否判断プログラム」0313をメインメモリに読み出して実行し、個々の利用事業者内利用者の管理する端末からの入力を通じて保持する検討ステータスをメモリの所定のアドレスから読み出し、当該検討ステータスに応じて前記契約データの締結可否の判断処理を実行し、当該処理結果をメインメモリの所定のアドレスに格納する。
【0041】
(契約締結部の具体的な構成)
契約締結部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成されている。具体的には、CPUが記憶装置から「契約締結プログラム」0314をメインメモリに読み出して実行し、可否判断プログラムの実行結果を読み出すとともに、当該実行結果が契約締結可能との判断結果である場合に限り契約締結処理を実行する。
【0042】
なおここで、契約締結プログラムの実行に際しては、当該実行に付随してタイムスタンプを付与する処理を行う場合もあり、この場合には、締結対象となる契約データとタイムスタンプとを紐づけて契約締結処理を実行する。
【0043】
<処理の流れ>
図4は、本実施形態の契約締結システムにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップS0401では、契約データの入力を受け付ける(契約データ入力受付ステップ)。ステップS0402では、契約当事者を識別するIDである契約当事者IDの入力を受け付ける(ID入力受付ステップ)。ここでステップS0401とステップS0402の順序は特に問わず、両者の順番が入れ替わってもよい。
【0044】
そしてステップS0403では、ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じて契約締結可否を判断し(可否判断ステップ)、ここでの判断結果が契約締結可能との内容であれば、ステップS0404として契約締結処理を実行し(契約締結ステップ)、判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、再度の契約締結検討を促す処理を行う。なお契約締結処理においては、当該契約締結処理に対してタイムスタンプを付与する処理が行われる場合もある。
【0045】
ここで図5を示す。同図は、本実施形態の契約締結システムを一の事業者内の複数の利用者、すなわち利用事業者内利用者で利用する場合の各利用者間における処理の流れの一例を示す図である。同図においては図1を用いて説明した例と同様の例に即して説明するものとし、その処理の流れは以下のステップからなる。まずステップS0501ではB1から契約データの入力を受け付ける(契約データ入力受付ステップ)。ステップS0502では、B1から契約当事者を識別するIDである契約当事者IDの入力を受け付ける(ID入力受付ステップ)。ここでステップS0501とステップS0502の順序は特に問わず、両者の順番が入れ替わってもよい。
【0046】
そしてステップS0503では、ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じてB1による契約締結可否を判断する(可否判断ステップ)。このとき可否判断ステップでの判断に先立って、ステップS0599として、一又は複数の利用事業者内利用者による稟議を経てB2ないしB4から種々の情報を取得し検討ステータスが生成され、保持され又は更新されている(検討ステータス生成ステップ)。なお同図では便宜上B社側の処理の流れを図示したが、A社側においてももちろん同様の処理の流れを想定することができる。
【0047】
そして可否判断ステップでの判断結果が契約締結可能との内容であれば、ステップS0504としてB1が契約締結処理を実行する(契約締結ステップ)。判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、B1に対し再度の契約締結検討を促す処理を行う。
【0048】
次に図6を示す。同図は本実施形態の契約締結システムを契約当事者間で利用する場合の各利用者間における処理の流れの一例を示す図である。同図においては図1を用いて説明した例と同様の例に即して説明するものとし、その処理の流れは以下のステップからなる。まずステップS0601では、A1(B1)により契約データの入力を受け付ける(契約データ入力受付ステップ)。ステップS0602では、A1(B1)により契約当事者を識別するIDである契約当事者IDの入力を受け付ける(ID入力受付ステップ)。ここでステップS0601とステップS0602の順序は特に問わず、両者の順番が入れ替わってもよい。
【0049】
そしてステップS0603では、ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスに応じてA1(B1)による契約締結可否を判断し(可否判断ステップ)、ここでの判断結果が契約締結可能との内容であれば、ステップS0604としてA1(B1)が契約締結処理を実行する(契約締結ステップ)。契約締結ステップの具体的な内容としては、A1(B1)のいずれかから契約締結に関する申込情報を送信し、A1又はB1のうち相手方となる当事者(同図の場合はB1)が当該申込情報を受信したのち承諾情報を送信する。申込情報を送信した当事者(同図の場合はA1)のもとで承諾情報を受信する。なお判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、A1(B1)に対し、再度の契約締結検討を促す処理を行う。
【0050】
<効果>
以上の構成を採用する契約締結システムを利用することにより、事業者内部の意思決定過程と、契約相手との契約締結過程とを、一気通貫で管理することができ、事後の検索や検証に資するようになる。
【0051】
<<実施形態2>>
<概要>
本実施形態の契約締結方法は、基本的には実施形態1に記載の契約締結方法の技術的特徴と同様であるが、複数の契約当事者の検討ステータスを記録するとともに、記録された検討ステータスを用いて契約締結可否判断を行うことを更なる技術的特徴として備えている。以下では、実施形態1で言及した点とは異なる上記特徴について詳しく説明をする。
【0052】
<機能的構成>
図7は、本実施形態の契約締結方法を一のシステムにて実現する場合の機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「契約締結システム」0700は、「契約データ入力受付部」0701と、「ID入力受付部」0702と、「可否判断部」0703と、「契約締結部」0704と、「決裁処理利用記録部」0705と、を有し、可否判断部は「決裁状況判断利用手段」0713をさらに有する。基本的な構成は、実施形態1の図2を用いて説明した契約締結システムと共通するため、以下では相違点である「決裁処理利用記録部」0705及び「決裁状況判断利用手段」0713の機能について説明する。
【0053】
「決裁処理利用記録部」0705は、複数の契約当事者の検討ステータスを記録するように構成されている。ここでいう複数の契約当事者とは、いわゆる契約相手方のことをいい、図1を用いて説明した例の場合であればA社とB社のことをいう。契約当事者が複数にわたる場合には、当該契約当事者のすべての検討ステータスが記録可能である。
【0054】
なお本実施形態においては、検討ステータスを構成する種々の情報につき、当該検討を行う契約当事者にて、それぞれ複数の契約当事者に対して公開可能か否かの選択が可能であることが望ましい。検討ステータスの内容としては事業者内で秘匿すべき事項もあれば、積極的に契約相手方に伝えたい事項もありその性質は様々にありうるところである。そのような性質に応じた公開選択が可能な構成を採用することで、検討ステータスの効果的な管理と活用が可能になる。
【0055】
「決裁状況判断利用手段」0713は、可否判断部において、決裁処理利用記録部にて記録された検討ステータスを用いて契約締結可否を判断するように構成されている。具体的な判断処理の態様としては、他の契約当事者の検討ステータスの内容が契約締結可という内容であるかどうかを、自身においても契約締結可との判断材料に用いる場合もあれば、契約ステータスの内容として、特定の懸念事項や留意事項、要望事項等が含まれている場合には、当該事項を踏まえて契約締結可否の判断を行う。
【0056】
ちなみに、上述のとおり検討ステータスについては、公開するか否かを選択可能に構成することができるほか、複数の契約当事者のすべての契約当事者の検討ステータスが記録可能とも限らない。したがって決裁状況判断利用手段においては、記録された検討ステータスのうち、利用可能と識別できる情報のみを用いて契約締結可否を判断するように構成されていればよい。
【0057】
なおここで、決裁状況判断利用手段においては、契約締結可否判断を行うのみでなく、当該可否破断の結果を、契約相手方に通知する機能をさらに備えてもよい。上述のように契約ステータスの内容として各種事項が含まれている場合には、当該事項に対応した回答を、契約締結可否判断とともに通知する構成をとることが考えられ、当該通知を受領した契約相手方は、スムーズな契約締結のために是正対応すべき事項が明確になるため、結果として契約締結のための調整が必要となる場合であっても、従前の経緯を踏まえたスムーズな処理が可能になる。
【0058】
<具体的な構成>
本実施形態の契約締結システムを構成する各装置のハードウェア構成は、基本的には、図3を用いて説明した実施形態1の契約締結システムにおけるハードウェア構成と同様である。そこで以下については、これまで説明していない「決裁処理利用記録部」及び「決裁状況判断利用手段」の具体的な処理について説明する。
【0059】
(決裁処理利用記録部の具体的な構成)
決裁処理利用記録部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、CPUが記憶装置から「決裁処理利用記録プログラム」をメインメモリに読み出して実行し、複数の契約当事者の検討ステータスをそれぞれ取得し、メインメモリの所定のアドレスに管理する。このとき個々の検討ステータスについては、検討ステータスを構成する種々の情報につき、公開可否の選択を受け付ける処理を行う場合もある。
【0060】
(決裁状況判断利用手段の具体的な構成)
決裁状況判断利用手段は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、可否判断プログラムの実行に際してCPUが記憶装置から「決裁状況判断利用サブプログラム」をメインメモリに読み出して実行し、決裁処理利用記録ステップにて記録された複数の契約当事者の検討ステータスを読み出して、当該検討ステータスに応じて契約データの締結可否の判断処理を実行し、当該処理結果をメインメモリの所定のアドレスに格納する。
【0061】
<処理の流れ>
図8は、本実施形態の契約締結システムにおける処理の流れの一例を示す図である。同図は本実施形態の契約締結システムを契約当事者間で利用する場合の各利用者間における処理の流れの一例を示す図である。同図においては図1を用いて説明した例と同様の例に即して説明するものとし、その処理の流れは以下のステップからなる。まずステップS0800では、一又は複数の利用事業者内利用者による稟議を経てA及びBにおいてそれぞれ検討ステータスが生成され、記録されている(決裁処理利用記録ステップ)。そしてステップS0801では、A1(B1)により契約データの入力を受け付ける(契約データ入力受付ステップ)。ステップS0802では、A1(B1)により契約当事者を識別するIDである契約当事者IDの入力を受け付ける(ID入力受付ステップ)。ここでステップS0801とステップS0802の順序は特に問わず、両者の順番が入れ替わってもよい。
【0062】
そしてステップS0803では、ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスのうち決裁処理利用記録ステップにて記録された検討ステータスを用いてA1(B1)による契約締結可否を判断する(可否判断ステップ)。ここでの判断結果が契約締結可能との内容であれば、ステップS0804としてA1(B1)が契約締結処理を実行し(契約締結ステップ)、判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、再度の契約締結検討を促す処理を行う。
【0063】
<効果>
本実施形態の契約締結システムを用いることにより、実施形態1の契約締結システムを用いる場合に比べ、相手方の決裁状況を把握できることで、より安心して契約締結処理を進めることができるようになる。
【0064】
<<実施形態3>>
<概要>
本実施形態の契約締結システムは、基本的には実施形態1又は2に記載の契約締結システムの技術的特徴と同様であるが、検討ステータスと紐づけられた通知先の情報を取得し、契約締結処理が行われた場合に、取得した通知先に締結処理に関する通知を出力する点を更なる技術的特徴として備えている。以下では、実施形態1及び2で言及した点とは異なる上記特徴について詳しく説明をする。
【0065】
<機能的構成>
図9は、本実施形態の契約締結システムを一のコンピュータ(装置)で実現した場合の機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「契約締結システム」0900は、「契約データ入力受付部」0901と、「ID入力受付部」0902と、「可否判断部」0903と、「契約締結部」0904と、「通知先情報取得部」0905と、「通知出力部」0906をさらに有する。基本的な構成は、実施形態1の図2を用いて説明した契約締結システムと共通するため、以下では相違点である「通知先情報取得部」0905及び「通知出力部」0906の機能について説明する。
【0066】
「通知先情報取得部」0905は、検討ステータスと紐づけられた通知先の情報を取得するように構成されている。ここでいう通知先とは、契約当事者あるいは、一又は複数の利用事業者内利用者の通知先のことを言い、「検討ステータスと紐づけられた」とは、事業者内の稟議フローと関連付けて通知先の情報が設定されることを意味する。具体的な通知手段は本システムを用いて出力されるメッセージ機能のほか、電子メールその他の手段を特に問わない。
【0067】
また、通知先の情報として上述の通知先のほか、通知すべき利用事業者内利用者の特定又は優先順位、通知すべき契約種別、通知出力の態様等を含めることができる。かかる構成を採用することにより、事業者内の稟議フローに応じて契約締結の事実さえ確認できればいい決裁権者と、契約内容まで確認したい決裁権者、そもそも当該事実について子細に確認する必要のない決裁権者等、決裁権者ごとの要求に柔軟に対応することができる。
【0068】
「通知出力部」0906は、契約締結部にて契約締結処理が行われた場合に、取得した通知先に締結処理に関する通知を出力するように構成されている。ここでの通知の出力は、上述した通知先の情報を踏まえて適宜の方法により行われることができ、当該通知先の情報にかかわらず、適宜契約締結担当者により設定することも可能である。当該構成を採用することにより、契約締結処理段階でイレギュラーな事象が生じた場合にも、本システムを用いることで当該事象の報告まで記録することができ、のちの契約管理を適切に実施すること可能になる。
【0069】
<具体的な構成>
本実施形態の契約締結システムを構成する各装置のハードウェア構成は、基本的には、図3を用いて説明した実施形態1の契約締結システムにおけるハードウェア構成と同様である。そこで以下については、これまで説明していない「通知先情報取得部」及び「通知出力部」の具体的な処理について説明する。
【0070】
(通知先情報取得部の具体的な構成)
通知先情報取得部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、CPUが記憶装置から「通知先情報取得プログラム」をメインメモリに読み出して実行し、通知先の情報を検討ステータスと対応させて取得しメインメモリの所定のアドレスに格納する。
【0071】
(通知出力部の具体的な構成)
通知出力部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、契約締結プログラムの実行により所定の処理が実行されると、CPUが記憶装置から「通知出力プログラム」をメインメモリに読み出して実行し、通知先情報取得プログラムの実行により取得していた情報をメインメモリに読み出し、当該情報に対応した通知先に対し、締結処理に関する通知を出力する
【0072】
<処理の流れ>
図10は、本実施形態の契約締結システムにおける処理の流れの一例を示す図である。同図は本実施形態の契約締結システムを契約当事者間で利用する場合の各利用者間における処理の流れの一例を示す図である。同図においては図1を用いて説明した例と同様の例に即して説明するものとし、その処理の流れは以下のステップからなる。まずステップS1000では、検討ステータスと紐づけられた通知先の情報を取得する(通知先情報取得ステップ)。そしてステップS1001では、A1又はB1により契約データの入力を受け付ける(契約データ入力受付ステップ)。ステップS1002では、A1又はB1により契約当事者を識別するIDである契約当事者IDの入力を受け付ける(ID入力受付ステップ)。ここでステップS1001とステップS1002の順序は特に問わず、両者の順番が入れ替わってもよい。
【0073】
そしてステップS1003では、ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す検討ステータスのうち決裁処理利用記録ステップにて記録された検討ステータスを用いてA1又はB1による契約締結可否を判断する(可否判断ステップ)。ここでの判断結果が契約締結可能との内容であれば、ステップS1004としてA1又はB1が契約締結処理を実行し(契約締結ステップ)、ステップS1005として、あらかじめ通知先情報取得ステップにて取得した通知先に締結処理に関する通知を出力する(通知出力ステップ)。判断結果が契約締結不可との内容であれば、その旨の情報を通知するとともに、再度の契約締結検討を促す処理を行う。
【0074】
<効果>
本実施形態の契約締結システムを用いることにより、実施形態1又は2の契約締結システムを用いる場合に比べ、事業者内の稟議に関与した契約締結者以外の者に対しても、契約締結管理をしやすい環境を提供できるようになる。
【符号の説明】
【0075】
0200・・・契約締結システム、0201・・・契約データ入力受付部、0202・・・ID入力受付部、0203・・・可否判断部、0204・・・契約締結部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
【手続補正書】
【提出日】2021-12-16
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
契約データの入力を受け付ける契約データ入力受付ステップと、
契約当事者を識別するIDである契約当事者IDと、利用事業者内の複数の利用者や決裁担当者を識別するためのIDである利用事業者内利用者IDの入力を受け付けるID入力受付ステップと、
ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す情報であって、決裁担当者ごとの決裁処理状況を把握可能な情報である検討ステータスに応じて契約締結可否を判断する可否判断ステップと、
可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理として、契約締結の意思がある旨の情報である申込情報を、特定の契約当事者IDにて識別される事業者ないし当該事業者の担当者に送信する処理を実行する契約締結ステップと、
をコンピュータにて実行する契約締結方法。
【請求項2】
契約締結ステップは、締結日時を記録するタイムスタンプ付与サブステップをさらに有する請求項1に記載の契約締結方法。
【請求項3】
複数の契約当事者の検討ステータスを記録する決裁処理利用記録ステップを更に有し、
可否判断ステップは、決裁処理利用記録ステップにて記録された検討ステータスを用いる決裁状況判断利用サブステップをさらに有する請求項1又は2に記載の契約締結方法。
【請求項4】
検討ステータスと紐づけられた通知先の情報を取得する通知先情報取得ステップと、
契約締結ステップにて契約締結処理が行われた場合に、取得した通知先に締結処理に関する通知を出力する通知出力ステップをさらに有する請求項1から3のいずれか一に記載の契約締結方法。
【請求項5】
契約データの入力を受け付ける契約データ入力受付ステップと、
契約当事者を識別するIDである契約当事者IDと、利用事業者内の複数の利用者を識別するためのIDである利用事業者内利用者IDの入力を受け付けるID入力受付ステップと、
ID入力受付ステップにて受け付けた契約当事者における契約データ入力受付ステップにて受け付けた契約データの契約締結検討状況を示す情報であって、決裁担当者ごとの決裁処理状況を把握可能な情報である検討ステータスに応じて契約締結可否を判断する可否判断ステップと、
可否判断ステップの判断結果が契約締結可能との判断結果である場合に限り契約締結処理として、契約締結の意思がある旨の情報である申込情報を、特定の契約当事者IDにて識別される事業者ないし当該事業者の担当者に送信する処理を実行する契約締結ステップと、
をコンピュータに実行させる契約締結プログラム。
【請求項6】
契約データの入力を受け付ける契約データ入力受付部と、
契約当事者を識別するIDである契約当事者IDと、利用事業者内の複数の利用者を識別するためのIDである利用事業者内利用者IDの入力を受け付けるID入力受付部と、
ID入力受付部にて受け付けた契約当事者における契約データ入力受付部にて受け付けた契約データの契約締結検討状況を示す情報であって、決裁担当者ごとの決裁処理状況を把握可能な情報である検討ステータスに応じて契約締結可否を判断する可否判断部と、
可否判断部の判断結果が契約締結可能との判断結果である場合に限り契約締結処理として、契約締結の意思がある旨の情報である申込情報を、特定の契約当事者IDにて識別される事業者ないし当該事業者の担当者に送信する処理を実行する契約締結部と、
を有する契約締結システム。