SVC and task 30 must then initiate set up of a new SVC.
`Assuming that the same SVC is to be used for the
`' datagrams 253 with destination address IMO) as for the
`datagrams 25A with destination address ITO). then alter
`task 30 has identified SVC(q) as the appropriate SVC.
`the datagram 25B is passed to the ATM layer 22 for
`sending out over SVC(q).
`In due course, machine M
`receives this datagram and passes it up to IP layer 20;
`however. before the datagram reaches this layer. it must
`undergo address-change processing similar to that car-
`ried out on datagram 25A. More particularly, the virtual
`destination address IMO) must be changed to the real IP
`address IM of machine M. and the real source address
`IT of machine T must be changed to the virtual
`IP
`address le of machine T associated with the virtual
`destination address IMO). This address-change process-
`ing is carried out by process 71.
`Vlfith regard to the source address change. where
`the corresponding change was effected for datagram
`25A by incrementing by one the virtual destination
`address ITO) of that datagram. then for datagram 253.
`the source address is changed to the destination
`address IMG) decremented by one.
`In a similar manner to process 70. process 71 must
`be carried out on datagram 258 after operation of the
`lP-to-SVC task 30 in machine T and prior to the filter
`task 29 in machine M.
`In addition. whilst
`the two
`address-changing operations of process 71 need not be
`carried out at the same time or at the same location. the
`changing of the source address must be done whilst the
`initial virtual destination address is still available.
`Following operation of process 71. datagram 2533
`with source address In.) and destination address IM is
`allowed through by filter task 29 and the contents of the
`datagram are passed to the relevant high-level applica-
`tion.
`
`
`
`IMQ of this machine. the virtual address chosen being
`dependent on the original virtual IP address forming the
`destination address of the datagram. As a result. all dat-
`agrams 25A having the same virtual destination
`address end up after operation of process 70 as data-
`grams 25AA with the same virtual source address.
`whereas datagrams 25A having different initial virtual
`destination addresses end up as datagrams 25AA with
`different source addresses. The process of changing
`the source address preferany involves a predetermined
`transformation of the virtual destination address - for
`
`example. to obtain the required virtual source address.
`the virtual destination address can simply be incre-
`mented by one (there would thus exist. for example. a
`set of even virtual IP addresses for machine M and a
`corresponding set of odd virtual
`IP addresses for
`machine T. each even virtual IP address of machine M
`being associated with the immediately adjacent. lower-
`valued, odd virtual IP address of machine T).
`The addresschanging process 70 must be carried
`out on datagram 25A after operation of the lP-to-SVC
`task 30 in machine M and prior to the filter task 29 in
`machine T. In addition, whilst the two address-hanging
`operations of process 70 need not be carried out at the
`same time or at the same location (though it is, of
`course. convenient to do so). the changing of the source
`address must be done whilst the initial virtual destina-
`tion address is still available.
`
`The contents of datagram 25AA are passed by IP
`layer 20 of machine T to a high-level application which.
`in the present example. produces a reply that it passes
`to layer 20 for sending back to IP address IMO), that is. to
`the source address contained in datagram 25AA. Layer
`20 produces a datagram 253 with source address lT
`and destination address IMO). Next. IP-to-SVC task 30 of
`layer 21 looks up the destination address in the cache
`table 27 to find out the SVC to be used for the reply. If,
`as will normally be the case. the same SVC is to be
`used for the reply as carried the original datagram 25A
`
`with destination address ITQ, then the SVC setup proc-
`ess will have been arraned to enter the address IMO) in
`cache table 27 against that SVC (in present case, iden-
`tified to machine T by “q'); a lookup on IMG) will thus
`return "q" as the required SVC. However. if it is desired
`to use a different SVC for datagrams 253 passing from
`T to M as used for datagrams 25A passing from M to T,
`then the first lookup on le by task 30 will not identify an
`
`9
`
`EP0836306 A1
`
`10
`
`narin sent with the real IP address of machine T; any
`reply will therefore be sent on an SVC set up to take dat-
`agrams from machine M to the real
`I? address of
`machine M. This SVC would end up taking all the reply
`messages for messages sent
`from machine M to
`machine T over all the SVCs set up in respect of the vir-
`tual IP addresses allocated to machine T. This is clearly
`undesirable. To avoid this. the source address of data-
`gram 25A is also changed by process 70. More particu-
`larly. the source address is changed from the real IP
`address of machine M to one ofthe virtual IP addresses
`
`Having described the general mechanism by which
`virtual IP addresses can be used for exchanging data-
`grams 25A and 253 across a SVC between machines
`M and T, the issue will now be addressed as to how the
`cache table 27 in machine T is updated on SVC setup to
`associate the new SVC (that is, SVC(q) at machine 1)
`with the virtual
`IP address IMG) of machine M (this is
`required where the same SVC is to be used for the reply
`datagram 253 as for the original datagram 25A). It will
`be appreciated that when the task 40 (see Figure 2) is
`executed. the INARP request sent to machine M will
`only return the real IP address IM of machine M. there
`being no other information available to the update task
`40 by which any other result could be obtained from the
`INARP task 50; clearly. something additonal needs to
`be done for update task 40 to be able to associate the
`virtual IP address IMO) with the newly created SVC(q) in
`table 27. In fact. there are a number of ways in which the
`update task could be informed that the IP address to be
`
`associated with SVC(q) is IMO). For example. the update
`task 40 could be arranged to send a request back over
`the newly-created SVC(q) asking machine M to identify
`
`New Bay Capita I, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 451 of 662
`
`

