shoda T.的うぇぶログ

26日、東京証券取引所は証券会社の受発注システムの一部を自社のデータセンターなどで預かり、取引所の売買システムに直接接続する「コロケーションサービス」を来年から提供すると発表した。
相場データや売買データの授受が高速化するため、相場状況からシステムが自動的に銘柄や発注量、発注のタイミングを計算する「アルゴリズム取引」の取引時間短縮につながるという。

コロケーションサービスは米国のニューヨーク証券取引所やナスダック証券取引所などがすでに提供している。

積極的にこの種の付加サービスを行うのは、世界的な取引所間の競争の激化と再編の波を乗り切るのに必要なことだろう。
とはいえ・・・東証の場合、その前に基幹となるシステムそのものの強化と安定化に注力する必要があるはず。付加サービスはその上で余力が出来てはじめて競争力となりうるのではないのか？
脆弱なシステムに屋上屋を重ねて証券会社まで巻き添えにしてしまったらどうするつもりなのだろう？

20日（現地時間）、米連邦裁判所は電子フロンティア財団（EFF）がUniversal Music Publishing Group（UMPG）を相手取って起こした訴訟で、コンテンツ企業は、著作権侵害を理由にWebコンテンツの削除を要求する前に、公正使用であるかどうかどうかを検討しなければならない、として、UMPGからの訴訟棄却請求を退けた。
この裁判は、UMPGが著作権を侵害していないビデオをYouTubeから削除させたのは言論の自由の侵害だ、としてEFFが起こしたもの。
（具体的に訴訟で問題となったのは、プリンスの曲に合わせて踊る幼児を写したホームビデオ。いったん削除されたビデオは再投稿されて現在観ることができる。
→ http://jp.youtube.com/watch?v=N1KfJHFWlhQ
観ればわかるが、完全に家族によるホームビデオであり、プリンスの曲にしても、ＴV(?)からの音声がバックでノイズ並みに流れている程度で、なぜ削除依頼したのかよくわからない。ＣＭかＰＶか何かと勘違いしたのだろうか？）

EFFは、「一部のコンテンツ保有者はデジタルミレニアム著作権法（DMCA）のプロセスで『先に撃っておいて後で質問する』方式を取っており、著作権を侵害しない公正使用に対する不適切な削除があまりに多くなっている」とし、この判決はインターネット上の言論の自由と公正使用の大きな勝利だとコメントしている。

18日、米FCC（連邦通信委員会）は2009年2月に迫ったテレビ放送の完全なデジタルへの移行（アナログ放送の終了）について、消費者の認知度を高めるために全米規模のキャンペーンを行うと発表した。

米国では半年先に迫ったアナログ波の停止だが、まだアナログ放送しか受信出来ない世帯が15%以上または10万世帯以上ある都市が全米で80以上存在し、その地域を中心にキャンペーンを展開するという。
さて半年でどれだけの効果が・・・

同様にアナログ波の停止を2011年7月に定めた日本は、生活保護世帯などへの地上デジタル放送チューナの無償配布を計画しており、この費用を国債でまかなう計画を立てているという。
アナログ波の使用している周波数帯の解放で利益を得るところもあるわけで費用負担についても、もう少し突っ込んだ議論があっていいのではないだろうか？

19日、経済産業省はアップルの携帯型音楽プレーヤ「iPod nano」の初期型で、計17件の加熱・焼損事故が起きたことを発表、バッテリ内部の欠陥が原因とみて利用者に注意を呼びかけた。
事故が起きたのは2005年9月から2006年9月に販売された第一世代の iPod nano。
いずれも充電中にバッテリが過熱して畳や紙が焦げたり、軽度の火傷や破損事故。

同省の発表を受けてアップルは20日、コメントとともに、同社の顧客窓口（AppleCare）を通じてバッテリ加熱を起こした製品を無償交換すると発表した。問題の製品はすべて同一供給元のバッテリを使用しているという。
今回の対応はあくまで自主対応で、リコールではない。また、交換に応じるのはあくまでもユーザがバッテリ過熱を感じたり事故を起こした製品のみ。

しかし・・・この時期の製品って、たしか他社のノートＰＣや携帯などでも過熱事故が相次いでいたような・・・もしかして同一製造元の同じラインの製品？？

8日、マイクロソフトは8月13日に公開予定のセキュリティ情報およびセキュリティ更新プログラム（修正パッチ）の概要を発表した。
セキュリティ情報は12件で、危険度が最高の「緊急」に設定されているものが7件、2番目に危険な「重要」に設定されているのが5件。いずれも「リモートでコードが実行される」危険性についてのもの。

Microsoft Update や Windows Update で「自動更新」に設定してあれば、特に意識しなくても自動更新されるが、この時期は夏期休暇の企業も多く、休み明けの週明けにアクセスが集中する可能性も大きい。
また、オリンピックを狙ったスパムも横行しており、それでなくともメール等のアクセスでネットが混雑する週明け・・・手動でアップデートの適用が可能であれば、早めに実行しておいた方がよさそうだ。

話題のGoogleのストリートビューだが、予想通りうちの事務所の窓も写っている。
片方が開いているので、たぶん５月か６月頃の映像だろうか。隣の建設中のマンションも、今よりまだだいぶ低い。

このストリートビューだが、どうやって作っているのか、技術的な関心も集めているようだ。
一説にはカメラを積んだ車で通りを走り撮影して回ったらしい。
しかし・・・Google だから、もう少しスマートな事をやってるのかと思って調べてみた。

