W0 03/027801
`
`PCT/U802/29991
`
`1 /5
`
`40
`
`»
`
`J"
`
`'“
`
`46
`
`fiwvgfixfi
`42
`Y
`3’" \v
`\/
`
`SIGNALING}
`L NETWORK ,z
`,
`V If
`~
`
`‘
`
`0
`44
`v
`
`:
`.
`~
`I
`48
`.
`MM SERVER I";
`fwflk/
`SECURE xx”
`v
`vNETWORK
`KEAJ< ’
`.1}
`20
`
`«a;
`Jmmww/.
`MAIL
`\
`I
`
`
`
`32
`90
`X
`w «i...
`fig:
`
`93
`
`«f»
`
`.
`
`SERVER
`
`52
`
`15 * RELAKE
`
`{K NETWORK
`
`.M V
`
`/
`50
`
`
`
`
`
`PETITIONER APPLE INC.
`
`EX. 1004-1
`
`FIG. 1D
`
`PETITIONER APPLE INC. EX. 1004-1
`
`

`

`W0 03/027801
`
`PCT/US02/29991
`
`2/5
`
`42
`
`mx
`“E
`
`V“
`
`r” SIGNALING '_
`K NETWORK
`X “Ky/F"
`M“.
`
`
`
`,
`
`v.
`
`v
`
`18/”
`
`\\
`
`‘jkm 48
`[If
`x<
`(
`SECURE
`)
`V NETWORK
`‘x‘
`'
`w“
`'-
`
`53
`, .0 /
`
`35
`
`
`
`' a 2";
`
`‘
`
`H
`
`MAIL/APP
`ispwj
`SERVER
`x . j,
`-
`f {m \wax!
`(V
`NETWORK
`
`51
`
`E
`
`/;
`
`
`
`PETITIONER APPLE INC.
`
`EX. 1004-2
`
`PETITIONER APPLE INC. EX. 1004-2
`
`

`

`W0 03/027801
`
`PCT/US02/29991
`
`3/5
`
`' w x/‘SCP
`ff
`“I
`46
`-
`42
`~’
`N? V x/
`f SIGNALING
`"A . 48
`/
`\k NETWORK J,
`i1/
`M"
`E
`‘\
`f
`SECUR
`g 0““
`NETWORK j,
`
`1
`f
`\
`
`49
`
`‘
`
`3°
`
`V
`
`
`
`____H
`M4 _____________
`r “11“”
`,
`xxx/v
`|SERVER
`‘ w
`53
`
`v
`
`.
`
`.
`
`
`
`
`
`PETITIONER APPLE INC.
`
`EX. 1004-3
`
`PETITIONER APPLE INC. EX. 1004-3
`
`

`

`W0 03/027801
`
`PCT/U802/29991
`
`4/5
`
`mcozmuEzfifioogu...
`
`323$@
`
`
`
`x3250:0E2.—
`
`flab—.00
`
`wMS.
`
`organ:HH
`
`
`
`9.3.3ddflmaZ
`
`<:.Q w
`
`2.5.USE
`
`nuE02
`
`houcgwmmmmdm.)0Eu
`
`=mu<mom—n—
`
`
`
`“005m3:0w53mwxuoymtook0‘
`
`mun—9mno»“
`
`55359:.o...afian
`
`“$503055
`
`Joov
`
`PETITIONER APPLE INC.
`
`EX. 1004-4
`
`PETITIONER APPLE INC. EX. 1004-4
`
`
`
`
`
`

`

`W0 03/027801
`
`PCT/US02/29991
`
`5/5
`
`42
`
`,x
`
`9/
`
`?”NSIGNALING\\
`K
`"j
`NETWORK
`2
`
`MAW
`/
`
`530
`/
`
`
`
`
`
`\v
`\
`x” a. g
`\\
`V
`x j8
`(QECURE‘)M/
`xxx
`» VETWOR|F< _
`N
`fkflw/
`
`x” SERVER
`
`
`
`
`I
`
`* (ff—“v” “x
`; NETWORKWM}
`
`w
`
`fi”}_f
`
`
`
`FIG. 5
`
`PETITIONER APPLE INC.
`
`EX. 1004-5
`
`PETITIONER APPLE INC. EX. 1004-5
`
`

