←EXIT   知的財産情報      TOP


ICON<特許戦略>

ICON<商標戦略>


ICONビジネスモデル特許
<ビジネスモデル特許/プロシジャ>
エピローグ
 最近、ビジネスモデル特許の講演会に何回出ても、我が社のビジネスモデル特許を取得する方法がわからない……という意見をよく聞きます.

現状:
ビジネスモデル特許の評論、動向講演は多くある。
しかし、講演会に出ても、我が社でビジネスモデル特許を取るには、どうするかの示唆は得られない

理由:
現状の講演会/典型パターンは、
@日本の発明、米国の発明の概略説明
A?米国におけるビジネスモデル特許の動向と現状
Bビジネスモデル特許の例(日本および米国)

つまり、湾岸戦争にたとえると、
従来の講演会は
湾岸戦争の戦況分析、戦況説明、評論をしているに過ぎず、これでは戦争(つまり、ビジネス戦争)には勝てない。


企業が知りたいのは、ビジネス戦争に勝てるノウハウ

湾岸戦争にたとえると、
戦況分析から戦略を企画し、戦争に勝つ兵器を開発(
ビジネスモデル特許を取得)して戦争(つまり、ビジネス戦争)に勝ち、利益を上げることである.


戦況分析という従来型講演会から、抜け出て、市場の視点にたちネット事業を特許の観点から分析/特許構築し、ビジネスモデル特許取得に至るプロセスを分かりやすく説明するスタイルが求められている.


●そこで、どうするか
(A)
ビジネスモデル特許の戦況評論は、既存の情報ソースで十分とする

(B)市場への目のつけどころ

(C)ビジネスモデルを構築する手順と行動力

(D)我が社のネット事業の分析(企画立案中も含む)と特許取得プロセス


戦況評論を聞くより、我が社に特化した行動手順を練る.
戦争は弾を撃ちながら、兵器を開発し、訓練し、作戦を練るもの.

相手は、弾を撃つのを待ってくれない(従来型の講演会で戦況評論を聞いている隙に、相手はビジネスモデル特許取得のノウハウを得て、兵器を開発している.一方、我が社は、依然として、戦況評論を集めているに過ぎない).

以下、続く



 


<オブジェクト指向プログラムの特許戦略>
ICONコンポーネントウエアの特許戦略
オブジェクト指向プログラム

第1弾
オブジェクト指向に基づく、発展形態としてコンポーネントウエアがあります。
 コンポーネントウエアは、ハードウエア部品(例えば、ICチップ)のように組み込んですぐに使えるプラグアンドプレイ型ソフトウエア部品の概念を中心とするソフトウエア開発技術です。


背景
  MS社のWIN95、NT(登録商標)を動作環境とするマシンが広く提供されるようになり、いわゆる共通プラットフォームとして、この上にビジュアルベーシック等のオブジェクト指向プログラムを使用してエンドユーザが比較的容易にソフト部品を構築できるようになってきました。
  そのようなソフト部品の特許戦略が現在およびここ2、3年は重要と考えられます。


 パソコンの発展、オブジェクト指向の基盤技術の発展および標準化により、 多種多様なソフト部品が開発されつつある。
 このようなオブジェクト指向プログラムに対してどのように特許をとっていくかは、企業にとって重要。


基盤技術 コンポーネントウエアを実現する代表的なものには、Active X 、CORBA、 Java等がある。


 ズバリ!
 マイクロソフト社が世界一の利益をほこるのは、オブジェクト指向をディフェクトスタンダードにしたから


日本オラクル、ヤフー等の株が異常?にたかい。
コンポーネントウエアで優れた特許を取得し、それが特定分野のディフェクトスタンダードになると、利益日本一になる可能性もある。
 それは、すぐれたアイデアを、認識できる組織にかぎられる。
 どこか?


第2弾

オブジェクトに注目
   

   

オブジェクトによるプログラムモジュール
   
   

   
↓    比較:
    
↓    従来ソフト=例えていうと、モノリシック基盤のようなもの
    ↓     欠点→
    ↓     これは、手間がかかる。
    ↓     バグがある。
    ↓     手作り、労働集約型産業であった。

近時、オブジェクト指向プログラムによるソフトが注目される。ただし、理論は30年前からあった。
    ↓
  これは、ソフトがICのようになるものである。
  →オブジェクト指向プログラム=IC部品というイメージ
                   
 すなわち、パッケージソフト部品 
         特長→
        
