分析シリーズ（知財活用戦略）　株式会社タイミーの特許から学ぶ　“ただ取るだけじゃない！ビジネスに活用する特許の出願～権利化”　（第１回）

　今回は、タイミーの興味深い特許活用の試みについて紹介しながら、特許の活用の仕方について考察してみたいと思う。こういう使い方があるというのは、既に知っている人にはその可能性の再認識を与えてくれるであろうし、知らなかった人には特許の視野（可能性）を拡げる良い機会になると思うので、企業の方にはぜひ最後まで読んでもらいたい。

　予め断っておくが、ここでの話はあくまで私の推察であり、実際にタイミーがここで紹介する通りに活用を試みたのか、出願時に既に活用を見据えた戦略を持っていたかは定かではないし、戦略面の事実確認は行っていない。結果的に見えている事実に基づいてはいるが、真実性を担保するものでないことについてはご理解いただきたい。

　その意味では、私の方で多少盛ってしまう可能性もあるかもしれないし、これを承知いただいた上で、フィクション的な読み物として読んでもらうスタンスの方がいいだろう。これがフィクションであろうとノンフィクションであろうと、ビジネスへの活用を見据えた特許の使い方を学ぶ機会になることへの障りはない。
　以降、「タイミーの戦略」や「タイミーの思惑」など、タイミーを主語にしてタイミーの考えを語っている（知っている）ように読める記載もでてくるだろうが、それは、都度「タイミーの戦略と私が推測していること」といったくどい文章にしたくないからであり、読み易い文章にするためにしていることを事前に断っておく。

　なぜこのようなことを言うかというと、良いことばかりをいうつもりがないからである。相手に気を遣うというのは、分析や考察を歪めてしまい、率直な意見を封じてしまうため、私はなるべくこのようなことはしたくないと考えている。戦略は常に成功から学ぶものではなく、失敗からも学べるものであるから、なるべく正直に、私が思ったことを話していこうと思う。（攻撃はしないが、学びのために必要と思う批評は隠さずにしていきたい）

　最初に言っておくと、タイミーの活用戦略は、特許の本来の使い方という意味では失敗している。ここで重要なのは“特許の本来の使い方”という部分であり、それは特許権を取得して、ビジネスを独占排他できる領域を作るという使い方である。
　しかし、特許の本来の使い方による活用に失敗したからといって、ビジネスとして失敗だったか、もっといえば、タイミーのビジネスにプラスに働くようにこの特許が活かされなかったかというとそこは定かではない。もしかすると、失敗も見越した（許容した）戦略だったかもしれないし、結果的にビジネスに活きているかもしれない。
　私がなぜこのように考えるかについても後できちんと説明するつもりである。

　また、今回も一度に全部を話すと記事が長くなりそうなので、複数回にわけて話そうと思う。暫定ではあるが、次の構成で３回に分けることを考えている。

　第１回：ビジネス戦略の目線を含まずにみたときの特許の評価
　第２回：タイミーのビジネス活用戦略について（ビジネスを絡めた特許の評価）
　第３回：タイミーのビジネス活用戦略の改善点（こうすれば成功した？）

　それでは、ここからは第１回の話として「ビジネス目線」を含まずに、純粋に特許の内容容をみただけで、私が率直に感じた特許権の評価について話したいと思う。

　対象の特許は、特許第６６６７９１８号である（以下「対象特許」という）。

　対象特許の請求項１に係る発明は以下の通りである。なお、特許を読み慣れていない人は、この発明の概要を後記しているので、請求項の記載を無理に読まなくてもよい。

【請求項１】
　求職者および雇用者間での雇用契約及び出退勤を管理する契約出退勤管理サーバであって、
　前記求職者が使用する求職者端末から送信された前記求職者に関する求職者情報を受け付ける求職者情報受付部と、
　前記雇用者が使用する雇用者端末から送信された少なくとも雇用時間帯及び賃金を含む雇用条件を受け付ける雇用条件受付部と、
　前記雇用条件に対して前記求職者端末から送信された前記求職者による応募を受け付ける求職希望受付部と、
　前記雇用条件と前記応募を行った求職者とが関連付けられたコードを生成し前記雇用者端末又は前記求職者端末に送信して表示するコード表示部と、
　前記求職者端末又は前記雇用者端末により、前記雇用者端末又は前記求職者端末に表示された前記コードを読み取ることで、前記求職者端末又は前記雇用者端末からコード読取情報を取得するコード読取情報取得部と、
　前記求職者の労働開始時に前記求職者端末又は前記雇用者端末が前記コードを読み取ったコード読取情報を取得することで、前記求職者が前記雇用者による雇用条件へ同意をして契約が締結された旨を記憶するとともに該読み取った時間を出勤時間として記憶し、前記求職者の労働終了時に前記求職者端末又は前記雇用者端末が前記コードを読み取ったコード読取情報を取得することで、前記コードを読み取った時間を退勤時間として記憶する契約出退勤管理部とを備える契約出退勤管理サーバ。

