PROVISIONAL PATENT APPLICATION TRANSMITTAL
`
`This is a request for filing a PROVISIONAL APPLICATION under 37 CFR 1 .53(b)(2).
`
`!~ _,/)"
`
`Docket
`Number
`
`RAPD-200
`
`Type a plus sign I+)
`inside this box - >
`
`+
`
`'
`
`INVENTOR(s)/APPLICANT{s}
`
`RESIDENCE (CITY AND EITHER STATE OR FOREIGN COUNTRY)
`
`20842 Maureen Way, Saratoga, California 95070
`
`g: FIRST NAME, MIDDLE INITIAL, LAST NAME
`
`:1
`u,
`~
`
`g ~ JungJi John Yu
`
`2.
`3.
`4.
`5.
`
`TITLE OF THE INVENTION 12ao characters maxi
`
`POLICY ENGINE ARCHITECTURE
`
`CORRESPONDENCE ADDRESS
`
`Alan S. Hodes
`Limbach & Limbach L.L.P.
`2001 Ferry Building
`San Francisco
`Phone: 41 5/433-41 50; Fax: 415/433-871 6
`
`STATE
`
`I CA I ZIP CODE
`
`I 94111-4262
`
`I COUNTRY
`
`I
`
`U.S.A.
`
`ENCLOSED APPLICATION PARTS (check all that apply)
`
`X
`
`Specification
`
`Number of Pages
`
`10
`
`X
`
`Small Entity Statement
`
`Drawing(s)
`
`Number of Sheets
`
`Other (specify):
`
`METHOD OF PAYMENT (check one)
`
`X
`
`X
`
`A check or money order is enclosed to cover the Provisional filing fees.
`
`is hereby authorized to charge any
`The Commissioner
`additional filing fees and credit Deposit Account Number:
`
`12-1420
`
`PROVISIONAL
`FILING FEE
`AMOUNT(S)
`
`$75.00
`
`The invention was made by an agency of the United States Government or under a contract with an agency of the
`United States Government
`
`~No. CJ Yes, the name of the U.S. Government agency and the Government contract number are:
`
`Respectfully submitted,("\
`
`\
`
`\
`
`SIGNATURE:----~------------(cid:173)
`TYPED or PRINTED NAME: Alan S. Hodes
`
`Date: December 17, 1998
`REGISTRATION NO. (if appropriate): 38, 185
`
`CERTIACATION UNDER 37 CFR § 1.10
`I hereby certify that this New Provisional Application and the documents referred to as enclosed herein are being
`deposited with the United States Postal Service on this date December 17. 1998, in an envelope bearing "Express Mail
`Post Office To Addressee" Mailing label Number EL186214025US addressed to: Box Provisional Patent Application,
`Assistant Commissioner
`for Patents, Washington, D.C. 20231.
`
`SIGNATURE: C ~~ ,,f.__,
`
`Modified PTO/SB/1616195) - PATENTS\PROV-APP.MRG
`
`Date:
`
`l~/17/t::f P
`
`Rav. 12./09197
`
`EX 1012 Page 1
`
`