`

`11
`
`EP 0 836 306 A1
`
`12
`
`the destination IP address In” it associates with that
`SVC; from this information. the update task could deter-
`mine the associated virtual IP address IMO) of machine
`M (assuming there is a predetermined relation between
`the two as is the case in the described embodiment)
`and then update table 27 accordingly. An alternative
`approach that avoids sending a special request to
`machine M is to wait for machine M to supply the desti-
`nation IP address IT“) in the first lP datagram 25A sent
`over the new SVC(q), the update task then deriving the
`required address IMG) as described ab0ve.
`A variant of this latter approach is to leave the
`update task 40 unchanged but provide an additional
`process that:
`
`(a) delays the INARP request until the destination
`address ITO of the first datagram from machine M
`to machine T can be captured;
`
`(b) uses the captured address In.) as the source
`address of the INARP request that is now sent on to
`machine M.
`
`The implementation of the address-changing proc-
`esses 70 and 71 . and of the INARP request modification
`process. can conveniently by done by inserting a mod-
`ule (hereinafter called the VNS module) between the
`IP/ATM layer 21 and the ATM layer 22 of machine T; in
`fact. an instance of this module is created for each SVC.
`this being relatively easy to implement when using a
`STREAMS type l/O implementation as provided in most
`UNIX systems (conveniently one stream is provided for
`each SVC and the VNS module is pushed onto each
`stream when the stream is created).
`
`
`
`The INARP response from machine M will therefore
`have a destination address IT“) and a source address
`(that forms the substance of the lNAFlP response) of IM.
`By ensuring that this response datagram is subject to
`the processing effected by process 70. the source data
`in the INARP response will be changed to IMO) by the
`time the response reaches the update task 40. Thus.
`the required updating of the table 27 of machine T can
`be achieved without modification to the existing tasks of
`machines M and T but simply by the addition of a further
`process for effecting steps (a) and (b) described above.
`This approach is the preferred one for updating table 27
`and is the one used in the module described below with
`reference to Figures 6 and 7.
`The above-described system involving the alloca-
`tion of multiple virtual IP addresses to machines M and
`T and the provision of the address-changing processes
`70 and 71. permits multiple SVCs to be concurrently
`operated between the machines M and T thereby ena-
`bling implementation of the test arrangement depicted
`in Figure 4. Of course, when testing the machine M. it is
`desirable that no changes are made to this machine;
`accordingly. it is preferred for such a test arrangement to
`implement the address-changing processes 70 and 71
`in machine T.
`
`The messages passing across the boundary
`between layers 21 and 22 have already been described
`above with reference to Figure 2 and the processing
`effected by the VNS module on each of these messages
`will next be described. First. the situation of Figure 5 will
`be considered where it is machine M that initiates the
`setting up of a new SVC to machine T. The first mes-
`sage received by the VNS module will be the SVC setup
`indication message X5" and this is passed thwugh the
`VNS module without modification (see Figure 6). Next.
`the INARP request X6T is received and is subject to the
`modification process 82 described above. namely it is
`delayed until the first IP datagram 25A is received and
`
`the address le extracted and used for the source
`address of the INARP request. The INARP response
`X7“ is then received and subject to the address-chang-
`ing process 70.lP datagrams X8R from machine M to
`machine T are also subject to the address-changing
`process 70.
`IP datagrams X8T from machine T to
`machine M are subject to address-changing process
`71.
`
`Figure 7 depicts the processing effected by the
`VNS module in the situation where it is the machine T
`rather than the machine M that initiates SVC setup. The
`messages passing through the VNS module in this case
`are those shown crossing the boundary between layers
`21 and 22 in Figure 2 for machine M. The first tour mes-
`sages X1T. XST. X2“. and X4R are passed through with-
`out modification. The lNAFtP request received from
`machine M is subject to the modification process 82.
`being delayed until the destination address of the first IP
`datagram from machine T to machine M can be cap-
`tured and used as the source address of the INARP
`
`request. The INARP response X7T is subjected to proc-
`ess 71 as are IP datagrams X8T from machine T to
`machine M.
`IP datagrams X8R from machine M to
`machine T are subjected to process 70.
`It will be appreciated that many variants are possi-
`ble to the above-described embodiment of the inven-
`tion. It will also be appreciated that the invention is not
`limited to switched virtual circuits but can equally be
`applied to permanent virtual circuits. Furthermore. the
`setting up of multiple virtual circuits between two
`machines can be used not only for implementing the
`test arrangement described above with reference to Fig-
`ure 4 but also fur other purposes.
`Although the present invention has been described
`in the context of high-level addresses constituted by IP
`addresses and virtual circuits set up across an ATM net-
`work, the invention can be applied to other types high-
`level addresses and other types of virtual-circuit net-
`work. For example, the high-level addresses could be
`MAC addresses in the case of a network in the form of
`a emulated LAN (ELAN) over an ATM network
`
`Clalms
`
`1. A system in which a plurality of entities are con-
`
`New Bay Capita I, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 452 of 662
`
`

`