　ご存知の通り、特許権者であるタイミーは、すきまバイトの市場を創り上げた先駆者といってよいだろう。対象特許も、タイミーのサービスに関わるものであり、“雇用契約と出退勤の管理”が、発明内容の主となっている。

　特許の内容をおおまかに説明すると、

　といった内容である。

　対象特許の内容を読んた私の率直な感想は『おそらくタイミーは「出退勤時間の管理」に関する“良い”特許が欲しかったのだろう』ということであった。つまり、この出願の狙いは、契約管理ではなく出退勤管理の方にあると思った。
　なぜならば、出勤時間と退勤時間をきちんと記憶できる仕組みは、すきまバイトのビジネスに“必須”の要素であり、金銭の支払いに直結する重要な要素といえるからである。
　そのビジネスに重要かつ必須の要素に関する特許は価値が高いし、他人に取って欲しくないと思うのが普通である。必然性の高い技術や方法を特許で押さえることができれば、他社を排除することもビジネスを支配することもできるため、タイミーは出退勤管理についての強い特許を取りたかったのだろうと思った。

　すきまバイトは、単発的な雇用の形態であるため、定期的に決まった曜日の決まった時間に働くわけではない。雇用者が提示する雇用条件の中には確かに日時や時間帯に関する情報が記載されているだろうが、この時間を決め打ちにして給与を支払うわけにはいかない。そうかといって、雇用者側は常に勤怠管理のシステムを有しているとも限らないし、雇用者側が記録した労働時間を１００％信用するというのもトラブルの原因になりかねない。

　単発的な雇用に対しては、（イ）実際に働く当日に、現場でタイムリーに労働の開始時と終了時を記録できるのがよく、（ロ）雇用者と求職者のうちの一方側だけが処理する記録とならないようにした方がよく、さらには、（ハ）雇用者側に余計な設備投資が必要ない仕組みがよい、ということになる。

　このような観点でみたときに、対象特許に記載されるように、
　雇用者側の端末（PCやスマホ）と求職者側の端末（スマホ）のどちらか一方に端末に“コード”を送信し、勤務開始時と終了時に他方の端末に“コード”を読み取らせることで、出勤時間と退勤時間を記録管理する
　という方法は、上記の（イ）～（ハ）を全て満たすものであり、極めて合理的かつ利便的である。

　もし、この方法を端的に記載しただけの内容で特許権が取得できたとしたら、この特許はタイミーを“すきまバイト事業”の支配的地位に定着させる大きな礎となったかもしれない。

　例えば、対象特許に記載される方法とは別の方法で、（イ）～（ロ）を満たす方法がないかを考えてみる。

　一つには、勤務開始時に雇用者端末と求職者端末のそれぞれから「開始」ボタンを押してもらい、サーバが両端末から「開始」信号を受信することで出勤時間を記録するという方法があるだろう（勤務終了時も同様）。

　しかし、この方法では、雇用者端末から「開始」信号が送信される時刻と求職者端末から「開始」信号が送信される時刻が一致しないことが多々起こり、数秒程度の乖離であれば問題ないだろうが、時間が大きく乖離してしまった場合にどちらの時刻を信じればよいかという問題が起こることが予想される。ちょっとでも支払う給与を少なくしたいと考える雇用者が遅めに「開始」ボタンを押したり、ちょっとでも多く給与を貰いたいと考える求職者が早めに「開始」ボタンを押すかもしれないわけである。どちらの開始時間が正しいかはケースバイケースであろうし、この手の悪用はすぐに判明しづらいため、長期的な不正が行われてしまうと、発覚したときに会社の責任が問われ、大きく信用を毀損するリスクがあるから、まず採用できないだろう。（打合せでクライアントに対してこういう代替案を提案してしまうのはよくないだろう。ビジネスを考慮すれば誰もやらない技術の特許を取っても役には立たないし、無駄な特許を取得しておいて成功報酬など請求しようものならクライアントにとって害でしかない。）