`

`PROVISIONAL APPLICATION FOR PATENT
`
`POLICY ENGINE ARCHITECTURE
`
`Atty Docket:
`
`RAPD-200
`
`This document describes the system architecture of an embodiment of an inventive policy-based network equipment. This
`system architecture is suitable for policy-based applications such as Virtual Private Networks (VPN), Firewall, Traffic
`Management, Network Address Translation, Network Monitoring, TOS Marking, etc. The architecture includes three major
`components - Policy-Based Application, Policy Engine API and a Policy Engine. Of course, each of these components may be
`inventive in and of itself.
`
`Policy-based
`application
`
`Policy Engine API
`
`System
`Bus
`
`,
`Control Path
`
`Data Path
`
`Input port
`
`Policy Engine
`
`-
`Output port
`
`Fig. 1 - Block Diagram
`
`Policy-Based Application: A policy-based application such as firewall, VPN, or traffic management is typically a software
`program residing on a host, equipped with its own policy data base and flow classification logic. The policy-based application
`typically has access to the media through an OS driver interface. It examines every packet coming in from the network along
`the data path, compares it against the flow classification criteria, and performs the necessary actions based upon the policies
`defined in the policy database.
`
`Policy Engine API (PAPI): This API serves as an interface to the policy engine. It allows the policy-based application to
`access to all the media I/0 through a generic OS driver interface. In addition, the API allows the application to invoke the
`acceleration functions provided by the policy engine. The application can speed up the overall system performance by turning
`on the appropriate acceleration functions (action processors) on the policy engine.
`
`Policy Engine: A Policy Engine is a purpose-built hardware engine that takes in two inputs - network traffic and network
`policies. It then outputs regulated traffic flows based upon the specifications of the network policies. The Policy Engine
`preferably runs at wire speed.
`
`Before describing a detailed embodiment, several terms are defined.
`
`Service
`
`Policy
`
`A Service in a policy-based network defines a network application that is controlled and managed by a set of policies.
`Typical services are firewall, VPN, traffic management, network address translation, network monitoring, etc.
`
`A Policy is defined by network managers to describe network traffic behaviors based upon business needs. It specifies
`what types of traffic are subject to policy control and how to control them. A policy has two components: Flow
`Classification Spec and Actions Spec.
`
`-1-
`
`EX 1012 Page 2
`
`

