清水敏の弁理士日記

知的財産関係のニュースと、実務的心覚えとをつづる。実務的情報については、できるだけ元情報の所在を記載する。
特許事務所のサーバがランサムウェアに感染したら
0
    これは思ってもぞっとする。ある日事務所に出てきて、パソコン画面にランサムウェアらしきメッセージが表示されてサーバのファイルに全くアクセスできなくなったら…。期限管理もできない。もちろん一所懸命に作っていた図面や明細書にもアクセスできない。電子メールも読めず、国内のクライアントとのオンラインではアクセスを拒否されて、などということになったら弁理士としては途方にくれてしまうだろう。

    というのが現実にあった、と申し立てて、外国の出願人の案件の審査請求期限を徒過してしまった代理人(特許管理人)がいたらしく、出願人が救済を求めて起こした訴訟の判決があった。詳細は検索してもらうこととして、東洋の小さな国の小さな特許事務所にもインターネットを介した攻撃が毎日来ていることは昔よくわかった。自分のところにそんな物が来るはずがないと安心していてはいけない。

    我が事務所では、三重、四重の防御態勢をとっているが、それでもメール等でそれらしいものが毎日やってくる。すこしでも怪しいものは即ゴミ箱行きである。

    弁理士がデータを扱うことになるというのだが、他人のデータを預かるのは絶対に避けたい。
    | 清水敏 | パソコンなど | 18:50 | comments(0) | trackbacks(0) |
    ファイルサーバのリプレース(2)
    0
      ファイルサーバのリプレースをしてしばらく経過した。この間に発生した問題をあげて見る。

      1)ネットワークに新しいサーバが表示されない状態が暫く続いた。この問題には対応して解消した。というか、いろいろやっているうちにきちんと表示されるようになった。正確な原因も解決策もよく分からない。
      続きを読む >>
      | 清水敏 | パソコンなど | 08:31 | comments(0) | trackbacks(0) |
      ファイルサーバのリプレース
      0
        ファイルサーバをリース切れ以後2年程継続して使用していたが、最近、ハードディスクエラーが発生した。とりあえずの動作には支障はないが、なにしろファイルサーバには全てのデータが入っているので無視することはできない。そこでファイルサーバをリプレースすることにした。作業は今週の月曜日から始まり、昨日一応完了した。
         今回のファイルサーバはハードディスクにかえて全てSSDになっている。さすがにファイルの読み書きが速い。多分バックアップも短時間で終わるのではないかと考えている。
         ところで、ファイルサーバはウェブサーバ、DNSサーバ、DHCPサーバ、ウィルスチェックアプリケーションのサーバも兼ねている。今回のこれらの機能は全て新しいサーバに移植したのだが、直後からクライアント(特にブラウザ)の動きがおかしくなった。具体的には、事務所内に立ち上げているウェブサーバ(上記ファイルサーバ内に立ち上げているものと、別のサーバに立ち上げているもの)の両者において、先頭ページを読み出すと画面が乱れる。どのように乱れるかというと、本来は1つしかないフィールドが2つとか3つとか表示されるし、タイトルも2回表示される。画面に表示される画像(HTML+CSSで作られたもの)が、3つ一部重なって上下に表示されたりする。しかもこれが一部のクライアントだけで起こり、他のクライアントではなんの異常もない。
         この原因がどうしてもわからず、しばらく仕事が滞った。なにしろ現在の事務所の仕事は、ファイルサーバだけでなくウェブサーバにも大きく依存しているので、ブラウザ表示が正しく行われないと仕事にならない。
         結局、原因と判明したのは、サーバと連動するウィルスチェックアプリケーションと、一部クライアントにインストールされていた、別のウィルスチェックアプリケーションとの干渉であった。どちらか一方を止めるとほぼ正常な表示になる。今回は、新しいサーバに導入したウィルスチェックアプリケーションのバージョンが上がっていたために、既存のアプリケーションと干渉を起こしたということだ。
         これとは別に、ネットワーク関係で以前は問題なく動作していた通信ができなくなっているという問題がある。しかしこれについては回避策があるのでまあよしということにして、新しいファイルサーバでの業務を本日から開始することにした。
        続きを読む >>
        | 清水敏 | パソコンなど | 07:52 | comments(0) | trackbacks(0) |
        マックのメールでThunderbirdにフォワードすると添付ファイルが消えた
        0
          朝事務所に出ると、最初の仕事はバックアップの確認、そしてクライアントのサーバとの通信。さらに、電子メールのチェック。通常は電子メールがきても他の人が担当者に振り分けるので、私はチェックのみ。しかし今日は、その振り分けを担当している者が遅刻することになっていたので、私が代わりに振り分け処理をした。外国の代理人からメールが4件。正確に言うとそのうち振り分けが必要なメールは3件。そこで、その3件を担当者にForwardして1件落着。
           しかし、担当者からクレームが。「メールは来たが添付ファイルがない」という。そんな馬鹿な、と見に行ったが確かにフォワードしたメールはあるが、添付ファイルは見当たらない。そういえばこんなことが前にもあった。
           そこでもう一度フォワードした。ここで、私のメールは、送信した後で、私が自分でもう一度チェックしないと実際に送信されない仕掛けになっている。この自分でのチェックでフォワードしたメールを見ると、その時点で既に添付ファイルがなくなっている。まさに狐につままれた感じ。フォワードでなくリダイレクトしても同様。考え込んだが理由が分からない。
           しかし、最初にフォワードしたメールが私のところにCCで入っていたので内容を見ると、ちゃんと添付ファイルが存在している。これにはさらに「?」。
           よく考えると、添付ファイルが存在しているのにもかかわらず見えないのは、メーラ(Thunderbird)が悪いのでは?と考えてサーチしてみると、同じような経験をしている人が結構いた。しかし大部分は詳細に見ると私のトラブルとは条件が違う。1件だけ、同じようなことを書いている人がいた。その記事によれば、サンダーバードの表示形式をプレーンテキストではなくシンプルHTMLにすればよい、という。
           そこで早速確かめてみると、おお、ちゃんと添付ファイルが出てきた。それまではメール一覧に添付ファイルの印(クリップ)も表示されていなかったのに、今やちゃんと表示されている。
           ということで、こうしたトラブルに遭遇した場合には、Thunderbirdのメニューから表示>メッセージの表示形式と進み、「プレーンテキスト」ではなく「シンプルHTML」に変更すれば大丈夫(だと思う)。
          続きを読む >>
          | 清水敏 | パソコンなど | 13:20 | comments(0) | trackbacks(0) |
          ファイルサーバ(リース切れ)がそろそろ…
          0
            先週の日曜日、事務所に出てきたらファイルサーバが再起動の途中で止まっている。どうやら前日の深夜にWindows Updateがあり、自動的に再起動したのだが、起動ディスクにエラーがあって起動できなかったようだ。一度電源を落として起動したら無事起動したのだが、既にリース切れして2年程経過しているのでそろそろリプレースする必要があるという結論になった。このサーバは3代目だったと思うが今まで特に問題なく動いてきてくれた。
             バックアップは万全にとってあるが、万が一サーバが起動しなくなったら一時的にせよ業務に支障が生ずる。それを避けるためという意味合いもあり、ここはやはりリプレースが妥当だと自分に言い聞かせる。
             ベンダの営業を呼んで話をし、新しく導入する機器も決めた。その席上で、「起動時にエラーが出ているのにサポートからなんの連絡もないのはおかしいのでは?」という話が出た。私はこのベンダとは保守契約も結んでいて、何らかのエラーがサーバに発生すると以前は電話連絡があったものだが、そういえば今回は何も言って来ない。そこで調べてもらったのだが、なんともおそろしい誤りが発生していたことが判明したのだ。
            続きを読む >>
            | 清水敏 | パソコンなど | 07:58 | comments(0) | trackbacks(0) |
            メールを受信したら自動的にDBに登録
            0
              事務所の包袋管理にmySQLを使っている。最近はクライアントから来るデータも外国代理人から来るデータも大体のデータは電子データになっているので、DBへの登録は昔のようにスキャナで読み込ませて、などというのと比較して随分と楽になった。包袋管理のプログラムもPHP+javascriptで自作したのだが、長年の改良で昔に比べると随分と操作も楽になった。

              一方、現在ではクライアントや外国代理人とのやりとりが電子的になった分、電子メールの数が随分と増えた。そのため、DBへの登録の操作が簡単になったことはともかく、数が増えたためにDBへの登録が負担になってきた。クライアントによっては、以前は電話で済ませたような簡単なこともいちいちメールで連絡してくるので、それらもDBに登録しようとするとなかなか大変である。

              そこで、電子メールを受信したら自動的にDBに登録することを考えた。

              最初は事務所内にメールサーバを立ち上げて、サーバがメールを受信したらそれをトリガーに処理することを考えたが、サーバにはなるべく手をつけない方が良いというのと、メールサーバを外部に接続することは避けたいということがあって断念した。となると、私がいつも使っているマックでメールを受信したら、サーバのDBに登録するシステムが必要になる。

              調べると、マックではJXAというのが最近は導入されていて、以前のAppleScriptに加えてJavaScriptでスクリプトが書けるという。メール受信のルールで、特定のアドレスからのメールを受信したらJavascriptを起動してやればできそうである。ということでちょっとスクリプトを組んでみた。

              メールには添付ファイルもあるので、添付ファイルもDBに登録する必要がある。実際には、サーバの特定フォルダ内に添付ファイルを格納し、DBにはそのファイルへのパスを登録するというシステムにしてあるのだが、これをクライアント上のJavaScriptから処理する必要がある。最初はJavaScriptで直接DBにアクセスしようとも思ったが、それはセキュリティ上でよろしくない、という人がいたので、断念。JavaScriptからサーバで動いているApache経由でPHPプログラムにデータを渡してやることを考えた。調べると、JavaScriptのXMLHttpRequestがこの機能にぴったりである。

              が、JXAでこれを実装しようとすると、XMLHttpRequestはundefinedとなって、さっぱり動かない。どうもSAFARI上では動くものの、JXAでは動かないようだ。これは誤算だった。しかしやりだしたものはなんとか完成させないといけない。そこでない知恵を振り絞って考えたのが、次のようなシステムである。

              JXAでメールのサブジェクトまたはコンテンツから正規表現で事務所の事件番号を探す。一致するものがあれば、メールの受信日時を名前にして添付ファイルをサーバの一定のフォルダに保存する。このパスと、事件番号、送信者の情報とをURLencodeし、サファリに、サーバでこの情報を処理するためのPHPプログラムのURL+これらエンコードしたデータとをつないだURLを渡し、サーバにアクセスさせる。

              サーバのapache経由で該当のPHPプログラムが動き、そのプログラム内でデータベースにメール本文と添付ファイルのレコードを挿入する。合わせて、添付ファイルとして特定フォルダに格納されていたファイルを、事件番号とクライアントによって決まるフォルダに移動し、DBの添付ファイルのレコードにそのパスを記録してやる。

              あとは、メールを受信したらマックの MailのルールでJXAのスクリプトを起動してやれば良い。

              これでなんとか動くようになった。が、なぜか「添付ファイルが存在しない」と怒れらることが頻繁にある。問題なく動くこともあるのに、ダメな場合はダメである。何が問題がわからなかったが、探し回って、一旦メールを受信フォルダから別のフォルダに動かしてからJXAのスクリプトを動かすことで、問題が生じる頻度はだいぶ減った(まだ時々ある)。

              とまあ、まだ万全ではないが、うまく動いている時には、DBに自動的に必要な情報が記録されるし、添付ファイルも保存されるしで、ちょっとした感動ものである。まあ、こうした関係について熟知している人ならもっと上手にできるだろうけれど、早朝30分プログラマとしては結構大したものだと思うのである。
              | 清水敏 | パソコンなど | 21:12 | comments(0) | trackbacks(0) |
              OSXの「共有」メニューにメールの選択肢が表示されなくなった
              0
                タイトル通りの事態になった。プレビュー等で何かを表示したあとでそれをメールに添付してどこかに送るとき、プレビューの共有メニューをよくつかっていた。わざわざメールのプログラムを自分で起動する必要がないので。しかし、いつのころからかこの共有メニューにメールの選択肢が表示されなくなってしまった。
                なんでだろ、と思いながら、調べて解決するでもなく過ごしていたが、今日、我慢ができなくて調べたらあっさり解決したのでメモ。
                解決策はアップルのサポートページにあった。

                やりかたは単純で、ターミナルから以下のコマンドを入力するだけ。

                /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -seed

                アップルのサポートページには「数分かかることがあります。」と記載されていたが、たしかにかなり長いと感じた。その間、ターミナルのウィンドウはじっとしていると思ったらリストがずらずらと表示され、また動きがなくなってしまったのでちょっと「?」状態だった、一応完了した。

                で、プレビューを表示して共有メニューを出して見ると、あら不思議、ちゃんとメールが復活している。

                たまにはちゃんと調べてみるもんだ、と思った。
                | 清水敏 | パソコンなど | 13:29 | comments(0) | trackbacks(0) |
                2017/04/13 風を引いた。mac airでimacを操作してみた話。
                0
                  先週の土曜日以来、風をひいた。火曜日には38度3分の熱が有り、出張も近いことから大事をとって事務所への出勤を取りやめた。しかし、家からiCloud経由で事務所のiMacに接続し、そこからさらにRemote desktopで他のWindowsマシン等に接続して作業できるので、通信速度さえ問題なければ家にいてもそこそこ仕事することは可能だということがわかった。ただし、ディスプレイの解像度が違うので、表示がぼやけてなかなかはっきりと見えない点が問題だ。

                  ところで熱は一応さがり、本日はめでたく出張できる。出張時の新幹線の中でも、テザリングで事務所に接続できるので、事務所においてある書類も一応は見ることができる。便利といえば便利だが、電車の中でぼんやりしていることもできなくなったのは、ある意味で残念である。

                  で、今は新幹線の中。デザリングで事務所のパソコンに接続した上でこれを書いている。何もそんなことをする必要はないのだが、どの程度できるか確認中。遅延が大きすぎて仕事にならないよ。

                  ということで、ここからは直接にブログに入った。さすがに遅延はなく、普通と同じ入力感。「仕事にならないよ。」というのはもとは「仕事にならないようだ。」だったのだが、「仕事にならない。」と修正しようとして文字を削除する際の遅延が大きすぎてどこまで削除したかわからず、「よ」が残ってしまったよ。

                  面白いことに気づいた。先に書いたように、入力に対する遅延は甚だ大きく、とてもテキストは入力できない。画面の移動も、タッチパッドでスワイプしても全然遅く、とてもやっていられない。しかし、ポインタを画面の上端とか下端とかに持っていくと、画面がすごく早く移動する。これは、向こうからは画面全体が送られてきているので、その画面の中で表示する位置をローカルで変えているせいだと思う。なにしろあちらは5Kでこちらは12.3インチのmac airなので、画面の大きさは全然違う。全体のごく一部がウィンドウ内に表示されているだけだ。で、ポインタの位置を変えると、相手の画面全体の中で表示する位置を変更するらしい。これはローカルだから遅くない。
                   これに対して、スワイプすると、その入力は向こう側のiMacに送られ、相手側ではそのスワイプ指示にしたがって画面を更新し、その画面全体がこちらに送信されてくるので、これはものすごく遅くなる。
                   ということで、例えば向こう側に表示されている画面を変化させず、隅から隅まで見るような場合には特に支障はないことが判明した。まぁ、あんまり役には立たないが。

                  2017/04/13 世界の知財関連情報

                  2017/04/13 日本の知財関連情報

                  | 清水敏 | パソコンなど | 08:38 | comments(0) | trackbacks(0) |
                  ファイルのアップロードではまったこと
                  0
                    事務所の包袋管理のシステムをApache+PHP+mySql+JavaScriptで組んでいる。日々、いろいろ改良を加えて自分が使いやすいシステムを構築できたのだが、最近、次のようなことがあった。
                    私が使用しているマシンはiMac 27インチであり、そこでSafariによって上記システムを利用している。システム自体は別のサーバにあり、所内ネットワークでサーバに接続する。包袋管理なので、書類はpdfにし、Safariからサーバにアップロードし、サーバ側で適切なフォルダに格納するようにしている。HTMLにアップロード用のボタンを配置しておき、そこに目的のファイルをドラッグアンドドロップしてOKすればあとはサーバが面倒を見てくれる。後から事務所の事件番号、クライアントの事件番号、出願番号、審判番号、登録番号、任意のキーワード、などで検索でき、時系列で見ることができるので非常に重宝している。ファイルをドラッグアンドドロップするときには、適切な位置にファイルをドラッグするとアップロード用のボタンの色が変わるので、そこでドロップすればよい。
                    ところが、最近、アップロード用のボタンのあたりにファイルをドラッグしても、ボタンの色が全く変化しなかったり、ファイルをボタンよりかなり上にドラッグしたところでボタンの色が変わったり、というように妙な動きをするようになった。この原因を調べるのにしばらく時間がかかった。というか、htmlファイルを生成するプログラムを精査してみても原因がわからないので放置していた。が、やっと今日、その原因がわかったような気がする。
                    iMacの27インチは例の5kディスプレイなので、その解像度で画面を表示すると、やたら文字が小さくなる。なにしろ目が疲れる仕事なので、あまり字が小さいと読みづらいし、かといって画面全体の解像度を小さくすると今度は作業効率が下がる。そこで最近は、Safariの表示を「実際の大きさ」ではなく「拡大」して作業することが多い。どうやらこれが原因である。今日、やはりドラッグしてもアップロードボタンの色が変わらないという挙動があった後、何気なくSafariの表示を通常の大きさにしてから同じようにドラッグすると、ちゃんとボタンの色が変わる。拡大を一回しても大丈夫。しかし、拡大を2回押すと、ドラッグしてボタンの色が変わる位置が、ボタンより上側にずれる。さらに拡大すると、もはやどこにファイルをドラッグしてもボタンの色は変わらない。
                    ということで、Safariでアップロード用のボタンにファイルをドラッグアンドドロップするときは、通常の表示の大きさにするか、せいぜい1回だけ拡大した表示で行うことをお勧めする。ボタンからのずれを探るのもなかなか面白い作業ではあるけれど、作業効率は落ちるので。

                    ちなみにFireFoxではこうした現象は生じないようだが、ドラッグした位置が適切でもボタンの色が変化しないので、あまり感じがよろしくない。このへんの「感じ」が結構ものをいうんですね、これが。
                    | 清水敏 | パソコンなど | 17:05 | comments(0) | trackbacks(0) |
                    Word VBA ではまったこと
                    0
                      特許請求の範囲で「前記」「当該」などの前置語があるか否かを特許請求の範囲のテキスト上に表示するVBAマクロを作り、利用している。動きは以下のとおり。

                      最初に対象となるテキストを選択するダイアログを表示する。
                      ファイルが選択されたらそのテキストを読み、従属関係を解析して多数項従属を展開したツリーを作る。
                      ツリーの各ノードを展開したウィンドウを表示する。
                      ツリーの各ノードに対応するテキスト(「請求項1」などというテキストを表示している)をクリックすると、従属関係にしたがって独立クレームからそのクレームまでの経路のテキストを全て画面に表示する。
                      このとき、「前記」「当該」は赤字で表示、「当該」「前記」ののちに続く文字列は青でかつ枠で囲み、先行語は緑で表示する。

                      したがって、先行語の有無を調べるためには、各請求項をクリックして目で見て確認することになる。

                      これを便利に使っていたのだが、特定の案件の特許請求の範囲についてこの処理をすると、なぜか最初にツリーが表示されるときに、同時にあたかも自動的にある請求項がクリックされたように、その請求項のテキストが表示されてしまうことになっていた。他の案件ではこうした問題は生じない。請求項の文言を見ても特に他と異なるところはない。どうしても理由がわからないので、試みにツリーを表示するためのウィンドウを、それまではツリーが全て完成してから表示していたのを、最初にウィンドウを表示してからツリーを作成するようにしたところ、こうした問題は治まった。理由は未だにわからない。

                      また、以前からこのプログラムでは、最初にツリーのノードをクリックすると、そのときだけ請求項のテキストを表示するウィンドウ(ワードの文書)が、ウィンドウ(ダイアログ)の後ろに開かれてしまい、中身を見ることができないという問題があった。どうせ2回目をクリックすればちゃんと表示されるし、自分が使用するだけなのでこれまではほっておいたのだが、今日、ちょっと思いついて、ツリーのウィンドウを表示するに先立って、空の文書のウィンドウを開いておくことにしてみた。すると、ツリーを最初にクリックしてもちゃんとそのテキストがツリーウィンドウの前に表示されるようになった。これも正確なわけはわからないが、モードレスのダイアログは、どうしても犠牲にするウィンドウを1つ必要とするような感じである。もっとも、以前の動きは必ずしもそうとはいえず、ときどきはちゃんと開いたりしているので、謎は謎のままである。だれか明確に説明してもらえると非常に助かるのだが。

                      まあ、とりあえずこれでこのマクロについてはほぼ理想的な動きが得られるようになった。満足。

                      | 清水敏 | パソコンなど | 12:57 | comments(0) | trackbacks(0) |
                       123456
                      78910111213
                      14151617181920
                      21222324252627
                      282930    
                      << April 2019 >>
                      + 研修のお知らせ
                      (大阪中心)知財イベントカレンダーをご覧下さい。(別ウィンドウが開きます。)
                      + 補助金カレンダ(別ウィンドウが開きます)
                      補助金を網羅しているわけではありません。この情報については随時更新していますが、既に募集が終わっている場合も考えられます。自治体では予算を使い切ったら終了、というところもあります。この情報によって何らかの損害が生じても弊所は責任を負いかねます。必ず各自で情報の確認をお願いします。 愛知県 大阪府 兵庫県 京都府 香川県 静岡県 和歌山県 奈良県
                      + RECOMMEND
                      + RECOMMEND
                      + RECOMMEND
                      サイコパス (文春新書)
                      サイコパス (文春新書) (JUGEMレビュー »)
                      中野 信子
                      この本を読みながら、最近のニュースに出てきたあの人、この人を思い出した。ところで、サイコパスとは関係ないのだが、この本によれば日本は全世界の面積の0.25%しか占めていないのに、災害被害総額では15〜20%を占めているそうだ。最近の噴火、地震、豪雨の連続を見ていると納得してしまうが、一応この数字はどこかでチェックしておく必要がある。
                      そこで調べて見た。一般財団法人国土技術研究センターによると、世界における日本の国土の占める割合は0.28%だそうだ。Wikipediaでは0.25%と記載されている。ここは国土技術研究センターを信用したい。一方、内閣府によると、日本の災害被害額が世界の災害被害額に占める割合は16%だそうだ。この数字はちょっと古いが、それでも大筋で15〜20%という値は正しそうだ。
                      + RECOMMEND
                      + RECOMMEND
                      + RECOMMEND
                      + RECOMMEND
                      + RECOMMEND
                      + RECOMMEND
                      + SELECTED ENTRIES
                      + RECENT COMMENTS
                      + RECENT TRACKBACK
                      + CATEGORIES
                      + ARCHIVES
                      + 本の紹介
                      + MOBILE
                      qrcode
                      + LINKS
                      + PROFILE