`

`(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`(19) World Intellectual Property
`Organization
`International Bureau
`
`(43) International Publication Date
`15 August 2013 (15.08.2013) WI P O I P C T
`
`\2
`
`(10) International Publication Number
`
`WO 2013/120069 A1
`
`(51)
`
`International Patent Classification:
`G061“ 9/00 (2006.01)
`
`(21)
`
`International Application Number:
`
`(74)
`
`Agents: GOLDSTEIN, Kevin W et al.; Stradley Ronon
`Stevens & Young, LLP, 30 Valley Stream Parkway, Mal-
`Vem, PA 19355 (US).
`
`PCT/US2013/025559
`
`(81)
`
`(22)
`
`International Filing Date:
`
`11 February 2013 (11.02.2013)
`
`(25)
`
`(26)
`
`(30)
`
`(71)
`
`(72)
`(71)
`
`Filing Language:
`
`Publication Language:
`
`English
`
`English
`
`Priority Data:
`61/596,883
`
`9 February 2012 (09.02.2012)
`
`US
`
`Applicant; CONNECTIFY [US/US]; 2400 Market Street,
`Suite 411, Philadelphia, PA 19103 (US).
`
`Inventors; and
`Applicants : PRODOEHL, Brian [US/US]; 2400 Market
`Street, Sllite 411, Philadelphia, PA 19103
`LE-
`WANDA, David [US/US]; 2400 Market Street, Suite 411,
`Philadelphia, PA 19103 (US). GIZIS, Alex [US/US]; 2400
`Market Street, Suite 411, Philadelphia, PA 19103 (US).
`LUTZ, Brian [US/US]; 2400 Market Street, Suite 411,
`Philadelphia, PA 19103 (US).
`
`Designated States (unless otherwise indicated, for every
`kind of national protection available): AE, AG, AL, AM,
`AO, AT, AU, AZ, BA, BB, BG, BH, BN, BR, BW, BY,
`BZ, CA, CII, CL, CN, CO, CR, CU, CZ, DE, DK, DM,
`DO, DZ, EC, EE, EG, ES, FI, GB, GD, GE, GH, GM, GT,
`HN, HR, HU, ID, IL, IN, IS, JP, KE, KG, KM, KN, KP,
`KR, KZ, LA, LC, LK, LR, LS, LT, LU, LY, MA, MD,
`ME, MG, MK, MN, MW, MX, MY, MZ, NA, NG, N1,
`NO, NZ, OM, PA, PE, PG, PH, PL, PT, QA, RO, RS, RU,
`RW, SC, SD, SE, SG, SK, SL, SM, ST, SV, SY, TH, TJ,
`TM, TN, TR, TT, TZ, UA, UG, US, UZ, VC, VN, ZA,
`ZM, ZW.
`
`(84)
`
`Designated States (unless otherwise indicated, for every
`kind of regional protection available): ARIPO (BVV, GH,
`GM, KE, LR, LS, MW, MZ, NA, RW, SD, SL, SZ, TZ,
`UG, ZM, ZW), Eurasian (AM, AZ, BY, KG, KZ, RU, TJ,
`TM), European (AL, AT, BE, BG, CII, CY, CZ, DE, DK,
`EE, ES, FI, FR, GB, GR, HR, HU, IE, IS, IT, LT, LU, LV,
`MC, MK, MT, NL, NO, PL, PT, RO, RS, SE, SI, SK, SM,
`
`[Continued on nextpage]
`
`(54) Title: SECURE REMOTE COMPUTER NETWORK
`m “1
`
`(57) Abstract: Systems and methods to provide improved secure, high speed
`networking between two or more computers is disclosed. The invention
`provides a robust and flexible means to readily establish a secure connection
`between two or more computers using insecure pllblic or private network
`connections, while e1iminating most of the difficulties and issues a user typ-
`ically experiences with varying Virtual private networks ("VPN") and firewall
`configurations. The inventive system can be adapted to route traffic across
`multiple network connections based on a variety of criteria,
`inclllding
`without limitation, the importance of any given data, the cost of each means
`of connection, and/or the performance of each possible means of connecting
`to the client system.
`
`counties
`1111
`
`
`
`commit?
`1t?
`
`
`
`mm W (1 mu m
`
`tel \
`NS
`9—...—
`Gv'll'lL‘MEGA'iDlN
`mew ms): in;
`
`ttcr'
`tlu»_
` \11D11L) \ ‘ \
`
`
`
`
`wvsea;
`:1 w: CAL
`was»:
`VHV51CAL
`‘
`ugmozi
`termm
`wenqu
`re mm
`1N1'ER‘ME
`lmERFacE
`wmnce
`News:
`112
` 112 1 1 I 12
`
`
`
`
`
`
`114\
`
`
`‘
`i,
`
`31.15“ m
`as x
`me x
`
`emcee-mom
`1:11er mcujaok
`
` \
`
`
`
`
`
`
`
`
`
`
`
`
`
`wamron O‘MEREKTERNM. rslwmx m
`
`
`
`comma
`
`to /
`my
` PFVSICKL
`' Melon
`HE'WOM
`Hh'i‘i‘t‘cfl
`tllTEERCE
`1MY":FAF£
`
`
`
`
`t
`m ‘1 DRSWVJRDRECYURV
`sci» up «as
`
`
`
`avatar-acme N
`1 ME mm in
`
`
`
`F16 4
`
`PETITIONER APPLE INC.
`
`EX. 1004-6
`
`ll
`
`wo2013/120069A1Iltalllllllllllllllllll
`
`PETITIONER APPLE INC. EX. 1004-6
`
`

`

`WO 2013/120069 A1 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
`
`TR), OAPI (BF, BJ, CF, CG, CI, CM, GA, GN, GQ, GW, Published:
`
`ML’ MR’ NE’ SN’ TD’ TG)‘
`
`— with international search report (Art. 21(3))
`
`PETITIONER APPLE INC.
`
`EX. 1004-7
`
`PETITIONER APPLE INC. EX. 1004-7
`
`

`

`WO 2013/120069
`
`PCT/USZOl3/025559
`
`SECURE REMOTE COMPUTER NETWORK
`
`Field of the Invention
`
`The present invention relates generally to the field of computer networks, and in
`
`more particularity, relates to secure, high speed networking between two or more
`
`computers using insecure public or private network connections. The secure, remote
`
`network provides for the configuration of an encrypted “tunnel” on a user’s private network
`
`for data packets to pass through an insecure public network without risk of exposure.
`
`Computers can communicate with one another only when connected together using
`
`some form of a communications network. The internet is one such network, which has
`
`grown extensively over the past decade, and has the distinct advantage of being able to
`
`connect computers together from anywhere in the world. Another type of communications
`
`network is a local area networks (“LAN”), which are private networks that typically exist
`
`between only a few trusted computers, usually in an office or home. A further example of a
`
`computer communications network is a wide area network (“WAN”), which is usually used
`
`as a means of communications access to the internet via a wireless radio protocol.
`
`There are many possible reasons to want remote computers to join a LAN. A LAN
`
`itself is often secure, it may contain or have access to important corporate resources at the
`
`office, or access to one's personal media or data files in a residential setting. However, once
`
`a user attaches to a LAN via a direct internet connection, the LAN is no longer secure. For
`
`this reasons, the Virtual Private Network (“VPN”) was created. The VPN is software that
`
`appears to be another LAN adapter, but uses encryption technology and methods, and
`
`internet connections, to bridge remote computers onto a local area network, without risk of
`
`directly connecting the LAN to the public and insecure internet.
`
`Fig. 1 illustrates a prior art classic Virtual Private Network 100. In such a network,
`
`predefined or rolling algorithms allow a secure connection between a computer 102 and a
`
`corporate server 116. This connection is made over any network 114, which may also be
`
`the internet, with security managed by the VPN layer on the client 108 and the server 118.
`
`Any software clients 104 on the client computer 102 will see the VPN layer 108 as a virtual
`
`network interface 106, appearing no different than the driver for a physical network
`
`—Pagel~
`
`PETITIONER APPLE INC.
`
`EX. 1004-8
`
`PETITIONER APPLE INC. EX. 1004-8
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`interface 112. The VPN encapsulates all traffic sent to it as encrypted, private data, then
`
`sends it via a standard network interface and driver 110 to a physical network interface
`
`device 112, such as a Wi—Fi or Ethernet device.
`
`The VPN data is secure over the unsecured network 114, using strong encryption.
`
`This type of encryption is superior to other standard forms of encryption, because even the
`
`structure of the data is hidden from any resource outside of the VPN. The classic VPN
`
`typically has pre—shared keys; an administrator will create encryption keys for each client
`
`computer 102, which are also known to the server 116. This prevents unauthorized users
`
`of the same VPN technology to connect, and it allows an administrator to de-authorize any
`
`given user. Some simple VPNs use only a single shared key for all connections.
`
`The classic prior art VPN routes data to a server 116, which is also physically
`
`interfaced 112 to the external, insecure network 114. The server 116 communicates via an
`
`driver interface 110 to the server part of the VPN 118. It is only within this part of the
`
`system that the encrypted data is decrypted. In the classic VPN, the VPN server 118 is
`
`responsible for authenticating VPN clients 108. It will, of course, reply to said clients with
`
`encrypted packets, so the communication and traffic is encrypted in both signal directions
`
`and is two-way secure.
`
`On the server 116, the VPN server 118 will also appear as a normal networking
`
`device to the server host operating system (“OS”), allowing access to the server's network
`
`software layer 110 and network software clients 104 within the server computer, and
`
`usually, out via a physical interface 112 to a secure corporate network 120.
`
`The effect of the classic prior art VPN is that the remote client computer 104
`
`behaves as if it is in the same building, connected to the secure corporate network 120, as
`
`the server 118 and other client computers 104. Yet, the data from the client 104 is secure,
`
`and the corporate network 120 is not subject to risk of attack via an open internet 114 or
`
`other insecure connection. A big disadvantage of a classic VPN is its complexity of use. A
`
`network administrator is usually needed, to hand out keys, to manage fire walls, etc.
`
`Moreover, it is dependent on the central authority for all VPN certifications. Even in a
`
`business scenario, managing a VPN and keeping it functional for all remote users can be a
`
`complex and problematic task.
`
`— Page 2—
`
`PETITIONER APPLE INC.
`
`EX. 1004-9
`
`PETITIONER APPLE INC. EX. 1004-9
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`In response to these type of issues, and to enable simpler VPNs for home users, a
`
`new kind of VPN management has become popular. This new VPN eliminates some or all
`
`aspects of a single central server, replacing it with a central manager for VPN certifications,
`
`which will let VPN clients rendezvous with one another, but then, at least to some extent,
`
`run peer-to—peer as long as the VPN is operating. Fig. 2 illustrates an example prior art
`
`embodiment of this modified VPN 200, which has enjoyed some success as a personal VPN.
`
`In this architecture, there is no corporate intranet, simply clients 102 that wish to merge
`
`their local networks together via a VPN.
`
`This network architecture still enlists a management server 202, but in this instance
`
`the server is only for management purposes. A client 102 will establish a connection to a
`
`web or similarly accessible front end 204, which will allow it to define a VPN connection and
`
`other clients. The web front end 204 informs the VPN Manager of the connection, and it
`
`proceeds to direct the clients to establishing a peer-to-peer, authenticated VPN connection.
`
`Some VPNs designed this way will continue to route some traffic through the VPN
`
`Manager 206, while others drop the management interface entirely and leave the clients to
`
`operate entirely peer—to—peer.
`
`Another limitation of the typical VPN user is the network itself. Some client devices
`
`may have multiple internet connections: WAN, LAN, Wi—Fi, etc. But each of these
`
`connections are not necessarily useful at all times, particularly over the course of a day for a
`
`traveler. For example, while a Wi-Fi connection may be the best communication means at
`
`one location, a WAN may be better for signal transmission at a different location.
`
`It may be
`
`complex to switch the VPN from interface to interface, and there is usually no way to take
`
`advantage of the speed of multiple interfaces when they are available.
`
`There is a history for using multiple physical interfaces and treating them as a single
`
`faster interface. This has historically been called “network bonding.” The use ofa bonded
`
`set of slower physical interfaces 112 to create one large, virtual interface is fairly well
`
`documented. Fig. 3 shows a typical prior art bonded network interconnect 300.
`
`In this
`
`system, there is a computer 102 with client applications 104 and a network interface layer
`
`106 that needs to be connected to the internet or other fast network 114. However, it only
`
`has access to slow connections 304.
`
`— Page 3 n
`
`PETITIONER APPLE INC.
`
`EX. 1004-10
`
`PETITIONER APPLE INC. EX. 1004-10
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`Using either a network layer or a device layer abstraction 302, such a system splits
`
`network traffic in some agreed—upon way over multiple point—to—point connections, such as
`
`phone lines, to a service provider 306. That service provider 306 contains a similar
`
`network layer or device layer 302, which can reassemble the traffic, delivering it to a
`
`standard network layer protocol 110, and ultimately, interfaced 112 to the target network
`
`114. Examples of this type of architecture include the Integrate Services Digital Network
`
`(“ISDN”) standard, and various systems for bonding analog phone modems such as
`
`Microsoft Modem Bonding, FatPipe, and others.
`
`To improve upon this prior art, a number of additional features can be built into a
`
`VPN system. A more flexible means of establishing the VPN connection, with the option of
`
`using readily available public resources and standards is a tangible advancement. Using
`
`standards allows the user a choice between public or private resources for this connection.
`
`A further goal of the inventive system is an even greater simplification of the VPN setup,
`
`and taking the need for a proprietary central server out of the system as a further
`
`improvement. A further objection and advancement
`
`is to establish a novel means by which
`
`the VPN can route though firewalls that can often hinder VPN use in the field. And a final
`
`advancement allows dynamic use of any and all available interfaces, optimizing performance
`
`across all means of connection between two points on the VPN, and allowing rules to factor
`
`in the cost of any interface's use as well.
`
`Based on the typical complexity of creating, establishing, and maintaining a VPN,
`
`there is plenty of room for improvement in this field. Specifically, a VPN can be created
`
`dynamically, without the need for expert configuration of the VPN, firewalls, routers, and
`
`other networking components. Coupling this with the ability to intelligently use all available
`
`bandwidth, and make the best of potentially faulty connections readily permits the ability to
`
`create a more ideal VPN for use by remote clients.
`
`OFT E I V
`
`IQN
`
`The primary elements of the secure remote computer network include means to
`
`configure an encrypted “tunnel” for data packets on a private network to pass through an
`
`insecure public network without risk of exposure.
`
`In preferred embodiments, the inventive
`
`systems and methods provide a robust and simple configuration mechanism, based on
`
`— Page 4 -
`
`PETITIONER APPLE INC.
`
`EX. 1004-11
`
`PETITIONER APPLE INC. EX. 1004-11
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`existing open standards for internet “instant” messaging and media delivery that will
`
`remove the complexity and unreliability often associated with current VPNs.
`
`More particularly, the present invention overcomes the disadvantages of the prior art
`
`and fulfills the needs described above by providing, in a preferred embodiment, a computer
`
`communications network system, comprising (a) at least one switchboard computer in a
`
`hub mode in communication connectivity with an external network; (b) at least one
`
`switchboard computer in a client mode in communication connectivity with an external
`
`network; and (c) a directory service in communication connectivity with an external
`
`network; wherein said at least one switchboard computer in a hub mode initiates a
`
`connection with said directory service to be registered and made available for said at least
`
`one switchboard computer in a client mode to dynamically communicate with said at least
`
`one switchboard computer in a hub mode through an external network.
`
`Another embodiment of the present invention is a computer communications network
`
`system, comprising (a) at least one switchboard computer in a hub mode in communication
`
`connectivity with an external network, said at least one switchboard computer further
`
`comprising a discovery server to monitor external activity, a management data base to
`
`record current network communication statistics, a plurality of network address translators,
`
`a virtual network interface to communicate with a plurality of client computers, and a virtual
`
`private network to encrypt data prior to transmitting said encrypted data to one of said
`
`network address translators; (b) at least one switchboard computer in a client mode in
`
`communication connectivity with an external network, said at least one switchboard
`
`computer further comprising a discovery server to monitor external activity, a management
`
`data base to record current network communication statistics, a plurality of network address
`
`translators, a virtual network interface to communicate with a plurality of client computers,
`
`and a virtual switch and router in communication connectivity with a virtual private network
`
`to encrypt data prior to transmitting said encrypted data to one of said network address
`
`translators; and (c) a directory service in communication connectivity with an external
`
`network; wherein sald at least one switchboard computer in a hub mode initiates a
`
`connection with said directory service to be registered and made available for said at least
`
`one switchboard computer in a client mode to communicate with said at least one
`
`switchboard computer in a hub mode through an external network.
`
`— Page 5 ~
`
`PETITIONER APPLE INC.
`
`EX. 1004-12
`
`PETITIONER APPLE INC. EX. 1004-12
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`Still another embodiment of the present invention is a method for creating a flexible
`
`and secure network connection between two or more computers, having at least one
`
`switchboard computer in a hub mode in communication connectivity with an external
`
`network; and at least one switchboard computer in a client mode in communication
`
`connectivity with an external network; and a directory service in communication
`
`connectivity with an external network; the method comprising the steps of (a)initiating from
`
`said at least one switchboard computer in a hub mode a connection with said directory
`
`service; and (b) registering said at least one switchboard computer in a hub mode a
`
`connection with said directory service as available for said at least one switchboard
`
`computer in a client mode to dynamically communicate with said at least one switchboard
`
`computer in a hub mode through an external network.
`
`lirieLQescrimimetth
`
`Fig. 1 illustrates an example prior art computer network architecture having a single
`
`VPN client and single VPN server;
`
`Fig. 2 illustrates an example prior art computer network architecture having more
`
`than one VPN client connected to a management server through the internet;
`
`Fig. 3 illustrates an example prior art computer network architecture having a client
`
`computer connected to the internet through a service provider;
`
`Fig. 4 illustrates the main components ofa preferred embodiment of a
`
`“Switchboard” VPN network;
`
`Fig. 5 illustrates the internal design of a preferred embodiment of the Switchboard
`
`module;
`
`Fig. 6A illustrates a preferred embodiment of one mode of client to hub connection
`
`via the XMPP or other directory protocol;
`
`Fig. SB illustrates another preferred embodiment of another mode of client to hub
`
`connection via the XMPP or other directory protocol through a two-hop network; and
`
`v Page 6 -
`
`PETITIONER APPLE INC.
`
`EX. 1004-13
`
`PETITIONER APPLE INC. EX. 1004-13
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`Fig. 7 illustrates an exemplary embodiment of a large private network with multiple
`
`hub access points.
`
`Other features and advantages of the present invention are provided in the following detailed
`
`description ofthe invention, which refers to the accompanying drawings.
`
`De:aited..Qexamion..Qt.Etete.tr.ed..Embflm_em.
`
`The present invention provides in various exemplary embodiments, methods and
`
`systems for transmitting data between two computer networks, using multiple, potentially
`
`insecure or unreliable connections to deliver the effect of unifying the two networks as one
`
`secure network.
`
`In addition, it provides an improved method of establishing a virtual
`
`private network over insecure or unreliable connections.
`
`An exemplary embodiment of a switchboard network 400 system according to the
`
`present invention is illustrated in Fig. 4. The network consists of at least one switchboard
`
`in hub mode 404, one or more switchboards in client mode 402, and at least one an
`
`Extensible Messaging and Presence Protocol (“XMPP”) or other similar directory service 406.
`
`The switchboard hub mode 404 is similar in some ways to a traditional VPN server, but
`
`more so it conceptually functions as a hub, similar to that in an Ethernet network. As such,
`
`the hub is not necessarily unique in a switchboard network, and there may be multiple hubs
`
`as well as multiple clients. The directory service can be an XMPP 406 or something similar
`
`in concept. The directory service can be completely private, hosted on a server appliance
`
`computer, or hosted on a public server such as Goog/e Talk.
`
`To describe the operation of an exemplary embodiment of the present inventive
`
`switchboard network, the computer 102 in hub mode 404 initiates making a connection to
`
`a directory service such as an XMPP 406, and registering that it (the computer 102 in hub
`
`mode 404) is available. The XMPP is an open protocol for real-time (e.g., instant)
`
`messaging over computer networks. The switchboard is well suited to using the XMPP
`
`protocols for directory-based discovery, but this is not the only possible service. Another
`
`similar service that might be used by the Switchboard is the Light Directory Access Protocol
`
`(“LDAP”). Potential clients may then access that service based on other security protocols,
`
`as applicable, and request connection to the switchboard network 400, via any number of
`
`— Page 7 v-
`
`PETITIONER APPLE INC.
`
`EX. 1004-14
`
`PETITIONER APPLE INC. EX. 1004-14
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`independent physical interfaces 112 connected to one or more external public or private
`
`networks, such as the internet 114.
`
`The detailed internals of an exemplary embodiment of the switchboard module 502
`
`are shown in Fig. 5. The switchboard interface appears to a host computer as another
`
`Network Interface Card, via a virtual network interface 504 for the host operating system.
`
`A Management Interface process 512 is presented to adjust the behavior of the switchboard
`
`network, based on a local client 104 interface 510, such as an XML remote procedure call
`
`(“XML-RPC”). Behaviors are also modified by changes in the active system, discovery of
`
`clients or hubs via the Discovery Server 536, or statistics and other data, which is tracked
`
`in the Management Database 520.
`
`The purpose of the Discovery Server 536 is to monitor external activity. The
`
`Discovery Server 536 will communicate with the centralized XMPP service 406, record
`
`changes to the clients 104 attached to a switchboard in server mode, and complete similar
`
`management functions.
`
`The purpose of the Management Database 520 is to record current statistics and
`
`other information useful to the network. For example, the database 520 knows the cost,
`
`current performance, and expected reliability of every way of connecting between any two
`
`nodes in the network. Thus, as illustrated in Fig. 4, for a client 402 with two physical
`
`interfaces 112 connected to the Internet 114, communicating to a hub 404 with three
`
`physical interfaces 112 also connected to the Internet 114, the database 520 would track
`
`statistics on the six possible ways of establishing a connection between the client 402 and
`the hub 404.
`
`The actual switchboard module 502 starts, as mentioned, with the virtual network
`
`interface 504. Traffic is routed 506 through a network address translation layer (“NAT”)
`
`508, which allows the host network address space to be independent of the internal routing
`
`decisions made by switchboard. The NAT 508 feeds 514 a virtual router/switch 518, which
`
`in the case of client mode will be bypassed. Data 524 from the Management Database 520
`
`and the discovery server 536 inform the Socket Packet Scheduler 526. This Scheduler 526
`
`takes into account quality of service, the number of active links between the hub and each
`
`client, the efficiency and cost of each link, and the global load on each hub link, to provide
`
`an optimal, packet by packet routing to each client over each available interface.
`
`n Page 8 —.
`
`PETITIONER APPLE INC.
`
`EX. 1004-15
`
`PETITIONER APPLE INC. EX. 1004-15
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`It is important to note that each physical link 114 to a client or hub is inherently
`
`dynamic. Interfaces may be added, removed, or simply go unreliable, and the switchboard
`
`system quickly adapts to any lost or added interfaces 112. So in a practical case, a laptop
`
`computer running a Switchboard client over Wi—Fi could be plugged into a gigabit Ethernet
`
`connection, and immediately boost the performance of on—going transactions. Or, a PC-Card
`
`or USB-based 3D modem could be added, and the laptop computer could then be taken
`
`mobile, again without disruption in on—going network transactions.
`
`The output of the router 528 passes through an optional compression module 530.
`
`This layer will compress traffic 532 to the VPN 534 that will benefit from compression, and
`
`in the other signal direction, expand traffic 532 from the VPN 534 into the router. The
`
`VPN 534 itself applies encryption to each packet, then sends it down the appropriate
`
`Internet Protocol tunnel 538 to another Network Address Translator 542. This second NAT
`
`translates the VPN packet addresses to match the network conventions of the physical
`
`network interfaces 112. VPN packets are then sent 110 to the appropriate NICs 112, and
`
`then on to each respective network 114.
`
`A packet being received by a hub 404 or client 402 follows this path in reverse. The
`
`external network 114 delivers a packet to one or more of the physical interfaces 112.
`
`These are VPN packets, which contain the encrypted private network packets. These run
`
`through a NAT 542 and on to the VPN 534 manager. This layer will dismantle the VPN,
`
`decrypt the payload, and collect complete data packets. These are then sent on 532 to the
`
`compression module 530 and decompressed if possible.
`
`If operating in a hub mode node, the packet is sent 528 to the router module 518,
`
`and perhaps sent back out to another client node, depending on the routing information for
`
`that node. Again, this is optimized in the packet scheduler 526, by analysis of the
`
`performance for all possible links, the quality of service for the particular packet, reliability
`
`of each outgoing link, and load balancing of all traffic across the hub.
`
`When the switchboard module is in client mode, the router 518 is bypassed and the
`
`packet is sent directly to the local side NAT 508. Similarly, if this is a packet destined for
`
`the hub's local network, the router directs it on 514 to the local side NAT 508. Network
`
`addresses are rationalized here for the local network 106, and eventually get routed to local
`
`client programs, or possibly back to the internet via a hub firewall.
`
`— Page9 ~
`
`PETITIONER APPLE INC.
`
`EX. 1004-16
`
`PETITIONER APPLE INC. EX. 1004-16
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`Fig. 6A and Fig. 6B illustrate some aspects of the discovery server 536 described
`
`above. As shown in Fig. 6A, a peer—to—peer 600 network may be established between any
`
`two of the multiple connections possible on switchboard enabled devices. The hub 602
`
`registers 604 with an XMPP service 606, which can be public or private. The client 612 will,
`
`at a later time, contact the XMPP or other directory service 606 and ask for a connection to
`
`the switchboard hub 602. These are general purpose protocols inherent in XMPP.
`
`In other
`
`words, the XMPP service 606 knows nothing specific about the network being established by
`
`the switchboard.
`
`In the case of XMPP, the XMPP service 606 will interrogate the client 612 and hub
`
`602, and attempts to establish a peer—to-peer link 614 between the two computers. This
`
`uses the Jingle protocol, which is intended to encapsulate multimedia data between two
`
`systems. Since the Jingle protocol itself does not care about specific contents, the
`
`switchboard is taking advantage of this mechanism for real-time streaming to make the VPN
`
`connection 614 without the usual complexity of setup.
`
`Jingle connections are set up via the open Interactive Connectivity Establishment
`
`(“ICE”) methodology, which can usually manage the complexities of NAT traversal, and thus
`
`create the peer-to—peer connection 614 shown in Fig. 6A. But when ICE cannot establish
`
`the connection, the XMPP service 606 can act as an intermediary, creating a two-hop
`
`network 620, as shown in Fig. GB. Based on the fact that the client 612 and hub 602 have
`
`connected to the XMPP service, the ICE protocols can manage a hop 622 through the XMPP
`
`service 606, because the XMPP service 606 device can be seen by, or be communicating
`
`with, both the client 612 and hub 602.
`
`It is important to note that the Jingle protocol establishes rapid transport protocol
`
`(“RTP”) connections, which are ideal for media streaming, not Transmission Control
`
`Protocol/Internet Protocol (“TCP/IP”) connections. TCP/IP connections are normally desired
`
`for 2—way data communications, where every data packet sent is acknowledged as received.
`
`Such acknowledgement of receipt is not undertaken with RTP connections. This would
`
`normally be a problem for a data link such as the switchboard VPN. However, the
`
`Switchboard VPN is already managing the possibility of faulty links, and is doing so at a high
`
`level. As such, this equates to being an advantage to the switchboard protocol.
`
`- Page 10 -*
`
`PETITIONER APPLE INC.
`
`EX. 1004-17
`
`PETITIONER APPLE INC. EX. 1004-17
`
`

`

`WO 2013/120069
`
`PCT/US2013/025559
`
`The TCP/IP protocol works great for a reliable or mostly reliable connection. But as
`
`packet failures increase, a network can get swamped by retry packets. Moving the
`
`management of these problems to a higher, multi—network view in a switchboard, more
`
`intelligent decisions can be made about lost packets. Such lost packets could get routed via
`
`a different network connection. For example, a lower priority connection might receive a
`
`request for multiple missing packets, for transmission efficiency. Similarly, a critical
`
`channel that has not yet failed may be moved to a more reliable connection, lowering the
`
`traffic burden on the failing connection. In short, the media-friendly connection is actually
`
`an advantage for switchboard’s means of implementing the VPN.
`
`A final aspect of the invention is, as mentioned, the non-uniqueness of the hub,
`
`versus a server in some prior VPN systems. As shown in Fig. 7, the switchboard
`
`architecture can be readily scaled up to very larger networks. A large private network 702
`
`may have many different points of access, via switchboard hubs 602, to a public network
`
`such as the internet 704. A switchboard client 612 may accordingly gain access to the
`
`private network via any hub 602.
`
`In such a network, the directory service 606 will automate the optimization of this
`
`connection. The dir