`

`Flow Classification Spec
`Flow Classification Spec provides the screening criteria for a classifier to sort the packets of network traffic into
`flows. The Flow Classification Spec can be very elaborate. They can be as detailed as defining a pair of hosts running
`a specific application. Alternately, they can have a simple wildcard expression.
`
`Action Spec
`Action Spec is to describe what to do with packets that match the Flow Classification Spec. The Action Spec can be as
`simple as a discard or forward decision in the firewall case. It can also be as complicated as IPSec encryption rules
`based on SA (Security Association) spec.
`
`Flow
`
`Stream
`
`All packets that match the same Flow Classification Spec fonn a Flow.
`
`A Stream is a stream of packets that have the same source and destination address, source and destination port, and
`protocol type. (Optionally, the application can add the input and output media interface to the stream classification
`criteria in addition to the packet header if desired.) RapidStream policy engine sorts packets into Streams. A flow may
`include of one or more Streams. All packets belong to the same Stream share the same policy.
`
`Stream Spec
`A Stream Spec is the criteria used by the Stream Classifier to uniquely identify a stream. In one embodiment, it is the
`5-tuple in a packet header
`source and destination address, source and destination port, and protocol type.
`
`Integrated Services
`When multiple network services are to apply to the same flow, it is called "Integrated Services". Integrated Services
`simplify the management of various service policies, minimize potential policy conflicts and reduce TCO (Total Cost
`of Ownership).
`
`Flow Classifier
`In a typical conventional policy-based network, a policy decision is typically derived from a policy database. As
`discussed above, a flow is a stream of correlated packets to which policy decisions apply.
`
`When a packet arrives, a flow classifier typically classifies the packet and fmds a action spec according to some
`predefmed matching criteria. The found action spec is then passed to a action processor for policy enforcement. The
`process of flow classification and action processing may repeat for many iterations as multiple policies are activated at
`the same time as shown in the Fig 2. For example, a VPN (virtual private network) application may comprise
`Firewall Policy, IPSEC Policy, IPCOMP ( IP compression) policy, NAT (Network Address Translation) Policy, QoS
`(Quality of Service)policy, Monitoring Policy, L2TP/PPTP (L2 Tunnel Protocol/ Point To Point Tunnel Protocol)
`Tunnel Policy, and so on.
`
`!'"""'"""""""""""""""'''''''''''"""'''''''''''''''''''''''''''"'''''''''"""'''''''''''"'''''""''''"""'"''"""""''''''''''''''"''''"""'"'""'"''''"''''''''''''"""""""""""""""""'""""""""""""""'"'"''''''''''''''''''''"'"'""""'""""""""""""""""""";
`
`!
`
`I
`
`:
`
`i
`'
`I
`I
`i
`;
`I
`I
`l
`i
`I
`I
`.
`
`I
`
`:
`
`i
`
`I
`
`i
`I
`I
`I
`I
`I
`I
`I
`i
`I
`
`I
`I
`
`!
`
`Packet
`
`flow
`classifier 1
`
`Decision
`
`action
`processor 1
`
`~~
`
`Packet
`
`flow
`classifier 2
`
`Decision
`
`action
`processor 2
`
`n
`
`Packet ~:ifier Decision ;::sor
`
`
`
`I>
`
`O
`
`= ..........................................................................................................................................................................................................................................................................................................................................................
`
`Fig. 2 - Example of Flow Classification and Action Processing in Typical Conventional Policy-based Network
`
`-2-
`
`EX 1012 Page 3
`
`

`

`The flow classification is a rule based operation can be very flexible to tune to application needs. For example, it may
`defme a rule to identify packets with a pattern of any random bytes within a packet, and/or across many packets. The
`flow classifiers may also differ per action processor for perfonnance optimization.
`
`As a result the matching criteria used by a flow classifier to classify a flow may include a specific value, a range, or
`wildcard on interface port numbers, protocols, IP addresses, TCP ports, applications, application data, or any user
`specifiable criteria. The distinctions of various implementation makes it difficult to cache a flow with its decision in
`many ways.
`
`Stream Classifier
`Stream Classifier is the component that classifies packets into Streams based upon the packets' header info.
`
`Action Processor
`Action Processor is the component that executes the action based upon the action spec.
`
`Policy Binding
`Policy Binding is the process to bind a stream with its associated action specs.
`
`Policy Cache
`At the completion of the policy binding process, an entry for a given Stream is created on the policy engine which
`contains all the policy info (Action Specs, etc.). The collection of all active entries is called Policy Cache.
`
`Packet Tagging
`Certain applications (e.g. Network Monitoring) would like to receive flows based on the flow classification spec and
`would prefer the policy engine to do the flow classification for them. Packet Tagging is a way of tagging all incoming
`packets with an application specified "tag".
`
`Now, some Policy Engine design considerations are discussed.
`
`Today's policy-based applications are challenged with several key issues. These issues can be major inhibitors for the future
`growth of the emerging industry:
`
`1) flow classification overhead Flow classification specs can be complicated and lengthy for each network service. Each
`packet needs to be compared with potentially hundreds of rules in order to fmd the matching one and determine the proper
`actions. With stateful applications, state tracking is even more time consuming. Multiple network services on a same
`system simply make matters worse.
`
`2) flow classification technique is evolving - Flow classification and analysis technique is more than just looking into the
`packet's address, port number and protocol type and or other header information. It often involves state tracking for newer
`applications. This technique is a continuous improving process and not suitable for hardware based implementation. And
`most importantly, flow classification techniques are often viewed as the key differentiators for vendors.
`
`3) action execution speed - Once the classification process is complete, the proper actions need to take place. Some of the
`actions are simple like discard or forwarding decision for firewall, while some others are extremely time consuming like
`triple-DES encryption and SHA hashing algorithm or QOS scheduling algorithm. Software based implementations cannot
`keep up with the bandwidth expansion as the industry moves into newer and faster media technologies.
`
`4)
`
`integrated services - As more and more policy-based applications become available, it is desirable to provide integrated
`services on a single platform because it reduces policy management complexity, avoids potential policy conflicts, and
`Jowers the TCO (Total Cost of Ownership). On the other hand, integrated services impose a huge computing power
`requirement that simply can not be achieved with off-the-shelf general purpose machines.
`
`A policy engine is designed to address some or all of the above performance considerations. It preferably comes equipped with
`a Policy Engine API (PAPI). PAPI design takes into account the following considerations:
`
`1) Time-to-market for application developers - Understanding that time-to-market is a major concern for the application
`vendors, PAPI design preferably minimizes the development effort required by the application developers in order for the
`existing applications to take advantages of policy engine's performance.
`
`-3-
`
`EX 1012 Page 4
`
`