高品質
        知識集約型

      

      ↓
 特許戦略! が重要になる。


手続き型プログラミング言語
 まず、プログラムの変遷を考察すると、

 いままでのコンピュータプログラム
 →手続き型プログラミング言語



 
ノイマン型アーキテクチャ(現在使われているほとんどのコンピュータ)であった。

特長:プログラム内蔵方式→→データと手続きを主記憶上に展開
 

    逐次処理方式→→→プログラムカウンタにより、時系列的に命令を実行
  

   情報要素:記憶装置と演算処理装置により操作されるデータ、およびプロセスという2つの情報要素を持ち、それらの間で直列的に処理を行う。


   プログラム→命令を伝達するために用いる。

   プログラムの記述手段→プログラミング言語
    データ→変数
    プロセス→関数手続き、プロシージャ

  
システムは変数と関数の集合体として記述
    自由度は高い→計算機ができることであれば、基本的にすべて記述できる。


      しかし→→→→→記述の自由度のために、
                 プログラムの品質低下
     
     代表的なプログラムは、例えば
     FORTRAN

     COBOL
 


    特許的には、
   
    クレームは、コンピュータの実行する機能を手段として捉え、

    手段(mean)クレームで構成。
 
    開示は、ブロック図とフローチャートで行う。

     ソフトの内容にもよるが、基本的に審査基準でも、確立。


構造化プログラミング言語

次に、構造化プログラミング言語が開発された。
主に軍事面から構造化技術が開発され、記述の自由度を制約した。
    すなわち、データ構造と、制御構造に特定の制約を付加

       →プログラムの信頼性を高める。
      この構造化技術を言語仕様に取り込んだのが構造化プログラミング言語
       PASCAL
       Ada


      システムは、制約された変数と関数の集合体として記述                       プログラムの信頼性向上を図る。


      しかし→→→→→プログラミング言語が計算機のメカニズムを反映したものである点では、基本的に手続き型の言語

   特許面:手続き型プログラミング言語と同様
   


オブジェクト指向プログラミング言語
   →計算機の機構に対応したものではない


   特長: ハードウエアを反映した変数と関数という要素とは、まったく無関係にオブジェクトという要素によりシステムを構成する技法
    
    
システムはオブジェクトという要素により構成

     ハードウエアの制御という旧来のプログラミング言語の目的を
     もっていない。




   オブジウェクト指向技術は、ハードウエアの機構とは無関係

  例えば→
Smalltalk     純粋なオブジェクト指向プログラミング言語    
        C++     手続き型の中にオブジェクト指向機構を                  取り込んだ複合型のプログラミング言語

 



 特許:

    クレームは、オブジェクトが中心

   プログラムモジュールで構成、内容、分野の特定。

    開示は、例えば、オブジェクトの内容、プロパティ、メソッド、イベント等

    メソッドはフローチャートもありえる。
    まだ審査基準での見解には至っていない。
    しかし、オブジェクト指向技術に気付いた企業からは、多くの出願が予想される

    現在→米国企業の出願が多い。
    例えば、サン、IBM、

   きずいていない企業→→→とりのこされるおそれあり。


信頼性が向上したのは何故か?
   ↓
   ↓
   オブジェクト内部の変数に対して、外部から直接操作ができない機構にした。
   ↓
   ↓
 情報隠蔽→→変数と関数のカプセル化
   ↓
   ↓
 端的には、これによってオブジェクトを用いたプログラムの信頼性をあげた。


コンピュータ面:

オブジェクトは、「記憶領域と手続きの論理的な組織体」

プログラム上は、変数宣言と、それらに対する操作関数の宣言を組織化した
もの
 →→組織化→→→カプセル化という


考察:
  現在の計算機はデータと手続きにより記述されるノイマン型アーキテクチャを 持ち、
 それ以外の形態では情報を保持できない。

  オブジェクト自体は、ノイマン型計算機の記憶空間上に変数や関数と同じように実際に存在はしない。

  ある処理手続きによって操作される記憶領域とその手続きの組織体を、
  あくまで論理的にオブジェクトと称している。
   ↓
   ↓
   ↓
   例えば、画面上にボタンや、タイマを作るオブジェクト


