AI開発にまつわる紛争や訴訟リスクを減らすには？ 弁護士が解説
ユーザーが保有しているデータをAIベンダーに提供し、AIベンダーの技術力・ノウハウを利用して学習済みモデルを生成してユーザに納品するというAI開発は現在盛んに行われています。 当事務所でもAI開発案件を多数法務サポートしておりますが、私の知る限り、AI開発のトラブルが裁判まで発展したケースはありませんでした。 今回は、おそらく史上初めてAI開発契約の効力が争われた裁判をご紹介したいと思います。 といっても、2019年10月28日に東京弁護士会主催で行われたAIシンポジウムの企画の一環として行われた模擬裁判のお話です。もちろん、弁護士会が主催する以上、模擬裁判といってもお遊びではありません。 裁判長役には知財の世界では知らない者のいない超ビッグネーム三村量一先生を迎え、テーマは、「AI開発契約であるにもかかわらず、従前のシステム開発の契約書を利用して契約を締結した場合、どのようなことがリスク
ロカポ ブログ: GeoHashが米国特許6,552,670（通称 BINGEO）に引っかかってるかもしれない
「元ここギコ！」さんのFacebook書込みに触発されて、GeoHash の仕様が掲載されているWikipediaのページを久しぶりにじっくり見てみた。 GeoHashとは、緯度経度の位置情報を表すコードで、短い文字列で場所を表すことができるため、Twitterのジオタグなどに使われてることが多い。 この種の位置情報コードは、現在私が把握しているだけで全世界に24種類ある。私自身も位置情報コードを発明して特許を取ったことがある。（このブログのタイトル「ロカポ」はその位置情報コードの名前。現在はロカポv2にあたる LP-Address を無償公開）。それ以来、位置情報コードの情報は常に収集していて、「位置情報コード百科 - GEOCODE Encyclopedia」というドキュメントをつくったり、大学で論文として発表したりしている。 で、本題に戻ると、GeoHashのエンコーディングの手順が
mysql空間拡張とGeoHash, quadkeyについて検索速度を比較してみた & quadkeyって何？の紹介 - Code for History
1週間程前かな？退社間際にやったSQL調整がどうしてもうまくいかず、100ms程度だった検索速度が空間検索条件を外すと爆速になったので、十分な確認もなく短絡して、Twitterで「mysqlの空間検索遅過ぎる！使えねー」と呟いてしまいました。 明日になればGeoHashとかquadkey*1のような一次元空間コード検索に変更してやるぞと。 が、翌日取り急ぎ検索条件をquadkeyに変更してやっても、特に速くならない。 あり？と思ってよくよくさらにチェックしてやると、複合検索のプロファイルの見方を間違えてて、テーブル間のリレーションキーで非空間テーブル=>空間テーブルの向きは主キーでリンクされてたけど、その逆はリレーションキーにインデックスを張ってなかったので、オプティマイザの選択が先に非空間テーブルの検索条件=>フィルタされたレコードに対し逐次空間検索、となっていたのが遅い原因でした。 非
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.opengis.co.jp/techguidej/76BingStructure_J.pdf