`

`2) Maintain flexibility for developers' value-added - PAPI may allow application developers to enhance or maintain their
`value-add so that vendors' differentiation is not compromised.
`
`3) Platform for integrated services - PAPI has the model of an integrated services platform in mind. Application developers
`can over time migrate their services into an integrated platform without worrying about the extensibility of the API and the
`performance penalty.
`
`Components of a detailed embodiment are now described.
`
`Policy-based
`applications
`
`Flow
`classifier
`
`Policy Database
`
`Classification Spec Action Spec
`
`,...,
`"'"
`
`II'"
`
`System
`Bus
`
`~ ,
`
`Control Path
`
`Polley Engine API
`
`Policy Engine
`
`SC: stream classifier
`AP: action processor
`
`Data Path .u SC
`
`AP M AP ~AP~
`, , Act specl
`
`H
`
`Stream spec
`
`Act spec2
`
`~
`
`.......
`.......
`.......
`.......
`.......
`
`Fig. 3
`
`Policy-based Application
`
`Policy Cache
`
`A policy-based application provides a service to the network users. This service is managed by a set of policies. Firewall, VPN
`and Traffic Management are the most typical policy-based applications. As the industry evolves, policy-based applications are
`likely to consolidate onto a single platform called Integrated Services. Integrated Services has the benefits of centralized policy
`management and lower cost of ownership.
`
`A policy-based application is typically equipped with its own policy database and flow classifier. A policy database contains a
`list of policies. Each policy has two fields - the flow classification spec and the action spec. The flow classification spec is
`used by the flow classifier to sort the incoming network traffic into flows. The action spec is to instruct the application what to
`do with the packets associated with that flow. The application performs the proper actions against the packets based upon the
`policy database for each flow. The massaged packets are then forwarded to the destination.
`
`This is shown to a different level of detail in Fig. 4:
`
`-4-
`
`EX 1012 Page 5
`
`

`

`fl
`flow
`C
`~~~~~~~~~~~--+~___,__ classifier
`
`flo
`
`Classific. spec (n,1)
`Classific. spec (2, 1)
`Classific. spec (1, 1)
`
`Classific. spec (1,2)
`
`action spec (n, 1)
`action spec (2, 1)
`
`action spec ( 1, 1)
`
`action spec ( 1,2)
`
`Packets
`
`Stream spec, action spec(l,al), action spec(2,a2), ...
`
`Classific. spec (1,n)
`
`action spec (1,n)
`
`Agent
`
`First few Packets
`
`Packets
`
`Policy Engine
`
`stream spec ( 1 )
`
`stream spec (2)
`
`act spec(1,a1) act spec(2,a2)
`
`act spec(l,bl)
`
`act spec(2,b2)
`
`act spec(n,an)
`
`act spec(n,bn)
`
`stream spec (3)
`
`act spec(l,zl)
`
`act spec(2,zl)
`
`act spec(n,zn)
`
`Fig 4
`
`Policy Engine
`
`The policy engine has a built-in Stream Classifier and multiple of special purpose Action Processors. The stream classifier
`works in concert with the application's flow classifier to accelerate the classification process. The action processors are
`specialized in executing specific action specs at the wire speed. Each of the action processors can be enabled or disabled on a
`per stream basis. The policy engine uses a data structure called Policy Cache to keep track of all the active streams and the
`action specs associated with the streams. The policy cache is created on the fly by the policy engine and they are referenced by
`the stream classifier and the action processors for acceleration of action execution. This data structure can be managed and
`controlled by the application through the policy engine APL
`
`-5-
`
`EX 1012 Page 6
`
`