オブジェクト指向に基づく、発展形態としてコンポーネントウエアがある。
   ↓
   ↓
  コンポーネントウエア
   ↓
   ↓
  コンポーネントウエアは、ハードウエア部品(例えば、ICチップ)のように組み込んですぐに使えるプラグアンドプレイ型ソフトウエア部品の概念を中心とするソフトウエア開発技術


  背景
  ↓
  ↓
  前述したように
  MS社のWIN95、NT(登録商標)を動作環境とするマシンが広く提供されるようになり、いわゆる共通プラットフォームとして、この上にビジュアルベーシック等のオブジェクト指向プログラムを使用してエンドユーザが比較的容易にソフト部品を構築できるようになってきたもの。
  ↓
  ↓
 低コストどの普及
 ソフトの部品化
 ビジュアル操作


コンポーネントウエアの特長
 
 
ソフトをICのように部品を組み合わせて構成することが可能になった。
  (これは、ソフトウエアの昔からの夢である)
   

    
従来:ソースコードの再利用
          →→→力に任せて一からコーディングを行っており、
              生産性、品質、開発期間の短縮が望みがたい。


   
最新技術:
      ↓
      ↓
    複数のオブジェクトを部品としてパッケージ化する技術を提供し、
    かつ、これら部品間の共通のインターフェースの標準化を図る。
      ↓
    特に、インターネット上での部品の組み合わせを行うことも可能になる。



 特許対策

  
パソコンの発展、オブジェクト指向の基盤技術の発展および標準化により、
   多種多様なソフト部品が開発されつつある。
   ↓
   ↓
  このようなオブジェクト指向プログラムに対してどのように特許をとっていくかは、
  企業にとって重要。


  
コンポーネントウエアを実現する代表的なものには、Active X 、CORBA、 Java等がある。  



   問題は、純粋的なソフト業界でなく、
    民生、産業分野の多くで、オブジェクト指向プログラムが用いられつつあり、
  それらの特定分野でどのようにソフト部品として保護(特許化)するかである。
   ↓
   ↓
  ソフト部品は、汎用性もあるので、例えば自動車業界で開発したオブジェクトソフト部品は、石油精製プラント業界、繊維業界でも用いられて効果的なこともありえる。
    例えば、ソフト部品を特定機能ICのように特許化      



特許の取り方


(あくまで一例)

1.文書指向・タスク指向
 ユーザ指向設計であり、例えばアプリケーションは複合文書の概念で抽象化される(例えば、Webページ)。
   従来のプログラムを中心とするアーキテクチャと異なり、タスクの記述により、アプリケーションを設計する。
  設計の中に、新規なものがあり、その程度が高いと特許の可能性があると考えられる。



2.プラグアンドプレイ型部品の組み立て開発
 
これは、部品のインターフェースによって設計を行うので、インターフェース指向となり、ソフト部品として単独で特許がとれそうである。

3.アーキテクチャ指向開発
 通常、部品を組み合わせる核となるソフトウエアアーキテクチャは、フレームワークとして提供される。
 ソフトウエアアーキテクチャを設計したり、コンポーネントウエアに付随するソフトウエアアーキテクチャに基づいてアプリケーションを開発するが、このようなアーキテクチャの部分での開発で特許がとれる可能性がある。


4.ネットワーク指向ソフトウエアアーキテクチャ
 分散オブジェクト環境やJavaなどのネットワーク上でアプリケーションを構築する場合、ネットワーク上に分散したコンポーネントが連携して、ソフト部品、アプリケーションなどを実現するとき特許の可能性がある。


5.ビジュアル開発
 
画面上でコンポーネントを組み合わせて、例えばハードのパーツをつなぎあわせる如く、ソフトを構築できるが、そのようなソフト部品も特許の可能性がある。

6.インクリメンタル開発
 
部品を組み合わせてさらに高度な部品を作れ、そのため機能を段階的に増やすことが可能になる。このようなインクリメンタル開発でも、段階的な部品も含めて特許が取れる可能性がある。
 従来のようにソフトウエア全体を一度に開発する苦労の多いビッグバン開発に比べて、必要な部品を段階的に開発でき、例えば優先度の高い機能を短期開発できるとともに、開発期間も短縮する。


  続く!!


21世紀は、より高度なエージェント指向(人工知能)
さらにその上の指向も予想される
  ↓


ICON

  


  

 ←EXIT                             TOP→