が、やはりそういう泥臭くカネとヒマにあかしたゴリゴリなやり方をしてるようだ。実際に各地で目撃報告もある。
そういえば、元々の Google 本業の検索にしても、情報収集部分はチカラシゴトだったが。
これがカメラ↓

http://ekstreme.com/thingsofsorts/fun-web/chatting-with-a-google-street-view-driver

これはイギリスでの目撃報告＆運転手との会話報告だが、こちらに翻訳している人がいる。
日本での報告例もある。

んで・・・なんでがっかりしたかと言うと、最近の Google のソフトのアイデアや品質のよさから、もう少しスマートなことを想像していたのだ。
まぁ、アリテイに言えば、少し解像度は落ちるかもしれないが、この程度のビューであれば、画像変換だけで実現出来ると思うのだ・・・
Google には、それくらいのことはやってほしかった。

いやまぁ・・・深い意味はないんですが（笑

＃投稿時刻は「やらせ」です（ｗ

4日（現地時間）、米国の連邦控訴裁判所は、米国のケーブルテレビネットワークや三大テレビネットワークなどが著作権法に違反するとしてネットワークDVR（ビデオレコーダ）のサービス提供を計画していた米Cablevision Systems を訴えていた裁判で、訴えを退けた。

ネットワークDVRとは、家庭にあるDVRの代わりに、ネットワーク上に番組を蓄積しておき、家庭のSTB（セットトップボックス：子機）を操作して蓄積された番組を視聴出来るようにするというもの。
この判決で、事実上Cablevision Systems の計画にゴーがかかったようなもの。

日本でも、去る５、６月に録画番組の配信サービスに対する裁判で、限定的ながら合法判決が出ており、今後この分野でも進展がみられるだろう。
ただし、日本のケースは、いずれも主として海外居住者向けに、録画機をレンタルしたり預かってユーザ指定の国内の番組を録画するシステム。

日本デジタル家電が自社保有の親機をユーザにレンタルし、ユーザが購入した子機を通じて視聴するシステムについては複製権の侵害との判決が出ている。
一方、永野商店が行っている、ユーザが購入した親機と子機のうち、親機を預かり運用だけを請け負っているシステムに対しては、放送事業者の差し止めと損害賠償の請求は棄却されている。
この訴訟はまだ控訴が行われる見込みだが、もし今回の判決により米国で本格的なネットワークDVRサービスが始まった場合、日本でも同様のサービスを計画するところも出てくるだろう。

一方、NHKなどの放送事業者側も、放送済みの番組をオンデマンドで流すサービスを開始する予定にしており、いずれのシステムが残るとしても、放送時間や場所に拘束されずに、一般の放送番組をいつでもどこでも視聴出来る時代がもうすぐ来そうだ。

4日、NTT東日本およびNTT西日本は、ユーザに提供しているひかり電話対応ルータ（東日本）やVoIPアダプタ（西日本）の一部機種のファームウェア（ソフトウェア）に不具合があり、電源投入後約８ヶ月間連続使用した場合に、ひかり電話の発着信が出来なくなることが判明したと発表した。
該当する機器の台数はNTT東日本が約120万台、NTT西日本が約6万台。
→ http://www.ntt-east.co.jp/release/0808/080804a.html

このバグを修正したバージョンは7日から提供される予定で、オンラインでバージョンアップが行われる（ただし、バージョンアップの開始はユーザ操作が必要）。

今回の不具合は2月頃にユーザからのクレームがきっかけで検証をしたが、当初は現象が再現出来なかった。その後、疑似環境での接続テストやプログラムの変数変更等のテストでようやく判明したと言う。
具体的には、ファームウェアのタイマー機能において約249日（８ヶ月）でリセットされるべきカウンターがリセットされない実装になっていたのが原因という。そのため約８ヶ月間連続使用しなければ再現しない。

しかし８ヶ月で「リセットされるべき」カウンターとは奇妙な実装だ（笑
ま、発表はソフトに詳しくない人（それも複数人）を経てのものだから、曖昧な表現にならざるを得ないのかもしれない。
約249日と言うのは、おそらく10msec精度のタイマーで248日と13時間ほどの数値と思われ、二進数で31ビットで表わせる最大値となる。「リセットされるべき」となっているが、そうではなくてこの数値を超えると32ビットになり、32ビットで表現される内部カウンターを符号付きの数値として扱った場合には、負数となってしまい正しく判定出来ないのが原因と思われる。
つまり内部のタイマー設定値と比較すべき数値が負数なので、タイムアップ判定が出来ず、タイマー待ちのままとなるのが原因と思われる。

かつて、Windows3.1 でも同様の不具合で連続使用すると止まってしまったことがあるし、Windows NTではデータベースだったと思うが、ログ記録が出来なくなって使用不能になるトラブルもあった。
電源を入れっぱなしで使用するのが前提の機器としては、設計＆テストが甘すぎると言わざるを得ない。
もしソフト修正が公表されているように単純に「リセット」するだけの対策を行ったのだとしたら、この前後のタイマー判定がめちゃくちゃになるはずだ。
バージョンアップの約８ヶ月後に新たな問題が出なければいいのだが・・・

それにしても、東証のシステムと並んでNTTのひかり電話関係もまたトラブルの宝庫だと感心せざるを得ない(-_-;)