`13
`
`EP0836306A1
`
`nected to a network and can exchange messages
`across virtual circuits set up over the network
`between said entities. each entity having an opera-
`tive high-level address on the network, and each
`said entity comprising:
`
`-- high-level messaging means for handling
`message transmission and receipt on the basis
`of said high-level addresses. said high-level
`messaging means
`comprising means
`for
`including in outgoing ones of said messages
`the operative high-level address of the entity as
`a source identifier and the operative high level
`address of the intended recipient entity as a
`destination identifier, and means for filtering
`incoming ones of said messages according to
`the destination identifier contained in the mes-
`sage:
`-- virtual-circuit means for providing virtual cir-
`cuits between the entity and other said entities,
`there being a respective virtual circuit for each
`different destination identifier in use. and
`-- intermediate means for passing an outgoing
`message from said high-level messaging
`means to that one of the virtual circuits pro-
`vided by the virtual-circuit means which corre-
`sponds“ to the destination identifier of the
`message;
`
`message,
`
`3. A system according to claim 2, wherein said
`address-changing means is responsive to mes-
`sages sent in both directions between said first and
`second entities with virtual high—level addresses as
`destination identifiers,
`the said transformation
`effected in respect of such messages sent in one
`said direction being the reverse of the transforma-
`tion effected in respect of other such messages
`sent in the opposite said direction.
`
`4. A system according to claim 1, wherein said
`address-changing means comprises first address-
`changing functionality for effecting said changes for
`messages sent from said first entity to said second
`entity. and second address-changing functionality
`for effecting said changes for messages sem from
`said second entity to said first entity. both said first
`and second address-changing functionalities being
`provided in said second entity.
`
`5. A system according to claim 1, wherein said
`address-changing means comprises first address-
`changing functionality for effecting said changes for
`messages sent from said first entity to said second
`emity. and second address-changing functionality
`for effecting said changes for messages sent from
`said second entity to said first entity, the two said
`address-changing functionalities being provided in
`respective ones of said first and second entities.
`
`6. A system according to claim 1, wherein:
`
`-- each said entity has a low-level address on
`the network;
`-- said intermediate means of each entity fur-
`ther comprises:
`
`
`
`characterised in that each of a first and a second
`said entity has a plurality of virtual high-level
`addresses associated with it that are different from
`said operative high-level address of the entity, said
`virtual high-level addresses being usable by the
`messaging means of said first and second entities
`as destination identifiers in outgoing messages;
`and in that between said intermediate means of
`said first and second entities, there are provided
`address-changing means responsive to each of at
`least some of said messages sent between these
`entities with a said virtual high-level address as its
`destination identifier to change that address to the
`said operative high-level address of
`the corre-
`sponding entity, and to change the operative high-
`level address provided as the source identifier of
`the message into one of the said virtual high-level
`addresses associated with the sending entity in
`dependence on the virtual high-level address ini-
`tially provided as the destination identifier of the
`same message.
`
`2. A system according to claim 1. wherein said
`address-changing means effects a predetermined
`transformation on the virtual high-level address
`forming the initial destination identifier of a said
`message to which the address-hanging means is
`responsive in order to form the virtual high-level
`address to be used for the source identifier of that
`
`-- first association means for providing an
`association between the destination identi-
`tier of a outgoing message and the low-
`level address of the corresponding said
`entity.
`-- second association means for providing
`an association between the destination
`identifier of an outgoing message and a
`said virtual circuit,
`
`said intermediate means using its second
`association means to identity from the destina-
`tion identifier of a said outgoing message which
`virtual circuit
`is to be passed the message
`where such virtual circuit exists. and otherwise
`first passing a request to the said virtual circuit
`means of the same entity to establish a virtual
`circuit to the entity having the low-level address
`identified by said first association means as
`
`New Bay Capita I, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 453 of 662
`
`