`

`Enabling the Policy Engine, in one embodiment, is now described.
`
`Policy-based
`application
`
`Flow
`classifier
`
`Policy Database
`
`Classification Spec Action Spec
`
`System Bus
`
`Policy Engine
`
`SC: stream classifier
`AP: action processor
`
`SC
`
`AP
`
`AP
`
`Fig. 5
`
`Policy Cache
`
`The policy engine is enabled through the policy binding process. This process is to bind an incoming stream with its associated
`action specs. This process may be broken down into 3 phases:
`
`Phase 1 - Policy Learning
`When the first packet of a new stream arrives, it is passed up to the policy-based application (generally a legacy
`application) for flow classification. The application classifies the flow by matching the incoming packet against the
`policy database. If the packet matches one of the policy's classification spec, the corresponding action spec is then
`retrieved and thus completes the policy learning phase. More packets may be used. In fact, it may take multiple
`packets for more sophisticated flow classification (stateful packet inspection), since the policy decisions (action specs)
`may come from different applications which may have implemented different flow classifiers. In those cases, the
`application's flow classification logic keeps track of the flow's state until a matching criteria is met.
`
`As shown in Fig. 5, in one particular implementation, a stream oriented table is implemented as the policy cache to
`cache the policy (action specs) on a per stream basis. A network stream has a finer granularity than flow criteria used
`by flow classifiers to uniquely identify a traffic. As the first packet of a flow arrives, the hardware forwards the
`packet to the host software module and requests for policy decisions (action specs). After having the packet classified
`by flow classifiers, the Agent collects the policy decisions and offloads them to the policy engine along with a stream
`spec which is used to identify a stream. Policy engine then creates a stream entry according to the stream spec and
`records it and its action specs in the entry.
`
`Phase 2 Policy Binding
`At the end of phase 1, the application software has uniquely identified a policy for the incoming packet stream. The
`application can then accelerate the execution of the actions associated with the stream by offloading the action spec
`from the application to the policy engine. This process is called policy binding - it binds a unique stream, which is
`identifiable with the packet's header (e.g., 5-tuple), with the action specs retrieved from the policy database. The
`action specs activate the corresponding action processors to execute the actions for the specified stream.
`
`-6-
`
`EX 1012 Page 7
`
`

`

`Phase 3 - Policy Execution
`Upon the completion of policy binding process, the policy engine may immediately take control of the bound stream
`and execute the appropriate actions per action specs (e.g., in the policy cache) without any intervention from the
`"host'' (policy-based) application. The application need not "see" any packets belonging to that stream after the
`binding (unless the stream is actually destined for the host.).
`
`This method leads to a seamless integration with various implementations of policy-based applications. The
`applications are benefited of high performance, ease of integration and time to market.
`
`This method also relieves hardware from doing complicated pattern matching because it can simply compute a hash
`value (or use some other identification function) from the well known fields (which uniquely identify a stream) of the
`packet to find its corresponding policy decisions (action specs). So it does not require a massive computing power to
`do the classification and the classification need not be done more than once for each packet even though there may be
`multiple applications. A benefit is inexpensive hardware cost for very high performance policy-based applications.
`
`All of the preceding has been disclosed in a co-pending provisional application. The current provisional application is to focus
`on one aspect of the policy engine itself: namely, the architecture of the policy engine itself from a system level. One
`challenge of this (or, in fact any) hardware assisted solution is not only that it has to maximize parallelism among different
`policies enforcement, but also that the architecture requires flexibility among order of policies enforcement. This is because the
`policy enforcement is usually order sensitive. (For example, decryption of packets need to be performed after firewall policy
`enforcement for incoming traffic to an corporate network.) 1n addition to being order sensitive, the architecture needs to allow
`new policies to be added which are sometimes not known at the product release.
`
`-7-
`
`EX 1012 Page 8
`
`

`

`Policy Engine Architecture
`
`Stream Classification
`Module
`
`Packet
`Input/Output
`Module
`
`Packet
`Scheduler
`
`On Chip
`Packet Buffers
`
`Policy Enforcement
`Module
`
`-~·-
`ij\temal
`Racket
`imory
`
`Fig. 6
`
`Embedded
`CPU
`
`Action
`Processor A
`
`Action
`ProcessorB
`
`• • • •
`
`Action
`ProcessorN
`
`-8-
`
`EX 1012 Page 9
`
`

`

`12-byte Packet Service Header
`
`4
`
`8
`
`4
`
`8
`
`4
`
`8
`
`4
`
`8
`
`4
`
`8
`
`4
`
`8
`
`4
`
`8
`
`4
`
`8
`
`8-bit Cell Service Header
`
`2
`
`1
`
`1
`
`4
`
`'I
`
`P,~et Service Header: 12-byte Packet Service Header is stored in the On Chip Packet Buffers. One Packet Service
`H~~er is generated per incoming packet.
`
`tf.::;: Ai!~ ID : The #x Action Processor ID.
`Afix Ptr: A pointer to Action Processor's action spec (e.g. DES key) of the #x
`
`C~Jl Service Header: For the purpose of creating deep pipeline to maximize the policy engine performance. Packets are
`fr~gmented into fixed-sized cells. One-byte Cell Service Header is attached to each cell and travel along with cells to the
`Act!on Processors.
`
`P)a # : Relative Packet number to ensure packet ordering. Pkt # is given when copied to
`'I
`On Chip Packet Buffer., 00 > 01 > 10 > 11 > 00
`· -
`Start : First cell of a packet
`Stop : Last cell of a packet. If both Start and Stop bit cell, packet size is equal to or smaller than a cell ( 64 B ).
`Next AP : Next Action Processor to perform on the cell. "0000" indicates completion of all action processing.
`Hop Policy Enforcement unit.
`
`-9-
`
`EX 1012 Page 10
`
`

`