　別案として、出勤開始の準備が整った段階でまず雇用者端末から「出勤準備完了（開始許可）」の信号をサーバに送信し、開始許可の信号を受信したことで、求職者端末から「出勤開始」ボタンを押下することができるようにするという方法が考えられる。

　この方法であれば、雇用者が、出勤開始できると判断するまでは求職者側で「出勤開始」の操作を行うことができず、求職者側も、「出勤開始」の操作ができない間は働く必要がない。準備が整った段階で早く働いて欲しい雇用者が開始許可の操作に消極的になる理由もないので、開始許可以降に、速やかに求職者が「出勤開始」ボタンを押すフローができあがるだろう。ゆえに出勤時間は求職者端末からの出勤開始の信号受信時で問題ない。
　この方法は（イ）～（ロ）は満たすことができる代替案になるだろう。デメリットを挙げるとすれば、ネットワーク通信が増える点にある。対象特許の方法であれば、コードが送信された後、現場でのやり取りは求職者端末と雇用者端末の端末間通信と、コードを取得した端末（あるいはコードが読み取られた端末）からのサーバへの送信で済むため、サーバ側とのトラフィックは一度で済むが、代替案の方法では、雇用者端末からサーバへの通信、サーバから求職者端末への通信、求職者端末からサーバへの通信と、少なくとも３度の通信が発生する。

　この点、一度の通信と三度の通信であれば負荷に大した差はないと思うかもしれないが、通常、勤務開始時間というのは３０分や１時間区切りで設定されるし同じ時刻に集まりやすい。例えば、勤務開始予定時刻が同じ時間の雇用が１万件あれば、トラフィックの差は２万になり、これを処理するために必要なサーバの数も変わってくるだろう。

　このように、技術的にたいして変わらないように見える効果の差であっても、ビジネスの実態を考慮してその効果を評価すると大きな優位性を生じさせることがある。（イ）～（ロ）に加えて、サーバと端末間のネットワークトラフィックを極力少なくするという利点も得ようとすると、対象特許に記載される出退勤管理の方法は、およそ理想的な方法といえるように思える。

　だが一方で、タイミーは、この理想的な方法のみの内容で特許が取れるとは考えていなかった。そこで、『出退勤管理の理想的な方法＋出退勤管理に関わる別の観点からの発明を加えることで、出退勤管理に関する“良い”特許をなんとか取得したい』というのが、対象特許の出願に際してのタイミーの狙いだったのではないかと私は推測した。

　出退勤管理に関わる別の観点からの発明が、出退勤管理を実現する際の必然性の高い内容であれば、この組み合わせによる特許は結果的に出退勤管理の理想的な方法を保護してくれる（タイミーが独占できる）。従って、出退勤管理に関わる別の観点からの発明として、どこに目を付けるかが極めて重要になる。

　そして、対象特許でタイミーが目を付けたのが、「雇用に関する契約管理」である。

　私は、出退勤管理に契約管理を付随させるというタイミーの結論に対し、『筋が悪い』と思った。

　確かに、すきまバイトの形で雇用者と求職者の間に立つタイミーは、各雇用に関して締結される契約を管理しなければならないし、雇用者と求職者の間でトラブルが発生した場合の備えも考えると、締結された契約一覧を長期間保存しなければならないだろう。

　しかし、雇用契約の登録をどのタイミングで行うかは、システムを設計する中で適宜決めればよいことであり、対象特許のようにわざわざ「労働開始時に読み取ったコードを取得したタイミングで記録する」必要もない。言ってしまえば、タイミーのサイト上で求職者が雇用を選択し、マッチングが成立した時点で契約の管理を開始（登録）したっていいわけである。

　つまり、雇用に関する契約の締結を、出退勤のタイミングに合わせなければならない理由はないのだから、対象特許は、他社にとって設計回避が極めて容易な、実質的に“価値の低い特許”であると私は評価した。

　この評価はおそらく、一般的な弁理士の感覚と大きくずれるものではないだろうと私は思っている。タイミーのビジネスや業界の動向などを知らずに対象特許をみれば、
「前記求職者の労働開始時に前記求職者端末又は前記雇用者端末が前記コードを読み取ったコード読取情報を取得することで、前記求職者が前記雇用者による雇用条件へ同意をして契約が締結された旨を記憶するとともに該読み取った時間を出勤時間として記憶し、」
　との発明特定事項を除けば、対象特許の請求項１には極めてシンプルで必要性の高い処理内容しか記載されていない。