`

`15
`
`EP0836 306A1
`
`the first association means of each of said first and
`second entities serving to provide an association
`between the virtual high-level addresses of the
`other of said first and second entities and the low-
`Ievel address of that other entity
`
`8. A system according to claim 7, further compris-
`ing a network server containing associations
`between
`high-level
`addresses
`and
`low-level
`addresses, said first association means of each
`said entity comprising means for interrogating said
`network server for a required association.
`
`9. A system according to claim 7, wherein said sec-
`ond association means comprises cache means for
`temporarily holding said associations between said
`destination identifiers and currently corresponding
`virtual circuits.
`
`associated with the destination identifier of the
`outgoing message; and
`-- the said virtual-circuit means of each entity
`includes setup means responsive to a said
`request from the imermediate means of the
`same entity to establish a virtual circuit to the
`said entity having the low-level address pro-
`vided in said request, said setup means caus-
`ing the intermediate means to update its
`second association means to associate the
`newly-established virtual circuit with the said
`destination identifier relevant to said request;
`
`
`
`10. A system according to any one of claims 1 to 9.
`wherein said high-level addresses are IP addresses
`and said network is 3 ATM network
`
`11. A system according to any one of claims 1 to 9,
`wherein said high-level addresses are MAC
`addresses and said network is a emulated LAN
`over an ATM network.
`
`12. A method of testing the ability of network node
`apparatus to operate a plurality of virtual circuits at
`the same time. said network node apparatus being
`arranged to establish a virtual circuit for each differ-
`ent high-level destination address being handled,
`said method involving setting up a system accord-
`ing to claim 4 with said network node apparatus as
`said first entity. and causing the network node
`apparatus to send messages to at least some of
`said virtual high-level addresses associated with
`said second entity.
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 454 of 662
`
`

`

`1A6.w6w0PE
`
`__>C.<
`
`meZFwZ
`
`
`
`22E.,...w._22?:n:
`
`_‘0.“.
`
`C5.moan:
`
`.mKm>mmm
`
`mm<_2._.<.
`k<u$959.2.2:.n$303:2
`._._uwwwmoo<n:n_..m2_I2.nwmmmoo<n:2m
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 455 of 662
`
`

`