`EMBODIMENT OF PRESENT INVENTION
`
`As illustrated in the Policy Engine architecture block diagram, in accordance with one embodiment includes a Packet
`Input/Output Module, a Stream Classification Module, and a Policy Enforcement Module.
`
`The Packet Input/Output Module places the received packets in the external packet memory and notifies the Stream
`Classification Module of such packets. Upon completion of all policies enforcement, Packet Input/Output Module transmits the
`packet from external packet memory to the network.
`
`The Stream Classification Module, based on the policy cache, creates a Packet Service Header for each packet. The Packet
`Service Header indicates what policies need to be enforced,
`in what order, and it is software programmable. The Packet
`Service Header includes a number of pairs of AP ID and AP Pointers. An AP ID uniquely defmes an Action Processor, and the
`AP pointer points to the Action Spec required to enforce such policy. An example of an action processor is a DES engine
`which needs a 56-bit or 112-bit key to do the encryption or decryption. The policy cache can be modified if network
`requirements changes. In addition to that, the order of different policy enforcement can also be programmed to achieve
`different application requirements.
`
`The Policy Enforcement Module includes a Packet Scheduler, an On Chip packet Buffer(s), and several Action Processors.
`The Packet Scheduler copies packets from external packet memory to On Chip Packet Buffer. After copying the packets to the
`Packet Buffer, packets are fragmented into 64 bytes cells. An 8-bit Cell Service Header is added to the beginning of each 64-
`byte cell. The Cell Service Header has a packet Number to uniquely identify a packet in the Policy Enforcement Module
`pipeline and a Start and Stop bit to indicate the first and last cell of a packet. A Next AP field , together with the AP IDs in the
`Packet Service Header, tells the Policy Enforcement Module where is the next destination Action Processor of each cell.
`
`It is preferable to have the On Chip Packet Buffer because it allows Action Processors very low latency and high bandwidth
`access to the packets as compared with external Packet Memory. In case the next Action Processor is busy for a cell, the On
`Chip Packet Buffer serves as temporary storage for that cell. This prevent the blocking of following cells which need to go
`through this particular Action Processor. Each Action Processor performs a particular policy enforcement. In addition to this, it
`is capable of reading the required action spec based on the AP pointer on the packet Service Header. Each Action Processor
`may also have an input and output FIFO to buffer the cells.
`
`Each cell is routed to the next Action Processor based on the Packet Service Header and Cell Service Header. The cell routing
`is preferably distributed to each Action Processor, instead of being centralized to a cell routing unit. This distributed approach
`allows for adding and removing policies much more easily. Upon completion of all policy enforcement for a particular packet,
`the packet scheduler copies that packet to external packet memory. The Packet Input/utput module is then notified and
`transmits the packet to the network.
`
`I
`
`-10-
`
`EX 1012 Page 11
`
`

`