　そして「労働開始時に…コード読取情報を取得することで、…契約が締結された旨を記憶するとともに…出勤時間として記憶し」という記載は、契約が締結された旨を記録するという処理に対する限定要素のオンパレードなのである。
　労働開始時のタイミングでなければならず、コード読取情報の取得によらなければならず、出勤時間の記録とともにしなければならない。
　このうちの少なくとも１つを回避できれば、対象特許を侵害することにはならず、タイミーが対象特許で開示してくれた理想的な出退勤管理を他社は実施（真似）できてしまう。

　このような内容の発明を特許出願し、早期審査で権利化し、特許権を維持しようとすることは、『見せかけだけの特許に費用を払うというほとんど無駄な投資ではないか』と思ったし、おそらくタイミーは、彼らが特許に期待していた以上の満足を得られず、むしろ特許はたいして使えないという失望を抱いてしまうのではないかと危惧した。
　また、上記の限定要素は出願時の請求項から入っていた内容であったから、このような特許しか取れないとわかっていて出願代理をし、安くない料金を請求する代理人は名ばかりのスタートアップ支援で企業を食いものにするけしからん代理人ではないかという一種の憤りも覚えた。

　しかし、このような私の危惧や憤りは、大きな誤解であったかもしれないということに私は気付いた。（出願人のタイミーにも代理人のＩＰＴｅｃｈ特許業務法人にも『大いなる思い違いをして申し訳ない』と私は心の中で謝罪した。）

　タイミーの対象特許は、タイミーのおそるべき戦略と紐づくものであり、技術的要素だけをみれば（弁理士視点だけで判断すれば）限定的とも思える上述の発明特定事項こそが、すきまバイトビジネスの支配者を狙わんとするタイミーの思惑そのものであったかもしれないのである。

　これだから知財は面白いし、技術の枠の中ではなく、ビジネスの中でこそ知財は活き活きするのである。

　が、タイミーのおそるべき戦略については、第二回で話をしていくことにする。

　さて、第一回はあくまで、ビジネス戦略の目線を含まない、いわゆる請求項の内容から発明を限定的にするような余計な言い回しがないかという、長らく弁理士の専門領域とされてきた視点から、対象特許を評価するものであるため、この点について少しだけ補足しておこう。

　既に述べた、限定要素と思える発明特定事項
「前記求職者の労働開始時に前記求職者端末又は前記雇用者端末が前記コードを読み取ったコード読取情報を取得することで、前記求職者が前記雇用者による雇用条件へ同意をして契約が締結された旨を記憶するとともに該読み取った時間を出勤時間として記憶し、」
　はさておき、ここでは、理想的な出退勤管理の方法に関して、請求項１に限定的な要素がないかをみていくことにする。

　求職者情報受付部、雇用条件受付部、および求職希望受付部に係る発明特定事項については、およそ無駄な記載のない必須の内容しか記載されていないものと思われる。
　私が気になったのは、コード表示部における「前記雇用条件と前記応募を行った求職者とが関連付けられたコードを生成し…送信して表示する」という部分である。

　確かに、雇用を管理するためには、雇用条件と応募を行った求職者とを関連付けて管理することは必須である。よって、サーバにおいてこのような関連付けの情報が登録され、管理されることは必然的な対応であろう。しかし、生成され送信され表示される“コード”が、雇用条件と応募を行った求職者とが関連付けられたコードであることは必然ではないかもしれない。

　例えば、次のような方法が考えられる。

　この方法であれば、端末の送信するコードは、「雇用条件と応募を行った求職者とが関連付けられた」ものでなくてもよい。あらかじめ関連付けた情報を端末に送信するのではなく、片方の情報だけを送信し、残りの情報は労働当日の端末間のやりとりの中で補充するからである。

　但し、この方法の場合、端末側に専用アプリのインストールが必要となるかもしれない。読み取ったコードには、アクセス先のURLと特定の情報が含まれるが、端末に登録されている情報を含めてサーバにアクセスするための処理が必要になると考えられるからである。

　しかし、すきまバイトの市場規模を考えれば、専用アプリを作る費用はビジネス参入のたいした障壁にはならず、事実、タイミーもマイナビもバイトルもタウンワークも、Appストアから専用アプリをインストールできる。（２０２６年１月時点）

　そして、専用アプリを前提とすれば、上記の方法とは別の方法がさらに考えられる。

　このようにしてみると、コード表示部においては、「少なくとも前記雇用条件と前記応募を行った求職者のいずれかを特定するコードを生成し前記雇用者端末又は前記求職者端末に送信して表示するコード表示部」と記載しておく方が、上述の代替方法も含めて、より網羅的に理想的な出退勤管理の方法をカバーする特許権が取得できただろう。