`Mm&0H
`
`
`
`E?moan:mm>mmmN6E_“3
`
`2<ummmmoo<st<2.umammoo<n:.2wZ_IO<_)_
`
`
`
`moo<a.
`
`-cub...“-
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 456 of 662
`
`

`

`EP0836306A1
`
`" FIG. 3
`
`(PRIOR ART)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`/
`
`"N" SVCS
`
`A
`
`
`
`
`
`
`
`
`
`
`.j.
`
`"N" SVCs
`
`
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 457 of 662
`
`

`

`EPO 836 306 A1
`
`mm<s_._.<
`
`k_uwmmmonza.imm._.mZ_I0<_>_2.uwmmmoo<n:._<mm5—mz.IO<_2
`,2.2K:EbfiéJn33092.22<u$599.55.
`
`mmm>mmw
`
`H.D.aCyaBmN
`
`CLLa,
`
`New Bay Capital, LLC
`Ex.1006-Page 458 of 662
`
`

`

`EPO 836 306 A1
`
`VNS MODULE
`
`PASS-THRU
`
`82\
`
`DELAY UNTIL FIRST X6
`M WHICH USE DEST ADDR I."I
`INARP SOURCE ADDR.
`
`FRO
`
`-
`
`IP DGRMV
`
`’
`
`Samoa.
`
`IM -> IMO.)
`
`V
`
`- °°s“'”°’="” _ "WP'RES’"
`Source:
`IT =>IT
`IP DGRM
`(i)
`
`Dest: IM0)=> IM
`Source: IT => ITG)
`
`up DGRM)
`
`FIG. 6
`
`VNS MODULE
`
`I
`
`IP/ATM
`
`(INARP)
`
`FROM WHICH USE DSTN ADDR IMG)
`-
`INARP SOURCE ADDR.
`
`I LAY UNTIL FIRST X8
`
`("a DGRM)
`
`=>IT
`
`Source:
`
`lM => IMm
`
`New Bay Capital, LLC
`Ex.1006-Page 459 of 662
`
`

`

`EP0836306A1
`
`“mm” m“
`
`EUROPEAN SEARCH REPORT
`
`Applkaflon Nunba
`EP 96 41 0106
`
`APPLICATION (lnLCLé)
`
`HO4L29/06
`HO4QlI/O4
`
`PROCEEDINGS OF THE ANNUAL SYMPOSIUM ON
`FOUNDATIONS OF COMPUTER SCIE, SANTA FE.
`NOV. 20 - 22, 1994,
`no. SYMP. 35, 20 November 1994,
`GOLDNASSER S (EDITOR),
`pages 424-434, XPOOOS319SO
`LUND C ET AL:
`'IP OVER
`CONNECTION-ORIENTED NETWORKS AND
`DISTRIBUTIONAL PAGING'
`* paragraph 1 - paragraph 1.1 *
`
`DATA COMMUNICATIONS,
`vol. 24, no. 17,
`1 December 1995,
`page 103/104, 106, 108, 110 XP009547618
`MARSHALL G:
`ICLASSICAL IP OVER ARM:A
`STATUS REPORTI
`paragraph “Simple virtues““
`
`IBM TECHNICAL DISCLOSURE BULLETIN,
`vol. 35, no. 4A,
`1 September 1992,
`pages 28-31, XPOOO314666
`'COORDINATED
`ADDRESS RESOLUTION PROTOCOL PROCESSING'
`* the whole document *
`
`EP 0 523 386 A (FUJITSU)
`* page 4,
`line 20 - page 5,
`figure 3 *
`
`line 14;
`
`m w
`of rekvnt passages
`to dais:
`COMPUTER COMMUNICATIONS REVIEW,
`v01. 25, no. 4,
`1 October 1995,
`pages 49-58, XPOOOS4165O
`PARULKAR G ET AL:
`“AITPM: A STRATEGV FOR
`INTEGRATING 1P WITH ATM“
`* paragraph 2.1 *
`
`
`
`“trifle-d
`
`MHWHII‘BI‘
`
`m
`
`THE HAGUE
`
`CATEGORY 0F GTE!) DOCUMENTS
`: panimlafly rdmm if Taken duo:
`: partlmluly relevant if combined with tooth:
`document of the “me category
`: Technological background
`: non-written disclosure
`: Immediate document
`
`
`
`EPOPOEMl5“In,“(POOCOIJ
`
`13 March 1997
`
`T : (nary a: principle undying The Invention
`E : aflia p:th comment. but published m, or
`the the filing date
`D 2 dnammt and In the Inflation
`L : lacuna! did fol- other fans
`................................................................................
`6 : music of the nu patent family. corresponding
`Amman
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 460 of 662
`
`

`

`PCT
`
`WORLD INTELLECTUAL PROPERTY ORGANIZATION
`lntemational Bureau
`
`INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(51) International Patent Classification 7 :
`G06F 17/00
`
`(11) International Publication Number:
`
`WO 00/17775
`
`(43) International Publication Date:
`
`30 March 2000 (30.03.00)
`
`(21) International Application Number:
`
`PCT/US99/21934
`
`(22) International Filing Date:
`
`22 September 1999 (22.09.99)
`
`(30) Priority Data:
`60/ 1 01 ,43 ]
`09/399,753
`
`22 September 1998 (22.09.98)
`21 September 1999 (21.09.99)
`
`US
`US
`
`(7]) Applicant (for all designated States except US): SCIENCE
`APPLICATIONS INTERNATIONAL CORPORATION
`[US/US]; 10260 Campus Point Drive, San Diego, CA
`92121 (US).
`
`(72) Inventors; and
`(75) Inventors/Applicants (for US only): MILLER, Craig [US/US];
`Science Applications International Corporation, 10260 Carn-
`pus Point Drive, San Diego, CA 92121 (US). MANGIS, Jef-
`frey, K. [US/US]; Science Applications International Corpo-
`ration, 10260 Campus Point Drive, San Diego, CA 92121
`(US). LESTER, Harold, D. [US/US]; Science Applications
`International Corporation, 10260 Campus Point Drive. San
`Diego, CA 92121 (US). NICHOLAS, John, M. [US/US];
`Science Applications International Corporation, 10260 Cam-
`pus Point Drive, San Diego, CA 9212] (US). WALLO, An-
`drew [US/US]; Science Applications International Corpo—
`ration, 10260 Campus Point Drive, San Diego, CA 92121
`
`(US). KRESS, Thomas, P. [US/US]; Science Applications
`lntemational Corporation, 10260 Campus Point Drive, San
`Diego, CA 92121 (US). CHEAL, Linda, .1. [US/US]; Science
`Applications lntemational Corporation, 10260 Campus Point
`Drive, San Diego, CA 92121 (US). WEATHERBEE, James,
`E., Jr. [US/US]; Science Applications lntemational Corpo-
`ration, 10260 Campus Point Drive, San Diego, CA 92121
`(US). DAVIES, Linda, M. [US/US]; Science Applications
`lntemational Corporation, 10260 Campus Point Drive, San
`Diego, CA 92121 (US).
`
`(74) Agents: WRIGHT, Bradley et al.; Banner & Witcoff, Ltd,
`Eleventh floor,
`1001 G Street, N.W., Washington, DC
`20001-4597 (US).
`
`(81) Designated States: AE, AL, AM, AT, AU, AZ, BA, BB, BG,
`BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK, DM, EE,
`ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP,
`KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU. LV, MD,
`MG, MK, MN, MW, MX. NO, NZ, PL, PT, RO, RU, SD.
`SE, 86, SI, SK, SL, TJ, TM, TR. “IT, TZ, UA, UG, US,
`UZ, VN, YU, ZA, ZW, ARIPO patent (GH, GM, KE, LS,
`MW, SD, SL, SZ, 'I‘Z, UG, ZW), Eurasian patent (AM, AZ,
`BY, KG, KZ, MD, RU, TJ, TM), European patent (AT, BE,
`CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC,
`NL, PT, SE), OAPI patent (BF, BJ, CF, CG, CI, CM, GA,
`GN, GW, ML, MR, NE, SN, TD, TG).
`
`Published
`Without international search report and to be republished
`upon receipt of that report.
`
`
`
`A collaborative system and method allows members of a group to collaborate on a project such as a bid or proposal. According
`to a first embodiment, a complex instrument trading engine (CITE) facilitates negotiation between two or more parties. A set of tools
`and techniques are provided in order to facilitate negotiation and execution of complex instruments such as contracts between corporations
`and governments. According to a second embodiment, referred to as a dynamic collaborative environment. a user can define a group
`and a vinual private network environment including user-selected tools that facilitate communication, research, analysis, and electronic
`transactions within the group. The environment can be destroyed easily when it is no longer needed. Multiple environments can co—exist
`on the same physical network of computers.
`
`(54) Title: USER-DEFINED DYNAMIC COLLABORATIVE ENVIRONMENTS
`
`roup:
`ru '
`vldenlify group
`Describe amp
`'Paymenl
`
`Compose
`Advertisement
`
`Functions
`Available to
`Group
`
`Environment
`(link '0 wllcafions)
`
`Destroy
`Environment
`
`(57) Abstract
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 461 of 662
`
`

`

`
`
`Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT.
`51
`Slovenia
`ES
`LS
`Lesotho
`Albania
`Slovakia
`FI
`Lithuania
`LT
`SK
`Armenia
`SN
`FR
`LU
`Austria
`Senegal
`Luxembourg
`52
`Swaziland
`LV
`Latvia
`Australia
`CA
`Monaco
`TD
`Chad
`MC
`GB
`Azerbaijan
`MD
`TG
`GE
`Togo
`Republic of Moldova
`Bosnia and Herzegovina
`MG
`GH
`TJ
`Barbados
`Madagascar
`Tajikistan
`TM
`MK
`Turkmenistan
`GN
`The former Yugoslav
`Belgium
`TR
`GR
`Burkina Faso
`Turkey
`Republic of Macedonia
`'l'l‘
`HU
`Mali
`Trinidad and Tobago
`Bulgaria
`IE
`UA
`Ukraine
`Benin
`Mongolia
`IL
`UG
`Brazil
`Mauritania
`Uganda
`Malawi
`United States of America
`US
`Belarus
`IS
`IT
`UZ
`Mexico
`Uzbekistan
`Canada
`VN
`Viet Nam
`JP
`Niger
`Central African Republic
`KE
`Netherlands
`YU
`Cango
`Yugoslavia
`ZW
`Zimbabwe
`Switzerland
`KG
`Norway
`New Zealand
`KP
`Cote d‘Ivoire
`Poland
`Cameroon
`China
`Portugal
`Romania
`Cuba
`Russian Federation
`Czech Republic
`Sudan
`Germany
`Sweden
`Denmark
`Estonia
`Singapore
`
`Spain
`Finland
`France
`Gabon
`United Kingdom
`Georgia
`Ghana
`Guinea
`Greece
`Hungary
`Ireland
`Israel
`Iceland
`Italy
`Japan
`Kenya
`Kyrgyzstan
`Democratic People's
`Republic of Korea
`Republic of Roma
`anakstan
`Saint Lucia
`Liechtenstein
`Sri Lanka
`Liberia
`
`KR
`KZ
`LC
`Ll
`LK
`LR
`
`FOR THE PURPOSES OF INFORMATION ONLY
`
`ML
`MN
`MR
`MW
`MX
`NE
`NL
`NO
`NZ
`PL
`PT
`R0
`RU
`SD
`SE
`SG
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex.1006-Page 462 of 662
`
`

`

`PCT/US99/‘21934
`W0 00/l 7775
`usgg-QEMNED DYNAMIC COLLABORATIVE ENVIRONMENTS
`This application is related in subject matter to and claims priority from
`provisional US. application serial number 60/101,431, filed on September 22, 1998.
`The contents of that application are bodily incorporated herein.
`
`BA GRO
`
`OF THE
`
`NTION
`
`
`
`This invention relates generally to computer systems and networks. More
`particularly, the invention relates to systems and methods for providing user-defined
`collaborative environments for transacting business or electronic commerce.
`2. Related Information
`'
`Following hurricane Andrew, many insurance companies sought to limit their
`risk by withdrawing coverage from coastal areas. While this made good sense for the
`specific companies, it was not acceptable from a societal perspective. The cities,
`towns, homes and businesses built near the coasts could not afford to go without
`insurance, nor could the financial institutions that loaned money on these properties
`afford the risk. The problem facing the insurance companies was not the absolute
`magnitude ofthe risk, but the concentration of the risks in one area, leading to the
`possibility ofvery large losses resulting from a single event.
`One law firm had conceived the idea ofproviding a mechanism for insurance
`companies to exchange risk. Companies with a high exposure in one area (e.g.
`Florida windstomrs) could reduce their risk by ceding part ofthis to another company
`with non-coincident risk (e.g. California earthquakes) and assume part of the second
`company’s risk in return. A company (CATEX) was formed to conduct such trading,
`but the trading rules had yet to be defined and the trading infrastructure had not yet
`been developed CATEX postulated that the key barrier to insurance risk trading was
`determining the relative risk of different perils in different regions. One approach
`suggested by CATEX was to try to estimate these relative risks (termed relativities)
`for a broad set of perils and regions, to provide an initial basis for trading.
`It was recognized, for various reasons, that this could not be done feasibly
`because: general estimates of risk, rather than the risk for specific locations,
`buildings, ships, etc. would be inadequate for commerce; there were many risks to
`evaluate given all of the permutations of location, perils, and structure; and
`companies would not be willing to trade risk based strictly on a third-party's analysis
`1
`
`1. Technical Field
`
`SUBSTITUTE SHEET (RULE 26)
`
`New Bay Capital, LLC
`A
`-
`- -
`
`New Bay Capital, LLC
`Ex.1006-Page 463 of 662
`
`

`

`W0 00/l 7775
`
`PCTlUS99/21934
`
`~
`
`004mm»me
`
`An analysis of the problem, however, indicated that estimating the relativities
`was not essential to facilitate trading, or, in a broader sense, that trading was the only
`way to address the problem of insuring concentrated risk. The key difficulty
`determining how to create greater efficiency in the reinsurance market, whether by
`introducing new instruments (like swaps), bringing new capital to the market,
`connecting more buyers to more traders, or reducing the cost ofplacing reinsurance.
`It was determined that the above concept could be implemented in an electronic
`trading system that could play an important role in promoting these factors, and
`could, in fact, transform the reinsurance market, which is not very automated. A
`system that allowed trading was developed and implemented; A more detailed
`description of this system, as enhanced in accordance with various inventive
`principles herein (referred to as “first-generation” complex instrument trading
`technology), are provided below.
`More generally, as electronic commerce (and
`business-to-business commerce, in particular) has grown, various companies have
`
`
`
`developed software tools and services to facilitate transactions on the Internet and
`over private networks. E-Bay, for example, hosts a well~known web site that
`operates a transaction model (a so-called “concurrent auction”) that permits buyers
`to submit bids on items offered by individuals. Lotus Notes provides a network-
`
`oriented system that allows users within a company to collaborate on projects.
`Oracle Corporation hosts various transaction engines for clients that pay to host such
`services on a web site. DIGEX Corporation similarly hosts web-based application
`
`programs including various transaction engines. Other companies sell so-called
`“shrink wrap” software that allows individuals to set up web sites that provide
`
`catalog ordering facilities and the like.
`Some Internet service providers, such as America Online, host “chat rooms"
`
`that permit members to hold private discussions with other members who enter
`various rooms associated with predetermined topics. A company known as
`
`blueonline.com hosts a web site that facilitates collaboration on construction projects.
`
`Various virtual private networks have been created to facilitate communication
`among computer users across the Internet and other networks, but these networks
`provided very limited fimctionality (e.g., e-mail services); are not user-defined (they
`must be created and installed by system administrators); and they cannot be easily
`
`destroyed when they are no longer needed.
`2
`
`SUBSTITUTE SHEET (RULE 25)
`
`New Bay Capital, L LC
`
`New Bay Capital, LLC
`Ex.1006-Page 464 of 662
`
`

`

`WO 00/17775
`
`PCTlUSQ9/21934
`
`mummmwwp
`
`The aforementioned products and services are gen