`l I·· r 1'·,
`
`1· i:;.
`t,".
`i·.
`! ...
`j'"r" :··:
`! ..
`! .. ~
`',;
`, ..
`
`VERIFIED STATEMENT (DECLARATION) CLAIMING $MALL ENTITY
`tllATUS (37 CPR 1 .l(f) and 1.27(aU • SMALL BUSINESS CONCERN
`
`tnat 1 em
`J t1eretw •••
`IN! OWl'llr ot V1it 1mall ~S!nMII minctm idil'ltl\'itil DttlOWl
`[l
`an Qfflc11I Qt 1M •J!'lll•
`1)1.Jcil"IIMiC OCIMIMI ttrlpgwirR t<J Hl on llohalf ctf Ch GOOC41111'1
`icifiptjflNI below:
`[XI
`NAME OF CONCIRN 81+8:"~~
`
`
`...... ~s=-i4,~· ~1.,..,of ... ""lil.'"'1-n""¥MM--, WiiiJ""'"",,..-...,.1-$"'&"'1...,1·,---~~:-----
`.At:IOAUS OF CONCS'!i!Ri!'/Niliw!!!!lffo!!ll!l:Mooriii!IC-l~r,rk-.A:--~
`I htffby d.cltr• ihM h MlilYI idlm1fflod &ml!l llminess l'lOl"IMl'l'l ~1.1«Mfli18
`.l!ltl • Gm8H t:>uslnl!IU aaoown ,1111 «Mlfifltid In 13
`OFR 121,$-1 I. arid r•ccLu:ld
`In 97 CP.11 1.S(dl, fbf f!IUl'~11n l1f p11vin9
`r1~Wlllld 1'9N lfflder 11Ctl1:111 41 (al .iral {b~ of 'Tttle
`35, Unbd SU.• Cqd&. '" 1h1'1 tlMI ri1o1mber cif ~ of tr.a COl'IOel'ft, lnaludlnu 1/'li:xie 11,f 1'1111nlH&'Dl111, dClea no"t eicc.td
`lilf tha 1tttan1nt, !~ l di• 11um1:itr (If ~yl!#EI.G of the buslnmle concam la 1h41 awaiao over
`5.00 ~~. For ~Olll
`tM pre'Jlou:c; fbl;(al yaar ,e,f th• ,:ionoll'n c1 'ltll J:lllfflOl'IA a111)10yed 011 a fLll•tlrri1, part-time or 111mporary basis durirc MJl!lh ot
`ilVi pr,;iy PtrlO(lf; of 1:hit fiHil VNT, and 12, conmwR& 111 lfflllnlilll of e;ai::i, Wit!' wlffln 1it.h1r, clir=ctty or tndifac:tt,,,, •L'I•
`to =,,mro1 the o:rhl!H'. or 11 'll'IN l!lll'!V et parlitt eontro!; o, ht11; ihtf; po,Mr to oer,t:ro!
`c.onClllrn oontrola 01 t,u ttu1 ps-
`'IIOUI,
`1)
`.
`
`;tui ria~ 1.!r1$1r IIOffll'Ht OIi iaw haw bul'I etiiwtvt,11 t& and rttm1ln with ti'U!I 1m1ll bue.inea1 COo'lfttri
`
`I hltt•b'f' adar•
`il;lii,mifjljlj ilwvG wilh f•w t.'O the irn.witio11, 111,ie~ E!QL!CV
`!NGINE Af!QITECTUAE bv l~Qfl$)
`Jt.rui..al ,.loon Vu
`ducril:led in
`
`!Xl thil 11pecifioa1ion filed harewlth W'itl'I ti'tlt H llstlt4 llbow,
`
`U
`lill*tic1iion no, , fihld •
`U pat1nt no, , i11ulld ,
`thti. ri\ltu, hlkil 11v 1119 1ww identified ~malt bl.isinlss CD®am 11r, Mt excll,lalw. &aeh lnc:IMdual. C:OMffll'I'\ at m'G•nl:eati~n
`lltvin; rlgnts kl tha invanticn la'i listud .bitQw• and nc rlgl'!r.l m 'INI lnwra:iOI'\ ar• l'laltl !,y MV J!*'Con, obr 1l'llln me
`hwel'ltor, wtm QOl,lltl Mt qullifv ii 1111 lndtipendlfflt ln11entor Ul'ldet !'I CIIIII 1.11!~ It th~ pr10n m1G11'htl 1n111nt1cm, o, by
`anv concern whldl would oot ciuallf\l as a smaM tlusir'lass co11r::erf11.11'\\iw
`37 CFR 1,9!dl {)~ a """oflt Df1ll\i11"ililf\ 1i1nPr
`37 CFft 1 .9(t),
`
`ftlt'juiNlnt 1f(ll'l'I 111111!1!'1 il*'T\ed l)lflOn, CIC)ftOfltll r:,,r
`
`•NOY&: S0p11l'te vtftll!KI ttlrtl!ml!ll\t.a ••
`tnt:iliu. (t, CPA , .2.7i.
`OtQIIN2mil N>'illnQ rioNs to \ti11 !n"ff!1tlon warring IC" th1if 1111tU& H 111'1'1•11
`taMI! ACO~'.Jes""s,.._ ________
`
`..... --....-----~---~~~-------~
`..,......_~~~~~---~-----
`
`l ) lr,1111\,idullll C ! Giiil ii.ie:!n.11111 de1ncern [ j Nonprofl~ Organlz11ticm
`
`NAM&
`~CDRi""'S""'S~~~~~------------~~~~~~~~~-----~-------~~~~~-
`[ ] Srnatl Elusinl'l:ss Cancsm i ] Noript'Ofit Om,mrn
`[ I 11'1dlvie11.11!
`t xk.nowttdta the duW to file, In tl'lls epplcatkln or i,ztent, na1!tlt:a&n tif MIi' C:t'oog.e lrt statua resulting In loss of
`tit at. !lie ti1'l'lllo or rs•~l'll:I, h
`tadlat of 1:lle iHI.!& fee 1M' MY l'?laitltlilNll'lltQI
`entlt&til'l'llll'lt to litm1!111ntlty wtus piof m ~ln(J.
`fM due al'fsr n du c,i whietl tot.aw, • • IJim.ll ermiv le no lo1'IQ« approprilltfl. t!l:7 CFR 1,29(1:1!1
`l l\l'lt&by df!Clare mat all ~ mi/!14 h411'eln ot my own lcnowl1cl&t 1r1 true l!IKI that all 1t1tameM& l'Md.t on
`llatl,awd w ti. m,11; md fur'dler 1h11 thliu
`,.,.... with h
`l<....wi!IIClta thwt willful
`1~ffl8\'J01'1 and bali.t _.
`flffltllm9"'ll
`...,..
`filM i'lillimtmtll aml the ~ IQ made 1111 punidlatlll b!,< tifl9 01 imr:i,iaw\mtnt, ,r bpm, 11r1iw St$n
`1M1 ti1 ttM 1 $ of
`tt~lcatlM; 11ny paterrl
`
`1111 Unitid litate11 Cade, Mei thlJ1 $Ll!llh wlJIM f111lc11 tt:1tOm1t1t11 mav Jeop11rdla tM validity lif h
`iu1.1lnt tilarflOn, or aw f.!•11\ 1Q whleih thJs verified lttit.lll\'lilll'II! iA l!liteft!Mi.
`
`J.IAME OF fl!RSOH SIGNING ~.,Y,1-1gjl'l!jllli1,u.llL._,¥"b-~-~~--------------(cid:173)
`'910 Msiiiin-Qw.
`Tl1'L.E. CF IIIIRSON OTH!FI THAN ~.a
`Prlllli!lli!.il!l111·~ut..11.~l.lW,.o......,......,-,;:;-~---!!"':('P.-----(cid:173)
`Sujffl 197: IPD 4W, ;i@iri1 ihh
`ADCAE&S OF ~ING
`"i:.
`
`OAT£: _.1,/:..:;?~-....;/..;;6;......--t...f.;;..Y ________
`SIONATtlA!: ~.
`
`=
`
`_
`
`Received:
`
`12/16/98
`
`2:10PM;
`
`408
`
`984
`
`8483
`
`-> LIMBACH & LIMBACH
`
`L.L.P.;
`
`Page
`
`3
`
`FROM: Rap1dStream,Inc.
`o1H1t t:)y ! L.J.IIJll:\J.11,;H
`l L.Lll/11;\A(;H
`
`PHONE NO. : 408 984 8483
`Dec. 16 1998 03:19PM P3
`, :.e,, tiHH! w: al.lAMiJlW:I.L.#H!:l!.l i ~~M ::11 ij
`4Ul:l 41ol, ,a\;14;
`
`I
`I••
`~ ... ti.
`l:,·
`i..
`
`I· ... t:
`L-...
`1~.'
`r.
`lf L,
`lt I ! .
`
`V
`I t:,:
`r ..
`j:./
`
`I.
`
`~ • I
`'•i'
`
`!. t..:.
`
`EX 1012 Page 12
`
`