　また、究極的には「コード表示部」は必須ではないかもしれない。雇用者端末と求職者端末が現場でやり取りできるなら、一方の端末が自身に登録されたアカウントを含むコードを表示し、他方の端末がコードを読み取って、雇用者と求職者のそれぞれを識別するアカウントを併せて出勤開始リクエストをサーバに送信すればよいかもしれない。
　加えて、請求項１は、出勤時間に対比させるようにして退勤時間の記憶についても記載しているが、これも他社に対して僅かな隙を与えてしまうかもしれない。合理性を考えれば、出勤も退勤も同じコードを読み取って使い回す方がよいが、例えば、出勤開始後に、退勤用のコードを新たに生成して端末に送信するという方法も考えらえるだろう。この場合「前記コード（＝出勤処理のときに使用したコード）」を使うわけではないので、対象特許の請求項１に係る発明の文言侵害は成立しなくなるだろう。（せいぜい均等侵害の可能性が残されるに過ぎないが、契約出退勤管理部は対象特許に係る発明の本質的部分を含んでおり、請求項の記載上は一連の処理のように読めるため、この場合の均等侵害の成立は難しいように思える。）

　ビジネス戦略上の本命が「雇用契約管理」にあるとすれば、むしろ、出退勤管理に抜け道がある（請求項１を回避した出退勤の管理方法がある）ことの方が問題となるかもしれず、より良い権利としては、下記のような請求項１があり得たかもしれない。

【請求項１】（下線が追記部分）
　求職者および雇用者間での雇用契約及び出退勤を管理する契約出退勤管理サーバであって、
　前記求職者が使用する求職者端末から送信された前記求職者に関する求職者情報を受け付ける求職者情報受付部と、
　前記雇用者が使用する雇用者端末から送信された少なくとも雇用時間帯及び賃金を含む雇用条件を受け付ける雇用条件受付部と、
　前記雇用条件に対して前記求職者端末から送信された前記求職者による応募を受け付ける求職希望受付部と、
　前記雇用条件と前記応募を行った求職者とが関連付けられたコードを生成し前記雇用者端末又は前記求職者端末に送信して表示するコード表示部と、
　前記雇用者端末又は前記求職者端末に表示された情報であって前記求職者端末又は前記雇用者端末により、前記雇用者端末又は前記求職者端末に表示された前記コードを読み取ることで、前記求職者端末又は前記雇用者端末から読み取られた前記情報を含む、前記求職者により応募された前記雇用条件を特定する雇用特定情報コード読取情報を取得するコード読取雇用特定情報取得部と、
　前記求職者の労働開始時に前記求職者端末又は前記雇用者端末が前記雇用者端末又は前記求職者端末から前記コードを読み取った前記情報を含む前記雇用特定情報コード読取情報を取得することで、前記求職者が前記雇用者による雇用条件へ同意をして契約が締結された旨を記憶するとともに該読み取った時間を当該雇用条件に係る雇用の出勤時間として記憶し、前記求職者の労働終了時に前記求職者端末又は前記雇用者端末が前記コードを読み取ったコード読取情報を取得することで、前記コードを読み取った時間を退勤時間として記憶する契約出退勤管理部とを備える契約出退勤管理サーバ。

【請求項１】（クリーン版。下線が追記部分）
　求職者および雇用者間での雇用契約及び出退勤を管理する契約出退勤管理サーバであって、
　前記求職者が使用する求職者端末から送信された前記求職者に関する求職者情報を受け付ける求職者情報受付部と、
　前記雇用者が使用する雇用者端末から送信された少なくとも雇用時間帯及び賃金を含む雇用条件を受け付ける雇用条件受付部と、
　前記雇用条件に対して前記求職者端末から送信された前記求職者による応募を受け付ける求職希望受付部と、
　前記雇用者端末又は前記求職者端末に表示された情報であって前記求職者端末又は前記雇用者端末から読み取られた前記情報を含む、前記求職者により応募された前記雇用条件を特定する雇用特定情報を取得する雇用特定情報取得部と、
　前記求職者の労働開始時に前記求職者端末又は前記雇用者端末が前記雇用者端末又は前記求職者端末から読み取った前記情報を含む前記雇用特定情報を取得することで、前記求職者が前記雇用者による雇用条件へ同意をして契約が締結された旨を記憶するとともに該読み取った時間を当該雇用条件に係る雇用の出勤時間として記憶する契約出退勤管理部とを備える契約出退勤管理サーバ。